[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]
[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] <sudip> can anyone please reject lcov from mantic-proposed..
[12:04] <ahasenack> 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] <ahasenack> 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] <apw> ahasenack, looking.
[12:06] <ahasenack> apw: thanks
[12:17] -queuebot:#ubuntu-release- Unapproved: accepted flash-kernel [source] (jammy-proposed) [3.104ubuntu19]
[12:23] <apw> sudip, are you about to upload over it?
[12:24] <sudip> apw: I dont have upload rights, but I will create another SRU debdiff and add ubuntu-sponsors and then wait :)
[12:26] <apw> 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] <sudip> ohh.. I thought if you reject then it will be possible to upload the same version.. thanks apw, I will continue then
[12:28] <apw> sudip, no, once there are binaries associated they cannot be replaced, and a new source version is needed.
[12:28] <sudip> ok. I will move to 2.0-1ubuntu0.2 then.
[16:08] <mitchdz> 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] <Eickmeyer> 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] <sil2100> Eickmeyer: hey! Let me check
[16:14] <sil2100> Eickmeyer: hm, it seems Dominik (or anyone else) did not verify the SRU formally
[16:14] <Eickmeyer> Agreed, that's why I'm scratching my head.
[16:15] <Eickmeyer> Tough one to verify, tbh.
[16:16] <sil2100> Let me reach out to Dominik, I think he'd be able to get this verified
[16:16] <Eickmeyer> Sounds good. Thought it should (finally) be included in one of these point releases. :)
[16:18] <arraybolt3> It looks like it can be verified with a PXE booting stunt?
[16:18] <arraybolt3> 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] <tsimonq2> 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] <tsimonq2> (Sean reached out looking for assistance in the Ubuntu Flavors Matrix channel, the full rubberducking session is there.)
[19:20] <vorlon> mm there were more failures yesterday than just the two, and I thought today's builds had succeeded
[19:21] <tsimonq2> Ubuntu Cinnamon failed to build 5 hours ago. :)
[19:21] <vorlon> 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] <tsimonq2> I concur.
[19:22] <vorlon> 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] <vorlon> (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] <vorlon> tsimonq2: "ok initramfs-tools is not in xubuntu's desktop-minimal seed"
[19:25] <tsimonq2> ohhhhhhhhhhhh
[19:26] <tsimonq2> Yeah, that certainly follows.
[19:26] <vorlon> brb burning breakfast
[19:26]  * Eickmeyer checks Ubuntu Cinnamon as well
[19:27] <tsimonq2> Crispy breakfast sounds good, if you add a little spice. ;)
[19:27] <Eickmeyer> Same issue.
[19:27]  * Eickmeyer adds
[19:28] <tsimonq2> 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] <tsimonq2> I would hate for that to be a red herring (not that I think it is, but confirming wouldn't hurt.)
[19:29] <Eickmeyer> tsimonq2: Standby... can check studio and edubuntu
[19:30] <fossfreedom_> initramfs-tools?  not in our seeds.  daily build has worked today
[19:31] <tsimonq2> hmmmm
[19:31] <Eickmeyer> tsimonq2, vorlon: initramfs-tools isn't seeded in edubuntu's desktop-minimal or ubuntustudio's desktop seeds.
[19:31] <vorlon> but it may be pulled in by something
[19:31] <vorlon> https://ubuntu-archive-team.ubuntu.com/germinate-output/edubuntu.noble/ etc
[19:32] <vorlon> wcat https://ubuntu-archive-team.ubuntu.com/germinate-output/edubuntu.noble/desktop-gnome-minimal  | grep initramfs-tools tada
[19:32] <Eickmeyer> Right, I'm just saying it's not explicitly seeded.
[19:32] <fossfreedom_> we have zfs-initramfs in ship-live ... this would pull in initramfs-tools
[19:35] <tsimonq2> Eickmeyer: If this works, maybe it should be. ;)
[19:36] <tsimonq2> It does look as if both Ubuntu Cinnamon and Xubuntu are missing those packages from their minimal seed.
[19:36] <Eickmeyer> Honestly, I don't see the harm in seeding it.
[19:36] <tsimonq2> Eickmeyer: Do you have access to spin a rebuild for Ubuntu Cinnamon?
[19:36] <Eickmeyer> tsimonq2: Yes, I do.
[19:37] <Eickmeyer> Actually, not to spin a rebuild. I misread.
[19:37] <tsimonq2> Give me a minute, I'll look at all 10 flavors to see who *doesn't* have it. :)
[19:44] <tsimonq2> Lubuntu (hah), Xubuntu, Ubuntu MATE, and Ubuntu Cinnamon all don't have this in their most-minimal desktop seed.
[19:45] <vorlon> 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] <Eickmeyer> Ok pushed to to Cinnamon and uploaded to meta.
[19:48] <vorlon> 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] <fossfreedom_> 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] <Eickmeyer> vorlon: Wouldn't that be clear down in the minimal ... ^ What he said?
[19:52] <vorlon> it may or may not be necessary to explicitly seed it depending on what else is present
[20:08] <tjaalton> mitchdz: jammy is actually frozen for the point-release
[20:09] <mitchdz> Ah yeah my bad
[20:09] <mitchdz> I'll revisit once freeze is over
[20:09] <mitchdz> Thanks
[20:10] <mwhudson> oh hi i replied in the bug before i saw this tsimonq
[20:10] <mwhudson> 2
[20:10] <tsimonq2> mwhudson: oh hi no worries :)
[20:10] <mwhudson> we should not put initramfs-tools in minimal, no
[20:10] <mwhudson> but um
[20:11] <tsimonq2> > 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] <tsimonq2> Seems fairly reasonable to me.
[20:11] <mwhudson> tsimonq2: it's a better idea than removing the diversion, but probably fixing it via seeds is better
[20:13] <tsimonq2> 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] <mwhudson>  * xorg                          # this includes xserver-xorg->xserver-xorg-{input|video}-* (no need to add specific drivers manually)
[20:13] <mwhudson>  * !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] <vorlon> 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] <mwhudson> vorlon: right but fossfreedom_ did
[20:15] <vorlon> ah yes
[20:16] <mwhudson> 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] <mwhudson> vorlon: maybe it should be added to desktop common?
[20:16] <vorlon> honestly I think gardening seeds is likely a bigger deal than their graph
[20:17] <vorlon> mwhudson: <handwave>
[20:18] <vorlon> "gardening the seeds" well there's a great accidental metaphor
[20:18] <vorlon> "thinning the rows"
[20:19] <mwhudson> spraying the glycophosphate
[20:20] <mwhudson> er glyphosate
[20:21] <vorlon> haha
[20:21]  * vorlon works the words "roundup-ready" into a germinate MP
[20:34] <Eickmeyer> Keep Monsanto away from my seeds. 😂
[20:47] <arraybolt3> And thus Ubuntu Non-GMO was launched.
[21:06] <vorlon> ahasenack: are you going to continue working on jupyter-client?  Should I remove the new version from -proposed?
[21:06] <ahasenack> vorlon: I just found a patch for the utc deprecation dep8 failure, testing it
[21:06] <vorlon> great
[21:07] <vorlon> just let me know when I should throw the new package out of -proposed
[21:07] <ahasenack> ok
[21:07] <vorlon> cc: dbungert who has a card for sorting jupyter for python3
[21:07] <vorlon> (but is national holiday here today so)
[21:08] <dbungert> that package has been the gift that keeps giving.  Was going to resume tomorrow or so
[21:08] <dbungert> currently there is a grumpy websocket test, analyzing that is where I left off
[21:09] <ahasenack> yep
[21:09] <ahasenack> see my email to ubuntu-devel@, it's about that test
[21:09] <ahasenack> 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] <ahasenack> hm, there is more to it
[21:18] <ahasenack> it's src:python-dateutil that is using DeprecationWarning: datetime.datetime.utcfromtimestamp()
[21:18] <ahasenack> 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] <ahasenack> 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] <vorlon> can jupyter-client tests be fixed to not care about the deprecation warning
[21:19] <ahasenack> I suppose
[21:19] <ahasenack> and the fix itself still sounds simpler than the one in jupyter-notebook, which doesn't exist yet
[21:20] <ahasenack> well, isn't even understood
[21:24] <ahasenack> 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] <ahasenack> but an upload of python-dateutil might destabilize the whole mgiration at this point... I'll check beck on jupyter-client tomorrow
[21:38] <doko> ahasenack: why destabilize?
[21:41] <doko> 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] <doko> libnvme times out on the buildds like in Debian, remove it from -proposed?
[22:07] <doko> nux/armhf:
[22:07] <doko> [----------] 1 test from TestLoggingWriter
[22:07] <doko> [ RUN      ] TestLoggingWriter.TestWriteMessage
[22:07] <doko> gtest-nuxcore-logger.cpp:171: Failure
[22:07] <doko> Value of: result
[22:07] <doko> Expected: is equal to 0x5d40f0 pointing to "ERROR 2010-09-10 06:34:45 test.module testfile.cpp:1234 my message\n"
[22:07] <doko>   Actual: "ERROR 2010-09-10 07:34:45 test.module testfile.cpp:1234 my message\n"
[22:08] <doko> [  FAILED  ] TestLoggingWriter.TestWriteMessage (0 ms)
[22:08] <doko> is that a problem with our buildd setup? 1h time difference looks suspicious
[22:19] <doko> jbicha: https://launchpad.net/ubuntu/+source/console-setup/1.223ubuntu2  that didn't work
[22:21] <doko> ahh, wait, didn't update
[22:21] <jbicha> 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] <doko> just new translations, afaics
[22:48] <ahasenack> doko: > why destabilize?
[22:48] <ahasenack> I wouldn't want to trigger a lot of python3 tests again, but I haven't checked
[22:49] <doko> 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] <doko> 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] <ahasenack> doko: oh, I guess I really needed that break then
[23:14] <ahasenack> but there is something in python-dateutil
[23:15] <ahasenack>  /usr/lib/python3/dist-packages/dateutil/tz/tz.py:37: in <module>
[23:15] <ahasenack>     EPOCH = datetime.datetime.utcfromtimestamp(0)
[23:15] <doko> there are some pending patches in the debian bts too, but incomplete
[23:15] <doko> debian vcs
[23:16] <ahasenack> that utcfromtimestamp() is in there, and triggers a deprecation warning in python 3.12
[23:17] <ahasenack> whether that is actually what is failing the test, I'd like to check when I'm rested
[23:17] <ahasenack> 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)
[23:51] -queuebot:#ubuntu-release- New: accepted ldc [arm64] (noble-proposed) [1:1.36.0-1]