[01:20] <rnetocombr> 16.04.2 build delayed ?
[01:21] <jbicha> rnetocombr: yes, see https://lists.ubuntu.com/archives/ubuntu-release/2017-January/003998.html and https://wiki.ubuntu.com/XenialXerus/ReleaseSchedule
[01:23] <rnetocombr> jbicha: ok! thanks!
=== juliank_ is now known as juliank
=== giraffe is now known as Guest35314
[06:21] <pitti> rbasak: hmm, jackpot51 isn't here, but "isolate" is pretty much defined as "stop everything which is not part of the given target"
[06:21] <pitti> so this sounds like a case of YAFIYGI to me -- isolate isn't something which users should ever want to actually use...
[07:01] <lpotter> uyhjjjjjjjjjjj
[07:27] <fooctrl> did anyone have any success getting ubuntu working on macbook pro 2016 (with touch id)?
[09:08] <seb128> slangasek, hey, is there any reason you copied the yakkety SRU to -updates but not the xenial one on bug #1506427?
[09:08] <ubottu> bug 1506427 in ido (Ubuntu Xenial) "Using calendar with keys might cause Indicator-datetime to crash unity-panel-service" [Medium,Fix committed] https://launchpad.net/bugs/1506427
[09:09] <lpotter> sorry. cat meets keyboard
[09:34] <rbasak> pitti: any suggestion on what should be done instead for this? Bug 1576024.
[09:34] <ubottu> bug 1576024 in network-manager (Ubuntu) "Wifi "device not ready" after booting into OS for the 1st time" [Undecided,Confirmed] https://launchpad.net/bugs/1576024
[09:43] <happyaron> rbasak: we got some SRUs to nm and nm-applet, that should improve the situation a lot
[09:45] <rbasak> happyaron: are you referring to the root cause that jackpot51 isolated, or something else?
[09:45] <rbasak> I'm just trying to help out because he has proposed a fix that will probably work (or so it seems to me) but it may not be the right fix.
[09:46] <seb128> happyaron, reading the comment that bug seems specific and having to do with systemd integration in oem mode, so likely differently from the upstream code issues which make wifis sometime snot listed (which you likely refers to)
[09:46] <seb128> rbasak, ^
[09:46] <pitti> rbasak: I guess what you said -- find out who added that isolate call there
[09:47] <seb128> hey pitti, wie gehts?
[09:47] <happyaron> we have several reports that results into similar situation, but for systemd stuff no
[09:47] <seb128> what component is calling the isolate?
[09:47] <pitti> seb128: bonjour ! ça va bien, merci ! j'apprends javascript et angular maintenant
[09:47] <pitti> seb128: in bug 1576024
[09:47] <ubottu> bug 1576024 in network-manager (Ubuntu) "Wifi "device not ready" after booting into OS for the 1st time" [Undecided,Confirmed] https://launchpad.net/bugs/1576024
[09:48] <seb128> pitti, right, I read that, doesn't tell what is doing the systemctl isolate call, is that the oem tools?
[09:49] <pitti> supposedly, yes
[09:49] <Laney> what should it be doing there?
[09:50] <rbasak> pitti: OK, thanks
[10:19] <seb128> pitti, do you know what's going on there? https://autopkgtest.ubuntu.com/packages/postgresql-9.5/xenial/armhf
[10:21] <doko_> Laney: what does this mean in an autopkg test? autopkgtest for linux/blacklisted: i386: Regression
[10:21] <Laney> it means the package is blacklisted
[10:21] <pitti> seb128: supposedly coincides with moving from lxc to lxd; got fixed by https://anonscm.debian.org/cgit/pkg-postgresql/postgresql-common.git/commit/?id=fc40fc34 but this isn't in xenial yet
[10:31] <seb128> pitti, thanks, it looks like the xenial/krb5 current SRU is blocked by the postgrestql/autopkg issue, should that just be ignored then?
[10:31] <pitti> seb128: short term it can be ignored (the test succeeded, just that stderr spew), mid-term it would be good to SRU that p-common fix
[10:32] <seb128> pitti, k, thanks
[10:37] <seb128> SRU team, ^ you probably want to consider krb5/xenial as good to be copied to updates (if the autopkg issue is what is blocking it, it's old in the queue and verified but currently there is no clear communication about those issues, maybe it would be good to comment back on the corresponding bug when there is a blocker)
[10:37] <seb128> bdmurray, rbasak, sil2100, ^
[10:39] <doko_> Laney: just the i386 build?
[10:40] <Laney> doko_: Yeah, blacklists are per series and arch
[10:40] <Laney> It makes the test machines OOM and die
[10:40] <doko_> ok, ta
[10:51] <rbasak> seb128: commented in the bug.
[10:52] <rbasak> seb128: I'm happy to take their word for what they say; I'm just concerned that they're missing an entire class of use cases. If say they've considered it and are being careful about them, then that's fine.
[10:56] <seb128> rbasak, thanks, I don't know the specifics of that SRU but I noticed that a few didn't get copied over despite beeing aged+verified and it looks like some SRU team members at least don't copy over things that have autopkg issues listed but they don't say so either/comment on the bug and the uploaders don't get notified/notice so the updates get silently stucked forever
[10:56] <seb128> which is a process issue
[10:57] <seb128> would be good if the SRU team had a mailing list or some place for such discussions (or is there one but I just don't know about?)
[10:57] <rbasak> seb128: understood and agreed. I've noticed this too. When looking at releasing SRUs I keep having to comment to ask about any reported autopkgtest regressions. IMHO there should be an automatic comment in the bug if autopkgtest regressions are detected, so that the bug driver can comment instead of having to do yet another round trip.
[10:58] <rbasak> It would save the SRU team work as well, helping us process more quicker. A comment of "autopkgtest failure X is a regression because Y and therefore this SRU won't cause problems due to Z" would be really helpful.
[10:59] <rbasak> But that can only happen if the bug driver knows about it.
[10:59] <seb128> indeed
[11:00] <rbasak> I do try to look at the reported regressions and make my own determinations about false positives, but it is rather time consuming to have to look at so many, and sometimes I am not confident but the bug driver (whom I trust) is.
[11:12] <seb128> yeah, should be up to the uploader to follow up on those, not to the SRU team
[11:12] <seb128> which they would probably do if they were told that they need to investigate
=== _salem is now known as salem_
[14:11] <slangasek> seb128: probably just that the xenial SRU of ido was lost in the noise of all the stale unverified SRUs
[14:14] <seb128> slangasek, k, I though that since the bug was being handled all series would be looked at, but if you work from the queue and by serie I guess the workflow is different
[14:31] <kdub> what could cause dh_auto_build to not compile in parallel? (package is compat 9, so passing -O--parallel of course)
[15:22] <doko_> coreycb, barry: updated https://bugs.launchpad.net/ubuntu/+source/kombu/+bug/1656333 (this issue needs verification itself, didn't do that yet). The one outstanding issue is python-glanceclient
[15:22] <ubottu> Launchpad bug 1656333 in kombu (Ubuntu Trusty) "[SRU] Fix uuid shim in newer Python versions" [Undecided,Fix committed]
[15:22] <doko_> jamespage: ^^^
[15:24] <coreycb> doko_, thanks.  have a link to the new build output?
[15:25] <doko_> coreycb: http://qa.ubuntuwire.org/ftbfs/rebuilds/test-rebuild-20161216-updates-python2712-trusty.html  the old logs (failing ones) are overwritten
[15:26] <coreycb> doko_, thanks. i'll take a look at glanceclient
=== salem_ is now known as _salem
[23:58] <catbus1> Hi, I assume the 16.04 daily build will become 16.04.2 on Feb 2nd. Am I right? If so, if someone wants to test 16.04.2 before the release date, they can grab it from here: http://cdimages.ubuntu.com/ubuntu-server/xenial/daily/current/ right?
[23:58] <catbus1> As of now, it doesn't have 4.8 kernel yet.