=== jamesh_ is now known as jamesh
[05:35] <guiverc> vorlon, the lubuntu dailiess that now boot on bios boxes (Thank you!) aren't giving a "Kernel requires an x86-64 CPU  .. i686 detected" which historically they've provided, do you care? or does this matter?  want bug report or ignore?
[05:39]  * guiverc suspects that would cause slower boots on amd64? and thus would be won't fix..
[08:37] <xnox> guiverc:  historically they've provided => provided i386 isos, or i386 kernel? lubuntu stopped that, a while ago.
[08:38] <xnox> guiverc:  i'm not sure what you mean, and curious to understand.
[08:39] <guiverc> I realize that; xnox, but in testing I've always 2-3 times per cycle booted an amd64 ISO on a 32-bit only box looking for a valid error message like what I mentioned..  I'm only getting a blinking cursor (no error "Kernel requires an x86-64 CPU  but only detected i686"
[08:41] <guiverc> the message has changed over time..
[08:46] <xnox> guiverc:  ooooh, i see, interesting.
[08:47] <cjwatson> That message is from the kernel - I don't think it was ever an Ubuntu customisation.  But maybe if something fails before getting as far as the kernel then that would cause you not to see it.
[08:47] <guiverc> xnox, to be accurate; I do see grub selected (lubuntu, lubuntu nomodeset type selection) then blinking cursor
[08:48] <xnox> yeah, bios grub is "i386"
[08:49] <cjwatson> It's still there upstream at least (https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/x86/boot/cpu.c#n73)
[08:51] <xnox> i wonder if it fails to decompress? because we switched to LZ4 compressed kernel?
[08:53] <xnox> (and with gzip, maybe grub used to uncompress the kernel, although don't think so)
[08:54] <guiverc> how long ago was the switch?  (I'm wondering if I have an iso before that for comparison)
[08:55] <xnox> hm, but also we switched from isolinux to grub-pc on iso which is another variable.
[08:56] <xnox> guiverc:  do you see that message with any focal iso?
[08:56]  * guiverc was just looking for a 20.04.1 iso
[08:56] <xnox> if yes, it's isolinux => grub switch
[08:59] <guiverc> "This kernel requires an x86-64 CPU, but only detected an i686 CPU" for what my list-thumb-drives says is kubuntu 20.04.1  (booting on amd64 to confirm
[09:04] <guiverc> kubuntu 20.04.1  /etc/apt/sources.list says 2020-07-31  (I only ever grab dailies); can't recall what official will say
[09:04] <guiverc> 20.04.1 was 2020-08-06 sil's notice
[09:16] <slyon> Hey, could somebody please re-trigger this 0.100-0ubuntu3 arm64 test for me? https://autopkgtest.ubuntu.com/packages/netplan.io/groovy/arm64 It passed on all other architectures, but failed on arm64 due to a "no such file or directly" error on a file, which is clearly written during the test.. It might have been a flaky situation.
[09:17] <seb128> slyon, hey, retried now
[09:17] <slyon> thank you
[09:18] <seb128> np!
[09:52] <guiverc> I filed bug report 1895956
=== gusnan is now known as Guest61917
[12:16] <slyon> hmm... My netplan/arm64 test failed again :-/ ... The test creates a /netplan-dummy.service file, reboots, and moves it to /run/systemd/system/ after reboot. This file is missing after reboot (or not created at all?) on arm64, while it works on the other architectures... The other file created during the same test (/etc/systemd/system/cloud-init-dummy.service) works just fine on all architectures.
[12:16] <slyon> Does anybody have an idea what could cause this file to be missing/deleted on the arm64 autopkgtest runner?
[12:32] <zyga> stgraber: hello, I have a question about using lxd inside lxd inside ubuntu 16.04
[12:33] <zyga> stgraber: is that configuration supported?
[12:33] <zyga> stgraber: we have few problems with a test that checks that
[12:33] <zyga> https://bugs.launchpad.net/snapd/+bug/1892468
[12:33] <ubottu> Launchpad bug 1892468 in snapd "Nested lxd test useful?" [Undecided,New]
[12:42] <stgraber> zyga: possibly a dbus bug which got fixed in later releases? Nested containers don't get their own apparmor namespace so they don't get mac_admin which probably explains that sysfs behavior.
[12:42] <zyga> ah
[12:42] <zyga> can you comment on the bug please
[12:42] <zyga> I think this explains a bit
[12:42] <stgraber> zyga: does running 18.04 in the nested container fix it? If so, that would strongly point to sending in dbus having been fixed
[12:43] <zyga> running 18.04 on the host and containers does fix ti
[12:43] <zyga> *it
[12:43] <zyga> the test we have matches host/container systems
[12:44] <stgraber> Right but that's changing a lot of variables, would be interesting to change just the nested container to see if it's something that got fixed in more recent Ubuntu or if the fix is coming from kernel or policy changes on the host
[12:45] <zyga> stgraber: I can play and report back
[12:45] <zyga> stgraber: but for the purpose of the bug, do you think that test is valid?
[12:45] <zyga> should we pursue backporting fixes to dbus?
[13:34] <seb128> LocutusOfBorg, hey, any update on the gstreamer merges?
[15:34] <LocutusOfBorg> seb128, I syncd stuff the bad1.0 is probably finished, test building shortly
[15:34] <seb128> LocutusOfBorg, thanks
[16:03] <LocutusOfBorg> seb128, bad is done, lets do good now, but its pita
[16:50] <LocutusOfBorg> seb128, I might have also the good one in my ppa
[16:50] <LocutusOfBorg> will need some additional i386 fixes, not sure if we can drop new dependencies added in 1.18
[16:51] <LocutusOfBorg> https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/locutusofborg-ppa
[16:51] <LocutusOfBorg> lets see how far we go, we might also need to ship again pkgconfig files, but with meson... meh!
[16:53] <Laney> don't drop that stuff
[16:53] <Laney> it lets our plugin moves work transparently
[17:08] <vorlon> xnox: LP: #1895956 - do you think we should worry about fixing this?
[17:08] <ubottu> Launchpad bug 1895956 in Ubuntu CD Images "amd64 groovy ISOs when booted on i386 no longer give cpu error" [Undecided,New] https://launchpad.net/bugs/1895956
[17:19] <juliank> tjaalton: Reported the i915 thing as https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1896091 now that I reproduced it on 5.8.0-19
[17:19] <ubottu> Launchpad bug 1896091 in linux (Ubuntu) "[i915] graphic corruption following orkqueue: PF_MEMALLOC task 131(kswapd0) is flushing !WQ_MEM_RECLAIM events_unbound:active_work [i915]" [Undecided,New]
=== ijohnson is now known as ijohnson|lunch
[17:38] <tjaalton> juliank: you should attach a dmesg dump there
[17:38] <juliank> tjaalton: hmm, why didn't ubuntu-bug do that?
[17:39] <juliank> strange
[17:39] <tjaalton> probably because the user has no access to it anymore?
[17:39] <tjaalton> +unprivileged
[17:40] <juliank> oh
[17:40] <juliank> I'll journalctl -k it
[17:41] <juliank> I'll add a bug for apport
[17:46] <juliank> tjaalton: done
[17:48] <tjaalton> text/html ;)
=== ijohnson|lunch is now known as ijohnson
[17:57] <juliank> tjaalton: sorry, fixed
[17:57] <juliank> tjaalton: it also posted twice, so fixed that too :/
[17:58] <tjaalton> hum, still shows it unreadable here
[18:05] <tjaalton> anyway, next would be to test newer kernels.. and if it's not fixed in drm-intel-next, file it upstream
[18:14] <juliank> tjaalton: well, i can try 5.9.0-rc5 from mainline ppa
[18:14] <juliank> it's a shame mainline ppa has no signed kernels
[18:16] <juliank> or well ppa to add, it's so hard :/
[18:17] <tjaalton> just download two files and install them
[18:17] <tjaalton> kernel and modules
[18:17] <tjaalton> it has drm-intel-next builds too
[18:18] <juliank> Found that
[18:18] <juliank> I have secure boot enabled, so need to enroll the kernel hash into mok
[18:18] <juliank> but oh well
[18:25] <juliank> booted with disabled validation, oh well
[18:26] <juliank> Hey, I'd be fine doing human CI on kernels, really
[18:38] <nicolasbock> Hi, lately emacs-gtk keeps crashing. I can't find an open bug for it though.