[00:01] <GRiD> hello
[00:07] <JoeJulian> When an upload pack is being generated, a read is done to the file while it's still open for writing, without attempting to flush the write. Is this a bug? On a networked filesystem, this seems to result in a short read: http://fpaste.org/ziBn/
[00:14] <poolie> hi grid
[00:14] <poolie> hi JoeJulian
[00:14] <poolie> that's interesting
[00:15] <poolie> wow that is very interesting
[00:15] <poolie> the double read is a bit interesting too
[00:16] <poolie> i don't know if it's illegal but it's certainly unusual for a unix filesystem to require some special action to read back a file that was just written
[00:27] <GRiD> poolie, is there someone in particular who looks after the btree_index code?
[00:27] <poolie> probably lifeless or jam know it best
[00:30] <GRiD> ok thanks. i'll talk to lifeless, then. trying to wrap up this bug i was (slowly) looking at. it's regarding the bzr search plugin too, which looks like he also wrote.
[00:32] <poolie> oh ok
[00:32] <poolie> which one?
[00:35] <GRiD> 720853
[00:35] <poolie> bug 720853
[00:35] <ubot5> Launchpad bug 720853 in bzr search plugin "bzr crashed with RuntimeError in normpath(): maximum recursion depth exceeded while calling a Python object" [High,Confirmed] https://launchpad.net/bugs/720853
[00:35] <GRiD> had a patch to solve the recursion, but i think it wasn't quite right and a test or two might have been failing. going to look again.
[00:36] <poolie> that would be good to fix
[00:36] <poolie> oh i see your comment
[00:40] <GRiD> i think it actually comes down to the bzr search plugin trying to index some data it shouldn't, and it's triggering a case in the index that's not caught right now when the key is too big.
[00:41] <poolie> right
[00:46] <lifeless> o/
[00:47] <GRiD> hi lifeless :)
[00:58] <poolie> JoeJulian, can you please file a bug?
[00:58] <poolie> it seems like a gluster bug but we can possibly work around it
[00:59] <poolie> you could try doing an fsync in there and see if it helps
[01:41] <JoeJulian> poolie, will do. I've also opened a gluster bug.
[12:56] <jelmer> good morning Orlando :)
[13:20] <davi_> jelmer, hi, is it fine to copy .bzr/repository/git (specially the idmap) between copies of the same repository?
[13:21] <jelmer> davi_: hi
[13:21] <jelmer> davi_: as long as the source repository has only a subset of the revisions of the target repository, that should be fine
[13:21] <davi_> jelmer, thanks
[13:21] <jelmer> davi_: it *should* also work if that is not the case, but I don't think that is very well tested. bug reports welcome
[13:22] <davi_> ok
[13:22] <jelmer> there is also a bug open about having bzr-git hook into bzr's fetch to automatically copy cache data when it's fetching revisions
[13:24] <jelmer> davi_: how's your attempts to use push going?
[13:27] <davi_> jelmer, been working fine lately :)
[13:28] <davi_> jelmer, there was one bug with pulling with fetch_tags, but i worked around it by pulling the revisions first and then pulling tags.
[13:31] <jelmer> davi_: is that with actual push or some form of dpush?
[13:33] <davi_> jelmer, push, well, bzr pull to be precise.
[13:33] <davi_> i guess that's a slightly different code path
[13:34] <jelmer> it's indeed slightly different, but the hard bit (mapping between bzr and git) is shared between push and pull
=== beuno is now known as beuno-lunch
=== daveb_ is now known as croepha
=== beuno-lunch is now known as beuno
[20:35] <maxb> bleh, bzr-gtk build failure on oneiric beta-ppa
[20:35] <maxb> The wonderful world of GNOME 3 migrations as applied to nautilus extensions
=== yofel_ is now known as yofel