Re: Enabling salsa-ci on all Debian Python Team repos
> Am 20.09.22 um 16:13 schrieb Emanuele Rocca: > > Salsa CI is useful because it automatically performs binary/source builds, > > arm64 crossbuilds, and it runs various pretty important tests such as > > lintian, > > piuparts, reproducible build testing, and more. It also runs autopkgtest in > > LXC. > > quite most of these steps I usually need to do locally before I do any > upload of packages. So I see no real gain to run any pipeline by > default, for me this would be just burning energy in CPU cycles just for > "because we can". exactly this. the vast majority of the team members (based on the commits email i receive) are uploading the package to the archive at the same time as they are pushing a full set of changes to salsa (and sometimes only *after* the package has been ACCEPTED); in this case CI runs too late, and it has 0 benefit for that specific upload. For future ones? maybe, but that's to be proven, and the burden of proof is on the proponent. Someone with upload rights still need to verify (and build!) a package locally, so what would be the advantage of this CI for our packages, given only a very very tiny number of MRs are submitted i could see the benefit for projects that receive external contributions and/or are released out-of-sync with such contributions (say dh-python) but for /packages/, as Carsten said, it's a waste of CPU time to enable CI, IMO -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
Re: Enabling salsa-ci on all Debian Python Team repos
Hi, Am 20.09.22 um 16:13 schrieb Emanuele Rocca: Salsa CI is useful because it automatically performs binary/source builds, arm64 crossbuilds, and it runs various pretty important tests such as lintian, piuparts, reproducible build testing, and more. It also runs autopkgtest in LXC. quite most of these steps I usually need to do locally before I do any upload of packages. So I see no real gain to run any pipeline by default, for me this would be just burning energy in CPU cycles just for "because we can". CI/CD makes sense for me within a greater view such as is a version upgrade of package A not break other stuff in other packages, like does working all packages that now need to use a new version of pytest or setuptools, django etc. But that's not ready within the current way the default CI pipeline is working (in my POV). So no, for me it makes currently no sense to enable a CI thingy for ALL packages by default! We have automatic Lintian checks, the buildds itself, and also the autopkgtest infrastructure, why double such things, that's waste of energy and resources! The packages are not getting better by running tests multiple times within the same environment. And given my experience within other teams and groups, nobody really cares about packages that fail in some tests within a CI run. I strongly believe it wouldn't be better here. Sure you can do all this manually on your own, but it's better to live in a world where the machines work for us rather than the other way around. :-) I still don't see why this is a benefit. If you use an CI option within your own namespace is another thing, doing so make sense to me to prepare a new version for uploading. -- Regards Carsten
Re: git-multimail 1.6.0 package review
On 2022-09-18 11:10:24, Bo YU wrote: > Hi, > On Thu, Sep 15, 2022 at 05:32:33PM +0100, Antoine Beaupré wrote: >>Hi! >> >>I've done a quick review of the 1.6.0 package on salsa as of commit >>d5bd184a1cf73b752f80dea46d8080493a5e663b. [...] >>Also, I didn't quite follow the work on the test cases, but why did you >>replace pep8 by pycodestyle in the patch in debian/patches? The patch >>itself doesn't actually explain the *why* (it explains the "what" but we >>typically want more than this...) > > This time i add dep3 header for the patch. It should be noted that > despite this patch, it is still not helpful for upstream test cases. > I have forwarded this for upstream: > https://github.com/git-multimail/git-multimail/issues/221#issuecomment-1245009306 > (To avoid bring noisy for upstream, i just recorded it in a issue) I don't think pull requests are noisy... you should probably just submit this as a PR upstream. [...] >>I'm also surprised we need that launcher at all. Normally, the >>`setup.py` wrapper has a scripts= stanza which should install the >>upstream one, why do we do it differently? > > yeah. The reason why I use launcher here is bacause that @jcfp helped > me to review it in the previous time: > > ``` > the (large) git_multimail.py file is installed twice, both as a > public module under /usr/lib/python3 and as a script in /usr/bin; > the latter could be replaced by a tiny launcher (take a look at the > nfoview package if you need inspiration; your launcher would be even > shorter because it doesn't need the sys.path manipulation) > ``` > I am not sure if I understand jcfp's meaning correctly and I refer to > nfoview: > https://salsa.debian.org/python-team/packages/nfoview/-/blob/debian/master/debian/launcher/nfoview > > The issue is that I installed git_multimail.py twice in fact it should > be under /usr/lib/python3 only as jcfp said. So i remove it in /usr/bin > by hand. > > Now I have removed the launcher for git-multimail and it should work:) Hm. This is weird. Why would you *not* want git-multimail under /usr/bin? I understand the that git_multimail.py *module* should be in /usr/lib/, but you should *also* have a launcher in /usr/bin/ I think, therefore, this is incorrect: +override_dh_python3: + dh_python3 + rm -f debian/git-multimail/usr/bin/git_multimail.py + First off, don't use `-f` there: we *do* want to fail if the file doesn't exist, so that we can remove the override. Second, this looks wrong: `git-multimail` (the launcher) should be the thing that's installed under /usr/bin, not `git_multimail.py` (the module). If the module ends up in /usr/bin, then it's probably a bug upstream that should be filed. Could you clarify what happens with the package right now? [...] >>Finally, one fundamental issue with this package is that, as you >>correctly identified, it's unmaintained upstream. If we do ship it in >>Debian, maybe we'd want to keep it out of stable until that is settled? > > Ok. I think so also. Fortunately, maintainer of upstream has a little > response, but that's all. Okay, so the right way to do this is to file a release-critical bug against the package once it enters Debian. >>I think that's what I have for now. I haven't double-checked the >>upstream branch to see if it matches the upstream repo I have here, but >>that would be my next step before uploading... just a formality to make >>sure everything matches up. >> >>Thanks for working on this package! > > Thanks. This is the first package made by me with you all help. > > The new version for git-multimail is here: > https://mentors.debian.net/package/git-multimail/ > > Thanks again for your encouragement.:) I hope that helps! :) a. -- Omnis enim ex infirmitate feritas est. All cruelty springs from weakness. - Lucius Annaeus Seneca (58 AD)
Re: Enabling salsa-ci on all Debian Python Team repos
Hi Sandro, On Tue, Sep 20, 2022 at 08:31:14AM -0400, Sandro Tosi wrote: > the way i worded my initial question was so that you could list the > reasons that make it so useful, in detail: so would you like to do? Salsa CI is useful because it automatically performs binary/source builds, arm64 crossbuilds, and it runs various pretty important tests such as lintian, piuparts, reproducible build testing, and more. It also runs autopkgtest in LXC. Sure you can do all this manually on your own, but it's better to live in a world where the machines work for us rather than the other way around. :-)
Re: Enabling salsa-ci on all Debian Python Team repos
On Tue, Sep 20, 2022 at 4:33 AM Emanuele Rocca wrote: > On 19/09 02:14, Sandro Tosi wrote: > > what would the team get out of doing this? > > The way I see it, CI on Salsa is so useful that it should be enabled by > default unless there are good reasons not to. the way i worded my initial question was so that you could list the reasons that make it so useful, in detail: so would you like to do? -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
Request to join the team
Dear all I'm working with Claudius Heine (cmhe) and would like to join the DPT to help maintain packages; currently I'm interested in packages related to the TPM (tpm2-pytss) and cryptography (python-cryptography) but I may get involved with other topics in the future. My Salsa account is mlegner. I've read and I accept the Debian Python Team Policy [1]. Cheers Markus [1] https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst
Re: Enabling salsa-ci on all Debian Python Team repos
Hi Sandro, On 19/09 02:14, Sandro Tosi wrote: > what would the team get out of doing this? The way I see it, CI on Salsa is so useful that it should be enabled by default unless there are good reasons not to. ciao, Emanuele
