[00:07] <infinity> wxl, tsimonq2: What's new is infrastructure changes to build the images correctly.  Packages (other than a couple of small security updates that snuck in) aren't different.
[00:08] <infinity> Also, lubuntu i386 didn't build.  I'll need to retry that.
[00:08] <wxl> infinity: i already got tsimonq2 on that
[00:09] <infinity> wxl: Oh?  I don't see it building anywhere.
[00:09] <wxl> infinity: well he said he was going to do it
[00:09] <wxl> infinity: in any case, we can take care of that. don't worry about it
[00:10] <wxl> infinity: do you have any idea what those security updates are?
[00:11] <infinity> wxl: https://lists.ubuntu.com/archives/xenial-changes/2017-February/thread.html
[00:11] <wxl> infinity: thanks :)
[00:11] <infinity> wxl: Look for things accepted to xenial-updates after base-files/linux-hwe.
[00:11] <infinity> Most of those weren't on ISOs.
[00:12] <infinity> ffmpeg would be on most ISOs.
[00:12] <infinity> And libgc is on some.
[00:12] <infinity> That's about it.
[00:13] <wxl> starting with debian-installer 20101020ubuntu451.10 (Accepted)  ?
[00:13] <wxl> oops
[00:13] <tsimonq2> wxl: Oh? I was just at dinner. :P
[00:13] <wxl> that's proposed
[00:13] <wxl> starting with open-vm-tools 2:10.0.7-3227872-5ubuntu1~16.04.1 (Accepted)
[00:13] <infinity> wxl: The real changes were mangling the code that generates the bootloader configs and such.
[00:13] <wxl> tsimonq2: well get off your butt and do your job :)
[00:13] <tsimonq2> wxl: I'm on it dude jeez :)
[00:13] <wxl> tsimonq2: :)
[00:14] <tsimonq2> wxl: :)
[00:14] <wxl> infinity: a d-i change? https://lists.ubuntu.com/archives/xenial-changes/2017-February/015941.html
[00:14] <infinity> wxl: d-i isn't on your images. :P
[00:14] <tsimonq2> wxl: Huh where which image?
[00:15] <wxl> tsimonq2: amd64
[00:15] <tsimonq2> wxl: No I mean which codename?
[00:15] <tsimonq2> Xenial? Zesty?
[00:15] <wxl> tsimonq2: xenial xanadu
[00:15] <tsimonq2> :P
[00:15] <wxl> xerxes xylophone
[00:15] <infinity> Hrm?  lubuntu-xenial-i386 is the one that didn't build.
[00:15] <infinity> I feel like I could have just fixed that for you 10 minutes ago.
[00:16] <tsimonq2> infinity: Where? O_o
[00:16] <wxl> http://iso.qa.ubuntu.com/qatracker/milestones/372/builds
[00:16] <infinity> tsimonq2: What do you mean "where"?
[00:17] <tsimonq2> infinity: nvm
[00:22] <infinity> tsimonq2: Lemme know when you've sorted it (or just want me to do it), I'm blocking on you.
[00:23] <infinity> (Need to build source DVDs, but won't do that until after lubuntu is sorted, or I'd end up blocking you for 4 hours)
[00:25] <wxl> actually
[00:25] <wxl> we may need to have you do it infinity
[00:25] <wxl> at least assuming we can't request a rebuild while rebuilding
[00:25] <wxl> i think the tracker's stuck in some weird state
[00:25] <infinity> Ahh, did you try?
[00:25] <wxl> because we have a build log for a successfully build image
[00:26] <infinity> Then I might have to do it from my end, yeah.
[00:26] <tsimonq2> infinity: Yeah looks like it
[00:26] <infinity> Kay.  Stop touching it, I'll fix. :P
[00:26]  * wxl slaps tsimonq2 's hand
[00:26] <tsimonq2> :O
[00:26] <tsimonq2> k
[00:28] <wxl> in other news it looks like lubuntu has some ffmpeg libs, assumedly because we use ffmpegthumbnailer in pcmanfm
[00:28] <wxl> so we'll probably want to check that just to be sure
[00:28] <infinity> Yeah, most everyone has ffmpeg somewhere.
[00:29] <infinity> To be fair, though, unless it breaks the *installer*, I don't deeply care, you can escalate regressions to the security team to fix after the release.
[00:29] <wxl> could also affect video/audio players, i assume?
[00:29] <infinity> And I don't think anyone plays video in their installer.
[00:29] <wxl> XD
[00:29] <wxl> YOU"D BE SURPRISED
[00:29] <lynorian> infinity, live session
[00:29] <tsimonq2> infinity: I can get you a PR in ~ 2 hours XD
[00:29] <infinity> lynorian: Sure, you *can* play video in a live session.  But if "software in the live session has bugs" was release critical, we'd never release.
[00:30] <infinity> Cause good luck having an ffmpeg or firefox or libreoffice with "no bugs".
[00:30] <wxl> what is exactly the difference between the .manifest and the .list?
[00:30] <infinity> wxl: manifest is the list of packages installed in the livefs.  .list is the file list on the ISO.
[00:30] <wxl> ah
[00:33] <wxl> um
[00:33]  * infinity is pretty non-plussed with his body for decided that a 3 hours nap was enough after being up for over 24.
[00:33] <wxl> ffmpeg is not in .list tho? that's iiiinteresting
[00:33] <infinity> s/decided/deciding/
[00:33] <infinity> wxl: Why would it be?
[00:33] <infinity> wxl: Re-read what I wrong.
[00:33] <infinity> wrong?
[00:33] <infinity> wrote.
[00:33] <infinity> re-read what I wrote. :P
[00:34] <wxl> OH
[00:34] <wxl> derp
[00:34] <infinity> .list is the file list on the ISO.  Literally a directory listing of the CD.
[00:34] <wxl> nevermind
[00:34] <tsimonq2> infinity: You and teward should have landed some stuff last night (he was overly sleep deprived too :P) hehehehe
[00:34] <infinity> desktop CDs have very few packages on the ISO, cause most of them are preinstalled in the livefs.
[00:34] <wxl> right right
[00:34] <wxl> got it
[00:36] <infinity> wxl: Or, from a task perspective, livefs (and thus manifest) is minimal+standard+$flavour-desktop+$flavour-live
[00:36] <infinity> wxl: While /pool/ on the ISO, and thus in .list is ship-live.
[00:39] <powersj> infinity: forgive me if you have said this, but for server is the 20170215.8 ISO the final one?
[00:41] <infinity> powersj: It's final unless someone finds a critical bug in it.
[00:42] <infinity> Everything on http://iso.qa.ubuntu.com/qatracker/milestones/372/builds (except the rebuilding lubuntu/i386) is what I'm hoping to release.
[00:42] <powersj> ok thanks
[00:44] <powersj> server amd64, i386, and ppc64el ISO tests are kicked off. I'll update results later tonight
[00:45] <infinity> powersj: Oh.  Yeah.  Server ISOs now have two kernels, which means the boot menus changed a bit.  If you're testing with preseeds, that shouldn't matter, but if you have infrastructure that scripts manipulating the bootloader menus, that might break.
[00:46] <cyphermox> oh look, netboots still need testin'
[00:46] <powersj> infinity: thanks for the heads up, that would explain why they are oversized :(
[00:46] <infinity> Yeah, they're a bit bigger. :P
[00:46] <infinity> Can't do much about that.
[00:46] <powersj> yeah
[00:48] <wxl> two kernels? whaaaaaa
[00:48] <powersj> hwe
[00:48] <wxl> oh
[00:48] <wxl> bah
[00:49] <xnox> infinity, the comment inside the hwe preseed is funny "If we're booting using the backported Vivid kernel, install it too."
[00:49] <xnox> infinity, what's Vivid?
[00:49] <infinity> Hahahaha.  Wow, I've missed that comment for how many years? :)
[00:50] <xnox> infinity, i guess you are in a similar panic induced productivity mode each time =)
[00:51] -queuebot:#ubuntu-release- Builds: Lubuntu Desktop i386 [Xenial 16.04.2] has been updated (20170216)
[00:52] <infinity> xnox: Oh well.  Can fix it on the next d-i build.  Comments aren't RC. :P
[00:53]  * infinity kicks off a source DVD build and goes to figure out if he needs food or sleep or play or something else entirely.
[00:54] <tsimonq2> Am I being impatient, or is kopete taking forever to migrate from zesty-proposed?
[00:55] <infinity> xnox: Oh, it's possible I haven't missed it "for years".  It was probably right in lts-{utopic,vivid,wily,xenial}, but I bet I copied lts-vivid to make the new rolling hwe stuff.
[00:55] <wxl> in general, tsimonq2, i would expect that the answer is you're being impatient.
[00:55] <infinity> xnox: Hahahah.  Nope.  vivid, wily, and xenial all say Vivid. ;)
[00:56] <infinity> tsimonq2: Definitely impatient.
[00:57] <tsimonq2> I'm glad. :P
[00:57]  * xnox kicks off auto testing of s390x with hacked up hwe stack tests. Let's see if they do the right thing or not.
[01:10] <cyphermox> xnox: infinity: am i supposed to run a test (for netboot) with special settings to get the HWE kernel, or are we just looking to see the install completing normally without changes?
[01:11] <xnox> cyphermox, hwe netboot has ./preseed.cfg that sets to install hwe kernel.
[01:11] <cyphermox> good
[01:11] <xnox> cyphermox, so if one boots with that netboot it should all be dandy. I replace preseed.cfg in my install tests, hence i'm checking it's there and then preseeding everything else as well.
[01:18] <infinity> cyphermox: Yeah, what xnox said.  If you use an external preseed, they don't stack, and you need that altmeta line in yours.  If you just boot it raw and step through the menus, it'll DTRT.
[01:19] <xnox> infinity, s390x server is not published to the 16.04.2 tracker =( and my automation tests old ISO
[01:19] <xnox> and in daily stream it's marked as "rebuilding"
[01:19] <infinity> Uh.  Oh.   My facebook is full of memes of him looking down at Trump's tiny hands.
[01:23] <xnox> our PM let Trump grab her by the waist
[01:23] <wxl> ew
[01:24] <infinity> xnox: Fresh build on the way.
[01:24] <xnox> infinity, lovely
[01:24] <xnox> infinity, that means i need to stay up. oh well. it takes about half an hour to spin & publish?
[01:24] <xnox> or is it without livefs build?
[01:25] <infinity> xnox: Fair point, I don't need to rebuild the livefs.
[01:26] <infinity> I do need to kill the source DVD build, though.
[01:26] <xnox> maybe you do need livefs too..... did things move, and when was the last one done?
[01:27] <xnox> (we do use the livefs on s390x for the "no-network" install)
[01:27] <infinity> xnox: The last livefs was built for the failed ISO build.  It's fresh.
[01:33] <infinity> xnox: Built and mirroring now.
[01:35] -queuebot:#ubuntu-release- Builds: Ubuntu Server s390x [Xenial 16.04.2] (20170216.1) has been added
[01:37] <xnox> voila
[01:37] <infinity> cello
[01:37] <xnox> Voilà != Viola, but puns are so ha-ha funny =)
[02:15] <xnox> infinity, if only HMC would use fixed width fonts for descripltions =(
[02:15] <xnox> visually rolling kernel is shorter than default kernel
[02:15] <xnox> but it does look good.
[02:25] <xnox> ..
[02:25] <xnox> infinity, finished testing everything, s390x is good to go.
[02:26] <xnox> good night.
[02:43] <powersj> server amd64, i386, ppc64el look good
[02:43] -queuebot:#ubuntu-release- New source: gnome-recipes (zesty-proposed/primary) [0.12.0-0ubuntu1]
[02:50] <tsimonq2> infinity: How would I go about removing PowerPC Zesty Daily builds other than just disabling them on the tracker?
[02:54] <tsimonq2> infinity: (I mean for Lubuntu)
[02:55]  * tsimonq2 goes to bed, will fix in the morning
[03:11] <infinity> tsimonq2: Pretty sure I already disabled them.  Just need to remove them from the tracker.
[03:12] <cyphermox> infinity: on ppc64el should I not be getting kernel 4.8?
[03:13] <infinity> cyphermox: That depends on your menu selections.  Did you ask for the HWE kernel?
[03:13] <cyphermox> no, I did not
[03:13] <infinity> cyphermox: Are you talking ISO, or netboot?
[03:13] <cyphermox> I don't recall seeing a prompt for it
[03:13] <cyphermox> netboot
[03:13] <infinity> There are two netboots.
[03:13] <cyphermox> ah, that will explain it
[03:14] <infinity> Which reminds me, I should update cdimage/netboot to expose the HWE builds.
[03:14] <infinity> http://ports.ubuntu.com/ubuntu-ports/dists/xenial-updates/main/installer-ppc64el/current/images/
[03:14] <infinity> You'll see hwe-* variants there.
[03:15] <cyphermox> yeah, I knew where to look
[03:15] <cyphermox> just didn't realize I had to look.
[03:15] <cyphermox> might as well kill this running amd64 test then
[05:12] -queuebot:#ubuntu-release- New binary: rmlint [amd64] (zesty-proposed/universe) [2.4.6-1] (no packageset)
[05:12] -queuebot:#ubuntu-release- New binary: rmlint [i386] (zesty-proposed/universe) [2.4.6-1] (no packageset)
[05:13] -queuebot:#ubuntu-release- New binary: golang-github-docker-libnetwork [i386] (zesty-proposed/universe) [0.8.0~dev.2+git20161130.568.fd27f22-2] (no packageset)
[05:13] -queuebot:#ubuntu-release- New binary: rmlint [ppc64el] (zesty-proposed/universe) [2.4.6-1] (no packageset)
[05:14] -queuebot:#ubuntu-release- New binary: golang-github-docker-libnetwork [amd64] (zesty-proposed/universe) [0.8.0~dev.2+git20161130.568.fd27f22-2] (no packageset)
[05:14] -queuebot:#ubuntu-release- New binary: rmlint [arm64] (zesty-proposed/universe) [2.4.6-1] (no packageset)
[05:14] -queuebot:#ubuntu-release- New binary: golang-github-docker-libnetwork [ppc64el] (zesty-proposed/universe) [0.8.0~dev.2+git20161130.568.fd27f22-2] (no packageset)
[05:14] -queuebot:#ubuntu-release- New binary: rmlint [s390x] (zesty-proposed/universe) [2.4.6-1] (no packageset)
[05:15] -queuebot:#ubuntu-release- New binary: rmlint [armhf] (zesty-proposed/universe) [2.4.6-1] (no packageset)
[05:15] -queuebot:#ubuntu-release- New binary: rmlint [powerpc] (zesty-proposed/universe) [2.4.6-1] (no packageset)
[05:17] -queuebot:#ubuntu-release- New binary: golang-github-docker-libnetwork [arm64] (zesty-proposed/universe) [0.8.0~dev.2+git20161130.568.fd27f22-2] (no packageset)
[05:17] -queuebot:#ubuntu-release- New binary: golang-github-docker-libnetwork [armhf] (zesty-proposed/universe) [0.8.0~dev.2+git20161130.568.fd27f22-2] (no packageset)
[07:22] -queuebot:#ubuntu-release- New: accepted golang-github-docker-libnetwork [amd64] (zesty-proposed) [0.8.0~dev.2+git20161130.568.fd27f22-2]
[07:22] -queuebot:#ubuntu-release- New: accepted golang-github-docker-libnetwork [armhf] (zesty-proposed) [0.8.0~dev.2+git20161130.568.fd27f22-2]
[07:22] -queuebot:#ubuntu-release- New: accepted golang-github-docker-libnetwork [ppc64el] (zesty-proposed) [0.8.0~dev.2+git20161130.568.fd27f22-2]
[07:22] -queuebot:#ubuntu-release- New: accepted py-isort-el [amd64] (zesty-proposed) [2016.1-1]
[07:22] -queuebot:#ubuntu-release- New: accepted rmlint [arm64] (zesty-proposed) [2.4.6-1]
[07:22] -queuebot:#ubuntu-release- New: accepted rmlint [i386] (zesty-proposed) [2.4.6-1]
[07:22] -queuebot:#ubuntu-release- New: accepted rmlint [ppc64el] (zesty-proposed) [2.4.6-1]
[07:22] -queuebot:#ubuntu-release- New: accepted golang-github-docker-libnetwork [arm64] (zesty-proposed) [0.8.0~dev.2+git20161130.568.fd27f22-2]
[07:22] -queuebot:#ubuntu-release- New: accepted ht-el [amd64] (zesty-proposed) [2.1-1]
[07:22] -queuebot:#ubuntu-release- New: accepted rmlint [armhf] (zesty-proposed) [2.4.6-1]
[07:22] -queuebot:#ubuntu-release- New: accepted rmlint [s390x] (zesty-proposed) [2.4.6-1]
[07:22] -queuebot:#ubuntu-release- New: accepted golang-github-docker-libnetwork [i386] (zesty-proposed) [0.8.0~dev.2+git20161130.568.fd27f22-2]
[07:22] -queuebot:#ubuntu-release- New: accepted rmlint [powerpc] (zesty-proposed) [2.4.6-1]
[07:22] -queuebot:#ubuntu-release- New: accepted rmlint [amd64] (zesty-proposed) [2.4.6-1]
[07:57] -queuebot:#ubuntu-release- Builds: Xubuntu Desktop amd64 [Xenial 16.04.2] has been marked as ready
[07:57] -queuebot:#ubuntu-release- Builds: Xubuntu Desktop i386 [Xenial 16.04.2] has been marked as ready
[08:55] -queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop amd64 [Xenial 16.04.2] has been marked as ready
[08:55] -queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop i386 [Xenial 16.04.2] has been marked as ready
[09:33] -queuebot:#ubuntu-release- New binary: zfs-linux [i386] (zesty-proposed/main) [<IP_ADDRESS>-2] (core)
[09:34] -queuebot:#ubuntu-release- New binary: zfs-linux [ppc64el] (zesty-proposed/main) [<IP_ADDRESS>-2] (core)
[09:34] -queuebot:#ubuntu-release- New binary: zfs-linux [s390x] (zesty-proposed/main) [<IP_ADDRESS>-2] (core)
[09:37] -queuebot:#ubuntu-release- New binary: zfs-linux [amd64] (zesty-proposed/main) [<IP_ADDRESS>-2] (core)
[09:37] -queuebot:#ubuntu-release- New binary: zfs-linux [powerpc] (zesty-proposed/main) [<IP_ADDRESS>-2] (core)
[09:37] -queuebot:#ubuntu-release- New binary: zfs-linux [arm64] (zesty-proposed/main) [<IP_ADDRESS>-2] (core)
[09:38] -queuebot:#ubuntu-release- New binary: zfs-linux [armhf] (zesty-proposed/main) [<IP_ADDRESS>-2] (core)
[09:45] <Odd_Bloke> slangasek: Ah, OK; I see they have gone through now, thanks!  Is there something I should have done to avoid the empty .changes file?
[09:59] -queuebot:#ubuntu-release- New binary: gjs [i386] (zesty-proposed/universe) [1.47.90-0ubuntu1] (desktop-extra, mozilla, ubuntugnome)
[09:59] -queuebot:#ubuntu-release- New binary: gjs [ppc64el] (zesty-proposed/universe) [1.47.90-0ubuntu1] (desktop-extra, mozilla, ubuntugnome)
[10:00] -queuebot:#ubuntu-release- New binary: gjs [amd64] (zesty-proposed/universe) [1.47.90-0ubuntu1] (desktop-extra, mozilla, ubuntugnome)
[10:01] -queuebot:#ubuntu-release- New binary: gjs [powerpc] (zesty-proposed/universe) [1.47.90-0ubuntu1] (desktop-extra, mozilla, ubuntugnome)
[10:02] -queuebot:#ubuntu-release- New binary: gjs [armhf] (zesty-proposed/universe) [1.47.90-0ubuntu1] (desktop-extra, mozilla, ubuntugnome)
[10:02] -queuebot:#ubuntu-release- New binary: gjs [s390x] (zesty-proposed/universe) [1.47.90-0ubuntu1] (desktop-extra, mozilla, ubuntugnome)
[10:03] -queuebot:#ubuntu-release- New binary: gjs [arm64] (zesty-proposed/universe) [1.47.90-0ubuntu1] (desktop-extra, mozilla, ubuntugnome)
[10:17] -queuebot:#ubuntu-release- New binary: k3b [ppc64el] (zesty-proposed/universe) [2.0.3a+git20170215-0ubuntu1] (kubuntu)
[10:21] -queuebot:#ubuntu-release- New binary: k3b [amd64] (zesty-proposed/universe) [2.0.3a+git20170215-0ubuntu1] (kubuntu)
[10:21] -queuebot:#ubuntu-release- New binary: k3b [s390x] (zesty-proposed/universe) [2.0.3a+git20170215-0ubuntu1] (kubuntu)
[10:24] -queuebot:#ubuntu-release- New binary: k3b [powerpc] (zesty-proposed/universe) [2.0.3a+git20170215-0ubuntu1] (kubuntu)
[10:24] -queuebot:#ubuntu-release- New binary: mutter [ppc64el] (zesty-proposed/universe) [3.23.90-0ubuntu1] (desktop-extra, edubuntu, ubuntugnome)
[10:25] -queuebot:#ubuntu-release- New binary: mutter [amd64] (zesty-proposed/universe) [3.23.90-0ubuntu1] (desktop-extra, edubuntu, ubuntugnome)
[10:26] -queuebot:#ubuntu-release- New binary: k3b [i386] (zesty-proposed/universe) [2.0.3a+git20170215-0ubuntu1] (kubuntu)
[10:27] -queuebot:#ubuntu-release- New binary: mutter [s390x] (zesty-proposed/universe) [3.23.90-0ubuntu1] (desktop-extra, edubuntu, ubuntugnome)
[10:27] -queuebot:#ubuntu-release- New binary: k3b [arm64] (zesty-proposed/universe) [2.0.3a+git20170215-0ubuntu1] (kubuntu)
[10:28] -queuebot:#ubuntu-release- New binary: k3b [armhf] (zesty-proposed/universe) [2.0.3a+git20170215-0ubuntu1] (kubuntu)
[10:28] -queuebot:#ubuntu-release- New binary: mutter [i386] (zesty-proposed/universe) [3.23.90-0ubuntu1] (desktop-extra, edubuntu, ubuntugnome)
[10:29] -queuebot:#ubuntu-release- New binary: mutter [powerpc] (zesty-proposed/universe) [3.23.90-0ubuntu1] (desktop-extra, edubuntu, ubuntugnome)
[10:31] -queuebot:#ubuntu-release- New binary: mutter [arm64] (zesty-proposed/universe) [3.23.90-0ubuntu1] (desktop-extra, edubuntu, ubuntugnome)
[10:31] -queuebot:#ubuntu-release- New binary: mutter [armhf] (zesty-proposed/universe) [3.23.90-0ubuntu1] (desktop-extra, edubuntu, ubuntugnome)
[12:20] -queuebot:#ubuntu-release- New: accepted zfs-linux [amd64] (zesty-proposed) [<IP_ADDRESS>-2]
[12:20] -queuebot:#ubuntu-release- New: accepted zfs-linux [armhf] (zesty-proposed) [<IP_ADDRESS>-2]
[12:20] -queuebot:#ubuntu-release- New: accepted zfs-linux [powerpc] (zesty-proposed) [<IP_ADDRESS>-2]
[12:21] -queuebot:#ubuntu-release- New: accepted zfs-linux [s390x] (zesty-proposed) [<IP_ADDRESS>-2]
[12:21] -queuebot:#ubuntu-release- New: accepted zfs-linux [arm64] (zesty-proposed) [<IP_ADDRESS>-2]
[12:21] -queuebot:#ubuntu-release- New: accepted zfs-linux [ppc64el] (zesty-proposed) [<IP_ADDRESS>-2]
[12:21] -queuebot:#ubuntu-release- New: accepted zfs-linux [i386] (zesty-proposed) [<IP_ADDRESS>-2]
[12:25] -queuebot:#ubuntu-release- New: accepted mutter [amd64] (zesty-proposed) [3.23.90-0ubuntu1]
[12:25] -queuebot:#ubuntu-release- New: accepted mutter [armhf] (zesty-proposed) [3.23.90-0ubuntu1]
[12:25] -queuebot:#ubuntu-release- New: accepted mutter [powerpc] (zesty-proposed) [3.23.90-0ubuntu1]
[12:25] -queuebot:#ubuntu-release- New: accepted mutter [s390x] (zesty-proposed) [3.23.90-0ubuntu1]
[12:26] -queuebot:#ubuntu-release- New: accepted mutter [arm64] (zesty-proposed) [3.23.90-0ubuntu1]
[12:26] -queuebot:#ubuntu-release- New: accepted mutter [ppc64el] (zesty-proposed) [3.23.90-0ubuntu1]
[12:26] -queuebot:#ubuntu-release- New: accepted mutter [i386] (zesty-proposed) [3.23.90-0ubuntu1]
[12:38] <tsimonq2> infinity: Got it, thanks.
[12:54] <Odd_Bloke> bdmurray: Could you accept gce-compute-image-packages in to trusty-updates?  It's verification-done and has been baking for 13 days.
[13:00] -queuebot:#ubuntu-release- New: accepted k3b [amd64] (zesty-proposed) [2.0.3a+git20170215-0ubuntu1]
[13:00] -queuebot:#ubuntu-release- New: accepted k3b [ppc64el] (zesty-proposed) [2.0.3a+git20170215-0ubuntu1]
[13:00] -queuebot:#ubuntu-release- New: accepted k3b [powerpc] (zesty-proposed) [2.0.3a+git20170215-0ubuntu1]
[13:00] -queuebot:#ubuntu-release- New: accepted k3b [s390x] (zesty-proposed) [2.0.3a+git20170215-0ubuntu1]
[13:01] -queuebot:#ubuntu-release- New: accepted k3b [arm64] (zesty-proposed) [2.0.3a+git20170215-0ubuntu1]
[13:01] -queuebot:#ubuntu-release- New: accepted k3b [i386] (zesty-proposed) [2.0.3a+git20170215-0ubuntu1]
[13:01] -queuebot:#ubuntu-release- New: accepted k3b [armhf] (zesty-proposed) [2.0.3a+git20170215-0ubuntu1]
[13:02] -queuebot:#ubuntu-release- New: accepted gjs [amd64] (zesty-proposed) [1.47.90-0ubuntu1]
[13:02] -queuebot:#ubuntu-release- New: accepted gjs [armhf] (zesty-proposed) [1.47.90-0ubuntu1]
[13:02] -queuebot:#ubuntu-release- New: accepted gjs [powerpc] (zesty-proposed) [1.47.90-0ubuntu1]
[13:02] -queuebot:#ubuntu-release- New: accepted gjs [s390x] (zesty-proposed) [1.47.90-0ubuntu1]
[13:02] -queuebot:#ubuntu-release- New: accepted gjs [arm64] (zesty-proposed) [1.47.90-0ubuntu1]
[13:02] -queuebot:#ubuntu-release- New: accepted gjs [ppc64el] (zesty-proposed) [1.47.90-0ubuntu1]
[13:02] -queuebot:#ubuntu-release- New: accepted gjs [i386] (zesty-proposed) [1.47.90-0ubuntu1]
[13:05] -queuebot:#ubuntu-release- Unapproved: libodb-pgsql (xenial-proposed/universe) [2.4.0-1 => 2.4.0-1build0~16.04.1] (no packageset)
[13:06] -queuebot:#ubuntu-release- Unapproved: libodb-pgsql (yakkety-proposed/universe) [2.4.0-1 => 2.4.0-1build0~16.10.1] (no packageset)
[13:12] -queuebot:#ubuntu-release- Unapproved: libodb-qt (xenial-proposed/universe) [2.4.0-2 => 2.4.0-2build0~16.04.1] (no packageset)
[13:13] -queuebot:#ubuntu-release- Unapproved: libodb-qt (yakkety-proposed/universe) [2.4.0-2 => 2.4.0-2build0~16.10.1] (no packageset)
[13:16] -queuebot:#ubuntu-release- Unapproved: libodb-sqlite (xenial-proposed/universe) [2.4.0-1 => 2.4.0-1build0~16.04.1] (no packageset)
[13:16] -queuebot:#ubuntu-release- Unapproved: libodb-sqlite (yakkety-proposed/universe) [2.4.0-1 => 2.4.0-1build0~16.10.1] (no packageset)
[13:22] -queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop amd64 [Xenial 16.04.2] has been marked as ready
[13:22] -queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop i386 [Xenial 16.04.2] has been marked as ready
[13:23] -queuebot:#ubuntu-release- New: accepted nginx [amd64] (zesty-proposed) [1.10.3-0ubuntu2]
[13:23] -queuebot:#ubuntu-release- New: accepted nginx [armhf] (zesty-proposed) [1.10.3-0ubuntu2]
[13:23] -queuebot:#ubuntu-release- New: accepted nginx [powerpc] (zesty-proposed) [1.10.3-0ubuntu2]
[13:23] -queuebot:#ubuntu-release- New: accepted nginx [s390x] (zesty-proposed) [1.10.3-0ubuntu2]
[13:23] -queuebot:#ubuntu-release- New: accepted nginx [arm64] (zesty-proposed) [1.10.3-0ubuntu2]
[13:23] -queuebot:#ubuntu-release- New: accepted nginx [ppc64el] (zesty-proposed) [1.10.3-0ubuntu2]
[13:23] -queuebot:#ubuntu-release- New: accepted nginx [i386] (zesty-proposed) [1.10.3-0ubuntu2]
[13:50] <Sweet5hark> seb128: Sweet5hark, you might want to ask on #ubuntu-release if they can skip the autopkg for that one, explaining that following upload is going to fix things but that we might get the new version in zesty before waiting for another build/infra round
[13:50] <Sweet5hark> ^^ any strong positions on how to play that?
[13:53] <Sweet5hark> talking about libreoffice, which is stuck in autopackage tests due to a missing dep (for the test)
[14:09] <Laney> Sweet5hark: How do we know that these releases are good?
[14:09] <Laney> 5.2.2 at least passed intermittently, but 5.3 never has
[14:10]  * Laney goes to eat
[14:48] -queuebot:#ubuntu-release- Unapproved: accepted ubuntu-image [source] (xenial-proposed) [0.15+16.04ubuntu1]
[14:50] -queuebot:#ubuntu-release- Unapproved: accepted ubuntu-image [source] (yakkety-proposed) [0.15+16.10ubuntu1]
[15:15] <ginggs> would someone please remove the armhf and powerpc binaries for theano?  it no longer builds on these architectures
[15:17] <ginggs> LP: #1646827
[15:17] <ginggs> No reverse dependencies found
[15:34] <santa_> hi
[15:34] <santa_> dear release wizards, I have a question about britney behaviour with autopkgtests
[15:35] <cyphermox> shoot; don't need to ask to ask, just ask ;)
[15:35] <santa_> lets supose we have three source packages
[15:36] <santa_> libfoo, libbar and baz
[15:36] <santa_> libfoo produces the binary packages libfoo-dev and libfoo5
[15:37] <santa_> libbar produces the binary packages libbar-dev and libbar5
[15:37] <santa_> baz produces the binary package bazapp
[15:37] <santa_> libbar-dev depends on libfoo-dev
[15:38] <santa_> src:baz depends on both libfoo-dev and libbar-dev
[15:38] <santa_> so the question is
[15:38] <santa_> if we upload these 3 packages at the same time and they land in proposed...
[15:39] <santa_> does this trigger the autopkgtests of src:baz twice?
[15:39] <infinity> Yes.  And it should.
[15:40] <santa_> so if I remove the libfoo-dev build depend of baz it would be autopkgtested once
[15:40] <cyphermox> the fact that things are uploaded "at the same time" doesn't mean they show up at the same time, for starters, but they are also different libraries which need to be tested independently if you want to identify regressions correctly
[15:41] <cyphermox> if you remove libfoo-dev as a build-depends of baz and baz does need it to build, it's wrong.
[15:41] <infinity> santa_: Build-dependencies aren't the trigger, it's runtime dependencies.  If the binaries depend on both libraries, you'll get tests against each.
[15:41] -queuebot:#ubuntu-release- Builds: Ubuntu Server armhf+raspi2 [Xenial 16.04.2] (20170216.1) has been added
[15:42] <santa_> infinity: so it would be built twice, no matter what I do?
[15:43] <infinity> s/built/tested/
[15:43] <santa_> yeah, tested I meant
[15:43] <infinity> Testing "too much" is never really a bug. :P
[15:43] <santa_> cyphermox: keep in mind that i said that libbar-dev depends on libfoo-dev, hence the question
[15:44] <santa_> infinity: well I had frameworks in mind
[15:45] <santa_> http://gpul.grupos.udc.es/ka-iron-hand_reports/frameworks_archive/5.31_zesty_proposed_migration.pdf
[15:45] <santa_> srlsy
[15:45] <santa_> so I was just pondering about removing "redundant" build dependencies
[15:46] <santa_> but if the zillions of autopkgtests are unavoidable lets get over it XD
[15:46] <infinity> santa_: You may think in terms of frameworks, but proposed-migration thinks in terms of migrating individual packages.  We test each as if we were going to attempt a partial upgrade, then if that can't work, we test with deps in proposed to see if we can migrate in chunks, etc.
[15:48] <infinity> santa_: The point of testing partial upgrades is to make sure your deps are correct.  If newapp works with oldlib (or oldapp works with newlib), we can migrate in smaller sets.  If the combination doesn't work, but you declare it does, there's a bug.  If the combination doesn't work, and you declare it doesn't, there's no bug, they just migrate together.  The way testing works, all this is determined without humans needing to evaluate each ...
[15:48] <infinity> ... situation.
[15:49] <Laney> You'd probably be happier if all of the KDE tests didn't perform a full build
[15:51] <slangasek> Odd_Bloke: building with the -v flag so that all the relevant bits of the changelog were included
[15:51] <Odd_Bloke> slangasek: Ah, `-v <version in -updates>`?
[15:51] <slangasek> yes
[15:51] <Odd_Bloke> Right, will endeavour to remember that next time.
[16:00] <infinity> I've thought a few times about an extension to dpkg-genchanges (disabled by default, probably, because ew slow external network ickiness) that would check rmadison for you and apply the appropriate -v.
[16:02] <ginggs> cyphermox: hi, are you aware of http://autopkgtest.ubuntu.com/packages/d/devscripts/zesty/s390x ?
[16:02] <infinity> I am.
[16:04] <ginggs> infinity: o/ would you respond to my mail sometime please?
[16:05] <cyphermox> err?
[16:06] <infinity> cyphermox: I assume he's poking you because you're the last uploader. :P
[16:06] <cyphermox> yeah, i figured
[16:06] <cyphermox> just don't know what that error is
[16:06] <infinity> ginggs: The s390x devscripts thing isn't a devscripts bug, it's infrastructure.
[16:06] <infinity> cyphermox: ^
[16:06] <cyphermox> I had figured as much too; I had a similar issue building locally
[16:06] <cyphermox> well
[16:07] <cyphermox> aside from the obvious fr_CA <> C
[16:08] <cyphermox> it might not be the same thing, but it looked like an issue due to some changes in gpg2?
[16:11] <infinity> cyphermox: It's a curious interaction between gpg2 and containers.
[16:11] <infinity> It's a bug, to be sure, but not a bug in devscripts. :P
[16:11] <cyphermox> right
[16:16] <ginggs> weird that it's ok on armhf
[16:17] <ginggs> infinity: thanks for the theano removal - just got the mail now
[16:42] <cyphermox> anyone else unable to boot the xenial armhf+raspi2 preinstalled server image?
[17:24] <dannf> infinity: fyi, i see server isos in the tracker now, but looks like arm64 has no download link (others do)
[17:25] <infinity> dannf: It also has no testcases, so whee.
[17:25] <infinity> dannf: http://cdimage.ubuntu.com/ubuntu-server/xenial/daily/20170216.1/
[17:25] <dannf> ah, then it can never fail! my job here is done.
[17:25] <dannf> thx
[17:25] <infinity> dannf: Give them a spin and lemme know what's what.
[17:26] -queuebot:#ubuntu-release- Unapproved: livecd-rootfs (xenial-proposed/main) [2.408.7 => 2.408.8] (desktop-core)
[17:26] <infinity> apw: ^-- Yo, pls accept blindly.
[17:29] <dmj_s76> infinity: Is the release still scheduled for today?
[17:30] <infinity> dmj_s76: Yes.
[17:32] -queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (xenial-proposed) [2.408.8]
[17:33] <Laney> Pheature Phreeze
[17:41] <sergiusens> bdmurray: slangasek can I get snapacraft into xenial-updates and yakkety-updates? armhf is failing on network timeouts and I was hoping to get a pass on those
[17:46] -queuebot:#ubuntu-release- Builds: Ubuntu GNOME Desktop amd64 [Xenial 16.04.2] has been marked as ready
[17:46] -queuebot:#ubuntu-release- Builds: Ubuntu GNOME Desktop i386 [Xenial 16.04.2] has been marked as ready
[17:48] <infinity> dmj_s76: Of course, if you're looking for some way to be helpful, looks like mythbuntu could use someone to smoketest their new images and make sure I didn't break them with the respin.
[17:54] <tsimonq2> infinity: Just curious, ETA on Feature Freeze?
[17:56] -queuebot:#ubuntu-release- Unapproved: snapd (xenial-updates/main) [2.22.2 => 2.21] (desktop-core, ubuntu-server) (sync)
[17:57] <Laney> I'll email about it in a bit
[17:58] <infinity> tsimonq2: When Laney sends an email, apparently.
[17:59] <Laney> Need to remember how to work svn first
[17:59] <Laney> Not to send the email
[17:59] <Laney> Although that would be quite a fun contraption
[18:01] -queuebot:#ubuntu-release- Unapproved: rejected snapd [sync] (xenial-updates) [2.21]
[18:12] <tsimonq2> Laney: hehehehehe +1
[18:12] <tsimonq2> infinity: Ok, thanks.
[18:13] <tsimonq2> Laney: What evil abomination still uses SVN? :P
[18:13] <Laney> pkg-gnome
[18:13] <infinity> Lots of things do.
[18:13] <tsimonq2> Grrr :P
[18:14] <Laney> It was actually painless in the end
[18:15] <tsimonq2> I ironically added SVN support to Snapcraft :P
[18:29] <sergiusens> bdmurray: slangasek correction, only yakkety has the timeout, I retriggered in the meantime but it has ben painful as of late
[18:30] <adamantium> so, will there be the 16.04.2 iso? delayed 4th or 5th time?
[18:32] <adamantium> thanks in advance on any info on 16.04.2 iso.
[18:35] <infinity> adamantium: There will be.
[18:37] <adamantium> infinity: today?
[18:37] <infinity> adamantium: Yes.
[18:37] <adamantium> infinity: thank you
[18:46] -queuebot:#ubuntu-release- New binary: nut [i386] (zesty-proposed/main) [2.7.4-5ubuntu1] (ubuntu-server)
[18:46] -queuebot:#ubuntu-release- New binary: nut [s390x] (zesty-proposed/main) [2.7.4-5ubuntu1] (ubuntu-server)
[18:46] <wxl> infinity: you got an eta for shipping 16.04.2?
[18:47] <infinity> wxl: Today.
[18:47] <infinity> wxl: (Probably late afternoon or early evening my time)
[18:47] <infinity> "My time" being UTC-7
[18:48] <wxl> great thanks :)
[18:48] -queuebot:#ubuntu-release- New binary: nut [amd64] (zesty-proposed/main) [2.7.4-5ubuntu1] (ubuntu-server)
[18:48] <dannf> infinity: arm64 installs w/ both kernels worked w/ no issue. will try to get a test case added - https://code.launchpad.net/~dannf/ubuntu-manual-tests/arm64-server-kvm/+merge/317539
[18:48] <infinity> dannf: stgraber added test cases.
[18:49] <infinity> dannf: Refresh the page.
[18:49] -queuebot:#ubuntu-release- New binary: nut [arm64] (zesty-proposed/main) [2.7.4-5ubuntu1] (ubuntu-server)
[18:49] -queuebot:#ubuntu-release- New binary: nut [powerpc] (zesty-proposed/main) [2.7.4-5ubuntu1] (ubuntu-server)
[18:49] -queuebot:#ubuntu-release- New binary: nut [armhf] (zesty-proposed/main) [2.7.4-5ubuntu1] (ubuntu-server)
[18:49] <infinity> dannf: They might be crap test cases, so feel free to still propose changes, but should be good enough for you to report some pass/fail and give me green text. :)
[18:50] <dannf> infinity: ack
[18:53] <flocculant> dannf: your test case is completely different than the one st graber used - I can just get that sorted now if it helps
[18:55] <dannf> flocculant: it overlaps. i used qemu as the host to run his tests
[18:55] <flocculant> yes I saw
[18:56] <flocculant> well - read the mp - makes no difference to me - I can deal with that now if it helps
[18:56] <dannf> flocculant: thanks! i don't think there's a rush, i've already ran it on 16.04.2 and it passed, but would be nice to have it there for the next release
[18:57] <flocculant> dannf: ok - leave it with me and I'll get that done this week :)
[19:25] <cyphermox> robru: so for transgui, looks like the issue on ppc64el is that fpc never got built for that arch, and building it depends on fp-utils which itself is built from fpc -- so either we need to get that bootstrapped somehow, or fp-utils isn't really required to build fpc.
[19:26] <infinity> It needs bootstrapping.
[19:26] <cyphermox> right
[19:27] <infinity> Except it's not on ppc64el in unstable either, so it might just not be supported.
[19:27] <ginggs> fpc needs porting for ppc64el first
[19:27] <cyphermox> robru: I say move to another package.
[19:27] <ginggs> shouldn't be a big job ppc64 works
[19:28] <robru> alright
[19:30] <cyphermox> robru: I suggest pcsc-lite or maybe fbset?
[19:32] <cyphermox> oh, and I saw licensecheck too you could look at
[19:39] <jbicha> bdmurray: is there a reason you accepted the nm packages for yakkety but not xenial? bug 1619354 bug 1645698
[19:42] <cyphermox> robru: dub looks fun, too; it's D but you probably don't need to know D
[19:44] <cyphermox> robru: I suggest you mention it here if you're looking at some package in particular from excuses/FTBFS/whatnot so that if someone else is about to look at it, we don't duplicate work
[19:44] -queuebot:#ubuntu-release- Unapproved: accepted cups [source] (yakkety-proposed) [2.2.0-2ubuntu0.1]
[19:44] <robru> cyphermox: yeah I was wondering how people know not to duplicate work
[19:45] <cyphermox> we used to have a channel just for it, but there aren't many people working in this stuff -- might as well just say it here
[19:45] <infinity> robru: As a general rule, people doing +1 type stuff are not a large army, so duplication doesn't really happen.  When we had people actively tasked with doing it, we coordinated on IRC.
[19:45] <infinity> (I'd argue that the discussion belongs in #ubuntu-devel, though, not here)
[19:46] <cyphermox> heh
[19:46] <jbicha> yes, #ubuntu-devel please :)
[19:46] <cyphermox> either works
[19:47] <robru> two against one, it seems ;-)
[19:48] <bdmurray> jbicha: I don't know but looking at it now there's an improper bug reference in the changelog.  "Add patches showing wwan options after logout/in (LP: #165019)"
[19:50] <bdmurray> bug 1651019
[19:50] <bdmurray> jbicha: it's supposed to be that one if you want to fix it
[19:54] <jgrimm> infinity, for 16.04.2 release notes.. planning to call out that we are now  'ISO size > max CD media size' because of additional kernel?
[19:55] -queuebot:#ubuntu-release- Unapproved: accepted spyder [source] (yakkety-proposed) [3.0.2+dfsg1-0ubuntu0.2]
[19:55] <infinity> jgrimm: I wasn't deeply concerned about it, TBH, but if you feel the urge, the release notes are a wiki.
[19:56] -queuebot:#ubuntu-release- Unapproved: network-manager-applet (xenial-proposed/main) [1.2.0-0ubuntu<IP_ADDRESS> => 1.2.6-0ubuntu<IP_ADDRESS>] (kubuntu, ubuntu-desktop)
[19:56] <infinity> jgrimm: I might be wrong, but I suspect the number of people who install servers from actual physical CDs are a very tiny minority.
[19:56] <jgrimm> infinity, cool. yeah i think worth mentioning as its been something we've made reasonable attempts to keep it to size up till now
[19:56] <jgrimm> infinity, totally agree.. i don't think its really a big deal either, just being transparent
[19:56] <infinity> jgrimm: Certainly, most larger deployments use some netboot/maas/cobbler/etc strategy, and one-offs are usually USB sticks, or if optical is all they have, a DVD drive if they're from this century.
[19:57] <jgrimm> infinity, agree 100%
[19:57] <infinity> jgrimm: But go forth and document.
[19:57] <jgrimm> thanks sir
[19:57] <jgrimm> powersj, ^^
[19:57] <powersj> ok, shall I put my note there?
[19:57] <jbicha> bdmurray: fixed; you're able to process new packages into stable releases, right?
[19:57] <infinity> Oh, we didn't copy .1 notes out to .1 yet.  Should do that before people start editing.
[19:58] <infinity> cyphermox: I thought you did that?  I guess not? :P
[19:58] <cyphermox> Changes summary yes
[19:58] <cyphermox> which i need to update again now
[19:58] <jgrimm> powersj, yup and ask for the ISO size test to be updated too
[19:58] <infinity> Ahh.
[19:58] -queuebot:#ubuntu-release- Unapproved: accepted gtk+3.0 [source] (yakkety-proposed) [3.20.9-1ubuntu2.1]
[19:58] <bdmurray> jbicha: I think so
[19:58] <powersj> jgrimm: ok
[19:58] <cyphermox> I can copy stuff too
[19:58] <powersj> thx
[19:59] <bdmurray> cyphermox: just copy or copy and paste?
[19:59] <cyphermox> whatever will work, + replacing .1 with .2.
[19:59] <infinity> Okay, 16.04.1 notes are archived.
[19:59] <jbicha> bdmurray: bug 1652537 is high priority (chrome-gnome-shell for trusty and xenial), but I'm interested in bug 1649330 and bug 1656712 also (bubblewrap, ostree, flatpak > xenial)
[20:02] <infinity> jgrimm: Okay, https://wiki.ubuntu.com/XenialXerus/ReleaseNotes is for 16.04.2 now.  Feel free to peruse, remove stuff that you don't think is relevant, add you ISO size bit, whatever.  Enjoy.
[20:02] <jgrimm> infinity, ack. and thanks!
[20:04] -queuebot:#ubuntu-release- Unapproved: accepted wine-development [source] (yakkety-proposed) [1.9.20-1ubuntu2]
[20:05] <cyphermox> infinity: do you know which was the last included USN?
[20:05] <infinity> cyphermox: Lemme do some timezone math.
[20:05] <cyphermox> checking to see if it was https://www.ubuntu.com/usn/usn-3197-1/
[20:07] <infinity> cyphermox: Looks like libgc.
[20:07] <slangasek> robru, Laney: what's the story with autopkgtests now returning 'blacklisted' as a result and causing proposed-migration stalls?
[20:08] -queuebot:#ubuntu-release- Unapproved: accepted wine [source] (yakkety-proposed) [1.8.5-1ubuntu2]
[20:08] <infinity> cyphermox: Which also gives you a reasonable SRU cutoff, based on libgc's position on https://lists.ubuntu.com/archives/xenial-changes/2017-February/thread.html
[20:09] <robru> slangasek: first I'm hearing of this. example?
[20:09] -queuebot:#ubuntu-release- Unapproved: accepted wine-development [source] (xenial-proposed) [1.9.6-1ubuntu1]
[20:09] <slangasek> robru: upstart/blacklisted; linux/blacklisted in output for systemd
[20:10] <robru> slangasek: no idea
[20:10] <cyphermox> infinity: agreed. done.
[20:10] <slangasek> robru: right, so someone else made the change on the autopkgtest end apparently, without coordinating ;)  hopefully Laney knows something
[20:11] <cyphermox> infinity: are you still updating release notes? I see some thing wrong.
[20:11] <infinity> slangasek: What's your proof that the change in UI is also what's stalling things?
[20:11] <cyphermox> (for one, the kernel version may be misleading)
[20:11] <infinity> slangasek: (systemd has other failing tests)
[20:11] <robru> slangasek: Laney appears responsible: https://bugs.launchpad.net/auto-package-testing/+bug/1579090
[20:11] <infinity> cyphermox: I'm not updating them currently.
[20:12] -queuebot:#ubuntu-release- Unapproved: accepted wine1.6 [source] (xenial-proposed) [1:1.6.2-0ubuntu14.1]
[20:12] <slangasek> infinity: update_excuses lists it as 'regression'.  If they're *not* blocking, then someone has a very funny idea of how the UI should look.
[20:13] <robru> slangasek: all the examples of "blacklisted" that I'm seeing in excuses also say "ignored failure". what are you seeing that's actually a problem?
[20:13] <infinity> autopkgtest for upstart/blacklisted: amd64: Regression ♻ , i386: Regression ♻ , ppc64el: Regression ♻
[20:14] <slangasek> robru: erm, http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#systemd ?
[20:14] <infinity> That would be his example.
[20:14] <robru> oh I was looking at the one specifically for zesty
[20:14] <infinity> I think it's fair to show the test is regressed, but also being ignored.
[20:14] <slangasek> that one is for zesty
[20:14] <infinity> I disagree that "blacklisted" is the best term.
[20:14] <infinity> ignored would be clearer.
[20:15] <slangasek> infinity: which is language we already use elsewhere, so saying it's a "regression" when in fact there was no test run is pointless
[20:15] <infinity> Err, wait.  What does "blacklisted" mean?
[20:15] <infinity> It's not the same as ignored, is it?
[20:15] <infinity> Is this a new thing? :P
[20:15] <slangasek> that was my question
[20:15] <infinity> Cause I see "Ignored fialure" elsewhere.
[20:16] <infinity> So confusing.
[20:16] <slangasek> then you started defending it, so I was about to demand why you had knowledge of this that wasn't shared :-P
[20:16] <infinity> Hah.  Yeah.  I assumed people had wiggled ignored around to be this.
[20:16] <slangasek> "ignored failure" means we've overridden it with hints. "blacklisted" apparently means someone blacklisted the package on the autopkgtest end
[20:16] <infinity> Oh, right.
[20:16] <robru> rather I was looking at a stale copy that didn't have this problem
[20:16] <infinity> That fits with what I'm seeing here.
[20:16] <infinity> Cause linux/i386 is indeed blacklisted, due to murdering testbeds.
[20:17] <infinity> So maybe it should also list the result as "ignored failure", I agree there.
[20:17] <slangasek> there happens to be a test in the britney2 source to make sure 'blacklisted' is shown correctly
[20:17] <infinity> Hard to tell without looking at code if it's actually hurting promotions, though, since there are other legit failed tests in that set.
[20:17] <slangasek> but I don't see any actual code in britney to handle it specially
[20:18] <slangasek> I've looked at the code, and there's nothing else in here that I see treating it as a "special" regression
[20:18] -queuebot:#ubuntu-release- Builds: Ubuntu Server armhf+raspi2 [Xenial 16.04.2] has been updated (20170216.2)
[20:19] <infinity> cyphermox: ^-- New one to test with Paolo's changes.
[20:19] <infinity> Well, my changes implementing Paolo's suggestion.
[20:19] <cyphermox> weee
[20:19] <slangasek> furthermore, "maybe someone introduced two countervailing bugs instead of just the one you see and know about" is not a comforting response
[20:19] <infinity> Heh.
[20:20] <infinity> Right, definitely a UI bug, maybe a behaviour bug (yuor reading of the code would imply so)
[20:20] <infinity> Well, not a behaviour regression, though.
[20:20] <infinity> We already had to hint blacklisted stuff.
[20:20] <infinity> But if we're going to the bother of mentioning it on excuses, we shouldn't block on it either.
[20:21] <slangasek> yes, I think it's listed on excuses only because it shows up as an autopkgtest result with 'blacklisted' as the version number, e.g. http://autopkgtest.ubuntu.com/packages/u/upstart/zesty/amd64
[20:21] <infinity> I like that upstart is now blacklisted on more arches than it's not.
[20:21] <slangasek> so where does this blacklist happen?  this is the first I've heard of it
[20:21] <infinity> Somewhere in the bit of autopkgtest I haven't learned about yet.
[20:22] <infinity> Was that helpful? ;)
[20:22] -queuebot:#ubuntu-release- Unapproved: accepted gnome-software [source] (yakkety-proposed) [3.20.1+git20170208.0.a34b091-0ubuntu1]
[20:22] <slangasek> barry: you got some autopkgtest training, didn't you?
[20:23] <slangasek> ah apparently it's swiftly answered just by looking at the production branch checkout
[20:24] <slangasek> it's in worker-config-production/worker.conf, which is owned by ~ubuntu-release, so people could at least be updating that and hints files simultaneously
[20:25] -queuebot:#ubuntu-release- Unapproved: accepted gnome-software [source] (xenial-proposed) [3.20.1+git20170208.0.a34b091-0ubuntu1~xenial1]
[20:25] <infinity> slangasek: Yeah, but if britney can divine that something is blacklisted, hinting it twice is a colossal waste of time, so I'm all for making it a bit smarter.
[20:26] <infinity> (Waste of time and error-prone)
[20:26] <slangasek> infinity: yes. but in the meantime, britney's not doing that, so people shouldn't blacklist without also updating hints
[20:26] <infinity> Fair point.
[20:26] <infinity> upstart is hinted.
[20:27] <infinity> linux could use an /i386 hint for now.
[20:28] <slangasek> where do you see this upstart hint?  I only see one for upstart/1.13.2-0ubuntu35
[20:28] <infinity> slangasek: Which is the current version.
[20:29] <slangasek> yes, which is not the version that autopkgtest is reporting results for
[20:29] <slangasek> it reports results for blacklisted as a *version*
[20:29] <infinity> Oh, I see the hilarity there.
[20:29] <infinity> Right, that's special.
[20:29] <infinity> Maybe a hint for all/blacklisted/all would work? :)
[20:29] <infinity> (using the package/version/arch spec)
[20:29] <slangasek> probably not, but I'm syncing the list of all currently blacklisted packages
[20:30] <infinity> It might work.  Britney does have a concept of "all" as a package hint key.
[20:31] <infinity> (Think "block all")
[20:31] <slangasek> maybe. anyway, trying this for now
[20:43] -queuebot:#ubuntu-release- Unapproved: accepted cups [source] (xenial-proposed) [2.1.3-4ubuntu0.2]
[20:46] <slangasek> and the systemd/armhf test suite regression, which I can't reproduce on the porter box, seems to be an actual regression. Sigh.
[21:00]  * tsimonq2 rings a large bell
[21:01] <tsimonq2> 21 UTC ;)
[21:01] -queuebot:#ubuntu-release- Unapproved: accepted strongswan [source] (xenial-proposed) [5.3.5-1ubuntu3.1]
[21:02]  * acheronuk watches the FF portcullis of doom descend
[21:02] <tsimonq2> ^
[21:04] <tsimonq2> Darkness and clouds... :P
[21:04] <Bashing-om> tsimonq2: Not looking good for the home team ?
[21:06] <tsimonq2> Soo Laney or infinity or slangasek, Has It Begun yet? :P
[21:06] <tsimonq2> Bashing-om: Give or take :P
[21:07] <infinity> tsimonq2: It began 13 years ago.
[21:07] <wxl> infinity: what are you talking about? i thought tsimonq2 was 15 XD
[21:09] <tsimonq2> wxl: Noo I'm 14 but I turn 15 on 3/11 :P
[21:09] -queuebot:#ubuntu-release- Builds: Ubuntu Studio DVD amd64 [Xenial 16.04.2] has been marked as ready
[21:09] -queuebot:#ubuntu-release- Builds: Ubuntu Studio DVD i386 [Xenial 16.04.2] has been marked as ready
[21:09] <tsimonq2> infinity: I mean Feature Freeze :P
[21:10] <infinity> tsimonq2: According to the topic and your INBOX, yes.
[21:11] <infinity> yofel: Happy with marking Kubuntu ready?
[21:11] <infinity> wxl / tsimonq2: Ditto for lubuntu?
[21:11] <tsimonq2> infinity: wxl is Kubuntu guy now :P
[21:11] <infinity> Err, that's not confusing.
[21:12] <wxl> yeah well
[21:12] <acheronuk> confuses me
[21:12] <wxl> i'm filling in
[21:12] <tsimonq2> infinity: Ping wxl for Kubuntu and me for Lubuntu
[21:12] <wxl> we're almost there but not quite yet, infinity. another 30 mins or so?
[21:12] <infinity> Sure.
[21:15] <tsimonq2> infinity: Lubuntu is good to go. wxl is the one who calls Kubuntu. :P
[21:16] <wxl> tsimonq2: you need me to mark lubuntu ready for you?
[21:17] <teward> bdmurray: poke.  You can blame Perl for the holdup on -proposed -> zesty.
[21:17] <teward> for the SRU, but i'm not as worried about the SRU as I am getting the final merge from Debian in :P
[21:17] <tsimonq2> wxl: I can in a sec
[21:17] <teward> (for nginx, for context)
[21:18] <wxl> tsimonq2: well i'm looking at the tracker if you want me to
[21:18] <tsimonq2> wxl: Sure actually
[21:18] -queuebot:#ubuntu-release- Builds: Kubuntu Desktop amd64 [Xenial 16.04.2] has been marked as ready
[21:18] <wxl> done
[21:19] -queuebot:#ubuntu-release- Builds: Lubuntu Desktop amd64 [Xenial 16.04.2] has been marked as ready
[21:19] -queuebot:#ubuntu-release- Builds: Lubuntu Desktop i386 [Xenial 16.04.2] has been marked as ready
[21:26] -queuebot:#ubuntu-release- Builds: Ubuntu Base amd64 [Xenial 16.04.2] has been marked as ready
[21:26] -queuebot:#ubuntu-release- Builds: Ubuntu Base arm64 [Xenial 16.04.2] has been marked as ready
[21:26] -queuebot:#ubuntu-release- Builds: Ubuntu Base armhf [Xenial 16.04.2] has been marked as ready
[21:26] -queuebot:#ubuntu-release- Builds: Ubuntu Base i386 [Xenial 16.04.2] has been marked as ready
[21:26] -queuebot:#ubuntu-release- Builds: Ubuntu Base powerpc [Xenial 16.04.2] has been marked as ready
[21:26] -queuebot:#ubuntu-release- Builds: Ubuntu Base ppc64el [Xenial 16.04.2] has been marked as ready
[21:26] -queuebot:#ubuntu-release- Builds: Ubuntu Base s390x [Xenial 16.04.2] has been marked as ready
[21:41] <slangasek> well, I wonder if this 'force-badtest linux/blacklisted' is dtrt.  It kinda looks like it's forcing tests that /do/ have version numbers to be ignored.
[21:41] <sergiusens> slangasek: bdmurray thanks for releasing snapcraft to yakkety-updates, any reason why xenial-updates is still missing? (which has no test rergressions even)
[21:42] <slangasek> sergiusens: because I was distracted in the middle of releasing them, and was reminded to do the other release when I saw you pop back up on IRC ;)
[21:43] <slangasek> (so, done before you asked)
[22:09] <sergiusens> hah, well thank you very much!
[22:16] <slangasek> barry: the systemd bits of LP: #1647031 have landed now in zesty; can you take care of reverting the NM revert?
[22:16] <barry> slangasek: i just saw that and was gonna ask you about it :)
[22:16] <slangasek> :)
[22:17] <barry> so... yep
[22:17] <tsimonq2> I just saw that too ;)
[22:18]  * infinity murders poor nusakan's SAN.
[22:19] <slangasek> poor nusakansan
[22:19] <tsimonq2> infinity: SAN?
[22:19] <barry> you nuked nusakan?
[22:20] <slangasek> the noose tightens
[22:22] -queuebot:#ubuntu-release- Unapproved: pciutils (xenial-proposed/main) [1:3.3.1-1.1ubuntu1 => 1:3.3.1-1.1ubuntu1.1] (core)
[22:24] -queuebot:#ubuntu-release- Unapproved: pciutils (yakkety-proposed/main) [1:3.3.1-1.1ubuntu4 => 1:3.3.1-1.1ubuntu4.1] (core)
[22:25] <infinity> tsimonq2: http://lmgtfy.com/?q=SAN
[22:25] <tsimonq2> infinity: Oh for pete's sake :P
[22:26] <tsimonq2> infinity: But what if I use DuckDuckGo?
[22:26] <wxl> !kick tsimonq2
[22:26] <tsimonq2> wxl: hahahahaha :P
[22:26] <jbicha> barry: you want to merge https://code.launchpad.net/~jbicha/network-manager/+git/network-manager/+merge/317560
[22:27] <infinity> tsimonq2: http://lmgtfy.com/?s=d&q=SAN
[22:27] <jbicha> I have upload rights but not git commit rights; happyaron is the opposite
[22:27] <barry> jbicha: um, are you sure?  that diff has almost nothing in it
[22:27] <jbicha> well I meant that as a question
[22:28] <jbicha> barry: I already uploaded that to zesty hours ago so this is keeping git in sync with the repo
[22:28] <tsimonq2> infinity: Excellent, thank you. :P
[22:30] <barry> jbicha: oh i see.  okay, i can merge and push that to git
[22:52] -queuebot:#ubuntu-release- Builds: Mythbuntu Desktop amd64 [Xenial 16.04.2] has been marked as ready
[22:52] -queuebot:#ubuntu-release- Builds: Mythbuntu Desktop i386 [Xenial 16.04.2] has been marked as ready
[23:27] <roflcopter> 16.04.2 today, huh? , seems like it will never come
[23:28] <Guest40327> 16.04.2 today, huh? , seems like it will never come
[23:33] -queuebot:#ubuntu-release- Unapproved: accepted libodb-boost [source] (yakkety-proposed) [2.4.0-1build0~16.10.1]
[23:34] -queuebot:#ubuntu-release- Unapproved: accepted libodb-pgsql [source] (yakkety-proposed) [2.4.0-1build0~16.10.1]
[23:35] -queuebot:#ubuntu-release- Unapproved: accepted libodb-qt [source] (yakkety-proposed) [2.4.0-2build0~16.10.1]
[23:37] -queuebot:#ubuntu-release- Unapproved: accepted libodb-sqlite [source] (yakkety-proposed) [2.4.0-1build0~16.10.1]
[23:39] -queuebot:#ubuntu-release- Unapproved: accepted libodb-sqlite [source] (xenial-proposed) [2.4.0-1build0~16.04.1]
[23:40] -queuebot:#ubuntu-release- Unapproved: accepted libodb-qt [source] (xenial-proposed) [2.4.0-2build0~16.04.1]
[23:41] -queuebot:#ubuntu-release- Unapproved: accepted libodb-pgsql [source] (xenial-proposed) [2.4.0-1build0~16.04.1]
[23:42] -queuebot:#ubuntu-release- Unapproved: accepted libodb-boost [source] (xenial-proposed) [2.4.0-1build0~16.04.1]
[23:42] -queuebot:#ubuntu-release- Unapproved: rejected network-manager-applet [source] (xenial-proposed) [1.2.6-0ubuntu<IP_ADDRESS>]
[23:58] -queuebot:#ubuntu-release- Unapproved: accepted network-manager-applet [source] (xenial-proposed) [1.2.6-0ubuntu<IP_ADDRESS>]


[03:52] <drab> hi, I'm trying to preseed ubuntu on a raid1 and the preseed worked except that / and swap got flipped, so I got a huge swap and very small root partition
[03:52] <drab> anybody seen that before? this is the relevant preseed snippet: https://paste.ubuntu.com/23546912/
[03:53] <drab> whcih seems about correct to me, shuold give me a swap no bigger than 2GB and a / of everything else (-1 max size)
[03:53] <drab> a similar ex[ert recipe works just fine with non raid setup
[09:31] <mozart1893> HELLO CAN ANYONE HELP ME THROUGH ON ADDING A NEW NETWORK INTERFACE TO A UBUNTU SERVER 16.04 WITH ens33
[11:05] <jamespage> coreycb, ddellav, zul: lescina was backed up on storage - freed up some space
[11:06] <jamespage> the local apt repository had a morgue directory with the full history of deb updates in it...
[11:14] <tomreyn> mozart1893: no need fopr caps lock. are you still looking for assistence? if so, please describe the issue you're facing in more detail.
[11:43] <Roshan> I have install plain Linode server with apache and now want install my own mail server and need your help to do this.
[11:44] <tomreyn> use postfix or exim, read their manuals / getting started guides first of all.
[11:44] <tomreyn> poistfix has a pretty good manual / starting guide.
[11:44] <tomreyn> mailservers are a complex matter, be prepared to spend a lot of time.
[11:45] <tomreyn> ... or have someome else do it for you.
[11:46] <Roshan> tomreyn, I want to do it on Linode server
[11:46] <rbasak> cpaelzer: I looked at bug 1644595 but couldn't find the claimed violation. I commented.
[11:47] <OerHeks> https://www.linode.com/docs/email/running-a-mail-server
[11:48] <rbasak> Oh, I see what's going on.
[11:49] <cpaelzer> rbasak: I found the file itself, but I'll read the bug - thanks for looking at it
[11:49] <rbasak> cpaelzer: no, my mistake.
[11:49] <rbasak> I'll comment with a correction.
[11:50] <cpaelzer> rbasak: ah ok
[11:51] <cpaelzer> rbasak: you might - as I did first - have stumbled over Al[l]adins number of "l" chars
[11:52] <rbasak> It looks like it's typod in the boilerplate.
[11:53] <rbasak> cpaelzer: so this should be reported to Debian as a policy violation. I can do that, or would you prefer to?
[11:53] <cpaelzer> rbasak: If that is the way to go I can do that
[11:53] <cpaelzer> rbasak: I was just a bit out of my comfort zone, that is why I pulled you in
[11:54] <rbasak> cpaelzer: OK. Make it "Severity: serious" as it's a "severe violation of Debian policy".
[11:54] <rbasak> I checked and it applies to current sid, too.
[13:29] <jurislav> anyone thinks ZFS as a production fs is a bad idea..?
[13:35] <zul> coreycb/ddellav/jamesage:The way that neutron loads its plugins have changed in ocata so im going through the neutron plugins in universe and make sure they are kosher
[13:35] <coreycb> zul, got a pointer?
[13:36] <zul> coreycb: yep
[13:36] <zul> coreycb:gimme a sec
[13:36] <zul> coreycb: for ex https://github.com/openstack/neutron-lbaas/commit/00568ab38e5e057aec9fd0231bf8fa3101e4ceac
[13:39] <coreycb> zul, ok that's lbaas plugins. does that change how how plugins are configured?
[13:40] <zul> coreycb:i dont think so because i was able to run the smoketests against ocata without a problem
[13:41] <coreycb> zul, ok i'm still poking at horizon
[13:41] <zul> coreycb: ok cool...
[13:42] <zul> coreycb: i didnt upload horizon last week because i wanted to be double sure now im glad i didnt
[13:42] <coreycb> zul, thanks
[13:43] <zul> coreycb: ill be in plugin hell
[14:13] <samba35> please correct me if i am using ethernet   pci passthrought in guest  ,is that is full virtualization ?
[14:16] <ppetraki> samba35, nope, it's bare metal, that device cannot be shared with anyone else
[14:17] <samba35> ok
[14:19] <ppetraki> samba35, you typically use PCI passthrough only when speed, or some specific functionality is desired. Like giving a storage controller to a VM functioning as a virtual storage appliance is a good example.
[14:19] <ppetraki> samba35, it's also helpful for hacking kernel drivers in VM, it won't crash your main system
[14:20] <samba35> ok
[14:20] <samba35> thanks
[14:21] <ppetraki> you're welcome
[14:21] <samba35> i am confused with full and para virtualization
[14:21] <ppetraki> it is confusing :)
[14:22] <samba35> do you have better way to explain to lay man :)
[14:25] <ppetraki> In a nutshell: full virtualization is when you completely emulate a device, which can be expensive as the driver is doing "lots of stuff" as if it was still talking to the firmware on that device... but that device isn't there, the software just presents a device that quacks like it.
[14:26] <samba35> Thanks
[14:27] <ppetraki> para virtualization: is when you create a new class of device that  performs the intended function e.g. network, storage. But actually knows it's in a virtual environment. So there's alot less overhead, which makes it faster, but also makes that VM's performanced biased towards that platform
[14:27] <ppetraki> virtio drivers are considered para-virtual
[14:27] <samba35> okk
[14:28] <ppetraki> pci passthrough is zero-virtualization, well everything else is virtualized but that device is not. So you get all the benfits of a VM... except the ability to move it, because the destination must have the same physical device available
[14:29] <samba35> can you please explain what do u mean by " completely emulate a device"
[14:30] <ppetraki> pick any device that shows up in lspci on your physical hardware, the VM presents a device that responds exactly as if the hardware was really there, down to touching it's registers
[14:30] <ppetraki> as a result, there are only a handful of fully virtualized devices available.
[14:30] <ppetraki> I can't even name one
[14:30] <samba35> i bought 1 motherboard to test  pci-passthrouth with core2 quad cpu @40 us $
[14:31] <ppetraki> does it have intel vt-d?
[14:31] <samba35> yes
[14:32] <ppetraki> then you're good, that supports "modern pci passthrough" you can attach and detach a device to a VM as much as you want.
[14:32] <samba35> can i do pco-passthrought without vt-d ?
[14:32] <ppetraki> you can... but you have to plan it. You literally have to tell the system kernel "don't touch this device", that's how Xen did it
[14:33] <ppetraki> no one does it that way anymore, if they can help it
[14:33] <samba35> ic
[14:34] <samba35> this info was new to me i never ever use xen
[14:34] <ppetraki> most people don't need to deal with pci passthrough, virtio is plenty fast
[14:34] <samba35> Thank you !
[14:34] <ppetraki> :)
[14:34] <ppetraki> yw
[14:34] <ppetraki> have fun
[14:35] <samba35> i do use virtio with nic but what is best way to get gpu in guest ?
[14:37] <samba35> i have install palo alto networks firewall on ubuntu 12.04 as a 1st guest and again ubuntu as a 2nd guest as a dmz but i am not able to do some tasks
[14:38] <ppetraki> samba35, gpu as in cuda or brook gpu? or do you just want 3d accell?
[14:38] <samba35> as i am new to palo alto networks firewall
[14:39] <samba35> 3d accell?
[14:39] <samba35> 3 d accelerator ?
[14:39] <ppetraki> samba35, virtio-gpu and connect to it with spice
[14:40] <samba35> please correct me to use spice do i require special hardware ?
[14:40] <ppetraki> nope, it's just a viewer protocol
[14:41] <samba35> ic
[14:41] <ppetraki> the docs could be better: http://askubuntu.com/questions/250981/how-do-i-configure-spice-with-kvm
[14:42] <samba35> Thanks
[14:42] <ppetraki> follow the instructions for adding the virtio-gpu in virt-manager, then apt install spice-client-gtk python-spice-client-gtk
[14:43] <ppetraki> I'm surprised I can't find a native wiki on it...
[14:43] <coreycb> jamespage, we're getting some xenial-ocata backport failures for packages that need debhelper  > 10.  but prior to those we had some that backported successfully and i think they were picking up debhelper 10.2.2 from xenial-backports.
[14:43] <jamespage> coreycb, hmm
[14:43] <coreycb> jamespage, does that make any sense?  could something have changed?
[14:44] <jamespage> coreycb, unlikely - backports is not enabled by default in either our build schroots or the ppa's
[14:44] <samba35> will give try later today
[14:44] <coreycb> jamespage, ok.  i did have debhelper 10.2.2 backported the the ocata uca for a bit until i realized it was in xenial-backports, and it seemed to be causing problems.  maybe it's deb was lingering around after i deleted it.
[14:45] <jamespage> coreycb, that might be possible
[14:49] <ddellav> zul thanks for the heads up on the neutron plugins
[14:51] <zul> ddellav: yep
[14:52] <coreycb> jamespage, i think i'll try to backport it again after we test/promote b1
[14:52] <jamespage> coreycb, ack
[15:09] <coreycb> zul, horizon's uploaded.  i have a charm change to go along with it.
[15:09] <coreycb> ddellav, ^
[15:09] <zul> coreycb: sweet
[15:12] <ddellav> coreycb excellent
[15:14] <coreycb> zul, ddellav: do you have anything else outstanding for b1?
[15:15] <ddellav> coreycb according to the list, just the debian syncs are remaining as far as i can tell
[15:15] <zul> coreycb: we should be good to go...i was able to run a smoketest against the ci ppa
[15:15] <coreycb> ddellav, ok yeah
[15:15] <coreycb> zul, awesome, how many failures?
[15:16] <zul> coreycb:we might as well upload newer versions of those "syncs"
[15:16] <zul> a couple but those tests were not confgiured properly
[16:44] <rbasak> powersj: based on your comment in bug 1643245, I think that should be Fix Released?
[16:45] <powersj> rbasak: I only moved it to fix committed since zesty isn't released.
[16:46] <powersj> Should I have done something different?
[16:46] <rbasak> powersj: we still treat it as Fix Released if it's in the zesty (ie. development) release pocket.
[16:46] <powersj> ok
[16:46] <powersj> then yes please, go ahead and change it to released. Thank you!
[16:47] <rbasak> powersj: done, thanks. Consider it this way: if you uploaded a fix to Zesty with a bug reference, that would automatically change to Fix Released as soon as the package hit the zesty release pocket.
[16:47] <rbasak> I appreciate that's a little unintuitive from a wider Ubuntu perspective.
[16:48] <powersj> rbasak: ah ok, that makes it clearer to me
[20:02] <coreycb> jamespage, zul, ddellav: xenial-ocata-staging looks good - http://paste.ubuntu.com/23550029/
[20:03] <coreycb> can't test zesty until some zesty charm updates land
[20:07] <zul> coreycb: yeah waiting for them to land
[20:07] <zul> coreycb: i think thats what i got as a result as well
[20:10] <coreycb> zul, ok also there are 2 charm updates to land.  beisner is picking up the swift charm-helper update to enable 2.11.0 in the zesty syncs, and there's a PR for horizon static files
[20:11] <zul> coreycb: you mean this one? https://code.launchpad.net/~zulcss/charm-helpers/swift-ocata/+merge/311743
[20:12] <coreycb> zul, yup. sorry didn't know you had that out there for review.
[20:12] <zul> coreycb:no worries
[20:20] <jamespage> coreycb, I'll shove that lot into proposed then
[20:20] <coreycb> jamespage, thanks
[20:20] <jamespage> zul, coreycb: we should look to get libvirt into the UCA as well
[20:21] <jamespage> anyone looking at that?
[20:21] <zul> jamespage: i can probably
[20:21] <jamespage> zul, I see qemu already went back
[20:21] <jamespage> libvirt is a natural partner for that
[20:21] <jamespage> there are some nice features for migrations
[20:21] <zul> jamespage: qemu wasnt me ;)
[20:21] <jamespage> oh
[20:21] <jamespage> who was that?
[20:22] <coreycb> jamespage, not me
[20:24] <jamespage> coreycb, zul: might have been me
[20:25] <zul> jamespage: just did a quick check we dont have to backport libxen this time ;)


[03:22] <blakep> Anyone here?
[03:23] <blakep> How would one go about creating an iso that has custom packages
[03:23] <blakep> ?


[10:26] -queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/4265 Diff missing (groovy/gdm3, groovy/gnome-remote-desktop, groovy/gnome-shell, groovy/krfb, groovy/mutter, groovy/pipewire, groovy/weston, groovy/xdg-desktop-portal). Pending binary packages (groovy/xdg-desktop-portal-kde)
[10:46] -queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/4265 Diff missing
[12:34] -queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/4266 No packages are being considered! If you are preparing sources manually, please upload them to the PPA now
[12:37] -queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/4266 Generating diffs
[12:53] -queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/4266 Generating diffs
[13:26] -queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/4266 Successfully built
[15:26] -queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/4265 Diff missing (groovy/gdm3, groovy/gnome-remote-desktop, groovy/gnome-shell, groovy/krfb, groovy/pipewire, groovy/weston, groovy/xdg-desktop-portal, groovy/xdg-desktop-portal-kde). Uploading build (groovy/mutter)
[15:46] -queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/4265 Diff missing (groovy/gdm3, groovy/gnome-remote-desktop, groovy/gnome-shell, groovy/krfb, groovy/pipewire, groovy/weston, groovy/xdg-desktop-portal, groovy/xdg-desktop-portal-kde). Pending binary packages (groovy/mutter)
[16:06] -queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/4265 Diff missing
[19:42] -queuebot:#ubuntu-ci-eng- rbalint, https://bileto.ubuntu.com/#/ticket/3801 Proposed pocket (groovy/glibc, groovy/libnss-nis, groovy/libnss-nisplus). Successfully built (groovy/systemd)


[16:17] -SwissBot:#ubuntu-news- ::OMG!Ubuntu:: Enable This Nautilus Setting to Move Files Faster on Ubuntu @ https://www.omgubuntu.co.uk/2023/02/ubuntu-open-folder-on-drag-drop-hover (by Joey Sneddon)
[22:33] -SwissBot:#ubuntu-news- ::Planet:: Scarlett Gately Moore: KDE Snaps, snapcraft, Debian packages. @ https://www.scarlettgatelymoore.dev/kde-snaps-snapcraft-debian-packages/


[18:30] <tomreyn> there seems to be no release announcement for 19.04, yet. traditionally, those got published on markshuttleworth.com, roughly 5 months before release


[10:47] <Tobias_79> Hi, I recently ran into a bug in the kernel OOM killer that repeadtedly caused complete system freezes when a cgroup went out of memory (trusty, kernel 3.13.0-66), the problem is described here: https://community.nitrous.io/posts/stability-and-a-linux-oom-killer-bug is there any chance that the fixes from kernel 3.14 will be backported to the trusty kernel?
[10:56] <rbasak> Tobias_79: this channel is specifically for bug triage. Try asking in #ubuntu-kernel - that's where the kernel developers hang out so you're more likely to reach someone who can answer you there.
[13:49] <melodie> hi
[13:49] <melodie> recently I stumbled upon this bug report, which I think is not a bug: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-mga/+bug/1378940
[13:50] <melodie> the XorgConf.txt file sent shows that the guy had VESA loaded, and not MGA
[19:05] <MegaBrutal> Could you please triage bug #1509717?
[19:52] <jtaylor> MegaBrutal: looks like someone looked at it now
[19:52] <jtaylor> thanks for reporting it btw, it looks like it could be related to my lvmcache issues
[19:52] <jtaylor> missing module in initramfs would probably cause the unclean shutdowns I'm getting
[20:10] <MegaBrutal> jtaylor: Once upon a time, I also reported an lvmcache issue, bug 1423796. Does this affect you? If so, you could increase the bug-heat...
[20:11] <jtaylor> MegaBrutal: I only added check_cache to my initramfs to make it work
[20:12] <jtaylor> didn't test if it works without now
[20:12] <jtaylor> ah you mentioned that in the report
[20:16] <MegaBrutal> It also missed a module. To be fair, I also haven't tested it in a long time. Though apw did not close the bug report, so I assume it is not solved yet.
[20:18] <jtaylor> I didn't need to add a module in 15.10 so thats probably fixed
[20:18] <jtaylor> also might be worth testing if check_cache is still needed
[20:20] <jtaylor> my issue is that due to the unclean shutdown the cache is 100% dirty on reboot
[20:20] <jtaylor> so it needs to flush it on boot which takes half an hour
[20:20] <jtaylor> couldn't figure out how to get it to shutdown cleanly, but maybe it was a missing module as you reported
[20:21] <jtaylor> my system boots as the raid is not my boot device
[20:21] <jtaylor> so it maybe activates it after the initramfs
[20:21] <jtaylor> but can't turn it off in it