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. [...] > 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. > 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 It defines a package list file and uses wget to obtain each repository's public key. Fortunately, wget works at the "script" level of the jobs involved, whereas it didn't work at what must have been the global "before_script" level (suggested in the documentation) and needed to be installed first. To make autopkgtest and piuparts find the packages, the repository details are then copied into the appropriate location in each case. However, since such customisation is not readily incorporated into the existing job descriptions, I have had to duplicate the existing job description code and insert additional statements in the script sections. As a consequence of these changes, the extra packages are found and installed within the environments concerned. This is enough to make the piuparts job succeed, but autopkgtest still fails. Fortunately, that may be due only to problems with the actual tests: I think the upstream maintainers may have made some errors. [...] > 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 course, if the packages enter the Debian archives, all of this extra effort will be made largely redundant, anyway, even if coordinated testing of new package versions would still benefit from such effort. [...] > I don't know if an FAQ, conventions, best practises or something might > help... I think that the documentation could be reworked, but that is largely true for a lot of the materials available for Debian. And since some of that documentation resides on the Debian Wiki, that is another reason why I am trying to move this particular packaging exercise forwards. Thanks once again! Paul
