Re: Upload request: psrecord (NEW)

2024-10-25 Thread Peter Wienemann

Hi Alexandru,

On 2024-10-15 18:02:10, Alexandru Mihail wrote:

I'd like to request an upload of the psrecord NEW package
( https://salsa.debian.org/python-team/packages/python-psrecord ) as I
don't have uploading rights. This closes #1075810. It's lintian OK and
the latest upstream version.


thanks for working on this new package. I reviewed your work and have 
the following remarks:


Package name

I saw that you started with psrecord as source package name and tijuca 
suggested to use python-psrecord in [0]. After looking into the package, 
my personal preference is to switch back to psrecord as source package 
name since in my view the main task of the package is to provide a 
psrecord executable and I consider the fact that it is written in Python 
an implementation detail. This is basically the situation mentioned by 
stefanor in [1]. Therefore my proposal is to use psrecord for both the 
source and the binary package name.


I understand that this is an unfortunate situation for you since one 
person suggests to do A and another person suggests to do B. Therefore I 
propose to wait a bit and see what other people think about this. More 
opinions are much appreciated - in particular in view of recent 
discussions about namespacing Python packages.


Packaging details
=

branch layout
-
The team policy specifies branch name conventions [2]. According to this 
policy the branch containing the upstream source should be called 
"upstream". Actually used is "upstream/latest" (also note that the 
presently used upstream branch does not match the branch specified in 
d/gbp.conf).


d/control
-
a) The present code fails to build in a clean build environment because 
the following build dependencies are missing:

- python3-psutil
- help2man

b) The "Provides" field should be removed (cf. [3]).

d/rules
---
a) The override_dh_auto_build target is unnecessary and can be removed.

b) The "ifeq ($(filter nodoc,$(DEB_BUILD_PROFILES)),)" block is empty 
and can thus be removed.


c) When using the package clean-up validation as described on [4], I get 
the following diff


1c1
< /<> directory 300
---
> /<> directory 320
31a32
> /<>/psrecord.egg-info directory 40

Fixing this requires replacing

rm -rf psrecord.egg-info/SOURCES.txt

by

rm -rf psrecord.egg-info

in the override_dh_auto_clean target.

d) execute_before_dh_installman target:
This assumes that the package being built is installed in the build 
environment (uses /usr/bin/psrecord). What would work is using 
"$(CURDIR)/debian/psrecord/usr/bin/psrecord" instead. But this requires 
PYTHONPATH to be set properly, e. g. by adding


export PYTHONPATH=$(shell pybuild --print build_dir -i python3)

It is also nicer and less error-prone to avoid a hardcoded version in 
the help2man call. You can set it at runtime, e. g. by adding


VERSION=$(shell dpkg-parsechangelog -S version)

and use the VERSION variable in the help2man version string.

e) If you generate the manpage during the build, it is better to remove 
the static version from d/psrecord.1. Otherwise potential future changes 
between the provided and the generated version will again result in 
package clean-up validation issues.


d/copyright
---
a) According to [5], the Upstream-Contact "[m]ay be free-form text, but 
by convention will usually be written as a list of RFC5322 addresses or 
URIs." Following this convention means using


Upstream-Contact: Thomas Robitaille 

(note the angle brackets).

b) I see slight deviations from the upstream license file for the 
"Files: *" stanza. It should be:


Copyright: 2013, Thomas P. Robitaille

In the "License: BSD-2-clause" stanza, the "All rights reserved." line 
is missing.


c) There is no "Files: debian/*" stanza.

[0] https://lists.debian.org/debian-python/2024/08/msg00049.html
[1] https://lists.debian.org/debian-python/2024/10/msg00093.html
[2] 
https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst#branch-names
[3] 
https://www.debian.org/doc/debian-policy/ch-relationships.html#virtual-packages-provides

[4] https://wiki.debian.org/sbuild#Validate_package_cleanup
[5] https://www.debian.org/doc/packaging-manuals/copyright-format/1.0


Also, to anyone with admin powers, please nuke
https://salsa.debian.org/python-team/packages/psrecord as this was
migrated to the new location following discussions about naming
conventions. it's empty.


I cannot help with this part. But in view of the open discussion about 
the package name, it might be prudent to wait until this issue has been 
settled.


If you have questions concerning anything mentioned above, do not 
hesitate to ask.


Best regards,

Peter



python-pyinstaller: package naming questions

2024-10-25 Thread Soren Stoutner
I am in the process of packaging python-pyinstaller.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1084906

Currently my source package is named python-pyinstaller.  It produces two 
binary 
packages:

pyinstaller - installs executables to /usr/bin
python3-pyinstaller - installs Python modules to /usr/lib/python3/dist-packages

I have been following the discussion about package names and have started to 
wonder if 
pyinstaller wouldn’t be a better source package name.  That is what it is 
called upstream, 
and the “py” prefix already indicates it is related to Python.

Beyond that, I was wondering if it wouldn’t be better to only provide one 
binary file.  I don’t 
know if there is any value to the Python modules without the executables in 
/usr/bin.  Is 
there any policy or best practice that says this should be split into two 
binary packages?

Soren

P.S.  I figured I would ask now as it is easy to make changes before the first 
upload.

-- 
Soren Stoutner
so...@debian.org 


signature.asc
Description: This is a digitally signed message part.