[08:29] <xypron> I am looking for a sponsor for LP #1980519
[08:36] <cpaelzer> Hi xypron I've looked at it and have nothing to complain but lack expertise in regard to flash-kernel - maybe waveform (last merge) or alexghiti (added real risc HW) can help you?
[08:37] <waveform> I'm having a look now
[08:58] <Unit193> vorlon: Howdy, a long time ago you added https://sources.debian.org/src/irssi/1.2.3-1/debian/patches/20fix_ssl_proxy_hostname_check/ to Irssi.  Is it even useful in this day and age?  I'd think it'd be time to drop that, moreso since upstream plans to remove that since it never really panned out.
[10:10] <xnox> sforshee:  did copy package to sponsor them into all the -proposed queues.
[10:10] <xnox> sforshee:  kinetic is obviously gonna build and migrate soon; not sure about SRUs. Also not sure what we are supposed to do with ESM series. Or who is supposed to do those.
[10:36] <bluca> juliank: do you have a launchpad ticket we can follow for the phased update problem?
[10:37] <bluca> we are hitting it again in our Github Actions jobs, as a new src:systemd phased update was published
[11:06] <gioele> hi, what is the proper way to request the re-inclusion of a package was is impish and in kinetic, but skipped jammy?
[11:06] <gioele> (more precisely, collectd: https://bugs.launchpad.net/ubuntu/+source/collectd/+bug/1971093)
[11:08] <gioele> the root cause (FTBFS of a required library: https://bugs.launchpad.net/ubuntu/+source/collectd/+bug/1960612) has now been fixed in kinetic. Should this be treated like a backport request?
[12:39] <jbicha> gioele: Backports sounds like a good way to add that package back. Are you able to prepare that backport yourself? https://wiki.ubuntu.com/UbuntuBackports
[13:20] <juliank> bluca: pleasesee https://discourse.ubuntu.com/t/call-for-testing-the-new-apt-stable-release-update-for-21-10-22-04/29372
[13:23] <bluca> ta
[15:38] <vorlon> Unit193: what is it that upstream plans to remove?  I still rely on being able to make an SSL connection to my IRC proxy
[18:18] <sforshee> xnox: thanks! I prepared packages once before for the ESM series but they were never put in the ESM archive, so I haven't bothered with them since
[21:29] <Unit193> vorlon: If you're using znc/bip that'd be normal, but I expect not.  All proxy settings are being considered for removal in 1.5, so I hear.
[21:34] <vorlon> Unit193: so it will not support proxies at all?  well that makes it useless to me
[21:50] <Unit193> vorlon: How exactly do you use it?
[21:51] <vorlon> Unit193: with bip
[21:51] <Unit193> Normally one connects directly to that, and bip connects to the network...
[21:52] <vorlon> hmm
[21:53] <Unit193> If it actually works the way this would have to, I didn't even know bip could do that..
[21:59] <vorlon> well, I could try reconfiguring my client to use bip as you describe, but when I first set this up many years ago the documentation I followed certainly suggested it was to be done as a proxy
[22:53] <Unit193> I'm gonna presume use_proxy is on.  OK, yeah I'll forward that information upstream then.
[23:14] <vorlon> Unit193: fwiw it's less of an issue for me now because I only connect to one IRC server; but work used to have an internal IRC server which meant I was using irssi to connect to multiple servers, which made the use of bip in proxy mode relevant
[23:16] <Unit193> vorlon: OK, I don't know exactly how bip works, I thought it worked more or less like ZNC which has mutiple network support, but you connect to ZNC as if it were the IRC server.  Not trying to make it harder on you or anything, if this actually works than upstream might be more interested after all.
[23:17] <Unit193> Thank you for the feedback.
[23:18] <vorlon> sure thing