[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

>> #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
| 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: