| davidstrauss | BasicOSX: So, 1.14 tonight? 8) | 00:16 |
|---|---|---|
| lifeless | BasicOSX: yes, because whatever is going on is parallelisable fixable between spiv and I | 00:23 |
| lifeless | BasicOSX: waiting on the release for it won't make it get fixed faster, and whatever the issue is 1.13 already has it | 00:23 |
| BasicOSX | I'm working 1.13.2 and 1.14final in parallel | 00:25 |
| awilkins | jelmer ? | 00:25 |
| BasicOSX | bug 368932 | 00:41 |
| ubottu | Launchpad bug 368932 in bzr "FAIL: test_no_color (bzrlib.plugins.bzrtools.tests.shelf_tests.ShelfTests)" [Undecided,New] https://launchpad.net/bugs/368932 | 00:41 |
| lifeless | BasicOSX: WARNING Installed Bazaar version 1.13.2 is too old to be used with plugin | 00:44 |
| lifeless | "Bzrtools" 1.14.0. | 00:44 |
| BasicOSX | lifeless: I said as much in the bug report, justl ooking for confirmation | 01:09 |
| lifeless | BasicOSX: I've marked it invalid already :) | 01:12 |
| BasicOSX | Just being extra careful ... doing 2 releases is hectic | 01:21 |
| lifeless | BasicOSX: oh sure | 01:39 |
| lifeless | spiv: ping | 02:23 |
| spiv | lifeless: pong | 02:24 |
| lifeless | how are you going on the ACF stuff | 02:24 |
| lifeless | do you want me to jump in? | 02:24 |
| spiv | lifeless: so the key problem seems to be distinguishing "ghost" from "missing-but-required" in the sink. | 02:26 |
| spiv | Or I suppose "will cause ACF errors later" from "won't cause errors". | 02:26 |
| SamB | ACF? | 02:31 |
| lifeless | absent content factory | 02:31 |
| lifeless | spiv: so the sink has two cases, stacked-without-basis and stacked-with-basis | 02:31 |
| lifeless | spiv: in *both* cases we want to end up with the same behaviour | 02:31 |
| lifeless | thats a likely bug at the moment | 02:32 |
| spiv | The sink doesn't necessarily know if there is stacking, though. | 02:32 |
| lifeless | right | 02:32 |
| lifeless | stacked-without-basis won't 'know' | 02:32 |
| lifeless | we will have to unwind some of the 'support' in knit.py for stacking to let the sink figure out it needs various inventories, or something along those lines | 02:33 |
| lifeless | spiv: ok, case one, without basis | 02:35 |
| lifeless | we'll see N revisions | 02:35 |
| lifeless | thats what the user *wants* us to have | 02:35 |
| lifeless | we want all adjacent inventories | 02:35 |
| lifeless | inventories that we can't get are either corrupt branch symptoms, or ghosts | 02:35 |
| SamB | what if you tried to access the branch a remote branch is stacked on ... but the url was only good over there ? | 02:38 |
| mwhudson | SamB: stacking is a client side thing, basically | 02:39 |
| lifeless | in the former, we will either be unable to reconstruct some inventories[existing checks should handle this], or we can reconstruct but the union of deltas for inventory will reference texts we can't access | 02:39 |
| lifeless | SamB: I don't understand the question | 02:39 |
| lifeless | so, if we have an inventory parent missing, can reconstruct the inventory, then we can do a delta against all the parents we *did* get, and check that every text added is available locally | 02:43 |
| lifeless | thats basically the logic in find_file_ids_altered again | 02:43 |
| spiv | Right. | 02:45 |
| spiv | So basically requiring adjacent parents is too strict. It's sufficient but not necessary. | 02:45 |
| spiv | Each parent we have cuts down the set of texts that we require. | 02:48 |
| spiv | We don't even *need* any parents for some inventory so long as we have every text referenced by that inventory. | 02:49 |
| lifeless | right, though every parent we miss is more data we'll send | 02:51 |
| spiv | Right. | 02:51 |
| spiv | Ok, I think I know how to rework this. It's a shame it's so complex. | 02:52 |
| spiv | It'd be nice to have a nice helper object for tracking the set of "key A needs keys X, Y, Z", which I could just feed newly seen keys and their dependencies into... | 02:54 |
| cody-somerville | ugh, this is weird | 02:54 |
| cody-somerville | I do bzr add and nothing happens | 02:54 |
| cody-somerville | bzr status shows the directory I'm trying to add as unknown | 02:54 |
| cody-somerville | bzr 1.13.1 | 02:55 |
| spiv | cody-somerville: that does sound odd | 02:55 |
| cody-somerville | aw, I see why from bzr.log | 02:56 |
| mwhudson | cody-somerville: is it ignored | 02:56 |
| mwhudson | ? | 02:56 |
| cody-somerville | no | 02:56 |
| cody-somerville | nested bzr tree | 02:56 |
| spiv | mwhudson: "unknown" implies "not ignored" | 02:56 |
| mwhudson | oh right, you said that already :) | 02:56 |
| cody-somerville | removing the .bzr in the directory resolves the issue | 02:57 |
| cody-somerville | However, its odd that bzr doesn't say something more meaningful than just nothing | 02:57 |
| mwhudson | spiv: right | 02:57 |
| spiv | cody-somerville: file a bug. The nested tree stuff isn't fully mature yet. | 02:58 |
| cody-somerville | will do | 02:58 |
| lifeless | actually | 02:58 |
| lifeless | its deliberate | 02:58 |
| lifeless | we don't auto-add nested trees or child trees | 02:59 |
| lifeless | there are separate commands for that | 02:59 |
| cody-somerville | still a bug that no error is given when I specifically try to add it | 02:59 |
| cody-somerville | In this case, I didn't intend for it to be a nested or child tree | 02:59 |
| spiv | lifeless: oh? Hmm, I guess I can see that. Sounds like the current UI is confusing enough that we should do something differently, though. | 03:00 |
| lifeless | cody-somerville: 'bzr add tree' will add *in that tree* | 03:01 |
| cody-somerville | bzr help add doesn't mention that | 03:02 |
| SamB | lifeless: should say SOMETHING if you explicitly mention one, though | 03:02 |
| SamB | like "not adding nested tree blah blah blah because blah blah blah" | 03:03 |
| SamB | or whatever | 03:03 |
| lifeless | cody-somerville: its a bit of a theme in bzr that when you give it a path it acts on the tree the path is in | 03:03 |
| lifeless | SamB: it *never* sees that its a nested tree | 03:04 |
| lifeless | SamB: because its been given the root of a tree | 03:04 |
| cody-somerville | Thats not quite what .bzr.log suggested | 03:04 |
| SamB | lifeless: well, it should say that it's not doing anything | 03:04 |
| cody-somerville | Let me add that to my bug report | 03:04 |
| cody-somerville | oh wait | 03:05 |
| cody-somerville | nvm | 03:05 |
| lifeless | SamB: its the same as 'bzr add' isn't it? | 03:05 |
| lifeless | SamB: that already says " | 03:05 |
| lifeless | ignored 702 file(s). | 03:05 |
| lifeless | If you wish to add some of these files, please add them by name. | 03:05 |
| lifeless | " | 03:05 |
| SamB | oh, wait, why does "bzr add tree" do an add in that tree ... that sounds pretty wierd | 03:05 |
| lifeless | SamB: same reason that 'bzr commit /path/to/tree' commits in that tree | 03:06 |
| SamB | these commands are too context-dependent :-( | 03:06 |
| === BasicPRO changed the topic of #bzr to: Bazaar version control system | 1.13.2 released 28 April, 2009 | 1.14rc2 released 20 April, 2009 | http://bazaar-vcs.org | http://irclogs.ubuntu.com/ | http://planet.bazaar-vcs.org/ | ||
| Peng_ | The question is, does 1.13.2 go before or after 1.14rc2 in NEWS? | 03:12 |
| Peng_ | And I bet I could find out in about 15 seconds. :P | 03:12 |
| fullermd | Yes :p | 03:14 |
| SamB | hmm, so should NEWS be a directed graph instead of a linear history ? | 03:14 |
| lifeless | no | 03:16 |
| lifeless | its a flattened traversal of all releases done for convenience | 03:16 |
| lifeless | 'trunk' has never been released | 03:16 |
| lifeless | spiv: so if you're not needing help with acf stuff, I'll keep pushing round trips down | 03:19 |
| fullermd | Trunk is not released. It escapes. | 03:19 |
| * SamB steals trunk | 03:21 | |
| spiv | lifeless: sure | 03:25 |
| Peng_ | SamB: Now you have to be PQM. :P | 03:33 |
| * SamB puts the tags back in and lets trunk escape again | 03:34 | |
| === arjenAU2_ is now known as arjenAU | ||
| xiaohui | I have make a local branch of trunk at rev 2376, then I committed with unchange , the revision goes to 2377. After I used *bzr rebase lp:project* , now the revision is 2467, anctually the revision of trunk is 2466 now. When I use *bzr push*, it shows * bzr: ERROR: These branches have diverged. Try using "merge" and then "push".* How should I do now? | 04:08 |
| lifeless | you have to use --force after rebasing | 04:09 |
| lifeless | because rebasing looks to bzr like you have created new unrelated history | 04:10 |
| xiaohui | when I pushed the to my branch but not the trunk | 04:11 |
| lifeless | thats right | 04:12 |
| lifeless | if you want to rebase you'll have to --force always | 04:12 |
| xiaohui | and some one told me use the *bzr rebase lp:mybranch* to have a try | 04:12 |
| lifeless | because rebase breaks the links that let bzr know what you have done built on something you'd pushed earlier | 04:12 |
| xiaohui | you mean I shoud use it like *bzr rebase --force*? | 04:13 |
| SamB | xiaohui: maybe you just shouldn't use it ;-P | 04:13 |
| SamB | it IS rather destructive | 04:14 |
| SamB | have you read what Linus has to say about it? | 04:14 |
| SamB | you probably should | 04:14 |
| Kilroo | Out of curiosity, is it at all likely that when I installed 1.13 over an existing installation recently it either failed to overwrite my installation of bzr-svn or installed the wrong one...or did I probably just accidentally tell it not to include the core plugins? | 04:14 |
| xiaohui | no, SamB | 04:14 |
| xiaohui | SamB: what the Linus said? | 04:15 |
| lifeless | Kilroo: I would guess you didn't tell it to include the plugins | 04:15 |
| lifeless | xiaohui: 'rebase turns tested code into untested code' -- Linus | 04:15 |
| Kilroo | I suspected as much. | 04:15 |
| xiaohui | so ,lifeless how should I do now.I have no idea | 04:16 |
| lifeless | xiaohui: use --force when you push, or don't use rebase. | 04:17 |
| xiaohui | so use the *bzr rebase lp:trunk*, and *bzr push --force * to my branch | 04:19 |
| xiaohui | I see, thank you lifeless | 04:19 |
| xiaohui | oh, it doesn't work | 04:24 |
| SamB | xiaohui: this is what I meant: http://lwn.net/Articles/328438/ | 04:29 |
| SamB | it took me a while to find it again | 04:29 |
| SamB | I wonder how I got to it the first time ... | 04:30 |
| xiaohui | thanks ,SamB | 04:31 |
| xiaohui | there are some more terrible problem *bzr: ERROR: Could not acquire lock "(remote lock)"* | 04:31 |
| xiaohui | I use the * bzr break-lock lp-140409033803088:///~xiaohui/opencog/moses/.bzr/branch/lock * and it return the ERROR of *bzr: ERROR: Unsupported protocol for url "lp-140092643935568:///~xiaohui/opencog/moses/.bzr/branch/lock"* | 04:33 |
| xiaohui | how to break the remot lock? | 04:35 |
| lifeless | xiaohui: bzr break-lock lp:~xiaohui/opencog/moses | 04:37 |
| xiaohui | :), | 04:40 |
| garyvdm | ping igc1 | 04:50 |
| garyvdm | Sorry Ian - I got to run - I'll send my question in a mail. | 04:52 |
| BasicPRO | Bug 304883 is fix released, but I do not see it in NEWS or find a log of it | 05:19 |
| ubottu | Launchpad bug 304883 in bzr "Handling of carriage return character across platforms" [High,Fix released] https://launchpad.net/bugs/304883 | 05:19 |
| === BasicPRO is now known as BasicOSX | ||
| BasicOSX | but it is tagged 1.14 | 05:19 |
| BasicOSX | The other 2 bugs tagged for 1.14 have NEWS entries and I find them in the logs | 05:19 |
| lifeless | wow, hadn't heard of it even | 05:22 |
| BasicOSX | I've PQM'd 1.14 with bug 364900 and bug 358037 to keep the ball rolling | 05:24 |
| ubottu | Launchpad bug 364900 in bzr "pure python Groupcompressor failure" [Critical,Fix committed] https://launchpad.net/bugs/364900 | 05:24 |
| ubottu | Launchpad bug 358037 in bzr "Revision not in bzrlib.groupcompress.GroupCompressVersionedFiles" [Undecided,Fix released] https://launchpad.net/bugs/358037 | 05:24 |
| BasicOSX | Looks like 358037 was in 1.14rc2, so but result is the same | 05:25 |
| BasicOSX | lifeless: advise on bug 304883? Wait on it or push 1.14 out the door? | 06:20 |
| ubottu | Launchpad bug 304883 in bzr "Handling of carriage return character across platforms" [High,Fix released] https://launchpad.net/bugs/304883 | 06:20 |
| BasicOSX | lifeless: or as RM my call? :-) | 06:20 |
| lifeless | your call | 06:20 |
| lifeless | I would get 1.14 out | 06:21 |
| BasicOSX | brb, getting a coin | 06:22 |
| spiv | BasicOSX: see also igc's reply to your mail on the list | 06:24 |
| === chandlerc__ is now known as chandlerc | ||
| === dereine[OFF] is now known as dereine | ||
| lifeless | later, all, started early this morning | 06:56 |
| Peng_ | Is "getting a coin" a slang term I don't know, or did you actually get a small amount of money? | 06:56 |
| lifeless | Peng_: to flip | 06:56 |
| Peng_ | Ahhhh. Thanks. :) | 06:57 |
| lifeless | one flips coins to make binary decisions | 06:57 |
| fullermd | Y'know, 1d2 ;) | 06:57 |
| Peng_ | Yes, in the rock I've been living under we used a piece of bark. | 06:57 |
| Peng_ | Isn't there a virtual coin flip website? | 07:00 |
| fullermd | Who trusts other people's entropy? | 07:00 |
| === dereine is now known as dereine[OFF] | ||
| lifeless | theres a sshkeygen website | 07:04 |
| fullermd | There is? | 07:05 |
| Peng_ | They even encourage you to enter your username and hostname for the comment. It's brilliant. | 07:05 |
| fullermd | Wow. | 07:05 |
| fullermd | The internet has ruined my ability to take minor joy in imagining spectacularly bad ideas :( | 07:05 |
| Peng_ | Where does the guy who runs it even get enough entropy? Maybe the website gives out the same keys every time. | 07:05 |
| fullermd | Oh, that's easy. Any amount of entropy automatically contains some unknown multiple of the amount of entropy it contains! | 07:06 |
| lifeless | fullermd: http://www.sshkeygen.com/ <- :) | 07:06 |
| Peng_ | Oh! It defaults to 512-bit keys! WTF? | 07:07 |
| Peng_ | "upswing isodialuric overbray 92580" is a great suggested passphrase. | 07:08 |
| fullermd | Crap. Now I have to change all my keys... | 07:08 |
| vila | hi all | 07:13 |
| lifeless | vila: hi, your ssh fix, is it blocked? | 07:14 |
| vila | lifeless: not reviewed so far AFAIK | 07:16 |
| lifeless | vila: is the bug in 1.14? | 07:16 |
| vila | as mentioned in the cover letter, no, only in bzr.dev | 07:16 |
| vila | but the NEWS file is a bit misleading in that reagard | 07:17 |
| vila | regard even | 07:17 |
| fullermd | It works for me... | 07:22 |
| vila | fullermd: what ? Changing all your ssh keys ? | 07:25 |
| fullermd | That would be a slightly different definition of 'work' ;) | 07:26 |
| vila | fullermd: so, you mean you tested my patch ? | 07:28 |
| * fullermd nods at vila. | 07:28 | |
| vila | fullermd: thanks | 07:28 |
| fullermd | I now get "that's not a branch, wtf are you smoking" instead of "Password: ] bzr+ssh < 0KB 0KB/s |" | 07:29 |
| fullermd | Which actually might be a really good password, come to think of it, but... | 07:29 |
| lifeless | jamesh: docs for gnome-keyring via python, where would I find? | 07:30 |
| vila | BasicOSX: Dear RM, how about defining a 1.15 series and a 1.15rc1 milestone so that we can target bugs ? Thanks in advance :) | 07:40 |
| jamesh | lifeless: I don't know if there are specific docs, but the module is gnomekeyring, and the API is almost identical to the C API | 08:04 |
| jamesh | lifeless: with the exception that the async interfaces have not been wrapped | 08:04 |
| lifeless | argh | 08:08 |
| lifeless | I want a place to store a aws key id and secret key | 08:08 |
| lifeless | jamesh: but no async api means blocking the ui, doesn't it ? | 08:13 |
| jamesh | lifeless: yes. | 08:13 |
| lifeless | sadness | 08:14 |
| jamesh | but it is usually pretty quick ... | 08:14 |
| lifeless | is it trivial to wrap the async interface and simply laziness, or are there complications | 08:14 |
| jamesh | provided it doesn't ask the user for authorisation before returning the data | 08:14 |
| lifeless | jamesh: given I don't want to depend on something as complex to rebuild as pygnome, for now I'll used sync apis | 08:15 |
| jamesh | wrapping the async interface involves lots of callback wrappers, so it probably is laziness | 08:15 |
| lifeless | you've seen my ec2 client? | 08:15 |
| jamesh | lifeless: nope. How does it differ to pyboto? | 08:16 |
| jamesh | python-boto, that is. | 08:16 |
| lifeless | jamesh: two ways, its a gui, and its async | 08:16 |
| lifeless | lp:txaws | 08:16 |
| jamesh | it'd be really nice if twisted.defer was part of the Python standard library | 08:17 |
| jamesh | I mean twisted.internet.defer | 08:17 |
| lifeless | yes | 08:17 |
| lifeless | someone should propose it | 08:17 |
| lifeless | I hear people can commit stuff to python | 08:17 |
| jamesh | then it wouldn't be controversial to wrap async APIs like gnome-keyring using deferred objects | 08:17 |
| lifeless | jamesh: I wrote this because I spent 50% more than our monthly cap developing the bzr ec2 test support | 08:18 |
| lifeless | jamesh: and I didn't want to accidentally leave an instance running overnight ;) | 08:18 |
| jamesh | you could just set up a cron job to kill all ec2 instances on the hour. | 08:19 |
| lifeless | kindof expensive | 08:19 |
| lifeless | and nowhere near as useful | 08:19 |
| jamesh | that'd also encourage test suites to take less than an hour to execute | 08:19 |
| lifeless | bzr's is < 2 minutes if you throw enough instances at it :) | 08:19 |
| lifeless | so its lp's | 08:19 |
| lifeless | s/its/is/ | 08:19 |
| jamesh | having an easy API for deferred objects in C would also help | 08:23 |
| jamesh | even if it is just a bunch of PyObject_CallMethod() wrappers | 08:24 |
| lifeless | agreed | 08:26 |
| lifeless | I have one I'm piecing together in libvfs | 08:26 |
| lifeless | igc1: btw, you need to enlarge your 'open data format' stuff a _lot_ - last I read it it looked like handwaving : 'we' have spent a lot of time considering extension points for the core store and not found any that were satisfactory in the general case | 08:50 |
| lifeless | igc1: [and a general mechanism is by definition the general case] | 08:51 |
| igc1 | lifeless: Can you point me to mailing list discussions that I ought to read/re-read? | 08:52 |
| === igc1 is now known as igc | ||
| === bob2_ is now known as bob2 | ||
| === bob2 is now known as Guest49921 | ||
| lifeless | igc: versioned properties discussions right from the start basically | 08:53 |
| lifeless | igc: various challenges exist - consistency, updating, schema, validation, check, reconcile, propogation, merge, | 08:54 |
| lifeless | indexing | 08:54 |
| lifeless | and performance | 08:55 |
| === Guest49921 is now known as bob2 | ||
| lifeless | igc: more broadly, one needs to consider how things will degrade for clients not supporting $extension, and if the answer is 'they do the wrong thing', then a repo with that extended data in it is broken for clients | 08:56 |
| lifeless | which is arguably identical to our current behaviour | 08:56 |
| lifeless | In general terms, I think the question is about 'is it possible' not 'how to make it happen', for a safe extensible format | 08:57 |
| igc | lifeless: it's software - anything is possible :-) :-) | 08:58 |
| igc | lifeless: seriously, I like your list | 08:59 |
| igc | lifeless: I don't expect the core to solve every problem for every type of data | 08:59 |
| igc | lifeless: I do expect it to provide plumbing where it can and delegate things it can't to the plugin/code registering the extended data | 09:00 |
| lifeless | I'd be delighted to make sure fetch calls hooks to let people add data and recieve extended data | 09:00 |
| igc | lifeless: there will be limitations but I don't believe that means we should throw the baby out with the bathwater and say "it can't be done" | 09:01 |
| lifeless | I'm not at all sure that the _storage_ of said data should be in .bzr/repository | 09:01 |
| lifeless | igc: I think there is a different between an extensible store, and hooks allowing plugins to do what they want to alongside core operations | 09:03 |
| lifeless | igc: I argue that there isn't a difference at the user level, but there is a vast difference for the programming and performance implications we face | 09:04 |
| lifeless | we consider very carefully where *our* data goes and what it implies; is it a column store or row store, how long does it take to do X, or Y. | 09:05 |
| lifeless | someone storing a mime type per file could easily add 50% to the raw storage size of inventories | 09:06 |
| lifeless | and writing a general purpose, high performance, tuning-free, self-maintaining database, while extremely interesting, isn't really what we're here to do | 09:06 |
| lifeless | IMO | 09:06 |
| lifeless | I hope I'm making sense | 09:07 |
| igc | lifeless: you are and I agree with most of what you're saying | 09:07 |
| igc | lifeless: but ewe need a better answer than "new format required" when code/a plugin wants a small amount of data managed for it | 09:08 |
| lifeless | igc: I think plugins should maintain their own stores | 09:09 |
| igc | lifeless: it one thing to say "one format only during the life of 2.0" | 09:09 |
| lifeless | in db terms they should get their own shard, and do what they want with it | 09:09 |
| igc | lifeless: it implies though that only people running the development format get to see any data-dependent new features until 3.0 is released | 09:10 |
| lifeless | it comes back to definitions | 09:11 |
| lifeless | I don't think replacing format with 'schema version' makes things better | 09:11 |
| igc | lifeless: which, IMO, means 3.0 is back to "big bang" releasing with lower quality (as a rule) | 09:11 |
| lifeless | if something is -truely- safe to add to the data existing code processes it can be added to an existing format with todays mechanisms | 09:12 |
| lifeless | I think we're trying to cross the chasm at the moment | 09:13 |
| lifeless | and fast incremental releases are giving our non early adopters problems | 09:13 |
| igc | lifeless: but we seem to do that extremely rarely because format bumps are our only instrument for code-data alignment protection | 09:13 |
| igc | lifeless: I think branch dpeendency rules will help here | 09:14 |
| lifeless | we'll be having a sprint | 09:14 |
| lifeless | I am not against achieving safe finer granularity; I'm against making the system more fragile, | 09:16 |
| lifeless | and I think that adding more stores is a better approach than a single 'extensible' store, for a number of reasons | 09:16 |
| lifeless | those above | 09:16 |
| lifeless | plus separation of core and non core data | 09:17 |
| lifeless | see for instance the long desired 'file graph is a cache' one | 09:17 |
| igc | I like the multiple stores approach - it's what I was getting at with the baggage idea | 09:17 |
| lifeless | bzr-search is an example of this | 09:17 |
| lifeless | living breathing working without needing changes to bzr itself | 09:18 |
| igc | lifeless: right, so we need the rules on how to do that better documented and explained | 09:18 |
| lifeless | sure | 09:19 |
| igc | lifeless: I need to head to dinner | 09:19 |
| fullermd | And a lot more hooks, sounds like. | 09:19 |
| igc | I'll copy-and-paste this conversation into the spec so it doesn't get lost | 09:19 |
| lifeless | I sure | 09:20 |
| lifeless | what else | 09:20 |
| lifeless | oh, right - I disagree with one format, no schema changes implying big-bang | 09:20 |
| lifeless | it just means we have more time spent stewing it in beta | 09:20 |
| lifeless | and we should allow for that | 09:21 |
| * igc dinner | 09:24 | |
| === BasicOSX changed the topic of #bzr to: Bazaar version control system | 1.13.2 released 28 April, 2009 | 1.14 released 29 April, 2009 | http://bazaar-vcs.org | http://irclogs.ubuntu.com/ | http://planet.bazaar-vcs.org/ | ||
| fullermd | Yay! | 09:56 |
| * fullermd watches the tarball trickle in from LP at 27 kBps. | 09:56 | |
| Peng_ | BasicOSX: Congrats on the release. :) | 10:04 |
| BasicOSX | ty | 10:04 |
| spiv | BasicOSX: yes, congrats and thanks! | 10:05 |
| davidstrauss | BasicOSX: woo hoo! | 10:05 |
| BasicOSX | now the scary part, merge back to trunk | 10:06 |
| BasicOSX | I need some assistance, "You should also merge (not pull) the release branch into lp:~bzr/bzr/current, so that branch contains the current released code at any time." | 10:07 |
| BasicOSX | I keep getting "Transport operation not possible: readonly transport " | 10:07 |
| BasicOSX | Can someone tell me the command I should be using? Or can verify I still have write access to that branch? | 10:08 |
| spiv | BasicOSX: anyone in the ~bzr team should be able to, I think... | 10:11 |
| spiv | BasicOSX: and you are, so that's a bit odd. You have a checkout or branch of lp:~bzr/bzr/current that you're trying to merge into, and then getting that error when you push/commit that? | 10:12 |
| BasicOSX | yes | 10:12 |
| spiv | Maybe you haven't do "bzr launchpad-login tanner"? Seems a bit unlikely though... | 10:13 |
| BasicOSX | re-trying using 1.14/bzr vs bzr.dev/bzr | 10:14 |
| spiv | I doubt that'll make a difference (I certainly hope it doesn't!) | 10:15 |
| BasicOSX | 4:15am, I'm desperate :-) | 10:15 |
| spiv | Which transport / URL is that error about? | 10:15 |
| BasicOSX | lp:~bzr/bzr/current | 10:16 |
| BasicOSX | I'm going http now | 10:16 |
| BasicOSX | for branch | 10:16 |
| spiv | That's an alias, not a URL, technically... | 10:16 |
| BasicOSX | oh, ok, umm, https+urllib://code.launchpad.net/%7Ebzr/bzr/current/ | 10:16 |
| spiv | It translates to either http://... or bzr+ssh://... depending on if you did lp-login or not. | 10:16 |
| spiv | Ah, right, so you *haven't* done "bzr launchpad-login" then. | 10:17 |
| BasicOSX | I tried to branch with lp, got dreaded AbsentContentFactory | 10:17 |
| BasicOSX | I'm branching via http now, will do login and push next | 10:17 |
| spiv | It doesn't matter how you branch (do whatever works), it's how you push that I'm interested in. | 10:17 |
| BasicOSX | I'd like to branch via lp: seems faster, but routinely fails on most branches on lp | 10:18 |
| spiv | Pretty much any stacked branch that has a merge, yeah :( | 10:18 |
| spiv | Now that 1.13.2 is out that should be less of a problem. | 10:19 |
| BasicOSX | I blame the Republicans | 10:19 |
| BasicOSX | hmph, branch segfaulted! | 10:22 |
| Peng_ | BasicOSX: Use nosmart+lp: to still use bzr+ssh, but avoid AbsentContentFactory. (It uses the VFS, so it's basically equivalent to sftp.) | 10:22 |
| BasicOSX | nice, I'll note that | 10:23 |
| spiv | Peng_: oh, does the nosmart+ prefix survive the translation from lp: to bzr+ssh: ? That's handy. | 10:28 |
| BasicOSX | it worked for me, xfer much faster, still taked long time for inserts :-) | 10:29 |
| Peng_ | spiv: Surprising, huh? I only found out yesterday. | 10:30 |
| BasicOSX | bah | 10:33 |
| BasicOSX | bzr branch nosmart+lp:~bzr/bzr/current | 10:33 |
| BasicOSX | bzr: ERROR: Revision {[('john@arbash-meinel.com-20050711051006-2d11704675600e95',)]} not present in "KnitVersionedFiles(_KnitGraphIndex(CombinedGraphIndex()), <bzrlib.knit._DirectPackAccess object at 0x875cfac>)". | 10:33 |
| Peng_ | I thiiink that's a known bug? Like when you branch --stacked either into a shared repo or a standalone repo? | 10:35 |
| BasicOSX | standalone | 10:36 |
| BasicOSX | going back to http | 10:36 |
| spiv | BasicOSX: that's with bzr.dev? | 10:36 |
| BasicOSX | yes | 10:36 |
| spiv | BasicOSX: ok, known bug, introduced in r4307 | 10:37 |
| spiv | (bug 368418) | 10:37 |
| ubottu | Launchpad bug 368418 in bzr "'Revision X not present': when branching from stacked branch with ghosts" [Critical,In progress] https://launchpad.net/bugs/368418 | 10:37 |
| spiv | Which you should recognise, because you reported it ;) | 10:38 |
| Peng_ | BasicOSX: This is random, but thanks for being the release manager. You've been doing a good job, and you've helped improve the release process for every future RM. | 10:38 |
| spiv | I'm working on it right now. I think I have a functioning fix, just crossing the "t"s and dotting the "i"s. | 10:38 |
| spiv | (I certainly have a branch that works with the ghosts in bzr.dev) | 10:39 |
| spiv | (Not sure why it's taking so long for you to branch though... don't you have a shared repo?) | 10:44 |
| BasicOSX | I always do standalone | 10:44 |
| BasicOSX | most of my work is done in a pbuilder chroot, so pristine enviro | 10:45 |
| spiv | Oh, that's a shame. Perhaps prime it from a more local branch to save time? | 10:45 |
| BasicOSX | I read releasing doc as pull from LP each time, but that might have been my noob eyes first time I read it and dumb brain for not re-thinking it | 10:47 |
| spiv | Yeah, that sounds like something that wastes a fair bit of time for not much gain. | 10:48 |
| davidstrauss | BasicOSX: Fresh 1.14 RPMs for bzr and bzrtools: http://fourkitchens.com/blog/2009/04/29/bazaar-114-rpms-rhel-5-centos-5 | 10:48 |
| BasicOSX | not sure I wanna pollute my ubuntu system with rpms :-P | 10:49 |
| davidstrauss | BasicOSX: They're not for Ubuntu ;-) | 10:49 |
| davidstrauss | BasicOSX: Any objection to linking to my RPMs from the official download page? | 10:52 |
| BasicOSX | I see someone found the 1.15rc1 milestone | 10:52 |
| BasicOSX | davidstrauss: not really my call | 10:53 |
| BasicOSX | It is a wiki tho, so I'm sure the powers that grant edit access could let you maintain your own section | 10:54 |
| spiv | davidstrauss: I'm pretty much done for the day, but if all else fails mail the list to let people know about them. | 10:58 |
| mwhudson | jelmer_: hello, did you get my email? | 12:00 |
| ronny | yo | 12:10 |
| ronny | is there any specific reason why bzr < 1.14 doesnt seem to be installable via easy_install? | 12:10 |
| ronny | lifeless: can you guys make it possible to easy-install older versions of bzr, too? | 12:32 |
| beuno | jam, lifeless, vi, ping? | 14:09 |
| beuno | vila even | 14:09 |
| beuno | bzr just dies with a traceback | 14:10 |
| beuno | and it's still streaming content | 14:10 |
| jam | beuno: what's up? | 14:30 |
| jam | (I'm not 100% here, but I can try to help) | 14:31 |
| beuno | jam, hi | 14:31 |
| beuno | still feeling sick? | 14:31 |
| jam | beuno: yeah | 14:31 |
| jam | mostly a bad cough | 14:31 |
| beuno | :/ | 14:31 |
| beuno | well, I already killed the process | 14:31 |
| beuno | but, bug 369242 | 14:31 |
| ubottu | Launchpad bug 369242 in bzr "bzr keeps streaming content after crashing" [Undecided,New] https://launchpad.net/bugs/369242 | 14:31 |
| beuno | never happened to me | 14:31 |
| beuno | so I wasn't sure how to best debug it | 14:31 |
| jam | beuno: so it sounds like the *local* client is dying, but it isn't killing the ssh process, and the remote server is stil sending data | 14:32 |
| jam | however, I would be surprised if the local ssh client would buffer forever | 14:32 |
| beuno | right, I waited for 5-10 minutes, and it was still chewing up all my bw | 14:32 |
| beuno | maybe it would of died at some point, but it seemed excesive | 14:33 |
| jam | well, 5-10 minutes of your whole bandwidth seems like a lot of data to me | 14:35 |
| jam | I have to wonder where it all went | 14:35 |
| beuno | I was wondering as well :) | 14:36 |
| jam | so.. you have "after crashing" | 14:36 |
| jam | does that mean the bzr process was dead? | 14:36 |
| beuno | yes | 14:36 |
| jam | or just gave a traceback, but was still running? | 14:36 |
| beuno | traceback | 14:36 |
| jam | because after that you say "bzr streaming content" | 14:36 |
| beuno | and I think the process was ssh | 14:36 |
| beuno | may be the wrong wording | 14:37 |
| beuno | jam, either way, bug reported, can be followed up at any time | 14:38 |
| beuno | wanted to see if someone was interested in debugging it "live" | 14:38 |
| beuno | go back to resting :) | 14:38 |
| beuno | thanks | 14:38 |
| rocky | this is odd, trying to easy_install bzr 1.14 in jaunty and getting a problem with not being able to find zlib.h | 15:58 |
| rocky | jelmer: i think you manage the download files for bzr-svn in too many locations... out of sync ;) | 16:06 |
| rocky | does bzr 1.14 work ok on py2.6 or is it still not officially supported? | 16:14 |
| beuno_ | rocky, I think it does just fine? I'm using jaunty with 2.6 with no problems | 16:14 |
| jim6 | Hi - I've just installed bzr, and am having trouble checking out through a http proxy. I have tried ; export http_proxy=www-proxy.<blah>:8080 ; bzr checkout <blah> . I'm getting connection refused. Can anyone help | 16:18 |
| === beuno_ is now known as beuno | ||
| jim6 | ? | 16:18 |
| LarstiQ | jim6: http_proxy=http://ww-proxy.<blah>:8080 | 16:24 |
| LarstiQ | s/ww/www/ | 16:24 |
| jim6 | LarstiQ: tried it, still no joy | 16:24 |
| LarstiQ | jim6: try -Dtransport -Derror and pastebin the traceback? | 16:25 |
| LarstiQ | that is, bzr checkout foo -Derror -Dtransport; | 16:25 |
| jim6 | LarstiQ: http://dpaste.com/39284/ | 16:29 |
| LarstiQ | jim6: does it differ if you try https_proxy instead of http_proxy? | 16:30 |
| LarstiQ | it being a https url you are connecting to | 16:30 |
| * LarstiQ knows very little of proxies, as you can see | 16:30 | |
| LarstiQ | jim6: also, I'm reminded this might be an xmlrpc problem, in which case you could try prepending nosmart_ | 16:31 |
| LarstiQ | nosmart+ | 16:31 |
| LarstiQ | jim6: so that would be `bzr checkout -v -rrevno:630 nosmart+https://launchpad.net/pybindgen` | 16:31 |
| LarstiQ | jim6: alternatively, you could try via bzr+ssh:// instead of http(s) based | 16:32 |
| jim6 | LarstiQ: looks like https_proxy worked >_< | 16:32 |
| jim6 | thanks | 16:32 |
| jim6 | that was pretty obvious once you pointed it out ;) | 16:32 |
| LarstiQ | jim6: ah, maybe you can do me a favour in kind then ;) | 16:33 |
| === dereine[OFF] is now known as dereine | ||
| LarstiQ | the text I'm reading on the relation between confidence intervals and hypothesis testing is _not_ making things clear :/ | 16:33 |
| jim6 | I could give it a go ... ? | 16:34 |
| LarstiQ | jim6: sections 1.7 and 1.8 in http://richtlijn.be/~larstiq/ProbStatII.pdf | 16:36 |
| jim6 | LarstiQ: over my head, sorry :-/ | 16:41 |
| LarstiQ | jim6: no worries, I'll get there eventually. | 16:42 |
| LarstiQ | even if it is by skipping to parts that are less dense ;) | 16:42 |
| jelmer_ | abentley: hi | 16:48 |
| abentley | jelmer_: hi. | 16:48 |
| jelmer_ | abentley: I'm trying out nested trees and noticed some rough edges, ones that aren't covered by your pending patches as far as I can tell. Should I send you an email about these issues or wait? | 16:50 |
| abentley | jelmer_: please send me an email. It might be stuff I haven't thought of. | 16:50 |
| jelmer_ | abentley: ok | 16:51 |
| jelmer_ | abentley: How does bzr know the canonical location of a reference-joined branch? | 17:06 |
| jelmer_ | abentley: (I've used "bzr join --reference <local-branch>" and that doesn't seem to update .bzr/branch/references) | 17:06 |
| abentley | jelmer: It defaults to using the relative path to the tree. | 17:07 |
| abentley | jelmer_: Quite possibly it should record it then. I'm still mulling that issue over. | 17:08 |
| === beuno_ is now known as beuno | ||
| davidstrauss | abentley: It would be immensely useful to join in a way that allows easy merging from the original sources. | 17:09 |
| jelmer_ | davidstrauss: Don't you mean for by-value nested branches? | 17:09 |
| davidstrauss | abentley: (This would require tracking the origins and allowing a batch merge.) | 17:09 |
| abentley | davidstrauss: Okay, are you assuming that the subtree is a checkout/lightweight checkout of the original sources? | 17:09 |
| davidstrauss | abentley: The subtree still needs to allow commits of local changes. | 17:10 |
| fullermd | Oooh, Ikarus is using bzr.... | 17:10 |
| abentley | davidstrauss: So merge in the subtree should still merge from the original sources. | 17:10 |
| davidstrauss | abentley: yes | 17:10 |
| davidstrauss | abentley: This would be for vendor branching | 17:10 |
| abentley | davidstrauss: I mean, it does already. | 17:10 |
| davidstrauss | abentley: It tracks the original branch URLs for merging? | 17:11 |
| LarstiQ | fullermd: which Ikarus? | 17:11 |
| abentley | davidstrauss: bzr branch tracks the original branch URLs for merging. | 17:11 |
| fullermd | LarstiQ: http://www.ikarus-scheme.org/ | 17:11 |
| davidstrauss | abentley: and this is with a normal (non --by-reference) join? | 17:12 |
| abentley | Oh, I misunderstood. | 17:12 |
| davidstrauss | abentley: all the parent branch data is preserved? | 17:12 |
| LarstiQ | fullermd: ah ok, not the Dutch person who'se nick is Ikarus and has a ~10 year shared history with myself and jelmer then ;) | 17:12 |
| abentley | For vendor branches, --by-reference is recommended. | 17:12 |
| davidstrauss | abentley: Is --by-reference stable? | 17:12 |
| abentley | davidstrauss: No | 17:12 |
| fullermd | Probably not :p | 17:12 |
| fullermd | But he probably compiles slower anyway... | 17:13 |
| davidstrauss | abentley: --by-reference doesn't quite join it into the parent tree, right? | 17:13 |
| abentley | davidstrauss: Right. Inside the subtree, bzr will behave as though it's not joined. In the containing tree, bzr will behave as though it is joined. | 17:14 |
| davidstrauss | abentley: Does it do this by preserving the original branch and merely noting the join in the parent tree? | 17:15 |
| abentley | davidstrauss: Right. | 17:15 |
| davidstrauss | abentley: It seems kind of inconsistent and non-atomic to treat the by-reference join differently inside its subtree than outside | 17:17 |
| davidstrauss | abentley: I'd rather just have the normal join and have the branch parents be an array | 17:17 |
| davidstrauss | abentley: and have an option to step through branch parents and merge | 17:18 |
| abentley | davidstrauss: It's a performance win, and it's not just about merge. There should always be a way to treat a subtree as though it was not part of a larger tree. | 17:19 |
| davidstrauss | abentley: ok | 17:19 |
| abentley | davidstrauss: There will probably be a way to force commands to treat it as one large tree. | 17:19 |
| abentley | even in subtrees. | 17:20 |
| davidstrauss | abentley: I'm concerned that the abstraction is just good enough to make the behavior changes related to your working directory confusing | 17:21 |
| davidstrauss | abentley: svn always commits from your w.d. below | 17:21 |
| davidstrauss | abentley: but bzr commits the branch as a whole by default | 17:21 |
| jelmer_ | davidstrauss: The whole point of using a by-reference nested tree as opposed to a by-value nested tree is that you can use it both as part of the whole and separately | 17:22 |
| davidstrauss | abentley: but you'd have to check to see if you're in a subtree first to know the behavior with the proposed by-reference join design | 17:22 |
| abentley | davidstrauss: The idea is that your subtrees are somewhat independent entities, and it makes sense to commit to them individually. | 17:23 |
| LarstiQ | davidstrauss: it might still make sense to make the workflow with by-value nested trees nicer though. | 17:24 |
| abentley | I think that users won't find it hard to remember where the subtrees are, because they will be split at intuitive places. | 17:24 |
| davidstrauss | abentley: Probably true | 17:24 |
| davidstrauss | abentley: Will a subtree understand that it's a subtree, or will the referenced branch be naive of its status? | 17:25 |
| abentley | Naive. | 17:27 |
| abentley | davidstrauss: Note that branches may be used in multiple contexts, sometimes as subtrees. | 17:27 |
| davidstrauss | abentley: So it would therefore be complex to warn the user that their commands are operating on a subtree? | 17:27 |
| abentley | davidstrauss: It would be more expensive, and would involve only trees, not branches. | 17:28 |
| davidstrauss | abentley: That makes sense | 17:28 |
| abentley | But theoretically, you can try to open a containing tree, and then see if there's a tree-reference for the root's file-id. | 17:29 |
| davidstrauss | abentley: Would it be flawed or expensive to always treat trees within trees as nested trees? | 17:30 |
| davidstrauss | abentley: Repo layouts typically only put branches at leaves in the directory structure. | 17:30 |
| abentley | davidstrauss: Opinions vary. | 17:30 |
| LarstiQ | flawed, imo. | 17:30 |
| * jelmer_ agrees; I think it would defeat the whole purpose of having nested trees in the first place | 17:31 | |
| LarstiQ | although you could argue what it means to be a nested tree | 17:31 |
| abentley | davidstrauss: I think that having it done automatically would be bad. Remember that you're normally required to "add" anything. And I think that if users aren't expecting this behavior, they may be unpleasantly surprised. Especially while it's beta. | 17:31 |
| davidstrauss | abentley: Good point, though it means users might be confused whether to use add or join on subtrees. | 17:32 |
| davidstrauss | abentley: Right now, you can do either with very different results that seem, at least superficially, the same. | 17:33 |
| abentley | davidstrauss: At this point, I think maximum specificity is good. When this feature is fully polished, I'd be willing to re-examine supporting "add". | 17:33 |
| abentley | davidstrauss: You can't add a nested tree at present. | 17:35 |
| abentley | davidstrauss: https://pastebin.canonical.com/17020/ | 17:36 |
| abentley | doh | 17:36 |
| abentley | ubottu: !paste | 17:36 |
| ubottu | pastebin is a service to post multiple-lined texts so you don't flood the channel. The Ubuntu pastebin is at http://paste.ubuntu.com (make sure you give us the URL for your paste - see also the channel topic) | 17:36 |
| abentley | davidstrauss: http://paste.ubuntu.com/160792/ | 17:37 |
| davidstrauss | abentley: So adding it fails silently? | 17:37 |
| jelmer_ | abentley: I think bzr shouldn't silently ignore adds in that case though | 17:37 |
| abentley | davidstrauss: yes. | 17:38 |
| abentley | jelmer_: I'm really tired of debating the correct "add" ui :-( | 17:39 |
| davidstrauss | abentley: But silence means success :-P | 17:39 |
| abentley | davidstrauss: No, not to add. | 17:40 |
| abentley | davidstrauss: add tells you what it added. | 17:40 |
| abentley | davidstrauss: So silence is failure. | 17:40 |
| davidstrauss | abentley: Or a no-op | 17:40 |
| davidstrauss | abentley: My assumption as a user would be that there was nothing to add | 17:41 |
| abentley | davidstrauss: That's true. | 17:41 |
| davidstrauss | abentley: Sorry to bring up a debate that you hate, but this sort of stuff totally befuddles most users | 17:42 |
| davidstrauss | abentley: If you can't add a subtree, add should throw a full-on error | 17:42 |
| abentley | http://paste.ubuntu.com/160796/ | 17:42 |
| abentley | davidstrauss: It is interpreted as trying to add files to the subtree. | 17:42 |
| abentley | davidstrauss: Of which there aren't any. | 17:43 |
| jelmer_ | ahh | 17:43 |
| ZuLuuuuuu | Hello, I saw Mercurial is supported on more and more project hosting sites (lastly by Google Code) though I don't know any project hosting site other than Launchpad to support Bazaar. Is implementing support for Bazaar hard or something? Why are project hosting sites support Mercurial but not Bazaar? For example Savannah also has support for Mercurial and not for Bazaar. | 17:44 |
| davidstrauss | abentley: But in your example, the subtree isn't joined, even by reference. | 17:44 |
| abentley | davidstrauss: True. | 17:45 |
| abentley | davidstrauss: Not sure what you're getting at. | 17:45 |
| davidstrauss | abentley: Either subtrees should be always transparently nested or bzr should refuse to recurse into them. | 17:45 |
| abentley | davidstrauss: I'm not sure how the fact that the subtree in my example isn't joined by reference is related to that point. | 17:46 |
| jelmer_ | davidstrauss: you don't have to be in a tree ($CWD) to version files in it | 17:46 |
| davidstrauss | jelmer_: Yes, I understand | 17:46 |
| jelmer_ | ZuLuuuuuu: Bazaar code hosting doesn | 17:47 |
| jelmer_ | ZuLuuuuuu: Bazaar Code hosting will work fine for most situations with simple write access | 17:47 |
| jelmer_ | ZuLuuuuuu: e.g. no need for a smart server to be running | 17:47 |
| davidstrauss | abentley: You're running "add" from cwd for branch/tree foo, but the command is actually using branch/tree bar without any feedback. I would expect bzr to do this if I had joined (by-reference) bar into foo, but not if bar is just in a subdirectory. | 17:48 |
| ZuLuuuuuu | But hosting a project in project hosting site has some advantages | 17:49 |
| ZuLuuuuuu | I would prefer a VCS with more support if I were a new user | 17:49 |
| fullermd | SF does bzr now, doesn't it? | 17:49 |
| abentley | davidstrauss: When you pass a directory location to "bzr add", it always opens the tree containing that directory and adds that directory and its children to it. | 17:49 |
| abentley | davidstrauss: "cd..;bzr add foo" would add files to "foo", for example. | 17:50 |
| davidstrauss | abentley: I've always considered "add" to add its argument to the tree/branch in the cwd, but that's clearly not the case. | 17:51 |
| davidstrauss | :-/ | 17:51 |
| davidstrauss | abentley: The current semantics are troubling if you don't specify any arguments to add. | 17:52 |
| ZuLuuuuuu | fullermd: yes it support bazaar, git, mercurial | 17:52 |
| davidstrauss | abentley: http://paste.ubuntu.com/160802/ | 17:53 |
| davidstrauss | abentley: at least "stat" should show that something's a tree/branch | 17:54 |
| davidstrauss | or maybe not | 17:55 |
| davidstrauss | but it's totally unpredictable that add recurses and performs its add operations on the deepest tree | 17:55 |
| davidstrauss | but commit doesn't unless the sub-trees have been joined | 17:56 |
| abentley | davidstrauss: If you supply a path to commit, you should get the same "deepest-tree" behavior. | 17:56 |
| davidstrauss | abentley: but if i don't supply a path, add and commit have different recursive behavior | 17:57 |
| abentley | davidstrauss: I don't think so. What do you mean? | 17:58 |
| abentley | the deepest-tree behavior is only if you specify a path. | 17:58 |
| davidstrauss | abentley: oh, indeed. hmm. | 17:59 |
| davidstrauss | abentley: Really, this is the only effect I'm trying to avoid: http://paste.ubuntu.com/160810/ | 18:02 |
| abentley | I agree that situation is ugly. | 18:03 |
| abentley | The simplest solution would be to include 'bar' in the list of ignored files. | 18:04 |
| abentley | But I guess that doesn't work because it interprets what you're doing differently. | 18:05 |
| davidstrauss | abentley: Yeah, you can explicitly add ignored items | 18:05 |
| abentley | We have a message in "commit" saying where you're committing. Putting one in "add" might help with "bzr add bar". | 18:06 |
| davidstrauss | abentley: I wouldn't be opposed to dropping join and integrating its functionality into add | 18:08 |
| abentley | davidstrauss: I would be. | 18:08 |
| davidstrauss | abentley: but that would require changing how add works, fundamentally | 18:08 |
| davidstrauss | abentley: A non-reference join is, from a user's perspective, a history-importing add | 18:09 |
| jelmer_ | davidstrauss: That would be a very bad idea imho | 18:19 |
| jelmer_ | davidstrauss: add makes a file versioned, it does not import history | 18:20 |
| jelmer_ | davidstrauss: What you are suggesting would make it import history | 18:20 |
| davidstrauss | jelmer_: Currently, the docs define add as "Add specified files or directories." The distinction between making files versioned and merely joining a subtree with existing versioned files isn't made in the docs. | 18:21 |
| davidstrauss | jelmer_: I'm not arguing we should make add behave the way I describe, I'm just throwing it out there. | 18:22 |
| davidstrauss | jelmer_: Actually, the docs conflict with the behavior I demonstrated: "Therefore simply saying 'bzr add' will version all files that are currently unknown." | 18:23 |
| davidstrauss | jelmer_: Though I guess that is the docs somewhat implying that the files aren't already versioned | 18:24 |
| abentley | davidstrauss: It's previously been proposed that "add" would do "join --reference". | 18:30 |
| pindonga | hi ppl . I am trying to build bzr-1.14, and I keep getting errors while building pyrex stuff... I don't know how to make them pass. I can build the extension using --allow-python-fallback, but when I do a build after that, I lose the prebuilt extension | 18:32 |
| pindonga | how do I manage to build it completely? I am running centos 5 on a x86_64 arch | 18:33 |
| jelmer_ | pindonga: what errors are you getting? | 18:40 |
| pindonga | when building bzr 1.14 using python2.5 setup.py build | 18:41 |
| pindonga | I get 'Cannot build extension "bzrlib._chk_map_pyx"' | 18:42 |
| pindonga | oh... I see the problem | 18:42 |
| pindonga | I wasn't looking right | 18:42 |
| pindonga | I am missing some dev headers (zlib.h) | 18:42 |
| jelmer_ | pindonga: installing the zlib development package should fix that | 18:43 |
| pindonga | yes | 18:43 |
| pindonga | thx | 18:43 |
| Tak | he's like the third person today to ask about zlib.h | 18:51 |
| pindonga | jelmer, it was just the missing lib, thx | 18:54 |
| MattCampbell | Does anyone know what tools are required to build the Bazaar installer for Windows, and where to get the source file(s) specific to that installer? | 19:13 |
| LarstiQ | MattCampbell: if http://bazaar-vcs.org/BzrWin32Installer is not up to date it should be adjusted (but I'll look around for something newer) | 19:17 |
| Ddorda | hello. i want to use bzr with launchpad | 19:41 |
| Ddorda | not sure how to login | 19:41 |
| Ddorda | i did bzr launchpad-login Ddorda | 19:41 |
| Ddorda | and got: | 19:41 |
| Ddorda | bzr: ERROR: https://launchpad.net/%7EDdorda/%2Bsshkeys is permanently redirected to https://launchpad.net/~ddorda/+sshkeys | 19:41 |
| beuno | Ddorda, have you uploaded your ssh key to launchpad? | 19:42 |
| beuno | hrm | 19:42 |
| Ddorda | i did | 19:42 |
| beuno | abentley, any idea why bzr would do that? ^ | 19:42 |
| Ddorda | but i think maybe i sent the worng data to the ssh key? | 19:42 |
| abentley | beuno: Not offhand. | 19:43 |
| abentley | Ddorda: Is your launchpad login actually Ddorda? | 19:43 |
| Ddorda | right | 19:43 |
| LarstiQ | instead of ddorda? (lower case) | 19:44 |
| abentley | Ddorda: because it looks like it's 'ddorda' | 19:44 |
| Ddorda | i will try it | 19:46 |
| Ddorda | it's stuck on "B/s" when i do "ddorda" | 19:47 |
| LarstiQ | Ddorda: it's not done? I'm expecting it to have returned you to the prompt. | 19:49 |
| Ddorda | well, yea | 19:49 |
| Ddorda | it done and write for me "B/s" | 19:50 |
| Ddorda | weird | 19:50 |
| Ddorda | and how do i check if i'm logged in? | 19:50 |
| LarstiQ | Ddorda: `bzr launchpad-login` prints your launchpad login (username) | 19:51 |
| Ddorda | great | 19:52 |
| LarstiQ | Ddorda: I left a comment on bug #321935 about the leftover "B/s" | 19:54 |
| ubottu | Launchpad bug 321935 in bzr "[master] Progress bar leaves artifacts in output" [High,Confirmed] https://launchpad.net/bugs/321935 | 19:54 |
| Ddorda | changed my status to affects me too | 19:55 |
| Ddorda | well thanks for your help :D | 20:07 |
| jelmer_ | Tak: I think there was somebody working on noting the zlib dependency more prominently in NEWS | 20:35 |
| beuno | mwhudson, feeling like a new release of Loggerhead? | 20:45 |
| mwhudson | jelmer_: hi! | 20:45 |
| jelmer_ | mwhudson: Hi! | 20:45 |
| mwhudson | beuno: mmm, yes, probably | 20:45 |
| mwhudson | jelmer_: did you get my email? | 20:46 |
| jelmer_ | mwhudson: Yep | 20:46 |
| jelmer_ | mwhudson: I just got back from two weeks of travel so slowly catching up, expect a reply later tonight | 20:46 |
| mwhudson | jelmer_: ok, great | 20:46 |
| beuno | mwhudson, is there anything specific you want to hold off for? | 20:46 |
| beuno | or should I start the machinery on the weekend? | 20:46 |
| beuno | Peng? | 20:46 |
| mwhudson | beuno: i'm not really sure, i can't think of anything | 20:47 |
| jelmer_ | beuno: Is start-loggerhead gone yet ? >-) | 20:47 |
| mwhudson | beuno: perhaps scan the open bug list | 20:47 |
| mwhudson | jelmer_: heh, no :/ | 20:47 |
| beuno | jelmer_, no :( | 20:47 |
| beuno | and it shouldn't be too hard to get rid of it | 20:47 |
| mwhudson | beuno: i would like to wait a few days after 2.2.4 to see if the latest version helps much on launchpad | 20:47 |
| beuno | I hate that I've hit a new record of "have no time" | 20:47 |
| mwhudson | beuno: we should decide what version of bzr we target, test against that and rip out some of our compatibility code | 20:48 |
| beuno | mwhudson, 1.14 | 20:48 |
| beuno | 1.13 was a bad one :) | 20:48 |
| beuno | would we break with previous versions? | 20:48 |
| beuno | 1.13.2 is on the release PPA though | 20:49 |
| mwhudson | beuno: well, i don't think we _probably_ mostly work back to 1.3 or something now | 20:49 |
| beuno | so I don't know... | 20:49 |
| mwhudson | uh! | 20:49 |
| mwhudson | s/don't// | 20:49 |
| beuno | 1.13 is is | 20:49 |
| mwhudson | fair enough | 20:49 |
| beuno | anything under that, unsupported | 20:49 |
| mwhudson | there's definitely some crap we can remove | 20:49 |
| beuno | yeah | 20:50 |
| beuno | I added some of that :) | 20:50 |
| mwhudson | the "changes touching file" code, at least | 20:50 |
| mwhudson | right :) | 20:50 |
| beuno | was a fun first week of work | 20:50 |
| LarstiQ | yay fun | 20:50 |
| beuno | heya LarstiQ | 20:51 |
| beuno | I realized today | 20:51 |
| beuno | I can't bug you anymore about nested trees :) | 20:51 |
| beuno | after maybe 2 years | 20:51 |
| beuno | big change for me! | 20:51 |
| jdobrien | Anyone want to tackle this project killer: [] | 20:57 |
| jdobrien | Command failed! | 20:57 |
| jdobrien | All lines of log output:["PQM Cannot merge between different VCSsystems. 'bzr+ssh://bazaar.ubunet/~jdobrien/ubunet/sms-valdate-new'(pqm.Baz1_1Handler) and 'bzr+ssh://bazaar.ubunet/~ubunet-pqm-team/ubunet/trunk'(pqm.Bazaar2Handler) are different."] | 20:57 |
| LarstiQ | jdobrien: why is it using Baz1 handler? | 20:58 |
| beuno | lifeless, up yet? ^ | 20:58 |
| beuno | abentley? ^ | 20:58 |
| jdobrien | LarstiQ: I am not | 20:59 |
| Ddorda1 | there is anyway to check if there's any updates automaticly? | 20:59 |
| jdobrien | bzr115dev | 20:59 |
| abentley | beuno: The baz1 handler is used if no bazaar branch can be opened. | 20:59 |
| jdobrien | the branch exists | 20:59 |
| abentley | jdobrien: What format is it in? | 21:00 |
| jdobrien | 1.9 | 21:00 |
| abentley | Do its revisions show up in the LP UI? | 21:00 |
| * jdobrien checks | 21:00 | |
| LarstiQ | Ddorda1: I'm not sure what you mean with automatically, are you thinking of something like `bzr missing` ? | 21:01 |
| abentley | jdobrien: Are you sure bazaar.ubunet is a real domain? | 21:01 |
| jdobrien | abentley: I've landed 4 branches using the same command (only branch name different) today | 21:01 |
| abentley | jdobrien: But the branch name appears to be significant here. | 21:02 |
| Ddorda1 | i mean if there's any way to announce me when there is an update | 21:02 |
| Ddorda1 | to a bzr | 21:03 |
| jdobrien | hmm | 21:03 |
| jdobrien | abentley: I see version history in lp | 21:04 |
| abentley | jdobrien: Are you sure that branch name is right? bazaar.ubunet does not look like a real domain. | 21:05 |
| jdobrien | abentley: what is it that appears incorrect? | 21:05 |
| abentley | bazaar.ubunet | 21:05 |
| jdobrien | abentley: it is correct...PQM had it in it's ssh config | 21:08 |
| jdobrien | abentley: we are having issues with developers using different version of bzr on our project | 21:08 |
| jdobrien | abentley: for example, some have had to use nosmart+ to pull branches | 21:09 |
| === Ddorda1 is now known as Ddorda | ||
| abentley | jdobrien: What URL are you using to look at the LP history? | 21:09 |
| LarstiQ | Ddorda1: the bazaar-announce mailing list gets mails for release candidates and final releases, as well as mail for bzrtools and others. | 21:09 |
| LarstiQ | abentley: https://code.edge.launchpad.net/ubunet I suppose | 21:10 |
| jdobrien | abentley: https://bazaar.launchpad.net/~jdobrien/ubunet/sms-validate-new/changes/1271?start_revid=1271 | 21:10 |
| Ddorda | abentley: and where can i subscribe to this? | 21:11 |
| jdobrien | abentley: it is a private project | 21:11 |
| LarstiQ | Ddorda: https://lists.ubuntu.com/mailman/listinfo/bazaar-announce | 21:12 |
| abentley | jdobrien: given that it's hosted on Launchpad, I would recommend using its launchpad location. But another problem is that you omitted the 'i' in validate. | 21:12 |
| jdobrien | abentley: sorry to have wasted your time :-) | 21:13 |
| Ddorda | if i change something in the code, does the bzr know how to edit the file without removing what i change? | 21:14 |
| Ddorda | LarstiQ: but this will announce me when there's a new release of bazaar, no? | 21:15 |
| Ddorda | i want to know if there's a option the the bzr will announce me about a project code update (not the bzr) | 21:15 |
| LarstiQ | Ddorda: if you bzr pull it will merge the new file contents with your local changes | 21:16 |
| LarstiQ | Ddorda: that mailing list is low traffic, only for new releases of bzr related software in practice | 21:16 |
| Ddorda | "bzr pull" you say? | 21:17 |
| LarstiQ | Ddorda: if that is not what you meant with `bzr know how to edit the file` I do not know what you had in mind | 21:18 |
| Ddorda | okay. thanks | 21:18 |
| jdobrien | statik: we have a crap load of people with dead status | 21:20 |
| LarstiQ | jdobrien: swine flu? | 21:20 |
| jdobrien | dang wrong window | 21:21 |
| jdobrien | channel | 21:21 |
| jdobrien | LarstiQ: :) | 21:21 |
| jdobrien | i need to stop working 18 hour days | 21:21 |
| mwhudson | spiv: have you fixed bzr.dev yet? | 21:58 |
| === dereine is now known as dereine[OFF] | ||
| === dereine[OFF] is now known as dereine | ||
| BasicOSX | API mismatch is my fault | 22:10 |
| abentley | BasicOSX: Are you bob tanner? | 22:15 |
| BasicOSX | yes | 22:15 |
| abentley | BasicOSX: Okay, correction to my email, 1.14 is *probably* the right setting. lifeless probably has a clearer idea. | 22:16 |
| beuno | BasicOSX, rockin' job at release management, btw :) | 22:16 |
| BasicOSX | beuno: thanks | 22:17 |
| BasicOSX | abentley: I'll wait for clarification on it and will update release docs | 22:17 |
| abentley | BasicOSX: The question is just what kind of API change makes it incompatible. I miss the old API breaks section. That made it clear whether API compatibility had been broken. | 22:19 |
| BasicOSX | Compatibility Breaks section does not include API breaks? | 22:20 |
| BasicOSX | I see in 1.14 API Changes section, but I would +1 your RFC for API breaks section :-) | 22:21 |
| BasicOSX | Would make RM job easier | 22:22 |
| abentley | BasicOSX: then again, bzr 1.14 requires Branch.open implementations to accept an "ignore_fallbacks" parameter, and that's not even mentioned in API changes. | 22:24 |
| === spm_ is now known as spm | ||
| === jelmer_ is now known as jelmer | ||
| epsilon_0 | i use bzr all the time with LP, and this morning i got this error when trying to bzr push: | 22:54 |
| epsilon_0 | Socket exception: Connection reset by peer (10054) | 22:54 |
| epsilon_0 | bzr: ERROR: Unable to connect to SSH host bazaar.launchpad.net; (10054, 'Connection reset by peer') | 22:54 |
| beuno | epsilon_0, did you retry? | 22:55 |
| epsilon_0 | yes | 22:55 |
| epsilon_0 | 4 times | 22:55 |
| beuno | epsilon_0, can you try by adding the -Dhpss flag? | 22:56 |
| epsilon_0 | whay does it do? | 22:56 |
| epsilon_0 | *what | 22:56 |
| beuno | epsilon_0, it's a debug flag | 22:56 |
| beuno | that will give us more information | 22:56 |
| epsilon_0 | ok | 22:57 |
| epsilon_0 | one second | 22:57 |
| epsilon_0 | says connected | 22:58 |
| epsilon_0 | then halts | 22:58 |
| epsilon_0 | now im waitin | 22:58 |
| beuno | epsilon_0, ~/.bzr.log | 22:58 |
| beuno | will have a lot of information | 22:58 |
| epsilon_0 | and in windows? | 22:59 |
| beuno | uhm | 23:00 |
| beuno | I don't know :) | 23:00 |
| epsilon_0 | bzr: ERROR: Unable to connect to SSH host bazaar.launchpad.net; (10054, 'Connection reset by peer') | 23:00 |
| epsilon_0 | HPSS calls: 1 <bzrlib.smart.medium.SmartSSHClientMedium object at 0x017EE5F0> | 23:00 |
| epsilon_0 | ill try to find .bzr | 23:00 |
| thumper | epsilon_0: what else has changed on your machine? | 23:01 |
| epsilon_0 | ohh.. now i got u... .bzr in the local project dir | 23:01 |
| epsilon_0 | hm. i guess i didnt, | 23:02 |
| epsilon_0 | i can't find .bzr | 23:02 |
| garyvdm | epsilon_0: .bzr.log is in My Documents on windows | 23:03 |
| epsilon_0 | ok | 23:03 |
| epsilon_0 | what do u want me to post | 23:03 |
| beuno | epsilon_0, can you pastebin the last 20 lines? | 23:04 |
| epsilon_0 | ok | 23:06 |
| epsilon_0 | http://cl1p.net/i_want_bzr_back/ | 23:07 |
| beuno | interesting... | 23:08 |
| beuno | lifeless, spiv, any ideas ^ | 23:08 |
| epsilon_0 | guys, i have to go, will u be around here tomorrow?\ | 23:10 |
| beuno | epsilon_0, sure | 23:10 |
| beuno | you could file a bug | 23:10 |
| beuno | with .bzr.log attached | 23:10 |
| epsilon_0 | : ( | 23:10 |
| epsilon_0 | so i can't commit my project until the bug is fixed? | 23:10 |
| garyvdm | epsilon_0: please pastebin the whole file. I don't think the bit you pasted is relevant | 23:11 |
| epsilon_0 | ok | 23:11 |
| garyvdm | beuno: The log bit there is all from tbzr. | 23:12 |
| beuno | garyvdm, ah | 23:12 |
| beuno | :) | 23:12 |
| epsilon_0 | on sec | 23:14 |
| epsilon_0 | http://download.cl1p.net/i_want_bzr_back/?t=382895686&FILE=46755 | 23:14 |
| epsilon_0 | there | 23:15 |
| spiv | beuno, epsilon_0: "connection reset by peer" suggests that SSH is the problem, not, bzr. | 23:15 |
| beuno | hi spiv | 23:15 |
| epsilon_0 | what could it be, i didn't changed a thing | 23:16 |
| garyvdm | is pant? running | 23:16 |
| epsilon_0 | pant? | 23:17 |
| garyvdm | can't remember what it's called | 23:17 |
| epsilon_0 | lol | 23:17 |
| epsilon_0 | pageant | 23:17 |
| garyvdm | thats it | 23:17 |
| spiv | epsilon_0: I see from the error code (10054) that you're on windows... how do you have ssh configured? | 23:17 |
| epsilon_0 | as usual with putty | 23:18 |
| epsilon_0 | its not the first time i commit, i commited 30 times before | 23:18 |
| spiv | Huh, that traceback in the logfile suggests it's trying to use paramiko, not putty. | 23:18 |
| epsilon_0 | paramiko, i dont know what that it | 23:19 |
| epsilon_0 | bzr might me trying to use it :) not me | 23:19 |
| spiv | :) | 23:19 |
| spiv | epsilon_0: bzr uses putty if it can run 'plink -V' successfully. | 23:20 |
| spiv | epsilon_0: if it can't, it will be falling back to putty. I suspect a problem with your %PATH% | 23:20 |
| epsilon_0 | hmm | 23:21 |
| spiv | You can set the BZR_SSH environment variable to 'plink' to force it to try use it, but if the autodetection can't find plink then that probably won't help. | 23:22 |
| epsilon_0 | plink is not recgninzed | 23:22 |
| epsilon_0 | should i add it to path? | 23:22 |
| spiv | epsilon_0: yes, I think so. I'm not an expert on configuring Windows though... | 23:23 |
| spiv | mwhudson: no, I haven't. Subscribe to the bug report :P | 23:23 |
| epsilon_0 | oh | 23:24 |
| epsilon_0 | i found the problem | 23:24 |
| epsilon_0 | it seems the bzr installation on Windows adds a shortcut called "start bzr in command prompt" | 23:25 |
| mwhudson | spiv: pfft | 23:25 |
| epsilon_0 | which opens the shell with different env. vars. | 23:25 |
| epsilon_0 | i normally didnt use it | 23:26 |
| spiv | epsilon_0: ah. | 23:26 |
| epsilon_0 | i did use it to open the shell this time | 23:26 |
| epsilon_0 | hmm, now i get somehthing else | 23:27 |
| epsilon_0 | but i think i can handle this on my on from here | 23:28 |
| epsilon_0 | thanks guys | 23:28 |
| === dereine is now known as dereine[OFF] | ||
| awilkins | putting plink on the path is helpful | 23:53 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!