Steve Langasek <[EMAIL PROTECTED]> writes: > On Tue, Aug 03, 2004 at 12:07:36PM -0700, Russ Allbery wrote:
>> #255582 gpdf >> I was unable to reproduce this bug in testing, and from the reports it >> sounded like it should be easily reproducible. Perhaps it has since >> cleared up due to library migrations? Mailed the two people who >> reported it and asked them to check, and one of them wrote back to say >> they were no longer seeing this either. > The bug was tagged "grave" on the 26th of July, which was not so long > ago. Perhaps you could ask Tim Dijkstra <[EMAIL PROTECTED]> for more > details about his environment (versions of library dependencies)? Sure, I can follow up here. It smells like a library dependency issue that isn't fully captured by tight enough dependencies to me, somehow, but I could be wrong. (Wasn't there a bit Gnome migration right about then, or was that a little earlier?) >> #260428 affiche >> Reporter was using affiche under a non-GNUstep environment, which >> isn't really its intended usage. I was unable to reproduce the bug >> under fvwm2, although the behavior of the application is a little odd. >> I would attribute that to not running under GNUstep, though. > I've followed up to this bug with the results of my own test. A > backtrace from someone able to reproduce this on i386 would be good, > though, to confirm we're looking at the same bug. (I don't currently > have an i386 machine with a local X server running, and remote display > doesn't work due to heavy dependencies on XShm in affiche.) Yeah... I still can't duplicate it. I tried on a different system that's running WindowMaker, and it still works for me. >> #261319 dhcp-client >> Behavior with regards to /etc/resolv.conf is documented (although >> not in the most obvious location), and the package provides an >> (undocumented) way of working around it. The documentation could >> be improved, but replacing /etc/resolv.conf is a common problem >> with DHCP clients and doesn't warrant removing the package. > I agree that this is not RC. Whether it's serious is perhaps debatable; > but given that this is a general, pre-existing problem, if you feel that > downgrading it is not appropriate, feel free to tag it sarge-ignore. Personally, I would turn it into a documentation bug and downgrade it to important, but it feels to me like the sort of call that the maintainer should make. I'm not very sure yet how many changes I should be making to other people's bugs; so far, I've not done anything other than add patch tags. >> #239326 freewrl >> There is a packaging problem here, in that what is installed as the >> freewrl binary isn't the actual binary. However, there are deeper >> problems than that, as the binary segfaults immediately if built out >> of the source tree and then run. gdb wasn't helpful (to me at least). > Does this bug affect the version of the package in sarge? (The bug is > tagged "sid", and the version of the package in sid isn't progressing to > sarge any time soon.) Yup, unfortunately: windlord:~> dpkg -l freewrl Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad) ||/ Name Version Description +++-==============-==============-============================================ ii freewrl 0.29-1.1 vrml browser and netscape plugin windlord:~> freewrl Segmentation fault It dies in a different place, so it may or may not be exactly the same bug, but it looks like it dies deep inside dynamically loaded Perl modules with a corrupted stack. -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
