next changelogs and ppa uploads

Harald Sitter apachelogger at ubuntu.com
Mon Sep 22 12:36:27 UTC 2014


On Mon, Sep 22, 2014 at 2:29 PM, Scott Kitterman <ubuntu at kitterman.com> wrote:
> On Monday, September 22, 2014 14:18:33 Harald Sitter wrote:
>> On Mon, Sep 22, 2014 at 2:09 PM, Scott Kitterman <ubuntu at kitterman.com>
> wrote:
>> > On Monday, September 22, 2014 13:54:04 Harald Sitter wrote:
>> >> On Mon, Sep 22, 2014 at 1:47 PM, Scott Kitterman <ubuntu at kitterman.com>
>> >
>> > wrote:
>> >> > On Monday, September 22, 2014 13:41:32 Harald Sitter wrote:
>> >> >> On Mon, Sep 22, 2014 at 1:18 PM, Scott Kitterman
>> >> >> <ubuntu at kitterman.com>
>> >> >
>> >> > wrote:
>> >> >> > On Monday, September 22, 2014 12:12:36 Harald Sitter wrote:
>> >> >> >> I'd like to propose that *all* ppa uploads of next workspace get a
>> >> >> >> changelog entry.
>> >> >> >>
>> >> >> >> objections?
>> >> >> >>
>> >> >> >> in fact, what are everyone's thoughts on doing this on general
>> >> >> >> principle and have a script to then compress ppa entries into one
>> >> >> >> version when/if it gets uploaded to the archive?
>> >> >> >>
>> >> >> >> right now its an outright mess as one has to check a notes page or
>> >> >> >> ultimately the ppa to find out what ~ppa version is the latest of a
>> >> >> >> given package, having multiple ppas where things could be doesn't
>> >> >> >> really help either.
>> >> >> >
>> >> >> > Let's see the script that compresses the changelog entries first.  A
>> >> >> > PPA
>> >> >> > upload changelog ought to be uploadable to the archive once the
>> >> >> > ~ppaX
>> >> >> > is
>> >> >> > removed.
>> >> >>
>> >> >> Let's make a decision before we have someone waste their life on it,
>> >> >> shall
>> >> >> we?
>> >> >
>> >> > OK.  Since next workspace is PPA only for some time, I think it's
>> >> > reasonable if there's a script up to when we do the first uploads to
>> >> > the
>> >> > archive, then I think we should do it like other packages where the
>> >> > debian/changelog entries are pre-compacted.
>> >>
>> >> Mhh, how about putting a metadata file in the relevant branches then?
>> >> The file would always contain the latest version.
>> >> cat _ppa_version
>> >>
>> >>   4:5.0.1-0kittens11~spaceships100~ppa6
>> >>
>> >> There's really only those two options IMO. We have to put the data
>> >> somewhere>>
>> >> :S
>> >
>> > I don't think I'm following you.  What goes in this file that's not
>> > already in the changelog?
>>
>> Versions of ppa uploads are not in the changelog. What we are doing is
>> we have a forever unreleased changelog entry for what will eventually
>> go into the archive. The actual versions that are being uploaded to a
>> PPA are not tracked, the ppa-bzr-build-package script temporary merges
>> source and packaging and injects a temporary changelog entry which
>> never ends up in bzr.
>>
>> Since you don't want the PPA versions tracked in the changelog for
>> things that eventually go to the archive we have to put the
>> information somewhere.
>>
>> Concrete example: earlier I changed the plasma5 systemsettings package
>> and needed to lookup the version that is our latest PPA upload. So I
>> went to the next ppa, which had 5.0.1, while the changelog had 5.0.2
>> (that already required me as faulty human to realize that), so I had
>> to go to next-staging find systemsettings, filter a bit and finally I
>> found the correct version.
>> In fact this is even an even more general problem for ppa uploads, if
>> I fix something in a PPA-only package version (e.g. a backport) I need
>> to know the previous ppa version in order to generate a new upload,
>> currently this involves a human somehow finding out what the previous
>> upload was.
>
> Is it just the latest version number in the PPA?

Yes.

>  If so, can't you get that
> programmatically from LP?

Yes

>  That would seem even less prone to error.

Besides random timeouts for no good reason, keyring unlocking queries,
connection resets and the fact that one would have to query multiple
PPAs with >100 sources each, sure. ;)

(yes, I have done too much launchpad scripting)

HS



More information about the kubuntu-devel mailing list