[00:56] <lotuspsychje> good morning
[04:11] <lotuspsychje> anyone knows howto make apport import logs in case the kernel is HWE when filed against 'linux' and results to linux-signed-hwe-5.19 ?
[04:12] <lotuspsychje> only 2 logs imported auto here
[04:12] <lotuspsychje> bug #2017955
[04:12] -ubottu:#ubuntu-discuss- Bug 2017955 in linux-signed-hwe-5.19 (Ubuntu) "Realtek Ethernet 8125 will disconnect randomly from Ethernet" [Undecided, New] https://launchpad.net/bugs/2017955
[08:05] <tomreyn> lotuspsychje: hey, i'm trying to understand this: are you meaning to apport-collect to an existing bug id, but this bug is attributed to the wrong package? or are you trying to submit a new bug against a package but it does not seem possible to report it against this very package?
[08:08] <tomreyn> oh, i get it now. you're saying that bug reported against "linux", if apport resolves it to a linux-signed-hwe-... package, do not gather the right / enough logs.
[08:26] <tomreyn> i've also posted in #ubuntu-kernel, maybe this helps getting traction on it.
[08:37] <lotuspsychje> +1 tomreyn thank you
[09:35] <lotuspsychje> !23.04
[09:35] <lotuspsychje> checkout the releasenotes dreamcat4 
[09:36] <dreamcat4> yeah i was wondering  in terms of the stability, breakages, new issues. sometimes it can take a few weeks to address
[09:36] <lotuspsychje> dreamcat4: https://discourse.ubuntu.com/t/lunar-lobster-release-notes
[09:36] <lotuspsychje> the known bugs are also shows there, new packages, etc
[09:39] <dreamcat4> actually i should upgrade very soon, to then install radeon drivers (and see for myself)
[09:41] <dreamcat4> main thing i am guessing is the glibc / libc / libcstd++ runtime versions. that the version of libraries needs to be 'compatible' with whatever those radeon proprietary drivers were compiled with. that is my main area of concern
[09:41] <dreamcat4> will do a full backup before upgrading. just in case of that (to be able to roll back)
[09:43] <dreamcat4> everything else i don't really anticipate being an issue, barring any unforseen severe breakages
[09:43] <dreamcat4> need to upgrade to be able to install bismuth (window tiling for kde plasma)
[09:43] <dreamcat4> (and also maybe newer kde plasma itself)
[13:04] <tarzeau> ogra: do you have some references in europe, preferably switzerland of ubuntu and enterprise and snaps?
[13:04] <tarzeau> i mean i can understand that some users like snaps, and get software as snaps. but enterprise? no way
[13:05] <ogra> tarzeau, i'm in field engineering nowadays, but sadly most of my customers are confidential  ... i can tell you that i just set up a snap store proxy for one of the rather bigger european telcos though ... for some thousands of their desktop installs 
[13:06] <ogra> snaps come with buolt in central fleet MGMT (originally implemented for IoT but seems like enterprises found out it helps them too )
[13:06] <tarzeau> i'm surprised. but knowing google went the debian way and testing, i doubt their users/desktops have snaps
[13:07] <ogra> i.e. snapd has a REST API that will allow you to hook it into your SW management tools easily, so you can adjust permissions, manage updates, take backups and use all the other built-in snap features
[13:07] <tarzeau> and from my collegues in other fields (medical, telco, airtransport, and some others), i'm not aware of any snap/enterprise usage either
[13:08] <tarzeau> i thought ansible (and the like) is for that kind of stuff
[13:09] <ogra> depends ... 
[13:09] <ogra> i have quite a bunch of medical device customers ... though thats indeed not server/desktop but utilizing (and paying for) Ubuntu Core with is 100% snap based and has no deb support
[13:10] <ogra> but we also hav plenty of enterprises using snaps on top of server/cloud installs ... 
[13:11] <ogra> snaps are a safer (and more admin friendly) alternative to docker containers for example, some customers get that and roll their own snaps replacing docker 
[13:11] <tarzeau> thanks for your explanation. i consider snap as well as docker a security problem and not fit for enterprise 
[13:13] <ogra> well, snaps are readonly gpg signed suqshfs filesystem images ... never unpacked, with pre-defined and fully controllable writable areas for their data ... they are transactional and ome with built in selftests ... i.e. your snapped webserver can have a test if port 80 is open after updae, if it fails the snap will automatically roll back to the former version
[13:14] <ogra> so there is a lot of added security you wont see with debs or docker 
[13:14] <ogra> tinker proof ... self healing ... confined ... to throw in some buzzword bingo value here 🙂
[13:15] <ogra> many customers get that ... and like it actually ... 
[13:17] <tarzeau> do you know that meme with the bus and that train?
[13:18] <ogra> nope ... 
[13:18] <tarzeau> to me it feels like a big brick of concrete, not flexible, huge and just a "klotz"
[13:19] <tarzeau> https://imgflip.com/i/7jtu03
[13:19] <ogra> well, that is completely off ... snaps *need* debs, they are built from them ... 
[13:20] <ogra> anyway ... did you notice that most companies in the business are doing bigger layoffs recently ... 
[13:21] <ogra> and did you notice that canonical is actually in teh position to do hiring instead ? ... 
[13:21] <ogra> snaps have a non trivial play in that 🙂
[13:25] <ogra> (admittedly more in the IoT area were they are pretty well established, but enterprise and cloud is picking up and slowly coming to speed here )
[13:26] <tarzeau> ok. my prediction: people will move to debian for a bunch of reasons
[13:28] <ogra> people move all the time ... some to debian some to ubuntu ... i dont see that as a problem 
[13:31] <tarzeau> the reason we moved at work to ubuntu was pre 2018, ubuntu unity, but now that's gone, there's basically no difference between deb/ubu, except well there's a huge difference
[13:32] <ogra> like 10y of security support for all of the archive ? 🙂 
[13:33] <tarzeau> well that's not free as in free beer
[13:33] <ogra> it is for non commercial use
[13:33] <tarzeau> nobody right in their mind would use such software without updates (i mean, if it's not a satellite sent far far away, and it's not possible to upgrade)
[13:34] <tarzeau> the 5 free ones when you register and use UA?
[13:34] <tarzeau> ubuntu pro
[13:34] <ogra> right
[13:34] <leftyfb> nobody in their right mind would run an EOL OS in production
[13:34] <tarzeau> but i can have that without registration from debian?
[13:34] <ogra> or 50 if you are an ubuntu community member
[13:34] <tarzeau> leftyfb: true, they would upgrade it
[13:34] <ogra> can you ? 
[13:35] <ogra> show me how debian does give CVE support for *all* of their archive for 10y ... would be news to me that they do 
[13:35] <tarzeau> i said 5 years
[13:35] <ogra> and i said 10 🙂
[13:35] <tarzeau> but your 10 is really only 5
[13:36] <leftyfb> tarzeau: ESM is only needed for after EOL, which is 5 years
[13:36] <leftyfb> Debian does not provide updates for all their packages beyond 5 years, just like ubuntu
[13:36] <ogra> and their 5 is clearly only for select packages they ave people to care for 
[13:36] <leftyfb> unless you're running Unstable, which you shouldn't be doing in production
[13:36] <oerheks> and ESM covers not all packages..
[13:36] <ogra> it does now
[13:36] <tarzeau> ogra: clearly not. the expection list is very small
[13:36] <ogra> well, since it got rnamed to pro