Bug#996722: src:python-volatile: fails to migrate to testing for too long: uploader built arch:all binaries

2021-10-23 Thread Paul Gevers
Hi,

On 21-10-2021 23:15, Nicholas D Steeves wrote:
> For the record,
> from the package maintainer perspective: good communication on the BTS,

Always :)

> integrating the proposed change,

or telling the NMU'er to upload without delay if it's the only change.

> and uploading without cancelling the
> NMU upload is the best social practice?

I don't know about the "without cancelling" part.

> I'd like to keep things
> positive, you know?

Appreciated.

> P.S. I won't be annoyed by the rejection email for -3.1.

I'll *try* to cancel.

Paul



OpenPGP_signature
Description: OpenPGP digital signature


Bug#996722: src:python-volatile: fails to migrate to testing for too long: uploader built arch:all binaries

2021-10-21 Thread Nicholas D Steeves
Hi Paul

Paul Gevers  writes:

> Hi Nicolas,
>
> Thanks you, but as I detect these issues in an automatic way without
> much manual labor, I don't need the credits :). And I uploaded to
> DELAYED exactly to give others the opportunity to fix it before me, so
> uploading to DELAYED in my opinion *always* has that ACK implied.
>

Thank you for providing the opportunity to respond, and ok, as you
prefer! :-)

> I have pasted the diff below, but for such a no change NMU, I'd just
> ignore it if I were you. It's not interesting especially if you beat the
> upload anyways.
>

Agreed.

> I can (and will try) to cancel my upload, but it's rather harmless if I
> fail because it will indeed be rejected if there is already an newer
> version in the suite and you'll only get a reject e-mail about it (which
> can still be annoying, so I'll try and cancel).
>

Ok, thank you for the guidance, and for a positive first "receiving an
NMU proposal" experience :-)  I'll upload momentarily.  For the record,
from the package maintainer perspective: good communication on the BTS,
integrating the proposed change, and uploading without cancelling the
NMU upload is the best social practice?  I'd like to keep things
positive, you know?

Best,
Nicholas

P.S. I won't be annoyed by the rejection email for -3.1.


signature.asc
Description: PGP signature


Bug#996722: src:python-volatile: fails to migrate to testing for too long: uploader built arch:all binaries

2021-10-21 Thread Paul Gevers
Hi Nicolas,

On 21-10-2021 02:17, Nicholas D Steeves wrote:
> I will of course credit you for identifying this issue and taking the
> initiative to fix it, and will upload without delay once I receive your
> ACK (please CC me).

Thanks you, but as I detect these issues in an automatic way without
much manual labor, I don't need the credits :). And I uploaded to
DELAYED exactly to give others the opportunity to fix it before me, so
uploading to DELAYED in my opinion *always* has that ACK implied.

> For future reference, if there was an NMUdiff, I would incorporate it
> into the -4 release along with my change, but then, what is the best
> practise?

I have pasted the diff below, but for such a no change NMU, I'd just
ignore it if I were you. It's not interesting especially if you beat the
upload anyways.

> Ask for the NMU submitter to cancel the delayed upload,
> upload -4 which will presumably cause -3.1 to be rejected when the
> delayed timer fires, or cancel the delayed upload myself?

I can (and will try) to cancel my upload, but it's rather harmless if I
fail because it will indeed be rejected if there is already an newer
version in the suite and you'll only get a reject e-mail about it (which
can still be annoying, so I'll try and cancel).

Paul

paul@mulciber /tmp/python-volatile $ git diff HEAD~
diff --git a/debian/changelog b/debian/changelog
index dacf399..8fcaf23 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+python-volatile (2.1.0-3.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * source only upload to enable migration (Closes: #996722)
+
+ -- Paul Gevers   Sun, 17 Oct 2021 20:58:04 +0200
+
 python-volatile (2.1.0-3) unstable; urgency=medium

   [ Debian Janitor ]



OpenPGP_signature
Description: OpenPGP digital signature


Bug#996722: src:python-volatile: fails to migrate to testing for too long: uploader built arch:all binaries

2021-10-20 Thread Nicholas D Steeves
Hi Paul!

Paul Gevers  writes:

> Source: python-volatile
> Version: 2.1.0-2
> Severity: serious
> Control: close -1 2.1.0-3
> X-Debbugs-CC: jel...@debian.org   
> Tags: sid bookworm pending
> User: release.debian@packages.debian.org
> Usertags: out-of-sync
>
[snip]
> I have immediately closed this bug with the version in unstable, so if
> that version or a later version migrates, this bug will no longer affect
> testing. I have also tagged this bug to only affect sid and bookworm, so
> it doesn't affect (old-)stable.
>
> Your package is only blocked because the arch:all binary package(s)
> aren't built on a buildd. Unfortunately the Debian infrastructure
> doesn't allow arch:all packages to be properly binNMU'ed. Hence, I will
> shortly do a no-changes source-only upload to DELAYED/15, closing this
> bug. Please let me know if I should delay or cancel that upload.
>

Solving this bug justifies an upload, and I'd also like to update my
email address in src:python-volatile.  Normally I don't think changing
an email address would justify an upload, so this is a great opportunity
;-)

I will of course credit you for identifying this issue and taking the
initiative to fix it, and will upload without delay once I receive your
ACK (please CC me).

For future reference, if there was an NMUdiff, I would incorporate it
into the -4 release along with my change, but then, what is the best
practise?  Ask for the NMU submitter to cancel the delayed upload,
upload -4 which will presumably cause -3.1 to be rejected when the
delayed timer fires, or cancel the delayed upload myself?

Thanks!
Nicholas


signature.asc
Description: PGP signature


Bug#996722: src:python-volatile: fails to migrate to testing for too long: uploader built arch:all binaries

2021-10-17 Thread Paul Gevers
Source: python-volatile
Version: 2.1.0-2
Severity: serious
Control: close -1 2.1.0-3
X-Debbugs-CC: jel...@debian.org 
Tags: sid bookworm pending
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing
and unstable for more than 60 days as having a Release Critical bug in
testing [1]. Your package src:python-volatile has been trying to migrate
for 64 days [2]. Hence, I am filing this bug.

If a package is out of sync between unstable and testing for a longer
period, this usually means that bugs in the package in testing cannot be
fixed via unstable. Additionally, blocked packages can have impact on
other packages, which makes preparing for the release more difficult.
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that
hamper the migration of their package in a timely manner.

This bug will trigger auto-removal when appropriate. As with all new
bugs, there will be at least 30 days before the package is auto-removed.

I have immediately closed this bug with the version in unstable, so if
that version or a later version migrates, this bug will no longer affect
testing. I have also tagged this bug to only affect sid and bookworm, so
it doesn't affect (old-)stable.

Your package is only blocked because the arch:all binary package(s)
aren't built on a buildd. Unfortunately the Debian infrastructure
doesn't allow arch:all packages to be properly binNMU'ed. Hence, I will
shortly do a no-changes source-only upload to DELAYED/15, closing this
bug. Please let me know if I should delay or cancel that upload.

Paul

[1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html
[2] https://qa.debian.org/excuses.php?package=python-volatile




OpenPGP_signature
Description: OpenPGP digital signature