[12:25] <bac> teknico, frankban: reviews done
[12:25] <teknico> bac, thanks!
[12:34] <bac> teknico: the last time gary asked me to be more specific about parameters we discovered the API was not spec'ed properly and it was an opportunity to fix it.  so good things come out of the digging to write those docs, even if they are a pain sometimes.
[12:35] <teknico> bac, I totally agree with that too :-)
[12:38] <teknico> ok, lunch time!
[13:24] <gary_poster> teknico, land with changes.  thank you
[13:25] <gary_poster> bac, could you review benji's branch too?  It would be awesome to get that taken care of
[13:26] <bac> gary_poster: ok
[13:26] <gary_poster> ty
[13:26] <benji> gary_poster and bac: Ben has already reviewed it.
[13:27] <gary_poster> benji, oh!  kanban board did not have tag.  thanks
[13:27] <benji> gary_poster: I'll add the tag.
[13:27] <gary_poster> cool, thanks
[13:28] <benji> That's another good job for a script.
[13:32] <bac> benji: i don't see been on the RV as a reviewer.  what's going on?
[13:34] <benji> bac: is this the one you are looking at: https://codereview.appspot.com/7129049/ ?
[13:34] <bac> benji: nope.  why would i look there and how would i know to?
[13:35] <benji> bac: I bet you aren't; apparently when you re-propose it generated a new review and the old review is still linked to the board
[13:35] <benji> That is something that would be good to fix.
[13:35] <bac> ugh
[13:35] <benji> Otherwise we risk people reviewing non-up-to-date branches.
[13:37] <bac> benji: yeah, so a bug with two linked merge proposals is a problem
[13:37] <bac> i'll make a slack card
[13:42] <bac> benji: and i don't even see a way to mark a rietveld as abandoned or obsolete
[13:42] <benji> hmm
[13:43] <benji> bac: under "Edit Issue" there is a "Closed" checkbox
[13:43] <frankban> bac: thanks for the review
[13:44] <bac> benji: oh, on https://codereview.appspot.com/7069068 i have "Can't edit" instead b/c i'm not the owner
[13:45] <benji> that might make editing it via script harder; unless we can have an uber user
[13:46] <teknico> re: docs, as the Chinese are purported to say, be careful what you ask for, you might get it...
[13:53] <gary_poster> goodspud, Stefanie Danevoy wrote that she booked Dijkstra for Monday for us instead of Blue Fin for the daily standup.  Since (barring snow issues) you and Alejandra are going to be with us in Austin I'm going to reply that we don't need it.  Make sense?
[13:54] <goodspud> gary_poster, certainly does
[13:54] <gary_poster> cool thanks goodspud
[13:55] <goodspud> We are being booted out of our Juju room
[14:02] <teknico> bcsaller, good morning, I need to pick your brains some more, when you're around
[14:02] <bac> gary_poster: did you get any snow?
[14:03] <gary_poster> bac, dusting.  schools delayed two hours
[14:09] <bcsaller> teknico: I need about 10 minutes, but happy to talk then
[14:09] <teknico> bcsaller, great, thanks
[14:10] <teknico> gary_poster, we might have to delay our meeting a few minutes, is that ok?
[14:10] <gary_poster> teknico, NEVER!  I mean, sure.
[14:10] <teknico> :-)
[14:10] <gary_poster> :-)
[14:22] <frankban> hi benji, are you reviewing #1099909 ?
[14:22] <_mup_> Bug #1099909: We are trying to talk on the web socket before we have connected <juju-gui:In Progress by frankban> < https://launchpad.net/bugs/1099909 >
[14:23] <benji> frankban: I reviewed it a few days ago, if there is something new I can review that too
[14:24] <frankban> benji: ah... so that's why your name is in the card. yes please, https://codereview.appspot.com/7129055
[14:24] <frankban> thanks
[14:29] <benji> frankban: The branch looks good. I had a couple of small comments.
[14:31] <frankban> thanks benji
[14:32] <teknico> gary_poster, if bcsaller can talk to me in half an hour or so, maybe it's best if we go ahead and talk now, if you still can
[14:32] <gary_poster> teknico, now is fine for me, or can wait a bit.  I'm in the hangout now.
[14:32] <teknico> gary_poster, ok, getting there
[14:33] <gary_poster> cool
[14:36] <bcsaller> teknico: when ever you get done with that hangout I'm free now
[14:36] <teknico> bcsaller, I will, thanks
[15:09] <benji> I just noticed a story we should probably address: When looking at a service a user may want to see the available relations and which services could fulfill those relations.
[15:16] <hazmat> bcsaller, so your definitely not seeing annotations in the initial delta stream?
[15:17] <bcsaller> hazmat: are you? I wasn't, I get the change events just fine from the stream but didn't see them in the initial pump
[15:19] <hazmat> bcsaller, well it annotates current, which is stored as previous, which is used for initial delta to new client
[15:19]  * hazmat writes a test
[15:20] <hazmat> bcsaller, this is live / position stuff is live on uistage also?
[15:20] <bcsaller> hazmat: the annotations get assigned x/y but not the whole story
[15:21] <bcsaller> hazmat: I think it sets up last state based on current and then diffs it vs current and sends nothing on the initial pump
[15:23] <hazmat> bcsaller, confirmed re not seeing them in the browser
[15:23] <hazmat> bcsaller, the delta manager is global across clients
[15:24] <hazmat> so previous w/ annotations should have it.. anyways obviously doesn't.. investigating.. eta is like +2hrs, treating as priority so we can show for next week
[15:26] <bcsaller> hazmat: when that changes the code I have in my branch should handle the rest, and thanks
[15:29] <gary_poster> bac bcsaller benji frankban hazmat teknico call in 1
[15:30] <hazmat> bcsaller, you should be able to put your branch into review even without yet?
[15:30] <teknico> bcsaller, sorry, it took a while :-) maybe we can talk after the weekly call?
[15:31] <bcsaller> hazmat: I took things a little further in the branch than I should have and am cutting a version with only the part of the feature gary expects to show, so soon but not yet
[15:45] <arosales> gary_poster: unfortunately I have a conflict for today's retrospective
[15:45] <gary_poster> arosales, ok, feel to change time
[15:45] <gary_poster> or talk onday
[15:45] <gary_poster> M
[15:46] <arosales> gary_poster: sorry I was referring to the standup in a few minutes
[15:47] <gary_poster> oh ok cool arosales
[16:17] <hazmat> bcsaller, having a hard time reproducing this behavior in unit tests..
[16:17] <bcsaller> hazmat: because you're seeing the annotation data or just hard to implement?
[16:18] <hazmat> bcsaller, because i'm seeing the annotation data
[16:18] <bcsaller> hmm
[16:18] <hazmat> wierd. still playing with it
[16:19] <hazmat> deploying a service, setting annotations, connecting a client and it gets the annotations.. might need to step up to a higher level w/ browser and improv to get a better sense of it
[16:20] <teknico> testing guihelp testing :-)
[16:21] <hazmat> teknico, works :-)
[16:21] <gary_poster> heh
[16:21] <teknico> not for me though?
[16:22] <hazmat> teknico, most clients are smart about that.. guihelp by me doesn't highlight for me
[16:22] <hazmat> teknico, but perhaps it works for you?
[16:22] <teknico> yes, it does if you write it :-)
[16:23] <hazmat> cool
[16:31] <hazmat> bcsaller, ah ic the problem
[16:31] <bcsaller> hazmat: :)
[16:32] <hazmat> the annotations on previous where getting overwritten, because the annotations are coming in as a stream, in the dstream from the browser you can even see them getting removed.
[16:32] <hazmat> not sure if that made sense.. but working on it
[16:35] <benji> so is it "guihelp" or "gui-help"?
[16:35] <hazmat> benji, former
[16:35] <benji> k
[16:35]  * benji edits his IRC config.
[16:58] <hazmat> bcsaller, fix is @ https://codereview.appspot.com/6936063 its a trivial (one-liner) w/ test .. going to proceed
[16:59] <bcsaller> hazmat: thanks
[17:05] <hazmat> bcsaller, merged
[17:05]  * hazmat wanders off to arrange exit visa
[17:05] <bcsaller> hazmat: thanks, I'll test it now, don't expect any issues
[17:29] <teknico> bcsaller, there's still one problem with the third parameter of toggleServiceModule
[17:29] <teknico> the one we renamed from "context" to "module"
[17:29] <teknico> and now we're doing: module.get('component').get('container').one('#service-menu');
[17:29] <teknico> that line raises TypeError: Object #<SVGGElement> has no method 'get'
[17:31] <bcsaller> verify each component in that call chain making sure its what you expect. I didn't think container was a DOMNode but it looks like it might be in the test (rather than a Y.Node)
[17:31] <gary_poster> Random crazy idea: introspection panel & charm panel could use http://angularjs.org/ .  Maybe worth investigating.
[17:32] <bcsaller> gary_poster: thats a different framework
[17:33] <gary_poster> Looks like it has community ties to jquery
[17:33] <gary_poster> but is standalone
[17:33] <gary_poster> bcsaller, yes.  usable in isolation, for only parts of an app.
[17:36] <teknico> bcsaller, the container in the test is created by Y.Node.create
[17:39] <teknico> bcsaller, the value of the "module" parameter of the call (formerly "context") is an SVG "g" element
[17:40] <teknico> maybe we cannot yet get rid of the "view" parameter
[17:41] <bcsaller> teknico: hmm, in that case its still view->module, but context is... I'd have to read through to find that, I'm guessing its <g> containing the rendered service
[17:43] <teknico> bcsaller, it doesn't look like the case, it only contains other SVG elements
[17:43] <teknico> unless the inspector is not showing everything
[17:44] <bcsaller> teknico: it might be higher up the tree, we should see if the usage is required, it sounds like it shouldn't be needed to make this process work, I'll peek at 'active_context'
[17:47] <bcsaller> teknico: it looks like its passed around in old code, but not actually used (in the relations module)
[17:48] <teknico> bcsaller, I think I lost you
[17:48] <teknico> bcsaller, for the sake of this branch, do you mind if I put the "view" parameter back in
[17:48] <teknico> and leave the signature refactoring to you?
[17:49] <teknico> my EOW is fast approaching, and I'd like to land this before then :-)
[17:52] <bcsaller> teknico: sorry, yeah, its fine, I can clean the rest up next week
[17:52] <teknico> bcsaller, ok, thanks
[17:55] <bac> gary_poster, benji: either of you have a moment to review https://code.launchpad.net/~bac/lp2kanban/pick-newest-mp/+merge/143925
[18:05] <bac> does anyone else see the kanban board lose its brain where one card shows links from another?  for instance selecting the RV link from one card takes you to the link from the one above it?  a full page reload cures it.
[18:18] <hazmat> so current trunk i'm not seeing the login at all..
[18:19] <benji> bac: I'm lunching at the moment but I will check if you still need a review when I'm done.
[18:20] <bac> hazmat: how did you run it?
[18:20] <hazmat> bac, make debug
[18:20] <bac> hazmat: debug - no login required, prod - login
[18:20] <hazmat> bac, debug should still send th elogin
[18:20] <hazmat> else with login-required its broken
[18:20] <bac> hazmat: yes, sends but doesn't prompt
[18:20] <hazmat> bac, its not sending
[18:20] <hazmat> this relates to my comments on the branch
[18:21] <bac> hazmat: ok, that's different.  i just meant the credentials are in config-debug.js but not config-prod.js
[18:21] <hazmat> simply shortcircuiting if not connected is broken for the login caller
[18:21] <bac> as you were.  :)
[18:21] <hazmat> because it results in not actually logging in at all, even though the caller did env.login
[18:21] <hazmat> the caller needs to be updated to do it on env connected
[18:30] <hazmat> else we're left with the current behavior which unfortunately is just broken
[18:33] <gary_poster> hazmat, trunk of juju-gui running make debug and make devel I consistently see a login on rapi logs
[18:33] <gary_poster> 2013-01-18 13:32:30,605 juju.rapi.ws:INFO Process message {"op":"login","user":"admin","password":"admin","request_id":2}
[18:34] <gary_poster> like that ^^
[18:34] <gary_poster> hazmat, is that not what you are talking about?
[18:35] <hazmat> gary_poster, yes. but i'm not seeing the login request
[18:36] <hazmat> i'm trying to test the login-required before i land it to ensure no breakage.
[18:36] <gary_poster> hazmat, not sure what to tell you.  I'll try a make clean and then do it again.  I'm pretty sure the code path should login as well.  Note that we wait for connection before we login now...that's not the behavior you commented on.  we changed that on the basis of your comment.
[18:38] <hazmat> gary_poster, i'm not seeing the wait behavior here.. https://codereview.appspot.com/7129055/
[18:38] <hazmat> just a moving the shortcircuit from env to app
[18:38] <hazmat> on check creds
[18:38] <hazmat> gary_poster, the redispatch will auto login ?
[18:39] <gary_poster> hazmat redispatch will go through routes again, yes, and our first route is check_user_credentials
[18:39] <gary_poster> We have to be connected in order to try and login
[18:39] <hazmat> hmm
[18:39] <gary_poster> so the connected flag is not being set when run against your branch I guess
[18:40] <gary_poster> which should happen in env.js...looking
[18:41] <gary_poster> hazmat, are you no longer sending ready as part of your initial response?
[18:41] <gary_poster> looking at line 88 of env.js
[18:41] <gary_poster> and preceding comment
[18:41] <hazmat> gary_poster, on the ws server sends.. {"state": "login-required", "version": 0, "extensions": [], "ready": true, "default_series": "precise", "provider_type": "dummy"}
[18:41] <hazmat> clients not sending anything
[18:42] <gary_poster> hazmat can try to debug for 18 min.  where's your rapi branch?
[18:42] <hazmat> gary_poster, lp:~hazmat/juju/rapi-login
[18:42] <gary_poster> k
[18:43] <hazmat> gary_poster, thanks. if not let me know and i'll continue debug
[18:43] <gary_poster> ok hazmat
[18:49] <gary_poster> something is setting connected to false again...
[18:49] <gary_poster> no...
[18:49] <gary_poster> but connected is not true
[18:50] <gary_poster> I bet we need this.env.after
[18:50] <gary_poster> try
[18:50] <gary_poster> ing
[18:50] <gary_poster> yeah that does the trick
[18:50] <hazmat> gary_poster, or env.once('connected')
[18:51] <gary_poster> we don't want it once, I think...I think we need it every time...thinking
[18:51] <gary_poster> well we need to reset the db every time
[18:51] <gary_poster> the redispatch is ok to do
[18:57] <benji> arosales: here are the screen shots you requested; let me know if you have ideas for any additional ones I can make: http://imgur.com/a/HqkQR
[18:57]  * arosales looking
[18:57] <gary_poster> benji, thos are for jcastro on #juju. not arosales, unless arosales also asked for them
[18:58] <benji> gary_poster: ah!
[18:58] <arosales> :-)
[18:58] <benji> arosales: feel free to enjoy them anyway ;)
[18:58] <gary_poster> benji they look cool to me, thanks :-)
[19:00] <arosales> benji: will do
[19:00] <teknico> gary_poster, it's too late, sorry, I give up, not landing my branch, feel free to adopt it, your or anyone else
[19:01] <teknico> s/your/you/
[19:01] <gary_poster> teknico, what's wrong?
[19:01] <gary_poster> I mean with the branch
[19:01] <gary_poster> it's well past your EoD, I picked up on that :-)
[19:01] <teknico> benji and bcsaller need to agree whether the firsts parameter of toggleControlPanel is a service or a box
[19:01] <teknico> last merge from trunk subverted all the assumptions :-)
[19:02] <teknico> s/firsts/first/
[19:02] <benji> heh
[19:03] <teknico> the changes are all there, it only needs that little agreement :-)
[19:03] <gary_poster> ok thanks teknico.  benji, can you run with that branch?
[19:04] <teknico> tests are failing, you'll see very quickly what the problem is :-)
[19:05] <teknico> have a nice weekend everyone!
[19:11] <bac> thanks benji
[19:12] <benji> gary_poster: sure, I assume it is "double click on service leaves service menu open" we are discussing
[19:12] <gary_poster> yes benji
[19:12] <gary_poster> apparently everything was workling till merge
[19:19] <bac> hazmat: where is your branch/MP/Rietveld for the jitsu speed up work?
[19:20] <hazmat> bac, its a juju-core branch
[19:20] <bac> hazmat: ok
[19:20] <hazmat> bac, i think it still needs a little work.. but its at https://code.launchpad.net/~hazmat/juju/test-sans-stat/+merge/143598
[19:21] <hazmat> ie. the testing env var needs to propogate to the provisioning agent, else it only applies to the bootstrap node
[19:22] <bac> benji: are you picking up teknico's branch?
[19:22] <bac> otherwise i can
[19:22] <benji> bac: yep
[19:22]  * benji realizes he needs to add his head to the card.
[19:24] <bac> gary_poster: we missed our call yesterday.  any time/desire to make it up this afternoon?
[19:24] <gary_poster> bac yes will ping in a few
[19:24] <bac> k
[19:37] <gary_poster> bac in 53 minutes?
[19:37] <bac> ok
[19:41] <gary_poster> benji those screen shots are great I think
[19:41] <benji> gary_poster: cool, I think
[19:41] <benji> ;P
[19:41] <gary_poster> benji, :-P
[19:41] <benji> heh
[19:42] <benji> I wonder if I can script my IRC client so it adds "... I think" to the end of everything I type.
[19:50] <benji> I am confused.  I think I migth have been bitten by the cards-point-to-the-wrong-review bug.
[20:09] <bac> benji: did a kanban page reload help?
[20:09] <bac> or was it the old MP?
[20:10] <benji> bac: no, but I don't think that is actually what is going on; there appears to be only one MP
[20:17] <benji> guihelp: have any of you guys used lbox's -adopt switch?  As far as I can tell Nicola's branch is good to go, I just need to land it
[20:17] <gary_poster> no
[20:18] <benji> I'll just make my own branch and go straight to lbox submit with a comment about what is going on.
[20:20] <benji> ...right after I figure out why the tests are failing.
[20:26] <hazmat> benji, yes.. i have
[20:26] <hazmat> benji, it basically sets bzr commit --author
[20:27] <hazmat> benji, i just extract someone's identity from the change log to use for it,.. so it looks the same as there others
[20:27] <benji> thanks hazmat
[21:09] <bac> benji: are you going to be landing nicola's branch today?
[21:10] <benji> bac: I think/hope so.
[21:54] <gary_poster> benji do you need reviews or are you just going for it? I see you linked the branch
[21:54] <benji> gary_poster: yeah, it was a one-line fix; I am just going to land it
[21:55] <gary_poster> cool benji
[21:55] <bac> gary_poster: i lost the tab with your review and i don't see a card.  send me the link again, please
[21:56] <gary_poster> bac https://codereview.appspot.com/7141059
[21:57] <bac> gary_poster: done
[21:57] <gary_poster> thanks bac
[22:01] <gary_poster> hazmat gui trunk has necessary fixes.  verified that you can do a bad login and then a good one
[22:01] <gary_poster> (so IOW the disconnect after bad login was fine)
[22:22] <hazmat> gary_poster, thanks
[22:22] <hazmat> gary_poster, cool.. hopefully that fixes staging as well
[22:22] <gary_poster> welcome
[22:23] <gary_poster> hazmat staging works for me
[22:23] <hazmat> yup works for staging
[22:23] <gary_poster> cool
[22:24] <gary_poster> have a great weekend all.  bye
[22:24] <benji> bye


[18:54] <joey> FunnyLookinHat: Now this is what we need. http://www.engadget.com/2014/05/29/lian-li-table-pc-chassis/
[19:02] <FunnyLookinHat> joey, hahaha - Yeah but those are so constrictive with your workspace


[00:03] <LordMetroid> Is Canonical doing most of the dev work themselves?
[00:03] <calc> LordMetroid: dev work for what?
[00:03] <LordMetroid> Assembling the distribution...
[00:04] <calc> LordMetroid: some is done by canonical and some by community
[00:04] <calc> LordMetroid: there are many more community people than canonical people though
[00:04] <calc> LordMetroid: canonical people have the benefit of being able to work on it full time though
[00:04] <LordMetroid> Yes, but I can't seem to figure out where the main work is being done
[00:04] <pwnguin> its a little tough to tell; im given to understand canonical occasionaly contracts community members to do some work
[00:04] <directhex> depending on which news sources you believe, i'm apparently an evil microsoft plant
[00:05] <calc> and yes directhex is an evil Novell-Microsoftie ;-)
[00:05] <directhex> oh yeah, i love me some microsofts
[00:05] <calc> my OOo build worked, yipee
[00:05] <directhex> is it called OOOo yet?
[00:05] <pwnguin> LordMetroid: in one sense, the vast majority of Ubuntu is written by non-ubuntu people be it canonical or otherwise
[00:06] <calc> now to forward port all my OOo 3.0 patches to 3.1
[00:06] <directhex> pwnguin, debian!
[00:06] <Amaranth> directhex: throw some of that microsoft cash my way :)
[00:06] <pwnguin> directhex: and the people who write the programs debian packages
[00:06] <LordMetroid> So I've tried to figure out where the decisions are being made now for a good 4 month but I can't seem to grasp it
[00:06] <directhex> ah, your question is a governance question
[00:06] <LordMetroid> yes, I think so
[00:07] <calc> maybe he means UDS decisions?
[00:07] <pwnguin> ubuntu is divided into "members" "developers" and "core developers"
[00:07] <directhex> and "annoying hanger-ons"
[00:07] <pwnguin> theoretically there isn't supposed to be a hierarchy like this
[00:08] <LordMetroid> UDS's where the decision are being made?
[00:08] <LordMetroid> I was thinking of going down to UDS in Barcelona
[00:08] <Amaranth> LordMetroid: UDS is where things are planned
[00:08] <pwnguin> UDS is one place where decisions are made
[00:08] <calc> most of them happen at UDS
[00:08] <Amaranth> LordMetroid: but the people doing the work make the decisions, basically
[00:08]  * directhex remembers to pack his ice beam & missiles
[00:09] <LordMetroid> lol
[00:09] <pwnguin> LordMetroid: basically, anyone in core developers can upload to main/restricted
[00:09] <Amaranth> LordMetroid: So just because some people at UDS decide we're going to rewrite nautilus in scheme doesn't mean it'll get done
[00:10] <directhex> Amaranth, thank $EXPLETIVE
[00:10] <calc> directhex: instead you are going to rewrite it in mono, eh? ;-)
[00:10] <directhex> calc, damn straight!
[00:10] <LordMetroid> *facepalm*
[00:10] <ajmitch> calc: he's probably going to unveil that at UDS
[00:10] <directhex> calc, with winforms!
[00:10]  * Amaranth remembers when we almost decided to use xgl for FUSA
[00:11] <pwnguin> LordMetroid: the CoC directs people to be collaborative, so they shouldnt really be abusing the powers to override any consensus
[00:11] <directhex> unless they're sabdfl
[00:11] <LordMetroid> CoC?
[00:11] <ajmitch> calc: don't forget, directhex's a fan of VB.NET as well :)
[00:11] <Amaranth> one Xserver with multiple xgl servers under it for each user and OpenGL effects for user switching
[00:11] <directhex> ajmitch, "fan of"? never written a line of it matey!
[00:11] <ajmitch> directhex: you try & hide it now...
[00:11] <Amaranth> then everyone would get compiz and we could do awesome transitions for user switching, logging out, etc
[00:11] <directhex> ajmitch, which sorta breaks the first rule of packaging... :/
[00:11] <pwnguin> LordMetroid: in the event that no obvious consensus can be found, the technical board exists to handle things
[00:12] <LordMetroid> ok
[00:12] <Amaranth> I had that one specced and most people either saying it was a good idea or they weren't sure
[00:12] <pwnguin> !coc
[00:12] <Amaranth> thank goodness that didn't happen :P
[00:12] <RAOF> Amaranth: That would've been *awesome*.  Apart from the death of upstream, of course.
[00:12] <Amaranth> RAOF: yeah, that was before upstream completely died
[00:12] <Amaranth> RAOF: we were going to get input redirection too!
[00:13] <directhex> know what i want?
[00:13] <ajmitch> a pony?
[00:13] <directhex> i want mouse sensitivity settings that can cope with mice >1000dpi
[00:13] <pwnguin> a gnome-panel that does intelligent layout?
[00:13] <directhex> and a pony
[00:13] <Amaranth> I want sharks with fricken laser beans
[00:13] <pwnguin> directhex: wacom has some ridiculusly high input resolution
[00:13] <Amaranth> err, beams
[00:13] <directhex> but i'm both allergic to horse hair and french, so if i could have that with chips...
[00:13] <LordMetroid> Death of Upstream, that seems really horrible!
[00:13] <Amaranth> who put those two keys so close together?
[00:13] <RAOF> Mmmm... laser beans.
[00:13] <ajmitch> pwnguin: I won't mention my hassles with gnome-panel & multiple displays then, I may break the CoC :)
[00:14] <directhex> pwnguin, the highest resolution consumer-grade mouse on the market is 5600dpi
[00:14] <LordMetroid> 5600dpi is nothing, I can move way less distance than that!
[00:14] <directhex> pwnguin, my mouse does 4000, and i need to lower it to 1500 for it to be remotely usable on ubuntu
[00:14] <LordMetroid> I move one pixel at a time!
[00:15]  * Amaranth spends $10 on a mouse
[00:15] <Amaranth> so I doubt it does that :P
[00:15] <pwnguin> directhex: maybe its time to gift some x developers with high resolution mice ;)
[00:15] <directhex> Amaranth, the 5600dpi mouse is $130
[00:15] <directhex> so... no
[00:16] <directhex> pwnguin, if i knew which specific person would guaranteed produce results, then i'd donate a reasonable high-dpi mouse
[00:16] <pwnguin> LordMetroid: wacom input resolution is like 20000x20000
[00:16] <directhex> pwnguin, tablets != mice though
[00:16] <pwnguin> indeed
[00:16] <LordMetroid> I have a wacom from the 90s
[00:18] <pwnguin> anyways, i hope you have a better understanding of how decisions are made
[00:18] <pwnguin> locally, with the backing of consensus and oversight of community and technical boards
[00:19] <LordMetroid> Hmm, maybe one should find a place to stay in Barcelona before it is too late
[00:20] <LordMetroid> Yes, I have thank you very much pwnguin
[00:20] <directhex> i really don't remember where i put my euros
[00:21] <LordMetroid> euros chemrous, just use the plastic
[00:21] <directhex> aha, here on my desk
[00:22] <LordMetroid> Remember, do not drink the tap water, it does not contain your bacteria culture and from my experience of Spain, it is highly chlorated as well so you will become quite quizzy
[00:24] <directhex> i never drink the tap water when abroad. who knows what those funny foreigners have done to it
[00:26] <james_w> luckily the beer is fine
[00:27] <LordMetroid> All these people attending the UDS, they are like diehardcore distro developers?
[00:27] <directhex> and/or microsoft plants
[00:27] <LordMetroid> >_>
[00:27] <directhex> james_w, what's drinkable beerwise though? i'm used to nice local ale!
[00:28] <james_w> we'll be short on ale unfortunately
[00:28] <directhex> well, never mind. i hopefully have enough euros that i won't taste it by the end
[00:29] <james_w> there's plenty of good lager and wine though
[00:32] <Amaranth> directhex: Do a couple shots first, you won't taste any of it :)
[00:32] <directhex> hm, i wonder if anyplace sells my favourite rum. i'm almost out!
[00:33] <directhex> is james_w going?
[00:33] <james_w> directhex: where?
[00:34] <directhex> james_w, uds!
[00:34] <james_w> of course!
[00:34] <james_w> UDS in Barcelona? I wouldn't miss that
[00:36] <LordMetroid> You think a general user of Ubuntu which merely is reporting bugs when he sees them has anything to contribute at the UDS?
[00:37] <LaserJock> I'd think it'd at least be nice to have some non-developer feedback for some things
[00:37] <Amaranth> LordMetroid: You may have some ideas or input that is useful
[00:38] <LordMetroid> I develop my own software projects. Mainly concerned about usability...
[00:38] <LaserJock> usability is always a hot topic
[00:39] <pace_t_zulu> anyone here familiar with building Chromium on Ubuntu?
[00:39] <dtchen> pace_t_zulu: fta does; he maintains the ppa.
[00:39] <pace_t_zulu> dtchen: i don't see fta in here
[00:40] <directhex> #ubuntu-mozillateam
[00:42] <dtchen> pace_t_zulu: https://launchpad.net/~chromium-daily/+archive/ppa
[00:43] <pace_t_zulu> dtchen: i am trying to figure out why my builds fail on stock Ubuntu systems
[00:43] <pace_t_zulu> dtchen: if there are any steps particular to Ubuntu that are necessary
[00:44] <dtchen> contrast w/ his generated source packages.
[00:54] <calc> is there a way to view a diff of a git commit without having to give the commit name of the previous commit?
[00:54] <james_w> git show
[00:55] <james_w> or "git diff name^..name"
[00:58] <LaserJock> james_w: btw, do you know if people have been testing the bzr git plugin on the gnome repos?
[00:58] <james_w> yes, they have
[00:59] <LaserJock> james_w: and it's been working pretty good?
[00:59] <james_w> I've no idea
[01:00] <LaserJock> pretty much every upstream and Debian project I've worked with has gone git now
[01:00] <james_w> 100% success record for the feedback I've heard
[01:00] <LaserJock> awesome
[01:00] <LaserJock> do you imagine it might be LP ready pretty soon?
[01:00] <james_w> you didn't ask what the sample size was though ;-)
[01:00] <LaserJock> heh
[01:01] <james_w> I don't know when LP will be ready, you're better off asking them
[01:30] <pace_t_zulu> asac: are you around?
[01:34] <RAOF> LaserJock: I've been playing with Banshee, and the initial branch works just fine (now that it no longer consumes multiple GB of memory), but subsequent pulls seem to die, but only in the particular repository I have.  I'm trying to track it down to something easily reproducible before filing a bug.
[01:34] <Ademan> this is somewhat offtopic I suppose, but it relates to a jaunty package (ushare)
[01:34] <Ademan> does anyone know why the pid stored in a pid file would consistently be two less than the actual pid of the daemon?  (the daemon is being started by start-stop-daemon)  If I had to guess I'd say the pid is from the bash instance that starts start-stop-daemon, rather than the instance of the daemon itself.  Can anyone confirm this?
[01:42] <Ademan> WAIT, duh, the process is daemonizing itself by forking twice...
[01:43] <Ademan> and that was my own addition/mistake
[01:43] <Ademan> please disregard anything i've said :-p
[02:34] <billisnice> my intel and 9.04 is slow
[02:39] <wgrant> billisnice: You might want to read the release notes.
[02:40] <LaserJock> luckily all my intel problems have been fixed in -proposed
[02:40]  * wgrant is using the x-updates PPA plus bits of Karmic.
[02:40] <wgrant> KMS is nice.
[03:10] <billisnice> does 9.04 update to x-updates PPA auto when you update?
[03:15] <maco> huh, hey guys, there's no jaunty directory under http://cdimage.ubuntu.com/ ...who should be told about that?
[03:15] <ajmitch> maco: there is one under /releases/
[03:16] <maco> and http://cdimage.ubuntu.com/releases/jaunty/release/ only has DVDs
[03:16] <ajmitch> as far as I know, releasse.ubuntu.com is the main site
[03:16] <calc> maco: cd's are available at http://releases.ubuntu.com/9.04/
[03:17] <wgrant> Right, most images will be on releases.ubuntu.com or ports.ubuntu.com
[03:17]  * ajmitch cannot spell either :)
[03:17] <maco> ah, so then what's cdimage?
[03:17] <directhex> unofficial portrs
[03:17] <directhex> e.g. ps3 port
[03:17] <directhex> plus other general non-standard cruft
[03:18] <wgrant> And the pre-release images.
[03:18] <wgrant> Only RC and final are ever on releases.u.c, IIRC.
[03:24] <maco> i give up on quassel for tonight
[05:17] <pace_t_zulu> is there a python-tlslite package available in the repos? i can't seem to find one
[06:36] <pitti> Good morning
[06:36] <StevenK> Morning pitti
[06:36] <pitti> directhex: dh_clistrip> URL?
[06:36] <pitti> calc: hi
[06:37] <pitti> apw: no, the default "lp:apport" is trunk, which isn't wrong
[06:37] <pitti> Riddell: will look ASAP
[06:38] <pitti> doko: tsconf> is there a MIR bug?
[06:38] <pitti> hey StevenK, how are you?
[06:38] <StevenK> pitti: Great, you? :-)
[06:43] <NCommander> morning pitti and StevenK
[06:44] <StevenK> And that's an early morning
[06:52] <TheMuso> Morning pitti
[06:52] <pitti> hey TheMuso
[06:52] <TheMuso> Yay, chroot problem. :)
[07:01] <pitti> Riddell: oh, I take it this was invalidly closed as "fix released" then?
[07:02]  * pitti boggles
[07:02] <pitti> "You are not the bug assignee nor the maintainer of xmlrpc-c (Ubuntu), and therefore cannot edit this bug's status. "
[07:02] <pitti> WTH?
[07:02] <pitti> it's an Ubuntu bug
[07:11] <NCommander> pitti, which bug?
[07:15] <dholbach> good morning
[07:25] <pitti> NCommander: sorted out already, I wasn't logged in
[07:25] <pitti> NCommander: filed as bug 371517
[07:26] <NCommander> Launchpad being buggy
[07:34] <stooj> Hi folks
[07:41] <dholbach> pitti: do you know what the deal with libpango/libthai is atm?
[07:41] <dholbach> (karmic amd64)
[07:42] <pitti> dholbach: might be what doko meant with tsconf promotion
[07:44] <dholbach> pitti: hm, not sure I get it - in any case it makes pbuildering / sponsoring anything to do with pango a bit tough :-)
[07:45] <pitti> right, it's uninstallable right now
[07:45] <pitti> doko: hm, tsconf is in main; what did you mean?
[07:45] <pitti> dholbach: what is the error?
[07:46] <persia> dholbach, If you're on amd64, you ought to be able to construct an i386 or lpia pbuilder environment, which might get around some of that class of issue (assuming it's arch-specific).
[07:46] <dholbach> persia: I dunno
[07:46] <dholbach> pitti: it tries to deinstall everything to do with pango :)
[07:48] <dholbach> ah
[07:48] <dholbach> it seems to need a newer libdatrie0
[07:49] <dholbach> libdatrie0 0.1.3-2 is in the archive right now, libthai0 conflicts with libdatrie << 0.1.4
[07:50] <dholbach> ah, maybe pango needs a rebuild against libdatrie
[07:50]  * dholbach will try that
[07:51] <pitti> hm, this morning's dist-upgrade killed f-spot
[07:51] <pitti> ah, seems to be some mono transition
[07:51]  * pitti eyes directhex
[07:52] <StevenK> dholbach: 0.1.3-2 is the latest in Debian, too
[07:52] <dholbach> StevenK: libdatrie0 -> libdatrie1 - I'm just trying a quick pango rebuild
[07:52] <StevenK> Ah!
[07:53]  * StevenK checks other rdepends
[07:54] <StevenK> Right, m17n-lib and libthai need a rebuild too
[07:54] <StevenK> dholbach: &
[07:55] <StevenK> s/&/^/
[07:55] <dholbach> StevenK: will you take care of them or shall I do it?
[07:55] <StevenK> dholbach: I'll look at them when my machine finishes it's current build run
[07:55] <dholbach> StevenK: gracias
[08:00] <StevenK> pitti: Oh, is the NBS checker pointing at karmic yet?
[08:00] <pitti> StevenK: yes
[08:00] <StevenK> \o/
[08:34] <dholbach> StevenK: I'm just taking care of m17n-lib and libthai - don't worry
[08:35] <dholbach> libthai does not seem to need the rebuild anyway
[09:48] <doko> pitti: james_w did promote it yesterday
[09:48] <pitti> ah, ok
[10:02] <pitti> StevenK, kirkland, jdstrand, james_w: warning, I just ran new-binary-debian-universe, and the output has some bogus (packages which are and should be in main)
[10:02] <pitti> so please don't use that right now
[10:04] <pitti> ah, ignore me, it's just harmless noise
[10:05] <olmari> cjwatson_: in case you bear any interest on the issue, I coudn't repeat the dreaded apt "racing condition" bug anymore...
[10:10] <olmari> cjwatson_: as suggested on the bugreport, would there be any way to get some ubuntu "installation server" to be available basically with mirror of 23th of april, as with that day this bug happened every time no matter which other way I tried to install ubuntu-desktop with mini-installer :)
[10:22] <Omahn> Is it normal for the build servers to have over 5000 packages queue or is it just the recent opening of Karmic that's had such an affect?
[10:30] <maxb> Omahn: The buildds are still churning through the initial surge of autosynced packages that happens when the archive opens again after a release
[10:30] <Omahn> maxb: I'm guessing it normally settles after a week or so then?
[10:31] <maxb> lpia's already settled. At the current rate of progress amd64 and i386 should have caught up in another day or so
[10:32] <maxb> The other architectures are, I presume, building on slower hardware.
[10:32] <Omahn> I'm guessing all the build servers are internal to Canonical?
[10:32] <maxb> yes
[10:33] <Omahn> Seems sensible. Shame though, we have some fairly beefy boxes sitting at our place that could certainly help.
[10:44] <ebroder> Anybody backporters around willing to sign off on bug #216761?
[11:08] <scapor> Could someone tell me where the data in the user's home of a persistent live usb (created with usb-creator) is stored? there's no other partition created, no /home on the usb stick's one partition
[11:09] <scapor> and an empty /home in the sqaushfs
[11:10] <soren> scapor: There's a file on the usb stick that holds the filesystem overlay.
[11:10] <soren> I forget what it's called. casper-rw, perhaps.
[11:10] <tdmackey> yeah, casper-rw
[11:11] <tdmackey> in the root directory
[11:11] <scapor> I see. And that's sqaushfs too, then ? :)
[11:11] <tdmackey> tells how much reserved space there is for persitent storage
[11:12] <scapor> oh it's a ext3 partition I see
[11:12] <scapor> tdmackey: soren: thank's very much :)
[11:15] <tkamppeter> pitti, can you pass through the SRU package of bug 365329? Thanks.
[11:26] <soren> scapor: Sure.
[11:33] <pitti> tkamppeter: please reupload with correctly wrapped changelog (too long line)
[11:35] <maxb> What is the official line length, ooi? /me can't find an exact statement in debian-policy
[11:37] <pitti> lintian uses 79 or so
[11:38] <soren> I tend to wrap at 72. It be pleasin' to me eyes.
[11:40]  * soren doesn't know why he got all piratey all of a sudden
[11:41] <slangasek> a vitamin C deficiency?
[11:41] <dholbach> must be scurvy :)
[11:43] <bigon> is the procedure to request package remove written somewhere?
[11:43] <slangasek> create a bug on the package, give a reason, subscribe ubuntu-archive
[11:43] <slangasek> bigon: ^^ written there ;)
[11:44] <bigon> :)
[11:44] <dholbach> https://wiki.ubuntu.com/UbuntuDevelopment/PackageArchive#Removing%20Packages
[11:44]  * dholbach makes sure it's linked from https://wiki.ubuntu.com/UbuntuDevelopment/KnowledgeBase
[12:19] <kumarabhi> hey people
[12:19] <kumarabhi> is there any bounty programme from ubuntu for  studen developers
[12:19] <kumarabhi> student developers
[12:21] <tkamppeter> pitti, can I use the same version number or do I have to bump it?
[12:21] <pitti> tkamppeter: same number is fine
[12:28] <slangasek> StevenK: you haven't killed hildon-fm-l10n yet... :)
[12:28] <StevenK> Hm. I'll do that now.
[12:29] <tkamppeter> pitti, s-c-p reuploaded.
[12:51] <dpm> hi pitti, I've got a question on langpacks when you've got a minute
[12:51] <dpm> I'm trying to find out the status of a translation not from Rosetta but from the langpack sources.
[12:51] <pitti> dpm: hi! just ask
[12:51] <dpm> I have tried to find the language-pack-gnome-mk-base from here -> https://edge.launchpad.net/~ubuntu-langpack/+archive/ppa?field.name_filter=mk&field.status_filter=published&field.series_filter=hardy , but they don't seem to be there. Is there a location where I can find those -base packages?
[12:52] <pitti> dpm: what do you mean by "find the packages"?
[12:52] <pitti> apt-get source?
[12:52] <pitti> dpm: what are you trying to do?
[13:00] <dpm> pitti: I'm trying to find out the status of a given translation for Hardy in a more or less accurate way. Therefore, I'm not looking at the Rosetta stats, but at the data from the last released langpacks. I've first gone the apt-get source way, but I noticed that depending on the language, a given translation had less strings than others, and in any case they seemed to differ from the Rosetta template. Then danilo told me that there is some
[13:00] <dpm>  post-processing going on after the PO files are extracted from Rosetta (such as removal of duplicate strings) ...
[13:01] <pitti> dpm: apt-get source will give you the exact data that is shipped in a release
[13:01] <pitti> dpm: we don't do any post-processing _in_ the source packages' build process
[13:01] <pitti> just some to create these source packages
[13:02]  * pitti -> lunch, bbl
[13:03] <dpm> pitti: ok, I'll ask you some more later, enjoy your meal!
[13:03] <slangasek> dpm: if you need answers sooner, there may be others in the channel who can help answer
[13:03] <slangasek> (I know a bit about langpacks, though I'm not an expert)
[13:04] <ogra> god, when did the ArchiveAdministration wikipage grow so much
[13:04] <dpm> slangasek: thanks, I can wait. I think in the case of langpacks pitti and ArneGoetje are the experts, though
[13:05] <slangasek> they are
[13:05] <slangasek> but you needn't treat them as a bottleneck for everything :)
[13:06] <ogra> slangasek, so its your day today, could you take care for bug 369159 ? seems that slipped through the recent syncs
[13:06] <ogra> pfft
[13:06] <slangasek> ogra: it did not...
[13:06] <ogra> hmm, why dont i see it on any ML
[13:07] <slangasek> at a guess, because StevenK accidentally included in a NOMAIL flush-syncs batch
[13:07] <ogra> ah
[13:07] <ogra> we have that ?
[13:07] <ogra> ok
[13:08] <slangasek> yes, it's what's supposed to be used for all autosyncs
[13:08]  * ogra wonders how he missed the bugmail ... at least i have that
[13:09] <ogra> why are you up already btw ? :)
[13:10] <slangasek> so that I can get my archive day done before Europe has a chance to fill the queue with even more stuff. >:)
[13:10] <ogra> heh
[13:18] <mdke> pitti: re your last comment on bug 366098, do you mean "jaunty" instead of "karmic"?
[13:19] <slangasek> no, he means karmic
[13:20] <slangasek> of questionable import in the case of ubuntu-docs, but it was copied nonetheless :)
[13:21] <mdke> slangasek: karmic already has a package with a higher version number, though
[13:21] <calc> hi
[13:21] <mdke> slangasek: does that not matter?
[13:21] <slangasek> mdke: in that case, the copy presumably failed ;)
[13:22] <mdke> slangasek: I don't know how it works. The bug isn't fixed in the karmic package with the higher version number, because it's not a bug in karmic
[13:22] <slangasek> correct
[13:22] <mdke> as long as it hasn't superceded the existing karmic package, I'm happy
[13:23]  * calc hugs slangasek for syncing all his packages :)
[13:23] <slangasek> it hasn't; I guess pitti overlooked the error message (as well as overlooking that it wasn't a karmic bug, of course)
[13:23] <mdke> ok, no worries then
[13:23] <mdke> thanks slangasek
[13:23] <slangasek> calc: get _rene_ to upload those to unstable, please, so we don't have to do that manually again :)
[13:26] <calc> slangasek: ok... he is going to once he decides to actually upload OOo 3.1.0 to unstable :\
[13:26]  * slangasek nods
[13:34] <TheMuso> Are any build admins able to kick the amd64 build of alsa-lib back into gear? Its a chroot problem, but appears to be due to locking issues which don't seem to be a problem for other builds now.
[13:35] <mdz> pitti: I'm trying to work up a patch for bug 316215.  can you point me to some information about access_control.* and how it works?
[13:35] <mdz> what I want is to make the path in linux.device_file read/writable by the user
[13:36] <mterry> slangasek: Thanks for the pm-utils patch fixups!
[13:38] <slangasek> mterry: sure thing :)
[13:55] <pitti> dpm: re
[13:56] <pitti> mdke: I copied it from jaunty-proposed to jaunty-updates and karmic
[13:56] <pitti> mdke: ah, I remember (sorry, too much SRU stuff this morning); this should be reopened, of course
[13:57] <slangasek> pitti: no, it shouldn't, it wasn't a bug in karmic at all
[13:57] <slangasek> the bug was "document includes an 'unreleased' watermark", and karmic isn't released... :)
[13:58] <pitti> slangasek: right, but it should be kept as a RC bug as a reminder to do it *before* karmic's release this time
[13:58] <dpm> pitti: thanks. Going back to the question: I'm trying to compare the status of the translation of e.g. gnome-terminal in two different languages. I see that in Rosetta the template has got 483 strings, and both translations are 100% complete. However, when I apt-get source the langpack for each language, one PO file has got 472 strings and the other 467. In any case, none of them has got the 483 strings from the original template.
[13:59] <dpm> pitti: 1) Why do the 100% translated PO files have a different number of strings and also differ in number from the Rosetta template? (I know that this does not pose any kind of problem, I'm just trying to understand why)
[13:59] <slangasek> pitti: I don't think a bug is the right way to track things that are supposed to be part of the release process
[13:59] <pitti> slangasek: if we move it there, that works for me as well
[13:59] <pitti> aside from the fact that I question the entire idea of this watermarking in the first place
[14:00] <pitti> after all, everything in karmic is a "draft" until we release
[14:00] <slangasek> I was rather surprised that this wasn't in the process checklists already
[14:00] <pitti> dpm: are you getting the ones from hardy-proposed, hardy-updates, or hardy final?
[14:02] <dpm> pitti: hardy-updates
[14:04] <pitti> mdz: http://people.freedesktop.org/~david/hal-spec/hal-spec.html#access-control is the initial documentation
[14:04] <geser> doko: do you know why python-distutils.mk from cdbs (karmic) renames dist-packages to site-packages?
[14:05] <pitti> mdz: there is an existing patch which adds ACLs for smartcard readers: http://bazaar.launchpad.net/%7Eubuntu-core-dev/hal/ubuntu/annotate/head%3A/debian/patches/02_smart_card_readers_acl.patch
[14:06] <doko> geser: what is python-distutils.mk?
[14:07] <geser> doko: /usr/share/cdbs/1/class/python-distutils.mk
[14:08] <doko> geser: see above, answered to pitti as well. packaging *.install files expect these in site-packages
[14:09] <mdz> pitti: thanks
[14:10] <mdz> pitti: what defines the meaning of access_control.type=smart-card-reader?
[14:11] <pitti> mdz: it's just a human readable identifier which binds together the policy (who has access) in the .policy file with the subject (device file, in the fdi)
[14:12] <geser> doko: do we still need to modify packages for the python2.6 transition with all this automatic renaming done by the different packaging helpers?
[14:13] <mdz> pitti: ah, and "active" and "inactive" in the .policy refer to active user and inactive user?
[14:13] <pitti> mdz: console session, but that by and large maps to user, yes
[14:13] <mdz> pitti: so access_control.type=foo maps to org.freedesktop.hal.device-access.foo ?
[14:13] <pitti> mdz: right
[14:14] <mdz> pitti: can you give me a hint as to whether I should create a new type or if an existing one is appropriate?
[14:14] <pitti> mdz: looking at /usr/share/hal/fdi/policy/10osvendor/20-acl-management.fdi
[14:15] <DnaX> please fix bug #340718! I've post a patch before final release.
[14:15] <doko> geser: if a package ftbfs, yes
[14:15] <pitti> mdz: well, portable_audio_player wouldn't be entirely wrong
[14:15] <pitti> or camera
[14:16] <pitti> mdz: ah, hang on, there's "PDA"
[14:16] <DnaX> this package fail to install and irda do not work automatically
[14:16] <mdz> pitti: that reminds me of another bug which i haven't looked for / filed yet...when I plug in the G1, I get multiple popups (music player, camera).  technically correct, but not very helpful
[14:17] <mdz> pitti: PDA seems to imply a palm-like sync interface though
[14:17] <pitti> mdz: I noticed that, too; I just didn't see an obvious way to fix it
[14:18] <mdz> this stuff is closest:
[14:18] <mdz>     <!-- support for Linux USB stack where linux.device_file is set (e.g. device node is on the main usb device) -->
[14:18] <pitti> mdz: not necessarily, that's just there for the Pam/pocketpc ones
[14:19] <pitti> mdz: in that block, portable_audio_player is closest then
[14:20] <mdke> pitti: we use the watermark for the doc.ubuntu.com website too. But I agree with slangasek that a bug is not the right way to remember this, since it will happen in releases after karmic too. I think the best way is to include it on a -doc specific release process list
[14:20] <mdz> pitti: the text in org.freedesktop.hal.device-access.policy wouldn't really be accurate though.  I don't know how big a problem that is
[14:20] <DnaX> pitti: have you see irda-utils bug?
[14:20] <mdz> "System policy prevents access to audio players"
[14:21] <pitti> mdke: works for me
[14:21] <DnaX> pitti: can you triage it?
[14:21] <mdke> pitti: ok, I'll do that then
[14:22] <pitti> mdz: that string is displayed if the admin sets the PK policy to "auth_admin"
[14:22] <pitti> mdke: it's not shown for "yes" or "no"
[14:22] <pitti> erm, mdz: ^
[14:22] <pitti> DnaX: I don't have any IR devices, and I'm quite busy ATM, sorry
[14:22] <mdz> pitti: then why are there so many entries with the same defaults (yes and no)
[14:23] <pitti> mdz: it's the upstream default, and we never cleaned it up
[14:23] <DnaX> pitti: I have it... and i've post a working patch for it!
[14:23] <pitti> mdz: basically, that allows an admin to say "my users can access a music player, but not an USB stick"
[14:23] <mdz> pitti: ok, just tell me what you recommend and I will submit a patch
[14:23] <pitti> DnaX: please subscribe ubuntu-main-sponsors then
[14:23] <DnaX> done
[14:24] <pitti> mdz: string-wise, PDA still sounds closest to me
[14:24] <pitti> DnaX: thanks
[14:36]  * zhxk wants know if there are any ready made pakages in depo to ubuntu
[14:37]  * zhxk wants know if there are any ready made pakages in depo to ubuntu about arm cross-build-chains
[14:38] <ikonia> zhxk: you'll have to build your own tool chain to cros-compile
[14:40] <zhxk> ikonia:well, i encontered a problem to it  http://pastebin.ca/1412096
[14:40] <zhxk> its logs to (export,config,make)
[14:41] <zhxk> to e2fsprogs
[14:43] <ikonia> zhxk: that's nothing to do with ubuntu development
[14:59] <zhxk> ikonia:which channel should i ask?
[14:59] <ikonia> zhxk: no idea, but it's nothing to do with ubuntu
[15:00] <pitti> dpm: the hardy-updates are from January, perhaps the mk translations weren't that complete at that time?
[15:02] <zhxk> ikonia:thanks all the same
[15:02] <ikonia> no problem
[15:02] <persia> zhxk, You may want to ask in #ubuntu-arm, while we don't do cross-compilation, someone there may have more useful information.
[15:02] <zhxk> persia:thanks a lot
[15:05] <dpm> pitti: If I understand it correctly, the mk translation was complete at the time, the only thing I cannot understand is the difference in the number of actual strings (msgid) in the template (Rosetta) and in the PO file (langpack source package). The PO file in the langpack tarballs seem to have the same number of strings as the Rosetta templat, though. In any case, I think I'll try to follow this up in an e-mail and I'll provide the links
[15:05] <dpm> to the exact files I'm looking at, which will be easier
[15:06] <tkamppeter> pitti, did you see my s-c-p re-upload?
[15:06] <pitti> tkamppeter: yes, I did
[15:07] <pitti> dpm: okay
[15:08] <kirkland> pitti: okay, thanks for the headsup
[15:13] <directhex> it's an ikonia!
[15:28] <dholbach> al-maisan_: congratulations to your upload to Ubuntu :)
[15:28] <al-maisan_> dholbach: thanks :) it's a pleasure to contribute :)
[15:28] <dholbach> :-)
[15:39] <ogra> slangasek, when do you plan the first dailies again ?
[15:39] <slangasek> ogra: tomorrow
[15:40] <slangasek> (but they'll probably fail to build, the installer's not merged up yet)
[15:40] <ogra> good (i just got the responsibility for alpha1 mobile images assigned)
[15:40] <ogra> yeah, i wouldnt expect them to build yet
[15:41] <ogra> mako, you dont happen to be around, do you ?
[15:54] <dholbach> tjaalton, bryce: anything Andreas can do to make bug 352708 more useful?
[16:07] <kirkland> cjwatson_: hey, one more ssh auth question ... i assume that the message the client signs to verify its identity is some randomly generated different signature every time, right?  (else replays would be possible)
[16:25] <soren> kirkland: It's a blob of data consisting of the session id and some other tidbits, yes.
[16:39] <dholbach> can somebody please shove ibus through binary new? :)
[16:41] <james_w> dholbach: it's not built has it?
[16:42] <dholbach> ah, so it's through new, but not built yet, ok :)
[16:42] <dholbach> thanks james
[16:42] <kirkland> pitti: hey
[16:42] <james_w> dholbach: binary NEW after building I think
[16:42] <kirkland> pitti: am i correct in remembering you being the person who is anti-/etc/groups ?  :-)
[16:43] <kirkland> pitti: i was thinking about for Karmic making /sbin/mount.ecryptfs_private perm'd 4750, and adding an ecryptfs group
[16:43] <pitti> kirkland: I am, yes :)
[16:43] <kirkland> pitti: currently, any user can created an encrypted-private dir
[16:43] <kirkland> pitti: which means that users could, say, "hide" data from the sysadmin, perhaps
[16:43] <dholbach> james_w: ok, I'll shut up and wait then :)
[16:44] <pitti> kirkland: I thought that was the point? :-)
[16:44] <kirkland> pitti: fedora is shipping ecryptfs with a patchset that restricts this to users the admin puts in the ecryptfs group
[16:44] <kirkland> pitti: yeah, well, RHEL got some customer complaints, evidently!
[16:45] <kirkland> pitti: users in the ecryptfs group can continue to "hide" data from root, but not everyone, necessarily
[16:46] <kirkland> pitti: i guess my question to you is, how would i solve this without a group?
[16:46] <kirkland> pitti: is this something that PolicyKit is cut out to do?
[16:46] <pitti> kirkland: you can add a PK check to ecryptfs.mount if you wanted to
[16:47] <kirkland> pitti: what does that look like?
[16:47] <pitti> kirkland: my main crusade was to stop people from using groups for device access
[16:47] <kirkland> pitti: ah!
[16:47] <pitti> kirkland: for your use case, a group is less evil
[16:47] <kirkland> pitti: so a group might actually be "okay" for this?
[16:47] <pitti> kirkland: but I don't think you'd want to deny it by default, do you?
[16:47] <kirkland> pitti: less evil, heh :-)
[16:47] <pitti> kirkland: well, adding a group is still an excuse for us to push work to an admin
[16:47] <kirkland> pitti: right, this is going to be a really tough one, particularly for upgrades
[16:48] <pitti> kirkland: upgrades> don't even think about it
[16:48] <pitti> kirkland: you can't add users to groups on upgrades
[16:48] <kirkland> pitti: ideally, there would be an existing group that we already use, that I could piggy back onto
[16:49] <kirkland> pitti: i think 'admin' is not the right one, though
[16:49] <kirkland> pitti: i think i might make it a really, really low priority debconf question
[16:50] <kirkland> pitti: "Do you want to restrict eCryptfs use to members of 'ecryptfs' only?"
[16:50] <kirkland> pitti: default in Ubuntu is "no"
[16:50] <pitti> kirkland: that wouldn't help us, though
[16:50] <kirkland> pitti: but fascist sysadmins can preseed that "yes", or change it later
[16:50] <pitti> kirkland: since you can't have a group "no-ecryptfs"
[16:51] <kirkland> pitti: well, i worded that question poorly
[16:51] <pitti> kirkland: seriously, a fascist sysadmin could just dpkg-statoverride mount.ecryptfs
[16:51] <kirkland> pitti: really, it's just about the setuid binary
[16:51] <kirkland> pitti: which is mount.ecryptfs_private
[16:51] <pitti> kirkland: no, but you want users who currently run ecryptsfs to continue to do so after an upgrade
[16:51] <kirkland> pitti: not the generic mount.ecryptfs
[16:51] <kirkland> pitti: right, which is why the question would be low priority, and the default value would be our current policy
[16:52] <kirkland> pitti: which would keep that setuid binary 4755
[16:52] <kirkland> pitti: the fascists can make it 4750
[16:52]  * kirkland decides that 'fascist' isn't particularly accurate, when describing this class of sysadmin
[16:53] <pitti> kirkland: ah, I see
[16:53] <pitti> kirkland: but those kind of sysadmin can probably also use statoverride themselves
[16:53] <kirkland> pitti: it's really just about the encrypted-private, encrypted-home
[16:53] <pitti> kirkland: but well, your call
[16:53] <pitti> kirkland: as long as it doesn't involve putting users into that group _by default_, it's okay with me
[16:53] <kirkland> pitti: well, i didn't know that -stateoverride existed, or what it did, until i just manpaged it
[16:54] <kirkland> pitti: yeah, i don't think we add any users in that group by default
[16:54] <kirkland> pitti: if the admin chooses to go with mount.ecryptfs_private at 4750, then it's up to them to add users to that group
[16:55]  * slangasek envisions a nanog logo involving a fasces
[16:55] <kirkland> ||)
[16:55] <kirkland> ||*
[16:56] <kirkland> slangasek: i like the asterisk one better ;-)
[16:56] <slangasek> heh
[16:57] <kirkland> pitti: cool, thanks for your ideas
[16:57] <kirkland> pitti: i think i know how we're going with this
[16:58] <pitti> kirkland: great, thanks for the discussion
[17:07] <kirkland> cjwatson_: i'm curious what you think about https://bugs.launchpad.net/bugs/371719, if this might be acceptable for Karmic
[17:58] <savvas> pitti: here? do you think I should file a bug at debian about libmtp package still using a link? and for the proper prefix?
[17:58] <pitti> savvas: Debian is moving towards udev rules in /lib/ as well, so they should just do that
[18:00] <savvas> pitti: sorry I'm confused :) you mean I shouldn't and just keep the patch as it is in ubuntu, right?
[18:04] <pitti> savvas: oh, Debian should by all means fix their package as well
[18:04] <pitti> savvas: but we shuold keep the ubuntu one as it is for now, yes
[18:05] <pitti> savvas: basically, debian could take our patch (and update the version numbers in the comparison adequately)
[18:05] <savvas> ok trying right now then, I'll let you know if a few minutes
[18:05] <pitti> savvas: no hurry; I need to leave in 30 mins, I won't get to sponsoring it today anyway
[18:06] <savvas> ok then :)
[18:19] <savvas> those preinst / postinst are really twisted scripts, but gooooood :) I got the hang of it, no changes required, conf files and packages will be properly upgraded
[18:21] <savvas> (I mean no changes required on my behalf)
[18:31] <pitti> savvas: no; the main point of the merge is to send the patch to Debian, so that eventually we can sync again
[18:32] <pitti> savvas: also, would you have time to integrate the other patch I mentioned?
[18:32] <pitti> good night everyone, see you all tomorrow
[18:33] <savvas> pitti: I'll check that out as well, I'll let you know through the bug report
[18:38] <rtg> kees: I've updated the kernel flavours blueprint https://wiki.ubuntu.com/KernelTeam/Specs/KarmicKernelFlavours and referenced one that you wrote a year ago.
[18:43] <kees> rtg: ah-ha, cool.
[18:43] <kees> rtg: instead of the current one?
[18:43] <rtg> kees: I'm not sure what you mean.
[18:44] <kees> https://blueprints.edge.launchpad.net/ubuntu/+spec/security-karmic-pae-desktop instead of the other one since the other was already scheduled for the last UDS
[18:44] <geser> doko: any idea how to resolve the FTBFS of cerealizer in karmic? the problem is that cdbs renames the dist-packages back to site-packages, but the testscript adds get_python_lib() prefixed with debian/cerealizer to find the modules which fails as the files are at this point in site-packages and not dist-packages
[18:44] <geser> doko: http://launchpadlibrarian.net/26117036/buildlog_ubuntu-karmic-i386.cerealizer_0.7-3_FAILEDTOBUILD.txt.gz
[18:45] <rtg> kees: I just referenced yours since it was apropo wrt PAE, but my spec also covers other topics.
[18:45] <kees> rtg: also, why do lpia and armel get -$arch instead of -generic
[18:45] <kees> rtg: okay, but I'd like to make sure that the cs-limit nx-emulation stuff gets in too.
[18:45] <rtg> actually, they $flavour
[18:45] <rtg> they get $flavour
[18:46] <kees> rtg: and why "generic-pae" instead of just "pae"
[18:46] <rtg> kees: the names are open for discussion. perhaps 3gb is more appropriate.
[18:47]  * kees nods
[18:47] <kees> "-allyourRAMisbelongtous"
[18:47] <elmo> I thought the cutoff for non-PAE was 2Gb? :-P
[18:47] <rtg> kees: my goal is to have the minimum difference between -generic and -generic-pae
[18:48] <kees> rtg: I don't know what the conventions are for UDS scheduling, but you might want to check if using +spec/use-pae-when-possible is correct (since it was last UDS)
[18:48] <elmo> umm, 4, rather
[18:48] <rtg> elmo: 1GB is reserved for mem mapped I/O stuff
[18:48] <kees> elmo: iiuc, it's only 3 because of how the kernel maps virtual memory.
[18:48] <maswan> elmo: minus whatever pci etc wants, and then kernel/userland split
[18:48] <maswan> elmo: We got 3.5GB on our machines, back in the days before real pointers
[18:49] <kees> rtg: -generic vs -generic-pae> yeah, I'm all for it being just a single CONFIG difference.  :)
[18:49] <maswan> but anyway, 32-bit stuff has been obsolete for close to 5 years now anyway. ;)
[18:49] <elmo> maswan: haha
[18:50] <kees> rtg: and what're your current thoughts on cs-limit?
[18:51] <rtg> kees: um, ambivalent.  I _would_ like to see some evidence that it might have prevented past abuses.
[18:51] <kees> rtg: I can certainly go find some example exploits that don't work as a result of cs-limit nx-emulation.
[18:52] <rtg> kees: that would certainly help bolster credibility for the patch
[18:52] <kareem> hello
[18:52] <kees> rtg: if it helps, nearly all security vulnerability research starts with "and if we turn off NX, [example]".
[18:52] <kees> rtg: all the stuff about how to avoid ASLR, stack canaries, etc, all depend on NX being non-functional.
[18:53] <kareem> Would this qualify as a Q for here?  I'm trying to make an Ubuntu package for FreeSWITCH, and when I test it, I keep getting: "E: Internal Error, Could not perform immediate configuration (2) on g++-4.2"  No one in any other Ubuntu channels I've been in can figure it out.
[18:53] <kees> rtg: shall I send it to the kernel-team thread?
[18:53] <rtg> kees: I've got no problem with NX, its just that the cs-limit emulation is a bit of a hack (but understandable given HW limits)
[18:53] <rtg> kees: yes- the k-t list is appropriate
[18:54] <kees> rtg: well, cs-limit == NX for people lacking NX hardware, so basically, all exploits that work when NX is missing are protected by cs-limit nx-emu
[18:54] <rtg> kees: true, it is page granular.
[18:55] <kees> rtg: do you still want examples?  it's an entire class of vulnerabilities, so I thought it'd be an obvious protection.
[18:55] <ogra_> heh ... that abbreviation is used way to often /me just thought of nx-server/client
[18:55] <rtg> kees: it may be obvious to you, but a list of examples wouldn't hurt.
[18:55] <kees> rtg: okay
[19:18] <cody-somerville> My ssh-agent seems to have been replaced with one that has an icon of a weird looking fish
[19:18] <cody-somerville> I thought I remember reading about this in a changelog
[19:18] <cody-somerville> Can anyone jot my memory?
[19:23] <Pici> cody-somerville: seahorse?
[19:23] <cody-somerville> I'd like to use seahorse
[19:30]  * zhxk runs away
[19:44] <LaserJock> is there an easy way to determine what the default python version is for a given release?
[19:44] <geofft> packages.ubuntu.com/python
[19:45] <LaserJock> geofft: thanks, that was easy :-)
[19:48] <geser> LaserJock: you can also run "python --version" (assuming a supported setup)
[19:48] <LaserJock> yeah, I just didn't have chroots available for the releases I wanted
[19:52] <LordMetroid> Does the launchpad automatically forward bug reports upstream?
[19:53] <geser> LordMetroid: no
[19:54] <LordMetroid> Damn, why not? It ought to, it is so convenient to report bugs for anything in one place
[19:56] <geser> one reason is that the bug might be due to Ubuntu changes, another reason that not every bug is really a bug but an user-error and upstream won't be happy if we auto-forward those bugs too
[19:56] <geser> I guess there are more reasons against it
[19:56] <LordMetroid> So what do I do with this:  https://bugs.launchpad.net/ubuntu/+source/gimp/+bug/371819 ?
[19:56] <LaserJock> upstreams not wanting automatic bugs from LP comes to mind
[20:02] <geser> LordMetroid: forward the bug to the gimp bugtracker yourself and add a bugwatch to the bug in LP
[20:02] <LordMetroid> ok... I'll try to do that
[20:03] <geser> I guess some upstream prefer to have a human contact to a bug instead of some script (another reason against automatic bug-forwarding)
[20:15] <LordMetroid> Bugwatching is more intersting then birdwatching...
[20:23] <mrooney> Would anyone be kind enough to whitelist me on the ubuntu-devel list?
[20:24] <cody-somerville> mrooney, Are you a Ubuntu developer?
[20:25] <mrooney> cody-somerville: I am not familiar with the official definition of that :)
[20:25] <cody-somerville> mrooney, Are you a member of the ubuntu-dev or ubuntu-core-dev teams on launchpad?
[20:25] <mrooney> As I understand it anyone can be whitelisted if they have a history of reasonable posts
[20:25] <mrooney> cody-somerville: nope
[20:26] <cody-somerville> mrooney, You might try e-mailing an administrator of the list
[20:26] <cody-somerville> mrooney, Or try your luck and see if the right people see your message above
[20:27] <mrooney> cody-somerville: yeah I have seen someone successfully ask here so I thought I'd try as well :)
[20:35] <kirkland> jcastro: yo
[20:35] <kirkland> jcastro: got your email about ec2+screen
[20:35] <kirkland> jcastro: try the new screenbin
[20:35] <kirkland> jcastro: i put everything you need in there
[20:35] <jcastro> ok
[20:35] <kirkland> jcastro: you'll need to install Karmic's deb on your Jaunty system
[20:35] <kirkland> jcastro: give that a try, and let me know how it works for you
[20:36] <jcastro> likely tomorrow before I prep for a talk on s-p
[20:36] <kirkland> jcastro: neat
[20:36] <kirkland> jcastro: who are you talking to?
[20:37] <kirkland> jcastro: btw ... kees patched screen itself to fix one annoyance, where someone trying to type in their read-only session will cause a 'bell' or ding-message to all other users
[20:38] <kirkland> jcastro: i built that in the screen-profiles ppa for hardy/intrepid/karmic
[20:38] <kirkland> jcastro: you'd probably want that package on your host :-)
[21:08] <thebloggu> my network manager applet is taking too long (like 2-3 min) to recognize my wireless card (not even connect to network, just recognize the card only) on boot. it is possible it is a bug or maybe i am missing something. using openbox if it is relevant
[21:17] <pace_t_zulu> can someone help me will pbuilder?
[21:17] <pace_t_zulu> i have a problem with unmet dependencies on a build
[21:18] <pace_t_zulu> i have read https://wiki.ubuntu.com/PbuilderHowto
[21:18] <pace_t_zulu> but i can't find a way to resolve the issue
[21:27] <pace_t_zulu> can someone help me figure out how to fix unresolved dependencies in debuild and/or pdebuild?
[21:32] <pwnguin> pace_t_zulu: unresolved dependencies?
[21:33] <pwnguin> as in, the build deps aren't installable?
[21:33] <pace_t_zulu> pwnguin: yeah i figured pbuilder would handle it better
[21:33] <pace_t_zulu> pwnguin: no, the build can't happen
[21:33] <pace_t_zulu> pwnguin: i think it is specific to this package
[21:33] <pace_t_zulu> pwnguin: i am trying to put together a patch
[21:34] <pwnguin> if you have an error log, that might help to pastebin. but right now i have to run the vacuum =(
[21:37] <maco> thebloggu: see if it's showing up in hal during that 2-3 minute wait
[21:38] <thebloggu> maco, how can i do that ?
[21:38] <maco> lshal...
[21:38] <pace_t_zulu> pwnguin: http://pastebin.ubuntu.com/164447/
[21:39] <maco> (by the way, #ubuntu-bugs might be a good place for debugging...or #nm for that matter)
[21:39] <thebloggu> maco, wow enourmous :P it will be difficult to test it because it is on boot
[21:39] <thebloggu> right after start
[21:40] <maco> thebloggu: log in, run "lshal >> lshal.out" and then read through at your leisure to see if your wirless card is listed
[21:40] <maco> (it'll put the output in a file called lshal.out)
[21:42] <thebloggu> maco, ok, i'll test it and i'll bring the results here
[21:43] <maco> #nm would be better
[21:43] <maco> since they know how this stuff all works and all i know "it gets info from hal" ;)
[21:46] <pace_t_zulu> pwnguin: did you get that pastebin?
[21:48] <pwnguin> yea
[21:49] <pwnguin> pace_t_zulu: so it's complaining that ipython isn't installable
[21:49] <pwnguin> pace_t_zulu: by chance, is this a patch for a package in universe?
[21:51] <pace_t_zulu> pwnguin: let me check
[21:52] <pace_t_zulu> pwnguin: indeed it is
[21:52] <pwnguin> then #ubunt-devel isn't the right place to chat about the patch :)
[21:53] <pwnguin> #ubuntu-motu handles universe packages
[21:53] <pwnguin> lets move the conversation to there, and stop bothering core developers :)
[22:46] <pace_t_zulu> pwnguin: you here?
[23:26] <tkamppeter> pitti, hi


[14:02] <Brainstorm> Updates for Bangladesh: +256 cases (now 1.6 million), +7 deaths (now 27880), +19523 tests (now 10.4 million) since a day ago


[09:55] <slyon> fiesh: well.. I guess you could still use a systemd drop-in config override to (re-)set whatever setting is needed to make systemd-networkd work for your usecase
[09:56] <slyon> e.g.: /etc/systemd/network/netplan-eth0.network.d/override.conf
[09:57] <slyon> c.f.: https://www.freedesktop.org/software/systemd/man/systemd.network.html
[10:01] <fiesh> slyon: that's a nice suggestion... this selectively overrides settings that netplan set differently or didn't touch?
[10:01] <slyon> yes, exactly
[10:01] <fiesh> slyon: I'm somewhat confused I'm the only one running into this issue to be honest.  like a server with static devices shouldn't lose its routes when a cable is unplugged and replugged one would think
[10:02] <fiesh> but from what I can gather, that's exactly what happens, and it's only deactivated for bridge devices by the pull request I linked above
[10:03] <slyon> yeah... what version of systemd are you using? I remember there was some issue wrt carrier loss... lets see if I can digg that up
[10:04] <fiesh> 245.4-4ubuntu3.6
[10:05] <slyon> ok.. that should contain all available fixes
[10:07] <slyon> Would you mind filing a bug about this on Launchpad? Especially if you find a override-setting fixing the problem for you? https://bugs.launchpad.net/netplan/+filebug
[10:07] <slyon> or even better, use: 'ubuntu-bug netplan.io'
[10:09] <fiesh> oh yes, I'll do that... didn't know about the tool
[10:10] <slyon> thank you!
[10:10] <fiesh> it'll take me a bit since I only want to experiment witht the overrides when the system isn't actively used
[10:10] <fiesh> thanks for your help!
[10:10] <slyon> sure, take your time!
[10:10] <fiesh> (and I need to be there in person in case network connectivity drops)
[10:16] <fiesh> I also hope netplan will support tc-cake (or just tc in general) since it's the most amazing thing since bread
[10:17] <fiesh> with it, you can eat your cake and have it too
[10:19] <slyon> yeah.. there are many features still missing in netplan unfortunately. You can check if there is a tc/tc-cake feature request (wishlist bug) already on https://bugs.launchpad.net/netplan/ and file one if it does not yet exist.
[10:22] <fiesh> good idea, i'll put it on my todo list once this works and I know that I don't have to switch away from netplan ;)
[10:22] <lukasm> cool :)
[10:22] <fiesh> tc-cake is nothing short of magic, latency just ceases to exist


[00:01] <kcj[work]> Morning.
[00:56] <hads> morning
[18:39] <ibeardslee> morning
[19:34] <hads> morning
[20:24] <olly> morning