severity 825423 important thanks On Thu, May 26, 2016 at 10:34:12PM +0200, Johannes Schauer wrote:
> this seems to suggest that you are not using a throw-away chroot but > a persistent one. Could you provide details about your chroot setup? > Are you not using schroot? I am using schroot. This is my /etc/schroot/chroot.d/stretch file: [stretch] type=directory description=Debian stretch directory=/chroot/stretch groups=sbuild root-groups=sbuild preserve-environment=true > That linux-image-4.5.0-2-amd64 cannot be uninstalled is not a bug in sbuild > but > a bug elsewhere. That a package cannot be uninstalled is nothing sbuild can do > something about. Well, except if, by mutual agreement, some mechanism is agreed between maintainers to ensure that a package may be uninstalled. > If anything, it is the responsibility of the chroot management > system to provide workarounds for situations like this if that's the last > ressort. > > > The reason for this, I think, is that linux-image refuses to be uninstalled > > if it detects that it's the same version which is running in the system. > > > > > > This check, however, fails to account this case, where the linux-image > > being removed is the same version but not actually the same which is > > running, > > if that is the case, then this sounds like a bug in the source package linux. Yes, this is what I think. If you feel uncomfortable with the fact that I submitted this report against three different packages, feel free to make a reassign. I just wanted to hear the input from the maintainers of the affected packages. > > I think it should not be too much difficult to check that we are not in a > > chroot. > > > > If we are in a chroot, removing the package should succeed, even if the > > version > > matches the linux-image running in the ssystem. > > > > > > Alternatively (and this is where the bug would not be only a bug in linux), > > linux-image could provide some kind of escape mechanism allowing sbuild > > to uninstall it successfully. > > I do not think it's a good idea for anybody to mingle with the dpkg database > or > maintainer scripts except for dpkg or the package itself. Neither do I. By "escape mechanism" I meant something like sbuild or schroot creating a file which linux-image can then check for existence. I believe such file already exist (/etc/debian_chroot), that's why I think this problem should be easy to solve. > [...] > > sbuild is indeed used on the buildds but those are using trow-away chroots > where it will not matter whether packages fail to uninstall. Since your setup > is different, I don't think buildds will be affected by this problem. Well, I'm downgrading to "important" just in case it helps the discussion. I've seen too many people angry for FTBFS bugs just because they don't happen in the official autobuilders right now, but I think our standards should be higher anyway (in the sense that packages must build from source noy only in the official autobuilder, not only when LANG=C, not only when the filesystem is ext4, etc.) Thanks.
