| Patch | Description | Author | Forwarded | Bugs | Origin | Last update |
|---|---|---|---|---|---|---|
| 1539621689.revert.schroot-1.6.10-48-g2600bcab.revert-environment-preserve-empty-values.patch | Revert "environment: Preserve empty values" Upstream commit 2600b ("environment: Preserve empty values") causes the Debian build to fail in the test suite. Revert that change for the time being and investigate later. The failing test: test 2 Start 2: sbuild-chroot-chroot 2: Test command: /<<PKGBUILDDIR>>/debian/build/test/sbuild-chroot-chroot 2: Test timeout computed to be: 10000000 2: .........................Additional environment: CHROOT_BTRFS_SNAPSHOT_NAME= 2: F..........................................................................................Additional environment: CHROOT_LVM_SNAPSHOT_DEVICE= 2: Additional environment: CHROOT_LVM_SNAPSHOT_NAME= 2: F.................. 2: 2: 2: !!!FAILURES!!! 2: Test Results: 2: Run: 133 Failures: 2 Errors: 0 2: 2: 2: 1) test: test_chroot_btrfs_snapshot::test_setup_env (F) line: 412 ./test/test-sbuild-chroot.h 2: assertion failed 2: - Expression: extra.empty() 2: 2: 2: 2) test: test_chroot_lvm_snapshot::test_setup_env (F) line: 412 ./test/test-sbuild-chroot.h 2: assertion failed 2: - Expression: extra.empty() 2: 2: 2/8 Test #2: sbuild-chroot-chroot .............***Failed 0.05 sec |
Christoph Biedl <debian.axhn@manchmal.in-ulm.de> | not-needed | 2022-05-29 | ||
| 1448890714.schroot-1.7.2-72-gbf30a928.setup-d-20copyfiles-canonicalize-destination-path.patch | Setup.d: 20copyfiles: canonicalize destination path When parts of the destination path are symlinks, these symlinks are followed in the context of the host filesystem instead of the context of the chroot filesystem. This patch should fix it. |
no | release/schroot-1.7.2-72-gbf30a928 <https://codeberg.org/shelter/reschroot/commit/bf30a928> | 2015-11-30 | ||
| 1453505583.schroot-1.7.2-72-g11587fd8.etc-setup-d-20copyfiles-replace-dangling-symlink-during-cp.patch | Etc/setup.d/20copyfiles: Replace dangling symlink during cp. #1 Add --remove-destination to the cp calls in etc/setup.d/20copyfiles to fix problems with dangling symlinks. Error message from cp is: cp: not writing through dangling symlink ‘asymlinkfile’ This is useful since /etc/resolv.conf may be a dangling symlink ( which happens if resolvconf is installed in the schroot, or if the schroot uses systemd and /etc/resolv.conf points to the non-existant /run/systemd/resolve/resolv.conf ). Adding --remove-destination fixes this. (cp -f doesn't fix it.) |
no | release/schroot-1.7.2-72-g11587fd8 <https://codeberg.org/shelter/reschroot/commit/11587fd8> | 2016-01-22 | ||
| 1496783678.schroot-1.7.2-127-ga5e5d8d9.fix-bash-completion.patch | Fix bash completion | not-needed | debian | release/schroot-1.7.2-127-ga5e5d8d9 | 2017-06-06 | |
| 1530433671.schroot-1.7.2-129-g00c0a972.cmake-use-soelim-r-option.patch | Cmake: Use soelim -r option While non-portable, it's implemented as a no-op in BSD soelim, and is useful for reproducible builds. |
no | release/schroot-1.7.2-129-g00c0a972 | 2018-07-01 | ||
| 1487872945.schroot-1.7.2-137-g5c36362b.support-copyfiles-installation-into-non-existent-directories.patch | Support copyfiles installation into non-existent directories Trying to copy a file into a non-existent directory is currently fatal, and thus makes the whole schroot invocation fail. This means one cannot unconditionally add files if the chroot is possibly not going to have the containing directory. |
no | release/schroot-1.7.2-137-g5c36362b <https://codeberg.org/shelter/reschroot/commit/5c36362b> | 2017-02-23 | ||
| 1487872999.schroot-1.7.2-138-g5a611c49.support-copyfiles-source-destination-specifications.patch | Support copyfiles <source> <destination> specifications This makes it possible to store local files in the schroot configuration directory that will get installed on the chroot. For example a local policy-rc.d script. |
no | release/schroot-1.7.2-138-g5a611c49 <https://codeberg.org/shelter/reschroot/commit/5a611c49> | 2017-02-23 | ||
| 1662655911.reschroot-1.6.13-2-g779349dc.replace-usage-of-egrep-and-which.patch | Replace usage of egrep and which Debian bug: https://bugs.debian.org/1019295 |
no | release/reschroot-1.6.13-2-g779349dc <https://codeberg.org/shelter/reschroot/commit/779349dc> | 2022-09-08 | ||
| 1662656169.reschroot-1.6.13-3-ga9e100e5.clean-up-mess-created-in-the-portuguese-translations.patch | Clean up mess created in the Portuguese translations Thanks Américo Monteiro <a_monteiro@gmx.com> for sorting things out. Debian bug: https://bugs.debian.org/965348 |
no | release/reschroot-1.6.13-3-ga9e100e5 <https://codeberg.org/shelter/reschroot/commit/a9e100e5> | 2022-09-08 | ||
| 1664011392.reschroot-1.6.13-4-g93017cff.update-french-translation.patch | Update French translation Thanks Martin Quinson <Martin.Quinson@ens-rennes.fr> Debian bug: https://bugs.debian.org/1020255 |
no | release/reschroot-1.6.13-4-g93017cff <https://codeberg.org/shelter/reschroot/commit/93017cff> | 2022-09-24 | ||
| 1665995770.reschroot-1.6.13-5-g81b88b45.document-a-login-shell-might-be-switched-to-a-regular-shell.patch | Document a login shell might be switched to a regular shell Possibly that behaviour can be changed at a later time. Spotted by Sven Brinkmann. |
Christoph Biedl <debian.axhn@manchmal.in-ulm.de> | no | upstream, commit release/reschroot-1.6.13-5-g81b88b45 <https://codeberg.org/shelter/reschroot/commit/81b88b45> | 2022-10-17 | |
| 1692468301.reschroot-1.6.13-6-g271acf6e.subject-mount-a-new-instance-of-dev-pts-in-the-chroot.patch | Subject: Mount a new instance of /dev/pts in the chroot Provided by Simon McVittie <smcv@debian.org>, thanks. This avoids various failure modes when schroot is run inside some other container manager, such as lxc, most commonly manifesting as inability to run programs that create pseudo-terminals such as script(1). Mounting a new instance of devpts is considered to be best-practice for container managers in Linux >= v2.6.29 with CONFIG_DEVPTS_MULTIPLE_INSTANCES=y. That config option was made unconditional in v4.7. This has some assumptions, which cannot be avoided if we are going to mount /dev/pts using schroot's fstab: * If the kernel is older than v4.7, it is assumed to be v2.6.29 or later with CONFIG_DEVPTS_MULTIPLE_INSTANCES=y. Users of older kernels, or intermediate versions with CONFIG_DEVPTS_MULTIPLE_INSTANCES=n, can revert this change via /etc. * gid 5 must be the right owner for ptys. This is correct for Debian (it's the hard-coded tty group specified in base-passwd) and probably many other distributions (it's systemd's configure-time default) but not necessarily correct everywhere. However, if the host system and the chroot disagree on the right gid, schroot's previous behaviour would have been wrong anyway, because it bind-mounted the host's /dev/pts. * /dev/ptmx inside the chroot must be either a real device node (as created by debootstrap < 1.0.76, and debootstrap >= 1.0.89 if possible) or a symlink to pts/ptmx (as created by debootstrap between 1.0.76 and 1.0.88 inclusive, and by debootstrap >= 1.0.89 if run in a container whose seccomp rules do not allow it to create the device node, such as systemd-nspawn). Bind-mounting /dev/pts/ptmx over /dev/ptmx, so that we get the new instance's /dev/ptmx equivalent instead of the host's, can only be done from code, so I have done it in the 10mount hook instead of in the fstab. To keep the host system terminal on which we were invoked (which might itself be a pty, from a different instance of /dev/pts) available to the chroot, bind-mount it onto /dev/console. This is the same trick used in the lxc and systemd-nspawn Linux container managers. Bug-Debian: https://bugs.debian.org/856877 Bug-Debian: https://bugs.debian.org/983423 Signed-off-by: Simon McVittie <smcv@debian.org> |
Christoph Biedl <debian.axhn@manchmal.in-ulm.de> | no | upstream, commit release/reschroot-1.6.13-6-g271acf6e <https://codeberg.org/shelter/reschroot/commit/271acf6e> | 2023-08-19 | |
| 1664222056.reschroot-1.6.13-9-g55af32cf.fix-localename-type.patch | Fix localename type Needs to be a string. Fixes error: ``` /var/tmp/portage/dev-util/schroot-1.6.10_p7/work/schroot-1.6.10/sbuild/sbuild-basic-keyfile.tcc:217:18: error: no viable overloaded '=' localename = std::locale::classic(); ~~~~~~~~~~ ^ ~~~~~~~~~~~~~~~~~~~~~~ /usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/include/g++-v10/bits/basic_string.h:665:7: note: candidate function not viable: no known conversion from 'const std::locale' to 'const std::__cxx11::basic_string<char>' for 1st argument operator=(const basic_string& __str) ^ [...] ``` Bug: https://bugs.gentoo.org/739034 Signed-off-by: Sam James <sam@gentoo.org> |
Sam James <sam@gentoo.org> | no | debian | upstream, commit release/reschroot-1.6.13-9-g55af32cf <https://codeberg.org/shelter/reschroot/commit/55af32cf> | 2022-09-26 |
| 1658716738.reschroot-1.6.12-2-g2045008e.fix-variable-usage-in-copyfiles-copy-file-function.patch | Fix variable usage in copyfiles copy_file() function <https://codeberg.org/shelter/reschroot/commit/2045008e614229fffeca4b1a3f8915c8bb7bdebc> The function was using $file to refer to the source file of the copy, instead of $1. This happens to currently work because in shell the function has access to the global variables defined from the call site, but this makes it dependent on the global state and the call site semantics. If these variables change name then this specific code will stop working, which will be the case with the upcoming source and optional destination specification in copyfiles. |
no | release/reschroot-1.6.12-2-g2045008e | 2022-07-25 | ||
| fix-dupes-in-buildd-configuration.patch | Fix dupes in buildd configuration The files /etc/schroot/buildd/copyfiles /etc/schroot/buildd/nssdatabases contain duplicated information. This was possibly introduced in 2011, in commit d7dad336 ("etc: Add buildd profile-template from sbuild"). |
Christoph Biedl <debian.axhn@manchmal.in-ulm.de> | invalid | 2022-09-28 | ||
| fix-example-configuration.patch | Fix example configuration | Christoph Biedl <debian.axhn@manchmal.in-ulm.de> | invalid | debian | 2022-10-14 | |
| setup.d-10mount-Don-t-assume-we-can-mknod-dev-console.patch | setup.d/10mount: Don't assume we can mknod /dev/console By default, systemd-nspawn containers run with CAP_MKNOD, but with a seccomp profile that prevents creation of device nodes other than the basics (and in particular preventing creation of char device 5,1, conventionally /dev/console). If we cannot create the usual device node for /dev/console as a mount point onto which to mount the terminal from which schroot was invoked, then we need to fall back to creating it as some other non-directory, non-symlink inode that can act as a mount point. An empty regular file will do. |
Simon McVittie <smcv@debian.org> | no | debian | 2024-08-20 | |
| setup.d-10mount-Don-t-bind-mount-dev-pts-ptmx-onto-dev-pt.patch | setup.d/10mount: Don't bind-mount /dev/pts/ptmx onto /dev/ptmx If /dev/pts is a new instance of devpts with ptmxmode=666, as it is since commit 271acf6e "Subject: Mount a new instance of /dev/pts in the chroot", then it's safe to bind-mount /dev/pts/ptmx onto /dev/ptmx because we explicitly make its mode 0666. However, if an old conffile has been kept or overwritten by configuration management (as on debian-ports buildds), or if a profile has been explicitly configured to bind-mount the host's /dev/pts in preference to using a new instance, then it is not safe to bind-mount the host's /dev/pts/ptmx onto /dev/ptmx, because the host's /dev/pts/ptmx will often have permissions 000 for reasons that are not clear to me. With recent-ish kernels (v4.7+, with commit eedf265a "devpts: Make each mount of devpts an independent filesystem" included), this bind-mount becomes unnecessary, because the kernel automatically redirects actions on /dev/ptmx to work with an adjacent devpts mount. It was included in my 2017 patch to accommodate older kernels like the one in Debian 8 'jessie', but is unnecessary if we can assume a Debian 9 'stretch' or later kernel. |
Simon McVittie <smcv@debian.org> | no | debian | 2024-08-20 |