[00:00] to the logs: ignore the lie above :P [00:00] I hope Eclipse fixes whatever bug bzr 2.1.0b4 causes bzr-eclipse to expose in Helios. [00:00] Assuming that the guy who responded to my question about it by saying it's an eclipse bug is right. [00:00] I need to capture some logs and figure out how to report it. And where. [01:02] if I didn't know what I was doing and "mv /foo1/branch /foo2/branch" and now it says, 'bzr: ERROR: No repository present: "file:///foo2/branch"', how do I fix that? [01:03] How much else have you done since? [01:03] That's it. === mwhudson_ is now known as mwhudson [01:04] I just needed to get the branch off that nfs mount. [01:05] Would "mv /foo2/branch /foo1/branch & bzr mv /foo1/branch /foo2/branch" work then? [01:05] Oh wait. [01:05] Don't you need a repo on top of it? [01:05] Oh! Right! I forgot I made /foo1 a repo! [01:05] Thanks. [01:06] I mostly mess around with shared repositories so far so sometimes the other way of doing it muddles me [01:06] Given the use case you're talking about, would bzr branch /foo1/branch /foo2/branch be preferable, though? [01:07] I'm a noob, so if it wouldn't, I just don't understand why yet. [01:16] * igc food [01:50] EdWyse_Office: move it back, then do 'bzr branch /foo1/branch /foo2/branch === abentley1 is now known as abentley === mordred_ is now known as mtaylor === abentley1 is now known as abentley === mwhudson_ is now known as mwhudson [03:42] Glenjamin: hey === sdboyer_ is now known as sdboyer [04:09] is it possible to change committer names/emails on old commits? [04:10] chromakode: No. [04:10] Well. [04:11] I'm aware of some voodoo to do it in git [04:11] was wondering if there's an equivalent in bzr-land [04:11] chromakode: bzr-fastimport can do it -- quite easily, too -- but you'd wind up with new revision IDs, so unless you put the nuclear launch codes in your email address, it's usually not worth it. [04:11] right, yep [04:11] I understand that issue [04:11] not worth it :) [04:12] is doing this technically impossible with bzr (does it mess up hashes?) [04:13] Like I said, you can do it with bzr-fastimport. [04:13] I dunno if it changes the hashes. [04:14] understood. please excuse my ignorance of bzr internals, but is the committer info hashed? [04:14] okay [04:14] Still, bzr is not designed to go changin' stuff. :P [04:14] thanks, just a matter of curiosity! [04:14] :) [04:14] altering history never works out [04:14] I learned that watching 90s cartoons [04:14] You can find a few "@mylaptop" commits in the history of Bazaar itself. :D [04:15] haha [04:15] it's hard for me to let go of the ideal commit log [04:17] bzr also has a commit with revid 'A' in it's history :-) [04:17] -' grrr [04:17] huh! what happened there? [04:19] The hypothesis I've heard is that a unit test accidentally committed to the real history, and the developer apparently didn't catch it in time. [04:20] ha! [04:21] The commit message is "silly commit" and it adds a file called "b". :D [04:22] that's a wonderful piece of trivia [04:23] it is a unit test [04:23] its still in the tree [04:23] but it somehow went awry? [04:24] early unit tests weren't as isolated [04:25] haha. [04:25] someone clearly ran a unit test on their dev tree [04:25] how else would you test? [04:25] ;) [04:27] That revision also suffers from the "@mylaptop" committer ID problem. :D [04:28] hmm [04:28] maybe that could be avoided if there was an "Are you sure?" prompt if you try to commit with an unset email/username [04:29] chromakode: no, because the test suite runs with a null UI [04:29] chromakode: the /commit/ is what the test suite wanted [04:29] I realize that won't help for the test suite [04:29] but it might help me from being stupid when I'm branching on a laptop [04:29] if you're interested, its revno: 0.2.1 [04:30] the tree is still downloading :/ [04:30] You can also do "bzr log -r revid:A". [04:30] is there any reason bzr requires the -r argument? [04:30] Peng: the machine name is valid btw, not really a problem :P [04:30] chromakode: because bzr log FOO logs the branch FOO [04:31] Or the file FOO. [04:31] is it ambiguous if there's a colon in there and no file? [04:31] http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/revision/0.2.1 :D [04:31] its easier to tell people 'to control the revision use -r' [04:31] sorry if this is annoying, I've just always been curious about these things [04:32] than to say 'if you pass a revision that is not a branch or a file it will work, and when you want a branch or file *and* a revision use -r' [04:32] ah, good point [04:32] it's just kind of odd to me when I only want a rev, not a file [04:33] It's more consistent with other commands, too. [04:34] yeah, it's definitely more consistent [04:34] For example, "bzr branch -r 123 some_location" [04:35] chromakode: It's not annoying. :) Besides, I've asked lifeless far more weird questions than you have. :P [04:35] yes, I should just develop the semantic association that -r is always revision [04:35] okay, I have one more question, regarding workflow [04:36] do you create lots of new branches when you need to work in multiple directions at one? do you branch when you're fixing a bug? how do you manage the directory structure of your branches? [04:36] or do bzr users tend to shelve and unshelve more? [04:37] I just create lots of branches. [04:37] I realize they're separate commands with different purposes, but I wonder what the dominant context-switch approach is [04:38] Some people create multiple branches but just use one working tree, "bzr switch"ing to the branch they want. [04:38] Peng: how do you structure your directories? a bunch of branches inside a repo? [04:38] I think there are some plugins for making this easier. [04:38] chromakode: Yeah. [04:38] ah, is bzr switch relatively new? [04:38] No. [04:38] okay. I thought I'd read about it somewhere [04:39] chromakode: I know one of Bazaar's developers creates a subdirectory for each version. I don't, but I don't create a lot of branches either. :P [04:41] cool. thanks for answering my questions :) [04:42] :) [06:50] does bash use bash programmable completion? [06:50] bzr [06:50] * [06:53] does for me, i'm guessing most packages of it would [06:53] at leats, if i understand correctly ;) [06:54] yeah, but i mean does it do it through bash? I don't see nothing about bzr in /etc/bash_completion [06:54] i have /etc/bash_completion.d/bzr{,.simple} [06:56] oh [06:56] nice [06:56] i didn't know about that dir, but its awesome that exists [06:57] yeah! [07:00] :) [07:21] hi all [08:13] When I decided to add our pdfs and graphics for our web site to the local branch, then push to the remote repo (a little over a gig) using the windows gui, it gets to "fetching revisions:inserting stream", the status bar at 50%, and stops. 20 minutes and counting so far. Is that expected behavior? === gerard_1 is now known as gerard_ [08:23] * igc dinner [08:27] hey all [08:34] jfroy: still around? i've installed keychain but i just get the command line prompt when i try and access a protected branch [09:06] Glenjamin: did you add the relevant key to ssh-agent? (either with ssh-add or keychain) [09:06] it's a username/password auth which i'm trying to get handled by bzr-keychain on mac os x [09:07] ah, sorry. just made a guess :) === mgolisch_ is now known as mgolisch [11:01] can sbdy tell me how to run bzr serve via ssh? i tried bzr serve --allow-writes --inet --protocol=ssh, but no avail. there'sno help about the protocols :( === LenZGr_ is now known as LenZGr === LenZGr is now known as LenZ === LenZ is now known as LenZG === LenZG is now known as LenZGr_ [11:22] * GaryvdM waves at bialix [11:22] heya Gary! [11:22] * bialix waves back :-D === LenZGr_ is now known as LenZ [11:52] GaryvdM: what you think about pyqt 4.7? [11:55] bialix: I have not installed it, so I don't really know. It's good though that they have installers for more versions of python. [11:55] yes [11:56] I fear that will continue to ignore 2.5, but apparently it's not [11:57] I think for the windows installers, we should upgrade only early in the next cycle. [11:58] not now, which is what i think jam is going to do. [11:59] I'm installing bzr onto a clients mac atm. [12:02] And it is working :-) [12:02] cool! [12:07] bialix: It's not that hard. Did you know that we have an installer that includes pyqt (but not qt.) I did not. [12:07] for Mac? [12:07] Yip [12:08] there is some advice on bazaar.canonical.com/QBzr [12:08] http://wiki.bazaar.canonical.com/MacOSXDownloads [12:08] * bialix has no mac to play with, alas [12:09] that's really cool [12:09] GaryvdM: should we update our page then? http://wiki.bazaar.canonical.com/QBzr ? [12:09] it said: NOTE: OSX users will also need to install PyQt. Instructions are available from Installation of PyQt on Mac OS X. [12:11] Yes, we can just point them to http://wiki.bazaar.canonical.com/MacOSXDownloads [12:12] I trust your experience :-) [12:43] I'm trying to use the bzr packaging scripts to update the qbzr ppa for the first time. [12:43] I'm getting an error with update-changelogs.sh [12:43] see http://paste.ubuntu.com/360630/ [12:43] * bialix waiting for jam and 2.1.0rc1 bzr.exe installer [12:46] GaryvdM: maybe it searching case-insensitive? [12:46] err, sensitive I mean [12:48] strange [12:48] really [12:51] dch can't find changelog when run from the script, but if I run dch manually, it works? [13:01] Hmm - I removed the "-c changelog" from line 30 of update-changelogs.sh. Not sure how it works normally [13:06] I don't think so, maybe the bzr packaging branches have a different layout. [13:07] ah, that is the case. [14:39] bialix: I'm waiting for information about how to get tbzr 0.5.0 built [14:39] naoki added i18n, but I don't have the .mo files he wanted bundled [14:39] hi jam [14:39] ok [14:39] Hi jam [14:39] I haven't gotten a response from him, so I don't really know [14:40] hi GaryvdM [14:40] morning all [14:40] morning jam [14:42] jam: For qbzr, we have to do >python setup.py build_mo -f [14:42] maybe it is the sameqQ [14:42] ? [14:44] GaryvdM: could be. I do see a build_mo in setup.py [14:44] He didn't add any such step to the release process when he updated the installers [14:44] but I bet he wasn't sure how the process went, and probably had already done certain steps manually [14:46] * bialix looks [14:49] bialix: I'm thinking we should do our releases as follows: 0.19b1 0.19b2 ... 0.19bn 0.19rc1* 0.19rc2 0.19.0 0.19.1 [14:49] Like bzr core. [14:49] to be in sync with bzr? [14:50] this is for 2.2? [14:50] Yes [14:50] interesting idea [14:50] why not [14:50] jam should be happy [14:51] The betas don't have to be in sync, but the rest should. [14:52] GaryvdM: you can certainly do that, but are you sure you're going to release in sync? Especially for stable releases... [14:52] jam: tbzr uses the same code as qbzr for i18n [14:53] jam: python setup.py build_mo actually builds mo [14:53] they are in locale [14:53] can I help you with installer? [14:53] jam: True, we would probably have less stable releases than bzr. [14:55] rats, naoki pushed loom branch to lp [14:56] bzr produce not very nice error for this [14:56] !pastebin [14:56] For posting multi-line texts into the channel, please use http://ubuntu.pastebin.com | To post !screenshots use http://tinyurl.com/imagebin | !pastebinit to paste directly from command line | Make sure you give us the URL for your paste - see also the channel topic [14:57] http://ubuntu.pastebin.com/m5c1d1aca [14:57] bialix: If you want. For now I have to update the build process to add "build_mo" into the tbzr build steps [14:57] and currently that is blocked on getting "msgfmt" installed [14:57] which is blocked on cygwin upgrading from 1.5 to 1.7... [14:57] jam: how you're handle qbzr then? [14:58] it uses the same stuff [14:58] bialix: you version qbzr [14:58] qbzr's .mo [14:58] and explorer too [14:58] no [14:58] I believe [14:58] we don't version mo [14:58] *shrug* the build works [14:58] running build_mo manually says 'no msgfmt' fonud [14:58] fonud [14:58] found [14:58] they are present in tar.gz [14:58] and I don't see it on my system [14:58] no, sorry [14:59] mo is purely build time files [14:59] can you install them for windows not cygwin? [15:00] running build_mo manually -- maybe something wrong with your path? [15:03] bialix: it is possible, running 'c:\Python25\python setup.py build_mo' doesn't work in tbzr or qbzr [15:03] are you sure the .mo files are in the installers? [15:03] I can test you 2.0.4 if you want [15:04] but naoki patch for installers is wrong re iss.cog [15:04] he's added line: ; cog.outl('Source: "%s\\locale\\*.mo"; DestDir: "{app}\\doc\\tbzr"; Flags: createallsubdirs ignoreversion recursesubdirs; Components: tortoise' % os.environ['TBZR']) [15:04] I see the .mo files for one of the older builds [15:04] should be: [15:04] (2.0.3 here) [15:04] oops [15:05] jam: for c:\Python25\python setup.py build_mo' you need not cygwin msgfmt. you can install gettext from gnuwin32.sf.net [15:06] bialix: I *can* but I don't want to do my own dependency tracking if I can avoid it [15:07] setting up a build host is already a huge pain [15:08] I have some free time today [15:08] I can help [15:10] I needed to install gettext-devel [15:10] and msgfmt is found [15:10] oddly, I don't know how the .mo files would be in 2.0.3... [15:10] running python setup.py build will happily skip creating .mo files [15:10] it issues a warning to the terminal, but doesn't stop the build process [15:10] might want to look closer at that === CardinalXiminez_ is now known as CardinalFang [15:15] jam: it seems absent msgfmt was the main reason [15:16] because you only need setup.py build to build both mo and other tbzr stuff [15:16] there is used such trick as: build.sub_commands.insert(0, ('build_mo', None)) [15:17] bialix: missing msgfmt, but I didn't notice because when build_mo failed it didn't stop the build [15:18] it may be my fault [15:18] I did not return anything from build mo [15:18] however, what is your thoughts on the changes to the iss script? [15:18] they seems a bit wrong [15:19] based on the code in tbzrlib/i18n.py it should be locale dir right along bzr.exe [15:22] jam: I think that line should be ; cog.outl('Source: "%s\\locale\\*.mo"; DestDir: "{app}\\locale"; Flags: createallsubdirs ignoreversion recursesubdirs; Components: tortoise' % os.environ['TBZR']) [15:22] ; cog.outl('Source: "%s\\locale\\*.mo"; DestDir: "{app}\\locale"; Flags: createallsubdirs ignoreversion recursesubdirs; Components: tortoise' % os.environ['TBZR']) [15:24] jam: do you see where to add that line? [15:24] I understand where that would go [15:24] I'd just like confirmation that it does the right thing [15:25] bialix: so I can confirm that 2.0.4-1 does *not* have the .mo files [15:26] jam: based on the code in tbzr: [15:26] def _get_locale_dir(): [15:26] if hasattr(sys, 'frozen'): [15:26] base = os.path.dirname(unicode(sys.executable, sys.getfilesystemencoding())) [15:26] return os.path.join(base, u'locale') [15:27] sys.executable is the bzr.exe path? I guess [15:27] or other tbzr exe binary [15:28] jam: do you remember how to get exit code of other program in windows shell? [15:29] found [15:30] %ERRORCODE% or %ERRORLEVEL% ? [15:30] jam: about build_mo exit code: that's seems intended behavior: http://ubuntu.pastebin.com/d137823cd [15:30] I can change this if you think it's desirable [15:31] do you think? [15:31] bialix: so doing that means that when I don't have msgfmt installed it fails to build but doesn't stop the build process [15:31] or I can produce error if --force flag is used... [15:32] I would think that you would want to fail if you can't build the i18n files [15:32] at least for building the official installers [15:32] yes, for official installer it makes many sense [15:32] I can change this for qbzr [15:32] I'm not a big fan of building the installer and having users tell me it is broken [15:32] though it seems to happen often enough [15:33] why for users then? ;-) [15:33] well, I wouldn't care except they expect me to do something about it [15:34] :-) [15:34] and spending an hour building yet-another installer isn't my ideal time sink [15:34] except - expect. nice [15:35] like a palindromne [15:40] jam: my guess about iss.cog was correct [15:40] yeah, looks like [15:41] based on naoki answer [15:44] ok, the build at least succeeds this time [15:44] great [15:44] now to sort out the installed location issues [15:44] at least we found problem with build_mo [15:44] I will update the builders for qbzr, explorer and MP for tbzr [15:52] Greetings. I have a query about 'bzr revert' not acting as I expected. [15:53] I thought in general terms it aligned the files in a WT to correspond to the state of the tip revision. [15:53] but that's not happening. [15:54] Tried with 2.1.0b4 on WinXP and 2.1.0b1 on linux with same result [16:05] smartgpx: it does [16:07] bialix: not for me. but maybe I am misunderstanding. can I email you a noddy script to look at? [16:07] you can pastebin it [16:07] or email [16:07] smartgpx: it brings it to the state of the branches tip [16:08] smartgpx: not the bound branch [16:09] *not the bound branch's tip [16:09] does 'inventory' report on the branches tip? [this is simple personal stuff, no bound branches involved.] [16:11] I wish to get a branch from several commits ago. How should i do that? [16:12] smartgpx: no - bzr inventory --help -> Purpose: Show inventory of the *current working copy* or a revision. [16:12] for branch tip: bzr inventory -r -1 [16:13] BusMaster: bzr branch -r -4 ../new-branch [16:13] err [16:13] BusMaster: bzr branch -r -4 old-branch new-branch [16:14] vila, old-branch can be something like lp:~sagar/+junk/sarathi ? [16:15] vila, or is that the repository ? [16:15] BusMaster: sure, can be any valid branch URL [16:15] heya vila! [16:15] vila, ok thanks [16:15] hey bialix ! [16:23] regarding revert - see http://pastebin.com/d5b917d0c [16:23] I expected to get back to a working directory with only the one committed file in it. [16:26] * GaryvdM looks [16:27] smartgpx: there is no changes so revert is a no-op [16:28] smartgpx: bzr does not touch unversioned files [16:28] yeah, no changes on versioned files [16:29] If you did bzr add, and then bzr revert, "two" would be deleted. [16:29] You may find clean-tree helpfull here [16:32] add and revert not sucessful - http://pastebin.com/d79a6bb18 [16:33] sorry - I guess I was wrong about that then. [16:36] bzr help revert says "Any files that have been newly added since that revision will be deleted" so it doesn't seem to be working right? [16:38] This makes providing a 'clean' reply to ANSWER:98183 a bit complicated? [16:40] No, actually it doesn't if you are prepared to Branch from an old revision rather than 'winding back' the tree you currently have. === beuno is now known as beuno-lunch [16:53] vila: are you still around? [16:53] I was wondering if you've seen http://code.google.com/p/python-ntlm/ [16:54] for handling NTLM auth proxies for bzr [16:57] jam: hmm, interesting [16:57] in the short term, there also seems to be: http://sourceforge.net/projects/ntlmaps/ [16:57] jam: if it's done as AuthHandler as it seems, it may be easy to integrate [16:57] which seems to run a local app [16:57] that you proxy through, which then proxies via NTLM for you [16:58] hard for *me* to test, as I don't have an NTLM proxy :) [16:58] jam: but keep in mind that most NTLM proxies also accept Basic so we have yet to find people really blocked by the lack of NTLM support [16:58] and I'm guessing neither do you [16:58] jam: you guess right :-/ [16:58] well, bug 363019 is blocking someone... [16:58] Launchpad bug 363019 in bzr "bzr fails to do proxy authentication" [Low,Confirmed] https://launchpad.net/bugs/363019 [16:59] as is bug 244879 [16:59] Launchpad bug 244879 in bzr "http urllib implementation doesn't support NTLM auth scheme" [Medium,Confirmed] https://launchpad.net/bugs/244879 [16:59] at least gareth white claims so [16:59] he says he used a different intermediate proxy for it [16:59] jam: I *am* looking at it, but it seems the problem in 363019 is that we can't even ping code.lp.net [17:00] Gareth found a workaround so he isn't blocked :D [17:01] vila: so for 363019 the don't even know if there is a route to c.lp.net? [17:01] couldn't they use a browseR? [17:02] jam: I asked if he can ping [17:02] vila: looking at the last traceback:ConnectionError: Connection error: Couldn't resolve host 'code.launchpad.net' (11001, 'getaddrinfo failed') [17:02] doesn't look like it has anything to do with proxies [17:02] unless they are proxying DNS requests... [17:02] I seem to remember David Cornoupeau talking about a config where the DNS was proxied, but I didn't make sense (to me) at the time [17:03] I've heard of using DNS as a secret proxy [17:03] you make request for certain 'well-formed' IP addresses, and it proxies the actual http responses, etc. [17:04] http://thomer.com/howtos/nstx.html [17:05] wow. even has "IP-over-ICMP" [17:05] so you use ping packets to get your data... [17:08] jam: I don't want to hear more about that :D [17:10] jam: hmm, looking at http://code.google.com/p/python-ntlm/, it's doing far too much to be re-used directly (at least the handler part), [17:11] http://code.google.com/p/python-ntlm/source/browse/trunk/python26/ntlm/ntlm.py seems to be the needed part, but it makes my eyes bleed :-/ [17:14] vila: it doesn't seem that bad, just foolish [17:14] rather than using code comments [17:14] they use variables [17:14] like calling struct.pack 20 times [17:14] and assert [17:14] rather than 1 pack with 20 args [17:15] jam: I didn't say bad :) [17:15] Or I would have said: it makes my *heart* bleed :) [17:15] I think it is ~ reasonable when you are debugging, but for an actual implementation, it seems it could be made a lot better [17:15] +1 [17:19] jam: and no tests :-{ [17:19] in this case, running against a real server is probably the best test [17:19] s/best/first/ [17:20] :D [17:20] jam: anyway, thanks for the pointer, that can at least be a starting poijnt [17:21] vila: no, *best* test (most authoritative) [17:22] jam: no, *first* test, *one* server, we're talking MSoft here, do you really think a single server will be enough ? [17:23] vila: it is enough if you're the guy stuck behind that particular proxy :) [17:23] yeah, but I'm the guy maintaining the code ;D [17:27] jam: can I download new installer, or you're not finished it? [17:28] bialix: I'm rebuilding 2.0 right now, and I'll be doing 2.1 next [17:28] ah, ok [17:28] so, I'll check tomorrow [17:29] * bialix waves bye [17:37] hey. Im trying to make a new branch, done init and add, but when I push it says I don't have permissions for some reasons :S [17:37] what might be the problem? [17:46] \o/ my passport just arrived [17:47] YES [17:47] pfew [17:48] igc: what are you doing awake... :) === beuno-lunch is now known as beuno [18:10] jam: we use KnownGraph to caluclate revnos for pack-0.92 too right ? [18:23] vila: yeah, I don't think reading from the index is fast-pathed [18:23] but we should still use KG [18:24] jam: so loading the graph for say, mysql, took how long ? I have 1sec in mind but it may be for bzr itself [18:25] vila: mysql is now in 1.9 format [18:25] so gets btree indices [18:25] which have the faster path [18:25] jam: the log code says: "generating the merge graph can take 30-60 seconds" that's not true anymore I think [18:26] jam: even better then [18:26] vila: so for their 6.0 branch, doing: [18:26] time py -c "from bzrlib import branch; b = branch.Branch.open('.'); b.get_revision_id_to_revno_map()" [18:26] takes 2.2s [18:27] with 68.8k revisions [18:27] for emacs with 106,080 k revisions, I see it taking 4.2s [18:28] well 106,080 or 106k :) [18:29] good, thanks, I'm not there yet but I'm pretty sure I understand what happen for that bug: 1) we fail to find the rev in the ancestry and display garbage instead, but 2) we just shouldn't *force* that a rev be in the direct ancestry when dealing with arbitrary revids or should we.... [18:32] vila: which bug? [18:32] the log not-in-ancestry stuff? [18:32] yup [18:34] can I use bzr to manage code that's in a CVS repository? i.e. bzr co cvs:something [18:34] newz2000: unfortunately no [18:35] it is too hard to get stable revisions out of cvs, so you have to go through a converter [18:35] ok, thanks jam [18:35] newz2000: I believe there is a 'bzr cvsserve' which lets people checkout a bzr branch as though it were cvs, though :) [18:36] I'll suffer through some how. :-) [18:44] vila: this seems like a slow week for 3rd-party submissions, did it seem like that for you? [18:45] jam: yes, on the other hand, we have an rc coming out so people should know there is little chance to land something, we'll see next week [18:47]