[00:00] <slangasek> balloons: oh did you think my suggested binary package name of juju-1-i-hate-progress was a joke?  I was expecting to see that in the new queue ;-P
[00:01] <balloons> slangasek, you missed the contest earlier
[00:01] <balloons> I was soliciting names, and well, sinzui picked alfred
[00:01] <slangasek> ah but you still have to get it past AA
[00:01] <balloons> I thought it was a much better name, don't you think?
[00:09] <superm1> Laney: so is the service's autostart .desktop file changing for gnome-software?  you might need to adjust that casper thing I did a week or two ago to keep it from starting on live media then too
[00:11] <jderose> infinity: FYI, oem-config-gtk and ubiquity-frontend-gtk are missing after doing an OEM install from the 20160419 daily ISO (I recall before you mentioning that this can happen when the local archive is out of sync when the ISO is built)
[00:13] <flexiondotorg> infinity, slangasek cyphermox pitti I've just zsynced that latest image and I'm still seeing the swap issue - https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1552539
[00:13] <ubot5`> Launchpad bug 1552539 in casper (Ubuntu) "Ubiquity Erase Disk and Install Fails to create Swap Space" [Critical,Fix released]
[00:16] <flexiondotorg> If I boot the live desktop /dev/sda is mounted now.
[00:16] <flexiondotorg> Which was not happening previously.
[00:19] <slangasek> balloons, stokachu: juju-1-default needs to ship its /usr/bin/juju in the package, not create/remove it in the maintainer scripts
[00:22] <slangasek> flexiondotorg: well, please reopen the bug; I don't really have context on this particular issue, I guess it needs cyphermox to look at it
[00:24] <slangasek> except he may be EOD so it may be pitti's turn next
[00:25] <stokachu> slangasek: ^ the name change
[00:32] <balloons> slangasek, ohh..
[00:35] <balloons> slangasek, so you don't want to see a symlink, but rather a wrapper script installed in /usr/bin/jujuj?
[00:35] <slangasek> balloons: no, I want the link shipped by the package (and have just uploaded this fix)
[00:39] <balloons> slangasek, ack, gotcha.
[00:39] <balloons> ty
[00:40] <slangasek> infinity, cyphermox: ok, ubuntu-cpc/xenial/daily-preinstalled failed, with an error that I can't see is related to the latest change...
[00:41] <slangasek> yep, reverted latest commit and it still fails
[00:41] <slangasek> so, hmm?
[00:56] <cyphermox> slangasek: looking
[00:56] <cyphermox> all the last commit was supposed to do was to put it in ubuntu-server rather than ubuntu-cpc
[00:58] <cyphermox> slangasek: because no filesystem to use to build the image?
[01:01] <slangasek> cyphermox: that appears to be the error message
[01:01] <cyphermox> yeah
[01:01] <cyphermox> there is no filesystem build for today
[01:01] <slangasek> cyphermox: erm
[01:02] <slangasek> I have never seen this error before; there is a 'livecd-base' cronjob but I've never known this to be relevant
[01:03] <cyphermox> I think we're missing some hooks
[01:03] <cyphermox> the lp build wasn't triggered?
[01:22] <slangasek> cyphermox: so, no new build attempts shown here. https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/xenial/cpc
[01:22] <cyphermox> right
[01:23] <cyphermox> is that also happening from ubuntu-cdimage?
[01:26] <slangasek> cyphermox: what do you mean?
[01:27] <cyphermox> are the builds there triggered from ubuntu-cdimage code?
[01:27] <slangasek> erm
[01:27] <slangasek> cyphermox: that was what your patch was supposed to be implementing
[01:27] <slangasek> trigger build, download result
[01:27] <slangasek> publish
[01:27] <cyphermox> right
[01:28] <cyphermox> we got the download, rename result and publish done now, so I guess we're just missing the triggering
[01:28] <slangasek> heh, ok
[01:29] <cyphermox> I expected it worked, since infinity fixed my initial merge
[01:32] <cyphermox> did you get any output from running for-project ubuntu-cpc cron.daily-preinstalled ?
[01:34] <cyphermox> hrm
[01:35] <cyphermox> maybe that was missing --live.
[01:37] <cyphermox> slangasek: yeah, that's my best guess, the code that starts the livefs is user run_live_builds, which won't get called if you're not passing --live.
[01:38] <cyphermox> this could do with a unit test
[02:02] <rcj> slangasek, going to spin cloud images.  doesn't look like there's anything we're waiting on now but you might know better.  Shall I fire off builds?
[02:05] <slangasek> rcj: I don't know of anything you'd be waiting on; http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html is rather dull
[02:06] <slangasek> cyphermox: '--live'  - heh, was not part of the commandline I cut'n'pasted from infinity, no
[02:06] <rcj> slangasek, oh now that is indeed a very handy thing.  Thanks.  Just kicked builds.
[02:07] <slangasek> rcj: once upon a time we did reports that would show what on your latest image was out-of-date wrt the release pocket, maybe we should do something like that for -proposed also
[02:07] <cyphermox> slangasek: just my guess from looking at the code, I'm not at all familiar with how the images are built aside from looking at the logs in LP and p.u.c/~ubuntu-archive/cd-build-logs
[02:08] <cyphermox> well, getting thrown in the deep end certainly helps a lot, but I'm just a young padawan.
[02:08] <slangasek> cyphermox: you're right that almost all of these images are built with --live on the commandline, I forgot about it because I believe in sensible default behavior and Santa Claus
[02:08] <slangasek> cyphermox: this command is running something instead of exiting immediately - thanks ;)
[02:08] <cyphermox> yippee
[02:08] <rcj> slangasek, yeah, we have a manifest diff tool to know if we need to build a daily, but -proposed is opaque to us (and mostly that doesn't matter, just on weeks like this)
[02:08] <cyphermox> I get to wipe this rpi2 again soonish then
[02:23] <bluesabre> the above thunar package does not completely close any existing bugs, but should significantly reduce the number of crashes our users have experienced in testing
[02:28] <slangasek> infinity: hmm I think we can probably prune the various precise/daily* paths under www/full now
[02:30] <cyphermox> aren't those used for the unit tests?
[02:30] <slangasek> cyphermox: ... that is not a reason to keep cruft on our CD servers
[04:54] <tjaalton> doko, slangasek: I'll try to bisect llvm-3.7..3.8, the llvmpipe bug trigger should be there, since older mesa is just as affected
[04:57] <tjaalton> sigh, packaging still uses svn
[05:00] <cyphermox> oh cool, the cpc build worked and dropped things in the right place
[05:02] <slangasek> tjaalton: where did you see that older mesa was affected?
[05:02] <tjaalton> slangasek: from the bug? the original description
[05:02] <tjaalton> "Note this problem exists both when run against mesa 11.1.2-1ubuntu2 in Xenial proper.."
[05:06] <slangasek> tjaalton: ok, I wasn't considering the version currently in xenial "older mesa" ;)
[05:06] <tjaalton> heh, right, new one was staged at that point
[05:08] <slangasek> tjaalton: I did ask jderose to test with previous builds from xenial, so we could check whether this regressed when the llvm toolchain was switched or if it regressed at some other point.  I suspect something more recent, and that we weren't really completely broken for installs on nvidia for 2 months
[05:10] <tjaalton> slangasek: well this is mostly limited to skylake I bet, during 11.2~ bringup some new tests were failing (switch to dh enabled them) that I reported upstream (mesa), but it only happened on skylake builds. turns out it was due to llvm afterall
[06:24] <pitti> flexiondotorg: please reopen and attach a current installer syslog
[06:27] <tjaalton> slangasek: mesa llvmpipe tests pass fine with llvm-3.9 snapshot.. there's at least a commit to "Added Skylake client to X86 targets and features" which sounds like we should get
[06:52] <flexiondotorg> pitti, Doing now...
[06:52] <flexiondotorg> pitti, Just up to the point I ge the swap dialog?
[06:53] <flexiondotorg> Typical. Didn't do it this time :-(
[06:57] <flexiondotorg> pitti, OK. Reproduced. Just syslog?
[06:57] <pitti> flexiondotorg: partman log also can't hurt
[06:58] <flexiondotorg> pitti, Any in-particular you'd like them?
[06:58] <flexiondotorg> *Anywhere
[06:59] <flexiondotorg> This most recent image appears quite broken.
[06:59] <flexiondotorg> a11y indicator no longer working in Ubuntu MATE. oem-config stuff is absent.
[07:00] <flexiondotorg> pitti, syslog - http://paste.ubuntu.com/15942262/
[07:00] <pitti> flexiondotorg: can you please attach it to the bug?
[07:03] <flexiondotorg> pitti, As requested. https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1552539
[07:03] <ubot5`> Launchpad bug 1552539 in casper (Ubuntu) "Ubiquity Erase Disk and Install Fails to create Swap Space" [Critical,Fix released]
[07:03] <flexiondotorg> I have to go to work now.
[07:03] <pitti> cheers!
[07:06] <pitti> flexiondotorg: was that an UEFI/GPT install or mbr?
[07:10] <jibel> pitti, morning
[07:10] <pitti> bonjour jibel, ça va ?
[07:11] <jibel> pitti, what do you think about bug 1572325? There is one PPA but I don't think it is what is blocking the upgrade
[07:11] <ubot5`> bug 1572325 in ubuntu-release-upgrader (Ubuntu) "upgrade bug 14.04 to 16.04" [Undecided,New] https://launchpad.net/bugs/1572325
[07:11] <jibel> pitti, ça va bien et toi?
[07:11] <jibel> pitti, tu es à Londres?
[07:11] <pitti> ça va bien aussi, merci; non, je suis chez moi
[07:11] <pitti> virtual participant only :)
[07:11] <jibel> me too :)
[07:12] <jibel> pitti, it looks like the hwe stack is holding it back
[07:12] <jibel> too many upgrade bugs reporting in lp
[07:12] <pitti> meh, no apt term log
[07:13] <pitti> just let me set up that test install, then I'll have a look
[07:13] <pitti> tjaalton uploaded some metapackages for the hwe stack yesterday for upgrades, maybe/hopefully it's that
[07:13] <jibel> pitti, https://bugs.launchpad.net/ubuntu/+source/ubuntu-release-upgrader/+bug/1572325/+attachment/4640212/+files/VarLogDistupgradeAptlog.txt
[07:13] <ubot5`> Launchpad bug 1572325 in ubuntu-release-upgrader (Ubuntu) "upgrade bug 14.04 to 16.04" [Undecided,New]
[07:14] <jibel> the calculation fails
[07:14] <jibel> so there is no term.log
[07:18] <pitti> the first "Broken" which cannot be repaired is apparently: Broken xorg:amd64 Depends on xserver-xorg
[07:19] <jibel> probably similar to bug 1572298
[07:19] <ubot5`> bug 1571677 in xorg-lts-transitional (Ubuntu) "duplicate for #1572298 upgrading caused a broken apt cache due to *-lts-vivid packages conflicting with current X packages" [Undecided,Fix released] https://launchpad.net/bugs/1571677
[07:19] <pitti> meh, this is impossibly hard to read; I wish we had the output of apt that it normally shows
[07:20] <jibel> yeah it's terribly hard to read, must read backward, back and forth several times
[07:20] <jibel> recursive reading
[07:21] <jibel> with some practice it's readable but I didn't do it for a while.
[07:26] <nhaines> willcooke: oh, do you have a moment?  :)
[07:28] <willcooke> nhaines, just doing the school run.  Be back in 20 mins or so
[07:28] <nhaines> willcooke: thanks.
[07:30] <nhaines> Oh hey, I just found an error in my merge proposal, grr.  :)
[07:33]  * pitti promotes the xorg-transitional lot to main
[07:50] <doko> rbasak, fixed your percona-server-5.6 upload, but didn't test the test package
[07:52] <willcooke> nhaines, back
[07:52] <nhaines> \o/
[07:53] <nhaines> willcooke: I have an update for the package 'example-content' that I'd like to get reviewed and uploaded to xenial before release.  Also seb128 you listen, too.  :)
[07:53] <nhaines> I'm not sure whom to poke about it.
[07:54] <jibel> nhaines, seb128 is the last uploader
[07:54] <jibel> talk to him
[07:54]  * nhaines waves to seb128.
[07:55] <jibel> nhaines, or dholbach who is the original maintainer
[07:55] <nhaines> jibel: since he and dholbach weren't around an hour ago, I was looking for other alternatives.
[07:55] <jibel> nhaines, you'll find him on #ubuntu-devel
[07:56] <nhaines> jibel: oh!  I was expecting him at least in -locoteams.  Thanks!
[07:56] <seb128> shrug
[07:56] <seb128> nhaines, first, good morning
[07:56] <seb128> then I just joined IRC for like 1 minutes and you pinged me 3 times already
[07:56] <seb128> let's call down please :-)
[07:56]  * seb128 feels agresssed
[07:58] <nhaines> seb128: sorry, been working for about 12 hours today and falling asleep.  I'm just hoping to set up an overview before I do lose consciousness!
[07:58] <pitti> meh, no "prepare for OEM" icon on the desktop, /me files a bug
[07:58] <seb128> pitti, on what desktop?
[07:58] <seb128> nhaines, I can sponsor that in the next hour, unsure if the release team is wanting to take an update for it now though
[07:58] <pitti> seb128: when you install in OEM mode, the  oem session used to have a "Prepare for OEM install..." icon
[07:59] <pitti> that's also in the test case description on http://iso.qa.ubuntu.com/qatracker/milestones/359/builds/117327/testcases/1305/results
[07:59] <pitti> that went AWOL
[07:59] <seb128> pitti, oh ok, I didn't try OEM mode for a while
[07:59] <seb128> had forgotten about that ;-)
[08:00] <nhaines> seb128: great.  I know it's way too late, but there were all sorts of content licensing issues with the video submissions (that I subverted by just creating original content).  It turns out installing Ubuntu 24 times takes a very, very long time.
[08:00] <jibel> davmor2, ^ did you notice that?
[08:01] <jibel> pitti, usually it happens when oem-config on the iso and in the squashfs have different versions
[08:01] <jibel> ubiquity* in the squashfs
[08:01] <jibel> a respin should fix it
[08:02] <jibel> argh and i386 has not been copied to current/
[08:02] <seb128> jibel, just curious but in which way the icon fails to be created when those are out of sync?
[08:02] <pitti> err, there's not even an oem-config-prepare command
[08:02] <seb128> we should have an autopkgtest or something ensuring one doesn't migrate without the other one
[08:03] <pitti> yes, and ubiquity should be  current on the images
[08:03] <jibel> pitti, /pool/main/u/ubiquity/oem-config_2.21.59_all.deb is on the iso and ubiquity2.21.60 on the squashfs
[08:03] <pitti> this is deeper, I think the whole ubiquity/oem packages are missing
[08:03] <cjwatson> seb128: they're the same source package
[08:04] <cjwatson> jibel: hm, that usually only happens when the mirror is stale on cdimage, but I fixed that class of problems a little while back I thought
[08:05] <jibel> cjwatson, okay, so maybe it is not the problem then.
[08:05] <cjwatson> jibel: it is the problem, I'm just looking into why :)
[08:05] <jibel> ah :)
[08:06] <davmor2> jibel: notice what?
[08:06] <jibel> davmor2, no oem-prepare in the live session
[08:06] <pitti> bug 1572436
[08:06] <ubot5`> bug 1572436 in ubiquity (Ubuntu Xenial) ""Prepare for OEM install" icon missing on desktop" [High,New] https://launchpad.net/bugs/1572436
[08:06] <cjwatson> unlikely to be a ubiquity bug given this
[08:07] <pitti> err, I changed the bug title when filing the description, apparently that was ignored
[08:07] <cjwatson> -rw-rw-r-- 1 cdimage cdimage 293029 Apr 20 06:56 rsync.log.0
[08:07] <davmor2> jibel: there never is in the live session it is in the initial installed session, but I didn't bother with iso's yesterday as they were going to be respun
[08:07] <cjwatson> ok, so that's recent
[08:07] <davmor2> I'll try it now though
[08:08] <davmor2> Last time I tried it was there though so that was Friday
[08:08] <pitti> I attached the syslog
[08:08] <pitti> oem-config* does not get removed, but there's no sign of them getting installed either
[08:08] <jibel> davmor2, sorry, you're right
[08:09] <pitti> jibel: well, if that's the reason, we need to respin anyway
[08:10] <pitti> who can trigger respins these days?
[08:11] <cjwatson> pitti: won't get installed if it's uninstallable
[08:11] <cjwatson> pitti: I'm waiting for the rest of the London crew to get in before I start, just in case there's something else
[08:11] <pitti> cjwatson: ah, strict dependency on ubiquity, sure
[08:12] <flexiondotorg> pitti, It was mbr install.
[08:12] <pitti> but updated
[08:12] <pitti> flexiondotorg: ah, thanks
[08:14] <pitti> yofel: how important is http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#akonadi for the release? i. e. do we unblock and respin kubuntu for this?
[08:14] <yofel> pitti: hold off for that, I'm just making another upload, and once that's up we will need a respin as akonadi in release doesn't work at all with mysql 5.7
[08:15] <pitti> yofel: ack
[08:16] <pitti> we might want a full respin for http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#console-setup anyway (not sure if that's destined to an SRU or the final)
[08:16] <flexiondotorg> pitti, I found that reproducing the swap issue using VirtualBox was the most reproducible way.
[08:16] <flexiondotorg> So that test install was in VirtualBox.
[08:17] <flexiondotorg> You can reliably recreate the situation as follows.
[08:17] <cjwatson> this is certainly looking like full respin territory due to the cdimage mirror desync
[08:17] <flexiondotorg> Install Ubuntu 15.10 in VirtualBox. Do a full disk install without any encryption and withoutout LVM.
[08:18]  * adconrad glares at his colo machine going offline during release week.
[08:18] <pitti> hey adconrad
[08:18] <pitti> adconrad: wrt. your earlier ping, the new snapd is good; a test retry worked
[08:18] <flexiondotorg> After installed, boot 16.04 iso in the same VM and attempt a full disk install over that disk. You should run into the swap issue.
[08:18] <adconrad> pitti: Ta.
[08:18] <cjwatson> I can't quite puzzle out exactly why this happened, unfortunately; the timings only tell me that there was a build which thought it was running in parallel at 21:52:40 UTC, but not what it was running in parallel with
[08:19] <cjwatson> my suspicion is that we're locking the mirror a little too aggressively, for things that don't need the mirror, but meh
[08:20] <jamespage> hi release team
[08:20] <jamespage> we just hit a problem during final openstack testing on xenial today;
[08:20] <jamespage> we test on an openstack cloud, using the daily image stream's
[08:21] <jamespage> and the latest images are renaming the virtual network devices:
[08:21] <jamespage> Apr 20 08:06:00 ubuntu kernel: [    3.491798] virtio_net virtio0 ens2: renamed from eth0
[08:21] <adconrad> Is that not by design?
[08:21] <pitti> jamespage: I thought the latest cloud-init does that now?
[08:21] <tjaalton> jibel: do you have the transitional crap available?
[08:21] <pitti> I mean, stop hardcoding eth0 and supplying net.ifnames=0
[08:21] <pitti> and instead set up /e/n/i dynamically
[08:22] <pitti> i. e. I thought net.ifnames=0 got dropped deliberately, not accidentally
[08:22] <adconrad> jamespage: I suspect you want to talk to smoser, but pretty sure this is all working as he intended.
[08:22] <jamespage> pitti, I don't know the context for this change in behaviour
[08:23] <jibel> tjaalton, what do you mean?
[08:23] <tjaalton> jibel: what xorg-lts-transitional provides in xenial
[08:23] <tjaalton> use a mirror which has it
[08:23] <jibel> looking
[08:24] <nhaines> willcooke, jibel: everything got sorted with my issue.  Thanks for your help--now I get to go to sleep.  :)
[08:24] <jamespage> adconrad, pitti: cloud init has not changed since 15th
[08:25] <willcooke> nhaines, good stuff.  Enjoy sleep
[08:25] <jamespage> did we have a blip in daily image production?
[08:25] <adconrad> jamespage: Nothing else that would affect that has changed any more recently.
[08:25] <Odd_Bloke> jamespage: That's intended behaviour that changed in the image.
[08:25] <pitti> so what is the actual bug?
[08:25] <jamespage> Odd_Bloke, when did that change?
[08:26] <pitti> I suppose the net.ifnames= flag is not in cloud-init but in the cloud image build scripts (is that livecd-rootfs?)
[08:26] <Odd_Bloke> jamespage: I can check the exact timing, but I think it was early last week.
[08:26] <Odd_Bloke> Yeah, it's livecd-rootfs.
[08:26] <Odd_Bloke> jamespage: This was to align us with the rest of Ubuntu (including -server).
[08:28] <pitti> adconrad: apt in trusty/wily got fully tested with several upgrades and installs; any objection to me releasing now? might save a few failed upgrades
[08:29] <Odd_Bloke> jamespage: And it arrived so late because some matching cloud-init work was needed for us to not completely break all of our clouds during the development cycle.
[08:29] <jibel> tjaalton, I couldn't find a mirror with xorg-lts-transitional
[08:29] <adconrad> pitti: Go for it.
[08:30] <adconrad> jibel: Are you testing with universe enabled?  It needs seeding/moving to main, which I haven't done yet.
[08:30] <pitti> adconrad: it's done
[08:30] <pitti> but I only promoted them an hour ago or so
[08:30] <adconrad> Oh.
[08:30] <adconrad> pitti: Thanks.
[08:31] <jibel> adconrad, yes, universe it enabled
[08:31] <jibel> it is probably just not snyc to the mirrors yet
[08:33] <yofel> pitti: ^
[08:33] <pitti> adconrad: want me to unblock http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#console-setup now, so that we don't have to wait for that for the rebuild?
[08:33] <pitti> adconrad: (need to rebuild anyway due to the above mirror desync)
[08:33] <adconrad> pitti: It's not the only thing relevant to a new rebuild, I'll get everything at once.
[08:34] <pitti> adconrad: ack, leaving to you then
[08:34] <yofel> pitti: actually, please reject that
[08:34] <pitti> I'll look at that swap thing then
[08:34] <tjaalton> jibel: released one hour ago
[08:34] <pitti> yofel: rejected
[08:34] <yofel> thanks
[08:38] <yofel> pitti: now ^
[08:38] <tjaalton> doko: so llvm-3.8 needs backports to detect skylakes better. do you prefer a complete patchset with all the avx512-churn for xeons, or the bare minimum?
[08:40] <pitti> yofel: ack, thanks, waved through
[08:40] <yofel> pitti: thanks!
[08:40] <pitti> yofel: (only into -proposed, still needs an unblock to actually land)
[08:41] <rbasak> doko: ah I missed that. Thanks.
[08:41] <doko> tjaalton, isn't llvm maintained by the desktop team? ;p
[08:41] <adconrad> tjaalton: Is that the cause of jderose's complaints?
[08:41] <tjaalton> guess that'd be me
[08:41] <tjaalton> adconrad: most definitely
[08:41] <adconrad> tjaalton: So, there's a *chance* to fix it for release?
[08:41] <tjaalton> yes
[08:41] <adconrad> \o/
[08:42] <davmor2> jibel: confirmed oem-config is missing checking to see if it is on the system at all
[08:42] <doko> tjaalton, well, take what is likely to appear in the llvm 3.8 branch
[08:42] <rbasak> I think the build is a little unstable. I'll retry i386.
[08:42] <tjaalton> doko: I checked git, there's nothing for this. is there an upstream I can yell at?
[08:42] <jibel> davmor2, it's all right, don't waste your time one this
[08:42] <jibel> on*
[08:43] <pitti> davmor2: right, the oem bug is fully understood
[08:43] <davmor2> nice so another re spin in 10.....9......8......
[08:44] <pitti> davmor2: I think you should start counting at ~ 2000 rather
[08:46] <doko> tjaalton, ENOCLUE
[08:46] <jamespage> adconrad, pitti: just for full context on the behavioural change in the cloud-images - the change was made last week, but for various reasons the updated images did not get synced/into stream data until the last 24 hrs...
[08:48] <tjaalton> doko: trying sylvestre..
[08:49] <tjaalton> better yet, #llvm@oftc
[09:02] <pitti> flexiondotorg: is that "Erase ubuntu 16.04 LTS and reinstall" or "Erase disk and install Ubuntu"?
[09:02] <pitti> flexiondotorg: I think the former keeps the partitions but removes the files, the latter repartitions
[09:02] <flexiondotorg> pitti, Minute. In the middle of server deployment at work. Give me 5...
[09:04] <pitti> flexiondotorg: with the latter I get a correct mkswap/reactivate in syslog
[09:04] <pitti> trying the former now
[09:07] <LocutusOfBorg> asking a virtualbox exception in a few minutes
[09:07] <LocutusOfBorg> :(
[09:07] <flexiondotorg> pitti, "Erase disk and install Ubuntu"
[09:07] <LocutusOfBorg> upstream asked to include this one line patch https://www.virtualbox.org/changeset/60565/vbox/trunk/src/VBox/Devices/Storage/DevLsiLogicSCSI.cpp#file0
[09:08] <pitti> flexiondotorg: hm, that's what I tried
[09:10] <LocutusOfBorg> ^^
[09:11] <LocutusOfBorg> I also uploaded on debian, so we can just sync if needed
[09:11] <rbasak> And...my laptop PSU seems to be dead. Good week for it.
[09:11]  * rbasak watches his battery drop
[09:12] <apw> rbasak, oh man that sucks, what kind of machine is it
[09:12] <doko> LocutusOfBorg, the version number is wrong ...
[09:12] <rbasak> Samsung ARM Chromebook. It's OK, I have a computer here I can use too.
[09:13] <LocutusOfBorg> doko, what do you suggest
[09:13] <rbasak> (as in a desktop)
[09:13] <LocutusOfBorg> I uploaded -3 in debian, I want to sync
[09:13] <LocutusOfBorg> and cjwatson suggested a build1 to let autosync do its job
[09:14] <doko> LocutusOfBorg, well ... it has a delta. you don't know if you will have the time to sync ... but I don't care
[09:15] <LocutusOfBorg> pick the one you want ^^
[09:15] <LocutusOfBorg> :)
[09:15] <adconrad> Neither.
[09:15] <Laney> BOTH
[09:15] <cjwatson> LocutusOfBorg: I think I would have suggested -3~build1, not -2build1
[09:16] <LocutusOfBorg> well, ubuntu1 is fine, I can force sync after xenial
[09:16] <LocutusOfBorg> :)
[09:16] <Odd_Bloke> Laney: Needs more .0-ubuntu1? ^_^
[09:17]  * Laney the version doctor
[09:17] <doko> adconrad, the libsemanage rebuild didn't yet happen
[09:17] <pitti> no, please no "ubuntu" version numbers for no-change builds
[09:17] <adconrad> doko: Gah.  Doing over the next half hour.  Thanks for the reminder.
[09:21] <LocutusOfBorg> pitti, I did a change
[09:21] <LocutusOfBorg> it is a no change from debian -3 revision
[09:21] <LocutusOfBorg> I mean, -2ubuntu1 is the same as the upcoming debian -3
[09:22] <LocutusOfBorg> adconrad, upstream is looking at your modules patch
[09:22] <Laney> OK, enough of the version porn :P
[09:22] <LocutusOfBorg> BTW can anybody please make hedgewars migrate? it needs a rm of the powerpc binary I guess
[09:22] <LocutusOfBorg> since fpc is broken there
[09:22] <LocutusOfBorg> (also migrate fpc please)
[09:23] <LocutusOfBorg> we have ffmpeg fixes on proposed, I want people to use video recording features
[09:23] <adconrad> I might remove all the PPC rdeps of fpc for now, yeah.
[09:24] <LocutusOfBorg> it will require a bootstrap anyway I think
[09:25] <LocutusOfBorg> ta
[09:25] <LocutusOfBorg> I still hope to plain sync it, I don't like deltas
[09:26] <LocutusOfBorg> also adconrad "polybory/armhf" please remove
[09:26] <LocutusOfBorg> broken, we don't know why, we removed that binary on debian too
[09:26] <LocutusOfBorg> and nifti2dicom on powerpc
[09:26] <LocutusOfBorg> I did a lot of work on it
[09:27] <flexiondotorg> pitti, I'll try and create an image that will fail here.
[09:27] <flexiondotorg> If I can do that, I can snapshot and transfer it.
[09:27] <pitti> flexiondotorg: I'm currently trying with doing a manual install in the second round, someone got the error with that
[09:27] <pitti> flexiondotorg: getting the base image is no problem at all I figure
[09:28] <pitti> just have a swap partition on [sv]da5
[09:28] <flexiondotorg> I tried doing this with cyphermox.
[09:28] <flexiondotorg> pitti, Yes, just having swap seems to be sufficient, but not in an lvm.
[09:38] <Laney> RAOF: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#dovecot is making me sad with sadness
[09:40] <yofel> pitti: akonadi is built, could you please unblock it?
[09:41] <pitti> adconrad: ^ do you want to handle that together with your global sweep, or should I do that now?
[09:42] <cjwatson> pitti: if I do https://bugs.launchpad.net/ubuntu/+source/language-pack-kde-wa/+bug/1527035 is your stuff going to try to reupload it in an SRU?
[09:43] <ubot5`> Error: Could not gather data from Launchpad for bug #1527035 (https://launchpad.net/bugs/1527035). The error has been logged
[09:43] <cjwatson> what.  anyway, that's a removal request
[09:43] <pitti> cjwatson: as long as it stays below 5%, it won't; but if someone translates it enough it will come back, yes
[09:43] <pitti> cjwatson: but not -kde-*, those are manually maintained, those aren't me
[09:43] <cjwatson> ah ok
[09:44] <adconrad> pitti: Aye.
[09:44] <Laney> (xenial-amd64)root@nightingale:~# dpkg -L dovecot-core | grep --color=none so.0 | xargs ldd
[09:44] <Laney> /usr/lib/dovecot/libdovecot-fts.so.0.0.0: linux-vdso.so.1 =>  (0x00007ffce4745000) libstemmer.so.0d => /usr/lib/x86_64-linux-gnu/libstemmer.so.0d (0x00007faa0cda3000)
[09:44] <cjwatson> clickety
[09:44] <pitti> cjwatson: oh, wait -- I guess they were actually
[09:44] <pitti> cjwatson: we used to produce l-p-kde-*, but not for a long time; it still has a 14.04 version number
[09:45] <pitti> I guess we only kept them for upgrades, and can remove them wholesale post xenial
[09:45] <cjwatson> well, it was uninstallable anyway, so I've removed it
[09:45] <pitti> right, for this particular one
[09:45] <pitti> thanks
[09:50] <davmor2> pitti: I have a box I can reproduce the swapspace issue on before todays iso, I'll try todays and see if I can still reproduce it, the fix didn't land until the latest iso though right?
[09:50] <adconrad> rbasak: Can mysql-5.6 go now?
[09:50] <pitti> davmor2: there's no fix yet
[09:50] <rbasak> adconrad: as soon as percona-5.6 and pinba-engine-mysql have hit the release pocket, I think so, yes.
[09:50] <pitti> davmor2: I thought this was only on GPT, there the casper change could have helped, but as it also happens on MBR there's no change
[09:50] <rbasak> adconrad: what did you do to infinity?
[09:50] <davmor2> pitti: I thought you made a systemd change that could potentially fix it
[09:51] <adconrad> rbasak: The server infinity has been on for the last 4 years mysteriously died last night.
[09:51] <pitti> davmor2: yes, but it didn't
[09:51] <pitti> davmor2: I don't understand what happens so far, no luck in reproducing
[09:51] <rbasak> infinity: along with my laptop PSU and my openstack instance? Sounds suspicious.
[09:52] <davmor2> pitti: balls, I can see if I can reproduce the issue at least and enable ssh for you, you can dig around the system to your hearts content then
[09:52] <pitti> davmor2: i. e. ssh to a live session where ubiquity will fail? ok
[09:52] <pitti> not that I would actually know what partman is trying to do, but seeing it live might help
[09:53] <davmor2> pitti: let me see if I can reproduce it in live session first
[10:08] <Odd_Bloke> So I see that console-setup looks like it's going to migrate; is the plan to respin for that?  (And should I kick off a respin of cloud images once it lands?)
[10:08] <Odd_Bloke> infinity: ^
[10:09] <cjwatson> there needs to be a full respin anyway due to an image building snafu :-/
[10:10] <infinity> Yeah.
[10:11] <infinity> There's a full respin on the horizon.
[10:11] <infinity> Odd_Bloke: I'll poke you when we re-freeze for another respin, so you can get cloudy.
[10:12] <nhaines> Could someone review http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#example-content ?
[10:12] <bluesabre> infinity: is there any way we can get https://launchpad.net/ubuntu/+source/thunar/1.6.10-2ubuntu1 out of proposed before the full respin? :-)
[10:12] <infinity> bluesabre: It's on the way.
[10:12] <doko> Apparently successful
[10:12] <doko> final: console-setup,grilo-plugins,thunar,virtualbox
[10:12] <nhaines> It's a non-binary new content update, with the remaining Ubuntu Free Culture Showcase results.
[10:12] <bluesabre> infinity: thanks :)
[10:14] <Odd_Bloke> infinity: Ack, thanks. :)
[10:15] <rbasak> Struggling to edit the release notes - 500 Internal Server Error logging in :-/
[10:17] <rbasak> Now logged in but the page is immutable.
[10:17] <cjwatson> rbasak: bug 1564858 - I don't suppose you'd like to have a really quick look over "reverse-depends src:nagios-plugins"?  Some of those are false positives due to alternative deps, but at least some of the Recommends seem to be real and I'm loath to break those at the last minute
[10:17] <ubot5`> bug 1564858 in nagios-plugins (Ubuntu) "Please remove nagios-plugins from the archive" [Undecided,New] https://launchpad.net/bugs/1564858
[10:18] <rbasak> cjwatson: looking
[10:19] <infinity> LocutusOfBorg: Oh, you upstreamed my vbox patch?  Thanks!
[10:23] <LocutusOfBorg> yep :) thanks to you1
[10:23] <LocutusOfBorg> they already applied it in a similar way (they added a -revision part, to handle people building custom svn versions)
[10:23] <darkxst> vbox is the only thing holding us back from root-less Xorg ;(
[10:24] <LocutusOfBorg> darkxst, NO
[10:24] <LocutusOfBorg> NO NO :D
[10:25] <LocutusOfBorg> all the bothering I did here in the last few days was to have a root-less xorg with vbox
[10:25] <LocutusOfBorg> https://anonscm.debian.org/cgit/pkg-virtualbox/virtualbox.git/commit/?id=cc16e5049641855149fe9d6b091415bebcc58d3d
[10:25] <LocutusOfBorg> https://anonscm.debian.org/cgit/pkg-virtualbox/virtualbox.git/commit/?id=97c3c9c3056c7d2c21670a23f8e758921ffc12f2
[10:25] <darkxst> LocutusOfBorg, is that going to land before release?
[10:25] <LocutusOfBorg> already landed
[10:25] <LocutusOfBorg> :)
[10:26] <LocutusOfBorg> I tested it on a clean xenial and unstable virtualbox guests
[10:26] <LocutusOfBorg> everything is fine
[10:26] <darkxst> LocutusOfBorg, when?
[10:26] <LocutusOfBorg> yesterday
[10:26] <LocutusOfBorg> and some days before
[10:26] <LocutusOfBorg> the commit is from 6 days ago, and I tested it on debian
[10:27] <LocutusOfBorg> but I re-tested 5.0.18 yesterday, when I pushed it on unstable and xenial
[10:27] <rbasak> cjwatson: nagios-plugins and nagios-plugins-basic are taken over by src:monitoring-plugins as transitional packages. Here are my notes: http://paste.ubuntu.com/15944747/
[10:27] <rbasak> cjwatson: I think that covers all of them?
[10:28] <rbasak> cjwatson: I'd appreciate you double checking me here though.
[10:28] <darkxst> LocutusOfBorg, our spin from about 12 hrs ago, doesnt work with root-less X
[10:28] <LocutusOfBorg> darkxst, how did you test it
[10:29] <darkxst> LocutusOfBorg, remove xserver-xorg-legacy and restart gdm3
[10:29] <LocutusOfBorg> do you have a chan for discussing this?
[10:29] <LocutusOfBorg> -release might not be the best place
[10:29] <darkxst> #ubuntu-gnome
[10:29] <cjwatson> rbasak: oh, right, I totally missed the transitionals
[10:29] <cjwatson> rbasak: no-brainer then, thanks for the cluebat
[10:30] <cjwatson> teward,infinity: one of you two want to weigh in on https://bugs.launchpad.net/ubuntu/+source/electrum/+bug/1529681 ?  I'm pretty sure the answer is "no" but could use a proper explanation
[10:30] <ubot5`> Launchpad bug 1529681 in electrum (Ubuntu) "Please sync Electrum from Debian testing" [Undecided,New]
[10:37] <cjwatson> teward: (never mind, infinity did it)
[10:39] <cjwatson> sanity check, does https://bugs.launchpad.net/ubuntu/+source/juju-quickstart/+bug/1560512 still make sense given the current plan to keep both juju 1 and 2 in xenial?
[10:39] <ubot5`> Launchpad bug 1560512 in juju-quickstart (Ubuntu) "Please remove juju-quickstart from xenial" [Undecided,New]
[10:40] <cjwatson> jamespage: there's a question for you in https://bugs.launchpad.net/ubuntu/+source/openvswitch-dpdk/+bug/1549668; does it block removal?
[10:40] <ubot5`> Launchpad bug 1549668 in openvswitch-dpdk (Ubuntu) "Please remove openvswitch-dpdk from xenial" [Medium,Confirmed]
[10:40] <flexiondotorg> pitti, Anything useful I can do to help with the swap issue?
[10:40] <jamespage> cjwatson, yeah - the openvswitch source package now provides the dpdk binaries directly
[10:41] <jamespage> cjwatson, openvswitch-dpdk was a workaround for last cycle for universe...
[10:41] <cpaelzer> jamespage: beat me with the reply :-)
[10:41] <pitti> flexiondotorg: I guess the next steps is to find out what partman is doing precisely; if it issues shell commands, then running just those in a terminal might reproduce the issue as well
[10:41] <jamespage> so no I don't think that blocks removal - I'll comment
[10:41] <nhaines> Laney: could you take a look at http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#example-content for me?  I'd like to get that into release since we're respinning images anyway.  It's the Ubuntu Free Culture Showcase results.
[10:41] <pitti> flexiondotorg: there should be some swapoff, mkswap, swapon at least, maybe a wipefs too
[10:41] <cjwatson> jamespage: that seems like a non sequitur, the question is about ovs-vswitchd
[10:41] <cjwatson> (if that's dpdk-related, that's fine, but don't expect an archive admin to know that)
[10:42] <jamespage> cjwatson, thats the main binary name for ovs
[10:42] <jamespage> we have two versions - vanilla and dpdk enabled
[10:42] <cjwatson> ok, don't tell me, tell the bug :)
[10:42] <jamespage> cjwatson, I commented on the bug..
[10:42] <cjwatson> ah ok
[10:43] <cjwatson> thanks, that's all
[10:43] <cjwatson> I don't need to learn about ovs, I'm just trying to get the ubuntu-archive subscribed bug list under control :)
[10:43] <Laney> nhaines: Nothing to do there, it says it's a valid candidate
[10:44] <nhaines> Laney: oh!  It updated on me!
[10:44] <nhaines> infinity: thanks!  :)
[10:49] <flexiondotorg> pitti, OK. Are the partman commands issued via code in ubiquity or code in partman? I'll look through the source and see what it is doing.
[10:49] <pitti> flexiondotorg: I don't know for sure, but I think that's all partman
[10:49] <nhaines> Laney: thanks to you too.  :)
[10:50] <pitti> flexiondotorg: ideally partman.log would even tell the commadns it runs, but it doesn't
[10:51] <flexiondotorg> pitti, OK. I take a look at lunch time. 1 hr from now.
[10:55] <davmor2> pitti: see pm ssh all setup for you and system is in the warning screen
[10:55] <pitti> davmor2: thanks; just finishing my current thing, will then have a look
[10:59] <tjaalton> doko: how much does llvm need disk space when building?
[11:00] <LocutusOfBorg> tjaalton, around 50GB
[11:00] <tjaalton> sheesh..
[11:00] <LocutusOfBorg> probably a little more now
[11:00] <tjaalton> no wonder it didn't fit in my ramdisk..
[11:00] <doko> tjaalton, below 50G, succeeding on the buildd's ;)
[11:00] <LocutusOfBorg> doko, last time I checked it was increasing
[11:00] <doko> tjaalton, ahh, but we remove some part of the build before installing ...
[11:01] <LocutusOfBorg> well, with 3.8 there is an find *.a -delete before dh_install
[11:01] <LocutusOfBorg> so we save some space
[11:01] <tjaalton> heh, ok
[11:01] <tjaalton> I'll build it elsewhere then
[11:01] <infinity> doko: libsemanage sorted.
[11:02] <LocutusOfBorg> tjaalton, ppa? DebOMatic?
[11:02] <LocutusOfBorg> I can start a build if you give me a dsc
[11:02] <tjaalton> LocutusOfBorg: nah, locally with schroot, just need to attach another ssd..
[11:03] <LocutusOfBorg> as you wish
[11:03] <tjaalton> disabling avx512 on skylake, that should fix most issues but would still leave hsw-e with a big WTF
[11:03]  * LocutusOfBorg wonders if tjaalton found some brokeness on llvm
[11:03] <tjaalton> yes
[11:03] <LocutusOfBorg> please share :)
[11:04] <tjaalton> it enables features on skylake only found on xeons
[11:04] <tjaalton> breaks llvmpipe
[11:04] <tjaalton> llvm-3.9 is fine
[11:04] <LocutusOfBorg> :(
[11:04] <tjaalton> but dropping avx512 is something 3.8 might get upstream
[11:04] <tjaalton> so that's what I'll try
[11:06] <LocutusOfBorg> I see the bug
[11:11] <Laney> superm1: service> no, that bit is the same
[11:11] <Laney> you just rm-ed the file right?
[11:35] <xnox> Laney, cjwatson, infinity, apw: review please http://paste.ubuntu.com/15945830/
[11:49] <tjaalton> hm, how come libsemanage1-dev is uninstallable? can't build sssd
[11:50] <doko> tjaalton, proposed? infinity might need to re-upload the version which was removed before
[11:50] <tjaalton> ahh ok
[11:50] <tjaalton> saw that now
[11:53] <infinity> doko: I did.
[11:54] <infinity> tjaalton: Where are you seeing it uninstallable?
[11:55] <tjaalton> infinity: here, trying to build a version with a new patch
[11:56] <infinity> tjaalton: Seems installable to me...?
[11:57] <tjaalton> is it on archive.u.c yet?
[11:57] <infinity> tjaalton: Unless in conjunction with things like polkit in -proposed then, yes, wait a bit.
[11:57] <tjaalton> ah
[11:57] <tjaalton> yep
[11:58] <infinity> Should be resolved in ~10m.
[11:58] <tjaalton> cool, llvm build should finish about now so I'll just test that in the meantime :)
[12:04] <xnox> cjwatson, show the other template
[12:04] <xnox> which is like vlan_error
[12:04] <xnox> or some such.
[12:04] <xnox> which tells people to go away
[12:04] <cjwatson> vlan_failed?
[12:04] <xnox> cjwatson, netcfg/vlan_failed
[12:04] <xnox> yes
[12:04] <cjwatson> mkay, not ideal but would work
[12:27] <cjwatson> superm1: hm.  should I remove mythnettv-gui as well as mythnettv?
[12:27] <superm1> Laney: yes, sounds fine then
[12:28] <superm1> cjwatson: yes
[12:30] <cjwatson> superm1: all right, thanks, done
[12:31] <superm1> Thanks
[12:55] <tjaalton> infinity:  libsemanage1-dev : Depends: libsemanage1 (= 2.3-1build3) but 2.4-3build1 is to be installed
[13:04] <cyphermox> flexiondotorg: pitti: I take it the swap is still an issue?
[13:04] <pitti> cyphermox: yeah, keeping notes in the bug
[13:05] <pitti> being completely ignorant what actually happens in partman & co I'm tryign to understand this from strace
[13:05] <pitti> and of course totally not reproducible here
[13:05] <cyphermox> pitti: SSD?
[13:06] <pitti> I have an ssd, or QEMU etc., so faster devices, yes
[13:06] <pitti> davmor2's is spinning rust
[13:06] <cyphermox> yeah
[13:06] <cyphermox> I'm also on SSD and using QEMU. I'll dust one of the older laptops
[13:07] <cyphermox> so, I'll help testing on metal and spinning rust.
[13:07] <pitti> cyphermox: and of course enabling debugging (systemd-analyze set-log-level debug) just got davmor2 past the point where it failed
[13:07] <davmor2> pitti: and again
[13:07] <cyphermox> ok
[13:07] <davmor2> meh
[13:08] <davmor2> oh hang on though you said swapon failed right?
[13:08] <pitti> davmor2: again what? succeeded? I reset the log level back to info
[13:08] <davmor2> pitti: if swap on failed then the system won't try and use it for swap right?
[13:08] <pitti> davmor2: well, /dev/sda3 is in swapon -s, so whatever happened it's on right now
[13:09] <davmor2> pitti: okay let me try it again then
[13:10] <davmor2> pitti: error is back up
[13:11] <cyphermox> swapon must be doing some syscall we could trace with systemtap, so we'd know exactly who tries to bring up swap in every single case
[13:12] <pitti> cyphermox: the usual mechanics is that some program like mkswap open()s the device for writing, and on close() the kernel triggers a change uevent; this might then trigger $whatever
[13:12] <pitti> that's how udev, mdadm, etc. learn about newly created partitions
[13:12] <cyphermox> sure
[13:12] <cyphermox> but then they must call swapon
[13:13] <infinity> tjaalton: In a chroot?
[13:13] <pitti> I don't know systemtap, if that can tell us what happens between swapoff and mkswap (as that's where the bug is, *before* swapon in ubiquity), that'd be great
[13:13] <davmor2> pitti: I've given cyphermox the ssh access details too incase you need some extra eyes and I'm back on the error page
[13:13] <infinity> tjaalton: I don't see that in either proposed or release.
[13:13] <cyphermox> pitti: what do you mean before then?
[13:13] <infinity> tjaalton: You have a broken chroot.
[13:14] <cyphermox> davmor2: no, first I'll set up a pristine env in which I can reproduce
[13:14] <pitti> davmor2: ah nice, thus now I have a debugging log with the original error
[13:14] <cyphermox> pitti: the thing is, you kind of need to know what you're looking for to use systemtap.
[13:14] <pitti> cyphermox: ubiquity doesn't get to swapon, it's already failing at mkswap
[13:14] <tjaalton> infinity: alright then
[13:14] <cyphermox> ok
[13:14] <pitti> cyphermox: as it looks like, something (via udev) tries to call swapon while mkswap is still running/not done yet
[13:15] <cyphermox> pitti: only because the swap is already brought back "on" by something?
[13:15] <infinity> tjaalton: Looks like you half-upgraded to proposed at some point and then disabled it?
[13:15] <cyphermox> pitti: I can probably trace both calls
[13:15] <tjaalton> infinity: yep, for the mesa/llvm-3.9.. downgraded these bits now
[13:15] <pitti> cyphermox: yes; in strace, swapoff is called from ubiquity, then it calls mkswap; but before mkswap even opens the device for writing, it checks /proc/swaps and there sda3 is already back on
[13:16] <cyphermox> interesting
[13:16] <cyphermox> pitti: is the strace output in the bug?
[13:16] <infinity> pitti: What would be aggressively reenabling swap?
[13:16] <pitti> so it's "swapoff" - (something in the background runs swapon) -- ubiquity calls mkswap -- whoops, busy
[13:16] <infinity> pitti: That's a vile bug.
[13:16] <pitti> cyphermox: yes, I left everything in the bug so far
[13:16] <pitti> infinity: that's the answer we are looking for :)
[13:16] <cyphermox> pitti: infinity: yes, that was my understanding too
[13:17] <davmor2> pitti: could it be the size of the drive and memory in the system? It's a 1 TB drive and 8GB of memory that would make the swap bigger right?
[13:18] <pitti> davmor2: I'd say it's less likely; swapoff worked, so your system did not run out of RAM; also, 8 GB is plenty
[13:18] <cyphermox> pitti: that's why I was saying that I could maybe tell you which process calls swapon()
[13:19] <pitti> cyphermox: right; I think that'd be very useful
[13:19] <cyphermox> give me a sec, this should be a very simple script
[13:20] <pitti> I suppose it's some magic from the dev-sda3.swap systemd unit, but I can't trigger that behaviour with CLI tools
[13:20] <pitti> like, call swapoff manually, it doesn't come back on
[13:21] <pitti> cyphermox: so in that sense, systemtap is a bit like attaching strace to every process?
[13:21] <cyphermox> yeah
[13:22] <pitti> cyphermox: so, I finally got a debug journal while that bug happens; I'll attach it to the bug
[13:22] <pitti> Apr 20 13:11:21 ubuntu systemd[1]: dev-sda3.device: Changed dead -> plugged
[13:22] <pitti> Apr 20 13:11:21 ubuntu systemd[1]: dev-sda3.swap: Trying to enqueue job dev-sda3.swap/start/fail
[13:22] <pitti> Apr 20 13:11:21 ubuntu systemd[1]: dev-sda3.swap: Installed new job dev-sda3.swap/start as 2745
[13:22] <pitti> Apr 20 13:11:21 ubuntu systemd[1]: dev-sda3.swap: About to execute: /sbin/swapon /dev/sda3
[13:22] <pitti> that answers *what* calls swapon
[13:22] <pitti> now we need to understand how
[13:23] <cyphermox> well, then we're past the point systemtap can help
[13:23] <cyphermox> this would probably just be grepping through systemd
[13:24] <pitti> err, why is the swap partition in /etc/fstab
[13:24] <pitti> that's irritating
[13:24] <pitti> (in the life system, I mean)
[13:25] <pitti> anyway, need some time to ponder this
[13:25] <cyphermox> could it be that we write to fstab before calling swapon/mkswap?
[13:25] <knome> ;)
[13:25] <knome> hmm, oops
[13:25] <cyphermox> knome: that was an appropriate response actually ;)
[13:25] <pitti> cyphermox: oooh, we do that?
[13:25] <knome> happy i could help then :)
[13:25] <pitti> cyphermox: because that would totally explain it
[13:26] <cyphermox> pitti: I don't know, but I never checked *that*
[13:26] <pitti> cyphermox: hm, no, no fstab in the strace
[13:26] <pitti> cyphermox: I guess that's already done earlier, in casper maybe?
[13:27] <pitti> that fstab line explains why there's a dev-sda3.swap unit in the first place
[13:27] <pitti> it's read at boot, then /dev/sda3 gets an add/change uevent from the writing, systemd thinks "oh, my sda3 finally came online, let's mount/swapon this"
[13:28] <cyphermox> pitti: in casper?
[13:28] <cyphermox> oh, I see what you mean
[13:29] <pitti> well, that still doesn't explain why I wouldn't get that on the command line
[13:29] <cyphermox> I don't know, I thought it was maybe possible that when partman does the partitioning it would write to fstab before running mkswap
[13:29] <pitti> right, sounds plausible, but we ought to see that in the strace then
[13:29] <cyphermox> I don't know what you're tracing
[13:30] <cyphermox> this is all shell scripts
[13:31] <pitti> cyphermox: I basically just attached strace -fvvs1024 to the running ubiquity and then asked davmor2 to re-trigger the bug
[13:32] <pitti> and the -f traces all children too
[13:32] <cyphermox> well, I checked, the fstab.d scripts (what might write a swap entry to fstab) run from finish.d, so at the end, much after mkswap
[13:33] <cyphermox> was worth just making sure that it was indeed the case even if I didn't doubt it
[13:33] <pitti> ah, good, so this machine might be tainted now
[13:33] <cyphermox> why?
[13:33] <pitti> partman succeeded once, davmor went back to it to repartition to retrigger the bug
[13:33] <pitti> I mean if this isn't origianlly in /etc/fstab
[13:33] <cyphermox> oh, indeed
[13:34] <pitti> cyphermox: hm,  but shouldn't partman write the /target's fstab, not the life system's?
[13:34] <cyphermox> but we could reproduce this easily then
[13:34] <cyphermox> pitti: /target of course, yes
[13:34] <pitti> ok, nothign cares about that in the life system, so we can ignore that
[13:34] <cyphermox> right
[13:34] <pitti> /target isn't even mounted at this point
[13:35] <cyphermox> fwiw
[13:35] <cyphermox> scripts/casper-bottom/13swap:FSTAB=/root/etc/fstab
[13:35] <cyphermox> scripts/casper-bottom/12fstab:DESCRIPTION="Configuring fstab..."
[13:35] <cyphermox> scripts/casper-bottom/12fstab:FSTAB=/root/etc/fstab
[13:35] <pitti> yeah, 13swap is what I meant
[13:36] <pitti> my gut feeling is that a cheesy workaround for this would be to simply not write this to the life system's fstab
[13:37] <cyphermox> ubiquity should probably remove swap entries from the live fstab, or if we can just run swapon directly instead of adding to fstab.
[13:37] <pitti> I don't see why we actually need this -- we can swapon the partitions we find if we insist (although IMHO that goes a bit against "don't touch the hard disks")
[13:37] <pitti> I'd still like to actually understand the bug, though
[13:37] <cyphermox> pitti: not any more than zeroing it just before..
[13:37] <cyphermox> oh wait, nevermind
[13:38] <cyphermox> still, just adding it to fstab will have the same effect as running swapon
[13:38] <pitti> so, I do swapoff
[13:38] <cyphermox> yeah, then remove from fstab?
[13:38] <pitti> I am now trying to tickle the system so that it auto-swapons
[13:38] <cyphermox> oh ok
[13:39] <pitti> I tried blkid -p /dev/sda3, dd if=/dev/sda3 of=/dev/null, and even udevadm trigger --verbose --sysname-match=sda3
[13:39] <pitti> none of this triggers it, *grumpf*
[13:40] <pitti> davmor2: can you reliably reproduce this with every life system boot?
[13:40] <pitti> davmor2: I guess in order to try this you need to shut down the ssh session that you gave us?
[13:40] <pitti> hm, so do we want to try the above workaround, or do we want to continue debugging on this box..
[13:41] <pitti> not even mkswap triggers this
[13:41] <davmor2> pitti: indeed,  I have been able to reproduce it reliably on this box and the macbook with spinning platters since around final beta
[13:42] <davmor2> pitti: and I have been doing loads of installs on them so yes it is pretty reliable
[13:44] <pitti> davmor2: ok, could you try this: reboot the live system with break=casper-bottom, in the shell rm /scripts/casper-bottom/13swap, then continue and see if you still get the bug?
[13:44] <pitti> davmor2: (do you know where to add that breaks=?)
[13:45] <pitti> (mind you, this is not a fix, but its results are an useful data point)
[13:45] <pitti> and in the meantime I'll try to make some sense of this in a local VM
[13:45] <davmor2> pitti: nope
[13:46] <pitti> davmor2: ok:
[13:46] <pitti> 1) press a key at the human == keyboard screen, ack the language
[13:47] <pitti> 2) press F6, and then Escape to close the menu
[13:47] <davmor2> pitti: ah so end of the kernel line
[13:47] <pitti> you should now see a line "Boot options" ...
[13:47] <pitti> then <space> break=casper-bottom<Enter>
[13:48] <pitti> then you  should end up in a prompt like (initramfs)
[13:48] <pitti> where you rm /scripts/casper-bottom/13swap
[13:48] <pitti> and then just Ctrl+D to continue
[13:52] <davmor2> pitti: slightly different this is a uefi system so just hit e to edit the line added the break=casper-bottom after the boot=casper and that dropped me to the initramfs busy box to rm the script
[13:53] <pitti> davmor2: ah right, yes; that's a bit easier indeed
[13:56] <davmor2> pitti: try number 2 still got to the location page with no error I'll give it another couple of tries just to be sure
[13:57] <davmor2> pitti: try number 3 still no error
[13:57] <pitti> yay
[13:59] <davmor2> try number 4 no error
[13:59] <pitti> davmor2: can you now restart the live session normally, and re-trigger the bug?
[13:59] <davmor2> let me reboot now and see if I can still trigger it
[13:59] <davmor2> beat me to it
[13:59] <pitti> davmor2: another thing came to my mind which I'd like to see
[14:01] <davmor2> pitti: on reboot I am back to error dialogue
[14:01] <pitti> ok, good
[14:03] <davmor2> pitti: whats the other thing you'd like to try?
[14:03] <pitti> davmor2: I'm still figuring that out; I can do this in my own VM
[14:03] <davmor2> pitti: righto
[14:03] <pitti> but that at least means we have *a* way to prevent this
[14:07] <yofel> Hi, there's another ubiquity patch I would like to get in, as auto-login for kubuntu is broken: https://lists.ubuntu.com/archives/kubuntu-devel/2016-April/010350.html
[14:07] <yofel> (ubiquity doesn't chroot when editing the config)
[14:07] <yofel> Until when would I have to find someone (who?) that could help me with applying that? I could at least make a debdiff if that helps
[14:09] <cyphermox> I can apply the changes if it's fine for the release team to land this
[14:10] <Odd_Bloke> infinity: Reminder that it takes us about 24 hours to publish cloud images, so we're beginning to push towards infringing on your drinking time tomorrow evening if we don't kick off our respin soonish. ;)
[14:10] <infinity> Odd_Bloke: So, not something we can solve today, but is there something we can do to make that not a 24h process?
[14:11] <infinity> Odd_Bloke: (And requiring us to be ready more than a day in advance because you need to be is... Special)
[14:11] <Odd_Bloke> infinity: Not much; replicating to Azure just takes for-frickin-ever.
[14:11] <infinity> Odd_Bloke: Is that being done from our DC, or from Azure itself?
[14:11] <Odd_Bloke> infinity: We publish the image once from our DC, then tell Azure to replicate it internally.
[14:11] <infinity> Odd_Bloke: (ie: if you pushed RC images to an Azure instance, rsynced Final images over them, and pushed from there...?)
[14:12] <Odd_Bloke> infinity: ("tell" via API)
[14:13] <Odd_Bloke> infinity: So the slowness is all on Azure's side.
[14:13] <infinity> I'm not sure the entire release process should be at Azure's mercy. :P
[14:13] <infinity> (That's never been true before)
[14:14] <Odd_Bloke> infinity: IME, in the past we've normally gotten away with using an RC from Tuesday or earlier.
[14:14] <infinity> Odd_Bloke: Who's "we"?
[14:14] <Odd_Bloke> infinity: Once the RC is sync'd final release is an easy switch flip.
[14:15] <Odd_Bloke> But we don't yet have an RC.
[14:15] <infinity> Odd_Bloke: Do you mean the cloud people just don't bother respinning when the rest of us fix something on Wednesday?
[14:15] <Odd_Bloke> Sorry, I realise I didn't make that clear.
[14:15] <Odd_Bloke> infinity: Not if it's in installer or desktop stuff, no. :)
[14:16] <pitti> davmor2, cyphermox: https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1552539/comments/27
[14:16] <ubot5`> Launchpad bug 1552539 in ubiquity (Ubuntu) "Ubiquity Erase Disk and Install Fails to create Swap Space" [Critical,Confirmed]
[14:16] <pitti> I am now able to reproduce this with some shell code, with a plausible explanation
[14:16] <pitti> cyphermox: that assumes that partman actually removes and re-adds the partition after swapoff and before mkswap
[14:16] <Odd_Bloke> (That's what I mean by "getting away with"; changes not being in packages we have on our images :)
[14:16] <pitti> cyphermox: which sounds plausible and right, just would like to confirm that this is what happens
[14:17] <cyphermox> pitti: what?
[14:18] <cyphermox> I suppose, but partman has been doing the same thing for swap in $forever
[14:18] <pitti> cyphermox: I mean, does ubiquity/partman remove and add the swap partition in between swapoff and mkswap?
[14:18] <pitti> cyphermox: yes, as I said this is correct behaviour, I'd just like to know if it actually happens that way
[14:18] <cyphermox> ubiquity just does things via partman
[14:19] <cyphermox> I suppose it does -- look at partman-basicfilesystems
[14:19] <cyphermox> just running swapoff; mkswap will do that remove then add
[14:19] <cyphermox> ie -- you're disabling it, wiping the old one to make a new one
[14:20] <pitti> cyphermox: no, that doesn't reproduce it, as that leaves the actual /dev/sdaX in place
[14:20] <cjwatson> Odd_Bloke: We haven't had actual RCs for years, but you could just pick the latest daily.
[14:20] <pitti> i. e. the partition contents changes, but not the device for the partition itself -- you need to change the partition table for that
[14:20] <pitti> and the latter is what triggers this bug (which is why I couldn't reproduce it with the commands before)
[14:20] <cjwatson> Odd_Bloke: (but granted that doesn't help if we actually need to change something)
[14:21] <cyphermox> pitti: you'd see which partitions change in the confirm dialog in ubiquity
[14:21] <Odd_Bloke> cjwatson: Yeah, we use dailies for RCs, but infinity earlier said that there were changes coming for a respin so I've disabled our automatic build trigger so that we don't have a build in-progress when we want to kick off another build.
[14:21] <pitti> cyphermox: right; and I suppose it just writes the new partition table to /dev/sda (trying to find that in the strace, not easy to see but I figure it's there somewhere)
[14:22] <infinity> Odd_Bloke: The current state of the archive should be safe for you to do cloud builds.
[14:22] <infinity> Odd_Bloke: Right up until pitti and/or cyphermox change something you use. :P
[14:22] <pitti> infinity: so I pretty much understand the bug and we have *a* solution
[14:22] <cyphermox> not planning on changing anything right now
[14:22] <Odd_Bloke> infinity: OK, build kicked.
[14:23] <Odd_Bloke> Thanks!
[14:23] <infinity> pitti: Is the solution in casper/ubiquity?
[14:23] <infinity> pitti: If so, cloudy people are safe. :P
[14:23] <pitti> it's not necessarily elegant, but should do (davmor tested it)
[14:23] <pitti> yes, casper, and cloud is safe
[14:23] <infinity> Ta.
[14:23] <infinity> Their modern new world seem to move a lot slower than our old, "obsolete" world. :P
[14:23] <pitti> there might be a more complicated/elegant one, but at this point in time I'd frankly just go with changing the 13swap hook in casper to just call mkswap instead of adding to the life system's fstab
[14:24] <pitti> or we leave swap alone entirely
[14:24] <Odd_Bloke> infinity: Only Azure.  :p
[14:25] <cyphermox> pitti: you mean swapon, not mkswap?
[14:25] <pitti> err yes, sorry
[14:25] <cyphermox> ok :)
[14:30] <pitti> infinity, cyphermox: http://paste.ubuntu.com/15949514/
[14:31] <pitti> as I said, not necessarily brilliant or elegant, but I think appropriate at this point
[14:31] <cyphermox> pitti: let's just make sure that once the system is booted we really do have a swap available then
[14:32] <pitti> meh, forget that patch
[14:32] <pitti> no swapon in the initrd
[14:32] <cyphermox> :(
[14:32] <cyphermox> call the target's ? ;)
[14:32] <pitti> heh, I figure we could do that (I'm just testing it in VM)
[14:32] <cyphermox> it's going to be even uglier.
[14:33] <pitti> yeah, /root/sbin/swapon does not find libmount.so, and chroot /root swapon doesn't have /dev mounted
[14:33] <cyphermox> wow
[14:33] <pitti> I'm beginning to understand why we wrote it to fstab instead of just calling swapon :)
[14:33] <superm1> make a systemd job in the target to swapon once you pivot roots?
[14:33] <cyphermox> could we inject a unit to swapon once?
[14:34] <pitti> normally that job is "fstab" :)
[14:34] <cyphermox> yeah, but we can't otherwise inhibit's systemd fiddling with partitions
[14:34] <pitti> but yes, we can inject another unit into /root/run (but that's not mounted yet either)
[14:34] <superm1> maybe uglier but how about another job after fstab finishes to delete lines from fstab related to swawp?
[14:35] <pitti> thought about that too, or just disable the .swap unit
[14:35] <pitti> or copy swapon into the casper initrd
[14:37] <Laney> add a preset to disable *.swap?
[14:37] <pitti> well, entirely disabling swap is much easier
[14:37] <pitti> just remove that 13fstab script
[14:37] <pitti> (that's what davmor tested)
[14:38] <pitti> the other is copy_exec /sbin/swapon, and just call it from the life initrd
[14:39] <pitti> LD_LIBRARY_PATH=/root/lib/x86_64-linux-gnu /root/sbin/swapon works, so it's just the libraries, nothing else
[14:40] <pitti> or we change partman to disable the swap units which it touches, but that's more intrusive (affects d-i and cloud)
[14:40] <pitti> well, not cloud
[14:45] <tjaalton> infinity: I've got a working llvm by dropping all features from skylake that 3.9 thinks belong to server cpu's. but looking at what happened between 3.7..3.8 there's just one feature that got added to skylake ("protection keys"), I'll try dropping just that
[14:46] <pitti> infinity, cyphermox: V2: http://paste.ubuntu.com/15949860/
[14:48] <pitti> ^ same diff, in case you want to go with that
[14:49] <pitti> I tested the copy_exec on a regular desktop install with installing that updated casper, and ensuring that /sbin/swap on was in the initrd (libmount.so already was before, though)
[14:53] <jderose> infinity: I filed a bug about oem-config-gtk not being installed after an OEM install - https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1572615
[14:53] <ubot5`> Launchpad bug 1572615 in ubiquity (Ubuntu) "xenial 20160419: oem-config-gtk not installed after OEM install" [Undecided,New]
[14:53] <cyphermox> what?
[14:54] <seb128> jderose, bug #1572436
[14:54] <ubot5`> bug 1572436 in Ubuntu CD Images ""Prepare for OEM install" icon and oem-config-prepare missing on desktop" [High,Confirmed] https://launchpad.net/bugs/1572436
[14:54] <tjaalton> jderose: on that llvmpipe bug you mention that some haswells are affected.. are you sure it's the same bug?
[14:54] <jderose> seb128: thanks! marked mine as a duplicate
[14:55] <seb128> jderose, thanks
[14:56] <cyphermox> infinity: user-setup for yofel's issue ^, that will also need an ubiquity refresh, as usual.
[14:56] <jderose> tjaalton: not sure about Haswell (I'll check that shortly), but it does seem to effect Haswell-E. so I'm guessing it's only when certain CPU extensions are available that llvm is (seemingly) generating invalid code
[14:57] <tjaalton> jderose: right, I've looked at llvm today and I can fix skylake, but HSW-E is weird, there should be no difference really
[14:58] <jderose> tjaalton: you come across any upstream llvm 2.8.x fixes that seem promising?
[14:58] <tjaalton> nah I'll drop a cpu feature that should be only for server cpu's
[14:59] <tjaalton> right now I'm testing if it's enough to drop the only one that got added in 3.8
[14:59] <tjaalton> and leave the others
[15:01] <jderose> tjaalton: do you happen to have your llvm 2.8 patches with Skylake fixes available in a PPA so I can help test?
[15:01] <tjaalton> not in a ppa, builds take far too long for that
[15:02] <tjaalton> I'll put this somewhere once I know more
[15:02] <jderose> tjaalton: awesome, thank you very much. please let me know anywhere i can help :)
[15:04] <jderose> tjaalton: as soon as i'm in the office, i'll double check things on Haswell-E... but we were definitely having problems on these systems early last week
[15:04] <tjaalton> sure, I need to know the cpu model id from /proc/cpuinfo
[15:05] <jderose> k
[15:06] <pitti> cyphermox: user-setup needs a corresponding ubiquity and d-i upload, right?
[15:06] <cyphermox> no just ubiquity
[15:07] <cyphermox> I don't know if you were going to be doing a respin though, and if it's worth putting in for that respin
[15:07] <lamont> https://bugs.launchpad.net/ubuntu/+source/python-formencode/+bug/1569035 <-- do y'all care enough about that for us to upload it before release, or shall we just go for the 0-day -updates mentality?
[15:07] <ubot5`> Launchpad bug 1569035 in python-formencode (Ubuntu) "Packaging error causing installation to /debain/usr/..." [High,Confirmed]
[15:07] <pitti> cyphermox: I thought we'd respin for the swap issue anywa
[15:07] <lamont> jamespage: ^^ any strong opinion to throw into the mix?
[15:07] <cyphermox> ok, will get you a ubiquity update then
[15:07] <jamespage> lamont, not specifically
[15:07] <pitti> cyphermox: I let it into -proposed now, for testing etc.; infinity can still decide whether or not to let it in (it'll be blocked)
[15:08] <pitti> cyphermox: and someone other than me still needs to review casper anyway
[15:08] <lamont> jamespage: if release team decides they want it today, I'll smack it through (should be trival to fix), otherwise I'm gonna focus on other crits and worry about it post-release
[15:08] <cyphermox> yep
[15:08] <jamespage> lamont, fine withme
[15:08] <jamespage> lamont, I think maas it the primary consumer of this right?
[15:09] <lamont> possibly the sole consuimer
[15:10] <pitti> it's seeded on ubuntu-server
[15:10] <pitti> so in principle we don't already have another reason to respin it so far
[15:11] <pitti> but if the server team can re-test new images, no objection from me
[15:12] <jderose> tjaalton: isantop is in the office, is going to get /proc/cpuinfo output from our Haswell-E systems
[15:13] <tjaalton> jderose: cool, thanks
[15:23] <pitti> apw: new linux landed, but not http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#linux-raspi2, is that intended?
[15:23] <apw> pitti, we are about to get new ones ... for raspit
[15:26] <stokachu> ive got a few last minute updates to my openstack package is it to late to upload?
[15:27] <stokachu> even if i need to file a bug to have it processed once the release is done
[15:28] <rbasak> infinity: I think we can remove src:mysql-5.6 now, but please double-check. reverse-depends is probably behind.
[15:29] <rbasak> (yes, it is)
[15:31] <coreycb> infinity, can we seed neutron-vpnaas and aodh into main for xenial?  their MIRs were just approved.
[15:31] <isantop> jderose / tjaalton: Both cpuinfo files are attached to the LP bug https://bugs.launchpad.net/oem-priority/+bug/1564156
[15:31] <ubot5`> Launchpad bug 1564156 in llvm-toolchain-3.8 (Ubuntu) "xenial: invalid opcode when using llvmpipe" [Undecided,In progress]
[15:34] <tjaalton> isantop: thanks, nice machines..
[15:36] <infinity> coreycb: Bugs?
[15:36] <teward> infinity: have you had a chance to poke the nginx bug for a review for FinalFreeze breaking?
[15:37] <infinity> teward: Not yet.
[15:37] <seb128> do we have an edubuntu release (I saw stgraber graber about not being a LTS, but unsure if there is an iso)
[15:38] <coreycb> infinity, bug 1482765 and bug 1546728.  jamespage said the seeds are ready to go.
[15:38] <ubot5`> bug 1482765 in neutron-vpnaas (Ubuntu) "[MIR] neutron-vpnaas" [Undecided,Fix committed] https://launchpad.net/bugs/1482765
[15:38] <ubot5`> bug 1546728 in aodh (Ubuntu) "[MIR] aodh" [High,Fix committed] https://launchpad.net/bugs/1546728
[15:38] <infinity> lamont: lolz.
[15:38] <teward> infinity: OK
[15:38] <seb128> or asked differently, is software-center still on some iso? it losts its translations, I've an update to fix that
[15:38] <infinity> lamont: Fix it fast, we're respinning "soon".
[15:38] <seb128> unsure if that would mean respining somewhere though
[15:38] <jamespage> infinity, coreycb: http://paste.ubuntu.com/15951098/
[15:38] <jamespage> diff for seed
[15:41] <lamont> infinity: ack.  is it on the media?
[15:41] <infinity> lamont: It's on server media, yeah.
[15:41] <lamont> sigh
[15:41] <infinity> formencode-i18n (from python-formencode) is seeded in:
[15:41] <infinity>   ubuntu-server: daily
[15:41] <infinity> python3-formencode (from python-formencode) is seeded in:
[15:41] <infinity>   ubuntu-server: daily
[15:41]  * lamont makes it his top-of-day
[15:41] <infinity> lamont: Top being RFN.
[15:42] <infinity> jamespage: Commit the seeds, I'll sort the fallout.
[15:42] <jamespage> infinity, done
[15:42] <jamespage> infinity, not on media for reference...
[15:43] <infinity> jamespage: Ta.
[15:45] <coreycb> jamespage, infinity: thanks
[15:46] <infinity> seb128: edubuntu isn't releasing, no.
[15:46] <jderose> i added a bit about the new privilege separation features in Apt 1.2. those with more knowledge about it, please feel free to fact check me, refine it for accuracy - https://wiki.ubuntu.com/XenialXerus/ReleaseNotes#Apt_1.2
[15:47] <seb128> infinity, k, the bot seems to suggest that the package is on mythbuntu though, but I guess that's getting a respin?
[15:47] <seb128> infinity, thanks for accepting in any case ;-)
[15:47] <infinity> teward: nginx FFe looks fine, any chance you planned to upload?
[15:48] <infinity> seb128: The bot is wrong.
[15:48] <seb128> I see
[15:48] <infinity> (due to packagesets being out of sync with reality)
[15:52] <slangasek> infinity: are you going to apply those packageset changes?
[15:53] <infinity> slangasek: Yeah, Laney and Colin and I were literally just going to go through the list.
[15:53] <slangasek> ok
[15:53] <slangasek> infinity: I'm also posting it to ubuntu-devel
[15:53] <infinity> After I re-run the update script yet again to reflect up-to-the-minute reality.
[15:53] <infinity> slangasek: Sure.
[15:53] <slangasek> ok, I'll wait for that list and then post it to ubuntu-devel :)
[15:53] <infinity> slangasek: packagesets can be aletered post-release, so it's not world-ending if we get it a bit wrong, but I'd like it mostly right.
[15:54] <lamont> infinity: verfied that it built the right files and e'rything
[15:54] <infinity> Once the archive settles from the current crop of uploads, I think the next spin will be "final", barring something truly RC.
[15:54] <infinity> lamont: Good, good.
[15:56] <teward> infinity: yeah, i wanted your ACK on it first
[15:56] <teward> it'll be uploaded in about an hour after lunch
[15:57] <apw> infinity, the firmware respins ^
[15:57] <ogra_> yay
[15:57] <lamont> oops
[15:57] <ogra_> infinity, note that needs changes in livecd-rootfs once these landed
[15:57] <lamont> and... uploaded to ubuntu this time. :(
[15:58] <ogra_> (the firmware bits)
[15:58] <ogra_> apw, does the raspi one include the wlan firmware for rpi3 too ?
[15:59] <infinity> ogra_: I know.
[15:59] <infinity> ogra_: Already staged locally, pending my review of the name changes.
[15:59] <ogra_> infinity, cool
[15:59] <apw> ogra_, it includes whatever the old one did
[16:00] <ogra_> apw, bah, not updated from upstream ?
[16:00] <infinity> ogra_: We wanted to, but Paolo was unsure about breaking something.
[16:00] <ogra_> (iirc the rpi firmware got updated on github to include the wlan bits for pi3)
[16:00] <infinity> ogra_: So, we'll update post-release with proper testing, etc.
[16:00] <apw> ogra_, no, ppisati said we could not because you would need to fix uboot or something
[16:00] <ogra_> yeh, fine with me
[16:00] <infinity> ogra_: This update was just to fix the naming.
[16:01] <ogra_> cool then
[16:02] <ogra_> apw, hmm uboot shouldnt care about linux-firmware :) ... but we'll sort it in an sru
[16:02] <apw> ogra_, somrthing about the dtb moving ..
[16:02] <ogra_> oh ?
[16:03] <ogra_> well, i'll talk to him ... but given gadget and kernel snap are being re-worked completely in the next weeks i guess we can solve any blockers here
[16:03] <infinity> lamont: Was dropping that find | rm intentional?
[16:06] <flexiondotorg> I can see everyone's busy but if there is a sponsor for this it would be great - https://bugs.launchpad.net/ubuntu/+source/ubuntu-mate-artwork/+bug/1572120
[16:06] <ubot5`> Launchpad bug 1572120 in ubuntu-mate-artwork (Ubuntu) "ubuntu-mate-artwork 16.04.7 bug fix release [dsc attached]" [Undecided,New]
[16:07] <flexiondotorg> Adds fixes recently added to Ubuntu. Does NOT have to be in for the upcoming image respin.
[16:07] <lamont> infinity: hrm
[16:08] <lamont> infinity: hrm.
[16:08] <slangasek> infinity: ^^ so I notice we still don't have linux-snapdragon in xenial... do you know if that's supposed to be fixed before tomorrow?
[16:09] <tjaalton> jderose, isantop: can you try building mesa on the haswell? enable tests by dropping the override in rules. if it's hitting the same bug then llvmpipe tests should fail
[16:09] <infinity> slangasek: We're on it.
[16:09] <slangasek> infinity: ok
[16:09] <lamont> infinity: -0ubuntu5 uploaded, good catch.
[16:09] <jderose> tjaalton: yup, sure
[16:10] <pitti> lamont: p-formencode LGTM, accepted; but it'll be blocked by britney, I'll leave the unblock to Adam (if we want it on the final ISO), otherwise it's going to end up as an SRU
[16:11] <jderose> tjaalton: so just drop the "override_dh_auto_test:" line in debian/rules?
[16:11] <pitti> lamont: oh, I thought that was part of the fix
[16:11] <tjaalton> jderose: yep
[16:11] <jderose> k, on it
[16:14] <lamont> pitti: it was fatfingers
[16:14] <lamont> and only checking formencode-i18n :/
[16:14] <infinity> tjaalton: So, llvm vs mesa.  What's the verdict?  You're pretty much out of time.
[16:14] <pitti> lamont: ok; still waiting on the LP diff to get generated, then will look at 5
[16:14] <lamont> ta
[16:14] <slangasek> jamespage: hi, you've seeded aodh and neutron-vpnaas, I see approved MIRs for these two but the python-gnocchiclient dependency has an incomplete MIR
[16:15] <tjaalton> infinity: I can drop avx512 and the subvariants(!) from skylake feature set. leaves the haswell-e out in the cold though
[16:15] <cyphermox> ubiquity:  for user-setup, if you decide to land the fix for yofel's SDDM autologin issue ^
[16:15] <infinity> tjaalton: Out in the cold in what sense?
[16:15] <infinity> tjaalton: Degraded performance, or broken?
[16:16] <tjaalton> infinity: jderoes says it has a similar issue as skylake on that bug
[16:17] <tjaalton> but hitting this issue needs a gpu that isn't properly supported by oss drivers
[16:17] <jamespage> slangasek, urgh
[16:17] <pitti> cyphermox: ack, thanks; I'll review/accept (diff still pending) so that it is sitting in -proposed next to the updated user-setup; we either land both or none
[16:18] <tjaalton> infinity: I'd say it's still something
[16:18] <flexiondotorg> tjaalton, https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/1522922/comments/107
[16:18] <ubot5`> Launchpad bug 1522922 in xserver-xorg-video-intel (Ubuntu) "Screen flickering in Intel i915 driver" [High,Triaged]
[16:18] <tjaalton> flexiondotorg: they'll deal wit hit
[16:19] <flexiondotorg> tjaalton, Out of interest, who is they?
[16:19] <tjaalton> intel
[16:19] <slangasek> jamespage: neutron-vpnaas is clean, I've promoted it now.  aodh will need something done with LP: #1536887
[16:19] <ubot5`> Launchpad bug 1536887 in python-gnocchiclient (Ubuntu) "[MIR] python-gnocchiclient, python-gnocchi, python-pandas" [Undecided,Incomplete] https://launchpad.net/bugs/1536887
[16:19] <infinity> tjaalton: No way to fix it for haswell-e as well?
[16:19] <infinity> (And how common is haswell-e?)
[16:19] <cyphermox> pitti: indeed
[16:20] <jamespage> slangasek, I think thats a not this release then
[16:20] <jamespage> slangasek, I'll unssed aodh
[16:20] <tjaalton> infinity: I don't know what's causing it. HSW-E is the $400-600 six-core cpu
[16:20] <slangasek> infinity, tjaalton: indeed, I would expect dropping that insn to just result in performance degradation, so that it "only" works as well as it does on other chips already
[16:20] <slangasek> jamespage: cheers
[16:20] <jamespage> slangasek, done
[16:21] <infinity> tjaalton: Well, some fix is better than none.  If we could do the same fix for haswell-e, that would be nice.
[16:21] <infinity> tjaalton: But we've run out of time, so if we're fixing anything, it needs to be NOW.
[16:21] <pitti> lower performance for final and SRUing a better fix later on seems ok
[16:21] <tjaalton> slangasek: yeah, and the real WTF moment hit me when the cpu model id on my low-power SKL-Y laptop is the same llvm checks for server features..
[16:21] <tjaalton> infinity: I'll push it
[16:21] <tjaalton> actually
[16:22] <tjaalton> jderose: please test installing libllvm3.8 from http://koti.kapsi.fi/~tjaalton/skl/build2/
[16:22] <slangasek> Even the lower performance fix is quite late in the game.  I think it would be saner to release note this and fix it for .1
[16:22] <jderose> tjaalton: k, will do
[16:22] <tjaalton> mesa might get a workaround by then
[16:23] <tjaalton> or llvm fixed, but yes
[16:23] <slangasek> infinity: ^^ my $.02
[16:23] <tjaalton> your call
[16:23] <infinity> slangasek: It would perhaps be, but I'm also not keen on screwing the OEM that works most closely with us to ship our releases on release day. :P
[16:23] <tjaalton> also
[16:23] <infinity> tjaalton: Does mesa need (re)building to fix this, or just llvm?
[16:24] <tjaalton> turns out kabylake, which is has crippled kernel support on purpose (needs i915_bpo.preliminary_hw_support=1), is also seeing this bug
[16:24] <tjaalton> infinity: just llvm
[16:24] <jderose> slangasek: when do you expect .1 to come out? in the mean time, System76 will probably need to spin an updated ISO so our Nvidia using customers have a viable restore procedure, but that's fine
[16:24] <slangasek> jderose: .1 is due in June
[16:24] <pitti> cyphermox: got bored and generated the diff locally; accepted
[16:24] <infinity> slangasek: Late july...
[16:24] <infinity> (3mo after release, ish)
[16:24] <slangasek> jderose: .1 is due in late July
[16:24] <jderose> slangasek: gotcha, thanks. that's not too far away anyway
[16:24] <tjaalton> workaround for KBL is to use that option post-install, the kernel module "protection" will get dropped for .1
[16:24] <slangasek> ;)
[16:25] <tjaalton> june!?
[16:25] <infinity> The other Ju.
[16:25] <tjaalton> ahh
[16:25] <slangasek> infinity: sorry, don't know why I got that wrong, maybe we did 14.04.1 in june?
[16:25] <tjaalton> phew
[16:25] <slangasek> anyway
[16:25] <pitti> 6.06 :)
[16:25] <jderose> pitti: haha :P
[16:25] <tjaalton> yeah 14.04.1 was in august
[16:25] <tjaalton> iirc
[16:25] <slangasek> ok maybe wishful thinking on my part ;)
[16:26] <slangasek> anyway
[16:26] <pitti> did anyone call dibs on http://people.canonical.com/~ubuntu-archive/component-mismatches.txt ? if not, I'll do the binary bits, they look reasonable
[16:26] <slangasek> this is in a sense a hardware enablement bug
[16:26] <slangasek> that comes too late for the normal process
[16:26] <slangasek> and I don't think it should be a fire drill to get it in for .0 when .1 is around the corner
[16:27] <slangasek> pitti: libgrilo-0.2-1-dbg can be ignored, it was NBS and I removed it.  The other binary changes look sane to me, go for it
[16:27] <teward> infinity: just uploaded now :)
[16:28] <slangasek> also, somebody promoted liblouisutdml and didn't close the MIR bug
[16:29] <slangasek> pitti: ah the pymongo changes will be unnecessary because jamespage is unseeding aodh again per above discussion
[16:36] <davmor2> pitti, cyphermox: I assume I can drop this ssh port now right?
[16:37] <davmor2> and is the new iso going to be spun up soon?
[16:38] <jderose> tjaalton: mesa builds fine with tests enabled on haswell
[16:38] <tjaalton> jderose: not the same thing then I guess
[16:39] <jderose> seems not
[16:39] <infinity> slangasek: Hadn't closed it yet.  Multitasking something fierce here.
[16:40] <slangasek> infinity: ok :)
[16:40] <tjaalton> infinity, slangasek: uploaded it anyway, drop it if needed
[16:41] <infinity> tjaalton: Ta.
[16:41] <slangasek> tjaalton: s/drop/divert to -updates/ :)
[16:41] <tjaalton> or that :)
[16:43] <tjaalton> from the debdiff ^ CDI, DQI et al are subvariants of AVX512, confusing..
[16:44] <cyphermox> davmor2: I think so (closing ssh)
[16:44] <davmor2> cyphermox: thanks
[16:46] <cyphermox> infinity: anything you can/want to delegate?
[16:52] <infinity> arges: If you're the one doing kernel SRUs right now, could you hold off if you still have more?
[16:52] <infinity> arges: It kinda cripples the publisher at a rather sensitive time...
[16:54] <infinity> slangasek, tjaalton, jderose: So, I really wanted to get this llvm fix in for the release, but given the 8hr build time for llvm, I don't think it's realistic.
[16:54]  * slangasek nods
[16:55] <infinity> slangasek, tjaalton, jderose: Lining it up for a (near-)0-day SRU seems fine, though it certainly sucks that installs on skylake might be wonky.
[16:55] <jderose> infinity: that's fine with me. as long as the fix is coming as an SRU soon, we can spin and updated ISO in the meantime, then point people to 16.04.1 once its out
[16:55] <infinity> jderose: Yeah, I know you'll be alright, you know what you're doing. :)
[16:55] <jderose> infinity: s/wonky/almost-totally-broken/ :P
[16:56] <infinity> Less pleasant for random users, but random people buying new hardware tend to understand that Linux isn't always perfect on 2 month old configs.
[16:56] <infinity> I wish we'd addressed this a couple of days ago. :/
[16:56] <jderose> infinity: sometimes i know what i'm doing :P but it doesn't effect us for shipments as we pre-install the proprietary nvidia driver
[16:56]  * ogra_ blames the manufaturers
[16:56] <ogra_> +c
[16:57] <jderose> infinity: yeah, sorry about that... i was out of town at a trade show. bad timing
[16:57] <infinity> jderose: Ahh, so I can blame you? :)
[16:57] <infinity> jderose: (Not like you're the only person in the world who could have seen this...)
[16:57] <jderose> infinity: sure, if that makes you feel better, i'm fine with that :D
[16:57] <infinity> But life's like that, I guess.
[16:57] <infinity> jderose, tjaalton: Can I get one of you to write a release note entry describing the problem and what (if any) workaround there is to install on an affected machine?
[16:58] <infinity> Please tell me there's a workaround..
[16:59] <teward> rbasak: obvious ping, do you have something to add on the release notes for HTTP/2?  We're coming down to the time where that should get put into the notes, no?
[16:59] <jderose> infinity: assuming tjaalton has the llvm 3.8 SRU available, you can work around it by installing using the "Install Ubuntu" option in the pre-boot menu, which in my experience you might need to try a few time for success. then once you get to your broken unit session, switch to a VT, login, and apt-get update && apt-get dist-upgrade
[16:59] <jderose> s/broken unit/broken unity/
[17:00] <jderose> infinity: but yeah, i'd be happy to add it to the release notes once i double check that my instructions are correct
[17:00] <Kamilion> and I'm assuming running the alternate installer and letting it upgrade-during-install will also net you an operable system come next week.
[17:01] <infinity> jderose: Oh, I suppose this doesn't affect ubiquity-dm, since it's not composited?
[17:01]  * infinity hopes.
[17:01] <infinity> jderose: If so, the workaround would just be to tick the "download updates while installing" box or whatever it is, and never try the live session.
[17:01] <jderose> infinity: well, that was my feeling at first... but sometimes it still does seem to fail, and if i switch to a VT, i see the same thing in dmesg about invalid opcodes being trapped
[17:01] <infinity> Oh, lovely.
[17:02] <infinity> Okay, bigger hammer, then.
[17:02] <jderose> infinity: yeah, "download updates while installing" is another option... a better one in fact. will just have to double check that it works as expected
[17:02] <infinity> Kamilion: Yeah, using d-i would be fine, but given we only provide that as netboot, it's a steep learning curve for people who were expecting to click 4 boxes in ubiquity and go grab a coffee.
[17:03] <Kamilion> as long as upgrading from 14.04 or 15.10 works, that's what I figure a lot of folks will experience in real world usage
[17:03] <Kamilion> *I* intend to clean reinstall most of my systems this cycle, but I can wait till .1
[17:03] <infinity> Upgrading will work once the SRU is in place, yeah.
[17:04] <infinity> That said, people upgrading aren't likely to be affected by this bug in the first place, since they're not likely to have new enough hardware to be broken by it.
[17:04] <Kamilion> bring half up through upgrades, and roll my own ISOs post-sru.
[17:04] <Kamilion> yep.
[17:04] <jderose> infinity: true, upgrades should be fine. it's only an issue for fresh installs
[17:05] <Kamilion> and I'll roll my xen ISOs after I hear the SRUs are tested green
[17:05] <Kamilion> since I expect to be running on primarily newish server hardware
[17:06] <Kamilion> I also roll more often due to frequent security updates in the virtualization stack this last year.
[17:11] <infinity> tjaalton: llvm accepted, so we can 0-day it once it's gotten testing.
[17:11] <infinity> tjaalton: But it won't make images unless we have a *critical* respin (which we'd better not)
[17:13] <pitti> infinity: your livecd-rootfs change still looks premature? linux-firmware-raspi2 doesn't exist in the archive yet, but raspberrypi2-firmware still does
[17:13] <pitti> (i. e. known?)
[17:13] <infinity> pitti: It's accepted.
[17:13] <infinity> pitti: I'm smart enough not to respin until it's all in place. :P
[17:14] <ogra_> did you fix the hack for the dragonboard in live-build/auto/build too ?
[17:14] <pitti> I believe in slangasek's theory of publisher slowdown in release weeks :)
[17:14] <tjaalton> infinity: ok, cool. skylakes using i915 graphics won't hit this issue, so it's limited to workstations that have new dGPU's
[17:14] <tjaalton> and i can write a relnotes entry
[17:14] <infinity> pitti: This was because arges pushed a bunch of kernel SRUs.
[17:15] <infinity> ogra_: Quel hack?  I've not built offician dragonboard images yet.
[17:15] <infinity> ogra_: So, no, didn't know there was one.
[17:15]  * infinity looks.
[17:15] <ianorlin> or just install with skylake and then update and then put in dGPU
[17:15] <pitti> I'm off for a few hours for basketball, will check back in around 20:30 UTC
[17:15] <ogra_> infinity, has a comment ... look for "metapackage"
[17:16] <pitti> infinity: anything you particularly want me to look into tonight? (just in case you are at beer then, which I hope)
[17:16] <infinity> ogra_: Oh.  That whole bit is wrong.  Awesome.
[17:16] <pitti> otherwise, it'd be iso testing
[17:16] <ogra_> infinity, nah, works fine with the PPA packages :)
[17:16] <tjaalton> ianorlin: not if the cpu doesn't have gfx support
[17:16] <stokachu> i see openstack 1.0.6 approved here but rmadison isn't showing it in proposed
[17:16] <stokachu> did it hangup somewhere?
[17:17] <ianorlin> which even most skylake E3 xeons have
[17:17] <tjaalton> ok
[17:17] <infinity> stokachu: It's not instant.
[17:17] <Kamilion> like the E3-1220 v what?
[17:17]  * Kamilion has some V2s and V3s around and knows V5 was released
[17:17]  * cyphermox -> lunch
[17:17] <stokachu> infinity: ok
[17:18] <Kamilion> is it only the greenlow v5s?
[17:18] <ianorlin> like there are quite a few with integrated
[17:18] <pitti> infinity: FTR, casper is ready to promote, but blocked
[17:19] <infinity> ogra_: Well, I'll let you deal with your ugly hacks.  None of that is sane for the archive.
[17:19] <infinity> pitti: Yeahp, I'm unblocking en masse when I'm happy with the state of things and prepping for the Final Spin(tm).
[17:19] <ogra_> it will just have to be switched to the meta
[17:21] <infinity> ogra_: The meta doesn't depend on the firmware (it can't).
[17:21] <infinity> ogra_: So, it'd be the meta and the renamed firmware.
[17:21] <infinity> But sure, I can make those changes.
[17:22] <ogra_> nah, i'm fine doing them ...
[17:22] <ogra_> the only really ugly one is the dragonboard since we had no meta at all
[17:22] <infinity> ogra_: Why on earth are you installing "linux-flavour" instead of "linux-image-flavour" for snappy builds?
[17:22] <infinity> ogra_: Total waste of time and space to install the headers.
[17:22] <ogra_> on x86 systems that pulls firmware in
[17:23] <infinity> ogra_: No, it comes from linux-image-generic, not linux-generic
[17:23] <ogra_> the firmware dep ?
[17:23] <ogra_> oh
[17:23] <infinity> ogra_: Yeah, linux-foo is linux-image-foo + headers.
[17:23] <ogra_> well, then i'll use image :)
[17:24] <ogra_> doesnt really matter for the resulting snap since the dirs are pre-defined
[17:24] <slangasek> why does p-m think libsemanage is 0 days old?
[17:24] <infinity> ogra_: Matters for build time, then.
[17:24] <ogra_> yeah
[17:24] <infinity> slangasek: Because it got deleted and copied back in because magic.
[17:24] <infinity> slangasek: I could reset it in the state files, but meh.
[17:24] <slangasek> infinity: ah.  why was it deleted?
[17:25] <infinity> slangasek: To make room for the one I built in a PPA and slipped under the radar.
[17:25] <slangasek> infinity: heh
[17:26] <infinity> ogra_: Anyhow, if you're happy fixing this all, go for it.  It's not actually *on* images, so I don't care if livecd-rootfs changes as long as the code you fix is obviously contained to snaptastic things.
[17:26] <ogra_> yeah ...
[17:26] <slangasek> RAOF: your changelog entry for dovecot is incorrect; dovecot-core ends up with a dep on libstemmer0d
[17:27] <slangasek> RAOF: see also http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#dovecot
[17:29] <jderose> infinity: roughly when are you expecting to fire off the next ISO builds?
[17:31] <infinity> jderose: When the current lot of crap all migrates.  I'm done accepting new things.
[17:31] <jderose> infinity: okay, thanks. just trying to best time when i drive to the office so i have access to all our hardware for testing
[17:32] <ogra_> infinity, http://paste.ubuntu.com/15954073/ looks ok ?
[17:33] <ogra_> (or do we have a dep for the raspi2 and snapdragon FW packages ?)
[17:34] <infinity> ogra_: That looks correct.
[17:34] <ogra_> ok
[17:34] <infinity> ogra_: The raspi/snapdragon metas can't depend on the firmware because it's non-free.
[17:34] <infinity> (multiveeeeeeerse)
[17:34] <ogra_> ooooh indeeed
[17:34] <ogra_> :)
[17:37] <ogra_> uuuh
[17:37] <ogra_> why does "dpkg-buildpackage -rfakeroot -S" get me a gui popup for the gpg passphrase
[17:37] <ogra_> how irritating
[17:37] <infinity> Because that's how gpg agents work.
[17:38] <ogra_> not til i upgraded to xenial :)
[17:38] <infinity> You can switch to the text pinentry method.  Somehow.
[17:38] <infinity> I've not bothered to fill in that blank yet.
[17:39] <ogra_> it breaks my workflow ... i'm used to type my passphrase twice !!
[17:39]  * ogra_ has a spare passphrase in his brain now 
[17:39] <Odd_Bloke> Type it here:
[17:39] <infinity> If you're capable of typing your passphrase correctly twice in a row, it's too short/simple.
[17:39] <ogra_> hunter2
[17:39] <Odd_Bloke> ogra_: I HAVE YOU NOW
 *******
[17:39] <ogra_> :D
[17:40] <balloons> ogra_, don't lie.. it's snappysolveseverything
[17:40] <balloons> :-)
[17:40] <ogra_> lol
[17:40] <Odd_Bloke> theresanassertionforthat
[17:44] <balloons> So I'm the stereotypical, before release day bloke, looking for a friend who might be able to upload a new juju2 package for me. Any takers?
[17:45] <balloons> Not everyone all at once now, I know this is the chance of a lifetime
[17:49] <infinity> balloons: You've missed your chance.
[17:49] <infinity> Oh.  juju's not on any images?  Really?
[17:49] <infinity> I guess you haven't missed your chance.
[17:49] <balloons> infinity, :-) I'm certainly not going to be 'that guy' pushing you to respin
[17:52] <willcooke> tjaalton, hey did this get out of NEW yet?  https://bugs.launchpad.net/ubuntu/+source/xorg-lts-transitional/+bug/1571677
[17:52] <ubot5`> Launchpad bug 1571677 in xorg-lts-transitional (Ubuntu) "upgrading caused a broken apt cache due to *-lts-vivid packages conflicting with current X packages" [Critical,Fix released]
[17:52] <willcooke> how can I find out?
[17:53] <willcooke> tjaalton, ignore
[17:54] <infinity> Heh.
[17:59] <rbasak> teward: thanks for the reminder.
[17:59] <teward> rbasak: you're welcome, sorry to poke :)
[18:04] <superm1> infinity: just wanted to poke and remind on the grub in boot seed thing in case it fell off your radar
[18:05] <infinity> superm1: Oh, balls.  Thanks.
[18:05] <infinity> superm1: To be clear, that only negatively affected myth, right?  So, I can respin world minus myth, sort yours, and do you?
[18:05] <infinity> I could have phrased that better.
[18:05] <superm1> infinity: we're the only ones that install nvidia driver during install IIRC
[18:06] <superm1> but yes i think i think youcould respind the world without us and then drop from teh seed, spin us and magic everything works
[18:06]  * jderose drives into the office, be back soon... good luck ya'll, thanks for all the hard work!
[18:11] <tjaalton> willcooke: sure did :)
[18:17] <rbasak> infinity: I'm getting a bunch of postinst failure apport-filed bugs for mysql-5.7. This isn't really a regression from 5.6 but has always been a problem. Users customise their configs and then mysqld fails to start after upgrade. For 5.7 some customisations use directives that no longer work, too, including a conffile default in 5.6 packaging. What do you think about adding a fail-to-start-service
[18:17] <rbasak> hook that just prints a warning instead, so dist-upgrades won't explode?
[18:18] <rbasak> (this would be for upgrades only so won't need a respin)
[18:19] <slangasek> rbasak: how about fixing up the config file on upgrade instead?
[18:20] <rbasak> slangasek: we could do that for a couple of cases, but I hate to sed custom conffiles anyway - always feels risky to me.
[18:20] <rbasak> And it wouldn't cover all cases.
[18:23] <slangasek> rbasak: I am personally lukewarm about letting a package install succeed yet leave the service failed.  I know it doesn't do great things to an upgrade, but I personally feel it's more truthful to treat that as an upgrade failure
[18:23] <slangasek> (and in a perfect world, fix that upgrade failure)
[18:24] <slangasek> I also get squeamish about per-package deviations from the standard behavior of expecting services to start successfully on install/upgrade
[18:25] <rbasak> I think this is a fundamental issue with server services. On desktop the expectation is that package that provide daemons just work out of the box. On server the intention usually is that the user customises after the install, often in a way that packaging can't really fathom. And then that changes with a new version.
[18:25] <rbasak> (a new upstream version)
[18:25] <rbasak> Packaging fixing it up is then hit and miss. And then release upgrades break.
[18:25] <rbasak> This system is broken.
[18:28] <rbasak> I also get the impression that production server users will either be able to fix it up later, or redeploy without doing a release upgrade. Having the release upgrade break is worse. I think the majority of mysql bugs reported in this fashion is from desktop users experimenting with server stuff, not production server users.
[18:28] <rbasak> For that class of users, I think mysqld not starting is preferable to a release upgrade exploding.
[18:30] <infinity> rbasak: How would it "not require a respin"?  (unless it's a 0-day SRU)
[18:30] <rbasak> I'd also prefer not to receive a gazillion apport bugs from users who have broken mysql configs because they messed with them.
[18:30] <rbasak> infinity: I mean a 0-day SRU would be fine.
[18:30] <slangasek> rbasak: and again, I think that warrants a deep policy discussion, not a one-off package deviation the day before release
[18:30] <Skuggen> We might be able to handle the simplest cases, but I don't think it's possible to fix all such issues automatically
[18:31] <infinity> rbasak: We can discuss it when I'm not flat out trying to release, then, but I tend to agree with Steve, any attempt we can make to migrate, we should.  We can't catch every case, but those really should be failures.
[18:31] <rbasak> slangasek: I'm not confident hacking up a sed a day before release. Too many untested/unknown edge cases IMHO.
[18:31] <slangasek> rbasak: I'm happy to review seddery
[18:32] <slangasek> infinity: you probably missed my question last night about removing all the precise/daily* directories under www/full
[18:32] <infinity> slangasek: Go for it.
[18:32] <infinity> slangasek: And yes, I missed everything overnight because that server that had an IRC client uptime of over four years died overnight.
[18:37] <rbasak> Skuggen: would you like to attempt some seddery?
[18:37] <Odd_Bloke> slangasek: Could you ACK the gce-utils upload in to partner/xenial-proposed, please?
[18:40] <slangasek> Odd_Bloke: let's see!
[18:41] <Skuggen> rbasak: Yeah, I can see if I can get something simple going. There are a couple of known options that could simply be renamed, but for others I guess we'd probably just have to comment them out?
[18:41] <slangasek> Odd_Bloke: acked
[18:41] <Skuggen> (And give some sort of noticeable warning that we've done it)
[18:42] <slangasek> noticeable warnings optional
[18:42] <Odd_Bloke> slangasek: I knew you could do it.  I always believed.
[18:42] <Skuggen> slangasek: Yeah, during a full dist upgrade it would be pretty hard to make it noticeable :)
[18:42] <slangasek> Skuggen: well, there's a mechanism for it, which is to pop a debconf error. But please don't ;)
[18:43] <Skuggen> Maybe just add a note together with the commented-out option
[18:44] <rbasak> Skuggen: maybe start with the two options present in the previous default conffile that got renamed?
[18:44] <rbasak> Skuggen: and look for those only in that conffile?
[18:44] <rbasak> Otherwise we'll get into questions about what files to scan, etc.
[18:44] <rbasak> And yeah, definitely add a commented note in the file explaining that packaging did it.
[18:45] <Skuggen> rbasak: Yeah. At most I think we could scan through /etc/mysql
[18:45] <Skuggen> But we can detect this sort of issue by running mysqld --verbose --help in postinst
[18:51] <slangasek> infinity: ignore me pushing changes to the ubuntu-cdimage branch and deploying them
[18:52] <slangasek> xnox: why do we have 'Ubuntu Core s390x' as a local delta to etc/qa-products on nusakan?
[18:52] <infinity> slangasek: WCPGW?
[18:53] <slangasek> infinity: nothing, that's why you should ignore it ;)
[18:53] <rbasak> Skuggen: scanning /etc/mysql is dangerous because of hitting MariaDB config, etc. But let's take this to #debian-mysql and come back here when we have a patch.
[18:53] <infinity> slangasek: That's me.  I didn't commit it because I was mid-merge on the cyphermox branch.
[18:53] <infinity> slangasek: I can commit my nusakan changes now.
[18:53] <slangasek> infinity: k
[18:53] <slangasek> infinity: why do we have Ubuntu Core s390x at all? that's not on the list of target deliverables
[18:54] <infinity> slangasek: Because we have it for all arches, and it's the simplest/best livecd-rootfs/lp-buildd+livefs testcase.
[18:54] <infinity> slangasek: They don't need to ever be aware of or care about it if they don't want, it takes me seconds to validate and release, so meh.
[18:55] <slangasek> infinity: ok
[19:07] <infinity> slangasek: I made a bit of a mess of committing that all, but it's there now. :P
[19:10] <apw> tjaalton, llvm i386 seems to have exploded ...
[19:14] <infinity> slangasek: Have you demoted pymongo binaries yet?  I don't want to stomp on you and hit the double-override bug.
[19:14] <slangasek> infinity: you have the lock
[19:14] <slangasek> infinity: (I hadn't seen they got promoted and haven't demoted)
[19:19] <Odd_Bloke> Is there a reason that packages built for partner-proposed 35 minutes would still be "Pending publication"?  Am I just being impatient?
[19:25] <infinity> Odd_Bloke: BTW, we did bump one package that affects cloud (tzdata), but I'm not super fussed if you don't respin for it, especially given that the license is public domain.
[19:25] <slangasek> Odd_Bloke: yeah it takes a while.  I suspect that publication has gotten slower over the past week or two but don't know why
[19:30] <Odd_Bloke> infinity: Cool, I think we'll skip the respin. :)
[19:32] <Odd_Bloke> slangasek: It's finally arrived there, but several minutes after Launchpad stopped warning me that some files hadn't been published.
[19:36] <slangasek> Odd_Bloke: yes, launchpad doesn't see all the way to the edge, its idea of published is different from yours
[19:38] <jderose> tjaalton: hmm, looks like the i386 build of llvm-toolchain-3.8 failed - https://launchpad.net/ubuntu/+source/llvm-toolchain-3.8/1:3.8-2ubuntu2/+build/9602931
[19:38] <Odd_Bloke> slangasek: OK, I'll file that info away for the future. :)
[19:45] <rcj> Odd_Bloke, Having just read the tzdata diff I can tell you that time travel is impossible.  We can hardly keep track of time when it is moving linearly.
[19:58] <Odd_Bloke> slangasek: I've validated that gce-utils change; could you migrate it to release, please? :)
[20:00] <slangasek> Odd_Bloke: done
[20:01] <Odd_Bloke> slangasek: Thanks!
[20:03] <slangasek> infinity: http://lucifer.0c3.net/~adconrad/packageset-changes-new.txt hasn't been refreshed; is the new one still coming?
[20:03] <infinity> ###### FINAL RESPIN OF ALL FLAVOURS IN PROGRESS; PLEASE TEST ASAP ######
[20:03] <davmor2> \o/
[20:04] <infinity> slangasek: Oh.  I can finish re-rerunning it tonight.  Colin, Laney and I went through it all and it looked alright, though.  And, in Laney's words "I used to commit changes that large without review all the time, so meh."
[20:04] <slangasek> infinity: well, I think this is a special case because of the main changes and we should give teams an opportunity to "rescue" some of these
[20:04] <infinity> slangasek: So, the plan was just to commit tonight/tomorrow and call it good, rather than inviting people to bikeshed about it.  If people lose upload rights to something they really like, they can poke the DMB to fix it.
[20:04] <ogra_> infinity, can you trigger snappy too, so I can see if anything fails after the change
[20:05] <infinity> slangasek: But if you want it out for review, go to town.  Like I said before, packageset changes are per-series, not per-pocket, so we can (and do) mangle them post-release.
[20:05] <slangasek> infinity: "go to town"?
[20:05] <infinity> ogra_: You can.
[20:05] <slangasek> you said you were going to generate an updated list, which I don't know how to do
[20:05] <infinity> slangasek: As in, go for it.  Be my guess.  Bring it.  Etc.
[20:05] <infinity> slangasek: Right, I'll provide the updated list when I get hotelward.
[20:06] <slangasek> ok
[20:06]  * infinity refreshes his local mirror from the office first, so he can skip that step on the hotel network. :P
[20:12] <flocculant> :)
[20:13] <infinity> Oh, ffs.
[20:14] <infinity> ogra_: You broke my world respin (and two of us missed it in review).
[20:14] <infinity> Fixing.
[20:16] <davmor2> infinity: this isn't an iso blocker but can it be added to the release notes please as it is important https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/1561647
[20:16] <ubot5`> Launchpad bug 1561647 in software-properties (Ubuntu) "No mokutil prompt triggered when installing from additional drivers" [Undecided,New]
[20:17] <davmor2> willcooke: ^
[20:17] <cyphermox> ah, jes
[20:17] <infinity> davmor2: Document away.
[20:17]  * cyphermox goes to fiddle the software-properties UI to make this work
[20:18] <davmor2> infinity: if this is the final spin why is there an unapproved livecd-rootfs above?
[20:18] <infinity> 14:13 < infinity> Oh, ffs.
[20:18] <infinity> 14:14 < infinity> ogra_: You broke my world respin (and two of us missed it in review).
[20:18] <infinity> 14:14 < infinity> Fixing.
[20:18] <infinity> davmor2: ^
[20:19] <infinity> Going to head back to the hotel and re-trigger from there. :/
[20:19]  * davmor2 shakes his fist and ogra_ and blames him for everything, include war and world hunger ;)
[20:22] <slangasek> heh, what difference do those two little characters make
[20:23] <cjwatson> srsly
[20:23] <Odd_Bloke> Would have been fine in Python.
[20:23]  * cjwatson commits a basic automatic syntax check of at least those files to bzr
[20:23] <Odd_Bloke> Oh, right, infinity isn't here to troll about Python. ;.;
[20:28]  * pitti waves, quoi de neuf ?
[20:29] <ogra_> oh man
[20:30]  * davmor2 hugs ogra_ :) hey dude :)
[20:31] <ogra_> heh, thanks
[20:31]  * ogra_ hugs davmor2 too
[20:31] <pitti> ogra_: hey bearded man!
[20:31] <ogra_> lol
[20:31]  * pitti hugs ogra_ as well -- feels like release week!
[20:32] <ogra_> YAY !
[20:32] <pitti> a dozen people do hacks they aren't proud of, and at the end we get something that works, much to everybody's surprise :)
[20:32] <ogra_> only for non snappy though ... in the snappy world the hard work only starts now
[20:32] <infinity> Hard work's still in progress for the rest too. :P
[20:33] <davmor2> ogra_: PFFFF Don't even get me started ;)
[20:33] <ogra_> yeah, but you only need to approve these gazzillions of SRUs the snappy people push to the archive
[20:33]  * ogra_ really wishes we had used the phone model for snappy and just used an overlay archive ... 
[20:34] <jderose> infinity: slangasek: confirmed that tjaalton's test build libllvm3.8_3.8-2ubuntu1.1_amd64.deb fixes the issue on the first laptop i tested... now onto testing other hardware
[20:34] <ogra_> "rolling release via SRUs" doesnt really leave me confident
[20:35] <jderose> ogra_: the wave is always rolling, you just need to ride it carefully :P
[20:35] <davmor2> ogra_: but surely they'll be no need to update things in main as long as snapd can install ubuntu-core and the apps that's it right it all upgrade automagically right :D
[20:36] <slangasek> jderose: huzzah
[20:36] <ogra_> davmor2, yeah, because snappy images arent using anything but snapd at all :)
[20:36] <davmor2> ogra_: there you go then easy :P
[20:37] <infinity> jderose: Now if only it worked on i386. :P
[20:39] <davmor2> jderose: this is ogra_ he knows no fear he rides on the back of  laser toting shark across the rolling wave
[20:39] <ogra_> Oh my
[20:42] <phillw> infinity: are the lubuntu alternate images to also be respun. They landed before you mentioned a further issue?
[20:43] <slangasek> phillw: lubuntu because they are alternate are unaffected
[20:43] <flocculant> phillw: I saw that - I'd have to assume that anything that's live is going to be subject to the global respin
[20:44] <flocculant> I'd certainly plan that way if I was Lubuntu and not Xubuntu
[20:44] <phillw> slangasek: so we have an RC for alternate now?
[20:44] <slangasek> phillw: should be, yes
[20:45] <phillw> great, thanks.. just lets us concentrate resources on those while we await desktop to land :)
[20:46] <flocculant> phillw: sorry - got confused there with you having that alternate
[20:57] <tjaalton> apw, jderose, infinity: oh well, so it's expected that all tests pass on i386, others can screw it. so need to disable avx512 tests at least
[21:08] <tjaalton> just need to figure out how..
[21:12] <davmor2> infinity: any eta on the new, new isos?
[21:15] <slangasek> davmor2: they're at least an hour out and probably more like 2; I don't know what Adam's transit time is back to the hotel, but the fixed livecd-rootfs isn't yet in xenial
[21:16] <davmor2> slangasek: and with that I give up staying up to test oem install like I wanted and go to bed, night all
[21:19] <slangasek> davmor2: wise choice. g'night!
[21:23] <infinity> davmor2: The new livecd-rootfs is publishing, so I'll retry in ~30m.
[21:26] <jderose> cyphermox: so it seems the grub-install is failing with nvme drives... ubiquity tries to install grub to /dev/nvme instead of, for example, /dev/nvme0n1
[21:27] <jderose> found this on BIOS systems thus far, will test UEFI shortly (although these are BIOS systems that can boot from an nvme drive)
[21:35] <superm1> jderose: why would you install in legacy mode on new systems?
[21:35] <slangasek> pitti: I see sysvinit Breaks: systemd (<< 228-5ubuntu3), but that doesn't enforce systemd 228-5ubuntu3 being configured before sysvinit, which means the conffile may already be migrated away before systemd postinst runs... I think the right way to do this is with initscripts Pre-Depends: systemd, and for initscripts' preinst script to handle any conffile cleaning so that users are spared
[21:35] <slangasek> conffile prompts on upgrade
[21:36] <slangasek> pitti: (not for release of course, but I think this is advisable for SRU)
[21:37] <jderose> superm1: well, because it used to work :P
[21:38] <infinity> slangasek: Taking a lock on c-m.
[21:39] <slangasek> infinity: copy
[21:49] <jderose> cyphermox: actually, installing to a nvme drive in UEFI mode is fine... only BIOS mode is the problem. likely an issue with grub-pc i'm guessing
[21:51] <slangasek> jderose: well, under UEFI grub always "installs" to the ESP and calls efibootmgr, so completely different code path vs. BIOS, yes
[21:53] <slangasek> who's sitting on the s390x button?
[21:54] <cjwatson> the mass retry you mean?
[21:54] <cjwatson> that was Adam
[21:54] <slangasek> cjwatson: yeah :)
[21:54] <cjwatson> it'll finish in time, it's only a few hundred builds
[21:54] <cjwatson> and s390x eats builds for breakfast
[21:55] <infinity> Om nom.
[21:56] <slangasek> yes, and probably half the build failure mails are to me ;P
[21:56] <infinity> Lucky you!
[21:58] <pitti> slangasek: ah, good point; this needs to be tested thoroughly, pre-depends have some habit of causing trouble;
[21:59] <infinity> ##### FINAL MASS REBUILD IN PROGRESS FOR REALZ THIS TIME #####
[22:00] <pitti> infinity: \o/
[22:00] <cjwatson> slangasek: you have procmail, what are you complaining about
[22:00] <pitti> slangasek: filed bug 1572752 about that
[22:00] <ubot5`> bug 1572752 in systemd (Ubuntu Xenial) "improve UTC setting migration on upgrades" [Undecided,New] https://launchpad.net/bugs/1572752
[22:02]  * pitti moves to sysvinit, but whatever
[22:02] <teward> infinity: UNLEASH THE FLOOD OF EVILS!
[22:02] <teward> s/EVILS/ERRORS/
[22:02] <teward> (just kidding!)
[22:03] <infinity> teward: It can't go worse than the last rebuild attempt...
[22:03] <cyphermox> jderose: ok, but installing grub on a drive is installing grub on a drive, the target device isn't different if it's nvme or not
[22:03] <teward> infinity: i... am glad I was busy building a deconstructed computer?  :p
[22:04] <ogra_> infinity, but it was fast at least
[22:04] <cyphermox> anyway, will fix now that dinner is out of the way
[22:05] <pitti> ok, this mass rebuild is a bit too late for me to wait for, I'll get onto testing tmw morning then; good night!
[22:09] <Kamilion> cyphermox: tell that to platform SD controllers *grumble*
[22:10] <tsimonq2> infinity: awesome :)
[22:10] <cyphermox> Kamilion: well, there was a need to do some extra handling for NVMe in grub-installer, but what I'm saying is that I don't recall how BIOS or UEFI would make a difference in this particular case
[22:12] <Kamilion> I was grumbling because a lot of "platform SD controllers" are not bootable at all
[22:12] <cyphermox> see, that I would expect a bit more from BIOS.
[22:12] <Kamilion> vs your average SD-to-USB chip
[22:12] <cyphermox> I don't have NVMe here to test though, and I suppose I should fix that
[22:13] <infinity> And mysql-5.6 removed at the zero hour.
[22:15] <flexiondotorg> jderose, I confirm "ubiquity tries to install grub to /dev/nvme instead of, for example, /dev/nvme0n1"
[22:15] <flexiondotorg> On a BIOS system.
[22:15] <jderose> flexiondotorg: thanks for confirming :)
[22:17] <jderose> flexiondotorg: happen to know whether this was a problem with 14.04.4 and/or 15.10? i haven't tested those yet, but will try to shortly
[22:18] <flexiondotorg> jderose, 15.10 also affected. Haven't tested 14.04.
[22:22] <cyphermox> jderose: flexiondotorg: would either of you mind trying to re-do an install but adding -x to /usr/share/grub-installer/grub-installer
[22:22] <cyphermox> (before ubiquity reaches that point of course)
[22:23] <cyphermox> I fixed NVMe in some cases already, so something simple must be missing
[22:23] <flexiondotorg> cyphermox, Not before release :-(
[22:24] <flexiondotorg> Wil;l be using the nvme computer for VM< testing.
[22:26] <cyphermox> or maybe there's enough info already in the installer logs, is there a bug open for this yet?
[22:31] <flexiondotorg> https://bugs.launchpad.net/ubuntu/+source/grub-installer/+bug/1507505
[22:31] <ubot5`> Launchpad bug 1507505 in grub-installer (Ubuntu) "Unable to install GRUB in /dev/nvme" [Undecided,Confirmed]
[22:31] <flexiondotorg> cyphermox, ^^^
[22:31] <cyphermox> yippe...
[22:33] <flexiondotorg> https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1561572
[22:33] <ubot5`> Launchpad bug 1561572 in grub2 (Ubuntu) "Grub fails to install bootloader on NVMe drives" [Undecided,New]
[22:34] <flexiondotorg> cyphermox, I've marked the second as a dupe of the first.
[22:34] <cyphermox> thanks
[22:34] <slangasek> cjwatson: procmail doesn't tell me who clicked the build button, so I don't have a way to filter build failures I care about from those I don't :)
[22:41] <infinity> slangasek: I believe the response is "aww, schnookums".
[22:42] <infinity> (Though I've long thought that repeated nags on retries are spam to the uploader)
[22:42] <infinity> Not sure how trivial it wouldn't be to refcount and only spam on the first try.
[22:43] <slangasek> infinity: hey, my pain is your pain; you don't want me complaining about pointless retries of failed builds, keep them out of my inbox ;-)
[22:43] <infinity> ;)
[22:43] <infinity> It's a harder bug to fix than one would think, which is why I've never done so.
[22:43] <slangasek> yeah
[22:43] <infinity> (it's fundamentally counter to how LP does retries, which is to wipe the record and reset to fresh)
[22:54] <flocculant> infinity and -release team (wonderful that you are ofc) - have to crash now, when do you think respin will be ?
[22:54] <flocculant> can I assume when I surface it'll have happened?
[22:55] <slangasek> flocculant: as the bot says, builds are happening currently
[22:55] <flocculant> I did send a pre-pre-respin warning out
[22:56] <flocculant> slangasek: ok thanks - I'll assume that all went on then
[22:56] <flocculant> have to go and do real job first thing
[22:57] <flocculant> slangasek infinity - and when do - release hope to have ticks from the rest of us? UTC ish
[22:58] <flocculant> given we do stuff in real life ;)
[22:59] <slangasek> flocculant: release is expected to go out during business hours in London tomorrow; I don't know if infinity has a more specific target than that
[23:02] <RAOF> Laney, slangasek: Urgh, sorry. I read the output of sbuild and missed that where I should have been grepping the output of dpkg --info. :(
[23:08] <slangasek> RAOF: alrighty, fixed package accepted; I don't expect we'll let this into release though :)  It can go to y-proposed->y
[23:09] <RAOF> That bug is annoying, and I hit it again recently, and thought “oh, yeah! We've made that change that main can build-depend on universe as long as runtime dependencies only apply to universe packages”.
[23:10] <RAOF> I guess I'll have to try and fix it more invasively at some point :(
[23:10] <RAOF> slangasek: Obviously there's no point in letting it into release; the delta against xenial is 2 changelog entries :)
[23:10] <slangasek> yup!
[23:11] <flocculant> slangasek: cool - not too worried, might have to smoketest a few, just wanted to ensure it wasn't going to be some crazy UK is wake now release is all :)
[23:11] <flocculant> thanks
[23:12] <flocculant> and we want to get some fixed thunar tests in too
[23:13] <slangasek> Laney: what generate-freeze-block command did you run that generated the freeze hint?  ubuntu-server seems to not be frozen, and various things that aren't in any task are frozen
[23:19] <infinity> slangasek: Not sure what his command was, but it's conceivable he missed server. :/
[23:19] <slangasek> Laney: n/m, reverse-engineered :)
[23:19] <infinity> slangasek: Going to add a dovecot block before that gets through?
[23:20] <slangasek> infinity: already added that one by hand, and fixing the freeze rule as a whole
[23:20] <infinity> slangasek: Ta.
[23:21] <slangasek> infinity: and somehow Laney's hint froze linux-firmware-nonfree, which somehow lp says is not in the archive
[23:21] <infinity> flocculant: If all goes well, we expect to release between 12 and 2 London time, so ticking things ready a couple of hours before that (say, 9 UTC) would be nice.
[23:21] <infinity> slangasek: It was in the archive when he generated the block.
[23:21] <slangasek> infinity: it's meant to be gone?
[23:21] <infinity> Yeah.
[23:21] <infinity> We've been doing cleanup. :P
[23:21] <slangasek> ok
[23:22] <cjwatson> Yeah, I removed that earlier today.
[23:22] <cjwatson> Well, yesterday.  Whatever.
[23:22] <infinity> cjwatson: It's "today" until we sleep.
[23:23] <cjwatson> The removal bug had only been open for like five months.
[23:23] <cjwatson> orphaned-sources hopefully sorted now.
[23:23] <flocculant> infinity: ....
[23:23] <infinity> cjwatson: Worse, given that the bug was prompted by an AA review, and the AA failed to follow up.
[23:23] <infinity> *cough*
[23:24] <infinity> Not naming any names, ADAM.
[23:24] <flocculant> I just knew you'd  say that - so I will be working - and likely to land at home ~1pm UTC
[23:25] <flocculant> infinity: so expecting that I shortly ago asked the rest of xubuntu release to give me acks etc
[23:25] <infinity> flocculant: Righto.  You don't have to be the one who tests everything (yay, delegation), just tick the ready box when you're happy.  Should be able to do that from a phone on the train. ;)
[23:26] <flocculant> infinity: dude ...
[23:27] <flocculant> I drive a van - me ensures that everyone is completely aware that if I run into someone while driving - adam made me do it :-
[23:27] <infinity> flocculant: My usual MO for late confirmation is to publish you anyway, and if you tell me you hate your ISOs, we can pull/fix/whatever right before I do the last push.
[23:27] <flocculant> infinity: ack :)
[23:27] <flocculant> afauik we are all cool - mostly just want some sort of +'ves on thunar things
[23:28] <infinity> flocculant: Yup.  My bar for flavours is "does it boot/install/reboot and not blow up the computer", but obviously you can (and should) be stricter, as appropriate. :)
[23:28] <infinity> flocculant: Yup.  My bar for flavours is "does it boot/install/reboot and not blow up the computer", but obviously you can (and should) be stricter, as appropriate. :)
[23:29] <infinity> flocculant: Bonus points for also not stabbing users in the face via the installer.
[23:29] <flocculant> infinity: yup I tend to assume (and check~) that if I can't install - Ubuntu can't too - if Ubuntu can't then phew ...
[23:30] <flocculant> ubuntu can fix that ;)
[23:30] <infinity> ;)
[23:30] <flocculant> https://launchpad.net/~xubuntu-release
[23:30] <flocculant> is  completely up to date
[23:31] <infinity> cjwatson: Alright, everything from the out-of-date outdate is sorted.  Will see how much more is broken when the new report spits out.
[23:31] <tsimonq2> infinity: so all the release-critical bugs are fixed?
[23:32] <flocculant> infinity: I recently pointed my testers at the 'fixed' thunar - if we get fails on tracker for things we can't fix or shout about then I'm cool
[23:32] <infinity> tsimonq2: Every bug in the distro is fixed -- we can go home.
[23:32] <tsimonq2> \o/
[23:33] <tsimonq2> infinity: how will flavors know when it's time to release? will there be something here?
[23:33] <tsimonq2> just out of curiosity
[23:33] <Kamilion> now we just have to deal with overly huge packages like fonts-noto-cjk
[23:33] <infinity> Yup.

[23:33] <Laney> slangasek: Ah. That's not on the whiteboard list of doom in the office, so I guess I forgot it. Sozzles.
[23:33] <tsimonq2> infinity: cool, thanks, have a nice night, and best wishes releasing :)
[23:33] <Laney> Don't think any troublesome uploads happened
[23:33] <infinity> Laney: Yeah, the whiteboard list was for LTS support, so ubuntu-desktop and ubuntu-server were lumped together.  Oops.
[23:34] <flocculant> infinity: anyway - I''ll be aronund early, will try to be about 11ishfor tea, then luch time
[23:34] <flocculant> then bluesabre will be arounf
[23:34] <Laney> infinity: and someone wrote "Desktop" on it. :P
[23:34] <infinity> I blame Andy.
[23:34] <tsimonq2> plame popey
[23:34] <tsimonq2> *blame
[23:34] <tsimonq2> http://blamepopey.com/
[23:35] <Laney> Right. Night.
[23:35] <bluesabre> I should be around at 11urc
[23:35] <bluesabre> utc
[23:35] <bluesabre> :)
[23:35] <flocculant> infinity: I blame Thursday's pretend Friday
[23:35] <flocculant> bluesabre: hey :)
[23:35] <flexiondotorg> infinity, At this point do you have a release ETA for tomorrow, err later today? ;-)
[23:36] <flocculant> bluesabre: pretty much relies on not loads of 'oh god Thunar'
[23:36] <infinity> flexiondotorg: Just the one I mentioned above. :P
[23:36] <infinity> 23:21 < infinity> flocculant: If all goes well, we expect to release between 12 and 2 London time [...]
[23:36] <flocculant> flexiondotorg: seems like lunchtime ... corned beef and pickle ;)
[23:36] <infinity> Err.
[23:36] <infinity> flexiondotorg: ^
[23:36] <bluesabre> flocculant: we should be safe
[23:37] <flocculant> bluesabre: yup
[23:37] <flexiondotorg> Shit, that early.
[23:37] <bluesabre> I won't be around at the 12-2 window
[23:37] <flexiondotorg> OK.
[23:37]  * Kamilion is rolling a xen iso from the lubuntu ISOs just published
[23:38] <infinity> bjf: Can I get you (or someone else you know with raspi2 HW) to smoketest http://cdimage.ubuntu.com/ubuntu-server/daily-preinstalled/20160420.5/ for me?
[23:38] <infinity> bjf: It's not on the tracker, so just pinging me with "it's not crap" will do.
[23:39] <Kamilion> lemme track down a blank SD and I'll give it a go (if I can find a blank)
[23:39] <flexiondotorg> Kinda means I'm up all night then,
[23:39] <infinity> cjwatson: Huzzah.  Fresh run of outdate_all didn't expose any new badness, so pending a publisher cycle or two, that should clear out, I think.
[23:41] <infinity> And there's my server ISOs.
[23:41] <flexiondotorg> infinity, the Ubuntu MATE images didn't make it to cdimage. Only amd64 is there.
[23:42] <infinity> flexiondotorg: It's probably still syncing.
[23:42] <flexiondotorg> Yeah, there are popping up. SOrry.
[23:42] <flexiondotorg> infinity, Are bugs in Ubiquity consider release critical?
[23:43] <infinity> flexiondotorg: Depends on the bug.  At this stage in the game, it's got to be pretty amazingly critical.
[23:43] <mwhudson> got a request to upload docker.io, there's no reason not to do that right now? (it's universe after all)
[23:43] <flexiondotorg> infinity, Understood.
[23:43] <infinity> mwhudson: Yeah, not seeded in anything.
[23:44] <infinity> flexiondotorg: There will be point releases (first one in 3 months) to fix installer/ISO bugs, so if things aren't completely perfect, help polish for .1 :)
[23:44] <mwhudson> infinity: ta
[23:46] <slangasek> cyphermox: ^^ if you're still around and want to test some rpi2
[23:46] <slangasek> (make that ^^^^^)
[23:46] <cyphermox> ah, sure
[23:47] <cyphermox> you're making me wipe out the device early enough that I didn't start setting up maas yet :)
[23:47] <infinity> cyphermox: Iz not in the tracker, and it's too late now for that to be a priority, so just IRC ping results.
[23:47] <cyphermox> yeah no worries
[23:47]  * cyphermox zsyncs the image
[23:48] <cyphermox> flexiondotorg: still want to know about that ubiquity bug, especially if it's different than the NVMe issue you mentioned earlier
[23:49] <cyphermox> hrm
[23:49] <flexiondotorg> cyphermox, Nothing yet. zsyncing.
[23:49] <cyphermox> slangasek: is it normal given how the image is made, that it's nearly a full download again?
[23:49] <infinity> Yeah, xz isn't remotely rsync-friendly.
[23:49] <cyphermox> ok
[23:50] <infinity> If we wanted it to be, we could unxz and gzip --rsyncable
[23:50] <infinity> Perhaps worth a ponder for another time.
[23:50] <infinity> If anyone cares deeply.
[23:50] <cyphermox> it's not that big a deal, the image is fairly small anyway
[23:50] <slangasek> infinity: except gzip doesn't do sparse.
[23:51] <infinity> slangasek: That only matters on unpack, mind you.  But yeah, not ideal.
[23:52] <infinity> (The packed file is still small, because it's just a bunch o' zeroes)
[23:52]  * slangasek nods
[23:53] <infinity> Alright.  I think I've done all I can usefully do tonight.
[23:53] <infinity> Will aim to be back in ~8h or less.
[23:54] <slangasek> infinity: anything you want me to do overnight?
[23:54] <slangasek> infinity: also, do I get a packageset delta report?
[23:54] <infinity> slangasek: ISO testing until you can't stand it anymore?  Particularly prodding people (or yourself) to help where flavours seem to be lacking, once Canonical stuff has good coverage.
[23:55] <slangasek> k
[23:56] <infinity> slangasek: Hot off the press: http://lucifer.0c3.net/~adconrad/packageset-changes-new-new.txt
[23:56] <slangasek> infinity: ta
[23:59] <cyphermox> infinity: do we need to run some changes script for the .0?
[23:59] <infinity> cyphermox: Nein.
[23:59] <cyphermox> given how long it takes to run ;)