[00:48] lifeless: could you give me a quick http review https://code.launchpad.net/~mbp/bzr/198646-http-boundary-2.3/+merge/69440 [01:04] poolie: so does that transparently retry ? [01:05] yeah that's the bit around line 109 [01:05] will it be clear in .bzr.log that this happens? [01:06] (readv -> full read imposes quite a heavy network cost on big pack files / indices) [01:06] (both the re-read, and making 2 requests, and the original that gets thrown away using the downward pipe [01:07] there's a mutter statement [01:07] unconditionally [01:07] based on henrik's statement this will be somewhat intermittent [01:07] the one I can see doesn't say anything about retries [01:08] nb this isn't immediately going to read the whole thing [01:08] it's going to fall back to reading one range at a time, and only if that fails, the whole thing [01:09] ok [01:09] based on the description of the squid bug i think that will be enough [01:09] obviously it also somewhat sucks [01:09] oh, actually [01:09] _degrade_range_hint does explain what it's doing [01:16] thanks [01:40] poolie: no worries [01:40] its nice to get corner cases like this addressed [01:41] yeah, it's not really our bug but it's nasty when someone hits it === AfC is now known as AfC|run [07:20] Hi everybody! I've a question about Bazaar, if I want to create a branch to do some experimental stuff, I have to create a new directory with the new branch. The problem is that in Eclipse, I must create or reconfigure my project to work on this branch... [07:20] Is it possible to work on a new branch in the same directory and switch to an other when we want without changing directory ? [07:22] hi Merwin, yes, i recommend you use the bzr-colo plugin [07:23] poolie: looks exactly what I want, thank you ;) [07:24] it's really good [07:25] hi all [07:26] bzr: ERROR: exceptions.ImportError: cannot import name shlex_split_unicode [07:26] hi blackarchon, that's interesting [07:26] nothing else? [07:27] i got this when trying "bzr explorer" with bzr trunk and bzr-explorer trunk [07:27] sounds like a broken installation or something [07:27] i just installed them [07:27] which version? [07:28] oh, trunk [07:28] really, current trunk? [07:28] bzr-explorer is rev 527 [07:28] and bzr is rev 6046 [07:31] were they installed on this machine before? [07:31] yes, before there was bzr 2.3.3 and explorer 1.1.3 [07:32] could you please run 'bzr --version' and 'bzr plugins -v' and check it's fetching things from the directories you expect? [07:35] bzr --version: http://pastebin.com/87xu73UX [07:35] jelmer, hey you still around> [07:36] plugins -v: http://pastebin.com/TWEgDpn4 [07:36] ah i see, it's still using old explorer [07:36] great, remove that or point it at the correct one and you should be ok [07:38] ah thx, I renamed my plugins folder and it works now :) [07:39] you're welcome [07:42] another issue was that I had to use "python setup.py install build_ext --allow-python-fallback" to install bzr trunk [07:42] because otherwise I get an error: [07:42] building 'bzrlib._annotator_pyx' extension [07:42] gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -fPIC -I/usr/include/python2.6 -c bzrlib/_annotator_pyx.c -o build/temp.linux-i686-2.6/bzrlib/_annotator_pyx.o [07:43] cc1: error: bzrlib/_annotator_pyx.c: Der Wert ist zu groß für den definierten Datentyp [07:43] what's the matter with this one? [07:44] ! [07:45] nothing else? [07:45] Missing Python.h maybe? (wild guess) [07:45] Cannot build extension "bzrlib._annotator_pyx". Use "build_ext --allow-python-fallback" to use slower python implementations instead. [07:45] ok, now i'd guess maybe this used to be an amd64 machine and now it's 32 bit, or vice versa? [07:45] error: command 'gcc' failed with exit status 1 [07:46] any warnings before the error? [07:46] http://pastebin.com/YdQAdcyJ [07:46] this is all [07:49] it's a 32 bit debian squeeze [07:49] can you run it with LANG=en_US so i can see the exact english error [07:49] ok [07:49] no 64-bit parts anywhere? [07:50] the message is: Value too large for defined data type [07:51] it's a pure 32 bit debian [07:52] is it this: http://stackoverflow.com/questions/2438890/cc1plus-error-include-value-too-large-for-defined-data-type-when-compiling-wit/2496749#2496749 ? [07:52] ie it's on an exotic filesystem or something? [07:53] well it really IS on a smb mount - let me check this on a native ext3 file system [07:54] hooray for google [07:55] i would never expect the file system being responsible for such an error... [07:57] it's pretty cryptic [07:57] it would be nice if gcc at least gave a clue which operation was failing [08:02] really, this would be quite helpful [08:12] jelmer, you didn't fully remove all refs to lru_cache un dfulwich [08:38] jelmer, also there is this relevant bug: https://bugs.launchpad.net/bzr/+bug/743256 [08:38] Ubuntu bug 743256 in Bazaar Windows Installers "No way to install extra Python modules with stand-alone bzr installation on Windows" [High,Fix released] [08:49] /usr/local/lib/python2.6/dist-packages/bzrlib/plugins/explorer/lib/explorer.py:264: DeprecationWarning: bzrlib.config.GlobalConfig.get_editor was deprecated in version 2.4.0. result = self._user_config.get_editor() [08:49] :( [08:50] Noldorin: hi [08:50] blackarchon: that shouldn't be harmful [08:50] jelmer, what shouldn't? [08:50] blackarchon: the deprecation warning he is seeing [08:51] oh sorry [08:51] not to me [08:51] jelmer, hi [08:51] jelmer, so yes, i can actually include custom modules in standalone bzr now thanks to that :-) [08:51] did you see my brief bug report? [08:52] jelmer: ok :) [08:54] jelmer, 2nd problem now: the new dulwich does not define ThinPackData....the latest bzr-git requires it though :-S [08:54] in remote.py [08:55] spiv: good luck with future adventures [08:58] Noldorin: don't use dulwich trunk with a release of bzr-git [08:58] jelmer, i had to so that i could get --pure [08:59] or maybe i don't need that now? [08:59] I think --purge has been in a few releases now [08:59] *pure [09:01] jelmer, oh ok, never mind, working with the old dulwich now :-) [09:01] jelmer, just a note regarding your dulwich trunk and lru_cache btw...hope you got that [09:17] jelmer what does dulwich rely on for ssh? [09:23] Noldorin: you need to have an external ssh client installed [09:24] jelmer, will putty do? [09:24] jelmer, i think it's looking for standard openssh... [09:24] Noldorin: it has to be a command-line client, named ssh [09:24] yeah [09:24] putty ships "plink" which might work if you rename it to ssh.exe [09:27] jelmer, seems to yes...except it asks me whether to trust key...and stdin is redirected :-S [09:29] error: index-pack died of signal 11 [09:29] bzr: broken pipe [09:36] jelmer, well, let's discuss this tomorrow [09:36] you know the issue [09:36] thanks so fgar [09:36] good night [09:37] Noldorin: g'night [10:25] Riddell: thanks! :) === zyga_ is now known as zyga-x11 [12:52] Hi, I want to do "bzr switch -b newbranch" but create newbranch from a previous revision of current branch [12:52] Is -rREV the way to do it? [13:20] "bzr switch -rREV -b newbranch" didn't work, it created the new branch from current's branch tip [13:20] any ideas? [13:48] ok solved the problem by uncommiting the new branch to the revision I wanted [13:48] but isn't it a bug that "bzr switch -rREV -b newbranch" didnot work? [15:06] hi all [15:07] would this behavior: http://pastebin.ubuntu.com/654553/ possibly be the cause of launchpad not showing a diff for https://code.launchpad.net/~ubuntuone-control-tower/ubuntuone-installer/trunk? === beuno is now known as beuno-lunch === deryck is now known as deryck[lunch] === beuno-lunch is now known as beuno [17:16] hi jelmer [17:18] Is there any bzr command to remove backup file generated by "bzr revert"? [17:36] i'm looking to import / tag several releases of a piece of software from tarballs. my first stab was to look for something like svn_load_dirs, but bzr-equiv tools seem to all be deprecated. is there a canonical "right way" to do this? [17:36] hi dannf [17:36] dannf: it seems like what you want might be "bzr import" from the bzrtools plugin? [17:36] hey jelmer :) [17:37] * dannf read through the help... [17:38] huh - yeah, that might be all i need. kinda obvious in retrospect :) === deryck[lunch] is now known as deryck [17:56] why would a directory that I see on the web on launchpad do not show up in my local branch [17:57] I did both bzr update and bzr merge [17:57] both says its ok but the directory don't show up [17:57] it is a --stacked branch [17:58] santagada: perhaps you have local revisions that deleted the directory? [17:59] jelmer: no, I didn't even know it existed until today [18:00] jelmer: and bzr status says its clean [18:00] santagada: what did you do to merge the remote branch? [18:01] jelmer: I had some changes to two files before, which I didn't want to commit [18:01] jelmer: now I did bzr revert * and it is saying that my tree is out of date [18:01] santagada: bzr up should fix that [18:01] how the frack was it uptodate just before the rever [18:01] revert [18:02] and now it says it is out of date [18:02] makes no sense [18:02] jelmer: I tried bzr update, then tried bzr merge [18:02] santagada: is it a bound branch (created with "bzr co") or a normal branch? [18:03] between then I tried also bzr pull but I think it started pulling all history of the repo [18:03] jelmer: bzr branch --stacked [18:03] or bzr checkout --lightweight I dont remember [18:03] I learned to never ever use --lightweight or --stacked ever again after that, but this is an old tree [18:04] great now I think it is working, but it is downloading the whole tree just to trhow it out after the update [18:04] /tree/repo/ [18:07] santagada: it sounds like you had an empty branch before [18:08] jelmer: yep, but bzr did download 200mb, just to throw all out I think... who would ever ever whant that? [18:08] santagada: that's because of --stacked, which still is suboptimal for local branches [18:08] jelmer: --stacked and --lightweight are suboptimal period [18:09] I had like 20 problems with it... people that told me to use this think it is better because its faster [18:09] it is never faster [18:09] santagada: it depends on what you're doing [18:09] santagada: --lightweight for local branches works fine [18:10] if I didn't want to store revision data I could just delete .bzr [18:10] jelmer: bzr doesn't do hard/simbolic links like mercurial? [18:11] santagada: why hardlink if there is no need to have those files in the lightweight checkout at all? [18:11] there is also an option to hardlink [18:11] jelmer: because if I don't want to have history I could just delete the .bzr dir [18:12] santagada: see "bzr co --hardlink" [18:12] always re-downloading it is like the worst idea. it makes bzr seems awfully slow [18:13] now it downloaded 300mb and in the end I think I will have to do it again because It will probably throw the data out [18:14] santagada: that is more of an odd side-effect of using --stacked than a design decision [18:14] there are plans to allow --stacked (e.g. don't pull in remote data) but allow storing the data that has to be retrieved from the remote to be stored locally when we have to fetch it anyway. [18:14] jelmer: can I open a bug report for deprecating it, or do anyone think this is usefull? [18:15] santagada: stacking is very useful, just not the way you're using it [18:15] santagada: e.g. launchpad stacks by default if you push to it [18:15] so you only have to push 3 revisions if you push a new branch [18:15] if you committed only 3 changes [18:16] well mercurial and git do that and don't have --stacked [18:16] they also don't have 400mb repositories [18:16] santagada: git has stacking [18:16] santagada: it's just got a different name [18:17] jelmer: well by default when using github it just works [18:17] santagada: sure, but the same goes for Launchpad [18:18] no, I see even docs on bzr about using --lightweight [18:20] santagada: same thing - there are situations in which --lightweight is a bad idea [18:20] santagada: if there are places in the docs where we recommend the wrong thing, I think we should fix them [18:20] I see zero places where it is a good idea [18:21] either hardlink or deleting .bzr solves everycase I seen of --lightweight [18:21] santagada: it allows you to do a commit to a large tree without pulling down all the history, for example [18:21] jelmer: it does download all history [18:21] santagada: if it does, that's a bug [18:21] jelmer: or at least a large subset of it [18:22] I don't know, but a bzr update download 580mb of data seems like a bug to me [18:22] santagada: that does indeed sound like a bug [18:24] well I'm just give up trying to understand it, delete all repos that I have and do a simple branch [18:24] and continue using github for my stuff === santagad` is now known as santagada` === santagada` is now known as santagada_ === santagada_ is now known as santagada [18:41] hi Noldorin [18:44] hi jelmer, any updates on lp:gcc? [18:47] jelmer, hi :-) [18:47] jelmer, so i've set up things now, but am getting an error when i dpush: [18:47] h://git@github.com/alexreg/ircdotnet.git [18:47] jimis: sorry, nothing yet [18:47] jelmer, i think this is a git error [18:47] (using plink.exe btw) [18:48] Noldorin: what's the error? [18:48] jelmer, that's it [18:48] C:\Users\Alex\Documents\Visual Studio 2010\Projects\IRC.NET\0.4>bzr dpush git+ss [18:48] h://git@github.com/alexreg/ircdotnet.git [18:48] error: index-pack died of signal 11 [18:48] bzr: broken pipe [18:49] Noldorin: you might want to try with the very latest dulwich and bzr-git [18:49] jelmer, ok sure [18:49] will do [18:50] jelmer, the repos for bxr-git and dulwich are on LP and Github respectively right> [18:50] ? [18:51] Noldorin: yep [18:51] ok [18:51] jelmer, if i get this working i will right together a little blog post :-) [18:52] jelmer, then maybe you can just link future people to that [18:52] cool :) [19:03] jelmer, different error now: [19:03] error: unable to find fb1c6f6b77779fe32a31c04494b385bc53aac21f [19:03] fatal: object of unexpected type [19:03] bzr: ERROR: unpack index-pack abnormal exit [19:04] jelmer: please let me know if there is a bug I can subscribe to [19:05] I'm a GSOC student for gcc, and that affects my work :-s [19:06] jimis: there is a bug, let me find the # [19:06] bug 797915 [19:07] Launchpad bug 797915 in Launchpad itself "large bzr-svn imports failing" [Critical,In progress] https://launchpad.net/bugs/797915 [19:07] jimis: what's your project? [19:07] Noldorin: what's the branch you're trying to push? [19:07] Noldorin: I can give it a try on linux, that way we at least know if it's a problem specific to windows [19:08] thanks for the bug [19:08] jelmer, git+ssh://git@github.com/alexreg/ircdotnet.git [19:08] jelmer, sure [19:08] jelmer, i think i added you as a committer a long time ago already :-) [19:08] jelmer: GCC optimisation, see an outdated wiki page at: http://gcc.gnu.org/wiki/OptimisingGCC [19:11] Noldorin: but what branch are you trying to push? [19:11] jelmer, oh sorry. lp:ircdotnet/0.4 [19:11] jimis: I can do another one-off import if that helps [19:13] jelmer: it's just that patches I post need to be against current trunk, for now I manually download the files that have changed and that I need to produce the patch [19:14] thanks for the offer to help, I'll let you know when these files will be too many to handle manually :-) [19:21] jelmer, any luck? [19:31] jelmer, ? [19:38] Noldorin: sorry [19:38] Noldorin: got distracted by something else [19:38] Noldorin: I can reproduce it here [19:39] no prob [19:39] ok [19:39] interesting [19:40] jelmer, what should we try now then? [19:47] still looking [19:59] jelmer sure, just ping me :-) [20:22] jelmer getting closer to stability here! === yofel_ is now known as yofel [21:30] 333433333333/win 3 [21:36] jelmer, hey [21:36] jelmer, any updates? :-) [21:52] jelmer, around still? [23:58] is there a way/hack to revert a non-last revision without uncommitting the whole revision stack? [23:58] RenatoSilva, "revert a non-last revision" ? [23:59] are you missing a preposition there perhaps?