| james_w | mwhudson: thanks for the pointer to iolaus | 01:37 |
|---|---|---|
| james_w | lifeless: sounds similar to some of the ideas you were telling me about: http://github.com/droundy/iolaus | 01:38 |
| * james_w crashes | 01:38 | |
| jelmer | \o/ it's in haskell | 01:43 |
| lifeless | james_w: yes, there are similarities | 01:46 |
| poolie | igc, re bug 524177 | 01:47 |
| ubottu | Launchpad bug 524177 in bzr "Doc rebuilds are deleting chm files" [Undecided,New] https://launchpad.net/bugs/524177 | 01:47 |
| poolie | is that some kind of problem with the scripts on escudero? | 01:47 |
| poolie | also, when you file bugs, can you please triage them too? | 01:48 |
| poolie | no point making someone else reopen the bug to do it | 01:48 |
| poolie | spiv, maybe at the end of the eintr thread we should add something about it to the developer guide | 01:55 |
| spiv | poolie: yeah | 01:56 |
| spiv | poolie: and, assuming we keep until_no_eintr (which I think we need to for reading from pipes at least), put a very clear warning in its docstring. | 01:56 |
| spiv | Probably with a pointer to full treatment in the developer guide. | 01:56 |
| poolie | hm | 01:57 |
| poolie | so until_no_eintr is a bit dangerous because it's highly likely to be needed on functions that can return partial results | 01:58 |
| poolie | and you need to loop separately on them too | 01:58 |
| poolie | perhaps | 01:58 |
| poolie | i suppose it's not actively dangerous, just often not sufficient | 01:58 |
| poolie | so a patch that describes the way these things should be handled might be a good way to get to agreement with gzlist | 01:58 |
| poolie | just an idea | 01:58 |
| poolie | also | 01:58 |
| poolie | we could add a test_source for known broken apis | 01:59 |
| spiv | Right, so until_no_eintr is right for things that are very close to the underlying syscall, or at least std libc, interface. | 02:02 |
| spiv | But as soon as you have any layers between that and until_no_eintr it's probably wrong. | 02:03 |
| spiv | And you either need to push the eintr handling down into a lower layer, or use a different API entirely. | 02:03 |
| spiv | I think I am converging on agreement with gzlist. | 02:04 |
| spiv | There was a disconnect because he wasn't aware of the pipe.read issue being a valid and appropriate use of until_no_eintr, so he was of course sure the right thing was to rip out until_no_eintr, whereas I was of course sure we still wanted it :) | 02:05 |
| spiv | I'm not aware of a better alternative for the pipe.read than just wrapping it in until_no_eintr, but if one comes up we can evaluate that. | 02:05 |
| lifeless | freetown2: hmm, 350mb apt-get update | 02:11 |
| lifeless | erem grade. | 02:11 |
| poolie | lifeless: ? | 02:19 |
| lifeless | poolie: lucid moving fast | 02:19 |
| === _thumper_ is now known as thumper | ||
| parthm | poolie: I am going through your review comment https://code.launchpad.net/~parthm/bzr/2.0_376388_dot_bazaar_ownership/+merge/19593 | 03:37 |
| parthm | Does http://pastebin.com/m4d62c257 seem like a reasonable approach in osutils? | 03:37 |
| parthm | I also plan to add osutils.open that optionally takes ownership_src arg. This can then be used succintly for creating files like log and conf. | 03:38 |
| poolie | parthm: that looks pretty reasonable | 03:53 |
| poolie | parthm: raise just one warning when it fails, and use trace.warning not warnings.warning | 03:55 |
| parthm | OK. Thanks. | 03:55 |
| parthm | I saw your comment regarding making this patch for trunk. That sounds fine to me. I am thinking that for now I will continue working on the same branch so that review comments are not lost. Then it can be merged up? | 03:57 |
| poolie | yep | 03:58 |
| parthm | One more question, is there a doc that lists the dependencies we need to have in order to hack bzr? I have been installing packages seperately one at a time as I hit issues (pyrex, testtools, pyftpdlib, subunit etc.). | 03:59 |
| parthm | Due to time some tests also get skipped. | 03:59 |
| poolie | is this on ubuntu? | 04:00 |
| poolie | the easiest way is to say 'apt-get build-deb bzr' | 04:00 |
| spiv | Theoretically the INSTALL file should list the dependencies, but that part of it seems to be out of date. | 04:02 |
| parthm | Yes. Its ubuntu. build-deb sounds good. Thanks. | 04:04 |
| parthm | Yes. INSTALL does look out of date :) | 04:05 |
| poolie | parthm: what do you think of http://pastebin.ubuntu.com/379525/ | 04:50 |
| poolie | are there any other questions it should answer? | 04:50 |
| parthm | poolie: This certainly answers most of my. I wasn't aware of the appendpath trick. Maybe we can have pointers for getting further help (irc, mailing list). Specifically I faced a problem getting into irc (i am new to it) as it required a registered nick, I kept getting "cannot send" messages before I googled and realized what was happening. | 05:00 |
| poolie | yeah that kind of sucks actually | 05:00 |
| poolie | i'll add some pointers | 05:00 |
| parthm | Maybe somewhere a tip can be put in regarding avoiding "resubmit merge request" as comments are lost. I made that mistake. | 05:01 |
| parthm | The doc looks good. | 05:02 |
| parthm | I seem to have hit upon an interesting situation. http://pastebin.ubuntu.com/379534/ Not sure what I did (maybe ^C of some test?), I ended up with some unknown file/dir which don't exist on disk. How do I get rid of it? | 05:07 |
| spiv | parthm: that's pretty weird. | 05:11 |
| poolie | lifeless: did you or anyone already register #bzr with freenode? | 05:14 |
| lifeless | poolie: yes years ago | 05:18 |
| poolie | did you register the group too? | 05:19 |
| lifeless | don't know what you mean | 05:20 |
| poolie | ok, that works | 05:20 |
| lifeless | I've just added you to the channel access list though | 05:20 |
| poolie | http://freenode.net/group_registration.shtml#groupcontacts | 05:20 |
| lifeless | what does that mode do ? | 05:21 |
| poolie | allows non-registered users to talk | 05:22 |
| poolie | isn't it obvious? ;-) | 05:22 |
| parthm | Nice :) | 05:22 |
| lifeless | poolie: no, its not :P | 05:22 |
| lifeless | poolie: you might like to drop op though; and tell chanserv the mode bits you want, otherwise netsplits can confuse things. | 05:23 |
| === ubott2 is now known as ubottu | ||
| lifeless | poolie: [dropping op because freenode frown on folk sitting with op on for extended durations, telling chanserv so that it sticks properly] | 05:23 |
| poolie | ok | 05:24 |
| poolie | > freenode frown on folk sitting with op on for extended durations | 05:24 |
| poolie | why? | 05:24 |
| lifeless | something about community spirit; I don't recall really. | 05:25 |
| lifeless | http://freenode.net/using_the_network.shtml | 05:25 |
| lifeless | Use the chanserv "op" command to obtain channel operator status only when needed. This will help to keep your channel temperature low and reduce conflicts. | 05:25 |
| lifeless | </quote> | 05:25 |
| parthm | poolie: I plan to send a new merge request for 2.0_376388_dot_bazaar_ownership against the trunk. Its seems overrideAttr are not available in 2.0. I will be using them for writing the tests as you suggested. | 05:25 |
| poolie | hm | 05:26 |
| lifeless | poolie: /msg chanserv access #bzr list -- thats what I looked at when you asked, and you weren't there so I did | 05:26 |
| poolie | yeah, i see | 05:26 |
| lifeless | access #bzr add poolie | 05:26 |
| poolie | i think all the core devs should have access | 05:26 |
| lifeless | I don't know if that makes you fully-capable; I don't know enough to tell. | 05:26 |
| lifeless | I suggest you try adding e.g. jam | 05:27 |
| poolie | 'flags #bzr' gives more linenoise | 05:27 |
| lifeless | if you can't I'll dig deeper to find out how to make you as-capable as me | 05:27 |
| poolie | hang on | 05:27 |
| poolie | so you have also sRA bits | 05:28 |
| lifeless | I don't know what they mean | 05:28 |
| poolie | and f | 05:28 |
| lifeless | I didn't want to randomly type stuff in until I check | 05:28 |
| lifeless | are you able to add jam ? | 05:29 |
| poolie | oh go on :-P | 05:29 |
| cody-somerville | +f - Enables modification of channel access lists. | 05:29 |
| cody-somerville | +F - Grants full founder access. | 05:29 |
| poolie | send chanserv help flags | 05:29 |
| poolie | so i think i can't grant access, but i'll try | 05:29 |
| poolie | yeah, i can't grant rights | 05:30 |
| poolie | so i think i need you to do | 05:30 |
| poolie | flags #bzr poolie +* | 05:31 |
| lifeless | poolie: you look the same as me now | 05:31 |
| poolie | ew | 05:31 |
| poolie | sweet, thanks | 05:31 |
| cody-somerville | poolie, lifeless: You guys should get the +F flag from Christel (who is a freenode staff member IIRC). | 05:32 |
| lifeless | cody-somerville: thanks for helping out | 05:32 |
| poolie | cody-somerville: by asking christel, i suppose? | 05:33 |
| * cody-somerville nods. | 05:33 | |
| cody-somerville | lifeless, Is that a polite way of telling me to bugger off? :=) | 05:33 |
| poolie | seems away atm | 05:33 |
| poolie | no, seriously, thanks | 05:33 |
| cody-somerville | If you guys register yourself as a group, you can get your own cloaks and then you grant anyone with that cloak certain privileges (ie. ops). | 05:34 |
| Kamping_Kaiser | jelmer: out of intrest, does that subvertpy test need disabling in testing/unstable or only stable? | 05:34 |
| poolie | cody-somerville: right, i was just asking about that too | 05:34 |
| poolie | i wonder if we should register our own group or be subsidiary to canonical | 05:34 |
| lifeless | cody-somerville: no, its me saying thanks | 05:34 |
| poolie | istr some mail about this | 05:34 |
| lifeless | cody-somerville: I so rarely look at IRC modes it all pages out. | 05:34 |
| lifeless | poolie: I think we should be like ubuntu, or perhaps subsidiary to ubuntu - more than staff can help. | 05:35 |
| lifeless | cody-somerville: besides which, I have no politeness chip. | 05:35 |
| poolie | their policy seems to prefer a company | 05:35 |
| lifeless | whose? | 05:36 |
| poolie | freenode's policy | 05:37 |
| lifeless | hmm, odd. | 05:37 |
| poolie | ok, so it's filed now | 05:37 |
| poolie | we'll see | 05:37 |
| cody-somerville | poolie, Ubuntu is a registered group. | 05:37 |
| poolie | i'm glad that's sorted | 05:37 |
| poolie | ok, i tried to register Bazaar c/o Canonical | 05:37 |
| cody-somerville | poolie, You have a cloak of canonical/launchpad/poolie | 05:37 |
| poolie | and i granted flags to some core devs | 05:38 |
| lifeless | cody-somerville: are cloaks like bitmasks ? | 05:38 |
| cody-somerville | lifeless, They mask your hostname | 05:38 |
| lifeless | yes I know that | 05:38 |
| lifeless | but their value | 05:38 |
| lifeless | can you have e.g. canonical/launchpad/ubuntu/fsf/bazaar/lifeless | 05:38 |
| lifeless | oh, add debian | 05:39 |
| poolie | i think they are hierarchical | 05:39 |
| lifeless | hmm thats a bit annoying | 05:39 |
| lifeless | community membership is more setlike | 05:39 |
| poolie | one propeller beanie at a time please | 05:39 |
| lifeless | or can you choose amongst many cloaks you have permission to use ? | 05:39 |
| lifeless | (at login time I mean) | 05:40 |
| cody-somerville | You can only have one but you can combine them - although its a bit awkward. | 05:40 |
| cody-somerville | Some people have: pdcp/supporter/ubuntu/member/$nick | 05:41 |
| cody-somerville | and what not. | 05:41 |
| poolie | k | 05:42 |
| poolie | so more to the point is """[+o] attracts the attention of participants who react negatively to authority. Have your nick added to the channel access list and op yourself only when needed. """ | 05:42 |
| lifeless | http://web.media.mit.edu/~marcelo/cornucopia/ | 05:43 |
| mneptok | poolie: OH, LOOK AT *YOU*, MISTER IMPORANT! | 05:43 |
| poolie | see | 05:43 |
| * mneptok pouts in the corner | 05:43 | |
| * cody-somerville recommends a script created by Dennis Kaarsemaker, http://www.kaarsemaker.net/downloads/code/chanserv.py | 05:43 | |
| parthm | I am getting two failures while running blackbox selftest on unmodified trunk http://pastebin.ubuntu.com/379546/ . Is this expected? | 05:44 |
| mneptok | IIRC, i had a /canonical/staff Freenode cloak when i was an employee | 05:44 |
| lifeless | cody-somerville: sadly its for xchat :P | 05:44 |
| lifeless | parthm: no, because pqm selftests trunk on every commit | 05:45 |
| mneptok | i think "canonical/staff/bzr" would look sexy on poolie | 05:46 |
| poolie | that's pretty strange | 05:46 |
| poolie | i pick up my wizard staff and cloak | 05:46 |
| spiv | parthm: hmm, both in "expectFailure" | 05:46 |
| mneptok | while lifeless should get canonical/staff/i/get/around/more/than/a/monaco/hooker | 05:46 |
| spiv | parthm: what version of testtools do you have? | 05:47 |
| poolie | k | 05:47 |
| poolie | so that's done | 05:47 |
| lifeless | mneptok: how much does a monaco hooker get around? | 05:47 |
| poolie | now i don't need to document | 05:47 |
| parthm | spiv: testtools-0.9.2. I installed it locally from a downloaded tarball. | 05:47 |
| poolie | ok, i think this ^^ is exactly what i was reading about inappropriate behaviour :) | 05:47 |
| mneptok | lifeless: my memories of that time in my life are kinda hazy ... | 05:47 |
| mneptok | wait ... was that out loud? | 05:48 |
| poolie | but presumably in their maserati | 05:48 |
| spiv | parthm: hmm, that's what I have (well, a deb saying 0.9.2-1, from the bzr PPA IIRC) | 05:48 |
| lifeless | spiv: doesn't look like testtools to me ? | 05:48 |
| lifeless | its interesting that some extensions are not built | 05:49 |
| lifeless | parthm: try running 'make' | 05:49 |
| * parthm running tests again after make | 05:50 | |
| spiv | parthm, lifeless: FWIW, trunk with and without extensions passes those tests for me, as known_failure | 05:50 |
| lifeless | ah | 05:51 |
| lifeless | could be testtools then, but that version should be fine | 05:51 |
| parthm | I see the same failures even after make. :( | 05:51 |
| lifeless | parthm: are you sure that version of testtools is being loaded? | 05:51 |
| spiv | parthm: what if you don't use --parallel=fork? | 05:52 |
| spiv | (and what version of subunit?) | 05:52 |
| poolie | parthm: you can vote on https://code.edge.launchpad.net/~mbp/bzr/doc/+merge/19682 if you want; I put in your suggestions | 05:52 |
| lifeless | oh, I didn't realise subunit was in there. Smells like an old subunit perhaps. | 05:52 |
| spiv | lifeless: neither did I at first, but parthm sensibly included the command line in the paste :) | 05:52 |
| parthm | lifeless: Yes. I see the correct path in the error log. | 05:52 |
| parthm | subunit is 0.0.2 from packages | 05:53 |
| lifeless | poolie: as a potential user, you might like https://code.edge.launchpad.net/~lifeless/testresources/bug-522338/+merge/19684 | 05:54 |
| lifeless | parthm: thats pretty old | 05:54 |
| lifeless | parthm: what platform are you on? | 05:54 |
| parthm | poolie: will do. thanks. | 05:54 |
| parthm | lifeless: I am using ubuntu 9.10 | 05:55 |
| parthm | will run again w/o fork. | 05:55 |
| lifeless | parthm: you might want to grab the subunit PPA, it has newer subunit, testtools all packaged | 05:57 |
| poolie | maybe we should add a version assertion to bzr? | 05:58 |
| lifeless | poolie: it doesn't turn up all that often. We can if you like | 05:58 |
| poolie | maybe next time | 05:58 |
| parthm | yep. subunit was the problem. all tests pass without fork. will install the latest ppa. | 06:00 |
| parthm | i agree with poolie, it would be good to have a version check. for someone new to bzr codebase its very helpful if the error message clearly indicates this. | 06:01 |
| parthm | thanks for the help | 06:01 |
| parthm | got to go. have a nice day! | 06:31 |
| Kamping_Kaiser | james_w: bzr-builddeb from testing fails to build on stable ( http://paste.debian.net/60457/ ). Would this be a dependencies issue, or is the setup.py file actually broken? | 06:38 |
| quicksilver | Hmm. bzr missing defaults to 80 cols with no terminal on stdout? | 06:39 |
| quicksilver | that seems nasty. | 06:39 |
| lifeless | quicksilver: it defaults to your terminfo | 06:40 |
| lifeless | and if there is no terminal, we use something that will often be sensible | 06:40 |
| lifeless | Kamping_Kaiser: possibly a parser change in rst | 06:41 |
| quicksilver | I'd hoped --line would default to infinitely long lines | 06:41 |
| quicksilver | (if there was no terminal) | 06:41 |
| lifeless | we did that for about 3 days | 06:41 |
| lifeless | after gigabytes of output in test runs it got changed | 06:41 |
| quicksilver | ok :) | 06:41 |
| lifeless | I can see your argument, perhaps file a bug - we may have solved our issue the wrong way. | 06:42 |
| Kamping_Kaiser | lifeless: rst? | 06:42 |
| lifeless | you could mention that other tools defaults to no-apparent-limit (if they do) | 06:42 |
| lifeless | Kamping_Kaiser: ReST - restructured text | 06:42 |
| Kamping_Kaiser | oh | 06:42 |
| lifeless | the language README is written ni | 06:43 |
| mneptok | NI! | 06:43 |
| Kamping_Kaiser | lifeless: would that be bzr's rest parser? I'll check the changelog incase theres some info | 06:43 |
| lifeless | no | 06:43 |
| lifeless | python module | 06:43 |
| Kamping_Kaiser | ok | 06:43 |
| quicksilver | lifeless: what I'm actually doing is writing a command line tool to analyse a bunch of repos with --missing and deduce some things about their topology. | 06:45 |
| quicksilver | lifeless: like, which ones have already been merged into "mainline", and which of the non-merged ones shared common parents, etc | 06:45 |
| quicksilver | lifeless: are you aware of any prior art? | 06:46 |
| lifeless | quicksilver: bzr removable | 06:51 |
| Kamping_Kaiser | lifeless: looks like its a stray space. whats the preferred way of submitting trivial changes? patch? bzr branch? | 06:53 |
| quicksilver | lifeless: thanks. Interesting. I had slightly more ambitious plans but that's definitely the basic function. | 06:57 |
| Kamping_Kaiser | (used a patch :)) | 07:01 |
| lifeless | Kamping_Kaiser: 'whatever works' | 07:24 |
| lifeless | poolie: the apt-cache policy bug is committed to apt trunk | 07:50 |
| poolie | great | 07:51 |
| lifeless | very small patch for being open for 5 years :( | 07:55 |
| poolie | many are | 07:55 |
| poolie | i'd like to do a scatterchart of (open_time,close_time) | 07:55 |
| ejat | hi .. anyone can help me with this bug 524269 | 08:00 |
| ubottu | Launchpad bug 524269 in bzr "cant bzr update in development trunk" [Undecided,New] https://launchpad.net/bugs/524269 | 08:00 |
| naoki_ | Hi | 08:03 |
| naoki_ | http://paste.ubuntu.com/379585/ | 08:03 |
| naoki_ | bzr branch svn+ssh://... fails on Windows. | 08:04 |
| naoki_ | I think it isn't a bug of bzr-svn. | 08:07 |
| ejat | lifeless: thanks for changing the description .. so confirm its a bugs ? | 08:14 |
| lifeless | ejat: doubt it | 08:17 |
| lifeless | ejat: I suspect you're missing ca-certificates or something | 08:18 |
| naoki_ | I read strace. All opened fd is closed correctly. | 08:19 |
| naoki_ | I can't find a suspect. | 08:19 |
| poolie | naoki_: hello! | 08:20 |
| lifeless | naoki_: disable your virus scanner | 08:20 |
| poolie | the first error looks like one we fixed recently | 08:20 |
| poolie | lifeless: you're probably right but that's such a bad thing to have to say :-/ | 08:21 |
| lifeless | naoki_: its not hooking in at a low enough level, so it is interfering with normal system calls | 08:21 |
| lifeless | poolie: it is; I blame microsoft. | 08:21 |
| ejat | lifeless: sorry .. after upgrade .. im missing the bzr-svn .. after reinstall bzr-svn .. working fine | 08:23 |
| ejat | lifeless: can i change the status to invalid ? | 08:26 |
| lifeless | I hope so | 08:27 |
| poolie | lifeless: i mean other apps must hit this | 08:29 |
| poolie | writing a file then reading it is not such a strange thing to do | 08:29 |
| poolie | perhaps we should show a message and block | 08:30 |
| lifeless | poolie: sure | 08:30 |
| naoki | In linux, strace shows close() correctly. | 08:41 |
| naoki | But in Windows, Process Monitor desn't show CloseFile! | 08:41 |
| poolie | interesting | 08:42 |
| naoki | http://paste.ubuntu.com/379598/ | 08:43 |
| naoki | In line 86, CreateFile failse. (rename) | 08:44 |
| naoki | In line 85, WriteFile happens to pack file. | 08:44 |
| naoki | There are no CloseFile between line 85 and 86. | 08:45 |
| naoki | http://paste.ubuntu.com/379599/ | 08:45 |
| naoki | This is strace in Linux. | 08:46 |
| naoki | write(7, "E", 1) is writing 1 byte. | 08:47 |
| naoki | next, close(7), and then, rename() happens. | 08:47 |
| lifeless | poolie: I've fixed the sort performance in testresources | 09:14 |
| poolie | mm i saw | 09:14 |
| poolie | i wonder if the effort estimates are actually accurate enough that it's worth sorting carefully | 09:15 |
| lifeless | poolie: well, it takes 0.02 seconds to sort for u1 now | 09:20 |
| lifeless | so there is room to grow :P | 09:20 |
| lifeless | anyhow, its not sorting carefully now | 09:20 |
| lifeless | its sorting quickly | 09:20 |
| lifeless | poolie: you might find http://www.youtube.com/watch?v=1HatEDkNnn8 and the related videos interesting | 09:42 |
| poolie | igc, you really don't have to finish the explorer bug tonight | 09:51 |
| jelmer | Kamping_Kaiser, it needs disabling when subvertpy is built against svn < 1.5 | 10:08 |
| Kamping_Kaiser | jelmer: <= or < ? I thought i had 1.5.1, since its a stable system | 10:10 |
| jelmer | Kamping_Kaiser, < | 10:10 |
| Kamping_Kaiser | hmm. most odd. | 10:10 |
| naoki | I want subvertpy binary package... | 11:11 |
| jelmer | naoki: for windows you mean? | 11:11 |
| naoki | Yes | 11:11 |
| jelmer | naoki: Isn't subvertpy included in the windows installer? | 11:11 |
| naoki | Yes. But I test bzr-svn with python2.6 and python2.5 I have. | 11:12 |
| naoki | Yes. But I'd like to test bzr-svn with python2.6 and python2.5 I have. | 11:12 |
| naoki | Wow! I can build subvertpy! | 11:19 |
| naoki | I can reproduce svn+ssh: problem with Python 2.6... | 11:23 |
| jelmer | which problem? | 11:25 |
| naoki | In Windows, bzr branch svn+ssh://.../foo foo fails. | 11:28 |
| naoki | svn+http is OK. In Linux, all OK | 11:28 |
| naoki | traceback is http://paste.ubuntu.com/379585/ | 11:29 |
| naoki | strace in Linux is http://paste.ubuntu.com/379598/ | 11:29 |
| naoki | Procmon in Windows is http://paste.ubuntu.com/379599/ | 11:29 |
| naoki | In Linux, close() called after last 1-byte write() | 11:29 |
| naoki | In Windows, CloseFile() isn't called after last 1-byte WriteFile() | 11:30 |
| naoki | So rename() fails. | 11:31 |
| jelmer | naoki: that doesn't seem related to bzr-svn | 11:36 |
| jelmer | it happens deep down in bzrlib (though it's perhaps masking another error from bzr-svn) | 11:36 |
| lifeless | naoki: have you tried turning off your virus scanner? just to see? | 11:37 |
| naoki | I've disabled auto-protect feature in AntiVirus. But I can't totally disable AntiVirus because I am using my company's PC. | 11:40 |
| lifeless | the lack of a close is interesting though | 11:41 |
| lifeless | perhaps a generator in the svn side not completing appropriately | 11:41 |
| === jayne_ is now known as jayne | ||
| radoe | jelmer: is the usage of --layout=trunkX (like trunk2) documented somewhere? | 12:20 |
| === mrevell is now known as mrevell-lunch | ||
| jelmer | radoe: What layouts are available you mean? | 12:26 |
| jelmer | "bzr help svn-layout" | 12:26 |
| radoe | jelmer: no, I had to used --layout=trunk2 to be able to svn-import a somewhat weird svn repo. And Ihad to look into the source to figure this out, as it is not mendtioned anywhere. bzr help svn-layout only mentions trunk without an additional level. | 12:28 |
| radoe | Hm, my connection has some serios lag, sorry for the typos... | 12:29 |
| jelmer | the 2 just means two levels of directories before the actual branches | 12:30 |
| radoe | jelmer: yes, I figured this out, but had to look into the sources to get it. And I'm not sure why I had to use it anyway, because my trunk/branches are directly below the URL I specified. Let me explain about layout used in SVN a bit... | 12:34 |
| radoe | jelmer: The repo root used is svn+ssh://app/svn/instsrv. The repository has a /packages directory, which holds individual packages, like nagios-client | 12:36 |
| radoe | jelmer: so I tried to svn-import like "bzr svn-import svn+ssh://somehost/app/svn/instsrv/packages/nagios-client" | 12:37 |
| radoe | jelmer: and got the error " | 12:37 |
| radoe | "bzr: ERROR: The specified path is inside a branch." | 12:38 |
| jelmer | radoe: svn-import imports all branches in a repo or all branches under a specific directory | 12:38 |
| jelmer | radoe, it looks like you're trying to retrieve an individual branch | 12:38 |
| radoe | jelmer: i had to specify layout=trunk2, simply trunk did not work (same error) | 12:38 |
| jelmer | radoe: for an individual branch, use "bzr branch svn+ssh://somehost/app/svn/instsrv/packages/nagios-client nagios-client" | 12:39 |
| radoe | jelmer: well, like I said, the repo is somewhat weired. It holds different packages below /packages, each with trunk and branches. | 12:40 |
| jelmer | radoe, what is the repo root? | 12:41 |
| radoe | jelmer: svn+ssh://somehost/app/svn/instsrv/ | 12:42 |
| jelmer | radoe, does it say it's using trunk2 when it starts? | 12:43 |
| radoe | jelmer: I had to specify trunk2 explicitly like in "bzr svn-import --layout=trunk2 svn+ssh://rdoering@zsl01/app/svn/instsrv/packages/nagios-client" to get what I want. | 12:46 |
| jelmer | radoe: Does the repository also have parts that do not follow the branches/tags/trunk convention? | 12:46 |
| jelmer | or perhaps at different levels? | 12:47 |
| jelmer | that would confuse the heuristics | 12:47 |
| radoe | jelmer: possible, let me check... | 12:48 |
| radoe | jelmer: below /packages/*/ there is always a trunk, only some have a branches/ dir | 12:50 |
| jelmer | radoe, and packages is the only top-level directory? | 12:50 |
| radoe | jelmer: no, I'm lookiong at the others currently. | 12:51 |
| radoe | jelmer: ah, in parallel to /packages there are two directories which qualify for trunk1 layout. | 12:52 |
| Ng | why would bzr think a file has been removed/added when its md5sum hasn't changed? | 13:01 |
| Peng | Because you did "bzr rm" and "bzr add"? | 13:02 |
| Peng | Or an equivalent merge? | 13:02 |
| Peng | There's more to a file's identity than its contents. | 13:02 |
| Ng | I'm merging an update from my pristine upstream branch into my local modified branch, but I haven't explicitly rm'd/add'd these files | 13:02 |
| Ng | normally when I do this it just merges in the upstream changes | 13:02 |
| beuno | Ng, maybe the merge deletes it? | 13:03 |
| Ng | http://paste.ubuntu.com/379718/ that's the pristine branch, with a diff of the revision that relates to the bzr import of the new release zip | 13:04 |
| Ng | skipping down to the bottom of that, version.php - after the merge that change shows up as a full conflict | 13:04 |
| Ng | not the whole file, just that one line. I'm sure that's within bzr's merging abilities, it always has been before | 13:05 |
| Ng | I wonder if this is some subtle, barely visible side effect of bzr import | 13:05 |
| beuno | hm | 13:07 |
| beuno | james_w may know | 13:10 |
| james_w | whu? | 13:11 |
| james_w | Ng: I'm not too sure | 13:13 |
| james_w | Ng: why do you say bzr thinks a file has been removed/added? | 13:14 |
| Ng | james_w: hmm, that might actually just be fallout from trying to correct the conflicts. I just branched afresh and did the merge and it looks more like it thinks that lots of files that are already in the branch have been added | 13:15 |
| naoki | I got it! | 13:16 |
| naoki | plink.exe have an pack file handle! | 13:16 |
| james_w | Ng: can you show me the bzr status of the fresh merge? | 13:16 |
| Ng | james_w: http://paste.ubuntu.com/379723/ is the merge itself, http://paste.ubuntu.com/379724/ is bzr st | 13:17 |
| moldy | hi | 13:17 |
| james_w | Ng: it seems like the root id of your tree changed somehow | 13:18 |
| james_w | that's not usual | 13:18 |
| moldy | is there decent bzr completion for zsh yet? | 13:18 |
| james_w | Ng: I assume that you don't do anything odd on your branch, and the pristine branch just uses "bzr import" each new version? | 13:18 |
| Ng | james_w: correct | 13:20 |
| james_w | Ng: care to run a couple of bits of python for me? | 13:21 |
| Ng | james_w: sure :) | 13:22 |
| james_w | Ng: python -c "from bzrlib.branch import Branch; print Branch.open('.').basis_tree().path2id('')" | 13:23 |
| james_w | run that in both branches | 13:23 |
| Ng | james_w: both say TREE_ROOT | 13:24 |
| james_w | oddness | 13:25 |
| james_w | Ng: not different tree roots then apparently | 13:25 |
| james_w | lets try all the file ids changing | 13:25 |
| james_w | python -c "from bzrlib.branch import Branch; print Branch.open('.').basis_tree().path2id('license.txt')" | 13:25 |
| james_w | in both again please | 13:26 |
| Ng | ok those are different | 13:26 |
| === mrevell-lunch is now known as mrevell | ||
| james_w | ok | 13:27 |
| james_w | python -c "from bzrlib.branch import Branch; b = Branch.open('.'); rev = b.revision_history()[-2]; print b.repository.revision_tree(rev).path2id('license.txt')" | 13:27 |
| james_w | that in the pristine branch please | 13:27 |
| james_w | should print the same as the working branch did | 13:27 |
| Ng | huh, no, it's still different | 13:30 |
| Ng | I can make both branches available if that would be helpful, there's nothing secret in either | 13:33 |
| Ng | I hope the answer isn't that I'm doing something stupid ;) | 13:33 |
| james_w | I can take a look | 13:34 |
| james_w | easier than IRC-RPC | 13:34 |
| Ng | hehe | 13:35 |
| Ng | http://mairukipa.tenshu.net/~cmsj/bzr-wat.tgz - "www" is the working tree, "wordpress" is the upstream imports | 13:35 |
| naoki | Ping: jelmer | 13:37 |
| jelmer | naoki: pong | 13:37 |
| naoki | I foud ssh client have "upload/xxxxx.pack" handle. | 13:38 |
| naoki | I tried cygwin ssh and plink (PuTTY) | 13:38 |
| naoki | Both client have pack file handle. | 13:38 |
| naoki | bzr branch from svn+ssh success if I kill ssh client before renaming ".pack" file. | 13:39 |
| naoki | Is there any way to kill source.transport connection before groupcompress? | 13:40 |
| naoki | Or bzrlib should not rename but copy .pack file? | 13:40 |
| jelmer | naoki: why would that be necessary? | 13:40 |
| naoki | Because commit_write_group() renames .bzr/repository/upload/randomname.pack | 13:42 |
| naoki | So ssh client should not have the handle of the file. | 13:42 |
| bialix | hi naoki, jelmer | 13:45 |
| naoki | hi | 13:45 |
| jelmer | naoki: The ssh client doesn't handle the bazaar packs at all | 13:45 |
| naoki | I don't know why ssh client have a handle of pack file. | 13:46 |
| naoki | But procmon tells me the ssh client have the handle. | 13:46 |
| naoki | And I success to branch when I kill the ssh client. | 13:46 |
| bialix | naoki, can you convert your patch for unicode Popen to merge proposal? | 13:48 |
| bialix | this is related to bzrlib | 13:48 |
| naoki | Okey, I'll do. bialix | 13:49 |
| bialix | naoki: about SSH: do you have a real reasons to prefer plink over pageant? | 13:49 |
| naoki | I use pagent daily. So I set SVN_SSH=plink. | 13:50 |
| naoki | Is there way to use paramiko with ssh? | 13:50 |
| naoki | I've tried http://sshwindows.sourceforge.net/ | 13:51 |
| naoki | But ssh.exe also grip a handle of pack file. | 13:52 |
| bialix | sorry, I meant paramiko | 13:52 |
| naoki | Very very strange.. | 13:52 |
| bialix | svn has no pack files, right? | 13:53 |
| naoki | Procmon tells me only ssh client have the handle when renaming. | 13:53 |
| naoki | # I added "time.sleep(100)" in front of rename() | 13:54 |
| jelmer | naoki: It's inheriting handles from the parent process perhaps? | 13:54 |
| naoki | Oh | 13:56 |
| naoki | How libsvn sucks! | 13:56 |
| jelmer | naoki: I don't know, just speculating | 13:58 |
| naoki | Can paramiko do port forward? | 14:02 |
| naoki | sorry, port forward cant convert svn+ssh://remotehost to svn://localhsot | 14:03 |
| jelmer | naoki: you can't use paramiko for svn+ssh | 14:04 |
| jelmer | naoki: you need to have a ssh executable | 14:04 |
| jelmer | naoki: svn and svn+ssh are different protocols | 14:04 |
| james_w | Ng: so, there's something a little odd going on here | 14:04 |
| james_w | Ng: I can't pinpoint any bugs. Is there a chance you had this happen before and dealt with it? | 14:04 |
| maxb | *blink* Why can't you use paramiko for svn+ssh? | 14:05 |
| Ng | james_w: it's not impossible, but I don't immediately remember anything obviously weird happening previously | 14:06 |
| james_w | Ng: ok | 14:06 |
| james_w | Ng: something a bit odd happened when you merged the last couple of versions, but I can't really work out what | 14:06 |
| jelmer | maxb: Because we call out to libsvn | 14:09 |
| jelmer | maxb: and that just invokes ssh.exe | 14:09 |
| maxb | oh, I see | 14:09 |
| Ng | james_w: thanks for looking. If it was you, would you manually fix up this merge and keep using these branches, or reconstruct the working one from a fresh copy of the pristine branch? | 14:10 |
| james_w | Ng: I'd fix up | 14:10 |
| james_w | Ng: have you modified any of the files that it is complaining about? | 14:11 |
| Ng | james_w: I don't think so. I can imagine I might previously have removed things like license.txt, but I shouldn't have any changes in the php/css stuff | 14:12 |
| james_w | you did remove license.txt :-) | 14:12 |
| james_w | in that case it's pretty much in the situation you want moving forwards | 14:12 |
| james_w | as merges from the pristine branch should be much more happy now | 14:12 |
| Ng | james_w: ok, thanks :) | 14:14 |
| naoki | afk | 14:15 |
| === salgado is now known as salgado-lunch | ||
| naoki_ | apr_proc_create uses CreateProcessW(bInheritHandles=TRUE) | 15:16 |
| naoki_ | libapr/threadproc/win32/proc.c | 15:16 |
| naoki_ | libsvn uses this function. | 15:17 |
| naoki_ | http://msdn.microsoft.com/en-us/library/ms682499%28VS.85%29.aspx | 15:24 |
| naoki_ | Inheriting handles is required for pipe. | 15:25 |
| naoki_ | So, libsvn and libapr is not wrong. | 15:25 |
| naoki_ | One option is killing connections before commit_write_group(). | 15:28 |
| naoki_ | Second option is pooling enough connections before start_write_group() | 15:30 |
| naoki_ | Any other solutions? | 15:30 |
| jelmer | naoki: we shouldn't kill connections before commit write group, there might be more actions the user would like to do | 15:47 |
| jelmer | Why would pooling connections before start write group help? | 15:47 |
| naoki_ | when start write group, bzr creates pack file. | 15:53 |
| naoki_ | A handle of the pack file is inherited to ssh client process. | 15:53 |
| naoki_ | When commit_write_group, bzr renames the pack file. | 15:54 |
| naoki_ | ssh client blocks renaming. | 15:54 |
| === salgado-lunch is now known as salgado | ||
| jam | naoki: if you set BZR_SSH=paramiko it will use pageant as well | 16:11 |
| jam | and avoid spawning a separate process | 16:11 |
| jam | ah, but jelmer is saying you need an actual ssh process... | 16:11 |
| jelmer | you can set BZR_SSH but that will just be ignored :-) | 16:11 |
| jam | naoki_: what about a pre-exec function that closes the extra file handles | 16:13 |
| jam | all you need is stdin/stdout, right? | 16:13 |
| naoki_ | libsvn creates ssh process. We cannot control it. | 16:14 |
| jam | well, we could have an ssh wrapper | 16:15 |
| jam | jelmer: does it need something explicitly called 'ssh' ? | 16:15 |
| jelmer | you can set a different executable in ~/.subversion/config | 16:16 |
| naoki_ | or SVN_SSH environment | 16:20 |
| naoki_ | But how the wrapper release handles? | 16:21 |
| jam | naoki_: so we could set SVN_SSH before we call out to svn+ssh | 16:21 |
| jam | naoki_: well, given that there is a program that can ask Windows what program has what files open, I'm sure you can enumerate your own file handles | 16:22 |
| jam | I don't know the functions | 16:22 |
| jam | this: http://social.msdn.microsoft.com/Forums/en/netfxbcl/thread/37dc9843-2583-41fc-8260-b78183aa4bed | 16:23 |
| jam | says there is NtQuerySystemInformation | 16:23 |
| jam | also: http://stackoverflow.com/questions/733384/how-to-enumerate-process-handles | 16:25 |
| jam | naoki_: possibly we could also open the file handle with "DELETE_OK" and possibly a rename-ok? | 16:26 |
| === beuno is now known as beuno-lunch | ||
| jam | it seems surprisingly ugly: http://www.techreplies.com/development-resources-58/enumerating-handles-processes-c-like-procxp-782021/ | 16:28 |
| naoki_ | How about try rename, catch PermissionDenied, and then copy instead of rename? | 16:53 |
| slicslak | any macosx users here? should I d/l bzr or use macports? i prefer macports but I don't want to use it if the port isn't maintined well (It appears to be a few versions behind atm) | 16:55 |
| naoki_ | In NewPack.finish() | 16:55 |
| naoki_ | http://paste.ubuntu.com/379852/ | 17:00 |
| mobby | Hi, sorry if this is the wrong place to ask this so feel free to point me in the direction (politely ;-) but I would like to know a bit more about co-located branches Bazaar. | 17:04 |
| mobby | I don't know anything about co-located branches so you will have to have some patience :) | 17:05 |
| mobby | Really my question is... How do colocated branches work? Or more specifically as a developer how would I use co-located branches day-to-day | 17:06 |
| rubbs | mobby: I'm not an expert, and I"m not too sure how they would work in Bzr, but colocated branches allow for multiple branches within the same directory | 17:07 |
| jam | naoki_: given that the file may be >>GB in size, I'm not particularly happy with that solution, but it would be possible | 17:07 |
| jam | when does it get deleted, though? | 17:07 |
| rubbs | git does this by having all of the repo information in one directory and you "switch" between the different branches. | 17:07 |
| rubbs | mobby: every time you switch you reload the working tree. | 17:08 |
| mobby | ah rubbs that the bit that I was really wondering about | 17:08 |
| rubbs | mobby: IIRC it would also let you have a project within a project. | 17:08 |
| jam | mobby: so the way *I* do it isn't exactly colocated. I set up a shared treeless repository (bzr init-repo --no-trees) and then a single working tree (bzr co --lightweight trunk work) | 17:08 |
| jam | and that point you can create new branches cheaply | 17:08 |
| jam | and switch between them | 17:08 |
| jam | the colo: plugin does something akin to this | 17:08 |
| jam | only puts the branches under a new namespace "colo:" and hides them under .bzr/branches IIRC | 17:08 |
| rubbs | jam: just curious is this also the answer to the "externals" question? | 17:09 |
| jam | the main reason I prefer not having them colocated | 17:09 |
| jam | is that I can have *multiple* working trees sharing the same set of branches | 17:09 |
| mobby | yeah I saw the colo plugin, which intrigued me but I couldn't find much information for what it was all about and hence me coming here | 17:09 |
| jam | which I use fairly often | 17:09 |
| jam | I have a 'work' which is my primary action item, and then an 'alt_work' | 17:09 |
| jam | So if I work on a bugfix, and submit it for review, I'm on to the next | 17:10 |
| jam | but the review needs some minor tweaks before landing | 17:10 |
| jam | so alt_work gets switched, fixed, submitted | 17:10 |
| jam | without disturbing the current work | 17:10 |
| jam | rubbs: do you mean bzr-externals ? | 17:11 |
| rubbs | jam: ah, I haven't looked into that recently. I'll go check it out. | 17:11 |
| mobby | so I suppose the co-located branch thing works best with branches of the same project rather than branches of differing projects?... I have a feeling I might have asked a stupid question there... | 17:14 |
| rubbs | mobby: not a dumb question because I was a little confused. it works best with branches of the same project. | 17:15 |
| mobby | ah ok cool. thanks. | 17:15 |
| rubbs | np | 17:15 |
| jam | mobby: 'it works best' because switching a tree to an unrelated one takes a lot of effort | 17:16 |
| jam | otherwise we don't specifically care | 17:16 |
| mobby | so rather than having folder upon folder of branches for each bit of work you are doing you can just have one folder which is the working tree and when you swicth branches the working tree files are updated to reflect that branch? | 17:16 |
| jam | mobby: right | 17:16 |
| rubbs | mobby: correct | 17:16 |
| rubbs | jam: you beat me to it ;) | 17:17 |
| jam | (with or without the colo: plugin, as mentioned) | 17:17 |
| mobby | ah great thanks! Yeah that does sound good. | 17:17 |
| rubbs | mobby: I believe it was created to reflect a more git-like workflow. | 17:17 |
| rubbs | and that is the way git works (more or less) | 17:17 |
| mobby | so I suppose if you had uncommitted changes in the working tree, if you switched you would lose those changes (if it doesn't warn you)? | 17:17 |
| jam | mobby: generally it preserves them | 17:18 |
| jam | with the idea that you may be switching to a new branch to put those changes | 17:18 |
| jam | (like a bugfix, etc) | 17:18 |
| rubbs | mobby: if it doesn't do what you want, you could potentially use shelve to get around the default behavior | 17:18 |
| mobby | yeah sorry my VCS knowledge is pretty much reserved to CVS and SVN as that is what I've been using in working life. I decided that I would look into others, found Bazaar and think it is really very good. Thus I;ve been trying to improve my knowledge of Bazaar and its capabilities | 17:19 |
| mobby | oh that;s cool it preserves them | 17:19 |
| mobby | thanks guys for your help. | 17:20 |
| rubbs | mobby: don't apologize for learning ;) I just thought I'd point that part out, didn't mean to make you feel ignorant. | 17:20 |
| rubbs | np | 17:20 |
| awilkins | SVN does switching between branches, but it's merging is painful | 17:22 |
| mobby | no you didn't make me feel ignorant at all, I've learnt a lot in just a few mins :) | 17:22 |
| mobby | yeah that's the other thing even my SVN knowledge is fairly limited as works process has not required further investigation into features | 17:23 |
| rubbs | good to hear! I think I can speak for both jam and myself when I say we like to help people learn about bzr. | 17:23 |
| mobby | I started trying to think of better ways of working, started learning about Bazaar, found out what VCS's can do (and realised how little I knew) and I've enjoyed using bazaar. I'm just trying to get as confident with it as possible so I can recommend its use in the compant i work for | 17:24 |
| aleksander_m | does 'bzr send -o patch.merge' include always by default the patch preview? | 17:25 |
| * awilkins now has to install Vista (sob) | 17:25 | |
| naoki_ | os.O_NOINHERIT avoids HANDLE inheritance | 17:26 |
| aleksander_m | the mini-tutorial says that it 'usually' contains the patch preview, but I cannot get it included | 17:26 |
| mobby | Thanks again for the help guys. Bye. | 17:28 |
| jam | naoki_: I thought you had to inherit handles to get pipes | 17:33 |
| james_w | hi jam | 17:37 |
| jam | hey james_w | 17:37 |
| james_w | I'd like to merge https://code.edge.launchpad.net/~jameinel/bzr-builddeb/changelog-parser/+merge/18557 but I don't understand one of the comments in the file | 17:37 |
| jam | k | 17:38 |
| james_w | there's a comment in there asking about it | 17:38 |
| jam | james_w: the strict=True stuff? | 17:39 |
| jam | so the BASE file is used as a reference | 17:39 |
| jam | but its content won't ever be put into the final changelog file | 17:39 |
| james_w | # BASE lines don't end up in the output, so we allow strict=False | 17:39 |
| jam | james_w: so we determine if THIS or OTHER should be used, based on whether they match BASE | 17:40 |
| jam | (if one matches BASE, then the other gets chosen) | 17:40 |
| jam | however, only THIS or BASE content is ever put into the file | 17:40 |
| james_w | right | 17:40 |
| jam | my idea was that | 17:40 |
| jam | if someone went through and cleaned up old content | 17:40 |
| jam | such that it now passes strict | 17:40 |
| jam | but didn't used to | 17:40 |
| jam | then we can still use the advanced merging | 17:40 |
| james_w | I think that makes sense | 17:41 |
| james_w | thanks, merging now | 17:41 |
| jam | james_w: I'm currently testing the md5sum caching logic | 17:42 |
| james_w | I just used the old code in a merge and got confused by it not conflicting on anything | 17:42 |
| jam | I have a patch, but want to make sure it works properly | 17:42 |
| james_w | great | 17:42 |
| james_w | which approach did you choose> | 17:42 |
| james_w | the "correct" way? | 17:42 |
| jam | download .dsc, compare md5sums for files that are on disk | 17:42 |
| jam | I think that was the correct way | 17:42 |
| jam | anyway to avoid downloading the .dsc ? | 17:42 |
| jam | though probably if it requires an extra round trip, we don't win | 17:43 |
| james_w | not really | 17:43 |
| james_w | they are small, so yeah, it's just round trip costs | 17:44 |
| james_w | we should only download a .dsc once though | 17:44 |
| jam | well, once per run at least | 17:44 |
| james_w | well, twice for syncs, but yeah, that can't be avoided | 17:44 |
| jam | ... why did it delete all of the old downloads? | 17:44 |
| jam | is that the cleanup when finished stuff? | 17:44 |
| james_w | yeah | 17:45 |
| jam | :,( | 17:45 |
| jam | :'( | 17:45 |
| james_w | I don't want the entire history of Debian and Ubuntu on jubany | 17:45 |
| jam | sure | 17:45 |
| jam | messes with my work, though :) | 17:45 |
| james_w | you could change it to download in to the updates dir if that's not what it is doing | 17:45 |
| jam | well, my testing | 17:45 |
| james_w | then when you use --no-push they will stick around | 17:45 |
| james_w | and it will then just download the .dsc each time | 17:46 |
| jam | it downloads into updates, but even with --no-push they went missing | 17:46 |
| james_w | anyway, changelog merge improvements merged, thanks | 17:46 |
| james_w | ah, maybe there's a finally block at a lower level too | 17:46 |
| james_w | that's probably worth removing once we have the cache | 17:46 |
| james_w | that's a win wherever it is used | 17:47 |
| jam | if commit_db.has_commit_started(): | 17:47 |
| jam | revid_db.cleanup_last_run(cleanup, push_back) | 17:47 |
| jam | commit_db.finish_commit() | 17:47 |
| jam | that cleanup includes an rmtree | 17:47 |
| james_w | oh, yeah, so not a win | 17:47 |
| james_w | we could make the cleanup smarter then | 17:47 |
| === beuno-lunch is now known as beuno | ||
| jam | james_w: so how does that all work. You have a global sqlite file, and if you start working on a package import, but don't finish it, the next run you nuke the wohle directory? | 17:51 |
| jam | what is the rationale? | 17:51 |
| jam | just that you can't trust the intermediate steps? | 17:51 |
| james_w | yeah | 17:51 |
| james_w | I wasn't confident that the work wouldn't be in some inconsistent state | 17:52 |
| james_w | if bzr is atomic, and bzr-builddeb makes use of that in the correct way then we could just carry on | 17:52 |
| james_w | but I wasn't confident in that | 17:52 |
| jam | genearlly bzr is atomic | 17:53 |
| jam | generally | 17:53 |
| jam | however, I also see this: | 17:53 |
| jam | if push :commit_db.start_commit() | 17:53 |
| jam | with *no* matching finish_commit() | 17:53 |
| jam | argh | 17:53 |
| jam | I missed the else: | 17:53 |
| jam | http://paste.ubuntu.com/379881/ | 17:54 |
| jam | so it seems that when starting, we nuke the old content | 17:54 |
| jam | unconditionally | 17:54 |
| jam | either we first rollback, and then nuke it | 17:54 |
| jam | or we just nuke it | 17:54 |
| james_w | cleanup_last_run is misnamed | 17:55 |
| james_w | it's finish then cleanup | 17:55 |
| james_w | I think | 17:55 |
| jam | well, it checks if there are rows in the db | 17:55 |
| jam | and if there are or aren't it calls cleanup_cb() | 17:55 |
| jam | so all code paths lead to cleanup | 17:55 |
| === asac_ is now known as asac | ||
| jam | which rmtree(updates/<PACKAGE>) | 17:55 |
| james_w | ah, yeah, we always cleanup | 17:56 |
| james_w | you're right | 17:56 |
| james_w | which would interfere with any caching of the packages | 17:56 |
| naoki_ | I've made patch and report bugs | 17:56 |
| naoki_ | https://bugs.launchpad.net/bzr/+bug/524560 | 17:56 |
| ubottu | Ubuntu bug 524560 in bzr "bzr branch from svn+ssh fails on win32" [Undecided,New] | 17:56 |
| jam | well, at least it shouldn't re-download files in a single run | 17:56 |
| jam | which is better for me | 17:56 |
| jam | but it would be nice to not re-download them between runs, since I'm using --no-push so lp doesn't get updated | 17:56 |
| james_w | yeah | 17:56 |
| jam | anyway, test is currently running to at least look for double-downloads of a single import | 17:56 |
| james_w | ok, all your fixes are on production now | 17:59 |
| jam | \o/ | 17:59 |
| james_w | including the encoding one | 17:59 |
| james_w | and it's up and running again | 17:59 |
| james_w | it's got 2000 nops to churn through though unfortunately | 17:59 |
| jam | james_w: which.. requires getPublishedSources for all of them? | 18:00 |
| james_w | yeah | 18:00 |
| === deryck is now known as deryck[lunch] | ||
| jam | james_w: https://code.edge.launchpad.net/~jameinel/udd/single-download-524123/+merge/19731 | 18:02 |
| james_w | jam: merged, thanks | 18:09 |
| pynonoir | Hi. If I replace a normal directory with bazaar branches, by a shared repository with the same branches inside (same path for bzr+ssh), will my users have some problems when pulling/pushing ? | 18:13 |
| jam | james_w: thanks | 18:13 |
| jam | pynonoir: you should be fine | 18:14 |
| Kinnison | as long as the urls to the branches don't change, you should be fine | 18:14 |
| jam | only possible problems would be perms | 18:14 |
| Kinnison | oh true; permissions if this is multiple unix users | 18:14 |
| pynonoir | there are indeed multiple users | 18:14 |
| * Kinnison typically doesn't expect repositories to be shared between users | 18:15 | |
| Kinnison | unless you *really* need the space savings, I'd say it wasn't worth the risk | 18:15 |
| pynonoir | Kinnison: that was more to save bandwidth | 18:16 |
| Kinnison | hmm | 18:16 |
| Kinnison | in what sense? | 18:17 |
| Kinnison | give me a use-case in which you expect bandwidth to be saved | 18:17 |
| Kinnison | (I'm not very well today; so forgive me if I'm a touch slow :-) | 18:17 |
| pynonoir | mmm, if there is a branch called A on the distant server. Then one of my users make a clone (bzr branch), do some modifications and then push it as a new branch on the distant server | 18:19 |
| pynonoir | maybe only the delta can be sent if it pushed on a shared repo ? | 18:19 |
| Peng | If each user has a separate shared repo, you should still get most of the bandwidth savings.. | 18:22 |
| pynonoir | Peng: good idea, I will do this | 18:22 |
| pynonoir | thanks | 18:22 |
| Kinnison | and that will negate any user permissions issues too :-) | 18:23 |
| === deryck[lunch] is now known as deryck | ||
| === radoe_ is now known as radoe | ||
| === salgado is now known as salgado-afk | ||
| Lo-lan-do | Hi all. What to do if bzr check tells me about sha1 mismatches? | 19:57 |
| fullermd | Flip a bit at a time until they match? 8-} | 19:58 |
| Lo-lan-do | Haha. | 19:59 |
| Lo-lan-do | And seriously? Should I worry, or is it a harmless warning that should be marked as such? | 20:00 |
| james_w | I doubt it is harmless | 20:01 |
| james_w | unfortunately I don't know how to dig deeper | 20:03 |
| Lo-lan-do | Will bzr reconcile fix them? | 20:03 |
| james_w | I'm not sure about that either | 20:03 |
| james_w | you could file a bug/question | 20:03 |
| rubbs | it wouldn't hurt, but doubt it would fix it. | 20:03 |
| lifeless | Lo-lan-do: please file a question | 20:03 |
| lifeless | if the data is private, file a private bug | 20:04 |
| Lo-lan-do | lifeless: ? | 20:05 |
| lifeless | if the error message contains data that you feel is confidential, you can't get privacy on answers.lp | 20:05 |
| lifeless | but you can in bugs | 20:05 |
| Lo-lan-do | Oh, I see. Launchpad. | 20:06 |
| Lo-lan-do | No questions unless I register? | 20:08 |
| lifeless | yes | 20:09 |
| lifeless | if you don't want to register, you can mail the list | 20:09 |
| Lo-lan-do | I'll do that, thanks. | 20:11 |
| mkanat | mwhudson: Have there been any more hangs? | 20:44 |
| mwhudson | mkanat: don't think so | 21:16 |
| james_w | Lo-lan-do: what are the messages exactly? | 21:36 |
| james_w | perhaps others have seen them before or know what they will refer to, but I don't | 21:37 |
| Lo-lan-do | sha1 mismatch: ('6500@9d84d37e-dcb1-4aad-b103-6f3d92f53bf6:trunk%2Fgforge%2Fwww%2Fplugins%2Ffckeditor', 'svn-v4:9d84d37e-dcb1-4aad-b103-6f3d92f53bf6:trunk:6500') has sha1 9287ea6b641b2676b769ce316258446d8f20f4fd expected da39a3ee5e6b4b0d3255bfef95601890afd80709 referenced by lolando@debian.org-20090923124104-8gq9ozsdlowgtyue | 21:59 |
| _TiN_ | Hi, what is the solution to serve bazaar, with apache? I'm trying to add support for bzr-vcs in http://trac.usla.org.ar | 22:05 |
| james_w | Lo-lan-do: aha, bzr-svn, that changes things a little. I'm still no closer to knowing if it's a problem or what to do about it though. | 22:07 |
| mneptok | _TiN_: http://doc.bazaar.canonical.com/bzr-0.15/http_smart_server.htm | 22:08 |
| mneptok | _TiN_: note the strongly worded "this is NOT secure!" bit | 22:08 |
| Lo-lan-do | james_w: I'm re-running check, will paste output into a mail if it helps. | 22:08 |
| lifeless | mneptok: that warning is gone now | 22:09 |
| james_w | Lo-lan-do: good idea, it might clue some people in | 22:09 |
| lifeless | mneptok: please ref current docs | 22:09 |
| jam | james_w: the packaging script was stopped for a while, right? | 22:10 |
| jam | I just ran hottest-100 and got about 5 branches moved from 'ok' to 'packaging-out-of-date' | 22:10 |
| james_w | jam: yeah | 22:11 |
| james_w | just catching up now | 22:11 |
| jam | well, as of 2 hrs ago | 22:11 |
| jam | k | 22:11 |
| mneptok | lifeless: couldn't find CURRENT for FastCGI setup. but PEBKAC is more than likely to blame. | 22:12 |
| _TiN_ | mneptok: I'm trying with fcgi and mod_python and doesn't work, I suspect bazaar is not generating correctly the app | 22:12 |
| lifeless | mneptok: http://doc.bazaar.canonical.com/latest/en/user-guide/http_smart_server.html | 22:13 |
| lifeless | 'fast cgi bzr' into google | 22:13 |
| mneptok | _TiN_: is mod_python actually loaded as a module in your Apache configs? | 22:13 |
| _TiN_ | mneptok: iep, In this tracs i have svn hg git | 22:14 |
| mneptok | _TiN_: FYI, i have never set up bzr+apache, so i'm not the best resource. please click that URL lifeless pasted. | 22:14 |
| mneptok | _TiN_: if you read that document, it's "the blind being led by the sighted." if you ask my advice, it's "the blind being led by the blind idiot." :) | 22:15 |
| jam | lifeless: it looks like we need to strip some zeros out of our sha1 strings (bug #524553) | 22:22 |
| ubottu | Launchpad bug 524553 in bzr-windows-installers "Bazaar is getting wrong sha1" [High,Invalid] https://launchpad.net/bugs/524553 | 22:22 |
| jam | :) | 22:22 |
| lifeless | jam: oh did you get an answer to it? my mail is closed... | 22:23 |
| jam | lifeless: he was getting "abcd0fgh..." and we were saying "abcd000fgh", of course his sha1 strings were only 35 chars long | 22:23 |
| lifeless | ! where was he getting the truncated one from ? | 22:24 |
| ubottu | Error: I am only a bot, please don't think I'm intelligent :) | 22:24 |
| jam | I'm pretty sure it amounts to using '%x' versus '%08x' sort of thing | 22:24 |
| jam | lifeless: I have no clue, custom code I would assume | 22:24 |
| lifeless | heh | 22:24 |
| fullermd | It was compressed. Space savings are important. | 22:26 |
| jam | fullermd: of course, the next step is to get a collision under these circumstances | 22:28 |
| fullermd | Pshaw. Everybody knows hashes don't collide. I checked every file in my home dir, and none of the hashes were even close. | 22:30 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!