Re: mass bug filing of 'deluser/delgroup: command not found' errors detected by piuparts
On 2012-03-23 04:07, Ian Jackson wrote: If you absolutely want a workaround an obvious one is to bodge a fake deluser into the piuparts setup. I don't think working around bugs without properly documenting them first ist a good solution. Especially for sid where we do much more pedantic tests than for stable. Alternatively you could ask package maintainers to simply comment out the deluser line. Right, thats another possible solution for now. I don't think it's reasonable to do an MBF, and request many changes to packages, until we know that we won't want to do soon afterwards another MBF on the same topic against the same packages deprecating the approach from the previous MBF. Actually, we are currently down to 4 packages that fail on an unconditional call to deluser and don't have bugs filed, yet. There were several more when I started this thread. sid/wheezy: boxbackup-server slurm-llnl-slurmdbd slurm-llnl experimental: condor 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/4f6c2fc0.5080...@abeckmann.de
Re: mass bug filing of 'deluser/delgroup: command not found' errors detected by piuparts
On 2012-02-04 08:55, Vincent Bernat wrote: OoO Peu avant le début de l'après-midi du jeudi 02 février 2012, vers Andreas Beckmann deb...@abeckmann.de disait : I'm planning to file bugs against all packages that currently fail the piuparts test with a 'deluser/delgroup: command not found' error in wheezy and sid. Currently 17 binary packages from 15 source packages are affected. deluser allows the use of --system to avoid to remove a real user. userdel does not have this kind of switch. Using userdel instead of deluser is dangerous. I would prefer to leave the user untouched than removing the wrong user instead. Of course, the postrm script should not stop because of this (|| true). I have revised the template to include a link to the discussion about not removing system users on package removal: 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. The fix should be easy: your package is using adduser or deluser from the adduser package, which is only priority important. Using useradd or userdel from the passwd package (priority required) should fix this problem. There is ongoing discussion how to handle system users on package removal, see http://bugs.debian.org/621833 Consensus seems to be not to remove system users (to avoid reusing UIDs which could grant access to the wrong files) but to lock them (where locking/unlocking is not yet precisely defined). Until that has been decided it should be sufficient to have the postrm script ignore any errors from deluser: deluser ... || true 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...): cheers, 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/4f6afc80.30...@abeckmann.de
Re: mass bug filing of 'deluser/delgroup: command not found' errors detected by piuparts
On 2012-03-22 13:50, Ian Jackson wrote: Andreas Beckmann writes (Re: mass bug filing of 'deluser/delgroup: command not found' errors detected by piuparts): I have revised the template to include a link to the discussion about not removing system users on package removal: I think it would be better to wait with this MBF until we have sorted out the whole problem. The problem I'd like to solve here is not how to deal with system users on postrm but package fails to purge due to unconditional use of deluser which blocks piuparts tests of dependent packages which might have more serious bugs. I don't think this is good advice. Better suggestions welcome. I'd like to give advice how to fix the buggy postrm scripts *now* while being aware that general changes in user handling may be needed later. 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/4f6b23b3.1020...@abeckmann.de
Re: mass bug filing of 'deluser/delgroup: command not found' errors detected by piuparts
Andreas Beckmann writes (Re: mass bug filing of 'deluser/delgroup: command not found' errors detected by piuparts): I have revised the template to include a link to the discussion about not removing system users on package removal: I think it would be better to wait with this MBF until we have sorted out the whole problem. There is ongoing discussion how to handle system users on package removal, see http://bugs.debian.org/621833 Consensus seems to be not to remove system users (to avoid reusing UIDs which could grant access to the wrong files) but to lock them (where locking/unlocking is not yet precisely defined). Until that has been decided it should be sufficient to have the postrm script ignore any errors from deluser: deluser ... || true I don't think this is good advice. Ian. -- 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/20331.8231.1817.581...@chiark.greenend.org.uk
Re: mass bug filing of 'deluser/delgroup: command not found' errors detected by piuparts
Andreas Beckmann writes (Re: mass bug filing of 'deluser/delgroup: command not found' errors detected by piuparts): Better suggestions welcome. I'd like to give advice how to fix the buggy postrm scripts *now* while being aware that general changes in user handling may be needed later. If you absolutely want a workaround an obvious one is to bodge a fake deluser into the piuparts setup. Alternatively you could ask package maintainers to simply comment out the deluser line. I don't think it's reasonable to do an MBF, and request many changes to packages, until we know that we won't want to do soon afterwards another MBF on the same topic against the same packages deprecating the approach from the previous MBF. Ian. -- 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/20331.59623.230318.675...@chiark.greenend.org.uk
Re: mass bug filing of 'deluser/delgroup: command not found' errors detected by piuparts
OoO Peu avant le début de l'après-midi du jeudi 02 février 2012, vers 13:11, Andreas Beckmann deb...@abeckmann.de disait : I'm planning to file bugs against all packages that currently fail the piuparts test with a 'deluser/delgroup: command not found' error in wheezy and sid. Currently 17 binary packages from 15 source packages are affected. deluser allows the use of --system to avoid to remove a real user. userdel does not have this kind of switch. Using userdel instead of deluser is dangerous. I would prefer to leave the user untouched than removing the wrong user instead. Of course, the postrm script should not stop because of this (|| true). -- Vincent Bernat ☯ http://vincent.bernat.im Use debugging compilers. - The Elements of Programming Style (Kernighan Plauger) pgplI1TdM1oHI.pgp Description: PGP signature
mass bug filing of 'deluser/delgroup: 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 'deluser/delgroup: command not found' error in wheezy and sid. Currently 17 binary packages from 15 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. The fix should be easy: your package is using adduser or deluser from the adduser package, which is only priority important. Using useradd or userdel from the passwd package should fix this problem. 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 'deluser/delgroup: not found' errors (but may contain false positives). Regards, Andreas Bdale Garbee bd...@gag.com bind9 (U) Damien Raude-Morvan draz...@debian.org tomcat6 (U) Debian Java Maintainers pkg-java-maintain...@lists.alioth.debian.org tomcat6 tomcat7 Debian OLPC debian-olpc-de...@lists.alioth.debian.org sugar-0.86 sugar-0.88 sugar-0.90 Debian Virtualbox Team pkg-virtualbox-de...@lists.alioth.debian.org virtualbox Dirk Eddelbuettel e...@debian.org slurm-llnl (U) Evgeni Golov evg...@debian.org bley Felix Geyer debfx-...@fobos.de virtualbox (U) Gennaro Oliva oliv...@na.icar.cnr.it slurm-llnl Igor Stroh jen...@debian.org ldap2dns James Page james.p...@ubuntu.com tomcat7 (U) Jeremy Malcolm termi...@debian.org gozerbot John M Collins j...@xisl.com gnuspool Jonas Smedegaard d...@jones.dk sugar-0.86 (U) sugar-0.88 (U) sugar-0.90 (U) LaMont Jones lam...@debian.org bind9 Ludovic Claude ludovic.cla...@laposte.net tomcat6 (U) Luke Faraone l...@faraone.cc sugar-0.88 (U) sugar-0.90 (U) Mario Izquierdo (mariodebian) mariodeb...@gmail.com tcos Martin Schulze j...@debian.org sysklogd Michael Koch konque...@gmx.de tomcat6 (U) Michael Meskes mes...@debian.org virtualbox (U) Mickael Profeta prof...@debian.org prelude-manager prelude-manager (U) Miguel Landaeta mig...@miguel.cc tomcat6 (U) tomcat7 (U) Niels Thykier ni...@thykier.net tomcat6 (U) Philip Hands p...@hands.com gnuspool (U) Pierre Chifflier pol...@debian.org prelude-manager prelude-manager (U) tony mancill tmanc...@debian.org tomcat6 (U) tomcat7 (U) Torsten Werner twer...@debian.org tomcat6 (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/4f2a7d7c.40...@abeckmann.de
Re: mass bug filing of 'deluser/delgroup: command not found' errors detected by piuparts
Andreas Beckmann writes (mass bug filing of 'deluser/delgroup: command not found' errors detected by piuparts): Most of these errors happen during the 'postrm purge' phase because non-essential programs are called by the maintainer script without checking their existance. We had a conversation (here I think) last year about whether programs should be trying to automatically remove users in their postrm. IIRC the conclusion of that discussion the answer was that they should not, at least in the default case. We should double check this, before you submit your MBF, so that information about what to do can be included in your bug report. The fix should be easy: your package is using adduser or deluser from the adduser package, which is only priority important. Using useradd or userdel from the passwd package should fix this problem. In particular, I think this is the wrong advice because IMO the correct fix is not to call any of these tools from postrm purge. Thanks, Ian. -- 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/20266.41842.239869.396...@chiark.greenend.org.uk
RE : mass bug filing of 'deluser/delgroup: command not found' errors detected by piuparts
We had a conversation (here I think) last year about whether programs should be trying to automatically remove users in their postrm. IIRC the conclusion of that discussion the answer was that they should not, at least in the default case. We should double check this, before you submit your MBF, so that nformation about what to do can be included in your bug report. In particular, I think this is the wrong advice because IMO the correct fix is not to call any of these tools from postrm purge. In that case you got his kind of piuparts error [1], if you did not remove the homedir of the previously added user. What is the right fice for this ? Cheers, Frederic [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=657146 -- 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/a2a20ec3b8560d408356cac2fc148e5325072...@sun-dag1.synchrotron-soleil.fr
Re: RE : mass bug filing of 'deluser/delgroup: command not found' errors detected by piuparts
On Thu, Feb 02, 2012 at 05:09:42PM +, PICCA Frédéric-Emmanuel wrote: We had a conversation (here I think) last year about whether programs should be trying to automatically remove users in their postrm. IIRC the conclusion of that discussion the answer was that they should not, at least in the default case. We should double check this, before you submit your MBF, so that nformation about what to do can be included in your bug report. In particular, I think this is the wrong advice because IMO the correct fix is not to call any of these tools from postrm purge. The relevant bug is this: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=621833 And I agree with Ian's summary: system users should be created, but not removed. In that case you got his kind of piuparts error [1], if you did not remove the homedir of the previously added user. What is the right fice for this ? The proper way to fix this is to change piuparts to not complain about home directories that belong to system users created during the package install. -- Freedom-based blog/wiki/web hosting: http://www.branchable.com/ signature.asc Description: Digital signature
Re: mass bug filing of 'deluser/delgroup: command not found' errors detected by piuparts
Lars Wirzenius wrote: On Thu, Feb 02, 2012 at 05:09:42PM +, PICCA Frédéric-Emmanuel wrote: In that case you got his kind of piuparts error [1], if you did not remove the homedir of the previously added user. What is the right fice for this ? The proper way to fix this is to change piuparts to not complain about home directories that belong to system users created during the package install. Almost all system users should use a non-existent home directory, which solves the problem for those users. And in cases like the one linked to from footnote [1] above, I think rm -rf on purge seems like the right solution, even if the user/group itself sticks around. Most of the time packages shouldn't leave data around when purged, even if they leave users around just in case something else uses the UID. - Josh Triplett -- 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/20120203072301.GA15817@leaf
