Aw: Should cocotb & pyuvm be under Electronics or Python team ?

[Steffen Möller]

Hello,

Thank you for your work!

I suggest to direct to electronics about everthing that is tailored for the 
electronics and only have non-electronic-specific dependencies with the Python 
repository.

Best,
Steffen

> Gesendet: Sonntag, 23. Juli 2023 um 01:51 Uhr
> Von: "أحمد المحمودي" 
> An: debian-python@lists.debian.org, 
> pkg-electronics-de...@alioth-lists.debian.net
> Betreff: Should cocotb & pyuvm be under Electronics or Python team ?
>
> Hello, 
> 
>   I am currently working on packages for cocotb & pyuvm, both are Python 
>   packages, that are used for verification (simulation) of VHDL/*Verilog 
>   models, ie. their scope is electronics. Do I am wondering whether to 
>   package them under Electeonics team or Python team.
> 
>   Also, I've set the Section source control field to 'electronics', yet 
>   lintian complained that since the binary package names are 
>   python3-{cocotb/pyuvm}, then the section should be 'python'. Should I 
>   ignore/override that ? Or should I modifybthe Section field to 
>   'python' ?
> 
> Thanks
> 
> 
> -- 
> ‎أحمد المحمودي (Ahmed El-Mahmoudy)
>  Digital design engineer
> GPG KeyIDs: 4096R/A7EF5671 2048R/EDDDA1B7
> GPG Fingerprints:
>  6E2E E4BB 72E2 F417 D066  6ABF 7B30 B496 A7EF 5761
>  8206 A196 2084 7E6D 0DF8  B176 BC19 6A94 EDDD A1B7
>

Re: Should Binaries provided by python-babel have a "python3-" prefix?

[Steffen Möller]

Hi Nilesh,

On 26.11.20 13:16, Nilesh Patra wrote:
> 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.

I propose to have the "3" only for packages that depend on python3. The
source package name, documentation and data package names should not be
versioned.

Best,

Steffen

Re: python-datrie: FTBFS with recent hypothesis version

[Steffen Möller]

Er - accepted, not uploaded.

On 09.01.20 19:45, Michael Crusoe wrote:

[whoops, forgot to CC everyone]

On Mon, 9 Dec 2019 12:14:02 +0100 Matthias Klose mailto:d...@debian.org>> wrote:
> On 09.12.19 11:46, Andreas Tille wrote:
> > Hi,
> >
> > I have upgraded python-datrie in Git[1] to latest upstream version
> > (0.8).  It shows the same issue - so I admit I have no better clue
than
> > reporting the issue upstream which I'd rather leave to the official
> > Uploader of the package.
> >
> > BTW, we probably should expect build issues with Python 3.8[2]
>
>
https://patches.ubuntu.com/p/python-datrie/python-datrie_0.7.1-3ubuntu1.patch


I can confirm that this patch fixes the build and I've opened a merge
request at
https://salsa.debian.org/python-team/modules/python-datrie/merge_requests/1


Can someone with more permissions than I have accept that merge
request and upload the new package?

Thanks and happy new year!

Re: python-datrie: FTBFS with recent hypothesis version

[Steffen Möller]

Done - Steffen.

On 09.01.20 19:45, Michael Crusoe wrote:

[whoops, forgot to CC everyone]

On Mon, 9 Dec 2019 12:14:02 +0100 Matthias Klose mailto:d...@debian.org>> wrote:
> On 09.12.19 11:46, Andreas Tille wrote:
> > Hi,
> >
> > I have upgraded python-datrie in Git[1] to latest upstream version
> > (0.8).  It shows the same issue - so I admit I have no better clue
than
> > reporting the issue upstream which I'd rather leave to the official
> > Uploader of the package.
> >
> > BTW, we probably should expect build issues with Python 3.8[2]
>
>
https://patches.ubuntu.com/p/python-datrie/python-datrie_0.7.1-3ubuntu1.patch


I can confirm that this patch fixes the build and I've opened a merge
request at
https://salsa.debian.org/python-team/modules/python-datrie/merge_requests/1


Can someone with more permissions than I have accept that merge
request and upload the new package?

Thanks and happy new year!

Re: Numpy migration?

[Steffen Möller]

On 06.01.19 17:07, Ole Streicher wrote:

Mattia Rizzolo  writes:


On Sat, Jan 05, 2019 at 08:30:28PM +0100, Ole Streicher wrote:

This would remove one dependent party (release team) from the chain of
blocking causes for the migration.

Given your email on -mentors a few minutes ago I see there are troubles
on removing python-astropy from unstable (I'll reply to that in a bit),
but for testing is quite easy.
Just file a bug against release.debian.org asking to remove it from
testing, and one against python-astropy at RC-level with "not release
with buster", and it will be out of testing beofore you even notice.

The reverse build deps of python-astropy in testing are pyregion and
veusz. Veusz has the build-dep removed in unstable, but didn't migrate
since 192 days.
This is because it does not build on arm64 and others 
(https://buildd.debian.org/status/fetch.php?pkg=veusz=arm64=3.0-1=1530124204=0) 
- also because of some Numpy issue if I get this right:


dpkg-buildpackage
-

dpkg-buildpackage: info: source package veusz
dpkg-buildpackage: info: source version 3.0-1
dpkg-buildpackage: info: source distribution unstable
 dpkg-source --before-build veusz-3.0
dpkg-buildpackage: info: host architecture arm64
 fakeroot debian/rules clean
dh clean --with python3,sphinxdoc --buildsystem=pybuild
   dh_auto_clean -O--buildsystem=pybuild
I: pybuild base:217: python3.7 setup.py clean
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/numpy/core/__init__.py", line 16, in 

from . import multiarray
ImportError: cannot import name 'multiarray' from 'numpy.core' 
(/usr/lib/python3/dist-packages/numpy/core/__init__.py)

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "setup.py", line 31, in 
import numpy
  File "/usr/lib/python3/dist-packages/numpy/__init__.py", line 142, in 
from . import add_newdocs
  File "/usr/lib/python3/dist-packages/numpy/add_newdocs.py", line 13, in 

from numpy.lib import add_newdoc
  File "/usr/lib/python3/dist-packages/numpy/lib/__init__.py", line 8, in 

from .type_check import *
  File "/usr/lib/python3/dist-packages/numpy/lib/type_check.py", line 11, in 

import numpy.core.numeric as _nx
  File "/usr/lib/python3/dist-packages/numpy/core/__init__.py", line 26, in 

raise ImportError(msg)
ImportError:
Importing the multiarray numpy extension module failed.  Most
likely you are trying to import a failed build of numpy.
If you're working with a numpy git repo, try `git clean -xdf` (removes all
files not under version control).  Otherwise reinstall numpy.

Original error was: cannot import name 'multiarray' from 'numpy.core' 
(/usr/lib/python3/dist-packages/numpy/core/__init__.py)

E: pybuild pybuild:336: clean: plugin distutils failed with: exit code=1: 
python3.7 setup.py clean
dh_auto_clean: pybuild --clean -i python{version} -p "3.7 3.6" returned exit 
code 13
debian/rules:22: recipe for target 'clean' failed
make: *** [clean] Error 25
dpkg-buildpackage: error: fakeroot debian/rules clean subprocess returned exit 
status 2

Build finished at 2018-06-27T18:29:58Z

Finished

Re: Matplotlib 3.0 - update ok?

[Steffen Möller]

Let me ask you this: where is the rush to package this machine learning
library? Could it wait after the Buster release cycle, where we might
be in a more comfortable position to upgrade matplotlib?
The short answer is yes. The almost as short one is "Conda has it 
already, use that". The slightly longer answer is that I don't think 
that this is the right thing for Debian to do. We are then shipping an 
old version of matplotlib, i.e. oldstable, with a new release of our 
distribution. I do also think that that long-term support version 2 of 
matplotlib should remain in our distribution. So we would need to find 
a way to support two versions for the same distribution.


Kind of answering myself - I do not see a rush, either. I was just 
positively surprised about Orange and would like many users to share 
that experience with Buster - not two years later.


How deep is the Python Policy wrt package naming set in stone? Wrt to 
the renaming that Andreas suggested - I would be prepared to work 
through renames of matlibtools to matlibtools2 in all those source trees 
that are incompatible with version 3.


Cheers,

Steffen

Re: Matplotlib 3.0 - update ok?

[Steffen Möller]

Hi Ghis,

On 16.10.18 08:30, ghisv...@gmail.com wrote:

On Mon, 2018-10-15 at 22:44 +0200, Steffen Möller wrote:

Hello,

I am keeping me busy packaging the Orange machine learning library
that
seems nice (https://orange.biolab.si/#Orange-Features). Now, the
test
routines demand a matplotlib.pyplot module that is not in version 2
that
we feature. Version 3 is the current stable release.

Ack. Thank you for explaining the context.


Now, I am tempted to create a package matplotlib3 instead of forcing
everyone to update from this long term release (see
https://matplotlib.org/).

Any opinions from your sides?

How is that going to work without creating package conflicts?

I suppose  the main module is still named "matplotlib" not
"matplotlib3" in version 3 onwards? So using python3-matplotlib3 would
be a breach of policy.

Yes. We would need to freely interpret that policy in analogy to Debian
libraries e.g. for C/C++ or Java.

Let me ask you this: where is the rush to package this machine learning
library? Could it wait after the Buster release cycle, where we might
be in a more comfortable position to upgrade matplotlib?


The short answer is yes. The almost as short one is "Conda has it
already, use that". The slightly longer answer is that I don't think
that this is the right thing for Debian to do. We are then shipping an
old version of matplotlib, i.e. oldstable, with a new release of our
distribution. I do also think that that long-term support version 2 of
matplotlib should remain in our distribution. So we would need to find a
way to support two versions for the same distribution.

Cheers,

Steffen

Matplotlib 3.0 - update ok?

[Steffen Möller]

Hello,

I am keeping me busy packaging the Orange machine learning library that 
seems nice (https://orange.biolab.si/#Orange-Features). Now, the test 
routines demand a matplotlib.pyplot module that is not in version 2 that 
we feature. Version 3 is the current stable release.


Now, I am tempted to create a package matplotlib3 instead of forcing 
everyone to update from this long term release (see 
https://matplotlib.org/).


Any opinions from your sides?

Cheers,

Steffen

Re: sponsorship request

[Steffen Möller]

Hello,

On 07/03/16 18:00, Alex Mestiashvili wrote:
> Hello Debian Python folks,
>
> I've prepared the new version of python-bibtexparser [0] and look for a
> sponsor.
>
> Thank you,
> Alex
>
> [0] https://anonscm.debian.org/cgit/python-modules/packages/bibtexparser.git
>
I can just do that.

Cheers,

Steffen