[06:30] <dholbach> good morning
[20:00] <jose> pleia2: hey, if you need a hand with releasing just ping me, free from school today :)
[20:00] <pleia2> jose: I'm good for releasing today, but care to do a quick editorial review for obvious issues?
[20:01] <jose> will do right now
[20:01] <pleia2> PaulW2U probably found everything, but doesn't hurt
[20:01] <pleia2> Unit193: if you could link check too that'd be great: https://wiki.ubuntu.com/UbuntuWeeklyNewsletter/Issue337
[20:02] <jose> I got pleia2'd
[20:07] <jose> pleia2: now that I'm checking the Feedback section on the template, why don't we change 'send your tech support queries to<EMAIL_ADDRESS>to 'go to askubuntu.com'?
[20:07] <jose> less people respond on the ML
[20:09] <pleia2> jose: maybe give them a list of options? askubuntu, forums, mailing list
[20:09] <pleia2> I don't really feel comfortable promoting one over another
[20:10] <jose> I think that'd be good, maybe we can check that for issue 338?
[20:10] <pleia2> sure
[20:10] <pleia2> feel free to edit the template, I will review in a bit
[20:11] <jose> ok!
[20:12] <jose> found no errors
[21:19] <pleia2> thanks :)
[21:29] <Unit193> Looks good.
[21:31] <pleia2> ty


[00:05] <joey> wgrant, you're smarter than you look! ;-)
[00:05] <wgrant> Heh.
[00:07] <joey> wgrant, I think rockstar had the same impression.
[00:07] <joey> wgrant, as in, he ran away
[00:07] <wgrant> Now, LAZR looks interesting. And that code isn't awful.
[00:07] <joey> yeah we've been hacking on LAZR for some time and it is continually being updated
[00:07] <wgrant> Although I had to hack lazr.restful to make it work with Python 2.6, and I should probably file a bug.
[00:08] <joey> wgrant, actually someone was working on that iirc
[00:08] <joey> flacoste or barry
[00:08] <wgrant> Ah.
[00:08] <joey> you might file a bug though
[00:08] <joey> not sure where they are with that
[00:08] <joey> maybe we can use your patch
[00:08] <wgrant> I saw somebody make the tests work with 2.4, but there are code changes needed for 2.6.
[00:09] <wgrant> I might file a bug after breakfast.
[00:09] <joey> that's like, 9 hours from now?
[00:09] <joey> aren't you in the UK?
[00:09] <wgrant> .au
[00:09] <joey> oh, my apologies.
[00:09] <wgrant> +11. It's just past 9am here.
[00:09] <joey> I thought you were in the UK for some reason
[00:10] <wgrant> By that I of course mean +10, because DST finished.
[00:10] <joey> Where abouts? OZ?
[00:10] <wgrant> Yes.
[00:10] <wgrant> Melbourne.
[00:10] <joey> Right on.
[02:42] <ScottK> joey: When you opensource sure.  Sorry to be a party pooper, but you've not opensourced the part of Launchpad that most interests me.
[02:57]  * wgrant agrees with ScottK


[01:44] <thumper> hi davecheney
[01:49] <davecheney> thumper: hi mate
[01:49] <davecheney> just about to get on a plane back to syd
[01:49] <davecheney> got 10 mins to talk
[01:50] <thumper> oh, ok
[01:50] <davecheney> thanks for your CL that hard codes precise
[01:50] <thumper> davecheney: the ec2 screwage was due to the series changes I did some time ago
[01:50] <davecheney> that will probably solve the problem
[01:50] <thumper> davecheney: it does (at least for me)
[01:50] <davecheney> that whole debarcale made me so angry last night
[01:50] <thumper> davecheney: I was broke, made the change, and it worked and deployed something
[01:50] <thumper> sorry about that
[01:51] <thumper> I've been learning a lot about tools recently
[01:51] <davecheney> nah, not your fault
[01:51] <thumper> I also have some man page chagnes
[01:51] <davecheney> I have half a mind to demand that everyone takes one for the team and upgrades off precise so they can see what it's like
[01:51] <davecheney> this shit just works if your laptop runs precise
[01:51] <thumper> davecheney: no-one should be using precise
[01:51] <thumper> davecheney: company policy says you should be using the latest
[01:51] <thumper> davecheney: and upgrade to the new version at beta time
[01:51]  * davecheney agrees with thumper
[01:52] <davecheney> well, i dunno about raring
[01:52] <thumper> those are the rules
[01:52] <thumper> the whole company should upgrade to raring at raring beta time
[01:52] <thumper> always has been therule
[01:52] <davecheney> i think it isn't well communicated to new starters
[01:52] <thumper> heh
[01:52] <davecheney> not that much is
[01:53] <thumper> davecheney: so I want to run ./scripts/generate-docs.py man -o - | gzip > /usr/share/man/man1/juju.1.gz
[01:53] <thumper> but I need a sudo somewhere
[01:53] <thumper> how to I make that work?
[01:53] <davecheney> thumper: no idea, never used that before
[01:53] <thumper> :)
[01:53] <davecheney> is that from the older python juju ?
[01:53] <thumper> no, something I've just made
[01:53] <thumper> about to propose it
[01:53] <thumper> but we need some install magic...
[01:54] <thumper> for the deb
[01:54] <davecheney> ohhhhhhhhh, i see the problem
[01:54] <thumper> right :)
[01:54] <thumper> I wrote it in python because it was a lot faster for me
[01:54] <davecheney> this is normally done in a postinstall
[01:54] <davecheney> right ?
[01:54] <thumper> right
[01:54] <davecheney> that runs as root correct ?
[01:54] <thumper> probably
[01:54] <davecheney> doesn't fakeroot make it work enough for testing ?
[01:54] <thumper> but I don't know how to test it
[01:54] <thumper> well, locally I just go: ./generate-docs.py man
[01:55] <thumper> man ./juju.1
[01:55] <thumper> and it works
[01:55] <davecheney> can you test by making the path relative ?
[01:55] <davecheney> ie
[01:55] <davecheney> gzip > usr/share/....
[01:55] <thumper> I'll ask someone who knows packages :)
[01:55] <thumper> where do we store our packaging info?
[01:56] <thumper> and is there a way I can test it?
[01:56] <davecheney> package info ?
[01:56] <davecheney> the debian/ overlay ?
[01:57] <davecheney> have a look at the build recipes from the juju-core page
[01:57] <thumper> ok, ta
[01:57] <davecheney> the overlay repo is owned by me
[01:57]  * thumper nods
[01:57] <davecheney> no good reason for that
[01:57] <davecheney> it just is
[01:57] <davecheney> sorry, i have tiny internet, so it'll be faster for you to find it than me
[01:58]  * thumper nods
[01:58] <thumper> that's fine
[02:36]  * thumper has munchies
[03:28]  * thumper goes to make dinner, back later to talk with fwereade__
[06:06] <TheMue> morning
[07:47] <bigjools> fwereade__: hi, around?
[07:47] <fwereade__> bigjools, heyhey, in a hangout so responding slowly, but yes
[07:47] <bigjools> fwereade__: ah ok, I'd like to do a quick hangout with you, can you let me know when you're free please
[07:51] <jam> fwereade__: 2 things I need to discuss with you, though I'm about to head to lunch. (1) What have we decided about fmt.Fprintf vs log.Infof? I'd like to land something, that is the last bit remaining. (At this point, I've stopped caring, just looking for an answer so I can land). (2) You wanted to talk about --public.
[07:51] <jam> I should be back in 1-2 hrs. I'll ping you when I'm back
[07:52] <rogpeppe> morning all
[07:54] <davecheney> evenin'
[07:54] <dimitern> jam: Fprintf, as I recall, because log output from commands is discarded
[07:58] <fwereade__> jam, cheers
[08:06] <rogpeppe> jam: i would prefer a two stage solution - first crank up the default logging level to "Notice" and add a way to set the logging level. then use log.Infof and log.Noticef as appropriate.
[08:06] <rogpeppe> jam: the fact that all log output from commands is discarded, even errors, is i think wrong.
[08:19] <fwereade__> bigjools, heyhey
[08:20] <fwereade__> bigjools, available in 3 minutes or so, would you start a hangout please?
[08:20] <bigjools> fwereade__: hi, yes, let me find you on g+
[08:23] <bigjools> fwereade__: invited you
[08:34] <dimitern> rogpeppe: when I was doing upgrade-charm cmd, I added logging and was wondering why virtually no other cmds use it (except the bootstrap I think) and fwereade__ suggested that I should remove it, because the output gets ignored
[08:34] <rogpeppe> dimitern: this is something we need to sort out
[08:35] <rogpeppe> dimitern: i've made my views clear; i suspect i won't win the argument though.
[08:35] <dimitern> rogpeppe: yeah it's a little worrying
[08:35] <rogpeppe> dimitern: thanks for your review this morning, BTW
[08:36] <dimitern> rogpeppe: sure thing
[08:36] <dimitern> rogpeppe: so is this a step towards indirect watching
[08:36] <rogpeppe> dimitern: yup
[08:37] <fwereade__> dimitern, rogpeppe: it is true that we need to sort out logging/feedback; I'm still not so sure it's something we should be committing to fixing for 13.04
[08:37] <dimitern> rogpeppe: cool, how is it going to work for status, i'm curious?
[08:37] <rogpeppe> dimitern: the backing is now free to make whatever changes it likes to the allInfo in response to a mongo change
[08:38] <rogpeppe> dimitern: when the allWatcher backing sees a status change, it will look up the object that the status is referring to in the allInfo and update the status on that
[08:39] <rogpeppe> dimitern: i'm not yet sure if we're guaranteed to see the status change before we see the object itself being created
[08:40] <rogpeppe> dimitern: i think we are, as the status change happens in a separate transaction
[08:41] <fwereade__> .me afk a bit
[08:43] <dimitern> rogpeppe: cool stuff! well for one, unit/machine status won't change on u/m creation, only afterwards (it defaults to pending)
[08:43] <rogpeppe> dimitern: yeah. i'll have to do this for other stuff too, like service config and constraints
[08:44]  * rogpeppe has a look at the txn source.
[08:44] <dimitern> rogpeppe: yeah, sgtm
[08:55]  * rogpeppe just noticed that txn.Runner.Run isn't entirely thread safe
[08:55] <rogpeppe>  but perhaps i'm missing something
[09:03] <davecheney> rogpeppe: eeeeeeeeeeeek
[09:03] <rogpeppe> davecheney: it's nothing too bad
[09:03] <rogpeppe> davecheney: just that bson.NewObjectId does a non-thread-safe lazy initialization of the machine id
[09:04] <rogpeppe> davecheney: i'm about to propose a fix
[09:04] <davecheney> rogpeppe: +1
[09:16]  * rogpeppe strays off the lbox beaten track and gets bitten by a panic in the undergrowth
[09:20]  * TheMue dcc's rogpeppe a plaster
[09:20]  * davecheney visits instantrimshot.com
[09:26] <dimitern> fwereade__: I realised I didn't include removeStatusOp :) good thing to write better tests
[09:26] <fwereade__> dimitern, cheers
[09:27] <dimitern> fwereade__: I think it came along nicely, will propose it in a bit - you wanted to see it, right?
[09:27] <fwereade__> dimitern, please, yeah
[09:33] <rogpeppe> mgz: ping
[09:34] <mgz> hey rogpeppe
[09:35] <rogpeppe> mgz: i'm just trying to diagnose an lbox problem - it's saying no common ancestor between two branches. how can i see the revisions leading up to a particular revision id? (in this case<EMAIL_ADDRESS>[09:36] <mgz> `bzr log -n0 -rrevid:^THAT`
[09:36] <rogpeppe> mgz: ha! i've just worked it out, no probs
[09:36] <rogpeppe> mgz: i did bzr log -r<EMAIL_ADDRESS>[09:37] <mgz> right, -r is smart by default, if something looks like a revid rather than a revno it can work it out
[09:38] <rogpeppe> mgz: interestingly yours only printed a single log message
[09:39] <mgz> yea, you want the leading .. for the history to that point
[09:39] <dimitern> fwereade__:  there it is - https://codereview.appspot.com/8256043/
[09:39] <fwereade__> dimitern, cheers, I'm just writing an essay on it atm, I'll look atthe changes soon
[09:40] <dimitern> fwereade__: wow, an essay, why?
[09:40] <fwereade__> dimitern, well, not really
[09:40] <dimitern> fwereade__: to explain why the approach is better than having status in the docs?
[09:40] <fwereade__> dimitern, I'm just trying to add a concise response to rogpeppe and TheMue's concerns re doc-splitting
[09:41] <dimitern> fwereade__: :) thought so, cheers - I tried to the best of my knowledge to reply, but I'd appreciate yours as well
[09:52] <dimitern> fwereade__: following on status stuff, there are 3 cards on the kanban board which are related. i think i can pick up the one about MA setting status next
[09:55] <rogpeppe> davecheney: https://codereview.appspot.com/8306043
[09:55]  * davecheney looks
[09:57] <rogpeppe> mgz: i think something must have been sticky. i started again with a fresh branch and it all worked.
[10:09] <rogpeppe> davecheney: i can't really see any down sides to the change to use an array rather than a slice. it's about the same number of lines of source, and it has the additional advantage that the indexes are checked at compile time. if there was any additional complexity involved, i'd agree.
[10:09] <rogpeppe> s/lines of source/number of bytes of source/
[10:10] <mgz> rogpeppe: lbox does do some very voodoo things and its assumptions when creating new branches and merging don't seem solid to me
[10:11] <rogpeppe> mgz: yeah, i've got that impression
[10:11] <rogpeppe> mgz: it doesn't help that the error messages often don't include the stderr from the bzr command that failed
[10:11] <rogpeppe> mgz: i only found out what was going on by delving in and changing the source
[10:30] <dimitern> jam: standup?
[10:41] <rogpeppe> fwereade__: ping
[10:42] <rogpeppe> dimitern: ping
[10:43] <dimitern> rogpeppe: pong
[10:43] <rogpeppe> dimitern: i was just wondering why a Unit doesn't have a charm url set by default.
[10:43] <rogpeppe> dimitern: perhaps you could explain?
[10:44] <dimitern> rogpeppe: because it needs to be deployed first
[10:45] <dimitern> rogpeppe: and there are sanity checks to perform in SetCharm as well
[10:45] <dimitern> rogpeppe: makes sense?
[10:46]  * dimitern lunch, bbiab
[10:46] <rogpeppe> dimitern: so you'll always get a charm url set when a unit starts running?
[10:47] <dimitern> rogpeppe: I think so, yes - when it's in the started state the charm's already deployed
[10:47] <rogpeppe> dimitern: cool
[11:22] <jam> dimitern, mgz: the standup time is still now rather than 1hr ago, though we haven't actually had a chance to discuss moving it.
[11:22] <mgz> right, we were just checking
[11:29] <dimitern> back
[11:31] <dimitern> mgz: ping
[11:31] <jam> mgz: you coming to mumble?
[11:36] <jam> fwereade__: I'm back around, though we have our standup for about 15 min. Thanks for commenting on the CL. now just to chat about --public
[11:36] <fwereade__> jam, sure, I'll be around
[11:36] <fwereade__> rogpeppe, hell, sorry, I didn't see that
[11:36] <fwereade__> rogpeppe, what can I do for you?
[11:39] <rogpeppe> fwereade__: np. i got an answer from dimitern
[11:40] <dimitern> fwereade__: so basically LGTM from you?
[11:40] <fwereade__> rogpeppe, ah, yes -- to be specific, the unit sets its charm URL once it knows what charm it's going to use
[11:41] <fwereade__> dimitern, I have a lot of comments that I'm still making -- we should talk, and figure out which of them should be addressed and when, and that will then segue into an LGTM when we agree :)
[11:42] <dimitern> fwereade__: sure, thanks
[11:42] <fwereade__> dimitern, just reviewed, maybe read over it after the standup while I talk to jam?
[11:43] <dimitern> fwereade__: cheers, sgtm
[11:49] <dimitern> fwereade__: ping me when you have 10m for a g+ please
[11:49] <jam> fwereade__: so you had some concern about --public vs local tools
[11:49] <jam> I believe without --public it is roughly equivalent to '--upload-tools' except we are using the public tools.
[11:54] <TheMue> fwereade__: thx for your response regarding the multi docs
[11:54] <fwereade__> TheMue, yw, hope it made some sense
[11:54] <fwereade__> jam, really quick g+?
[11:55] <jam> fwereade__: sure
[11:57] <TheMue> fwereade__: yes, so far i can live with it. only my concerns about transactions done by the accessing software and not the dbms itself still remain. but i'm fine if i'm wrong here. ;)
[12:02] <mgz> oh lord i think this is actually working...
[12:02] <rogpeppe> mgz: always a worrying moment
[12:03] <jam> mgz: you got it?
[12:03] <jam> yay
[12:04] <jam> I wonder if you could have avoided the intermediate commit with "rm -rf *; bzr merge --force -r 0..-1 ..."
[12:04] <jam> but if the commit helps, great.
[12:04] <rogpeppe> fwereade__: have you got time for a v quick G+ chat?
[12:05] <fwereade__> rogpeppe, not just now, I think... about to talk to dimiter and will really need some lunch after that I think
[12:06] <rogpeppe> fwereade__: ok, np. i need to resolve some issues around the allWatcher and split documents.
[12:06] <rogpeppe> fwereade__: i *think* i understand the issues, but i just want to make sure
[12:07] <fwereade__> rogpeppe, ah, ok: was my suggestion that it should be directly analogous to annotation watching sensible?
[12:07] <rogpeppe> fwereade__: not really. we don't want the allWatcher client to be aware of every split.
[12:10] <fwereade__> rogpeppe, ok, so I guess you want status and presence watches feeding into the unit and machine infos
[12:10] <rogpeppe> fwereade__: yup
[12:10] <rogpeppe> fwereade__: and it's the issues around doing that that i need to resolve
[12:10] <rogpeppe> fwereade__: in particular the txn log ordering
[12:11] <rogpeppe> fwereade__: for instance, if the status doc is created in the same transaction as its unit, i don't think there's any guarantee that i'll see the unit before i see its status.
[12:13] <rogpeppe> fwereade__: which means, i think, that i'll need a side-stash where we store items that we've been told about but that we don't yet know the parent docs for.
[12:13] <rogpeppe> fwereade__: because we don't want to be telling a client about a unit status without any other info about that unit.
[12:14] <fwereade__> rogpeppe, or you could drop events for unrecognised statuses on the floor, and when first constructing an X doc grab the status explicitly that one time
[12:15] <fwereade__> rogpeppe, for future changes, just update the fields you need to in the info doc and reorder as appropriate
[12:15] <fwereade__> rogpeppe, (whether those changes are to the object or to its status)
[12:15]  * rogpeppe tries to work out if that's guaranteed to work
[12:16] <jam> interesting, if you start 'lbox submit', and it starts checking your tree, and then you 'bzr switch' while it is still thinking about uploading
[12:16] <jam> it will end up submitting the new branch
[12:16] <jam> even though it tested the old
[12:16] <rogpeppe> jam: ha. "don't do that" :-)
[12:17] <jam> rogpeppe: fortunately both were meant to be submitted eventually
[12:17] <jam> I switched in order to clean up the second for submit
[12:17] <jam> so I just ended up pulling that back into the first
[12:17] <rogpeppe> jam: i've done a similar thing before.
[12:19] <rogpeppe> fwereade__: yes, i think that'll work ok. we'll be doing more work than strictly necessary, but that's true all round anyway
[12:19] <fwereade__> rogpeppe, cool
[12:19]  * fwereade__ has a relieved :)
[12:49] <jam> mgz: is everything looking good?
[12:50] <mgz> think so, doing recipe builds now to see
[12:50] <mgz> got some local prpv
[12:50] <mgz> ....provider test failures, under packing build/test environment that didn't appear when run in branch, but that's not related to any changes in branch so far as I can see
[13:00] <jam> mgz: care to walk me through how to make a bucket public and what its URL would then be?
[13:01] <mgz> on what cloud?
[13:02] <jam> mgz: in this case, canonistack
[13:02] <jam> I think I can 'swift post juju-dist -r ???'
[13:04] <mgz> ".r:*,.rlistings"
[13:07] <jam> mgz: then how do I translate that into a public url?
[13:07] <jam> manually hack the auth info?
[13:13] <jam> looks like if I do a manual auth request I can just grab the publicURL for the swift endpoint.
[13:14] <jam> yay, looks like it worked
[13:14] <jam> we now have a public bucket for canonistack
[13:22] <dimitern> fwereade__: ping
[13:34] <fwereade__> dimitern, pong
[13:35] <dimitern> fwereade__: forgot to ask about moving status docs where they're used, but I figured you meant moving them in unit/machine.go respectively
[13:36] <fwereade__> dimitern, yeah, sorry
[13:37] <dimitern> fwereade__: np, so re lazy creation of status docs - now it's explicit in addUnit/MachineOps
[13:38] <fwereade__> dimitern, sweet
[13:38]  * dimitern started to feel at home in the state package :)
[13:48] <dimitern> fwereade__: something's fishy about removeUnitOps - when there's one unit only it returns s.removeOps
[13:50] <fwereade__> dimitern, always?
[13:50] <fwereade__> dimitern, or when there's one unit *and* the service is Dying?
[13:51] <dimitern> fwereade__: when it's dying, RC=0, UC=1
[13:51] <fwereade__> dimitern, yep -- removal of the last unit should also remove the service
[13:51] <fwereade__> dimitern, (of a Dying service)
[13:52] <dimitern> fwereade__: the thing is, this is not enough I think - we should also remove the status there, right?
[13:53] <fwereade__> dimitern, if removeUnitOps is failing to remove the unit, or any of its associated data, that should be rectified
[13:53] <dimitern> fwereade__: re https://codereview.appspot.com/8256043/diff/11001/state/service.go#newcode611
[13:53] <dimitern> fwereade__: I think I'm correct in putting removeStatusOp there, because it'll be included in the case above
[13:54] <fwereade__> dimitern, hm, ok
[13:54] <dimitern> fwereade__: if I move removeStatusOp at the end we'll miss the case when svc is dying
[13:54] <fwereade__> dimitern, you've found two bugs in unit removal, I suspect
[13:55] <fwereade__> dimitern, one is that the annotation removal is only done at the end, and is missed in the final-unit-of-dying-service case
[13:55] <dimitern> fwereade__: not quite sure what I found yet, but moving it at the end causes a lot of tests to fail
[13:55] <dimitern> fwereade__: right!
[13:55] <fwereade__> dimitern, another is that the constraints removal op is done too early
[13:56] <dimitern> fwereade__: so all these 3 should go after Remove: true of the unit: constraints, status, annotations
[13:56] <fwereade__> dimitern, yep: your mission is to find the right way to code that nicely :)
[13:57] <dimitern> fwereade__: well, just adding them in the append call that adds the removal of the unit doc seems fine?
[13:57] <fwereade__> dimitern, and on general principles it's probably best to do the service removal ops last, once you've sorted out the unit
[13:57] <fwereade__> dimitern, yeah, I'm just whining about having to keep track of the constraint removal op
[13:58] <fwereade__> dimitern, hey, I have an evil idea
[13:58] <dimitern> fwereade__: yeah?
[13:58] <fwereade__> dimitern, drop the Assert from removeConstraintsOp and use it unconditionally
[13:58] <fwereade__> dimitern, mgo/txn will ignore a remove of a doc that doesn't exist
[13:59] <dimitern> fwereade__: yeah, I did that for removeStatusOp as well
[13:59] <fwereade__> dimitern, I noticed -- I think it's a good practice in general
[13:59] <fwereade__> dimitern, for that sort of data anyway
[13:59] <fwereade__> dimitern, excellent
[14:00] <dimitern> fwereade__: sweet! now tests pass :)
[14:00] <fwereade__> dimitern, that'll let you lose a level of indentation in the else clause at the top of the method too
[14:01] <dimitern> fwereade__: where?
[14:01] <dimitern> fwereade__: u.doc.MachineId != "" ?
[14:02] <fwereade__> dimitern, yeah, that becomes `else if ... {` not `else { if ... {`
[14:02] <dimitern> fwereade__: done, only one thing remains
[14:03] <dimitern> fwereade__: in the unit/machine get/set status test when dying
[14:03] <dimitern> fwereade__: Status() always returns successfully, even when the thing is removed
[14:04] <fwereade__> dimitern, yeah, fix that -- now the docs are guaranteed, there's no justification for that missing=pending nonsense
[14:04] <dimitern> fwereade__: that's because of the Pending default case
[14:04] <fwereade__> dimitern, and for that matter there's no justification for Pending being "", either
[14:05] <dimitern> fwereade__: sure, will do
[14:17] <dimitern> jam: now I see the sync-tools cmd's filenames are with underscore, I think this needs to change to conform to the other commands. it's not just bitching, but underscores are usually for test modules :)
[14:29] <rogpeppe> fwereade__: you might be pleased to know that i just saw TestBootstrapAndDeploy pass.
[14:29]  * fwereade__ cheers wildly and flings lacy unmentionables
[14:30] <dimitern> fwereade__: wanna last glance at https://codereview.appspot.com/8256043 before I throw it in trunk?
[14:30] <fwereade__> dimitern, sure, cheers
[14:30]  * rogpeppe is now trying for a clean run of all live tests
[14:30] <dimitern> rogpeppe: with the API?
[14:31] <rogpeppe> dimitern: i'm not sure what you mean
[14:31] <dimitern> rogpeppe: was it not passing before?
[14:31] <rogpeppe> dimitern: it's been the reason the live tests haven't been passing for a month or so
[14:32] <dimitern> rogpeppe: whoa, I totally missed that :) good to hear they pass now
[14:33] <rogpeppe> dimitern: you should run the live tests some time :-)
[14:34] <dimitern> rogpeppe: yeah, with openstack I did, but never with ec2
[14:36] <dimitern> niemeyer: ping
[14:37] <rogpeppe> fwereade__: dear mr on-call reviewer; here's a review for you :-) https://codereview.appspot.com/8318043
[14:37] <fwereade__> rogpeppe, cheers
[14:37] <rogpeppe> hey, we're on revision 12
[14:37] <rogpeppe> in binary
[14:37] <rogpeppe> 1100
[14:38] <dimitern> rogpeppe: not for long :)
[14:38] <rogpeppe> dimitern: 13 next
[14:38] <rogpeppe> dimitern: then NaN
[14:38] <dimitern> or NaB
[14:43] <rogpeppe> TheMue: ping
[14:45] <fwereade__> rogpeppe, LGTM
[14:45] <rogpeppe> fwereade__: thanks
[14:46] <fwereade__> rogpeppe, I think that's probably a trivial tbh, given that I infer you've run the live tests :)
[14:47] <rogpeppe> fwereade__: you looked at the juju home stuff in more detail than me, ISTR. perhaps you could suggest a solution to a related panic i'm seeing in the live tests.
[14:47] <fwereade__> rogpeppe, blarg
[14:47] <fwereade__> rogpeppe, paste it?
[14:47] <dimitern> niemeyer: when you see this, can you please remove the flag from the channel that doesn't allow topic changes? we discussed to start using it to convey information through it, like the on call reviewer, possibly bug counts, etc.
[14:48] <rogpeppe> fwereade__: http://paste.ubuntu.com/5673777/
[14:48] <rogpeppe> fwereade__: i'm not sure when juju home is supposed to be initialized
[14:49] <fwereade__> rogpeppe, before any test that needs to use it
[14:49] <fwereade__> rogpeppe, and at the beginning of cmd/juju.Main
[14:51] <rogpeppe> fwereade__: i can't see how the live tests work at all then
[14:51] <rogpeppe> fwereade__: because AFAICS they don't initialise juju home
[14:51] <fwereade__> rogpeppe, it is possible that they do not: I did not think to verify that in the review
[14:52] <rogpeppe> fwereade__: they do work, apart from that one test
[14:52] <rogpeppe> fwereade__: so there's something odd going on
[14:53] <rogpeppe> fwereade__: ah, i see!
[14:53] <rogpeppe> fwereade__: the authorized-key field doesn't look at JUJU_HOME
[14:54] <rogpeppe> fwereade__: right, i know how to fix it now
[14:54] <fwereade__> rogpeppe, wait, ISTM that we're running a weird test with just the dummy provider mixed in among all the live tests
[14:54] <fwereade__> rogpeppe, why are we creating a totally fresh config in a test that has a config available already?
[14:54] <rogpeppe> fwereade__: actually we're just leveraging the dummy provider there, not using it
[14:55] <rogpeppe> fwereade__: we use it to put the tools into, then fake 'em up into the actual environment
[14:55] <fwereade__> rogpeppe, hmm, ok, I see
[14:55] <fwereade__> rogpeppe, not sure I entirely approve but that's the least of my worries :)
[14:56] <fwereade__> rogpeppe, anyway, thanks
[14:56] <rogpeppe> fwereade__: np
[14:59] <niemeyer> dimitern: I believe anyone can change the topic
[14:59] <niemeyer> dimitern: Via chanserv
[15:00] <dimitern> niemeyer: do you know how of hand, or I should try google? :)
[15:00] <niemeyer> dimitern: Hold on
[15:01] <niemeyer> dimitern: /msg chanserv topic #juju-dev I am a new topic.
[15:01] <niemeyer> dimitern: This is handy too, for future uses: /msg chanserv help
[15:02] <dimitern> niemeyer: cheers!
[15:02] <fwereade__> need to think for a bit, going for a walk, be back later
[15:20] <mattyw> anyone know what this means (juju-core bootstrap --upload-tools on aws) 2013/04/03 15:17:02 ERROR JUJU:jujud:bootstrap-state jujud bootstrap-state command failed: state entity tag not found in configuration
[15:21] <mgz> mattyw: see the "Cannot bootstrap instances in ec2" thread on the juju-dev list
[15:38] <rogpeppe> fwereade__: another review for you (this one actually fixes the live tests) https://codereview.appspot.com/8321043
[15:39] <dimitern> rogpeppe: the diff is screwed
[15:39] <rogpeppe> dimitern: thanks; will try again
[15:40] <rogpeppe> dimitern: PTAL
[15:40] <fwereade__> rogpeppe, awesome, LGTM
[15:41] <rogpeppe> fwereade__: ta!
[15:42] <rogpeppe> dimitern: i'm not sure how to run the openstack live tests.
[15:43] <rogpeppe> dimitern: do i need an account on canonistack or something?
[15:43] <dimitern> rogpeppe: you need creds yeah, there's a wiki page about it, let me find it
[15:44] <rogpeppe> dimitern: i'll submit anyway if that's ok - it must be better than the old one, and it's not tickling anything provider-specific
[15:45] <dimitern> rogpeppe: well jujutest is used in both, but yeah, I agree it's good to land
[15:46] <dimitern> rogpeppe: if openstack live tests fail (which is not uncommon on canonistack) we'll fix them
[15:46] <rogpeppe> dimitern: yeah; but the logic we're actually testing here is all state-based.
[15:46] <dimitern> rogpeppe: https://wiki.canonical.com/InformationInfrastructure/IS/CanonicalOpenstack?action=show&redirect=CanoniStack
[15:48]  * rogpeppe looks for his 2-factor keyring
[15:54]  * dimitern thinks provisioner tests are kinda crap - no testing is done for errors while starting a machine
[15:56] <dimitern> does it sound sane to add some way to cause StartInstance to fail in the dummy provider for testing sake?
[16:47] <TheMue> so, time to leave. one final review for today: https://codereview.appspot.com/8322043
[16:48] <TheMue> n8 all
[17:43] <rogpeppe> fwereade__: if you're around, another CL for your delight and delectation: https://codereview.appspot.com/8328043/
[17:46] <dimitern> rogpeppe: I can take a look
[17:46] <dimitern> rogpeppe: meanwhile - https://codereview.appspot.com/8330043/ ?
[20:05] <thumper> morning
[20:07] <fwereade__> thumper, heyhey
[20:08] <thumper> hi fwereade__
[20:08] <fwereade__> thumper, do you have any clue why upgrade-juju is using version.Current?
[20:08] <thumper> fwereade__: in which place?
[20:08] <fwereade__> thumper, I think it just uses it once, in bumpedVersion
[20:09] <thumper> fwereade__: that is (IMO) used only for developers to force a new version
[20:09] <thumper> fwereade__: which I'd love to find a different way around
[20:09] <fwereade__> thumper, sure, but I don;t think it's correct, is it?
[20:09] <thumper> um...
[20:09]  * thumper looks
[20:09] <fwereade__> thumper, the agent-version is relevant, and the version of the tools we *built* is relevant
[20:10] <fwereade__> thumper, or at least the above two might be
[20:10] <fwereade__> thumper, but I don;t see what the current client version has to do with it
[20:11] <thumper> fwereade__: I think the expectation there is that the client version will be equal or greater than any existing tools
[20:11] <fwereade__> thumper, seems like a bit of an assumption to me, but I guess it's a derail anyway
[20:12] <thumper> fwereade__: yes, I agree that the whole method is wrong
[20:12] <thumper> fwereade__: could be easily fixed
[20:28]  * thumper does a few drive by boy-scout branches to feel like something is improving
[20:51]  * fwereade__ heartily endorses thumper's behaviour
[20:51] <fwereade__> thumper, btw, do you know offhand what's a valid launchpad id?
[20:52] <thumper> fwereade__: where are you looking?
[20:52] <thumper> and id for what?
[20:52] <fwereade__> thumper, I'm peering suspiciously at the charm.validUser regexp
[20:52] <fwereade__> thumper, user id
[20:53] <fwereade__> thumper, in charm/url.go
[20:53] <thumper> hmm...
[20:53] <thumper> I'd have to look it up
[20:53] <thumper> what is the regex?
[20:53] <fwereade__> thumper, https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=2&ved=0CDsQFjAB&url=https%3A%2F%2Fhelp.launchpad.net%2FYourAccount%2FNewAccount&ei=nZVcUcjSO8GS7AaHnIDwCA&usg=AFQjCNE_bzVarX3yyWj40q2JeFnCtuT-hw&sig2=UjM0ZR4vv8kZOCr3nVeAzQ&cad=rja
[20:53] <fwereade__> er, not that, whatever it is
[20:54] <fwereade__> thumper, regexp.MustCompile("^[a-z0-9][a-zA-Z0-9+.-]+$")
[20:54] <thumper> hmm.. not sure we can have capitals
[20:54] <thumper> A short unique name, beginning with a lower-case letter or number, and containing only letters, numbers, dots, hyphens, or plus signs.
[20:55] <thumper> so perhaps...
[20:55] <thumper> that regex matches what LP says
[20:55] <thumper> though I'm not sure that uppercase is valid there
[20:55] <fwereade__> thumper, ok, excellent, I just couldn't find where it was specified
[20:55] <thumper> but I would have to read the LP source
[20:56] <fwereade__> thumper, seems like it might be covered, so let's go with it
[20:56] <fwereade__> thumper, they'll all come from LP anyway
[20:56] <fwereade__> thumper, thanks
[20:56] <thumper> kk
[21:00]  * thumper goes to grap his boxing wraps to have something to do while the tests run
[22:15]  * thumper rages a little
[22:20] <bigjools> thumper: against a machine?
[22:20] <thumper> bigjools: against our shitty package dependency chains
[22:20] <thumper> and circular deps
[22:20] <thumper> especially in testing
[22:20] <bigjools> ruh roh
[22:22]  * thumper made another package
[22:26] <thumper> hmm...
[22:26] <thumper> my refactoring got just a little out of hand...
[22:26]  * thumper stops refactoring
[22:27] <thumper> davecheney: I have a branch that is more paletable with "precise" in it, has many of the fixes I wanted for removing version.Current without actually removing it yet
[22:28] <thumper> simple refactoring grew past 800 line diff, so I've stopped
[22:28] <thumper> tests all still pass \o/
[22:28] <davecheney> thumper: SUBMIT!!
[22:28] <thumper> davecheney: well, proposing first :0
[22:28] <davecheney> seriouslu, i'm blocked at the moment
[22:29] <davecheney> ok, i shall review in anger
[22:34] <fwereade__> thumper, this might very *very* well with what I'm about to propose, I just realised I was about to start replacing version.Current with "precise" everywhere :)
[22:34] <thumper> fwereade__: wait...
[22:35] <thumper> review incoming
[22:35] <thumper>  https://code.launchpad.net/~thumper/juju-core/mongo-driveby/+merge/156992
[22:35] <thumper> other one coming...
[22:36] <thumper> davecheney: fwereade__: Rietveld: https://codereview.appspot.com/8348043
[22:37] <davecheney> thumper: ta
[22:38]  * thumper goes to get gym kit on
[22:42] <thumper> fwereade__: I hope this doesn't clash with what you've been doing
[22:43] <fwereade__> thumper, nope, not at all so far, it *might* be a disturbingly perfect matchup
[22:45] <thumper> fwereade__: that that would be fortuitous
[22:48] <thumper> I'm about to head off to the gym shortly
[22:50] <thumper> hmm... I just spotted a copy and paste error
[22:56] <fwereade__> thumper, you have a preliminary review
[22:56] <fwereade__> thumper, lots of questions I'm afraid
[22:56] <thumper> :(
[22:56] <thumper> ok
[22:57] <fwereade__> thumper, take heart, I'm +1 on the fundamentals, mostly just quibbling about the details, only really unsure in a couple of places
[22:58]  * thumper nods
[22:58] <thumper> I'll look after the gym
[23:40] <fwereade__> thumper-gym, davecheney: PTAL at https://codereview.appspot.com/8352043
[23:42] <fwereade__> thumper-gym, davecheney, it's a minimal bootstrap --fake-tools; I have verified that I can use cross-series envs fine, so long as I fake up all required series at bootstrap time
[23:42] <fwereade__> thumper-gym, davecheney: adding it to upgrade-juju is harder because I get distracted and want to fix things, so I think it's best left for now
[23:43] <fwereade__> thumper-gym, davecheney: it's not a complete fix but it hopefully gives davecheney in particular a useful way forward
[23:45] <davecheney> fwereade__: tahnks
[23:45] <fwereade__> davecheney, if you get a mo, please try it out, in case I've done something stupid
[23:46] <fwereade__> davecheney, juju bootstrap --upload-tools --fake-series precise
[23:46] <fwereade__> davecheney, I think covers your use case
[23:46] <fwereade__> davecheney, you might want precise,quantal if you're on raring and need quantal charms
[23:47]  * fwereade__ -> bed


[04:32] <da0487> Hello. I am just learning how to triage. Is this where I report bugs that are actually feature requests?
[04:33] <greg-g> da0487: you should report them as bug, and they will be marked as "Wishlist"
[04:33] <greg-g> and, if it is about a specific application, the best place for those requests to go is on the bug tracker for that application (so, for instance, for banshee, you would use bugzilla.gnome.org)
[04:36] <da0487> I mean I found a bug on launchpad which is actually a feature request. I belive the wiki says to put the bug number here
[04:37] <da0487> https://bugs.launchpad.net/ubuntu/+source/firefox-3.0/+bug/339772
[04:38] <greg-g> da0487: ah, yes, I can mark it as wishlist for you
[04:38] <greg-g> thanks!
[04:38] <da0487> yay! a successful triage
[04:39] <greg-g> da0487: if you really want to be a hero, forwarding this bug upstream to the firefox bugzilla would be _ideal_
[04:40] <ripps> Does anybody here know how to run autogen.sh within debian/rules? I tried asking #ubuntu-motu, but there not really talkative today.
[05:22] <patanachai> bug #338818 > wishlsit
[05:22] <patanachai> wishlist, sorry
[05:26] <crimsun> patanachai: err, i'm not sure i would actually set that one; scott has a pretty good handle on what Importance that bug would be
[05:27] <patanachai> crimsun: oh, thanks for let me know.
[06:05] <dholbach> good morning
[06:07] <mrooney> dholbach: morning!
[06:08] <mrooney> hm it is actually about bed time for me
[06:08] <dholbach> hiya mrooney
[07:00] <mrooney> IntuitiveNipple: canonical employees are above man-pages, obviously!
[07:00] <IntuitiveNipple> huh?
[07:01] <mrooney> your notify-osd bug
[07:01] <dholbach> mrooney: ???
[07:01] <mrooney> bug 339796
[07:03] <mrooney> I was mostly jesting but also remarking on how the universe packages seem to be put to stricter standards then main packages by canonicalers
[07:03] <Hobbsee> mrooney: why does it need one?  it's not callable, as it were
[07:03] <mrooney> Hobbsee: I didn't file the bug :)
[07:04] <Hobbsee> also, feature freeze and such would have been a concern, i expect
[07:04] <Hobbsee> true
[07:04] <mrooney> I just think the man page reqs are odd
[07:05] <Hobbsee> i don't think various canonical packages actually go through motu review, anyway
[07:05] <Hobbsee> so there could be anything in them ;)
[07:05] <mrooney> haha
[07:05] <Hobbsee> well, except for any packages that the archive admins deemed unsuitable, and threw out
[07:05] <mrooney> the fact that firefox doesn't have a manpage astounds me
[07:06] <dholbach> manpages are very nice to have when they make sense - for things living in usr/lib that are not really callable (like panel applets) they don't really make sense though
[07:06] <IntuitiveNipple> For something that is so visible, it would make sense to have a man-page. First place I look when trying to figure something out is a man-page.
[07:06] <mrooney> not that firefox originates from firefox
[07:06] <mrooney> err
[07:06] <mrooney> from canonical
[07:06] <mrooney> but I have to google how to use profiles every time
[07:06] <dholbach> I'm sure that patches are welcome
[07:07] <mrooney> I am not sure Mozilla would feel that way, but you never know, I guess!
[07:07] <Hobbsee> dholbach: i'm not sure that's the issue - i suspect mrooney's more is "why do the canonical people get special treatment?  And should they?"
[07:07] <Hobbsee> (unless you're referring to firefox there, and not the dx stuff)
[07:07] <mrooney> yeah I was actually referring to firefox itself
[07:08] <mrooney> as a side comment on a really glaring missing manpage
[07:08] <dholbach> I'm not sure a manpage for notify-osd makes a lot of sense, but I'm sure that if somebody writes one, it'll be included
[07:08] <dholbach> if you want to tell Canonical employee <X>, <Y> and <Z> that they are doing a crap job, do it
[07:09] <IntuitiveNipple> I always read debian policy (12.1) to mean that it is a bug not to have a man-page: "Each program, utility, and function should have an associated manual page included in the same package"
[07:09] <dholbach> specific complaints are much more helpful than "no canonical people care about manpages"
[07:11] <mrooney> dholbach: I was really just making a sarcastic joke about a bug report that was filed :)
[07:12] <dholbach> and I was really just saying "tell people if you think they do a bad job and if you have an idea how they can improve, tell them as well" :)
[07:12] <mrooney> dholbach: but my specific comment would be "why are community universe packages held to such strict standards by MOTU when main doesn't follow the same standards"
[07:12] <mrooney> I guess it seems sometimes like main has less strict standards, which seems out of place
[07:12] <Hobbsee> "make canonical people follow the freezes, and the QA standards, like everyone else is asked to"
[07:12] <Hobbsee> does that work?
[07:13] <dholbach> Hobbsee: it still is unspecific
[07:13] <Hobbsee> how so?
[07:15] <dholbach> I personally think that telling person X that case Y could have been handled better if Z was done (specific) is much more helpful than "(all / some) canonical people don't do Z" (unspecific)
[07:16] <dholbach> and I don't think it's fair to the people who do Z
[07:16] <dholbach> anyway... I should be taking the dog for walk
[07:16] <mrooney> dholbach: I wasn
[07:16] <mrooney> errr
[07:16] <mrooney> I wasn't saying X person does Y
[07:16] <mrooney> I was saying X people aren't held to Y standards
[07:16] <dholbach> X was fairly unspecific :)
[07:18] <mrooney> dholbach: I think what I was trying to point out was "main rules aren't a superset of universe rules", although I got the impression they were supposed to be
[07:18] <mrooney> oh well have fun with the dog, I hope it isn't too cold
[07:18] <dholbach> 3°C, but the sun is shining, so all's good
[07:19] <mrooney> ah yes also if the wind is still the temperature is often irrelevant
[07:23] <dholbach> mrooney: I agree though, that the archive admins who review the package in the last instance have different priorities than the MOTU team who review the package on REVU
[07:24] <mrooney> dholbach: yeah, that is part of it really, they are different teams so I guess they can't be expected to value the same things and such
[07:24]  * Hobbsee wonders why the canonical stuff doesn't go through REVU
[07:24] <dholbach> Hobbsee: even MOTUs don't have to go through MOTU
[07:24] <dholbach> errr
[07:24] <dholbach> through REVU
[07:24] <dholbach> https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages
[07:24] <dholbach> MOTUs can upload new packages directly to the archive. However they are greatly encouraged to have a new package reviewed prior to uploading. (cf. MOTU/Council/Meetings/2007-02-23)
[07:25] <dholbach> if we want a strict policy, we should try to find one that works for everybody and talk to the TB about it
[07:25] <Hobbsee> hrm.  So then it's just a difference between those who have upload rights, and those who don't.  And those who can take someone else's package, and upload it directly.
[07:26] <dholbach> I've been an advocate of bringing the NewPackages process in line with the regular sponsoring process, but wasn't successful with that
[07:27] <Hobbsee> hmmm
[07:27] <Hobbsee> (why weren't you successful?)
[07:28] <dholbach> concerns about quality of the packages and the general feeling that four eyes are better than two
[07:28] <dholbach> the reality is though that we have a huge backlog in REVU and that everybody is free to ask somebody else if they're unsure about their own verdict
[07:29] <dholbach> I'd much prefer if (like with any other upload) the sponsor would take responsibility for their judgement
[07:29] <Hobbsee> hmmm
[07:29] <Hobbsee> REVU uploads are a fair amount larger, and can contain a lot more bugs, though
[07:30] <dholbach> same goes for new upstream versions or big packaging changes :)
[07:30] <Hobbsee> upstream has usually tested those
[07:30] <Hobbsee> and/or has a bugtracker.
[07:30] <Hobbsee> but you'll probably find that's also why people aren't fans of sponsoring huge packaging changes, if they don't know a lot about it
[07:30] <dholbach> I think that people who say "this looks good to me" should be able to upload those
[07:31] <dholbach> anyway... I'll go out now - see you later :)
[14:06] <bddebian> Boo
[19:48] <YoBoY> hi
[19:49] <mathiaz> hi - is there a canned response to ask someone to open a new bug?
[19:51] <mathiaz> ex: bug 225919: the last comment is a different bug - is there a generic response to ask the commenter to open a new bug?
[19:53] <charlie-tca> I don't believe there is. Usually a "thanks for your report, but it is a different issue. Would you please open a new bug report for it?"
[19:54] <YoBoY> if you can reproduce the bug mathiaz you can open the second bug yourself
[19:55] <MightyTweek> mathiaz: There are some canned responses on the wiki. https://wiki.ubuntu.com/Bugs/Responses
[19:56] <mathiaz> MightyTweek: I don't see any in the wiki page.
[20:01] <MightyTweek> mathiaz: Yes, you're right. If you come up with one you might consider adding it to the list.
[20:58] <andol> blueyed: Do you mind if I ask you a queston regarding bug #270468 and its reporting to Debian?
[21:00] <andol> blueyed: Well, never mind that first bug mentioned. I was actually thinking about bug #315136.
[21:07] <blueyed> andol: sure.
[21:08] <blueyed> andol: in the best case you still have the directory with debian's .dsc/package and your changed one.. then from the extracted package directory, just run "submittodebian". if reportbug is configured ok, this will give you the diff between ubuntu/debian and allow you to send it to debian.
[21:10] <blueyed> andol: see https://wiki.ubuntu.com/Debian/Bugs#Using%20submittodebian%20to%20forward%20patches%20to%20Debian
[21:12] <blueyed> andol: I'll have to go now.. please just drop me an email and I can help you out tomorrow.. (or ask here or in #ubuntu-motu). Thanks and cu.
[21:23] <andol> Anyone else: Follow-up on the question to (and answer from) blueyed. Before the bug/patch is submited to Debian, should it actually be tested against a Debian unstable, or is it enough to make an educated guess whatever the bug applies there too?
[21:36] <danage> when's pidgin 2.5.5. coming through the repos? icq is b0rked in 2.5.2 but you probably all know that
[21:41] <bcurtiswx> danage you can get it through getdeb.net if your anxious
[21:53] <andol> Ok, I'll try #ubuntu-motu instead
[22:09] <Ampelbein> Hrm... my FFe-request bug #340151 has been marked duplicate to another report which I do not think is correct. Opinions on that?
[22:10] <bdmurray> Ampelbein: it seems fixed already
[22:11] <Ampelbein> Oh. I did not want to undupe the report before asking here.
[22:11] <danage> bdmurray: do you think there will be a freeze exception for jaunty?
[22:12] <bdmurray> Ampelbein: the activity log doesn't attribute the action to you
[22:12] <bdmurray> danage: I've no idea
[22:13] <danage> Ampelbein: #340151 is a dupe of #340075
[22:15] <Ampelbein> danage: why? one is a freeze-exception-request, the other a bug report. in my opinion there should not be a mix-up.
[22:15] <danage> it's an identical issue
[22:15] <danage> you could convert freeze exception request to feature request
[22:16] <danage> but it relates to a bug, so think they should be duped
[22:17] <danage> oh you filed it
[22:18] <Ampelbein> yeah. because i did not want to mix the bug report with the FFe
[22:19] <danage> perhaps just see what happens :)
[22:21] <Ampelbein> will do that. The report WAS marked a dupe so i wondered, what would be the correct way to go on.
[22:21] <danage> let's hope it makes its way into jaunty
[23:53] <mathiaz> bdmurray: is there a way (tag?) to track bugs that are related to LTS -> LTS upgrades?
[23:53] <mathiaz> bdmurray: bug 239704
[23:54] <mathiaz> bdmurray: ^^ affects upgrade from hardy to intrepid *and* hardy to next LTS
[23:54] <mathiaz> bdmurray: but doesn't apply to intrepid+


[21:28] <nielsslot> botch: looks like it's still not fixed yet: https://bugs.launchpad.net/ubuntu/+source/kdebase-workspace/+bug/280997
[21:28] <botch> nielsslot: thanks for the link..
[21:29] <nielsslot> it was in the release notes of intrepid :)
[21:29] <Zvezdichko> Good evening there
[21:29] <Zvezdichko> :)
[21:34] <marisol> alguien me puede ayudar con mi tarjeta grafica
[21:34] <marisol>  alguien me puede ayudar con mi tarjeta grafica
[21:35] <JackWinter> !es | marisol
[21:51] <thorns> Will kde 4.2 update the current kde 4.1 in intrepid or is it current only in jaunty?
[22:12] <christopher> Looking for help with a wine question: I have a keychain digital pic frame that runs an exe to let me download pictures onto it..... not finding a way in wine, but then again, I'm not too savvy with wine either. Any help please?
[22:34] <Borg^Zap> i mounted a windows partition and i need to get into the Documents and Settings dir and i need to know how to enter the spaces
[22:34] <guedressel> Borg^Zap: ok - whats your problem?
[22:34] <p_quarles> Borg^Zap: you can escape spaces with either quote marks of \
[22:36] <Borg^Zap> ok so im trying to copy a dir and i need to put in "cp /hda1/Documants and Settings/*" how do i make that work?
[22:36] <guedressel> A) you use quotes "path"
[22:36] <p_quarles> Borg^Zap: by using \ or " to escape the spaces
[22:37] <Borg^Zap> ok thanks
[22:37] <guedressel> B) you escape the bad chars like p_quarles tells you
[22:54] <ubuntu_> ...
[22:55] <zetheroo> ok .. at first I was told that this was simply not possible ... but now its happening to more people .. Ubuntu Intrepid causes Kernel Panics and yet on the same system Kubuntu Intrepid does not! --
[23:04] <zer0o> guys how do i manually install a downloaded program from a terminal? there's no instruction in the file and its a srv
[23:06] <jussi01> !nickspam > esay_uzak
[23:06] <jussi01> zer0o: err, what exactly do you mean?
[23:06] <zer0o> i downloaded an application from a website
[23:06] <zer0o> how do i manually install it?
[23:07] <jussi01> zer0o: ahh, what app is it?
[23:07] <zer0o> ive already unzipped it and put it in my home
[23:07] <zer0o> now?
[23:07] <zer0o> there's no instructions in the file
[23:07] <zer0o> and is not in the repos
[23:07] <jussi01> ie. can you give me a link to have a look?
[23:07] <zer0o> teeworlds
[23:07] <zer0o> http://teeworlds.com/
[23:08] <jussi01> zer0o: its in the repos here...
[23:08] <cinar> Selam iyi geceler
[23:08] <zer0o> ive got hardy
[23:08] <zer0o> maybe is not in mine
[23:08] <zer0o> anyway
[23:08] <jussi01> !tr | cinar
[23:08] <zer0o> isnt there a command? to type in the terminal?
[23:08] <cinar> Thank You! zer0o
[23:09] <zer0o> o_O ?
[23:09] <jussi01> !info teeworlds hardy
[23:09] <cilkay> Hello. I've added "deb http://ppa.launchpad.net/project-neon/ubuntu hardy main" to /etc/apt/sources.list, ran apt-get update and then attempted to apt-get install kde-nightly-kdebase but no such package was found. If I examine the repo using a browser, I can see the kde packages. Why isn't apt-get finding them?
[23:09] <zer0o> see
[23:09] <zer0o> so how do i do?
[23:09] <jussi01> zer0o: patience!
[23:09] <cilkay> I want to try the KDE nightly packages in Hardy without blowing away KDE 3x.
[23:09] <zer0o> sure, i wasnt being impatient... i was only asking
[23:09] <zer0o> :D
[23:09] <jussi01> cilkay: #amarok.neon
[23:10] <cilkay> thanks jussi01
[23:11] <cilkay> It's a strangely-named channel.
[23:11] <jussi01> zer0o: ahh its an easy one
[23:11] <jussi01> zer0o: cd into the folder
[23:11] <jussi01> then simply do: ./teeworlds
[23:12] <zer0o> no way
[23:12] <zer0o> how did u find out?
[23:13] <jussi01> zer0o: I downloaded it and looked...
[23:13] <zer0o> bash: ./teeworlds: No such file or directory >>> but when u open a terminal u r in ur home, so how's that possible?
[23:15] <zer0o> i think im missing something, i downloaded the file and unzipped it into my home so now i have teeworlds-0.5.0-linux_x86 in my home
[23:15] <jussi01> zer0o: its in a folder cd teeworlds-0.5.0-linux_x86
[23:16] <zer0o> so it doesnt need any installation
[23:16] <zer0o> its a kind of bootable package
[23:16] <zer0o> right?
[23:16] <jussi01> zer0o: yeah, its compiled alread
[23:16] <jussi01> y
[23:17] <zer0o> well how do i add it on my kmenu > games ?
[23:19] <jussi01> zer0o: thats a little more complicated and I cant for the life of me remember how kde3 does it
[23:20] <zer0o> can u explain it for kde4 and i'll try to "translate" it for me?
[23:20] <killermach> is there a GUI tool for setting up NFS?
[23:20] <zer0o> btw, are u able to play? when i start it i click on "connect" and it tries to connect to "localhost:8303" but it doesnt start and remains like this 4ever
[23:22] <BlueEagle> !u
[23:23] <xL__> hey all
[23:23] <dabear_> y r u so mad @ him, typin' u instead o' you saves tim u noww!
[23:23] <dabear_> 11
[23:23] <killermach> BlueEagle: awesome.. another super hero fighting lazy  where ever it is :)
[23:24] <gnuton> Hi there
[23:24] <BlueEagle> killermach: :)
[23:25] <gnuton> I can't see kdm using XDMCP... any hints?
[23:25] <xL__> hi gnuton
[23:25] <gnuton> hey xL__
[23:25] <gnuton> it shows a empty X11 screen...
[23:25] <xL__> gnuton: how are you
[23:25] <xL__> ?
[23:26] <gnuton> xL__: i'm fine thanx.. just a bit tired..
[23:26] <gnuton> xL__: and u?
[23:26] <xL__> me too
[23:26] <gnuton> xL__: where are u from?
[23:26] <gnuton> are u european?
[23:26] <xL__> like dead :))
[23:27] <Blitzz|Kubuntu> How do I end a runaway WINE process? I can't find it in KSysGuard
[23:27] <xL__> yes ,, where are toy from?
[23:27] <ngirard> Hi all. On kubuntu 8.10, after upgrading, i've found my control panel to be empty. Any thoughts ?
[23:27] <gnuton> Blitzz|Kubuntu: try to run ps -ax | grep wine
[23:27] <gnuton> xL__: I'm italian
[23:28] <Blitzz|Kubuntu> arning: bad ps syntax, perhaps a bogus '-'?
[23:28] <gnuton> xL__: but I live in finland
[23:28] <Blitzz|Kubuntu> *Warning
[23:28] <gnuton> Blitzz|Kubuntu: it works for me. Try to run without the '-'
[23:28] <Blitzz|Kubuntu> I get nothing
[23:29] <gnuton> Blitzz|Kubuntu: so you don't have any wine process running :P
[23:29] <Blitzz|Kubuntu> Yes I do
[23:29] <xL__> ping me pls :)))
[23:29] <gnuton> xL__: thank you for versioning me :P
[23:29] <Blitzz|Kubuntu> It's stuck and on a repeating sound buffer and it's on the taskbar
[23:29] <gnuton> xL__: why have I to ping u? :P
[23:29] <xL__> you are very polite gnuton
[23:30] <xL__> to see if i am alive hahahaha
[23:30] <gnuton> xL__: :D
[23:30] <gnuton> xL__: are u german?
[23:31] <xL__> no i am from Greek
[23:31] <gnuton> usually most of people are german. So thinking that everyone is german is a good approximation :D
[23:31] <xL__> Greece
[23:31] <xL__> i mean
[23:31] <gnuton> xL__: :D
[23:31] <gnuton> xL__: I really like the greece :D
[23:32] <maxbaldwin> !gc
[23:32] <maxbaldwin> greece.... gr? gc?
[23:32] <bazhang> !gr
[23:32] <xL__> i like finland too
[23:32] <gnuton> xL__: my parents live in Taranto.. that is very close to patrasso :D
[23:32] <xL__> gr
[23:32] <gnuton> xL__: the finland is too dark and cold.
[23:33] <neoTheCat> how do i setup wireless, or can someone point me to somewhere that shows, how i can get wireless as soon as i bootup? i do not want to use knetwork manager.
[23:33] <gnuton> xL__: But the finland have a lot of beautifl girls! :D
[23:34] <Blitzz|Kubuntu> I don't understand this.
[23:34] <xL__> i like girls :)))
[23:34] <Blitzz|Kubuntu> How do I kill a program that doesn't even have a visible process?
[23:34] <gnuton> neoTheCat: I'm not sure about that.. but I think that you can have a look to  /etc/network/interfaces
[23:34] <Blitzz|Kubuntu> ...Or a working Close menu option
[23:34] <gnuton> neoTheCat: you should put there something to set your lan
[23:35] <gnuton> Blitzz|Kubuntu: you can't kill a program not visibile... simply because all the process are visible! :P
[23:35] <neoTheCat> gnuton:  yeah, i have everything setup in there, and it *looks* correct, but when i restart networking, DHCPDISCOVER keeps timing out
[23:35] <Blitzz|Kubuntu> Then why is the program running and in the taskbar?
[23:36] <Blitzz|Kubuntu> Also, my Mute doesn't work.
[23:36] <gnuton> neoTheCat: ... I can't help you so..  I never hadn't that problem
[23:36] <Blitzz|Kubuntu> So that I can shut off the stupid program's constant buzzing
[23:36] <Blitzz|Kubuntu> Ugggh, I give up.
[23:36] <neoTheCat> okalee dokalee.  thanks.
[23:37] <gnuton> :D
[23:37] <gnuton> Poor blizzz :P
[23:37] <blizzz> i don't think so ^^
[23:44] <m_tadeu> hi...how can I connect to an access point with a hidden essid
[23:45] <killermach> what packages do I need to install for ldap server?
[23:46] <MikeH> Anyone here managed to sync their N95 (Or other S60 phone) with Kontact?
[23:50] <Guest51> hi
[23:52] <dare1> how to install kcontrol in ubuntu?
[23:53] <gordon_> Hello
[23:54] <gordon_> I got a question or two...I hope someone can help
[23:54] <Guest9453> m_tadeu: if you know the ssid, just type it in i think
[23:55] <m_tadeu> doesn't work...
[23:55] <m_tadeu> it only works when the router is broadcasting the ssid
[23:58] <gordon_> With Wine installed can you install a Windows based software right from its original disk?
[23:58] <ActionParsnip> hi all, does anyone play penumbra? When I execute the game it seems to have a display capability beyond what my monitor will display. Can anyone please advise?
[23:59] <ActionParsnip> gordon_: yes, just run wine /path/to/setup.exe after you mount the cd (assuming setup.exe is the appname ion the cd)
[23:59] <gordon_> Thanks...I want to install COD4 and run it from Wine...Im new to Linux