Re: Fwd: grammalecte_2.1.2+ds-1_amd64.changes REJECTED
On 2021-11-08 14 h 00, Romain Porte wrote: > Hello, > > 06/11/2021 18:18, Louis-Philippe Véronneau : >> Hello! >> >> Grammalecte was rejected. It would be nice if you could fix the issue >> mentioned below :) > > Please have a look at https://mentors.debian.net/package/grammalecte/ > > DSC file: > https://mentors.debian.net/debian/pool/main/g/grammalecte/grammalecte_2.1.2+ds-1.dsc > > > Commits since last upload: > > * 534d918 (HEAD -> debian/latest, origin/debian/latest) d/changelog: update > * a9a6817 fix missing autopkgtest dep > * 3f684d0 fix d/copyright REJECT > * 1f38706 fix d/watch > * e6d7849 introduce d/salsa-ci.yml > > Salsa repo: https://salsa.debian.org/python-team/packages/grammalecte > > Thanks. > Sorry for being so slow to sponsor. While trying to build, I get this error: mv: will not overwrite just-created 'debian/tmp/usr/share/doc/python3-grammalecte/README.txt' with 'debian/tmp/usr/lib/python3.9/dist-packages/grammalecte/README.txt' This happens because you are trying to move multiple files to the same path: debian/tmp/usr/lib/python3.10/dist-packages/grammalecte/README.txt debian/tmp/usr/lib/python3.9/dist-packages/grammalecte/README.txt -> debian/tmp/usr/lib/python3.9/dist-packages/grammalecte/README.txt I'd suggest singling out one python interpreter with `py3versions -d`? -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄ OpenPGP_signature Description: OpenPGP digital signature
Re: DPT repositories checks/"violations" report
On 2021-11-27 08 h 54, Stefano Rivera wrote: > Hi Sandro (2021.11.27_06:01:08_+) > >> Hello, >> while working on something else[1], i noticed how many of the >> repositories in the DPT salsa group are in poor shape: >> >> * missing branches >> * changes not pushed to salsa >> * general misalignment in configuration/setup/organization >> * many other small nuances >> >> [1] https://github.com/sandrotosi/debian-python-team-tracker > > +1 this is great! \0/ I've been wanting something for QA like that for a while, but never had the time / energy to look into it further. All in all, it's too easy to forget to push something to Salsa and never realise it. >> please take the content with caution, as it's still an early, raw >> draft (i spot-checked some of the reported issues, but there could be >> bugs/issues) and it contains data that can be outdated (see below re >> caching); the fact that the report indicates only 43 repos are without >> violations is a bit disarming, but i think the tool tries to err on >> the side of verbosity and pedantry, with 2 level of violations (ERROR >> and WARNING) to mark which ones are the most important that require >> immediate attention vs the nice-to-have ones. > > When we did the migration to git, there weren't good tools for managing > the setup of the salsa repos (hooks, etc.) yet. I'd assume those exist > now, we should check in with what other teams are doing. That stuff can > all be fixed in one run of a tool, I'd assume. Could this become part of the Debian Janitor at some point? I could see teams adding a per-team config file to check things like what branch names should be expected, etc. and the Janitor fixing all this if it has commit access. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄ OpenPGP_signature Description: OpenPGP digital signature
Re: DPT repositories checks/"violations" report
Hi Sandro (2021.11.27_06:01:08_+) > Hello, > while working on something else[1], i noticed how many of the > repositories in the DPT salsa group are in poor shape: > > * missing branches > * changes not pushed to salsa > * general misalignment in configuration/setup/organization > * many other small nuances > > [1] https://github.com/sandrotosi/debian-python-team-tracker +1 this is great! I've been doing some 3.10 NMUs recently, and found myself re-creating several upstream and pristine-tar branches... > please take the content with caution, as it's still an early, raw > draft (i spot-checked some of the reported issues, but there could be > bugs/issues) and it contains data that can be outdated (see below re > caching); the fact that the report indicates only 43 repos are without > violations is a bit disarming, but i think the tool tries to err on > the side of verbosity and pedantry, with 2 level of violations (ERROR > and WARNING) to mark which ones are the most important that require > immediate attention vs the nice-to-have ones. When we did the migration to git, there weren't good tools for managing the setup of the salsa repos (hooks, etc.) yet. I'd assume those exist now, we should check in with what other teams are doing. That stuff can all be fixed in one run of a tool, I'd assume. SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Re: xcffib update for qtile packaging
Hi Jérôme, On 11/27/21 3:44 PM, Jérôme wrote: Hello, In the absence of a reply, I have worked on xcffib package to update it to the last upstream release as well as Debian standards. I intend to adopt it[1] but I am looking for a sponsor - or moving this package to DPT? - in order to upload it. Does anybody here have time for that please? And any review is welcome, here is the current repository: https://salsa.debian.org/jlebleu/xcffib Moved to DPT and uploaded as well. I pushed some changes though, do consider taking a look at them. Thank you very much for working on it and adopting the same. :-) Regards, Nilesh OpenPGP_signature Description: OpenPGP digital signature
Re: DPT repositories checks/"violations" report
On Sat, 27 Nov 2021 at 09:38:41 +, Scott Kitterman wrote: > I don't think the pypi tarball "issue" should be presumed to be a > problem at all. I wasn't paying attention to Debian when that discussion > happened, but in my experience there was a lot wrong with the idea. > A properly constructed sdist is exactly what we want to build a package > from. That's almost never found on GitHub. I think the closest we got to a conclusion was "it depends": if your upstream reliably produces a properly constructed sdist (or at least is happy to accept pull requests to make their sdist properly constructed) then it makes an ideal source package, but if your upstream treats sdists in closer to the same way a C programmer would treat a prebuilt binary release (omitting source and including content generated from that source instead), then a git clone is probably more appropriate. To me, at least, it makes sense for this to be a case-by-case decision made by someone who is familiar with this specific upstream - and wanting to have someone familiar with this specific upstream is why we have named maintainers, rather than having everything collectively-maintained like some distributions do. (For what it's worth, the GNOME team uses a mixture of `meson dist` and git clones, and that's with an upstream that is a single project that is in principle meant to be team-maintained with a single cohesive policy - so if we can't standardize on one source format being "always the right one" for GNOME, I would be very surprised if the Python team was able to standardize on one source format for a large number of separate upstreams linked only by their implementation language.) smcv
xcffib update for qtile packaging
Hello, In the absence of a reply, I have worked on xcffib package to update it to the last upstream release as well as Debian standards. I intend to adopt it[1] but I am looking for a sponsor - or moving this package to DPT? - in order to upload it. Does anybody here have time for that please? And any review is welcome, here is the current repository: https://salsa.debian.org/jlebleu/xcffib Thanks in advance, Jérôme [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=952121 16/08/2021 09:16, Jérôme: Hi, Qtile[1] is « a full-featured, hackable tiling window manager written and configured in Python ». I am using it on Debian for few years thanks to the initial work of Iain R. Learmonth - who has retired from the Debian project as of now. It has been a little while since I would like to contribute to this package, but I take the opportunity of Bullseye release to do it! Does anybody plan to work on it, or is using it? I would prefer to not maintaining it alone. I will open an ITP bug and work on the packaging in order to push it to Salsa and ask some review. I am only maintaining one package as of now - written in C++ with Qt - so any sponsoring would be welcome if someone has some time! Qtile also depends on xcffib which needs to be updated. I can adopt this package too. Again, if anybody plan to work on it, or is working on a package which depends on it, feel free to tell. Thanks in advance! Regards, Jérôme [1] http://www.qtile.org/
Re: DPT repositories checks/"violations" report
On November 27, 2021 6:01:08 AM UTC, Sandro Tosi wrote: >Hello, >while working on something else[1], i noticed how many of the >repositories in the DPT salsa group are in poor shape: > >* missing branches >* changes not pushed to salsa >* general misalignment in configuration/setup/organization >* many other small nuances > >[1] https://github.com/sandrotosi/debian-python-team-tracker > >That makes it hard to make mass work as in [1], so I thought it would >be interesting to have a tool to evaluate the amount of issues our >repos have, and identify such "violations" so that they can be >addressed. > >That information is now available at [2]. > >[2] https://github.com/sandrotosi/dpt-repos-check/blob/main/violations.txt > >please take the content with caution, as it's still an early, raw >draft (i spot-checked some of the reported issues, but there could be >bugs/issues) and it contains data that can be outdated (see below re >caching); the fact that the report indicates only 43 repos are without >violations is a bit disarming, but i think the tool tries to err on >the side of verbosity and pedantry, with 2 level of violations (ERROR >and WARNING) to mark which ones are the most important that require >immediate attention vs the nice-to-have ones. > >The checks are under-documented, although they should be somehow >self-explanatory. While the current format is just a text file, I plan >on getting it converted to markdown, although I'm still not sure how >to convey that amount of information effectively. > >The report is extremely intensive to generate, as it needs to make 10+ >API calls to salsa.d.o for each repository, and it gets throttled >quite early in the run (i got away in dev by installing a cache, so >that i could test it without hitting salsa every time, but that makes >some info stale); for that reason, and if we decide is valuable to >generate it periodically, i don't expect to be able to run it more >than once a month (maybe once a week? TBD). > >Comments, critics and improvements are welcome. I don't think the pypi tarball "issue" should be presumed to be a problem at all. I wasn't paying attention to Debian when that discussion happened, but in my experience there was a lot wrong with the idea. A properly constructed sdist is exactly what we want to build a package from. That's almost never found on GitHub. Scott K
