[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 <IP_ADDRESS>
[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<EMAIL_ADDRESS>[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<EMAIL_ADDRESS>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


[12:30] <aaron114> Hello
[12:31] <aaron114> Does anyone know when exactly (Second) will ubuntu 9.10 be released
[12:32] <jpds> aaron114: No.
[12:32] <aaron114> jpds: Oh realy. That's too sad
[12:32] <aaron114> but it will be realeased at 29th right?
[12:33] <jpds> Yep.
[17:32] <Mamarok> newz2000: hi, the Kubuntu Ship-It page still says beta in the download link: https://shipit.kubuntu.org/


[01:24] <David80> hi, a question about installing persistence with ubuntu. Can I do this from Windows Vista onto a USB drive?
[06:26] <GMH> Hello.
[06:26] <GMH> Are the pages at docs.lubuntu.net supposed to be superseded by manual.lubuntu.me?  Because docs.lubuntu.net seems broken.
[08:37] <guiverc> GMH lubuntu.net is not a Ubuntu/Canonical/Lubuntu web site.. we have no control over what is there
[16:10] <GMH> guiverc: oh i see.  thank you
[20:23] <superlemon> hey
[20:23] <superlemon> the lemon is here


[00:51] <racarr_> wow new chromium worked on the first try
[00:52] <racarr_> that never happens :p
[00:52] <racarr_> it seems a little more responsivice perhaps...but it was never bad
[02:42] <RAOF> Oh, great.
[02:43] <RAOF> Looks like glibc's now using Haswell's fancy lock elision instructions.
[02:47] <RAOF> Making valgrind confusinated.
[03:16] <racarr_> just read alittle about the implementation
[03:16] <racarr_> that is really...fancy
[03:17] <racarr_> if someone told me to implement that I would probably just cry
[03:26] <RAOF> racarr_: Oh, re: vsync conversation above - we can pull whatever vsync related information you need out of drm.
[03:27] <racarr_> :) cool
[03:28] <racarr_> ill doa littlestudy of how chromiumis usingit and see what we should expose
[03:28] <RAOF> racarr_: Specifically, the infrastructure to support GLX_sync_control is there, so we can get the frame time and such.
[03:28]  * RAOF goes babywards
[03:29] <racarr_> :) ttyl
[05:59] <RAOF> So, um... how does this _ever_ fail to leak?
[06:01] <RAOF> Ok, new question.
[06:01] <RAOF> Why does is the leak only *fatal* on *some* of the CI infrastructure?
[06:02] <RAOF> tvoss: Good morning!
[06:02] <tvoss> RAOF, good morning :)
[09:43] <anpok> alf__: will you have time to look at the input-sender again today?
[09:48] <alf__> anpok: sure
[10:04] <anpok> not urgent, but is anybody else also affected by: https://bugs.launchpad.net/mir/+bug/1294610
[10:09] <greyback> Hi folks, a preliminary review for https://code.launchpad.net/~dandrader/mir/expose-android-input/+merge/224335 would be appreciated
[10:33] <anpok> oh the ci failure looks interesting - will propose a synchronous timer destruction then.
[10:44] <alan_g> In other news: "The Library Evolution Working Group (LEWG) voted to base the Networking TS on Boost.ASIO."
[10:45] <anpok> good timing
[10:46] <anpok> but there wasnt really an alternative, was there?
[10:50] <alan_g> It is a massive change in direction. (But probably a rational one.)
[15:49] <anpok> alan_g: wrt to https://code.launchpad.net/~alan-griffiths/mir/fix-1334287/+merge/224457/comments/538943 I want to use the action queue to sequentialize the timer callbacks and the canceling operations.. then either cancel happens before asio decides to schedule the timer or the other way round, and synchronous_server_action waits till the canceling completes..
[15:51] <anpok> so in the bad case, the callback is called during cancel waits that the server action queue executes the actual cancel operation
[15:52] <anpok> but i just messed up my solution .. need to clear my head .. and look again what I missed.. or if you want to look I could push it somewhere..
[15:53] <alan_g> anpok: ack - I'm halfway through fixing my fix, so I won't look right now. Tomorrow am?
[15:57] <anpok> yes
[15:58] <kgunn> davmor2: is there any way you could perform some smoke testing on silo20 ? this is the same silo you tested 2 days ago....
[15:58] <kgunn> we had some packaging isssues, so mostly just a rebuild
[15:58] <kgunn> but we'd like to get some external eyes on it
[15:58] <davmor2> kgunn: I can have a look after I'm just trying to trace an issue currently.
[15:59] <kgunn> rsalveti: ^ if you would like to help with testing silo20 that'd be awesome (its the display blank policy move from powerd to usc)
[16:22] <dandrader> is anyone working on getting unity-system-compositor updated against latest lp:mir/devel?
[16:23] <dandrader> I mean unity-system-compositor/devel-mir-next
[16:24] <rsalveti> kgunn: I tested it already, also replied to that thread giving +1
[16:24] <kgunn> rsalveti: thanks!
[16:25] <kgunn> dandrader|lunch: i think alf__ might have been, but got sucked into a regression/critical bug investigation
[16:25] <alf__> kgunn: dandrader|lunch: exactly
[16:26] <davmor2> kgunn: I'm off early today but when I get back I'll give you a ping with my results
[16:27] <kgunn> dandrader|lunch: dednick needs it too...if i can get someone on it today i will
[16:27] <kgunn> alf__: btw, any update on that bug ?
[16:27] <alf__> kgunn: not yet, I am trying to track what is going through all the layers
[16:27] <kdub_> which bug?
[16:29] <alf__> kdub_: https://bugs.launchpad.net/mir/+bug/1332632
[16:34] <kdub_> kgunn, I've fixed up usc locally here for my overlay work, maybe I s hould dust it up and propose
[16:35] <kgunn> kdub_: yeah, please do
[16:36] <alf__> kdub_: problem with usc is that it overrides the scene and returns renderables manually. However with the new changes it can't do that (it doesn't know how to create a SceneElement)
[16:37] <kdub_> alf__, i just wrote a SceneElement impl there
[16:37] <kdub_> that forwards the renderable along
[16:37] <alf__> kdub_: For some reason it wants to only expose surfaces from two sessions (current and next). I was thinking that instead of customizing the scene it could hide the unneeded session.
[16:38] <kdub_> alf__, yes, that seems the better approach
[16:38] <alf__> kdub_: problem is that the new SceneElement doesn't properly handle visibility events
[16:38] <alf__> kdub_: (i guess, unless you managed to do it somehow :))
[16:38] <kdub_> right, I was just realizing the visibility events in my branch wouldn't work
[16:40] <alf__> kdub_: well, if you have cycles to work on it great, otherwise I am going to pick it up again after I am done with this bug
[16:40] <kdub_> alf__, okay
[16:41] <kdub_> kgunn, so it seems my usc branch was only sufficient for testing out overlay stuff, not for landing
[16:48] <kgunn> alf__: kdub_ ack
[16:48] <AlbertA> alf__: I believe it does the current and next
[16:48] <AlbertA> alf__: so that with the split greeter
[16:49] <AlbertA> alf__: alpha transitions can be done
[16:49] <AlbertA> alf__: if you hide it, then it will just show a black screen as you slide off the greeter
[16:50] <kdub_> AlbertA, is the sliding not moving the surface?
[16:50] <alf__> AlbertA: I was thinking of hiding every other surface/session besides current and next
[16:51] <AlbertA> kdub_: no because this is under nested, they are essentially fullscreen sessions
[16:51] <kdub_> oh, and alpha channel is just arranged to look like its moving
[16:51] <AlbertA> kdub_: right
[16:51] <AlbertA> alf__: oh ok
[16:51] <kdub_> so... potential optimization
[16:52] <alf__> AlbertA: ...so then the default SceneElementSequence would be what USC wants (hopefully)
[16:52] <kgunn> mterry: ^
[16:53] <mterry> mmm, ok...
[16:53] <AlbertA> kdub_: right I mean for performance reasons... if the animation could be done in USC then that would be better since you wouldn't need alpha blending then
[16:53] <AlbertA> kdub_: it would just be surface movement
[16:53] <kdub_> right
[16:57]  * alan_g thinks it is time to get "nested" back under test
[16:58] <kdub_> indeed
[16:59] <alan_g> Something to do tomorrow.
[18:30] <Davmor3> kgunn: So this working okay
[18:34] <AlbertA> Davmor3: you mean landing-020 looks ok?
[18:42] <racarr_> im still stuck on how to get change notifications to the compositor for cursor-is-a-renderable
[18:42] <racarr_> and I am starting to wonder if maybe cursor is a surface
[18:42] <racarr_> but NOT a frontend::Surface
[18:43] <racarr_> the thing is scene::Surface would have to lose inheritance of frontend::Surface
[18:43] <racarr_> then you add like a
[18:44] <racarr_> ...ClientSurface : scene::Surface, frontend::Surface
[18:44] <racarr_> BasicSurface : ClientSurface (:/, basic surface is really just like clientsurfaceimpl)
[18:44] <racarr_> scene::Surface : input::Surface, SurfaceBufferAccess
[18:45] <racarr_> CursorSurface : scene::Surface
[18:46] <racarr_> the problem with Cursor : Renderable
[18:46] <racarr_> is you need an add_observer API
[18:47] <racarr_> but its desirable not to have RenderableObserver as...basically a parallel class to
[18:47] <anpok> racarr_:  a SceneElement maybe?
[18:47] <racarr_> SurfaceObserver
[18:47] <anpok> with a Renderable inside?
[18:47] <racarr_> but you cant just promote surfaceobserver to renderableobserver
[18:47] <racarr_> because
[18:47] <racarr_> ms::Surface is NOT
[18:47] <racarr_> a renderable
[18:47] <racarr_> so then the shell wouldn't have add_observer
[18:48] <racarr_> anpok: Yes, that part is fine
[18:48] <racarr_> the problem is, the way the compositor gets
[18:48] <racarr_> notifications is by seeing
[18:48] <anpok> if the scene changed
[18:48] <racarr_> Observer::surface_added(ms::Surface)
[18:48] <anpok> i see
[18:48] <racarr_> and calling ms::Surface->add_observer
[18:48] <racarr_> so if its not a surface observers wont work
[18:48] <anpok> that is correct as long as there are only surfaces in a scene
[18:49] <anpok> scene::Surface that is
[18:49] <racarr_> but surface is NOT a renderable (it produces renderable snapshots)
[18:49] <racarr_> so you cant just make it Renderable::add_observer
[18:49] <racarr_> yes
[18:49] <racarr_> so either somehow I need to untangle that
[18:49] <anpok> yes
[18:49] <racarr_> or! make
[18:49] <racarr_> the Cursor a surface.
[18:49] <racarr_> but its pretty clearly NOT a frontend::Surface
[18:49] <racarr_> so that hierarchy would have to be untangled
[18:52] <anpok> and untangling the hierachy is close to untangling scene / surface / renderable
[18:52] <racarr_> Mm
[18:52] <anpok> and i think the latter is the one we are aiming for in the long run?
[18:53] <anpok> but dont listen to me i am prone to prefere big changes
[18:54] <racarr_> i am just worried it will get so big
[18:54] <racarr_> that I will spend a week
[18:54] <racarr_> porting all the client code and test code and stuff
[18:54] <racarr_> to new interfaces
[18:54] <racarr_> and then...um
[18:55] <racarr_> it will be wrong for some reason lol
[18:55] <racarr_> because im still not confident
[18:58] <racarr_> I kind of like this
[18:58] <racarr_> um
[18:58] <racarr_> scene::Surface : input::Surface, SurfaceBufferAccess { ... add/remove_observer... }
[18:59] <racarr_> i.e. what the two views of the scene require.
[18:59] <racarr_> and Client(/Application?)Surface : scene::Surface, frontend::Surface
[19:00] <racarr_> trying to figure out how much churn its going to cause...who uses implicit cast...from scene::Surface to frontend::Surface or uses the frontend::Surface methods in scene::Surface.
[19:03] <racarr_> i.e. the shell primarily deals with scene::Surface...
[19:03] <racarr_> and you dont want the shell to have to dynamic_cast<frontend::Surface>
[19:03] <racarr_> but the shell does want to call things like mf::Surface::configure(attrib, val)
[19:03] <racarr_> so you end up needing those methods on scene::Surface anyway
[19:04] <racarr_> which. means the cursor has to implement them, but shouldn't
[19:04] <racarr_> potentially the shell could work in terms of
[19:04] <racarr_> ClientSurface.
[19:04] <racarr_> Window : scene::Surface, frontend::Surface?
[19:04] <anpok> the shell might want to add other things to the scene
[19:04] <racarr_> ...just throwing that one out there :p
[19:05] <anpok> not just the cursor.. or surfaces.. i think some form of type detection will be necessary as soon as it turns into a tree
[19:05] <racarr_> maybe on the view sides
[19:06] <racarr_> but if on the client side, i.e. shell code manipulating surfaces
[19:06] <racarr_> all the code looks like
[19:06] <racarr_> i.e. the wm code
[19:06] <racarr_> "cast to frontend surface/cient surface/whatever, if it is one do stuff, if not return"
[19:06] <racarr_> then that cant be right
[19:07] <anpok> hm what is wm code?
[19:07] <racarr_> ill be honest I kind of miss mir::shell::Surface
[19:07] <racarr_> anpok: Wiondow management code
[19:08] <anpok> yeah, but what is it? Raof mentioned in malta ... that you would probably have the tree of things that you want to traverse to insert new items or manipulate them.. dispatch input .. draw.. and another set of things which represents the clients and the attached surfaces..
[19:09] <racarr_> what is it in what sense?
[19:09] <racarr_> I mean its unity-mir
[19:09] <racarr_> but I feel like thats not what you are asking lol
[19:09] <anpok> :)
[19:09] <racarr_> but right there is this
[19:09] <racarr_> well there could be
[19:09] <racarr_> this shell side view of the scene v.
[19:10] <racarr_> the compositor side view.
[19:10] <racarr_> but I guess we sort of had something like that and it was wildly unpopular and took a lot of time to consolidate
[19:10] <anpok> I think that the view part looks like what you said above .. traverse and figure out the type of elements.. and I think the WM code will interact with actual windows/surfaces partially ignoring the graph  in many cases
[19:10] <anpok> ah
[19:11] <racarr_> hmm..
[19:12] <racarr_> I have a whole other tree of thought
[19:12] <racarr_> as a potential fix for the cursor...but im not sure
[19:12] <racarr_> how promising it is
[19:12] <racarr_> that maybe, rather than the compositor observe and then ask for renderable lists on changes
[19:13] <racarr_> the compositor is given the renderable list.
[19:13] <greyback> does cursor really have to be part of scene? It might better belong in a layer on top all for itself
[19:13] <AlbertA> ummm I seem to remember alan pragmatically suggesting just sending the renderables + cursor
[19:13] <AlbertA> a while ago
[19:13] <racarr_> sending the renderables + cursor?
[19:13] <racarr_> greyback: In this branch so far it is in a special layer in the surface stack
[19:13] <AlbertA> right to the compositor
[19:13] <racarr_> greyback: The point is its in the "RenderableList" that the compositor sees
[19:14] <AlbertA> which can then always put it on top, etc...
[19:14] <racarr_> Oh in the sense of sending them v. the surface stack asking for them
[19:14] <greyback> racarr_: sure I get that. But since you're struggling to incorporate cursor into the scene, perhaps it doesn't belong there at all
[19:15] <AlbertA> racarr_: basically cursor would not be in RenderableList
[19:15] <AlbertA> but separate
[19:15] <AlbertA> it seemed to make sense at the time (a few months ago)
[19:15] <racarr_> but then how do you know
[19:15] <racarr_> when to ask for it?
[19:16] <racarr_> when its changed
[19:16] <AlbertA> at the same time as when the renderables are obtained
[19:16] <racarr_> but thats in response to callbacks from SurfaceObserver
[19:16] <racarr_> you could add like
[19:17] <racarr_> ms::Observer::cursor_moved()
[19:17] <AlbertA> yeah that would make sense to me
[19:17] <racarr_> but its starting to feel kind of clumsy at that point I think...why am I dealing with the cursor so seperately?
[19:18] <AlbertA> because it's not a surface? lol
[19:18] <racarr_> everything except mesa with hardware cursor, literally just treats it like any other renderable
[19:18] <racarr_> but
[19:18] <racarr_> the compositor doesnt consume surfaces
[19:18] <racarr_> it consumes
[19:18] <racarr_> renderables
[19:18] <racarr_> it just uses surfaces to know when
[19:18] <racarr_> renderables are ready to be consumed
[19:18] <racarr_> is the problem
[19:18] <AlbertA> true...I guess it depends on who is in charge
[19:18] <AlbertA> of the z-policy
[19:18] <AlbertA> I guess scene is
[19:18] <AlbertA> not compositor
[19:19] <AlbertA> so yeah it would make sense for it to be in the renderablesList
[19:19] <racarr_> render list generalizes nicer to
[19:19] <racarr_> touch spot visualization as well
[19:19] <racarr_> than cursor_moved() which starts to become
[19:19] <racarr_> increasingly nebulous
[19:20] <AlbertA> yep yep
[19:20] <racarr_> maybe...ms::Observer is the wrong interface for the compositor
[19:21] <AlbertA> so is the issue that right now you would have to work the cursor into surfacestack?
[19:21] <racarr_> well, that part isn't so bad
[19:21] <racarr_> there I am specializing it, the surface stack has a cursor built in (or perhaps you add/remove_input_visualization(mg::Renderable))
[19:21] <racarr_> and they show up in generate_renderable_list
[19:21] <racarr_> but not input::for_each, etc
[19:22] <racarr_> the problem is just about the notifications really
[19:22] <racarr_> because, the compositor receives surface_added(ms::Surface) and uses that to install
[19:22] <AlbertA> oh I see...
[19:22] <AlbertA> like if only the cursor moves
[19:22] <racarr_> a SurfaceObserver
[19:22] <racarr_> yeah
[19:23] <racarr_> and then. the SurfaceObserver interface cant be changed
[19:23] <racarr_> to RenderableObserver i.e. renderable_added(mg::Renderable), etc
[19:23] <racarr_> because Unity-Mir uses it
[19:23] <racarr_> and mir::scene::Surface is NOT a renderable
[19:23] <racarr_> it just generates one
[19:24] <AlbertA> so what about a generic notification in Scene::Observer
[19:24] <AlbertA> like scene_changed...
[19:25] <AlbertA> so that it's just opaque enough
[19:25] <racarr_> AlbertA: That's kind of...what im close to giving up and trying...but thats going to make it really hard to implement
[19:25] <racarr_> partial updates right
[19:25] <racarr_> because...what could you do
[19:25] <racarr_> keep around a copy of the old render list
[19:25] <racarr_> then generate a new one
[19:25] <racarr_> and diff them?!
[19:26] <racarr_> it's kind of painful
[19:26] <AlbertA> you mean partial updates by the compositor? or just a general observer
[19:26] <racarr_> by the compositor
[19:27] <racarr_> i.e. the cursor is moving around just paint
[19:27] <racarr_> tiny regions
[19:27] <AlbertA> ummm but that's not our compositor architecture
[19:27] <AlbertA> we do full frame updates
[19:28] <AlbertA> I mean I envision
[19:28] <racarr_> I guess I thought we were going to make it smarter and that was part of hte motivation
[19:28] <AlbertA> once we have a tree
[19:28] <racarr_> behind
[19:28] <racarr_> ms::Observer
[19:28] <racarr_> vs the old
[19:29] <racarr_> std::function<void()> notify_change
[19:29] <AlbertA> every change we optimize drawing on the current tree...
[19:29] <AlbertA> but not damage based composition
[19:30] <racarr_> maybe...
[19:30] <racarr_> hmm so with the generic notification
[19:30] <racarr_> how do prevent double draw.
[19:30] <racarr_> i.e. surface_changed also generates scene_changed
[19:30] <racarr_> or is it not really a
[19:31] <racarr_> "generic" notification but rather like
[19:31] <racarr_> "scene_changed_in_a_way_the_other_callbacks_dont_represent"
[19:31] <racarr_> or
[19:31] <AlbertA> right
[19:31] <racarr_> does the
[19:31] <racarr_> compositor just use
[19:31] <racarr_> scene_changed
[19:31] <racarr_> and ignore the
[19:31] <racarr_> sort of damaged based ones
[19:31] <racarr_> SO MANY OPTIONS SO LOW BLOOD SUGAR
[19:32] <AlbertA> yeah...good points
[19:35] <racarr_> haha ok lunch...then I think I am going to come back and get something pumped out with the generic callback..
[19:35] <AlbertA> but doesn't SurfaceObserver kinda have the same issue right now? I mean if an observer was listening to say orientation_set_to and transformation_set_to
[19:35] <racarr_> thanks AlbertA anpok :)
[19:35] <racarr_> AlbertA: ?
[19:35] <racarr_> oh
[19:35] <racarr_> yes
[19:35] <AlbertA> I mean right now they all get collapsed to one notification
[19:35] <racarr_> but they should be intelligent
[19:35] <racarr_> for example the cursor controller one is
[19:35] <racarr_> and doesnt
[19:35] <racarr_> collapse on
[19:36] <racarr_> surface attribc change, orientation, etc
[19:36] <racarr_> because those by themselves
[19:36] <racarr_> arent enough to
[19:36] <racarr_> change the actual position
[22:47] <dandrader> kgunn, alf__: FYI: I've started updating unity-system-compositor/devel-mir-next to latest lp:mir/devel myself as this is blocking me anyway
[22:49] <kgunn> ack
[23:59] <racarr_> [       OK ] TestTouchspotVisualizations.touch_is_given_to_touchspot_visualizer (12 ms)
[23:59] <racarr_> whee
[23:59] <racarr_> I made...a dumb mistake in all of this
[23:59] <RAOF> Heh
[23:59] <racarr_> in that...once I figured out cursor is a renderable...I started thinking about the interface
[23:59] <racarr_> I would want for touchspots
[23:59] <racarr_> and realized that
[23:59] <racarr_> it was exactly the same as the interface that I thought of exposing
[23:59] <racarr_> as a temporary solution
[23:59] <racarr_> tounblock thomi


[17:42] <stokachu> fabrice: i was wondering what still needed to be done for https://github.com/juju/theblues/pull/8 to finalize?
[17:42] <stokachu> i have my own debian package repo for theblues as well
[17:42] <rick_h__> jrwren: ^
[17:43] <stokachu> also is this package blocked on anything for making it into the official archives?
[17:44] <jrwren> stokachu: I don't know. going to official was never a goal. It may not pass deblint
[17:46] <jrwren> stokachu: ah, it depends on libmacaroons which is not in official archives, so there is a dep chain up which would need to become official.
[17:46] <stokachu> ok, is there any word on if libmacaroons will be in the official archives for xenial?
[17:48] <jrwren> stokachu: I know of no effort. Maybe best to ask in #ubuntu-devel
[17:49] <jrwren> stokachu: or even check debian WNPP?
[17:50] <stokachu> how are you guys using it?
[17:50] <stokachu> just compiling from source?
[17:50] <jrwren> stokachu: we packaged libmacaroons ourselves, so again, probably much deblint. Never with scrutiny of an official archives package
[17:51] <stokachu> so is it safe to say then i shouldn't be relying on theblues for our projects?
[17:52] <rick_h__> stokachu: it's safe to say we should be working to get that pushed farther. theblues is supposed to be the client library we offer folks as a canonical supported tool.
[17:52] <rick_h__> stokachu: it's just not gotten the attention/roadmap love as it's been young and mostly used on the team
[17:53] <stokachu> no worries, im just in a bit of a time crunch with this other project that uses the charmstore api
[17:53] <stokachu> and i don't see getting libmacaroons in debian then ubuntu anytime soon
[17:53] <rick_h__> stokachu: you need it packaged and in before freeze?
[17:53] <stokachu> yea
[17:53] <stokachu> i can always just use requests and call out manually
[17:53] <rick_h__> yea, I don't think the team realized that
[17:54] <stokachu> nah i didn't tell anyone I needed that either
[17:54] <rick_h__> we'd prefer to use the client tool and to make it official and avoid the juju based library messes of the past
[17:54] <stokachu> as this project was kind of last minute
[17:54] <stokachu> yea
[17:54] <rick_h__> stokachu: understand.
[17:54] <jrwren> the requests calls can get tricky with auth and macaroons IIRC.  But I may be confused on that.
[17:54] <stokachu> well whatever i can do, i can get into debian mentors and get libmacaroons packaged
[17:54] <stokachu> it's just finding someone to quickly pull it in before our freeze
[17:54] <rick_h__> stokachu: I don't think we can get it in before freeze. The team is sprinting next week and the package does work
[17:55] <stokachu> yea
[17:55] <stokachu> so right now im only using the api to pull in a bundle file
[17:55] <rick_h__> stokachu: if we can find someone to help review/push it along we can ask the team to help with the items
[17:55] <stokachu> could probably ask stephane or xnox
[17:56] <rick_h__> stokachu: the team will need someone to help them build out the required effort to see what needs doing
[17:56] <stokachu> ah
[17:57] <stokachu> ill see what it takes to get libmacaroons packaged
[17:57] <rick_h__> stokachu: ty, if you can get a cursory list of what's ungood in the current package then we can chat how much time it'll take to address.
[17:57] <stokachu> since theblues is really ubuntu only that shouldnt be as bad
[17:57] <rick_h__> stokachu: thank you
[17:57] <rick_h__> stokachu: yea
[17:58] <stokachu> np
[17:58] <stokachu> i ran a lintian against my theblues package and it didn't give any bad errors


[01:57] <reformed> goons pop up everywhere!
[02:00] <zenwhen> huh
[02:00] <zenwhen> Whats your forums name?
[02:02] <zenwhen> oh well
[02:02] <zenwhen> Gmail, this channel isnt very active either. XD
[02:13] <Gmail> what
[04:11] <zenwhen> hi
[04:11] <zenwhen> :D
[04:19] <Gmail> zenwhen: yo
 huh
 Whats your forums name?
 oh well
 Gmail, this channel isnt very active either.  Have a nice night. :*
[04:22] <Gmail> night?
[04:22] <Gmail> its day
[09:34] <jordi> apparently I have the ubuntu virus. :/
[09:49] <crimsun> is it terminal?
[09:52] <jordi> no. you get better in 1 or 2 days. sucks though.
[09:54] <crimsun> ah
[09:55] <crimsun> I have the awful Debian virus.
[09:56] <crimsun> I've been sick for many years. :<
[10:08] <azeem> crimsun: jordi once even had the Hurd virus, so go figure
[01:43] <Treenaks> balls???
[01:44] <Simira> ok, no further details needed
[01:44] <Treenaks> jordi: older, more experience
[01:48] <jordi> heh
[01:48] <jordi> paper balls, or whatever they were.
[01:48] <jordi> ooh
[01:48] <jordi> I see the difference in today's death in a bag.
[01:49] <jordi> They added tomato to the bread
[01:49] <mgedmin> my bread had no tomatoes, thanfully
[01:49] <Treenaks> toma'oes? that sounds british :)
[01:49] <jordi> I don't like crude tomato too much either.
[01:50] <jordi> but it makes the lunchpack slightly better.
[01:50] <jordi> stress "slightly"
[01:50] <Treenaks> hey at least they won't let you die...
[01:50] <Treenaks> not easily, anyway
[01:52] <Kamion> jordi: hey, I hit him ... eventually
[01:53] <jordi> missed that, sorry :)
[01:54] <jordi> heh
[02:57] <jordi> it was delicious.
[02:57] <Treenaks> jordi: you sure?
[02:58] <jordi> no, it's probably the Kas orange which seemed to be in bad condition (bob2 can assert), making me believe that the food was good.l