Andreas Tille <[EMAIL PROTECTED]> writes:
> Bill, I'm afraid you might ignore the fact that there are many
> developers who consider menu outdated and more or less just add menu
> files to just avoid a lintian warning about a missing menu file.
Hm, which lintian warning is that? There was a wish
On Sun, 9 Dec 2007, Bill Allombert wrote:
OK, this hint (is it documented somewhere?) would probably help
Not yet, though you are welcome to provide a patch for the menu
manual.
As ususal. I hope there are not even more hidden/undocumented
features which are waiting for patches in the docs.
Steve Langasek wrote:
> ... also, -Wl,--as-needed is *not* a complete solution for the problems
> caused by generating extra -l arguments. Every -lfoo option passed to the
> linker requires the corresponding -dev package to be installed at build
> time; while it is a bug if the -dev packages don'
Hey,
in the cryptsetup package we currently link statically against libgcrypt11
and libgpg-error0. cryptdisks is run before mountall.sh, thus we cannot
depend on libraries which are are located in /usr/lib. in many systems
/usr is a seperate partition.
static linking has been a good solution in t
On Sun, Dec 09, 2007 at 03:47:52PM -0800, Steve Langasek wrote:
> > However, not all applications uses those symbols in their current code, so
> > they do not need to be linked against speex themselves.
> And therefore, the scripts generating dependency information for dynamically
> linking to li
On Sun, Dec 09, 2007 at 11:31:27PM +0100, Luk Claes wrote:
> Please don't answer when you don't have read the whole thread... It was
> already very clearly mentioned that the team decided to file with
> severity important instead...
Please don't CC me on replies, I am subscribed.
cheers,
Michae
On Sun, Dec 09, 2007 at 11:31:19PM +0100, Romain Beauxis wrote:
> Le Sunday 09 December 2007 22:45:46 Nikita V. Youshchenko, vous avez écrit :
> > > However, most of the applications don't need to link against theora and
> > > speex.
> > Doesn't libshout reference symbols from libspeex and libtheo
On Sun, Dec 09, 2007 at 07:23:00PM +0100, Josselin Mouette wrote:
> Le dimanche 09 décembre 2007 à 19:11 +0100, Bernhard R. Link a écrit :
> > Just curing the symptoms instead of the problems will not help to get
> > there any sooner.
> What if there is no problem?
> For example, pkg-config --li
On Sun, Dec 09, 2007 at 01:42:02PM +0100, Christoph Haas wrote:
> On Thu, Dec 06, 2007 at 01:11:32PM -0500, Kris Deugau wrote:
> > Mmmh. Strictly speaking, sysklogd logs mail to /var/log/mail.log, along
> > with duplicating (!!) much of the content to (IIRC) /var/log/messages and
> > /var/log/ma
Michael Banck wrote:
> On Sat, Dec 08, 2007 at 06:39:15PM +0100, Raphael Hertzog wrote:
>> I don't agree with this. In a team, it's difficult to notice that one
>> member disappeared. And lack of involvement in one package doesn't mean
>> being completely MIA. As co-maintainer I wouldn't want to re
Le Sunday 09 December 2007 22:45:46 Nikita V. Youshchenko, vous avez écrit :
> > However, most of the applications don't need to link against theora and
> > speex.
>
> Doesn't libshout reference symbols from libspeex and libtheora?
Yes
> If it does, resulting binary must be linked against both th
On Mon, Dec 10, 2007 at 12:45:46AM +0300, Nikita V. Youshchenko wrote:
> > Ok, let's consider another very simple case:
> > libshout allows to perform streaming of speex, vorbis, and theora formats.
> >
> > Hence, when asking for the libs to link with, you got -lspeex and -ltheora
> > since it's n
> Ok, let's consider another very simple case:
> libshout allows to perform streaming of speex, vorbis, and theora formats.
>
> Hence, when asking for the libs to link with, you got -lspeex and -ltheora
> since it's needed to cover all build cases.
>
> However, most of the applications don't need
On Wed, Dec 05, 2007 at 11:10:29AM +0100, Andreas Tille wrote:
> On Wed, 5 Dec 2007, Bill Allombert wrote:
>
> >Actually this is not true: You can just add
> >!C menu-1
> >to the start of each files (or each menu-1 files if you prefer)
> >before concatening them.
> >Menu change format each time it
Don Armstrong wrote:
> I've modified the code to now have an explicit default list of
> architectures instead of assuming that all architectures are keeping
> up [and made the version display more verbose for things that matter.]
Thanks a lot Don. The bugs have now moved down to "Resolved". Looks
Romain Beauxis <[EMAIL PROTECTED]> writes:
> Ok, let's consider another very simple case:
> libshout allows to perform streaming of speex, vorbis, and theora formats.
>
> Hence, when asking for the libs to link with, you got -lspeex and -ltheora
> since it's needed to cover all build cases.
Why?
On Sat, 08 Dec 2007, Frans Pop wrote:
> Don Armstrong wrote:
> > [There is some argument that I should completely ignore hurd-i386 by
> > default since it isn't keeping up *at all* but I haven't made that
> > change yet.]
>
> It's been anoying for a long time and there is absolutely no
> improveme
On Sun, 09 Dec 2007, Michael Banck wrote:
> D'oh, that's a known bug in dak which does not generate Packages.gz
> for d-i/hurd-i386 [1]; I've been told it's low priority. I suggest
> you prod the ftp-masters to get this fixed.
>
> base-installer is uptodate on hurd-i386, partman-lvm is Arch: all
>
Michael Banck wrote:
> On Sun, Dec 09, 2007 at 08:06:58PM +0100, Frans Pop wrote:
> > Michael Banck wrote:
> > > D'oh, that's a known bug in dak which does not generate Packages.gz
> > > for d-i/hurd-i386 [1]; I've been told it's low priority. I suggest
> > > you prod the ftp-masters to get this f
On Sun, Dec 09, 2007 at 08:06:58PM +0100, Frans Pop wrote:
> Michael Banck wrote:
> > > And note that that is not because we upload new versions every day.
> > > partman-lvm: last version built for hurd: 45; uploaded: 2006-07-19 (1.5
> > > years!) base-installer: last version built for hurd: 1.57;
Michael Banck wrote:
> > And note that that is not because we upload new versions every day.
> > partman-lvm: last version built for hurd: 45; uploaded: 2006-07-19 (1.5
> > years!) base-installer: last version built for hurd: 1.57; uploaded:
> > 2006-05-14
>
> D'oh, that's a known bug in dak which
Le Sunday 09 December 2007 20:03:27 Kurt Roeckx, vous avez écrit :
> Anyway, I think it is bad style to use macro's in public header
> files that call functions from another library. It's also easy
> to replace them with real functions. If there are such functions
> being called I suggest you rep
On Sat, Dec 08, 2007 at 06:39:15PM +0100, Raphael Hertzog wrote:
> I don't agree with this. In a team, it's difficult to notice that one
> member disappeared. And lack of involvement in one package doesn't mean
> being completely MIA. As co-maintainer I wouldn't want to remove someone
> if I'm not
On Sun, Dec 09, 2007 at 07:23:00PM +0100, Josselin Mouette wrote:
> Hi,
>
> Le dimanche 09 décembre 2007 à 19:11 +0100, Bernhard R. Link a écrit :
> > Just curing the symptoms instead of the problems will not help to get
> > there any sooner.
>
> What if there is no problem?
>
> For example, pkg
On Fri, Dec 07, 2007 at 07:14:31PM -0800, Don Armstrong wrote:
> [There is some argument that I should completely ignore hurd-i386 by
> default since it isn't keeping up *at all* but I haven't made that
> change yet.]
Well, feel free to ignore hurd-i386 for that.
I'm not going to argue about how
On Sat, Dec 08, 2007 at 11:28:27AM +0100, Frans Pop wrote:
> Frans Pop wrote:
> http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=partman-lvm;dist=unstable
> hurd 11 uploads behind; 7 out of 20 bugs long solved
>
> http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=base-installer;dist=unstable
> hurd
Hi,
In Lille (France) there is a meeting organized by the INRIA (40 years of
this French institute of computer science). I just realized there should be
other (future?) DD or DM here, so we can try to organized a key signing
party.
Best regards,
Vincent
--
Vincent Danjean GPG k
Hi,
Le dimanche 09 décembre 2007 à 19:11 +0100, Bernhard R. Link a écrit :
> Just curing the symptoms instead of the problems will not help to get
> there any sooner.
What if there is no problem?
For example, pkg-config --libs gtk+-x11-2.0 will return, among others,
-lglib-2.0 and -lm. And this
* Josselin Mouette <[EMAIL PROTECTED]> [071209 18:48]:
> > due to the recent dpkg-shlibdeps changes, people have started adding
> > -Wl,--as-needed into their LDFLAGS.
> >
> > THIS IS NOT A GOOD IDEA.
>
> > If there are broken scripts adding too many libraries then it is time to
> > fix those scr
Le dimanche 09 décembre 2007 à 09:03 +0100, Simon Richter a écrit :
> Hi,
>
> due to the recent dpkg-shlibdeps changes, people have started adding
> -Wl,--as-needed into their LDFLAGS.
>
> THIS IS NOT A GOOD IDEA.
Of course it is. This is the most reliable way of dropping unneeded
dependencies.
On Fri, 07 Dec 2007, Loïc Minier wrote:
> On Fri, Dec 07, 2007, Raphael Hertzog wrote:
> > libgtk-x11-2.0.so.0 libgtk2.0-0 #MINVER#
> > * Devel-Package: libgtk2.0-dev
> > [EMAIL PROTECTED] 2.8.0
> > ...
> > How does that sound ?
>
> Sounds like a good start! Perhaps the injection should be exp
Le Sunday 09 December 2007 09:56:39 Zack Weinberg, vous avez écrit :
> I'm curious what prompted your message. Did a program you use
> actually break? What was the failure mode?
Yes, I agree too.
I've been using this flag recently, and in most cases it just does what's
required...
I think th
On Thu, Dec 06, 2007 at 01:11:32PM -0500, Kris Deugau wrote:
> Christoph Haas wrote:
>> At work we are using syslog-ng a lot and it's very useful for a central
>> logging server. However I don't like the syntax because it's verbose and
>> typo-prone. So I was looking at metalog and seeing it orphan
> due to the recent dpkg-shlibdeps changes, people have started adding
> -Wl,--as-needed into their LDFLAGS.
>
> THIS IS NOT A GOOD IDEA.
>
> You are essentially telling gcc to pass an option to the linker without
> understanding what it does, and, more specifically, an option that tells
> the link
Philippe Cloutier <[EMAIL PROTECTED]> writes:
>>
>> This bug is now about that all plugins are installed by default,
>> dragging in too many dependencies at install/upgrade time. I have the
>> following compromise in mind, which I first want to be commented on
>> before I do the follwing changes:
Hi,
due to the recent dpkg-shlibdeps changes, people have started adding
-Wl,--as-needed into their LDFLAGS.
THIS IS NOT A GOOD IDEA.
You are essentially telling gcc to pass an option to the linker without
understanding what it does, and, more specifically, an option that tells
the linker to sec
36 matches
Mail list logo