Re: Some RC bug work
Steve Langasek <vorlon@debian.org> 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 <tim@famdijkstra.org> 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 (rra@stanford.edu) <http://www.eyrie.org/~eagle/>
Reply to: