Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.maint.python > #16489 > unrolled thread

Re: Upload request: psrecord (NEW)

Back to article view | Back to linux.debian.maint.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Upload request: psrecord (NEW) Peter Wienemann <wiene@debian.org> - 2024-11-24 18:00 +0100
    Re: Upload request: psrecord (NEW) Peter Wienemann <wiene@debian.org> - 2024-11-27 20:50 +0100
      Re: Upload request: psrecord (NEW) Peter Wienemann <wiene@debian.org> - 2024-11-30 10:00 +0100
        Re: Upload request: psrecord (NEW) Peter Wienemann <wiene@debian.org> - 2024-12-01 17:50 +0100
          Re: Upload request: psrecord (NEW) Peter Wienemann <wiene@debian.org> - 2024-12-07 22:10 +0100
            Re: Upload request: psrecord (NEW) weepingclown <weepingclown@disroot.org> - 2024-12-08 18:00 +0100
              Re: Upload request: psrecord (NEW) Peter Wienemann <wiene@debian.org> - 2024-12-08 18:40 +0100
                Re: Upload request: psrecord (NEW) weepingclown <weepingclown@disroot.org> - 2024-12-08 19:50 +0100
            Re: Upload request: psrecord (NEW) Peter Wienemann <wiene@debian.org> - 2024-12-08 18:20 +0100

#16489 — Re: Upload request: psrecord (NEW)

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

[toc] | [next] | [standalone]

#16491

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

[toc] | [prev] | [next] | [standalone]

#16503

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

[toc] | [prev] | [next] | [standalone]

#16506

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

[toc] | [prev] | [next] | [standalone]

#16555

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/psrecord/blob/cda423ed3fa00fadad66cd7a28ed342748d9f88e/LICENSE

[toc] | [prev] | [next] | [standalone]

#16559

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" <hille42@web.de> 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

[toc] | [prev] | [next] | [standalone]

#16562

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

[toc] | [prev] | [next] | [standalone]

#16563

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 <wiene@debian.org> 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

[toc] | [prev] | [next] | [standalone]

#16560

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

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.maint.python

csiph-web