| GRiD | hello | 00:01 |
|---|---|---|
| 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:07 |
| poolie | hi grid | 00:14 |
| poolie | hi JoeJulian | 00:14 |
| poolie | that's interesting | 00:14 |
| poolie | wow that is very interesting | 00:15 |
| poolie | the double read is a bit interesting too | 00:15 |
| 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:16 |
| 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:27 |
| 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:30 |
| poolie | oh ok | 00:32 |
| poolie | which one? | 00:32 |
| 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:35 |
| poolie | that would be good to fix | 00:36 |
| poolie | oh i see your comment | 00:36 |
| 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:40 |
| poolie | right | 00:41 |
| lifeless | o/ | 00:46 |
| GRiD | hi lifeless :) | 00:47 |
| 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:58 |
| poolie | you could try doing an fsync in there and see if it helps | 00:59 |
| JoeJulian | poolie, will do. I've also opened a gluster bug. | 01:41 |
| jelmer | good morning Orlando :) | 12:56 |
| davi_ | jelmer, hi, is it fine to copy .bzr/repository/git (specially the idmap) between copies of the same repository? | 13:20 |
| 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:21 |
| 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:22 |
| jelmer | davi_: how's your attempts to use push going? | 13:24 |
| davi_ | jelmer, been working fine lately :) | 13:27 |
| 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:28 |
| jelmer | davi_: is that with actual push or some form of dpush? | 13:31 |
| davi_ | jelmer, push, well, bzr pull to be precise. | 13:33 |
| davi_ | i guess that's a slightly different code path | 13:33 |
| jelmer | it's indeed slightly different, but the hard bit (mapping between bzr and git) is shared between push and pull | 13:34 |
| === beuno is now known as beuno-lunch | ||
| === daveb_ is now known as croepha | ||
| === beuno-lunch is now known as beuno | ||
| 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 | 20:35 |
| === yofel_ is now known as yofel | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!