[00:39] 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] jelmer: codehosting (though not codeimport) in master currently relies on the Python 2 version of breezy [00:49] 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] jelmer: I'm expecting to deploy the codehosting/breezy work to production tomorrow [01:04] cjwatson: ack, thanks [01:04] cjwatson: FWIW we're not in a hurry, just trying to figure out what constraints we have [01:07] 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] 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] https://code.launchpad.net/~sil2100/launchpad-buildd/pass_build_id/+merge/377635 [13:13] sil2100: Yep, saw it, in the middle of a sprint at the moment but it's on my list [13:14] I agree it's likely to need to be something other than build_id, but will have a think [13:14] sil2100: When is 18.04.4? [13:14] Still 2020-02-06 as scheduled? [13:44] cjwatson: yes ;) [13:44] cjwatson: thank you! [13:44] cjwatson: I renamed it to image_build_id for now so that it doesn't conflict with the in-code build_id [13:45] 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] On cdimage it has many names ;p [13:47] sil2100: Isn't that already --datestamp? [13:48] Passed as NOW? [14:05] 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] Since it can be DATE.1, DATE.2 depending on how many builds a day there were [14:06] 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] But yeah, I actually never used NOW [14:07] * sil2100 looks at livecd-rootfs code [14:09] 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] And BUILDSTAMP is then used for ubuntu-cpc builds to populate /etc/cloud/build.info [14:11] hm, good to know that, maybe I should poke the CPC guys to know if I can hijack this [14:11] DATE.1, DATE.2 is exactly what we already use datestamp for [14:12] I think [14:12] args["datestamp"] = build.version [14:13] The naming is a mess, but it exists and we shouldn't add another thing that does the same thing [14:13] It's true that cdimage doesn't pass it; it's the optional version argument to livefs.requestBuild [14:14] When I wrote this I never intended it to be required to be an actual timestamp [14:14] cjwatson: agreed! Yeah, I guess I missed it since I looked at cdimage first [14:14] Name notwithstanding [14:14] Excellent [14:14] (I think some of the naming was live-build's fault, but it's been a while) [14:14] Thanks for pointing that out! [14:14] I shall use it in that case ;) [14:14] Since it's actually perfect, since it means there's less stuff that needs to land [14:15] 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!