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
< /<<PKGBUILDDIR>> directory 300
---

/<<PKGBUILDDIR>> directory 320

31a32

/<<PKGBUILDDIR>>/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

On Saturday, October 26, 2024 7:26:48 AM EDT Alexandru Mihail wrote:

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.

Yes, indeed after first reading DPT conventions, I also concluded the
best source/binary pkg name combo would be plain psrecord. I'll wait a
bit more, suggestions are very much welcome. If nothing relevant
happens in the meantime (both in this thread or more general
discussions) I will move the whole repo again to salsa/dpt/psrecord.
This little tool is quite useful and I'd hate for it to be stuck in
limbo for too long.

Some additional background on this:

In the before times, what is now the Debian Python Team was two teams:

Debian Python Modules Team (DPMT)
Python Applications Packaging Team (PAPT).

DPMT packaged Python modules and extensions and the binary package naming
rules (that are at least informally extended to source package names now) applied.

PAPT packaged applications written in Python and these naming rules did not apply.

Part of the reason why they were separate is that there are some things about packaging applications that are different. This is one of them. It is an unfortunate side effect of the team's merger that this distinction has been somewhat lost.

From reading this thread, it seems like psrecord is an application written in Python. Upstream could, if they felt like it, re-implement the whole thing in Rust and it would still be psrecord. Assuming that's at least generally correct, I think psrecord is definitely the correct package name.

The only exception is that applications which provide a publically available module/ extension that other programs can use should provide a binary which uses the python3-foo naming convention (see spf-engine as an example). It is
a matter of taste and judgement for small applications that provide a public module/extension should ship the application in a separate binary package or not. Generally, tiny packages are bad because they require more overhead, including making the packages file bigger for every single user.

It would be good if you would review the existing DPT documentation (particularly the policy) with this in mind and see if you have suggestions to make it clearer.

Scott K
-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEE53Kb/76FQA/u7iOxeNfe+5rVmvEFAmcdBAIACgkQeNfe+5rV mvHoJg//XNm9Usqlgwe04WphnnoJilQr0v/cKp/ia+PYrUq52UkPIxgxooLbFphj f0GpdmLIc/ei+rAxgH1xPHn4BB/prSeek0PF082FsA589gmZqKCGFXkH4aElOVoD cd8eKJ+tSx5peE4OHj6wzOdweebFbML7vGEzkA+6DoehHuQo3bXF+h5847+s6pZH vAJKvLeABZHxHt0d0NG805XPLpm/KaZhfYe1/esTvUdTRX3xOtQtffnAjRS6yPyH j2AKh4IjbKOLpM946Op0gU1jp/2jGSGw+aYnmzfcaz8lULXl8IhXj7hBr70vxtXC /AimntUjGPIaaHwoYvg/mPssPqA1qNGmdMns3QLTK+D9Yim6D93LGJ++4DIZrENS BuyxQFA+9560X1ziomZkOy6gBj567FpjK/0diH8rprUpg74bEHr4Ifp8R+g7PPm4 o+VesdwNlIU25GKDlybXuMU7jjY5ot2QSqSkxshWWw1JiRalwh9gG7PHAaChYUcB fEJcud72Uq727C5KkwnMWIELVPdEBIB++WtuwUEJiW7PBlKsDWRd1Y4DBhhLkebn CevkwpTiK4VyqHJ2f7GK+v4tm2lcFxJycT41Lfe8lhVzXBMyQWuAkHxICtRPXsXx Yw8Gcm5fcSStdN3NmN9p+NswrtqNxYU8a+6ZGIhsRD7SofMLrg4=
=/hF/
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Alexandru,

On 2024-10-24 21:30:48, Peter Wienemann wrote:

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]).

I forgot one more item in the above list:

c) To be able to use the --plot option, python3-matplotlib is needed.
Therefore you should add a corresponding Recommends or Suggests field
(cf. [0]) to the binary package.

Best regards

Peter

[0] https://www.debian.org/doc/debian-policy/ch-relationships.html#binary-dependencies-depends-recommends-suggests-enhances-pre-depends

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Scott,

On 2024-10-26 17:00:18, Scott Kitterman wrote:

From reading this thread, it seems like psrecord is an application written in Python. Upstream could, if they felt like it, re-implement the whole thing in
Rust and it would still be psrecord. Assuming that's at least generally correct, I think psrecord is definitely the correct package name.

yes, I think this applies to psrecord.

The only exception is that applications which provide a publically available module/ extension that other programs can use should provide a binary which uses the python3-foo naming convention (see spf-engine as an example). It is a matter of taste and judgement for small applications that provide a public module/extension should ship the application in a separate binary package or not. Generally, tiny packages are bad because they require more overhead, including making the packages file bigger for every single user.

In addition psrecord provides a public module (as per [0]) but I am
inclined to consider this one of the "small application" cases which do
not warrant a separate binary package.

Best regards,

Peter

[0] https://peps.python.org/pep-0008/#public-and-internal-interfaces

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Scott,

On 2024-10-27 20:12:28, Peter Wienemann wrote:

On 2024-10-26 17:00:18, Scott Kitterman wrote:

From reading this thread, it seems like psrecord is an application
written in Python.  Upstream could, if they felt like it, re-implement
the whole thing in
Rust and it would still be psrecord.  Assuming that's at least generally
correct, I think psrecord is definitely the correct package name.

yes, I think this applies to psrecord.

The only exception is that applications which provide a publically
available
module/ extension that other programs can use should provide a binary
which
uses the python3-foo naming convention (see spf-engine as an
example).  It is
a matter of taste and judgement for small applications that provide a
public
module/extension should ship the application in a separate binary
package or
not.  Generally, tiny packages are bad because they require more
overhead,
including making the packages file bigger for every single user.

In addition psrecord provides a public module (as per [0]) but I am
inclined to consider this one of the "small application" cases which do
not warrant a separate binary package.

re-reading your message, I think I got it wrong in my above reply. Sorry
for the confusion. I am trying to summarize to clarify the situation:

Since psrecord ships both an executable and a public module (and it is
small), the suggested package names are:

- psrecord as source package name
- python3-psrecord as binary package name (shipping executable and module)

Alternative (but not recommended due to the smallness):

- psrecord as source package name
- python3-psrecord as binary package name (shipping the module)
- psrecord as additional binary package name (shipping the executable).

Is choosing psrecord as source package name still advisable in the above
cases? Or is python-psrecord as source package name better for the executable+module case?

Best regards

Peter

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On October 27, 2024 9:04:41 PM UTC, Peter Wienemann <[email protected]> wrote: >Hi Scott,

On 2024-10-27 20:12:28, Peter Wienemann wrote:

On 2024-10-26 17:00:18, Scott Kitterman wrote:

From reading this thread, it seems like psrecord is an application written in Python.  Upstream could, if they felt like it, re-implement the whole thing in
Rust and it would still be psrecord.  Assuming that's at least generally >>> correct, I think psrecord is definitely the correct package name.

yes, I think this applies to psrecord.

The only exception is that applications which provide a publically available
module/ extension that other programs can use should provide a binary which >>> uses the python3-foo naming convention (see spf-engine as an example).  It is
a matter of taste and judgement for small applications that provide a public
module/extension should ship the application in a separate binary package or
not.  Generally, tiny packages are bad because they require more overhead, >>> including making the packages file bigger for every single user.

In addition psrecord provides a public module (as per [0]) but I am inclined to consider this one of the "small application" cases which do not warrant a separate binary package.

re-reading your message, I think I got it wrong in my above reply. Sorry for the confusion. I am trying to summarize to clarify the situation:

Since psrecord ships both an executable and a public module (and it is small), the suggested package names are:

- psrecord as source package name
- python3-psrecord as binary package name (shipping executable and module)

Alternative (but not recommended due to the smallness):

- psrecord as source package name
- python3-psrecord as binary package name (shipping the module)
- psrecord as additional binary package name (shipping the executable).

Is choosing psrecord as source package name still advisable in the above cases? Or is python-psrecord as source package name better for the executable+module case?

I think this is fine:

- psrecord as source package name
- python3-psrecord as binary package name

You can also have

Provides: psrecord

Then apt install psrecord will work.

Scott K

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Alexandru,

On 2024-11-10 19:23:29, Alexandru Mihail wrote:

d/control

Done

at present both the source package and the binary package are called "psrecord". Looking at [0] my understanding is that the recent package
name discussion concluded with

source package name: psrecord
binary package name: python3-psrecord

Please correct me if I overlooked something.

Somewhat related: I still feel uncertain what is the best matching
section for this package: "devel", "utils" or "python" (cf. [1])? I
leave the decision to you.

[0] https://lists.debian.org/debian-python/2024/10/msg00104.html
[1] https://packages.debian.org/unstable/

d/copyright
-----------

Done

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

I reread the BSD license, and what other packages have in copyright.. I
can't find the line you're talking about, could you tell me where the
line should be ?

I am referring to this line:

https://salsa.debian.org/python-team/packages/psrecord/-/blob/471390a544f149afcaa20cf1cad5c9f92c95c744/LICENSE#L2

I feel I'm getting close to upload ready for this, any extra comments
from anyone would be welcome ! If nothing else comes up, I'm going
forward and requesting an upload from anyone who has the time to do so.

Trying to build the package using the present repository contents, I get
a build failure:

$ gbp buildpackage
[...]
gbp:error: Cannot find pristine tar commit for archive 'psrecord_1.4.orig.tar.gz'
$ pristine-tar list
python-psrecord_1.4.orig.tar.gz

(BTW, I'm stuck with the main [default] branch on the psrecord repo, I
still can't figure out how to unprotect it and delete ( I think someone
with admin powers has to do that, it's been discussed here before )

I changed the default branch to "debian/master" and protected it. I
guess you should be able to delete the "main" branch now.

Best regards,

Peter

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Thanks for this! psrecord sounds really similar to our https://github.com/con/duct which we recently also uploaded to Debian
(it is that popular topic I guess ;) ). https://packages.debian.org/sid/con-duct .

psrecord though is much more mature -- seems have been there for a
decade so must have more users.

Cheers!

On Tue, 15 Oct 2024, Alexandru Mihail wrote:

Hello,

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.
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.

Have a great one,

Alexandru Mihail

--
Yaroslav O. Halchenko
Center for Open Neuroscience http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
WWW: http://www.linkedin.com/in/yarik

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Alexandru,

On 2024-11-23 22:20:16, Alexandru Mihail wrote:

After implementing welcomed suggestions from people who replied to this thread (thanks Peter et al) I think this package is ready for upload
(or further review if you find anything wrong, of course). It's lintian
clean and you can find it on salsa here: https://salsa.debian.org/python-team/packages/psrecord

it seems that you forgot to push your changes to salsa. The newest
commit I see in the above repository is from November 10, 2024, i. e. it
is older than my last comments (see [0]).

Best regards

Peter

[0] https://lists.debian.org/debian-python/2024/11/msg00014.html

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Alexandru,

On 2024-11-24 23:31:22, Alexandru Mihail wrote:

I implemented the last things you pointed out (I chose utils for the
section of psrecord as I see it fits its use the most).

the build failure mentioned in [0] still persists. I also noticed that
the upstream branch contains commits which are out of place in this branch.

[0] https://lists.debian.org/debian-python/2024/11/msg00014.html

As of you protecting debian/master I can no longer directly push to
this branch. I have the developer role and only Maintainer+Owner roles
can directly push to protected. For now, I've created a merge request
which you can push to master: https://salsa.debian.org/python-team/packages/psrecord/-/merge_requests/1
but for the future, I either need to acquire Maintainer role or I'll
have to keep crafting merge requests for other members to approve,
which seems a bit time consuming :)

The following question is directed to the Python team:

What is the usual way to handle this situation? Grant uploaders the
maintainer role for their projects?

Best regards

Peter

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Alexandru,

On 2024-11-27 20:41:33, Peter Wienemann wrote:

On 2024-11-24 23:31:22, Alexandru Mihail wrote:

As of you protecting debian/master I can no longer directly push to
this branch. I have the developer role and only Maintainer+Owner roles
can directly push to protected. For now, I've created a merge request
which you can push to master:
https://salsa.debian.org/python-team/packages/psrecord/-/merge_requests/1
but for the future, I either need to acquire Maintainer role or I'll
have to keep crafting merge requests for other members to approve,
which seems a bit time consuming :)

The following question is directed to the Python team:

What is the usual way to handle this situation? Grant uploaders the maintainer role for their projects?

to move forward I just granted you the maintainer role for the project "psrecord". In case this does not match the intended permission model of
the team, we can still adapt the settings.

Feel free to ping me when you think the package is ready for upload.

Best regards

Peter

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Alexandru,

On 2024-11-30 14:00:19, Alexandru Mihail wrote:

Yes, there were some rogue commits in [upstream], I reimported upstream tar.gz and redone the whole process, it seems to build fine for me now
in an empty sbuild.
Seems fine now, thanks for the time; upload when you think OK.

I still see contents in the "upstream" branch which does not belong
there, namely the "debian" directory containing your packaging files.

How do you manage the "upstream" and the "pristine-tar" branches? Those branches are somewhat special. There is usually no reason to touch those branches by hand. If you use "gbp import-orig", it takes care of those
branches for you (see "man gbp import-orig"). It also automatically
creates an upstream release tag for you (I do not see any in your
repository).

An initial upstream code import could look like this:

$ mkdir psrecord && cd $_
$ git init
$ gbp import-orig --debian-branch=debian/master https://github.com/astrofrog/psrecord/archive/refs/tags/v1.4.tar.gz

This results in:

$ git branch
* debian/master
pristine-tar
upstream

$ git tag
upstream/1.4

The work on packaging the upstream code happens in the "debian"
directory which must only be committed to the "debian/master" branch. Neglecting more complicated cases (uploads to distributions different
from "unstable", handling patches, etc.) you always commit to the "debian/master" branch. The next commits to the "pristine-tar" and the "upstream" branches are added when you run "gbp import-orig" the next
time to import a new upstream release. Again those commits to
"pristine-tar" and "upstream" (and a new upstream release tag) are
handled by "gbp import-orig". Importing new upstream releases can be
done e. g. by running

$ gbp import-orig --uscan

provided you have a correctly set up gbp.conf and watch file.

I hope this clarifies the gbp workflow a bit. Sorry for not providing
more in-depth information in my previous comments.

Best regards

Peter

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Alexandru,

On 2024-12-06 17:13:18, Alexandru Mihail wrote:

Pinging about (upload) my last mail, I cleaned up upstream mess on
psrecord now and I think it's ready for upload. Would really appreciate
your scrutiny one last time.

I am mostly happy now. There are two issues left:

1. The generated man page is not cleaned up. As a result the package
clean-up validation (see [0]) fails:

----------------------------------------------------------------------
diff /tmp/file-list.pre-build /tmp/file-list.post-build -------------------------------------------------------

17c17
< /<<PKGBUILDDIR>>/debian directory 220
---

/<<PKGBUILDDIR>>/debian directory 240

21a22

/<<PKGBUILDDIR>>/debian/psrecord.1 regular file 1427

fbcd91b4cb61d6616892a323e65daee05a54131e6177ae5b81da9ee4276722a6 ----------------------------------------------------------------------

Adding a line

rm -f debian/psrecord.1

to the override_dh_auto_clean target in debian/rules should fix this.

2. The timestamp of the changelog entry is older than the most recent
commit (excluding commits that modify the changelog file).

Bonus item (optional):
In my opinion the legibility of debian/rules files is increased by
adding empty lines between the various targets.

The same also applies to the license text in debian/copyright (cf. lines
3 and 6 of the upstream LICENSE file [1]). Please note that "empty"
lines in the "License" fields of debian/copyright files are denoted by a
dot (".") in the second column.

Best regards

Peter

[0] https://wiki.debian.org/sbuild#Validate_package_cleanup
[1]
https://github.com/astrofrog/psr

Hi,

d/clean would work just as well, that's exactly what I tend to use if I have more than a few files that I have to specify manually to be cleaned. And personally, I'd recommend to use execute_after_dh_auto_clean than override_dh_auto_clean so that it
doesn't override anything it was previously doing, just in case.

Best,
Ananthu

On 8 December 2024 3:50:39 pm UTC, "Hilmar Preuße" <[email protected]> wrote:

On 07.12.24 22:01, Peter Wienemann wrote:

Adding a line

    rm -f debian/psrecord.1

to the override_dh_auto_clean target in debian/rules should fix this.

I'm just wondering if you can use debian/clean for that purpose.

Hilmar

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Alexandru,

On 2024-12-08 16:11:02, Alexandru Mihail wrote:

Did all the little final housework you suggested, including bonus (nice
catch !)
Ready for upload when you can !

I've just uploaded psrecord. It should show up in the NEW queue [0] soon
- waiting for FTP master review.

Thanks a lot for your work and for contributing to Debian.

Have a wonderful weekend,

You, too.

Best regards

Peter

[0] https://ftp-master.debian.org/new.html

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Ananthu,

On 2024-12-08 17:58:09, weepingclown wrote:

d/clean would work just as well, that's exactly what I tend to use if I have more than a few files that I have to specify manually to be cleaned.

I always feel undecided which option I should give preference to.

And personally, I'd recommend to use execute_after_dh_auto_clean than override_dh_auto_clean so that it doesn't override anything it was previously doing, just in case.

As long as the override_dh_auto_clean target still contains
dh_auto_clean the original functionality should be retained. At least
this is my understanding. Please correct me if this is wrong. But you
are perfectly right that using execute_after_dh_auto_clean is less
error-prone. Thanks for this suggestion. I added it to my notes. :-)

Best regards

Peter

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Peter,

I believe the previous way of doing this was -

override_dh_foo:
dh_foo
<do stuff>

which is now less verbose if you want -

execute_after_dh_foo:
<do stuff>

or execute_before, when you need that.

My understanding is that there is no added benefit than less verbosity and maybe more clarity (since it tells you in a first glance that it should run before/after dh_foo). So yes, nothing problematic as long as you still have dh_foo there once you use
override_dh_foo, but these execute_* targets feel much better to me. tbph, overriding a target only to run the exact same thing again makes me feel stupid each time, so I change the older patters whenever I come across them in a package :p

Best,
Ananthu

On 8 December 2024 5:36:32 pm UTC, Peter Wienemann <[email protected]> wrote: >As long as the override_dh_auto_clean target still contains dh_auto_clean the original functionality should be retained. At least this is my understanding. Please correct me if this is wrong. But you are perfectly right that using execute_after_dh_auto_
clean is less error-prone. Thanks for this suggestion. I added it to my notes. :-)

Best regards

Peter

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)