[00:36] <vpa1977> it looks like doxygen needs another no-change rebuild against llvm-18: https://launchpadlibrarian.net/722579659/buildlog_ubuntu-noble-amd64.linbox_1.7.0-4ubuntu1~ppa1_BUILDING.txt.gz. Would it be ok for me to upload it now?
[00:41] <vpa1977> (validated in ppa, the issue is fixed with rebuild)
[00:50] <bdmurray> vpa1977: yes
[01:29] <vorlon> dbungert: sure did, thank youuuu
[01:30] <vorlon> vpa1977: any idea how we ended up with a misbuilt doxygen?
[01:31] <dbungert> vorlon: I suggest we also include https://code.launchpad.net/~dbungert/livecd-rootfs/+git/livecd-rootfs/+merge/463379
[01:32] <vorlon> dbungert: yep, just hadn't had a chance to ack it yet, done now
[01:32] <dbungert> thanks, will merge and upload shortly
[01:36] <vpa1977> vorlon: the misbuild one pulled llvm-toolchain out of -updates: https://launchpadlibrarian.net/722421221/buildlog_ubuntu-noble-amd64.doxygen_1.9.8+ds-2build4_BUILDING.txt.gz
[01:36] <vpa1977> *misbuilt
[01:36] <vpa1977> Get:60 http://ftpmaster.internal/ubuntu noble-updates/main amd64 libllvm18 amd64 1:18.1.0~rc2-4 [27.5 MB]
[01:36] <vorlon> so this was something that had been silently fixed in a later version of llvm-toolchain-18 and so never affected doxygen, ok
[05:50] <pushkarnk> Are things in a flux on armhf? I am unable to build openjdk in a chroot in spite of an apt update
[10:57] <slyon> @pilot in
[11:09]  * sudip wonders if we are in Beta Freeze now
[12:16] <slyon> sudip: things are still in flux, due to https://ubuntu.com/security/CVE-2024-3094 and a mass rebuild happening for noble-proposed
[12:16] -ubottu:#ubuntu-devel- Malicious code was discovered in the upstream tarballs of xz, starting with version 5.6.0. Through a series of complex obfuscations, the liblzma build process extracts a prebuilt object file from a disguised test file existing in the source code, which is then used to modify specific functions in the liblzma code. This results in a modified liblzma library that can be ... <https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-3094>
[12:17] <slyon> please coordinate with #ubuntu-release if you need to upload new stuff
[12:20] <sudip> slyon: I dont have upload rights, but can you guide me on what do I need to do for LP: #2059906. as usual I have added the debdiff and added sponsors, but since this is my first freeze I am not sure if anything else is needed at this time
[12:20] -ubottu:#ubuntu-devel- Launchpad bug 2059906 in fwbuilder (Ubuntu) "fwbuilder fails to install in Noble" [Undecided, Confirmed] https://launchpad.net/bugs/2059906
[12:20]  * sudip wont ask these silly questions on next freeze
[12:22] <RikMills> sudip: that bug looks to be a consequence of the deleted and rebuiling of affected binaries
[12:23] <RikMills> it should sort itslef out in time
[12:23] <RikMills> in theory
[12:23] <slyon> sudip: this is a simple fix for an unseeded package. So we should still be upload it up until https://wiki.ubuntu.com/FinalFreeze
[12:23] <slyon> Bugfixes are still allowed during FeatureFreeze
[12:24] <RikMills> when this migrates: https://launchpad.net/ubuntu/+source/fwbuilder/5.3.7-5build2
[12:24] <sudip> RikMills: I dont think so, but I might be wrong. the dependency was on source:version, which will not change with rebuilds. but the binary:version will change and that was the problem here
[12:24] <slyon> so attaching the debdiff and subscribing ~ubuntu-sponsors was the correct thing to do. You can always try to find sponsors on IRC to speed things up, or else somebody will pick it up from the sponsoring queue eventually. But people are busy with fixing the archive and t64 transition, so it might take longer that usual
[12:24] <RikMills> the issue should fix itself
[12:25] <RikMills> sudip: the reason is that amd64 binaries in the release pocket were deleted, but arch:all were not
[12:25] <RikMills> which will fix when the rebuild migrates
[12:26] <RikMills> https://discourse.ubuntu.com/t/whats-happening-in-noble-repositories/43729/19
[12:27] <RikMills> uploading new revisions now will delay a fix
[12:28] <sudip> ack, from the build log it seems it has the correct dependencies, I will remove sponsors from that bug for now
[12:29] <sudip> removed
[12:30] <sudip> thanks RikMills slyon
[14:33] <slyon> @pilot out
[15:00] <lvoytek> @pilot in
[17:53] <helmut> Hi. I have now received the 10th [proposed-migration] email for a package I maintain in Debian and can do nothing about in Ubuntu by virtue of having a launchpad account with the same email address. As the underlying problem (sending of those emails without any opt-out) does not seem solvable in the short term, is there any way to unstuck migration of debvm such that I don't have to redirect mails
[17:53] <helmut> from launchpad to /dev/null?
[19:01] <lvoytek> @pilot out
[19:16] <jbicha> helmut: it's approximately the same as Debian testing migration. https://ubuntu-archive-team.ubuntu.com/proposed-migration/update_excuses.html#debvm says that the autopkgtest fails on ppc64el
[20:38] <helmut> jbicha: it's an infra bug on canonical side
[20:39] <helmut> jbicha: it's a chain of failure. if canonical's ppc64el infra weren't broken, it wouldn't fail. if ubuntu were updating from debian, it wouldn't fail. if launchpad were providing an opt-out it wouldn't spam me. any of these fixes the issue at hand
[20:39] <jbicha> helmut: ok, we have a hints file like Debian https://wiki.ubuntu.com/ProposedMigration#Are_there_any_exceptions.3F__I.27m_sure_acmefoo_has_just_made_it_into_the_release_pocket_despite_not_satisfying_all_of_the_requirements.
[20:43] <helmut> If all else fails, I can blackhole noreply+proposed-migration@ubuntu.com
[21:14] <cjwatson> helmut: not that this is my job any more, but FWIW, Launchpad can't really provide an opt-out here because Launchpad isn't the thing sending the emails
[21:48] <rbasak> bdmurray: ^ any chance we can limit these emails to only those who specifically uploaded to Ubuntu, rather than via Debian?