[00:02] <tsimonq2> cyphermox: Totally unsure >_<
[00:02] <tsimonq2> cyphermox: I'll find that out...
[00:04] <tsimonq2> cyphermox: Also, I'm going to have to have a look at getting us a Qt slideshow that isn't completely Kubuntu branded >_<
[00:04] <tsimonq2> cyphermox: s/slideshow/ubiquity/
[00:05] <cyphermox> tsimonq2: Qt shouldn't mean that the slideshow is kubuntu branded
[00:07] <cyphermox> in any case, that would be in ubiquity
[00:08] <tsimonq2> cyphermox: Hm, let's see which packages are in the seed for lubuntu-next live...
[00:09] <cyphermox> bbl, it's an ice cream break.
[00:11] <tsimonq2> !info ubiquity-frontend-kde
[00:11] <ubot5> ubiquity-frontend-kde (source: ubiquity): KDE frontend for Ubiquity live installer. In component universe, is optional. Version 17.04.9 (zesty), package size 66 kB, installed size 536 kB
[00:11] <tsimonq2> Ah, ok, so it is part of ubiquity. Got it.
[00:12] <ahoneybun> yep tsimonq2
[00:12] <ahoneybun> blaze and I fixed it a release or two ago
[00:13] <ahoneybun> when PyQt4 dropped webkit
[00:13] <ahoneybun> so we moved it to PyQt5
[00:13] <tsimonq2> ahoneybun: Mind if I fork?
[00:13] <ahoneybun> it's not mine
[00:13] <ahoneybun> fork what?
[00:13] <tsimonq2> ahoneybun: Or maybe move to a common base that Kubuntu and Lubuntu Next can just share?
[00:13] <tsimonq2> The Qt part of the ubiquity frontend.
[00:13] <ahoneybun> I'm not sure what you mean
[00:13] <ahoneybun> ohhh
[00:13] <tsimonq2> Yeah :)
[00:14] <ahoneybun> fork it I guess
[00:14] <ahoneybun> but ubiquity provides the main UI on the side with the progress
[00:14] <tsimonq2> Yeah
[00:14] <ahoneybun> the progress bar on the bottom is that -kde frontend
[00:14] <ahoneybun> the slides are ubiquity-slideshow-ubuntu
[00:15] <tsimonq2> ahoneybun: Are there KDE Frameworks libraries used?
[00:15] <tsimonq2> Oh, doesn't look like it?
[00:15] <tsimonq2> In that case we can make something work.
[00:16] <ahoneybun> it's just python I think
[00:16] <tsimonq2> Yay!
[00:16] <ahoneybun>  /ubiquity/artful/ubiquity/frontend
[00:17] <ahoneybun> kep
[00:17] <ahoneybun> kde_ui.py
[00:17] <tsimonq2> Oh bah, there is KDE frameworks in there...
[00:17] <tsimonq2> Ugh
[00:17] <ahoneybun> where?
[00:17] <tsimonq2> from ubiquity.frontend.kde_components import ProgressDialog
[00:17] <tsimonq2> from ubiquity.frontend.kde_components.Breadcrumb import Breadcrumb
[00:17] <tsimonq2> from ubiquity.frontend.kde_components import qssutils
[00:17] <tsimonq2> In kde_ui.py
[00:17] <ahoneybun> most likely KDE4 stuff
[00:18] <ahoneybun> nah
[00:18] <ahoneybun> Qt5 now
[00:18] <ahoneybun> I mean you should just need to hook inot the kde qt frontend
[00:19] <tsimonq2> I'll try getting a minimal LXD container and just installing that package and seeing what mess it pulls in.
[00:19] <tsimonq2> If it pulls in three quarters of all KDE Frameworks then I'm noping out and rewriting it :P
[00:19] <ahoneybun> well the frameworks should be small now
[00:20] <ahoneybun> well in small pieces lol
[00:20] <ahoneybun> just be happy your not the first Qt based distro tsimonq2
[00:20] <ahoneybun> then it would be worse
[00:20] <tsimonq2> Yeah lol
[00:21]  * ahoneybun has a new domain
[00:22] <tsimonq2> :D
[00:22] <ahoneybun> and they gave me a long IP for this new linode
[00:22] <ahoneybun> damn it
[00:23] <ahoneybun> I want an .xyz domain
[01:03] <cyphermox> tsimonq2: all you really should have to do is remove obvious branding that is directly in ubiquity for the "KDE UI" which is really just a pretty standard Qt GUI, and in doing so no fork but just making things customizable (there should be plenty of examples of generic stuff in the Gtk sections)
[01:04] <cyphermox> also, might I suggest not using the Qt GUI if possible, unless you plan on spending a lot of time on it, it's definitely not as well tested as the rest (fewer users, it needs some work for other issues that were noticed)
[01:05] <tsimonq2> cyphermox: Then what would we use if not the Qt GUI?
[01:05] <tsimonq2> I don't want to include a bunch of GTK libraries just to run Ubiquity...
[01:05] <cyphermox> I mean, it's *important* that it works, for whomever wants to use it, but there are few people looking at ubiquity regularly... and by few I mean mostly just me, maybe xnox, and possibly infinity?
[01:06] <cyphermox> if you have time to hack on the Qt GUI to make it real solid, by all means :)
[01:06] <xnox> yes, i do.
[01:06] <cyphermox> xnox: yeah, but it's not your main focus
[01:06] <xnox> tsimonq2, did you fall into the trap of not specifying which frontend you want?
[01:06] <cyphermox> xnox: no, they actually want Qt.
[01:07] <cyphermox> I'm just expressing my concern for the Qt GUI not being as well tested so far, because it's only used by Kubuntu
[01:07] <xnox> tsimonq2, i believe there is qt4, qt5 frontends, but both are /kde/ frameworks based. I believe there was a QML frontend in progress, not sure if it is merged or not.
[01:07] <tsimonq2> xnox: :/
[01:07] <cyphermox> there is?
[01:07] <xnox> a pure QML kdeframeworkless frontend would be nice.
[01:07] <cyphermox> afaik it's all only Qt5.
[01:08] <cyphermox> xnox: none of ubiquity requires KDE really, AFAIK
[01:08] <xnox> there was a branch by somebody either on launchpad, or something werid like a tarball import on github.
[01:08] <tsimonq2> xnox: That would be my end goal, here.
[01:08] <xnox> taking kde frontend as a starting point and moving that to qml would be a way forward.
[01:08] <xnox> unless you somehow can google up previous efforts of the same.
[01:09] <xnox> a QML subiquity frontend would be awesome too ;-)
[01:09] <tsimonq2> xnox: You mean sub-iquity?
[01:09]  * tsimonq2 is a "super big fan" of the naming choice on that one :P
[01:10] <xnox> yeah, new iteration of installer tech, based on cloud/maas experience. subiquity = server ubiquity
[01:10] <tsimonq2> xnox: But yeah, I'll probably use that as my starting point though.
[01:10] <cyphermox> xnox: that would probably be a major undertaking, it's *not at all* the same thing as the usual desktop installer.
[01:11] <xnox> sure.
[01:11] <tsimonq2> Soooo it's sub-iquity then? :D
[01:11] <xnox> tsimonq2, so looking at ubiquity kde frontend it is pure qt so far.
[01:12] <tsimonq2> xnox: Excellent! But does it depend on KDE Frameworks?
[01:12] <xnox> the bits that say from ubiquity.frontend.kde_components are the custom /ubiquity/ widgets for Qt.
[01:12] <xnox> so should not need any KDE frameworks.
[01:12] <cyphermox> nope.
[01:12] <cyphermox> maybe ksmserver, whatever that is
[01:13] <cyphermox> probably easy enough to make optional.
[01:13]  * xnox wonders if i'm looking at old xenial qt4 build though, one second
[01:13] <cyphermox> xnox: don't worry, there isn't much to look at; I have an up to date branch here.
[01:13] <xnox> curently requires kde-window-manager but that's probably because the ubiquity-dm is not ported to not use that.
[01:13] <xnox> tsimonq2, you may want to fix that ^
[01:14] <xnox> there are no dependeinds declared on kdeframework anything
[01:14] <xnox> ubiquity-dm is the only thing that call into kde, and should be ported to support whatever LXQT wants.
[01:15] <tsimonq2> xnox: Yeah, it was recently ported to Qt 5.
[01:15] <cyphermox> tsimonq2: short story, don't hesitate to ask on #ubuntu-installer if you have questions
[01:15] <tsimonq2> cyphermox: OK :)
[01:16] <cyphermox> xnox or I can answer :)
[01:16] <tsimonq2> I wonder how easy it would be to have some common Qt libraries between Lubuntu LXQt and Kubuntu and just have some elements customized...
[01:17] <cyphermox> tsimonq2: at first glance you have almost nothing to do; but I haven't seen your new image, you mentioned there was some stray branding from kubuntu.
[01:18] <cyphermox> tbf, there probably should not be any branding in ubiquity directly, that belongs to the theming, $flavour-default-settings, u-slideshow-$flavour and whatnot
[01:20] <tsimonq2> cyphermox: tl;dr, on a system with a wired connection, boot the image into "Try Without Installing," Click OK when it gets to the X error, then right-click and select the terminal emulator. Then run ubiquity from there, and you'll see what I'm talking about irt.
[01:20] <tsimonq2> s/irt/irt this/
[01:21] <cyphermox> ok
[01:21] <tsimonq2> I did it in virt-manager, but ymmv
[01:22] <cyphermox> oh boy, this is doing to take a while to download
[01:22] <tsimonq2> Yeeeah, hopefully in the future we'll slim that down... :P
[01:22] <cyphermox> it's not about that, somehow my tubes are slow
[01:23] <cyphermox> I will let it download, and catch up on it / on scrollback tomorrow morning.
[01:24] <cyphermox> tsimonq2: if you figure it in the meantime I'll be happy to review and merge a MP.
[01:25] <tsimonq2> cyphermox: ack :)
[01:53] <ahoneybun> any branding is done with a kubuntu.svg file in ubiquity
[01:53] <ahoneybun> just add the lubuntu one, make a change to one line and done
[01:53] <ahoneybun> tsimonq2: ^
[01:54] <tsimonq2> ahoneybun: ack :P
[02:04] -queuebot:#ubuntu-release- Unapproved: thunar (zesty-proposed/universe) [1.6.11-1 => 1.6.11-1ubuntu0.17.04.1] (mythbuntu, xubuntu)
[02:09] -queuebot:#ubuntu-release- Unapproved: thunar (yakkety-proposed/universe) [1.6.11-0ubuntu0.16.10.1 => 1.6.11-0ubuntu0.16.10.2] (mythbuntu, xubuntu)
[02:10] -queuebot:#ubuntu-release- Unapproved: thunar (xenial-proposed/universe) [1.6.11-0ubuntu0.16.04.1 => 1.6.11-0ubuntu0.16.04.2] (mythbuntu, xubuntu)
[02:42] -queuebot:#ubuntu-release- Unapproved: xfce4-weather-plugin (xenial-proposed/universe) [0.8.6-1 => 0.8.9-0ubuntu0.16.04.1] (ubuntustudio, xubuntu)
[10:19] -queuebot:#ubuntu-release- New source: python-pypowervm (artful-proposed/primary) [1.1.4-0ubuntu1]
[10:50] <ginggs> r-base is ready to migrate except for r-cran-spatstat on armhf and s390x http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#r-base i tried running it in lxc on amd64 locally, and it failed the first time, but not the 2nd time when i added -s . any ideas please?
[10:53] <alan_g> I'm trying to update the version of mir in 16.04 (SRU bug 1685186): it's reached minimum age in -proposed. Can we please proceed to -updates?
[10:53] <ubot5> bug 1685186 in mir (Ubuntu) "[SRU] Mir needs to be updated to 0.26 in 16.04LTS" [High,In progress] https://launchpad.net/bugs/1685186
[11:10] <apw> alan_g, this seems to leave xenial with a newer version than in well everything after, thats not good for an upgrade perspective
[11:12] <alan_g> apw: next on my list is 0.27 for artful. You're concerned with zesty though?
[11:13] <apw> alan_g, the rules are concerned with all releases, they say you can't have a version in xenial that is higher than yakkety etc
[11:13] <apw> alan_g, not actually sure how this got accepted into -proposed as things stand
[11:14] <apw> tjaalton, ^^ ?
[11:19] <alan_g> So, we'd need to release a 0.26.4 version on yakkety and zenial? (0.26.3 has been tweaked to build for xenial, so that would need reverting)
[11:22] <Laney> ginggs: Let's skip those
[11:23] <apw> alan_g, well something with a version number higher than that in xenial would be the norm yes; for y z and a.  unless you have some kind of exception i am unaware of (and i could be)
[11:23] <ginggs> Laney: thanks
[11:38] <alan_g> How would I go about justifying an exception?
[11:39] <alan_g> The way we get here is that the 0.26 series was used for xenial+overlay and that was used for IoT projects on Ubuntu Core. We want to drop "overlay" now but maintain the same Mir support.
[11:40] <apw> alan_g, it is not clear how this would be possible without truly breaking updates, but you are LTS oriented; slangasek ^ ?
[11:47] <alan_g> Updating zesty from 0.26.2 to 0.26.4 would be simple enough. Yakkety was on an earlier series, so that would cause some issues.
[11:49] <alan_g> But the only people I think might care are UbuntuCore users that need "kiosk", or developers who I don't expect to be targeting yakkety.
[11:50] <jbicha> alan_g: technically, if you are not in a hurry and don't want to update Yakkety, then you could just wait until July when Yakkety is EOL
[11:51] <jbicha> but I think all that's being asked for now is that Yakkety has a higher version number than Xenial so that upgraders don't have a package newer than what is available in the archives
=== alan_g is now known as alan_g|lunch
[12:10] -queuebot:#ubuntu-release- Unapproved: rejected isc-dhcp [source] (trusty-proposed) [4.2.4-7ubuntu12.10]
[12:24] <slashd> rbasak, uploaded
[12:24] <rbasak> ack
[12:24] -queuebot:#ubuntu-release- Unapproved: isc-dhcp (trusty-proposed/main) [4.2.4-7ubuntu12.9 => 4.2.4-7ubuntu12.10] (core)
[12:27] -queuebot:#ubuntu-release- Unapproved: accepted isc-dhcp [source] (trusty-proposed) [4.2.4-7ubuntu12.10]
[12:29] -queuebot:#ubuntu-release- Unapproved: accepted isc-dhcp [source] (xenial-proposed) [4.3.3-5ubuntu12.7]
[12:33] -queuebot:#ubuntu-release- New binary: isc-dhcp [i386] (trusty-proposed/main) [4.2.4-7ubuntu12.10] (core)
[12:34] -queuebot:#ubuntu-release- New binary: isc-dhcp [ppc64el] (trusty-proposed/main) [4.2.4-7ubuntu12.10] (core)
[12:34] -queuebot:#ubuntu-release- New binary: isc-dhcp [powerpc] (trusty-proposed/main) [4.2.4-7ubuntu12.10] (core)
[12:35] -queuebot:#ubuntu-release- New binary: isc-dhcp [amd64] (trusty-proposed/main) [4.2.4-7ubuntu12.10] (core)
[12:41] -queuebot:#ubuntu-release- New binary: isc-dhcp [armhf] (trusty-proposed/main) [4.2.4-7ubuntu12.10] (core)
[12:42] -queuebot:#ubuntu-release- New binary: isc-dhcp [arm64] (trusty-proposed/main) [4.2.4-7ubuntu12.10] (core)
[12:44] <rbasak> slashd: ^ you may need to track down an archive admin to accept from NEW.
[12:45] <slashd> rbasak, https://launchpad.net/~ubuntu-archive ???
[12:45] <rbasak> Yep
[12:46] <slashd> rbasak, ack will do
[12:46] <rbasak> slashd: https://launchpad.net/ubuntu/trusty/+queue
[12:48] <slashd> sil2100, the SRU that rbasak just approved is introducing ^ a new binary pkg --> https://launchpad.net/ubuntu/trusty/+queue. Could you please accept the new binary in the archive ?
[12:49] <sil2100> slashd: hey! Sadly my AA privilages only allow to take care of kernel related packages - I guess you'd have to poke a real AA like apw ^
[12:50] <slashd> apw ^^ could you please have a look at this request ^ ?
[12:50] <slashd> tks sil2100
=== alan_g|lunch is now known as alan_g
[13:00] <cyphermox> rbasak: could you please reject my nplan from the xenial queue? I just realized it's missing -v
[13:08] <rbasak> ack
[13:09] -queuebot:#ubuntu-release- Unapproved: rejected nplan [source] (xenial-proposed) [0.22~16.04.1]
[13:27] <cyphermox> rbasak: ta
[13:29] -queuebot:#ubuntu-release- New: accepted isc-dhcp [amd64] (trusty-proposed) [4.2.4-7ubuntu12.10]
[13:29] -queuebot:#ubuntu-release- New: accepted isc-dhcp [armhf] (trusty-proposed) [4.2.4-7ubuntu12.10]
[13:30] -queuebot:#ubuntu-release- New: accepted isc-dhcp [powerpc] (trusty-proposed) [4.2.4-7ubuntu12.10]
[13:30] -queuebot:#ubuntu-release- New: accepted isc-dhcp [arm64] (trusty-proposed) [4.2.4-7ubuntu12.10]
[13:30] -queuebot:#ubuntu-release- New: accepted isc-dhcp [ppc64el] (trusty-proposed) [4.2.4-7ubuntu12.10]
[13:30] -queuebot:#ubuntu-release- New: accepted isc-dhcp [i386] (trusty-proposed) [4.2.4-7ubuntu12.10]
[13:30] <apw> slashd, ^
[13:30] -queuebot:#ubuntu-release- Unapproved: nplan (xenial-proposed/universe) [0.21~16.04.1 => 0.22~16.04.1] (no packageset)
[14:09] <slashd> apw, thanks
[15:52] -queuebot:#ubuntu-release- Unapproved: accepted linux-firmware [source] (xenial-proposed) [1.157.11]
[16:12] -queuebot:#ubuntu-release- Unapproved: util-linux (zesty-proposed/main) [2.29-1ubuntu2 => 2.29-1ubuntu2.1] (core)
[16:14] -queuebot:#ubuntu-release- Unapproved: util-linux (yakkety-proposed/main) [2.28.2-1ubuntu1.1 => 2.28.2-1ubuntu1.2] (core)
[16:16] -queuebot:#ubuntu-release- Unapproved: util-linux (xenial-proposed/main) [2.27.1-6ubuntu3.2 => 2.27.1-6ubuntu3.3] (core)
[16:37] <bdmurray> cyphermox: How did you verify bug 1680279?
[16:37] <ubot5> bug 1680279 in shim-signed (Ubuntu Yakkety) "attach secureboot state files to shim-signed apport reports" [Undecided,Fix committed] https://launchpad.net/bugs/1680279
[16:37] <bdmurray> cyphermox: specifically how did you review the report?
[17:31] <cyphermox> bdmurray: I can generate a crash file, and look in to see if we have a value for the two variables (SecureBoot-* and MokSBStateRT-*)
[17:32] <cyphermox> the fact that the value is an unprintable character isn't too much an issue (we can "decipher" that, but just knowing that the files are there or not helps a lot already)
[17:34] <bdmurray> cyphermox: You viewed the .crash in /var/crash with a text editor or something? Was it not apport-gtk's dialog?
[17:34] <cyphermox> as I remember I went to vi the .crash file in /var/crash.
[17:38] <bdmurray> Maybe we should let slangasek decide since he did the SRU work
[17:39] <bdmurray> cyphermox: Also might these files not exist? there is attach_file_if_exists() instead of attach_file()
[17:39] <cyphermox> yes, at least MokSBStateRT can be absent
[17:41] <slangasek> fwiw when I was testing this I used apport-gtk's dialog
[17:43] <bdmurray> And did you choose not to use attach_file_if_exists()?
[17:47] <bdmurray> It won't cause a problem as apport will carry on, it'll just be extra baggage with the bug.
[18:00] <bdmurray> Oh, I guess its okay
[18:01] <bdmurray> Error: [Errno 2] No such file or directory: '/sys/firmware/efi/efivars/MokSBStateRT-605dab50-e046-4300-abb6-3dd810dd8b23'
[18:09] <bdmurray> slangasek: is the fact that its an unprintable character an issue?
[18:21] <slangasek> bdmurray: the 'no such file or directory' messages are actually useful information to me, it shows a recent enough version of the hook was run and found nothing
[18:21] <slangasek> bdmurray: the unprintable character is an issue, but IMHO having unprintable character is better than nothing
[18:22] <slangasek> and I told cyphermox I wasn't going to be working on the unprintable character problem any time soon, which was why he switched from v-failed to v-done
[18:23] <bdmurray> slangasek: okay, cool
[18:25] <cyphermox> ^that. unprintable character is better than nothing, as just existence already give you all you need for the MokSBStateRT case anyway (it's either there or not)
[18:27] <bdmurray> Sure it just seems like you could store this information as a boolean e.g. MokSBStateRtExists: True and it'd be cleaner.
[18:28] <slangasek> bdmurray: for most of them we do care about the content, and it is possible if inconvenient to extract that info from the unprintable character IIRC
[18:28] <slangasek> ultimately I want the content
[18:42] <bdmurray> slangasek: Understood.
[18:44] <bdmurray> Bug 1659618 mentions a kexec-tools SRU ftbfs on armhf but that's not showing up on the pending-sru report...
[18:44] <ubot5> bug 1659618 in kexec-tools (Ubuntu Yakkety) "Enable ARM64 support in kexec-tools" [High,Fix committed] https://launchpad.net/bugs/1659618
[18:44] <bdmurray> I see some other ftbfs on the report.
[18:54] <slangasek> bdmurray: under yakkety I see 'kexec-tools armhf: Failed to build', is that not what you're talking about?
[18:59] <bdmurray> slangasek: I'm talking about 1:2.0.10-1ubuntu2.1 for xenial which FTBFS but come to find out there is an even newer version in xenial which isn't in the bug comments at all.
[19:00] <slangasek> ok
[19:01] <bdmurray> So while I was looking at the wrong package version an SRU team member didn't comment on the bug when accepting the new version in.
[19:02] <bdmurray> That should have flipped the tags for xenial too.
=== mcasadevall is now known as NCommander
[20:18] -queuebot:#ubuntu-release- Unapproved: grub2 (artful-proposed/main) [2.02~beta3-4ubuntu4 => 2.02~beta3-4ubuntu4] (core)
[20:40] -queuebot:#ubuntu-release- Unapproved: grub2 (artful-proposed/main) [2.02~beta3-4ubuntu4 => 2.02~beta3-4ubuntu4] (core)
[21:40] <gaughen> cyphermox, would you have a look at this MIR request please - https://bugs.launchpad.net/ubuntu/+source/vine/+bug/1688091
[21:40] <ubot5> Ubuntu bug 1688091 in vine (Ubuntu) "[MIR] vine" [High,New]
[21:40] <cyphermox> sure
[21:43] <gaughen> thank you cyphermox!
[21:44] <jbicha> cyphermox: and LP: #1686726 too?
[21:44] <ubot5> Launchpad bug 1686726 in gnome-getting-started-docs (Ubuntu) "[MIR] gnome-getting-started-docs" [High,Triaged] https://launchpad.net/bugs/1686726
[21:54] <bdmurray> tjaalton: Why was mir accepted in xenial-proposed when it doesn't seem to be fixed in Artful and the version number will be greater than any other release?