[00:03] <slangasek> tsimonq2: done and rolled out
[00:03] <tsimonq2> slangasek: Thanks.
[01:42] <tsimonq2> slangasek: So the build logs for Lubuntu daily-live timestamped 20180104 show that the *implementation* is correct but the repositories aren't.
[01:43] <tsimonq2> slangasek: I certainly wouldn't have expected this...
[01:45] <slangasek> mm?
[01:45] <tsimonq2> slangasek: It errors out with this: fatal: could not read Username for 'https://git.launchpad.net': No such device or address
[01:45] <slangasek> ok then
[01:45] <tsimonq2> So it just needs git+ssh?
[01:46] <tsimonq2> (Do the builders have the capability to do that? Stupid question but I think it's worth asking...)
[01:46] <slangasek> well, git+ssh *definitely* requires a username...
[01:47] <tsimonq2> Right, but apparently so does https
[01:47] <tsimonq2> https://people.canonical.com/~ubuntu-archive/cd-build-logs/lubuntu/bionic/daily-20180104.log - there it is
[01:47] <slangasek> tsimonq2: yes, if I browse to https://git.launchpad.net/~lubuntu-dev/ubuntu-seeds/+git/platform.bionic  I get an Ubuntu SSO prompt
[01:48] <tsimonq2> That's not what I'm referring to.
[01:48] <slangasek> and then I log in, and then I get Repository '~lubuntu-dev/ubuntu-seeds/+git/platform.bionic' not found.
[01:48] <tsimonq2> Besides, that doesn't exist (thus the SSO prompt)
[01:48] <tsimonq2> Ohhh
[01:48] <tsimonq2> I'm misreading this
[01:49] <tsimonq2> (or am I? dunno)
[01:49] <slangasek> what I see is that https://git.launchpad.net/~lubuntu-dev/ubuntu-seeds/+git/lubuntu/ clones fine, then it fails to get platform.bionic
[01:49] <tsimonq2> In fact, line 59 of that log I just linked is probably the culprit
[01:49] <tsimonq2> RIght
[01:49] <tsimonq2> s/59/60/
[01:50] <slangasek> * Checking out https://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/platform.bionic/
[01:50] <slangasek> bzr: ERROR: Not a branch: "https://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/platform.bionic/".
[01:50] <tsimonq2> Right
[01:50] <tsimonq2> I can now repro locally
[01:51] <slangasek> fwiw your bzrpattern edit changed http to https
[01:51] <slangasek> and I can branch from http
[01:51] <slangasek> -        elif self.prefer_bzr:
[01:51] <slangasek> -            pattern = "http://bazaar.launchpad.net/~%s/ubuntu-seeds/"
[01:51] <slangasek> you assumed https was correct? :)
[01:51] <tsimonq2> Right, and I thought that was harmless, because I assumed when everything in Canonical's sites switched over to https, so did bazaar.launchpad.net
[01:52] <tsimonq2> (there was an announcement and everything)
[01:52] <slangasek> ok.  I'm switching it back
[01:53] <tsimonq2> Also change it back in the tests (when you fixed them I saw you changed to https as well)
[01:55] <slangasek> tsimonq2: done. by all rights I should've demanded you change this already when reviewing because you were making an unrelated change, but I was being lenient ;)
[01:56] <tsimonq2> slangasek: Right, and to be completely fair, I thought HTTPS Bazaar was a thing.
[01:59] <tsimonq2> slangasek: Also, you apparently believed me, you did it in your commits fixing the tests ;P
[02:02] <tsimonq2> slangasek: ubuntu-archive-tools> To get this part fixed, I could do this in multiple ways... I'm leaning towards trying to programatically detect if it's a git or bzr repo and then adding a --vcs argument if the user wants to override, would that be alright?
[02:03] <slangasek> tsimonq2: sorry, I don't actually know the context of what needs to be fixed on that branch, and my attention is elswhere right now
[02:05] <tsimonq2> slangasek: Alright. When you do have a minute though, branch-seeds in lp:ubuntu-archive-tools is what I'm referring to.
[02:05] <tsimonq2> (Just needs "Gitifying")
[02:18] <slangasek> tsimonq2: ok, I don't know that I've ever used this command, but I see that it's referenced in https://wiki.ubuntu.com/NewReleaseCycleProcess.  I don't see a use case for a --vcs option to override - it seems to me that if a flavor is migrating their seeds, they should do so for historical releases all at the same time
[02:18] <slangasek> tsimonq2: I'm fine with programmatically detecting bzr vs git (which should be as straightforward as a string match on the URI)
[02:22] <tsimonq2> slangasek: Adam does this at the beginning of every release cycle. ;)
[02:22] <tsimonq2> slangasek: http://bazaar.launchpad.net/~lubuntu-dev/ubuntu-seeds/lubuntu.bionic/revision/390 for example
[02:23] <tsimonq2> (well, not *absolutely* sure, but it does look like this is the script he uses)
[02:24] <tsimonq2> (I'd ask Adam himself but it seems like he's still on vac)
[02:27] <tsimonq2> vcs> makes sense
[04:47] <tsimonq2> slangasek: There, I think this should do it: https://code.launchpad.net/~tsimonq2/ubuntu-archive-tools/add-git-support-to-branch-seeds/+merge/335687
[07:01] <cpaelzer> slangasek: bzr merging always i bizzare to me (so it lives to its abbreviation) - but yeah now that the Delta is generated it obviously is the wrong target
[07:01] <cpaelzer> slangasek: thanks for the hint
[07:03] <cpaelzer> what I had set was the default LP gave me
[07:03] <cpaelzer> I think I fixed the target, but will double check once the diff is up this time
[07:11] <cpaelzer> hmm now it shows no diff, did you already merge and your pingwas only FYI?
[07:12] <cpaelzer> oh you did, thank you slangasek
[08:59] <LocutusOfBorg> hello apw, please merge? https://code.launchpad.net/~costamagnagianfranco/britney/hints-ubuntu/+merge/335626
[10:16] <Laney> :'(
[10:24] <sil2100> Oh shit
[10:25] <xnox> holiday, celebrate!
[14:10] <tsimonq2> Right, unexpected holiday ...
[15:17] -queuebot:#ubuntu-release- Unapproved: rejected sosreport [source] (artful-proposed) [3.5-1~ubuntu17.10.1]
[15:17] -queuebot:#ubuntu-release- Unapproved: rejected sosreport [source] (zesty-proposed) [3.5-1~ubuntu17.04.1]
[15:17] -queuebot:#ubuntu-release- Unapproved: rejected sosreport [source] (xenial-proposed) [3.5-1~ubuntu16.04.1]
[15:18] -queuebot:#ubuntu-release- Unapproved: rejected sosreport [source] (trusty-proposed) [3.5-1~ubuntu14.04.1]
[15:57] <dpb1> sil2100: hey
[15:57] <dpb1> are you working on #1737640?
[16:48] -queuebot:#ubuntu-release- Unapproved: accepted sosreport [source] (artful-proposed) [3.5-1~ubuntu17.10.1]
[16:50] -queuebot:#ubuntu-release- Unapproved: accepted sosreport [source] (zesty-proposed) [3.5-1~ubuntu17.04.1]
[16:54] -queuebot:#ubuntu-release- Unapproved: accepted sosreport [source] (xenial-proposed) [3.5-1~ubuntu16.04.1]
[16:56] -queuebot:#ubuntu-release- Unapproved: accepted sosreport [source] (trusty-proposed) [3.5-1~ubuntu14.04.1]
[17:19] -queuebot:#ubuntu-release- Unapproved: accepted openvswitch [source] (artful-proposed) [2.8.1-0ubuntu0.17.10.1]
[17:22] -queuebot:#ubuntu-release- Unapproved: accepted openscad [source] (artful-proposed) [2015.03-2+dfsg-2ubuntu1.17.10.1]
[17:25] -queuebot:#ubuntu-release- Unapproved: accepted cloud-initramfs-tools [source] (artful-proposed) [0.39ubuntu1.1]
[17:42] -queuebot:#ubuntu-release- Unapproved: accepted cloud-initramfs-tools [source] (zesty-proposed) [0.35ubuntu2.1]
[17:45] -queuebot:#ubuntu-release- Unapproved: rejected evolution-data-server [source] (artful-proposed) [3.26.3-1ubuntu0.1]
[17:45] -queuebot:#ubuntu-release- Unapproved: rejected evolution [source] (artful-proposed) [3.26.3-0ubuntu0.1]
[17:50] -queuebot:#ubuntu-release- Unapproved: accepted cloud-initramfs-tools [source] (xenial-proposed) [0.27ubuntu1.5]
[17:57] <tsimonq2> ...are the Launchpad builders still down, even for Ubuntu builds?
[17:58] <tsimonq2> Oh, hm, seems things might be back?
[18:00] <tsimonq2> Oh, reading #lp, nvm
[18:07] -queuebot:#ubuntu-release- Unapproved: rejected horizon [source] (xenial-proposed) [2:9.1.2-0ubuntu4]
[18:13] <rbasak> tsimonq2: also the topic here :)
[18:14] <tsimonq2> rbasak: I know, but I see builds going, so I wondered...
[18:47] <teward> rbasak: this brings up an obvious question, but does this require alteration to the release schedule to adjust freeze dates, etc. because of the downtime?
[18:47] <teward> since we can't build things anymore :P
[19:04] <cjwatson> tsimonq2: Only test rebuilds, which have built on Launchpad already and so are negligible risk
[19:04] <cjwatson> (well, mostly only test rebuilds)
[19:09] <rbasak> teward: I'm not on the release team. But I think it probably doesn't make sense to adjust schedules twice, so we might as well defer any discussion until we know when the downtime will be over.
[19:10] -queuebot:#ubuntu-release- Unapproved: horizon (xenial-proposed/main) [2:9.1.2-0ubuntu3 => 2:9.1.2-0ubuntu4] (openstack, ubuntu-server)
[19:10] <tsimonq2> cjwatson: Alright, thanks
[19:25] <slangasek> jbicha: hrm, do you know the history of the gvfs delta that runs the autopkgtests through 'sudo', without taking any steps to ensure that the user running the tests has passwordless sudo access?
[19:27] <slangasek> jbicha: (yours is the oldest Ubuntu upload before the merge changelog gets truncated, so you get to field the question ;)
[19:33] <slangasek> apparently this dates back to gvfs 1.20.1-1ubuntu3 by pitti
[20:12] -queuebot:#ubuntu-release- New source: opengcs (bionic-proposed/primary) [0.3.4+dfsg2-0ubuntu1]
[20:19] <jbicha> I suggest skipping a January alpha (there's still a 17.10 respin that needs to be done too) and most flavors weren't participating in the January alpha
[20:25] <acheronuk> unless miraculous updates appear in the VERY near future, I would agree with that ^^^
[20:30] <jbicha> a year ago, we didn't have an "Alpha 1" and things were fine, so I don't think it's very useful
[20:35] <flocculant> 'we've' not had an alpha for some cycles and things are fine :)
[21:16] -queuebot:#ubuntu-release- Unapproved: accepted google-cloud-sdk [source] (artful-proposed) [183.0.0-0ubuntu1~17.10.0]
[21:20] -queuebot:#ubuntu-release- Unapproved: accepted google-cloud-sdk [source] (xenial-proposed) [183.0.0-0ubuntu1~16.04.0]
[21:21] -queuebot:#ubuntu-release- Unapproved: accepted google-cloud-sdk [source] (trusty-proposed) [183.0.0-0ubuntu1~14.04.0]
[21:47] <tsimonq2> jbicha: Right, that was the plan.
[21:47] <tsimonq2> jbicha: (I've had my eye on this, everything *could* magically work out but it's unlikely)
[21:47] <tsimonq2> flocculant: Let's not get started on that debate again ;)
[21:48] <tsimonq2> I totally see the use in it
[21:48] <tsimonq2> (So, I'll continue pushing to do it.)
[21:49] <tsimonq2> If a flavor doesn't want to do it, it's simple, they opt out.
[21:49] <tsimonq2> ¯\_(ツ)_/¯
[21:51] <slangasek> I think you could get the same benefit without the milestone overhead
[21:53] <tsimonq2> I disagree, it's a nice occasion for testing, and we've found (and squashed) bugs because of A1 testing before.
[21:54] <slangasek> you can schedule testing without imposing an archive freeze and publishing milestone images
[21:57] <tsimonq2> Sure you can, but milestones seem to get the most traction, because there's a sense of urgency attached to releasing images as a milestone.
[21:58] <slangasek> if you wanted to do an "alpha" that was just coordinating testing, instead of imposing a milestone freeze on the archive that causes drag for other teams due to the buggy way per-flavor freezes are implemented, then I would have no objections
[22:00] <tsimonq2> What would it take to fix the buggy implementation of the per-flavor freezes so that other teams wouldn't be dragged down by it?
[22:15] <tsimonq2> (I ask because rather than avoiding milestones only because the per-flavor freeze implementation is buggy could be fixed by correctly implementing the per-flavor freeze... I'd rather do that than go without milestones.)
[22:16] <tsimonq2> ((That sentence didn't make gramatical sense but you probably got the point anyways...))
[22:23] -queuebot:#ubuntu-release- Unapproved: rejected libzstd [source] (zesty-proposed) [1.3.1+dfsg-1~ubuntu0.17.04.1]