Re: please be more careful about your team uploads
On 2024-05-08 10:18:27, Antoine Beaupré wrote: > On 2024-05-08 16:08:07, Alexandre Detiste wrote: >> Hi, >> >> That was the very first day I got to work on DPT packages; >> so well yes, I did some mistakes at first; >> and having been DM for far too long (~10 years) I needed to retrain; >> I had so many things stuck in my queue at first. >> >> https://lists.debian.org/debian-python/2023/12/msg00012.html >> >> >> I'm now going through the ITP's >> needed for stalled package updates. > > Great to have you onboard, just don't forget to push next time. :) Actually, now that I look at the git history, you *did* push changes to that repository, they're just different from what was uploaded. I can't make heads or tails out of this. Could you make sure the python-invoke git repository is in sync with the archive now please? A.
Re: please be more careful about your team uploads
On 2024-05-08 10:18:27, Antoine Beaupré wrote: > On 2024-05-08 16:08:07, Alexandre Detiste wrote: >> Hi, >> >> That was the very first day I got to work on DPT packages; >> so well yes, I did some mistakes at first; >> and having been DM for far too long (~10 years) I needed to retrain; >> I had so many things stuck in my queue at first. >> >> https://lists.debian.org/debian-python/2023/12/msg00012.html >> >> >> I'm now going through the ITP's >> needed for stalled package updates. > > Great to have you onboard, just don't forget to push next time. :) Actually, now that I look at the git history, you *did* push changes to that repository, they're just different from what was uploaded. I can't make heads or tails out of this. Could you make sure the python-invoke git repository is in sync with the archive now please? A.
Re: please be more careful about your team uploads
On 2024-05-08 16:08:07, Alexandre Detiste wrote: > Hi, > > That was the very first day I got to work on DPT packages; > so well yes, I did some mistakes at first; > and having been DM for far too long (~10 years) I needed to retrain; > I had so many things stuck in my queue at first. > > https://lists.debian.org/debian-python/2023/12/msg00012.html > > > I'm now going through the ITP's > needed for stalled package updates. Great to have you onboard, just don't forget to push next time. :) For what it's worth, my trick for this is i register my local git repos in myrepos and run "mr status" from time to time, which tells me when i forget to push. I do try to be particularly more careful when i work on team packages, especially if i'm not an uploader... A. -- Only after disaster can we be resurrected. It's only after you've lost everything that you're free to doanything. Nothing is static, everything is evolving, everything is falling apart. - Chuck Palahniuk, Fight Club
Re: please be more careful about your team uploads
On 2024-05-08 16:11:46, Alexandre Detiste wrote: > Ok I guess you want to do this one: > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1008768 Not really! It's a RFP, if I was going to do it, I would have renamed that package to "ITP" and reassigned it... a. -- I would defend the liberty of consenting adult creationists to practice whatever intellectual perversions they like in the privacy of their own homes; but it is also necessary to protect the young and innocent. - Arthur C. Clarke
Re: please be more careful about your team uploads
On 2024-05-08 16:08:07, Alexandre Detiste wrote: > Hi, > > That was the very first day I got to work on DPT packages; > so well yes, I did some mistakes at first; > and having been DM for far too long (~10 years) I needed to retrain; > I had so many things stuck in my queue at first. > > https://lists.debian.org/debian-python/2023/12/msg00012.html > > > I'm now going through the ITP's > needed for stalled package updates. Great to have you onboard, just don't forget to push next time. :) For what it's worth, my trick for this is i register my local git repos in myrepos and run "mr status" from time to time, which tells me when i forget to push. I do try to be particularly more careful when i work on team packages, especially if i'm not an uploader... A. -- Only after disaster can we be resurrected. It's only after you've lost everything that you're free to doanything. Nothing is static, everything is evolving, everything is falling apart. - Chuck Palahniuk, Fight Club
Re: please be more careful about your team uploads
On 2024-05-08 16:11:46, Alexandre Detiste wrote: > Ok I guess you want to do this one: > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1008768 Not really! It's a RFP, if I was going to do it, I would have renamed that package to "ITP" and reassigned it... a. -- I would defend the liberty of consenting adult creationists to practice whatever intellectual perversions they like in the privacy of their own homes; but it is also necessary to protect the young and innocent. - Arthur C. Clarke
please be more careful about your team uploads
Hi, I'm working on updating the python-invoke package and see you've done two uploads on the package: https://tracker.debian.org/news/1491303/accepted-python-invoke-200-11-source-into-unstable/ https://tracker.debian.org/news/1491393/accepted-python-invoke-200-12-source-into-unstable/ So, first off: thanks for fixing those issues! :) But, second, could you be a little more careful about how you do those? Normally, I would have expected those changes to be pushed to salsa so that I can build on top of. Or, at the very least, you should have sent a debdiff... The uploads are a little bizarre too, because they have a NMU-like versionn number (e.g. 2.0.0-1.1) yet they say "Team upload" on the changelog. Clearly that should have yielded lintian warnings, did you ignore those? In any case, i'm now in the rather unfortunate position of having to retrofit that stuff back in the package, and it's making my life a little harder than it should... So please be a little more careful next time around, thanks! a. -- I know where I am going, and I know the truth, and I do not have to be what you want me to be. I am free to be what I want. - Muhammad Ali
Re: ITP: web-cache -- Simple Python key-value storage backed up by sqlite3 database
Control: retitle -1 ITP: web-cache -- Simple Python key-value storage backed up by sqlite3 database On 2024-04-30 12:26:05, Antoine Beaupre wrote: > * Package name: python3-web-cache Actually, py2dsp makes a package named `web-cache` for this, which seems a tad too generic. Thoughts? -- Only after disaster can we be resurrected. It's only after you've lost everything that you're free to doanything. Nothing is static, everything is evolving, everything is falling apart. - Chuck Palahniuk, Fight Club
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: 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: 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: git-multimail 1.6.0 package review
On 2022-09-15 17:32:33, 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...) 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. -- I've got to design so you can put it together out of garbage cans. In part because that's what I started from, but mostly because I don’t trust the industrial structure—they might decide to suppress us weirdos and try to deny us the parts we need. - Lee Felsenstein
git-multimail 1.6.0 package review
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 Source: https://github.com/git-multimail/git-multimail -# -# Please double check copyright with the licensecheck(1) command. Files: * Copyright: 2014-2022, Matthieu Moy 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! -- The greatest crimes in the world are not committed by people breaking the rules but by people following the rules. It's people who follow orders that drop bombs and massacre villages. - Banksy signature.asc Description: PGP signature
Re: a review of your bumblebee-status package
On 2022-06-07 18:46:37, Ben Westover wrote: > Hello, > > I've read more into versioneer, and it turns out with the way it works > you can't simply remove versioneer.py from the source, much less > _version.py. Therefore, I'm excluding _version.py in d/copyright, then > replacing it with the much smaller PyPI version in d/patches, and not > touching versioneer.py at all, since with the way versioneer works it's > technically not vendoring. Got it, thanks for bearing with me here. -- The destiny of Earthseed is to take root among the stars. - Octavia Butler
Re: a review of your bumblebee-status package
On 2022-06-07 15:44:28, Julian Gilbey wrote: > On Tue, Jun 07, 2022 at 09:47:33AM -0400, Antoine Beaupré wrote: >> On 2022-06-07 07:11:15, Julian Gilbey wrote: >> > [...] >> > As far as I understand, versioneer (or the _version.py generated by >> > it) uses a whole bunch of heuristics to determine the version number >> > of the package, for example by looking at git tags and so on. Several >> > times, I have found that _version.py in the PyPI release of a package >> > is a very small file (just a few lines long) stating the version >> > number of the package, while the _version.py in GitHub is huge and >> > doesn't work on a standalone packaged version. If I recall correctly, >> > In more than one package I (co-)maintain, I've gone for the PyPI >> > version of this file. >> >> Uh! So you just keep the file around altogether? That seems like a break >> of policy... > > Maybe I wasn't clear: we pack the GitHub as the .orig.tar.gz and then > apply a patch (in debian/patches) to replace _version.py with the > version found in the PyPI package. (There are often good reasons to > prefer the GitHub version over the PyPI version.) I just looked > through my local packages and the only examples I could find were the > now-removed python-language-server and python-jsonrpc-server. > > I'm not sure how this would break policy. It seems to me that generated files shouldn't be shipped as part of the source we distributed to users. Those files should be (re)generated at build time. a. -- Be who you are and say what you feel Because those who mind don't matter And those who matter don't mind. - Dr. Seuss
Re: a review of your bumblebee-status package
On 2022-06-06 23:42:19, Ben Westover wrote: > Here's another note: > > On 6/6/22 10:49 AM, Antoine Beaupré wrote: >> * i'm really not sure I like that C binary to fetch the keyboard >>layout... surely there must be a more pythonic way of doing this? i >>guess there's another layout-xkb module that does the right thing, >>but it seems odd to have both there.. > > This is apparently an issue that upstream already knows about > (https://github.com/tobi-wan-kenobi/bumblebee-status/issues/790) > but hasn't done anything about for a year. > The fact that there shouldn't be a C binary here at all has just now > been reported by me: > https://github.com/tobi-wan-kenobi/bumblebee-status/issues/883 That's good. I wonder if we could just not do this ourselves and patch that thing out. Then we could submit that upstream as a fix for the above... But that's not a blocker. I think as long as you fix the Architecture fields, this should just work. (And it seems like you did, on salsa.) -- Tout ce qui n’est pas donné est perdu. - Proverbe indien
Re: a review of your bumblebee-status package
On 2022-06-07 07:11:15, Julian Gilbey wrote: > Hi Ben, > > On Mon, Jun 06, 2022 at 10:42:53PM -0400, Ben Westover wrote: >> > > _version.py is not a copy of versioneer, it's *generated* by versioneer. >> > > However, there is versioneer.py in the root directory, which is. I'll >> > > exclude that from the source and repack. >> > >> > hmm... how about that generated file though? shouldn't it be ... well, >> > generated at build time instead? :) >> >> As far as I understand it, this file is used by the author of the program, >> not end users. I don't understand it well, though, because I haven't put >> much time into researching what versioneer even does. >> If my hunch is correct, I may be able to just remove the file from the >> source altogether, but I haven't tried that yet. > > As far as I understand, versioneer (or the _version.py generated by > it) uses a whole bunch of heuristics to determine the version number > of the package, for example by looking at git tags and so on. Several > times, I have found that _version.py in the PyPI release of a package > is a very small file (just a few lines long) stating the version > number of the package, while the _version.py in GitHub is huge and > doesn't work on a standalone packaged version. If I recall correctly, > In more than one package I (co-)maintain, I've gone for the PyPI > version of this file. Uh! So you just keep the file around altogether? That seems like a break of policy... -- On reconnait la grandeur et la valeur d'une nation à la façon dont celle-ci traite ses animaux. - Mahatma Gandhi
Re: a review of your bumblebee-status package
On 2022-06-06 22:42:53, Ben Westover wrote: > Hello Antoine, > I am aware of this failure and have reported it upstream. For now, I'll disable the offending test. >>> >>> After doing that, I discovered that almost all of the tests are faulty >>> (at least on Python 3.10), so I've disabled tests altogether for now. >> >> Does the package *work* at all in 3.10? We might not want to silence >> real errors here... > > Upstream says 3.4-3.9 is supported, but I don't know if that's because > 3.10 doesn't work or because they haven't bothered to add it. Searching > their bug tracker, I wasn't able to find any 3.10-related issues yet. > I also haven't tried to use the program with Python 3.10, because I > don't use it myself at all (packaging this for a friend). I think it's worth doing a trial run in an actual unstable VM before disabling those tests. Otherwise we're just guessing and we might put a completely non-working package out there... That's going to help no one: neither our users or upstream... >>> _version.py is not a copy of versioneer, it's *generated* by versioneer. >>> However, there is versioneer.py in the root directory, which is. I'll >>> exclude that from the source and repack. >> >> hmm... how about that generated file though? shouldn't it be ... well, >> generated at build time instead? :) > > As far as I understand it, this file is used by the author of the > program, not end users. I don't understand it well, though, because I > haven't put much time into researching what versioneer even does. > If my hunch is correct, I may be able to just remove the file from the > source altogether, but I haven't tried that yet. Well, it's used by the program to show the version info, so it's *eventually* used by users for sure. I think just removing the file is a good first guess. >> let me know when / if you need me to look at it again, and thanks again! > > It should be ready for review now, as long as I haven't messed anything > up majorly in my attempts to fix the issues you brought to my attention. Did you remove the versioneer file though? -- Striving for social justice is the most valuable thing to do in life - Albert Einstein
Re: a review of your bumblebee-status package
On 2022-06-06 21:10:31, Ben Westover wrote:
> Hello again,
> Some corrections to my previous message:
>
>> As for how it's installed, I believe that's handled by the upstream setup.py:
>> data_files=[
>> ("share/bumblebee-status/themes", glob.glob("themes/*.json")),
>> ("share/bumblebee-status/themes/icons",
>> glob.glob("themes/icons/*.json")),
>> ("share/bumblebee-status/utility", glob.glob("bin/*")),
>> ]
>> Looks like it's put into /something/share/bumblebee-status/utility.
>
> Confirmed that it's /usr/share/bumblebee-status/utility.
>
>>> * the build fails here, in a fresh Debian unstable qemu image, with:
>>>
>>> ERROR tests/core/test_output.py - RuntimeError: unable to find
>>> theme default
>>
>> I am aware of this failure and have reported it upstream. For now, I'll
>> disable the offending test.
>
> After doing that, I discovered that almost all of the tests are faulty
> (at least on Python 3.10), so I've disabled tests altogether for now.
Does the package *work* at all in 3.10? We might not want to silence
real errors here...
> _version.py is not a copy of versioneer, it's *generated* by versioneer.
> However, there is versioneer.py in the root directory, which is. I'll
> exclude that from the source and repack.
hmm... how about that generated file though? shouldn't it be ... well,
generated at build time instead? :)
let me know when / if you need me to look at it again, and thanks again!
a.
--
Every time I see an adult on a bicycle I no longer despair for the
future of the human race.
- H. G. Wells
Re: [Pkg-privacy-maintainers] Bug#1007165: Bug#1007165: please import upstream v21.1.0
I'm working on uploading v22 right now. -- In a racist society it is not enough to be non-racist, we must be antiracist. - Angela Davis
Re: Bug#1007025: I want to join the DPT
On 2022-03-18 22:22:25, Bo YU wrote: > On Fri, Mar 18, 2022 at 9:30 PM Antoine Beaupré wrote: [...] > Oops, my bad. I forget to cc you indeed :-(. No problem. :) >> By default, the BTS doesn't include the original submitter when you only >> write to the bug report... > > Thank you all. I have changed the RFP to ITP for the bug. I can't wait to > start the adventure. :-) You should also assign yourself to the ticket, by making your email address the "owner". -- Never underestimate the bandwidth of a station wagon full of tapes hurtling down the highway. - Andrew S. Tanenbaum, "Computer Networks"
Re: Bug#1007025: I want to join the DPT
On 2022-03-18 16:45:25, Bo YU wrote: > Hi all, > > On Thu, Mar 17, 2022 at 10:44 PM Sandro Tosi wrote: > >> > Sorry again. I recheck the #1007025 [0], it should be RFP tag. >> > This is my misspelt in the first request email. >> > So I think I can go to to work it :-) >> >> OMG you're right! i guess morning coffee hadnt kicked in when first >> replying. I would still contact anarcat before starting any work, >> because they may already have started the packaging effort and you two >> can collaborate. It's also possible nothing was done and so you can >> start from scratch. >> > 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:-). 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.) > 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). No offense taken whatsoever. Also: I didn't receive that email at all, I 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. -- >From the age of uniformity, from the age of solitude, from the age of Big Brother, from the age of doublethink - greetings! - Winston Smith, 1984
Re: help me update dateparser to 1.0.0 in time for bullseye
On 2021-02-09 08:23:27, stefa...@debian.org wrote: > Hi Antoine (2021.02.08_16:53:57_+) >> I have more cycles for this again, and see the 1.0 release still hasn't >> hit unstable... need help? :) > > Uploaded. I suspect it might be too late for the freeze (in three days?) but we'll see, I guess. Thanks for your work in any case!! a. -- Le pouvoir n'est pas à conquérir, il est à détruire - Jean-François Brient, de la servitude moderne
Re: help me update dateparser to 1.0.0 in time for bullseye
On 2021-02-05 04:41:37, Stefano Rivera wrote: > Hi Antoine (2021.02.05_02:13:56_+) >> I can't figure out how to update dateparser to 1.0.0. I am battling >> pytest and deps and failing. Seems like we'd need to package >> hijri_converter as a dependency, and fix the build so it doesn't require >> network. > > Also probably a good idea to package that CLDR data and rebuild the > tables from source. > > I pushed some commits to get the build time test passing. The > autopkgtest still needs to be changed to use pytest too, etc. > I'll finish this up later, and upload. > > Instead of my patches, you could have used pytest's > --continue-on-collection-errors flag. I have more cycles for this again, and see the 1.0 release still hasn't hit unstable... need help? :) a. -- Any sufficiently advanced technology is indistinguishable from magic. - Arthur C. Clarke
Re: help me update dateparser to 1.0.0 in time for bullseye
On 2021-02-05 04:41:37, Stefano Rivera wrote: > Hi Antoine (2021.02.05_02:13:56_+) >> I can't figure out how to update dateparser to 1.0.0. I am battling >> pytest and deps and failing. Seems like we'd need to package >> hijri_converter as a dependency, and fix the build so it doesn't require >> network. > > Also probably a good idea to package that CLDR data and rebuild the > tables from source. > > I pushed some commits to get the build time test passing. The > autopkgtest still needs to be changed to use pytest too, etc. > I'll finish this up later, and upload. > > Instead of my patches, you could have used pytest's > --continue-on-collection-errors flag. thanks stefano, you rock! and sorry for the state of the package, i know it's not exactly in sync with the best practices... -- La propriété est un piège: ce que nous croyons posséder nous possède. - Alphonse Karr
help me update dateparser to 1.0.0 in time for bullseye
hon3-all_3.9.1-1 python3-attr_20.3.0-1 python3-convertdate_2.2.1-1 python3-coverage_5.1+dfsg.1-2+b2 python3-dateutil_2.8.1-5 python3-distutils_3.9.1-2 python3-git_3.1.12-1 python3-gitdb_4.0.5-1 python3-importlib-metadata_1.6.0-2 python3-iniconfig_1.1.1-1 python3-lib2to3_3.9.1-2 python3-minimal_3.9.1-1 python3-mock_4.0.3-1 python3-more-itertools_4.2.0-3 python3-nose_1.3.7-7 python3-packaging_20.9-1 python3-parameterized_0.7.0-2 python3-pbr_5.5.0-2 python3-pkg-resources_52.0.0-1 python3-pluggy_0.13.0-6 python3-py_1.10.0-1 python3-pymeeus_0.3.7-1 python3-pyparsing_2.4.7-1 python3-pytest_6.0.2-2 python3-regex_0.1.20201113-1 python3-ruamel.yaml_0.16.12-2 python3-ruamel.yaml.clib_0.2.2-1+b2 python3-setuptools_52.0.0-1 python3-six_1.15.0-2 python3-smmap_3.0.4-1 python3-toml_0.10.1-1 python3-tz_2020.5-1 python3-tzlocal_2.1-1 python3-zipp_1.0.0-3 python3.9_3.9.1-3 python3.9-minimal_3.9.1-3 readline-common_8.1-1 sbuild-build-depends-main-dummy_0.invalid.0 sed_4.7-1 sensible-utils_0.0.14 sysvinit-utils_2.96-5 tar_1.32+dfsg-1 tzdata_2021a-1 util-linux_2.36.1-6 xz-utils_5.2.5-1.0 zlib1g_1:1.2.11.dfsg-2 +--+ | Build| +--+ Unpack source - Format: 3.0 (quilt) Source: dateparser Binary: python3-dateparser Architecture: all Version: 1.0.0-1 Maintainer: Debian Python Team Uploaders: Antoine Beaupré , Andrey Rahmatullin Homepage: https://github.com/scrapinghub/dateparser Standards-Version: 4.3.0.1 Vcs-Browser: https://salsa.debian.org/python-team/packages/dateparser Vcs-Git: https://salsa.debian.org/python-team/packages/dateparser.git Testsuite: autopkgtest Testsuite-Triggers: build-essential, locales-all, python3-all, python3-convertdate, python3-coverage, python3-mock, python3-nose, python3-parameterized, python3-six Build-Depends: debhelper-compat (= 12), dh-python, locales-all, python3-all, python3-convertdate, python3-coverage, python3-dateutil, python3-git, python3-mock, python3-nose, python3-parameterized, python3-pytest, python3-ruamel.yaml, python3-regex, python3-setuptools, python3-six, python3-tz, python3-tzlocal Package-List: python3-dateparser deb python optional arch=all Checksums-Sha1: 2f0a087c6dbbe86d6236766c6d78cbf1eef2a3e0 471943 dateparser_1.0.0.orig.tar.gz 657db08c7feb1171fe564e61ef79fa2381cfcb3a 3548 dateparser_1.0.0-1.debian.tar.xz Checksums-Sha256: aeaa2025f8b66d32757dfde5b988ce57e3addaaae8d56b99f69c14f6fdf996ee 471943 dateparser_1.0.0.orig.tar.gz 3ee753f653a9f6f7f5f3949072b0e6efad5b1a847ab1aa53850e71db871c4f97 3548 dateparser_1.0.0-1.debian.tar.xz Files: e02d7a1b33d02ab06f9f791e05d8663d 471943 dateparser_1.0.0.orig.tar.gz 47fc1f13948374505ef953654d3b8541 3548 dateparser_1.0.0-1.debian.tar.xz dpkg-source: warning: extracting unsigned source package (dateparser_1.0.0-1.dsc) dpkg-source: info: extracting dateparser in /<> dpkg-source: info: unpacking dateparser_1.0.0.orig.tar.gz dpkg-source: info: unpacking dateparser_1.0.0-1.debian.tar.xz Check disk space Sufficient free space for build User Environment APT_CONFIG=/var/lib/sbuild/apt.conf HOME=/sbuild-nonexistent LANG=fr_CA.UTF-8 LC_ALL=C.UTF-8 LOGNAME=anarcat PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games SCHROOT_ALIAS_NAME=unstable-amd64-sbuild SCHROOT_CHROOT_NAME=unstable-amd64-sbuild SCHROOT_COMMAND=env SCHROOT_GID=1000 SCHROOT_GROUP=anarcat SCHROOT_SESSION_ID=unstable-amd64-sbuild-b247c996-12bc-4f52-b178-0d00188ccff8 SCHROOT_UID=1000 SCHROOT_USER=anarcat SHELL=/bin/sh USER=anarcat dpkg-buildpackage - Command: dpkg-buildpackage -us -uc -rfakeroot dpkg-buildpackage: info: source package dateparser dpkg-buildpackage: info: source version 1.0.0-1 dpkg-buildpackage: info: source distribution UNRELEASED dpkg-buildpackage: info: source changed by Antoine Beaupré dpkg-source --before-build . dpkg-buildpackage: info: host architecture amd64 fakeroot debian/rules clean dh clean --with python3 --buildsystem=pybuild dh_auto_clean -O--buildsystem=pybuild I: pybuild base:232: python3.9 setup.py clean running clean removing '/<>/.pybuild/cpython3_3.9/build' (and everything under it) 'build/bdist.linux-x86_64' does not exist -- can't clean it 'build/scripts-3.9' does not exist -- can't clean it dh_autoreconf_clean -O--buildsystem=pybuild dh_clean -O--buildsystem=pybuild dpkg-source -b . dpkg-source: info: using source format '3.0 (quilt)' dpkg-source: info: building dateparser using existing ./dateparser_1.0.0.orig.tar.gz dpkg-source: info: building dateparser in dateparser_1.0.0-1.debian.tar.xz dpkg-source: info: building dateparser in dateparser_1.0.0-1.dsc debian/rules build dh build --with python3 --buildsystem=pybuild dh_update_autotools_config -O--buildsystem=pybuild
Re: [Python-modules-team] Processing of paramiko_2.7.1-1_source.changes
On 2020-05-11 22:27:57, Sandro Tosi wrote: > Antoine, you did not push the upstream branch. please do so, in order > to keep the repo consistent Oops, sorry about that, somehow I forgot that one... This is one of my problems with the multi-branch layout: I always forgot either upstream or pristine-tar... :/ Any trick to avoid those errors in general? Anyways, it should be there now! a. -- It is capitalism and government which stand for disorder and violence. Anarchism is the very reverse of it; it means order without government and peace without violence. - Alexander Berkman
Re: request to join the team, again
Same, with PAPT, please. Thanks. A. On 2017-12-30 09:46:28, Antoine Beaupre wrote: > Hi, > > I've been packaging stuff in Debian for a while and I'm often packaging > dependencies that would benefit from being under the DPMT umbrella. > > My alioth login is "anarcat". > > I have read read the policy and accept it. > > My next steps are to package the dependencies of the newest > rapid-photo-downloader. > > Thanks, > > A. > > -- > Quidquid latine dictum sit, altum sonatur. > Whatever is said in Latin sounds profound. -- It is capitalism and government which stand for disorder and violence. Anarchism is the very reverse of it; it means order without government and peace without violence. - Alexander Berkman signature.asc Description: PGP signature
Bug#909550: ITP: internetarchive -- python interface to archive.org
Package: wnpp Severity: wishlist Owner: Antoine Beaupré X-Debbugs-CC: debian-python@lists.debian.org * Package name: internetarchive Version : 1.8.1 Upstream Author : Jacob M. Johnson * URL : https://github.com/jjjake/internetarchive * License : AGPL 3 Programming Lang: Python Description : python interface to archive.org Command-line tool (`ia`) and Python library for searching, downloading and uploading content to the Internet Archive. -- Binary package names: python3-internetarchive python-internetarchive internetarchive Unsure about those package names: I wonder if the libraries should be separate from the main binary, although the latter is really just a wrapper for the former. Upstream documentation is available at: https://archive.org/services/docs/api/internetarchive/ I've tested the package as installed by pip and it seems to work well. py2dsp seems to work as well and was used to generate this email. Can (should?) be maintained under the PAPT (or DPMT?) umbrella. signature.asc Description: PGP signature
Re: providing sphinx3-* binaries
On 2017-09-28 19:59:12, Dmitry Shachnev wrote: > On Thu, Sep 28, 2017 at 08:27:20AM -0400, Antoine Beaupré wrote: >> > And moving Python 3 packages to /usr/bin/sphinx3-build or something like >> > that will mean diverging from upstream (see below). >> >> Note that we already diverge from upstream in numerous places in Python, >> first and foremost in the naming of the Python binary itself. > > How do we diverge there? In my opinion we follow PEP 394 quite closely: > https://www.python.org/dev/peps/pep-0394/ Ah. Oops. :) I guess I was thinking of virtualenvs... >> > Good suggestion, I have submitted a pull request upstream: >> > https://github.com/sphinx-doc/sphinx/pull/4092 >> >> Excellent - I meant to do that but ran out of time writing the email in >> the first place. :) >> >> I see, however, it's not getting too much traction.. But they have a >> fair point - I didn't realize there was a difference between variables >> from the environment and from the commandline in Make. Maybe it's good >> enough as it is then. > > It is not ‘they’, it is our Simon :) He also replied on this mailing list, > just did not CC you. Oops again. :) I replied there as well. [...] >> This is why I mention pybuild: maybe *that* is where docs should be >> built? I am not sure. In any case, I feel there's a shim missing here, >> and there's a good occasion to leverage the automation we have to >> generate proper build deps and build-time commands. > > Maybe pybuild can do this, but it then needs to make some assumptions > about the doc source path, build path, wished formats, etc. For finding source > path it can probably use something like this: > > https://github.com/sphinx-doc/sphinx/blob/stable/sphinx/setup_command.py#L111 > > But it is up to pybuild maintainer (Piotr) to decide whether he wants this > feature or not. Well, it would sure be nice to have some place for this, of course. [...] >> > Also there is no such thing as sphinx3-build upstream (unlike other >> > packages >> > that follow this convention). So all upstream projects will try to use >> > sphinx-build, not sphinx3-build, even if they are Python 3 only. And if you >> > override this command anyway, you can use two existing ways, I don’t see a >> > need for the third one. >> >> The reasoning here is that is is more discoverable, namely through >> commandline completion, and is consistent with the /usr/bin/python* >> binary naming conventions. > > I have just figured out that there *is* bash completion for python3 -m > syntax. What i meant is that "sphinx" doesn't show there is a python2 vs python3 version. [...] > Now it is explicit: > https://anonscm.debian.org/cgit/python-modules/packages/sphinx.git/commit/?id=5b2efffcaae8c915 Excellent, thanks again. A. -- Pour marcher au pas d'une musique militaire, il n'y a pas besoin de cerveau, une moelle épinière suffit. - Albert Einstein
Re: providing sphinx3-* binaries
On 2017-09-28 01:03:27, Dmitry Shachnev wrote:
> Hi Antoine, and thanks for the detailed mail!
>
> On Tue, Sep 26, 2017 at 06:29:05PM -0400, Antoine Beaupré wrote:
>> We just had a short conversation on the #debian-devel IRC channel
>> regarding the upcoming Python 2 EOL, in the context of the Sphinx
>> packages.
>>
>> [...]
>>
>> So that's the first problem I have. The other problem we identified is
>> that the /usr/bin/sphinx-build symlink is not owned by any package.
>>
>> $ LANG=C dpkg -S /usr/bin/sphinx-build
>> dpkg-query: no path found matching pattern /usr/bin/sphinx-build
>>
>> That's a rather bad practice... We shouldn't install those symlinks in
>> postinst. They should be alternatives or conflicts or *something*. In
>> 2013, the sphinx maintainer [explained][1] the following:
>>
>> > True for docutils; however, sphinx doesn't use alternatives, and it
>> > doesn't do so for good reasons.
>> >
>> > The alternatives mechanisms is only suitable if both commands are
>> > compatible, i.e. their behavior doesn't vary with Python version. This
>> > is the case for rst2html and friends, but no so much for
>> > sphinx-build. The problem is that sphinx-build can import 3rd-party
>> > Python code, which is not necessarily compatible with both Python 2
>> > and 3.
>>
>> I understand that reasoning, but I don't think I agree with it. Or at
>> least, I don't think that, in the long term, it should be something that
>> blocks us.
>
> I think the reason why we should not use alternatives still applies. The
> current approach is conservative and it guarantees that when a package has
> python-sphinx in build-dependencies, /usr/bin/sphinx-build will always use
> Python 2. With alternatives there is no such guarantee.
Understood, fair point.
> And moving Python 3 packages to /usr/bin/sphinx3-build or something like
> that will mean diverging from upstream (see below).
Note that we already diverge from upstream in numerous places in Python,
first and foremost in the naming of the Python binary itself.
>> I am not sure what the solution is, but I would offer the following:
>>
>> 1. there should be a more easy way to override SPHINXBUILD in
>> quickstart-generated Makefiles. IMHO, that means SPHINXBUILD?=
>> instead of SPHINXBUILD=
>
> Good suggestion, I have submitted a pull request upstream:
> https://github.com/sphinx-doc/sphinx/pull/4092
Excellent - I meant to do that but ran out of time writing the email in
the first place. :)
I see, however, it's not getting too much traction.. But they have a
fair point - I didn't realize there was a difference between variables
from the environment and from the commandline in Make. Maybe it's good
enough as it is then.
>> 2. similarly, --with=sphinx should do the right thing depending on the
>> detected pybuild Python version, that is, call
>> /usr/share/sphinx/scripts/python{,3}/sphinx-build directly depending
>> on which version we are building for.
>
> I do not understand this. You mentioned pybuild, so you are talking about
> setup.py based build systems, not Makefile based ones, right?
True. Well, technically, I refer to dh_sphinxdoc, but from what I could
tell, that doesn't seem to actually *build* the documentation, but just
clean it up, something I didn't expect.
> If setup.py calls build_sphinx automatically, then there is nothing else
> to do. If it does not, then you should call ‘setup.py build_sphinx’ with
> explicit interpreter, i.e. python or python3.
>
> The only thing where pybuild may help is when you want to run Sphinx for
> all supported Python versions, then you can use its COMMAND syntax.
>
> And there is no such thing as --with=sphinx. There is --with=sphinxdoc,
> but it operates on already built and installed documentation, so it cannot
> help with building.
I guess this is what I mean should be automated better. Every time I
used --with=sphinxdoc, I expected it to build the docs and then
remembered, when the produced package lacked any docs whatsoever, that I
needed to build things myself.
A simple --with=sphinxdoc should be sufficient to build sphinx docs. We
shouldn't expect upstream to do that step in setup.py, as it is rarely
hooked into the main build. Yes, there's the `build_sphinx` command, but
it's not hooked into `setup.py build` except in some rare project.
This is why I mention pybuild: maybe *that* is where docs should be
built? I am not sure. In any case, I feel there's a shim missing here,
and there's a good occasion to leverage the automation we have to
generate proper build deps and build-time commands.
>> 3. sphinx packages should follow the "python vs python3&
