[00:14] <doko> three more transitions finished. libgenome, libmsn, coinutils. good night
[02:54] <pitti> barry: hmm, and the last runs indeed succeed again -- http://autopkgtest.ubuntu.com/packages/p/pytables/
[02:55] <pitti> barry: so, nevermind
[02:56] <pitti> good .. almost morning
[02:58] <pitti> jdstrand: I haven't seen it before; isn't that test running as root? seems weird to not have permisisons
[02:58] <pitti> jdstrand: or is that some click --user mode?
[02:59] <pitti> jdstrand: ack, will look at the bug; not sure there's much that I can do on the autopkgtest side, but it seems for now we don't yet understand enough what happened
[07:18] <doko> pitti, kicad ... tried to update the stable branch, but this apparently must relate to the current trunk. can't find any reference to this flag
[07:18] <pitti> doko: http://pkgs.fedoraproject.org/cgit/kicad.git/tree/kicad.spec#n232 uses it as well, and it was recommended on the upstream bug
[07:19] <pitti> doko: err, Debian bug
[07:19] <pitti> doko: anyway, as noted in the pad this is waiting on apw's boost fix
[07:19] <pitti> then it can be retried
[07:32] <dholbach> good morning
[08:21] <kako> Hi, I'm wondering why I can't find the libt1-dev package for 15.04. Was the name changed? Is there an alternative? On a 14.04 I can find it by "dpkg -S /usr/include/t1lib.h" => libt1-dev, but on 15.04 I get no result. Is there no "libt1.(a|so)" for vivid?
[08:38] <infinity> kako: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=744881
[08:59] <kako> infinity: thanks, this is a answer... but now I must find out how to compile php without t1 :-(
[09:08] <infinity> kako: The same way it's configured in the distro?
[09:09] <infinity> kako: --without-t1lib
[09:19] <guest42315> dpkg: error processing archive /var/cache/apt/archives/unity-control-center_15.04.0+15.10.20150813-0ubuntu1_amd64.deb (--unpack):
[09:19] <guest42315>  trying to overwrite '/usr/share/man/man1/bluetooth-wizard.1.gz', which is also in package gnome-bluetooth 3.8.2.1-0ubuntu12
[09:19] <guest42315> dpkg-deb: error: subprocess paste was killed by signal (Broken pipe)
[09:20] <guest42315> on wily :/
[09:23] <mitya57> guest42315, it's 1484658, will be fixed soon
[09:24] <mitya57> bug 1484658
[09:24] <seb128> mitya57, do you handle the landing or should I?
[09:25] <mitya57> Just wanted to ask the same :)
[09:25] <mitya57> I can do it.
[09:26] <seb128> thanks
[09:30] <guest42315> mitya57, oh thanks :D
[09:30] <guest42315> \o/
[09:31] <mitya57> building in landing-023 now
[09:33] <mitya57> 2015-08-14 09:32:28,962 ERROR unity-control-center 15.04.0+15.10.20150813-0ubuntu1 is missing from the changelog, which has up to 15.04.0+15.10.20150805-0ubuntu1. Please sync destination version back to trunk.
[09:34] <mitya57> seb128, can I tell citrain to forcefully merge your upload to trunk?
[09:34] <seb128> yes
[09:34] <seb128> want me to do it?
[09:36] <seb128> seems you did, thanks
[09:37] <mitya57> Yes I did it.
[09:38] <tsdgeos> doko: is https://code.launchpad.net/~aacid/unity8/dropgcc49more/+merge/268047 correct? i think i've seen some other projects do this too
[09:38] <mitya57> Oh wait, why did it commit the indicator-bluetooth change to 15.04 branch?
[09:39] <doko> tsdgeos, yes
[09:39] <seb128> shrug
[09:39] <tsdgeos> doko: tx
[09:39] <seb128> mitya57, because works was from previous cycle and we didn't retarget :-/
[09:40] <mitya57> :(
[09:40] <mitya57> At least the branches aren't diverged so it's possible to push that commit to trunk.
[09:41] <seb128> right
[09:41] <mitya57> seb128, I'm not a member of ~indicator-applet-dev, can you do that?
[09:41] <seb128> k
[09:41] <mitya57> branch & push
[09:44] <seb128> mitya57, there, you go, https://code.launchpad.net/indicator-bluetooth
[09:44] <seb128> 15.04 back on r87
[09:44] <seb128> and trunk on 89
[09:45] <mitya57> seb128, thanks a lot
[09:45] <seb128> yw!
[09:46] <kako> infinity: yes, of course ;-). But what If I need the type 1 font functionality?
[10:03] <guest42315> No tool chain set from kit "Ubuntu Device (GCC armhf-ubuntu-sdk-15.04-vivid)".
[10:03] <guest42315> No tool chain set from kit "UbuntuSDK for i386 (GCC ubuntu-sdk-14.10-utopic)".
[10:03] <guest42315> ubuntu-sdk on wily
[10:06] <guest42315> Failed to parse '/usr/lib/x86_64-linux-gnu/qt5/qml/Ubuntu/Components/plugins.qmltypes'.
[10:06] <guest42315> Error: /usr/lib/x86_64-linux-gnu/qt5/qml/Ubuntu/Components/plugins.qmltypes:1106:39: Meta object revision without matching export.
[10:07] <guest42315> /usr/lib/x86_64-linux-gnu/qt5/qml/Ubuntu/Components/plugins.qmltypes:1125:39: Meta object revision without matching export.
[10:09] <sil2100> pitti: https://bugs.launchpad.net/langpack-o-matic/+bug/1484882 <- :)
[10:09] <sil2100> pitti: hey!
[10:09] <sil2100> pitti: I'll also request a manual langpack-o-matic run later today if that's not a problem - will you have a moment for that?
[12:37] <mterry> infinity, thanks for the NEW and presumably the rebuild presses on progressivemauve  :)
[12:39] <mterry> pitti, oh interesting about --v5 not being in Debian, thanks for the warning.  I am not very familiar with d-shlibmove
[12:39] <infinity> mterry: No rebuild presses, but if it was dep-wait, that clear automatically.
[12:40] <mterry> infinity, hrm, they were failures.  Some kind soul pressed some buttons
[12:45] <flexiondotorg> seb128, Regarding Blueman2. You mentioned a merge should be done. Do you mean a merge proposal for the just the debian packaging?
[12:50] <seb128> flexiondotorg, no, a merge
[12:50] <seb128> flexiondotorg, https://wiki.ubuntu.com/UbuntuDevelopment/Merging
[12:50] <flexiondotorg> seb128, Thanks for the docs.
[12:51] <seb128> yw
[12:51]  * flexiondotorg goes to have a read.
[12:51] <seb128> basically there are ubuntu changes to that package
[12:51] <seb128> so you can't drop them
[12:51] <seb128> you need to reapply them on top of the debian version
[12:52] <flexiondotorg> seb128, I understand that bit :-)
[12:52] <seb128> k, that's what a merge is
[12:52] <flexiondotorg> seb128, I need to learn the mechanics of merging.
[12:52] <seb128> take the debian version and reapply the ubuntu changes
[12:52] <seb128> your sync request was basically copying the debian version discarding ubuntu work
[12:52] <flexiondotorg> seb128, Understood.
[12:53] <infinity> flexiondotorg: The simplest mechanic is "debdiff debian_ver ubuntu_ver > ubuntu.diff" and then apply that diff to the new Debian.
[12:53] <infinity> Which takes some wiggling in the changelog.
[12:53] <infinity> Or, if it's a simple merge, MoM may have done it for you and you just need to check it.
[12:54] <flexiondotorg> infinity, seb128 Thanks for the info.
[12:54] <infinity> https://merges.ubuntu.com/b/blueman/
[12:54] <flexiondotorg> My concern is I am on Jury service right now. Very limited time on a computer. I don't know if I will have the oppotunity to do this work before next weeks feature freeze :-(
[12:54] <infinity> So, wasn't simple enough for MoM to get it right.
[12:55] <infinity> But the conflicts are likely easy to resolve by a human.
[13:07] <jdstrand> pitti: I spent about 5 hours digging into that bug yesterday and I'm quite puzzled-- it only happens under adt-run. there are steps to reproduce in the bug and how it doesn't reproduce in a schroot
[13:08] <pitti> sil2100: hey! (spotty now, in train)
[13:08] <jdstrand> are you able to reproduce? I can help speed up trying to reproduce if needed
[13:08] <pitti> mterry: d-shlibs> heh, nobody is :) it was my first encounter too
[13:08] <pitti> sil2100: I can do a manual run, for what?
[13:09] <pitti> jdstrand: hey! adt-run captures stdout and stderr into pipes, maybe that's related? /dev/pts sounds like that could be related
[13:10] <jdstrand> pitti: hello :)
[13:10] <jdstrand> well, it's weird
[13:10] <pitti> jdstrand: just a straw of bandwidth right now, and I spent the morning on g++ again, sorry
[13:11] <jdstrand> that's ok
[13:11] <pitti> jdstrand: I have the bug report now as a reminder
[13:11] <jdstrand> pitti: how easy is it to kick off an autopkgtest in jenkins for click-apparmor in wily?
[13:11] <jdstrand> pitti: basically, the severity will be somewhat less if it is only on a local schroot
[13:12] <jdstrand> pitti: but if jenkins can't run it, that is more important
[13:13] <pitti> jdstrand: rather hard, as we don't run Jenkins any more :)
[13:13] <pitti> jdstrand: more seriously, it's rather easy
[13:14] <pitti> jdstrand: requested
[13:14] <pitti> jdstrand: are you still an archive admin? then you can do it yourself too (https://wiki.ubuntu.com/ProposedMigration/AutopkgtestInfrastructure#Administration)
[13:14] <pitti> err, or I would have requested it if my ssh command hadn't failed, /me kicks VPN
[13:15] <jdstrand> pitti: I am (though not active in the traditional sense-- have the powers still for shuffling MIRs and security updates)
[13:15] <pitti> ok, done for realz
[13:15] <jdstrand> thank you
[13:15] <jdstrand> and haha on the jenkins bit :)
[13:15] <pitti> jdstrand: not "haha", it's a great relief :)
[13:15] <jdstrand> hehe
[13:15] <jdstrand> I just meant I actually laughed at your joke :)
[13:16] <pitti> jdstrand: (no worries - TGIF!)
[13:21] <jdstrand> pitti: fyi, not that it matters much, but I don't have access wo wendigo
[13:21] <jdstrand> s/wo/to/
[13:21] <pitti> jdstrand: right, you just need access to snakefruit for requesting tests (the britney host)
[13:22] <jdstrand> ok. I was running the command to see if it was running
[13:22] <jdstrand> np
[13:24] <pitti> jdstrand: btw, result will take a bit, the queues are rather long
[13:24] <pitti> (~ 110 tests waiting)
[13:24] <pitti> will appear on http://autopkgtest.ubuntu.com/packages/c/click-apparmor/wily/amd64/
[13:24] <pitti> (and /i386 of course)
[13:25] <jdstrand> is https://jenkins.qa.ubuntu.com/view/wily/view/All/job/wily-adt-click-apparmor/ no longer used? (I see jenkins in the url)
[13:30] <pitti> jdstrand: no, it's not; I sent u-devel-annouce@ about that two weeks ago or so
[13:30] <pitti> jdstrand: https://lists.ubuntu.com/archives/ubuntu-devel-announce/2015-August/001145.html FYI
[13:37] <jdstrand> I thought I remembered there was something on that. ok, thanks
[13:46] <jdstrand> pitti: curious, is the queue expressed anywhere in http://autopkgtest.ubuntu.com/?
[13:46] <pitti> jdstrand: no, not yet; it's an open wishlist item
[13:47]  * jdstrand nods
[13:47] <jdstrand> pitti: the site looks good. nice job :)
[13:49] <pitti> jdstrand: most of it isn't my job (I just did a few fixes), but thanks
[13:50] <pitti> jdstrand: it's "debci", aka. http://ci.debian.net
[13:53] <hallyn> infinity: could you unblock libvirt (as of 1.2.16-2ubuntu8)
[13:55] <sil2100> pitti: hey! I wanted that manual langpack creation since 1) wanted to check if all is working 2) get out our first updated base of translations for the overlay with no manual hacks involved
[13:55] <sil2100> pitti: anyway, still waiting for the base export to happen
[13:55] <sil2100> pitti: I asked wgrant for it, but it'll probably take a while until it finishes
[14:01] <infinity> hallyn: You have the power to do that.
[14:02] <hallyn> oh?  /me checks
[14:03] <Laney> (Close the bug)
[14:04] <infinity> Or remove the block-proposed tag.
[14:04] <infinity> Which is more appropriate than closing the bug.
[14:04] <cyphermox> morphis: I was told you were preparing a packaging branch for bluez in ~bluetooth?
[14:04] <infinity> Since the bug isn't closed until the package migrates.
[14:04] <infinity> hallyn: ^
[14:04] <morphis> cyphermox: yeah
[14:04] <cyphermox> morphis: is that lp:~bluetooth/bluez/ubuntu and were you done?
[14:04] <morphis> yeah
[14:04] <cyphermox> morphis: I wonder if we shouldn't keep history
[14:05] <morphis> would be fine for me
[14:05] <hallyn> i see - i thought it was a package property, not bug
[14:06] <hallyn> infinity: thx
[14:07] <infinity> hallyn: Excuses has a link to the bug that's blocking it and everything. :)
[14:10] <cyphermox> morphis: finally, I'm curious, is it set up as a merge-mode branch on purpose, ie. for CI train landings or something?
[14:11] <morphis> cyphermox: no, just for manual uploads atm
[14:11] <morphis> but would be good to have that
[14:13] <cyphermox> ok
[14:13] <cyphermox> morphis: I'll see if I can prepare a bluez branch too then I'll show you how it works / what I've done, we can see if that would work
[14:14] <morphis> that would be nice
[14:14] <morphis> still struggeling a bit with all this stuff :)
[14:16] <seb128> cyphermox, basically my fault for suggesting that workflow
[14:17] <seb128> but I don't know of a workflow working well for upstream projects
[14:17] <cyphermox> well, it's what I would have used too
[14:17] <seb128> CI train works fine for thing smaintained in launchpad
[14:17] <cyphermox> but I've thought that now maybe git would work
[14:17] <seb128> yeah, I think that too
[14:17] <seb128> I just have no clue about what workflow would be nice
[14:17] <seb128> and how to set it up
[14:17] <cyphermox> I wanted to make that for NM given that we already force NM to go through the train
[14:17] <seb128> and I didn't want to block starting a vcs on me figuring out those details
[14:18] <cyphermox> seb128: I'll play with it this week, get to a conclusion and let you know
[14:18] <seb128> thanks
[14:18] <cyphermox> to seed it I just need to download a few hundred .dscs :)
[14:20] <infinity> cyphermox: Thus proving that source packages *are* a VCS.
[14:20] <infinity> If you keep all of them...
[14:21] <cyphermox> yeah
[14:21] <cyphermox> but it's not so much for the history that I was looking into this
[14:22] <cyphermox> it's more for the ease of pulling in new upstream releases or cherry-picking patches from some git tree, which is what Tony wants to do in NM
[14:31] <infinity> flexiondotorg: Or maybe you're paying attention in this channel? :)
[14:38] <pitti> utlemming: http://anonscm.debian.org/cgit/pkg-systemd/systemd.git/commit/?id=3676d8c7b FYI
[14:38] <pitti> infinity: ^ I think he discussed that with you
[14:40] <infinity> pitti: Yeah.  To be fair, his rule only applied to CPUs, but I can't immediately think of how allowing the memory rule under Xen would be a bad thing.
[14:40] <infinity> pitti: (It's probably a no-op entirely, since Xen memory management isn't done that way)
[14:41] <pitti> infinity: yes, I just didn't want to make the rule even more complicated; apparnetly hyper-v needs the memory rule too
[14:41] <infinity> pitti: THat said, all it would take is one more LABEL to make it do exactly what his rule did.
[14:41] <utlemming> pitti: I think your match won't work: ATTR{[dmi/id]sys_vendor}=="Xen", Machine"
[14:42] <infinity> pitti: Inset a vm_cpu_hotadd_apply LABEL in between the two, and make Xen jump to that one.
[14:42] <pitti> well, what should *really* be done is to stop working around kernel defaults in userspace and just activate hotplugged CPUs
[14:42] <infinity> pitti: Yes, no argument on that.
[14:42] <pitti> it's stupid to always override kernel defaults with constant values from userspace
[14:42] <infinity> pitti: utlemming also has a point WRT your typo. ;)
[14:43] <infinity> Or copy-pasto.
[14:48] <barry> pitti: ping.  i'm confused.  when you look at dh-python for wily/{amd64,i386} on autopkgtest.ubuntu.com, you see a thumbs-down-fail, but if you chase the link to the test logs, it looks to me like they're passing.  am i looking at the wrong thing?
[14:49] <infinity> barry: Search for '- - - re'
[14:50] <infinity> Makefile:16: recipe for target 'test201' failed
[14:50] <infinity> make: *** [test201] Error 2
[14:50] <infinity> adt-run [09:19:05]: test dh-python: -----------------------]
[14:50] <infinity> adt-run [09:19:05]: test dh-python:  - - - - - - - - - - results - - - - - - - - - -
[14:50] <infinity> dh-python            FAIL non-zero exit status 2
[14:50] <infinity> For example.
[14:50] <barry> ah.  okay, i need to file a bug on autopkgtest.  it's too hard to find the results in a big log file :(
[16:36] <seb128> could somebody overwrite the boottest for bluez again?
[16:36] <seb128> it's buggy
[16:36] <seb128> Laney overwrote it earlier, but that doesn't stick and cyphermox did an upload since
[16:36] <cyphermox> yes, please :)
[16:47] <tjaalton> doko: looks like the switch to gcc5 broke mesa build on debian & ubuntu
[16:48] <tjaalton> http://pastebin.com/VgJX9ghz etc
[17:06] <tjaalton> doko: Sarvatt pointed me to https://llvm.org/bugs/show_bug.cgi?id=22593
[17:12] <LocutusOfBorg1> Unit193, can I upload virtualbox-ext-pack on unstable?
[17:37] <seb128> slangasek, can you override buggy boottests?
[17:37] <seb128> cf backlog, somebody to skip the bluez one would be nice
[17:37] <slangasek> seb128: it is possible to do, but why do you believe the boot test is buggy?
[17:38] <seb128> slangasek, because pitti said this morning that it always failed on bluez and that he keeps skipping it
[17:39] <seb128> slangasek, http://irclogs.ubuntu.com/2015/08/14/%23ubuntu-desktop.html#t07:57
[17:39] <seb128> if you want reference
[17:39] <seb128> we should sort that out one day, but atm the bluez transition had an issue and half migrated
[17:39] <seb128> which is breaking iso builds
[17:40] <slangasek> pitti: what is broken about the bluez boottest?
[17:40] <seb128> so would be nice to unblock it without waiting on the boottest situation to be sorted out
[17:40] <slangasek> seb128: and what is the impact of this new bluez on the phone stack - which is what boottests are supposed to tell us?
[17:42] <seb128> slangasek, basically making bluetooth not working on touch
[17:42] <seb128> which was an approved decision before landing
[17:42] <slangasek> ok
[17:43] <seb128> the phone team is working on enabled bluez5 but they don't plan any product on wily and the image is already in a not so good state
[17:43] <seb128> so they said it's ok to unblock desktop and make bluetooth buggy on touch for a while
[17:43] <slangasek> but it's not expected to make the phone unbootable, for instance; this is probably just an error with the boot tests being broken? (trying to install packages on a running system with apt instead of offline)
[17:44] <seb128> right
[17:44] <slangasek> ok, will override as soon as I find the syntax
[17:44] <seb128> thanks
[17:44] <slangasek> though maybe it's just (force-skip)
[17:46] <slangasek> seb128: done
[17:49] <seb128> slangasek, thanks
[17:50] <doko> tjaalton, I don't understand, the last successful build is https://launchpad.net/ubuntu/+source/mesa/10.6.3-1ubuntu1 ?
[17:53] <tjaalton> doko: it was built with old gcc
[17:53] <tjaalton> now llvm needs to be rebuilt with gcc5 and only then would mesa build again
[17:53] <doko> tjaalton, on Aug 11?
[17:53] <tjaalton> hm sorry
[17:53] <tjaalton> well it fails on my sbuild
[17:53] <doko> no, I already rebuilt 3.5 and 3.6
[17:54] <tjaalton> hmm
[17:54] <tjaalton> then I need to check my chroots
[17:54] <tjaalton> ..next week
[17:54] <doko> tjaalton, you sure to have -proposed enabled?
[17:54] <tjaalton> but debian fails too
[17:54] <tjaalton> no
[17:54] <doko> then do
[17:54] <tjaalton> failure on debian is expected then?
[17:54] <doko> and I'm pestering Sylvestre to rebuild it in Debian
[17:54] <tjaalton> sid
[17:54] <tjaalton> ahh ok
[17:54] <doko> yes
[17:55] <tjaalton> then I'll revisit it next week :)
[17:55] <tjaalton> thanks
[20:36] <mitya57> Mirv, hi, is there any reason why qtcreator is not built with system qbs (like in Debian)?
[20:54] <mitya57> Mirv, also, in Qt 5.5 there are duplicate headers in /usr/include/x86_64-linux-gnu/qt5/QtQmlDevTools/ and /usr/include/x86_64-linux-gnu/qt5/QtQml/,
[20:55] <mitya57> do you know if we really need the former? and if we need, can we symlink them?
[20:58] <LocutusOfBorg1> ginggs, congrats!
[22:52] <ejat> hi ..
[22:53] <ejat> can someone help me know why need to remove gnome-bluetooth ?
[22:53] <ejat> http://paste.ubuntu.com/12084015/