=== cpaelzer__ is now known as cpaelzer
[07:41] <cpaelzer> it seems on d/t/control you can't restrict the @ wildcard with architectures like  Depends: @ [amd64 s390x], @builddeps@, ethtool
[07:41] <cpaelzer> all I want is to only run it on those two and not on any other arches
[07:41] <cpaelzer> it feels like this must be easy and common, but I haven't seen a great and easy "tag for architectures that it should run" yet
[07:42] <cpaelzer> I might have been missing it all the years, hints welcome :-)
[08:02] <infinity> cpaelzer__: Why shouldn't it run for all arches?  If it's known to fail on others, then it'll fail, so what?
=== cpaelzer__ is now known as cpaelzer
[08:03] <cpaelzer> infinity: yes it is known to fail on other arches
[08:04] <cpaelzer> infinity: the package has many tests and just one would have that "fails on some arches"
[08:04] <infinity> cpaelzer: Right, we don't generally want to hide problems by skipping testsuites where they fail.
[08:04] <cpaelzer> I'd want to have the coverage of the other tests that work well on all arches
[08:04] <cpaelzer> and these extra tests that have limited arches run only on those known to work
[08:04] <infinity> cpaelzer: Ahh, if the goal is to run all the "good" tests, just wrap the bad one in a dpkg-architecture check?
[08:04] <cpaelzer> yes
[08:05] <cpaelzer> I have doen so years ago for DPDK, but I wondered if there is anything new
[08:05] <cpaelzer> better than if dpkd --print-architecture ...
[08:05] <infinity> From my POV, I wouldn't want arch-restriction semantics in debian/tests/control, cause it would encourage its use for evil. :P
[08:06] <infinity> But that's just my opinion.
[08:06] <cpaelzer> hehe, maybe that is the reason it isn't there
[08:06] <cpaelzer> will do a less comfortable semi-manual arch check for this special case then ...
[08:08] <cpaelzer> thanks for the talk infinity, now I feel less like "there must be a tag for arch-restrictions, but I'm the only one not knowing it"
[08:13] <infinity> cpaelzer: Nah, it really doesn't exist.  And while I can see an argument that it could be useful, I think what would be more useful is work on debci/autopkgtest to record granular test results and britney integration to use those.
[08:14] <infinity> cpaelzer: Cause it's valuable information to know that 5/6 pass, and 1/6 is an xfail, cause it's never passed.  Ignoring that 1/6 by arch-restricting is just a bandaid.
[08:22] <cpaelzer> ack to that as a vision for autopkgtest.u.c
[08:31] <seb128> vorlon, hey, do you still plan to do the regular i386 removals to unblock things? there is a stack of 3 days old blocked item on the proposed-migration summary
[08:33] <ricotz> seb128, hi :), is there a list of packages which will keep their i386 builds?
[08:35] <seb128> ricotz, hey, yes, https://people.canonical.com/~ubuntu-archive/packagesets/focal/i386-whitelist
[08:35] <ricotz> thanks!
[08:35] <seb128> ricotz, it's built according to the feedback given in https://discourse.ubuntu.com/t/community-process-for-32-bit-compatibility/12598
[08:35] <seb128> ricotz, np!
[08:59] <ricotz> seb128, looks like this whilelist doesn't apply to PPAs?
[09:02] <cjwatson> The whitelist applies to PPAs
[09:02] <infinity> cjwatson: It does?  Without a toggle?
[09:02] <ricotz> cjwatson, ok, I see "vala" is in the list, but https://launchpad.net/~vala-team/+archive/ubuntu/daily/+packages
[09:02] <cjwatson> There is currently no toggle available.  There probably should be
[09:02] <infinity> cjwatson: Cause a common use-case of PPAs is to build stuff that doesn't exist in PRIMARY, which the whitelist wouldn't allow.
[09:03] <cjwatson> Somebody who needs such a toggle should file a bug please
[09:03] <infinity> ricotz: vala != vala-git.
[09:03] <ricotz> sorry, the is vala-git for some convenient reasons
[09:03] <cjwatson> ricotz: But there is no ... that
[09:03] <infinity> ricotz: The whitelist is source package.
[09:04] <infinity> cjwatson: Filing.
[09:04] <cjwatson> Ta
[09:05] <infinity> cjwatson: UI might be interesting.  From a "what other options does it look like" perspective, it clearly fits well next to the "use same components as PRIMARY" toggle, but that page is called "Edit Dependencies" not "influence build record creation".
[09:05] <infinity> Maybe under the arch selection makes as much sense, though.,
[09:09] <infinity> cjwatson: LP: #1855069
[09:09] <ubottu> Launchpad bug 1855069 in Launchpad itself "PPAs should be able to toggle using PRIMARY's arch-{white,black}lists" [Undecided,New] https://launchpad.net/bugs/1855069
[09:53] <rbalint> seb128, already did https://github.com/df7cb/newpid/pull/2
[09:58] <seb128> rbalint, hey, that's upstream and not Debian right? well, I guess if upstream is active that's going to flow back to Debian and then us...
[09:59] <rbalint> seb128, this is the repo listed in Vcs-Git
[09:59] <seb128> rbalint, ah ok, perfect then, thanks!
[10:19] <seb128> tjaalton, hey, do you think you could look at the silx autopkgtest (https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/amd64/s/silx/20191130_223733_29186@/log.gz), I tried to unblock xorg-server proposed-migration and I think that's the remaining problem but I don't understand the openCL error there
[10:29] <tjaalton> seb128: me neither
[10:29] <seb128> tjaalton, do you know who would know? we need that sorted out one way or another
[10:30] <tjaalton> no..
[10:30] <tjaalton> same pocl used on both focal and debian
[10:30] <tjaalton> failed on debian too but because of something else
[12:50] <ahasenack> hello, could an archive admin please take a look at the haproxy i386 failure in https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#haproxy ?
[12:51] <ahasenack> is this a case where the i386 package has to be removed, as per vorlon's email to ubuntu-devel a few days ago?
[12:53] <ahasenack> oh, that email said to use #ubuntu-release
=== cpaelzer__ is now known as cpaelzer
=== ricab is now known as ricab|lunch
[14:34] <coreycb> doko: 20.04 won't have python 3.6 will it? I don't think so but figured I'd check.
[14:42] <cjwatson> Even 19.10 didn't have Python 3.6.
[14:42] <cjwatson> Indeed it was removed in 19.04.
[14:53] <doko> coreycb: ^^^
[14:53] <coreycb> doko: cjwatson: yeah sorry not thinking
[14:55] <doko> coreycb: and we are trying to drop 3.7 in 20.04
[14:56] <doko> coreycb, jamespage: I'm now proposing to update 2.7 to 2.7.17 in bionic. I have no regressions found in main (builds). is there anything you want to check for openstack?
[14:56] <coreycb> doko: so 20.04 will be 3.8 only?
[14:56] <doko> and likely 2.7
[14:56] <coreycb> doko: ok
[14:59] <coreycb> doko: thanks. we could run regression with 2.7.17 in -proposed if needed.
[15:01] <doko> coreycb: ok, packages are currently in ubuntu-toolchain-r/ppa PPA. then I'll go ahead with the uploads to proposed, and wait for checks. it's not urgent
[15:01] <coreycb> doko: thanks i'll keep an eye out for it in proposed
[15:31] <seb128> tsimonq2, hey, just as a FYI, I removed https://bugs.launchpad.net/ubuntu/+source/indicator-multiload/0.4+git20170224-0ubuntu1 since it was buggy/not building/removing translations
[15:31] <ubottu> Error: launchpad bug 0 not found
[15:33] <vorlon> seb128: the three-day-old blocked packages are the ones that have non-trivial revdeps that I haven't unwound.  do you have specific ones you want me to look at?
[15:38] <seb128> vorlon, liborcus would be nice, it's one of the blocker for glibc and others
[15:38] <vorlon> for glibc?
[15:39] <vorlon> I'll look at liborcus
[15:39] <seb128> vorlon, according to https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses_by_team.html#desktop-packages yes
[15:39] <seb128>  liborcus blocking glibc (2.30-0ubuntu2 to 2.30-0ubuntu3) for 4 days
[15:39] <seb128> (the test issue is fixed in -3 which isn't mgirating because of i386)
[15:39] <vorlon> seb128: blocking via autopkgtest failure; if the test is broken in -3 we should be badtesting that?
[15:40] <vorlon> in -2, sorry
[15:40] <seb128> well it's fixed in -3 so I guess we could also retry with that added to the trigger= list
[15:40] <seb128> but ideally the fixed version would just migrate
[15:41] <vorlon> that ideal is the slow path in general for unblocking packages
=== ricab|lunch is now known as ricab
[15:45] <seb128> vorlon, right, I'll just retry with the trigger for now, going through the rdepends list indeed doesn't seem trivial :-/
[15:46] <seb128> vorlon, oh, also, can you make dbus migrate? the only remaining blocker is http://autopkgtest.ubuntu.com/packages/s/systemd/focal/i386
[15:46] <seb128>  dbus : Depends: libdbus-1-3 (= 1.12.16-2ubuntu1) but 1.12.14-1ubuntu2 is to be installed
[15:47] <seb128> that doesn't seem like it has to do with the dbus update right?
[15:52] <vorlon> seb128: that should be fixable with an --all-proposed retry; we saw that last week and it has to do with our pins not doing :amd64 on the i386 runners
[15:52] <seb128> vorlon, k, let me try that, thx
=== persia_ is now known as persia