Hello Niels Thykier. Thanks for following up on this bug report...
On Mon, Dec 08, 2014 at 08:36:36AM +0100, Niels Thykier wrote: > On Thu, 27 Nov 2014 12:32:08 +0100 Andreas Henriksson <andr...@fatal.se> > wrote: > > Control: tags 771092 + moreinfo > > > > Just adding the passwd dependency would hide the real problem here. > > Someone needs to look into why the migration code is being run > > again and again (as it apparently does on a sparc buildd atleast)! > > This code is going to be dropped in Jessie+1 where it's expected > > that everyone has migrated. If there are cases where migration > > isn't working we need to fix those now. > > > > Regards, > > Andreas Henriksson > > > > > > Hi, > > The postinst looks like (modulo wrapping): > > """ > > # upgrade existing libuuid user/group. > if getent group libuuid >/dev/null && ! getent group uuidd >/dev/null ; then > groupmod --new-name uuidd libuuid > fi > if getent passwd libuuid >/dev/null && ! getent passwd uuidd >/dev/null > ; then > [...] > fi > """ > > In both cases, the condition for the ifs seems to be false. In the failing build logs the condition is true and it explodes because of groupmod not yet existing, so your issue seems unrelated to what I'm looking for information on. The buildd chroot upgrade seems to run the migration code and then somehow throw away all the resulting user/group modifications, so that on next package upgrade the migration runs again (and again, ...). > But: > > > """ > $ getent group libuuid >/dev/null && echo "group libuuid present"; \ > getent group uuidd >/dev/null && echo "group uuidd present" > group uuidd present > $ getent group libuuid >/dev/null && ! getent group uuidd >/dev/null > $ getent passwd libuuid >/dev/null ; echo "User libuuid present" ; \ > getent passwd uuidd >/dev/null && echo "User uuidd present" > User libuuid present > User uuidd present > $ getent passwd libuuid >/dev/null && ! getent passwd uuidd \ > >/dev/null && echo "true" > """ > > I "only" have /group/ uuidd, but I have both users present!? I'm not sure how that happened, but it is only a minor issue. The migration code checks that both the old user/group exists and new user/group not exists, so if both exists it's not a problem. Ofcourse it's not nice to leave old cruft around... I'd suggest we track this in a separate bug report. Please follow up on how both users looks. Does anything else then name and uid set them apart? If you remove the new username and reinstall the package does the user get migrated? My guess would be that the group got migrated on upgrade, then you already had a user with the new username so no user migration was done (and you where thus left with both the old and new usernames in place). > Inside the user migration, there is a remark that usermod will fail if > the process is running. Does that hold for groupmod as well? This remark comes from ubuntu users running into that problem. If the same where true for groupmod, the (launchpad) bug report for it would probably have said groupmod instead of usermod as groupmod is run first. So my guess is no. Regards, Andreas Henriksson -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
