Hi, Quoting Luca Boccassi (2022-07-26 15:27:35) > If it's not appropriate, please do update it accordingly, but IIRC it's what > gets used in these cases.
a bunch of sbuild issues piled up during the last weeks so I'll be doing an upload soon and will include a fix for this as well. > > I put the gcc maintainer in CC. Is the buildd tarball to be more than twice > > the size compared to before now? > > Good find - regardless of whether it's intended that the tarball is so > large, perhaps it is an indication that the sbuild testsuite is a bit > fragile w.r.t. the running environment? Would it be possible to adjust > it to be more resilient? Is there a different disk-based scratch area > available for test artifacts? the autopkgtest checks whether the sbuild unshare backend works. The environment on salsaci and the one on ci.debian.net does not support Linux user namespaces. To still be able to test it, the autopkgtest creates a virtual qemu environment and runs the test inside a qemu virtual machine. The size of the machine image is the limiting factor here. The virtual machine image size was not a problem since the introduction of this test in January 2021, so I wouldn't call it "fragile". Increasing the disk size is simple but while you call such an adjustment to make it more "resilient" I first want to confirm that the more than twice increase in size is intentional or not. Otherwise, changing the disk size might have the opposite effect of "resilient" and hide problems resulting from an accidental upload which unnecessarily increased the installation size by half a Gigabyte. Thanks! cheers, josch
signature.asc
Description: signature
