[00:00] <cyphermox> I want a Lorem keyboard.
[00:00] <tsimonq2> Hah.
[00:00] <tsimonq2> +1
[00:09] <cyphermox> tsimonq2: lubuntu-desktop-amd64 looks good to me, but I did just see https://bugs.launchpad.net/ubuntu/+source/gnome-system-tools/+bug/1617468
[00:09] <ubot5> Ubuntu bug 1617468 in gnome-system-tools (Ubuntu) "Package contains files in /usr/@DATADIRNAME@/locale" [Undecided,Confirmed]
[00:10] <cyphermox> alternate is still running, and that's super slow, fortunately there is an easy fix to that I think
[00:11] <cyphermox> it's just not something we can do for this release though
[00:13] <tsimonq2> cyphermox: Ok, I'll take a look.
[00:14] <cyphermox> I don't think the reason for alternate is the slightly lower download size, so using a livefs rather than a pool of packages might help there, at a slight download cost.
[00:14] <tsimonq2> cyphermox: What about Lubuntu Alternate? We're thinking of axing that pretty soon, so if it's a simple fix, JFDI please.
[00:14] <cyphermox> axing alternate is another way to fix it being slow, of course.
[00:14] <tsimonq2> cyphermox: (will be up for discussion soon, fwiw)
[00:14] <tsimonq2> lol
[00:14] <tsimonq2> yep
[00:14] <wxl> the other reason for alternate is lower resource usage
[00:15] <wxl> esp. RAM
[00:15] <cyphermox> wxl: yeah, that's what I figured, download size isn't (the ~150M difference doesn't seem worth it)
[00:16] <tsimonq2> wxl: I don't want to go on about this today, but we have mini.iso?
[00:17] <wxl> i mean it exists, yes
[00:17] <wxl> not like anyone ever tests it :)
[00:17] <wxl> referred to as netboot, btw
[00:17] <tsimonq2> ^ yep
[00:17]  * tsimonq2 goes back to cleaning room and waitng for ISO
[00:32] <tsimonq2> cyphermox: Ok, rebooting now.
[00:35] <lyn||ian> well should there be an install using mini.iso using netboot testcase?
[00:50] <cyphermox> lyn||ian: those exist already
[00:50] <cyphermox> Product (Netboot)
[00:51] <cyphermox> speaking of which, if you happen to have armhf, those aren't tested yet.
[00:51] <lyn||ian> ah yeah I forgot about that off the top of it
[01:02] <cyphermox> tsimonq2: alternate looks fine too.
[01:06] <tsimonq2> cyphermox: Thanks
[02:36] <rbalint> i am testing a fix in python-numpy for the alignment issue in pywavelets it my PPA https://launchpad.net/~rbalint/+archive/ubuntu/scratch/+packages
[02:38] <rbalint> numpy has many reverse deps which I'm rebuilding to look for regressions but if the fix turns out to be good there won't be enough time to run autopkgtest for each package before zesty's release :-(
[03:27] <slangasek> rbalint1: it parallelizes fairly well; try it and see?
[03:32] -queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (zesty-proposed) [2.441]
[03:32] <slangasek> cyphermox: ^^
[03:41] <slangasek> cyphermox: and https://api.launchpad.net/devel/~ubuntu-cdimage/+livefs/ubuntu/zesty/ubuntu-server-live
[03:42] -queuebot:#ubuntu-release- Unapproved: sleuthkit (zesty-proposed/universe) [4.4.0-2 => 4.4.0-2ubuntu1] (no packageset)
[03:43] -queuebot:#ubuntu-release- Unapproved: accepted sleuthkit [source] (zesty-proposed) [4.4.0-2ubuntu1]
[03:53] <cyphermox> slangasek: ta; will fix ubuntu-cdimage now.
[04:09] <slangasek> cyphermox: eta?  I'm timing out here; if there are no other fixes beyond my previous review feedback I could just do that in-line with the merge?
[04:12] -queuebot:#ubuntu-release- Builds: Ubuntu GNOME Desktop amd64 [Zesty Final] has been marked as ready
[04:12] -queuebot:#ubuntu-release- Builds: Ubuntu GNOME Desktop i386 [Zesty Final] has been marked as ready
[04:12] <cyphermox> slangasek: debian-cd
[04:16] <cyphermox> slangasek: ubuntu-cdimage is updated.
[04:20] <slangasek> cyphermox: hmm run-tests fails for me
[04:20] <slangasek> (which I noticed only after merging, because I'm Bad)
[04:20] <cyphermox> oh of course, that change would do that yes
[04:24] <cyphermox> fixed
[04:27] <slangasek> cyphermox: should that not be SUBPROJECT=live?
[04:28] <cyphermox> that's not what I wrote?
[04:28] <cyphermox> 29 6 * * *      for-project ubuntu-server cron.daily --live; for-project ubuntu-server cron.daily-preinstalled --live; SUBPROJECT=live for-project ubuntu-server cron.daily-live --live
[04:29] <slangasek> cyphermox: I see you rewrote both instances of ubuntu-server-live to ubuntu-server; I was suggesting self.config["SUBPROJECT"] = "live" in the test, in which case the test url would be http://kapok.buildd/~buildd/LiveCD/xenial/ubuntu-server-live/[...]
[04:29] <slangasek> seems to me that would be a more true test
[04:29] <cyphermox> yes
[04:30] <slangasek> cyphermox: I'll fix that locally
[04:30] <cyphermox> yeah just going through the motions and running the test
[04:30] <cyphermox> which fails.
[04:30] <cyphermox> ah, changed one too much
[04:31] <slangasek> yeah. fixed here, committing & pushing
[04:35] <slangasek> cyphermox: I see you replied to my debian-cd review comment; am I waiting for you to make that change, then?
[04:36] <cyphermox> slangasek: do you feel strongly about the change? seems to me like we shouldn't carry only-ubiquity just for kicks.
[04:36] <cyphermox> ie. things as they are in this branch will work and not have cruft.
[04:36] <cyphermox> well; not any more than the other bits have cruft, anyway
[04:38] <slangasek> cyphermox: the cruft you mean is the only-ubiquity boot option?
[04:38] <cyphermox> yes
[04:38] <slangasek> hmm
[04:38] <slangasek> trying to decide which bothers me more, cruft in the code or cruft on the boot line
[04:38] <slangasek> :)
[04:38] <cyphermox> liveparams would carry that otherwise
[04:38] <cyphermox> it *all* needs refactoring
[04:39] <cyphermox> I'd be happy to do it once we're not scrambling to release stuff
[04:39] <slangasek> yeah, merging as-is
[04:39] <cyphermox> we're basically in friday-pm mode by now
[04:41] <slangasek> merged
[04:41] <slangasek> needs livecd-rootfs to publish
[04:42] <slangasek> hmm, failing
[04:42] <slangasek> o rite, that's the private branch nonsense that shouldn't be on the private branch ;)
[04:44] <cyphermox> I thought you had fixed that already?
[04:44] <slangasek> nah
[04:46] <slangasek> ok there we are, test build running now w/ PROPOSED=1
[04:46] <wxl> hey is there any chance that the published sums for kubuntu's i386 image is wrong?
[04:47] <wxl> i zsync'd mine and every sum is totally wrong, but zsync should check it, right?
[04:47] <apw> wxl, got a link to the image, i can compare
[04:47] <slangasek> wxl: it's surely possible. You're talking the current candidate image?
[04:47] <wxl> apw: http://cdimage.ubuntu.com/kubuntu/daily-live/20170412/zesty-desktop-i386.iso
[04:48] <wxl> yep slangasek see above
[04:48] <wxl> the thing that got me looking was weird issues that don't seem to exist on any other reports https://share.riseup.net/#kpC2GLxkE0o0mMjdlyClpg
[04:49] <slangasek> wxl: I just recalculated and the image on the master server has the checksum which matches the SHA256SUMS file
[04:49] <wxl> ok lemme see if i can regrab this
[04:51] <cyphermox> slangasek: are these faileds due to a mistake on my part, or is something else off? I can't even get logs.
[04:52] <slangasek> cyphermox: those were because of the private branch not properly dispatching to lp
[04:52] <cyphermox> ok
[04:52] <slangasek> (that's the bit that I don't think should be on the private branch)
[04:53] <cyphermox> aren't you also missing something for pointing to LP?
[04:53] <cyphermox> ubuntu-server-live-amd64 on kapok.buildd starting at 2017-04-13 04:43:40
[04:54] <cyphermox> oh wait
[04:54] <cyphermox> No valid suites to build for
[04:54] <wxl> weird. now zsync is updating.
[04:55] <slangasek> cyphermox: https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/zesty/ubuntu-server-live/+build/94534 https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/zesty/ubuntu-server-live/+build/94535
[04:55] <slangasek> have not yet diagnosed
[04:55] <cyphermox> http://people.canonical.com/~ubuntu-archive/cd-build-logs/ubuntu-server/zesty/daily-live-20170413.2.log
[04:56] <slangasek> that's old
[04:56] <slangasek> keep up ;)
[04:56] <cyphermox> ah
[04:56] <slangasek> but, I see no logs for the failed livefs
[04:57] <cyphermox> I see three logs on cd-build-logs, only two builds (one per arch) on LP; something is clearly off
[04:57] <slangasek> cyphermox: cd-build-logs just hasn't synced the .3 log yet, which is the one that triggered the above livefs attempts, but I don't know why they failed
[04:58] <cyphermox> what does .3 say? nothing at all?
[04:58] <wxl> ok now i got the right value
[04:58] <wxl> disaster averted
[04:58] <slangasek> cyphermox: it says that no livefs builds succeeded
[04:58] <cyphermox> so specific.
[04:58] <slangasek> cyphermox: nusakan has no more information about it than the livefs links themselves do. consistency
[04:59] <slangasek> rbalint1: livecd-rootfs autopkgtest fails ;)
[04:59] <cyphermox> can you spin up a livefs build outside ubuntu-cdimage to test?
[04:59] <cyphermox> http://paste.ubuntu.com/24372349/
[05:00] <cyphermox> that uses Release, not Proposed, but it won't matter now
[05:02] <cyphermox> and it's "$script ubuntu-cdimage zesty ubuntu-server-live amd64"
[05:08] <cyphermox> it's almost more verbose in its error now
[05:08] <slangasek> ah?
[05:09] <cyphermox> *almost*
[05:09] <cyphermox> I have no idea why it's not happy; maybe still livecd-rootfs?
[05:11] <slangasek> yeah, I really don't know
[05:12] <slangasek> has this particular livecd-rootfs code been tested before upload?
[05:13] <slangasek> cyphermox: an ubuntu-server build still does something useful: https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/zesty/ubuntu-server/+build/94540
[05:13] <slangasek> cyphermox: but a build of ubuntu-server-live in my own ppa did nothing different
[05:14] <cyphermox> wat
[05:14] <cyphermox> it was working here.
[05:16] <slangasek> were you feeding any additional json when you were building?
[05:16] <slangasek> https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/zesty/ubuntu-server-live/+build/94542
[05:16] <slangasek> after setting project=ubuntu-server in the metadata
[05:16] <slangasek> that's evidently not passed by ubuntu-cdimage
[05:16] <slangasek> and maybe I should also be setting subproject there
[05:17] <cyphermox> https://launchpad.net/~cyphermox/+livefs/ubuntu/zesty/subiquity/+build/94541
[05:18] <cyphermox> the most we'd be missing is subproject; but then it should still be building an ubuntu-server image
[05:19] <cyphermox> what's different in your last build?
[05:19] <cyphermox> I can't read, it's too late
[05:20] <cyphermox> I thought you knew how to create livefses! ;)
[05:21] <slangasek> ... I do, I was following your script which populated it with empty json
[05:21] <slangasek> assumed you had tested that ;)
[05:22] <cyphermox> the script just does the creation
[05:22] <cyphermox> we'll still be missing subproject.
[05:22] <slangasek> yes, with empty json, you could specify non-empty at creation time :)
[05:23] <cyphermox> I didn't think of it
[05:23] <slangasek> anyway, subproject set, maybe that'll be more useful
[05:23] <cyphermox> I could get it to do the json metadata with a user-provided json file
[05:24] <slangasek> https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/zesty/ubuntu-server-live/+build/94543 log looks more promising
[05:25] <cyphermox> yep
[05:25] <cyphermox> oops.
[05:26] <slangasek> ?
[05:26] <cyphermox> I never removed set -x and some echoes.
[05:26] <slangasek> ah
[05:26] <slangasek> 'sudo [...] snap download'?  why sudo?
[05:27] <cyphermox> muscle memory, I suppose.
[05:27] <cyphermox> it shouldn't be necessary.
[05:30] <slangasek> cyphermox: alright, the api-triggered build succeeded, and I've triggered a build from nusakan as well, and now I'm dropping off
[05:30] <cyphermox> ok
[05:49]  * cyphermox -> sleep
[06:04] -queuebot:#ubuntu-release- Builds: Xubuntu Desktop amd64 [Zesty Final] has been marked as ready
[06:04] -queuebot:#ubuntu-release- Builds: Xubuntu Desktop i386 [Zesty Final] has been marked as ready
[06:12] -queuebot:#ubuntu-release- Builds: Kubuntu Desktop amd64 [Zesty Final] has been marked as ready
[06:13] -queuebot:#ubuntu-release- Builds: Kubuntu Desktop i386 [Zesty Final] has been marked as ready
[08:06] <davmor2> sil2100, infinity: Moving onto mini.iso
[08:10] <rbalint> slangasek: surprising to see livecd-rootfs passing only on ppc64el :-)
[08:28] <sil2100> davmor2: \o/
[08:30] -queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop amd64 [Zesty Final] has been marked as ready
[08:30] -queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop i386 [Zesty Final] has been marked as ready
[08:59] -queuebot:#ubuntu-release- Builds: Ubuntu Desktop amd64 [Zesty Final] has been marked as ready
[08:59] -queuebot:#ubuntu-release- Builds: Ubuntu Desktop i386 [Zesty Final] has been marked as ready
[08:59] -queuebot:#ubuntu-release- Builds: Ubuntu Server amd64 [Zesty Final] has been marked as ready
[08:59] -queuebot:#ubuntu-release- Builds: Ubuntu Server arm64 [Zesty Final] has been marked as ready
[08:59] -queuebot:#ubuntu-release- Builds: Ubuntu Server armhf+raspi2 [Zesty Final] has been marked as ready
[08:59] -queuebot:#ubuntu-release- Builds: Ubuntu Server i386 [Zesty Final] has been marked as ready
[08:59] -queuebot:#ubuntu-release- Builds: Ubuntu Server ppc64el [Zesty Final] has been marked as ready
[08:59] -queuebot:#ubuntu-release- Builds: Ubuntu Server s390x [Zesty Final] has been marked as ready
[08:59] -queuebot:#ubuntu-release- Builds: Ubuntu Studio DVD amd64 [Zesty Final] has been marked as ready
[08:59] -queuebot:#ubuntu-release- Builds: Ubuntu Studio DVD i386 [Zesty Final] has been marked as ready
=== klebers_ is now known as klebers
[09:41] <davmor2> infinity: hmm I'm not hitting the hang that the guy on the tracker is seeing on hardware or vm so not sure what is going on there mini.iso for amd64 and i386 are now completed
[09:45] <sil2100> davmor2: woot, thanks!
[10:03] -queuebot:#ubuntu-release- New binary: linux-signed-lts-xenial [amd64] (trusty-proposed/main) [4.4.0-74.95~14.04.1] (kernel)
[10:04] -queuebot:#ubuntu-release- New binary: linux-signed [amd64] (xenial-proposed/main) [4.4.0-74.95] (core, kernel)
[10:04] -queuebot:#ubuntu-release- New binary: linux-signed [amd64] (yakkety-proposed/main) [4.8.0-48.51] (core, kernel)
[10:05] -queuebot:#ubuntu-release- New binary: linux-signed-hwe [amd64] (xenial-proposed/main) [4.8.0-48.51~16.04.1] (kernel)
[10:27] -queuebot:#ubuntu-release- New: accepted linux-signed-lts-xenial [amd64] (trusty-proposed) [4.4.0-74.95~14.04.1]
[10:27] -queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (xenial-proposed) [4.4.0-74.95]
[10:27] -queuebot:#ubuntu-release- New: accepted linux-signed-hwe [amd64] (xenial-proposed) [4.8.0-48.51~16.04.1]
[10:28] -queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (yakkety-proposed) [4.8.0-48.51]
[10:37] -queuebot:#ubuntu-release- Unapproved: ovito (zesty-proposed/universe) [2.8.1+dfsg2-5 => 2.8.1+dfsg2-5ubuntu1] (no packageset)
[10:37] -queuebot:#ubuntu-release- Unapproved: accepted ovito [source] (zesty-proposed) [2.8.1+dfsg2-5ubuntu1]
=== maclin1 is now known as maclin
[11:54] <ogra_> hmm, archive.canonical.com is unusably slow ...
[11:55] <ogra_> (dont hit people that when they test with "install additional software" enabled ? adonbe-flashpulgin is downloading since 10+ minutes)
[11:55] <ogra_> *adobe
[11:59] <jbicha> ogra_: yes, I mentioned that yesterday, I think one problem is that there was a new Flash update for everyone published on Tuesday LP: #1682107
[11:59] <ubot5> Launchpad bug 1682107 in ubiquity (Ubuntu) "[ubiquity] adobe-flashplugin download is slow" [Undecided,Invalid] https://launchpad.net/bugs/1682107
[12:00] <ogra_> jbicha, right, but there is no reason for that server to be slow, archive.u.c isnt slow either ...
[12:01]  * ogra_ me too's the bug
[12:01] <jbicha> too many people trying to download the same file, with no mirrors
[12:02] <ogra_> well, thats the same as security.u.c ... :)
[12:02] <jbicha> I don't know if me-too-ing will help much for a closed bug :|
[12:02] <ogra_> oh, i missed that
[12:08] <wgrant> archive.c.c should be quick again now. There was just a few minutes of heavy traffic.
[12:09] <wgrant> security.u.c doesn't have the same problem, since security updates are published to -updates too
[12:09] <wgrant> So most hosts get security updates from mirrors
[12:09] <wgrant> (but security.u.c is sometimes problematic too)
[12:23] <fossfreedom_> hmm - just reading on omgubuntu - people seem to have the ability to login to gnome-shell as well as unity and unity8 on the normal ubuntu ISO
[12:25] <jbicha> fossfreedom_: gnome-shell is not included by default in 17.04: http://releases.ubuntu.com/17.04/ubuntu-17.04-desktop-amd64.manifest
[12:26] <fossfreedom_> odd that two different people reported the issue
[12:29] <jbicha> I think that's user error, the other article has step 16: Install gnome-shell
[12:32] <fossfreedom_> ah - makes sense now.
=== Laney changed the topic of #ubuntu-release to: Released: Xenial 16.04.2, Zesty | Archive: closed | ? Release Coordination | Please don't upload things during freezes where you shouldn't, or be prepared to apologise to the release team | We accept payment in cash, check or beer | melior malum quod cognoscis
[13:13] <tsimonq2> infinity: You're up early!
[13:14] <tsimonq2> :D
[13:14] <infinity> tsimonq2: It's 2:14pm.
[13:14] <tsimonq2> infinity: Oh. :P
[13:15] <davmor2> infinity: well that was nice and smooth
[13:17] <Laney> no you
[13:21] <cyphermox> morning
[13:23] <LocutusOfBorg> infinity, can we start asking when the AA will open? :p
[13:23] <LocutusOfBorg> seriously, nice release!
[13:23] -queuebot:#ubuntu-release- Builds: 38 entries have been added, updated or disabled
[13:24] <tsimonq2> It was a super quick cycle imho
[13:24] <infinity> LocutusOfBorg: No.
[13:25] <LocutusOfBorg> (it was a joke :) )
[13:26]  * LocutusOfBorg goes to upvote the release topic on slashdot https://slashdot.org/recent
=== coreycb_vaca is now known as coreycb
[13:52] <bdmurray> Laney: So you think your patch is worth testing?
[13:53] <bdmurray> infinity: Should we hold off on modifying metarelease until bug 1681566 is sorted?
[13:53] <ubot5> bug 1681566 in virtualbox (Ubuntu) "nvidia-375 DKMS module not recompiled on upgrade to 17.04" [Undecided,Confirmed] https://launchpad.net/bugs/1681566
[13:53] <infinity> bdmurray: Yes.
[14:20] <bdmurray> Laney, infinity: I did an upgrade test (it worked) and updated the bug.
[14:46] <Laney> bdmurray: Ta.
[14:52] -queuebot:#ubuntu-release- Unapproved: dkms (zesty-proposed/main) [2.3-3 => 2.3-3ubuntu1] (core)
[14:53] <bdmurray> Laney: For good measure I installed zesty dkms on yakkety and upgraded the kernel and that worked too.
[14:54] <Laney> bdmurray: It's in the queue now
[14:54] <Laney> Did someone SRUify the bug?
[14:54]  * Laney refuses to open it to find out :P
[14:54] <bdmurray> Laney: No.
=== lan3y is now known as Laney
=== Dmitrii-Sh_ is now known as Dmitrii-Sh
[15:14] -queuebot:#ubuntu-release- Unapproved: rejected golang-1.6 [source] (xenial-proposed) [1.6.2-0ubuntu5~16.04.1]
[15:17] -queuebot:#ubuntu-release- Unapproved: accepted dkms [source] (zesty-proposed) [2.3-3ubuntu1]
[15:19] -queuebot:#ubuntu-release- Unapproved: accepted golang-1.6 [source] (yakkety-proposed) [1.6.3-1ubuntu1.2]
[15:21] <ogra_> AAAAAAAAAAAAAAAAAAAAAAAAA
[15:21] <ogra_> !
[15:22] <Pici> AAAA
[15:22]  * Ursinha hugs ogra_
[15:22] <Ursinha> I don't know why you are screaming, but just in case
[15:22]  * nacc assumes aa-series naming
[15:22]  * ogra_ hugs Ursinha (meant to do that anyway :) )
[15:22] <Ursinha> :)
[15:23] <ogra_> Ursinha, that was a praise for infinity's nicely crafted mail ;)
[15:23] <Ursinha> aah :)
[15:24] <davmor2> I thought he was going for an ascii  christmas tree
[15:24] <ogra_> only the right half though
[15:24] <rbasak> "Actually"
[15:25] <rbasak> Not sure if that was meant to be ironic or not!
[15:25] <bdmurray> sil2100: Did I hear you are verifying bug 1681566?
[15:25] <ubot5> bug 1681566 in dkms (Ubuntu Zesty) "nvidia-375 DKMS module not recompiled on upgrade to 17.04" [Undecided,Fix committed] https://launchpad.net/bugs/1681566
[15:25] <bdmurray> You'll need to manually install dkms as -proposed will get disabled on upgrade.
[15:25] <sil2100> bdmurray: yeah, prepping up a yakkety env as we speak
[15:26] <bdmurray> sil2100: ^^
[15:26] <infinity> bdmurray: Yo, speaking of things enabled/disabled.  On security-only systems, security is used for the upgrade too, right?
[15:26] <infinity> bdmurray: (I was planning to copy this to security, due to the high impact nature of the oops)
[15:26] <bdmurray> infinity: As far as I know, yes.
[15:27] <bdmurray> I could test that now.
[15:27] -queuebot:#ubuntu-release- Unapproved: livecd-rootfs (zesty-proposed/main) [2.441 => 2.441.1] (desktop-core)
[15:38] -queuebot:#ubuntu-release- Unapproved: accepted golang-1.6 [source] (xenial-proposed) [1.6.2-0ubuntu5~16.04.2]
[15:40] <bdmurray> infinity: I upgraded from X to Y with -security and apt 1.3.3 is installed at the end of that.
=== bluesabre_ is now known as bluesabre
[15:50] <sil2100> Fix looks good so far, I already saw when the upgrade was happening that the module was rebuilt
[15:50] <cyphermox> slangasek: ^ can I haz review for livecd-rootfs please?
[15:52] <bdmurray> sil2100: for both kernels?
[16:01] <sil2100> I think so, but I will know now after I has rebooted
[16:01] <sil2100> I can has a working system then to check
[16:02] <sil2100> bdmurray: yep, for both kernels
[16:02] <sil2100> Putting details in the bug
[16:05] <sil2100> I guess it's goodish, I suppose?
[16:05] <sil2100> Is there anything specific expected?
[16:06] <bdmurray> Looking, does dkms status list modules for both kernels?
[16:06] <sil2100> Yes
[16:06] <sil2100> As per output pasted to the bug
[16:07] <bdmurray> and "grep 'Building for' in /var/log/dist-upgrade/apt.log"?
[16:08] <slangasek> cyphermox: it occurs to me that you could just do ubuntu-server:|ubuntu-base:*[...]) and not add the extra case
[16:09] <slangasek> cyphermox: would that be more or less clear?
[16:10] <cyphermox> I don't mind either way; seems more explicit the way I uploaded it; but you can see it differently
[16:10] <cyphermox> either way seems pretty clear.
[16:10] <sil2100> bdmurray: hm, strangely not much useful info there
[16:11] <clivejo> will this dkms fix mean a respin of the release ISO?
[16:11] <bdmurray> sil2100: Did you use do-release-upgade?
[16:11] <sil2100> Yes, as per bug
[16:11] <sil2100> do-release-upgrade -d
[16:11] <bdmurray> clivejo: no, its only an issue for multiple kernels
[16:11] <nacc> clivejo: i don't believe so, as it won't affect new installs
[16:12] <sil2100> bdmurray: http://paste.ubuntu.com/24374912/ is my apt.log
[16:12] <bdmurray> sil2100: sorry, apt-term.log
[16:13] <sil2100> hmm
[16:13]  * cyphermox -> pea soup, brb
[16:14] <sil2100> Building for 4.8.0-45-generic
[16:14] <sil2100> Building for 4.8.0-45-generic
[16:14] <sil2100> Building for architecture x86_64
[16:15] <sil2100> Argh
[16:15] <sil2100> Darn it, re-trying
[16:15] <sil2100> bdmurray: scratch this result, wait 10 minutes
[16:16] <slangasek> cyphermox: on balance I think your existing patch is clearer, ubuntu-server:| makes it hard to see the missing *
[16:18] -queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (zesty-proposed) [2.441.1]
[16:21] <bdmurray> slanagasek: Could you have a look at my apt-xapian-index Zesty upload?
[16:22] <slangasek> bdmurray: sure!
[16:25] <bladernr`> out of curiosity, how long until do-release-upgrade will work for zesty GA?  I noticed that do-release-upgrade -d still seems to load zesty, but -p or simply do-release-upgrade still says there is nothig available.
[16:25] <bladernr`> maas seems to be deploying GA now though.
[16:25] <slangasek> bladernr`: we have at least one SRU that's critical to land first because of dkms impact
[16:26] <bladernr`> ahhh ok.  Thanks.  I have a few systems to upgrade adn run tests on, so I'll wait for that
[16:26] <bdmurray> shouldn't be much longer though
[16:26] <bladernr`> thanks slangasek bdmurray
[16:26] <bdmurray> bladernr`: nothing changes between -p and not -p
[16:26] -queuebot:#ubuntu-release- Unapproved: accepted apt-xapian-index [source] (zesty-proposed) [0.47ubuntu13]
[16:26] <bdmurray> bladernr`: well aside of the dkms fix
[16:28] <bdmurray> sil2100: I'm running another upgrade too fwiw
[16:28] <sil2100> It's almost donnish here
[16:30] <bdmurray> bladernr`: Other than the dkms change why would you wait for the metarelease file (which affects the need to use -p) to change? I feel like there is a misconception that something magical happens when you don't have to use -p.
[16:30] <bladernr`> I just wanted to be sure that what I was installing was GA level, that's all.
[16:30] <tsimonq2> infinity: I applaud your humor in that email :P
[16:31] <bladernr`> so yeah, in my mind -d means non-ga Dev release stuff, -p means ready to go, and no - is GA.  But FWIW, when I use -p I get the same "No release available' message anyway.
[16:31] <bladernr`> ubuntu@s1lp9g003:~$ sudo do-release-upgrade -p
[16:31] <bladernr`> Checking for a new Ubuntu release
[16:31] <bladernr`> No new release found
=== michihenning is now known as michi
[16:32] <bdmurray> bladernr`: sorry, I meant -d
[16:33] <bladernr`> ahhh, ok.  So yeah, as I said, my perception of -d is "this is dev and will change and could be broken" while -p and no opts is "this is release or release worthy for normal use"
[16:33] <tsimonq2> cyphermox: Mmmm pea soup
=== ChrisTownsend1 is now known as ChrisTownsend
[16:34] <bdmurray> bladernr`: that perception regarding -d is true until the devel release is released.
[16:34] <bdmurray> bladernr`: so right now it'll be the same thing as when I flip the metarelease file
[16:35] <bladernr`> bdmurray, ack.  upgrades underway.  Thanks for clarifying that.
[16:39] <sil2100> bdmurray: ok, much better now
[16:39] <sil2100> Building for 4.8.0-45-generic 4.10.0-19-generic
[16:39] <sil2100> Building for 4.8.0-45-generic 4.10.0-19-generic
[16:39] <sil2100> Building for architecture x86_64
[16:39] <xnox_> infinity, that's the TEST-12 failing https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1672542
[16:39] <ubot5> Ubuntu bug 1672542 in systemd (Ubuntu Zesty) "systemd 232-18ubuntu1 ADT test failure with linux 4.10.0-13.15" [Undecided,New]
[16:39] <sil2100> bdmurray: sorry about the wasted time, I was an idiot and tested the wrong thing
[16:40] <ogra_> but good that this gets some testing too
[16:40] <ogra_> :)
[16:40] <sil2100> bdmurray: so building for two now as per your test results
[16:44] <bdmurray> sil2100: okay, I think its good to go then.
[16:45] <sil2100> Noted in the bug, setting verification-done
[16:45] <sil2100> bdmurray, Laney: done
[16:47] <bdmurray> sil2100: I think infinity is the one who needs notifying
[16:47] <sil2100> He's here, he knows
[16:47] <bdmurray> Okay
[16:47] <Laney> sil2100: good job done well
[16:47] <Laney> well good job done?
[16:49] <slangasek> Ford: Quality is Job 1
[16:49] <slangasek> Fnord: Quality is Well Jobbed
[16:50] <xnox_> slangasek, breaks often! fixed quickly!
[16:53] <slangasek> Ford, 2017: systemd is pid 1?
[16:55] <bdmurray> Laney: I don't think the dkms change needs SRUing.
[16:55] <infinity> bdmurray: Wat?
[16:57] <infinity> bdmurray: It's released now.  But also, wat?
[16:57] <infinity> bdmurray: PS: Wat?
[16:57] <bdmurray> infinity: I mean SRUing to things other than Z!
[16:57] <tsimonq2> infinity: systemd-resolved Likes Breaking Everything.
[16:57] <infinity> bdmurray: Oh.  Indeed.  Yes, it's only needed in Z.
[16:58] <tsimonq2> infinity: https://ubuntuforums.org/showthread.php?t=2356828
[16:58] <slangasek> just noticed from the release announcement that the kernel versioning has caught up with Ubuntu's
[16:58] <slangasek> can I claim to be running zesty with a warty kernel?
[16:58] <apw> slangasek, we should do that, codename the kernel by the nearest ubuntu release by version
[16:59] <tsimonq2> infinity: I had this problem last night while doing QA and didn't think anything of it, but ubiquity didn't think I was connected to the internet. This might be why.
[17:00] <tsimonq2> infinity: When cyphermox comes back from his pea soup, he has more details. I sent him my logs, so he knows the terminology behind the broken bits.
[17:00] <bdmurray> "ukuu"?
[17:00] <infinity> tsimonq2: That forum post is not a remotely actionably bug report.
[17:01] <tsimonq2> infinity: Then let me get you a real one. bug 1647031 is pretty spot on.
[17:01] <ubot5> bug 1647031 in systemd "systemd-resolved’s 127.0.0.53 server does not follow CNAME records" [Unknown,New] https://launchpad.net/bugs/1647031
[17:01] <infinity> tsimonq2: That was fixed.
[17:03] <apw> yeah i remember that change going by
[17:03] <tsimonq2> infinity: Maybe. But it accurately describes the problems I'm seeing.
[17:03] <bdmurray> infinity: but it's "(VERY BAD !)"
[17:03] <infinity> bdmurray: Indeed.
[17:03] <slangasek> lp:~ubuntu-sru/britney/hints-ubuntu-zesty/ created fwiw
[17:03] <tsimonq2> All I know is that something regressed, infinity.
[17:04] <infinity> slangasek: Iz branch from dev?
[17:04] <slangasek> infinity: yes
[17:04] <infinity> \o/
[17:04] <slangasek> we ought to find a spot for that on the checklist, if we're ever to start using p-m directly for SRU releases
[17:04] <infinity> bdmurray: So, yes.  dkms is released, I'd recommend giving a couple of hours for downstream mirrors to pick it up before flipping meta-release.
[17:05] <infinity> slangasek: Probably belongs right at the end of ReleaseProcess.
[17:05] <bdmurray> infinity: roger
[17:08] <flocculant> thanks for the work release peeps - have a good break :)
[17:12] <slangasek> infinity: agreed and done
[17:16] <cyphermox> tsimonq2: tbf, your issue may or may not have anything to do with that forum port or the comments about DNSSEC
[17:17] <cyphermox> you should file a new bug; and test if disabling DNSSEC helps; but as I recall your issue was timeouts and that's probably not dnssec.
[17:21] <wxl> yeah tsimonq2 the fix on the forum is manually setting nameservers
=== tyhicks` is now known as tyhicks
[17:36] <infinity> bdmurray: Make that "wait at least 4 hours", as we only trigger tertiary mirrors every 4h.
[17:37] <infinity> bdmurray: So, meh.  If it gets late, change it in the morning.  Your call.
[17:37] <bdmurray> infinity: 4h is still mid-afternoon for me
[17:38] <infinity> bdmurray: Kay.  I say do it around your EODish, then.
[17:45] <tsimonq2> If I want to work on merges from Debian in universe, can I assume developers are checking bug reports with patches for the packages they upload?
[17:46] <tsimonq2> I mean, before uploading, do people check the sponsorship queue?
[17:46] <tsimonq2> ack wxl cyphermox
[17:49] <tsimonq2> Reason being, I anticipate being antisocial this weekend and making a dent in merges.ubuntu.com and I don't want to dup work
[17:49] <tsimonq2> :P
[19:05] -queuebot:#ubuntu-release- Unapproved: xapian-bindings (zesty-proposed/main) [1.4.3-1 => 1.4.3-1ubuntu1] (ubuntu-server)
[19:10] <wxl> if this networking problem is somehow related to systemd-resolv, then shouldn't EVERYONE be having a problem?
[19:12] <slangasek> the network is dark and full of terrors, and there could be any number of latent bugs in systemd-resolved that are only reproducible in select environments
[19:12] <wxl> alright, well, do we actually have a bug tracking all this?
[19:12] <slangasek> that's up to the person who's seeing the bug to file it
[19:13] <wxl> yeah. and i'm not. and so far haven't found one that is :/
[19:13] <slangasek> the dnssec problem is understood, and xnox is working on that
[19:13] <slangasek> but it's not at all clear that tsimonq2 is seeing a dnssec-related problem
[19:13] <slangasek> ("understood" in the sense of "we know resolved isn't doing dnssec right")
[19:13] <wxl> is that bug 1647031 ?
[19:14] <ubot5> bug 1647031 in systemd "systemd-resolved’s 127.0.0.53 server does not follow CNAME records" [Unknown,New] https://launchpad.net/bugs/1647031
[19:14] <slangasek> no
[19:14] <slangasek> also, why is that bug open again?
[19:14] <wxl> nextcloud
[19:14] <slangasek> oh a different task, right
[19:14] <wxl> for systemd, nm it's fixed
[19:14] <wxl> if you find one, let me know. meanwhile, brb
=== coreycb is now known as coreycb_vaca
[22:06] <cyphermox> tsimonq2: it's maybe a bit early for that seeing as AA isn't open; but it's customary to ask people who last uploaded/merged something before taking it, and that tends to reduce work duplication.
[22:09] <Ukikie> cyphermox: ...Aren't you supposed to be outside? ;)
[22:09] <cyphermox> I was outside for a moment to get a propane tank and food
[22:10] <tsimonq2> cyphermox: But but but... Adam said in his email we could get a head start if we wanted :D
[22:10] <tsimonq2> cyphermox: But yes, I always do that in the bug report anyways.
[22:10] <cyphermox> tsimonq2: you sure can, I'm just saying it can't be uploaded until the archive is open, by then, things may change.
[22:11] <cyphermox> I'm going to go back outside soonish, but there's work to be done still
[22:11] <tsimonq2> cyphermox: Ok :)
[23:24] <bdmurray> infinity: meta-release is done
=== Bashing-1m is now known as Bashing-om