=== bob2_ is now known as bob2
=== bob2 is now known as Guest50183
=== Guest50183 is now known as bob2
=== t0mm13b is now known as t0mm13b|ZZzzzz
[03:17]  * igc lunch
[03:26] <spm> not quite sure how to describe this: have a branch that on codehost that is only using 216Kb of disk; yet our copy is 50Mb; bzr pack reduces the pack file to a single 44Mb monster. fwiw this is managed by config-manager if that helps at all.
[03:27] <SamB_XP_> spm: I've a suggestion: fetch a new copy ;-)
[03:27] <SamB_XP_> then, do the old switcheroo
[03:27] <spm> good ol' rm-rf :-)
[03:28] <BasicOSX> Hello, http://bazaar-vcs.org/Download click bzr-2.0rc1.tar.gz link is broken.  http://launchpad.net/bzr/2.0/2.0rc1/+download/bzr-2.0rc1.tar.gz
[03:33] <spm> SamB_XP_: gah. is even bigger. 56Mb now.
[03:34] <SamB_XP_> spm: pulled from the 216K one ?
[03:34] <spm> aye
[03:34] <spm> via config-manager
[03:34] <SamB_XP_> what happens if you just "bzr fetch"?
[03:34] <SamB_XP_> er. branch.
[03:34] <SamB_XP_> too many damn vcses, there are
[03:35] <spm> bzr branch, standalone as in. 650Kb.
[03:35] <spm> :-)
[03:36] <SamB_XP_> spm: what does config-manager do to it ?
[03:36] <SamB_XP_> and ... 650K is still >2x as big :-(
[03:38] <spm> SamB_XP_: cm, is the magic that pulls all the various sourcecode branches together that are used under, eg, Launchpad
[03:39] <SamB_XP_> what does it do rather than "bzr branch" ?
[03:39] <spm> i should add we *don't* get this issue - to our noticing :-) on the launchpad tree itself. So is very odd.
[03:39] <spm> lifeless'd be the best to ask on that score i spect
[03:39] <SamB_XP_> spm: what format did you say the branch is in ?
[03:40] <spm> Branch format 7
[03:40] <spm> tho.. also get Standalone tree (format: unnamed) from a straight info
[03:41] <SamB_XP_> er, repository-format-wise, I mean
[03:42] <spm> repository: Development repository format - rich roots, group compression and chk inventories == that one?
[03:42] <SamB_XP_> spm: ah, yeah, that's even 2a ...
[03:42] <spm> 'k
[03:42] <spm> i woder if it's sharing or something in some weird way
[03:43] <spm> Branch history: 57 reviosns -is also what I get from a bzr branch of same
[03:43] <spm> yet: Repository: 10382 revisions
[03:43] <spm> which seems... excessive for such a small branch
[03:43] <SamB_XP_> indeed!
[03:45] <spm> is there some way you can tickle bzr to show what files/whatevers it thinks it's holding a pack? am searching for any even vague clue as to wtf at this stage
[03:45] <spm> in a pack, as in.
[03:47] <spm> Ahh. clue: the branch up on LP codehost is stacked on another. I suspect we may be getting a copy of the entire stacked branch...
[03:48] <SamB_XP_> ah. that's likely ;-)
[03:49] <spm> next Q becomes "WHY!?!?!?" and then "HOW DO WE MAKE IT STOP!!!" ;-) I think at this point I'll pull all the info together and throw an email at Rob.
[03:49] <spm> thanks SamB_XP_ for your time, much appreciated
[03:50] <SamB_XP_> happy to be captain obvious for you ;-)
[03:50] <spm> heh
[03:51] <SamB_XP_> (that's another name for "help desk", I think ;-)
[03:51] <spm> Teddy Bear in the Corner is another
[03:52] <poolie> igc, sphinx is in review
[03:52] <poolie> spm, would you mind making a new pqm branch for us this afternoon
[03:52] <spm> poolie: sure, 1.19?
[03:52] <poolie> no, 2.0.0
[03:53] <poolie> igc, are you back?
[03:53] <poolie> coming off 2.0, for the 2.0final release, so that people can land things targeted at 2.0.1
[03:54] <poolie> spm, regarding your funny branch:
[03:54] <BasicOSX> poolie:  seem my comment about broken download link?
[03:54] <spm> poolie: sure; so is that 2.0.0 you want? or 2.0.1? Just to clarify.
[03:54] <poolie> there is no ui to find out what's in a pack but it is feasible to do it through the api and we could possibly add a tool
[03:55] <poolie> also, you could file a bug or support question about that branch
[03:55] <poolie> BasicOSX: no
[03:55] <BasicOSX> http://bazaar-vcs.org/Download click bzr-2.0rc1.tar.gz link is broken.  http://launchpad.net/bzr/2.0/2.0rc1/+download/bzr-2.0rc1.tar.gz
[03:55] <spm> poolie: ok, ta. I suspect the latter is the way to go. fwiw it's not so much "A" branch, as about 2 dozen of 'em.
[03:56] <poolie> spm, so actually you can do it now if you want
[03:56] <poolie> that's a branch coming off 2.0 and called 2.0.0
[03:56] <poolie> or later is fine, just let me know
[03:56] <poolie> BasicOSX: thanks
[03:56] <spm> cool, 2.0.0 it is, and doing now is fine - pizza is apparently heating in the oven as we speak! :-)
[03:59] <igc> poolie: back for 15 minutes or so
[03:59] <poolie> igc, so the submission bounced but i'll fix it and resubmit
[03:59] <poolie> then cut a release
[03:59] <poolie> thanks for your feedback on ej's draft
[04:00] <igc> poolie: tests failed?
[04:00] <poolie> mm, see the mp
[04:01] <poolie> or actually don't, it's shallow
[04:01] <poolie> you just need a copyright statement
[04:01] <poolie> though that might be hiding other failures
[04:01] <poolie> at any rate i'll follow up
[04:01] <poolie> i might get some lunch first though
[04:02] <igc> poolie: thanks. I'm able to head off for a medical appointment
[04:02] <igc> s/able/about/
[04:03] <spm> poolie: should be all systems go: https://code.edge.launchpad.net/~bzr-pqm/bzr/2.0.0
[04:03] <poolie> great
[04:04] <poolie> good luck igc
[04:04] <igc> poolie: that's a generated file btw
[04:04] <igc> that's why I didn't add a copyright
[04:04] <poolie> we can tell it its an exception
[04:05] <igc> sounds the right choice to me
=== cprov is now known as cprov-zzz
[04:19]  * igc off the doctor - bbl
[04:19] <igc> off to the doctor, that is
[04:50] <jml> poolie, the new page looks really good.
[04:51] <jml> poolie, I think the serif font for "Bazaar" clashes with the rest of the page, fwiw.
[04:52] <poolie> mm
[04:52] <poolie> you should say so in the thread then
[04:55] <jml> poolie, ok. will do.
[04:56] <jml> (I was hoping to short circuit finding the right message in the thread :))
[04:56] <jam> poolie: did you cut an official 1.18.1? Your patch seemed to go through pqm just fine
[04:56] <jam> I noticed because I was getting kerguelen 'rebuilt' slightly with the 2a upgrade
[04:56] <jam> and it seemed to build a 1.18.1 with a mbp revision
[04:56] <poolie> jam, i didn't make the tarball yet
[04:56] <poolie> right
[04:56] <poolie> i don't have any more changes for 1.18.1
[04:57] <poolie> also, spm just made a 2.0.0 branch for us
[04:57] <poolie> oh, except someone snuck in to pqm in front of me :)
[04:58] <jam> poolie: is this 2.0.0 or 2.0.0-rc2 ?
[05:01] <poolie> it's the branch leading up to 2.0rc2 then 2.0
[05:01] <poolie> so other 2.0.x suitable stuff can land on bzr/2.0
[05:03] <lifeless> why not land on 2.0 directly?
[05:04] <lifeless> actually, I'll ask that tomorrow; today I have a plane to catch.
[05:04] <poolie> i'm drafting a mail, it will be out in a bit
[05:04] <fullermd> What will you do with it when you catch it?
[05:04] <SamB_XP_> for a split second I heard "crash"
[06:11] <poolie> spiv, thanks for putting progress onto the ~ bug
[06:12] <spiv> poolie: np
[06:12] <poolie> and the kind of pre-impl note, really
[06:13] <spiv> Seeing as it was already marked "In Progress" I needed some other way to make it visible that it really is in motion again :)
[06:14] <poolie> replied
[06:14] <poolie> yes
[06:26] <jam> poolie: I went ahead and created the 1.18.1 release, since I had the installers built
[06:26] <jam> you can cut the tarball when you lke
[06:27] <jam> http://launchpad.net/bzr/1.18/1.18.1
[06:27] <poolie> jam, i just did it
[06:27] <poolie> thanks
[06:27] <poolie> i was going to <https://code.edge.launchpad.net/~mbp/bzr/trivial/+merge/11501> stop making source zip files too
[06:27] <poolie> i think you already agreed with that?
[06:27] <jam> poolie: oddly enough, POST doesn't fail instantly when the page doesn't exist
[06:28] <jam> which means I would have had to wait until the whole 15MB was uploaded before it failed...
[06:28] <poolie> hm :/
[06:28] <jam> I've run into that before
[06:28] <poolie> what was sending the post?
[06:28] <poolie> the cheesy upload script?
[06:28] <jam> poolie: curl
[06:28] <jam> *my* cheesy version of it
[06:28] <poolie> we should probably change it to use the api
[06:29] <poolie> :)
[06:29] <jam> which analyzes filenames etc, so it does most of the work
[06:29] <poolie> should we just announce it now, or wait for other builds?
[06:29] <jam> so it is just 'upload.py *.exe'
[06:29] <jam> poolie: I think you need to cut a tarball and announce that on the dev list :)
[06:29] <poolie> i did, there's a tarball there
[06:30] <jam> I'd like to follow our planned announcements
[06:30] <jam> poolie:   bzr-1.18rc1.tar.gz
[06:30] <jam> I think you packaged something slightly wrong
[06:30] <jam> poolie: so, I'd like to follow the plan, but I'm noticing that having to come back 1-week later isn't working very well, either
[06:31] <poolie> hm, good catch
[06:31] <jam> as for 'no zips....' I'm not 100% sure, let's check the downloads
[06:31] <jam> for older versions
[06:32] <jam> poolie: so... foo.zip has very few downloads versus the others
[06:32] <jam> setup.exe 2.5k, tar.gz 1.4k, .zip 122
[06:32] <jam> about 1/10th
[06:33] <jam> fairly consistently
[06:33] <jam> setup.exe is 2x the tar.gz, and the tar.gz is about 10-20 times more than the .zip
[06:34] <poolie> and i suspect some of them are misguided
[06:34] <poolie> and now the 2.0 docs patch landed
[06:34] <jam> poolie: I'm actually pretty impressed that 1.17 has 11k downloads overall
[06:34] <jam> I guess it is extra long because 1.18 was a bit delayed
[06:34] <jam> poolie: approve
[06:36] <poolie> thanks
[06:36] <jam> though I should say... you can open a .zip in plain Windows Explorer, you can't open a .tar.gz
[06:36] <jam> or .tar.bz2
[06:36] <poolie> true
[06:36] <jam> but... I don't think people who want *source* will care
[06:36] <poolie> at least in recent windows
[06:36] <poolie> they can get the source from the nonadmin installer though?
[06:36] <jam> >= XP I believe
[06:36] <poolie> or indeed from bzr
[06:37] <jam> yeah, the source is in nonadmin, I believe
[06:37] <jam> anyway, good night
[06:38] <poolie> good night! and thanks
[06:43] <vila> eerk, hi jam !
[06:43] <vila> hi all :)
[06:43] <poolie> vila, hi
[06:43] <vila> the never-sleeping team :-)
[06:43] <fullermd> vila: Ah, just the person I wanted to see...
[06:44] <fullermd> vila: I've answered your question.
[06:44] <fullermd> vila: http://www.over-yonder.net/~fullermd/dl/bzrdocs.png
[06:44] <vila> . o 0 (*Which* question :)
[06:44] <vila> ROTFL
[06:45] <fullermd> User-Agent: NCSA_Mosaic/2.7b5 (X11;FreeBSD 8.0-BETA2 amd64)  libwww/2.12 modified
[06:45] <vila> wow, now I'm impressed, congrats !
[06:45] <fullermd> I'll bet you serious money I'm the only one on the *PLANET* with that U-A string.
[06:45] <fullermd> In fact, I may be the only person ever to compile it on amd64   :p
[06:46] <vila> my god I forgotten about the default grey background, sniff, tear dropping
[06:46] <fullermd> Took a bit of work.  I guess I should have been doing real work instead, but...
[06:47] <fullermd> Tons of int/ptr size mismatch warnings, probably due to the I32LP64 config.  Probably not overly safe to use I guess, but it was fun   8-}
[06:47] <vila> More seriously, that really kick ass ! No proprietary software can pretend such long term support...
[06:48] <vila> but man, you should have tried a 32bits VM :-)
[06:48] <fullermd> But it does show PNG's!  So there's a white and blue and green arrow sign in the middle of the gray for the homepage.
[06:48]  * fullermd grabs
[06:48] <fullermd> bzr.png in that dir
[06:49] <vila> PNG ??? How comes... relying on a external library even then ?
[06:49] <fullermd> Yeah, it's got libpng support.
[06:50] <fullermd> Really *OLD* libpng support.  That was one of the things that took non-trivial hackery to get running right.
[06:50] <vila> fullermd: but to completely ansewr the question, you need to capture a video of the revolving earth you know...
[06:50] <fullermd> It's funny; I was actually wondering just last week "Dangit, how old a browser do you have to use to not understand <script>?  Why can't people stop putting these stupid comment wrappers around them?"
[06:50] <fullermd> I guess now I know the answer...
[06:51] <vila> aha, you had to hack it... ok
[06:51] <fullermd> Well...  it doesn't revolve very long.  Maybe my connection's too fast for it.
[06:52] <vila> By the way, didn't you mention the 'if it doesn't work, try again' syndrome recently ?
[06:52] <vila> One place where it applies *today* is web browsing !
[06:52] <fullermd> Maybe dunno.  I know I've used "If at first you don't succeed, redefine the parameters of success."
[06:52] <vila> And *that* one is here to stay I fear :-/
[06:53] <vila> I was referring to principle more than the wording itself.
[06:55] <fullermd> igc: ^^^  New docs look wonky in Mosaic   :p
[06:55] <fullermd> Anyway, I guess that fills my "do insane stuff for no good reason" quota for the week.  Back to work!
[06:55] <vila> fullermd: congrats and keep nagging web site devs for compatibility :-D
[06:56] <fullermd> I pulled up Google too.  The javascript took up more space than the rest of the page
[06:56]  * vila wonders about starting a 'support mosaic' campaign....
[06:56] <fullermd> Well, _my_ page works fine in it   :p
[06:57] <vila> Aren't societies defined by how they care of their elders ?
[06:57] <fullermd> (some people might even say it looks better...  not my fault they don't appreciate the genius of my palette.)
[06:57] <vila> Web devs should think a bit more about Mosaic, really....
[06:58] <vila> fullermd: by the way, did you get my mail about that page of yours or did it get lost ?
[06:58] <fullermd> I did.  Sorta skimmed it; have it flagged to look at in detail when have($tuit)
[06:59] <fullermd> But yes, the installer is pretty...   special...
[06:59] <vila> fullermd: ok, np, wasn't sure I sent it
[06:59] <fullermd> It's a prototype.  We're planning to replace it after 2.1.6 release ships.  Maybe after 2.2 if we slip...
[06:59] <igc> fullermd: damn, that's disappointing
[07:00] <vila> I guess that may be reflecting the fact that you're not actively recruiting new users ?
[07:00] <fullermd> igc: Inoright!  Obvious failure in testing...
[07:00] <fullermd> I think it more reflects the fact that nobody's driven a new installer through.
[07:00]  * fullermd isn't joking about the releases where it was considered obsolete   :(
[07:01] <fullermd> If you're doing something simple, and you've used it before, though, it's *REALLY* fast and easy.
[07:01] <vila> fullermd: my point exactly.
[07:01] <fullermd> Yah.  Nobody likes it, though.  Especially code-wise; it's impossible to work with.
[07:02] <fullermd> It's really horrible.
[07:02] <fullermd> There was a drive to integrate the bsdinstaller instead, that gets occasional perks of action.  Been meaning to look at it myself in my CFT.
[07:02] <fullermd> It'd be nice to throw sysinstall into a deep hole   :|
[07:03] <vila> well, as the first point of contact... it's certainly not the best way to be introduced to FreeBSD...
[07:04] <fullermd> Yeah.  It's definitely something that has to be read about before being used.
[07:05] <fullermd> Actually, it's probably less that the devs are used to it, than that they just don't use it.  I know setting up this box, I used an extra drive as a running system, and installed it manually via that.
[07:05] <fullermd> (had to anyway, since sysinstall can't hack ZFS, but I would have anyway just 'cuz it's simpler)
[07:05] <fullermd> ...   anyway, that's way OT here.
[07:05] <igc> poolie: 2.0.0 has the new docs thanks
[07:06] <poolie> yep
[07:06] <vila> fullermd: back to my point again :) New users needs it, actual users works around it :)
[07:06] <igc> poolie: were you planning to submit them to 2.0 or merge across at some point
[07:06] <igc> ?
[07:06] <poolie> to merge across
[07:06] <poolie> probably after making 2.0rc1
[07:06] <igc> you mean rc2 right :-)
[07:07] <igc> vila better you too it :-)
[07:07] <igc> s/better/beat/
[07:07] <vila> fullermd: OT, yes, on the other hand, your help to setup the FreeBSD test slave was invaluable, so thanks again
[07:07] <igc> s/too/to/
[07:07] <vila> igc: ??
[07:07] <vila> ha 2.0rc1 :)
[07:07] <fullermd> vila: Always glad to help   :>
[07:09] <poolie> gosh
[07:09] <poolie> vila: really?
[07:09] <vila> Is there a bug filed about two concurrent processes trying to create the same pack file at the same time ?
[07:09] <poolie> vila, there might be
[07:09] <poolie> do you want to make rc2?
[07:09] <vila> poolie: :-D
[07:10] <poolie> mm
[07:11] <poolie> vila, you're doing it off 2.0.0 right?
[07:11] <vila> poolie: what ?
[07:11] <poolie> > igc: vila beat you too it :-)
[07:11] <poolie> i thought he meant you were going to make an rc
[07:11] <vila> poolie: I think igc joke was about the 2.0rc1 I *did* not about the 2.0rc2 you *will* do :)
[07:11] <igc> poolie: I meant vila called beta1 rc1 accidentally some weeks ago
[07:11] <poolie> but maybe you just merged back to 2.0?
[07:11] <poolie> oh right
[07:11] <poolie> heh
[07:12] <poolie> :)
[07:13] <spiv> vila: hmm, I know I fixed a bug where packing resulted in the same pack.
[07:13] <spiv> vila: but I don't know of a bug report for two concurrent processes.
[07:13] <vila> spiv: different beast,
[07:14] <vila> my case is two processes doing 'bzr update' for two branches in the same shared repo
[07:14] <vila> sometimes, they both upgrade to the same revision from roughly the same revisions and probable requires the same set of revisions which end up creating the same .pack file in upload/
[07:15] <vila> it's pathological at best so there is no hurry, I was just wondering...
[07:15] <vila> I should file it anyway
[07:19] <vila> fullermd: my GF just saw the Mosaic screenshot and had a good laugh when I explainde :D
[07:19] <fullermd> I always try to entertain on multiple continents at once.
[07:28] <poolie> vila, so you're definitely ok for UDS? i told clan you were.
[07:29] <poolie> vila, oh, also, in conflict resolution
[07:30] <poolie> it seems like it would be nice to avoid needing an explicit 'resolve' command if i clearly edited out the conflict markers
[07:30] <poolie> what do you think?
[07:30] <poolie> maybe commit should see if things can be automatically considered resolved, using the same logic 'resolve' with no arguments does
[07:32] <vila> poolie: definitely ok for UDS.
[07:33] <vila> I think resolve is required because some cases are too tricky to get right (or were). I'm not sure I know better at that point
[07:33] <vila> It's true that *I* fail to call resolve in roughly 30% of the cases though...
[07:34] <poolie> me wonders, should we recombine 2.0rc* in the news into just one heading, as we had for 1.17?
[07:34] <poolie> i think we should
[07:35] <poolie> vila, that's great about uds
[07:35] <fullermd> I'd agree.  It's useful during the RC's, but post-release it's just noise.
[07:35] <poolie> i'm just wondering if being required to run 'resolve' ever saves trouble
[07:36] <vila> resolve cleans up the mess (.THIS, .moved, etc) as you go along, I'd be inclined to keep it that way
[07:38] <vila> I mean, conflict resolution, with tenths or hundreds of conflicts are quite stressful, *I* would not like a tool that suddenly sayd: "It's ok, I will clean up some mess, don't worry, everything will be good !"
[07:38] <vila> especially if the tool generated the conflicts in the first place because he didn't know how to merge cleanly
[07:38] <vila> So i'd prefer to put effort to generate less conflicts instead :D
[07:39] <vila> But back to our original point, the idea of resolve --interactive is that the cleanup is more automatic, yes.
[08:43] <vila> Anybody to review https://code.edge.launchpad.net/~vila/bzr/shell-like-tests/+merge/11204 ?
[08:43] <vila> I have more patches coming there, so I could land that first...
[08:43] <vila> I have more patches coming there, so *if* I could land that first...
[09:04] <hno> Is it possible to create a lightweight repository where history starts at a given revision? But keeping sufficient information to be able to pull/push/merge of new changes?
[09:05] <Lo-lan-do> What's a lightweight repository?
[09:05] <fullermd> He means a shallow branch or history horizon or whatever we decide to call it.
[09:05] <fullermd> Stacking is a step toward that, and may be enough.
[09:05] <hno> probably yes..
[09:06] <hno> from what I have read of stacking it's not exactly what I am looking for. The repository should be self-contained, just not dragging along 10 years of history.
[09:07] <Lo-lan-do> Oh, yes, sorry, I read your initial question backwards.
[09:08] <Lo-lan-do> I guess if you don't care about keeping existing checkouts working, you could replay all revisions from the old repo starting at some point onto an empty repo.
[09:09] <Lo-lan-do> The new revisions would be unrelated to the old ones, so you couldn't move stuff back and forth between the two repos though.
[09:09] <hno> Lo-lan-do: I do care about push/pull/merge being possible between this repository and the one with full history.
[09:10] <Lo-lan-do> Forget replay then :-)
[09:10] <vila> hno: stacking is the closest to your needs today
[09:11] <hno> vila: Ok.
[09:11] <vila> hno: but why do you want that ?
[09:12] <Spabby> He folks, we moved our bzr repos to another server which has port forwarding from the outside world, but now when I try to checkout from that server BZR won't do it because the keys do not match, is there any way I can wipe bzr's key database on my local windows machine please?
[09:13] <Lo-lan-do> Spabby: SSH keys?
[09:13] <Spabby> yes
[09:13] <Spabby> I use bzr+ssh
[09:13] <Spabby> and told it to remember the key the first time I used this IP
[09:13] <Lo-lan-do> Probably in the SSH config then.
[09:13] <Lo-lan-do> Using Putty?
[09:13] <Spabby> it is correct, the machine at that address does have a different key; it's a different machine
[09:13] <hno> vila: The repository without old history? because in many situations dragging along the complete history just adds unwanted bloat. The specific use case is feature branches that I want to be just enought to keep the feature but at the same time self-contained not depending on another repository for a checkout,
[09:13] <Spabby> tortoise bzr
[09:14] <vila> hno: why don't you use a shared repository ?
[09:14] <Lo-lan-do> Spabby: I'm not sure tortoise embeds an SSH client.  If it does, though, try looking for a file called known_hosts or so.
[09:14] <Spabby> im just using bzr+ssh to checkout a new branch, but bzr is aware of another machine on that ip and now is trying to warn me that the key has changed, which I know
[09:15] <Lo-lan-do> (I don't do Windows so I can't give you the exact name)
[09:15] <hno> vila: I do, but these are pushed to another server.
[09:15] <vila> hno: haaaa, so you want to stack on the *server*
[09:16] <hno> vila: No, I do not want the complete history to be on that server. Not needed there for it's purpose.
[09:16] <vila> hno not even once ?
[09:16] <hno> not in that repository no.
[09:17] <Spabby> Lo-lan-doI can't find any file that is similar to that name, or looks correct
[09:17] <vila> hno: anyway, you should be able to stack against another server
[09:17] <Spabby> where would I find it on linux?
[09:17] <Spabby> please?
[09:17] <hno> vila: I said I want it to be self-contained not needing access to another repository for checkout.
[09:17] <Lo-lan-do> Spabby: On Linux it's in ~/.ssh/known_hosts
[09:17] <Spabby> ah right it's an OS problem rather than bzr
[09:18] <Lo-lan-do> Spabby: But as I said, it's related to SSH more than Bzr
[09:18] <Lo-lan-do> Hence my question about which SSH client you're using.
[09:20] <vila> hno: hmm, you're very close to being self contradictory you know :-) You can't have the ability to merge while not being able to recognize that you are merging something already merged in your old history
[09:20] <Spabby> the ssh client is tortoise bzr
[09:20] <Spabby> im not using an ssh client to ssh in, im just using the bzr+ssh protocol
[09:21] <hno> vila: I don't see a problem with that.
[09:21] <vila> that's the problem :)
[09:21] <hno> development generally moves forward you know..
[09:22] <Lo-lan-do> Spabby: That protocol still uses an SSH client, even if it's not visible :-) The question is: is it provided by tortoisebzr or is it external?
[09:22]  * Lo-lan-do browses the tbzr website
[09:22] <fullermd> tbzr probably just uses whatever bzr does.  And I think it traditionally grabs putty at least if it's available.
[09:23] <fullermd> Believe it was recently changed in trunk to mostly prefer paramiko, but that's irrelevant for released versions.
[09:23]  * hno read up on http://bazaar-vcs.org/HistoryHorizon and it describes very well what I am looking for.
[09:24] <Spabby> it's in c:\documents and settings\<user>\Application Data\<bazaar\2.0
[09:24] <Spabby> if anyone wants to know :D
[09:26] <Spabby> thanks for the help Lo-lan-do
[09:29] <vila> hno: I was talking about what is possible *now*, staked-on repos are accessed only when needed, the main difference with  history horizon is that you will be told: 'Sorry can't do that, need to access <URL>' where stacked repos don't ask the question,
=== Ng_ is now known as Ng
[09:29] <vila> hno: yet, stacked repos are accessed only when *needed*
=== thekorn_ is now known as thekorn
[09:46] <hno> vila: you can't to a checkout of a stacked branch without access to the full history, not even an lightweight one. Same for diff/log etc.
[09:51] <vila> hno: It seems that either I don't understand you or you're trying to do accomplish something that really requires history horizon, or you found a bug or you don't understand how stacked branches work
[09:52] <vila> you can create a stacked branch locally that will point to the same stacked-on branch than its counter-part on the server
[09:52] <vila> both will have a reduced history if that's what you're interested in
[10:21] <hno> vila: stacked branches works just fine for temporary feature branches in an all-online world. But is a bit too lightweight for many other purposes, mainly missing a shadow/ghost copy of the ancestor revision.
[10:23] <vila> hno: let's not rehash why we need history horizon, you're preaching the choir. I thought you wanted to solve a problem today, with today's features, if that's not the case, sorry for the noise.
[10:24] <hno> vila: I just objected to you saying the main difference is when the two accesses the stacked-on repository. To me that's the minor difference.
[10:25] <vila> hno: no worries :)
[10:28] <hno> I'll use full branches for now. And cheer happily the day history horizons become available.
[10:38] <hno> Hmm... is it supposed to take ages to for 1.18 branch into a 2a repository (both locally)?  CPU been running at 100% for many minutes now... still making progress howeer, but probably another 5-10 minutes before it finishes.
[10:39] <fullermd> Is it 2a on both sides, or is it converting from another format?
[10:40] <hno> source repository is using the 1.9 format.
[10:40] <fullermd> Yah, so that's having to convert the format, as well as rewrite all the revisions on the fly (since it's going poor->rich root).
[10:40] <fullermd> Time consuming.
[10:41] <hno> Ok. So all normal then.
[10:41] <fullermd> Don't forget that because of the root richness, any revs you make in that 2a repo can't be applied to the 1.9 source, so you might not want to do that if there are other branches of it in 1.9 that you care about your changes being portable to.
[10:43] <hno> Hmm... so you can't merge from a 2a into 1.9? Not even via bundles?
[10:43] <fullermd> Into 1.9-rich-root, yes.  Into 1.9, no.
[10:43] <fullermd> (and similarly, 1.9-rich-root can't be merged into 1.9; that's the watershed)
[10:45] <hno> Ok. So I guess there will be some (many) years before we can officially switch to 2a then.. need to wait for main enterprise distros to pick up support.
[10:46] <hno> because I guess that also means you can't pull/push into 1.9 from 2a..
[10:46] <fullermd> Well, 2a is compatible with any rich root format.
[10:46] <fullermd> Which goes back to rich-root-pack, which was in 1.0.
[10:47] <fullermd> (and can with some manual fiddling probably interact with some formats back to 0.15, but you probably don't want to get into that)
[10:47] <fullermd> Of course, moving between knitpack formats (pack/0.92 through 1.14) and 2a can be pretty slow, but that's not necessarily a deal breaker; small blocks of revs don't take near as long as the whole thing.
[10:48] <fullermd> You'd just need a flag day for going rich-root.
[10:48] <hno> ok, that's better. Means we can push relevant branches from the main repository into an older format contributors can access when stuck on older bzr versions...
[10:48] <fullermd> If everybody's recent enough that 1.9 for the central branch is working, then just taking that to 1.9-rich-root would be simple.
[10:49] <fullermd> (well, conceptually; once one branch hops over the rich root boundary, they pretty much all have to follow before they can interact again, but that's a Simple Matter of Cat-Herding  ;)
[10:50] <hno> i think some are stuck on bzr 1.3 unfortunately..
[10:51] <Lo-lan-do> Even Debian stable has 1.5 :-)
[10:51] <Lo-lan-do> (And 1.16 in backports)
[10:54] <fullermd> Well, 1.3 is new enough for rich-root-pack anyway.
=== mrevell is now known as mrevell-lunch
[12:15] <awilkins> Academic question : How would you design a DVCS for a set of data that was itself a directed acyclic graph?
[12:17] <Lo-lan-do> Consider graph-friendly diff and merge algorithms?
[12:18] <awilkins> Do those cover data which is both large and does not have intrinsic ordering like source?
[12:18] <Lo-lan-do> And store diffs as a set of added/removed nodes and arcs?
[12:18] <luks> versioning linked data is a pain
[12:19] <Lo-lan-do> Your nodes don't have identifiers that could be used for ordering?
[12:19] <awilkins> luks: Sure is :-)
[12:19] <luks> especially if you have lots of them
[12:19] <awilkins> Lo-lan-do: They do have identifiers, but we're talking 2.9M node minimum
[12:20] <awilkins> That's for a single version of the core data, and there are presently 12 versions available for historical versioning
[12:20] <Lo-lan-do> Are you versioning a social network?
[12:20] <awilkins> Lo-lan-do: A terminology
[12:20] <Lo-lan-do> Must be loads of fun.
[12:21] <awilkins> Lo-lan-do: Like pulling teeth. Via your colon.
[12:21]  * Lo-lan-do backs away
[12:24] <awilkins> The worst bit today is that I must argue to prevent people putting requirements for permissions or ACLs on this data, or my head may explode.
[12:25] <awilkins> IMHO this requirement is a Bad Idea, especially since they are moving to a distributed authoring system which (should) have a gatekeeper-style flow of data to the release branch
[12:33] <hno> Oh, bzr 2.0rc2 is out?
[12:48] <hno> now the tricky question,, should I push 2.0rc2 into Fedora rawhide so that Fedora 12 can ship with bzr 2.0 (hopefully not a rc by then.. F12 development freeze is 29/9), or wait until Fedora 13 with that upgrade...
[12:52] <vila> hno: no changes are expected between rc2 and final
[12:52] <fullermd> vila: Well, great, NOW you've done it.  The whole thing'll be rewritten now.
[12:52] <Lo-lan-do> What about 1.8.1?
[12:53] <Lo-lan-do> 1.18.1, sorry
[12:53] <vila> fullermd: I didn't mention any release number... Just commenting out in the wild you know, don't take seriously, etc
[12:53] <fullermd> Murphy ALWAYS takes things seriously!
[12:54] <vila> Lo-lan-do: 1.18.1 sources and windows installers are available, OSX ones should follow shortly and THEN 1.18.1 will be announced :)
[12:54] <vila> Subject: bzr 1.18.1 source and Windows installers available
[12:55] <vila> To: Bazaar <bazaar@lists.canonical.com>
[12:55] <vila> Date: Thu, 10 Sep 2009 15:39:36 +1000
[12:55] <vila> Subject: bzr 2.0rc2 source frozen
[12:55] <vila> To: Bazaar <bazaar@lists.canonical.com>
[12:55] <vila> Date: Thu, 10 Sep 2009 17:19:15 +1000
[12:55] <vila> There's a separate branch (see other mail) for 2.0final, which I plan
[12:55] <vila> to do one week from today.
[12:55] <vila> --
[12:55] <vila> Martin <http://launchpad.net/~mbp/>
[12:55] <Lo-lan-do> Yay :-)
[12:56] <vila> so there, it wasn't me saying it, jinx conjured :)
[12:56] <Lo-lan-do> I'm at a client's next week to evaluate a migration to bzr.  I'm bound to get the question of 2.0 availability.
[12:59] <fullermd> Sheesh.  Why don't you just predict the power will stay on and no volcanos will erupt while you're at it?
[12:59]  * vila checks eight-ball furiously
[12:59]  * pygi shoots at vila 
[13:00]  * vila ducks
[13:00]  * pygi sends dogs after vila's ducks
[13:00] <vila> ouch rib hurts
[13:00] <james_w> hno: I'm planning to push 2.0 in to Ubuntu now, so it should work fine for Fedora
[13:00] <fullermd> "I flipped over my magic eight-ball, and it said 'Outlook not so good'.  I said 'Sure, but Microsoft ships it anyway.'"
[13:01] <vila> They said 'Use windows or better' so I used Ubuntu
[13:01] <vila> james_w: \o/
[13:01] <fullermd> Eep!  The Daystar is climbing into the sky!  Must be bedtime...
[13:01] <SamB_XP_> last time it said that near me, I said something like "Wow! wormgas is right for once!"
=== mrevell-lunch is now known as mrevell
=== psynaptic is now known as greg_harvey
=== greg_harvey is now known as psynaptic
[13:55] <jelmer__> wow, we're already well on our way to test 30k
[14:11] <Tak> jelmer__: how difficult would it be to do a ppa for md-bzr?
[14:36] <jam> jelmer__: do you know if there is a bzr-svn that claims compatibility with bzr 2.0?
[14:36] <jam> morning all
[14:37] <jam> vila: the joke works better if you use a windows version
[14:37] <jam> "Use windows xp or better"
[14:37] <jam> as that would be something they actually *do* say :)
[14:37] <vila> ha yes, you're right of course ! Morning jam :)
[14:38] <jelmer__> Tak: hi
[14:38] <jelmer__> Tak: not very difficult, but would require somebody to dedicate time to keep it up to date
[14:38] <jelmer__> jam: the 1.0 branch claims 2.0 support, but hasn't had a release yet
[14:44] <jam> abentley: you sent an email about releasing bzrtools 2.0.0 but I don't think you actually tagged it
[14:45] <jam> maybe because there wasn't an actual change the tag didn't get uploaded?
[14:45] <jam> jelmer__: k, just looking at building a 2.0.0rc2 installer, and obviously that will be important :)
[14:47] <jelmer__> jam: there isn't a version change either, version.py says 1.18.0
[14:47] <jelmer__> (unless I'm looking at the wrong branch)
[14:47] <jam> jelmer__: in the tarball?
[14:47] <jam> I wonder if he created a tarball, and didn't update trunk
[14:48] <jam> jelmer__: the tarball clearly has 2.0.0 in version.py
[14:48] <jam> so I'm missing something
[14:49] <jam> I don't see any other possible branches on: https://code.edge.launchpad.net/bzrtools
[14:50] <bialix> igc: ping
[14:52] <hsn> !pastebin
[14:52] <ubottu> pastebin is a service to post multiple-lined texts so you don't flood the channel. Ubuntu pastebin is at  http://paste.ubuntu.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:54] <bialix> there is also imagebin.ca
[14:54] <jelmer__> ls
[14:54] <hsn> how serious is this problem? http://paste.ubuntu.com/268588/ if i do bzr get and bzr check then newly created repo is ok
[14:54] <balor> How do I throw away the current changes in my working directory?
[14:55] <hsn> balor: bzr revert
[14:55] <bialix> balor: bzr revert
[14:55] <balor> much obliged
[14:55] <bialix> bingo
[14:57] <igc> hi bialix
[14:58] <bialix> hi
[14:58] <igc> rev 3 pushed now
[14:58] <bialix> what is build-bzr-exe.py
[14:58] <abentley> jam: I just didn't push after I tagged it.
[14:58] <igc> my name for the script that the code buried in setup.py could become
[14:58] <igc> bialix:^
[14:59] <bialix> there is no in revno.3
[14:59] <bialix> igc: I see there is Makefile changed and some buildout config
[14:59] <igc> bialix: right
[15:00] <igc> bialix: if you run make, it will take some time to pull everything down from the URLs but ...
[15:00] <igc> it will go close to working
[15:00] <bialix> igc: I think we should import bzr's setup.py and use function from there to get list of bzrlib modules
[15:00] <igc> for me, it falls over bhilding the tortoise stuff because it can't import PyQt4
[15:01] <igc> bialix: that sounds ok to me
[15:01] <igc> bialix: for you, I'm hoping the tortoise stuff will build and then it will get to ...
[15:01] <igc> the commented out setup.py py2exe line in the script
[15:01] <bialix> igc: 1) I don't use buildout and don't plan to use it
[15:03] <bialix> if you think I should then I need some time to install it and get familiar with this technology
[15:03] <igc> bialix: there's nothing to install
[15:03] <bialix> I think this is irrelevant to actual py2exe stuff
[15:03] <igc> bialix: just run make
[15:03] <igc> it bootstraps
[15:03] <bialix> sorry, but your current Makefile require buildout
=== cprov-zzz is now known as cprov
[15:04] <igc> I never installed buildout
[15:04] <igc> bialix: the make file basically ...
[15:04] <bialix> does it will install setuptools in my Python?
[15:05] <igc> 1. bootstraps buildout
[15:05] <bialix> ...run bootstrap.py which trying to run setuptools
[15:05] <igc> 2. uses it to pull down the right versions of the right products
[15:05] <igc> 3. generates a disk image with bzr & plugins installed
[15:06] <igc> 4. calls py2exe via setup.py
[15:06] <igc> 5. runs inno-setup
[15:06] <bialix> igc: sorry, I think I'm interesting only in steps 4 and 5
[15:06] <igc> bialix: and that's where I'm up to
[15:07] <igc> bialix: you have everything needed already for steps 1-3
[15:07] <bialix> so if you have the documented layout how bzrlib and plugins are layed out it's all I need without buildout and setuptools
[15:07] <igc> python, c compiler, pyrex
[15:07] <bialix> igc: I'm explicitly prevent to install setuptools to my py2.5
[15:08] <bialix> igc: gimme layout
[15:08] <bialix> that's all I need
[15:08] <bialix> then I can work on py2exe stuff
[15:08] <igc> the layout is ...
[15:08] <igc> a build_win32 directory with a bzr directory inside that
[15:09] <igc> if you can take the code out of bzr.dev/setup.py that calls py2exe and move it into a script in bzr-windows-installers, I'm happy to do the rest
[15:09] <bialix> igc: sorry, urgent call. can you describe layout in the some document and push it to the branch or mail me?
[15:09]  * bialix bbl
[15:11] <igc> sidnei ping
[15:11] <bialix> igc: if you're ok using scmproj I'll create scmproj-based project for my work to avoid using buildout
[15:11] <bialix> you can transform it to buildout config w/o problems
[15:12] <igc> bialix: sure
[15:13] <jam> igc: don't you know when to sleep?
[15:13] <igc> bialix: the key thing is that py2exe code needs to run against a location where bzr isn't the current directory but some other path
[15:14] <igc> jam: I'm exhausted and in pain tonight :-(
[15:14] <igc> jam: after 2 3pm nights in a row, I need to go to bed
[15:15] <jam> igc: I'm very sorry to hear that
[15:15] <igc> jam: but I'm stuck on the Windows installer and if bialix or someone else doesn't help in the next 24 hours, then we won't have a better one for 2.0
[15:15] <sidnei> igc: oi
[15:16] <igc> jam: given I'm on leave next Thursday and Friday
[15:16] <igc> sidnei: do you have the buildout image documented somehow so bialix can see it without using buildout?
[15:16] <igc> s/somehow/somewhere/
[15:17] <igc> sidnei: see above
[15:17] <jam> igc: what is the sticking point?
[15:17] <igc> sidnei: I'm struggling to get the new bzr-windows-installers project building an installer
[15:18] <jam> as I've certainly dealt with it a bit myself
[15:18] <sidnei> bialix: it will not install setuptools in your python
[15:18] <igc> the current code assumes a py2exe target in setup.py
[15:18] <sidnei> bialix: it will download a copy of setuptools in the 'eggs' directory and use that
[15:19] <igc> and that assumes the bzr being packaged is directly under where the installer artifacts are
[15:19] <igc> sidnei: if you grab the trunk of lp:bzr-windows-installers, you'll see where I'm up to
[15:19] <sidnei> igc: where you said 'generates a disk image', is that something you added?
[15:20] <igc> sidnei: no ...
[15:20] <igc> I just meant it installs the plugins into the bzr getting packaged
[15:20] <sidnei> igc: then that's incorrect?
[15:20] <sidnei> igc: ah
[15:21] <igc> sidnei: I'm still learning how it hangs together
[15:21]  * bialix back
[15:21] <igc> sidnei: btw, it's a shame that generated script is a .bat file - python would be *much* nicer!
[15:21] <bialix> guys, I'm really like when things are documented. at least somehow
[15:22] <bialix> at least a bit
[15:22] <igc> bialix: I will document it
[15:22] <igc> bialix: but I need to make it work first :-(
[15:22] <bialix> igc: I can see what I can do about py2exe tonight
[15:22] <bialix> igc: but promise that you go to bed now
[15:22] <igc> bialix: thank-you heaps
[15:22] <sidnei> igc: i discussed that with jam at some point. unfortunately doing a bunch of calls to subprocess is not something python excels at
[15:22] <igc> shall do
[15:22] <bialix> *now*
[15:22] <bialix> check mail tomorrow
[15:23]  * igc heads off to sleep
[15:23] <igc> night all (and thanks guys)
[15:35] <jelmer__> emmajane: hi
[15:35] <jelmer__> emmajane: what is the plan wrt the maintainance of the new web site? Will it be a wiki again, plain html/python in a bazaar branch?
[15:37] <emmajane> jelmer__, hey :)
[15:37] <emmajane> jelmer__, unconfirmed but *very* likely flat HTML in a bazaar branch.
[15:37] <emmajane> jelmer__, which is part of why I've already got it as flat HTML in a bazaar branch.
[15:39] <jam> jelmer__: do you have a rough eta of a 1.0rc even?
[15:39] <jam> Just to have something that will at least pretend to work with 2.0rc2
[15:40] <jelmer__> jam: there's a critical bug in subvertpy I need to fix, after that I think we're ready for a RC
[15:40] <jam> k
[15:40] <jam> of course, you need to tell me the versions of everything
[15:40] <jam> subvertpy, bzr-rewrite, bzr-svn, etc
[15:40] <jam> I'm always guessing a bit when it comes to making the next release
[15:47] <jelmer__> ok
[15:47] <jelmer__> bialix: did you have a chance to look into bzr-git on windows again?
[15:51] <bialix> jelmer__: not yet
[15:51] <james_w> jam: I just created a version tracking page at http://bazaar-vcs.org/Releases/2.0.0
[15:51] <bialix> I need the patch for bzr-git to allow dulwich be imported in the case of bzr.exe. I don't remember if you merged it
[15:51] <james_w> we can try and get all the versions to go with 2.0.0 on there so that we all know what we are expected to package
[15:51] <bialix> jelmer__: lp:bzr-git is ok to use?
[15:52] <jelmer__> bialix: Yeah, that was merged
[15:52] <jelmer__> bialix: yep, lp:bzr-git is the main branch
[15:52] <bialix> then I'll try to run selftest shortly
[15:52] <bialix> ping me later
[15:52] <jelmer__> bialix: hmm, actually
[15:52] <jelmer__> I think I might have merged the subvertpy one
[15:52] <jelmer__> not the dulwich one
[15:52] <jelmer__> this should be in __init__.py right?
[15:53] <bialix> right
[15:53] <bialix> I'll look
[15:53] <bialix> time passed, I forget the details
=== kiko__ is now known as kiko
=== hsn is now known as hsn_
=== oubiwann_ is now known as oubiwann
[16:23] <jam> can anyone here read Japanese?
[16:23] <jam> I'm getting some spam on my blog, and I'm curious what it says
[16:30] <Lo-lan-do> I can read a bit
=== deryck is now known as deryck[lunch]
=== cprov is now known as cprov-lunch
[16:31] <Lo-lan-do> jam: URL?
[16:32] <jam> Lo-lan-do: I just deleted it, I found a Japanese - English translation online
[16:32] <jam> which did a poor job
[16:32] <jam> but enough to make me know that I didn't want 150,000 yen for men who like women
[16:32] <Lo-lan-do> Okay :-)
[16:32] <jam> Lo-lan-do: excerpt:  性欲のピークを迎えたセレブ熟女たちは、お金で男性を買うことが多いようです。
[16:33] <jam> what was really strange is that there weren't any outbound links
[16:33] <jam> which made me wonder if it was actually a legitimate conversation about my blog in japanese
[16:33] <jam> but no
[16:33] <jam> not at all :)
[16:33]  * emmajane chuckles.
[16:51] <jam> so I have 2.0.0rc2 installers built, but they don't include bzr-explorer, etc.
[16:51] <jam> Should I upload them? (bialix ^^)
=== deryck[lunch] is now known as deryck
[18:00] <james_w> renamed=[(u'README', u'README', 'readme-20090910165710-bk5k711lzk9ktzce-10', 'file', True, False),
[18:00] <james_w> really now?
=== cprov-lunch is now known as cprov
[18:20] <eyalw> Hi, I'm trying to push the initial commit into my branch on LP, and I get :: bzr: ERROR: At lp:saturn-clock you have a valid .bzr control directory, but not a branch or repository. This is an unsupported configuration. Please move the target directory out of the way and try again.
[18:31] <vila> wow, karmic boot + login in ~16 secs (excluding password typing time :-)
[18:31] <james_w> so in a rich root repository a branch gets a random file-id for the tree root on creation?
[18:31]  * james_w waves to vila
[18:31]  * vila waves back ! 
[18:39] <awilkins> vila: Is that Karmic + ext4 ?
[18:42] <vila> awilkins: default install, ext4 yes (keep in mind that's a VM though)
[18:42] <awilkins> So if you have lots of RAM the entire disk may be in it :-)
[18:42] <vila> so that ext4 is a single file on ext3 in the host
[18:43] <vila> I don't think it matter that much at boot... and anyway that's still a huge progress :)
[18:49] <james_w> is it possible to specify or modify the root file-id?
[18:49] <james_w> I'd like it to match another branch, even if they don't share any revision history yet
[19:01] <eyalw> can anyone help with bzr please
[19:02] <Tak> eyalw: try push --overwrite?
[19:05] <Tak> eyalw: btw, there's a monodevelop-bzr branch now for MD 2.0 at https://code.launchpad.net/~taktaktaktaktaktaktaktaktaktak/monodevelop-bzr/2.0
[19:05] <Tak> although there's also a MD 2.2 beta release now
[19:09] <eyalw> Tak: same error
[19:11] <eyalw> Tak: how is that gonna help
[19:11] <eyalw> Tak: if bzr can't commit, how can something that use it
[19:12] <Tak> it won't help in this instance, but we were talking a few weeks ago about md-bzr
[19:12] <Tak> two separate threads ;-)
[19:12] <eyalw> Tak: wow, nice memory : )
[19:14] <Tak> if you do `bzr plugins` , it shows the launchpad plugin, correct?
[19:14]  * Tak brb
[19:18] <eyalw> Tak: so how do I install it
[19:21] <Tak> the easiest way is to branch it, load the solution in md, build it, and drop the dll in ~/.config/MonoDevelop/addins
[19:26] <eyalw> Tak: nm, I jusr recreated the branch, so it fixed the problemo
[19:26] <Tak> cool
[19:32] <eyalw> Tak: I get an error that the remote repository is not compatible with my local shared repository, different rich root support, you know anything about that?
[19:32]  * eyalw is off to gym
[19:32] <Tak> eek
[19:46] <Pilky> hey all, I'm having a bit of a problem with bzrlib
[19:46] <Pilky> I've got a simple branch with 3 files in, lazydog.txt, veryactivedog.txt and a .bzrignore with the rule *active*
[19:47] <Pilky> I create a working tree object (wt)
[19:47] <Pilky> but if I do wt.smart_add(files, save=False) it doesn't detect that veryactivedog.txt should be ignored
[19:48] <Pilky> (I'm using save=False just to test)
[19:52] <Tak> that's the same thing that would happen if you did `bzr add lazydog.txt veryactivedog.txt` , isn't it?
[19:53] <Pilky> oh wait yeah
[19:54] <Pilky> lol, forgot about that
[19:55] <Pilky> Tak: but then how do you get smart_add to add everything?
[19:55] <Pilky> or do I need another method for that
[19:56] <Tak> give it a directory?
[19:56] <Pilky> ah thanks
[19:57] <Pilky> the API docs could really do with mentioning stuff like that
[19:58] <Pilky> might have a go at looking at improving the documentation of bzrlib when I'm bored one night and feel like learning more about bzr's internals
[19:59] <Tak> I think it's in the ui help for add
=== bialix is now known as bialix-py2exe
[20:03] <Pilky> yeah, but if you're developing using an API it's annoying to have to jump to user documentation to find out how an API works
[20:03] <Pilky> that said it's not quite as annoying as the number of undocumented or half documented methods
[20:04] <Tak> the ui api is part of the api, though ;-)
[20:05] <Pilky> oh wait, so it is
[20:05] <Pilky> ah well
[20:05] <Pilky> bad example then :P
[20:05] <Pilky> good example of bad documentation = WorkingTree.commit()
[20:08] <bialix-py2exe> lol
[20:12] <Kobaz> when i load up emacs (22), it loads some sort of bazaar module... anyone know how to disable it?  it makes file loading take forrreeeevvveeer
[20:12] <Kobaz> it only loads the module when i'm in a bzr branch
=== bialix-py2exe is now known as bialix-qbzr
=== bialix-qbzr is now known as bialix
[20:28] <garyvdm> Hi bialix
[20:28] <bialix> hi garyvdm
[20:28] <bialix> lp seems down
[20:28] <garyvdm> I see :-(
[20:28] <bialix> garyvdm: for you too?
[20:28] <garyvdm> yes
[20:29] <bialix> garyvdm: I've planned to update translations in 0.14 branch
[20:29] <garyvdm> Ok
[20:29] <garyvdm> bialix: I'm hoping to release 0.14.1 tonight
[20:29] <bialix> but can't until lp finished maintenance work
[20:29] <garyvdm> I c
[20:30] <bialix> well, in this case no translations update from me
[20:30] <bialix> it's not critical
[20:30] <bialix> do you fixed that bug with locking as you planned?
[20:31] <bialix> guys! anybody has copy of igc's branch with new windows-installer stuff?
[20:31] <sidnei> bialix: i think lp:bzr-windows-installers it is
[20:32] <bialix> sidnei: lp is down *right now*
[20:32] <sidnei> bialix: oh, in which case you want an actual copy. i have one.
[20:32] <garyvdm> bialix: I fixing that bug right now.
[20:33] <bialix> sidnei: I need latest revno 3 which igc did today
[20:33] <bialix> can you publish it or mail me in archive?
[20:33] <sidnei> bialix: i can, i suppose. let me think about how to do it
[20:34] <bialix> it should be pretty small I suppose
[20:34] <sidnei> bialix: i guess you want the actual branch, not a 'bzr export'
[20:34] <bialix> don't care
[20:34] <sidnei> bialix: much easier then, email?
[20:34] <garyvdm> sidnei: bzr senf
[20:35] <garyvdm> *bzr send
[20:36]  * bialix recall my ol plugin gzipped-bundle
[20:39] <sidnei> garyvdm: it's asking me for a submit branch
[20:39] <bialix> sidnei: am I understand correctly that buildout just lay out bzr and plugin branches based on its names?
[20:39] <bialix> sidnei: export will be enough
[20:39] <sidnei> bialix: yes, that sounds correct
[20:40] <bialix> I'll get the actual branch later when lp will back to life
[20:40] <baccenfutter> hi, are noob questions allowed?
[20:40] <bialix> yes, but be careful
[20:40] <garyvdm> sidnei: You can provide you current branch as the submit branch, and provide a -r
[20:41] <bialix> garyvdm: this won't work
[20:41] <garyvdm> baccenfutter: Sure - bialix: :-p
[20:41] <sidnei> garyvdm: -rlast:3 .
[20:41] <sidnei> Bundling 0 revision(s).
[20:41] <bialix> exactly
[20:41] <baccenfutter> I'm about to setup a repository for a collaborative project with a couple of friends - now I don't really quite get, how to go about the main structure.
[20:42] <bialix> sidnei: you can use empty branch (revno.0) as submit
[20:42] <baccenfutter> We want to have the trunk centralized public and a branch locally each
[20:42] <baccenfutter> so do I now go about and init a trunk on the server and then a local repo and branch that into first?
[20:43] <bialix> yes
[20:43] <baccenfutter> oder do I build the whole thing on my box and push that?
[20:43] <baccenfutter> s/oder/or/
[20:43] <baccenfutter> k, so first
[20:43] <bialix> this will work too
[20:43] <garyvdm> baccenfutter: Either
[20:43] <baccenfutter> i'd prefere first, if it would work
[20:43] <bialix> np
[20:45] <baccenfutter> and then how would I wanna design that? /trunk, /branch, brach/user1, branch/user2, branch/foo?
[20:46] <sidnei> bialix: i think it's on its way *wink*
[20:46] <bialix> lp seems back to life
[20:46] <baccenfutter> or is the branch folder created on first branch?
[20:46]  * bialix chase the branch until it run away
[20:47] <bialix> sidnei: thanks a lot
=== khmarbaise_ is now known as khmarbaise
[20:48] <sidnei> bialix: np. fwiw, your server didn't accept the first message i sent, it responded that it was spam
[20:48] <bialix> ah yes
[20:48] <bialix> it's free emial provider
[20:49] <garyvdm> baccenfutter: You need to create that structure, and you can do that how ever you like
[20:49] <garyvdm> baccenfutter: We have a doc on that, let me find it quick
[20:50] <bialix> I have account at gmail which is myname.myfamilyname @ gmail.com
[20:51] <bialix> but I've got your mail already thanks
[20:51] <bialix> sidnei: ^
[20:51] <sidnei> bialix: thank you!
=== cprov is now known as cprov-afk
[20:51] <bialix> sidnei: do you will be around soe time so I can ask about buildout stuff if needed
[20:51] <zsquareplusc> could someone please write an easy to understand help page for bzr split? :p
[20:51] <bialix> sidnei: do you will be around some time so I can ask about buildout stuff if needed?
[20:52] <sidnei> bialix: i will be around for the next 2-3 hours, but ping me directly im not paying attention to irc
[20:52] <garyvdm> baccenfutter: http://doc.bazaar-vcs.org/latest/en/user-guide/index.html#organizing-your-workspace
[20:52] <bialix> sidnei: ping
[20:52] <bialix> this way?
[20:52] <sidnei> bialix: yep
[20:52] <bialix> ok
[20:53] <Kobaz> unkuhnown
[20:53] <bialix> zsquareplusc: may be you don't need it?
[20:54] <zsquareplusc> bialix: i want to have a subtree as standalone branch (splitting sub-projects from a historically grown big tree)
[20:55] <bialix> you still will have entire history for entire project after split
[20:55] <bialix> just less files
[20:55] <bialix> is it your intent?
[20:55] <zsquareplusc> no
[20:56] <bialix> you can try fastimport then
[20:57]  * bialix fears to run buildout
[20:58] <zsquareplusc> ok, so split isn't what i need then. but i have to say that it is not intuitive at all that command. it spits out errors about not being a workingtree which i don't understand
[20:59] <garyvdm> bialix: Can I do the translations import? I interested as to how to do it.
[20:59] <garyvdm> ^for 0.14.1
[21:00] <bialix> garyvdm: I've realized we need to upload qbzr.pot template for 0.4 seies first
[21:00] <bialix> for 0.14 series first
[21:00] <garyvdm> oh
[21:00] <bialix> perhaps I'm just starting this too late
[21:00] <bialix> I can guide you but maybe not tonight right before release, ok?
[21:00] <garyvdm> OK
[21:01] <bialix> garyvdm: ping me if you need my help with release
[21:01] <garyvdm> ok
[21:01] <bialix> I've promised to Ian to help with py2exe stuff
[21:02] <garyvdm> bialix: I don't think any strings have changed from 0.14.0 to 0.14.1. I'll dbl check.
[21:02] <bialix> I think so
[21:02] <bialix> so I think it's not critical for 0.14.1 even if couple of them are
[21:05] <garyvdm> bialix: No strings have change.
[21:05] <garyvdm> So I'm going to do the release now.
[21:05] <bialix> let's rock!
[21:06] <bialix> garyvdm: wait
[21:06] <garyvdm> ...
[21:07] <bialix> can I push one small fix first?
[21:07] <bialix> garyvdm: ^
[21:07] <garyvdm> sure
[21:08] <bialix> just a sec
[21:09] <bialix> garyvdm: done
[21:09] <bialix> thx
[21:10] <bialix> sidnei: does buildout supposed to build svn from scratch?
[21:14]  * bialix wonder why buildout put all components (install them) into the same directory where helper files/dirs resides, why not in subdir?
[21:16] <bialix> jam: are you here?
[21:16] <jam> bialix: yse
[21:16] <jam> yes
[21:16] <bialix> do you know why buildout put downloaded components in the same dir, but not in the subdir?
[21:17] <jam> bialix: I don't really know why, and think it sucks, which is I why I 'fixed' the buildout script in bzr so that it creates a staging directory, copies things into there, and then does its work
[21:17] <jam> I believe you can configure the directories buildout wants to work in
[21:18] <bialix> and why for releases it's not used official tarballs instead of getting branches?
[21:18] <jam> as I think I remember sidnei saying he usually points buildout at local directories in various places on disk
[21:18] <jam> bialix: because I prefer to build from branches
[21:18] <jam> we have a VCS, lets use it
[21:18] <bialix> my home inet is limited :-/
[21:18] <jam> tracking tarballs is sucky
[21:19] <jam> bialix: if you use branches, you don't have to download a lot each time
[21:19] <jam> as you probably already have it in a repo
[21:19] <jam> (after the first download)
[21:19] <bialix> but not so sucky to download svn sources and unzip them :-P
[21:19] <bialix> I don't follow
[21:19] <sidnei> the directories are configurable yes, just come up with a consensus and i can help applying it
[21:21] <bialix> jam: IIUC your proposal is to have one big 2a shared repo and doing build inside it?
[21:21] <jam> bialix: thats basically what I'm doing on kerguelen
[21:21] <bialix> :-/
[21:21] <jam> I think it started with a mix, because bzr-svn was in rich-root, but nothing else was
[21:21] <jam> now that we are moving to 2a, we could simplify a bit
[21:21] <bialix> I see but not quite agree
[21:22] <bialix> sidnei: can I stop buildout execution, fake the big branches (like bzr one) and the resume it?
[21:22] <sidnei> bialix: iirc, yes
[21:23]  * bialix trying
[21:24] <zsquareplusc> ok, instead of splitting up a repository i can re-export from CVS. but i'd like to combine some of the CVS modules in one bzr branch, however export is restricted to one module at a time. is it possible to merge two branches like that? can i simply use bzr merge?
[21:24] <bialix> sidnei, jam: why bzr branches going into $PRODUCT/release ?
[21:25] <bialix> sidnei: I see here .installed.cfg: can I edit it manually and fake some steps?
[21:25] <sidnei> bialix: i believe that's what jam is referring to when he said he's creating a 'staging' directory
[21:25] <sidnei> bialix: yes, though you shouldn't need to
[21:26] <bialix> I'm afraid I'll wait all night until I'll pull all required branches from lp
[21:26] <bialix> and my inet quota will be exhausted
[21:27] <bialix> what's good for kerguelen is not good for mere mortals
[21:27] <sidnei> bialix: you can branch from a local branch into the local build repo?
[21:28] <sidnei> (if you have a local branch of the dependencies that is)
[21:28] <bialix> lol: bzr info said I have: Unshared repository with trees (format: 2a)
[21:29] <bialix> bzr reciepe should not branch. it should init + pull
[21:29] <bialix> so process could be resumed
[21:29] <jam> bialix: init + pull can't be resumed unless you are doing a format conversion
[21:29] <jam> packs => packs fetch is an all or nothing affair
[21:30] <jam> (same for 2a => 2a)
[21:30] <jam> only the cross-format conversion builds things as you go
[21:30] <jam> and then, I think it only does that locally now ...
[21:30] <bialix> I don't have words
[21:32] <bialix>  git operates in the term of hash-addressable objects it can easily support resume I think
[21:32] <bialix> *if git...
[21:32]  * bialix shut up
[21:33] <jam> bialix: there are things we could do. we don't
[21:33] <jam> We used to
[21:33] <jam> lifeless felt that having atomic inserts was better than resumable copies
[21:33] <jam> and it also lets us fetch things 'out of order'
[21:33] <jam> and not worry about it until the stream is finished
[21:34]  * bialix no more believe in ideal solution, sorry
[21:34] <jam> out-of-order fetching actually made fetching quite a bit faster
[21:34] <jam> especially since we can read inventories to determine text keys
[21:34] <jam> and write the inventories to disk
[21:35] <jam> rather than buffering them
[21:35] <jam> or re-downloading them
[21:35] <jam> I've oft wanted a resumable fetch
[21:35] <jam> we just aren't there yet
[21:35] <bialix> sidnei: what should I edit in buildout.cfg to disable fetching of bzr?
[21:35] <jam> bialix: and while git does things in terms of sha1s, it still needs to know when it has the complete set of sha1s
[21:35] <jam> I believe it isn't perfect about resuming fetch either
[21:36] <jam> since it doesn't talk about all file shas
[21:36] <jelmer> I don't think git does resumable fetch either
[21:36] <jelmer> I wouldn't see how, anyway
[21:36] <jelmer> you only get back one pack file from the server
[21:37] <bialix> sidnei: remove bzr from "parts"?
[21:38] <bialix> jam: I think this problem related to recent garyvdm post about downloading too much stuff via dumb transport
[21:38] <jam> bialix: so log in to launchpad, and everything will be downloaded via the smart transfer
[21:39] <jam> jelmer: for the stuff you've gotten so far, you could write it to disk and mark it as locally available
[21:39] <lifeless> moin
[21:39] <jam> I don't know how you would resolve the 'what do I have that you don't question'
[21:39] <bialix> by "this problem" I meant "resumable pull"
[21:39] <jam> which is generally done by inspecting the revision graph
[21:39] <jam> lifeless: morning
[21:39] <jelmer> jam: but you don't have any guarantee about the order of the pack file
[21:39] <jam> jelmer: exactly. So you can't be sure when you've gotten all the content for a revision
[21:40] <jam> without actually focusing on determining that
[21:40] <jam> which is probably not cheap
[21:40] <jelmer> right
[21:40] <jam> lifeless: did I read correctly that you were catching a plane yesterday?
[21:40] <bialix> jelmer: if I know which pack file I need to download from server and I see it present locally I can just omit it
[21:40] <bialix> no?
[21:40] <jelmer> bialix: not with the git smart server
[21:40] <jelmer> bialix: as that generates a pack file on the fly for you
[21:40] <lifeless> neither git nor hg do resumable branches
[21:40] <jelmer> bialix: you don't actually know what it's name is until it's completely sent
[21:41] <bialix> jelmer: but pack has inside objects?
[21:41] <jelmer> bialix: yes, a pack file contains objects
[21:41] <jam> lifeless: well I think hg sort of does, but encourages you to 'hg truncate' if the fetch fails
[21:41] <jam> though they may do it for you
[21:41] <eyalw1> hi, I'm getting an "different rich-root support" error when I try to branch a LP project into my local repo, why is that ? and how do I fix this
[21:41] <bialix> can you recover objects from partially downloaded pack?
[21:41] <jelmer> bialix: that's what jam and I were just discussing
[21:41] <lifeless> jam: I used hg to get this netbeans thing
[21:42] <lifeless> jam: it rolls back on failure
[21:42] <jelmer> bialix: you might be able to recover some objects, but that doesn't really help you
=== kiko is now known as kiko-afk
[21:42] <bialix> sorry, I'm battling with buildout and don't read carefully
[21:42] <awilkins> eyalw1: One end is a rich-root format, the other isn't
[21:42] <awilkins> eyalw1: Is your repo in --2a format?
[21:42] <eyalw1> awilkins: what is a rich root format?
[21:42] <jelmer> bialix: unless you go back and check that you happened to have gotten all of the objects required for a revision it doesn't help
[21:42] <jelmer> bialix: (and the chances of that are slim)
[21:43] <lifeless> jam: bialix: let me say, I'd love resumable downloads.
[21:43] <awilkins> eyalw1: rich-root versions metadata about the root folder, as well as everything else. Which means you can do things like move it
[21:43] <bialix> jelmer: okay okay
[21:43] <lifeless> I just think they are extremely hard to do well; and none of our competitors do them.
[21:43] <bialix> lifeless: but you just trying to say "but..."
[21:43] <bialix> don't
[21:43] <jelmer> lifeless: that's a good reason why we should do them well :-)
[21:43] <lifeless> jelmer: it is
[21:44] <awilkins> eyalw1: It's required for SVN interoperability, and is the default in --2a format - new formats will all be rich root. Older formats were only rich-root if you explicitly said so.
[21:44] <jam> jelmer: well the 'extremely hard to do them correctly' is the main reason we don't
[21:44] <lifeless> I've put my thoughts on the issues on the list before
[21:44] <eyalw1> awilkins: so, do you suggest to use it by default or not
[21:44] <lifeless> atomic insertion has bought us a _lot_
[21:44] <awilkins> eyalw1: I tend to use it by default because I have a lot of SVN repos I interoperate with
[21:45] <lifeless> we used to have lots of rpeository glitches on NFS, and we couldn't do concurrent insertions
[21:45] <bialix> so, no one modern VCS has resumable pull?
[21:45] <eyalw1> awilkins: but for people who don't use svn, is it recommended?
[21:45] <jelmer> bialix: darcs :-)
[21:45] <lifeless> jelmer: does it?
[21:45]  * bialix chuckles
[21:45] <awilkins> eyalw1: I would probably start using --2a for new projects
[21:45] <jelmer> lifeless: I'm pretty sure it does
[21:46] <awilkins> eyalw1: Which is rich-root. Existing projects are mostly not using rich-root.
[21:46] <eyalw1> awilkins: why isn't bzr use it by default today
[21:46] <lifeless> jelmer: it would be interesting to check :)
[21:46] <awilkins> eyalw1: But if you were branching the bzr repository, that moved to --2a a while ago (see topic :) )
[21:46] <bialix> it seems only svn has decent windows support. all others are suck on different tiny details. darcs too
[21:46] <awilkins> eyalw1: Because it didn't historically
[21:46] <jelmer> lifeless: Yeah
[21:47] <jelmer> bialix: even bzr?
[21:47] <awilkins> bialix: I find Bazaar to be the best of the DVCS for supporting Windows, but it has some nasties (like the OS locking thing which stopped you using the powerful shelve 2 command)
[21:48] <awilkins> Certainly git and Mercurial I found to be less Windows-friendly
[21:48] <bialix> awilkins: (proper) support for case-insensitive fs?
[21:48] <bialix> line-endings?
[21:48] <bialix> lifeless almost fixed os locks
[21:48] <awilkins> bialix: I view these as less of an issue ; the only tools silly enough to require particular line-endings I use are windows-only anyway
[21:48] <lifeless> bialix: is it still giving trouble?
[21:49] <bialix> I dunno
[21:49] <eyalw1> awilkins: ok, thanks : ) I guess ill read about it some more on google
[21:49] <lifeless> jelmer: #subunit :P
[21:49] <bialix> lifeless: but ya know: OSLMD
[21:49] <lifeless> bialix: I agree
[21:49] <awilkins> bialix: And I don't create files who's names differ only by case, so that doesn't really cause any showstoppers - if Bazaar handles the "rename a file to a different case of the same name" use case on windows, that's the only one I know about that was a problem with SVN for a long while
[21:50]  * awilkins tests the "rename to different case" thing
[21:50] <bialix> awilkins: I have no desire to chew all this again tonight again and again
[21:50] <bialix> sorry
[21:51] <awilkins> bialix: No problem ; I guess I've just adapted my habits enough that these things are irrelevant to me
[21:51] <bialix> awilkins: I mostly too, but they still blow into the face of novices
[21:52] <bialix> if you want sell a tool to novices you should be perfectly looking
[21:52] <bialix> don't tell people: uh oh, this is known issue, so don't see at this error please
[21:52] <bialix> when I have to tell this in ru_bzr I feel bad
[21:52] <bialix> awilkins: one more thing! diff headers!
[21:53] <bialix> they are in utf-8!
[21:53] <bialix> huh?!
[21:53] <bialix> I hope one day abentley will help to resolve this
[21:53] <awilkins> bialix: No BOM I presume
[21:53] <bialix> awilkins: you're ascii-only guy I assume
[21:54] <bialix> diff for non-ascii filenames show name of the file as utf-8
[21:54] <lifeless> jelmer: ping
[21:54] <bialix> in the windows console
[21:54] <bialix> блаженны незнающие
[21:54] <awilkins> bialix: It seems to cope with the same-name-different-case-rename scenario
[21:54] <bialix> awilkins: this scenario I've fixed many years ago, yes
[21:55] <awilkins> bialix: Yes, British english, CP1252 console
[21:55] <awilkins> Or UTF-8 / 16 powershell
[21:55] <awilkins> And UTF-8 bash
[21:55] <awilkins> (on linux)
[21:55] <eyalw1> awilkins: bzr: ERROR: no such option: --2a
[21:56] <lifeless> jam: ping
[21:56] <jam> lifeless: ?
[21:56] <awilkins> eyalw1: Which version are you using?
[21:56] <awilkins> eyalw1: bzr version
[21:56] <lifeless> jam: py memory dump
[21:56] <lifeless> jam: I want to analyse this 6gb trace
[21:56] <eyalw1> awilkins: 1.13.1
[21:56] <bialix> awilkins: what's about powershell?
[21:56] <jam> lifeless: now officially branded 'meliae' and available as "bzr branch lp:meliae" :)
[21:56] <lifeless> jam: the existing tools seem to want to load the entire thing
[21:56] <jam> lifeless: the general operations do, yes
[21:56] <jam> which is what heapy does, too
[21:57] <jam> just doesn't support 6GB dumps in the first place
[21:57] <awilkins> bialix: Powershell? It's all .NET strings internally so it's UTF-16 in memory
[21:57] <bialix> it's console?
[21:57] <bialix> which encoding it uses?
[21:57] <awilkins> bialix: Yes, next-generation Microsoft console
[21:57] <lifeless> jam: so, the comments about module references and the like are a little unclear to me
[21:57] <jam> lifeless: so how would you reduce what you read in?
[21:57] <awilkins> bialix: Better scripting than cmd.exe
[21:57] <lifeless> jam: mainly because it only seems to me that it would matter when there are global variables that are the leak?
[21:57] <jam> since stripping stuff out would lead to an imprecise picture...
[21:58] <awilkins> bialix: In a lot of ways I find it easier than bash
[21:58] <jam> lifeless: so if you have a function it references its module
[21:58] <lifeless> jam: you should delete the old py_memory_dump +junk branch, or rename it into meliae, so that folk get some sign to chance :>
[21:58] <jam> which means if you have a variable pointing to a function you end up...
[21:58] <bialix> awilkins: std cmd.exe uses OEM encoding, and could be switched to ANSI. But it does not support utf-8 in the way bzr can understand it
[21:58] <jam> which is what 'remove_expensive_references' is somewhat about
[21:58] <jam> for when you want to compute the recursive size of things
[21:59] <lifeless> ok
[22:00] <jam> lifeless: I'm happy to include things that would be useful to you
[22:00] <awilkins> bialix: Did you get the PM?
[22:00] <jam> understanding memory consumption has been pretty tricky for me
[22:00] <lifeless> jam: cc1: warnings being treated as errors
[22:00] <lifeless> meliae/_scanner_core.c: In function '_dump_object_info':
[22:00] <lifeless> meliae/_scanner_core.c:261: error: format '%d' expects type 'int', but argument 3 has type 'Py_ssize_t'
[22:00] <bialix> PM?
[22:01] <lifeless> jam: you seem to have a very good handle on it. I agree that tuple keys are a poor proxy for a compact object btw
[22:01] <jam> lifeless: I run on 32-bit, so don't notice some 64-bit issues. Patches/bug reports welcome
[22:03] <lifeless> jam: if you change that line to use %ld, does it build?
[22:04] <lifeless> jam: have you considered using the unparsed \0 separated strings as keys?
[22:04] <jam> lifeless: changed to %ld
[22:04] <jam> in rev 70
[22:05] <lifeless> jam: theres a bunch more; I was checking ld worked for you :P
[22:05] <jam> lifeless: I've considered something like that, but it doesn't work particularly well for parent lists
[22:05] <jam> lifeless: I changed more than that one
[22:05] <jam> I changed all the Py_ssize_t ones I've found
[22:05] <lifeless> jam: did you change the tests :P
[22:06] <jam> lifeless: the tests passed here
[22:06] <jam> both ways
[22:06] <lifeless> jam: I'll have a patch for you soon :P
[22:06] <jam> there are probably some 64-bit size-of-objects bugs as well
[22:06] <jam> since some things scale, and some don't
[22:06] <jam> I also saw some python 2.6 differing from python2.5
[22:06] <jam> like dicts getting bigger for some reason
[22:07] <jam> I think the GC header actually grew from 12 bytes to 16 bytes here
[22:07] <lifeless>         self.assertSizeOf(6, 'a', extra_size=1, has_gc=False)
[22:07] <lifeless> what does 6 mean here
[22:07] <jam> lifeless: 6 32/64-bit words
[22:07] <jam> extra_size = num bytes
[22:08] <lifeless> yes but why 6
[22:08] <jam> lifeless: because a string has:
[22:08] <jam> ob_refcnt, ob_size, ob_type
[22:08] <jam> 3
[22:08] <jam> hash == 1
[22:08] <lifeless> so 6 means 'string overhead'
[22:08] <jam> flags == 1
[22:08] <jam> lifeless: right
[22:08] <jam> in C
[22:08] <jam> sizeof(PyString) == 6*4
[22:09] <lifeless> so, 64 bit word size is still 4
[22:09] <jam> or 6*8
[22:09] <jam> lifeless: pointers and longs are 8 bytes in python
[22:09] <jam> on 64-bit
[22:09] <lifeless> jam: yes, because neither of those are words
[22:09] <jam> the one that doesn't change is an int field in strings
[22:09] <jam> so it is probably 5*4, extra_size=1+4
[22:09] <jam> or something like that
[22:10] <jam> lifeless: so call the 'basic pointer/long' size what you want
[22:10] <jam> I'm focusing on multiples of those
[22:10] <bialix> awilkins: https://bugs.launchpad.net/bzr/+bug/382699
[22:10] <ubottu> Ubuntu bug 382699 in bzr "diff headers should contain non-ascii filenames in user_encoding, not in utf-8" [Undecided,Confirmed]
[22:10] <jam> lifeless: AFAIK word is still 16 bits
[22:10] <jam> given that microsofts api's use DWORD for Double Word == 32bits
[22:10] <lifeless> jam: it gets worse, as pointer width is a model thing, and there are hybrid arches
[22:10] <lifeless> jam: with 32 bit points, and 64 bit numbers
[22:11] <jam> lifeless: I don't particularly care about getting the test suite to pass on hybrid arches, but if someone cares to put in the effort, great
[22:11] <jam> there are also alignment issues, etc
[22:12] <jam> And I've heard that py 2.7 is going to re-align strings
[22:12] <jam> and cut out a couple of bytes of waste
[22:12] <bialix> wow, buildout finished to get components
[22:12] <lifeless> jam: can you confirm on win32
[22:12] <lifeless>         self.assertSizeOf(4, '', extra_size=0+8, has_gc=False)
[22:13] <jam> lifeless: confirmed
[22:13] <lifeless> thanks
[22:14] <jam> lifeless: on py2.7 I think that becomes self.assertSizeOf(4, '', extra_size=0+5, has_gc=False)
[22:14] <jam> as they use offsetof(ob_sval) rather than sizeof(PyStringObject)
[22:14] <jam> but as I don't have py27 to test, I'm not worried about it
[22:15] <lifeless> lp:~lifeless/meliae/64-bit
[22:15] <bialix> awilkins: one day (soon) I'll plan to write article with some advices how the best work with bzr in windows (from command-line and gui). I'd like to consult with you about powershell tricks which can be useful for bzr users
[22:16] <awilkins> bialix: My use on Windows is entirely Powershell + qbzr ; I don't use the overarching GUIs like Olive and bzr-explorer
[22:16] <bialix> awilkins: it's ok, I just need couple of advices who the best configure powershell for bzr needs
[22:16] <bialix> s/who/how/
[22:19] <jam> lifeless: :(, on mingw32 with %ld, I get: 271: warning: long int format, Py_ssize_t arg (arg 3)
[22:20] <jam> oh, also with python2.5
[22:20] <lifeless> And this is why C sucks
[22:20] <lifeless> does %zd work for you?
[22:21] <jam> lifeless: %zd is not understood by Visual Studio
[22:21] <jam> It doesn't complain
[22:21] <jam> but the test suite gives:
[22:21] <jam> "size": zd
[22:22] <jam> in the output
[22:22] <jam> lifeless: #define time, I guess
[22:22] <lifeless> #define SIZET_FORMAT "%l...
[22:22] <lifeless> yes
[22:23] <lifeless> so backto analysing the dump
[22:23] <jam> lifeless: so I would start with 'strip_duplicates.py'
[22:23] <jam> which uses a fairly lightweight Set object and doesn't store each row in memory
[22:23] <lifeless> there are two issues I know of
[22:24] <lifeless> these expensive references
[22:24] <lifeless> and cycle breaking
[22:24] <jam> it doesn't matter for analyzing with meliae, but it avoids using sort -u, etc
[22:24] <lifeless> have you heard of Tarjan's method?
[22:24] <jam> lifeless: not specifically
[22:25] <lifeless> http://en.wikipedia.org/wiki/Tarjan%27s_strongly_connected_components_algorithm
[22:26] <lifeless> I've implemented this in C++ for cygwin's setup.exe
[22:26] <lifeless> it is/was how it breaks dependency cycles for installs
[22:27] <jam> lifeless: seems somewhat similar to gdfo, only smallest distance from origin
[22:29] <lifeless> it finds cycles
[22:30] <lifeless> a strongly connected component is a subgraph where every element in the subgraph can reach every other element
[22:30] <awilkins> Heh, I think I wrote that for VB DLLs once
[22:30] <jam> lifeless: so the main reason for the remove-expensive-references is because if you hit a module, your cycle basically includes *everything*
[22:30] <lifeless> jam: so I was thinking about a few things we could do for very large memory dumps
[22:31] <lifeless> tarjan's method is a tool we may find useful
[22:31] <bialix> jam, sidnei: components layout is simply awful, sorry for my french
[22:31] <lifeless> one thing I was thinking was to shove the memory dump into a b+ tree; with long reference lists split into internal graph nodes
[22:31] <lifeless> this would allow logn lookups to do graph processing on it
[22:32] <sidnei> bialix: merci beaucoup
[22:32] <bialix> oops
[22:32] <jam> lifeless: performance might be a bit poor given the sorted requirement, shear number of keys, and probably lack of locality
[22:32] <jam> but it certainly seems like a way to handle the memory issues
[22:33] <bialix> sidnei: but really, all eggs are put into the same basket
[22:33] <bialix> heh
[22:33] <bialix> never mind
[22:33] <sidnei> literally yeah
[22:33] <lifeless> jam: actually locality should be pretty good
[22:33] <lifeless> jam: I'm going to give it a spin anyhow
[22:34] <jam> lifeless: I suppose it depends on the locality of the malloc, right?
[22:34] <lifeless> right
[22:34] <lifeless> what arena its in basically
[22:34] <lifeless> things allocated in a tight loop of the same type will be 'close'
[22:34] <jam> lifeless: anyway, tests right now are passing on py2.5 using mingw and py2.6 using VC on Windows
[22:34] <bialix> it's not my call now to maintain this mess, so who am I to point on such things
[22:34] <lifeless> even if they use several subtypes, we should see a cluster of related regions
[22:35] <sidnei> bialix: i'd be happy to change it if you got a better proposal
[22:36] <bialix> I'd like to see buildout helper dirs, source components dirs and release dirs separated by dedicated subdirectories
[22:36]  * bialix wonder how jam handle all this
[22:36] <sidnei> bialix: care to draw some ascii art for me?
[22:37] <sidnei> like pwd/<buildout-stuff>, pwd/source, pwd/release?
[22:37] <bialix> yep
[22:37] <lifeless> jam: cool, let me know when you've pushed ;)
[22:37] <jam> lifeless: pushed rev 71
[22:37] <jam> hold on a sec
[22:38] <jam> it was pushing to a personal branch rather than the official trunk
[22:38] <jam> pushed now
[22:39] <lifeless> jam: have you merged my branch?
[22:39] <jam> lifeless: I'm happy to make you a dev if you want
[22:39] <jam> I didn't know you published a branche
[22:40] <lifeless> 07:13 < lifeless> lp:~lifeless/meliae/64-bit
[22:40] <jam> lifeless: doing it now
[22:40] <lifeless> jam: thanks
[22:42] <jam> lifeless: so after merging, I still get: 271: warning: long int format, Py_ssize_t arg (arg 3) with gcc, but at least the tests pass
[22:43] <jam> lifeless: test suite still passes, though the warnings suck
[22:43] <lifeless> jam: I get no warnings.
[22:43] <lifeless> jam: I suspect you just need to use the #ifdef in some spots you missed
[22:43] <lifeless> jam: bzr diff should show you those
[22:43] <GaryvdM> Please can someone copy qbzr 0.14.1 in the bzr ppa. https://edge.launchpad.net/~qbzr-dev/+archive/ppa/+copy-packages
[22:44] <lifeless> GaryvdM: drop a mail to the list cc john ferlito
[22:45] <jam> lifeless: is this your last commit:
[22:45] <jam> 66 Robert Collins    2009-09-11
[22:45] <jam>    64 bit port.
[22:45] <jam> well only commit :)
[22:45] <bialix> something wrong with buildout. No module named subvertpy
[22:45] <jam> I don't have a #define for %ld vs %d etc
[22:46] <lifeless> jam: oh, thought you did
[22:46] <lifeless> so %zd is the right thing to use
[22:46] <lifeless> but visual studio will fail
[22:46] <jam> lifeless: except it isn't a C standard...
[22:46] <lifeless> jam: I know :P
[22:47] <lifeless> so we need a #define for it
[22:47] <jam> what is zd?
[22:47] <lifeless>        z      A following integer conversion corresponds to a size_t or ssize_t argument.
[22:47] <lifeless> (man 3 printf)
[22:47] <lifeless> zd == ssizet
[22:47] <lifeless> zu == sizet
[22:48] <bialix> jam: are you using some special additionasl settings on kerguelen for building installer? buildout from Ian's branch can't find subvertpy, while it actually downloaded
[22:48] <jam> lifeless: not in my 'man 3 printf' but I'll trust you :)
[22:49] <jam> The PRIuPTR macro (from <inttypes.h>) ...
[22:49] <jam> http://stackoverflow.com/questions/174612/cross-platform-format-string-for-variables-of-type-sizet
[22:49] <bialix> sidnei: for building bzr.exe build-installer.bat should add location of subvertpy to PYTHONPATH
[22:49] <bialix> sidnei: it seems don't
[22:50] <bialix> sidnei: is it intended?
[22:50] <sidnei> bialix: likely not, but jam should know better
[22:51] <bialix> jam: have a minute?
[22:51] <bialix> sidnei: I smell bug, but I'm not sure
[22:52] <lifeless> jam: uhm, thinking.
[22:54] <jam> lifeless: so it seems using "#ifdef __GNU__; #define FMT "%zd"" doesn't work here
[22:54] <bialix> sidnei: oh, my bad
[22:54] <jam> it gives "zd" in the output.
[22:54] <jam> Probably the formatting is done in the windows library
[22:54] <jam> arg
[22:54] <lifeless> jam: what gcc version do you have?
[22:54] <bialix> sidnei: Ian has disabled it in his branch
[22:54] <jam> lifeless: 3.4.4 (cygming special
[22:54] <lifeless> god thats old
[22:55] <jam> lifeless: newest version in cygwin
[22:55] <jam> there is a 4.x version but not for mingw
[22:55]  * awilkins is using the 4,1.x mingw one
[22:56]  * awilkins starts his bzr-build vm
[22:56] <lifeless> jam: cygwin's mingw packages are often old
[22:57] <lifeless> jam: #ifdef __linux__
[22:57] <lifeless> jam: will keep me happy
[22:58] <GaryvdM> bialix: what version of PyQt should I have for the windows installer?
[22:59] <bialix> 4.4.3 for Python 2.
[22:59] <bialix> 2.5
[22:59] <jam> lifeless: well, it doesn't handle 64-bit windows but hey...
[22:59] <jam> (I can't use sizeof() because types are defined yet...)
[22:59] <lifeless> jam: 64 bit windows will be different
[22:59] <lifeless> jam: as its LLP64
[22:59] <bialix> incredible
[23:00] <bialix> buildout seems to build bzr-svn successfully for me
[23:00] <lifeless> jam: I could be wrong; still, wait for the bug reports :P
[23:00] <jam> lifeless: so I don't have a good answer for *windows* yet
[23:00] <jam> because I can't just use %ld
[23:00] <jam> I can set it to use %zd for you
[23:00] <jam> without much problem
[23:00] <jam> #ifdef _WIN32 #else
[23:00] <bialix> sidnei: I've reached the point when I have to say you: you rock
[23:00] <sidnei> bialix: what did i do *wink*
[23:01] <bialix> sidnei: [01:00]	<bialix>	incredible
[23:01] <bialix> [01:00]	<bialix>	buildout seems to build bzr-svn successfully for me
[23:01] <lifeless> jam: so regarding the PRIuMAX approach;
[23:01] <lifeless> jam: http://www.embedded.com/columns/technicalinsights/204700432
[23:01] <sidnei> bialix: \o/!!!
[23:02] <lifeless> jam: thats the referenced article, and in it he suggests (at the end) just doing a specfic typedef
[23:02] <lifeless> jam: which is what I favour too
[23:02] <bialix> \o/ indeed
[23:02] <bialix> sidnei: jam: thanks, and sorry
[23:03] <bialix> lifeless: at which time igc usually wake up?
[23:03] <lifeless> another hour or two
[23:03] <jam> lifeless: I don't have a problem with that, but I still can't find the #ifdef combination that will activate on 32-bit windows versus 64-bit windows...
[23:03] <lifeless> he's one hour TZ behind me
[23:03] <jam> lifeless: igc went to bed pretty late, though
[23:04] <jam> he was up around 6 hours ago, IIRC
[23:04]  * bialix going for some coffee
[23:04] <lifeless> bialix: but I wake up early in my TZ :P
[23:04] <lifeless> jam: #ifdef _WIN64
[23:05] <bialix> it seems I have no good news for him
[23:05] <bialix> igc: when you wake up -- ping me
[23:05] <lifeless> jam: actually try just WIN64
=== bialix is now known as bialix-coffee
[23:06] <jam> lifeless: seems to work: http://paste.ubuntu.com/268811/
[23:07] <lifeless> jam: have you tried WIN64 ?
[23:07] <lifeless> http://mail.python.org/pipermail/patches/2000-May/000619.html
[23:07] <jam> lifeless: I don't have a win64 machine to test it on
[23:08] <jam> anyway, time for me to go
[23:08] <lifeless> ok
[23:08] <lifeless> _WIN64 is the one, I think. I find lots of refs to it
[23:08] <lifeless> night
[23:27] <igc> ping bialix
[23:27] <awilkins> His nick says he's having coffee
[23:28] <lifeless> jam: how important is using FILE* in the scanner?
[23:28] <igc> ping bialix-coffee
=== bialix-coffee is now known as bialix
[23:29] <bialix> igc: good morning
[23:29] <igc> bialix: morning
[23:29] <bialix> I hope you sleep well
[23:29] <igc> very
[23:29] <bialix> I have 2 news
[23:29] <bialix> bad and not so bad
[23:30] <bialix> igc: I think we should leave bzr setup.py as is for 2.0
[23:30] <bialix> and don't extract py2exe stuff right now
[23:30] <bialix> good news
[23:31] <bialix> after battling with buildout all night I've reached the point when bzr and all plugins compiled sucessfully, excerpt tbzr
[23:31] <bialix> because tbzr require msvc 2008 which I don't have
[23:32] <bialix> so basically last time inno setup installer compiler blow up on the point when there is no docs
[23:33] <bialix> igc: so my proposal is just add you chm docs to existing build, add bzr-explorer and ship 2.0
[23:33] <igc> bialix: sounds good to me
[23:33] <bialix> igc: and persuade jam to build another rc2 installer from your sources
[23:33] <bialix> bzr 2.0 is frozen, but your branch is good enough to tweak buildout stuff as needed
[23:34] <bialix> igc: I should say that despite my ignorance and my skepticism -- buildout is coolthing
[23:34] <igc> bialix: right, so 2.0 is frozen so we can't change what's in there
[23:34] <bialix> sidnei and jam are f** geniuses
[23:34] <igc> bialix: but there's plenty of room for tweaking the code in bzr-windows-installers, adding plugins, etc.
[23:35] <bialix> igc: I've got successful build of bzr-svn!!!
[23:35] <bialix> igc: right
[23:35] <igc> bialix: hooray!
[23:36] <igc> bialix: the dependency list for building the installer is crazy long still
[23:36] <igc> bialix: it will be good to gradually improve that - ditch cog as you suggested, etc.
[23:37] <bialix> you have igc: if you can get access to kerguelen then you can speed up the testing the whole thing I guess
[23:38] <bialix> s/you have//
[23:38] <igc> bialix: final builds will happen there
[23:38] <igc> bialix: I just want to enhance and debug it locally first
[23:38] <bialix> igc: I've battled with your build.bat until I've realized you commented out some stuff
[23:39] <bialix> igc: installing things like compiler and pyrex is not hard
[23:39] <igc> bialix: so can you push your changes?
[23:39] <bialix> but you can't build tbzr without msvc 2008
[23:40] <GaryvdM> bialix: Dose qbzr/installer/copy_libs.py get used for the bzr installer?
[23:40] <bialix> GaryvdM: lemme check
[23:40] <GaryvdM> bialix: and if so, can you fix Bug #427593
[23:40] <ubottu> Launchpad bug 427593 in qbzr "installer\copy_libs.py should copy PyQt4\plugins\imageformats" [Undecided,New] https://launchpad.net/bugs/427593
[23:41] <GaryvdM> ps the lag on my Irc is very bad, so Sorry If don't respond quick
[23:41] <bialix> GaryvdM: it's wrong bug
[23:42] <bialix> igc: I have not changed your code yet
[23:42] <bialix> igc: I've tweaked the things in the build-win32 dir
[23:43] <bialix> heh, Gary Gary
[23:43] <bialix> ScoobyDoo, where are you
[23:44] <bialix> igc: do you have msvc 2008?
[23:45] <igc> bialix: no, just mingw32 5.1.4
[23:45] <garyvdm> Hi bialix: Not sure if you got my prevs msg
[23:45] <bialix> garyvdm: no, copy_libs not used anymore
[23:45] <garyvdm> Hi igc
[23:45] <igc> garyvdm: is bug 427586 the one?
[23:45] <ubottu> Launchpad bug 427586 in qbzr "installer\copy_libs.py crashes if dir missing" [Undecided,New] https://launchpad.net/bugs/427586
[23:46] <bialix> garyvdm: last message I've got is: [01:42]	<GaryvdM>	ps the lag on my Irc is very bad, so Sorry If don't respond quick
[23:46] <bialix> garyvdm: I've said: the bug 427593 is wrong
[23:46] <ubottu> Launchpad bug 427593 in qbzr "installer\copy_libs.py should copy PyQt4\plugins\imageformats" [Undecided,New] https://launchpad.net/bugs/427593
[23:46] <garyvdm> bialix: Yes that was the last messages sent
[23:46] <igc> hi garyvdm
[23:46] <bialix> garyvdm: I fixed installer build stuff in trunk
[23:47] <bialix> not sure it was backported for 0.14.1
[23:47] <bialix> garyvdm: I can build installer myself
[23:47] <bialix> anyway I'm not sleeping yet
[23:47] <igc> garyvdm: thanks for the recent qbzr bug fixes - qbzr is looking pretty damn good now!
[23:47] <garyvdm> bialix: I ran installer from trunk
[23:47] <garyvdm> igc: thanks
[23:47] <bialix> garyvdm: then look at make_release.txt document
[23:48] <bialix> it explains how installer built
[23:48] <garyvdm> bialix: I also used the one from trunk.
[23:48] <bialix> http://bazaar.launchpad.net/~qbzr-dev/qbzr/trunk/annotate/head%3A/docs/make_release.txt
[23:48] <garyvdm> bialix: I have built the installer, I noticed that I does not have the image formats
[23:49] <bialix> garyvdm: that's right
[23:50] <bialix> garyvdm: oh!
[23:50] <bialix> garyvdm: you have installed pygments as eggs???
[23:50] <garyvdm> bialix: Why is bug 427593 wrong?
[23:50] <ubottu> Launchpad bug 427593 in qbzr "installer\copy_libs.py should copy PyQt4\plugins\imageformats" [Undecided,New] https://launchpad.net/bugs/427593
[23:51] <garyvdm> bialix: yes - with easy install
[23:51] <bialix> because imageformats should be installed not in _libs
[23:51] <bialix> but in C:\Program Files\Bazaar
[23:51] <bialix> along bzr.exe
[23:51] <bialix> garyvdm: then my copy_libs script did not copy pygments
[23:52] <bialix> because it can't deal with eggs
[23:52] <garyvdm> bialix: What if that install bzr from source, and qbzr from installer?
[23:52] <garyvdm> *they (a user)
[23:52] <bialix> our _libs required only for custom bzr.exe case
[23:52] <bialix> you can freely omit them
[23:53] <garyvdm> Bialix: I think it did copy the pygments egg - I'll double check.
[23:53] <bialix> actually our _libs are used only with bzr.exe. only
[23:54] <bialix> I can rebuild installer tomorrow if you wish
[23:55] <bialix> igc: so what is consensus about bzr.exe installer now?
[23:55] <bialix> igc: do you plan to extend buildout stuff with reciepes for bzr-explorer and chm docs?
[23:55] <igc> bialix: yes I do
[23:55] <bialix> if so then I can test it in morning
[23:56] <bialix> and ensure everything excerpt tbzr are build and packaged correctly
[23:56] <igc> bialix: great. I'll add the recipes for the new plugins and docs then
[23:56] <igc> bialix: we can leave tbzr out initially IMO - it's going to be off by default anyhow
[23:56] <bialix> igc: *my* morning will be after 8 hours
[23:56] <igc> sure
[23:57] <bialix> oh
[23:57] <igc> bialix: my immediate focus this morning will be getting explorer 0.8 out
[23:57] <bialix> and we should make it actually off by default in installer
[23:57] <bialix> does it mentioned in todo?
[23:57] <garyvdm> bialix: I think that my installer is ok. I'
[23:57] <igc> it should if it doesn't already
[23:57] <garyvdm> bailix: I'm going to upload it.
[23:57] <bialix> igc: re explorer: I need update tramslations
[23:58] <bialix> garyvdm: ok
[23:58] <jam> lifeless: I would be plenty open to using a callback, etc. I used FILE as a way to have very minimal memory overhead so that you can dump 6GB of data without going OOM.
[23:58] <igc> bialix: let's do that next week
[23:58] <igc> I'll call for translations to be enhanced after my changes land
[23:59] <jam> btw, I have an rc2 built from current sources
[23:59] <jam> but still waiting on bzr-svn 1.0, etc.
[23:59] <jam> so I'm not releasing it yet
[23:59] <igc> i.e. I expect/hope translations to improve between rc2 and 2.0