[02:08] <kanashiro> doko: https://bugs.launchpad.net/ubuntu/+source/redmine/+bug/2054623
[02:08] -ubottu:#ubuntu-release- Launchpad bug 2054623 in redmine-plugin-redhopper (Ubuntu) "Removed from Debian testing" [Undecided, New]
[06:31] <sgmoore> bdmurray: Hi. Again, sorry for my newbness, but I read there our limit is 4.5, I downoaded our ISO to test and it is 4.2 so I am not sure how it is hitting the size limit, uness I am missing something. I sady didn't write down how much it was over ( saw the message to rikmills ) I am going to have to guess here and say 4.7 and in the future if you could ping me as well with anything in regards to Kubuntu :) Thank you!! And thanks for the
[06:31] <sgmoore> autopackage pings.
[12:27] <ahasenack> ubuntu-archive: hi, when someone as a moment, could you please complete the glusterfs demotion to universe? It's showing up in component mismatches already, as a "source and binary movements to universe"
[12:27] <ahasenack> ttps://bugs.launchpad.net/ubuntu/+source/glusterfs/+bug/2045063 is the demotion bug
[12:27] -ubottu:#ubuntu-release- Launchpad bug 2045063 in glusterfs (Ubuntu) "Demote glusterfs for noble" [High, In Progress]
[12:27] <ahasenack> it will also move bin:qemu-block-supplemental and bin:samba-vfs-modules-extra to universe, that's expected
[12:27] <ahasenack> they are also showing up in the report as binary-only moves to universe
[12:31] <apw> ahasenack, demoted.
[12:32] <ahasenack> apw: thanks!
[12:39] <LocutusOfBorg> ubuntu-archive: please kick searx out from noble (Debian bug: #1051510). This will make flask migrate, with Python3.12 compatibility code
[12:39] -ubottu:#ubuntu-release- Debian bug 1051510 in src:searx "searx: SearX upstream is no longer maintained" [Serious, Open] https://bugs.debian.org/1051510
[12:39] <LocutusOfBorg> also fava bug: #1031724
[12:39] <LocutusOfBorg> debian bug: #1031724
[12:39] -ubottu:#ubuntu-release- Debian bug 1031724 in src:fava "fava: frontend is not built from source; missing source" [Serious, Open] https://bugs.debian.org/1031724
[13:42] <LocutusOfBorg> please kick liquidsoap out, so ocaml can migrate
[13:43] <LocutusOfBorg> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1064128
[13:43] -ubottu:#ubuntu-release- Debian bug 1064128 in liquidsoap "liquidsoap: FTBFS: Error: Unbound module Pcre" [Serious, Open]
[14:10] <jbicha> should we temporarily revert ceph in noble-proposed to 18.2.0-0ubuntu6 since the riscv64 build may take all day? it's a blocker for python3-defaults
[14:16] <LocutusOfBorg> is it the last blocker? in 10h it will finish build anyway, right?
[14:17] <ginggs> ahasenack: i've just noticed
[14:17] <ginggs> Implicit dependency: python3-defaults samba (not considered)
[14:34] <sil2100> Preparing for release of .4!
[14:35] <bdrung> ahasenack, ping for tzdata. we even got an user request.
[14:35] <LocutusOfBorg> ginggs, apw samba-vfs-modules-extra should go in universe?
[14:36] <LocutusOfBorg> new package automagically accepted in main looks lilke
[14:36] <LocutusOfBorg> *like
[14:36] <LocutusOfBorg> this should make samba migratable
[14:36] <apw> LocutusOfBorg, if it was automatically put in main it must have existed before me thinks.
[14:37] <LocutusOfBorg> apw, its a binary provided by src:samba
[14:37] <LocutusOfBorg> not a standalone source
[14:37] <apw> LocutusOfBorg, oh then the default is to match the source disposition
[14:37] <LocutusOfBorg> so, new binaries in main are automatically accepted in the same pocket? :)
[14:37] <LocutusOfBorg> yes
[14:37] <LocutusOfBorg> that one!
[14:37] <LocutusOfBorg> this is why probably demoting that binary is ok
[14:38] <apw> component-missmatches will let us no.
[14:38] <apw> know
[14:38] <LocutusOfBorg> Binary only movements to universe (ubuntu-server)
[14:38] <LocutusOfBorg> qemu-block-supplemental	qemu
[14:38] <LocutusOfBorg> samba-vfs-modules-extra
[14:38] <LocutusOfBorg> yeah
[14:39] <apw> indeed.  there we go.
[14:40] <LocutusOfBorg> thanks!
[14:57] <blackboxsw> ahasenack: I think if there is SRU review time today cloud-init verification has been complete for a while on 23.4 and it's aging again but it doesn't seem represented on the SRU trello board
[14:57] <tsimonq2> Hi QA Tracker, did you fall asleep? :)
[15:14] <tsimonq2> "Hey, you, you're finally awake"
[15:22] <juliank> ubuntu-release can we force migrate glibc? The remaining tests don't look all that bad and then we can land the move to /usr today even
[15:23] <juliank> There's a weird regression with timezones in perl but it doesn't look like it should be a blocker
[15:23] <juliank> autopkgtest for liblocale-gettext-perl/1.07-6build1: amd64: Regression ♻ , arm64: Regression ♻ , armhf: Regression ♻ , ppc64el: Regression ♻ , s390x: Regression ♻
[15:23] <juliank> These are the only ones
[15:28]  * arraybolt3 stumbles into room
[15:28] <arraybolt3> ok how close are we to release?
[15:28] <arraybolt3> I have a release announcement to finish writing and need to know how much time I have.
[15:28] <arraybolt3> (Was up until like 2:30 AM my time getting Lubuntu's tests finished up.)
[15:39] <LocutusOfBorg> apw, what about kicking liquidsoap out to let ocaml migrate?
[15:40] <LocutusOfBorg> with it I can't see if anyhting is blocking still
[15:49] <ginggs> juliank: ack, hinting glibc
[15:51] <ginggs> may as well do python3-defaults too
[16:01] <ahasenack> blackboxsw: the board is only about unapproved packages. For packages already in proposed, the report is https://ubuntu-archive-team.ubuntu.com/pending-sru.html
[16:01] <ahasenack> blackboxsw: and today there is still an SRU freeze. It might be lifted today still
[16:08] <juliank> thanks ginggs
[16:55] <juliank> ginggs: how's your britney knowledge
[16:57] <ginggs> I know britney is a harsh mistress
[17:07] <juliank> ginggs: I'll upload base-files and glibc soon, and they need to migrate together. But they don't need to be upgraded together, and I don't want to complicate upgrades by mutual depends/breaks, so I'm thinking I'll just mark them block-proposed in a bug; or we set direct block in a hints file
[17:07] <juliank> Because arguably if they should migrate we probably want to use explicit unblock
[17:08] <juliank> If one migrates before the other because we missed something hidden somewhere debootstrap breaks
[17:10] <juliank> Well let me add the bug tag when I upload and it's going to be fine
[17:21] <juliank> skipped: glibc (95, 137, 3)
[17:21] <juliank>     got: 41+0: a-3:a-7:a-1:i-26:p-1:r-1:s-2
[17:21] <juliank>     * arm64: libdsocksd0, libnss-db, libsocksd0, libsocksd0-dev, unscd, zzuf
[17:21] <juliank> Ugh ginggs, it did not migrate
[17:22] <juliank> I can't read that
[17:23] <juliank> The others also should be ready to migrate
[17:27] <LocutusOfBorg> no ubuntu-archive around to help ocaml?
[17:30] <arraybolt3> juliank: https://wiki.ubuntu.com/ProposedMigration "The update_output.txt file is completely unreadable!" :P
[17:31] <arraybolt3> but... wow, a-3:a-7:a-1... we really need some way of identifying architectures other than by their first letter.
[17:34] <ginggs> juliank: I can have look at glibc again in a bit
[17:35] <juliank> ginggs: I'm running install in apt trying to figure out which dependency is failing :D
[17:37] <juliank> ginggs: but this is all awkward :(
[17:38] <juliank> ginggs: One thing to say is new glibc drops the libc6-prof binary and conflicts with the old version
[17:41] <juliank> maybe it really is that and it complains about libc6-prof becoming uninstallable or something, idk
[17:50] <ahasenack> bdrung: hi, about tzdata (my first time reviewing this package)
[17:50] <ahasenack> bdrung: the sru docs have a whole section on it: https://wiki.ubuntu.com/StableReleaseUpdates#tzdata
[17:51] <ahasenack> they talk about zdump and other checks
[17:51] <ahasenack> is that part of the autopkgtests, or is it expected to be done manually, per sru?
[18:42] <athos> Hi ubuntu-archive. Could you please remove phpdox from noble (LP: #2054727)?
[18:42] -ubottu:#ubuntu-release- Launchpad bug 2054727 in phpdox (Ubuntu) "Please remove phpdox from noble" [Undecided, New] https://launchpad.net/bugs/2054727
[18:44] <ahasenack> ricotz: I think you have some copy&paste typo from previous libreoffice srus:
[18:44] <ahasenack> " * Version 7.6.2 is currently released in mantic. For a list of fixed bugs compared to 7.6.4 see the list of bugs fixed in the release candidates of 7.6.5 (that's a total of 94 bugs):"
[18:44] <ahasenack> mantic has 7.6.4
[18:47] <ricotz> ahasenack, sorry, I hope this was the only issue
[18:47] <ahasenack> still looking
[18:48] <ahasenack> diffing libreoffice is not for low-end machines :)
[18:48] <ahasenack> even LP didn't produce a diff
[18:48] <ahasenack>  /dev/mapper/vg0-root  336G  294G   25G  93% /
[18:48] <ahasenack> uhoh
[18:49] <ricotz> ahasenack, yeah :\, the LP diff would not be worth anything against 7.6.2 anyway :(
[18:49] <ricotz> ahasenack, I am using a tmpfs for this beast
[18:50] <ahasenack> down to 21G now
[18:50] <ahasenack> I might do this elsewhere
[18:52] <ricotz> ahasenack, I might be able to provide you a diff
[18:52] <ahasenack> I think it will work
[18:52] <ahasenack> what I'm doing
[18:52] <ahasenack> still 20Gb free :)
[18:52] <ahasenack> my nvme might be losing a few years of life, but heh
[18:53] <ahasenack> :)
[18:55] <ricotz> I am like hammering the RAM instead :)
[19:04] <ahasenack> ricotz: you have fix-riscv64-bridge.diff and fix-riscv64-bridges.diff, that could have been avoided :)
[19:07] <ricotz> ahasenack, I am aware :\, fixing the naming would create conflicts with debian
[19:07] <ahasenack> aha
[19:07] <ahasenack> yeah, not worth a delta for sure
[19:07] <ahasenack> hopefully these can be dropped next time
[19:07] <ahasenack> (if merged upstream)
[19:08] <ahasenack> ricotz: have you used debian/watch recently? It doesn't seem to be finding the upstream releases
[19:09] <ricotz> ahasenack, these patches are part of 24.2, but I guess they will need to be kept around in 7.6
[19:09] <ahasenack> maybe because they removed 7.6.5 from https://dev-builds.libreoffice.org/pre-releases/src/ apparently?
[19:09] <ahasenack> I see 7.6.5.1
[19:09] <ahasenack> hm, pre-release?
[19:09] <ahasenack> also 7.6.5.2
[19:09] <ricotz> ahasenack, correct the tarball got repacked
[19:10] <ricotz> https://download.documentfoundation.org/libreoffice/src/7.6.5/
[19:10] <ahasenack> yeah, that has .2
[19:10] <ricotz> tracking the pre-release is preferred
[19:11] <ahasenack> do they just drop the older ones? Where is 7.6.5?
[19:11] <ricotz> yes, there were two different 7.6.5.2 tarballs
[19:11] <ahasenack> I'm talking about 7.6.5
[19:12] <ricotz> the RC revision stays part of the tarball name
[19:12] <ricotz> https://dev-builds.libreoffice.org/pre-releases/src/libreoffice-7.6.5.2.tar.xz
[19:13] <ahasenack> you linked 7.6.5.2 again
[19:13] <ahasenack> are you saying 7.6.5.2 is the official 7.6.5, and that the .2 just shows that it was 7.6.5RC2 before?
[19:14] <ricotz> yes
[19:14] <ahasenack> why not call the version in d/changelog 7.6.5.2 then? I'm confused
[19:14] <ahasenack> I'm trying to match what is in unapproved with what upstream published
[19:14] <ahasenack> since I can't really go over the huge diff
[19:15] <ricotz> because this is not how upstream is labeling it officially
[19:15] <ahasenack> so in unapproved I see a 7.6.5 orig tarball
[19:15] <ahasenack> I was expecting to find a 7.6.5 tarball upstream
[19:15] <ricotz> because it is the final release, and this is how it works for years
[19:16] <ricotz> this release was a bit special while there were two 7.6.5.2 tarballs
[19:16] <ricotz> due to a hotfix change
[19:16] <ahasenack> so if I download 7.6.5.2 from upstream, it should match the 7.6.5 orig tarball in unapproved, is that it?
[19:16] <ricotz> https://cgit.freedesktop.org/libreoffice/core/tag/?h=libreoffice-7.6.5.2-hotfix1
[19:17] <ricotz> yes, this one https://download.documentfoundation.org/libreoffice/src/7.6.5/
[19:17] <ricotz> the one from pre-release is different
[19:18] <ricotz> ahasenack, the tarballs are signed and can be checked with the provided *.asc
[19:19] <ricotz> the main tarballs at least, -help, -translations, -tarballs are generated by me
[19:28] <ricotz> ahasenack, https://people.ubuntu.com/~ricotz/libreoffice-7.6.5.2.diff
[19:29] <ricotz> ahasenack, https://git.launchpad.net/~libreoffice/ubuntu/+source/libreoffice/log/?h=wip/mantic-7.6
[19:36] <bdrung> ahasenack, i (hopefully) answered your questions in https://bugs.launchpad.net/ubuntu/+source/tzdata/+bug/2052739/comments/9
[19:36] -ubottu:#ubuntu-release- Launchpad bug 2052739 in tzdata (Ubuntu Mantic) "tzdata 2024a release" [Undecided, Confirmed]
[19:42] <ahasenack> ricotz: accepted, unsure why the bot didn't say something
[19:42] <ahasenack> bdrung: I'll get back to it later today
[19:43] <ricotz> ahasenack, thank you very much
[19:47] <bdrung> ahasenack, thanks
[19:59] <bdmurray> sgmoore: It looks like Kubuntu shrank with in the limits again as I'm no longer getting emails about it being oversized.
[20:01] <sgmoore> bdmurray: great :)
[20:14] <ahasenack> do riscv64 builds block migration?
[20:15] <ahasenack> https://launchpad.net/ubuntu/+source/ceph/18.2.0-0ubuntu7 is still building for riscv64, and it's on the list of things blocking python3-defaults
[20:19] <bdmurray> ahasenack: yes
[20:19] <ahasenack> "Started 20 hours ago
[20:19] <ahasenack> "
[20:20] <ahasenack> let's see how long the previous one took
[20:20] <ahasenack> Finished on 2024-02-07 (took 1 day, 4 hours, 15 minutes, 1.0 seconds)
[20:20] <bdmurray> "Issues preventing migration:\n "missing build"
[20:20] <ahasenack> so 28h and change
[20:20] <ahasenack> 8h more
[20:20] <bdmurray> almost there!
[20:20] <ahasenack> glass half-full
[20:46] <ahasenack> bdrung: one last question, if you are still around. How is debian/icu/* populated?
[20:46] <ahasenack> or rather, updated?
[21:08] <bdmurray> ahasenack: see update-icu in debian/rules
[21:09] <bdmurray> ahasenack: basically its from here IIRC https://github.com/unicode-org/icu-data/tree/main/tzdata/icunew
[21:45] <doko> bdmurray, ginggs: please can we stop autosyncs until python3-defaults migrated? looks like we get some unwanted syncs delaying the migration. and I saw that glibc just migrated
[21:45] <ahasenack> we are so close
[21:46] <ahasenack> last I checked we were just waiting on a riscv64 build
[21:46] <bdmurray> doko: I can turn off autosyncs but for how long should I do that? I'll be around for 3 hours or so and could come back later to reenable it.
[21:47] <doko> bdmurray: well, for the perl migration, they were turned off for a few days. maybe watch until python3-defaults migrated?
[21:48] <doko> it shouldn't be longer than the weekend
[21:48] <bdmurray> vorlon, sil2100: FYI ^^
[21:48] <ahasenack> hm, this is in the way of python3-defaults too I think: https://ubuntu-archive-team.ubuntu.com/proposed-migration/update_excuses.html#ucx
[21:48] <ahasenack> missing build on ppc64el
[21:49] <ahasenack> bistro/bistro.c:83:5: error: nested extern declaration of ‘ucm_bistro_patch_lock’ [-Werror=nested-externs]
[21:49] <ahasenack> cc1: all warnings being treated as errors
[21:49] <bdmurray> Is there anything dependent on that though?
[21:49] <ahasenack> I can look at that tomorrow...
[21:49] <ahasenack> I arrived there via "adios2"
[21:49] <ahasenack> Implicit dependency: python3-defaults adios2 (not considered)
[21:50] <ahasenack> I think it's just that and ceph now
[21:50] <ahasenack> and ceph is the riscv64 build that takes 28h
[21:50] <ahasenack> I see no reds under python3-defaults in the current excuses page
[21:51] <ahasenack> it also failed in debian
[21:51] <ahasenack> (ppc64el build of ucx)
[21:51] <doko> yes, looking at removing that, and restoring the previous adios2 build
[21:52] <doko> we have to wait for the ceph build
[21:52] <ahasenack> adios, adios2
[21:56] <ginggs> :)
[21:56] <ahasenack> ah, someone got it
[21:57] <doko> https://launchpad.net/ubuntu/+source/adios2/+publishinghistory
[21:58] <doko> https://launchpad.net/ubuntu/+source/ucx/+publishinghistory
[21:58] <ahasenack> ah, the power
[21:59] <ahasenack> 7h for the riscv64 build to finish
[22:00] <bdmurray> Is it worth waiting for that build?
[22:00] <doko> what else do you suggest?
[22:02] <bdmurray> Oh, I guess we can't hint builds.
[22:02] <doko> I could remove it. ok let's do it. sorry pushkar
[22:03] <bdmurray> Yeah, let it build again over the weekend.
[22:04] <doko> I'll be afk most of the weekend, but will read backlog in the evenings
[22:09] <doko> so adios2 -10 failed to build on s390x. removing adios2 instead, and demoting paraview. that can be undone by restoring the ucx and adios2 builds later
[22:12] <doko> done
[22:12] <doko> lets wait ...
[23:20] <jbicha> ceph's noble riscv64 failed with no log so I suggest a temporary revert since a build takes a full day
[23:21] <jbicha> oh never mind, ceph was already reverted
[23:21] <bdmurray> I thought doko said he did that
[23:21] <bdmurray> ;-)