[03:20] <vpa1977> bryceh: Oh thank you for the presentation --CL-- =)
[03:25] <cgmb> The ROCm stack has been FTBFS on arm64 since the update to glibc 2.38 last year. I'd like to ask for the arm64 binaries to be removed from the archive so that the fixes for amd64 and ppc64el can migrate from noble-proposed to noble-release. What process should I be following?
[03:31] <arraybolt3> cgmb: ask in #ubuntu-release, that's probably the fastest way.
[03:31] <vpa1977> cgmb: I believe it is described here https://wiki.ubuntu.com/UbuntuDevelopment/PackageArchive#Removing_Packages
[03:32] <bdmurray> and that wiki page mentions opening a bug report
[03:35] <cgmb> Thanks! I've filed a merge request with a fix for glibc, so hopefully we'll get arm64 in the release anyway. I just don't want to have everything else depend on that.
[04:31] <mwhudson> cgmb: it's a bit late to be getting changes to glibc into 24.04 i'd say
[09:08] <rbasak> bryceh: ah so we have git ubuntu merge finish which does one thing and git-ubuntu.reconstruct-changelog which does another :-/
[09:08] <rbasak> I didn't realise the former wasn't just calling the latter
[09:09] <rbasak> (well, I probably once did know, but that code dates from 2017!)
[14:41] <adrien> cpaelzer, sil2100 : I got the tests running for the libtracefs MIR but that also means I started getting results on non-amd64... s390x segfaults (maintainer has no BE machine anymore), ppc64el has 3, 4 or 5 test failures (it varies), and I'm waiting for arm64 results (amd64 last run failed but it seems to be testbed failure somehow)
[14:42] <adrien> cpaelzer, sil2100 : my question is whether we want to support all arches for such a package; it's clear I won't be able to fix that many issues on non-amd64 platforms in less than several full days (and that's being optimistic)
[14:45] <cpaelzer> sadly adrien, yes it is meant to work everywhere
[14:45] <cpaelzer> if you can isolate s390x and ppc issues fheimes might be able to get you IBM developers to assist
[14:46] <cpaelzer> they are also the ones to tell you "ok, do not build it on these platforms for now"
[14:46] <cpaelzer> adrien: there are a few s390x boxes in your team which you should be able to get access, ppc64 via MAAS
[14:48] <adrien> cpaelzer: thanks; tbh I'm thinking it won't be possible for noble
[14:49] <cpaelzer> I pinged fheimes in your channel, he is the one you want to get an ok for "be x86+arm only for now" which he wants to talk to IBM to not be surprised
[14:49] <cpaelzer> adrien: you can then adapt the build to not build on broken platforms
[14:50] <cpaelzer> adrien: if there are fixes later than noble these arches might then be re-enabled with fixes in place
[14:50] <adrien> sounds good, thanks
[14:51] <adrien> I guess IBM might also prefer that we skip these arches for now if it means getting better support afterwards
[14:51] <cpaelzer> exactly
[14:52] <cpaelzer> but while that sounds nice (unblocking now, having it later) it needs coordination
[14:52] <cpaelzer> hence I'm trying to link you and fheimes
[14:53] <adrien> yep, we'll see how it goes :)
[15:04] <enr0n> adrien: there were also big endian issues for libtraceevent (I think written by the same author), and there is a patch for that in Ubuntu now. Maybe that would shed some light?
[15:08] <adrien> enr0n: I was aware of it but I assumed it was in the library while it's actually changing the tests and I can actually spot a similar structure so it's probably worth a try!
[15:09] <adrien> (no idea what a tep_file is though :P )
[15:15] <sudip> adrien: tep is "trace event parser"
[15:17] <adrien> sudip: ah, makes sense, thanks
[15:24] <adrien> I see "DEB_BUILD_OPTIONS=noautodbgsym parallel=4" in the logs of libtracefs and I haven't yet found where this could come from; there are very few references to "noautodbgsym" and I don't know where this would come (I know: probably debhelper but it doesn't mean I understand where it comes from!)
[15:25] <cjwatson> adrien: https://git.launchpad.net/launchpad-buildd/tree/lpbuildd/binarypackage.py#n191
[15:26] <cjwatson> adrien: https://bugs.launchpad.net/launchpad-buildd/+bug/1623256
[15:26] -ubottu:#ubuntu-devel- Launchpad bug 1623256 in launchpad-buildd "RM pkg-create-dbgsym -> adjust the way to create dbgsym packages like Debian does" [High, Fix Released]
[15:31] <adrien> cjwatson: thanks! it's pretty clear, I'll go edit the package
[15:58] <sergiodj> @pilot in
[17:17] <adrien> mateus-morais pointed out that it was maybe due to a PPA setting and indeed, I didn't have the generation of dbgsyms enabled in the config; I'm using ppa-dev-tools to create specific-purpose PPAs and never had to pay attention to that
[17:18] <adrien> I'll look at the LP API to see if it can be enabled that way (I don't remember what other thing was not available through the API (well, I think it was related to -proposed) but I have IRC logs for that)
[18:01] <sergiodj> @pilot out
[18:26] <cjwatson> adrien: pretty sure you can set build_debug_symbols or whatever on the archive
[18:51] <mwhudson> adrien: you can enable proposed through the api but it's a bit fiddly
[18:51] <mwhudson> (well works in a different way to the ui might suggest it works)
[18:56] <adrien> mwhudson: oh, do you have code for that?
[18:56] <adrien> I couldn't find anything in the API but maybe I'm not used to the API enough
[18:57] <adrien> that's the kind of thing I'd like to have in ppa-dev-tools so it only has to be done once
[18:57] <mwhudson> adrien: https://github.com/mwhudson/rebuild-archive-scripts/blob/main/create-rebuild-ppas
[18:57] <mwhudson> well that limits the dependency to the release pocket but well
[19:03] <adrien> thanks, another goal is to set the dependency to proposed :P
[19:31] <juliank> packages with removed amd64 binaries that need resolving: https://pad.riseup.net/p/migrate-list-amd64
[19:31] <juliank> ^ needs to be added to topic, I only have permission in #ubuntu-release
[19:33] <juliank> ta
[19:34] <adrien> btw, there is a specific flag to manipulate topic through chanserv I think
[19:34] <juliank> possibly
[19:35] <juliank> Well yes I use /msg Chanserv topic
[19:35] <juliank> But arguably it's sneaky
[19:35] <juliank> Because it just does /topic for you and hides who did it
[19:35] <vorlon> yeah
[19:36] <adrien> yes but it's also possible to grant the access without granting +o (but now I'm wondering about +t ; it's been so long for all of that)
[19:46] <mwhudson> liushuyu: good like with pike8.0 i got very confused
[19:46] <mwhudson> *luck
[19:56] <liushuyu> mwhudson: seems like some bad zlib detection in pike8.0 that caused those errors
[20:16] <liushuyu> okay, so pike8.0's zlib test can never succeed due to a bug in the test code, so it's always using vendored zlib code
[20:16] <liushuyu> (sounds familar?)
[20:16] <liushuyu> * familiar
[20:19] <mirespace> stellarsolver ftbfs solved, MP and package here: https://code.launchpad.net/~mirespace/ubuntu/+source/stellarsolver/+git/stellarsolver/+merge/464130
[20:20] <liushuyu> mirespace: can you record your findings in https://pad.riseup.net/p/migrate-list-amd64?
[20:21] <mirespace> liushuyu: yes of course, I wasn't sure about permissions for writting ... omw for adding the info there
[20:22] <mirespace> liushuyu: done, thank you
[20:22] <liushuyu> mirespace: You're welcome! And thanks for helping with the unblocking work!
[20:23] <mirespace> :)
[20:38] <liushuyu> pike8.0 fix: https://code.launchpad.net/~liushuyu-011/ubuntu/+source/pike8.0/+git/pike8.0/+merge/464142
[20:39] <liushuyu> ... also forwarded to Debian as https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1066378
[20:39] -ubottu:#ubuntu-devel- Debian bug 1066378 in src:pike8.0 "pike8.0: FTBFS: zlibmod.c:1235:5: error: implicit declaration of function ‘pop_n_elems’ [-Werror=implicit-function-declaration]" [Serious, Open]
[20:43] <liushuyu> ... wait a moment, pike8.0 isn't fully fixed
[20:43] <liushuyu> There are some other errors
[21:00] <liushuyu> pike8.0 fix updated
[21:04] <liushuyu> taking prelink
[21:23] <liushuyu> prelink fix: https://code.launchpad.net/~liushuyu-011/ubuntu/+source/prelink/+git/prelink/+merge/464143
[21:27] <liushuyu> taking prime-phylo
[21:31] <mirespace> taking slrn
[21:34] <mwhudson> liushuyu: oh heh
[21:42] <cgmb> Would anyone be able to sponsor a change to ucx on arm64 (dropping libamdhip64-dev from the B-D)? https://bugs.launchpad.net/ubuntu/+source/ucx/+bug/2060999
[21:42] -ubottu:#ubuntu-devel- Launchpad bug 2060999 in ucx (Ubuntu) "Please drop libamdhip64-5 from depends on arm64" [Undecided, New]
[22:00] <vpa1977> cgmb: sure, would it be possible to do a ppa build with the change?
[22:04] <mirespace> slrn fixed, MP and package at https://code.launchpad.net/~mirespace/ubuntu/+source/slrn/+git/slrn/+merge/464147
[22:05] <vpa1977> (not really a patch pilot, but will go through ftbfs fixes)
[22:18] <liushuyu> prime-phylo fix: https://code.launchpad.net/~liushuyu-011/ubuntu/+source/prime-phylo/+git/prime-phylo/+merge/464149
[22:20] <liushuyu> taking ruby-fusefs
[22:22] <mirespace> figuring out spherepack
[22:35] <enr0n> mirespace: FYSA I filed a removal bug for spherepack (bug 2060735). It hasn't been commented on/approved though.
[22:35] -ubottu:#ubuntu-devel- Bug 2060735 in spherepack (Ubuntu) "please remove spherepack and ncl from the archive" [Undecided, New] https://launchpad.net/bugs/2060735
[22:36] <mirespace> enr0n - I updated the list with that bug a moment ago
[22:36] <enr0n> cool
[22:36] <mirespace> thankyou for the ping enr0n
[22:36] <enr0n> no problem
[22:43] <liushuyu> ruby-fusefs fix: https://code.launchpad.net/~liushuyu-011/ubuntu/+source/ruby-fusefs/+git/ruby-fusefs/+merge/464150
[22:46] <liushuyu> taking rust-gdk-pixbuf-sys
[22:50] <cgmb> vpa1977: I'm not sure how to do a ppa build, but I can attach a log of a build I ran in qemu. It is... slow, but almost finished.
[22:50] <vpa1977> cgmb: thats fine this I will do it.
[23:11] <liushuyu> looking at rust-glib-sys test failures
[23:12] <liushuyu> The GIR data contains a lot of constants and functions that are not available on Unix-like platforms
[23:52] <mirespace> I'm surrender for today (or maybe I should say tomorrow now , hehe)... have fun