[00:39] <jelmer> cjwatson: does launchpad currently rely on the Python 2 version of Breezy, or are there any plans to rely on the Python 2 version?
[00:48] <cjwatson> jelmer: codehosting (though not codeimport) in master currently relies on the Python 2 version of breezy
[00:49] <cjwatson> jelmer: If possible it would be helpful if the issues blocking codeimport were fixed before breezy dropped Python 2 support, so that we have an overlap period; though another possibility is to split out codeimport
[00:50] <cjwatson> jelmer: I'm expecting to deploy the codehosting/breezy work to production tomorrow
[01:04] <jelmer> cjwatson: ack, thanks
[01:04] <jelmer> cjwatson: FWIW we're not in a hurry, just trying to figure out what constraints we have
[01:07] <cjwatson> jelmer: We've made some pretty substantial progress on dependencies in the last few months, but there's still a lot of code to port and a few complicated remaining dependencies (notably lazr.authentication/lazr.restful is going to need some fiddling)
[13:09] <sil2100> Hello! I have a small MP I'd like someone from the LP-team to take a look at, since I'm really bad at naming stuff - this is all needed for some stuff we'd like to have for 18.04.4 images:
[13:09] <sil2100> https://code.launchpad.net/~sil2100/launchpad-buildd/pass_build_id/+merge/377635
[13:13] <cjwatson> sil2100: Yep, saw it, in the middle of a sprint at the moment but it's on my list
[13:14] <cjwatson> I agree it's likely to need to be something other than build_id, but will have a think
[13:14] <cjwatson> sil2100: When is 18.04.4?
[13:14] <cjwatson> Still 2020-02-06 as scheduled?
[13:44] <sil2100> cjwatson: yes ;)
[13:44] <sil2100> cjwatson: thank you!
[13:44] <sil2100> cjwatson: I renamed it to image_build_id for now so that it doesn't conflict with the in-code build_id
[13:45] <sil2100> It'll usually be a timestamp, but I'd also like it to be an arbitrary identifier that someone can push to a build if needed
[13:45] <sil2100> On cdimage it has many names ;p
[13:47] <cjwatson> sil2100: Isn't that already --datestamp?
[13:48] <cjwatson> Passed as NOW?
[14:05] <sil2100> cjwatson: I don't know, I mean, at least it's not passed via cdimage for sure - I don't know what for --datestamp is used, but the build_id that I want to pass is the cdimage build/publish timestamp identifier, and that's not always a strict timestamp
[14:05] <sil2100> Since it can be DATE.1, DATE.2 depending on how many builds a day there were
[14:06] <sil2100> I see that datestamp is pushed as NOW into the environment, so I could be a bit worried that this not being an actual timestamp might cause trouble
[14:07] <sil2100> But yeah, I actually never used NOW
[14:07]  * sil2100 looks at livecd-rootfs code
[14:09] <sil2100> I guess it's only used there to do `echo "BUILDSTAMP=\"$NOW\"" >> config/binary`, so I guess in theory I could use that? I'm just worried as the variable/parameter names can confuse people
[14:10] <sil2100> And BUILDSTAMP is then used for ubuntu-cpc builds to populate /etc/cloud/build.info
[14:11] <sil2100> hm, good to know that, maybe I should poke the CPC guys to know if I can hijack this
[14:11] <cjwatson> DATE.1, DATE.2 is exactly what we already use datestamp for
[14:12] <cjwatson> I think
[14:12] <cjwatson>         args["datestamp"] = build.version
[14:13] <cjwatson> The naming is a mess, but it exists and we shouldn't add another thing that does the same thing
[14:13] <cjwatson> It's true that cdimage doesn't pass it; it's the optional version argument to livefs.requestBuild
[14:14] <cjwatson> When I wrote this I never intended it to be required to be an actual timestamp
[14:14] <sil2100> cjwatson: agreed! Yeah, I guess I missed it since I looked at cdimage first
[14:14] <cjwatson> Name notwithstanding
[14:14] <sil2100> Excellent
[14:14] <cjwatson> (I think some of the naming was live-build's fault, but it's been a while)
[14:14] <sil2100> Thanks for pointing that out!
[14:14] <sil2100> I shall use it in that case ;)
[14:14] <sil2100> Since it's actually perfect, since it means there's less stuff that needs to land
[14:15] <sil2100> In the best case I'll just have to tweak cdimage to pass it, and the rest should just work - since livecd-rootfs already populates /etc/cloud/build.info with it, so that's what we can use!