[00:26] <mhall119> YoBoY: it'd be a pretty significant refactoring for us to be able to handle users that don't come from LP
[01:03] <mhall119> AlanBell: Mootbot-UK isn't in #ubuntu-us-fl anymore?
[03:30] <blahdeblah> mhall119: Is the first URL in the topic the same as the locoteams directory?  I've never heard of it.  Also, is it just for official locos?
[03:33]  * mhall119 checks the topic
[03:33] <mhall119> blahdeblah: no, that's just the launchpad group for locoteams
[03:33] <mhall119> http://loco.ubuntu.com is the loco directory
[03:33] <mhall119> and it's for approved and non-approved loco teams
[03:34] <mhall119> any team in launchpad that is also part of the ~locoteams team will be included in loco-directory
[03:34] <blahdeblah> so can anyone edit the agenda on http://loco.ubuntu.com ?
[03:35] <mhall119> you can only edit the agenda for a meeting for your team
[03:35] <mhall119> so, any team you're a member of, you can edit the agenda for
[03:35] <blahdeblah> How?  I'm logged in, and I'm a member of the team, but i can't see any tools for editing.
[03:36] <mhall119> what team?
[03:36] <blahdeblah> ubuntu-au
[03:36] <mhall119> oh, duh, should have guessed that
[03:36] <mhall119> does it have the correct username at the bottom of the page?
[03:36] <blahdeblah> I'm not too snobbish to answer when people ask the obvious... ;-)
[03:37] <blahdeblah> No username at all.  Just did a hard refresh and still nothing.
[03:37] <mhall119> hmmm, you sure you're logged in?
[03:37] <mhall119> mine has "Logged in as: mhall119"
[03:38] <mhall119> login link is at the top of the page, last item
[03:38] <blahdeblah> I clicked on join this team, it redirected me to launchpad, i clicked "yes, log me in", and it took me back to the team page, saying i am already a member.
[03:38] <mhall119> okay, what does it say at the bottom after "Logged in as:"
[03:38] <blahdeblah> hmmm... Evidently login and login are not the same
[03:39] <mhall119> ?
[03:39] <blahdeblah> I clicked the login link, it took me to another launchpad "yes, sign me in" page, and now i can see edit controls.
[03:40] <blahdeblah> Strange that it seems to have two levels of logged-in-ness
[03:40] <mhall119> huh...they should both work the same
[03:40] <mhall119> they use the same code, as far as i know
[03:40] <blahdeblah> well, they didn't
[03:40] <mhall119> :(
[03:40] <blahdeblah> never mind - it's working now
[03:40] <mhall119> :)
[03:41] <blahdeblah> So what are the great things that it allows us to re-use?
[03:41] <mhall119> well, in the near future, we'll be generating team reports with them
[03:42] <mhall119> there's also plans to integrate it with Mootbot-UK, so it will pull your next agenda item in for you, and post back a link to where it was discussed in the LD entry
[03:42] <mhall119> the "log url" field
[03:42] <blahdeblah> It seems to me that a wiki page is a lot more flexible than the few tiny little fields that "add agenda item" gives you
[03:42] <mhall119> flexible for putting stuff in
[03:42] <mhall119> not so much for getting stuff out
[03:42] <mhall119> the wiki is like a black hole of information
[03:43] <blahdeblah> I just wouldn't want to see the barriers to participation increased
[03:43] <mhall119> neither do we, which is why we want feedback on what barriers are encountered so we can remove them
[03:43] <blahdeblah> mhall119: Feedback: give us wiki integration for the agenda items :-)
[03:44] <mhall119> well, like I said, getting stuff out of a wiki is nearly impossible
[03:44] <mhall119> putting it back, well we can provide you markup to copy/paste, but the admins are pretty strict about adding plugins to the wiki
[03:45] <blahdeblah> copy/paste is non-viable - just give an option to include a wiki page's content as the agenda item's main content, instead of that tiny little 40x5 (or whatever it is) box
[03:45] <blahdeblah> (The 3rd one, that is: "Description")
[03:45] <mhall119> hmmm, how about if we make the input box bigger and accept wiki markup?
[03:46] <blahdeblah> *lots* bigger
[03:46] <mhall119> you should use Chrome
[03:46] <mhall119> it put's a resize grip on all textarea boxes
[03:47] <mhall119> but if you would be so kind as to file a bug, I'd be happy to increase the box size: https://bugs.launchpad.net/loco-directory/+filebug
[03:47] <blahdeblah> Meh.  When it's advanced enough for Canonical to replace Firefox with it, i might consider switching, but Firefox has too many useful plugins.
[03:47] <mhall119> handling wiki markup will take longer to implement
[03:47] <mhall119> but we should be able to integrate Creole
[03:48] <blahdeblah> s/put's/puts/ - that's the 2nd time today i've seen someone do that!
[03:48]  * blahdeblah pulls out the angry eyes >:o
[03:48] <blahdeblah> :-)
[03:48] <mhall119> pull's
[03:48] <blahdeblah> don't make me come down there!
[03:48] <mhall119> I know, and I'm married to an English major too
[03:48] <mhall119> shame on me
[03:48] <nigelb> heh
[03:49] <mhall119> blahdeblah: that'd be a lot of 'down', since I'm on the opposite side of the world
[03:49] <blahdeblah> :-D
[03:49] <nhandler> mhall119: The biggest issue I have with the LD is that it forces people to use two different systems: the LD for loco stuff and the wiki for all of their other teams.
[03:49]  * blahdeblah agrees
[03:49] <mhall119> nhandler: yeah, I don't like that either, which is why my next big project is opening up LD's features to all teams
[03:51] <blahdeblah> mhall119: What is the value of being able to query this stuff easily?  To allow some "big brother" monitoring of the locos?  I personally would never bother looking at our team's meeting history unless there was something that prompted me to search, and a wiki is good enough for that.
[03:51] <mhall119> blahdeblah: no big brother scenarios
[03:51] <mhall119> like I said, we want to automate team reports
[03:52] <mhall119> we want to integrate mootbot better
[03:52] <blahdeblah> How did i know that was going to be the first answer?  ;-)
[03:52] <blahdeblah> But for whom are the reports?  Why would they look at them?
[03:52] <mhall119> we want to provide useful data for people to make their own apps or mashups or what have you
[03:52] <mhall119> blahdeblah: team reports are something you should already be doing
[03:52] <mhall119> it lets the rest of the community know what's going on in other places/teams
[03:53] <blahdeblah> I can't think of a less interesting topic for an app/mashup than "what we did in April 2009".
[03:53] <mhall119> Ubuntu Weekly News makes use of team reports
[03:53] <blahdeblah> Even then, if it's anything more than 1-3 months old, it's historical interest only.
[03:54] <mhall119> probably, yeah
[03:54] <mhall119> oh, re-approval, it's very handy for team reapprovals
[03:54] <blahdeblah> Seems like a lot of trouble to go to for data that is not going to get queried much...
[03:54] <mhall119> ah, it was no trouble at all ;)
[03:54] <blahdeblah> Except for the people who are editing it... ;-)
[03:55] <mhall119> you don't _have_ to use LD if you don't find it useful
[03:56] <blahdeblah> Cool
[03:56] <blahdeblah> Just trying to understand your reasoning behind recommending it over the wiki
[03:56] <blahdeblah> I like the low-overhead, easy-add, flexible nature of wikis
[03:56] <mhall119> but if you _want_ to use it, we're happy to make improvements to make that easier
[03:56] <mhall119> if you find that you prefer the wiki way of doing things, then by all means keep using that
[03:56] <mhall119> sure
[03:56] <blahdeblah> at the moment, we're doing an awful lot of double/triple entry
[03:56] <mhall119> though, I can't remember the last time I got a timeout after posting to LD
[03:57] <blahdeblah> One of head_victim's bugbears is we don't seem to have a way to share the same event data between, say, LD, wiki, web site, and Facebook.
[03:58] <mhall119> well LD provide ical, rss and JSON feeds of all it's data
[03:58] <mhall119> surely your website and facebook can use one of those
[03:58] <blahdeblah> I don't believe Drupal has any way to import iCal data automatically.
[03:58] <mhall119> it can import rss though
[03:58] <blahdeblah> (At least, not the severely limited version Canonical provides)
[03:58] <mhall119> I'd be willing to bet someone's made an ical importer for it
[03:59] <blahdeblah> I'd be willing to bet it requires manual intervention, too ;-)
[03:59] <mhall119> do you use a specific Drupal module for calendar data?
[03:59]  * blahdeblah checks
[03:59] <mhall119> if so, we can perhaps write some code to integrate it with LD
[04:00] <mhall119> https://wiki.ubuntu.com/LoCoDirectory/API/Clients already has the start of a PHP client library
[04:01] <blahdeblah> looks like we use the "Basic Event" module.
[04:01] <blahdeblah> And we're on drupal 5.22 which is pretty old i understand
[04:02] <mhall119> yeah, I think they just came out with 7 or something
[04:02] <blahdeblah> yeah
[04:03]  * mhall119 isn't much of a drupal developer
[04:03] <blahdeblah> me neither
[04:03] <mhall119> but http://drupal.org/project/event says it has an API to store event data
[04:03] <mhall119> so that + LD client library + whatever drupal uses for scheduled updates
[04:03] <mhall119> should give you integration
[04:04] <blahdeblah> apparently, there are no scheduled updates
[04:04] <blahdeblah> cron was last run 5 weeks ago
[04:04] <blahdeblah> I would have thought Canonical's hosting would provide some mechanism to do that
[04:04] <mhall119> http://drupal.org/node/286938 makes it sound like it can import ical
[04:05] <mhall119> blahdeblah: I'm not sure what they offer, sorry
[04:06] <blahdeblah> Does look interesting
[04:06] <mhall119> but again, LD lets us provide this data in a usable form (3 forms, actually), while the wiki does not
[04:06] <blahdeblah> Anyway, thanks for your help, mhall119 - i'm sure head_victim will have more to say about all this.
[04:07] <mhall119> thanks for your input, I look forward to fixing your bugs :)
[04:07] <blahdeblah> :-P
[04:07] <mhall119> we can't fix what isn't reported
[04:09] <blahdeblah> https://bugs.launchpad.net/loco-directory/+bug/715581
[04:09] <ubot4> Launchpad bug 715581 in loco-directory "Agenda item description field is too small (affects: 1) (heat: 6)" [Undecided,New]
[04:10] <mhall119> blahdeblah: which is more important for you, vertical space or horizontal?
[04:11] <blahdeblah> yes
[04:11] <blahdeblah> ;-)
[04:11] <mhall119> portrait or landscape?
[04:11] <mhall119> can't say 'yes' to that :P
[04:15] <blahdeblah> mhall119: Personally, i would prefer more width, because most screens nowadays are 16:9 or 16:10 aspect ratio, but others might see it differently.  I would say at least 3 times wider and 2 times taller than it currently is.
[04:16] <mhall119> hmmm, that might be too big for most other teams...
[04:16] <mhall119> usually they just use a single line for an agenda item
[04:16] <mhall119> the description field was really only for short descriptions
[04:17] <blahdeblah> Evidently ;-)
[04:17] <mhall119> what are you planning on storing in it?
[04:17] <blahdeblah> If people are going to take the time to prepare for the meeting by adding structured agendas, they will probably want to write 3 or 4 sentences about their item, IMO.
[04:18] <mhall119> https://wiki.ubuntu.com/AustralianTeam/Meetings sayd "first a half line subject, followed by a short description as a sub-point of the subject, and signing it with your wikiname or IRC nick after that"
[04:24] <mhall119> 3 or 4 sentences will probably be the max
[04:24] <mhall119> we don't need a 6x size increase to contain that
[04:24] <mhall119> https://wiki.ubuntu.com/AustralianTeam/Meetings/2011February8 would easily fit
[04:24] <mhall119> I think doubling the width and height should be sufficient
[05:31] <head_victim> mhall119: the idea will be to do that but the team isn't used to it yet so I'm going to introduce it slowly
[05:34] <head_victim> Make sure everyone knows what it is, where it is and how to use it before it's the only thing in use.
[08:01] <dholbach> good morning
[08:21] <AlanBell> mhall119: mootbot-uk appears to be down. Daviey runs that one, I just hacked it together.
[08:22] <Daviey> *sigh*
[08:25] <Daviey> should be back
[12:17] <mhall119> thanks Daviey
[17:06] <Ronnie> evening
[17:28] <leoquant> evening Ronnie
[17:28] <leoquant> (response time?)
[17:28] <Ronnie> hey leoquant, also in this channel :P
[17:29] <leoquant> ツ
[19:32] <Ronnie> YoBoY: do you know more teams which have the same LP setup as ubuntu-fr (that the team_owner and team_admins are teams itself?)
[19:32] <Ronnie> i have a bugfix for this, and want to check this
[20:07] <YoBoY> Ronnie: http://loco.ubuntu.com/teams/ubuntu-it
[20:18] <Ronnie> thx YoBoY, looks like thats working too
[20:20] <Ronnie> YoBoY: http://img225.imageshack.us/i/schermafdruk1d.png/
[20:22] <YoBoY> Ronnie: great... but i'm not really sure... if your patch can provide the full list of a team, the "team contact" become useless or redundant, no ?
[20:52] <dscassel> <?xml version="1.0" encoding="UTF-8"?>

This test script was made to automate HUNTAR test case ID 5103 in the 10.0.1 Waterloo backplane.</selenium-comment>
Navigate to the User and Groups page before begining to execute and be logged in with Admin credentials.</selenium-comment>
oegroup creation</selenium-comment>
[20:52] <dscassel> <assertTitle parameter="target=Users and Groups, value=" keyword="false" description="Gets the title of the current page."/>
[20:52] <dscassel> <click parameter="target=ui=livelink::user:userAddItemSelect(), value=" keyword="false" description="Clicks on a link, button, checkbox or radio button. If the click action
causes a new page to load (like a link usually does), call
waitForPageToLoad."/>
[20:52] <dscassel> <clickAndWait parameter="target=ui=livelink::user:addGroup(), value=" keyword="false" description="Clicks on a link, button, checkbox or radio button. If the click action
causes a new page to load (like a link usually does), call
waitForPageToLoad."/>
[20:52] <dscassel> <assertTitle parameter="target=Content Server Create Group, value=" keyword="false" description="Gets the title of the current page."/>
[20:52] <dscassel> <type parameter="target=GroupName, value=oegroup" keyword="false" description="Sets the value of an input field, as though you typed it in.

Can also be used to set the value of combo boxes, check boxes, etc. In these cases,
value should be the value of the option selected, not the visible text."/>
[20:52] <dscassel> <clickAndWait parameter="target=ui=livelink::submitBtn(), value=" keyword="false" description="Clicks on a link, button, checkbox or radio button. If the click action
causes a new page to load (like a link usually does), call
waitForPageToLoad."/>
[20:52] <dscassel> <assertTitle parameter="target=Content Server Group Members Info, value=" keyword="false" description="Gets the title of the current page."/>
[20:52] <dscassel> <selectFrame parameter="target=EditGroup, value=" keyword="false" description="Selects a frame within the current window.  (You may invoke this command
multiple times to select nested frames.)  To select the parent frame, use
"relative=parent" as a locator; to select the top frame, use "relative=top".
You can also select a frame by its 0-based index number; select the first frame with
&quot
[20:52] <dscassel> <clickAndWait parameter="target=ui=livelink::doneBtn(), value=" keyword="false" description="Clicks on a link, button, checkbox or radio button. If the click action
causes a new page to load (like a link usually does), call
waitForPageToLoad."/>
Client group creation</selenium-comment>
[20:52] <pleia2> !ops
[20:52] <ubot4> Help! Channel emergency! (ONLY use this trigger in emergencies) - elky, Madpilot, tritium, Nalioth, tonyyarusso, PriceChild, Amaranth, jrib, Myrtti, mneptok, Pici, jpds, gnomefreak, bazhang, jussi, Flannel, ikonia, maco, h00k, IdleOne, nhandler, bilalakhtar, Jordan_U, or rww!
[20:53] <dscassel> <selectWindow parameter="target=null, value=" keyword="false" description="Selects a popup window using a window locator; once a popup window has been selected, all
commands go to that window. To select the main window again, use null
as the target.

Window locators provide different ways of specifying the window object:
by title, by internal JavaScript "name," or by JavaScript variable
[20:53] <dscassel> Apologies. right click paste gets me every time.
[20:53] <pleia2> might want to look into flood protection if your client has it :)
[20:53] <pleia2> (irssi has saved me!)
[20:54] <dscassel> pleia2: It prevented another 11 lines from being pasted in. :P
[20:54] <pleia2> ah
[20:58] <mhall119> irssi saves me from paste flooding moore than I'd like to admit
[20:59] <Pici> pleia2: still need help?
[20:59] <pleia2> Pici: no, flood has ended :)
[20:59] <pleia2> thanks anyway
[21:00] <Pici> np
[21:11] <Ronnie> mhall119: is #688064 is committed into production? if so, the status should be changed to "fix released"
[21:13] <cjohnston> bug 688064
[21:13] <ubot4> Launchpad bug 688064 in loco-directory "Add meetings to 'upcoming events' on team's pages (affects: 1) (heat: 4)" [Wishlist,Fix committed] https://launchpad.net/bugs/688064
[21:14] <cjohnston> yes it is
[21:14] <cjohnston> want to fix it Ronnie ?
[21:14] <Ronnie> ill change it. i just needed a confirm
[21:15] <cjohnston> :-)
[21:17] <mhall119> Ronnie: +1
[21:17] <mhall119> good catch
[21:17] <Ronnie> just working trough my assigned bug ;)
[21:18] <Ronnie> a few to go
[21:19] <Ronnie> mhall119: any progress on django foundations lately?
[21:20] <Ronnie> cjohnston: if you have time, can you review this bug 712569. i need this fix also for another bug and dont want to create conflicts
[21:20] <ubot4> Launchpad bug 712569 in loco-directory "meetings ical does not use python-vobject (affects: 1) (heat: 6)" [Undecided,In progress] https://launchpad.net/bugs/712569
[21:21] <mhall119> Ronnie: no, I haven't had a chance to do much of anything lately
[21:21] <mhall119> been busy with a new project at work
[21:21] <Ronnie> oke, is there anything i can help to get the foundations running?
[21:24] <mhall119> the next step is writing a "getting started" guide
[21:25] <Ronnie> is the project already that far?
[21:26] <mhall119> probably not
[21:26] <mhall119> :)
[21:26] <mhall119> but writing the guide will tell us where it's not ready
[21:26] <Ronnie> whats for example the method for adding urls to the root urls.py (manually?) and what with the media directory of imported branches, they need to be linked
[21:27] <mhall119> yup, all that needs to be decided and documented
[21:28] <Ronnie> i think that will be difficult stuff
[21:29] <Ronnie> at least for what i noticed with the google map sample
[21:42] <Ronnie> daker, mhall119: looking at this bug 712569 . does the language menu needs translation ? i guess its very hard to find my language if the name of the language is translated in chinese
[21:42] <ubot4> Launchpad bug 712569 in loco-directory "meetings ical does not use python-vobject (affects: 1) (heat: 6)" [Undecided,In progress] https://launchpad.net/bugs/712569
[21:42] <Ronnie> oops: bug 648296
[21:42] <ubot4> Launchpad bug 648296 in loco-directory "Languages in language selector should be listed alphabetically (affects: 1) (heat: 4)" [Wishlist,In progress] https://launchpad.net/bugs/648296
[21:46] <daker> Ronnie, if you could look at my branch https://code.launchpad.net/~daker/loco-directory/ld-languages-menu
[21:47] <daker> and see what's the problem with it
[21:47] <Ronnie> i was looking at the diff, usually much easier to understand
[21:47] <daker> ok
[21:48] <Ronnie> but as far is i understand you look for the translation file to lookup translations for the languages
[21:49] <Ronnie> but i think the languages should not be translated for each country (the language should be written in the language itself)
[21:50] <daker> they are not translated
[21:51] <Ronnie> can we translate them ourself (with help of the loco's) once and put them hardcoded into the db?
[21:53] <daker> not sure, the languages are taken from LP
[21:54] <daker> cjohnston, mhall119  what do you think ?
[22:29] <Ddorda> guys, say, i'm willing to ask for canonical sponsorship for the uds
[22:29] <Ddorda> i saw "Would you be willing to participate as member of the crew?", what crew?
[22:32] <nhandler> Ddorda: The crew helps out with keeping everything running smoothly at the events (i.e. making sure people are where they need to be, that the rooms have all of the proper equipment, help with the video and audio streams of the sessions, and other work that gets done) at least from what I've heard from discussions
[22:32] <Ddorda> nhandler: hm.. i guess i don't mind taking part in that, not sure how much i can help :P
[22:34] <cjohnston> Ddorda: sponsorship isnt open yet
[22:34] <cjohnston> Daviey: ^^
[22:34] <daker_> Ddorda, A crew is a body or a class of people who work at a common activity
[22:34] <Ddorda> cjohnston: well, as much as i see it is :O
[22:35] <Ddorda> daker_: i know what crew is
[22:35] <cjohnston> it isnt..
[22:35] <Ddorda> i meant what it will be doing
[22:35] <cjohnston> the app is broken
[22:35] <cjohnston> it shouldnt show the application yet
[22:35] <Ddorda> cjohnston: http://summit.ubuntu.com/uds-o/sponsorship/
[22:35] <Ddorda> this one?
[22:36] <cjohnston> correct.. it shouldnt yet show the application.. there is a patch submitted
[22:36] <cjohnston> waiting for it to be aplied
[22:36] <Ddorda> well, it worked for me :x
[22:37] <daker_> Lol
[22:37] <Ddorda> erm..
[22:37]  * Ddorda scratches his head
[22:38] <Ddorda> well, if it worked, it worked, right?
[22:38] <Ddorda> or i should refill everything soon?
[22:38] <daker_> you will be the first one to apply xD
[22:38] <Ddorda> daker_: seem so :P
[22:38] <cjohnston> they will prolly disregard any that are sent in prior to it being open
[22:38] <cjohnston> daker_: there have already been others
[22:40] <Ddorda> cjohnston: too bad, i wrote the "why me" part for long time :x
[22:42] <Ddorda> cjohnston: i'll get "released" when the new version will come out?
[22:42] <cjohnston> ?
[22:42] <Ddorda> cjohnston: "You've already requested sponsorship to uds-o. If you have....."
[22:44] <cjohnston> my understanding is that it isnt open.. im trying to verify now.. i dont know what will happen to the app if its done prior to sponsorship being accepted
[22:44] <Ddorda> so do you have any idea if when the new page comes out i'll be able to refill it?
[22:44] <cjohnston> dunno
[22:44] <Ddorda> cjohnston: okay, thank you
[22:45] <Ddorda> cjohnston: if you'll anything further can you PM it to me or something?
[22:45] <Ddorda> I wanna be updated :P
[22:45] <cjohnston> sure
[22:45] <Ddorda> cjohnston: thanks
[22:45] <Ddorda> going to sleep now. g'night folks :)
[23:49] <mhall119> UDS sponsorship is not open yet
[23:50] <mhall119> IIRC, any applications sent now will likely sit and wait until the sponsorship period opens and closes, you don't get any priority by being in there first
[23:54] <mhall119> AlanBell: where's the mootbot-uk code hosted?


[07:43] <Speedy2> www.search2.net
[07:44] <elky> Is that a typo or are you spamming us?
[07:44] <vish> elky: spam
[07:44] <elky> it does appear that now
[07:45] <vish> elky: i'v just reported it to the ops, its been happening in several channels
[07:46] <elky> Yeah, i noted. I was going to see if they were a human who could be reasoned with.
[07:49] <dholbach> good morning
[18:00] <mdeslaur> jdstrand, kees: meeting?
[18:01] <kees> mdeslaur: ah, yes.  it's that time, isn't it?
[18:01] <kees> jdstrand: ready?
[18:01] <mdeslaur> kees: my calendar thinks it is :)
[18:01] <jdstrand> o/
[18:01] <kees> :)
[18:01] <jdstrand> yes
[18:01] <kees> okidoky
[18:01] <kees> this week, OOo publication, and then going to check for any low-hanging fruit
[18:02] <persia> If there's time in the agenda, can I grumble a bit about community integration at the end?
[18:02] <kees> I'd like to finish some of the qrt stuff I had on my plate (like the additional RNG tests)
[18:02] <kees> persia: totally
[18:02] <mdeslaur> persia: yes
[18:02] <persia> THanks.
[18:02] <kees> probably going to start another kernel update cycle soon too
[18:03] <kees> looks like we made feature freeze pretty well.
[18:03] <kees> that's it from me.  mdeslaur, you're up.
[18:03] <mdeslaur> I just published pidgin updates. I plan on attacking the new squid issue, and the ffmpeg updates next.
[18:04] <mdeslaur> besides that, I'm on community, so have been going down the sponsoring list
[18:04] <mdeslaur> that's pretty much it
[18:04]  * jjohansen fades in late
[18:04] <jdstrand> so I guess I'm up next
[18:05] <jdstrand> I am triager this week
[18:06] <jdstrand> I plan to talk to soren walk me through kvm-autotest to see how we can use it in QRT for our gui applications. it should be totally doable
[18:06] <kees> oooh, I was just thinking about that today in the shower -- I wanted to see if I could build an OOo test
[18:06] <jdstrand> kees: exactly (though for me it was firefox)
[18:07] <kees> I worry about use having different resolutions, languages, installed applications in our VMs, though.
[18:07] <mdeslaur> wouldn't Mago be more appropriate for that?
[18:07] <jdstrand> I looked at it a it on my own last week, but it was not...
[18:07] <jdstrand> obvious...
[18:07] <kees> yeah
[18:07] <jdstrand> how to use it in that capacity
[18:07] <jdstrand> soren gave that presentation at the sprint and seems to think it shouldn't be a problem-- so I'm hopeful :)
[18:08] <persia> Mago requires accessibility support.  kvm-autotest requires reliable display parameters (which kvm can provide).
[18:08] <jdstrand> mdeslaur: I looked at Mago a bit, but didn't find documentation on how to really get into it
[18:08] <jdstrand> plus what persia mentioned
[18:08]  * robbiew sneaks in the back door :/
[18:09] <mdeslaur> I'm just kind of afraid with kvm-autotest that it will be hard to always have a 100% reproducable environment
[18:09] <jdstrand> I plan to see what is next on the 'what CVE to fix next' list, and do that
[18:09] <jdstrand> mdeslaur: I think we can with snapshots, etc
[18:10] <jdstrand> mdeslaur: anyway, I'm investigating right now, not integrating :)
[18:10] <mdeslaur> ok, fair enough :)
[18:10] <mdeslaur> jdstrand: don't forget, I run my VMs at 1920x1080
[18:10] <jdstrand> mdeslaur: if you have some good resources for mago, I'd like them too
[18:10] <kees> jdstrand: if you start getting somewhere with it, let me know and I can "reproduce locally"  :)
[18:10] <kees> mdeslaur: seriously?
[18:10] <mdeslaur> kees: no
[18:10] <kees> hah
[18:11] <jdstrand> mdeslaur: well, I take you point. these would likely have to be 'special' VMs anyway (ie, kvm-autotest and libvirt doesn't make sense afaict)
[18:11] <mdeslaur> oh, okay
[18:11] <jdstrand> but anyway, we'll see-- I just thought there might be something there, and soren is willing to walk me through it
[18:12]  * kees hopes to re-use the libvirt-configured VMs
[18:12] <mdeslaur> jdstrand: don't forget to bug soren as much as possible while he's still on the payroll :)
[18:12] <jdstrand> kees: me too... we'll see
[18:13] <jdstrand> I might be able to wrap stuff, etc, like I did with vm-tools. but like I said, I've barely looked at it :)
[18:13] <jdstrand> anyhoo
[18:14] <jdstrand> if I have time, I'd like to see if I can clean up the apparmor abstractions, esp for firefox/evince
[18:14] <jdstrand> that's it for duties. I do have two items to bring up-- one is I'm fairly sure related to what persia wants to talk about
[18:14] <jdstrand> persia: why don't you go ahead?
[18:15] <persia> Probably :)
[18:15] <persia> OK.  jdstrand and I have been having a productive conversation in a thread at https://lists.ubuntu.com/archives/ubuntu-motu/2010-February/006550.html
[18:15] <persia> Summarised, the TB and DMB have approved a proposal that significantly limits the scope of "MOTU".
[18:16] <persia> So, since "MOTU" no longer maps well to "community supported", I'd like to see some initiative from the wider security team (potentially including current members of MOTU SWAT) to define a process that supports the entire archive wihout relying on the scope of MOTU.
[18:19] <kees> sounds good to me.
[18:19] <jdstrand> that makes sense to me, but, tbh, it is clear to me how "community supported" is being defined in the new world. I guess "not in officially supported" is one definition, but there then is a team surrounding "not officially supported"
[18:19] <jdstrand> err
[18:19] <jdstrand> s/is/isn't/
[18:19]  * persia much prefers "not supported by Canonical" to "not officially supported", but yes, this needs thought.
[18:19] <jdstrand> fair enough
[18:19] <kees> we'll have the help of the Supported: tag in the packages files
[18:20] <persia> It's going to be a bit before everything is implemented, so there's time, but it seems appropriate to start thinking about it now so that we don't get caught later.
[18:20] <jdstrand> yeah, that defines our responsibilities
[18:20] <mdeslaur> persia: Is there anything you see that would need changing in our current process?
[18:21]  * kees mumbles something about syncSource ACLs in LP
[18:21] <jdstrand> persia: also, not pointing fingers or being judgemental, but motu-swat has not been active for a while. the reasons are numerous and in part due to lack of process from ubuntu-security (which should all be fixed now)
[18:21] <persia> mdeslaur: Were I designing the process, and noting that my understanding of your process is entirely based on jdstrand7s email, I'd probably only do the following:
[18:21] <kees> no amount of our process can reduce the bottleneck that is LP's lack of ACLs, though.
[18:22] <persia> 1) declare an inclusive security group with responsibility for everything (although some members may concentrate in certain areas).
[18:22] <kees> but, outside of that, I'd agree: we've tuned the process to eliminate human bottlenecks as much as possible
[18:22] <persia> 2) encourage all members of that group to actively review and sponsor stuff.
[18:22] <jdstrand> kees: yes, but if more people submitted patches and more people joined ubuntu-security-sponsors, I think we could handle the publishing bits ok
[18:22] <persia> 3) have a restricted set that is responsible for pocket copies and USN releases.
[18:22] <jdstrand> (I'd love to see the volume of community supported patches be a real problem for us)
[18:23] <persia> I think that's mostly a matter of making sure submitters feel entitled as part of the team.
[18:23] <mdeslaur> persia: this is the team that has responsibility of reviewing everything: https://launchpad.net/~ubuntu-security-sponsors
[18:23] <persia> I know that when we do stuff in MOTU that involves telling people that submitting patches makes them Ubuntu Developers, we get more patches.
[18:23] <kees> persia: 3 exists, 2's element of "encourage" hasn't happened, though we've asked the community team for help there. 1 exists as ubuntu-security-sponsors, IIUC
[18:24] <persia> kees: I think you're right, and that it's just a matter of semantics and communication.
[18:24] <jdstrand> well, the ubuntu-security team itself is how it is due to ACLs and requiring the possibility for embargoed issues.
[18:24] <jdstrand> it could I guess be a subteam in this whole thing...
[18:25] <jdstrand> kees: your understanding is correct on '1'
[18:25] <kees> persia: our problem has traditionally been that of motivating others; we're usually utterly slammed for time, and doing coaching, blogging, etc can be very time-consuming.
[18:25] <jdstrand> keep in mind, that the new process for sponsoring security uploads is just that: new this cycle. I personally wanted to see how it worked for a little bit to make sure it was sane
[18:26] <jdstrand> however, we are fully integrated into the MOTU pages now-- from dholbach's reports, to Sponsoring pages to how you can help
[18:26] <persia> I understand entirely :)  I just wanted to raise the point, because while I think all the process stuff jdstrand mentioned in the email was good, I found some of the phrasing and language exclusive, and based on previous meeting logs, though it was pervasive in the sematics of the team, rather than being jdstrand's email.
[18:26] <jdstrand> the only thing that wasn't done was an email to ubuntu-motu@ and ubuntu-devel@
[18:27] <mdeslaur> persia: right now, we always have one team member who is on active community-sponsoring duty, so if a bug is opened and a debdiff submitted, it will get reviewed and uploaded in a few days.
[18:27] <persia> mdeslaur: Right.  I think that's great.  I just want to highlight that there are likely to be other groups than MOTU active in universe, and that this probably has implications related to the semantics of your communications.
[18:29] <jdstrand> persia: there is a difference between canonical supported and community supported, and a necessary exclusivity in some ways-- it is our team's job to take care of canonical supported pacakges. our name is on the USN, it is in the emails to bugtraq, etc. in some ways, submitting a debdiff for a package in main is a lot like just giving us a VCS link to a fix
[18:29] <jdstrand> persia: that said, I don't want to appear as exclusive
[18:29] <persia> Heh.
[18:30] <persia> I understand the difficulty, and don't want to complicate things :)
[18:30] <jdstrand> that didn't come out quite right
[18:30] <jdstrand> I want people involved, but there is very much a difference between a community supported package and a canonical supported, from our point of view
[18:30] <persia> There are differences between the set of things that is done related to embargoes and USNs and pocket copies.
[18:30] <jdstrand> I'm not sure that matters though-- there is so much to do in community supported packages that just isn't happening now
[18:31] <persia> I'm less confident there's a meaningful difference between "main" and "universe" for stuff that isn't embargoed.
[18:31] <persia> (because any dev can upload it)
[18:31] <kees> there is -- it's an SRU
[18:31] <jdstrand> persia: are we talking about stable releases or devel?
[18:31] <kees> so, when something goes into main, we're responsible for it.
[18:31] <persia> Don't you do both?
[18:31] <jdstrand> persia: stable and devel? yes
[18:32] <jdstrand> persia: but we are directly responsible for main/restricted
[18:32] <jdstrand> for stable
[18:32] <jdstrand> in fact, a supported configuration is running an Ubuntu system with -security but without -updates
[18:33] <persia> Right.  I think we havea  close to common understanding of stuff.
[18:33] <persia> I agree there needs to be a distinction for certain folks active in security.
[18:33] <jdstrand> sure-- I think it is perhaps a matter of perspective, and my language is tainted by my perspective
[18:34] <persia> I just think there needs to be a distro-wide security team of some sort (which may well be ubuntu-security-sponsors) that is highlighted as a central team, rather than relying on each developer team to grow it's own security folk.
[18:34] <persia> Mine too :)
[18:34] <kees> I'm actually not convinced that's the right thing to do.
[18:34] <kees> I think each developer team needs to know how to handle stable security updates.
[18:35] <kees> they're much more familiar with the code and how to test
[18:35] <persia> OK.  How do we deal with security for stuff not handled by the restricted set of security developers then?
[18:35] <kees> I'm not saying we shouldn't have a general security team, but I don't think we should discourage security work by devel teams
[18:35] <persia> can we convince each team to grow a security representative?  Or would we do better to have a central coordnation team that reached out when CVEs were published?
[18:36] <persia> Just as a semantic note: I consider teams to be massively overlapped, so I'd hope that individual developers might participate in several teams.
[18:36] <kees> I think each team should at least have a security representative -- perhaps the same person that deals with SRUs.
[18:36] <jdstrand> kees: I was not trying to discourage anyone, and would hope that people from the dev teams would provide patches for their stuff (with testing)
[18:37] <kees> jdstrand: right, i was replying persia's "rather than relying on each developer team to grow it's own security folk."
[18:37] <persia> OK.  This could work.  In that case, there *should* be a MOTU swat, but each developer team should also havea  similar body.
[18:37] <jdstrand> ah
[18:37] <kees> since I *do* want devteams to grow security folk
[18:38] <kees> persia: I think that would be ideal, yes.  however, we've had a very hard time growing either type of person.  :)
[18:38] <persia> I don't think we need to continue having a hard time :)
[18:38] <persia> Just petition the tech board to add a requirement that devteams nominate some -security and -updates contacts.
[18:38] <jdstrand> the devel release is often much more exciting than a stable release for most people
[18:39] <kees> persia: how would that be tracked in LP/
[18:39] <persia> And that those contacts are expected to participate in discussions with the central -updates and -security teams (so they'd be at this meeting).
[18:39] <kees> s#/#?#
[18:39] <persia> kees: Nominees would be added to ubuntu-security-sponsors and fill roles similar to that of motu swat today.
[18:40] <kees> I'm looking for a way for an outsider to answer the question "who is the security contact for [team]?" when looking at LP.
[18:40] <jdstrand> persia: so anyone could provide the debdiff (including the devteam) and then the rep from the devteam in ubuntu-security-sponsors could ack it
[18:40] <jdstrand> ?
[18:41] <persia> kees: A wiki page?
[18:41] <persia> jdstrand: And with luck the security rep from the devteam helps in other ways, but yes.
[18:41] <kees> persia: okay, seems disconnected from LP a bit, but it's the best we've got.
[18:41] <persia> kees: The other alternative is to have special teams like ubuntu-desktop-security, but I don't think that scales.
[18:41] <kees> the issue is finding someone that can help with testing.  no one likes testing ancient stable releases.  :(
[18:42] <persia> LP needs to get smarter before we have that feature.
[18:42] <persia> That's why you get the TB to require devteams to nominate someone :)
[18:42] <jdstrand> yeah, last stable is about as far back as people like to test
[18:42] <kees> I want to avoid this person from becoming a bottleneck, though, and I worry that might become socially tricky.
[18:43] <kees> "You never checked with me about this patch!"   "You weren't online."  etc
[18:43] <jdstrand> I can imagine an ack on a patch, but waiting on testing
[18:43] <persia> kees: Could we work around that by a combination of "Ubuntu doesn't have maintainers" and allowing a devteam to nominate several members rather than one if coordination may be an issue?
[18:43] <jdstrand> kees: I think that should be solved be our sponsorship process
[18:44] <jdstrand> (it, ACKs, etc in LP)
[18:44] <kees> I guess my entire opinion is best summarized by "I would love more people participating, but since that number is approaching zero, I see no reason to impose groups/lists/etc"
[18:44] <persia> Fair.  I'm just concerned about the packages that are no longer cared for by MOTU slipping through the cracks.
[18:45] <mdeslaur> kees: I agree with that...once we actually _get_ debdiffs we can start looking how to increase sponsoring, etc.
[18:45] <kees> wel, to be honest, they already are slipping through the cracks.
[18:45] <persia> OK, maybe I'm approaching this from the wrong direction then.
[18:45] <persia> (and feel free to change topic if time is short)
[18:45] <kees> stefanlsd and jstrand helped a great deal to close the crack with the sync-finder and sync-doer, though
[18:46] <persia> Perhaps we ought think about "How do we extend the security process to more actively encourage patch submissions from devteams to the security team?"
[18:46] <jdstrand> persia: that is the question
[18:46] <kees> but, I mean, the list is huge even after that: http://people.canonical.com/~ubuntu-security/cve/universe.html
[18:47] <persia> As long as we answer that question in a way that works with Archive Reorg, all my concerns about MOTU SWAT are resolved.
[18:47] <jdstrand> persia: that is what we tried to do with our recent procedural changes (so it isn't a wholly new process)
[18:47] <kees> persia: right, I like that.  I like _anything_ that'll get more people helping.
[18:47] <persia> OK.  So, I suggest that explicity expecting devteams to actively track at least open CVEs in their packagesets is a place to start.
[18:48] <persia> Until MOTU's responsibility gets smaller, I'm unsure MOTU SWAT can keep up, but it sets a model that means that as new devteams are formed, they are already participating in the process.
[18:48] <james_w> integration with harvest could be a good idea
[18:48] <persia> That also skips the requirement for specific nominees, etc. (although if you add a request to report in this meeting, a natural nominee will likely emerge)
[18:50] <kees> persia: yeah, I do like the idea of solidifying "expecting devteams to actively track at least open CVEs in their packagesets"
[18:51] <jdstrand> I'm not sure what that will get us, but we'll see
[18:51] <persia> kees: And would you be willing to add "expecting devteams to report on the progress of such tracking during the weekly security team meeting"?
[18:51] <kees> persia: sure, I guess that would be good.
[18:52] <persia> Well, that combination matches my preferred mental model well enough that I'm completely satisfied :)
[18:52] <kees> persia: where should these suggested idea be presented?  TB or DMB?
[18:52] <kees> I assume TB
[18:53] <persia> TB: it'S the TB that is responsible for approving devteams.  The DMB only approves membership changes in devteams if so delegated.
[18:53]  * kees nods
[18:53] <persia> jdstrand: did you have anything else on this, or shall we move to the second of your "two things"?
[18:54] <jdstrand> persia: I'm pretty much of the same mind as everyone-- more involvement is good. how we get there is rather secondary to me
[18:55] <kees> persia: I've added this to the TB agenda now: https://wiki.ubuntu.com/TechnicalBoardAgenda
[18:55] <jdstrand> simply put, I don't have anything else
[18:55] <persia> kees: Excellent :)
[18:55] <kees> jdstrand: oh, I thought you had a second item, non-overlapping with persia?
[18:56] <jdstrand> kees: I do, I was letting go of persia's sleeve is all
[18:56] <kees> hah, ok
[18:56] <jdstrand> the other thing is a bit of a clarification on security support in -backports
[18:56] <jdstrand> specifically bug #411849
[18:57] <jdstrand> my understanding was that it is up to the backports team to do this type of thing
[18:57] <kees> I agree 100%
[18:58] <jdstrand> alright, so, so I guess that is it on that then
[18:58] <jdstrand> ubuntu-security got dragged into that bug and it seemed at least worth reviewing
[18:58] <kees> jdstrand: yeah, backports is not our problem in the least, IMO.
[18:59] <jdstrand> I agree (and responded as such in the bug)
[18:59] <kees> if anyone feels differently, I'm all ears, but my operating principle has been to ignore -backports totally.
[18:59] <kees> okay, cool
[19:00] <kees> anyone have anything else?
[19:00] <mdeslaur> not me
[19:00] <kees> thanks everyone!
[19:01] <jdstrand> o
[19:01] <jdstrand> o/


[12:00] <ogayot> Hi, we have a package (kitty) that calls mlock(2) multiple times as part of the build-time test suite. On ppc64el builders, the pagesize is 64k and the RLIMIT_MEMLOCK is set to 64k too. So only a single call to mlock() can succeed. Would it be realistic to bump the RLIMIT_MEMLOCK value? Thanks!
[12:27] <ogayot> (for now, I'll just disable the test if the limit is too low)
[12:50] <cjwatson> ogayot: In the past I've resisted making this sort of tweak specifically to the builder environment.  My reasoning is that if a build-time test requires some property of the system, and we tweak that just for builders, then it means that the tests are a less accurate reflection of what will actually work when the package is installed on a real system.
[12:51] <cjwatson> ogayot: If we need different limits, we should consider either (a) changing systemd or whatever to have different defaults, or (b) changing the package to have requirements that are more consistent with the systems we actually ship.
[12:52] <cjwatson> (IMO anyway
[12:52] <cjwatson> )
[12:53] <ogayot> cjwatson: yes that makes sense. I like the idea of having systemd set more sensible values by default. I'll keep the test disabled for now. Thanks!
[19:29] <sarnold> cjwatson: how about upgrading the builders to 22.04 or newer? I think the limits were raised
[19:29] <sarnold> max locked memory           (kbytes, -l) 33002300
[19:29] <sarnold> max locked memory           (kbytes, -l) 7939824
[19:29] <sarnold> I suspect it's now a fraction of installed memory size
[19:30] <cjwatson> sarnold: actually in progress :)
[19:30] <cjwatson> just kept getting bumped by other things
[19:30] <sarnold> cjwatson: yay! :D
[19:30] <sarnold> I'm familiar with that :(


[01:10] <godbyk> daker: Thanks for the heads-up! I've deactivated him from the Ubuntu Manual and website teams.
[01:10] <godbyk> (I didn't intend to activate his website membership, I misread the link.)
[11:14] <daker> no problem :)


[13:40] <frankban> hi benji, could you please take a look at https://codereview.appspot.com/7039049/ ?
[13:40] <benji> frankban: sure
[13:40] <frankban> benji: sometimes, while sending, my local termbeamer crashes with this traceback: http://pastebin.ubuntu.com/1491877/
[13:41] <frankban> benji: thanks
[13:41] <benji> hmm
[13:47] <benji> thanks for the traceback, frankban.  I filed this to track the bug: https://bugs.launchpad.net/termbeamer/+bug/1095646
[13:47] <_mup_> Bug #1095646: Occational exception about None instead of sequence <Termbeamer:New> < https://launchpad.net/bugs/1095646 >
[13:48] <frankban> cool benji, thank you
[14:25] <frankban> benji: thanks for the review
[14:25] <benji> frankban: my pleasure
[14:27] <frankban> benji: re FINAL=1 for tests: our Makefile exits with an error if FINAL is not defined and the last version in CHANGES.yaml is not 'unreleased'. see http://bazaar.launchpad.net/~juju-gui/juju-gui/trunk/view/head:/Makefile#L73
[14:27] <benji> frankban: bummer; that is a bug (and should be filed as such)
[14:28] <frankban> I se three possible solutions: 1) define FINAL or 2) move the tests step before the "change the yaml file", or 3) fix the Makefile
[14:29] <benji> 1 or 2 are fine in the short term, I would like 3 eventually
[14:31] <frankban> benji: if you agree, I'd leave FINAL for now, and file a bug like "it must be possible to run tests without defining FINAL when the last release in CHANGES.yaml is not "unreleased"
[14:31] <benji> +1
[14:31] <frankban> benji: cool, thanks
[15:04] <bac> hi Makyo, do you know if bug 1092208 is still valid?  i can't reproduce it but i may be doing something wrong.
[15:04] <_mup_> Bug #1092208: Pending relation line is not getting events <juju-gui:Triaged> < https://launchpad.net/bugs/1092208 >
[15:04] <Makyo> Checking..
[15:04] <bac> Makyo: when i draw the line and then move one of the unit i see the pending relation disappear entirely
[15:08] <Makyo> bac, Happens too fast for me locally to test, whoops.  Trying uistage.
[15:08] <Makyo> Ditto there..
[15:15] <bac> Makyo: i think i can now see it on staging when drawing between mysql and wp.  but it is very short-lived as the line quickly turns into a black relation line and does track.  it happens so quickly that i think this bug is no longer valid.
[15:16] <Makyo> bac, Yeah, that's what I'm seeing as well.  I'll try later today in LXC and see if I can slow things down any.
[15:19] <bac> Makyo: that card should probably be marked as blocked on your relation extraction from mega, anyway.
[15:20] <Makyo> bac, True, that is changing quite a bit.
[15:20] <bac> i'll do that now
[15:32] <Makyo> benji, frankban goodspud hazmat teknico call now
[15:41] <bac> goodspud: will you be around later to chat about bug 1091616?
[15:41] <_mup_> Bug #1091616: Unusual drag/zoom behaviour <regression> <juju-gui:Triaged> < https://launchpad.net/bugs/1091616 >
[15:52] <goodspud> bac, apologies. I got wrapped up in a conversation with Luca and Greg, losing track of time
[15:52] <bac> goodspud: np
[15:52] <goodspud> bac, happy to talk any time
[15:53] <bac> goodspud: ok, regular g+?
[16:15] <hazmat> teknico, frankban so it looks like the browser is ignoring the websocket since its not over https
[16:18] <frankban> hazmat: do you mean using the gui charm trunk?
[16:18] <hazmat> frankban, yes
[16:19] <hazmat> frankban, effectively that means the charm is broken afaics. here's a recent deploy of the charm from today https://<IP_ADDRESS>/
[16:20] <frankban> hazmat: I saw https working, double checking now. So, you expect to see the juju gui service there, right?
[16:20] <hazmat> frankban, yes, chrome seems to be stripping the connect for the websocket
[16:22] <frankban> hazmat: that makes sense, I am retrying to deploy the gui
[16:23] <teknico> it's working here with the encrypted websocket
[16:23] <teknico> except for one failing test
[16:26] <hazmat> teknico, right... with your branch merged this will be resolved ... as long as  https triggers wss
[16:30] <frankban> hazmat: https://ec2-174-129-127-84.compute-1.amazonaws.com/
[16:30] <frankban> hazmat: it seems to work there :-/
[16:32] <teknico> hazmat, what code loads config.yaml? are values case sensitive? there's a case of True|true and False|false here
[16:33] <hazmat> frankban, hmmm
[16:34] <hazmat> frankban, interesting
[16:34] <hazmat> frankban, aha.. sorry my mistake the issue with the canonistack intsance is the internal ip address leaking
[16:34] <hazmat> mea culpa
[16:36] <frankban> hazmat: no worries, so, it's interesting that, for https sites, chrome blocks all the insecure requests, but allows unencrypted websocket connections
[16:37]  * benji is back from the mechanic's shop.
[16:38] <teknico> uhm, according to the reference it should not make any difference: http://yaml.org/type/bool.html
[16:39] <hazmat> frankban, yeah.. that is strange.. we probably do need to track the issue separately for the charm, as it should work with canonistack setups ideally (ie use ip address) even with the tls wss this won't work there without using the ip address for the websocket config
[16:40] <hazmat> teknico, so its a bit of a mess..
[16:40] <hazmat> teknico, juju validates and parses them as yaml
[16:40] <hazmat> teknico, however the config-get without a charm format metadata specification.. will default to python repr(value)
[16:42] <hazmat> with a charm metadata.yaml value  of format: 2  i think it does do yaml output by default
[16:42] <hazmat> of course the config-get also takes a --format / json flag
[16:45] <hazmat> frankban, thanks for verifying
[16:46] <frankban> hazmat: in the charm, the ws address is obtained using unit-get public-address
[16:47] <hazmat> ic
[16:51] <hazmat> frankban, that seems sane and reasonable and fine to leave as is. i just confirmed the issue was trying to use ec2 provider against openstack.. with the openstack native provider addresses default to using ips instead of dns entries
[16:52] <frankban> hazmat: ack
[17:25] <teknico> hazmat, the yaml thing was a false alarm
[17:25] <teknico> hazmat, all tests using juju-api-agent pass, the failing one uses juju-api-improv
[17:27] <teknico> hazmat, I wonder if we miss anything in juju-api-improv.conf.template
[17:47] <hazmat> teknico, which test fails?
[17:49] <teknico> hazmat, test_staging
[17:49] <teknico> here's the error: CalledProcessError: Command '['jitsu', 'watch', '--failfast', 'juju-gui', '--state', 'started', '--open-port', '443']' returned non-zero exit status 1
[17:50] <teknico> I'm doing a deploy with staging: true to see what happens
[20:22] <teknico> hazmat, WSS branch is finally ready :-) https://codereview.appspot.com/7007045


[12:14] <ev>  cjwatson: correct me if I'm wrong, but installing grub to a partition's VBR when it's already on the MBR will mean you're still booting off the MBR pointing at whatever partition was created when GRUB was installed to the MBR
[12:14] <ev> in other words, not the desired effect
[12:15] <ev> I'm wondering if grub leaves any kind of signature on MBR beyond the obvious 0x55AA so we could detect this scenario and warn the user
[12:19] <CIA-3> console-setup: cjwatson * r392 ubuntu/debian/ (changelog keyboard-configuration.postinst):
[12:19] <CIA-3> console-setup: Don't fail to configure keyboard-configuration if setxkbmap fails to
[12:19] <CIA-3> console-setup: talk to the X display (LP: #728764).
[12:20] <cjwatson> ev: there is unfortunately no way to reliably detect that
[12:21] <cjwatson> it would be lovely, but the MBR is basically chaos.  any signature you might use is either seriously mutable across GRUB versions, susceptible to not being overwritten when another boot loader is installed, or both
[12:21] <cjwatson> and there are zero bytes free in GRUB's MBR so no room to add anything
[12:22] <cjwatson> (0x55AA isn't GRUB's signature, BTW - the disk doesn't have a valid DOS partition table without that)
[12:23] <cjwatson> I'm actually not at all sure how the BIOS detects whether the MBR is bootable
[12:24] <cjwatson> actually I suspect that the MBR must always be bootable and will sometimes chain to a PBR
[12:27] <ev> oh I didn't mean to imply it was grub's signature, but that of the mbr
[12:28] <ev> which is why I said beyond 0x55AA
[12:28] <ev> perhaps we should just always display a message when they select a partition
[12:28] <ev> chances are there will be a bootloader in the mbr
[12:29] <ev> and just word it to say "if you have a bootloader in the mbr"
[12:29] <ev> we don't ever use blocklists, right?
[12:29] <ev> just trying to determine what state mpt's laptop is in (running around the office between broken computers today, it seems)
[12:31] <ev> ah, we do.
[12:32] <ev> I guess that's preferable to taking up an entire primary partition for just core.img, even with the risks of the filesystem moving things around?
[12:48] <cjwatson> the thing is
[12:48] <cjwatson> there is a contingent who really, really, really, really, really want to install our boot loader in a partition record
[12:48] <cjwatson> I'm worried we'll piss them off even further by throwing up more and more warnings
[12:49] <cjwatson> and they sort of have a point, they don't want Ubuntu to take over the machine because it isn't their primary OS
[12:49] <cjwatson> don't generalise from mpt's laptop
[12:49] <cjwatson> it's a Mac
[12:49] <cjwatson> they're weird
[12:50] <cjwatson> once the world switches over to GPT, this will stop being a problem - GRUB will occupy a partition
[12:50] <cjwatson> can't really do that sanely on MBR though
[12:50] <cjwatson> I confess I can never remember exactly how boot loaders are best installed on Macs, and it always makes my head hurt
[12:51] <cjwatson> I think if you put them in the MBR there, other things stop working
[12:51] <cjwatson> there are messy interactions with refit and boot camp
[13:42] <CIA-3> console-setup: cjwatson * r393 ubuntu/debian/changelog: releasing version 1.57ubuntu10
[13:53] <ev> fair point
[13:54] <ev> I'm not arguing for or against blocklists, in case that wasn't clear.  I was just curious as to the motivation for using them given the risks.
[13:54] <cjwatson> lesser evil
[13:54] <cjwatson> I'd love not to need to
[13:54] <ev> right-o :)
[13:55] <cjwatson> (we won't need them with btrfs, once we get round to writing the code to make grub use its bootloader embedding area)
[14:05] <ev> is this documented/explained somewhere? Google-fu seems to be failing.
[14:06] <cjwatson> the btrfs bit?
[14:08] <ev> yes
[14:08] <cjwatson><EMAIL_ADDRESS>[14:09] <cjwatson> the 64kb comment
[14:12] <ev> great stuff, thanks
[14:28] <ev> cjwatson: we had someone try to install Ubuntu today and wasn't offered the resize option, because HP thinks it's funny to use up all four primary partitions.  Given that the only option from here for the regular user is format, what are your thoughts on pointing them in the direction of Wubi in this case (if they have an NTFS partition)?
[14:28] <ev> Not trying to apply it as the solution to everything, but it seems like one of those cases where their options are already limited and if it doesn't work they're no worse off.
[14:28] <ev> (This would presumably be done by greying out the resize option and changing its text to explain the situation with a link to run Wubi.  The code behind the link would copy Wubi to the Windows startup folder and reboot, and I'd change Wubi to remove itself from there during install.)
[14:28] <ev> sorry to keep bugging you today
[14:28] <ev> but I figured this is one of those things you'd want a say on before I just went ahead and did it
[14:29] <cjwatson> interesting thought
[14:29] <cjwatson> it's not the only option of course since it's conceivable they might want to delete something
[14:29] <cjwatson> but I think it's worth mentioning
[14:30] <cjwatson> if it can work smoothly, go for it
[14:31] <ev> brilliant, thanks
[14:31] <ev> but indeed, it would still leave the other options intact
[14:31] <ev> this would just replace the resize option in that case
[14:52] <cjwatson> ev: bug 712654 - is this something you know of us having fixed between alpha 2 and alpha 3?
[14:52] <ubot2> Launchpad bug 712654 in ubiquity "system does not reboot after installation is complete - virtual box" [Medium,New] https://launchpad.net/bugs/712654
[14:52] <ev> nope
[14:52] <ev> I've seen intermittent reports of this over the years, but I've never been able to reproduce it
[14:54] <cjwatson> could you mention that in the bug for the record?
[15:00] <ev> cjwatson: absolutely
[15:01] <cjwatson> ta
[15:01] <ev> any thoughts on what could be causing this?  It's a bit perplexing as the code around shutting down is fairly simple.
[15:01] <ev> I wonder if we should start logging the loop level.
[15:03] <cjwatson> I'm not sure, I wondered if it might be outside ubiquity
[15:05] <ev> yeah, that's definitely possible though quite harder to debug
[15:06] <ev> especially if it's X level
[15:06] <ev> :-/
[15:07] <ev> I wonder.  Perhaps the flush during unmount of /target is taking quite a long time
[15:07] <ev> and it's appearing as though the system has locked up
[15:11] <cjwatson> or could be YA upstart job logic error
[15:13] <ev> lets tell them to pass --debug and strace -f and just wait for the aufs overlay to fill up. ;)
[15:13] <ev> I've followed up on the bug
[15:14] <cjwatson> hah
[15:14] <cjwatson> the other day I wound up waiting until after partitioning and stracing to /target/tmp/ubiquity.trace
[15:14] <cjwatson> which was a good decision since the strace was >1GB
[15:18] <cjwatson> ev: also - did you notice Brian got back to you on bug 709363?
[15:20] <ev> oo, I had not.  Thanks
[15:20] <ev> strace> :)
[15:22] <ev> huh, so it's definitely not swap anymore
[15:24] <ev> ohhh, ecryptfs.


[09:19] <snow_ru> hi all
[09:22] <snow_ru> buc menh
[10:47] <AnAnt> Hello, is there a gconf setting to change the default Ubuntu desktop (to classical instead of Unity) ?
[10:48] <vish> AnAnt: probably in gdm selection?
[10:48] <vish> s/selection/settings
[15:55] <hakermania> Hello all
[23:33] <KNRO> Hi, I have the upstream source code for a kernel module. I can build it fine using make, and I tried to prepare a package for it, but it depends on kernel-headers. What's the correct way to do it? and yes, I spent a couple of hours googling with no avail!
[23:47] <Ampelbein> KNRO: https://wiki.ubuntu.com/MeetingLogs/devweek0809/DKMSPackage might help