[00:00] <wgrant> https://help.launchpad.net/Packaging/SourceBuilds/Recipes
[00:01] <caraka> Thank you wgrant, I had just landed there via google. Again. haven't read that for a while, and it's time for a more thorough re-read.
[00:02] <caraka> Thank you very much!
[00:02] <wgrant> caraka: It's reasonably complete, but I'll be happy to answer any more questions.
[00:02] <wgrant> np
=== caraka_ is now known as caraka
=== mpt_ is now known as mpt
[13:00] <Odd_Bloke> cjwatson: wgrant: Are the bos-arm64-* builders only being used for xenial builds?
[13:01] <cjwatson> Odd_Bloke: They're only being used for burn-in tests right now, until we're more confident in them.
[13:02] <cjwatson> Odd_Bloke: Well, and the handful of virtualised PPAs with arm64 enabled.
[13:02] <Odd_Bloke> cjwatson: So is it weird that https://launchpad.net/~cloud-images-release-managers/+livefs/ubuntu/xenial/cpc/+build/41523 got scheduled on to one of them?
[13:03] <cjwatson> Odd_Bloke: No, because you forgot to ask for that livefs to be made non-virtualised ...
[13:03] <cjwatson> Odd_Bloke: #webops should be able to do that for you
[13:03] <cjwatson> Odd_Bloke: (assuming your previous livefses were non-virtualised, which I believe they were)
[13:04] <Odd_Bloke> Oh, yes, it's that time in every release cycle where I forget that each release is considered a separate livefs.
[13:04] <cjwatson> In [1]: lp.load('/~cloud-images-release-managers/+livefs/ubuntu/wily/cpc').require_virtualized
[13:04] <cjwatson> Out[1]: False
[13:04] <cjwatson> In [2]: lp.load('/~cloud-images-release-managers/+livefs/ubuntu/xenial/cpc').require_virtualized
[13:04] <cjwatson> Out[2]: True
[13:05] <cjwatson> Odd_Bloke: Though, it would probably have worked if you'd let it finish.
[13:05] <cjwatson> Odd_Bloke: But the armhf build wouldn't have done.
[13:05] <Odd_Bloke> cjwatson: Yeah, I was trying to see what priority the build would get, but it got scheduled before I could see that. :p
[13:06] <cjwatson> 2505 plus any relative_build_score for the livefs archive
[13:06] <cjwatson> livefsbuild.archive, that is
[13:07] <cjwatson> So total score 2505 in this case
[14:01] <vila> cjwatson: I have a recipe failing (https://launchpadlibrarian.net/222877368/buildlog.txt.gz) saying the public for my ppa (https://launchpad.net/~vila/+archive/ubuntu/ppa)  is not available. Is there a known delay for xenial ?
[14:02] <cjwatson> "the public for your ppa"?  EPARSE
[14:02] <vila> *key
[14:02] <vila> sorry
[14:03] <vila> that's how I read the error but I may be wrong :-/
[14:03] <cjwatson> Oh, that message.  That's cosmetic and does not cause whatever failure you're *actually* seeing.
[14:03] <cjwatson> AFAICS that recipe build succeeded.
[14:03] <teward> so i'm trying to attempt a merge via the UDD method for nginx in Xenial, but it's failing to download, do I have to pull from Wily instead since Xenial just opened?
[14:03] <cjwatson> teward: Just don't use UDD.
[14:03] <vila> cjwatson: https://code.launchpad.net/~vila/+recipe/uci-config-gating-vila says 'Could not be uploaded correctly)
[14:04] <cjwatson> teward: But in any case it's not yet set up for xenial.
[14:04] <teward> cjwatson: ack
[14:04] <cjwatson> vila: https://launchpadlibrarian.net/222877494/upload_1008452_log.txt
[14:04] <vila> cjwatson: err, found the upload log, forget me ;)
[14:04] <cjwatson> You've somehow managed to produce two different recipe builds with the same version.
[14:05] <cjwatson> Arrange for that not to happen :-)
[14:05] <vila> cjwatson: yeah, operator error, I fixed an issue in a dependency and thought just re-running the recipe would be enough
[14:06] <cjwatson> vila: You could just retry the individual builds.
[14:06] <cjwatson> vila: The recipe produces a source package.  If you don't need to modify the contents of the source package, then you don't need to re-run the recipe.
[14:07] <cjwatson> vila: What you probably want to do is retry https://code.launchpad.net/~vila/+archive/ubuntu/ppa/+build/8192502
[14:08] <vila> cjwatson: yup, thanks ! Just found it back ;)
[15:28] <teward> cjwatson: is there a timeline when bzr and launchpad will be set up for xenial?
[15:28] <cjwatson> teward: You mean just bzr.  Launchpad is already set up.
[15:29] <teward> i mean for the lp:ubuntu/package stuff for xenial
[15:29] <teward> but yes
[15:29] <cjwatson> teward: Probably next week, since William has most experience with it and he's on leave this week.
[15:29] <teward> ack
[15:29] <dobey> i wouldn't rely on branch imports really
[15:29] <cjwatson> It's not something I'm inclined to mess with.
[15:29] <teward> :P
[15:29] <cjwatson> Indeed, please migrate your processes away from them.
[15:29] <cjwatson> They will be going away once we have a git equivalent sorted out.
[15:29] <teward> probably should have the developer docs updated, they still link to the UDD stuff
[15:29] <teward> (which is bzr)
[15:29] <cjwatson> I've been telling them for years and they ignore me.
[15:29] <teward> heh
[15:30] <cjwatson> Using source packages is better than the unreliable mess that the imports are right now.
[15:31] <teward> true, except the source packages are going to give me a splitting headache... :/
[15:31] <teward> the side effect of Debian being hyperactive with changing packaging :/
[15:31]  * teward sighs, and prepares for another two hours of work
[15:58] <teward> cjwatson: the PPAs work with xenial though right?
[15:58] <teward> (or is that also on the radar)
[15:59] <cjwatson> teward: PPAs are fine.
[16:00] <cjwatson> That used to be a separate step ages ago, but now PPAs work automatically as soon as the series is initialised.
[16:00] <teward> nice
=== jroll|dupe is now known as jroll
[20:18] <Odd_Bloke> cjwatson: wgrant: I don't think I've been getting emails about review comments on a git merge proposal I submitted; known bug?
[20:30] <Odd_Bloke> Oh, in fact, something is definitely up; apparently OOPS-6db37bf38de8f54f864dceb1fb48de26 was it trying to email out about the comment I just added.
[20:30] <ubot5> https://oops.canonical.com/?oopsid=OOPS-6db37bf38de8f54f864dceb1fb48de26