Transitionning to the lextudio pysnmp / pyasn1 ecosystem
Hi, As you may know, the upstream author for pysnmp passed away last year. As a result, the whole suite was forked by "lextudio". I packaged it, and the result is this list of source packages: python-pyasn1-lextudio python-pyasn1-modules-lextudio python-pysmi-lextudio python-pysnmp-lextudio Appart from the OpenStack packages, here's the list of reverse dependencies for the old python3-pysnmp4 binary package: * patator * pdudaemon * pysmi * snimpy * changeme * python3-snimpy * python3-pysnmp4-apps * python3-pysnmp4-mibs * snmpsim My plan is to file bugs against these packages, asking to transition to the newer packages. We're just below the threshold for asking debian-devel about mass bug-filling, so I figured out I would only send a mail to the Python list. Do you guys approve my plan? Should we make transition dummy packages? Also to Adam Cécile: can you make your pull request against the new Salsa repository? Cheers, Thomas Goirand (zigo)
[backintime] I'll package the next release
Hello together,
I hope different from the past this announcement will work this time.
Last time I announced the will to package something ("feedparser") but
someone else did it without communication.
Back In Time [1][2] will have a new upstream release [3] in the next
days. I [4] will try to prepare the packaging for Debian this time. The
next Debian release is minimum 2 years away so I have enough time. ;)
Kind
Christian Buhtz
[1] --
[2] --
[3] --
[4] --
[backintime] I'll package the next release
Hello together,
I hope different from the past this announcement will work this time.
Last time I announced the will to package something ("feedparser") but
someone else did it without communication.
Back In Time [1][2] will have a new upstream release [3] in the next
days. I [4] will try to prepare the packaging for Debian this time. The
next Debian release is minimum 2 years away so I have enough time. ;)
Kind
Christian Buhtz
[1] --
[2] --
[3] --
[4] --
Request to join python team
I would like to join the team to help maintain the packages Robber [1], Delta [2] and Pytest-executable [3]. My salsa login is: Thais-ra I have read the python team policy [4] and accept it. [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1051387 [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1051346 [3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1032951 [4] https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst
Re: [backintime] I'll package the next release
Hello Christian,
Am 15.09.23 um 13:18 schrieb bu...@posteo.de:
Hello together,
I hope different from the past this announcement will work this time.
Last time I announced the will to package something ("feedparser") but
someone else did it without communication.
Back In Time [1][2] will have a new upstream release [3] in the next
days. I [4] will try to prepare the packaging for Debian this time. The
next Debian release is minimum 2 years away so I have enough time. ;)
the DPT isn't the maintainer of this package, you are aware of this?
Means, I see primarily no work nor action on the side of the DPT that's
needed to take as the package has a person as Maintainer set.
Do you have talked to the Maintainer and/or Uploader if they are
interested in help with any packaging work done by you?
Not that you not can do this for yourself, but please be not
disappointed if the Debian Maintainers refuse your packaging work to merge.
--
Regards
Carsten
Re: [backintime] I'll package the next release
Dear Carsten, thanks for your reply. Am 15.09.2023 11:19 schrieb Carsten Schoenert: the DPT isn't the maintainer of this package, you are aware of this? DPT = Debian Python Team ? Yes I'm aware of this. But to my knowledge the list is not restricted to DPT package topics. Do you have talked to the Maintainer and/or Uploader if they are interested in help with any packaging work done by you? The communication is not the most fluent. I'm not sure which kind of help he would accept. I'll see. Not that you not can do this for yourself I do. if the Debian Maintainers refuse your packaging work to merge. I expect that. :D Kind Christian
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
Re: Transitionning to the lextudio pysnmp / pyasn1 ecosystem
On Friday, September 15, 2023 3:38:05 AM EDT Thomas Goirand wrote: > Hi, > > As you may know, the upstream author for pysnmp passed away last year. > As a result, the whole suite was forked by "lextudio". I packaged it, > and the result is this list of source packages: > > python-pyasn1-lextudio > python-pyasn1-modules-lextudio > python-pysmi-lextudio > python-pysnmp-lextudio > > Appart from the OpenStack packages, here's the list of reverse > dependencies for the old python3-pysnmp4 binary package: > > * patator > * pdudaemon > * pysmi > * snimpy > * changeme > * python3-snimpy > * python3-pysnmp4-apps > * python3-pysnmp4-mibs > * snmpsim > > My plan is to file bugs against these packages, asking to transition to > the newer packages. We're just below the threshold for asking > debian-devel about mass bug-filling, so I figured out I would only send > a mail to the Python list. Do you guys approve my plan? Should we make > transition dummy packages? > > Also to Adam Cécile: can you make your pull request against the new > Salsa repository? Why did you hijack this from the Python team instead of just working with the existing maintainers to update the existing packages from the new upstream location? Scott K signature.asc Description: This is a digitally signed message part.
Re: [Debian-salsa-ci] Publishing multiple packages with aptly in Salsa CI
Hi, Someone wrote: >> 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 For another angle, see: https://salsa.debian.org/philh/user-setup/-/pipelines/576662 In which I have a `harvest-repos` job that grabs artifacts from `build` jobs in other pipelines, and an `aptly-plus` job that's got an added `needs: harvest-repos` that can combine the artifacts from its build and harvest-repos jobs and lump them all together. In the resulting aptly repo you can see that it includes both the local package (user-setup) under the 'u' directory, and 'grub-installer' under the 'g' directory: https://salsa.debian.org/philh/user-setup/-/jobs/4671054/artifacts/browse/aptly/pool/main/ That's done with: https://salsa.debian.org/installer-team/branch2repo/ Quite a lot of that is already part of the standard salsa-CI pipeline, and my aim is that branch2repo will pretty-much disapear, with its components being optional bits of the standard pipeline, and maybe a few variable settings. Cheers, Phil. -- Philip Hands -- https://hands.com/~phil signature.asc Description: PGP signature
Re: [Debian-salsa-ci] Publishing multiple packages with aptly in Salsa CI
On Friday, 15 September 2023 16:33:25 CEST Philip Hands wrote: > > For another angle, see: > > https://salsa.debian.org/philh/user-setup/-/pipelines/576662 > > In which I have a `harvest-repos` job that grabs artifacts from `build` > jobs in other pipelines, and an `aptly-plus` job that's got an added > `needs: harvest-repos` that can combine the artifacts from its build and > harvest-repos jobs and lump them all together. > > In the resulting aptly repo you can see that it includes both the > local package (user-setup) under the 'u' directory, and 'grub-installer' > under the 'g' directory: > > https://salsa.debian.org/philh/user-setup/-/jobs/4671054/artifacts/browse/ aptly/pool/main/ Yes, that was the desired effect: have packages corresponding to several source packages being made available in the pool and thus the created package repository. > That's done with: > > https://salsa.debian.org/installer-team/branch2repo/ > > Quite a lot of that is already part of the standard salsa-CI pipeline, > and my aim is that branch2repo will pretty-much disapear, with its > components being optional bits of the standard pipeline, and maybe a few > variable settings. Indeed. As noted before, my modifications were effectively (1) to keep the source repository around to get access to my scripts, (2) to be able to add package repositories to the apt configuration, (3) to download packages so that aptly can process them. (1) is just preferable to writing scripts in the horrible YAML syntax and then doing fragment inclusion, which I found can lead to opaque error messages. Being able to obtain a set of scripts would be quite helpful generally as the environment can vary substantially from one kind of job to another. (2) is something that could be part of the standard job definitions, particularly since other jobs like autopkgtest need to know about additional repositories in certain cases, brand new packages being one of them. (3) is just a small enhancement for this specific scenario. I thought that someone must have done this before, even if the standard pipeline didn't support it. I imagine that some coordination would be desirable to prevent fragmentation and people like me introducing our own ways of addressing this particular need. Paul
Re: [backintime] I'll package the next release
Hey, On Fri, Sep 15, 2023 at 07:48:30AM +, bu...@posteo.de wrote: > Back In Time [1][2] will have a new upstream release [3] in the next days. I > [4] will try to prepare the packaging for Debian this time. The next Debian > release is minimum 2 years away so I have enough time. ;) Thanks for the heads up; I thought you were going to say it had happened and I'd missed it :) Help appreciated as always, although as an existing package you won't find it as exciting as doing something new. I may also get chance while travelling next week. Thanks, -- Jonathan Wiltshire j...@debian.org Debian Developer http://people.debian.org/~jmw 4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC 74C3 5394 479D D352 4C51 ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1
