reprotest: doesn't respect $RELEASE

I configured xdg-desktop-portal-gtk with RELEASE: experimental because the debian/master branch has build-dependencies that aren't in unstable yet.

It looks as though the reprotest job doesn't respect this:

https://salsa.debian.org/debian/xdg-desktop-portal-gtk/-/jobs/202379

$ apt-get update
Get:1 http://cdn-fastly.deb.debian.org/debian unstable InRelease [210 kB]
Get:2 http://cdn-fastly.deb.debian.org/debian unstable/main amd64 Packages [8307 kB]
Fetched 8517 kB in 2s (3912 kB/s)
...
Reading package lists...
$ eatmydata apt-get build-dep -y .
Note, using directory '.' to get the build dependencies
...
The following packages have unmet dependencies:
 builddeps:. : Depends: xdg-desktop-portal-dev (>= 1.4) but it is not going to be installed

mentioned in commit debian/flatpak@d66ec3cb

mentioned in commit debian/flatpak@5901646f

mentioned in commit debian/flatpak@1274c646

mentioned in commit debian/flatpak@0accd034

I fear, that the reprotest doesn't respect any RELEASE configuration but always uses unstable.

I just tried this on package fig2dev with buster, where you can see, that unstable packages are installed, as well as with stretch, which fails on packages, that are no longer available in buster and unstable.

changed title from reprotest: doesn't respect "RELEASE: experimental" to reprotest: doesn't respect $RELEASE

I fear, that the reprotest doesn't respect any RELEASE configuration but always uses unstable.

Yes, that would have been a better summary. I've changed the title of this issue accordingly.

mentioned in merge request gnome-team/glib!6 (merged)

mentioned in commit debian/flatpak@0693185a

mentioned in merge request !178 (closed)

Another instance of this is the problem that it doesn't use experimental's Sources file to get the tarball, but tries unstable only:

$ # Check if we can obtain the orig from the git branches # collapsed multi-line command
gbp:info: All Orig tarballs 'gr-limesdr_2.0.0-27-gca01a64.orig.tar.gz' found at '/builds/debian-hamradio-team/gr-limesdr/debian/output'
gbp:error: upstream/2.0.0-27-gca01a64 is not a valid treeish
Ign:1 http://deb.debian.org/debian sid InRelease
Get:1 http://deb.debian.org/debian sid InRelease [139 kB]
Get:2 http://deb.debian.org/debian sid/main Sources [8386 kB]         <--- no experimental here
Get:3 http://deb.debian.org/debian sid/main amd64 Packages [8234 kB]
Fetched 16.8 MB in 4s (3934 kB/s)
Reading package lists...

https://salsa.debian.org/debian-hamradio-team/gr-limesdr/-/jobs/361027

mentioned in commit joachim-guest/ncurses@be7783d0

I got this as well: https://salsa.debian.org/js-team/node-yarnpkg/-/jobs/470201

from the log:

$ apt-get update
Get:1 http://deb.debian.org/debian sid InRelease [142 kB]
Get:2 http://deb.debian.org/debian sid/main amd64 Packages [8194 kB]
Fetched 8336 kB in 2s (4455 kB/s)
Reading package lists...

whereas the build step from the same pipeline which works fine has

780fb5b7e12b5e4869459c5f21d73aad71abd53b1d9ade6ce9d4670a898e5a91 apt-get update
Get:1 http://deb.debian.org/debian unstable InRelease [142 kB]
Get:2 http://deb.debian.org/debian sid InRelease [142 kB]
Get:3 http://deb.debian.org/debian experimental InRelease [72.2 kB]
Get:4 http://deb.debian.org/debian unstable/main amd64 Packages [8194 kB]
Get:5 http://deb.debian.org/debian sid/main Sources [8463 kB]
Get:6 http://deb.debian.org/debian experimental/main amd64 Packages [377 kB]
Fetched 17.4 MB in 4s (4769 kB/s)
Reading package lists...

mentioned in issue salsa/support#185 (closed)

mentioned in commit a11y-team/espeak-ng@ccdd8444

mentioned in commit a11y-team/at-spi2-atk@70f098e2

mentioned in issue #236

marked this issue as related to #236

marked this issue as related to #192

mentioned in issue #192

mentioned in issue #118

mentioned in commit ruby-team/vagrant@c95bc620

mentioned in commit input-method-team/ibus-hangul@f1fa913a

mentioned in commit input-method-team/ibus-hangul@e170b6c9

Aargh, sorry for this long standing issue! I think its fix is related to #351

added Accepting MRs label

mentioned in commit yifei/keysmith@4047956b

mentioned in commit yifei/kclock@ec807bef

https://salsa.debian.org/yifei/keysmith/-/jobs/6369797

This also seems to affect crossbuild-arm64, there is mentioning of experimental in the log but the CI container doesn't actually use it.

If reprotest by design always runs in sid, perhaps it could enable allow_failure: true by default if the effective RELEASE is not sid.

Or if it is possible to distinguish failure to install the build-dependencies from failure of reprotest itself, then ignore only the failure caused by unavailable build-dependencies in sid.

To me having allow_failure: true jobs is ugly and potentially harmful as it will make the whole pipeline look like it is having an exception, and is no longer green. Running things and allowing it to fail is also kind of wasteful of energy.

I think it is better to change the reprotest so that by default it only runs on pipelines targeting Debian unstable. A matrix of what jobs are intended to job where has been drafted at !551.

I would like to highlight that, maybe, the reprotest job should be replaced by debrebuild: #399. That is one of the reasons of !569.

If there is any objection about moving from reprotest to debrebuild, please speak up in #399.

mentioned in commit qt-kde-team/kde/keysmith@9b290da5

mentioned in commit qt-kde-team/kde/kclock@255a51c7