On 2018-12-03 14:51, Antoine Beaupré wrote:
On 2018-12-03 14:37:03, Adam D. Barratt wrote:
On 2018-12-03 14:23, Antoine Beaupré wrote:
On 2018-12-03 08:16:47, Julien Cristau wrote:
Control: tag -1 confirmed
On Mon, Jun 18, 2018 at 01:56:11PM -0400, Antoine Beaupre wrote:
diff -Nru monkeysign-2.2.3/debian/changelog
monkeysign-2.2.4/debian/changelog
--- monkeysign-2.2.3/debian/changelog 2017-01-24 15:40:35.000000000
-0500
+++ monkeysign-2.2.4/debian/changelog 2018-06-18 12:18:46.000000000
-0400
@@ -1,3 +1,14 @@
+monkeysign (2.2.4) unstable; urgency=medium
+
+ [ Tobias Rueetschi ]
+ * false isn't defined, that must be False
+
+ [ Antoine Beaupré ]
+ * actually send multiple emails instead of a single one
+ * CVE-2018-12020: add no verbose to avoid fake signatures
+
+ -- Antoine Beaupré <anar...@debian.org> Mon, 18 Jun 2018
12:18:46
-0400
+
monkeysign (2.2.3) unstable; urgency=medium
[ Simon Fondrie-Teitler ]
This would need to be versioned as 2.2.3+deb9u1.
But it's exactly the 2.2.4 release published to unstable - why the
different version number?
Because, as you say, a package with the version "2.2.4" has already
been
uploaded to Debian. One can't have a different package in stable and
unstable with the same version number.
Sure you can. If a package is not updated between the time the unstable
package trickles down into testing and then becomes table, it will have
the exact same version number and binary builds.
Right, so it's, err, not a different package in that situation? :P
(It's not "exactly the same" - the stretch upload will be built in a
stretch chroot, so may well end up with different dependencies. At the
very least, it needs a d/changelog entry detailing that it was
uploaded
to stable, which makes it different from the unstable upload.)
[...]
First I was told to upload it to unstable before uploading it to
stable,
and now I am told the 2.2.4 release cannot be uploaded to stable. I
hope
you understand I might find the process a tad confusing. :)
The point is that for bugs that affect both unstable and stable, the
fixes should always be applied to unstable first. Unstable is where
development happens, and if there turns out to be a fundamental issue
with the change then finding and fixing it in unstable is a matter of a
dinstall's delay - it would also be a poor experience to have the fix
regress between stable releases because no-one applied the fix to
unstable.
No-one is saying that you can't upload 2.2.4 to stable. We're saying
that the version number can't be precisely 2.2.4, as that's already been
used.
Regards,
Adam
