[01:27] <richi235> I'm quite sure it will be 5.2 because 18.04 hwe-edge is 5.2 too in the bionic git repo. and usually lts hwe-edge and the newest non-lts distro have the same kernel
[08:27] <apw> lotuspsychje, hey ... do we ahve any bugs filed for these bionic/linux-hwe issues
[08:27] <lotuspsychje> not yet apw 
[08:28] <lotuspsychje> i gotta go to city right now, ill try to debug after apw 
[08:28] <apw> lotuspsychje, getting the reporters to file bugs would get the exact version combinations recorded
[08:28] <apw> lotuspsychje, in case it is a linux-hwe/mesa/x missmatch or something
[08:28] <lotuspsychje> ok tnx
[08:29] <lotuspsychje> i told the -discuss crew to forwards bugs here
[08:29] <lotuspsychje> we will keep an eye open 
[08:30] <lotuspsychje> bbl
[08:40] <tjaalton> what issues?
[10:10] <tomreyn> tjaalton: two quotes (from different people running hwe on 18.04) from -discuss: "kernel 5.0.0.23 update made me boot in recovery mode and use the dpkg fix option, both machines"; "5.0.0-23-generic booted after dpkg recoverymode, but backlight doesnt work anymore"
[10:11] <tjaalton> ok, that doesn't say much
[10:34] <apw> tomreyn, could we get a bug number please with some versions and details in it
[10:37] <tomreyn> apw: i'm not affected, can't file a bug
[10:38] <apw> tomreyn, you likely could poke whoever you are quoting
[10:38] <tomreyn> will do
[10:38] <apw> ta
[10:39] <apw> tjaalton, i have no information beyond what is here, that someone was mentioning it in #ubuntu-discuss
[10:39] <apw> the "dpkg fix" is new information
[10:39] <apw> and i don't know if that is indicative of a missmatch
[10:40] <tjaalton> right
[10:41] <ogra> apw, does the snapcraft.yaml in ther kernel.ubuntu.com trees get any active testing ? (specifically in ubuntu-bionic.git ) ... https://forum.snapcraft.io/t/with-custom-kernel-in-amd64-architecture-snap-command-not-found/12574
[10:41] <ogra> s/ther/the/
[10:45] <apw> ogra, we are not using it every cycle that is for sure, i would refer you to klebers in the first instance
[10:45] <ogra> (i wonder if the re-built kernel misses any options or anything)
[10:47] <apw> ogra, it would be using the original configuration i assume .. isn't the error about not having the snap userspace binary though in that case?
[10:47] <apw> ogra, so something about their overall image and not specifically the kernel ?
[10:48] <apw> ogra, its not saying "snap: i can't find some useful kernel feature"
[10:48] <ogra> apw, yes, but i know that the core18 snap gets tested for exactly that before release, the image boots normally so the gadget is ok ... whihc only leaves the kernel (missing option ... issue because he used an old compiler parhaps .... whatever) as the first candidate for looking at
[10:49] <apw> ogra, for not finding a userspace binary ?
[10:49] <apw> that isn't even in the kernel or gadget snap is it ?
[10:49] <ogra> the snap error can be a fallout of snapd not running 
[10:49] <ogra> which can happen if you missing one of the snap options 
[10:49] <ogra> )in the kernel)
[10:50] <apw> /usr/share/subiquity/console-conf-wrapper: line 13: snap: command not found
[10:50] <apw> no that _really_ says there is no snap binary in the path
[10:50] <ogra> the image is built from stable core18 and snapd snaps, the only difference to one of our images are gadget and kernel ... 
[10:51] <apw> ogra, and the error still says the binary is missing
[10:51] <ogra> theoretically it functiona exactly the same as our image
[10:52] <ogra> geez
[10:53] <ogra> *theoretically it should function
[10:53] <apw> error: cannot list snaps: cannot communicate with server: Get http://localhost/v2/snaps: dial unix /run/snapd.socket: connect: connection refused
[10:53] <apw> snap says that if the server is not there
[10:53] <ogra> yeah 
[10:53] <apw> not snap: command not found
[10:53] <apw> so ... the snap command is not in their image
[10:53] <apw> somehow
[10:53] <ogra> well, i'll dig on 
[10:54] <apw> and as that is made outside of the machine it should be easy to confirm right ?
[10:54] <apw> looking at the ISO/squash wahtever it is
[10:54] <ogra> well, its a partitioned image ... not so easy to guiden an illiterate user though mounting it ... 
[10:54] <ogra> and thanks to journald we dont have logs to read :/
[10:55] <ogra> aha ! 
[10:55] <ogra> he uses a brand-store !
[10:56] <ogra> (and thanks for answering the initial question ... that was actually all i needed to know)
[13:58] <lotuspsychje> apw: this is whats happening to my system: https://bugs.launchpad.net/ubuntu/+source/linux-signed-hwe/+bug/1838644 
[15:21] <lotuspsychje> tjaalton: updated #1838644
[15:22] <tjaalton> lotuspsychje: well, dmesg from recovery mode doesn't help because i915.ko isn't loaded
[15:22] <tjaalton> but if 5.1.21 works then it's bisect time..
[15:23] <tjaalton> you have earlier mainline builds on the parent dir, try 5.1rc's
[15:23] <lotuspsychje> allrighty
[15:24] <tjaalton> which laptop model?
[15:25] <lotuspsychje> tjaalton: Clevo Machine:   Device: laptop System: Notebook product: N7x0WU
[15:25] <tjaalton> ok
[15:33] <lotuspsychje> tjaalton: 5.1.0-050100rc1-generic also works
[15:34] <tjaalton> right.. feared as much
[15:36] <tjaalton> lotuspsychje: try the older build of drm-intel-next
[15:36] <tjaalton> oldest
[15:36] <tjaalton> https://kernel.ubuntu.com/~kernel-ppa/mainline/drm-intel-next/2019-02-08/
[15:36] <tjaalton> rc1 has some fixes on top of that
[15:36] <tjaalton> hoping that this one is broken..
[15:36] <lotuspsychje> lets c
[15:37] <tjaalton> otherwise need to bisect using older drm-intel-next tags..
[15:41] <lotuspsychje> tjaalton: also working 5.0.0-997-generic
[15:42] <tjaalton> from that dir?
[15:42] <lotuspsychje> yes
[15:43] <tjaalton> have you built kernels before? :)
[15:44] <lotuspsychje> no
[15:44] <tjaalton> ok
[15:44] <tjaalton> do you have time to hang around?
[15:44] <lotuspsychje> a bit sure, i added to autojoin here
[15:44] <tjaalton> well, I can also post to the bug
[15:44] <tjaalton> getting late here
[15:44] <lotuspsychje> ok tnx for your time tjaalton 
[15:44] <tjaalton> as in EOD late
[15:45] <lotuspsychje> ill see if i can catch a dmesg before the flickering
[15:45] <tjaalton> I'm pretty sure what it's about
[15:45] <tjaalton> so no immediate need for that
[15:45] <lotuspsychje> what do you suspect?
[15:47] <tjaalton> i915 watermark programming
[15:47] <lotuspsychje> ok
[15:49] <lotuspsychje> tjaalton: are you interested in my intel NUC test
[15:49] <tjaalton> depends :P
[15:49] <lotuspsychje> tjaalton: cause i dont have the issue there
[15:50] <tjaalton> this is specific to hw
[15:50] <lotuspsychje> i see
[15:50] <tjaalton> display mostly
[15:51] <tjaalton> I'll build you a kernel
[15:51] <lotuspsychje> tnx
[15:53] <tjaalton> will take a while
[15:55] <lotuspsychje> sure thing tyt
[16:00] <TJ-> Looks like it could be related to the i915 CDCLK changes
[16:02] <TJ-> the dmesg from a flickering boot shows [   23.332952] [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe A FIFO underrun
[16:03] <tjaalton> yes
[16:27] <tjaalton> lotuspsychje: still here? first build ready, I'll copy it somewhere..
[16:28] <lotuspsychje> ill test after dinner
[16:28] <tjaalton> lotuspsychje: https://aaltoset.kapsi.fi/bisect/
[16:32] <lotuspsychje> tjaalton: working Linux Rootbox 5.0.0-rc1
[16:33] <tjaalton> lotuspsychje: the one I built is working?
[16:34] <lotuspsychje> well i installed it and sudo update-grub
[16:35] <tjaalton> ok
[16:35] <lotuspsychje> ./boot/initrd.img-5.0.0-rc1 is the one right?
[16:36] <tjaalton> these are all going to be 5.0.0-rc1
[16:36] <tjaalton> the thing is to track the build number (-11 here)
[16:37] <tjaalton> or, abi number to be precise
[16:37] <lotuspsychje> Linux Rootbox 5.0.0-rc1 #11
[16:37] <tjaalton> yes
[16:37] <lotuspsychje> ok oof :p
[16:37] <lotuspsychje> first food here now :p
[16:37] <lotuspsychje> tnx for your tile tjaalton 
[16:38] <lotuspsychje> time
[16:38] <lotuspsychje> got a lot of clevo customers out there, so apreciate it!
[16:39] <tjaalton> next builds will be quicker
[16:46] <tjaalton> lotuspsychje: 12 copied
[17:00] <lotuspsychje> cool
[17:04] <EoflaOE> How can you make it faster?
[17:10] <tjaalton> it doesn't clean the old files, and since only a subset of the source keeps changing between bisect points, only those (plus the packaging) will be rebuilt
[23:45] <tomreyn> drm-tip builds seem to be partially broken (the current is, but also some of the previous ones) - possibly a git process concurrency / locking issue
[23:45] <tomreyn> https://kernel.ubuntu.com/~kernel-ppa/mainline/drm-tip/current/