[01:19] terje: I believe you need to create an openpgp key and add it to your launchpad profile https://help.ubuntu.com/community/GnuPrivacyGuardHowto [01:20] then it you can use dput to upload your package: dput ppa:/

[01:42] looking at: mapserver-bin depends on conflicting packages: libcurl3t64-gnutls=8.5.0-2ubuntu8 vs libcurl3-gnutls=8.5.0-2ubuntu2 [01:49] mwhudson: did... you happen to not see there's a newer `xca` already in the archive? *points at 2.5.0-1build12* [01:50] 'cause... I think you missed that when you tried to do a rebuild against the t64 version of a qt5 package for build deps [01:50] s/1build12/1build2/ [01:51] teward: i ran my script without setting APT_CONFIG properly [01:52] mwhudson: ah, ok. XCA is on my direct ping list 'cause i'm also the DM for the package :P [01:52] teward: where do rejected uploads get reported though?? [01:52] i get emails on rejects [01:52] i did not know that! [01:52] i just uploaded a better one [01:52] ye i receive Rejected, etc. as the package maintainer [01:52] so things where i'm in the Maintainer field get me notified :p [01:53] til [01:53] anyway i've just uploaded a better versioned version [01:53] i think there is some difference in debian and ubuntu wrt which qt packages are getting renamed but that can be next week's problem [01:53] oh i'm pretty sure there are [01:53] AFAICT we're doing full renames on packages, etc. Debian is not [01:54] but that may be me being semi-ignorant and not watching closelyt [01:54] replacing the build-dep with one on the -dev package would help!! [01:54] if only that actually worked :p [01:55] *shrugs* Qt is weird [02:30] mkukri: asking you since you uploaded it last - is there a reason that the 70_no-bitmaps.conf file in fontconfig was changed from "false" to "false"? (Note "scalable" vs "outline".) When the value is set to "outline", it kills the ability for any native app in a KDE Plasma session to use Noto Color [02:30] Emoji, meaning emojis are broken all over the place. [02:30] Setting that value to "scalable" like it is on Jammy instantly fixes the issue. [02:36] (It also results in LibreOffice seeing Noto Color Emoji like it does on Jammy, but since this is a major regression I think we can live with that.) [02:42] looking at: * htcondor depends on conflicting packages: libcurl4t64=8.5.0-2ubuntu8 vs libcurl4=8.5.0-2ubuntu2 [03:32] mmpf [03:32] https://bugs.launchpad.net/ubuntu/+source/indicator-datetime/+bug/1987920 -- unity-control-center depends on this [03:32] -ubottu:#ubuntu-devel- Launchpad bug 1987920 in indicator-datetime (Ubuntu) "indicator-datetime fails to build with default gcc (gcc-12)" [High, Confirmed] [03:53] vorlon: should we remove indicator-datetime and rdeps? [03:53] (which includes a fair bit of unity afaics) [04:07] although haha it might be quite easy to fix [04:07] broken by the default colours changing in evolution-data-server... [04:26] ok fix works on amd64, let's see if it builds on armhf when i upload... [05:15] mwhudson: unity has a supported flavor [05:16] s/supported/official/ [05:16] vorlon: i fixed it anyway [05:16] ok [05:16] poor impulse control [08:33] arraybolt3: that might be an upstream change and/or mismerge, let me check [08:36] arraybolt3: we have inherited that from Debian (it changed in 2.15.0-1), it is not something i have changed. [08:36] jbicha: you look like the uploader of the revision that changed that. is that something we should keep in ubuntu? === sem2peie- is now known as sem2peie [09:44] sil2100: here's an armhf binary removal LP: #2058768 [09:44] -ubottu:#ubuntu-devel- Launchpad bug 2058768 in libwfa2 (Ubuntu) "libwfa2: Please RM armhf binaries" [Undecided, New] https://launchpad.net/bugs/2058768 [09:44] juliank: do you want to exclude libwfa2 from your reports? === sem2peie- is now known as sem2peie [09:45] ginggs: if binaries get removed they'll disappear 30 mins later [09:45] juliank: cool! [09:51] Hi, can someone sync 1. golang-github-google-go-github (60.0.0-1) and 2. dh-make-golang (0.7.0-1) from debian unstable. This fixes dh-make-golang FTBFS (see LP: #2046369). Note: The build order is important. [09:51] -ubottu:#ubuntu-devel- Launchpad bug 2046369 in dh-make-golang (Ubuntu) "dh-make-golang 0.6.0-2 fails to build from source" [Undecided, New] https://launchpad.net/bugs/2046369 [09:52] dviererbe: on it. [09:52] thx [09:52] ginggs: on it [09:54] ta! [09:55] dviererbe: erm, that's quite a version bump for that first package :/ [09:57] schopin: according to the changelog, there is no intermediate version [09:57] for both packages [09:58] ginggs: should be done now o/ [10:01] dviererbe: could you document in the bug why both new upstream versions should be synced (aside from "well, at least those build correctly")? [10:04] sil2100: so, LP: #2058912 is back on the RM train after all :/ [10:04] -ubottu:#ubuntu-devel- Launchpad bug 2058912 in xwiimote (Ubuntu) "t64: please remove xwiimote and rdeps armhf binaries from noble" [Undecided, New] https://launchpad.net/bugs/2058912 [10:05] schopin: I think I have no other reason than fixing the FTBFS [10:07] a general question is how aggressive we can be wrt removing packages on armhf: I think we should drop all of R, would that be likely accepted if there aren't dependent packages outside of the R realm? [10:08] schopin: looking! [10:08] anybody looking at the FTBFS on amd64 for cairo-dock-plug-ins? I see that's in universe, so I'll have a look if no-one else is already [10:08] that's probably quite a lot of work to assess so I'd prefer to have some input on that first [10:09] adrien: I think that'd be accepted, but you'd need to do the legwork of actually coming up with the list of binary packages :) [10:09] But I'm no AA. [10:15] I'm going to come up with a few categories and ask AAs directly [10:15] like bioinformatics [10:17] schopin: so looking at the packages in your rm bug, I see that xf86-input-xwiimote has a version in -proposed which does have armhf binaries, and deps on the t64 ones [10:18] Guess I'll remove the noble-proposed one as well [10:20] sil2100: how is that possible? oO [10:21] ah, no, so I see it rebuilt but the libxwiimote didn't change, just the changelog entry is confusing now [10:21] I'll drop the -proposed version alltogether I think [10:24] We could still execute https://magenta.jak-linux.org/ubuntu-archive/distcheck/noble.armhf/removal-candidates.with-proposed-missing.txt :) [10:25] plug holes hard :) [10:27] schopin: done [10:27] ta [10:27] or is it too weird to potentially only remove *some* binaries of a package, because I don't track if all packages in the source are leaf packages? === sem2peie- is now known as sem2peie [11:06] going to wait for britney to run, especially after the current test re-queues [11:06] and for the amd64 queue to stabilize [11:07] arraybolt3: I believe the emoji issue is fixed with fontconfig from noble-proposed [11:22] src:tanglet: libqt6gui6 [11:22] src:tetzle: libqt6gui6 [11:22] src:theli: libcurl4 [11:23] fixed these now [11:24] src:rustc-1.62: libllvm14 [11:24] src:rustc-1.68: libllvm15 [11:25] src:rustc-1.73: libllvm17 [11:25] src:rustc-1.74: libllvm17 [11:25] I guess I'll have a stub at these [11:25] * stab [11:28] TheRedQueen: ^^^??? [11:28] Thanks doko [11:28] doko: It's a bot, it automuted due to flooding [12:07] @pilot in === ChanServ changed the topic of #ubuntu-devel to: Archive: Feature Freeze | Devel of Ubuntu (not support) | Build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of Focal-Mantic | Patch Pilots: waveform [12:38] adrien: R removals, please file a bug report, with what you think should be removed, with a rdeps analysis [12:39] Retried arm64 test failures [12:40] Waiting for qa team to see about merging arm64 runs, it will drop the queue from 1481 -> 898 [12:41] doko: to clarify source removals need bugs, armhf removals just pinging on irc with reason and short analysis summary [12:52] Retrying armhf test failures after all teh weekend fixing [12:52] (queues on armhf are empty) [12:54] ugh kernels for focal have been uploaded, taking precious autopkgtest resources [12:55] I feel like these tests could wait until after time_t deadline [13:01] sure, but for that large number of R packages ... [13:40] adrien: are you already looking at rdeps for R removals? [13:40] rrrdeps [13:49] ginggs: no, not yet: I was looking at test queues this morning and just finished lunch, why? [13:51] Issuing some more no-change rebuilds [13:51] adrien: there's a subset of them (r-bioc-rhtslib and rdeps) which definitely can be removed [13:52] (debian decided to drop 32-bit architectures instead of doing time_t) [13:52] good to know, thanks [13:52] so i wondering whether i should go ahead and file a but for removal of those [13:52] do you have a link to a discussion? I'm curious as to why it would only be a subset [13:52] bug* [13:52] (or maybe others didn't require changes?) [13:53] (if so, I shouldn't have fixed the analysis for R packages and said every one of them required a transition :D ) [13:53] adrien: i can point you at debian bug #1063275 [13:53] -ubottu:#ubuntu-devel- Debian bug 1063275 in src:r-bioc-rhtslib "r-bioc-rhtslib: identified for time_t transition but no ABI in shlibs" [Serious, Fixed] https://bugs.debian.org/1063275 [13:53] thanks a lot! [13:55] should i file i bug for r-bioc-rhtslib in the meantime [13:58] ginggs: that would be great, thanks! I see r-bioc-rsamtools is mentioned there too (I see both as issues in armhf logs) [13:59] adrien: ack, i'll do that [14:00] and I was looking for a third one: r-bioc-variantannotation which I think is in the same boat with a removal request ( https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1063378 ) [14:00] -ubottu:#ubuntu-devel- Debian bug 1063378 in ftp.debian.org "RM: r-bioc-variantannotation [armel armhf i386 hppa m68k powerpc sh4] -- ROM; r-bioc-rhtslib does not support of 32 bit architectures any more" [Normal, Open] [14:00] I think these three are the top offenders I've seen in logs [14:05] adrien: for reference, LP: #2058933 [14:05] -ubottu:#ubuntu-devel- Launchpad bug 2058933 in r-bioc-rhtslib (Ubuntu) "r-bioc-rhtslib: Please RM armhf binaries" [Undecided, New] https://launchpad.net/bugs/2058933 [14:09] awesome, thanks! === JanC is now known as Guest5517 === JanC_ is now known as JanC [15:10] @pilot in === ChanServ changed the topic of #ubuntu-devel to: Archive: Feature Freeze | Devel of Ubuntu (not support) | Build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of Focal-Mantic | Patch Pilots: waveform, vorlon [15:14] I'm looking at pyxplot in order to ask for its removal; it's only used by debian-science metapackages and debian_science has a "dependency_data" directory which seems to be a versioning of the results of d/control: does anyone know how they're built and what they're used for? [15:14] it's only Recommends: pyxplot so it doesn't matter much IIUC but I'm curious [16:04] @pilot out === ChanServ changed the topic of #ubuntu-devel to: Archive: Feature Freeze | Devel of Ubuntu (not support) | Build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of Focal-Mantic | Patch Pilots: vorlon [16:11] what's the solution if i have a package that has @builddeps@ in its test depends, and failing tests because it needs the new dpkg from proposed. (passes with --apt-pocket=proposed=src:dpkg locally) [16:12] is re-trigger with all_proposed=1 a solution to that? [16:14] everything is being triggered with all proposed right now, at least on noble [16:14] regardless of what you do [16:14] the general answer would be to add &trigger=dpkg/ to the url, though [16:34] anyone looked at libbsd x gvmd? it seems to have a broken assumption that `%ld` is correct scanf arg for time_t where on 32-bit that's an obvious fail. is there a point fixing that, or removing armhf better? [16:35] there are several such cases btw (do you have the exact warning btw?) [16:35] if it can be removed it should be removed [16:36] but you can also fix it after asking for removal [16:36] it just doesn't become a blocker anymroe [16:36] adrien: `format ‘%ld’ expects argument of type ‘long int *’, but argument 3 has type ‘time_t *’ {aka ‘long long int *’} [-Wformat=]` [16:36] only a problem if long long != long, which is the case on armhf... [16:39] juliank: the offending version already migrated despite the regression listed, so maybe it was already removed? and it is not in the removal_candidates.txt you shared === JanC_ is now known as JanC [17:45] mkukri: the immediate answer is to ask for removal of armhf binaries where they are broken. the long-term answer is that yes, this should be changed to %lld -> (long long) time_t_var [17:47] jbicha: ah, it appears you're right. Didn't realize this wasn't Kubuntu-specific. Thank you! [17:47] (re: the emoji breakage) === tsimonq2_ is now known as tsimonq2 === NotEickmeyer is now known as Eickmeyer === gusnan_ is now known as gusnan === sem2peie- is now known as sem2peie [18:52] vorlon: i think the short answer was already done as the package in question is already in -release, i was just misled by it being on the update excuses page === JanC_ is now known as JanC [22:05] doko: Going to try to fight the hard-coded shlib depends, are there packages in particular that need attacked? I'm not quite sure what packages are to be fixed and what packages have already had their armhf binaries removed from the reports on juliank's server. [22:09] arraybolt3: the list (what I sent to the ML) is done [22:09] ah, so there's no more to fix? [22:09] or is there more to fix somewhere? I'm wanting to help out with the time_t transition if possible. [22:37] arraybolt3: at this point, look to fix build failures in -proposed, where packages ftbfs on non-armf === blahdeblah_ is now known as blahdeblah === mfo is now known as Guest3963 === mfo_ is now known as mfo