On Friday, 18 August 2023 19:54:55 CEST Carles Pina i Estany wrote: > > Ha! I wasn't aware of the aptly option > (https://salsa.debian.org/salsa-ci-team/pipeline/#using-automatically-built-> > apt-repository and SALSA_CI_DISABLE_APTLY=0). > I think that I might have re-invented the wheel in a tiny part of > Debusine CI/CD.
It is certainly a way of propagating packages to those that might need them. However, the instructions indicating how a package might access these dependencies appear to be deficient. It does not appear to be sufficient to merely specify the dependency package repositories and mark them as trusted. Doing that will just cause the repositories to be regarded as ignored and the GPG keys signalled as unrecognised. So, the GPG keys need to be obtained. This is a hassle because something like wget is needed to do that, and then apt has to be persuaded not to fail in an opaque way. So the modified recipe is something like this: before_script: - apt-get update - NON_INTERACTIVE=1 apt-get install -y wget - echo "deb https://salsa.debian.org/moin-team/emeraldtree/-/jobs/4575438/ artifacts/raw/aptly unstable main" | tee /etc/apt/sources.list.d/pkga.list ... - wget -q -O /etc/apt/trusted.gpg.d/emeraldtree.asc https:// salsa.debian.org/moin-team/emeraldtree/-/jobs/4575438/artifacts/raw/aptly/ public-key.asc ... - apt-get update This seems to make the various jobs happy, but the one that I was most concerned with remains unhappy! I don't actually need the dependencies for anything other than autopkgtest, but that job employs its own environment where the above recipe has no effect. So, what I now need to do is to find out how I can make the new packages available to autopkgtest specifically. > I will point out at some things that might safe some time to you > (great) or not (ignore! :-) ): > > debusine's .gitlab-ci.yml: > https://salsa.debian.org/freexian-team/debusine/-/blob/devel/.gitlab-ci.yml This is definitely useful for examples of the CI definition syntax and how hidden jobs can be used to provide additional script fragments. [...] > The job autopkgtest, via debci command, runs autopkgtest: > https://salsa.debian.org/freexian-team/debusine/-/jobs/4574458#L65 The difficult thing appears to be the configuration of this testing environment. One approach might involve overriding the existing job definitions to incorporate the injection of new packages. [...] > It's possible for sure. Other people in this list might come up with a > different idea. I don't have almost any experience with Debian > packaging, but I have some experience on the salsa CI. So I might be > giving you solutions that might be sub-optimal! :-) I think that you are giving me some good ideas at least. I do feel that I am encountering problems that must have been encountered many times before, but I could imagine that people do not use these tools in this way or have different expectations of what they are able to accomplish. As for Debian's tooling, I consider it rather chaotic. When I previously did packaging, things like pbuilder were still in use, being slowly pushed aside by sbuild and probably other things that are now forgotten or obsolete. There always seems to be new things coming along, new mixtures of technologies, and the potential for more confusion and uncertainty. Paul
