=== lesbraz is now known as sbraz
=== hosegypldlckylih is now known as didrgdfjeeuvlgel
=== didrgdfjeeuvlgel is now known as georgiag
=== JanC is now known as Guest3759
[09:04] <LocutusOfBorg> sudip, thanks, will check it
[09:05] <zhsj> hi, could someone help retrying this build https://launchpad.net/ubuntu/+source/golang-1.22/1.22.11-1/+build/30029786 it's a flaky test
[09:08] <LocutusOfBorg> zhsj, .
[09:08] <zhsj> thanks
[10:42] <adrien> Can someone retry the builds for armci-mpi: https://launchpad.net/ubuntu/+source/armci-mpi/0.4-4 ? There are no logs (anymore?) and the issue might have been related to openmpi and a transition finished a few weeks ago. Thanks. :)
[11:02] <sudip> adrien: done
[11:02] <adrien> sudip: thanks!
[11:36] <adrien> I'm looking at bochs which FTBFS on amd64 (and ppc64el?) but not in Debian. In Ubuntu the build goes through "override_dh_auto_build-indep" which fails and in Debian, it doesn't. What would explain the difference?
[11:37] <adrien> (also, I don't think it's easy to fix that build rule)
[11:48] <slyon> @pilot in
=== ChanServ changed the topic of #ubuntu-devel to: Archive: Open | Devel of Ubuntu (not support) | Build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of Focal-Oracular | Patch Pilots: slyon
[11:48] <ginggs> adrien: indep builds (arch:all) are separate in debian.  in ubuntu amd64 and arch:all are built together
[11:49] <ginggs> https://buildd.debian.org/status/package.php?p=bochs
[11:55] <bluca> slyon: hi - would you be able to help sponsor a backports upload, please? thanks! https://bugs.launchpad.net/ubuntu/+source/sphinxcontrib-globalsubs/+bug/2095011
[11:55] -ubottu:#ubuntu-devel- Launchpad bug 2095011 in sphinxcontrib-globalsubs (Ubuntu Noble) "[BPO] sphinxcontrib-globalsubs/0.1.2-2 from plucky" [Undecided, Confirmed]
[11:56] <adrien> ginggs: thanks! I found the target in the logs for arch=all :)  I'll see how I can fix the target. One question though: do these builds always run on amd64 machines in practice?
[12:01] <ginggs> adrien: i think there might be a way for a package to request arch:all be built on a different architecture, but it's 99.9% on amd64
[12:01] <toabctl> what's the way to get python-boto3 synced from debian into plucky? there seems to be a conflict but the patch we added in ubuntu is now also in debian and the version in debian got updated. so this can be synced now imo.
[12:02] <ginggs> toabctl: 'requestsync', see https://wiki.ubuntu.com/SyncRequestProcess
[12:03] <toabctl> thx!
[12:04] <adrien> ginggs: thanks again :)
[12:05] <slyon> bluca: yes, this looks pretty straight forward
[12:09] <slyon> https://launchpad.net/ubuntu/noble/+queue?queue_state=0&queue_text=sphinxcontrib-globalsubs
[12:13] <bluca> thanks!
[12:53] <schopin> adrien: ginggs: for reference, s390-tools has an example of an arch:all package that needs to be built on s390x, it's specified through the XS-Build-Indep-Architecture field.
[13:03] <jbicha> ginggs: I don't understand why poppler didn't smooth migrate. Do you want to try force hinting it in?
[13:21] <Skia> tsimonq2: since you already sponsored the `zip` upload to plucky, don't forget to come back to the oracular and noble SRUs, I've updated the changelogs after your feedback. Happy to discuss the versionning scheme here too, btw :-)
[13:26] <schopin> Skia: are you looking at the util-linux+shadow proposed migration?
[13:26] <Skia> yes, all autopkgtest are now green, I'm waiting for next britney run
[13:28] <Skia> the PS6 outage really didn't help in having those migrate :/
[13:28] <schopin> great, thanks :)
[13:45] <sudip> jbicha: excuses says poppler has old binaries left, hint wont work
[13:50] <jbicha> sudip: I don't understand what "old binaries" means. Every soname bump will have that but we're supposed to have our britney set to allow smooth updates
[13:54] <sudip> jbicha: https://ubuntu-archive-team.ubuntu.com/madison.cgi?package=poppler&a=&c=&s=plucky-proposed%2Cplucky&S=on shows '24.08.0-4' binaries are still there which is preventing the migration
[13:55] <sudip> that should have been removed automatically when that version was Superseded, but it was leftover
[13:56] <sudip> Britney should try it as soon as any of the ubuntu-archive admins removes those binaries
[13:57] <jbicha> thank you. I wouldn't have found that!
[14:05] <adrien> schopin: that's interesting, thanks
[14:06] <ginggs> schopin: thanks, I tried to searching for that, but had no luck
[14:06] <schopin> yeah, it's completely undocumented, I don't recall who told fheimes about it but I figured this was the opportunity to spread that knowledge a bit further.
[14:07] <ginggs> jbicha: let me know if a hint is still needed after the binary removals
[14:17] <adrien> schopin, ginggs : https://codesearch.debian.net/search?q=XS-Build-Indep-Architecture&literal=1
[14:18] <adrien> that's probably 0.001% of packages :P
[14:19]  * schopin is looking into the poppler thing
[14:25] <seb128> sudip, I cleaned the poppler binaries from plucky-proposed now
[14:26] <sudip> thanks seb128
[14:26] <seb128> schopin, ah sorry, I was in an hangout with Jeremy and did it before reading your IRC message
[14:26] <sudip> schopin: you are late ;-)
[14:26] <schopin> I'm learning!
[14:27] <jbicha> Seb pointed out to me that the excuses page is clear enough; I just wasn't familiar with this error case
[14:28] <seb128> that's an issue when new binaries are added but never migrate out of proposed and become NBS, there is no autocleaning
[14:28] <seb128> jbicha, I removed the os-prober upload from plucky-proposed also
[14:36] <sudip> schopin: if you want to remove something then lp: #2095193 please
[14:36] -ubottu:#ubuntu-devel- Launchpad bug 2095193 in ocaml-taglib (Ubuntu) "Please remove binaries of ocaml-taglib from plucky" [Undecided, New] https://launchpad.net/bugs/2095193
[14:50] <toabctl> slyon, hey. could help with sponsoring a debian sync please? see https://bugs.launchpad.net/ubuntu/+source/python-boto3/+bug/2095419
[14:50] -ubottu:#ubuntu-devel- Launchpad bug 2095419 in python-boto3 (Ubuntu) "Sync python-boto3 1.36.0+dfsg-1 (main) from Debian unstable (main)" [Wishlist, New]
[14:52] <slyon> toabctl: sure, let me take a look..
[14:52] <slyon> did you do a test-build somewhere?
[14:52] <toabctl> no. but I can do that now.
[14:56] <slyon> it's fine. I'm running an sbuild locally
[14:56] <toabctl> I did the same now. builds fine
[14:59] <slyon> ACK. Build passes, and I see the tests passing in dh_auto_test. Diff looking good, too.
[15:06] <slyon> toabctl: https://launchpad.net/ubuntu/+source/python-boto3/1.36.0+dfsg-1
[15:07] <toabctl> thx!
[15:49] <adrien> doko: you've removed r-cran-seurat 5.2.0-1, is it because you believe it's broken?
[16:04] <ginggs> adrien: i requested that, the new version in -proposed is making the migration of r-bioc-* difficult
[16:06] <slyon> @pilot out
=== ChanServ changed the topic of #ubuntu-devel to: Archive: Open | Devel of Ubuntu (not support) | Build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of Focal-Oracular | Patch Pilots: N/A
[16:09] <adrien> ginggs: I thought pretty much the same but wasn't sure, thanks for confirming :)
[16:16] <tsimonq2> Skia: ack will look after coffee :)
[16:17] <tsimonq2> Ooh, looks like my sponsorship report changes landed! Any feedback?
[16:17] <schopin> Might want to ask the most recent patch pilot ;)
[16:17] <schopin> Oh, looks like tomorrow's my shift.
[16:18] <adrien> I don't see build logs for https://launchpad.net/ubuntu/+source/armci-mpi/0.4-4/+build/29208895 but I saw some logs as the build progressed; what could have happened? Also, the build seemed stuck for a pretty long time.
[16:19] <schopin> adrien: the builder crashed.
[16:19] <schopin> e.g. OOM
[16:19] <adrien> that would be very consistent, thanks
[16:19] <schopin> yw
[16:20] <tsimonq2> slyon: WDYT? ;) ^^^
[16:20] <adrien> is disabling LTO a favored solution?
[16:22] <slyon> tsimonq2: Yes, I was surprised by the new looks. Looking very nice! There's some dead whitespace to the left/right of the table, which make for bigger rows. But I guess I can perfectly live with that :) Or is there any easy way to make it full-width?
[16:25] <adrien> I just looked at the page, it looks much better indeed. :)  And I don't see a trivial way to increase the max width which is set at 80rem in the code so maybe that needs to be changed there
[16:25] <adrien> also, some spacing between the navbar and table would be nice
[16:26] <ginggs> adrien: i see armci-mpi FTBFS everywhere except armhf and riscv64
[16:26] <ginggs> so disabling LTO is definitely worth a try
[16:27] <ginggs> similarly for https://launchpad.net/ubuntu/+source/kakoune/
[16:27] <adrien> I'll give it a try
[16:27] <ginggs> adrien: for universe packages, we could add them to lto-disabled-list
[16:27] <ginggs> https://launchpad.net/ubuntu/+source/lto-disabled-list/
[16:28] <ginggs> rather than carrying a delta
[16:28] <adrien> tsimonq2: also, I'd avoid "text-align:center" and maybe switch statistics to tables and last point maybe but I'm not sure it's feasible: make the table sortable (well, with JS it probably is)
[16:32] <adrien> ginggs: I'll try builds and follow up with an MRs for the list if that's effective (probably won't happen today)
[16:36] <enr0n> adrien: ginggs: I have had luck in the past getting patches accepted in debian which basically have if $DEB_VENDOR == Ubuntu -> disable lto
[16:37] <enr0n> I like having something in d/rules personally, because the lto-disabled-list is not very discoverable
[16:41] <adrien> enr0n: I'll definitely ponder doing that too. I think I had an LTO-related patch accepted in debian a few months ago too. I guess that if the memory usage is unreasonable everywhere, it could even be skipped for all distros. (and I keep forgetting about lto-disabled-list myself)
[16:43] <tsimonq2> enr0n: That's against policy now, I believe.
[16:43] <enr0n> tsimonq2: what is, exactly?
[16:43] <tsimonq2> enr0n: https://www.debian.org/doc/debian-policy/ch-source.html#vendor-specific-patch-series
[16:43] <tsimonq2> I may be wrong :)
[16:44] <enr0n> tsimonq2: that's about vendor-specific debian/patches/series, no?
[16:44] <adrien> I think so too
[16:45] <tsimonq2> slyon, adrien: Thanks :) I usually use Bootstrap and not Vanilla, so there's a bit of a learning curve for me. I think there's a way to do sortable tables natively with Vanilla, and as for the rest of the CSS modifications, I'll take a look. :)
[16:45] <tsimonq2> enr0n: Ah okay, you're talking about a rules file, yeah?
[16:45] <adrien> (I remember we discussed that feature on foundations' MM channel a few weeks ago, that was a TIL :P )
[16:46] <enr0n> tsimonq2: correct
[16:46] <adrien> tsimonq2: :) CSS is hard, frameworks are plenty, and optimal width is a unicorn :'(
[16:46] <tsimonq2> enr0n: I'm mistaken then, false alarm ;)
[16:46] <tsimonq2> adrien: CSS definitely isn't my favorite, but I'll take one for the team (volunteers welcome... ;P)
[16:47] <tsimonq2> https://code.launchpad.net/ubuntu-sponsoring
[16:57] <tsimonq2> Oooh, thanks to amurray it also has a .launchpad.yaml file now for CI! :)
[16:57] <jbicha> Frequently, it works to just disable LTO for Debian too. Debian may eventually enable LTO by default
[16:58] <jbicha> export DEB_BUILD_MAINT_OPTIONS=optimize=-lto
[17:00] <adrien> tsimonq2: I can contribute a bit but pretty often, for CSS, I find that my changes are a couple lines at most and almost better of IM
=== nukelet9 is now known as nukelet
[17:53] <LocutusOfBorg> liushuyu, hello, ldc FTBFS
[17:53] <liushuyu> LocutusOfBorg: I am very sorry about that, I am testing a new build
[17:54] <LocutusOfBorg> the extra flag broke it
[17:54] <liushuyu> LocutusOfBorg: https://salsa.debian.org/d-team/ldc/-/merge_requests/8
[17:54] -ubottu:#ubuntu-devel- Merge 8 in d-team/ldc "d/rules: fix the build regression in the previous revision" [Opened]
[17:55] <liushuyu> LocutusOfBorg: You are right, the issue was (1) LDC always uses LLVM's own switches as its switches, so if LLVM version changes, its switches will change too (2) the build system sometimes accepts whitespace-separated flags, sometimes accepts semi-colon-separated flags and I got confused
[17:56] <liushuyu> I now have a PPA build for this one v
[17:56] <liushuyu> https://launchpad.net/~liushuyu-011/+archive/ubuntu/misc/+sourcepub/16892189/+listing-archive-extra
[18:13] <liushuyu> LocutusOfBorg: Also I have https://salsa.debian.org/d-team/dh-dlang/-/merge_requests/3 to improve dh-dlang support for LDC (also added autopkgtest to avoid accidental breakage)
[18:13] -ubottu:#ubuntu-devel- Merge 3 in d-team/dh-dlang "Derive `DFLAGS` from `CFLAGS` as well when using LDC" [Opened]
[18:23] <liushuyu> doko: Also it seems to me that on Ubuntu, even if you don't have time64 specified on armhf, we still append time64 flags during the build (at least according to the build logs I examined)
[18:24] <liushuyu> (Context: I am talking about the comment here: https://bugs.launchpad.net/ubuntu/+source/ruby-defaults/+bug/2085283)
[18:24] -ubottu:#ubuntu-devel- Launchpad bug 2085283 in ruby-defaults (Ubuntu) "Merge ruby-defaults from Debian unstable for plucky" [High, Confirmed]
[18:25] <doko> liushuyu: then why not sync?
[18:26] <liushuyu> doko: I was just following a previous merge (the previous merge also dropped this change)
[18:27] <liushuyu> ... and we also have more changes than Debian, I have forwarded all of them here: https://salsa.debian.org/ruby-team/ruby/-/merge_requests/9
[18:27] -ubottu:#ubuntu-devel- Merge 9 in ruby-team/ruby "Fix memory corruption issues and enable LTO" [Opened]
[18:56] <sudip> jbicha: poppler is migrating
[20:02] <tsimonq2> schopin: Would you be able to look at the running builds that are stuck and cancel/retry? Seeing a handful of instances on https://launchpad.net/builders - I don't have access to do it and it would be beneficial to unstick things.
[20:02] <tsimonq2> (re: test rebuilds)
[20:17] <LocutusOfBorg> liushuyu, is your dh-dlang a superset of my changes?
[20:17] <liushuyu> LocutusOfBorg: No, I just rebased my changes onto my branch
[20:17] <liushuyu> * rebased your changes
[20:17] <LocutusOfBorg>     DFLAGS_TRANSLATED = $(shell python3 /usr/share/dh-dlang/gcc-to-ldc-flags.py --dh-dlang-ignore-unknown-options $(CFLAGS))
[20:17] <LocutusOfBorg> this variable is not exported?
[20:20] <liushuyu> LocutusOfBorg: Thanks! It's a rebase issue, I have fixed that now
[20:21] <liushuyu> I actually wonder if DFLAGS in the debhelper (from dpkg-dev) is really used
[20:23] <liushuyu> LocutusOfBorg: It should be DFLAGS = -release -wi $(DFLAGS_TRANSLATED)
[20:23] <liushuyu> (the first two arguments will never appear in CFLAGS or DFLAGS)
[20:36] <LocutusOfBorg> done all of them please double check
[20:36] <LocutusOfBorg> I'm afk
[20:39] <liushuyu> LocutusOfBorg: Thank you very much! LGTM now
[21:05] <tsimonq2> Tons of these on a full-upgrade today (Plucky system):
[21:05] <tsimonq2> /usr/bin/py3clean:101: DeprecationWarning: glob.glob1 is deprecated and will be removed in Python 3.15. Use glob.glob and pass a directory to its root_dir argument instead. for fn in glob1(directory, "%s.*" % fname):
[21:05] <tsimonq2> doko, ginggs: ^^^^ that belongs to python3-minimal, is it known?
[21:06] <jbicha> tsimonq2: what version of python3-minimal do you have installed?
[21:07] <tsimonq2> python3-minimal/plucky-proposed,now 3.13.1-1~exp2
[21:08] <jbicha> you have plucky in the future 😉
[21:08] <tsimonq2> Yes, yes I do. ;)
[21:09] <ginggs> tsimonq2: I think that's https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1092357
[21:09] -ubottu:#ubuntu-devel- Debian bug 1092357 in python3-minimal "py3clean: DeprecationWarning: glob.glob1 is deprecated and will be removed in Python 3.15." [Important, Fixed]
[21:09] <tsimonq2> ginggs: Yup, that's exactly it!
[21:10] <tsimonq2> I suppose y'all are waiting for the existing churn to finish before a new python3-defaults upload?
[21:10] <ginggs> Exactly
[21:10] <tsimonq2> Sounds good - as long as it's known, no problem :)
[21:12] <tsimonq2> ginggs: Might you have access to look at stuck test rebuilds as I mentioned to Simon earlier? ^^^
[21:20] <ginggs> tsimonq2: I do, looking...
[21:21] <tsimonq2> ginggs: TIA :)
[22:02] <jbicha> athos: I believe the php-defaults diff is longer needed since it was included in the most recent LTS. On the other hand, an Ubuntu diff allowed running the php transition when we wanted instead of when it autosynced
[22:04] <athos> jbicha: this is pretty much why we are keeping the delta for now!
[22:05] <athos> at least we get some control on when to start the transition
[22:18] <mwhudson> maybe using the sync blocklist would be a cleaner way of doing htat
[22:19] <mwhudson> (maybe)