[12:28] <lotuspsychje> you guys got some cases/tricks where you can LTS upgrade to the next release but only on the last point release, like 20.04==>22.04.5 for example?
[12:30] <ahasenack> that should be the case, the point release is just a tag for the iso image
[12:30] <ahasenack> the archive is always moving
[12:31] <ahasenack> and the do-release-upgrade tool will always update to the latest available packages in the archive for that release
[12:32] <lotuspsychje> ahasenack: im asking because i had some customer call doing an early 20.04==>22.04.1 and resulted in some bad bugs
[12:33] <lotuspsychje> so a last point release so it doesnt get eol would be nice
[12:34] <sdeziel> lotuspsychje: 22.04.1 is the latest point release currently available for 22.04
[12:34] <lotuspsychje> oh
[12:35] <sdeziel> 22.04.2 is planned for Feb 2023
[12:35] <lotuspsychje> yeah but i mean what if i only want an LTS upgrade on 22.04.2?
[12:37] <sdeziel> lotuspsychje: the way it works is that LTS users get proposed about LTS+1 when LTS+1 gets its first point release (.1). Users are free to wait for the second point release to be available before doing the jump
[12:37] <ahasenack> I don't think you can configure do-release-upgrade to filter on point releases of the target
[12:37] <ahasenack> it's what sdeziel said, but after .1 is released, then do-release-upgrade will do the upgrade if asked
[12:38] <lotuspsychje> ok tnx
[12:38] <lotuspsychje> i also dont wanna disable lts upgrades on my customers
[12:39] <lotuspsychje> so i was wondering if some trick existed
[12:43] <sdeziel> lotuspsychje: which bugs have they hit?
[12:49] <frickler> the usual "trick" would be to have a local mirror of upstream repos, then you can snapshot 22.04.1 when it is released and have consistent upgrades. aptly ftw.
[13:13] <lotuspsychje> sdeziel: the customer in question, was a desktop (laptop) resulted in an intel flickering bug on 5.15 and fixed from 5.17, FF snap update does not yet support belgian EID card reader, so i had to install chrome temporary and cheese is still borked on 22.04 aswell
[13:13] <lotuspsychje> sdeziel: so in a bit more time (point releases) those might be fixed
[13:17] <sdeziel> lotuspsychje: that's unfortunate.. As for alternatives for Firefox, I quite like chromium which is one `snap install chromium` away ;)
[13:17] <lotuspsychje> i think chromium was also a part of that bug sdeziel 
[13:17] <sdeziel> dunno if Chromium's snap support the belgian EID card reader ... maybe it's a snap limitation/issue?
[13:17] <lotuspsychje> bug #1741074
[13:18] <lotuspsychje> yeah it is
[13:18] <lotuspsychje> they working on it for sure
[13:18] <sdeziel> good, at least there is something to track
[13:19] <lotuspsychje> yeah its all known bugs, but not so good for my customers
[13:20] <lotuspsychje> bug #1958191 for the flickering
[13:21] <lotuspsychje> and bug #1949183 +upstream for cheese
[13:25] <sdeziel> I subscribed to those likely to affect me, thanks!
[13:25] <lotuspsychje> np sdeziel 
[13:26] <lotuspsychje> would be nice to have an LTS upgrade feature for extreme paranoia admins lol
[14:35] <kanashiro[m]> ahasenack: I have an initial version of the pcs MIR bug, could you take a look? LP #1953341 
[15:01] <ahasenack> kanashiro[m]: will do (after lunch)
[18:17] <kanashiro[m]> ahasenack: FWIW I am already starting to work on the MIR template for the ruby dependencies needed
[18:17] <ahasenack> ok
[19:17] <kanashiro[m]> ahasenack: ruby-open4 which is one of the dependencies seems dead upstream (no activity since 2013): https://github.com/ahoward/open4 
[19:18] <ahasenack> not a good mir candidate :/
[19:19] <kanashiro[m]> meh, this is a good start..
[19:58] <kanashiro[m]> ahasenack: do you think it is worth to write a patch to depend on something else instead of ruby-open4?
[20:09] <ahasenack> otp
[22:14] <ahasenack> kanashiro[m]: would that be simple?
[22:15] <ahasenack> assuming there is another popen-like ruby module out there
[22:15] <ahasenack> maybe file a bug with upstream, see what they think. But just "nothing new since 2014" might not be enough of a reason
[22:17] <sarnold> "oh good that means it's perfect" :)
[22:18] <sarnold> I thought ruby had popen baked into the kernel's open() function: https://apidock.com/ruby/Kernel/open
[22:18] <kanashiro[m]> ahasenack: I could try to move to posix-spawn or childprocess gems, and of course this would be submitted upstream 
[22:19] <ahasenack> kanashiro[m]: maybe keep that as an option, but don't work on it yet
[22:19] <kanashiro[m]> I will start filling a bug as you mentioned to see what they think 
[22:19] <ahasenack> is it used in a lot of places?
[22:19] <ahasenack> the code from that module, I mean
[22:20] <ahasenack> (just looking for a quick grep, not a deep analysis)
[22:51] <kanashiro[m]> Not in many places