Re: Bug#1007025: git-multimail 1.6.0 package review
Hi, On Tue, Sep 20, 2022 at 10:56:05AM -0400, Antoine Beaupré wrote: 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. Ok, got it. Will do. Sometime I mentioned the patch in the issue, the maintainer of upstream will pick it into if he think that is valuable. [...] 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. yeah, right. 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? The issue is that, it really seems like a bug here. First, I install git-multimail manual: ``` sudo python setup.py install # log is below ... creating /usr/local/lib/python3.10/dist-packages/git_multimail-1.5.0-py3.10.egg Extracting git_multimail-1.5.0-py3.10.egg to /usr/local/lib/python3.10/dist-packages Adding git-multimail 1.5.0 to easy-install.pth file Installing git_multimail.py script to /usr/local/bin ... vimer@dev:~/build/rfs/git-multimail$ which git_multimail.py /usr/local/bin/git_multimail.py ``` It looks like you said. The git_multimail.py is placed in /usr/local/bin/git_multimail.py (if from debian package, it will be placed into /usr/bin/) The content of git-multimail.deb is: ``` This package provides the Python 3 modules and the git-multimail script. drwxr-xr-x root/root 0 2022-09-14 09:11 ./ drwxr-xr-x root/root 0 2022-09-14 09:11 ./usr/ drwxr-xr-x root/root 0 2022-09-14 09:11 ./usr/bin/ -rwxr-xr-x root/root161143 2022-09-14 09:11 ./usr/bin/git_multimail.py drwxr-xr-x root/root 0 2022-09-14 09:11 ./usr/lib/ drwxr-xr-x root/root 0 2022-09-14 09:11 ./usr/lib/python3/ drwxr-xr-x root/root 0 2022-09-14 09:11 ./usr/lib/python3/dist-packages/ drwxr-xr-x root/root 0 2022-09-14 09:11 ./usr/lib/python3/dist-packages/git_multimail-1.6.0.egg-info/ -rw-r--r-- root/root 35851 2022-09-14 09:11 ./usr/lib/python3/dist-packages/git_multimail-1.6.0.egg-info/PKG-INFO -rw-r--r-- root/root 1 2022-09-14 09:11 ./usr/lib/python3/dist-packages/git_multimail-1.6.0.egg-info/dependency_links.txt -rw-r--r-- root/root14 2022-09-14 09:11 ./usr/lib/python3/dist-packages/git_multimail-1.6.0.egg-info/top_level.txt -rw-r--r-- root/root161147 2022-07-21 07:30 ./usr/lib/python3/dist-packages/git_multimail.py drwxr-xr-x root/root 0 2022-09-14 09:11 ./usr/share/ drwxr-xr-x root/root 0 2022-09-14 09:11 ./usr/share/doc/ drwxr-xr-x root/root 0 2022-09-14 09:11 ./usr/share/doc/git-multimail/ -rw-r--r-- root/root 11317 2022-07-21 07:30 ./usr/share/doc/git-multimail/README.rst.gz -rw-r--r-- root/root 210 2022-09-14 09:11 ./usr/share/doc/git-multimail/changelog.Debian.gz -rw-r--r-- root/root 1755 2022-09-14 09:11 ./usr/share/doc/git-multimail/copyright ``` I think the people found the issue also: https://github.com/git-multimail/git-multimail/issues/221#issuecomment-1252529169 Certainly, lintian will give a kindly warning: W: git-multimail: script-with-language-extension [usr/bin/git_multimail.py] If I understand correctly, this is a bug as you said. The workround is still to use launcher file in d/ as in previous commit? Many thanks for your time to help me review it again :) -- Regards, -- Bo YU signature.asc Description: PGP signature
Re: Bug#1007025: git-multimail 1.6.0 package review
On 2022-09-22 17:03:24, Bo YU wrote: > Hi, > On Tue, Sep 20, 2022 at 10:56:05AM -0400, Antoine Beaupré wrote: >>> 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. > > Ok, got it. Will do. > Sometime I mentioned the patch in the issue, the maintainer of upstream will > pick it into if he think that is valuable. Yeah, that's a reasonable assumption, but I find that maintainers often process merge requests way more quickly and easily as they just need one click to merge. :) [...] > I think the people found the issue also: > https://github.com/git-multimail/git-multimail/issues/221#issuecomment-1252529169 > > Certainly, lintian will give a kindly warning: > W: git-multimail: script-with-language-extension [usr/bin/git_multimail.py] > > If I understand correctly, this is a bug as you said. > The workround is still to use launcher file in d/ as in previous commit? I think the simplest solution is not to rewrite the launcher, but to rename it. So in debian/rules, you would simply do: override_dh_auto_install: dh_auto_install mv debian/git-multimail/usr/bin/git_multimail.py debian/git-multimail/usr/bin/git-multimail Also, get rid of the noop sections like: override_dh_installdocs: dh_installdocs Cheers! -- I prefer the tumult of liberty to the quiet of servitude. - Thomas Jefferson
Re: Bug#1007025: git-multimail 1.6.0 package review
On Thu, 22 Sep 2022 12:35:12 -0400 Antoine Beaupré wrote: > I think the simplest solution is not to rewrite the launcher, but to > rename it. So in debian/rules, you would simply do: > > override_dh_auto_install: > dh_auto_install > mv debian/git-multimail/usr/bin/git_multimail.py > debian/git-multimail/usr/bin/git-multimail Antoine, IIRC the git_multimail.py file upstream installs into /usr/bin is not a launcher but a full copy of the module as installed into /usr/lib/python3. The code in that file auto-detects whether it's run as a program. That resulted in two copies of that sizeable file in the package I reviewed back in June. Hence my suggestion - quoted in an earlier message by Bo - to replace the copy in /usr/bin with a tiny launcher, reducing the installed size of the package by almost half. pgpndg25pGdX0.pgp Description: OpenPGP digital signature
Re: Bug#1007025: git-multimail 1.6.0 package review
On 2022-09-22 19:43:24, Jeroen Ploemen wrote: > On Thu, 22 Sep 2022 12:35:12 -0400 > Antoine Beaupré wrote: > >> I think the simplest solution is not to rewrite the launcher, but to >> rename it. So in debian/rules, you would simply do: >> >> override_dh_auto_install: >> dh_auto_install >> mv debian/git-multimail/usr/bin/git_multimail.py >> debian/git-multimail/usr/bin/git-multimail > > Antoine, IIRC the git_multimail.py file upstream installs into > /usr/bin is not a launcher but a full copy of the module as installed > into /usr/lib/python3. The code in that file auto-detects whether > it's run as a program. Oh. I misunderstood that, sorry. > That resulted in two copies of that sizeable file in the package I > reviewed back in June. Hence my suggestion - quoted in an earlier > message by Bo - to replace the copy in /usr/bin with a tiny launcher, > reducing the installed size of the package by almost half. Sure, that completely makes sense then, sorry. a. -- À force de ne jamais réfléchir, on a un bonheur stupide - Jean Cocteau
Re: Enabling salsa-ci on all Debian Python Team repos
Emanuele Rocca writes: > What's wrong with pushing your work before uploading to ftp-master > instead? :-) I am learning to do this with my packages. Because otherwise, when I push to get, I often find I forgot to do a pull beforehand, and there are changes in salsa that are not reflected in my upload I just did, and as I result I have a bit of a mess to try and resolve. But still, I need to remember to do it in this order. Normal solution would be to get the CI to upload the new changes automatically, but I imagine there are going to be problems here regarding control of the GPG key required to sign that changes file. -- Brian May https://linuxpenguins.xyz/brian/
Re: Enabling salsa-ci on all Debian Python Team repos
> Well but that's the whole point of automated testing. There's no *need* > to do it locally if it's already done by Salsa for you. What is already > automated and working pretty well is: > > - amd64 build > - i386 build > - source build > - autopkgtest > - blhc > - lintian > - piuparts > - reprotest > - arm64 crossbuild > > That's a pretty time consuming list of things to go through for a human! > > The only work left to be done on your machine is a binary build to see > if the packages look good, perhaps some specific manual testing [1], > source build and upload. Isn't that better? sure its better, now let's assume something in those tests fails: how do you debug it and fix it? you still need to repeat it locally = you wasted time. In conclusion, you're no only proposing a technical change (add CI to all our packages), but also a workflow change (push to salsa before an upload). experience dictates that's never a good idea, and in such an heterogeneous team like ours, it's simply not gonna give the fruits you think it will. I still think it's a waste of time, and addition of emails that we're going to simply ignore (or not receive at all, if you're not subscribed to tracker.d.o, wihch is suspect is the vast majority of team members), but if the majority of the core contributors want it, sure go ahead -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
RFS: domdf-python-tools/3.4.0-1 [ITP] -- Helpful functions for Python
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "domdf-python-tools": * Package name : domdf-python-tools Version : 3.4.0-1 Upstream contact : Dominic Davis-Foster * URL : https://github.com/domdfcoding/domdf_python_tools * License : CC-BY-SA, PSFL-2, Expat * Vcs : https://salsa.debian.org/python-team/packages/domdf-python-tools Section : python The source builds the following binary packages: python3-domdf-python-tools - Helpful functions for Python To access further information about this package, please visit the following URL: https://mentors.debian.net/package/domdf-python-tools/ https://salsa.debian.org/nilsonfsilva/domdf-python-tools Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/d/domdf-python-tools/domdf-python-tools_3.4.0-1.dsc Changes for the initial release: domdf-python-tools (3.4.0-1) experimental; urgency=medium . * Initial release. (Closes: #1020324) Note: The documentation binary, I was not made because it depends on a dependency: https://github.com/sphinx-toolbox/sphinx-pyproject, which is not yet on debian Regards, -- Josenilson Ferreira da SIlva Nilson F. Silva 81-3036-0200 81-991616348 81-98546-9553
Re: Enabling salsa-ci on all Debian Python Team repos
Hello Emanuele, Am 21.09.22 um 12:01 schrieb Emanuele Rocca: Well but that's the whole point of automated testing. There's no *need* to do it locally if it's already done by Salsa for you. What is already automated and working pretty well is: - amd64 build - i386 build - source build - autopkgtest - blhc - lintian - piuparts - reprotest - arm64 crossbuild That's a pretty time consuming list of things to go through for a human! sure, that's a killer argument that I can't really argue against. But that is not the point for me. For all these checks we already have existing infrastructure, running the same also by a pipeline job isn't helping at all if it's not clear how to handle the fallout (we already mostly have seen in other places too!). As Sandro and Arnaud have pointed out it's probably mostly a matter of the workflow for a package upload. And for me the CI pipeline stuff right now doesn't fit really into the package upload workflow that is typically used. Using the CI stuff in your own namespace is perfectly fine and I'm using this option from time to time. But I use there also the possibility to do heavily force pushing to not blow up the git tree with dozens of Fixup commits! In the 'official' git tree this is a no go of course. Nobody is perfect and even every Python package will have it's own small differences in between. As long as we don't have *one* Debian way to build packages and a helpful way to deal with breakage in any of the test runs it will always be a waste of time an energy to run for all packages a CI run at all times! If the decision is to do this step I will simply need to ignore any errors that are not RC. The only work left to be done on your machine is a binary build to see if the packages look good, perhaps some specific manual testing [1], source build and upload. Isn't that better? I do all package built locally as a all/any build run. As written above and trying to say, I like atomic git commits that are doing things "correct" and by looking at the commit it's clear why this commit was done. I have to "fight" enough on my day job with my colleagues as they do git mostly using committing every forward and backward steps with no clean up locally finally before pushing their stuff and so I need to spend a lot of time to get the changes and their basically meaning. You would end up the same in the packages here as people would commit again and again to fix up the packages. I stand on my thinking, it's not helpful to enable a global CI for all packages. Doing this from case to case is absolutely fine to me. Arnaud Ferraris has written about the usage of a CI option in Debian Mobile etc. His writing is affirming me as I see and have the same experience within the PureOS ecosystem. People work there the same as I did describe, package are prepared in the local namespace and if the CI is running there successfully then a push to the team namespace is done. -- Regards Carsten
Re: Enabling salsa-ci on all Debian Python Team repos
Hi Carsten (2022.09.23_05:01:05_+) > sure, that's a killer argument that I can't really argue against. But that > is not the point for me. > > For all these checks we already have existing infrastructure, running the > same also by a pipeline job isn't helping at all if it's not clear how to > handle the fallout (we already mostly have seen in other places too!). Yeah, it's similar for me. I test build locally, my sbuild setup does most (but not all) of the same checks as gitlab CI. Then when I'm happy I push and upload. If there is any gitlab CI, it runs too late. And if it fails, I usually don't even bother to investigate, because I trust my local setup implicitly. Anything that's failing in gitlab CI is almost certain to be a failure specific to gitlab CI. I do see a value in having it enabled globally, for the team, though. 1. It can make the team packages friendlier to new contributor team members who don't have a setup like that. I would like to see our team act more like a team and have people contribute to packages that they don't regularly maintain. 2. Getting a test failure on a merge-request catches contributor mistakes early. I love having CI on incoming patches like that. SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Re: Enabling salsa-ci on all Debian Python Team repos
Hi Carsten, Hi List, Le Fri, Sep 23, 2022 at 07:01:05AM +0200, Carsten Schoenert a écrit : > heavily force pushing to not blow up the git tree with dozens of Fixup > commits! In the 'official' git tree this is a no go of course. Would doing the work in a git branch and 'git merge --squash' at the end be a solution to this problem ? I have the same issue when trying to use CI to run tests instead of running them locally, but using Mercurial, I just 'hg amend' them and I end up with a clean history. With Mercurial and its concept of obsolete commit combined with the evolve extension, a team can amend commits and share these amended commits without anyone losing work. I never found the equivalent in git where rewriting an history to clean it once the dust as settled breaks every repository that already pulled these commits. In other words, Mercurial allows you to work in a decentralized fashion both on your source and on the history of your source. -- Nicolas Chauvat logilab.fr - services en informatique scientifique et gestion de connaissances
