[06:09] <ogra_> geez, what happened to ubuntu-image ...
[06:10] <ogra_> spams my $pwd with .manifest files now
[06:39] <slangasek> ogra_: when using -o or -O? (one of these gives you a deprecation warning, precisely because of things such as this)
[06:40] <ogra_> the deprecated one ( -o )
[06:40] <slangasek> yeah
[06:40] <slangasek> if you use -O it'll dump them in the target dir instead
[06:40] <ogra_> ah, right ...
[06:40] <ogra_> well, for test builds i prefer -o ...
[06:40] <slangasek> sure
[06:41] <ogra_> since i have you here ... do you have an idea why vt.handoff= might to not work on core ? (any obvious thing i might be missing  ?)
[06:41] <slangasek> hum
[06:41] <slangasek> define "not work"?
[06:41] <ogra_> i'm playing with adding psplash to a gadget https://github.com/ogra1/pc-splash-gadget/commit/b8ea0f98fb5c3e5dfa40b7ed14a652a43a39458d ...
[06:42] <slangasek> fwiw we are looking to drop it as obsolete in bionic
[06:42] <ogra_> it works fine but i have to hit alt+a cursor key to get a console
[06:42] <ogra_> or have to add a snap that calls chvt on startup
[06:42] <slangasek> what do you expect vt.handoff=1 to do?
[06:42] <slangasek> the default vt is already 1
[06:42] <ogra_> well, i would expect subiquity to take over vt1
[06:42] <ogra_> once it starts
[06:43] <ogra_> but i tried different numbers
[06:43] <slangasek> ok
[06:43] <ogra_> funnily i have the same setup working fine on the arm gadgets
[06:43] <ogra_> and there vt-handoff= DTRT
[06:43] <slangasek> that's interpreted by the kernel, and it's an Ubuntu sauce patch
[06:43] <slangasek> so if something is missing in your kernel?
[06:43] <ogra_> well, this image uses the ps--kernel snap
[06:44] <ogra_> so i'd expect the sauce to be there
[06:44] <ogra_> *pc-kernel
[06:44] <slangasek> ok; not sure then
[06:44] <ogra_> and manually switching tty properly drops the splash ...
[06:44] <ogra_> well, i'll keep digging
[06:45] <ogra_> it is just weird that it works on all the arm images with the same psplash setup ...
[06:46] <ogra_> (i wonder if it is grub then ... handling the framebuffer differently than u-boot )
[07:26] <ginggs> slangasek: thanks for fixing scalapack!
[07:32] <slangasek> ginggs: n/p - clearing out my nag mails for transitions that wouldn't finish ;P
[07:59] <doko> jbicha: I see you last touched dput. would you be able to do the Debian merge?
[08:44] <Phanes> you need to drop wayland until its more developed
[10:58] <doko> willcooke: please could you dedicate some time to http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg  ... the fonts mismatches are there for weeks now
[10:59] <willcooke> doko, ack.  seb128 is this a laney thing? ^
[11:01] <doko> cpaelzer: LP: #1732892, why did you unassign the security team?
[11:04] <seb128> willcooke, it doesn't need to be, doko could fix himself if we wanted, I'm not sure we really own fonts
[11:04] <doko> seb128: you do own that specific font package
[11:04] <seb128> willcooke, it's more a mir/archive admin thing
[11:04] <doko> s/you/desktop/
[11:04] <seb128> doko, if you say so...
[11:05] <seb128> doko, what do you expect us to do? isn't that just archive admin job to promote the new split version?
[11:06] <doko> seb128, willcooke: fonts-smc has desktop as bug subscribers
[11:06] <seb128> right, to the point what do you expect us to do?
[11:06] <seb128> just subscribe that team to the new packages so you can promote them?
[11:06] <doko> seb128: yes, then please file a MIR / archive bug, after you verified that it's a split
[11:06] <seb128> why not just promoting them?
[11:06] <doko> I'm not your archive nanny
[11:06] <seb128> shrug, more useless paper work
[11:07] <seb128> well, I'm not your MIR one
[11:07] <doko> it's not *my* MIR
[11:07] <seb128> adding that to the backlog but it's not likely going to be for this week
[11:07] <seb128> maybe next
[11:07] <seb128> well you are the one asking about it
[11:07] <seb128> it's a split you could just promote the new ones without requiring paperwork
[11:07] <doko> no, I should not ask about it, you should see that yourself
[11:08] <seb128> well you do ask though
[11:08] <seb128> don't next time :)
[11:16] <Nafallo> hey doko. you might be the right person to find out if there are any plans for stop supporting ARMv7 now that ARMv8 is out the door? :-)
[11:17] <cjwatson> Why is it urgent for you to ask that we stop supporting ARMv7?
[11:17] <Nafallo> hey cjwatson :-)
[11:18] <Nafallo> no no. misunderstanding. I was wondering if there was plans in that direction before I invent in hardware...
[11:19] <Nafallo> invest even
[11:24] <cjwatson> Ah.  I've heard the odd rumbling about it but I don't think it's especially imminent?
[11:24] <Nafallo> so we're good for bionic most likely? :-)
[11:27] <cjwatson> bionic is certainly fine
[11:27] <Nafallo> \o/
[11:58] <cpaelzer> doko: you did assign and unassign them in one shot
[11:58] <cpaelzer> doko: then I thought it was a mistake and assigned them again, to realize it might have been intentional
[11:58] <cpaelzer> doko: so I pinged you on that day but got no response and then left it in the state
[11:58] <cpaelzer> essentially my update was an un-educated no-op
[11:59] <cpaelzer> LP log still shows that
[11:59] <cpaelzer> doko: I'm perfectly fine assigning them, I just thought you might have had a reason to unassign them
[12:05] <doko> cpaelzer: ok, reassigned. that matches at least my comment. ta
[14:01] <xnox> pitti, cockpit avocado tests started to fail https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-bionic/bionic/s390x/c/cockpit/20171127_183415_2e5fa@/log.gz
[14:01] <xnox> pitti, possibly systemd 235 related, as they did previously pass just fine (in nova s390x)
[14:01] <pitti> xnox: I know; I already removed them upstream, next release will drop them
[14:02] <xnox> pitti, oh, ok.
[14:02] <xnox> pitti, were they not really doing anything?
[14:02] <pitti> the smoke test is much smaller and more robust
[14:02] <xnox> ack.
[14:02] <pitti> and the avocado one has always been unstable, and the phantom part has been broken for a long time (and failures ignored)
[14:12] <jbicha> doko: my upload of dput was just a drive-by to fix a bug, you're welcome to do the merge if you like
[14:44] <jbicha> Ubuntu 17.10 installs kerneloops-applet by default, but is that intentional?
[14:45] <jbicha> one particular problem is that it is gtk2 and we should not be adding gtk2 apps to the default install any more
[14:48] <jbicha> rbalint: hi, kerneloops maintainer :)
[14:51] <rbasak> xnox: do you expect bug 1691096 to still affect sid? I just hit it there.
[14:51] <rbasak> If that's unexpected I can investigate further.
[15:39] <juliank> slangasek: I just uploaded a new gnu-efi to experimental. Apparently that breaks some API. I'm not sure of the details involving shim and friends and backporting of them and what breaks builds, I plan to just copy them all into https://launchpad.net/~juliank/+archive/ubuntu/gnu-efi-staging once it's available in launchpad and see what happens. I thought you might want to know and/or know something I should look out for.
[15:39] <juliank> bah, that was a long message
[16:07] <rbalint> jbicha: hi :-)
[16:08] <jbicha> rbalint: did you see my question about installing kerneloops-applet by default?
[16:09] <rbalint> jbicha: yes, i was not involved in that
[16:11] <rbalint> jbicha: rewriting to gtk3 is not something i can realistically do in the near future :-(
[16:12] <rbalint> jbicha: while i did not look at the complexity of the task yet
[16:13] <jbicha> what does kerneloops-applet even do? do you think it needs to be installed by default for Ubuntu desktop?
[16:36] <rbalint> jbicha: it asks for confirmation to send oopses to oops.kernel.org or via apport
[16:38] <jbicha> bdmurray: good morning, do you have an opinion on kerneloops-applet? ^
[16:39] <rbalint> jbicha: well, it collects valuable information for kernel devs who may fix oopses faster but there is never immedeate need for that
[16:39] <slangasek> juliank: are you familiar with UEFI testing in VMs?  cyphermox might be able to give you pointers to useful documentation, though you don't even need to enable Secure Boot to smoketest shim
[16:40] <bdmurray> jbicha: I'd check with the kernel team to see if they use the OOPSes. I believe they aren't being sent anywhere now and they have not complained...
[16:41] <rbalint> jbicha: do you think it should not be shipped or you don't like it being shipped only because of not being gtk3?
[16:42] <juliank> slangasek: I sometimes boot one of my disks in a VM in UEFI mode, but I don't do much testing of UEFI stuff :)
[16:42] <jbicha> kerneloops-applet also shows up in Startup Applications (which is pretty trivial to fix)
[16:45] <jbicha> I don't know how useful it is, but having anything in bionic's default install requiring gtk2 is a serious bug in my opinion (except maybe mozilla), see LP: #1585903
[16:45] <juliank> slangasek: I expect it's most likely just build failures anyway :)
[16:46] <slangasek> quite possible
[16:46] <juliank> IIRC, gnu-efi needs to be backported to older releases, and I figured there might be trouble there.
[16:47] <slangasek> right, in principle we want the source for the shim-signed binary that we binary-copy backwards to be present in each release
[16:47] <juliank> But they are not really uploaded AFAICT
[16:49] <juliank> In the worst case we could just rename it gnu-efi-shim or whatever for older releases
[16:49] <juliank> So it does not disturb other reverse deps :)
[16:49] <slangasek> we would also have to change the package build-deps in dev to match this
[16:50] <juliank> indeed
[17:10] <rbalint> jbicha: having kerneloops-applet seems to be a minor mistake in https://launchpad.net/ubuntu/+source/ubuntu-meta/1.392
[17:10] <rbalint> jbicha: only kerneloops-daemon should have been added that talks to apport
[17:11] <rbalint> jbicha: and pulls nothing from gtk2
[17:13] <jbicha> rbalint: Debian's kerneloops recommends kerneloops-applet ;) this issue appeared in 17.10 after a merge from Debian
[17:14] <rbalint> jbicha: in xenial ubuntu-desktop depends only on kerneloops-daemon
[17:14] <jbicha> https://launchpad.net/ubuntu/+source/kerneloops/0.12+git20140509-6ubuntu1
[17:15] <rbalint> jbicha: ah, indeed
[17:15] <rbalint> jbicha: i forgot about that
[17:16] <rbalint> jbicha: suggests would be enough
[17:16] <jbicha> rbalint: do you want to do that then? ;)
[17:17] <rbalint> jbicha: yes, i'm in the process of merging kerneloops' delta from Ubuntu to Debian
[17:17] <rbalint> jbicha: anyway
[17:17] <jbicha> great, thanks
[17:17]  * rbalint needs to go afk for some time
[17:17] <jbicha> I don't know if we'll be able to completely drop gtk2 from default install for bionic, but we're making some progress :)
[17:19]  * cjwatson needs to finish the gtk3 branch of debconf
[17:19] <cjwatson> It mostly didn't seem very hard, but there was something wrong with the result, I forget exactly what
[17:38] <cyphermox> ah?
[17:38] <cyphermox> the format of the wizard?
[17:38] <cyphermox> well, look I guess
[17:38] <cyphermox> rather than "format"
[17:50] <cjwatson> something like that, I'll need to try it again to see
[17:51] <cyphermox> I remember when I did my porting attempt the issue was that the new wizard format from GTK3 looked kind of odd to me; but it's just my opinion, based on my relatively limited GTK skills.
[17:51] <cyphermox> not sure if you re-did the whole thing since then :)
[22:24] <xnox> rbasak, the keyring bug is only fixed in ubuntu; and the bug fix so far has been rejected (and reworked) multiple times upstream.
[22:47] <LocutusOfBorg> jbicha, please steal gtk+2.0 from me?
[23:12] <jbicha> LocutusOfBorg: it's on my todo list, I'm working on gtk2 depends issues
[23:13] <LocutusOfBorg> ;)
[23:13] <LocutusOfBorg> thanks!