=== Unit193 is now known as JackFrost
[05:09] <doko> rbasak: yes, didn't have an explicit transition tracker for that. now uploaded
[07:34] <cpaelzer> rbasak: if you have some +1 power/time left to spare today I've just seen that wireshark is an FTBFS now and IIRC it has no owning team
[08:47] <GunnarHj> cjwatson: As regards fonts-ubuntu: Unless you have a brilliant solution offhand, I'm inclined to give up and keep a diff between Debian and Ubuntu.
[08:47] <GunnarHj> https://salsa.debian.org/gunnarhj/fonts-ubuntu/-/commit/002b5c39
[08:47] <ubottu> Commit 002b5c3 in gunnarhj/fonts-ubuntu "debian/rules: Reverse control hack for Ubuntu"
[10:00] <slyon> didrocks: hey! sorry for asking for more testing around bug #1960500 but I suggested two easy cases that should be really simple to implement and will benefit all of us :)
[10:00] <ubottu> Bug 1960500 in libxcvt (Ubuntu) "[MIR] libxcvt" [Undecided, New] https://launchpad.net/bugs/1960500
[10:02] <slyon> oh I guess this MIR was actually done by tjaalton ^
[10:08] <didrocks> slyon: yeah, this is not really part of desktop team realm :) And agreed with you
[10:16] <tjaalton> I knew it
[10:17] <tjaalton> slyon: #1 and #2 are the same thing?
[10:18] <slyon> tjaalton: yes. I prefer #1. but if there is some manual testing story, we could downgrade it to #2
[10:19] <slyon> tjaalton: have a look at protobuf-c's ubuntu delta, I've implemented a test there for libprotobuf-c that you can pretty much copy & paste, with minor adoptions
[10:34] <tjaalton> guess I'll just use cvt.c with hardcoded defaults
[10:46] <slyon> wfm
[10:50] <tjaalton> uploaded to sid
[11:21] <cjwatson> GunnarHj: I had a look last night and all the other approaches I could think of were worse.
[11:26] <ahasenack> morning
[11:58] <xypron> libcrypt-openssl-rsa-perl is currently stuck with "libcrypt-openssl-rsa-perl blocking libcrypt-openssl-random-perl (0.15-2build3 to 0.15-2build4) for 11 days". Executing the autopkgtest locally against jammy-proposed shows that the missing dependency is fixed. Could someone, please, be so kind as to trigger a rebuild: https://autopkgtest.ubuntu.com/request.cgi?release=jammy&arch=amd64&package=libcrypt-openssl-rsa-perl&trigger=
[11:58] <xypron> libcrypt-openssl-random-perl%2F0.15-2build4
[13:26] <ahasenack> does anybody know if something changed in jammy recently regarding debconf prompts, debconf-set-selections, etc?
[13:42] <xnox> GunnarHj: jbicha: if i recall correctly the build itself cannot control dpkg-genchanges which is executed by lp-buildd/sbuild. and it does compare the contents of .dsc i thought. However i also thought we had something somewhere to allow building non-free in restricted or multiverse. But I don't think we support building Debian's non-free in Ubuntu's main.
[13:43] <xnox> i'll try to look where we have this non-free => (restricted,multiverse) mapping, and if we could hack fonts-ubuntu into that.
[13:44] <xnox> GunnarHj:  jbicha: the "non-free/" prefix in .dsc is required for Debian right? (i have never done non-free uploads into debian)
[13:52] <jbicha> xnox: fonts-ubuntu has always been in main; this is just about hacking the metadata. It's not a big deal; we can keep an Ubuntu diff here
[13:58] <xnox> jbicha: yes i understand all that. but in launchpad, when importing .dsc with non-free/* we only allow to build it into multiverse & restricted; not main. and it's not really about the diff/metadata of the .deb; but what is listed in .dsc vs .changes.
[14:00] <xnox> and debian/rules cannot change .dsc => or rather shouldn't. I hope .dsc is immutable during the launchpad build.
[14:00] <jbicha> I don't understand what you're saying about not being able to build non-free into main. There's https://launchpad.net/ubuntu/+source/fonts-ubuntu/0.83-2
[14:06] <xnox> jbicha: interesting, but that's bionic.
[14:09] <jbicha> personally, I don't think it's worth spending much time on this :)
[14:10] <GunnarHj> xnox: Our only problem is that vrms lists fonts-ubuntu as non-free (even if it's in "main"), which makes some users tend to think they should uninstall it, and with that uninstall important reverse dependencies.
[14:10] <GunnarHj> jbicha: Agreed. I'll submit a MR with a reversal in a minute.
[14:13] <cjwatson> xnox: The only thing Launchpad does with non-free is to set the initial default component override to multiverse.  Nothing else.
=== Nafallo_ is now known as Nafallo
[14:19] <xnox> cjwatson:  ack. will check dpkg-genchanges evolution. it looks like it became more strict over time. with current behaviour different to the past. And yeah, we don't really care about component/ prefix in launchpad, as we handle that separately.
[14:48] <fheimes> hello archive admins - would you mind having a look at libzdnn in jammy's new queue (and ideally accepting it)?
[14:49] <schopin> fheimes: you'll have better luck asking in #ubuntu-release
[14:50] <fheimes> ok - will ask there
[15:10] <enr0n> fheimes: I am taking a look at LP #1960255. Do you have access to a P8 system to grab some extra info (/proc/cpuinfo etc.)?
[15:10] <ubottu> Launchpad bug 1960255 in ubuntu-release-upgrader (Ubuntu Jammy) "Prevent do-release-upgrades on P8 systems from focal or impish to jammy" [Undecided, New] https://launchpad.net/bugs/1960255
[15:13] <fheimes> @enr0n there is the PowerMAAS environment that has some P9s and serveral P8s, yes
[15:13] <fheimes> @enr0n do you have access to that? (in case not, do you want?)
[15:16] <fheimes> enr0n: deploying a P8 system ...
[15:18] <enr0n> fheimes: I do not believe I have access, not sure I would need access myself just yet. Just looking to confirm a way to check for P8 during upgrade.
[15:23] <fheimes> enr0n: ok (thought about testing or so) - anyway, deployment of 20.04 on a P8 system is ongoing (takes quite some time ...)
[15:25] <enr0n> fheimes: ok, thanks! I will update the bug report now with the specific info I am looking for
[15:29] <fheimes> enr0n ok, I'll then paste the cpuinfo data there ...
[15:31] <enr0n> fheimes: thanks I appreciate it
[15:33] <fheimes> enr0n I actually have the info already: https://pastebin.ubuntu.com/p/mKtMTzhSpn/
[15:35] <enr0n> fheimes: awesome. Would you mind running `apt-config dump | grep APT::Architecture` as well please?
[15:36] <fheimes> yepp, but that only provides architecture info and doesn't distinguish between the processors ...
[15:36] <fheimes> https://pastebin.ubuntu.com/p/RWFgTDG3qF/
[15:36] <fheimes> enr0n ^
[15:41] <enr0n> fheimes: right. Thanks again for getting that info
[15:41] <fheimes> np
=== genii-core is now known as genii
[16:37]  * ogra just notices that his 20.04 system still has mountall installed ... shouldnt update-manager have removed it at some point ? 
[16:47] <ahasenack> wow, that's... old
[16:47] <ahasenack> were you release upgrading for a long time?
[16:47] <ahasenack> does apt-get autoremove try to remove it?
[17:19] <enr0n> vorlon: I am looking for a sponsor for LP #1961266. It addresses a TODO for the plocate MIR, so I thought you would be the person to ask.
[17:19] <ubottu> Launchpad bug 1961266 in plocate (Ubuntu) "remove debian/source/include-binaries file from plocate package" [Medium, Triaged] https://launchpad.net/bugs/1961266
[17:40] <juliank> enr0n: If it's not urgent, it's also worthwhile seeing if it can find a sponsor outside the team, so that when you apply for upload rights, you also have some community endorsements
[17:40] <juliank> (jfyi)
[17:41] <juliank> but it might be urgent here, just keep it in mind :)
[17:43] <enr0n> juliank: thanks that's good to know :)
[18:12] <ahasenack> hi, members of the MIR team (main inclusion request), the security team ACKed two MIRs that are on my plate, and I think they are ready now, could someone please take a look at the bug status and confirm that?
[18:12] <ahasenack> they are https://bugs.launchpad.net/ubuntu/+source/libyang2/+bug/1958293 and https://bugs.launchpad.net/ubuntu/+source/wireguard/+bug/1950317
[18:12] <ubottu> Launchpad bug 1958293 in libyang2 (Ubuntu) "[MIR]: libyang2" [Critical, In Progress]
[18:13] <ubottu> Launchpad bug 1950317 in wireguard (Ubuntu) "[MIR] Wireguard" [Critical, Confirmed]
=== JanC is now known as Guest5415
=== JanC_ is now known as JanC