[15:00] <barry> #startmeeting
[15:00] <MootBot> Meeting started at 09:00. The chair is barry.
[15:00] <barry> hello everyone and welcome to this week's ameu reviewer's meeting.  who's here today?
[15:00] <danilos> me
[15:00] <EdwinGrubbs> me
[15:00] <mars> me
[15:01] <bigjools> me
[15:01] <bac> me
[15:02] <barry> jtv: hi!
[15:02] <jtv> hi barry!
[15:02] <barry> adeuring: ping
[15:02] <barry> allenap: ping?
[15:02] <adeuring> whoops, me
[15:02] <salgado> me!
[15:02] <barry> BjornT: ping
[15:02] <gary_poster> me
[15:02] <barry> cprov: ping
[15:02] <BjornT> me
[15:03] <barry> gmb: ping
[15:03] <barry> intellectronica: ping
[15:03] <gmb> me
[15:03] <barry> rockstar: ping
[15:03] <intellectronica> me
[15:03] <jtv> me
[15:03] <barry> sinzui: ping
[15:03] <sinzui> hi barry
[15:03] <flacoste> me
[15:04] <barry> hi everyone
[15:04] <sinzui> me
[15:04] <barry> [TOPIC] agenda
[15:04] <MootBot> New Topic:  agenda
[15:04] <barry>  * Roll call
[15:04] <barry>  * asiapac meeting time change
[15:04] <barry>  * deprecate zapi and ztapi in favor of zope.component APIs, gary
[15:04] <barry>  * Action items
[15:04] <barry>  * Mentoring update
[15:04] <barry>  * Peanut gallery (anything not on the agenda)
[15:05] <barry> [TOPIC]  * asiapac meeting time change
[15:05] <MootBot> New Topic:   * asiapac meeting time change
[15:05] <barry> so just a quick note that we've changed the date and time of the asiapac meeting.  10pm my time was just too difficult for me to remember, so now it's wednesdays utc 2300
[15:06] <barry> which i think also makes it easier to communicate between the two review teams
[15:06] <barry> just in case y'all wanted to drop by :)
[15:06] <danilos> in case I have no idea what to do at midnight, I might ;)
[15:06] <barry> :)
[15:06] <barry> [TOPIC]  * deprecate zapi and ztapi in favor of zope.component APIs, gary
[15:06] <MootBot> New Topic:   * deprecate zapi and ztapi in favor of zope.component APIs, gary
[15:07] <barry> gary_poster: the floor is yours
[15:07] <flacoste> for US fols, that's nice, we'll be able to drop by
[15:07] <gary_poster> :-) k
[15:07] <barry> flacoste: yep.  we don't have jamesh's tz to worry about any more :)
[15:07] <gary_poster> Zope deprecated zapi and ztapi quite awhile ago
[15:07] <gary_poster> Jim Fulton significantly refactored the zope.component API so that it was easier to use it directly
[15:08] <gary_poster> these APIs are more parallel (register/unregister for instance for adapters and utilities)
[15:08] <rockstar> me
[15:08] <gary_poster> and also don't hide how views work as adapters, for instance, behind what I believe to be an unnecessary and ultimately confusing veil
[15:09] <gary_poster> I think we (probably me) should come up with a cheat sheet on "if you were doing this, try doing this"
[15:09] <gary_poster> but Zope is already leaving that stuff behind, and I think we should too
[15:09] <barry> gary_poster: what kinds of things do we commonly do now that would be better off w/o zapi?
[15:09] <sinzui> I only see zapi and ztapi in old code. I have never reviewed code that added it.
[15:09] <barry> gary_poster: % fc lib/canonical zapi | wc -l
[15:09] <barry> 23
[15:10] <gary_poster> sinzui: so, do you mean, it is already effectively deprecated?
[15:10] <sinzui> gary_poster: I think so
[15:10] <barry> sinzui: 23 hits on zapi, 35 hits on ztapi
[15:11] <barry> which doesn't seem like much
[15:11] <gary_poster> barry: zapi should be completely unnecessary.  same with ztapi.  It's just cruft, keeping people from understanding the actual use of the component code, for no particular win
[15:11] <gary_poster> ok, so maybe simple proposal:
[15:11] <sinzui> gary_poster: I only know what Phillip wrote in his book. I think flacoste/SteveA have driven us from using it in the past two years.
[15:12] <gary_poster> 1) Someone (I?) does (do) a branch that rips out the remainder
[15:12] <barry> maybe the newest code is in l/c/lazr/rest/tales.py?
[15:12] <gary_poster> 2) that policy is official
[15:12] <allenap> me
[15:12] <gary_poster> the reason that this came up is that I saw leonardr use it
[15:12] <barry> +1, +1
[15:12] <gary_poster> ok
[15:13] <gary_poster> at least that was non-controversial ;-)
[15:13] <barry> gary_poster: maybe start with lib/canonical/lazr?
[15:13] <gary_poster> yeah
[15:13] <jtv> gary_poster: it was the "(I?)" part that sold us
[15:13] <gary_poster> lol :-)
[15:14] <gary_poster> k, done, unless someone else wants to say something
[15:14] <barry> jtv: are you saying that gary_poster is our jerry maguire?
[15:14] <barry> gary_poster: thanks
[15:14] <gary_poster> :-)
[15:14] <barry> [TOPIC]  * Action items
[15:14] <MootBot> New Topic:   * Action items
[15:14] <barry>  * abentley to email ml and gustavo with suggestions for improving storm
[15:14] <barry> abentley: just in time! :)
[15:14] <abentley> barry: Done.
[15:15] <jtv> barry: EPOPCULTREF
[15:15] <abentley> barry: Response was not very positive.
[15:15] <gary_poster> heh
[15:15] <barry> abentley: yeah
[15:15] <gary_poster> conversation with stub seemed potentially fruitful though
[15:15] <abentley> In fact, he said if we like the SQLObject api, we should use the shim
[15:17] <flacoste> well
[15:17] <barry> what do you guys think?  personally, i prefer both native storm query syntax and native storm class definitions
[15:17] <flacoste> that has some drawbacks
[15:17] <flacoste> and I don't think the shim is what we want to use
[15:17] <flacoste> native storm query: yes
[15:17] <flacoste> native storm class defs: not sure at all
[15:17] <abentley> I think stores should be optional.
[15:17] <abentley> Most of the time, we don't want or need them.
[15:18] <flacoste> the problem with the shim is that the results objects are incompatible
[15:18] <bigjools> as I found to my cost
[15:19] <abentley> Okay, so if we make our own base class, would that be acceptable?
[15:19] <barry> flacoste: what would you propose instead for class defs?  base class/metaclass?
[15:20] <flacoste> base class is probably best
[15:20] <barry> abentley: not outside the realm of possibility
[15:20] <flacoste> as metaclass usually makes people's brain explode
[15:20] <barry> flacoste: indeed
[15:20] <barry> flacoste: how would that change the attribute definition syntax?
[15:21] <flacoste> i think we might need a metaclass for that, i don't know
[15:21] <flacoste> and maybe the native storm syntax isn't that bad
[15:21] <barry> flacoste: i think we would, but i guess my question is: what would you do differently?
[15:21] <flacoste> it's just that I agree with abentley that the ID stuff is kind of boring
[15:22] <barry> true
[15:22] <flacoste> well, the attribute names for instance
[15:22] <flacoste> field_id instead of fieldID
[15:22] <bigjools> the only real problem with Storm syntax for me is importing a gazillion content classes
[15:23] <allenap> bigjools: That does have the advantage that things break hard when classes are changed.
[15:23] <allenap> and early.
[15:23] <barry> is anybody motivated enough to try an experiment here?
[15:23] <abentley> bigjools: Not seeing the connection.
[15:24] <bigjools> abentley: if you use Python expressions for the query joins ...
[15:24] <abentley> bigjools: Is that compared to raw SQL with SQLObject?
[15:25] <bigjools> yes. if you write a string in SQL then you don't have the import pain, but then Storm can't work out the FROM tables
[15:25] <jtv> barry: what experiment did you have in mind?
[15:26] <flacoste> barry: well, i think abentley's gripes are good, so if he's willing to try to cook up a base class that suits him, that would be a good start
[15:26] <bigjools> allenap: that's a great point
[15:26] <abentley> flacoste: Sure, I'm happy to start with that.  Metaclass foo later.
[15:26] <barry> jtv: a base class/metaclass to make various common boring or painful things easier
[15:27] <barry> abentley: cool.  i know there's an experiments page somewhere but my firefox is misbehaving right now
[15:28] <barry> [ACTION] abentley to experiment with a base class to ease the pain and boredom with storm
[15:28] <MootBot> ACTION received:  abentley to experiment with a base class to ease the pain and boredom with storm
[15:29] <barry>  * flacoste to take dead zone reviews issue to ml
[15:29] <flacoste> done
[15:29] <flacoste> not sure of the resolution there
[15:29] <flacoste> though
[15:29] <barry> flacoste: me neither
[15:29] <barry> jtv: what do you think about that thread?
[15:30] <barry> jtv: i think you and stub get weighted more heavily here as you're the most tz challenged
[15:31]  * barry taps the mic and asks "is this thing still on?"
[15:31] <jtv> barry: I do agree, just slightly concerned about having yet more ways to write a database class
[15:31] <jtv> barry: sorry, hard to type at this temperature
[15:31] <rockstar> jtv, +1
[15:31] <barry> jtv: TOOWTDI
[15:31] <barry> jtv: and you're dutch so it should be obvious to you
[15:31] <gary_poster> :-)
[15:32] <barry> jtv: sorry, i meant the dead zone review thread
[15:32] <jtv> barry: ahhh
[15:33] <jtv> barry: I thought we already were discussing that on the ml
[15:33]  * jtv reads back
[15:33] <barry> jtv: we are, just wanted to give you a higher bandwidth channel.  but it's okay, we can continue on the ml
[15:34] <jtv> barry: yes, sorry, having that one line added in the middle changed the meaning of my backlog
[15:34] <jtv> I think we agreed that cover letters are good, and possibly better than asking a reviewer personally
[15:35] <barry> cover letters + mp + (maybe?) irc topic?
[15:35] <jtv> barry: ah yes, the topic line, I liked that
[15:36] <barry> jtv: cool.  let's see if we can make that work. we can always try something else if need be
[15:36] <jtv> maybe a "candidate queue"?
[15:36] <jtv> after all, the "queue" is what an OCR has accepted
[15:36] <jtv> or a "review backlog"
[15:37] <barry> jtv: backlog: xxx in the topic?
[15:37] <jtv> barry: looks lovely
[15:37] <danilos> we can have two queues, one for on call, another for backlog, with OCRs reviewing alternately one from each
[15:37] <barry> danilos: +1
[15:37] <jtv> oh, practical problem: how does the next reviewer know which *branch*?  that's too long to record in the topic
[15:38] <barry> jtv: give an mp #?
[15:38] <danilos> how about just using links to bugs or MPs?
[15:38] <jtv> Yeah, nick:mp# would do it for me
[15:39] <barry> danilos: i think that makes the topic too long
[15:39] <abentley> hmm: The MP ids are unique.  Maybe we should provide a direct link to them.
[15:39] <danilos> abentley: yeah, that would be an improvement (something like we have for bugs)
[15:40] <barry> abentley: do you mean, have the bot recognize "mp 1234"?
[15:40] <danilos> barry: I meant only bug ids (and bugs will point to branches, which will point to mps :)
[15:40] <barry> danilos: ah yes, fair enough
[15:40] <danilos> I'd prefer a bookmarklet https://code.launchpad.net/+merge-proposal/%s :)
[15:41] <jtv> danilos: good idea, but blueprint names get longer
[15:41] <danilos> jtv: they are also not linked to branches afaik
[15:41] <abentley> barry: No, I meant to be able to put code.launchpad.net/mp/1234 as a url.
[15:41] <barry> abentley, jtv, danilos let's see if we can hash out the details on the ml
[15:41] <jtv> danilos: good point :)
[15:42] <barry> only a couple of minutes left, so...
[15:42] <barry>  * gary to email list about RENormalizing test, investigate alternate inline spellings
[15:42] <gary_poster> done.  See how to do it.  doctest not easily extensible for this, so will need to hack.
[15:42] <barry> i think that one's done
[15:42] <barry> gary_poster: thanks
[15:43] <barry>  * barry to add `pretty()` functions to reviewers docs
[15:43] <barry> i suck, not done
[15:43] <barry>  * flacoste to work on API reviewer cheat sheet
[15:43] <flacoste> i suck, not done
[15:43] <barry> [TOPIC] peanut gallery
[15:43] <MootBot> New Topic:  peanut gallery
[15:43] <danilos> I'd like to raise one issue here
[15:43] <barry> does anybody have anything not on the agenda?
[15:43] <barry> danilos: go4it
[15:43] <flacoste> if it's not done next week, i change my name to flacoste_hoover
[15:43] <danilos> the lightness of our reviews makes them not be that useful anymore as a learning tool
[15:43] <barry> flacoste: :)
[15:44] <danilos> we need to reiterate some points even if they are not necessarily what we expect developer to do
[15:44] <flacoste> what do you mean?
[15:44] <flacoste> or can you give an example?
[15:44] <danilos> eg. concrete example I have: we should mention LaunchpadForm for any form which is not using it
[15:44] <flacoste> good point
[15:44] <danilos> Henning was not aware of LaunchpadForm and hacked around even though he modified quite a few forms before
[15:45] <danilos> just a question for reviewers to ask: "why is this not using this and that infrastructure we have"
[15:46] <barry> danilos: +1
[15:46] <gmb> I didn't realise that our reviews were that shallow.
[15:46]  * bigjools fears for future Soyuz reviews
[15:47] <gmb> Just last week EdwinGrubbs pointed out a much easier way for me to do something that I'd spent ages hacking around with.
[15:47] <danilos> (even if reviewer knows the answer, we should help developers get to learn more about existing infrastructure, since there's so much of it)
[15:47] <bigjools> we need an infrastructure cheat sheet
[15:47] <gmb> bigjools: The only way you can have a shallow soyuz review is if the person doing the review is dead.
[15:47] <al-maisan> :)
[15:47] <gary_poster> :-)
[15:47] <flacoste> lol
[15:47] <bigjools> gmb: that can be arranged!
[15:47] <danilos> bigjools: the idea is not to force people to switch to new infrastructure, just to be aware of it, and understand why it's not being used
[15:48] <bigjools> danilos: that's fine - I just know that we have lots of, er, legacy code shall we say, done before a lot of the infrastructure was in place
[15:48] <bac> it works the other way too.  yesterday i saw something cool sinzui was doing in a doctest i was reviewing and adopted it.
[15:48] <danilos> bac: indeed
[15:49] <bigjools> bac: yes, that's a great reason to be a reviewer
[15:49] <danilos> anyway, we're over time already, and I think I am done
[15:49] <barry> bac: we should find a way to share those insights across the team!
[15:49] <barry> danilos: thanks. and apologies for going over
[15:49]  * sinzui just wanted the code to be readible
[15:49] <danilos> barry: we've tried so far to do that using wikis and mailing lists, but it doesn't really work out
[15:49] <mars> danilos, how about cleaning up technical debt as a learning exercise, rather than reviewing or using a cheat sheet?
[15:49]  * barry will eagerly await bac's email describing this insight :)
[15:49] <bigjools> I would like a cheat sheet, personally
[15:50] <mars> that's how I started - fixing callsites, submitting 2000-line patches...
[15:50] <jtv> mars: it's not always stuff you'd easily recognize as tech debt
[15:50] <gary_poster> cheat sheets get awfully big
[15:50] <bigjools> then the info is shared
[15:50] <gary_poster> we already have some
[15:50] <danilos> gary_poster: only if you want to cheat in everything you do :)
[15:50] <gary_poster> that are really really big
[15:50] <gary_poster> :-)
[15:50] <bigjools> gary_poster: they can't get bigger than the doctests we have though :)
[15:50] <gary_poster> heh
[15:50] <barry> :)
[15:50] <barry> anyway.  let's break for today
[15:50] <barry> #endmeeting
[15:50] <MootBot> Meeting finished at 09:50.
[15:50] <flacoste> thanks barry
[15:51] <barry> thanks everyone!
[15:51] <bigjools> thanks barry
[15:51] <jtv> thanks barry
[15:51] <gary_poster> thanks, bye
[15:51] <danilos> thanks all
[23:01] <barry> #startmeeting
[23:01] <MootBot> Meeting started at 17:01. The chair is barry.
[23:01] <MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
[23:01] <barry> hello and welcome to the first of our newly scheduled asiapac reviewers meetings.  who's here today?
[23:01]  * barry pings jml thumper and mwhudson
[23:01] <mwhudson> hello
[23:02]  * thumper pongs
[23:02] <thumper> :)
[23:02] <jml> barry: hi
[23:02] <barry> yay!  how's it going guys?
[23:02] <thumper> busy
[23:02] <jml> yeah, very busy
[23:03] <thumper> too many things to do at once
[23:03] <barry> mwhudson: very very busy?
[23:03] <jml> people keep finding bugs in our software
[23:03] <thumper> oh, and I have a dentist appt in 1 hour
[23:03] <mwhudson> barry: you guessed it!
[23:03] <thumper> which I need to walk to
[23:03] <barry> well then, we'll make this quick!
[23:03] <barry> [TOPIC] agenda
[23:03] <MootBot> New Topic:  agenda
[23:03] <barry> * Roll call
[23:03] <barry>  * asiapac meeting time change
[23:03] <barry>  * deprecate zapi and ztapi in favor of zope.component APIs, gary
[23:03] <barry>  * Action items
[23:03] <barry>  * Mentoring update
[23:03] <barry>  * Peanut gallery (anything not on the agenda)
[23:04] <barry> that's basically copied from the ameu meeting this morning, which i have not had time to write up yet
[23:04] <thumper> ok
[23:04] <mwhudson> well the first one seems to have worked
[23:04] <barry> indeed!
[23:04] <barry> [TOPIC]  * deprecate zapi and ztapi in favor of zope.component APIs, gary
[23:04] <MootBot> New Topic:   * deprecate zapi and ztapi in favor of zope.component APIs, gary
[23:04] <barry> let me see if i can channel gary_poster
[23:05] <thumper> do anyone outside foundations care?
[23:05] <jml> barry_imposter
[23:05] <thumper> haha
[23:05] <barry> thumper: probably not.  there's only about 70 hits for both in our code base
[23:05] <mwhudson> i've used ztapi in a test i think once
[23:05] <barry> and most of those are in very old code
[23:05] <mwhudson> i won't do it again :)
[23:05] <mwhudson> next
[23:06] <barry> mwhudson: yeah, you better not.  gary_poster is a big guy
[23:06] <barry> [TOPIC]  * Action items
[23:06] <MootBot> New Topic:   * Action items
[23:06] <mwhudson> i can't imagine him as a brawler though some how
[23:06] <barry> :)
[23:06] <barry>  * abentley to email ml and gustavo with suggestions for improving storm
[23:06] <jml> I think that's been done for some time :)
[23:07] <barry> abentley: right.  though today we talked about an experiment that abentley will conduct to see if he can create a base class that makes some annoyances simpler
[23:07] <barry> we still do not want to use the sqlobject shim
[23:07] <jml> barry: sure.
[23:07] <barry> we were generally agreed that native storm class defs and queries are fine with us
[23:08] <jml> ok.
[23:08] <barry> though foo_id is boring
[23:08] <barry> and needing to specify the store is boring
[23:08] <barry> we'll see what he comes up with
[23:08] <thumper> LPStorm class?
[23:08] <jml> it's also complicated :)
[23:08] <mwhudson> do you have to have the foo_id as a separate definition?
[23:08] <jml> barry: so I guess this is out-of-scope for reviewer meetings for the moment?
[23:08] <barry> thumper: something like that, tho i suspect a metaclass may be necessary
[23:08] <thumper> mwhudson: I believe so
[23:08] <barry> mwhudson: yep
[23:09] <thumper> I've seen both field_id and fieldID
[23:09] <thumper> do we have a standard?
[23:09] <barry> mwhudson: foo_id = Int(primary=True); foo = Reference(foo_id, Foo.id)
[23:09] <barry> thumper: we do not
[23:09]  * barry prefers and uses foo_id
[23:09]  * thumper votes for field_id
[23:09] <barry> thumper: rock on
[23:09] <mwhudson> barry: wouldn't foo = Reference(Int(primary=True), Foo.id) work?
[23:09] <barry> mwhudson: interesting!  dunno
[23:09] <thumper> barry: can you add an agenda item to add it for the next reviewer meeting
[23:10] <mwhudson> if it does, i think we can write a convenience class....
[23:10] <barry> [ACTION] barry will add foo_id vs fooID to next reviewers meeting
[23:10] <MootBot> ACTION received:  barry will add foo_id vs fooID to next reviewers meeting
[23:10] <mwhudson> FKeyIDRef or something
[23:10] <thumper> mwhudson: sometimes you need to do field.foo_id.is_in([1,2,3])
[23:10] <jml> mwhudson: best. name. evar. :P
[23:10] <mwhudson> ah ok
[23:10] <thumper> mwhudson: a bit hard to do without a defined foo_id
[23:10] <mwhudson> i should mention this on the list i guess
[23:10] <barry> mwhudson: please do
[23:11] <barry> next?
[23:11] <thumper> ya
[23:11] <thumper> yarp
[23:11] <barry>  * flacoste to take dead zone reviews issue to ml
[23:11] <barry> he did this
[23:11] <barry> jtv was at our meeting and i think we've decided on mp + cover + an irc cue
[23:12] <barry> basically jtv and stub would add a cue to the, er queue to let ocrs know that thye have branches they'd like reviewed
[23:12] <barry> or something like that.  i don't remember the details, but i'll write it up when i go through the minutes
[23:13] <thumper> I've also cleaned up the claiming a team review
[23:13] <thumper> so we should have less pending team review
[23:13] <thumper> s
[23:13] <thumper> when someone has done one
[23:13] <mwhudson> i guess in time, jtv and stub will end up reviewing each other's branches a lot
[23:13] <barry> yep, stubs a mentat now
[23:13] <jml> thumper: the remaining issue is that it's still hard to see which branches need review.
[23:13] <thumper> action for me: make sure a default reviewer is added through bzr send if none specified
[23:13]  * thumper thinks
[23:14] <thumper> if we have a bug for this
[23:14] <barry> thumper: yes please.  and btw, i used bzr send for the first time yesterday. awesome sauce
[23:14] <thumper> increase its priority
[23:14] <jml> thumper: partly because the mp status isn't always updated.
[23:14] <thumper> barry: just wait for the changes with jml is reviewing
[23:14] <thumper> jml: I've got some ideas
[23:14] <thumper> lets make the views better
[23:15] <jml> thumper: partly because there aren't clear mp statuses for "reviewed, waiting on reply"
[23:15]  * barry *can't* wait :)
[23:15] <thumper> jml: lets make one
[23:15] <thumper> jml: we use a decorated class now anyway
[23:15] <jml> thumper: let's talk about it after :)
[23:15] <thumper> jml: let's just invent a new status column
[23:15]  * thumper nods
[23:15] <barry> sounds good.  thanks guys
[23:16] <barry>  * gary to email list about RENormalizing test, investigate alternate inline spellings
[23:16] <barry> he did this
[23:16] <barry> doctest is hard to extend
[23:16] <barry> 'nuff said
[23:16]  * jml coughs politely
[23:16]  * mwhudson is tempted to say "two wrongs don't make a right"
[23:16] <barry> :)
[23:17] <barry> both flacoste and i suck at our two action items so i won't even mention them
[23:17] <mwhudson> if you can't specify this close-to-inline, it's a terrible terrible idea
[23:17] <jml> barry: you probably should :)
[23:17] <mwhudson> otherwise, it's just terrible, perhaps
[23:17] <barry>  * barry to add `pretty()` functions to reviewers docs
[23:17] <barry>  * flacoste to work on API reviewer cheat sheet
[23:18] <jml> these are both good ideas.
[23:18] <barry> mwhudson: we all agree on that!
[23:18] <mwhudson> good
[23:18] <barry> jml: yep, we should suck less and do more
[23:18] <barry> anyway, that's about it for my list.  do you guys have anything y'all want to talk about?
[23:19] <thumper> I'm working my way through the code-review bugs
[23:19] <thumper> if people have a strong opinion about something
[23:20] <thumper> they should contact me directly
[23:20] <jml> barry: I have a couple of things
[23:20] <thumper> otherwise they'll be fixed in thumper-priority
[23:20] <mwhudson> i guess i could say the same about loggerhead/codebrowse
[23:20] <barry> thumper: isn't that thumpertime?
[23:20] <barry> thumper: thanks
[23:20] <barry> jml: go ahead
[23:20] <thumper> barry: something like that :)
[23:20] <jml> first, the reviewer checklist
[23:21] <jml> 1. it's getting kind of long
[23:21] <jml> 2, it's hard to find
[23:21] <jml> the first one is a someday/maybe thing
[23:22] <jml> i.e. it doesn't matter too much, but it would be nice if it were shorter and more usable
[23:22] <jml> but I actually don't know where to find the latest version :)
[23:22] <barry> agreed, agreed. it's on My List to garden it and move it to dev.lp.net
[23:22] <jml> cool.
[23:22] <jml> second, mentoring
[23:23] <jml> I'm mentoring stub, and I don't feel I'm doing a particularly good job of it.
[23:23] <barry> jml: because of the tz?
[23:23] <jml> barry: partly
[23:23] <jml> barry: in more than one way, actually. there's not a huge deal of overlap, for a start.
[23:24] <jml> barry: but also my OCR day is busiest in the morning, as people from the Americas submit things on their Thursday evening.
[23:24] <barry> jml: and you overlap with stub in the morning?
[23:25] <jml> my afternoon.
[23:25] <thumper> stub's morning
[23:25] <barry> jml: i can chat with flacoste and/or stub if you want to see if we can line someone else up
[23:26] <jml> also, are there any docs on mentoring on the wiki?
[23:26] <barry> jml: some i think, but probably not much
[23:26] <jml> barry: that might be a good idea. let's leave it for another week though & see how it goes.
[23:26] <mwhudson> overlapping in the mentees morning isn't really the right end of things, i guess
[23:26] <barry> jml: sounds good
[23:27] <jml> that's it from me.
[23:27] <barry> that tz is just a challenge all around unfortunately
[23:27] <barry> cool, thanks jml.  anything else guys?
[23:27] <thumper> nope
[23:28] <mwhudson> nope
[23:28] <barry> guess we're done!
[23:28] <barry> #endmeeting
[23:28] <MootBot> Meeting finished at 17:28.
[23:28] <thumper> yay
[23:28] <mwhudson> thanks bazza
[23:28] <barry> thanks.  btw, i really like this meeting time
[23:28] <jml> barry: ya :)
[23:28] <jml> me too.
[23:28] <barry> great! see y'all back at the ranch


[18:52] <anotheral> is this the canonical channel for cloud-init?
[18:53] <utlemming> anotheral: yup
[18:53] <anotheral> i was just wondering if there's any documentation of the order of operations that happens in a cloud-config yaml?
[18:53] <anotheral> i have some stuff that needs to happen before some other stuff :)
[18:54] <utlemming> anotheral: /etc/cloud.cfg controls what happens when
[18:54] <anotheral> beautiful
[18:54] <anotheral> ta
[18:54] <utlemming> anotheral: if you want to change that in user-data, you can do that too
[18:54] <utlemming> anotheral: i.e. put #cloud-config into user-data
[18:54] <anotheral> so the order of items in that cloud.cfg file is the order of execution?
[18:54] <anotheral> not the order in my yaml
[18:55] <utlemming> anotheral: yes
[18:56] <anotheral> ah, looks like write_files isn't even in 12.04 cloud-init
[18:56] <utlemming> anotheral: if you want to change that on boot, then define cloud_init_modules or cloud_config_modules in your #cloud-config user-data
[18:56] <anotheral> oh interesting - that's good to know!
[18:56] <anotheral> thanks folk!  LOOOOVE your product
[20:52] <harlowja> yw!
[22:48] <anotheral> if you don't mind, i do have one more question
[22:49] <anotheral> i'm trying to create some files, but ubuntu 12.04 doesn't have the write_file capability
[22:49] <anotheral> is there a decent workaround anyone is aware of?
[23:26] <harlowja> anotheral send in a bash script that writes out the files
[23:27] <harlowja> using bash syntax
[23:27] <anotheral> ah right


[20:44] <ibeardslee> morning
[20:52] <ajmitch> morning
[21:58] <snail> morning
[21:58] <hads> morning
[21:59] <hads> .win 2
[21:59] <hads> D'oh
[22:01] <Atamira> morning
[22:01] <hads> Have a bung HDD in a server, no SMART flags but it's bringing everything to a crawl.
[22:02] <snail> we have a school of architecture. the theses students seem to be using our 2GB max theses file size as a target :(
[22:14] <thumper> morning
[22:52] <ajmitch> good to see there's still some progress on the UFB project
[23:00] <mwhudson> morning


[15:02] <ailo> holstein: I'm a little curious why you always seem to want to make a point to new users that they might not need low latency capability.
[15:02] <ailo> I'd say it's only a small amount of musicians who'd not need it
[15:02] <smartboyhw> ailo: Maybe that he just likes the generic one:)
[15:03] <ailo> smartboyhw: Please. I wasn't asking you. And that's not why.
[15:03] <smartboyhw> :)
[15:04] <ailo> holstein: At least at some point, you need it
[15:06] <ailo> holstein: We can't help that that problem is as complicated as it is.
[15:06] <ailo> holstein: The easy answer to people is always, install Ubuntu Studio, right?
[15:07] <ailo> holstein: even at jack default settings, you might get xruns, if you're not running jack in realtime mode
[15:08] <ailo> I mean, qjackctl default settings
[15:08] <ailo> Which is almost the same thing
[15:09] <len-dt> ailo, remember he also suggests jack is not always needed either.
[15:09] <ailo> I don't believe that to be true for musicians, who will be using software that depend on jack
[15:09] <len-dt> Yes.
[15:10] <smartboyhw> len-dt: The main problems in the Ubuntu Studio section in Ubuntu Forums mainly involve Jack, that shows people using Ubuntu Studio do need Jack.
[15:11] <len-dt> He has spent a lot of time helping people though and I think has found people who want to record some stereo sounds and think they need something really special rather than pulse and audacity.
[15:13] <len-dt> I see that when he is talking to people on the forum who have trouble, he is trying to find out what they are trying to do. If they are doing something that requires special SW.
[15:14] <len-dt> Trying to find the right tools to use match.
[15:14] <len-dt> look at what he uses personally... it is low lat or RT.
[15:16] <ailo> It's a little hard to double guess what people are after. If you don't ask them about it first.
[15:16] <smartboyhw> Actually, then, a question: Is it possible for me NOW to install the generic kernel?
[15:16] <len-dt> yup
[15:16] <ailo> But, if someone says "full music production", you kind of anticipate that this person will be using jack software, and requires a reliable platform
[15:17] <len-dt> yes to that too
[15:17] <smartboyhw> Hmm, let me go and install a generic kernel and see if there's any diff:)
[15:18] <ailo> holstein: I think you've done an awesome effort helping people out in general. I've just seen this tendency from you lately, that I guess is because of what len said - that often people are looking to only do one thing, which they don't need jack for
[15:19] <len-dt> however, if the person's understanding of production is that they have never done any... having to learn ardour and jack and all the stuff that goes with it be fore they record _anything_ is probably not the best starting point.
[15:20] <ailo> Good point
[15:20] <len-dt> maybe recording the bands live gigs is a better start.... pulse and audacity
[15:20] <len-dt> stereo off the board.
[15:21] <ailo> I would still recommend for someone to learn the tools they are going to use, nevertheless
[15:21] <ailo> If you need multitrack recording/mixing, you need to learn how to use a DAW
[15:21] <len-dt> yes
[15:21] <ailo> jack is a separate issue though
[15:21] <ailo> You can use Ardour with alsa
[15:22] <ailo> But turning jack on is not that complicated after all
[15:22] <ailo> You can even let Ardour do it
[15:22] <smartboyhw> ailo: I do agree, strangely those guys in Ubuntu Forums seemed perplexed...
[15:22] <ailo> smartboyhw: I don't think turning jack on is the big problem
[15:23] <smartboyhw> ailo: I said I don't think it is an problem, I said those guys in Ubuntu Forums has...
[15:23] <len-dt> ailo, routing seems to be an issue for some though.
[15:24] <ailo> len-dt: To Ardour channels, or in general?
[15:24] <len-dt> For those of use who have played with recording to tape, jack is wonderful
[15:25] <ailo> len-dt: I mean, if you're using routing with jack for other things, then there's no reason not to learn how that works
[15:25] <len-dt> lots of people just getting into audio now are from the it just works set.
[15:25] <smartboyhw> Hmm, a LOL thing: When I look at https://wiki.ubuntu.com/UbuntuStudio/Artwork/OfficialPrecise it's still not yet filled in. Real weird since it's already 12.04.1:)
[15:26] <ailo> I lied about ardour starting jack
[15:26] <ailo> Maybe A3. Some software will do it
[15:26] <ailo> smartboyhw: Maybe you can do it?
[15:26] <ailo> smartboyhw: How's your documentation work coming along?
[15:27] <smartboyhw> ailo: What? I am not reponsible for artwork. On the documentation, I'm better free after coming Wednesday, and I will hand it in around Sat or Sun:)
[15:27] <len-dt> Of the linux music I have heard probably 75% of it is totally electronic... all synth. Many people seem to be looking for something more like LMMS
[15:28] <ailo> smartboyhw: Ḯ'm just making a point that this team is not big, and LOLing at unfinished work is not going to help finish it
[15:28] <smartboyhw> Uh oh.
[15:28] <ailo> smartboyhw: So, if you feel something needs to be done, and no one's doing it, you can always pick it up yourself
[15:28] <smartboyhw> ailo: But where do I find the artwork?
[15:28] <ailo> smartboyhw: Don't ask me. I don't care about that page
[15:28] <knome> smartboyhw, if there is no artwork in the wiki, there is no artwork at all
[15:29] <smartboyhw> Uh oh.
[15:29] <knome> feel free to contribute, as ailo said.
[15:29] <ailo> smartboyhw: Also, I'm reorganizing the wiki later this fall
[15:29] <smartboyhw> ailo: Really? How?
[15:30] <ailo> smartboyhw: It's in the blueprints
[15:30] <smartboyhw> Uh oh, give me the blueprint link again:)
[15:30] <knome> smartboyhw, can you find something yourself?
[15:30] <ailo> smartboyhw: https://blueprints.launchpad.net/ubuntu/+spec/topic-quantal-flavor-ubuntustudio
[15:30] <smartboyhw> knome: Sorry.
[15:31] <knome> smartboyhw, it's not helpful to ask others to fetch you everything and waste their time
[15:32] <smartboyhw> knome: Again, I'm sorry. ailo: OK, I read the blueprint about documentation, but then there's really a lot of TODOs...
[15:33] <len-dt> smartboyhw, yes
[15:33] <knome> smartboyhw, that's how things are when somebody hasn't seriously started working on them.
[15:33] <len-dt> pick one with no name beside it that interests you and go for it
[15:34] <ailo> He's already working on one thing
[15:34] <smartboyhw> len-dt: Almost all items has names:)
[15:34] <smartboyhw> Let me write back my publishing documentation down:)
[15:37] <len-dt> smartboyhw, in your testing of 12.10 ISOs have you noticed scroll bars on the install slideshow?
[15:37] <smartboyhw> len-dt: Yep, new thing in ubiquity, I think
[15:38] <len-dt> they showed up in 12.04, but I personally have not seen scroll bars on any test install I have done.
[15:39] <smartboyhw> Uh oh.
[15:39] <len-dt> ^^^  for about a month or two
[15:39] <knome> len-dt, i saw them when i installed xubuntu on my laptop
[15:39] <knome> len-dt, i'm going to tweak the xubuntu slideshow for Q though
[15:39] <len-dt> this is a good thingg
[15:39] <knome> len-dt, but still don't know what causes that...
[15:39] <smartboyhw> I saw them in Ubuntu Desktop too.
[15:40] <knome> len-dt, maybe cut the images to exact sizes, but i'm not sure how that relates, because xubuntu had them too even if the images were cut
[15:40] <len-dt> I was thinking that upstream had fixed it because I haven't seen it for a while.
[15:40] <len-dt> even testing 12.04.1, but I do get it on the original 12.04
[15:41] <len-dt> when installing from live... looking at the main menu made them vanish
[15:42] <ailo> I removed myself from some of the tasks. Don't even remember putting myself on them
[15:42] <len-dt> knome, when was the last date you installed a xubuntu ISO
[15:43] <knome> len-dt, it's not too long ago
[15:43] <knome> len-dt, but the last time i saw them was when installing my laptop, start of this month
[15:43] <ailo> smartboyhw: I would recommend you subscribe to the blueprints that you are interested in
[15:43] <len-dt> 12.10 or 12.04?
[15:43] <smartboyhw> Wait, I will subscribe them now:
[15:43] <smartboyhw> :)
[15:43] <knome> len-dt, 12.04
[15:44] <knome> len-dt, maybe it's fixed. i don't know. haven't done too many 12.10 tests yet
[15:45] <len-dt> Ya, it was a problem there. I was just wondering because there is a blueprint item for that I was hoping to make DONE
[15:45] <smartboyhw> Wait, I do see a fix scroll bar in ubiquity slide show item in the liveDVD blueprint
[15:45] <len-dt> Yes smartboyhw
[15:45] <smartboyhw> len-dt: Sorry, I pressed enter a second after you
[15:46] <len-dt> There have been a few things to fix that got fixed upstream.
[15:47] <len-dt> As I said I haven't seen them for a while, so they may have been fixed. It is something all our alpha/beta tests should look for.
[15:48] <smartboyhw> OK.
[15:53] <smartboyhw> BTW, I think I will write a testcase soon for upgrading Ubuntu Studio, astraljava disabled it due to DE change, I think we can re-enable it for 12.10/
[16:02] <smartboyhw> len-dt: I think I'll wait for a new build of Ubuntu Studio Quantal to test to see if scrollbars exist. Seems like there's build errors these days:(
[16:03] <len-dt> Yes.
[16:04] <smartboyhw> Excuse me, big bug: How come when I click "Help" in Ubuntu Studio 12.04.1 Firefox says it can't find it? I am reporting this:(
[16:05] <len-dt> It may be because we don't include ubuntu-docs.
[16:05] <smartboyhw> True. Then what should we do? I'll report the bug now.
[16:06] <len-dt> It is fixed in 12.10
[16:06] <smartboyhw> Wait, what is this package named? I mean the help one.
[16:07] <len-dt> smartboyhw, I think you mean the help icon on the main menu?
[16:07] <smartboyhw> Yes
[16:07] <len-dt> That is a different issue, it is fixed in 12.10 already
[16:07] <smartboyhw> I know, then should I still report it?
[16:09] <len-dt> No,  I don't think so. I did do a patch of the file involved forr 12.04, but interest in including it was not there
[16:10] <len-dt> It seemed that fixing it in 12.10 was acceptale.
[16:11] <len-dt> https://code.launchpad.net/~ubuntustudio-dev/ubuntustudio-default-settings/UbuntuStudio.precise
[16:20] <smartboyhw> len-dt: I'm seriously wondering: Maybe you didn't use an Launchpad account to do the patch?
[16:20] <smartboyhw> Because I looked at the revisions part, and it sounds like you're not using an Launchpad account to upload the patch.
[16:21] <knome> smartboyhw, seriously, that's the least of the worries. he HAD to use a launchpad account to be able to upload the branch.
[16:21] <smartboyhw> Hmm, weird.
[16:22] <knome> len-dt, 'bzr launchpad-login len-ovenwerks'
[16:22] <smartboyhw> But why I can't even click on his link to his Launchpad profile in the Revisions part?
[16:23] <knome> smartboyhw, because the launchpad integration isn't working perfectly.
[16:23] <smartboyhw> len-dt: Use 'bzr launchpad-login' first to check if you are using launchpad.
[16:23] <smartboyhw> knome: Uh oh, that's why
[16:23] <knome> smartboyhw, but please, stop wasting peoples' time. he was able to push, so what if his nick isn't linked?
[16:23] <smartboyhw> Oh.
[16:24] <knome> thanks for understanding
[16:24] <smartboyhw> Sorry again knome. :(
[23:14] <holstein> ailo: i dont know that you do need lowlatency
[23:14] <holstein> sometimes i do sand sometimes i dont
[23:15] <holstein> i feel like its a waste of time for me to show someone, and for someone to care about how to get lowlatency for 90% of what we all do
[23:15] <holstein> its really just live soft synths and live effects that need "realtime" ish latency
[23:15] <holstein> other than than, its a non-issue
[23:17] <holstein> ailo: i feel like the out-of-the-box config is something we all have thought long and hard about, and its good for most tasks


[11:55] <lool> Ubuntu Mobile Meeting in 5 minutes
[11:55]  * ogra rushes to make some quick coffee
[11:59]  * lool finishes his tiramisu
[12:00] <NCommander> whats tiramisu?
[12:00] <ogra> yummy
[12:00] <ogra> now i'm hungry
[12:00]  * lool throws Google on NCommander
[12:01]  * NCommander has flashes of hummus and chips
[12:01] <davidm> #startmeeting
[12:02] <StevenK> ENOMOOTBOT
[12:02] <Hobbsee> always a promising start.
[12:02] <StevenK> Haha
[12:02] <davidm> Yea, great.
[12:02] <persia> MootBot, #startmeeting
[12:03] <Hobbsee> are you going to play the part of mootbot too?
[12:03] <davidm> OK the meeting is started no mootbot so the fun commences.
[12:03] <StevenK> The nick is registered, I didn't want to get killed
[12:03] <davidm> OK lets get started
[12:03] <davidm> persia you did the agenda for today so....
[12:04] <persia> OK.  Agenda at https://wiki.ubuntu.com/MobileTeam/Meeting/2009/20090115
[12:04] <persia> First up: action items from the last meeting:
[12:04] <persia> I reviewed and assigned the open specifications.
[12:04] <persia> I also sent reminders to everyone I thought would be good to do stuff, and got corrections.
[12:05] <persia> ogra was to finish the touchscreen spec
[12:05] <ogra> working on it
[12:05] <ogra> i had so much other stuff, but i'm happy to report that evtouch isnt ftbfs anymore and in jaunty :)
[12:05]  * lool still didn't finish specs; I'm really late on this as these are to be completed and reviewed by tomorrow
[12:05] <davidm> persia, so all spec's are assigned now?
[12:06] <persia> davidm, I believe so: I'll triple-check
[12:06] <ogra> so we have at least the old touchscreen stuff back in (which didnt look like it would be possible, not even our X team could help here)
[12:06] <persia> [ACTION] persia to verify all specs are assigned
[12:06] <StevenK> I think I can mark one of my specs as Implemented, but I can go through that later
[12:06] <StevenK> ogra: I still need to re-seed it, that will happen post-alpha-3
[12:07] <persia> Getting back to the agenda...
[12:07] <davidm> OK is anyone going to have all of their assigned specs complete tomorrow?
[12:07] <ogra> right, it also has the return of the "missing cursor" bug in the calibration tool
[12:07] <ogra> but thats minor and i have a fix
[12:07] <StevenK> davidm: Complete in what sense?
[12:07] <ogra> implemented :P
[12:07] <ogra> indeed
[12:07] <StevenK> Haha
[12:08] <StevenK> I have one of those, so nyah
[12:08] <davidm> as in done writing and ready to approve
[12:08] <davidm> I'd love implemented but some how I doubt that will happen
[12:08] <davidm> persia, where are you on your spec's?
[12:09] <lool> davidm: Implemented isn't due tomorrow fortunately  ;-)
[12:09] <persia> I need a little help with mid-jaunty-launcher, and will be chasing StevenK tomorrow, but otherwise in reasonable shape.
[12:09] <lool> I'll do my best to complete writing my specs up to approvable, perhaps over the week-end if I have no other choice
[12:09] <davidm> Very true
[12:09] <StevenK> persia: I'd like your help to proof-read my specs, I think some need a little belting and polishing
[12:10] <davidm> lool,  if at all possible we are a week behind now.
[12:10] <persia> StevenK, Sure.  Let's touch base in the morning.
[12:10] <StevenK> persia: *nod*
[12:10] <persia> So, let's get back to the agenda, shall we :)
[12:10] <persia> lool was to bring up DVD with bfiller and others and see whether it's a firm need.
[12:10] <lool> Concerning the UNR DVD: I brought it up during a call on UNR; I think they want an ISO and a way to install from USB, but they don't really care about it size
[12:10] <lool> So they don't target what's in the current Ubuntu desktop DVD
[12:10] <lool> Instead they target having an useful image with an identified set of langpacks
[12:11] <lool> Exact requirements to be confirmed over the UNR jaunty integration
[12:11] <ogra> well, the current iso is 1G big
[12:11] <ogra> its already beyond any CD size
[12:11] <lool> ogra: The current DVD ISO?
[12:11] <StevenK> The current .img
[12:11] <StevenK> It's close to 1GB
[12:11] <ogra> the currnet ubuntu-netbook-remix,img
[12:11] <ogra> s/\,/\./
[12:12] <persia> So let's declare that to be a DVD-type image?
[12:12] <ogra> well, an USB img :)
[12:12] <davidm> That can work, it would fit on a DVD blank, just not use it all
[12:12] <lool> Ok, let me bring back context here: people were frightened about the word "DVD" last week because the Ubuntu desktop DVD .iso is relatively large and hence painful to test
[12:12] <ogra> yeah
[12:12] <StevenK> The code will declare it oversize if it's >1GB, currently
[12:12] <ogra> its 4.something gig
[12:12] <StevenK> I can live with that, personally
[12:12] <lool> The UNR folks don't care about what's in the Ubuntu desktop DVD, they just want a good image; I don't think they target a CD sized ISO either
[12:13] <ogra> 1G is handleable ...
[12:13] <lool> So 1 GB is fine, 500 MB is fine; what matters is that we end up with a good UNR image
[12:13] <ogra> yeah
[12:13] <mcasadevall> yay for system crashes
[12:13] <lool> And right, I agree that testing a 1 GB or a 700 MB image doesn't make a big difference
[12:13] <persia> So this can just be merged into unr-handling-jaunty, or does it need additional actions?
[12:13] <lool> Now we will see how big the image ends up being with the requirements of the UNR jaunty integration
[12:13] <ogra> the -mid image is intresting huge as well though ... is that through langpacks ?
[12:13] <lool> If we want all langpacks and extra apps, it can take a bit of space
[12:14] <davidm> merged into unr-handling-jaunty I think persia
[12:14] <lool> Yeah
[12:14] <StevenK> Keep in mind both images now have pools
[12:14] <StevenK> And pools are large ... :-P
[12:14]  * lool dives in
[12:14] <ogra> but we only install langpacks, not lang-support, right ?
[12:14] <ogra> -support is overkill and not needed
[12:14] <persia> Right.  Let's move on then.
[12:14] <persia> Current items:
[12:15] <persia> First up: I'd like to propose a transition to tracking progress through a roadmap.
[12:15] <persia> Quick review of the status of any specs or bugs that need discussion, to make sure things don't get missed.
[12:15] <davidm> works for me
[12:16] <persia> So, to support that, I've drafted https://wiki.ubuntu.com/MobileTeam/Roadmap as a list of things for quick discussion.
[12:16] <lool> I'm fine with listing spec status, but what do you mean to transition to it?  Would you remove anything from the current meeting?
[12:16] <lool> What bugs qualify for the Bugs section?
[12:16] <persia> Yep.  Drop the going around to several people and asking about them, but rather focusing on the work needing done.
[12:16] <persia> Anything you've been chasing, or you want to discuss.
[12:17] <ogra> well, we should do a quick rundown on the statuses
[12:17] <persia> OK.  Going through them then:
[12:17] <ogra> spcename: current status
[12:17] <ogra> in each meeting until implemented imho
[12:17] <ogra> *spec
[12:17] <persia> ogra, That's the idea.
[12:17] <StevenK> I think the roadmap should contain the driver for the spec
[12:17] <ogra> we all only have three or four, should be fast
[12:18] <lool> Ok; I don't quite see how that qualifies as a roadmap if we elect bugs there ourselves, but I don't really care about the name; I guess we want a) a list of specs to review on all meeting b) an entry in the recurring agenda to look at specs status
[12:18] <ogra> StevenK, ++
[12:18] <persia> Happy to add that.
[12:18] <StevenK> lool: So we call a roadmap. Shrug
[12:18] <persia> I just picked "Roadmap" because other teams had roadmaps.  I could call it something else.
[12:18] <lool> That's not what I call a roadmap
[12:18]  * ogra calls it Gladys
[12:18] <lool> Let's call it JauntySpecs?
[12:19] <persia> Except I don't expect it to be specs the entire cycle.
[12:19] <mcasadevall> sorry about that.
[12:19] <persia> I expect we'll have more bugs as we get closer to release.
[12:19] <lool> For me a roadmap would typically encompass vaguer things than specs and cover more than just this cycle
[12:19] <ogra> well, we will probably have specs that arent implemented by FF either
[12:19] <lool> persia: What's wrong with pushing them in the agenda simply?
[12:19] <ogra> and fall over into the next cycle
[12:20] <lool> Or do you want to have all milestoned bug reviewed at all meetings?
[12:20] <davidm> JauntyStatusReview??
[12:20] <persia> lool, Yes, I'd like to review stuff at each meeting, just to make sure we're not missing things.
[12:21] <lool> persia: I can't say it's a bad idea, it's exactly what we do during release team meetings, but it's going to take a while
[12:21] <lool> I would find the output useful for sure
[12:21] <persia> Right.  Let's go hrough them quick-like then.
[12:21] <StevenK> Or we could update each spec with one line before the meeting
[12:21] <StevenK> And then just ask if there is any questions, or cries for help
[12:22] <persia> StevenK, That works for me.
[12:22] <davidm> StevenK, +1 on that
[12:22] <persia> OK.  Let's get them updated with oneliners for the next meeting, and proceed from there.  Everyone good with that?
[12:22] <ogra> +1
[12:22] <lool> Hmpf
[12:22] <davidm> But since we did not do that this time can we just have a quick statement on each?
[12:22] <StevenK> Right
[12:22] <StevenK> I was about to say that
[12:22] <persia> lool, You'd rather quick discussion in the meeting?
[12:23] <ogra> only if there are issues i'D say
[12:23] <lool> persia: I have nothing better to propose to what was proposed here
[12:24] <persia> OK.  Let's go through them this time, and we'll look at updating the list with drivers and oneliners for next time.
[12:24]  * StevenK likes one-liners
[12:24] <lool> I wonder whether it would make sense to list spec status in AR instead, probably equal pain
[12:24] <ogra> both
[12:24] <ogra> i mean we should do both
[12:24] <persia> mid-screen-rotation: I still need to review the status of Aberto's work.
[12:24] <lool> I knew saying this someone would say both
[12:24]  * StevenK silences lool and ogra
[12:24] <persia> mid-jaunty-launcher: StevenK and I will chat tomorrow.
[12:25] <StevenK> Sounds omnious
[12:25] <persia> mobile-applications: Someone needs to volunteer to review an email reader
[12:25] <NCommander> persia, I did
[12:25] <NCommander> email and IM was assigned to me last meeting
[12:25] <persia> NCommander, Sorry.  Missed that.  I'l update the spec
[12:25] <NCommander> NP
[12:26] <persia> mid-ship-seed-for-mobile-images : ?
[12:26] <StevenK> Implemented
[12:26] <StevenK> The spec needs some polish, but it's done
[12:26] <lool> Link is broken
[12:27] <persia> mid-application-switcher: not even drafted, but I ought get to that this weekend
[12:27] <persia> mobile-team-seed-management ?
[12:27] <lool> Drafter is you
[12:28] <persia> heh.  I think StevenK already implemented about half of it, but I'll get it drafted so we can tell tomorrow then.
[12:28] <persia> unr-handling-jaunty
[12:28] <StevenK> Processing
[12:28] <StevenK> Er
[12:28] <StevenK> *Preceeding*
[12:28] <persia> Proceeding?
[12:28] <davidm> persia, yes
[12:28] <persia> recovery-partition
[12:29] <lool> recovery-partition: needs drafting
[12:29] <StevenK> persia: As in, work is on-going
[12:29] <lool> poulsbo-packaging: needs more complete drafting, implementation in progress AIUI
[12:29] <StevenK> It is
[12:29]  * NCommander thought recovery-parition was drafted
[12:29] <NCommander> I looked at that spec
[12:29] <persia> offline-installer: I've nearly completed the script to automate the testing, but need to write the spec
[12:29] <ogra> offline-installer: looks like ready for review, persia drafted fine :) no coding work started yet
[12:30] <lool> NCommander: Well the current spec is very vague and doesn't include UDS discussion
[12:30] <StevenK> I'm being bad and working on specs before they're approved
[12:30] <persia> ogra, Right.  I seem to have confied that with something else :)
[12:30] <ogra> persia, erm, i'm the assinee :)
[12:30] <persia> s/confined/confused/
[12:30] <ogra> yeah
[12:30] <persia> touchscreen?
[12:31] <ogra> not sure that will fully make it, but we should have a GUI for the build tools in any case
[12:31] <ogra> eneral-resolution-for-touchscreen-handling: drafting, needs to get in shape, tech info missing yet, BOF info there. looked into evdev code
[12:31] <ogra> +g
[12:31] <ogra> selection-of-arm-images: drafting, though there shouldnt be anything to do for the selection case, the BOF session covered everything, images were selected, needs enablement on the build servers once d-i is ready
[12:31] <ogra> afaik NCommander looked at d-i and will go on there once we're ready
[12:31] <lool> (It's not in the current 'Roadmap' page)
[12:32] <ogra> right, its not really a spec
[12:32] <ogra> since we did the selection
[12:32] <NCommander> d-i is dep-wait on the kernel udebs
[12:32] <NCommander> WHich aren't very happy ATM
[12:32] <ogra> but we should keep it to see how far we got on the build servers
[12:32] <ogra> or the general image status... or some such
[12:32] <StevenK> ogra: And there is no image buildd for armel yet
[12:33] <ogra> StevenK, how could teher be, we have no d-i and no livefs buildd :)
[12:33] <ogra> and no initramfs possibilities
[12:33] <lool> persia: I don't think mid-display-manager warrants being listed, but perhaps the bug relater to startx / CK should be?
[12:33] <ogra> live cant hapen unless there is initramfs support
[12:33] <StevenK> ogra: When I say image buildd, I mean livefs buildd
[12:34] <lool> squashfs-initrds: we need to kill that spec; I should just copy notes from UDS and #ubuntu-devel and close this
[12:34] <ogra> yeah, but there are other showstoppers anyway that need solving first
[12:34] <persia> lool, Yes, I'd think so.  What's the bug number?  Do you want to cover it?
[12:34] <ogra> no kernel, no initrd -> no live image
[12:34] <lool> I don't have it off hand unfortunately
[12:34] <persia> lool, When you find it, just remove the spec, and add the bug.
[12:35] <persia> Anyway, I think I have a solution for bug #291670, but I'm still trying to figure out how the testsuite needs to be written.  Should be done in a couple days.
[12:35] <lool> So, we've spent > 10 minutes on spec status
[12:35] <lool> But this only covers our "mobile" specs
[12:35] <ogra> because we werent prepared
[12:36] <persia> Well, this is the mobile meeting, no?
[12:36] <lool> I have a problem with covering only MID and "mobile" specs progress in this meeting and not at all the other ones
[12:36] <lool> persia: But we have no ARM meeting
[12:36] <ogra> yeah, it should cover the team specs
[12:36] <lool> And we spend more time on ARM stuff than on MID/mobile stuff
[12:36] <ogra> which will hopefully change again :)
[12:36] <ogra> once ARM is ready
[12:37] <persia> lool, It's not really important how you spend your time: this set of specs is interesting to determine what needs doing, and how it's going for the Mobile flavours.
[12:37] <ogra> during arch enablement/portin we should keep that status here as well imho
[12:37] <ogra> it will vanish as soon as we get automated images and the archive is complete
[12:37] <NCommander> There are a few outstanding ARM spec/issues that need discussion.
[12:38] <lool> persia: I don't think it's fair to list half of the specs we work on and take action on that etc. every week and not cover the other half
[12:38] <ogra> thats why i proposed to have an ARM section in this meeting :)
[12:38] <persia> But this is the Mobile Meeting.
[12:38] <lool> So as awful as it sounds, I'm tempted to propose that we have a mobile team meeting where mobile team is not the Ubuntu Mobile project's team, but something like the desktop and foundation and kernel and server teams
[12:38] <ogra> and most of the mobile team works on AMR atm
[12:38] <persia> Just because you're working also on something else, doesn't make this the only meeting.
[12:38] <ogra> *ARM
[12:39] <persia> Anyway, we're getting off-topic.  Let's go back to the agenda.
[12:39] <persia> Any Other Business ?
[12:39] <davidm> persia, we come back to my concern, I don't want to schedule another meeting
[12:39] <persia> (related to the mobile flavours)
[12:40] <davidm> persia, I propose we make the mobile meeting 1/2 hour and have a team projects meeting 1/2 hour
[12:40] <ogra> ++
[12:40] <NCommander> ++
[12:41] <ogra> thats what i suggested from the beginning ... though i'd have said 1/3 for projects
[12:41] <ogra> 1/3 for spec stauses
[12:41] <ogra> 1/3 for general mobile stuff
[12:41] <ogra> not in that order though
[12:42] <davidm> OK 2/3 mobile meeting 1/3 hour other projects
[12:42] <ogra> right
[12:42] <lool> This meeting is supposedly about Ubuntu Mobile; there's nobody covering Ubuntu Mobile work outside of the team; I propose we hold a public team meeting where we discuss Ubuntu Mobile along other of the team's activity
[12:43] <davidm> Lets face it we are enabling the entire main and most of universe so that includes mobile stuff
[12:43] <lool> If we reach the point where we have enough Ubutnu Mobile topics to warrant a full meeting like the one we had until now, then we can reinstatee it
[12:43] <ogra> lool, thats what davidm's setup above covers
[12:44] <lool> Right, I'm insisting on the way we shuffle the names and official contents of this and the new meeting
[12:45] <lool> Now this is not to say that contributions are not welcome, but it's a bit hard to bend ourselves so much right now
[12:46] <ogra> the topic calls this "Ubuntu Mobile Team" so i dont see a prob here, we're discussion what the ubuntu mobile team works on
[12:47] <ogra> (and note it doesnt say *canonical* mobile team ... *ubuntu* includes the community ... i dont understand the naming prob)
[12:47] <lool> There's confusion between the Ubuntu Mobile project which is not related to arm and the mobile team, currenlty manned mostly by Canonical employees which work on ARM
[12:47] <ogra> because we make that confusion up
[12:47] <ogra> the channel topic has a clear name
[12:48] <lool> I don't think so
[12:48] <lool> We've put a process up for joining the ubuntu-mobile launchpad team which is aimed at MID/Netbook, not ARM
[12:49] <ogra> so you would send people away that have worked with us on ARM stuff and want to discuss it in this meeting because they can grab us at the same time in a single place ?
[12:49] <persia> Yes!
[12:50] <persia> I'd suggest they go to the Desktop or Sever or Foundation meeting, and discuss it there.
[12:50] <ogra> or would refuse them from entering the ubuntu-mobile LP team just because their MID interest is in n800 only ?
[12:50] <persia> No reason not to discuss MID-on-arm here, or n800.
[12:50] <NCommander> my issue with sending them to another team is the Mobile ARM guys our here, and not usually at the Desktop/Server/Foundations meeting
[12:52] <davidm> Any we are all not going to be at the  Desktop/Server/Foundations meeting so this is the only place to catch all of us
[12:53] <lool> How can we take community input on what would be best for Ubuntu MID/UMPC/UNR on one side, and Ubuntu ARM enablement on the other?
[12:53] <Hobbsee> ask community people at the meeting?
[12:53] <persia> Hobbsee ++
[12:53] <ogra> by donating a part of the meeting time to ARM ... invite other teams to participate and tell the commnity about it
[12:54] <lool> We don't have an Ubuntu ARM enablement meeting (for reasons described earlier); it's hard to cover these people
[12:54] <ogra> and draw a clear line between the two sections
[12:54] <Hobbsee> the other option is to make a LP poll, and stick it in the topic of #ubuntu-arm or something.
[12:54] <Hobbsee> if you want to specifically target arm people.
[12:54] <lool> Are some people who would quality as community people around?  Could you share your opinion?
[12:54] <lool> *qualify
[12:55] <Hobbsee> I don't have an opinion either way, sorry.  I don't follow anywhere near closely enough
[12:55] <lool> Hobbsee: Would you mind replacing this meeting with one where half of it would be ARM and the other half MID/Netbook?
[12:55] <ogra> 1/3
[12:56] <ogra> 20min ...
[12:56] <Hobbsee> Splitting the meeting into multiple sections means that the first one couldn't run overtime, which may be a problem.
[12:56] <Hobbsee> lool: depends which was first, but I really don't mind either way.
[12:56] <ogra> and it would need annoucement in the channels and MLs
[12:57]  * ogra would see the "cant run over time" a good thing actually :)
[12:57] <davidm> We are out of time folks
[12:57] <lool> My feeling is that we've been designing this for easy access to the Ubuntu Mobile/MID/UMPC/Netbook community from the start, but didn't attract a lot of community so far and might have been optimizing the wrong way
[12:57] <Hobbsee> The other general concern is if you start late due to technical difficulties (or lack of coffee), your first meeting could be forced very short (and presumably you can't overflow to -mobile, as others will be participating in the arm discussion)
[12:58] <lool> Hobbsee: That's a good point
[12:58] <davidm> 2 minutes left
[12:58] <lool> I guess it's unlikely we come to any conclusion today
[12:58] <StevenK> I like how "lack of coffee" is a reason for a late start
[12:58]  * StevenK glances at davidm
[12:58] <Hobbsee> you'd probably do better to have 2 meetings @ the same time, on different days
[12:58] <Hobbsee> StevenK: *grin*
[12:58] <ogra> Hobbsee, thats what we want to avoid
[12:58] <davidm> Hobbsee, that is a lot of meetings
[12:59] <Hobbsee> davidm: this is true.  But presumably they should be short and sweet, and various people would only need to attend one or the other?
[12:59] <lool> Unfortunately, it reaches a threshold on number of meetings and number of days where people have to wake up very early or stay up very late   :-/
[12:59] <NCommander> Hobbsee, as a general rule of thumb, I think both myself and davidm would be very cranky to get up very early on another day
[12:59] <Hobbsee> NCommander: may you never come to australia.
[12:59] <davidm> If they are short and sweet then bundeling should be fin
[12:59] <Hobbsee> lool: this is true.
[12:59]  * lool :-)
[13:00] <davidm> OK meeting closed
[13:00] <lool> Ok folks, we have to leave the floor
[14:01] <persia> Who's here for the Java Team Meeting
[14:03] <slytherin> me
[14:05] <persia> Anyone else?
[14:08] <persia> slytherin, Unless you've something extra to share, let's skip this week, and come back next week, when there are more of us.
[14:08] <slytherin> persia: I have only one thing to tell.
[14:09] <slytherin> The sync/merge of maven packages have stalled for now as I am not completely able to figure out why some packages have FTBFS in Ubuntu. ex. doxia-sitetools. I will probably continue the work over weekend.
[14:10] <persia> You're working with ludovicc on this?
[14:13] <slytherin> persia: not exactly. I haven't yet collaborated with him about build failures. I will do that hence forth.
[14:14] <slytherin> in any case, the Debian developer who is uploading the package is uploading most of them to experimental. So for solving FTBFS I have to first check if any build dep from experimental will solve the problem.
[14:15] <persia> OK.  I'd suggest checking with him, as he reported last week that he was deeply involved.
[14:16] <slytherin> yup
[14:18] <persia> OK.  Until next week then :)
[16:04] <mib_dmkxwlmf> hello
[16:04] <mib_dmkxwlmf> can you speak spanish?
[16:04] <mib_dmkxwlmf> or only english?
[18:50] <juliux> hi
[19:19] <popey> @schedule
[19:19] <popey> thats not right
[19:20] <ogra> its a very relaxed schedule :)
[19:22] <popey> bah
[19:26] <boredandblogging> ooh oops
[19:26] <boredandblogging> forgot to move the meeting on the calendar
[19:26] <boredandblogging> darn
[19:27] <popey> nvm
[19:27] <popey> glad I actually remembered ahead of time for once :)
[19:28] <boredandblogging> heh
[19:28] <boredandblogging> popey: how's life?
[19:35] <popey> madly busy :)
[19:55] <juliux> evening
[20:57] <juliux> hi all
[20:57] <boredandblogging> hey hey
[20:58] <itnet7> hey there!
[21:00] <dantalizing> wazzza
[21:00] <cdrigby_Singapor> Good <your time of day here> everyone. I am here for the LoCo meeting, representing the Singapore group TUSG (http://ubuntu.sg)
[21:01] <ziroday> cdrigby_Singapor: hey, its not started yet :)
[21:01] <boredandblogging> @now
[21:01] <boredandblogging> shall we get started?
[21:01] <boredandblogging> popey: ping
[21:01] <boredandblogging> JanC: ping
[21:01] <boredandblogging> effie not around?
[21:02] <JanC> I'm here
[21:02] <popey> pong
[21:02] <boredandblogging> sweet
[21:03] <juliux> i am also here
[21:03] <boredandblogging> shall we start with Singapore and then do the rest of the agenda?
[21:03] <juliux> sounds good
[21:03] <popey> rock on
[21:05] <ziroday> cdrigby_Singapor: this is the part where you speak :)
[21:06] <cdrigby_Singapor> Hello everyone. Ziroday & I are here for the Singapore group.
[21:06] <supervivid> and me
[21:06] <cdrigby_Singapor> Aha. G'day, supervivid.
[21:06] <boredandblogging> how many people were at the intrepid install fest?
[21:07] <boredandblogging> pictures of the food look great :-P
[21:08] <cdrigby_Singapor> I was not at that one myself (I was in the US at the time). Perhaps one of the others was at the event. I'm sorry I missed the food!
[21:08] <supervivid> 5 members
[21:08] <supervivid> the food were great!
[21:09] <juliux> where there also some activities befor 2008? and what are your plans for 2009?
[21:09] <juliux> any releaseparties again?
[21:09] <supervivid> we will be planning a few activities, and release party is in the radar
[21:10] <cdrigby_Singapor> 2008 - software freedom day, plus a follow up "welcome to Ubuntu" session for those that visited our SFD booth.
[21:11] <cdrigby_Singapor> 2009 - Regular meetings, new user "clinics" held three or four times/year, SFD 2009.
[21:11] <cdrigby_Singapor> A release party for next version, of course!
[21:11] <ziroday> juliux: but to answer your question, before 2008 there was just loose organization and the setting up of infastructure such as websites, IRC and mainly getting everybody together
[21:12] <juliux> ziroday: so 2008 was your year;)
[21:12] <supervivid> yes
[21:13] <cdrigby_Singapor> It will probably be February before we show much activity in 2009. Lunar New Year is soon, which is major holiday here in Singapore.
[21:14] <boredandblogging> looks like you guys did great stuff for SFD
[21:14] <JanC> ziroday: were the LoCo team members involved in Ubuntu-promotion before 2008?  (I mean, without calling yourselves "ubuntu singapore")
[21:15] <ziroday> JanC: to some degree, there were no big events planned. However we were all together
[21:15] <cdrigby_Singapor> I was using and promoting Ubuntu since 2005 or so. But I was in Paris, France before the end of 2006.
[21:16] <JanC> you don't need (big) events necessarily, I was thinking about giving support etc.?
[21:16] <ziroday> boredandblogging: yeah it was really great. Plus we were the only desktop orientated group there which rocked. Lots and lots of people at our stand
[21:16] <juliux> any plans to get more people working/helping your locoteam?
[21:17] <ziroday> JanC: ah support wise yes, the IRC and mailing list was up then. And were somewhat active. But as juliux said 2008 was our year
[21:18] <cdrigby_Singapor> Juliux: Recruiting is a big concern. Attending community events, such as Interesthink, is going to be a focus for bringing in more folks.
[21:19] <ziroday> juliux: However the issue is getting people from the "Oh hi this is neat" in the conferences to actually using and then being part of the loco. Were hoping  the forums which are more new user friendly will make that task easier
[21:19] <cdrigby_Singapor> juliux: as well, using Facebook and various boards and sites around the area, we will advertise our regular meetings and events.
[21:19] <boredandblogging> how about LUGs at universities?
[21:20] <cdrigby_Singapor> juliux & boredandblogging: Many of us are are involved in other FOSS groups here. That is the other source of recruiting.
[21:21] <JanC> are you working towards non-IT people too?
[21:21] <boredandblogging> think you guys have a good start, but I would like to see more promotion and support
[21:21] <cdrigby_Singapor> boredandblogging: Three universities have active FOSS groups: Singapore Management University, National University of Singapore, and Nanyang Technological University. They all joined us in participating in SFD.
[21:23] <ziroday> JanC: yep, we met quite a few on SFD. Unfortunately many are uncomfortable with IRC or mailing lists. The idea of a website and forum was really really meant to bridge that gap
[21:23] <cdrigby_Singapor> JanC: Yes, but that is a tougher nut to crack of course.
[21:25] <boredandblogging> ok, lets vote
[21:25] <cdrigby_Singapor> JanC: The "ubuntu clinic" idea is focused on end-users who are not IT-oriented. It is meant to be primarily educational for end-users.
[21:26] <boredandblogging> seems like Singapore has good plans, but I would to see the LoCo come back in a few months
[21:27] <popey> I have to say I agree with boredandblogging, I'd like to see more evidence of sustained activity
[21:27] <boredandblogging> after some activity on the forums and some events
[21:27] <JanC> you can try places where end-users come, e.g. I gave a presentation to a computer club with mostly elderly people in it (most evenings they just talk about how to use styles in MS Word and stuff like that)
[21:27] <JanC> of course you also have to adapt your presentation to that public then  ツ
[21:28] <JanC> boredandblogging: +1
[21:28] <juliux> boredandblogging: +1
[21:29] <cdrigby_Singapor> OK - shall we return after April release?
[21:30] <JanC> cdrigby_Singapor: I would say, return if you think you have enough to show, there are no deadlines
[21:30] <cdrigby_Singapor> OK
[21:31] <boredandblogging> cdrigby_Singapor, ziroday good luck
[21:31] <ziroday> boredandblogging: thanks :)
[21:31] <supervivid> thank you
[21:31] <boredandblogging> ok, I had some things on the agenda
[21:31] <cdrigby_Singapor> Thanks. Au revoir.
[21:32] <popey> so you do
[21:32] <boredandblogging> is there anything we can do to promote the global bug jam?
[21:32] <popey> you could podcast about it :)
[21:32] <popey> we could blog about it :)
[21:32] <popey> twitter / identi.ca etc
[21:32] <boredandblogging> popey: we will be interviewing Jorge Sunday
[21:32] <popey> ace
[21:32] <boredandblogging> think all the LoCos know about it by now, right?
[21:33] <juliux> yes it comes over loco-contacts
[21:33] <dantalizing> who are you interviewing?
[21:33] <dantalizing> ;)
[21:33] <boredandblogging> dantalizing: pffft
[21:33] <boredandblogging> ok, so next
[21:33] <boredandblogging> the next two items might be related
[21:33] <popey> i dunno what else?
[21:34] <popey> we could ask all the other linux podcasts to do it?
[21:34] <popey> maybe do an audio promotion they can slot in?
[21:34] <boredandblogging> popey: thats a good idea
[21:34] <boredandblogging> a nice logo or banner
[21:34] <boredandblogging> that people can post on their blogs
[21:34] <boredandblogging> and locos can post on their sites
[21:34] <popey> yeah, "I'm going to bug jam!" type banner
[21:34] <boredandblogging> right
[21:34] <popey> have a countdown?
[21:34] <popey> like we do for releases
[21:34] <boredandblogging> oh nice
[21:35] <itnet7> +1
[21:35] <popey> maybe you guys could make a very short video about it - which would include jorge, maybe 3 mins long
[21:35] <popey> which we could all embed
[21:35] <popey> separate from the podcast but obv recorded on sunday when you have him
[21:35] <boredandblogging> right right, I like that
[21:35] <popey> facebook too
[21:35] <popey> how about a facebook group?
[21:36] <juliux> facebook?
[21:36] <juliux> not everybody has an account there
[21:36] <popey> so?
[21:36] <popey> not everyone has flash
[21:36] <popey> not everyone has twitter or identi.ca
[21:36] <juliux> there are you right;)
[21:36] <boredandblogging> lol
[21:36] <popey> media blitz :)
[21:36] <boredandblogging> ok, will see what I can do about the video
[21:36] <juliux> i think it is more a task for the marketing team
[21:36] <JanC> more places == more viewers
[21:36] <popey> yup JanC
[21:37] <boredandblogging> yeah
[21:37] <juliux> and if we do something we should create content every loco could use
[21:37] <dantalizing> email?
[21:38]  * popey is creating a facebook group now..
[21:38] <boredandblogging> think the banner at a minimum
[21:38]  * juliux doen't like systems where he as to create an extra account
[21:38] <popey> you dont have to juliux
[21:39] <popey> nobody is asking you to
[21:39] <juliux> popey: to read things at facebook i have to
[21:39] <popey> right
[21:39] <popey> and you have to have an internet connection to get on irc
[21:39] <popey> get over it :)
[21:39] <juliux> so the group you reach with a facebook group is very limited
[21:39] <popey> you're massively mistaken there
[21:39] <juliux> i will stop and will let you do
[21:40] <popey> thanks!
[21:42] <dantalizing> crickets
[21:42] <JanC> it's for existing Facebook-users
[21:43] <boredandblogging> next topic...
 it's for existing Facebook-users
[21:43] <JanC> not to push people to facebook
[21:44] <boredandblogging> we can discuss facebook later
[21:44] <boredandblogging> lets move on
[21:44] <boredandblogging> at UDS we had talked about getting successful LoCos to share some stories
[21:44] <boredandblogging> like what they have done
[21:44] <boredandblogging> so other LoCos can learn
[21:45] <boredandblogging> think we said maybe doing an IRC meeting everyone couple of months
[21:45] <boredandblogging> popey: about that often right?
[21:45] <juliux> i think regular irc meeting would be very good
[21:45] <popey> yes
[21:46] <popey> getting them to come along and share
[21:46] <boredandblogging> and gives other LoCos a chance to ask questions directly
[21:46] <juliux> my experiences is the best shareing is if people get contacted personal
[21:46] <JanC> sounds good
[21:47] <popey> true
[21:47] <boredandblogging> so lets try to at least have one or two before 9.04 is released?
[21:47] <juliux> yes
[21:48] <boredandblogging> should we focus on one LoCo per meeting or just a roundtable?
[21:48] <popey> we could trial it with one?
[21:48] <juliux> i like the roundtable
[21:48] <juliux> and perhaps a topic per meeting
[21:49] <boredandblogging> yeah, maybe try with one, if its not too messy, then a roundtable?
[21:50] <juliux> yeah
[21:50] <boredandblogging> anyone want to organize this?
[21:51] <JanC> I think working with topics might be a good idea
[21:51] <boredandblogging> we need to pick one loco and maybe just send out an email to loco-contacts?
[21:51] <popey> yeah
[21:51]  * popey votes the french loco
[21:51] <JanC> and then find a couple of loco's to talk about what they do around it
[21:52] <boredandblogging> JanC: what topic would you suggest?
[21:53] <JanC> I don't know, but we could ask the locos what they want/need ?
[21:53] <boredandblogging> think the first time, it would be easier if we just pick something
[21:53] <boredandblogging> and then after they see how it works
[21:53] <boredandblogging> let them pick
[21:54] <popey> "organising a release party" would be a good one :)
[21:54] <popey> (for the French)
[21:54] <JanC> for example
[21:55] <boredandblogging> ok...
[21:55] <JanC> and afterwards other locoteams can tell how they do it, so that people see there are alternatives...
[21:55] <boredandblogging> so we are agreed on release party and the French?
[21:56] <juliux> yes
[21:56] <JanC> if "The French" agree  ツ
[21:56] <boredandblogging> JanC: it will become chaos anyway :-P
[21:56] <juliux> if we need a second one i am interesting to do fair work or ubucon;)
[21:56] <boredandblogging> juliux: sounds good
[21:56] <boredandblogging> JanC: just threaten to call huats 4K :-P
[21:56] <popey> ooo yeah, I'd like to hear about that juliux
[21:57] <popey> we don't do enough organising for events like that and I'd love to know what goes on to make one happen
[21:57] <dantalizing> 4k is his real name now
[21:58] <juliux> so we have some content for the next months;)
[21:58] <boredandblogging> excellent
[21:58] <boredandblogging> someone want to ask huats?
[21:59] <boredandblogging> I can do it
[21:59] <JanC> juliux: fair work as in open source events or as in ordinary computer fairs?
[21:59] <dantalizing> lol
[22:00] <juliux> JanC: fair work for opensource vents at ordinary computer fairs;)
[22:00] <juliux> JanC: most time there is an opensource area at the fairs
[22:01] <JanC> well, not really at the fairs we do mostly
[22:01] <juliux> but we also have opensource fairs only like linuxtag
[22:01] <JanC> they are fairs where they sell all sorts of new & used computers & computer parts
[22:02] <boredandblogging> cool
[22:02] <JanC> so we get mostly people looking for cheap computer stuff
[22:02] <juliux> normaly we don't attend this selling shows
[22:02] <JanC> the advantage is you get a lot of "ordinary" people
[22:03] <juliux> btw we start next week ubucon-de 2009 organisation;)
[22:03] <JanC> and, we offer to install Ubuntu on second hand computers they buy
[22:04]  * JanC once installed Ubuntu in Turkish for a young woman who just moved from Turkey to Belgium
[22:04] <JanC> nobody sold Windows in Turkish there...   :P
[22:05] <boredandblogging> heh
[22:05] <boredandblogging> ok, one more agenda item
[22:05] <dantalizing> windows with turkish translations? or nobody spoke turkish to sell windows?
[22:05] <JanC> turkish translations
[22:05] <boredandblogging> LoCos requesting to use LP lists
[22:06] <juliux> i personal think locos should use normal maillingliste, because there you don't need an extra account to get on the list, a mailaddress is enough
[22:07] <juliux> so the entry barrier is very slow
[22:07] <popey> it's good to get people on launchpad though
[22:07] <itnet7> we had signed up for the beta ,and now we have 40 users in the beta and 70 in the mailing list
[22:07] <popey> and signing up to launchpad is no more difficult than signing up for mailman
[22:07] <itnet7> in order to get people involved in bug triaging the need and LP account anyways
[22:07] <popey> email address/password is all you need
[22:08] <itnet7> should read: they need an LP
[22:08] <dantalizing> and who doesnt love launchpad?
[22:09] <boredandblogging> the decision the CC made a while ago and reaffirmed by mdke recently was that main list should be on mailman
[22:09] <boredandblogging> secondary lists (like for planning or admin) can be on LP
[22:09] <boredandblogging> apparently LP still doesn't have some features (which, I don't know)
[22:09] <popey> the good thing about launchpad is someone can sign up for a group (loco) and be on the mailing list with one extra button press
[22:09] <popey> archive is appalling boredandblogging
[22:09] <popey> nothing like the archiving that mailman uses
[22:09] <popey> very flat and ugly
[22:10] <boredandblogging> ahh, ok
[22:10] <popey> i am not sure about spam management and other settings either
[22:10] <JanC> mailman doesn't do archiving AFAIK  ツ
[22:10] <JanC> but there are several tools that with mailman
[22:10] <popey> I suspect you know what I'm talking about though
[22:10] <popey> the default one used by lists.ubuntu.com
[22:11] <JanC> I think the intention is to move everything to launchpad once launchpad is ready for it?
[22:11] <dantalizing> launchpad-users was recently moved to launchpad
[22:11] <JanC> in that case we should probably do what the CC decided?
[22:11] <juliux> i think we should hand over that to the cc back
[22:12] <popey> yeah
[22:12] <popey> +1
[22:12] <juliux> the have allready made an decision about that so they should change the decision if needed;)
[22:12] <boredandblogging> JanC: yeah, long term it will moved to LP
[22:12] <JanC> juliux: +1
[22:12] <boredandblogging> awesome
[22:12] <boredandblogging> anything else to discuss?
[22:12] <dantalizing> so is someone going to bring this up wiht cc?
[22:12] <boredandblogging> we need to start doing reviews again
[22:13] <dantalizing> is there support in this council for lp lists?
[22:13] <boredandblogging> dantalizing: if you want the policy changed, yeah probably
[22:13] <boredandblogging> i didn't know about the archiving issue, thats a big deal for me
[22:15] <boredandblogging> JanC, juliux at UDS we talked about joining the mailing lists of the LoCos that didn't respond to the review emails
[22:15] <boredandblogging> and emailing the lists directly
[22:15] <JanC> BTW: how is moderation infrastructure for launchpad lists?
[22:16] <JanC> (I haven't used them)
[22:16] <popey> dunno, i am not a moderator of any lp lists i dont think
[22:16] <JanC> boredandblogging: right
[22:16] <popey> maybe one, but it gets zero traffic
[22:16] <JanC> ツ
[22:17] <juliux> boredandblogging: sounds good
[22:17] <boredandblogging> how long do we give them?
[22:17] <JanC> we had an annoying person on the ubuntu-be list that I'm the admin of, so I think it's important
[22:18] <juliux> boredandblogging: i think if send them twice a mail we should join there lis
[22:18] <juliux> t
[22:18] <boredandblogging> juliux: joing their list after sending the contact 2 emails?
[22:18] <JanC> juliux: if we can join it...
[22:19] <JanC> are all locoteam-lists free to join or are some of them moderated?
[22:19] <juliux> boredandblogging: yes
[22:19] <JanC> (and should we require lists to be free to join?)
[22:19] <juliux> boredandblogging: how often are you mailing them? every month?
[22:20] <boredandblogging> juliux: I've never emailed any contact more than once
[22:20] <juliux> ok
[22:20] <boredandblogging> (but I have never gotten any bounces)
[22:20] <popey> guys - I need to go - I have to drive my mum home :)
[22:20] <boredandblogging> popey: later
[22:22] <nizarus> thx popey :)
[22:22] <popey> :)
[22:22] <boredandblogging> ok, so I send them one more email
[22:22] <juliux> boredandblogging: good
[22:22] <boredandblogging> the thing is that I don't ask for a response
[22:22] <boredandblogging> I should probably say they should respond acknowledging the email
[22:23] <juliux> yeah
[22:23] <boredandblogging> if they don't respond within two or 3 weeks
[22:23] <boredandblogging> join their mailing list
[22:23] <boredandblogging> and then give them how long?
[22:23] <juliux> i think we can resend them a mail after four week
[22:23] <juliux> s
[22:24] <boredandblogging> resend which one?
[22:24] <boredandblogging> resent to the mailig list?
[22:24] <JanC> well, I'd say they should really respond within 1 or 2 weeks after we mail their list?
[22:25] <JanC> even if it's not the official contact
[22:25] <itnet7> Thanks for discussing our topic earlier guys, Gotta Run! ttyl
[22:25] <boredandblogging> I agree
[22:25] <boredandblogging> if it takes more than 2 weeks
[22:25] <JanC> if there is nobody reading the list, then there is no locoteam
[22:25] <boredandblogging> right
[22:26] <boredandblogging> ok, so email the contact a 2nd time, give them 2 weeks, if no response, email list, if no response in 2 weeks, we can consider the LoCo unapproved
[22:26] <boredandblogging> and if they respond at any point, give them one month?
[22:26] <juliux> yeah
[22:26] <boredandblogging> for their approval application
[22:27] <boredandblogging> ok
[22:27] <juliux> but two weeks could be a normal holidy
[22:27] <juliux> holiday
[22:28] <boredandblogging> then I say 3 weeks for the contact, 1 week for the mailing list
[22:28] <JanC> juliux: for a loco-contact, yes
[22:28] <JanC> but 2 mails = 2 x 2 weeks
[22:28] <juliux> oh yes
[22:29] <juliux> so i am fine with your way boredandblogging
[22:29] <boredandblogging> ok, cool
[22:29] <JanC> and a mailing list has enough people so that normally not everybody is on holidays I suppose  ツ
[22:29] <boredandblogging> JanC: hopefully
[22:30] <boredandblogging> ok, I'll update the wiki pag
[22:30] <boredandblogging> e
[22:30] <boredandblogging> and then go back through the LoCos who never responded
[22:30] <boredandblogging> thats all I have
[22:34] <juliux> what about next meeting?
[22:35] <juliux> and have contacted some locos for reapproval for the next meeting?
[22:35] <boredandblogging> ummm, no
[22:35] <boredandblogging> thats my fault
[22:36] <boredandblogging> I'll try to do it sometime next week
[22:37] <juliux> thanks a lot
[22:37] <boredandblogging> thanks juliux JanC
[22:37] <juliux> i will go to bed now
[22:37] <juliux> cu the next days
[22:37] <boredandblogging> juliux: nite
[22:37] <JanC> slaapwel juliux


[09:51] <eyfour> Who do I contact in order to get bug fixes for init scripts pulled into the repos?
[09:51] <eyfour> The maintainer of the package in question is an upstream Debian developer, and the bug was fixed a couple of years ago in Debian.
[09:52] <eyfour> Bug link: https://bugs.launchpad.net/ubuntu/+source/postgrey/+bug/981789
[17:10] <cprofitt> this bug was marked a duplicate: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1510339
[17:10] <teward> cprofitt: okay?
[17:11] <cprofitt> not sure that this is a duplicate -- but if it is shouldn't the duplicate be reversed and the later bug be marked the duplicate
[17:16] <cprofitt> your thoughts teward -- I was thinking of chaning the duplicate status... the original bug likely should have be marked will not fix -- since 15.04 is not an LTS
[17:20] <teward> cprofitt: the question is not what the bug was filed under.  the question is if the bug still exists in a supported release.
[17:20] <teward> if I filed a bug under 9.04, but nothing's moved to fix it and it continues to exist in 16.04 and 16.10 then the bug is still valid
[17:20] <teward> that said i'm not qualified to touch on a network-manager bug
[17:20] <teward> i avoid those like the plague :)
[17:21] <teward> (same for kernel bugs, unless they directly torpedo something I work on)
[17:21] <cprofitt> I could reverse the duplicate status...
[17:21] <teward> i'd honestly wait for more opinions
[17:21] <teward> i'm least qualified to comment in this case (network-manager bugs are weird...)
[17:23] <cprofitt> teward: thanks I will try to ask Martin -- he is the one who marked the duplicate...
[17:23] <cprofitt> thanks for the advice
[17:24] <teward> cprofitt: it may be the case they're the same underlying problem though
[17:25] <teward> that said, I will say 100% that you should *not* reverse the dupes, if they're not the same then that's one thing, but switching which is a dupe of which makes no sense
[17:25] <teward> that's my opinion
[17:27] <cprofitt> teward: why would the dups not be reversed -- I was always taught newer bugs were makred as duplicates of older bugs... has that changed?
[17:28] <cprofitt> I was taught that when devs are looking at fixing bugs having the original report was important due to that establishing the original date of the issue.
[17:29] <teward> i'm not sure who taught you that, but consider I have a handful of bugs that are 'recent' but have an 'old' bug they're marked to.
[17:29] <teward> the original report is the one yours is marked as a dupe of by date alone
[17:29] <teward> oop i misread the years
[17:29] <cprofitt> yep
[17:29] <teward> cprofitt: the second consideration is which one has more 'useful data'
[17:30] <teward> i've actually switched dupe status from an older to a newer when the older had zero debug data but the newer had a lot more, and the core issue was the same
[17:30] <teward> there's a few cases of that on the nginx bugs, though i have handled so many you'd have to dig to find the xpecific examples
[17:30] <teward> bleh i can't type
[17:30] <teward> cprofitt: Personally, if they're the same issue, I suggest leaving it alone, I see more debug data on the newer one than the older
[17:30]  * cprofitt nods I can agree with that
[17:30] <teward> assuming they're the same issue (checking with Martin wouldn't hurt)
[17:31] <teward> the only reason *I* would change it is if I knew they weren't the same issue.
[17:31] <cprofitt> the newer one has more activity... though not the same file uploads...
[17:32] <cprofitt> I never change my own bugs status -- makes it look petty, but wanted to understand what happened here since it ran counter to what I had been taught.
[17:32] <cprofitt> in the end -- getting the bug fixed is important.
[17:33] <teward> actually i just thought of an example of the issue - there's older bugs closed as Invalid for "Address already in use" for nginx.  Ther'es now a 'master' bug that was created detailing the signature
[17:33] <teward> and that's now in apport dupe detection
[17:34] <teward> and I put all the old bugs as dupes of the new one :P
[17:34] <teward> not because it's an 'issue that still exists' but because the master is the new 'master' for those types of issues.  A little irregular, but it slices down the annoyingness of all the invalid bugs, and points to detailed reasoning for the problem and how to fix it
[17:34]  * teward shrugs
[17:34] <cprofitt> cool... it has been a while since I have done bug reports... so if that is the new process that is cool. Want to make sure I do not cause issues for not being up to speed.
[17:34] <teward> the process 'varies'
[17:35] <teward> cprofitt: if it were anything under my direct radar, though, yours would have been closed as a dupe of the newer one which has more info, but that's just me.  Feel free to poke Martin though since they closed it in the first place
[17:35] <teward> or take it to the mailing list
[17:35]  * teward goes back to poking two servers to try and get them to talk to each other
[17:36] <cprofitt> teward: poking rarely works ;)
[17:36] <cprofitt> for servers.
[17:36] <teward> (read as: "Threaten the servers with digital violence should the networking not come up")
[17:36] <teward> nah, it's probably me fubaring the firewall ACLs :P
[17:36] <cprofitt> oh... that works at times.
[17:37] <cprofitt> firewalls are fun :)
[17:37] <cprofitt> really ;)


[00:30] <czajkowski> reminder for folks http://www.lczajkowski.com/2010/10/23/the-business-value-of-open-source-software/
[09:30] <tdr112> morning
[09:33] <slashtom> good morning
[09:35] <tdr112> hey slashtom , how are things
[09:35] <slashtom> grand, yourself?
[09:35] <tdr112> grand , a bit busy ,
[12:05] <czajkowski> aloha


[03:38] <MTecknology> so.. I've been trying to sync data out to my linode for about 2.5hr now
[03:39] <MTecknology> fun..
[11:14] <geser> wgrant: is it intended that I get an email for "upload failed" from the recent archive rebuild?
[11:18] <wgrant> geser: No. Could you please forward it to me?
[11:21] <geser> wgrant: mailed
[11:23] <wgrant> geser: Thanks.
[11:24] <geser> the "error" is obvious but at first I was surprised why I got this mail at all
[11:24] <wgrant> Indeed, that's a bug.
[11:24] <wgrant> It may actually be fixed in the next revision in the deployment queue, I think.
[11:25] <wgrant> The build notification code has been in a bit of flux lately due to source package recipes.
[11:25] <geser> btw: is there a bug filed about timeouts viewing the archive rebuild page in LP? (OOPS-1855H1087)
[11:26] <wgrant> It's known.
[11:26] <wgrant> It should work after a couple of refreshes.
[11:26] <wgrant> As you might have noticed, it reuses the PPA UI.
[11:26] <wgrant> And that wasn't designed for something the size of the primary archive.
[11:26] <geser> today I was lucky and the 2nd attempt worked
[11:32] <wgrant> geser: So, I'm not sure why those rejections have never been sent before.
[11:32] <wgrant> They weren't meant to be.
[11:32] <wgrant> But the code says they should have been.
[11:35] <wgrant> Ah.
[11:35] <wgrant> I see.
[11:47] <wgrant> geser: https://launchpad.net/ubuntu/+archive/test-rebuild-20110125/+packages renders far faster than without +packages, FWIW.
[11:47] <wgrant> That shouldn't time out.
[11:48] <wgrant> The build counters ("Currently 26 packages building and 14388 packages waiting to build.") are the problem, and +packages doesn't have them.
[11:53]  * jelmer waves to wgrant
[11:54] <wgrant> Morning jelmer.
[12:52] <Hanmac> hello, i uploaded a source, but the build failed, and the log says it could not install the build bependencies "libgimp2.0-dev" because it depents libgtk2.0-dev BUT lunchpad did not install this ... what schould i do?
[12:53] <geser> have you the link to the build log?
[12:53] <Hanmac> http://launchpadlibrarian.net/63079835/buildlog_ubuntu-natty-i386.gimp-apng_0.1.0-1.1_FAILEDTOBUILD.txt.gz
[12:56] <Hanmac> i hope you see a error
[12:56] <geser> I might have an idea, checking it. One moment please
[12:57] <ari-tczew> Hanmac: Odd, your page shows none failures. https://launchpad.net/~hanmac/+related-software
[12:57] <geser> ari-tczew: check https://launchpad.net/~hanmac/+archive/ppa/+packages
[12:58] <geser> ari-tczew: looks like an LP bug
[13:05] <geser> Hanmac: I can reproduce it in my natty pbuilder with your PPA. It has something to do with your libpng but I didn't found out yet what exactly.
[13:07] <Hanmac> i thought the error was there:  "libgimp2.0-dev : Depends: libgtk2.0-dev (>= 2.12.5) but it is not going to be installed" so i need also the other dev package?
[13:08] <ari-tczew> Probably libgtk2.0-dev has got broken depends.
[13:08] <geser> Hanmac: when there is a dependency problem somewhere inside a dependency chain then apt only prints the first dependency but not the real problem
[13:11] <geser> Hanmac: the usual tactic I use in such cases to find the real problem: try installing the mentioned packages too (apt-get install) and see what happens. Repeat till the real problem is shown
[13:11] <geser> but it didn't work this time: http://paste.ubuntu.com/559879/
[13:12] <geser> once I explicitly added libcairo-dev to the list of packages to install it worked *puzzled*
[13:13] <geser> Hanmac: so a work-around seems to be to add "libcairo-dev" to Build-Depends, but I don't know why it works then
[13:16] <Hanmac> ok i thy it ... and i install a local builder to test the build later
[14:09] <Hanmac> you was right, it exist a bug in my png lib ... i nead a symlink libpng12.so.0 -> libpng15.so
[15:42] <fta> hm, got a bunch of ftbfs last night. but no build log, no email
[15:42] <fta> (ppa)
[15:58] <Hanmac> i uploaded something but i does not get a mail or it shows on my ppa site
[19:41] <Hanmac> i have problems with file in the .pc folder -> http://launchpadlibrarian.net/63103870/buildlog_ubuntu-natty-i386.gimp-apng_0.1.0-1.5_FAILEDTOBUILD.txt.gz but dbuild work with my system
[19:47] <Hanmac> some one an idea with the .pc files?
[23:10] <vex> .window move 11
[23:10] <vex> gah