[03:30] <sethj> Due to a versioning error on my part when I try to upload an updated package to my PPA launchpad rejects it because a source file in PPA already has that version number. I deleted the affected packages but I'm still receiving the error. Do I need to do something else, or just wait longer?
[03:37] <wgrant> sethj: You can't change the contents of a package without also changing the version.
[03:37] <wgrant> You will need to increment the version number.
[03:38] <sethj> grr, the new version is correct, the old one was wrong :(
[03:40] <sethj> wgrant, would it be possible to delete the PPA and then reopen it with the same name and then upload?
[03:40] <wgrant> sethj: You could, but version numbers are cheap...
[03:40] <sethj> At this point that would (potentially) be easier than repackaging with an incrementing version number.. (unless I'm missing an easy way to rename the source file)
[03:40] <wgrant> mv
[03:40] <sethj> wgrant, the problem is it isn't my software, so that's not exactly my choice.
[03:40] <wgrant> What's the difficulty?
[03:41] <wgrant> It's the version number in the packaging that's the problem.
[03:41] <sethj> well I was thinking bzr would throw a fit if I just used mv.
[03:41] <wgrant> The package management system doesn't care what the software calls itself.
[03:41] <sethj> I realize that.
[03:41] <sethj> Maybe I'm too picky.
[03:41] <wgrant> bzr doesn't track the tarball in any version control scheme that I know of.
[03:41] <sethj> ah, cool then.
[03:41] <wgrant> mv foo_1.2.3.orig.tar.gz foo_1.2.3+really.orig.tar.gz
[03:41] <wgrant> dch -e, fix the version from 1.2.3-1 to 1.2.3+really-1
[03:42] <wgrant> That should be all you need.
[03:44] <sethj> That didn't work.
[03:44] <sethj> You see
[03:45] <sethj> Everything but the .orig.tar.gz files are package_2.1-0ubuntu1 (the PPA has 0ubuntu0), it's the orig.tar.gz file that is causing the error.
[03:45] <wgrant> Right, so rename everything 2.1+oops-0ubuntu1, or similar.
[03:45] <ubot5> https://oops.canonical.com/?oopsid=OOPS-0ubuntu1
[03:46] <wgrant> You need to change the orig tarball version, which is the bit before the -
[03:46] <wgrant> The version number of the .dsc and .debian.tar.gz is defined by debian/changelog
[03:46] <wgrant> So rename the tarball and fix debian/changelog, and all should be good.
[03:46] <sethj> yeah but none of that changed the orig.tar.gz
[03:47] <sethj> I tried editing the filename directly, but then dput thew a fit.
[03:47] <sethj> maybe rename it and then rebuild the package?
[03:47] <wgrant> Hmmm?
[03:47] <wgrant> You need to rename the orig.tar.gz yourself.
[03:47] <wgrant> Then change debian/changelog
[03:47] <wgrant> Then build and upload the package.
[03:47] <sethj> okay, so that's what I missed.
[03:48] <sethj> I didn't rebuild.
[03:48] <wgrant> dput just reads the .changes and uploads the files mentioned in it.
[03:48] <wgrant> It doesn't know what a changelog is :)
[03:48] <wgrant> So it can't notice changes to the changelog.
[03:49] <sethj> ah
[03:49] <sethj> my bad.
[03:49] <sethj> Looks like it is working now. Thank you wgrant!
[03:49] <wgrant> Great
[03:49] <wgrant> Let me know if you run into any more trouble.
[09:20] <Odd_Bloke> cjwatson: wgrant: Could you mark https://launchpad.net/~daniel-thewatkins/+livefs/ubuntu/wily/cpc as non-virtualised, please?
[09:40] <wgrant> Odd_Bloke: It is done.
[09:42] <Odd_Bloke> wgrant: Danke.
[10:18] <Odd_Bloke> wgrant: Should I still be seeing my armhf builds (for example) building on lgw01-*?
[10:20] <Odd_Bloke> (https://launchpad.net/~daniel-thewatkins/+livefs/ubuntu/wily/cpc/+build/37836, for example.)
[10:21] <Odd_Bloke> I'm seeing failures with a missing /usr/bin/env which I vaguely recall being related to being on a virtualised builder (though my memory may be lying to me).
[10:23] <wgrant> Odd_Bloke: No, that's still building virtualised.
[10:23] <wgrant> Oh, the PPA needs to be devirt too, I guess.
[10:23] <wgrant> I can do that if you want.
[10:23] <Odd_Bloke> wgrant: Oh, yes please.
[10:23] <Odd_Bloke> I forgot that both were considered.
[10:25] <wgrant> Odd_Bloke: Done.
[10:25] <Odd_Bloke> Thanks again.
[10:25] <Odd_Bloke> Aha, there we go.
[11:21] <Odd_Bloke> wgrant: I'm not seeing packages I upload to that PPA build for (e.g.) armhf; am I forgetting something else I need to do to get those building?
[11:29] <wgrant> Odd_Bloke: Oh, I'd forgotten livecd-rootfs was arch: any. I'll enable armhf, but do you want all arches?
[11:29] <Odd_Bloke> wgrant: Yes please.
[11:30] <Odd_Bloke> wgrant: I had a look using lp-shell and couldn't see any, but is there a way of seeing what arches are enabled for a PPA?
[11:30] <wgrant> Odd_Bloke: Done. You'll need to reupload.
[11:30] <wgrant> Or recopy, in fact.
[11:30] <wgrant> Odd_Bloke: archive.processors
[11:31] <Odd_Bloke> wgrant: Aha, great.
[17:45] <Odd_Bloke> cjwatson: wgrant: One thing we need in our images is /etc/cloud/build.info which includes a serial (which, obviously, changes for each build). Is there a way that we can pass data in to the livefs.requestBuild call that we could consume during the live-build process?
[17:47] <Odd_Bloke> A brief examination of buildlivefs suggests not.
[17:48] <cjwatson> Odd_Bloke: can you just use NOW which already exists?
[17:48] <cjwatson> for this very purpose
[17:48] <cjwatson> echo "BUILDSTAMP=\"$NOW\"" >> config/binary
[17:49] <Odd_Bloke> Our serials are currently <DATE>.N where N is the index of the build during that day (when N>0).
[17:49] <Odd_Bloke> And we'd need to maintain that for trusty.
[17:49] <cjwatson> So, if you really had to maintain exactly that format (I decided it was not necessary to maintain it in cdimage), we could do that, but it'd take a launchpad-buildd rollout
[17:50] <Odd_Bloke> I mean, we don't use SUBPROJECT for anything. *looks around shiftily*
[17:50] <cjwatson> haha
[17:51] <cjwatson> I wonder if it would make sense to let the livefs and livefs.requestBuild metadata override the build arguments precomputed by LP
[17:52] <cjwatson> at least for datestamp
[17:52] <cjwatson> then you could pass metadata_override={"datestamp": whatever}
[17:52] <cjwatson> the only other place that lands is in /etc/media-info
[17:52] <cjwatson> and I'm guessing you wouldn't in fact object to that being consistent
[17:53] <cjwatson> or we could just make livefs.requestBuild take a version argument
[17:53] <cjwatson> Odd_Bloke: can you file a bug on Launchpad for this, in any case?
[17:54] <Odd_Bloke> cjwatson: Against Launchpad itself?
[17:54] <cjwatson> yes
[18:08] <Odd_Bloke> cjwatson: That's https://bugs.launchpad.net/launchpad/+bug/1496074
[18:08] <ubot5> Ubuntu bug 1496074 in Launchpad itself "Enable passing version information to livefs builds" [Undecided,New]
[18:08] <cjwatson> Thanks
[18:10] <cjwatson> Odd_Bloke: You'd be OK using NOW / BUILDSTAMP if you could override it?
[18:10] <Odd_Bloke> cjwatson: I believe so, yes.
[18:11] <cjwatson> Odd_Bloke: all right, will get that fixed for you, hopefully this week
[18:11] <Odd_Bloke> cjwatson: Thanks!
[18:32] <pgquiles_> sorry if it's obvious but, whats wrong with my code? http://pastebin.ubuntu.com/12419392/ Apparently it does not get any bugs from Launchpad :-?
[18:37] <cjwatson> pgquiles_: You can't iterate over the whole bug collection.  You can pick a bug target and iterate over bugs on that.
[18:37] <cjwatson> Or search for something.
[18:39] <pgquiles_> cjwatson: what do you mean by "a bug target"? (that code was taken straing out of the wiki: https://help.launchpad.net/API/launchpadlib#Collections )
[19:04] <pgquiles_> ah, now I see what a bug_target is
[22:26] <nottrobin> how can I give access to push to git repositories to someone who isn't the project owner?
[22:42] <wgrant> nottrobin: The project owner doesn't have any special access to Git repositories. The owner of the Git repository is a separate setting, and it is that person or team that has push access.
[22:43] <nottrobin> wgrant: thanks. is there any way to grant access to anyone else apart from the git repository owner?
[22:44] <wgrant> nottrobin: Not at this stage, though we'll likely be adding that functionality when we introduce customisable per-branch permissions.
[22:44] <nottrobin> wgrant: great
[22:44] <cjwatson> nottrobin: It's usually best, for now, to just make the repository owned by a suitable team.
[22:45] <nottrobin> cjwatson: aye. In this case, I'm trying to update the git repo from a script, and I don't want the script to have all the team permissions
[22:46] <wgrant> Many projects have a special committers team which doesn't have general project access, it just owns the repos.
[22:46] <nottrobin> yeah I could play around with that
[22:46] <nottrobin> thanks guys