[00:01] -queuebot:#ubuntu-release- New binary: pytorch-sparse [amd64] (noble-proposed/universe) [0.6.18-2build1] (no packageset) [00:05] -queuebot:#ubuntu-release- New binary: pytorch-sparse [arm64] (noble-proposed/universe) [0.6.18-2build1] (no packageset) [01:20] -queuebot:#ubuntu-release- New: accepted gambas3 [amd64] (noble-proposed) [3.19.0-2ubuntu1] [01:20] -queuebot:#ubuntu-release- New: accepted pytorch-sparse [arm64] (noble-proposed) [0.6.18-2build1] [01:20] -queuebot:#ubuntu-release- New: accepted pytorch-sparse [amd64] (noble-proposed) [0.6.18-2build1] === chris14_ is now known as chris14 [07:38] -queuebot:#ubuntu-release- New: rejected optee-os-s32 [source] (noble-proposed) [3.18-bsp37.0-5] [07:39] -queuebot:#ubuntu-release- New: rejected ipp-crypto [source] (noble-proposed) [2021.9.0-0ubuntu1] [11:13] -queuebot:#ubuntu-release- New binary: python-term-image [amd64] (noble-proposed/universe) [0.7.1-2] (no packageset) [11:13] -queuebot:#ubuntu-release- New binary: slidge [amd64] (noble-proposed/none) [0.1.0~rc2+git20240217.72ce4cc0-1] (no packageset) [11:39] -queuebot:#ubuntu-release- Unapproved: flash-kernel (jammy-proposed/main) [3.104ubuntu18 => 3.104ubuntu19] (core) [11:50] can anyone please reject lcov from mantic-proposed.. [12:04] ubuntu-archive: hi #aa, I believe I took care of all gluster armhf reverse dependencies. gluster no longer builds on 32bits architectures. I think the only remaining step is for an AA to interviene? See https://ubuntu-archive-team.ubuntu.com/proposed-migration/update_excuses.html#glusterfs [12:05] and https://bugs.launchpad.net/ubuntu/+source/glusterfs/+bug/2052734 [12:05] -ubottu:#ubuntu-release- Launchpad bug 2052734 in glusterfs (Ubuntu) "Please remove glusterfs on armhf" [Undecided, New] [12:06] ahasenack, looking. [12:06] apw: thanks [12:17] -queuebot:#ubuntu-release- Unapproved: accepted flash-kernel [source] (jammy-proposed) [3.104ubuntu19] [12:23] sudip, are you about to upload over it? [12:24] apw: I dont have upload rights, but I will create another SRU debdiff and add ubuntu-sponsors and then wait :) [12:26] sudip, you don't need to wait for the previous to be rejected; you have to bump the version anyhow, and that will replace it. [12:27] ohh.. I thought if you reject then it will be possible to upload the same version.. thanks apw, I will continue then [12:28] sudip, no, once there are binaries associated they cannot be replaced, and a new source version is needed. [12:28] ok. I will move to 2.0-1ubuntu0.2 then. [16:08] tjaalton: Asking again now on Monday instead of Friday :) How would you like to handle https://bugs.launchpad.net/ubuntu/+source/samba/+bug/2046994 ? Shall we just push to Jammy since that's verified by the user or also push to Focal without it being verified due to HW constraints? [16:08] -ubottu:#ubuntu-release- Launchpad bug 2046994 in samba (Ubuntu Jammy) "Spotlight search function broken with macOS Ventura and later client" [High, Fix Committed] [16:08] -queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (jammy-proposed) [2.765.39] [16:12] sil2100: Just noticing a version of casper stuck in jammy-proposed for a great deal of time now, bug 1990621 there. No clue what was going on with that or if that needed to be released? [16:12] -ubottu:#ubuntu-release- Bug 1990621 in casper (Ubuntu Jammy) "[SRU] PXE Boot contains wrong suggested link to ISO for live file system" [Low, Fix Committed] https://launchpad.net/bugs/1990621 [16:12] Eickmeyer: hey! Let me check [16:14] Eickmeyer: hm, it seems Dominik (or anyone else) did not verify the SRU formally [16:14] Agreed, that's why I'm scratching my head. [16:15] Tough one to verify, tbh. [16:16] Let me reach out to Dominik, I think he'd be able to get this verified [16:16] Sounds good. Thought it should (finally) be included in one of these point releases. :) [16:18] It looks like it can be verified with a PXE booting stunt? [16:18] I've done PXE booting before (trying to circumvent the need for flashing ISOs all the time), it was a pain but I'm willing to tackle it if helpful :) [17:14] -queuebot:#ubuntu-release- New binary: python-term-image [amd64] (noble-proposed/universe) [0.7.1-3] (no packageset) [19:19] vorlon, mwhudson: Please see https://bugs.launchpad.net/ubuntu/+source/livecd-rootfs/+bug/2054341 - the tl;dr is that Ubuntu Cinnamon and Xubuntu have failing builds today, and I can't quite figure out what is causing the issue. All of my notes are there :) [19:19] -ubottu:#ubuntu-release- Launchpad bug 2054341 in livecd-rootfs (Ubuntu) "Ubuntu Cinnamon and Xubuntu FTBFS due to failure in diversion process" [Undecided, New] [19:19] (Sean reached out looking for assistance in the Ubuntu Flavors Matrix channel, the full rubberducking session is there.) [19:20] mm there were more failures yesterday than just the two, and I thought today's builds had succeeded [19:21] Ubuntu Cinnamon failed to build 5 hours ago. :) [19:21] mwhudson's suspicion was that it's an ordering failure, where plymouth calls update-initramfs if it's present and skips it if it's not, without a dependency; and that we manage to tickle things where initramfs-tools is not yet present but the post-diversion wrapper *is* [19:22] I concur. [19:22] we can fix the wrapper but it should also be fixable via seeds given mwhudson's analysis which I am trying to locate again [19:23] (because "fix" the wrapper really means make it a no-op if invoked before initramfs-tools is installed which could also be a bug on the part of a package) [19:25] tsimonq2: "ok initramfs-tools is not in xubuntu's desktop-minimal seed" [19:25] ohhhhhhhhhhhh [19:26] Yeah, that certainly follows. [19:26] brb burning breakfast [19:26] * Eickmeyer checks Ubuntu Cinnamon as well [19:27] Crispy breakfast sounds good, if you add a little spice. ;) [19:27] Same issue. [19:27] * Eickmeyer adds [19:28] Eickmeyer: What I'm now wondering is, can we confirm Ubuntu Studio, Edubuntu, and Ubuntu Budgie actually have that package in the right spot? :) [19:28] I would hate for that to be a red herring (not that I think it is, but confirming wouldn't hurt.) [19:29] tsimonq2: Standby... can check studio and edubuntu [19:30] initramfs-tools? not in our seeds. daily build has worked today [19:31] hmmmm [19:31] tsimonq2, vorlon: initramfs-tools isn't seeded in edubuntu's desktop-minimal or ubuntustudio's desktop seeds. [19:31] but it may be pulled in by something [19:31] https://ubuntu-archive-team.ubuntu.com/germinate-output/edubuntu.noble/ etc [19:32] wcat https://ubuntu-archive-team.ubuntu.com/germinate-output/edubuntu.noble/desktop-gnome-minimal | grep initramfs-tools tada [19:32] Right, I'm just saying it's not explicitly seeded. [19:32] we have zfs-initramfs in ship-live ... this would pull in initramfs-tools [19:35] Eickmeyer: If this works, maybe it should be. ;) [19:36] It does look as if both Ubuntu Cinnamon and Xubuntu are missing those packages from their minimal seed. [19:36] Honestly, I don't see the harm in seeding it. [19:36] Eickmeyer: Do you have access to spin a rebuild for Ubuntu Cinnamon? [19:36] tsimonq2: Yes, I do. [19:37] Actually, not to spin a rebuild. I misread. [19:37] Give me a minute, I'll look at all 10 flavors to see who *doesn't* have it. :) [19:44] Lubuntu (hah), Xubuntu, Ubuntu MATE, and Ubuntu Cinnamon all don't have this in their most-minimal desktop seed. [19:45] making sure initramfs-tools gets into the minimal seed is better in terms of layering anyway, since otherwise it's another package the installer has to unpack+install on the target system [19:47] Ok pushed to to Cinnamon and uploaded to meta. [19:48] there is a spec from me (probably Canonical internal at the moment) asking for the kernels to be installed in the innermost squashfs layer (mwhudson and dbungert will be familiar); not sure if that would also take care of this without explicit seeding. But having initramfs-tools in the lowermost squashfs is definitely the right outcome [19:51] so should ubuntu itself have initramfs-tools here in this seed? https://git.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/+git/platform/tree/minimal?h=noble .... or am i looking at the wrong git branch for ubuntu ? [19:51] vorlon: Wouldn't that be clear down in the minimal ... ^ What he said? [19:52] it may or may not be necessary to explicitly seed it depending on what else is present [20:08] mitchdz: jammy is actually frozen for the point-release [20:09] Ah yeah my bad [20:09] I'll revisit once freeze is over [20:09] Thanks [20:10] oh hi i replied in the bug before i saw this tsimonq [20:10] 2 [20:10] mwhudson: oh hi no worries :) [20:10] we should not put initramfs-tools in minimal, no [20:10] but um [20:11] > We could fix the replacement update-initramfs script to be a noop if it can't find the .REAL binary. Maybe that's a better idea. [20:11] Seems fairly reasonable to me. [20:11] tsimonq2: it's a better idea than removing the diversion, but probably fixing it via seeds is better [20:13] In my opinion at least, fixing the seeds is a good bandaid, I do wonder about a long term solution along the lines of what you said, though. :) [20:13] * mwhudson stares at the platform desktop-common seed [20:13] * xorg # this includes xserver-xorg->xserver-xorg-{input|video}-* (no need to add specific drivers manually) [20:13] * !linux-image-* # xorg transitively depends on this, but this would pull in grub-pc; we handle that separately [20:13] * mwhudson is extremely skeptical about every part of that second comment [20:14] * tsimonq2 dreams of the day we can finally remove xorg from the common seed, probably sometime in the 25.10 cycle ;P [20:14] mwhudson: "in minimal" sorry for the ambiguity, I'm not talking about putting it in ubuntu-minimal but making sure it's in xubuntu-desktop-minimal et al [20:15] vorlon: right but fossfreedom_ did [20:15] ah yes [20:16] maybe at the ubuntu summit we can spend some time drawing circles on a whiteboard and think about whether our seeds actually make any sense [20:16] vorlon: maybe it should be added to desktop common? [20:16] honestly I think gardening seeds is likely a bigger deal than their graph [20:17] mwhudson: [20:18] "gardening the seeds" well there's a great accidental metaphor [20:18] "thinning the rows" [20:19] spraying the glycophosphate [20:20] er glyphosate [20:21] haha [20:21] * vorlon works the words "roundup-ready" into a germinate MP [20:34] Keep Monsanto away from my seeds. 😂 [20:47] And thus Ubuntu Non-GMO was launched. [21:06] ahasenack: are you going to continue working on jupyter-client? Should I remove the new version from -proposed? [21:06] vorlon: I just found a patch for the utc deprecation dep8 failure, testing it [21:06] great [21:07] just let me know when I should throw the new package out of -proposed [21:07] ok [21:07] cc: dbungert who has a card for sorting jupyter for python3 [21:07] (but is national holiday here today so) [21:08] that package has been the gift that keeps giving. Was going to resume tomorrow or so [21:08] currently there is a grumpy websocket test, analyzing that is where I left off [21:09] yep [21:09] see my email to ubuntu-devel@, it's about that test [21:09] and upstream gave up on it, they pinned jupyter-client to an older verison (what we currently have in noble release) about a year ago [21:17] hm, there is more to it [21:18] it's src:python-dateutil that is using DeprecationWarning: datetime.datetime.utcfromtimestamp() [21:18] I used https://github.com/jupyter/jupyter_client/pull/972/files for jupyter-client [21:18] -ubottu:#ubuntu-release- Pull 972 in jupyter/jupyter_client "Do not use datetime.utcnow() that is deprecated in Python 3.12" [Merged] [21:18] vorlon: I don't have a fix yet for the dep8 issue on the noble-release jupyter-client, I'll have to continue tomorrow [21:19] can jupyter-client tests be fixed to not care about the deprecation warning [21:19] I suppose [21:19] and the fix itself still sounds simpler than the one in jupyter-notebook, which doesn't exist yet [21:20] well, isn't even understood [21:24] python-dateutil has fixes for python 3.12 upstream: https://github.com/beeware/briefcase/pull/1290 [21:24] -ubottu:#ubuntu-release- Pull 1290 in beeware/briefcase "Fix up support for Python 3.12" [Merged] [21:25] but an upload of python-dateutil might destabilize the whole mgiration at this point... I'll check beck on jupyter-client tomorrow === _doko is now known as doko [21:38] ahasenack: why destabilize? [21:41] is somebody looking at update-motd? [21:42] -queuebot:#ubuntu-release- New: accepted python-term-image [amd64] (noble-proposed) [0.7.1-2] [21:42] -queuebot:#ubuntu-release- New: accepted slidge [amd64] (noble-proposed) [0.1.0~rc2+git20240217.72ce4cc0-1] [21:42] -queuebot:#ubuntu-release- New: accepted python-term-image [amd64] (noble-proposed) [0.7.1-3] [21:50] libnvme times out on the buildds like in Debian, remove it from -proposed? [22:07] nux/armhf: [22:07] [----------] 1 test from TestLoggingWriter [22:07] [ RUN ] TestLoggingWriter.TestWriteMessage [22:07] gtest-nuxcore-logger.cpp:171: Failure [22:07] Value of: result [22:07] Expected: is equal to 0x5d40f0 pointing to "ERROR 2010-09-10 06:34:45 test.module testfile.cpp:1234 my message\n" [22:07] Actual: "ERROR 2010-09-10 07:34:45 test.module testfile.cpp:1234 my message\n" [22:08] [ FAILED ] TestLoggingWriter.TestWriteMessage (0 ms) [22:08] is that a problem with our buildd setup? 1h time difference looks suspicious [22:19] jbicha: https://launchpad.net/ubuntu/+source/console-setup/1.223ubuntu2 that didn't work [22:21] ahh, wait, didn't update [22:21] doko: it fixed the Depends: xkb-data . But there's a new console-setup to be merged if someone wants to do more [22:25] just new translations, afaics [22:48] doko: > why destabilize? [22:48] I wouldn't want to trigger a lot of python3 tests again, but I haven't checked [22:49] looks like debian autosyncs are enabled again, so you won't destabilize much ... [23:02] -queuebot:#ubuntu-release- New binary: ldc [amd64] (noble-proposed/universe) [1:1.36.0-1] (no packageset) [23:13] -queuebot:#ubuntu-release- New binary: asn [amd64] (noble-proposed/none) [0.75.3-1] (no packageset) [23:13] -queuebot:#ubuntu-release- New binary: wsdd [amd64] (noble-proposed/universe) [2:0.7.1-5] (no packageset) [23:14] ahasenack: now I don't understand that anymore: "python-dateutil has fixes for python 3.12 upstream: https://github.com/beeware/briefcase/pull/1290" this is the briefcase project, not python-dateutil [23:14] -ubottu:#ubuntu-release- Pull 1290 in beeware/briefcase "Fix up support for Python 3.12" [Merged] [23:14] doko: oh, I guess I really needed that break then [23:14] but there is something in python-dateutil [23:15] /usr/lib/python3/dist-packages/dateutil/tz/tz.py:37: in [23:15] EPOCH = datetime.datetime.utcfromtimestamp(0) [23:15] there are some pending patches in the debian bts too, but incomplete [23:15] debian vcs [23:16] that utcfromtimestamp() is in there, and triggers a deprecation warning in python 3.12 [23:17] whether that is actually what is failing the test, I'd like to check when I'm rested [23:17] but it's the only thing in the output [23:28] -queuebot:#ubuntu-release- New: accepted asn [amd64] (noble-proposed) [0.75.3-1] [23:28] -queuebot:#ubuntu-release- New: accepted wsdd [amd64] (noble-proposed) [2:0.7.1-5] [23:28] -queuebot:#ubuntu-release- New: accepted ldc [amd64] (noble-proposed) [1:1.36.0-1] [23:39] -queuebot:#ubuntu-release- New binary: ldc [arm64] (noble-proposed/universe) [1:1.36.0-1] (no packageset) === guiverc2 is now known as guiverc [23:51] -queuebot:#ubuntu-release- New: accepted ldc [arm64] (noble-proposed) [1:1.36.0-1]