=== chris14_ is now known as chris14
[06:30] -queuebot:#ubuntu-release- New binary: nvidia-cuda-toolkit [amd64] (lunar-proposed/multiverse) [11.8.0-2] (no packageset)
[06:36] -queuebot:#ubuntu-release- New binary: nvidia-cuda-toolkit [arm64] (lunar-proposed/multiverse) [11.8.0-2] (no packageset)
[07:20] <LocutusOfBorg> vorlon, did the removal fail somewhere?
[07:20] <LocutusOfBorg> missing build on armhf: scilab-full-bin, scilab-include, scilab-minimal-bin (from 6.1.1+dfsg2-4)
[07:20] <LocutusOfBorg> oh... only lunar-proposed was NBS cleaned up
[07:34] -queuebot:#ubuntu-release- New binary: nvidia-cuda-toolkit [ppc64el] (lunar-proposed/multiverse) [11.8.0-2] (no packageset)
[07:36] -queuebot:#ubuntu-release- New sync: python-numpy-groupies (lunar-proposed/primary) [0.9.20-1]
[09:00] <LocutusOfBorg> jbicha, I'm merging webkit2gtk from expeirmental
[09:00] <LocutusOfBorg> is it ok? there is a tarball mismatch I can't upload the riscv64 fix
[09:41] <ricotz> hello, what is the state of the autopkgtests on arm64/ppc64el/s390x for lunar?
[09:41] <ricotz> seems they are not running at all?
[09:47] <seb128> paride, ^ is there any known issue atm?
[09:51] <paride> ricotz, the queues appear to be empty, and https://autopkgtest.ubuntu.com/running shows some running tests
[09:51] <cjwatson> vorlon: extra-germinate> Hmm, I'm not sure.  Maybe try protocol=2 on the dump side to see if it's something about the newer default protocol in Python 3?
[09:52] <paride> ricotz, what test run are you missing more specificlly?
[09:52] <ricotz> paride, I am looking at https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#libreoffice and e.g. https://autopkgtest.ubuntu.com/packages/libr/libreoffice/lunar/arm64
[09:52] <paride> ricotz, ok let me have a look
[09:53] <ricotz> paride, so afaics the test didn't ran for libreoffice 4:7.5.2~rc1-0ubuntu1
[09:53] <ricotz> paride, thanks
[09:56] <ricotz> paride, I don't see any issues running libreofice's autopkgtests for all archs on all other stable ubuntu series, so just lunar seems to have trouble
[10:01] <paride> ricotz, this can happen if the workers that was executing the tests for a package doesn't add its test results to the database (e.g. it's killed, or crashes, or ...)
[10:01] <paride> ricotz, the job is not given back to the queue, and britney just assumes the test is still running
[10:02] <paride> ricotz, we have to manually re-queue tests in this case
[10:02] <ricotz> paride, could you browsw the recent logs at https://autopkgtest.ubuntu.com/packages/libr/libreoffice/lunar/arm64 ?
[10:02] <ricotz> paride, ok, I can schedule them myself if reasonable
[10:03] <ricotz> paride, so the failure in the logs looks troublesome and infra or kernel related
[10:04] <paride> ricotz, at first glance looks like a timeout while installing dependencies
[10:05] <ricotz> same issue on ppc64el and s390x
[10:05] <paride> see for example: Fetched 834 kB in 9s (97.7 kB/s)
[10:05] <ricotz> I see
[10:05] <ricotz> so network trouble
[10:06] <ricotz> although is it pretty much arch specific :\
[10:07] <paride> ricotz, that's because amd64 tests run on a different datacenter
[10:07] <paride> ricotz, also see https://lists.ubuntu.com/archives/ubuntu-devel/2023-March/042500.html
[10:07] <paride> but apparnetly I've been a bit too optimist in my reply there
[10:11] <ricotz> ok, so the problem is known, just needs to be trackled :)
[11:10] <ginggs> paride: it seems none of the tests triggered by britney make it into the queues
[11:11] <ginggs> manual triggers do work though
[12:30] -queuebot:#ubuntu-release- Unapproved: dotnet7 (kinetic-proposed/universe) [7.0.102-0ubuntu1~22.10.1 => 7.0.103-0ubuntu1~22.10.1] (no packageset)
[12:31] -queuebot:#ubuntu-release- New binary: webkit2gtk [i386] (lunar-proposed/main) [2.39.91-1ubuntu1] (desktop-core, i386-whitelist)
[12:40] -queuebot:#ubuntu-release- Unapproved: dotnet6 (kinetic-proposed/universe) [6.0.113-0ubuntu1~22.10.1 => 6.0.114-0ubuntu1~22.10.1] (no packageset)
[12:47] -queuebot:#ubuntu-release- Unapproved: dotnet6 (jammy-proposed/universe) [6.0.113-0ubuntu1~22.04.1 => 6.0.114-0ubuntu1~22.04.1] (no packageset)
[12:51] -queuebot:#ubuntu-release- New binary: webkit2gtk [s390x] (lunar-proposed/main) [2.39.91-1ubuntu1] (desktop-core, i386-whitelist)
[12:57] <jbicha> LocutusOfBorg: thank you for webkit2gtk
[12:57] <LocutusOfBorg> thank me if riscv64 succeeds :D
[12:57] <LocutusOfBorg> btw, do you plan to forward the delta to Debian, right?
[13:00] <RikMills> sil2100: do you have time to have a look at a quick FFe?
[13:00] <jbicha> LocutusOfBorg: the debian/rules change is already applied in Salsa, & yes, I'll forward riscv if it works 🤞
[13:00] <RikMills> LP: #2011435
[13:00] -ubottu:#ubuntu-release- Launchpad bug 2011435 in plasma-framework (Ubuntu) "[FFe] KDE frameworks 5104.0 into Lunar archive" [Undecided, New] https://launchpad.net/bugs/2011435
[13:00] <sil2100> RikMills: I might!
[13:01] <RikMills> sil2100: see above
[13:01] <LocutusOfBorg> jbicha, thanks, upstream seems to be not keen on merging it, but meh
[13:01] -queuebot:#ubuntu-release- New binary: webkit2gtk [ppc64el] (lunar-proposed/main) [2.39.91-1ubuntu1] (desktop-core, i386-whitelist)
[13:01] <RikMills> sil2100: this is one we have done at this stage for 6 or 7 release cycles
[13:01] <sil2100> RikMills: ok, so this was basically planned but the schedule for the update is what it is, right?
[13:01] <RikMills> sil2100: yep
[13:02] <RikMills> it was only released on saturday
[13:02] <RikMills> publicly
[13:09] <RikMills> sil2100: thanks for the ack! :D
[13:58] <LocutusOfBorg> seb128, vorlon hello, do you think we can have "nss-plugin-pem" on i386? (reason: curl wants it)
[13:58] <LocutusOfBorg> I can probably disable testsuite and live happy, but looks more something we should try to MIR
[14:05] -queuebot:#ubuntu-release- New binary: webkit2gtk [armhf] (lunar-proposed/main) [2.39.91-1ubuntu1] (desktop-core, i386-whitelist)
[15:08] <vorlon> LocutusOfBorg: seeing that we already have libnss3 and libnspr4 built on i386, it doesn't seem too bad to also enable nss-plugin-pem on i386, despite us not wanting to support nss generaly
[15:08] <vorlon> LocutusOfBorg: scilab/armhf> I had the command in my history, so I don't know why it failed.  I reran it and it tells me again it's been removed
[15:17] <vorlon> cjwatson: trying protocol=3 first since it appears current protocol is 4
[15:18] <vorlon> cjwatson: also it turns out that ubuntu-archive-toolbox is unreasonably memory-constrained, so maybe this is a race condition of some kind that will magically go away when we get more memory
[15:20] <vorlon> LocutusOfBorg: as for an MIR, I don't see any reason for libcurl-nss to be in main, it's probably pulled in by the -dev package only.
[15:31] <vorlon> cjwatson: not fixed by either protocol=3 or protocol=2
[15:31] -queuebot:#ubuntu-release- New binary: tzdata [amd64] (lunar-proposed/main) [2022g-7ubuntu2] (core)
[16:11] <vorlon> LocutusOfBorg: https://launchpad.net/ubuntu/+source/nss-pem/1.0.8+1-1/+build/25666841
[16:30] -queuebot:#ubuntu-release- Packageset: Removed libb2 from i386-whitelist in lunar
[16:30] -queuebot:#ubuntu-release- Packageset: Removed libmms from i386-whitelist in lunar
[16:30] -queuebot:#ubuntu-release- Packageset: Removed libofa from i386-whitelist in lunar
[16:30] -queuebot:#ubuntu-release- Packageset: Removed lsb from i386-whitelist in lunar
[16:30] -queuebot:#ubuntu-release- Packageset: Removed python-exceptiongroup from i386-whitelist in lunar
[16:30] -queuebot:#ubuntu-release- Packageset: Removed ruby3.0 from i386-whitelist in lunar
[16:30] -queuebot:#ubuntu-release- Packageset: Added lsb-release-minimal to i386-whitelist in lunar
[16:30] -queuebot:#ubuntu-release- Packageset: Added nss-pem to i386-whitelist in lunar
[16:31] -queuebot:#ubuntu-release- New binary: webkit2gtk [amd64] (lunar-proposed/main) [2.39.91-1ubuntu1] (desktop-core, i386-whitelist)
[16:37] <cjwatson> vorlon: I guess memory-constrainedness is a possibility.  I can't think of many _reasonable_ causes for this
[17:05] <vorlon> cjwatson: it's also possible, I haven't checked, that the subprocess for one of the archs is dying with an error (unrelated to OOM) that I'm not getting output on and thus causing cascading failures after the parent dies
[17:06] <utkarsh2102> hi! I am on +1 this week, let me know if there's anything specific you'd like me to focus on.
[17:41] <ahasenack> utkarsh2102: universe packages :P
[17:41] <ahasenack> but beware test timeouts (at the very end of a test log, look for "kind: install")
[17:42] <ahasenack> those are a result of a slow network to ftpmaster.internal, and I don't think retrying them is worth it until the problem is really solved
[18:19] <utkarsh2102> ahasenack: nice, thank you! what should we do about those then?
[18:19] <utkarsh2102> big_tests?
[18:20] <ahasenack> wait I think, there is an RT
[18:20] <ahasenack> paride also wondered about switching the archive from ftpmaster.internal to the US mirror, since the dep8 machines are over there
[18:21] <ahasenack> that would mean some mirror lag, though (packages in ftpmaster that would not yet be in the mirror over there)
[18:40] <bdmurray> Its RT 156412
[18:40] <bdmurray> utkarsh2102: big_tests won't help with timeouts
[19:47] -queuebot:#ubuntu-release- New binary: webkit2gtk [arm64] (lunar-proposed/main) [2.39.91-1ubuntu1] (desktop-core, i386-whitelist)
[19:51] <Eickmeyer> Can I get an ack on ubuntustudio-default-settings in bin NEW and its associated FFe in bug 2008025?
[19:51] -ubottu:#ubuntu-release- Bug 2008025 in ubuntustudio-default-settings (Ubuntu) "[FFe] pipewire/pulseaudio configs for ubuntustudio in lunar" [High, New] https://launchpad.net/bugs/2008025
[20:48] <teward> vorlon: around for a few minutes for me to grab you on something?
[20:49] <vorlon> teward: hi
[21:16] <utkarsh2102> bdmurray: aah, I see! what does big_tests helps with then?
[21:17] <bdmurray> utkarsh2102: OOM and tests which take a long time to run
[21:18] <bdmurray> That should be documented in README.md of autopkgtst-package-configs
[21:19] <utkarsh2102> I see, that's what I had in mind
[21:20] <utkarsh2102> so isn't test time out and test taking a long time to run the same thing?
[21:20] <utkarsh2102> I mean, I assume that the former is a result of the latter, no?
[21:22] <bdmurray> The tests are timing out due to poor network connectivity which should be transient otherwise we'd throw everything in big_tests. Packages which run hundreds or thousands fo tests would be appropriate for big_packages or ones whose actual tests take a long period of time.
[21:22] <bdmurray> s/big_tests/big_packages/
[21:24] <bdmurray> I've currently landed a potential workaround to the test setup taking a long time due to network timeouts. We'll know if it worked in some number of hours - probably 3.
[21:25] <bdmurray> When I say test setup taking a long time I mean https://lists.ubuntu.com/archives/ubuntu-devel/2023-March/042500.html
[22:05] <kanashiro[m]> hi, could someone from the release team take a look at this FFe bug? LP #2011481
[22:05] -ubottu:#ubuntu-release- Launchpad bug 2011481 in pacemaker (Ubuntu) "[FFe] Depend on pcs and suggest crmsh" [Undecided, New] https://launchpad.net/bugs/2011481
[23:38] <bdmurray> I've created a discourse post about the current status of the autopkgtest service https://discourse.ubuntu.com/t/autopkgtest-service/34490