[00:09] <foli> The Canonical data centre firewall maintenance is done now.
[00:10] <sarnold> thanks foli :)
[06:13] <pitti> xnox, stgraber, barry: a bit complicated -- we must use lxd for armhf as we run them on arm64 cloud instances and need the "remote" feature; and s390x isn't in scalingstack yet, so we only have that old setup
[06:13] <pitti> but there is no principal reason why s390x couldn't move to lxd
[06:13] <pitti> (i. e. that's just historical)
[06:16] <wgrant> pitti: You could also use actual armhf nova instances, though it's not quite as simple.
[07:06] <pitti> wgrant: I played around with direct kernel boot some time ago, but back then there were still some bugs/config issues that broke that
[07:07] <pitti> if it works now, that'd be nice of course, we could run kernel tests
[07:07] <pitti> but anyway, s390x was promised to get into scalingstack, so I never bothered to move them to lxd
[07:12] <wgrant> pitti: Yep, it's happening Soon™.
[07:28] <rbasak> mapreri: I know you're waiting on inkscape PPU. Is there anything else for you still pending?
[07:29] <rbasak> I have an action "rbasak to get mapreri's PPU additions done by the TB" but the TB has already done sbuilder and libreoffice-dictinataries I see. I'm not sure if there's anything else.
[08:19] <mapreri> rbasak: No other requests pending, thanks.  (OTOH I wonder whether, given the apparent complexity of getting such rights I should ask also for the other 2 packages that I maintain which are in main, "just because" and without any particular need)
[08:22] <rbasak> mapreri: now that I understand it takes only one DMB member, it's one DMB approval and one TB action. We're also working on smoothing the DMB request -> TB process.
[08:22] <mapreri> That's my perception now too.
[08:24] <tsdgeos> sil2100: can you click https://autopkgtest.ubuntu.com/request.cgi?release=zesty&arch=i386&package=unity8&trigger=unity8%2F8.15%2B17.04.20170131.1-0ubuntu1 (unity8 rebuild) for us?
[08:24] <sil2100> tsdgeos: sure
[08:24] <tsdgeos> sil2100: appreciated :)
[08:25] <mapreri> rbasak: btw, "Is the DMB asking for too much from applicants before granting core dev and/or MOTU?" => No, the requests are just fine, don't reduce them.
[08:25] <tsdgeos> got bunch of flacky tests
[08:25] <mapreri> (imho)
[08:25] <mapreri> That just a so weird corner case.
[08:25] <sil2100> Test request submitted. <- yw ;)
[08:26] <tsdgeos> rbasak: not sure if totally related to your case or not, but it's also a bit "weird" that I as an employee unity8 developer can submit unity8 in bileto to land and it will land, but if like now a flacky test fails, i can't press the "retry" button
[08:27] <mapreri> tsdgeos: Isn't that a case already covered by PPU?
[08:28] <mapreri> Is just that you're not going to upload directly to the archive because you have your own "deployment" pipeline
[08:29] <rbasak> tsdgeos: that's solely an ACL issue I think. Technical, not organisational.
[08:29] <rbasak> tsdgeos: perhaps bileto should grow a feature to allow you to do that.
[08:29] <tsdgeos> mapreri: maybe, if i knew what PPU means :D
[08:30] <tsdgeos> rbasak: that makes some sense i guess
[08:31] <mapreri> tsdgeos: => that's probably a sign that you shouldn't apply for that then :) - (and instead autopkgtests/bileto grow something)
[08:31] <tsdgeos> i'll try to talk to robru
[08:31] <mapreri> tsdgeos: https://wiki.ubuntu.com/UbuntuDevelopers#Per-package_Uploaders
[08:31] <mapreri> (FYI)
[08:31] <tsdgeos> mapreri: tx, i tried googleing for it and only could find people's wiki/applications for it
[09:02] <rbasak> stgraber: thank you!
[09:02] <rbasak> mapreri: you should be done.
[09:06] <mapreri> \o/
[09:06] <mapreri> rbasak: thank you!
[09:07] <mapreri> rbasak: FYI, I'm subscribed to the tech board ML.
[11:34] <Mirv> xnox: umbrello against s390x seems to be in infinite loop http://autopkgtest.ubuntu.com/running#pkg-umbrello eg against my qtbase-opensource-src-gles/5.7.1+dfsg-2ubuntu3~2 it has started over numerous time without anyone specifically triggering it. so it's always left at "Test in progress" http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#qtbase-opensource-src-gles
[11:35] <Mirv> I've seen the Running for time being reset today least three times
[11:35] <xnox> Mirv, fun. However I don't have access to the infra. Try Laney and/or barry
[11:36] <Mirv> xnox: thanks for highlighting.
[11:36] <xnox> no problem.
[11:39] <Laney> mmm
 failure: (down) ['cp', '-r', '--preserve=timestamps,links', '/data/adttmp/autopkgtest-virt-lxc.shared.2l76ah7r/downtmp/umbrello-16.12.1', '/data/adttmp/autopkgtest-virt-lxc.shared.2l76ah7r/downtmp/build.8Xe/umbrello-16.12.1'] failed (exit status 1, stderr "cp: error writing '/data/adttmp/autopkgtest-virt-lxc.shared.2l76ah7r/downtmp/build.8Xe/umbrello-16.12.1/obj-s390x-linux-gnu/unittests/testpythonwriter': Cannot allocate memory\n")
[12:17] <Laney> Feb 02 00:41:08 aupkg01 kernel: cp invoked oom-killer: gfp_mask=0x24000c0, order=0, oom_score_adj=0
[12:17] <Laney> wtf
[12:39] <pitti> Laney: must be a helluva file :)
[12:41] <Laney> pitti: it passed before a few times http://autopkgtest.ubuntu.com/packages/u/umbrello/zesty/s390x
[12:41] <Laney> :(
[13:55] <zul> doko: ping python-murano-pkg-check?
[14:32] <ricotz_> why is 15.04/Vivid still marked as support on launchpad?
[14:34] <mdeslaur> ricotz_: it's used by the phone, if we deactivate it on launchpad we can't build packages for the phone anymore
[14:35] <ricotz_> mdeslaur, I see, quite a weird situation then
[14:35] <mdeslaur> ricotz_: yes, launchpad needs to be fixed to be able to mark a release as unsupported without deactivating it
[14:36] <mdeslaur> ricotz_: but this was only supposed to be temporary
[14:37] <ricotz_> mdeslaur, ok, but one should not be able to build things for it in random ppas/recipes
[14:38] <cjwatson> We don't really mind hugely if people can.
[16:15] <jgrimm> rbasak, thanks for pointing out test log history, indeed dogtag-pki has been failing for long time, unrelated to merge. http://autopkgtest.ubuntu.com/packages/d/dogtag-pki/zesty/amd64
[16:17] <nacc> jgrimm: right it's realted to tomcat, iirc
[16:17] <nacc> jgrimm: and 'known'
[16:18] <nacc> tjaalton: --^ iirc was looking at it
[16:19] <greyback> Hi folks, migration of https://bileto.ubuntu.com/#/ticket/2404 from proposed failed again, we've a single flaky test on i386. It's something we've struggled to fix, as we can't reproduce it anywhere except on britney
[16:19] <jgrimm> nacc, cool thanks.. context was that it showed up in the list of regressions on latest nspr upload
[16:19] <jgrimm> nacc, good to know what its actually attributed to tho!
[16:20] <nacc> jgrimm: right, probably unrelated
[16:20] <jgrimm> thanks sir
[16:28] <barry> doko, caribou o/
[16:29] <caribou> barry: doko: o/
[16:29] <caribou> barry: doko: to summarize, trusty & xenial builds using the release's gcc don't show any sensible differences
[16:30] <caribou> (trusty & xenial builds in a schroot using the release's gcc)
[16:30] <barry> caribou: that's very interesting, and mostly what i'd expected.  i just couldn't find any upstream python change that could have affected performance (but there are a lot of changes between .6 and .12)
[16:30] <caribou> I'm now re-running the initial tests (i.e. using the latest gcc in trusty/xenial) to verify the previous round of tests
[16:32] <caribou> doko: the only compiler difference I noticed b/w trusty's 4.8 and xenial's 5.3 is the addition of -fstack-protector-strong in Xenial
[16:32] <caribou> and -Wdate-time but that shouldn't matter
[16:32] <doko> caribou: what is "release's gcc"?
[16:32] <caribou> doko: the one in trusty/main (not the one in -updates or -security)
[16:32] <doko> ta
[16:38] <caribou> doko: barry:  I'll let you know once I get the new set of results (most probably tomorrow)
[16:38] <barry> caribou: cool.
[16:40] <Laney> Mirv: xnox: I reverse engineered pitti and now umbrello passes :-)
[16:40] <xnox> Laney, can you clone or fork pitti too?
[16:41] <Laney> I think only his wife has that CAP
[16:42] <xnox> latency is too large on that CAP
[17:17] <tjaalton> jgrimm, nacc: yes, tomcat 8.5 broke dogtag, and is blocking a lot of updates. 8.5 should be removed from proposed and blocked for now
[17:18] <nacc> tjaalton: i assume we need an AA to do that?
[17:19] <tjaalton> yep
[17:31] <jgrimm> tjaalton, thank you!
[18:30] <GunnarHj> bdmurray: Thanks for approving my yakkety upload at bug #1655036! Any chance you have a couple of minutes to sponsor the xenial debdiff at that bug? xenial is more important, and I don't have the permission yet.
[18:30] <GunnarHj> https://lists.ubuntu.com/archives/devel-permissions/2017-January/001014.html
[18:32] <bdmurray> GunnarHj: I left the tab open and will try and do it today
[18:33] <GunnarHj> bdmurray: Thanks, crossing my fingers. :)