[09:30] <apw> White_Light, https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/unstable/commit/?id=8506e11a79d14989409542b885beba7119190562
[09:30] <apw> White_Light, ^ does that help ?
[13:51] <brainwash> why did the packaging for the mainline kernel ppa change?
[13:52] <brainwash> in 4.16.4
[13:54] <brainwash> starting with 4.16.4 my first login attempt (initializing xorg) fails
[13:57] <brainwash> https://paste.ubuntu.com/p/FJq75SVQDT/
[14:02] <brainwash> issue is present in 4.17rc4 also
[14:24] <brainwash> so, I cannot spot anything relevant in the 4.16.4 changes file
[14:47] <White_Light> apw, I'll try it out, thanks
[15:29] <White_Light> apw, yep that fixes it
[15:29] <White_Light> I was able to successfully build binary-perarch after modifying makefile.rules
[15:47] <jackpot51> I have a question about pulling a patch from upstream. I have a one-line patch I sent to the alsa-devel list here: http://mailman.alsa-project.org/pipermail/alsa-devel/2018-May/135685.html
[15:47] <jackpot51> If that is merged upstream, what is the typical timeline to have it backported to the Ubuntu kernel?
[16:37] <brainwash> jackpot51: does it qualify as SRU? https://wiki.ubuntu.com/StableReleaseUpdates
[16:38] <jackpot51> Yes: For Long Term Support releases we regularly want to enable new hardware. Such changes are appropriate provided that we can ensure not to affect upgrades on existing hardware. For example, modaliases of newly introduced drivers must not overlap with previously shipped drivers. This also includes updating hardware description data such as udev's
[16:38] <jackpot51>  keymaps, media-player-info, mobile broadband vendors, or PCI vendor/product list updates. 
[16:38] <jackpot51> Covered by that statement
[16:38] <brainwash> ok
[16:40] <brainwash> can't answer you initial question though
[16:40] <brainwash> your
[16:41] <brainwash> cuz I'm not part of the kernel team
[16:52] <jackpot51> That's ok
[18:06] <bjf> jackpot51, if it has been flagged for "stable" then it will end up in one of grekh's trees. we apply those shortly after he does a release and then it comes out in our next sru cycle
[18:07] <jackpot51> Thanks bjf. About when would that happen?
[18:30] <bjf> jackpot51, don't know when gregkh will pick it up
[18:31] <bjf> jackpot51, an alternative is to file a launchpad bug, attach a pointer to that quirk and point us at the LP bug. we have no problem picking up quirks early (before upstream stable releases)
[18:31] <jackpot51> Oh cool, I didn't know that. I will file a launchpad bug
[18:31] <bjf> jackpot51, you can also submit the patch to our mailing list if you feel like it
[18:34] <jackpot51> bjf: Which one would you prefer?
[18:36] <bjf> jackpot51, the lp bug route is easiest for you and fine with u
[18:36] <bjf> us
[18:36] <bjf> jsalisbury, ^
[18:37] <jsalisbury> bjf, ack
[18:38] <jsalisbury> jackpot51, I'll keep an eye out for the new bug after you open it.
[18:38] <jackpot51> Ok, thanks jsalisbury
[18:40] <bjf> jsalisbury, thanks much
[18:40] <jackpot51> jsalisbury: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1769721
[18:41] <jackpot51> Oh, I need to resubmit patch as an attachment due to launchpad changing the whitespace
[18:41] <jsalisbury> jackpot51, thanks.  I'll build a test kernel with the patch and post it to the bug, just so we can confirm it works.
[18:42] <jsalisbury> jackpot51, no need to resubmit the patch, I can grab it.
[18:43] <jackpot51> Oh, thanks
[18:43] <jsalisbury> np
[18:43] <jackpot51> jsalisbury and bjf: I very much appreciate the speed and accuracy you have!
[18:43] <jsalisbury> jackpot51, anytime
[18:46] <jackpot51> I look forward to submitting my next patch upstream in a couple months. It will be much larger ;-)
[18:46] <jackpot51> https://github.com/system76/linux/commit/8c34dafed7f12367ed979d8accc6f8ddc1ec48bf