Bug#787956: raising the severity, prevents usage of the multilib packages
On Sat, Nov 26, 2016 at 07:52:26PM +0100, Matthias Klose wrote:
> On 26.11.2016 19:42, Mark Brown wrote:
> > On Sat, Nov 26, 2016 at 03:56:21PM +0100, Matthias Klose wrote:
> > Please allow at least a little time for a response, I've no real idea
> > what you're even asking for here.
> well, I asked you in private before, without getting replies on all messages
> and
> proposals.
You sent me a mail last week asking for some additional multilib
packages for x32 ABI which seemed a bit strange at this point in the
release cycle and not that urgent as a new ABI would be at most
wishlist. I'd been intending to have a look to try to work out what's
going on with x32 over the weekend. I'm having a hard time relating
that to what you're talking about here though I do see you mentioned
that this was for "libgphobos (gdc runtime)" in both.
> This exactly is the correct issue, not "some random bug".
I'm afraid I'm still unclear what you are trying to do or why. This is
a bug about trying to use the lib32z1-dev package, your private mails
were about adding x32 multilib packages and I'm really confused about
how either of these things relates to the shared libgphobos you keep
mentioning. The proposed changes below don't have anything to do with
x32 either so I'm just completely confused now.
Can you please provide a clear, from first steps description of what's
needed and why?
> attaching the diff for the proposed changes
Please do not upload this, I will be back at home on Monday and can do
an upload then and...
> + * Non-maintainer upload.
> + * Install the zconf.h header file for the multilib packages. Closes:
> #787956.
> + * Use the target prefixed ar, available since binutils 2.26.
> + * Run dh_makeshlibs for the 64bit multilib library.
> + * Add ${misc:Depends} to zlib1g-dbg's dependencies.
> + * Support nobiarch build profile (Johannes Schauer). Closes: #709623.
...this clearly isn't just fixing the bug and there are a bunch of
additional changes not mentioned in the changelog.
I need to investigate what's going on here as I'm unconvinced that this
doesn't introduce further problems (will this break multiarch for
example, I appear to be able to build with -m32...). This might be a
lot clearer with split out incremental patches and really seems
inappropriate for a zero notice NMU.
> -Standards-Version: 3.9.4
> +Standards-Version: 3.9.8
If you're making changes like this they ought to be mentioned in the
changelog.
> -Build-Depends: debhelper (>= 8.1.3~), binutils (>= 2.18.1~cvs20080103-2)
> [mips mipsel], gcc-multilib [amd64 i386 kfreebsd-amd64 mips mipsel powerpc
> ppc64 s390 sparc s390x], dpkg-dev (>= 1.16.1)
> +Build-Depends: debhelper (>= 9), gcc-multilib [amd64 i386 kfreebsd-amd64
> mips mipsel powerpc ppc64 s390 sparc s390x] , dpkg-dev (>= 1.16.1)
Not sure why the debhelper dependency got changed or why we dropped the
binutils dependency.
Bug#787956: raising the severity, prevents usage of the multilib packages
On Sat, Nov 26, 2016 at 08:59:34PM +0100, Matthias Klose wrote: > On 26.11.2016 20:35, Mark Brown wrote: > > On Sat, Nov 26, 2016 at 07:52:26PM +0100, Matthias Klose wrote: > >> On 26.11.2016 19:42, Mark Brown wrote: > >>> On Sat, Nov 26, 2016 at 03:56:21PM +0100, Matthias Klose wrote: > >> This exactly is the correct issue, not "some random bug". > > I'm afraid I'm still unclear what you are trying to do or why. > well, you removed the example from your reply and didn't comment on it. That is one of several different things you've been talking about which seem to be related somehow to at least one underlying goal. I'm still trying to figure out that underlying goal here to work out what the most sensible thing to do is. > The example fails because the zconf.h header is not found. You can see the > list > of the standard include paths when calling gcc with the -v option. Which apparently changed at some point in the toolchain, probably quite some time ago, but fortunately we'd actually managed to remove all the users before that happened so it didn't affect anyone. Right now as far as I can tell there's been some change in the GNU D compiler that's attempting to add usage of the multilib zlib versions for some reason which is not at all clear to me. You said something about moving the GDC runtime to a shared library but I'm finding that confusing as the issue with the header file as should also affect static usage so it seems like there must be something else in the mix somewhere. It seems there's also something going on with x32 but as far as I can tell that's orthogonal though it does seem to be related to changes in GDC as well somehow. As things stand it seems like the best thing to do just looking at this issue by itself is remove the multilib zlib packages since they've been broken for some time without anyone noticing and we have multiarch so there shouldn't be any need for new users. However I don't want to just upload that right now since you're looking to add new users though I'm a bit confused as to why, it seems like a step backwards. Shouldn't people building i386 D programs on amd64 (or other similar builds that would historically have been done with multilib) just be using multiarch to install the 32 bit runtime? Please bear in mind that I'm not at all familiar with D here. signature.asc Description: PGP signature
Bug#787956: raising the severity, prevents usage of the multilib packages
On Sun, Nov 27, 2016 at 06:39:22PM +0200, Sami Liedes wrote: > It seems to me that Mark is saying that this is not even supposed to > work with lib32z1-dev installed, but rather you should have > zlib1g-dev:i386 installed (and not doing so is user error). Right, that's now the expected way for users to get an i386 version on amd64. > I found this surprising (and wonder what lib32z1-dev is actually for > then), but as I don't know how these packages are supposed to work, I > won't take a position. I am happy enough that I got things working by > installing zlib1g-dev:i386. In the past before Debian supported coinstallation of packages from multiple architectures on one system (multiarch) some packages like zlib were built specially to provide binaries for one architecture in packages for another architecture (so lib32z1 is a 32 bit version of zlib built as a package for a 64 bit architecture for example). This was called multilib and the goal has been to phase it out in favour of using multiarch. It appears that there have been changes in the toolchain that mean that broke the multilib packages (I'm guessing that it was some of the multiarch implementation) but given the availability of multiarch which supports all libraries rather than just ones that have been specially built people should be using that instead. There are some cases where the infrastructure isn't able to cope yet which may be what's going on here but they definitely don't apply to end users. signature.asc Description: PGP signature
Bug#787956: raising the severity, prevents usage of the multilib packages
On Tue, Nov 29, 2016 at 02:00:48PM +0100, Matthias Klose wrote: > On 28.11.2016 19:42, Mark Brown wrote: > > On Sat, Nov 26, 2016 at 08:59:34PM +0100, Matthias Klose wrote: > > Which apparently changed at some point in the toolchain, probably quite > > some time ago, but fortunately we'd actually managed to remove all the > > users before that happened so it didn't affect anyone. > Wrong. Until the zconf.h header was moved from /usr/include to > /usr/include/ these packages found the *wrong* header in > /usr/include, now they don't find anything anymore. So that'll be what changed. But really this is a bug in the multiarch support, zconf.h isn't at all architecture specific within the context of Debian (there's a few things that change but they're all related to completely non-Unix OSs). > > Right now as far as I can tell there's been some change in the GNU D > > compiler that's attempting to add usage of the multilib zlib versions > > for some reason which is not at all clear to me. You said something > > about moving the GDC runtime to a shared library but I'm finding that > > confusing as the issue with the header file as should also affect static > > usage so it seems like there must be something else in the mix > > somewhere. > The libphobos configury falls back to the zlib copy shipped within the GCC > sources, when the system zlib cannot be used. So sure, dropping the build > dependencies on the multilib zlib packages does use the embedded copy, but > that's not what you usually want to do. OK, so this makes at least that part of things clearer. It's not a result of linking against the DSO but rather a result of not using an embedded copy of the source. > > It seems there's also something going on with x32 but as far as I can > > tell that's orthogonal though it does seem to be related to changes in > > GDC as well somehow. > that's just the third multilib on amd64 and i386. Well, there's a bunch of questions there - people seem generally negative on x32 and the use cases for multilib with tooling for early boot and so on don't seem to apply in any case. I'd really have expected that it'd just be added as a new architecture at this point. > > Shouldn't people building i386 D programs on amd64 (or other similar > > builds that would historically have been done with multilib) just be > > using multiarch to install the 32 bit runtime? Please bear in mind > > that I'm not at all familiar with D here. > there's nothing you need to understand with D, just that it tries to use zlib > as > a dependency. No, it's trying to use a multilib zlib as a dependency. That's still really unclear to me here - to repeat my question above why aren't we asking people who want to build non-native D applications to just install the multiarch runtime? The motivation I'm aware of for still having the multilib packages is to allow other multilib packages to be built with them but I'm not seeing any packages written in D (and it'd be pretty surprising TBH given the narrow use case) so I'm not seeing the use case. > So removing these packages is fine with me too; in this case, please wait with > the removal and I'll prepare a new source package to build these multilib > libraries for the stretch release. No, that's obviously not a good solution as it just ends up duplicating the source. signature.asc Description: PGP signature
Bug#778180: xemacs21: ftbfs with GCC-5
On Fri, Jul 10, 2015 at 03:57:40PM -0600, Brett Johnson wrote: > gcc5 changes the semantics of inline function declarations, causing some > inline functions in xemacs to be considered "extern", and thus cause In what way does it change the semantics - this seems like a very surprising and counterintuitive thing to do? signature.asc Description: Digital signature
Bug#778180: xemacs21: ftbfs with GCC-5
tag 778180 - patch kthxbye > --- xemacs21-21.4.22.orig/configure.in > +++ xemacs21-21.4.22/configure.in > @@ -1941,6 +1941,8 @@ if test "$cflags_specified" = "no"; then > CFLAGS="-g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes" > dnl Yuck, bad compares have been worth at least 3 crashes! > CFLAGS="$CFLAGS -Wsign-compare" > +dnl Use old gnu inline semantics because we're too lazy to fix the source > +CFLAGS="$CFLAGS -fgnu89-inline" > dnl XEmacs is known not to be strict-aliasing-safe. > case "`gcc -v --help 2>&1`" in >*-fstrict-aliasing* ) CFLAGS="$CFLAGS -fno-strict-aliasing" ;; The other thing here is that if we're overriding CFLAGS we should do it in the packaging, not by editing configure - I've done this locally. signature.asc Description: Digital signature
Bug#778180: xemacs21: ftbfs with GCC-5
On Thu, Aug 13, 2015 at 11:33:36AM -0400, Martin Michlmayr wrote: > * Mark Brown [2015-08-13 12:51]: > > > gcc5 changes the semantics of inline function declarations, causing some > > > inline functions in xemacs to be considered "extern", and thus cause > > In what way does it change the semantics - this seems like a very > > surprising and counterintuitive thing to do? > Basically, GCC 5 changed the default from GNU89 inline semantics to > C99 inline semantics. > You can find more background here: > https://gcc.gnu.org/gcc-5/porting_to.html > see section "Different semantics for inline functions" That doesn't seem to correspond to what is happening, AFAICT the relevant things are static inline and this claims to affect only extern inline functions. signature.asc Description: Digital signature
Bug#778180: xemacs21: ftbfs with GCC-5
On Thu, Aug 13, 2015 at 09:39:09AM -0600, Brett Johnson wrote: > I agree that it would be better to make the change in the packaging, > rather than in configure.in. If you've already done this, would you > mind submitting a patch? Who would I submit a patch for the packaging to?! signature.asc Description: Digital signature
Bug#787956: raising the severity, prevents usage of the multilib packages
On Fri, Jan 06, 2017 at 08:48:06AM +0100, Matthias Klose wrote: > On 05.12.2016 18:50, Mark Brown wrote: > > As we have been discussing it is still not clear to me if I should fix > > or remove the multilib packages since it is still not clear to me that > > there is a sensible use case for them. As things stand I'm still not > > seeing much of a use case here so it seems like the best thing to do > > would be to remove the multilibs. > If this didn't become clear, may I suggest to fix the packages for the release > instead of removing them? I got that, what I still don't have a handle on is why that's a good idea - it was a worrying struggle to understand what was going on and even now that I think I've got that figured out it feels like something that's just being done by default and I am concerned that the packages will do more harm than good given the confusion they can cause with respect to multiarch. signature.asc Description: PGP signature
Bug#787956: raising the severity, prevents usage of the multilib packages
On Sat, Jan 07, 2017 at 11:15:51AM +0100, Matthias Klose wrote: > multiarch is not yet ready; you can't build it on the buildds, you can't > depend > on foreign architectures on the buildds. If you want to spend some time > working > on this, it would be appreciated, but until then I think it's better to make > these packages working. Right, but as I said before it doesn't seem like anyone is doing that with programs written in D and it also doesn't seem likely that they'll start soon. I'm just not seeing the users here. signature.asc Description: PGP signature
Bug#787956: raising the severity, prevents usage of the multilib packages
On Wed, Nov 30, 2016 at 03:31:59PM +0100, Matthias Klose wrote: > On 30.11.2016 13:45, Mark Brown wrote: > > Well, there's a bunch of questions there - people seem generally > > negative on x32 and the use cases for multilib with tooling for early > > boot and so on don't seem to apply in any case. I'd really have > > expected that it'd just be added as a new architecture at this point. > it's available in the GCC packages for a while now. Sure, but there's a bunch more stuff needed. > > install the multiarch runtime? The motivation I'm aware of for still > > having the multilib packages is to allow other multilib packages to be > > built with them but I'm not seeing any packages written in D (and it'd > > be pretty surprising TBH given the narrow use case) so I'm not seeing > > the use case. > If we remove everything where "people seem generally negative on FOO", we'll > end > up with a really small distro. We still require the multilibs for 32bit > architectures needing to build 64bit kernels, and I'd rather not ask people to > work around issues when they can be fixed. These are good reasons for having multilib for C and (to a bit of a lesser extent) C++ but this is D which is a different thing - it's a new language which is much less widely used. It is much more difficult to see the use case for D, as far as I can tell the applications don't really need multilibs. signature.asc Description: PGP signature
Bug#787956: raising the severity, prevents usage of the multilib packages
On Mon, Dec 05, 2016 at 04:40:29PM +0100, Matthias Klose wrote: > On 05.12.2016 11:29, Mark Brown wrote: > > On Wed, Nov 30, 2016 at 03:31:59PM +0100, Matthias Klose wrote: > >> it's available in the GCC packages for a while now. > > Sure, but there's a bunch more stuff needed. > sorry, I don't understand what you mean. Getting full x32 support is going to require more than just the compiler. > Well, there are less requirements for the C and C++ runtime libraries > (basically > glibc), but the D runtime library requires one more, zlib. I'm not sure what > you > are arguing here. I am suggesting that since nothing except for the multlib D runtime packages needs a multilib zlib and there seems to be a very limited use case for them it seems better to just not ship the multilib runtime for D and instead have people who want to build or run non-native D code use multiarch. That's where we want to get to anyway. > PS: I pinged about a) moving back zconf.h to /usr/include and b) running > dh_makeshlibs for the 64bit multilib variant. Any update on this? I saw your content free pings. signature.asc Description: PGP signature
Bug#787956: raising the severity, prevents usage of the multilib packages
On Mon, Dec 05, 2016 at 06:24:46PM +0100, Matthias Klose wrote: > On 05.12.2016 18:14, Mark Brown wrote: > > I am suggesting that since nothing except for the multlib D runtime > > packages needs a multilib zlib and there seems to be a very limited use > > case for them it seems better to just not ship the multilib runtime for > > D and instead have people who want to build or run non-native D code use > > multiarch. That's where we want to get to anyway. > >> PS: I pinged about a) moving back zconf.h to /usr/include and b) running > >> dh_makeshlibs for the 64bit multilib variant. Any update on this? > > I saw your content free pings. > If the ping should have been content free, than the content should be in the > PS. > Or please could you tell me what you are missing? As we have been discussing it is still not clear to me if I should fix or remove the multilib packages since it is still not clear to me that there is a sensible use case for them. As things stand I'm still not seeing much of a use case here so it seems like the best thing to do would be to remove the multilibs. signature.asc Description: PGP signature
Bug#837712: Processed: severity of 837712 is serious
On Fri, Oct 21, 2016 at 02:08:47PM +, Debian Bug Tracking System wrote: > Bug #837712 [src:xemacs21] xemacs21: FTBFS with bindnow and PIE enabled > Severity set to 'serious' from 'important' I've still not seen any usable reproduction instructions. signature.asc Description: PGP signature
Bug#837712: Processed: severity of 837712 is serious
On Fri, Oct 21, 2016 at 05:45:39PM +0200, Lucas Nussbaum wrote: > On 21/10/16 at 16:32 +0100, Mark Brown wrote: > > > Bug #837712 [src:xemacs21] xemacs21: FTBFS with bindnow and PIE enabled > > > Severity set to 'serious' from 'important' > > I've still not seen any usable reproduction instructions. > Well it fails to build in a standard, up-to-date unstable chroot here. > That was what I implied with the '# now fails in unstable' comment in my > BTS control message. > You cannot reproduce it? Could you send a build log so that we could > diff it with mine? Oh, someone uploaded these compilers to unstable? Nice :( I'll go take a look. Comments in the BTS messages really aren't visible, the messages are very noisy so it's hard to spot them. signature.asc Description: PGP signature
Bug#812532: files with the same name installed in / and /usr
severity 812532 serious On Sun, Oct 23, 2016 at 12:36:18AM +0200, Marco d'Itri wrote: > Control: severity -1 grave Please don't play severity games, it's not at all helpful. > On Jan 24, Marco d'Itri wrote: > > which have the same name of file installed by the hostname package in > > /bin/, so this breaks the package when installed on a marged /usr system. > Merged /usr is the default since debootstrap 1.0.85, so the package > is uninstallable on new systems. Which was uploaded yesterday without warning which isn't exactly helpful, there's not even been a proposal from anyone working on this for how to fix it. I would expect that if something like this were going to be imposed it'd be imposed towards the start of the release cycle rather than at the very end. signature.asc Description: PGP signature
Bug#812532: files with the same name installed in / and /usr
On Sun, Oct 23, 2016 at 01:18:54AM +0200, Marco d'Itri wrote: > On Oct 23, Mark Brown wrote: > > Which was uploaded yesterday without warning which isn't exactly > > helpful, there's not even been a proposal from anyone working on this > > for how to fix it. I would expect that if something like this were > > going to be imposed it'd be imposed towards the start of the release > > cycle rather than at the very end. > We have been discussing switching to merged /usr for over two years and > there are just five broken packages left, all of them rarely used. My expectation is that the people working on a transition like this would be pushing it forwards - things get talked about for a long time often (and Debian is quite big so the fact that some people have been talking about it doesn't mean everyone knows), there's a difference between talking about something and it actually happening. In the case of merging / and /usr it's been talked about for pretty much as long as I've been involved in Debian but the change in bug severity was the first indiciation I'd had that there was a chance of it actually being implemented. I'd have expected to at least have seen something going round saying that the transition was mostly complete and that there were only a few packages blocking it prior to just dumping a new version of deboostrap in unstable and rendering everything instabuggy. Most similar transitions have come along with patches (usually quite early on in the process) though it's not always possible, in this case I suspect it is. > This bug has been open since january and you never asked for help > (actually you hinted that yp-tools was useless anyway as is). I didn't ask for help because I just don't care about this transition, in part because as I indicated there's no way to really use yp-tools at present so it's the least of anyone's worries so when I'm spending time on these packages it'd be on the things that are required to make the package more practically useful. > We (people interested in merged /usr) are not going to waste another > release cycle. That doesn't mean it's a good idea to just implement the transition quite late in the release cycle without making any effort to coordinate with the affected packages. Some advance warning would have made all the difference here. signature.asc Description: PGP signature
Bug#812532: files with the same name installed in / and /usr
On Sun, Oct 23, 2016 at 02:06:29AM +0200, Marco d'Itri wrote: > On Oct 23, Mark Brown wrote: > > I'd have expected to at least have seen something going round saying > > that the transition was mostly complete and that there were only a few > > packages blocking it prior to just dumping a new version of deboostrap > > in unstable and rendering everything instabuggy. Most similar > I did this in *february* for the other packages, but not this one since > you had recently suggested that it was not ready anyway. Telling other package maintainers doesn't help me know that this is a transition that's actually happening, and one of the things that would tell me that there might be some sense of urgency would be an indication that the transition was actually happening. I do remember you asking me about my plans to fix it but there was no context that this was anything more than a "hey, it'd be nice sometime". For things like this even if people aren't working on something now if there's a bigger picture it's good to tell people about it, something like "OK, but please note that we're actively working on this transition and expect it to be done for stretch" would've really helped here in avoiding surprise with sudden RC bugs out of nowhere. > > I didn't ask for help because I just don't care about this transition, > > in part because as I indicated there's no way to really use yp-tools at > > present so it's the least of anyone's worries so when I'm spending time > Maybe then the package should not be in testing anyway? It's not impossible that someone could use it, it's just not as useful as it could be. signature.asc Description: PGP signature
Bug#999155: ping
On Mon, Jan 24, 2022 at 05:51:43PM +0100, Thorsten Alteholz wrote: > In order have some activity on this bug and to avoid autoremoval of > dependencies, this is a reminder of outstanding things to do ... Please don't send content free pings, they just add noise and make it likely that it's going to take longer (since I remember that I did something but forget that it was just handling the ping). signature.asc Description: PGP signature
Bug#992089: xemacs21-packages: contains a file with a non-free "disparaging to Sun" license
On Wed, Aug 11, 2021 at 02:38:48PM +0200, Pierre Gruet wrote: > Source: xemacs21-packages > Version: 2009.02.17.dfsg.2-4 > Severity: serious > Tags: stretch buster bullseye sid ... > The file > xemacs-packages/jde/java/src/jde/debugger/expr/LValue.java > incorporates a non-free license, stating This bug has been present for several decades now, it is *extremely* late for the buster release at this point and fixing this will require an upload of a new source version to pull out the file. I therefore propose that we ignore this bug for the upcoming release to avoid the minor but still present risk of disruption at this point in the cycle. signature.asc Description: PGP signature
Bug#1008265: CVE-2018-25032: zlib memory corruption on deflate
On Fri, Mar 25, 2022 at 10:50:51PM +0100, Salvatore Bonaccorso wrote: > Here is a preliminary debdiff to address this. Thanks, that's roughly what I uploaded - it looks like your mail raced with my own update. signature.asc Description: PGP signature
Bug#999155: RC bug in mm and zlib
On Wed, Jan 05, 2022 at 12:57:47PM +0100, Thorsten Alteholz wrote: > are you already working on an update of mm and zlib? Or do you need some > help? They're utterly trivial, I'll get round to them at some point when I do a batch run through all my packages. It'd be more effort to integrate something. signature.asc Description: PGP signature
Bug#915190: xemacs21-support: infinite loop in /etc/xemacs21/site-start.d
On Sun, Dec 02, 2018 at 02:20:17PM +0900, Tatsuya Kinoshita wrote:
> reassign 909381 xemacs21-support
> forcemerge 915190 909381
> tags 915190 + patch
> thanks
>
> See the following patch to fix this bug.
Which I didn't see because the mail only went to the control bot and the
pre-merged bug - it isn't even visble in the web view of the bug unless
you explicitly expand the message :( It's better to add an explicit CC
to the maintainer to make sure the BTS does the right thing, the
defaults really aren't altogether helpful for reassignments and control
mail. I'll just apply this just now, thanks...
>
> ```
> --- a/debian/00debian.el
> +++ b/debian/00debian.el
> @@ -94,8 +94,4 @@
> )
> load-path))
>
> -;; should now load from one of the /etc dirs since they are first in
> -;; the path now.
> -(load "site-start" t)
> -
> ;;; end 00debian.el
> ```
>
> This `(load "site-start" t)` was intended to load `/etc/emacs/site-start.el`,
> but unneeded now (dropped by emacsen-common 3.x).
>
> cf. https://lists.debian.org/debian-emacsen/2018/06/msg00093.html
> > Date: Sat, 16 Jun 2018 11:04:27 -0500
> > From: Rob Browning
> > Subject: [PATCH 3/4] Given new policy and emacsXY unversioning drop shared
> > dirs
> > To: debian-emac...@lists.debian.org
> > Cc: Mark Brown
> >
> > ---
> > debian/00debian.el | 7 +--
> > 1 file changed, 1 insertion(+), 6 deletions(-)
> >
> > diff --git a/debian/00debian.el b/debian/00debian.el
> > index 87508d5..fd06986 100644
> > --- a/debian/00debian.el
> > +++ b/debian/00debian.el
> > @@ -83,10 +83,6 @@ starting with a '.'"
> > (dir-and-all-good-subs
> > (expand-file-name "~/.xemacs/packages"))
> > (list (concat "/etc/xemacs" debian-xemacs-major-version))
> > - '("/etc/emacs")
> > - (list (concat "/usr/local/share/emacs/xemacs-" debian-xemacs-version
> > - "/site-lisp"))
> > - '("/usr/local/share/emacs/site-lisp")
> > `(,@(dir-and-all-good-subs "/usr/local/lib/xemacs/site-lisp")
> > ,@(dir-and-all-good-subs
> >(concat "/usr/share/xemacs/site-lisp-"
> > @@ -96,8 +92,7 @@ starting with a '.'"
> >(concat "/usr/share/xemacs" debian-xemacs-major-version
> >"/site-lisp/"))
> > )
> > - load-path
> > - '("/usr/share/emacs/site-lisp")))
> > + load-path))
> >
> > ;; should now load from one of the /etc dirs since they are first in
> > ;; the path now.
> > --
> > 2.15.1
>
> Thanks,
> --
> Tatsuya Kinoshita
signature.asc
Description: PGP signature
Bug#1012674: NMU: zlib: contrib/testzlib included (lintian: source-ships-excluded-file)
On Mon, Jul 11, 2022 at 06:16:31PM +0200, Bastian Germann wrote: > I have uploaded zlib 1.2.12.dfsg-0.1 with the changes attached to DELAYED/3. Why? Please drop this. signature.asc Description: PGP signature
Bug#1012674: NMU: zlib: contrib/testzlib included (lintian: source-ships-excluded-file)
On Mon, Jul 11, 2022 at 06:54:13PM +0200, Bastian Germann wrote: > Am 11.07.22 um 18:40 schrieb Mark Brown: > > On Mon, Jul 11, 2022 at 06:16:31PM +0200, Bastian Germann wrote: > > > I have uploaded zlib 1.2.12.dfsg-0.1 with the changes attached to > > > DELAYED/3. > > Why? Please drop this. > Okay. When are you going to address this bug then? > It has been a month not reacting to the RC bug. > I think this is not acceptable for a key package such as zlib. I'm not sure what there is to react to here other than doing an upload; it's a packaging thing more than something causing active breakage for users and we're nowhere near to doing a release yet so there didn't seem a huge sense of urgency here so I'd been going to roll it into packaging the new upstream release. The bug gives the air of being from an audit and in those cases you do have to balance keeping people up to date with creating noise for submitters and there's been no followup requests for status or anything. I have been hoping that we're going to get another upstream release which rolls in some of the fixes for the string of problems that people have been having with the security fix release that was recently done though that is looking depressingly unlikely and so I need to figure out what needs backporting. Given the release schedule startng to kick off at the beginning of next year it'll be some time this year, I'd guess some time this quarter. In any case this upload isn't a targetted fix for the individual issue, it's got a whole bunch of other unrelated changes including a new upstream release which are clearly out of scope. Like I say I have substantial concerns about the new upstream release so that having been rolled in is especially worrying. signature.asc Description: PGP signature
Bug#1012674: zlib: contrib/testzlib included (lintian: source-ships-excluded-file)
On Wed, Jul 27, 2022 at 09:00:09PM +0200, vollan...@gmail.com wrote: > There is no licence on this code, it is juste free!! If that's the goal they should have a clear statement that they're in the public domain, without an explicit license grant of some kind the default is that things are copyrighted and all rights reserved. signature.asc Description: PGP signature
Bug#897573: You need to install the extra package
On Mon, May 07, 2018 at 03:01:23PM +0200, Bastien ROUCARIES wrote: > hi, > > It is a feature you need to depends on extra package It would have been rather more helpful if you were to mention which package this is. It would also have been helpful to have made some effort to communicate this change to packages that build depend on yours when making the change rather than just letting them break with zero communication. Please also note that -done mails only go to the submitter of a bug, with duplicated bugs like this one signature.asc Description: PGP signature
Bug#853714: yp-tools_3.3-5.1_source.changes ACCEPTED into unstable
On Tue, Mar 27, 2018 at 08:51:30PM +, Debian FTP Masters wrote: >* Non-maintainer upload. >* debian/patches: > - Add patch to fix FTBFS with GCC 7. (Closes: #853714) > - Add patch to fix FTBFS on architectures with strict alignment >requirements. (Closes: #836021) Please don't send unnanounced non-maintainer uploads - note that this package can't ever be usefully installed or used at the moment as the rest of the NIS suite isn't split out into separate packages, the RC bugs are useful for keeping it out of releases. signature.asc Description: PGP signature
Bug#853714: yp-tools_3.3-5.1_source.changes ACCEPTED into unstable
On Wed, Mar 28, 2018 at 12:27:03PM +0100, James Cowgill wrote: > On 28/03/18 02:56, Mark Brown wrote: > > bugs are useful for keeping it out of releases. > I emailed the BTS with the diff on Thursday last week. The BTS says it > forwarded the email to you: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=853714#21 I'm seeing no sign of that mail having arrived on my systems. No idea what happened there... > If you don't want the package in the next release, you should file a > separate RC bug for it or at minimum email the bug explaining why it is > still open. I wasn't specifically using these bugs to keep the package out of testing (it does no harm there, it's just not useful), the problem is more that every out of tree patch added to the package makes it harder to work with and make useful. signature.asc Description: PGP signature
Bug#897551: usbview: FTBFS: convert-im6.q16: unable to open file `/tmp/magick-20115vbmutCN0nGsV': No such file or directory @ error/constitute.c/ReadImage/544.
clone 897551 -1 reassign -1 imagemagick retitle -1 imagemagic: Errors converting SVG to PNG causing build failures thanks On Wed, May 02, 2018 at 10:55:01PM +0200, Lucas Nussbaum wrote: > > make[2]: Entering directory '/<>' > > convert -geometry $(basename $(dirname $(dirname > > hicolor/64x64/apps/usbview_icon.xpm))) usbview_icon.svg > > hicolor/64x64/apps/usbview_icon.xpm > > convert-im6.q16: delegate failed `'rsvg-convert' -o '%o' '%i'' @ > > error/delegate.c/InvokeDelegate/1919. > > convert-im6.q16: unable to open file `/tmp/magick-20115vbmutCN0nGsV': No > > such file or directory @ error/constitute.c/ReadImage/544. > > convert-im6.q16: no images defined `hicolor/64x64/apps/usbview_icon.xpm' @ > > error/convert.c/ConvertImageCommand/3258. > > make[2]: *** [Makefile:964: hicolor/64x64/apps/usbview_icon.xpm] Error 1 > The full build log is available from: > > http://aws-logs.debian.net/2018/05/02/usbview_2.0-21-g6fe2f4f-1_unstable.log This appears to be triggered by some internal bug in ImageMagick, the "delegate failed" messsage doesn't appear to be an intentional error message and I can't see any obvious indication that there's been an intentional change in the ImageMagick CLI. signature.asc Description: PGP signature
Bug#952257: xemacs21-packages: FTBFS: Malformed UTF-8 character (fatal) at /usr/share/texinfo/Texinfo/ParserNonXS.pm line 3364.
On Sun, Feb 23, 2020 at 02:22:15PM +0100, Lucas Nussbaum wrote: > Relevant part (hopefully): > > make[3]: Entering directory '/<>/xemacs-packages/edit-utils' Not sure how these are generated but there's over 1000 lines of log here, most of it irrelevant. This makes it hard to both find the actual problem and reply to this mail. The only relevant part of the log is: > > cd . && makeinfo -o edit-utils.info edit-utils.texi > > cd . && makeinfo -o tempo.info tempo.texi > > utf8 "\xE5" does not map to Unicode at > > /usr/share/texinfo/Texinfo/ParserNonXS.pm line 1796, line 22. > > Malformed UTF-8 character: \xe5\x67\x65 (unexpected non-continuation byte > > 0x67, immediately after start byte 0xe5; need 3 bytes, got 1) in pattern > > match (m//) at /usr/share/texinfo/Texinfo/ParserNonXS.pm line 3364. > > Malformed UTF-8 character (fatal) at > > /usr/share/texinfo/Texinfo/ParserNonXS.pm line 3364. > > make[3]: *** [../../XEmacs.rules:310: tempo.info] Error 25 signature.asc Description: PGP signature
Bug#1060768: pdudaemon: Missing dependency on python3-aiohttp
Package: pdudaemon
Version: 0.0.8.58.g597052b-1
Severity: serious
Attempting to use pdudaemon without python3-aiohttp installed results in
a traceback:
# pdudaemon
Traceback (most recent call last):
File "/usr/sbin/pdudaemon", line 33, in
sys.exit(load_entry_point('pdudaemon==0.1', 'console_scripts',
'pdudaemon')())
^^
File "/usr/sbin/pdudaemon", line 25, in importlib_load_entry_point
return next(matches).load()
File "/usr/lib/python3.11/importlib/metadata/__init__.py", line 202, in load
module = import_module(match.group('module'))
File "/usr/lib/python3.11/importlib/__init__.py", line 126, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
File "", line 1206, in _gcd_import
File "", line 1178, in _find_and_load
File "", line 1149, in _find_and_load_unlocked
File "", line 690, in _load_unlocked
File "", line 940, in exec_module
File "", line 241, in _call_with_frames_removed
File "/usr/lib/python3/dist-packages/pdudaemon/__init__.py", line 32, in
from pdudaemon.httplistener import HTTPListener
File "/usr/lib/python3/dist-packages/pdudaemon/httplistener.py", line 24, in
from aiohttp import web
ModuleNotFoundError: No module named 'aiohttp'
but there is no dependency declared in the package. Installing the
python3-aiohttp resolves this issue.
-- System Information:
Debian Release: 12.1
APT prefers stable-security
APT policy: (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: arm64
Kernel: Linux 6.1.0-10-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8),
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages pdudaemon depends on:
ii python3 3.11.2-1+b1
pn python3-hid
pn python3-paramiko
ii python3-pexpect 4.8.0-4
ii python3-pyasn10.4.8-3
ii python3-pysnmp4 4.4.12-2
ii python3-requests 2.28.1+dfsg-1
ii python3-serial3.5-1.1
pn python3-systemd
pn python3-usb
Versions of packages pdudaemon recommends:
ii inetutils-telnet [telnet] 2:2.4-2
ii openssh-client 1:9.2p1-2
pdudaemon suggests no packages.
Bug#1074796: gnome-shell: Silently applies pending package updates on shutdown
Package: gnome-shell Version: 43.9-0+deb12u2 Severity: serious [This bug is probably misfiled, I have no idea which GNOME component is responsible for the actual behaviour so this is a guess based on the fact that I interact with the UI to trigger it.] When I select "Power off" from the power menu at the top right of the screen if there any pending package updates then instead of shutting down GNOME will reboot into a single user mode, apply the pending package updates and then shut down. I have never noticed any visible indication that this will happen rather than an immediate shutdown. On my system when there is a kernel package update this renders the system unbootable, my /boot partition does not have enough space to store two copies of the initramfs so installation of the new kernel package is left half finished with no modules available. This in turn causes boot failures since the display driver is the nVidia module and the nouveau driver which gets loaded instead simply does not work on this hardware. I can imagine this may also be an issue in cases where the user needs to power the system off urgently, for example due to running out of battery, and since I use an encrypted rootfs I am also routinely suprised to find that the system I thought I had turned off has been sitting at the decrypt filesystem prompt for an extended period. I would expect some indication that upgrades are to happen, and for there to be some way to skip the update and just do a normal shutdown instead. Windows has a model where when updates are pending some additional shutdown and reboot options are provided called "Update and X". -- System Information: Debian Release: 12.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386, arm64 Kernel: Linux 6.1.0-18-amd64 (SMP w/56 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages gnome-shell depends on: ii dconf-gsettings-backend [gsettings-backend] 0.40.0-4 ii gir1.2-accountsservice-1.0 22.08.8-6 ii gir1.2-adw-1 1.2.2-1 ii gir1.2-atk-1.0 2.46.0-5 ii gir1.2-atspi-2.0 2.46.0-5 ii gir1.2-freedesktop 1.74.0-3 ii gir1.2-gcr-3 3.41.1-1+b1 ii gir1.2-gdesktopenums-3.0 43.0-1 ii gir1.2-gdkpixbuf-2.0 2.42.10+dfsg-1+deb12u1 ii gir1.2-gdm-1.0 43.0-3 ii gir1.2-geoclue-2.0 2.6.0-2 ii gir1.2-glib-2.0 1.74.0-3 ii gir1.2-gnomebluetooth-3.042.5-3 ii gir1.2-gnomedesktop-3.0 43.2-2 ii gir1.2-graphene-1.0 1.10.8-1 ii gir1.2-gstreamer-1.0 1.22.0-2 ii gir1.2-gtk-3.0 3.24.38-2~deb12u1 ii gir1.2-gtk-4.0 4.8.3+ds-2+deb12u1 ii gir1.2-gweather-4.0 4.2.0-2 ii gir1.2-ibus-1.0 1.5.27-5 ii gir1.2-mutter-11 43.8-0+deb12u1 ii gir1.2-nm-1.01.42.4-1 ii gir1.2-nma-1.0 1.10.6-1 ii gir1.2-pango-1.0 1.50.12+ds-1 ii gir1.2-polkit-1.0122-3 ii gir1.2-rsvg-2.0 2.54.7+dfsg-1~deb12u1 ii gir1.2-soup-3.0 3.2.2-2 ii gir1.2-upowerglib-1.00.99.20-2 ii gir1.2-webkit2-4.1 2.44.2-1~deb12u1 ii gnome-backgrounds43.1-1 ii gnome-settings-daemon43.0-4 ii gnome-shell-common 43.9-0+deb12u2 ii gsettings-desktop-schemas43.0-1 ii gstreamer1.0-pipewire0.3.65-3+deb12u1 ii libatk-bridge2.0-0 2.46.0-5 ii libatk1.0-0 2.46.0-5 ii libc62.36-9+deb12u7 ii libcairo21.16.0-7 ii libecal-2.0-23.46.4-2 ii libedataserver-1.2-273.46.4-2 ii libgcr-base-3-1 3.41.1-1+b1 ii libgdk-pixbuf-2.0-0 2.42.10+dfsg-1+deb12u1 ii libgirepository-1.0-11.74.0-3 ii libgjs0g 1.74.2-1+deb12u1 ii libgles2 1.6.0-1 ii libglib2.0-0 2.74.6-2+deb12u3 ii libglib
Bug#1059165: src:zlib: fails to migrate to testing for too long: triggers autopkgtest issues
clone 1059165 -1 reassign -1 nodejs retitle -1 autopkgtest failures on i386 found -1 18.19.0+dfsg-6 block 1059165 by -1 kthxbye On Wed, Dec 20, 2023 at 08:15:31PM +0100, Paul Gevers wrote: > The Release Team considers packages that are out-of-sync between testing and > unstable for more than 30 days as having a Release Critical bug in testing > [1]. Your package src:zlib has been trying to migrate for 32 days [2]. > Hence, I am filing this bug. The version in unstable triggers autopkgtest > failures in multiple packages (although I suspect that the current dolfin > issues are due to it being flaky). The failure for burp has already a bug > report against that package, which leaves nodejs on i386. ... > This bug will trigger auto-removal when appropriate. As with all new bugs, > there will be at least 30 days before the package is auto-removed. Not sure that's likely in the case of zlib? > If you believe your package is unable to migrate to testing due to issues > beyond your control, don't hesitate to contact the Release Team. There are non-technical issues with me doing active work on nodejs package but from a quick glance the log does not seem particularly plausibly related to zlib, and I note that the failures are not ok 498 parallel/test-debugger-heap-profiler not ok 962 parallel/test-fs-utimes-y2K38 # TODO : Fix flaky test the second of which especially doesn't inspire confidence that this is due to zlib rather than general updates to unstable setting off an already flaky test (eg, the kernel changed timing?). Full log is: https://ci.debian.net/packages/n/nodejs/testing/i386/41176091/ and looking at: https://ci.debian.net/packages/n/nodejs/testing/i386/ there seem to be a number of packages triggering what from spot checks look to be the same or similar issues in nodejs in testing. I frankly don't really know what I'm supposed to do with this, the test results look like noise as far as zlib is concerned so I don't see anything to fix or investigate in the package itself. AFAICT bugs don't get filed for autopkgtest failures like they do for build failures so perhaps this was just missed up until now? signature.asc Description: PGP signature
Bug#1059165: [Pkg-javascript-devel] Bug#1059165: src:zlib: fails to migrate to testing for too long: triggers autopkgtest issues
On Wed, Dec 20, 2023 at 10:14:44PM +0100, Jérémy Lal wrote: > BURP wrong zlib version check in the failing test - this could be NMUed > DOLFIN has a single test failure, that is odd and unrelated as well - this > could be NMUed For non-technical reasons I can't do these NMUs myself if they're warranted/needed. signature.asc Description: PGP signature
Bug#1070854: clc-intercal FTBFS: dpkg-genbuildinfo: error: binary build with no binary artifacts found
On Fri, May 10, 2024 at 05:25:35PM +0300, Adrian Bunk wrote: > chmod +x `pwd`/debian/clc-intercal/usr/bin/* > dpkg-genbuildinfo --build=any > -O../clc-intercal_1.00-1_ppc64el-buildd.buildinfo > dpkg-genbuildinfo: error: binary build with no binary artifacts found; > .buildinfo is meaningless > dpkg-buildpackage: error: dpkg-genbuildinfo --build=any > -O../clc-intercal_1.00-1_ppc64el-buildd.buildinfo subprocess returned exit > status 25 I can't reproduce this, and nothing about the build I'm seeing in the log looks meaningfully different to what I get when I build locally. AFAICT there are .so files being installed among the various perl things and dpkg-genbuildinfo runs happily. signature.asc Description: PGP signature
Bug#367882: FTBFS: 'VERSION' was not declared in this scope
On Sat, Jun 03, 2006 at 01:03:54AM +0200, Steinar H. Gunderson wrote: > Downgrading to scons in stable seems to fix the problem, so this sounds very > much like a scons bug to me. Changing Add_define in bysys/libscim.py to append a list rather than a string appears to resolve the build failure. Patch below. I'm trying to remember if this is a deliberate thing or a bug: I seem to remember the former and do note that the examples in the manual tend to add spaces as one would expect given this being deliberate (eg, in the "Appending to End Values in a Construction Environment" section). --- bksys/libscim.py.orig 2006-06-03 10:35:47.0 +0100 +++ bksys/libscim.py2006-06-03 10:36:02.0 +0100 @@ -68,7 +68,7 @@ def Add_define(env, name): if env.has_key(name): - env.AppendUnique(CCFLAGS = '-D' + name + '=\\"' + env[name] + '\\"' ) + env.AppendUnique(CCFLAGS = ['-D' + name + '=\\"' + env[name] + '\\"'] ) return # these are our options > Cc-ing [EMAIL PROTECTED] I have no idea how that reached me but it did... Should be [EMAIL PROTECTED] -- "You grabbed my hand and we fell into it, like a daydream - or a fever." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#338886: [EMAIL PROTECTED]: Bug#338886: leafnode security bug SA-2005:02 (CVE-2005-1911)]
The enclosed bug was filed by Leafnode upstream. I believe this patch
contains the relevant fix:
diff -urN leafnode-1.11.2.rel/artutil.c leafnode-1.11.3.rel/artutil.c
--- leafnode-1.11.2.rel/artutil.c 2004-03-16 02:54:43.0 +
+++ leafnode-1.11.3.rel/artutil.c 2005-06-08 14:53:24.0 +0100
@@ -37,7 +37,7 @@
rewind(f);
debug = 0;
hdr = NULL;
-while ((p = getfoldedline(f)) && *p) {
+while ((p = getfoldedline(f, getaline)) && *p) {
/* read only headers */
char *q = p;
if ((strncasecmp(q, header, hlen) == 0)) {
diff -urN leafnode-1.11.2.rel/fetchnews.c leafnode-1.11.3.rel/fetchnews.c
--- leafnode-1.11.2.rel/fetchnews.c 2005-05-04 11:01:44.0 +0100
+++ leafnode-1.11.3.rel/fetchnews.c 2005-06-08 14:53:12.0 +0100
@@ -1166,7 +1166,7 @@
}
c = NULL;
n = 9; /* "other" header */
- while ((l = getfoldedline(nntpin)) && *l && strcmp(l, ".")) {
+ while ((l = getfoldedline(nntpin, mgetaline)) && *l && strcmp(l, ".")) {
/* regexp pattern matching */
if (filterfile && dofilter(l)) {
killed++;
diff -urN leafnode-1.11.2.rel/getfoldedline.c
leafnode-1.11.3.rel/getfoldedline.c
--- leafnode-1.11.2.rel/getfoldedline.c 2003-10-19 23:12:22.0 +0100
+++ leafnode-1.11.3.rel/getfoldedline.c 2005-06-08 14:56:13.0 +0100
@@ -8,7 +8,7 @@
#include
/[EMAIL PROTECTED]@*/ /[EMAIL PROTECTED]@*/ char *
-getfoldedline(FILE * f)
+getfoldedline(FILE * f, char *(*reader)(FILE *))
{
/* what characters are considered whitespace that marks the beginning of
continuation lines.
@@ -18,7 +18,7 @@
int c;
size_t len, oldlen;
-l1 = getaline(f);
+l1 = reader(f);
if (!l1)
return NULL;
l2 = (char *)critmalloc((len = strlen(l1)) + 1, "getfoldedline");
@@ -33,7 +33,7 @@
ungetc(c, f);
if (strchr(white, c)) {
/* join */
- l1 = getaline(f);
+ l1 = reader(f);
if (l1) {
oldlen = len;
len += strlen(l1) + 1;
@@ -60,7 +60,7 @@
main()
{
char *f;
-while ((f = getfoldedline(stdin))) {
+while ((f = getfoldedline(stdin, getaline))) {
puts(f);
free(f);
}
diff -urN leafnode-1.11.2.rel/leafnode.h leafnode-1.11.3.rel/leafnode.h
--- leafnode-1.11.2.rel/leafnode.h 2005-04-05 16:56:08.0 +0100
+++ leafnode-1.11.3.rel/leafnode.h 2005-06-08 15:06:15.0 +0100
@@ -3,7 +3,7 @@
* conditions.
*/
-/* $Id: leafnode.h,v 1.92 2005/04/05 15:56:08 emma Exp $ */
+/* $Id: leafnode.h,v 1.93 2005/06/08 14:06:15 emma Exp $ */
#ifndef LEAFNODE_H
#define LEAFNODE_H
@@ -353,7 +353,7 @@
/* from getfoldedline.c */
/[EMAIL PROTECTED]@*/ /[EMAIL PROTECTED]@*/
-char *getfoldedline(FILE * f);
+char *getfoldedline(FILE * f, char *(*reader)(FILE *));
/* reads one line, regardless of length, returns malloc()ed string! */
/* from writes.c (ln-2) */
--
"You grabbed my hand and we fell into it, like a daydream - or a fever."
--- Begin Message ---
Package: leafnode
Version: 1.11.2.rel-1
Severity: grave
Tags: security upstream confirmed fixed-upstream
Leafnode 1.11.2 contains a denial of service bug, fixed in subsequent
versions. Find below the full security announcement.
Please fix. Thank you, -- Matthias
---
leafnode-SA-2005:02.fetchnews-hangs-on-header
Topic: potential denial of service in leafnode
Announcement: leafnode-SA-2005:02
Author: Matthias Andree
Version:1.00
Announced: 2005-06-08
Category: main
Type: potential denial of service
Impact: fetchnews hangs, no new fetchnews/texpire processes
can be started
Credits:Adam Funk (bug report)
Danger: medium:
- no build-up of memory consumption
- no privilege escalation through this bug
- malicious upstream server can be unlisted
CVE Name: CVE-2005-1911
URL:http://leafnode.sourceforge.net/leafnode-SA-2005-02.txt
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-1911
Affects:leafnode versions up to and including 1.11.2
Not affected: leafnode 1.11.3
Default install: affected.
Corrected: 2005-06-08 14:06 UTC (CVS) - committed corrected version
2005-06-08 leafnode 1.11.3 released
0. Release history
2005-06-08 1.00 initial announcement
1. Background
leafnode is a store-and-forward proxy for Usenet news, is uses the
network news transfer protocol (NNTP). It consists of several
collaborating programs, the server part is usually started by inetd,
xinetd or tcpserver, the client part is usually started by cron,
a PPP post-connect script or manually.
This security announceme
Bug#339105: needs to Replace: ia32-libs
On Mon, Nov 14, 2005 at 02:46:23PM -0800, Joshua Kwan wrote: > lib32z1 should Replace: ia32-libs. I'm still waiting for someone to give me a version number for the ia32-libs release which removes libz. -- "You grabbed my hand and we fell into it, like a daydream - or a fever." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#339409: typo in lib64z1-dev dependency
On Wed, Nov 16, 2005 at 04:43:40AM +0100, Matthias Klose wrote: > s/lib64c-dev/lib64c6-dev/ The version of glibc in unstable seems to disagree with that one (not that it matters too much given your subsequent message). -- "You grabbed my hand and we fell into it, like a daydream - or a fever." signature.asc Description: Digital signature
Bug#339409: typo in lib64z1-dev dependency
On Wed, Nov 16, 2005 at 04:43:40AM +0100, Matthias Klose wrote: > Package: lib64z1-dev > Severity: serious > Version: 1:1.2.3-6 > s/lib64c-dev/lib64c6-dev/ Could you clarify what the problem you're reporting here is, please? As far as I can tell the current packages are installable with just the lib64c-dev dependency: | $ sudo apt-get install lib64z1-dev | Reading package lists... Done | Building dependency tree... Done | The following extra packages will be installed: | libc6-dev-ppc64 | The following NEW packages will be installed: | lib64z1-dev libc6-dev-ppc64 | 0 upgraded, 2 newly installed, 0 to remove and 1 not upgraded. | Need to get 59.4kB/2049kB of archives. | After unpacking 7758kB of additional disk space will be used. | Do you want to continue [Y/n]? and glibc does have the packages provide lib64c-dev (I have 2.3.5-8 here). -- "You grabbed my hand and we fell into it, like a daydream - or a fever." signature.asc Description: Digital signature
Bug#339409: acknowledged by developer (Re: Bug#339409: typo in lib64z1-dev dependency)
On Sat, Nov 19, 2005 at 03:20:20PM +, Stephen Gran wrote: > If there were more than one package per architecture providing this > virtual package, then the dependency would need to be adjusted to > provide consistent behavior. But at first blush, we don't seem to be > there. Yes, that's pretty much it - the real package is only needed to avoid tools like apt getting upset if they have to make a decision about what to install. If there is only one possible option this doesn't apply (which is why you can use Provides: when renaming a package). -- "You grabbed my hand and we fell into it, like a daydream - or a fever." signature.asc Description: Digital signature
Bug#345015: smstools: Please rebuild against new libmm
Package: smstools Version: 1.16-1 Severity: serious A new libmm has been uploaded with a new soname (libmm14) so smstools needs to be rebuilt against it - at present it is uninstallable. I can prepare an NMU doing this if you like. Sorry about the lack of coordination on this one - I was rushing due to Christmas when I did the upload. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: powerpc (ppc) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.14-2-powerpc Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#346885: usbview: FTBFS: build-depends on removed xlibs-dev
On Mon, Jan 09, 2006 at 02:38:11AM +0100, Adeodato Simó wrote: > To fix this bug, you need to update your build-dependencies and > substitute xlibs-dev for the list of individual X development > libraries that your package needs to be built. You can find detailed > information about how to do that in the DependsXlibsDev wiki page [2]. I think you mean that the other way round, no? -- "You grabbed my hand and we fell into it, like a daydream - or a fever." signature.asc Description: Digital signature
Bug#346885: usbview: FTBFS: build-depends on removed xlibs-dev
On Mon, Jan 09, 2006 at 08:43:01PM +0100, Adeodato Simó wrote: > The other way round? Certainly not, xlibs-dev does not exist anymore. > Is "substitute xlibs-dev for the list of individual ..." unproper > English to indicat ethat xlibs-dev is to disappear from Build-Depends? I parse it as meaning precisely the opposite of what you intend: "Replace the list with xlibs-dev" (basically reading "in place of" for for). The rest of your mail makes it fairly clear what you meant, I just wanted to double check. (An upload will be hitting incoming shortly, BTW.) -- "You grabbed my hand and we fell into it, like a daydream - or a fever." signature.asc Description: Digital signature
Bug#347545: login crashes when trying to use nis
reassign 347545 glibc thanks On Wed, Jan 11, 2006 at 01:57:27PM +0100, Edward Welbourne wrote: > When root tried to su - eddy it got this response on stderr: > -su: nss_nis/nis-netgrp.c:79: _nss_nis_setnetgrent: Assertion > `malloc_usable_size (netgrp->data) >= len + 1' failed. This is a problem with an NSS module which is part of glibc rather than with the NIS package. On client systems the NIS package just maintains the binding to the server and provides utility programs like ypcat. No code from the package actually runs in a process doing database lookups or authentication through the glibc APIs. Reassigning the bug to glibc which provides the NSS module. I'll try to address the other issues you have raised here but there's quite a few of them. If you would like any of these issues addressing further please file appropriate low severity bugs against the NIS package. I'd especially welcome improvements to the documentation. > The debconf info (which used to contain the nis/domain datum discussed > above) says nis is "not yet configured". Since I've uninstalled nis Actually, no, it doesn't say that. It reports that there is a Debconf note called nis/not-yet-configured - there will always be some reference to that note in the template generated by reportbug for NIS (the presence or absence of a '*' indicates if it's been shown or not). > and re-installed it recently, I can only suppose this is due to the > installation scripts not configuring nis. Getting to the point above > had involved a great deal of guess-work, reading of man pages, > stumbling by chance on relevant files and filling those with data by > trial and error. Nothing made itself even remotely obvious as a "how > to tell nis to configure itself", even in the course of all that > rummaging. Given the above I'm guessing that this is based on your understanding of what the Debconf information displayed by reportbug means. I would therefore expect that you had in fact already configured NIS fully and that the reason you were unable to find any documentation on what you were missing was that you weren't missing anything. > Running dpkg-reconfigure, I get consulted for the > nis/domain value; it already knows the value I had configured it to by > hand; and I think this was run when I re-installed nis. Yes, NIS will prompt for that when installed. Each time it is configured it will also take any value configured on the system and use it to seed the Debconf question. > (The prompt > for this is, fundamentally, unhelpful: only when I'd got it wrong, and > rummaged a lot as above, did I discover a passing comment, probably in > a man page: from which I realized that it isn't a domain name in the > normal sense; and gleaned that the datum is stored in Right, unfortunately someone decided to use the same term for the two concepts. Fortunately most installations I've encountered use the same value for both DNS and NIS domains so it's actually not frequently a problem in practice. > It would be worth saying "look in your NIS server's > /etc/defaultdomain for the authoritative version of this variable" or > some such.) Saying things like that gets a bit tricky: for example the user may not have sufficient access to their NIS server to be able to go and look at files like that or their NIS server may use some completely different configuration mechanism. I can't off-hand think of much to do with that prompt beyond reinforcing the idea that you should consult whoever is admining the network about the value if you're not picking the name on the server yourself. I'll see if I can come up with something better next time I upload. > I didn't get consulted for the ypserver's IP address, nor The default installation relies on broadcasting to discover a suitable server; in most situations that will work fine. I'm not going to add support for configuring this without also providing support for adding compat entries to passwd and whatnot since it's not already supported and it's something that relatively few users will need. > was I asked whether I wanted to enable nis in passwd and group. The package doesn't do that automatically because editing /etc/passwd and /etc/group during configuration is rather nasty and is not supported by base-passwd which is what manages those files. There is a bug open against base-passwd (#311531) requesting support for adding NIS entries but, well, it's open. Doing this is much more tricky than it might at first appear since the package has to deal with combinations of install, upgrade, removal and configuration operations along with user changes to the system (which we have to respect above anything else). Other distributions that I've seen deal with this do so by having a separate program that manages all authentication and system database related stuff through a unified interface rather than by
Bug#328069: oprofile-common: Conflicts with old oprofile
Package: oprofile Version: 0.9.1-3 Severity: serious Both oprofile-common and oprofile-gui conflict with older versions of the oprofile package: Unpacking oprofile-common (from .../oprofile-common_0.9.1-3_powerpc.deb) ... dpkg: error processing /var/cache/apt/archives/oprofile-common_0.9.1-3_powerpc.deb (--unpack): trying to overwrite `/usr/bin/opannotate', which is also in package oprofile dpkg-deb: subprocess paste killed by signal (Broken pipe) Selecting previously deselected package oprofile-gui. Unpacking oprofile-gui (from .../oprofile-gui_0.9.1-3_powerpc.deb) ... dpkg: error processing /var/cache/apt/archives/oprofile-gui_0.9.1-3_powerpc.deb (--unpack): trying to overwrite `/usr/bin/oprof_start', which is also in package oprofile dpkg-deb: subprocess paste killed by signal (Broken pipe) They should probably conflict with and replace these old versions. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: powerpc (ppc) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.11-powerpc Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#302684: zeroconf configuration method / option?
On Sun, Apr 03, 2005 at 05:21:41PM +0200, Thomas Hood wrote: > For the time being I think that the cleanest thing to do is to add a > zeroconf method to the inet and inet6 address families. Initially the Note that zeroconf should not be used with IPv6 - that includes its own link local allocation mechanism that's not such a bolt-on and is handled by the kernel. -- "You grabbed my hand and we fell into it, like a daydream - or a fever." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#302684: zeroconf configuration method / option?
On Wed, Apr 06, 2005 at 07:08:18PM +1000, Anand Kumria wrote: > Yes - totally agreed, it is a bug that zeroconf currently wil attempt to > assign an IPv4 link-local address to an interface with an address family > of 'inet6'. That's not buggy: an interface can quite happily run multiple protocols simultaneously. Indeed, when the IPv6 kernel module is installed it will go ahead and do automatic address assignment on all network interfaces it can (IPv6 address assignment is rather different to IPv4 so this is can sensibly be done by the kernel - there's no policy in having an ethernet link local address, for example). -- "You grabbed my hand and we fell into it, like a daydream - or a fever." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#302684: zeroconf configuration method / option?
On Wed, Apr 06, 2005 at 07:06:21PM +1000, Anand Kumria wrote: > On Sun, Apr 03, 2005 at 03:28:24PM +0100, Mark Brown wrote: > > It would be helpful if the program were to monitor the configuration of > > the interface and only bring up a zeroconf address in the absence of any > > other configuration (though if it were to do this it ought to look out > It is explicitly okay to have an interface with both a IPv4 routable > address and an IPv4 link-local It is possible but this behaviour is discouraged: the main reason for doing it is when failing over from a zeroconf address to an allocated one (for example, when a DHCP server becomes avaliable). I do believe the RFC recommends this behaviour and it's mostly how the Apple and Microsoft implementations appear to behave (see the appendix in the RFC). Because of this I do feel allocating an address when another is present ought to be at most optional behaviour. Allocating a route without an address is more useful since it allows communication with zeroconfed devices even when the system is explicitly configured (for example, statically) so I can see that usefully being done separately. Perhaps as another option, perhaps non-optionally. > If you know of any way I can programatically determine whether a > specific interface will use ARP to do hardware <-> IP address > resoultion, I'm certainly interested. You can determine the link type of the interface from the kernel (it is displayed as link/ether or whatever by 'ip link') and select specific interface types you know do ARP. That's not 100% ideal but it does appear from a brief glance to be what the kernel is doing internally so if it's good enough for the kernel I'd say it's good enough for zeroconf too :) . -- "You grabbed my hand and we fell into it, like a daydream - or a fever." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#302684: zeroconf configuration method / option?
") Fcc: +sent-mail On Thu, Apr 07, 2005 at 12:59:19PM +1000, Anand Kumria wrote: > On Wed, Apr 06, 2005 at 10:35:36AM +0100, Mark Brown wrote: > > That's not buggy: > Yes it is, if this only existed in /etc/network/interfaces > iface eth0 inet6 static Oh, you're thinking of the Debian configuration done by the package - I was thinking about the program itself. > That is it a bug if an an IPv4 link local address appears on the eth0 > interface. If there were also a line like: > iface eth0 inet static > *then* an IPv4 link local address should be assigned. Yes - there is an argument for supplying a link local address anyway (by analogy with IPv6) but it's very dodgy. > > interfaces it can (IPv6 address assignment is rather different to IPv4 > > so this is can sensibly be done by the kernel - there's no policy in > > having an ethernet link local address, for example). > Actually the defense mechanism isn't so different -- just the allocation > method. I've been thinking about factoring the link-local defense state > machine out of the IPv6 layer in the kernel and then using it for any > addresses marked as IPv4 link-local. Does it actually use the defense mechanisms for link local addresses allocated on the basis of hardware address (which was the set I was thinking of as most different - as you say the zeroconf algorithm owes something to the way autoconfigured routeable addresses are assigned)? Not that it really matters for this. -- "You grabbed my hand and we fell into it, like a daydream - or a fever." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#302684: zeroconf configuration method / option?
On Thu, Apr 07, 2005 at 01:55:51PM +1000, Anand Kumria wrote: [Disabling zeroconf when an address is allocated otherwise.] > Actually I read it entirely the other way -- the RFC recommends > *against* doing it the way that has been done on these platforms. The behaviour it's complaining about is the way that most (if not all, can't remember) existing implementations will immediately deconfigure the link local address if they get another address, ignoring the disruption this causes to existing network use. Section 1.9 says: | For these reasons, a host SHOULD NOT have both an operable routable | address and an IPv4 Link-Local address configured on the same interface. and then goes goes on to discuss procedures for phasing out the link local address, including a MUST requirement to stop advertising it. Failing over the other way (from asigned to link local) is optional behaviour, though. -- "You grabbed my hand and we fell into it, like a daydream - or a fever." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#286758: kernel-image-2.6.9-powerpc: Same openpic hang on PowerBook
On Tue, Mar 01, 2005 at 04:08:32PM +0800, Martin Michlmayr wrote: > 2.6.9 has been removed from the archive. Can you please test the > 2.6.10 kernel from the archive to see whether this issue is still > there? Also, can you confirm that you've never seen this with 2.6.8 > (which is the kernel we'll release with sarge). I'm running 2.6.10 and haven't seen the problem yet (it was intermittent). I don't recall seeing it in 2.6.8. -- "You grabbed my hand and we fell into it, like a daydream - or a fever." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#308877: smlnj: Build relies on network connection
Package: smlnj Version: 110.52-1 Severity: serious Justification: fails to build from source The smlnj package build attempts to download files from a web site during the build. Aside from being a policy violation, this means that the package cannot be built on machines disconnected from the internet and will become unbuildable should upstream stop distributing the relevant files. | /home/broonie/src/packages/smlnj/boots/smlnj-110.52/config/unpack: Fetching bootfiles from http://smlnj.cs.uchicago.edu/dist/working/110.52/. Please stand by... | /home/broonie/src/packages/smlnj/boots/smlnj-110.52/config/unpack: Fetching 110.52-boot.ppc-unix.tar.bz2 was no success. |You should try to do it manually now. | /home/broonie/src/packages/smlnj/boots/smlnj-110.52/config/unpack: Please, fetch bootfiles archive | (boot.ppc-unix.* or 110.52-boot.ppc-unix.*) | from http://smlnj.cs.uchicago.edu/dist/working/110.52/ | and then re-run this script! One possible solution would be for these files to be downloaded and included in the source package. -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: powerpc (ppc) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.11-powerpc Locale: LANG=en_GB, LC_CTYPE=en_GB (charmap=ISO-8859-1) -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#308877: smlnj: Build relies on network connection
On Thu, May 12, 2005 at 05:07:59PM -0600, aaron wrote: > The actual package build doesn't require any downloads. The binary > needed to compile is contained in the binary package. I believe > the cmucl package uses the same technique, although I could be mistaken. In that case you really ought to separate out the bootstrapping build from the regular build rather than silently starting a download as part of the main build process. Had I had to do something like invoke 'debian/rules bootstrap' to cause this to happen I probably wouldn't have filed a bug. Having looked at the build process it appears that this wouldn't be a major adjustment to the package. > Blah, i dont agree that this a policy violation, but I'll do it anyway. It is certainly a policy violation for the package to require files to be downloaded during the build. I'd argue that having that download happen in the main flow is at best error prone since it increases the chances that someone will end up doing this by mistake. -- "You grabbed my hand and we fell into it, like a daydream - or a fever." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#317473: zlib_1:2.2.2-7 (sparc/unstable): FTBFS: cannot find -lgcc_s for 64-bit build
reassign 317473 gcc-4.0 thanks On Fri, Jul 08, 2005 at 03:17:52PM -0700, Steve Langasek wrote: > These problems began following packaging changes intended to support > biarch on amd64; perhaps something went wrong with that change? It > could also be caused by recent toolchain updates, though; it looks like As far as I can tell the problem is in the toolchain. Nothing changed with regard to how the 64 bit compilers were built compared to -4 (the commands being issued look to be the same) and I appear to be unable to get a biarch build of a simple hello world program to build with the compilers I found to try: gcc-4.0 -m64 hello.c also complains about not being able to find libgcc. -- "You grabbed my hand and we fell into it, like a daydream - or a fever." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#317473: zlib_1:2.2.2-7 (sparc/unstable): FTBFS: cannot find -lgcc_s for 64-bit build
On Sat, Jul 09, 2005 at 12:33:04AM +0100, Mark Brown wrote: > get a biarch build of a simple hello world program to build with the > compilers I found to try: > gcc-4.0 -m64 hello.c > also complains about not being able to find libgcc. Forgot to mention: I also see equivalent trouble with trying to do 32 bit builds on amd64. -- "You grabbed my hand and we fell into it, like a daydream - or a fever." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#317655: zeroconf: Crucifies the network
Package: zeroconf Version: 0.3-1 Severity: critical It appears that zeroconf can get itself into a state where it continually loops, issuing ARP requests for IP addresses which other computers already have assigned. Looking at the code there appears to be no attempt to restrict the number of addresses tried and unless I misread the code the default interval between probes is rather low. Ideally zeroconf should either give up or back up if it encounters a large number of conflicts in order to avoid DoSing the network. The RFC recommends a limit, IIRC. Filed with raised severity since this can cause serious disruption to the network when it happens. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: powerpc (ppc) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.11-powerpc Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Versions of packages zeroconf depends on: ii ifupdown0.6.7high level tools to configure netw ii iproute 20041019-3 Professional tools to control the ii libc6 2.3.2.ds1-22 GNU C Library: Shared libraries an zeroconf recommends no packages. -- "You grabbed my hand and we fell into it, like a daydream - or a fever." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#317655: acknowledged by developer (Bug#317655: fixed in zeroconf 0.6-1)
On Tue, Jul 12, 2005 at 04:18:24PM -0700, Debian Bug Tracking System wrote: >* Don't crucify Mark's network with lots of ARP packets (Closes: #317655) > -- thus the ugency. Great, thanks! That was actually the debconf network which inspired me to report the problem (though I had seen it before and not investigated fully enough to report the issue). -- "You grabbed my hand and we fell into it, like a daydream - or a fever." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#318292: zlib1g: ICE on m68k
Package: zlib1g Version: 1:1.2.2-8 Severity: serious Justification: no longer builds from source GCC ICEs building deflate.c. There's a preexisting bug #317475 which may well be the same issue (also -O3, ICE). Filing this so I remember to check into this and file a bug on GCC. | gcc -O3 -g -D_REENTRANT -fPIC -DUSE_MMAP -DHAS_snprintf -DHAS_vsnprintf -c -o deflate.o deflate.c | deflate.c: In function 'deflate_fast': | deflate.c:1373: internal compiler error: Segmentation fault | Please submit a full bug report, | with preprocessed source if appropriate. | See http://gcc.gnu.org/bugs.html> for instructions. | For Debian GNU/Linux specific bug reporting instructions, see . | make[1]: *** [deflate.o] Error 1 | make[1]: Leaving directory `/build/buildd/zlib-1.2.2/build-tree/zlib-1.2.2' | make: *** [debian/stampdir/build] Error 2 -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: powerpc (ppc) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.11-powerpc Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Versions of packages zlib1g depends on: ii libc6 2.3.2.ds1-22 GNU C Library: Shared libraries an zlib1g recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#286758: kernel-image-2.6.9-powerpc: Same openpic hang on PowerBook
Package: kernel-image-2.6.9-powerpc Version: 2.6.9-4 Followup-For: Bug #286758 I'm seeing the same hang on my PowerBook. I'm pretty sure I had seen the same with -3, but only when the machine was running on battery (I hadn't written up a bug report since I wanted to confirm the failure mode). processor : 0 cpu : 7447A, altivec supported clock : 1499MHz revision: 1.1 (pvr 8003 0101) bogomips: 1495.04 machine : PowerBook5,4 motherboard : PowerBook5,4 MacRISC3 Power Macintosh detected as : 287 (PowerBook G4 15") pmac flags : 000a L2 cache: 512K unified memory : 512MB pmac-generation : NewWorld -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable') Architecture: powerpc (ppc) Kernel: Linux 2.6.8-powerpc Locale: LANG=en_GB, LC_CTYPE=en_GB (charmap=ISO-8859-1) Versions of packages kernel-image-2.6.9-powerpc depends on: ii initrd-tools 0.1.76 tools to create initrd image for p ii module-init-tools 3.1-rel-2 tools for managing Linux kernel mo -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#288180: nis kills sparc64
reassign 288180 kernel-image-2.6.8-2-sparc64-smp thanks This bug report appears to be a kernel issue: no matter how messed up NIS gets it shouldn't be capable of causing this kind of damage. On Sun, Jan 02, 2005 at 09:57:26AM +, Beezly wrote: > Package: nis > Version: 3.12-3 > Severity: critical > > Installing the nis package on my E4500 kills the machine. It seems to > stop the machine creating new processes althought it's difficult for me > to tell as I have limited physical access to the machine. > > Doing apt-get install nis produces the following... > > gold:/usr/sbin# apt-get install nis > Reading Package Lists... Done > Building Dependency Tree... Done > The following NEW packages will be installed: > nis > 0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded. > Need to get 235kB of archives. > After unpacking 844kB of additional disk space will be used. > Get:1 http://mirrors.shef.ac.uk testing/main nis 3.12-3 [235kB] > Fetched 235kB in 4s (53.7kB/s) > Preconfiguring packages ... > Selecting previously deselected package nis. > (Reading database ... 29539 files and directories currently installed.) > Unpacking nis (from .../archives/nis_3.12-3_sparc.deb) ... > Setting up nis (3.12-3) ... > Setting NIS domainname to: beezly.org.uk > Starting NIS services: ypbind > > The machine becomes inaccessible after loading ypbind and you cannot > interrupt the terminal, however it IS still possible to ping the > machine. ssh to the machine gets as far as opening a connection, but no > further. > > Marked critical as it flattens my machine, every application and makes > it unusable. > > Anything you want me to try out, please let me know although it can take > me a while to get back to you... I have to drive over two hills to get > to the machine! > > Cheers, > > Andrew > > > -- "You grabbed my hand and we fell into it, like a daydream - or a fever." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#456855: Processed: latest scons will cause skim FTBFS
On Mon, Feb 04, 2008 at 03:42:02PM +, Debian Bug Tracking System wrote: > Processing commands for [EMAIL PROTECTED]: > > reassign #456855 scons 0.97.0d20071212-3 > Bug#456855: skim: FTBFS: TypeError: coercing to Unicode: need string or > buffer, list found I've taken a bit of a look at the skim package and I note that rather than using SCons directly it is in fact using an old version of bksys[1] from the days when it was a layer on top of SCons. I strongly recommend updating to use some other system (such as a current version of bksys). I've seen a number of versions of the SCons wrappers of various ages with varying degrees of brokeness. Since the code is abandoned by its authors upstream should only continue using it if they are willing to support and maintian it themselves. In this case it appears that the *immediate* problem is seen as a problem by SCons upstream (though it did only ever work by accident). It can be avoided by changing the SConscripts to pass in only single files or paths. As I said in my previous e-mail in future when reassigning bugs you should also send an explanatory e-mail to the maintainer of the package you are reassigning to detailing the analysis you have done to determine that there is a problem. Not doing this is unhelpful, especially when (as in this case) there is also no analysis in the bug log. [1] http://code.google.com/p/waf/ [2] http://www.nabble.com/differences-in-Chmod-behavior-between-0.97-and-current-dev-code-td14700437.html -- "You grabbed my hand and we fell into it, like a daydream - or a fever." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#429858: usbview: no text displayed on buttons
severity 429858 normal tag 429858 + unreproducible moreinfo thanks On Wed, Jun 20, 2007 at 11:30:13PM +0530, [EMAIL PROTECTED] wrote: > Package: usbview > Version: 1.0-7 > Severity: grave Please file bugs with realistic severities. > In the bottom are 4 buttons. No text is displayed on them. If I press the > last button (right most), it exists. Without the text on the buttons, the > package is mostly unusable. I'm not sure quite what you're expecting the program to do. Even if this problem were present the impact on the program is minimal - the primary functionality of the program is the device tree and you report that it is displayed. With the exception of the about button they are basically redundant. As it is I can't reproduce this problem. Please provide information about the system that you are running the program on such as that generated by reportbug - for example, by using reportbug to generate a followup for this report. -- "You grabbed my hand and we fell into it, like a daydream - or a fever." signature.asc Description: Digital signature
Bug#429858: usbview: no text displayed on buttons
On Wed, Jun 20, 2007 at 09:03:43PM +0100, Mark Brown wrote: > As it is I can't reproduce this problem. Please provide information > about the system that you are running the program on such as that > generated by reportbug - for example, by using reportbug to generate a > followup for this report. Gah, sorry - it's in your original report. -- "You grabbed my hand and we fell into it, like a daydream - or a fever." signature.asc Description: Digital signature
Bug#428323: libgempc430: Causes pcscd to segfault on startup
On Mon, Jun 11, 2007 at 04:07:28PM +0200, [EMAIL PROTECTED] wrote: > frame #0 is corrupted so not very helpful :-( > I don't really know what to suggest next. You can try to execute the function > OpenGemPC430ByName() from GemPC430/GemPC430Utils.c step by step. I've got a horrible feeling that this is a compiler bug. Apart from anything else, compiling with -fstack-protector-all, -O1 or -O0 (independently of each other) allows things to start up quite happily. I'm not sure how much longer I'll have access to the card reader to investigate this. -- "You grabbed my hand and we fell into it, like a daydream - or a fever." signature.asc Description: Digital signature
Bug#428323: libgempc430: Causes pcscd to segfault on startup
On Sat, Jun 23, 2007 at 10:07:18PM +0200, Ludovic Rousseau wrote: > Can you give me the package versions of your build tools so I can try to > reproduce the bug on my PowerPC machine? It's sid as of today. I can dig out the actual versions tomorrow hopefully. -- "You grabbed my hand and we fell into it, like a daydream - or a fever." signature.asc Description: Digital signature
Bug#428323: libgempc430: Causes pcscd to segfault on startup
On Sat, Jun 23, 2007 at 10:07:18PM +0200, Ludovic Rousseau wrote: > Can you give me the package versions of your build tools so I can try to > reproduce the bug on my PowerPC machine? ii binutils 2.17cvs2007042 The GNU assembler, linker and binary utiliti ii gcc-4.14.1.2-12 The GNU C compiler ii libc6-dev 2.5-11 GNU C Library: Development Libraries and Hea -- "You grabbed my hand and we fell into it, like a daydream - or a fever." signature.asc Description: Digital signature
Bug#431873: udeb is missing in .shlibs
tag 431873 - patch thanks On Thu, Jul 05, 2007 at 06:49:51PM +0200, Jérémy Bobbio wrote: > The attached patch should fix this issue. Only for the d-i case, unfortunately. The cross library packages also have the same problem and it looks like they can't be fixed without doing the shlibs by hand. Expect a fix tomorrow evening. -- "You grabbed my hand and we fell into it, like a daydream - or a fever." signature.asc Description: Digital signature
Bug#431873: udeb is missing in .shlibs
On Thu, Jul 05, 2007 at 06:49:51PM +0200, Jérémy Bobbio wrote: > It seems that in fixing #431124, you have removed the .shlibs entry > mentioning zlib1g-udeb. This currently breaks the debian-installer > builds as udeb depending on zlib1g doesn't reference the correct package > anymore. That's not from #431124, it's from converting to use debhelper which isn't quite as helpful as I'd like about shared libraries. -- "You grabbed my hand and we fell into it, like a daydream - or a fever." signature.asc Description: Digital signature
Bug#432491: missing conflict with lib32z1
On Tue, Jul 10, 2007 at 11:02:38AM +0200, martin f krafft wrote: > updated. The bad version still lives in lenny though, so I wonder > what will happen if libc6 migrates to lenny before lib32z1. Also, on That at least is unlikely - the only thing holding zlib out of testing is glibc and manual approval for the udeb (which both need) so it's most likely that they'll go in together. -- "You grabbed my hand and we fell into it, like a daydream - or a fever." signature.asc Description: Digital signature
Bug#431408: Fix build with current kernels
The build of mol with current kernels appears to be fixed by simply removing the inclusion of linux/compiler.h. -- "You grabbed my hand and we fell into it, like a daydream - or a fever." signature.asc Description: Digital signature
Bug#432262: libc6-i386 is uninstallable
notfound 432262 1:1.2.3.3.dfsg-5 thanks On Wed, Aug 01, 2007 at 10:19:37PM +0200, Kurt Roeckx wrote: > This problem isn't really fixed yet. Since you have a: > Depends: libc6-i386 (>= 2.6-1) > It will upgrade libc6-i386 before lib32z1, and you'll get the problem. > You should make sure that lib32z1 gets upgraded before libc6-i386. I really don't think this is terribly important to deal with. This problem only affects users who were running testing or unstable (both of which are development distributions) while the affected package was present. I'd imagine that a very large proportion of the affected users have already upgraded so won't benefit from any fix. For other users blogging the upgrade path (or posting to -amd64) so that it shows up in Google would probably be enough. I also can't immediately think how to avoid the problem, though I must confess that given the above I haven't tried terribly hard. Obviously, the dependency is generated by dpkg-shlibdeps and I'm not inclined to ignore it on this nor can I see any way of forcing the upgrade that works with that dependency. That said, if you come up with a suggestion for helping people upgrade (or I have any bright ideas, for that matter) then I'd certainly consider implementing it. If you do then please file it as a separate wishlist bug - the handling of the upgrade from the systems with the broken versions installed is a separate issue to the original breakage and much less severe since it doesn't affect stable users. -- "You grabbed my hand and we fell into it, like a daydream - or a fever." signature.asc Description: Digital signature
Bug#432262: libc6-i386 is uninstallable
close 432262 thanks On Wed, Aug 01, 2007 at 11:39:55PM +0200, Kurt Roeckx wrote: > On Wed, Aug 01, 2007 at 10:33:07PM +0100, Mark Brown wrote: > > notfound 432262 1:1.2.3.3.dfsg-5 > > thanks > You probably also want to "close" it with that version again, if you > think it should be closed. Bah, humbug. So I do - thanks. > > That said, if you come up with a suggestion for helping people upgrade > > (or I have any bright ideas, for that matter) then I'd certainly > I can't remember the exact behaviour of a Conflict, but I > think you can use that. Hrm. Possibly. I'll have a look. -- "You grabbed my hand and we fell into it, like a daydream - or a fever." signature.asc Description: Digital signature
Bug#423350: RM: open21xx -- RoQA; orphaned, RC-buggy
On Mon, Aug 13, 2007 at 01:43:04PM +0200, Matej Vela wrote: > It seems we have a solution for the RC bug and some interest in > keeping open21xx, so I'll let it be for a while. If (as it seems) the package had never built on any of the affected architectures then the bug shouldn't have been RC anyway... -- "You grabbed my hand and we fell into it, like a daydream - or a fever." signature.asc Description: Digital signature
Bug#439967: [xml/sgml-pkgs] Bug#439967: libxml2: gzopen64() implicitly converted to pointer
On Tue, Aug 28, 2007 at 10:32:10PM +0200, Mike Hommey wrote: > So, actually, this is an issue with zlib.h diverting gzopen and friends > to *64 calls when _FILE_OFFSET_BITS is 64, but doesn't define the > function prototypes unless _LARGEFILE64_SOURCE is also defined. As discussed on IRC if this is urgent I recommend working around it by defining _LARGEFILE64_SOURCE along with _FILE_OFFSET_BITS. I'd rather consult with upstream before fixing this which can sometimes take a while. Please let me know if this is going to be a problem. -- "You grabbed my hand and we fell into it, like a daydream - or a fever." signature.asc Description: Digital signature
Bug#444204: scons: version 0.97.0d20070918-1 fails to clean csound 5.06 but 0.97.0d20070809-1 doesn't
On Wed, Nov 21, 2007 at 10:08:09PM -0300, Felipe Sateler wrote: > Any schedule on when this fix will be included in debian? This is preventing > a > security fix on ardour [1]. Note that there is no explicit mention in the bug > log but there was some talk at debian-multimedia about it (scons fails while > checking for pkgconfig). According to schedule upstream should have released a fix for this about a month ago. However, they are currently working on fixing another bug (and have been since the time they fixed this one). I'll hassle them again and consider packaging a snapshot of my own for Debian. -- "You grabbed my hand and we fell into it, like a daydream - or a fever." signature.asc Description: Digital signature
Bug#456644: edac-utils: Patch fixing this
Package: edac-utils Version: 0.10-1 Followup-For: Bug #456644 The problem is with the check for verbosity - the logical expression it is part of is is the last statement executed by the script and so the return code from that becomes the return code of the init script. If the check for verbosity fails (as it will by default) then this will mean that the exit value for the entire script will be an error. The most obvious change to fix the check appears to be removing it entirely - the init script does not check for verbosity anywhere else and has already produced some output by the time it does this check so it would be an error to not terminate anyway: --- /etc/init.d/edac.orig 2008-01-02 11:09:48.0 + +++ /etc/init.d/edac2008-01-02 11:11:39.0 + @@ -48,7 +48,7 @@ $EDAC --register-labels 1>/dev/null 2>&1 rc=$? case $rc in -0) [ "$VERBOSE" != no ] && log_end_msg 0 ;; +0) log_end_msg 0 ;; 5) log_failure_msg ": No EDAC support for this hardware"; log_end_msg 1 ;; *) log_failure_msg ": Unknown return code $rc. Please file a bug report"; log_end_msg 1;; esac -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#458849: Triggered by replacement of SCons Install/InstallAs
This bug is triggered by the replacement of the SCons-supplied Install and InstallAs methods in lines 124 and 125 of platform/default/SConscript. SCons then gets terribly confused copying the envirionment. The aqsis package should be able to avoid this by defining new Install and InstallAs equivalents rather than overriding the default ones. Not using the DESTDIR support provided by upstream also avoids the issue since it does not replace the methods. I'm not sure if this usage is supposed to be supported upstream or not so I've not yet cloned this bug to SCons - I've asked SCons upstream. Ideally the SCons packaging branch would get merged and SCons would have native DESTDIR support so these hacks wouldn't be needed. -- "You grabbed my hand and we fell into it, like a daydream - or a fever." signature.asc Description: Digital signature
Bug#458849: [EMAIL PROTECTED]: [Issue 1884] Infinite loop in InstallAs]
Update from SCons upstream; personally I'd expect aqsis needs fixing here. -- "You grabbed my hand and we fell into it, like a daydream - or a fever." --- Begin Message --- http://scons.tigris.org/issues/show_bug.cgi?id=1884 --- Additional comments from [EMAIL PROTECTED] Sun Jan 13 21:38:29 -0800 2008 --- Wanted to ack this report. I pulled down a copy of aqsis and have isolated a test case from it. It's a kind of tricky combination of the following factors: -- Redefining the Install/InstallAs builders to wrap the original calls. --- End Message --- --- Begin Message --- http://scons.tigris.org/issues/show_bug.cgi?id=1884 User stevenknight changed the following: What|Old value |New value Status|NEW |STARTED --- Additional comments from [EMAIL PROTECTED] Sun Jan 13 21:47:00 -0800 2008 --- Gah--hit the wrong thing and submitted that previous comment too soon. As I was saying, it's a combination of several factors: -- Redefining the Install/InstallAs builders as wrappers that call the original methods, which are now ToolInitializer objects -- Have the redefined wrappers *not* actually use the "attached" environment, but instead use the "env" variable from the nested scope, which means it's actually still attached to the "wrong" environment -- Clone the environment *after* the Install/InstallAs wrappers have been called on the original environment, which changes them in the original environment -- Call Install/InstallAs on the cloned environment, which (because of the "env" variable in the nested scope) still ends up calling something that refers to the original environment I don't have a fix yet. This may require a change to the aqsis SConscript file, because this really only worked kind of by accident, and because the relevant construction variables in the two construction environments were the same. If the construction environments had different $DESTDIR values, for example, you would have probably seen things from the cloned environment still getting installed into the original environment's $DESTDIR. So the aqsis configuration is kind of wrong to begin with, but we should still at least handle the situation more gracefully, of course. I'll try to figure both the SCons fix for the infinite recursion and the aqsis SConscript file change (if any) and let you know. Warning: I'm going to be basically off-line from Wednesday until at least Saturday this week, so there's a chance that if I don't find the problem right away that it might wait until next week. --- End Message --- signature.asc Description: Digital signature
Bug#427185: zlib - FTBFS: cannot stat `build-tree/zlib-1.2.3/libz.so.1.2.3': No such file or directory
reassign 427185 gcc-4.1 found 427185 4.1.2-11 notfound 427185 1:1.2.3-15 retitle 427185 Warning output when linking 64 bit objects on i386 thanks The enclosed FTBFS in the 64 bit zlib on i386 appears to be a toolchain issue, though I may have assigned it to the wrong package. The issue is that linking a 64 bit ELF object (at least via GCC) appears to produce this warning unconditionally: > > /usr/bin/ld: error in > /usr/lib/gcc/i486-linux-gnu/4.1.3/64/crtend.o(.eh_frame); no .eh_frame_hdr > table will be created. (it says it is an error but the return code appears to be unaffected) which causes the zlib configure script to think that shared libraries cannot be built, causing a FTBFS. A full copy of the original report is enclosed: On Sat, Jun 02, 2007 at 01:34:05PM +0200, Michael Ablassmeier wrote: > Package: zlib > Version: 1:1.2.3-15 > Severity: serious > User: [EMAIL PROTECTED] > Usertags: qa-ftbfs > > hi, > > while doing an archive wide package rebuild your package failed to build from > source for the following reason: > > > gcc -m64 -O3 -g -D_REENTRANT -fPIC -DNO_vsnprintf -DUSE_MMAP > -DHAS_snprintf -DHAS_vsnprintf -c -o compress.o compress.c > > gcc -m64 -O3 -g -D_REENTRANT -fPIC -DNO_vsnprintf -DUSE_MMAP > -DHAS_snprintf -DHAS_vsnprintf -c -o crc32.o crc32.c > > gcc -m64 -O3 -g -D_REENTRANT -fPIC -DNO_vsnprintf -DUSE_MMAP > -DHAS_snprintf -DHAS_vsnprintf -c -o gzio.o gzio.c > > gcc -m64 -O3 -g -D_REENTRANT -fPIC -DNO_vsnprintf -DUSE_MMAP > -DHAS_snprintf -DHAS_vsnprintf -c -o uncompr.o uncompr.c > > gcc -m64 -O3 -g -D_REENTRANT -fPIC -DNO_vsnprintf -DUSE_MMAP > -DHAS_snprintf -DHAS_vsnprintf -c -o deflate.o deflate.c > > gcc -m64 -O3 -g -D_REENTRANT -fPIC -DNO_vsnprintf -DUSE_MMAP > -DHAS_snprintf -DHAS_vsnprintf -c -o trees.o trees.c > > gcc -m64 -O3 -g -D_REENTRANT -fPIC -DNO_vsnprintf -DUSE_MMAP > -DHAS_snprintf -DHAS_vsnprintf -c -o zutil.o zutil.c > > gcc -m64 -O3 -g -D_REENTRANT -fPIC -DNO_vsnprintf -DUSE_MMAP > -DHAS_snprintf -DHAS_vsnprintf -c -o inflate.o inflate.c > > gcc -m64 -O3 -g -D_REENTRANT -fPIC -DNO_vsnprintf -DUSE_MMAP > -DHAS_snprintf -DHAS_vsnprintf -c -o infback.o infback.c > > gcc -m64 -O3 -g -D_REENTRANT -fPIC -DNO_vsnprintf -DUSE_MMAP > -DHAS_snprintf -DHAS_vsnprintf -c -o inftrees.o inftrees.c > > gcc -m64 -O3 -g -D_REENTRANT -fPIC -DNO_vsnprintf -DUSE_MMAP > -DHAS_snprintf -DHAS_vsnprintf -c -o inffast.o inffast.c > > ar rc libz.a adler32.o compress.o crc32.o gzio.o uncompr.o deflate.o > trees.o zutil.o inflate.o infback.o inftrees.o inffast.o > > gcc -m64 -O3 -g -D_REENTRANT -fPIC -DNO_vsnprintf -DUSE_MMAP > -DHAS_snprintf -DHAS_vsnprintf -o example example.o -L. libz.a > > /usr/bin/ld: error in > /usr/lib/gcc/i486-linux-gnu/4.1.3/64/crtend.o(.eh_frame); no .eh_frame_hdr > table will be created. > > gcc -m64 -O3 -g -D_REENTRANT -fPIC -DNO_vsnprintf -DUSE_MMAP > -DHAS_snprintf -DHAS_vsnprintf -c -o minigzip.o minigzip.c > > gcc -m64 -O3 -g -D_REENTRANT -fPIC -DNO_vsnprintf -DUSE_MMAP > -DHAS_snprintf -DHAS_vsnprintf -o minigzip minigzip.o -L. libz.a > > /usr/bin/ld: error in > /usr/lib/gcc/i486-linux-gnu/4.1.3/64/crtend.o(.eh_frame); no .eh_frame_hdr > table will be created. > > make[1]: `libz.a' is up to date. > > make[1]: Leaving directory `/build/user/zlib-1.2.3/build-tree/zlib-1.2.3' > > touch debian/stampdir/build-64 > > install -m 644 -s build-tree/zlib-1.2.3/libz.so.1.2.3 > /build/user/zlib-1.2.3/debian/lib64z1/usr/lib64/libz.so.1.2.3 > > install: cannot stat `build-tree/zlib-1.2.3/libz.so.1.2.3': No such file > or directory > > make: *** [middle-binary-lib64z1] Error 1 > > The Full Build log is available and can be viewed at: > > http://people.debian.org/~lucas/logs/2007/06/01/ > > bye, > - michael > > -- "You grabbed my hand and we fell into it, like a daydream - or a fever." signature.asc Description: Digital signature
Bug#427185: zlib - FTBFS: cannot stat `build-tree/zlib-1.2.3/libz.so.1.2.3': No such file or directory
reassign 427185 gcc-4.1
thanks
On Sun, Jun 03, 2007 at 03:39:25PM +0200, Matthias Klose wrote:
> unreproducible; works for me in a current unstable environment.
I've just updated again to current unstable (only portmap and findutils
changed) and can still reproduce the problem:
| [EMAIL PROTECTED]:/tmp$ cat foo.c
| int main(void)
| {
| return 0;
| }
| [EMAIL PROTECTED]:/tmp$ gcc -m64 -o foo foo.c
| /usr/bin/ld: error in
/usr/lib/gcc/i486-linux-gnu/4.1.3/64/crtend.o(.eh_frame); no .eh_frame_hdr
table will be created.
| [EMAIL PROTECTED]:/tmp$ echo $?
| 0
and similarly if I compile to an object and link that. Reassigning back
to gcc-4.1 since it can be reproduced outside of the zlib build
environment - whatever is going on here doesn't appear to be related to
that package.
Perhaps we have somehow managed to get different versions of some
toolchain packages? I have:
ii binutils 2.17cvs2007042 The GNU assembler, linker and binary utiliti
ii binutils-multi 2.17cvs2007042 Binary utilities that support multi-arch tar
(these are both at 2.17cvs20070426-8.)
ii gcc-4.14.1.2-11 The GNU C compiler
ii gcc-4.1-multil 4.1.2-11 The GNU C compiler (multilib files)
ii gcc-multilib 4:4.1.2-2 The GNU C compiler (multilib files)
ii libc6-dev 2.5-9+b1 GNU C Library: Development Libraries and Hea
ii libc6-dev-amd6 2.5-9+b1 GNU C Library: 64bit Development Libraries f
ii libc6-i686 2.5-9+b1 GNU C Library: Shared libraries [i686 optimi
and apt currently claims that none of the packages on that system are
out of date. I don't know what the buildd that was used for the
original report had. Removing binutils-multiarch appears to have no
effect on the problem.
--
"You grabbed my hand and we fell into it, like a daydream - or a fever."
signature.asc
Description: Digital signature
Bug#428323: libgempc430: Causes pcscd to segfault on startup
Package: libgempc430 Version: 1.0.1-5 Severity: grave Justification: renders package unusable When a Gemplus smart card reader is connected and this package is installed libgempc430 segfaults on startup on my PowerPC based system: #0 0x0010 in ?? () #1 0x0fddeee8 in IFDHCreateChannelByName () from /usr/lib/pcsc/drivers/ifd-GemPC430.bundle/Contents/Linux/libGemPC430.so.1.0.1 #2 0x100077f0 in IFDOpenIFD (rContext=0x100b0008) at ifdwrapper.c:158 #3 0x1000a9fc in RFInitializeReader (rContext=0x0) at readerfactory.c:1147 #4 0x1000b3f8 in RFAddReader (lpcReader=0x100b6cf0 "GemPC430", dwPort=2097152, lpcLibrary=0x100b7a08 "/usr/lib/pcsc/drivers/ifd-GemPC430.bundle/Contents/Linux/libGemPC430.so.1.0.1", lpcDevice=0x30831b10 "usb:08e6/0430:libusb:002:003") at readerfactory.c:243 #5 0x10006a44 in HPAddHotPluggable (dev=0x100c6878, bus_device=0x30831c4c "002:003", driver=0x100bdfa0) at hotplug_libusb.c:498 #6 0x10006bd0 in HPRescanUsbBus () at hotplug_libusb.c:303 #7 0x10006da8 in HPEstablishUSBNotifications () at hotplug_libusb.c:391 #8 0x0ffcc7b4 in start_thread () from /lib/libpthread.so.0 #9 0x0fee29e4 in clone () from /lib/libc.so.6 ID of device: Bus 002 Device 003: ID 08e6:0430 Gemplus GemPC430 SmartCard Reader Please note that I've only got access to this device as a result of being at Debconf and may therefore be unable to reproduce in future. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: powerpc (ppc) Kernel: Linux 2.6.21-1-powerpc Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages libgempc430 depends on: ii libc6 2.5-10 GNU C Library: Shared libraries ii libusb-0.1-4 2:0.1.12-7 userspace USB programming library ii pcscd 1.4.2-1Middleware to access a smart card libgempc430 recommends no packages. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#428323: libgempc430: Causes pcscd to segfault on startup
On Mon, Jun 11, 2007 at 01:18:32PM +0200, [EMAIL PROTECTED] wrote: > Can you rebuild the libgempc430 package and install the driver directly so the > debug info is not stripped? Done that. Note that when doing this you need to patch the Makefiles to avoid stripping the binary. Console output: pcscdaemon.c:297:main() pcscd set to foreground with debug send to stderr debuglog.c:213:DebugLogSetLevel() debug level=debug pcscdaemon.c:500:main() pcsc-lite 1.4.2 daemon ready. [New Thread 813900992 (LWP 30547)] hotplug_libusb.c:454:HPAddHotPluggable() Adding USB device: 002:003 readerfactory.c:1113:RFInitializeReader() Attempting startup of GemPC430 00 00 using /usr/lib/pcsc/drivers/ifd-GemPC430.bundle/Contents/Linux/libGemPC430.so.1.0.1 readerfactory.c:980:RFBindFunctions() Loading IFD Handler 3.0 ifdhandler.c:51:IFDHCreateChannelByName() lun: 0, device: usb:08e6/0430:libusb:002:003 libusb_wrap.c:93:OpenUSB() Lun: 0, Device: usb:08e6/0430:libusb:002:003 libusb_wrap.c:183:OpenUSB() Trying to open USB device: 002/003 libusb_wrap.c:210:OpenUSB() Using USB device: 002/003 GCCmds.c:406:GCCmdSetMode() -> 00 03 01 00 01 <- 00 02 00 01 GCCmds.c:415 GCCmdSetMode (null) GCCmds.c:328:GCCmdGetOSVersion() -> 00 05 22 05 3F E0 10 <- 00 11 00 47 65 6D 55 73 62 2D 52 31 2E 30 34 2D 47 4D 20 GCCmds.c:340 GCCmdGetOSVersion (null) Program received signal SIGSEGV, Segmentation fault. Backtrace: #0 0x0010 in ?? () #1 0x0fdde2e8 in IFDHCreateChannelByName (Lun=0, lpcDevice=0x0) at ifdhandler.c:63 #2 0x100077f0 in IFDOpenIFD (rContext=0x100b0008) at ifdwrapper.c:158 #3 0x1000a9fc in RFInitializeReader (rContext=0x0) at readerfactory.c:1147 #4 0x1000b3f8 in RFAddReader (lpcReader=0x100b6cf0 "GemPC430", dwPort=2097152, lpcLibrary=0x100b7a08 "/usr/lib/pcsc/drivers/ifd-GemPC430.bundle/Contents/Linux/libGemPC430.so.1.0.1", lpcDevice=0x30831b10 "usb:08e6/0430:libusb:002:003") at readerfactory.c:243 #5 0x10006a44 in HPAddHotPluggable (dev=0x100c6878, bus_device=0x30831c4c "002:003", driver=0x100bdfa0) at hotplug_libusb.c:498 #6 0x10006bd0 in HPRescanUsbBus () at hotplug_libusb.c:303 #7 0x10006da8 in HPEstablishUSBNotifications () at hotplug_libusb.c:391 #8 0x0ffcc7b4 in start_thread () from /lib/libpthread.so.0 #9 0x0fee29e4 in clone () from /lib/libc.so.6 Looks rather like something trampled over the stack... I'll try to investigate further. -- "You grabbed my hand and we fell into it, like a daydream - or a fever." signature.asc Description: Digital signature
Bug#428323: libgempc430: Causes pcscd to segfault on startup
On Mon, Jun 11, 2007 at 04:07:28PM +0200, [EMAIL PROTECTED] wrote:
> But the program do not execute the line 53 of GemPC430/GemPC430Utils.c
>
> DEBUG_CRITICAL2("OS string: %s", os_version);
>
> And I have no idea why.
> frame #0 is corrupted so not very helpful :-(
Yup, that's about as far as I got. As you say, it looks like something
dumped all over the stack :(
> I don't really know what to suggest next. You can try to execute the function
> OpenGemPC430ByName() from GemPC430/GemPC430Utils.c step by step.
Tried that, I'm managing to get gdb to fall over (due to stepping into
libc functions). I'm trying to drill down by instrumenting the code
currently but it's a bit slow.
--
"You grabbed my hand and we fell into it, like a daydream - or a fever."
signature.asc
Description: Digital signature
Bug#387115: NMU patch
I'm about to upload an NMU fixing this using the enclosed patch. The
patch currently in the report appears to be non-functional.
--
"You grabbed my hand and we fell into it, like a daydream - or a fever."
diff -u vertex-0.1.15/vertex/string.cpp vertex-0.1.15/vertex/string.cpp
--- vertex-0.1.15/vertex/string.cpp
+++ vertex-0.1.15/vertex/string.cpp
@@ -30,7 +30,7 @@
#ifdef __MSW__
int strcasecmp(const char *s1, const char *s2);
#endif
-char *strcasestr(const char *haystack, const char *needle);
+char *strcasestr(const char *haystack, const char *needle) throw();
int strpfx(const char *s, const char *pfx);
int strcasepfx(const char *s, const char *pfx);
@@ -219,7 +219,7 @@
* Case insensitive version of strstr(). Returns the pointer to
* needle in haystack if found or NULL on no match.
*/
-char *strcasestr(const char *haystack, const char *needle)
+char *strcasestr(const char *haystack, const char *needle) throw()
{
const char *strptr1, *strptr2, *strptr3;
diff -u vertex-0.1.15/debian/changelog vertex-0.1.15/debian/changelog
--- vertex-0.1.15/debian/changelog
+++ vertex-0.1.15/debian/changelog
@@ -1,3 +1,10 @@
+vertex (0.1.15-1.3) unstable; urgency=low
+
+ * Non-maintainer upload.
+ * Fix more throw() specification mismatches (closes: #387115).
+
+ -- Mark Brown <[EMAIL PROTECTED]> Tue, 11 Sep 2007 22:49:24 +0100
+
vertex (0.1.15-1.2) unstable; urgency=low
* Non-maintainer upload.
signature.asc
Description: Digital signature
Bug#487104: setting package to nis, tagging 487104
# Automatically generated email from bts, devscripts version 2.10.35 # via tagpending # # nis (3.17-17) unstable; urgency=low # # * Force locale for ypcat to C in order to work around errors from #fprintf() with multi-byte characters (closes: #487104). # package nis tags 487104 + pending -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#487104: nis: map values containing non-ascii characters vanish
severity 487104 important kthxbye On Fri, Aug 15, 2008 at 05:12:43PM +0100, Jonathan H N Chin wrote: > The problem causes data loss, so it is "grave" at minumum: > http://www.debian.org/Bugs/Developer#severities > (At my site at least, the data loss is serious, as I explained in my > previous message, but I grant that this may not be the case elsewhere.) Please don't drop people from the CC list if you're going to make a major change like this to the status of a bug. The first time I found out that this was upgraded to RC severity was when I noticed that my closure message went to the release critical bugs list. As previously discussed while I do think this should be fixed for lenny I really don't think this is a severe enough problem to warrant removing the package from the distribution; the definition of data loss is being stretched a bit here (the data is still present and accessible via interfaces other than ypcat) and the package continues to function well in the overwhelming majority of use cases. Like I say, I appreciate that this is something which is very important in your system and do think this is something that should be fixed for the next release but given the choice between having this bug and not shipping at all it seems much more constructive to ship with the bug. Incidentally, my testing also seemed to indicate that it was quite hard to get a Debian system to generate UTF-8 data which had this problem - I ended up using a hex editor to get the encoding that you had, other encodings worked fine. -- "You grabbed my hand and we fell into it, like a daydream - or a fever." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#487104: nis: map values containing non-ascii characters vanish
reassign 487104 libc6 thanks On Thu, Jun 19, 2008 at 05:02:01PM +0100, [EMAIL PROTECTED] wrote: > Solaris 10 and Debian nis package 3.13-2 both accept non-ascii > characters in maps: > However, 3.17-6 does not: > This breaks login access to the system. As Jonathan said, ypcat is just a thin wrapper around libc APIs - in fact, as far as tools like login are concerned the NIS package has no involvement beyond binding to the NIS server. All parsing of data provided by the server is done outside of the NIS package. Reassigning there as a result but please provide further information on what has changed between a working and non-working system - I strongly expect that you will also have changed other packages. -- "You grabbed my hand and we fell into it, like a daydream - or a fever." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#487104: nis: map values containing non-ascii characters vanish
On Fri, Jun 20, 2008 at 11:32:05AM +0100, Jonathan H N Chin wrote: > I have a webserver running sarge. I'm building a replacement using etch. > It's not an upgrade, it's a fresh install. So, everything is different. You say this but... > When I used ypcat to retrieve the map, both entries were present > on Solaris 10 and debian nis 3.13-2. > However with nis 3.17-6, the non-ascii key was not found at all ...here you are talking about specific NIS package versions rather than a change from sarge to etch. Can you please confirm that the issue you are seeing manifests when changing distributions rather than being specifically the result of an upgrade of the nis package? As I said previously, code from the NIS package is not involved in reading data from the server for use when logging in so it is very unlikely that this issue is in the nis package. -- "You grabbed my hand and we fell into it, like a daydream - or a fever." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#476976: scons: Doesn't work at all
severity 476976 serious reassign 476976 python-central found 0.6.4 kthxbye On Sun, Apr 20, 2008 at 03:55:46PM +0200, Christian Marillat wrote: > $ scons > Traceback (most recent call last): > File "/usr/bin/scons", line 161, in > import SCons.Script > File "/usr/lib/scons/SCons/Script/__init__.py", line 80, in > import SCons.Options > ImportError: Bad magic number in /usr/lib/scons/SCons/Options/__init__.pyc The Python compiled files are managed by python-central rather than by SCons itself. As far as I can tell something has gone wrong during an upgrade leaving incompatible .pyc files lying around though I'm at a bit of a loss to explain exactly how. Purging (probably just removing, even) and reinstalling SCons should resolve the problem on your system though it would be helpful if you could wait until the python-central maintainers have had a chance to request diagnostic information. -- "You grabbed my hand and we fell into it, like a daydream - or a fever." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#476976: scons: Doesn't work at all
found 477180 0.98.1-1 thanks On Mon, Apr 21, 2008 at 06:19:37PM +0200, Matthias Klose wrote: > fixing this in 0.9.5. Mark, sorry, you have to rebuild against this > version. Christian: to remove these files, please install the old No problem, as it happens upstream just released a new version today so I have to rebuild anyway. -- "You grabbed my hand and we fell into it, like a daydream - or a fever." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#476976: Reopen #476976 (_not_ fixed in scons 0.98.2-1)
reassign python-central kthxbye On Fri, Apr 25, 2008 at 06:51:00PM +0200, Cyril Brulebois wrote: > reopen 476976 > found 476976 0.98.2-1 > thanks > > Debian Bug Tracking System <[EMAIL PROTECTED]> (25/04/2008): > > This is an automatic notification regarding your Bug report > > which was filed against the scons package: > > > > #476976: scons: Doesn't work at all > > > > It has been closed by Mark Brown <[EMAIL PROTECTED]>. > > | Changes: > | scons (0.98.2-1) unstable; urgency=low > | . > |* New upstream release. > |* Build against new python-central, picking up new generated code which > | fixes upgrades (closes: #476976). > > Hmm, no, the upgrade isn't fixed. > > Context: > > It started with my wondering whether I was hitting a regression in > scons, which you can trigger by trying to build blender in a clean sid > environment. AFAIUI by reading the diff, the Options->Variables > transition is being initiated, being at the moment mostly transparent, > then it's planned to warn for deprecation, and then to remove that > compat layer completely. > > While I'm perfectly OK with the above plan, it looks like that compat > layer just doesn't work. > | scons: Reading SConscript files ... > | ImportError: No module named BoolOption: > | File "/home/kibi/hack/collab-maint/blender-2.45/SConstruct", line 44: > | import tools.btools > | File "/home/kibi/hack/collab-maint/blender-2.45/tools/btools.py", line 4: > | import SCons.Options.BoolOption > | make: *** [build-stamp] Error 2 > > How I reproduced #476976: > - > Blender FTBFS with scons/0.98.2-1. Wondering which version was OK, I > downgraded scons to its testing version (0.98.0-1), which doesn't have > the Option->Variable transition, Blender built fine. Upgrading to the > sid version of scons again, Blender built fine again. And when purging > it: > | $ sudo dpkg -P scons > | (Reading database ... 26708 files and directories currently installed.) > | Removing scons ... > | dpkg - warning: while removing scons, directory `/usr/lib/scons/SCons' not > empty so not removed. > | dpkg - warning: while removing scons, directory `/usr/lib/scons' not empty > so not removed. > | [EMAIL PROTECTED]:~/hack/collab-maint/blender-2.45$ find /usr/lib/scons/ > | /usr/lib/scons/ > | /usr/lib/scons/SCons > | /usr/lib/scons/SCons/Options > | /usr/lib/scons/SCons/Options/EnumOption.pyc > | /usr/lib/scons/SCons/Options/ListOption.pyc > | /usr/lib/scons/SCons/Options/PathOption.pyc > | /usr/lib/scons/SCons/Options/__init__.pyc > | /usr/lib/scons/SCons/Options/BoolOption.pyc > | /usr/lib/scons/SCons/Options/PackageOption.pyc > > All of this being in an uptodate i386 chroot; python-central is 0.6.5. > Maybe you'll need to embed a code snippet in a maintainer script to > clean the mess that previous python-central version(s) introduced/left > in your previously-uploaded scons packages? > > Anyway, the above-mentioned regression deserves its own bugreport, which > is on its way. > > Mraw, > KiBi. -- "You grabbed my hand and we fell into it, like a daydream - or a fever." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#476976: Reopen #476976 (_not_ fixed in scons 0.98.2-1)
reassign 476976 python-central kthxbye On Fri, Apr 25, 2008 at 06:51:00PM +0200, Cyril Brulebois wrote: > reopen 476976 > found 476976 0.98.2-1 > thanks > > Debian Bug Tracking System <[EMAIL PROTECTED]> (25/04/2008): > > This is an automatic notification regarding your Bug report > > which was filed against the scons package: > > > > #476976: scons: Doesn't work at all > > > > It has been closed by Mark Brown <[EMAIL PROTECTED]>. > > | Changes: > | scons (0.98.2-1) unstable; urgency=low > | . > |* New upstream release. > |* Build against new python-central, picking up new generated code which > | fixes upgrades (closes: #476976). > > Hmm, no, the upgrade isn't fixed. > > Context: > > It started with my wondering whether I was hitting a regression in > scons, which you can trigger by trying to build blender in a clean sid > environment. AFAIUI by reading the diff, the Options->Variables > transition is being initiated, being at the moment mostly transparent, > then it's planned to warn for deprecation, and then to remove that > compat layer completely. > > While I'm perfectly OK with the above plan, it looks like that compat > layer just doesn't work. > | scons: Reading SConscript files ... > | ImportError: No module named BoolOption: > | File "/home/kibi/hack/collab-maint/blender-2.45/SConstruct", line 44: > | import tools.btools > | File "/home/kibi/hack/collab-maint/blender-2.45/tools/btools.py", line 4: > | import SCons.Options.BoolOption > | make: *** [build-stamp] Error 2 > > How I reproduced #476976: > - > Blender FTBFS with scons/0.98.2-1. Wondering which version was OK, I > downgraded scons to its testing version (0.98.0-1), which doesn't have > the Option->Variable transition, Blender built fine. Upgrading to the > sid version of scons again, Blender built fine again. And when purging > it: > | $ sudo dpkg -P scons > | (Reading database ... 26708 files and directories currently installed.) > | Removing scons ... > | dpkg - warning: while removing scons, directory `/usr/lib/scons/SCons' not > empty so not removed. > | dpkg - warning: while removing scons, directory `/usr/lib/scons' not empty > so not removed. > | [EMAIL PROTECTED]:~/hack/collab-maint/blender-2.45$ find /usr/lib/scons/ > | /usr/lib/scons/ > | /usr/lib/scons/SCons > | /usr/lib/scons/SCons/Options > | /usr/lib/scons/SCons/Options/EnumOption.pyc > | /usr/lib/scons/SCons/Options/ListOption.pyc > | /usr/lib/scons/SCons/Options/PathOption.pyc > | /usr/lib/scons/SCons/Options/__init__.pyc > | /usr/lib/scons/SCons/Options/BoolOption.pyc > | /usr/lib/scons/SCons/Options/PackageOption.pyc > > All of this being in an uptodate i386 chroot; python-central is 0.6.5. > Maybe you'll need to embed a code snippet in a maintainer script to > clean the mess that previous python-central version(s) introduced/left > in your previously-uploaded scons packages? > > Anyway, the above-mentioned regression deserves its own bugreport, which > is on its way. > > Mraw, > KiBi. -- "You grabbed my hand and we fell into it, like a daydream - or a fever." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#477912: scons: Broken Option->Variable compat. layer (causing regressions).
forwarded 477912 http://scons.tigris.org/issues/show_bug.cgi?id=2024 tag 477912 + upstream kthxbye On Fri, Apr 25, 2008 at 06:55:37PM +0200, Cyril Brulebois wrote: > I noticed that problem while preparing a security upload for Blender, > that's why I'd like to avoid having to adapt it to the new Variable-way > of doing things in scons, if possible. Blender really ought to be updated, the interface is actually being deprecated, and the patch to fix Blender is completely trival (see below) and ought to be compatible with older versions of SCons, though I've not tested that. I've forwarded this upstream in any case; the issue is that the compatibility version of BoolOption isn't a module so can't be directly imported. --- blender-2.45.orig/tools/btools.py +++ blender-2.45/tools/btools.py @@ -1,7 +1,6 @@ import os import os.path import SCons.Options -import SCons.Options.BoolOption try: import subprocess except ImportError: @@ -12,7 +11,7 @@ import sys Options = SCons.Options -BoolOption = SCons.Options.BoolOption +BoolOption = Options.BoolOption def print_arguments(args, bc): if len(args): -- "You grabbed my hand and we fell into it, like a daydream - or a fever." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#477912: scons: Broken Option->Variable compat. layer (causing regressions).
severity 477912 important kthxbye On Fri, Apr 25, 2008 at 09:15:39PM +0200, Cyril Brulebois wrote: > Since it's no longer a blocker for that security fix, and working around > it is really easy, you might want to downgrade the severity. That works for me! Thanks. -- "You grabbed my hand and we fell into it, like a daydream - or a fever." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#477971: Missing -I fixed in unstable
This should be fixed by SCons 0.98.2-2 which was uploaded to unstable this afternoon, please let me know if that's not the case. -- "You grabbed my hand and we fell into it, like a daydream - or a fever." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#476976: Reopen #476976 (_not_ fixed in scons 0.98.2-1)
On Sat, Apr 26, 2008 at 05:14:22PM +0200, Matthias Klose wrote: > sorry, will need another rebuild with 0.6.6 (or you remove the > directory manually). Will upload python-central tonight. No problem, thanks for the fix. -- "You grabbed my hand and we fell into it, like a daydream - or a fever." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#476976: Sorry: still not working
reassign 476976 python-central 0.6.6 kthxbye On Mon, Apr 28, 2008 at 09:36:33PM +0200, Andreas Tscharner wrote: > Package: scons > Version: 0.98.2-3 > Followup-For: Bug #476976 > > Sorry, but the bug is still not fixed: > > [EMAIL PROTECTED]:~$ scons > Traceback (most recent call last): > File "/usr/bin/scons", line 161, in > import SCons.Script > File "/usr/lib/scons/SCons/Script/__init__.py", line 80, in > import SCons.Options > ImportError: Bad magic number in > /usr/lib/scons/SCons/Options/__init__.pyc > > > -- System Information: > Debian Release: lenny/sid > APT prefers unstable > APT policy: (500, 'unstable') > Architecture: i386 (i686) > > Kernel: Linux 2.6.24 (SMP w/2 CPU cores) > Locale: LANG=de_CH.utf8, LC_CTYPE=de_CH.utf8 (charmap=UTF-8) > Shell: /bin/sh linked to /bin/bash > > Versions of packages scons depends on: > ii python2.5.2-1An interactive high-level > object-o > ii python-central0.6.6 register and build utility for > Pyt > > scons recommends no packages. > > -- no debconf information > > > -- "You grabbed my hand and we fell into it, like a daydream - or a fever." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#487104: nis: map values containing non-ascii characters vanish
On Fri, Aug 15, 2008 at 04:40:36PM +0200, Aurelien Jarno wrote:
> On Fri, Aug 15, 2008 at 03:15:21PM +0100, Jonathan H N Chin wrote:
> > > - Could you please run the ypcat command using:
> > > 'LC_ALL=en_GB.ISO-8859-1 LANG=en_GB.ISO-8859-1 ypcat'
> > > (note that you may have to generate the corresponding locale)
> > This works.
> This seems to say that the problem is in the nis package instead of the
> glibc package.
The ypcat program is just a thin wrapper around glibc routines. It uses
yp_all to ask glibc to iterate over all the keys in the map doing this:
static int
print_data (int status, char *inkey, int inkeylen, char *inval,
int invallen, char *indata __attribute__ ((unused)))
{
if (status != YP_TRUE)
return status;
if (kflag && (inkeylen > 0))
{
if (inkey[inkeylen - 1] == '\0')
--inkeylen;
fprintf (stdout, "%*.*s ", inkeylen, inkeylen, inkey);
}
if (invallen > 0)
{
if (inval[invallen -1] == '\0')
--invallen;
fprintf (stdout, "%*.*s\n", invallen, invallen, inval);
}
else
fputs ("\n", stdout);
return 0;
}
In any case, the major issue reported was with login and account lookups
which are handled by the NSS module provided by glibc, the RCness being
due to the inability to log in.
--
"You grabbed my hand and we fell into it, like a daydream - or a fever."
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
