dlatest: Query the Debian archive for the latest available version of the package (was: Closing bugs, incrementing release number, and uploads to mentors.debian.net)
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 wishlist bug against devscripts with the final version of the code? The program is done to my satisfaction now, and a bug report filed URL:http://bugs.debian.org/517962. -- \ “Generally speaking, the errors in religion are dangerous; | `\those in philosophy only ridiculous.” —David Hume, _A Treatise | _o__) of Human Nature_, 1739 | 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
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 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) http://www.eyrie.org/~eagle/
--
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 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
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
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: * 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
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 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
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 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 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 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
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. 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
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 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
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), 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
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 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 this 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
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 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. 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
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 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
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 “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
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 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
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 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
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 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
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 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
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
Description: Digital signature
Re: Closing bugs, incrementing release number, and uploads to mentors.debian.net
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 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
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 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
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 (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
Closing bugs, incrementing release number, and uploads to mentors.debian.net
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. So the conflict is that a bug fixed and marked as closed in the changelog will *not* be found by the automated changelog parser (what's the name of this process?) in the case when the bug was fixed in a release that didn't actually make it into Debian. For example: if package ‘foo’ at version ‘1.0-1’ exists in Debian, and then a new version makes its way into Debian with the following changelog: foo (2.0-2) unstable; urgency=low * Fixed bad debian/copyright; thanks to Boris Sponsor. -- Arthur Hacker art...@example.org Tue, 03 Jan 2300 18:47:31 +1100 foo (2.0-1) unstable; urgency=low * New upstream release (closes: bug#98765432). -- Arthur Hacker art...@example.org Mon, 02 Jan 2300 07:52:04 +1100 foo (1.0-1) unstable; urgency=low * Initial Debian packaging (closes: bug#9864264). -- Arthur Hacker art...@example.org Wed, 10 Nov 2298 07:52:04 +1100 When this changelog is processed by a default ‘dpkg-genchanges’ as part of building the package, only the last entry (for version ‘2.0-2’) will be output. But there are *two* new releases in the changelog since version ‘1.0-1’. The entry for ‘2.0-1’ never gets examined for closed bugs. Should it be normal, then, to always specify arguments to ‘dpkg-genchanges’ manually to specify which entries from the changelog to include? 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”? -- \ “Progress might have been all right once, but it's gone on too | `\long.” —Ogden Nash | _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
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
Re: Closing bugs, incrementing release number, and uploads to mentors.debian.net
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 “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) http://www.eyrie.org/~eagle/ -- 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
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 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 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 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
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 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 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 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) http://www.eyrie.org/~eagle/ -- 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 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 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
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 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 notice multiple changelog entries, remember -v... for later cd foo... less `find debian` more source package review here pdebuild + lintian/etc binary package review here 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
