[08:04] <andrewsh> jbicha: you upload 1.11-2ubuntu1 of redshift somehow removes the ubuntu-mono-light/dark icons
[08:04] <andrewsh> your*
[08:05] <andrewsh> and that's despite the changelog entry saying it still has --enable-unity enabled
[08:06] <andrewsh> hmmm, the diff shows s,--enable-ubuntu,--enable-unity,; is that right?
[08:07] <Unit193> -	dh_auto_configure -- --enable-randr --enable-vidmode --enable-geoclue2 --disable-geoclue --with-systemduserunitdir=/usr/lib/systemd/user/ --enable-ubuntu
[08:07] <Unit193> +	dh_auto_configure -- --enable-randr --enable-vidmode --enable-geoclue2 --disable-geoclue --with-systemduserunitdir=/usr/lib/systemd/user/ --enable-unity
[08:07] <Unit193>  Yep.
[08:07] <andrewsh> that doesn’t seem correct to me
[08:07] <andrewsh> since --enable-ubuntu did install the icons, and --enable-unity doesn't (does that work at all?)
[08:08] <Unit193> You'll also note the changelog disappeared.
[08:08] <andrewsh> AC_ARG_ENABLE([ubuntu], [AC_HELP_STRING([--enable-ubuntu],
[08:09] <Unit193> configure: WARNING: unrecognized options: --disable-maintainer-mode, --enable-unity
[08:10] <andrewsh> actually, I think ritesh could just enable it in Debian
[13:05] <cyphermox> MIR team ping; doko, didrocks, jdstrand: do we meet this week?
[13:06] <didrocks> cyphermox: nothing to say apart from "done Vulkan MIR, still work needed"
[13:06] <cyphermox> yeah, I'm not done with mine.
[13:06]  * jdstrand is here and has nothing to report
[13:07] <cyphermox> there are two bugs open, but I'll take ledmon (I have prior context on it)
[13:08] <cyphermox> let's skip then
[13:08] <didrocks> k
[13:08] <jdstrand> +1
[13:09] <jdstrand> I was actually wondering if every other week might make more sense
[13:09] <jdstrand> but meeting and adjourning quickly is fine too
[14:39] <seb128> LocutusOfBorg, hey! Do you know if something changed in cosmic for virtualbox/the vboxvideo driver that could explain https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1792932 (live CD failing to boot to a working session under virtualbox)
[14:39] <seb128> tjaalton, ^ moving the discussion here
[14:41] <tjaalton> k
[15:06] <seb128> vorlon, do you know who could help tjaalton to figure out if something change on the initramfs side in cosmic that would impact the vboxvideo driver? that's the bug just mentioned before which is a blocker for cosmic but we are failing at getting traction/understanding of the issue, seems the vboxdriver is taking too long to init and tjaalton thinks that might be because it's missing from the installed initrd
[15:09] <tjaalton> having it there might help, but it's never been on the installer initrd afaik
[15:09] <seb128> ah
[15:09] <seb128> I probably misunderstood, I though you said that was changed/explained it was taking to long to init
[15:09] <xnox> blame kernel? =)
[15:10] <seb128> tjaalton, so was the driver init faster in bionic? or boot slower? or did we just get lucky?
[15:10] <tjaalton> something changed that makes it racy now
[15:10] <seb128> I'm a bit unsure what changed/what you think is creating the issue now
[15:10] <tjaalton> I'll test on another machine with I can use to test this..
[15:10] <seb128> k, thx
[15:11] <seb128> let me know if we can help with something
[15:11] <LocutusOfBorg> apw, are you using vboxvideo inside the kernel?
[15:11] <tjaalton> the window of failure is only a few seconds, and something either made X quicker to start or vboxvideo slower to init, or both
[15:11] <LocutusOfBorg> ^^ which version? did you sync it to 5.2.18?
[15:11] <LocutusOfBorg> tjaalton, now vboxvideo is a kernel module, not sure how it can take seconds to boot
[15:11] <xnox> isn't this a general gdm fails to init on boot, sometimes?
[15:11] <LocutusOfBorg> but... installing virtualbox-guest-x11 makes it work?
[15:11] <xnox> or like you mean you don't get plymouth either?
[15:11] <tjaalton> LocutusOfBorg: takes > 25s
[15:12] <LocutusOfBorg> because I do something more on that package, wrt a normal kernel module
[15:14] <tjaalton> LocutusOfBorg: after first reboot it works, because the kernel module is already loaded before X starts
[15:20] <LocutusOfBorg> no real idea... seems not really vbox related?
[15:22] <tjaalton> I'll compare bionic/debian/cosmic..
[15:45] <LocutusOfBorg> sforshee, https://irclogs.ubuntu.com/latest/%23ubuntu-devel.html
[15:45] <LocutusOfBorg> it will update with some new messages
[15:45] <LocutusOfBorg> tjaalton, the kernel vboxvideo is now mainline, so they aren't using the vbox provided anymore
[15:46] <LocutusOfBorg> is it possible to have a spin with the vbox provided one, or a custom kernel so we know if this is the cause?
[15:46] <tjaalton> LocutusOfBorg: it's in staging
[15:48] <LocutusOfBorg> tjaalton, exactly
[15:48] <LocutusOfBorg> so this is the upstream one
[15:49] <LocutusOfBorg> tjaalton, as said, install virtualbox-guest-dkms and reboot
[15:49] <LocutusOfBorg> and tell me which one is used, and if it works
[15:49] <tjaalton> it's fine after the system is installed
[15:49] <tjaalton> only the installer instance is broken
[15:51] <LocutusOfBorg> so, seed vbox-guest-dkms or a custom kernel that sforshee can provide you? is it possible?
[15:51] <sforshee> will using the driver from virtualbox-guest-dkms even make a difference? Seems like this is a problem of when the device is ready
[15:52] <tjaalton> yeah I don't think it would
[15:54] <tjaalton> looks like bionic image on vbox just hangs if I click "show apps"
[15:55] <tjaalton> so it's not exactly bug free there either :)
[15:59] <tjaalton> and second/third attempt shows just a corrupt screen afte X has loaded
[16:00] <coreycb> RAOF: hi, can you reject keystone from the xenial unapproved queue? I need to learn how to use dput.
[16:10] <smoser> what is the right tag for verification on bionic for
[16:10] <smoser>  https://bugs.launchpad.net/ubuntu/xenial/+source/cloud-initramfs-tools/+bug/1792905
[16:10] <smoser> right now
[16:10] <smoser> basically, 2 independently functioning fixes are in -proposed for bionic.
[16:10] <smoser> i've verified one of them.
[16:11] <smoser> i do not want to hold up this SRU at all as we really need an image built with *either* of the fixes.
[16:32] <tjaalton> LocutusOfBorg, sforshee: debian testing (4.18) has vboxvideo loaded in 5-6s, compared to 25-30s in cosmic. it's not in initrd there either
[16:32] <sforshee> hmm
[16:33] <tjaalton> this is the live image
[16:33] <tjaalton> on both
[16:34] <sforshee> it's not like there are any driver-specific options that might be different, it's just enabled or disabled
[16:34] <sforshee> tjaalton: can you provide a dmesg from both? Maybe there will be some clues there
[16:37] <tjaalton> sforshee: yeah I'll try..
[16:48] <tjaalton> sforshee: oh, there's an error about module verification, could that be it?
[16:48] <tjaalton> anyway, I'll dump these somewhere..
[16:51] <tjaalton> sforshee: https://aaltoset.kapsi.fi/vbox-slow/
[17:00] <tjaalton> well, on bionic it's still slow but xserver doesn't fail the same way
[17:00] <sforshee> tjaalton: there's certainly something weird, a couple of big delays that account for most of the difference but nothing in dmesg tells me why
[17:01] <sforshee> the delay from systemd starting to the vboxvideo module loading looks to be about 7s
[17:01] <sforshee> still awfully long
[17:01] <tjaalton> right, well the root bug is something changed in xserver 1.20 compared to 1.19 which makes it fail now if vesa is loaded first
[17:24] <tjaalton> sforshee, seb128, LocutusOfBorg: we just need https://gitlab.freedesktop.org/xorg/xserver/commit/0a9415cf793babed1f28c61f8047d51de04f1528
[17:28] <tjaalton> the diff to bionic log was that glamor init succeeds now, when it shouldn't
[19:05] <seb128> tjaalton, good work figuring that issue out!
[19:06] <tjaalton> the commit says the feature was enabled in mesa 17.3 but in fact it was in 18.1 which was why I didn't think of that earlier..
[19:15] <seb128> no worry, glad that you figured it out before cosmic is out :)
[19:26] <tjaalton> well, the author helped..
[19:26] <tjaalton> as I first thought it was a regression in xserver
[22:35] <coreycb> bdmurray: i'm going to add some patches to the bionic neutron upload if you haven't gotten to that one yet
[22:36] <coreycb> bdmurray: feel free to reject that
[22:38] <bdmurray> coreycb: Oh, could you update the regression potential in bug 1790598 then?
[22:40] <coreycb> bdmurray: the other patches that I'm adding are for a different issue. Still want me to update 179058?
[22:42] <bdmurray> coreycb: Well, Regression Potential of minimal isn't great.
[22:42] <coreycb> bdmurray: well i can't argue with that. we'll get it updated.
[22:43] <bdmurray> coreycb: thanks
[23:20] <mwhudson> do the git-ubuntu imports contain enough info to reconstruct the dsc?
[23:20] <nacc> mwhudson: for an existing publish?
[23:20] <mwhudson> yes
[23:20] <nacc> mwhudson: every DSC is stored in a special branch
[23:20] <mwhudson> ah cool
[23:20] <nacc> mwhudson: which srcpkg?
[23:20] <mwhudson> nacc: uhh i think it was dh-golang this time
[23:20] <nacc> i can try and find the right ref for you
[23:20] <mwhudson> basically i run debdiff and it says "can't find dsc"
[23:20] <nacc> yeah
[23:21] <mwhudson> hmm i guess i also need the tarball for that to do anything useful
[23:21] <nacc> https://git.launchpad.net/ubuntu/+source/dh-golang/log/?h=importer/ubuntu/dsc
[23:21] <nacc> we have a git-ubuntu export-orig
[23:21] <mwhudson> nice
[23:21] <nacc> to get the orig tarball out of the pristine-tar (or downlaod it from LP if we don't have it in pristine-tar)
[23:22] <nacc> in *theory*, if you have a full repo cloned, you can get the equivalent srcpkg locally; that was the hope, at least :)
[23:22] <nacc> the above is the DSC files in ubuntu, there is a corresponding importer/debian/dsc branch for those
[23:22] <nacc> it's not an ABI yet (that is, those branches may change content, etc.), but in the current implementation that's what the importer does
[23:23] <mwhudson> i'm glad someone is thinking about these things :)
[23:23] <nacc> tbf it's mostly rbasak at this point. I just have memories :)
[23:50] <RAOF> coreycb: Keystone rejected from xenial. Enjoy your dput!