=== cpaelzer__ is now known as cpaelzer
cpaelzerit seems on d/t/control you can't restrict the @ wildcard with architectures like  Depends: @ [amd64 s390x], @builddeps@, ethtool07:41
cpaelzerall I want is to only run it on those two and not on any other arches07:41
cpaelzerit feels like this must be easy and common, but I haven't seen a great and easy "tag for architectures that it should run" yet07:41
cpaelzerI might have been missing it all the years, hints welcome :-)07:42
infinitycpaelzer__: Why shouldn't it run for all arches?  If it's known to fail on others, then it'll fail, so what?08:02
=== cpaelzer__ is now known as cpaelzer
cpaelzerinfinity: yes it is known to fail on other arches08:03
cpaelzerinfinity: the package has many tests and just one would have that "fails on some arches"08:04
infinitycpaelzer: Right, we don't generally want to hide problems by skipping testsuites where they fail.08:04
cpaelzerI'd want to have the coverage of the other tests that work well on all arches08:04
cpaelzerand these extra tests that have limited arches run only on those known to work08:04
infinitycpaelzer: Ahh, if the goal is to run all the "good" tests, just wrap the bad one in a dpkg-architecture check?08:04
cpaelzerI have doen so years ago for DPDK, but I wondered if there is anything new08:05
cpaelzerbetter than if dpkd --print-architecture ...08:05
infinityFrom my POV, I wouldn't want arch-restriction semantics in debian/tests/control, cause it would encourage its use for evil. :P08:05
infinityBut that's just my opinion.08:06
cpaelzerhehe, maybe that is the reason it isn't there08:06
cpaelzerwill do a less comfortable semi-manual arch check for this special case then ...08:06
cpaelzerthanks 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:08
infinitycpaelzer: 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:13
infinitycpaelzer: 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:14
cpaelzerack to that as a vision for autopkgtest.u.c08:22
seb128vorlon, 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 summary08:31
ricotzseb128, hi :), is there a list of packages which will keep their i386 builds?08:33
seb128ricotz, hey, yes, https://people.canonical.com/~ubuntu-archive/packagesets/focal/i386-whitelist08:35
seb128ricotz, it's built according to the feedback given in https://discourse.ubuntu.com/t/community-process-for-32-bit-compatibility/1259808:35
seb128ricotz, np!08:35
ricotzseb128, looks like this whilelist doesn't apply to PPAs?08:59
cjwatsonThe whitelist applies to PPAs09:02
infinitycjwatson: It does?  Without a toggle?09:02
ricotzcjwatson, ok, I see "vala" is in the list, but https://launchpad.net/~vala-team/+archive/ubuntu/daily/+packages09:02
cjwatsonThere is currently no toggle available.  There probably should be09:02
infinitycjwatson: Cause a common use-case of PPAs is to build stuff that doesn't exist in PRIMARY, which the whitelist wouldn't allow.09:02
cjwatsonSomebody who needs such a toggle should file a bug please09:03
infinityricotz: vala != vala-git.09:03
ricotzsorry, the is vala-git for some convenient reasons09:03
cjwatsonricotz: But there is no ... that09:03
infinityricotz: The whitelist is source package.09:03
infinitycjwatson: Filing.09:04
infinitycjwatson: 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
infinityMaybe under the arch selection makes as much sense, though.,09:05
infinitycjwatson: LP: #185506909:09
ubottuLaunchpad bug 1855069 in Launchpad itself "PPAs should be able to toggle using PRIMARY's arch-{white,black}lists" [Undecided,New] https://launchpad.net/bugs/185506909:09
rbalintseb128, already did https://github.com/df7cb/newpid/pull/209:53
seb128rbalint, 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:58
rbalintseb128, this is the repo listed in Vcs-Git09:59
seb128rbalint, ah ok, perfect then, thanks!09:59
seb128tjaalton, 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 there10:19
tjaaltonseb128: me neither10:29
seb128tjaalton, do you know who would know? we need that sorted out one way or another10:29
tjaaltonsame pocl used on both focal and debian10:30
tjaaltonfailed on debian too but because of something else10:30
ahasenackhello, 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:50
ahasenackis this a case where the i386 package has to be removed, as per vorlon's email to ubuntu-devel a few days ago?12:51
ahasenackoh, that email said to use #ubuntu-release12:53
=== cpaelzer__ is now known as cpaelzer
=== ricab is now known as ricab|lunch
coreycbdoko: 20.04 won't have python 3.6 will it? I don't think so but figured I'd check.14:34
cjwatsonEven 19.10 didn't have Python 3.6.14:42
cjwatsonIndeed it was removed in 19.04.14:42
dokocoreycb: ^^^14:53
coreycbdoko: cjwatson: yeah sorry not thinking14:53
dokocoreycb: and we are trying to drop 3.7 in 20.0414:55
dokocoreycb, 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
coreycbdoko: so 20.04 will be 3.8 only?14:56
dokoand likely 2.714:56
coreycbdoko: ok14:56
coreycbdoko: thanks. we could run regression with 2.7.17 in -proposed if needed.14:59
dokocoreycb: 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 urgent15:01
coreycbdoko: thanks i'll keep an eye out for it in proposed15:01
seb128tsimonq2, 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 translations15:31
ubottuError: launchpad bug 0 not found15:31
vorlonseb128: 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:33
seb128vorlon, liborcus would be nice, it's one of the blocker for glibc and others15:38
vorlonfor glibc?15:38
vorlonI'll look at liborcus15:39
seb128vorlon, according to https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses_by_team.html#desktop-packages yes15:39
seb128 liborcus blocking glibc (2.30-0ubuntu2 to 2.30-0ubuntu3) for 4 days15:39
seb128(the test issue is fixed in -3 which isn't mgirating because of i386)15:39
vorlonseb128: blocking via autopkgtest failure; if the test is broken in -3 we should be badtesting that?15:39
vorlonin -2, sorry15:40
seb128well it's fixed in -3 so I guess we could also retry with that added to the trigger= list15:40
seb128but ideally the fixed version would just migrate15:40
vorlonthat ideal is the slow path in general for unblocking packages15:41
=== ricab|lunch is now known as ricab
seb128vorlon, right, I'll just retry with the trigger for now, going through the rdepends list indeed doesn't seem trivial :-/15:45
seb128vorlon, oh, also, can you make dbus migrate? the only remaining blocker is http://autopkgtest.ubuntu.com/packages/s/systemd/focal/i38615:46
seb128 dbus : Depends: libdbus-1-3 (= 1.12.16-2ubuntu1) but 1.12.14-1ubuntu2 is to be installed15:46
seb128that doesn't seem like it has to do with the dbus update right?15:47
vorlonseb128: 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 runners15:52
seb128vorlon, k, let me try that, thx15:52
=== persia_ is now known as persia

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