=== chris14_ is now known as chris14
RAOFjuliank: 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/199524705:12
LocutusOfBorgvorlon, hello, looks like the fix worked!07:47
LocutusOfBorgbtw, 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/103193407:48
LocutusOfBorgremoving libgeo-distance-xs-perl makes libgeo-distance-perl migrate07:48
cpaelzerLocutusOfBorg: 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-proposed08:01
cpaelzerLocutusOfBorg: only then will we overcome the uninstallability issue that also blocks this08:01
cpaelzerLocutusOfBorg: 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 present08:02
LocutusOfBorgI also tried to heal autopkgtests with all-proposed08:02
cpaelzerthe debian bug and the changelogs are rather clear that this is the way to go and the to be removed one really is dead08:03
LocutusOfBorgoh... lol the autopkgtests are against the wrong (being removed) package08:03
cpaelzeryes they are on build108:03
LocutusOfBorgyes also the breaks+replaces of xs-perl package are clear08:03
cpaelzerthe remaining PKG has no autopkgtests anymore, but while that is sad it is better than beign entirely unmaintained08:04
cpaelzerand the one in proposed is just a failed rebuild failing on its own build time tests08:05
cpaelzerthe new one at least still has build time testing08:06
cpaelzerafter investigation, agreed and removed08:06
LocutusOfBorglovely thanks!08:59
-queuebot:#ubuntu-release- Unapproved: accepted openscap [source] (kinetic-proposed) [1.2.17-0.1ubuntu7.22.10.1]09:32
-queuebot:#ubuntu-release- Unapproved: accepted openscap [source] (jammy-proposed) [1.2.17-0.1ubuntu7.22.04.1]09:38
ginggsvpa1977: i see openjdk-17 migrated, s390x had a slow day yesterday, but the migration-reference/0 tests did eventually run09:41
ginggsand then you need to wait for the next britney run to complete before those results would be considered09:41
-queuebot:#ubuntu-release- Unapproved: accepted openscap [source] (bionic-proposed) [1.2.15-1ubuntu0.4]09:43
-queuebot:#ubuntu-release- Unapproved: accepted openscap [source] (focal-proposed) [1.2.16-2ubuntu3.3]09:44
ginggsxnox: 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:26
ginggsi'm looking at https://autopkgtest.ubuntu.com/packages/p/python-fabio/lunar/amd6410:28
ginggsmigration-reference/0 tests consistently pass with the 5.19 kernel in release10:29
ginggsbut when triggered by any package from proposed (even yabasic, which is totally unrelated and triggered manually by me) the test is likely to fail10:30
ginggshttp.client.IncompleteRead: IncompleteRead(13391 bytes read, 1711 more expected)10:31
renanrodrigoHello all. In the abscence of Robie, who is taking care of SRUs on Wednesdays?11:50
=== chris15 is now known as chris14
=== tjaalton_ is now known as tjaalton
xnoxginggs:  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:46
xnoxginggs:  i guress you are implying our 6.1 kernel in proposed is toast, and cannot do netwokring or some such?13:47
xnoxcc: arighi ^^^^^13:47
ginggsxnox: thanks, and yes, something weird going on14:11
xnoxarighi:  which possibly explains the autopkgtest infra timeouts talking on the network of uploading /downloading tarballs?14:12
-queuebot:#ubuntu-release- New source: jtreg7 (lunar-proposed/primary) [7.1.1+1-0ubuntu1]14:30
juliankRAOF: Yes I followed up on this upstream and I think it got fixed but it needs an SRU too and then I forgot about it14:37
arighixnox, 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 instances16:08
arighiI'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 logs16:09
vorlonrenanrodrigo: Wednesdays> we don't generally backfill for SRUs but just pick up vanguard the next day. Is there something urgent for today?16:18
vorlonbritney only waiting now for 1356 test results and 2494 tests queued on arm64 alone16:27
vorlonchecking to see if I can obviously identify tests for stale triggers16:27
vorlon300+ tests queued for each of glib2.0 and nodejs but neither package is waiting for these results16:31
renanrodrigovorlon: there is a hotfix for ubuntu-advantage-tools, as always :(16:32
renanrodrigowe agreed with ahasenack so he takes care of it16:32
vorlonrenanrodrigo: ok16:32
arighiginggs, I'm trying to reproduce the problem in a local vm16:32
ginggsarighi: thanks!16:38
arighiginggs, 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:38
ginggsarighi: not off-hand sorry, but if i come across any, i'll let you know16:42
arighiginggs, I'll try a few more times with python-fabio, let's see if I can get one of those http IncompleteRead errors16:45
vorlonbdmurray, 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:50
ginggsvorlon: sounds good to me16:51
bdmurraysomething weird just happened with all the arm64 tests - they all seem to have the same start time16:55
vorlonbdmurray: ^^16:55
vorlonbdmurray: I just flushed the huge queue and requeued everything britney is actually waiting for on arm6416:56
vorlonor do you mean *running* tests?16:56
bdmurrayYes, I loaded the running page and it was empty for a second and then it wasn't16:57
vorlonanyway, that shrank the queue more than I expected, so I believe something's missing there but I can iterate later today16:58
vorlon(665 tests queued, but update_excuses.html says we have 1155 arm64 test results we're waiting for)16:58
bdmurrayI'm gonna get some coffe and then see if I can figure out what happened.16:58
-queuebot:#ubuntu-release- Unapproved: ubuntu-advantage-tools (kinetic-proposed/main) [27.13.5~22.10.1 => 27.13.6~22.10.1] (core)17:20
-queuebot:#ubuntu-release- Unapproved: ubuntu-advantage-tools (jammy-proposed/main) [27.13.5~22.04.1 => 27.13.6~22.04.1] (core)17:22
-queuebot:#ubuntu-release- Unapproved: ubuntu-advantage-tools (focal-proposed/main) [27.13.5~20.04.1 => 27.13.6~20.04.1] (core)17:24
-queuebot:#ubuntu-release- Unapproved: ubuntu-advantage-tools (bionic-proposed/main) [27.13.5~18.04.1 => 27.13.6~18.04.1] (core)17:25
-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:26
vorlonummm ok last successful build of gromacs/ppc64el used gcc-11; so I tried to downgrade and now I have 19 failing tests instead of 117:59
vorloncool, cool17:59
vorlonmpiexec has detected an attempt to run as root.17:59
vorlonOMPI_ALLOW_RUN_AS_ROOT_CONFIRM=1 yes because setting one env var to override isn't enough18:01
vorlonok that gets us a pass18:04
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-advantage-tools [source] (kinetic-proposed) [27.13.6~22.10.1]18:06
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-advantage-tools [source] (jammy-proposed) [27.13.6~22.04.1]18:09
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-advantage-tools [source] (focal-proposed) [27.13.6~20.04.1]18:10
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-advantage-tools [source] (bionic-proposed) [27.13.6~18.04.1]18:11
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-advantage-tools [source] (xenial-proposed) [27.13.6~16.04.1]18:12
sergiodjhi, FFe to start untangling the mess that's become dh-elpa/emacs/flycheck: https://bugs.launchpad.net/ubuntu/+source/dh-elpa/+bug/200891918:12
-ubottu:#ubuntu-release- Launchpad bug 2008919 in dh-elpa (Ubuntu) "[FFe] Implement support for 'buttercup_eval'" [Undecided, New]18:12
vorlonlast britney run failed with a connection error to rabbitmq >:|18:14
Eickmeyervorlon: 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:18
vorlonEickmeyer: you do? I don't see that ubiquity-slideshow-ubuntu or ubiquity have updated today in lunar release18:22
Eickmeyervorlon: 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
vorlonEickmeyer: ah ok18:23
EickmeyerI'll switch them when I can get a core-dev to release a new version of ubiquity-slideshow-edubuntu.18:23
vorlonrunning a build18:23
athosHi! Is there any documentation regarding support of installations with -updates pocket disable (release and security only) for point releases?18:33
athoshttps://wiki.ubuntu.com/SecurityTeam/FAQ stages that "Systems configured to use only the security pocket are also supported."18:33
vorlonathos: not afaik (and it wouldn't come from the release team anyway)18:38
athosand 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:38
athosLP: #200846518: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/200846518:39
vorlonathos: 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 reason18:40
vorlonwe, 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, nack18:41
vorlon(and we also only auto-install from -security, not -updates)18:41
vorlon^ meaning unattended-upgrades18:42
athosNice! 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:44
sergiodjhm, I saw this bug, too.  I think we should reassign it; openldap doesn't seem to be the culprit here18:45
sergiodjreassign to another package18:45
sergiodjor to Ubuntu itself18:45
vorlonsimpler to just mark it "invalid"18:48
vorlonwhich has the same semantics without misleading the submitter18:48
mdeslaurwait a sec, having -updates disabled is something we do support18:49
mdeslaurthough, perhaps when not installing from a point release...it never occurred to me how problematic that is18:52
mdeslaurs/when not/not when/18:52
rbasakYeah. Why is the security pocket separate otherwise?19:03
rbasakOh, unattended-upgrades automatic vs. manual might be a fair reason I suppose. But that didn't really exist originally!19:05
arraybolt3And the security pocket is frequently shipped by security.ubuntu.com, not a user-chosen mirror.19:06
arraybolt3That way a slow mirror doesn't interfere with security updates.19:06
mdeslaurI 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 something19:07
mdeslaurI mean, if we don't want to support it anymore it sure would make security updates simpler :)19:08
rbasakIt seems like it should be supportable still, but with caveats that we could do with documenting.19:08
rbasakLike 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
mdeslauryeah, there are definitely some gotchas there that aren't documented19:09
tsimonq2I 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
tsimonq2I would certainly be in support of having a queue for security updates in Universe, or something to make it easier for community developers.19:23
tsimonq2Out of those Landscape customers, I wonder how many have Universe enabled, and if a majority do, what kind of packages are installed.19:24
mdeslaurtsimonq2: oh? is ubuntu-security-sponsors subscribed to it?19:35
mdeslaur(no idea for how many universe, sorry...that's a good question though)19:36
mdeslaurtsimonq2: we have someone dedicated to sponsoring rotation every week19:36
vorlonhttps://autopkgtest.ubuntu.com/running#queue-ubuntu-lunar-arm64 now looks very close in size to the set of tests britney is waiting for20:29
vorlonand also, looks to be manageable over the next 24h or so20:29
Eickmeyervorlon: Latest Edubuntu installs and looks good after install. I'm very pleased with this. Told amypenguin about it, she's very happy too.20:48
LocutusOfBorgvorlon, mariadb needs mariadb-10.1 kicked out21:29
LocutusOfBorgwith mariadb-10.1 I actually mean mariadb-10.621:29
LocutusOfBorgthey created a versionless src package21:29
LocutusOfBorgbut it can't migrate due to mariadb triggering mariadb-10.1 autopkgtests (and failing)21:29
LocutusOfBorgdo you think we can do the magic?21:30
vorlonLocutusOfBorg: 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
LocutusOfBorgand then remove mariadb-10.6? yes probably21:31
LocutusOfBorgvorlon, that test needed changes because of new mariadb and they were done in mariadb itself21:32
LocutusOfBorgso the test is outdated for mariadb-10.621:32
vorlonyes, I've seen such failures of tests before between versioned source packages21:32
LocutusOfBorge.g.   * Temporarily disable MTR on s390x as Debian buildd seems unstable21:33
LocutusOfBorg  * Skip tests that have bug reports and known to fail on 1:10.11.1-221:33
LocutusOfBorgand so on, src:mariadb looks the natural way to move forward21:33
LocutusOfBorgvorlon, do you know why ocaml is not migrating please?21:43
LocutusOfBorglooks blocked on llvm-toolchain-13 only, on arm64, and the test is regressed in release21:43
LocutusOfBorgand update_excuses_notest shows it as migratable21:44
LocutusOfBorg(also, src:ddnet is not a thing anymore on s390x) Debian bug: #103115921: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/103115921:45
LocutusOfBorgplease do some magic if possible21:45
vorlonLocutusOfBorg: any magic I do now would be redundant with your baseline retest, which just hasn't been picked up yet by a britney run afaics21:46
LocutusOfBorgmmm ok, I saw ffmpeg migrate 5 minutes ago21:46
LocutusOfBorgbut maybe the test was quicker21:47
vorlonI could be wrong tho; we have output from a run that started at 19:29:42, which is after your baseline test result21:47
LocutusOfBorgyep, and from britney log, I see ocaml is trying to fetch some result that doesn't exist21:48
LocutusOfBorgthis is why I think there is some issue21:48
vorlonI: [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']): fail21:48
vorlonI: [2023-03-01T19:58:02+0000] - -> does not match any pending request for llvm-toolchain-13/arm6421:48
vorlonthat is... less than useful21:48
vorlonI'll badtest it21:48
LocutusOfBorgalso dpkg is holding the migration due to dahdi-linux regression21:50
LocutusOfBorgnow 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 fault21:50
LocutusOfBorgwhat can we do about it? (yes, fixing dadhi is also something to do)21:51
vorlonwe can skiptest if that's the only remaining blocker21:53
vorlonwhich I confirm is true21:53
Eickmeyervorlon: 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:37
EickmeyerOther than that, lgtm.22:38
=== chris14_ is now known as chris14
vorlonhttps://launchpad.net/ubuntu/+source/gromacs/2022.5-2ubuntu1 fixed gromacs/ppc64el.  last blocker for boost1.7423:06
-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:19
sergiodjahasenack: ^23:22
vorlonpublisher looking slow, https://launchpad.net/ubuntu/+source/gromacs/2022.5-2ubuntu1/+build/25633954 has been 'accepted' for quite a while23:51

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!