Re: Closing bugs, incrementing release number, and uploads to mentors.debian.net

[Russ Allbery]

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 there are some archs out of
> sync), e.g.:
> | $ rmadison --suite unstable guile-1.6
> |  guile-1.6 |1.6.8-6 |  unstable | hppa, m68k, sparc
> |  guile-1.6 |  1.6.8-6.1 |  unstable | source, alpha, amd64, arm, armel, 
> hurd-i386, i386, ia64, mips, mipsel, powerpc, s390

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 bug against devscripts
with the final version of the code?

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Closing bugs, incrementing release number, and uploads to mentors.debian.net

[Cyril Brulebois]

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 with a package that needed more than a second
iteration (see Ben's remark in another subthread).

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: Closing bugs, incrementing release number, and uploads to mentors.debian.net

[Cyril Brulebois]

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 upload a source package. Even if they wanted to, sponsors
can't sign the _source.changes (which is what contains Closes et al.)
and upload it as is, they have to build (at least) a binary, otherwise
dak's going to reject the upload (and I'm sure _source.changes are
available from mentors.d.n, though I didn't check).

(One may suggest they could build the binary-only part and use
mergechanges, but…)

Which means that indeed, it's the sponsors' “responsibility” to use a
proper -v when needed.

> Now that I better understand how that all happens, I will communicate
> with sponsors explicitly about this for future package releases, and
> find out how they want to proceed.

I think that's a good idea, yes.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: Closing bugs, incrementing release number, and uploads to mentors.debian.net

[Cyril Brulebois]

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), e.g.:
| $ rmadison --suite unstable guile-1.6
|  guile-1.6 |1.6.8-6 |  unstable | hppa, m68k, sparc
|  guile-1.6 |  1.6.8-6.1 |  unstable | source, alpha, amd64, arm, armel, 
hurd-i386, i386, ia64, mips, mipsel, powerpc, s390

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: Closing bugs, incrementing release number, and uploads to mentors.debian.net

[Cyril Brulebois]

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 signature

Re: Closing bugs, incrementing release number, and uploads to mentors.debian.net

[Piotr Ożarowski]

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 on
>> /usr/share/doc/*/changelog.Debian.gz data while deciding what
>> minimum required version should I use in Depends (I don't want to
>> check http://lists.debian.org/debian-devel-changes archives, see
>> mentioned bug reports)
>
> Doesn't the availability of the 'rmadison' tool make that trivial for
> the sponsor, without needing to alter already-uploaded changelog
> entries?

while sponsoring I'm checking debdiff output with last uploaded
version, so I don't need rmadison to tell which one is uploaded and
which one isn't. I'm thinking about other developers who want to use
your package as a dependency in their own package.


--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Closing bugs, incrementing release number, and uploads to mentors.debian.net

[Ben Finney]

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 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?
I thought that was quite frowned upon.

> All I want is to be able to depend on
> /usr/share/doc/*/changelog.Debian.gz data while deciding what
> minimum required version should I use in Depends (I don't want to
> check http://lists.debian.org/debian-devel-changes archives, see
> mentioned bug reports)

Doesn't the availability of the ‘rmadison’ tool make that trivial for
the sponsor, without needing to alter already-uploaded changelog
entries?

-- 
 \   “I bought some powdered water, but I don't know what to add.” |
  `\—Steven Wright |
_o__)  |
Ben Finney


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Closing bugs, incrementing release number, and uploads to mentors.debian.net

[Piotr Ożarowski]

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"). Why would the "UNRELEASED" suite survive to be
> uploaded, even to mentors.debian.net?

last revision (the one you intend to upload) should not be marked as
UNRELEASED of course, only previous attempts should be
(i.e. versions > last_uploaded_version and < last_version).
All I want is to be able to depend on /usr/share/doc/*/changelog.Debian.gz
data while deciding what minimum required version should I use in Depends
(I don't want to check http://lists.debian.org/debian-devel-changes
archives, see
mentioned bug reports)


--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Closing bugs, incrementing release number, and uploads to mentors.debian.net

[Ben Finney]

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.
> > 
> > Ah okay. I've never had a sponsor do that; following your advice
> > with multiple releases between actually-gets-to-Debian releases,
> > I've only ever seen the latest changelog entry in the upload.
> 
> Take a look at some of the ACCEPTED messages for emdebian-tools […]
> The interim versions, with all their bug closure entries, then get
> merged into a single .changes file (preserved within the ACCEPTED
> messages in the PTS) that covers all changes since the last version
> in Debian. OK, sometimes I forget but then it's my fault and my
> problem.

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).

I was pointing out that, though I've followed the advice to increment
the release number when I release — because I find that practice
sensible — I've never had sponsored packages contain anything but the
single latest changelog entry appear in the changes file.

I presume that this means your requirement, that a new release from
the maintainer needs a new release number, is not widely followed or
even well known among sponsors.

Now that I better understand how that all happens, I will communicate
with sponsors explicitly about this for future package releases, and
find out how they want to proceed.

-- 
 \  “I busted a mirror and got seven years bad luck, but my lawyer |
  `\thinks he can get me five.” —Steven Wright |
_o__)  |
Ben Finney


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Closing bugs, incrementing release number, and uploads to mentors.debian.net

[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”). Why would the “UNRELEASED” suite survive to be
uploaded, even to mentors.debian.net?

-- 
 \  “When we call others dogmatic, what we really object to is |
  `\   their holding dogmas that are different from our own.” —Charles |
_o__)   Issawi |
Ben Finney


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Closing bugs, incrementing release number, and uploads to mentors.debian.net

[Sandro Tosi]

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 than a ironed rule.
>>
>> Well, the way he wrote (and he is usually very careful at writing)
>> it seems like a preamble for the real question.
>
> Perhaps " I'd like to know that I'm wrong, or that I'm right but
> there is a way to get around it." was not clear enough?

Ok about this particular aspect, there are some sponsors that require
the have a new revision each "iteration" (sponsoree RFS, sponsor
replies, sponsoree needs to do changes to package), others that do not
want this, others that adapt to both situations.

So you're wrong thinking this is a general recommendation or wide used
(something like a "should" or "must"), but you're right thinking it's
a recommendations sometimes done, that you might *consider* doing as
long as your sponsor agrees

Cheers,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Closing bugs, incrementing release number, and uploads to mentors.debian.net

[Ben Finney]

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 (and he is usually very careful at writing)
> it seems like a preamble for the real question.

Perhaps “ I'd like to know that I'm wrong, or that I'm right but
there is a way to get around it.” was not clear enough?

-- 
 \   “Value your freedom or you will lose it, teaches history. |
  `\ “Don't bother us with politics,” respond those who don't want |
_o__)   to learn.” —Richard Stallman, 2002 |
Ben Finney


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Closing bugs, incrementing release number, and uploads to mentors.debian.net

[Piotr Ożarowski]

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)


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Closing bugs, incrementing release number, and uploads to mentors.debian.net

[Sandro Tosi]

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
>>>  sponsor requires further changes), recommended practice is to
>>>  increment the release number and make a new changelog entry, to
>>>  easily distinguish from any existing release.
>>
>> This is only required by *SOME* sponsors, and I absolutely *DO NOT
>> WANT* this from my sponsorees; so please stop (target is everyone)
>> spread mis-information to people approaching Debian since few time,
>> like it's a "project requirement" when it is not.
>
> Sandro ;-)
>
> 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 (and he is usually very careful at writing) it
seems like a preamble for the real question.

> Should we leave that to the sponsoree's discretion, and live in peace? ;-)
> Does anybody see any flaws with that?

This is perfectly fine (for me and for you, and many others) but what
about the "newbie" (no negative aspect here) that reads this? He can
think that this is the right way to do, while it is not, or better is
*another* way of doing things, both being technically correct.

To express a suggestions, there are many ways, like "IMHO", "Many
sponsors prefers to", "it seems that  is wide used". For
example, many times I've encouraged to use the new copyright format
(while I don't use it since I consider it overkilling) because there
are some that prefers it (and maybe the sponsorees to).

NOTE: this was not a personal attack or way, just a head-up about that
sponsorees may not have yet the judgement about what is correct,
what's wrong, what has different ways to be accomplished, and hence
it's the sponsor (and -mentor) task to provide such knowledge (and
sponsorees to document about it :) ).

Cheers,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Closing bugs, incrementing release number, and uploads to mentors.debian.net

[George Danchev]

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 number and make a new changelog entry, to
 easily distinguish from any existing release.


This is only required by *SOME* sponsors, and I absolutely *DO NOT
WANT* this from my sponsorees; so please stop (target is everyone)
spread mis-information to people approaching Debian since few time,
like it's a "project requirement" when it is not.


Sandro ;-)

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.


Should we leave that to the sponsoree's discretion, and live in peace?  
;-) Does anybody see any flaws with that?


[1] citing him: "As I understand it..."



--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Closing bugs, incrementing release number, and uploads to mentors.debian.net

[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 number and make a new changelog entry, to
>  easily distinguish from any existing release.

This is only required by *SOME* sponsors, and I absolutely *DO NOT
WANT* this from my sponsorees; so please stop (target is everyone)
spread mis-information to people approaching Debian since few time,
like it's a "project requirement" when it is not.

Regards,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Closing bugs, incrementing release number, and uploads to mentors.debian.net

[Neil Williams]

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; following your advice with
> multiple releases between actually-gets-to-Debian releases, I've only
> ever seen the latest changelog entry in the upload.

Take a look at some of the ACCEPTED messages for emdebian-tools - I use
www.emdebian.org in the same manner as I require maintainers to use
mentors.debian.net - I upload interim versions when Debian is in
transition or in freeze. The interim versions, with all their bug
closure entries, then get merged into a single .changes file (preserved
within the ACCEPTED messages in the PTS) that covers all changes since
the last version in Debian. OK, sometimes I forget but then it's my
fault and my problem.

Compare:
http://packages.debian.org/changelogs/pool/main/e/emdebian-tools/current/changelog
(the actual changelog, including all interim releases)
and
http://packages.qa.debian.org/e/emdebian-tools.html

Possibly the clearest example is:
http://packages.qa.debian.org/e/emdebian-tools/news/20080411T191703Z.html

In general, emdebian-tools x.x.0 is a Debian upload (barring exceptions
like RC bugs or urgent Debian fixes) and x.x.x is an Emdebian upload,
so 1.3.0 went to Debian, 1.3.1 went to Emdebian whilst waiting for
1.3.0 to migrate into testing and 1.4.0 went back into Debian. The
current release is 1.4.15 and the next Debian upload will be 1.5.0,
including all the changes since 1.4.3. Outside a release freeze, I
normally only have two or three interim releases during the time the
package is waiting to migrate into testing. I generally make a release
of emdebian-tools about three times a month - longer when larger
transitions are occurring within the package (as is the case now). I
have been known to make releases of emdebian-tools on four consecutive
days, fixing different issues in different parts of the package.

$ parsechangelog -v1.4.3|wc -l
340

:-)

$ parsechangelog |wc -l
39

$ parsechangelog -v1.4.3|grep Closes
Closes: 497816 498495 507285 507686 510521 512016

$ parsechangelog |grep Closes
Closes: 512016

(Should have mentioned too, dpkg-buildpackage -v just passes the
relevant version string to the underlying parsechangelog code that is
then used by dpkg-genchanges to produce the .changes file. Whatever
changelog you can generate with dpkg-buildpackage -v you can preview
with parsechangelog -v).

> What does this mean? Should I be refraining from your advice on
> release number increments, or teaching my sponsors how to sponsor
> better?

It means that you follow the requirements of the sponsor who has agreed
to review and upload the package. It's not up to anyone to "teach other
sponsors", we have our preferred ways of working and our own reasons
for those methods - typically around ensuring that sponsoring does not
interrupt existing workflow patterns. (Sponsors have a lot of other
stuff to do and there are many, many things in Debian where various
DD's have significantly different ways of doing things.) Debian may
seem to have a lot of standards and rules but there is a lot of
variation in the areas where Policy allows choice.

If your sponsor hasn't made it clear which methods and requirements
they prefer, ask. I've tried to make my own criteria clear.

(The page has been updated with the latest changes mentioned on the
list today too.)

-- 


Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/



pgpSYyhn9TMLy.pgp
Description: PGP signature

Re: Closing bugs, incrementing release number, and uploads to mentors.debian.net

[Ben Finney]

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-Debian releases, I've only
ever seen the latest changelog entry in the upload.

What does this mean? Should I be refraining from your advice on
release number increments, or teaching my sponsors how to sponsor
better?

-- 
 \ “If life deals you lemons, why not go kill someone with the |
  `\ lemons (maybe by shoving them down his throat).” —Jack Handey |
_o__)  |
Ben Finney


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Closing bugs, incrementing release number, and uploads to mentors.debian.net

[Martin Meredith]

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 practice is to
> >   increment the release number and make a new changelog entry, to
> >   easily distinguish from any existing release.
> 
> This is afaik only recommended if you want Neil Williams to sponsor you.
> 
> If someone is working with me, this is absolutely *not* recommended.

I was just reading through this, and was thinking "I've never done that before, 
nor have any of my sponsors asked me to do it either"

I've never actually seen this practice. For me, a version bump should only be 
made for uploads that actually go into Debian.

If/when I'm working with anyone as a sponsor, and they do this, It'll be sent 
back to them to change the version number to correspond with the debian 
release. 
Mentors.debian.net is just a holding ground IMO.


signature.asc
Description: Digital signature

Re: Closing bugs, incrementing release number, and uploads to mentors.debian.net

[Neil Williams]

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’ etc.) Is there a normal way to
> > > have ‘dpkg-genchanges’ always understand “include all entries newer
> > > than what's currently in Debian”?
> > 
> > Most of the helpers that sit in front of dpkg-buildpackage will pass the
> > -v option all the way through or have some way of doing so, probably for
> > precisely this reason.
> 
> 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?

The maintainer doesn't have to worry about -v - the sponsor does that
with the final build that actually gets uploaded to Debian. (Remember,
the sponsor always uploads a local build, hence why mentors always
needs the location of the .dsc, not the .debs)

I'll add some docs on that to my sponsoring page later.

-- 


Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/



pgpD9GZB8U6OP.pgp
Description: PGP signature

Re: Closing bugs, incrementing release number, and uploads to mentors.debian.net

[Neil Williams]

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 fixed in a new release, recommended practice is to put
>   a “Closes: bug#NNN” in the changelog at that specific release
>   entry.
> 
> * 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 entry, to
>   easily distinguish from any existing release.
> 
> * When packages are created by ‘dpkg-buildpackage’, the ‘*_changes’
>   files by default contain only changes from the latest entry in the
>   changelog.

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.


-- 


Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/



pgpCNnK3Zu4oi.pgp
Description: PGP signature

Re: Closing bugs, incrementing release number, and uploads to mentors.debian.net

[Ben Finney]

"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* issuing the commands to build it?
> 
> As a sponsor, usually I would do stuff like this:
> 
> dget http://mentors.foo...-3.dsc

My question was relating to building the source package in the first
place; i.e. to invoke ‘dpkg-genchanges’ with the appropriate ‘-v’
argument when building it. Hence, no ‘foo.dsc’ file exists yet at that
point.

It looks like ‘rmadison’ is the key to what I want to do. Here's a
first cut at getting the appropriate ‘-v’ option automatically:

= $HOME/.devscripts =
# Get the latest version of current package in Debian archives
latest_debian_version=$(dlatest)

# Options to pass to dpkg-buildpackage
genchanges_opts="-v${latest_debian_version}"

DEBUILD_DPKG_BUILDPACKAGE_OPTS="${diff_ignore_opts} ${tar_ignore_opts} 
${genchanges_opts}"
=

= $HOME/bin/dlatest =
set -o errexit

packagename=$(parsechangelog | grep '^Source:' | cut -d' ' -f 2)
suitename=$(parsechangelog | grep '^Distribution:' | cut -d' ' -f 2)
latest_debian_version=$(rmadison --suite ${suitename} ${packagename} \
| cut -d'|' -f 2 | sed -e 's/^[[:space:]]+//')

echo "${latest_debian_version}"
=

-- 
 \  “If we have to give up either religion or education, we should |
  `\  give up education.” —William Jennings Bryan, 1923-01 |
_o__)  |
Ben Finney


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Closing bugs, incrementing release number, and uploads to mentors.debian.net

[Paul Wise]

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 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

cd foo...
less `find debian`

pdebuild + lintian/etc

debsign
debrelease
barf mail to -mentors

You can also replace 'remember -v...' with 'forget to add -v...' :)

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Closing bugs, incrementing release number, and uploads to mentors.debian.net

[Ben Finney]

"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 release and build?
> 
> Maybe add some script using rmadison/etc to ~/.devscripts that adds
> to DEBUILD_DPKG_BUILDPACKAGE_OPTS?
> 
> That would be the lazy way

Thanks, I wasn't aware of ‘rmadison’, I'm reading the man page now.

> 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?

-- 
 \   “We must respect the other fellow's religion, but only in the |
  `\   sense and to the extent that we respect his theory that his |
_o__) wife is beautiful and his children smart.” —Henry L. Mencken |
Ben Finney


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Closing bugs, incrementing release number, and uploads to mentors.debian.net

[Russ Allbery]

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 could script something
fairly easily via a wrapper around whatever package building tool that you
use.  Something like:

#!/bin/sh
set -e
package=`dpkg-parsechangelog | grep ^Source: | cut -f 2 -d ' '`
current=`apt-cache showsrc "$package" | grep ^Version: | cut -f 2 -d ' ' \
| sort -r | head -n 1`
if [ -n "$current" ] ; then
git-buildpackage -v"$current" "$@"
else
git-buildpackage -v0 "$@"
fi

This assumes apt-cache showsrc will find packages in unstable and
experimental.  If it won't, you may have to do something more complicated
(grep-dctrl would probably help).

The sort there isn't entirely correct; you really want to do a dpkg
version comparison.

-- 
Russ Allbery (r...@debian.org)   


--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Closing bugs, incrementing release number, and uploads to mentors.debian.net

[Paul Wise]

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 script using rmadison/etc to ~/.devscripts that adds to
DEBUILD_DPKG_BUILDPACKAGE_OPTS?

That would be the lazy way; usually you would remember because you'd
debdiff and interdiff against the .deb and .diff.gz in the archive.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Closing bugs, incrementing release number, and uploads to mentors.debian.net

[Ben Finney]

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 understand “include all entries newer
> > than what's currently in Debian”?
> 
> Most of the helpers that sit in front of dpkg-buildpackage will pass the
> -v option all the way through or have some way of doing so, probably for
> precisely this reason.

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?

-- 
 \   “Always do right. This will gratify some people, and astonish |
  `\the rest.” —Mark Twain |
_o__)  |
Ben Finney


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Closing bugs, incrementing release number, and uploads to mentors.debian.net

[Sune Vuorela]

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 entry, to
>   easily distinguish from any existing release.

This is afaik only recommended if you want Neil Williams to sponsor you.

If someone is working with me, this is absolutely *not* recommended.

/Sune


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Closing bugs, incrementing release number, and uploads to mentors.debian.net

[Russ Allbery]

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
> than what's currently in Debian”?

Most of the helpers that sit in front of dpkg-buildpackage will pass the
-v option all the way through or have some way of doing so, probably for
precisely this reason.  git-buildpackage passes all unknown options to
debuild, for example, which then passes it along to dpkg-buildpackage and
from there to dpkg-genchanges.

-- 
Russ Allbery (r...@debian.org)   


--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Closing bugs, incrementing release number, and uploads to mentors.debian.net

[Kapil Hari Paranjape]

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 versions succeeding  mmm.nnn-qqq get included in the
changes file.

Kapil.
--



signature.asc
Description: Digital signature