[04:32] <pitti> @pilot out
[04:32] <pitti> (whoops, forgot to reset on Friday)
[04:32] <pitti> Good morning
[04:37] <jbicha_> pitti: good morning, have you seen bug 1614820 ?
[04:38] <pitti> jbicha_: hey, good morning! I saw it fly by, just haven't looked at it yet (ETIME, sorry)
[04:39] <jbicha> ok, maybe next release cycle then
[04:48] <pitti> jbicha: it would be really hard to avoid generating the /var/crash/ files, but merely not reporting them should be fairly straightforward in apport-gtk?
[04:48] <pitti> jbicha: i. e. this is just checking for that gsettings key?
[04:50] <pitti> org.gnome.desktop.privacy report-technical-problems false
[04:50] <pitti> jbicha: but why is this off by default?
[04:50] <pitti> jbicha: we certainly don't want that
[04:52] <jbicha> we can ship a gsettings override, perhaps in apport itself, for that
[04:52] <pitti> jbicha: not in apport, that would be rude (changing defaults of some other package)
[04:53] <jbicha> the package is gsettings-desktop-schemas
[04:53] <jbicha> we have lots of overrides in ubuntu-default-settings and ubuntu-gnome-default-settings but some people don't have those installed
[04:53] <jbicha> (ubuntu-settings)
[04:54] <jbicha> the only thing actually using that key right now I believe is Fedora's abrt so it doesn't hurt anything to set that key how we want it
[04:57] <pitti> jbicha: another concern is that we already have such a setting somewhere ("Send error reports to Canonical")
[04:57] <pitti> so that ^ one should move to this new official key
[04:57] <pitti> I followed up to the bug with a summary
[05:04] <jbicha> pitti: the gsettings key is from update-notifier so maybe that part of the bug doesn't need any apport changes
[05:05] <jbicha> but the other part of the bug is that GNOME expects the bug reporting service to run a org.freedesktop.problems.daemon dbus service, what do you think about that?
[05:11] <pitti> jbicha: apport isn't a daemon, what should this  do?
[05:11] <pitti> and what happens if it's not there?
[05:12] <jbicha> if it's not there, GNOME doesn't show the on/off switch to report bugs in Intial Setup and gnome-control-center's Privacy pages
[05:13] <jbicha> we could run a service that does nothing (that works) or we could patch the 2 apps to skip checking for that service
[05:32] <jbicha> I guess patching the apps would be better if there's no reason otherwise for apport to listen on dbus
[05:59] <pitti> rharper, smoser: FYI, netplan 0.10 just landed in y, with support for vlan
[06:00] <pitti> mwhudson, rharper, smoser: I'm going to look into wifi with networkd first (blocking ogra), is there anything else which is blocking you wrt. netplan?
[06:16] <cpaelzer> good morning
[07:15] <mwhudson> pitti: if you could spend 5 mins looking at https://github.com/snapcore/snapd/pull/1765 that'd be great
[07:16] <mwhudson> pitti: but i am off sick _and_ EOD so no hurry :)
[07:21] <LocutusOfBorg> jbicha, hi, do you plan to look at kido?
[07:22] <LocutusOfBorg> I see some upstream activity
[07:30] <jbicha> LocutusOfBorg: the best I came up with was filing bug 1617835 but if you can do better, go ahead
[07:32] <LocutusOfBorg> jbicha, fcl is fixed in Debian I see
[07:32] <LocutusOfBorg> let me see
[07:35] <LocutusOfBorg> it might be trivial
[07:46] <Saviq> pitti, morning, could I ask you to restart the last missing test in https://requests.ci-train.ubuntu.com/static/britney/ticket-1864/landing-067-xenial/excuses.html - it seems to have disappeared - and also https://requests.ci-train.ubuntu.com/static/britney/ticket-1864/landing-067-yakkety/excuses.html - not sure what made it uninstallable there
[07:59] <pitti> mwhudson: ugh, get well soon!
[08:00] <pitti> Saviq: sorry, had to kill some running tests due to cloud maintenance, will restart
[08:05] <Saviq> tx
[08:50] <ogra_> pitti, nothing else for now ...
[08:50] <ogra_> (we dont have networkd on the images though)
[08:51] <ogra_> (and i dont see it in the xenial archive)
[08:52] <pitti> ogra_: sure you do
[08:52] <pitti> it's in the systemd package :)
[08:52] <ogra_> ah, it doesnt have its own binary package ?
[08:52]  * ogra_ kind of expected that 
[09:48] <gb_mks> hello
[09:49] <gb_mks> I found a bug related in the package "click-review". Can anyone help me to solve it? https://bugs.launchpad.net/click-reviewers-tools/+bug/1617288
[09:57] <Saviq> pitti, hey, we're trying to get to grips with unity8 failures in britney, we've a bunch of flaky fixes in store, but the most common issue these days seems to be a time out, how long is the timeout on autopkgtests in britney by default? from looking at timestamps, it seems to be 3h - a passing run of unity8 seems to be between 2h and 2h54m (even though http://autopkgtest.ubuntu.com/packages/u/unity8/yakkety/amd64/ says 5h33m, but that seems to be some
[09:57] <Saviq>  delay outside of the test run itself?)
[09:58] <pitti> Saviq: right, the default timeout is 10,000s, i. e. roughly 2:50 hours
[09:58] <pitti> Saviq: right, lcy01 has been very unstable (should be fixed now), so some tests were attempted several times
[09:58] <Saviq> yup, that sounds about right
[09:59] <Saviq> pitti, is it possible to increase the time out for unity8?
[09:59] <pitti> Saviq: but these cloud failures should not appear as test failures, they get auto-retried until it finishes
[09:59] <Saviq> I can easily imagine it going over the 2:50h mark if the system load is higher, for example
[09:59] <pitti> Saviq: it is, if they legitimately take that long
[09:59] <pitti> so if they don't just hang eternally on something
[10:00] <pitti> Saviq: does that affect all arches?
[10:00] <Saviq> pitti, we only claim victory on those on amd64 and i386, and both sometimes go over the 2h50m limit
[10:01] <Saviq> pitti, it would go down considerably if they were run in parallel
[10:01] <pitti> Saviq: qmluitests.sh seems to need around 1:45 h, well below the 2:50 h limit
[10:01] <Saviq> because there's at least some time spent in those tests waiting (we're improving that now, too)
[10:02] <pitti> Saviq: do you actually see such a timeout in http://autopkgtest.ubuntu.com/packages/u/unity8/yakkety/amd64/ ? I don't
[10:02] <Saviq> pitti, I think it depends a lot on the load, https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-vivid-ci-train-ppa-service-landing-092/vivid/i386/u/unity8/20160822_110521@/log.gz
[10:02] <pitti> the failures there are pretty fast
[10:03] <Saviq> pitti, I've only seen those on PPA tests, couldn't find any example on proposed migration
[10:03] <Saviq> lemme have a good look again
[10:03] <pitti> Saviq: so this might rather be vivid vs. yakkety?
[10:03] <pitti> Saviq: anyway, I can bump it, but I'd really not do it if these are eternal hangs
[10:03] <pitti> these are blocking the infra long enough already
[10:05] <Saviq> pitti, we have one potential example of an eternal hang there, we're working on fixing that now, too - but it's tricky to say it really is if we're getting timeouts for other reasons, too
[10:05] <Saviq> pitti, about parallel, do the test nodes have more than one core?
[10:06] <pitti> Saviq: normally not
[10:06] <pitti> Saviq: we can mark it as "big test" and give it 4 cores and more RAM, if that helps to speed up the test considerably, i. e. if it actually *can* run in parallel
[10:07] <Saviq> pitti, they do run in parallel in our CI
[10:07] <pitti> Saviq: the tradeoff is that they are much more likely to fail due to cloud capacity issues
[10:07] <pitti> Saviq: so if they automatically use more available cores, I can add it to that list
[10:08] <Saviq> pitti, we rely on DEB_BUILD_OPTIONS=parallel, is that going to be set?
[10:08] <pitti> yes, that happens automatically
[10:08] <Saviq> pitti, I'd say let's try that
[10:08] <pitti> Saviq: oh, is the autopkgtest a package build?
[10:08] <Saviq> pitti, no
[10:08] <Saviq> it's 1300 UI tests
[10:08] <pitti> D_B_O is only set for builds, not for tests
[10:09] <pitti> as this is a dpkg-buildpackage specific thing
[10:09] <Saviq> hmm, bug #1399177 ?
[10:09] <pitti> tests should ask nproc or /proc/cpuinfo etc.
[10:09] <Saviq> ah ack
[10:09] <Saviq> so builds but within adt-run
[10:09] <Saviq> still
[10:09] <Saviq> we'll fix that then
[10:09] <pitti> eek, indeed
[10:10] <Saviq> pitti, let's mark unity8 big, then, and I'll land a fix to the test script to talk nproc
[10:10] <pitti> Saviq: is it really necessary to build the package for running the tests?
[10:11] <Saviq> pitti, we're not building the package
[10:11] <Saviq> we're building a few mocks
[10:11] <pitti> Saviq: also, the build doesn't happen via "Restrictions: build-needed" by autopkgtest itself, but the test calls dh_auto_configure etc., so it's manually building the package without dpkg-buildpackage
[10:11] <Saviq> pitti, it's not building the whole thing, only some mocks
[10:12] <Saviq> but yes, we're doing away with that too
[10:12] <pitti> ah, ok
[10:12] <Saviq> we'll package those mocks soon
[10:12] <pitti> Saviq: so, back to the question: will any of this actually use more than one core if they are available?
[10:13] <Saviq> pitti, not right now, if adt-run doesn't set D_B_O parallel, I'll have to fix the test to do that from nproc then
[10:14] <Saviq> so maybe it doesn't make sense to mark it big yet
[10:14] <Saviq> to not block the infra
[10:15] <Saviq> pitti, can we increase the time out to 3h30m or so for now, it should give us a bit more info on whether we have a real issue or not
[10:16] <Saviq> and I'll work on getting nproc in and we'll mark unity8 big after that's done
[10:16] <pitti> Saviq: I can set it to 40,000 s by adding it to the "long_tests" list (i. e. roughly 12 h)
[10:17] <Saviq> pitti, right, if I see any time out there then, we'll know it's our fault
[10:17] <Saviq> that would work
[10:19] <pitti> Saviq: ok, rolled out that change
[10:19] <Saviq> pitti, thanks, I'll let you know how we're doing
[10:19] <pitti> ack
[10:44] <mardy> pitti: hi! a new version of gnome-control-center-signon has landed in yakkety, so hopefully the version number is now consistent
[10:44] <mardy> pitti: (talking about bug 1565772)
[11:20] <LocutusOfBorg> jbicha, kido is good
[11:20] <LocutusOfBorg> fcl too, assuming somebody removes the armhf binary :)
[11:22] <pitti> mardy: thanks! I'll mark it as v-needed  (dropping v-failed) once LP comes back (has been down for me in the last 10 mins)
[11:23] <mardy> pitti: OK, thanks
[12:34] <smoser> pitti, we do need bonds.
[12:36] <ogra_> james bonds ?
[12:58] <pitti> smoser: ok, I have that on the list for early September
[13:48] <kenvandine> pitti, ping
[13:48] <kenvandine> pitti, we're about ready to land some work in libertine that makes it build depend on content-hub, which depends on ubuntu-app-launch... which of course depends on upstart :)
[13:49] <kenvandine> so we need the libertine binaries to be removed for s390x in yakkety
[13:50] <kenvandine> pitti, can you please help out with that?
[13:53] <dobey> omg circular deps
[13:58] <pitti> kenvandine: removed; AFAICS the reverse dependencies of libertine shoudl already be removed
[13:58] <kenvandine> pitti, thanks!
[13:59] <kenvandine> ChrisTownsend, ^^
[14:00] <ChrisTownsend> pitti: kenvandine: Thanks!
[14:20] <jonathon> Is it possible to get a package update into universe? The SRU wiki page doesn't mention universe (there's a link to an anchor from the MOTU page but it's not there any more).
[14:20] <pitti> jonathon: there is no difference wrt. the policy, i. e. "yes"
[14:25] <jonathon> Right-o, thank you. I'll read through the pages a few more times. :)
[14:55] <rbasak> infinity: are you chairing the DMB meeting in five minutes?
[14:56] <rbasak> BenC: around?
[15:00] <rbasak> !dmb-ping
[15:10] <pitti> awe: yay, I read the NM 1.4 announcement yesterday, seems our ofono patches are upstream now? congrats!
[15:11] <ogra_> woah !
[15:11] <awe> thanks pitti!
[15:11] <pitti> awe: Debian already has 1.4, so merge o'clock soon?
[15:11] <awe> hehe
[15:11]  * awe hopes there are no dbus interface changes
[15:11] <pitti> awe: yeah, "Canonical contributed ... ofono support" was a nice read there :)
[15:11] <ogra_> the result of years of work ....
[15:11] <awe> indeed
[15:12] <pitti> awe: allegedly the API has stayed very stable, even 1.2 plugins still work with NM 1.4
[15:12] <awe> abeato got a nice mention as well for his statistics API
[15:12] <awe> pitti, yes... that's pretty much true, although the move to gbus had some unexpected side-effects
[15:13] <awe> also, there's still a bit of code that didn't get merged upstream
[15:13] <awe> so we'll still need to carry some patches
[15:14] <awe> but it was a good start
[15:14] <awe> and hopefully we can continue to push more code to them
[15:37] <cpaelzer> hi, anybody here knows how/where I should reach out to get s390x enabled in an ppa on LP ?
[16:02] <attente> hi, i'm getting this debootstrap error: "chroot: cannot change root directory to '/home/william/tmp/root': Operation not permitted"
[16:03] <attente> this is when running it with fakeroot in my home directory
[16:03] <attente> is there a reason why debootstrap needs to chroot here?
[16:07] <attente> is there a better way than using fakeroot?
[16:27] <jonathon> cpaelzer: #launchpad might worth a look?
[16:35] <dobey> attente: sudo?
[16:48] <attente> dobey: trying to do this unprivileged in my home
[16:55] <ogra_> attente, wont work, deboostrap needs to create device nodes ... you can try fakechroot ... if you actually like cans of worms
[16:56] <ogra_> (or just download an ubuntu-base tarball ;) instead of building yourself )
[16:57] <dobey> yeah, download the preinstalled tarball then
[16:58] <attente> where is the tarball? i'll try that
[17:02] <ogra_> http://cdimage.ubuntu.com/ubuntu-base/releases/xenial/release/ or http://cdimage.ubuntu.com/ubuntu-base/daily/current/
[17:02] <ogra_> depending what you want
[19:32] <elbrus> ginggs_: thanks (unfortunately the autopkg fails on ci.debian.net and I don't know why, as it works on my computer)
[19:34] <elbrus> here it doesn't ask the password and that is correct. however on ci.d.n it does ask and fails because the isn't a valid answer at all
[19:35]  * elbrus shakes his head in disbelief and will probably need to upload a package with more debugging output... but doesn't know what output would be good.... mysql -vvv or something
[19:41] <ginggs_> elbrus: yw and good luck with the autopkg stuff