Hi,
On 20 Aug 2023 at 00:49:20, Paul Boddie wrote: > On Saturday, 19 August 2023 20:32:59 CEST Carles Pina i Estany wrote: > > > > Quick answer for now... > > And a very quick reply from me... :-) > > [...] > > > I don't know if a .asc files are allowed. Actually, from my > > .bash_history: > > --- > > wget -O- https://www.virtualbox.org/download/oracle_vbox_2016.asc | sudo gpg > > --dearmor --yes --output /usr/share/keyrings/oracle-virtualbox-2016.gpg --- > > > > (I was following instructions, I didn't try leaving the .asc file there) > > They are allowed in recent versions of apt, as confirmed by the man page. > > [...] Cool! I'll try next time (I cannot see it on my man apt-get, apt or sources.list on bookworm but I might need a newer apt) > > You could try using: > > --- > > variables: > > SALSA_CI_AUTOPKGTEST_ARGS: '--setup-commands=ci/setup-the-repo.sh' > > --- > > (and write and ship the ci/setup-the-repo.sh in the repo, do whatever > > you need there) > > This could be very useful. Also available (and also added last year for a similar case): ----- variables: SALSA_CI_PIUPARTS_PRE_INSTALL_SCRIPT: 'ci/pin-django-from-backports.sh' ----- (and SALSA_CI_PIUPARTS_POST_INSTALL_SCRIPT) > > Or, probably even better but less flexible: > > --- > > variables: > > SALSA_CI_AUTOPKGTEST_ARGS: '--add-apt-source="deb http://MIRROR SUITE > > COMPONENT' --- > > (I found add-apt-source via "man autopkgtest" in TEST BED SETUP OPTIONS. > > I haven't used add-apt-source, I don't know what happens with the gpg > > keys... but you could use [trusted=yes] :-| ) > > > > For the MIRROR you have salsa variables that might help if you need to > > specify the pipeline. > > So could this. > > > > So, what I now need to do is to find out how I can make the new packages > > > available to autopkgtest specifically. > > > > We will get there! (one way or another) > > Well, I have engineered something very inelegant, revealed in full here: > > https://salsa.debian.org/moin-team/moin/-/blob/debian/master/debian/salsa-ci.yml I, more or less, see what you did! Interesting approach, but if you could use the variables and ship the shell script it might reduce some duplication between jobs (if possible, I haven't look into too much detail in your case) and more importantly you might be able to use the standard "autopkgtest" or "piuparts" (instead of redefining them). Just last week I created a new autopkgtest (I have it running on bookworm and bullseye). It's done this way: ------ autopkgtest-bullseye: extends: .test-autopkgtest variables: RELEASE: "bullseye-backports" SALSA_CI_AUTOPKGTEST_ARGS: '--setup-commands=ci/pin-django-from-backports.sh --skip-test=debusine-doc-linkcheck' ------ Or, for more context: https://salsa.debian.org/freexian-team/debusine/-/blob/add-bullseye-support/.gitlab-ci.yml#L84 It ends up having "autopkgtest" and "autopkgtest-bullseye". But using the variable SALSA_CI_DISABLE_AUTOPKGTEST I could disable the one without my extends. [...] > > hopefully SALSA_CI_AUTOPKGTEST_ARGS will help you. I added this in > > salsa-ci/pipeline last year because I was trying to do a similar thing > > to what you are doing (I had to pin a package from backports). > > > > (I'm just a user of salsa-ci/pipeline, not a member of the team neither > > I can speak for them!) > > If this can simplify what I've done, which is really quite horrible, then I > will adopt it instead. The way that the artefacts of the dependencies are > bound up in specifically numbered jobs is also particularly unfortunate. Of If it's in the same pipeline: you don't need the numbers to get the artifacts (the .deb files from build). For the aptly generated artifact: I will investigate this tomorrow (to fetch it and try to use) (I want to replace some code that I did with the aptly repo, if possible). Cheers, -- Carles Pina i Estany https://carles.pina.cat || Wiktionary translations: https://kamus.pina.cat
