Re: Sponsorship request: python-ping3
El 18/10/23 a las 00:56, Carles Pina i Estany escribió: > > Hi, > > On 17 Oct 2023 at 22:42:27, Carles Pina i Estany wrote: > > [...] > > > > 2. Regarding testing, this package is a bit a mess. First you probably > > > realized that you can't run tests at buildtime because a raw socket > > > requires root privilege. I see you designed custom autopkgtest to > > > > yep... > > > > [...] > > > > > From there you have two options: the first one is to drop the > > > Testsuite: field and keep the two tests you designed and call it a > > > day, or you drop it and write a third test stanza in > > > debian/tests/control with a shell script you'd also have to write > > > that moves the tests to the tmp dir autopkgtest creates, puts > > > localhost in /etc/hosts and then run tests. In that case you need > > > to add pytest to the dependencies of this test stanza. > > > > Sounds doable no problem, I'll try it this evening and see how it goes. > > From doable to "I'm 99% sure that not possible". I cannot send pings > from autopkgtest in salsa with any software. > > Side note: I remembered that when using "needs-internet": HTTP GET > requests (even using hostnames) works. This is my first package for > Debian, but I've used autopkgtest with needs-internet to run a sphinx > "linkcheck" and it was working correctly. > > I've checked that no ICMP replies even using the standard ping binary > from iputils-ping: > - > Test-Command: set +e ; ping -c 4 8.8.8.8 ; ping -c 4 example.com ; curl -s -I > https://en.wikipedia.org ; curl -s -L https://en.wikipedia.org | head -5 > Depends: python3-ping3, iputils-ping, curl > Restrictions: needs-root, needs-internet > Features: test-name=test-real-ping > - > That's in: > https://salsa.debian.org/carlespina/python-ping3/-/blob/autopkgtest-connectivity/debian/tests/control > > The output: > https://salsa.debian.org/carlespina/python-ping3/-/jobs/4822521#L213 > > 4 packets transmitted, 0 received, 100% packet loss, time 3059ms > 4 packets transmitted, 0 received, 100% packet loss, time 3079ms ... AFAIU, there are network restrictions on salsa. Reaching HTTPS in the outside world should work. But I am not sure about ICMP. FWIW, this is probably overengineering, but it is also possible to use namespaces to avoid reaching INET, pinging from one namespace to the other. As example: https://salsa.debian.org/debian/isc-dhcp/-/blob/master/debian/tests/client-server Cheers! -- Santiago signature.asc Description: PGP signature
Re: Publishing multiple packages with aptly in Salsa CI
Hi, > Hello, > > A few weeks ago, I asked about techniques for making new packages available > to > other new packages so that the autopkgtest job could be run successfully in a > pipeline in the Salsa CI environment. Eventually, this was made to work by > taking advantage of the aptly job defined in the standard Debian CI pipeline. > > To recap, the aptly job publishes the package built during the execution of a > pipeline by creating a dedicated apt-compatible package repository just for > that package. Such repositories can then be made available to various jobs in > the pipeline of another package, allowing the successful installation of that > package and its dependencies, including new packages, and the successful > execution of jobs like autopkgtest. > > However, one other thing I wanted to achieve was to take the complete set of > new packages and to publish them in a single package repository. This would > allow people to install and test the built packages in a more convenient > fashion than asking them to hunt down each built package from job artefacts > or > to build the packages themselves. > > Obviously, the aptly job in the standard Debian CI pipeline publishes a > single > package (or maybe a collection of packages built from a single source > package), but I wanted to aggregate all packages published by a collection of > aptly repositories. Fortunately, it seems that this is possible by augmenting > the existing aptly job definition as shown in the following file: > > https://salsa.debian.org/moin-team/moin/-/blob/debian/master/debian/salsa-ci.yml [snip] Please, considering discussing about this on the Salsa CI mailing list: debian-salsa...@alioth-lists.debian.net (taking the liberty to CC:) > Ignoring the "ls" command which was there to troubleshoot this rather opaque > environment, one script adds repository definitions to the apt configuration, > whereas the other performs the appropriate "apt source" and "apt download" > commands, making the source and binary package files available for aptly to > process. Consequently, aptly will include all the dependency packages in the > final package repository. > > (Since the scripts reside in my package's debian directory, I also had to > request the availability of the Git repository for the job. Generally, I have > found it challenging to have these job definitions make effective use of > scripts due to environmental inconsistencies.) With my Salsa CI maintainer's hat, I am happy to receive MRs ;-) > > I imagine that publishing packages like this is not particularly desirable, > at > least if done widely, but I hope it shows that it can be done relatively > easily, at least if all the right incantations have been discovered. It depends. Right now, I am looking forward to ease testing reverse dependencies, which is somehow related. As far as Salsa CI also makes it possible to control the number of jobs, and to don't abuse the Salsa infrastructure, any enhancement is welcome. cheers, -- Santiago signature.asc Description: PGP signature
Request to join the Debian Python Modules Team
Hi there, I would like to request to be included in the Debian Python Modules Team. * Why you want to join the team: I would like to maintain altair (See #941599) within the team, as any other future python module that I would be interested in. * Your Salsa login: santiago * I state I have read https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst and I accept it. Cheers, -- Santiago signature.asc Description: PGP signature
