Hi!

In short:
I would very much like to see all top-150 packages run Salsa CI at
least once before being uploaded to unstable. What people think is a
reasonable way to proceed to reach this goal?


Background:
We have had several cases recently where an upload to Debian unstable
causes widespread failure in unstable, and it could have been easily
prevented if Salsa CI pipeline had run for the package and revealed
the problem before upload to archive for everyone to suffer.

This message was prompted by the fact that right now we have a massive
large of Python packages affected by the "No module named 'packaging'"
bug [1] which would have been caught by Salsa CI running the
autopkgtest job before upload [2]. I don't want to blame maintainers
for missing on some details while doing new releases - it happens. But systematically not using available and easy testing facilities does
annoy me.

We can't have Salsa CI for all of Debian overnight, but at least
widespread issues could be mitigated significantly by having Salsa CI
at least on the top-150 or top-500 packages.

We do not have stats on how many packages use Salsa CI, but we have
stats on how many are not even hosted on Salsa:

```
curl -LO https://trends.debian.net/vcs-hosting_unstable-packages.csv
curl -LO https://popcon.debian.org/sourcemax/by_inst
for x in $(tail -n +13 by_inst | head -n 150 | cut -c 7-25)
do
grep -E "^$x," vcs-hosting_unstable-packages.csv
done | grep -v salsa

dpkg,1.22.10,other
coreutils,9.4-3.1,no vcs
acl,2.3.2-2,other
zlib,1:1.3.dfsg+really1.3.1-1,no vcs
attr,1:2.5.2-1,other
hostname,3.23+nmu2,no vcs
readline,8.2-4,no vcs
e2fsprogs,1.47.1-1,other
base-files,13.3,no vcs
bash,5.2.21-2.1,not git
expat,2.6.2-1,no vcs
gettext,0.22.5-2,no vcs
diffutils,1:3.10-1,no vcs
libbsd,0.12.2-1,other
sqlite3,3.46.0-1,no vcs
dmidecode,3.6-1,other
pciutils,1:3.13.0-1,other
libxdmcp,1:1.1.2-3,git on alioth
wget,1.24.5-2,no vcs
file,1:5.45-3,other
laptop-detect,0.16,other
fuse,2.9.9-8.1,no vcs
lsof,4.95.0-1.1,no vcs
scowl,2020.12.07-2,other
emacsen-common,3.0.5,no vcs
libusb-1.0,2:1.0.27-1,no vcs
setuptools,70.3.0-2,no vcs
traceroute,1:2.1.5-1,no vcs
liblockfile,1.17-1,github
```

If you are a maintainer of a top-150 package and want help in getting
it on Salsa and have Salsa CI activated, just email debian-salsa-ci@,
and we will guide you through how to best run `gbp import-dscs --debian-branch=debian/latest --upstream-branch=upstream/latest --pristine-tar`, what to put in a README.source how to activate Salsa
CI with potential customizations you feel are make sense. We have
already done this to many projects, but as surprisingly many
maintainers prefer not to receive contributions, we encourage those
who want to have help to reach out themselves.

When I proposed DEP18[1] my main motivation was to get more packages
on git and on salsa.debian.org so that it is easier to collaborate on
the next upload with the maintainer and all interested contributors
before the upload is done. Collaborating on packages by NMUs is just
not a modern and efficient way to collaborate.

On top of this, I also wished that packages would use Salsa CI, at
least once before the upload. This helps the maintainer get assurance
of the package health before upload. Running Salsa CI on Merge
Requests automatically helps contributors get immediate feedback, and
it also gives the maintainer assurance that contributions don't cause
easily testable regressions.

Many people raised concerns on DEP18, and some of them are valid, and
I will continue to ponder about it and how to restructure the proposal
to foster collaboration without alienating any of our current
maintainers who have a well optimized existing workflow.

However, pushing for wider Salsa CI adoption I think makes sense as a
goal by itself, and I would be keen to hear what people think is a
reasonable way to proceed with that?


[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1079175, https://salsa.debian.org/salsa-ci-team/pipeline/-/issues/376
[2] https://salsa.debian.org/python-team/packages/setuptools/-/jobs/6156348
[3] https://salsa.debian.org/dep-team/deps/-/merge_requests/8

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

On Aug 21, Otto Kekäläinen <[email protected]> wrote:

I would very much like to see all top-150 packages run Salsa CI at
least once before being uploaded to unstable. What people think is a reasonable way to proceed to reach this goal?

Advertise widely and frequently that there is a pool of people which is
happy to help investigating the failed CI jobs.
Then start personally advocating the benefits of CI to the maintainers
of these packages: I expect that in most cases you will find out that
they are not using CI just because they are not well informed about it.

Recently I enabled CI for most of my packages, and the experience has
been generally positive.
The most important benefit for me is that I can know before an upload if
the packages's own autopkgtests will fail, and I also learnt about blhc.
I am even considering mirroring on Salsa my few Github repositories just
to get CI support.

Of course, this works best if a package *HAS* autopkgtests, so it would
be great if more people contributed non-trivial tests to the packages
they care about.


Something that many developers are probably not aware of is that they
can enable CI for a repository with no code changes at all and with
a single command:

salsa update_projects $NAMESPACE/$PROJECT \
--jobs yes --ci-config-path recipes/debian.yml@salsa-ci-team/pipeline

(salsa(1) is part of devscripts)

And then they can immediately schedule a new pipeline without having to
push a new commit:

https://salsa.debian.org/$NAMESPACE/$PROJECT/-/pipelines/new

This allows to see how Salsa CI works with very low friction and no committment at all: worst case it can be disabled again and nobody will notice. :-)

--
ciao,
Marco

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

iHUEABYIAB0WIQQnKUXNg20437dCfobLPsM64d7XgQUCZsVOhwAKCRDLPsM64d7X gQvVAPoDtzjvleJ9Kud3DXBlU0HDEr9wTAZYO9I+VR2PTUS+GAD+NXZl9px5LuU3 OReHxbMVeyI62eGyp5fCUntUEKpvlgQ=
=fkUi
-----END PGP SIGNATURE-----

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

Hi!

I would very much like to see all top-150 packages run Salsa CI at
least once before being uploaded to unstable. What people think is a reasonable way to proceed to reach this goal?

Advertise widely and frequently that there is a pool of people which is
happy to help investigating the failed CI jobs.
Then start personally advocating the benefits of CI to the maintainers
of these packages: I expect that in most cases you will find out that
they are not using CI just because they are not well informed about it.

So maybe just send a mass email to the maintainers of these 150 packages?

Recently I enabled CI for most of my packages, and the experience has
been generally positive.

Glad to hear!

...

Of course, this works best if a package *HAS* autopkgtests, so it would
be great if more people contributed non-trivial tests to the packages
they care about.

Autopkgtests are of course nice, but Salsa CI will also help detect if
the build is broken, or if e.g. debian/control relationships are
broken and package is uninstallable etc. The coverage is not complete,
but if the basic things that Salsa CI tests for break, then the
package is most likely going to cause havoc once it lands in unstable
and require an urgent re-upload. As examples, the failing build of https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1071245 broke
installation of gnupg on Debian unstable and thus everything that uses
gnupg and could have been prevented with simple Salsa CI run (the
package has now Salsa CI, so this won't repeat), or https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1021336 where pam
files tried to overwrite files in other key packages, breaking Debian
unstable installations and chroot creation for everyone would have
been caught by basic Salsa CI tests (MR to include Salsa CI suggested
in https://salsa.debian.org/vorlon/pam/-/merge_requests/20). Using
Salsa CI will save both the maintainer some headaches, and protect
everyone using unstable and doing packaging work from being affected
by a temporarily broken dependency.

Something that many developers are probably not aware of is that they
can enable CI for a repository with no code changes at all and with
a single command:

salsa update_projects $NAMESPACE/$PROJECT \
--jobs yes --ci-config-path recipes/debian.yml@salsa-ci-team/pipeline

(salsa(1) is part of devscripts)

And then they can immediately schedule a new pipeline without having to
push a new commit:

https://salsa.debian.org/$NAMESPACE/$PROJECT/-/pipelines/new

This allows to see how Salsa CI works with very low friction and no committment at all: worst case it can be disabled again and nobody will notice. :-)

Thanks, these are great to point out! i will add them to the Salsa CI
README in next docs update (https://salsa.debian.org/salsa-ci-team/pipeline/-/merge_requests/519).

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

On Tue, Aug 20, 2024 at 10:44:30PM -0700, Otto Kekäläinen wrote:

Advertise widely and frequently that there is a pool of people which is happy to help investigating the failed CI jobs.
Then start personally advocating the benefits of CI to the maintainers
of these packages: I expect that in most cases you will find out that
they are not using CI just because they are not well informed about it.

So maybe just send a mass email to the maintainers of these 150 packages?

or maybe document it in a more permanent place like developers-reference?


--
cheers,
Holger

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org
⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
⠈⠳⣄

If you think fertilized eggs are people but parents who've crossed the oceans with their kids aren't, stop pretending your concerns are religious.

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

iQIzBAABCgAdFiEEuL9UE3sJ01zwJv6dCRq4VgaaqhwFAmbFm1AACgkQCRq4Vgaa qhzL2g//YNoABz/uR9J5q+MdOQMQBz/QYQFtWgG1iSEuzegQN81kaDgcKgx8wJK2 8eMdQijZj4W2/3Lfpy2loqOmLifza0S+WNTxcB7glj43Vdd7EAGBSUKe0iyzMCAF CekidkxTt6up5YDAeGUqRz38d+JqoGUZecTpxLZc2nb/3FO9Ag3WKl6pkhrK/xLu IYtVQYYFI8BBG/GIn3988Vu2dUwPW/Itwy1QlZhsCDd2aSF1vR1Vh/bcNA7ZSLGX 8mdT7KR3Wt02OpdkLy7r8rUozyeArMxAldGO0zBGIrpGlqfvvtOoMigUul8/c7WN PNaZ1/Zzow5SpiJrxWHpoTkqPimh+RIfzNTX5s8Vq7p0KqcJ0ZOLqKBBhhEqmleQ KqxnTHe/WQwZd2WpjWqLbpM4Ni8Sy00Opy0ZtNaRiJYUmpKXq+hfgBcziQ+dCpl+ piXYEcIPPWexVs+8xgMZzJRPfYPizJDW5ETQdvbBclYBifvT2arNZIJ1Ryt9z0A/ Hyk6JpEM7WUUiZ9UONHtpADYGE+LiEv

On Tue, Aug 20, 2024 at 10:44:30PM -0700, Otto Kekäläinen wrote:

Something that many developers are probably not aware of is that they
can enable CI for a repository with no code changes at all and with
a single command:

salsa update_projects $NAMESPACE/$PROJECT \
--jobs yes --ci-config-path recipes/debian.yml@salsa-ci-team/pipeline

Yes, this is hidden knowledge.
I think you can find it on some wiki page if someone points you to that
page.

Thanks, these are great to point out! i will add them to the Salsa CI
README in next docs update (https://salsa.debian.org/salsa-ci-team/pipeline/-/merge_requests/519).

When can one find that README and how can one know about that?
The MR mentions maint-guide and debmake-doc but I assume nobody reads
those except very new packagers.

--
WBR, wRAR

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

iQJhBAABCgBLFiEEolIP6gqGcKZh3YxVM2L3AxpJkuEFAmbFtTctFIAAAAAAFQAP cGthLWFkZHJlc3NAZ251cGcub3Jnd3JhckBkZWJpYW4ub3JnAAoJEDNi9wMaSZLh CtYQAJ3DjTq8DdVojqP01tWt6FLBwKxt5W23MPNrqMonva7HUFGp/R8O6O2FUh7F 7qpZcY7P4uq/l6sG2yUUglu9jwhQUtcQV3y6dvwR9jgSIy2tOsOi/7D06+Bv5zsj dY8un3UGaRf3qX7VERIWpRELFKSQb1oCti2o5IH/VHS5sp1wnqoTQOCoL/aBYDju 8ihic4nixahryEC+WNNlqKMhkJaSIDZrSyxUfbmBovJ8JWazTdlOAu1albiGzjpg MPb91o9iVjGFXq9fsu0RrSa8AsBLNoB7pxE8LFUUI1i5DF59psbbcRC9/Iqyhk6O S0rOgHqsluOJ5NuGiVPgNMgaIAhtJLZ8ojMI57uNssEtuGdiC48Ta1Yxur0I/1Jv vDIJTQqg2tNX9Ilis6wsRaA22FQv8vuBqvwT6uTiFhYHUZ413Jr8Sof0xvlxuIXa IsqrcEGkw7gTESRtEay7nKBWJAFOqwCqDlTyOi9ZdcX+VAYN9PCl0g5mJYj6ISFx 3wnJtGe5Wj39HZBvFhlEWt6DlWx2p9PVHSoQR/QwKuhQ5ItnztyLbShdUy3Aub/A NdpGwVLjZacBC599wrv1yWRq+57DCfJsV83oQFJ5mt29QxysDwQNwgPX0q8gwMX1 5h01RUN45TRFZgdmnB9IhIboANKbiYC6sI30KwpL3QuoZpjr
=EZqV
-----END PGP SIGNATURE-----

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

Hi Otto,

On Tue, Aug 20, 2024 at 06:35:52PM -0700, Otto Kek�l�inen wrote:

In short:
I would very much like to see all top-150 packages run Salsa CI at
least once before being uploaded to unstable. What people think is a reasonable way to proceed to reach this goal?

Background:
We have had several cases recently where an upload to Debian unstable
causes widespread failure in unstable, and it could have been easily prevented if Salsa CI pipeline had run for the package and revealed
the problem before upload to archive for everyone to suffer.

I'd like to rephrase your quest. What you really want is unstable to be
less unstable. Whilst a number of people disagree with that notion, I sympathise with that view. We do use unstable to discover problems
before hitting testing, but in order for this to be effective, the bugs
to find should mostly be integration problems and it shouldn't be too
bumpy to let actual users ride unstable and report non-obvious problems.

Your proposal here is to improve the situation using salsa-ci and it is
not the worst of ideas given that salsa-ci works well for large numbers
of packages.

One complaint I've seen about this workflow and one that I agree with is
the waiting time. Checking salsa-ci before uploading incurs an extra
context switch. What we'd really like to do is click the equivalent to "Auto-merge" (if the pipeline passes). As I write this, Sean or Ian will
likely come along and say tag2upload. Working in this direction and
enabling a "upload if ci passes" would bring the salsa-ci experience to
another level.

Let me suggest that there are more ways to do this. Freexian is putting
a ton of effort into https://debusine.debian.net. It can do much of the
same tasks as salsa-ci already (with less flexibility). Extending it to
act as an upload-proxy that forwards your upload to the archive if
builds pass could be another option of improving unstable quality. In
earlier times, debomatic.debian.net was used as a pre-upload QA tool if
I remember correctly.

Then the top-150 packages tend to be packages with unusual aspects. For instance, the git repositories for gcc-VER, glibc and linux all lack
upstream sources. For linux, there is a pipeline, but in order to
complete in a timely manner, it enables the pkg.linux.quick build
profile and the pipeline is elaborate with a complex extract-source
stage. It's not a matter of just enabling the pipeline for our core
packages but spending a lot of time fiddling with the settings until it
works. I guess that sending a working pipeline configuration for these
could improve the situation. Would it also make sense to source
dedicated gitlab runners for heavy core packages to further reduce the
feedback time and the impact of enabling CI there?

Given this I want to resonate what others already said. This seems more
like something to put effort into and make it work practically than
worth discussing. Doing a survey mail to the relevant maintainers for
figuring out where to best direct that effort also seems sensible to me.
More than once, I've experienced that it's not the technically best
solution that ends up working well, but the one that has the best
support crowd. To be blunt, I don't think the /usr-move we do in DEP17
is the technically best solution, but most people seem to be happy with
the level of support.

Thanks for working on making unstable more enjoyable!

Helmut

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

Hi!

I'd like to rephrase your quest. What you really want is unstable to be
less unstable. Whilst a number of people disagree with that notion, I

I don't think anybody disagrees that breaking a core packages and
stopping (nearly) all other DDs from doing development for a day or
two is acceptable.

I do agree that there are some developers who view unstable as a CI
system by itself, and we occasionally see certain DDs do multiple
uploads in a few days for the same package after they read the QA
system results. This is better than nothing, and maybe OK for
small/unimportant packages. For important packages I think it would be
vital to have enough CI should run before upload unstable, and use
unstable only to detect stuff that is hard to gate keep with automatic
testing (as you wrote in slightly different words).

One complaint I've seen about this workflow and one that I agree with is
the waiting time. Checking salsa-ci before uploading incurs an extra
context switch. What we'd really like to do is click the equivalent to

The CI waiting time is always less than human review waiting time. For
example in https://salsa.debian.org/debian/entr/-/merge_requests/10
the CI took 10 minutes, but it will take several days for a reviewer
to respond on the MR itself.

Also, I think a 10-minute break is a good thing for the author
themselves. The maintainer should get some fresh air and do the final
review of their changes after a small break to ensure nothing was done
too hastily.

"Auto-merge" (if the pipeline passes). As I write this, Sean or Ian will likely come along and say tag2upload. Working in this direction and
enabling a "upload if ci passes" would bring the salsa-ci experience to another level.

This would be super cool, in particular if it was extensible to get
triggered automatically when a new upload has had a minimum number of
approvers in the MR, and it would got merged and tagged and uploaded automatically.

Let me suggest that there are more ways to do this. Freexian is putting
a ton of effort into https://debusine.debian.net. It can do much of the
same tasks as salsa-ci already (with less flexibility). Extending it to
act as an upload-proxy that forwards your upload to the archive if
builds pass could be another option of improving unstable quality. In
earlier times, debomatic.debian.net was used as a pre-upload QA tool if
I remember correctly.

I used to use debomatic.debian.net, and I have been reading about
Debusine and the funding it gets from the Sovereign Fund. I tried to
use Debusine back in March, but the client requires Python 3.11+ which
my system does not have. I will need to make a new attempt soon. Thus,
I don't have any good opinion about it yet. However, as you probably
guess, I have a strong preference for workflows that integrate version
control and code reviews and CI. This is what Salsa does (and GitLab,
GitHub and alike).

Then the top-150 packages tend to be packages with unusual aspects. For instance, the git repositories for gcc-VER, glibc and linux all lack
upstream sources. For linux, there is a pipeline, but in order to
complete in a timely manner, it enables the pkg.linux.quick build
profile and the pipeline is elaborate with a complex extract-source
stage. It's not a matter of just enabling the pipeline for our core
packages but spending a lot of time fiddling with the settings until it

I have been reading the Kernel team Salsa CI before, and I am
impressed how the pipeline has been customized, and glad to see it was
green for the latest upload: https://salsa.debian.org/kernel-team/linux/-/pipelines/720187

I suspect you are right that some of the top-150 packages are special
case that can't use Salsa CI easily, but for example the setuptools
that had #1079175 yesterday would have been able to run Salsa CI
without anything custom (just a debian/gbp.conf file to define how it
needs to be built from git, see https://salsa.debian.org/python-team/packages/setuptools/-/commits/debian/latest/).

works. I guess that sending a working pipeline configuration for these
could improve the situation. Would it also make sense to source

I have done that - details visible in my MR history at https://salsa.debian.org/dashboard/merge_requests?scope=all&state=all&author_username=otto&search=%22enable+salsa%22
- and will continue to. For example, after #1071245 happened, I sent
to GnuPG an MR that enabled Salsa CI and included fixes to make it
green. Inspired by #1021336 I just sent one to PAM this week. Some
maintainers happily accept it, but surprisingly many reject, and I
have no backbone from any DEP or GR or policy to ask them to seriously
consider using Salsa CI. Some even say that they don't want to look at
MRs at all, no matter how many fixes might be pending there on a
silver plate. It is a lot of work to do these contributions and
frustrating when people reject them without any real reason, just some expression of personal preference.

Having some discussions on debian-devel@ might make people change
their personal preference in favour of a collective preference.

dedicated gitlab runners for heavy core packages to further reduce the feedback time and the impact of enabling CI there?

I am aware of many who happily would donate hardware for runners. I
guess this is mostly a question of documenting how to add runners so
people doing it can avoid reinventing the wheel or wasting unnecessary
time on failures that stem purely from inconsistent runner
configurations. Dedicated runners could also be faster as they could
be using local cache unlike random runners that can't properly benefit
from caching.

Given this I want to resonate what others already said. This seems more
like something to put effort into and make it work practically than
worth discussing. Doing a survey mail to the relevant maintainers for figuring out where to best direct that effort also seems sensible to me.

Thanks! I will publish a draft for comments and later proceed to send
targeted emails.

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

Am Tue, Aug 20, 2024 at 06:35:52PM -0700 schrieb Otto Kek�l�inen:

...

ACK to everything.

However, pushing for wider Salsa CI adoption I think makes sense as a
goal by itself, and I would be keen to hear what people think is a
reasonable way to proceed with that?

ACK. What about configuring Salsa that Salsa CI is switched on by
default?

Since 2021 I'm discussing with Debian Java team (last mail about this in
my DPL contact[1]) to not hide the "Switch Salsa CI on"-button which
makes it extra hard to get Salsa CI for these packages. Not sure about
other teams but IMHO the better strategy would be to make it extra
hard to switch of Salsa CI.

Kind regards
Andreas.

[1] https://lists.debian.org/debian-java/2024/06/msg00007.html

--
https://fam-tille.de

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

Hi,

Andreas Tille <[email protected]> ezt írta (időpont: 2024. aug. 22., Cs, 17:22):

Am Tue, Aug 20, 2024 at 06:35:52PM -0700 schrieb Otto Kekäläinen:

...

ACK to everything.

However, pushing for wider Salsa CI adoption I think makes sense as a
goal by itself, and I would be keen to hear what people think is a reasonable way to proceed with that?

ACK. What about configuring Salsa that Salsa CI is switched on by
default?

Since 2021 I'm discussing with Debian Java team (last mail about this in
my DPL contact[1]) to not hide the "Switch Salsa CI on"-button which
makes it extra hard to get Salsa CI for these packages. Not sure about
other teams but IMHO the better strategy would be to make it extra
hard to switch of Salsa CI.

I wholeheartedly agree with Otto's goals in his first email and wanted
to propose the same, just make Salsa CI opt-out instead of opt-in.
The default (recipes/debian.yml@salsa-ci-team/pipeline) should work
well for most packages.

There is another thread about enabling Salsa CI team-wide involving
multiple teams and it did not progress much: https://salsa.debian.org/salsa/support/-/issues/170
Enabling CI by default Salsa-wide would finally end those time
consuming discussions, too.

Cheers,
Balint

Kind regards
Andreas.

[1] https://lists.debian.org/debian-java/2024/06/msg00007.html

--
https://fam-tille.de

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

On Aug 23, Theodore Ts'o <[email protected]> wrote:

1) From a technical respective, what does Salsa CI buy me? Is it just

Maybe different and more Debian-specific tests than the one that you are running elsewhere? They should all be documented here: https://salsa.debian.org/salsa-ci-team/pipeline/ .

2) If I'm already using Github's CI, and have autopkgtest, what are
the benefits for using Salsa CI? (Especially given the amount of

Standardized Debian testing?

testing that I'm doing already, why should I spend more time enabling
Salsa CI?)

The effort needed to do so is so small that the question really should
be "why should I NOT spend a few seconds enabling Salsa CI?".

3) What's the simple recipe for enable Salsa CI?

salsa update_projects $NAMESPACE/$PROJECT \
--jobs yes --ci-config-path recipes/debian.yml@salsa-ci-team/pipeline

(salsa(1) is part of devscripts)

And then you can immediately schedule a new pipeline without having to
push a new commit:

https://salsa.debian.org/$NAMESPACE/$PROJECT/-/pipelines/new

4) Where do the results for Salsa CI end up getting reported?

https://salsa.debian.org/$NAMESPACE/$PROJECT/-/pipelines/, and you will
also get emails for pass/fail transitions.

--
ciao,
Marco

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

iHUEABYIAB0WIQQnKUXNg20437dCfobLPsM64d7XgQUCZsiJuwAKCRDLPsM64d7X gaooAQDSjJuj3Ok1KRKKpr20Fx1glvU4iG2FUDtibuAkVx+RIQD/f+18149syWut 72+l9OxfOx7YI5IUGCpGPQfoBZozHQA=
=v0v4
-----END PGP SIGNATURE-----

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

On Tue, Aug 20, 2024 at 06:35:52PM -0700, Otto Kek�l�inen wrote:

In short:
I would very much like to see all top-150 packages run Salsa CI at
least once before being uploaded to unstable. What people think is a reasonable way to proceed to reach this goal?

Since I'm the e2fsprogs (one of the top-150 packages) maintainer, I
thought I would take a look at this. And since I'm not super savvy
about Salsa --- e2fsprogs does have a Salsa git repro, but it's not
the primary. My primary git repositories are on github.com and
kernel.org. So I did a Google search for "Debian Salsa CI" --- and
found very little useful for me to understand more about Salsa CI.

For background, I am using Github's CI to make make sure that there
are no build regressions or new Salsa warnings on Linux, Windows, and
MacOS. I also do test builds using dgit, wired to git-buildpackage
and building using schroot; the test builds run a Lintian check and
run e2fsprogs's "make check" regression test. I'm not brave enough to
run Debian unstable on my Development system, so I will also do a
backport to Debian-testing built using git-buildpackage, and I do a
dogfood test run on my developer workstation before I upload. Also,
aspart of my upstream development, I am regularly doing manual test
builds on Debian stable, and create debian packages for e2fsprogs
which are integrated into the gce-xfstests[1] test appliance and make
sure there are no test regressions found when running xfstests to test
latest kernel (but which sometimes pick up e2fsprogrs regression,
although 99.99% of the time regressions are picked up using
e2fsprogs's built-in regression test suite).

[1] https://thunk.org/gce-xfstests

So here are the questions that would be **really** nice if it was
easily accessible to a prospective Debain maintainer:

1) From a technical respective, what does Salsa CI buy me? Is it just
doing a build and sources using "configure ; make ; make check"? Is
it doing a dpkg-buildackage? Is it going to do the equivalent of
autopkgtest? Maybe it's in the Debconf 2019 presentation, the video
is #5 on the Google searches, but I was too lazy to roll the video.
If slides were easily accessible, I probably would have looked at the
slides, but I wasn't able to easily find them.

2) If I'm already using Github's CI, and have autopkgtest, what are
the benefits for using Salsa CI? (Especially given the amount of
testing that I'm doing already, why should I spend more time enabling
Salsa CI?)

3) What's the simple recipe for enable Salsa CI?

4) Where do the results for Salsa CI end up getting reported?

Sorry if these were all stupid questions, but I couldn't find the
answers easily, so I figured I'd ask on this e-mail thread. :-)

- Ted

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

On Fri, Aug 23, 2024 at 03:08:11PM +0200, Marco d'Itri wrote:

Salsa CI?)

The effort needed to do so is so small that the question really should
be "why should I NOT spend a few seconds enabling Salsa CI?".

3) What's the simple recipe for enable Salsa CI?

salsa update_projects $NAMESPACE/$PROJECT \
--jobs yes --ci-config-path recipes/debian.yml@salsa-ci-team/pipeline

OK, more stupid questions. What is "$NAMESPACE"?

And I thought I saw something about a debin/salsa-ci.yml file?

And is this web page authoratative? Or just a false search positive?

https://salsa.debian.org/salsa-ci-team/pipeline#basic-use

It doesn't mention the "salsa" command at all, but maybe that isn't
the right web page. This goes back to my observation that it would be
helpful if there was better documentation to make life easier for
package maintainers.

- Ted

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

On Fri, Aug 23, 2024 at 04:00:25PM -0400, Theodore Ts'o wrote:

On Fri, Aug 23, 2024 at 03:08:11PM +0200, Marco d'Itri wrote:

Salsa CI?)

The effort needed to do so is so small that the question really should
be "why should I NOT spend a few seconds enabling Salsa CI?".

3) What's the simple recipe for enable Salsa CI?

salsa update_projects $NAMESPACE/$PROJECT \
--jobs yes --ci-config-path recipes/debian.yml@salsa-ci-team/pipeline

OK, more stupid questions. What is "$NAMESPACE"?

The parent of the repo.

And I thought I saw something about a debin/salsa-ci.yml file?

AFAIU it's optional.

And is this web page authoratative? Or just a false search positive?

https://salsa.debian.org/salsa-ci-team/pipeline#basic-use

It doesn't mention the "salsa" command at all

That salsa(1) command is just a fancy way to change the "CI/CD
configuration file" repo setting.


--
WBR, wRAR

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

iQJhBAABCgBLFiEEolIP6gqGcKZh3YxVM2L3AxpJkuEFAmbI8W8tFIAAAAAAFQAP cGthLWFkZHJlc3NAZ251cGcub3Jnd3JhckBkZWJpYW4ub3JnAAoJEDNi9wMaSZLh ajAP/iEbg9Hb1oQpPZk9+yGW/h/htCagyYcyVfg06bhj8SSOCQdraiPglLUZ9MOq av0GIzBC55bkzs6BgNfxgaJBA+7bMPuBw4fVcRJj3Y9nH93DlUlTiHki82eNMRD2 xKGuneB9kSWGkhSjcwcxKF/ff3sNDt7BDOoM7i7OG2l4+WZwEUhaIjMhmlXxY6RX mLomT2isI3W0anzG1ljwCGEkvdPk0hRNvaQ7PQZX02F1kbMGXWp0A30sN6zevOpB pTYXUZpja07V8gwta5aSvQJjInQ3E6HgAomGuOqnRFWmdVBTBcbwtRDcWKrXNuZq v0GpJJsoOFMbhSYEHpDCFnPP2iqdegYqT59ft7qFrxJOO8UCkZ2jf59IiN8faVHY dcqdgtngdryJiFqGmHMAwvOz9p3fYRGYJW5UfIaWGr04xdO1VZumCaHIBBTt7u2S Ky30KePJpdW2Qhaa0TIvWaC/RA2/HqmR+bzAHiNVUPIvZtlQW553POJQ2+tPk46p ytX6XkOq9mx870faYvQKgCfXUW3mdX1GDc2rzXTh8eUiiJqWj7+8wG5VOQXWN8vu R9b1m9UAvXJ/LaSb4pjT2jt2aEZwJ4Ke2Mspal9Wtfkv+9CAykhjkNVqPOEhdF0f XLTP6ZcRlSKHspQb3V2yMDIzVrEKCZDMQRByA2Qnch5W/LWr
=5vfA
-----END PGP SIGNATURE-----

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

El 23/08/24 a las 16:00, Theodore Ts'o escribi�:

On Fri, Aug 23, 2024 at 03:08:11PM +0200, Marco d'Itri wrote:

Salsa CI?)

The effort needed to do so is so small that the question really should
be "why should I NOT spend a few seconds enabling Salsa CI?".

3) What's the simple recipe for enable Salsa CI?

salsa update_projects $NAMESPACE/$PROJECT \
--jobs yes --ci-config-path recipes/debian.yml@salsa-ci-team/pipeline

OK, more stupid questions. What is "$NAMESPACE"?

And I thought I saw something about a debin/salsa-ci.yml file?

And is this web page authoratative? Or just a false search positive?

https://salsa.debian.org/salsa-ci-team/pipeline#basic-use

It doesn't mention the "salsa" command at all, but maybe that isn't
the right web page.

That is the right web page.

This goes back to my observation that it would be
helpful if there was better documentation to make life easier for
package maintainers.

ACK.

And probably the reason why the salsa command doesn't appear there is
because of my preferred way to configure the pipeline in a package is
adding the debian/salsa-ci.yml file. The Gitlab setting makes
customisations more difficult, and more difficult for others that don't
have read access to those settings. (Yes, this is not what is written in
the documentation, and I probably should create MR to discuss it.)

If you have any other questions, don't hesitate to ask! :-)

-- Santiago

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

iHUEABYIAB0WIQR+lHTq7mkJOyB6t2Un3j1FEEiG7wUCZskP/AAKCRAn3j1FEEiG 7zP3AQCs0AUkb0+liHwuJwLZ5x74tjaclT8AQbMP1oai6lcuwwD9GmLOQX+klnp0 HTpFuVFqcn3LysxG+gyqYEemgPjxkQ4=
=R0Lq
-----END PGP SIGNATURE-----

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

On Aug 23, Theodore Ts'o <[email protected]> wrote:

salsa update_projects $NAMESPACE/$PROJECT \
--jobs yes --ci-config-path recipes/debian.yml@salsa-ci-team/pipeline

OK, more stupid questions. What is "$NAMESPACE"?

Whatever you see after "salsa.debian.org/" in the URL.

And I thought I saw something about a debin/salsa-ci.yml file?

You do not need one, if your pipeline does not need any customization.
You can always add it later and change the path with salsa(1) or in the
Salsa UI.

And is this web page authoratative? Or just a false search positive?

https://salsa.debian.org/salsa-ci-team/pipeline#basic-use

It doesn't mention the "salsa" command at all, but maybe that isn't
the right web page. This goes back to my observation that it would be helpful if there was better documentation to make life easier for
package maintainers.

It is authoritative, but apparently I was better than the actual
CI maintainers at figuring out the simplest possibile recipe. :-)

--
ciao,
Marco

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

iHUEABYIAB0WIQQnKUXNg20437dCfobLPsM64d7XgQUCZskNpQAKCRDLPsM64d7X gQEKAP0YGzurocX/NmUUysmDuMbP+0/67+9gNNPkGs5miOWmeAD9GXBqZvJEedF4 Z0dH8FSVkN45sJtDyW+GGTC+M73+uwY=
=nZRb
-----END PGP SIGNATURE-----

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

Le mer. 21 août 2024 à 03:36, Otto Kekäläinen <[email protected]> a écrit :

Hi!

In short:
I would very much like to see all top-150 packages run Salsa CI at
least once before being uploaded to unstable. What people think is a reasonable way to proceed to reach this goal?

Background:
We have had several cases recently where an upload to Debian unstable
causes widespread failure in unstable, and it could have been easily prevented if Salsa CI pipeline had run for the package and revealed
the problem before upload to archive for everyone to suffer.

This message was prompted by the fact that right now we have a massive
large of Python packages affected by the "No module named 'packaging'"
bug [1] which would have been caught by Salsa CI running the
autopkgtest job before upload [2]. I don't want to blame maintainers
for missing on some details while doing new releases - it happens. But systematically not using available and easy testing facilities does
annoy me.

We can't have Salsa CI for all of Debian overnight, but at least
widespread issues could be mitigated significantly by having Salsa CI
at least on the top-150 or top-500 packages.

We do not have stats on how many packages use Salsa CI, but we have
stats on how many are not even hosted on Salsa:

```
curl -LO https://trends.debian.net/vcs-hosting_unstable-packages.csv
curl -LO https://popcon.debian.org/sourcemax/by_inst
for x in $(tail -n +13 by_inst | head -n 150 | cut -c 7-25)
do
grep -E "^$x," vcs-hosting_unstable-packages.csv
done | grep -v salsa

dpkg,1.22.10,other
coreutils,9.4-3.1,no vcs
acl,2.3.2-2,other
zlib,1:1.3.dfsg+really1.3.1-1,no vcs
attr,1:2.5.2-1,other
hostname,3.23+nmu2,no vcs
readline,8.2-4,no vcs
e2fsprogs,1.47.1-1,other
base-files,13.3,no vcs
bash,5.2.21-2.1,not git
expat,2.6.2-1,no vcs
gettext,0.22.5-2,no vcs
diffutils,1:3.10-1,no vcs
libbsd,0.12.2-1,other
sqlite3,3.46.0-1,no vcs
dmidecode,3.6-1,other
pciutils,1:3.13.0-1,other
libxdmcp,1:1.1.2-3,git on alioth
wget,1.24.5-2,no vcs
file,1:5.45-3,other
laptop-detect,0.16,other
fuse,2.9.9-8.1,no vcs
lsof,4.95.0-1.1,no vcs
scowl,2020.12.07-2,other
emacsen-common,3.0.5,no vcs
libusb-1.0,2:1.0.27-1,no vcs
setuptools,70.3.0-2,no vcs
traceroute,1:2.1.5-1,no vcs
liblockfile,1.17-1,github
```

If you are a maintainer of a top-150 package and want help in getting
it on Salsa and have Salsa CI activated, just email debian-salsa-ci@,
and we will guide you through how to best run `gbp import-dscs --debian-branch=debian/latest --upstream-branch=upstream/latest --pristine-tar`, what to put in a README.source how to activate Salsa
CI with potential customizations you feel are make sense. We have
already done this to many projects, but as surprisingly many
maintainers prefer not to receive contributions, we encourage those
who want to have help to reach out themselves.

When I proposed DEP18[1] my main motivation was to get more packages
on git and on salsa.debian.org so that it is easier to collaborate on
the next upload with the maintainer and all interested contributors
before the upload is done. Collaborating on packages by NMUs is just
not a modern and efficient way to collaborate.

On top of this, I also wished that packages would use Salsa CI, at
least once before the upload. This helps the maintainer get assurance
of the package health before upload. Running Salsa CI on Merge
Requests automatically helps contributors get immediate feedback, and
it also gives the maintainer assurance that contributions don't cause
easily testable regressions.

Many people raised concerns on DEP18, and some of them are valid, and
I will continue to ponder about it and how to restructure the proposal
to foster collaboration without alienating any of our current
maintainers who have a well optimized existing workflow.

However, pushing for wider Salsa CI adoption I think makes sense as a
goal by itself, and I would be keen to hear what people think is a
reasonable way to proceed with that?

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1079175, https://salsa.debian.org/salsa-ci-team/pipeline/-/issues/376
[2]
https://salsa.debian.org/python-team/packages/setuptools/-/jobs/6156348
[3] https://salsa.debian.org/dep-team/deps/-/merge_requests/8

A bunch of packages I know (nodejs, receptor to name a few) have salsa CI failures, but no sbuild failures.
It would be perfect if the build process was exactly the same.

Jérémy

<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le mer. 21 août 2024 à 03:36, Otto Kekäläinen &lt;<a href="mailto:[email protected]">[email protected]</a>&gt; a écrit :<br></div><blockquote class=
"gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi!<br>

In short:<br>
I would very much like to see all top-150 packages run Salsa CI at<br>
least once before being uploaded to unstable. What people think is a<br> reasonable way to proceed to reach this goal?<br>


Background:<br>
We have had several cases recently where an upload to Debian unstable<br> causes widespread failure in unstable, and it could have been easily<br> prevented if Salsa CI pipeline had run for the package and revealed<br>
the problem before upload to archive for everyone to suffer.<br>

This message was prompted by the fact that right now we have a massive<br> large of Python packages affected by the &quot;No module named &#39;packaging&#39;&quot;<br>
bug [1] which would have been caught by Salsa CI running the<br>
autopkgtest job before upload [2]. I don&#39;t want to blame maintainers<br> for missing on some details while doing new releases - it happens. But<br> systematically not using available and easy testing facilities does<br>
annoy me.<br>

We can&#39;t have Salsa CI for all of Debian overnight, but at least<br> widespread issues could be mitigated significantly by having Salsa CI<br>
at least on the top-150 or top-500 packages.<br>

We do not have stats on how many packages use Salsa CI, but we have<br>
stats on how many are not even hosted on Salsa:<br>

```<br>
curl -LO <a href="https://trends.debian.net/vcs-hosting_unstable-packages.csv" rel="noreferrer" target="_blank">https://trends.debian.net/vcs-hosting_unstable-packages.csv</a><br>
curl -LO <a href="https://popcon.debian.org/sourcemax/by_inst" rel="noreferrer" target="_blank">https://popcon.debian.org/sourcemax/by_inst</a><br>
for x in $(tail -n +13 by_inst | head -n 150  | cut -c 7-25)<br>
do<br>
  grep -E &quot;^$x,&quot; vcs-hosting_unstable-packages.csv<br>
done | grep -v salsa<br>

dpkg,1.22.10,other<br>
coreutils,9.4-3.1,no vcs<br>
acl,2.3.2-2,other<br>
zlib,1:1.3.dfsg+really1.3.1-1,no vcs<br>
attr,1:2.5.2-1,other<br>
hostname,3.23+nmu2,no vcs<br>
readline,8.2-4,no vcs<br>
e2fsprogs,1.47.1-1,other<br>
base-files,13.3,no vcs<br>
bash,5.2.21-2.1,not git<br>
expat,2.6.2-1,no vcs<br>
gettext,0.22.5-2,no vcs<br>
diffutils,1:3.10-1,no vcs<br>
libbsd,0.12.2-1,other<br>
sqlite3,3.46.0-1,no vcs<br>
dmidecode,3.6-1,other<br>
pciutils,1:3.13.0-1,other<br>
libxdmcp,1:1.1.2-3,git on alioth<br>
wget,1.24.5-2,no vcs<br>
file,1:5.45-3,other<br>
laptop-detect,0.16,other<br>
fuse,2.9.9-8.1,no vcs<br>
lsof,4.95.0-1.1,no vcs<br>
scowl,2020.12.07-2,other<br>
emacsen-common,3.0.5,no vcs<br>
libusb-1.0,2:1.0.27-1,no vcs<br>
setuptools,70.3.0-2,no vcs<br>
traceroute,1:2.1.5-1,no vcs<br>
liblockfile,1.17-1,github<br>
```<br>

If you are a maintainer of a top-150 package and want help in getting<br>
it on Salsa and have Salsa CI activated, just email debian-salsa-ci@,<br>
and we will guide you through how to best run `gbp import-dscs<br> --debian-branch=debian/latest --upstream-branch=upstream/latest<br> --pristine-tar`, what to put in a README.source how to activate Salsa<br>
CI with potential customizations you feel are make sense. We have<br>
already done this to many projects, but as surprisingly many<br>
maintainers prefer not to receive contributions, we encourage those<br>
who want to have help to reach out themselves.<br>

When I proposed DEP18[1] my main motivation was to get more packages<br>
on git and on <a href="http://salsa.debian.org" rel="noreferrer" target="_blank">salsa.debian.org</a> so that it is easier to collaborate on<br>
the next upload with the maintainer and all interested contributors<br>
before the upload is done. Collaborating on packages by NMUs is just<br>
not a modern and efficient way to collaborate.<br>

On top of this, I also wished that packages would use Salsa CI, at<br>
least once before the upload. This helps the maintainer get assurance<br>
of the package health before upload. Running Salsa CI on Merge<br>
Requests automatically helps contributors get immediate feedback, and<br>
it also gives the maintainer assurance that contributions don&#39;t cause<br> easily testable regressions.<br>

Many people raised concerns on DEP18, and some of them are valid, and<br>
I will continue to ponder about it and how to restructure the proposal<br>
to foster collaboration without alienating any of our current<br>
maintainers who have a well optimized existing workflow.<br>

However, pushing for wider Salsa CI adoption I think makes sense as a<br>
goal by itself, and I would be keen to hear what people think is a<br> reasonable way to proceed with that?<br>


[1] <a href="https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1079175" rel="noreferrer" target="_blank">https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1079175</a>,<br>
<a href="https://salsa.debian.org/salsa-ci-team/pipeline/-/issues/376" rel="noreferrer" target="_blank">https://salsa.debian.org/salsa-ci-team/pipeline/-/issues/376</a><br>
[2] <a href="https://salsa.debian.org/python-team/packages/setuptools/-/jobs/6156348" rel="noreferrer" target="_blank">https://salsa.debian.org/python-team/packages/setuptools/-/jobs/6156348</a><br>
[3] <a href="https://salsa.debian.org/dep-team/deps/-/merge_requests/8" rel="noreferrer" target="_blank">https://salsa.debian.org/dep-team/deps/-/merge_requests/8</a></blockquote><div><br></div><div>A bunch of packages I know (nodejs, receptor to name a
few) have salsa CI failures, but no sbuild failures.</div><div>It would be perfect if the build process was exactly the same.</div><div><br></div><div>Jérémy </div></div></div>

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

On Thu, 22 Aug 2024 00:46:09 -0700, Otto Kek�l�inen wrote:

Also, I think a 10-minute break is a good thing for the author
themselves. The maintainer should get some fresh air and do the final
review of their changes after a small break to ensure nothing was done
too hastily.

That depends on the amount, type, and size of packages one is working
on.
In the Debian perl Group we have 4000 packages, and there are days
with 5-10 new upstream releases.
Many of the packages are trivial, so updating them (including
autopkgtests and blhc and lintian and whatnot) doesn't take longer
than 5 minutes.

So I can decide to wait for salsa CI for 10 minutes or update 2 more
packages in the same time. (Or try to context switch and keep a stack
of where I was etc.)

I totally see the value of salsa CI for complex packages, for running
things which can't be run locally, for merge requests, etc.

But there are also situations where it doesn't help. -- I guess what
I want to say is that salsa CI is a useful tool, and like every tool,
it has its places but it's not a panacea.


Cheers,
gregor

--
.''`. https://info.comodo.priv.at -- Debian Developer https://www.debian.org
: :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06
`. `' Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
`-

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

iQKTBAEBCgB9FiEE0eExbpOnYKgQTYX6uzpoAYZJqgYFAmbKcPRfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEQx RTEzMTZFOTNBNzYwQTgxMDREODVGQUJCM0E2ODAxODY0OUFBMDYACgkQuzpoAYZJ qgbMaw/+LXoYMNhs+c85klqQQ0hZ9+xFedYOBsJcU85t8AL8Kc3t3uDYjNs+Ufaf UrWRfIdd/sZr4XxSH77icRBM7W/CXGPa49s1tncBVbieqD/3Tv5vGCkLNBPcOMux lU+DviLwkBsfaRBHDmCP/ve+WWCHARbNPYBdiBMVIkNHtY2FgqRoyRflJDuTc/L+ QlsBpBh4d5RMBqMrpF1pmucCZFJMuN8lso1SHfCZeHwroB1S7CcR/c/v91/eMRNo Wy2yf1fPTOuxz0vf+bxtIaDoaP24yi6WxAW+OPlylzPti8Z2MLZk97CUAfIX+etq bPFjLfAqFsCKmlJG1Rxpa2aThgk20rdtOkhLARIppCPNeYoM3KHHZIknIRflzByB EAAYBQyW1Kxar/TUz/IFLkC/WLhr9CVaXR71wbAYSMFZI/9uUhPv/qke8Jc57u4S QGCJFWH6VMRiJOCcXiOP7W16+gXJqlhLqbrJtQ6jT4cHROp+y9B3HMUhBXzhoDRb
trJk7e1w

On 25/08/24 01:46, gregor herrmann wrote:

Many of the packages are trivial, so updating them (including
autopkgtests and blhc and lintian and whatnot) doesn't take longer
than 5 minutes.

So I can decide to wait for salsa CI for 10 minutes or update 2 more
packages in the same time. (Or try to context switch and keep a stack
of where I was etc.)

This is why "tag2upload once pipeline passes" is needed. (And more runners.)

Regards,

--
Gioele Barabucci.

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

To: [email protected]

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

SWwgMjUvMDgvMjAyNCAwODoyNywgR2lvZWxlIEJhcmFidWNjaSBoYSBzY3JpdHRvOg0KPiBP biAyNS8wOC8yNCAwMTo0NiwgZ3JlZ29yIGhlcnJtYW5uIHdyb3RlOg0KPj4gTWFueSBvZiB0 aGUgcGFja2FnZXMgYXJlIHRyaXZpYWwsIHNvIHVwZGF0aW5nIHRoZW0gKGluY2x1ZGluZw0K Pj4gYXV0b3BrZ3Rlc3RzIGFuZCBibGhjIGFuZCBsaW50aWFuIGFuZCB3aGF0bm90KSBkb2Vz bid0IHRha2UgbG9uZ2VyDQo+PiB0aGFuIDUgbWludXRlcy4NCj4+DQo+PiBTbyBJIGNhbiBk ZWNpZGUgdG8gd2FpdCBmb3Igc2Fsc2EgQ0kgZm9yIDEwIG1pbnV0ZXMgb3IgdXBkYXRlIDIg bW9yZQ0KPj4gcGFja2FnZXMgaW4gdGhlIHNhbWUgdGltZS4gKE9yIHRyeSB0byBjb250ZXh0 IHN3aXRjaCBhbmQga2VlcCBhIHN0YWNrDQo+PiBvZiB3aGVyZSBJIHdhcyBldGMuKQ0KPg0K PiBUaGlzIGlzIHdoeSAidGFnMnVwbG9hZCBvbmNlIHBpcGVsaW5lIHBhc3NlcyIgaXMgbmVl ZGVkLiAoQW5kIG1vcmUgDQo+IHJ1bm5lcnMuKQ0KDQpBY3R1YWxseSBJIHB1c2gga2VlcGlu ZyAiVU5SRUxFQVNFRCIgZXZlbiBpbiBjYXNlcyB3aGVyZSBpcyBuZWFyIHN1cmUgdG8gDQpi ZSByZWFkeSBiZWNhdXNlIEkgd2FudCBzZWUgc2Fsc2EgQ0kgcmVzdWx0IGFuZCBkbyBmaXhl cy9pbXByb3ZlbWVudHMgaWYgDQpuZWVkZWQgYmVmb3JlIHJlbGVhc2UsIHNob3J0bHkgYWZ0 ZXIgaW4gbWFqb3Igb2YgY2FzZSBJIGRpZCBhIHJlbGVhc2UgDQpjb21taXQgd2l0aCBvbmx5 IGZpbmFsaXplIHRoZSBkL2NoYW5nZWxvZyBhbmQgSSBza2lwIHNhbHNhIENJIG9uIHRoYXQg DQood2l0aCAiLW8gY2kuc2tpcCIgb24gZ2l0IHB1c2gpIHRvIGF2b2lkIHdhc3RlIHNhbHNh IENJIHJlc291cmNlIGZvciANCnNhbWUgcmVzdWx0IG9mIHRoZSBwcmV2aW91cy4NCg0KV2ls bCB0YWcydXBsb2FkIGJlIHVzYWJsZSBpbiB0aGF0IGNhc2UgKHdpdGggQ0kgc2tpcHBlZCBv biBsYXRlc3QgY29tbWl0IA0Kd2l0aCBvbmx5IGZpbmFsaXplIG9mIGQvY2hhbmdlbG9nLCBh bmQgc3VjY2Vzc2Z1bGwgb2YgdGhlIHByZXZpb3VzKSBvciANCndpbGwgdGhlcmUgYmUgYSBu ZWVkIGZvciBzYWxzYSBDSSBzdWNjZXNzZnVsbHkgY29tcGxldGVkb24gdGhlIHNwZWNpZmlj IA0KcmVsZWFzZSBjb21taXQ/DQoNCg==

--------------3x1zpEmCBvxFNB60gm1R9lEA--

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

wsF5BAABCAAjFiEELEHRfLe4S9D5+1GzaAZorpB/EB0FAmbLFiIFAwAAAAAACgkQaAZorpB/EB3Q 7A//QnQ0P4jKsB3ODHeCtIDKS0clWnHx0NDr/8n4Nj6KRO9hsTO7AjuduTXCfXmUqhGBw1PN2cvK 59O2nCbeKdn2gER/W82LbKceNrtufPaDgosF9IA8Mv39pgQmxwTswlNtqUseeH5hxaUSVt8/kVdF DynDWkWD3/RhjkoDeX0hekvjJSJKreTxZMh8WnDQEeo23vTgod6WblLVTXUgyCLx9eSp0m/WqPUN 2zHMkN7ZMnSUw8ZjEcboSN+TqALdPuCl13iGaFrKW5R/YAEYL5NR4UTMTO88uOOSG8DGt3Mm4/54 Kiw0vJDPzpngR0D9D1NavHGIH9e6if+QgVVyQfpvvAE6iE/pCwRpNTS6BuoMn7m8CT5eNC6Od3HL ZVHBVivkBA20RxuHN9wIZHPYEOBDucJps/b5XpKuwGhTGtG6S6G54ss9H313ujpWnPYjcxWfRibW Cf/sOKk/zP3Ni/Jon+0vXHWwmbgVxe1vrjdX2Zpny3X8ie+uToP9uKV5Sd8cIJTeQaVmM1TTxFgR b4CiLeC8Ar52jcvE3wEQZvymIFvETRni5aPYFWiQlA8pbztKB1ke2yK+DCtAzNj6o+yaSDdEDeml EHJkNV2OvYhIiKyR3ujq6cq1AeBIoLXtcOFj3BcpyLr9p+ovsvd2L5k6yerS05ghoM8e2Qm86pEM Hyw=
=qF5k
-----END PGP SIGNATURE-----

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

On Sun, 25 Aug 2024 13:31:45 +0200, Fabio Fantoni
<[email protected]> wrote:

Actually I push keeping "UNRELEASED" even in cases where is near sure to
be ready because I want see salsa CI result and do fixes/improvements if >needed before release, shortly after in major of case I did a release
commit with only finalize the d/changelog and I skip salsa CI on that
(with "-o ci.skip" on git push) to avoid waste salsa CI resource for
same result of the previous.

Will tag2upload be usable in that case (with CI skipped on latest commit
with only finalize of d/changelog, and successfull of the previous) or
will there be a need for salsa CI successfully completedon the specific >release commit?

CI could skip if only changelog changed. That would be helpful for my
packages and my workflow as well.

Greetings
Marc
--
---------------------------------------------------------------------------- Marc Haber | " Questions are the | Mailadresse im Header Rhein-Neckar, DE | Beginning of Wisdom " |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402

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

Hi Helmut!

Let me suggest that there are more ways to do this. Freexian is putting
a ton of effort into https://debusine.debian.net. It can do much of the same tasks as salsa-ci already (with less flexibility). Extending it to
act as an upload-proxy that forwards your upload to the archive if
builds pass could be another option of improving unstable quality. In earlier times, debomatic.debian.net was used as a pre-upload QA tool if
I remember correctly.

I used to use debomatic.debian.net, and I have been reading about
Debusine and the funding it gets from the Sovereign Fund. I tried to
use Debusine back in March, but the client requires Python 3.11+ which
my system does not have. I will need to make a new attempt soon. Thus,

Ok, I tested Debusine again and managed to build a package following
the tutorial with the build definition:

```
build_components:
- any
- all
environment: debian/match:codename=trixie:variant=sbuild
host_architecture: amd64
input:
source_artifact: 507533
```

However, I struggle to figure out how to do something similar to what
Salsa CI. Do you happen to have at hand a complete build+test
definition I could copy-paste and test?

Also, I see the build reports 'success' despite Lintian failing on an
error. Additionally, seems this system does not send out email
notifications?

At https://freexian-team.pages.debian.net/debusine/reference/faq.html
it says in two ways that the core design philosophy is to invent
something new instead of using something existing, as the existing
thing isn't controlled by Debian. That makes sense in some situations,
but in the case of a code forge with review, build and test features,
it seems that trying to build a new custom thing from scratch is
perhaps a bit too ambitious?

GitLab isn't perfect, but I'd say that the setup Debian has now with salsa.debian.org is pretty good, and I'd rather polish it than fund
building a new system from scratch. I am however willing to test
Debusine a bit more to see if it has hidden powers that could be
amazing.

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