[02:23] Can I please get Binary NEW queue reviews for marble and akonadi? There's a sort of large tree that's depwait because of those... [02:39] Also, if a package is demoted to -proposed, what criteria does it have to meet to get back in -release? [02:40] (Adam demoted libkf5kface to -proposed during the opencv stuff, there's a new upstream release that should fix things) [02:44] (At least I thought, but it's irrelevant to the question about criteria, which I'd like to know for future reference ;) 0 [02:44] s/0/)/ [03:08] Can kubrick be let through? arm* is intentionally no longer built because of this gem: https://bugs.kde.org/show_bug.cgi?id=386367 [03:08] KDE bug 386367 in general "Support open GL ES" [Wishlist,Unconfirmed] [03:09] (by "let through" I mean "do the thing so Britney doesn't complain about missing those ;)") [04:17] -queuebot:#ubuntu-release- Unapproved: childsplay (trusty-proposed/universe) [1.6-1 => 1.6-1ubuntu0.1] (no packageset) [04:57] tsimonq2: most tests I queue are by clicking the 'retry' buttons on the proposed-migration / autopkgtest pages [04:58] tsimonq2: a package demoted to -proposed gets back into devel the same way any other package migrates from -proposed to devel [05:00] tsimonq2: and removing kubrick/arm64 would appear to make kdegames newly uninstallable on that architecture (arch: all package with dep on kubrick). are you sure that's what you want here? [05:03] slangasek: demotion remigration> Does it need *all* arches to pass builds or just the arches it previously built on> [05:03] the latter [05:03] Ok, cool. [05:04] specifically, the rule is that there must not be any out of date binaries for any arch [05:04] Well how does it know if there's out-of-date binaries if it's removed from -release and all -proposed arches are FTBFS? [05:04] by definition if there are no binaries there are no out of date binaries [05:05] however, if there was an older version of the package in -proposed that did build on some archs, and those binaries are published, but the package no longer builds on those archs, those are out-of-date binaries [05:06] But then why would it be removed from -proposed in the first place? [05:06] s/proposed/release/ [05:06] for whatever reason the AA gave when removing it [05:06] (which is logged in LP) [05:06] Fair. :P [05:11] slangasek: kubrick> Would something like this be correct in the Depends field of kdegames? (Debian policy doesn't seem to help on this): kubrick [!arm64] (>= ${kde:Version}), [05:11] not unless you change the package to be arch: any instead of arch: all. [05:12] Why is that the case? [05:12] [] notation is evaluated at package build time. [05:12] Oh, gotcha. [05:13] (And it seems sane in this case to change to any) [05:16] slangasek: https://launchpad.net/ubuntu/+source/meta-kde/5:92ubuntu4 [05:16] So yes, I'm OK with that now. [05:16] ok [05:16] removed [05:17] Thanks. [05:17] why was it dropped on arm64, though? I don't know how to interpret 'KDE Bug:386367' from the changelog; and it never failed to build in Ubuntu [05:18] "Kubrick needs openGL which means it can't be built on platforms which use openGLES. Arm platforms typically use GLES. Ideally it should be posted to also build with GLES." [05:19] curious; that doesn't seem like the sort of thing that would've been a new requirement in kubrick [05:20] Well we did do a new upstream release. [05:20] (well, they did, you get the point) [05:23] ah, the difference is the previous version was building against qt4 [05:23] Oh, right, that would explain it. [05:28] slangasek: So then out of curiosity, why did that not have to go through Binary NEW? [05:29] which? [05:29] (given that there were new binaries specifically for each arch instead of just one arch:all binary) [05:29] kdegames [05:29] hmm because the binary was already known for each arch [05:30] Oh, I thought it'd have to go through Binary NEW. TIL. [05:39] * tsimonq2 goes to bed, thanks slangasek! [05:39] * slangasek waves [07:50] yes, we did test build kubrick and found the FTBFS doing that. thanks for the above [12:59] -queuebot:#ubuntu-release- Unapproved: slic3r (artful-proposed/universe) [1.2.9+dfsg-6.1 => 1.2.9+dfsg-6.1ubuntu1] (no packageset) [13:01] damnit, tagged the wrong bug [13:03] -queuebot:#ubuntu-release- Unapproved: slic3r (artful-proposed/universe) [1.2.9+dfsg-6.1 => 1.2.9+dfsg-6.1ubuntu2] (no packageset) [13:04] ^ please ignore 1.2.9+dfsg-6.1ubuntu1 (wrong bug in changelog) [13:17] -queuebot:#ubuntu-release- Unapproved: rejected slic3r [source] (artful-proposed) [1.2.9+dfsg-6.1ubuntu1] [16:50] slangasek: good morning, several recent amd64/i386 autopkgtests fail with "ERROR: testbed failure: unexpected eof from the testbed" [16:52] I can +1 that, I've seen a couple ones myself failing like that. [16:52] slangasek: more specific example: http://autopkgtest.ubuntu.com/packages/g/grass/bionic/amd64 [16:54] It would certainly help if there weren't literally two amd64/i386 builders not stalled >_< https://launchpad.net/builders/ [16:54] s/2/3/ but still [16:57] Seems like they've been like that for about 13 hours... === elmo_ is now known as elmo [18:42] jbicha: looking at it I see some neutron errors in one of the x86 cloud regions; I'll escalate [18:43] meanwhile, I guess the good news is the arm64 backlog is finally less than the x86 backlog :P [18:44] (also, armhf is now the second fastest autopkgtest arch, how do you like that) === ajmitch_ is now known as ajmitch [20:30] If anyone's around, Launchpad's down to 2 active builders for amd64 and i386. [21:19] Oh, seems to be good now. \o/ [22:19] -queuebot:#ubuntu-release- New binary: mame [amd64] (bionic-proposed/universe) [0.192+dfsg.1-0ubuntu1] (no packageset) [23:34] -queuebot:#ubuntu-release- New binary: msxpertsuite [amd64] (bionic-proposed/universe) [3.8.1-2] (no packageset)