[02:48] <lotuspsychje> good morning
[03:01] <BredaSimonides> Good morning to your timezone
[03:03] <lotuspsychje> hey BredaSimonides 
[07:50] <ducasse> good morning
[14:19] <marcoagpinto> Hello!
[14:22] <Maik> o/
[17:13] <mncheckm> leftyfb, I guess if I updated that diff I could just still use a browser, but you could script it with rmadison which is the way forward I think
[17:14] <mncheckm> also it looks like overkill to go through web when the data is in plain text
[17:15] <leftyfb> mncheckm: again, what exactly are you doing? Why are you making diffs of sources.lists?
[17:16] <mncheckm> leftyfb, to put into VCS so a devops pipeline could be put on top of it, obviously
[17:17] <leftyfb> using what mechanism? A proper tool like ansible or chef uses templates for sow thing like this
[17:18] <mncheckm> maybe shouldn't focus on diffs to sources.list then, but the information isn't still needed?
[17:20] <mncheckm> leftyfb, I had been wrong not to do ssh PROD apt policy PACKAGE , but I'm happy I learned about rmadison from you
[17:31] <leftyfb> mncheckm: whatever it is you're trying to accomplish, which still isn't clear, rmadison probably isn't the right solution
[17:34] <mncheckm> leftyfb, I'm trying to debug an NT_STATUS_LOGON_FAILURE with winbindd on a bionic machine for which I wanted to check the proper settings for the realm with realmd which I intend to build with a PREFIX to avoid installing it
[17:34] <leftyfb> what does that have to do with sources.list?
[17:34] <mncheckm> this turned into "this should be available from the command line what am I missing"
[17:35] <mncheckm> leftyfb, apt-get source didn't work for the package because the deb-src wasn't enabled but I didn't want to enable them all
[17:35] <leftyfb> mncheckm: why are you building from source as opposed to from apt?
[17:35] <mncheckm> to avoid installing the package
[17:36] <mncheckm> I just need the binary
[17:36] <leftyfb> why?
[17:36] <mncheckm> because I don't want to go into "would installing it trigger something I don't want"
[17:36] <mncheckm> leftyfb, why are you asking all these questions exactly?
[17:37] <mncheckm> I mean I'm grateful you helped me
[17:37] <mncheckm> I usually get tons of whys when noone knows the answer but that's not the case here clearly
[17:38] <leftyfb> because there's a long rabbit-hole to get to your actual goal. A lot of the time, your initial question/problem has to do with something that you think you need to do but don't because 7 steps back there was a better solution to the problem
[17:38] <mncheckm> leftyfb, well okay
[17:38] <leftyfb> in this case, I would actually use an lxd container to test things out
[17:39] <leftyfb> or at the very least, use the container to build your binary and upload it to the machine you're testing
[17:39] <mncheckm> leftyfb, wouldn't that install around >200M?
[17:39] <leftyfb> but then you also went on about version control of sources.list ... this I still don't understand exactly, not the way you're presenting it any way
[17:40] <leftyfb> mncheckm: the test lxd container(s) can and should be on a different machine not in production
[17:41] <mncheckm> leftyfb, well as much as you want to solve this at the right step, I wish to know exactly what I asked and just provided some plausible reason which I might actually want to do at some point
[17:41] <mncheckm> leftyfb, that's right but how would that test the environment of the PROD machine
[17:42] <leftyfb> mncheckm: using rmadison  is a good solution to determine versions and sources of packages on one release from another. It is not a good solution for anything to do with version control or automation
[17:42] <leftyfb> mncheckm: rebuild the PROD machine in a test environment. Or like I said, build your binary in a separate environment and upload it temporarily to the PROD machine
[17:43] <mncheckm> leftyfb, maybe we were just out of sync when I asked "bionic package from local" and you answered "what am I trying to accomplish" which was before I ever added diffs to the mix IIRC
[17:44] <mncheckm> I expect to get an answer to my general problem, not my specific problem, there
[17:45] <leftyfb> haven't all your questions already been answered?
[17:45] <mncheckm> leftyfb, sure and quite well
[17:46] <mncheckm> leftyfb, maybe I should asked differently somehow
[17:46] <leftyfb> :)
[17:46] <mncheckm> should've
[17:46] <leftyfb> ^ sorry, that wasn't meant for here
[17:46] <mncheckm> oh
[17:46] <mncheckm> now thats funny :)
[17:46] <leftyfb> still haven't figured out how to make hexchat stop stealing focus on notification
[17:46] <mncheckm> does it do that?
[17:46] <leftyfb> yes, and it's VERY annoying
[17:47] <mncheckm> I have 2.14.3 but I don't think I've got that
[17:48] <mncheckm> leftyfb, FWIW I have Settings/Prefernces/Chatting/Alerts/Alerts all disabled except blink in tray and task
[17:49] <mncheckm> leftyfb, you might try that
[17:49] <leftyfb> I don't want notifications turned off, I want them to stop stealing focus
[17:50] <leftyfb> I think I know why though
[18:02] <leftyfb> HA!
[18:02] <leftyfb> self-inflicted
[18:04] <leftyfb> I had a "NoAnnoyance" and "Steal My Focus" gnome extensions installed to get rid of the "Window is ready" notification when opening new windows. Turns out, those messages don't show anymore somehow and those extensions were causing the problem, by design
[18:05] <mncheckm> leftyfb, glad you found that
[18:05] <mncheckm> I have some extensions myself might be helpful to remember that
[22:56] <Jeremy31> How long are the Ubuntu oem kernels supported?
[23:37] <JanC> the same as the rest of the distro, I suppose?
[23:38] <Jeremy31> JanC: the oem kernels aren't ones used in Ubuntu releases, the one is actually 5.14
[23:39] <JanC> I'm not sure they are included in the extended support packages, but as they are in main I would assume that they are supported like everything else in main  :)
[23:41] <Jeremy31> linux-oem-20.04d package is a 5.14 kernel, went EOL upstream in November from what I can find, last Ubuntu update was about 18 days ago.  A bit strange that they would go through any effort to support an EOL kernel that isn't used in a supported Ubuntu release
[23:41] <JanC> many kernels supported in Ubuntu are EOL upstream
[23:43] <Jeremy31> JanC: but most of them have usually been used in an Ubuntu supported version
[23:43] <JanC> I guess as long as the OEM customer pays...
[23:43] <JanC> or maybe even does (part of) the work...
[23:44] <JanC> for LTS releases I guess they could also "upgrade" people to a newer HWE kernel, but not everyone would like that...
[23:45] <Jeremy31> JanC: the HWE was default for Ubuntu desktop in 20.04
[23:46] <JanC> yeah, for desktops maybe it could work
[23:47] <Jeremy31> It was last year that it upgraded to the HWE kernel used in 20.10, a bit of a surprise to me
[23:47] <JanC> in focal there are 5.6, 5.10, 5.13 & 5.14 OEM kernels, it seems...
[23:48] <Jeremy31> Which would mean more work for the kernel devs
[23:49] <Jeremy31> But for now 5.13 is supported in 21.10 IIRC
[23:55] <JanC> 20.04 LTS got 5.13 a couple weeks ago, I think
[23:55] <Jeremy31> I think that is correct
[23:57] <Jeremy31> Usually updated after 3 months of the short term support version release
[23:57] <JanC> and I suppose as long as companies want to pay Canonical for extra OEM kernels and that allows Canonical to hire more kernel developers then it's agood thing  ;)
[23:57] <Bashing-om> !info linux-generic-hwe-20.04 focal
[23:58] <Jeremy31> Likely the same for linux-generic-hwe-20.04-edge now
[23:59] <Jeremy31> !info linux-generic-hwe-20.04-edge focal