[00:52] <xnox> cpaelzer: is there llvm skew on riscv64? as bpftool needs llvm which might be still building on riscv or some such?
[00:53] <xnox> possibly worth a ping to arighi / paulo on ubuntu-kernel here, or on matrix kernel chanel
[11:50] <slyon> @pilot in
[13:34] <ahasenack> I'm really starting to dislike jupyter-* packages
[13:36] <ahasenack> fix one thing, another one pops up
[13:50] <ahasenack> amd64 builders are, er, loaded?
[13:50] <ahasenack> "start in 35min"
[14:01] <slyon> sudip: Hey! I'm currently looking at your proposed lptools merge in https://code.launchpad.net/~sudipmuk/ubuntu/+source/lptools/+git/lptools/+merge/460236, can you explain why you changed the Recommends/Depends in d/control?
[14:02] <sudip> slyon: https://bugs.launchpad.net/ubuntu/+source/lptools/+bug/2052680/comments/1
[14:02] -ubottu:#ubuntu-devel- Launchpad bug 2052680 in lptools (Ubuntu) "Please merge lptools 0.3.0 (universe) from Debian unstable (main)" [Undecided, Confirmed]
[14:04] <slyon> sudip: oh thanks! I missed the linked bug report :)
[14:05] <sudip> :)
[15:24] <dbungert> ahasenack: I am 3 bugfixes deep trying to get jupyter-notebook to migrate.  Are you working on LP: #2054342 ?  I think the proposal to "limit jupyter-client to < 8" should be seriously considered.
[15:24] -ubottu:#ubuntu-devel- Launchpad bug 2054342 in jupyter-notebook (Ubuntu) "FTBFS (test failure) with jupyter-client >= 8" [Undecided, New] https://launchpad.net/bugs/2054342
[15:28] <slyon> sudip: Can you please comment on https://bugs.launchpad.net/ubuntu/+source/digimend-dkms/+bug/2052708/comments/4 ?
[15:28] -ubottu:#ubuntu-devel- Launchpad bug 2052708 in digimend-dkms (Ubuntu Jammy) "[SRU] digimend-dkms 10-4: digimend kernel module failed to build" [Undecided, Confirmed]
[15:31]  * sudip looks
[15:35] <flag> any AA around?
[15:36] <ppisati> we need a cleanup: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2054439
[15:36] -ubottu:#ubuntu-devel- Launchpad bug 2054439 in linux (Ubuntu Noble) "RM obsolete binaries from noble to allow linux to migrate" [Undecided, Confirmed]
[15:36] <ppisati> (on behalf of the kernel team)
[15:37] <sudip> slyon: replied to your comment.
[15:51] <ahasenack> dbungert: I am attempting to fix the dep8 test failure with jupyter-client 7.9.x, it now passws locally, just checking a ppa
[15:52] <ahasenack> dbungert: if that passes, we can give vorlon the go-ahead to remove jupyter-client 8.6.x from noble-proposed
[15:52] <ahasenack> and re-upload a new 7.9.x with the dep8 fix
[15:52] <dbungert> +1
[15:53] <ahasenack> I even tried a jupyter-core patch yesterday, for the jupyter-notebook ftbfs, but that didn't help
[16:00] <lvoytek> @pilot in
[16:10] <slyon> sudip: thx! sponsored
[16:11] <slyon> @pilot out
[16:13]  * slyon passing on the torch to lvoytek 
[16:36] <sudip> thanks slyon
[16:54] <ahasenack> dbungert: vorlon I have jupyter-client 7.4.9-2ubuntu1 passing dep8 in noble: https://autopkgtest.ubuntu.com/results/autopkgtest-noble-ahasenack-plusoneweek/noble/amd64/j/jupyter-client/20240220_164938_21410@/log.gz with patch https://git.launchpad.net/~ahasenack/ubuntu/+source/jupyter-client/commit/?id=8bc7ee5cf88d831f54c625d32abd00e87de3ff69
[16:54] -ubottu:#ubuntu-devel- Commit 8bc7ee5 in ~ahasenack/ubuntu/+source/jupyter-client "* d/p/ignore-datetime-warnings.patch: with python 3.12, some datetime"
[16:54] <ahasenack> it's ignoring the deprecated datetime usage from python-datetime
[16:55] <ahasenack> I figured we can update python-datetime after the python transition is done. Or I could fix python-datetime now, I juse fear it could cause a massive amount of retesting (haven't checked)
[16:55] <ahasenack> branch: https://code.launchpad.net/~ahasenack/ubuntu/+source/jupyter-client/+git/jupyter-client/+ref/jupyter-client-749-deprecated-utcnow
[16:56] <ahasenack> doko: are you ok with removing https://launchpad.net/ubuntu/+source/jupyter-client/8.6.0-0ubuntu1 from noble-proposed? You were the one who uploaded it, ahead of debian. We have exhausted our options to fix jupyter-notebook, it just doesn't work with jupyter-client >= 8.x (upstream ack'ed the breakage)
[16:57] <dbungert> ahasenack: that looks like a good plan, nice work
[16:59] <ahasenack> we just need an AA now :)
[17:02] <ahasenack> ...and for that, I should be in the right channel
[18:00] <lvoytek> sudip: I see your debdiff for LP: #2026760 for the no-change rebuild and the description look good. My only note is that for the version, since there are no changes (other than maintainer) you can just increase the build# rather than -3ubuntu0.1. So in this case it would be 4.1.0-3build2. If you'd like though I can sponsor the change and just update the #
[18:00] -ubottu:#ubuntu-devel- Launchpad bug 2026760 in wrk (Ubuntu Mantic) "[SRU] wrk fails to run" [Undecided, Confirmed] https://launchpad.net/bugs/2026760
[18:18] <ahasenack> dbungert: have you looked at ansible by any chance?
[18:18] <ahasenack> I saw a good dep8 test recently, with 9.2.0, but didn't manage to replicate it
[18:19] <ahasenack> I'll look at  libapache2-mod-python/3.5.0.1-1build1, I remember working on it in the past
[18:21] <doko> ahasenack: mkukri was working on the latter. https://bugs.launchpad.net/ubuntu/+source/libapache2-mod-python/+bug/2054133 maybe just sponsor that?
[18:21] -ubottu:#ubuntu-devel- Launchpad bug 2054133 in libapache2-mod-python (Ubuntu Noble) "Running with Python 3.12 failed because imp was removed." [Undecided, In Progress]
[18:21]  * ahasenack checks
[18:21] <dbungert> ahasenack: negative, schopin may have though
[18:23] <ahasenack> it's still being reviewed by upstream
[19:26] <sudip> lvoytek: yes, please. I was in doubt about the version but since SRU wiki says to do ubuntu0.1 so I just followed that
[19:33] <lvoytek> Alright, updated and sponsored
[19:52] <sudip> thanks lvoytek
[19:54] <lvoytek> sure thing
[19:58] <ahasenack> dbungert: [ubuntu/noble-proposed] jupyter-client 7.4.9-2ubuntu1 (Accepted)
[19:58] <sergiodj> juliank: hi, a few days ago you mentioned that the Noble chroot problem reported by tjaalton had been fixed by gnupg2/2.4.4-2ubuntu3, but I'm still seeing the error (and postfix being installed)
[19:58] <dbungert> :tada:
[19:59] <dbungert> ahasenack: I'm clicking the rebuild button on jupyter-notebook
[19:59] <ahasenack> dbungert: hold, we need it to be published first
[19:59] <dbungert> k
[19:59] <sergiodj> juliank: I'm going to remove gpg meanwhile
[19:59] <juliank> sergiodj: Are you bootstrapping it from scratch?
[20:00] <sergiodj> yes
[20:00] <juliank> sergiodj: Upgrades will continue to see the issue, but fresh bootstraps should not pull in gpg-wks-server anymore
[20:00] <lvoytek> @pilot out
[20:00] <sergiodj> juliank: I did a bootstrap from scratch and could reproduce the problem
[20:01] <sergiodj> removing gnupg from the schroot fixed the issue for now
[20:01] <juliank> sergiodj: How did you bootstrap with gnupg from proposed without installing the one in the release pocket first?
[20:01] <juliank> The one in the release pocket still depends on gpg-wks-server
[20:02] <juliank> the release pocket gpg-wks-server does not depend on mail-transport-agent though
[20:02] <juliank> so you can get mail-transport-agent by installing the release pocket first and then upgrading
[20:03] <juliank> Or something else pulling in mail-transport-agent :)
[20:03] <sergiodj> I haven't debugged it much further, but you're probably right in that mk-sbuild only enables -proposed after the initial bootstrap
[20:03] <juliank> gnupg2 should migrate any britney run now
[20:03] <sergiodj> I'll give it a try after gnupg migrates
[20:38] <ahasenack> dbungert: you can click that button now, the new jupyter-client is published
[20:43] <ahasenack> the current rebuild still used client 8.6.0
[20:43] <ahasenack> I'll click again
[20:49] <dbungert> ahasenack: debating an explicit upload on jupyter-notebook with a <8 dep on jupyter-client
[20:50] <ahasenack> unsure, but wouldn't be wrong
[20:50] <ahasenack> there is a >= already
[20:50] <ahasenack>                python3-jupyter-client (>= 5.3.4) <!nocheck>,
[21:03] <dbungert> ahasenack: build button spam success, jupyter-notebook built this time
[21:04] <ahasenack> hooray
[23:02] <dbungert> teward: maybe we should bring this to this channel.  re bios boot of the live-server candidate, I'm able to see the grub menu and "HWE kernel" entry on bios boot, is it possible the menu went by too fast?
[23:03] <teward> no, it didn't pass me up i'll reload and see if it was a bug but it didn't show HWE Kernel
[23:03] <teward> i'm finishing up UEFI now and then going to drop aother VM up to test again
[23:06] <teward> dbungert: ok it's there, but i could have sworn i saw an extra option on UEFI and the naming is inconsistent on both
[23:06] <teward> i'll dig back later, but it looks like that could've been because tiny-screen
[23:06] <teward> (4k resolution)
[23:07] <teward> (with small VM screen)
[23:08]  * tsimonq2 sends teward to fix All 4k screens
[23:08] <dbungert> there is a difference between uefi and bios boots, bios boot has "test memory" and uefi has "boot from next volume" and "uefi firmware settings"
[23:08]  * teward pushes @tsimonq2 into the abyss of Windows 3.1 disks.
[23:10] <dbungert> cruel and unusual
[23:13] <tsimonq2> friendly banter between friends :D
[23:17] <teward> but still cruel that i tossed Simon into the abyss of 3.1 disks xD