[06:33] <cpaelzer> rbasak: yes I knew about the DPDK MRE ack, sil also did the wiki update
[06:33] <cpaelzer> rbasak: was there a follow on action I missed?
[06:34] <cpaelzer> rbasak: or was this "just" still on your personal todo and I should have let you know that it is done?
[06:35] <cpaelzer> rbasak: just checked the mail he sent and (now checking receipients more closely) see that it was only me and dpb1
[07:38] <slangasek> looks like ubuntu-budgie builds are going to be broken for a bit, since they pull in linux-tools-*, which is the package we broke to let the mpfr4 transition finish.  But why does Budgie install linux-tools, anyway?
[07:50] <LocutusOfBorg> folks, with guile fixed, I plan to land ticket 3141 in 10h if nobody complains
[07:51] <LocutusOfBorg> the rebuilds have worked correctly, and silo is happy with the diffs
[08:20] -queuebot:#ubuntu-release- Unapproved: accepted util-linux [source] (xenial-proposed) [2.27.1-6ubuntu3.5]
[09:56] <rbasak> cpaelzer, sil2100: I just figured out what happened. Christian's email to ubuntu-release@ on Jan 4 only got delivered to my inbox yesterday. So I thought he didn't know it was approved.
[09:56] <rbasak> Perhaps due to moderation?
[09:56] <rbasak> I thought he didn't know it was approved> i didn't know it was approved either as I hadn't seen the IRC conversation
[09:56] <rbasak> So I thought it was still with sil2100
[10:08] <bdrung_work> the test failure for salt-formula-ceilometer on i386 is a false positive (VirtSubproc.Timeout). The failed test runs for the salt dependencies salt-formula-* should be rerun since i fixed the regressions yesterday with new uploads. where is the correct place to report this?
[10:09] <cpaelzer> rbasak: ok
[10:09] <cpaelzer> rbasak: confusion resolved now at least :-)
[10:09] <cpaelzer> rbasak: I replied to the list again so that it is known there, but that might take another 4 weeks :-)
[10:10] <rbasak> cpaelzer: I seem to have got that one straight away
[10:14] <sil2100> oh
[10:15] <rbasak> Oh. No I didn't.
[10:15] <rbasak> (get it straight away)
[10:15] <rbasak> Anyway.
[10:15] <rbasak> :)
[10:18] -queuebot:#ubuntu-release- New: accepted libgweather [amd64] (bionic-proposed) [3.27.4-1]
[10:18] -queuebot:#ubuntu-release- New: accepted libgweather [armhf] (bionic-proposed) [3.27.4-1]
[10:18] -queuebot:#ubuntu-release- New: accepted libgweather [ppc64el] (bionic-proposed) [3.27.4-1]
[10:18] -queuebot:#ubuntu-release- New: accepted libgweather [arm64] (bionic-proposed) [3.27.4-1]
[10:18] -queuebot:#ubuntu-release- New: accepted libgweather [s390x] (bionic-proposed) [3.27.4-1]
[10:18] -queuebot:#ubuntu-release- New: accepted libgweather [i386] (bionic-proposed) [3.27.4-1]
[10:20] <LocutusOfBorg> jbicha, just to be clear, export V=1 makes gtk-doc fail to build also in Debian :)
[10:20] <LocutusOfBorg> so, the problem is not an Ubuntu only, but probably an even upstream one
[10:21] <LocutusOfBorg> maybe forwarding to upstream developers might help, also having a better error message, to avoid other linux distro having the same issue
[10:24] -queuebot:#ubuntu-release- Unapproved: accepted grub2 [source] (artful-proposed) [2.02~beta3-4ubuntu7.2]
[10:25] <jbicha> is "V=1" a convention?
[10:26] <jbicha> ok, I see it's an automake thing
[10:29] <LocutusOfBorg> jbicha, it is exported by ubuntu buildds, but in any case, I think docbook-xls is evaluating it
[10:29] <LocutusOfBorg> upstream should probably be doing V=0 in testsuite, not Debian or Ubuntu
[10:33] -queuebot:#ubuntu-release- Unapproved: accepted grub2-signed [source] (artful-proposed) [1.85.2]
[10:33] <LocutusOfBorg> jbicha, https://patchwork.kernel.org/patch/7699771/
[10:34] -queuebot:#ubuntu-release- Unapproved: grub2 (artful-proposed/main) [2.02~beta3-4ubuntu7.1 => 2.02~beta3-4ubuntu7.2] (core)
[10:54] <sil2100> rbasak: I see you have commented/discussed on the libzstd SRU - should I leave it on your plate as you have the most context?
[10:57] -queuebot:#ubuntu-release- Unapproved: accepted ceph [source] (artful-proposed) [12.2.2-0ubuntu0.17.10.1]
[11:00] <rbasak> sil2100: ack. Ah - I see it's in the queue.
[11:04] -queuebot:#ubuntu-release- Unapproved: accepted grub2 [arm64] (artful-proposed) [2.02~beta3-4ubuntu7.2]
[11:07] -queuebot:#ubuntu-release- Unapproved: grub2 (artful-proposed/main) [2.02~beta3-4ubuntu7.2 => 2.02~beta3-4ubuntu7.2] (core)
[11:09] -queuebot:#ubuntu-release- Unapproved: accepted pulseaudio [source] (artful-proposed) [1:10.0-2ubuntu3.1]
[11:13] -queuebot:#ubuntu-release- Unapproved: rejected pulseaudio [source] (xenial-proposed) [1:8.0-0ubuntu3.8]
[11:13] -queuebot:#ubuntu-release- Unapproved: pulseaudio (xenial-proposed/main) [1:8.0-0ubuntu3.7 => 1:8.0-0ubuntu3.8] (core)
[11:17] -queuebot:#ubuntu-release- Unapproved: rejected linux-firmware [source] (xenial-proposed) [1.157.17]
[11:22] -queuebot:#ubuntu-release- Unapproved: accepted fwupd [source] (xenial-proposed) [0.8.3-0ubuntu2]
[11:23] -queuebot:#ubuntu-release- Unapproved: accepted pulseaudio [source] (xenial-proposed) [1:8.0-0ubuntu3.8]
[11:26] -queuebot:#ubuntu-release- Unapproved: rejected libzstd [source] (xenial-proposed) [1.3.1+dfsg-1~ubuntu0.16.04.1]
[11:29] <sil2100> smb: hey! I'm looking at your iscsitarget SRU upload for trusty right now
[11:30] <sil2100> smb: I remember it for xenial, but hm, the new upload is for fixing an ADT test - but I don't see any failures for the iscsitarget package that's currently in trusty-proposed - is it only because those ran a long long time ago?
[11:31] <smb> sil2100, yes? That one is a combo. The part I did is only the test, the other part is from what alrady was in proposed
[11:31] <sil2100> smb: does it mean that if the tests were re-run right now without the fix, they would fail?
[11:31] <smb> sil2100, The dep8 failure is racy
[11:31] <smb> So accidentally sometimes did work
[11:31] <sil2100> Ah, ok, guess better to have it than not
[11:31] <sil2100> Thanks
[11:32] -queuebot:#ubuntu-release- Unapproved: accepted libzstd [source] (xenial-proposed) [1.3.1+dfsg-1~ubuntu0.16.04.1]
[11:32] <smb> sil2100, For detail, when checking for the daemon being running it sometimes took the start script as the running daemon (if system was slow enough)
[11:32] -queuebot:#ubuntu-release- Unapproved: accepted libzstd [source] (artful-proposed) [1.3.1+dfsg-1ubuntu0.1]
[11:32] -queuebot:#ubuntu-release- Unapproved: accepted iscsitarget [source] (trusty-proposed) [1.4.20.3+svn499-0ubuntu2.5]
[11:40] -queuebot:#ubuntu-release- New binary: libzstd [s390x] (artful-proposed/universe) [1.3.1+dfsg-1ubuntu0.1] (ubuntustudio)
[11:41] -queuebot:#ubuntu-release- New binary: libzstd [ppc64el] (artful-proposed/universe) [1.3.1+dfsg-1ubuntu0.1] (ubuntustudio)
[11:42] <rbasak> ahasenack: ^ that's confusing
[11:42] <rbasak> I wasn't expecting a new binary called libzstd
[11:43] <rbasak> It's not in debian/control
[11:43] <ahasenack> isn't that the source name?
[11:44]  * LocutusOfBorg is ready to land ticket 3141
[11:44] <rbasak> Oh
[11:44] <rbasak> That's the name of the source, not the new binary
[11:44] <ahasenack> I think so
[11:44] <rbasak> https://launchpad.net/ubuntu/+source/libzstd/1.3.1+dfsg-1ubuntu0.1/+build/14353830 has what I expected
[11:44] <ahasenack> cool
[11:45] <rbasak> Never mind. Sorry!
[11:45] <ahasenack> np :)
[11:50] -queuebot:#ubuntu-release- New binary: libzstd [s390x] (xenial-proposed/universe) [1.3.1+dfsg-1~ubuntu0.16.04.1] (no packageset)
[11:53] -queuebot:#ubuntu-release- New binary: libzstd [arm64] (artful-proposed/universe) [1.3.1+dfsg-1ubuntu0.1] (ubuntustudio)
[11:55] -queuebot:#ubuntu-release- New binary: libzstd [armhf] (artful-proposed/universe) [1.3.1+dfsg-1ubuntu0.1] (ubuntustudio)
[11:56] <LocutusOfBorg> how ofter does britney run on bileto?
[11:56] -queuebot:#ubuntu-release- New binary: libzstd [powerpc] (xenial-proposed/universe) [1.3.1+dfsg-1~ubuntu0.16.04.1] (no packageset)
[11:57] -queuebot:#ubuntu-release- New binary: libzstd [amd64] (artful-proposed/universe) [1.3.1+dfsg-1ubuntu0.1] (ubuntustudio)
[11:59] -queuebot:#ubuntu-release- New binary: libzstd [i386] (xenial-proposed/universe) [1.3.1+dfsg-1~ubuntu0.16.04.1] (no packageset)
[12:01] -queuebot:#ubuntu-release- New binary: libzstd [i386] (artful-proposed/universe) [1.3.1+dfsg-1ubuntu0.1] (ubuntustudio)
[12:08] -queuebot:#ubuntu-release- New binary: libzstd [arm64] (xenial-proposed/universe) [1.3.1+dfsg-1~ubuntu0.16.04.1] (no packageset)
[12:10] -queuebot:#ubuntu-release- New binary: libzstd [amd64] (xenial-proposed/universe) [1.3.1+dfsg-1~ubuntu0.16.04.1] (no packageset)
[12:11] -queuebot:#ubuntu-release- New binary: libzstd [ppc64el] (xenial-proposed/universe) [1.3.1+dfsg-1~ubuntu0.16.04.1] (no packageset)
[12:18] -queuebot:#ubuntu-release- New binary: libzstd [armhf] (xenial-proposed/universe) [1.3.1+dfsg-1~ubuntu0.16.04.1] (no packageset)
[12:56] -queuebot:#ubuntu-release- Unapproved: open-vm-tools (artful-proposed/main) [2:10.1.10-3 => 2:10.1.10-3ubuntu0.1] (edubuntu, ubuntu-cloud, ubuntu-server)
[12:56] -queuebot:#ubuntu-release- Unapproved: open-vm-tools (xenial-proposed/main) [2:10.0.7-3227872-5ubuntu1~16.04.1 => 2:10.0.7-3227872-5ubuntu1~16.04.2] (edubuntu, ubuntu-cloud, ubuntu-server)
[12:57] -queuebot:#ubuntu-release- Unapproved: open-vm-tools (trusty-proposed/main) [2:9.4.0-1280544-5ubuntu6.2 => 2:9.4.0-1280544-5ubuntu6.3] (ubuntu-cloud, ubuntu-server)
[13:31] -queuebot:#ubuntu-release- Unapproved: linux-firmware (xenial-proposed/main) [1.157.16 => 1.157.17] (core, kernel)
[13:56] <LocutusOfBorg> why libunistring from silo didn't end up in binNEW queue?
[13:56] <LocutusOfBorg> is publishing from silo something that avoids the queue? seems strange
[13:57] <jbicha> LocutusOfBorg: yes
[13:58] <LocutusOfBorg> wow, I don't understand the rationale for this but yeah
[14:02] -queuebot:#ubuntu-release- Unapproved: walinuxagent (artful-proposed/main) [2.2.21-0ubuntu1~17.10.1 => 2.2.21+really2.2.20-0ubuntu1~17.10.1] (ubuntu-cloud, ubuntu-server)
[14:02] -queuebot:#ubuntu-release- Unapproved: walinuxagent (xenial-proposed/main) [2.2.21-0ubuntu1~16.04.1 => 2.2.21+really2.2.20-0ubuntu1~16.04.1] (ubuntu-cloud, ubuntu-server)
[14:02] -queuebot:#ubuntu-release- Unapproved: walinuxagent (trusty-proposed/main) [2.2.21-0ubuntu1~14.04.1 => 2.2.21+really2.2.20-0ubuntu1~14.04.1] (ubuntu-cloud, ubuntu-server)
[14:06] <LocutusOfBorg> ack thanks
[14:16] <jbicha> it's a bug
[14:17] <apw> LocutusOfBorg, this is why releasing from biletto is meant to involve an AA doing the new review beforehand if there are any new binaries
[14:49] <superm1> Hi, can an archive admin please help review unapproved today?  fwupdate is blocking fwupd build and migration
[15:27] -queuebot:#ubuntu-release- Unapproved: libsmbios (xenial-backports/universe) [2.3.0-0ubuntu1.1 => 2.4.0-1~ubuntu16.04.1] (no packageset)
[15:42] -queuebot:#ubuntu-release- Unapproved: libsmbios (trusty-backports/universe) [2.2.28-2 => 2.4.0-1~ubuntu14.04.1] (no packageset)
[16:44] <nacc> slangasek: if you have a moment: LP: #1749745
[16:44] <nacc> that's at least one, which is currently blocking php-defaults
[16:48] <slangasek> nacc: how is php-crypt-chap blocking?  it has a FTBFS but only Recommends: php-mcrypt
[16:48] <nacc> slangasek: it build-depends on it
[16:49] <slangasek> a build-depend doesn't block migration
[16:49] <nacc> slangasek: we can't build it with php-defaults for 7.2
[16:49] <nacc> as there is no php-mcrypt
[16:49] <slangasek> and php-crypt-chap is arch: all
[16:49] <slangasek> with no interesting dependencies that would block a transition
[16:49] <nacc> the tests fail at runtime becuase it tries to load mcrypt
[16:49] <nacc> (well, use mcrypt)
[16:49] <slangasek> tests> right, that's the rationale I was looking for
[16:49] <nacc> i don't know why it's a reverse-recommends only , as it seems like a hard dependency :)
[16:50] <slangasek> howso?
[16:50] <nacc> slangasek: as in, the code uses mcrypt explicitly
[16:50] <nacc> afaict
[16:50] <slangasek> it's reasonable for a testsuite to cover things that are optional
[16:50] <slangasek> hmm ok
[16:50] <nacc> slangasek: i didn't dig into it too much
[16:50] <nacc> but afaict, if something is still using mcrypt (per ondrej) it's probably cruft
[16:50] <nacc> even if optionally
[16:51] <slangasek> yes, but that alone is not a rationale for us to remove it in advance of Debia
[16:51] <nacc> slangasek: i guess i should have been clearer: a rebuild of php-crypt-chap will fail eventually (due to missing php-mcrypt) and the tests will always fail with PHP7.2
[16:51] <slangasek> hngh and then I go and remove the wrong package
[16:51] <slangasek> hi please trust me with your archive
[16:52] <nacc> somehow it doesn't change my trust level :)
[16:52]  * slangasek puts php-horde-passwd back
[16:53] -queuebot:#ubuntu-release- New sync: php-horde-passwd (bionic-release/primary) [5.0.7-1]
[16:56] <slangasek> nacc: any idea why serious bugs haven't been filed in Debian for these yet? (ex: yubikey-ksm)
[16:56] <nacc> slangasek: i really don't know. the Debian side of this transition has been ... poor, IMO this time
[16:57] <nacc> slangasek: lots (most) faililng dep8 all over
[16:57] <nacc> some ftbfs
[16:57] <nacc> slangasek: it's possible it's coming, or they will just be removed eventually
[16:57] <nacc> slangasek: oh wait, i know why
[16:57] <nacc> slangasek: debian has 7.1 and 7.2
[16:57] <nacc> and i think 7.1 is the default (so php-mcrypt points there)
[16:58] <slangasek> k
[16:58] <nacc> xnox: have you checked the new php-doctrine-cache works?
[17:03] <xnox> nacc, no! but i have high hopes; since upstream dropped the test suite =)
[17:07] <nacc> xnox: lol
[17:09] -queuebot:#ubuntu-release- Unapproved: debian-installer (xenial-proposed/main) [20101020ubuntu451.19 => 20101020ubuntu451.20] (core)
[18:15] <bdmurray> balloons: So can bug 1744968 be considered verification-done?
[18:16] <balloons> bdmurray, I was wanting cyphermox to chime in as well, so I didn't change the tags
[18:16] <balloons> bdmurray, but I suppose netplan is waiting on juju, and there isn't any reason to hold juju.
[18:18] <balloons> bdmurray, set to verification-done
[18:42] -queuebot:#ubuntu-release- Unapproved: rejected salt [source] (artful-proposed) [2017.7.2+dfsg1-1ubuntu1]
[18:45] -queuebot:#ubuntu-release- Unapproved: accepted open-vm-tools [source] (artful-proposed) [2:10.1.10-3ubuntu0.1]
[18:48] -queuebot:#ubuntu-release- Unapproved: accepted open-vm-tools [source] (xenial-proposed) [2:10.0.7-3227872-5ubuntu1~16.04.2]
[18:49] -queuebot:#ubuntu-release- Unapproved: accepted open-vm-tools [source] (trusty-proposed) [2:9.4.0-1280544-5ubuntu6.3]
[18:54] -queuebot:#ubuntu-release- Unapproved: accepted walinuxagent [source] (artful-proposed) [2.2.21+really2.2.20-0ubuntu1~17.10.1]
[18:56] -queuebot:#ubuntu-release- Unapproved: accepted walinuxagent [source] (xenial-proposed) [2.2.21+really2.2.20-0ubuntu1~16.04.1]
[18:57] -queuebot:#ubuntu-release- Unapproved: accepted walinuxagent [source] (trusty-proposed) [2.2.21+really2.2.20-0ubuntu1~14.04.1]
[19:07] -queuebot:#ubuntu-release- Unapproved: accepted debian-installer [source] (xenial-proposed) [20101020ubuntu451.20]
[19:42] <wmww> Is this the place to bring up a package issue in 18.04?
[19:51] <nacc> wmww: #ubuntu+1
[19:51] <nacc> wmww: presuming you mean a bug or so
[19:54] <wmww> nacc: Clang won't install due to dependency issue. I'll report it there.
[19:58] <nacc> slangasek: if you could also look at LP: #1749783 when you get a chance.
[20:03] <nacc> slangasek: also just updated to include the debian bugs fo rhte same
[20:04] <nacc> i'm assuming whoever is doing the debian builds may be bootstrapping them in, which is leading to this mess on our side
[20:34] -queuebot:#ubuntu-release- New binary: gnome-desktop3 [s390x] (bionic-proposed/main) [3.27.90-1ubuntu1] (ubuntu-desktop)
[20:36] -queuebot:#ubuntu-release- New binary: gnome-desktop3 [ppc64el] (bionic-proposed/main) [3.27.90-1ubuntu1] (ubuntu-desktop)
[20:36] -queuebot:#ubuntu-release- New binary: gnome-desktop3 [i386] (bionic-proposed/main) [3.27.90-1ubuntu1] (ubuntu-desktop)
[20:37] -queuebot:#ubuntu-release- New binary: gnome-desktop3 [amd64] (bionic-proposed/main) [3.27.90-1ubuntu1] (ubuntu-desktop)
[20:38] -queuebot:#ubuntu-release- New binary: gnome-desktop3 [arm64] (bionic-proposed/main) [3.27.90-1ubuntu1] (ubuntu-desktop)
[20:38] -queuebot:#ubuntu-release- New binary: gnome-desktop3 [armhf] (bionic-proposed/main) [3.27.90-1ubuntu1] (ubuntu-desktop)
[21:12] -queuebot:#ubuntu-release- Unapproved: rejected gcc-4.8 [sync] (trusty-proposed) [4.8.4-2ubuntu1~14.04.4]
[21:27] -queuebot:#ubuntu-release- Unapproved: gcc-4.8 (trusty-proposed/main) [4.8.4-2ubuntu1~14.04.3 => 4.8.4-2ubuntu1~14.04.4] (core) (sync)
[21:39] -queuebot:#ubuntu-release- Unapproved: accepted gcc-4.8 [sync] (trusty-proposed) [4.8.4-2ubuntu1~14.04.4]
[21:42] <flocculant> infinity: re this  “minimal install” option - how's that going to pan out for flavours? also reminding that we've been trying to get a Xubuntu minimal going for some cycles now
[21:42] <flocculant> bluesabre: ^^
[21:50] <superm1> flocculant, at least from the way it looks like it's been implemented in the PR it's a simple flat file that calls out what you want ripped out of your livefs while installing
[21:51] <flocculant> PR ?
[21:52] <flocculant> sorry - I do QA for us not coding :p
[21:52] <superm1> flocculant, https://code.launchpad.net/~didrocks/ubiquity/minimal-install/+merge/337698 that's the merge request for it
[21:53] <superm1> currently it points to everything in a file /usr/share/ubiquity/manifests/minimal_install_removal
[21:53] <flocculant> superm1: oh right - I have enough trouble getting around bzr and mp - not a clue what PR is :D
[21:53] <superm1> so I would expect the best thing for a flavor to do is dpkg-divert that and provide a list of what they want out
[21:53] <flocculant> superm1: we've been looking at a completely seperate iso to do that
[21:54] <superm1> you should probably discuss with didrocks and xnox specifically on the best way they want to see flavors do it
[21:54] <superm1> but that seems like a plausibly good way to me
[21:54] <flocculant> mmm
[21:56] <infinity> superm1: Eh?  There's nothing to dpkg-divert.  The removal file doesn't come from ubiquity.
[21:57] <superm1> infinity, it will though I thought
[21:57] <superm1> i mean i guess nothing is accepted yet and it can change
[21:57] <infinity> superm1: If the removal file isn't supplied during the image build, that's a massive and glaring bug. :P
[21:57] <infinity> (And I'd push back hard on such a "design")
[21:58] <flocculant> infinity: evening :)
[21:58] <superm1> https://code.launchpad.net/~didrocks/ubiquity/minimal-package-list/+merge/337700
[21:58] <infinity> Gross.
[21:59] <tsimonq2> Oh jeez.
[21:59] <tsimonq2> Please don't tell me that's a hardcoded list...
[22:00] <infinity> It sure is.
[22:02] <flocculant> so glad I'm just qa ...
[22:02] <flocculant> if you can call - asking and being ignored that ;)
[22:04] <infinity> flocculant: Sorry, not maliciously ignoring you, just literally have no answer.
[22:05] <infinity> flocculant: Or, rather "the Canonical Desktop team landing hackish temporary features doesn't really have much impact on flavours".
[22:05] <infinity> (Assuming the claim that they plan to ditch ubiquity entirely comes to fruition)
[22:06] <slangasek> I don't understand that claim
[22:06] <infinity> slangasek: I don't either, but it's right there in the MP. :P
[22:06] <slangasek> yeah
[22:06] <slangasek> I blame xnox
[22:06] <slangasek> (by which I mean, "I summon xnox")
[22:06] <infinity> slangasek: Now, I could dissect the claim as "we intend to use subiquity-style fs-stacking in ubiquity", which isn't the world's worst idea.
[22:07] <flocculant> infinity: ack - never would assume you would do such a thing, if you wanted to - make it obvious :)
[22:07] <infinity> And would neatly reduce the live removal stage of both ubiquity and live-installer to a no-op.
[22:07] <cjwatson> An idea with a decade's pedigree
[22:07] <infinity> cjwatson: Indeed.
[22:07] <cjwatson> Which nobody ever got to work before, but that shouldn't stop people trying :)
[22:08] <infinity> Well, the big problem is booting a functional desktop with stacked livefses.
[22:08] <infinity> Where one was bad enough.
[22:08] <tsimonq2> It doesn't help that OMG! Ubuntu! misinterpreted the commit message that Didier wrote, and since some people decide to pick that apart, the rumor has spread that Desktop is now switching to subiquity.
[22:08] <tsimonq2> FTR.
[22:08] <infinity> But things have matured a lot since the bad old days.
[22:08] <infinity> tsimonq2: Yes, well.  Let's not let the press dictate our plans. :)
[22:08] <tsimonq2> infinity: Stacked squashfses is something interesting.
[22:08] <cjwatson> The big problem back then was unavoidable file overlaps between the livefses (e.g. /var/lib/dpkg/status), but yeah, filesystem technology has moved on.
[22:08] <infinity> Right, and they almost mostly work now.
[22:09] <tsimonq2> infinity: I agree, but in more than one channel this morning people lolwat'ted at that :)
[22:09] <infinity> cjwatson: Well, if you're intentionally stacking linearly, that's not an issue.
[22:09] <tsimonq2> infinity: stacked squashfses> Oh, that's cool. I'd hate to ask for an ETA, but will it land before Feature Freeze?
[22:09] <infinity> cjwatson: ie: base > desktop > desktop-fat > live, then you peel back in inverse order.
[22:09] <cjwatson> Yeah.
[22:10] <infinity> cjwatson: It all goes to hell when people want to use that to define packagesets.
[22:10]  * slangasek nods
[22:10] <cjwatson> desktop-lardons, if you will
[22:10] <cjwatson> (you probably won't)
[22:11] <slangasek> desktop-evoo
[22:13] <infinity> desktop-chubby?
[22:14] <tsimonq2> desktop-apps maybe?
[22:14] <infinity> However, I'm not sure if either the current hack or stacked fses addresses what Xubuntu wanted, which was a smaller image, not just a smaller install footprint.
[22:15] <infinity> If they don't care about image size, then I think stacking is the right answer for everyone to be working on.
[22:15] <infinity> (Or, rather, if the back down on the image size thing, despite caring?)
[22:15] <infinity> s/the/they/
[22:16] <infinity> A single image with two install options is much less hassle to QA as well.
[22:16] <tsimonq2> Talking about image size reminds me to tell you infinity -- I tried removing no-follow-recommends on Lubuntu Next and it pulled in a Plasma desktop... :P so I guess I'll have to play with the recommends more on things, but 18.10 might see us lifting that, finally, for Lubuntu Next. I don't think we care about image size anymore as long as it's not ridiculous.
[22:17] <flocculant> infinity: I can't answer that - though iirc we were looking more at a step between a mini.iso and the current full fat Xubuntu - bluesabre Ukikie are the people who could answer more speciffically
[22:17] <tsimonq2> And Lubuntu Next might use stacking, I think that's a great idea, honestly.
[22:19] <infinity> tsimonq2: Yeah, you might be able to enlist jbicha's help with your recommends issues (if he's up for it, I don't want to volunteer him).  He's very familiar with the tricks we had to pull when ubuntu-desktop and ubuntu-gnome had to somehow magically coexist without pulling each other in.
[22:20] <tsimonq2> infinity: That sounds like that would have been *super* fun. /s
[22:20] <infinity> tsimonq2: It was a bit of a headache making sure unity didn't pull in GNOME and GNOME didn't pull in unity, yes, but it kinda mostly worked most of the time. :P
[22:20] <tsimonq2> :D
[22:22] <tsimonq2> infinity: So, speaking of images as well... Lubuntu Next won't have an Alternate image. We might play with Calamares' netboot functionality but as far as direct d-i goes, we're likely going to be done with that. But we sort of need Lubuntu's Alternate images to work, for one last release, so we can ship them. :P
[22:22] <tsimonq2> infinity: I mean, it would help if it could pull a kernel in :P *ahem*
[22:23] <tsimonq2> (bug 1746807)
[22:24] <tsimonq2> infinity: Something landed between the ISO landing on January 31st and February 1st that broke things, and I can't figure out what.
[22:24] <tsimonq2> (s/landing/spinning up/ on that second occurrence :P)
[22:25] <flocculant> tsimonq2: does that mean that eventually other people won't get asked to test Lubuntu Alternates right at the last minute when you run out of time :D
[22:25] <tsimonq2> flocculant: It will, yes :D
[22:25] <flocculant> ha ha
[22:26] <tsimonq2> hahaha
[22:26]  * flocculant waits ... but is available if necessary till then ;)
[22:26] <tsimonq2> Right, we gotta get the LTS out.
[22:26] <tsimonq2> Then we can cut the cruft.
[22:27] <tsimonq2> (Well, we're already *kinda* doing that, but we aren't touching the LXDE edition except for bugfixes :) )
[22:42] <flocculant> :)
[22:43] <flocculant> what I'm trying to aim for is for us to only sign up to fix 'not diabolical' bugs which get reported on the tracker
[22:44] <flocculant> I can then turn up 4 times a year and say we have no bugs unless I found them :D
[22:45] <flocculant> I find more things in places like qemu than xfce packages
[22:51] <xnox> slangasek, what did you mean by stacked squashfs? you mean like doing overlayfs and packing each layer as squashfs?
[22:52] <xnox> slangasek, or am I out-of-date and squashfs naturally supports stacking somehow?
[23:00] <slangasek> xnox: overlay between multiple squashes
[23:04] <bdmurray> slangasek: Can you set the phased-update-percentage for compiz to 0 see #ubuntu-devel.
[23:04] <bdmurray> ? for good measure
[23:05] <xnox> slangasek, and we have tooling to build those? could be fun.
[23:05] <slangasek> xnox: we effectively already do this for subiquity
[23:05] <slangasek> it's only a two-deep stack
[23:06] <slangasek> bdmurray: source package is compiz? which release?
[23:06] <nacc> slangasek: compiz on xenial
[23:06] <slangasek> nacc, bdmurray: done
[23:06] <nacc> looks to have migrated about 4 hours ago?
[23:07] <xnox> slangasek, ok.
[23:07] <slangasek> xnox: and this is what we were talking about for the maas install options?
[23:08] <nacc> slangasek: thanks
[23:08] <xnox> slangasek, i thought so, yeah
[23:08] <xnox> ?!
[23:08] <slangasek> bdmurray, nacc: what's the follow-through? unity needs rebuilt and pushed?  does it need revalidated?
[23:08] <slangasek> xnox: yes, that's why I'm surprised you didn't know we had tooling :)
[23:08] <nacc> slangasek: i think unity at a minimum needs a rebuild
[23:09] <nacc> it's the only reverse build-depends?
[23:09] <bdmurray> there is a unity in -proposed
[23:09] <xnox> slangasek, i was not involved in the subiquity livecd-rootfs stuff
[23:09] <nacc> so they just need to migrate together, bdmurray ?
[23:09] <slangasek> xnox: ack, I failed to give you context on the current state then
[23:09] -queuebot:#ubuntu-release- New binary: ddnet [s390x] (bionic-proposed/universe) [11.0.3-1] (no packageset)
[23:09] -queuebot:#ubuntu-release- New binary: mbedtls [s390x] (bionic-proposed/universe) [2.7.0-2] (no packageset)
[23:10] <slangasek> bdmurray: I should let you follow it up then?
[23:10] <bdmurray> slangasek: I'm looking into it fwiw
[23:11] <bdmurray> enabling -proposed makes the upgrade not want to remove unity
[23:12] -queuebot:#ubuntu-release- New binary: ddnet [amd64] (bionic-proposed/universe) [11.0.3-1] (no packageset)
[23:12] -queuebot:#ubuntu-release- New binary: mbedtls [amd64] (bionic-proposed/universe) [2.7.0-2] (no packageset)
[23:12] -queuebot:#ubuntu-release- New binary: ddnet [i386] (bionic-proposed/universe) [11.0.3-1] (no packageset)
[23:12] -queuebot:#ubuntu-release- New binary: mbedtls [i386] (bionic-proposed/universe) [2.7.0-2] (no packageset)
[23:13] -queuebot:#ubuntu-release- New: rejected ukui-power-manager [source] (bionic-proposed) [1.1.0-0ubuntu1]
[23:13] -queuebot:#ubuntu-release- New binary: ddnet [armhf] (bionic-proposed/universe) [11.0.3-1] (no packageset)
[23:14] -queuebot:#ubuntu-release- New binary: ddnet [arm64] (bionic-proposed/universe) [11.0.3-1] (no packageset)
[23:14] -queuebot:#ubuntu-release- New binary: mbedtls [arm64] (bionic-proposed/universe) [2.7.0-2] (no packageset)
[23:14] -queuebot:#ubuntu-release- New binary: mbedtls [armhf] (bionic-proposed/universe) [2.7.0-2] (no packageset)
[23:15] <xnox> slangasek, could you please process openssl1.0 through new?
[23:16] -queuebot:#ubuntu-release- New: accepted ddnet [amd64] (bionic-proposed) [10.8.6-3]
[23:16] -queuebot:#ubuntu-release- New: accepted ddnet [ppc64el] (bionic-proposed) [10.8.6-3]
[23:16] -queuebot:#ubuntu-release- New: accepted ddnet [arm64] (bionic-proposed) [11.0.3-1]
[23:16] -queuebot:#ubuntu-release- New: accepted ddnet [i386] (bionic-proposed) [11.0.3-1]
[23:16] -queuebot:#ubuntu-release- New: accepted iraf-rvsao [amd64] (bionic-proposed) [2.8.3-1]
[23:16] -queuebot:#ubuntu-release- New: accepted iraf-rvsao [armhf] (bionic-proposed) [2.8.3-1]
[23:16] -queuebot:#ubuntu-release- New: accepted iraf-rvsao [ppc64el] (bionic-proposed) [2.8.3-1]
[23:16] -queuebot:#ubuntu-release- New: accepted jsonrpc-glib [arm64] (bionic-proposed) [3.27.90-1]
[23:16] -queuebot:#ubuntu-release- New: accepted jsonrpc-glib [i386] (bionic-proposed) [3.27.90-1]
[23:16] -queuebot:#ubuntu-release- New: accepted jsonrpc-glib [s390x] (bionic-proposed) [3.27.90-1]
[23:16] -queuebot:#ubuntu-release- New: accepted ddnet [arm64] (bionic-proposed) [10.8.6-3]
[23:16] -queuebot:#ubuntu-release- New: accepted ddnet [armhf] (bionic-proposed) [11.0.3-1]
[23:16] -queuebot:#ubuntu-release- New: accepted iraf-rvsao [arm64] (bionic-proposed) [2.8.3-1]
[23:16] -queuebot:#ubuntu-release- New: accepted jsonrpc-glib [amd64] (bionic-proposed) [3.27.90-1]
[23:16] -queuebot:#ubuntu-release- New: accepted jsonrpc-glib [ppc64el] (bionic-proposed) [3.27.90-1]
[23:16] -queuebot:#ubuntu-release- New: accepted libgeo-shapelib-perl [amd64] (bionic-proposed) [0.22-2]
[23:16] -queuebot:#ubuntu-release- New: accepted libgeo-shapelib-perl [armhf] (bionic-proposed) [0.22-2]
[23:16] -queuebot:#ubuntu-release- New: accepted libgeo-shapelib-perl [ppc64el] (bionic-proposed) [0.22-2]
[23:16] -queuebot:#ubuntu-release- New: accepted libgpiod [armhf] (bionic-proposed) [1.0-1]
[23:16] -queuebot:#ubuntu-release- New: accepted mbedtls [arm64] (bionic-proposed) [2.7.0-2]
[23:16] -queuebot:#ubuntu-release- New: accepted ddnet [amd64] (bionic-proposed) [11.0.3-1]
[23:16] -queuebot:#ubuntu-release- New: accepted iraf-rvsao [i386] (bionic-proposed) [2.8.3-1]
[23:16] -queuebot:#ubuntu-release- New: accepted libgeo-shapelib-perl [amd64] (bionic-proposed) [0.22-1]
[23:16] -queuebot:#ubuntu-release- New: accepted libgeo-shapelib-perl [i386] (bionic-proposed) [0.22-2]
[23:16] -queuebot:#ubuntu-release- New: accepted mbedtls [amd64] (bionic-proposed) [2.7.0-2]
[23:16] -queuebot:#ubuntu-release- New: accepted mbedtls [s390x] (bionic-proposed) [2.7.0-2]
[23:16] -queuebot:#ubuntu-release- New: accepted python3-precis-i18n [amd64] (bionic-proposed) [1.0.0-1]
[23:16] -queuebot:#ubuntu-release- New: accepted ddnet [s390x] (bionic-proposed) [11.0.3-1]
[23:16] -queuebot:#ubuntu-release- New: accepted libgeo-shapelib-perl [arm64] (bionic-proposed) [0.22-2]
[23:16] -queuebot:#ubuntu-release- New: accepted mbedtls [i386] (bionic-proposed) [2.7.0-2]
[23:16] -queuebot:#ubuntu-release- New: accepted texhyphj [amd64] (bionic-proposed) [1.2+dfsg-1]
[23:16] -queuebot:#ubuntu-release- New: accepted jsonrpc-glib [armhf] (bionic-proposed) [3.27.90-1]
[23:16] -queuebot:#ubuntu-release- New: accepted minidb [amd64] (bionic-proposed) [2.0.2-1]
[23:16] -queuebot:#ubuntu-release- New: accepted libgeo-shapelib-perl [s390x] (bionic-proposed) [0.22-2]
[23:16] -queuebot:#ubuntu-release- New: accepted ddnet [s390x] (bionic-proposed) [10.8.6-3]
[23:16] -queuebot:#ubuntu-release- New: accepted libgpiod [arm64] (bionic-proposed) [1.0-1]
[23:16] -queuebot:#ubuntu-release- New: accepted libgpiod [ppc64el] (bionic-proposed) [1.0-1]
[23:16] -queuebot:#ubuntu-release- New: accepted libgpiod [amd64] (bionic-proposed) [1.0-1]
[23:16] -queuebot:#ubuntu-release- New: accepted libgpiod [s390x] (bionic-proposed) [1.0-1]
[23:16] -queuebot:#ubuntu-release- New: accepted libgpiod [i386] (bionic-proposed) [1.0-1]
[23:18] <bdmurray> slangasek: Yes, we just need the version of unity from -proposed
[23:19] <slangasek> xnox: rationale for an openssl1.0 binary package that doesn't seem to exist in Debian?
[23:19] <xnox> slangasek, security team must have openssl1.0 binary for SRU and security regression to support openssl1.0 in main
[23:20] <xnox> slangasek, there is an LP bug linked....
[23:20] <xnox> slangasek, hence i shipped them, non-coflicting, in /usr/lib/ssl1.0/ which should be good enough for security team.
[23:20] <slangasek> xnox: got it, thanks
[23:21] <slangasek> xnox: and I assume there's no requirement to seed this binary package into main
[23:22] -queuebot:#ubuntu-release- New: accepted openssl1.0 [amd64] (bionic-proposed) [1.0.2n-1ubuntu3]
[23:22] -queuebot:#ubuntu-release- New: accepted openssl1.0 [armhf] (bionic-proposed) [1.0.2n-1ubuntu3]
[23:22] -queuebot:#ubuntu-release- New: accepted openssl1.0 [ppc64el] (bionic-proposed) [1.0.2n-1ubuntu3]
[23:22] -queuebot:#ubuntu-release- New: accepted openssl1.0 [arm64] (bionic-proposed) [1.0.2n-1ubuntu3]
[23:22] -queuebot:#ubuntu-release- New: accepted openssl1.0 [s390x] (bionic-proposed) [1.0.2n-1ubuntu3]
[23:22] -queuebot:#ubuntu-release- New: accepted openssl1.0 [i386] (bionic-proposed) [1.0.2n-1ubuntu3]
[23:26] <xnox> slangasek, don't think so.
[23:40] <bdmurray> slangasek: What else needs to happen with the compiz / unity xenial issue?
[23:41] <bdmurray> unity has two unverified bugs
[23:44] <slangasek> bdmurray: under the circumstances, with 20 verified bugs, 2 unverified bugs, and a critical regression, I was inclined to release without verification of the last 2
[23:45] <bdmurray> slangasek: we could test for a regression in bug 1666359 using what is given
[23:47] <slangasek> bdmurray: could; but I think it's better to release the current package now and not block on further verifications
[23:47] <bdmurray> slangasek: okay