[00:15] lifeless: looks like it is my work. will fix that up [00:16] rick_h: So, Sidnei explained himself, and I've rejected my convoy MP. [00:16] rick_h: So I'll be sorting out combo-url today, after I fix a critical regression. That I caused. :-( [00:16] StevenK: yea, saw that. Does his stuff work then? [00:17] StevenK: ouch, gotcha [00:17] Seems to, yes. [00:17] StevenK: cool, very nice then [00:17] StevenK: for my edification, whats the MP url ? [00:18] lifeless: Which MP? [00:18] the convey one [00:18] I'd like to see what sidnei has proposed [00:18] lifeless: https://code.launchpad.net/~stevenk/convoy/exportable-app [00:19] he's right, I should have seen it, but got hung up on the wsgi callable args [00:19] root = environ.get('CONVOY_ROOT', '/srv/launchpad.dev/convoy') [00:19] Sorry I led you around the fence there StevenK [00:19] app = combo_app(root) [00:19] return app(environ, start_response) [00:19] That ^ works [00:19] right [00:20] heh [00:21] rick_h: I'll be splitting the setup.py changes into a seperate MP, but they are only a would be nice. [00:22] sinzui: i'm having trouble reproducing the badge issue on lp.dev. i created a private bug, linked to a branch, assigned bug to foo, in a separate browser logged in as foo, went to code page, and badges were visible. i restarted lp and badges were still visible [00:22] wallyworld: foo being name16, the admin? [00:22] no, name12 [00:22] Hmm [00:22] What about no-priv? [00:22] let me try [00:23] name12 does have some privs. [00:23] owns some projects, IIRC [00:23] May even be in ubuntu-team [00:23] StevenK: cool [00:24] wgrant: sinzui: assigning to no-priv seems to reproduce it [00:24] wgrant: btw, what happened to the password when logging in on lp.dev? [00:26] wallyworld: I deleted passwords [00:26] LP doesn't know about passwords any more. [00:26] So I removed the field. [00:27] And deleted the code. \o/ [00:27] And DB tables. [00:27] ok. so sso is the service that prompts for pw? [00:27] On prod? Yes [00:27] Yep [00:28] LP's AccountPassword table has been sitting around with old data since April 2010. [00:28] Basic auth even still worked with the old passwords :) [00:50] sinzui: found the issue. added comment on the bug [01:36] wallyworld, great news. Thank you for taking a look into the issue. [01:36] sinzui: np. it's all a mess - there's duplicated code that "does the same thing" from 2007 and 2009 [01:37] You get to delete lines. We should get karma for deleting lines of code instead of adding features [01:37] sinzui: i have a fix and test i could land but i think i'll delete the dup code. i'm worries about the sql though since one codebase uses permissions and the other direct queries. i'll look into it [01:40] * wallyworld has just got a call from the mechanic - have to pop out to get car looked at [02:34] wgrant: Hai. I *think* I have it working. Would you mind eyeballing my diff? [02:37] How does this even work? The mutator method isn't on the model. [02:37] StevenK: The mutator method is on the model... [02:38] I've declared it on the interface, with the decrations. [02:38] You declare it there, but the method itself is on the model. [02:39] Right. What I'm saying is my test passes, but I haven't even written the method yet. [02:39] StevenK: I think wgrant is trying to say 'interface methods never ever ever actually get called' [02:39] Perhaps the set_attributes="visibility" is wrong wrong wrong. [02:40] StevenK: The mutator is to prevent unauthorized transitions. [02:40] wgrant: http://pastebin.ubuntu.com/833450/ [02:41] StevenK: Right. I would add visibility to IPersonEditRestricted. [02:42] StevenK: And add a test to confirm that a mortal without commercial subs can't set the visibility through the API. [02:43] Erm, no, not that interface [02:43] Do it however the rest of the launchpad.Edit-write-restricted attributes are done. [02:46] I thought that was IPersonEditRestricted [02:46] Maybe it is. [02:55] from lp.services.verification.model.logintoken import LoginToken [02:55] * StevenK glares at his mouse [03:26] * wgrant banishes bug search to a separate module. [03:28] Could you perhaps banish it to something outside of the code base? [03:31] heh [04:09] wgrant: http://pastebin.ubuntu.com/833507/ is what I have so far, but it doesn't allow anyone to check visibility [04:21] StevenK: Looks like a good start [04:21] Ah, Launchpad. [04:21] IBugTask has three methods which do similar but not quite the same thing for different targets: getStatusCountsForProductSeries getBugCountsForPackages getOpenBugTasksPerProduct [04:34] http://lpqateam.canonical.com/qa-reports/deployment-stable.html looks rather odd, are parts not updating>? [04:35] james_w: What's odd? [04:36] it's saying that a revision can be deployed that already has [04:36] and that an undeployable revision has been deployed? [04:36] Right, that's the last revision that can be deployed. [04:36] Deployed to qastaging, yes. [04:36] or is qastaging not the target? [04:36] That page shows things that are on qastaging but not on production. [04:36] ah, ok [04:37] qastaging automatically updates about 40 minutes after buildbot blesses a devel revision. [04:37] "Revision 14747 can be deployed to production." is what started my confusion [04:37] it looks like 14747 is *already* deployed to production? [04:37] Right. [04:38] But it also can be deployed :) [04:38] ok :-) [04:39] do you know where the code for this lives? [04:39] lp:qa-tagger [04:39] thanks [05:28] lifeless: would you be adverse to me adding a permission "launchpad.CommercialSubscriber"? [05:32] wallyworld: That's not needed here. [05:32] wallyworld: Since you have project scope to work with. [05:33] launchpad.Edit with a mutator checking that there is a commercial subscription is fine. [05:33] wgrant: we currently have a declarative permission check on that field for launchpad.Moderate. seems like a good practice [05:34] It also doesn't really scale, as we see here. [05:34] declarative security = good [05:34] i'm sure we can find other usages for the new permission [05:35] Yes, declarative security is good. [05:35] instead of hard coding rules everywhere [05:35] But not in the current style we have. [05:35] not sure i understand your objection? [05:36] Having to define new global permissions is a bit icky. [05:36] why? [05:36] Because we end up with stuff with three subtly conflicting meanings, like launchpad.Moderate. [05:37] the meaning is pretty well documented in permissions.zcml [05:37] Heh [05:38] my view at the moment is that we have too many permission checking bits of code scattered everywhere [05:38] and i don't want to add another [05:39] the bug i fixed this morning was due to this sort of thing [05:39] so if i have to add something, i wanted it to be done using our current security framework [05:39] We don't have a security framework.. [05:39] we do - it's provided by zope [05:39] The one we inherit from Zope is not suitable for our purposes. [05:42] seems to be doing ok for now - it functions, no? may not be perfect but it's what we have [05:46] Huh? [05:46] so i'd rather stick to that than adding new stuff [05:46] We work around it in tonnes of places. [05:46] For this sort of thing. [05:46] wallyworld: bug this morning ? [05:46] wallyworld: the merge proposal one ? [05:46] lifeless: the bug badges one [05:46] wallyworld: bug # ? [05:46] * wallyworld looks [05:46] bug 741234 [05:46] <_mup_> Bug #741234: product:+code-index merge proposal queries do not show private bugs visible by assignment < https://launchpad.net/bugs/741234 > [05:46] ok [05:46] so that has nothing to do with declaritive security [05:46] and everything to do with querying too restrictively - duplication of code yes [05:46] i meant that it had to do with bits of security code scattered everyehrre [05:46] and delarative security helps avoid that [05:46] mmm [05:46] It can't avoid that. [05:46] so there is a layering confusion in this discussion [05:46] This is exactly the sort of thing that cannot be done with anything like the Zope security framework that we inherit. [05:46] the DB layer, unless we model *everything* [and thus don't need any zope security framework stuff] cannot implement all business rules. [05:46] The app server layer, unless the DB returns *only* the right stuff, cannot validate and serve content quickly, unless they hold all objects in memory all the time [more-or-less, and close enough for the purpose of this discussion] [05:46] today, we neither model everything (e.g. the appservers do not impersonate the user who made the request - the DB does not know about users and cannot enforce update business logic like 'bug supervisors can set this enum') [05:46] nor can we hold everything in memory in every appserver process [05:46] agree with all that [05:46] the issue at hand - we have a field protected in zcml by a declarative permission. i want to change that to a new one [05:46] -> we have two entirely different layers, which need entirely different implementations even though there are many rules which will occur at both levels [05:46] wallyworld: ok, well I went on this tangent when you used the bug this morning as a symptom of what you're dealing with this afternoon :P You can understand my confusion? [05:47] wallyworld: what are you working on this afternoon ? [05:47] lifeless: sure, sorry. i was merely trying to illustrate a point [05:47] bug 885503 [05:47] <_mup_> Bug #885503: Its not obvious on the UI how to choose to have all bugs reported against your project marked private by default. < https://launchpad.net/bugs/885503 > [05:47] the private_bugs field is protected by launchpad.Moderate [05:47] wallyworld: I'm horribly detail orientated - sorry! [05:48] i was thinking about using a new permission launchpad.CommercialSubscriber [05:48] since that's what defines the editablity of that field once the bug is fixed [05:48] or i could use a mutator like wgrant suggested but i didn;t want to do that [05:48] so, your logic here is 'add a new rule saying 'members of commercialsubscribers get commercialsubscriber on the product configuration' [05:49] The editability of the field is defined by (user holds launchpad.Edit on project + project has commercial subscription) [05:49] s/logic/proposed solution/ [05:49] i was also thinking we could use the permission elsewhere [05:49] not sure where right now... but [05:50] so, AIUI the zope way of doing this is to only grante Moderate to the field for the right folk [05:50] e.g. its just granted too leniently atm [05:50] or too restrictive [05:50] and probably you'd end up factoring out a separate object so that the granularity of the permission system would allow custom rules for that field(s) [05:50] since we want to allow folks other than registry and admin [05:51] specifically, permissions *should not* reflect 'combination of rules' - they should reflect 'allowed to do X' [05:51] so yes, I object. [05:51] it doesn't fit with the zope security model [05:51] (AIUI) [05:51] np, thanks for the input [05:52] gotta fly out and get the kid from school - it's just started to piss down rain here [05:52] wallyworld: I complete share your concerns about security code being everywhere. [05:52] the /adapters/ that grant moderate for objects of IFoo - thats where there rules, and combinations of rules, are meant to live [05:52] But I don't think we should shoehorn everything into the Zope model. [05:52] Because we've seen it simply doesn't work. [05:52] so I'd rephrase the problem as 'why isn't lp.Moderate being granted to $user on $field' and chain back. [05:53] we may find the zope model isn't granular enough, and we can look at how to deal with that [05:53] wallyworld: ciao, chat later [05:53] lifeless: i haven't looked where else moderate is used, don't think chaining will necessarily work perhaps [05:54] talk later [05:56] lifeless: Max heat demolition has landed. [05:56] lifeless: I'll land the aging removal tomorrow once these get through to db-stable. [06:09] Anyone know if there is a workaround to this ec2 land error? https://pastebin.canonical.com/59669/ [06:12] Think it is because the branch is owned by a team, not a person [06:13] stub: You'll have to either hack it or ec2 test and lp-land manually. [06:14] Yer, looks like a trivial fix. Just one more thing to sort before actually landing what I wanted to land :) [06:18] But of course, I only need the fix locally to use it and can land later. [07:36] wgrant: cool [07:37] wgrant: btw what was the change from max heat to bug count - I saw a reference fly by but didn't look into it [07:43] lifeless: The ordering on DistroSeries:+needs-packaging [07:44] ie. nobodycares [07:44] Sort of like hardware bug searches. [07:44] Tag sorting. [07:44] Blueprint sorting. [07:45] Except those three are a little harder to remove without people noticing. [07:49] Is it my imagination, or are ec2 errors 'psycopg2.OperationalError: FATAL:  could not open relation mapping file "global/pg_filenode.map": No such file or directory' rather common? [07:49] I've had approximately two of them ever. [07:49] db setup must be failing, or ram disk being full or something? [07:49] hmm... [08:13] oh... think it is picking up my PG9.1 image rather than the 8.4 image [08:14] * stub gets explicit === almaisan-away is now known as al-maisan === al-maisan is now known as almaisan-away [08:54] wgrant: e.g. sortbypopcon would be win [08:55] good morning [08:55] lifeless: If we had it :) [08:55] But LP doesn't really consume. [08:55] It subsumes :( === almaisan-away is now known as al-maisan [10:08] gmb: Bwahahaha at your Churchill comment on FB. === al-maisan is now known as almaisan-away [11:18] adeuring: If you QA r14748 and r14755 we can probably deploy [11:19] StevenK: ah,. ok, let me look... [11:33] morning party people [11:44] StevenK: done [13:31] adeuring: can you do me a fav and peek at this really quick? https://code.launchpad.net/~rharding/launchpad/graph_lpjs_928500/+merge/92024 [13:31] rick_h: sure [13:31] ty, very small but want to get it going [13:34] rick_h: looks good. thanks for this fast fix! [13:35] adeuring: ty [13:39] bah, anyone seen broken ec2 land in get_stakeholder_emails in autoload.py? [13:49] nvm, found it, bug https://bugs.launchpad.net/launchpad/+bug/928853 in case anyone hits it [13:49] <_mup_> Bug #928853: ec2 land fails if there is no None value in the stakeholder email set < https://launchpad.net/bugs/928853 > [14:03] adeuring: another one please if you have a sec, sorry https://code.launchpad.net/~rharding/launchpad/ec2_land_928853/+merge/92033 [14:03] rick_h: sure, np [14:04] rick_h: r=me. [14:04] adeuring: ty [14:05] jcsackett: hi, there's only one way to figure out what badges to show - i removed the duplicate code [14:06] wallyworld_: i only see you removing the bug badge code; BranchBadges still exists, as does HasBadges &c. [14:06] wallyworld_: i was referring to the problem that over all of LP we now have multiple ways of doing things--which isn't a problem you introduced, it clearly already existed. [14:07] from memory HasBadges is a base class/interface and the code in branchlisting uses BranchBadges/HasBadges to do it's work, but now there's only the one way of doing it [14:08] it's a bit convoluted, but there is only the one code path [14:08] wallyworld_: ok. [14:08] it's a bit hard to explain on irc - i'll fill you in on the standup [14:08] wallyworld_: i won't be at tonight's standup. we'll have to discuss at the next one. but please do fill me in. :-) [14:09] thanks again for solving that bug. good to know that i was just looking in an entirely the wrong place. :-) [14:09] will do. i'm fairly sure i'm correct in my assertion but still i may have made a mistake. it was a lot clearer in my mind several hours ago when i did it [14:10] np. i can see where the confusion crept in - there we 2 methods to determine whether to show bug badges [14:10] and one was never called by the view code [14:10] hence your test passed but it still failed in practice [14:11] there pseudo dup code was done in 2007 and in 2009 [14:11] so i deleted the 2nd way (which was inferior anyway since it made one sql per linked bug) [14:12] and now there's a single method that is invoked when the branch listing renders and i reimplemented it to re-used the bug privacy filter stuff instead of doing it's own thing [14:13] which was the real root cause here [14:13] ie duplicated (but not) bug visibility code [14:13] messy [14:32] adeuring, abentley -- reminder that standup is G+. I sent invites. [14:46] abentley, adeuring, rick_h -- ah, one more thing, I will take lunch offline so I can get back into my gym routine and relocate to Wendy's shop. [14:46] ok [14:46] deryck: good stuff, go kill the treadmill [14:49] rick_h, it usually is the one doing the killing. [15:09] sinzui: I have pocketlint 0.5.27-0gdp410~oneiric1 installed, and it's broken with doctests. Known issue? [15:10] abentley, no. please report a bug at https://bugs.launchpad.net/pocket-lint so that I can get a fix in today [15:13] sinzui: bug #928903 [15:13] <_mup_> Bug #928903: Pocketlint is broken with doctests < https://launchpad.net/bugs/928903 > [15:14] abentley, I might have this fixed in the hour. I need to save my blog post first [15:25] adeuring: Could you do a review for me? It's a one-liner. https://code.launchpad.net/~abentley/launchpad/stable-test-failures2/+merge/92047 [15:27] abentley: sure [15:27] adeuring: thanks. [15:28] abentley: r=me === Ursinha is now known as Ursinha-lunch [15:35] rick_h: know anything about jsbuild failures? http://pastebin.ubuntu.com/834010/ [15:36] abentley: looking [15:36] abentley: is this off devel? /me looks if the combo stuff from SteveK landed [15:37] rick_h: This is off stable. [15:37] rick_h: r14759 [15:38] abentley: make clean? I'm not seeing that locally [15:40] rick_h: That works, but if I delete build/js/yui/yui-3.3.0/yui/yui.js it breaks again. [15:40] abentley: ok, SteveK has a branch that redoes how that build stuff works that should be coming really soon [15:41] it's been reviewed [15:41] rick_h: cool. [15:41] abentley: so if it's ok, we'll just think to test it once it lands [15:42] rick_h: Sure. [16:20] abentley, pocket-lint is fixed, you will get the package in about 4 hours [16:21] sinzui: Thanks! === matsubara is now known as matsubara-lunch === Ursinha-lunch is now known as Ursinha === matsubara-lunch is now known as matsubara === salgado_ is now known as salgado [19:07] lifeless, do you want to talk about our plans for work-items in LP or are you happy with what we described on the mailing list? [19:11] salgado, I believe lifeless is dismantling a droid to get a message to General Poster about the plan for the death star [19:14] heh === abentley changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: abentley | Firefighting: - | Critical bugtasks: 4*10^2 [19:27] salgado: I would enjoy chatting about it, but you shouldn't block on us talking; I've got no timeslots today but perhaps tomorrow (you can check my google calendar) [19:31] rick_h: btw [19:31] rick_h: talking of template engines, handlebarsjs.com is horribly misleading vs the actual handlebars.js git repo. (e.g. examples that don't work ...) [19:32] lifeless: :( sucky. [19:33] meh, its advertising site [19:33] I tried an experiment, and found errors on the site, so went 'wtf'?!?!?! [19:33] (also note the total lack of contact details >< hard to file a bug... [19:33] yea, that's beyond annoying when the main examples don't work [19:34] rick_h: the example 'Handlebars HTML-escapes values returned by a {{expression}}. If you don't want' ... is the first (perhaps only) one that was wonky [19:34] a vs A [19:34] small thing, but quite disappointing [19:34] * rick_h is now curious how different Y.Handlebars might be from the git repo [19:34] I've not tracked how the pulling in has gone from the YUI side [19:35] I'd be interested to know, it has some bearing on my experiment [19:35] as does the breadth of features yui itself uses from within handlebars [19:37] lifeless: right, I'll check that out. I'm curious now. The framework isn't using much, but my understanding is that they're using for internal/public apps that should be working it a bit [19:37] but not sure which apps have it so I'll ask/check [19:39] lifeless: https://pastebin.canonical.com/59772/ [19:39] lifeless: basically any file in that dir yui- is yui customizations, some api docs, tweaks [19:40] thanks [19:40] what channel is that ? [19:40] #yui [19:45] rick_h, handlebars and Y.Handlebars are not different [19:45] rick_h, are you using 3.5pr2 currently? [19:45] rockstar: on an outside app yea. I'm trying to talk lifeless into handlebars for our stuff [19:46] * rick_h hates mustache with the heat of many pizza ovens [19:46] :) [19:46] rockstar: you guys playing with it? [19:46] rick_h, we've been using Y.substitute still [19:46] ah ok [19:46] rick_h, your loader code that you stole from us won't run in its current form on 3.5 [19:46] rockstar: I'm not using most of it [19:47] only stole some basics on generating the module config [19:47] Why do you need handlebars currently? [19:47] we've got mustache and not happy with it [19:47] What are you not happy with? [19:47] but it has a python version which is why it won [19:47] really poor performance, lack of building decent helpers/modules [19:47] and very buggy from python -> js versions [19:47] Oh, so apparently you're doing templating somewhere other than the browser as well? [19:48] rockstar: yea, the new buglisting is mustache on server/client [19:48] the first load is server generated and the subsequent are client [19:49] right, so the dicussion is can we implement a python version of handlebars and use it client side and solve a lot of issues [19:49] or does fixing mustache make sense [19:49] or something else entirely [19:49] but LP is getting waaaay to many ways to build a tpl [19:49] Yeah, I bet. [19:50] the fact that we're YUI and YUI is bringing in handlebars is a BIG plus imo [19:50] Absolutely. [19:50] rockstar: we still have use cases around filing bugs etc from stone age (text) browsers [19:50] lifeless, yeah, and U1 doesn't worry about those browsers. [19:51] rockstar: which is a bit sad; also for google juice you still need server rendered content [19:51] But we also aren't TOO concerned about duplicating templates slightly. [19:51] lifeless, not for private content you don't :) [19:51] I still think there's a way around that using normal "google, don't index this...but go look here" for that [19:51] beuno: actually you do [19:51] beuno: search appliance [19:52] lifeless, we don't do search appliance, but yes, that would be a use case [19:52] rick_h: there is, the way it works is you point google at server rendered pages using a site map [19:52] rick_h, yeah, google has a hashbang protocol [19:52] beuno: canonical has one internally [19:52] But javascript only is not great for accessibility [19:52] yea, that's very true [19:52] Or, rather, it misses a11y in many core cases [19:52] so, long story short, I don't think we can justify client only rendering yet, all things considered. [19:53] but we don't want to pay through the nose for doing both, nor do we want to only do client in a few cases [19:53] I don't think you *should* justify client only rendering [19:53] Ever. [19:53] rockstar: my personal jury is still out on that; call me on the fence with a lean towards server-side-needed-indefinitely [19:54] I do think we should separate the layers [19:54] data layer <-> template layer <-> HTTP HERE [19:54] lifeless, yeah, I'd be happy to chat about that sometime and kick you off the fence. [19:54] and client rendering can possibly suck straight from the data layer [19:54] rockstar: which side do you want me to land on ? [19:54] hah [19:54] lifeless, server-side-needed-indefinitely [19:55] :) so as I say I'm bent that way as it stands [19:55] :) [19:55] but its worth reevaluating regularly [19:55] don't ruin the surprise! [19:55] Screen readers force us into perpetual IE6 support. :) [19:56] you guys are sending the end of my day into depression [19:56] it's just a trick to make you stay working later [19:56] rockstar: we just blew IE6 away [19:56] rockstar: so gnar gnar gnar :P [19:56] Yeah, we did that too (and IE7 as well), but if you care about a11y, you still have to *kinda* support it. [19:56] Screen readers don't care about bleeding edge. [19:57] We can ship out cd's more cheaply. [19:57] what are our stats on that stuff? Is that out there to see? [19:57] not to minimize the issue at all, just curious [19:57] we have *200* data types in LP, supporting something awkward across the board is very expensive [19:57] rick_h: stats on which stuff? [19:58] browser/screen reader/etc [19:58] rick_h, how do you get stats on browser plugins? [19:58] I'd assumed that the screen readers would alter UA? [19:58] I guess I've never actually used/seen used one [19:58] rick_h: chat to TheMuso [19:59] rick_h: he's one of our blind staff [19:59] rick_h, go make a blind friend. That's what I did. [19:59] k [19:59] I mean, chat with TheMuso as well, but have someone you can meet for lunch. [19:59] he'll be in #canonical in a couple hours [19:59] I'll put out a personal ad in the area :) [19:59] Seeing the crap impaired sight people deal with makes my heart hurt. [20:00] lifeless: so this guys in #yui gave me this for some handlebar exapmles: http://beta.tdp.me/static/scripts/bundle.js http://beta.tdp.me [20:00] lifeless: says he's using some self build block helpers and such [20:01] to give you stuff to poke at [20:01] lifeless: so do you have stuff with the server side making api calls to services so it can server side process it? [20:01] sorry, meant rockstar ^ === matsubara is now known as matsubara-afk [20:07] sounds like it's affecting a few people - https://bugs.launchpad.net/ubuntu/+source/python-launchpadlib/+bug/929068 [20:07] <_mup_> Bug #929068: [Precise] bug_task.date_created is returning 'unicode' objects instead of 'datetime' objects < https://launchpad.net/bugs/929068 > [20:12] lifeless: After updating sourcedeps.conf, update-sourcecode will update sourcedeps.cache for you. Please commit that. [20:17] abentley: it still works if it is stale, right ? [20:17] lifeless: Yes, it's just slower. [20:18] abentley: I did that particular change in an environment where update-sourcecode won't work [long story], which is why I didn't have the cache updated [20:18] lifeless: Ah. [20:19] bryceh, bug 924240 looks to be the same [20:19] <_mup_> Bug #924240: datetime interpretation changed < https://launchpad.net/bugs/924240 > [20:23] statik: can we move our 1:1 up (to ~now ?) [20:24] well, wadllib could do something like that [20:24] try downgrading it? [20:24] hah [20:24] python-wadllib_1.2.0+ds-2build1_all.deb [20:24] indeed it works [20:25] lifeless: yes! better for my schedule also [20:25] skype? g+? pots? pigeons? [20:26] lifeless: g+? https://plus.google.com/hangouts/extras/canonical.com/statik-hangout [20:28] I'll start one - that wants me to activate my canonical address as a profile [20:28] ETOOMANYONLINEIDENTITIES [20:29] invites sent [20:39] rick_h, I make a