[01:47] <lotuspsychje> good morning
[07:14] <lordievader> Good morning
[07:16] <oerheks> heya lordievader 
[07:17] <lordievader> Morning oerheks , how are you doing?
[07:18] <oerheks> still alive, no covid sofar..
[07:18] <oerheks> haven' t seen you for a while :-)
[07:22] <lordievader> Nice, we did get covid a while back. Wasn't a lot more than a cold for me.
[07:22] <lordievader> I've been busy, didn't get a lot of time for IRC.
[07:25] <oerheks> i have this feeling development and bugfixing become harder for maintainers
[07:25] <oerheks> also retbleet, need a good kernel 5.19+
[14:24] <Eickmeyer[m]> Maik: RE: omgubuntu: Joey Sneddon has proven time and time again that he just doesn't care about Ubuntu and just wants clicks. He barely recognizes Lubuntu and Ubuntu Studio as official flavors (?!) and has basically stopped covering the official flavors altogether. In fact, he tends to be hostile toward Lubuntu in particular. I have similar issues with Full Circle Magazine, but they're less for the clicks and more just ignorant.
[15:08] <Maik> Eickmeyer[m]: thanks for letting me know. It's kinda sad imho.
[18:04] <Chunkyz> Afternoon 🙂
[18:36]  * arraybolt3[m] wonders if we should keep omgubuntu out of the Ubuntu Weekly Newsletter, especially after they made fun of Snap when they heard about last week's mess
[18:49] <lotuspsychje> arraybolt3[m]: joey's methods have always been bit satire
[18:50] <arraybolt3[m]> Yeah but did you see the bomb that went off in the comment section? 🤮
[18:50] <ogra> he is stirring these for every snap related message
[18:51] <arraybolt3[m]> I mean, I kinda feel like we're doing ourselves and maybe our users a disservice to be basically advertising him in the UWN. It makes sense why we'd put his article in there, but it's just, blah.
[18:52] <ogra> write him a mail and explain to him that you consider dropping OMG and why ? 
[18:52] <lotuspsychje> sensation news sells, thats how the whole world runs MSM
[18:52] <ogra> perhaps thats a wakeup call ? 
[18:52] <ogra> (stay friendly and do not attack etc)
[18:53] <arraybolt3[m]> And why do people hate Snaps anyway? I get it, people don't like that auto-updates are a thing in today's malware-ridden world. They don't like that one company has control over the server (but you still use the OS that only one company has control over?). They don't like that it can be slower (I'll take slower over less secure in many if not most circumstances, thanks). All of those reasons aren't very good IMO.
[18:54] <lotuspsychje> there will always be pro & contras for everything
[18:55] <lotuspsychje> something new arises, common case ppl oppose to it
[18:55] <arraybolt3[m]> Personally, my way of thinking is, yes, auto-updates are crummy sometimes, but they're better than the alternative. Yes, it would be nice if other people could run their own Snapcraft servers, but I don't fault Canonical for wanting to keep control of the servers since that's probably a source of income for them and they kinda need income if they're going to keep Ubuntu alive. And yes, some speed improvements would be welcome but
[18:55] <arraybolt3[m]> they're working on those like crazy.
[18:58] <arraybolt3[m]> My only serious gripe with Snap is that the command set the "snap" CLI uses is different enough from apt's command set that I keep having to look stuff up to figure out what I'm doing.
[19:00] <sarnold> hah, me too
[19:01] <sarnold> I've had a dead mattermost client often enough that I'm reluctant to use snap for anything long-lived
[19:01] <sarnold> it's fine for yt-dlp, sure, update whenever
[19:01] <ogra> hmm, i have no issues with my MM client here 
[19:02] <ogra> (emphasis on "my" ... i dont use the "other" snap 🙂 )
[19:02] <sarnold> ahhhhhhhhh
[19:02] <sarnold> so you know when it's updated :) I have no idea when marco updates
[19:02] <ogra> yeah
[19:02] <arraybolt3[m]> Like, if we could have "snap install", "snap remove", "snap purge", "snap autoremove", "snap autopurge", "snap-cache search", and "snap-cache show", I would be SO HAPPY.
[19:02] <ogra> lol
[19:03] <sarnold> just when I start getting a bunch of errors trying to open links, open images, change channels, etc... "oh, I guess marco updated this two weeks ago"
[19:03] <leftyfb> uh
[19:03] <ogra> insall, remove and purge are there though 
[19:03] <sarnold> arraybolt3[m]: lol EXACTLY
[19:03] <arraybolt3[m]> (Also the bit that has to do with snapshots could have been a bit more clear. I can never remember the snapshot handling commands.)
[19:03] <ogra> ... well purge being an option to remove
[19:03] <arraybolt3[m]> ogra: The functionality may be there, but the command set just ain't the same.
[19:03] <ogra> cache-search -> find ... 
[19:03] <ogra> show -> info 
[19:04] <arraybolt3[m]> Is "snap purge" a thing?
[19:04] <ogra> snap remove --purge foo 
[19:04] <arraybolt3[m]> ogra: Right. THAT'S MY PROBLEM. "snap find" when you're used to "apt-cache search" is trick to remember.
[19:04] <ogra> like it was in apt 10y ago 😉
[19:04] <ogra> before purge became its own command
[19:04] <arraybolt3[m]> I get all of the functionality exists to do everything apt's commands do, but I got spoiled on apt and don't want to learn another package manager now.
[19:05] <arraybolt3[m]> (That's one good reason I stick with Ubuntu and Debian - I played with Arch and pacman drove me bonkers.)
[19:05] <ogra> well, our CTO likes to reinvent the world ... so re-using well known command names was a no-no ....
[19:06] <sarnold> arraybolt3[m]: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1618648
[19:06] <ogra> (and he was mainly involved in designing snap UX)
[19:06] <arraybolt3[m]> Come to think of it, I should just make a shell script or a bunch of aliases to do this for me.
[19:06] <ogra> haha
[19:06] <arraybolt3[m]> I'll publish it as "snaptitude", what do you think?
[19:06] <sarnold> rofl
[19:07] <sarnold> $ snap search foo
[19:07] <sarnold> Name                      Version                  Publisher              Notes  Summary
[19:07] <sarnold> foobar2000                1.6.11                   mmtrt                  -      foobar2000 is an advanced freeware audio player.
[19:07] <sarnold> OMG it looks like they actually got around to supporting it :)
[19:08] <arraybolt3[m]> No.
[19:08] <arraybolt3[m]> You're kidding me.
[19:08] <arraybolt3[m]> Ah, that's you who made the bug report!
[19:09] <sarnold> *nod* I knew it existed
[19:09] <sarnold> I didn't expect it to be six years old...
[19:09] <arraybolt3[m]> Does "snap show foobar2000" do anything?
[19:10]  * arraybolt3[m] is on a Chromebook otherwise I'd check on my own hardware
[19:10] <ogra> "unknonw command "show" ... "
[19:11] <ogra> *unknown
[19:12] <oerheks> snap info foobar
[19:12] <arraybolt3[m]> Ah well, can't win 'em all I guess.
[19:13] <sarnold> oh dangit, guess I better re-open..
[19:13] <arraybolt3[m]> Nope. Must be search or me is not happy.
[19:13] <arraybolt3[m]> Er, show...
[19:14] <arraybolt3[m]> This is the most ridiculous gripe session. Really, it's just another package manager. I'll figure it out. Other than the command set, I think Snaps are 
[19:14] <arraybolt3[m]> a good idea.
[19:16] <ogra> at least snap revert and snap save are pretty unique ... just dont use the other commands 😉
[19:19] <leftyfb> ogra: except that is only temporary
[19:19] <sarnold> arraybolt3[m]: it's more emblematic of the larger issue, that they've ignored feedback for years and then wonder why some people are vocally against the thing..
[19:19] <leftyfb> ogra: you literally have to break snapd and the ability to install and update snaps on your system in order to stick with a single version of a snap for more than 90 days
[19:21] <leftyfb> it's very un-enterprise with the inability to freeze a specific version of an app
[19:23] <sarnold> well, it's *extremely* enterprise -- if you want to do that, just buy a brand store and put your apps in it :)
[19:24] <leftyfb> does the "brand store" allow you to install and freeze specific versions of snaps?
[19:25] <sarnold> yeah, though perhaps mostly as a consequence of you choosing when to upload things
[19:25] <leftyfb> sarnold: I'm not talking about uploading anything. In this case I'm referring to the lxd snap
[19:26] <leftyfb> a few years ago an update got pushed out that broke all of our customers. Priority #1 support issue
[19:26] <ogra> leftyfb, it is not temporary ... 
[19:27] <ogra> leftyfb, once a *new* version comes out it will upgrade, but it will never again upgrade to the one you reverted from
[19:27] <leftyfb> huh?
[19:27] <ogra> so as long as no new update comes out you are staying at the version yu reverted to
[19:27] <leftyfb> :/
[19:27] <ogra> else revert would be pointless
[19:28] <leftyfb> "it will never update unless an update is available"
[19:28] <ogra> right
[19:28] <leftyfb> I get what you're saying, but that is in no way the ability to freeze a version
[19:28] <ogra> revert is not for freezing 
[19:28] <leftyfb> right
[19:29] <ogra> it is to allow you (or the packager by using a self test) to make sure you always have a working version
[19:31] <leftyfb> either way, after Canonical broke all of our customers, we reverted to lxd installs via apt. Then they removed that ability. So now I manually(scripted)install a specific version of the lxd snap .snap and .assert files that I downloaded a while back and disable/mask the snapd service
[19:31] <leftyfb> also put the snapd apt package on hold since upgrades to snapd will re-enabled it
[19:32] <ogra> remember that snaps come from IoT ... the built in selftest ability and auto) rollback make sure that this 5G device 150km out in the woods is always on and always running, so you do not need to send a tecnician
[19:32] <leftyfb> even more reason to implement a version freeze feature
[19:33] <ogra> well, lxd has tracks for that ... jzst pick the right track and stick with it ... there are still updates, but they are rare
[19:34] <leftyfb> the update to lxd at the time was within the same track
[19:34] <leftyfb> updates to lxd in the same track aren't rare
[19:34] <ogra> depends on the track
[19:35] <ogra> i.e. the last update to the 5.0 track was in april
[19:35] <leftyfb> at the time this was the 3.x track
[19:35] <ogra> which has not been updated since 2019 now 🙂
[19:36] <leftyfb> this was several years ago
[19:36] <ogra> right, i assumed so
[19:36] <leftyfb> regardless, now my global robotics company is afraid of snaps
[19:36] <ogra> just saying ... if you pick an older stable tack, you wont see many updates
[19:36] <leftyfb> that should worry some people
[19:36] <leftyfb> yes, that's the idea
[19:37] <leftyfb> oh , wait
[19:38] <leftyfb> is it guaranteed that we will always be able to install those older tracks?
[19:38] <ogra> if it is for a company, you can nowadays use the snap store proxy in airgapped mode ....
[19:38] <leftyfb> we looked at that, it doesn't freeze versions indefinitely. 
[19:38] <ogra> i'm pretty sure they wont go away, but that is up to the packager in the end ... they can ask for deletion
[19:38] <ogra> err
[19:38] <ogra> in airgapped mode it has to 
[19:39] <ogra> how would it get the packages or info when it is airgapped ? 😉
[19:39] <leftyfb> how do you install?
[19:39] <ogra> you download from outside the network and dump snap and assertion file in place from i.e. usb stick 
[19:39] <ogra> or through sshfs or whatnot
[19:40] <leftyfb> that's what we're doing now sans proxy
[19:40] <ogra> th proxy then acts like a local store
[19:40] <leftyfb> and killing snapd :)
[19:40] <ogra> right, the proxy saves you from killing snapd
[19:40] <ogra> (ad losing effectively all snap functionality)
[19:41] <leftyfb> snapd saves me from building, maintaining and running a proxy server :)
[19:41] <ogra> building ? 
[19:42] <leftyfb> it needs to be installed on a server of some sort right?
[19:42] <leftyfb> and configured?
[19:43] <leftyfb> and said server needs to be installed and configured
[19:43] <ogra> ah, right, well, it could be an lxd container 😉
[19:44] <arg_> cause its all containned in 1 single file, easier to work with, download whatever.
[19:44] <leftyfb> either way, this is a VERY simple feature that is part of every other packaging system on the planet and is left out "for our own good"
[19:45] <ogra> not *every* but yeh, most ... 
[19:45] <ogra> (i'm pretty sure you can not prevent apk's or IOS apps from updating either)
[19:46] <leftyfb> you can
[19:46] <ogra> easily ? (i honestly never tried 🙂 )
[19:47] <arg_> ban the server IPs but it'd block playstore or other things.
[19:47] <leftyfb> ogra: yeah, it's pretty conveluted and difficult, but possible ......
[19:47] <leftyfb> you just don't click the update button for that app
[19:47] <ogra> right, as "easy" as blocking snap updates then
[19:48] <ogra> (you can point api.snapcraft.io to localhost in /etc/hosts and whanot) 
[19:49] <leftyfb> iOS has the ability to auto-update it's apps but it's not enabled by default. So you literally have to do nothing to freeze a version of an app. I'm not sure if Android has the ability to auto-update, but I know if you don't click on the update button for each app on my Android devices, they do not update on their own
[19:49] <leftyfb> I'm running an app on an iphone 4 that was removed from the app store years ago
[19:50] <leftyfb> updating it at one point would have removed it
[19:50] <ogra> hmm must be a smasung thing that i can not easily stop auto-upgrades on my phone 
[19:50] <ogra> (though i never dug into that deeply)
[19:50] <ogra> *samsung
[19:51] <leftyfb> you asked about apk's packaging system. It gives you the option of not updating. Samsung and all the rest of the fragmented implementations of Android love to run their own tools on top to do what they want
[19:52] <ogra> right .. i judged by my phone 
[19:52] <leftyfb> either way, the point still stands. It's a poor decision to omit the ability to NOT update a snap package
[19:53] <sarnold> how many VMs does your phone run?
[19:53] <ogra> dunno ... my ubuntu phone ran multiple 😉 
[19:54] <arraybolt3[m]> You can run QEMU on Android using Termux.
[19:54] <leftyfb> to be fair, that's kinda how android works right? Pretty similar to snap. Lots of little self-contained applications?
[19:54] <ogra> no idea if (and how many) are running in samsungs android clone 
[19:55] <ogra> well, they are containerized ... not necessarily VMs though