[00:25] <mwhudson> jelmer: http://bazaar.launchpad.net/~jelmer/openoffice/hosted/files
[00:27] <lifeless> reasonably snappy in that view
[00:28] <mwhudson> yeah, i'm pleasantly surprised
[00:28] <jelmer> mwhudson: nice
[00:29] <mwhudson> jelmer: the scanner is still choking on it if you try to look at the branch page :)
[00:31]  * spiv yawns... he slept in!
[00:59] <lifeless> spiv: ping
[01:00] <lifeless> spiv: I vant reviews ;)
[01:00] <spiv> lifeless: ok :)
[01:01] <jelmer> lifeless: speaking of which... :-)
[01:02] <lifeless> jelmer: right, push stuff?
[01:02] <jelmer> lifeless: Yeah, InterBranch.pull()
[01:04] <lifeless> I need to look at that in context with smart server pulls
[01:04] <lifeless> I thought push would be sufficient, but it turns out it isn't
[01:04] <mwhudson> jelmer: how large is that openoffice import btw?
[01:05] <jelmer> mwhudson: ~4.5 Gb IIRC
[01:05] <jelmer> lifeless: k
[01:06] <mwhudson> jelmer: that's still pretty large!
[01:07] <jelmer> lifeless: it now also looks like the InterBranch.pull / InterBranch.push code is necessary for svn nested trees support
[01:08] <mwhudson> jml: can you explain in a short sentence what "Is there a way to get lp-reviews to participate on the list the way BB does" means?
[01:08] <lifeless> jelmer: ?
[01:08] <jml> mwhudson: let me try :)
[01:09] <lifeless> mwhudson: BB acts like a member of the list; it responds to things on the list ([MERGE] mails, and responses to [MERGE] mails with review commands in them), it sends mail to the list (when something is merged, or someone votes through the webui)
[01:09] <lifeless> mwhudson: you never need to go to the webui
[01:09] <jml> mwhudson: "Watch the mailing list for specially flagged messages; when these messages appear, create a merge proposal, send a message to that thread and monitor the discussion as if it were taking place on Launchpad"
[01:10] <mwhudson> lifeless: you never need to go to the webui for code reviews either
[01:11] <lifeless> mwhudson: thats not the end goal; it would be a bit silly to have that as a goal.
[01:11] <lifeless> the goal is to be inline with the list discussions
[01:11] <mwhudson> jml: so the problem with code review as it is is that you have to send things to special addresses?
[01:11] <jelmer> lifeless: bzr nested tree support has a local dictionary of where external trees can be found, by file id
[01:11] <mwhudson> (merge@ for new proposal, mp+<id>@ for comments)
[01:11] <lifeless> jelmer: in Branch8, yes.
[01:11] <jelmer> lifeless: that seems like a reasonable thing to do, given that their location can move and that you'd also want the historical location to move
[01:11] <jml> mwhudson: I think the problem is that Launchpad will send the email out again
[01:11] <jelmer> lifeless: in svn, that location is tied to the tree
[01:12] <jml> mwhudson: and yes, the special address
[01:12] <jelmer> lifeless: so whatever default infrastructure there is at the moment I'll need to override for push and pull
[01:12] <mwhudson> jml: mm, that too
[01:12] <jml> mwhudson: I think abentley's last post on the thread nails the problems.
[01:12] <jml> to the mast, like a flag.
[01:12] <lifeless> mwhudson: bb *adds* to the discussions on the list; lp-reviews currently appears to want to own the discussion
[01:13] <lifeless> participate vs being the forum
[01:13] <mwhudson> right
[01:14] <lifeless> python's code reviews happen separately to discussion; I find it very hard to have any internal zeitgeist about whats in the pipeline there
[01:16] <abentley> lifeless: It sometimes feels like you guys want to use Code Review instead of Bundle Buggy, but want Code Review to be just like Bundle Buggy.
[01:16] <lifeless> abentley: I love BB to bits; I think its soo close to Just Right that its not funny.
[01:17] <jelmer> same here, except for the occasional downtime bb works really really well
[01:18] <lifeless> abentley: I'd like to be using Code Review because it has all the admin stuff built in, uses the lp login rather than separate credentials, and is something other projects can trivially turn on
[01:20] <abentley> lifeless: OpenID authentication, even LP team awareness would be possible if I thought it was worth the effort.
[01:21] <lifeless> of course; I think its better to keep improving Code Review though
[01:22] <jml> also, it'd be pretty awesome if Code Review (which is general purpose) became as good for you as the custom-tailored tool BB
[01:23] <lifeless> jml: indeed
[01:23] <jml> by "pretty awesome", I meant "pleasantly surprising"
[01:23] <jml> except that I don't see a reason to aim for anything lower than that
[01:24] <lifeless> for instance, bb has nicer email syntax; why can't code review have as nice a syntax?
[01:24] <lifeless> (quoting Aaron about it being nicer)
[01:25] <fullermd> Code review makes me sad because it suggests I'll have to dive back into the mess of figuring out how to deal with LP's emails  :|
[01:25] <jml> I personally think the syntax should be: (review 'approve)
[01:26] <jml> with options on (setq ok-to-merge-p (lambda () t))
[01:26] <spiv> jml:  :set jml_is_trolling=yes
[01:26] <lifeless> jml: (lisp allowed be YHWH) ?
[01:26] <jml> man, forgot the quote.
[01:26] <lifeless> an, forgot the h
[01:27] <jml> lifeless: nice syntax is vague and a little bit subjective. have you filed bugs about it?
[01:27] <lifeless> and the m. fail cold fingers
[01:27] <lifeless> jml: I've asked Aaron when I get told by lp that I got it wrong
[01:28] <lifeless> jml: bug filing when one isn't sure its a bug feels like makework
[01:29] <jml> lifeless: on this, our feelings differ.
[01:30] <lifeless> I have, do and will file bugs whenever I think its a bug, but won't, and it will stay like that in the absence of some reason to think it should change [repeated 'have you filed bugs?' questions are not sufficient or necessary].
[01:30] <lifeless> bah missed the end of the phrase,
[01:30] <jml> lifeless: ok
[01:30] <lifeless> won't when I am not sure
[01:31] <lifeless> so please, either tackle whatever issue you have head-on with me, or stop the somewhat snarky 'have you filed bugs' questions.
[01:31] <jml> ok.
[01:32] <lifeless> concretely, if you mean 'I think this is a bug, could you make sure there is one about this', thats fine - say that :)
[01:32] <jml> lifeless: here's what I mean.
[01:32] <jml> lifeless: I don't know what your difficulty with the launchpad mail review syntax was
[01:33] <jml> lifeless: and I don't know how to find out what it is without asking you
[01:33] <jml> lifeless: and until just now, I didn't know you had any issues at all.
[01:34] <jml> lifeless: which makes it hard for me to participate (even silently) in discussions about making code review better for you.
[01:35] <lifeless> thats all true
[01:36] <lifeless> that said, every issue I've had I've brought with one or more developers of code review, at the time
[01:36] <lifeless> when they say 'bug' I file a bug
[01:36] <jml> which is great :)
[01:37] <jml> but some things are open questions. it'd be good to have those discussed on some sort of asynchronous, stable medium.
[01:37] <jml> whether the bug tracker (I'm very happy to say wontfix), or launchpad-users or something.
[01:38] <lifeless> I'm not on lp-users; whats the SNR there like at the moment?
[01:40] <jml> lifeless: there have been less than fifty threads this year. <5 are pure noise, the rest are divided about evenly between announcements, requests for help and suggestions
[01:40] <poolie> lifeless: launchpad-users is excellent
[01:40] <poolie> so low volume
[01:40] <poolie> i get the impression not all devs read it, but jml does
[01:41] <jml> poolie: hi, wb!
[01:41] <lifeless> https://launchpad.net/~launchpad-users -> LP down try again message :(
[01:41] <poolie> fwiw i rarely use the lp mail interface because signing is a slight hassle, but my miss rate when i do is no worse than BB
[01:41] <jml> really? yikes.
[01:41] <poolie> lifeless: yeah me too
[01:42] <poolie> back now for me
[01:42] <igc> morning
[01:47] <lifeless> jml: two things
[01:47] <lifeless> jml: I've forwarded you one discussion I had with Aaron to give you data.
[01:47] <jml> lifeless: I saw that, thanks.
[01:49] <lifeless> jml: but in general, I think its unreasonable to expect that every issue a user encounters of ones products *will* be in fora one is also in; one needs to deal with the discovery of issues that happened in the pasts by asking for that data, not by asking if the right thing was done
[01:49] <lifeless> particularly when the right thing being done doesn't imply that you'd have had earlier access to that data.
[01:52] <jml> lifeless: ok.
[01:55] <lifeless> anyhoo; I'm on lp-users now; I won't guarantee to ask all questions there
[01:55] <poolie> lifeless: btw i saw last week that launchpad echelon is somewhere near the planning horizon for that team
[01:55] <poolie> by which i mean it may happen next year
[01:55] <lifeless> if I have a review question and a faster/closer source is available, that source will be asked
[01:55] <poolie> that feature name will give the fudsters something to chew on :)
[01:55] <poolie> but, it means smarter two-way interaction with mailing lists, for instance telling bugs when they're being discussed
[01:56] <lifeless> but when one isn't, I will ask lp users rather than private mail to a specific dev
[01:56] <lifeless> jml: ^
[01:59] <jml> lifeless: sweet, thanks.
[01:59] <poolie> lifeless: so what's the bottom line as far as switching?
[02:00] <jml> lifeless: the main thing for me is that if there's something left to do or to talk about further, we should get it written down somewhere.
[02:00] <lifeless> poolie: Well, we can but try. I'm a little [lot] concerned that it partitions the list
[02:01] <lifeless> the ui headaches are discussable
[02:01] <lifeless> not having as clean an interface as bb is sad but not a deal breaker.
[02:01] <lifeless> not getting the reviews into my bzr list folder is the biggest issue
[02:02] <poolie> is that just a matter of having suitable headers for filtering?
[02:02] <lifeless> I don't know
[02:02] <lifeless> anyhow, I think the next step should be what I asked for on the list
[02:03] <lifeless> someone that knows code review's design, how its meant to work etc, should update our developer docs
[02:03] <lifeless> to say how we should do things to work with code reviews
[02:04] <jml> +1
[02:04] <lifeless> the exercise of doing that will beneficial in a few ways, and if it can't be done successfully that rather indicates that there is a showstopper :P
[02:06] <lifeless> speaking of reviews
[02:07] <lifeless> poolie: you resubmit:'d a patch of mine a while back, I disagreed, you went silent.
[02:07] <poolie> which one?
[02:07] <lifeless> poolie: I've updated the patch and sent it for review again; this time I want bb:approve, even though I haven't changed that part fo the code.
[02:08] <lifeless> http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C1241072466.9565.45.camel%40lifeless-64%3E
[02:08] <lifeless> concretely, -Dlock should only have a side effect while we fix up tests
[02:08] <lifeless> once they are fixed the overload of using it to trigger error will go because the test suite will always error
[02:09] <lifeless> so using a different variable really doesn't make sense to me, because you'll always with -Dlock -Dlock_check when testing during the transition fixup period
[02:09] <lifeless> and -Dlock_check won't have any effect outside the test suite
[02:11] <lifeless> poolie: jam has given tweak: but as you did 'resubmit' before I thought you'd appreciate the chance to see it again
[02:12] <poolie> isn't this what -E is supposed to be for?
[02:12]  * lifeless looks up -E
[02:13] <lifeless> poolie: same thing
[02:13] <lifeless> -Elock == -Dlock checked as the code does
[02:14] <poolie> what do you mean?
[02:15] <lifeless> oh, its not quite the same
[02:16] <lifeless> anyhow, the point is - I want a temporary thing for a transition period only
[02:16] <poolie> lifeless: aiui -E is for things that affect the running of the test suite
[02:16] <poolie> whereas debug_flags is isolated per test so that we can test -D
[02:16] <lifeless> -Dlock already exists and is ideal for doing this
[02:16] <poolie> but won't it be masked off when each test runs?
[02:16] <lifeless> no
[02:16] <poolie> anyhow, looking at that patch without rereading my original mail i have no objection
[02:17] <lifeless> ok thanks
[02:17] <poolie> ^^ and with your explanation here
[02:17] <poolie> igc, re the option naming thread
[02:17] <poolie> i guess it's not a big deal but these threads seem kind of inefficient
[02:17] <poolie> (i'm not complaining about your posts at all i'm just thinking aloud)
[02:18] <poolie> there are some small things we want to fix, and they might be reflections of or connected to larger problems
[02:18] <poolie> and we need to fix the big things but i have this nagging feeling the conversation always goes on to that at the expense of making incremental changes
[02:18] <poolie> maybe it's ok and it's the only way we'll work up energy to do the big things
[02:19] <lifeless> I think uncontentious small changes should just get done; and big things should be really carefully addressed - needs constraints, known lessons *before* putting solutions on the table
[02:19] <igc> poolie: well even the big things usually end up being tackled a bit at a time
[02:19] <lifeless> 'we're only as smart as the amount of time we spend before we come up with an answer'
[02:19] <igc> poolie: the trick is making small changes along the right path
[02:20] <poolie> mm
[02:20] <poolie> i agree with both of you
[02:20] <poolie> i guess, i'd like the small things discussed more in terms of "this is going down the right/wrong path" rather than "oh look at this big problem over there"
[02:21] <igc> poolie: UI threads have a history of spinning out of control - everyone and their dog has an opinion :-)
[02:21] <lifeless> poolie: that suggests we should have the sprint asap to determine the path
[02:21] <poolie> right, and it's probably not worth squelching it
[02:21] <poolie> agree
[02:21] <igc> and that's a general comment - not just for bzr
[02:21] <poolie> have to say i'm not feeling super keen on flying right at the moment
[02:22] <poolie> so, 1-should we do it before UDS; and 2-where?
[02:22] <lifeless> I don't think we have time
[02:23] <poolie> 1 probably depends on whether we'll empty the brisbane core work queue
[02:23] <lifeless> 2 weeks; several things to prep for allhands, network deltas needed, 1.15 to release, iter_changes to overhaul for commit
[02:23] <igc> lifeless: I think you should do it at UDS and include me when you can
[02:23] <poolie> oops i forgot there'll be no igc
[02:23] <lifeless> I think after UDS is likely best
[02:24] <igc> before UDS, I agree with Robert - let's keep focus on 1.15
[02:24] <lifeless> bbc took the better part of a week for me to methodically aggregate our already learnt lessons and needs
[02:24] <lifeless> its not a parallelisable task - more people doing it means more people have the aggregate state, but thats all
[02:25] <igc> I for one are busy enough on nested tree reviews, tuning log dir performance and looking at branch-specific rules
[02:25] <lifeless> heck, on nested trees I'm still deeply scared that we're basically going in the wrong direction
[02:28] <lifeless> mmm, I should be more clear
[02:29] <lifeless> on the planning sprint, I think we should do a bunch of analysis before hand
[02:29] <lifeless> bbc is radically different to all the prior proposals
[02:29] <lifeless> yet we'd talked about it at every sprint for the 3 or so years before
[02:30] <lifeless> bbc is different because I took the time to really step back, clear head, and get to the root of the issues
[02:31] <lifeless> someone needs to do the same thing for repository/branch management headache, inline-vs-checkouts and so on
[02:32] <lifeless> on nested trees, what I mean is that having a lookaside datastructure and a composite tree really seems to drive complexity up to me, rather than having things that iterate choose to recurse when they want to
[02:34] <lifeless> poolie: concretely, I think we should finish bbc; get commit fully fixed for it (someone needs to do iter_changes), get networking fully done (spiv and I are halfway through the delta representation, jelmer is reporting memory issues,...)
[02:35] <lifeless> poolie: we should estimate when we'll get these things done (soon!) and plan a sprint in brisbane a few weeks after that
[02:35] <lifeless> a few weeks to allow time to sit and think *before* we get together.
[02:38] <igc> I think it's really import we keep focus on nailing networking & making bbc production strength right now
[02:39] <mwhudson> spiv: does 'bzr serve' use a thread-per-request model?
[02:40] <spiv> mwhudson: yes
[02:44] <mwhudson> spiv: how do you think it would scale to 100 concurrent connections? :)
[02:44] <spiv> mwhudson: depends on what the connnections do :)
[02:45] <spiv> mwhudson: (I don't really have any basis to make a good guess about it)
[02:46] <mwhudson> spiv: well, i'd be pretty confident that if it forked, it wouldn't do very well at 100 connections
[02:46] <mwhudson> spiv: i guess if it only did vfs stuff, it wouldn't use much ram?
[02:46] <spiv> Right.
[02:47] <lifeless> you don't need to alter bzr at all to just do vfs stuff :P
[02:47] <spiv> (there may be bugs with transferring large files, but if so we can fix those...)
[02:48] <mwhudson> lifeless: i'm not sure what you're saying
[02:48] <lifeless> mwhudson: I mean that the methods available are just in a dict
[02:48] <lifeless> a plugin can strip them back to a 'I want these only' set
[02:49] <mwhudson> yes, spiv already said as much in an email
[02:49] <lifeless> cool
[02:54] <lifeless> jelmer: is that packed?
[02:55] <jelmer> lifeless: the memory usage thing?
[02:56] <jelmer> lifeless: It was 4 packs, all around 1Gb
[02:56] <lifeless> thumper: ^ it will shrink :P
[02:56] <lifeless> jelmer: I suspect it will shrink massively if you pack it
[02:56] <lifeless> jelmer: I was asking for disk space usage, not about the memory bug
[02:56] <jelmer> ah
[02:56] <lifeless> the memory thing you need to debug
[02:57] <jelmer> lifeless: do I need to buy more memory first before I pack ? :-)
[02:57] <lifeless> no
[03:04] <lifeless> poolie: you've gone quiest
[03:04] <poolie> silence indicated assent
[03:04] <lifeless> cool
[03:04] <poolie> also, sneezing my head off :)
[03:04] <poolie> (thunk)
[03:04] <lifeless> :(
[03:05] <poolie> but seriously that did sound like a good plan
[03:06] <lifeless> spiv: actually, jam has reviewed stuff; I just didn't see it because he didn't copy me/used the web ui
[03:31]  * igc lunch
[03:34] <poolie> lifeless: i think we should create a ~bazaar-reviews team, enable its mailing list feature, and subscribe it to reviews
[03:35] <poolie> that should mean there's a single archive for all reviews, people can subscribe to just reviews if they wish, and they can read it through gmane etc
[03:37] <lifeless> poolie: we already have a lsit of all devs
[03:37] <lifeless> poolie: why create a new list?
[03:38] <lifeless> poolie: nevertheless; I reiterate - updating our docs should be the next step.
[03:39] <lifeless> we don't have to land the updated docs until we're happy, but we should be updating them before changing the workflow
[03:39] <lifeless> because they are meant to be our reference manual
[03:39] <poolie> lifeless: i'd create a new list just because avoiding mixing paint in lists seems to be a good guideline in launchpad
[03:40] <poolie> you can always add ~bzr to that new team or vice versa
[03:40] <poolie> cf problems with bialix not wanting the ppa spam sent to ~bzr
[03:40] <lifeless> I actually mean<EMAIL_ADDRESS>:)
[03:47] <poolie> if that works properly that's fine
[03:47] <poolie> so, actually i wonder about migrating our list there too
[03:47] <lifeless> that might be nice
[03:47] <poolie> mostly in the hope of getting less spam to deal with manually
[03:48] <lifeless> I think the spam will be identical
[03:48] <poolie> it seems like i'm the only person who moderates the list, it gets hundreds of spams per week, and it's either not possible or not a priority for IS to make the filtering better
[03:48] <lifeless> what I want for reviews is for us to 1) update docs 2) search for solutions found doing that 3) trial, 4) mov
[03:48] <poolie> um
[03:48] <lifeless> e
[03:48] <poolie> it looks like a broken filter to me
[03:49] <poolie> i don't get nearly so many unfiltered spam in my own mail
[03:49] <lifeless> if the docs end up saying  'join team A and join team B' then I think something is broken
[03:49] <poolie> anyhow i agree with that plan, except that the stages can overlap
[03:49] <lifeless> lp makes it hard to undo mistakes
[03:50] <lifeless> but sure, I'm not against some overlap; I am against us forgetting to do one of these because we rush ahead; and I definitely want a clear separation between 'investigate how it works' and 'move'
[03:56] <lifeless> I think broadly I'm being conservative because missed reviews are a pain, and we often have a backlog *anyway* so its worth a small number of people doing the analysis of a move before many people are affected
[03:56] <lifeless> see for instances python's dvcs pep for a similar situation
[03:59] <poolie> ok
[03:59] <poolie> lifeless: btw my previous review for -Dlock did also mention updating the flag documentation
[03:59] <poolie> if this is only transitional it may not be a big deal
[04:00] <lifeless> poolie: right
[04:00] <lifeless> its a bandaid until we can always be asserting
[04:00] <lifeless> poolie: have I mentioned my little aws gui ?
[04:00] <poolie> no
[04:01] <lifeless> bzr branch lp:~lifeless/txaws/client; cd client; bin/aws-status
[04:13] <Kilroo> Well, I gotta say, I'm considerably happier with my Bazaar experience since this morning when I figured out that the bzr-eclipse plugin apparently chokes on spaces in paths.
[04:15] <lifeless> heh :(
[04:15] <Kilroo> Now it's just a question of exactly how I'm going to use it.
[04:28] <helebek> hi all, anybody using bzr on windows? I need some help, please.
[04:29] <lifeless> helebek: ask your question :)
[04:29] <sidnei_> helebek: ask, and an answer you shall receive.
[04:29] <lifeless> poolie: let me know what you thnk of the aws gui
[04:31] <helebek> I installed the windows binaries from the bazaar website successfully. Everything I do local works fine, when I try sftp I get an error from a python script.  Any ideas?
[04:31] <helebek> thank you, btw
[04:33] <sidnei_> helebek: can you connect to the host with putty?
[04:33] <helebek> yes I can connect with putty and plink
[04:34] <helebek> With sftp://python script giving the error is transport.py (line 213). It says "AttributeError: 'str' object has no attribute 'get' "
[04:34] <sidnei_> oh, yikes. might be a known issue. lifeless?
[04:36] <helebek> With bzr+ssh it asks for the password and then says authentication is successful. Then buff "bzr: ERROR: Connection closed: please check connectivity and permissions"
[04:37] <poolie> Kilroo: that kind of sucks, can you file a bug please? javierder is working on it quite actively
[04:38] <Kilroo> I think there's already a bug on it, actually.
[04:38] <poolie> lifeless/others, rfc, i'm cleaning up the ui stuff and am thinking of merging all of bzrlib/ui/*py into just one ui.py
[04:38] <poolie> it may marginally improve load time
[04:38] <poolie> and some of the files are getting small
[04:38] <poolie> any conceptual objections, and also
[04:38] <Kilroo> No, wait. That might have been for spaces in a url you're trying to pull from.
[04:39] <Kilroo> I'll check, and either file or comment as appropriate
[04:39] <lifeless> poolie: conceptual objection: its mixing paint :P.
[04:39] <poolie> i vaguely recall implementation problems with python (pyc files?) when a directory module turns into a file
[04:39] <lifeless> poolie: the other transform is a problem
[04:39] <lifeless> foo.pyc is found before foo/__init__.pyc
[04:40] <Kilroo> but as long as you don't give the path any spaces to turn into %20's, you don't run into situations where bzr-eclipse can't find your working tree because there's no such place as My%20Documents.
[04:40] <poolie> so you want the base class separate from the text version?
[04:40] <poolie> Kilroo: the rule is this (modulo bugs): if it's a URL, it should be escaped as %20; if it's a non-url filename it should not have those escapes
[04:41] <lifeless> I think it is cleaner, particularly when we expect dramatically different implementations aorund
[04:41] <lifeless> e.g. gtk
[04:41] <lifeless> Kilroo: please be sure to file a bug on bzr-eclipse
[04:42] <lifeless> poolie: "
[04:42] <lifeless> poolie: "
[04:42] <lifeless> Reporting suggestions through the bug tracker is fine, though if they're
[04:42] <lifeless> likely to be controversial or require extensive discussion it's better
[04:42] <lifeless> to go to the list.  (This one doesn't.)"
[04:42] <lifeless> poolie: ^ thats why I want to keepreviews on the list :)
[04:47] <poolie> lifeless: so the subdirectory is a nonissue you think?
[04:47] <poolie> why?
[04:48] <poolie> well, actually
[04:48] <poolie> there are a few related issues
[04:49] <poolie> aiui the objections to discussing features in the bug tracker are: new designs may not break down into clear separate actionable bugs at first
[04:49] <poolie> some people may want to be involved but not subscribed to all bugs
[04:49] <poolie> bugs are just linear unthreaded and not so good for long conversations
[04:50] <poolie> and it's good for a bug to just contain a summary of what needs to be done not the full discussion
[04:50] <poolie> personally i mostly agree with most of them
[04:51] <poolie> the third doesn't apply to code reviews which are threaded (though they may be inferior to mail in other ways)
[04:51] <poolie> regarding the first and last, i would agree that general discussion should be separate from discussing a particular patch
[04:51] <poolie> but that's true on the list as well
[04:52] <lifeless> the existence of code isn't a reliable separator for those things
[04:52] <lifeless> how often do we have a thread turn into a patch, or vice verca
[04:54] <Kilroo> I find that question moderately intriguing.
[04:54] <lifeless> bad quotes from other channels: "It was once said a Black man would be President when pigs fly.Indeed 100 days into Obama's presidency,swine flu."
[04:57] <lifeless> back shortly, lunchy style break time
[06:54] <lifeless> poolie: did you give aws-status a spin?
[06:59] <poolie> ew
[07:00] <poolie> lifeless: not yet, are you really keen that i do?
[07:00] <poolie> i guess so or you wouldn't be asking... :)
[07:03] <lifeless> well, I know that activation energy is the large thing usually
[07:04] <lifeless> my theory is if I nag you past that, you'll give it a spin and it will be there thereafter if you want to play more :)
[07:09] <poolie> it may work better if i'm already in aws-mode
[07:09] <poolie> at the moment i've been in email mode striving for finishing-ui-mode
[07:09] <lifeless> :)
[07:09] <poolie> now interrupted by shops-mode
[07:09] <poolie> and, i may not return this afternoon actually
[07:09] <poolie> so have a good weekend if i don't see you
[07:09] <lifeless> you too
[07:09] <poolie> bug me about it again
[07:09] <lifeless> you can be sure of that :)
[07:10] <lifeless> did you fly in this morning?
[07:13] <jml> if any of have a spare moment, could you please take a look at https://bugs.edge.launchpad.net/launchpad-code/+bug/310347
[07:18] <spiv> jml: added a spare comment ;)
[07:18] <jml> spiv: thanks :)
[07:20] <lifeless> hmm, evo quit by itsself. fun
[07:41] <lifeless> wish me luck, that batch of hpss patches is wending its way up to pqm now
[07:48] <jml> lifeless: good luck.
[07:52] <jml> spiv: I just sent a patch to the mailing list that you might approve of.
[08:07] <lifeless> jml: bazaar ?
[08:08] <jml> lifeless: yeah.
[08:15] <jml> lifeless, spiv: can one of you two please land that for me?
[08:15] <jml> I wonder if I should try to get pqm privs for bzr.
[08:21] <spiv> jml: I can do that now, sure.
[08:21] <jml> spiv: thanks.
[08:21] <spiv> jml: I only held off because I wondered if perhaps you already had privs :)
[08:22] <jml> spiv: I'm pretty sure I don't. (Is there a way to find out, other than submitting?)
[08:22] <spiv> jml: ask lifeless (or equiv. pqm admin)
[08:28] <lifeless> jml: ask spm
[08:28] <lifeless> night all
[08:28] <jml> ok. thanks.
[08:28] <jml> lifeless: g'night.
[08:28] <spm> lifeless: too late I'm not here.... oops.
[08:28] <spm> damn. shouldn't have responded.
[08:29] <spm> jml: actually - that is something best sent via rt. if only so that we have the audit trail if you ken.
[08:30] <lifeless> spm: asking *about* != asking for
[08:30] <jml> spm: yeah, although right now I'm only interested in finding out whether I have permissions.
[08:31] <jml> spm: and I'd rather just submit a branch than file an RT to figure that one out :)
[08:32] <spm> jml: :-) and no, you dont have access
[08:32] <jml> spm: ta
[08:49] <lifeless> and it landed, woo
[08:52] <spiv> jml: pqm got a conflict, presumably with what lifeless just landed, resolving and firing again.
[08:52] <jml> spiv: thanks.
[08:53] <lifeless> spm: presumably :P
[08:53] <lifeless> bah
[08:53] <lifeless> spiv: ^
[08:53] <lifeless> spiv: also, way less roundtrips. We're under 9!
[08:56] <spiv> lifeless: Nice.  Very nice!
[09:10] <lifeless> not stacked sadly
[09:10] <lifeless> anyhoo next week I want us to pair
[09:11] <lifeless> and figure out sketches for getting the rest down
[09:12]  * igc dinner
[11:57] <gnomefreak> is there a way to rename a branch or just push revision with new name?
[11:58] <Peng_> gnomefreak: Just...rename the directory with your standard "mv" or whatever.
[11:59] <gnomefreak> Peng_: that would consit of sshing into launchpad right? if so how
[12:00] <Peng_> gnomefreak: Oooh, Launchpad. Can't you do it from the web UI?
[12:00] <gnomefreak> checking
[12:01] <gnomefreak> under change details is what i want i think
[12:02] <gnomefreak> Peng_: thanks it worked
[12:03] <Peng_> :)
[12:27] <wgrant> Hmmm. 'bzr revert' doesn't seem to back changes up if the file is involved in a conflict caused during a pull.
[12:28] <wgrant> Is that because it tries to avoid backing up changes during merges, and assumes that a conflict could only result from a merge onto a clean tree?
[12:59] <RAOF> Hm.  bzr-git is now at 10 minutes CPU time and 2GiB RAM useage, but it looks like it's a-workin.
[13:00]  * RAOF thanks jml for the extra GB of ram.
[13:04] <RAOF> On the plus side, the ram usage is steadily decreasing.
[14:11] <bac> hi, is there a PPA for bzr-gtk?
[14:13] <lifeless> wgrant: we record the hash of files output during merge
[14:13] <wgrant> bac: https://edge.launchpad.net/ubuntu/+ppas?name_filter=bzr-gtk suggests that there are several official-looking ones.
[14:13] <lifeless> wgrant: so we can revert cleanly without backups then
[14:13] <wgrant> lifeless: Right, I've since looked through that code thoroughly.
[14:13] <bac> thank wgrant
[14:13] <wgrant> lifeless: Bug #370334
[14:14] <wgrant> lifeless: But you can't revert to the files immediately before the merge.
[14:14] <wgrant> lifeless: Because they were uncommitted changes.
[14:16] <lifeless> wgrant: mark it confirmed high :)
[14:17] <bac> wgrant: doesn't look like any of those support bzr 1.14.
[14:17] <wgrant> lifeless: Thanks!
[14:17] <wgrant> lifeless: Er, but I have no bzr Importance privileges.
[14:18] <lifeless> wgrant: join the team :P
[14:18] <lifeless> or remind me tomorrow; its late here
[14:18] <wgrant> lifeless: I was quite surprised to see you around at this hour, yes...
[14:41] <wgrant> abentley: Thanks.
[14:41] <abentley> wgrant: np.  Of course, this means I have no plausible deniability when people ask why this bug isn't fixed. :-)
[14:42] <wgrant> abentley: Heh.
[16:01] <Kamping_Kaiser> hm... Woudl be nice if bzr fell back to LC_CTYPE=C if nothing else was set :/
[16:06] <Peng_> What does it do instead?
[16:10] <GaryvdM> I broke my windows installation, and I'm having some difficulty getting ssh working . Putty is setup, PageANT is running with a new private key, I've uploaded the new public key.
[16:10] <GaryvdM> But I get bzrlib.errors.ConnectionReset: Connection closed: please check connectivity and permissions
[16:11] <GaryvdM> How can I debug this?
[16:24] <Kamping_Kaiser> Peng_, crashes. (this is 0.8, its possible it Just Works in the current release)
[16:24] <Peng_> Kamping_Kaiser: 0.8 is *incredibly* old.
[16:26] <Kamping_Kaiser> Peng_, yes, shipped in Ubuntu 6.06 (which this server is running) :/
[16:27] <GaryvdM> Hmm: I just noticed this error: http://pastebin.com/d3fc9a661
[16:28] <GaryvdM> Maybe I need to delete all my keys on lp and start over.
[16:29] <Peng_> Kamping_Kaiser: The PPA might still support 6.06. https://launchpad.net~bzr/+archive
[16:29] <Peng_> Err./
[16:29] <Peng_> Kamping_Kaiser: https://launchpad.net/~bzr/+archive
[16:29] <Peng_> I blame my Internet connection! :P
[16:30] <Kamping_Kaiser> Peng_, i'll check, thanks.
[16:32] <GaryvdM> Yhea - ssh working now. :-)
[18:38] <LarstiQ> beuno: bzr 1.14 is in the non-beta ppa now.
[18:54] <rockstar> abentley, hey.
[18:55] <abentley> rockstar: hey
[18:56] <rockstar> format_registry.aliases() returns a set with three strings in it.  What format strings are those for?  Repositories?
[18:56] <abentley> rockstar: You're talking about the bzrdir format registry?
[18:56] <rockstar> abentley, ah, that should make it obvious...
[19:07] <jam> abentley: ping
[19:08] <abentley> jam: pong
[19:08] <jam> did you still want to chat about whatever it was yesterday?
[19:09] <abentley> jam: sure.
[20:02] <S11001001> rebase hackers: why is rebase trunk 1.13-compatible and 1.15-compatible, but not 1.14?
[20:02] <LarstiQ> S11001001: because 1.14 has the same api as 1.13?
[20:03] <LarstiQ> assuming it checks api compatibility, not bzr version
[20:03] <S11001001> api
[20:04] <LarstiQ> there you have it then :)
[20:04] <S11001001> Unable to load plugin 'rebase'. It requested API version (1, 15, 0) of module <module 'bzrlib' from '/usr/local/lib/python2.6/site-packages/bzrlib/__init__.pyc'> but the minimum exported version is (1, 14, 0), and the maximum is (1, 14, 0)
[20:04] <S11001001> and bzrlib/__init__.py has api_minimum_version = (1, 14, 0)
[20:04] <LarstiQ> S11001001: right, that is a mistake and I'm expecting a 1.14.1 release for it
[20:05] <S11001001> okay, thanks LarstiQ
[20:05] <LarstiQ> S11001001: if you're willing, you can safely edit that (1, 14, 0) into (1, 13, 0)
[20:07] <S11001001> sounds good
[20:07] <S11001001> merci
[20:50] <jonnydee1> Hi, I've just checked out (lightweight) the rebase trunk from http://people.samba.org/bzr/jelmer/bzr-rebase-old/trunk because the version available in Jaunty seems not to be compatible with bzr 1.14.
[20:50] <jonnydee1> The last trunk's revision, however, seems not to be compatible with 1.14, either, because it already requires bzr 1.15. So I tried to get a previous revision using 'bzr pull -r -2' and got the following error message:
[20:50] <jonnydee1> bzr: ERROR: Cannot lock LockDir(http://people.samba.org/bzr/jelmer/bzr-rebase/trunk/.bzr/branch/lock): Transport operation not possible: http does not support mkdir()
[20:51] <jonnydee1> Anyone any idea?
[20:51] <LarstiQ> BasicOSX: what are the 1.14.1 plans?
[20:51] <LarstiQ> jonnydee1: the error you get because in a lightweight checkout, 'pull' goes to what you're bound to, being http://people.samba.org/.., which is not writable.
[20:52] <LarstiQ> jonnydee1: you can use `bzr revert` instead to make the tree state be the same as in a prior revision.
[20:52] <jonnydee1> So a pull is not a readonly operation?
[20:52] <LarstiQ> jonnydee1: however, bzr 1.14 shoud have api compatility 1.13, instead of the 1.14 it has
[20:52] <jonnydee1> @LarstiQ: Thanx for your hint
[20:53] <LarstiQ> jonnydee1: so you can change bzrlib/__init__.py, (1, 14, 0) -> (1, 13, 0)
[20:53] <LarstiQ> jonnydee1: if pull was a readonly operation, how would it help you? :)
[20:54] <jonnydee1> I mean readonly in terms of "do not modify the repository I pull from"
[20:54] <LarstiQ> jonnydee1: the point being that pull operates on the branch, which you don't have access to in this case.
[20:54] <LarstiQ> jonnydee1: in general, I think it's a very bad idea to use lightweight checkouts over high latency links.
[20:54] <BasicOSX> LarstiQ:  1.14.1 milestone created, plan? tag bugs to that milestone and discuss when devs happy with bug list for me to make a release?
[20:55] <jonnydee1> BTW: "bzr revert -r -2" also gives me a bzr: ERROR: Cannot lock LockDir(http://people.samba.org/bzr/jelmer/bzr-rebase/trunk/.bzr/branch/lock): Transport operation not possible: http does not support mkdir()
[20:55] <LarstiQ> BasicOSX: sounds good. My vote is for the list of changes to be just the api version, we can roll a 1.14.2 later
[20:55] <LarstiQ> jonnydee1: ah hmm.
[20:56] <BasicOSX> LarstiQ:  been out of loop for a couple days (real job stuff) 1.14.1 regression release?
[20:56] <jonnydee1> ok, but I understood that a pull on a lightweight checkout tries to pull into the remot branch :) -- seems pretty logical regaring the fact that a lightweight checkout doesn't have history information...sorry, my fault
[20:57] <LarstiQ> jonnydee1: I suggest you `bzr reconfigure --checkout`
[20:57] <LarstiQ> BasicOSX: basically.
[20:58] <BasicOSX> :-( I'm going to get another condolence email from RMS!
[20:58] <LarstiQ> BasicOSX: practice makes perfect!
[20:58] <jonnydee1> LarstiQ: This gives me a bzr: ERROR: KnitPackRepository('file:///home/jonnydee/.bazaar/plugins/rebase/.bzr/repository/') is not compatible with KnitPackRepository('http://people.samba.org/bzr/jelmer/bzr-rebase/.bzr/repository/') different rich-root support
[20:59] <jonnydee1> I will just re-checkout the branch
[20:59] <LarstiQ> BasicOSX: and besides, dealing with issues is more important than never making a mistake.
[21:00] <BasicOSX> I was joking, it's just funny to get email from RMS on regression releases that say "Condolences on the release"
[21:00] <LarstiQ> :)
[21:00] <BasicOSX> LarstiQ:  quick scan of ML doesn't show me the discussion of the regression, what should up? installing from source broken on Windows?
[21:01] <LarstiQ> BasicOSX: let me check.
[21:01] <BasicOSX> what should up = what showed up ?
[21:02] <LarstiQ> BasicOSX: the api_minimum_version thread
[21:02] <LarstiQ> BasicOSX: which is breaking plugins
[21:03] <BasicOSX> oh? hmm, I remember that -and- it's my fault, 1.14 should have api of 1.13? 1.14?
[21:03]  * LarstiQ applies qannotate to bzrlib/__init__.py
[21:04] <BasicOSX> http://permalink.gmane.org/gmane.comp.version-control.bazaar-ng.general/57260 <- that thread, right LarstiQ  ?
[21:04] <LarstiQ> BasicOSX: yup
[21:07] <BasicOSX> Did a bug ever get opened for this issue?
[21:07] <BasicOSX> does not look like it
[21:07] <LarstiQ> I don't think we really need it, but that's my opinion.
[21:08] <LarstiQ> BasicOSX: looking at the diff, between rc2 and final api version changed from (1, 13, 0) to (1, 14, 0). So yeah, roll it back to (1, 13, 0)
[21:09] <jonnydee1> LarstiQ: Will that change 'rollback from (1, 13, 0) to (1, 14, 0)' be included in 1.14.1? Will it resolve the 'rebase' problem?
[21:15] <LarstiQ> jonnydee1: yes.
[21:20] <jonnydee1> LarstiQ: cool!!! :D  You guys are great!!! Thanx for your help!!!
[21:22] <LarstiQ> jonnydee1: np :)
[21:26] <jonnydee1> Sorry for annoying you, but I just tried out the new "bzr mv --auto" feature. I created an empty branch, added a text file to it and committed it to the branch. Then I created a new directory, and moved the text file into this new directoy. Afterwards, I did a "bzr mv --auto"...
[21:27] <jonnydee1> Which resulted in a
[21:27] <jonnydee1> => new
[21:27] <jonnydee1> test.txt => new/filew.xml
[21:27] <jonnydee1> then I did a 'bzr st' and got a traceback.
[21:28] <jonnydee1> message: "bzr: ERROR: exceptions.IndexError: list index out of range"
[21:29] <jonnydee1> I think it's because bazaar doesn't add the (still unversioned) directory first...
[21:30] <jonnydee1> (btw: in my case the directory was called 'new')
[21:31] <LarstiQ> jonnydee1: a bug report is not annoying :)
[21:31]  * LarstiQ tries to reproduce
[21:31] <jonnydee1> ok :)
[21:32] <LarstiQ> jonnydee1: I believe I followed your recipe exactly, but no traceback.
[21:32]  * LarstiQ is on bzr.dev
[21:33] <jonnydee1> ok, I will redo my steps again -- just to make sure I can reproduce this behavior...
[21:34] <GPHemsley> I just issued the command `bzr log -v -rthread:` to see what it did, and I got a Python traceback
[21:34] <GPHemsley> Is this a known bug?
[21:35] <LarstiQ> GPHemsley: looms?
[21:35] <GPHemsley> LarstiQ: What about them
[21:35] <GPHemsley> ?
[21:35] <jonnydee1> LarstiQ: I can reproduce this behavior
[21:36] <LarstiQ> GPHemsley: I'm not familiar with thread:
[21:36] <LarstiQ> jonnydee1: can you capture it in a script that I could run?
[21:37] <GPHemsley> LarstiQ: I'm not, either, but I definitely shouldn't be getting a Python traceback
[21:37] <jonnydee1> Of course, I am just doing this...
[21:37] <LarstiQ> GPHemsley: true, true :)
[21:37] <LarstiQ> jonnydee1: cool
[21:37] <LarstiQ> GPHemsley: when I run that, I get: No namespace registered for string: u'thread:'
[21:38] <LarstiQ> GPHemsley: which is supotimal (and reported), but not a traceback
[21:38] <GPHemsley> LarstiQ: What version?
[21:38] <LarstiQ> GPHemsley: bzr.dev
[21:38]  * GPHemsley is on 1.13.1
[21:38]  * LarstiQ tries with 1.13
[21:38] <GPHemsley> Perhaps it was fixed already?
[21:38] <LarstiQ> doesn't happen there either.
[21:39] <GPHemsley> hmm
[21:39] <LarstiQ> GPHemsley: does the traceback show it happens in plugin code?
[21:39] <GPHemsley> this is the error:
[21:39] <GPHemsley> bzr: ERROR: exceptions.AttributeError: 'BzrBranch7' object has no attribute 'get_loom_state'
[21:39] <GPHemsley> plugins/loom/revspec.py
[21:40] <GPHemsley> lines 44 and 51
[21:40] <GPHemsley> So, I think that's a yes
[21:40] <jonnydee1> LarstiQ: Here is my script: "bzr init trunk && cd trunk && echo Hello World! > test.txt && bzr add && bzr ci -m "Import." && mkdir new && mv test.txt new/filew.xml && bzr mv --auto && bzr st"
[21:42] <LarstiQ> jonnydee1: thanks, that does blow up on me.
[21:42] <jonnydee1> np ;)
[21:42] <LarstiQ> and I thought I did that manually, hmm.
[21:42] <jonnydee1> should I report a bug?
[21:43] <LarstiQ> jonnydee1: yes please :)
[21:43] <jonnydee1> ok - thanks again for your feedback
[21:44] <GPHemsley> LarstiQ: I filed a bug: https://bugs.launchpad.net/bzr/+bug/370545
[21:45] <LarstiQ> GPHemsley: I'm reassigning it to bzr-loom
[21:45] <GPHemsley> LarstiQ: Already did :)
[21:45] <LarstiQ> doh :)
[21:46] <GPHemsley> So, what I really wanted was to filter log output for only specific files/directories
[21:46] <GPHemsley> Is that feature not available?
[21:47] <LarstiQ> GPHemsley: `bzr log file`?
[21:47] <GPHemsley> well, more specifically, a specific directory and down
[21:47] <LarstiQ> GPHemsley: there are some shortcomings, that might be one of them.
[21:48] <LarstiQ> GPHemsley: Ian has been working on that lately iirc
[21:48] <GPHemsley> if I do `bzr log .` or `bzr log ..`, I only gives me the results that specifically affected the directory itself... not all the files in it
[21:48] <GPHemsley> s/I/it/
[21:49]  * LarstiQ fails to find the relevant emacs page
[21:56] <jonnydee1> LarstiQ: I've filed the "bzr mv --auto" bug: https://bugs.launchpad.net/bzr/+bug/370551
[21:56] <LarstiQ> jonnydee1: thanks
[21:57]  * LarstiQ calls it a night
[21:57] <jonnydee1> no problem :)
[21:57] <LarstiQ> GPHemsley: I couldn't find a wiki page or bug concerning that atm, maybe Ian mentioned it on t elist.
[21:57] <GPHemsley> k
[21:57] <GPHemsley> thanks for your help
[22:19] <GPHemsley> Is there a way to customize the colors used for bzr cdiff?
[22:41] <jonnydee1> Hi, just an idea: wouldn't a "bzr-portable-1.xx-x.exe" be a better name than a "bzr-nonadmin-1.14-1.exe"? (Just to make clear it can also be installed on a USB stick.)
[22:42] <jonnydee1> (erm, I wanted to write "bzr-nonadmin-1.xx-x.exe" instead of "bzr-nonadmin-1.14-1.exe")
[23:02] <BasicOSX> darn it jam, stop hog'n PQM queue! :-P


[02:38] <maco> mdeslaur: the column dragging thing: ouch! needs a higher threshold for sure
[02:39] <maco> ive noticed people who didnt grow up on computers having trouble *not* dragging when they click
[03:31] <mdeslaur> maco: yeah, luckily it's been fixed in later versions. I had to actually create an icon on her desktop called "FIx Email" cause she was breaking it a couple times a week.
[03:33] <maco> ouch
[03:34] <maco> i put a script on my friend's debian laptop that rewrites xfce's stored session with a backed up working one and gave her instructions for how to run it from a terminal if her xfce saves a crashed state
[03:35] <maco> apparently im the only debian support she's got because some guy she went on a date with put it on her computer at the end of the date then stopped respnding to phone calls and email


[04:18] <lotuspsychje> good morning
[05:07] <Talikka> Mood morning.
[05:08] <Talikka> It seems Linux Mint people are active in Facebook and Ubuntu people in IRC.
[05:08] <Talikka> I want to build a global community of grassroot support https://aku-opettaa.blogspot.com/2019/06/cooperation-between-ubuntu-communities.html
[06:50] <ducasse> good morning
[11:28] <BluesKaj> Hi folks
[11:57] <Talikka> interested in new business and association endeavours in Scandinavia and neighbouring countries? #ubuntu-nordic


[02:12] <cfhowlett> http://civs.cs.cornell.edu/cgi-bin/vote.pl?id=E_0fdc957f50e982d0
[08:51] <studio-user825> exit
[15:07] <like> hello ubuntu studio have rosegarden 15-12 ?
[15:13] <cfhowlett> like you already asked this in #ubuntu; same answer
[15:42] <like> yes
[15:43] <like> im trying to build but is same of nothing
[15:43] <like> they comes preinstaled on ubuntustudio the rosegarden package 15-12
[15:44] <cfhowlett> like, you already asked this is #ubuntu.  same answer.  if you really must have 15-12 NOW, see if there's a ppa or compile it yourself


[01:37] <micahg> zequence: not much time before the weekend, if I can I'll take a look, otherwise it'll be the weekend (in which case you might want to find someone else)
[08:44] <zequence> OvenWerks: If you like, confirm this bug #1226993
[08:44] <zequence> lp #1226993
[08:44] <zequence> hmm..
[08:44] <zequence> https://bugs.launchpad.net/ubuntu/+source/ubuntustudio-menu/+bug/1226993
[08:48] <knome> bug 1226993
[08:48] <knome> zequence, that ^
[08:50] <zequence> knome: Weird. Think it used to work the other way as well before
[08:52] <knome> maybe...
[08:52] <knome> lp 1226993
[10:10] <smartboyhw> zequence, Bug 1226693
[10:10] <smartboyhw> Oops
[10:10] <smartboyhw> Bug 1226993
[10:12] <smartboyhw> Please mark it as [FFe] in the title and subscribe the Ubuntu Release Team next time. I will do it for you this time.
[10:15] <knome> if it's an artwork update, it doesn't require a FFe
[10:15] <smartboyhw> knome: Oh
[10:16] <knome> UIFe is tomorrow
[10:18] <smartboyhw> zequence: BTW I saw in some log yesterday or the day before that you dont care about adding your name in debian/copyright?
[10:18] <smartboyhw> (Or did I get it wrong)
[10:18] <smartboyhw> For menu
[11:16] <madeinkobaia> Hi all : )
[11:32] <zequence-work> madeinkobaia: I got your WP. The blue I though would have been a nice touch, but because of the way the CoF is made, it looks a bit lofi 3D, if you know what I mean
[11:33] <knome> hey :)
[11:33] <zequence-work> So, I'd go with the grey one
[11:33] <knome> is the wallpaper somewhere public?
[11:34] <zequence-work> madeinkobaia: Maybe you could post them to the mail list?
[11:34] <zequence-work> Ah, well, links to them at least
[11:35] <madeinkobaia> Hey...I will put the monochrom version in the list : )
[11:36] <madeinkobaia> ... in few minutes :)
[12:23] <madeinkobaia> Done, message on the dev-list sent. Note that I forgot to update the subject line, it should be "Ubuntu Studio 13.10 - Default wallpaper proposition RC2" (and not RC1 of course ;) ).
[12:24] <madeinkobaia> zequence-work: ^
[12:24] <madeinkobaia> knome: ^
[12:24] <knome> seems to be stuck in the moderation queue (too big))
[12:24] <knome> oh wait
[12:24] <knome> nvm me
[12:42] <madeinkobaia> still don't received the dev-list mail :(
[13:43] <OvenWerks> zequence-work: I guess the backdrop needs to be added to -settings and the config set to point to it.
[13:44] <OvenWerks> I can't do that till at least tonight.
[15:25] <zequence-work> OvenWerks: No, it's ubuntustudio-look
[15:25] <zequence-work> I can do that
[15:26] <zequence-work> settings should not have any aesthetic things in it
[15:33] <zequence-work> OvenWerks: This is mostly because of the menu, -settings is depending on -look, which we should change
[15:34] <zequence-work> -settings is also depedning on the lightdm-greeter. this should also be changed
[18:53] <madeinkobaia> Does someone read the comments on the dev-list about my wp proposition ?
[19:06] <zequence> madeinkobaia: don't worry about that
[19:06] <zequence> ralf is ralf :)
[19:07] <zequence> OvenWerks: The default wallpaper needs to be set in -default-settings, but the actual wallpaper went to -look
[19:12] <madeinkobaia> zequence: I actually write an answer ;) otherwise you can not use it. I strictly don't care.
[19:20] <zequence> madeinkobaia: I've already added the WP and asked for it to be uploaded
[19:22] <zequence-work> 1227323 1227325
[19:22] <zequence-work> Bug 1227323
[19:22] <zequence-work> Bug 1227325
[19:24] <zequence-work> OvenWerks: Could you just test those packages, make sure they work
[19:40] <madeinkobaia> Why the dev list mails switch to "issue 12" to "issue 14" ? where is the answer I sent ?
[19:47] <zequence-work> madeinkobaia: it probably had too many links in it
[19:47] <zequence-work> madeinkobaia: I'll let it through, one moment
[19:50] <zequence-work> madeinkobaia: Ah, it went through..
[19:51] <madeinkobaia> zequence-work: So ?
[19:53] <madeinkobaia> zequence-work: See also on PM. Thanks


[02:32] <bimberi> $ bzr branch lp:hwtest
[02:32] <bimberi> bzr: ERROR: Revision<EMAIL_ADDRESS>not present in "revisions.kndx".
[02:33] <bimberi> 'bzr co --lightweight' works (but not just 'bzr co').
[02:46] <jml> hmm
[02:48] <jml> bimberi: what happens if you do 'bzr branch http://bazaar.launchpad.net/~hardware-certification/hwtest/trunk'?
[02:58] <jml> bimberi: I appear to get the same error. At a guess, I'd say that the branch needs to be fixed by someone who has a copy
[03:00] <bimberi> jml: your command worked
[03:00] <jml> *interesting*
[03:02] <jml> bimberi: are you a member of the hardware-certification team?
[03:05] <wgrant> I thought they said that they fixed all of those branches.
[03:05] <wgrant> After they broke them a few weeks ago.
[03:05] <bimberi> jml: no (sorry so unresponsove, frequently afk atm)
[03:05] <wgrant> (they being lp-bzr people)
[03:05] <jml> wgrant: I am they.
[03:06] <wgrant> jml: I always forget which team you're in, sorry.
[03:06] <jml> wgrant: np :)
[03:06] <wgrant> Too many LP people.
[03:07] <jml> wgrant: when we fixed up the branches that the LP bug corrupted, we noticed other corrupted branches that were not caused by us.
[03:07] <rockstar> I've seen corrupt branches on launchpad that were user errors...
[03:07] <jml> right.
[03:08] <jml> or bzr client errors.
[03:08]  * jml tries fetching the branch over sftp
[03:09] <jml> if it works there, then it's probably a bazaar bug.
[03:09]  * bimberi retries lp:hwtest - same error.  Now retrying http://...
[03:16] <bimberi> "Branched 300 revision(s)."
[03:16] <bimberi> So yes it worked.
[03:16] <wgrant> But that'll be an outdated version.
[03:18] <rockstar> wgrant, why would it be outdated?
[03:19] <anilm> do you guys know about this?
[03:19] <anilm> Sorry, there was a problem connecting to the Launchpad server.
[03:19] <jml> anilm: what URL were you connecting to?
[03:19] <anilm> jml: http://bazaar.launchpad.net/~amakhijani/survv/blog/files
[03:20] <jml> anilm: I've also had problems connecting to the code browsing service.
[03:20] <wgrant> rockstar: If the branch is broken on SFTP, won't it not have been pushed to HTTP for a while?
[03:20] <anilm> jml: ahh ok
[03:21] <rockstar> jml would know authoritatively, but I think not.
[03:21] <jml> wgrant: if you don't have write access, you should get the same version of the branch no matter what protocol you use.
[03:22] <wgrant> jml: Ah.
[03:23]  * jml can get the branch via sftp, but not via bzr+ssh
[03:24] <jml> I'm guessing this is a Bazaar bug.
[03:24] <jml> afaict, the version of the branch that I've got (as a non-team-member) is the latest.
[03:26] <jml> I can't see any relevant errors in the logs I've got on hand.
[03:26] <jml> I'll chase it up with the Bazaar guys tomorrow.
[04:17] <nixternal> not being able to connect to bazaar in LP, is that known yet?
[04:18] <nixternal> give me the "try reloading in a few" message
[04:18] <beuno> nixternal, Loggerhead?  as in "view revisions/code"?
[04:18] <nixternal> yes
[04:18] <beuno> well, it's been misbehaving for a few days now
[04:19] <nixternal> k, it was working perfectly earlier, as it was flying allowing me to steal, I mean research, other's code :)
[04:19] <beuno> heheh
[04:19] <nixternal> k, I will try again later then...thanks beuno
[04:20] <beuno> I think the devs are aware, and, AFAIK, a new version is being rolled out on wednsday, which should make it work much better
[04:20] <nixternal> groovy
[05:19] <lifeless> beuno: generally any misbheaviour is considered a severe problem and should be escalated, for future reference
[05:20] <beuno> lifeless, ah, alright. Since jml was notified above, and it has been the case for the past days, I didn't think it was worth bothering anyone. I'll make sure to be more annoying next time  :)
[05:21] <lifeless> beuno: uhm, I think he interpreted it as a branch specific thing
[05:21] <jml> lifeless: no I didn't.
[05:21] <lifeless> oh
[05:21] <jml> I interpreted it as an intermittent thing.
[05:22] <lifeless> well, I'm chasing it
[05:22] <jml> thanks.
[05:34] <lifeless> its up and running
[05:35] <beuno> thanks lifeless   :)
[08:57] <Zic> hi, I've a question not close related to Launchpad : I'm an Ubuntu Member with an @ubuntu.com alias mail which I use mainly into the free software world mailing-list, I recently change to a new domain name my email server, and @ubuntu.com alias alway forward mails to the old one
[08:58] <Zic> I just changed my default e-mail contact in my launchpad account
[08:58] <Zic> (to my new<EMAIL_ADDRESS>[08:58] <wgrant> It should change automatically within a few days.
[08:58] <Zic> How long Launchpad "rehash" email alias ?
[08:58] <Zic> few days ? thanks for your help :)
[08:59] <wgrant> Might be nightly, I forget.
[09:00] <Zic> can you confirm that Launchpad use the e-mail contact defined in accounts ? because, after my migration, I use my @ubuntu.com alias for e-mail contact on Launchpad
[09:00] <Zic> I just changed it to my newdomain, because I thought Launchpad use the contact adress to do the alias forward
[09:01] <wgrant> I believe that setting your ubuntu.com alias as your primary Launchpad address will cause problems.
[09:01] <wgrant> But IANALPD, I've just heard it happen to people.
[09:01] <Zic> yes, I believe it too, it's why I set it to my new email adress
[09:15] <geser> doesn't LP use the first non @ubuntu.com email address for mail forwarding anymore?
[11:46] <persia> geser: That matches my experience, but the tales of those who manipulate accounts with primary set to @ubuntu.com are legion: likely best to set something else primary before any adjustment, and once complete, maybe set back @ubuntu.com
[14:13] <cyberix> Please give me a feature that helps me keep track about the Ubuntu packages I have been working with.
[14:13] <wgrant> cyberix: What do you mean by "keep track"?
[14:13] <cyberix> My use case is as follows
[14:13] <cyberix> 1) I'm working on a new Ubuntu package
[14:13] <cyberix> 2) Someone points out a bug in my packaging
[14:14] <cyberix> 3) I realize I did the same error on all my previous packages
[14:14] <cyberix> 4) I try to remember all the packages I created
[14:14] <wgrant> 5) Look at https://launchpad.net/people/+me/+packages.
[14:14] <wgrant> 6) ???
[14:14] <wgrant> 7) Profit.
[14:14] <Matt-W> Hello. There seems to be a lock stuck on one of my project's bzr branches.
[14:15] <cyberix> wgrant: Thank you. That is just what I'm looking for.
[14:15] <wgrant> Matt-W: Use bzr break-lock on it, if it says it's held by you.
[14:15] <Matt-W> wgrant: unfortunately it's held by somebody else
[14:16] <Matt-W> for 951 hours and counting
[14:16] <wgrant> Matt-W: Who supposedly has it held?
[14:16] <Matt-W> held by<EMAIL_ADDRESS>on host vostok [process #25147]
[14:16] <Matt-W> locked 951 hours, 31 minutes ago
[14:16] <Matt-W> he's the other person with commit access to the branch
[14:17] <wgrant> You can probably safely break it - I doubt he's still doing anything with it after 40 days
[14:17] <spiv> It's highly unlikely that they've actually been doing a commit for the last 951 hours :)
[14:17] <cyberix> What happens to translations that people contribute for Ubuntu?
[14:17] <Matt-W> he's not been able to commit at all this may explain it
[14:17] <wgrant> cyberix: They go into the next language pack update.
[14:17] <cyberix> The language pack then overwrites the translations that I ship?
[14:18] <cyberix> the ones that are included in my original package
[14:18] <Matt-W> woo, a successful commit
[14:18] <Matt-W> Thanks
[14:19] <wgrant> cyberix: Those translations aren't in your package if said package is in main.
[14:19] <wgrant> cyberix: If your package is in universe or multiverse, it is not translated in Launchpad at this time.
[14:19] <cyberix> Oh
[14:19] <cyberix> Interresting
[14:20] <cyberix> Ofcourse it makes sense to atleast have them separate
[14:20] <cyberix> otherwise the task of translating Ubuntu would grow insanely big
[14:20] <wgrant> It's actually largely due to technical issues with getting the universe translations to end users, I believe.
[14:22] <cyberix> I'm having trouble with creating a process to handle Launchpad translations for a piece of software I wrote
[14:22] <cyberix> I change one letter in the original software
[14:22] <cyberix> then I have to create a new translation template
[14:22] <cyberix> which makes all translations go fuzzy
[14:22] <cyberix> and as, my software is not very common, no-one will check those
[14:24] <cyberix> I'm currently "just including" all the translations I get from Launchpad
[14:24] <cyberix> but I've understood that this leads to broken user experience
[14:25] <cyberix> Also I'm not sure, if I'd like to do new releases all the time because some translation was updated.
[14:27] <cyberix> I should find myself some guide for managing this
[14:27] <cyberix> It is just that most guides concentrate on the technical issues
[14:40] <shirish> hi all, if a bug affects two versions of Ubuntu, say Intrepid as well as Hardy, how can I show that?
[14:41] <shirish> I have seen those kind of bugs but don't know how people affected that change.
[14:41] <shirish> nominate for release?
[14:42] <persia> shirish: If you've tested against both, and you think it's important enough to get fixed as a stable release update, you can Nominate it for hardy.
[14:44] <shirish> persia the bug I've bug #240191 affects both hardy and intrepid, its a merge request of a package from debian
[14:45] <Hobbsee> that doesn't affect hardy.
[14:45] <Hobbsee> as in, hardy doesn't get 'merges'
[14:46] <shirish> Hobbsee: ah ok, it should be called a sync then or what, somebody else reported it, I just added stuff.
[14:46] <persia> Also, #ubuntu-bugs is a better place for this sort of discussion.
[14:46] <shirish> ah ok, sorry guys
[14:46] <Hobbsee> it should be caleld a stable release update, adn only the critical changes should be pushed into hardy.
[14:46] <Hobbsee> or the entire thing backported.
[14:46] <Hobbsee> neither of which is a merge.
[14:47] <shirish> true, so the description needs to be changed.
[14:48] <Hobbsee> no, it shouldnt, as it's valid for intrepid.
[14:48] <Hobbsee> which is what hte bug was first for.
[14:48] <Hobbsee> before you attempted to sidetracker.
[14:48] <Hobbsee> er, side track it.
[14:50] <shirish> ok I would be just happy when I get the updated package, that's about it
[15:42] <phobie> Are watch-files parsed on PPA?
[15:44] <Hobbsee> phobie: parsed how?
[15:45] <phobie> show me if my package is up to date
[15:45] <phobie> like uscan or on debian.net
[15:45] <Hobbsee> ppas do not have internet access, so, no
[15:46] <Hobbsee> (beyond the mirror, anyway)
[15:47] <phobie> http://dehs.alioth.debian.org/maintainer.php?name=eric
[18:13] <Rugby471> hi guys, is there anyone here who can delete the series located here for me
[18:13] <Rugby471> https://launchpad.net/crunchbang-tips/random/
[18:15] <Rugby471> ?
[23:52] <jml> bimberi: btw, I filed https://bugs.edge.launchpad.net/bzr/+bug/242232 as a followup to our conversation over the weekend.


[09:39] <bwana> that's odd
[09:39] <bwana> i can't get to http://www.ubuntu.com/
[09:40] <bwana> anyone else having problems
[06:59] <spike> can anybody help me with a serial connection to a cisco pix?
[07:00] <spike> Ive tried with minicom, using /dev/ttyS0, got permissions on it for my user, baudrate set to 9600, 8N1, blanked init and reset strings
[07:02] <ivoks> ok
[07:03] <spike> I get this /dev/ttyS0, UART: 16550A, Port: 0x03f8, IRQ: 4 from setserial -g /dev/ttyS0
[07:03] <spike> I've checked the bios and serial support is on (had it on Disabled before)
[07:03] <spike> using the standard light blue cisco cable
[07:04] <ivoks> i don't know about cisco pix
[07:05] <ivoks> i tought you need help with ubuntu :)
[07:05] <spike> well, I'm connecting from an ubuntu box :P
[07:06] <spike> #cisco definitely has prob with attitude the few times someone speaks in there :/
[07:06] <ivoks> well, what did you expect from company that puts Cisco/Cisco as default username and password :)
[07:07] <ivoks> egotrip :)
[07:09] <spike> there's nothing wrong at all with that
[07:09] <ivoks> it's not cisco/cisco :)
[07:10] <ivoks> but with capital C :)


[02:07] <bjsnider> could someone please run the following command:
[02:07] <bjsnider> telnet alt1.gmail-smtp-in.l.google.com 25
[02:08] <Daekdroom> bjsnider, now what?
[02:08] <bjsnider> pastebin the result please
[02:08] <Daekdroom> http://pastebin.com/UFneBuk5
[02:09] <bjsnider> my port 25 must be blocked
[02:10] <ActionParsnip> bjsnider: http://paste.ubuntu.com/1122605/
[02:11] <bjsnider> telnet: Unable to connect to remote host: Network is unreachable
[02:11] <bjsnider> my sonfoabitch isp must be blocking port 25
[02:13] <bjsnider> nmap says it's open on this computer
[02:13] <bjsnider> either my router is blocking it, or my isp is
[02:29] <BluesKaj> KDE 4.9 seems to holding up nicely on Kubuntu 12.10
[05:00] <mahir256> so i upgraded to lubuntu 12.10 alpha 3, and then i restarted, but now the login screen isn't showing up
[05:02] <genii-around> mahir256: Were you running proprietary video driver like nvidia before the upgrade?
[05:06] <mahir256> no i was not. i installed lubuntu with the free software only option
[05:07] <ActionParsnip> mahir256: try reinstalling the lightdm package
[05:08] <mahir256> lightdm is already the newest version.
[05:09] <mahir256> (apt output)
[05:11] <mahir256> so i upgraded lightdm. what now?
[05:17] <mahir256> hello?
[08:32] <gnomefreak> that was odd :(
[09:46] <ritz> heya, xserver xorg drivers are broken on quantal , and need a rebuild against xorg-abi-13
[09:46] <ritz> or  refresh
[09:47] <ritz> do I file this against lp for each componenet ? ( mouse/synaptic/keyboard/radeon which effect me )
[09:47] <ritz> and radeon driver would need a refresh ( xaa has been dropped )
[10:08] <dupondje> ritz: no, somebody 99,9% sure already knows that
[10:08] <dupondje> its in a transition :) no worries
[10:13] <ritz> sweet :) , hmmm 0.1% bothers me though
[10:15] <gnomefreak> the chances are you are not the 0.1%
[10:16] <gnomefreak> if you are than you have serious bad luck
[10:17] <gnomefreak> ok i cant add the weather applet anyone know the trick to it?
[11:20] <BluesKaj> Hey all
[11:44] <Fudge> hi BluesKaj
[11:52] <BluesKaj> hey dupondje
[11:52] <BluesKaj> oops
[11:52] <BluesKaj> hey Fudge
[11:52] <dupondje> hey ! :)
[11:53] <BluesKaj> my eye hand co-ordindination sucks this morning
[11:53] <Fudge> hows life BluesKaj
[11:53] <BluesKaj> doing well otherwise Fudge , thanks ...how's things with you?
[11:55] <Fudge> all good here mate tks
[13:11] <centrelink> http://ascii.io/a/683
[13:11] <centrelink> lol y
[14:05] <genii-around> Breakage, woo! ;-)
[14:15] <BluesKaj> BBL
[17:20] <hivemind> i'm trying to install 12.10 alpha 2 on asus eee pc x101ch from the flash storage
[17:20] <hivemind> but
[17:21] <hivemind> the flash storage is displaying as /dev/sda2, and C:/ and D:/ in win is displaying as /dev/sda1 and /dev/sda3
[17:21] <hivemind> i'm deleting both of them and getting two of free space
[17:22] <hivemind> what i supposed to do to connect them together?
[17:22] <hivemind> sorry for my english, i'm russian
[17:25] <hivemind> anybody?
[17:51] <smallfoot-> libpng 1.5 is not in repo
[17:51] <smallfoot-> so warsow dont work
[18:07] <ceed^> I want the Up button back in the new version of Nautilus on Ubuntu.
[18:07] <trism> smallfoot-: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=648317
[18:40] <alexhairyman> In the quantal branch (Which I have absolutely no memory of ever installing) I can't remove the f10 menu accelerator
[18:40] <alexhairyman> I've searched through gconf and ccsm for any values mapped to F10 and can't find anythin
[18:41] <alexhairyman> (Or I've changed it all)
[19:15] <IdleOne> How do I get rid of the Kopete menu entry? I have removed and purged kopete
[19:16] <IdleOne> Now it is sitting there in the K menu like a pimple in the middle of my forehead


[06:02] <dpm> good morning all
[16:00] <kelemengabor> dpm: hi, do you have a second?
[16:01] <dpm> kelemengabor, sure, just finished off a call
[16:04] <kelemengabor> so, the time for the Natty langpack updates testing is up, but we got no response from those three languages (es, sl, pt_BR) that reached 100% coverage in ubuntu-help translation - this quite kills the point of having updated base packages. What should we do?
[16:07] <kelemengabor> also, Andre_Gondim report in: don't you want fully translated Natty help in -updates? :)
[16:07] <dpm> hit them with a stick!
[16:07] <kelemengabor> :D
[16:07] <dpm> let me give them a heads up on the list
[16:08] <Andre_Gondim> let me see
[16:08] <kelemengabor> Andre_Gondim: https://wiki.ubuntu.com/Translations/LanguagePackUpdatesQA
[16:19] <dpm> kelemengabor, I've just sent a reminder to the translators list and to each team's list. Let's have another chat tomorrow to see if anyone has signed off those languages in the meantime
[16:19] <kelemengabor> dpm: okay
[16:20] <dpm> thanks for looking at this kelemengabor!
[16:21] <kelemengabor> you are welcome :)
[16:22] <kelemengabor> also, there was a question raised on the list by Hannie: will there be another update for the docs translation (for Natty)?
[16:22] <kelemengabor> or rather: should we do another?
[16:26] <kelemengabor> I think we should talk about this with the docs team, and develop a clear schedule for next cycle, as it would be great to have more time to translate the docs, but their help would be needed
[16:35] <happyaron> anyone know about how to translate codeblocks? it seems the wiki on codeblocks.org is largely out dated.
[16:51] <dpm> kelemengabor, yeah, I agree. Perhaps we should have a UDS session for that as well (common schedule for updates)
[16:51] <dpm> happyaron, no, I don't know, sorry
[16:53] <happyaron> dpm: hey, it's not your problem... I believe it's codeblocks developers' problem.
[16:55] <happyaron> their wiki contains only out dated instructions, there release tarballs contains no translation, their forum has nobody talking on this issue for 5 years. But in svn trunk, there is POT files in non-standard directory, and I don't know where to place the translated files...


[16:05] <ncw> Hi, I reported a bug in Ubuntu's Xorg the other day (https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1240623)
[16:06] <ncw> I'm wondering what the timescale is for investigating it. We have customers on Ubuntu, who might be upgrading soon, so knowing whether you'll fix it in an update, or whether we need to write a workaround for the bug, would be helpful.
[16:31] <tjaalton> too quick
[17:05] <bjsnider> know the info _would_ be helpful, but _only_ if the information is provided quickly
[17:15] <bjsnider> tjaalton, i've got one for you
[17:16] <tjaalton> oh no
[17:16] <bjsnider> i've got one app here, xchat-gnome, that has a bunch of corrupted video crap in the titlebar
[17:16] <bjsnider> i talked to gcampax about it, and he suggests it's the graphics driver
[17:16] <bjsnider> intel/ivybridge/saucy
[17:17] <tjaalton> ah, there are some filed against -intel
[17:18] <bjsnider> the titlebar is basically transparent
[17:18] <bjsnider> and it doesn't matter if i use old xchat-gnome code or the latest
[17:18] <tjaalton> maybe file a new bug against -intel and see how quickly ickle reacts
[17:18] <bjsnider> ok