Bug#762715: updates to dch --lts

2017-11-11 Thread Mattia Rizzolo 
On Mon, Oct 23, 2017 at 11:21:49AM -0400, Antoine Beaupré wrote:
> I think what we would need here is a "before/after" set of tricky
> changelog files and flags. Building such a corpus takes time,
> unfortunately, but the actual tests shouldn't be that hard...

Yeah, I agree on that..

Anyway, I've wrote a very very small testcase that clearly is not
exercising anything at all, just for some peace of mind.

I also tweaked the merge that you did with your first patches; as I
wrote in a commit I doubt that code ever worked at all, as those regex
looks wrong to me on several levels, but it's so messy that I don't feel
like further refactoring it by myself.


All in all, I've committed it, I'd appreciate if people could run with
git's debchange so to also check nothing was broken by this.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#762715: updates to dch --lts

2017-10-23 Thread Antoine Beaupré 
On 2017-10-23 16:52:01, Mattia Rizzolo wrote:
> Hi!
>
> On Mon, Oct 23, 2017 at 10:33:58AM -0400, Antoine Beaupré wrote:
>> I figured I would do *some* refactoring while I was there to avoid
>> further code duplication.
>
> YES!  Please refactor it all :D
>
>> I haven't tested all scenarios (and the test suite is limited inthat
>> regard) but this mostly works in my tests locally.
>
> I'd be very happy if you could expand the testsuite some more: that's
> one reason why refactoring that thing is so unappealing, breakages are
> very easy to miss.  I'd actually take that patch before the others.
>
>
> (I haven't reviewed the patches just yet, but from a quick look they
> seem sane at least)

There was at least this bit missing to get the first changelog right...

-- 
A patriot must always be ready to defend his country
against his government.
- Edward Abbey
>From 4cad5da523ce6fca51ceb5f5cd2b19286b738c22 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Antoine=20Beaupr=C3=A9?= 
Date: Mon, 23 Oct 2017 17:01:47 -0400
Subject: [PATCH 3/3] add missing changelog line template for --lts

---
 scripts/debchange.pl | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/scripts/debchange.pl b/scripts/debchange.pl
index d01ca9a8..27915460 100755
--- a/scripts/debchange.pl
+++ b/scripts/debchange.pl
@@ -1273,6 +1273,9 @@ ()
 		print O "  * Non-maintainer upload by the Security Team.\n";
 	}
 	$line = 1;
+} elsif ($opt_lts && ! $opt_news) {
+print O "  * Non-maintainer upload by the LTS Security Team.\n";
+$line = 1;
 	} elsif ($opt_team && ! $opt_news) {
 	print O "  * Team upload.\n";
 	$line = 1;
-- 
2.11.0

Bug#762715: updates to dch --lts

2017-10-23 Thread Antoine Beaupré 
On 2017-10-23 16:52:01, Mattia Rizzolo wrote:
> Hi!
>
> On Mon, Oct 23, 2017 at 10:33:58AM -0400, Antoine Beaupré wrote:
>> I figured I would do *some* refactoring while I was there to avoid
>> further code duplication.
>
> YES!  Please refactor it all :D
>
>> I haven't tested all scenarios (and the test suite is limited inthat
>> regard) but this mostly works in my tests locally.
>
> I'd be very happy if you could expand the testsuite some more: that's
> one reason why refactoring that thing is so unappealing, breakages are
> very easy to miss.  I'd actually take that patch before the others.
>
>
> (I haven't reviewed the patches just yet, but from a quick look they
> seem sane at least)

I think what we would need here is a "before/after" set of tricky
changelog files and flags. Building such a corpus takes time,
unfortunately, but the actual tests shouldn't be that hard...

The problem is there are so many options in dch now that the combination
of options makes the problem space basically exponentional... a
multi-dimentional matrix!

Not sure I have much time to work on this unfortunately...

a.

-- 
The world is a dangerous place, not because of those who do evil,
but because of those who look on and do nothing.
- Albert Einstein

Bug#762715: updates to dch --lts

2017-10-23 Thread Mattia Rizzolo 
Hi!

On Mon, Oct 23, 2017 at 10:33:58AM -0400, Antoine Beaupré wrote:
> I figured I would do *some* refactoring while I was there to avoid
> further code duplication.

YES!  Please refactor it all :D

> I haven't tested all scenarios (and the test suite is limited inthat
> regard) but this mostly works in my tests locally.

I'd be very happy if you could expand the testsuite some more: that's
one reason why refactoring that thing is so unappealing, breakages are
very easy to miss.  I'd actually take that patch before the others.


(I haven't reviewed the patches just yet, but from a quick look they
seem sane at least)

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#762715: updates to dch --lts

2017-10-23 Thread Antoine Beaupré 
Control: tags 762715 +patch

On Mon, Oct 31, 2016 at 12:10:37PM -0400, Antoine Beaupré wrote:
> On 2016-10-28 20:10:43, Holger Levsen wrote:
> >> Since this may change again in the future before this issue is resolved,
> >> maybe it's better to just refer to the LTS notes here:
> >> https://wiki.debian.org/LTS/Development#Build_the_update
> >
> > no. "dch --lts" should do the right thing - and just like "dch --bpo" it
> > will be outdated & in need of an update once in a while - each time we
> > release… \o/ yay! :)
> 
> There are probably ways to make it use variables instead of hardcoding
> (say) "wheezy-security"... :)
> 
> I looked at the code and there are around 14 instances of "$opt_s" in
> the code. Either we need to duplicate that or make --lts enable $opt_s
> and customize some bits of it.

I ended up copying the -s option the same way lamby copied the --bpo
option to create --sru in #871657. Not ideal, but at this point it's the
way of the land...

So attached are patches to add a --lts option. I figured I would do
*some* refactoring while I was there to avoid further code duplication.
I haven't tested all scenarios (and the test suite is limited in that
regard) but this mostly works in my tests locally.

A.
From 0d1b329ac97c54a3163d350b9e5d37cfc9e9dad8 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Antoine=20Beaupr=C3=A9?= 
Date: Mon, 23 Oct 2017 10:29:28 -0400
Subject: [PATCH 1/2] unify version information

instead of having a guessed version info per type of upload (stable,
bpo, but also eventually lts, security, etc), we just have a single
variable we use.

we also merge the bpo and stable information hashes because they
mostly contain the same data. only stable had less information, but if
the info wasn't found, it was falling back to the previous entry in
the changelog, which is not better than our guess.

this also partly fixes -s uploads distro guessing.
---
 scripts/debchange.pl | 57 +++-
 1 file changed, 25 insertions(+), 32 deletions(-)

diff --git a/scripts/debchange.pl b/scripts/debchange.pl
index ef8b84b5..00da3b6d 100755
--- a/scripts/debchange.pl
+++ b/scripts/debchange.pl
@@ -611,11 +611,10 @@ ()
 my $MAINTAINER = 'MAINTAINER';
 my $EMAIL = 'EMAIL';
 my $DISTRIBUTION = 'UNRELEASED';
-my $bpo_dist = '';
-my %bpo_dists = ( 60, 'squeeze', 70, 'wheezy', 8, 'jessie', 9, 'stretch' );
-my $stable_dist = '';
-my %stable_dists = ( 8, 'jessie', 9, 'stretch' );
+my %dists = ( 60, 'squeeze', 70, 'wheezy', 7, 'wheezy', 8, 'jessie', 9, 'stretch' );
 my $latest_dist = '9';
+# dist guessed from backports, SRU, security uploads...
+my $guessed_dist = '';
 my $CHANGES = '';
 # Changelog urgency, possibly propogated to NEWS files
 my $CL_URGENCY = '';
@@ -1168,31 +1167,25 @@ ()
 		$end++;
 		}
 
-		# Attempt to set the distribution for a backport correctly
-		# based on the version of the previous backport
-		if ($opt_bpo) {
-		my $previous_dist = $start;
-		$previous_dist =~ s/^.*~bpo(\d+)\+$/$1/;
-		if (defined $previous_dist and defined
-			$bpo_dists{$previous_dist}) {
-			$bpo_dist = $bpo_dists{$previous_dist} . '-backports';
-		} else {
-			# Fallback to using the previous distribution
-			$bpo_dist = $changelog->{Distribution};
-		}
-		}
-
 		# Attempt to set the distribution for a stable upload correctly
 		# based on the version of the previous upload
-		if ($opt_stable) {
+		if ($opt_stable || $opt_bpo || $opt_s) {
 		my $previous_dist = $start;
-		$previous_dist =~ s/^.*+deb(\d+)u$/$1/;
+		$previous_dist =~ s/^.*[+~]deb(\d+)u$/$1/;
 		if (defined $previous_dist and defined
-			$stable_dists{$previous_dist}) {
-			$stable_dist = $stable_dists{$previous_dist};
-		} else {
+			$dists{$previous_dist}) {
+if ($opt_s) {
+$guessed_dist = $dists{$previous_dist} . '-security';
+} elsif ($opt_bpo) {
+$guessed_dist = $dists{$previous_dist} . '-backports';
+} else {
+$guessed_dist = $dists{$previous_dist};
+}
+} elsif ($opt_s) {
+$guessed_dist = $dists{$latest_dist} . '-security';
+} else {
 			# Fallback to using the previous distribution
-			$stable_dist = $changelog->{Distribution};
+			$guessed_dist = $changelog->{Distribution};
 		}
 		}
 
@@ -1231,12 +1224,12 @@ ()
 }
 
 if ($opt_bpo) {
-	$bpo_dist ||= $bpo_dists{$latest_dist} . '-backports';
+	$guessed_dist ||= $dists{$latest_dist} . '-backports';
 }
 if ($opt_stable) {
-	$stable_dist ||= $stable_dists{$latest_dist};
+	$guessed_dist ||= $dists{$latest_dist};
 }
-my $distribution = $opt_D || $bpo_dist || $stable_dist || (($opt_release_heuristic eq 'changelog') ? "UNRELEASED" : $DISTRIBUTION);
+my $distribution = $opt_D || $guessed_dist || (($opt_release_heuristic eq

Bug#762715: updates to dch --lts

2016-11-23 Thread James McCoy 
On Mon, Oct 31, 2016 at 12:10:37PM -0400, Antoine Beaupré wrote:
> On 2016-10-28 20:10:43, Holger Levsen wrote:
> >> Since this may change again in the future before this issue is resolved,
> >> maybe it's better to just refer to the LTS notes here:
> >> https://wiki.debian.org/LTS/Development#Build_the_update
> >
> > no. "dch --lts" should do the right thing - and just like "dch --bpo" it
> > will be outdated & in need of an update once in a while - each time we
> > release… \o/ yay! :)
> 
> There are probably ways to make it use variables instead of hardcoding
> (say) "wheezy-security"... :)
> 
> I looked at the code and there are around 14 instances of "$opt_s" in
> the code. Either we need to duplicate that or make --lts enable $opt_s
> and customize some bits of it.
> 
> Did we ever hear from the maintainers of devscripts to see if a patch
> would be accepted? I'd be happy to fix that up... it doesn't look too
> hard.

Yes, patches are accepted.  See also #800413. :)

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Bug#762715: updates to dch --lts

2016-10-31 Thread Antoine Beaupré 
On 2016-10-28 20:10:43, Holger Levsen wrote:
>> Since this may change again in the future before this issue is resolved,
>> maybe it's better to just refer to the LTS notes here:
>> https://wiki.debian.org/LTS/Development#Build_the_update
>
> no. "dch --lts" should do the right thing - and just like "dch --bpo" it
> will be outdated & in need of an update once in a while - each time we
> release… \o/ yay! :)

There are probably ways to make it use variables instead of hardcoding
(say) "wheezy-security"... :)

I looked at the code and there are around 14 instances of "$opt_s" in
the code. Either we need to duplicate that or make --lts enable $opt_s
and customize some bits of it.

Did we ever hear from the maintainers of devscripts to see if a patch
would be accepted? I'd be happy to fix that up... it doesn't look too
hard.

A.
-- 
Le travail des pauvres est la seule source de toutes les douceurs de 
l'existence.
- Bernard Mandeville

Bug#762715: updates to dch --lts

2016-10-28 Thread Holger Levsen 
Hi,

On Wed, Oct 26, 2016 at 01:23:56PM -0400, Antoine Beaupré wrote:
> I believe a few parameters here are incorrect as they have changed since
> this bug was reported.
> 
> * release should be: "wheezy-security"
> * the first log entry should be: "Non-maintainer upload by the Wheezy
>   LTS Team."
> * increment the version like this:
>   * if a package already e.g. had a +wheezy1 update, use +wheezy2 for the
> next update,
>   * if a package hasn't seen an update, use +deb7u1 for the next update.
> 
> Basically, the change is "s/squeeze/wheezy/" and "wheezy-security works
> now".

I happily stand corrected on all these details. Thanks!
 
> Since this may change again in the future before this issue is resolved,
> maybe it's better to just refer to the LTS notes here:
> https://wiki.debian.org/LTS/Development#Build_the_update

no. "dch --lts" should do the right thing - and just like "dch --bpo" it
will be outdated & in need of an update once in a while - each time we
release… \o/ yay! :)


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Bug#762715: updates to dch --lts

2016-10-26 Thread Antoine Beaupré 
I believe a few parameters here are incorrect as they have changed since
this bug was reported.

* release should be: "wheezy-security"
* the first log entry should be: "Non-maintainer upload by the Wheezy
  LTS Team."
* increment the version like this:
  * if a package already e.g. had a +wheezy1 update, use +wheezy2 for the
next update,
  * if a package hasn't seen an update, use +deb7u1 for the next update.

Basically, the change is "s/squeeze/wheezy/" and "wheezy-security works
now".

Since this may change again in the future before this issue is resolved,
maybe it's better to just refer to the LTS notes here:

https://wiki.debian.org/LTS/Development#Build_the_update

A.

-- 
Hard times are coming when we will be wanting the voices of writers
who can see alternatives to how we live now and can see through our
fear-stricken society and its obsessive technologies to other ways of
being, and even imagine some real grounds for hope. We will need
writers who can remember freedom. Poets, visionaries—the realists of a
larger reality. - Ursula Le Guin