Re: Joining PAPT
> > fortran-language-server package is implemented in python, so it looks like > > it makes sense to have it under PAPT. > > done, welcome :) thanks, I have prepared the package at https://salsa.debian.org/python-team/applications/fortran-language-server please have a look and let me know if it meets the PAPT criteria Best, Denis
Re: Streamlining the use of Salsa CI on team packages
> I am not a fan of pointing to a moving target with the "include" statement: > > include: > - https://salsa.debian.org/salsa-ci-team/pipeline/raw/master/salsa-ci.yml > - > https://salsa.debian.org/salsa-ci-team/pipeline/raw/master/pipeline-jobs.yml > > "master" will change, and that can break CI jobs where nothing in the > local repo has changed. It does have pros and cons. The good: Additional build/verification steps or even automatic deployment can be added by the Salsa team at some point without requiring changes to each repository. The bad: As you mentioned, a moving target can be bad and cause inadvertent build failures and other issues that are out of the hands of maintainers. The ugly: Pulling in external scripts always bears a certain risk. They may go away at some point or cause potentially dangerous side effects. However, I do think that a standardised CI pipeline is very useful. Consider that the buildd infrastructure also uses a standardised build process that packages cannot simply get away from. If this process is replicated on Salsa, with an external script or not, people will quickly get a "glimpse" of what would happen on buildd. The need to manually adapt the CI script every time something changes in the buildd process is a heavy burden to bear and will easily lead to people "forgetting" to update their scripts. That kind of defeats the purpose. Also, consider that the Salsa CI pipeline is not an absolute source of truth, but a tool for developers and maintainers to quickly spot issues with their packages. If an autobuild fails, it's not the end of the world. It just means you have to go check what's going on.
Re: Streamlining the use of Salsa CI on team packages
I think we should definitely use Gitlab-CI! The 'salsa-ci-team/pipeline' project does have good coverage, with reprotest and piuparts. I'm the lead dev on another approach, also part of the salsa-ci-team, called 'ci-image-git-buildpackage': https://wiki.debian.org/Salsa/Doc#Running_Continuous_Integration_.28CI.29_tests It has lintian, autopkgtest and more, but lacks piuparts and reprotest. It does have "aptly" support where it will automatically build and deploy binary packages to a apt repo. Then other CI builds can add those repos for CI runs. This is very helpful for complex suites of packages that depend on each other. We use it in the Android Tools Team (click on any "pipeline" button to see it in action): https://salsa.debian.org/android-tools-team/admin 'salsa-ci-team/pipeline' is quite simple for packages with simple requirements. One limitation with it is that you can't include a bash script directly in the debian/.gitlab-ci.yml file, which is the normal way of working with GitLab-CI. That was a central requirement for ci-image-git-buildpackage. The automation is just bash commands, so you can use them in a bash script as needed. Or easily add multiple jobs, or do anything you would normally do in GitLab-CI. For example: https://salsa.debian.org/android-tools-team/android-platform-system-core/blob/master/debian/.gitlab-ci.yml I am not a fan of pointing to a moving target with the "include" statement: include: - https://salsa.debian.org/salsa-ci-team/pipeline/raw/master/salsa-ci.yml - https://salsa.debian.org/salsa-ci-team/pipeline/raw/master/pipeline-jobs.yml "master" will change, and that can break CI jobs where nothing in the local repo has changed. Louis-Philippe Véronneau: > Hello folks! > > I'd like to propose we start using Salsa CI for all the team packages. I > think using a good CI for all our packages will help us find packaging > bugs and fix errors before uploads :) > > I also think that when possible, we should be using the same CI jobs for > our packages. The Salsa CI Team's default pipeline [1] is a good common > ground, as currently it: > > * builds the package > * runs piuparts > * runs autopkgtest > * runs lintian > * runs reprotest > * and does more! > > I don't think a failing CI should be a blocker for an upload, but I > think it's a good red flag and should be taken in account. > > I know the Ruby team also decided to use debian/salsa-ci.yml instead of > debian/gitlab-ci.yml [2]. I guess we should also do the same. > > Thoughts? If we decide to go ahead with this, I guess we should modify > the policy accordingly and contact the Salsa Team to see if adding this > additional load is OK with them. > > [1] https://salsa.debian.org/salsa-ci-team/pipeline#basic-use > [2] https://salsa.debian.org/salsa-ci-team/pipeline/issues/86#note_106245 >
Re: [Help] Bug#938668: tifffile: Python2 removal in sid/bullseye
Hi Andrey, On Thu, Sep 05, 2019 at 11:06:22PM +0500, Andrey Rahmatullin wrote: > > Depends: python3-numpy (>= 1:1.16.0~rc1), python3-numpy-abi9, python3:any, > > python:any > > > > > > How can I get rid of the python:any dependency? > You ship a Python 2 script, /usr/bin/tifffile. It also doesn't work, for > obvious reasons. Fix its shebang. Argh. Thanks a lot for opening my eyes. > It would also be a good idea to test it > before the last upload, but as nobody noticed that the package doesn't > work since it was broken in December and got into buster, maybe it should > just be RMed? Good question. I admit I'm actually a bit pissed since the former maintainer introduced several packages into the team and than simply left the team. I tried my best to get the packages in a decent state but in this case failed obviously. I've just checked popcon of "vote" which is not really amazing. > I've just filed an RC bug for it. Fixed in new upload. > Also, my understanding is that public modules should be packaged > separately as python3-foo packages and private modules should be put into > private paths, but this package ships a public module and the changelog > entry says "The package does not really provide a Python module for > inclusion into other projects." See > https://www.debian.org/doc/packaging-manuals/python-policy/programs.html#current_version_progs Thanks for the hint. I admit I try to concentrate on other Python3 migration issues. In case some more problems come up with tifffile I'll reconsider RM. Kind regards Andreas. -- http://fam-tille.de
Re: Should python-cloudpickle get a py2keep tag?
On Thu, 2019-09-05 at 20:14 +0200, Matthias Klose wrote: > > you are asking about the least preferred option, without telling why > you can't > convert to python3, or why you can't remove the affected > packages. If you have > both spyder and spyder3 (Python3?), then why not drop spyder? I > didn't look at > skimage, but maybe look there first if it needs to be Python2. > I was assuming that py2keep was a temporary flag that would be removed after the leaf packages get fixed. Since spyder and skimage are under the science team I wasn't sure how long it would take for them to get around to removing the python2 packages. Both spyder and skimage packages have python3 versions. spyder does install into /usr/bin/spider so it's removal will have a bigger impact on end users than something that's just a python package. I did upload a new version of cloudpickle last night 1.2.1-1 with Python2 removed, I'm trying to figure out if I should let the dependencies just live with the previous python-cloudpickle 0.8.0 package or if I should upload a new version of 1.2.1 with the python2 packaging built. Diane
Should python-cloudpickle get a py2keep tag?
Hi, The py2removal bug says to discuss the py2keep tag first. src:cloudpickle is a dependency of src:spyder and src:skimage. python-skimage has a popcon inst score of 469 spyder has a popcon inst score of 1385 spyder3 has a popcon inst score of 1069 The removal bug says the popcon threshold for py2keep is >= 300. So add it? Diane signature.asc Description: This is a digitally signed message part
Re: [Help] Bug#938668: tifffile: Python2 removal in sid/bullseye
On Thu, Sep 05, 2019 at 07:42:15PM +0200, Andreas Tille wrote: > for some reason I do not understand are the dependencies of the > binary package > > Depends: python3-numpy (>= 1:1.16.0~rc1), python3-numpy-abi9, python3:any, > python:any > > > How can I get rid of the python:any dependency? You ship a Python 2 script, /usr/bin/tifffile. It also doesn't work, for obvious reasons. Fix its shebang. It would also be a good idea to test it before the last upload, but as nobody noticed that the package doesn't work since it was broken in December and got into buster, maybe it should just be RMed? I've just filed an RC bug for it. Also, my understanding is that public modules should be packaged separately as python3-foo packages and private modules should be put into private paths, but this package ships a public module and the changelog entry says "The package does not really provide a Python module for inclusion into other projects." See https://www.debian.org/doc/packaging-manuals/python-policy/programs.html#current_version_progs -- WBR, wRAR signature.asc Description: PGP signature
Re: [Help] Bug#938668: tifffile: Python2 removal in sid/bullseye
On Thu, 5 Sep 2019, Andreas Tille wrote: Control: tags -1 help Hi, for some reason I do not understand are the dependencies of the binary package Depends: python3-numpy (>= 1:1.16.0~rc1), python3-numpy-abi9, python3:any, python:any How can I get rid of the python:any dependency? Very good question. The only thing I can see is debian/tests/control has Depends: python, but I don't see how that should end up in the binary package's Depends. Scott
[Help] Bug#938668: tifffile: Python2 removal in sid/bullseye
Control: tags -1 help Hi, for some reason I do not understand are the dependencies of the binary package Depends: python3-numpy (>= 1:1.16.0~rc1), python3-numpy-abi9, python3:any, python:any How can I get rid of the python:any dependency? Kind regards Andreas. -- http://fam-tille.de
