next changelogs and ppa uploads

Scott Kitterman ubuntu at kitterman.com
Mon Sep 22 12:29:43 UTC 2014


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?  If so, can't you get that 
programmatically from LP?  That would seem even less prone to error.

Scott K



More information about the kubuntu-devel mailing list