[00:03] <wwitzel3> cmars: thanks, it has been fun, hopefully the finishing touches won't take too long
[00:19] <katco> davecheney: hey sorry, wifey and kiddo are home
[00:19] <katco> davecheney: but rq, i was wondering if you had time to look at my PR again, i was wondering why the name feature_tests was dangerous?
[00:24] <davecheney> katco: _test as a package name is reserved for external tests
[00:24] <davecheney> the tool will probably let you get away with it
[00:24] <davecheney> but it'll bite us (just like testing in package main did)
[00:24] <katco> davecheney: these are external tests though, correct?
[00:24] <davecheney> also, package names should be alphas only
[00:24] <davecheney> pacakge foo_test is synthesised by the test runner
[00:25] <davecheney> so it's a good idea to stay away from that special cased behaviour
[00:25] <katco> davecheney: feature_testS is as well?
[00:25] <davecheney> katco: please don't use underscores in package names
[00:25] <katco> davecheney: do you have a suggestion?
[00:25] <davecheney> the name of the package should describe what it does, not its contents
[00:26] <davecheney> as a stop gap
[00:26] <davecheney> package featuretests
[00:26] <katco> davecheney: so, something that describes the fact that it runs functional/feature tests
[00:26] <katco> davecheney: i honestly can't think of anything better than featuretests if you don't want an underscore/hyphen
[00:27] <davecheney> i don't have any comment apart from please don't use underscores, or any other punctuation in pacakge names
[00:27] <davecheney> and don't call a package _test
[00:27] <davecheney> 'cos the go tool will end up barfing and we'll hve to back it out
[00:28] <katco> davecheney: so if i were to rename the package, you would lgtm?
[00:28] <davecheney> katco: i guess so
[00:28] <davecheney> does this need to live in the juju repository ?
[00:29] <katco> davecheney: that depends; i think the intent was for developers to have the option of running it, but by virtue of the fact that it is intended for external tests only, it could certainly be external
[00:30] <katco> davecheney: sinzui, wallyworld, and axw all gave verbal agreement on name/location
[00:30] <katco> davecheney: perhaps they could weigh in further
[00:33] <katco> davecheney: as a point of intellectual curiosity, i still don't understand why the go tool will at some future point reject _test packages
[00:38] <wallyworld> katco: what about "featuretests". i really don't care about the _
[00:38] <davecheney> katco: _test is a majic package
[00:38] <davecheney> it never exists on disk
[00:39] <davecheney> is is only syntehsised for external tests by the test runner
[00:39] <davecheney> this magic will bite us
[00:39] <davecheney> please don't anger it
[00:53] <katco> davecheney: wallyworld: sorry, brushing the little one's teeth for the first time :)
[00:53] <wallyworld> \o/
[00:53] <katco> davecheney: interesting, look at how it laid it out on disk: > pwd
[00:53] <katco> /tmp/go-build388828020/github.com/juju/juju/feature_tests/_test/github.com/juju/juju
[00:54] <katco> feature_tests.test binary is in /tmp/go-build388828020/github.com/juju/juju/feature_tests/_test
[00:54] <katco> so it looks like it generated a blank _test directory within feature_tests
[00:54] <davecheney> katco: i'm not sure what you want me to say
[00:54] <davecheney> i gave you my advice
[00:55] <katco> davecheney: sorry, i thought you'd be interested. i'm not looking for you to say anything. thanks for the input.
[00:56] <davecheney> i just know this will blow up
[00:56] <davecheney> remembver we have to support Go all the way back to 1.2 shipped in a 3 year old operating system
[00:56] <davecheney> the possiblilities of backporting fixes to those old distros, after two bitter years of trying, is exactly 0%
[01:02] <mattyw> morning all
[01:02] <mattyw> hope everyone had a good holiday
[01:02] <katco> mattyw: happy new years to you sir!
[01:02] <perrito666> mattyw: morning, happy new year
[01:13] <anastasiamac> mattyw: morning! and a Happy 2015 :)
[01:14] <mattyw> katco, perrito666 anastasiamac happy new year all
[01:16] <wallyworld> katco: standup?
[01:16] <katco> wallyworld: shoot brt
[01:18] <perrito666> ohno dying pixel
[01:19] <katco> perrito666: #nopixelleftbehind
[01:19] <perrito666> katco: I discovered today that dell announced my next machine :p now I just need a way to get one of those
[01:20] <katco> perrito666: sweet :)
[01:20] <perrito666> none of you want to visit .ar and save me of customs hell?
[01:40] <katco> axw: package name has been updated; ready for review whenever you're ready
[01:40] <axw> katco: cool, looking now
[02:01] <axw> katco: sorry to be a pain in the butt, but I have a question before I can LGTM
[02:01] <katco> axw: not at all, what's up?
[02:01] <axw> katco: published
[02:01] <katco> axw: k looking
[02:10] <katco> bleh i fail at review board
[02:17] <axw> katco: so my concern is there's nothing stopping unit X from requesting leadership for unit Y, but from your response that's what William wants? what are the access controls *meant* to be? I don't think there's any precedent for a free-for-all
[02:18] <katco> axw: it's an excellent point. again he brought up several examples wherein the unit getting leadership might not be the unit requesting it. i believe they were hypotheticals.
[02:19] <katco> axw: i think in general, he is trying to be sensitive to bulk-first architecture, but the cross section of that and leadership is interesting to say the least
[02:19] <thumper> menn0: yep, there was a problem with the creation of the environments, test and patch coming
[02:19] <thumper> menn0: just running all the tests to catch bad tests
[02:19] <katco> axw: and just for fun i'll throw the fact in that i could have misinterpreted :)
[02:20] <axw> katco: can that particular change be reverted, and moved to a separate PR that fwereade can take a look at?
[02:20] <axw> katco: I'm not comfortable with it, but I don't want to block the rest
[02:21] <katco> axw: i'm due to talk with him tomorrow about leadership, why don't i just bring it up there and see what he has to say
[02:21] <axw> katco: okey dokey
[02:21] <axw> thanks
[02:21] <katco> axw: thanks for the review :)
[02:21] <axw> nps
[02:21] <katco> axw: 10 points!
[02:25] <ericsnow> wwitzel3: FYI, I've updated the branch with the gceapi commit
[02:25] <ericsnow> wwitzel3: I've broken some tests but wanted to get up what I had before calling it a night
[02:26] <ericsnow> wwitzel3: we can change the name too
[02:26] <ericsnow> wwitzel3: I may check back in later, but maybe not :)
[02:36] <menn0> menn0: ok. want me to review when it's ready?
[02:37] <menn0> thumper: ^^ :)
[02:37] <wwitzel3> ericsnow: sounds good, thanks :)
[02:38] <thumper> menn0: http://reviews.vapour.ws/r/690/
[02:38] <thumper> menn0: full test run is still going
[02:38] <thumper> but I expect it to finish shortly
[02:38] <thumper> (running again)
[02:38] <thumper> first run found one other place in the code where we were doing it wrong
[02:39] <thumper> just finished, all tests pass locally
[02:40]  * menn0 looks
[02:44] <menn0> thumper: is that factory change supposed to be there?
[02:45] <menn0> thumper: it appears like you intend the type of factory.EnvParams.Owner to change but I don't see that
[02:45] <menn0> thumper: never mind
[02:45] <menn0> thumper: i'm being stoopid
[02:45] <menn0> thumper: ship it
[02:45] <thumper> :)
[02:46] <thumper> ta
[02:46] <menn0> thumper: just a typo in that test name
[02:46] <thumper> fixing
[02:48] <thumper> menn0: and thanks
[02:55] <anastasiamac> axw: about facade version numbering...
[02:56] <anastasiamac> axw: should they start at 0 or 1?
[02:56] <anastasiamac> axw: i have seen a few 0s when I was adding mine...
[02:58] <thumper> ah fark.....
[02:58]  * thumper headdesks
[02:59] <anastasiamac> thumper: again?..
[02:59] <axw> anastasiamac: sorry, was afk
[02:59] <axw> anastasiamac: new ones should be 1
[02:59] <thumper> anastasiamac: nothing to do with you
[03:00] <axw> anastasiamac: 0 is for the facades that existed before we had versioning
[03:00] <axw> or something like that
[03:02] <anastasiamac> axw: oh! thnx - that makes sense ;)
[03:02] <anastasiamac> thumper: i was not expecting it to do with me
[03:03] <anastasiamac> thumper: but ur desk must be very sturdy with all this stress relief :p
[03:24] <anastasiamac> axw: I'll add this explanation to api/facadeversions.go for future references :0
[03:24] <axw> anastasiamac: SGTM, thanks
[03:25] <axw> anastasiamac: I think jam would be able to clarify the rationale, maybe ask him to review
[03:26] <anastasiamac> jam, ping :)
[03:26] <anastasiamac> axw: thnx ;-)
[03:26] <axw> a bit early I think
[03:26] <jam> axw: anastasiamac: I'm up, but currently in leads meeting
[03:27] <axw> no rest for the wicked/leads :)
[03:29] <anastasiamac> axw: :) or OCRs
[03:30] <anastasiamac> axw: could u plz cast ur eyes on my annotations PR when u get a chance?
[03:30] <axw> anastasiamac: yup, just finishing up with another
[03:31] <anastasiamac> axw: tyvm :p
[03:51] <anastasiamac> m trying to update dependencies.tv with newer version of names... i get the commit hash, I get the date but what is the date suffixed with? for eg. what's T02:50:22Z?
[03:51] <anastasiamac> axw: ^^?
[03:52] <axw> anastasiamac: just use godeps to get the correct values
[03:52] <anastasiamac> how?
[03:52] <axw> anastasiamac: godeps ./... | grep names >> dependencies.tsv
[03:52] <axw> then fix up by hand
[03:52] <axw> that's how I do it anyway. there's probably a smarter way
[03:54] <ericsnow> axw: this (from Nate) works for me: "GOOS=windows godeps -t ./... > dependencies.tsv"
[03:54] <anastasiamac> axw: i know what names commit i want dependencies.tsv to contain
[03:55] <anastasiamac> axw: ericsnow: i know what date to put as well, i just don't get the last charas?..
[03:55] <anastasiamac> chars even
[03:55] <axw> anastasiamac: not sure what date you're talking about?
[03:55] <ericsnow> anastasiamac: just set your names repo to that commit and then let godeps sort it out for you
[03:55] <axw> anastasiamac: ah, the date at the end of the git lines - that's from a newer version of godeps I believe
[03:55] <ericsnow> axw: newer versions of godeps put a date along with some of the revisions
[03:55] <anastasiamac> ericsnow: axw: I have updated names repo and need juju dependencies.tsv to have my commit in it
[03:56] <ericsnow> anastasiamac: with the names repo set to the revision you want, run the command I listed and see what it writes to dependencies.tsv
[03:58] <anastasiamac> ericsnow: this removed all dates
[03:58] <ericsnow> anastasiamac: I'm guessing your godeps is older then
[03:59] <ericsnow> anastasiamac: try "go get -u launchpad.net/godeps && go install launchpad.net/godeps" or something like that
[04:01]  * anastasiamac updating godeps
[04:01] <anastasiamac> ericsnow: thnx :) got it ;-0
[04:01] <ericsnow> anastasiamac: :)
[04:06] <jam> anastasiamac: so pong now, in case there is something you still need clarity on
[04:07] <anastasiamac> jam: just to confirm - axw's understnading of facade versioning:
[04:08] <anastasiamac> jam: initial numbering - 1 for new facades, 0 for facades that existed before versioning
[04:08] <anastasiamac> jam: ?
[04:09] <thumper> night all
[04:09]  * thumper goes to walk dogs
[04:09] <axw> night
[04:09] <jam> anastasiamac: the "0" version is for things that were in 1.18 (pre-versioning), yes
[04:10] <anastasiamac> jam: axw: thnx for clarification. I'll add it as a comment to facadeversions on my brnach :-)
[04:11] <anastasiamac> branch*
[04:16] <axw> anastasiamac: did you just rename annotator.go to annotations.go, or are there other changes in that file?
[04:17] <axw> oh it's not renamed at all, just extracted
[04:17] <anastasiamac> axw: there r other changes... like GlobalEnitty
[04:17] <axw> anastasiamac: I meant annotator.go specifically
[04:17] <anastasiamac> axw: m going to remove annotator.go in the next PR
[04:17] <axw> oh I see
[04:18] <anastasiamac> axw: also state is now passed in
[04:18] <anastasiamac> axw: current annottor is written with embedding into entities in mind
[04:19] <anastasiamac> axw: my implementation ensures that the new annotations does not need to b embedded
[04:19] <axw> right
[04:19] <axw> so I see
[04:19] <axw> sgtm
[04:20] <anastasiamac> axw: :)
[04:22] <axw> anastasiamac: reviewed
[04:22]  * axw disappears for lunch
[06:01] <anastasiamac> fwereade: ping
[07:15] <fwereade> anastasiamac, pong
[07:15] <fwereade> anastasiamac, getting rid of that embedding sounds like a good thing to me, that always felt like a timebomb
[07:16] <anastasiamac> fwereade: about bulk annotation calls, i've sent u an email. Just thought i'd give u a heads-up ;-)
[07:16] <fwereade> anastasiamac, ty
[07:16] <anastasiamac> fwereade: m glad u feel this way about embedding ;)
[07:30] <anastasiamac> axw: r u k to drop annotation bulk call review comments until I get confirmation from intrested parties? I'd love to land what I have so far and address the rest in separate PR...
[07:30] <anastasiamac> axw: pretty plz? :)
[07:31] <jam> fwereade: ping for status chat
[07:31] <axw> anastasiamac: not really, because 1.22 is about to go out and then this is set in stone...
[07:32] <axw> anastasiamac: if you go with my suggestion then everybody should be happy because it can handle any combination in one bulk call
[08:30] <TheMue> morning
[08:30] <axw> morning
[08:39] <dimitern> wallyworld_, still around?
[08:45] <anastasiamac> axw: addressed :) when u get a chance, could u plz inspect? :P
[08:52] <axw> anastasiamac: looking
[08:59] <axw> anastasiamac: reviewed
[09:24] <anastasiamac> axw: thnx!
[09:25] <axw> nps
[09:58] <voidspace> dimitern: TheMue: I'll be a couple of minutes late to standup
[09:58] <voidspace> see you soon, sorry!
[09:58] <dimitern> voidspace, ok, no
[09:58] <dimitern> np even :)
[10:02] <voidspace> dimitern: omw
[11:03] <wallyworld_> dimitern: hi, was away for a bit
[11:04] <wallyworld_> voidspace: i think you're ocr? if you get a chance, i'd love to be able to land http://reviews.vapour.ws/r/692/
[11:04] <dimitern> wallyworld_, hey, I wanted to ask are you willing to help now and then with goamz reviews/maintenance on github, as you've contributed in the past
[11:04] <wallyworld_> sure
[11:04] <wallyworld_> i'm not an expert but happy to help
[11:04] <dimitern> wallyworld_, ok, you have an invite already :)
[11:05] <wallyworld_> ok, will look, probably tomorrow, am tired tonight
[11:05] <dimitern> wallyworld_, no worries, we'll get community members to help as well
[11:05] <dimitern> wallyworld_, sure, have a good one :)
[11:05] <wallyworld_> will do
[12:03] <voidspace> wallyworld_: nope, ericsnow and axw
[12:03] <voidspace> wallyworld_: I can look in a bit if they don't get to it
[12:05] <wallyworld_> voidspace: ah, oh, sorry, i'm a day out. i can wait till tomorrow
[12:09] <voidspace> wallyworld_: looking at it now
[12:10] <wallyworld_> i owe you one, thanks
[12:15] <frankban> katco, wallyworld_ : thank you both for the reviews! I replied to some of your comments and I have some questions, (however I am not sure I understand how review board works with comments). could you please take another look when you have time?
[12:15] <wallyworld_> frankban: will do
[12:15] <frankban> ty
[12:28] <voidspace> wallyworld_: so imagemanager and the Client, with DeleteImage method, is pre-existing
[12:29] <voidspace> wallyworld_: this is just the command to expose it
[12:29] <wallyworld_> voidspace: yeah, all the api and apiserver stuff landed in a previous branch. this is just to add a juju command it use it
[12:29] <wallyworld_> yep
[12:29] <voidspace> wallyworld_: LGTM
[12:29] <wallyworld_> voidspace: you rock, tyvm
[12:30] <voidspace> wallyworld_: a disturbing amount of boilerplate required just for TestDeleteImage though
[12:30] <voidspace> wallyworld_: the mocking, the patching, the fakes
[12:30] <voidspace> wallyworld_: not that I see a better way
[12:30] <wallyworld_> yeah. i find i complain about biolerplate in general with go
[12:30] <wallyworld_> lack of generics etc makes it unavoidable
[12:30] <voidspace> wallyworld_: and as a result of it, you don't actually test that the delete command calls the DeleteImage client method
[12:31] <voidspace> right
[12:31] <voidspace> you check the api method is called - but that is mocked out, so it's not tested
[12:31] <wallyworld_> true, i think you are right, i'm more or less following established patterns
[12:32] <voidspace> yeah, effectively we test the layers but don't test through all the boundaries
[12:32] <wallyworld_> we are introducing a featuretests package for integration tests
[12:32] <voidspace> cool
[12:32] <voidspace> anyway, I added my ShipIt
[12:32] <wallyworld_> the first cab off the rank is katherine's leadership service tests
[12:33] <wallyworld_> so with featuretests, we can add a tests to check the end-end wiring
[12:33] <voidspace> great
[12:33] <wallyworld_> so we have a mix of fast *unit* tests and fewer slower intergration tests
[12:34] <wallyworld_> work in progress
[12:34] <wallyworld_> thanks for lgtm, i can now land this to meet the 1.22 deadline
[12:42] <rick_h_> jam: still around?
[13:23]  * perrito666 reads a little wtf in a review answer and gets a small brain freeze like sensation
[13:48] <jam> rick_h_: hey
[13:49] <rick_h_> jam: howdy, got a few min I can steal sorry for the post-hours?
[13:49] <jam> rick_h_: calling you now https://plus.google.com/hangouts/_/guyjqtpuoh55ecfsilhje5smdia
[14:58] <ericsnow> wwitzel3: ping
[15:02] <wwitzel3> oh right
[15:07] <wwitzel3> ericsnow: no one is here ..
[15:10] <katco> fwereade: ping
[16:44] <ericsnow> jw4: ping
[16:57] <ericsnow> fwereade: you still around?
[17:21] <frankban> wallyworld_: I updated my branch to reuse the code in envcmd for the default environment. I'll wait for Tim about naming issues
[17:46] <gsamfira_> hello folks
[17:46] <gsamfira_> I was doing a deploy of juju 1.21  beta5 on MaaS and noticed that the --constraints argument is ignored
[17:47] <gsamfira_> looking at: https://github.com/juju/juju/blob/1.21/provider/maas/environ.go#L781 , it seams that the Constraints field is missing
[17:47] <gsamfira_> is this by design?
[18:03] <perrito666> ericsnow: wwitzel3 ?
[18:03] <perrito666> weekly random time meeting?
[18:03] <wwitzel3> perrito666: omw
[18:04] <voidspace> rebooting and then coming (weird unity freeze thing I need to get rid of to use the browser)
[18:05] <dimitern> TheMue, are you around for the team meeting?
[18:05] <perrito666> cmars: ?
[18:08] <voidspace> dimitern: as you're still around...
[18:08] <voidspace> dimitern: https://code.launchpad.net/~mfoord/gomaasapi/nodegroupsinterfaces/+merge/245891
[18:08] <dimitern> voidspace, sure, will have a look
[18:41] <voidspace> g'night all
[18:41] <wwitzel3> nn voidspace
[18:41] <dimitern> voidspace, i'm reviewing your MP and will send a review
[18:41] <voidspace> wwitzel3: o/
[18:41] <voidspace> dimitern: cool, thanks
[18:41] <dimitern> voidspace, have a good one ;)
[18:41] <alexisb> o yeah, there is totally uber in tokyo:
[18:41] <alexisb> http://www.bloomberg.com/news/2014-08-05/uber-expands-tokyo-service-to-include-taxi-booking.html
[18:42] <katco> i forgot to mention for anyone who was interested in the spec: it also generates the interfaces for all of the code to ensure parity
[18:42] <katco> so what you see in the spec is directly in the codebase
[18:42] <alexisb> katco, have you and jam talked about your spec format before?
[18:42] <alexisb> if not we should make that happen
[18:43] <katco> alexisb: i have not
[18:44] <katco> alexisb: i have something regarding leadership to discuss with him as well. it's low-priority, but we could definitely fill a meeting with the 2 topics
[18:45] <alexisb> katco, you should get on his calendar
[18:45] <katco> alexisb: will do, i'll send him an email
[18:45] <alexisb> I would offer to set if up but with your earlier timezone you have a better chance of getting on the calendar solo
[18:45] <katco> what tz is he?
[18:46] <katco> why am i asking, it's right here lol
[18:47] <katco> so 10h difference
[18:47] <dimitern> alexisb, yeah, uber started in sofia recently as well
[18:48] <alexisb> dimitern, cool
[18:48] <alexisb> katco, keep in mind he has his son in the afternoon after school
[18:49] <katco> alexisb: ok ty for the info
[18:49] <dimitern> katco, i can't wait for that blog post :)
[18:50] <katco> dimitern: i'm about halfway done, i will let you know :)
[18:50] <dimitern> katco, my org mode skills so far include only storing my emacs conf in org babel source blocks and some todo lists :)
[18:50] <dimitern> awesome
[18:50] <katco> dimitern: this is even easier; it's basically a plain-text outline that you just export
[18:50] <katco> dimitern: if you can write markdown, you can do this just as easily
[18:51] <dimitern> katco, cool! i suppose it goes via latex to generate the pdf
[18:51] <katco> dimitern: yes, exactly
[18:51] <katco> dimitern: i also got it to export and odf, but it's not nearly as nice
[18:52] <katco> dimitern: but i suppose the important thing is that you don't need to know latex or anything to produce one, just how to write an outline in org mode
[18:53] <dimitern> katco, that's way better!
[18:53] <katco> dimitern: yeah, essentially these things just fall out of the notes i take when i'm gathering requirements. it's so easy
[18:54] <perrito666> dimitern: I wonder, do you know the answer to gsamfira_ question??
[18:54] <katco> well, for me. but i don't think it should be hard for the uninitiated either
[18:54]  * katco goes to grab lunch
[18:54] <dimitern> katco, +1
[18:54] <dimitern> perrito666, hmmm - what's that?
 hello folks
 I was doing a deploy of juju 1.21  beta5 on MaaS and noticed that the --constraints argument is ignored
 looking at: https://github.com/juju/juju/blob/1.21/provider/maas/environ.go#L781 , it seams that the Constraints field is missing
 is this by design?
[18:56] <dimitern> perrito666, gsamfira_ it is by design because constraints are processed earlier
[18:56] <gsamfira_> dimitern: then something happens, because acquireNode never sends tags to maas
[18:56] <gsamfira_> so you get a random node
[18:56] <dimitern> gsamfira_, ah, wait .. that's total bs
[18:56] <gsamfira_> if you have a maas install handy, give it a shot
[18:57] <dimitern> gsamfira_, it seems they need to be there as an arg
[18:57] <dimitern> gsamfira_, that has changed recently, I guess with the AZ distribution logic
[18:57] <dimitern> gsamfira_, *please* file a bug about it
[18:58] <gsamfira_> sure thing
[18:59] <dimitern> gsamfira_, thanks! I'll have a look in the morning
[18:59] <gsamfira_> sure. The fix is easy. Just add Constraints field :). Not sure if its correct, but it works :)
[19:01] <gsamfira_> dimitern: https://bugs.launchpad.net/juju-core/+bug/1408762
[19:01] <mup> Bug #1408762: --constraints option is ignored on MaaS provider <juju-core:New> <https://launchpad.net/bugs/1408762>
[19:02] <dimitern> gsamfira_, cheers!
[19:43] <perrito666> sometimes I feel we use the word status a bit too much
[19:45] <wwitzel3> need a status update on the status of health status
[19:45] <alexisb> :)
[19:49] <perrito666> wwitzel3: I am dealing with the status of the entity, which is analog to going to a toolshop asking the thing to put the thiguie in there
[20:25] <bac> hi marcoceppi, recently you fixed the install hook on squid-reverseproxy for precise.  could you make that fix for the trusty version too


[21:46] <pleia2> sent document to summary writers
[21:46] <pleia2> I'm out tomorrow, taking a boat, then a plane, possibly ending with a train
[23:57] <jose> I can move stuff to the wiki


[01:40] <ChrisMorgan> Does Launchpad support hooks of some sort, to send a request to a web page upon being pushed to?  (In hg it'd be a changegroup hook)
[01:41] <ChrisMorgan> I ask, because a quick look for bzr hooks shows only supports code-registered hooks, while with hg it's in the repository's hgrc and so easy to do.
[01:41] <thumper> no we don't have any web hooks at this stage
[01:41] <thumper> the closest is an email
[01:43] <ChrisMorgan> Which could work but would be more messy.
[01:43] <ChrisMorgan> OK, thanks.
[01:46] <thumper> ChrisMorgan: we have a plan to have webhooks one day
[01:46] <thumper> it isn't that hard
[01:46] <thumper> but it is a feature that isn't done
[12:46] <rockingwing> one of the ubuntu audio dev team here?
[14:39] <lamont> geser: I'd much prefer the URL for the build record, which gets me places, than the URL for the buildlog, which gets me nothing but a text file
[14:40] <lamont> geser: and satinash would be one of the machines that's not quite current yet - there are about 4 armel buildds where that's the case
[14:50] <fta> dpm, too bad rosetta reports "X-Generator: Launchpad (build Unknown)", i have no idea if the last export got the fix or not (lp jumped from r11952 to r11965 and the fix is in r11953)
[14:56] <lamont> geser: hubbard and gourd are the last hold outs, that's why they're on manual
[15:20] <henninge> fta: the fix for the export-to-branch feature won't be available until after the roll-out on the 8th, I am sorry.
[15:20] <henninge> If that is what you were asking about.
[15:31] <jussi> heya all, any launchpadders about?
[15:32] <jussi> Ive a real quick papercut bug, however, Ill go file a bug for it if no one is about to fix it.
[15:36] <jussi> simply, on this page: https://help.launchpad.net/ReadingOpenPgpMail - the gmail section mentions firegpg, which has been discontinued/isnt available anyemore. http://blog.getfiregpg.org/2010/06/07/firegpg-discontinued/
[15:43] <jussi> hrm, it appears to be a wiki, but I dont see how to edit it
[16:24] <geser> bigjools: should I just ask for a give-back for https://launchpad.net/ubuntu/+source/libgphoto2/<IP_ADDRESS>-2ubuntu1/+build/2059754? Failed to upload with no upload log :(
[16:24] <bigjools> geser: you want me to retry it?
[16:25] <bigjools> it's a result of the bug about leaving builds stuck as uploading
[16:25] <bigjools> they got fixed but the upload log is missing
[16:25] <geser> if you want, else I would ask a core-dev to do it (if it's the right action for solving it)
[16:28] <bigjools> geser: I can do it
[16:29] <bigjools> done
[16:29] <bigjools> you'll get a proper failure next time
[17:46] <geser> bigjools: is this http://launchpadlibrarian.net/59617004/upload_2044918_log.txt a package error or LP being to strict? I remember seeing that problem in the past but forgot what the "solution" was.
[18:09] <jelmer> geser: that's a package error. there shouldn't be a reason for the package to have timestamps that far in the past.
[18:35] <geser> ok
[20:29] <kees-jan> Hi,
[20:29] <kees-jan> Is this the right place for a ppa related question?
[20:32] <LetoThe2nd> heya! I just reported a bug via apport, which got marked as duplicate. the message said i shall lookup the original and see if i can provide additional information. i think i can (workaround), but the original bug is marked private. therefore, the mail i received is kind of pointless - i can't access and comment the original bug :-(
[20:56] <micahg> LetoThe2nd: you might want to ask in #ubuntu-devel if it was the retracer that made the comment
[22:43] <maxb> losa ping: codebrowse appears to need kicking. All access is timing out.
[22:59] <spm> maxb: yeah, looks like swap death.
[23:02] <spm> maxb: should be groovy now
[23:03] <maxb> much better, thanks :-)
[23:45] <ibbo> I'm trying to upload a .deb I created using the python packaging guide, but I can't upload the signature file as it's 4K, what should I be doing to upload my package?
[23:46] <micahg> ibbo: you can't, you have to upload a source package
[23:46] <ibbo> oh right, so my project on launchpad can't have a ppa?
[23:47] <micahg> ibbo: no, PPAs have source packages uploaded to them
[23:47] <micahg> ibbo: https://help.launchpad.net/Packaging/PPA/Uploading
[23:47] <ibbo> ok thanks, I'm clearly misunderstanding something
[23:50] <ibbo> ok I'm confused, I have created a new package and I want to put it somewhere people can download, ideally http://launchpad.net/pyspy which is my project's launchpad page
[23:51] <ibbo> the Packaging/PPA/Uploading page says to upload the changes file, but this is a new package
[23:52] <micahg> ibbo: the changes file isn't a diff, but a listing of the changelog with other items
[23:58] <ibbo> ok, I've uploaded it to my personal ppa, can I associate a ppa with my project?
[23:59] <micahg> ibbo: no, not at this time, PPAs are team owned, but you can add a note in the project description where the PPA is


[01:32] <desrt> robert_ancell: 'nobody' account, for example
[01:32] <desrt> and nfsnobody, i think also exists
[01:33] <desrt> in general, there are a few high-numbered accounts that are not normal users, and we wanted to avoid those
[01:33] <robert_ancell> desrt, they're already blacklisted explicitly
[01:34] <robert_ancell> oh, I see you disable the blacklist and use this instead.
[01:36] <robert_ancell> RAOF, I forget again, can you cancel uploads?
[01:36] <desrt> robert_ancell: we were trying to move away from heuristics...
[01:37] <RAOF> robert_ancell: No, but if it's still in -proposed you can reject it.
[01:37] <robert_ancell> RAOF, how do I do that?
[01:37] <desrt> RAOF: hey... how's that mainloop unhate going?
[01:37] <RAOF> desrt: Generating ASIO rage.
[01:37] <RAOF> desrt: But the prerequisites are basically done, so I should be able to *actually* provide you with a manual dispatch option soon.
[01:38] <desrt> RAOF: cool.  keep me updated :)
[01:38] <RAOF> robert_ancell: You ask me to reject an upload :)
[01:38] <desrt> robert_ancell: btw: big drawing changes in gdk lately.... seems like maybe you were right to stay on 3.12 ;)
[01:38] <robert_ancell> RAOF, right, can you reject accountsservice/0.6.37-1ubuntu4 please?
[01:38] <robert_ancell> desrt, ha!
[01:38] <RAOF> robert_ancell: Sorry, no can do. It's already gone through.
[01:39] <robert_ancell> man, it was in proposed seconds ago :(
[01:39] <RAOF> Hm. Or maybe I actually *don't* know how to do this...
[01:41] <robert_ancell> meh, I'll just do a new upload
[01:41] <robert_ancell> desrt, so what do you do on systems that have 100000s of users and but still have a "nobody" account?
[01:42] <robert_ancell> this is the sort of user who is confused by the change
[01:42] <desrt> robert_ancell: enable heuristics?
[01:42] <desrt> the situation is kinda crap :(
[01:42] <robert_ancell> it's compile time right?
[01:42] <desrt> ya...
[01:42] <desrt> you could also up the max
[01:42] <robert_ancell> yeah, that doesn't seem right
[01:42] <desrt> that was possible in login.defs before
[01:42] <desrt> but now it's compile-time
[01:43] <desrt> apparently login.defs is not universal
[01:43] <robert_ancell> desrt, right, but if you set UID_MAX to 100000 then the nobody user will show because there's no blacklist anymore
[01:43] <desrt> exactly.
[01:43] <desrt> do we support uids > 65k?
[01:43] <robert_ancell> apparently
[01:43]  * desrt thought the FS had only 16bits for owner/group
[01:43] <robert_ancell> it's undefined. I guess it depends on what fs you are using
[01:44] <robert_ancell> uid_t is undefined I mean
[01:44] <desrt> so ext2/3/4 support 16bit uids
[01:44] <desrt> but they have an extended attribute for higher numbers
[01:44] <robert_ancell> yeah
[01:45] <desrt> so ya... i guess it's possible
[01:45] <robert_ancell> I think we should just consider uid < UID_MIN and a small blacklist of known legacy system UIDS greater than that
[01:45] <desrt> hmm.  chown doesn't like large-number uids
[01:46] <robert_ancell> oh, I'm sure loads of other code falls apart but for the purposes of what is considered a system user to a-s I think it has no concept of an upper limit
[01:46] <desrt> ah ya... goes up to 2^32 indeed
[01:47]  * desrt had one too many digits
[01:48] <desrt> maybe we should be changing our nobody user....
[01:48] <desrt> 2^32-1 instead of 2^16-1
[01:48] <desrt> having nobody in the middle of the range of normal valid uids is a bit weird
[01:48] <robert_ancell> desrt, since the number is baked into the fs bits we can never move it right?
[01:58]  * robert_ancell heads out for a bit
[02:01] <desrt> robert_ancell: would be a new-install thing
[02:01] <desrt> the number itself means nothing in terms of the fs -- only in terms of existing installs on those fses
[03:36] <pitti> Good morning
[03:39] <TheMuso> Morning pitti, an early start for you today it seems. :)
[03:39] <pitti> TheMuso: indeed, couldn't sleep any more after my wife got up; head full of ideas :)
[03:56] <TheMuso> pitti: Ah that sucks.
[08:11] <seb128> good morning desktopers!
[08:48] <seb128> shrug
[08:48] <seb128> * Other changes:
[08:48] <seb128> - This release changes the default behavior of gtk-update-icon-cache
[08:48] <seb128>   to not include image data into the icon cache. Use the new
[08:48] <seb128>   --include-image-data flag to get the old behavior back.
[08:48] <seb128> GTK2 2.24.24 stable update
[08:49] <Laney> oh yeah was going to look at that one
[08:49] <Laney> are you taking it?
[08:49] <didrocks> "nice" :/
[08:49] <seb128> go GTK, keep doing such changes
[08:49] <seb128> Laney, no, I'm not, I was just reading the ftp list changes
[08:49] <seb128> there is a new glib as well btw ;-)
[08:49] <Laney> indeed
[09:40] <Laney> grah
[09:41] <Laney> looks like dspam died in the overnight badness
[09:41] <Laney> meaning that mail was being refused
[09:41] <Laney> (with a bounce)
[09:41] <Laney> wonder how many subscriptions I lost due to that
[09:56] <seb128> Saviq, seems like unity8 migrated, the logout silo is for the next round? ;-)
[09:56] <Saviq> seb128, in testing
[09:56] <seb128> Saviq, thanks
[10:02] <seb128> larsu, it could be useful if you wrote a https://wiki.ubuntu.com/Process/Merges/TestPlan/gsettings-qt
[10:02] <seb128> larsu, just take one of the indicator one, e.g as a base https://wiki.ubuntu.com/Process/Merges/TestPlan/indicator-messages
[10:02] <seb128> larsu, something easy, just how you usually test updates/changes, like run the example from the source, one test scenario with settings maybe as well
[10:03] <larsu> seb128: make check!
[10:03] <larsu> just kidding, will do
[10:03] <seb128> ;-)
[10:03] <seb128> danke
[10:03] <larsu> thanks for the pointer
[10:03] <seb128> yw
[10:03] <seb128> btw I'm asking because I just put your changes from yesterday up for landing
[10:04] <larsu> ah cool thank you!
[10:04] <seb128> yw ;-)
[10:36] <larsu> seb128: re those manual test cases. Does it make sense to add those to the source and copy them to the wiki as described in https://wiki.ubuntu.com/Testing/TestCaseFormat ?
[10:37] <seb128> larsu, your call, it doesn't hurt to have them in the source I guess (I know ted has been doing that for the stuff he works on)
[10:38] <larsu> okay, thanks
[12:54]  * didrocks grumbles about http://bugs.python.org/issue9351
[13:00] <ogra_> didrocks, just use go then :P
[13:02] <didrocks> ogra_: volonteering yourself? :)
[13:02] <ogra_> hahahahaha
[13:02] <ogra_> ha
[13:02] <ogra_> ha
[13:02] <ogra_> ...
[13:02] <ogra_> ha
[13:03] <didrocks> :p
[13:04] <ogra_> :)
[13:56] <didrocks> ok, I'm going for a late run, I should be back just on time for the meeting :)
[13:56] <didrocks> see you later!
[14:12] <tkamppeter> Someone succeeded to run the current Adobe Reader under the current Ubuntu? I have a highly DRMed PDF file and cannot open it.
[14:29] <ChrisTownsend> seb128: Hey, got a moment to chat about https://bugs.launchpad.net/unity/+bug/1281058 for Unity Trusty SRU?
[14:29] <seb128> ChrisTownsend, hey, sure
[14:30] <ChrisTownsend> seb128: Cool.  So I was under the impression that the translations for this is not there for Trusty.  Is this true?
[14:31] <ChrisTownsend> seb128: As we'd like to include this in the next Unity Trusty SRU.  I just want to make sure about the translations.
[14:32] <ChrisTownsend> seb128: There is some question that the translations are part of unity-greeter and Unity gets the translations for "free" from that.
[14:32] <seb128> ChrisTownsend, translations are not included in the current langpacks no
[14:33] <seb128> I guess the template got ovewritten by one of the unity SRUs
[14:33] <seb128> you could use the translation from unity-greeter I guess
[14:33] <seb128> you would need to change the gettext domain for that though
[14:33] <seb128> it feels hackish
[14:33] <ChrisTownsend> seb128: Yeah, that is hackish.
[14:34] <ChrisTownsend> seb128: Well, this is priority bug with a string.  What's your recommendation on how to proceed?
[14:35] <seb128> ChrisTownsend, the change is going to be in the next unity SRU?
[14:36] <ChrisTownsend> seb128: Well, that's what I'm trying to determine.  I don't think we should include it if it's not translated, but we need to get it in when the translated strings are available.
[14:36] <ChrisTownsend> seb128: But we do need to get it in though.
[14:38] <seb128> ChrisTownsend, then we need to upload manually a pot include that string to launchpad, then wait for a langpack export
[14:43] <Trevinho> seb128: how long that would take, approx?
[14:44] <seb128> Trevinho, not sure when the next langpack trusty update is due
[14:44] <seb128> dpm, pitti: do you know?
[14:44] <pitti> seb128, Trevinho: we just did one two weeks ago (https://wiki.ubuntu.com/Translations/LanguagePackUpdatesQA)
[14:45] <pitti> so supposedly not that soon, unless there's something urgent to fix
[14:45] <seb128> pitti, right, that doesn't help us to resolve the current question ;-)
[14:45] <pitti> "whenever someone starts the community verification process"
[14:45] <pitti> last time, GunnarHj kindly did it
[14:45] <Trevinho> pitti: the problem is that there's this OEM prio bug that needs some new translations (already provided by unity-greeter)...
[14:46] <seb128> pitti, they need to add an user visible string to unity, if we don't want to slap in in the face of users untranslated, we need to upload an updated template to launchpad, get translators to do their work and then do an export
[14:46] <seb128> then only we can upload the code change in unity
[14:46] <pitti> Trevinho: as I said, "unless there's something urgent to fix" - best to create an SRU bug then with specific instructions which translatoins to watch out for, and testing the ones in https://launchpad.net/~ubuntu-langpack/+archive/ppa
[14:46] <seb128> Trevinho, you might as well try to hack around by loading that string from the unity-greeter domain then...
[14:47] <Trevinho> seb128: we might yes, let me see
[14:47] <pitti> seb128: ah, that sounds like that SRU needs to happen first, then?
[14:47] <Trevinho> (not lovely, but still...)
[14:47] <pitti> Trevinho: so in short, don't wait for the update to happen, ask for it :)
[14:47] <seb128> pitti, the langpack needs to include the string before we can SRU the unity change
[14:47] <Trevinho> pitti: ok, makes sense :)
[14:47] <seb128> or we can declare the untranslated string fine
[14:48] <pitti> seb128: I'm afraid that doesn't work; it only gets imported into LP via an upload
[14:48] <seb128> it's going to happen only in case where other users are logged in while you try to stop the system
[14:48] <pitti> we can keep that in -proposed until the corresponding langpacks are in -proposed too, and release both together
[14:48] <seb128> pitti, no, we can tweak the template to include the string and upload to https://translations.launchpad.net/ubuntu/trusty/+source/unity/+pots/unity/+upload
[14:48] <seb128> I did that before
[14:49] <pitti> ah, if that works, sure
[14:49] <seb128> my template just got overwritten by a SRU import since
[14:49] <pitti> why wasn't it included in that SRU, too then?
[14:49] <pitti> changing it *only* in LP is wrong
[14:49] <pitti> changing it in trunk and in LP is fine
[14:50] <seb128> because dh_translation regenerate the pot at package build
[14:50] <seb128> the code change is not there
[14:50] <seb128> because of the reason described before
[14:50] <seb128> need the translations in place before we do the code changes
[14:50] <seb128> though I guess we would have the code in but commented
[14:51] <seb128> that would be good enough to have intltool-update to pick the string
[14:51] <pitti> I don't understand that
[14:51] <pitti> if the string isn't translated now, why can't it be marked translatable and uploaded to -proposed
[14:51] <pitti> and then the translations happen on LP
[14:52] <seb128> the string doesn't exists in the code
[14:52] <seb128> they want to add a new dialog/string
[14:52] <seb128> it's not like it was there currently and displayed in english
[14:52] <seb128> so if we add it first, we have an user "regression"
[14:52] <pitti> right, so we can do that in -proposed
[14:52] <pitti> or in utopic even, which is what SRUs need to do anyway
[14:52] <seb128> just keep the SRU in proposed for ages?
[14:52] <seb128> it's in utopic
[14:53] <pitti> if it's as urgent as you say, then it shouldn't be "ages", if we have translators already translating it in utopic, and can get some to do the ones we need for OEM
[14:54] <seb128> right, the variable there is the time it's going to take to get new langpacks out and validated
[14:54] <pitti> but I suppose you could also re-import it into LP manually, if for some reason the code change can't happen first?
[14:54] <seb128> but I guess we can take on some locales showing an english UI
[14:54] <pitti> well, we aren't going to get it translated to all ~ 200 languages anyway :)
[14:55] <seb128> the SRU team is not so happy to introduce a non translated UI in front of users
[14:55]  * pitti -> ubuntu on air, sorry
[14:55] <seb128> so that was trying to find a middle ground solution
[14:55] <seb128> pitti, thanks for the chat!
[14:55] <Trevinho> ta
[14:55] <pitti> seb128: back in ~ 1 hour, for now it's pitti TV time :)
[14:56] <seb128> pitti, good luck with the hangout as well ;-)
[14:56] <pitti> merci!
[15:22] <didrocks> woot, even time to take a shower before the meeting!
[15:23] <seb128> didrocks, just went for exercice?
[15:23] <didrocks> yep ;)
[15:23] <didrocks> it wasn't that hot today, so running late was acceptable
[15:24] <didrocks> seems they shoot a movie in the park btw…
[15:30] <seb128> hey
[15:30] <seb128> it's meeting time!
[15:31] <seb128> qengho, Laney, tkamppeter, desrt, attente, larsu, didrocks, FJKong, hey
[15:31] <qengho> Aiee!
[15:31] <didrocks> hey
[15:32] <FJKong> hey
[15:32] <seb128> ok, let's get started
[15:32] <seb128> qengho, you start ;-)
[15:32] <qengho> Just one item that *looks* small.
[15:32] <qengho> * Testing cr 35.0.1916.153. Fixing patching bugs: New high-dpi geometry problem. Testing session saving/restoration backport.
[15:33] <qengho> EOF
[15:33] <seb128> is that the current stable? is it landing in Ubuntu this week? ;-)
[15:34] <qengho> It's upstream's "stable". It should land as soon as it's better than the last version!  Yes, this week. :)
[15:34] <seb128> I see that Debian already landed it for a week to their stable
[15:34] <seb128> great
[15:34] <seb128> qengho, thanks
[15:34] <seb128> Laney, hey
[15:34]  * Laney crawls out of the swamp
[15:34] <Laney> • Finish evo/e-d-s 3.12 transition
[15:34] <Laney> • Quite a number of merges: packagekit, sane-backends, inkscape, lcms2, others
[15:34] <Laney> • Upstream updates (mostly in Debian too): gtk2 glib2.0 folks (see below) vala
[15:34] <Laney> • Work with Renato on folks update, do this in Debian
[15:34] <Laney> ∘ Required some zeitgeist fixes first
[15:34] <Laney> ‣ In Debian this broke stuff: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=752482 - firefighting of this issue, seems fixed in new upstream release. Pending testing results & NMU.
[15:34] <Laney> • Look at theme problems in qt4 in Unity, turns out to be because we're not setting the deprecated(!) GNOME_DESKTOP_SESSION_ID any more. Patch upstart to set this.
[15:35] <Laney> ☀
[15:36] <seb128> Laney, thanks
[15:36] <seb128> tkamppeter, hey
[15:37] <seb128> no tkamppeter I guess
[15:37] <seb128> desrt, your turn ;-)
[15:37] <desrt> hi
[15:38] <desrt> not the most productive week -- got stuck in a number of debugging-the-compiler/library situations
[15:38] <desrt> got snagged by https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=731509 for example
[15:38] <desrt> but i did manage to get the fast mutexes finished and ready to merge -- they will go in probably today or tomorrow
[15:39] <desrt> also had a fight today with some new optimisations in gcc 4.9... sigh.
[15:39] <desrt> all in all one of those "learned a lot of things that i wish i didn't have to know...." weeks
[15:40] <seb128> yeah, I was just reading the #gtk+ backlog
[15:40] <seb128> compiler bugs are fun
[15:40] <desrt> don't get me started....
[15:40] <desrt> thing is -- this is arguably not a compiler bug
[15:40] <desrt> they'd tell me to complain at glibc
[15:40] <desrt> and glibc would tell me to complain at the C99 spec authors...
[15:41] <desrt> because it turns out that you cannot, in the general case, use memcmp() on an array.  go figure.
[15:41] <seb128> you are right, I should not get you started on that ;-)
[15:41] <seb128> desrt, thanks
[15:41] <seb128> attente, hey
[15:42] <attente> seb128: hey
[15:42] <attente> work on g-s-d, g-c-c, gnome-shell for the accountsservice patch
[15:42] <attente> g-s-d and gnome-shell work is ready, wrapping up g-c-c work which should be ready soon
[15:42] <attente> eof
[15:42] <desrt> \o/
[15:42] <seb128> nice
[15:43] <desrt> attente: if you need reviews, you know where to find me
[15:43] <seb128> seems to make desrt happy as well ;-)
[15:43] <attente> desrt: sure :)
[15:43] <desrt> attente: at the weston centre, most probably :p
[15:44] <seb128> attente, did you have anything still waiting for sponsoring?
[15:44] <seb128> I did the gtk sponsoring to utopic, I guess we should also get that to trusty once it has got some testing?
[15:44] <desrt> seb128: do we want to discuss the possibility of including the mir backend in the mainline uploads of gtk to the archive?
[15:45] <desrt> it's not in super-working form, but it does work.... and it's very isolated, so it's highly unlikely to regress the existing code
[15:45] <attente> seb128: right, i forgot, there's that u-g-m MP that tedg was reviewing, but was blocked by not having that gtk patch
[15:45] <seb128> desrt, we should discuss that, but having robert_ancell around when we do would be useful
[15:45] <desrt> k
[15:46] <attente> seb128: and i guess there's just that g-s-d sru, but i don't know if it's been uploaded to trusty-proposed yet
[15:46] <desrt> might be nice to figure out sooner or later what our workflow will look like there, because it's going to be strange
[15:46] <seb128> attente, g-s-d has been uploaded/approved and is being tested
[15:46] <attente> seb128: oh, ok, thanks for that :)
[15:46] <seb128> yw!
[15:47] <seb128> attente, feel free to ping tedg ont he u-g-m review I guess
[15:47] <seb128> I can do a landing for it then
[15:47] <attente> ok
[15:47] <seb128> attente, thanks
[15:47] <seb128> desrt, for what? the GTK Mir backend?
[15:47] <seb128> well, I guess it's going to be "have it as a distro patch on 3.12" for this cycle
[15:48] <seb128> which is already what we have, so no real issue
[15:48] <seb128> then depends on what it goes upstream
[15:48] <seb128> what->when
[15:49] <seb128> but we need robert_ancell for that discussion
[15:49] <desrt> seb128: ya... just pondering how we track the changes and where we keep them
[15:49] <desrt> indeed
[15:50] <seb128> ok, next is larsu if he's there
[15:50] <seb128> he said he would probably be away but send me his update before, but I don't think he actually did
[15:50] <seb128> larsu, ?
[15:50] <seb128> ok, I guess he's not around then
[15:50] <seb128> didrocks, hey
[15:51] <didrocks> yep ;)
[15:51] <didrocks> * Tweak and finished the category and framework loader functionality
[15:51] <didrocks> * Put this under tests and happily reached the bar of 120 tests!
[15:51] <didrocks> * Start fighting with the CLI with argparse and shell completion to get auto-registration and generation (and got back to some popular old python bugs…)
[15:51] <didrocks> * Try to fix and finally disabled Travis CI as it's running under 12.04 and we depend on python 3.4. Unfortunately, there is no pypi python-gobject and so, no virtualenv 3.4 on 12.04 to use system libs… I'm fallbacking at running the tests manually on my machine until 14.04 is available in Travis.
[15:51] <didrocks> * Some MIR-review work (some more onthe list)
[15:52] <seb128> oh, didrocks having some free slots again for archive activities, nice ;-)
[15:52] <seb128> didrocks, do you know when Travis plan to provide 14.04? waiting for .1?
[15:52] <didrocks> seb128: seems it's "in the work" since the last couple of month, but no ETA yet
[15:52] <didrocks> however, it's a popular topic on their bugtracker
[15:52] <didrocks> so I guess it will come soon :)
[15:52] <seb128> I can imagine ;-)
[15:53] <seb128> didrocks, thanks (and good work on the tests front ;-)
[15:53] <didrocks> thanks ;)
[15:53] <seb128> FJKong, hey, do you have anything to share this week?
[15:54] <happyaron> hi, late...
[15:54] <seb128> happyaron, hey, same ... if you have anything to share, now is the time!
[15:55] <happyaron> I'm working on the git migration, package auto-release for Sogou, and is waiting to see what to do for cinnamon
[15:55] <Laney> what is the git migration?
[15:55] <happyaron> we decided to not use bzr anymore for the project
[15:55] <seb128> what project?
[15:55] <happyaron> Sogou
[15:55] <seb128> oh, ok
[15:56] <attente> does that mean we no longer need to work on the fcitx-transition for unity?
[15:56] <happyaron> don't think so, just being too busy
[15:56] <didrocks> the package auto-release shouldn't use/be coordinated with the CI team?
[15:56] <happyaron> didrocks: for CI I think maybe, for auto-release no.
[15:57] <didrocks> happyaron: not sure I understand exactly what you mean by "auto-release" then :)
[15:58] <happyaron> didrocks: well, that's preparing packages for all commits with different version of components for QA
[15:58] <didrocks> happyaron: yeah, that's exactly what we do in CI and what the CI team is in charge, hence the "you should talk to them"
[15:58] <happyaron> OK
[15:59] <happyaron> but hell, the project we are working on is tightly following Sogou's normal development/release procedure
[15:59] <seb128> ok, let's discuss those details out of the meeting
[15:59] <seb128> happyaron, thanks
[16:00] <happyaron> :)
[16:00] <seb128> ok, my turn then
[16:00] <seb128> sponsoring (g-s-d/trusty, gtk3, eog)
[16:00] <seb128> • desktop updates (eog)
[16:00] <seb128> • handled CI landings (indicator-keyboard, u-g-m, ubuntu-themes, libdbusmenu-qt)
[16:00] <seb128> • landed the u-s-s wizard and then some bluetooth improvements
[16:00] <seb128> • debugged unity8-desktop issues (online accounts segfault, packagekit issues, indicator not starting, platform-api/backend issues)
[16:00] <seb128> • looked at some ubuntu-system-settings bugs, fixed a few UI issues in the updates panel
[16:00] <tkamppeter> seb128, sorry, I have missed it.
[16:00] <seb128> with the usual "reviewed errors.ubuntu.com, launchpad, kept an eye on SRUs, etc"

[16:00] <tkamppeter> seb128, here is what I did:
[16:00] <didrocks> seb128: how is that handover for u-s-s going?
[16:00] <seb128> tkamppeter, ok, your turn
[16:01] <tkamppeter> - Mentoring of GSoC students
[16:01] <tkamppeter> - Some organizational stuff for OpenPrinting Summit.
[16:01] <tkamppeter> - Bugs.
[16:02] <seb128> tkamppeter, thanks
[16:02] <FJKong> hey I am still working on sogou Input method project
[16:03] <seb128> FJKong, ok, thanks
[16:03] <seb128> didrocks, not so handed over yet, I know Pat is looking at the bug and trying to organize work
[16:03] <seb128> well, we have people doing work
[16:03] <seb128> cyphermox did some bluetooth improvements
[16:03] <didrocks> seb128: hoping for you it's happening soon to free you more cycles ;)
[16:03] <seb128> Ken is looking at some ofono changes
[16:04] <seb128> yeah
[16:04] <seb128> to be honest we didn't spent to much efforts on it recently, I mostly ignored it for over a months
[16:04] <seb128> just did some landing recently and looked at some UI issues/bugs today
[16:04] <seb128> but yeah
[16:04] <seb128> ok
[16:04] <seb128> is there any other topic?
[16:05] <seb128> seems not
[16:05] <seb128> let's wrap then
[16:05] <seb128> thanks everyone
[16:06] <Laney> thanks!
[16:06] <didrocks> thanks everyone!
[20:35] <seb128> jdstrand, thanks for the work on adding an apparmor profile to ubuntu-system-settings ... do you plan to do a merge request with the changes?  (you added debdiffs ... do you plan to upload directly?)
[20:45] <seb128> robert_ancell, hey
[20:45] <robert_ancell> hello
[20:45] <seb128> how are you?
[20:46] <seb128> robert_ancell, desrt mentioned today, during the weekly meeting, that we should discuss landing the GTK Mir backend
[20:46] <seb128> what do you think? does it same ready for that?
[20:46] <desrt> specifically, in the standard gtk packages in the distro
[20:47] <seb128> right, sorry, landing = upload to utopic
[20:47] <desrt> if we want this in by U we need to figure out the workflow
[20:47] <desrt> ie: periodically generate one mega-patch from an upstream gtk branch, or what?
[20:48] <robert_ancell> We just need the overlay scrollbar changes to land really and then we might as well. It's not amazing but there's no real cost to releasing it
[20:48] <robert_ancell> I'd say one mega-patch
[20:48] <seb128> that seems the easiest way to include it yes
[20:48] <seb128> robert_ancell, why do we need the overlay change?
[20:48] <desrt> one thing to consider is that this causes gtk to take a dependency on the mir client library
[20:48] <robert_ancell> It would mean that libmirclient is included on the image, has anything else pulled it in yet?
[20:48] <seb128> robert_ancell, I'm going to make that land tomorrow
[20:48] <robert_ancell> seb128, otherwise that GTK+ module will crash
[20:49] <jdstrand> seb128: working on it now. awe is going to coordinate the landing
[20:49] <seb128> jdstrand, ok, please go through the CI landing, otherwise you are going to invalidate silos/force them to rebase
[20:49] <jdstrand> seb128: yes, he said he would do that
[20:49] <seb128> great
[20:49] <seb128> jdstrand, thanks
[20:49] <robert_ancell> libmirclient seems fairly lightweight
[20:50] <seb128> robert_ancell, shrug, that's going to be an issue
[20:50] <jdstrand> I'm just doing the lowlevel stuff for the feature they wanted, they get to land it :)
[20:50] <desrt> robert_ancell: only crashes if you run with the mir gdk backend, right?
[20:50] <robert_ancell> desrt, yes
[20:50] <seb128> ;-)
[20:50] <seb128> robert_ancell, ignore what I just said
[20:50] <robert_ancell> these modules were just assuming the GDK backend was the X11 one
[20:50] <seb128> mir is already in main
[20:50] <seb128> I though it was not
[20:50] <desrt> seb128: but CD?
[20:51] <desrt> hah.  "CD"
[20:51] <robert_ancell> yeah, it's not the mainness, just the image size and any related dependencies
[20:51] <seb128> desrt, adding a small library to the iso is not an issue, we have libwayland there for example
[20:51] <desrt> cool -- didn't know if it was properly split out
[20:52] <seb128> robert_ancell, how much dependency/space are we talking about?
[20:52] <seb128> can't be more than a few hundred kbs
[20:52] <robert_ancell> Installed-Size: 629
[20:52] <seb128> right
[20:52] <seb128> that's fine
[20:52] <desrt> but any depends on gtest/gflag/boost/etc?
[20:52] <desrt> you're going to be taking at least boost asio... dunno if this is already in the image for something else
[20:52] <robert_ancell> + Installed-Size: 162 for libmirclientplatform-mesa
[20:52] <robert_ancell> do we already have boost on the images?
[20:53] <robert_ancell> libboost-system1.55.0 is Installed-Size: 83
[20:53] <robert_ancell> so, that's approx 874 total I think?
[20:54] <robert_ancell> oh, plus 393 for libmirprotobuf0
[20:54] <desrt> and protobuf itself...
[20:54] <robert_ancell> and 1083 if we don't have libprotobuf8 already
[20:54] <robert_ancell> We might?
[20:54] <seb128> you guys are doing it wrong
[20:54] <desrt> surprised not to see asio on this list...
[20:54]  * seb128 boots iso and run apt
[20:55] <desrt> seb128 is so damn high tech :p
[20:55] <robert_ancell> desrt, asio is all templates I think
[20:55] <desrt> with his VMs and ISOs
[20:55] <robert_ancell> woo
[20:55] <robert_ancell> What is installed size units again? k?
[20:56] <jdstrand> seb128: you probably saw the profile and the changelog, but just to be clear, this isn't about confining system-settings. this is about having it run with an apparmor label so that ofono is able to allow it access on DBus (phonedations wanted to restrict access to ofono's DBus interface to only a few services, excluding unconfined)
[20:56] <jdstrand> this should effectively be no change for system-settings
[20:56] <seb128> jdstrand, ok, that makes sense to me, thanks for explaining it ;-)
[20:57] <seb128> robert_ancell, yes
[20:58] <seb128> robert_ancell, desrt: that install the 3 libs previously listed and that counts for 243kb of deb and 1Mb installed
[20:59] <robert_ancell> do we have image budgets anymore?
[20:59] <seb128> no
[20:59] <robert_ancell> so that's probably acceptable thewn
[20:59] <seb128> we try to be reasonable though
[20:59] <seb128> yeah, without doubt
[20:59] <desrt> larsu: dunno if you followed, but removing "schema" property didn't go over too well....
[20:59] <seb128> there are other stuff we would axe before that
[21:00] <seb128> robert_ancell, ok, so i'm going to land the scrollbar change tomorrow ... then what, is the GTK patch good to go, or do you need more work?
[21:00] <desrt> seb128: almost all of the 'more work' required is blocked on mir changes
[21:00] <robert_ancell> that's it - we can just keep updating the GTK+ patch as needed
[21:00] <seb128> right
[21:00] <seb128> desrt, that shouldn't block us to land "what we have"
[21:00] <desrt> nope.  certainly not.
[21:00] <seb128> robert_ancell, https://bugs.launchpad.net/ubuntu/+source/unity8-desktop-session/+bug/1300925 btw
[21:01] <seb128> robert_ancell, that has that mention "   * Show desktop applications when CLICK_SCOPE_SHOW_DESKTOP_APPS is set"
[21:01] <seb128> robert_ancell, we might just want to export that in the unity8-desktop script
[21:01] <seb128> I didn't test it yet
[21:01] <robert_ancell> the main issue blocking for it to be usable is bug 1333029
[21:01] <seb128> robert_ancell, see what I just wrote ;-)
[21:02] <robert_ancell> ag
[21:02] <robert_ancell> ah
[21:02] <seb128> if I understand correctly that changelog, exporting that env should make unity8 not require the desktop key
[21:02] <seb128> need testing though
[21:02] <robert_ancell> that's a dupe right?
[21:02] <seb128> yes
[21:03] <seb128> though Saviq/mhr3 were unsure if we still need that filter or if it's the right way
[21:03] <seb128> the intend is to not list a ton of entries that don't work
[21:03] <robert_ancell> sure
[21:03] <seb128> we are still going to have the issue that if we don't filter we show e.g libreoffice
[21:03] <seb128> or java stuff
[21:03] <seb128> or wxwidgets apps
[21:03] <seb128> or gtk2 ones
[21:04] <seb128> not sure how we can best resolve that
[21:04] <robert_ancell> it's a bit tricky, because you really don't know unless you whitelist and that's not practical
[21:04] <seb128> the desktop key might be the best way
[21:04] <robert_ancell> we need to ld_preload something and detect if your accessing a blacklisted library and stop and show a dialog in that case
[21:04] <seb128> it means somebody has to review that the app works under Mir
[21:04] <seb128> well
[21:04] <seb128> or we need to get XMir
[21:05] <robert_ancell> I should talk to RAOF and see if I can help out there. That would open up more options for us
[21:06] <seb128> right
[21:06] <seb128> if we get XMir we solve the issue
[21:06] <seb128> if we don't, I would say the best solution might to flag things that are "known to be working"
[21:06] <seb128> either by patching those, or building a whitelist
[21:06] <seb128> either way would work but is work
[21:06] <seb128> the whitelist might be less work than carrying delta on debian packages
[21:07] <robert_ancell> seb128, right, I was thinking of patches for each package but just a big-ol-whitelist in unity of .desktop file names would work fine
[21:08] <seb128> +1 for the whitelist
[21:08] <seb128> or export the variable and deal with the fact that stuff in the list are going to not run
[21:08] <robert_ancell> anyone working on that? Shall we have a go?
[21:08] <seb128> until we get XMir
[21:08] <robert_ancell> I think that would be worse
[21:08] <seb128> right
[21:08] <seb128> can you get info on how likely XMir is for trusty?
[21:08] <seb128> ups
[21:08] <seb128> utopic
[21:08] <robert_ancell> Yeah, I'll ask
[21:08] <seb128> thanks
[21:09] <seb128> if it's not, so let's do the whitelist thing
[21:09] <robert_ancell> Anything else higher priority?
[21:10] <seb128> not that I know
[21:10] <robert_ancell> seb128, oh, what happened with that branch you wanted me to review
[21:11]  * robert_ancell tries to remember what it was...
[21:11] <seb128> when was that?
[21:11] <robert_ancell> last week sometime
[21:11] <seb128> oh, making u-s-d include the old libgnome-desktop code?
[21:11] <robert_ancell> You take a few days off and you loose track of everything :)
[21:11] <robert_ancell> yes, that one
[21:11] <seb128> that didn't happen
[21:12] <robert_ancell> You want me to look at that one?
[21:12] <seb128> I looked at it, but u-s-d uses gnome-desktop for other things in other plugins
[21:12] <seb128> it's not easy
[21:12] <seb128> if you want, sure
[21:12] <robert_ancell> are those other things changing too?
[21:12] <seb128> but I think we should just ship libgnome-desktop3.8 as a separate source and build u-s-d with it
[21:12] <seb128> no
[21:12] <seb128> but it makes a lot of code to copy
[21:13] <robert_ancell> I thought there was some reason we couldn't copy the lib, but it is just basically helper functions right?
[21:13] <seb128> we can't use the system lib and a local one, or we need to rename symbols
[21:13] <robert_ancell> was there a bug?
[21:13] <seb128> it's quite some code/functions
[21:13] <seb128> not sure, I don't think so
[21:13] <seb128> the reason for not copying the lib was "let's try to avoid having another lib copy in the archive", but that's not a blockerr
[21:14] <robert_ancell> I'll have a look.
[21:15] <seb128> robert_ancell, thanks, let me know your conclusion after looking at it, mine was that the copy of the old lib is the easiest way
[21:15] <seb128> on that note calling it a day
[21:15] <seb128> good night (or day for those on the other side of the world) everyone ;-)
[21:15] <robert_ancell> btw, this is my list of things blocking gtk-mir https://bugs.launchpad.net/bugs/+bugs?field.searchtext=&orderby=-importance&search=Search&field.status%3Alist=NEW&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.status%3Alist=FIXCOMMITTED&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&assignee_option=any&field.assignee=&field.bug_reporte
[21:15] <robert_ancell> r=&field.bug_commenter=&field.subscriber=&field.tag=gtk-mir&field.tags_combinator=ANY&field.status_upstream-empty-marker=1&field.has_cve.used=&field.omit_dupes.used=&field.omit_dupes=on&field.affects_me.used=&field.has_patch.used=&field.has_branches.used=&field.has_branches=on&field.has_no_branches.used=&field.has_no_branches=on&field.has_blueprints.used=&field.has_blueprints=on&field.has_no_blueprints.used=&field.has_no_bluep
[21:15] <robert_ancell> rints=on
[21:16] <robert_ancell> night
[21:16] <robert_ancell> desrt, were you happy with the a-s solution I put into utopic for large UIDs?
[21:17] <seb128> robert_ancell, https://bugs.launchpad.net/bugs/+bugs?field.tag=gtk-mir
[21:17] <seb128> nicer url
[21:17] <robert_ancell> hah, I was just trying to find a nicer url
[21:18] <seb128> ;-)
[21:18] <seb128> ok, on that note, bye


[00:10] <TheMuso> Woohoo! There is a new release of the l4t stack, and we now have a gstreamer module for multimedia playback, and they even included a player with it.
[00:19] <twb> lilstevie: can you think of any reason why wifi wpa wouldn't work out-of-the-box under the ubuntu installed from your olife thingo?
[00:20] <twb> I noticed that android uses a different MAC for the same wlan0 NIC, so I have enabled both on the AP (openwrt hostapd), but it still doesn't like me.
[00:21] <twb> http://paste.debian.net/148936/ is the approach I'm trying
[00:23] <TheMuso> twb: Which kernel are you running?
[00:25] <twb> <IP_ADDRESS>
[00:25] <twb> The guy next to me has the 16GB model and is running olife as well and his is working.
[00:25] <twb> And I double-checked the PSK so WTF
[00:25] <TheMuso> Ah ok. I had to try a couple of times to connect to my WPA network, but it connected eventually.
[00:25] <TheMuso> But I use 2.6.38 with uBoot.
[00:26] <TheMuso> Sorry I should clarrify. I can connect without issue running under 2.6.38, but had a few times where I had to retry when using the 2.6.36 kernel.
[00:26] <twb> OK
[00:29] <twb> Grr
[00:29] <twb> I can see wpa_supplicant associating and then being kicked off again (reason=0)
[00:31] <doko> infinity, the gcc-snapshot build on ain could be killed (superseded and will fail anyway). new one running on satiniash. could need a panda to build. afk now
[00:59] <twb> OK I give up for now
[01:00] <twb> Same AP is working under android, even.  Even *copying* the wpa_supplicant.conf from android doesn't work.
[01:27] <lilstevie> twb: interesting
[01:28] <lilstevie> twb: can you pastie your whole dmesg
[01:28] <lilstevie> TheMuso: yeah, u-boot installs are cool :p
[01:29] <lilstevie> twb: wait, if you are using wpa_supplicant rather than network manager I have a few suggestions
[01:34] <steev_> lilstevie: NM uses wpa_supplicant
[01:35] <Sycro5> Hello, I'm looking for some help regarding bluetooth on the Pandaboard.  I've tried to use both the onboard BT as well as an external USB BT adapter without success.  I'm running Ubuntu 11.10.  Has anyone successful got BT working or have suggestions for me?
[01:37] <Sycro5> with the onboard bluetooth, I'm not even able to turn BT on.  When I use the adapter, I can turn it on and even find BT devices but can't pair with any of them
[01:40] <lilstevie> steev_: yes, but using the supplicant directly isn't straight forward
[01:44] <Sycro5> So would it be possible to pair a wii remote with the pandaboard to use the wii remotes IR camera?
[01:44] <Sycro5> And is it easier to use the onboard BT or the USB dongle?
[02:01] <twb> lilstevie: FWIW using supplicant directly is the same process I'm doing on every other wifi client I have
[02:01] <twb> lilstevie: those instructions I posted?   I wrote those :-)
[02:01] <twb> Which dmesg did you want?
[02:02] <lilstevie> your booted one, but then I saw how you were doing it
[02:02] <twb> k
[02:02] <lilstevie> http://rootzwiki.com/topic/947-ubuntu-on-the-transformer/page__view__findpost__p__23297
[02:03] <lilstevie> thats how it was done before nm accepted the device as wireless
[02:04] <twb> I could try nm if you like
[02:05] <twb> I didn't try ap_scan=2; I'm getting as far as associating and auth'ing w/the AP, so that shouldn't matter...
[02:05] <lilstevie> fair enought
[02:05] <lilstevie> eough even
[02:05] <lilstevie> ah
[02:05] <lilstevie> I give up
[02:06] <twb> Yeah, it's bloody weird
[02:06] <twb> I'm going to test at home before I fiddle around much more, because at home I have a single PSK for all MACs, whereas as at work each MAC has its own PSK
[02:06] <twb> (Yes, I gave the same PSK to both android and ubuntu MACs)
[02:08] <lilstevie> yeah, the MAC issue is a bit of a pita
[02:09] <lilstevie> a closed source, and libbionic daemon does that
[02:10] <twb> Hum, maybe I have accdentally stoppd that
[02:11] <twb> IIRC the only service I turned off was lightdm tho
[02:15] <lilstevie> lol
[02:16] <lilstevie> I mean the MAC issue is a pita because it won't run
[02:16] <twb> Ah right
[02:16] <lilstevie> and is closed source
[02:48] <Sycro5> can anyone help me out with the bluetooth issue?
[12:24] <q4a> hi all. Is there fix or workaround of this bug? https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/901847
[12:24] <ubot2> Launchpad bug 901847 in ubiquity "armhf+omap4 desktop installer dies in plugininstall.py" [High,Confirmed]
[12:25] <ogra_> not yet, no
[12:25] <q4a> thx for answer
[12:28] <doko> janimo, ping on bug 861296, linux-ac100
[12:28] <ubot2> Launchpad bug 861296 in linux-ti-omap4 "mmap fails to allocate 2030Mb heap on ARM" [Undecided,Fix committed] https://launchpad.net/bugs/861296
[12:37] <ogra_> bah, someone was faster on giving back gst-plugins-good
[12:37]  * ogra_ bets infinity ...
[12:37] <lool> Gave back gst-plugins-good0.10/armel (and /powerpc) against latest libavc1394 to pick up multiarch .la file change
[12:38] <lool> ogra_: I was  :-0
[12:38] <ogra_> haha
[12:38] <lool> it took me a bit long to figure out that the .la file had been fixed already
[14:27] <janimo> doko, yes? Regarding the mmap bug?
[14:42] <doko> janimo, yes, apply to linux-ac100
[14:43] <janimo> doko, will for precise, I am not sure it's worth the hassle for oneiric
[14:44] <janimo> only for consistency maybe
[14:45] <doko> janimo: please do it for consistency then.
[14:47] <ogra_> janimo, while youre at it you could also do the config change :)
[14:47] <ogra_> so that the internal mic works
[15:04] <janimo> ogra_, which change is that? I was not aware we're only one config toggle away from mic working
[15:04] <ogra_> just that one :)
[15:05] <ogra_> (usb sound stuff)
[16:37] <ogra_> lool, poke
[16:38] <ogra_> lool, david pointed me to you, we seem to have some weird armhf behavior in bug 901847
[16:38] <ubot2> Launchpad bug 901847 in ubiquity "armhf+omap4 desktop installer dies in plugininstall.py" [High,Confirmed] https://launchpad.net/bugs/901847
[16:38] <ogra_> seems users cant execute shells in hf installs
[16:40] <lool> ogra_: Do you have such an environment?
[16:40] <lool> I would suspect it could be due to the runtime linker
[16:40] <ogra_> i only have the chroot i mentioned... where it apparently works ...
[16:40] <ogra_> but xranby has an install on his ac100
[16:40] <lool> xranby: Oy
[16:41] <ogra_> (the bug manifests the same way on all hf images it seems)
[16:45] <lool> other chroot calls work, so probably something with sudo / pam
[16:46] <lool> I wonder whether this is relevant: Dec  8 19:55:41 localhost ubiquity: dpkg-trigger: error: must be called from a maintainer script (or with a --by-package option)
[16:46] <infinity> lool: No, that's a red herring.
[16:46] <infinity> I wonder if this relates to the procps "when I upgrade, my system explodes" madness somehow.
[16:47] <infinity> Cause users can definitely execute shells on armhf.  If they couldn't, our buildds wouldn't work.
[16:47] <ogra_> but thats not a chroot ... (the breakage i mean)
[16:47] <infinity> ogra_: What do chroots have to do with anything?
[16:47] <ogra_> well, in chroots it works ...
[16:48] <ogra_> i can chroot/sudo into a user shell
[16:48] <ogra_> while the same thing doesnt work on a bare install
[16:48] <GrueMaster> To add to that, I have a semi-working netinstall (prior to the libc6 udeb issue) that will only log me in if I have init=/bin/sh.
[16:48] <ogra_> root can run any shell on that same install though
[16:48] <infinity> ogra_: Sure, but I still suspect it's the same issue.
[16:49] <ogra_> hmm
[16:49] <GrueMaster> I can't log in to the same image with a normal init, even with ssh.  Gets most of the way in, but chokes on giving me a shell prompt.
[16:49] <infinity> Boom, killed.
[16:49] <ogra_> try systemd instead :P
[16:49] <infinity> Just like that.
[16:49] <infinity> ogra_: /etc/init.d/procps start
[16:50] <infinity> ogra_: Do that in a chroot with proc mounted, watch system explode for all !root users.
[16:50] <infinity> ogra_: Now, realise that any installed system does that on boot.
[16:50] <infinity> GrueMaster: Remove procps's init script and see if it boots.
[16:50] <ogra_> infinity, hmm, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=631807 ??
[16:50] <ubot2> Debian bug 631807 in libcap-ng0 "segfault in libcap-ng0 is back on armel - filecap , bluetoothd etc" [Important,Open]
[16:51] <GrueMaster> ok.  Will try (if the system is still imaged).
[16:51] <ogra_> i wonder if that could reach into our issue
[16:52] <infinity> Maybe.
[16:52] <infinity> But I don't see a SEGV here.
[16:52] <ogra_> yeah
[16:53] <infinity> GrueMaster: (note that it's actually an upstart job, so /etc/init/procps.conf is what needs to go)
[16:54] <GrueMaster> I know.
[16:54] <infinity> So, something in "cat /etc/sysctl.d/*.conf /etc/sysctl.conf | sysctl -e -p -" is killing us.
[16:54] <infinity> Just need to iterate through reboots until I find the culprit.
[16:54] <ogra_> does it die if you run it manually ?
[16:54] <infinity> I can reboot and see.
[16:55] <GrueMaster> bah.  System was reimaged to precise armel.  I don't have that install to test (and netinst is borked due to libc6-udeb).
[16:56] <GrueMaster> Will muck with a server image.
[16:56] <infinity> Server dies in the installer with the same issue.
[16:58] <infinity> ogra_: Yeah, doing it manually produces the same result.  Which is comforting.  It's not upstart's fault.
[16:58] <infinity> ogra_: Just one of these settings is broken.
[16:58] <ogra_> yay
[16:59]  * infinity is inclined to blame one of:
[16:59] <infinity> kernel.yama.ptrace_scope = 1
[16:59] <infinity> vm.mmap_min_addr = 65536
[16:59] <ogra_> and since its on panda as well, it cant be my tewaks in the ac100
[16:59] <infinity> Another reboot and testing.
[16:59] <ogra_> hmm, the min addr thing was required for something on armel
[16:59]  * ogra_ forgot what though
[17:00] <infinity> Wait, does the file installed on armel differ?
[17:00] <ogra_> no
[17:00] <ogra_> same file
[17:00] <ogra_> but apparently different behavior
[17:00] <infinity> No, it's a different value.
[17:00] <infinity> At least, it is here...
[17:00] <ogra_> cant
[17:00] <infinity> Why can't it be? :P
[17:01] <ogra_> the bit putting it there is the same on both
[17:01] <ogra_> cat attack, cant type atm ...
[17:02] <infinity> Well, the default is:
[17:02] <infinity> vm.mmap_min_addr = 65536
[17:02] <infinity> My quickstart has:
[17:02] <ogra_> right
[17:02] <infinity> # ARM-specific default:
[17:02] <infinity> vm.mmap_min_addr = 32768
[17:02] <ogra_> ugh
[17:02] <ogra_> how does that get there
[17:03] <ogra_> jasper puts it in place on non ac100
[17:03] <infinity> Eh?
[17:03] <infinity> It does no such thing.
[17:03] <ogra_> and ac100-tarball-installer in ac100
[17:03] <infinity> adconrad@cthulhu:~/pps/jasper-initramfs-0.66$ rgrep zeropage *
[17:03] <infinity> adconrad@cthulhu:~/pps/jasper-initramfs-0.66$
[17:03] <infinity> You may be mistaken.
[17:03] <ogra_> jasper_setup should
[17:03] <GrueMaster> Interesting on the mmap_min_addr thing.  On omap kernel, that is the correct value, but on omap4 it is 32768
[17:04] <GrueMaster> Makes kernel SRU testing fail btw.
[17:05] <infinity> For the record, this fixes it:
[17:05] <infinity> sed -i -e 's/65536/32768/' /etc/sysctl.d/10-zeropage.conf
[17:06] <infinity> So, we should probably just ship the right value in procps.
[17:06] <ogra_> yep
[17:06] <infinity> Cause editing conffiles from other packages is wrong, wrong, wrong.
[17:06] <ogra_> jasper never did that
[17:06] <infinity> But what did?
[17:06] <ogra_> its a .d dir
[17:06] <infinity> Something gave me the right value on my QS.
[17:07] <infinity> And even with a comment!
[17:07] <ogra_> jasper puts an override file in place
[17:07] <infinity> ogra_: Yes, but this is the same file.
[17:07] <infinity> ogra_: Same filename as the one in procps.
[17:07] <ogra_> strange
[17:07] <infinity> Anyhow, now that I've found the issue, will fix after my call.
[17:07] <ogra_> awesome
[17:17] <ogra_> infinity, oh, i was wrong anyway wrt jasper ... vm.min_free_kbytes = 8192 is what we set there (for an USB NIC issue)
[17:18] <ogra_> workaround for bug 746137
[17:18] <ubot2> Launchpad bug 746137 in jasper-initramfs "Page allocation failure on Pandaboard and Beagle XM" [Undecided,Fix released] https://launchpad.net/bugs/746137
[17:18] <ogra_> see sysctl/30-jasper-smsc-min-free-kbytes.conf
[17:19] <ogra_> in the jasper tree
[17:28] <ogra_>         # If a non-arch-specific default exists, install the arch-specific
[17:28] <ogra_>         # version of the conf in place of it, otherwise, build up a general
[17:28] <ogra_>         # 10-arch-specific.conf file.
[17:28] <ogra_>         for archconf in debian/sysctl.d/*.conf.$(DEB_HOST_ARCH); do \
[17:28] <ogra_> infinity, ... nothing modifies it, procps itself puts a different file in place for armel
[17:28] <ogra_> (thats from debian/rules ... i think we just need to drop the armel file from the source)
[17:29] <ogra_> err, other way round, cp the armel file to an armhf file
[17:30]  * ogra_ does that
[17:34] <ogra_> uploaded
[17:34] <infinity> ogra_: \o/
[17:38] <lool> Was this the sudo chroot issue?
[17:38] <ogra_> lool, right
[17:38] <ogra_> vm.mmap_min_addr being set to a too high value
[17:39] <ogra_> since the original fix was bound to the armel arch naming
[17:40] <lool> Ok; I'll stop the install I was running -- it's really painful to work with full images instead of a small armhf chroot!
[17:41] <ogra_> just use ubuntu-core if you need a minimal one :)
[17:42] <ogra_> (just take an existing install and replace the rootfs with ubuntu-core and add a root pw)
[18:10] <infinity> ogra_: I do wonder how many other armel-specific hacks we might be missing for armhf. :/
[18:10] <ogra_> well, iirc there were a few made by the security team like this one
[18:10] <ogra_> but they were rather kernel defaults so we should be good here
[18:11] <ogra_> i guess we'll run into them over time
[18:11] <ogra_> the bad thing is that i really cant remember all of them anymore ... i only remembered the procps thing that kees did when i actually looked at the code
[18:12] <ogra_> the bad part here is that it wasnt even mentioned in the changelog or anything
[18:42] <ogra_> infinity, hmm, i was hoping the janitor just had a hiccup
[18:42] <ogra_> (thats why i didnt manually close yet)
[18:42] <infinity> ogra_: I didn't check timing, but I assume you uploaded before you added the procps task.
[18:43] <ogra_> yeah, in the hope it just closes by bug number :P
[18:43] <infinity> Yeah, it won't. ;)
[18:43] <ogra_> which it apparently doesnt anymore
[18:43] <infinity> A procps upload can only close a bug in procps.
[18:43] <ogra_> well, it used to not care for the package in the past
[18:44] <infinity> (Which I think is a silly limitation that creates busywork, but whatever)
[18:44] <ogra_> right
[18:46] <GrueMaster> We should still make sure the kernels have the correct  CONFIG_LSM_MMAP_MIN_ADDR setting.  Currently, they are different on omap vs omap4.
[18:46] <infinity> GrueMaster: Except that, on boot, they all get set to the procps-provided one anyway.
[18:46] <ogra_> doesnt matter since procps overrides them (on all arches) anyway
[18:46] <infinity> (But yes, the kernel defaults should match)
[18:46] <ogra_> *snap*
[18:46] <ogra_> agreed
[18:47] <infinity> GrueMaster: Which one's wrong?
[18:47] <ogra_> and there are plenty of packages that modify them as well
[18:47] <infinity> Oh, I'm betting omap, because it probably matches the x86 kernels.
[18:47] <infinity> Right?
[18:47] <ogra_> via sysctl.d files
[18:47] <GrueMaster> Well, the QRT scripts look at the kernel config settings.
[18:47] <ogra_> which is completely wrong in this case
[18:47] <GrueMaster> Not sure, but I would assume the omap4, since it is out-of-main.
[18:48] <GrueMaster> What should be correct, 32768 or 65536?
[18:48] <infinity> 32768
[18:48] <GrueMaster> Ok, them omap is wrong.  At least in the kernel config.
[18:48] <ogra_> fun
[18:48] <infinity> Though, that's questionable.  I wish I could track down WHY arm was set differently.
[18:49] <infinity> ogra_: Any ideas there?
[18:49] <ogra_> i dont remember it anymore
[18:49] <ogra_> i was involved in it
[18:49] <infinity> Awesome.
[18:49] <ogra_> we should ask kees
[18:49] <ogra_> he probably remembers it better than me
[18:49] <GrueMaster> He didn't know.
[18:49] <ogra_> it dates back to jaunty
[18:49] <infinity> GrueMaster: For now, then, making omap match the rest sounds "correct", until we can sort out why not.
[18:49] <GrueMaster> I worked with him all day Friday on these scripts.
[18:51] <ogra_> iirc it blocks a security feature of the kernel on arm if it is set to high
[18:51] <ogra_> null pointer dereference or some such
[18:52] <infinity> That's what it's for in the first place (preventing null dereferencing)
[18:52] <kees> hola
[18:52] <infinity> But I'm willing to believe it's weird on ARM.  We should just get the omap default fixed.
[18:52] <GrueMaster> Well, none of the scripts are broken now.  I worked with him Friday, and we have everything running on all arm HW.
[18:52] <infinity> kees: Yo.
[18:53] <kees> mmap_min_addr on arm needed to be 32k because, IIRC, qemu and some of the dynamic loaders put stuff below 64k.
[18:53] <infinity> kees: Wouldn't that be true on all arches...?
[18:53] <kees> infinity: all arch flavors? yes, I assumed so.
[18:54] <infinity> kees: No, I meant !arm... Curious why qemu would be different only there.
[18:54] <kees> I have no problem seeing it raised, btw. this was a requirement from ogra_ originally.
[18:54] <ogra_> yay
[18:54] <ogra_> it was the dynamic loader thing
[18:54] <ogra_> now i remember
[18:54] <infinity> Raising it seems to make the system explode, so I suspect we were right. :P
[18:54] <kees> infinity: oh, I assume because memory layouts were different between archs
[18:54] <infinity> I just wish the reasoning had been documented.
[18:55] <ogra_> infinity, qemu even explodes with values above 4k iirc
[18:55] <ogra_> and wine or dosemu have other values as well
[18:55] <kees> oh! that's right, qemu was 4k, hence a sysctl file on install. yeah
[18:55]  * infinity nods.
[18:55] <infinity> Alright.
[18:55] <ogra_> and there might be other packages i dont re,ember
[18:55] <infinity> So, ARM's ld.so is weird or something.  Having been in there, I can buy that.
[18:55] <kees> dosemu is fully emulated so it doesn't care about mmap_min_addr. wine in 32bit mode doesn't care either. wine in 16bit mode beens access to 0 addr.
[18:56] <ogra_> ah, right
[18:56] <kees> beens? needs.
[18:56] <infinity> beens!
[18:56] <ogra_> heh
[18:56] <kees> what an odd typo
[18:56] <infinity> kees: You're an odd fellow.
[18:56] <infinity> kees: Sees to fit.
[18:56] <kees> infinity: fair point
[18:56] <infinity> Seems, too.
[18:56] <infinity> Fuck typing.
[18:56] <kees> infinity: where would you have expected the 32k thing to be documented, btw?
[18:57]  * ogra_ wants a t-shirt with that
[18:57] <infinity> kees: In the sysctl fragment that's different on ARM, perhaps?
[18:57] <ogra_> kees, iirc there was a bug for it
[18:57] <ogra_> but launchpad doesnt like to find it
[18:57] <infinity> kees: Right now, it has a very unhelpful "# ARM-secific default:" comment.
[18:57] <ogra_> for the arm part at lest
[18:57] <kees> infinity: ah, yeah
[18:57] <ogra_> i find all the wine bugs though
[18:58] <kees> # ARM-specific default, due to the dynamic loader using regions below 64k:
[18:58] <kees> ^^ how about that?
[18:58] <ogra_> and i know we discussed it at lenght back then
[18:58] <ogra_> so there *must* be irc logs
[18:58] <ogra_> but i cant find them either
[18:58] <infinity> kees: If that's the truth, then yes, sounds lovely. ;)
[18:59] <infinity> kees: If by "the dynamic loader", you mean "ld.so", being specific doesn't hurt.
[18:59] <kees> ogra_: how should that comment read? was there a bug for it?
[19:00] <GrueMaster> I just did a google for arm sysctl mmap_min_addr site:launchpad.net and all the results point to qemu.
[19:00] <GrueMaster> Karmic timeframe.
[19:00] <ogra_> kees, i *think* we had a bug ... but seriously, that was jaunty or karmic my mind doesnt date back that far
[19:00] <kees> yeah, me either
[19:01] <ogra_> i remember discussing the qemu part with you in dublin
[19:01] <kees> yeah, that was a whole different issue. that was the 4k part, not the 32k
[19:01] <ogra_> but at that time the procps side was already in place
[19:01] <ogra_> and we did that one online
[19:01] <ogra_> its weird that google doesnt find a single irc log
[19:02] <ogra_> http://irclogs.ubuntu.com/2009/03/18/%23ubuntu-kernel.txt
[19:02] <ogra_> ha !
[19:03] <ogra_> doesnt have the explanatiojn though :(
[19:03] <ogra_> only the discussion
[19:03] <kees> yeah
[19:03] <ogra_> [17:38] <ogra> the help of SECURITY_DEFAULT_MMAP_MIN_ADDR says "On arm and other archs it should not be higher than 32768."
[19:03] <ogra_> thats the reason :)
[19:04] <ogra_> we did it because i read docs :P
[19:04] <infinity> [17:29] <kees> according to the Kconfig help text, anyway
[19:04] <infinity> [17:29] <kees> ia64, ppc64, x86: 65536, all others: 32768
[19:04] <ogra_> yep
[19:05] <infinity> Alright, well.  Fixed now.  I have eglibc things to do.
[19:05] <GrueMaster> So we need to fix omap.  Good to know.
[19:05] <infinity> GrueMaster: Want to file a bug?
[19:05] <GrueMaster> yep.  I like filing kernel bugs.  Keeps them on their toes.
[19:06] <infinity> Thankfully, init/procps probably starts early enough for it to be a non-issue, but...
[19:16] <GrueMaster> Other than kconfig saying we should set it this way, is there any other compelling reason?
[19:16] <parin1> on ubuntu 11.10 touchscreen freezes after some time
[19:17] <parin1> i use http://www.amazon.com/e2239Fwt-21-5-LED-Touchscreen-Monitor/dp/B0056J9JPC
[19:18] <slangasek> infinity, kees, ogra_: current qemu does not need any special handling of minimum memory addresses; we killed that sysctl file off a while ago
[19:18] <kees> slangasek: cool
[19:19] <infinity> GrueMaster: Well, Kconfig seems to be right. ;)
[19:20] <GrueMaster> I'm just curious as to what it would affect.  It has been 65536 on omap since we started using main (natty or oneiric - can't remember).
[19:21] <infinity> GrueMaster: Except that it's reset on boot.
[19:21] <infinity> GrueMaster: So, it's not actually that at all.
[19:21] <infinity> GrueMaster: if it wasn't for the procps init job setting it to 32k, everything non-root would fail.
[19:21] <infinity> GrueMaster: (As seen by the current armhf bug that Oli just fixed)
[19:22] <GrueMaster> Ah.
[19:22] <GrueMaster> ok.
[19:23] <GrueMaster> So this may impact booting w/o initrd possibly?
[19:23] <infinity> Nah.
[19:23]  * GrueMaster needs to see how far back this affects omap kernels.
[19:24] <infinity> But it impacts anything that one might try to start from init as !root before the procps job runs.
[19:24] <infinity> (Which, in practice, seems to be little or nothing, but still)
[19:24] <infinity> A kernel default that doesn't allow non-root use seems suboptimal. ;)
[19:26] <GrueMaster> I'm just wondering if it needs attention for the next SRU run.
[19:27] <infinity> It should probably be fixed in omap SRU kernels.  Can't hurt to fix it.
[19:27] <infinity> But it's not particularly critical, if things have been working.
[19:27] <slangasek> infinity: why does this affect !root?  Does this imply qemu should in fact re-add the sysctl file, even though I haven't been able to find any failures with it gone?
[19:28] <GrueMaster> Ok, so I need to backtrack and see how far back it is affected.  I'll put a med priority on it.
[19:29] <infinity> slangasek: The setting only affects !root.  Root can map whatever they want.
[19:29] <slangasek> yes, and when I run qemu, I run !root
[19:29] <infinity> slangasek: In the ARM case, having the wrong setting (64k) breaks.
[19:29] <infinity> slangasek: The qemu thing is entirely unrelated.
[19:29] <slangasek> ok
[19:37] <parin1> any one used touchscreen on ubuntu 11.10?
[19:46] <GrueMaster> infinity: ogra_  Bug #903346 filed.  Will list broken kernel releases that need to be addressed shortly.
[19:46] <ubot2> Launchpad bug 903346 in linux "On omap, CONFIG_DEFAULT_MMAP_MIN_ADDR needs to be set to 32768 per kconfig notes" [Medium,Confirmed] https://launchpad.net/bugs/903346
[19:55] <ogra_> GrueMaster, awesome, great
[19:56] <GrueMaster> Confirmed also in Natty.  Pulling maverick to see if it is affected as well.
[19:56] <ogra_> funny that omap still works though
[19:56] <ogra_> why are you able to exec anything if its 65k
[19:57] <infinity> ogra_: Because procps resets it.
[19:57]  * GrueMaster sheepishly admits to accidentally purging release images on desktop before checking internal mirror to verify backup).
[19:57] <GrueMaster> The sysctl is there to correct it.
[19:57] <ogra_> then we have been really really lucky with our initrd and upstart
[19:57] <infinity> ogra_: The initrd runs entirely as root.
[19:57] <ogra_> oh, indeed
[19:57] <infinity> ogra_: As do most/all upstart jobs before the procps script.
[19:57] <ogra_> and pid 0 as well
[19:58] <ogra_> you mentioned it before, now i understand what you meant :P
[19:58]  * ogra_ didnt relate that comment to omap before
[19:59] <infinity> Right.  I need a short nap to recover from last night before I finish this eglibc merge.
[19:59] <GrueMaster> So this really only would affect users that take our code and do weird embedded work with it (or other things).
[19:59] <infinity> I suspect it's best not to upload libc when I'm in this state. :P
[19:59] <ogra_> nobody doing embedded work would use our stff anyway
[19:59] <ogra_> infinity, go to bed
[19:59]  * ogra_ goes back to TV
[20:00]  * GrueMaster considers searching for lunch.
[20:00] <infinity> GrueMaster: Or someone naively removing the config file, or disabling the procps init, or trying to run an init job as !root before procps's runs, or...
[20:01] <infinity> GrueMaster: In the end, the procps bits and the kernel defaults should match, it's pretty unexpectedly strange when they don't, I'd say.
[20:01] <ogra_> if i *would* do embedded work with ubuntu i would do it as initrd hooks and abuse update-initramfs to build my rootfses though
[20:01] <infinity> (Especially since the sysctl snippets claim to mirror the defaults)
[20:01] <ogra_> to keep it as tiny as possible
[20:02] <ogra_> and i bet others doing embedded stuf would do something similar ... anyway i would expect most stuff to run as root in embedded
[20:02] <ogra_> anyway, really TV now


[14:16] <mup> PR snapcraft#3960 opened: ua: do not re-enable enabled services <Created by mr-cal> <https://github.com/snapcore/snapcraft/pull/3960>
[14:16] <mup> PR snapcraft#3961 opened: ua: do not re-enable enabled services for snapcraft_legacy <Created by mr-cal> <https://github.com/snapcore/snapcraft/pull/3961>
[14:46] <mup> PR snapd#12265 closed: DT-728: fix "being refreshed" notifications <Needs Samuele review> <Created by sergio-costas> <Closed by sergio-costas> <https://github.com/snapcore/snapd/pull/12265>
[19:11] <mup> PR snapcraft#3962 opened: Setup snapd for snapcraft_legacy providers <Created by mr-cal> <https://github.com/snapcore/snapcraft/pull/3962>
[21:26] <mup> PR snapcraft#3963 opened: meta: support top-level `provenance` keyword for on-prem support <Created by mr-cal> <https://github.com/snapcore/snapcraft/pull/3963>


[04:28] <akp55> hey, how can i bring up a vlan without an address assigned to it?  i see this about bringing up a std interface w/o an address -  enp10s0f1: {}, but nothing for vlan/. here is my netplan conf - https://termbin.com/1zfm


[06:36] <YoBoY> good morning
[07:04] <dholbach> good morning!
[07:32] <czajkowski> aloha
[08:13] <valorie> czajkowski: aloha
[08:13] <valorie> I've been out of town, and was reading up
[08:14] <valorie> someone was asking about our Washington state LoCo
[08:14] <valorie> and was directed to the deprecated team URL
[08:14] <valorie> is progress being made on getting those old team names gone?
[08:15] <valorie> in our case, http://loco.ubuntu.com/teams/washingtonstate
[08:16] <valorie> rather than http://loco.ubuntu.com/teams/ubuntu-washington
[09:24] <czajkowski> valorie: no idea, it's an annoying bug
[09:24] <czajkowski> also helps if teams start naming themselves correctly :)
[09:30] <valorie> lol
[09:30] <valorie> I can't take responsibility for the wrong one
[10:57] <AlanBell> http://loco.ubuntu.com/events/team/568/detail some names on the sign up sheet are not right and not linking to launchpad right
[10:58] <AlanBell> x3n2 and openiduser155 in particular
[10:59] <AlanBell> and kpocius
[11:21] <crazzy> hi
[11:22] <crazzy> hello?
[11:22] <crazzy> hi
[11:22] <serfus> crazzy, hey there
[11:23] <serfus> are you looking for support?
[11:55] <czajkowski> dholbach: know any thing more about that bug, where we have duplicate teams on the LD ?
[11:55] <dholbach> czajkowski, the fix is implemented
[11:55] <dholbach> team admins can "merge teams"
[11:56] <dholbach> they just have to visit the old team's page
[11:56] <dholbach> then click on "merge teams"
[11:56] <czajkowski> dholbach: ahhhh lovely
[11:57] <czajkowski> dholbach: is there a way to add LC to be able to do this, as I can then go spring cleaning and clear up the teams like Washington
[11:57] <dholbach> there probably is a way to do this
[11:57] <czajkowski> dholbach: also when we push for teams to name themselves correctly I can just do it much quicker
[11:57] <dholbach> what do you mean by "naming"?
[11:58] <dholbach> you mean something like ~ubuntu-xyz
[11:58] <dholbach> or "Ubuntu XYZ team"?
[11:58] <dholbach> I'd prefer if we didn't change the former
[11:58] <dholbach> so... "Launchpad ID" or "display name"?
[12:00] <czajkowski> display name I think
[12:02] <dholbach> ok
[12:02] <dholbach> that's something they have to change in LP
[12:03] <czajkowski> hmmm
[12:05] <dholbach> we try to get as much info as possible from LP
[12:05] <dholbach> so we don't have to edit it in 2 places
[12:06] <czajkowski> nods
[14:36] <kemmotar> hi
[14:39] <kemmotar> why ubuntu-ua (Ukrainian LoCo) is not listed in http://loco.ubuntu.com/teams/ ?
[14:44] <daker> kemmotar, maybe you should ask czajkowski
[14:45] <czajkowski> kemmotar: do you have a launchpad page created for the team ?
[14:47] <kemmotar> czajkowski: Yes
[14:48] <czajkowski> kemmotar: can you give me the link please
[14:49] <kemmotar> czajkowski: https://launchpad.net/~ubuntu-ua
[15:02] <czajkowski> hmm I dont have my login links ton see if you're listed under locoteams in lp
[15:02] <czajkowski> dholbach: can you hel;p for a moment |?
[15:02] <czajkowski> please
[15:03] <dholbach> ubuntu-ua is not member of locoteams
[15:04] <dholbach> ah, it's invited
[15:04] <dholbach> https://launchpad.net/~locoteams/+members#invited
[15:04] <dholbach> czajkowski, ^
[15:05] <czajkowski> ahh there we go
[15:05] <czajkowski> and kemmotar is gone
[15:05] <czajkowski> thank you dholbach
[15:06] <dholbach> might be worth mailing him and the other team admins
[15:06] <dholbach> that they should just click on the invitation link on the team page in lp
[15:07] <cjohnston> mornin
[15:07] <czajkowski> nods
[15:38] <mhall119> morning
[15:39] <dholbach> hi mhall119
[15:40] <mhall119> hey dholbach
[15:40] <mhall119> got time for code reviews today?
[15:41] <dholbach> I did a few
[15:41] <mhall119> cool, I'm just getting online
[15:41] <dholbach> :)
[15:41]  * mhall119 loves coffe shop wifi
[15:42] <mhall119> for what it's worth, I tested the local-time patch with old data I have been using for testing for months
[15:44] <dholbach> it's just that we talked so much about it that I thought it'd be good if somebody else had a look over it too
[15:45] <mhall119> okay
[15:49] <mhall119> I'll be on and off all day, so just leave me a message if you need anything
[15:50] <mhall119> btw, I'm working on the loco/global directory combination stuff now, looks like it'll be doable
[15:50] <dholbach> wow, nice
[15:50] <mhall119> just going to require some refactoring
[15:51] <mhall119> I'll put up a demo when I've got something running
[15:51] <mhall119> feels good to be working on this stuff again
[15:52] <dholbach> sweet
[15:52] <dholbach> :-)
[16:40] <Necrox> hello!! everyone
[16:40] <Necrox> i need help with a few things
[16:57] <czajkowski> !lococouncil
[16:57] <ubot4> lococouncil is The Loco Council is itnet7, czajkowski, paultag, huats, leogg, popey - they are there to help, just ask! :) You can send them an email at<EMAIL_ADDRESS>[16:58] <paultag> czajkowski, Howdy :)
[16:58] <czajkowski> move along nothing to see
[16:58] <czajkowski> :p
[16:58]  * paultag hugs czajkowski
[16:58]  * paultag walks away :)
[16:58] <czajkowski> either that or I poke you but I already agreed a week of no poking
[16:58] <czajkowski> :p
[16:59]  * paultag chuckles silently to himself in the corner
[16:59]  * czajkowski pokes paultag behave you
[18:37] <AlanBell> I have names like openiduser155 attending an event in loco directory. Is that something broken in their profile or do I need to raise a bug? http://loco.ubuntu.com/events/team/568/detail
[18:38] <mhall119> AlanBell: we already have bugs for it, and fixes to django-openid-auth waiting to be reviewed by those developers
[18:38] <AlanBell> great, thanks
[18:38] <mhall119> speak of which, dholbach or Daviey, could you guys ping them about it?
[18:39] <dholbach> in a call
[18:39] <mhall119> ok
[18:39] <mhall119> we can always just ship our own local copy, but I'd rather not get into maintaining a separate branch of it if we don't have to
[19:06] <Daviey> mhall119: *sigh*.... i would have thought that would have landed by now
[19:06] <Daviey> mhall119: Do you want to try adding a "ping" to the merge proposal... if that doesn't help, i'll chase the maintainer
[19:15] <mhall119> Daviey: done
[19:18] <Daviey> mhall119: lemme know if there is (or isn't) progress by this time tomorrow
[19:18] <mhall119> I'm checking to see what activity there is on the project at all
[19:18] <mhall119> looks like nothing's made it into trunk since august 10th
[19:18] <Daviey> :(
[19:19] <Daviey> it's not a rapid project, to be fair
[19:19] <Daviey> it's not like you expect constant inovation :)
[19:19] <mhall119> I'm just wondering if jamesh is still actively maintaining it or not
[19:21] <mhall119> hmm, looks like it's going to require Django 1.2 now too
[19:21] <mhall119> but I think both LD and summit are still on 1.1