[03:02] <installhang> has anyone had trouble installing?
[03:04] <filledbyoem> a
[03:05] <filledbyoem> I seem to not be able to install
[05:18] <xubuntu705> hola puede alguien decirme como actualizar mi sistema
[05:19] <cfhowlett> !es | xubuntu705
[10:40] <MethylatorX> Hallo
[10:40] <MethylatorX> how to install compiz and emerald
[12:21] <pkg_add> Hello :)
[16:56] <Mark_D> Just installing 15.05: Installer hangs at "Preparing to install Xubuntu" and network LED flashes. In the 14.04 installer you could enter all details (partitioning, user etc.) immediately and then let it do its job without waiting at the beginning. Has anything changed ?
[17:04] <drc> Mark_D: I too just finished install 15.04 (again :) and had no problems.  Not sure what your specific problem is but I'd start with these (if possible): 1) Check the md5sum of the dl'd iso, 2) upon booting the burnt iso, check the media (from the menu).  If both of these are good, then I'd start looking at the hardware.
[18:57] <datahood> hello people?
[19:00] <datahood> are there any techs here?
[20:38] <eipi-1_> hhhiiiiiiiiiiiiiiiiiiiiiiiiidddddddddeeeeeeeeeeeeeeeeeeeeeeee  hooooooooo!
[22:43] <xubuntu20w> hi
[22:44] <drc> hello


[13:50] <BluesKaj> Hi all
 A4SH
 A45H
[17:30] <stuffandthings> After maybe 2h, though it varies, things just come to a crawl, apps stall, etc, 23.10. Ruled out thermals. Attempting a shutdown/resart makes it get stuck shutting down with 10 tasks left or so. How should I try to find out the cause? BTW this only started to happen about 2 weeks ago.
[17:31] <stuffandthings> the listing of attempting to end those tasks keeps cycling, that part is not frozen ever.
[17:32] <stuffandthings> (that is system-d, right?)
[18:05] <stuffandthings> ugh its happening again
[18:06] <stuffandthings> sudo commands do nothing but running something like top works fine
[19:18] <user|64> hey, new user to Kubuntu, is this the right place to ask a question regarding uhhh, bluetooth being wonk?
[19:19] <user|64> or just refusing to enable
[19:19] <user|64> I *believe* I have bluez
[21:08] <lakitu>  <lakitu> hey - kubuntu here - the audio system tray icon says "No output or input devices found" & I have no sound - how can I get sound? I have audio devices connected
[23:43] <mmikowski> stuffandthings: Probably kernel upgrade related. Try an earlier kernel from 2 weeks ago.
[23:43] <mmikowski> lakitu: What's your hardware?
[23:43] <stuffandthings> so its a known thing?
[23:44] <stuffandthings> i7 7700 based lenovo tiny
[23:44] <mmikowski> stuffandthings: not necessarily, but sounds kernel related.
[23:44] <mmikowski> what is uname -r?
[23:44] <mmikowski> you can poke around in ubuntu kernel bugs to see if it is related. Also check syslog
[23:44] <stuffandthings> im experience it right now, cant open a konsole
[23:45] <mmikowski> tail -f syslog.
[23:45] <mmikowski> well that sucks!
[23:45] <stuffandthings> i need to wait to restart
[23:45] <stuffandthings> atleast 20 min
[23:45] <stuffandthings> unless theres a hotkey to launch konsole
[23:46] <stuffandthings> the taskbar is dead
[23:46] <mmikowski> can you Ctrl + Alt + F2 to switch to tty and then back to Ctrl + Alt + F1?
[23:46] <mmikowski> Alt + Space and type konsole?
[23:46] <stuffandthings> i dont want to risk changing tty right now
[23:46] <stuffandthings> alt space aint doing it
[23:47] <stuffandthings> got it
[23:47] <mmikowski> Well CPU sounds good. Usually quite reliable.
[23:47] <stuffandthings> it was really slow
[23:47] <mmikowski> yeah, you might have a process eating up all your resources.
[23:47] <stuffandthings> but konsole still didnt launch
[23:48] <stuffandthings> not according to top
[23:48] <mmikowski> So while kernel is possible, but may be a different change
[23:48] <stuffandthings> proc monitor is open
[23:48] <stuffandthings> pretty sure its the kernel
[23:49] <stuffandthings> im on 6.4.3
[23:49] <stuffandthings> i think 6.3 was fine
[23:50] <stuffandthings> wait, im on 6.6.3, what am i saying
[23:50] <stuffandthings> 6.5 was fine, lol
[23:52] <mmikowski> stuffandthings: Well, you can try it.
[23:53] <mmikowski> If it works, you've found your culprit. Otherwise, you will want to look at syslog and journalctl to see if there are errors that imply this.
[23:54] <stuffandthings> yeah
[23:54] <mmikowski> You might also want to press Ctrl + Esc and look at processes to see if there's something spinning up. I apologize if this is too remedial.
[23:55] <stuffandthings> i had/have the proc mon open
[23:55] <mmikowski> ok
[23:56] <stuffandthings> and showing all processes
[23:56] <mmikowski> I've got a separate question for others: Anyone seen the Discover with red [X]'s where the images are supposed to go? On 22.04.3 LTS, using the backports-extra repo and Plasma 5.27.9: https://www.reddit.com/r/Kubuntu/comments/17zguut and https://i.imgur.com/E0xrzSk.png.
[23:57] <mmikowski> stuffandthings: anything stand out for taking way too much CPU or memory?
[23:57] <stuffandthings> not a bit
[23:57] <stuffandthings> under 5%
[23:57] <mmikowski> Plasma should take 500K or so.
[23:58] <stuffandthings> plasma shell is the highest for mem but only around 256meg
[23:58] <stuffandthings> system has 16gig


[00:01] <poolie> spiv, hello
[00:01] <poolie> spiv, lifeless, igc, jam, call in a sec
[00:05] <jelmer> 'morning spiv, poolie
[00:05] <jelmer> how should I figure out what the parent revisions of an existing file text revision are?
[00:06] <jelmer> CommitBuilder.record_entry_contents() doesn't take any text_parents arguments
[00:14] <jelmer> lifeless: ^
[00:21] <jml> abentley: how come I have to do 'bzr up' rather than 'bzr co' in the branches that export-loom makes?
[00:22] <lifeless> jelmer: it assigns the value itself
[00:23] <jelmer> lifeless: what if the text wasn't changed but inherited
[00:23] <jelmer> ?
[00:23] <lifeless> it may or may not assign a new one based on the per file graph
[00:23] <poolie> hello jelmer, lifeless
[00:24] <poolie> spiv, oh well that was probably a good place to wrap up
[00:24] <lifeless> what's the goal here, reimplementing this, or using it ?
[00:24]  * jml waves
[00:24] <poolie> good luck
[00:24] <spiv> poolie: :)
[00:24] <jelmer> lifeless: but there's no way for CommitBuilder to figure out what the parents of a text are when recording an existing text
[00:24] <lifeless> jelmer: it has the parent trees as state
[00:24] <lifeless> jelmer: read the code :P
[00:24] <jelmer> lifeless, The parents of the text I mean
[00:24] <jelmer> lifeless: If you commit a merge for example and the merged revision is a ghost
[00:25] <jelmer> lifeless, and one of the texts wasn't changed
[00:25] <lifeless> then it cannot calculate it correctly because the ghost data is absent
[00:25] <jelmer> lifeless, is there no way to determine what the parents of the text are?
[00:25] <lifeless> so it calculates it based on the available data
[00:25] <lifeless> jelmer: you keep repeating this, but I'm really not understanding if you are asking a question, making an assertion, or seeking help solving a problem
[00:25] <jelmer> all three
[00:25] <lifeless> the statment doesn't make sense to me
[00:26] <lifeless> perhaps you could unpack whats going on so I'm not guessing at quite so much at once
[00:26] <jelmer> So, let me start by explaining the issue I'm trying to solve
[00:27] <jelmer> bzr-svn needs to make sure that the parents recorded for a text revision are correct
[00:27] <jelmer> generally, it will induce the parents for a specific text from the information in svn
[00:28] <jelmer> if that doesn't help, it'll look a specific svn property
[00:34] <jelmer> lifeless, Never mind, I just answered my own question
[00:34] <lifeless> :P
[00:34] <lifeless> jelmer: so commit builder has enough state to look in each inventory that is available to determine the files presence, and last-changed, in that inventory
[00:35] <lifeless> jelmer: doing a commit with ghosts should never happen except for an importer from tla
[00:35] <lifeless> ghosting is something that happens deliberately, after revisions are created, not adhoc
[00:35] <jelmer> lifeless: The thing is, bzr-svn uses the commit code also when pushing
[00:35] <lifeless> jelmer: when pushing, there should be no ghosts though
[00:35] <jelmer> lifeless: There can be - when pushing into svn you're not necessarily pushing merged revisions as well
[00:36] <lifeless> also, there is a hole in our ghost support infrastructure; a last-changed value in an inventory which is the value of a ghost will cause checkout/export to fail
[00:36] <jelmer> yes, several people have hit that using bzr-svn
[00:36] <lifeless> yah
[00:37] <lifeless> back shortly, food calls
[00:37] <lifeless> spiv: please let me know if my branch hook patch was sufficient unto the tests
[00:38] <spiv> lifeless: I'll take a look now
[00:38] <jelmer> lifeless: thanks for playing soundboard (hope that's a correct translation)
[00:41] <lifeless> jelmer: sounding board is probably more common, but soundboard is totally understandable :P
[00:42] <spiv> lifeless: looks ok to me.  I can't think of any other worthwhile unit tests to add.
[00:43] <lifeless> spiv: well, its approved once trunk unfreezes
[00:43] <lifeless> spiv: I was more meaning 'does it do what you need'
[00:49] <spiv> lifeless: Oh I see.  Yes, I think so.
[01:02] <lifeless> right, its now yours, enjoy.
[01:03]  * LaserJock crosses his fingers
[01:03] <LaserJock> darn
[01:03] <LaserJock> lifeless: james_w set me up with a little hacky script to import both debian and ubuntu source packages
[01:04] <LaserJock> I got one to work fine
[01:04] <LaserJock> but 2 have died
[01:04] <mwhudson> ah, hi LaserJock
[01:05] <LaserJock> hi mwhudson
[01:05] <mwhudson> LaserJock: i didn't do anything about the matplotlib vs python2.4-matplotlib thing
[01:05] <LaserJock> oh?
[01:05] <mwhudson> LaserJock: i just confused about what the right thing would be
[01:05] <lifeless> LaserJock: oh, shame.
[01:06] <mwhudson> oh, wrong channel
[01:06] <mwhudson> except you're not in #launchpad :)
[01:06] <LaserJock> mwhudson: I'll join #launchpad
[01:09] <LaserJock> lifeless: well, it would be fun if it just worked without any problems
[01:09] <LaserJock> lifeless: but it looks like I might be able to help debug bzr-builddeb
[01:09] <LaserJock> so that's good anyway :-)
[01:13] <lifeless> LaserJock: cool
[01:14]  * markh cheers lifeless on his review-athon :)
[01:17] <jelmer> oops
[01:17] <jelmer> 95 % of the memory usage of bzr-svn appears to be in reading ~/.subversion/config
[01:19] <RAOF> jelmer: That's with respect to the crazy "eat 1GB of ram on multi-pull" bug?
[01:19] <jelmer> RAOF: Yep
[01:20] <spiv> jelmer: whee!
[01:20]  * RAOF wonders how one can blow 1gb resident on reading a config file :)
[01:20] <jelmer> it's parsing ~/.subversion/ for reading every file multi-pull tries to open
[01:20] <jelmer> and multi-pull tries to open a lot of files
[01:20] <RAOF> Aaah.  And no GC gets done?
[01:24] <jelmer> RAOF, Nope
[01:25] <jelmer> RAOF, Ok, that fixes it..
[01:26] <markh> lifeless: in the abspath mail you said to add a test that "sets sys.platform to something windows" - can you please elaborate?
[01:26] <markh> did you mean *checks*?
[01:27] <LaserJock> anybody got an idea of what http://paste.ubuntu.com/44717/ means?
[01:27] <LaserJock> it looks like it's trying to make a path with non-ASCII characters
[01:28] <markh> LaserJock: or possibly even any parent being non-ascii
[01:29] <LaserJock> is that anywhere in the bzr branch?
[01:29] <LaserJock> or does that just apply to the root directory of the branch
[01:30] <lifeless> markh: no, I mean sets
[01:30] <lifeless> markh: you have conditional code based on the platform right?
[01:31] <markh> so set sys.platform for the benefit of other platforms to be able to test it?
[01:31] <poolie> yay bubba :)
[01:31] <lifeless> markh: set sys.platform so that other platforms test that case, yes.
[01:31] <markh> heh - I'd figured that might be a dangerous thing to do, but OK...
[01:32] <lifeless> markh: look for sys.platform in the osutils tests
[01:32] <markh> will do, thx
[01:32] <lifeless> probably can be cleaner than that is, but its an example
[01:33]  * markh goes to wait in line for an hour at the chinese embassy...
[01:34] <lifeless> markh: off to china?
[01:34] <markh> yeah - brother getting married there next month!
[01:35] <markh> I was actually visiting him there earlier this year - quite amazing - but you really need someone who speaks the language close by :)
[01:35] <markh> (which he does)
[01:43] <jml> markh: does he *read* the language?
[02:48] <lifeless> markh: when you get back, I have a branch I'd appreciate your testing
[02:51] <Verterok> a7p: still around?
[02:55] <a7p> jep
[02:55] <a7p> but I won't last more than another 30 minutes
[02:55] <Verterok> ok
[02:56] <Verterok> I'll make it short enough :)
[02:56] <Verterok> a7p: I can't reproduce the crash, also I don't see any related error in the log
[02:56] <Verterok> a7p: could you check ~/Library/logs/Java?
[02:56]  * a7p starts up a terminal
[02:57] <Verterok> if the jvm crashed, there should be a log there
[02:58] <a7p> jep, got a couple of eclipse-crashfiles here
[02:59] <a7p> should I attach one to the bug?
[02:59] <Verterok> a7p: please :)
[03:01] <a7p> Verterok: done
[03:02] <Verterok> thanks! I'll keep digging
[03:04]  * a7p keeps supplying useless treasuremaps
[03:11] <Verterok> a7p: not so useless :)
[03:12] <a7p> ;)
[03:12] <Verterok> a7p: it seems like a bug was fixed in Eclipse 3.3
[03:13] <a7p> would be pritty bad, if they only introduced new ones... *g*
[03:13] <Verterok> a7p: http://lists.apple.com/archives/Java-dev/2007/Nov/msg00014.html
[03:15] <Verterok> a7p: sorry, "it seems that a similar bug was fixed in 3.3"
[03:16] <a7p> looks, pretty much like my problem.
[03:20] <Verterok> a7p: the widget used in the commit dialog will be replaced, pretty soon. it's a work in progress
[03:21] <a7p> wounderful, nice to hear
[03:21] <a7p> if i understood correctly, this is a osx 10.5 issue - other platforms won't suffer from it.
[03:22] <Verterok> I'll try to rollout a new build as soon as possible
[03:27]  * a7p looks happily forward to it - Thanks Verterok, that's Bugreporting the way I like it.
[03:27] <a7p> and now I'm going to put my tired head to rest
[03:29] <lifeless> fooding
[04:14] <Peng_> I should just try this myself, but what does Bazaar do if, when using HTTP, a /.bzr/ directory redirects somewhere else?
[04:14]  * Peng_ tries it himself.
[04:19] <lifeless> spiv: http://marc.info/?l=linux-netdev&m=122091500114869&w=2
[04:21] <lifeless> spiv: details on why coalescing the bytes written to the socket helped
[04:23] <Peng_> Oh, good, it works.
[04:24] <spiv> lifeless: that's a nice clear description of things
[04:25] <spiv> lifeless: It's a pity I learned that stuff the hard way rather than by reading about it :)
[04:25] <lakin> Is there a pdf version of the html guide?
[04:25] <lakin> http://doc.bazaar-vcs.org/latest/en/user-guide/index.html
[04:25] <lakin> ?
[04:27] <lifeless> Peng_: you can redirect a branch, redirecting a repository is likely to die horribly
[04:28] <markh> jml: apparently well enough to read signs and stumble through things, but not well enough to comfortably read a newspaper for example
[04:28] <markh> lifeless: how can I help?
[04:28] <lifeless> markh: test my patch
[04:28] <markh> which one? :)
[04:28] <lifeless> the one I cc'd to you
[04:28] <lifeless> that prominently asks for help :P
[04:28] <markh> _walkdirs
[04:28] <markh> oh :)
[04:29] <jml> markh: when I visited, I found the inability to read the language much more frustrating than being unable to speak it.
[04:30] <markh> jml: I doubt we would have survived ordering in some of the places we ate at, for example.  We would have ended up having a much more "westerners" experience I think
[04:31] <markh> I remember once thinking "surely I can order a coffee" - and failed misterably :)
[04:32] <markh> the "coffee" part was understood, but trying to explain I wanted it to take away was a sticking point :)
[04:32] <lifeless> just get it, then walk out the door
[04:33] <markh> yeah, and just keep walking :)
[04:33] <lifeless> well no, stop and let them change it around now they get the message :P
[04:37] <Peng_> lifeless: Well, I'm redirecting both the branch and repo (from /foo/... to /bar/...). Hopefully it'll be okay.
[04:39] <Peng_> lifeless: BTW, this is very trivial, but I think bzr-search's cmd_index wastes a transport. It opens one, and then passes the URL to index_url, which opens it again.
[04:39] <lifeless> Peng_: patches appreciated :P
[04:41] <Peng_> lifeless: Heh. But what should I change it to do? Make index_url accept a transport? Rename index_url to index_transport or something?
[04:46] <lifeless> Peng_: I think there is a transport taking helper already
[04:47] <lifeless> Peng_: if there isn't, split the current one in two, and call the helper
[04:54] <markh> lifeless: is there a subset of the tests I can specify?  Otherwise things get lost in the noise...
[04:54] <lifeless> ./bzr selftest --no-plugins osutils win32 walkdirs
[04:55] <markh>   File "O:\src\bazaar\bzr\bzr.lifeless\bzrlib\tests\branch_implementations\test_parent.py", line 95, in test_win32_set_parent_on_another_drive
[04:55] <markh>     base_url = b.abspath('.')
[04:55] <markh> AttributeError: 'BzrBranch6' object has no attribute 'abspath'
[04:56] <markh> x7 times
[04:56] <lifeless> heh
[04:56] <lifeless> well thats unrelated :P
[04:59] <uniscript> anyone know a way of using bzr on an svn project, but with local storage but not the whole history?
[04:59] <markh> lifeless: they are the only errors
[05:00] <Peng_> Hmm, I think it winds up opening the branch twice too.
[05:01] <lifeless> markh: cool
[05:01] <lifeless> markh: care to review it ? :)
[05:01] <markh> having a quick look now
[05:01] <lifeless> uniscript: branch --stacked
[05:02] <uniscript> but the docs say that that's just a light checkout or am I reading it wrong?
[05:02] <uniscript> i.e. can I branch, ci merge etc. with such a branch locally with no access to the svn repo?
[05:03] <uniscript> and then just push / merge upstream later?
[05:05] <markh> hrmph - I'm not testing much as I haven't run a build
[05:06] <markh> things are a little uglier when I do :(
[05:08] <markh> lifeless: http://pastebin.com/m27ccab4c
[05:10] <lifeless> markh: could you fix?
[05:10] <lifeless> markh: the intent should be pretty obvious
[05:10] <markh> not today :(
[05:10] <lifeless> sure
[05:11] <lifeless> No windows dev environment here at the moment, so I can't
[05:11] <markh> np
[05:11] <lifeless> uniscript: no, no-access requires full history copied, today.
[05:11] <uniscript> OK thanks, at least I know not to go chasing after the wind :)
[05:12] <lifeless> uniscript: partial-local-storage is what you asked for :P, sorry that its not enough
[05:12] <uniscript> you say "today" is  it in the pipeline?
[05:12] <lifeless> long term plans, nothing to hold breath over :)
[05:13] <uniscript> I can imagine that people would like to join an svn repo from some revision onwards
[05:13] <uniscript> Or I suppose it can be part of the ability to consolidate bzr repos
[05:13] <uniscript> does that exist?
[05:13] <lifeless> I'm not sure what you mean
[05:13] <uniscript> clear out irrelevant history?
[05:14] <uniscript> say I have 1000 revisions in my repo
[05:14] <uniscript> and I don't want all that history kept, can I say merge 200-300 as one revision and dump all that history?
[05:15] <Peng_> Wait, it's just a one-line change to fix this.
[05:16] <Peng_> Well, that's to stop it from wasting one transport. There are others too.
[05:21] <Peng_> lifeless: Do you mind if I pass "foo/" to index_url instead of an URL like "file:///path/to/foo/" or whatever?
[05:29] <lifeless> Peng_: for testing?
[05:41] <lifeless> bug 248275
[05:41] <lifeless> poolie: ^ is that a bubba alias?
[05:42] <mwhudson> i think it's probably a different mentally ill person
[05:44] <Peng_> lifeless: No, because it's the least-invasive way to get rid of that wasted transport (it's just used like get_transport(url).base)
[05:45] <lifeless> Peng_: oh. well foo/ isn't a url, its a url fragment or possibly a unicode path
[05:45] <lifeless> I'd rather not pass paths to url functions, bad things tend to eventually happen
[05:47] <Peng_> ok
[07:01] <vila> good morning bazaar !
[07:18] <lifeless> man I hate libc maintainers sometimes
[07:19] <lifeless> st_mtime is a         def __get__(self):
[07:19] <lifeless>             return self._mtime
[07:19] <lifeless> bad paste sorry
[07:19] <lifeless> st_mtime is a defined macro from bits/stat.h now :(
[07:27] <lifeless> ok
[07:27] <lifeless> 10% shaving by using a compiled stat object
[08:21] <jonnydee> hi, I
[08:21] <jonnydee> 've got a question:  I've got a checkout and did a "bzr ci --local" yesterday. Today I did a "bzr up" and now my local commit from yesterday shows up as a pending merge. Is there any way to get to the previous state where my local commit just will be committed with the next "bzr ci"? without in fact doing a merge?
[08:22] <jonnydee> (for the case my last sentence got cut):  Is there any way to get to the previous state where my local commit just will be committed with the next "bzr ci"? without in fact doing a merge?
[08:23] <jonnydee> and what effects does a "bzr update" have on the local repository if it contains local commits?
[08:26] <Peng_> jonnydee: (Your last sentence didn't get cut. IRC's line length limit is closer to 500 chars, and many/most IRC clients handle it sensibly.)
[08:28] <Peng_> jonnydee: Sorry, but I don't have experience with checkouts, so I can't really answer your question.
[08:28] <jonnydee> Peng_: ok thanks for your feedback
[08:29] <bob2> it's a lightweight checkout?
[08:29] <jonnydee> no, a normal checkout
[08:29] <jonnydee> does it make any difference?
[08:29] <jonnydee> (in my case)
[08:31] <Peng_> jonnydee: My wild guess would be that you can't avoid a merge, because it would require rebasing, and bzr isn't big on that.
[08:31] <Peng_> But I don't know the mechanics of local commits in checkouts, so that may be wrong.
[08:33] <jonnydee> probably you are right... So I'll do a merge... Thanks a lot for your help :)
[08:39] <jml> lifeless: you raiding tonight?
[08:49] <sabdfl> bzr diff -r date:2008-09-09,09:00:00
[08:49] <sabdfl> doesn't seem to work
[08:49] <sabdfl> any suggestions?
[08:55] <uws> sabdfl: bzr diff -r date:2008-09-09T09:00:00
[08:55] <spiv> sabdfl: seems to work ok for me
[08:56] <uws> with a comma it works for me as well
[08:56] <sabdfl> ./bzr diff -r date:2008-09-09TO09:00:00        ~/software/bzr.dev
[08:56] <sabdfl> bzr: ERROR: Requested revision: u'date:2008-09-09TO09:00:00' does not exist in branch: BzrBranch7('file:///home/mark/software/bzr.dev/')
[08:56] <uws> TO?
[08:56] <uws> sabdfl: it's a 0, not O
[08:56] <spiv> sabdfl: There probably isn't a revison after that time, hence the "no such revision" error.
[08:56] <uws> but with comma it works fine for me as well, as I said
[08:57] <sabdfl> doh
[08:57] <spiv> I don't think there's been any commits to bzr.dev since  2008-09-08 07:18:35 +0100
[08:57] <uws> yeah, I get it with dates in the future as well
[08:58] <uws> but the error message is at the very least misleading
[08:58] <spiv> (And "-r date:..." calculates using your local timezone, so comparing is often confusing....)
[08:58] <spiv> Yeah, the error message could definitely be better.
[08:59] <bob2> and different output for "no commits since that time to compare to" and "no commits at or after that time at all"
[10:04] <lifeless> jml: shutdown night
[11:45] <LeoNerd> lifeless: So.. I mailed the mailing list about my "log" range ideas... no response.. :/
[11:54] <kinkie> Hi all.. I've made a little mess, by inadvertently deleting a branch from a repo. I have the branch pushed-to in launchpad, is there a way to recover the branch in my repo without branching and merging again? Thanks
[11:56] <uws> kinkie: if you branch it again, it will (re)use the revisions from your local repo, so it's cheap
[11:56] <awilkins> kinkie: bzr heads --all will show all tips in your repo
[11:56] <awilkins> And uws is also correct
[11:57] <uws> awilkins: What is the difference between "dead" and "alive" heads?
[11:57] <awilkins> My way is tricksier but requires no network connection ; his way is easy and requires minimal network
[11:57] <awilkins> uws: "Dead" heads are ones that are not in a branch
[11:57] <uws> awilkins: well, if you ask on irc i assume a network connection is available ;)
[11:58] <uws> awilkins: how does it know?
[11:58] <awilkins> uws: I presume it recurses, but I'm not sure.
[11:58] <awilkins> uws: I'm going to try it now :-)
[11:58]  * awilkins randomly deletes a branch
[11:59] <awilkins> Yup, dead heads are ones with no branch, but still listed by all
[11:59] <uws> awilkins: it can't know if I have branches somewhere on my machine (or on another machine) that are on that specfic head, right?
[11:59] <uws> e.g. a checkout on another machine
[11:59] <uws> eh, s/checkout/branch/
[11:59] <awilkins> uws: I think it restricts itself to branches within that repo
[11:59] <uws> ah, that makes sense (common setup anyway)
[12:00] <awilkins> Probably very wuick in a no-trees repo
[12:00] <kinkie> awilkins: ok, I found the head. What then? (I'm not so big on bzr recoveries yet ;)
[12:00] <awilkins> Pretty quick in a trees repo too ; it only has to check .bzr folders
[12:00] <kinkie> trunk is 'trunk'
[12:00] <kinkie> let's call the branch 'foo'
[12:01] <awilkins> You should be able to branch it from the listed revid:
[12:01] <kinkie> should I just 'bzr branch trunk foo'? And as long as the name matches, it'll just revive the branch?
[12:01] <awilkins> bzr branch trunk -r revid:<myrevid> foo   ?
[12:02] <uws> awilkins: heads --all shows me a bunch of revisions that have been committed/merged into my branch ages ago. how come?
[12:02] <awilkins> uws: because they're all tips of branches that no longer exist in your repo
[12:03] <awilkins> uws: I suspect if you branch your trunk into another repo and try again they'll disappear
[12:04] <uws> awilkins: I still don't know how it figures that out
[12:05] <awilkins> uws: The help says "revisions without descendants"
[12:05] <uws> awilkins: yeah, but they're merged, so they have revisions on top of them
[12:06] <kinkie> awilkins: that did it. THANKS A LOT!
[12:06] <uws> awilkins: (but indeed, creating a new repo makes them disappear_)
[12:06] <awilkins> There may be more to it than meets the eye then
[12:07] <awilkins> kinkie: Thanks for helping me practice that, never done it before
[12:08] <kinkie> I honestly hope it's an one-shot affair ;-)
[12:09] <awilkins> kinkie: I had a small doubt that it might not work with a revision that was never merged into the branch I'm instructing it to branch, but I just tried it and that works just fine
[12:11] <uws> awilkins: hmmmm. it could be that revisions I've uncommitted show up as heads
[12:11] <awilkins> uws: Aha, yes, I think you've put your finger on it
[12:12] <uws> awilkins: I was triggered by the exceptionally high number of typos in the commit messages :)
[12:15] <Leonidas> maybe I am too stupid, but somehow bzr commit -x does not exclude anything.
[12:56] <poolie> night all
[14:40] <james_w> Leonidas: it works for me, but it doesn't affect the diff shown by --show-diff, which I will file a bug on, is that all you were looking at, or did you look at the committed diff?
[14:41] <Leonidas> james_w: when I committed it has included the file in the output, so I think it has committed it as well. I did an uncommit, but I'll test it again when I find some time to make sure it is not because I'm too stupid to use it.
[14:42] <james_w> Leonidas: I saw it was in the diff, but not the "modified foo" lines it prints, and "bzr diff -c -1" afterwards shows only the changes that I wanted
[14:50] <james_w> bug 268135
[16:02] <james_w> that's not good: "branch.lock_read()" deleting the branch, there's something fishy going on here
[16:04] <Peng_> I was just messing around because of the slow startup thread on the mailing list, I ran "bzr revert" on a single file, and it took like 5 seconds. :(
[16:04] <james_w> ah no, just me being stupid it seems
[16:04] <Peng_> Stupid hard drives.
[16:23] <james_w> I have a problem with code I am writing
[16:24] <james_w> it does "revid = tree.commit()" and then "other_branch.fetch(tree.branch, last_revision=revid)"
[16:25] <james_w> this works fine when the branches are in separate repositories, but fails when they share one
[16:25] <james_w> as the fetch detects that it is fetching to the same repo, and just checks that the last_revision is present
[16:26] <james_w> this check is what fails
[16:26] <james_w> if I use pdb to pause just before the fetch "bzr log" and "bzr heads" from another process outside can see the revision in question
[16:27] <james_w> do I need to do something to make the current process see the just committed revision, or am I missing something else?
[16:27] <foebrian> morning all
[16:27] <foebrian> is there a way to remove a project from bazaar? to unregister it?
[16:29] <Odd_Bloke> foebrian: Why do you want to?
[16:29] <james_w> hi Odd_Bloke
[16:30] <Odd_Bloke> james_w: o/
[16:31] <james_w> Odd_Bloke: how's the job?
[16:31] <foebrian> Odd_Bloke: well i setup bazaar on my home server, and missedtyped the project path, so now 6 projects are considdered one, so i want to unregister it, then fix by adding just one project. if that make sense
[16:31] <Odd_Bloke> james_w: Not bad.
[16:32] <Odd_Bloke> Currently work on OO.o. D:
[16:33] <Odd_Bloke> foebrian: What do you mean by 'projects'?
[16:34] <foebrian> Odd_Bloke: well i have a single project folder /storage/projects then below that i have my project 'branches' like /project1   /project2  /project3, so now all the folders are commited to one 'branch' even though they are seprate projects
[16:35] <foebrian> does that make sense?
[16:36] <Odd_Bloke> foebrian: Right, move /storage/projects/.bzr to somewhere else (just as a backup), and then 'bzr init' in each of the separate project directories.
[16:36] <Odd_Bloke> If the projects are related, you should consider running 'bzr init-repo /storage/projects' beforehand, it'll save space.
[16:37] <foebrian> Odd_Bloke: so the removal of .bzr will remove it then? unfornately they are not related, seprated things
[16:38] <Odd_Bloke> foebrian: Yeah.
[16:42] <foebrian> Odd_Bloke: awesome, it worked! thanks Odd_Bloke!
[16:42] <foebrian> chaos is removed!
[16:42] <james_w> bug 264705 if anyone has any ideas about my problem
[16:43] <Odd_Bloke> foebrian: No worries.
[16:48] <Odd_Bloke> james_w: Are you still working on versioning all of Ubuntu?
[16:49] <james_w> Odd_Bloke: yup
[16:49] <Odd_Bloke> james_w: How's it going?
[16:50] <james_w> Odd_Bloke: it's coming along, spending a week or two bug fixing at the moment before Ubuntu beta freeze, and then back to importing and documentation
[16:50] <Odd_Bloke> james_w: Ah, cool.
[17:00] <LeoNerd> By the way guys: I've just built myself a WinXP VM in VirtualBox. First thing I did was installed Bazaar, which has TortoiseBZR. I'd like to report it JustWorks. It's lovely ;)
[17:01]  * kinkie is away: see you later/tomorrow
[17:04] <Odd_Bloke> kinkie: If you could disable away messages, for this channel at least, that would be appreciated. :)
[17:53] <jam> lifeless: ping me when you wake up, I need you to make a 1.7 branch so I can do 1.7rc1
[18:03]  * justizin wonders why the OSX 10.5 installer is an older version of bzr (1.5) than the OSX 10.4 installer (1.6)
[18:03] <justizin> does the 10.4/1.6 not work on leopard?
[18:11] <Verterok> justizin: the installers are builded by the community
[18:11] <justizin> fair enough :)
[18:11] <justizin> looks like 1.6 installer wants python 2.5 on 10.4, complains i need python 2.5 even though i have it on leopard
[18:11] <Verterok> justizin: I build the 10.4, and 'ld like to build the 10.5 too, but no leopard nor mac-intel here :(
[18:12] <justizin> Verterok: can i run the build for you? ;)
[18:12] <justizin> i've got three intel macs here running leopard.
[18:12] <Verterok> justizin: the 10.4 installer depends on a user installed python. 10.4 only provides python2.3 by default
[18:12] <justizin> love to help..
[18:12] <justizin> yeah i figure as much..
[18:13] <justizin> how does the checking work?
[18:13] <justizin> seems it should be possible to look for python in /System/Library/Frameworks as well as /Library/Frameworks or ~/Library/Frameworks...
[18:13] <Verterok> justizin: let me check
[18:13] <justizin> but i know this is a challenge for many mac / python installers..
[18:13] <justizin> np
[18:14] <justizin> 1.5 will serve my needs for now but i'd love to help make available better installers for mac any way i can.
[18:14] <Verterok> justizin: the 10.4 installer checks CFBundleShortVersionString property in /Library/Frameworks/Python.framework/Versions/2.5/Resources/Info.plist
[18:15] <justizin> is it possible to configure alternative checks, or does it only allow one location to provide a dependency?
[18:16] <Verterok> justizin: I think it's possible, but I dont' know if its going to work
[18:16] <justizin> hm
[18:16] <justizin> is source for the installer accessible?
[18:16] <Verterok> justizin: all the C extensions are compliled against 10.4 dynlibs
[18:17] <justizin> fair enough
[18:17] <justizin> i suppose we can just port it to 10.5
[18:17] <Verterok> justizin: I think phanatic builds the 10.5 installer, and have all the required bits
[18:18] <Verterok> justizin: check Issues section at http://bazaar-vcs.org/MacOSXBundle
[18:18] <justizin> got it
[18:22] <newz2000> in eclipse using bzr-eclipse I've found that if I check out my work into a subfolder of the project (for example, trunk) then eclipse doesn't recognize the project as being managed by vcs. Does anyone know a workaround?
[18:23] <Verterok> justizin: if you don't have a reply, please let me know and I'll push my installer branch to some public location
[18:23] <Verterok> newz2000: Eclipse only support project level team provider mappings
[18:23] <newz2000> oh, too bad
[18:24] <Verterok> newz2000: what is the layout you need?
[18:24] <justizin> Verterok: i'd like if you published it..
[18:25] <Verterok> justizin: at your service ;) http://verterok.com.ar/code/bundle-10.4/
[18:25] <newz2000> well, I was taught an interesting way to manage my project... create a folder, keep my main trunk branch in a sub-folder, and when I'm fixing problems create a branch for the fix and work on it there.
[18:25] <newz2000> I've been using it lately and its working out nice
[18:26] <Verterok> justizin: the pmproj file is a work in progress (tm) to include bzr-svn, just remove both bzr-svn entries and it 'll build ok :p
[18:26] <newz2000> so my project might include these folders: trunk/ add-openid/ jquery126/
[18:26] <justizin> ok
[18:26] <newz2000> all branches
[18:26] <justizin> i was thinking about that challenge myself.
[18:27] <justizin> are you just including a copy of svn 1.5 or wha?
[18:27] <Verterok> justizin: most of the work is there, just need the glue :)
[18:27] <Verterok> justizin: I acctually build bzr-svn against both versions of subversion (1.4 and 1.5)
[18:28] <Verterok> justizin: and adds a check like the python-2.5 one
[18:28] <justizin> interesting..
[18:28] <justizin> 1.4 needs to be patched to work, though, eh?
[18:28] <Verterok> justizin: not any more, bzr-svn now provides it own bindings
[18:28] <justizin> ah-ho
[18:28] <justizin> neato
[18:29] <newz2000> oh, Verterok, you're Guillermo! Nice to meet you and nice work on the project.
[18:29] <justizin> i've just been using bzr-svn on my ubuntu box, then grab a copy using straight bzr from mac or other servers like RH which don't have bzr-svn yet
[18:29] <justizin> still will keep doing that but it'd be nice to have bzr-svn around other places sometimes :)
[18:29] <Verterok> newz2000: thanks! it's greatly appreciated! :D
[18:30] <Verterok> newz2000: maybe your need can be solved if bzr-eclipse provides a way to branch directly from a project
[18:30] <newz2000> I wonder if it would be better to file a bug/feature request on eclipse, though I'm not sure how responsive they are
[18:30] <newz2000> so that vcs can just live in sub folders
[18:30] <Verterok> newz2000: like: right click on on trunk --> branch as new Project. and create add-openid project
[18:31] <newz2000> ah
[18:31] <Verterok> newz2000: that could work for your workflow?
[18:31] <newz2000> yeah, that would work, but the only prob is the directory structure might become a mess
[18:31] <newz2000> let me think it through for a second
[18:32] <Verterok> newz2000: you cound place the new project in any directory you want, i.e: like a share repo
[18:32] <newz2000> so for example, I'm working on a project called XYZ
[18:32] <newz2000> it would go into workspace/XYZ
[18:33] <newz2000> and that would be the root of my project (no trunk/ folder)
[18:33] <Verterok> justizin: poke me if you need some help to get the whole build process working (I know it need documnetation)
[18:33] <newz2000> and to add a feature I branch from there to a new project at workspace/XYZ-feature23/
[18:33] <newz2000> does that sound right?
[18:33] <justizin> np doing a few things atm but will prod a bit and see what errors i get if i try a build
[18:34] <Verterok> newz2000: that is one approach, actually, you could do taht with current bzr-eclipse
[18:34] <newz2000> yes, I believe so
[18:34] <Verterok> newz2000: also, you can place the projects inside /whatever/path/you/like :)
[18:35] <newz2000> oh, really? I just use the default options usually
[18:35] <newz2000> then let me try that, it is probably the easiest solution
[18:35] <newz2000> and fixes another problem I'm about to experience since the python-path in pydev is set per-project
[18:36] <Verterok> newz2000: also, if you want the "branch from project into a new project", please file a bug :)
[18:36] <newz2000> ok, thanks for your time Verterok, I appreciate the help
[18:37] <Verterok> newz2000: np, glad to help
[18:37]  * newz2000 just tried it - it works!
[18:39] <Verterok> great!
[19:54] <ericvw> If I have standalone branch, but I want to migrate it into a centralized development work-flow because I will be on multiple computers, how would I go about migrating?
[19:55] <fullermd> Push it up to your central location, and use 'bind' or 'reconfigure' to turn its current location into a checkout of the central branch.
[19:56] <ericvw> fullermd: and it will know from the push where to update from and commit to?
[20:08] <sabdfl> hey beuno
[20:10] <beuno> hey sabdfl
[20:10] <beuno> how's it going?
[20:10] <sabdfl> groovy here, thanks. you?
[20:10] <beuno> better now that I have internet again  :)
[20:14] <fullermd> ericvw: No, from the bind/reconfigure.
[20:14] <fullermd> ericvw: The push just sets up the data in the central location.
[20:30] <ericvw> fullermd: thanks!
[20:53] <strk> can a repository be downgraded to an older version to be compatible with older bzr clients ?
[20:56] <jelmer> strk, generally, yes
[20:56] <jelmer> strk: "bzr upgrade --old-format" (where old-format is the name of the format to downgrade to)
[20:56] <strk> Could not load movie 'http://request/remote.php?theme=touchscreen.swf'
[20:57] <strk> (sorry)
[20:58] <willyyam> any reason why bzr is a bad choice as a backend for a versioned backup system?
[20:58] <strk> willyyam: it's too new for debian stable users :)
[20:59] <strk> is also slower then CVS
[20:59] <willyyam> or, to put it another way, are twice-daily large binary blobs a problem over a long time (5+ years)
[20:59] <willyyam> actually, I use it on debian stable daily
[20:59] <strk> that one ships 0.11 it seems
[21:00] <strk> we're using 0.16 and somewhat lost compatibility
[21:00] <strk> so you can't fetch gnash sources from debian stable, unless you upgrade bzr
[21:00] <strk> it sucks
[21:00] <jelmer> strk: Lenny will be out soon hopefully :-)
[21:00] <jelmer> strk, performance is pretty bad with old formats though
[21:00] <strk> soon == few monts
[21:01] <strk> jelmer: I'm talking about performance with 0.16 unfortunately
[21:01] <jelmer> strk: but yeah, bzr upgrading to an older format should work
[21:01] <strk> I guess downgrade would make it even slower ?
[21:01] <strk> it takes from 15 to 30 minutes for a simple commit on a GPRS connection
[21:01] <strk> about 1 minute on a DSL
[21:02] <strk> the GPRS experience makes you hate it :)
[21:02] <strk> but you can commit to a local branch while out-of-the-office and merge when back on high bandwidth, which is a bit harder with CVS
[21:54] <beuno> pickscrape,
[21:54] <beuno> "ping"
[21:54] <beuno> is this what I'm suppose to be looking at?  lp:~pickscrape/loggerhead/directory_breadcrumbs
[22:00] <beuno> mwhudson, I'm trying to remember what was wrong with lp:~pickscrape/loggerhead/directory_breadcrumbs
[22:00] <beuno> but everything seems fine
[22:00] <beuno> do you remember why we didn't merge that in the end?
[22:03] <pickscrape> beuno: yes, I think that was it
[22:03] <lifeless> jam: made
[22:03] <jam> lifeless: thanks
[22:03] <beuno> pickscrape, it looks fine to me. You fixed everything, didn't you?
[22:03] <lifeless> the losas have that documented too FWIW
[22:03] <pickscrape> Probably some hideous use of METAL that would have made the loggerhead codebase horrible :)
[22:04] <pickscrape> I think I did, but it probably needs a really good test and review to make sure I didn't miss anything or code it into a hole or anything like that
[22:04] <beuno> pickscrape, fire off the merge request, I'll take a look at the code
[22:04] <beuno> I've been using it, and can't find any problems with the UI at all
[22:05] <pickscrape> merge request via LP right?
[22:06] <beuno> yeap
[22:10] <mwhudson> beuno: maybe i just haven't got aroudn to looking at the lastest version
[22:10] <beuno> mwhudson, yeah, me neither, but trying to get up-to-date today with LH stuff  :)
[22:10] <beuno> thanks
[22:10] <mwhudson> beuno: good idea
[22:10] <pickscrape> Merge request sent
[22:11] <pickscrape> Just reading my commit comments on that branch, I was concerned about having to create an inventory object for the annotate view.
[22:14] <ivantis> hello
[22:14] <ivantis> how do i log in with bzr to launchpad? i need to push some code
[22:14] <ivantis> i already have an account
[22:15] <beuno> ivantis, https://help.launchpad.net/BzrHowto
[22:15] <ivantis> thx
[22:17] <kwah> hi everyone
[22:17] <kwah> I tried to ask on a mailing list... https://lists.ubuntu.com/archives/bazaar/2008q3/047006.html
[22:17] <kwah> but got no reply
[22:18] <kwah> either I could not find relevant information myself
[22:18] <kwah> or it is the lame question
[22:18] <kwah> any comments?
[22:19] <mwhudson> kwah: well, if you have a shared repo upgrading the repository is a separate thing from upgrading the branches
[22:20] <mwhudson> kwah: the main negative impact of upgrading is that people using older versions of bzr won't be able to access your branches
[22:20] <kwah> mwhudson, and what about branches that were checked out?
[22:20] <kwah> not branched, I mean
[22:21] <mwhudson> the branch/checkout distinction is basically irrelevant here
[22:21] <mwhudson> or do you mean lightweight checkouts?
[22:22] <kwah> I am wondering, because some people are working with repo and I do not know, what they will see
[22:22] <mwhudson> either way, the only impact would be better perfomance :)
[22:22] <kwah> error message upon checking in
[22:22] <mwhudson> no
[22:22] <kwah> no, not lightweight
[22:22] <mwhudson> ah
[22:22] <mwhudson> actually, the conversion process is kind of slow
[22:23] <mwhudson> so using a knit branch that's a checkout of a packs branch, say, might be a little tedious
[22:23] <mwhudson> but it would _work_
[22:23] <kwah> so it will be just transparent for the user?
[22:24] <mwhudson> right
[22:24] <kwah> hm... I guess I have to experiment myself more.
[22:24] <kwah> anyway, it would be nice to have some points about this in documentation
[22:24] <kwah> help messages are kinda cryptic
[22:25] <mwhudson> file a bug, maybe?
[22:25] <kwah> mwhudson, thanks for the explanation
[22:25] <kwah> mwhudson, I may try
[22:25] <mwhudson> np
[22:34] <jam> lifeless: you created the 1.7 branch, but didn't give me authorization to commit to it.
[22:34] <lifeless> jam: fixing
[22:35] <lifeless> 7am :P
[22:35] <lifeless> done
[22:37] <jam> np
[22:37] <jam> thanks
[22:38] <lifeless> you forgot to time just python
[22:38] <lifeless> to get the delta for locale
[22:41] <jam> lifeless: sure, replied
[22:54] <beuno> mwhudson, http://launchpadlibrarian.net/17058288/loggerhead_changes_path.diff
[22:55] <beuno> related to: https://bugs.edge.launchpad.net/loggerhead/+bug/260363
[22:55] <beuno> we're doing that everywhere else in LP
[22:55] <beuno> +1 to apply that patch?
[22:55] <beuno> s/LP/LH
[22:55] <beuno> I'm starting to get dizzy  :)
[22:55] <mwhudson> beuno: s/not path is None/path is not None/
[22:56] <mwhudson> and if we're really doing that EVERYWHERE in LH, i guess it should be in TemplateView
[22:56] <beuno> I knew this wasn't going to be that easy...
[22:56] <beuno> let me see how this can be refactored...
[22:59] <mwhudson> beuno: it seems all the views a pretty consistent about how they handle 'args'
[22:59] <mwhudson> either it's <revid>/path
[22:59] <mwhudson> or they ignore it
[22:59] <mwhudson> so we could change the signature from
[22:59] <mwhudson> get_values(self, h, args, kwargs, response)
[22:59] <mwhudson> to
[23:00] <mwhudson> get_values(self, h, revid, path, kwargs, response)
[23:02] <beuno> mwhudson, good idea. Let me change that and see how it looks
[23:02] <mwhudson> beuno: thanks :)
[23:05] <beuno> mwhudson, LH seems to be acting up again: http://bazaar.launchpad.net/~bzr/bzr/trunk/annotate/3697?file_id=setup.py-20050314065409-02f8a0a6e3f9bc70
[23:18] <beuno> Verterok, w00t!
[23:18] <beuno> thanks for that
[23:18] <Verterok> beuno, mwhudson: ^
[23:19]  * Verterok just send the review request
[23:19] <mwhudson> ?
[23:19] <mwhudson> ah right
[23:19] <Verterok> mwhudson: Bug #243415
[23:20] <poolie> good morning
[23:20] <beuno> morning poolie
[23:20] <Verterok> mwhudson ,beuno: the template needs some love, but it would be great to get some early feedback
[23:21] <james_w> hi poolie.
[23:21] <Verterok> hi poolie
[23:21] <beuno> Verterok, I can give it some love. That's the easy part  :)
[23:21]  * poolie feels welcome
[23:22] <james_w> poolie: a friend told me that the "topics" thing on the mailing list doesn't seem to be working correctly, merge requests seem to be delivered even if the merge topic isn't desired.
[23:24] <lifeless> abentley: bb is down?
[23:24] <james_w> hey lifeless
[23:24] <Verterok> beuno: it would be *really* appreciated
[23:25] <abentley> lifeless: restarted
[23:25] <beuno> Verterok, I'll try and get to that after the refactor I'm doing
[23:25] <lifeless> abentley: thanks
[23:26] <Verterok> beuno: no hurry. thanks :)
[23:26]  * lifeless waves around
[23:26] <poolie> hello lifeless
[23:27] <beuno> howdy lifeless
[23:27] <lifeless> turns out that the vodafone system allows their helpdesk line to be put in as the 'notify me that a bill has been emailed' number
[23:27]  * lifeless is satisfied
[23:29] <james_w> if I have two branches which share a repository, and commit to one, should the commit be instantly visible in the branch.repository of the other?
[23:29] <james_w> https://bugs.edge.launchpad.net/bugs/264705
[23:29] <mwhudson> pickscrape, beuno: i think that now History objects only last for the duration of a request, get_inventory should cache the inventories it returns
[23:31] <lifeless> james_w: if the other branch drops its read lock to 0, then ups it, yes
[23:31] <lifeless> james_w: but while locked the other repo may not refresh its indices list
[23:32] <lifeless> jam: ping
[23:32] <pickscrape> mwhudson: my worry was whether the breadcrumbs code adds an inventory object to the annotate page that was not needed before
[23:32] <mwhudson> pickscrape: it was created anyway
[23:32] <pickscrape> mwhudson: in that case I'm not worried :)
[23:32] <mwhudson> pickscrape: in annotate_file, and possibly in get_file_path
[23:33] <mwhudson> pickscrape: but it would be better to create it only once, hence the caching suggestion
[23:33] <james_w> lifeless: thanks. Any suggestions for how to solve this bug?
[23:33] <pickscrape> mwhudson: oh, you mean it doesn't actually do the caching at the moment?
[23:33] <mwhudson> pickscrape: right
[23:34] <pickscrape> ok
[23:34] <lifeless> james_w: what bug
[23:36] <james_w> lifeless: 264705
[23:37] <lifeless> james_w: as I said, drop the references to the branch after the merge operation
[23:37] <Yasumoto> I'm working with the fiveadayapplet, does anyone happen to know what error code 104 is?
[23:37] <lifeless> no idea, we don't use numeric error codes
[23:38] <lifeless> so its either not related to bzr, or coming from the OS
[23:38] <james_w> lifeless: doesn't that introduce a race condition?
[23:38] <Yasumoto> kk, that'd make sense why Google wasn't showing anything related to bzr, thank you :)
[23:38] <lifeless> james_w: you say you have branch A and B, you do something on A, and then B fails to see the data?
[23:39] <james_w> Yasumoto: /tmp/5-a-day-applet.txt may help you to debug
[23:39] <lifeless> james_w: if B is locked prior to doing the task on A, B will not see new data introduced by A until B has been unlocked
[23:39] <lifeless> james_w: what races are you worried about ?
[23:40] <Yasumoto> james_w: awesome, thanks for the heads up
[23:40] <james_w> lifeless: well, if B is unlocked and locked again isn't there time for the branch to be modified leading to trouble
[23:41] <lifeless> is B write locked or read locked?
[23:41] <james_w> write locked, it needs to do a merge of this new revision
[23:42] <lifeless> and sure, someone else could grab a write lock
[23:42] <james_w> perhaps I don't need the fetch there, and can move it up a function
[23:42] <lifeless> but if you do rev = B.tip, B.unlock();b.lock_write(); check B.tip == rev
[23:42] <lifeless> you can be sure noone has altered the tip
[23:43] <lifeless> I don't understand why you would mutate branch A while holding a write lock on B
[23:43] <lifeless> which branch are you actually working on :P
[23:43] <mwhudson> pickscrape, beuno: i made a few more changes: https://code.edge.launchpad.net/~mwhudson/loggerhead/directory_breadcrumbs
[23:43] <mwhudson> take a look?
[23:44] <mwhudson> pickscrape, beuno: here's the diff of all of em http://bazaar.launchpad.net/~mwhudson/loggerhead/directory_breadcrumbs/revision/216?remember=211&compare_revid=211
[23:44] <james_w> lifeless: A is the "upstream" branch and B is the "packaging" one, this command commits the new upstream, and then merges it to the packaging one, so we need to write to both
[23:45] <james_w> lifeless: it locks B early to check there are no uncommitted changes, and get some info from it, but it could do the unlock I think.
[23:45] <lifeless> james_w: to me they are separate steps, is there any need to make the aggregate atomic ?
[23:45] <beuno> mwhudson, lovely.  +1
[23:46] <mwhudson> beuno: i guess i'll merge
[23:46] <james_w> lifeless: I think having it as one command makes sense. Is that what you mean by atomic?
[23:46] <lifeless> no
[23:46] <poolie> abentley, thanks for reading and replying to my mail
[23:46] <beuno> mwhudson, yes please!
[23:46] <lifeless> atomic - all-or-nothing
[23:46] <abentley> poolie: np
[23:46] <lifeless> indivisible etc
[23:47] <poolie> i have to admit the content of the reply was at first discouraging
[23:48] <james_w> lifeless: it doesn't really need to be. However the upstream branch is ephemeral, so currently it "disappears" on any error.
[23:48] <lifeless> james_w: ok, well I'd either patch bzrlib to have a public refresh-view method to trigger a refresh, or drop and reacquire the lock
[23:49] <lifeless> poolie: what email was discouraging?
[23:49] <pickscrape> mwhudson: all looks ok to me
[23:49] <mwhudson> pickscrape: good, because i just merged it :)
[23:49] <mwhudson> pickscrape: thanks!
[23:49] <pickscrape> hehe :)
[23:50] <poolie> aaron's re what do we do now
[23:50] <abentley> poolie: I'm sorry for any hurt feelings.  I felt it was important to be frank.
[23:50] <poolie> it is
[23:50] <pickscrape> Funny how someone who is picky about whitespace can be picked up on whitespace by someone else who is also picky about whitespace :)
[23:50] <james_w> lifeless: thanks, it's late now, but you've probably given me enough to fix this tomorrow, thanks.
[23:50] <poolie> i'd prefer that to folks just smiling and nodding
[23:52] <lifeless> poolie: ah right
[23:52] <lifeless> hadn't found that reply at that point
[23:52] <lifeless> hmmm food, that will make me smile and nod
[23:53] <abentley> poolie: I was a bit surprised at your suggestion, because I thought we agreed that too many cooks contributed to our problems with stacking.
[23:53] <Verterok> mwhudson: I added a --reload option to serve-branches (mainly to ease dev's life :): http://bazaar.launchpad.net/%7Eguillo.gonzo/loggerhead/reloader/revision/220
[23:54] <beuno> Verterok, :O
[23:54] <mwhudson> Verterok: ah, you look like someone that knows somethign about paste!
[23:54] <beuno> Verterok, gazillion thanks!!!!
[23:55] <Verterok> mwhudson: not at all :)
[23:55] <beuno> mwhudson, we need that merged. Now!
[23:55] <beuno> millions of hours spent restarting LH....
[23:55] <Verterok> mwhudson: just readed some docs, and the source ;)
[23:55] <mwhudson> beuno: you have the powah
[23:55] <mwhudson> Verterok: :)
[23:55]  * beuno excercise it
[23:56] <beuno> mwhudson, don't believe Verterok. He knows plenty, he's just shy
[23:56] <Verterok> beuno: before merging, let me update serve-branches.1
[23:57] <Verterok> beuno: hehe
[23:57]  * Verterok hides
[23:57] <beuno> Verterok, sure. Push, I'll pull, etc
[23:58] <igc> morning
[23:58] <james_w> morning igc
[23:58] <beuno> morning igc!
[23:58] <igc> hi guys
[23:58] <beuno> all the cool people are around today
[23:58] <Verterok> beuno, mwhudson: it's the --reload help description ok?
[23:58] <Verterok> hi igc
[23:58] <igc> hi
[23:59] <poolie> hello igc!
[23:59] <mwhudson> Verterok: i guess it should be clear that the application gets restarted when the application changes
[23:59] <igc> hi poolie
[23:59] <mwhudson> Verterok: you could possibly think that it was something to do with the branch changing
[23:59] <beuno> Verterok, and, I'd also add this is only really useful for development