* Package name : git-multimail Version : 1.5.0 Upstream Author : Matthieu Moy and others * URL : https://github.com/git-multimail/git-multimail * License : GPLv2 Programming Lang: Python Description : Send notification emails for pushes to a git repository git-multimail is a tool for sending notification emails on pushes to a Git repository. It includes a Python module called git_multimail.py, which can either be used as a hook script directly or can be imported as a Python module into another script. git-multimail is derived from the Git project's old contrib/hooks/post-receive-email, and is mostly compatible with that script. See README.migrate-from-post-receive-email for details about the differences and for how to migrate from post-receive-email to git-multimail. ---- It may be too late now that everyone moved to the cloud (which seems like it doesn't like to send email either), but it turns out I actually needed this right now and couldn't find a copy in Debian. I'm sure there are still deployments where this could be useful and I am not aware of an equivalent replacement already present in Debian (but do correct me if I'm wrong!) I am not sure I have the cycles to package it in the short term, but I'll see what i can do.
Hi all, I am a newbie for Debian develop and noticed the RFP [0]. So, hi Antoine, Have you started to work on this? If not, I think I can finish it with DPT's help:-). If yes, please let us know(As I said, I am a newbie and do not know what this is polite to ask the reporter directly. No offense). Thank you all, Bo [0]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1007025
Hi! I'm happy to see anyone pick up this work. I don't have the context for that thread, but I did (deliberately) file the bug as an RFP (Request For Package). If I would be working on it, I would have changed its status to ITP (Intent To Package). So while it's nice to hear from you, you don't actually need my approval to go ahead and package this. :) (I file a lot of RFPs, mostly to keep track of packages missing from Debian. But sometimes I do start working on them and I *do* make sure to change the bug status accordingly.) had to be told by a friend about your response (and I don't know how they found it!) because you didn't CC me... By default, the BTS doesn't include the original submitter when you only write to the bug report... a.
Oops, my bad. I forget to cc you indeed :-(. Thank you all. I have changed the RFP to ITP for the bug. I can't wait to start the adventure. :-) BR, Bo
[...] No problem. :) You should also assign yourself to the ticket, by making your email address the "owner".
What is the state of this? A Python Team DD should have contacted you about the RFS.
yeah. jcfp have help me to review it and points out some issues I should to fix. But I am stuck in the git-multimail testsuits fail in autopkgtest. The newest repo is here: https://salsa.debian.org/python-team/packages/git-multimail Its autotestpkg consists of two parts, one is import-private-module, and it is ok. But the other part is its upstream testsuits and there are one casesuit is failed. In fact, the problem is not packing, because I have the same fail on upstream build also. To my dismay, upstream doesn't look like it's going to maintain it either[0] given that, I will look at this test case some days and will ask for help if continue to fail. [0]: https://github.com/git-multimail/git-multimail/issues/211
Hi! I've done a quick review of the 1.6.0 package on salsa as of commit d5bd184a1cf73b752f80dea46d8080493a5e663b. It looks like there's some leftover stuff in debian/copyright, i would remove this: modified debian/copyright @@ -2,8 +2,6 @@ Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/ Upstream-Name: git-multimail Upstream-Contact: Matthieu Moy <matthieu.moy@univ-lyon1.fr> Source: https://github.com/git-multimail/git-multimail -# -# Please double check copyright with the licensecheck(1) command. Files: * Copyright: 2014-2022, Matthieu Moy <matthieu.moy@univ-lyon1.fr> 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...) It seems like you have README.rst both in debian/rules and debian/docs. Either one of those should be sufficient, and you should remove the other. Same with the launcher in python3-git-multimail.install vs debian/rules. 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? I would also name the binary package `git-multimail` instead of `python3-git-multimail`, since we don't really care that much that the thing is written in python, since it's not a library. 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!
[...] I have just found you have reported this upstream in: https://github.com/git-multimail/git-multimail/issues/221 ... which is great! Could you also open a PR against the repository and link that in the patch? You might want to review the patch tagging guidelines as well, as this is the kind of things it answers: https://dep-team.pages.debian.net/deps/dep3/ 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? a.
Hi, Ok, removed comment here. 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) There should be no duplicate file. I have droped they. 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:) Got it. I mixed python module and library here. (I paste and copy another mail in here:) Ok. I think so also. Fortunately, maintainer of upstream has a little response, but that's all. The new version for git-multimail is here: https://mentors.debian.net/package/git-multimail/ Thanks again for your encouragement.:)
[...] I don't think pull requests are noisy... you should probably just submit this as a PR upstream. [...] /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? [...] Okay, so the right way to do this is to file a release-critical bug against the package once it enters Debian. I hope that helps! :) a.
Hi, 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, right. 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/root 161143 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/root 14 2022-09-14 09:11 ./usr/lib/python3/dist-packages/git_multimail-1.6.0.egg-info/top_level.txt -rw-r--r-- root/root 161147 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 :)
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 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!