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 1.4.0.1
> 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 1.4.0.1 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.
Ian.
Reply to: