Re: Bug#1065325: morph's abandoned packages (list)
On Sat, May 11, 2024 at 11:54:29PM +0200, Alexandre Detiste wrote: > Yes do please. i finished migrating to dh13 and pushed to salsa > Le sam. 11 mai 2024 à 20:51, Nilesh Patra a écrit : > > > > Quoting Alexandre Detiste : > > > I would pick-up matplotlib I guess, I have some special connection to it, > > > It was one the packages that enabled me to escape > > > my horrible SAS-Insitute powered previous job/life. > > > > > > It's a big one. > > > > > > Help is appreciated, I already cherry picked some commits from Ciel's PR. > > > > Would you consider to add me in as an Uploader (co-maintainer) alongside > > you? > > > > I am a Debian Developer. > > > > Best, > > Nilesh Best, Nilesh signature.asc Description: PGP signature
Re: morph's abandoned packages (list)
Quoting Alexandre Detiste : > I would pick-up matplotlib I guess, I have some special connection to it, > It was one the packages that enabled me to escape > my horrible SAS-Insitute powered previous job/life. > > It's a big one. > > Help is appreciated, I already cherry picked some commits from Ciel's PR. Would you consider to add me in as an Uploader (co-maintainer) alongside you? I am a Debian Developer. Best, Nilesh signature.asc Description: PGP signature
Re: Suggesting change in DPT Policy
On 2024-02-27 03:05, Andreas Tille wrote: > I became more deeply involved into DPT since 2022 as a consequence of > the suggestion for transfering several Debian Med/Science packages to > DPMT[1][2]. I happily followed this suggestion and moved >30 packages > from the Blends teams to DPT. I was happy with this move since it makes > sense. > > Recently we received lots of testing removal warnings in those Blends > teams due to RC bugs caused by Cython 3.0 and Python3.12 migrations. So > I did what I usually do in those teams: I dedicated quite some time in > team wide bug hunting. That way I squashed about 50 bugs on packages > where I was not in Uploaders. When doing so I usually run > routine-update on the package which basically streamlines packaging to > latest standards including calling Janitor tools which are so far > accepted inside DPT. > > I probably should have reviewed the DPT policy on Maintainership[3] more > carefully. In other teams, it's common for the Maintainer to be set to > the team, so I assumed it was just an oversight when I made this > change[4] when touching the package to fix RC bug #1058177. However, I > I was pointed immediately about the fact that I was mistaken according > to the current DPT policy. I apologize for this. However, the wording > of the comment on my commit was discouraging, especially considering I > was a volunteer who had fixed a critical bug. Because of this, I > decided to focus my efforts on fixing other critical bugs for the > moment. If the comment had started with a 'Thanks for fixing the > critical bug, but...' I likely would have corrected my mistake quickly. > The lack of respect from my teammate simply made me prioritize my time > on other issues that are more visible to our users. I wonder whether I > should propose another change to the policy about maintaining a kind and > polite language inside the team - but that's a different thing. > > While I applied the patch for another RC bug (#1063443) after >2 weeks > which triggered a RC bug in reportbug I remembered the "keep the > maintainer" policy. But I kept on doing Janitor like changes since > finally the package is maintained in a team where Janitor is accepted. > When doing so I failed the phrase "please contact the Maintainer for the > green light." I apoligize for this again. The response was another > volunteer-demotivating private mail (thus no quote) which also was > lacking the "Thanks for fixing"-phrase and degrading my changes as > "frivolous". > > So far what happened (seen from my possibly biased perspective). > > Why do I like to change the policy? > > The current wording provides some means to stop volunteer team members > helping out moving forward to speed up migrations and fix Debian wide > dependencies. It hides team maintained packages from a common BTS > view. When pointing my browser to > https://bugs.debian.org/team+pyt...@tracker.debian.org > I currently see 1339 open bugs (calculated by [UDD1]). This hides > another 309 [UDD2] bugs (>18% of team bugs) from our sight. To work > around this flaw I used an UDD query to find relevant Python3.12 bugs. > > When I think twice about the wording > Team in Uploaders is a weak statement of collaboration.[3] > I personally consider it a statement of *no* collaboration (which fits > the wording of the responses I've got). > > How can a team member for instance find another RC bug #1009424? Just > from reading the bug report it is pretty easy to fix but does not > feature any response in BTS. I came across this while looking into > Cython 3.0 bugs. The same source package (basemap) that had the open > Cython bug (#1056789, tagged patch since 2023-12-09) is featuring RC bug > (#1009424) that stayed unattended for 22 months? We all know volunteers > have limited time and I do not want to blame anybody in the team to not > care promptly about RC bugs. But what else is the sense of a packaging > team than stepping in situations for long standing RC bugs and RC bugs > tagged patch? > > This kind of situation wouldn't occur in teams where collaboration is > strong and communication is effective. My motivation to address these > long-ignored critical bugs diminishes when the maintainer opts for > "weak" cooperation and lacks respectful communication with potential > helpers. I see no difference to simply do a NMU. > > I've checked the current situation who is actually using the DPT team as > Uploaders[UDD3]. 66 of the 73 maintainers have less than 5 packages > some of these "Maintainers" are other teams and lots of the persons > listed as Maintainer are known to be MIA. This means the packages are > de-facto not maintained which is most probably an unwanted effect of the > current policy. I know other maintainers from other teams to be fine > with stronger team understanding. > > Since I consider the current
Re: Remaining numpy 1.24 issues on 32bit architectures
Hi,
On Mon, Jan 30, 2023 at 09:12:57AM +0100, Andreas Tille wrote:
> I made some tiny steps forward ("only" 84 failures instead of 89 when I
> wrote my first mail) in the numpy 1.24 migration for 32bit architectures
> but I'm facing issues I do not have a real clue for. In
>
>
> https://salsa.debian.org/med-team/python-skbio/-/blob/master/debian/patches/numpy-1.24.patch#L123-L126
Apologies for pointing the discussion into an orthogonal direction for
once. Ofcourse, we could try fixing these, but if you look closely, skbio
has never built on 32 bit archs ever since around 2016 on i386[3] and
it has never built on the rest of 32 bit ever since it entered debian[4]
and now this new upstream FTBFS that you point to, won't really block
migration in any way.
So my question is this: Why are we trying hard to fix this on 32-bit _now_
given that the upstream support has never been solid for this package on
32-bit archs?
> ...
> which obviosly[2] failed. I wonder whether someone might give some
> hints how to get dtypes consistently to one integer representation which
> is the background of nearly all these test suite issues.
I can think of two alternatives to fix this:
1. There are a few type conversions to "int" (.astype(int)) in the skbio source
code.
This defaults to 32-bit integer type on 32-bit machines. Explicitly
casting them to 64-bit can fix this. I happened to write a similar patch
for another package recently, see[5] if it helps.
2. Just ignore datatypes while comparing pandas dataframes with
`check_dtype` parameter. An example/reference patch here[6]
> > [1]
> > https://buildd.debian.org/status/package.php?p=python-skbio=experimental
> [2] https://salsa.debian.org/med-team/python-skbio/-/jobs/3868951
[3]: https://buildd.debian.org/status/logs.php?pkg=python-skbio=i386
[4]:https://buildd.debian.org/status/logs.php?pkg=python-skbio=armhf
[5]:
https://salsa.debian.org/med-team/python-bioframe/-/blob/master/debian/patches/32-bits.patch
[6]:
https://salsa.debian.org/python-team/packages/python-upsetplot/-/blob/master/debian/patches/ignore-dtype-while-asserting.patch
--
Best,
Nilesh
signature.asc
Description: PGP signature
Re: librcsb-core-wrapper: (autopkgtest) needs update for python3.11: initialization of CorePyWrap raised unreported exception
Hi again, On Mon, Nov 28, 2022 at 08:05:35PM +0530, Nilesh Patra wrote: > On Sun, 27 Nov 2022 22:26:31 +0100 Paul Gevers wrote: > > Source: librcsb-core-wrapper > > Version: 1.005-10 > > We are in the transition of adding python3.11 as a supported Python > > version [0]. > > [...] > > [0] https://bugs.debian.org/1021984 > > [1] https://qa.debian.org/excuses.php?package=python3-defaults > > > > https://ci.debian.net/data/autopkgtest/testing/amd64/libr/librcsb-core-wrapper/28726239/log.gz > > > > Testing with python3.11: > > Traceback (most recent call last): > >File "", line 1, in > > SystemError: initialization of CorePyWrap raised unreported exception > > autopkgtest [17:14:04]: test autodep8-python3 > > There are a few similar bug reports with same error messages which aren't > helpful and > I am not quite sure as to how to debug errors like these. I did try to check > this using > gdb but I don't get anything helpful from this either. > > I also found similar bug reports on a few git hub projects, without any > closure/conclusion, > for instance this one[1] > > Could someone on the list please help fix this/point towards the right > direction to check so > this can be debugged ny further? Similar report is also filed for tagpy (Bug#1025201) -- could someone please help in fixing these? > [1]: https://github.com/hsnr-gamera/gamera-4/issues/54 -- Best, Nilesh signature.asc Description: PGP signature
Re: librcsb-core-wrapper: (autopkgtest) needs update for python3.11: initialization of CorePyWrap raised unreported exception
Hi all, On Sun, 27 Nov 2022 22:26:31 +0100 Paul Gevers wrote: > Source: librcsb-core-wrapper > Version: 1.005-10 > We are in the transition of adding python3.11 as a supported Python > version [0]. > [...] > [0] https://bugs.debian.org/1021984 > [1] https://qa.debian.org/excuses.php?package=python3-defaults > > https://ci.debian.net/data/autopkgtest/testing/amd64/libr/librcsb-core-wrapper/28726239/log.gz > > Testing with python3.11: > Traceback (most recent call last): >File "", line 1, in > SystemError: initialization of CorePyWrap raised unreported exception > autopkgtest [17:14:04]: test autodep8-python3 There are a few similar bug reports with same error messages which aren't helpful and I am not quite sure as to how to debug errors like these. I did try to check this using gdb but I don't get anything helpful from this either. I also found similar bug reports on a few git hub projects, without any closure/conclusion, for instance this one[1] Could someone on the list please help fix this/point towards the right direction to check so this can be debugged ny further? [1]: https://github.com/hsnr-gamera/gamera-4/issues/54 Cheers! -- Best, Nilesh signature.asc Description: PGP signature
Re: compreffor FTBFS with Python 3.11 as supported version
Hi Python team/Stefano, On Sun, 13 Nov 2022 20:34:36 +0200 Adrian Bunk wrote: > Source: compreffor > Version: 0.5.1-2 > Severity: serious > Tags: ftbfs > > https://buildd.debian.org/status/logs.php?pkg=compreffor=0.5.1-2%2Bb2 > > ... > src/cython/_compreffor.cpp:196:12: fatal error: longintrepr.h: No such file > or directory > 196 | #include "longintrepr.h" > |^~~ This seems to stem from moving a header file in py3.11 $ apt-file search longintrepr.h [...] libpython3.10-dev: /usr/include/python3.10/longintrepr.h libpython3.11-dev: /usr/include/python3.11/cpython/longintrepr.h Was this really intended? -- Best, Nilesh signature.asc Description: PGP signature
Re: zope.testrunner: FTBFS: AttributeError: 're.Pattern' object has no attribute 'replace'
reassign -1 dh-python 5.20220924
stop
Hi,
On Sun, 18 Sep 2022 08:02:58 +0200 Lucas Nussbaum wrote:
> Source: zope.testrunner
> > make[1]: Entering directory '/<>'
> > dh_python3 --shebang=/usr/bin/python3 -X tests
> > I: dh_python3 tools:114: replacing shebang in
> > debian/python3-zope.testrunner/usr/bin/zope-testrunner3
> > I: dh_python3 tools:114: replacing shebang in
> > debian/python3-zope.testrunner/usr/bin/zope-testrunner
> > Traceback (most recent call last):
> > File "/usr/bin/dh_python3", line 284, in
> > main()
> > File "/usr/bin/dh_python3", line 214, in main
> > dependencies.parse(stats, options)
> > File "/usr/share/dh-python/dhpython/depends.py", line 228, in parse
> > args += " -X '%s'" % pattern.replace("'", r"'\''")
> > AttributeError: 're.Pattern' object has no attribute 'replace'
> > make[1]: *** [debian/rules:20: override_dh_python3] Error 1
This looks like a bug with dh-python itself. Maybe this needs to be "sub"
instead of "replace", similar
string regex replaces at a couple more places.
Please let me know if I made a mistake here and this is not a bug in dh-python.
--
Best,
Nilesh
signature.asc
Description: PGP signature
Re: rdflib: FTBFS: dh_auto_test: error: pybuild --test --test-nose -i python{version} -p "3.10 3.9" returned exit code 13
On 2/24/22 6:10 PM, Andreas Tille wrote: Sorry for dragging you into this - the experimental branch was way advanced which I learned in bug #995675. This leaves the question how we can proceed. It makes probably sense to run ratt or something like this to learn about packages that are broken. Looks like I made some wasted effort there :/ Although, Michael's changes are pretty similar to mine Unfortunately I did never got ratt working (since I failed to setup sbuild properly). Would be nice if you could do this. There's also a ruby-team/meta[1] these are all shell scripts so maybe you could use maybe you can replace sbuild with pdebuild (or whatever you use) and try On the other hand in the current situation with two open RC bugs all other packages are broken anyway and will be removed from testing if we do not act upon the issue. So may be we should upload to unstable? What do you think? Pseudo excuses do not look too bad[2] and package in testing this is broken anyway, you can upload IMO [1]: https://salsa.debian.org/ruby-team/meta [2]: https://release.debian.org/britney/pseudo-excuses-experimental.html#rdflib Regards, Nilesh OpenPGP_signature Description: OpenPGP digital signature
Re: rdflib: FTBFS: dh_auto_test: error: pybuild --test --test-nose -i python{version} -p "3.10 3.9" returned exit code 13
On 2/24/22 6:00 PM, Nilesh Patra wrote: One really odd thing I noticed is that there is no dh_auto_build is overridden but not triggered inside it again, and so dh_auto_build happening at all. ^ Wow, in a hurry I wrote really sloppy english there I meant there is a override_dh_auto_build in d/rules, but nothing sensible is happening there except for building docs, i.e. dh_auto_build is not called again in the override, and so there is no build happening at all. I fixed this thing. OpenPGP_signature Description: OpenPGP digital signature
Re: rdflib: FTBFS: dh_auto_test: error: pybuild --test --test-nose -i python{version} -p "3.10 3.9" returned exit code 13
On 2/24/22 3:36 PM, Andreas Tille wrote: Please consider releasing rdflib v6 which in my brief testing is compatible with pyparser v3. I tried to follow your suggestion to upgrade rdflib to version 6 in Git. Unfortunately I'm stumbling upon a different issue in the new test suite[1]. One really odd thing I noticed is that there is no dh_auto_build is overridden but not triggered inside it again, and so dh_auto_build happening at all. So I enabled this, which got the tests running. Next there were some tests that need internet access or trying to open tcp ports, so I disabled them; after which the package is building. I am simply running these tests also as autopkgtest with "needs-internet" restriction which should be a good enough scrutiny. All changes in salsa. But please kindly check this properly before you do a dput. Hope that helps. Regards, Nilesh OpenPGP_signature Description: OpenPGP digital signature
Re: Salsa python-team write access for tiledb-py ?
On 2/18/22 9:33 PM, Dirk Eddelbuettel wrote: Hi debian-python, [...] I cannot write to https://salsa.debian.org/python-team/packages/tiledb-py so I created a (temporary ?) copy at https://salsa.debian.org/edd/tiledb-py If you're ok with me updating the team repo, I can reset origin and push to existing one. I granted you access to that repo; I however do not have enough powers to add you into the team. But I hope that helps you, anyway. Regards, Nilesh OpenPGP_signature Description: OpenPGP digital signature
Re: Should we allow Janitor to commit directly to all DPT packages?
On 2/18/22 2:23 AM, Sandro Tosi wrote: I admit I'm hesitating a bit for different reasons. While I agree that direct commits are better than MRs I found several DPT packages with very sensible changes in Git but no uploads following these. For instance fixing VCS fields and Maintainer name should be followed by an according upload to make those changes visible to users and developers of the *packages* in Debian. In the Debian Med team for instance we do those automatic changes before uploading a package - say when upgrading to new upstream versions or fixing some bugs. Than we run the Janitor scripts and other automatic changes which is all done in routine-update. I personally find this workflow more convenient. That way Debian Med team (as well as pkg-r team) are blacklisted for Janitor to not have competing changes inside the package. thanks for bringing the perspective of how things are done in the Med team, but it feels none of the points you mentioned nor the specific Med team workflow apply here, I suppose the highlight was the usage of routine-update[1] package before upload and we could use it with DPT too. This does similar(same?) changes as in janitor. But that said, I agree with what you wrote: or are relevant to just let Janitor commit directly to our packages. I vote a in for/OK for janitor to commit directly as well. [1]: https://tracker.debian.org/pkg/routine-update Regards, Nilesh OpenPGP_signature Description: OpenPGP digital signature
Re: Please make a separate package for mistune 2.x
On 2/6/22 12:20 AM, Julian Gilbey wrote:
On Fri, Feb 04, 2022 at 09:27:59PM +0530, Nilesh Patra wrote:
On 2/4/22 9:18 PM, Julian Gilbey wrote:
[...]
_mistune.py within the Debian package,
and have nbconvert do "import nbconvert.filters._mistune as mistune"
(see /usr/lib/python3/dist-packages/nbconvert/filters/markdown_mistune.py).
That seems like an eminently sensible solution to this problem.
But that'd lead to a number of mistune's embedded copies in a huge number of
packages; since majority of
the rev-deps (when I last checked) haven't adapted to this new version. When
they do,
and it becomes a overhead to fix each one later.
Even worse, if we discover a security problem sometime later, then all such
packages would be
effected, and that honestly does not look like a good idea to me.
I have just had another idea, which might solve all of the problems:
create a new Debian package called mistune0 (or mistune1), which
contains the legacy version of mistune, but with the Python module
called "mistune0" instead of "mistune". Then it will be
co-installable with mistune 2.x, and the packages which still depend
on mistune 0.8.4 could be patched to say "import mistune0 as mistune"
until they are updated upstream. This will also avoid having multiple
copies of the legacy code in the archive, which addresses the security
issue, and allow those packages which have migrated to mistune 2.x to
still say "import mistune".
Ah, looks like we just had to think in the reverse direction from the initial
proposal (mistune-{0,1} instead of mistune-{1,2}).
Indeed, that sounds like a much better plan.
I hope PEB agrees with this as well, would like to hear from them :)
Thanks for the discussion, Julian :)
Regards,
Nilesh
OpenPGP_signature
Description: OpenPGP digital signature
Re: Please make a separate package for mistune 2.x
On 2/4/22 9:33 PM, Julian Gilbey wrote: _mistune.py within the Debian package, and have nbconvert do "import nbconvert.filters._mistune as mistune" (see /usr/lib/python3/dist-packages/nbconvert/filters/markdown_mistune.py). That seems like an eminently sensible solution to this problem. But that'd lead to a number of mistune's embedded copies in a huge number of packages; since majority of the rev-deps (when I last checked) haven't adapted to this new version. When they do, and it becomes a overhead to fix each one later. Even worse, if we discover a security problem sometime later, then all such packages would be effected, and that honestly does not look like a good idea to me. This is true, though there are only 7 reverse dependencies currently in testing. Yeah, in total the reverse-deps are 8 and there is one different reverse-build-dep (pasted at end of this mail) But the problem is if these fall through the cracks, and close to the release we notice some package is not looking nice. Also, if you suppose that the upstreams are very slow, and we get to the new debian release with these things still embedded, it'd be a real mess to upload fixes to stable, right... I somehow do not understand the urgency of uploading this newer version, as the maintainer said: | I intend to upload src:mistune 2.0.0 to unstable between March the | 15th and April the 15th (depending on the progress of its | reverse-dependencies). We could simply wait a little more for the dust to settle, IMHO. That would be a reasonable approach, but how long will it take for the dust to settle? With this major change, and no guidance from upstream on how to migrate, and at least a number of upstream authors happy to rely on setup.py having "mistune <1.0.0" in the install_requires field, it might be several months or longer before things are fixed upstream. I think we could do this transition even a month or two before the soft freeze starts, which is roughly an year from now (considering general trend timings of starting in feb in release year). Situation might improve by then, I suppose. If it does not, we could still go ahead with the older python3-mistune in the archive, I do not see a huge problem there, except for maybe a few mistune uploads to stable if desired. And what do we do when some packages have converted and some haven't? In such a case, we atleast will have a few examples to see how to go about doing the API changes the right way. We could patch out at our end and send the changes upstream for review provided we are stuck in an unfortunate situation. Let me know what you'd think about this? Regards, Nilesh Reverse-Depends * giara [amd64 arm64 armel armhf i386 mips64el mipsel ppc64el s390x] * iredis * lektor * lookatme * matrix-mirage [amd64 arm64 armel armhf i386 mips64el mipsel ppc64el s390x] * python3-flasgger * python3-m2r * python3-schema-salad Reverse-Testsuite-Triggers * markdown-it-py Reverse-Build-Depends * lektor * lookatme * markdown-it-py * python-flasgger * python-m2r * python-schema-salad OpenPGP_signature Description: OpenPGP digital signature
Re: Please make a separate package for mistune 2.x
On 2/4/22 9:18 PM, Julian Gilbey wrote: Basically, the mistune upstream author has completely messed up on this by making what is essentially a completely different package with superficially similar functionality but the same name. True. [...] _mistune.py within the Debian package, and have nbconvert do "import nbconvert.filters._mistune as mistune" (see /usr/lib/python3/dist-packages/nbconvert/filters/markdown_mistune.py). That seems like an eminently sensible solution to this problem. But that'd lead to a number of mistune's embedded copies in a huge number of packages; since majority of the rev-deps (when I last checked) haven't adapted to this new version. When they do, and it becomes a overhead to fix each one later. Even worse, if we discover a security problem sometime later, then all such packages would be effected, and that honestly does not look like a good idea to me. I somehow do not understand the urgency of uploading this newer version, as the maintainer said: | I intend to upload src:mistune 2.0.0 to unstable between March the | 15th and April the 15th (depending on the progress of its | reverse-dependencies). We could simply wait a little more for the dust to settle, IMHO. Regards, Nilesh OpenPGP_signature Description: OpenPGP digital signature
Re: Please enable me transfering python-bioblend to Debian Med team
Hi Stefano/Ondřej, On 1/11/22 8:03 PM, Andreas Tille wrote: Hi, I think we sorted out that the request to move python-bioblend to Debian Med is valid. I'm CCing Debian Python team maintainers to get this finally done. Could you process this transfer please? Moving python-bioblend from python->med team. You have maintainer access in -med and owner in -python, hence please consider transferring this. Regards, Nilesh OpenPGP_signature Description: OpenPGP digital signature
Re: Transfering packages from Debian Med to DPT (Was: Please enable me transfering python-bioblend to Debian Med team)
Before you/someone else makes a move, some of these packages are bioinformatics and are better suited for med team: * indexed-gzip - This one is mainly for NIFTI image files * python-anndata - For gene annotation * python-fitbit - For FITBIT API (more in med domain) * python-cooler - For genomic interaction data There are probably more, but please do not move these ^^ Nilesh OpenPGP_signature Description: OpenPGP digital signature
Re: Transfering packages from Debian Med to DPT (Was: Please enable me transfering python-bioblend to Debian Med team)
On 12/23/21 1:54 PM, Andreas Tille wrote: Hi again, by chance I learned that I do not have permissions to create repositories in salsa:python-team/packages thus moving packages would be not as simple as transfering the projects. Please grant me maintainer permissions to enable moving packages smoothly. AFAICS here[1] you do have maintainer permissions. [1]: https://salsa.debian.org/groups/python-team/packages/-/group_members?search=tille Regards, Nilesh
Re: Please enable me transfering python-bioblend to Debian Med team
Hi Pierre-Elliot, On Wed, Dec 22, 2021 at 08:06:01PM +0100, Pierre-Elliott Bécue wrote: > >> I'm sorry but pressuring to take over a package is not really fine. If > >> you're not happy with the time it takes for an answer, you can try to > >> fill an ITS and if the procedure goes to its end then you may take over. > > > > Please note: The people involved are the same. We are members of > > both teams but consider the Debian Med team more appropriate. We > > are simply missing the permissions to do the move properly. > > I am aware of that. > > Yet, the fact that you are members of both teams doesn't entitle you to > decide such a transfer, even if you had the technical rights to do so. Hmm, I am not sure what the problem in such a case would be (permission in both teams) Steffen is the maintainer (uploader if you might prefer it that way) and he has agreed already[1] -- so what's the problem? [1]: https://lists.debian.org/debian-med/2021/12/msg00119.html > I therefore stand my point: the way Debian is made has not changed > recently, and taking over still requires a formal approval from the > maintainer, which you are not. > > The only alternatives are either an ITS or MIA team orphaning their > packages, but as the maintainer is an active team, the latter will not > happen. I do not think it is sensible to take consensus from an entire team to move a single package. Honestly speaking, we really do not need to make team transfer debian processes such a high friction ones -- it just stalls the work for no good reason. The package has not seen uploads since more than two years, I really doubt anyone in the team feels strong ly about not moving it. If you are talking about Ondřej doing the uploads apart from the initial uploads, then you probably are also aware that Ondřej does a number of team-maintained package uploads to fix bugs, does updates and so on (a lot of us do so, for that matter albeit in other teams) I really don't think that he has a personal interest in every single one of those packages (including this one) but we should hear from him. > >> and they could be willing to check that no one in the team objects. Sure but how are you making a "check" here? I do have admin access in a few teams, and speaking for myself: I would send out an email to the list, wait for a time frame (maximum 1 week) and check if someone has any comments If not, I would make a move. So we already have a mail in the debian-python mailing list, and no objections so far, so I would have probably done more to ask for consensus better (asking on IRC channels etc) but admittedly, we only have 24 hours in the day, and several dozens of packages to do. > I think you missed the second part of my sentence you're quoting. I recetified this above. > >> Steffen only did the first upload. I'd suggest to contact Ondrej (Cc-ed). > >> > >> In the meantime, Nilesh is member of the Python team and therefore can > >> do an update of the package (but not change the maintainer). > > > > I'm a member myself - but the upload should happen in the Debian > > Med team. This is the point of my mail. > > I disagree. > > Either the python team accepts the package to be transferred and it > indeed should happen there. Please don't repeat your points. You wrote the same stuff above (wrt MIA, ITS etc) > This probably means we should have a stanza in the DPT policy about > transfer of maintainership. This would be definitely helpful. PS: I do not mean to be disrespectful, please do not interpret my reply that way, I am only trying to reason it out. Regards, Nilesh signature.asc Description: PGP signature
Re: [RFH] Bug#1000812: pyrle: import fails on Python 3.10
Hi Stefano, On 12/4/21 9:00 PM, Stefano Rivera wrote: Hi Nilesh (2021.12.04_15:15:05_+) Would you have any hint on this? Is it a bug with the python3 package itself? You're waiting for python3-tabulate to be patched for Python 3.10 support. Indeed. I was just being silly as it seems. I patched tabulate to work with python3.10 (smoke tests go well, and I did a few manual tests) and uploaded. Thanks a lot for your time. Regards, Nilesh OpenPGP_signature Description: OpenPGP digital signature
[RFH] Bug#1000812: pyrle: import fails on Python 3.10
Dear Python team, Would you have any hint on this? Is it a bug with the python3 package itself? Let me know. Regards, Nilesh On Thu, 2 Dec 2021 12:02:59 +0530 Nilesh Patra wrote: > On Mon, 29 Nov 2021 20:35:40 +0100 Andreas Tille wrote: > > Am Mon, Nov 29, 2021 at 11:36:33PM +0530 schrieb Nilesh Patra: > > > I rebuilt with python3.10, and now error is this. > > > Something wrong with pandas? > > > > As far as I understood we need to wait for pandas 1.3 to work > > with Python3.10. > > I retried autopkgtest now, and it still seems a non-bug with pyrle. > @Rebecca, please re-assign this bug to relevant package. > > autopkgtest [11:57:49]: test autodep8-python3: [--- > Testing with python3.10: > Traceback (most recent call last): > File "", line 1, in > File "/usr/lib/python3/dist-packages/pyrle/__init__.py", line 1, in > from pyrle.rle import Rle > File "/usr/lib/python3/dist-packages/pyrle/rle.py", line 13, in > from tabulate import tabulate > File "/usr/lib/python3/dist-packages/tabulate.py", line 16, in > from collections import Iterable > ImportError: cannot import name 'Iterable' from 'collections' > (/usr/lib/python3.10/collections/__init__.py) > > """ > Minimal example to reproduce: > > $ python3.10 > Python 3.10.0+ (default, Nov 17 2021, 06:49:13) [GCC 11.2.0] on linux > Type "help", "copyright", "credits" or "license" for more information. > >>> from tabulate import tabulate > Traceback (most recent call last): > File "", line 1, in > File "/usr/lib/python3/dist-packages/tabulate.py", line 16, in > from collections import Iterable > ImportError: cannot import name 'Iterable' from 'collections' > (/usr/lib/python3.10/collections/__init__.py) > """ > > $ apt policy python3.10 > python3.10: > Installed: 3.10.0-5 > Candidate: 3.10.0-5 > Version table: > *** 3.10.0-5 500 > 500 http://deb.debian.org/debian sid/main amd64 Packages > 100 /var/lib/dpkg/status signature.asc Description: PGP signature
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: Bug#997772: python-cogent: FTBFS: You must configure the bibtex_bibfiles setting
On 11/3/21 1:30 PM, Andreas Tille wrote: Control: tags -1 pending Hi Stuart, Am Wed, Nov 03, 2021 at 09:43:40AM +1100 schrieb Stuart Prescott: Extension error: You must configure the bibtex_bibfiles setting make[2]: *** [Makefile:40: html] Error 2 this is sphinxcontrib-bibtex saying that you need to add the following to doc/conf.py: bibtex_bibfiles = "path/to/references.bib" However I can't see a .bib file anywhere in the source. I also can't see any code in the rst files or the docstrings that would actually use sphinxcontrib- bibtex so I'm not sure how this extension is actually used in these documents. Perhaps it isn't actually needed at all. Thanks for the good hint which helped me over this issue[1]. Unfortunately now dh_auto_install has an issue that did not occured before: [...] Pushed to salsa, and now it works as it should. I leave the onus of checking and uploading onto you. Regards, Nilesh OpenPGP_signature Description: OpenPGP digital signature
Re: platform.machine() on salsa i386 build?
Hi Ole, On 10/30/21 5:50 PM, Ole Streicher wrote: Hi, https://salsa.debian.org/debian-astro-team/pyraf/-/jobs/2130878#L2062 How can one find out the correct machine here? I just committed something to salsa -- sort of a hack, but it works (i386 pipeline passes). I do this for one of my other package as well. Please consider taking a look. Nilesh OpenPGP_signature Description: OpenPGP digital signature
Re: Bug#997758: nose: FTBFS: There is a syntax error in your configuration file: invalid syntax (conf.py, line 220)
(U) Martin A. Brown tldp Martin Pitt cssutils (U) Martin Wimpress python-rx (U) Martin Zobel-Helas python-caldav Mathias Behrle relatorio (U) Mathieu Trudel-Lapierre netplan.io (U) Matthias Geerdsen kopanocore (U) Matthias Klose i8c libi8x Mattia Rizzolo ubuntu-dev-tools (U) Maximiliano Curia python-intbitset Mehdi Abaakouk python-lzo (U) Michael Fladischer celery (U) django-assets (U) django-downloadview (U) django-nose (U) drf-extensions (U) pilkit (U) python-cement (U) python-elasticsearch (U) python-measurement (U) python-pamqp (U) python-sievelib (U) Michael Fladischer python-anyjson (U) Michael Hanke brian (U) mpi4py (U) nibabel (U) nipy (U) python-mne (U) pyxnat (U) scikit-learn (U) seaborn (U) statsmodels (U) Michael Hanke annexremote (U) datalad (U) dcmstack (U) dipy (U) lazyarray (U) neo (U) nitime (U) pynn (U) Michael R. Crusoe python-bx (U) python-pomegranate (U) python-pybedtools (U) python-screed (U) Michael R. Crusoe python-gffutils (U) python-rdflib-jsonld (U) Michael Vogt gdebi (U) python-defer (U) Michal Arbet designate-dashboard (U) kazoo (U) lz4tools (U) manila-ui (U) mistral (U) mistral-dashboard (U) murano (U) openstack-trove (U) pykafka (U) python-fluent-logger (U) python-jsonschema (U) python-kafka (U) python-tooz (U) swift (U) Mihai Moldovan dnf libdnf librepo x2gobroker (U) Mikael Djurfeldt python-csa Mike Gabriel lomiri-url-dispatcher (U) python-rx (U) x2gobroker (U) Miriam Ruiz deap Mo Zhou caffe (U) Muammar El Khatib amp (U) Neil Muller python-formencode (U) Neil Williams kazoo (U) NeuroDebian Team datalad NeuroDebian Team dcmstack imbalanced-learn Nicholas D Steeves elpy (U) Nick Morrott python-project-generator (U) valinor (U) yotta (U) Nicolas CANIART tap.py (U) Nicolas Dandrimont flask-limiter (U) moksha.common (U) piuparts (U) python-fedora (U) python-limits (U) python-pyramid-chameleon (U) Nilesh Patra cyvcf2 (U) h5sparse (U) nitime (U) python-xopen (U) seaborn (U) Nilesh Patra python-spectra (U) umap-learn (U) Noah Meyerhans python-boto (U) Nobuhiro Iwamatsu python-nubia (U) python-spinners Ole Streicher skimage (U) stsci.tools (U) yt (U) Olivier Sallou biomaj3 (U) biomaj3-cli (U) biomaj3-core (U) biomaj3-daemon (U) biomaj3-download (U) biomaj3-process (U) biomaj3-user (U) python-easydev (U) Olof Johansson svtplay-dl Ondřej Kobližek backblaze-b2 (U) python-logfury (U) python-tempita (U) Ondřej Nový backblaze-b2 (U) pytest (U) python-eventlet (U) python-flake8 (U) python-logfury (U) python-maxminddb (U) python-pyeclib (U) python-werkzeug (U) swift (U) swift-bench (U) Ondřej Surý blinker (U) Otto Kekäläinen py-stringmatching (U) Oxan van Leeuwen guessit (U) Paul Belanger python-statsd (U) voluptuous (U) Paul Tagliamonte dput-ng (U) Paulo Roberto Alves de Oliveira (aka kretcheu) rows Peter Pentchev createrepo-c Philipp Huebner yamllint (U) Picca Frédéric-Emmanuel vitables (U) Pino Toscano osinfo-db (U) Piotr Ożarowski aiohttp-mako beaker (U) dh-python pygments python-formencode (U) routes piuparts developers team piuparts Python Applications Packaging Team dodgy muttdown prospector voltron Rebecca N. Palmer libgpuarray (U) statsmodels (U) theano (U) Robbie Harwood (frozencemetery) python-gssapi Robert S. Edmonds voluptuous (U) Ross Gammon gramps Ruben Undheim python-zeroconf (U) Ryan Pavlik click-man Samuel Thibault dogtail Sandro Tosi guessit (U) matplotlib python-cycler Sao I Kuan cwlformat (U) insilicoseq (U) recan (U) Sascha Steinbiss ariba (U) fastaq (U) gfapy (U) gnome-keysign iva (U) Sebastian Heinlein (devel) python-defer Sebastien Badia python-ncclient python-xmltodict Sebastien Delafond hyperspy (U) python-param (U) python-twilio (U) Sergio Durigan Junior check-manifest (U) kitchen (U) pagure python-fedora (U) python-maxminddb (U) Simon Eisenmann kopanocore (U) Simon McVittie tap.py (U) Sophie Brun python-rx (U) python-twilio (U) Stefano Karapetsas trash-cli Stefano Rivera beautifulsoup4 (U) dh-python (U) python-confuse (U) python-flexmock (U) python-launchpadlib python-webencodings (U) ubuntu-dev-tools (U) Steffen Moeller bcbio (U) cyvcf2 (U) mirtop (U) nanosv (U) python-bx (U) python-datacache (U) python-deeptools (U) python-geneimpacts (U) python-gffutils (U) python-gtfparse (U) python-louvain python-pomegranate
Re: Why is isal limited to just three archs?
Hi Thomas, On 10/16/21 4:07 PM, Graham Inggs wrote: Hi, Did you look into the source package? isal is written in assembly language... I see at least an erasure_code/ppc64le directory. I did a quick test build in Ubuntu and the package built and passed its tests on armhf, ppc64el and riscv64, failing only because of missing symbols. Perhaps the reduced libisal2.symbols.arm64 can be used for other architectures as well? After Graham's tests, would it be possible to extend the arch list? I could help test it across more archs if you would like -- porter boxes to rescue :) Nilesh OpenPGP_signature Description: OpenPGP digital signature
Why is isal limited to just three archs?
Hi Ondřej, I see that isal package is limited to amd64, arm64 and kfreebsd-amd64. Is there a particular reason for this? -- Is it possible to extend support to other archs? Actually, a -med team package fastp has started to depend on libisal-dev, and this now is limited to the few archs isal supports. So it would be really nice if isal can build on more archs. Please do let me know. Nilesh OpenPGP_signature Description: OpenPGP digital signature
Re: request to join python-team/packages group on salsa
On 11 October 2021 4:17:48 am IST, Emmanuel Arias wrote: >El dom, 10 de oct. de 2021 a la(s) 17:36, Afif Elghraoui (a...@debian.org) >escribió: >Hi, > >You need to be patient. >that a good exercise to understand the "upload process", also some DD >prefer >use mentors. Hi, Afif is already a DD since some years. @Afif, you might want to ping once on #debian-python IRC. Maybe someone could do it quickly that way. Nilesh -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: RFS: python-mockito/1.2.2-2 -- Spying framework for Python - documentation
On 9/19/21 2:29 PM, Fabrice Bauzac-Stehly wrote: > python-mockito (1.2.2-2) unstable; urgency=medium > . >* Source-only upload. Hi, I do not see these changes in salsa. Still the old changelog. can you push? I'll happily sponsor Cheers, -- Nilesh Patra Debian Developer, Uploading ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ ⢿⡄⠘⠷⠚⠋ nil...@debian.org / nileshpatra.info / tchncs.de ⠈⠳⣄ OpenPGP_signature Description: OpenPGP digital signature
Re: Python style guide checker (formerly called pep8)
Hi Geert, On 12 September 2021 1:53:25 pm IST, Geert Stappers wrote: >Hello Debian-Python, > >In which package is a pep8 code style checker? Is this what you seek? https://tracker.debian.org/pkg/autopep8 Corresponding binary package is python3-autopep8 Nilesh -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: RFS: python-click-log/0.3.2-1 -- Logging integration for Click - Python 3.x
On 6/5/21 8:04 PM, Emmanuel Arias wrote: > Hi, > > I'm not DD, but I send you some review, to gain time: > > * d/changelog says: `Bump debhelper from old 10 to 12.` but actuall> > debhelper-compat version is 13. > * Please use UNRELEASED instead of unstable, that can be confused. Fixed > * What about enable salsa-ci? Enabled > * What about adding an autopkgtest? The test is running during build time.[1] I don't think running the same thing as autopkgtest does a very significant improvement. @Fabrice, more review: * The pristine tar contained .tar.gz.*, it should instead contain .orig.tar.gz for origtargz both for the sake of consistency and for origtargz to run fine * We are in freeze time, and a new version upload unless absolutely necessary isn't appropriate[2]. This package does not seem to have any (RC) bug or affecting any package that a version bump would be desired. Hence, this should be uploaded after bullseye release. Feel free to ping me then, and I'll happily sponsor. Also, please take a look at my commits in salsa. Thanks a lot for your work! [1]: https://salsa.debian.org/python-team/packages/python-click-log/-/blob/master/debian/rules#L13 [2]: https://release.debian.org/testing/freeze_policy.html Nilesh signature.asc Description: OpenPGP digital signature
Re: Bug#985102: RFS: jupyter-packaging/0.7.12-1 [ITP] -- tools to help build and install Jupyter Python packages
Hi, I uploaded the one on salsa. It looked nice to me. I am closing the RFS bug, then. Thanks a lot for your work on this! PS: Next time, please consider to first import, and then commit all your changes systematically - for example, adding autopkgtests, modifying copyright et. al. rather than a huge bulk of changes in "initial commit" Nilesh
Should Binaries provided by python-babel have a "python3-" prefix?
Hi, Currently src:python-babel provides 3 binaries: * python3-babel * python-babel-doc * python-babel-localedata of which python3-babel is the main binary, -babel-doc is for the documentation and -babel-localedata is for storing locale data files used by python3-babel. Should this be renamed to a "python3-" prefix for both binaries? They do not contain any actual code though BTW this also has a RC bug, and I pushed the fix to salsa. If it needs a renaming, it'd be great if someone could upload it to NEW. If not, I'll do a source-only-upload. Please let me know what you think of this. Kind regards Nilesh
Re: Issues when reading mailboxes from alioth-lists.debian.net
Hi,
> Traceback (most recent call last):
> File "./test_mbox.py", line 6, in
>if mbox_file.items() != []:
> File "/usr/lib/python3.8/mailbox.py", line 132, in items
>return list(self.iteritems())
> File "/usr/lib/python3.8/mailbox.py", line 125, in iteritems
>value = self[key]
> File "/usr/lib/python3.8/mailbox.py", line 73, in __getitem__
>return self.get_message(key)
> File "/usr/lib/python3.8/mailbox.py", line 781, in get_message
>msg.set_from(from_line[5:].decode('ascii'))
> UnicodeDecodeError: 'ascii' codec can't decode byte 0xe2 in position 37:
> ordinal not in range(128)
> Exit code: 1
For me the error goes way for me when I change line 781 in
/usr/lib/python3.8/mailbox.py
to:
msg.set_from(from_line[5:].decode('utf-8'))
May be this is a minor feature enhancement since at the moment messages with
unicodes don't seem to be decoded.
Or there's an API change which I'm not aware of.
Either way this should act like a temorary fix for now. Let me know if this
doesn't seem right.
Kinds Regards,
Nilesh
[RFS] djangorestframework-gis
Hi, djangorestframework-gis reports failing tests and has RC bug: #961901 filed against it. I've fixed this, and this builds in a clean chroot with passing tests. My changes have been pushed to the team repo here[1]. (Many thanks to Utkarsh for granting access to this repo \o/) This Needs review and sponsorship. [1]: https://salsa.debian.org/python-team/modules/djangorestframework-gis Regards, Nilesh
Re: Request for joining DPMT
Pardon me, I've read and accept the policy: https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst#maintainership On Sat, 13 Jun 2020 at 15:32, Nilesh Patra wrote: > > > On Sat, 13 Jun 2020 at 15:31, Nilesh Patra wrote: > >> Hi, >> I'm interested in joining DPMT - I fix bugs for debian-python team and >> also help package a few modules. >> I've fixed RC bugs for DPMT packages before: #950050 and #952172 being >> recent ones. >> I also maintain several python packages under the debian med team >> >> I've a couple of more RC bug fixes for DPMT packages ready, and I wish to >> push it directly to the team now. >> Hence, I will be grateful if I'm granted access. >> > > I forgot to mention this: my salsa username is: gi-boi-guest > > Regards >
Re: Request for joining DPMT
On Sat, 13 Jun 2020 at 15:31, Nilesh Patra wrote: > Hi, > I'm interested in joining DPMT - I fix bugs for debian-python team and > also help package a few modules. > I've fixed RC bugs for DPMT packages before: #950050 and #952172 being > recent ones. > I also maintain several python packages under the debian med team > > I've a couple of more RC bug fixes for DPMT packages ready, and I wish to > push it directly to the team now. > Hence, I will be grateful if I'm granted access. > I forgot to mention this: my salsa username is: gi-boi-guest Regards
Request for joining DPMT
Hi, I'm interested in joining DPMT - I fix bugs for debian-python team and also help package a few modules. I've fixed RC bugs for DPMT packages before: #950050 and #952172 being recent ones. I also maintain several python packages under the debian med team I've a couple of more RC bug fixes for DPMT packages ready, and I wish to push it directly to the team now. Hence, I will be grateful if I'm granted access. Kind regards Nilesh
Re: [RFC] python-cobra, python3-sbml5
On Sun, 5 Apr 2020, 15:50 Andreas Tille, wrote: > On Sun, Apr 05, 2020 at 03:40:56PM +0530, Nilesh Patra wrote: > > > > '_libsbml' file which corresponds to libsbml (with python3-sbml5 as a > > > > provide) package. When I dug into looking at libsbml, I noticed that > the > > > > relevant file (libsbml.py) which throws error > > > > is generated with swig-3.0 by the upstream [3] > > > > > > I admit I'm absolutely naive about swig - but if libsbml.py is really > > > autogenerated what about re-generating it with swig-4? > > > > I think there's a miscommunication here. The file in the archive(on doing > > $apt source python3-sbml5) is generated with swig-4 already, while it's > > generated with swig-3 upstream. > > Hence the issue. > > Ahhh, so it is regenerated in the Debian package build process but it > conflicts with other parts of the upstream code? Did I now understood > correctly? > Yep. That's my _suspicion_ though, that the rest of the upstream code isn't compatible with the new version, and there are API changes needed. Hence I sent the mail to confirm if I'm thinking in the right direction. > I wonder if we should exclude this kind of autogenerated code inside > the source tarball since we are repackaging the source anyway to exclude > some files for policy reasons. I'm doing so in other source tarballs > for instance with cython files to be absolutely sure that this code > is regenerated. This would probably not solve the build issue but might > be a good idea in general. What do you think? > It seems like libsbml.py would be needed by the rest of the code. So we can maybe keep the upstream's generated code and not generate it on our own - this however does not seem DFSG compliant. Not really sure what to do here. > Kind regards > > Andreas. > > > > > [1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=955656 > > > > > > > > [2]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=955656#10 > > > > > > > > [3]: > https://salsa.debian.org/med-team/libsbml/-/blob/master/src/bindings/python/libsbml.py?expanded=true=simple > > -- > http://fam-tille.de >
Re: [RFC] python-cobra, python3-sbml5
Hi On Sun, 5 Apr 2020, 11:43 Andreas Tille, wrote: > Hi Nilesh, > > On Sat, Apr 04, 2020 at 06:53:55PM +0530, Nilesh Patra wrote: > > > > >From the logs, in the last message[2] it looks like an import-error for > > '_libsbml' file which corresponds to libsbml (with python3-sbml5 as a > > provide) package. When I dug into looking at libsbml, I noticed that the > > relevant file (libsbml.py) which throws error > > is generated with swig-3.0 by the upstream [3] > > I admit I'm absolutely naive about swig - but if libsbml.py is really > autogenerated what about re-generating it with swig-4? > I think there's a miscommunication here. The file in the archive(on doing $apt source python3-sbml5) is generated with swig-4 already, while it's generated with swig-3 upstream. Hence the issue. > > > [1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=955656 > > > > [2]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=955656#10 > > > > [3]: > > > https://salsa.debian.org/med-team/libsbml/-/blob/master/src/bindings/python/libsbml.py?expanded=true=simple > > > > Thanks and regards > > Nilesh > > -- > http://fam-tille.de >
[RFC] python-cobra, python3-sbml5
Hi, Currently python-cobra FTBFS reported here [1]. >From the logs, in the last message[2] it looks like an import-error for '_libsbml' file which corresponds to libsbml (with python3-sbml5 as a provide) package. When I dug into looking at libsbml, I noticed that the relevant file (libsbml.py) which throws error is generated with swig-3.0 by the upstream [3] While the same file in the apt archive (observed after $apt source python3-sbml5) seems to be generated with swig-4.0, and that's the current swig version in Debian now. When I compared, the one generated with swig 4.0 looks pretty different from the one generated by swig 3.0. I "suspect" that the error is due to the swig version change to 4.0, and corresponding API changes. I would really appreciate if I could have more folks "confirm" that this is the case, and I'm not missing out on anything else. I'll then file a report upstream then, asking for corresponding code changes needed for swig 4.0. [1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=955656 [2]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=955656#10 [3]: https://salsa.debian.org/med-team/libsbml/-/blob/master/src/bindings/python/libsbml.py?expanded=true=simple Thanks and regards Nilesh
Re: [RFS] django-oauth-toolkit
> Are you sure that debian/tests/pkg-python/import-name has the correct value? I guess yes. > What does `cat debian/tests/pkg-python/import-name` show? [debian/master][~/packages/oauth-toolkit/django-oauth-toolkit]$ cat debian/tests/pkg-python/import-name oauth2_provider Seems correct. I'm not really sure what is causing this. > Anyways, thanks for your help, I made some minor tweaks and uploaded it a few hours ago. Thanks a lot for sponsoring the upload, :) Could you as well review my changes for pytds[1] that are done here[2]? That would be great. I'm planning to fix more packages in coming days, :) [1]: https://lists.debian.org/debian-python/2020/03/msg00023.html [2]: https://salsa.debian.org/gi-boi-guest/pytds Thanks and regards, Nilesh
Re: Re: [RFS] django-oauth-toolkit
> just a quick glance at the commits: you do not need to replace autopkgtest-pkg-python with home-grown code, just tell it what to import: > echo oauth2_provider > debian/tests/pkg-python/import-name Thanks, I didn't know about that. However, when I added that in, autopkgtest seems to fail with: Removing autopkgtest-satdep (0) ... autopkgtest [15:10:19]: test autodep8-python3: set -e ; for py in $(py3versions -r 2>/dev/null) ; do cd "$AUTOPKGTEST_TMP" ; echo "Testing with $py:" ; $py -c "import django_oauth_toolkit; print(django_oauth_toolkit)" ; done autopkgtest [15:10:19]: test autodep8-python3: [--- Testing with python3.7: Traceback (most recent call last): File "", line 1, in ModuleNotFoundError: No module named 'django_oauth_toolkit' autopkgtest [15:10:19]: test autodep8-python3: ---] autopkgtest [15:10:20]: test autodep8-python3: - - - - - - - - - - results - - - - - - - - - - autodep8-python3 FAIL non-zero exit status 1 autopkgtest [15:10:20]: summary autodep8-python3 FAIL non-zero exit status 1 The command I used: sudo autopkgtest -B ../*.deb -- schroot unstable-amd64-sbuild Am I missing something here? Need your guidance here. Thanks and regards, Nilesh
[RFS] django-oauth-toolkit
Hi, Currently django-oauth-toolkit FTBFS with python3.8. I have fixed it, and build + autopkgtest pass. My changes have been pushed here [1]. Needs review and sponsorship. [1]: https://salsa.debian.org/gi-boi-guest/django-oauth-toolkit Thanks and regards Nilesh
[RFS] pytds
Hi, Currently pytds FTBFS with python3.8. I have fixed it, and build + autopkgtests pass. It is also lintian-clean. There are however, a few build warnings which I am not sure how to fix: I see a lot of: Setting up python3-roman (2.0.0-3) ... /usr/lib/python3.8/subprocess.py:838: RuntimeWarning: line buffering (buffering=1) isn't supported in binary mode, the default buffer size will be used self.stdin = io.open(p2cwrite, 'wb', bufsize) similar warnings; I didn't find buffer=1 in any of the subprocess/file descriptor based functions, not really sure what is causing this. I also see dh_python related warnings as: W: dh_python3 fs:112: Paths differ: debian/python3-tds/usr/lib/python3.8/dist-packages/.test-cache/rootcert.pem and debian/python3-tds/usr/lib/python3/dist-packages/.test-cache/rootcert.pem ... similar warnings; not sure what is wrong here either. I have fixed rest of the warnings, that pytest reported. My changes have been pushed here[1]. Needs review and sponsorship. [1]: https://salsa.debian.org/gi-boi-guest/pytds Thanks and regards, Nilesh
Re: Help for issues with lazyarray needed
On Thu, 5 Mar 2020, 14:16 Andreas Tille, wrote: > Control: tags -1 pending > > Hi, > > I have updated lazyarray in Git[1] (by moving it to Debian Science > team). The old package was lagging way behind upstream and a Python3 > port is available by upstream so I just create the python3-lazyarray > package fixing the open bugs. > > Unfortunately there is an open issue[2]. Since the latest upstream > commit has only one failure (in contrast to the latest tagges upstream > version which is according to commit logs not really the latest) I > based the source tarball on the latest commit. Unfortunately there > is one remaining issue for Python3.7 and two for Python3.8 > > >dh_auto_test -O--buildsystem=pybuild > I: pybuild base:217: cd > /build/lazyarray-2.10.0+hg20170630.23ccca1/.pybuild/cpython3_3.7_lazyarray/build; > python3.7 -m nose -v test > test.test_lazyarray.test_create_with_int ... ok > ... > == > FAIL: test.test_lazyarray.test__issue4 > -- > Traceback (most recent call last): > File "/usr/lib/python3/dist-packages/nose/case.py", line 197, in runTest > self.test(*self.arg) > File > "/build/lazyarray-2.10.0+hg20170630.23ccca1/.pybuild/cpython3_3.7_lazyarray/build/test/test_lazyarray.py", > line 701, in test__issue4 > assert_equal(b[mask1].shape, partial_shape(mask1, b.shape), > a[mask1].shape) > AssertionError: Tuples differ: (4, 1, 3) != (4,) > > First tuple contains 2 additional elements. > First extra element 1: > 1 > > - (4, 1, 3) > + (4,) : (4, 1, 3) > > -- > Ran 87 tests in 0.027s > > FAILED (failures=1) > I had tried this, I think Passing [:-1] in the mask2 initialisation would fix this. We also need to cast this into a numpy array. > > > I continued manually in the pbuilder chroot to get Python3.8 issues: > > pbuilder-chroot# cd > /build/lazyarray-2.10.0+hg20170630.23ccca1/.pybuild/cpython3_3.8_lazyarray/build; > python3.8 -m nose -v test > ... > == > ERROR: test.support.testresult.get_test_runner_class > -- > Traceback (most recent call last): > File "/usr/lib/python3/dist-packages/nose/case.py", line 197, in runTest > self.test(*self.arg) > TypeError: get_test_runner_class() missing 1 required positional argument: > 'verbosity' > > == > ERROR: test.support.testresult.get_test_runner > -- > Traceback (most recent call last): > File "/usr/lib/python3/dist-packages/nose/case.py", line 197, in runTest > self.test(*self.arg) > TypeError: get_test_runner() missing 2 required positional arguments: > 'stream' and 'verbosity' > > -- > Ran 45 tests in 7.327s > > FAILED (SKIP=1, errors=2) > I'll try this by midnight today. If I can, I'll try a fix for this, and make a MR, or a patch. Would that work? > I somehow suspect that the latter issue is not really hard and I wonder > whether I can get some help from DPMT? > > My current plan is to ignore the test suite errors for the moment, > upload a Python3 enabled package to new queue. Once it has passed new I > will see whether we found some solution for the said issues. If not > I'll file a new RC bug to prevent testing migration. I'd like to do > that means to get the latest version of pynn built to keep on with the > Python3 migration for this package. > > Any help for the remaining issues is welcome. > > Kind regards > > Andreas. > > [1] https://salsa.debian.org/science-team/lazyarray > [2] https://bitbucket.org/apdavison/lazyarray/issues/6/test-failure > > -- > http://fam-tille.de > >
