[00:06] <lifeless> poolie: would you like to have lunch?
[00:06] <lifeless> poolie: today I mean
[00:06] <poolie> mm
[00:06] <poolie> i would
[00:06] <poolie> i have to finish circa 5
[00:06] <poolie> rather than 1 :-O
[00:06] <lifeless> this sounds compatible so far
[00:07] <poolie> the bad 1 o'clock that is
[00:07] <lifeless> I'll be finishing ~ 2 I imagine
[00:07] <lifeless> wish I knew why i'm waking so early
[00:07] <lifeless> but it sure is peaceful to be hacking - no trucks or traffic
[00:08] <lifeless> anyhow, if you'd like to have lunch, so would I. So we should
[00:19] <poolie> sure
[00:19] <poolie> pick a place
[00:19] <poolie> meeting here would let me work more
[00:19] <poolie> meeting somewhere at the end of a motorcycle would add joy to my life :)
[00:21] <lifeless> poolie: you're not seriously asking me to choose between you working or having joy?
[00:22] <lifeless> poolie: thats rather faustian :)
[00:22] <lifeless> uhm, I could go pie. Or vietnamese. or $other
[00:22] <poolie> one of us needs to choose :)
[00:22] <lifeless> lets say pie
[00:23] <poolie> i am enjoying my work
[00:23] <poolie> ok, here?
[00:23] <igc> poolie: yes, bzr-mac
[00:23] <poolie> wfm
[00:23] <igc> morning all
[00:23] <poolie> great
[00:23] <lifeless> done
[00:23] <lifeless> 12ish?
[00:23] <poolie> igc, i was thinking about platform-specific bugs
[00:23] <lifeless> or is that too early for your stomach
[00:23] <poolie> i suspect non-core people aren't subscribed to bug mail, or don't read it
[00:23] <poolie> in fact core people probably don't read all of it
[00:23] <poolie> should we maybe explicitly forward or subscribe platform teams to relevant bugs?
[00:25] <poolie> lifeless: wfm, i woke about 6.30
[00:28] <igc> poolie: maybe. I'm not sure if there would be any backlash against that or not. We could ask if anyone objects?
[00:29] <poolie> ok
[00:29] <igc> poolie: there's certainly value in asking the teams to test platform specific fixes
[00:29] <poolie> i've had some success in the past pointing them out on the main list marked with eg win32
[00:30] <poolie> i guess the question is whether they're platform test teams or platform dev teams
[00:30] <igc> poolie, jml: can users/teams subscribe to bugs with certain tags?
[00:31] <jml> igc, I don't believe so. It's quite possibly a filed bug too
[00:34] <lifeless> vila: still here?
[00:34] <poolie> igc, i was wondering the same thing
[00:34] <poolie> it's probably better to just subscribe the team
[00:35] <poolie> i think it's probably not appropriate to subscribe the whole team to all relevant bugs
[00:35] <poolie> (maybe they want it)
[00:35] <poolie> but we could make ~bzr-win32-bug-team
[00:36] <lifeless> poolie: do you want developers or qa-on-fixes
[00:36] <poolie> developers
[00:36] <lifeless> poolie: if its qa on fixes I'd suggest ~bzr-qa-PLATFORM
[00:36] <poolie> primarily
[00:36] <poolie> i think some of these bugs are shallew
[00:37] <poolie> btw did you have any luck with wine in the case we mentioned yesterday?
[00:37] <lifeless> poolie: no, it was on my todo to experiment today, but late last night bialix said it works
[00:37] <poolie> how sad :)
[00:39] <lifeless> its terrible fixing bugs and stuff
[00:39] <lifeless> bialix is going to try and get a 1.18.1 prepared with the windows fixes
[00:40] <lifeless> Whats really a shame is that all of them were very shallow.
[00:41] <lifeless> does buildbot actually run ascii tests specifically at the moment?
[00:49] <poolie> i don't know
[00:49] <poolie> i don't think so
[00:49] <poolie> but it sounds like vincent will add it soon
[00:55] <poolie> lifeless: oh, actually unfortunately i can't do lunch today, i have to do something for s
[00:55] <lifeless> ok
[00:55] <lifeless> no wakas
[00:55] <poolie> monday could be good, let's talk then?
[00:57] <lifeless> friday or tuesday would be better for me
[00:58] <poolie> k
[00:58] <igc> poolie: can you clarify vila's email last night ...
[00:58] <poolie> mm, which one?
[00:58] <poolie> about the rc? just done
[00:58] <igc> poolie: the one that said rc1 vs beta1
[00:58] <igc> and lrelease date early next week
[01:00] <poolie> ah, i didn't see that about the release date
[01:00] <igc> poolie: so to confirm, rc2 next week
[01:00] <igc> poolie: and 2.0 the week after
[01:00] <igc> if 2.0 is next Monday, that impacts what I'll do today!
[01:04] <lifeless> poolie: would tomorrow work foryou?
[01:04] <poolie> igc: yes
[01:04] <poolie> was i insufficiently clear about what i wanted to happen or was vincent just a bit random here?
[01:04] <poolie> probably both
[01:05] <lifeless> poolie: I think unclear; I know I've been unclear
[01:06] <lifeless> *I've been unsure*
[01:06] <lifeless> I was asking you yesterday whether this should be done before we're finished with the critical bugs or not, and you said not-before, but this seems to have happened before they are fixed : I don't really know where we stand.
[01:07] <igc> poolie: I thought it was clear-ish but it's a change in process and we'll still finding our feet wrt monthly vs otherwise
[01:07] <igc> poolie: 1.18 is yet to be announced for example IIUIC
[01:07] <poolie> true
[01:07] <poolie> what's "this"?
[01:08] <poolie> 2.0b1? at that time all of the 2.0 critical bugs were closed, i believe
[01:08] <lifeless> doing a 2.0 b1
[01:08] <lifeless> poolie: jam is working on the fragmentation issue, I'm working on the pushing of 1.9 stacking against 2a issue
[01:09] <lifeless> 415508 and 402645 were still open
[01:09] <poolie> bug 415508
[01:09] <poolie> !
[01:09] <poolie> it shouldn't be
[01:09] <lifeless> poolie: also when you said critical I heard 'targeted to 2.0' not 'critical'
[01:09] <lifeless> which is a hearing defect
[01:11] <poolie> we have non-2.0 bugs marked critical
[01:11] <poolie> um
[01:11] <lifeless> poolie: I'd like to either untarget, or bump to critical, all the non-critical, non-fixed, bugs targeted to 2.0
[01:11] <lifeless> I think it will make sure you and I are on the same page
[01:11] <poolie> i'd like to either degrade or target all the critical bugs
[01:11] <poolie> so the non-critical bugs targeted to 2.0 are meant to be things we'd like to fix, or would consider merging
[01:12] <poolie> this might be an unhelpful distinction compared to just looking at the high/critical lists generally
[01:12] <poolie> so, um
[01:12] <poolie> i think both those changes are good
[01:12] <poolie> but let's do them one-by-one not wholesale
[01:12] <poolie> and then if we find a case that seems to invalidate the approach we'll reconsider it
[01:12] <lifeless> I strongly desire that targeted means 'will delay release'
[01:13] <poolie> mm, me too
[01:13] <lifeless> not having them critical seems to make them mean something different to you
[01:13] <poolie> i found that yesterday required more thinking than was optimal
[01:13] <poolie> or more thinking of a kind of overhead category
[01:13] <lifeless> ok bug 416732
[01:14] <lifeless> targeted to 2.0. SHould block it IMO
[01:14] <AfC> lifeless: that's what "blocker" means in GNOME. Actually, "blocker" (if confirmed as such) means «holy shit, stop everything, and there will be a release about 30 minutes after we figure out the problem»
[01:14] <poolie> bug 402645 you mentioned before
[01:14] <lifeless> poolie: lets do this over the phone; it will be quicker
[01:14] <poolie> mm
[01:14] <poolie> let me finish something here first
[01:14] <poolie> then i'll call
[01:15] <lifeless> ok
[01:15] <AfC> lifeless: so yeah, I guess that's what "critical" means there too
[01:15] <AfC> it's all very informal
[01:16] <poolie> so the key question is
[01:16] <poolie> should there be a category of 'wannabe blocker' or 'kinda blocker'
[01:16] <lifeless> AfC: there are two dimensions here; one is 'before this release', the other is 'what should a dev look at next'
[01:16] <poolie> it seems to cause mental pain for the RM and may have no benefit
[01:16] <lifeless> poolie: I don't think there should be; it should be a blocker, and if someone disagrees they stop it being a blocker.
[01:17] <lifeless> make the decision and make it easy to change if wrong.
[01:17] <mneptok> lifeless: the answer to the second question is always "my manboobs"
[01:17] <lifeless> mneptok: no, never. I'm sorry, but goram-no.
[01:17] <AfC> lifeless: well, the later is task prioritization, and I've never found bug trackers are good for that. Anyway, topic for beer.
[01:17] <mneptok> lifeless: so much for the adventurous and brave spirit of New Zealanders.
[01:17] <lifeless> mneptok: ba!
[01:17] <poolie> lol
[01:25] <poolie> lifeless: your phone seems engaged, call me when you're fere
[01:25] <poolie> free*
[01:25] <poolie> as in beer
[01:39] <lifeless> poolie: doing
[01:40] <lifeless> poolie: your phone rang out
[01:43]  * lifeless tries again
[02:06] <emmajane> poolie, ping?
[02:06] <emmajane> beer?
[02:06] <emmajane> I like beer.
[02:07] <emmajane> mneptok, stay classy :)
[02:07]  * emmajane reads backwards in time.
[03:05] <emmajane> poolie, reply sent. :) I'll be back in a bit for a little bit.
[03:17] <jam> lifeless: you only get knit-delta-closure etc if you pass "include_delta_closure=True" which doesn't happen for normal fetches, only when someone wants fulltexts.
[03:17] <jam> so you end up getting every little bit of content as a separate 'substream' in a normal fetch
[03:17] <jam> 2a would be different
[03:17] <jam> though I think it would be 1 group per substream
[03:18] <jam> which still isn't great
[03:18] <jam> and means that the target repository won't really have a chance to do batching
[03:18] <jam> since it won't get all the groups in a single 'insert_record_stream'
[03:18] <jam> you would have to batch between the streams...
[03:18] <spiv> jam: it's still the same write group, though.
[03:19] <jam> spiv: sure... still sort of violates what I thought substreams were abouet
[03:19] <AfC> jam: wish you were here. Then I could buy you a coffee.
[03:20] <spiv> Well, it's explicitly allowed for there to be multiple substreams of the same kind.
[03:23] <spiv> It would be more elegant to turn the stream from the request into a continuous object stream, but Python doesn't make that easy to do.  Well, we could add more threads...
[03:23] <jam> spiv: sure. but 1 record at a time is not really a bunch of *streams*, but more, a bunch of records... :)
[03:23] <jam> also, Repositories know about write groups
[03:23] <jam> VF's know about record streams
[03:24] <jam> so you would have to figure out how to have the VF know about the current Repo's write_group
[03:24] <jam> which is a small inversion
[03:24] <jam> or have Repo.commit_write_group() tell the VF.flush_your_buffer()
[03:24] <spiv> Well, for 1.9 pack repos I don't think there was any practical difference between insert_record_stream([2 records]) and 2 insert_record_stream([1 record]) ?
[03:24] <jam> (and dump_your_buffer for abort)
[03:24] <spiv> Because it's the write group that allocates the pack file.
[03:25] <jam> spiv: present day there isn't for 2a
[03:25] <jam> I would *like* to regroup on-the-fly
[03:25] <jam> given the discussion about fragmentation and recombination
[03:25] <jam> I can't regroup if everything I see is a single record-at-a-time
[03:25] <spiv> Ah, I see.  I was trying to figure out why you cared :)
[03:34] <AfC> bzr 1.18 is out or will be immenently right? (ie, it's ok for me to "advise" people that they really ought to be using bzr >= 1.18 on a website & in release notes for something I'm cutting today or so?)
[03:35] <jam> AfC: 1.18 is out, the announcement hasn't hit pending the building of all packages for all platforms
[03:35] <jam> the code is cut, though
[03:36] <AfC> k
[03:36] <AfC> close enough
[03:45] <poolie>  2009/8/27 Mary Gardiner<EMAIL_ADDRESS>[03:45] <poolie> > Why say "can we upgrade this to critical" when you mean "can we fix this?"
[03:45] <poolie> >                                    -- Martin Pool, twitter.com
[03:45] <poolie> great sig :)
[03:46] <jml> heh
[03:46] <spiv> Heh.
[03:47] <fullermd> Wait.  We're supposed to FIX them?
[03:50] <lifeless> poolie: I've just mailed the list with I think the pith of our chat
[03:51] <lifeless> spiv: jam: it would be quite easy to daisy chain all the substreams of the same kind together in the insert_stream method
[03:55] <poolie> >  "Do not assign bugs to other people unless you are confident they will work on them." sounds like some people can avoid getting bugs assigned to them altogether :)
[03:55] <poolie> but no one on this team :)
[03:57] <lifeless> poolie: if you assign a bug to me, its == 'hey robert, please fix this for me'
[03:57] <lifeless> and I'm very unlikely to unassign it immediately.
[03:57]  * igc lunch
[03:57] <poolie> mm
[03:57] <poolie> i'll reply in mail
[03:58] <lifeless> I've seen fairly regularly in other areas, assign-to-someone being used by users to get their bug looked at
[03:58] <lifeless> I think that was before the permissions on the assigned field were straightened out
[04:00] <poolie> what is 'staying stay' supposed to mean?
[04:02] <lifeless> blah, typo
[04:02] <lifeless> just switching folders.
[04:06] <lifeless> poolie: staying stale
[04:07] <lifeless> poolie: as data:  https://bugs.edge.launchpad.net/~mbp/+assignedbugs :)
[04:08] <mwhudson> would bzr reconfigure --append-revisions-only be a useful feature?
[04:08] <lifeless> mwhudson: yes!
[04:09] <fullermd> Only I'm not sure I'm sanguine with it in reconfig.
[04:09] <mwhudson> lifeless: is there an easy way to set it at the moment?
[04:09] <lifeless> mwhudson: vim
[04:10] <lifeless> fullermd: got a better place?
[04:10] <fullermd> Unfortunately, no.  We should have a place for a lot of things like that.
[04:11] <fullermd> And reconfigure is a great command for it.
[04:11] <fullermd> But it's currently fairly purely "reshuffle the arrangement of bzrdir components", and I don't like mixing that with "set branch config options".
[04:11] <fullermd> mwhudson: init has a flag for it, so check the cmd_init code.
[04:11] <lifeless> fullermd: and repository options
[04:11] <lifeless> mwhudson: api wise its easy
[04:12] <poolie> lifeless: i know
[04:12] <lifeless> branch.get_config().set_user_option()
[04:12] <poolie> they're some of my favorite bugs
[04:12] <fullermd> Yah, I know.  I put that one there, remember  :p
[04:12] <poolie> it may be too large of a queue but they're also things that i want to do in my slack time, if any
[04:12] <lifeless> poolie: o/~ these are a few of my favourite things
[04:12] <fullermd> Still a bit uncomfortable with it being there, though.
[04:12] <poolie> it may be there's some better place to store that
[04:12] <lifeless> poolie: Would you be happy having an mbp tag on the tracker?
[04:12] <poolie> mm
[04:12] <poolie> maybe
[04:13] <poolie> tags are still harder to use
[04:13] <poolie> there is this 'bug list' feature that's meant to do exactly what i want here
[04:13] <poolie> no idea when that will be done though
[04:13] <lifeless> I get concerned when I do something with someone else assigned to it.
[04:13] <lifeless> to the point that I don't do those things.
[04:13] <lifeless> or do them less often
[04:15] <poolie> ok
[04:15] <poolie> that's definitely a problem
[04:15] <poolie> some of this stuff is like working in python
[04:15] <poolie> nice, but you have to work with what you've got
[04:15] <lifeless> s/.*, //
[04:15] <poolie> ie encoding all the bugs as tuples :-/
[04:16] <lifeless> :P
[04:16] <lifeless> I like that we can file bugs on launchpad in launchpad.
[04:49] <lifeless> thumper: will pyconz be briliant or just ok?
[04:55] <thumper> lifeless: I have no idea
[04:55] <thumper> lifeless: I expect it to be at least ok
[04:55] <lifeless> very close to uds
[04:56] <lifeless> I'm trying to decide if I should come to pyconnz and give a lightning talk on fixing unittest
[04:56] <lifeless> amongst other things
[05:03] <poolie> lifeless: i think you have a good point about assignment actually
[05:03] <poolie> i've just had enough metadevelopment for today
[05:04] <lifeless> poolie: thats fine, I have too
[05:05] <lifeless> I was expecting a 3 minute call :P
[05:05] <poolie> :-)
[05:16] <poolie> spiv, igc, either of you want to catch up?
[05:16] <poolie> now would be good for me
[05:17] <spiv> poolie: sure, I'll call
[05:17] <lifeless> poolie: I've EOD'd
[05:24] <RobOakes> Hi, I just started using bzr (and I've absolutely loved it, especially the bzr-svn module), but had a couple of new user questions.  Is this a good place to ask them?
[05:27] <RobOakes> I created a test branch from an SVN repository and then posted it to my server.  From there, I made a "working" branch that I could experiment with.  However, whenever I post anything to the working branch, it also posts to the main branch on the server via SFTP.  Is that normal?  And if so, is there any way to disable it?
[05:45] <fullermd> RobOakes: How did you make the working branch?
[05:46] <RobOakes> The first branch I created by using bzr push from within the SVN working copy.  It took four days, but eventually it created a bzr branch of the code.
[05:47] <RobOakes> The "working" branch was created from that initial export using bzr branch /path/to/original
[05:47] <fullermd> What does 'info' tell you in the working branch?
[05:47] <mtaylor> lifeless: ooh, when's pyconnz?
[05:48] <thumper> mtaylor: you mean kiwipycon?~
[05:48] <RobOakes> It says "checkout of branch sftp://path/to/branch"
[05:48] <RobOakes> Related branches push branch: sftp://path/to/branch
[05:48] <thumper> mtaylor: http://nz.pycon.org
[05:49]  * mtaylor is always looking for excuses to go places...
[05:49] <thumper> mtaylor: where are you based?
[05:49] <fullermd> RobOakes: Right.  So you didn't make a branch, you made a checkout (either by running 'checkout' instead of branch, or later using 'bind' or one of its relatives).
[05:49] <mtaylor> thumper: seattle
[05:49]  * mtaylor now notices that CFP is open for US pycon
[05:49] <thumper> mtaylor: we'd love to have you :)
[05:49] <RobOakes> Okay.  Is there any way to unbind it?
[05:49] <fullermd> RobOakes: You want to turn it into a separate branch if that's what you want, with e.g. 'unbind'.
[05:50] <thumper> mtaylor: it is just a weekend though
[05:50] <thumper> mtaylor: we're only just starting out
[05:50] <RobOakes> Very, very nice.  I just tried a test commit and it looks like everything is working.  Now, when I want to update the remote branches, I use bzr push, right?
[05:50] <mtaylor> thumper: I'd love to come! you know, I'm sort of low on flying miles this year...
[05:50] <thumper> mtaylor: need to keep that gold membership?
[05:51] <fullermd> RobOakes: Right.
[05:51] <mtaylor> thumper: yes!
[05:51] <mtaylor> thumper: if I lose it, they'll stop upgrading me places, and that would make me sad :(
[05:51] <thumper> mtaylor: you could talk to me in person about code reviews
[05:52] <mtaylor> thumper: oooh. now there's a business reason to come
[05:52] <RobOakes> Got time for a second question?  Because of reasons too complicated to go into, I do most of my development work on a linux virtual machine.  However, the actual files are stored on the physical hard drive and accessed through an interface.
[05:52] <RobOakes> For reasons I don't understand bzr seems to think that the file permissions change, quite frequently.  This leads to very big (and pointless commits).  Is there a way to tell bzr to ignore changes in the file permissions?
[05:53] <fullermd> The only permission bzr watches is the +x.  That really shouldn't be changing around unless you're flipping it...
[05:54] <lifeless> mtaylor: mid nov
[05:54] <fullermd> (I mean, depending on just what the 'interface' is, it may not mean much, but it shouldn't be _changing_)
[05:55] <RobOakes> I'm not, but the way vmware handles it's remote directories is weird.  Sometimes, they mount as 777 and sometimes they mount with other permissions.
[05:55] <RobOakes> I still haven't quite figured out the overall method to the madness.
[05:55] <fullermd> That's...    pretty insane.
[05:56] <fullermd> Anyway, making bzr ignore it would really be hackaroundish.  Wouldn't be my choice of how to handle it.
[05:56] <fullermd> But given that, no, AFAIK there's no existing config option to say "ignore +x totally plz".
[05:56] <RobOakes> Agreed.  My plan has been to watch the permissions and only commit when they are 777, this prevents the nasty problem.
[05:56] <fullermd> Maybe you could thunk something in with a plugin, but that's way outta my league.
[05:57] <RobOakes> I may think about doing that.  My first desire would be for VMware to tell me why the permissions in the vmfs module are all crazy.
[05:58] <fullermd> Vague memory tells me there is (or was) a plugin to try and allow some +x handling on win32; that might be a place to start.
[05:58] <RobOakes> I'll take a look at that.  I'll look through the devel mailing list and see if I can find anything about it.
[05:59] <spiv> Maybe write a plugin or shell alias that checks that a) a file that should not be +x is indeed not, and b) a file that should be, is.  Then abort/warn before commit as appropriate?
[05:59] <fullermd> Oh, good, somebody competent is here.  I'll leave you with spiv    8-}
[06:00] <RobOakes> That would help solve the problem, and wouldn't be too complicated.
[06:00] <RobOakes> Anyway ... thanks for the help.  That clears up most of the miscellaneous questions I had.
[06:00] <spiv> That would catch any sort of weird "all mounted files get +x"/"all mounted files lose +x" condition.
[06:00] <spiv> And hopefully you can fix the root problem :)
[06:00]  * spiv grabs a late lunch.
[06:01] <RobOakes> Agreed.  What's funny is that I don't seem to have the same issue with my svn working copies.  (But I also haven't spent much time testing it.  I figure it's a weird VMware thing.)
[06:54] <vila> hi all
[06:55] <vila> lifeless, poolie : the test are run with and without locale for quite a few days/weeks
[06:55] <vila> poolie: argh, sorry about the rc/beta misunderstanding :-(
[06:55]  * vila checks mail
[06:56] <lifeless> vila: thanks
[06:56] <poolie> it's ok
[06:56] <poolie> vila, what was the source of the confusion?
[06:57] <vila> hmm, I think I fired qlog to search for examples of updates for version_info and could only found rc examples of course
[06:58] <vila> you certainly mentioned 'beta' but it didn't print hard enough in my brain to override at that point :-/
[06:59] <vila> add to that some stress due to bugs encountered while setting up my 2.0 branch and apport masking me the real cause, etc, => small mistake, big consequences :-/
[07:01] <poolie> ok
[07:01] <poolie> i thought that might have been it
[07:01] <poolie> the examples in the docs are a bit of a two-edged sword
[07:01] <poolie> without them it would be vague but it's easy to mentally or literally copy & paste them
[07:02] <vila> while discussing with jam, I still wasn't sure about my mistake as 'cycle.txt' doesn't mention 2.0beta1 but mention 2.0rc1
[07:02] <vila> so it's still unclear whether 2.0 is different because it starts the new cycle
[07:12] <poolie> jam, you rejected your merge sort bug?
[07:13] <vila> poolie: re-reading releasing.txt, memory comes back also: the document is clear about final releases, less so about candidates and says nothing about betas, I'll outline everything I found by mail
[07:13] <poolie> s/bug/mp
[07:13] <vila> poolie: I saw it too, but I think he wanted to work on a second part instead and I'm pretty sure he send a submission to pqm
[07:19] <lifeless> poolie:
[07:19] <lifeless>   File "/home/robertc/source/baz/pending/working/bzrlib/tests/test_selftest.py", line 2645, in test_run_bzr_user_error_caught
[07:19] <lifeless>     'bzr: ERROR: Not a branch: ".*nonexistantpath/".\n')
[07:19] <lifeless> AssertionError: pattern "bzr: ERROR: Not a branch: ".*nonexistantpath/".
[07:19] <lifeless> " not found in
[07:19] <lifeless> """\
[07:19] <lifeless> bzr: ERROR: Attempt to escape test isolation: 'file:///nonexistantpath/' []
[07:19] <lifeless> """
[07:21] <jml> :(
[07:21] <igc> bbl - some errands to run
[07:21] <lifeless> jml: this is good
[07:21] <lifeless> jml: its a step towards not making 4 directories on every test
[07:22] <jml> lifeless, I was reacting to a costly mistake that bzr let me make
[07:23] <jml> make lots and lots of tedious changes, shelve them, merge in latest trunk, forget to commit, unshelve them, realize they're all mixed together, revert, sigh
[07:23] <lifeless> jml: oh :(
[07:25] <lifeless> jml: did you lose the changes?
[07:25] <lifeless> jml: perhaps you can uncommit, or maybe we kept a backup for you?
[07:27] <jml> backups would end with '~', right?
[07:27] <jml> ... and the modified files aren't open in my editor.
[07:27] <lifeless> mmm, they would have it in the name
[07:27] <lifeless> is there a backup of the shelf in .bzr/checkout/**
[07:28] <lifeless> jml: we should have kept backups for sure, grep for **/*~*
[07:28] <lifeless> em, find . | grep .. or $something like that
[07:29] <jml> no backup in .bzr/checkout
[07:30] <jml> the backups look like they are of the wrong changes
[07:30] <jml> I want what was in the shelf
[07:31] <lifeless> please file a bug about this; we may tease it into several bugs
[07:31] <lifeless> however, the backups are numbered
[07:31] <lifeless> are you looking at the right ones
[07:31] <jml> there's only ~1~
[07:31] <jml> no others.
[07:32] <lifeless> ok, two bugs
[07:32] <lifeless> revert is meant to back things up
[07:32] <lifeless> unless you've set no backups
[07:43] <vila> poolie: ouch, only 2.0rc1 appears on https://edge.launchpad.net/bzr in the download part, that's not true for https://launchpad.net/bzr though
[07:44] <poolie> i like the pedantry of the tooltip on RDF
[07:44] <poolie> vila, you're saying it should show the last stable release too
[07:44] <poolie> sounds like an lp bug
[07:44] <vila> yes
[07:44] <poolie> oh, sigh
[07:44] <poolie> will you file it or should i?
[07:45] <vila> well, had I made a beta I think the problem would have been the same... please do, I'm already filing  another:-/
[07:45] <poolie> oh, which one?
[07:46] <poolie> i'm going to finish soon btw
[07:46] <poolie> for a change
[07:46] <vila> TooManyConcurrentRequests when pulling from lp in a lp bound branch
[07:47] <vila> lifeless: bug #309309 was the one I was referring too yesterday in my review
[07:48] <AfC> Launchpad is pathetic. Again. "The URI scheme "bzr" is not allowed.  Only URIs with the following schemes may be used: bzr+ssh, ftp, http, https, sftp" when trying to give it a bzr:// branch.
[07:50] <poolie> someone just filed a bug on that
[07:50] <poolie> it may be a recent regression
[07:50] <AfC> I mean, shit, even Ohloh manages to get that right.
[07:51] <AfC> poolie: (no, I don't think so. I recall trying to register the proper branch URI for my mainline about a year ago and it didn't work. Back then it _also_ crashed my browser when I tried to file a bug about it, which was exceptional. But now it just errors)
[07:51] <poolie> well, sorry
[07:51] <lifeless> AfC: I think you're being a little harsh; that code tries to be very paranoid (and thats arguably a mistake), but pathetic is a little strong.
[07:52] <AfC> poolie: {shrug} I'm not about to hold their behaviour against you.
[07:52] <AfC> poolie: but this is yet another feather in the cap of why I think it so important to encourage people to realize they don't need to use Lauchpad to work with Bazaar.
[07:54] <spiv> Yeah, I think that's always been the case.  I think there was/is some reluctance to open up unnecessary ports.
[07:54] <AfC> lifeless: perhaps, perhaps not. Given that I've registered an external branch as a project's mainline I don't really see it as necessary that Launchpad advertises "to get this do `bzr branch lp:myproject`. It's like? Huh? That's a mirror, and a 5 hour out of date mirror at that. How about Launchpad advertise `bzr branch bzr://...` like I asked it to.
[07:54] <AfC> lifeless: things like that, again and again
[07:54] <spiv> So my recollection is that refusing bzr:// is not because LP doesn't understand that prefix, but because it knows it can't work.
[07:55] <AfC> lifeless: me registering a release series at a certain well known foreign location and then Launchpad claiming it's where the releases are hosted? That's not cool either.
[07:55] <lifeless> AfC: for some folk its great, because they don't want lots of people pulling directly. Maybe there should be a toggle.
[07:55] <AfC> spiv: that's interesting. Bizarre to my eyes, but certainly informative. Of course, if bzr:// doesn't work maybe someone should take it out of bzr and I'd stop using it.
[07:56] <lifeless> AfC: it works, its just firewalled @ canonical.
[07:56] <spiv> bzr:// works just fine, in general.
[07:56] <lifeless> AfC: is there a bug on this?
[07:57] <AfC> lifeless: classic
[07:57] <spiv> Operationally, the way Launchpad is currently deployed, Launchpad cannot access that port on arbitrary hosts.
[07:57] <AfC> [and you said I was being harsh?]
[07:58] <spiv> It's probably worth revisiting that decision.  At the time there were very few TCP-only bzr branches out there, so it wasn't a big deal.
[07:58] <spiv> And, co-incidentally, someone did file a bug about it recently as mentioned above, so probably someone will be revisiting that decision soon.
[07:58] <AfC> lifeless: I can try and file one if you like. Launchpad's javascript doesn't seem to be crashing Epiphany anymore.
[07:59] <spiv> Oh hey, another Epiphany user.
[07:59] <AfC> :)
[07:59] <AfC> spiv: of course. GNOME integration, baby
[08:01] <poolie> vila: i don't think you put the changelog in the2.0rc1 release on lp?
[08:01] <poolie> vila: i filed bug 419735
[08:02] <vila> good
[08:02] <poolie> (not so important)
[08:02] <poolie> and more importantly bug 419733
[08:03] <poolie> and reopened bug 275677
[08:05] <poolie> vila, also we should probably change the process not to upload source zips
[08:05] <poolie> i misunderstood the request when i added that
[08:05] <lifeless> vila: checking the safety net appears to be 1-2 ms
[08:05] <lifeless> (*20K = most of a minute)
[08:05] <poolie> people actually wanted zips of windows binaries
[08:06] <vila> changelog... oooh, I just understood how it works, but that's not mentioned in releasing.txt and I think at the time I filed  http://bazaar-vcs.org/Download I was already worried because the bugs didn't appear
[08:06] <poolie> lots of bugs appear :)
[08:06] <poolie> which ones did you miss?
[08:06] <vila> I mean they weren't targeted at the milestone
[08:07] <poolie> mm
[08:07] <lifeless> poolie: I'm wondering if your fix to show every test is the right way to fix the test progress bar
[08:07] <vila> also creating the milestone was a key time in my mistale
[08:07] <poolie> rather than what?
[08:07] <lifeless> poolie: simply because if tests are very fast the progress bar starts to dominate :)
[08:07] <poolie> srsly?
[08:07] <poolie> nice
[08:07] <lifeless> I'm closing in on that
[08:07] <lifeless> Ran 203 tests in 2.975s
[08:08]  * jml is reminded of Ubuntu boot discussions
[08:08] <poolie> presumably because of the time to paint it, not to calculate the text
[08:08] <poolie> what's the delta if you run with =none
[08:08] <lifeless> =none ?
[08:08] <lifeless> how would I spell that
[08:08] <vila> BZR_PROGRESS_BAR=none ?
[08:08] <poolie> yes
[08:08] <lifeless> ./bzr --no-plugins selftest selftest
[08:08] <lifeless> ok
[08:09] <lifeless> Ran 203 tests in 2.881s
[08:10] <lifeless> about 0.5ms per I guess
[08:10] <lifeless> so not huge yet
[08:10]  * lifeless ignores for now
[08:11] <lifeless> mmm, but 5% of test time
[08:11] <lifeless> when it gets up a bit higher I'll worry
[08:12] <poolie> 3% according to my calculator
[08:12] <vila> lifeless: why not ./bzr selftest -s bt.test_selftest -s bb.test_selftest ?
[08:13] <poolie> but it seems like these are atypically fast tests?
[08:13] <lifeless> vila: I have a lot of plugins I don't want loaded for this; and its fast enough without -s that I've never learnt to use it.
[08:13] <poolie> i reckon the overall overage is still above 50ms
[08:13] <bialix> does anybody knows why merge shows many files as modified in its output, but status after merge shows there is changed only file or two?
[08:13] <lifeless> poolie: they weren't when I started
[08:14] <lifeless> bialix: you're merging in things that have patches you already have
[08:14] <lifeless> bialix: so the change ends up being nothing
[08:14] <bialix> I don't understand
[08:14] <bialix> why merge shows me incorrect info
[08:14] <poolie> there's a bug that merge should only show files as modified if they actually changed
[08:14] <bialix> ?
[08:15] <poolie> because they 'might have changed'
[08:15] <lifeless> bialix: because it shows the files that had changed on branch A
[08:15] <poolie> but the changes didn't add up to anything
[08:15] <lifeless> bialix: but in your branch, B, they already have the same textual changes
[08:15] <bialix> lifeless: about your fixes for win32 and locks
[08:15] <bialix> if I merge with --weave I don't have conflicts
[08:15] <bialix> but resulting diff after merge is scarely short
[08:16] <lifeless> bialix: for example; if you and I both change "print foo" to "print bar" in different branches, if I merge from you I will get your change, but end up with no difference in the file.
[08:16] <bialix> lifeless: I think this is a bug in merge
[08:16] <lifeless> as poolie says there is a bug open.
[08:16] <bialix> ok
[08:16] <bialix> lifeless: back to your 2 revisions with lock fixes: do you want to review them?
[08:16] <bialix> after I cherrypick them with weave?
[08:16] <lifeless> I'm not entirely sure that this is wrong though, I mean, it would be odd to merge what you thought were different branches and see no output.
[08:17] <lifeless> bialix: if you'd like me too, I'm very happy to.
[08:17] <bialix> lifeless: for me odd thing is that after merge status shows there is nothing changed, while merge shows there is a lot changes
[08:18] <bialix> it makes me nervous
[08:18] <luks> you can always diff against both parents and see if the diffs look the same
[08:19] <lifeless> bialix: I think it should say that this has happened
[08:19] <lifeless> bialix: being totally quiet would be wrong; looking like a normal change and st showing nothing all looks wrong.
[08:19] <lifeless> /all/also/
[08:19] <bialix> luks: I can, but only if I know that bzr lies me
[08:20] <bialix> lifeless: revno 4635 NEWS has completelly unrelated entry:
[08:20] <bialix> * Fix a test failure on karmic by making a locale test more robust.
[08:20] <luks> lifeless: well, if merge doesn't change anything in those files, does it need to list them?
[08:20] <bialix>   (Vincent Ladeuil, #413514)
[08:21] <lifeless> luks: see above
[08:21] <bialix> lifeless: it's not related to your patch. may I  omit it while cherrypicking?
[08:21] <lifeless> luks: its merging a patch from someone, you'd expect the change
[08:21] <lifeless> bialix: sure
[08:22]  * bialix start hates the fact that bialix adding bzr.ico to bzr.exe, grrr
[08:22] <luks> perhaps merge could output some diffstats
[08:23] <luks> so after each file you see how much of it is changed
[08:23] <lifeless> luks: that would be one way
[08:23] <lifeless> M foo.py +0 -0
[08:23] <luks> yeah
[08:23] <lifeless> M bar.py +123 -456
[08:24]  * fullermd goes back to dreaming of having that in log...
[08:24] <lifeless> fullermd: jfdi
[08:24] <lifeless> fullermd: log -p on 2a:)
[08:24] <luks> is it usably fast?
[08:24] <lifeless> fullermd: hey, how did you go with your src tree?
[08:24] <lifeless> luks: oh yeah
[08:24] <fullermd> Oh, yeah, I'll just go design up a new repo format   :p
[08:24] <lifeless> fullermd: shouldn't need to now
[08:25] <lifeless> it should be able to keep ahead of you
[08:25] <fullermd> lifeless: Oh, I didn't.  It's on my "hey, this is probably good enough to try sometime" list.   Soon's work quiets down a little.  15, 20 years maybe.
[08:26] <fullermd> Oh, I think it desperately calls for being cached at commit-time.  log bzr.dev takes 1.6 seconds (with a somewhat chilly cache).  log -p hasn't finished yet...
[08:26] <lifeless> fullermd: in 2a format!
[08:27] <bialix> jam: merge -cN --weave ROCKS!
[08:27] <fullermd> Well, I don't have a sizable 2a branch around.  But still.  I'll bet it's more than a factor or 2 or 3.
[08:27] <bialix> jam: you ** genius
[08:27] <fullermd> (which is my WAG for "pretty expensive")
[08:28] <lifeless> fullermd: so; I know someone that does log -v -p ~ in cron
[08:28] <lifeless> of a big arse branch
[08:28] <lifeless> data >> WAGs
[08:28] <fullermd> Sure, but who's got a hundred thousand revs of ~?
[08:28] <lifeless> fullermd: I mean approximately in cron
[08:28] <lifeless> not homedir
[08:30]  * lifeless watches screens of tests fail
[08:30] <lifeless> well, I expected that
[08:32] <fullermd> "Crap, we just blew up half the moon."  "Well, I expected that."
[08:33] <bialix> lifeless: cherrypicked branch bzr+ssh://bazaar.launchpad.net/~bialix/bzr/bzr-1.18-oslocks-win32/
[08:33] <bialix> should I send merge proposal to the list?
[08:34] <lifeless> bialix: please
[08:34] <lifeless> or just propose it in lp
[08:35] <bialix> poolie knows beforehand that I will ask you him about 1.18.1 and ran away
[08:35] <bialix> ghaa
[08:35] <bialix> poolie: 1.18.1?
[08:49] <bialix> hi garyvdm
[08:53] <vila> poolie: https://code.edge.launchpad.net/~vila/bzr/releasing-clarified/+merge/10792
[09:13] <bialix> lifeless: oops, I've just realized I had to use --author when commit your fixes. I can rework if you wish
[09:13] <lifeless> bialix: its fine
[09:13] <lifeless> bialix: NEWS has my name anyhow
[09:13] <bialix> sorry
[09:13] <lifeless> its fine
[09:22] <vila> lifeless: https://code.edge.launchpad.net/~lifeless/bzr/test-speed/+merge/10775 leads to 14 failures for a full test run (I was checking --parallel=fork was still working but it's unrelated)
[09:28] <lifeless> vila: thanks, could you attach --subunit output from that to the merge thread?
[09:28] <vila> lifeless: yup, trying to do that right now but the output looks far too verbose >-/
[09:29] <lifeless> vila: bzr selftest --subunit | subunit-filter --no-skip > failed.log
[09:29] <vila> subunit-filter ?
[09:30] <vila> got it
[09:31] <vila> hmm, known failures and unavailable features are back <SHUDDER>
[09:32] <vila> lifeless: re-running without fork, will be longer
[09:32] <lifeless> vila: thats because you only fixed it in bzr :)
[09:32] <lifeless> vila: ignore them
[09:33] <lifeless> vila: they'll get filtered out on my end
[09:34] <vila> lifeless: the file is still 2M want that by mail ?
[09:34] <lifeless> vila: sure
[09:34] <lifeless> bzip2 it
[09:37] <vila> lifeless: sent
[09:38] <lifeless> you'll probably like my mail to the list ;)
[09:38] <lifeless> jml: are you on xmpp
[09:39] <jml> lifeless, I think so.
[09:40] <lifeless> as?
[09:41] <lifeless> jml: [gchat counts]
[09:45] <jml> lifeless, I like your recent bzr ML post
[09:45] <lifeless> thank you
[09:45] <jml> lifeless, have you seen http://dev.launchpad.net/FasterTests
[09:46] <lifeless> no
[09:46] <lifeless> or rather maybe
[09:46] <CaMason> I want to fork one of my projects and develop elements of it seperate to the trunk. I will want to periodically merge changes from the trunk into this fork, but not overwite specific files. Is this possible?
[09:46] <jml> lifeless, it should probably cross-pollinate with your post
[09:46] <lifeless> jml: actually, yes I have
[09:46] <lifeless> I've even edited it.
[09:47] <jml> page history doesn't say so, but maybe that's pre-open sourcing
[09:47] <jml> probably was.
[09:47] <lifeless> look for my name
[09:48] <jml> ahh yes
[09:50] <jml> anyway, I'm off for the evening
[09:50] <jml> g'night.
[09:50] <lifeless> ciao
[09:52] <lifeless> LarstiQ: know where jelmer is?
[10:14] <vila> wow karmic booting in16s...
[11:31] <lifeless> vila: have you tried --lsprof-tests?
[12:02] <lifeless> vila: piiing
[12:42] <vila> lifeless: poong, was biking and lunching :)
[12:43] <vila> lifeless: not tried yet, but it's been a while since I wrote a test that took longer than 50ms :P
[12:46] <CaMason> if I've got two branches, one of which is a fork, how do I merge specific changes into the fork?
[12:46] <CaMason> i.e. I don't want to alter some of the files in the fork
[12:47] <vila> bzr merge trunk
[12:47] <CaMason> wont that give me a load of conflict messages?
[12:48] <CaMason> or even merge in some changes I don't want?
[12:48] <vila> The only way to know is to try
[12:48] <vila> Start with a clean working tree (no changes nor pending merges), 'bzr st' should reports nothing
[12:49] <lifeless> vila: 50ms is pretty slow ;)
[12:49] <vila> lifeless: higher value, many are 0ms :D
[12:49] <vila> lifeless: highest value, many are 0ms :D
[12:49] <lifeless> vila: --parallel gives wrong per test timings, btw
[12:50] <vila> lifeless: I know, I don't rely on these, I use '-v' without --parallel when the set is small enough
[12:50] <vila> in fact I mostly use parallel for the whole suite
[12:50] <vila> mostly
[12:51] <vila> but no always :)
[12:51] <lifeless> yea. its on my to-fix
[12:51] <vila> I still use -s more than --parallel
[12:51] <lifeless> subunit's parallel support has landed
[12:51] <lifeless> sorry, progress nesting
[12:51] <lifeless> anyhow, those tests all pass for me
[12:52] <lifeless> with revno: 4659
[12:52] <lifeless> message:
[12:52] <lifeless>   Detangle test listing: its more part of the ui layer not the execute-this-test-layer.
[12:52] <vila> eerk, same revno here
[12:53] <vila> revision-id<EMAIL_ADDRESS>right ?
[12:53] <lifeless> yes
[12:54] <vila> with extensions built ?
[12:54] <lifeless> hmm will check
[12:55] <vila> hmm, mine weren't up to date
[12:55] <vila> dirstae_helpers
[12:56] <vila> tricked by reviewing repeatedly in the same branch may be...
[13:01] <vila> lol, unrelated but funny failure: test_crash.TestApportReporting.test_apport_report_contents AssertionError: pattern "(?m)^CommandLine:.*selftest" not found in CommandLine: ['./bzr', 'tss', '--no-plugins']
[13:01] <vila> tss is an alias for selftest --parallel=fork) :
[13:02] <vila> so, sorry for the false alarm, the above is only failure I get once *I* recompiled my extensions
[13:06] <lifeless> so, +1 to land?
[13:07] <vila> re-reading now
[13:07] <lifeless> also file a bug on that failure
[13:07] <lifeless> tag selftest please
[13:07] <vila> k
[13:08] <vila> I don't follow the stopTestRun merged in python.. Is that in 2.7 ?
[13:08] <lifeless> yes
[13:10] <vila> I thought done() has been defined in subunit and testttools too... will they be updated too ?
[13:13] <lifeless> testtools is
[13:13] <lifeless> subunit I need to check but I think is already
[13:14] <vila> hmm, indeed testtools commit message explain it all
[13:20] <vila> is the stop_early/stop_on_failure transitional or really needed ?
[13:20] <lifeless> subunit does need an update
[13:20] <lifeless> vila: it's contractually correct I think
[13:21] <vila> so both are valid and need to be replicated ? stop_on_failure having higher priority ? Sounds a bit brittle
[13:21] <lifeless> erm
[13:22] <lifeless> I'll need to look closer, we may hav duplication
[13:22] <lifeless> I only shuffled around in this patch
[13:22] <lifeless> so whatever we had before, we have now
[13:22] <lifeless> I thought you meant stop_early -> self.stop()
[13:23] <vila> no :)
[13:23] <vila> You give us a far cleaner TestRunner,
[13:23] <vila> whatever is left appears bigger now
[13:24] <vila> so a loop on result_decorators to propagate a boolean looks highly suspicious
[13:24] <vila> the injection of BZRTransformingResult is uglier too now :)
[13:24] <vila> and I still don't like that self.verbosity handling here
[13:25] <vila> I think that sum up my review, will put that online under approve cause it's better, how about fixing those later
[13:29] <vila> lifeless: reviewed
[13:30] <lifeless> thanks
[13:30] <vila> reagrding 2.7, xfail becomes standard but not UnavailableFeature ?
[13:31] <lifeless> yes
[13:31] <vila> k
[13:40] <sender> hello, can anyone confirm that it is not a problem to just "rm <dir> -Rf" in a shared repository (the shared concept makes me feel this is not the right way to go, maybe leaving information behind in the shared .bzr or, worse, removing data necessary for other repo's under shared), thanks.
[13:42] <vila> sender: if <dir> is a branch all that will be lost is the working tree, the changes not committed there and the easy reference to the branch tip
[13:43] <vila> sender: doing 'bzr log -l 1 --show-ids' before the rm should give you all the needed bits to recreate the branch if needed
[13:46] <sender> vila: thanks. that means that the removed branch will always remain in the shared repo?
[13:47] <vila> the point of the shared repo is to share revisions between branches so the revisions will stay there yes
[13:47] <sender> ok. so, I need the hash @ revision-id or parent to recreate it?
[13:47] <sender> is there a way to fetch those, even after hard-removing a branch under a shared repo?
[13:47] <vila> the revid yes
[13:48] <vila> yes
[13:48] <vila> bzr branch -r revid:<revid> trunk resurrected
[13:51] <sender> hmm where does
[13:51] <sender> sorry, where does trunk points to?
[13:52] <sender> I've removed the branch, i've got the revid of that branch, now i am in the shared dir, and the command above gives me 'trunk' is no branch
[13:52] <vila> hmm, generally I use a shared repo for each project I'm working on, so I always have a branch which is the trunk
[13:52] <sender> and would trunk be the branch that was removed?
[13:53] <vila> err, you have a shared repo without any more branch ?
[13:53] <sender> can I pick just any other branch?
[13:53] <vila> yes
[13:54] <vila> we're cheating here anyway by using the branch as a entry point to the repo
[13:54] <vila> the revid doesn't have to be part of the branch history
[13:54] <sender> ah, nice it works :) yes exactly, it would make more sense to address the shared repo (as far as i can see)
[13:56] <vila> sender: well, we are searching in the garbage can here, so it's not often used either
[13:56] <vila> another way, a bit clearer may be is to do:
[13:57] <vila> bzr branch trunk resurrected ; cd resurrected ; bzr pull -r revid:<revid> --overwrite .
[13:57] <vila> mmm, not sure it's clearer, I guess it depends who you ask :)
[13:59] <sender> interesting. now this is fastforwarding/scrolling back the resurected branch to a certain rev, right?
[13:59] <sender> I guess this would never work with the regular revid, b/c those can diverge between branches, right?
[14:00] <vila> You mean the revno ?
[14:01] <sender> yes
[14:02] <fullermd> You could just as well use "bzr init ; pull -rX .".
[14:03] <luks> would that work?
[14:03] <fullermd> Yah, I've done it a few times.
[14:03] <vila> fullermd: preceding that with mkdir resurrected of course :)
[14:03] <vila> and a cd
[14:03] <luks> interesting, as far as I know, the revno is calculated based on the last_revision_info file
[14:03] <fullermd> Well, init would make the 'resurrected' for you   :p
[14:04] <fullermd> Well, obviously specifying the revid rather than the revno.  But you'd have to do that anyway, unless you had a branch with that rev in its history.
[14:04] <luks> ah
[14:04] <luks> I assumed that was a response to sender's last question
[14:04] <vila> and in the future you may not have to specify 'revid:' once we get some DWIMery there :)
[14:04] <fullermd> Someday, if somebody reviews the patch, it'll even DWIM the revid without having to qualify it   :p
[14:04] <vila> fullermd: hehe, I said it first :)
[14:05] <luks> what's blocking the patch, btw?
[14:05] <fullermd> That means you volunteer to review it, right?   :p
[14:05] <fullermd> Nothing.  People looking at it.
[14:05] <vila> when 2.0 is out, I already told you that there will be many discussions around and including that subject :-D
[14:09] <vila> fullermd: no sequitur, what is the latest bzr version available for FreeBSD and what is the command to install it ?
[14:10] <sender> ok one more question: is there a way to find all the removed branches (head revids I guess) in a shared repo (or look into the garbage can - as vila said it)?
[14:10] <fullermd> Oh, I got 1.18 in ports...   last week I guess.  I usually get 'em submitted within a day of the release, and it takes a few days to get committed.
[14:10] <fullermd> So something like (cd /usr/ports/devel/bazaar-ng ; make all install clean)
[14:10] <vila> bzr heads --dead
[14:10] <vila> you need the heads plugin
[14:11] <vila> and to clean the garbage from the shared repo, you do 'bzr gc'
[14:11] <fullermd> It's in bzrtools.
[14:11] <vila> err, wait, no, we still haven't that one :)
[14:12] <vila> right bzrtools (what was I thinking... wasn't it in another plugin like, years ago ?)
[14:13] <fullermd> Yah, it got Assimilated a while ago though.
[14:13] <sender> that would be sth like git compact?
[14:14]  * fullermd dreams of the day when he has a bzr command to check, reconcile, pack, and gc, all at once...
[14:17] <vila> fullermd: you shouldn't need them :)
[14:19] <vila> fullermd: seems to install 1.13 and failing because 1.13 is already installed
[14:20] <fullermd> 1.13??
[14:21] <sender> i've got two branches in my shared, but bzr heads gives only 1 tip of branch, is this b/c these branches are not diverged?
[14:21] <sender> Both HEADs have a different revno and different parent and revision-ids.
[14:21] <fullermd> Oh, I guess you probably have an old ports tree from a release.
[14:21] <vila> fullermd: 7.2
[14:21] <vila> sender: one is in the ancestry of the other ?
[14:22] <fullermd> sender: 'heads --dead' only lists heads that DON'T already have a branch pointing at them.
[14:22] <fullermd> vila: 'k, so you'll need an updated one.  Clean out the old (e.g., rm -rf /usr/ports/*), and pull down and extract a new with portsnap (e.g., portsnap fetch extract)
[14:23] <fullermd> Then you can get manually rid of the old bzr (pkg_delete /var/db/pkg/baz<TAB>) and install the new, or install portupgrade and use that to catch everything up.
[14:25] <sender> vila: true. thanks all!
[14:25] <vila> sender: so the most recent one is reported, the other one is not a HEAD because it has children
[14:27] <sender> makes sense
[14:27] <sender> so, if i understood correctly, right now there is no way to clean dead heads out of a repo?
[14:27] <vila> fullermd: ok, so from there, it's basically 1) grumble, too old, 2) cd /usr/ports/<magical>/<package> 3) make all install clean (gee don't try -j there >-)
[14:27] <vila> sender: There is: create a new shared repo, copy all the branches you care about from one to the other
[14:28] <vila> not pretty, but works
[14:28] <fullermd> vila: 1.5) pkg_delete to get rid of the old version, yah.
[14:28] <sender> it will do, thanks
[14:28] <fullermd> vila: And it -j's internally already where vetted   :]
[14:29] <fullermd> vila: If you install portupgrade, you can also (after the tree update) just fire a 'portupgrade -a' to upgrade everything with upgrades available.
[14:29] <fullermd> vila: That initial portsnap fetch/extract takes a while, but later updates (`portsnap fetch update`) are reasonably quick.
[14:30]  * fullermd really should sit down and write up a portupgrade replacement someday   :|
[14:30] <vila> fullermd: and what about upgrading the base system ? Not needed ? (*I* don't really care it's for the test farm so your advice will be god speak)
[14:31] <vila> oh, Ill make that 2.5 instead 1.5 if you don't mind :)
[14:31] <fullermd> Not needed right now, I'd say.  7.2's only a few months old.  I don't usually upgrade base but a few times a year, at most (sometimes much less)
[14:31] <vila> k
[14:31] <vila> in rome...
[14:31] <fullermd> My server's still running a pre-7.2 RELENG_7.
[14:31] <fullermd> FreeBSD 7.1-STABLE #0: Tue Feb 17 18:07:44 CST 2009
[14:31] <fullermd> I guess it's probably due for an update...
[14:33] <vila> fullermd: so to compare to Ubuntu, ports ~= main - base system +  universe + multiverse ?
[14:34] <fullermd> (of course, _I_ update base as the first thing I do after installing a system, before I even install any ports.  But I'm nuts  :P)
[14:34] <vila> fullermd: I tried that and got a nice brick yesterday night :)
[14:34] <vila> virtual brick mind you, but yet, that wasn't my day :D
[14:34] <fullermd> Mmm.  I don't know Ubuntu well enough to judge comparisons like that.
[14:35] <fullermd> Base is...  well, base.  Kernel, basic complement of utils needed to run the system (newfs, mount, ps, ls, kill, sh, ssh, that sorta thing), and everything else is in ports.
[14:36] <vila> fullermd: sounds correct
[14:36] <fullermd> Don't need X or a web server or any of those weird fringe languages like python to get the system running, frex, so they're all off in ports   :)
[14:37] <vila> that's not that clear when installing, but I think I get it
[14:37] <fullermd> I should try clarifying those bits in my rant from $YEARS ago.
[14:38] <fullermd> 'course, that's just a subset of "I should update my whole dang website"   :|
[14:39] <vila> haaa 1.18 ! Thanks fullermd that was well spent minutes
[14:39] <fullermd> vila: An offhand shortcut is "ls /{s,}bin /usr/{s,}bin"; that's base.
[14:39] <fullermd> Anything ports does (with occasional exceptions for special cases) is under /usr/local/
[14:40] <vila> and /usr/local in ports !!! That\s why I couldn't make bash my shell !!!
[14:40] <vila> s/in/is/
[14:40] <fullermd> bash?  You mean there are people who don't use tcsh?   :p
[14:41] <vila> pff, I get out of these wars 15 years ago and settle to a shell I can use both interactive and batch :D
[14:41] <fullermd> emacs?   :p
[14:41] <vila> then I learned perl, then python :D
[14:41] <lifeless> vila: an os isn't a shell
[14:42] <vila> fullermd, lifeless: the shell is where I see most of an os from emacs :-D
[14:42] <lifeless> vila: http://paste.ubuntu.com/260346/ - sneak preview for you of my next selftest patch.
[14:43] <lifeless> vila: this one causes some fallout, so its not finishd yet.
[14:43] <vila> ho ho, now you're getting angry :D
[14:43] <vila> is that permit dir and below ?
[14:43] <lifeless> yes
[14:44] <lifeless> I'll think about better names
[14:44] <vila> permit tree
[14:44] <lifeless> doesn't take a working tree
[14:44] <lifeless> possibly just permit_in_url
[14:45] <vila> ok
[14:46] <vila> that will not catch the access via os.xx calls, do you catch lots of pirates already ?
[14:46] <lifeless> with this patch, the time for the selftest only modules drops from ~3.4 seconds to ~2.9 seconds
[14:47] <lifeless> os.xx is in the pipeline
[14:47] <vila> oohh, you remove test_safety_net !! wow :D
[14:47] <lifeless> this catches bzrdir.open(), as it documents
[14:47] <lifeless> yes, test_safety_net triggers this code :)
[14:48] <lifeless> so it fails at commit, not @ arbitrary later time
[14:48] <lifeless> [minor lie there; TestCaseWithMemoryTransport cd's to TEST_ROOT, and TEST_ROOT *is* permitted
[14:48] <lifeless> but it was failing until I realised I needed to permit TEST_ROOT, at least transitionally
[14:49] <lifeless> TEST_ROOT is only permitted for TCWMT, not for TCWT
[14:49] <vila> TEST_ROOT is above self.test_dir right ?
[14:50] <lifeless> yes
[14:50] <lifeless> in TCWT, TEST_ROOT/NAME is permitted
[14:50] <lifeless> in TCWMT,  TEST_ROOT is permitted
[14:50] <lifeless> this isn't global, so its far safer
[14:50] <vila> hmm, that's bad, at least it shouldn't after setUp
[14:51] <lifeless> "at least transitionally"
[14:51] <vila> sorry, just reading the pastebin, I lack context
[14:51] <lifeless> I said that in IRC ;)
[14:51] <lifeless> 23:48 < lifeless> but it was failing until I realised I needed to permit TEST_ROOT, at least transitionally
[14:52] <vila> but transitionally is vague :)
[14:52] <vila> I read it, just couldn't put a precise meaning on  it :)
[14:52] <lifeless> vila: the actual bug is that TCWMT makes any dir on disk at all
[14:52] <lifeless> have to work towards it
[14:52] <lifeless> have to fix bzrlib.config
[14:53] <vila> I was about to mention config files
[14:53] <lifeless> yah
[14:53] <lifeless> so, my approach is
[14:53] <vila> I never clearly understand why it needed that
[14:53] <lifeless>  - add preventative jails replacing detection jails
[14:53] <lifeless>  - ix fallout
[14:54] <lifeless> (wow?!)
[14:54] <vila> ix ?
[14:54] <lifeless>  - fix f allout
[14:54] <lifeless>  - remove detection jails, things go faster
[14:55] <lifeless> anyhow, midnight, and I bet I wake @ 5 again.
[14:55] <lifeless> so I'd better go sleep. gnight.
[14:55] <vila> how about pushing down home/work dirs to TestCaseInTempDIr
[14:55] <vila> good night :)
[14:55] <lifeless> yes, for sure
[14:55] <vila> and the log file too :)
[14:56] <vila> even if some tests needs to inherit from TCITD now instead of TCWMT
[14:56] <lifeless> meh, just delete that
[14:57] <vila> oh, and puting the def setUp just after the def __init__ just at the beginning of the class will get you a beer or two next time we meet :-D
[14:58] <lifeless> hmm?
[14:59] <vila> TCWMT.setUp is lost in the middle of the class
[14:59] <lifeless> oh
[14:59] <lifeless> is it in alpha order?
[14:59] <vila> I bang my head against the desktop each time I missed __init__ or setUp because of that
[14:59] <lifeless> here's a naughty tests
[14:59] <lifeless> [14:59] <lifeless> FAIL: bzrlib.tests.blackbox.test_split.TestSplit.test_split
[14:59] <vila> it was in alpha order, once, years ago ?
[14:59] <lifeless> ----------------------------------------------------------------------
[14:59] <lifeless> RemoteException: RemoteException: Traceback (most recent call last):
[14:59] <lifeless>   File "/home/robertc/source/baz/pending/working/bzrlib/tests/blackbox/test_split.py", line 34, in test_split
[15:00] <lifeless>     self.run_bzr_error(('.* is not versioned',), 'split q')
[15:00] <lifeless> AssertionError: pattern ".* is not versioned" not found in
[15:00] <lifeless> """\
[15:00] <lifeless> bzr: ERROR: Attempt to escape test isolation: 'file:///tmp/testbzr-byGS2o.tmp/' ['/tmp/testbzr-byGS2o.tmp/bzrlib.tests.blackbox.test_split.TestSplit.test_split/', 'file:///tmp/testbzr-byGS2o.tmp/bzrlib.tests.blackbox.test_split.TestSplit.test_split/']
[15:01] <vila> excellent, you need permit_url('q') ?
[15:01] <lifeless> split a/q
[15:02] <lifeless> its running the command outside of a tree altogether
[15:02] <lifeless> which is walking up
[15:02] <vila> hmm, isn't 'a/q' less clear ?
[15:02] <lifeless> working_dir=a is the other way
[15:03] <vila> on the error hand, that's clearly a test that could be done at a lower level right ?
[15:03] <lifeless> quite likely
[15:03] <lifeless> not a broad focus yet
[15:04] <vila> cathc NotVersioned instead
[15:04] <lifeless> I'm focusing on environmental stuff at the moment
[15:04] <lifeless> make TestCase* as cheap as possible.
[15:04] <vila> sure, not in your focu.. exactly
[15:04] <lifeless> this is going to be a fun one:
[15:04] <lifeless> ERROR: bzrlib.tests.blackbox.test_ancestry.TestAncestry.test_ancestry
[15:04] <lifeless> RemoteException: RemoteException: Traceback (most recent call last):
[15:04] <lifeless>   File "/home/robertc/source/baz/pending/working/bzrlib/tests/blackbox/test_ancestry.py", line 58, in test_ancestry
[15:04] <lifeless>     self._build_branches()
[15:04] <lifeless>   File "/home/robertc/source/baz/pending/working/bzrlib/bzrdir.py", line 1172, in sprout
[15:04] <lifeless>     force_new_repo, stacked_branch_url, require_stacking=stacked)
[15:04] <lifeless> BzrError: Attempt to escape test isolation: 'file:///tmp/testbzr-byGS2o.tmp/' ['/tmp/testbzr-byGS2o.tmp/bzrlib.tests.blackbox.test_ancestry.TestAncestry.test_ancestry/', 'file:///tmp/testbzr-byGS2o.tmp/bzrlib.tests.blackbox.test_ancestry.TestAncestry.test_ancestry/']
[15:04] <lifeless>   File "/home/robertc/source/baz/pending/working/bzrlib/bzrdir.py", line 474, in determine_repository_policy
[15:05] <lifeless>     policy = self._find_containing(repository_policy)
[15:05] <lifeless>   File "/home/robertc/source/baz/pending/working/bzrlib/bzrdir.py", line 659, in _find_containing
[15:05] <lifeless> its walking to the root to find a stacking policy
[15:05] <vila> repo policy, I told you about these ones !
[15:05] <lifeless> yah
[15:05] <vila> triggered with TMPDIR too
[15:05] <vila> scary a t first, but then I realized it wasn't harmful
[15:05] <lifeless> so my hook based net catches them
[15:05] <lifeless> :)
[15:06] <vila> excellent
[15:06] <lifeless> but need a pervasive answer to stopping them
[15:06] <vila> may be we need dedicated branches for that kind of patches so that the effort can be spread
[15:06] <lifeless> we may need that
[15:06] <lifeless> OTOH it may be a simple annotation like '@needs_sprout
[15:07] <lifeless> and that would permit_dir TEST_ROOT for now
[15:07] <lifeless> I'd  like to land things that let you and others that are interested chime in in trunk
[15:07] <lifeless> rather than accrue large branches outside
[15:07] <vila> so it may landed somewhere even or *because* it leads to too many failures to be addressed in a single sumbission, right annotations may work too
[15:08] <lifeless> I suspect determine_repo_policy is 90% of these
[15:08] <lifeless> or more
[15:09] <lifeless> if they were running against memory:/// it would be easy
[15:09] <vila> from memory, maybe, many pirates there, but some more, I should retry the experiment, I think I had a script for that
[15:09] <lifeless> 3K
[15:09] <lifeless> here, I'll send you the fail.log
[15:10] <vila> 3000 failures ?
[15:10] <lifeless> :!subunit-filter --no-skip < failed.log | subunit-stats
[15:10] <lifeless> There are 266 lines with trailing white space in 84 files.
[15:10] <lifeless> There are 1961 lines longer than 79 characters in 313 files.
[15:10] <lifeless> Total tests:    3212
[15:10] <lifeless> Passed tests:      0
[15:10] <lifeless> Failed tests:   3212
[15:10] <lifeless> Skipped tests:     0
[15:10] <lifeless> Tags:
[15:10] <vila> ouch
[15:12]  * lifeless waves gnight
[15:12]  * vila waves back
[15:12] <fullermd> vila: BTW, I have this perl script I threw together to munch up the selftest failures and throw out the summary I posted to the list.
[15:13] <fullermd> You may find use for it, considering how many of those BSD failures seem likely to be the same root issue, whatever it may be.
[15:15] <vila> fullermd: sure
[15:15] <vila> the mail you're refferring to is around june 22 ?
[15:15] <fullermd> Sounds right.
[15:16] <vila> actually you may be interested in subunit which provided the same kind of filtering...
[15:18] <fullermd> On its way.
[15:19] <vila> cool
[15:22] <fullermd> No cracks about code quality.  I was young, and I needed the money  :p
[15:25] <vila> fullermd: oh, come on, that's perl, write once, use intensively, forget about it :D
[15:26] <vila> python is far harder to use for throw-away code :-D
[15:27] <vila> hu ho did I see gmake installed, wow, of course the famous BSD make ! :D
[15:36] <fullermd> Well, everybody's gotta use their own local variant.  'till I get my replacement finished, of course, and everybody flocks to it.
[15:38] <vila> well, I'm convinced that the problem is not with tools themselves but rather the way the are use (and in make's case abuse), I was.... impressed by the way autconf render the compile commands totally unreadable a couple of years ago...
[15:39] <fullermd> Well, it had to do that.  Otherwise it couldn't add 3 minutes up front to the build time.
[15:46] <samkramer> good morning
[15:47] <vila> mornibg samkramer, jam
[15:48] <jam> morning vila
[15:59] <vila> fullermd: wow, pertty clean perl, at least relative to my standard, use strict, even use warnings ! use Data::Dumper , the perl  army knive :) Apart from the 8wide tabs, nice code :-D
[16:00] <fullermd> Hey, just 'cuz a language CAN be dirty doesn't mean _you_ have to be in it.
[16:00] <fullermd> (your tab size is your own problem though; mine at 4-char  :p)
[16:01] <vila> fullermd: oooh, literal tabs ! yeah mine is 4-char too but translated in spaces, always
[16:02] <fullermd> Yeah, I believe in tabs for indentation.
[16:02] <igc> night
[16:02] <fullermd> (not, of course, for alignment.  I shouldn't _have_ to say that, but it seems like so many people get caught up in conflating the two...)
[16:03]  * fullermd waves to igc.
[16:03] <vila> night Ian
[16:04] <vila> fullermd: I believe in editors handling the indentation for me and providing a way to share settings inside projects
[16:18] <LarstiQ> lifeless: he left HAR early, the 14th or 15th, to go on a biking trip
[16:18] <LarstiQ> lifeless: from Utrecht to Switzerland iirc
[16:53] <vila> LarstiQ: pff, and no wifi on his bike ?
[16:57] <samkramer> any good links on configuring bazaar from scratch as a centralized server?
[18:03] <montywi> anyone that could help to get bzr 1.17 to work with gtk 0.97.0-final ?
[18:03] <montywi> After upgrading from bzr-1.13, 'bzr pull' dies with:
[18:04] <montywi>   File "/usr/local/lib64/python2.5/site-packages/bzrlib/config.py", line 1246, in get_credential_store
[18:04] <montywi>     cs = cs()
[18:04] <montywi>   File "/usr/local/lib64/python2.5/site-packages/bzrlib/plugins/gtk/keyring.py", line 39, in __init__
[18:04] <montywi>     gobject.set_application_name("bzr")
[18:04] <montywi> AttributeError: 'module' object has no attribute 'set_application_name'
[18:23]  * mneptok pokes poolie, igc, lifeless etc
[18:24] <mneptok> our work is stalled until Monty can commit. :)
[18:28] <montywi> mneptok: I got things going by downgrading to bzr-gtk 0.96.2, but it would be nice if bzr-gtk-0.97 would work too
[18:41] <fullermd> Well, vila cut the release, so it's obviously his fault  :]
[18:55] <bialix> lifeless: I should admit that I don't test your fixes yet
[18:56] <bialix> lifeless: only cherrypicked them and planning to test them soon
[18:59] <vila> montywi: that's bug #403430 and/or #397967, gobject API is a mess regarding the two functions needed there, worse than I thought it seems, please file a bug reporting what os/version you are using
[19:00] <bialix> lifeless: quick test reveals that push now works ok, and shelve at least run without errors
[19:00] <vila> montywi: in the mean time, just commenting out the offending line should do as the surrounding comments will tell you
[19:00] <bialix> vila: bonsoir
[19:01] <vila> bialix: hi !
[19:01]  * vila fades
[19:01] <bialix> today everybody ran away when I want to ask someting
[19:02]  * bialix watches for vila!
[19:02] <vila-dinner> bialix: quick then, gf waiting :)
[19:02] <bialix> gf?
[19:02] <fullermd> I'll run away BEFORE you ask me anything, if that'll help break your streak.
[19:02] <bialix> bon appetite, I'll wait
[19:03] <vila-dinner> girl-friend
[19:03] <Tak> hell - what was the solution to "ERROR: Operation denied because it would change the mainline history" with bzr-svn?
[19:03] <Tak> girl...friend?
[19:16] <bialix> so, I'm just curious, today is karmic featurefreeze, and what version of bzr was included there? I think it should be 1.18, but core devs insist on 2.0. who won in the end?
[19:19] <maxb> !info bzr karmic
[19:21] <bialix> cool, you know black magic
[19:22] <bialix> then I'll continue backport fixes for some annoying bugs
[19:22] <bialix> like https://bugs.launchpad.net/bzr/+bug/418931
[19:24]  * Tak `bzr push --overwrite --no-strict`, wait for horrible things to happen
[19:36] <bialix> !info qbzr karmic
[19:37] <bialix> !info bzr-explorer karmic
[19:37] <bialix> !info bzr-svn karmic
[20:26] <jwhitley> Just popping in here to tell everyone that it *rocks* that "bzr upgrade bzr+ssh://..." works.  Just finished a repo conversion on a remote slice with too little memory to do the conversion locally.
[20:26] <jwhitley> (That with bzr 1.18rc1)
[20:27] <bialix> conversion to 2a?
[20:58] <lifeless> moin
[21:00] <lifeless> bialix: cool
[21:00] <bialix> lifeless: hi?
[21:00] <lifeless> bialix: I'm glad the fixes worked for you
[21:00] <bialix> ah yes
[21:01] <bialix> though new shelve lacks some nice features from old one
[21:12] <jwhitley> @bialix: yes, conversion to 2a.  worked like a charm.
[21:12] <bialix> that's good
[21:15] <lifeless> jwhitley: thats a really good data point. We've got a desire to make upgrade always run remotely; we should document how to force it to do the work locally.
[21:15] <lifeless> igc: ^ what do you think, just a line in the upgrade guide?
[21:16] <jwhitley> lifeless: For some reason, I'd assumed for ages that upgrade was an inherently local operation.  Running out of memory on a remote host forced new awareness.  ;-)
[21:20] <lifeless> jwhitley: oh, did I misunderstand... it ran remotely and that was good?
[21:20] <lifeless> jwhitley: I thought you were saying, you had a remote branch ona server that doesn't have enough memory to do upgrades on  the server?
[21:28] <jwhitley> lifeless: you're correct, sorry to randomize matters.  For no particular reason, I'd assumed that 'bzr upgrade' had to be done on the same host as the branch/repo's filesystem.  I'm terribly glad that isn't the case, since the server does not have enough memory for the ugprade.
[21:28] <lifeless> ok
[21:29] <lifeless> you may find you need more memory for regular push-pull operations though
[21:30] <lifeless> as we're moving more and more code into the server to eliminate round trips
[21:30] <lifeless> if you find this happens you can use 'nosmart+' at the front of a url to disable server side processing for that operation
[21:56] <lifeless> vila-dinner: gimme a shout when you return
[22:00]  * bialix wonder when vila sleep
[22:02] <fullermd> Sleep is for wimps.
[22:02] <fullermd> Happy, healthy, well-rested wimps.  But wimps nonetheless.
[22:03] <bialix> I'm sure vila is not
[22:04] <fullermd> Well-rested?  Yeah, probably not   :)
[22:04] <bialix> :-#
[22:06] <CaMason> how can I copy specific changes from one branch to another?
[22:06] <CaMason> I have two branches, but they need to be kept slightly different
[22:07] <bialix> it depends
[22:07] <bialix> you can use merge -rN..M
[22:07] <bialix> or rebase -r N..M
[22:07] <bialix> err
[22:07] <CaMason> what's the difference?
[22:07] <bialix> replay -r N..M
[22:08] <bialix> merge just merge
[22:08] <bialix> replay will replay commit with all commit metadata
[22:08] <bialix> with merge you can cherrypick changes to specific files
[22:08] <bialix> not entire changeset
[22:09] <CaMason> ok. Don't I lose the 'link' with a cherrypick merge?
[22:09] <bialix> but merge will not carry commit metadata
[22:09] <bialix> yes, you do
[22:09] <CaMason> is my workflow wrong?
[22:09] <bialix> that's why Daggy Fixes is better
[22:10] <bialix> not necessary, it depends
[22:12] <bialix> but at least I'd recommend to read about Daggy Fixes
[22:12] <bialix> to understand another way
[22:17] <bialix> CaMason: if you're OK to share history without sharing some changes, you can merge only istory to preserve "link", but revert wrong changes
[22:18] <CaMason> so merge, commit, revert, commit?
[22:19] <bialix> no
[22:19] <bialix> merge, st/diff
[22:19] <bialix> revert $FILES
[22:19] <bialix> or shelve changes away
[22:19] <CaMason> ah now that's an idea
[22:19] <bialix> commit
[22:19] <CaMason> shelve changes away?
[22:20] <bialix> bzr shelve -h
[22:20] <bialix> shelve aka selective revert
[22:21] <CaMason> I see
[22:24] <CaMason> what is the purpose of shelving them over reverting?
[22:24] <beuno> CaMason, to bring back the change later on
[22:24] <beuno> so maybe you shelve, commit, un-shelve, continue working on that change
[22:25] <bialix> you may want to revert some changes in the one file and retain other changes in the same one file
[22:25] <bialix> well, you can deleted shelved changes
[22:25] <bialix> without bring them back
[22:25] <bialix> unshelve --delete does this
[22:25] <CaMason> I see, great :)
[22:26] <bialix> because bzr require explicit commit after merge you can change everything you want before you commit your merge
[22:27] <CaMason> I didn't realise that, thanks
[22:27] <bialix> so you can do merge only for history without merging changes
[22:27] <bialix> merge; revert . ; commit
[22:27] <CaMason> that's precisely what I wanted
[22:28] <bialix> revert . (dot is intended)
[22:28] <CaMason> how about if I had a lot of files, and only wanted to keep 2 of them? Could I shelve them, then revert, then unshelve, then commit?
[22:28] <bialix> ok, now you're armed
[22:28] <CaMason> armed D:=
[22:29] <bialix> yes you can
[22:29] <CaMason> :)
[22:30] <bialix> what a misterious smilie?
[22:30] <CaMason> D:== that one?
[22:30] <bialix> yeah. it's a cat?
[22:31] <CaMason> lol no. My friend keeps using it
[22:31] <CaMason> thing of that long faced guy from muppets
[22:31] <CaMason> and it's reversed. a 'shocked' face
[22:31] <CaMason> D:
[22:31]  * bialix start s fear
[22:32] <bialix> about armed: there is such russian proverbs: if you informed then you're armed
[22:33] <CaMason> I figured. I wanted to double check
[22:33] <CaMason> http://www.toymania.com/columns/spotlight/megabeaker.shtml
[22:33] <CaMason> that's what the smiley is based on :)
[22:33] <bialix> maybe I've translated it bad
[22:33] <CaMason> D:[22:34] <CaMason> maybe it's just be being an idiot ;)
[22:35] <bialix> funny muppets
[22:35] <bialix> I saw this show
[22:44] <igc> morning
[22:45] <bialix> igc: hi
[22:46] <bialix> you're early today
[22:46] <lifeless> hi igc
[22:47] <bialix> lifeless: btw about test. is there a way to test NotBranchError?
[22:47] <lifeless> bialix: in what regard?
[22:48] <bialix> I have some code that trying to open branch and show error dialog if there is none
[22:48] <bialix> I've mocked gui
[22:48] <lifeless> raise errors.NotBranchError("woo hoo")
[22:48] <lifeless> ?
[22:49] <bialix> inside function?
[22:49] <bialix> how?
[22:50] <lifeless> well just like that
[22:50] <lifeless> raise the exception wherever you want it raised
[22:52] <bialix> lifeless: http://pastebin.com/mf2f7519
[22:52] <bialix> I want to test the code path for except NotBranchError
[22:53] <Sjors> hey :)
[22:53] <Sjors> just reported this bug: https://bugs.launchpad.net/bzr/+bug/420188
[22:53] <bialix> I can't create empty dir in test sandbox
[22:54] <bialix> lifeless: err, I can, but empty dir won;t raise NotBranchError because root of sandboxed temp dir for tests has guard tree
[22:54] <lifeless> bialix: try this
[22:54] <lifeless> make a dir
[22:54] <lifeless> bzrdir.BzrDir.create('dir')
[22:54] <lifeless> this will make an empty dir
[22:54] <lifeless> should stop the search and raise NotBranchError
[22:55] <lifeless> alternatively you could hook into BzrDir.pre_open
[22:55] <lifeless> and raise NotBranchError from there yourself, for the path that you'll be opening
[22:56] <lifeless> that would be a little harder to write the code for; but do less IO/be faster
[22:56] <bialix> I'll try to play with it
[22:59] <lifeless> its basically
[22:59] <lifeless> bzrdir.BzrDir.hooks.install_named_hook("pre_open", my_deny_function, "deny a directory")
[22:59] <lifeless> with
[23:00] <lifeless> def my_deny_function(transport):
[23:00] <lifeless>     raise errors.NotBranchError(transport)
[23:00] <lifeless> this is a global hook, gets reset at the end of the TestCase automatically.
[23:00] <bialix> pre_open is new thing?
[23:00] <lifeless> 1.14
[23:00] <bialix> cool
[23:00] <bialix> that's nice
[23:00] <bialix> thanks
[23:03] <bialix> Sjors: looks like the bug actually in bzr-svn plugin
[23:03] <Sjors> bialix: yes, indeed
[23:04] <bialix> retargeted
[23:04] <lifeless> vila-dinner: ping
[23:36] <poolie> hello bialix, lifeless, vila, igc,
[23:36] <lifeless> hi poolie
[23:37] <lifeless> poolie: oh, btw - http://twitter.com/search/users?q=martin+pool&category=people&source=users
[23:38] <poolie> huh
[23:38] <poolie> updated, it may take a while
[23:47] <lifeless> hi jcastro
[23:48] <lifeless> figured you should be around here as you deal with upstreams <-> launchpad, and we're a big part of that
[23:56] <lifeless> poolie: remind/confirm 12 for lunch
[23:56] <vila> back from movie, lifeless ? I won't stay long though
[23:56] <poolie> still fine
[23:56] <poolie> hello vila
[23:56] <lifeless> vila: hi
[23:56] <vila> hey :-D
[23:56] <lifeless> vila: what movie?
[23:57] <vila> pff, a story about the end of world, french actors, quite good, very strange story. a bit a la Bunuel :)
[23:57] <vila> s/the/an end/
[23:57] <lifeless> vila: I highly recommend district 9
[23:58] <vila> k, noted, will check availability :)
[23:58] <lifeless> vila: I'm thinking of recording somewhere the test themes we have to work through to solve this problem
[23:58] <lifeless> a bit of a todo
[23:58] <lifeless> we could use bugs
[23:58] <lifeless> or a wiki page
[23:58] <lifeless> or something
[23:59] <vila> amazing, I was thinking about using a wiki page to handle bug lists as an alternative to assigning bugs to myself without working on them... But you're talking more about something like the url jml gave for launchpad I presume ?


 Check out "realMyst" … https://play.google.com/store/apps/details?id=com.noodlecake.realmyst
 1 rating, 1 star
 It is legit. I just installed it and it works
 http://www.techrepublic.com/article/how-to-change-the-wake-word-on-your-amazon-echo-to-computer/?linkId=33728520
 https://www.youtube.com/watch?v=2Gr1xxlZbWY


[04:31] <bschaefer> thomi, you were right about that gdb crash
[04:31] <bschaefer> http://pastebin.ubuntu.com/1062024/
[04:31] <bschaefer> causes it
[04:32] <thomi> hah!
[04:32] <bschaefer> I somehow ended up pinging you in this channel haha
[04:32] <thomi> meh
[04:32] <bschaefer> thomi, I was trying to figure out to prove that it was the problem...
[04:32] <bschaefer> soo it's sigc++ fault
[04:32] <bschaefer> haha
[04:33] <thomi> bschaefer: more likely it's the dodgy template code we grabbed off the Internet
[04:33] <bschaefer> thomi, o yeah
[04:33] <thomi> bschaefer: can you update the bug report please?
[04:33] <bschaefer> thomi, but you can't compile code with a lambda with sigc::slot<bool>  if it has a return
[04:33] <bschaefer> thomi, yup!
[04:34] <thomi> cheers
[04:35] <thomi> maybe we'll get a template guru to tell us what we're doing wrong
[04:36] <bschaefer> thomi, yeah, templates are ... odd, my professor has always said java did generics better haha
[04:36] <bschaefer> thomi, before I go, can you review this haha? https://code.launchpad.net/~brandontschaefer/unity/opening-dash-in-scale-mode-SRU
[04:36] <bschaefer> thomi, it was already accpetd in trunk
[04:37] <thomi> sure
[04:37] <bschaefer> awesome thanks. I can go to bed happy I got that gdb problem down to 1 file haha
[04:38] <thomi> bschaefer: approved
[04:38] <bschaefer> thomi, awesome thanks!
[04:38] <bschaefer> im off now, have a good night
[07:51] <sil2100> hm
[07:52] <sil2100> didrocks: since I will be essentially trying to release unity for quantal today, is there a possibility of 'freezing' trunk for today? By 'freezing' I mean disabling merging of new fixes
[07:52] <didrocks> sil2100: well, that's the discussion I tried to had with popey last week
[07:52] <didrocks> as you will define the process release, I understood that mmrazik and popey designed something without trunk freeze
[07:52] <didrocks> so see with them
[07:56] <didrocks> sil2100: also, what about the dee fix?
[08:49] <seb128> didrocks, I guess sil2100 falled asleep ;-)
[08:49] <didrocks> seb128: I'm under the same impression, asking and then sleeping :)
[09:04] <sil2100> ! ;)
[09:04] <sil2100> didrocks: almost done
[09:04] <sil2100> (I have a broken compiz/unity now so I don't see all chat windows)
[09:06] <didrocks> sil2100: sorry, what is almost done? dee or unity? :)
[09:37] <sil2100> didrocks: I had dee in my mind, but actually I've been thinking - do we need to add python3 to the build deps now?
[09:37] <didrocks> sil2100: not really, we just need to ship the additional gir file and we'll be fine
[09:38] <didrocks> as automagic dep doesn't work anyway and not in the gir area itself
[09:42] <sil2100> ACK
[09:52] <sil2100> didrocks: hm, to make this work, I need to modify the original commit I cherry-picked and, so to say, 'hack it' a bit (in dee)
[09:53] <sil2100> didrocks: should I do a quilt patch for that?
[09:53] <sil2100> didrocks: since I'll be modifying a Makefile
[09:54] <didrocks> sil2100: no, just fix it and propose it upstream
[09:54] <didrocks> as par of upstream branch
[09:54] <didrocks> then, cherry-pick your upstream commit into your packaging branch
[11:14] <sil2100> didrocks: did you try running a built unity with the new compiz/nux from -proposed?
[11:16] <didrocks> sil2100: well, as you can see in -proposed, there is a new unity rebuilt against those there :)
[11:16] <sil2100> didrocks: and it works for you?
[11:16] <didrocks> as it was compulsory because of the compiz ABI breaks
[11:16] <didrocks> sil2100: define "works" :)
[11:16] <sil2100> didrocks: does it run and look correctly ;)?
[11:17] <didrocks> sil2100: yep
[11:17] <sil2100> hm hm
[11:17] <sil2100> I'll try installing that then too
[11:18] <didrocks> what's your issue?
[11:19] <sil2100> I built a new packages on my system basing on the -proposed nux etc. and even though unity works, everything (panel, dash, launcher) are completely transparent
[11:19] <sil2100> This happens both on trunk of unity and the current version, after re-building
[11:19] <sil2100> But maybe something's broken on my side when I'm building those locally
[11:20] <sil2100> Yep, the packages from -proposed work normally
[11:20] <sil2100> Shit
[11:26] <didrocks> sil2100: I just tried another build, works wonderfully here :)
[11:26] <sil2100> So I need to find out why it's broken on my system
[11:26] <sil2100> didrocks: thanks
[11:39] <sil2100> Yup, something's wrong with my system, uh
[11:40] <didrocks> what was it?
[11:41] <sil2100> Don't know yet, but even building the very same sources gathered from apt-get source results in a binary with all unity transparent - where the packages from -proposed work fine (very same sources)
[11:41] <sil2100> So maybe I've got broken dependencies or something...
[11:43] <sil2100> didrocks: btw. is there a way to enable -proposed for my local sil2100 PPA? For build-dependencies?
[11:50] <didrocks> sil2100: you can have a ppa build-dep on another ppa
[11:50] <didrocks> sil2100: not sure if it works on real archives. I think it won't
[12:02] <sil2100> hm, dee is failing to build on quantal
[12:05] <didrocks> sil2100: the dee fix seems to have made the test failing, can you look at it, please? https://jenkins.qa.ubuntu.com/job/automerge-dee/68/console
[12:05] <sil2100> didrocks: it's not because of the fix
[12:05] <sil2100> didrocks: it was failing before as well - it's a quantal problem
[12:05] <sil2100> didrocks: I asked someone from my team to look into that
[12:06] <didrocks> sil2100: nice, keep me in touch then :)
[12:06] <didrocks> sil2100: the merge of the dee fix is blocked on that
[12:07] <sil2100> didrocks: I know...
[12:07] <sil2100> didrocks: I just want to prepare first everything related to unity, since A2 is tomorrow
[12:07] <didrocks> sil2100: well, it won't be in alpha2 :) but yeah, we should have releases of all the stack
[12:07] <didrocks> lenses, nux, unity
[12:08] <sil2100> didrocks: unity won't?
[12:08] <sil2100> Oh
[12:08] <sil2100> Ok
[12:08] <sil2100> ...;)
[12:08] <didrocks> well, alpha2 is tomorrow
[12:08] <didrocks> meaning that we are testing the iso already
[12:08] <didrocks> since Monday
[12:09] <didrocks> we don't push the crack on tomorrow and declare the image alpha
[12:09] <didrocks> it got certifications and tests
[12:09] <sil2100> Ah, since we had like INTENSE testing plans for today - hehe, ok, thanks for clarification
[12:09] <sil2100> ;)
[12:09] <sil2100> We'll do those anyway!
[12:18] <sil2100> didrocks: https://bugs.launchpad.net/dee/+bug/1017277
[12:19] <didrocks> mhr3: ^
[12:19] <sil2100> mhr3: could you look into that?
[12:22] <mhr3> y u break gobject-introspection gnome?
[12:24] <sil2100> mhr3: ;)
[12:50] <mhr3> sil2100, https://code.launchpad.net/~mhr3/libunity/more-api-changes/+merge/112340
[12:50] <mhr3> eeh
[12:50] <mhr3> not that
[12:50] <mhr3> sil2100, http://paste.ubuntu.com/1062498/
[12:54] <sil2100> mhr3: checking that now
[12:58] <sil2100> mhr3: it seems to work! Could you request a merge..?
[13:13] <sil2100> mhr3: pretty please with cherries on top... :)
[13:37] <sil2100> mhr3: if you're particulary busy, I can push the MRQ for you instead - if you don't mind ;)
[13:37] <mhr3> sil2100, sorry, just got back from lunch
[13:37] <mhr3> i'm on it
[13:38] <sil2100> mhr3: thanks! Since this bit is blocking another merge that is needed for the dee SRU
[13:45] <mhr3> sil2100, https://code.launchpad.net/~mhr3/dee/quantal-compability/+merge/112358
[13:45] <sil2100> mhr3: thank you!
[13:45] <mhr3> you get the pleasure of approving it
[13:45] <mhr3> fwiw i checked that it doesn't break precise
[14:12] <sil2100> What the...
[14:13] <sil2100> mhr3: you saw https://jenkins.qa.ubuntu.com/job/automerge-dee/69/console ?
[14:13] <sil2100> mhr3: I was actually building the dee package on my quantal machine and nothing like that popped up
[14:15] <mhr3> weird, i was also running both make and make check and it passed
[14:16] <mhr3> sil2100, i guess we use different flags in tests/
[14:17] <mhr3> not sure why the build has yet different ones
[14:17]  * sil2100 sighs
[14:20] <sil2100> mhr3: do you have a neat idea on how to fix this?
[14:24] <mhr3> sil2100, https://code.launchpad.net/~mhr3/dee/remove-thread-init/+merge/112368
[14:25] <mhr3> oh, should have pushed it to the old branch
[14:25] <mhr3> a sec
[14:25] <sil2100> mhr3: does this deprecate the old one?
[14:26] <mhr3> sil2100, pushed to the old one, nevermind this one
[14:28] <sil2100> mhr3: thanks!
[14:28] <sil2100> btw.
[14:28] <sil2100> mhr3: about this one: https://code.launchpad.net/~sil2100/dee/hack_python3_overrides/+merge/112308
[14:28] <sil2100> mhr3: didrocks asked me to push this upstream, since without it python3 overrides are not working at all
[14:28] <sil2100> They won't be installed
[14:29] <mhr3> sil2100, it's breaking build and not respecting prefix, we can't accept that
[14:29] <sil2100> And the merged in previous commit that added python3 overrides in fact overwrites the 2.7, thus breaking everything ;/
[14:29] <didrocks> mhr3: can you get it fix the right way then?
[14:30] <mhr3> let me ask gnome people
[14:30] <sil2100> mhr3: we need to get this at least fixed somehow, since right now it just breaks python2.7 overrides
[14:30] <mhr3> sil2100, if you want fast fix, revert the addition of the python3 branch
[14:31] <sil2100> mhr3: well, we could do that, but the whole point of the dee SRU was to fix python3 - so hm, we'd just have to wait with the SRU until a proper fix is done
[14:31] <sil2100> Or add the whole thing as a distro patch
[14:32] <sil2100> didrocks: maybe just quilt the whole thing..?
[14:33] <didrocks> sil2100: well, let's see what mhr3 can come with :)
[14:34] <didrocks> sil2100: as it's an upstream issue in the end
[14:34] <mhr3> didrocks, that's what we get after you push to our branch? :P
[14:34] <sil2100> didrocks: ok, then we'll wait with the SRU
[14:37] <didrocks> mhr3: completely, you ignored the MR for a month :p
[14:38] <didrocks> mhr3: it's just that my local install of the dee override tricked me in my test I guess
[15:06] <mhr3> didrocks, sil2100, it's it just me? doing "from gi.repository import ..." with python3 on P just gives me "No module gi.repository"
[15:06] <mhr3> so why are we even trying to sru that thing?
[15:06] <didrocks> mhr3: it's just you
[15:07] <didrocks> ah on precise
[15:07]  * didrocks doesn't have a precise box handy
[15:07] <didrocks> waow, we shipped some python3 Quickly template, so I was expecting that gobject-introspection to be here at least
[15:07] <didrocks> I never tested it myself
[15:07] <didrocks> so I have we have the packages :)
[15:08] <mhr3> also, all the other override files from upstream pygobject are only in python2.7 dir, so it wouldn't work either
[15:08] <didrocks> mhr3: yep, I'll try to look at precise later on. Speaking about quantal/trunk now :)
[15:09] <mhr3> didrocks, so try to import Gio on Q
[15:09] <didrocks> mhr3: it works, i can totally tell you that
[15:09] <didrocks> mhr3: this is what my lens is using :)
[15:09] <didrocks> (on Q)
[15:09] <mhr3> the question is if the overrides work
[15:09] <didrocks> I didn't run into any issue for what I'm using
[15:10] <mhr3> try DBusProxy
[15:10] <didrocks> if there are other parts having issue, we ship the override for python3 as well
[15:10] <didrocks> mhr3: what do you try to demonstrate here?
[15:10] <mhr3>       proxy = Gio.DBusProxy.new_sync(...)
[15:10] <mhr3>       result = proxy.MyMethod('(is)', 42, 'hello')
[15:11] <mhr3> use some real service and see if this works
[15:11] <didrocks> mhr3: well, I have enough to make the lens working and answering in python 3
[15:11] <didrocks> apart from this lens
[15:11] <mhr3> (taken from /usr/share/pyshared/gi/overrides/Gio.py)
[15:11] <didrocks> for the rest, we should as well shipping the overriding files for them
[15:11] <didrocks> but that doesn't mean that Dee hasn't a bug in not shipping python3 override file
[15:12] <mhr3> didrocks, nonetheless upstream pygobject will surely need to solve this as well :)
[15:12] <didrocks> mhr3: indeed
[15:12] <mhr3> and clearly they're the experts for this
[15:12] <didrocks> but still I don't see what's your point here and how it prevents solving it for Dee
[18:42] <davidcalle> seb128, thanks for reminding me about errors.ubuntu.com : both top bugs are fixed in trunk, ready for a SRU.
[18:51] <seb128> davidcalle, thanks! popey said they would SRU the fixes
[18:52] <davidcalle> Great :)
[18:52] <popey> nice one davidcalle


[00:51] <bluesabre> evening all
[00:52] <knome> hullo bb
[00:52] <knome> :P
[00:57] <bluesabre> hey knome
[01:36] <bluesabre> knome: contest seems functional
[01:36] <bluesabre> might want to make attribution clearer
[01:49] <bluesabre> knome: would changing any of my account settings in my profile break anything?
[03:51] <bluesabre> knome: did the mail go out for strategy document voting? I'm +1 for the changes
[03:51] <bluesabre> night all
[05:51] <Unit193> Erm..
[10:30] <Nairwolf> hi guys, I've asked the author of a wallpaper what was the licence, and he/she asked me "How will it be shared ?" What can I ask ?
[10:30] <Nairwolf> It will not be the default wallpaper, right, but it will be available for all users, right ?
[11:23] <bluesabre> http://packages.ubuntu.com/xenial/libreoffice-style-elementary is now built by libreoffice, so we should have more leverage with making our theme default
[12:35] <bluesabre> knome, flocculant: https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1548647
[12:35] <bluesabre> gotta run, bbl
[12:35] <bluesabre> (added a comment and debdiff)
[12:40] <Nairwolf> by the way, have you already experimented this bug ?  https://bugs.launchpad.net/ubuntu/+source/partman-basicfilesystems/+bug/990744
[12:41] <Nairwolf> it's really problematic with you choose the option "erase & install" and if you have already a xubuntu installed
[12:44] <flocculant> I've never seen it
[12:45] <flocculant> the issue that is
[12:45] <Nairwolf> I hope to test it again this week-end
[15:37] <ochosi> knome: so if you really want to work on the SASS port lemme know (or just start by pushing a new branch
[17:09] <knome> ochosi, i'll push a new branch at some point, and yeah, it needs to be done, so..
[17:10] <knome> bluesabre, attribution clearer in what way?
[17:10] <knome> bluesabre, changing your profile shouldn't break or affect anything
[17:10] <knome> bluesabre, we only use the username in anything important
[17:11] <knome> bluesabre, no voting on ml yet, i should take it there
[18:47] <ochosi> knome: i'll try to help out with it was what i meant ;)
[18:48] <knome> ochosi, hehe, sure
[18:52] <knome> ochosi, if you have ideas how to get the theme set up so that you can actually test it, i'm happy to hear that
[18:53] <knome> ochosi, i've got the SASS->CSS stuff set up
[18:53] <knome> ochosi, but when i activate the theme that is basically a copy of adwaita with some hex value changes, i see something completely different
[18:53] <knome> ochosi, eg. not all of it is correctly applied
[18:54] <knome> ochosi, maybe that can be related to the asset loading, but i haven't investigated very deeply
[19:45] <ochosi> knome: for that you could actually take a look at numix
[19:45] <ochosi> also, adwaita is normally compiled to some binary format
[21:07] <knome> ochosi, yeah, i have a vague understanding og the gresource format..
[23:27] <bluesabre> knome: "	Specify the attribution name you would like to be used with your submission. Do not insert copyright or year, just the name."
[23:27] <bluesabre> maybe not the clearest thing
[23:28] <bluesabre> or I'm an idiot :D
[23:29] <knome> plz suggest better wording :)
[23:29] <knome> would it help to give an example?
[23:29] <bluesabre> maybe
[23:30] <knome> eg. "not '(c) 2016 Bimbam Bulla', only 'Bimbam Bulla'"
[23:31] <bluesabre> yeah, seeing an example might make it easier.  For some reason I just seemed to struggle when reading it initially
[23:31] <knome> :D
[23:32] <knome> i would have asked for "Your name" on a regular form, but because internet and some people don't want to be known as anything else than Unit193...
[23:35] <bluesabre> :D
[23:38] <Unit193> No, I read "name" and think "Unit 193", 'tis OK.