Re: mass bug filing of 'ucf: command not found' errors detected by piuparts
On 2012-01-31 18:14, Andreas Beckmann wrote: > I'm planning to file bugs against all packages that currently fail the > piuparts test with a 'ucf: command not found' error in wheezy and sid. As ucf became transitively essential in the mean time, this mass bug filing is postponed until this problem can be easily checked again. Andreas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f469a4e.8020...@abeckmann.de
Re: mass bug filing of 'ucf: command not found' errors detected by piuparts
]] Roger Leigh > > Line 3: "UTC" or "LOCAL". Tells whether the Hardware Clock is set to > > Coordinated Universal Time or local time. You can always override > > this value with options on the hwclock command line. > > If you saw my mail of a couple of days ago, I have made patches > for util-linux and clock-setup to enable this. Yup, I'm catching up on mail after holidays and responded without reading all the threads. It's good to see it's moving in the right direction. :-) Cheers, -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87pqd6j3kc@qurzaw.varnish-software.com
Re: mass bug filing of 'ucf: command not found' errors detected by piuparts
On Wed, Feb 22, 2012 at 10:14:49AM +0100, Tollef Fog Heen wrote: > ]] Roger Leigh > > > Just FYI, please see #659451. I've split the UTC variable into > > /etc/default/hwclock, which means /etc/default/rcS can become a > > regular dpkg conffile (in current git only for now). This needs > > support in d-i clock-setup (done) and util-linux (pending) before > > upload. > > I really wish we could just use /etc/adjtime instead, from hwclock(8): > > The format of the adjtime file is, in ASCII: > > [...] > > Line 3: "UTC" or "LOCAL". Tells whether the Hardware Clock is set to > Coordinated Universal Time or local time. You can always override > this value with options on the hwclock command line. If you saw my mail of a couple of days ago, I have made patches for util-linux and clock-setup to enable this. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120222140103.gd24...@codelibre.net
Re: mass bug filing of 'ucf: command not found' errors detected by piuparts
]] Roger Leigh > Just FYI, please see #659451. I've split the UTC variable into > /etc/default/hwclock, which means /etc/default/rcS can become a > regular dpkg conffile (in current git only for now). This needs > support in d-i clock-setup (done) and util-linux (pending) before > upload. I really wish we could just use /etc/adjtime instead, from hwclock(8): The format of the adjtime file is, in ASCII: [...] Line 3: "UTC" or "LOCAL". Tells whether the Hardware Clock is set to Coordinated Universal Time or local time. You can always override this value with options on the hwclock command line. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87wr7fjkl2@qurzaw.varnish-software.com
Re: mass bug filing of 'ucf: command not found' errors detected by piuparts
On Tue, Jan 31, 2012 at 10:07:22PM +, Roger Leigh wrote: > On Tue, Jan 31, 2012 at 11:52:42AM -0800, Steve Langasek wrote: > > On Tue, Jan 31, 2012 at 08:10:11PM +0100, Luk Claes wrote: > > > > Interesting timing. initscripts started depending on ucf just a few > > > > days ago, which makes ucf quasi-essential. > > > > > Unless you are going to argue to add it to the essential set, I can't > > > see why that matters. It's still wrong to use non-essential packages > > > in postrm unconditionally. One could even argue that an essential > > > package should not use ucf unconditionally and have a sane fall back > > > when it's not available. > > > > Well, I would argue that packages in the essential set shouldn't be adding > > new dependencies without some discussion and review on debian-devel first. > > Hopefully we can remove the ucf dependency; please see #648433. > Currently /etc/default/rcS is intentionally only installed once > during a fresh install, and never updated afterward. However, > this precludes ever updating it. Ideally we could make it a > conffile and handle it entirely with dpkg; this would probably > require splitting out the variables which should never be touched > into a separate file under /etc/defaults. Just FYI, please see #659451. I've split the UTC variable into /etc/default/hwclock, which means /etc/default/rcS can become a regular dpkg conffile (in current git only for now). This needs support in d-i clock-setup (done) and util-linux (pending) before upload. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120213234531.ge8...@codelibre.net
Re: mass bug filing of 'ucf: command not found' errors detected by piuparts
On Thu, Feb 09, 2012 at 11:18:08PM +0100, Andreas Beckmann wrote: > Roger Leigh wrote: > > On Tue, Jan 31, 2012 at 11:52:42AM -0800, Steve Langasek wrote: > > > On Tue, Jan 31, 2012 at 08:10:11PM +0100, Luk Claes wrote: > > > > > Interesting timing. initscripts started depending on ucf just a > > > > > few > > > > > days ago, which makes ucf quasi-essential. > [...] > > > Well, I would argue that packages in the essential set shouldn't be > > > adding > > > new dependencies without some discussion and review on debian-devel > > > first. > > > > Hopefully we can remove the ucf dependency; please see #648433. > > Currently /etc/default/rcS is intentionally only installed once > > sysvinit is currently at 9/10 days and about to migrate to testing. > If these two controversial changes (initscripts adding dependency on ucf > (which becomes transitively-essential), updating rcS on upgrade) should > not find their way into testing (in the current form), action should be > taken now. I won't have time to do anything about it personally until the weekend. Not that this is IMO a massively urgent problem--we can remove the use of ucf any time. What I would like to know in order to fix the problem properly, is which variables in /etc/default/rcS can't ever be in a conffile, and which ones can. Because right now it's a mixture, and I'd like to separate them. If it's just UTC that's the problem, I think splitting it into e.g. /etc/default/hwclock would be the appropriate solution, then /etc/default/rcS could become a regular conffile and ucf can be dropped Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120210090804.gn8...@codelibre.net
Re: mass bug filing of 'ucf: command not found' errors detected by piuparts
Roger Leigh wrote: > On Tue, Jan 31, 2012 at 11:52:42AM -0800, Steve Langasek wrote: > > On Tue, Jan 31, 2012 at 08:10:11PM +0100, Luk Claes wrote: > > > > Interesting timing. initscripts started depending on ucf just a > > > > few > > > > days ago, which makes ucf quasi-essential. [...] > > Well, I would argue that packages in the essential set shouldn't be > > adding > > new dependencies without some discussion and review on debian-devel > > first. > > Hopefully we can remove the ucf dependency; please see #648433. > Currently /etc/default/rcS is intentionally only installed once sysvinit is currently at 9/10 days and about to migrate to testing. If these two controversial changes (initscripts adding dependency on ucf (which becomes transitively-essential), updating rcS on upgrade) should not find their way into testing (in the current form), action should be taken now. Andreas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f344620.8010...@abeckmann.de
Re: mass bug filing of 'ucf: command not found' errors detected by piuparts
On Tue, Jan 31, 2012 at 11:52:42AM -0800, Steve Langasek wrote: > On Tue, Jan 31, 2012 at 08:10:11PM +0100, Luk Claes wrote: > > > Interesting timing. initscripts started depending on ucf just a few > > > days ago, which makes ucf quasi-essential. > > > Unless you are going to argue to add it to the essential set, I can't > > see why that matters. It's still wrong to use non-essential packages > > in postrm unconditionally. One could even argue that an essential > > package should not use ucf unconditionally and have a sane fall back > > when it's not available. > > Well, I would argue that packages in the essential set shouldn't be adding > new dependencies without some discussion and review on debian-devel first. Hopefully we can remove the ucf dependency; please see #648433. Currently /etc/default/rcS is intentionally only installed once during a fresh install, and never updated afterward. However, this precludes ever updating it. Ideally we could make it a conffile and handle it entirely with dpkg; this would probably require splitting out the variables which should never be touched into a separate file under /etc/defaults. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120131220722.gz8...@codelibre.net
Re: mass bug filing of 'ucf: command not found' errors detected by piuparts
Hi, On Dienstag, 31. Januar 2012, Michael Biebl wrote: > Interesting timing. initscripts started depending on ucf just a few days > ago, which makes ucf quasi-essential. where was this discussed/announced? cheers, Holger -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201201312303.40162.hol...@layer-acht.org
Re: mass bug filing of 'ucf: command not found' errors detected by piuparts
On Tue, Jan 31, 2012 at 08:10:11PM +0100, Luk Claes wrote: > > Interesting timing. initscripts started depending on ucf just a few > > days ago, which makes ucf quasi-essential. > Unless you are going to argue to add it to the essential set, I can't > see why that matters. It's still wrong to use non-essential packages > in postrm unconditionally. One could even argue that an essential > package should not use ucf unconditionally and have a sane fall back > when it's not available. Well, I would argue that packages in the essential set shouldn't be adding new dependencies without some discussion and review on debian-devel first. That's not technically required by policy, but pulling new packages into the transitively-essential package set has the same sort of potentially disruptive effect on upgrades that adding pre-depends does. But the only reason I see for a transitively-essential package to avoid using ucf unconditionally is if it *doesn't* have a dependency on it. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: mass bug filing of 'ucf: command not found' errors detected by piuparts
On 01/31/2012 08:01 PM, Michael Biebl wrote: > On 31.01.2012 18:14, Andreas Beckmann wrote: >> Hi, >> >> I'm planning to file bugs against all packages that currently >> fail the piuparts test with a 'ucf: command not found' error in >> wheezy and sid. Currently 22 binary packages from 16 source >> packages are affected. >> >> Most of these errors happen during the 'postrm purge' phase >> because non-essential programs are called by the maintainer >> script without checking their existance. >> > > Interesting timing. initscripts started depending on ucf just a few > days ago, which makes ucf quasi-essential. Unless you are going to argue to add it to the essential set, I can't see why that matters. It's still wrong to use non-essential packages in postrm unconditionally. One could even argue that an essential package should not use ucf unconditionally and have a sane fall back when it's not available. Cheers Luk -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f283c93.7060...@debian.org
Re: mass bug filing of 'ucf: command not found' errors detected by piuparts
On 31.01.2012 18:14, Andreas Beckmann wrote: > Hi, > > I'm planning to file bugs against all packages that currently fail the > piuparts test with a 'ucf: command not found' error in wheezy and sid. > Currently 22 binary packages from 16 source packages are affected. > > Most of these errors happen during the 'postrm purge' phase because > non-essential programs are called by the maintainer script without > checking their existance. > Interesting timing. initscripts started depending on ucf just a few days ago, which makes ucf quasi-essential. Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
mass bug filing of 'ucf: command not found' errors detected by piuparts
Hi, I'm planning to file bugs against all packages that currently fail the piuparts test with a 'ucf: command not found' error in wheezy and sid. Currently 22 binary packages from 16 source packages are affected. Most of these errors happen during the 'postrm purge' phase because non-essential programs are called by the maintainer script without checking their existance. The 'command-not-found' failure logs are available from http://piuparts.debian.org/sid/command_not_found_error.html http://piuparts.debian.org/wheezy/command_not_found_error.html The 'postinst-failed' logs (mostly due to command-not-found, so showing more or less the same packages) are here: http://piuparts.debian.org/sid/unknown_purge_error.html http://piuparts.debian.org/wheezy/unknown_purge_error.html I'll file these bugs with Severity: important since having a piuparts clean archive is a release goal since lenny. The bug report will be based on this template: Hi, during a test with piuparts I noticed your package failed to purge due to a command not found. According to policy 7.2 you cannot rely on the depends being available during purge, only the essential packages are available for sure. Please see the manpages ucf(1), ucfr(1) and the example maintainer scripts under /usr/share/doc/ucf/examples/ for correct usage of ucf. Filing this as important because a.) it's a clear policy violation (to not clean up at purge) b.) having a piuparts clean archive is a release goal since lenny and c.) this package being piuparts buggy blocks packages depending on it from being tested by piuparts (and thus possibly the detection of more severe problems). From the attached log (scroll to the bottom...): $LOGEXCERPT Attachment: $PACKAGE_$VERSION.log.gz The logfiles will be checked individually to determine that the command-not-found is really the most serious error and caused the test to fail. Following is a list of maintainers and their source packages that have at least one binary package that both fails the piuparts test and has 'ucf: not found' errors (but may contain false positives). Regards, Andreas Alexander Wirt icinga (U) Benoit Mortier fusioninventory-agent (U) Bradley Bell rt-extension-assettracker (U) Cameron Dale torrentflux Christoph Haas cream cream (U) zabbix Dan Poltawski moodle (U) Debian Nagios Maintainer Group icinga ndoutils (U) Debian QA Group webissues-server Debian Request Tracker Group rt-extension-assettracker rtfm Dominic Hargreaves movabletype-opensource rt-extension-assettracker (U) rtfm (U) Fabio Tranchitella zabbix (U) Gonéri Le Bouder fusioninventory-agent Hendrik Frenzel ndoutils Jan Christoph Nordholz autofs5 Jan Wagner icinga (U) Jeroen Schot cream Michael Ablassmeier zabbix (U) Moodle Packaging Team moodle Neil Roeth psgml Niko Tyni rtfm (U) Patrick Matthäi webissues-server Penny Leach moodle (U) Pierre Chifflier ocsinventory-agent Radu Spineanu simba Reinhard Tartler boxbackup Tomasz Muras moodle (U) Xavier Oswald moodle (U) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f28218d.8020...@abeckmann.de
