[02:44] <stgraber> infinity: could you approve my lxc upload? it would make testing an upcoming lxd change easier for some of my users (they could pull it from proposed directly and we could run adt tests easily)
[02:47] <infinity> stgraber: Looking.
[02:49] <stgraber> it's a tiny change to fix broken bash completion but it also happens to free the "lxc" bash completion filename which lxd then must use itself, so our new lxd packages are effectively blocked on that tiny change right now :)
[02:50] <stgraber> not completely sure why bash-completion behaves so differently between /etc and /usr/share but well
[02:56] <infinity> https://bugs.launchpad.net/ubuntu/+source/unity-greeter/+bug/1538615 is a wild ride.
[02:56] <ubot5> Launchpad bug 1538615 in unity-greeter (Ubuntu Trusty) "Cat causes login screen to hang" [Medium,Triaged]
[02:58] <stgraber> thanks
[03:02] <bluesabre> infinity: since you just so happen to be around, would you mind releasing https://launchpad.net/ubuntu/+source/xubuntu-docs/16.04.3 from -proposed?
[03:03] <bluesabre> (pretty please) :)
[03:04] <infinity> bluesabre: That would mean a respin of xubuntu and studio images, and we release tomorrow.  Is it urgently needed in the images?
[03:05] <bluesabre> infinity: its not urgent, just a nice-to-have. At the same time, I do suppose our QA lead is currently asleep, so maybe I'll hold off until flocculant appears again
[03:05] <infinity> bluesabre: Yeah, given that I'd like to release in just over half a day, I think I'd want approval from both Xubuntu/Studio to muck with their images.  Or, if another critical "breaks the world" bug needs to be fixed, I'll slip it in.
[03:05] <infinity> bluesabre: Otherwise, it can wait a day. :)
[03:06] <bluesabre> yup, and I can't speak for studio :)
[03:06] <bluesabre> thanks!
[03:10] <dax> infinity: is that a dup of https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1463112 ?
[03:10] <ubot5> Launchpad bug 1463112 in unity (Ubuntu) "Cat sitting on keyboard crashes lightdm" [Medium,Confirmed]
[03:11] <infinity> dax: Probably.
[03:13] <dax> aww. the naming conflict between cat the shell thing and cat the little furry demons means that finding more dupes is less funny than expected
[03:13] <infinity> Quite.
[03:13] <infinity> I think I also once reported that the Unity lock screen wasn't cat-friendly.
[03:13] <infinity> Though, I don't recall what my complaint was.
[03:14] <infinity> Oh, I remember.  The first incarnation of the lock screen would wake up on keypress and if there was any input in the password field, would never go back to sleep.
[03:14] <infinity> So a cat walking across the keyboard once would keep your monitor on all night.
[03:28] <infinity> superm1: We seem to have no mythbuntu tests for Beta2.
[04:06] <stokachu> damnit, can someone please cancel that openstack package out, was supposed to be xenial
[06:06] <slangasek> why do so many packages seem to have problems with termios on powerpc+ppc64el only?
[06:06] <slangasek> ah, https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=810907 explains
[06:06] <ubot5> Debian bug 810907 in src:repsnapper "repsnapper: FTBFS on ppc64el: termios problems" [Serious,Open]
[06:06] <slangasek> I wonder if that's a linux-libc-dev bug
[08:00] <ypwong> Could someone from release team comment on https://bugs.launchpad.net/ubuntu/+bug/1546967 ?
[08:00] <ubot5> Launchpad bug 1546967 in Linux Backports "[FFe] [needs-packaging] linux backports and related meta packages" [High,New]
[08:08] <doko> slangasek, they should not have any cross-arch deps
[09:19]  * apw reviews bug #1546967 with his kernel hat on
[09:19] <ubot5> bug 1546967 in Linux Backports "[FFe] [needs-packaging] linux backports and related meta packages" [High,New] https://launchpad.net/bugs/1546967
[09:36] <xnox> infinity, s390x all good, i am expecting that d-i and server iso and cloud images are going to be released.
[09:36] <xnox> tested on all virtualisation modes
=== king-afk is now known as cking
[10:01] <ypwong> apw, if we change the version number to match ABI number, i think it suffice to just use x.x.x.y and no need to use x.x.x.y.z, right?
[10:02] <ypwong> rationale is, if kernel updates from, let's say, 4.4.0-15.31 to 4.4.0-15.32, there should be no need to rebuild lbm
[10:04] <apw> ypwong, well if you make it match it will be less confusing, you indeed do not need to rebuild unless x.x.x.y changes of course
[10:04] <apw> ypwong, that said, we are not producing non-abi bumper kernels except in the case where they do not make it to -proposed (pretty much) so you will always have an abi bump
[10:05] <apw> ypwong, so it _will_ change in the normal course every single kernel
[10:08] <ypwong> apw, ok
[10:30] <darkxst> this list seems somewhat incomplete http://iso.qa.ubuntu.com/qatracker/reports/defects
[10:32] <darkxst> only 2 of the bugs reported against ubuntu GNOME images are listed there
[10:32] <sil2100> Hello! For those that might be affected: I'll be disabling the system-image importer frequently in the nearest few hours as we're doing some rebuilds in the touch world
[12:25] <rcj> infinity, cloud images are ready
[12:58] <phid> apw: hi, we've made some changes for LBM according to your suggestions. The temporary development ppa can be found here: https://launchpad.net/~linux-backports-team/+archive/ubuntu/develope
[13:01] <apw> phid, will have a look, the version number being a . not a - for the abi seems odd
[13:02] <phid> apw: that's because it's native package now, from what I know linux-signed-generic uses same versioning rule
[13:03] <apw> linux-signed (4.4.0-8.23) xenial; urgency=medium
[13:03]  * davmor2 has a bone to pick with cyphermox and then slap him round the room with, additional drivers, I installed intel microcode and nvidia binary on a real machine no mokutils password request
[13:04] <cyphermox> maybe you didn't have secureboot enabled?
[13:05] <apw> not sure why intel microcode would need secure boot interactions, that is added to the initramfs and is signed by intel and validated by the cpu
[13:06] <apw> and why would an nvidia driver matter for secureboot at the mok level
[13:06] <ypwong> apw, we also looked at linux-generic/linux-signed-generic/linux-meta and their versions are like 4.2.0.34.37
[13:07] <apw> if the kernel was enforcing correctly it would reject a vile binary driver after you installed it but the act of installing it has no interwction with mok does it
[13:07] <apw> ypwong, yes meta is numbered differntly to signed
[13:07] <davmor2> cyphermox: paste.ubuntu.com/15487077
[13:07] <apw> thouhg that is as much legacy as anything else
[13:08] <davmor2> cyphermox: also it triggered installing fwts from terminal
[13:10] <davmor2> cyphermox: so it looks like it is just additional drivers
[13:11] <davmor2> cyphermox: however it might be related to the control system not working if it triggers the window from there maybe
[13:27] <ypwong> apw, ok, we will keep meta packages to use x.x.x.y.z and the packages that contain ko to use x.x.x-y.z
[13:28] <apw> ypwong, yeah that is a confusing delta in our package, i am struggling to know why it matters
[13:28] <apw> i guess it is as simple as native or not, hrm
[13:30] <ypwong> yeah that was confusing at first so we used another versioning scheme
[13:32] <apw> ypwong, i think in this case becuase your lbm modules are tied exactly to our binary version numbers, that matching exactly is good for keeping users from being confused
[13:32] <apw> however stupid out names are :)
[13:42] <doko> hmm, the re-run alias using snakefruit doesn't seem to work forme ... https://wiki.ubuntu.com/ProposedMigration/AutopkgtestInfrastructure#Re-running_tests
[13:48] <superm1> apw: how does the kernel decide if it's behaving in enforcing mode for preventing unsigned kernel modules?
[13:51] <apw> superm1, right now it does not, it will based on the mok settings
[13:52] <superm1> apw: oh okay, that explains why it's worked so far with current xenial kernel still
[13:52] <apw> superm1, right
[13:52] <apw> we're working on that problem at the moment
[13:53] <superm1> apw: do you have a WIP patch for this somewhere?
[14:01] <apw> superm1, i do not, rtg is looking after that one
[14:02] <superm1> rtg: anything you can share about it?
=== henrix_ is now known as henrix
[16:14] <ypwong> apw, packages using versions that match kernel are now in ppa
[16:19] <infinity> superm1: *poke, poke*
[16:19] <infinity> superm1: Still no myth testing on the tracker.
[16:21] <stokachu> infinity: get my email? :)
[16:21] <stokachu> i know you love us
[16:21] <superm1> infinity: it's been happening (which is why there were 2 packages uploaded a little bit ago)
[16:21] <superm1> found some odd stuff missing that caused interesting installation failures
[16:22] <superm1> if you could accept those 2 in (mythtv, mythbuntu-meta) and respin i'll ask testers to retest with that and make sure to file some reusults
[16:24] <stokachu> apw mind rejecting bigdata 1.0.0 now that 1.0.1 is there
[16:24] <infinity> superm1: Kay.  Can do.  But hurry, release is today. :P
[16:24] <superm1> infinity: kk :)
[16:25] <superm1> what time is cutoff?
[16:25] <infinity> superm1: My afternoonish/eveningish sometime.
[16:25] <infinity> superm1: No hard time, other than I'd like to be done before 8pm Mountain.
[16:25] <superm1> infinity: OK
[16:30] <flexiondotorg> infinity, So that is 02:00 UTC right?
[16:30] <apw> stokachu, if the previous one wasn't accepted you can reuse the version numbers ...
[16:30] <stokachu> apw: ah ok didnt realize that
[16:31] <infinity> flexiondotorg: Yeah, but I'm hoping we're done long before that.  That's just my "screw you all, I have plans this evening" cutoff. :P
[16:31] <apw> stokachu, and rejected
[16:31] <stokachu> thanks
[16:31] <flexiondotorg> infinity, Sounds fair :-)
[16:38] <davmor2> moves to release
[16:38] <willcooke> davmor2, so your testing shows 5 critical bugs?
[16:39] <davmor2> willcooke: well not just mine but yes
[16:39] <willcooke> this page?  http://iso.qa.ubuntu.com/qatracker/milestones/358/builds/115348/testcases
[16:42] <davmor2> yeap
[16:42] <infinity> So, the accessibility thing sucks, but I'm not sure it's beta-critical.
[16:43] <infinity> (obviously RC for final)
[16:43] <davmor2> willcooke: that accessibility menu missing is a big one, the can't format swap issue is the next, the mokutils one I think is now understood but needs modifying,
[16:43] <infinity> https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1560973 looks a bit scary.
[16:43] <ubot5> Launchpad bug 1560973 in grub2 (Ubuntu) "EFI booting Ubuntu image to grub removes existing boot entries and makes system unbootable" [Undecided,Confirmed]
[16:43] <davmor2> infinity: tell that to the blind guy trying to install it, final beta is when people start to install and upgrade the two things you can't do right now
[16:43] <infinity> Given we claim betas are "reasonably free from showstoppers".
[16:44] <infinity> davmor2: I don't disagree that it sucks a lot.
[16:45] <infinity> What I need to know is how deeply these bugs have been investigated, are there fixes in the queue, can we fix them quickly, will I have to push back beta by a day and swap a holiday?
[16:45] <Laney> cyphermox reckoned that one was XP
[16:45] <Laney> S 13 specific, maybe
[16:45] <Laney> someone with different hardware could confirm that
[16:46] <infinity> cyphermox: You have context on any of these bugs and care to enlighten me? :P
[16:47] <davmor2> Laney: no it happens in kvm too
[16:48] <Laney> write that on the bug please
[16:50] <willcooke> The a11y one, TheMuso is aware and has a plan to fix, but he says it wont be ready before beta.
[16:50] <willcooke> I agree its bad
[16:50] <infinity> I agree it's bad too, but people could have tested a bit earlier to discover the badness.  Anyhow, I see some uploads in the queue from him.  I'd rather not respin the world to include those, especially if they're not complete yet.
[16:51] <infinity> But if we must respin for other bits, we can try those bits too.
[16:51] <davmor2> Laney, infinity: sorry I thought I did with the whole fedora explanation, the issue is that all the ubuntu install paths for uefi is landing on the same file names and same path the only change is the newer version of grub2 lists both version of ubuntu
[16:51] <infinity> Sadly, most of these bug fixes will force a respin on all the flavours who've been marking their images ready over the last 24h. :P
[16:52]  * knome grins
[16:52] <willcooke> Laney, will you get a chance to look at this today:  https://bugs.launchpad.net/ubuntu/+source/unity-control-center/+bug/1546388
[16:52] <ubot5> Launchpad bug 1546388 in unity-control-center (Ubuntu) "unity-control-center crashed with SIGSEGV in _cogl_check_extension()" [Medium,Confirmed]
[16:53] <infinity> willcooke: Can I get you and slangasek to maybe triage these criticals together, and get managerial about throwing out assignments, and we can then examine the fallout and determine a plan forward for beta and post-beta?
[16:53] <Laney> willcooke: It doesn't crash for me. I told $whoever earlier that they should talk to tjaalton.
[16:53] <davmor2> I think the solution would be to have a the efi entry for shim.efi etc to be time stamped at install time and then that would make them unique
[16:53] <willcooke> Laney,  oh, sorry, wrong link... https://bugs.launchpad.net/ubuntu/+source/libunity/+bug/1538471
[16:53] <ubot5> Launchpad bug 1538471 in libunity (Ubuntu) "scope-runner-dbus.py assert failure: *** Error in `/usr/bin/python3': free(): invalid next size (fast): 0x0000000001ca17b0 ***" [Critical,Confirmed]
=== ochosi_ is now known as ochosi
[16:53] <willcooke> infinity, yeah, good plan.
[16:54] <davmor2> Laney: me it works fine on my laptop here but on the installed hardware it breaks, I thought you were talking to the other guy who had gfx issues when you said that
[16:54] <slangasek> infinity: where is the list of criticals?
[16:54] <infinity> slangasek: http://iso.qa.ubuntu.com/qatracker/milestones/358/builds -- red bugs on Ubuntu Desktop amd64.
[16:55] <infinity> willcooke: If there are others on your list not represented by those little red bugs, speak up.
[16:55] <slangasek> infinity: thanks
[16:55] <davmor2> slangasek: currently the only install that is flawless is netboot
[16:55] <willcooke> the only other one I'm really concerned about is this upgrade issue, but it doesn't look like we're going to get a fix for that today
[16:55] <slangasek> an upgrade issue should also not block the release of milestone images
[16:55] <Laney> willcooke: Umm, well I've been fixing hidpi only-ubiquity mode which I also got asked to look at
[16:56] <Laney> and then I should deploy some appstream generator fixes
[16:56] <Laney> ...but I could do this instead...
[16:56] <davmor2> infinity, slangasek: mokutils not trigging password on additional driver page no bug for that will be soon though got caught up in meetings and then the control center crasher
[16:57] <slangasek> davmor2: need bug reports and pointers to them, please
[16:57] <slangasek> mokutils seems to be bug #1560940?
[16:57] <davmor2> slangasek: yeap I'll get on it now
[16:57] <ubot5> bug 1560940 in ubiquity (Ubuntu) "None matching mokutils passwords" [Undecided,New] https://launchpad.net/bugs/1560940
[16:58] <davmor2> slangasek: no that is in ubiquity this is on the installed system you get no password prompt when installing nvidia binary and intel microcode
[16:58] <davmor2> slangasek: but that might be due to unity8 session downgrading pkcon
[16:59] <Laney> willcooke: https://bugs.launchpad.net/ubuntu/+source/libunity/+bug/1538471/comments/25 <- says that pygobject is able to fix it - and pitti is a maintainer of that, so maybe he could help
[16:59] <davmor2> willcooke: ^ is that a possible side effect?
[16:59] <ubot5> Launchpad bug 1538471 in libunity (Ubuntu) "scope-runner-dbus.py assert failure: *** Error in `/usr/bin/python3': free(): invalid next size (fast): 0x0000000001ca17b0 ***" [Critical,Confirmed]
[17:10] <davmor2> slangasek: bug 1546388
[17:10] <ubot5> bug 1546388 in unity-control-center (Ubuntu) "unity-control-center crashed with SIGSEGV in _cogl_check_extension()" [Medium,Confirmed] https://launchpad.net/bugs/1546388
[17:12] <slangasek> willcooke: ^^ davmor's u-c-c crasher bug wasn't on the iso tracker
[17:12] <slangasek> Laney: pitti is sick today, out for rest of week
[17:15] <Laney> slangasek: I know, but this one can wait IMO - certainly not beta critical anyway
[17:17] <willcooke> slangasek, @ u-c-c crasher.  Not crashing for Laney or me, so I think it's ok to not block
[17:18] <slangasek> ok
[17:26] <davmor2> slangasek: https://bugs.launchpad.net/ubuntu/+source/mokutil/+bug/1561647
[17:26] <ubot5> Launchpad bug 1561647 in mokutil (Ubuntu) "No prompt triggered when installing from additional drivers" [Undecided,New]
[17:26] <willcooke> So I think the only blocker atm is https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1552539
[17:27] <ubot5> Launchpad bug 1552539 in ubiquity (Ubuntu) "Ubiquity Erase Disk and Install Fails to create Swap Space" [Critical,Triaged]
[17:27] <davmor2> slangasek: I'll check on the unity8 bit of it in a second but I'll need a fresh install to trigger it
[17:27] <willcooke> davmor2, u8 is in universe, if it causes things to break then we shouldn't block the beta for it
[17:27] <slangasek> davmor2: bug #1560973 - did you *reproduce* the failure that Laney describes?
[17:27] <ubot5> bug 1560973 in grub2 (Ubuntu) "EFI booting Ubuntu image to grub removes existing boot entries and makes system unbootable" [Undecided,Confirmed] https://launchpad.net/bugs/1560973
[17:28] <davmor2> willcooke: no that was just another bug but isn't critical slangasek asked if there was anything else, if it isn't unity8 then it might be more important
[17:29] <willcooke> ah, soz
[17:29] <davmor2> slangasek: I did I'm sure I commented on it if not I will now
[17:30] <slangasek> davmor2: your comment describes a scenario in which you did *not* reproduce the bug. It does not say you reproduced the bug.
[17:30] <slangasek> davmor2: if you reproduced the bug, please include information about what hardware you reproduced it on
[17:34] <slangasek> Laney, davmor2: I have requested further info on LP: #1560973.  FTR this sounds to me like a firmware bug rather than a bug in Ubuntu, but will try to confirm that
[17:34] <ubot5> Launchpad bug 1560973 in grub2 (Ubuntu) "EFI booting Ubuntu image to grub removes existing boot entries and makes system unbootable" [Undecided,Incomplete] https://launchpad.net/bugs/1560973
[17:34] <slangasek> infinity: so far the only blocker bug that's been identified is the one willcooke mentioned, LP: #1552539, which seems to be a horrible interaction between systemd an ubiquity
[17:34] <ubot5> Launchpad bug 1552539 in ubiquity (Ubuntu) "Ubiquity Erase Disk and Install Fails to create Swap Space" [Critical,Triaged] https://launchpad.net/bugs/1552539
[17:34] <slangasek> all the others have been turfed, except for the UEFI boot one which still needs more info
[17:36] <infinity> slangasek: I don't suppose it's reasonable to release note (and mention in the release announcement) that one might need to delete swap partitions before attempting an install?
[17:36] <slangasek> willcooke: ^^ ?
[17:36] <slangasek> if that's confirmed to work, that does seem ok to me for beat
[17:36] <infinity> A quick ubiquity hack to walk /proc/swaps and swapoff anything that's not /dev/zram* would work, I imagine.
[17:37] <slangasek> beta
[17:37] <cherylj> hey guys, is there anything else you need from the team for Juju's FFE?  bug #1545913
[17:37] <ubot5> bug 1545913 in juju-core (Ubuntu) "[FFe] juju-core 2.0" [Undecided,Confirmed] https://launchpad.net/bugs/1545913
[17:37] <slangasek> cherylj: couldn't say; there's basically not going to be anyone looking at it until after the beta release is done today
[17:38] <willcooke> slangasek, infinity - at this point I'm more in favour of a quick fix than a release note
[17:38] <cherylj> thanks, slangasek.  I will check back later
[17:38] <infinity> willcooke: I'm a fan of quick fixes too, just not the forced QA turnaround that results. :)
[17:38] <slangasek> willcooke: "quick fix" does add another 4-6 hour turnaround
[17:38] <superm1> infinity: ah crap, mysql-5.7 got pulled into mythtv's build and caused problem
[17:38] <davmor2> slangasek: I've added the info from Laney's.  The issue as I see it is that there is no path or file name changes for boot/EFI/Ubuntu  so they always overide each other
[17:38] <superm1> since it didn't pull in all the way
[17:39] <infinity> superm1: Oh, bother.
[17:39] <davmor2> slangasek: fedora is installed in boot/EFI/Fedora so the 2 show up in the UEFI menu
[17:39] <infinity> superm1: I can delete mysql-5.7 from proposed and re-copy it in after a fresh mythtv build, if that's all you're blocking on.
[17:39] <infinity> superm1: We probably want to wait for the result of this larger discussion about blockers anyway.
[17:40] <superm1> infinity: yeah that's all right now
[17:40] <slangasek> davmor2: you have *not* described reproducing the bug, you have described *not* reproducing the bug.  Can you reproduce Laney's bug, whereby booting the USB stick, and then removing it, leaves the system unbootable?
[17:40] <superm1> infinity: after freeze is lifted i can sort out what needs to change to build against 5.7 properly
[17:40] <infinity> superm1: I imagine once 5.7 completely replaces 5.6, the answer will be "very little", unless you have some hardcoded versioned deps somewhere.
[17:41] <slangasek> davmor2: you are speculating about the cause of the bug.  What I need is confirmation that the bug is reproducible, and on what hardware
[17:41] <superm1> yeah i am inclined to think you're right, the failure was looking for mysql/mysql.h and that failing
[17:42] <infinity> superm1: Huh.  That shouldn't fail.  Sounds like a potential bug in the 5.7 packaging.  But even if it worked, you'd then end up with a dep on the new libmysqlclient, which would keep you stuck in proposed.
[17:42] <infinity> superm1: Maybe the simplest thing here will be to slap your sources in a PPA that excludes -proposed in build-deps and then copy in the results.  Lemme look at doing that for you.
[17:42] <Laney> slangasek: I don't understand what you're asking in the penultimate step I'm afraid
[17:43] <davmor2> slangasek: for that I was using kvm give, it takes an hour or so to install fedora so give me some time
[17:43] <Laney> slangasek: I don't explicitly add the USB stick to the options - it's preferred by the firmware's boot order when inserted
[17:43]  * infinity alters his staging PPA to exclude proposed...
[17:44] <slangasek> Laney: so you recovered the system by going into your firmware and choosing 'Add Boot Option', which is going to modify the contents of the nvram variable.  What I'm trying to see is, once the problem has been reproduced, can we then boot the USB stick again without having to modify the nvram variable, so that we can see what state it's in at that point
[17:44] <slangasek> davmor2: if you are installing Fedora, you are wasting your time
[17:45] <slangasek> davmor2: I am asking you if you can reproduce Laney's bug.  So doing something that you expect will not reproduce Laney's bug, then confirming that you have not reproduced Laney's bug, does not help me
[17:46] <willcooke> slangasek, infinity - if the quick fix is not at all quick.  The +1 on the release note.  I'd like to do a bit of testing here quickly first....
[17:47] <infinity> willcooke: The quick fix itself would be fairly quick, the turnaround for respinning all the flavours and retesting them is less quick.
[17:48] <davmor2> slangasek: ah I was misunderstand so my comments then would be an additional bug, in that if you install 2 ubuntu systems side by side there is only one system listed in EFI.  Let me double check on Laney's bug now
[17:49] <infinity> willcooke: That said, if we had some commitment from our side to spot-check all the flavours post-fix, I wouldn't be against it.  I just don't want to force all the community people who are "done" testing to start over on release day.
[17:50] <slangasek> davmor2: ok.  please note that what Laney describes is his existing boot entries in firmware being wiped, /without/ installing Ubuntu.  He only booted to the bootloader
[17:50] <willcooke> infinity, gotya - that makes sense
[17:51] <Laney> There's not so many changes between pygobject 3.18 and 3.20, so I'm going to upload that
[17:52] <Laney> (to change bugs a second)
[17:53] <davmor2> Laney: slangasek so it doesn't happen on my Lenovo let me test on this xps 13 biab
[18:00] <davmor2> Laney: on your xps 13 do you have bootx64.efi in /boot/efi/EFI/boot/ ?
[18:02] <davmor2> slangasek: if the answer from Laney is no that is what the issue is by default the efi system looks for that file if it isn't there is doesn't see the harddrive and so you have to manually create an efi entry for it
[18:02] <slangasek> davmor2: no, that is not the issue
[18:03] <slangasek> davmor2: the issue Laney is describing is "I stuck an Ubuntu USB stick in my system, booted to the bootloader, and my firmware forgot how to boot my hard drive".
[18:03] <slangasek> /boot/efi/EFI/boot/bootx64.efi is a workaround for /recovering/ from this
[18:05] <davmor2> Laney: also what version of the bios are you on?
[18:05] <davmor2> biab
[18:22] <infinity> superm1: Okay, building mythtv in a clean PPA, we'll see if that goes better.
[18:22] <superm1> Okay thanks
[18:23] <flocculant> infinity: this swap bug - is that a major issue? I've had probably two people mention it to me in months and months - I can never confirm it - indeed I can't confirm it now either
[18:23] <davmor2> slangasek, Laney: Right I remove my manual entry of /boot/efi/EFI/boot  I then rebooted in UEFI created the entry point to ubuntu that then boots with no issues, once I install the USB pendrive not it removes the previous Ubuntu entry I created which I assume is what Laney is seeing.  If I manually now add the file and folder back it doesn't remove the ubuntu entry
[18:24] <davmor2> s/not it/now it
[18:24] <davmor2> and the only entry I have is for the usb pendrive
[18:24] <infinity> flocculant: It's a non-issue entirely on fresh disks, it's certainly an annoyance when reinstalling.
[18:25] <davmor2> slangasek: so if Laney is missing that file that is likely to be the cause of the bug
[18:25] <flocculant> infinity: not for me in vbox - ever
[18:26] <infinity> flocculant: Huh.  Can't tell if you're lucky or others are unlucky.
[18:26] <flocculant> and that's what the bug appears to be about
[18:26] <flocculant> infinity: ha ha
[18:26] <davmor2> slangasek: it is likely to only affect xps13 users to and some asus iirc
[18:27] <davmor2> flocculant: are you installing on hardware? I don't see it in kvm only on real machines
[18:27] <slangasek> davmor2: the /cause/ of the bug is buggy firmware.  The absence of /boot/efi/EFI/boot/bootx64.efi is not the cause of the bug; we do not install /boot/efi/EFI/boot/bootx64.efi, it would help if we did but it's not implemented and it's a workaround for the firmware bug
[18:30] <davmor2> slangasek: agreed and if Laney is missing that file then his system will boot happily with a manually added entry pointing the the shim file but the minute he adds the pendrive it removes it.  If he has that file and this is still happening then it could be another issue altogether, But I can replicate his symptoms exactly with the file removed.  And I agree it is a workaround for buggy fw which iirc was on my
[18:30] <davmor2> asus box and this xps13 box but not on my lenovo fw
[18:33] <davmor2> anyway TEA has been call back in 30
[18:49] <Laney> slangasek: Hope those are useful to you
[18:50] <Laney> Will pop back briefly tomorrow morning to perform any other steps, otherwise will be off for a week
[18:50] <Laney> (sorry!)
[18:52] <flexiondotorg> infinity, flocculant Just reading the backlog.
[18:53] <flexiondotorg> I've seen the swap issue on vms and hardware.
[18:53] <infinity> flexiondotorg: Right, I don't think anyone's disputing that it's a bug.
[18:53] <infinity> flexiondotorg: flocculant just seems to be the only person in the world who's never seen it.
[18:53] <infinity> (lucky him)
[18:53] <flocculant> davmor2: swap issue - never seen it - full stop, not in vb, kvm or hardware
[18:53] <flocculant> ha ha
[18:53] <flexiondotorg> However, in the last couple of days I've completed about 20 installs on hardware and VM for Ubuntu, Ubuntu MATE and Lubuntu.
[18:54] <flexiondotorg> I've encunter the swap issue once.
[18:54] <infinity> Methinks it might be slightly racy. :P
[18:54] <infinity> The giant hammer fix I'm thinking of would work around whatever race is there, but not really solve the issue itself.
[18:56] <flexiondotorg> infinity, I can be available to smoke test some image later if a respin is required, but not PowerPC because that takes ages.
[18:57] <flocculant> I would too - but I'd only be able to if you forced the error everywhere so I could see it :)
[18:57] <infinity> flexiondotorg: Given the types of changes we're discussing, I don't think much testing of PPC would be required, though confirming that they're still bootable would be worth doing before releasing them blind.
[18:58] <flexiondotorg> infinity, Can I test boot one image from one flavour? Is that sufficient?
[18:58] <flexiondotorg> For PPC.
[18:58] <infinity> flexiondotorg: Not really.  The goal is to make sure the image wasn't mis-built, do we're not releasing a blob of useless bits masquerading as an ISO.
[18:58] <infinity> s/do we're/so we're/
[18:59] <flexiondotorg> OK. You're making me sad. But I'll test boot Lubuntu Desktop and Ubuntu MAT Desktop for PPC.
[18:59]  * flexiondotorg glares at his USB DVD writer.
[18:59] <flocculant> infinity: what sort of time scale are we talking about?
[19:00] <infinity> flexiondotorg: Alright.  This is all still under the assumption that we intend to respin.  I'm leaving that up to slangasek and willcooke to make the final call.
[19:00] <flexiondotorg> OK.
[19:00] <infinity> flocculant: Realistically, if this drags on any longer today, *and* we decide we need to respin, we might delay the release to tomorrow.
[19:00] <infinity> I'd rather get it right than rush it.
[19:00] <flocculant> ok
[19:00] <flocculant> yea for sure
[19:01] <slangasek> Laney: thanks, yes, I take that as confirmation that this is the firmware doing something inappropriate
[19:02] <flexiondotorg> Just so I'm clear, the only issues on the cards for fix and the swap creation and EFI corruption?
[19:02] <flexiondotorg> *fixing are
[19:03] <slangasek> flexiondotorg: only swap creation. We can't fix buggy firmware from Ubuntu, and the workaround isn't landing for beta
[19:04] <infinity> slangasek: Okay, so that leaves the question of if "only swap creation" is worth fixing for beta, or just release noting.
[19:04] <slangasek> infinity: I'm going to defer to willcooke
[19:05] <infinity> Given it can only affect reinstalls, which are already a bit of a power user / QA tester thing to do.
[19:05] <willcooke> so far I haven't been able to recreate it
[19:05] <willcooke> trying again, and then considering blowing away my test machine
[19:05] <infinity> Well, blowing away the test machine makes it 100% unreproducible. :)
[19:05] <willcooke> :D
[19:06] <willcooke> ship it!
[19:06] <infinity> Since the bug has to do with existing swap being active when we try to smack it around.
[19:06] <infinity> Or, as I understand it.
[19:06] <rtg> superm1, I'm gonna start with https://lkml.org/lkml/2013/8/19/331 as a guide
[19:07] <flexiondotorg> willcooke, Do a full disk encrpytion install. Then do a full disk not encrypted install over the top.
[19:07] <flexiondotorg> Increases the odds of seeing it a little.
[19:09] <cyphermox> is someone already looking at the swap issue?
[19:09] <cyphermox> I mean, aside from me
[19:09] <infinity> So... Release announcement including something like "In certain cases, the installation may halt on failure to create or reinitialise the swap partition.  The workaround for this is to delete pre-existing swap partitions before starting the installer."
[19:10] <infinity> slangasek, willcooke: ^  +/-1
[19:10] <willcooke> +1
[19:10] <infinity> cyphermox: My simple workaround was going to be to walk /proc/swaps right before partitioning and swapoff anything that doesn't match /dev/zram*
[19:10] <infinity> cyphermox: But finding the actual bug would be nicer.
[19:10] <cyphermox> +1
[19:11] <cyphermox> why are swaps even automatically getting added? should that not only happen at boot?
[19:11] <slangasek> infinity: can we really say that this isn't the bug? isn't systemd working as designed, autoprobing swap?
[19:12] <infinity> slangasek: It might be working as designed, yes.  I'm unsure myself.
[19:12] <cyphermox> what about just making systemd not autoprobe swaps just for the installer?
[19:12] <cyphermox> (ie, in casper or something)
[19:12] <infinity> slangasek: If it is, indeed, doing what it's meant to here, and we decide its actions are Pure and Good and True, then installer partitioners indeed just need to handle swapoffing the world before partitioning.
[19:13] <infinity> cyphermox: If systemd is autoprobing swap and making good use of it, restricting that from casper would cripple people who use livecds as, well, livecds.
[19:13] <infinity> cyphermox: swapoffing in the installer would be the more friendly solution.
[19:13] <cyphermox> infinity: heh
[19:13] <cyphermox> you don't have swap on a CD
[19:14] <cyphermox> they might have swap on the disk otherwise, but that's far from being certain ;)
[19:14] <infinity> Well, yes.  But if they do have swap on disk, and we activate it, their live session just got (potentially) less crap.
[19:14] <cyphermox> that said, if we can just swapoff the world before partitioning, that should be easy
[19:14] <infinity> Why would we take the possibility for that away?
[19:14] <stgraber> seems a bit odd to me that a live usb stick or live cd would start using a random partition on my hard drive just because it's got the right partition type
[19:15] <cyphermox> ^ that
[19:15] <infinity> stgraber: And indeed, that's the other argument. :)
[19:15] <infinity> Which would then be a systemd bug full stop.
[19:15] <stgraber> on an installed system that's fine, but if the goal of a live media is not to touch what's installed on disk, then what we're doing right now is pretty wrong
[19:15] <slangasek> that would be the argument for it being a systemd bug, yes
[19:15] <infinity> Cause you'd also expect the same from a dual-boot system (don't use the other OS's swap unless I said so, jerkface)
[19:15] <cyphermox> it's not really such an issue anymore that I know, but slowlaris used to write the magical kernel crash dumps to its swap
[19:15] <slangasek> doesn't matter if it's installed or live, random swap activation is either ok or not ok
[19:15] <cyphermox> oh, hibernate ;)
[19:15] <stgraber> oh yeah, also wouldn't the current behavior completely break an existing suspend to disk?
[19:16] <infinity> STD writes a signature.
[19:16] <infinity> I kinda hope any auto-activation is smart enough not to touch those.
[19:16] <infinity> But also potentially broken, yes.
[19:16] <cyphermox> well, let's see systemd then
[19:16] <infinity> So, lots of open questions here for later.
[19:16] <infinity> But for today, we're good with release-noting and release announce mentioning the issue?
[19:16] <infinity> slangasek: Still waiting on your +1 on that.
[19:17] <slangasek> infinity: yes, +1
[19:17] <infinity> Alrighty.  Then I guess we're not respinning (except for myth, when I get superm1's fixes through), and I can pre-publish.
[19:18] <infinity> cyphermox: I think that, even if we decide systemd is being dumb, it's probably right for partman to swapoff non-ram devices before trying to abuse the disk *anyway*.
[19:18] <infinity> cyphermox: Then we can sort out if systemd's also being a jerk.
[19:18] <cyphermox> yes
[19:19] <cyphermox> assign the bug to me, I will need to rebuild ubiquity to fix keyboards anyway
[19:19] <cyphermox> or, I expect I will
[19:20] <infinity> cyphermox: I imagine the fix belongs in partman, not ubiquity, ubiquity just happens to be the only one that sees the bug because d-i boots with a shell-based init instead of something fancy like systemd.
[19:20] <cyphermox> well, swapoffing yes
[19:20] <cyphermox> but it needs to be pulled in to ubiquity anyway
[19:20] <infinity> I feel bad about verbifying swapoff.  swapoffing sounds so awful.
[19:21] <infinity> cyphermox: *nod*
[19:21] <cyphermox> too late
[19:21] <infinity> cyphermox: https://bugs.launchpad.net/ubuntu/+source/partman/+bug/1552539
[19:21] <ubot5> Launchpad bug 1552539 in ubiquity (Ubuntu) "Ubiquity Erase Disk and Install Fails to create Swap Space" [Critical,Triaged]
[19:21] <infinity> cyphermox: Assign away, I can never remember your LP UI, and too lazy to search right now.
[19:22] <infinity> s/UI/UID/
[19:22] <cyphermox> yeah, I meant to make my LP UID cyphermox after all, but PPAs and all.
[19:23] <infinity> cyphermox: Meh, no one can love their PPAs that much, surely.
[19:23] <cyphermox> it's not love, it's just laziness
[19:23] <infinity> :)
[19:23] <infinity> Well, if you ever delete all your PPAs, let me know, and I'll rename you. :P
[19:23] <cyphermox> I suppose I could wipe everything later
[19:24] <cyphermox> I will still need a PPA that can build everything though
[19:24] <infinity> willcooke: Okay, so looks like the last thing I need from your team is a bit more i386 testing, and a signoff on both images being "good enough".
[19:25] <willcooke> I'll do that now
[19:25] <infinity> willcooke: And hopefully you and slangasek have sorted out assignment and blame for all the current bugs so we can fix them in the next week or so instead of forgetting until release week.
[19:27] <willcooke> :)
[19:29] <infinity> willcooke: Not being entirely facetious there.  We sometimes have a nasty habit of only remembering bugs during a testing cycle, which isn't the ideal time to fix them. :P
[19:29] <willcooke> infinity, understood.  I have a spreadsheet
[19:31] <infinity> superm1: Still waiting on those mythtv builds, but I'll ping you as soon as it's all copied over so you can ACK the binaries and we can unblock and get you rebuilt.
[19:36] <infinity> superm1: Oh, looks like I have an hour or more to wait for armhf still.  I'll take lunch, and then get back to you.
[19:37] <infinity> superm1: It's building in https://launchpad.net/~adconrad/+archive/ubuntu/staging/+packages FWIW.
[19:39] <wxl> um, are we planning to release today?
[19:39] <infinity> wxl: Yep.
[19:39] <wxl> infinity: k, cool. just checking. :)
[19:43] <infinity> wxl: If you feel like being helpful/annoying, you can chase people down to make sure their beta-2 pages are all existing and check the main ReleaseNotes for accurate links, etc.
[19:43] <wxl> infinity: okie dokie
[19:43] <infinity> (pretty sure it all points to 16.04/release right now when it should be 16.04/beta-2, for instance)
[19:44]  * infinity goes on a quick hamburger hunt.
[19:51] <davmor2> slangasek: https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1561712 this is the new bug for the issue I though Laney was reporting.
[19:51] <ubot5> Launchpad bug 1561712 in grub2 (Ubuntu) "EFI doesn't show multiple installs of the same operating system" [Undecided,New]
[19:52] <davmor2> this isn't critical or anything
[19:52] <davmor2> slangasek: it would just be nice to have
[19:54] <slangasek> davmor2: that's going to be a wontfix
[19:54] <davmor2> slangasek: why is that?
[19:55] <slangasek> you get the boot menu from inside of grub, you won't have it at the UEFI level
[19:56] <infinity> Or, more to the point, we're not going to install EFI/ubuntu-1, EFI/ubuntu-2, etc.  That way lies madness.
[19:57] <davmor2> slangasek: fair enough
[19:57] <infinity> There might be something we can do to refcount EFI/ubuntu, though, to at least avoid the "I installed two and deleted one, and now it's all gone" problem.
[19:58] <infinity> Though I'm unsure how that would happen unless you actually use dpkg to uninstall grub-efi before deleting the OS you wanted to get rid of.
[20:00] <davmor2> infinity: if you delete the partition to make use of the full hdd the entry point would nolonger exist right
[20:00] <infinity> davmor2: If you delete the EFI partition all bets are off for your old EFI OSes anyway.
[20:01] <infinity> That's not only something we can't fix, it's expected behaviour.
[20:01] <davmor2> infinity: not the efi partition the os partition or is all of grub now stored in EFI partition
[20:01] <infinity> The bit you're talking about is in the EFI partition...
[20:03] <davmor2> infinity: for example |efi|16.04|swap|16.10| 16.10 is aweful so delete it and then have |efi|   16.04   |swap|
[20:04] <davmor2> infinity: so that would keep the efi mount point from 16.10 but that would also pin point the 16.04 install too
[20:05] <willcooke> meh - dont try and install 4 vms at the same time
[20:05] <willcooke> davmor2, I'm going through the i386 test cases arm
[20:05] <willcooke> atm
[20:05] <wxl> infinity: yofel/kubuntu is kind of stuck with bug 1561051. if you have any suggestions to debug, please pass them yofel's way.
[20:05] <ubot5> bug 1561051 in ubiquity (Ubuntu) "Ubiquity-DM dies on Kubuntu images" [Undecided,Confirmed] https://launchpad.net/bugs/1561051
[20:07] <davmor2> willcooke: 4 at the same time is fine as long as the resources are low enough
[20:08] <infinity> wxl: I'm afraid I have no clue.
[20:09] <wxl> infinity: i figured as such. just thought i'd pass it on.
[20:09] <yofel> I would already be happy if someone told me how ubiquity-dm is launched... I have no idea what "program" I'm supposed to pass to it
[20:09] <wxl> infinity: asked them to either mark not-ready or to update the Beta2 page, which, at this point, seems cleaned up.
[20:09] <infinity> yofel: I'm sure cyphermox can help you with some basic ubiquity-dm debugging tips.
[20:10] <yofel> ok, thanks
[20:10] <infinity> yofel: Does the live session (and ubiquity invoked from the desktop) work fine?
[20:11] <infinity> yofel: If so, I'd suggest that unless you can fix this issue in the next hour or so, you release note that installs must be done from the desktop and we revisit tomorrow.
[20:11] <yofel> yes (well, the widget that shows the icon is too small to properly show it, but you can start ubiquity)
[20:11] <infinity> yofel: But if it's broken entirely, not releasing may be the only option. :/
[20:12] <yofel> nah, we can release, we're just missing the language selection I think. The desktop also looks somewhat broken, but not unusable
[20:12] <yofel> and the install itself went fine in my tests
[20:12] <infinity> yofel: Kay.  I'll come back around to you in a bit when everything else seems ready, and we'll sort out some wording to throw in the Kubuntu section of the release announcement to warn people about breakage.
[20:13] <yofel> thanks, I'll be around for a few more hours
[20:13] <wxl> yofel: meanwhile, update the Beta2 page :)
[20:13]  * infinity goes to finish his lunch.
[20:14] <davmor2> slangasek, infinity, cyphermox: out of interest how do you get a tty from the ubiquity session or do you have to go to the desktop session?
[20:15] <cyphermox> you can't right now, but we can fix that
[20:15] <cyphermox> (in fact, I want to fix that, because it's annoying)
[20:15] <davmor2> cyphermox: :)
[20:16] <superm1> davmor2: it's a little hacky but if you open network manager settings and try to import a vpn configuration you can right click and hit "open in file manager", then in file manager browse to /usr/bin/ and double click gnome-terminal.real
[20:18] <davmor2> cyphermox, willcooke: so I just tried all the options for the swap format issue and it affect all the automatic partitioning options on mac and lenovo so only lvm/encryptedlvm automatic installs work or manual partitioning
[20:18] <davmor2> I'll add that info to the bug
[20:20] <cyphermox> sounds about right. if you use LVM/encrypted all partitions are deleted, and with manual also all partitions end up getting replaced/deleted.
[20:20] <willcooke> davmor2, if you're around for a bit, would appreciate an extra pair of hands on the i386 ISO tests
[20:20] <willcooke> so we can mark them good enough
[20:22] <davmor2> willcooke: Yeah I'm around till it's done I need to go for a walk in a bit for testing the phone cause walks along canal towpaths in wolverhampton aren't dangerous enough :)
[20:22] <willcooke> that sounds like a terrible idea
[20:23] <cyphermox> infinity: I confirm my keyboard selection fix for d-i
[20:23] <cyphermox> ubiquity will still need more work though
[20:23] <cyphermox> (or I didn't test it right, but whatever)
[20:38] <davmor2> cyphermox: just confirming with no unity8 install secureboot enabled mokutil isn't trigger in additional drivers
[20:39] <cyphermox> mmkay
[20:39] <teward> cyphermox: there's a potential fix for the d-i keyboard issue?  (sorry just asking, i was looking for something in scrollback, saw your message)
[20:39] <davmor2> cyphermox: does from the command line and shows the mokutil section in the installer just not on additional drivers
[20:40] <cyphermox> there's a couple reasons why it might not be triggered, usually it's because the system isn't booted EFI; or SecureBoot is in a state where it won't actually check things, etc.
[20:40] <cyphermox> davmor2: I'm not sure what you mean by additional drivers?
[20:40] <davmor2> cyphermox: open the dash type additional drivers
[20:40] <cyphermox> teward: as I said, console-setup; but that also needs a rebuild of d-i
[20:40] <cyphermox> davmor2: ah, ok
[20:40] <teward> ah, i see.
[20:41] <davmor2> cyphermox: it is how you install binaries
[20:41] <cyphermox> davmor2: that's quite annoying then, additional dirvers should be happy to ask debconf questions :(
[20:41] <davmor2> cyphermox: for hardware
[20:42] <davmor2> cyphermox: yes and ask I say if I install fwts in the cli it asks me straight away same system same setup no modifications
[20:42] <davmor2> cyphermox: and nvidia definitely should trigger it
[20:42] <flexiondotorg> slangasek, infinity, willcooke Is this being release noted? http://launchpad.net/bugs/1555237
[20:42] <ubot5> Launchpad bug 1555237 in ubuntu-release-upgrader (Ubuntu) "Upgrade from 14.04.4→ 16.04 dies midway taking out the session." [Critical,In progress]
[20:43] <cyphermox> davmor2: yeah, I know what this is. please file a bug against additional drivers (software-properties, I think)
[20:44] <teward> cyphermox: thanks for looking into it though :)
[20:45] <davmor2> cyphermox: already filed it against mokutil so I'll just move that over and remove the unity8 concern I had
[20:45] <davmor2> willcooke: to answer your question I can install nvidia and intel microcode with unity8 session installed :)
[20:46] <willcooke> davmor2, thx
[20:46] <willcooke> flexiondotorg, yes, should be.  I can add it now...
[20:47] <davmor2> willcooke: still need to test amd on upgrade but obviously that needs upgrades to work
[20:48] <willcooke> davmor2, yeah.  I'm doing the last few mandatory i386 tests now, and then I think we will mark it "good enough"
[20:48] <davmor2> I got 3 on the go
[20:48] <willcooke> btw - is there a wiki page just for final beta release notes or do I add to this page: https://wiki.ubuntu.com/XenialXerus/ReleaseNotes/
[20:49] <davmor2> cyphermox: did you say there were bugs already for the broken OEM end user?
[20:49] <cyphermox> yeah
[20:50] <superm1> davmor2: bug 1552621 IIRC
[20:50] <ubot5> bug 1552621 in ubiquity (Ubuntu) "Can't login to desktop autometically after oem-config is finished on OEM mode" [Undecided,Confirmed] https://launchpad.net/bugs/1552621
[20:50] <cyphermox> also https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1508865
[20:50] <ubot5> Launchpad bug 1508865 in ubiquity (Ubuntu) "oem-config: networking not enabled during user config" [High,Confirmed]
[20:51] <wxl> willcooke: https://wiki.ubuntu.com/XenialXerus/Beta2
[20:51] <willcooke> ahha! Thanks wxl
[20:56] <davmor2> willcooke, cyphermox: https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/1561647
[20:56] <ubot5> Launchpad bug 1561647 in software-properties (Ubuntu) "No mokutil prompt triggered when installing from additional drivers" [Undecided,New]
[20:57] <cyphermox> davmor2: thanks
[20:57] <superm1> infinity: it finished finally on that ppa
[20:57] <superm1> infinity: when you copy it over don't forget to also let mythbuntu-meta out of proposed too
[20:58]  * flexiondotorg wonders if people testing in VirtualBox and VMWare that LP: 1370707 is intended behaviour now?
[20:58] <ubot5> Launchpad bug 1370707 in plymouth (Ubuntu) "Plymouth does not display the graphical boot splash" [Medium,Confirmed] https://launchpad.net/bugs/1370707
[20:58] <flexiondotorg> Because that a blacklisted, to ensure a sane resolution is negotiated by X.
[20:59] <flexiondotorg> Excuse the typing, I'm sat in pitch black room with no backlit keyboard.
[21:02] <infinity> willcooke: ReleaseNotes is a living document, there isn't one for each milestone.
[21:02] <jibel> willcooke, all the mandatory test cases are missing from the tracker for ubuntu deskktop apparently
[21:02] <willcooke> infinity, creating the Ubuntu one now, copied from the main release notes and removing a bit and adding a bit.
[21:02] <infinity> willcooke: Err, no.  Don't create an Ubuntu one. :)
[21:02] <willcooke> undo undo
[21:03] <infinity> willcooke: Just edit https://wiki.ubuntu.com/XenialXerus/ReleaseNotes
[21:03] <infinity> willcooke: The flavours like to do whacky things, but Ubuntu just uses the main document and updates it as we go.
[21:03] <jibel> willcooke, if you compare to http://iso.qa.ubuntu.com/qatracker/milestones/356/builds/112745/testcases the first section is missing
[21:03] <wxl> hey hey now infinity, maybe YOU'RE the one doing whacky things XD
[21:04] <infinity> wxl: Whackiness is in the eye of the beholder.
[21:04] <willcooke> jibel, so it is
[21:05] <doko> are autopkg tests for s390x turned off? didn't see any done when retrying tests
[21:06] <willcooke> jibel, how do we make it come back?
[21:06] <infinity> doko: The s390x queue is empty, that would seem to imply they're being run.
[21:07] <doko> infinity, but if you look at update_excuses (ruby2.3), then you see the rebuilds missing)
[21:08]  * flocculant ponders doing the not whacky thing with release notes in future ... 
[21:08] <willcooke> ok, got the swap issue and worked around it
[21:09] <infinity> flexiondotorg: The not whacky thing would just be to start at your "final location" with whatever milestone you start at, and keep editing it, instead of creating a new one for each milestone.
[21:09] <infinity> Err
[21:09] <jibel> willcooke, I readded the missing test suite
[21:09] <infinity> flocculant: ^
[21:10] <infinity> Too many fl nicks.
[21:10] <jibel> willcooke, it's 5 more mandatory tests
[21:10] <flexiondotorg> infinity, wha?
[21:10] <willcooke> "thanks" jibel ;)
[21:10] <infinity> flexiondotorg: Wrong fl.
[21:10] <flexiondotorg> infinity :-)
[21:11] <flocculant> infinity: yea - I got what you meant - I kind of build a draft through the cycle anyway
[21:11] <jibel> willcooke, i'm checking non english installs in i386
[21:11] <willcooke> thanks
[21:24] <davmor2> willcooke: so the system settings issue looks like it might be an issue triggered from the dash, maybe. If I search for an element ie open dash and look for screen and open it from there then I get the crash opening system settings for the first time after that
[21:25] <wxl> didn't we get an email from edubuntu saying they weren't participating in beta2?
[21:25] <davmor2> wxl I think edubuntu just weren't releasing at all for 16.04 iirc
[21:26] <wxl> davmor2: k. i'm going to mark them as "no" on /Beta2
[21:26] <wxl> they're not in the milestones, so there ya go
[21:28] <jibel> even keyboard detection is broken :(
[21:29] <willcooke> davmor2, weird.  Just tried on my fresh 16.04 amd64 install from like 10 mins ago, and it works here.  Please open a bug anyway against u-s-s and we can take a look
[21:30] <willcooke> oh btw - the genital warts thing is fixed
[21:30] <popey> hah, i arrive and that's the first thing I see
[21:30] <slangasek> that's... um... good news
[21:30] <willcooke> :)
[21:30] <davmor2> willcooke: there is already and apport bug for it let me dig it out
[21:30] <popey> nice one willcooke
[21:35] <davmor2> willcooke: https://launchpad.net/bugs/1546388
[21:35] <ubot5> Launchpad bug 1546388 in unity-control-center (Ubuntu) "unity-control-center crashed with SIGSEGV in _cogl_check_extension()" [Medium,Confirmed]
[21:36] <stokachu> can someone reject juju2
[21:36] <flexiondotorg> willcooke, My daughter finally sleeps.
[21:37] <flexiondotorg> What i386 test are remaining? I might be able to help with one.
[21:37] <davmor2> flexiondotorg: none
[21:37] <willcooke> flexiondotorg, thanks!  We're not doing too bad now
[21:37] <flexiondotorg> willcooke, Daviey Heroic effort you two :-)
[21:37] <flexiondotorg> Oops, davmor2. I meant you.
[21:37] <davmor2> :)
[21:37] <willcooke> wouldnt hurt to do a quick pass of a mandatory test
[21:38] <knome> Daviey, don't worry, you are heroic as well!
[21:38] <davmor2> willcooke: I've added a comment to it for when I triggered it.
[21:39] <jibel> flexiondotorg, CJK input is not tested
[21:39] <flexiondotorg> jibel, Not something I can help with :-(
[21:39] <davmor2> flexiondotorg: you mean you are not fluent in Chinese Korean or Japanese?? Why
[21:40] <flexiondotorg> davmor2, 没有
[21:41] <davmor2> flexiondotorg: hahaha
[21:41] <doko> stokachu, done
[21:42] <infinity> doko: D'oh, beat me by half a second.
[21:42] <doko> infinity, so any idea about the s390x issues?
[21:42] <infinity> doko: Not sure right now what's up there.
[21:43]  * flexiondotorg makes fish finger butty
[21:44] <infinity> flexiondotorg: Makes... What now?
[21:44] <flexiondotorg> superm1, Can we do anything to help test mythbuntu?
[21:44] <flexiondotorg> Is an install in a VM good enough?
[21:44] <superm1> flexiondotorg: waiting on infinity to re-spin with new packages
[21:44] <flexiondotorg> infinity, Food of the Gods. Ask willcooke and popey ;-)
[21:44] <flocculant> infinity: it's a very english thing I guess - you're not missing anything :p
[21:45] <superm1> flexiondotorg: an extra test on VM would be helpful.  it will boot up confused that it doesn't have a backend anywhere near by, but that is fine
[21:45] <infinity> superm1: Still need to get them through propose-migration, we'll get there.
[21:45] <willcooke> flexiondotorg, \o/
[21:45] <superm1> but testing with today's images without those packages leads to weird problems
[21:46]  * infinity reads https://en.wikipedia.org/wiki/Fish_finger_sandwich and loses his appetite.
[21:46]  * flexiondotorg is standing by. Someone ping me when a new mythbuntu image is available for testing
[21:46] <slangasek> doko: the autopkgtest api unfortunately is not completely reliable at making sure either your test is scheduled or you get an error.  I haven't looked deeply at this, but I've seen re-run requests go missing before.  If you don't see the request on http://autopkgtest.ubuntu.com/running.shtml, and you don't see the result on the corresponding per-package page within 5 minutes, I recommend re-submi
[21:46] <slangasek> tting the request
[21:46] <davmor2> flocculant: you lie. Fish Fingers are food from the Cods easy mistake to make
[21:46] <slangasek> doko: also, for most requests you shouldn't need to submit on snakefruit, you can do it directly from update_excuses nowadays?
[21:47] <davmor2> flexiondotorg: ^ even
[21:47] <davmor2> sorry flocculant
[21:47] <flexiondotorg> Homemade tarate sauce. Winning
[21:47] <doko> slangasek, not for building against -proposed, which is most of things I have to do
[21:47] <slangasek> doko: ok, true
[21:48] <doko> and this is one thing which probably should get more automating when to do tests against proposed
[21:48] <slangasek> doko: what are your cases for that?  That workaround usually implies a missing versioned dep/breaks, and I worry about things slipping into xenial in a half-broken state
[21:48] <slangasek> doko: well, fix the versioned deps/breaks and autopkgtest should DTRT for you, that should automate it
[21:48] <infinity> slangasek: In the ruby case, the tests all use a common framework, so if the framework is broken in the release pocket, you're SOL.
[21:49]  * flexiondotorg groans at "food of the cods" ;-)
[21:49] <slangasek> infinity: fair.  but that's not the common case IME
[21:49] <davmor2> flexiondotorg: hey it's late and true
[21:50] <flexiondotorg> :-D
[21:50] <infinity> slangasek: Indeed, no.  The other case would be where a specific bugfix has to happen in two packages in concert, but that doesn't imply that either breaks/conflicts with the previous versions, just that the previous ones were already broken. :P
[21:50] <doko> slangasek, but this is true for every transition. you want to run all these tests using the version in -proposed
[21:50] <infinity> slangasek: In most cases that aren't framework or multi-package fixes, I'd expect deps to get it right.
[21:51] <wxl> infinity: imma gunna leave the rest of the chasing to you.
[21:52] <willcooke> right, at this point I think I'm ready to say Desktop is good enough.
[21:52] <slangasek> doko: ok, I concede the point. I believe this warrants a bug report against the infrastructure
[21:52] <doko> ok, giving back for s390x
[21:52] <willcooke> infinity, do I have to do anything to mark it as ready?
[21:52] <wxl> willcooke: you mean "good enough for beta." ship it!
[21:52] <willcooke> :D
[21:52] <infinity> willcooke: Tick the two boxes, scroll to the bottom, and find "mark as ready"
[21:52] <willcooke> exactly
[21:53]  * popey belatedly concurrs that fish-finger buttys are nectar.
[21:53] <infinity> popey: You people are weird.
[21:53] <willcooke> I've got some pickled eggs downstairs
[21:53] <popey> Correct.
[21:53]  * infinity hugs his poutine.
[21:53] <flocculant> pickled eggs are fine
[21:53] <popey> *parp*
[21:54]  * wxl fetches a barf bag.
[21:54] <flocculant> indeed :)
[21:54] <willcooke> infinity, sorry - can't find these boxes.  Where should I be looking, in the ISO tracker?
[21:54] <infinity> willcooke: Yeah, the milestone page that lists all the ISOs.
[21:54]  * flexiondotorg makes another fish finger butty, because one is never enough.
[21:54]  * wxl does like nattõ, though
[21:54] <infinity> willcooke: You tick the little boxes to the left of Ubuntu Desktop {amd64,i386}, scroll down, find "Mark as ready" in the dropdown box, and "update build status.
[21:55] <stokachu> doko: thanks!
[21:55] <infinity> willcooke: Traditionally, I do this for desktop after I see enough tests roll in because no one else seems to know where the buttons are.  If you're taking over that responsibility, yay. :)
[21:56] <flocculant> ha ha
[21:56] <willcooke> infinity, am I missing access to something perhaps, or just stupid (note *or*)   http://imgur.com/ZGcDNdl
[21:57] <infinity> willcooke: Or not logged in?
[21:57] <willcooke> yeah, am logged in
[21:57]  * flexiondotorg wonders if I can make then ready?
[21:57] <flocculant> willcooke: should look like http://i.imgur.com/iPxldFJ.png
[21:57] <infinity> willcooke: Possibly an access issue, then.  You're listed as a contact for desktop, but perhaps that's not enough.
[21:58] <infinity> stgraber: *poke*
[21:58] <ogra_> willcooke, just talk to the desktop team manager to have him grant you prmission
[21:58] <flocculant> infinity: I thought ' release team member'
[21:58] <flocculant> at least that's how it works for flavours generally
[21:58] <willcooke> ogra_, :p
[21:58] <infinity> flocculant: Well, that's a bit of a misnomer too, since most of you aren't in ~ubuntu-release.
[21:58] <ogra_> :)
[21:59] <knome> infinity, xenial beta 2 ubuntu desktop images to ready?
[21:59] <jibel> willcooke, I marked Ubuntu Desktop as ready
[21:59] <flocculant> infinity: flavour release team
[21:59] <wxl> ouch that's a burn
[21:59] <willcooke> thanks jibel
[21:59] <infinity> Ahh, there are groups in the tracker.  Of course there are.
[21:59] <willcooke> \o/
[21:59]  * wxl makes ~ubuntu-flavor-release to spite infinity 
[21:59] <willcooke> *Thank you* everyone
[21:59] <flocculant> :)
[22:00]  * willcooke goes to look for a beer - brb
[22:00]  * wxl should note that's also to spite flocculant since it's not flavoUr XD
[22:00]  * flocculant hasn't far to look
[22:00] <knome> flocculant, yeah, the beer is in your head already...
[22:00] <slangasek> flavour flāv
[22:00] <flocculant> wxl: I ignore mad mispellings from the colonies
[22:00] <wxl> wut wut slangasek
[22:00] <flocculant> knome: hand :p
[22:00] <wxl> flocculant: hehehe :)
[22:01] <flocculant> :)
[22:01] <infinity> slangasek: Did he really spell it with the diacritic?
[22:01] <slangasek> infinity: no, nor with the onerous 'u'
[22:03] <infinity> jibel: server ISO testing, is that auto-filled?
[22:03] <infinity> jibel: Cause it's looking sparse on x86.
[22:03] <infinity> (I'll do ppc* now)
[22:05] <stgraber> infinity: access is done through SSO and Launchpad teams
[22:05] <jibel> infinity, no it is not.
[22:05] <jibel> let me quickly go through it
[22:05] <stgraber> infinity: the sign-off name is just a text field so we know who to nag on IRC, it doesn't create any extra access
[22:06] <infinity> stgraber: Kay.  So how do I know what teams are mapped to what?
[22:06] <infinity> stgraber: Cause the drop-down list for product access lists pretty names that don't map to anything in my mind.
[22:07] <stgraber> infinity: what matters is the owner field in http://iso.qa.ubuntu.com/admin/config/services/qatracker/products
[22:07] <stgraber> infinity: desktop belongs to no drupal role, so that means only the release team has admin access to the product
[22:07] <infinity> stgraber: Right, I found that.
[22:07] <infinity> stgraber: Can't be only the release team, jibel can twiddle it.
[22:08] <stgraber> well, release team and the qatracker developers
[22:08] <stgraber> which does include jibel
[22:09] <jibel> infinity, TBH I don't know for server. default tests pass but then everything more advanced is really red
[22:09] <stgraber> so if we know to give admin access to other folks, we need a LP team with the right folks in it, then I can map that to a drupal role and we can use that role as the owner of the desktop product
[22:10] <jibel> infinity, we'd need someone from the server team to approve the images. I cannot do it based only on the results of the automated tests, they are too bad
[22:10] <infinity> jibel: It would be nice if that was reported to the tracker before release day. :/
[22:11] <jibel> infinity, well, the server team is supposed to take care of its product
[22:12] <jibel> infinity, I'll talk to matsubara
[22:13] <willcooke> jibel, is the "Install third-party software for graphics.... etc etc" screen in the installer not being in French a known issue?
[22:13] <willcooke> or rather, is it in English for you too?
[22:13] <infinity> s/issue/feature/
[22:14] <jibel> willcooke, yes it is untranslated
[22:14] <willcooke> oki
[22:15] <jibel> willcooke, some pages of the slideshow are also in english
[22:15] <infinity> That should definitely be fixed before release.
[22:16] <jibel> willcooke, and in the list of languages there are some fonts missing at the bottom of the list
[22:17] <jibel> willcooke, the installer needs a review of the localization before release
[22:17] <flexiondotorg> The languages is test had the same untranslated strings in Ubiquity.
[22:18] <flexiondotorg> Where that install 3rd party stuff has been modified since 15.10.
[22:19]  * willcooke makes a note to follow up next week
[22:22] <infinity> jibel: Oh.  Do you have some pointers at the red tests?
[22:22] <infinity> jibel: I bet it's because I didn't get around to getting postfix off the CD, so all the automated tests stall on postfix wanting to be configured. :/
[22:22] <infinity> s/CD/default install/
[22:23] <jibel> infinity, https://platform-qa-jenkins.ubuntu.com/view/ISO%20Installer/view/Xenial%20Server%20d-i/
[22:23] <jibel> infinity, matsubara know there existence and has access to the instance and the code of the tests.
[22:24] <jibel> their*
[22:25] <rcj> infinity, should cloud images hold off on beta-2 publication?  if so, I'll check in after dinner and bedtime for the little one.
[22:26] <infinity> rcj: You can publish whenever you like, really.  But if you want to do it when I announce, that'll be in a few hours, I think.
[22:27] <rcj> infinity: I'm going to start so that I might take off some of tomorrow as planned (poorly planned)
[22:30] <infinity> jibel: I'm having a hard time seeing the failures in those tests (I mean, other than the red ball...)
[22:30] <jibel> infinity, I'll have a look with Max and Diogo tomorrow
[22:31] <infinity> jibel: Sure, but release is today. ;)
[22:32] <infinity> jibel: If basic install profiles work (as I just tested on ppc), I'd rather release an imperfect beta than no beta.
[22:34] <slangasek> infinity: hmm. what pulled postfix in?  that seems worth a respin and autoretest...
[22:34] <willcooke> I'm gonna go and get a couple of hours downtime. bbl.
[22:34] <infinity> slangasek: mdadm.  I was working on a patch locally to drop the Recommends to a Suggests along with an update-mot.d snippet.
[22:34] <infinity> slangasek: We could do the former without the latter for now, and I can add the snippet when it's done.
[22:35] <infinity> (I'm in a unique position to test this, as I have RAID arrays in varying states of sadness because I'm terminally lazy about replacing disks)
[22:35] <slangasek> infinity: that makes sense to me... probably with a tracking bug for the update-motd.d so it doesn't get lost?
[22:35] <infinity> slangasek: Kay.  Can do.  I think there's a bug already, lemme go find it.
[22:36] <infinity> Well, there's this: https://bugs.launchpad.net/ubuntu/+source/mdadm/+bug/1549319
[22:36] <ubot5> Launchpad bug 1549319 in mdadm (Ubuntu) "server iso install prompts for postfix config" [Medium,Confirmed]
[22:37]  * lamont supports getting postfix off the CD
[22:37] <infinity> Right, that's the one I was thinking of.
[22:37] <infinity> So, I'll reference that in the upload, but not close it.
[22:37] <infinity> lamont: It'll still be on the CD, just not in the default install.  The latter is the oops.
[22:39] <lamont> better
[22:42] <infinity> slangasek: --^
[22:42] <infinity> rcj: Note that this change would also change cloud images too, unless you've been manually working around it and not installing postfix...
[22:43]  * infinity looks at a cloud image manifest.
[22:43] <infinity> Yeah.  Has postfix in it.
[22:43] <flocculant> infinity: so are we looking at hours for announce?
[22:43] <cyphermox> I discussed mdadm weeks ago with smoser
[22:43] <cyphermox> I thought he had already fixed this
[22:43] <infinity> cyphermox: Yeah, and he discussed it with me, and we came up with a plan, and I took ownership because I can test it and he can't (as easily), and then it failed to happen before beta because derp.
[22:44] <cyphermox> oh ok
[22:45] <infinity> flocculant: Yeah.  A fair number of them, I'd say, if we're going to do a quick server respin.
[22:45] <cyphermox> then he probably talked to you because he said you had some thoughts about the Recommends vs. Suggests for a mta
[22:45] <lamont> smoser and I also talked about mdadm vs postfix, and yeah... that. Suggests: is right
[22:45] <infinity> cyphermox: Yeah, I had conditions about dropping the Recommends, namely having another vaguely reasonably visible method of whining.
[22:45] <infinity> (the motd thing)
[22:45] <lamont> s/right/reasonable/
[22:46] <cyphermox> makes sense
[22:46] <infinity> So, will fix that later.  But the above upload changes the relationship at least.
[22:46] <flocculant> infinity: oh right - thanks - just needed to know, I've been up for 19 hours now and am about 20 years too late for an all-nighter :p
[22:46] <infinity> flocculant: I have no intention of preventing you from sleeping.
[22:46]  * infinity self-reviews that mdadm.
[22:46] <flocculant> ha ha
[22:47] <infinity> I also might pretend that I don't notice that mdadm is on the lubuntu alternates, so I don't force them to re-test...
[22:48] <infinity> slangasek: Want to review that post-upload and unblock if you think it's worth respinning server?  Kthx.
[22:49] <slangasek> infinity: looking
[22:49] <slangasek> infinity: yes, you appear to have spelled 'Suggests' correctly
[22:52] <infinity> slangasek: It was hard, but I Googled.
[22:57]  * infinity raises his brow.
[22:58] <infinity> balloons: Well, that seems to raise the stakes a bit.  No more "we're shipping two versions, so can we put one in universe and pretend it doesn't suck"?
[22:59] <stokachu> infinity: exactly
[22:59] <stokachu> xenial == juju 2.0 with juju 1 in the ppa
[22:59] <infinity> stokachu: Well, that just means the juju team needs to commit even harder to juju2 not sucking. :P
[22:59] <jibel> infinity, I looked at the failures of server tests, the installation is successful but the post-installation tests are failing for various reasons. So either the server testsuite is unmaintained or there is a real problem
[22:59] <stokachu> infinity: haha
[22:59] <infinity> stokachu: Yeah, wasn't being sarcastic.
[23:00] <infinity> jibel: That sounds a lot like test infra hating us.
[23:00] <stokachu> infinity: you should wait for beta 3 then
[23:00] <stokachu> or beta 10
[23:00] <jibel> infinity, the test infra is fine otherwise the installation would fail too
[23:00] <infinity> jibel: I mean the tests, sorry, not the actual infra behind them.
[23:01] <jibel> infinity, right
[23:01] <infinity> jibel: But if they all fail similarly, it would be some scaffolding they have in common.
=== davmor2 is now known as davmor2_HOLS
[23:01] <infinity> (Or some feature they're expecting on the installed system that isn't there anymore and they shouldn't be relying on)
[23:01] <infinity> jibel: Anyhow, my perusal of them came to a similar conclusion that things seem to work for the bits I care about (ie: stuff installs).
[23:01] <jibel> infinity, for example for tomcat the test checks if the deamon is running and it is not
[23:02] <jibel> infinity, yes, the installer works
[23:02] <jibel> no doubt about it
[23:02] <infinity> jibel: I think we can probably agree we're in "good enough for a milestone" territory, but clearly someone needs to apply love to the automated testing and figure out what/where to lay blame.
[23:03] <jibel> infinity, I'm fine with that
=== s8321414_ is now known as s8321414
[23:19]  * flexiondotorg snorts and wakes himself up.
[23:19] <flexiondotorg> How goes things? Anything I can do to be useful?
[23:24] <wxl> are we there yet?
[23:24] <infinity> About to respin myth.
[23:24] <wxl> oh my.
[23:24] <infinity> Yeah.  Life's never simple, is it?
[23:25] <wxl> guess nawt.
[23:39] <infinity> slangasek: Before I go and respin server, do we have someone who knows how to smoketest s390x to make sure it didn't break?
[23:39] <infinity> slangasek: I'm prepared to do the other 4.
[23:42] <rcj> infinity, yes, postfix in cloud images
[23:42] <infinity> rcj: Yeah, I checked the manifest and confirmed that.
[23:43] <slangasek> infinity: I had in fact intended to forego the smoketesting on respin given the narrow scope of the change and the cumbersome nature of smoke testing
[23:43] <slangasek> dannf: ^^
[23:43] <infinity> rcj: If you want to respin after the new mdadm lands to remove postfix, shiny.  If not, meh.  I know most of your users don't use milestones anyway.
[23:43] <slangasek> dannf: (fyi only and to give you the opportunity to disagree; if you and/or infinity feel strongly about this I will dig up instructions on how to test)
[23:43] <infinity> slangasek: Well, I was going to boot/install/reboot smoke the 4 arches I can do quickly.  If you want to skip s390x based on those other 4 being tested and an assumption about reliability of our process, that's fair.
[23:44] <infinity> Takes me ~15 to do x86*2 and ppc*2.
[23:44] <dannf> slangasek: no disagreement
[23:44] <rcj> infinity: most of our users don't care about milestones, we'll have a daily tomorrow :)
[23:44] <infinity> s/15/15m/
[23:44] <infinity> rcj: Right, that's what I figured.  Honestly not sure why you do milestones at all.
[23:45] <Ukikie> FWIW, got an irssi bugfix incoming.
[23:45] <slangasek> infinity: the most common boot path for this image is "rip it open on an ftp server and copy the kernel into the HMC", which I don't think mdadm is going to regress
[23:45] <rcj> infinity, re-spin and delivery for cloud-images would be ~18 hours.  We'll have another significant point for testing once cloud-init changes land to give us sane cloudy behavior with systemd's "predictable" network interface names
[23:45] <infinity> slangasek: No, true.  Maybe the only smoketest required is to tear open the ISO and verify it's an ISO with files in it. :P
[23:46] <rcj> infinity, good point in time for us to get clouds to pay attention to the development release and make sure their stuff works. :)
[23:46] <rcj> and we make sure that our new build/publication infra works before April ;)
[23:47] <infinity> rcj: Heh, indeed.  Doing beta-2 is valuable, I more wonder why you participate in *every* milestone.
[23:47] <infinity> rcj: You're the only Canonical/Ubuntu product that does.
[23:47] <slangasek> yes, would be great if you stopped doing that ;)
[23:48] <rcj> infinity, we're the base for other things like MAAS.  Juju gets to test on a 'milestone' which means ensuring their 'release' stream is functional, not just 'daily' stream generation and consumption.
[23:48] <rcj> infinity, which is to say, eh.
[23:49] <infinity> rcj: Oh, that's fair if they need one blessed image in the release stream to test against.
[23:49] <rcj> and now we'll have folks running against beta-2 in the release stream until GA rather than using fresh daily images, but you can't win them all
[23:50] <infinity> Quite.  That's the reason I hate milestones.  I love periodic test cycles, but kinda wish we would just throw away the results.
[23:50] <infinity> ie: All gather around for a week and test the crap out of everything, but then tell users to keep testing dailies.
[23:50] <infinity> And never actually "release" alpha/beta images.
[23:50] <infinity> Cause that seems to encourage people to install old, buggy images.
[23:50] <rcj> a little postfix breakage on package upgrades might be just enough to move people back to the daily stream
[23:52] <rcj> Well, we could just tell cloud users to pick up the current daily and just use the release calendar to drive when we poke people to get extra eyes on things.
[23:52] <infinity> slangasek: I wonder how hard it would be to turn "milestones" into "ISO testing weeks", and stop releasing milestones altogether.
[23:53] <infinity> The testing bit is clearly important.  The released product is general not something we want people using for long.
[23:53] <infinity> s/general/generally/
[23:54] <rcj> infinity, slangasek: I'll bring this up with the team and we can pursue this further here in time for y-series development.
[23:54] <infinity> Dear britney, please find mdadm and do stuff to it.  Kthx.
[23:54] <infinity> rcj: Yeah, I think you guys are unique snowflakes here, since people generally use your frequent respins, even on a stable series.
[23:58] <rcj> infinity, I sure hope they do :)
[23:58] <infinity> rcj: I'm trying to sort out how to get the rest of the distro to a similar point.  The major sticking point is that "the media" likes having blessed images to review and write terrible things about.
[23:58] <infinity> (or wonderful things)
[23:58] <rcj> infinity, I'll bring this up at the next cloud sprint.  Our release notes entry might point at latest daily next time.
[23:59] <stokachu> could i get a nod on conjure and bigdata? and juju-core too if possible :)
[23:59] <infinity> stokachu: A nod, as in an acknowlegement that you uploaded them?  Nodding away.