Jochen, On Tuesday, November 26, 2024 11:47:16 PM MST Jochen Sprickerhof wrote: > * Soren Stoutner <[email protected]> [2024-11-26 14:40]: > >Can you explain a little bit about how this gives better test results? > > The tarball used for sbuild usually is of variant buildd which contains > quite a number of packages. That mean packages in that set are not > tested and packages having a transitive dependency on that set are not > tested completely. It is possible to use a tarball of variant apt for > both but results in sbuild needing to install more packages.
Thank you for the explanation. > That's great to hear, so to recap it works with the piuparts call > encoded in sbuild together with the piuparts bootstrapping it's own > chroot with mmdebstrap but does not work with your sbuild config and > generated tarball. > > Can you please share how you created the tarball so I can reproduce your > result? I followed the instructions on the wiki at: https://wiki.debian.org/sbuild with a few modifications I will describe below. When creating the tarball I used .xz compression instead of .zst. I changed the apt source from https:// to http:// to make apt-cacher-ng happy in the default state. And I added the proxy information. The complete command I used is below: mmdebstrap --include=ca-certificates --variant=buildd unstable ~/.cache/sbuild/ unstable-amd64.tar.xz http://deb.debian.org/debian --aptopt='Acquire::http { Proxy "http://127.0.0.1:3142";; }’ I based my .sbuildrc off of the example in the wiki. For Piuparts, I changed --basetgz to use the .xz extension instead of .zst. I also added --no- eatmydata as suggested in the wiki. My entire .sbuildrc is below. # Set the chroot mode to be unshare. $chroot_mode = 'unshare'; # Exit to a shell on command failures. $external_commands = { "build-failed-commands" => [ [ '%SBUILD_SHELL' ] ] }; # Specify the distribution, -d $distribution = 'unstable'; ## Run lintian after every build (in the same chroot as the build). $run_lintian = 1; $lintian_opts=['--info', '--display-info', '--verbose', '--fail- on','error,warning']; ## Run autopkgtest after every build (in a new, clean, chroot). $run_autopkgtest = 1; $autopkgtest_root_args = ['']; $autopkgtest_opts = ['--apt-upgrade', '--', 'unshare', '--release', '%r', '-- arch', '%a' ]; ## Run piuparts after every build (in a new, clean, chroot). $run_piuparts = 1; $piuparts_root_args = ['PATH=/usr/sbin:/usr/bin', 'unshare', '--pid', '-- fork', '--mount-proc', '--map-root-user', '--map-auto']; $piuparts_opts = ["--basetgz=$HOME/.cache/sbuild/%r-%a.tar.xz", '--no- eatmydata', '--fake-essential-packages=systemd-sysv', '--distribution=%r']; #$piuparts_opts = ['--no-eatmydata', '--fake-essential-packages=systemd-sysv', '--distribution=%r']; #$piuparts_opts = ["--distribution=%SBUILD_DISTRIBUTION", '-- bootstrapcmd=mmdebstrap --skip=check/empty --variant=minbase -- aptopt="Acquire::http { Proxy \"http://127.0.0.1:3142\";; }”’]; > piuparts can reuse a tarball just fine for me and you can also ask it to > use apt-cacher-ng for generating a chroot on demand with: When using the currently uncommented piuparts_opts, I get the failure described earlier in this bug report. If I use the second piuparts_opts that is currently commented, it builds successfully, but generates a new tarball and doesn’t use apt-cacher-ng. > $piuparts_opts = ["--distribution=%SBUILD_DISTRIBUTION", > '--bootstrapcmd=mmdebstrap --skip=check/empty --variant=minbase > --aptopt="Acquire::http { Proxy \"http://127.0.0.1:3142\";; }"']; If I use this option (which I have just added to my .sbuildrc and tested, thank you) it creates a new chroot, which takes a small amount of time, but correctly uses apt-cacher-ng, which saves both bandwidth and time. Given your explanation above about the desirability of using a minimal chroot instead of the full build chroot, I would consider this to be the optimal behavior. My takeaway from this is that it would probably be best to update the wiki with two example piuparts_opts, one which uses --aptopt for those using apt- cacher-ng and one which doesn’t. I would be fine doing so if you like based on the information presented here (would you recommend the examples include --no- eatmydata on unshare or not?) We can then either close this bug report, or you can keep it open if you think Piuparts should be able to build using the pre-generated tarball, even if it is not recommended, and want to figure out why that isn’t working. -- Soren Stoutner [email protected]
signature.asc
Description: This is a digitally signed message part.
