Bug#1056891: Severity / marking of "uses cython3-legacy" bugs

[stefanor]

Hi Rebecca (2024.01.03_21:27:49_+)
> pandas and statsmodels are currently using cython3-legacy.  I left their
> cython 3.0 bugs open when I made this change, as I do want to actually
> switch them to cython 3.x at some point.
> 
> These bugs have now been raised to RC.  Is this an intentional attempt to
> remove cython3-legacy (which seems unlikely as there is no such bug on
> cython3-legacy itself), or have they been mistaken for packages that still
> depend on plain cython3 but don't build with cython3 3.x (which would be an
> active FTBFS and hence RC)?
> 
> If the second, how should such bugs be marked to make them less confusing?
> Is removing the usertag enough?

I didn't review the bugs when I raised the severity, I just took
everything that was usertagged. Sorry!

I'd suggest lowering the severity again.

You could add a separate usertag for using cython3-legacy, but we
can also see that pretty easily by looking at reverse-depends.

Stefano

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272

Bug#1058096: Processed: Bug#1058096 marked as pending in xonsh

[stefanor]

Hi Debian (2023.12.17_17:48:05_+)

Whoops, that was a typo, I was meaning to close 1057596.

Stefano

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272

Bug#1027213: gavodachs: autopkgtest fail with numpy/1.24.1

[stefanor]

Hi Markus (2023.01.09_10:45:30_+)
> I'd be fine with the patch, as it won't actually break anything that
> hasn't been broken already, but I have already prepared a fix
> in , waiting
> for an upload (delayed because of holidays, I suspect).  So, if
> you have not uploaded yet, I'd prefer that fix to go into the
> archive.  Otherwise, as I said, I'm fine with your patch too, for the
> time being.

Sure, I can apply this patch instead.

Or, you can stage the other patch (that resolves #1027398) in git, and I
can sponsor the upload.

SR

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272

Bug#1026312: Setuptools 65.5.0-1.1 breaks installing Python modules/extensions via meson

[stefanor]

Hi Simon (2022.12.20_18:59:12_+)
> This appears to be a behaviour change in the build system, and I think it's
> triggered by the new setuptools.

It is. The Debian detection in meson doesn't support the newer distutils
that dynamically sources available schema from the sysconfig module.
I'm working on a patch for meson.

The latest setuptools upload made setuptools-bundled distutils override
the system distutils, when installed. Triggering this bug report.

SR

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272

Bug#1022526: python-ssdeep: FTBFS: distutils.errors.DistutilsClassError: command class must subclass Command

[stefanor]

Hi Bo (2022.11.19_05:05:19_+)
> One question:
> If I put the packahe under Debian Python team, should to change
> maintainer to DPT from QA team?

Yes.
And if it's in the Python Team it needs a human maintainer/uploader too.

SR

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272

Bug#1024010: compreffor FTBFS with Python 3.11 as supported version

[stefanor]

Hi Nilesh (2022.11.16_14:22:09_+)
> 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?

Yes: https://docs.python.org/3/whatsnew/3.11.html

> The non-limited API files cellobject.h, classobject.h, code.h,
> context.h, funcobject.h, genobject.h and longintrepr.h have been moved
> to the Include/cpython directory. Moreover, the eval.h header file was
> removed. These files must not be included directly, as they are
> already included in Python.h: Include Files. If they have been
> included directly, consider including Python.h instead. (Contributed
> by Victor Stinner in bpo-35134.)

SR

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272

Bug#1022449: python-maxminddb: diff for NMU version 2.0.3-1.1

[stefanor]

Hi Faidon (2022.11.11_22:25:52_+)
> I don't mind having an NMU, though, whether targeted or for the new
> upstream version itself.

Sure, happy to NMU a new upstream version, too. I'll 0-day NMU that.

I'm afraid this specific bug isn't fixed there, yet, so we still need to
carry a patch. But it'll be in the next release.

I've been working through this class of FTBFS bugs, and this is a rare
case where the upstream has already dealt with the issue... But, not
released yet.

> I have one small request, which would be to push the changes to the
> git repo if you can (it's under the "debian" salsa project).

Done!

Upstream now has a main branch, so you probably want to delete your
master branch.

SR

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272

Bug#1023030: pysha3: Affected by CVE-2022-37454, unmaintained, remove from Debian?

[stefanor]

Hi Salvatore (2022.10.29_12:34:35_+)
> Probably a good idea, if we can have that happen in time for bookworm.
> Will you work on the reverse dependency to make it possible and then
> request the removal for src:pysha3?

Reverse dependency fixed, I'll file for RM now.

SR

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272

Bug#1008810: thrift: FTBFS with Python 3.10

[stefanor]

Hi László (2022.04.03_06:25:52_+)
>  With all due respect, it's a Golang FTBFS and not a Python one.

Thanks. I think there is a Python 3.10 issue entangled in here, but it's
fixed in 0.16.0:

https://github.com/apache/thrift/commit/b724787d373de99feeab0eb2e052f8c8d3ed

SR

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272

Bug#1008402: khmer: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p "3.10 3.9" returned exit code 13

[stefanor]

Hi Andreas (2022.04.03_08:15:43_+)
> Thanks a lot for the patch.  Do you mean by "it isn't complete yet" the
> issue that the build now fails with
> 
>FileNotFoundError: [Errno 2] No such file or directory: ''
> 
> as per Salsa CI[1]?

Exactly. That filename could be special cased (maybe in an except branch
catching ENOENT). But it feels like I've missed something higher-level
that should have avoided it trying to inspect the file more in the first
place.

SR

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272

Bug#1007912: automake-1.16: autopkgtest regression in 1:1.16.5-1.2: AttributeError: module 'sysconfig' has no attribute 'get_default_scheme'

[stefanor]

Hi Simon (2022.03.18_12:52:33_+)

Hrm, not sure how I missed that, thanks.

I'll make something upstreamable.

SR

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272

Bug#1003687: python-pip breaks python-virtualenv autopkgtest: invalid syntax

[stefanor]

Hi Paul (2022.01.13_18:00:41_+)

We have a transition in progress, although not coordinated with you guys.
See #1003573. Once that is done, all the python3 side will work again.

We need to get python2-pip through NEW to get 2.7 virtualenvs working
again. I'll probably mark those tests as skip-not-installable, for now.

SR

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272

Bug#1003396: python3-flexmock: must not ship /usr/lib/python3/dist-packages/docs/conf.py

[stefanor]

Hi Adrian (2022.01.09_14:06:47_+)

Whoops! Good catch, regression in the new upstream that I missed.

SR

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272

Bug#1001799: dh-python: python_version marker parsed incorrectly, adds a dependency that should be skipped

[stefanor]

Hi Luca (2021.12.16_13:15:58_+)

Agreed, this is a regression, thanks.

I meant to explicitly deal with <3, but forgot.

SR

> Package: dh-python
> Version: 5.20211214
> Severity: serious
> Justification: causes FTBFS in reverse deps
> 
> Hi,
> 
> With the following in setup.py's install_requires:
> 
> "pathlib2;python_version<'3.0'",
> 
> dh-python does not skip the line, but tries to find the python3 module
> providing path2lib, which of course does not exist, and thus fails the
> build:
> 
> I: dh_python3 pydist:304: Cannot find package that provides pathlib2.
> Please add package that provides it to Build-Depends or add "pathlib2
> python3-pathlib2" line to debian/py3dist-overrides or add proper
> dependency to Depends by hand and ignore this info.
> Traceback (most recent call last):
>   File "/usr/bin/dh_python3", line 280, in 
> main()
>   File "/usr/bin/dh_python3", line 201, in main
> dependencies.parse(stats, options)
>   File "/usr/share/dh-python/dhpython/depends.py", line 242, in parse
> deps = parse_pydep(self.impl, fn, bdep=self.bdep,
> **section_options)
>   File "/usr/share/dh-python/dhpython/pydist.py", line 496, in
> parse_pydep
> for part in dependency.split(','))
> AttributeError: 'NoneType' object has no attribute 'split'
> make: *** [debian/rules:8: binary] Error 1
> 
> This does not happen on previous versions of dh-python, so I imagine it
> could be a regression from:
> 
> https://salsa.debian.org/python-team/tools/dh-python/-/commit/832f01c9c7da22a1d00887d8ce0e6be9893bdf3e
> 
> Found while rebuilding:
> 
> https://salsa.debian.org/python-team/packages/microsoft-authentication-extensions-for-python/-/jobs/2284212
> 
> As far as I understand the usage of python_version in this format is
> legitimate, and the change causes reverse deps to FTBFS, hence the
> severity. Feel free to downgrade if that's not the case.
> 
> -- 
> Kind regards,
> Luca Boccassi



-- 
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272

Bug#996995: dh-python: Unable to parse debian/control

[stefanor]

Hi Chris (2021.10.22_08:24:04_+)

Thanks for the bug and the patch. I'm going to take a slightly different
approach (and add test coverage).

I thought it was too good to be true when my parsing rewrite passed all
the tests on the first attempt :P

SR

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272

Bug#994265: pypy breaks python-virtualenv autopkgtest on ppc64el: RuntimeError: maximum recursion depth exceeded

[stefanor]

Control: forwarded -1 https://foss.heptapod.net/pypy/pypy/-/issues/3463

Yeah, aware of this issue. I'm going to have to disable the JIT on PPC
until it's fixed upstream, I think.

SR

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272

Bug#991146: python3-libxml2: ambiguous package name 'python3-libxml2' with more than one installed instance

[stefanor]

Hi Thorsten (2021.07.17_17:43:51_+)
> I guess this is rare during normal operation, but we don’t prescribe
> use of apt anywhere and dpkg can indeed trigger it, and this is the
> actually normal case when crossgrading.

Yeah, it's worth fixing, and required for further multi-arch in the
Python stack.

> The fix is really easy, dh_python3 must arch-qualify the py3compile
> (and pypy3compile, I guess) line it inserts if the package is not
> arch:any. For it to become effective, all packages with the code in
> their maintainer scripts need to be rebuilt, which… is probably not
> feasible right now.

Yeah, I think this is 3 steps:
1. Add support for arch-qualified dependencies in the py*compile
   scripts.
2. Generate arch-qualified dependencies (and appropriate versioned
   dependencies on python3.*, for the support in 1) in dh_python3.
3. Re-build arch-dependent packages with the new dh_python3.

That sounds way too big to chase before the freeze, so I think this is a
bookworm problem.

SR

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272

Bug#988998: lava: diff for NMU version 2020.12-4.1

[stefanor]

Hi Antonio (2021.05.24_11:58:22_+)
> The lava upstream tests caught a problem with this patch on buster,
> please cancel the delayed upload.

Cancelled. Great, I missed that. And your upstream PR :)

SR

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272

Bug#973082: confirmed

[stefanor]

Hi Hans-Christoph (2021.02.01_10:27:12_+)
> Do the tests pass with this patch?

Yes.

SR

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272

Bug#961236: re2: FTBFS on 32 bit archs

[stefanor]

Hi Sebastian (2020.05.21_19:53:01_+)
> re2 FTBFS on the 32 bit archs. See
> https://buildd.debian.org/status/fetch.php?pkg=re2&arch=i386&ver=20200501%2Bdfsg-2&stamp=1590088309&raw=0
> for example.

Whoops. I guess I didn't check on the experimental builds...

Thanks for that.

SR


-- 
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272

Bug#937144: Bug#937769: getting python-linecache2/python-traceback2 fixes into testing (FAO traceback2, funcsigs nipype and numba maintainers).

[stefanor]

Hi Thomas (2020.04.21_21:20:16_+)
> > But that still leaves the question of what to do about the dependency of
> > pytest on pypy-funcsigs ? should pypy modules be removed from pytest and
> > it's reverse-dependencies in the same way that regular python2 modules
> > were? how feasible is that? are pypy-* packages only useful with python2
> > pypy or are they also useful with python3 pypy?

Pretty much, yes.

pypy itself (the python 2.7 pypy) will continue to exist for the
foreseeable future, to support building pypy3. But we don't need to ship
modules for it. I'd be pretty happy if we had working virtualenv, and
nothing else.

SR

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272

Bug#950672: hy: diff for NMU version 0.17.0-1.1

[stefanor]

Hi Tianon (2020.02.04_17:18:33_+)
> I'm hoping to get 0.18.0 packaged soon, which (as you mentioned)
> should make this moot, but I don't see any harm in getting a fix in
> sooner (really, feel free to skip DELAYED entirely if you want to get
> this fixed faster).

Thanks, rescheduled to 0.

SR

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272

Bug#866464: Bug #866464 in python-aalib marked as pending

[stefanor]

Control: tag -1 pending

Hello,

Bug #866464 in python-aalib reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below, and you can check the diff of the fix at:

https://salsa.debian.org/python-team/modules/python-aalib/commit/ffb17f03e3e5f1cbb8a6f475df6d316124162fdc


Replace python{3,}-imaging suggests with python{3,}-pil. (Closes: #866464)



(this message was generated automatically)
-- 
Greetings

Bug#889813: Bug #889813 in python-cffi marked as pending

[stefanor]

Control: tag -1 pending

Hello,

Bug #889813 in python-cffi reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below, and you can check the diff of the fix at:

https://salsa.debian.org/python-team/modules/python-cffi/commit/2d4fbfb18a1ddcceceebdfc09ac1a6ee317275f8


Patch: Avoid embedded bootstrapping race in recent python2.7 (Closes: #889813)



(this message was generated automatically)
-- 
Greetings