Russ Allbery r...@debian.org writes:
It would be great to get this into debuild as an option, so that you
could pass it some flag and it would do this work to figure out the
last Debian version and include all the changelog entries to that
point.
Maybe someone (Ben, perhaps?) could open a
Cyril Brulebois k...@debian.org writes:
Ben Finney ben+deb...@benfinney.id.au (19/01/2009):
latest_debian_version=$(rmadison --suite ${suitename} ${packagename} \
| cut -d'|' -f 2 | sed -e 's/^[[:space:]]+//')
Beware, you need to limit that to the source (in case there's a binary
built
Paul Wise p...@debian.org writes:
On Mon, Jan 19, 2009 at 5:40 PM, Ben Finney ben+deb...@benfinney.id.au
wrote:
usually you would remember because you'd debdiff and interdiff
against the .deb and .diff.gz in the archive.
How will those help me to get information about the package I'm
On Mon, 19 Jan 2009 12:59:15 +1100
Ben Finney ben+deb...@benfinney.id.au wrote:
Howdy all,
I see a conflict in the workflow of bug fixing and packaging. I'd like
to know that I'm wrong, or that I'm right but there is a way to get
around it.
As I understand it, the following facts hold:
On Mon, 19 Jan 2009 17:07:00 +1100
Ben Finney ben+deb...@benfinney.id.au wrote:
Russ Allbery r...@debian.org writes:
Ben Finney ben+deb...@benfinney.id.au writes:
I never invoke ‘dpkg-genchanges’ manually; that's done by
‘dpkg-buildpackage’, which in turn is usually invoked by
On Mon, Jan 19, 2009 at 06:06:20AM +, Sune Vuorela wrote:
On 2009-01-19, Ben Finney ben+deb...@benfinney.id.au wrote:
* When fixing bugs that prevented a previous release (e.g. one made to
mentors.debian.net) from making it into Debian (e.g. because the
sponsor requires further
Neil Williams codeh...@debian.org writes:
The maintainer doesn't have to worry about -v [for
‘dpkg-genchanges’] - the sponsor does that with the final build that
actually gets uploaded to Debian.
Ah okay. I've never had a sponsor do that; following your advice with
multiple releases between
On Mon, 19 Jan 2009 20:54:04 +1100
Ben Finney ben+deb...@benfinney.id.au wrote:
Neil Williams codeh...@debian.org writes:
The maintainer doesn't have to worry about -v [for
‘dpkg-genchanges’] - the sponsor does that with the final build that
actually gets uploaded to Debian.
Ah okay.
On Mon, Jan 19, 2009 at 02:59, Ben Finney ben+deb...@benfinney.id.au wrote:
* When fixing bugs that prevented a previous release (e.g. one made to
mentors.debian.net) from making it into Debian (e.g. because the
sponsor requires further changes), recommended practice is to
increment the
Quoting Sandro Tosi mo...@debian.org:
On Mon, Jan 19, 2009 at 02:59, Ben Finney ben+deb...@benfinney.id.au wrote:
* When fixing bugs that prevented a previous release (e.g. one made to
mentors.debian.net) from making it into Debian (e.g. because the
sponsor requires further changes),
Hello,
On Mon, Jan 19, 2009 at 12:16, George Danchev danc...@spnet.net wrote:
Quoting Sandro Tosi mo...@debian.org:
On Mon, Jan 19, 2009 at 02:59, Ben Finney ben+deb...@benfinney.id.au
wrote:
* When fixing bugs that prevented a previous release (e.g. one made to
mentors.debian.net) from
Since #389199 (and #386354) I strongly recommend to mark all
unreleased versions as UNRELEASED
FTR: I accept packages (changelogs) with unreleased versions *only* if
these versions are marked as UNRELEASED in distribution field (or
contain non-Debian distribution names, think: f.e. Ubuntu
Sandro Tosi mo...@debian.org writes:
Hello,
On Mon, Jan 19, 2009 at 12:16, George Danchev danc...@spnet.net wrote:
My context analyzer claims [1] that what Ben wrote was more like
question (though the question mark and interrogative form were
missing;-), rather than a ironed rule.
Hello,
On Mon, Jan 19, 2009 at 12:59, Ben Finney ben+deb...@benfinney.id.au wrote:
Sandro Tosi mo...@debian.org writes:
On Mon, Jan 19, 2009 at 12:16, George Danchev danc...@spnet.net wrote:
My context analyzer claims [1] that what Ben wrote was more like
question (though the question mark
Piotr Ożarowski pi...@debian.org writes:
Since #389199 (and #386354) I strongly recommend to mark all
unreleased versions as UNRELEASED
I do. However, I only upload when I release it, so at that point it's
not unreleased any more, and I change the suite (usually to
“unstable”). Why would the
Neil Williams codeh...@debian.org writes:
On Mon, 19 Jan 2009 20:54:04 +1100
Ben Finney ben+deb...@benfinney.id.au wrote:
Neil Williams codeh...@debian.org writes:
The maintainer doesn't have to worry about -v [for
‘dpkg-genchanges’] - the sponsor does that with the final build
2009/1/19 Ben Finney ben+deb...@benfinney.id.au:
Piotr Ożarowski pi...@debian.org writes:
Since #389199 (and #386354) I strongly recommend to mark all
unreleased versions as UNRELEASED
I do. However, I only upload when I release it, so at that point it's
not unreleased any more, and I change
Piotr Ożarowski pi...@debian.org writes:
2009/1/19 Ben Finney ben+deb...@benfinney.id.au:
However, I only upload when I release it, so at that point it's
not unreleased any more, and I change the suite (usually to
unstable). Why would the UNRELEASED suite survive to be
uploaded, even to
2009/1/19 Ben Finney ben+deb...@benfinney.id.au:
Piotr Ożarowski pi...@debian.org writes:
last revision (the one you intend to upload) should not be marked as
UNRELEASED of course, only previous attempts should be
So you're advocating to change the previous entries in the changelog?
yes
Paul Wise p...@debian.org (19/01/2009):
As a sponsor, usually I would do stuff like this:
dget http://mentors.foo...-3.dsc
apt-get source foo
interdiff -z -p1 foo...-1.diff.gz foo...-3.diff.gz | less
Why aren't you using “debdiff foo*-{1,2}.dsc”?
Mraw,
KiBi.
signature.asc
Ben Finney ben+deb...@benfinney.id.au (19/01/2009):
latest_debian_version=$(rmadison --suite ${suitename} ${packagename} \
| cut -d'|' -f 2 | sed -e 's/^[[:space:]]+//')
Beware, you need to limit that to the source (in case there's a binary
built that has the same name, and in case there
Ben Finney ben+deb...@benfinney.id.au (19/01/2009):
Yes, that's exactly what I was hoping to get from my packages (and
thought it was my responsibility to do so; I wasn't fully aware that
the sponsor re-builds the package and uploads the result).
(Just for completeness, from a pratical point
Neil Williams codeh...@debian.org (19/01/2009):
It is simple to pass the -v option to dpkg-buildpackage and then dpkg
includes all the changes since the specified -v into the .changes file
and the bugs get closed just fine.
It is very simple to overlook/forget about passing once one is
Howdy all,
I see a conflict in the workflow of bug fixing and packaging. I'd like
to know that I'm wrong, or that I'm right but there is a way to get
around it.
As I understand it, the following facts hold:
* When a bug is fixed in a new release, recommended practice is to put
a “Closes:
Hello,
On Mon, 19 Jan 2009, Ben Finney wrote:
* When packages are created by ‘dpkg-buildpackage’, the ‘*_changes’
files by default contain only changes from the latest entry in the
changelog.
By default, yes. However, there is the -vmmm.nnn-qqq option which makes the
changelog of all
Ben Finney ben+deb...@benfinney.id.au writes:
I never invoke ‘dpkg-genchanges’ manually; that's done by
‘dpkg-buildpackage’, which in turn is usually invoked by something else
(e.g. ‘pbuilder’ or ‘bzr-buildpackage’ etc.) Is there a normal way to
have ‘dpkg-genchanges’ always understand
On 2009-01-19, Ben Finney ben+deb...@benfinney.id.au wrote:
* When fixing bugs that prevented a previous release (e.g. one made to
mentors.debian.net) from making it into Debian (e.g. because the
sponsor requires further changes), recommended practice is to
increment the release number
Russ Allbery r...@debian.org writes:
Ben Finney ben+deb...@benfinney.id.au writes:
I never invoke ‘dpkg-genchanges’ manually; that's done by
‘dpkg-buildpackage’, which in turn is usually invoked by something else
(e.g. ‘pbuilder’ or ‘bzr-buildpackage’ etc.) Is there a normal way to
On Mon, Jan 19, 2009 at 5:07 PM, Ben Finney ben+deb...@benfinney.id.au wrote:
Okay. So is there a normal way to have the '-v' option during a run
set to include all entries newer than what's currently in Debian?
Or do I have to remember to set it manually each time I add a new
release and
Ben Finney ben+deb...@benfinney.id.au writes:
Okay. So is there a normal way to have the ‘-v’ option during a run set
to “include all entries newer than what's currently in Debian”? Or do
I have to remember to set it manually each time I add a new release and
build?
I have to look it up for
Paul Wise p...@debian.org writes:
On Mon, Jan 19, 2009 at 5:07 PM, Ben Finney ben+deb...@benfinney.id.au
wrote:
Okay. So is there a normal way to have the '-v' option during a
run set to include all entries newer than what's currently in
Debian? Or do I have to remember to set it
On Mon, Jan 19, 2009 at 5:40 PM, Ben Finney ben+deb...@benfinney.id.au wrote:
usually you would remember because you'd debdiff and interdiff
against the .deb and .diff.gz in the archive.
How will those help me to get information about the package I'm about
to build *before* issuing the
32 matches
Mail list logo
