Hello again Niels! On Tue, Dec 09, 2014 at 06:32:18AM +0100, Niels Thykier wrote: [...] > > 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, ...). > > > > This seems like plausible explanation given we tend to use throw-away > chroots or lvm-snapshots. So if this problem only appears on buildds > (or in other throw-ways environments), I guess you are just missing a > Depends after all. > > We can have the buildds upgraded post Jessie, before you remove the > migration code. I cannot recommend it now, as gcc has a new version in > unstable that could cause issues for other packages (that could pick up > a dependency on the newer gcc). [...]
I have absolutely no idea how the buildds work, but I imagine it's overall somewhat similar to how pbuilder handles chroots. ie. throw away chroots for builds, a pristine chroot as a base. With pbuilder you simply "pbuilder --update" to update the pristine chroot without throwing away the changes. This second part is not working correctly on the buildds, as they keep the upgraded package but throws away the usermod/groupmod changes done in the maintainer scripts. This means the throwaway chroot comes with a pre-installed version of src:util-linux packages which should have already done the migration of the user, but hasn't.... Are you saying that the buildds somehow copies the user/group database from the host (which is not yet running jessie?)? That would be weird.... I could add a pre-condition check in postinst to detect if we are upgrading *from* a version which should already have migrated but somehow haven't and bail out. I guess that would be an effective way to halt all buildds and I bet the release team wouldn't appreciate that right now... On the other hand I bet it would be an effective way of getting attention and feedback on the issue. :P Not sure how to proceed from here. Do we even know if this issue is isolated to only the Debian buildds? If so, I guess we could argue that the chroots provided are corrupt and buildd admins gets to fix up the mess when we open up Stretch. 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
