[00:00] bialix: I'll build and upload the latest chm files today - you'll like them [00:01] jam: while you still here: igc has new special branch for building windows installer [00:01] igc: maybe it worth to put them into bzr branch [00:02] it seems I'm in black list of jam [00:03] bialix: we recently agreed on the list that windows packaging didn't belong in the bzr core [00:03] jam: What version of qbzr did you use? I hope 0.14.1 [00:03] igc: I don't understand about translations [00:03] bialix: http://bugs.edge.launchpad.net/qbzr/0.14/0.14.1/+download/qbzr-setup-0.14.1.exe [00:03] bialix: I need to finish and package explorer 0.8 [00:03] garyvdm: please, merge 0.14 branch into trunk [00:03] and put it in new installer [00:04] bialix: I did I forgot to push :-( [00:04] bialix: then we can call for translations [00:04] bialix: then package those translations in 0.8.1 and ship that with 2.0.0 [00:04] igc: if by package you mean cut out tarball then I can do it for you after I'll update translations. or you prefer to release 0.8.1 later? [00:04] bialix: though 0.8 might be called explorer 1.0beta1 [00:04] bialix: Done. [00:05] and 0.8.1 might be called explorer 1.0 [00:05] igc: ok, I understand your plan now [00:05] release 0.8, test installer, release 0.8.1 right before 2.0 final [00:05] igc: ^ right? [00:05] bialix: my primary focus is getting explorer and chms into installer [00:06] ok ok [00:06] garyvdm: jam uses qbzr trunk [00:06] bialix: explorer gets a few 100 downloads each release [00:06] bialix: bzr 1.13 got 35k downloads [00:06] garyvdm: but now igc's installer stuff will rule the world [00:06] mwhaa mwhaa mwhaa [00:06] haha [00:07] bialix: so getting explorer 'in the box' is essential [00:07] to ramping up it's adoption [00:07] igc: ok, I've groked your idea already [00:07] "Bazaar Explorer wins hands down over RapidSVN" - latest quote received overnight [00:07] ok ok ok [00:08] hands down? [00:08] igc: will we get a start menu short cut for explorer? [00:08] it means easy? [00:08] bialix: whats happening with bzrw.exe? [00:08] garyvdm: that's the plan [00:08] garyvdm: oh! we definitely should create shortcut [00:09] aaaaaaaaaaaaahhhhhhhhhh [00:09] bialix: "Bazaar Explorer wins *easily* over RapidSVN" [00:09] there's too much little thing here and there [00:09] igc: I hope I won't forget all of them [00:09] garyvdm: thx [00:10] bialix: well I'd be fixing many explorer little things today if I was doing the installer instead! [00:10] igc: you should be proud [00:10] we should be proud - I'm a small part [00:11] you wrote most of it [00:11] ohloh said line count of explorer codebase is roughly the same as qbzr [00:11] bialix: right, but epxlorer is a small part compared to bzr core and qbzr and ... [00:11] just numbers [00:11] it's just the bit people *see* [00:11] don't be so shy [00:12] * bialix waits for new quote: bzr-explorer wins hands down over TortoiseBzr [00:12] :-# [00:12] :-) [00:13] bialix: the bigger question is, does it win over tortoise-hg? [00:13] so, igc, 2am here, and soon I'm going to sleep. [00:13] igc: honestly? [00:13] bialix: good night - chat in 8 hours or so [00:13] yes, +8 hours from now [00:14] hg beats as almost everywhere -- this is my opinion [00:14] hello all [00:14] garyvdm: thanks for releasing 0.14.1 [00:14] hi poolie [00:14] garyvdm: now we should ask for updating karmic? [00:14] good night bialix [00:15] poolie: hi and gnight [00:15] bialix: Yes will do [00:15] garyvdm: you rock [00:15] igc: you too [00:15] and sidnei and all all all [00:15] gnight [00:15] bialix: so do you [00:15] bialix: thanks! [00:15] night [00:16] Hi poolie [00:16] hi [00:24] hi [00:24] does bzr have equivalents to submission keywords such as HEAD? === tommieb is now known as t0mm13b [00:30] morning poolie [00:39] * igc away from IRC and email for a few hours [00:40] moldy: are you looking for this? http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#specifying-revisions [00:41] zsquareplusc: not quite, i think [00:42] zsquareplusc: i am looking for an easier way to say "show me the last committed change" [00:42] zsquareplusc: something like "bzr di -c tip" [00:42] then revno:-1 should help [00:42] moldy: bzr log -l 1 [00:43] garyvdm: not quite what i am looking for [00:43] what is di short for? [00:44] diff [00:44] moldy: bzr diff -c -1 [00:44] -1 = tip [00:45] ok, that works [00:46] bzr di -c last: [00:46] works, too :) thanks [00:47] jam: using something with a non C-guaranteed backend would be good for testing [00:47] jam: e.g. 'anything with write(bytes)' [00:47] poolie: NEWS in 2.0.0 still says 2.0rc2 and 1.18.1 aren't released yet [00:48] hi [00:48] on phone [00:48] in 2.0 or 2.0.0? [00:48] poolie: 2.0.0 [00:48] hm ok, i'll check [00:48] it might have bounced from pqm [00:48] or I might be brain dead [00:49] 1.18.1 isn't something I'd really expect 2.0.0 to mention :) [00:49] poolie: sorry, me brain dead [00:50] lifeless: just in the NEWS file which becomes the Release Notes, of course [00:51] lifeless: chapter tile was "1.18.1 NOT RELEASED YET" [00:51] lifeless: tends to stand out :-) [00:51] igc: oh [01:20] Night all. [01:22] igc: in 2.0.0? i thought i fixed that [01:38] poolie: you did. I just needed to pull your change down locally [01:52] jam, nice work on Keys() [01:53] spiv, around? [01:58] poolie: call? [01:58] 1m [01:59] poolie: I am, although my ADSL apparently may not be :( [02:05] is it possible to merge two independent branches into one (i.e. have 2 separate CVS modules converted, that should go together) [02:06] zsquareplusc: "bzr merge -r0..-1 ../other-branch" [02:07] ah, you have to use a range :-) i just tried single revisions. thanks spiv [02:55] * Pilky collapses [02:55] if anyone is interested, I've just released version 0.1 of my Objective-C Bazaar API: https://launchpad.net/objective-bzr [03:12] Endless struggle, release at 4am, die of heart attack. [03:12] That's always a good sign. Usually good code comes from that. === abentley1 is now known as abentley [03:43] AfC: So... good software clogs the arteries? [03:44] fullermd: Well, you know they gave it their all. Sacrificing for the cause. [03:44] so much for non zero sum [03:44] Either that, or they didn't want to have to deal with support... [03:48] * igc lunch [05:35] jam: bzr+ssh://bazaar.launchpad.net/~lifeless/meliae/strip_duplicates/ [05:40] poolie: those mails are on my plate, will finish this evening approx; EODing till then more or less, meeting family in town. [05:40] k [06:11] 435 class GlobalConfig(IniBasedConfig): [06:11] 436 """The configuration that should be used for a specific location.""" [06:11] why? [06:11] that seems like it's not global [06:22] poolie: "global" in the sense that it's per-user rather than per-branch? [06:23] I agree that it's confusing. [06:23] it doesn't seem like it's used for a specific location? [06:23] leaving aside it being per-user not per-machine [06:23] or per-planet ;) [06:37] only functions on the Material Plane [06:42] :) [07:00] hi all [07:38] Can I have some feedback on shell-like tests ? No feedback is hard to interpret... [07:47] hi vila [07:47] yes i'll read it today, soon [07:48] poolie: great ! The merge thought will help me in the next half-hour :-D === vila is now known as vila-dentist [07:48] * vila-dentist afk for ~1/2h [07:50] 'mere'? [07:50] good luck [07:56] I hope so. Combining merge thoughts with dentists doesn't help *ME*... [08:21] spiv, still around? does bug 427736 mean anything to you? i'm apparently getting xml inventories in what's meant to be a chk stream [08:21] Launchpad bug 427736 in bzr ""unknown object type identifier 60" in bencode " [High,In progress] https://launchpad.net/bugs/427736 [08:28] igc: hi again [08:28] hi bialix [08:29] poolie: I have question for you [08:29] and hi [08:29] hi [08:29] poolie: I'd like to have some logo for QBzr [08:29] i mean, sure, go ahead [08:29] but I'm not very good in computer graphics [08:30] recent incredible work on b-v.o site redesign makes me think it will be cool to have the help here [08:30] hi bialix [08:30] poolie: is it possible? [08:31] igc: so after some hours of sleep I think I should focusing on inno setup installer script improvements [08:31] bialix: i think so [08:31] we can probably get someone in canonical's graphic design group to help [08:31] but they're pretty busy [08:32] poolie: cool, I have couple of ideas for logo, but then good designer need to improve it [08:32] heh [08:32] poolie: it sounds like the bug that jam fixed recently that I encountered doing the inventory streaming work [08:32] can you send a mail to me and beuno with your thoughts? [08:32] poolie: it means you're positive but not sure [08:33] i'm sure they would be happy to help but it might be hard to get to the front of their queue [08:33] spiv, yes, it does, i thought we'd squashed these though [08:33] poolie: specifically, that CHK repositories were generating XML inventories when you called some APIs [08:33] poolie: I can draw by hands and then send my sketch to qbzr ml and cc you and beuno, yes [08:33] Right. [08:33] this seems to be the opposite [08:33] or not precisely opposite [08:33] bialix: the buildout recipes for explorer and the chm files are done now [08:33] if we can give them the concept it should be faster [08:33] poolie: well, what are the bzr versions involved? [08:33] bialix: grab rev 7 [08:34] LP is involved, I think, which is probably still running an affected version? [08:34] spiv, the tip of 2.0 here, and [08:34] yeah, that may be so [08:34] igc: so for CHM stuff I think I should add separate items for each language, so users can select what they want to have installed [08:35] poolie: bzr ping claims lp uses 1.17 [08:35] interesting [08:35] poolie: which is affected IIRC. [08:35] :/ [08:36] igc: so we put chm docs in C:\Program Files\Bazaar\docs just instead of old html, right? [08:37] poolie: yes, IIRC jam fixed this as part of the 'bzr send of 2a' bug, which NEWS says was fixed in 1.18rc1 [08:37] bialix: I think so. Either there are directly in the Bazaar directory [08:37] * spiv makes a note of that on the bug [08:37] thanks === vila-dentist is now known as vila [08:40] igc: so my plan is following: I'm update bzr.iss script for 2.0 and will update buildout receipe to override the one in bzr sources, so installer will be built from our tweaked script [08:40] igc: post 2.0 we can continue extract things (like py2exe) to your separate branch [08:40] bialix: excellent [08:40] poolie: lol, yeah 'mere' interesting freudian slip :) [08:40] bialix: today i've ... [08:41] I hope to finish installer during weekend and then we need jam to build new rc installer so I can test it with TBZR [08:41] built the help, updated the TODO and added the recipes for epxlorer/xmloutput/upload and CHM files [08:41] bialix: sounds good [08:42] bialix: I'll work on getting explorer 0.8 done over the weekend - no time for that today [08:42] igc: so I'll update translations ;-) [08:43] bialix: I've updated the buildout recipes to pull in qbzr 0.14.1 as well [08:43] ok [08:43] igc: we need to look at buildout improvements made by jam in bzr.dev/2.0 [08:44] * bialix found intermediate result of buildout layout awful [08:45] last question to bzr experts: is it possible to get overall size of the branch repo (in MiB) via remote dumb/smart transport? [08:45] this morning I'm thinking about resumable branch/pull/push [08:46] bialix: time to go - family stuff to do for next few hours [08:46] I can write simple hack to pull in small portions [08:46] igc: bye [08:46] bialix: thanks for your help! [08:46] poolie, spiv, vila, all: have a good weekend [08:46] night all [08:46] igc, you too! [08:46] igc: g'night and good week-end ! [08:46] spiv, in this kind of case i'd like to teach bzr to blacklist that op on that server [08:46] ditto from me [08:47] on 1.17 i mean [08:48] poolie: what is correct branch for 2.0rc2? lp:bzr/2.0 or some other? [08:48] bialix: I think you need to get the size of the packs, I don't remember an API for that (and that will still not get you the size of the indices...) [08:49] poolie: or https://code.launchpad.net/~bzr-pqm/bzr/2.0.0? [08:49] bzr/2.0.0 [08:49] see my mail 'branchs, bugs... 2.0' [08:49] bialix: lp:bzr-repodetails certainly contains interesting stuff in that regard [08:49] ok [08:51] vila: can I talk with you about my idea with plugin of resumable pull/push? [08:51] bialix: hmm, it you want to make it a plugin, then I think the effort will be better spent making the core resumable, [08:52] what accidental scenarios do you want to address ? [08:52] pulling/pushing a very big branches is several steps automatically [08:53] can they be recognize by bzr and acted upon (ctrl-C, network connection loss sound possible to address) [08:53] so if connection breaks or just time out user can resume it later [08:53] s/is several steps/in several steps/ [08:54] last night there was mini discussion about resumable pull in core [08:54] bialix: I understand the approach, I'm wondering about what could be done in core to make it useless :) [08:54] Oh, I missed that then [08:54] the short answer: bzr would like to do it but can't [08:54] oh, ok, I'm late in the game then ;) [08:54] can't today because it's not clear how ideal solution should work [08:55] vila: you can check irclogs from the point when we started talking about git [08:55] jam, lifeless and jelmer talking [08:55] I will do that later eventually, or do you think I need to read it to talk about your plugin ? [08:55] something about atomic insert prevents to have it in the core [08:56] bialix: Hmm, I can imagine it's not trivial, especially with gc [08:56] well, basically I want to talk my idea and have someone who listen and critize [08:56] bialix: shoot then :) [08:57] criticize [08:57] you already started doing this ;-) [08:57] so main idea is automatically get last_revision info from remote repo and then divide pull into smaller steps [08:57] right, but if it can't be done in core, then pulling by steps is the next best thing [08:57] like pull by 100 revisions at once [08:58] I'm just would like to know the size of remote repo [08:58] not only number of mainline revisions [08:58] bialix: I would go with a simple --step parameter and leave the user in control (use 128 or 256 as default value) [08:58] hmm, maybe [08:59] just for fat branch of 200 revisions and overall repo size of several GiB I'd like to step in smaller delta [08:59] I think there are too much criteria to take into account to make educated guesses: repo size, bandwidth, latency, connection quality, server robustness, server load, etc [08:59] yep [09:00] so in the end, only the user, at a given time (and even...) can roughly guess what is the "right" step [09:00] well, I imagine such plugin can measure how long each steps and then do some prediciton? [09:00] It seems like with the current structure it would be hard to work in granularities other than revision. [09:00] What you can add, though. is say: if it doesn't complete in 5mins, break it and try again with a smaller --step [09:00] vila: actually I've struggled last night with buildout and its desire to get fresh copy of bzr branch from lp [09:00] (though there are *BIG* advantages to being able to do so, even aside from this incremental question) [09:01] fullermd: A balance between #revisions, elapsed time, yes [09:01] vila: so some sort of auto adjusting of step will be nice, so I can have stepped-branch command aliased to plain branch and use it automatically all the time [09:02] Yah. But as long as things currently work as they do, when the bulk of the size is the 5 gig first revision, nothing will help. [09:02] vila: to use it with tools like buildout [09:02] bialix: I encounter such problems with the botnet and had to set the timeout to 1h and use a shared repo (where possible) [09:02] fullermd: yes [09:02] fullermd: sure [09:02] (luckily, that's relatively rare) [09:02] fullermd: and then the answer is: Don't do that ! [09:03] That's too facile an answer in the DVCS world sometimes :| [09:03] vila: also about stepped-branch: I should branch exactly one revision from remote to get correct branch/repo format and then start stepped-pull [09:03] Frankly, who will try to use Mosiac to go to say.. Facebook ? [09:03] Dunno. Why would you use ANYTHING to go to Facebook? [09:03] fullermd: vila: lol, I never laughed so loudly from your Mosaic experiments [09:03] fullermd: I hate that answer, but sometimes that's the only reasonable one, see example above [09:04] fullermd: while you're here: do you plan to build 1.18.1 package for bsd? I want to update bzr on my hosting [09:04] bialix: There is a very serious idea behind these experiments nevertheless ... backward compatibility [09:04] With 2.0 so close, and the major change being on Windows, I hadn't planned to. [09:04] fullermd: ok, so I'm stick with 1.18 [09:05] Wait... there was serious reason behind it? I was just doing it for S&G... [09:05] bialix: you use FreeBSD on your hosting ??? [09:05] Why stuck? [09:05] S&G ? [09:05] well, my hosting provider run freebsd [09:05] wair a sec [09:05] (i.e., why wouldn't 2.0 be good 'nuff?) [09:06] fullermd: how can I get os version? [09:06] uname -a [09:06] from command-line [09:06] bialix: uname -a [09:06] :-D [09:06] vila: Shi... stuff & Giggles [09:06] FreeBSD donkey.tophost.com.ua 6.2-RELEASE-p9 FreeBSD 6.2-RELEASE-p9 #1: Thu Jan 3 17:39:10 EET 2008 [09:06] poolie: do you want me to repush that branch or did you merge it another way? [09:07] fullermd: So, 'uname -a' tells you about the base system, but what about ports ? [09:07] Well, there isn't a "ports version"; there are only versions of individual ports. So you'd have to look at the ones you care about. [09:08] * vila frowns [09:08] fullermd: I was expecting better :-/ [09:08] vila: repodetails plugin does not work for lp:bzr [09:08] vila: should I file a bug? [09:08] bialix: certainly [09:08] bialix: it's very surprising given it has been developed *for* bzr.dev and used mainly there [09:09] poolie: 2.0 does blacklist that op [09:09] s/*for* bzr.dev/& first [09:09] Well, I guess you could import the ports tree from CVS into bzr and use the head's revno as some sort of overarching version... not sure what information that would actually communicate though. [09:09] AssertionError: Don't know how to process RemoteRepository(bzr+ssh://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/.bzr/) [09:10] fullermd: some sort of equivalent of the distros releases [09:10] poolie: or rather, it will give a UnknownMethod response to that particular request because it knows the client won't be able to use the stream. [09:10] bialix: ha right, use sftp then [09:10] I mean, what does "ports version" matter; you care about what version Apache or Firefox or bzr is. [09:10] fullermd: a single data point is easier to grasp [09:10] Well, if he's got bzr 1.18, I'm confident he doesn't have a ports tree shipped with 6.2 :p [09:10] even if (of course) less precise [09:11] fullermd: sure, don't pretend you didn't understand my question ;-) [09:11] vila: https://bugs.launchpad.net/bzr-repodetails/+bug/427751 [09:11] Ubuntu bug 427751 in bzr-repodetails "`bzr repository-details lp:bzr` fails" [Undecided,New] [09:11] Someone correct me if I'm wrong… with bzr's 2a format, performances for the long operations are more CPU-bound than I/O-bound, right? [09:11] (Not talking start-up time here) [09:11] vila: use sftp then is not option sometimes [09:11] Lo-lan-do: ETOOGENERAL [09:12] vila: I'm not sure I really _do_... what are you looking for? "$DATE of last time I updated my ports tree"? [09:12] vila: Fair enough. Let's restrict to "bzr check", for instance. [09:12] Most of my long bzr operations have been CPU-bound since 0.6.2... [09:12] fullermd: somethinh like that yes, "Is it a two years old install or a recent one" [09:13] Lo-lan-do: still a bit hard to answer :-/ Let say that most of the operations are faster and the repositories smaller than with previous formats [09:14] I'm probably going to recommend a nightly or weekly bzr check at a client's if I can get them to switch to bzr, but since they have large (CVS) repos it may take some time. [09:14] From there, we do less IO, so it doesn't always translate into more CPU [09:14] Yeah, I don't think of check as IO bound. I've got repos under 20 megs that take several minutes to check; might be IO bound on a floppy, but... [09:15] vila: and last one about stepped operations: I can save result of latest step in the branch.conf so user can use stepped-continue to continue. something like rebase doing. does it sound as more or less make sense? [09:15] bialix: as long as user can still override from command-line, yes, [09:15] override what? [09:16] the branch.conf value [09:16] why for? [09:16] Good. Next question: when working in bound branches (or pushing to a bzr+ssh server), most of the CPU-intensive stuff is avoided on the server, right? [09:16] but are you sure you will always have a branch.conf to start with ? [09:16] And the shared repo on the server "only" has to repack from time to time? [09:16] vila: I mean I've pulled 200 revs from 100. I save this counter and name of operation (pull). Then run `bzr stepped-continue` to continue [09:17] vila: yes, for stepped-branch is most logical step is to create local branch with 1 revision inside [09:17] vila: so basically stepped-branch op is: branch REMOTE_URL -r1; bzr stepped-pull [09:18] bialix: that sounds fine with standalone brances, but what about shared repos ? [09:18] and what about shared repos? [09:18] bzr working at branch level [09:19] shared repo is behind the scene [09:19] stepped-pull will be like this: for i in range(1, LAST_REVNO, STEP): bzr pull -r i..i+STEP [09:20] stepped push is similar [09:21] bialix: with shared repos stepped pull makes more sense for the revisions you don't have yet [09:22] vila: is not they will be skipped automatically? [09:22] vila: I have good results of invoking run_bzr and run actual CLI bzr commands (in scmproj) for doing stuff [09:22] vila: I'd prefer to not dive into bzrlib API [09:23] then I can write such stepped plugin very quickly [09:23] bialix: they will succeed by virtue of not involving problematic operations :) [09:23] I'm not quite understand, can you re-phrase? [09:24] vila: ^ [09:25] If I branch bzr.dev in a shared repo and bzr step-branch 2.0, almost all revisions are already in the repo [09:25] most of the steps can't fail since there is nothing to pull [09:25] * bialix bbl, sorry [09:25] bialix: You may well ignore that [09:42] Right, google calendar unreachable for more than 2 hours, imminent death of the net ? [09:43] mine works [09:43] Damn, no, same mistake than a couple of days ago: when *redirected* to an error page, *don't* hit refresh :-( [09:43] Only the part of the net whose users think google==net [09:48] Wait... you mean Google isn't the whole Interblog? [09:53] Lo-lan-do: you mean you're not aware that Google owns most of the black fiber ? [09:55] I use yoghurt cans and string for my Internetz. [09:55] Oh, no wonder you come through all muddled. [09:55] You gotta stick with coffee cans, man. [09:56] A bzr check tells me I have 7 inconsistent parents. Should I worry? Could bzr reconcile fix that? [09:57] I'd have a little chat with Mom and the mailman, myself... [09:57] But yah, reconcile fixes that. [09:57] (I've learned that ghost revisions can be safely ignored so I won't bother you about that) [09:58] Here goes a reconcile then. [09:58] * fullermd still wishes the two could be combined. [09:59] I want a combination check/reconcile/pack/garbagecollect, so I can fire off a "bzr makemybranchallneatandtidy" before I go to bed, and wake up knowing that it's as good as it can be. [10:00] * Lo-lan-do concurs [10:01] Um. There's a garbagecollect now? [10:01] Well, no. That's one reason I want it :p [10:01] Ah. [10:02] I had started working on it at FOSDEM with one of you guys, but it never went anywhere. [10:03] I forget who it was, possibly Odd_Bloke. [10:05] Sure wasn't me. I don't do python. Or FOSDEM, for that matter. === mrevell is now known as mrevell-luncheon === Adys_ is now known as Adys [13:04] fullermd: ping === kiko-afk is now known as kiko [13:16] Blah. After a bzr reconcile, I no longer have inconsistent parents, but I still have a few sha1 mismatches. Any way to fix that, or is my repo seriously corrupted? [13:19] It seems they're all on revisions coming from svn. I'll see if I can get rid of them by doing a fresh checkout. === cprov-afk is now known as cprov === mrevell-luncheon is now known as mrevell [13:51] Hi vila [13:52] hey garyvdm ! [13:54] garyvdm: your example in #427773 is bogus, what we care about is how we end up with a limbo dir :) [13:55] oh, right, there is a cascading bug too [13:55] but let's search the root cause anyway, this should never happen and identify a real problem [13:57] Is there a way to find out exactly where in the DAG ghost revisions are? [14:02] vila: Please can you give me a pointer. I want t write a test for bug 427773. I want to run bzrlib.merge.Merge3Merger.do_merge with a limbo dir, and check that it unlocks. [14:02] vila: I'm not sure where to put this test, and should I test other Merger classes? [14:02] Launchpad bug 427773 in bzr "empty limbo dirs prevents to successful execution of bzr commands and left working tree locked" [Undecided,Confirmed] https://launchpad.net/bugs/427773 [14:04] garyvdm: can you read me ? [14:08] garyvdm: when I was playing with building the installer 1.14.1 didn't exist yet. I'll certainly use it for the final rc2 build [14:08] morning vila [14:08] morning jam ! [14:13] vila: Hi [14:13] garyvdm: can you read me ? [14:13] * vila thinks garyvdm has net problems that makes this channel a write-only medium :-/ [14:15] My irc is very flaky [14:15] vila: I think I know what is causing bug 427773. I'm writing a test to confirm it. [14:15] Launchpad bug 427773 in bzr "empty limbo dirs prevents to successful execution of bzr commands and left working tree locked" [Undecided,Confirmed] https://launchpad.net/bugs/427773 [14:15] garyvdm: Good [14:16] garyvdm: I'm still interested by what *caused* the limbo dir creation [14:16] garyvdm: but no need to leave the branch locked, so your fix will be welcome anyway === goneri is now known as Lenickquetuveux === Lenickquetuveux is now known as Goneri === thekorn_ is now known as thekorn [14:32] Does TortoiseBzr form part of the linux and macos distributions of bzr? === deryck_ is now known as deryck === lamont` is now known as lamont [14:37] ChrisW: Nope, it's a windows only thing [14:37] ChrisW: bzr-explorer is considered a better alternative, and that is available (or shoudl be) for all platforms [14:39] meh, I desktop integration... guess I'll look at TortoiseHg instead ;-) [14:42] haa, nothing like a good and opened discussion.... :-/ [14:42] lol [14:43] vila: if he waited a few days i'd have a 0.1 of a native Mac client out [14:43] his loss :p [14:44] Pilky: tortoisebzr on mac ? great ! Is that a fork of the existing lp project or do you sync with naoki ? [14:44] heh not tortoisebzr [14:44] completely new client from scratch [14:44] james_w: are you looking into why the ppa builds started failing? [14:44] one I tried starting ages ago but gave up on [14:45] Pilky: a standalone app then ? [14:45] yep [14:45] I release 0.1 of an Objective-C framework for talking to bzr last night, I'm working on 0.1 of the app this weekend [14:45] Pilky: he said disktop integration and by this I think he meant finder-integration in mac vocabulary [14:45] yeah [14:46] probably [14:53] Hi vila. Sorry - my irc is very flaky, so I am now using http://www.web-irc.org/.. [14:53] igc: are you still around? [14:54] hi jam [14:54] hey igc [14:54] you know, you should really sleep... but since you are up [14:54] vilia: I saw what you said here: http://irclogs.ubuntu.com/2009/09/11/%23bzr.html [14:54] the ppa builds are failing with: cp: cannot stat `debian/tmp/doc/_static/en/quick-reference/bzr-quick-reference.pdf': No such file or directory [14:54] do you know what changed there? [14:54] jam: yep :-) [14:54] name is now ... [14:55] bzr-en-quick-reference.pdf [14:55] garyvdm: I also said (later): your fix is good, we want your fix :) [14:55] jam: if you look in http://doc.bazaar-vcs.org/test/downloads/pdf-en/ say, you'll see ... [14:56] that all the pdfs use that convention so I tweaked the quikc refs to follow it too [14:56] vila: Ok - did not see that - thanks [14:57] vila: Are the tests ok? [14:57] garyvdm: I don't know, I've yet to see your patch, I was talking about the principle of your fix [14:57] garyvdm: we want your fix AND we want to understand why bialix encounter the problem in the first place [14:58] i.e. what is the 'mkdir limbo' in his case [14:58] vila: I see. [14:58] garyvdm: pew, finally :-) [14:58] ChrisW: bzr-explorer is shipping on windows, gnome, kde and os x and working well on each [14:58] igc: He left... [14:58] vila: My fix is here: https://code.edge.launchpad.net/~garyvdm/bzr/Bug427773/+merge/11601 [14:59] vila: thanks [14:59] igc: and he want desktop integration aka tortoise and nothing else (that's how I understand him at least, since he didn't stay to say) [15:00] vila: ok [15:00] vila: the bug gary posted, I believe the original 'mkdir limbo' was a bzr merge that got interrupted by a power outage [15:00] at least, from his follow up post [15:00] if updating the workingtree fails badly, we leave stuff like limbo around [15:00] it doesn't happen often anymore, since we can rollback for stuff like symlinks, name collisions, etc. [15:01] but I would assume there are still possibilities [15:01] jam: really badly then because it's been a while since I encountered it for the last time [15:01] vila: it has to be an unhandled exception, yes [15:01] and we handle a lot [15:04] garyvdm: wow, that's TDD.... [15:06] vila: :-) [15:07] The nice thing is that I don't have to understand what you fixed and where you fixed it. The test are short and clear enough to demonstrate that you diagnosed the problem, had them failed, fix the problem, had them pass. So since PQM will catch you if you cheated, I can just approve :-D [15:07] garyvdm: Add a NEWS entry ! [15:07] garyvdm: so the problem was that after the failure the WT was still locked? [15:07] jam: yup [15:07] *left* locked [15:07] garyvdm: it helps to say that in the merge proposal [15:08] though apparently vila has been following on enough to already know [15:08] garyvdm: jam is right, I knew from following the bug comments, but it helps all reviewers to summarize [15:09] garyvdm: the NEWS entry can partly address that too :) [15:09] igc: your change seems ok. I'm wondering what the packaging bug is, then. [15:09] is it something in Make that is talking about the pdf, or is it a debian/* directory issue [15:09] jam: some MANIFEST file checking file presence ? [15:10] vila: My gut feeling says it is a bug in the packaging script [15:10] which as you say, is something like MANIFEST [15:24] Hmmm. Since there's no after: keyword in revisionspecs, is there a way of getting a log of stuff that happened after a given revid? [15:24] revid:.. [15:25] This includes the given revid. [15:25] I'd like to get stuff that happened strictly later than that. [15:25] (For a commit hook) [15:27] Lo-lan-do: err, why do you want to use a revspec if you're already in a commit hook ? [15:27] Lo-lan-do: What are you trying to get your hands on ? [15:27] I don't understand the question. [15:28] Lo-lan-do: me neither :) Let's try again [15:28] Lo-lan-do: What are you trying to get your hands on ? [15:28] Trying to run "bzr log -r $old..$new$ and not get $old listed [15:28] in a commit hook ??? [15:29] In a shell script that'll be run by a commit hook, yes. [15:29] Think commit emails, for instance, or triggering builds, or whatever. I want to keep the genericity of just calling a $repo/.bzr/hooks/post-commit script. [15:30] right, why not stay in your commit hook in python where you can call bzrlib.log.show_branch_change for example ? [15:31] def show_branch_change(branch, output, old_revno, old_revision_id): [15:31] """Show the changes made to a branch. [15:31] :param branch: The branch to show changes about. [15:31] :param output: A file-like object to write changes to. [15:31] :param old_revno: The revno of the old tip. [15:31] :param old_revision_id: The revision_id of the old tip. [15:31] """ [15:31] jam: fyi, reasonable progress on the new windows installer today [15:32] I want to keep the external shell script, because it may be used for other things than commit emails. [15:32] igc: good to hear [15:32] jam: I'm packaging explorer 0.8 this weekend and bialix is making innosetup and py2exe related fixes so everything should be good for ... [15:33] packaging on Windows by Monday your time [15:33] igc: any chance to do it sooner? I'd like to have a full build for the guys in Canada [15:33] and I'll be flying early monday morning [15:33] if not, no prob, I'll survive [15:33] jam: ping bialix and check [15:34] jam: I lack the expertise to make all the required installer changes [15:34] jam: though the buildoutv recipes are now done and more-or-less working [15:35] igc: I'm more concerned about bzr-explorer [15:35] vila: I've updated news. Please will you submit to pqm. [15:35] jam: so bialix hopefully has enough to tweak py2exe and the iss file from here [15:35] jam: ah, ok [15:36] garyvdm: you need a second vote :) [15:37] jam: I'll see how I go [15:37] vila: ok - Not sure how to get launchpad to update the diff, with out loseing your review. [15:37] night all [15:37] garyvdm: you can't [15:38] jam: care to have a quick look at https://code.edge.launchpad.net/~garyvdm/bzr/Bug427773/+merge/11601, I'll merge if you approve [15:39] garyvdm: also, naming your branches 427773-unlock-when-limbo instead of just Bug427773 helps [15:43] vila: approved [15:43] jam: thks [15:45] garyvdm: pqm'ed [15:45] vila, jam: Thanks [15:46] garyvdm: thanks to *you* :-D [15:48] vila: As it's a simple bug fix, should I submit it for 2.0? [15:49] garyvdm: since it isn't a regression, no [15:49] vila: ok [15:49] bbl [15:51] vila: simple bugfixes are expected for 2.0 [15:51] for the 2.0.1 stuff [15:51] as long as it isn't an api change [15:51] I think it should land for 2.0.1 [15:51] garyvdm: ^^ [15:51] >-/ [15:51] the point of the 2.0.x series is "bugfixes without features" [15:52] regardless regressions [15:52] vila: though it is a "feeling" thing [15:52] that we will have to tune with time [15:52] we can always "ask poolie" :) [15:52] my gut feeling is that we'd better keep the regression rule in place... [15:53] or we'll be back-porting everything, or am I already contradicting myself regarding spiv recent case.... [15:56] vila: spiv's is a code cleanup [15:56] I'm 90% sure we aren't keeping the regression rule [15:56] regression rule is for the "what do we backport for an rc" [15:56] bugfixes get done on the stable branch [15:57] the whole point is to give people bugfixes without features, not having to do with regressions [15:58] I really need to draw myself a picture with release numbers and associated dates :-/ [16:01] vila: well, 2.0.1 is likely to come out the same time as 2.1.0b1 [16:02] with 2.0.1 == bugfixes only, 2.1.0b1 == bugfixes + features [16:04] and we'll merge 2.0.x in 2.1 regularly then... I still have a feeling that we shouldn't need a 2.0.0 branch.... [16:04] 2.0 and 2.1 have to be enough or something escape me [16:04] vila: we need 2.0.0 branch so that I can land patches for 2.0.1 before 2.0.0-final is out [16:04] rc2 has been cut [16:05] which means 2.0.0 is imminent and bugfixes shouldn't land there [16:05] regressions can [16:05] land them to 2.0.1 then ! [16:06] or wait for 2.0 to be out.... [16:06] that's the part I'm missing... [16:07] sounds like more troubles than benefits, but well, it may just be that I don't look at it from the right POV [16:08] and I'm grumpy because I can't find some notes I took a couple of weeks ago, so there ! [16:10] vila: well, if it helps, there is no 2.0 [16:10] it will be 2.0.0 [16:10] lp:bzr/2.0 == the 2.0.x series [16:10] which *was* 2.0.0 until the 2.0.0rc2 was cut, when we started a new branch [16:10] the same as 'trunk == current series' and we create a new branch at rc time [16:11] yes, I liked that branch, do you mean that we will just use lp:bzr/2.0.x from now on ? [16:11] Then, yes, it helps [16:11] Arguably it would be clearer if the branch was explicitly called "lp:bzr/2.0.x" rather than "lp:bzr/2.0" [16:14] anyone know the magic attributes to tell gcc that a function is a "printf" style function, and it should check the % codes? [16:15] jam: http://gcc.gnu.org/onlinedocs/gcc-3.2.3/gcc/Function-Attributes.html [16:15] extern int [16:15] my_printf (void *my_object, const char *my_format, ...) [16:15] __attribute__ ((format (printf, 2, 3))); [16:16] vila: thanks [16:16] * vila bounces to jam and google :-D [16:21] haaaaa, found them ! [16:24] vila: you have some 64-bit machines at your disposal, right? [16:24] jam: yes, karmic or jaunty [16:24] can you do: "bzr co lp:meliae; cd meliae; py setup.py build_ext -i; py run_tests.py" ? [16:26] jam: Ran 101 tests in 0.027s [16:26] OK [16:26] s/py/python/ first :) [16:26] gotta love that 27ms [16:26] vila: I always alias py => python [16:26] mostly because on Windows it is [16:27] /cygdrive/c/Python26/python [16:27] which is crappy to type [16:27] :-D [16:27] how long does it take to run for you ? [16:27] 0.031s [16:27] on my laptop [16:27] vila: any compiler warnings? [16:28] __Pyx_GetItemInt and __Pyx_SetItemInt defined but not used [16:28] for _loader.c and _intset.c [16:28] is there a way to generate a patchset with bzr. i.e. i want to add a special formated comment and then export the last n revisions as patches .... [16:29] vila: you probably need a newer pyrex :) [16:29] jam: :-P [16:30] fm: you might look at 'bzr send' [16:30] bzr send -o filename [16:30] can put the data into a file [16:30] or log -p [16:30] but it generally exports all-at-once, not one patch per rev [16:31] but i'd like one patch per rev. [16:31] fm: log -p [16:31] fm: it's not supposed to be applied to a bzr branch? [16:31] vila: looks great [16:32] fm: for i in `seq A B`; bzr send -o filename.$i -r before:$i..$i; done [16:32] fm: care to explain your use case ? [16:32] fm: depends whether you want something that we can "bzr merge $YOUR_PATCH" [16:32] or whether you just want to send it to someone to look over [16:33] i am collaborating with people on a translation project. and they do not use version control systems. the patches are discussed by email. the target repository is an svn repository. but most patches are attached in pieces (my local revs) into a bug tracking system. [16:35] jam the for loop was my idea, but i thought there must be something prettier ... [16:36] in a perfect world i could modify allready committed versions ;) [16:37] fm: may be you want a branch for each of your patches instead and *then* you can use send and all its goodies :) [16:38] the translations files are huge (40.000+ lines). and i create patches by topic to be easier to review. a patch just doing simple spelling mistakes. then one correcting spaces. and others changing some "meaning" [16:39] vila: is is possible to "restack" branches as i do not know in which order the patches are applied in advance. they should not conflict ... [16:40] is it possible to "restack" branches? [16:40] fm: they do overlap ? [16:40] vila: they might [16:41] do you use bzr-svn >? [16:43] vila: no [16:44] i do not have any access to the server. i.e. i must contribute in patch form [16:44] ok [16:45] I don't have a really good answer, the problem is that you're working without connection to the svn server, at least having a mirror of that server locally (with bzr-svn) may help you find better workflows [16:46] using bzr should help you remove that " they should not conflict" constraint, if they conflict you can easily solve the conflict locally and then submit updated versions [16:47] otherwise, the short answer is 'log -p' [16:48] but log -p does not allow me to modify later if i missed a string. [16:49] short of (uncommit, shelve) dance until you get to the proper patch, no [16:49] followed by (unshelve; commit) dance, but you'll tired of dancing soon [16:49] an alternative is loom or maybe pipeline (I don't use the later) [16:50] but I'm unclear about 'log -p' will work there, you may want to add a '-n[123]' there and find the good one [16:59] * vila EODing with a violent headache :-/ === tro|| is now known as tro [17:04] i want to have a branch changing "get" to "got" and another one changing "car" to "vehicle". now i want to be able to reorder in which order they have to be applied to the base. [17:05] as there might be a line containing get and car. or at least in the three lines before and after === deryck is now known as deryck[lunch] [17:46] I cannot commit to my newly created bzr branch. [17:47] bzr: ERROR: Permission denied: "rynyps2dbs221zpo09ag.pack": [Errno 13] Permission denied: '/data/.bzr/repository/upload/rynyps2dbs221zpo09ag.pack' [17:47] bzr version 1.17 [17:47] It is certainly true that I lack write permission to /data [17:47] But I don't know of any good reason why write permission to that directory should be required. [17:48] Why does this happen? How can I fix it? [18:13] Did I leave something important out that makes it difficult to answer? [18:14] is your branch somewhere under /data? [18:15] or perhaps under a directory symlinked leading to /data? [18:15] if you create a new branch, it will go up to / looking for a repository to use [18:20] My branch is beneath /data, yea [18:20] How do I stop it from going up looking for a repository? [18:21] And how do I undo creating the branch? Just delete the .bzr directory which was created? [18:21] create a new repository [18:21] yes [18:21] (bzr init-repo) [18:22] Thanks, that worked. [18:23] Maybe bzr should only go up to / looking for a *usable* repository, and fall back to . if none is found? [18:25] I guess that figuring out what "usable" means is finicky and fiddly. === deryck[lunch] is now known as deryck [19:40] lifeless: I merged your streaming changes, though I had to make a bunch of tweaks to make sure it support python 2.5 and windows peculiarities [19:40] We should probably split up files.py a bit more and have more direct testing [19:41] otherwise if you have gzip it doesn't test the code path without it, etc. === t0mm13b|ZZzzzz is now known as t0mm13b [19:46] vila: how are patchsets like the ones sent to the linux kernel mailing list created? [19:48] Yhay - I finally got a decent internet connection. [19:50] is there a bisect plugin? [19:52] Tak: https://launchpad.net/bzr-bisect [19:53] nice, thanks [19:54] AFAIK most plugins for bzr are listed here: http://bazaar-vcs.org/BzrPlugins [19:54] so that's the best place to look if you want something [20:00] fm: 'bzr log -p' is not much like the kernel patchsets, which have the embedded data to recreate the git repository [20:00] 'the result of 'bzr send' does have the ability to recreate the data [20:01] jam i guess quilt is what i want [20:01] fm: the general bzr equivalent is 'bzr-loom' or 'bzr-pipeline' [20:01] which is the same idea of preparing a series of patches [20:01] just looking at the pipeline ,) [20:01] but does it without 'throwing away' as much history [20:02] Pilky, Tak: There is also: https://launchpad.net/bazaar which is the list of projects under the Bazaar banner. [20:05] http://bazaar-vcs.org/BzrPipeline sounds good [20:07] cool, thanks [20:08] is there anything for pipeline or loom, they seem quiet similar [20:08] fm: They are roughly similar, but store things on disk a bit differently [20:09] hopefully i do not have to edit the on disk format ... [20:09] fm: Sure. [20:09] bzr-pipeline works 'with regular branches' while 'bzr-loom' works with a custom branch format [20:09] I'm not sure if that means much to you now [20:10] but it means that the individual bits that you are working on [20:10] can be more directly accessed in 'pipeline' [20:10] (they have a path on disk, for example) [20:10] which will still be maintained in two years? [20:10] fm: which ever one stays possible [20:10] from current PoV, both [20:10] are these plugins used by any "big" project? [20:11] fm: Both are used by developers hacking on Launchpad [20:11] and Bazaar [20:11] what do you consider "big" [20:11] Though from my understanding of the internals, neither should have any trouble scaling [20:13] jam big was more about the project than the files. just was interested how others decided between the two. but i guess i will look at both [20:13] fm: Well, abentley was the one who put together pipeline to work on Launchpad because he wanted 'more direct access' than loom gave him [20:14] as such, he's started getting more people in Launchpad using ti [20:14] it [20:14] 'loom' was around earlier though [20:14] so I don't know how many users of each [20:14] if *I* was choosing, I would go with pipeline probably [20:14] it is closer to how I already work today [20:17] is there a way to find out whether a Repository object is representing an actual repository or a standalone branch? [20:17] besides checking if it returns 1 branch url from find_branches() and that url is the same as the repo [20:20] ah found it, was looking for is_shared() [20:20] bzr: ERROR: add-pipe should be run in a lightweight checkout. See bzr help pipeline for details. [20:20] Pilky: yep [20:21] i have a local repo created with a simple bzr init. what is the difference of a lightweight checkout? [20:23] fm: bzr init-repo --no-trees repo; bzr init repo/branch; bzr co --lightweight repo/branch working_tree; from there "add-pipe" [20:26] bzr reconfigure should do if i am reading correctly [20:26] it should [20:27] http://how-bazaar.blogspot.com/2009/07/breaking-up-work-for-reivew.html [20:27] what do i loose by going leightweight? [20:28] no local history?? that is why i use bzr instead of my svn repo .... [20:29] fm: if you have a 'bzr init-repo' you still have the data locally [20:29] just not in the working tree itself [20:29] mostly you just gain flexibility [20:29] as the working tree can point at multiple branches === ahasenack is now known as andreas-away === JaredWigmore is now known as JaredW === andreas-away is now known as ahasenack [22:25] you cant pull from 2a into 1.9 repo? [22:26] hsn: only into a 1.9-rich-root repo [22:26] hi SamB [22:26] jelmer: hello === kiko is now known as kiko-afk [22:56] Hi pygi. [22:57] hi garyvdm [22:57] how are you doing my friend? [22:57] pygi: At uds, you were running WinXP inside you desktop environment. How do you do that? [22:58] pygi: Good and you? [22:58] garyvdm, virtualbox [22:58] garyvdm, could be better, folks at uni are bugging them [22:59] pygi: thank you. I'm maintaining a website written in .asp, and so I have to boot into windows to often :-( [22:59] Hi Jelmer [22:59] hi Gary [22:59] garyvdm, I understand the problem. Virtualbox seems like an adequate solution for the problem [23:00] jelmer: Do you know of any plugins that implement commit_message_template hooks? (I know of bzr-builddeb) [23:02] garyvdm: bzr-builddeb is the only one I know of as well [23:02] jelmer: Ok - Thanks [23:03] garyvdm, any cool things you've done recently? :) [23:03] pygi: No - just lots of bug fixing. [23:03] awww [23:04] at least you did more then me :( [23:04] my uni is amazingly bugging me [23:05] pygi: Work hard! I all ways regret that I never finished at uni. [23:05] Party hard. There's plenty of time for work later. [23:05] exarkun, hardly. I'm in a bad enough situation already. [23:06] pygi: Nothing that some more partying can't solve, I'm sure! [23:06] garyvdm, yes, I will. But I also need to fix some stuff in bzr-gtk :P [23:06] * pygi looks at vila [23:06] Forget work and party. SLEEP hard; there'll be no time for it later. [23:07] pygi: Not a day goes by that I don't think about creating a gtk qbzr port (gbzr...) [23:07] garyvdm, what's the point? :D [23:07] I don't care about toolkits war xD [23:07] Well, once you've got gqbzr, you can port it to Motif, see... [23:08] pygi: neither do I, but there are lots of people that won't use qbzr because its written qt. [23:08] garyvdm, why do we even market it as such? :) [23:08] lets call it something else, so most won't even notice :p [23:09] fullermd, :D [23:09] pygi: My idea is that gbzr would be a branch of qbzr. When new features get added to qbzr, then you merge qbzr into gbzr, and port the changes. [23:10] When I have time.... [23:10] garyvdm, my opinion, which doesn't matter too much in this case, is that doing that is a waste of resources [23:10] jam: I agreee [23:10] jam: (re split ups and testing etc) [23:11] garyvdm, limited resources, while we're at it [23:11] pygi: but that would be less work that maintaining qbzr and bzr-gtk [23:12] *than [23:12] garyvdm, possibly [23:13] Any way - It's just a crazy idea in my head. I think I'm destined to just think about it, but never start for ever.... :-p [23:18] what is it in bzr-gtk that has a state? after a fresh login, it always fails with an exception when i run the 1st command and any successive run works :/ === Noldorin_ is now known as Noldorin [23:20] zsquareplusc: it's a bug in seahorse [23:21] garyvdm, we might talk about this one day. perhaps next UDS? UI stuff for bzr is getting better every day, but such diversity is hurting us (with no real maintenance on everything) [23:22] jelmer: ah. i had suspected bzr-notify. can i do something to fix that or just wait for 9.10 ;-) [23:22] zsquareplusc: you can uninstall searhose if you don't use it for anything else [23:23] hm, no option, i use it [23:23] zsquareplusc: otherwise, wait for 9.10 indeed [23:23] pygi: is there really anything that can be done, other than having upstream gtk and qt merge? [23:23] jelmer, surely ppa must have newer seahorse for 9.04 somewhere? :) [23:24] not aware of any [23:24] jelmer, not sure, make people stop caring about toolkits? :p [23:24] jelmer: get the pyqt package split into pieces like the qt libs are ? [23:25] SamB_XP_: how would that help? [23:25] then I would probably have room to install enough to install qbzr ... [23:26] Ah, in that sense. [23:26] I don't think disk space is the problem for most people though [23:26] okay, I don't know why they care so much [23:27] I mean, it would be *nice* for things to look and act consistantly with eachother ... [23:27] yeah, that's my main reason for picking bzr-gtk over qbzr [23:27] jelmer: https://code.launchpad.net/~lifeless/subunit/perl-install/+merge/11498 [23:28] ... but, you know, that doesn't seem to stop many people from using gitk as their preferred git visualization tool ... [23:34] Actually, disk space kept me from even looking at qbzr 'till I built this new system... but build time would have factored in too. qt4 is _big_. [23:35] Startup time is another issue [23:36] jelmer: what do you think of my idea? [23:41] Night all [23:57] Is there any way to have bzr-notify poll remote branches?