Bug#429064: linux-libc-dev: conflicts with
reopen 429064 thanks On Fri, Jun 15, 2007 at 09:22:12PM +0200, Aurelien Jarno wrote: > The glibc is correct here. If you don't want to get the bug assigned on > linux-2.6, then I am closing the bug. The reported problem does still exist, so closing this bug is shoving a real problem under the carpet because of disagreements amongst maintainers how to fix it. There are other (superior) way to deal with situations like this, I suggest you both talk to get to an agreement as to what the best technical fix would be... If that fails, you can invoke arbitration by the tech-ctte for example. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
glibc_2.3.6-7_i386.changes REJECTED
Hi maintainers, Sorry, but I'm going to reject this package. 1) You're adding a new package directly to unstable, instead of first to experimental. 2) Glibc is currently RC buggy, and it'd really really be better to just get an RC bugfree glibc in testing asap without all kinds of new changes 3) The locales-all package is 52MB, 275MB installed size. That's a factor 10 more than the wishlist (!) bug requestiong the package says. To top this off, it's also arch:any, so multiplying the required archive space by quite a factor. I'd encourage you to ensure the binary blogs in question are architecture neutral, and also look critically at why this package needs to be so huge, for 'just' the compiled locales. There are 380 locales supported in unstable atm, and the text representations take 6.8M? An easy optimalisation is already making sure the 850kB or so LC_COLLATE files of utf-8 locales to be shared amongst each of the UTF-8 locales. 4) You ask packages which previously depend on locales to now depend on locales|generated-locales, why not simply let locales-all provide locales? --Jeroen === If you don't understand why your files were rejected, or if the override file requires editing, reply to this email. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: glibc_2.3.6-7_i386.changes REJECTED
On Fri, Apr 14, 2006 at 12:37:20PM +0200, Aurelien Jarno wrote: > On Fri, Apr 14, 2006 at 03:03:31AM -0700, Jeroen van Wolffelaar wrote: > > Hi maintainers, > > > > Sorry, but I'm going to reject this package. > > > > 1) You're adding a new package directly to unstable, instead of first to > >experimental. > > Is it a new requirement? I wasn't aware of that. It isn't a requirement, but something I'd strongly advice for such an important package like glibc. Anyway, this certainly wasn't the strongest reason to reject, and I might not have rejected it if the other 3 points didn't exist. > More seriously, I can understand that for libc-bin, but not for package > that you are not obliged to install. > > I plan to add libc6-mipsn32 and libc6-mipsn64 soon. Should they also go > thru experimental first? As long as glibc is out of sync unstable vs testing and there are multiple RC bugs in unstable, definitely. Currently amd64 in testing is blocking on glibc being out of sync, so we'd really like to get glibc into a testing-worthy version as soon as possible. I don't have a strong opinion on this otherwise, it's more like "not to unstable right now, in this form" than "must be to experimental first", also taking into account the other issues you list with using experimental for this. I hope this clarifies my position adequately. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#271650: FTBFS: illuminator/arm -- shlibs error
On Tue, Sep 14, 2004 at 12:28:39PM -0400, Adam C Powell IV wrote: > severity 271650 important > reassign 271650 libc6 > merge 271650 222536 > thanks > > There's no way for you to have known this, but this is not an > illuminator bug, though it's keeping the latest illuminator out of > sarge. See also > http://lists.debian.org/debian-devel/2004/09/msg00616.html which had no > replies (though I welcome any ideas you have). Frankly, I have no clue :-( > Also, I'd appreciate you not filing RC bugs against a package with a > perfectly valid working version in sarge, which would pull the whole > thing out. Or else please tag it "sid". (I don't think the testing > scripts are sophisticated enough to know from the version that this > doesn't affect what's already in sarge...) There are no scripts pulling stuff automatically out of sarge, that's only done manually after checking bugreports, so just noting it there would already have been enough. Note that there is still a serious issue _somewhere_, and as I explained below, it is actually a problem for illuminator, even though the _fault_ is obviously somewhere else. If now somehow illuminator is build succesfully on arm due to sheer luck, it might propagate to testing, and lacking this luck in the future, it might be impossible to do security support for it. Build failures are always a problem of the failing package (in addition to the problem-causer, of course), however annoying that might be. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#252284: Exits (does not reload) on HUP
On Mon, Jun 07, 2004 at 12:22:10PM +0200, Thomas Hood wrote: > If you send nscd the HUP signal (signal 1) then nscd exits; it does > not reload as the author of the initscript supposed. > > If there is some signal that makes nscd restart then that signal should > be used. Otherwise 'reload' should be made a synonym for 'restart'. No, reload should not be supported then, and force-reload (defined as 'reload if supported, restart otherwise') should behave as defined. See policy 9.3.2. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl
Bug#252284: Exits (does not reload) on HUP
On Mon, Jun 07, 2004 at 12:22:10PM +0200, Thomas Hood wrote: > If you send nscd the HUP signal (signal 1) then nscd exits; it does > not reload as the author of the initscript supposed. > > If there is some signal that makes nscd restart then that signal should > be used. Otherwise 'reload' should be made a synonym for 'restart'. No, reload should not be supported then, and force-reload (defined as 'reload if supported, restart otherwise') should behave as defined. See policy 9.3.2. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#247241: FTBFS: no rule to make target build_tree when running 'debian/rules binary'
On Fri, May 21, 2004 at 01:08:09AM +0900, GOTO Masanori wrote: > At Tue, 4 May 2004 18:44:58 +0200, > Jeroen van Wolffelaar wrote: > > On Mon, May 03, 2004 at 09:36:07PM -0400, Jurij Smakov wrote: > > > According to chapter 4.8 of Policy "The binary target must be all that > > > is necessary for the user to build the binary package(s) produced from > > > this source package." > > (... patch ...) > > Thanks, it's correct. I've put it in. Cool, thanks. > Be carefult that you should set "DEB_BUILD_OPTIONS=nocheck" environment > variable to build with debian/rules binary. I don't understand. debian/rules binary should just work. Do you mean to say it will only work if I set some specific environment variable? If that's what you mean, I believe that would be a policy violation (didn't look into this very carefully yet). --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl
Bug#247241: FTBFS: no rule to make target build_tree when running 'debian/rules binary'
On Fri, May 21, 2004 at 01:08:09AM +0900, GOTO Masanori wrote: > At Tue, 4 May 2004 18:44:58 +0200, > Jeroen van Wolffelaar wrote: > > On Mon, May 03, 2004 at 09:36:07PM -0400, Jurij Smakov wrote: > > > According to chapter 4.8 of Policy "The binary target must be all that > > > is necessary for the user to build the binary package(s) produced from > > > this source package." > > (... patch ...) > > Thanks, it's correct. I've put it in. Cool, thanks. > Be carefult that you should set "DEB_BUILD_OPTIONS=nocheck" environment > variable to build with debian/rules binary. I don't understand. debian/rules binary should just work. Do you mean to say it will only work if I set some specific environment variable? If that's what you mean, I believe that would be a policy violation (didn't look into this very carefully yet). --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#221982: glibc's at fault here...
On Wed, May 05, 2004 at 12:07:08AM -0400, Daniel Jacobowitz wrote: > On Tue, May 04, 2004 at 06:25:20PM +0200, Jeroen van Wolffelaar wrote: > > retitle 221982 Please put nss modules in /lib/nss/ (or something like that) > > severity 221982 wishlist > > reassign 221982 glibc > > thanks > > > > Please keep myself in the Cc list. > > > > On Wed, Apr 21, 2004 at 02:03:33PM -0700, Jeff Bailey wrote: > > > On Wed, Apr 21, 2004 at 10:10:43PM +0200, Jeroen van Wolffelaar wrote: > > > > > > > glibc is misplacing libnss_* according to Andrew Suffield. > > > > > > > Disclaimer: I don't know that these files do, I trust this to the > > > > descretion of the glibc maintainers :). > > > > > > It's all good. Andrew's wrong in this particular case. Those files are > > > used to help glibc figure out things like how to read /etc/passwd and > > > such. These all are useful when /usr hasn't been mounted yet (and could > > > potentially be required for mounting it off of a remote NFS volume) > > > > Shouldn't it be in /lib/nss/ then? This is a good reason to not put it > > in /usr/lib//, but, I don't see why it shouldn't be in > > /lib/(nss|glibc-modules|whatever)/. These files are indeed no shared > > libraries, which makes it unnessasary (and against FHS if you're reading > > it in a certain way) to put them directly in /lib. > > You can link to them directly as shared libraries if you want to. They > are valid shared libraries. I don't see how the fact that normal use > uses dlopen makes them any less shared libraries. I was busy yesterday with shared libraries & lintian, and the discriminating factor according to lintian turns out to be: has a SONAME or not. According to policy, shared libraries do need a SONAME. I also look a bit closer to how glibc handles it, and indeed I agree with you it are shared libraries (that no other package uses them directly doesn't matter). But: Suppose the first digit indicates indicate the amount of backwards compatibility, and if either of the two others change, binary backwards compatibility is maintaind (it looks like that way). Then, this should be the layout: libc6: - libnss_dns.so.2 -> libnss_dns.so.2.3.2 (symlink) - libnss_dns.so.2.3.2 (actual library, with soname 'libnss_dns.so.2' libc6-dev: - libnss_dns.so -> libnss_dns.so.2 (symlink) - libnss_dns.a (static library for the sake of programs using this library) The problem with libc is that the filename is a bit weird (version before the .so) but that's not really a problem, but that there are symlinks etc, but no soname. If these are shared libraries, which they very much seem to be, then the soname should be set to libnss_dns.so.2 (in this case), and a shlibs entry for programs who wish to use that same library too. For the latter, you'll also need to add the static library in the -dev package (the .a file). It is actually a policy violation as it is now, but since it'd be very unfortunate if changes to these files turn out to have unforseen implications (I doubt it, but you can better play safe) this close to the Sarge release, I won't inflate the severity now. Adding a soname is quite zero-risk though: add '-Wl,-soname,libnss_dns.so.2' to the gcc line compiling libnss_dns-2.3.2.so (etc). Also extra shlibs entries don't hurt. And the strange filename is both quite unimportant, not clear it's wrong at all (just not like it is done usually), and of course way too risky to change right now. I'll make sure the lintian errors are much more clear by the way, if you run lintian with -i you'd have seen explaination, but the tag is a bit misleading. > I'd rather add shlibs entries for them, or a lintian exception. They > do not violate policy by living in /lib. Agree about the /lib: after looking closer they indeed are simple shared libraries. I was a bit 'distracted'[1] by the initial bugreport -- sorry. And by the unclear lintian error :). Kind regards, --Jeroen [1] This isn't exactly the word I was looking for, but as a non-native English speaker, it comes closest to what I could think of. -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl
Bug#221982: glibc's at fault here...
On Wed, May 05, 2004 at 12:07:08AM -0400, Daniel Jacobowitz wrote: > On Tue, May 04, 2004 at 06:25:20PM +0200, Jeroen van Wolffelaar wrote: > > retitle 221982 Please put nss modules in /lib/nss/ (or something like that) > > severity 221982 wishlist > > reassign 221982 glibc > > thanks > > > > Please keep myself in the Cc list. > > > > On Wed, Apr 21, 2004 at 02:03:33PM -0700, Jeff Bailey wrote: > > > On Wed, Apr 21, 2004 at 10:10:43PM +0200, Jeroen van Wolffelaar wrote: > > > > > > > glibc is misplacing libnss_* according to Andrew Suffield. > > > > > > > Disclaimer: I don't know that these files do, I trust this to the > > > > descretion of the glibc maintainers :). > > > > > > It's all good. Andrew's wrong in this particular case. Those files are > > > used to help glibc figure out things like how to read /etc/passwd and > > > such. These all are useful when /usr hasn't been mounted yet (and could > > > potentially be required for mounting it off of a remote NFS volume) > > > > Shouldn't it be in /lib/nss/ then? This is a good reason to not put it > > in /usr/lib//, but, I don't see why it shouldn't be in > > /lib/(nss|glibc-modules|whatever)/. These files are indeed no shared > > libraries, which makes it unnessasary (and against FHS if you're reading > > it in a certain way) to put them directly in /lib. > > You can link to them directly as shared libraries if you want to. They > are valid shared libraries. I don't see how the fact that normal use > uses dlopen makes them any less shared libraries. I was busy yesterday with shared libraries & lintian, and the discriminating factor according to lintian turns out to be: has a SONAME or not. According to policy, shared libraries do need a SONAME. I also look a bit closer to how glibc handles it, and indeed I agree with you it are shared libraries (that no other package uses them directly doesn't matter). But: Suppose the first digit indicates indicate the amount of backwards compatibility, and if either of the two others change, binary backwards compatibility is maintaind (it looks like that way). Then, this should be the layout: libc6: - libnss_dns.so.2 -> libnss_dns.so.2.3.2 (symlink) - libnss_dns.so.2.3.2 (actual library, with soname 'libnss_dns.so.2' libc6-dev: - libnss_dns.so -> libnss_dns.so.2 (symlink) - libnss_dns.a (static library for the sake of programs using this library) The problem with libc is that the filename is a bit weird (version before the .so) but that's not really a problem, but that there are symlinks etc, but no soname. If these are shared libraries, which they very much seem to be, then the soname should be set to libnss_dns.so.2 (in this case), and a shlibs entry for programs who wish to use that same library too. For the latter, you'll also need to add the static library in the -dev package (the .a file). It is actually a policy violation as it is now, but since it'd be very unfortunate if changes to these files turn out to have unforseen implications (I doubt it, but you can better play safe) this close to the Sarge release, I won't inflate the severity now. Adding a soname is quite zero-risk though: add '-Wl,-soname,libnss_dns.so.2' to the gcc line compiling libnss_dns-2.3.2.so (etc). Also extra shlibs entries don't hurt. And the strange filename is both quite unimportant, not clear it's wrong at all (just not like it is done usually), and of course way too risky to change right now. I'll make sure the lintian errors are much more clear by the way, if you run lintian with -i you'd have seen explaination, but the tag is a bit misleading. > I'd rather add shlibs entries for them, or a lintian exception. They > do not violate policy by living in /lib. Agree about the /lib: after looking closer they indeed are simple shared libraries. I was a bit 'distracted'[1] by the initial bugreport -- sorry. And by the unclear lintian error :). Kind regards, --Jeroen [1] This isn't exactly the word I was looking for, but as a non-native English speaker, it comes closest to what I could think of. -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#247241: FTBFS: no rule to make target build_tree when running 'debian/rules binary'
tags 247241 + patch
thanks
On Mon, May 03, 2004 at 09:36:07PM -0400, Jurij Smakov wrote:
> According to chapter 4.8 of Policy "The binary target must be all that
> is necessary for the user to build the binary package(s) produced from
> this source package."
Also, according to the same section, the binary-{indep,arch} and binary
targets must depend on the build target. The attached patch fixes this,
which solves this bug. The binary target indirectly depends on build via
binary-indep and binary-arch.
--- debian/rules.old2004-05-04 18:36:27.0 +0200
+++ debian/rules2004-05-04 18:38:38.0 +0200
@@ -148,10 +148,10 @@
rm -rf debian/include
# Required Debian targets
-binary-indep: testroot debian/control $(build-tree) $(patsubst
%,$(stamp)install_%,$(GLIBC_PASSES)) $(patsubst
%,$(stamp)binaryinst_%,$(DEB_INDEP_REGULAR_PACKAGES))
+binary-indep: build testroot debian/control $(build-tree) $(patsubst
%,$(stamp)install_%,$(GLIBC_PASSES)) $(patsubst
%,$(stamp)binaryinst_%,$(DEB_INDEP_REGULAR_PACKAGES))
# NOTE: Putting install_ stamps before binaryinst_ stamps in the list is the
# wrong way to represent dependencies. Fix this.
-binary-arch: testroot debian/control $(build-tree) \
+binary-arch: build testroot debian/control $(build-tree) \
$(patsubst %,$(stamp)install_%,$(GLIBC_PASSES)) \
$(patsubst %,$(stamp)binaryinst_%,$(DEB_ARCH_REGULAR_PACKAGES)) \
$(patsubst %,$(stamp)binaryinst_%,$(DEB_UDEB_PACKAGES))
--Jeroen
--
Jeroen van Wolffelaar
[EMAIL PROTECTED]
http://jeroen.A-Eskwadraat.nl
Re: Bug#221982: glibc's at fault here...
retitle 221982 Please put nss modules in /lib/nss/ (or something like that) severity 221982 wishlist reassign 221982 glibc thanks Please keep myself in the Cc list. On Wed, Apr 21, 2004 at 02:03:33PM -0700, Jeff Bailey wrote: > On Wed, Apr 21, 2004 at 10:10:43PM +0200, Jeroen van Wolffelaar wrote: > > > glibc is misplacing libnss_* according to Andrew Suffield. > > > Disclaimer: I don't know that these files do, I trust this to the > > descretion of the glibc maintainers :). > > It's all good. Andrew's wrong in this particular case. Those files are > used to help glibc figure out things like how to read /etc/passwd and > such. These all are useful when /usr hasn't been mounted yet (and could > potentially be required for mounting it off of a remote NFS volume) Shouldn't it be in /lib/nss/ then? This is a good reason to not put it in /usr/lib//, but, I don't see why it shouldn't be in /lib/(nss|glibc-modules|whatever)/. These files are indeed no shared libraries, which makes it unnessasary (and against FHS if you're reading it in a certain way) to put them directly in /lib. Kernel modules, which aren't shared libs either, are also placed in a seperate directory. It is also consistent with how /usr/lib works, also there shared object files are within subdirs. If you, glibc maintainers, really think they should be in plain /lib, please reassign to debian-policy to have an exception there (I can image 'historical reasons' could be a reason). But if historical reasons don't prevent a move, it could be a target of sarge+1. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] http://jeroen.A-Eskwadraat.nl
Bug#247241: FTBFS: no rule to make target build_tree when running 'debian/rules binary'
tags 247241 + patch
thanks
On Mon, May 03, 2004 at 09:36:07PM -0400, Jurij Smakov wrote:
> According to chapter 4.8 of Policy "The binary target must be all that
> is necessary for the user to build the binary package(s) produced from
> this source package."
Also, according to the same section, the binary-{indep,arch} and binary
targets must depend on the build target. The attached patch fixes this,
which solves this bug. The binary target indirectly depends on build via
binary-indep and binary-arch.
--- debian/rules.old2004-05-04 18:36:27.0 +0200
+++ debian/rules2004-05-04 18:38:38.0 +0200
@@ -148,10 +148,10 @@
rm -rf debian/include
# Required Debian targets
-binary-indep: testroot debian/control $(build-tree) $(patsubst
%,$(stamp)install_%,$(GLIBC_PASSES)) $(patsubst
%,$(stamp)binaryinst_%,$(DEB_INDEP_REGULAR_PACKAGES))
+binary-indep: build testroot debian/control $(build-tree) $(patsubst
%,$(stamp)install_%,$(GLIBC_PASSES)) $(patsubst
%,$(stamp)binaryinst_%,$(DEB_INDEP_REGULAR_PACKAGES))
# NOTE: Putting install_ stamps before binaryinst_ stamps in the list is the
# wrong way to represent dependencies. Fix this.
-binary-arch: testroot debian/control $(build-tree) \
+binary-arch: build testroot debian/control $(build-tree) \
$(patsubst %,$(stamp)install_%,$(GLIBC_PASSES)) \
$(patsubst %,$(stamp)binaryinst_%,$(DEB_ARCH_REGULAR_PACKAGES)) \
$(patsubst %,$(stamp)binaryinst_%,$(DEB_UDEB_PACKAGES))
--Jeroen
--
Jeroen van Wolffelaar
[EMAIL PROTECTED]
http://jeroen.A-Eskwadraat.nl
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#221982: glibc's at fault here...
retitle 221982 Please put nss modules in /lib/nss/ (or something like that) severity 221982 wishlist reassign 221982 glibc thanks Please keep myself in the Cc list. On Wed, Apr 21, 2004 at 02:03:33PM -0700, Jeff Bailey wrote: > On Wed, Apr 21, 2004 at 10:10:43PM +0200, Jeroen van Wolffelaar wrote: > > > glibc is misplacing libnss_* according to Andrew Suffield. > > > Disclaimer: I don't know that these files do, I trust this to the > > descretion of the glibc maintainers :). > > It's all good. Andrew's wrong in this particular case. Those files are > used to help glibc figure out things like how to read /etc/passwd and > such. These all are useful when /usr hasn't been mounted yet (and could > potentially be required for mounting it off of a remote NFS volume) Shouldn't it be in /lib/nss/ then? This is a good reason to not put it in /usr/lib//, but, I don't see why it shouldn't be in /lib/(nss|glibc-modules|whatever)/. These files are indeed no shared libraries, which makes it unnessasary (and against FHS if you're reading it in a certain way) to put them directly in /lib. Kernel modules, which aren't shared libs either, are also placed in a seperate directory. It is also consistent with how /usr/lib works, also there shared object files are within subdirs. If you, glibc maintainers, really think they should be in plain /lib, please reassign to debian-policy to have an exception there (I can image 'historical reasons' could be a reason). But if historical reasons don't prevent a move, it could be a target of sarge+1. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] http://jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#221982: glibc's at fault here...
# confirmed by accident tags 221982 = # As the report says, glibc is doing things wrong apparantly reassign 221982 glibc retitle 221982 Shouldn't put nss modules in /lib thanks glibc is misplacing libnss_* according to Andrew Suffield. Disclaimer: I don't know that these files do, I trust this to the descretion of the glibc maintainers :). Anyway, it's not lintian's fault that it is complaining about broken packages, rather, it is lintian's job to do so. Please add overrides if and where appropriate (f.e., if this is done for historic reasons), if you don't want to get reminded of this misplacement on every lintian run. Feel free to discuss this bug with [EMAIL PROTECTED] if you like. Thanks, --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#221982: glibc's at fault here...
# confirmed by accident tags 221982 = # As the report says, glibc is doing things wrong apparantly reassign 221982 glibc retitle 221982 Shouldn't put nss modules in /lib thanks glibc is misplacing libnss_* according to Andrew Suffield. Disclaimer: I don't know that these files do, I trust this to the descretion of the glibc maintainers :). Anyway, it's not lintian's fault that it is complaining about broken packages, rather, it is lintian's job to do so. Please add overrides if and where appropriate (f.e., if this is done for historic reasons), if you don't want to get reminded of this misplacement on every lintian run. Feel free to discuss this bug with [EMAIL PROTECTED] if you like. Thanks, --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#242546: libc6-i686: Package description: unclear about 2.6 requirements
On Tue, Apr 13, 2004 at 12:08:21AM +0900, GOTO Masanori wrote: > At Wed, 7 Apr 2004 12:29:05 +0200, > Jeroen van Wolffelaar wrote: > > The package description says: > > | This package includes support for NPTL. The optimized libraries will > > | not be used unless you are using a 2.6 kernel. > > > > It is unclear (at least to me, so probably also to others) whether this > > means that: > > > > - optimized NPTL functions will only be used with 2.6 kernels, the rest > > will work with either 2.4 or 2.6 > > > > or, > > > > - this whole package, libc6-i686, will only be used with 2.6 kernels > > > > The two sentences are on the same paragraph (suggesting they are > > related), but this is not clear from the wording... > > OK, I modified as follows: > > This set of libraries is optimized for i686 machines, and will only be > used if you have an i686 class CPU (check the output of `uname -m'). This > includes Pentium Pro, Pentium II/III/IV, Celeron CPU's and similar class > CPU's (including clones such as AMD Athlon/Opteron, VIA C3 Nehemiah, > but not VIA C3 Ezla). Plus this optimized libraries will not be used > unless you are using a 2.6 kernel. > . > This package includes support for NPTL. I'm not a native English speaker, but: you use a double negation now, which is IMHO a bit harder to read than: This set of libraries is optimized for i686 machines, and will only be used if you are running a 2.6 kernel on an i686 class CPU (check the ...) This moves the 2.6 requirement more to the front (-> beginning of first sentence), and IMHO rightfully so, because it's an important fact (especially since in Sarge 2.4 and not 2.6 is default). The enumeration about processor types is then the rest of that paragraph, people skipping the enumeration to the next paragraph won't miss important information. Regards, --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl
Bug#242546: libc6-i686: Package description: unclear about 2.6 requirements
On Tue, Apr 13, 2004 at 12:08:21AM +0900, GOTO Masanori wrote: > At Wed, 7 Apr 2004 12:29:05 +0200, > Jeroen van Wolffelaar wrote: > > The package description says: > > | This package includes support for NPTL. The optimized libraries will > > | not be used unless you are using a 2.6 kernel. > > > > It is unclear (at least to me, so probably also to others) whether this > > means that: > > > > - optimized NPTL functions will only be used with 2.6 kernels, the rest > > will work with either 2.4 or 2.6 > > > > or, > > > > - this whole package, libc6-i686, will only be used with 2.6 kernels > > > > The two sentences are on the same paragraph (suggesting they are > > related), but this is not clear from the wording... > > OK, I modified as follows: > > This set of libraries is optimized for i686 machines, and will only be > used if you have an i686 class CPU (check the output of `uname -m'). This > includes Pentium Pro, Pentium II/III/IV, Celeron CPU's and similar class > CPU's (including clones such as AMD Athlon/Opteron, VIA C3 Nehemiah, > but not VIA C3 Ezla). Plus this optimized libraries will not be used > unless you are using a 2.6 kernel. > . > This package includes support for NPTL. I'm not a native English speaker, but: you use a double negation now, which is IMHO a bit harder to read than: This set of libraries is optimized for i686 machines, and will only be used if you are running a 2.6 kernel on an i686 class CPU (check the ...) This moves the 2.6 requirement more to the front (-> beginning of first sentence), and IMHO rightfully so, because it's an important fact (especially since in Sarge 2.4 and not 2.6 is default). The enumeration about processor types is then the rest of that paragraph, people skipping the enumeration to the next paragraph won't miss important information. Regards, --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#242546: libc6-i686: Package description: unclear about 2.6 requirements
Package: libc6-i686 Version: 2.3.2.ds1-11 Severity: minor The package description says: | This package includes support for NPTL. The optimized libraries will | not be used unless you are using a 2.6 kernel. It is unclear (at least to me, so probably also to others) whether this means that: - optimized NPTL functions will only be used with 2.6 kernels, the rest will work with either 2.4 or 2.6 or, - this whole package, libc6-i686, will only be used with 2.6 kernels The two sentences are on the same paragraph (suggesting they are related), but this is not clear from the wording... --Jeroen -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.3 Locale: LANG=nl_NL.UTF-8, LC_CTYPE=nl_NL.UTF-8 Versions of packages libc6-i686 depends on: ii libc6 2.3.2.ds1-11 GNU C Library: Shared libraries an -- no debconf information -- Jeroen van Wolffelaar [EMAIL PROTECTED] http://jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
