[03:26] <rsalveti> popey: are you able to reproduce bug 1334940?
[07:16] <Saviq> sil2100, can we kick M&C on silo 5 do you think?
[07:23] <tvoss> good morning
[07:24] <tvoss> sil2100, can I get a silo for line 28?
[07:31] <sil2100> o/
[07:35] <sil2100> tvoss: let's see if there will be no conflicts
[07:35] <tvoss> sil2100, there most likely will be, but it's really only build system setups
[07:35] <tvoss> sil2100, also note that the list of mps is not complete, yet
[07:56] <sil2100> tvoss: anyway, silo 008 is for you
[07:56] <tvoss> sil2100, thank you
[07:57] <tvoss> sil2100, I will add a bunch of MPs now, and ping you once done to ask for a reconfigure
[08:02] <sil2100> tvoss: ok :)
[08:31] <sil2100> davmor2: hey, meeting?
[08:51] <seb128> sil2100, thanks for handling that settings landing! seems like you can m&c it now as well
[08:52] <t1mp> any ideas why jenkins is so slow these days? It takes >10h for a happroved MR to land in a branch
[09:04] <mhr3> psivaa, ping?
[09:04] <mhr3> psivaa, would you happen to know anything about foo:native not working on jenkins?
[09:05] <ogra_> t1mp, there was a mail
[09:06] <psivaa> mhr3: do you have a link for the job
[09:06] <mhr3> psivaa, here's one https://jenkins.qa.ubuntu.com/job/unity-team-unity-scope-click-devel-utopic-amd64-ci/129/console
[09:07] <mhr3> psivaa, another https://jenkins.qa.ubuntu.com/job/mediascanner2-utopic-amd64-ci/38/console
[09:07] <mhr3> psivaa, and there will be few more
[09:10] <t1mp> ogra_: ah yes, I see now.
[09:10] <t1mp> thanks.. I hope a solution can be found
[09:11] <oSoMoN> sil2100, hey, would you mind publishing silo 13?
[09:25] <tvoss> sil2100, could you reconfigure silo 27 please?
[09:27] <sil2100> o/
[09:27] <sil2100> One moment please and I'm handling your requests
[09:28] <Laney> Your call is important to us
[09:30] <tvoss> sil2100, can I push build and see the world explode?
[09:30] <tvoss> sil2100, pushed the button :)
[09:36] <psivaa> mhr3: sorry, could not find much info as to why it's failing except:
[09:36] <psivaa> sh: 1: x86_64-linux-gnu-gcc-4.9: not found
[09:36] <psivaa> dpkg-architecture: warning: couldn't determine gcc system type, falling back to default (native compilation)
[09:37] <mhr3> psivaa, hmm, wouldn't you anyway get that error *after* the dep checks?
[09:38] <mhr3> psivaa, plus it's not really an error... just a warning :)
[09:39] <popey> sil2100: ogra_ i can't land camera it in the store right now because the frameworks has been updated..
[09:40] <psivaa> mhr3: ok, but i dont see that in passing jobs.
[09:40] <ogra_> to something non existing ??
[09:40] <popey> -dev2 was pushed to click and the camera app uses it, but the docs, the store and the reviewers tools aren't updated
[09:40] <popey> exists on the device, yeah
[09:40] <popey> but nowhere else
[09:40] <popey> looks like a conversation in #phablet last night
[09:40] <popey> wish people would use the public channels
[09:41] <psivaa> mhr3: the installed version of gcc in the host is: 4.8.2-19ubuntu1, if that points to anything.
[09:42] <mhr3> psivaa, well what changed is the addition of gcc-4.9:native to the control file, and apparently pbuilder doesn't like that, i've heard that you were stripping the native suffix because of that, but i guess that stripping isn't global?
[09:42] <ogra_> sigh
[09:42] <psivaa> mhr3: i have no idea about that :), sorry. i'll ask fginther when he's around.
[09:42]  * sil2100 sighs
[09:43] <psivaa> too many sighs :)
[09:43] <mhr3> psivaa, ok, thanks for looking into it anyway
[09:43]  * mhr3 sighs too
[09:43] <sil2100> tvoss: the reconfigure has failed it seems, let me reconfigure again
[09:43] <tvoss> sil2100, hmmm, the silo is building
[09:43] <psivaa> mhr3: np.
[09:44] <sil2100> tvoss: ok, it might not have built all the components then
[09:44] <sil2100> tvoss: let me re-run it in a moment
[09:44] <tvoss> sil2100, yup, the build failed
[09:45] <ogra_> popey, ah, to prevent it from being offered to images with older frameworks
[09:45] <popey> yes
[09:45] <ogra_> k
[09:45] <ogra_> do we have any ETA for the update of the tools ?
[09:45] <ogra_> (and docs)
[09:47] <sil2100> tvoss: ok, the build failed also from a different reason, let me try and get to the source of it
[09:47] <popey> ogra_: jdstrand owns the docs and tools, asked james for ETA on store
[09:47] <ogra_> thanks
[09:49] <sil2100> hmmm
[09:49] <sil2100> tvoss: so, it seems that the unity-scope-click merge proposal branch targets lp:unity-scope-click/devel which is not up to sync with the archive
[09:51] <sil2100> tvoss: not sure if lp:unity-scope-click/devel should be used? What is the main branch for this project? I see lp:unity-scope-click being in sync with the archive
[09:55] <sil2100> I think you'll have to ask the author to retarget the merge
[09:56] <sil2100> ogra_, popey: you think we should wait with 102 for that to happen?
[09:56] <ogra_> sil2100, no, lets build one
[09:57] <sil2100> Ok then, let's kick a new image
[09:57] <popey> ☹
[09:58] <popey> ogra_: before you do..
[09:58] <ogra_> yeah ?
[09:58] <popey> any chance you can add my libkeychain to the image?
[09:59] <ogra_> that will cost another publisher run, but yeah, i can
[09:59] <popey> https://code.launchpad.net/~popey/ubuntu-seeds/add-keychain/+merge/224667
[09:59] <popey> thanks
[10:00] <tvoss> thostr_, ^ please see sil's comment
[10:10] <cjwatson> mhr3: As I noted in whatever unity-scope-click MP it was, I really think the advice to use g++-4.9:native is wrong - even though there does seem to be something suspicious here going on in jenkins.
[10:14] <mhr3> cjwatson, well pbuilder not supporting :native is what's wrong
[10:15] <mhr3> cjwatson, i'll let you fight with xnox about the need for :native, imo explicitely picking gcc version on individual packages like this is already what's wrong :P
[10:17] <xnox> cjwatson: well the intention is to protect from c++11 abi breaks.
[10:17] <xnox> cjwatson: yet, without breaking cross compilation....
[10:18] <xnox> cjwatson: not add that dependency at all?
[10:18]  * xnox ponders where pbuilderjenkins is maintained.
[10:33] <fginther> psivaa, mhr3, the ':native' stripping is not global. I'm applying it to unity-scopes-api now
[10:34] <mhr3> fginther, well, it would need to be applied to about ~15 projects
[10:34] <mhr3> at least
[10:36] <psivaa> fginther: ack, thanks. i'll take a look at it later for future ref :)
[10:37] <cjwatson> mhr3: No, there are excellent reasons to control the timing of C++11 ABI changes
[10:39] <cjwatson> xnox: The thing we need to do to make explicit compiler build-dependencies work for cross-building isn't to use :native, but to have sbuild know when to turn g++-4.9 into g++-4.9-$triplet
[10:39] <cjwatson> mhr3: Thomas is working on that set of packages, after discussion with me and Steve
[10:41] <cjwatson> xnox: g++-4.9:native doesn't help the cross case - sure, it'll give you a compiler that executes on the build architecture rather than on the host architecture, but it'll also target the build architecture so it's no good
[10:41] <cjwatson> xnox: I've been over this extensively with Wookey :-)
[10:41] <mhr3> cjwatson, i know, i just don't like that they're even needed... anyway that doesn't mean that half of unity stack should stop being cross buildable
[10:42] <cjwatson> xnox: I agree that this set of changes regresses cross-compilation, but realistically that's less important than controlling ABI changes in this case
[10:42] <cjwatson> (Well, may regress; I don't know what the current state of cross-building for this particular set of packages is)
[10:42] <cjwatson> mhr3: Like I say, we can and should fix this centrally
[10:42] <mhr3> cjwatson, and meanwhile any development can suffer?
[10:42] <cjwatson> mhr3: This is just making a well-known problem cover a few more packages
[10:43] <cjwatson> mhr3: Um, development suffers either way, this change isn't being made for no reason!
[10:43] <cjwatson> mhr3: We had to revert a toolchain defaults change until this was sorted out
[10:45] <cjwatson> mhr3: There is no currently-available method that both preserves cross-building and permits control of C++11 ABI changes across g++ version changes, to the best of my knowledge.  You could always not use a C++ version with experimental toolchain support :P
[10:45] <cjwatson> (But that ship has sailed, I know)
[10:45] <xnox> cjwatson: yes, i am aware that there is no way to declare cross-compilers as a build-dependency. Without adding any dependency the package will fail to build from source, given the export in the debian/rules. The extra dependency helps to keep native build working even after g++4.9 -> g++4.10 default change, but will not help x-building.
[10:46] <fginther> cjwatson, For CI, we have to strip out :native as pbuilder doesn't parse it correctly even though we are already doing native builds
[10:46] <cjwatson> fginther: yes, I know, but that apparently isn't working quite right in all cases, given this conversation
[10:46] <fginther> cjwatson, this is applied as a hook and currently only to the projects when needed
[10:46] <cjwatson> fginther: https://jenkins.qa.ubuntu.com/job/unity-team-unity-scope-click-devel-utopic-amd64-ci/129/console
[10:46] <xnox> imho, just adding the export of CC/CXX in debian/rules is suffcient to guarantee package builds against expected compiler abi.
[10:47] <cjwatson> fginther: aha, why not globally?
[10:47] <cjwatson> xnox: No, because the point is to decouple these changes from our toolchain default switch
[10:47] <fginther> cjwatson, it was new and I didn't want to introduce it global until it was needed globally
[10:47] <cjwatson> xnox: That would make it impossible to continue building against g++-4.8 after we switch to g++-4.9, for instance, or vice versa
[10:48] <cjwatson> xnox: Which is the point (not to do that for an extended period of time, but to give those projects control over when they switch because they have to coordinate SONAME changes and such)
[10:48] <fginther> mhr3, cjwatson, it's been working fine so far, so I see no reason to not apply it to all projects. It's just that it's time didn't come until today :-)
[10:48] <xnox> cjwatson: right. There was proposal emailed to allow specifying cross-compilers, such that they are appropriately remapped using a build profile something a keen off "gcc-4.9 <!cross-building>, ARCH-gcc-4.9 <cross-building>"
[10:49] <cjwatson> tvoss|food: ^- you might want to be aware of the above conversation
[10:49] <xnox> but exact semantics have not been implemented yet.
[10:49] <xnox> I think we will be discussing this at the Debconf.
[10:49] <cjwatson> xnox: right, exactly, that's what I discussed with Wookey years ago
[10:49] <xnox> ack. so same thing.
[10:50] <cjwatson> xnox: AFAIK the only thing that needs to be sorted is the way to tell which packages this should be applied to; I think I suggested a control field in the various relevant compiler packages, although I forget the name we settled on
[10:50] <cjwatson> (and of course implementation in dpkg-checkbuilddeps and sbuild)
[10:50] <brendand> ogra_, you won't believe the explanation for the autopilot bug :)
[10:50] <tvoss|food> cjwatson, ack and thanks
[10:51] <cjwatson> brendand: this one weird autopilot bug, discovered by a mom
[10:52] <brendand> cjwatson, earn $$$ without doing anything!!!
[10:52] <brendand> ogra_, here's the guilty landing http://paste.ubuntu.com/7710576/
[10:52] <brendand> ogra_, start with #95
[10:53] <brendand> ogra_, then install qtubuntu-sensors
[10:53] <brendand> ogra_, run the test suite and autopilot gets dbus *errors*
[10:53] <brendand> ogra_, then install ubuntu-application-api2-touch and they turn from errors into delays
[10:54] <brendand> ogra_, so i guess they tried to fix the dbus error incorrectly
[10:54] <brendand> ogra_, i do wonder though why autopilot has to scan the whole bus
[10:54] <brendand> ogra_, i need to ask them that
[10:59] <brendand> ogra_, so what can we do? revert that? i guess we need to get ricmm and/or rsalveti involved
[11:24] <ogra_> brendand, show it to ricmm
[11:25] <sil2100> brendand: \o/
[11:26] <brendand> ogra_, ok
[11:26] <sil2100> brendand: yeah, as per ogra_'s proposition, let's wait for ricmm to comment on this
[11:26] <sil2100> ricmm: ^
[11:40] <h0x15> Suggestion: some html page with an graphic representation of number of failures/crashes vs build number. Something like http://ci.debian.net on ci.ubuntu ?
[11:41] <ogra_> h0x15, do you mean http://ci.ubuntu.com/smokeng/utopic/touch/ ?
[11:42] <ogra_> or more detailed http://ci.ubuntu.com/smokeng/utopic/touch/mako/99:20140626.1:20140625/8744/
[11:42] <h0x15> yes, but visual grafig
[11:43] <h0x15> chart
[11:44] <thostr_> could somebody reconfigure silo *
[11:44] <thostr_> silo 8 that is
[11:45] <ricmm> sil2100: so whats the issue?
[11:45] <ricmm> ogra_:
[11:45] <ogra_> ricmm, seems our testing got extremely slow sinse papi2
[11:45] <ogra_> *since
[11:46] <ogra_> or rather with the new qtubuntu-sensors
[11:46] <ricmm> 95 is the orient
[11:46] <ricmm> not papi2
[11:46] <ogra_> see brendand above
[11:46] <ogra_> right, sorry
[11:47]  * sil2100 off to lunch
[11:47] <ricmm> brendand: extremely slow in what way? do you have a bug number with the information?
[11:48] <ogra_> ricmm, the UITK autopilot tests turned into a several hour job ... there is a dbus timeout that adds ~30sec per loop
[11:48] <brendand> ricmm, https://bugs.launchpad.net/autopilot/+bug/1334676
[11:49] <ogra_> all other AP tests got slow too
[11:50] <thostr_> trainguards: can anybody reconfigure silo 8
[12:01] <ricmm> brendand: and reverting the changes from the usensord landing fixes it?
[12:01] <ricmm> it might be dbus-cpp which we use to reach the usensord service
[12:02] <ricmm> which became apparent now that usernsord is a dbus service
[12:02] <ricmm> I'll examine after lunch if you dont mind
[12:02] <ricmm> as its getting cold
[12:02] <brendand> ricmm, yes
[12:20] <popey> ogra_: sil2100 camera updated in store
[12:24] <thostr_> sil2100: can you reconfigure silo 8
[12:30] <tvoss> davmor2, around?
[12:30] <tvoss> mandel, oSoMoN you fine with me setting silo 11 to tested?
[12:35] <davmor2> tvoss: I am
[12:35] <tvoss> davmor2, hey there :)
[12:35] <sil2100> thostr_: sure
[12:35] <sil2100> popey: \o/
[12:36] <sil2100> thostr_: I'm on lunch now so it's taking a bit longer for me to notice pings :)
[12:36] <tvoss> davmor2, I filed the issue you encountered in bug https://bugs.launchpad.net/location-service/+bug/1335102
[12:36] <tvoss> davmor2, mandel, oSoMoN are you guys then fine with me setting silo 11 to tested?
[12:36] <davmor2> tvoss: yeap everything works in 011 and it doesn't really break anything.  Except for killing the battery :)
[12:36] <tvoss> davmor2, ack, thank you
[12:47] <mhr3> is something wrong with s-jenkins?
[12:47] <mhr3> can't reach it
[12:58] <mhr3> if only i knew its ip
[12:59] <popey> mhr3: $ host s-jenkins.ubuntu-ci
[12:59] <popey> s-jenkins.ubuntu-ci is an alias for mayura.ubuntu-ci.
[12:59] <popey> mayura.ubuntu-ci has address 10.98.3.13
[13:00] <popey> mhr3: working fine here
[13:00] <oSoMoN> tvoss, yup, as far as I’m concerned silo 11 is good to go
[13:00] <mhr3> popey, thx, works via ip here too, just no dns it seems
[13:01] <mhr3> i'll blame the upgrade that i just did
[13:05] <ricmm> tvoss: ping
[13:07] <jdstrand> ogra_ (and popey): tools are fine (we don't have to change anything atm-- we will in the future so keeping them in mind with new frameworks is a good idea). I used to be able to edit the docs, but part moved out to a spreadsheet that I can't edit. I've asked lool to update it
[13:08] <popey> sweet, thanks
[13:15] <imgbot> [13:16] <alan_g> josepht: there seems to be something odd with https://jenkins.qa.ubuntu.com/job/mir-team-mir-development-branch-autolanding/
[13:16] <alan_g> I'd expect it to correspond with the "ready to land" in https://code.launchpad.net/mir/+activereviews
[13:16] <alan_g> But 804 is still in the latter and the other six in the latter are not in the former.
[13:16] <alan_g> Any idea what's going on?
[13:16] <kgunn> Ursinha: ^ sorry if i'm a redundant ping
[13:17] <josepht> alan_g: let me take a look
[13:18] <mhr3> fginther, so is the :native stripping going to be global?
[13:26] <jdstrand> fyi, just sent to the list. I did an emergency no-code-change upload for bug #1334940, but that has an unrelated testsuite failure
[13:27] <josepht> alan_g: it looks like the generic-land job failed to aquire a lock on bzr+ssh://ps-jenkins@bazaar.launchpad.net/~mir-team/mir/development-branch/
[13:27] <jdstrand> I have alerted Satoris, who is looking into it
[13:27] <josepht> alan_g: I'll try re-running that build
[13:28] <sil2100> davmor2: once 102 is built, could you take a look at it promotion-wise?
[13:28] <davmor2> sil2100: if the issue with not displaying music or videos is still there then no
[13:29] <alan_g> josepht: that may take some time.
[13:31] <alan_g> alf__: ^^
[13:34] <sil2100> davmor2: you mean the mediascanner bug?
[13:35] <josepht> alan_g: sorry, I meant the generic-land build, it's pretty quick and it failed again trying to acquire the lock.
[13:35] <davmor2> sil2100: yes
[13:35] <davmor2> sil2100: people having no access to their music or videos kinda sucks
[13:36] <sil2100> davmor2: I see a fix in the archive... I wonder if it made it to this image
[13:36] <sil2100> Of course it didn't make it ;/
[13:36] <sil2100> As it's still in -proposed
[13:37] <davmor2> sil2100: it failed to build see mailing list team are on it now I think
[13:37] <alan_g> josepht: weird. I just tried running break-lock --verbose ... it reported nothing
[13:38] <sil2100> Ah, right, email from 15 minutes ago
[13:38] <sil2100> Ok, so I'm starting to feel pressure here...
[13:39] <josepht> alan_g: Unable to obtain lock  held by alan-griffiths@bazaar.launchpad.net on taotie (process #28697), acquired 20 hours, 57 minutes ago.
[13:40] <alan_g> josepht: That's me. But...! I'll try merging that MP locally and push it - see what happens then
[13:40] <josepht> alan_g: hold on
[13:42] <mandel> tvoss, +1 from me for silo 11
[13:42] <josepht> alan_g: it seems to have merged that time
[13:42] <sil2100> ricmm: how's the dbus-related regression analysis proceeding?
[13:42] <alan_g> \o/
[13:45] <ricmm> sil2100: we are looking into it
[13:45] <alan_g> josepht: thanks. Any idea why jenkin's hasn't picked up the other jobs?
[13:45] <ricmm> sil2100: but no definitives. it should be related to using dbus-cpp to reach usensord
[13:45] <ricmm> trying to figure out which bit is actually timing out
[13:45] <josepht> alan_g: it also looks like jenkins has kicked off builds for the others as well
[13:45] <ricmm> brendand_: do you know exactly what it is that autopilot is trying to do?
[13:46] <brendand_> ricmm, the bug should say. but if it's not clear i can describe it in more detail
[13:46] <alan_g> josepht: where do you see that?
[13:46] <josepht> alan_g: s-jenkins
[13:48] <alan_g> josepht: Ah. I was looking at https://jenkins.qa.ubuntu.com - and that doesn't show the pending ones.
[13:48] <ricmm> brendand_: describe it in more detail, what exactly is autopilot trying to do by probing into connection peers?
[13:48] <alan_g> josepht: thanks for the help
[13:48] <ricmm> brendand_: to find it is a testability interface?
[13:48] <ricmm> if it is*
[13:48] <josepht> alan_g: my pleasure
[13:49] <ricmm> brendand_: also, got a test that fails every time?
[13:49] <ricmm> or is it all of them
[13:49] <brendand_> ricmm, yes it seems to be trying to find if that connection has the introspection interface
[13:50] <brendand_> ricmm, i run ubuntuuitoolkit. using --verbose
[13:50] <ricmm> brendand_: ok
[13:50] <brendand_> ricmm, you should see it hang for ~30 seconds, and then the error described
[13:51] <brendand_> ricmm, i think this log from pitti might be helpful: http://paste.ubuntu.com/7709407/
[14:02] <ricmm> brendand_: right, and the bug there is what, the app exit behaviour?
[14:02] <ricmm> I'm not seeing any timeouts in that log
[14:03] <brendand_> ricmm, the messages at the bottom
[14:03] <brendand_> ricmm, it seems to suggest a problem closing the connection
[14:03] <ricmm> those only show when the application exits
[14:04] <brendand_> ricmm, ok i won't read too much into it then
[14:04] <brendand_> ricmm, i'll leave it to you. if you have any more questions for me or need me to try anything, let me know
[14:04] <ricmm> brendand_: so if its the usage of the dbus usensord interface, reverting qtubuntu-sensors to anything before 24.3 should fix it
[14:05] <ricmm> is that correct?
[14:06] <brendand_> ricmm, well doing qtubuntu-sensors:armhf from 0.6+14.10.20140623.3-0ubuntu1 to 0.6+14.10.20140624.3-0ubuntu1 broke it
[14:06] <brendand_> ricmm, i didn't try then reverting it again
[14:07] <brendand_> ricmm, i can do that now
[14:07] <ricmm> 23.3 fixes it just checked
[14:07] <brendand_> ricmm, read my last comment on the bug though. if you *just* upgrade qtubuntu-sensors then it is broken in a different, less subtle way
[14:07] <brendand_> ricmm, ok cool
[14:08] <ricmm> if you just upgrade qtubuntu-sensors the API wont be available from platform-api
[14:10] <brendand_> ricmm, yeah
[14:10] <brendand_> ricmm, so is it that the new api is broken then?
[14:10] <ricmm> the API is using dbus-cpp to open a connection to the vibration service
[14:11] <ricmm> something there is setting itself up in a way that it baffles autopilot
[14:11] <ricmm> thomas will help in a minute as he knows that code best
[14:11] <ricmm> it'd be great if I could know the exact autopilot lines that are doing this probing
[14:11] <ricmm> which them timeouts
[14:13] <brendand_> ricmm, you can reproduce it without AP like this: http://pastebin.ubuntu.com/7709477/
[14:13] <brendand_> ricmm, using qdbus
[14:14] <brendand_> ricmm, i could give you the autopilot lines as well if you want
[14:14] <ricmm> brendand_: ah thats amaizing :)
[14:15] <brendand_> ricmm, but probably easier with those steps
[14:15] <ricmm> sure, but this looks good enough
[14:17] <ricmm> brendand_: the one thing I dont get is why autopilot needs to probe into the application's connections
[14:17] <ricmm> is that to see if the application connected back to autopilot? if it finds itself in the tree?
[14:19] <fginther> mhr3, yes, it will be made global. It will take a day or two to roll it out, so if another project needs it right now, we'll need to update it individually.
[14:23] <brendand_> ricmm,  i need to find that out. but i don't think it's worth getting hung up on it. it can't be good that some dead dbus connection is being left around like that, right?
[14:27] <ricmm> brendand_: its not a dead dbus connection, its a timing out introspect call
[14:27] <ricmm> brendand_: the bug lies either with usensord or dbus-cpp
[14:27] <ricmm> brendand_: I just want to know why the need to introspect the tested app's connections to find itself
[14:29] <jdstrand> hey, we need a/win 32
[14:29] <jdstrand> meh
[14:31] <plars> cjwatson, fginther, ev: I think we can skip the hangout if you want. I just sent an email. cjwatson: your response was very helpful and I think I have a better idea of what is needed.
[14:32] <boiko> sil2100: hi, could you please reconfigure landing-006? renato just told me there are some extra MRs needed for that one
[14:32] <ev> cool
[14:33] <cjwatson> plars: Ah, good timing, I was just about to engage in battle with audio
[14:33] <fginther> plars, ack
[14:33] <sil2100> boiko: sure
[14:33] <cjwatson> plars: Cool
[14:35] <jdstrand> hey, can I have a silo for mediascanner2 (line 31)
[14:35] <sil2100> boiko: reconfigured
[14:36] <jdstrand> it is a no-code-change update to bring the packaging in sync with my emergency upload from today and then a ftbfs fix on top of that. the fix is to disable a test that is broken due to a change in sqlite behavior
[14:36] <jdstrand> that test failure doesn't indicate that mediascanner2 is broken (I'm told) and simply needs to be updated
[14:37] <sil2100> tvoss: ok, so we might need to rebuild location-service from silo 11 - the changelog is too poor... there is a lot of changes but they're not mentioned in the changelog :|
[14:37] <sil2100> The core devs would kill me if this would go to the archive
[14:37] <sil2100> Especially oSoMoN
[14:37] <sil2100> I mean
[14:37] <sil2100> ogra_:
[14:37]  * sil2100 has some typing problems it seems
[14:37] <sil2100> oSoMoN: ignore my ping ;)
[14:38]  * ogra_ hopes oSoMoN also check for proper changelog though ;)
[14:38]  * oSoMoN can also kill
[14:39] <oSoMoN> ogra_, not just improper changelogs, also poor commit messages
[14:39] <ogra_> yeah
[14:42] <jdstrand> note, this mediascanner2 landing is crucial for the mediascanner2 to be able to scan on the device, because the apparmor fix to fix that can't land without the fix for the ftbfs
[14:42] <stgraber> jdstrand: you got silo 7
[14:42] <jdstrand> thanks!
[14:43] <stgraber> AlbertA: you've got silo 13
[14:43] <sergiusens> sil2100: hey, I don't understand this error; care to explain?
[14:44] <sil2100> sergiusens: hey! Which one?
[14:44] <sergiusens> sil2100: lolz; Friday woes :-) https://ci-train.ubuntu.com/job/landing-002-1-build/120/console
[14:44] <sergiusens> forgot to paste the link :)
[14:45] <imgbot> [14:45] <sil2100> ohoho, oh my
[14:45] <imgbot> [14:45] <sil2100> This is one absurd error
[14:45] <sil2100> sergiusens: I noticed you have a gift of making citrain confused!
[14:46] <sil2100> Let me dive into this one
[14:46] <stgraber> tvoss: libjsoncpp-dev and libnet-cpp-dev are universe packages, location-service is in main, so you'll need to file an MIR for each of them before I can let your package in
[14:46] <sil2100> Ah
[14:46] <sil2100> sergiusens: ok, I see the problem I think
[14:47] <sil2100> sergiusens: I mean... not sure if that's it, but it might lead to the confusion of citrain
[14:48] <sil2100> sergiusens: so, the problem seems to be that there is a mismatch between the lp-project name (lp:udm) and the source package name (golang-udm)
[14:48] <tvoss> stgraber, ack
[14:48] <sil2100> sergiusens: the principle of all citrain (and also cu2d) project is that the lp project name needs to be the same as the source package name
[14:48] <tvoss> stgraber, or alternatively patch out those dependencies, correct?
[14:49] <stgraber> tvoss: right, dropping those two dependencies works too :)
[14:49] <sil2100> sergiusens: this migth be the problem, and it's not really fixable in citrain as it's as I mentioned - it's a principle which CI Train enabled projects need to follow :)
[14:50] <tvoss> stgraber, can I patch them out from the existing MR?
[14:51] <stgraber> tvoss: yeah, that should be fine, update the current MR, rebuild it in the silo and that should do the trick
[14:51] <jdstrand> sil2100: hrmm, failure to merge the source :\
[14:51] <sil2100> jdstrand: where?
[14:51] <lool> jdstrand: I've updated the spreadsheet and gave you write acess
[14:51] <tvoss> stgraber, I'm confused, isn't the unity-scopes-api in main?
[14:51] <jdstrand> sil2100: it merges fine here. I have a feeling it is because of the changelog. the MR updates the changelog to sync to what is in the archive, but then expects something more
[14:52] <sil2100> Ah
[14:52] <sil2100> Let me take a look
[14:52] <jdstrand> sil2100: should we update the changelog too?
[14:52] <stgraber> tvoss:  unity-scopes-api | 0.5.1+14.10.20140626-0ubuntu1 | utopic/universe | source
[14:52] <stgraber> tvoss: so, no
[14:52] <tvoss> stgraber, ack and thx
[14:52] <tvoss> stgraber, my bad then
[14:52] <jdstrand> sil2100: eg, to have ubuntu3?
[14:52] <sil2100> jdstrand: wait, from what I see the build failure in silo 007 is caused by something else?
[14:53] <sil2100> (we're talking about 007, right?)
[14:53] <jdstrand> oh, right, not approved
[14:53] <jdstrand> yes, let me address that
[14:53] <sergiusens> sil2100: we had this discussion once; and didrocks told us it was supported though
[14:54] <stgraber> sergiusens: it sure should be, otherwise we wouldn't be able to land any of the system-image stuff
[14:55] <ricmm> sergiusens: so we know the issue, go-dbus has no default error if the interfaces are no introspectable
[14:55] <ricmm> sil2100: ^
[14:55] <ricmm> sergiusens: that wasnt for you, was for sil
[14:55] <sergiusens> I assumed :-)
[14:55] <ricmm> so sergio will try his best, but ultimately this exposes an architectural issue with autopilot
[14:55] <ricmm> brendand_: ^
[14:55] <sergiusens> sil2100: I'll fix that and you fix my issue ;) fair trade :-)
[14:55] <ricmm> I still dont understand why it needs to probe into the application's connections to check if the application has connected to autopilot
[14:56] <sil2100> sergiusens: ok, let me dig in deeper then ;) Didn't know Didier removed this restriction
[14:56] <sil2100> Ah
[14:56] <sil2100> hm
[14:56] <sergiusens> yeah, stgraber brings me some confidence that it should be working
[14:56] <sergiusens> sil2100: also, this is the first train landing for this
[14:56] <sil2100> Ok, I think I know what's up then ;) But let me double check first before I spout out another theory!
[14:57] <sil2100> Yeah, this might be the reason, I think citrain might be confused by the lack of tags
[14:57] <sil2100> sergiusens: could you try tagging in bzr the revision that's released into the archive?
[14:58] <sergiusens> sil2100: in trunk I asume; will do
[14:58] <sil2100> i.e. 0.1-0ubuntu1 in trunk, probably revision no 2
[14:58] <sil2100> Yeah :)
[15:01]  * sergiusens tries build
[15:03] <sergiusens> sil2100: still breaks
[15:03] <sergiusens> sil2100: I can force build I guess
[15:04] <sil2100> sergiusens: let me take a look again then
[15:05] <brendand_> ricmm, it might not be an 'issue' though - it might be essential for autopilot to do it, so please - keep looking on your side for a solution
[15:05] <balloons> fginther, can you have a look at https://code.launchpad.net/~nskaggs/reminders-app/fix-evernote-sdk-python3/+merge/223493 again? I see the pep8 errors again that you tried to get rid of earlier in the week. I fixed the errors in the code we want to be checking
[15:06] <brendand_> ricmm, i really don't understand autopilot well enough to know if there is another approach that can be used. we need to wait for someone who does to come online
[15:06] <sil2100> Ah!
[15:06] <sil2100> sergiusens: I see the problem... it's a bit more trivial it seems
[15:07] <brendand_> ricmm, did you find any root cause yet?
[15:07] <brendand_> ricmm, is it the go-dbus thing you mentioned?
[15:07] <sil2100> sergiusens: so, only now I noticed that trunk still has 0.1-0ubuntu1 in the changelog as UNRELEASED
[15:08] <sil2100> sergiusens: so... please make a quick direct push to trunk where you change 0.1-0ubuntu1 to utopic and maybe re-tag this one to 0.1-0ubuntu1
[15:08] <sil2100> sergiusens: it should work like a charm then
[15:08] <sergiusens> sil2100: ah, that can actually be it; is there a way to remove the tag easily though?
[15:09] <sergiusens> or only with --overwrite?
[15:09] <sil2100> sergiusens: I'm not sure... I know I did it a few times, but I don't remember if I didn't have to --overwrite in the end
[15:09] <sergiusens> ack, I'll figure it out
[15:10] <sil2100> As it's a new project I guess even --overwrite wouldn't hurt I guess... still, you might try doing a bzr tag --delete and then re-tagging it and pushing without it
[15:10] <sil2100> Who knows? Maybe it'll allow it
[15:10] <ogra_> if you are the only committer --overwrite is ok
[15:10] <fginther> balloons, did the packaging change recently? It looks like it's now looking in the temporary install path, should just add that to the exclude list
[15:11] <balloons> fginther, yes, I needed to add those modules to the packaging.. failed to do that originally :-)
[15:12] <fginther> balloons, I'll have to update the hook then, hang on
[15:17] <ricmm> brendand_: we have the solution on our side, just saying that we need to figure out why autopilot is doing this, because it is certainly a hack to find if the client connected back to autopilot
[15:17] <ricmm> so this fix, and the subsequent autopilot investigation, are separate things
[15:17] <ricmm> brendand_: the problem is that go-dbus doesnt provide introspection by default
[15:17] <ricmm> brendand_: so the way to fix it right now is to manually add introspection to usensord, which is the offending service
[15:18] <ricmm> we'll fix it np
[15:20] <brendand_> ricmm, sure - if autopilot doesn't *have* to use such a technique then it certainly shouldn't. like i said, i'll pursue it with them
[15:21] <brendand_> ricmm, you could comment on the bug with such analysis as well
[15:33] <sergiusens> sil2100: it's building now
[15:33] <sil2100> sergiusens: excellent
[15:33] <sergiusens> thanks
[15:34] <tvoss> sil2100, seb128 to make sure: silo 8 shouldn't be blocking any other landings right now
[15:35] <seb128> tvoss, there is nothing in 8?
[15:35] <seb128> oh
[15:35] <seb128> it didn't even build
[15:35] <seb128> tvoss, no, it should not
[15:35] <sil2100> davmor2: hm, and what about the ringer thing in the end?
[15:35] <tvoss> seb128, even if it did build, it is just for staging the toolchain specific changes right now
[15:36] <tvoss> seb128, sil2100 can you guys hand over that information to the next "shift"? :)
[15:36] <tvoss> mandel, ^
[15:36] <seb128> tvoss, right, that's a test silo
[15:36] <tvoss> mandel, feel free to go ahead with your landing
[15:36] <seb128> tvoss, just write that in the comment column
[15:36] <davmor2> sil2100: I'm still running tests
[15:37] <sil2100> tvoss: sure ;)
[15:37] <tvoss> sil2100, seb128 updated the comments column :) thanks
[15:37] <sil2100> stgraber: ^ just so you know, silo 008 is a test silo and shouldn't block assignment of other silos
[15:37] <davmor2> sil2100: ringer seems to be working at least :)
[15:37] <seb128> tvoss, yw
[15:38] <sil2100> davmor2: but is the blocker bug still happening? ;)
[15:38] <sil2100> davmor2: I know we won't promote anyway now, but I want to at least know the situation
[15:38] <sil2100> I'm starting to feel the pressure of no promotions for a week
[15:38] <mandel> sil2100, seb128 it would be ideal to land what we have in line 16 that uses dbus-cpp before tvoss work
[15:38] <sil2100> Monday is TRAINCON-0 already
[15:39] <davmor2> sil2100: it's a race condition I'm sure of it.  So it isn't happening this time that's not to say it might not kick in again.  I would say down grade it.  Keep watching for it and when it is reproducible leave the device in that state and then get the devs involved till it is actually fixed
[15:43] <sil2100> davmor2: right, but is it something you would block on right now promotion-wise?
[15:44] <stgraber> sil2100: yeah, I noticed, I ran into this with jdstrand's landing
[15:45] <davmor2> sil2100: no that's what I'm saying downgrade it from promotion blocker to other bugs of interest or whatever the section is called and just monitor it there till some has a device back in that state and then work with the devs till it is fixed
[15:45] <davmor2> sil2100: it's to random to block on
[15:45] <sil2100> Ah
[15:45] <sil2100> davmor2: ACK, I guess that sounds sane
[15:52] <boiko> sil2100: thanks (/me was out for lunch)
[16:01] <sil2100> I'll be there in a moment
[16:08] <popey> stupid browser crash
[16:08] <sergiusens> brendand: ricmm: mandel at least according to the dbus spec; implementing introspection is optional (it says MAY and to use the RFC definition of it)
[16:26] <mandel> sergiusens, I know it is optional for objects to implement the interface... but it is very useful and everyone assumes it is there
[16:26] <mandel> sergiusens, but you know what they say when you assume ;)
[16:26] <sergiusens> mandel: then they need to request a spec update ;-)
[16:27] <mandel> sergiusens, probably, or we just have to provide an easy way to provide the instrospect for the libs, I'm thinking about how to do it with dbus-cpp 'cause it has the same issue
[16:27] <sergiusens> mandel: then usensord is not the only one causing slow downs ;-)
[16:27] <sergiusens> mandel: should just fix autopilot then ;-)
[16:28] <mandel> sergiusens, no, the dbus-cpp ones have the exact same issue, but I can just push the go-dbus problem to you hehe
[16:28] <sergiusens> mandel: if I fix it, you are next in line :-P
[16:28] <mandel> sergiusens, I do agree, the way that autopilot works is wrong, makes waaaaay to many assumptions with no scientific base
[16:28] <mandel> sergiusens, if I'm next.. can you take some time ;)
[16:28] <sergiusens> let's just call it an autopilot bug then
[16:31] <sergiusens> lolz
[16:31] <sergiusens> sil2100: ^^
[16:31] <sergiusens> just in case ;-)
[16:31] <sergiusens> not just usensord
[16:33] <sergiusens> mandel: btw, media-hub would solve it for you ;-)
[16:33] <mandel> sergiusens, it is defiently not just sensord, all daemons that do not have an Introspect interface implemented will have it, yet, there is a bug  in ygo-dbus
[16:34] <ogra_> scientific base ? whats that ?
[16:34] <mandel> sergiusens, it should raise a NoSuchInterface error instead of doing nothing :)
[16:34] <mandel> ogra_, something I just pulled out of a hat ;)
[16:34] <sergiusens> mandel: it returns MethodUnkown
[16:34] <ogra_> mandel, you magician you  !!!
 let's just call it an autopilot bug then
[16:35] <brendand_> ^ NO
[16:36] <sergiusens> mandel: http://paste.ubuntu.com/7711951/
[16:36] <mandel> sergiusens, yet autopilot has a timeout?
[16:37] <sergiusens> brendand_: reasoning?
[16:37] <mandel> sergiusens, but, you do have an object in / correct?
[16:37] <sergiusens> mandel: nope; that's why I called both; just in case
[16:37] <sergiusens> returns an error in both cases
[16:40] <mandel> sergiusens, well, an error should be returned and autopilot should deal with it, dbus does make a diff when the object is not there => http://dbus.freedesktop.org/doc/api/html/dbus-protocol_8h_source.html
[16:40] <brendand_> sergiusens, so you're saying usensord doesn't do anything wrong?
[16:40] <mandel> sergiusens, I would use #define DBUS_ERROR_UNKNOWN_INTERFACE "org.freedesktop.DBus.Error.UnknownInterface"
[16:40] <ricmm> well the case here is different, usensord (go-dbus) just timesout
[16:40] <mandel> seb128, and #define DBUS_ERROR_UNKNOWN_OBJECT "org.freedesktop.DBus.Error.UnknownObject"
[16:40] <ricmm> mandel: does dbus-cpp return an error for unavailable interfaces?
[16:40] <mandel> seb128, sorry,
[16:40] <mandel> sergiusens, ^^
[16:41] <ricmm> right, thats what the other services on the bus that arent introspectable return
[16:41] <sergiusens> ricmm: my dbus-send calls return errors
[16:41] <mandel> ricmm, I need to check I don't know it by heart
[16:41] <sergiusens> ricmm: http://paste.ubuntu.com/7711951/
[16:41] <mandel> sergiusens, I think is better to use org.freedesktop.DBus.Error.UnknownInterface for the interface, that would be the only bug I can see
[16:42] <sergiusens> mandel: I could return UnkownInterface; that's easy
[16:42] <mandel> brendand_, the fact that a dbus object is not introspectable is not a bug at all since there is no guarantee that the object implements it, that said, an error should be returned and not just a timeout
[16:42] <sergiusens> brendand_: I'm saying autopilot should not rely on things that aren't mandatory on the dbus spec
[16:43] <mandel> sergiusens, that would be ideal, since with that error we know is not a missing method but an interface not implemented
[16:43] <mandel> and is easier to spot
[16:43] <sergiusens> mandel: I'll fix that then
[16:43] <mandel> sergiusens, love it :)
[16:44] <ricmm> sergiusens: this return of yours is after a patch? or is that what you get by default on the bus
[16:44] <brendand_> mandel, does the dbus spec have an opinion on how to handle that? does it say an error should be returned?
[16:44] <ricmm> method call sender=:1.373 -> dest=:1.284 serial=2 path=/; interface=org.freedesktop.DBus.Introspectable; member=Introspect
[16:44] <ricmm> this is the blocking call
[16:44] <mandel> brendand_, and error should be returned and it it is a known one: org.freedesktop.DBus.Error.UnknownInterface
[16:45] <brendand_> mandel, i think autopilot handles the situation where the correct error is returned just fine
[16:45] <mandel> brendand_, so if you get that error in the reply, you know that you are missing the interface and you can skip the test with a nice message
[16:45] <sergiusens> ricmm: what is :1.284 ?
[16:45] <brendand_> mandel, so if that's what the spec says and usensord is not doing that, then the bug is in usensord
[16:45] <mandel> brendand_, if that is the case the only issue is go-dbus not returning the error
[16:46] <brendand_> mandel, but to repeat what i said before, i am going to suggest to them that autopilot might want to be cleverer about this eventuality
[16:46] <mandel> brendand_, we have to blame it lower in the stack, you will have the same issue with all daemons that us go-dbus
[16:46] <mandel> s/us/use
[16:46] <ricmm> :1.285
[16:46] <brendand_> mandel, what is timing out exactly? it's not autopilot because qdbus also does the same thing
[16:47] <jdstrand> sil2100: hey, so I got the MR approved and updated the changelog manually but am seeing this: https://ci-train.ubuntu.com/job/landing-007-1-build/83/console
[16:47] <mandel> brendand_, you get a timeout error from go-dbus
[16:47] <jdstrand> sil2100: do I need to reconfigure the ppa?
[16:48] <sergiusens> mandel: can you show me the timeout error?
[16:48] <sergiusens> mandel: I am not seeing it
[16:48] <mandel> sergiusens, this is from ricmm => http://pastebin.ubuntu.com/7709477/
[16:49] <sergiusens> mandel: brendand_ I don't see a timeout here http://paste.ubuntu.com/7712004/
[16:49] <mandel> sergiusens,  1.158
[16:49] <brendand_> mandel, sergiusens - please update https://bugs.launchpad.net/autopilot/+bug/1334676 with your findings so the autopilot team can decide if they need to do anything in response
[16:49] <sergiusens> mandel: usensord is a named service
[16:49] <brendand_> gotta go now
[16:50] <mandel> sergiusens, hm..
[16:51] <mandel> sergiusens, we need to get the exact tests that ricmm did
[16:52] <brendand_> mandel, http://pastebin.ubuntu.com/7709477/
[16:52] <brendand_> mandel, i asked him to follow those - he should confirm though
[16:52] <ricmm> yea, just follow that
[16:52] <ricmm> you'll see it failing to introspect that connection
[16:52] <ricmm> however I'm not entirely sure what that means, im no dbus expert
[16:53] <ricmm> certainly if you introspect usensord's name you'll get an error, no timeout
[16:53] <ricmm> but if you target that connection, it dies
[16:55] <mandel> ricmm, if it is a named service you will need to use as a named one and that might be the issue
[16:56] <mandel> I need to run to do some errands before everything close
[16:57] <mandel> sergiusens, I think that if you are returning the error the issue is the what you mentioned, it is a named service
[16:57] <AlbertA> sil2100: landing-013 ready to go
[16:58] <sergiusens> brendand: ricmm mandel well I'm going to investigate some more; but it isn't as simple as I originally thought
[16:59] <fginther> Saviq, does lp:unity-system-compositor/devel-mir-next replace lp:~mir-team/unity-system-compositor/development-branch ?
[17:06] <sergiusens> ricmm: mandel http://paste.ubuntu.com/7712099/
[17:08] <ricmm> sergiusens: works the second time?
[17:08] <ricmm> thats not the usensord connection tho
[17:08] <sergiusens> ricmm: yeah...
[17:08] <sergiusens> nope
[17:08] <ricmm> the usensord connection fails all the times
[17:12] <sergiusens> ricmm: so is it possible that the unnamed connection is the client connection? I'm not sure how that is supposed to work though...
[17:12] <jdstrand> I need help with silo 7
[17:13] <jdstrand> it is telling me to adjust the changelog, which I've done and it still fails
[17:13] <jdstrand> https://ci-train.ubuntu.com/job/landing-007-1-build/84/console
[17:13] <jdstrand> I don't know what to do at this point
[17:14] <ricmm> sergiusens: im not sure either, one sec
[17:14] <ricmm> trying some stuff
[17:14] <sergiusens> ricmm: asking pitti on #ubuntu-devel
[17:15] <jdstrand> retoaded: ^ (re silo 7)
[17:16] <ogra_> jdstrand, "a change in debian/changelog with no UNRELEASED or no content in the changelog."
[17:16] <ogra_> jdstrand, note the "no UNRELEASED"
[17:16] <jdstrand> yeah, I know
[17:16] <ogra_> change "utopic" to UNRELEASED
[17:16] <ricmm> sergiusens: well it certainly is the pid of the client
[17:16] <ricmm> so the connection might indeed be the client end
[17:16]  * ogra_ thinks that sentence needs serious re-phrasing
[17:16] <ricmm> not sure how introspection works in that case
[17:16]  * jdstrand reads the message again
[17:17] <jdstrand> I guess I got hung up on "If you modify debian/changelog in your commit, the commit message for the merge proposal isn't used"
[17:17] <ogra_> you should not have no UNRELEASED, no
[17:17] <retoaded> jdstrand, that would need one of the CI train pocs
[17:17] <jdstrand> ogra_: I'm confused, should I have UNRELEASED or utopic?
[17:18] <ogra_> negation FTW :)
[17:18] <ogra_> jdstrand, right, thats what i mean ... you should have UNRELEASED in there
[17:18] <jdstrand> ok, let me try that
[17:18] <ricmm> tvoss: are you still around?
[17:20] <sergiusens> ricmm: yeah, I don't either
[17:20] <ricmm> sergiusens: maybe dbus-cpp needs to run the bus executor in a thread?
[17:20] <ricmm> for pure-clients dbus-cpp doesnt run the bus on its own
[17:20] <ricmm> so incoming messages dont get processed
[17:20] <ricmm> because there are no registered method handlers
[17:22] <ricmm> sergiusens: going to give that a shot and see what happens
[17:22] <ricmm> I have a bad feeling that it will work
[17:22] <ricmm> lol
[17:22] <sergiusens> a BAD feeling?
[17:22] <sergiusens> lol
[17:22] <ricmm> yea
[17:23] <sergiusens> too much star wars :-)
[17:37] <jdstrand> ok, that seems to be working
[17:37] <jdstrand> ogra_: thanks
[17:45] <ricmm> sergiusens: seems to work, lol
[17:45] <ricmm> god I love these wild guesses
[18:03] <elopio> fginther: the job failed with:
[18:03] <elopio> could not import package ubuntu_experience_tests: No module named ubuntu_experience_tests
[18:03] <elopio> could it be that it's not installing the deb, or that phablet-test-run is trying to run with py2?
[18:14] <sergiusens> ricmm: hawesome
[18:17] <rsalveti> ricmm: stop breaking stuff :P
[18:20] <ricmm> rsalveti: go to china or something
[18:20] <ricmm> rsalveti: tired of you
[18:20] <rsalveti> ricmm: doing that tomorrow, no worries
[18:31] <sergiusens> fginther: I see you used your personal account to take ownership of com.canonical; this basically means you have to use your account for everything (the store doesn't support multiple accounts)
[18:31] <sergiusens> fginther: followup, a question; did you build this with click chroot?
[18:55] <ricmm> sergiusens: alive?
[18:55] <ricmm> sergiusens: https://code.launchpad.net/~ricmm/platform-api/thread-for-client/+merge/224888
[18:55] <sergiusens> yeah
[18:56] <sergiusens> just quiet
[18:56] <sergiusens> ah, cuando veo c++ me tengo que concentrar :-P
[19:34] <balloons> fginther, did you manage to update the hook for reminders? Also, is the clock-autolanding job ok? This MP doesn't seem to want to be picked up for landing: https://code.launchpad.net/~nskaggs/ubuntu-clock-app/new-pep8-fixes/+merge/224853. It's unclear what jobs are being used for clock atm, looking at jenkins
[20:07] <tvoss> stgraber, still around?
[20:09] <tvoss> stgraber, in case you come back: patched out all the universe build deps and have a packaging in the silo
[20:09] <tvoss> davmor2, mandel ^ would be great if you guys could give it a spin