[07:37] <xypron> I am looking for a sponsor for ktexteditor 5.90.0-0ubuntu2 available in ppa:xypron/kde which fixes a bug in Kate (LP: #1958090)
[07:37] <ubottu> Launchpad bug 1958090 in ktexteditor (Ubuntu) "Kate: navigation keys do not cancel mark" [Undecided, In Progress] https://launchpad.net/bugs/1958090
=== doko_ is now known as doko
=== xnox1 is now known as xnox
=== waveform_ is now known as waveform
[10:53] <RikMills> xypron: there is no patch applied in your PPA package
[10:54] <RikMills> oh, wait, wrong diff
[11:37] <xypron> I am looking for a sponsor for "Sync cpio 2.13+dfsg-7 (main) from Debian sid (main)" LP #1958131
[11:37] <ubottu> Launchpad bug 1958131 in cpio (Ubuntu) "Sync cpio 2.13+dfsg-7 (main) from Debian sid (main)" [Wishlist, New] https://launchpad.net/bugs/1958131
=== stgraber_ is now known as stgraber
=== genii-core is now known as genii
=== ogra` is now known as ogra
[15:23] <bluca> slyon, ddstreet: hi, qq, is systemd going to be updated to v250 for Jammy?
[15:23] <bluca> there's a very nice feature for distros that allow maintainer scripts to start/stop/restart user instance units
[15:23] <bluca> I've already done the work for debian in init-system-helpers and debhelper
[15:25] <slyon> bluca: no we plan to stick with 249 for the LTS (probably updating to 249.9 stable). v250 was a big release with lots of new features and we want to stay on the safe side for the upcoming Jammy LTS release.
[15:26] <bluca> got it, thanks
[15:27] <bluca> we were a bit late with cadence last year, we'll try to do more frequent ones this year
[15:30] <slyon> yes. I was hoping for a November release of 250, as I had been planning to get it into Jammy. But we now made the call to stick with 249
[16:22] <xypron> I am looking for a sponsor for golang-github-containers-toolbox 0.0.99.2-2ubuntu1 available in ppa:xypron/gnu-efi which fixes building on RISC-V #1958132
[16:26] <slyon> ginggs: I see you're an uploader of bagel in Debian. Would you mind review/sponsoring this FTBFS fix for me? (This way I could avoid introducing an Ubuntu delta): https://paste.ubuntu.com/p/MzcPDVQPKH/
[16:27] <ginggs> slyon: sure
[16:29] <slyon> ty!
=== sem2peie- is now known as sem2peie
=== sem2peie- is now known as sem2peie
[21:14] <toddr> When upgrading from 20.04 to 21.10, do packages which have the identical version number in both repos get upgraded? Is there any way to coerce this to happen?
[21:15] <tumbleweed> no, they don't
[21:15] <tumbleweed> if the version number is *identical* it's the same binary deb
[21:16] <tumbleweed> "apt install --reinstall foo" will re-install a package
=== mfo_ is now known as mfo
[21:49] <toddr> So the problem here I'm trying to address is we have packages we build across several distros. We usually give them the same version number even though the packages would compile differently based on glibc, openssl, etc. library versions.
[21:50] <toddr> When someone switches from 20.04 to 22.04 (or 21.10, whatever), we need to detect and re-install the packages that won't function without reinstall. I can of course force a re-install of all of the binary packages but I was hoping for a trick where I might be able to set the repo priority higher or something and trick it into a automagic re-install of the same version.
[21:51] <toddr> too much to hope for? :D
[21:54] <Odd_Bloke> toddr: The way this is handled in the Ubuntu archive is to append (e.g.) ~20.04.0 to the focal version, ~22.04 to the jammy version etc.: those are different versions, and they sort in the order of the Ubuntu releases (at least until 2100 :p), so an upgrade happens when the archive containing the newer package is enabled.
[22:02] <toddr> ok thanks that helps. we're going to have to re-number our stuff but better now than later :D
[23:13] <cjwatson> Odd_Bloke: 100.04 will work too in that scheme :)
=== genii is now known as genii-core