[03:52] <lotuspsychje> morning
[05:14] <Maik_aD> good morning
[06:45] <marcoagpinto> The demon!
[07:38] <ducasse> good morning
[08:14] <marcoagpinto> morning
[09:50] <marcoagpinto> lotuspsychje!
[09:50] <marcoagpinto> Hello!
[09:50] <marcoagpinto> 20.04.1 is out!
[09:50] <marcoagpinto> I downloaded it yesterday, but too lazy to create a VM
[11:19] <DarkTrick> Question regarding the update structure for Ubuntu: With the official repos software updates are controlled by Ubuntu instead of the developer. So bug fixes don't depend solely on the developer - but in most cases - on the Ubuntu release AND a maintainer, that puts a recent version of the software inside the repos. That means: bug fixes only every 6 months or 2 years (if LTS) - and only if the maintainer updated the packages within
[11:19] <DarkTrick> the repo. Is there more information on why this structure was chosen VS e.g. a "devs can decide themselves when to release updates"?
[11:22] <daftykins> i think you're ignoring universe and PPAs with that analysis
[11:29] <tomreyn> DarkTrick: "bug fixes only every 6 months or 2 years (if LTS)" is incorrect as a general statement. it can apply to many (but not all) packages which only have community support. it can also apply to packages with non-critical bugs in 'main' and 'restricted'. but generally, at least in those sections, you will see bug fixes getting backported. a developer making those patches available seperately, or even actively supporting older
[11:29] <tomreyn> releases, certainly helps with this.
[11:31] <DarkTrick> daftykins, well my view is based on a basic setup. I'm unaware of any repo-trickery
[11:31] <daftykins> ok i think you've got some research to do :)
[11:32] <tomreyn> DarkTrick: the general idea behind this strategy is to provide version and feature stability for users for a while (the while that a release, or LTS lasts). which is what some if not many desire to not have to constantly upgrade software on their systems (which can and usually has side effects which are difficult to manage).
[11:32] <tomreyn> yes, you need to do some reading
[11:35] <DarkTrick> tomreyn, has it been different in the past?
[11:35] <DarkTrick> I'm not talking about LTS, but about the way updates are supplied
[11:36] <DarkTrick> I have a system like iOS app updates in mind, where OS updates and app updates are highly decoupled
[11:46] <lotuspsychje> DarkTrick: whats the purpose exactly of your investigation?
[11:51] <DarkTrick> lotuspsychje, Currently I see 1) speed of bug fixing is slow 2) maintenance overhead could be reduced
[11:51] <lotuspsychje> DarkTrick: there are several things that influence the speed of bug solving
[11:52] <DarkTrick> I mean: fixes and newer versions are already released, but it does not enter the repo
[11:52] <DarkTrick> There were a couple of cases for LibreOffice some years ago (I stopped tracking by now)
[11:53] <DarkTrick> or FreeCAD or KolourPaint
[11:53] <DarkTrick> As a user, that can write bug reports, I also end up spending time for things (e.g. writing reports), that are already solve, just not yet in the repos.
[11:54] <lotuspsychje> devs are doing the best they can i'm sure
[11:55] <lotuspsychje> DarkTrick: maybe if you are more interested in how package get released, try #ubuntu-release too
[11:55] <lotuspsychje> or contribute yourself, work with devs & maintainers?
[11:56] <DarkTrick> lotuspsychje, At first I would like to find the rationale behind the decision of the current situation. Perhaps #..release is a good place to start
[11:57] <lotuspsychje> DarkTrick: also these days we have a lot of snaps on ubuntu, where the maintainer pushes their updates fast, decoupled as you say from the Os
[11:57] <lotuspsychje> also something to think about
[11:58] <DarkTrick> as a user, do I see the different between snaps and "usual packages"?
[11:59] <lotuspsychje> DarkTrick: apt vs snapd, apt-cache search foo vs snap find foo
[11:59] <DarkTrick> ah
[12:00] <DarkTrick> lotuspsychje, do you happen to have an link on why that was introduced?
[12:00] <lotuspsychje> snaps?
[12:00] <DarkTrick> yes
[12:00] <lotuspsychje> !snap
[12:01] <lotuspsychje> <ubottu> Snaps are containerised software packages similar to flatpaks or appimage. For more info, see https://snapcraft.io
[12:12] <daftykins> it was introduced as an attempt to solve the fact that relying on system-wide shared libraries can be problematic when one program wants a newer version, but another program breaks on the newer version
[12:13] <daftykins> afaiui
[12:17] <tomreyn> there are some important softwares, such as what used to be web browsers (and now are the universal client software for everything), which are really difficult to maintain version stability for, where snaps and their rolling upgrade model (which snap provides - though apt could, too) can make a lot of sense.
[12:20] <lotuspsychje> i was thinking of that some times about we can still use our !latest factoid, as nowadays, a lot of 'later' snaps intrude in the LTS base system
[12:40] <DarkTrick> tomreyn, thank you for the explanation. snapcraft.io did not present it easily findable
[12:40] <DarkTrick> sry, that was @daftykins
[12:42] <daftykins> you're asking quite some basics that research online would find
[12:42] <DarkTrick> hm... snaps should be rather independent then... `snap install kolourpaint`, run it, infinite loop of invisible errors  ... if that's the alternative to the current system, I love the current one :D
[12:42] <DarkTrick> daftykins, I'm asking because I don't find it online...
[12:43] <DarkTrick> maybe I should stop using duckduckgo...? but google from Japan also sucks @ search results :/
[12:48] <tomreyn> try google.com/ncr
[12:48] <tomreyn> or startpage.com
[13:06] <daftykins> DarkTrick: yeah i don't think you're really trying though ;)
[14:42] <lotuspsychje> did you survive it Maik_aD
[14:45] <Maik_aD> lotuspsychje: sure :)
=== akem is now known as de_df_ck
=== dm2912_ is now known as dm2912