Re: Help with Lintian error in python3 (pybind11-wrapped) package

2023-07-10 Thread José Luis Blanco-Claraco
Thanks a lot, Andrey, for the time analyzing the problems here, and
for the clarifications. I thought libpython was like "libc" for
python...

So the main issue seems to be dh_python3 not recognizing the package
as "python"...
I attach the list of files and directories of the latest package
version just in case it's easy to spot problems from it (the
"__pycache__" are there for a test Ubuntu build, but are not in the
Debian build).

Note that I want to ship:
- A cpython .so module + its .pyi stubs.
- The corresponding py.typed file, which I understand is
recommended/mandatory when shipping .pyi stubs.
- Pure python scripts (right now, only "ros_bridge.py").

At present, I put everything under
"/usr/lib/python3/dist-packages/mrpt/" so everything is together, not
"polluting" the "dist-packages" directory.
Maybe the package should be named "python3-mrpt" instead?

Any way to test dh_python3 manually? Perhaps just build the package
locally and run dh_python3 from the pkg root directory?

Best,
JL

On Mon, Jul 10, 2023 at 2:58 PM Andrey Rakhmatullin  wrote:
>
> On Mon, Jul 10, 2023 at 11:22:05AM +0200, José Luis Blanco-Claraco wrote:
> > On Mon, Jul 10, 2023 at 11:09 AM Andrey Rakhmatullin  wrote:
> > > No, as it says "phyton3".
> > > (I would also expect that using appropriate substvars here is better than
> > > writing deps manually)
> >
> > I know, and added ${python3:Depends} and ${shlibs:Depends}, but
> > "dh-python" seems not to add any substvars, and "shlibs" does neither.
> shlibs:Depends is indeed irrelevant here.
> python3:Depends being empty is a problem that needs to be fixed. I've
> built the package and it lacks postinst/prerm so I guess dh_python3 didn't
> find any modules in the package. I also see that the package is named
> python3-pymrpt while the top-level module is named myrpt, though I don't
> know if this can cause any problems beside the autopkgtest not working.
>
> > In fact, the "so" module built from the pybind11 wrapper seems not to
> > list any python library in "ldd", which also puzzled me:
> >
> > ldd mrpt/pymrpt.cpython-310-x86_64-linux-gnu.so  | grep py
> >   libsnappy.so.1 => /lib/x86_64-linux-gnu/libsnappy.so.1 
> > (0x7facb732d000)
> Python extensions indeed don't need to link libpython, which is (mostly?)
> for embedding the interpreter, as extensions are loaded into an
> interpreter themselves.
>
> > I checked that other "*cpython.so" modules out there indeed list
> > "libpython3.xxx.so" in their "ldd".
> (I've checked two random extensiopns and they don't)
>
> > I understand this is what is preventing "shlibs" to automatically list
> > python3 as a substvar, but don't know how to fix it.
> It's not, and shlibs:Depends won't list python3 anyway.
>


-- 

/**
 * Jose Luis Blanco-Claraco
 * Universidad de Almería - Departamento de Ingeniería
 * [Homepage]( https://w3.ual.es/~jlblanco/ )
 * [GH profile]( https://github.com/jlblancoc )
 */
python3-pymrpt_2.10.1~20230709-1304-git-1ea114bb~lunar-1_amd64.deb
--

 new Debian package, version 2.0.
 size 5599708 bytes: control archive=2659 bytes.
2601 bytes,17 lines  control  
6102 bytes,64 lines  md5sums  
 Package: python3-pymrpt
 Source: mrpt
 Version: 1:2.10.1~20230709-1304-git-1ea114bb~lunar-1
 Architecture: amd64
 Maintainer: Jose Luis Blanco Claraco 
 Installed-Size: 28338
 Depends: libc6 (>= 2.34), libgcc-s1 (>= 3.3.1), libmrpt-apps2.9 (>= 
1:2.10.1~20230709-1304-git-1ea114bb~lunar), libmrpt-bayes2.9 (>= 
1:2.10.1~20230709-1304-git-1ea114bb~lunar), libmrpt-comms2.9 (>= 
1:2.10.1~20230709-1304-git-1ea114bb~lunar), libmrpt-config2.9 (>= 
1:2.10.1~20230709-1304-git-1ea114bb~lunar), libmrpt-containers2.9 (>= 
1:2.10.1~20230709-1304-git-1ea114bb~lunar), libmrpt-core2.9 (>= 
1:2.10.1~20230709-1304-git-1ea114bb~lunar), libmrpt-expr2.9 (>= 
1:2.10.1~20230709-1304-git-1ea114bb~lunar), libmrpt-graphs2.9 (>= 
1:2.10.1~20230709-1304-git-1ea114bb~lunar), libmrpt-gui2.9 (>= 
1:2.10.1~20230709-1304-git-1ea114bb~lunar), libmrpt-hwdrivers2.9 (>= 
1:2.10.1~20230709-1304-git-1ea114bb~lunar), libmrpt-img2.9 (>= 
1:2.10.1~20230709-1304-git-1ea114bb~lunar), libmrpt-io2.9 (>= 
1:2.10.1~20230709-1304-git-1ea114bb~lunar), libmrpt-kinematics2.9 (>= 
1:2.10.1~20230709-1304-git-1ea114bb~lunar), libmrpt-maps2.9 (>= 
1:2.10.1~20230709-1304-git-1ea114bb~lunar), libmrpt-math2.9 (>= 
1:2.10.1~20230709-1304-git-1ea114bb~lunar), libmrpt-nanogui2.9 (>= 
1:2.10.1~20230709-1304-git-1ea114bb~lunar), libmrpt-nav2.9 (>= 
1:2.10.1~20230709-1304-git-1ea114bb~lunar), li

Re: Help with Lintian error in python3 (pybind11-wrapped) package

2023-07-10 Thread José Luis Blanco-Claraco
On Mon, Jul 10, 2023 at 11:09 AM Andrey Rakhmatullin  wrote:
> No, as it says "phyton3".
> (I would also expect that using appropriate substvars here is better than
> writing deps manually)

I know, and added ${python3:Depends} and ${shlibs:Depends}, but
"dh-python" seems not to add any substvars, and "shlibs" does neither.

In fact, the "so" module built from the pybind11 wrapper seems not to
list any python library in "ldd", which also puzzled me:

ldd mrpt/pymrpt.cpython-310-x86_64-linux-gnu.so  | grep py
  libsnappy.so.1 => /lib/x86_64-linux-gnu/libsnappy.so.1 (0x7facb732d000)

but the module loads perfectly from python3 scripts/interpreter, etc.
I checked that other "*cpython.so" modules out there indeed list
"libpython3.xxx.so" in their "ldd".
I understand this is what is preventing "shlibs" to automatically list
python3 as a substvar, but don't know how to fix it.

This is my first python3 package, so I don't feel confident about how
things should work.
Neither found an equivalent pybind11-based wrapper packaged in Debian
for reference, so any further pointers would be appreciated!.

JL

-- 

/**
 * Jose Luis Blanco-Claraco
 * Universidad de Almería - Departamento de Ingeniería
 * [Homepage]( https://w3.ual.es/~jlblanco/ )
 * [GH profile]( https://github.com/jlblancoc )
 */



Re: Help with Lintian error in python3 (pybind11-wrapped) package

2023-07-10 Thread José Luis Blanco-Claraco
On Mon, Jul 10, 2023 at 11:02 AM gregor herrmann  wrote:
> phyton3 != python3
> :)

hahaha, I knew more eyeballs would be helpful!

Thanks a lot, Gregor, that solves the mystery :-)



Re: Doubt on debian/changelog version history

2021-04-26 Thread José Luis Blanco-Claraco
Thanks, Ansgar, Tobias, for the valuable feedback!

JL



Doubt on debian/changelog version history

2021-04-25 Thread José Luis Blanco-Claraco
Hi dear mentors!

I'm the upstream author and Debian maintainer of a package, and after
uploading a couple of versions to different releases (unstable and
experimental), now I'm unsure about what should be the *order* of the
different changelog entries in a forthcoming release to experimental,
I'm sure you'll be able to quickly solve my doubt.

Here is the order of events (from [1]):

[2021-01-03] Accepted mrpt 1:2.1.7-1 (source) into unstable
(New release, unstacle is frozen, so upload to experimental)
[2021-03-31] Accepted mrpt 1:2.2.0-1 (source amd64 all) into experimental
(Then we had to upload a patch to solve a serious bug in 2.1.7-1):
[2021-04-13] Accepted mrpt 1:2.1.7-2 (source) into unstable
Next, I want to release 2.3.0, into (I guess) experimental.

If I reflect the order of events above in debian/changelog, it would read:
mrpt (1:2.3.0-1) experimental; urgency=medium
...
mrpt (1:2.1.7-2) unstable; urgency=medium
...
mrpt (1:2.2.0-1) experimental; urgency=medium
...
mrpt (1:2.1.8-1) unstable; urgency=medium
...
mrpt (1:2.1.7-1) unstable; urgency=medium
...
mrpt (1:2.1.6-1) unstable; urgency=medium
...

Is it ok to have non-consecutive versions in the changelog? If not:
what's the correct way to handle it?

Extra question: How is a port from experimental to unstable supposed
to happen? Making a new upload with a new changelog entry?

Thanks!

[1] https://tracker.debian.org/pkg/mrpt

-- 

/**
 * Jose Luis Blanco-Claraco
 * Universidad de Almería - Departamento de Ingeniería
 * [Homepage]( https://w3.ual.es/~jlblanco/ )
 * [GH profile]( https://github.com/jlblancoc )
 */