| lifeless | I hope so :P | 00:00 |
|---|---|---|
| jml | hello | 00:05 |
| jml | I'm going to actually try to reproduce the problem with the steps I outlined. | 00:05 |
| jml | and then probably re-assign the bug to launchpad-code, and then trace what init_ex does on the server side. | 00:06 |
| lifeless | so | 00:08 |
| lifeless | init_ex is designed to do as much initialisation as the current logic then in bzr.dev permitted to be made unconditional or conditional on constant parameters | 00:09 |
| lifeless | and returns many results | 00:09 |
| mwhudson | jml: cool | 00:11 |
| lifeless | one way to do this would be to write an acceptance test for pushing to default stacked | 00:11 |
| jml | lifeless: that's definitely something we plan to do. | 00:12 |
| mwhudson | i thought we had such a thing | 00:15 |
| jml | mwhudson: I don't think we do. | 00:15 |
| mwhudson | oh right | 00:15 |
| mwhudson | we have puller tests to do with stacking | 00:15 |
| lifeless | I think if you did, it would have broken | 00:15 |
| mwhudson | "oops" | 00:16 |
| lifeless | or is itself broken | 00:16 |
| mwhudson | lifeless: right, i was going on the "we have a broken test" theory | 00:16 |
| mwhudson | i was wrong | 00:16 |
| vxnick | hi guys - I'm trying to push an update to launchpad but bzr is saying I need to merge then push (which I do) but to no avail | 00:19 |
| spiv | vxnick: did you commit the merge? | 00:20 |
| vxnick | yep | 00:20 |
| vxnick | I uncommitted the previous revision however | 00:20 |
| vxnick | because I put some bits in the wrong place so wanted to have them show under that revision | 00:20 |
| vxnick | rahter than a new one | 00:20 |
| spiv | vxnick: hmm. Are you sure you've merged from the branch you are trying to push to? | 00:21 |
| vxnick | 100% sure | 00:21 |
| lifeless | vxnick: then you have to push --overwrite, because uncommit doesn't propogate automatically | 00:21 |
| vxnick | ah thanks | 00:21 |
| lifeless | vxnick: because its a form of history editing | 00:21 |
| vxnick | so I guess uncommit isn't ideal for push/pull scenarios? | 00:21 |
| lifeless | note that if you're pushing to a branch other people can push to, you may end up removing their changes by doing this | 00:21 |
| lifeless | vxnick: rule of thumb - never uncommit after you have pushed | 00:21 |
| vxnick | noted, it's just me at the moment | 00:21 |
| vxnick | thanks | 00:22 |
| lifeless | vxnick: you can if you need to, but understand the mechanics ;) | 00:22 |
| vxnick | yeah, I'll double-check next time :) | 00:22 |
| vxnick | push --overwrite did the trick, many thanks guys | 00:23 |
| vxnick | another one to add to my repertoire ;) | 00:24 |
| pygi | mwhudson: thanks for the response | 00:33 |
| pygi | I pretty much think that locations.conf should be ok, yes | 00:33 |
| mwhudson | pygi: cool | 00:37 |
| poolie | lifeless: wrt rich-root and similar changes, will people be able to bzr branch their existing launchpad un-landed branches into an upgraded repo? | 00:37 |
| poolie | or will they need to upgrade all of them individually? | 00:38 |
| jml | james_w: I notice the bzr-nightly-ppa for hardy doesn't have 1.16dev | 00:38 |
| lifeless | poolie: I think it is important that they check and reconcile all their revisions | 00:38 |
| jml | lifeless: wait, pebkac | 00:38 |
| jml | double pebkac! | 00:38 |
| lifeless | its possible for revisions in different branches to interact badly with some combinations of ghsots | 00:38 |
| lifeless | I'd *like* to be able to say 'run check -r submit:' and if that is clean branch it into your shared repo | 00:39 |
| lifeless | but current check can't do that because it checks everything | 00:39 |
| lifeless | poolie: certainly they can run the commands to branch it into an upgraded repo, but that says nothing about data integrity | 00:39 |
| lifeless | poolie: did you want me to pop over [say around lunch till 5ish] ? | 00:40 |
| poolie | lifeless: ok, i have to go out to a movie at about 5 though | 00:43 |
| lifeless | I have this meeting in the city @6 so that suites me fine | 00:43 |
| lifeless | I'll tell him to bring it forward a bit | 00:43 |
| poolie | lifeless: you asked yesterday if i'd read some advisory | 00:54 |
| poolie | which one was that? | 00:54 |
| lifeless | the one I drafted about the smart server problems. I wasn't asking if you'd read it, but if you had any more edits to make before we sent it to bzr-announce | 00:54 |
| jml | Errors were encountered while processing: | 00:58 |
| jml | /var/cache/apt/archives/bzr_1.15+4422+116~08.04_i386.deb | 00:58 |
| jml | E: Sub-process /usr/bin/dpkg returned an error code (1) | 00:58 |
| jml | :( | 00:58 |
| lifeless | \o/ | 00:59 |
| poolie | lifeless: no more changes, please send it | 01:01 |
| poolie | jml, did you get an actual error? | 01:01 |
| poolie | lifeless: could you send a draft advice on how launchpad devs should upgrade? | 01:02 |
| poolie | spiv, pushing a new branch to launchpad was HPSS calls: 61 (23 vfs) SmartSSHClientMedium(connected=False, username=u'mbp', host='bazaar.launchpad.net', port=None) | 01:02 |
| poolie | seems surprisingly bad | 01:02 |
| jml | poolie: no. | 01:02 |
| jml | that's it. | 01:02 |
| lifeless | poolie: [lp devs] I've been working towards that prior to allhands | 01:02 |
| lifeless | poolie: my opinion is that its not ready for lp devs. Its still way to fragile a process and I think all we'd learn is the fragility. | 01:03 |
| lifeless | poolie: I will refresh the doc though | 01:03 |
| lifeless | poolie: and we can discuss further after that | 01:03 |
| mwhudson | poolie: launchpad is still 1.14 | 01:03 |
| lifeless | poolie: with 1.15 and no tags it should be 0 vfs | 01:04 |
| lifeless | poolie: wth 1.14 and tags, 9 vfs calls. | 01:04 |
| lifeless | sorry, with 1.15 and tags, 9 vfs calls | 01:04 |
| poolie | k | 01:04 |
| lifeless | but as mwhudson says, its still 1.14 on the server | 01:04 |
| lifeless | jml is looking into a critical upgrade bug for going to 1.15 | 01:05 |
| spiv | poolie: what lifeless said | 01:05 |
| spiv | I think it might be good if the -Dhpss output mentioned if any UnknownSmartMethod were seen, to make the new client/older server case less alarming. | 01:07 |
| poolie | spiv, good point | 01:08 |
| SamB | I think you guys should make the bzr-announce list more prominent | 01:08 |
| vxnick | I think I know the answer to this, but is there anyway I can branch (or checkout) a single file from a repo? The repo itself only contains this one file | 01:08 |
| lifeless | bzr cat | 01:08 |
| lifeless | to get the contents | 01:08 |
| lifeless | or bzr branch to branch the branch | 01:08 |
| SamB | I barely managed to find the URL to sign up when I was *looking* for it just now | 01:09 |
| SamB | and that was only because I heard you talking about sending something to it! | 01:09 |
| poolie | jml: installing that package worked for me | 01:13 |
| jml | poolie: on hardy? | 01:13 |
| poolie | on jaunty | 01:14 |
| jml | ok. | 01:14 |
| jml | I'll install from source then. | 01:16 |
| jml | ok, now I'm perplexed. | 01:23 |
| jml | http://paste.ubuntu.com/192055/ | 01:23 |
| jml | ahhh. plugins. | 01:24 |
| poolie | the traceback should say | 01:27 |
| poolie | it's kind of a bug that the message didn't | 01:28 |
| jml | yeah. | 01:31 |
| jml | Anyway, I've now successfully reproduced bug 385132 without involving Launchpad. | 01:31 |
| ubottu | Launchpad bug 385132 in bzr "bzr uses inaccessible, internal URL when pushing to server with host-relative default_stack_on url" [Critical,Triaged] https://launchpad.net/bugs/385132 | 01:31 |
| jml | lifeless: you said there were tests for this in bzrlib -- where might I find them? | 01:37 |
| lifeless | for the specific behaviour of honouring default policy | 01:37 |
| lifeless | bzrlib.tests.blackbox.test_push.*acceptance has one | 01:37 |
| lifeless | jml: ok, thanks for showing it w/out lp | 01:38 |
| poolie | lifeless: quick call? | 01:38 |
| jml | np. | 01:38 |
| lifeless | poolie: sure | 01:38 |
| jml | grrr. bzrtools out of date :( | 02:05 |
| === vxnick is now known as vxnick_away | ||
| jml | lifeless: I've just added a patch & linked a branch that add tests that reproduce the bug. | 02:10 |
| jml | Launchpad bug mail is being slow today. :( | 02:12 |
| lifeless | bug 385132? | 02:19 |
| ubottu | Launchpad bug 385132 in bzr "bzr uses inaccessible, internal URL when pushing to server with host-relative default_stack_on url" [Critical,Triaged] https://launchpad.net/bugs/385132 | 02:19 |
| jml | yeah. | 02:23 |
| jml | lifeless: are you planning on fixing bug 385132 today? | 02:41 |
| ubottu | Launchpad bug 385132 in bzr "bzr uses inaccessible, internal URL when pushing to server with host-relative default_stack_on url" [Critical,Triaged] https://launchpad.net/bugs/385132 | 02:41 |
| lifeless | jml: maybe | 02:41 |
| lifeless | jml: its clearly very important | 02:41 |
| lifeless | jml: however I have nothing on my plate that isn't. | 02:41 |
| jml | lifeless: should I ask someone else? (spiv? myself?) | 02:43 |
| spiv | jml: I'd be happy to look at that after I'm done with bug 380314 | 02:48 |
| ubottu | Launchpad bug 380314 in bzr "Branch.revision_history RPC fails on a stacked branch" [High,Confirmed] https://launchpad.net/bugs/380314 | 02:48 |
| jml | spiv: cool, thanks. | 02:48 |
| spiv | jml: which realistically means "tomorrow" | 02:48 |
| jml | spiv: :( | 02:48 |
| spiv | (I might be wrong, but I'd rather surprise than disappoint) | 02:49 |
| lifeless | jml: I suggest digging into it yourself | 02:50 |
| jml | yeah, that sounds like a winner. I'll do some RM work first though. | 02:52 |
| mwhudson | do we have any idea which change introduced the regression? | 02:53 |
| lifeless | ping or ring at anypoint if you need assistance understandin the intent vs actuality | 02:53 |
| lifeless | mwhudson: bugger, I was slack in the docstring, didn't mention the version | 02:54 |
| mwhudson | lifeless: ? | 02:55 |
| lifeless | I think its just the new verb not being completely correct rather than a regression | 02:55 |
| lifeless | type object 'EventsCodes' has no attribute 'IN_MOVED_TO' | 02:56 |
| lifeless | funky | 02:56 |
| mwhudson | ah | 02:56 |
| mwhudson | i guess that's good | 02:56 |
| lifeless | landed in 4304 | 02:58 |
| lifeless | -> poolies | 03:19 |
| poolie | lifeless: i don't find your rfc about log very compelling either way | 03:26 |
| poolie | lifeless: want a lift? i wouldn't mind leaving the house... | 03:26 |
| === vk5foss is now known as Bambi_BOFH | ||
| === Bambi_BOFH is now known as vk5foss | ||
| === Kamping_Kaiser is now known as `6og | ||
| igc | hi all | 04:36 |
| jml | igc: hello | 04:39 |
| * jml dons the trousers of release management | 04:39 | |
| jml | igc: how's bug 362030 looking? | 04:40 |
| ubottu | Launchpad bug 362030 in bzr "files whose content changed after EOL filtering erroneously marked as modified" [High,In progress] https://launchpad.net/bugs/362030 | 04:40 |
| poolie | jml nethack mode on :) | 04:41 |
| igc | jml: I'm completing the tests now | 04:41 |
| * poolie heads to the couch | 04:41 | |
| poolie | hello igc | 04:41 |
| igc | hi poolie | 04:41 |
| igc | poolie: late start today sorry - needed some sleep | 04:41 |
| jml | igc: cool. :) | 04:41 |
| jml | poolie: you still planning on doing bug 385191 for 1.16? | 04:42 |
| ubottu | Launchpad bug 385191 in bzr-gtk "removal of ProgressBarStack has broken bzr-gtk" [Critical,Confirmed] https://launchpad.net/bugs/385191 | 04:42 |
| fullermd | igc: With that fix done, is all the filtering stuff "expected" to DTRT? | 04:43 |
| poolie | igc, no problem | 04:46 |
| poolie | jml, iirc vila said that it's purely a bzr-gtk bug because it's been deprecated for a while | 04:47 |
| poolie | so i wasn't going to do anything else on it | 04:47 |
| jml | poolie: ok, I'll mark it as Invalid then? | 04:47 |
| poolie | oh i thought he did | 04:48 |
| jml | sounds like a "yes" to me :) | 04:48 |
| igc | fullermd: branch-specific rules are still outstanding. Otherwise, yes. | 04:51 |
| jml | bzr's policy is still to say "fix released" when a fix lands on trunk, right? | 04:52 |
| poolie | yes | 04:52 |
| fullermd | igc: 'k. Last time I fiddled with it, I ran into so many oh-but's that I just gave up, but it seemed like most of them were at least known and at best in-progress. | 04:56 |
| fullermd | igc: So, cool. I'll try fiddling with it again as soon as I get out from under the deluge currently innundating me. Expect an email from me in, I dunno, 50 years or so ;) | 04:56 |
| igc | fullermd: thanks. I wouldn't bother too much before 1.16 | 04:57 |
| fullermd | Well, I'd never bother with a release. That's what bzr.dev is for ;p | 04:57 |
| lifeless | jml: is it the value for final_stack or final_stack_pwd that are wrong? | 04:58 |
| jml | lifeless: wrt bug 385132? Whatever the second-last value in the returned tuple is, that's the one that's wrong. | 04:59 |
| ubottu | Launchpad bug 385132 in bzr "bzr uses inaccessible, internal URL when pushing to server with host-relative default_stack_on url" [Critical,Triaged] https://launchpad.net/bugs/385132 | 04:59 |
| lifeless | thats final_stack_pwd | 05:01 |
| lifeless | it should be a relpath, I think, for our cases | 05:01 |
| lifeless | there are unit tests for this api | 05:02 |
| lifeless | in bzrlib.tests.bzrdir_implementations (or perhaps per_bzrdir).test_bzrdir | 05:02 |
| jml | lifeless: thanks, that helps. | 05:03 |
| jml | I'm looking at http://bundlebuggy.aaronbentley.com/project/bzr/request/%3Ch06a8r%24v7c%241%40ger.gmane.org%3E | 05:08 |
| jml | and http://bundlebuggy.aaronbentley.com/project/bzr/request/%3Ch06a8r%24v7c%241%40ger.gmane.org%3E | 05:08 |
| jml | they look like the same patch to me -- should I merge the first one into bzr.dev? | 05:09 |
| BasicOSX | Could someone QA the 1.15.1 tar and zip at ftp://ftp.real-time.com/pub/bzr/? I am gun-shy and want 2nd set of eyes making sure the pyrex-ified files are in there. | 05:23 |
| jml | poolie: sorry, I think there's been some bug collision on bug 385191. | 05:23 |
| ubottu | Launchpad bug 385191 in bzr-gtk "removal of ProgressBarStack has broken bzr-gtk" [Critical,Confirmed] https://launchpad.net/bugs/385191 | 05:23 |
| jml | BasicOSX: sure, I'll get to that now | 05:23 |
| poolie | jml, ok, but it looks like violent agreement? :) | 05:28 |
| jml | poolie: ok, so you just accidentally assigned it to yourself & the 1.16 milestone? | 05:29 |
| jml | poolie: if so, great. :) | 05:29 |
| jml | BasicOSX: in the tarball, there's no C file corresponding to ./bzrlib/_walkdirs_win32.pyx | 05:29 |
| poolie | jml, i don't know how that happened | 05:30 |
| poolie | i did not click it | 05:30 |
| poolie | is launchpad bug i think | 05:30 |
| BasicOSX | I followed the release procedure to the letter -and- a make does it's all built | 05:30 |
| jml | BasicOSX: same in the zip. | 05:31 |
| BasicOSX | but I do see ./bzrlib/_walkdirs_win32.pyx | 05:31 |
| fullermd | That file isn't pyrexified for me either on the standard make. | 05:31 |
| BasicOSX | bug in make disst? | 05:31 |
| jml | BasicOSX: I'm bumping hard against the walls of my ignorance here. | 05:31 |
| fullermd | Never been built on any previous releases that I can see either. | 05:32 |
| fullermd | (so it's not a regression, but or not) | 05:32 |
| fullermd | Presumably it would only matter for somebody building for win32 directly from the tarball... | 05:32 |
| BasicOSX | make dist does not build it | 05:32 |
| BasicOSX | ie, make dist on linux | 05:33 |
| mwhudson | i think it would only get c-ified on win32 | 05:33 |
| mwhudson | looking at setup.py | 05:33 |
| poolie | <jml> "your RM thinks..." <-- nice one | 05:34 |
| poolie | in expression and sentiment | 05:34 |
| BasicOSX | I was under the impression that things goe pyrex-ified on install, but the last release went out with none and it caused problem | 05:34 |
| BasicOSX | engrish spoken here also | 05:34 |
| jml | BasicOSX: I think it's perfectly OK for a 1.15.1 release. | 05:34 |
| poolie | BasicOSX: the thing is we'd rather assume the RM has pyrex even if the installer doesn't | 05:35 |
| BasicOSX | poolie: _walkdirs_win32.pyx not in tar or zip when build in linux ok? | 05:35 |
| jml | BasicOSX: given that it's not a regression. | 05:35 |
| jml | (but poolie has the say here, I think) | 05:35 |
| poolie | the .pyx file is the original source, it must be present | 05:35 |
| poolie | um | 05:35 |
| jml | BasicOSX: it's the C file that's missing. | 05:35 |
| BasicOSX | oh, sorry miss understood | 05:36 |
| poolie | mwhudson: you may be right, but i thought we could generate the C files regardless of platform | 05:36 |
| poolie | however i think it's more ok if they're missing | 05:36 |
| poolie | on windows | 05:36 |
| mwhudson | poolie: you probably _can_ | 05:36 |
| poolie | um | 05:36 |
| mwhudson | poolie: but in this case, we certainly don' | 05:37 |
| mwhudson | t | 05:37 |
| poolie | my impression is that on unix there will be many people with compilers but not necessarily pyrex | 05:37 |
| poolie | on windows, probably only hardcore people will be compiling and it's reasonable for them to have it | 05:37 |
| BasicOSX | poolie: does RMS always send a condolences on a regression release? | 05:37 |
| poolie | but better just to ship it all | 05:37 |
| poolie | yes :) | 05:37 |
| poolie | it worried me too :) | 05:37 |
| jml | poolie: so we ought to be including the C for all of the .pyx files. we haven't so far, which means that it's ok for 1.15.1, but we should fix it for some unspecified future release? | 05:38 |
| jml | possibly 1.16, given that bug 385453 is already filed against it. | 05:38 |
| ubottu | Launchpad bug 385453 in bzr "make dist should fail if C files don't exist or can't be built" [Medium,Triaged] https://launchpad.net/bugs/385453 | 05:38 |
| fullermd | I note, for the record, that for 1.15 (and the last time we lacked the built .c files in a release.... 1.12?), I just added pyrex as a build dependancy to the port. | 05:38 |
| fullermd | And I'm seriously considering just leaving the dependancy in place for the future, Just In Case. It's _tiny_. | 05:38 |
| BasicOSX | what the heck, some how a title of 1.15.1 is 1.15.1 "" but I cannot remove the "" | 05:39 |
| fullermd | (I mean, seriously, it took like 10 seconds to download, build, and install, on my old hardware) | 05:39 |
| BasicOSX | nm, control-E killed line and it's gone | 05:39 |
| lifeless | so | 05:45 |
| lifeless | we should be versioning the pyx files now | 05:45 |
| lifeless | its on my todo | 05:45 |
| lifeless | but anyone can do it | 05:45 |
| poolie | jml; i thought that fixing this was the purpose of doing the .1 release? | 05:46 |
| jml | poolie: oh. | 05:47 |
| jml | poolie: I thought the purpose was fixing the smartserver error regression. | 05:47 |
| spiv | The build error was the original reason, the error regression just piggy-backed on that IIRC. | 05:48 |
| jml | ahh ok. | 05:48 |
| spiv | There was also hope for a while that the gc-stacking fixes would be suitable for a 1.15.1, but they became too large. | 05:49 |
| * jml writes out his revised understanding: | 05:54 | |
| poolie | BasicOSX: so does 1.15.1 actually include the C files? | 05:55 |
| jml | poolie: no. | 05:55 |
| jml | <jml> BasicOSX: in the tarball, there's no C file corresponding to ./bzrlib/_walkdirs_win32.pyx | 05:55 |
| spiv | Most Windows users will use the pre-built installer though, so that's possibly not such a big deal. | 05:56 |
| poolie | but for the other ones? | 05:57 |
| lifeless | spiv: it borks nearly every linux distro | 05:57 |
| lifeless | spiv: as they have been depending on the C files | 05:58 |
| BasicOSX | I see the .c in the zip file. http://pastebin.com/d7ff67cf | 05:58 |
| jml | poolie: all of the other ones are there. | 05:58 |
| spiv | lifeless: linux distros have been depending on building _walkdirs_win32? | 05:58 |
| BasicOSX | but I do -not- see them in the tar | 05:59 |
| lifeless | spiv: no, they run setup.py, setup.py builds or not, and depending on the exact distro we either end up with .so's or not. | 05:59 |
| BasicOSX | and the bad news is I sent the announce email | 05:59 |
| lifeless | spiv: and as they don't consistently fail when there are no .so's, users get slow bzr | 05:59 |
| jml | BasicOSX: http://pastebin.com/m3d0b70e0 | 05:59 |
| lifeless | as in fact our ppa was doing for a bit | 05:59 |
| jml | BasicOSX: I see the C files in the tar. | 06:00 |
| BasicOSX | correct, I forgot the '$' | 06:00 |
| spiv | lifeless: the only missing .c file is _walkdirs_win32.c, if I'm understanding the situation correctly. | 06:00 |
| BasicOSX | my apologies | 06:00 |
| jml | spiv: you are. | 06:00 |
| jml | at least in that respect :) | 06:01 |
| === BasicOSX changed the topic of #bzr to: Bazaar version control system | 1.15.1 released 09 June, 2009 | http://bazaar-vcs.org | http://irclogs.ubuntu.com/ | http://planet.bazaar-vcs.org/ | ||
| spiv | BasicOSX: congrats on another release. | 06:01 |
| jml | BasicOSX: thanks :) | 06:01 |
| BasicOSX | Transition of RM roll on a "pffft" on my part | 06:02 |
| jml | :D | 06:02 |
| lifeless | spiv: we're talking at different levells | 06:03 |
| jml | while everyone is talking about pyrex :) | 06:04 |
| jml | http://bundlebuggy.aaronbentley.com/project/bzr/request/%3Ch00992%24d67%241%40ger.gmane.org%3E <-- am I ok to land that? | 06:04 |
| lifeless | jml: poolie said he would land it | 06:05 |
| lifeless | jml: if its not landed its certainly approved to land | 06:05 |
| jml | cool. | 06:05 |
| lifeless | spm: ping | 06:06 |
| lifeless | spm: meet spiv. spiv makes pqm break with lp branches. | 06:07 |
| lifeless | spiv: meet spm. spm makes pqm work with lp branches. | 06:07 |
| lifeless | Now, will you both talk to yeach other please! | 06:07 |
| bialix | jml: hi | 06:53 |
| jml | bialix: hello | 06:53 |
| bialix | hello. I'd like to say you about Russain translation patch, because you're RM for 1.16 | 06:53 |
| bialix | I'd like to have this patch merged and released as part of 1.16, so more russian-spoken people will use it and review it | 06:54 |
| bialix | what should I do to help you? | 06:54 |
| bialix | http://bundlebuggy.aaronbentley.com/project/bzr/request/%3Ch0ld7v%24jjb%241%40ger.gmane.org%3E | 06:55 |
| jml | bialix: you should find someone to review it for you, I think. | 06:55 |
| bialix | poolie, igc: hi | 06:56 |
| igc | hi bialix | 06:56 |
| bialix | igc, can you help me with review of Russian translation patch? | 06:57 |
| igc | bialix: sorry that I haven't got to all your emails yet - flat out on an important eol patch | 06:57 |
| igc | bialix: not just now sorry | 06:57 |
| bialix | ok | 06:57 |
| bialix | 2 all: if anybody can review the patch (only the part related to Makefile changes) -- I'll be very grateful | 06:58 |
| jml | bialix: btw, is there a bug associated with this patch? | 06:59 |
| bialix | not yet, but I can file if this is best way | 06:59 |
| jml | bialix: please do, & assign it to the 1.16 milestone. | 06:59 |
| bialix | I can't assign to milestone. I'm not part of bzr devs LP group | 07:00 |
| jml | bialix: ok, I'll assign for you, on the assumption that this change is easy enough for the 1.16 release | 07:01 |
| bialix | jml: https://bugs.launchpad.net/bzr/+bug/385464 | 07:13 |
| ubottu | Launchpad bug 385464 in bzr "Russian translation for user documentation" [Undecided,Confirmed] | 07:13 |
| vila | hi all | 07:14 |
| bialix | vila: hi! | 07:15 |
| bialix | vila: can I resuade you to look at my russian translation patch, I need to find reviewer for Makefile changes | 07:15 |
| bialix | s/resuade/persuade/ | 07:15 |
| vila | bialix: ok | 07:17 |
| jml | poolie: you available for a fairly quick call? | 07:17 |
| bialix | vila: btw, thanks for your hint about SavedCommitMessageManager in bzr-gtk | 07:18 |
| bialix | I have many questions about that class. Who is designed it? | 07:18 |
| vila | bialix: but I thought your submission was a bit strange (empty bundle), can you make a merge-proposal instead. Even if the diff is huge, we'll be sure the real stuff is up for review | 07:19 |
| bialix | the branch is lp:~ru-bzr/bzr/doc-ru | 07:19 |
| bialix | this is merge directive, it's not empty | 07:20 |
| bialix | do you want full preview diff? | 07:20 |
| bialix | I can make it without bundle part | 07:20 |
| vila | bialix: oh, merge directive without diff silly me, of course | 07:20 |
| vila | bialix: no forget it, I'll mirror that locally to review | 07:21 |
| bialix | resulting htmls available at my site | 07:21 |
| bialix | for preview | 07:22 |
| vila | bialix: I'll generate them locally as part of the review anyway | 07:22 |
| bialix | ok, that's fine | 07:22 |
| jml | vila: hello | 07:22 |
| jml | vila: when you get a chance, can you please take a look at https://edge.launchpad.net/bzr/+milestone/1.16 and tell me if you think we need anything else for the 1.16 release | 07:23 |
| vila | jml: you mean on a general point of view, right ? | 07:25 |
| jml | vila: yeah. any things that are critical to a good 1.16 release & aren't on that list. | 07:25 |
| fullermd | What about fairings? | 07:26 |
| vila | ok, so nothing on my radar yet (bug #385453 can be fixed by adding the C files though) | 07:26 |
| ubottu | Launchpad bug 385453 in bzr "make dist should fail if C files don't exist or can't be built" [Medium,Triaged] https://launchpad.net/bugs/385453 | 07:26 |
| jml | vila: cool. | 07:27 |
| jml | fullermd: fairings? | 07:27 |
| jml | fullermd: what are they? | 07:27 |
| spm | hi spiv :-) | 07:28 |
| fullermd | jml: Well, that's the real question, ain't it? ;> | 07:28 |
| jml | vila: jam seems to be against adding C files right now. since we are close to release, I figure we should adopt a simpler solution for 1.16. | 07:28 |
| vila | jml: ha, ok, I haven't read his mail yet, but on the principle I trust him :) | 07:29 |
| spm | spiv: so aiui, your lp:spivs-awesome-code branches to bzr aren't getting thru PQM? | 07:30 |
| jml | vila: cool. :) I'll be around for a while longer, so feel free to ping me if you think of something. | 07:30 |
| vila | jml: ok | 07:31 |
| spiv | spm: well, they get through, but when they reach the top of the queue they silently fail (i.e. no email reply) | 07:32 |
| spm | spiv: do you think it's possible the sheer awesomeness of the code overwhelms PQM? | 07:32 |
| spiv | spm: my guess would be that something has broken pqm's ability to authenticate to bzr+ssh://bazaar.launchpad.net/, actually :) | 07:33 |
| spm | heh. lets not interject real data/facts here! | 07:33 |
| spiv | spm: I wasn't, that really is just speculation :) | 07:34 |
| * jml afk for a bit | 07:34 | |
| spm | spiv: ok. this is really weird. rob and myself fixed this the other day - the *same* fault/broken config file is back. argh. | 07:35 |
| spiv | spm: was that for the lp pqm, though? | 07:35 |
| spm | bzr | 07:35 |
| spiv | spm: wacky! | 07:35 |
| fullermd | Well, he didn't specify a _direction_... "the other day" could well be tomorrow :p | 07:35 |
| spm | :-) | 07:36 |
| spm | spiv: oki, give it a whirl now? | 07:37 |
| vila | urgh, http://paste.ubuntu.com/192236/ | 07:38 |
| vila | spiv: does the above rings a bell ? | 07:38 |
| vila | bialix: what format did you use for lp:~ru-bzr/bzr/doc-ru ? I can't branch it nor pull fom it :-( | 07:39 |
| bialix | Branch format 7 | 07:40 |
| bialix | Repository format: Packs 6 (uses btree indexes, requires bzr 1.9) | 07:41 |
| bialix | I can send you complete patch with bundle | 07:41 |
| spiv | spm: I don't have a pending branch handy, I'll let you know tomorrow most likely if that's ok. | 07:41 |
| spiv | vila: you can usually work around that bug in the branch by using nosmart or sftp | 07:42 |
| spm | spiv: np | 07:42 |
| bialix | spiv: thx for the fix of Connection reset by peer. I'm ought to test it properly | 07:42 |
| spiv | bialix: that's ok, it was just something that jam pointed out at the sprint and it looked like a quick fix to do between test runs :) | 07:42 |
| bialix | glad it finally fixed | 07:43 |
| vila | spiv: 8-} adding nosmart works, even if the progress bar reports bzr+ssh... meh. Anyway, I thought that symptom was fixed in several different ways already, there are still more ? | 07:45 |
| poolie | jml, hi | 07:46 |
| poolie | am talking to robert, you can call if it's urgent | 07:46 |
| spiv | vila: the damaged branches are still damaged. | 07:46 |
| vila | spiv: ha yes ! Sorry | 07:47 |
| spiv | vila: https://launchpad.net/bugs/354036 's description has the gory details :P | 07:47 |
| ubottu | Launchpad bug 354036 in bzr "ErrorFromSmartServer - AbsentContentFactory object has no attribute 'get_bytes_as' exception while pulling from Launchpad" [Undecided,Confirmed] | 07:47 |
| spiv | "Undecided,Confirmed"? | 07:47 |
| spiv | ubottu: wha? | 07:47 |
| ubottu | Sorry, I don't know anything about wha? | 07:47 |
| spiv | Oh, the "bzr (Ubuntu)" bug. Learn some context about the channel you're in :P | 07:48 |
| bialix | vila: entire bundle sent to you | 07:48 |
| spiv | bialix: (you may want to run the fix script attached to 354036 to repair your doc-ru branch) | 07:49 |
| vila | bialix: it's ok, spiv reminded me that my memory is suffering... what's the name of the disease ? | 07:49 |
| fullermd | "ghost memories" ;) | 07:49 |
| bialix | spiv: should I? it works for me and other ru-bzr people | 07:49 |
| jml | poolie: it's not. I'll survive :) | 07:50 |
| bialix | spiv: is not http:// URL is workaround? | 07:51 |
| spiv | bialix: the bug description on 354036 gives the precise details of the issue. People that don't already have those revisions will probably encounter that error if they use bzr+ssh or lp: URLs. | 07:52 |
| spiv | bialix: http:// (and sftp:// and nosmart+bzr+ssh://) URLs do workaround the problem, yes. | 07:52 |
| bialix | spiv: the bug description and comments is scary long | 07:53 |
| spiv | bialix: don't worry about the comments, the description is fully up-to-date. | 07:53 |
| bialix | you know this patch does not work with bzr.exe? | 07:54 |
| spiv | Which patch? The fix-branch.py script? | 07:55 |
| bialix | running with bzr.dev | 07:56 |
| bialix | spiv: should I run this script from my source branch? | 08:01 |
| bialix | i.e. what is working dir expected> | 08:01 |
| bialix | ? | 08:01 |
| vila | huh, pushing to a local branch with a WT updates the WT *including* uncommitted changes ? Is it really the desired behaviour or a bug ? | 08:01 |
| bialix | the script just prints: Missing inventories: set([('pqm@pqm.ubuntu.com-20090423015537-xfgqsbjj9ctpcd3o',)]) and hangs | 08:02 |
| bialix | spiv: ^ | 08:02 |
| jml | poolie: the main thing I want to know is, for 1.16, should I be concerned with landing the many "Approved" patches listed on bundlebuggy? | 08:02 |
| bialix | running from local source branch gives me different message: Missing inventories: set([]) | 08:06 |
| vila | jml: *I* will be concerned if I was you and will (well, *I* won't, but we're talking about you :) at least target bzr.dev *after* cutting a 1.16 branch... | 08:07 |
| jml | vila: | 08:08 |
| vila | jml: I will just PING (note capitals) the authors :) | 08:08 |
| jml | vila: :) | 08:08 |
| * vila adds more smileys everywhere just in case | 08:08 | |
| AfC | ping: Verb. To throw an electronic message at someone. Ping: Verb. To throw a "ping-pong" ball at someone. PING: Verb. To throw a large bowling ball at someone. :) | 08:10 |
| bialix | spiv: I'm not sure if this script is working. It just print message and then nothing happens. I don't see big network activity or something similar. It looks like it just hangs | 08:10 |
| vila | AfC: is that from a real source or did you just made it ? :-D | 08:10 |
| AfC | Just made it up | 08:10 |
| AfC | vila: feel free to use it :) | 08:10 |
| * bialix can keep it running for all day, of course. But not sure it makes sense | 08:13 | |
| vila | AfC: here you are: http://bazaar-vcs.org/Quotes | 08:15 |
| spiv | bialix: hmm, it shouldn't hang. If there are missing inventories, it will fetch them from the stacked-on repository then exit. If there are none ("set([])") it will simply exit immediately. | 08:17 |
| AfC | vila: There are some very funny passages on that page | 08:18 |
| bialix | so, it definitely hangs | 08:18 |
| vila | AfC: :-) | 08:18 |
| spiv | If it hangs it might be something odd like the SSH subprocess/thread not exiting perhaps? | 08:18 |
| bialix | you ask me? | 08:18 |
| bialix | I don't know | 08:19 |
| spiv | I ask the world in general :) | 08:19 |
| spiv | I don't expect anyone to know the answer... | 08:19 |
| bialix | entire mind of universe, I guess | 08:19 |
| vila | well *I* expect someone knows the answer about: | 08:19 |
| vila | huh, pushing to a local branch with a WT updates the WT *including* uncommitted changes ? Is it really the desired behaviour or a bug ? | 08:19 |
| vila | :-/ | 08:19 |
| spiv | Anyway, it should have done the fix. If you interrupt it and re-run you'll probably see that it's fixed it (i.e. it will report "set([])"). | 08:20 |
| vila | Or should I just test against old bzr releases ? | 08:20 |
| spiv | Or, it really has hung while trying to fetch the missing bits, which would be odd! But maybe a traceback would show something. | 08:20 |
| spiv | vila: I would expect push to a WT would keep the uncommitted changes (and apply them against the new base tree, if necessary) | 08:21 |
| * bialix asking ubuntu guy (Dima Vasiliev) to run this script one more time | 08:22 | |
| vila | and fail if they conflict with already present uncommitted changes ? | 08:22 |
| vila | and not be propagated if I branch from where I just pulled ? | 08:22 |
| spiv | vila: well, produce conflicts anyway. Not precisely what you mean by "fail" here. | 08:22 |
| vila | and not be propagated if I branch from where I just pushed ? | 08:22 |
| bialix | spiv: if you say so, I guess it's fixed | 08:23 |
| vila | spiv: yes, conflicts sorry | 08:23 |
| bialix | but it was not broken for me anyway, so I can't check this | 08:23 |
| spiv | bialix: *nod* | 08:23 |
| vila | bialix: you can try branching in a standalone branch (i.e. outside your shared repo) | 08:24 |
| poolie | jml: not necessarily | 08:25 |
| poolie | you should be concerned about any ones that are marked 1.16 | 08:25 |
| vila | bialix, spiv: not fixed from here, nosmart+ still needed | 08:25 |
| jml | poolie: ok, thanks. | 08:25 |
| poolie | and you should help me guilt everyone into landing them | 08:26 |
| poolie | but not necessarily for 1.16 | 08:26 |
| poolie | i landed a couple of mine today | 08:26 |
| jml | poolie: I'm happy to do that post-1.16 :) | 08:26 |
| bialix | spiv, vila: Dima said it just prints: Missing inventories: set([]) and then exit | 08:27 |
| bialix | vila: just running bzr get in temp dir outside any shred repo with bzr.exe 1.15. Still don't see error | 08:30 |
| bialix | 50% done | 08:30 |
| bialix | vila: Dima just branching on Ubuntu with official bzr 1.15 without errors | 08:35 |
| bialix | it smells like regression in bzr.dev | 08:35 |
| * bialix assumes vila runs bzr.dev | 08:36 | |
| fullermd | Fails for me with both. | 08:37 |
| * vila assumes bialix runs a magic version :) | 08:38 | |
| vila | bialix: just to be sure, can you run bzr info -v in your temp dir and check which repo is used / | 08:39 |
| vila | bialix: just to be sure, can you run bzr info -v in your temp dir and check which repo is used ? | 08:39 |
| * bialix thinks about the fact he and Dima have write privileges to this branch, and other people are not :-P | 08:39 | |
| fullermd | Well, python tracebacks might as well be Russian to _me_... so maybe his bzr just understands it while ours don't? ;) | 08:39 |
| bialix | fullermd: you're incredible right | 08:40 |
| bialix | hdime: hi | 08:40 |
| bialix | hdima | 08:40 |
| bialix | hdima: hi | 08:40 |
| hdima | hi | 08:40 |
| bialix | vila, fullermd: here is Dima | 08:40 |
| bialix | ask him | 08:40 |
| bialix | my branch command still working | 08:41 |
| bialix | it seems my i-net channel little than yours | 08:41 |
| hdima | bzr branch work fine for me, I don't see any errors | 08:41 |
| bialix | hdima: show here output of `bzr info -v` please | 08:44 |
| hdima | bialix: wait a sec | 08:45 |
| bialix | or pastebin it | 08:45 |
| vila | hdima: the bug (AFAIUI) should only be triggered if you don't have some revisions locally, so using a shared repo masks the bug | 08:45 |
| poolie | vila, hello, goodbye! :) | 08:45 |
| vila | poolie: have a nice evening ! ;) | 08:46 |
| poolie | let's try to talk tomorrow, if S will let me :) | 08:46 |
| vila | poolie: cough, Friday instead, I'm not there tomorrow | 08:46 |
| hdima | vila: I've create fresh branch in empty directory so I don't think it was masked | 08:46 |
| poolie | ok | 08:46 |
| vila | hdima: bzr info -v will tell us for sure | 08:46 |
| hdima | And I've ran fix_branch.py which returns: Missing inventories: set([]) | 08:47 |
| hdima | vila: Ok, but I've just deleted the branch and branch it again :-) | 08:48 |
| vila | hdima: argh ;) | 08:48 |
| jml | "bzr: ERROR: No module named bencode" -- what do I install? | 08:49 |
| bialix | my branching still in progress: [#########- ] bzr+ssh > 141913KB 122KB/s | Fetching revisions:Inserting stream | 08:49 |
| vila | jml: use --no-plugins or BZR_PDB=1, it's bzr-gtk and bencode related | 08:49 |
| bialix | jml: some plugin is not updated yet, I guess | 08:49 |
| jml | vila, bialix: thanks. | 08:49 |
| * jml considers aliasing ./bzr to './bzr --no-plugins' | 08:50 | |
| vila | jml: you just said jam fix has landed somewhere what bzr version are you using ? | 08:50 |
| hdima | Ok, here it is: http://paste.pocoo.org/show/122163/ | 08:50 |
| vila | jml: put your RM hat on and repeat: "I should not use --no-plugins when wearing my RM hat" :) | 08:51 |
| jml | vila: I'm fixing https://bugs.edge.launchpad.net/bzr/+bug/385132 | 08:51 |
| ubottu | Launchpad bug 385132 in bzr "bzr uses inaccessible, internal URL when pushing to server with host-relative default_stack_on url" [Critical,Triaged] | 08:51 |
| jml | vila: I'm wearing my Launchpadder hat. | 08:51 |
| jml | vila: *and* my RM trousers. | 08:51 |
| bialix | vila: http://paste.pocoo.org/show/122163/ | 08:51 |
| vila | jml: oh, np then ! Go ! Use --no-plugins !!! | 08:51 |
| vila | bialix, hdima: I'm lost :-/ | 08:52 |
| hdima | bialix: the same output :-) | 08:52 |
| bialix | no, it's your output | 08:52 |
| hdima | bialix: =)))) | 08:52 |
| * bialix just pointing it for vila | 08:52 | |
| vila | bialix: rats ! I thought it was yours and was comparing both ! :-D | 08:52 |
| hdima | I thought it was yours :-) | 08:53 |
| bialix | vila: wait a sec | 08:53 |
| bialix | my branching just finished without errors | 08:53 |
| jml | glyph: hello :) | 08:53 |
| bialix | here is mine: http://paste.pocoo.org/show/122164/ | 08:54 |
| jml | vila: re: your previous question: http://paste.ubuntu.com/192280/ | 08:54 |
| bialix | vila: they both looks suspiciously similar :-D | 08:54 |
| hdima | bialix: except the first line ;-)) | 08:55 |
| bialix | yeah | 08:55 |
| hdima | So it works | 08:55 |
| bialix | vila, spiv: so what now? | 08:55 |
| bialix | it works for us | 08:55 |
| bialix | and we both using official bzr 1.15 and we both have write privileges for this branch | 08:56 |
| vila | write privileges shouldn't have an impact here | 08:56 |
| bialix | as you wish | 08:56 |
| vila | apart from that, no idea | 08:56 |
| vila | trying with 1.15.1 from here | 08:57 |
| bialix | I don;t have 1.15.1 yet | 08:57 |
| vila | fails in the same way | 08:57 |
| vila | as is 1.14.1 | 08:58 |
| bialix | hdima: we just discovered Russian-only feature in LP. Yay! | 08:58 |
| bialix | I guess this is because Mark was in Russian | 08:59 |
| hdima | It's I18N feature ;-) | 08:59 |
| vila | also fails with 1.15 | 08:59 |
| hdima | Now I'm branching read-only with http://... | 09:00 |
| vila | I wonder if windows has some... thing... that has the same effect as adding nosmart+... | 09:00 |
| bialix | vila: hdima using ubuntu | 09:01 |
| hdima | vila: Maybe you need to run it in some sort of sandbox? | 09:01 |
| bialix | with --no-plugins flag may be? | 09:01 |
| vila | bialix: yeah --no-plugins and a lp: URL, I love that combo :-) | 09:01 |
| bialix | :-DDDDDD | 09:02 |
| hdima | :-) | 09:02 |
| bialix | you have bzr+ssh URL ;-) | 09:02 |
| hdima | bialix: Maybe we just need to branch it to a different site for vila? | 09:03 |
| glyph | hello! I have a question about branch etiquette. | 09:03 |
| bialix | no, http:// or nosmart+ prefix works | 09:03 |
| bialix | cool | 09:04 |
| bialix | yesterday I've asked about another etiquette | 09:04 |
| vila | hdima: Don't worry, I have been able to branch by adding nosmart+, I'm just trying to better diagnose the problem, but really I should leave it to spiv as obviously I'm going nowhere | 09:04 |
| bialix | it seems bzr users is very noble people | 09:04 |
| hdima | vila: Ah, OK | 09:04 |
| bialix | glyph: please, ask | 09:05 |
| glyph | If you're working on a feature in a branch, and it takes a long time, sometimes you have to integrate changes from trunk. | 09:05 |
| jml | yep. | 09:06 |
| glyph | It seems like the convention is to do 'bzr merge trunk' in your branch, and just keep working. | 09:06 |
| bialix | yes | 09:07 |
| jml | glyph: yes. that's what most people I know do. | 09:07 |
| glyph | If a lot of work has gone into trunk, that seems to create something I find confusing as a reviewer. | 09:07 |
| glyph | the revision has a giant diff of unrelated changes, which may involve some changes to resolve conflicts | 09:08 |
| glyph | the changes which resolve conflicts are relevant to the branch, but all the other stuff from trunk (which can be a lot) isn't | 09:08 |
| vila | glyph: time to use 'bzr diff -rsubmit:' ? | 09:08 |
| bialix | glyph: you can use `bzr merge --preview` or `bzr send -o-` to preview actual changes | 09:08 |
| jml | glyph: why is the diff in that revision relevant to the review? | 09:09 |
| glyph | jml: well, this is one of the things that I like about bzr as opposed to svn | 09:09 |
| BasicOSX | This cuz I'm using bzr.dev? KnitPackRepository('lp-hosted:///~tanner/mactrek/trunk/.bzr/repository') is not compatible with KnitPackRepository('lp-hosted:///~tanner/mactrek/osxtrek.1.4.0/.bzr/repository') different rich-root support | 09:09 |
| jml | bialix: 'send -o-' is equivalent to 'diff -rsubmit:', isn't it? | 09:09 |
| bialix | I never think about this | 09:10 |
| bialix | may be | 09:10 |
| glyph | jml: If I look at the revision history, I can see how the branch came to be much more easily | 09:10 |
| vila | jml: 85% sure yes | 09:10 |
| glyph | jml: If people integrate changes from trunk, it's easier to read if they do the re-branch thing | 09:11 |
| glyph | jml: If I'm just reading the end-of-branch diff, the experience isn't much different from svn :) | 09:11 |
| jml | glyph: except that the re-branch thing loses all changes from before then. | 09:11 |
| bialix | re-branch? I guess you need rebase | 09:11 |
| glyph | jml: it does? | 09:11 |
| vila | BasicOSX: lp-hosted ? | 09:11 |
| BasicOSX | yes | 09:12 |
| jml | glyph: the history of those changes, yes. | 09:12 |
| vila | BasicOSX: you scare me there is is 3h11 AM your time ? | 09:12 |
| bialix | jml: not if you're using rebase | 09:12 |
| vila | s/is is/is it/ | 09:12 |
| BasicOSX | vila: I need to keep up with you | 09:12 |
| glyph | jml: if you do re-branching by 'bzr branch trunk my-branch-2; cd my-branch-2; bzr merge ../my-branch', what history is lost? | 09:12 |
| vila | BasicOSX: what is lp-hosted ? (was my badly expressed question) | 09:13 |
| jml | glyph: oh, right. none. | 09:13 |
| jml | glyph: it's just weird :) | 09:13 |
| jml | glyph: I was thinking of Combinator-style "merging forward" | 09:13 |
| jml | my mistake. | 09:13 |
| glyph | jml: well, the thing I just said is the bzr non-history-losing translation of that idiom ;) | 09:13 |
| BasicOSX | vila: https://code.launchpad.net/mactrek I just took some upstream code, gotten via bzr svn-import and push to LP (bzr push lp:~tanner) | 09:14 |
| jml | glyph: a lot of the time when I do reviews, I look at the mainline history of that branch. | 09:14 |
| jml | glyph: not diff-by-diff, just the log messages. | 09:14 |
| * igc dinner | 09:14 | |
| glyph | jml: so yeah | 09:16 |
| glyph | jml: what I want to know is, why is it weird? | 09:16 |
| vila | BasicOSX: I think jml may know better about which branch stacks on which and what formats are used in thoses branches. Especially since some vcs-imports are involved and I don't know if you used that or did your ow import 8-} | 09:16 |
| BasicOSX | k | 09:17 |
| BasicOSX | I think it's cuz I locally did a bzr branch --stacked upstream my-branch | 09:17 |
| vila | BasicOSX: but https://code.edge.launchpad.net/mactrek also show branches with "This branch has not been pushed to yet. " warnings which may indicate yet another kind of problem | 09:17 |
| BasicOSX | then did a bzr push lp:~tanner/my-branch | 09:17 |
| jml | glyph: have a look at https://code.edge.launchpad.net/~ian-clatworthy/bzr/eol-st-ci-fix/+merge/7269 for an example | 09:17 |
| jml | (sorry I couldn't find one of my own) | 09:17 |
| jml | glyph: I look at something like that almost every time I review a branch. | 09:18 |
| jml | glyph: I get to see the history, but rarely look at the line | 09:18 |
| jml | at the diff for each revision. | 09:19 |
| jml | glyph: doing the re-branching thing you describe is weird because it disrupts the idea of a branch as a line of development. | 09:19 |
| jml | glyph: also, the initial commit that merges in your changes isn't particularly meaningful. | 09:20 |
| jml | glyph: at least to me, the operation I'm performing is "integrate changes from trunk with my work" | 09:20 |
| jml | not "start a new line of work and bring in everything from my last try at it" | 09:22 |
| jml | glyph: I guess that's not such a compelling answer. | 09:23 |
| BasicOSX | isn't the bug that was fixed in 1.15.1? | 09:23 |
| BasicOSX | Source format does not support stacking, using format: '1.6.1-rich-root' | 09:23 |
| BasicOSX | Packs 5 rich-root (adds stacking support, requires bzr 1.6.1) | 09:23 |
| jml | BasicOSX: don't think so. | 09:24 |
| BasicOSX | ok, I'll stop the panic attack and re-read bug report | 09:24 |
| jml | BasicOSX: the issue is that one branch is 1.6.1-rich-root and the other is 1.6.1, I think. | 09:24 |
| jml | BasicOSX: you can't stack rich-root on non-rich-root & vice verse | 09:24 |
| jml | versa, rather. | 09:24 |
| jml | *so* glad that mess is going away | 09:25 |
| bialix | vila, spiv: so outcome of the problem with doc-ru branch should be filed as bug? | 09:25 |
| jml | wish emacs had annotate integration. | 09:25 |
| jml | mwhudson: pls rewrite loggerhead in elisp kthxbye. | 09:26 |
| vila | bialix: I think so yes | 09:26 |
| glyph | jml: Well, it might not be super compelling, but it makes sense | 09:26 |
| jml | glyph: the other reason is that most merges really are boring. | 09:27 |
| bialix | vila: my gut feeling -- it's related to write permissions. but I have no facts | 09:27 |
| jml | glyph: even most of the ones that resolve conflicts. | 09:27 |
| vila | bialix: There is a way to check that: give me the write permissions (and remove them after the test) | 09:28 |
| bialix | join ru-bzr group then | 09:28 |
| glyph | jml: it does make the history more readable as a list of changes, rather than as a tree of diffs | 09:28 |
| hdima | bialix: maybe you remove write permission for me and give it back after the test? | 09:29 |
| glyph | I think I still prefer my way of doing it, but it explains why that isn't the default way | 09:29 |
| vila | bialix: done | 09:29 |
| bialix | hdima, vila: I do both | 09:29 |
| hdima | bialix: Don't forget to give it back ;-)) | 09:30 |
| bialix | you know how to PING me :-) | 09:30 |
| jml | glyph: as long as you don't make it compulsory for Twisted development, let's leave it there :) | 09:31 |
| hdima | bialix: yeah :-) | 09:31 |
| bialix | vila, hdima: done | 09:31 |
| * hdima test branching | 09:31 | |
| vila | bialix: you were right ! I can branch with 1.15 ! | 09:32 |
| bialix | wait for hdima | 09:32 |
| vila | bialix: well, still in progress with 1.15, will try bzr.dev then | 09:32 |
| hdima | bialix: you are right: I see the error :-)) | 09:33 |
| bialix | yahoo! | 09:33 |
| hdima | But what about fix_branch.py then? | 09:33 |
| bialix | vila: ^ | 09:33 |
| hdima | It seems it doesn't fix anything? :-) | 09:34 |
| vila | there is a bug there, I suspect spiv didn't test with such a config, I don't know off-hand what difference write privileges imply, but obviously something :) jml ? Any idea about what lp does differently here ? | 09:34 |
| jml | yes. | 09:35 |
| jml | (nyah-ah-ah) | 09:35 |
| vila | great, I'm so relieved :) | 09:35 |
| hdima | bialix: give me my rights back! :-)) | 09:35 |
| jml | Launchpad has two different branch storage areas. | 09:35 |
| jml | an upload area and the mirrored area | 09:36 |
| bialix | ok :-P | 09:36 |
| bialix | done | 09:36 |
| jml | via the SSH server, if you get a branch that you've got write access to, you always get the version in the upload area | 09:36 |
| jml | that gets pulled to the mirrored area with bzrlib, so the version in the mirrored area (which you get if you don't have write access) is always a working bzr branch. | 09:37 |
| hdima | bialix: thanks :-) | 09:37 |
| bialix | vila: you can leave the group yourself, I guess? | 09:37 |
| vila | bialix: branch ok with bzr.dev, you can toss my rights :) | 09:37 |
| vila | bialix: I'll try, wait | 09:37 |
| * fullermd tosses vila a left, just when he wasn't expecting it. | 09:38 | |
| bialix | happy to help | 09:38 |
| * vila watch the wreckage on the floor.... | 09:38 | |
| jml | spiv: you still around? | 09:39 |
| * hdima happy to help catch the bug | 09:39 | |
| vila | bialix: done | 09:39 |
| vila | jml: you mean the branch in the mirrored aread is *not* working | 09:40 |
| hdima | vila: now you're lost a chance to help with the translation :-) | 09:40 |
| jml | vila: working as far as bzrlib can tell :) | 09:40 |
| vila | jml: but exhibiting the bug right ? Oooooh, the script has fixed the uploaded branch, but the puller didn't realize it should update the mirrored one because the tip didn't change right ? | 09:41 |
| jml | spiv: in r4126.1.1, you add a test that doesn't have an assertion, test_default_stacking_with_stackable_branch_unstackable_repo -- is this deliberate. | 09:42 |
| jml | vila: bingo | 09:42 |
| vila | pfew... thanks bialix, that one could have stay hidden for a looooong time | 09:42 |
| bialix | vila: so now you can finally look at the patch :-) | 09:43 |
| vila | bialix: If you didn't interrupt me that much the review will have been finished at least 1h30 ago :-D | 09:43 |
| vila | bialix: nearly done | 09:43 |
| * hdima thinks the patch need to be approved at least | 09:44 | |
| * bialix shuts up and hides somewhere | 09:44 | |
| vila | bialix: doe | 09:47 |
| vila | bialix: done | 09:48 |
| vila | I only ask for a minor tweak: adding a comment, other than that, congrats for that work | 09:49 |
| glyph | jml: so do you think you'd ever have call to do my backwards-trunk-merge thing? | 09:53 |
| hdima | bialix: Agreed with vila. I think we need to write something like this: "The following docs was translated to Russian: ..." | 09:54 |
| jml | glyph: I don't think so. | 09:54 |
| jml | glyph: two possible circumstances that I can think of -- | 09:55 |
| jml | glyph: first, if I was resuming a long-dormant branch, then in a sense I am starting a whole new line of work. I might do that sort of thing (then again, I might not) | 09:56 |
| jml | glyph: the other case, when I have a really interesting conflict, I think I would instead do my normal thing and put in a detailed commit message. | 09:56 |
| glyph | jml: if you found a branch where someone (me) had done it a bunch of times, would it annoy you? | 09:59 |
| jml | glyph: I don't know -- it's never happened that I've noticed :) | 10:00 |
| jml | glyph: probably not. (I wonder what it would look like in bzr viz or bzr qlog) | 10:01 |
| bialix | hdima: can you adjust it, please? | 10:02 |
| bialix | vila: many thanks | 10:03 |
| hdima | bialix: yes | 10:04 |
| vila | bialix: thanks to you and your mates for doing that ! For so long (first revisions are from last August right ?) | 10:04 |
| bialix | yes, it was started by Alexey Shtokalo actually. But even before there was another attempt that failed | 10:05 |
| bialix | it's not easy job to do | 10:05 |
| hdima | vila: I believe we'll address duplication in the Makefile in the next patch because I don't like it too | 10:05 |
| vila | hdima: great ! | 10:05 |
| hdima | Yes, and now we want to do it more officially :-) | 10:06 |
| vila | hdima, bialix : that's one more reason to land that patch quickly :) | 10:06 |
| jml | but let's not forget the other reason: if it's not in soon, it misses 1.16 :) | 10:06 |
| bialix | vila: I know it's too much for one day, but.. can you help us with PQM? | 10:06 |
| * jml admires the shine on the RM trousers. | 10:07 | |
| hdima | Actually I have some thoughts about i18n but I think it's too early for now | 10:07 |
| bialix | hdima: please! not now | 10:07 |
| jml | lifeless: you around? | 10:07 |
| * bialix envies to jml | 10:08 | |
| hdima | bialix: it's only thoughts :-))) | 10:08 |
| vila | bialix: no problem, I was thinking about that, but you'll need to push a new branch in lp:~bialix/bzr/whatever-as-long-as-you-tell-me so we avoid the bug | 10:08 |
| fullermd | jml: That's dried blood sweat and tears from previous RM's. No cleaner in the world has managed to get it out... | 10:09 |
| vila | err lp:~bzr/bzr/whatever even | 10:09 |
| jml | fullermd: heh :) | 10:09 |
| vila | jml: did you get the updated notes from BasicOSX ? | 10:09 |
| bialix | vila: I have no access to ~bzr | 10:09 |
| bialix | perhaps hdima has? | 10:09 |
| vila | bialix: bah, use lp:~bialix then, that should be fine as long as you do that with a recent enough bzr (1.15 should be fine) | 10:10 |
| hdima | bialix: no I'm not | 10:10 |
| bialix | vila: perhaps we should get you to ru-bzr group back :-) | 10:10 |
| vila | bialix: :-) Naah, no time to learn Russian :-) | 10:11 |
| jml | vila: no, not yet. | 10:11 |
| bialix | vila: we can teach you some love words in russian... | 10:11 |
| vila | :-D | 10:12 |
| bialix | :-D | 10:12 |
| hdima | and some slang of course ;-) | 10:12 |
| bialix | vila: new branch with the tweak: lp:~ru-bzr/bzr/doc-ru-1.16 | 10:28 |
| jml | В огоро́де бузина́, а в Ки́еве дя́дька. | 10:28 |
| bialix | :-D | 10:28 |
| jml | (from http://en.wikiquote.org/wiki/Russian_proverbs -- I speak no Russian) | 10:29 |
| hdima | Looks like unreadable UTF-8 for me :-) | 10:29 |
| bialix | hdima: I see it right | 10:29 |
| bialix | v ogorode buzina a v kieve dyadka | 10:29 |
| hdima | bialix: Other guys still use KOI8-R on IRC :-) | 10:30 |
| vila | looks like perfect cyrillic for me :-) | 10:31 |
| hdima | Wow, Russian day on #bzr :-))) | 10:31 |
| jml | I can't figure out where this test is supposed to go. | 10:37 |
| jml | also, I suspect that TestSmartServerRequestBzrDirInitializeEx's docstring lies. | 10:37 |
| lifeless | jml: yes | 11:20 |
| jml | lifeless: hi | 11:25 |
| mwhudson | jml: no | 11:25 |
| jml | lifeless: I can't figure out which tests I'm supposed to be looking at here. | 11:25 |
| jml | mwhudson: awwwwwww, c'mon, be a sport. | 11:25 |
| lifeless | ok | 11:25 |
| lifeless | lets make a date; tomorrow say, and I'll look deeply with you | 11:25 |
| lifeless | I'm wellpast EOD | 11:25 |
| jml | lifeless: sounds like a plan. | 11:25 |
| mwhudson | jml: no | 11:26 |
| aquarius | I bzr branched a launchpad project, using my access credentials (it's a project that I can write to). Since then, I've changed my launchpad username, so "bzr pull" says "Using saved parent location: bzr+ssh://OLDUSERNAME@bazaar.launchpad.net/" and then "No such Launchpad account". Can I tell bzr to change the saved location? | 11:30 |
| james_w | aquarius: bzr pull --remember URL | 11:34 |
| aquarius | james_w: and lo it works. Good shout, fella | 11:36 |
| jml | gosh, it's been a while since I've seen 'fella' used colloquially. | 11:38 |
| aquarius | it's due for a revival, I think. Like "codswallop" | 11:38 |
| jml | codswallop I can see. | 11:39 |
| jml | aquarius: are you going to EuroPython? | 11:39 |
| aquarius | jml: probably not, but since I'm only 10 miles away I may drop in for an evening or two of beer | 11:41 |
| jml | aquarius: cool. I'll be attending -- would be cool to catch up. | 11:42 |
| jml | aquarius: also, there's a Bazaar sprint on the Fri & Sat, which you're welcome to gatecrash. (See http://wiki.europython.eu/Sprints) | 11:43 |
| aquarius | I might be able to do that, I'm not sure | 11:45 |
| vila | bialix, hdima: landed | 11:54 |
| === vila is now known as vila-lunch | ||
| igc | bialix: I've resubmited that patch for qversion as requested | 11:55 |
| hdima | vila-lunch: Cool! Thank you! | 12:04 |
| spiv | jml: hmm, regarding that test, probably was intentional, but that was *ages* ago ;) | 12:11 |
| === vila-lunch is now known as vila | ||
| spiv | jml: It looks rather like a test that is of the "...and then this last step doesn't blow up" variety. | 12:12 |
| spiv | jml: although it doesn't seem like it would be hard to sprinkle some assertions afterwards, for clarity. | 12:13 |
| spiv | Also, I've got "bzr pull -r N" from a stacked repo (into an empty repo), where "N" is in the stacked-on repo, down to 18 RPCs, none VFS. | 12:14 |
| spiv | glyph: so, what you describe generates a nearly identical history to the standard "bzr merge trunk". The only difference is that the order of the parents of the merge revision is swapped. | 12:18 |
| spiv | glyph: so one thought that occurs to me is that there's probably an easier way do that than actually constructing a new branch on disk ;) | 12:19 |
| spiv | glyph: but more importantly, I don't see why that makes the history any clearer. Either way there's a big honking merge in the middle of your feature development history that you want to land. | 12:20 |
| rocky | hey the release notes url linked on the main page for 1.15.1 is 404 | 12:55 |
| poolie | hi rocky | 13:07 |
| rocky | hello | 13:07 |
| poolie | fixed | 13:09 |
| poolie | rocky: thanks for reporting it | 13:17 |
| rocky | np | 13:18 |
| === `6og is now known as Kamping_Kaiser | ||
| Milo- | hey, is there a way of setting up 'default' permissions for newly created branches and uploaded files using bzr? | 14:45 |
| Milo- | my vsftp server's settings are completely ignored, and all new branches are created with 700 permissions, even though I want 755 | 14:46 |
| Spabby | hi folks, can anyone give me some advice what model is best for me to use for collaborative working using bzr please? | 14:51 |
| Spabby | We will be working on a zf based php project as a duo, with the development being done on a central LAMP server | 14:51 |
| Spabby | I'm not sure how and if we can achieve this with bzr | 14:52 |
| sevenseeker | ping vila | 14:52 |
| vila | sevenseeker: pong ? | 14:52 |
| sevenseeker | good morning, I was told you were knowledgeable about bzr+ssh | 14:53 |
| vila | sevenseeker: who said that ? :-) | 14:53 |
| sevenseeker | I want to use a pub key to connect to a machine but it is not named in the default way (I have many) | 14:53 |
| sevenseeker | ummm, lemme check | 14:53 |
| sevenseeker | bueno :) | 14:53 |
| vila | sevenseeker: what os are you using ? | 14:54 |
| sevenseeker | client is mac 10.5 and server is ubuntu 9.04 | 14:54 |
| vila | good, we are in civilized world then :) | 14:55 |
| vila | man sshd_config | 14:55 |
| sevenseeker | hahaha | 14:55 |
| sevenseeker | well I have ssh working fine | 14:55 |
| LarstiQ | sevenseeker: is ssh-add feasible? | 14:55 |
| sevenseeker | how do I make bzr use a specific key? | 14:55 |
| LarstiQ | sevenseeker: if not, you could specify the key to use in ~/.ssh/config | 14:56 |
| sevenseeker | oh, well... lemme check | 14:56 |
| sevenseeker | oh, I see... never done that (LarstiQ) | 14:56 |
| vila | sevenseeker: As Larstiq said, no need to involve bzr hence: man sshd_config, I thought the variable was Identity but I can't find it anymore :-/ | 14:56 |
| LarstiQ | vila: think so | 14:57 |
| vila | IdentifyFile ! man ssh_config not sshd you id...entity seeker :) | 14:57 |
| sevenseeker | vila: I see, lemme check... had no idea that would help me until you mentioned it :) | 14:58 |
| vila | sevenseeker: so the idea is that you define IdentifyFile in some host section (I tested that weeks ago but I did it manually :-/ Time to start TDA test driven administration :-D) | 14:58 |
| sevenseeker | sweet | 14:59 |
| visik7 | ok I used bazaar for 1 year alone :) | 15:07 |
| visik7 | now I'm using it in a team | 15:07 |
| visik7 | few questions: | 15:07 |
| Milo- | he's been writing those questions for 10 minutes | 15:17 |
| Milo- | I bet it's something huge | 15:17 |
| === oubiwann_ is now known as oubiwann | ||
| visik7 | this is my workflow A and B has rev1 and A commit and push (rev2) to a shared branch, now B commit and push too (its own rev2) and got a diverged error it, B runs merge and a commit and push | 15:31 |
| visik7 | Milo-: no I'm working and chatting and surfing and calling to the phone and a bunch of other things | 15:32 |
| sevenseeker | howdy again, thanks everyone for your help and feedback | 15:33 |
| sevenseeker | using ssh-agent I am able to push and branch remotely but I can't seem to get it working right, both push and branch TO the remote location only result in a dir with .bzr in it, and when I try and run 'bzr update' on it, it complains that it is NOT a working copy :( | 15:35 |
| LarstiQ | sevenseeker: that is intended behaviour | 15:36 |
| Peng_ | sevenseeker: Why do you want a working copy? | 15:36 |
| LarstiQ | visik7: go on :) | 15:37 |
| sevenseeker | well all I want to do is push a branch to the remote server for development, the constraint is that my dev box I am pushing from is not reachable by the remote servers | 15:37 |
| LarstiQ | sevenseeker: develpment in what sense? The .bzr control directory is everything bzr needs for publishing purposes | 15:38 |
| LarstiQ | Peng_: I vote for inclusion of this question in http://bazaar-vcs.org/FAQ | 15:38 |
| sevenseeker | so say locally I branch foo to bar, make my changes and commit, now I want to push 'bar' to actually work on it in my test envrionment remotely | 15:39 |
| sevenseeker | yes, a FAQ on this would rock! | 15:40 |
| visik7 | LarstiQ: so the question is before the push of B | 15:41 |
| Peng_ | LarstiQ: That's a good idea. I'm not gonna write it, though. I'm a terrible writer. | 15:41 |
| visik7 | how to handle the if A had push something ? | 15:41 |
| * LarstiQ nods at Peng_ | 15:41 | |
| sevenseeker | right now I am tarballing it all up and throwing it on the remote location, but I figured there was a better way | 15:42 |
| LarstiQ | sevenseeker: usually, one pushes a branch to a remote location, to then bzr pull/branch/merge from that location somewhere else | 15:42 |
| visik7 | B -> 1 pull -> 2 on error-> merge ->3 commit ->4pull (goto 2)-> push ? | 15:42 |
| LarstiQ | sevenseeker: is the remote location actually a workstation of yours, and not a central server? | 15:42 |
| sevenseeker | yes, it is a test machine (or dev on our production environment --> EC2) | 15:43 |
| j_baker | I'm having a bit of trouble downloading anything at https://launchpad.net/bzr/+download ... Is it just my network connection, or is anyone else having the same problem? | 15:43 |
| sevenseeker | so no, not central server | 15:43 |
| sevenseeker | although I will need that soon | 15:43 |
| LarstiQ | sevenseeker: you can create a working tree by using `bzr co` | 15:43 |
| sevenseeker | just for using Trac | 15:43 |
| LarstiQ | sevenseeker: and then `bzr update` to update the working tree | 15:43 |
| LarstiQ | (after subsequent pushes) | 15:44 |
| sevenseeker | oic, I wrongly thought co would 'pull' from another location, not use what is in the .bzr info | 15:44 |
| sevenseeker | dang, you guys rock | 15:44 |
| visik7 | is my workflow complete ? or did I miss somethng ? | 15:44 |
| sevenseeker | I really appreciate it | 15:44 |
| LarstiQ | sevenseeker: to see that clearer `bzr co .` | 15:45 |
| sevenseeker | I am still coming from svn, so used to that way, lol | 15:45 |
| LarstiQ | visik7: I'd do: `cd trunk; bzr pull; bzr pull ../feature-branch; (if that failed, bzr merge ../feature-branch); bzr commit; bzr push` | 15:46 |
| LarstiQ | visik7: alternatively, you could make use of checkouts and their lock-step development mode | 15:47 |
| luks | sevenseeker: hm, I wonder what are you used to with svn | 15:48 |
| luks | sevenseeker: because svn doesn't allow creating and managing working copies on remote servers | 15:48 |
| LarstiQ | luks: `svn co` vs `bzr co .` | 15:48 |
| visik7 | but on the last 2 commands between commit and push do you check if new changes are in ? | 15:48 |
| sevenseeker | I know, I meant that svn co pulled data from a remote source | 15:48 |
| sevenseeker | not pushing :) | 15:48 |
| luks | ah | 15:48 |
| LarstiQ | visik7: no, because you had already pulled trunk to mirror remote | 15:49 |
| visik7 | but how could you know if someone update the remote ? | 15:49 |
| LarstiQ | visik7: you would know if push said they diverged | 15:50 |
| visik7 | oh ok | 15:50 |
| visik7 | thanks | 15:51 |
| LarstiQ | visik7: as I said, checkout with it's check at commit time might suit you better | 15:51 |
| visik7 | what's the difference between push/pull and checkout/commit a part that the branch is bound ? | 15:53 |
| LarstiQ | visik7: ehm, that's not the relevant grouping | 15:54 |
| visik7 | ok I miss something | 15:54 |
| visik7 | could you explain me please ? | 15:57 |
| LarstiQ | visik7: push/pull/checkout/commit are useable in both situations | 15:58 |
| LarstiQ | visik7: in fully distributed mode, making a new revision (commit) and publishin that revision (push) are decoupled | 15:58 |
| LarstiQ | visik7: in a central style (bound branch), commit will also make your revision available in the branch you are bound to. | 15:59 |
| LarstiQ | visik7: however, that doesn't diminish the use of push to publish revisions in other locations. | 15:59 |
| LarstiQ | visik7: commit will also check that you're not diverged, and suggest you run update if you are. | 16:00 |
| LarstiQ | visik7: in the fully distributed mode, update is used to bring the working tree at the same revision as the branch, as seen in sevenseeker's situation | 16:01 |
| visik7 | so I don't understand how to use what you call "checkouts and their lock-step development mode"? | 16:01 |
| LarstiQ | visik7: for bound, update will bring the working tree (and local branch) up to date with the master branch | 16:01 |
| LarstiQ | visik7: if you're more familiar with a bound branch, use that term instead of a checkout | 16:02 |
| visik7 | I suggest my team to unbound their own branck | 16:02 |
| LarstiQ | visik7: in that case, B can not commit to a state where he'd diverge from the shared trunk | 16:02 |
| visik7 | I don't really like bounded branches | 16:02 |
| visik7 | oh for that | 16:02 |
| LarstiQ | yes | 16:02 |
| stbuehler | I'm having fun with bzr-svn again... bzr push takes ages (discovering branches [...]), bzr dpush doesn't work, and i still don't get the svn rev ids for the commits i pushed in the bzr log | 16:02 |
| LarstiQ | visik7: if you don't want to use them, that's fine. | 16:02 |
| LarstiQ | visik7: you'll get diverged branches from time to time, and you'll have to merge | 16:03 |
| LarstiQ | visik7: if trunk is diverged yet again after you do that, you'll have to merge again | 16:03 |
| visik7 | LarstiQ: I like unbound but I think that for other developers bounded branches are better | 16:03 |
| LarstiQ | visik7: depends on what they're comfortable with | 16:03 |
| visik7 | they have never used VCS nor DVCS | 16:04 |
| Milo- | I don't want to run "bzr serve" as root, what kind of permissions do I have to set for my server's users in order to my 'bazaar' -user to have access to the branches? | 16:04 |
| Peng_ | Milo-: That depends entirely on the permissions on your branches... | 16:05 |
| Milo- | the branches are automatically created with 700, which I can't seem to change | 16:05 |
| LarstiQ | visik7: that can mean they'll accept any new way of thinking :) | 16:05 |
| Milo- | haven't found a way to create them with some other permissions instead | 16:06 |
| LarstiQ | Milo-: how are they created? | 16:06 |
| Milo- | when running bzr init ftp://my-ftp.my-domain.myTLD/branch | 16:06 |
| visik7 | LarstiQ: yes but it's already difficult to explain a VCS I can't afford to explain DVCS they probably starts to running around screaming | 16:06 |
| LarstiQ | Milo-: I'll mention `setfacl` and POSIX acls before I know what the situation is | 16:06 |
| LarstiQ | Milo-: if you can, using something that is not ftp will be better | 16:06 |
| visik7 | LarstiQ: so for B -> update -> merge if errors -> commit ->merge if errors ? | 16:07 |
| LarstiQ | visik7: right, then checkouts might be better for them | 16:07 |
| Milo- | ssh would be create, but chrooting it is harder | 16:07 |
| Milo- | erm | 16:07 |
| Milo- | great* | 16:07 |
| Milo- | not create, hah | 16:07 |
| visik7 | B is my fellow developer :) | 16:07 |
| LarstiQ | visik7: commit -> update if mentions -> commit -> update if mentions, etc | 16:07 |
| visik7 | so no steps before starts coding ? | 16:08 |
| LarstiQ | visik7: `bzr checkout url/to/master; cd new-checkout; *hack*; bzr diff; bzr commit;` | 16:09 |
| Milo- | setfacl -m u:myBazaarUser:rx hmm, I'll try that | 16:09 |
| LarstiQ | Milo-: either I mistunderstand your question, or you're looking for group instead | 16:10 |
| Milo- | the users are in the bazaar group | 16:10 |
| Milo- | but the dedicated bazaar-user still can't access the files :/ | 16:11 |
| visik7 | LarstiQ: yes the checkout part is already done, I mean ... in the morning ... before everything take place a bzr update is suggested right ? | 16:11 |
| Milo- | and I need to find a way for bazaar to set up permissions for the group when ever it creates new files. | 16:11 |
| LarstiQ | Milo-: paste from my situation: | 16:11 |
| LarstiQ | setfacl -m group:developer:rwx /bzr | 16:11 |
| Milo- | I don't want to setup dedicated bazaar server as root | 16:11 |
| LarstiQ | setfacl -m default:group:developer:rwx /bzr | 16:12 |
| LarstiQ | visik7: not needed, but doesn't hurt to get new revisions before you start working | 16:12 |
| Milo- | LarstiQ I get "operation not supported" when I run that | 16:12 |
| LarstiQ | Milo-: feh, then your fs doesn't have POSIX acl support (turned on) | 16:13 |
| Milo- | ah | 16:13 |
| LarstiQ | Milo-: in that case, you'll need to fall back to plain old unix permissions | 16:13 |
| LarstiQ | Milo-: with setgid | 16:13 |
| Milo- | ? ? [*] Ext3 POSIX Access Control Lists ? ? | 16:13 |
| LarstiQ | Milo-: and appropriate umasks | 16:13 |
| Milo- | it's definitely there | 16:13 |
| LarstiQ | Milo-: and the fs in question is ext3? :) | 16:14 |
| Milo- | indeed | 16:14 |
| LarstiQ | mkay | 16:14 |
| LarstiQ | Milo-: they really are the most convenient way of solving this problem | 16:14 |
| LarstiQ | Milo-: could you pastebin the exact sequence? | 16:14 |
| Milo- | exact sequence? | 16:15 |
| Milo- | I rather ask something stupid than paste something stupid | 16:15 |
| LarstiQ | Milo-: a transcript of the commands you typed in and their output | 16:15 |
| LarstiQ | Milo-: the one that gave ris to 'operation not supported' | 16:15 |
| Milo- | http://codepad.org/9L366Wmt | 16:16 |
| LarstiQ | Milo-: ok, and `mount | grep home` just to make sure? | 16:17 |
| * LarstiQ googles the error | 16:17 | |
| Milo- | /dev/sda2 on /usr type ext3 (rw,noatime) | 16:17 |
| Milo- | no 'home' | 16:18 |
| LarstiQ | Milo-: ah, you might be missing some user-land utilities | 16:18 |
| visik7 | thanks LarstiQ | 16:18 |
| LarstiQ | Milo-: got libacl1 ? | 16:18 |
| visik7 | see you later | 16:18 |
| Milo- | no such thing in the portage :o | 16:19 |
| LarstiQ | Milo-: luckily you did a human grep for the information I was after anyway ;) | 16:19 |
| Milo- | I do have sys-apps/acl | 16:19 |
| LarstiQ | Milo-: sounds about right | 16:19 |
| Milo- | which has access control list utilities, libraries and headers | 16:19 |
| Milo- | well, I do know around my setup | 16:20 |
| Milo- | but creating this dedicated user for bzr server is giving me a lot of trouble | 16:21 |
| LarstiQ | Milo-: a dedicated user doesn't sound too sensible | 16:22 |
| Milo- | well, I don't want to run the server as root | 16:22 |
| LarstiQ | that sounds even less sensible :) | 16:22 |
| Milo- | not wanting, or running it as root? | 16:22 |
| LarstiQ | running it as root | 16:22 |
| LarstiQ | it has no business near root | 16:23 |
| Milo- | that's what I thought | 16:23 |
| LarstiQ | Milo-: maybe we should take a step back and discuss what your desired outcome is? | 16:23 |
| Milo- | I've plenty of users on my server, which are there to use bzr, share their projects and such | 16:23 |
| LarstiQ | right | 16:23 |
| Milo- | the users have their own accounts to do the changes, commits, etc | 16:23 |
| Milo- | and the bzr serve is there to let them share their projects as readonly (bzr branch bzr://..../branch | 16:24 |
| Milo- | ) | 16:24 |
| LarstiQ | ok | 16:24 |
| Milo- | first I tried to do that with anonymous ftp user, but it hit the brick wall since bzr kept creating all the .bzr folders with 700 permissions | 16:25 |
| Milo- | and now I think this one is hitting the same brick wall as well. | 16:25 |
| LarstiQ | Milo-: you don't want to provide readonly access via http? | 16:26 |
| LarstiQ | Milo-: or even bzr+ssh:// to other users branches? | 16:26 |
| Milo- | that should also have the same issue, no permissions to the folders. | 16:26 |
| LarstiQ | because they're using ftp to push their branches, and that results in 700 permissions? | 16:27 |
| Milo- | bzr+ssh would be okay, but that'd require a lot of configuring for my ssh settings and ensuring that ssh is still chrooted (for which, I haven't found a working tutorial yet) | 16:27 |
| LarstiQ | Milo-: what umask is the ftpd employing? | 16:27 |
| Milo- | 0022 | 16:27 |
| LarstiQ | hmmm | 16:28 |
| LarstiQ | Milo-: could you try a push with bzr+ssh:// or sftp:// to see if it has the same permissions? | 16:28 |
| Milo- | I don't want those users to have actual shell-access | 16:28 |
| Milo- | sftp:// only seems to work with default port | 16:29 |
| LarstiQ | Milo-: regardeless of that, I'd like for you to test out and see what happens | 16:30 |
| Milo- | oh and sftp doesn't work if I'm blocking them from logging in | 16:30 |
| LarstiQ | Milo-: if those _also_ get to 700, we have a problem somewhere else | 16:30 |
| Milo- | bzr: ERROR: No such file: '/test': [Errno 2] No such file | 16:31 |
| Milo- | that was with bzr init | 16:31 |
| Milo- | oh yeah | 16:32 |
| Milo- | sftp takes absolute path | 16:32 |
| Milo- | sftp created the repo with the right mask | 16:32 |
| Milo- | so it's an ftp issue | 16:32 |
| LarstiQ | yeah | 16:33 |
| * LarstiQ hates hates ftp | 16:33 | |
| Milo- | But I can't let my users to use sftp, since I don't want to use default ssh port and I don't want them to be able to have ssh login rights | 16:33 |
| LarstiQ | Milo-: that's fixable, but let's see what we can do with ftp | 16:34 |
| Peng_ | I thought OpenSSH's sftp is known for screwing up masks. | 16:34 |
| Peng_ | Or maybe it's group ownership. Anyway, it's something! | 16:34 |
| LarstiQ | Peng_: fixed in a 5.x release | 16:34 |
| Peng_ | LarstiQ: Oh, cool. | 16:34 |
| LarstiQ | afaik istr | 16:34 |
| Peng_ | ...I'm pretty sure I'm not crazy enough to build my own OpenSSH, though. :D | 16:35 |
| LarstiQ | Peng_: 5.1 is in sid and testing | 16:35 |
| Milo- | bzr+ssh:// also worked well | 16:36 |
| Peng_ | LarstiQ: Well, I don't run sid and testing. | 16:36 |
| Milo- | so how to fix ftp | 16:36 |
| LarstiQ | Milo-: if you could provide more debugging information on https://bugs.edge.launchpad.net/bzr/+bug/326543 that might help | 16:38 |
| ubottu | Launchpad bug 326543 in bzr "Broken permissions over FTP for .bzr/repository (and others)" [Undecided,New] | 16:38 |
| LarstiQ | Milo-: maybe run bzr with -Dtransport | 16:39 |
| LarstiQ | Milo-: ie, `bzr -Dtransport push/init foo` etc | 16:39 |
| Milo- | -Dtransport does what? | 16:39 |
| LarstiQ | Milo-: server logs of your ftpd might also help debug this | 16:39 |
| LarstiQ | Milo-: add verbose prints for transport (sftp/ftp/ssh/http) activity to .bzr.log | 16:39 |
| Milo- | ok | 16:39 |
| LarstiQ | Milo-: as well as information on which ftp server you're using | 16:40 |
| Milo- | vsftpd | 16:40 |
| LarstiQ | standard enough at least | 16:40 |
| Milo- | oh forgot, I never received my launchpad confirmation | 16:41 |
| Milo- | something wrong with my mail-box. It decides to ignore some weird places | 16:41 |
| Milo- | probably something wrong with my own domain settings | 16:41 |
| jseabold | Was wondering if someone could help me out. I've found some help here on this problem a few weeks ago, but it persists. | 16:42 |
| jseabold | I work on one branch on launchpad from two computers and even though I've committed and pushed visible changes to lp from one computer. | 16:42 |
| LarstiQ | Milo-: if you do the debugging work, I can attach it to the bugreport :) | 16:42 |
| jseabold | When I run bzr status on my other computer it says up to date with revision 1728 when the newest revision on the branch is 1730. | 16:42 |
| LarstiQ | jseabold: `bzr status` compares your working tree with your local branch data. It does not check remotely. | 16:43 |
| jseabold | sorry bzr update gives tree is up to date | 16:43 |
| Milo- | LarstiQ could you tell me exactly what you want for that report? | 16:43 |
| jseabold | but what it reports as up to date and what is on launchpad as the newest revisions is different | 16:44 |
| LarstiQ | Milo-: sure. `bzr init ftp://` goes wrong, right? I'd like to see results of `bzr -Dtransport init ftp://` from ~/.bzr.log | 16:45 |
| Milo- | ok | 16:46 |
| LarstiQ | jseabold: what does `bzr info` say your branch type is? | 16:46 |
| jseabold | Standalone tree (format: pack-0.92) | 16:47 |
| jseabold | Location: | 16:47 |
| jseabold | branch root: . | 16:47 |
| Milo- | woah currently I just keep getting this with all ftp-operations. http://codepad.org/1LhPZobe | 16:47 |
| Milo- | I might have broken my ftp | 16:47 |
| LarstiQ | jseabold: right, standalone tree, not a checkout. | 16:47 |
| LarstiQ | jseabold: you want `bzr pull`, not `bzr update` | 16:47 |
| jseabold | LarstiQ: that was my next question. thanks! So I should only use update on a checkout and pull on a standalone tree? | 16:48 |
| LarstiQ | jseabold: for this usecase, yes | 16:49 |
| jseabold | LarstiQ: wonderful thank you very much | 16:50 |
| eydaimon | bzr serve seems to not give me anything good when I run it. and by not good, I mean "erroreneric bzr smart protocol error: bad request 'GET / HTTP/1.1\r'". I'm starting with `bzr serve`. Am I doing something wrong? | 16:50 |
| eydaimon | oh, it's not an http serve :/ | 16:50 |
| eydaimon | is there a webserver type thing? | 16:50 |
| LarstiQ | eydaimon: if you have a recent loggerhead installed, you can `bzr serve --http` | 16:50 |
| eydaimon | loggerhead? | 16:51 |
| Milo- | LarstiQ interestingly, everything else but the ".bzr" is created with the right permissions :/ | 16:51 |
| Milo- | everything else but .bzr (and lock) is created with 755 | 16:51 |
| LarstiQ | Milo-: you mean, other uses of ftp besides bzr? | 16:51 |
| Milo- | no, when doing bzr init | 16:51 |
| LarstiQ | Milo-: or, do you mean .bzr/repository is fine, but .bzr/ is not? | 16:51 |
| eydaimon | LarstiQ: is it sufficient just to get the latest bzr ? | 16:52 |
| Milo- | yes | 16:52 |
| LarstiQ | Milo-: now that is weird | 16:52 |
| LarstiQ | eydaimon: no, loggerhead is a seperate project | 16:52 |
| Milo- | but 'other' needs to have access to the .bzr if 'other' wants to checkout or create its own branch out of it | 16:52 |
| LarstiQ | eydaimon: ie, as a loggerhead package in your distribution, or launchpad.net/loggerhead | 16:52 |
| eydaimon | ok | 16:52 |
| eydaimon | thanks | 16:52 |
| eydaimon | no such option --httlp so I have to upgrade bzr anyway | 16:53 |
| LarstiQ | Milo-: I'll note it on the bug, it seems relevant | 16:53 |
| LarstiQ | eydaimon: no, you have to install loggerhead :) | 16:53 |
| LarstiQ | eydaimon: the --http option is provided by loggerhead, not by bzr | 16:53 |
| LarstiQ | eydaimon: have a look at the `bzr plugins` output | 16:53 |
| LarstiQ | eydaimon: loggerhead 1.11 Loggerhead web viewer for Bazaar branches. | 16:54 |
| eydaimon | got it :) | 16:54 |
| LarstiQ | eydaimon: that is included in my output | 16:54 |
| eydaimon | thanks much | 16:54 |
| LarstiQ | Milo-: ah, a previous reporter also mentioned it | 16:54 |
| eydaimon | would be nice if plugins were integrated in bzr like packages.. bzr plugin install loggerhead | 16:55 |
| Milo- | so there is hardly anything new coming from me | 16:55 |
| Milo- | I'm also using bzr 1.14.1 | 16:55 |
| Milo- | with python 2.5.4 | 16:55 |
| LarstiQ | Milo-: can you try older versions to see if we can pinpoint when this change happened? | 16:55 |
| eydaimon | no port for loggerhead. hm | 16:55 |
| Milo- | I can only go back to 1.9 | 16:56 |
| Milo- | but I'll try 1.9, 1.10, 1.11, 1.12, 1.13.2 and the latest 1.15 | 16:56 |
| LarstiQ | Milo-: I'm hoping it's more recent than 1.9 | 16:56 |
| LarstiQ | Milo-: updated the bug | 16:57 |
| eydaimon | LarstiQ: where would I make such a suggestion for feature besides here? | 16:57 |
| LarstiQ | eydaimon: talk to bialix, iirc he did something like that in the past | 16:57 |
| LarstiQ | eydaimon: I just do `cd ~/.bazaar/plugins; bzr branch lp:loggerhead loggerhead` | 16:58 |
| eydaimon | good advise, thank you | 16:59 |
| Milo- | bzr-1.9 inited .bzr with 700 :/ but it also created everything else with 700 permissions | 17:00 |
| Milo- | same result with 1.10, 1.11, 1.12 (.bzr and its subfolders and files are created with 700 permissions) | 17:07 |
| LarstiQ | Milo-: ok | 17:07 |
| LarstiQ | Milo-: it did change between 1.9 and 1.10 though? | 17:07 |
| Milo- | no | 17:07 |
| LarstiQ | the subfolders permissions? | 17:08 |
| Milo- | 19:01:02 Milo- >> bzr-1.9 inited .bzr with 700 :/ but it also created everything else with 700 permissions | 17:08 |
| Milo- | so they're same as 1.10, 1.11, 1.12 | 17:08 |
| LarstiQ | vila: ^^ do you have an idea why ftp permissions on .bzr might be broken since at least 1.9? bug 326543 | 17:08 |
| ubottu | Launchpad bug 326543 in bzr "Broken permissions over FTP for .bzr/repository (and others)" [Undecided,New] https://launchpad.net/bugs/326543 | 17:08 |
| Milo- | and 1.13.2 | 17:08 |
| LarstiQ | Milo-: doh, didn't look at the correct end of the interval | 17:09 |
| Milo- | I'll try the 1.15 as well | 17:09 |
| LarstiQ | Milo-: 1.9 through 1.13.2 differ from 1.14.1 in the permissions of the subfolders? | 17:09 |
| Milo- | yes | 17:09 |
| LarstiQ | ok | 17:09 |
| Milo- | 1.14.1 created subfolders and files with right permissions | 17:09 |
| vila | LarstiQ: hmm, strange, all file/directories should have the same permission, that bug wasn't on my radar, I'm sure there was at least one bug, but I was convinced it has been fixed | 17:11 |
| Milo- | hmm | 17:11 |
| LarstiQ | vila: note, ftp, not sftp | 17:11 |
| Milo- | actually | 17:11 |
| Milo- | I | 17:11 |
| Milo- | nope | 17:11 |
| vila | yes ftp | 17:11 |
| LarstiQ | ok | 17:11 |
| Milo- | I'll paste you the permissions | 17:11 |
| vila | oh wait ! | 17:11 |
| Milo- | I re-did my tests :/ | 17:11 |
| vila | ftp need server side support ! | 17:11 |
| vila | isn't there an option for that in vsftpd ? | 17:12 |
| * vila refreshing memory a bit | 17:12 | |
| Milo- | http://codepad.org/2WQbwSQp there you have it :/ | 17:12 |
| Milo- | and those actually applies to all versions between 1.9 - 1.5 :/ | 17:13 |
| Milo- | erm | 17:13 |
| Milo- | 1.9 - 1.15 | 17:13 |
| Milo- | so LarstiQ no, there wasn't any changes between 1.9 and 1.14.1, except I made a bad test. | 17:14 |
| vila | chmod on ftp is implemented via the SITE CHMOD command | 17:14 |
| vila | Milo-: Do you have *one* bzr version that produces the right permissions ? | 17:14 |
| Milo- | no | 17:14 |
| Milo- | portage only goes down to version 1.9 | 17:14 |
| Milo- | file_open_mode=0777 | 17:15 |
| Milo- | local_umask=0022 | 17:15 |
| Milo- | those are my vsftpd.conf's settings | 17:15 |
| vila | Milo-: Ha, ok, then I'd say vsftpd may not respect our commands, can do a single test and look at your .bzr.log | 17:15 |
| vila | all _setmode commands should display the permissions asked | 17:16 |
| * LarstiQ heads to jitsu training | 17:16 | |
| Milo- | 1.826 FTP site chmod: setting permissions to 0600 on /test06/.bzr/README | 17:16 |
| Milo- | :o | 17:16 |
| Milo- | that's from the logs | 17:16 |
| vila | weird | 17:17 |
| Milo- | I'll paste it | 17:17 |
| vila | Milo-: to the bug report ? | 17:17 |
| Milo- | http://codepad.org/yZ9Q8HYs | 17:17 |
| Milo- | I'm not receiving the confirmation mail :/ | 17:18 |
| Milo- | so I can't create a bug-report | 17:18 |
| Milo- | something wrong with my email-configs | 17:18 |
| vila | Milo-: ok, I've marked the bug as confirmed so we'll better track it from there | 17:21 |
| vila | beuno: whoohoo, first time I update a tag in place :0) | 17:22 |
| Milo- | something weird is happening with my domain's email settings, launchpad is the second confirmed host that doesn't send mails through my domain, microsoft is the first one. | 17:22 |
| jam | hey vila, what are you still doing around :) | 17:28 |
| vila | jam: hey jam ! Fixing bzr-gtk pb :-) | 17:28 |
| jam | vila: I was curious if you had a chance to peek at the 'better_heads' code | 17:31 |
| jam | I'm guessing not | 17:31 |
| jam | anyway, I did an interesting check today | 17:31 |
| jam | about how many nodes we "access" to determine heads() | 17:31 |
| jam | and it seems that GDFO isn't helping a lot there. | 17:31 |
| jam | It helps a little | 17:31 |
| vila | jam: :-/ But I will spend ~4hours in the train tomorrow, your nudge came at the right momemnt :) | 17:32 |
| jam | as we access ~86% the total nodes | 17:32 |
| jam | (well the same number of nodes = _nodes[key] versus get_parent_map([keys]) sort of thing) | 17:32 |
| jam | on the flip side, w/ "linear dominator" | 17:32 |
| jam | we access only 57%, | 17:32 |
| vadi2 | Is it ok to have to commit after you do bzr merge each time? | 17:32 |
| vila | which graph ? bzr ? | 17:33 |
| jam | vila: right bzr.dev | 17:33 |
| jam | when doing a "heads()" check | 17:33 |
| jam | at merge revisions | 17:33 |
| jam | (comparing the two merge parents | 17:33 |
| jam | ) | 17:33 |
| jam | I'd be interested to see the effect for stuff like per-file graphs, etc | 17:33 |
| jam | But I figured this was a reasonable start at a real-world case | 17:33 |
| jam | I would guess that per-file graphs will be even more linear, and 'linear-dominator' will have a larger effect | 17:34 |
| jam | vila: what happened to your patch to change GC.annotate() to use a graph on the parent_map() rather than the VF itself? | 17:36 |
| jam | It doesn't seem to be present in my bzr.dev | 17:36 |
| vila | huh | 17:37 |
| jam | vila: actually, it could just be an old branch | 17:37 |
| jam | let me check | 17:37 |
| jam | vila: old branch, sorry | 17:38 |
| jam | vila: anyway, linear_dominators is probably even harder to cache than GDFO | 17:42 |
| jam | inserting a new merge child needs to invalidate any entries that were referencing the parents, etc. | 17:42 |
| vila | jam: same complexity I'd say, and I think we need *both* anyway | 17:43 |
| jam | vila: not at all. GDFO is only mutated by ghosts | 17:43 |
| jam | 'linear dominator' can be invalidated by a new child | 17:43 |
| jam | http://paste.ubuntu.com/192751/ | 17:44 |
| vila | jam: oops. yes of course, too many eggs at once | 17:44 |
| jam | anyway, I won't distract you more | 17:45 |
| vila | jam: let me finish my submission for bug #385191 | 17:45 |
| ubottu | Launchpad bug 385191 in bzr-gtk "removal of ProgressBarStack has broken bzr-gtk" [Critical,Confirmed] https://launchpad.net/bugs/385191 | 17:45 |
| vila | jam: as a side note, either you should start writing your graphs upside-down or we should ask qlog and bzr-gtk to write theirs upside-down :-D | 17:53 |
| jam | vila: time always flows down for me. "bzr log --forward" | 17:53 |
| jam | I don't really care what qlog does :) | 17:53 |
| jam | it is also a heck of a lot easier to write by adding more text below | 17:53 |
| vila | --forward.... vade retro performance satanas ! | 17:53 |
| jam | bzr log --short --forward -r -10..-1 is perfectly fast | 17:54 |
| vila | jam: I know your rationale :-) Just mentioning the fact that I sometimes mix things when switching my wet parser :) | 17:54 |
| jam | vila: I suppose we just need to teach vim how to 'invert' a graph :) | 17:57 |
| jam | / => \ etc | 17:57 |
| jam | and swaps the lines around | 17:57 |
| vila | ctrl-w is not cut under xchat...ctrl-w is not cut under xchat...ctrl-w is not cut under xchat...ctrl-w is not cut under xchat... | 17:58 |
| jam | :) | 17:58 |
| jam | I had the same problem with ^L for a while | 17:58 |
| jam | On my Ubuntu machine, Vim had problems displaying all the text, and ^L was refresh | 17:59 |
| vila | jam: or find the right way to inject your ascii art in dot | 17:59 |
| jam | but in Pidgin, ^L is "clear history" | 17:59 |
| jam | which... is painful when talking | 17:59 |
| vila | I'm pretty at swapping ctrl and apple when switching from ubuntu to OSX but sometimes... | 17:59 |
| vila | At least I don't mixup ctrl-backspace with ctrl-alt-backspace anymore.... | 18:00 |
| jam | :0 | 18:00 |
| vila | so, what I had in mind is caching the first children with more than one children for each revision, and yes, this may have to be updated differently, but it will also help a lot for loading graph chunks | 18:13 |
| vila | or avoid loading them | 18:13 |
| jam | vila: do you mean "first ancestor with more than one child"? | 18:16 |
| vila | jam: gee, time to stop, obviously I can't think or write clearly anymore :-/ | 18:16 |
| jam | for my work, I'm tracking "oldest ancestor with only one parent and one child" | 18:16 |
| jam | which is slightly different | 18:17 |
| jam | but fairly important for what I'm doing | 18:17 |
| jam | for http://paste.ubuntu.com/192784/ | 18:17 |
| jam | yours would have all of them point to A | 18:17 |
| jam | mine has the left point to B, and the right point to C | 18:17 |
| jam | Because heads(B, C) == heads(F, G) | 18:18 |
| jam | (sort of) | 18:18 |
| jam | but if you went back to A, you don't know enough | 18:18 |
| jam | anyway, I'm willing to be flexible if we find things that work better | 18:20 |
| jam | that seems to be working for me | 18:20 |
| jam | I think your version could also be interesting | 18:21 |
| jam | I would just need to think more about the implications | 18:21 |
| vila | jam: same here (about flexibility), I need to play a bit with a couple of ideas to better *feel* the implications :-) | 18:34 |
| vila | jam: EOD for me I need still ned to pack for tomorrow | 18:34 |
| jam | vila: interestingly, caching the heads() for linear dominators seems to make "bzr annotate" about 38=>28s | 18:35 |
| vila | a ga bo zu even still need to pack damn :) | 18:35 |
| vila | in the OOo case ? | 18:35 |
| jam | vila: in the "time bzr annotate NEWS" case | 18:35 |
| jam | I'm sure it depends on the structure of the file | 18:36 |
| jam | but NEWS has a lot of history, and a lot of "common introduced" lines to resolve | 18:36 |
| jam | I'm getting 2.3M calls to heads() | 18:36 |
| jam | hmm... only because I was accidentally combining the number of heads() calls with the number of parents stepped... | 19:10 |
| jam | so out of 135k calls to heads(), 126k are exact repeats (calls to revisions we've already resolved), and 7.8k are calls where we already know the dominator resolution | 19:11 |
| jam | leaving only 1.4k times that we actually need to walk the graph | 19:12 |
| jam | which then takes 5s out of 28.5s total time... | 19:13 |
| vadi2 | How do I resolve a conflict where a file with the same name was moved into a folder with another file with the same name? content-wise, they're similar, so I merged content from one into another manually, and deleted the .moved file. however bzr still thinks there is an issue | 19:53 |
| LarstiQ | vadi2: have you called `bzr resolve <file in question>`? | 19:55 |
| vadi2 | Think that did it. Thanks, was just using bzr resolve before | 19:55 |
| AnAnt | Hello, I got a question | 20:31 |
| hmeland | Are anyone else seeing "bzr pull" output like "http://bazaar.launchpad.net/%7Eabentley/bzrtools/bzrtools.dev/ is permanently redirected to file:///home/hmeland/.bazaar/plugins/bzrtools/" when using the current development version og bzr-svn? | 20:31 |
| AnAnt | let's say I want to make changes to some branch lp:~user1/project | 20:31 |
| AnAnt | so I do bzr branch lp:~user1/project | 20:31 |
| AnAnt | which say downloads 60 MB | 20:32 |
| AnAnt | then I do my little changes, and commit, then I want to push to my own branch: bzr push lp:~me/project | 20:32 |
| AnAnt | will that push 60 MB to launchpad ?! | 20:32 |
| Peng_ | AnAnt: With a recent version of bzr and (maybe) a recent branch format, no. | 20:33 |
| AnAnt | Peng_: is 1.13.1 recent ? | 20:33 |
| AnAnt | Peng_: and what format is recent ? | 20:34 |
| AnAnt | Peng_: is pack-0.92 a recent format ? | 20:34 |
| AnAnt | hmmm | 20:35 |
| Peng_ | AnAnt: The feature is called stacking, and it has been supported since bzr 1.6, and the 1.6 disk formats. Newer versions will automatically upgrade the disk format. I don't know if 1.13.1 is new enough. | 20:37 |
| Peng_ | AnAnt: It probably is. Try it and see! | 20:37 |
| AnAnt | ok | 20:37 |
| AnAnt | thanks | 20:39 |
| The_User | Hi! | 20:46 |
| The_User | I think my repository is broken: bzr co file:///myrepo/mybranch | 20:48 |
| The_User | Message: | 20:48 |
| The_User | bzr: ERROR: Revision {<email>-<date>-<charsequence>} not present in "<file or folder>-<date>-<other charsequence>". | 20:48 |
| The_User | When I create a new repository it works. | 20:48 |
| The_User | The error occures in 1.14 and 1.16 (bzr snapshot) | 20:48 |
| The_User | What could I do? | 20:48 |
| Peng_ | The_User: The developers may be able to help you, if you provide them with non-anonymized information. :P | 20:56 |
| jelmer | mwhudson: hi | 20:57 |
| garyvdm | Can a file id contain unicode chars - or will it all ways be ascii? | 20:58 |
| jelmer | garyvdm: they should always be plain string objects, and afaiu they can only contain ascii characters | 21:00 |
| jelmer | but I'm not entirely sure about that last bit | 21:01 |
| garyvdm | jelmer - so if I have to cast from a QString - I can use str()? | 21:01 |
| garyvdm | or should I use unicode()? | 21:01 |
| jelmer | garyvdm: you'd want str() | 21:02 |
| garyvdm | jelmer: Ok thanks | 21:02 |
| jelmer | there shouldn't be a reason for file ids to ever be in a unicode object | 21:02 |
| LarstiQ | garyvdm: you might even need to encode from a QString | 21:03 |
| garyvdm | jelmer: I did test adding a file with unicode chars in its name - and it excluded all the unicode chars from the file-id. | 21:03 |
| garyvdm | no - str(QString) works fine. | 21:04 |
| LarstiQ | garyvdm: hmmm | 21:05 |
| abentley | jelmer, garyvdm: file-ids may have unicode characters in them. | 21:06 |
| garyvdm | abentley - oh | 21:06 |
| jelmer | abentley: ah, ok | 21:06 |
| The_User | @Peng_ I could provide any information but I don't think that you could read the char-sequences, it's the same with different branches but with different filenames and charsequences | 21:06 |
| abentley | garyvdm: If you want to test what's *possible*, rather than default behaviour, use bzrlib. | 21:06 |
| LarstiQ | garyvdm: ah, it seems str(QString) will already encode | 21:06 |
| jelmer | abentley: but always utf8 then? | 21:07 |
| abentley | jelmer: No, unicode. | 21:07 |
| jelmer | abentley: I can't remember ever running across actual unicode objects for file ids in Bazaar API's | 21:07 |
| LarstiQ | garyvdm: str(QString(u"tähti")) → UnicodeEncodeError: 'ascii' codec can't encode characters in position 1-2: ordinal not in range(128) | 21:07 |
| jelmer | abentley: where is that used? | 21:07 |
| garyvdm | LarstiQ: yes | 21:08 |
| The_User | Peng_: bzr log crashes, should I print the backtrace? | 21:08 |
| abentley | jelmer, garyvdm: http://paste.ubuntu.com/192914/ | 21:08 |
| LarstiQ | The_User: pastebin it please | 21:08 |
| The_User | okay | 21:09 |
| abentley | jelmer: I don't claim it's used anywhere. | 21:09 |
| jelmer | abentley: \u doesn't get expanded in a plain string afaik | 21:12 |
| mwhudson | jelmer: yo | 21:12 |
| jelmer | abentley: if I use a unicode object I get an exception about it not being a utf8 string | 21:13 |
| jelmer | mwhudson: you were looking for me earlier, or was that about the qemu-kvm git repo? | 21:13 |
| abentley | jelmer: Cool. I guess they're utf-8 strings these days. | 21:13 |
| mwhudson | jelmer: the ping was before i started sending you email | 21:14 |
| jelmer | mwhudson: ah | 21:15 |
| The_User | LarstiQ: Peng_: I've just removed the email, http://config.fsf.org/trac/public/pastebin/26 | 21:15 |
| LarstiQ | The_User: you missed it at the bottom of the backtrace | 21:16 |
| The_User | LarstiQ: No, it ends with "were doing when the error eccurred" | 21:18 |
| The_User | LarstiQ: Oh sorry, unimportant | 21:19 |
| LarstiQ | The_User: check the KeyError | 21:19 |
| LarstiQ | The_User: you sniped off the actual command, was it a plain `bzr log`, no other arguments? | 21:20 |
| === vxnick_away is now known as vxnick | ||
| The_User | LarstiQ: No other arguments | 21:20 |
| LarstiQ | ok | 21:20 |
| The_User | all information is displayed correctly | 21:21 |
| LarstiQ | The_User: and if you `bzr log -r revid:<that revision>` ? | 21:21 |
| The_User | but then there is the crash | 21:21 |
| The_User | also the checkout is executed (files get copied) but then it aborts | 21:21 |
| The_User | same error with -r revid: | 21:22 |
| The_User | okay the checkout just creates a .bzr directory with some empty files and directories | 21:24 |
| The_User | I think that's interesting: bzr log -p: "bzr: ERROR: bzrlib.errors.NoSuchRevision: KnitPackRepository('file:///repo/.bzr/repository') has no revision" | 21:27 |
| The_User | what could be broken? | 21:28 |
| The_User | it's exactly the same with bzr branch | 21:36 |
| LarstiQ | The_User: I'm a bit low on energy after training, sorry. Could you try `bzr reconcile`? | 21:36 |
| The_User | what does this do? | 21:36 |
| The_User | should I create a backup? | 21:36 |
| The_User | reconcile works in the repo but not in the branch | 21:38 |
| The_User | same keyerror with reconcile, check and log | 21:39 |
| The_User | after reconcile there is only one pack-file in repository/packs | 21:40 |
| The_User | add and commit work without any problems | 21:42 |
| LarstiQ | The_User: meh | 21:43 |
| LarstiQ | The_User: reconcile fixes some inconsistencies and problems like such, but apparently not this one | 21:44 |
| The_User | :( | 21:44 |
| The_User | thanks | 21:44 |
| The_User | learned a new command :D | 21:45 |
| The_User | could bzr updates be a problem? | 21:46 |
| The_User | i mean 1.16 instead of 1.14 or something like that | 21:50 |
| LarstiQ | The_User: shouldn't be | 21:54 |
| LarstiQ | The_User: does it look like https://bugs.edge.launchpad.net/bzr/+bug/355951 ? | 21:54 |
| ubottu | Launchpad bug 355951 in bzr "KeyError when getting revision history" [Undecided,New] | 21:54 |
| LarstiQ | The_User: part of the backtrace looks similar | 21:55 |
| poolie | good morning | 22:03 |
| LarstiQ | hello poolie | 22:05 |
| LarstiQ | poolie: do you maybe have time to help The_User with http://config.fsf.org/trac/public/pastebin/26 (perhaps bug 355951 ?) | 22:05 |
| ubottu | Launchpad bug 355951 in bzr "KeyError when getting revision history" [Undecided,New] https://launchpad.net/bugs/355951 | 22:05 |
| LarstiQ | getting things rolling atleast | 22:06 |
| === The_User is now known as The_User|afk | ||
| === The_User|afk is now known as The_User | ||
| poolie | The_User: I think it is a dupe of bug 355951 | 22:25 |
| ubottu | Launchpad bug 355951 in bzr "KeyError when getting revision history" [Undecided,New] https://launchpad.net/bugs/355951 | 22:25 |
| poolie | or rather you are hitting that bug | 22:25 |
| poolie | The_User: could you please paste your traceback onto that bug | 22:25 |
| poolie | and probably subscribe yourself | 22:25 |
| poolie | and then also the output from 'bzr info' on that branch | 22:25 |
| === The_User is now known as The_User|afk | ||
| === The_User|afk is now known as The_User | ||
| === Kissaki^0ff is now known as Kissaki | ||
| === The_User is now known as The_User|afk | ||
| poolie | jml: today it's all about https://bugs.edge.launchpad.net/bzr/+milestone/1.16 | 23:39 |
| === poolie changed the topic of #bzr to: Bazaar version control system | 1.15.1 released 09 | ||
| poolie | June, 2009 | http://bazaar-vcs.org | http://irclogs.ubuntu.com/ | | 23:39 |
| poolie | http://planet.bazaar-vcs.org/ | 23:39 |
| jml | poolie: yes. :) | 23:39 |
| poolie | June, 2009 | http://bazaar-vcs.org | http://irclogs.ubuntu.com/ | today's focus: https://bugs.edge.launchpad.net/bzr/+milestone/1.16 | 23:39 |
| poolie | silly irssi | 23:39 |
| jml | poolie: once I get out of Launchpad meetings :) | 23:39 |
| poolie | and i filed bug 385719 :) | 23:39 |
| ubottu | Launchpad bug 385719 in malone "hard to navigate to milestone bug page" [Undecided,New] https://launchpad.net/bugs/385719 | 23:39 |
| jml | hard. pshaw. | 23:41 |
| jml | I do it all the time :) | 23:41 |
| * mwhudson does it by editing the url :/ | 23:46 | |
| poolie | by typing? | 23:46 |
| mwhudson | yeah | 23:47 |
| mwhudson | well, for launchpad-code, i have lots of launchpad-code milestones in the history | 23:47 |
| mwhudson | so find one and change the version | 23:47 |
| poolie | jam, are you still around? just wanted to say hi | 23:47 |
| poolie | oh i was asking jml | 23:47 |
| jml | poolie: front page of project -> click the link | 23:48 |
| jml | poolie: but also URL hacking | 23:48 |
| poolie | yeah, it's actually fairly obvious from the project homepage, but i tend to think of it as an aspect of bugs | 23:50 |
| poolie | and from bug pages it's hard to reach | 23:51 |
| jml | poolie: so, I'm out of LP meetings now :) | 23:55 |
| jml | poolie: maybe we should have a call in an hour or so? | 23:56 |
| jml | (gives me a chance to handle email etc) | 23:56 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!