Re: Proposal: Handling of changelog bug closures in Debian derived distros
* Guillem Jover | On Fri, 2006-11-17 at 12:32:18 -0800, Tollef Fog Heen wrote: | They are just strings. But, as I wrote, they are just one example; we | would probably want to associate uploads and bzr branches as well. The | LP syntax could be LP: #123 for closing bugs, LP: spec $specname for | associating with a spec, and LP: bzr $product/$branchname (or something | similar) for associating bzr branches with an upload. | | Are those the only ones you'd need for now? Could the recently proposed | Vcs field help with the bzr branches or does this refer to upstream | branches only? Given that we (Canonical and Ubuntu) is firmly committed to bzr, our interest in other RCS-es is not likely to be a concern. Note that being able to associate an upload and a branch is not the same as saying they come from the same place. As an example, we might have a changelog entry reading: * Integrate 8d branch for better support of 8D graphics cards.. LP: bzr xorg/8d-graphics-support The upload would then come from an integration branch, but we want to create the association automatically. | What about Implements: foo (or similar), a proper regex would have | to be defined, but you get the idea. | | Specs generally aren't implemented by a single upload, so it would be | Spec-related or something like that. | | Could you explain how would you use that information to associate | things? And is there some way you would mark that spec is fully | implemented? The association would be done in launchpad, so it would not be of concern for dpkg itself. (We would probably have the upload processor associate the relevant meta-data with the upload based on the .changes file and then make sure the meta-data was kept together with the other meta-data we keep for an upload.) I don't think we would ever want to mark spec progress in a changelog; we discussed it, but it was rejected since progress often isn't the result of a single upload, but rather a series of uploads of multiple packages. I'll be happy to have this discussion further, but I think a discussion on how Ubuntu's procedures work is getting sufficiently off-topic for debian-project. :-) (Another reason for wanting bug closure but not spec progress tracking in a changelog is bugs are closed frequently; often multiple per uploads. A person probably has somewhere in the range of 5-10 specs for a six month release cycle; changing the status of those by way of a web UI isn't a big overhead.) | I would rather just have a namespace allocation and derivatives can do | whatever they want within their namespace, but to a certain degree I see | why this is problematic and it seems you are unhappy with that? | | I'd prefer if we came up with something that is general and does not | need everyone around to implement their own solution. Granted some of | the work will still be specific per distribution, for example the | launchpad or bugzilla hooks into dak, but such solution would minimize | them, and most of the changes could be merged upstream w/o problem. A problem I see with trying to make this general is we end up with a lot of typing. The Closes syntax in changelogs is wonderful because it's so simple. If people had to write Closes: debian/#1234 (as an example), it'd be less readable, more writing and I think less liked as a whole. Inside a project, bug numbers are going to be unique; there's only one Freedesktop.org bug #1234, there's just one Debian bug #1234 and there's just one Launchpad bug #1234, so for me it makes a lot more sense to have a way to refer to bug #1234 in the context of a project and then treat that as a bug closing there. It's not like reopening bugs is that common anyway, so using a web/email UI for that is perfectly reasonable. If the syntax ended up being Closes: debian/#1234, Closes: Launchpad/#1234, Closes: Freedesktop.org/#1234, the «closes» bit is redundant and we could just as easily use Debian: #1234, LP: #1234 and fd.o: #1234 (We can argue over whether abbreviations should be allowed or not. I think they should, overlaps should be uncommon enough that we don't really need to care deeply.) -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `-
Re: Proposal: Handling of changelog bug closures in Debian derived distros
On Fri, 2006-11-17 at 12:32:18 -0800, Tollef Fog Heen wrote: Guillem Jover skrev: For specs I would add a new syntax, which could be used by everyone equally, even Debian could start using it if desired. Do launchpad specs have a numeric value or are just strings? They are just strings. But, as I wrote, they are just one example; we would probably want to associate uploads and bzr branches as well. The LP syntax could be LP: #123 for closing bugs, LP: spec $specname for associating with a spec, and LP: bzr $product/$branchname (or something similar) for associating bzr branches with an upload. Are those the only ones you'd need for now? Could the recently proposed Vcs field help with the bzr branches or does this refer to upstream branches only? What about Implements: foo (or similar), a proper regex would have to be defined, but you get the idea. Specs generally aren't implemented by a single upload, so it would be Spec-related or something like that. Could you explain how would you use that information to associate things? And is there some way you would mark that spec is fully implemented? I would rather just have a namespace allocation and derivatives can do whatever they want within their namespace, but to a certain degree I see why this is problematic and it seems you are unhappy with that? I'd prefer if we came up with something that is general and does not need everyone around to implement their own solution. Granted some of the work will still be specific per distribution, for example the launchpad or bugzilla hooks into dak, but such solution would minimize them, and most of the changes could be merged upstream w/o problem. I suppose there would not be much of a problem with allocating a namespace, but I'd like to go this route only as a last resort, in case we find out that we cannot get a general solution that satisfies everyone. regards, guillem -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: Handling of changelog bug closures in Debian derived distros
Guillem Jover skrev: For specs I would add a new syntax, which could be used by everyone equally, even Debian could start using it if desired. Do launchpad specs have a numeric value or are just strings? They are just strings. But, as I wrote, they are just one example; we would probably want to associate uploads and bzr branches as well. The LP syntax could be LP: #123 for closing bugs, LP: spec $specname for associating with a spec, and LP: bzr $product/$branchname (or something similar) for associating bzr branches with an upload. What about Implements: foo (or similar), a proper regex would have to be defined, but you get the idea. Specs generally aren't implemented by a single upload, so it would be Spec-related or something like that. I would rather just have a namespace allocation and derivatives can do whatever they want within their namespace, but to a certain degree I see why this is problematic and it seems you are unhappy with that? - tfheen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: Handling of changelog bug closures in Debian derived distros
Guillem Jover skrev: [...] which are wrong, ugly or may need a central registration place to avoid collisions either in the mnemonic or the alternative closure syntax. Probably the cleanest one is the Closes Ubuntu: approach. (With my Ubuntu, not my Debian hat on) While closing bugs will the by far most usual action, we do also want to have the ability to relate an upload to a specification or similar in Launchpad, which is why we don't think a Closes: syntax alone is enough. What are your thoughts on this matter? - tfheen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: Handling of changelog bug closures in Debian derived distros
On Thu, 2006-11-16 at 16:43:19 -0800, Tollef Fog Heen wrote: Guillem Jover skrev: which are wrong, ugly or may need a central registration place to avoid collisions either in the mnemonic or the alternative closure syntax. Probably the cleanest one is the Closes Ubuntu: approach. While closing bugs will the by far most usual action, we do also want to have the ability to relate an upload to a specification or similar in Launchpad, which is why we don't think a Closes: syntax alone is enough. What are your thoughts on this matter? Yes, I'm aware of that problem, it affects maemo as well. Initially, just wanted to discuss one issue at a time, but I suppose we can go for the whole thing. For specs I would add a new syntax, which could be used by everyone equally, even Debian could start using it if desired. Do launchpad specs have a numeric value or are just strings? I suppose it does not matter much anyway, the value could be just concatenated to the output field in the .changes file, and the final knowledge about what to do with that field is in dak or whatever archive software which is processing the uploaded .changes files. What about Implements: foo (or similar), a proper regex would have to be defined, but you get the idea. regards, guillem -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: Handling of changelog bug closures in Debian derived distros
On Wed, 2006-11-15 at 01:59:52 +1000, Anthony Towns wrote: On Tue, Nov 14, 2006 at 08:11:01AM +0200, Guillem Jover wrote: foo (1.0-2naibed2) quux; urgency=low, origin=naibed foo (1.0-2naibed1) quux; urgency=low, origin=naibed foo (1.0-2) unstable; urgency=high Neat. Thanks. ;) Presumably Debian should REJECT uploads with an Origin: field other than debian, no? I think there's an item on dak's TODO list about rejecting .deb:s with an Origin != debian. For the .changes files, if dpkg-dev started putting such field by default, then that could be considered, but as Joey said this could not be enforced until a stable system supported this, even with uploads putting that option in the changelog manually, dpkg-genchanges nor dpkg-gencontrol will export it (because the optional field ends up being XS-Origin). Would it be more pleasant to have something like: foo (1.0-2naibed1) naibed/quux; urgency=low instead? Would it be worth requiring: foo (1.0-2) debian/unstable; urgency=high Maybe, but the problem with those is that it makes the changelog format incompatible, the origin stuff is optional and old tools should not barf, at most complain that they do not understand that option. or foo (1.0-2) unstable; urgency=high, origin=debian for Debian uploads? I'd say not for now, and would tend for a smooth introduction of this into Debian. So that this would benefit the derivatives and they could start using it and Debian could switch to that in the future. regards, guillem -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: Handling of changelog bug closures in Debian derived distros
Hi Guillem, On Tue, 2006-11-14 at 08:11 +0200, Guillem Jover wrote: Right now there's no clean way for a Debian derivative to close bugs specific to their distro in a changelog entry and then distinguish those from Debian bugs. Yes, for a Debian derivative. I'd like that developers from derivatives would get involved in this discussion Absolutely. It's in the interest of the derivatives. I don't think that the Debian project should lead this discussion. How many derivatives currently automatically parse the changelogs to update their bug tracking systems? Maybe only Ubuntu, I'm not sure. so that we can get a general solution for everyone, A solution for the derivative. Or for multiple derivatives if they agree on using the same solution. I don't think it's a solution for Debian. as I think Debian should be responsible for providing the infrastructure to do that. No, I don't think that Debian is responsible for helping derivatives to automate the updating of the derivatives' bug tracking systems. Don't get me wrong, there's nothing wrong with cooperating with Ubuntu or other derivatives. But I think that joint efforts should make Debian better. If not then I wonder if Debian should do the efforts. So I'd propose to extend the changelog format I have not yet studied your proposal, because I want to get some bugs fixed before etch releases. :) Regards, Bart Martens signature.asc Description: This is a digitally signed message part
Re: Proposal: Handling of changelog bug closures in Debian derived distros
On Tue, Nov 14, 2006 at 08:11:01AM +0200, Guillem Jover wrote: foo (1.0-2naibed2) quux; urgency=low, origin=naibed foo (1.0-2naibed1) quux; urgency=low, origin=naibed foo (1.0-2) unstable; urgency=high Neat. Presumably Debian should REJECT uploads with an Origin: field other than debian, no? Would it be more pleasant to have something like: foo (1.0-2naibed1) naibed/quux; urgency=low instead? Would it be worth requiring: foo (1.0-2) debian/unstable; urgency=high or foo (1.0-2) unstable; urgency=high, origin=debian for Debian uploads? Cheers, aj signature.asc Description: Digital signature
Re: Proposal: Handling of changelog bug closures in Debian derived distros
On Tue, 14 Nov 2006, Bart Martens wrote: I don't think that the Debian project should lead this discussion. We are the origin of the tools, and we are the upstream for them, so *yes*, we are to be part of, and maybe even lead this discussion. No, I don't think that Debian is responsible for helping derivatives to automate the updating of the derivatives' bug tracking systems. Don't get me wrong, there's nothing wrong with cooperating with Ubuntu or other derivatives. But I think that joint efforts should make Debian better. If not then I wonder if Debian should do the efforts. It will make my life as a DD easier when maintaining my Debian packages where I want to merge from other debian-based distros, or if we have a cross-distro co-maintenance of a package... This is, as usual, something we better join in so that a good-for-everyone solution is found and implemented before it results in too many work for all involved. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: Handling of changelog bug closures in Debian derived distros
Anthony Towns wrote: Presumably Debian should REJECT uploads with an Origin: field other than debian, no? Might be nice, on the other hand... Would it be more pleasant to have something like: foo (1.0-2naibed1) naibed/quux; urgency=low instead? ...wouldn't something like this amount to having Distribution: naibed/quux in .changes. This might actually be desirable and would be already implemented in dak? Would it be worth requiring: foo (1.0-2) debian/unstable; urgency=high or foo (1.0-2) unstable; urgency=high, origin=debian for Debian uploads? Wouldn't the benefit be deminished by dch et al. producing changelog entries suited for upload to Debian by default? If derivatives change this, their packages woudln't go into Debian anyways. Cheers T. -- Thomas Viehmann, http://thomas.viehmann.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: Handling of changelog bug closures in Debian derived distros
On Wed, 15 Nov 2006 01:59:52 +1000, Anthony Towns aj@azure.humbug.org.au said: On Tue, Nov 14, 2006 at 08:11:01AM +0200, Guillem Jover wrote: foo (1.0-2naibed2) quux; urgency=low, origin=naibed foo (1.0-2naibed1) quux; urgency=low, origin=naibed foo (1.0-2) unstable; urgency=high Neat. Presumably Debian should REJECT uploads with an Origin: field other than debian, no? Would it be more pleasant to have something like: foo (1.0-2naibed1) naibed/quux; urgency=low instead? Would it be worth requiring: foo (1.0-2) debian/unstable; urgency=high or foo (1.0-2) unstable; urgency=high, origin=debian for Debian uploads? No, please don't/ It is one thing to patch dpkg to make things easier for the derivatives (on the other hand, they can patch their own version of dpkg), it is another to change how uplaods work in Debian, or to reject uploads to Debian because one forgot add the debian origin. manoj -- The trouble with opportunity is that it always comes disguised as hard work. Herbert V. Prochnow Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: Handling of changelog bug closures in Debian derived distros
Manoj Srivastava wrote: No, please don't/ It is one thing to patch dpkg to make things easier for the derivatives (on the other hand, they can patch their own version of dpkg), it is another to change how uplaods work in Debian, or to reject uploads to Debian because one forgot add the debian origin. Another thing: Whatever you do, don't do it on stable or security builds will end up in the void. Regards, Joey -- Still can't talk about what I can't talk about. Sorry. -- Bruce Schneier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: Handling of changelog bug closures in Debian derived distros
On Tue, Nov 14, 2006 at 08:11:01AM +0200, Guillem Jover wrote: * Using a different Closes: name, which just sidetracks the issue if every derivative have to use a different name, this does not scale. (Example: Maemo uses Fixes: instead of Closes: [1], and there's a proposal in Ubuntu to do something similar with a different name[3]). FTR, the syntax agreed upon for Launchpad (and thus Ubuntu) is: LP: #xxx which is not arbitrary or ambiguous like fixes vs. closes. [...] which are wrong, ugly or may need a central registration place to avoid collisions either in the mnemonic or the alternative closure syntax. Probably the cleanest one is the Closes Ubuntu: approach. I don't see a problem with the approach we've chosen for Launchpad (which will also cover several Ubuntu derivatives). Likewise, I think that qualifying it with the distribution name is perfectly OK; that's already unique enough. So I'd propose to extend the changelog format to add an optional origin field in the header, then that information will be preserved after the upload. Something like this: foo (1.0-2naibed2) quux; urgency=low, origin=naibed [...] I think this is a fine idea, though orthogonal to what we're doing with Launchpad references in changelogs. That origin could be matched against /etc/dpkg/origins. I'm attaching a PoC patch with those change to dpkg. Probably we'd not want to output the Origin field in the default mode (assuming Debian or local), instead of the current implementation which outputs Origin: debian. So comments and other proposals welcome! I didn't see the patch, but bear in mind that it's not unusual to upload a package to Debian from an Ubuntu system or vice versa. -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Proposal: Handling of changelog bug closures in Debian derived distros
Hi, Right now there's no clean way for a Debian derivative to close bugs specific to their distro in a changelog entry and then distinguish those from Debian bugs. I'd like that developers from derivatives would get involved in this discussion so that we can get a general solution for everyone, as I think Debian should be responsible for providing the infrastructure to do that. As an example, say package foo_1.0-2 is in Debian, then distro Naibed takes it and modifies some stuff and gets versions foo_1.0-2naibed1 and foo_1.0-2naibed2. If this distro wants to automatically parse the changelog for version tracking or when including a mix of changelog entries from Debian and Naibed at upload time, then it needs a way to distinguish the bugs from versions = 1.0-2 (Debian specific) to the ones from versions = 1.0-2naibed1 (Naibed specific). We cannot assume that Naibed will not use 'unstable' as the target suite, though. Currently we have in place the Origin and Bugs fields[0] for the debian/control file, but those only allow overriding the entire origin or bts for a package, and not for a specific version. The current workarounds I've seen to this problem have been: * Prepending an Origin code into each bug number. (Example: Maemo prepends NB to the bug number, like Fixes: NB#12345 [1]). * Appending an Origin code into each bug number. (Eample: a different practice in Maemo, appending @Nokia, like Closes: [EMAIL PROTECTED] [2]). * Using an URL to qualify the bug number. (Example: I think I've seen that in some Ubuntu changelogs, but cannot find any example now). * Using a different Closes: name, which just sidetracks the issue if every derivative have to use a different name, this does not scale. (Example: Maemo uses Fixes: instead of Closes: [1], and there's a proposal in Ubuntu to do something similar with a different name[3]). * Appending the Origin to the Closes. (Example: Closes Ubuntu: #123 and Closes: Malone #123). which are wrong, ugly or may need a central registration place to avoid collisions either in the mnemonic or the alternative closure syntax. Probably the cleanest one is the Closes Ubuntu: approach. So I'd propose to extend the changelog format to add an optional origin field in the header, then that information will be preserved after the upload. Something like this: foo (1.0-2naibed2) quux; urgency=low, origin=naibed * Fixed c. (Closes: #322) -- Naibed Devel [EMAIL PROTECTED] Tue, 3 Oct 2006 05:15:10 +0300 foo (1.0-2naibed1) quux; urgency=low, origin=naibed * Fixed b. (Closes: #321) -- Naibed Devel [EMAIL PROTECTED] Tue, 02 May 2006 03:11:39 +0300 foo (1.0-2) unstable; urgency=high * Fixed a. (Closes: #12345) -- Debian Devel [EMAIL PROTECTED] Thu, 27 Oct 2005 07:12:47 +0300 That origin could be matched against /etc/dpkg/origins. I'm attaching a PoC patch with those change to dpkg. Probably we'd not want to output the Origin field in the default mode (assuming Debian or local), instead of the current implementation which outputs Origin: debian. So comments and other proposals welcome! regards, guillem [0] http://lists.debian.org/debian-policy/2000/07/msg00074.html http://lists.debian.org/debian-policy/2000/11/msg00183.html [4] [1] https://stage.maemo.org/svn/maemo/projects/haf/trunk/gtk+/debian/changelog [2] https://stage.maemo.org/svn/maemo/projects/haf/trunk/maemo-launcher/debian/changelog [3] https://wiki.ubuntu.com/ClosingBugsFromChangelog https://features.launchpad.net/distros/ubuntu/+spec/changelog-closes-bugs [4] It was curious to see the different PoV related to derived distros and bug hoarding at that time. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: Handling of changelog bug closures in Debian derived distros
On Tue, 2006-11-14 at 08:11:01 +0200, Guillem Jover wrote:
[...]. I'm attaching
a PoC patch with those change to dpkg. Probably we'd not want to
output the Origin field in the default mode (assuming Debian or local),
instead of the current implementation which outputs Origin: debian.
Hmm, and of course forgot the attachment...
regards,
guillem
Index: scripts/changelog/debian.pl
===
--- scripts/changelog/debian.pl (revision 596)
+++ scripts/changelog/debian.pl (working copy)
@@ -62,13 +62,19 @@
%mapkv=(); # for future use
$i=100;grep($fieldimps{$_}=$i--,
- qw(Source Version Distribution Urgency Maintainer Date Closes
+ qw(Source Version Origin Distribution Urgency Maintainer Date Closes
Changes));
$i=1;grep($urgencies{$_}=$i++,
qw(low medium high critical emergency));
$expect='first heading';
+# Set the default Origin.
+$f{'Origin'} = 'debian';
+my $current_origin;
+
+my @closes;
+
while (STDIN) {
s/\s*\n$//;
#printf(STDERR %-39.39s %-39.39s\n,$expect,$_);
@@ -86,6 +92,10 @@
} else {
clerror(sprintf(_g(found start of entry where expected %s),
$expect));
}
+
+# Set the default value in case the optional origin is missing.
+$current_origin = 'debian';
+
$rhs= $'; $rhs =~ s/^\s+//;
undef %kvdone;
for $kv (split(/\s*,\s*/,$rhs)) {
@@ -113,6 +123,11 @@
(($newurgn $oldurgn ? $newurg : $oldurg).
$oldcomment.
$newcomment);
+} elsif ($k eq 'Origin') {
+if ($expect eq 'first heading') {
+ $f{'Origin'} = $v;
+}
+$current_origin = $v;
} elsif (defined($mapkv{$k})) {
$f{$mapkv{$k}}= $v;
} elsif ($k =~ m/^X[BCS]+-/i) {
@@ -142,6 +157,14 @@
$expect eq 'start of change data' || $expect eq 'more change data or
trailer' ||
clerror(sprintf(_g(found change data where expected %s),
$expect));
$f{'Changes'}.= ( .\nx$blanklines). $_\n; $blanklines=0;
+
+# Add only bug closures if we are on an entry with the same origin as
+# the first one.
+if ($f{'Origin'} eq $current_origin and
+$_ =~ /closes:\s*(?:bug)?\#?\s?\d+(?:,\s*(?:bug)?\#?\s?\d+)*/ig) {
+push(@closes, $ =~ /\#?\s?(\d+)/g);
+}
+
$expect= 'more change data or trailer';
} elsif (!m/\S/) {
next if $expect eq 'start of change data' || $expect eq 'next heading
or eof';
@@ -158,9 +181,6 @@
$f{'Changes'} =~ s/\n$//;
$f{'Changes'} =~ s/^/\n/;
-while ($f{'Changes'} =~
/closes:\s*(?:bug)?\#?\s?\d+(?:,\s*(?:bug)?\#?\s?\d+)*/ig) {
- push(@closes, $ =~ /\#?\s?(\d+)/g);
-}
$f{'Closes'} = join(' ',sort { $a = $b} @closes);
outputclose(0);
Index: scripts/dpkg-genchanges.pl
===
--- scripts/dpkg-genchanges.pl (revision 596)
+++ scripts/dpkg-genchanges.pl (working copy)
@@ -75,7 +75,7 @@
}
$i=100;grep($fieldimps{$_}=$i--,
- qw(Format Date Source Binary Architecture Version
+ qw(Format Date Source Binary Architecture Version Origin
Distribution Urgency Maintainer Changed-By Description
Closes Changes Files));
@@ -228,7 +228,7 @@
setsourcepackage;
} elsif (m/^Maintainer$/i) {
$f{Changed-By}=$v;
-} elsif (m/^(Version|Changes|Urgency|Distribution|Date|Closes)$/i) {
+} elsif
(m/^(Version|Changes|Urgency|Origin|Distribution|Date|Closes)$/i) {
$f{$_}= $v;
} elsif (s/^X[BS]*C[BS]*-//i) {
$f{$_}= $v;
Index: scripts/dpkg-gencontrol.pl
===
--- scripts/dpkg-gencontrol.pl (revision 596)
+++ scripts/dpkg-gencontrol.pl (working copy)
@@ -173,7 +173,7 @@
} elsif (m/^Version$/) {
$sourceversion= $v;
$f{$_}= $v unless length($forceversion);
-} elsif (m/^(Maintainer|Changes|Urgency|Distribution|Date|Closes)$/) {
+} elsif
(m/^(Maintainer|Changes|Urgency|Origin|Distribution|Date|Closes)$/) {
} elsif (s/^X[CS]*B[CS]*-//i) {
$f{$_}= $v;
} elsif (!m/^X[CS]+-/i) {
