| === genii is now known as genii-core | ||
| cpaelzer | is anyone, maybe a +1 looking at https://bugs.launchpad.net/ubuntu/+source/wireshark/+bug/1961901 ? | 07:32 |
|---|---|---|
| ubottu | Launchpad bug 1961901 in wireshark (Ubuntu) "3.6.2-1 FTBFS in Jammy on x86/s390x" [Undecided, New] | 07:32 |
| mirespace | cpaelzer: I can take a look | 08:24 |
| paride | cjwatson, hi! python3-paramiko doesn't seem to play well with OpenSSH 8.8, not even the version in Jammy (2.8.1-1ubuntu2) | 11:18 |
| paride | cjwatson, I can reproduce the issue in a venv installing the same version from pip, while paramiko 2.9.1 seems to be working fine | 11:19 |
| paride | cjwatson, given that paramiko is in main, should we move ahead packaging a new version, possibly going ahead of Debian? | 11:20 |
| paride | seb128, ^^ I was hoping to backport src:paramiko to Bionic in a PPA, but not even Jammy's version works | 11:22 |
| paride | I think we need paramiko 2.9.1 (https://github.com/paramiko/paramiko/issues/1955) | 11:22 |
| ubottu | Issue 1955 in paramiko/paramiko "paramiko ssh server (2.9.0) always rejects authentication with rsa-sha2-256 and ssh-rsa publickey algorithms" [Closed] | 11:22 |
| === d1b_ is now known as d1b | ||
| * paride goes to file a proper bug | 11:30 | |
| seb128 | paride, it's quite unfortunate :-/ | 11:37 |
| seb128 | paride, thanks for poking at the issue though! | 11:38 |
| paride | https://bugs.launchpad.net/ubuntu/+source/paramiko/+bug/1961979 | 11:45 |
| ubottu | Launchpad bug 1961979 in paramiko (Ubuntu) "Can't connect to Jammy hosts (openssh >= 8.8p1-1)" [High, New] | 11:45 |
| ahasenack | good morning | 12:08 |
| ahasenack | apw: hi, around? Need to ask you about the order of Depends in this wireguard package: https://pastebin.ubuntu.com/p/vzgnZWjSGy/ | 12:09 |
| ahasenack | specifically, why is wireguard-dkms (in universe) first | 12:09 |
| ahasenack | considering the kernel part of wireguard is in the ubuntu kernel already | 12:09 |
| apw | ahasenack, which series are you seeing that in. | 12:15 |
| ahasenack | apw: jammy | 12:15 |
| ahasenack | I wanted to put wireguard-modules first | 12:16 |
| ahasenack | I remember seeing somewhere that maybe cloud images, all or some, don't have that provides | 12:16 |
| apw | ahasenack, not sure why it matters | 12:16 |
| apw | ahasenack, which would be a bug in the cloud kernels rather | 12:16 |
| ahasenack | apw: wireguard has an approved MIR, and if I put bin:wireguard in main, wireguard-dkms will show up in component mismatches | 12:16 |
| ahasenack | or so I'm told | 12:16 |
| ahasenack | I think I'm starting to remember better what I read, and it was that in a cloud, if you installed wireguard, it would pull in a non-cloud kernel (like generic), instead of keeping, let's say, the azure kernel installed | 12:18 |
| apw | ahasenack, really? i would have expected that to be run in an environment with a kernel; _or_ it to always want -dkms regardless of order. | 12:18 |
| ahasenack | as you say, might be a bug in the cloud kernel then if it doesn't provide wireguard-modules, but it's a high visibility one | 12:18 |
| ahasenack | today, if you have a kernel that provides wireguard-modules, and do apt install wireguard, it will not pull in dkms, because the other dep is satisfied and installed already | 12:19 |
| apw | ahasenack, isn't that the reason it needs to be this way round? so that if you install this with a personal kernel, or a kernel without support you get the dkms not another kernel. | 12:19 |
| ahasenack | that could be the reason, yes | 12:19 |
| ahasenack | interesting | 12:19 |
| ahasenack | of course, installed kernel can be != running kernel | 12:20 |
| apw | ahasenack, likely the right thing to do is action the MIR and see what does actually happen. it may be this cannot be resolved without fixing the report. | 12:20 |
| ahasenack | but that's another issue | 12:20 |
| apw | ahasenack, an issue for sure; one which apt/dpkg cannot cope | 12:20 |
| ahasenack | for the MIR, because of this, I was more conservative and seeded bin:wireguard-tools | 12:20 |
| ahasenack | and then vorlon asked hm, why | 12:20 |
| apw | ahasenack, i suspect you may have just found out why you wanted to do that :) | 12:21 |
| ahasenack | "so that if you install this with a personal kernel, or a kernel without support you get the dkms not another kernel." ? | 12:21 |
| ahasenack | I think I'm fine with that argument | 12:21 |
| ahasenack | I'll refer this discussion to vorlon when he comes online later today | 12:22 |
| apw | yeah, this is a very important outcome, getting a generic kernel installed, which you don't run and doesn't give you wireguard is not going to solve ones request | 12:22 |
| ahasenack | true | 12:23 |
| ahasenack | dkms will install, build, and you can use wireguard right away | 12:23 |
| ahasenack | but it will be a different version from wireguard-tools (userspace) | 12:23 |
| ahasenack | I think that happens already | 12:23 |
| ahasenack | with the version we have in the kernel and the version of wireguard-tools we ship | 12:24 |
| apw | indeed. | 12:24 |
| apw | i am not sure there is a lot of testing done to even make sure it works | 12:24 |
| apw | all of that said, you would struggle in later series to get a kernel without it included | 12:24 |
| apw | as it is formally upstrea | 12:24 |
| ahasenack | nice, I thought it was a patch from us | 12:25 |
| ahasenack | like zfs | 12:25 |
| apw | ahasenack, no it is formally upstream as of a fair time ago. 5.10 or something. | 12:26 |
| ahasenack | ok | 12:27 |
| cjwatson | paride: Hm yes, https://www.paramiko.org/changelog.html does seem to indicate that we need 2.9 | 12:28 |
| cjwatson | paride: paramiko isn't one of the implementations that OpenSSH does interop testing against (in its autopkgtests, but the interop tests come from upstream). Maybe we should try to get that fixed at some point | 12:30 |
| cjwatson | paride: So moving ahead of Debian is probably fine, but we should escalate the bug to Debian as well since it's going to have the exact same problem | 12:31 |
| paride | cjwatson, yes I see no Debian bug reports about this issue | 12:31 |
| ahasenack | I worked with the audit package in the past year, and was looking at it in jammy, and foun out we are applying an unneeded delta: https://bugs.launchpad.net/ubuntu/+source/audit/+bug/1961981 | 12:34 |
| ubottu | Launchpad bug 1961981 in audit (Ubuntu) "Current delta applied twice, not needed" [Undecided, New] | 12:34 |
| ahasenack | we should get that package also updated, because of the newer kernel we have in jammy | 12:34 |
| * ahasenack hops on to ubuntu-security, since they are the maintainers | 12:36 | |
| seb128 | cjwatson, paride, I don't understand the details of the situation but if older Ubuntu serie paramiko aren't going to be able to connect to updated machines anymore should we try to SRU compat fixes to paramiko to older series before the LTS is out to try to minimize disturbance for users? or is that sort of changes probably not going to be ok for a SRU? | 13:08 |
| ahasenack | ginggs: are you guys then going to handle libapache2-mod-python? | 13:26 |
| ahasenack | updating it to master, before FF tomorrow? | 13:27 |
| ginggs | ahasenack: i'm about to upload | 13:27 |
| ahasenack | \o/ | 13:27 |
| cjwatson | seb128: Perhaps. I haven't looked at the changes here; I know that for Twisted (where I implemented corresponding changes) they were moderately involved because of needing to add extension negotiation first | 13:29 |
| cjwatson | seb128: I guess it depends on how much paramiko is used in practice as a client for servers that no longer accept RSA SHA-1 signatures | 13:29 |
| seb128 | I 've no idea about that and I'm unsure if we have data we can use to have an idea? | 13:30 |
| cjwatson | mm, not sure | 13:36 |
| paride | seb128, I think it's difficult to get useful data, even how popular a package is won't tell much about how it's used in practice | 13:36 |
| paride | ansible depends on python3-paramiko, for sure that's going to break some setups | 13:37 |
| cjwatson | classically paramiko's main use in practice in Ubuntu was I think in bzr/brz; LP still accepts SHA-1 sigs though | 13:37 |
| cjwatson | (or maybe just the main use I was aware of) | 13:37 |
| paride | and then there are two openstack related packages: python3-nova python3-cinder | 13:37 |
| paride | and also python3-os-xenapi | 13:38 |
| rpittau | coreycb, doko, hi! Any news on the python3.10 package for ubuntu focal ? :) | 13:38 |
| coreycb | rpittau: I haven't seen anything yet in focal. doko will know better on focal status. py3.10 is in jammy now (not just jammy-proposed) so that has probably been priority. | 13:45 |
| rpittau | coreycb: thanks! I'll wait for doko then :) | 13:45 |
| doko | yeah, sorry, feature freeze approaching ... | 13:45 |
| coreycb | doko: are you still planning to backport to focal? | 13:46 |
| doko | coreycb: I do | 14:17 |
| coreycb | doko: awesome, thanks | 14:22 |
| rpittau | thanks doko :) | 14:24 |
| cjwatson | LP builders are all running a focal base image now, so 5.4 kernel. Let us know if you see anything amiss | 14:30 |
| tumbleweed | \o/ | 14:35 |
| ricotz | ginggs, ahasenack, hi, is it fine if I upload a new libreoffice version? this will affect the python-default transition | 14:46 |
| ahasenack | ricotz: is it about the dep8 failures? | 14:50 |
| ahasenack | I think I retried some of those under openldap | 14:50 |
| ahasenack | yeah, it's green now: https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#openldap | 14:50 |
| ricotz | ahasenack, just a new libreoffice version without further changes | 14:51 |
| ricotz | *new upstream version | 14:52 |
| ahasenack | well, this is the right palce to ask | 14:52 |
| ahasenack | I don't have an answer, sorry | 14:52 |
| ricotz | ahasenack, I am just asking to avoid delay for python | 14:52 |
| ahasenack | just that tomorrow is feature freeze day | 14:52 |
| ricotz | this is not about FFe | 14:52 |
| ricotz | (this a new RC upload - 7.3.1~rc2) | 14:53 |
| ricotz | build + autopkgtest might take like 24 hours | 14:54 |
| ricotz | ahasenack, ^ | 14:55 |
| ahasenack | I understand, but I can't speak for the status of the python3.10 transition | 14:56 |
| ricotz | ahasenack, so I take it that the python-default transition is not ready that soon? | 14:56 |
| ricotz | ah ok | 14:56 |
| ahasenack | it's close, I see 2 packages with red tests only: https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#python3-defaults | 14:57 |
| ahasenack | libapache2-mod-python I know will be green once it tries the new version that ginggs just uploaded | 14:57 |
| ahasenack | python-pip I don't know what's going on | 14:57 |
| ricotz | there are some implicit dependencies as well | 14:57 |
| * ahasenack -> lunch | 14:58 | |
| ricotz | I see, thanks | 14:59 |
| rbasak | seb128: do you have an opinion on bug 1961092 please? Can we just drop the recommends entirely? | 15:07 |
| ubottu | Bug 1961092 in libnotify (Ubuntu) "Installing collectd pulls in the X.org stack" [Medium, Triaged] https://launchpad.net/bugs/1961092 | 15:07 |
| seb128 | rbasak, sorry for not responding, I saw your email ping, week is busy with feature freeze, I will do later | 15:17 |
| rbasak | seb128: thanks. I'm asking today because I wondered it if impacted feature freeze. If you don't think so then we can leave it for now. | 15:18 |
| seb128 | rbasak, Debian added it for a reason, I need to do some history and check with the other pkg-gnome members there | 15:18 |
| seb128 | rbasak, it doesn't from my perspective | 15:18 |
| rbasak | OK it can wait then. Thanks! | 15:18 |
| seb128 | np! | 15:18 |
| rbasak | schopin: do you have an opinion on https://code.launchpad.net/~eivnaes/ubuntu/+source/ppp/+git/ppp/+merge/415397 please? It seems like a reasonable request to carry patches from the upstream master branch for proper SSTP support, but maybe very late in the cycle to bring it into Jammy. | 15:21 |
| rbasak | And FF is tomorrow. | 15:21 |
| bluca | vorlon: hi - a little bird (TM) told you me you are the right person to annoy w.r.t. i386 libraries | 15:27 |
| bluca | any chance you could please help with https://bugs.launchpad.net/ubuntu/+source/ubuntu-meta/+bug/1961610 ? | 15:27 |
| ubottu | Launchpad bug 1961610 in ubuntu-meta (Ubuntu) "i386: seed inclusion for libfakechroot" [Undecided, New] | 15:27 |
| bluca | missing libfakechroot is blocking the migration of init-system-helpers from proposed | 15:27 |
| bluca | it's used for tests - I knew that adding tests was a bad idea :-) | 15:28 |
| schopin | rbasak: on paper that sounds reasonable but the patch is sizeable. I'll look into the particulars and get back to you before EOD (UTC) | 15:33 |
| rbasak | Yeah I was concerned about the amount of refactoring. Seems late in our cycle for that so I'm not sure which side of the trade-off is appropriate. Thanks for looking. | 15:36 |
| rbasak | I also wonder if the small fix is useful on its own. Might have to ask the contributor that if we don't want the big patch. | 15:37 |
| schopin | rbasak: ironically it seems the fix started off being small (but hackish): https://github.com/ppp-project/ppp/pull/259 | 15:48 |
| ubottu | Pull 259 in ppp-project/ppp "Allowing storage space for 32-bytes MPPE keying material." [Closed] | 15:48 |
| rbasak | schopin: one thought. This seems like the sort of change that we might be putting into ppp in a later SRU anyway. So it might be worth taking it now and asking this contributor to test it hard before release instead. | 15:54 |
| schopin | Really? I'm still not clear on what's a reasonable SRU, so I'll defer to you but that does sound reasonable to me :) | 15:56 |
| * schopin keeps looking at the patch nonetheless. | 15:56 | |
| === genii-core is now known as genii | ||
| vorlon | bluca: thanks for the ping. we'll rather solve this instead by marking the test failure as acceptable on i386, since no user is ever going to be installing the i386 version of this package on a real system | 16:00 |
| vorlon | apw: note that the wireguard handling here is quite inconsistent with the zfs handling (cc: ahasenack) | 16:01 |
| ahasenack | you mean who is doing the provides, the metapackage or the actual image kernelo? | 16:02 |
| vorlon | bluca: oh, except I see that these are build-time tests not runtime | 16:02 |
| vorlon | bluca: yeah in that case it may be simpler to just add the binaries | 16:03 |
| vorlon | ahasenack: both which package is doing the provides; and the fact that zfs-dkms is provided by our kernels | 16:03 |
| ahasenack | ok, good parallel | 16:03 |
| bluca | vorlon: yes it's just a build-time test, which uses fakechroot | 16:05 |
| bluca | the init-system-helpers build doesn't even start because there's no libfakechroot:i386 available, so it's blocked there | 16:06 |
| schopin | slyon: thanks for the tpm2-tss upload :) | 16:07 |
| slyon | yw! | 16:08 |
| rbasak | schopin: features for Internet protocol compatibility can be added in an SRU as the world changes around us. And this seems reasonably important for interoperability? So if someone credible were to drive it, I think it probably would be accepted in an SRU. | 16:24 |
| schopin | Thanks for the explanation :) | 16:26 |
| xnox | sforshee: yeap, will look into them. | 16:52 |
| cpaelzer | doko: IIRC mclemenceau has asked you to subscribe to and promote llvm-toolchain-13 | 19:03 |
| cpaelzer | doko: but I've seen today that things depending on it are still stuck | 19:03 |
| cpaelzer | doko: did any blocker come up or is this just still waiting to be handled? | 19:04 |
| cpaelzer | actuallly let me extend this by ... or was this handled and I look at non updated data :-/ | 19:05 |
| mmikowski | ahasenack: re zfs, thank you! | 19:05 |
| cpaelzer | doko: yeah it is handled already and instead is now juet entangled by ocaml things | 19:06 |
| ahasenack | mmikowski: I take it you found something interesting to play with? :) | 19:06 |
| cpaelzer | doko: it said waiting on llvm and I assumed this was still the component mismatch, but it is ocaml | 19:07 |
| cpaelzer | so TL;DR sorry for the noise ... | 19:07 |
| mmikowski | ahasenack: definitely some interesting leads. I'm finishing up with another POC, but will then follow up. But this definitely gets me started. | 19:16 |
| mmikowski | so thanks again. | 19:18 |
| kees | anyone know when is Ubuntu planning to stop building arm32 kernels/images? https://nullr0ute.com/2022/02/short-history-of-armv7-armhfp-arm32-in-fedora/ | 19:23 |
| mwhudson | kees: don't take this as anything definitive but i don't think it'll be soon | 20:09 |
| mwhudson | (much as i would selfishly like to stop having to care about it) | 20:10 |
| mmikowski | mwhudson: Nooo! My original Jetson TK1 board! (just kidding, although it was awesome 6 years ago). | 20:22 |
| kees | mwhudson: heh, okay, noted :) | 22:09 |
| mwhudson | i wonder if this is going to mean, e.g., less attention to y2038 from glibc upstream | 22:10 |
| amurray | mwhudson: hey, I see you TIL for libseccomp in jammy - I was going to do a merge of it today to get it in before FF but wanted to check you weren't already on it | 23:08 |
| mwhudson | amurray: i am not on it | 23:08 |
| amurray | no worries | 23:08 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!