| === alucardromero2 is now known as alucardromero | ||
| === chris14_ is now known as chris14 | ||
| mwhudson | jbicha: any news on folks ftbfs? | 04:15 |
|---|---|---|
| mwhudson | whyyyy are all the haskell-gi-* packages broken | 05:24 |
| === pushkarnk1 is now known as pushkarnk | ||
| LocutusOfBorg | mwhudson, good question, related to haskell | 09:09 |
| LocutusOfBorg | not sure | 09:09 |
| -queuebot:#ubuntu-release- Unapproved: accepted linux-firmware [source] (mantic-proposed) [20230919.git3672ccab-0ubuntu2.10] | 09:18 | |
| -queuebot:#ubuntu-release- Unapproved: accepted linux-firmware [source] (jammy-proposed) [20220329.git681281e4-0ubuntu3.30] | 09:19 | |
| -queuebot:#ubuntu-release- Unapproved: accepted qemu [source] (mantic-proposed) [1:8.0.4+dfsg-1ubuntu3.23.10.4] | 09:25 | |
| tjaalton | dviererbe: hi, looking at dotnet*. at least dotnet6 for mantic mentions changes that are not in the diff | 09:40 |
| dviererbe | tjaalton: Can you give me an example? | 09:41 |
| tjaalton | d/rules and d/copyright | 09:42 |
| tjaalton | and dotnet7 for mantic has the git repo in the diff | 09:42 |
| -queuebot:#ubuntu-release- Unapproved: rejected dotnet7 [source] (mantic-proposed) [7.0.117-0ubuntu1~23.10.2] | 09:43 | |
| dviererbe | Okay, thanks. I look into it. | 09:43 |
| -queuebot:#ubuntu-release- Unapproved: accepted firmware-sof [source] (jammy-proposed) [2.0-1ubuntu4.7] | 09:45 | |
| tjaalton | and I'm not sure if all the test changes should be lumped in the same bug adding a new dependency | 09:45 |
| dviererbe | tjaalton: The diff in launchpad is against 7.0.110-0ubuntu1, but the latest version is 7.0.117-0ubuntu1~23.10.1 | 09:49 |
| dviererbe | I was super confused, because I only did changes in debian/* | 09:50 |
| tjaalton | okay | 09:50 |
| tjaalton | tooling issue then | 09:50 |
| tjaalton | it doesn't know of -security | 09:50 |
| dviererbe | Regarding dotnet6 changelog. You are right. This is a copy&paste error and already included with the previous upload. | 09:54 |
| dviererbe | How is this fixable? | 09:55 |
| tjaalton | okay, just leave it | 09:56 |
| tjaalton | 2057982 headline at least should be changed if it's this massive change instead of just adding a dep | 09:56 |
| dviererbe | ack, changed it | 09:57 |
| tjaalton | well it's still just a question :) | 10:01 |
| dviererbe | Regarding if the test should be included. The old testsuite is known to fail. If I do not change the tests, then the test do not pass. | 10:03 |
| -queuebot:#ubuntu-release- Unapproved: accepted dotnet8 [source] (mantic-proposed) [8.0.103-8.0.3-0ubuntu1~23.10.2] | 10:06 | |
| -queuebot:#ubuntu-release- Unapproved: accepted dotnet8 [source] (jammy-proposed) [8.0.103-8.0.3-0ubuntu1~22.04.2] | 10:08 | |
| -queuebot:#ubuntu-release- Unapproved: accepted dotnet7 [source] (jammy-proposed) [7.0.117-0ubuntu1~22.04.2] | 10:11 | |
| -queuebot:#ubuntu-release- Unapproved: accepted dotnet6 [source] (jammy-proposed) [6.0.128-0ubuntu1~22.04.2] | 10:12 | |
| tjaalton | dviererbe: you need to build packages with -v"foo" to include the changelog of the current version in proposed | 10:13 |
| tjaalton | without that, tracking the closing of the bug won't happen automatically | 10:13 |
| tjaalton | missed that from dotnet6 for jammy, but you can still fix mantic | 10:14 |
| dviererbe | I thought that -v just affects how many entries of the changelog are included in the .changes file | 10:17 |
| tjaalton | yes, and those include the refs to sru bugs | 10:17 |
| tjaalton | the new dotnet6 uploads don't have a ref to the current one in proposed now | 10:18 |
| dviererbe | Just so I understood you correctly: I should get a new source package uploaded with -v set, right? | 10:19 |
| dviererbe | for dotnet6 mantic | 10:19 |
| tjaalton | I'm trying to remember if it's just the auto-closing on release that it'll miss if that's not done | 10:21 |
| tjaalton | in that case it's just a matter of doing it manually | 10:21 |
| tjaalton | (by you :) | 10:21 |
| tjaalton | or if it's just spamming the old bug. which is irrelevant here | 10:23 |
| tjaalton | your call, I think | 10:23 |
| -queuebot:#ubuntu-release- Unapproved: accepted landscape-client [source] (mantic-proposed) [23.08-0ubuntu1.1] | 10:24 | |
| dviererbe | I am happy to it manually this time and make sure to apply it on the next upload. | 10:24 |
| tjaalton | okay, good | 10:25 |
| tjaalton | the main benefit, iirc, is spamming the old bugs to re-test assuming the new update fixes a flaw in the original sru | 10:26 |
| dviererbe | Sorry for the complications. It's a while since I had to do an .NET SRU, since all the previous uploads where security uploads and the security team took care of many things. | 10:26 |
| tjaalton | no worries | 10:29 |
| -queuebot:#ubuntu-release- Unapproved: accepted dotnet6 [source] (mantic-proposed) [6.0.128-0ubuntu1~23.10.2] | 10:52 | |
| -queuebot:#ubuntu-release- Unapproved: accepted runc [source] (mantic-proposed) [1.1.7-0ubuntu2.3] | 10:56 | |
| -queuebot:#ubuntu-release- Unapproved: accepted runc [source] (jammy-proposed) [1.1.7-0ubuntu1~22.04.3] | 10:57 | |
| -queuebot:#ubuntu-release- Unapproved: accepted dpdk [source] (mantic-proposed) [22.11.4-0ubuntu0.23.10.1] | 11:00 | |
| -queuebot:#ubuntu-release- Unapproved: accepted runc [source] (focal-proposed) [1.1.7-0ubuntu1~20.04.3] | 11:01 | |
| -queuebot:#ubuntu-release- Unapproved: accepted dpdk [source] (jammy-proposed) [21.11.6-0ubuntu0.22.04.1] | 11:03 | |
| -queuebot:#ubuntu-release- New sync: libcypher-parser (noble-proposed/primary) [0.6.2-0.1] | 11:03 | |
| ginggs | tjaalton, dviererbe: sorry for missing the -v in the dotnet6 uploads | 11:08 |
| dviererbe | ginggs: no worries, I wasn't aware that dpkg-genchanges generates a Launchpad-Bugs-Fixed field. Maybe we should add this to the manpage? | 11:11 |
| -queuebot:#ubuntu-release- New: accepted libcypher-parser [sync] (noble-proposed) [0.6.2-0.1] | 11:17 | |
| -queuebot:#ubuntu-release- New binary: libcypher-parser [amd64] (noble-proposed/none) [0.6.2-0.1] (no packageset) | 11:20 | |
| -queuebot:#ubuntu-release- New binary: libcypher-parser [arm64] (noble-proposed/none) [0.6.2-0.1] (no packageset) | 11:21 | |
| -queuebot:#ubuntu-release- New binary: libcypher-parser [s390x] (noble-proposed/none) [0.6.2-0.1] (no packageset) | 11:21 | |
| -queuebot:#ubuntu-release- New binary: libcypher-parser [ppc64el] (noble-proposed/none) [0.6.2-0.1] (no packageset) | 11:22 | |
| -queuebot:#ubuntu-release- New binary: libcypher-parser [armhf] (noble-proposed/none) [0.6.2-0.1] (no packageset) | 11:23 | |
| doko | mitya57: I see you filed https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1067009, are you involved? | 11:30 |
| -ubottu:#ubuntu-release- Debian bug 1067009 in src:lomiri-ui-toolkit "lomiri-ui-toolkit: FTBFS: 63 failures which MUST be fixed" [Serious, Open] | 11:30 | |
| juliank | ubuntu-archive please rm apt-verify as per https://bugs.launchpad.net/ubuntu/+source/apt-verify/+bug/2058734 - ta! | 11:40 |
| -ubottu:#ubuntu-release- Launchpad bug 2058734 in apt-verify (Ubuntu) "RM: apt-verify; not fit for purpose, not installable" [Undecided, New] | 11:40 | |
| -queuebot:#ubuntu-release- New binary: libcypher-parser [riscv64] (noble-proposed/none) [0.6.2-0.1] (no packageset) | 11:40 | |
| -queuebot:#ubuntu-release- New: accepted libcypher-parser [amd64] (noble-proposed) [0.6.2-0.1] | 11:59 | |
| -queuebot:#ubuntu-release- New: accepted libcypher-parser [armhf] (noble-proposed) [0.6.2-0.1] | 11:59 | |
| -queuebot:#ubuntu-release- New: accepted libcypher-parser [riscv64] (noble-proposed) [0.6.2-0.1] | 11:59 | |
| -queuebot:#ubuntu-release- New: accepted libcypher-parser [arm64] (noble-proposed) [0.6.2-0.1] | 11:59 | |
| -queuebot:#ubuntu-release- New: accepted libcypher-parser [s390x] (noble-proposed) [0.6.2-0.1] | 11:59 | |
| -queuebot:#ubuntu-release- New: accepted libcypher-parser [ppc64el] (noble-proposed) [0.6.2-0.1] | 11:59 | |
| doko | juliank: done | 12:07 |
| mitya57 | doko: I just filed that bug, but don't have ideas how to fix it yet. And what caused it. | 12:13 |
| doko | at least the tests are disabled on armhf, so we will be able to build new binaries | 12:19 |
| schopin | ubuntu-archive: please RM libosmo-inet and friends from armhf as per https://bugs.launchpad.net/ubuntu/+source/libosmo-netif/+bug/2058739 | 12:20 |
| -ubottu:#ubuntu-release- Launchpad bug 2058739 in libosmo-netif (Ubuntu) "t64: remove libosmo-netif and rdeps from armhf" [Undecided, New] | 12:20 | |
| doko | schopin: so I have to find the binary names for myself? ;p doing now | 12:24 |
| fossfreedom_ | hi ubuntu-release - I am trying to figure out why the nemo autopkgtest for amd64 is marked as failed here https://ubuntu-archive-team.ubuntu.com/proposed-migration/noble/update_excuses.html but if you click on the amd64 hyperlink both brian and myself have poked the rebuild and the results have work. The red failed result is still from the 15th March. Can someone please 'unconfuse me' ? cheers. | 12:31 |
| doko | schopin: done | 12:46 |
| schopin | doko: thanks :) | 12:46 |
| doko | fossfreedom_: that was 2h ago, most likely will be part of a next update of excuses | 12:48 |
| fossfreedom_ | 🤞 cheers | 12:50 |
| juliank | The edos-distcheck reports (not the removal-candidates obviously) in https://magenta.jak-linux.org/ubuntu-archive/distcheck/noble.armhf/ now only show unsatisfiable build-dependencies for packages which have armhf binaries in the release pocket | 12:55 |
| juliank | They probably should be their own reports when I clean this up and put it on Canonical infra | 12:56 |
| juliank | Now it just appends `, but not a regression` | 13:02 |
| juliank | But I added https://magenta.jak-linux.org/ubuntu-archive/distcheck/noble.armhf/proposed.only-regressions.txt | 13:06 |
| rbasak | ubuntu-archive: I think src:glewlwyd is blocking gnutls28 and meets Steve's criteria for removal. I'm not sure if I have my tooling right here - please could you check? | 13:19 |
| rbasak | In particular the revdeps. | 13:19 |
| rbasak | Oh. On an older release, reverse-depends says nothing. But on a newer release it fails with 403 Forbidden. | 13:20 |
| rbasak | Do we know what that's about? | 13:20 |
| -queuebot:#ubuntu-release- New binary: libcupsfilters [amd64] (noble-proposed/main) [2.0.0-0ubuntu6] (no packageset) | 13:29 | |
| -queuebot:#ubuntu-release- New binary: libcupsfilters [s390x] (noble-proposed/main) [2.0.0-0ubuntu6] (no packageset) | 13:29 | |
| juliank | rbasak: https://magenta.jak-linux.org/ubuntu-archive/distcheck/noble.armhf/removal-candidates.txt confirms it is a leaf package | 13:29 |
| juliank | > 0 glewlwyd | 13:29 |
| -queuebot:#ubuntu-release- New binary: libcupsfilters [armhf] (noble-proposed/main) [2.0.0-0ubuntu6] (no packageset) | 13:29 | |
| juliank | This takes provides into accounts unlike reverse-depends | 13:29 |
| -queuebot:#ubuntu-release- New binary: libcupsfilters [ppc64el] (noble-proposed/main) [2.0.0-0ubuntu6] (no packageset) | 13:29 | |
| rbasak | Thanks! | 13:30 |
| -queuebot:#ubuntu-release- New binary: ubuntu-mate-artwork [amd64] (noble-proposed/universe) [24.04.0] (ubuntu-mate) | 13:33 | |
| -queuebot:#ubuntu-release- New: accepted ubuntu-mate-artwork [amd64] (noble-proposed) [24.04.0] | 13:35 | |
| -queuebot:#ubuntu-release- New binary: libcupsfilters [arm64] (noble-proposed/main) [2.0.0-0ubuntu6] (no packageset) | 13:36 | |
| juliank | rbasak: Oh you said src:glewlwyd, the script checks the binary package. The armhf binary certainly can be removed, but the others are ok too, at least on armhf. | 13:39 |
| juliank | rbasak: So the policy to remove armhf binaries is to ping, but source package removals need a bug | 13:39 |
| rbasak | juliank: ah I didn't appreciate the difference. Will just removing the armhf binary be sufficient then? | 13:40 |
| juliank | yeah | 13:41 |
| rbasak | On another thread, Debian has a time_t fix for iddawc in a new upload that I think we should take. I could sync it, but Debian's upload also includes "Use pkgconf instead of pkg-config" as a B-D change. Is this worth adding an Ubuntu delta to avoid that change, or should I just sync it? | 13:41 |
| juliank | ubuntu-archive: remove-package -b -a glewlwyd | 13:41 |
| rbasak | Oh pkg-config is just a transitional package that depends on pkgconf | 13:43 |
| rbasak | So no functional change there, so I'll sync | 13:43 |
| juliank | rbasak: This found a bug in the script, other files that filtered on packages having an upload in proposed (with or without a missing build) only showed source packages producing a single binary as I split the "Binary" field on spaces instead of "," | 13:45 |
| juliank | Now you can see it in https://magenta.jak-linux.org/ubuntu-archive/distcheck/noble.armhf/removal-candidates.with-proposed-missing.txt | 13:45 |
| juliank | Essentially "0 glewlwyd" says that "glewlwyd" is blocking migration of "src:glewlwyd" | 13:46 |
| juliank | because glewlwyd is in release but missing a build in proposed :) | 13:46 |
| juliank | All of these binaries are (assuming the package builds on other architectures) blocking migration and can be removed: https://magenta.jak-linux.org/ubuntu-archive/distcheck/noble.armhf/removal-candidates.with-proposed-missing.txt | 13:47 |
| juliank | That's 351 binary packages | 13:48 |
| juliank | Just wholesale drop them, they (1) are leaf packages, (2) have a newer version in proposed, (3) said newer version is missing a build for those binaries | 13:48 |
| juliank | Let's avoid doing long manual analysis each time :) | 13:49 |
| rbasak | Sure, but I have no idea what I'm doing on my +1 shift then, apart from manual analysis! | 13:49 |
| rbasak | I need a list of items that need manual attention really | 13:49 |
| juliank | We also have amd64 reports! | 13:51 |
| rbasak | If someone were to give me a specific +1 task to work on then I'd happily work on it. | 13:51 |
| rbasak | Eg. "figure out how to fix the build for $foo" | 13:51 |
| rbasak | or "make package $foo's autopkgtest for $arch" pass | 13:52 |
| juliank | I think we lost cross toolchains on armhf, doko , and it's breaking bochs, u-boot, snek, qemu | 13:52 |
| juliank | See https://magenta.jak-linux.org/ubuntu-archive/distcheck/noble.armhf/proposed.only-regressions.txt | 13:52 |
| -queuebot:#ubuntu-release- Unapproved: ubuntu-advantage-tools (mantic-proposed/main) [31.2~23.10 => 31.2.1~23.10] (core) | 13:52 | |
| rbasak | But honestly right now I feel like the entire +1 maintenance programme is pointless. I'm not really doing anything useful. Just flailing about wasting all my time trying to find something useful to do. | 13:52 |
| rbasak | juliank: I appreciate your work, but that doesn't seem to translate to something *specific* for me to do. | 13:53 |
| juliank | rbasak: It was more for doko :) | 13:53 |
| juliank | rbasak: There were specific actions, but we all do +1 maintenance basically | 13:53 |
| -queuebot:#ubuntu-release- Unapproved: ubuntu-advantage-tools (jammy-proposed/main) [31.2~22.04 => 31.2.1~22.04] (core) | 13:53 | |
| juliank | rbasak: Like in the report I uploaded execline to fix the dependency issue in the last paragraph and a bunch more but now they are all rsolved | 13:54 |
| juliank | Not sure about the python3.12 stuff | 13:54 |
| -queuebot:#ubuntu-release- Unapproved: rejected ubuntu-advantage-tools [source] (mantic-proposed) [31.2.1~23.10] | 13:54 | |
| juliank | It is rebuilt, but somehow dose-distcheck picked up the old one | 13:54 |
| -queuebot:#ubuntu-release- Unapproved: rejected ubuntu-advantage-tools [source] (jammy-proposed) [31.2.1~22.04] | 13:55 | |
| juliank | similarly libvirt-dev:armhf -> libvirt0:armhf (= 10.0.0-2ubuntu1) -> libglib2.0-0:armhf (>= 2.58.0) looked at old libvirt | 13:56 |
| juliank | I told the script to only look at the latest one, sigh | 13:56 |
| juliank | but rrdtool, profotbuf-c, timblserver, execline were actionable | 13:58 |
| juliank | doko: ok sorry, I don't know why dose-distcheck complains about bochs build-depending on gcc cross | 14:01 |
| juliank | Probably it tries to satisfy Build-Depends-Indep but they are only needed on amd64 | 14:01 |
| rbasak | courier-authlib depends on libgdbm6 instead of libgdbm6t64. It hasn't had an upload/rebuild since Lunar. Is there any reason why it hasn't had a no change rebuild from someone's automation? | 14:01 |
| juliank | rbasak: Do it, it doesn't even show up on my automation | 14:03 |
| rbasak | ack | 14:03 |
| juliank | Probably libgdbm6 is still installable :) | 14:03 |
| juliank | i.e. essential + courier-authlib still installs or I'd see it by now | 14:03 |
| juliank | rbasak: If you need trivial work, https://magenta.jak-linux.org/ubuntu-archive/distcheck/noble.armhf/proposed-binaries.txt has a trivial list at the start | 14:04 |
| juliank | rbasak: This is basically packages that have hardcoded libfoo1 depends and then gained libfoo1t64 from shlibs | 14:04 |
| rbasak | We should be able to find all binaries that don't have replacements in proposed that depend on a known list of non-t64 libs, surely? | 14:04 |
| juliank | Yes so I need to get the renamed library list and then could build one | 14:05 |
| juliank | The normal transition tracker doesn't work somehow | 14:05 |
| rbasak | Even if the list isn't complete I think it would probably be useful to just have the major ones that are showing up everywhere - that'd probably help with most of the entanglements. | 14:05 |
| juliank | https://ubuntu-archive-team.ubuntu.com/transitions/html/html/auto-gdbm.html | 14:06 |
| juliank | e.g. | 14:06 |
| juliank | courier-authlib doesn't appear there | 14:06 |
| rbasak | Package: courier-authlib | 14:06 |
| rbasak | Depends: adduser, libc6 (>= 2.34), libcrypt1 (>= 1:4.1.0), libgcc-s1 (>= 3.5), libgdbm6 (>= 1.16), libltdl7 (>= 2.4.7), libpam0g (>= 0.99.7.1), libstdc++6 (>= 5.2) | 14:06 |
| juliank | Yes | 14:06 |
| juliank | and that matches Bad: .depends ~ /\b(libgdbm\-compat4|libgdbm6)\b/ | 14:07 |
| juliank | and Affected too | 14:07 |
| juliank | so ben is broken or something? | 14:07 |
| rbasak | :-/ | 14:07 |
| doko | ben is broken, yes. I thought sil2100 would update it? | 14:07 |
| juliank | Oh I can write my own global ben easily I see | 14:07 |
| juliank | I feel like end of next week I'll have written my own britney | 14:08 |
| juliank | Let me whip up a global-ben.py | 14:09 |
| juliank | rbasak: OK so here's a global-ben.py output https://magenta.jak-linux.org/ubuntu-archive/distcheck/noble.armhf/global-ben.txt - this shows all binaries that depend on binaries removed in proposed (i.e. not present in the same source package in proposed) | 14:23 |
| juliank | I can also reverse this and group it by dependency | 14:23 |
| juliank | Then it is more ben like | 14:24 |
| juliank | I think global-ben is usable nowp | 14:30 |
| juliank | libaunit21 Reverse-Depends: libaunit22-dev | 14:37 |
| juliank | funny | 14:37 |
| juliank | So tons of stuff that needs rebuilding, if you grep that for rebuild-for | 14:38 |
| rbasak | You can additionally grep for t64 specifically | 14:39 |
| rbasak | Do you want to upload those? Ordering might matter though. | 14:40 |
| juliank | That's the other question, do we want to upload them or do we want to let stuff migrate first, I don't think they block migration? | 14:41 |
| juliank | rbasak: t64 you can grep for but that's where it adds the rebuild-for comment | 14:41 |
| juliank | :D | 14:41 |
| juliank | 2331 binary packages depend on old versions | 14:42 |
| juliank | Should I make this produce source packages | 14:42 |
| rbasak | It doesn't show up in update_excuses yet, but I think gdbm would have been blocked by courier once its autopkgtests are clear, and courier FTBFS because of courier-authlib. | 14:44 |
| rbasak | So I think there are cases where this list does block migration. Maybe not all of them though. | 14:44 |
| juliank | Nicer now | 14:45 |
| juliank | It now shows source packages right hand of : | 14:46 |
| rbasak | https://launchpad.net/builders - if that means what I think it does then the armhf build queue isn't bad at all at 15 minutes | 14:46 |
| juliank | I wonder if I should extend the script now that I have that data, I could make it build a tree of build-dependencies, order them and then give me rebuild-for instructions | 14:47 |
| juliank | But vorlon was saying we should just upload all packages | 14:47 |
| juliank | or rather they'd all be binNMUed in Debian | 14:47 |
| juliank | And if anything misbuilds it goes in for another round | 14:48 |
| juliank | I' | 14:48 |
| rbasak | Fine by me | 14:48 |
| juliank | So I think I'll just do all | 14:48 |
| juliank | I' | 14:48 |
| juliank | I will just amend the script slightly for nicer changelog entries :) | 14:48 |
| rbasak | Note that courier-authlib is already done :) | 14:54 |
| rbasak | (it's awaiting build) | 14:54 |
| ahasenack | the build queue is increasing, despite there being several idle builders | 14:54 |
| ahasenack | https://launchpad.net/builders | 14:54 |
| ahasenack | I started looking when the amd64 queue was at 60 jobs (because my build hasn't started yet), and it's now 79 | 14:55 |
| ahasenack | and ton of idle amd64 builders, according to that page | 14:55 |
| juliank | rbasak: https://magenta.jak-linux.org/ubuntu-archive/distcheck/noble.armhf/global-ben.rebuild-for.txt | 14:55 |
| juliank | Ah source package it should use | 14:56 |
| juliank | It now ignores packages that are missing a build in proposed | 14:57 |
| juliank | and gives me instructions for my rebuild script | 14:57 |
| Eickmeyer | ahasenack: Several jobs "cleaning" for an hour. Something needs to be kicked, I reckon. | 14:58 |
| seb128 | -> #launchpad | 14:58 |
| Eickmeyer | ^ indeed | 14:58 |
| juliank | Well 1690 packages to rebuild | 15:01 |
| juliank | let's goo | 15:01 |
| juliank | Ah shoot | 15:02 |
| juliank | I did not deduplicate source packages :) | 15:02 |
| juliank | 1120 | 15:05 |
| juliank | much better | 15:05 |
| doko | LP issue, raised with the LP team | 15:22 |
| juliank | OK actually 500 | 15:27 |
| juliank | but should be fine now | 15:27 |
| juliank | My rebuild-for script also ensures that if pull-lp-source finds a newer upload mentioning a t64 library that we do not trigger a rebuild | 15:28 |
| rbasak | Sounds good! | 15:38 |
| juliank | Just added Recommends to the ignore list | 15:49 |
| juliank | Those are manual | 15:49 |
| juliank | and don't impact migration | 15:49 |
| -queuebot:#ubuntu-release- New: accepted libcupsfilters [amd64] (noble-proposed) [2.0.0-0ubuntu6] | 15:53 | |
| -queuebot:#ubuntu-release- New: accepted libcupsfilters [armhf] (noble-proposed) [2.0.0-0ubuntu6] | 15:53 | |
| -queuebot:#ubuntu-release- New: accepted libcupsfilters [s390x] (noble-proposed) [2.0.0-0ubuntu6] | 15:53 | |
| -queuebot:#ubuntu-release- New: accepted libcupsfilters [arm64] (noble-proposed) [2.0.0-0ubuntu6] | 15:53 | |
| -queuebot:#ubuntu-release- New: accepted libcupsfilters [ppc64el] (noble-proposed) [2.0.0-0ubuntu6] | 15:53 | |
| juliank | Tool has one tiny issue: If there is an NBS binary in proposed that is broken it triggers another rebuild | 16:00 |
| juliank | It mostly gets caught because rebuild-for checks if the t64 library is named in the changelog already | 16:01 |
| juliank | cpdb-backend-cups | 2.0~b5-0ubuntu3 | noble-proposed | armhf | 16:03 |
| juliank | cpdb-backend-cups | 2.0~b5-0ubuntu4 | noble-proposed | source, amd64, arm64, ppc64el, riscv64, s390x | 16:03 |
| juliank | like this it almost triggered twice | 16:04 |
| juliank | This is fixed now fwiw | 16:34 |
| juliank | Sadly I can't easily pass the commands to xargs or so so it's uploading sequentially | 16:34 |
| juliank | ah GNU parallel | 16:36 |
| juliank | Had to add locking around debuild because scdaemon or the smartcard craps out when you sign stuff in parallel | 16:38 |
| -queuebot:#ubuntu-release- New binary: lomiri-ui-toolkit [armhf] (noble-proposed/universe) [1.3.5012+dfsg-5ubuntu1] (no packageset) | 16:40 | |
| -queuebot:#ubuntu-release- New: accepted lomiri-ui-toolkit [armhf] (noble-proposed) [1.3.5012+dfsg-5ubuntu1] | 16:41 | |
| -queuebot:#ubuntu-release- New binary: kf5-messagelib [amd64] (noble-proposed/universe) [4:23.08.5-0ubuntu3] (kubuntu) | 16:45 | |
| doko | juliank: hmm, did you only re-upload those packages that were missing or bad on armhf? | 16:46 |
| juliank | doko: All of the packages uploaded are missing a dependency transition on armhf; and did not have an outstanding armhf build in proposed (except a couple at the start, they had older binaries published in proposed like deepin-terminal | 16:50 |
| juliank | doko: Also for any libfoo1 dependency this found in the latest version; it also checked that libfoo1t64 was built on armhf | 16:51 |
| juliank | doko: Some stuff like libghc-hopenpgp-dev depends libnettle8 is unfortunate | 16:53 |
| juliank | But needs fixing either way to migrate | 16:54 |
| doko | I only looked at the ocaml stack so far. haskell still needs to be done | 16:54 |
| juliank | There's only 5 haskell ones that my t64 script found | 16:55 |
| juliank | but it doesn't know all renames | 16:55 |
| juliank | Only straightforward libname0 to libname0t64 | 16:55 |
| juliank | :D | 16:55 |
| juliank | So to make it clear: anything that is waiting on a build or failed to build in proposed has not been uploaded again | 16:56 |
| juliank | No pointless uploads in there hopefully :) | 16:57 |
| juliank | This also applies to if you drop the old binary in release pocket, even | 16:57 |
| juliank | We always only check the latest version of each binary package | 16:57 |
| juliank | This may be in proposed, likely is a lot of times | 16:58 |
| -queuebot:#ubuntu-release- Unapproved: python-rtslib-fb (jammy-proposed/main) [2.1.74-0ubuntu4 => 2.1.74-0ubuntu4.1] (no packageset) | 16:58 | |
| juliank | Basically like I said I built a simple ben that detects libfoo0 to libfoo0t64 transitions :) | 16:58 |
| juliank | it only knows about armhf | 16:58 |
| juliank | So if your package has an old dependency but only is on amd64, it doesn't get rebuild (but that's fine as there are Provides there) | 16:59 |
| -queuebot:#ubuntu-release- New binary: kf5-messagelib [armhf] (noble-proposed/universe) [4:23.08.5-0ubuntu3] (kubuntu) | 17:04 | |
| -queuebot:#ubuntu-release- New: accepted kf5-messagelib [amd64] (noble-proposed) [4:23.08.5-0ubuntu3] | 17:05 | |
| -queuebot:#ubuntu-release- New: accepted kf5-messagelib [armhf] (noble-proposed) [4:23.08.5-0ubuntu3] | 17:05 | |
| juliank | All have been uploaded | 17:06 |
| rbasak | Thank you! | 17:12 |
| juliank | A second batch has been identified after receiving the full list from vorlon, and I have uploaded them as well now | 17:24 |
| juliank | I hope there is someone doing +1 later today who will go through all my build failures :D | 17:24 |
| juliank | I think it's about 20 so far | 17:24 |
| rbasak | How to tell apart the build failures that are due to misordering, and everything else? | 17:25 |
| rbasak | I'm EOD very shortly though sorry. | 17:25 |
| juliank | I don't think there's suppsoed to be any misordering possible | 17:27 |
| juliank | In the sense that we renamed nothing | 17:27 |
| juliank | much will be down to cleaning up some implicit declarations or something | 17:27 |
| rbasak | I'm thinking of a build failure because of a missing t64 binary that will get resolved from the same batch of rebuilds, so a second rebuild might work. | 17:28 |
| rbasak | But this would be a few layers deep. | 17:28 |
| rbasak | s/would/could/ | 17:28 |
| juliank | There are no missing t64 binaries because the rebuilds don't rename any libraries to t64 as they are just rebuidls | 17:28 |
| juliank | The t64 renames already happened | 17:29 |
| juliank | Oh | 17:29 |
| juliank | But if you have bar depends libfoo1t64 and baz deends libfoo1 in your build-depends and then you rebuild baz | 17:29 |
| juliank | I see | 17:29 |
| juliank | So there may be dependency issues at build time like this | 17:30 |
| juliank | But we'll see them in my report too | 17:30 |
| juliank | They'd appear as new "Other conflicts" in https://magenta.jak-linux.org/ubuntu-archive/distcheck/noble.armhf/proposed.txt | 17:30 |
| juliank | As always, all reports are hourly updated :) | 17:31 |
| vorlon | I am currently working on getting glib2.0 migratable (in principle) | 18:20 |
| vorlon | after fixing multipath-tools to not have a hard-coded dep on libaio1 (instead of libaio1t64 :| ), which will let us get a view on https://ubuntu-archive-team.ubuntu.com/proposed-migration/update_output_notest.txt packages that will be uninstallable on armhf even if we ignore tests, I am currently going through the packages listed on | 18:21 |
| vorlon | https://ubuntu-archive-team.ubuntu.com/proposed-migration/update_excuses.html#glib2.0 as having test regressions | 18:21 |
| vorlon | after trivially confirming that the test was run correctly (with --all-proposed, against a version of the package built against the current glib2.0), I will be opening blocking bugs against the packages in -proposed, and removing the armhf binaries from the release pocket | 18:22 |
| vorlon | there's room for others to help if someone wants to start at the other end of the alphabet | 18:22 |
| vorlon | unfortunately I've gotten to the second one and it looks like a problem with a mesa misbuild | 18:23 |
| vorlon | (auto-multiple-choice) | 18:23 |
| vorlon | deliberate behavior change, zink is only built on LLVM_ARCHS in mesa and armhf is not listed as an LLVM_ARCH | 18:26 |
| vorlon | tjaalton: ^^ why is armel listed as an LLVM_ARCH but armhf not? | 18:26 |
| vorlon | or is this an undocumented bootstrap artifact | 18:26 |
| vorlon | yes it is | 18:27 |
| vorlon | doko: ^ mesa bootstrap didn't get cleaned up fully, fyi; fixing now | 18:27 |
| juliank | vorlon: There were a couple of rebuilds for libglib2.0t64 missing that were hopefully executed by https://magenta.jak-linux.org/ubuntu-archive/distcheck/noble.armhf/global-ben.rebuild-for.txt - assuming they are not hardcoded libglib2.0 dependencies (in which case no-change rebuild will be pointless :D) | 18:32 |
| juliank | just fyi | 18:33 |
| juliank | The worst offenders were libfuse2 and libcfitsio10 afacit | 18:34 |
| vorlon | juliank: thanks | 18:34 |
| juliank | and libssl3 :D | 18:34 |
| vorlon | uh | 18:35 |
| vorlon | you mean rebuilds for libssl3, right, not libssl3 depending on glib? | 18:35 |
| juliank | right | 18:35 |
| vorlon | ok | 18:35 |
| vorlon | tjaalton: unping, it was a bootstrap thing, sorted now | 18:37 |
| vorlon | and some of these failed tests against glib2.0 are 10 days old, better retry them with *current* all-proposed | 18:37 |
| juliank | I might teach global-ben next week to handle any libfoo[0-9]* -> libfoo[0-9]* (these are glob) patterns; like ben does autodetect library transitions I suppose, just detect non-numerical prefix | 18:37 |
| juliank | This will unblock libfoo1 to libfoo2 and so on from getting rebuild-for commands scheduled :) | 18:38 |
| vorlon | 39s " failed with stderr "sed: can't read /etc/apt/sources.list: No such file or directory | 18:38 |
| vorlon | oops | 18:38 |
| juliank | heh | 18:38 |
| vorlon | looks like that was an infra issue though | 18:38 |
| juliank | I think QA team rebuilt armhf images with deb822 sources, maybe | 18:39 |
| juliank | Skia: ^ | 18:39 |
| vorlon | eh it was a one-off several days ago, not worth his time | 18:40 |
| vorlon | I'm very happy to see most of these glib2.0 regressions (after the first 2) are badpkg | 18:40 |
| juliank | vorlon: Well from the deb822 branch merge request, I know Skia tested parts of the deb822 branch to build lxd armhf images in the infra, but not sure if it was prod or staging. | 18:41 |
| vorlon | bdmurray: running this now: retry-autopkgtest-regressions --all-proposed --log-regex 'FAIL badpkg' | grep armhf | 18:41 |
| juliank | Maybe wait until my 500 something uploads are done | 18:42 |
| vorlon | oh I thought they were done already | 18:42 |
| juliank | done building and installed | 18:42 |
| juliank | I uploaded them | 18:42 |
| vorlon | still, this will help clear some of the noise | 18:42 |
| juliank | armhf queues are empty almost :) | 18:42 |
| juliank | amd64 still has 9000 tests | 18:43 |
| juliank | I should write a script that parses queued.json and then produces a report with tests that can be removed right | 18:44 |
| tjaalton | vorlon: ack. I've had a new point-release waiting for the archive to be sorted since last week, but I'll sit on it still | 18:44 |
| vorlon | bdmurray: ^ amd64 tests look like they're going to be a blocker for any progress today unless we ignore them, are the runners currently healthy? | 18:44 |
| vorlon | tjaalton: ack, please wait a little longer - hopefully we'll get things unclogged by Monday | 18:45 |
| vorlon | 351s ERROR: ld.so: object '/usr/lib/x86_64-linux-gnu/click/libclickpreload.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored. | 18:47 |
| vorlon | ... in an armhf test log | 18:47 |
| vorlon | (gdb) run | 18:59 |
| vorlon | Starting program: /usr/sbin/cups-browsed | 18:59 |
| vorlon | During startup program terminated with signal SIGSEGV, Segmentation fault. | 18:59 |
| vorlon | blink | 18:59 |
| vorlon | # LD_DEBUG=all cups-browsed | 19:01 |
| vorlon | Segmentation fault | 19:01 |
| vorlon | *blink* | 19:01 |
| vorlon | juliank: looks like you may have missed some packages, libppd2 is still linked against libcupsfilters2 not libcupsfilters2t64? | 19:05 |
| vorlon | wait hmm | 19:05 |
| vorlon | heh that's not in our list because the source package is different between Debian and Ubuntu | 19:07 |
| Eickmeyer | Is it too late to make a joke about a stack of "cups" falling over? | 19:12 |
| Skia | juliank: vorlon: about those deb822 patches: we have them in our branch used in production, and indeed, we rebuilt many images since the beginning of last week. Current status for armhf is that we have about 15 workers in bos02 that **may** not be deb822, depending on whether or not bdmurray rebuilt the images after rolling back to 5.20 at the beginning of the week, but what's certain is that the | 19:21 |
| Skia | other 14 workers in bos03 that I deployed this week are completely deb822, built on our current 5.32+prod branch (which is here: https://salsa.debian.org/ubuntu-ci-team/autopkgtest/-/tree/ubuntu/cb2df3e+deb822+prod ) | 19:21 |
| vorlon | yes, I think those failures were transient (and were from several days ago) | 19:22 |
| Skia | that `sed` on `sources.list` error was indeed transient, was part of the fixes that we did Monday or Tuesday | 19:22 |
| juliank | ack | 19:22 |
| juliank | I wonder if *tests* themselves will fail requiring sources.list, onyl time will tell | 19:23 |
| juliank | Well it seems over 400 of my uploads have built succesfully, the rebuild-for list is down to 136 now | 19:24 |
| vorlon | there are also an unpleasant number of amd64 autopkgtest regressions against glib2.0 | 19:27 |
| vorlon | retrying these with --all-proposed as well | 19:27 |
| vorlon | juliank: have we done all perlapi rebuilds :/ | 19:29 |
| juliank | hmm | 19:30 |
| juliank | I don't have Provides tracking in global-ben | 19:30 |
| vorlon | yawp | 19:30 |
| juliank | But let me add a tracker of sorts | 19:30 |
| vorlon | I'll get on them | 19:30 |
| vorlon | hah perlapi-5.38.2t64 shows up in my chroot because I have i386 enabled; did I still not get the logic right on that? | 19:31 |
| vorlon | because i386 is obviously not t64 | 19:31 |
| juliank | vorlon: bad is perlapi-5.38.2? | 19:32 |
| vorlon | juliank: only on armhf | 19:32 |
| juliank | I only report on armhf | 19:32 |
| juliank | :D | 19:32 |
| vorlon | well there you go | 19:32 |
| vorlon | juliank: my script says only 5 packages to rebuild, which seems suspicious | 19:36 |
| vorlon | ah but frozen-bubble is one of them and that's the package we hit in tests | 19:36 |
| vorlon | hurray | 19:36 |
| juliank | vorlon: looking, I don't see any | 19:37 |
| vorlon | juliank: even frozen-bubble? | 19:38 |
| juliank | vorlon: See it ignores frozen-bubble because it has a newer version in proposed that is failing to build | 19:38 |
| vorlon | hmm | 19:38 |
| juliank | I think global-ben.txt should not ignore those, but global-ben.rebuild-for.txt should | 19:39 |
| vorlon | ah. my hack to make my rebuild script look at armhf instead of amd64 must have missed something | 19:39 |
| vorlon | the list I had was: | 19:40 |
| vorlon | Rebuilding cyrus-imapd | 19:40 |
| vorlon | Rebuilding frozen-bubble | 19:40 |
| vorlon | Rebuilding libgetdata | 19:40 |
| vorlon | Rebuilding liblocale-gettext-perl | 19:40 |
| vorlon | Rebuilding liboping | 19:40 |
| vorlon | are those all ftbfs? | 19:40 |
| vorlon | otoh libsdl-perl is also definitely ftbfs and is what actually blocks frozen-bubble | 19:41 |
| juliank | vorlon: Yeah you can grep '(missing|old) build for <name>' in https://magenta.jak-linux.org/ubuntu-archive/distcheck/noble.armhf/global-ben.log | 19:42 |
| juliank | I see now perlapi-5.38.2 Reverse-Depends: cyrus-imapd libsdl-perl frozen-bubble redland-bindings libgetdata | 19:43 |
| juliank | But I believe they are all ftbfs | 19:43 |
| juliank | checking liblocale-gettext-perl from your list, it already has a new one | 19:44 |
| vorlon | hmm if I remove frozen-bubble and libsdl-perl on armhf, and retry on !armhf with current dpkg, it should migrate and be happy | 19:44 |
| vorlon | juliank: ok. confused how I got these particular results then; I just did a chdist apt update immediately before running it | 19:46 |
| juliank | vorlon: So https://magenta.jak-linux.org/ubuntu-archive/distcheck/noble.armhf/global-ben.txt now shows FTBFS as well, but in () | 19:47 |
| vorlon | takes a long time for retry-autopkgtest-regressions to grep all the logs | 19:47 |
| vorlon | I deliberately didn't filter by package, so | 19:47 |
| vorlon | no armhf tests in the queue; something went very well or very badly | 19:49 |
| juliank | # packages listed in () are failing to build in proposed | 19:50 |
| juliank | android-platform-frameworks-native-headers Reverse-Depends: android-platform-frameworks-base | 19:50 |
| juliank | jupyter-nbextension-jupyter-js-widgets Reverse-Depends: (ipywidgets) (sagemath) | 19:50 |
| juliank | libabsl20220623 (rebuild-for libabsl20220623t64) Reverse-Depends: (llvm-toolchain-17) (libreoffice) (llvm-toolchain-snapshot) | 19:50 |
| juliank | is this readable | 19:50 |
| juliank | more or less | 19:50 |
| juliank | Lots of FTBFS | 19:50 |
| juliank | I should probably use [] for them | 19:50 |
| juliank | I use () for the hint of what the library got renamed to | 19:51 |
| juliank | done, and also ordered them at teh end | 19:53 |
| juliank | e.g. libxerces-c3.2 (rebuild-for libxerces-c3.2t64) Reverse-Depends: cegui-mk2 xalan [deepin-log-viewer] [passwordsafe] [toppic] [vecgeom] | 19:53 |
| juliank | You can reason I uploaded cegui-mk2 and xalan but not the others since they could be retried | 19:54 |
| juliank | I can build a more global ben that checks across all architectures, because obviously amd64 or so may still refer to old names (but that is fine, due to provides, so meh) | 19:56 |
| juliank | vorlon: I can also print you a simple list of all FTBFS I see | 19:56 |
| juliank | or rather ftbfs + missing | 19:57 |
| vorlon | juliank: well I can already use ubuntu-build to retry all ftbfs on armhf | 19:57 |
| juliank | I can't distinguish them :D | 19:57 |
| juliank | vorlon: Ah well do that maybe | 19:57 |
| juliank | But it's good global-ben.txt now has missing builds shown so you get a broader understanding of what a transition is depending on | 19:58 |
| juliank | I called it global-ben because it actually shows you all transitions in one page | 19:58 |
| juliank | :D | 19:58 |
| juliank | New report coming soon | 19:59 |
| juliank | It's almost :00 | 19:59 |
| juliank | vorlon: Do you know of any other virtual transition? | 20:00 |
| juliank | Why did the list of rebuilds grow, lol | 20:01 |
| juliank | 136 -> 149 | 20:01 |
| vorlon | juliank: uh there are a couple of other virtual transitions; I just have to find them | 20:01 |
| juliank | +rebuild-for "libssl3t64" condor | 20:02 |
| juliank | hmm | 20:02 |
| juliank | I did that | 20:02 |
| juliank | ugh <apt_pkg.Version object: Pkg:'condor' Ver:'23.4.0+dfsg-1build3' Section:'universe/science' Arch:'armhf' Size:8525492 ISize:21937152 Hash:706453376 ID:72014 Priority:4> Depends libssl3 | 20:04 |
| juliank | hmm | 20:04 |
| vorlon | booth tests not installable because of something in the curl stack still | 20:04 |
| juliank | Ah hardcoded depends | 20:04 |
| juliank | global-ben.log:# Rebuilding due to condor 23.4.0+dfsg-1build3 depending on {'libssl3t64'} | 20:06 |
| juliank | silly | 20:06 |
| vorlon | ahhh don't look at that debian/control file | 20:06 |
| juliank | So it was gone from previous report because condor was still building and now reappeared because it misbuilt :) | 20:06 |
| juliank | I like that behavior | 20:06 |
| juliank | I just upload another build4 now, saying "Some-change rebuild" | 20:07 |
| vorlon | how is that a build rather than ubuntu? | 20:08 |
| juliank | It should have been a maysync really | 20:08 |
| juliank | Oh well | 20:08 |
| vorlon | why? is this fixed in Debian? | 20:08 |
| juliank | You can't upload to Debian without fixing it | 20:08 |
| vorlon | and did you fix all the garbage in debian/control :P | 20:09 |
| juliank | No | 20:09 |
| vorlon | sure you can, it'll just ftbfs everywhere | 20:09 |
| juliank | let me reupload :) | 20:09 |
| vorlon | and ruby-ethon no-change rebuild didn't help because it's arch: all :P | 20:09 |
| juliank | heh yeah | 20:10 |
| juliank | I mean you can't know, they could do magic | 20:10 |
| juliank | If I were building a ctypes module package, I'd look at my libfoo-dev and then determine libfoo<num> from there | 20:10 |
| * vorlon nods | 20:10 | |
| vorlon | anyway, ruby-ethon -> that's the booth autopkgtest fixed | 20:11 |
| vorlon | bdmurray: https://autopkgtest.ubuntu.com/packages/c/castle-game-engine/noble/amd64 now shows 5 different tests queued with glib2.0 somewhere in the triggers, and 2 of them appear to be straight duplicates; maybe some queue pruning is needed here again | 20:12 |
| juliank | I can just run rebuild-for script on a loop based on global-ben output | 20:13 |
| juliank | Apparently some more transitions are still landing | 20:14 |
| juliank | I think I'm rebuilding kde now | 20:15 |
| vorlon | again? | 20:15 |
| vorlon | that shouldn't be the case | 20:16 |
| vorlon | i.e. please abort | 20:16 |
| vorlon | KDE specifically only changed the package name for the base packages | 20:16 |
| juliank | hmm | 20:17 |
| juliank | vorlon: it is correct though | 20:18 |
| vorlon | juliank: example? | 20:19 |
| juliank | vorlon: libkpim5messagecomposer5 got bumped to libkpim5messagecomposer5t64 | 20:19 |
| juliank | hence Rebuilding akonadi-calendar due to libkpim5akonadicalendar5 4:23.08.5-0ubuntu2 depending on {'libkpim5messagecomposer5t64', 'libkpim5messagecore5t64'} | 20:19 |
| vorlon | hmm | 20:19 |
| juliank | (ignore it says t64 in the right side) | 20:19 |
| juliank | (it shows the target name) | 20:19 |
| vorlon | well that shouldn't be all of kde, still | 20:19 |
| juliank | vorlon: yeah still kdepim only | 20:20 |
| vorlon | juliank: fwiw I'm rebuilding condor here to see what madness lies within | 20:20 |
| vorlon | it looks like libssl is the only hard-coded dep that actually gets picked up via shlibs | 20:20 |
| juliank | Oh I didn#t know it did | 20:22 |
| juliank | Well I think I'll leave the US folks to it, and run another round of rebuild-for tomorrow if some new transitions appeared | 20:24 |
| -queuebot:#ubuntu-release- Unapproved: obconf-qt (jammy-proposed/universe) [0.16.0-1ubuntu1 => 0.16.0-1ubuntu2] (no packageset) | 20:43 | |
| arraybolt3 | ^ fix for https://bugs.launchpad.net/ubuntu/+source/obconf-qt/+bug/1916897 | 20:43 |
| -ubottu:#ubuntu-release- Launchpad bug 1916897 in obconf-qt (Ubuntu) "Center windows option has no effect" [Medium, In Progress] | 20:44 | |
| arraybolt3 | ubuntu-sru: ^ | 20:44 |
| vorlon | I'm the SRU vanguard today and my shift is forfeit in favor of noble time_t migration | 20:44 |
| vorlon | so unlikely to be looked at until Monday | 20:44 |
| arraybolt3 | how unreasonable! /s | 20:44 |
| arraybolt3 | no problem, and thanks for fighting with the time_t behemoth | 20:45 |
| vorlon | juliank: yeah condor does all kinds of dlopen horrors for kerberos, sigh | 20:46 |
| juliank | heh | 20:46 |
| juliank | -rw-rw-r-- 1 jak jak 442 Mär 22 21:48 lomiri-filemanager-app_1.0.4+dfsg-1ubuntu2_source.ubuntu.upload | 20:51 |
| juliank | -rw-rw-r-- 1 jak jak 398 Mär 22 21:49 lomiri-ui-extras_0.6.3-1ubuntu1_source.ubuntu.upload | 20:51 |
| juliank | these also have such depends | 20:51 |
| juliank | rebuild-for "libsmbclient0" lomiri-filemanager-app | 20:52 |
| juliank | rebuild-for "libqt5printsupport5t64" lomiri-ui-extras | 20:52 |
| juliank | Well yeah had to mangle it | 20:52 |
| juliank | Should have dropped the first one at least really | 20:53 |
| * juliank is not reading the right report | 20:53 | |
| juliank | second one too | 20:54 |
| juliank | they are all added by shlibs why are they there manually | 20:54 |
| juliank | vorlon: I now added https://magenta.jak-linux.org/ubuntu-archive/distcheck/noble.armhf/proposed-binaries.only-regressions.txt which shows only proposed binary installability issues for binaries that are in the release pocket which I guess are all blockers | 21:01 |
| juliank | The normal one also showed Architecture: all ones that simply never were installable | 21:02 |
| juliank | We see a whole bunch of trivial conflicts | 21:02 |
| juliank | i.e. packages depending on two conflicting packages directly | 21:02 |
| juliank | i.e. one is hardcoded and the other comes from shlibs | 21:03 |
| juliank | I feel like it doesn't always show the shortest chain | 21:04 |
| juliank | e.g. 0install has Depends: ..., libgtk-3-0, ..., libgtk-3-0t64 | 21:05 |
| juliank | but we see libglib2.0-0t64:armhf (>= 2.36.0) vs libgtk-3-0:armhf -> libglib2.0-0:armhf (>= 2.77.3) | 21:05 |
| juliank | bad dose-distcheck | 21:05 |
| doko | lomiri is on the way building up it's dependencies | 21:10 |
| juliank | vorlon: I feel like # Rebuilding ui-utilcpp due to libui-utilcpp9t64 1.10.3-1.1build3 depending on {'libui-utilcpp9v5'} | 21:19 |
| juliank | vorlon: this is broken | 21:19 |
| juliank | Both are or were built by ui-utilcpp | 21:20 |
| juliank | libui-utilcpp9t64 is the new name for libui-utilcpp9v5 | 21:20 |
| juliank | ah dh_makeshlibs -V 'libui-utilcpp9v5 (>= 1.8.3)' | 21:20 |
| juliank | Bug in the NMU | 21:20 |
| juliank | debian bug #1063009 | 21:20 |
| -ubottu:#ubuntu-release- Debian bug 1063009 in src:ui-utilcpp "ui-utilcpp: NMU diff for 64-bit time_t transition" [Important, Fixed] https://bugs.debian.org/1063009 | 21:20 | |
| juliank | I guess need to fix the dh_makeshlibs and then go sync it | 21:21 |
| juliank | NMUed that and did a syncpackage --no-lp | 21:27 |
| juliank | waiting until tomorrow is annoying :) | 21:29 |
| vorlon | annoying, and infeasible wrt timing | 21:32 |
| vorlon | Eickmeyer: you might want to fix plasma-distro-release-notifier to not build-depend on libqt5widgets5 LP: #2058780 | 21:47 |
| -ubottu:#ubuntu-release- Launchpad bug 2058780 in plasma-distro-release-notifier (Ubuntu) "proposed-migration for plasma-distro-release-notifier 20220915-0ubuntu3" [Undecided, New] https://launchpad.net/bugs/2058780 | 21:47 | |
| Eickmeyer | vorlon: It was kinda funny because, at least at the time (~2 years ago) it FTBFS if it didn't have that, but Rik_Mills did a PPA rebuild on it recently that shows it's fixed now. It may have been a bug in qtbase5-dev at the time, but nto worth investigating. | 21:49 |
| Eickmeyer | Fixing momentarily. | 21:49 |
| Eickmeyer | I didn't want to fix something superflously without your go-ahead. | 21:49 |
| vorlon | well, it's "superfluous" now in that I've removed the armhf binary from the release pocket to unblock this; but as it's seeded maybe you care to fix it | 21:50 |
| Eickmeyer | Sure. | 21:51 |
| juliank | vorlon: So taking this public, there is OUTOFSYNC_ARCHES in britney which is supposed to allow things to migrate even if missing binaries - it is supposed to remove old binaries missing in new one, but since we don't have removals turned on in britney, it probably just ends up with NBS | 21:51 |
| vorlon | I'd rather not deal with all of this via NBS if I can avoid it | 21:52 |
| juliank | heh | 21:52 |
| juliank | "remove first and then migrate" vs "migrate and then remove" | 21:53 |
| juliank | :D | 21:53 |
| vorlon | well, the remove first and then migrate approach involves a little more per-package care at the moment, catching things like mesa not having been put back upright | 21:54 |
| juliank | ack | 21:54 |
| vorlon | and filing bugs on the packages that are broken | 21:54 |
| vorlon | but if we run out of time, yeah | 21:54 |
| juliank | some people think we have run out of time | 21:55 |
| juliank | :D | 21:55 |
| vorlon | I've been given a specific deadline by Mark ;-P | 21:55 |
| vorlon | (Wednesday) | 21:55 |
| juliank | ah | 21:55 |
| vorlon | and also, although that's the deadline Mark gave, I'm prepared to actually make the call on Monday | 21:56 |
| juliank | I wish we could have just removed all of armhf and then have britney migrate installable things back in | 21:57 |
| juliank | :D | 21:57 |
| vorlon | heh | 21:57 |
| juliank | s/remove/demote to proposed/ | 21:57 |
| Eickmeyer | Ok, now cdimage is having a sync fit. in https://cdimage.ubuntu.com/ubuntustudio/dvd/, 20240322 *was* popping in and out of existence, so I did a rebuild (had a new meta). Now 20240322.1 is popping in and out of existence. *facepalm* | 21:59 |
| vorlon | Eickmeyer: dns round robin to multiple web frontends that are not all in sync. Doing another rebuild doesn't help, and could possibly hurt (if one of the frontends is somehow out of space) | 22:00 |
| Eickmeyer | Well, 22 is steady, but 22.1 is phasing in/out. | 22:01 |
| vorlon | then it'll be sync delay | 22:01 |
| juliank | vorlon: A bunch of autopkgtests failed due to ubutnu-advantage-tools prerm failure like https://autopkgtest.ubuntu.com/results/autopkgtest-noble/noble/armhf/a/adequate/20240314_223741_08ffe@/log.gz | 22:01 |
| juliank | vorlon: The thing is we did not manage to retry them with searching for _Z11TimeRFC1123B5cxx11lb as the regex | 22:01 |
| vorlon | hmm yes we don't need an ubuntustudio bionic daily from 2019 on here | 22:01 |
| Eickmeyer | Ha! True. | 22:01 |
| juliank | So I retried the oens triggered by python-apt but am at a loss to find the others | 22:02 |
| vorlon | juliank: have all autopkgtests been retried at least once since then though? | 22:02 |
| juliank | all? no | 22:03 |
| juliank | I don't think we ever retried all autopkgtests | 22:03 |
| juliank | I last retried python-apt on 2024-03-14 22:37:41 UTC | 22:04 |
| juliank | and it has been failing there | 22:04 |
| juliank | and not been retried | 22:04 |
| vorlon | ok | 22:04 |
| juliank | So yeah maybe retry *all* armhf autopkgtests | 22:04 |
| vorlon | grr libmozjs still depends on wrong libreadline | 22:04 |
| juliank | Well anything that has not been tried will all-proposed since 2024-03-19 07:32:13 UTC | 22:05 |
| vorlon | jbicha: are you aware of mozj102 ftbfs on all archs? | 22:05 |
| vorlon | because of distutils | 22:05 |
| juliank | Ugh well the autopkgtest queues are full again | 22:11 |
| juliank | Or it feels like it | 22:11 |
| juliank | ok more feel than reality | 22:12 |
| vorlon | jbicha: https://launchpad.net/ubuntu/+source/mozjs102/102.15.1-3ubuntu1 (this blocks cjs and I forgot if there was something else) | 22:21 |
| vorlon | still fails; iterating (was building in parallel) | 22:26 |
| juliank | I meanwhile fixed python-apt | 22:29 |
| juliank | I just had to remove the python3-distuils b-d there :D | 22:29 |
| vorlon | jbicha: ok well now I'm getting a build failure because it can't write to /tmp/mozjs102-102.15.1/debian/build/_virtualenvs/build/lib/python3.12/site-packages/mach.pth because site-packages doesn't exist only dist-packages sooo | 22:38 |
| vorlon | *maybe* I can just patch that? | 22:39 |
| vorlon | probably easiest to just os.mkdir | 22:40 |
| juliank | ok it's almost midnight. Since the queues are quite full I looked again at whether we could merge triggers and what that would do, but it only went fro m 1700 to 1697 tests so meh | 22:42 |
| juliank | heh I have migrating no-change t64 rebuilds | 22:47 |
| juliank | I looked at one, and the dependency just disappeared | 22:48 |
| juliank | well I don't care | 22:48 |
| juliank | I guess some dependency fixed their shlibs or symbols or something | 22:48 |
| juliank | https://launchpad.net/ubuntu/+source/compartment/1.1.0-5.1build1 | 22:51 |
| juliank | I guess I had a bug in the script at that point | 22:51 |
| juliank | Yeah if you have no dependencies in the package, the script, earlier today took the depends from teh previous package | 22:51 |
| juliank | the initialization of the variable was indented wrong :D | 22:51 |
| juliank | But libcfitsio10t64 rebuilds end up without libcfitsio10t64 depends despite having had libcfitsio10 | 22:52 |
| juliank | :D | 22:52 |
| vorlon | jbicha: ok well this is a mess. https://paste.ubuntu.com/p/ydmqPPq8tm/ I have no idea what this code is actually doing, I think it's going to need an upstream fix | 22:58 |
| vorlon | and it looks like I need to rip out cinnamon on armhf to accomodate | 22:58 |
| juliank | ugh global-ben is confused by NBS in release pocket and issues rebuilds for proposed, but rebuild-for is catching them | 22:59 |
| juliank | # Rebuilding poco due to libpococrypto80 1.11.0-4 depending on {'libssl3'} | 23:00 |
| juliank | I guess I should improve that | 23:00 |
| vorlon | quite the stack of cinnamon things depending on cjs | 23:00 |
| juliank | well | 23:00 |
| vorlon | ah 102 is the old one, no wonder | 23:00 |
| juliank | cjs is their javascript engine, like gjs is for gbome? | 23:01 |
| juliank | I'd love if we could just remove all desktop environments on armhf | 23:01 |
| juliank | But I haven't figured out how to do so safey | 23:01 |
| juliank | or well reasonably safely | 23:02 |
| juliank | but that is a prime candidate for breaking in release pocket | 23:02 |
| juliank | just break cinnamon, gnome, kde isntallation in release, who cares | 23:02 |
| vorlon | ItzSwirlz: ^ so cinnamon depends on the old mozjs via cjs, and old mozjs needs a bunch of work to make it compatible with python3.12. I'm removing armhf packages so that this doesn't block the beta, but this is something you'll need to take care of for release | 23:03 |
| juliank | or ugh drop ubuntu cinnamon armhf seed I suppose | 23:03 |
| juliank | I should finish my "I want to remove X from release, which reverse depends should be removed too?" | 23:04 |
| juliank | then you go remove cjs/armhf and it goes like remove all of cinammon | 23:05 |
| juliank | and users are happy | 23:05 |
| juliank | I guess it's past midnight and I should sleep | 23:06 |
| juliank | good -hunting- killing armhf bugs! | 23:06 |
| vorlon | well, multipath-tools wasn't enough to sort glib2.0, blech | 23:08 |
| vorlon | ah qemu has the wrong libaio on some archs? | 23:12 |
| vorlon | and libaio is missing the Provides: | 23:12 |
| vorlon | oh this was a revert wasn't it | 23:12 |
| vorlon | ah no not exactly | 23:13 |
| vorlon | weird if britney picks up on it when the packages are also missing conflicts | 23:14 |
| ricotz | vorlon, hi, regarding python-distutils, this affects libreoffice as well, I am doing a PPA build for testing | 23:19 |
| vorlon | ricotz: cheers | 23:19 |
| vorlon | ah ok no, my chdist was showing me the wrong version of qemu because pins | 23:21 |
| vorlon | so the problem isn't that qemu isn't rebuilt, but that it's not being considered for migration | 23:21 |
| vorlon | implicit dependencies on python3.12/python3-defaults | 23:25 |
| vorlon | right, killing that britney policy right now and may it never be resurrected | 23:25 |
| jbicha | yeah, mozjs102 should be fixed eventually (or cjs switched to mozjs115) but dropping it on armhf avoid the need to rename now | 23:44 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!