=== chris14_ is now known as chris14
[05:12] <RAOF> juliank: Do you want apt bug #1995247 to get released into -updates at some point? There's a correctly-failing autopkgtest for sbuild that will need to be fixed first.
[05:12] -ubottu:#ubuntu-release- Bug 1995247 in apt (Ubuntu Kinetic) "Leftover /tmp/apt-key.* files after updates with embedded gpg keys in deb822 sources" [High, Fix Committed] https://launchpad.net/bugs/1995247
[07:47] <LocutusOfBorg> vorlon, hello, looks like the fix worked!
[07:48] <LocutusOfBorg> btw, please can any ubuntu-archive admin process Debian bug: #1031934 in Ubuntu?
[07:48] -ubottu:#ubuntu-release- Debian bug 1031934 in ftp.debian.org "RM: libgeo-distance-xs-perl -- ROM; RC buggy, no rdeps, abandoned upstream" [Normal, Open] https://bugs.debian.org/1031934
[07:48] <LocutusOfBorg> removing libgeo-distance-xs-perl makes libgeo-distance-perl migrate
[08:01] <cpaelzer> LocutusOfBorg: that looks right, indeed the only dep left is the old libgeo-distance-perl recommends to it. But we need to remove both the build1 in lunar and the build2 in lunar-proposed
[08:01] <LocutusOfBorg> correct
[08:01] <cpaelzer> LocutusOfBorg: only then will we overcome the uninstallability issue that also blocks this
[08:02] <cpaelzer> LocutusOfBorg: gladly htat is only a recommends, but in theory it will shortly regress the old set of libgeo-distance-perl+libgeo-distance-xs-perl - but I see no other way to come by not having this short lack of the recommend being present
[08:02] <LocutusOfBorg> I also tried to heal autopkgtests with all-proposed
[08:03] <cpaelzer> the debian bug and the changelogs are rather clear that this is the way to go and the to be removed one really is dead
[08:03] <LocutusOfBorg> oh... lol the autopkgtests are against the wrong (being removed) package
[08:03] <cpaelzer> yes they are on build1
[08:03] <LocutusOfBorg> yes also the breaks+replaces of xs-perl package are clear
[08:04] <cpaelzer> the remaining PKG has no autopkgtests anymore, but while that is sad it is better than beign entirely unmaintained
[08:05] <cpaelzer> and the one in proposed is just a failed rebuild failing on its own build time tests
[08:06] <cpaelzer> the new one at least still has build time testing
[08:06] <cpaelzer> after investigation, agreed and removed
[08:59] <LocutusOfBorg> lovely thanks!
[09:32] -queuebot:#ubuntu-release- Unapproved: accepted openscap [source] (kinetic-proposed) [1.2.17-0.1ubuntu7.22.10.1]
[09:38] -queuebot:#ubuntu-release- Unapproved: accepted openscap [source] (jammy-proposed) [1.2.17-0.1ubuntu7.22.04.1]
[09:41] <ginggs> vpa1977: i see openjdk-17 migrated, s390x had a slow day yesterday, but the migration-reference/0 tests did eventually run
[09:41] <ginggs> and then you need to wait for the next britney run to complete before those results would be considered
[09:43] -queuebot:#ubuntu-release- Unapproved: accepted openscap [source] (bionic-proposed) [1.2.15-1ubuntu0.4]
[09:44] -queuebot:#ubuntu-release- Unapproved: accepted openscap [source] (focal-proposed) [1.2.16-2ubuntu3.3]
[10:26] <ginggs> xnox: o/ do you happen to know if it's a bug or a feature that when an autopkgtest is triggered by a package in -proposed, the new kernel in proposed is installed?
[10:28] <ginggs> i'm looking at https://autopkgtest.ubuntu.com/packages/p/python-fabio/lunar/amd64
[10:29] <ginggs> migration-reference/0 tests consistently pass with the 5.19 kernel in release
[10:30] <ginggs> but when triggered by any package from proposed (even yabasic, which is totally unrelated and triggered manually by me) the test is likely to fail
[10:31] <ginggs> http.client.IncompleteRead: IncompleteRead(13391 bytes read, 1711 more expected)
[11:50] <renanrodrigo> Hello all. In the abscence of Robie, who is taking care of SRUs on Wednesdays?
[11:50] <renanrodrigo> absence**
=== chris15 is now known as chris14
=== tjaalton_ is now known as tjaalton
[13:46] <xnox> ginggs:  i believe it is an autopkgtest feature to always use kernel from proposed in general. the migration reference mode might be weird, and there have been recent bugs and regressions in how autopkgtest infra sets up the test beds.
[13:47] <xnox> ginggs:  i guress you are implying our 6.1 kernel in proposed is toast, and cannot do netwokring or some such?
[13:47] <xnox> cc: arighi ^^^^^
[14:11] <ginggs> xnox: thanks, and yes, something weird going on
[14:12] <xnox> arighi:  which possibly explains the autopkgtest infra timeouts talking on the network of uploading /downloading tarballs?
[14:30] -queuebot:#ubuntu-release- New source: jtreg7 (lunar-proposed/primary) [7.1.1+1-0ubuntu1]
[14:37] <juliank> RAOF: Yes I followed up on this upstream and I think it got fixed but it needs an SRU too and then I forgot about it
[16:08] <arighi> xnox, ginggs, sorry I'm noticing your messages only now, weird... I've been using 6.1 in my latop, in a lot of VMs and I haven't experienced any network problems, so I guess there's something special in the autopkgtest instances
[16:09] <arighi> I'm wondering if there's a way to recreate the same autopkgtest environment to see if I can reproduce the problem, unless there's a way to get more kernel-related info from the logs
[16:18] <vorlon> renanrodrigo: Wednesdays> we don't generally backfill for SRUs but just pick up vanguard the next day. Is there something urgent for today?
[16:27] <vorlon> britney only waiting now for 1356 test results and 2494 tests queued on arm64 alone
[16:27] <vorlon> checking to see if I can obviously identify tests for stale triggers
[16:31] <vorlon> 300+ tests queued for each of glib2.0 and nodejs but neither package is waiting for these results
[16:32] <renanrodrigo> vorlon: there is a hotfix for ubuntu-advantage-tools, as always :(
[16:32] <renanrodrigo> we agreed with ahasenack so he takes care of it
[16:32] <vorlon> renanrodrigo: ok
[16:32] <arighi> ginggs, I'm trying to reproduce the problem in a local vm
[16:38] <ginggs> arighi: thanks!
[16:38] <arighi> ginggs, hm.. all good in a local vm, both with python-fabio autopkgtest and yabasic, do you know any other autopgktest that may stress the network a bit more?
[16:42] <ginggs> arighi: not off-hand sorry, but if i come across any, i'll let you know
[16:45] <arighi> ginggs, I'll try a few more times with python-fabio, let's see if I can get one of those http IncompleteRead errors
[16:50] <vorlon> bdmurray, ginggs: fwiw I'm considering just dumping the entire huge queue for arm64, so far the hit rate for duplicate/unnecessary tests is 100%.  So dumping the huge queue and re-queuing the things britney is actually waiting for should cut the remaining queue by 30% (which is about how much I've already cut it by)
[16:51] <ginggs> vorlon: sounds good to me
[16:55] <bdmurray> something weird just happened with all the arm64 tests - they all seem to have the same start time
[16:55] <vorlon> bdmurray: ^^
[16:56] <bdmurray> ?
[16:56] <vorlon> bdmurray: I just flushed the huge queue and requeued everything britney is actually waiting for on arm64
[16:56] <vorlon> or do you mean *running* tests?
[16:57] <bdmurray> Yes, I loaded the running page and it was empty for a second and then it wasn't
[16:57] <vorlon> neato
[16:58] <vorlon> anyway, that shrank the queue more than I expected, so I believe something's missing there but I can iterate later today
[16:58] <vorlon> (665 tests queued, but update_excuses.html says we have 1155 arm64 test results we're waiting for)
[16:58] <bdmurray> I'm gonna get some coffe and then see if I can figure out what happened.
[17:20] -queuebot:#ubuntu-release- Unapproved: ubuntu-advantage-tools (kinetic-proposed/main) [27.13.5~22.10.1 => 27.13.6~22.10.1] (core)
[17:22] -queuebot:#ubuntu-release- Unapproved: ubuntu-advantage-tools (jammy-proposed/main) [27.13.5~22.04.1 => 27.13.6~22.04.1] (core)
[17:24] -queuebot:#ubuntu-release- Unapproved: ubuntu-advantage-tools (focal-proposed/main) [27.13.5~20.04.1 => 27.13.6~20.04.1] (core)
[17:25] -queuebot:#ubuntu-release- Unapproved: ubuntu-advantage-tools (bionic-proposed/main) [27.13.5~18.04.1 => 27.13.6~18.04.1] (core)
[17:26] -queuebot:#ubuntu-release- Unapproved: ubuntu-advantage-tools (xenial-proposed/main) [27.13.5~16.04.1 => 27.13.6~16.04.1] (no packageset)
[17:59] <vorlon> ummm ok last successful build of gromacs/ppc64el used gcc-11; so I tried to downgrade and now I have 19 failing tests instead of 1
[17:59] <vorlon> cool, cool
[17:59] <vorlon> mpiexec has detected an attempt to run as root.
[17:59] <vorlon> >_<
[18:01] <vorlon> OMPI_ALLOW_RUN_AS_ROOT_CONFIRM=1 yes because setting one env var to override isn't enough
[18:04] <vorlon> ok that gets us a pass
[18:06] -queuebot:#ubuntu-release- Unapproved: accepted ubuntu-advantage-tools [source] (kinetic-proposed) [27.13.6~22.10.1]
[18:09] -queuebot:#ubuntu-release- Unapproved: accepted ubuntu-advantage-tools [source] (jammy-proposed) [27.13.6~22.04.1]
[18:10] -queuebot:#ubuntu-release- Unapproved: accepted ubuntu-advantage-tools [source] (focal-proposed) [27.13.6~20.04.1]
[18:11] -queuebot:#ubuntu-release- Unapproved: accepted ubuntu-advantage-tools [source] (bionic-proposed) [27.13.6~18.04.1]
[18:12] -queuebot:#ubuntu-release- Unapproved: accepted ubuntu-advantage-tools [source] (xenial-proposed) [27.13.6~16.04.1]
[18:12] <sergiodj> hi, FFe to start untangling the mess that's become dh-elpa/emacs/flycheck: https://bugs.launchpad.net/ubuntu/+source/dh-elpa/+bug/2008919
[18:12] -ubottu:#ubuntu-release- Launchpad bug 2008919 in dh-elpa (Ubuntu) "[FFe] Implement support for 'buttercup_eval'" [Undecided, New]
[18:14] <vorlon> last britney run failed with a connection error to rabbitmq >:|
[18:18] <Eickmeyer> vorlon: Do you have a spare cycle to trigger a rebuild for the Edubuntu iso? I have a fix in place that fixes the ubiquity issue (lack of slideshow).
[18:22] <vorlon> Eickmeyer: you do? I don't see that ubiquity-slideshow-ubuntu or ubiquity have updated today in lunar release
[18:23] <Eickmeyer> vorlon: ubiquity-slideshow-ubuntu was not in the "live" seed for edubuntu, so I added it. ubiquity-slideshow-edubuntu was, but that's not in the archive right now.
[18:23] <vorlon> Eickmeyer: ah ok
[18:23] <Eickmeyer> I'll switch them when I can get a core-dev to release a new version of ubiquity-slideshow-edubuntu.
[18:23] <vorlon> running a build
[18:23] <Eickmeyer> Thanks!
[18:33] <athos> Hi! Is there any documentation regarding support of installations with -updates pocket disable (release and security only) for point releases?
[18:33] <athos> https://wiki.ubuntu.com/SecurityTeam/FAQ stages that "Systems configured to use only the security pocket are also supported."
[18:38] <vorlon> athos: not afaik (and it wouldn't come from the release team anyway)
[18:38] <athos> and I just came across this interesting bug where the user installed a point release and disabled the updates pocket. Then they get errors due to some seeded package version being greater/different from what is required by another binary package in release/security.
[18:39] <athos> LP: #2008465
[18:39] -ubottu:#ubuntu-release- Launchpad bug 2008465 in openldap (Ubuntu) "apt repository broken when having only jammy and jammy-security apt-repos enabled" [Undecided, New] https://launchpad.net/bugs/2008465
[18:40] <vorlon> athos: yep! I'd point to the security team for this.  I would never say that it's "supported" to disable the updates pocket for precisely this reason
[18:41] <vorlon> we, as the distro team, have to ensure that upgrades work; and the security team ensures that the security pocket doesn't have dependencies on updates.  But telling users that it's ok to disable updates in sources, nack
[18:41] <vorlon> (and we also only auto-install from -security, not -updates)
[18:42] <vorlon> ^ meaning unattended-upgrades
[18:44] <athos> Nice! I thought I was missing sth there :) I will ping the security team on that matter then. Should we state the opposite in that wiki though? i.e. "disabling the updates pocket is NOT supported"
[18:45] <sergiodj> hm, I saw this bug, too.  I think we should reassign it; openldap doesn't seem to be the culprit here
[18:45] <sergiodj> reassign to another package
[18:45] <sergiodj> or to Ubuntu itself
[18:48] <vorlon> simpler to just mark it "invalid"
[18:48] <vorlon> which has the same semantics without misleading the submitter
[18:49] <mdeslaur> wait a sec, having -updates disabled is something we do support
[18:52] <mdeslaur> though, perhaps when not installing from a point release...it never occurred to me how problematic that is
[18:52] <mdeslaur> s/when not/not when/
[19:03] <rbasak> Yeah. Why is the security pocket separate otherwise?
[19:05] <rbasak> Oh, unattended-upgrades automatic vs. manual might be a fair reason I suppose. But that didn't really exist originally!
[19:06] <arraybolt3> And the security pocket is frequently shipped by security.ubuntu.com, not a user-chosen mirror.
[19:06] <arraybolt3> s/shipped/served/
[19:06] <arraybolt3> That way a slow mirror doesn't interfere with security updates.
[19:07] <mdeslaur> I had the landscape folks check how many of their customers were running with -updates disabled a few years ago, and it was surprisingly high, like a third or something
[19:08] <mdeslaur> I mean, if we don't want to support it anymore it sure would make security updates simpler :)
[19:08] <rbasak> It seems like it should be supportable still, but with caveats that we could do with documenting.
[19:09] <rbasak> Like if you want to install new packages, and you installed from a point release, then you need to do that before disabling -updates. I'm not sure that would cover all cases though.
[19:09] <mdeslaur> yeah, there are definitely some gotchas there that aren't documented
[19:23] <tsimonq2> I know of a few security updates that would be nice to deliver but require someone from the security team to upload it (some have been sitting in the sponsorship queue for quite some time).
[19:23] <tsimonq2> I would certainly be in support of having a queue for security updates in Universe, or something to make it easier for community developers.
[19:24] <tsimonq2> Out of those Landscape customers, I wonder how many have Universe enabled, and if a majority do, what kind of packages are installed.
[19:35] <mdeslaur> tsimonq2: oh? is ubuntu-security-sponsors subscribed to it?
[19:36] <mdeslaur> (no idea for how many universe, sorry...that's a good question though)
[19:36] <mdeslaur> tsimonq2: we have someone dedicated to sponsoring rotation every week
[20:29] <vorlon> https://autopkgtest.ubuntu.com/running#queue-ubuntu-lunar-arm64 now looks very close in size to the set of tests britney is waiting for
[20:29] <vorlon> and also, looks to be manageable over the next 24h or so
[20:32] <bdmurray> 🤞
[20:48] <Eickmeyer> vorlon: Latest Edubuntu installs and looks good after install. I'm very pleased with this. Told amypenguin about it, she's very happy too.
[20:49] <vorlon> sweet
[21:29] <LocutusOfBorg> vorlon, mariadb needs mariadb-10.1 kicked out
[21:29] <LocutusOfBorg> with mariadb-10.1 I actually mean mariadb-10.6
[21:29] <LocutusOfBorg> they created a versionless src package
[21:29] <LocutusOfBorg> but it can't migrate due to mariadb triggering mariadb-10.1 autopkgtests (and failing)
[21:30] <LocutusOfBorg> do you think we can do the magic?
[21:31] <vorlon> LocutusOfBorg: is it sufficient to skiptest mariadb and let the rest be handled automatically?
[21:31] <vorlon> (how did this pass on armhf and s390x?)
[21:31] <LocutusOfBorg> and then remove mariadb-10.6? yes probably
[21:32] <LocutusOfBorg> vorlon, that test needed changes because of new mariadb and they were done in mariadb itself
[21:32] <LocutusOfBorg> so the test is outdated for mariadb-10.6
[21:32] <vorlon> yes, I've seen such failures of tests before between versioned source packages
[21:33] <LocutusOfBorg> e.g.   * Temporarily disable MTR on s390x as Debian buildd seems unstable
[21:33] <LocutusOfBorg>   * Skip tests that have bug reports and known to fail on 1:10.11.1-2
[21:33] <LocutusOfBorg> and so on, src:mariadb looks the natural way to move forward
[21:33] <vorlon> vyborně
[21:43] <LocutusOfBorg> vorlon, do you know why ocaml is not migrating please?
[21:43] <LocutusOfBorg> looks blocked on llvm-toolchain-13 only, on arm64, and the test is regressed in release
[21:43] <LocutusOfBorg> https://autopkgtest.ubuntu.com/packages/l/llvm-toolchain-13/lunar/arm64
[21:44] <LocutusOfBorg> and update_excuses_notest shows it as migratable
[21:45] <LocutusOfBorg> (also, src:ddnet is not a thing anymore on s390x) Debian bug: #1031159
[21:45] -ubottu:#ubuntu-release- Debian bug 1031159 in ftp.debian.org "RM: ddnet [s390x] -- RoQA; no longer builds on s390x" [Normal, Open] https://bugs.debian.org/1031159
[21:45] <LocutusOfBorg> please do some magic if possible
[21:46] <vorlon> LocutusOfBorg: any magic I do now would be redundant with your baseline retest, which just hasn't been picked up yet by a britney run afaics
[21:46] <LocutusOfBorg> mmm ok, I saw ffmpeg migrate 5 minutes ago
[21:47] <LocutusOfBorg> but maybe the test was quicker
[21:47] <vorlon> I could be wrong tho; we have output from a run that started at 19:29:42, which is after your baseline test result
[21:48] <LocutusOfBorg> yep, and from britney log, I see ocaml is trying to fetch some result that doesn't exist
[21:48] <LocutusOfBorg> this is why I think there is some issue
[21:48] <vorlon> I: [2023-03-01T19:58:02+0000] - Fetched test result for llvm-toolchain-13/1:13.0.1-11ubuntu14/arm64 20230301_185112_3871c@ (triggers: ['migration-reference/0']): fail
[21:48] <vorlon> I: [2023-03-01T19:58:02+0000] - -> does not match any pending request for llvm-toolchain-13/arm64
[21:48] <vorlon> that is... less than useful
[21:48] <vorlon> I'll badtest it
[21:49] <LocutusOfBorg> thanks
[21:50] <LocutusOfBorg> also dpkg is holding the migration due to dahdi-linux regression
[21:50] <LocutusOfBorg> now autopkgtests are installing devel linux 6.1 during tests, but not with migration-reference/0, so britney thinks dpkg is regressing something that is really new kernel fault
[21:51] <LocutusOfBorg> what can we do about it? (yes, fixing dadhi is also something to do)
[21:53] <vorlon> we can skiptest if that's the only remaining blocker
[21:53] <vorlon> which I confirm is true
[22:37] <Eickmeyer> vorlon: The LTSP testcase for Edubuntu can be removed from the testsuite, but I just added 1778 as a post-install testcase which should do the trick for the specific functions to be tested.
[22:38] <Eickmeyer> Other than that, lgtm.
=== chris14_ is now known as chris14
[23:06] <vorlon> https://launchpad.net/ubuntu/+source/gromacs/2022.5-2ubuntu1 fixed gromacs/ppc64el.  last blocker for boost1.74
[23:19] -queuebot:#ubuntu-release- Unapproved: openldap (kinetic-proposed/main) [2.5.13+dfsg-1ubuntu1 => 2.5.14+dfsg-0ubuntu0.22.10.1] (i386-whitelist, ubuntu-server)
[23:22] <sergiodj> ahasenack: ^
[23:51] <vorlon> publisher looking slow, https://launchpad.net/ubuntu/+source/gromacs/2022.5-2ubuntu1/+build/25633954 has been 'accepted' for quite a while