Hello,

On Sat 23 Nov 2024 at 10:20pm +01, Philipp Kern wrote:

sbuild chroot manager for unshare backend users -----------------------------------------------

After installing sbuild 0.87.0 or later from unstable, you can now build
packages without any additional setup. With an empty ~/.sbuildrc and
with no chroot tarballs in ~/.cache/sbuild, just run this to build the
"hello" source package:

sbuild --chroot-mode=unshare --dist=unstable hello

To keep the dynamically created chroot tarball for subsequent builds, you
can make this configuration permanent by putting this into your
~/.sbuildrc:

$chroot_mode = 'unshare';

$unshare_mmdebstrap_keep_tarball = 1;

Whenever a chroot tarball doesn't exist yet, or whenever an existing
tarball is too old, sbuild will take care of creating one for you
automatically. If you want to customize the contents of the tarballs
sbuild creates, read the documentation of UNSHARE_MMDEBSTRAP_EXTRA_ARGS
in sbuild.conf(5).

The new chroot management functionality is marked as experimental and any
feedback is very much appreciated.

-- Johannes Schauer Marin Rodrigues

This is interesting. One concern I have is speed -- isn't it always
slower to have to unpack a tarball before the build instead of having a
chroot under /srv/chroot that's always unpacked?

Thanks.

--
Sean Whitton

--=-=-Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQJNBAEBCgA3FiEEm5FwB64DDjbk/CSLaVt65L8GYkAFAmdCcfwZHHNwd2hpdHRv bkBzcHdoaXR0b24ubmFtZQAKCRBpW3rkvwZiQAA/D/94yaf/773blmliBCVhGobP cK2CgltroKsYuRt20zhvTAr0p7G9TSIko6PgZmlXMyF3EUX4hBmtVupIhanfQLZX XoTQ/ssIVqTS9nlT087eom+esI/s6Fi1qbBiHD6BXQbsXb0LCKEz6iv0XI2uYeCQ 4DjPq99teK3FqqLWKp+ZKoWZwWQrtM/nhQxInsF0TQjL4B44KtyV6vWIOAretEoJ lq6U6OFuTTYSOPha4/UsDeE0fJ7JgDMzFTebxgYUYwDcw96h00tuHBW6Xol+oEc4 f1avmlRqQqvHqz0O4OQDmoSPsbzQSN8b11504Er6M2hflS1ZXcgWrskP7LsMl6C6 ScTg9S6g1OxwcMxNPc6hez+mYOl3Rn5gpowpdb6v4uXNhr7U+ce47+cquXZJxkAB fV10EudfhRCgJNq0KQgmor9EhPwNeIHVVW1jM7ZBaLqqL0bCqYscXy6fn0Dm8g6a 6TPEIaeyran5cwhMh2VNHZtcv5JeTB63ES0C7duDfL5mdVGpKb9zECZpGTDOKUhK uidIqj9rQknLf/CCGtGYgyixsL7QDaEj99vgWtPYTHr4s++1c2CUV+Az9KeP+cbP P6F/KDmOyDjSE/cK6f8gs812TgU6KSbrFlurNVr2EECpbQ/i5GS/TtfxxdRJEwQL jFn7EV2ZYhXaHsSoYteNHA==RQ+d
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Us

Hi,

Quoting Sean Whitton (2024-11-24 01:23:24)

This is interesting. One concern I have is speed -- isn't it always slower to have to unpack a tarball before the build instead of having a chroot under /srv/chroot that's always unpacked?

that is correct. Unpacking a tarball takes time. Having an already unpacked directory present will be faster. Lets look at how slow unpacking a buildd chroot tarball is in practice. My machine is an ARM Cortex A73 with 3.6 GB RAM.

$ time sudo tar -C chroot -xf ~/.cache/sbuild/unstable-arm64.tar
sudo tar -C chroot -xf ~/.cache/sbuild/unstable-arm64.tar 0.01s user 0.02s system 2% cpu 0.983 total

This number will of course be different on your system. If your system is slower than mine or if your chroot tarballs contain a lot more pre-built packages, then unpack times will be longer than this.

In principle, unshare mode can also work with directories. Helmut is working
on something in that direction. But for me personally, one second of unpack time is not enough of a motivation for me to put time into directory+overlayfs support. But of course patches welcome!

Thanks!

cheers, josch
--==============i50045674091688174=MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Description: signature
Content-Type: application/pgp-signature; name="signature.asc"; charset="us-ascii"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEElFhU6KL81LF4wVq58sulx4+9g+EFAmdCzWoACgkQ8sulx4+9 g+FWMw/9GFseMEHY2tEL1G8Ts6dopFI4RSbpfS9P6+3vUH5aWivsdEw/cuC0LA02 35+uRqCImFEeQwxIBLbKmbQ73UUnm45eOVjrTrFiWZsOQzukr4wExYCSXkGq826l sfR0pMOG77dMbLmY57LtazP6MIrQieMBhqauljCxSqKxL0EehoqtzGWJ/OiMS+DK we24u7ebOBgFe4NBcOqqFTPsmWs4vDSLPFoGvbYoSau3LavwtTPAbB0dAZDf9taM 5nGmgZIO7AQcR8TGtzuySx8caKkb2E7hosAGVFwUxoQoTlojY8PZ7YN3sC7T6PT9 Nll19tvjAbId1Ir3/y7cIgKyc9AHASilSKM2786foKa0ZZOysA9sXCOGk2hjzqGH poDuN9mLMAqr0AIQfbdK3tidSmgO9yf/ZsiC/NLObyB3SsvtN8LUHBVsDqOJcgIt JtWb1tb1yoLrUIeDqnIEomii9Lsq8sZWys3SgR9cgCGYM0ZSu9fY9NmCX5Ho4vnV kypfH7BSNGEJzq0XLm9Oc46MV3sOsY3xM6o75580Y0qLxZtfTJTjdkJ+gcLStvWZ jEF2qa1lCgthx6Q1Ty+1NeLzyJimWDQpUTqHaFk7A+458zqkYv6bD4Y27Y/U/OWq d0OfBD/xpSkmhWNXFESoRJwC1Sd0Zsi59GYZOtStVA6FD16FCIQ=
=K8k6
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Nov 24, Sean Whitton <spwhitton@spwhitton.name> wrote:

This is interesting. One concern I have is speed -- isn't it always
slower to have to unpack a tarball before the build instead of having a chroot under /srv/chroot that's always unpacked?

People who feel this is a problem can try my super fast fork of pbuilder
with overlayfs support:

https://salsa.debian.org/md/pbuilder/-/commits/overlayfs/

--
ciao,
Marco

-----BEGIN PGP SIGNATURE-----

iHUEABYIAB0WIQQnKUXNg20437dCfobLPsM64d7XgQUCZ0L2BQAKCRDLPsM64d7X gbxMAP4slsD6JfBz2znVc33NiNNv7C4glnfW6bzoD612yif3+AEAvgss9KMinjzk +mf3kPMm48cG3ANKhf6dj2NsoNvYxQw=
=GJ6U
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hello,

On Sun 24 Nov 2024 at 07:53am +01, Johannes Schauer Marin Rodrigues wrote:

Hi,

Quoting Sean Whitton (2024-11-24 01:23:24)

This is interesting. One concern I have is speed -- isn't it always slower >> to have to unpack a tarball before the build instead of having a chroot under
/srv/chroot that's always unpacked?

that is correct. Unpacking a tarball takes time. Having an already unpacked directory present will be faster. Lets look at how slow unpacking a buildd chroot tarball is in practice. My machine is an ARM Cortex A73 with 3.6 GB RAM.

$ time sudo tar -C chroot -xf ~/.cache/sbuild/unstable-arm64.tar
sudo tar -C chroot -xf ~/.cache/sbuild/unstable-arm64.tar 0.01s user 0.02s system 2% cpu 0.983 total

This number will of course be different on your system. If your system is slower than mine or if your chroot tarballs contain a lot more pre-built packages, then unpack times will be longer than this.

In principle, unshare mode can also work with directories. Helmut is working on something in that direction. But for me personally, one second of unpack time is not enough of a motivation for me to put time into directory+overlayfs
support. But of course patches welcome!

Yes, one second is not that bad at all. It takes longer than that on
the porterboxes, and that is my most recent experience, so I was
thinking of that. Thanks for the timings.

--
Sean Whitton

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi,

On 2024-11-24 08:23, Sean Whitton wrote:

This is interesting. One concern I have is speed -- isn't it always
slower to have to unpack a tarball before the build instead of having a chroot under /srv/chroot that's always unpacked?

Other than the speed of tarball unpacking, which as Johannes showed
isn't that much of a concern, one feature of schroot I'd been using is in-memory union overlays, something like:

type=directory
directory=/srv/chroots/sid-arm64
union-type=overlay
union-overlay-directory=/dev/shm/

Writing to memory instead of disk during the build process improves
performance significantly. The equivalent in a sbuild+unshare world on
Bookworm seems to be:

$unshare_tmpdir_template = '/dev/shm/tmp.sbuild.XXXXXXXXXX';

In Trixie /tmp is a tmpfs by default so no config needed at all?

I'm moving my setups to sbuild+unshare, thanks josch for your great
work.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

* Soren Stoutner <soren@debian.org> [241125 18:30]:

In principle, unshare mode can also work with directories. Helmut is

working

on something in that direction. But for me personally, one second of

unpack

time is not enough of a motivation for me to put time into directory+overlayfs support. But of course patches welcome!

Yes, one second is not that bad at all. It takes longer than that on
the porterboxes, and that is my most recent experience, so I was
thinking of that. Thanks for the timings.

I haven’t had time to do any analysis myself, but there is some information posted on https://wiki.debian.org/sbuild:

You can use choose the compression algorithm for the tarball by specifying the extension (.tar.xz, .tar.gz or plain .tar, etc). As of May 2024, ZST seems

to provide the best size/time ratio. It certainly is the fastest on a Dell Precision 3800M, 16GB RAM, on an SSD drive (a computer from early 2015):

Format Tarball size Time

.xz ~100MB 179,60s user 7,09s system 75% cpu 4:07,49 total
.gz ~150MB 38,51s user 6,13s system 83% cpu 53,423 total
.zst ~139MB 22,68s user 6,28s system 74% cpu 38,868 total

IIRC these times are for tarball creation (incl. downloading and
apt). Unpacking is AFAICT a lot faster in many cases. Locally it
feels like <1s.

Chris

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Monday, November 25, 2024 10:37:39 AM MST Chris Hofstaedtler wrote:

the extension (.tar.xz, .tar.gz or plain .tar, etc). As of May 2024, ZST seems to provide the best size/time ratio. It certainly is the fastest on

a

Dell>
Precision 3800M, 16GB RAM, on an SSD drive (a computer from early 2015): >Format Tarball size Time

.xz ~100MB 179,60s user 7,09s system 75% cpu 4:07,49 total
.gz ~150MB 38,51s user 6,13s system 83% cpu 53,423 total
.zst ~139MB 22,68s user 6,28s system 74% cpu 38,868 total

IIRC these times are for tarball creation (incl. downloading and
apt). Unpacking is AFAICT a lot faster in many cases. Locally it
feels like <1s.

Thanks. I see I misunderstood what was being stated on the website.

--
Soren Stoutner
soren@debian.org
-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEJKVN2yNUZnlcqOI+wufLJ66wtgMFAmdEtn4ACgkQwufLJ66w tgPlQA//cSIgiCvFGa5d60Rgw3r5S8jLiXdkMHjVjHqEMMgOA5pjTENONinJ/sma JZ4HZnUMREsizmOVVwNpOsTTuaHfERChr4H0DE0QXY8Aof7XVp1VDs14Di3UOGfo 3Zu8BzQiFkcgwZfp3wL8cLuYVPOjkh2zFRruK1YFNH+SX5Ssns5tUP6C7rXk69Ps +qqQR70i2F08MdgZYgFz/HHFc0MVHW3funUqHwKoxe53E3/Yia1bvLoREi4miZsk VLBo0ah2WWeFBbHwxyipeFZ4LBzn/llyqVsc9au4st8crd4a1fYqYSbBcZ4iVoNq N9m+WqxqlWroyhGlY4OKliQcXPRvX1MqeUBBr7yjNVwCTAmweanE+aL5ikZGM+ZI JETDjnSXpDIRh2VyksrajQWlycy1gWiGg/9G3I+v904YUToGskNoZWIoZ/SgOhKZ POFU+OOLB6eTvWU+ezXgCrORHG/DcqrQVNJzWuxdBNd2g3WPNNyigfLZVdOpgiOS Xbl4XrcBE2EVWACOcc414hFplqxZi82CSAbIko59BwzWQ9pj53NOXUiEdi4do4/o PvpsVEAylxiuQctOvZ+DlUOQU5tpj0xuRpw3zOhjlxV8HWcUsL7PZb9AriAhx9SZ 2epiRvoktQUXDNkEZ2BMaQrykqocsz9RrAaPMpTwf6Kc7hNOSSE=
=y8Eb
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sunday, November 24, 2024 7:06:06 PM MST Sean Whitton wrote:

On Sun 24 Nov 2024 at 07:53am +01, Johannes Schauer Marin Rodrigues wrote:

Hi,

Quoting Sean Whitton (2024-11-24 01:23:24)

This is interesting. One concern I have is speed -- isn't it always

slower

to have to unpack a tarball before the build instead of having a chroot
under
/srv/chroot that's always unpacked?

that is correct. Unpacking a tarball takes time. Having an already

unpacked

directory present will be faster. Lets look at how slow unpacking a buildd chroot tarball is in practice. My machine is an ARM Cortex A73 with 3.6 GB RAM.

$ time sudo tar -C chroot -xf ~/.cache/sbuild/unstable-arm64.tar
sudo tar -C chroot -xf ~/.cache/sbuild/unstable-arm64.tar 0.01s user

0.02s

system 2% cpu 0.983 total

This number will of course be different on your system. If your system is slower than mine or if your chroot tarballs contain a lot more pre-built packages, then unpack times will be longer than this.

In principle, unshare mode can also work with directories. Helmut is

working

on something in that direction. But for me personally, one second of

unpack

time is not enough of a motivation for me to put time into directory+overlayfs support. But of course patches welcome!

Yes, one second is not that bad at all. It takes longer than that on
the porterboxes, and that is my most recent experience, so I was
thinking of that. Thanks for the timings.

I haven’t had time to do any analysis myself, but there is some information posted on https://wiki.debian.org/sbuild:

You can use choose the compression algorithm for the tarball by specifying the extension (.tar.xz, .tar.gz or plain .tar, etc). As of May 2024, ZST seems to provide the best size/time ratio. It certainly is the fastest on a Dell Precision 3800M, 16GB RAM, on an SSD drive (a computer from early 2015):

Format Tarball size Time

.xz ~100MB 179,60s user 7,09s system 75% cpu 4:07,49 total
.gz ~150MB 38,51s user 6,13s system 83% cpu 53,423 total
.zst ~139MB 22,68s user 6,28s system 74% cpu 38,868 total

So, more than 1 second, but 22 seconds with .zst doesn’t feel too bad.

--
Soren Stoutner
soren@debian.org
-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEJKVN2yNUZnlcqOI+wufLJ66wtgMFAmdEs/gACgkQwufLJ66w tgNMow/+KJDBioLt91r+VGTcxc+RVH6dKAYD0oIAlgvI7kxYg5iUIl/q87dGlFrt lGYVn/ydmwSXbzEBzkRrL8Zt282E20Frz8TQxk287QcNycgBFdg0NUAYUDGcbpw4 gjnzLJgK3kWq12vX4PhE5M6iwuO5EyFeRK8vACUPCu9TZMayiISoPVUQlfHk3TjJ Fzm1V55tYRZfkEuyAo3Vo1l5qgAIC0I/RnUgzR89cS33wGXhGNhhfneE7wA83kgM Feglad4g3ZYwJCOJEFzTwArqo/1GiZ03b5vAqvHXcP+C1iI+anhEdvwlp6zFgMTe +2s6KgxxZS0z0U0k3uOh5RePyxumEHBwe5ywAETa5gtUmZv3xw4IN4xJgfSEc1DD 54XDXWcEvP0I0i2gmgGIqYF0tk9dh0+McPj+JBv/ShxVIOcsxcfsvGjQuhZ3Jebd PQLZXlB8dH5K+AKzGenIL4SaEf0h1L9GDfcBMAU05fcFirhzGQ5KFMLo/3WMTINq a9I+mgHAuTNX3q1EBtLJ3QUDb9GDIG0W5PI4ZYPhWTwE2RmArz9/AH+0LwFQ380V vKlzbqz9jp3vuMGDKtqflXSh5AoeEvUvz5AFuvfBFLUSgvmPIqgvtDMVrLuiP4Dc 1IqxYVsKOBVpxu+gZWVVQW05CB2Xnhjptg1SNsUDvffpuzwYV2Q=
=ypWN
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Monday, November 25, 2024 4:57:50 PM MST Soren Stoutner wrote:

On Saturday, November 23, 2024 2:20:45 PM MST Philipp Kern wrote:

The news are collected on https://wiki.debian.org/DeveloperNews
Please contribute short news about your work/plans/subproject.

In this issue:
+ Debian buildds are using sbuild with unshare now
+ sbuild chroot manager for unshare backend users
+ Building packages with make --shuffle
+ debian.org: Support for Security Key-backed SSH keys

Debian buildds are using sbuild with unshare now ------------------------------------------------

The wanna-build team switched all buildds to the sbuild unshare backend
for trixie/sid/experimental plus *-backports. This means that official
Debian builds now run as non-root user and rely on user namespaces
instead of schroot. In addition this blocks any network access during
the build as per Debian policy 4.9.

Prior to the switch Santiago Vila did test rebuilds of all packages and
bugs have been filed:

https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=unshare;users=debian-wb-t
ea

m@lists.debian.org

Help is welcome to fix the remaining bugs.

We recommend all developers to use sbuild with unshare as well.
Notes on how to set it up as well as hints for custom usage are collected
on the Wiki:

https://wiki.debian.org/sbuild

I am not able to get the example unshare .sbuildrc to work with piuparts.

0m0.0s DEBUG: Unpacking /home/soren/.cache/sbuild/unstable-amd64.tar.xz into

/

tmp/tmplbhnn26l
0m0.0s DEBUG: Starting command: ['tar', '-C', '/tmp/tmplbhnn26l', '--auto- compress', '-xf', '/home/soren/.cache/sbuild/unstable-amd64.tar.xz']
0m0.5s DUMP:
tar: ./dev/console: Cannot mknod: Operation not permitted
tar: ./dev/full: Cannot mknod: Operation not permitted
tar: ./dev/null: Cannot mknod: Operation not permitted
tar: ./dev/ptmx: Cannot mknod: Operation not permitted
tar: ./dev/random: Cannot mknod: Operation not permitted
tar: ./dev/tty: Cannot mknod: Operation not permitted
tar: ./dev/urandom: Cannot mknod: Operation not permitted
tar: ./dev/zero: Cannot mknod: Operation not permitted
tar: Exiting with failure status due to previous errors

Does anyone have any pointers as to the root of the problem?

I suppose I should note that I have made a few modifications to the example file
because it wasn’t behaving as expected. Specifically, I disabled the mmdebstgrap auto create because otherwise it was ignoring the tarball I had created in the previous steps (including the apt-cacher-ng setting) and creating a new tarball pulling straight from the internet at each build, at each run of lintian, and at each run of piuparts. I also had to specify the distribution or things didn’t work when building against a changelog that targeting UNRELEASED.

Piuparts is fine if I let it generate its own tarball on each run. But it doesn’t like using the tarball previously created.


# 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';

# Use an existing tarball instead of creating one each time. $unshare_mmdebstrap_auto_create = 0;

## run lintian after every build (in the same chroot as the build): use --no- run-lintian to override
$run_lintian = 1;
# pass any lintian options
$lintian_opts=['--info', '--display-info', '--verbose', '--fail- on','error,warning'];

## run autopkgtest after every build (in a new, clean, chroot): use --no-run- autopkgtest to override
$run_autopkgtest = 1;
# use 'unshare' for autopkgtests
$autopkgtest_root_args = [''];
$autopkgtest_opts = ['--apt-upgrade', '--', 'unshare', '--release', '%r', '-- arch', '%a' ];

## run piuparts after every build (in a new, clean, chroot): use --no-run- piuparts to override
# this does not work in bookworm
$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'];

--
Soren Stoutner
soren@debian.org
-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEJKVN2yNUZnlcqOI+wufLJ66wtgMFAmdFESoACgkQwufLJ66w tgPSqhAAr+GAOXRFAVmcuMtpHrTnr+/ku67KEs5K/tQlCkLlJdZXEW5Qh4HGXSID dUO+sA1gDIxJK9CuyGkEw6brVa4PvVz8sjpu61Zf7uK36b9aVduiyXTn3P7IoJUT MnXxeZ46pvKwTtHaEiPhesFFrWQgXrbKQA+iLVaPbNcgwVPChpPIUjSCNs+oqh/x oMLT9j+gkFvuvOXJs7qzOi6QdNbttfUyRUxw0+V6+qL3vz/6CKIAPls+YZHvxSXm sCDGL3/4xR9RM2nHVWMkTGC7pKNuZlL3OhdxynMwA1nxgW5i/qkFoTllluDM0Vv9 1t/2R2qxhoylpuctbq6APpDMLZ71d37QZk3b3uo1rkIGbFzrvA798aKjjeNzIejQ ZiRH4Dse6e+mtNnR26qbx5wCBMggoU25c6xJnz8YKL+9IxjiamPBwrCPzqMs2EJa 2rigm1jDDalfGk9xdvIySqar5pJf4iw0YRiSWfRH49VSTGmcNg1mODDZpjdO1oIZ lpIyXRTbUD5UrcxQBladlLGsmKDoybZi81w+GcpR5+KIPgn4sBzeNkyfMNE258dy ZA4zCvlxRmnhiIT5acI0uxIPEhWsR1Pk82MELcg4gSjj91XsKVOCq2UHY1Dr4vkr IxQGUk7RmYgS+vChha/VEUEU+vsBuR5RnLmPjhtCbFbQBVFU5SM=
=zXp3
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Saturday, November 23, 2024 2:20:45 PM MST Philipp Kern wrote:

The news are collected on https://wiki.debian.org/DeveloperNews
Please contribute short news about your work/plans/subproject.

In this issue:

+ Debian buildds are using sbuild with unshare now
+ sbuild chroot manager for unshare backend users
+ Building packages with make --shuffle
+ debian.org: Support for Security Key-backed SSH keys

Debian buildds are using sbuild with unshare now ------------------------------------------------

The wanna-build team switched all buildds to the sbuild unshare backend
for trixie/sid/experimental plus *-backports. This means that official
Debian builds now run as non-root user and rely on user namespaces
instead of schroot. In addition this blocks any network access during
the build as per Debian policy 4.9.

Prior to the switch Santiago Vila did test rebuilds of all packages and
bugs have been filed:

https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=unshare;users=debian-wb-tea
m@lists.debian.org

Help is welcome to fix the remaining bugs.

We recommend all developers to use sbuild with unshare as well.
Notes on how to set it up as well as hints for custom usage are collected
on the Wiki:

https://wiki.debian.org/sbuild

I am not able to get the example unshare .sbuildrc to work with piuparts.

0m0.0s DEBUG: Unpacking /home/soren/.cache/sbuild/unstable-amd64.tar.xz into / tmp/tmplbhnn26l
0m0.0s DEBUG: Starting command: ['tar', '-C', '/tmp/tmplbhnn26l', '--auto- compress', '-xf', '/home/soren/.cache/sbuild/unstable-amd64.tar.xz']
0m0.5s DUMP:
tar: ./dev/console: Cannot mknod: Operation not permitted
tar: ./dev/full: Cannot mknod: Operation not permitted
tar: ./dev/null: Cannot mknod: Operation not permitted
tar: ./dev/ptmx: Cannot mknod: Operation not permitted
tar: ./dev/random: Cannot mknod: Operation not permitted
tar: ./dev/tty: Cannot mknod: Operation not permitted
tar: ./dev/urandom: Cannot mknod: Operation not permitted
tar: ./dev/zero: Cannot mknod: Operation not permitted
tar: Exiting with failure status due to previous errors

Does anyone have any pointers as to the root of the problem?

--
Soren Stoutner
soren@debian.org
-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEJKVN2yNUZnlcqOI+wufLJ66wtgMFAmdFDv4ACgkQwufLJ66w tgM7rA/+La79nB1q/R129Hd/NG9zx8ea/CeT9Za1IG043DRW5dLqlCCrVax5TdFF 1KZK8+iq2DAwl6AQiz1fZo0cq7swRZK97T8pQ+L2VXZE0sTeSn9vXqOJhSSlL0Tj rigP8PHO28vUNLoNaUJ+F7ei63H6UM1fLZqS9omly2u0Qjuo18sJCQAm9cx6BfZp DdQG3127jCtNTIuBJEGiuozGgL1LosQ3kCGWmdmvsolP+IoKqzN6upqgFm7wzdGx u2kSmqfo4H+L0eE1+p0v0MBYqY4ibvvmL84cg47YHUsYQae07nxMt/NObHACZyVv aAkHpxXPLH15rhP7uZSmxhnauhMO3cZv1H+KntYVEseykTS32dNh3ed4+u+5C3mv KxRE2VICa6pRIkb7fFYH+Gzweg770AdSZPn2BFL2VFL6jIRqdizb+6E9tb2dHuh9 GcWSGHUr/Ug485p3OOBkN+oV9zJfhISb3+ExzdxzV7gCFQJHlO/nsJ+u/B4DOhsg dfyOIs+7sI2ek05FNsKPpIcDT5SkhKqBFgVysL71cCEjtTYGmt325dzphQlV60Pr 9ikAdPrrtwfQ4E1RuvyEb0Yp3TNwcvDCa21Cynm4IrhEAlYel5zmB3WVDGgdT6hq inzsHxv1GNHazQH3q6JYqnbyZvJekSHmNMlAdpqlwgSItoW32Uo=
=+7Xb
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi,

Quoting Soren Stoutner (2024-11-26 01:07:06)

I suppose I should note that I have made a few modifications to the example file because it wasn’t behaving as expected. Specifically, I disabled the mmdebstgrap auto create because otherwise it was ignoring the tarball I had created in the previous steps (including the apt-cacher-ng setting) and creating a new tarball pulling straight from the internet at each build, at each run of lintian, and at each run of piuparts.

please report a bug about this. This should not happen. It's easier to get to the bottom of this in a bug on the BTS than on d-devel. :)

I also had to specify the distribution or things didn’t work when building against a changelog that targeting UNRELEASED.

That should also not happen. At least it works fine for me... If you open a bug or write me a private mail we can hopefully figure out how our setups differ.

Piuparts is fine if I let it generate its own tarball on each run. But it doesn’t like using the tarball previously created.

Jochen is the sbuild+piuparts expert and probably has some input on this. :)

# Specify the distribution, -d
$distribution = 'unstable';

Setting this will override the Distribution of the .changes file created by sbuild with "unstable", ignoring what your package has set. Are you sure you want this?

Thanks!

cheers, josch
--==============U29613373396236771=MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Description: signature
Content-Type: application/pgp-signature; name="signature.asc"; charset="us-ascii"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEElFhU6KL81LF4wVq58sulx4+9g+EFAmdFbK4ACgkQ8sulx4+9 g+F88A/9FvXuZwrbHLAv5pfnZmswjmhkX3z5JuMX+cuLT4SaTvi5CHzGBI4ZZUEE Log/ROUGpO71+hB8mWn0LlOttNWGGwwIeIwZDGov4/CXpjHZp/Ky44gRBeL33pQ+ CpOp977uwJ8Zkk8yQUhAs5hNhsMrMTBZhBriOD7H0SqyRm9q1YQ7MxlEadbCdXjL G3QMBIfwKGmwLyBYHcGmmsjW5y1r56ahb4jFe1crY9x5ySiXYUf/CEItQ4tt9KD2 LZDUhhoV9g2KMYM0iG9Dbvdfa6PKYKEy6co8SUE6UdctcqVrO2mx5lcttHhxaAhw Fagw7sFcclVy6wbgCuEUaZyY4RUHw0EtMSBs2stQ8FYFRM5upteSSuhBFBvJQOk1 sGO5/9otzZr8fzzfhPWHeO5RyycWo5O6Ts1RylSF/YxnSsewf8P3QU4VZJixD+KZ ur+RKn4odggGFVsqCD6X6PFO02mVaLzCmEf8cutS9VM9X04ZibDCpzTVjx6qK27C UfGnn4P5G7mFTgTznSclTgiP3i7LNgGsw8Zir+tOTeXSvbCU9R349Lm9mg4NhQhZ U5C2Rg3dTnfhEEAXIRY+1IEbnkXmF4K+fnUBClRKtEJKrG9sbuJjn89tB1PFmUWJ vup6tf7mdki23tZa8xI/SUmvprg57thDWtJZqKDZBQKmCSIX1SI=
=eUmj
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Soren,

* Soren Stoutner <soren@debian.org> [2024-11-25 16:57]:

I am not able to get the example unshare .sbuildrc to work with piuparts.

0m0.0s DEBUG: Unpacking /home/soren/.cache/sbuild/unstable-amd64.tar.xz into / >tmp/tmplbhnn26l
0m0.0s DEBUG: Starting command: ['tar', '-C', '/tmp/tmplbhnn26l', '--auto- >compress', '-xf', '/home/soren/.cache/sbuild/unstable-amd64.tar.xz']
0m0.5s DUMP:
tar: ./dev/console: Cannot mknod: Operation not permitted
tar: ./dev/full: Cannot mknod: Operation not permitted
tar: ./dev/null: Cannot mknod: Operation not permitted
tar: ./dev/ptmx: Cannot mknod: Operation not permitted
tar: ./dev/random: Cannot mknod: Operation not permitted
tar: ./dev/tty: Cannot mknod: Operation not permitted
tar: ./dev/urandom: Cannot mknod: Operation not permitted
tar: ./dev/zero: Cannot mknod: Operation not permitted
tar: Exiting with failure status due to previous errors

Does anyone have any pointers as to the root of the problem?

Which version of piuparts did you use?

How did you create the unstable-amd64.tar.xz?

Can you paste the complete piuparts command line as in the sbuild log?

Thanks

Jochen

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEc7KZy9TurdzAF+h6W//cwljmlDMFAmdFoEUACgkQW//cwljm lDPajRAAmJxn++5wzqCaI7hs8Y6qITBBtBbkkI7yyN82ZTcVC7tUgEkF6j0ldpK4 TppMuuiOxEZoE5gHyx9ZFWBQlsR2eGxcYqmLfCj+3zhf8I1I6Itnao5UoN5uu6kg 4zn/1/szNRToCZk37lUejHQqUo/uz6ZkshQ1Q1vWicL+9PyHCCRIRpk5GGWJ3yJh mugMoHV0VBPJw7bGHX6C/HOELEu8cDUmG0DQnEOs5nWY+ob+ZY+GE+s5ELPgR5+u UHOdORfPPz2zLAoGUb4O+TnhODlSFoVwzyoZAutC3UfW8ApNrf78oCuF8KcvQjY6 caz02qc12JKWI5wIU6JlRRw5NHHpOwQBBHgaB36Dc2ip2HmiIwFUTG37ayGxmrk0 wgoNnfn0vheWOjiaQsQdD02VBLJlCPgKG1wcA9z827n0+JnvCHVwV5MNvrh/IEUr RcB1zVMEXsbquCIyNFXdS/KEFeGGzED9ZbVPxmAA3BIuCJm9klWISO6PInqrO4vI DLwm2zm3cei8zbVgTZFevmuJZarCHACADiP90OWv6pBEeruRyN3i8c/oZqwIbc/7 Fra9R7KQEAgPBtdl9+Pq5tuwZXXs1la6ht4IFUbc30XaF8sbbBdHpLFlksMdR0mh 7iRm80kY5rxLQOwToLC+ej5jH5u920pPHq6/xgvnqQChGWJHLSA=
=VPsj
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tuesday, November 26, 2024 12:23:00 PM MST Soren Stoutner wrote:

On Tuesday, November 26, 2024 3:17:45 AM MST Jochen Sprickerhof wrote:

Hi Soren,

* Soren Stoutner <soren@debian.org> [2024-11-25 16:57]:

I am not able to get the example unshare .sbuildrc to work with piuparts.

0m0.0s DEBUG: Unpacking /home/soren/.cache/sbuild/unstable-amd64.tar.xz

into

/ tmp/tmplbhnn26l
0m0.0s DEBUG: Starting command: ['tar', '-C', '/tmp/tmplbhnn26l', '--

auto-

compress', '-xf', '/home/soren/.cache/sbuild/unstable-amd64.tar.xz']

0m0.5s DUMP:
tar: ./dev/console: Cannot mknod: Operation not permitted
tar: ./dev/full: Cannot mknod: Operation not permitted
tar: ./dev/null: Cannot mknod: Operation not permitted
tar: ./dev/ptmx: Cannot mknod: Operation not permitted
tar: ./dev/random: Cannot mknod: Operation not permitted
tar: ./dev/tty: Cannot mknod: Operation not permitted
tar: ./dev/urandom: Cannot mknod: Operation not permitted
tar: ./dev/zero: Cannot mknod: Operation not permitted
tar: Exiting with failure status due to previous errors

Does anyone have any pointers as to the root of the problem?

Which version of piuparts did you use?

How did you create the unstable-amd64.tar.xz?

Can you paste the complete piuparts command line as in the sbuild log?

I created two bug reports that I believe have the information you need:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1088307

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1088304

Sorry I should have pointed you to #1088308 instead of #1088304.

--
Soren Stoutner
soren@debian.org
-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEJKVN2yNUZnlcqOI+wufLJ66wtgMFAmdGIMgACgkQwufLJ66w tgO1DA/+O/tatKc+Oq3O+Xt8+7NdUn1KlLTLTWnZXUITXPofJW55FBr71y6jC948 Nu0TQx7sXX36sfFO7bHrgpB0Ut0dM3U0MbiZsjdHNa68l8ZtJZ6XWf5Sa/+kGgzF IP3mh2/dUPytL/kgyP/gMHqXftZTO1AaDq70uQYTxQ4Eqx86L7AaVkwpIoJwbnIl 3QPjiKUiABBPGSqsH6XBWGG9BhyIennhREMkKT9nkbBvMAVQwwmX5RX8ntFBMBWG 7zmXs8EFL5RFEx3QF5Nk6uaUOuVLATjyCViPB7ArhKZWP/ypIGyAoC5RyTKZYJDH zSoWEQwjJYl3dp8Ab168zuN2wWRjpQ8z4iwjeJrq/+6wwE0rwg3JBef7bPPxgJNL B2GLrKz9F9Byxv+xcu2AfQxEZ00qlJWkh/CQmkWwi7Q4XXVVHokDnpVCK0yX4wz6 h2k9bQ/5htTJXVecY2/jZ6Z9bF5BHWxCffQzK5x0g/2AZY3VpAgxglXKYeWIFivp q7bNRUolgfFYw8iJrb9Sk3jLTCsk/VGAyvxTfUHliDQD47XNGYrMbzn36VePSF1F GeloG6WLq83KnCFGbq+DgWYpqd5Rz2XtdwRVvj2gHRt8vzxfHV8Rpdl8+l882sXN A6Whz193rY+5BQbw+EVUMQa25VSdavpzQt1bNDaTINyIbXxLmZs=
=/cDG
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tuesday, November 26, 2024 3:17:45 AM MST Jochen Sprickerhof wrote:

Hi Soren,

* Soren Stoutner <soren@debian.org> [2024-11-25 16:57]:

I am not able to get the example unshare .sbuildrc to work with piuparts.

0m0.0s DEBUG: Unpacking /home/soren/.cache/sbuild/unstable-amd64.tar.xz

into

/ tmp/tmplbhnn26l
0m0.0s DEBUG: Starting command: ['tar', '-C', '/tmp/tmplbhnn26l', '--auto- >compress', '-xf', '/home/soren/.cache/sbuild/unstable-amd64.tar.xz']

0m0.5s DUMP:
tar: ./dev/console: Cannot mknod: Operation not permitted
tar: ./dev/full: Cannot mknod: Operation not permitted
tar: ./dev/null: Cannot mknod: Operation not permitted
tar: ./dev/ptmx: Cannot mknod: Operation not permitted
tar: ./dev/random: Cannot mknod: Operation not permitted
tar: ./dev/tty: Cannot mknod: Operation not permitted
tar: ./dev/urandom: Cannot mknod: Operation not permitted
tar: ./dev/zero: Cannot mknod: Operation not permitted
tar: Exiting with failure status due to previous errors

Does anyone have any pointers as to the root of the problem?

Which version of piuparts did you use?

How did you create the unstable-amd64.tar.xz?

Can you paste the complete piuparts command line as in the sbuild log?

I created two bug reports that I believe have the information you need:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1088307

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1088304

--
Soren Stoutner
soren@debian.org
-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEJKVN2yNUZnlcqOI+wufLJ66wtgMFAmdGIBQACgkQwufLJ66w tgNoKw//ezVTpOp0TMJe9PkG3ipQhpLqT5krxly9fPR9qCFSTwzTZQg3IJ/EsMIE tUV55xU+rJKgT26tGZT3L8P26vjfhlhCoohvm8+59WNRJnEHq0W4LCadLXAfWQO0 f4L1yvDorPbBe6WCH1kuPW9Trk+gcsgF7I1ERZM1qu9LqTmj9ElVEBdCa/UupLkV 7Xbf+WFUnK26SligmXBnvgpF0l6oaxoojghofos+WYUmH3hUviGAGDQfwAm5qFCw QcJSbK/BRqMgnvPP3vVcECfaoolC9tdoMDAilp/jpiF2e3YQj+AGw9rEt8PagX8/ dWAe7mF4wnUXUH6aN2us7BmaZDeeaJJ9oj7T0tHbXn9MTXaXFFRTNJk9H8twIxnt +WOuHW2jpGOyImHxz77CF3+o6LUrm44BphxF8qKtloND3LNg+5NPOUGJDEc1QvgL L++RxXrHQ1+AUceI0001U0csU5ILJAbWVGR9Htb7JW+BCUJbQLAEGR10yiKdgKwr G51N9lhRvBUF98ez4t6zCVy9XWPH2bJ9Z0ax8HNktY2Rli6pHfbJSf6HUBT/Cb5W 9SkkbFsHFTmjeg7nSYX/ffdy9pbs/wiZXphnVLeQK7V3pTlofStPYycRdiJ91B3Z wnrWu710I+HmPN6DnWhzNZlD9ZBeE65vBb/+vYqVpGxgGquRP8E=
=Dg4m
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, Nov 26, 2024 at 12:21:55PM -0700, Soren Stoutner wrote:

# Specify the distribution, -d
$distribution = 'unstable';

Setting this will override the Distribution of the .changes file created by sbuild with "unstable", ignoring what your package has set. Are you sure you
want this?

I would like it to be able to build instead of fail when the changelog says UNRELEASED

I just always pass -d to sbuild explicitly. It's not a big deal when you
always pass something like 7-8 options to sbuild explicitly and building for !unstable is rare enough so editing the command is not a big deal either.

--
WBR, wRAR

-----BEGIN PGP SIGNATURE-----

iQJhBAABCgBLFiEEolIP6gqGcKZh3YxVM2L3AxpJkuEFAmdGIRotFIAAAAAAFQAP cGthLWFkZHJlc3NAZ251cGcub3Jnd3JhckBkZWJpYW4ub3JnAAoJEDNi9wMaSZLh 2q8P/1VrpE+QrUPTuYjuZNIC2rz8B8BHZevD5n8qjobH/oO2OIh6mJGEzOlBz8F+ IC1H6maJ7TZ3IPd0By7baOzQJsg1Ie6E9L4hifYzGuVgxLzXxLvYQ5Jyzit9arAP nVP9o9UKk17qv8g9gQSSeE7yBZPCMslZOxqrZqnkYQnjdIn84APccMD3ymJY+Ems YZzxadg1NRmQcN6bBF4i07sF9SQM3sUrwqybbMbaJh7mdmSl6DQw71KS3LoBotZ8 F3uL6kWZgFx+VBLF6F5wBEI8vFF5cmzP18QUFBVvwz3voRHHqFQZvLhgzs1KOy6+ C3Dv1x4Fq+GQmNADudcMKhZ90nOsB/3sbnvMb+FHBSm1WRBfbD981Ngwo1g/BVv4 SZ5oV+S45YaaXM6aSLU5RpAdBBrngTsEprRe3ZtxX21MPgki72QXBP8nqUlwMRdj rBW4SVJqYxJu1yj075VDY8lFrPOU//iVDj4SMaSqwow4w1tuvF4HfT8XksKGr97+ YjibdHTqo+1ccgKHTtQ+fcVxDYUYAx6EdLGwdeAnN0Qb6QcOAh34FlvFW9L6FiE2 t0JGV8HVn8riNHwLAoEOPaw6SVL9wKLCBrkGZ70HkhjYieu/Y6Qbtj8lTYJ6b5W4 9W9dMctAORPga9nZOiU93drmeocyDfX4qaI3ancbznImfydA
=eJls
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Johannes,

On Monday, November 25, 2024 11:37:41 PM MST Johannes Schauer Marin Rodrigues wrote:

Hi,

Quoting Soren Stoutner (2024-11-26 01:07:06)

I suppose I should note that I have made a few modifications to the example file because it wasn’t behaving as expected. Specifically, I disabled the
mmdebstgrap auto create because otherwise it was ignoring the tarball I

had

created in the previous steps (including the apt-cacher-ng setting) and creating a new tarball pulling straight from the internet at each build,

at

each run of lintian, and at each run of piuparts.

please report a bug about this. This should not happen. It's easier to get

to

the bottom of this in a bug on the BTS than on d-devel. :)

I assumed this was some documentation problem in the rewrite of the wiki (hard to submit a bug report against the wiki page). But if this is an actual bug in sbuild I will be happy to submit a bug report.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1088304

I also had to specify the distribution or things didn’t work when building
against a changelog that targeting UNRELEASED.

That should also not happen. At least it works fine for me... If you open a bug or write me a private mail we can hopefully figure out how our setups differ.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1088307

Piuparts is fine if I let it generate its own tarball on each run. But it doesn’t like using the tarball previously created.

Jochen is the sbuild+piuparts expert and probably has some input on this. :)

I see he responded separately, so I will reply to that email with further information. I have also filed a bug:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1088308

# Specify the distribution, -d
$distribution = 'unstable';

Setting this will override the Distribution of the .changes file created by sbuild with "unstable", ignoring what your package has set. Are you sure you want this?

I would like it to be able to build instead of fail when the changelog says UNRELEASED, but I would be happy to not specify the distribution if I can figure out how to make it work. Lintian produces an error when this happens, so there is no chance I would ever upload such a package, because I always produce a lintian-clean build before upload.

E: python-trezor changes: unreleased-changes
N:
N: The distribution in the Changes field copied from debian/changelog
N: indicates that this package was not intended to be released yet.
N:
N: Please refer to Bug#542747 for details.
N:
N: Visibility: error
N: Show-Always: no
N: Check: fields/distribution

--
Soren Stoutner
soren@debian.org
-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEJKVN2yNUZnlcqOI+wufLJ66wtgMFAmdGH9QACgkQwufLJ66w tgMo/A//TmC2huIaSyL60iyWWSbw3l3i/971+arMdTEmt9jnR3pRv3TbCUcx0F9r mgPxCpdMpE77y7Wr/k8zP3Ou2BZ35IYt9aLmHCcMozysGu+LyJ0URSiZHw5FFp5N HVDL20IK+qISsn8yry/ux5cFJyzq1cixaQo89eX+7cS5RQLVmH3UTayrhPl/vF+C 7NLcM3MpDa04Hm1fvPdwY0lv+wnMheDLwIu9ANr2wnGJY3UcYcu8whXmuXVbth+J BkVMuF+Vi+d+jFzlwalqPdPLvoyZMKg4Lx46ebrsfiegiVWBmhRC+VFwdVASps4U Bs1e3Tp1VHCHE9wzjvNSTgS3aqr24HbzkFS9vPxVjhptwPdltMBk27OYle3UNfzy pHGRsA8U3ZLbkej7mYmnzfPJnvnk7klwc0DTyCRIMIuY28y+EDKjVd0Zq1E4qnsR ok8euzHbbGzmgd65C9hl6f+C7iVJlJov07oTd5q/yVeLQCfg3+ATk+Xghin/J/BO a2tjXB+OYqWK4QYfNaajQKJIOkUIWOONznc0HMPemlH3lFXhQoy/PFwEd/EVAjS5 3cVvEXoq8sQFtUoa8BvMsnQdjyajzHqBGFWP74rjNoVDnmfRoP1hiqNiItl2fG6S UGlGIyWOPe86UGQIKn4PuU7zX7Dz218GY2Zir+WlbeURacHvVl4=
=vCT/
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tuesday, November 26, 2024 12:27:22 PM MST Andrey Rakhmatullin wrote:

On Tue, Nov 26, 2024 at 12:21:55PM -0700, Soren Stoutner wrote:

# Specify the distribution, -d
$distribution = 'unstable';

Setting this will override the Distribution of the .changes file created by
sbuild with "unstable", ignoring what your package has set. Are you sure you
want this?

I would like it to be able to build instead of fail when the changelog

says

UNRELEASED

I just always pass -d to sbuild explicitly. It's not a big deal when you always pass something like 7-8 options to sbuild explicitly and building for !unstable is rare enough so editing the command is not a big deal either.

Yes. Passing -d to sbuild is functionally the same as specifying the $distribution variable .sbuildrc. In either case, if it isn’t specified, UNRELEASED appears to cause problems with sbuild and unshare, which appears to be a bug (unexpected behavior) according to this thread. The build logs do show that the main sbuild process converts UNRELEASED to unstable when auto- creating tarballs, although not when trying to find an existing one (see the bug reports previously linked). But Piuparts doesn’t so auto-adjust from UNRELEASED to unstable.

--
Soren Stoutner
soren@debian.org
-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEJKVN2yNUZnlcqOI+wufLJ66wtgMFAmdGInIACgkQwufLJ66w tgPQThAAh1bwzMh+JqEKyFgUM2DUgG5mtTesr1pMh/aGuq/ZnjEqKIO2kGy3NTeP 2y6rFiwvd6P9CtzJuTLRQS9aEA0jj33Z2cuOPYMGBdApgfWOkpJy4ioLIQgAYeah kM2sjzoP/RApNQ/NaACIHBON/+XF47NTCpBBKW+lbvqXsSLzUkAR4ekCwq58Jlz3 S7GORwCGTL2ibS45x932qAopmQtSEwvDfQAL5OQ9aBVH7mXz2XKbYIDu7qGfxzAg sPPSQgRVXhjTFCN/+TuAKNN7cJm2fHYBat9kpw/zk6CcTuUKuGYNdJfhw5cfx2R9 Is99KxBy1D+EzaOIy3Vcg5TKGfNRU54b3jkA2lQfLjTbvVg1AT2EDNrDkuHk3hxE GJ6Thv1Y/yGfBh7xSstzYaScIXZBZSNcFYZ7phY2copKQ6Qh1pNEE70qWqvdldD7 kvUujzzsfMKOT3RWjideEshwIf9gnFPnEJlYW6EdxDcy6QC/vRfRNSxkc19xDfo8 CD/YPFg50IgCfw/zuQF0PSN4sddvmSJ3g2siZBNkHqMtjQ+BPqWWJbDswQCDMoXx 2EgktWb2EvxiOjhCFvvxwymbH77OxTqDo+fAG7FdhaHOgtJrVVpLDWFMSXgwx3hQ kOpIQIJAmySD/uR5xLm4ElmPrOw4heAHsFpAm06ionrTRHPsArw=
=vrfS
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Soren,

Quoting Soren Stoutner (2024-11-26 20:21:55)

Setting this will override the Distribution of the .changes file created by sbuild with "unstable", ignoring what your package has set. Are you sure you want this?

I would like it to be able to build instead of fail when the changelog says UNRELEASED, but I would be happy to not specify the distribution if I can figure out how to make it work. Lintian produces an error when this happens, so there is no chance I would ever upload such a package, because I always produce a lintian-clean build before upload.

yes, running sbuild in an unpacked source package with an UNRELEASED d/changelog is supported and will (unless you configured something else) build the package in an "unstable" chroot. If it doesn't do that for you, we will find out why in the bugs you filed. Thank you!

For the piuparts issues, Jochen will probably come back to you. :)

Thanks!

cheers, josch
--==============97005219826735937=MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Description: signature
Content-Type: application/pgp-signature; name="signature.asc"; charset="us-ascii"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEElFhU6KL81LF4wVq58sulx4+9g+EFAmdGIecACgkQ8sulx4+9 g+F20Q/9EDC0kXT0YtMd2na25lB+0HIYCygC5pnDL+y40kU4ZVGKx5/14ky7+sqM 1I3vqVGYz+VP3FxJuACBMW+fN0E1lsBDqLjahW0SMr+vis3ziUWmg7IzpIOlJrLd hWkJ5cnc5VIffdPGK3cR/DkZDfFYVaI7kKUUNoXaieTtPB4wBbbvdTY+tSYc4AKV RJB4HRU3BVc3CUD3ZgcVdzr7Q+X7QIZRSHgkzcRDXypQGPv/c6EhwX4KTXIhS/yd 7YCa+LCoAFbxTznTI3o8ZAcfcyzXu1crML0zv+eSG/kYV7tgyx19LApHMDPVsm0W dv6m5mOa34f1w/Jut+iTxTRIFFhcRHx0B1iUhNUd+f1qsfMvzwhzdTWkvD3D8r3m Lyg09JFR3p77l8KnQeX/tBUuyRMPEIHLWk+8bqT3f+cioIM8JrLKLdqEm0YnoMhV MtKRUFQcTXx7O59hBz/tMxJi76nVdooHQTPKq8dMEEDedVD1RJPNZmMxxajHZffg 26ACP2VR02JaamUGL2e4jaYuVWjU42st64iGiiz6Ra5nRFdSB9WYMKuNm14UE84E Q32tbjRkPdwjJXmxjmi2dipsfAusbuduIau5osPLIekkyJgQUhZQkz/imL5YybeE odNhDzI6Nw0xZyHMSTe0PbCLK/BdY1lkli2pEj+6HA7x3qtJIhk=
=XZcg
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Monday, November 25, 2024 4:57:50 PM MST Soren Stoutner wrote:

On Saturday, November 23, 2024 2:20:45 PM MST Philipp Kern wrote:

Debian buildds are using sbuild with unshare now ------------------------------------------------

The wanna-build team switched all buildds to the sbuild unshare backend
for trixie/sid/experimental plus *-backports. This means that official
Debian builds now run as non-root user and rely on user namespaces
instead of schroot. In addition this blocks any network access during
the build as per Debian policy 4.9.

Prior to the switch Santiago Vila did test rebuilds of all packages and
bugs have been filed:

https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=unshare;users=debian-wb-t
ea

m@lists.debian.org

Help is welcome to fix the remaining bugs.

We recommend all developers to use sbuild with unshare as well.
Notes on how to set it up as well as hints for custom usage are collected
on the Wiki:

https://wiki.debian.org/sbuild

I am not able to get the example unshare .sbuildrc to work with piuparts.

A bug has been fixed and the instructions on the wiki have been updated so they now work out of the box.

https://wiki.debian.org/sbuild

--
Soren Stoutner
soren@debian.org
-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEJKVN2yNUZnlcqOI+wufLJ66wtgMFAmdHAvAACgkQwufLJ66w tgNWChAAq83cllz3ckPy8hxaoVSPYs8Zby7+jSJNL5cN6hUiJQcnWHuQBUaqCaaR 9vgicE3c8zWfH0odP11d0L+ROVEZTXdVX3X7mk0182tewqhwIzzMRTz14DDSsGm3 /p1reXhRHjzXogiT6PHX57v4nFoJv10ZmCgEgAjEd5Xi4PNEJLcaN7kcrG0I9dOh gCaGoMxMkWTaBsNvCJuaUICKCTKsd/qOWl/iHuCNlP+MxGUg2ulDxTRDdZ+m2Y6I bEBeP+P+Y/oNarnHmOmXvLH26CXMVcPiYeBy67iavblUJpWcLfTSAAX4mSyCwHfR B0Y4c4QWfUH+KXhb3ChqfkbtBGK6Yi7XQn8skMtvP/KS/bugRIciHWytY1wjiZaX QVZI5g2h40lx2VVMeGqLmUdRxsJLIXrcVjsYmNXNe10zZknrBPgdHwSJ1Rzh8Imc v7gwQJwPMF+gidH85PZ6l2OHJm3iWIN9xp31Bw2A6KsrYhe0rtMXawbdNf17SrIi YcUmQPwzPYIJ4QYQD21q7lPLtl2vMe7pZDr3ryohWHwlBcSrWvxwGLDTjo8xwbdR MJTqEN0TZrtieHHOQCDXnvHPTXB5pYo2t4OYVuHlrgY0CbEpixW8wryfCRkSJ4t1 F4YKmfY9LfUS7asHnwV7B+knV1VBDkCvsoewTWJ4p13J2Oe9sLA=
=Xc/q
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Julien,

* Julien Puydt <julien.puydt@gmail.com> [2024-12-01 10:59]:

My use case isn't with a single package, but with a bunch of them. For >example, updating the coq package means about fifty packages in seven
stages. That means I compile all packages of one of the stages
(sometimes in parallel), move the results to a local repo, then go on
with the packages of the next stage.

Previously, I had a ~/Debian/repo with those updated packages and my
chroot mounted it as /repo, with its sources.list pointing to it.

After the move, I tried to use webfs to serve the repo as
localhost:3143, adding it as a --extra-repository='deb [trusted=yes] >http://127.0.01:3143 ./Debian/repo/' argument when I launch sbuild. In
the build log I see the sbuild accesses the repo and sees the list of >packages -- but it 404s when it comes to downloading :-(

Can you try:

sbuild --build-dir=~/Debian/repo --extra-package=~/Debian/repo

This should save all binary packages to the directory and use them in subsequent runs.

Would it be possible to document using a local repository in the above
wiki page?

Please add it if it works for you.

Cheers Jochen

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEc7KZy9TurdzAF+h6W//cwljmlDMFAmdMNwgACgkQW//cwljm lDPNtA/+NZumnRyodP/QjmF48R85xSIIOki/0X3Y1VVgeAkTwuwqI37HQbXhXOUZ JOqZPvdgzF9kSCtFECHFO41gpcs5UR+r4n3B7t5ePwkETvtzrAu+j6MGiO3Xy8G+ 9uOuL4JNlzFtDOOsFw4bFMajXdFRieSeeggZ19JEiYvA560ah1gad3zuf/ocT7NJ P9UDxyzrrnFCSWMrx3kQJ1ICTB7798UcbQlFuv+n0GTGjkteJz7rnjXoXSK1F524 LTFsFqE4WN26a5CBg0f0kOv3t5l4pCDaRzOHQvKIBFw8hl1y0CLPsidx/DNp8DiL Nuh26SBn01OoSuSe1OVPvPFbqPKllxHZCTOyVbtfFRT0wCZjX1wZczeux9QsJYty BP3EWM5+h0+pOkYnO8W5H+rxhGakz1tD9zn8Q7h1HqmVR4GlVCKASMkfrjcAqEJM YDBv44e4xv/5yyd9zdHU+jtmPprzg44f+j79nl6aRea2OZvAdG9NN1QTwhmzGkGb E6h/w6/kHtRB6fIlLqv8IRt6dm3M+7sAddQ/SkE8n1YfVnPStmRBeupy9+jn7GFR WlV3ULiTMuVFphzM2eFAgyPZTdVrp6JA2UBJUUU6mHhfL/wX7/NnmWftVVXXEzCf 5mAXu3arANaMcNv5PPbDRSfVDR8nvcf+LPYP4RrpW1iNyDrdDAg=
=n3mM
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

To: debian-devel@lists.debian.org (Debian Devel)

This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------0jWmuc84Mv9d6zS4JmHBAlL9
Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64

SGksDQoNCk9uIDEyLzEvMjQgMTE6MzYsIEp1bGllbiBQdXlkdCB3cm90ZToNCj4gICAgIENh biB5b3UgdHJ5Og0KPiANCj4gICAgIHNidWlsZCAtLWJ1aWxkLWRpcj1+L0RlYmlhbi9yZXBv IC0tZXh0cmEtcGFja2FnZT1+L0RlYmlhbi9yZXBvDQo+IA0KPiAgICAgVGhpcyBzaG91bGQg c2F2ZSBhbGwgYmluYXJ5IHBhY2thZ2VzIHRvIHRoZSBkaXJlY3RvcnkgYW5kIHVzZSB0aGVt IGluDQo+ICAgICBzdWJzZXF1ZW50IHJ1bnMuDQo+IA0KPiANCj4gSXQgZG9lc24ndDogaXQg ZmFpbHMgc2F5aW5nIEJVSUxEX0RJUiBkb2Vzbid0IGV4aXN0Lg0KDQpEb2VzIGl0IHN0aWxs IG1lbnRpb24gfj8gdGhlbiB5b3UgY291bGQgdHJ5IHJlcGxhY2luZyB0aGUgPSB3aXRoIGEg c3BhY2UgDQphbmQgb3IgcmVwbGFjaW5nIH4gd2l0aCB5b3VyIGhvbWUgZm9sZGVyLiBTaGVs bCB+IGV4cGFuc2lvbiBkb2Vzbid0IA0KaGFwcGVuIGluIHRoaXMgd2F5IEFGQUlLIGFuZCBt aWdodCBub3QgYmUgc3VwcG9ydGVkIGludGVybmFsbHkgYnkgc2J1aWxkLg0KDQpQYXVsDQo=


--------------0jWmuc84Mv9d6zS4JmHBAlL9--

-----BEGIN PGP SIGNATURE-----

wsB5BAABCAAjFiEEWLZtSHNr6TsFLeZynFyZ6wW9dQoFAmdMPYUFAwAAAAAACgkQnFyZ6wW9dQpH RQf+L3fgApTevVzX4Y0nu8vOyfUZcbyowea3wUAkno+sjnCQub1Z6qsLY3g6OhB14GSh+IAtPM2y Ld2dKz5hLpILD8WkrJ176aQv52CMxd15JYskSSzNsFd9154L3oMqSdXKInWuCIW1XUj6HiDnQgTw +B431senk9ruwNYIIwHkO4VWnNVhWQP1OJHJzQ2vgs4DYJ8wnqZFo0vACjjE5V8Aq+nO7rC+bGFO plrylUT5vxpu8DmhUtIxDQYUm/Za43GgjlaMFSe3XJC+NFuepi6zQqke5KXPsy2HjanDjETWwX3p GJ7F3CyfWdxexofDW/VFfdclrKv/ZXHTrHOxOcePug==
=OeS1
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)