Bug#1130119: dpkg-source newly rejects unfinalised changelogs
Guillem Jover writes ("Re: Bug#1130119: dpkg-source newly rejects unfinalised
changelogs"):
> Because this was unintentional, I've prepared a minimal change to
> solve this for now, which I'll include in 1.23.8. Change attached.
Thanks.
> But
I wrote some point-by-point responses but I agree that we should talk
about the design questions properly.
I hope you will forgive a long and rather discursive reply.
I'm going to use the term "unfinalised" for the abstract concept of
changelog, or changelog-derived information, relating to a version
which is stitll in preparation. Ie what in dgit.git is represented by
a changelog entry without a trailer line, and what dch likes to
represent by replacing the target with UNRELEASED.
Unfinalised changelogs have a variety of useful properties: they can
allow builds of pre-release packages to be distinguished (ideally, in
their version number); they can prevent accidental confusion between
unreleased and released software; indeed they can prevent
unintentional release. I think this is common ground.
(In principle some of these purposes might be solved by use of git tag
information, without changing the tree. Some other ecosystems and
upstreams work this way. But git is not available everywhere in
Debian, git tags aren't reliably conveyed by git, and we generally
think that the output of a package build should depend only on the
tree and not on git objects/refs. So I'm going to assume that we are
going to keep representing this information in-tree, in
debian/changelog.)
The unfinalisedness of the changelog starts out as text in the
changelog file. It is then converted by various machinery (mostly in
dpkg-dev) to deb822 metadata in .changes etc.
We have two nearly separate questions to answer.
1. What syntax/format should we use in debian/changelog; and therefore
what information should be present about the unreleased code.
2. What metadata values should be eppear at various stages.
In d/changelog, we *do* want the target suite, because that's a
property of the branch so ought to be changed explicitly.
We want *some* version number information; either "based on " or "prospective " would do. Otherwise we can't
build sensible binaries from the in-development codebase.
Do we want any changed-by name/address? We *could* name the person
doing the administrative work on the changelog. Often, this is the
person who did the previous release - the new changelog entry is part
of routine post-release work. Sometimes this is done by the first
person to make a post-release change. But in neither case is this
really truthful. Subsequent substantive changes will typically be
done by someone else. ("Personal data shall be accurate".)
Taking a step back: what does changed-by really mean? In a release,
it is always the person deciding upon and preparing the release.
(That might be different to a sponsor who signs it.) Ie, the person
primarily responsible for the technical judgement that this code
should be released now. That's how we use the changelog trailer in a
released version and it's how all the downstream tooling interprets
it. It's *the human who made the release*.
An unreleased version *doesn't have a releaser*! No human has made
the release because it's not a release. Putting someone's name in
there to satisfy some tooling that demands that all code it works with
must have "someone who released it" is simply wrong. The code *isn't
released* and programs that expects to be able to work with unreleased
software should not be demanding that some dummy human name is
inserted as the notional releaser.
Likewise, any date we put in the changelog is largely meaningless.
It certainly quickly gets out of date, in most workflows. At least
there aren't data protection problems with including a wrong date, so
we could do that if we felt it convenient.
So I think an unfinalised debian/changelog file:
- should *not* contain the information that is normally in tthe trailer;
- *should* contain the target suite.
That is precisely what the traditional (Emacs mode, pre-dch)
unfinalised changelog format contains.
Now on to metadata (typically, in deb822 form). I think we actually
have two kinds of systems that need to deal with changelog metadata.
1. Things that build source and binary packages, including local test
builds, Salsa CI, and so on; 2. software maintaining a repository of
releases (ftp.debian.org, dgit-repos, tag2upload).
For (1) we need to be able to deal with unreleased source code. We
need to be able to build it, and lint it, and basically do everything
short of actually publishing it as part of a release. (More
sophisticated CI systems might want to "fake up" a private release,
but that's ratther a different questiton and isn't the usual case.)
For (2), archive sof
Bug#1130119: dpkg-source newly rejects unfinalised changelogs
Hi!
On Sun, 2026-03-08 at 20:30:02 +, Ian Jackson wrote:
> See previous bugs
>
> #843248 dpkg-parsechangelog intolerant of unfinalised changelogs
> #849081 dpkg-deb rejects building with unfinalised changeslog
>
> Perhaps there could be a test case ?
>
> (We would have spotted this in our Salsa CI of dgit.git but our CI
> uses testing so it has only broken just now.)
Because this was unintentional, I've prepared a minimal change to
solve this for now, which I'll include in 1.23.8. Change attached.
But…
On Sun, 2026-03-08 at 20:25:21 +, Ian Jackson wrote:
> Consider the changelog below.
>
> This is an "unfinalised changelog". We use this in dgit.git. It has
> the benefit of retaining the release name in the intro line, so that
> it is not possible to accidentally retarget to the wrong release. It
> also avoids having a (wrong) date which needs to be updated.
…while I understand the supposed benefits, this comes with negative
drawbacks. One is that the generated .changes does not contain the
Changed-By field anymore (a field which is currently not marked as
required, but I think that's wrong). It means we cannot enforce failures
for invalid syntax for the changelog (as specified both by
deb-changelog(5) and Debian Policy, "must" clauses), which means any
code that has to deal with changelog files needs to be lenient and
accept invalid stuff, complicating the overall ecosystem.
Because the final distribution is specified (instead of the
convention of using UNRELEASED), such builds could end up being
uploaded into a queue or a repo. I think ideally we'd have a key/value
designating the final target distribution in cases it's not obvious
from the previous entry, something like this made up example (but with
a better key name probably):
source (10.0-1) UNRELEASED; urgency=medium, targets-dist=unstable
For the argument that the date (or even maintainer) information is
wrong, I'd say that easily applies as well to the version, and if the
changelog is being used to build actual packages in the interim, then
there should be something in place. Even though the date could be
synthetized at build time (from the current time) and the maintainer
could be tried to be extracted from DEBFULLNAME/DEBEMAIL or the current
user (or required to be specified with -e), that would still not remove
the problem of letting through invalid syntax that everything else then
needs to cope with. (Also the maintainer could be set to something
that denotes this is a CI build.)
I think that looking at the trailer as containing wrong information is
the wrong way to look into it (given the above), because if one in
addition for example fills in the actual change contents out of git
at release/finalization time, then the entire entry is also wrong or
incomplete until fully finalized, and any such entry is just an interim
placeholder, in which case I'm not seeing what's wrong with having the
person (or some placeholder name) and initial date this was initialized
as such placeholder information.
So I would like to consider how to move into eventually deprecating
this (I'd say unusual and problematic) workflow by adding support to
the common workflow by improving its metadata tracking (such as the
intended dist, or perhaps reverse that and use the actual target dist
but mark it as finalized=no, or whatever).
Thanks,
Guillem
diff --git i/scripts/dpkg-buildpackage.pl w/scripts/dpkg-buildpackage.pl
index 3c8c9ec41..554270c2d 100755
--- i/scripts/dpkg-buildpackage.pl
+++ w/scripts/dpkg-buildpackage.pl
@@ -559,7 +559,7 @@ if ($changedby) {
$maintainer = $changedby;
} elsif ($maint) {
$maintainer = $maint;
-} else {
+} elsif (length $changelog->{maintainer}) {
my $email = mustsetvar($changelog->{maintainer}, g_('source changed by'));
eval {
my $addr = Dpkg::Email::Address->new($email);
diff --git i/scripts/dpkg-genchanges.pl w/scripts/dpkg-genchanges.pl
index 09b88b4be..2b249ae4e 100755
--- i/scripts/dpkg-genchanges.pl
+++ w/scripts/dpkg-genchanges.pl
@@ -439,8 +439,10 @@ foreach my $f (keys %{$changelog}) {
if ($f eq 'Source') {
set_source_name($v);
} elsif ($f eq 'Maintainer') {
-my $addr = Dpkg::Email::Address->new($v);
-$fields->{'Changed-By'} = $addr->as_string();
+if (length $v) {
+my $addr = Dpkg::Email::Address->new($v);
+$fields->{'Changed-By'} = $addr->as_string();
+}
} else {
field_transfer_single($changelog, $fields, $f);
}
Bug#1130119: dpkg-source newly rejects unfinalised changelogs [and 1 more messages]
Control: severity -1 normal Sorry about the severity. I had hoped to stop the regression reaching testing but it turns out it's too late for that, so it probably doesn't make sense to set the severity so high. Ian. -- Ian JacksonThese opinions are my own. Pronouns: they/he. If I emailed you from @fyvzl.net or @evade.org.uk, that is a private address which bypasses my fierce spamfilter.
Bug#1130119: dpkg-source newly rejects unfinalised changelogs [and 1 more messages]
Ian Jackson writes ("dpkg-source newly rejects unfinalised changelogs"):
> $ dpkg-buildpackage -uc -us .
> dpkg-buildpackage: warning: debian/changelog(l5): badly formatted trailer
> line
> LINE: --
> dpkg-buildpackage: warning: debian/changelog(l7): found start of entry
> where expected more change data or trailer
> LINE: dgit (14.11) unstable; urgency=medium
> dpkg-buildpackage: warning: debian/changelog(l7): found end of file where
> expected more change data or trailer
> dpkg-buildpackage: info: source package dgit
> dpkg-buildpackage: info: source version 14.12~
> dpkg-buildpackage: info: source distribution unstable
> dpkg-buildpackage: info: source changed by
> dpkg-buildpackage: error: cannot parse maintainer email address "" from
> changelog entry
> $ echo $?
> 255
> $
See previous bugs
#843248 dpkg-parsechangelog intolerant of unfinalised changelogs
#849081 dpkg-deb rejects building with unfinalised changeslog
Perhaps there could be a test case ?
(We would have spotted this in our Salsa CI of dgit.git but our CI
uses testing so it has only broken just now.)
Thanks,
Ian.
Bug#1130119: dpkg-source newly rejects unfinalised changelogs
Package: dpkg-dev Version: 1.23.7 Severity: serious Justification: regression breaks CI for existing workflows Hi. Consider the changelog below. This is an "unfinalised changelog". We use this in dgit.git. It has the benefit of retaining the release name in the intro line, so that it is not possible to accidentally retarget to the wrong release. It also avoids having a (wrong) date which needs to be updated. dpkg-source now rejects this: $ dpkg-buildpackage -uc -us . dpkg-buildpackage: warning: debian/changelog(l5): badly formatted trailer line LINE: -- dpkg-buildpackage: warning: debian/changelog(l7): found start of entry where expected more change data or trailer LINE: dgit (14.11) unstable; urgency=medium dpkg-buildpackage: warning: debian/changelog(l7): found end of file where expected more change data or trailer dpkg-buildpackage: info: source package dgit dpkg-buildpackage: info: source version 14.12~ dpkg-buildpackage: info: source distribution unstable dpkg-buildpackage: info: source changed by dpkg-buildpackage: error: cannot parse maintainer email address "" from changelog entry $ echo $? 255 $ It works in trixie with 1.22.21. Ian. dgit (14.12~) unstable; urgency=medium * -- dgit (14.11) unstable; urgency=medium tag2upload improvements: * git-debpush: Support --deliberately in git-debpush. Closes: #1127470. * git-debpush, dgit: Provide --untaint-history convenience alias for --deliberately-include-questionable-history. As per #1127470. * Generate our own Message-IDs on the Oracle, and convey them to the Manager via o2m protocol 9. Closes: #1127618. [Reviews and fixes from Sean Whitton] Bugfixes: * tag2upload: Don't sometimes send emails with wrong status in Subject. * tag2upload: Do not include inapplicable retry advice in email reports. * dgit/tag2upload overwrite checks: Do not refer inaccurately to the archive. * dgit/tag2upload: Avoid crashing on some fatal errors due eg to unfinalised changelogs. Closes: #1126152. * dgit rpush: Do print applicable retry advice on early failures. Documentation: * Completely overhaul docs of --deliberately, and error messages. New section in dgit(7) describing tainted history. Closes: #990667, #1127666. [Reports from Osamu Aoki & Simon Josefsson] * dgit(1): Expand xrefs. Closes: #1128591. [Report from Simon Josefsson] * git-debrebase(1): Document --noop-ok for scrap, make-patches. Promptted by #1129577. [Report from Charlemagne Lasse] -- Ian Jackson Sun, 08 Mar 2026 17:06:24 + -- Ian JacksonThese opinions are my own. Pronouns: they/he. If I emailed you from @fyvzl.net or @evade.org.uk, that is a private address which bypasses my fierce spamfilter.
