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

Re: Bug Stamp Out List

Thanks Marcus, that's helpful.  I won't quote bits where I agree with you.

Marcus Brinkmann writes ("Bug Stamp Out List"):
> Bug reports listed below:
>  1399, 1642, 1818, 2531, 2828, 2863, 2904, (2973, 3125), 3218, 3233, 3704,
>  4074, 4195, 4379, 4393, 4419, 4450, 4468, 4801, 4901, 4974
> Actions to take:
>  Tell Marcus what's going on here, because he is confused: 4074

I've sent an update to that report.

>  Close: 3218, 1642, 2531 (?), 3233, 3704, 4393, 4450, 4419
>  Patch+Close: 2904, 4195
>  Fix+Close: 2863, 1399, 1818, 4801, 4901, 4974
>  Decide(+Close): (2973, 3125), 4468
>  Investigate: 4319, 4379
>  Discuss: 2828

Is it easy for you to replace this summary with one which lists the
bugs' titles ?

> == Diagnosis ================================================================
> Report: 1399
> Status: Open, should be easy to fix.
> Analyse: dselect bails out if "Select" is choosen while db area locked.
> Explanation:
>  While dpkg database is locked, dselect can't operate cleanly.
>  However, when choosing Configuration, Installation or Removal, it does not
>  bail out back returns back to the main menu.
> Strategy:
>  Make dselect return to the main menu if Select is choosen while database is
>  locked.

This may be harder than it looks.  I think it's Investigate.

> Report: 1642
> Status: Open, can be closed.
> Changelog: See dpkg 1.0.6
> Analyse: dselect recursive dependency resolution doesn't do the right thing.
> Explanation:
>  Raul says that dselect's recursive dependency resolution doesn't work if
>  recommended packages aren't available.
> Strategy:
>  As dselect spits out messages about his today, this bug report can be
>  closed.

I disagree.  I think dselect should warn you once, but then let you
leave of the recursive package listing, or get you to dselect the
depending/recommending package, or something.

> Report: 2531
> Status: Open, can be closed?
> Analyse: install-info needs better locking strategy.
> Explanation:
>  I am a bit puzzled here, the bug report is very short, here:
>   Thomas Krichel writes ("incomplete package installation"):
>   > Unpacking replacement emacs ...
>   > install-info: failed to lock dir for editing! File exists
>   > install-info: failed to lock dir for editing! File exists
> Strategy:
>  Ian, if this was fixed silently, please close the report. Otherwise comment
>  what is wrong here. I have never seen this errornous behaviour (beside
>  under the Hurd, which doesn't have POSIX locking yet :)

The bug report is that install-info uses a .lock file, when it should
use fcntl F_SETLKW.  So, should be Needs code.

> Report: 3218
> Status: Open, can be closed.
> Changelog: See dpkg 1.2.4
> Analyse: install-info adds section in a wrong way.
> Explanation:
>  Because of a missing newline, install-info behaved wrong. It is
>  unclear to me if only a \n in install-info was necessary, or also in
>  base-files. However, both places are fine today.
> Strategy:
>  Close the report.

Was it fixed in the NMU series ?  If so it should have `Severity:
fixed' so that I know to incorporate the fix.

> Report: 3233
> Status: Open, can hopefully be closed.
> Analyse: bugs in dselect of 1.1.
> Explanation:
>  Heiko describes two bugs here, but didn't gave additional
>  information needed.
> Strategy:
>  This is probably so old, that the bugs have been fixed silently in the
>  meantime. I contacted the submitter, and if he does not respond positively
>  in the next time, this bug should be closed.

Yes, please close it.

> Report: 3704
> Status: Open, can be closed
> Changelog: See dpkg 1.2.11
> Analyse: dependency bug in dselect.
> Explanation:
>  When installed version is later then available version, dselect enters the
>  conflict resolution screen even with no conflict.
> Strategy:
>  As this bug was fixed in 1.2.11, the report can be closed.

Has anyone tested that this is definitely the same bug fixed in 1.2.11.

> Report: 4319
> Status: Open, unclear.
> Analyse: dpkg does overwrite changed conffiles during upgrade
> Explanation:
>  The claim was made that dpkg overwrote silently changed conffiles during
>  package upgrade, but it is not proven. It is hard to reproduce what
>  happened.
> Strategy:
>  This report should probably be closed. If there was really such bug in
>  dpkg, it would have been noticed by many people in the meantime. Without
>  the original packages, we can't try to reproduce it, and the changelog from
>  netstd/netbase doesn't reach back this far.
>  Alternatively you can try to get more information from the submitter, but I
>  wouldn't know what to ask, so someone else has to do it.

The netbase maintainers need to be contacted to make sure it's not a
bug in netbase.  If they think it might have been a bug in netbase
which they think is now fixed then the report can be closed.

> Report: 4379
> Status: Open, unclear.
> Analyse: Installing a package fails because a package it depends on is not
>  yet installed (but "selected").
> Explanation:
>  dpkg (started from dselect) did interrupt the installation because perl
>  needed libgdbm, which wasn't installed but selected.
>  The perl changelog tells me that perl pre-depended on libgdbm that days, so
>  it may be a pre dependency problem.
> Strategy:
>  I am quite certain that pre-depends work today and do not lead to
>  an interrupted install, but I don't know all install methods. So you may
>  want to close this bug. At the very least perl does not predepend on
>  libgdbm today, which may also be a good answer :)

I've closed it.

> Report: 4394
> Status: Open, can be closed.
> Changelog: See dpkg
> Analyse: Argument to $rootcommand should be quoted.
> Explanation:
>  The argument to the $rootcommand in dpkg-buildpackage should be quoted, so
>  "su -c" does work with command "debian/rules build".
> Strategy:
>  This bug was fixed in dpkg and the report can be closed.

The bug (and the fix) is in error.  You can't make both su and
sudo/super/really etc. work, and su is IMO wrong.  This is documented
in dpkg-source(1).  The bug should be left open so that I can make
sure I don't accidentally include the alleged fix.

> Report: 4419
> Status: Open, can be closed.
> Changelog: See dpkg 1.4.0
> Analyse: debian-changelog.el should use magic subst strings
> Explanation: changelog mode should use way to automaticall insert currentrr
>  keybindings.
> Strategy:
>  Was fixed in 1.4.0 and can be closed.

I've closed it.

> Report: 4450
> Status: Open, can be closed.
> Analyse: dselect should warn about super-current packages and don't downgrade stuff.
> Explanation:
>  The submitter says it's "scary" that dselect offers packages with lesser
>  available version under "up to date" packages, and is afraid of dselect
>  downgrading these.
> Strategy:
>  Close the report. Scott Ellis pointed out (correctly, AFAIK), that dselect
>  won't downgrade packages (-G option to dpkg). Therefore this report is
>  uninformed and can be closed.

Perhaps dselect could be clearer about the fact that it wouldn't
downgrade.  This is probably a documentation issue, `Fix+close'.

> Report: 4468
> Status: Open, normal (could probably be closed).
> Analyse: dpkg should accept that new package has no postrm.
> Explanation:
>  If a package is upgraded, and the old postrm _fails_, and there is no new
>  postrm, dpkg will give up.
> Strategy:
>  Well, there are two ways to interpret this:
>  1) dpkg is correct. the old postrm encounters problems, and dpkg just tries
>     the newer postrm as a last resort, and to give the maintainer a chance
>     to fix a bug in a newer version of the package. If there is no postrm in
>     the newer package, the problem can't be resolved, and dpkg should abort
>     (otherwise, the package maintainer had made an empty postrm, right?).
>  2) dpkg is incorrect. A missing postrm in the latest package could be
>     interpreted as "no postrm needed" and dpkg could ignore that first postrm
>     broke.
>  I think that interpretation 2) is very wrong, and in disharmony with the
>  philosophy of packaging script policy. A maintainer is responsible for
>  upgradeability. If one postrm in one version doesn't work, he must make sure
>  that all later packages include a workaround in the postrm of the later
>  version, and the postrm with the workaround must never be removed (in this
>  case, the submitter removed the postrm himself).
>  Ian, you set the severity from fixed back to normal. Why? What is the
>  reason that you think dpkg's behaviour is wrong or suboptimal?

I want to think about it more.  I set the severity back from `fixed'
because there is no change in the NMU series that changes the
behaviour here.


Reply to: