| igc | lifeless: is finish_commit -> post_commit a tweak or a resubmit? | 00:00 |
|---|---|---|
| igc | lifeless: btw, I choose finish_commit to mirror the other mutabletree hook - start_commit | 00:00 |
| lifeless | igc: I can appreciate that; there is some room for cleanup here. I specifically want to reserve finish_commit for a hook that actually is part of the guts of commit | 00:00 |
| lifeless | as this hook isn't; it happens afterwards, I think post_commit is the right name | 00:01 |
| igc | lifeless: sure | 00:01 |
| lifeless | its a tweak, the rest of it looked fine with s/finish/post/ | 00:01 |
| lifeless | uhm | 00:01 |
| igc | this close to 2.0, I'm happy to resubmit | 00:02 |
| lifeless | you mimght like to consider getting the delta of the commit into the parameters object or something | 00:02 |
| igc | it will only take a minute to check my tweak | 00:02 |
| lifeless | but we can do that later | 00:02 |
| lifeless | igc: sure | 00:02 |
| lifeless | I'll look at it asap | 00:02 |
| lifeless | bbs, shower time | 00:02 |
| lifeless | also, I'm ~ done for the day - as per my mail a couple of days back, I have a half day leave today and all wed + thur | 00:03 |
| fullermd | igc: BTW, something occured to me in skimming past that hook merge... | 00:03 |
| fullermd | igc: What happens to my expanded keywords when I uncommit? | 00:04 |
| zsquareplusc | is there a visual (GUI) tool to inspect a repo? to quickly look at the different branches? | 00:04 |
| igc | fullermd: questions, questions ... I have no idea just yet | 00:05 |
| igc | zsquareplusc: qlog | 00:05 |
| fullermd | Well, I suspect the answer is 'nothing'. And it's probably not as big a deal, since uncommit most often will preceed either 'revert' or 'commit', both of which would update them to the appropriate reality. | 00:05 |
| igc | fullermd: I suspect that's the case | 00:06 |
| igc | fullermd: maybe a post_uncommit hook is needed too | 00:07 |
| fullermd | I get uncomfortable combinatoric hot flashes just thinking down that path, though :| | 00:07 |
| fullermd | Anyway. Just a thought to squirrel away. | 00:09 |
| fullermd | Keywords not updating on commit is a flat day-to-day deal-breaker. Keywords pointing off into hyperspace after uncommit is a weird corner case behavior that will hardly ever matter. | 00:10 |
| zsquareplusc | igc: thanks, that displays something :-) i'm not yet sure if the display is complicated or the cvsps conversion was strange (branch names look OK though) | 00:10 |
| wgrant | Should bzr not warn during a commit if the whoami doesn't look sane (eg. the default)? | 00:17 |
| lifeless | wgrant: the default is sane some of the time | 00:19 |
| lifeless | wgrant: it looks up user@mailname for instances | 00:19 |
| wgrant | lifeless: HAhahaha. | 00:19 |
| lifeless | but perhaps we should revisit this | 00:19 |
| wgrant | lifeless: And which normal desktops have the email address set proprely? | 00:19 |
| lifeless | A different population of users, I suspect | 00:20 |
| wgrant | lifeless: Most people don't realise they need to do it, and those commits sit around forever. | 00:20 |
| zsquareplusc | i used cvsps-import. is it save to just delete the unneeded branches it created or is that destroying the repositories integrity (or isn't it a repository at all?) | 00:26 |
| lifeless | zsquareplusc: delete what you don't want | 00:26 |
| zsquareplusc | ok. that looks good. glog shows the two branches and it makes sense what it shows :-) | 00:31 |
| zsquareplusc | how do i get those on launchpad? push each branch separately? or is there a more efficient way to upload the repository? | 00:33 |
| AfC | Well, that's interesting. Gentoo has bzr 1.18 now, and they've (re) hard masked bzr 2.0-rc1. So I'll be downgrading apparently (unless I intervene, of course, but this you-can't-upgrade bug in 2.0-rc1 seems pretty frightening). So should I be reverting to 1.18 now that it's released? | 02:03 |
| poolie | hi spiv | 02:04 |
| spiv | poolie: welcome to the other side (of the netsplit) | 02:05 |
| poolie | mm | 02:05 |
| poolie | presumably the other side will eventually evolve into marsupial megafauna or something :) | 02:05 |
| spiv | AfC: if you aren't using 2a repositories, there's no real difference. If you're using 2a, but not doing upgrades, then either should be ok I think, but 2.0-rc1 is probably a little better. | 02:07 |
| spiv | poolie: how far away is rc2? | 02:07 |
| poolie | good question, probably if your change is merged we should do it soon | 02:08 |
| AfC | spiv: well we were about to upgrade to 2a everywhere last week but then fortunately we saw Robert's warning and held off | 02:08 |
| spiv | AfC: phew! | 02:08 |
| AfC | spiv: apparently! | 02:08 |
| spiv | Hmm. Actually, you should avoid 2.0-rc1 if there's any likelihood of doing cross-format fetches between local branches. | 02:09 |
| spiv | Which would trip over the same bug as we saw in upgrade. | 02:10 |
| AfC | ok, well, in that case I'll let the version downgrade propagate. | 02:10 |
| AfC | thanks | 02:10 |
| spiv | Yeah. Better safe than sorry. | 02:10 |
| spiv | 2.0-rc2 should be strictly better than both 1.18 and 2.0-rc1, I hope :) | 02:11 |
| poolie | igc, i want to say that bug 385879 is not a blocker for 2.0 | 02:19 |
| ubottu | Launchpad bug 385879 in bzr/2.0 "EOL filter only applied to files when first checked out" [High,In progress] https://launchpad.net/bugs/385879 | 02:19 |
| poolie | though still appropriate to fix in that series | 02:19 |
| poolie | i suspect this will be just the first cut of several similar bugs and i don't want to block 2.0 on all of them | 02:20 |
| igc | poolie: I don't want to block shipping rc2 ... | 02:22 |
| igc | poolie: but I do want that patch reviewed and landed if it's all ok | 02:23 |
| poolie | yep | 02:23 |
| poolie | i'll read it before doing 2.0rc2 | 02:23 |
| poolie | but if we can't merge it with tweaks, i think we should do rc2 anyhow | 02:23 |
| poolie | then i'll do more on that bug | 02:23 |
| igc | please | 02:24 |
| poolie | igc, oh btw i didn't read your doc patch itself, just the cover letter | 02:26 |
| poolie | i saw you moved the developer guide | 02:27 |
| poolie | there was some kind of kludge where the source was stored separately from the destination, requiring it to be copied during the build | 02:27 |
| poolie | did you get rid of that ? it would be nice to | 02:27 |
| igc | poolie: np. lifeless pointed out some tweaks I want to do anyway so I'm 75% of the way through those, ... | 02:27 |
| igc | e.g. removing old cruft from the Makefile | 02:27 |
| igc | poolie: the doc build in the new Makefile I'm hacking on is very simple now | 02:28 |
| zsquareplusc | is it possible to create a new branch, containing only parts of an existing one? i.e. the entire CVS repository was converted and there are some sub-projects that now all shown in one big bzr branch. | 02:28 |
| poolie | igc :) | 02:29 |
| poolie | zsquareplusc: i think bzr-rebase can help you do this? | 02:30 |
| zsquareplusc | hm. maybe. it would be easiest if it was possible to just branch from a path. (bzr-svn can do that from svn repos, so that the new branch only contains files from the given path) | 02:35 |
| AfC | zsquareplusc: well, if you branch, then just quickly `bzr rm` everything you don't want, then you'll have a Branch that has just what you want in it. Or, you can start a fresh branch {shrug} All depends on whether you need to preserve history, I guess | 02:49 |
| Raim | zsquareplusc: see bzr split | 02:50 |
| poolie | spiv, what's the state of https://code.edge.launchpad.net/~spiv/bzr/insert-stream-check-references linked to bug 406687? | 03:06 |
| ubottu | Launchpad bug 406687 in bzr/2.0 "insert_stream doesn't check references are satisfied" [Critical,Fix committed] https://launchpad.net/bugs/406687 | 03:06 |
| poolie | is that an abandoned attempt? | 03:06 |
| spiv | Yeah. (It has some code that tries to reuse code from 'bzr check') | 03:07 |
| zsquareplusc | AfC: yep but in this case i'd like to have the history cleaned. Raim 's split seems to provide that. but the help output of the command is a bit terse. i'll try it later again. | 03:23 |
| AfC | zsquareplusc: Huh. I didn't know about `bzr split`. I wonder what it does. "This command will produce a target tree in a format that supports rich roots" doesn't seem much help. | 03:27 |
| poolie | spiv, ok, reading now, and noting in passing bug 426046 | 03:28 |
| ubottu | Launchpad bug 426046 in bzr "diff against remote branch does many vfs operations" [Medium,Confirmed] https://launchpad.net/bugs/426046 | 03:28 |
| fullermd | No, split just automates 'branch ; rm a bunch of stuff ; mv remaining stuff' | 03:29 |
| * igc lunch | 04:20 | |
| fullermd | vila_: 'morning. | 04:59 |
| === vila_ is now known as vila | ||
| * vila waves ;-) | 05:00 | |
| fullermd | Forgot to ask if you ran into any other problems getting that VM working right. I guess no serious ones, since you're apparently using it :) | 05:01 |
| poolie | hi vila, you're up early? | 05:01 |
| vila | I'm not really there in fact :-) I woke up an hour ago and was just passing around :) I may go back to sleep for another hour | 05:01 |
| fullermd | Also, I had a thought on that group permissions thing. Would it be Bad to just take out the condition and always chgrp it? Should be a noop on SysV FSen, and would save chaining if's when the next platform needing it comes around. | 05:02 |
| vila | I broke a coast biking last Friday so I wake up easily :-/ | 05:02 |
| vila | fullermd: I was thinking about checking the group explicitely instead of sys.platform (which is ugly) | 05:03 |
| vila | but yes, we shouldn't check platforms there | 05:03 |
| poolie | a coast? | 05:04 |
| poolie | fullermd: there may be some situations where files get a group you can't always set | 05:04 |
| poolie | also, this may cause delays over sftp | 05:05 |
| vila | hmm, that thing in the upper chest | 05:05 |
| poolie | rib | 05:05 |
| poolie | ouch | 05:05 |
| vila | poolie: it's only in tests not in code | 05:05 |
| vila | rib yes ! | 05:05 |
| vila | not really broken but I don't know how that is said, and it hurts only when I laugh, cough or try to turn in my bed :-) | 05:06 |
| fullermd | It WAS comforting to see that all the test failures fixes involved fixing _tests_, not _code_ ;) | 05:06 |
| vila | hehe, that's why we are so happy when we see test failures | 05:06 |
| timClicks | hi all, how do I change the branch that bzr push is saved to? | 05:07 |
| vila | timClicks: bzr push --remember <new_url> | 05:08 |
| timClicks | vila: thanks :) | 05:08 |
| poolie | i think the muscle is called the intercostal in english/latin | 05:09 |
| fullermd | "Hey! My intercostal clavicle!" | 05:09 |
| fullermd | (what a great film...) | 05:10 |
| timClicks | vila: works perfectly, thanks for the prompt reply! | 05:10 |
| vila | c\^ote is th French word for both coast and rib | 05:10 |
| vila | timClicks: always happt to help (tm) :-) | 05:11 |
| vila | timClicks: always happy to help (tm) :-) | 05:11 |
| vila | fullermd: that's clavicule for you (not pointing any typo of course, not me ) | 05:11 |
| jml | not canicule, which is something completely different | 05:12 |
| vila | much more enjoyable when you're in that kind of hotness | 05:13 |
| jml | (I learnt that word on a day in Paris where it was 35 degrees!) | 05:13 |
| poolie | > Côte-Rôtie can be rendered in English as "the roasted slope" or "the burning coast" and refers to the long hours of sunlight that these steep slopes receive. | 05:13 |
| fullermd | Oh, I'm pretty sure it's always 'clavicle' anatomically, whether human or brontosaur. | 05:14 |
| vila | poolie: perfect timing to surd on jml joke, I'm impressed :) | 05:14 |
| poolie | mm :) | 05:14 |
| vila | s/surd/surf/ | 05:14 |
| jml | heh | 05:14 |
| jml | I was wondering what irrational square roots had to do with dog days on the coast :) | 05:14 |
| vila | ohhh, clavicle.... one more French word in English | 05:14 |
| poolie | spiv, i'm back to your patch, going to send soon | 05:15 |
| vila | go on go on... you won't make me laugh | 05:15 |
| poolie | oh how mean :) | 05:15 |
| poolie | i have some tweaks but i think we can merge it today | 05:16 |
| * fullermd delves into his quote file. | 05:16 | |
| fullermd | ``We don't just borrow words; on occasion, English has pursued other languages down alleyways to beat them unconscious and rifle their pockets for new vocabulary.'' | 05:16 |
| jml | vila, actually, it's not a French word in English. | 05:16 |
| jml | vila, it's a Latin word in French and English. | 05:17 |
| jml | vila, from 'clavicula', arrived in English in the 17th century. | 05:17 |
| fullermd | I'm pretty sure it got to English via [Middle] French, though, not via direct transplant. | 05:17 |
| vila | jml: Pff, leave us some please | 05:17 |
| vila | :) | 05:17 |
| * mwhudson lofts the issue of -ise vs -ize and runs away, terribly fast | 05:18 | |
| * fullermd thinks that just emphasizes the color of the issue. | 05:18 | |
| * jml throws a copy of Fowler's at mwhudson | 05:18 | |
| jml | fullermd, the OED says otherwise | 05:19 |
| * vila ouch, laughing hurts | 05:19 | |
| fullermd | Pfft. OED can be changed; it's not cast out of aluminum. | 05:19 |
| jml | haha | 05:19 |
| poolie | spiv https://code.edge.launchpad.net/~spiv/bzr/insert-stream-check-chks-part-2/+merge/11290 review done | 05:21 |
| spiv | poolie: btw, when are you going to disable the [ascii] tests that PQM runs? | 06:53 |
| poolie | spiv, i thought it was done in trunk | 06:57 |
| poolie | i wasn't going to do it soon for 2.0 | 06:57 |
| poolie | just out of general risk aversion | 06:57 |
| poolie | vila, what's the overall story on shell | 07:05 |
| poolie | shell-like tests now? did they merge? | 07:05 |
| vila | poolie: waiting for review :-) | 07:06 |
| vila | spiv: I think they have been disabled and pqm *is* faster now | 07:06 |
| vila | ha, hmm, yeah, trunk :-) | 07:07 |
| poolie | boring old trunk :) | 07:07 |
| poolie | igc, re bug 402623, it sounds like jam has a good handle on it | 07:07 |
| ubottu | Launchpad bug 402623 in bzr ".cix thrashing causes us to re-download the whole index multiple times" [Critical,Triaged] https://launchpad.net/bugs/402623 | 07:07 |
| poolie | would it be better to reassign it back to him? | 07:07 |
| igc | poolie: how busy is he? | 07:08 |
| vila | spiv: nudge https://code.edge.launchpad.net/~vila/bzr/controversial/+merge/11295 should be trivial now | 07:08 |
| vila | and hi all, here for good now :) | 07:08 |
| igc | poolie: I'm knee deep pulling the windows installer out of the core and enhacing it right now | 07:09 |
| poolie | mm, that's what i thought | 07:09 |
| igc | poolie: I'm happy to do other stuff but getting this out will allow multiple people to work on it | 07:09 |
| poolie | therefore probably not active on that patch at the moment | 07:09 |
| poolie | i'm not asking you to switch back to this, just the contrary | 07:09 |
| poolie | i was just looking at the non-2.0 critical list | 07:09 |
| igc | poolie: not today | 07:10 |
| igc | poolie: though my list for today did include looking over jam's reply | 07:10 |
| poolie | k | 07:10 |
| poolie | he seems to outline a patch for it, it might be simpler to let him just actually write it | 07:10 |
| igc | poolie: no complaints from me! | 07:11 |
| igc | poolie: my personal focus today is anything core related: doc patch, post-commit hook, content-filtering follow-up if any | 07:11 |
| poolie | cool | 07:12 |
| igc | poolie: so I'm waiting on a review of cf and doc patch | 07:12 |
| poolie | ok | 07:12 |
| poolie | i'm doing the doc one now | 07:12 |
| poolie | i'll read your cf patches and then maybe look for more cf things myself, you never know | 07:12 |
| igc | and working on getting the installer out of the core while I'm waiting | 07:12 |
| igc | poolie: so my thinking wrt cf is that that particular patch ought to get it 'working in the common cases' | 07:13 |
| igc | which is good enough for 2.0 - other fixes can come later | 07:13 |
| igc | bzr-keywords needs to use that new hook that landed this morning but, again, that can come post rc2 | 07:14 |
| poolie | sounds good to me | 07:17 |
| poolie | wow that's a huge patch? | 07:18 |
| poolie | s/?// | 07:18 |
| poolie | also you get some kind of distinction for writing batch files, if you did :) | 07:18 |
| spiv | vila: ta, yes. | 07:19 |
| vila | spiv: ok for landing then ? | 07:19 |
| poolie | ok commented on the docs patch | 07:20 |
| KhaZ | Hello! I'm trying to figure out how best to integrate my bzr depots into my rsnapshot backups. My first inclination is to simply bzr init a repo on the backup drive for every repo I want, and then simply 'pull' every hour/night/period. Is this what's normally done? | 07:22 |
| KhaZ | Furthermore: if that is the preferred way; is there a better storage type to use to maximize rsnapshot's hardlinking facilities? (i.e., something that keeps deltas in separate files, so I don't have X copies of non-changing data around?) | 07:26 |
| poolie | KhaZ: a recent pack-based format will come fairly close to that behaviour | 07:28 |
| poolie | that sounds reasonable | 07:28 |
| spiv | poolie: pushing tweaks now, about to submit to PQM for 2.0 | 07:28 |
| poolie | though maybe you'd rather backup the whole directory, including working trees, from your workstation/laptop? | 07:28 |
| poolie | that's what i do | 07:28 |
| poolie | woo spiv | 07:28 |
| spiv | vila: so the full test suite should pass now on FreeBSD? | 07:31 |
| spiv | vila: that's pretty neat! | 07:31 |
| vila | spiv: yes, at least on my FreeBSD vm, I'm waiting confirmation from fullermd but that will be easier with both patches landed | 07:32 |
| spiv | vila: was it just test suite bugs, or were there real bugs too? | 07:33 |
| vila | only test bugs | 07:34 |
| poolie | igc, i guess https://code.edge.launchpad.net/~ian-clatworthy/bzr/pdf-chm-docs-for-2.0/+merge/11182 is needed as well as doc-per-site-language? | 07:42 |
| poolie | they look like they overlap a bit? | 07:42 |
| igc | poolie: doc-site-per-language is a superset of the other | 07:43 |
| poolie | so i might mark it superseded then | 07:43 |
| igc | poolie: I left the other one there because it was the barest minimum required | 07:43 |
| igc | sure | 07:43 |
| fullermd | spiv: I think vila's not seeing the weird errors with revisions disappearing that I do. It may be py2.6 related, though I'm sure I've reproduced it on 2.5 in the past. | 07:47 |
| fullermd | Probably be a while before I can try out the changes; I haven't gone to 2a yet, probably won't have time 'till later this week at least. | 07:48 |
| vila | fullermd: oh, do you have the loom plugin installed ? | 07:48 |
| fullermd | Nyet. | 07:48 |
| vila | any othe plugin ? | 07:48 |
| vila | any other plugin ? | 07:48 |
| fullermd | Several, but I ran the tests with --no-plugins. | 07:49 |
| vila | ok | 07:49 |
| fullermd | After I do the 2a switch and catch up, I'll see if I can get a run in on both systems (amd64/8.x/py26 and i386/7.x/py25. That should nicely isolate the root of the problem :P) | 07:54 |
| vila | 8.x ? | 07:55 |
| fullermd | OS version. | 07:56 |
| vila | Is that released ? | 07:56 |
| fullermd | Who needs releases when you have CVS/SVN? :p | 07:56 |
| vila | :-) | 07:56 |
| vila | Ok, wrong question, same player tries again, | 07:57 |
| fullermd | It's actually branched though, so next update I'll be on 9.x. | 07:57 |
| vila | Should I setup my slave with 8.x instead of 7.2 ? | 07:57 |
| fullermd | Well, if 8 were out, maybe. It's on beta... beta4, I think? | 07:57 |
| fullermd | I doubt it would matter for the purposes of testing bzr. | 07:57 |
| vila | But which one is considered stable or is the most used ? | 07:58 |
| vila | ha, sry, missed that line | 07:59 |
| vila | so 8 is not out, ok, let me know when it is then :) | 07:59 |
| fullermd | 7 at this point, probably. 6 is fading out, 5 and earlier are probably dead outside of special cases. | 07:59 |
| fullermd | Last schedule update suggests ~end of the month. It'll probably slip, like schedules always do. | 08:00 |
| fullermd | ('course, it'll probably be announced without a Windows installer available ;> | 08:00 |
| vila | pff, those lazy packagers.... | 08:03 |
| bialix | good day gentlemen | 08:05 |
| * fullermd waves at bialix. | 08:05 | |
| * vila waves | 08:06 | |
| * bialix waves back | 08:06 | |
| vila | . o O (waves lead to tsunami...) | 08:06 |
| bialix | :-D | 08:06 |
| fullermd | That's OK, I'm a hundred miles or so inland. | 08:07 |
| vila | same here ;) | 08:07 |
| bialix | what's wrong with windows installer again? | 08:07 |
| vila | bialix: ?? | 08:09 |
| bialix | [10:00]<fullermd>('course, it'll probably be announced without a Windows installer available ;> | 08:09 |
| fullermd | Excess therbligs. | 08:09 |
| vila | bialix: Ooooh you mean the FreeBDS installers ? :-D | 08:10 |
| vila | BSD even | 08:10 |
| bialix | therbligs? | 08:10 |
| bialix | oh. I see | 08:11 |
| fullermd | Well, I was being a little facetious. | 08:11 |
| fullermd | (but 'excess therbligs' DOES seem to be a problem with making it, so...) | 08:11 |
| bialix | yes, you do | 08:11 |
| igc | hi bialix | 08:14 |
| bialix | hi igc | 08:15 |
| bialix | igc: ru-chm content is so small for some special reason? | 08:15 |
| igc | bialix: I alomst have the win32 installer stuff out of core btw | 08:15 |
| bialix | igc: cool | 08:15 |
| bialix | igc: why you want 2.6? | 08:15 |
| igc | bialix: if I publish the project, are you able to test it at all? I'm still get c compilers installed, etc on vista | 08:16 |
| igc | bialix: just felt I ought to ask re 2.5 vs 2.6 | 08:16 |
| bialix | I still use 2.5 because 2.6 is the whole new thing | 08:17 |
| bialix | poolie said there is something faster with 2.6. I dunno what exactly but I think it should be measured on win32 separately | 08:18 |
| spiv | poolie: oh, drat, it failed pqm. There's a test that tries to create a broken repo as part of the fixture that now fails at commit_write_group time... | 08:18 |
| bialix | igc: publish the project? I think I can try it | 08:19 |
| spiv | poolie: fixing now | 08:20 |
| spiv | (by skipping the test in that case) | 08:21 |
| === BjornT_ is now known as BjornT | ||
| spiv | I guess it's extra proof that the code works.. | 08:28 |
| spiv | Hmm. | 08:33 |
| spiv | I wonder if this last failure is actually a real bug or not... | 08:33 |
| spiv | It sure looks like a real bug uncovered by this patch... | 08:38 |
| igc | bialix: https://code.edge.launchpad.net/~bzr/bzr-windows-installers/trunk | 08:42 |
| igc | bialix: some questions ... | 08:43 |
| igc | 1. does the Makefile look ok? | 08:43 |
| igc | 2. What inside tools/win32 needs to remain in the bzr core project? | 08:43 |
| igc | I'm guessing most of it is redundant with this stuff pulled out? | 08:44 |
| === JaredWigmore is now known as JaredW | ||
| tonyyarusso | Say, I'm getting the following message and I'm not sure what it means: 'No handlers could be found for logger "bzr"' | 08:48 |
| spiv | tonyyarusso: where are you seeing that? | 08:50 |
| spiv | In a program that imports bzrlib, or from the "bzr" command-line tool itself? | 08:50 |
| tonyyarusso | spiv: 'bzr' itself | 08:50 |
| spiv | That's pretty weird. | 08:50 |
| spiv | Are you using any plugins? | 08:50 |
| tonyyarusso | Not that I'm aware of? I just started using it. | 08:51 |
| spiv | What command are you running? | 08:51 |
| spiv | It's a harmless message, but you shouldn't be getting it. | 08:51 |
| tonyyarusso | init, add, I think commit did it | 08:51 |
| spiv | Also, what version of bzr? | 08:51 |
| tonyyarusso | 1.3.1 | 08:51 |
| spiv | Hmm. That's pretty old. Possibly this is something that's fixed in a newer version. | 08:52 |
| tonyyarusso | Wait a sec, I think I found something relevant | 08:52 |
| tonyyarusso | Yup | 08:53 |
| tonyyarusso | For some reason my .bzr.log was owned by root | 08:54 |
| tonyyarusso | which apparently confuses it | 08:54 |
| spiv | Oh, right. I do remember something about that bug. | 08:56 |
| spiv | I'm not sure if that got fixed since 1.3.1. | 08:56 |
| tonyyarusso | meh, either way, as long as I know nothing's going to explode I can go to bed ;) | 08:57 |
| bialix | igc: tools/win32/ostools.py used by main Makefile | 08:58 |
| bialix | igc: sorry, I'm a bit busy right now, will look shortly | 08:59 |
| igc | bialix: np | 08:59 |
| spiv | poolie: Hah, yes, this patch did find a real bug. | 09:04 |
| spiv | poolie: Although not really an important one. The "push inventory-deltas to server without RPC that supports inventory-deltas" case had a subtle bug; it wasn't doing target_repo.refresh_data between stopping the RPC insert and falling back to the VFS insert. | 09:07 |
| spiv | So the new paranoia erroneously believed a text was missing in some cases (depending on autopacking, I think). | 09:08 |
| bialix | igc: about new Makefile: there is no docs bundled into installer? | 09:08 |
| igc | bialix: the intention is to bundle the new chm files | 09:08 |
| bialix | and? | 09:09 |
| igc | bialix: possibly by pulling them from the downloads area on doc.bazaar-vcs.org | 09:09 |
| bialix | ok, so bzr.iss should be updated | 09:09 |
| igc | and probably the buildout.cfg file as well | 09:09 |
| * bialix real prefer scons for complex builds | 09:09 | |
| spiv | poolie: resending now. | 09:10 |
| bialix | igc: I think bzr.iss.cog should be retired and special python script just used to generate the bzr.iss | 09:11 |
| bialix | but maybe post 2.0 | 09:12 |
| bialix | igc: how you expect to marry this separated project with bzr.dev at build time? | 09:19 |
| igc | buildout.cfg grabs the bzr code from lp | 09:20 |
| igc | bialix: ^^ | 09:20 |
| bialix | igc: ok re-phrase queston: you're using Makefile in the same position like in bzr.dev Makefile | 09:21 |
| bialix | so they will clash | 09:22 |
| igc | bialix: ah ok - I guess the Makefile for this project needs to delegate down to build-win32/Makefile or something like that? | 09:23 |
| bialix | delegate down? | 09:24 |
| Lo-lan-do | G'day all | 09:26 |
| === Ng_ is now known as Ng | ||
| Lo-lan-do | I'd like to help getting dulwich/bzr-git working (with bzr-receive-pack and bzr-upload-pack). | 09:28 |
| Lo-lan-do | I guess I'll be poking the usual suspects, aka jelmer, james_w and Jc2k (if memory serves) :-) | 09:28 |
| bialix | igc: may be you need to start from the desired layout of components at build time? | 09:29 |
| bialix | igc: I'd prefer to have bzr.dev and win32 tools in separate directories | 09:29 |
| igc | bialix: I need to have dinner now and spend some time with the kids | 09:35 |
| igc | bbl | 09:35 |
| bialix | kk | 09:35 |
| === bialix is now known as bialix-afk | ||
| igc | bialix: I've emailed bzr-windows with some brief details on the new project so hopefully a few people can help me pull this together | 09:35 |
| * igc dinner | 09:36 | |
| Lo-lan-do | jelmer: I've gotten to the point where I can "git clone" a bzr branch, with a small patch in bzr-git, see http://pastebin.com/f4e3d0434 | 10:09 |
| Lo-lan-do | Can't fetch or pull or push yet, but I'm on it :-) | 10:09 |
| jelmer__ | Lo-lan-do: cool :-) | 10:09 |
| Lo-lan-do | My test setup is "described" at http://pastebin.com/f14c3c80d | 10:11 |
| Lo-lan-do | Stuff between the ----- lines is done as guest, the rest as myself | 10:11 |
| Lo-lan-do | (guest being a trashable account, completely emptied from time to time) | 10:11 |
| Lo-lan-do | jelmer: Can I also bother you with dulwich, or is that more james_w's turf? | 10:14 |
| jelmer__ | Lo-lan-do: no, dulwich is fine too | 10:14 |
| Lo-lan-do | Okay :-) | 10:14 |
| Lo-lan-do | Oh, by the way, I believe the patch is incomplete, there are probably other places in bzr-git where the branch location is interpreted as a transport. I just haven't faced them yet. | 10:16 |
| Lo-lan-do | As for dulwich, there are several places where progress() is called with informative messages. These messages are unfortunately sent on the wire, and for some reason they don't conform to the git protocol so the client barfs on receiving them. | 10:19 |
| jelmer__ | Lo-lan-do: I think the intention was actually to use a transport there | 10:19 |
| jelmer__ | rather than a path | 10:19 |
| Lo-lan-do | Maybe. But my short-sighted patch makes it work :-) | 10:21 |
| Lo-lan-do | Example for dulwich: http://pastebin.com/f4adf44d1 | 10:21 |
| lifeless | jelmer__: ji | 10:22 |
| jelmer__ | lifeless: ji! | 10:24 |
| Lo-lan-do | Ni? | 10:25 |
| jelmer__ | Lo-lan-do: hmm, is that a recent change? I'm pretty sure that progress reporting worked in the past | 10:25 |
| Lo-lan-do | jelmer__: No idea. I've neglected this bzr-git stuff for too long. | 10:26 |
| lifeless | jelmer__: so, subunit. | 10:28 |
| lifeless | jelmer__: I want to release 0.0.2; your perl diff is incomplete. | 10:28 |
| lifeless | jelmer__: ~ a week+ ago you said a few days :P | 10:28 |
| lifeless | jelmer__: I'm here to nah | 10:29 |
| lifeless | *nag* | 10:29 |
| Lo-lan-do | Aehm. It appears my git client doesn't like sideband stuff… | 10:31 |
| Lo-lan-do | Or maybe it doesn't like that the server doesn't announce it. | 10:32 |
| Lo-lan-do | Or maybe I suck, since the server does announce it. | 10:35 |
| jelmer__ | lifeless: sorry about that | 10:41 |
| jelmer__ | lifeless: I took some time to look into it two days ago but I ended up fighting with automake | 10:41 |
| lifeless | jelmer__: I can help, but you need to point me in the right direction :) | 10:41 |
| jelmer__ | lifeless: automake doesn't have a way to install perl stuff by itself, so we have to call out to a perl makefile | 10:42 |
| jelmer__ | That Makefile can be generated by running perl/Makefile.PL | 10:43 |
| jelmer__ | but I can't figure out a way to get automake to trigger that rebuild before recursing down into the perl subdir | 10:43 |
| lifeless | so, you need configure to run perl/Makefile.PL | 10:45 |
| lifeless | or you need make to | 10:45 |
| lifeless | uhm | 10:45 |
| lifeless | put . into SUBDIRS | 10:46 |
| lifeless | in /Makefile.am | 10:46 |
| lifeless | SUBDIRS = . perl | 10:46 |
| lifeless | perl/Makefile: | 10:47 |
| lifeless | $(PERL) $@ | 10:47 |
| lifeless | or whatever | 10:47 |
| lifeless | in fact | 10:48 |
| lifeless | perl/Makefile: perl/Makefile.PL | 10:48 |
| lifeless | $(PERL) $@ | 10:48 |
| jelmer__ | lifeless: that doesn't work, it recurses before making perl/Makefile | 10:49 |
| lifeless | no | 10:50 |
| lifeless | thats what SUBDIRS = . perl | 10:50 |
| lifeless | is for | 10:50 |
| lifeless | you'll need one more target to tell it that it needs perl/Makefile to recurse | 10:50 |
| jelmer__ | lifeless: how do I tell it that? | 10:52 |
| lifeless | add | 10:52 |
| lifeless | $(RECURSIVE_TARGETS): perl/Makefile.PL | 10:53 |
| jelmer__ | just that? | 10:54 |
| lifeless | yes | 10:54 |
| lifeless | no rule | 10:54 |
| lifeless | or you will replace the big rule for recursive targets | 10:54 |
| jelmer__ | complains about a undefined user variable | 10:54 |
| lifeless | automake does? | 10:54 |
| jelmer__ | yes | 10:55 |
| lifeless | add distclean-local: | 10:55 |
| lifeless | -rm perl/Makefile | 10:55 |
| lifeless | while we are here | 10:56 |
| lifeless | can you pastebin your patcfh ? | 10:56 |
| lifeless | also, #subunit might be more appropriate at this point :O | 10:56 |
| jelmer__ | lifeless: I'm there (-: | 10:56 |
| lifeless | not on my server ;P | 10:57 |
| jelmer__ | http://pastebin.com/m2ec94176 | 10:57 |
| lifeless | jelmer__: as in, I can't see you in #subunit | 10:58 |
| jelmer__ | hmm, that's odd | 10:58 |
| lifeless | it had lost me | 11:01 |
| jelmer__ | lifeless: merge req submitted | 11:31 |
| lifeless | sweet | 11:32 |
| === bialix-afk is now known as bialix | ||
| vila | AfC: ping | 12:04 |
| spiv | lifeless: you'll be happy to know that the full check references patch has already found a (minor) bug | 12:04 |
| Kinnison | a "leak" ? | 12:05 |
| spiv | lifeless: (the fallback-to-vfs case in the hpss client for streaming inventory-deltas was missing a repo.refresh_data(), so the repo object didn't realise it had all the keys that it should have) | 12:06 |
| spiv | Hmm, PQM still rejected it. Oh, another test that wants to create damaged repositories. Hmm. | 12:16 |
| lifeless | spiv: you may enjoy ec2test and other massively parallel testing tools | 12:25 |
| vila | spiv: ... which PQM is not :-P | 12:28 |
| igc | night all | 12:29 |
| spiv | lifeless, vila: :P | 12:33 |
| === Pilky_ is now known as Pilky | ||
| AfC | vila: pong | 12:49 |
| vila | AfC: I was searching how to take the bazaar overlay into account, I just found package.keywords... | 12:49 |
| vila | AfC: I still have a question though | 12:50 |
| vila | I only added '=dev-util/bzr-1.18', but is there a way to say: 'accept all from that overlay' ? | 12:50 |
| vila | AfC: May be the question should have been, how do *you* proceed and what bzr version are you using ? | 12:54 |
| vila | AfC: still there ? | 12:58 |
| AfC | vila: ... "bazaar overlay" ... what's that? | 13:01 |
| vila | https://edge.launchpad.net/bzr-gentoo-overlay | 13:02 |
| vila | it seems that gentoo has bzr-1.15, this overlay has 1.18 (I need >= 1.16) | 13:02 |
| AfC | vila: if you mean someone's contrived unofficial Portage tree, then all I have to say is this: overlays are like PPAs, but worse: broken, unsupported, and usually unmaintained. | 13:02 |
| vila | ha :-/ | 13:03 |
| vila | So what do you use ? | 13:03 |
| AfC | vila: (and, still on that topic:) you run into SERIOUS hell if you find yourself needing to use packages from one person's overlay & another person's overlay. They will NOT mix. | 13:03 |
| AfC | vila: this is, frankly, just another variation of the plugin anti-pattern | 13:04 |
| AfC | vila: but anyway; it's enough to say that I work very hard to encourage Gentoo developers to get on with getting their work into Portage where they're supposed to be working; if it's broken, that's what package.mask is for. And if it's unstable, that's what ~arch is for. | 13:04 |
| AfC | vila: that's the way Gentoo was founded, but a lot of them lost the plot along the way. | 13:05 |
| AfC | anyway, back to point | 13:05 |
| vila | meh, speak slowly :) package.mask ? ~arch ? | 13:05 |
| AfC | Gentoo currently seems to have 1.15 as stable (which is largely meaningless, it merely means some combination of "no serious bugs in > 30 days" + "some developer has gotten around to marking it arch from ~arch". | 13:06 |
| AfC | Waiting on the latter is usually what the hold up is | 13:06 |
| AfC | Gentoo has 1.18 in ~arch | 13:06 |
| vila | aaah | 13:06 |
| AfC | Gentoo did have 2.0-rc1 in ~arch, but this has been "package.masked" | 13:06 |
| vila | And can I activate that for my host without any overlay ? | 13:07 |
| AfC | vila: you up & running with a Gentoo system right now? | 13:07 |
| AfC | vila: yes | 13:07 |
| vila | yes | 13:07 |
| AfC | vila: tip: install app-portage/eix | 13:07 |
| vila | so first I should remove that overlay right ? | 13:07 |
| AfC | vila: and use it's `eix-sync` to do `emerge --sync`. eix is a lovely little package search engine | 13:07 |
| AfC | vila: yes | 13:07 |
| AfC | vila: it is sometimes worth having your *own* private overlay at (say) /usr/local/portage but there's rarely if every payoff to using some developer's private tree. | 13:08 |
| vila | AfC: emergeing eix | 13:09 |
| vila | done | 13:09 |
| AfC | vila: just this once, do `update-eix` | 13:10 |
| vila | eix-sync in progress :-/ | 13:10 |
| AfC | ah | 13:10 |
| AfC | well, it'll do it for you, then | 13:10 |
| AfC | so, back to basics: | 13:11 |
| vila | it said running eix-update | 13:11 |
| AfC | package.mask is a file in /usr/portage/profiles which lists packages that are in the tree, but which will be blocked unless you go to some length to unblock them | 13:11 |
| vila | err, I can't read my messages, nor any other for that matter | 13:13 |
| vila | wow, back | 13:13 |
| vila | /portage/profies ! That was the needle I couldn't find, ok, so I can see bzr-2.0rc1 in package.mask there | 13:14 |
| AfC | That file is maintained as a part of the portage tree; it allows them to introduce (say) the next GNOME stack without suddenly pushing | 13:14 |
| AfC | it a bit at a time | 13:14 |
| AfC | vila: second concept: | 13:15 |
| AfC | arch and ~arch | 13:15 |
| AfC | vila: pull up... oh, say /usr/portage/dev-util/bzr/bzr-1.15.1.ebuild in less or view or gedit or whatever. | 13:15 |
| === Pilky_ is now known as Pilky | ||
| AfC | vila: and look half a page down at the KEYWORDS= line | 13:16 |
| vila | oook (compared 1.15 and 1.18) | 13:16 |
| AfC | [for all you in the audience playing along at home, looking on awestruck and shaking your heads at this craziness, that line in the 1.15.1 ebuild says: | 13:16 |
| AfC | KEYWORDS="amd64 ~ia64 ppc sparc x86 ~x86-fbsd" | 13:16 |
| AfC | whereas, if we look at the one in the /usr/portage/dev-util/bzr/bzr-1.18.ebuild file, we see | 13:17 |
| vila | 1.18 says: KEYWORDS="~amd64 ~ia64 ~ppc ~sparc ~x86 ~x86-fbsd" | 13:17 |
| AfC | what vila just said :)] | 13:17 |
| AfC | so on both amd64 and x86, | 13:18 |
| vila | AfC: just showing I'm following :) | 13:18 |
| AfC | we have 1.15.1 "stable" (colloquially known as arch) whereas we have 1.18 "unstable" aka testing (known as ~arch) | 13:18 |
| AfC | vila: now | 13:18 |
| AfC | vila: last detail | 13:18 |
| AfC | vila: you can tweak things individually by creating a file called | 13:18 |
| AfC | /etc/portage/package.keywords | 13:19 |
| AfC | and appending the line | 13:19 |
| AfC | dev-util/bzr | 13:19 |
| AfC | to it | 13:19 |
| AfC | or, say | 13:19 |
| AfC | >=dev-util/bzr-1.18 | 13:19 |
| AfC | [you used to have to say | 13:19 |
| AfC | >=dev-util/bzr-1.18 ~x86 | 13:19 |
| AfC | or, say | 13:19 |
| AfC | dev-util/bzr ~x86 | 13:19 |
| AfC | which actually makes a bit more sense | 13:20 |
| AfC | but one day I noticed by accident that it worked without that. It may be a Portage 2.2 thing | 13:20 |
| AfC | er, portage-2.2 :| | 13:20 |
| vila | I understand '=dev-util/bzr-1.18' but the others ? | 13:20 |
| AfC | right, | 13:20 |
| AfC | so | 13:20 |
| AfC | you don't need to explicitly list a version if you don't want to | 13:20 |
| AfC | ie | 13:20 |
| AfC | if you are willing to accept the unstable "~arch" ebuild of bzr | 13:21 |
| AfC | (which is *entirely* appropriate for you and I since you and I participate here in upstream) | 13:22 |
| AfC | then you can just put | 13:22 |
| vila | I can play with 'equery list -i -p bzr' now | 13:22 |
| AfC | dev-util/bzr | 13:22 |
| AfC | instead of | 13:22 |
| AfC | =dev-util/bzr-1.18 | 13:22 |
| AfC | or | 13:22 |
| AfC | >=dev-util/bzr-1.18 | 13:22 |
| AfC | or | 13:22 |
| AfC | =dev-util/bzr-1.18* | 13:22 |
| AfC | or whatever | 13:22 |
| AfC | vila: even simpler, | 13:23 |
| AfC | type | 13:23 |
| AfC | [hm] | 13:23 |
| AfC | try | 13:23 |
| AfC | # eix -e bzr | 13:23 |
| vila | oooooh | 13:23 |
| vila | what if I want to force a reinstall of 1.18 ? | 13:24 |
| vila | (since it came from the overlay ?) | 13:24 |
| AfC | I see 1.15.1 in green (stable) then (~)1.18 in yellow then 2.0_rc1 in reverse because that's what's installed | 13:24 |
| AfC | vila | 13:24 |
| AfC | # emerge bzr | 13:24 |
| AfC | :) | 13:24 |
| AfC | Ok, learning tip: | 13:24 |
| AfC | # emerge bzr -va | 13:24 |
| AfC | verbose ask | 13:24 |
| vila | haaa | 13:25 |
| AfC | which is an interactive form of | 13:25 |
| AfC | # emerge bzr -vp | 13:25 |
| AfC | verbose pretend | 13:25 |
| AfC | you should see a | 13:25 |
| * AfC tries | 13:25 | |
| vila | excellent | 13:25 |
| AfC | [ebuild R] | 13:25 |
| AfC | R for rebuild | 13:25 |
| AfC | *I* see: | 13:25 |
| AfC | [ebuild UD] | 13:25 |
| AfC | because since I installed 2.0_rc1 the Gentoo dev(s) looking after this package.mask'd 2.0_rc1 and added 1.18 | 13:26 |
| AfC | [ebuild UD] dev-util/bzr-1.18 | 13:26 |
| AfC | I should say | 13:26 |
| vila | AfC: yeah, don't use 2.0rc1 to upgrade to 2a | 13:26 |
| AfC | vila: oh, last point: | 13:26 |
| vila | and yes I see [ebuild R] | 13:26 |
| AfC | You can put USE flags per package in /etc/portage/package.use | 13:27 |
| AfC | ie, there I have: | 13:27 |
| AfC | dev-util/bzr curl | 13:27 |
| AfC | which is why I see | 13:27 |
| AfC | [ebuild UD] dev-util/bzr-1.18 [2.0_rc1] USE="curl sftp -bash-completion -doc -emacs -test" 5,838 kB | 13:27 |
| vila | excellent, added emacs :) | 13:28 |
| AfC | [apparently USE=sftp is kindly inherited from somewhere in the /etc/make.profile -> /usr/portage/profiles/default/linux/amd64/2008.0/desktop | 13:28 |
| AfC | profile chain | 13:28 |
| AfC | vila: Gentoo is undermanned and occasionally immature, but technically it's package management is unbelievably brilliant. | 13:29 |
| AfC | its {sigh} | 13:30 |
| AfC | vila: (and, compare the output from emerge -va / -vp with that from eix) | 13:30 |
| AfC | same same | 13:30 |
| * vila looking at bzr-1.18.ebuild and seeing the huge skip_tests :-( | 13:30 | |
| AfC | yeah, well | 13:30 |
| AfC | one thing at a time | 13:30 |
| AfC | the most important part is making the Gentoo packager(s) who are doing the work on these ebuilds feel loved. | 13:31 |
| vila | AfC: That is my target :-D I asked all these questions to setup one more slave in the botnet :) | 13:31 |
| vila | that's wonderful, I have the bug numbers right there, no need to search them again and again :D | 13:32 |
| AfC | Anyone know Christian Faulhammer [fauli] or Peter Volkov [pva]? If you see them, give them some props for their hard work. | 13:32 |
| AfC | vila: [frankly, filing a bug to get a package "stabilized" seems warped to me, but whatever] | 13:33 |
| vila | pva, I know the nick he reported many bugs in the test suite, but I don't remember seiing him here | 13:33 |
| AfC | vila: anyway, welcome to continuous moving target land. | 13:33 |
| vila | AfC: Thanks for the ride ! | 13:33 |
| AfC | vila: I recommend you run as much (ie, your entire system) as arch if this is a server. | 13:34 |
| AfC | vila: if it's a Desktop, then it's less alluring; | 13:34 |
| AfC | vila: I go to considerable trouble to ~arch the entire GNOME set | 13:34 |
| vila | It's a vm and will be used only to run the test suite | 13:34 |
| AfC | vila: but I'm back running a stable X server which is nice. | 13:34 |
| AfC | vila: fine | 13:34 |
| AfC | vila: (one of the things missing is the ability to say "unmask or ~keyword «GNOME» whereas I have something like 100 lines in /etc/portage/package.unmask to achieve that. Pain in the ass. But the entire rest of my system is stable. Nice mix) | 13:35 |
| AfC | s/unmask/keywords/ | 13:35 |
| vila | I just read this morning that you can transform package.keywords into a directory and use the package names for the file names into that directory... but I don't know if that apply... (mentioning it just in case it was a recent addition...) | 13:37 |
| AfC | That's a neat idea | 13:38 |
| AfC | No, the hassle is every 6 months GNOME (or the Gentoo packagers thereof) deciding to create 13 new packages where before there were 8 different ones. PITA. | 13:40 |
| vila | ha, ;-/ | 13:40 |
| AfC | so as you're trying to upgrade, `emerge` stops one by one saying "can't satisfy blah" and you tediously add it to /etc/portage/package.keywords | 13:40 |
| vila | AfC: found it back, that's in man portage | 13:40 |
| AfC | I could easily avoid this hassle if I just ran my entire system ~arch but I have no desire to do that | 13:41 |
| AfC | vila: ah | 13:41 |
| vila | But your explanations will help me now in that 752 lines monster :) | 13:42 |
| lifeless | gnight | 13:43 |
| vila | lifeless: gnight ! | 13:44 |
| AfC | vila: it's a bit dated, but the PDF at http://www.operationaldynamics.com/reference/articles/GentooUnusual/ is what I wrote some years ago about these topics. | 13:46 |
| * vila printing | 13:47 | |
| === mrevell is now known as mrevell-lunch | ||
| jelmer__ | heh | 14:30 |
| jelmer__ | "bzr stats" on a mercurial repo is now slightly faster than "bzr stats" on a bzr repo | 14:30 |
| jam1 | morning vila | 14:38 |
| === jam1 is now known as jam | ||
| vila | morning jam ! | 14:38 |
| AfC | jelmer__: is it faster than mercurial status (sic) on a mercurial repo? :) | 14:46 |
| jelmer__ | AfC: I'm not aware of a stats command in mercurial | 14:47 |
| jelmer__ | AfC: fortunately "bzr status" on a native branch is a lot faster than on a mercurial branch | 14:49 |
| AfC | oh... er, "stats" not "status". Don't seem to have that command here. | 14:49 |
| jelmer__ | it's a plugin | 14:49 |
| jelmer__ | "hg status" is several factors faster than "bzr status" on the same tree, because of the startup speed | 14:50 |
| AfC | ah :( | 14:55 |
| * vila rejoices ! Full test suite passing on the gentoo slave \o/ | 14:56 | |
| === mrevell-lunch is now known as mrevell | ||
| bialix | wow | 15:11 |
| jam | bialix: ? | 15:39 |
| bialix | hello jam | 15:39 |
| jam | morning bialix | 15:39 |
| bialix | for you it's morning | 15:40 |
| bialix | for me it's 17:40 | 15:40 |
| bialix | jam: are you asking me? | 15:40 |
| jam | bialix: You said "wow", I was trying to figure out what about | 15:41 |
| bialix | [16:56]* vilarejoices ! Full test suite passing on the gentoo slave \o/ | 15:41 |
| * bialix wonders what platform will be next? win32? | 15:41 | |
| vila | we have a winner here :) | 15:41 |
| vila | bialix: yes, that's my next target :) | 15:42 |
| bialix | oh! no! I can't believe! | 15:42 |
| vila | freebsd and gentoo was for warming me up :) | 15:42 |
| jam | vila: do you know how close we are? Or is the cygwin stuff getting in the way? | 15:43 |
| jam | Last I checked, we closed a few hundred failures with Robert's fixes to the merge and shelve code | 15:43 |
| vila | jam: still in the way, my next step (as opposed to target :-) is to finish setting up my local windows XP vm | 15:43 |
| Lo-lan-do | Speaking of win32… please tell me that TortoiseBZR works fine? | 15:44 |
| LeoNerd | I ran it over a year ago.. seemed just fine then | 15:44 |
| vila | and last I ran the test suite on windows it failed with Can't create thread, which I'm now able to reproduce on gentoo, so we're making significant progress on all fronts :-D | 15:44 |
| Lo-lan-do | (I'm selling bzr to a client, but many of their employees use TortoiseCVS currently) | 15:45 |
| Lo-lan-do | (yes, CVS) | 15:45 |
| bialix | Lo-lan-do: honestly I'd recommend bzr-explorer instrad | 15:45 |
| bialix | instead | 15:45 |
| Lo-lan-do | Aha. | 15:45 |
| vila | Lo-lan-do: try getting in touch with naoki which is now actively maintaining it or look at bzr-explorer | 15:45 |
| bialix | TortoiseBzr against TortoiseCVS is the little guy who can't piss into toilet | 15:46 |
| vila | Lo-lan-do: listen to bialix more than to me, *he* uses windows :-D | 15:46 |
| Lo-lan-do | vila: What's naoki's timezone? | 15:46 |
| vila | I think he's japanse | 15:46 |
| vila | I think he's japanese | 15:46 |
| Lo-lan-do | 'kay | 15:46 |
| bialix | Naoki from Japan | 15:46 |
| * Lo-lan-do looks at bzr-explorer while the Earth spins | 15:47 | |
| vila | . o 0 (He's still using Mosaic ??? ) | 15:47 |
| * vila wonders how many got the joke, fullermd maybe ? :-D | 15:48 | |
| * jelmer__ did :-) | 15:48 | |
| vila | amazing jelmer how old were you *then* ? :D | 15:49 |
| Lo-lan-do | I may be slightly too young, I started with Navigator and Communicator. | 15:49 |
| vila | Lo-lan-do: yup, too young, Navigator was what ? 3.0 already ? | 15:49 |
| jelmer__ | I never used it, my first browser was netscape | 15:49 |
| vila | haaaa | 15:50 |
| jelmer__ | I must've been 7 or 8 when mosaic was released | 15:50 |
| Lo-lan-do | Mosaic Netscape 0.9 – October 13, 1994 | 15:51 |
| Lo-lan-do | Netscape Navigator 3.0 – August 19, 1996 | 15:51 |
| Lo-lan-do | I started in September 1996, so yeah, 3.0 probably. | 15:51 |
| Lo-lan-do | (http://en.wikipedia.org/wiki/Netscape_Navigator) | 15:51 |
| vila | wikipedia never stops to amaze me | 15:52 |
| vila | http://en.wikipedia.org/wiki/Mosaic_web_browser | 15:52 |
| Lo-lan-do | The bzr-explorer site says "bound branches (also called heavyweight checkouts in Bazaar 1.x)" | 15:52 |
| * bialix just several days ago installed TCVS to get one project from sf.net. TCVS is amazed thing! | 15:53 | |
| Lo-lan-do | So checkouts are now lightweight unless otherwise specified? | 15:53 |
| vila | http://en.wikipedia.org/wiki/File:Mosaiclogo.png too bad it's not animated :-) | 15:53 |
| jam | Lo-lan-do: I think there is some discussion about doing that, I don't think there has been a specific patch that landed | 15:58 |
| jam | (note that 'bzr checkout' doesn't have a --heavyweight flag yet, etc) | 15:59 |
| Lo-lan-do | Okay. I'll just be careful when mentioning the feature then. | 15:59 |
| vila | jam: so reagrding #424444 did the recipe in #425594 helps understanding the problem ? | 16:00 |
| jam | vila: not sure, it seems that they are the same basic cause, I haven't dug any loser | 16:01 |
| jam | closer | 16:01 |
| jam | I'm just barely getting through the extra email from being away for 1 day ... | 16:01 |
| vila | ... I know the feeling :-/ :-) | 16:02 |
| DrSlony | Hey, how do I update something I downloaded using bazaar a while ago? | 16:03 |
| jam | DrSlony: either 'bzr pull' or 'bzr update' depending on how you got it | 16:04 |
| DrSlony | bzr branch lp:phatch | 16:05 |
| jam | phinze: ping if you are around | 16:05 |
| jam | DrSlony: genreally 'bzr pull' then | 16:05 |
| phinze | jam: pong, got your email | 16:05 |
| DrSlony | ok, thx :] | 16:05 |
| vila | DrSlony: bzr pull -v | 16:05 |
| vila | DrSlony: so you'll get some idea about what has changed, or 'bzr missing' first if you're unsure | 16:05 |
| vila | about getting these changes | 16:05 |
| DrSlony | great, thanks a lot! :) | 16:06 |
| Naoki | Good evening, all. | 16:58 |
| Naoki | Lo-lan-do: Currently, TBZR can init, add, delete, commit, push, pull, and some commands. | 16:59 |
| Lo-lan-do | Naoki: Can it do checkouts, logs and remote branches? | 16:59 |
| Lo-lan-do | (Good morning, by the way :-) | 16:59 |
| Naoki | Yes, it can. | 17:00 |
| Lo-lan-do | Excellent. diff? | 17:00 |
| Naoki | But lightweight checkout is not recommanded. | 17:00 |
| Naoki | Because "bzr st" on lightweight checkout impossible. | 17:00 |
| Lo-lan-do | No, heavyweights will be very fine. | 17:00 |
| Naoki | Yes. qlog, qdiff from context menu. | 17:01 |
| Lo-lan-do | Then it seems it will fit the bill perfectly. The targeted users are unlikely to need more than that. | 17:01 |
| Naoki | Most basic operation can done with TBZR, except move/rename. | 17:01 |
| Naoki | And currently, tbzr doesn't load plugin. So TBZR doesn't work with bzr-loom. etc. | 17:02 |
| Lo-lan-do | Ah, hm. I guess I'll tell them to run the CLI for renames then. That shouldn't be a problem. | 17:02 |
| Lo-lan-do | I believe the targeted users are not advanced enough to require plugins. | 17:03 |
| Lo-lan-do | This is all excellent news. Thanks! | 17:03 |
| Naoki | not at all. | 17:04 |
| Naoki | Good night. | 17:04 |
| Naoki | s/"bzr st" on lightweight checkout impossible/"bzr st" on lightweight checkout without connection to branch impossible/ | 17:07 |
| Naoki | lightweight checkout from local works fine. | 17:07 |
| Naoki | lightweight checkout from remote branch and offline is problem. | 17:08 |
| Lo-lan-do | In this case, the users are a company and the server is assumed to be always reachable (although I'll discourage lightweights anyway to avoid server load). | 17:10 |
| davidstrauss_ | Is it possible to have bzr stores its repo data in a place other than .bzr at the branch root? | 17:35 |
| Lo-lan-do | Yes, you can use shared repositories or lightweight checkouts (or both at the same time) | 17:36 |
| Lo-lan-do | But you'll still have a .bzr dir with a few files pointing to the actual location of the data, I believe. | 17:36 |
| davidstrauss_ | Yes, OK | 17:37 |
| Lo-lan-do | I'm not sure you can avoid that, but I'm just a bystander here so don't trust my word on that. | 17:37 |
| jelmer__ | davidstrauss_: what is it you're trying to do? | 17:38 |
| jelmer__ | davidstrauss_: if you don't have a pointer to the actual location of the data, how are you going to access the data? | 17:38 |
| jelmer__ | or perhaps, do you not care about history at this point? | 17:38 |
| Lo-lan-do | Magic! (or an environment variable, maybe) | 17:39 |
| === davidstrauss_ is now known as davidstrauss | ||
| davidstrauss | Lo-lan-do: I'm trying to version config on a server | 17:40 |
| davidstrauss | Lo-lan-do: And I'd rather not keep stuff in /.bzr | 17:40 |
| Lo-lan-do | If "stuff" is the real history data, then shared repos and/or lightweight checkouts are for you. If you don't want a .bzr dir at all… I'm not sure there's a way currently. | 17:41 |
| davidstrauss | Lo-lan-do: I'm thinking a symlink | 17:41 |
| Lo-lan-do | Hm. Interesting. Never tried it myself, but I guess it's worth a try :-) | 17:42 |
| === kfogel is now known as kfogel-lunch | ||
| theuiguy | Does anyone know whether python will use function arguments in order if you don't use named arguments? | 18:46 |
| theuiguy | For example: merge_cmd.run(branch=branch_base, revision=revision) . Could I call it as merge_cmd.run(branch_base, revision) | 18:47 |
| theuiguy | I'm hoping so, because it changed name from branch to location | 18:48 |
| jam | theuiguy: generally named arguments can be called as positional arguments | 18:49 |
| theuiguy | jam: thanks. Is there a better solution to this? I need to support older and new bzr with my plugin. | 18:51 |
| jam | theuiguy: don't use cmd_merge.run... | 18:51 |
| jam | At least, IMO, if you are using cmd_* then we probably have something wrong in our library, since it is only meant as a way to get from command line args to internal processing | 18:51 |
| jam | (I'm not saying you have the option, but it might be pointing at something we should look at) | 18:52 |
| theuiguy | jam: It's convenient in this case because I don't need to redo everything that happens when the command is called from the command line | 18:54 |
| bpierre | hi | 19:43 |
| bpierre | abentley: did you have time to look at my merge proposal for bzrtools? | 19:44 |
| abentley | bpierre: Sorry, I went away on vacation and then forgot about it. | 19:45 |
| abentley | bpierre: I will look at it this week. | 19:45 |
| bpierre | ok, thanks | 19:45 |
| === kfogel-lunch is now known as kfogel | ||
| lvh | hello | 19:56 |
| === fagsiuags is now known as pygi | ||
| kfogel | abentley: I haven't done anything "differently" in this branch in a while, but all of a sudden: | 20:36 |
| kfogel | $ pwd | 20:36 |
| kfogel | /home/kfogel/src/bzr/bzr.dev-trunk | 20:36 |
| kfogel | $ bzr pull | 20:36 |
| kfogel | Using saved parent location: http://bazaar-vcs.org/bzr/bzr.dev/ | 20:36 |
| kfogel | bzr: ERROR: Cannot lock LockDir(http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/.bzr/branch/lock): Transport operation not possible: http does not support mkdir() | 20:36 |
| kfogel | abentley: any idea what that's about? I'm just pulling, so not sure why any mkdir() on the server side would be needed. | 20:37 |
| abentley | kfogel: what does 'bzr info' say about the branch? | 20:37 |
| kfogel | abentley: http://paste.ubuntu.com/267498/ | 20:38 |
| kfogel | abentley: is this b/c of 2a upgrade of bzr trunk? | 20:38 |
| abentley | kfogel: Your branch is a checkout. You should run update, not pull. You are attempting to pull into http://bazaar-vcs.org/bzr/bzr.dev/ | 20:39 |
| kfogel | abentley: wow. I think that must be because I set it up way back when, before I'd developed other habits of setting things up. Thanks. I'm just going to restructure so that my bzr trunk works the same way my everything-else trunk works. | 20:40 |
| abentley | kfogel: No problem. | 20:40 |
| abentley | kfogel: 'bzr unbind' or 'bzr reconfigure --tree' is what you need. | 20:41 |
| kfogel | abentley: nothing fancy here, I'm just re-branching. Nothing Can Go Wrong. | 20:42 |
| Lo-lan-do | (Famous last words) | 20:46 |
| kfogel | abentley: I'm in a 2a shared repository on my local machine, with two branches in it: "trunk" (branched from lp:launchpadlib) and "apidoc-html-title-attrs" (branched from lp:~kfogel/launchpadlib/apidoc-html-title-attrs, which is *now* known as lp:~kfogel/launchpadlib/OLD-apidoc-html-title-attrs because I just now moved it as one strategy for coping with the fact that I couldn't push my changed local branch to it). Now I'm getting this err | 20:55 |
| kfogel | or: | 20:55 |
| kfogel | bzr push --remember lp:~kfogel/launchpadlib/apidoc-html-title-attrs | 20:55 |
| kfogel | Using default stacking branch /~lazr-developers/launchpadlib/trunk at lp-45207760:///~kfogel/launchpadlib | 20:55 |
| kfogel | bzr: ERROR: Server sent an unexpected error: ('error', "KnitPackRepository('lp-45207760:///~lazr-developers/launchpadlib/trunk/.bzr/repository')\nis not compatible with\nCHKInventoryRepository('lp-45207760:///~kfogel/launchpadlib/apidoc-html-title-attrs/.bzr/repository')\ndifferent rich-root support") | 20:55 |
| === khmarbaise_ is now known as khmarbaise | ||
| abentley | kfogel: 2a is not compatible non-rich-root formats, such as the one used by your default stacking branch, ~lazr-developers/launchpadlib/trunk | 20:57 |
| kfogel | abentley: thank you. But when I branched lp:launchpadlib into my local 2a repository, that worked. | 20:58 |
| kfogel | ? | 20:58 |
| Lo-lan-do | It works one-way | 20:58 |
| abentley | kfogel: Right. non-rich-root is compatible, at a model level, with rich-root. | 20:58 |
| abentley | kfogel: We just make up the missing data. | 20:58 |
| kfogel | Lo-lan-do, abentley: ah, okay. So I can branch older into newer, but never newer into older because older has no way to represent some of the data in newer. | 20:59 |
| kfogel | right? | 20:59 |
| abentley | kfogel: Correct, but there's more. | 20:59 |
| kfogel | abentley: ? | 20:59 |
| abentley | kfogel: The error is because no repository format is compatible, for stacking purposes with other repository formats. | 21:00 |
| abentley | kfogel: stacking is done at the data-representation level. | 21:00 |
| kfogel | abentley: *nod* And "stacking" being different from "sharing", I can share, but not stack. | 21:00 |
| abentley | kfogel: Right. | 21:01 |
| abentley | kfogel: Once you've branched older into newer, your branch is in the newer format, so there's only one format in the picture. | 21:02 |
| kfogel | abentley: thanks, that was helpful. | 21:02 |
| kfogel | I'm just going to rebranch everyone with default format. | 21:03 |
| abentley | kfogel: np. | 21:03 |
| kfogel | abentley: latest bzr (which I am using) does 2a by default; what's the right thing to pass to get "whatever format will work seamlessly with Launchpad, not counting the few Launchpad-hosted branches that are themselves in 2a"? | 21:04 |
| Magilum | bzr crashes trying to import my SVN repository in version 1.13.1 (the version in Ubuntu Jaunty), but I can't upgrade bzr to 1.18 and upgrade bzr-svn via the bazaar PPA. Will the PPA's bzr-svn get a dependency bump, or is there something else I should do to see if this error is fixed? | 21:05 |
| Lo-lan-do | I'm still amazed someone like kfogel is still involved in version control after all these years. I've known the name from the CVS book like 12 years ago :-) | 21:05 |
| kfogel | Lo-lan-do: well, everything else one does involves version control somehow, so... :-) | 21:06 |
| abentley | kfogel: You don't need to pass anything in to get the source branch's format. That is what "bzr branch" does by default. The '2a' default applies mainly to init and init-repository. | 21:06 |
| kfogel | abentley: I'm creating a shared repository first. | 21:06 |
| Lo-lan-do | I hope I'll still be around and doing stuff with forges in 5 years. | 21:06 |
| abentley | kfogel: If you create a shared repository, there can be only one format. | 21:06 |
| kfogel | abentley: I know. I'm asking what that format should be, for a currently typical (non-2a) Launchpad-hosted project. | 21:07 |
| kfogel | Lo-lan-do: escape while you still can! | 21:08 |
| kfogel | :-) | 21:08 |
| lamont | are bzr-gtk and bzr-svn from the bzr ppa the right versions for 1.18? (if someone knows before I go through the work of downloading them just to find out) | 21:08 |
| abentley | kfogel: There isn't a single answer to that question. You should use whatever format the development focus of that project uses. | 21:08 |
| Magilum | lamont: bzr-gtk seems to be, but bzr-svn's package is wrong. | 21:09 |
| Lo-lan-do | kfogel: Certainly not. I found a hole where I can do what I like without needing a job to earn my living, I'm not abandoning that in a hurry. | 21:09 |
| abentley | kfogel: if the development focus doesn't support stacking, it doesn't matter, though. | 21:10 |
| kfogel | abentley: the trouble is that such pages (e.g., https://code.edge.launchpad.net/~lazr-developers/launchpadlib/trunk in this case) talk about formats in plain English, whereas bzr wants flags. When I look at the output of 'bzr help init-repo', I'm unable to map what I see on the branch web page to the right flag. | 21:10 |
| kfogel | abentley: based on the error I got earlier, the development focus clearly supports stacking :-). | 21:11 |
| abentley | kfogel: bzr info will report the format. | 21:11 |
| kfogel | abentley: so I should check out a branch, run 'bzr info' on it, then create a shared repository so I can fetch the branch again? | 21:12 |
| kfogel | abentley: that came out sounding more sarcastic than I meant it, but... I do mean it a little sarcastically :-). | 21:12 |
| abentley | kfogel: You can run any operation that doesn't access the working tree on a remote branch. In this case, I meant you to run "bzr info sftp://bazaar.launchpad.net/~lazr-developers/launchpadlib/trunk". I'm sorry I was unclear. | 21:13 |
| kfogel | Ah, thank you. No, you were clear -- I just didn't know 'bzr info' worked on remote branches (though why shouldn't it, really?). | 21:14 |
| abentley | kfogel: So the weird bit is that the branch is in pack-0.92 format. | 21:14 |
| abentley | kfogel: It shouldn't be trying to stack. | 21:14 |
| kfogel | abentley: oh, running 'bzr info lp:launchpadlib' isn't enough, I guess I actually have to run the exact command you just gave, no? | 21:14 |
| kfogel | abentley: the end goal here is a shared repository with launchpadlib trunk in it, and with my already-existing branch in it. I'm not sure what the fastest path to that is anymore. Do you have any ideas? | 21:15 |
| abentley | kfogel: due to an ancient bug, bzr+ssh URLs do not provide the right information, and lp: resolves to bzr+ssh. | 21:15 |
| kfogel | ah | 21:15 |
| kfogel | abentley: ah | 21:16 |
| kfogel | abentley: http://paste.ubuntu.com/267520/ | 21:16 |
| kfogel | abentley: that's what I get when I branch launchpadlib to a standalone branch and run 'bzr info -v' | 21:16 |
| kfogel | abentley: none of the English there directly corresponds to a flag to init-repo either (?), as far as I can tell. | 21:17 |
| abentley | kfogel: The "format: unnamed" would normally correspond to an init-repo flag. The problem is that your working tree format is not the usual format produced by --pack-0.92 | 21:26 |
| kfogel | abentley: sorry, dropped off their b/c laptop somehow hit critical temperature (I have no idea how). | 21:28 |
| kfogel | abentley: I probably missed some things you said. | 21:28 |
| abentley | kfogel: No, after you said "none of the English there directly corresponds..." I saw you fall offline and waited. | 21:29 |
| kfogel | abentley: thx | 21:29 |
| kfogel | abentley: should I just give up on the shared repo for now? | 21:30 |
| kfogel | abentley: I don't really need it, I just prefer to do things that way. | 21:30 |
| abentley | kfogel: I think that if you create a --1.9 shared repository and a --2a shared repository, that will probably work. | 21:31 |
| abentley | kfogel: But yeah, the only advantage of keeping distinct projects in the same shared repo is reducing the management cost, and you lose some of that advantage by having two shared repos. | 21:33 |
| kfogel | abentley: ? these aren't distinct projects. these would all be branches of the same project | 21:34 |
| abentley | kfogel: So none of it should be in --2a format. | 21:35 |
| kfogel | abentley: sure, we've definitely established that | 21:37 |
| abentley | kfogel: Okay, I don't understand why you were suggesting that giving up on shared repositories was a solution. | 21:38 |
| kfogel | abentley: well, because we've been working on this a long time and I still don't know what command to use to create a shared repository that would actually work for these branches? | 21:39 |
| kfogel | abentley: I've already unblocked and just made standalone branches, so it's not a bottleneck anymore. I'm now just curious what I would have done, if I were going to go the shared repos route. | 21:39 |
| abentley | kfogel: bzr init-repo --pack-0.92 will work. | 21:39 |
| kfogel | abentley: thanks. | 21:40 |
| abentley | kfogel: Because you were asking about generalities before, I couldn't answer you. | 21:40 |
| kfogel | abentley: Er. I thank you for all the help, but I was pretty specific. See the log. | 21:41 |
| kfogel | "abentley: the end goal here is a shared repository with launchpadlib trunk in it, and with my already-existing branch in it. I'm not sure what the fastest path to that is anymore. Do you have any ideas?" | 21:42 |
| abentley | kfogel: I meant this one here: "I'm asking what that format should be, for a currently typical (non-2a) Launchpad-hosted project". | 21:42 |
| kfogel | abentley: well, sure -- but the whole discussion started with a problem statement and an error message. Seriously, look back at it :-). | 21:43 |
| kfogel | abentley: I guess I'm not sure how I could have been clearer about what I was trying to do. | 21:44 |
| === mm-mysql_ is now known as mm-mysql | ||
| abentley | kfogel: The error message does not describe how you are using bzr, or why you have a --2a format. The bit where you specifically asked "what's the fastest path" came relatively late in the discussion. | 21:53 |
| kfogel | abentley: sorry, I would have stressed that earlier if I'd realized my goals weren't immediately clear. | 21:53 |
| abentley | kfogel: After I said "So the weird bit is that the branch is in pack-0.92 format", we had all the information we needed to solve your specific problem. | 21:55 |
| abentley | kfogel: A lot of people like to keep a single shared repo, and I thought that was what you were doing. | 21:57 |
| kfogel | abentley: ah. I've never done that, though it's intriguing. | 21:57 |
| abentley | kfogel: And then when they upgrade their shared repo because one of the branches within it needs to be rich-root, they start running into problems everywhere. | 21:58 |
| kfogel | abentley: yeah, I'm not going to try it, b/c of precisely the problems we've seen today | 22:00 |
| abentley | kfogel: Now, your already-existing branch: did you do commits into it when it was in 2a format? | 22:00 |
| kfogel | abentley: nothing I can't easily replicate | 22:00 |
| abentley | kfogel: Cool, 'cause as you'd imagine, you can't put a --2a branch in a 0.92 repository, or merge it into a pack-0.92 branch like trunk. | 22:01 |
| kfogel | yup | 22:03 |
| poolie | hi jam | 23:03 |
| init | rawr | 23:16 |
| init | does anyone know where i can find the bzr_access script? | 23:16 |
| init | and/or somehow get equavilent functionality? | 23:16 |
| jam | hey poolie, care to try again? | 23:16 |
| jam | I was just bringing my son back home | 23:17 |
| init | i can't seem to find the link on google | 23:17 |
| jelmer__ | g'day poolie, jam | 23:17 |
| jam | init: contrib/bzr_access | 23:17 |
| jam | hey jelmer__ | 23:17 |
| jam | init: http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/annotate/head%3A/contrib/bzr_access | 23:18 |
| jam | with the direct link being | 23:18 |
| jam | http://bazaar.launchpad.net/%7Ebzr-pqm/bzr/bzr.dev/download/head%3A/bzr_access-20071210163004-c9lb1renhra2ncg0-1/bzr_access | 23:18 |
| init | aha | 23:18 |
| poolie | jam, hi, | 23:18 |
| init | thank you | 23:18 |
| init | ugh | 23:29 |
| init | i'm having an issue with loggerhead now | 23:29 |
| init | http://awos-bzr.wilcox-tech.com/repos/AWOS/annotate/head%3A/src/utils/Makefile <- happens with all files | 23:30 |
| init | ah ProgressBarStack was deprecated... | 23:35 |
| init | not sure what to replace it with | 23:36 |
| init | ahh managed to fix it | 23:44 |
| init | i think | 23:44 |
| mwhudson | jam: you still here? | 23:47 |
| init | yep i did | 23:47 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
