[04:32] @pilot out === udevbot changed the topic of #ubuntu-devel to: Xenial (16.04.1) Released! | Archive: feature freeze | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-xenial | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: [04:32] (whoops, forgot to reset on Friday) [04:32] Good morning [04:37] pitti: good morning, have you seen bug 1614820 ? [04:37] bug 1614820 in apport (Ubuntu) "Respect gsettings org.gnome.desktop.privacy report-technical-problems" [Wishlist,New] https://launchpad.net/bugs/1614820 === jbicha_ is now known as jbicha [04:38] jbicha_: hey, good morning! I saw it fly by, just haven't looked at it yet (ETIME, sorry) [04:39] ok, maybe next release cycle then [04:48] 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] jbicha: i. e. this is just checking for that gsettings key? [04:50] org.gnome.desktop.privacy report-technical-problems false [04:50] jbicha: but why is this off by default? [04:50] jbicha: we certainly don't want that [04:52] we can ship a gsettings override, perhaps in apport itself, for that [04:52] jbicha: not in apport, that would be rude (changing defaults of some other package) [04:53] the package is gsettings-desktop-schemas [04:53] we have lots of overrides in ubuntu-default-settings and ubuntu-gnome-default-settings but some people don't have those installed [04:53] (ubuntu-settings) [04:54] 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] jbicha: another concern is that we already have such a setting somewhere ("Send error reports to Canonical") [04:57] so that ^ one should move to this new official key [04:57] I followed up to the bug with a summary [05:04] pitti: the gsettings key is from update-notifier so maybe that part of the bug doesn't need any apport changes [05:05] 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] jbicha: apport isn't a daemon, what should this do? [05:11] and what happens if it's not there? [05:12] 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] 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] I guess patching the apps would be better if there's no reason otherwise for apport to listen on dbus [05:59] rharper, smoser: FYI, netplan 0.10 just landed in y, with support for vlan [06:00] 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] good morning [07:15] pitti: if you could spend 5 mins looking at https://github.com/snapcore/snapd/pull/1765 that'd be great [07:16] pitti: but i am off sick _and_ EOD so no hurry :) [07:21] jbicha, hi, do you plan to look at kido? [07:22] I see some upstream activity [07:30] LocutusOfBorg: the best I came up with was filing bug 1617835 but if you can do better, go ahead [07:30] bug 1617835 in kido (Ubuntu) "Please remove fcl 0.5.0-1 from yakkety-proposed" [High,New] https://launchpad.net/bugs/1617835 [07:32] jbicha, fcl is fixed in Debian I see [07:32] let me see [07:35] it might be trivial [07:46] 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] mwhudson: ugh, get well soon! [08:00] Saviq: sorry, had to kill some running tests due to cloud maintenance, will restart [08:05] tx === JanC is now known as Guest45177 === JanC_ is now known as JanC === carlo is now known as Guest67116 [08:50] pitti, nothing else for now ... [08:50] (we dont have networkd on the images though) [08:51] (and i dont see it in the xenial archive) [08:52] ogra_: sure you do [08:52] it's in the systemd package :) [08:52] ah, it doesnt have its own binary package ? [08:52] * ogra_ kind of expected that [09:48] hello [09:49] 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:49] Launchpad bug 1617288 in Canonical Click Reviewers tools "click-review assumes Ubuntu vendor" [Undecided,New] === zigo_ is now known as zigo [09:57] 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] delay outside of the test run itself?) [09:58] Saviq: right, the default timeout is 10,000s, i. e. roughly 2:50 hours [09:58] Saviq: right, lcy01 has been very unstable (should be fixed now), so some tests were attempted several times [09:58] yup, that sounds about right [09:59] pitti, is it possible to increase the time out for unity8? [09:59] Saviq: but these cloud failures should not appear as test failures, they get auto-retried until it finishes [09:59] I can easily imagine it going over the 2:50h mark if the system load is higher, for example [09:59] Saviq: it is, if they legitimately take that long [09:59] so if they don't just hang eternally on something [10:00] Saviq: does that affect all arches? [10:00] pitti, we only claim victory on those on amd64 and i386, and both sometimes go over the 2h50m limit [10:01] pitti, it would go down considerably if they were run in parallel [10:01] Saviq: qmluitests.sh seems to need around 1:45 h, well below the 2:50 h limit [10:01] because there's at least some time spent in those tests waiting (we're improving that now, too) [10:02] Saviq: do you actually see such a timeout in http://autopkgtest.ubuntu.com/packages/u/unity8/yakkety/amd64/ ? I don't [10:02] 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] the failures there are pretty fast [10:03] pitti, I've only seen those on PPA tests, couldn't find any example on proposed migration [10:03] lemme have a good look again [10:03] Saviq: so this might rather be vivid vs. yakkety? [10:03] Saviq: anyway, I can bump it, but I'd really not do it if these are eternal hangs [10:03] these are blocking the infra long enough already [10:05] 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] pitti, about parallel, do the test nodes have more than one core? [10:06] Saviq: normally not [10:06] 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] pitti, they do run in parallel in our CI [10:07] Saviq: the tradeoff is that they are much more likely to fail due to cloud capacity issues [10:07] Saviq: so if they automatically use more available cores, I can add it to that list [10:08] pitti, we rely on DEB_BUILD_OPTIONS=parallel, is that going to be set? [10:08] yes, that happens automatically [10:08] pitti, I'd say let's try that [10:08] Saviq: oh, is the autopkgtest a package build? [10:08] pitti, no [10:08] it's 1300 UI tests [10:08] D_B_O is only set for builds, not for tests [10:09] as this is a dpkg-buildpackage specific thing [10:09] hmm, bug #1399177 ? [10:09] bug 1399177 in autopkgtest (Ubuntu) "adt-run should parallelize builds as necessary by default" [Wishlist,Fix released] https://launchpad.net/bugs/1399177 [10:09] tests should ask nproc or /proc/cpuinfo etc. [10:09] ah ack [10:09] so builds but within adt-run [10:09] still [10:09] we'll fix that then [10:09] eek, indeed [10:10] pitti, let's mark unity8 big, then, and I'll land a fix to the test script to talk nproc [10:10] Saviq: is it really necessary to build the package for running the tests? [10:11] pitti, we're not building the package [10:11] we're building a few mocks [10:11] 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] pitti, it's not building the whole thing, only some mocks [10:12] but yes, we're doing away with that too [10:12] ah, ok [10:12] we'll package those mocks soon [10:12] Saviq: so, back to the question: will any of this actually use more than one core if they are available? [10:13] 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] so maybe it doesn't make sense to mark it big yet [10:14] to not block the infra [10:15] 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] and I'll work on getting nproc in and we'll mark unity8 big after that's done [10:16] Saviq: I can set it to 40,000 s by adding it to the "long_tests" list (i. e. roughly 12 h) [10:17] pitti, right, if I see any time out there then, we'll know it's our fault [10:17] that would work [10:19] Saviq: ok, rolled out that change [10:19] pitti, thanks, I'll let you know how we're doing [10:19] ack === hikiko is now known as hikiko|ln [10:44] pitti: hi! a new version of gnome-control-center-signon has landed in yakkety, so hopefully the version number is now consistent [10:44] pitti: (talking about bug 1565772) [10:44] bug 1565772 in gnome-control-center-signon (Ubuntu Yakkety) "[SRU] Allow plugins to decide which username to set on new accounts" [Critical,In progress] https://launchpad.net/bugs/1565772 [11:20] jbicha, kido is good [11:20] fcl too, assuming somebody removes the armhf binary :) [11:22] 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] pitti: OK, thanks === hikiko|ln is now known as hikiko === _salem is now known as salem_ [12:34] pitti, we do need bonds. [12:36] james bonds ? [12:58] smoser: ok, I have that on the list for early September === dpm is now known as dpm-afk === dpm-afk is now known as dpm [13:48] pitti, ping [13:48] 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] so we need the libertine binaries to be removed for s390x in yakkety [13:50] pitti, can you please help out with that? [13:53] omg circular deps [13:58] kenvandine: removed; AFAICS the reverse dependencies of libertine shoudl already be removed [13:58] pitti, thanks! [13:59] ChrisTownsend, ^^ [14:00] pitti: kenvandine: Thanks! [14:20] 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] jonathon: there is no difference wrt. the policy, i. e. "yes" [14:25] Right-o, thank you. I'll read through the pages a few more times. :) === kirkland` is now known as kirkland [14:55] infinity: are you chairing the DMB meeting in five minutes? [14:56] BenC: around? [15:00] !dmb-ping [15:00] bdmurray, BenC, cyphermox, infinity, micahg, rbasak, sil2100: DMB ping. === jcastro_ is now known as jcastro [15:10] awe: yay, I read the NM 1.4 announcement yesterday, seems our ofono patches are upstream now? congrats! [15:11] woah ! [15:11] thanks pitti! [15:11] awe: Debian already has 1.4, so merge o'clock soon? [15:11] hehe [15:11] * awe hopes there are no dbus interface changes [15:11] awe: yeah, "Canonical contributed ... ofono support" was a nice read there :) [15:11] the result of years of work .... [15:11] indeed [15:12] awe: allegedly the API has stayed very stable, even 1.2 plugins still work with NM 1.4 [15:12] abeato got a nice mention as well for his statistics API [15:12] pitti, yes... that's pretty much true, although the move to gbus had some unexpected side-effects [15:13] also, there's still a bit of code that didn't get merged upstream [15:13] so we'll still need to carry some patches [15:14] but it was a good start [15:14] and hopefully we can continue to push more code to them [15:37] hi, anybody here knows how/where I should reach out to get s390x enabled in an ppa on LP ? === salem_ is now known as _salem [16:02] hi, i'm getting this debootstrap error: "chroot: cannot change root directory to '/home/william/tmp/root': Operation not permitted" [16:03] this is when running it with fakeroot in my home directory [16:03] is there a reason why debootstrap needs to chroot here? [16:07] is there a better way than using fakeroot? === _salem is now known as salem_ [16:27] cpaelzer: #launchpad might worth a look? [16:35] attente: sudo? [16:48] dobey: trying to do this unprivileged in my home [16:55] attente, wont work, deboostrap needs to create device nodes ... you can try fakechroot ... if you actually like cans of worms [16:56] (or just download an ubuntu-base tarball ;) instead of building yourself ) [16:57] yeah, download the preinstalled tarball then [16:58] where is the tarball? i'll try that [17:02] http://cdimage.ubuntu.com/ubuntu-base/releases/xenial/release/ or http://cdimage.ubuntu.com/ubuntu-base/daily/current/ [17:02] depending what you want [19:32] ginggs_: thanks (unfortunately the autopkg fails on ci.debian.net and I don't know why, as it works on my computer) [19:34] 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 === SotK_ is now known as SotK [19:41] elbrus: yw and good luck with the autopkg stuff === acheronuk_ is now known as acheronuk === alexisb is now known as alexisb-afk