Russ Allbery 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 wishlist b
Cyril Brulebois writes:
> Ben Finney (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
Neil Williams (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
(finally!) satisfied wit
Ben Finney (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 of view:)
Well, you uplo
Ben Finney (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 are some archs out of
sync)
Paul Wise (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
Description: Digital s
2009/1/19 Ben Finney :
> Piotr Ożarowski 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
>> All I want is to be able to depend o
Piotr Ożarowski writes:
> 2009/1/19 Ben Finney :
> > 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 mentors.debian.net?
>
> last
2009/1/19 Ben Finney :
> Piotr Ożarowski 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"
Neil Williams writes:
> On Mon, 19 Jan 2009 20:54:04 +1100
> Ben Finney wrote:
>
> > Neil Williams 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.
> >
> > A
Piotr Ożarowski 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 “UNRELEASED” sui
Hello,
On Mon, Jan 19, 2009 at 12:59, Ben Finney wrote:
> Sandro Tosi writes:
>> On Mon, Jan 19, 2009 at 12:16, George Danchev wrote:
>> > My context analyzer claims [1] that what Ben wrote was more like
>> > question (though the question mark and interrogative form were
>> > missing;-), rather
Sandro Tosi writes:
> Hello,
>
> On Mon, Jan 19, 2009 at 12:16, George Danchev 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.
>
> Well, the way he wrote (a
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 releases
Hello,
On Mon, Jan 19, 2009 at 12:16, George Danchev wrote:
> Quoting Sandro Tosi :
>> On Mon, Jan 19, 2009 at 02:59, Ben Finney
>> 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
>>> spo
Quoting Sandro Tosi :
On Mon, Jan 19, 2009 at 02:59, Ben Finney 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
On Mon, Jan 19, 2009 at 02:59, Ben Finney 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 and make a
On Mon, 19 Jan 2009 20:54:04 +1100
Ben Finney wrote:
> Neil Williams 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; fo
Neil Williams 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 actually-gets-to-D
On Mon, Jan 19, 2009 at 06:06:20AM +, Sune Vuorela wrote:
> On 2009-01-19, Ben Finney 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 pr
On Mon, 19 Jan 2009 17:07:00 +1100
Ben Finney wrote:
> Russ Allbery writes:
>
> > Ben Finney 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’ e
On Mon, 19 Jan 2009 12:59:15 +1100
Ben Finney 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:
>
> * When a bug is
"Paul Wise" writes:
> On Mon, Jan 19, 2009 at 5:40 PM, Ben Finney
> 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
On Mon, Jan 19, 2009 at 5:40 PM, Ben Finney 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 commands to build it?
As
"Paul Wise" writes:
> On Mon, Jan 19, 2009 at 5:07 PM, Ben Finney
> 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
Ben Finney 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 my packages, but you c
On Mon, Jan 19, 2009 at 5:07 PM, Ben Finney 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 build?
Maybe add some s
Russ Allbery writes:
> Ben Finney 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 under
On 2009-01-19, Ben Finney 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 and make a new changelog
Ben Finney 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 “include all entries newer
>
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
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: bug#N
32 matches
Mail list logo
