[00:14] <jam> hi poolie
[00:14] <jam> turns out the EINTR bug was very shallow
[00:15] <poolie> hi jam, i saw your mail, and i'm happy to hear that
[00:15] <poolie> did you talk to aaron at all?
[00:17] <jelmer> maxb: merged, thanks.
[00:17] <jam> poolie: I haven't yet. For some reason I got hives last night, and couldn't sleep for the itchiness, so I ended up starting a bit late
[00:18] <jam> I think it was an allergic reaction to something, but I have no idea what
[00:18] <jam> I didn't eat anything different, etc
[00:19] <jam> I did write up most of the decisions I've taken
[00:19] <jam> so I'm pretty close to getting feedback time
[00:20] <mgz> poolie: have you seen <http://babune.ladeuil.net:24842/job/selftest-freebsd/183/> ?
[00:21] <mgz> it may well not be anything to do with your change,
[00:22] <mgz> I've seen that sort of failure on a bunch of different cases when poking things
[00:23] <mgz> right, bed for me.
[00:59] <eydaimon> If I do bzr revert -r -11  is there some easy way to get what revno I've reverted to? I tried bzr revno --tree but didn't work
[01:01] <fullermd> No, revert doesn't change the revno of anything, it just edits files.  It's not really any different from `bzr diff -r-11 | patch -R`.
[01:03] <poolie> jam that's great
[01:04] <poolie> mgz no i hadn't, thanks for pointing it out
[01:07] <poolie> mgz, that's interesting it didn't fail on ubuntu
[01:07] <poolie> the scope replacer thing ought to be platform-independent
[01:12] <jam> poolie: would it be a python 2.7 thing?
[01:12] <poolie> maybe
[01:13] <jam> I believe mgz is known for random python versions :)
[01:30] <poolie> hi spivvo
[01:36] <spiv> Hi poolie
[01:37] <poolie> hey there, how are you?
[01:53] <spiv> Pretty good.  Mary's got a new laptop, new enough to be giving her mild grief with video driver issues :/
[01:53] <poolie> oh, what kidn?
[01:54] <spiv> A 13" Dell Vostro
[02:05] <poolie> spiv, actually, would you mind investigating the scopereplacer?
[02:05] <poolie> it may have been my landing that broke it but i don't think it's especially related to anything i know
[02:05] <poolie> http://babune.ladeuil.net:24842/job/selftest-freebsd/183/testReport/junit/bzrlib.tests.blackbox.test_branch/TestBranchStacked/test_branch_stacked_from_smart_server/
[02:11] <poolie> actually nm
[02:13] <spiv> Heh.
[02:13] <poolie> >> Greetings To You,
[02:13] <poolie> On behalf of the OBAMA'S FOUNDATION and UNITED NATIONS,
[02:13] <poolie> we wish to notify you as a beneficiary of $900,000.00 USD in compensation of
[02:13] <poolie> scam victims.
[02:13] <poolie> mm i bet
[02:15] <lifeless> rotfl
[02:37] <mtaylor> hey all - I know fuckall about fedora - is there a "more sensible" way to get recent bzr on fedora12?
[02:37] <lifeless> 'debtakeover'
[02:38] <mtaylor> hehe
[02:38] <lifeless> there's a fedora maintainer
[02:38] <lifeless> why do you ask?
[02:38] <mtaylor> lifeless: and if I remember correctly, this is a known bug that's fixed in 2.2, right: http://hudson.drizzle.org/view/Drizzle-build/job/drizzle-build-drizzleslap/593/console?
[02:38] <mtaylor> lifeless: well, because I've got a fedora box with 2.0.5 on it, and I believe I'm suffering from a bug fixed by upgrading...
[02:38] <lifeless> mtaylor: that looks like a fs fail to me
[02:39] <mtaylor> lifeless: there's 112G available on the box...
[02:39] <lifeless> what fs
[02:39] <mtaylor> ext4
[02:39] <lifeless> when did it last crash/power down unexpectedly
[02:40] <mtaylor> oh! recently apparently
[02:40] <mtaylor> poo
[02:40] <mtaylor> lifeless: so my solution here is kill repo and re-pull, yes? or can I just kill that file?
[02:40] <lifeless> uhm
[02:40]  * lifeless hands you over to a bzr person
[02:40] <lifeless> spiv: ^
[02:40] <mtaylor> lifeless: I think you qualifiy still as a bzr person even if that's not your job title ;)
[02:43] <lifeless> its more that
[02:43] <lifeless>  - the answer is complex
[02:44] <lifeless>  - you need to dig a bit to get the actual answer on a case by case basis
[02:44] <lifeless>  - we should make that more automated
[02:51] <spiv> Sorry, my net connection dropped out, so I missed the start of the conversation.  Which file is damaged?
[02:51] <spiv> (Then, apparently unrelated, my wireless router needed to be restarted too...)
[02:51] <lifeless> 13:38 < mtaylor> lifeless: and if I remember correctly, this is a known bug that's fixed in 2.2, right: http://hudson.drizzle.org/view/Drizzle-build/job/drizzle-build-drizzleslap/593/console?
[02:53] <spiv> mtaylor: just deleting the file won't help; bzr will still expect that file to exist.  Simplest fix is to delete and recreate that repo, yes.
[03:03] <glyph> so, I am running this command here
[03:03] <glyph> $ bzr dpush
[03:03] <glyph> Using saved location: svn+ssh://svn.twistedmatrix.com/svn/Twisted/branches/strports-endpoints-4473
[03:03] <glyph>   8817kB    38kB/s | pushing revisions:generating file id map 0/1
[03:03] <glyph> why have I dpushed almost 10M of data for a couple of tiny diffs?  (you can see them at twistedmatrix.com/trac/timeline, they are not big)
[03:06] <lifeless> the 10M includes local disk IO rewriting your history.
[03:36] <jbowtie> Is there an easy way to query for all the documentation bugs in Launchpad?  I can't remember how to do that.
[03:37] <poolie> jbowtie, all the bzr doc bugs, or all altogether?
[03:37] <poolie> the easiest way is to click 'doc' in the tag cloud
[03:38] <poolie> jbowtie: which will take you to https://bugs.edge.launchpad.net/bzr/+bugs?field.tag=doc
[03:38] <jbowtie> I meant the bzr doc bugs, those are the ones I want to work on.
[03:38] <poolie> that would be excellent
[03:38] <jbowtie> poolie: Thanks for that, will hopefully send through a bunch of patches the next few days.
[03:39] <jbowtie> poolie: Just remember that when I apply for Ubuntu Developer status.
[03:39] <jbowtie> :)
[03:41] <jbowtie> It's a shame that all the Canonical positions require you to be in the American or European timezones, I'd apply for job so I could work on Bazaar/Launchpad full time.
[03:44] <spiv> jbowtie: http://webapps.ubuntu.com/employment/canonical_BSE/ (in /topic) doesn't require those timezones AFAIK
[03:45] <wgrant> Lots of positions don't.
[03:46] <jbowtie> spiv: You're right, I hadn't seen that one!  Looks like I will be applying when I get home tonight.
[03:47] <jbowtie> wgrant: I suppose so, but every time I see one it has the timezone requirement attached.
[03:48] <poolie> jbowtie: definitely apply
[03:50] <jbowtie> poolie: Oh, I will. Though I suspect you just want to make sure I actually write those documentation patches.  :P
[03:50] <poolie> it will help :)
[03:50] <poolie> i'm reading cvs now as it happens but i don't expect the gate will close for another week or so
[04:03] <vila> poolie: just passing around, don't bang your head too much on the scopereplacer thing, I've seen it a few times, it has always been transient
[04:03] <poolie> oh, hi
[04:03] <poolie> how strange
[04:04] <vila> poolie: often triggered for smart server test so it may be related to some thread ordering differences in turn triggering different import ordering
[04:04] <vila> not worth the effort until it happens too often
[04:08] <poolie> :/
[04:08] <poolie> ok, thanks
[04:18] <vila> poolie: last occurrence was http://babune.ladeuil.net:24842/job/selftest-freebsd/98/testReport/junit/bzrlib.tests.blackbox.test_branch/TestBranchStacked/test_branch_stacked_from_smart_server/
[04:18] <vila> jun 14
[04:19] <vila> run #184 just succeeded, transient again
[04:19]  * vila back to bed
[04:53] <glyph> lifeless: I guess I can rebase first, then dpush?
[04:56] <glyph> Hmm.
[04:56] <glyph> Is there a way to construct bzr+ssh URLs to be $HOME-relative?
[04:56] <glyph> like, I can 'scp foo bar:' and it'll just drop 'foo' into my home directory on bar
[04:58] <spiv> glyph: yes
[04:58] <spiv> glyph: bzr+ssh://host/~/foo
[04:59] <spiv> (requires bzr 2.1 or newer on the server)
[05:01] <poolie> maybe we should just add $host:
[05:04] <spiv> And make trailing slashes significant? ;)
[05:09] <poolie> oh like rsync? :)
[05:11] <mwhudson> hnnnnnnnnngh
[05:11] <glyph> spiv: hey good idea!
[05:11] <glyph> whoops typo
[05:11] <glyph> what I meant was
[05:11] <glyph> "spiv: die in a fire"
[05:11] <mwhudson> the only way i ever get rsync command lines right is if they're in my shell history
[05:11] <glyph> Thanks a lot though!  I will be using "~" a lot now! :)
[05:11] <poolie> :)
[05:12] <glyph> mwhudson: how do you get the rsync command lines you typoed out of your shell history
[05:12] <mwhudson> glyph: it's a mystery
[05:12] <mwhudson> well, actually trial and error i guess
[05:14] <poolie> it is actually a bit logical
[05:14] <poolie> "a" means "the thing a", and "a/" is "everything inside a"
[05:15] <poolie> that's what ayn rand was talking about
[05:15] <poolie> 'a is a and a/ is not a'
[05:15] <mwhudson> haha
[05:17] <glyph> poolie: as a source it makes sense to me.  the problem is when you put it on the destination
[05:17] <glyph> 'sync a with remote:a' and 'sync everything in a with remote:a'
[05:17] <glyph> like... what does that mean?
[05:17] <poolie> it makes no difference to the destination
[05:17] <poolie> rsync a remote:b
[05:18] <poolie> and you will end up with remote:b/a/...
[05:18] <poolie> rsync a/ remote:b and you'll end up with remote:b/... containing what was in a
[05:18] <poolie> the fact that it looks like it might do something does make it confusing of course
[05:34] <lifeless> glyph: it will still do the same work
[05:34] <lifeless> glyph: the point is that the 8M doesn't represent 'network IO'
[05:35] <lifeless> it represents 'IO'
[05:37] <spiv> lifeless: I didn't think we included local IO in the transport activity reporting
[05:37] <spiv> lifeless: a quick grep suggests I'm right...
[05:37] <lifeless> I was moderately sure we did
[05:37] <lifeless> if we don't its arguably a bug (NFS etc)
[06:33] <poolie> we don't include localtransport io
[06:34] <poolie> i don't know what bzr-svn may be doing for its own io
[06:34] <poolie> lifeless: the reasoning is that for the common base case of branching from lp to localhost, it would naively double the data transferred and the rate
[06:34] <poolie> obviously you can account for stuff to make that even out but maybe yagni
[06:41] <glyph> https://bugs.launchpad.net/bzr-mac-installers/+bug/621446
[06:42] <glyph> Can somebody poke the responsible parties there?  the 2.2.0 mac installer on bazaar.canonical.com still has 1.0.4dev.
[06:43] <poolie> glyph: can you send a mail? i don't see them online atm
[06:44] <glyph> Send a mail to whom?  Do you mean put a comment on the bug?
[06:45] <poolie> hm, so i thought that 1.0.4dev would have this fixed
[06:45]  * poolie looks
[06:45] <poolie> but there is now a 1.0.4 final
[06:46] <glyph> Mmmm... it may have been due to the old buggy repository.  Let me try again.
[06:47] <glyph> Nope, reconfirmed outside of the shared repo.  Very, very definitely affects the 1.0.4dev in the current bzr mac installer.
[06:58] <glyph> poolie: thanks
[07:06] <poolie> and 1.0.4 works?
[07:06] <poolie> does 'bzr plugins -v' confirm you're using the plugin from the installer?
[07:30] <zaas[1]> i have a question about branches and git and it's differences, who could possibly help me?
[07:36] <fullermd> Probably a number of people, but only after you ask the question   :>
[07:39] <zaas[1]> ok :) I am trying to decide between Git and Bzr and i favor git a little bit because of it's branch support. However, i work with 2 windows developers and have avarage repositories < 30Mb of php & images
[07:39] <zaas[1]> i find bazaar far more clearly
[07:40] <zaas[1]> but i fear that local branching might be a breaking drawback
[07:40] <zaas[1]> am i right to think this or is this not something that will likely bother me? Git and bzr both seem to do their basics well
[07:41] <zaas[1]> but git evangelists love their index, cheap branching and the tree-eating monster
[07:41] <zaas[1]> and i am confused what to pick
[07:41] <zaas[1]> (not to much text i hope?) :)
[07:43] <fullermd> Well...   those are pretty broad points.  Hard to give a specific answer, since there's no real specific question...
[07:43] <fullermd> Certainly the branch representations are rather different, so they have different advantages and drawbacks.
[07:44] <fullermd> And one drawback of the bzr way is that some minor setup is required to share history among local branches, and rather more setup and ongoing care to share a single working tree among them git-style.
[07:44] <zaas[1]> ah, can you name a bazaar advantages? I know git's: 1 tree and easy push
[07:44] <fullermd> Contrarily, an advantage is that it's way easier and less hackish to have working trees of multiple branches at once with shared history.
[07:45] <fullermd> And it's also somewhat easier and more obvious to push only a particular branch around.
[07:45] <zaas[1]> in my case branches will normally be about bugfixes or small features that need to be merges later on
[07:46] <fullermd> Me, I find that multiple WT's on the different branches make a lot of things a lot easier.  It sounds like you're doing web stuff, and it's handy to be able to have a browser tab on one branch, and another on another branch, at the same time, rather than having to switch back and forth one at a time.
[07:47] <fullermd> I don't think there's always a clearcut winner on which method is better, even in some specific cases; certainly in general it's all over the place.
[07:48] <fullermd> I would lay good odds that bzr grows a native and robust variant of git-style before git grows a native and robust variant of bzr-style.
[07:48] <fullermd> Though AFAIK neither is right around the corner, so that's more of a longer-term thing.
[07:50] <zaas[1]> this is very true. bzr to git is much better then the other way around. also i am fearing the windows developers (2) will not like the git-hassle
[07:51] <zaas> oops
[07:51] <zaas> @fullermd but you love bzr over git i assume?
[07:52] <fullermd> Oh, yes.  That's why I'm here   :)
[07:52] <zaas> i guess for simple vcs is does not really matter and bzr seems the safer choice
[07:53] <zaas> why did you go for bzr?
[07:53] <fullermd> Oh, mostly for dumb and superficial reasons.  But I stayed because I found better reasons.
[07:54] <fullermd> There are things git has that I wish bzr did (and that multiple-branches-in-one-tree thing is a big one).
[07:54] <fullermd> But, I think bzr can grow those capabilities without changing or compromising any of the advantages of the way it currently does things.
[07:54] <fullermd> And I don't think git can do the complement; it would be a much bigger change in their model of things to support side-by-side branches and WT's with shared history.
[07:56] <fullermd> I also particularly like bzr's exploitation of merge asymmetry.  I've seen git-using projects go to a lot of trouble to try and avoid situations that that makes a non-issue.
[07:56] <vila> hi all !
[07:56] <zaas> haha, my initial choice for git was it's hardcore status and the tree-eating monster on their homepage... but i find it hard to justify my choices now with bzr having API support and git does indeed seem to remain git
[07:57] <zaas> it was made for large speed-needing many devvers projects like linux
[07:58] <zaas> hi vila
[07:59] <fullermd> Sure, I expect there will always be performance/resource-usage advantages you can point at for git.  How much they matter in a relative or absolute sense, probably less clear.  And certainly for small projects, I don't think it matters what you pick at this point perf-wise.
[11:22] <bialix> ~~~
[11:28] <vila> bialix: hi ! You're on the beach looking at waves ~~~ ?
[11:29] <bialix> bonjour vila!
[11:29] <bialix> not on the beach unfortunately
[12:28] <poolie> hello vila, bialix
[12:28] <poolie> won't be here for long
[12:30] <vila> poolie: yeah, *you* are on your way to the beach ;)
[12:30] <vila> oh my, already 13:30, time for lunch
[14:23] <bialix> vila: ping
[14:23] <vila> bialix: pong
[14:23] <bialix> do you by any chance know what's the difference between wt format 5 and 6?
[14:24] <bialix> 1.14 format creates wt5 and 2a creates wt6
[14:26] <vila> bialix: let me check, in the meant time, why do you care ?
[14:26] <bialix> I have format1 plugin to avoid 2a as default; wanna update it to 1.14
[14:27] <vila> bialix: from the docstrings, wt6 supprot views
[14:27] <bialix> ah
[14:27] <bialix> ok, thank you
[14:27] <vila> wt5 support content filtering
[14:28] <bialix> ok
[14:28] <vila> bialix: by the way, you still need this plugin ? poolie didn't add a config option for it ?
[14:29] <bialix> I dunno. I have several machines with bzr 1.18 .. 2.1.2 on them, so I'd better safe than sorry
[14:29] <bialix> still can't upgrade to 2.2 because of problems with bzr.exe and bundled pyqt
[14:29] <bialix> waiting for 2.2.1
[14:30] <vila> right, so I'm supposed to release that tomorrow ;)
[14:30] <jml> I'm using workingtree.list_files to go through files in a checkout
[14:30] <bialix> vi-la! vi-la! vi-la!
[14:30] <jml> I'd like to inspect the contents of these files
[14:31] <jml> should I just use normal Python facilities to open the file or is there some more efficient bzr-like way?
[14:32] <bialix> there is method to get the content regardless of workingtree/revisiontree
[14:32] <bialix> also this method supposedly should normalize the file if content filters defined, I guess
[14:33] <vila> jml: there is get_file_text that you can use with the file_id IIRC + what bialix said
[14:34] <vila> jml: so it won't be especially more efficient, but easier for you to code I presume
[14:35] <james_w> using the bzr APIs makes it easier to support things like acting against the tip revision of a remote branch, if that would ever be useful to you
[14:38] <bialix> vila: as I understand you will pair with poolie on release tomorrow morning your time? I will hope to see that tomorrow, as fan
[14:41] <vila> bialix: yeah, that's the plan, I will now go prepare my branches and notes to be ready ;)
[14:41] <jml> thanks guys :)
[14:43] <mgz> I have a vision of vila bearing bundles of sticks.
[14:43] <mgz> And possibly marching on a castle.
[14:44] <vila> ...with a big black tower ?
[14:46] <bialix> ... while poolie sneaks with the ring?
[14:46] <mgz> ehhehe.
[14:46] <vila> my preciouuuus ! That's where it was !
[14:46] <bialix> :-D
[16:02] <knittl> am i understanding a testament correctly? it only signs the current tree (or of any given revision) but not its history?
[16:03] <mgz> I believe so, you can find more from jam I think on the mailing list.
[16:04] <jam> knittl: correct
[16:04] <knittl> ok, thanks
[16:06] <mgz> yup, under the topic "security", dated 2009-11-05
[16:06] <knittl> can you paste a link? :)
[16:06] <mgz> I'm using gmail search, google is a bit crap about indexing the https list archives
[16:06] <mgz> so.. one sec
[16:07] <mgz> https://lists.ubuntu.com/archives/bazaar/2009q4/064053.html
[16:07] <knittl> great, thanks a lot
[16:10] <GaryvdM> Hi all
[16:10] <mgz> hey gary.
[16:31] <bialix> Heya GaryvdM !
[16:31] <GaryvdM> Hi bialix
[16:31] <bialix> GaryvdM: have you asked jam about PyQt
[16:31] <bialix> ?
[16:31] <bialix> PyQt downgrade for 2.2.1
[16:31] <GaryvdM> No - Thanks for the reminder
[16:32] <mgz> also, for 2.2.1, should look at the manifest thing
[16:32] <mgz> probably just want to put the dll in a subfolder and add magic xml.
[16:33] <GaryvdM> jam: We would revert to an older version of pyqt. Please could you install it on the ec2 machine.
[16:33]  * GaryvdM goes to find the bug an download url.
[16:35] <mgz> I've got several old versions locally, which do you want?
[16:36] <bialix> GaryvdM: http://bialix.com/python/PyQt-Py2.6-gpl-4.5.2-1.exe + http://bialix.com/python/PyQt-Py2.6-gpl-4.5.2-1.exe.asc
[16:36] <bialix> mgz: right, manifest
[16:36] <GaryvdM> Ah - thats it :-)
[16:37] <bialix> I haven't tested it locally yet for simple application. should test tonight
[16:37] <GaryvdM> and bug 632501
[16:38] <mgz> http://www.no-ack.org/2010/09/complete-guide-to-py2exe-for-pygtk.html <- perhaps a little interesting
[16:38] <bialix> btw, Gary, I'm a bit worried about this one: https://bugs.launchpad.net/bugs/640082
[16:39] <GaryvdM> bialix: Are you able to reproduce that. I wonder if bzrw.exe is causing that?
[16:40] <mgz> that sounds like a good theory gary.
[16:40] <bialix> Gary, no, I did not try
[16:40] <bialix> why?
[16:40] <bialix> mgz, GaryvdM : ^
[16:40] <mgz> the standard streams don't point anywhere with WinMain rather than main
[16:41] <bialix> it seems like the bug from Gordon is not involved bzrw.exe
[16:42] <bialix> mgz: I'm sure we should invoke the subprocesses as bzr.exe
[16:42]  * bialix is checking
[16:42] <mgz> yeah, could be something else.
[16:43] <bialix> mgz: yep, we're forcing bzr.exe even if initial GUI invoked with bzrw.exe
[16:44] <bialix> I did it long ago when I first time started to play with bzrw.exe idea
[16:47] <GaryvdM> bialix: I just tested. The bug happens with bzrw qpull, but not bzr qpull
[16:47] <bialix> bam
[16:47] <bialix> bad
[16:47] <GaryvdM> I have an idea to fix this.
[16:48] <bialix> yes?
[16:48] <GaryvdM> Let me try do a installer build without tbzr (thats where I got stuck...)
[16:49] <bialix> this is just silly: http://lists.sourcegear.com/pipermail/veracity-users/2010-September/000033.html
[16:49] <GaryvdM> Rather than blackhole the std(out/err), just leave them
[16:50] <bialix> GaryvdM: I don't follow
[16:51] <Glenjamin> bialix: what's veracity?
[16:51] <bialix> Glenjamin: new DVCS
[16:51] <Glenjamin> ah yes, thats what the world needs.
[16:51] <bialix> is it sarcasm?
[16:52] <Glenjamin> yes
[16:52] <Glenjamin> also their google-fu sucks
[16:52] <bialix> ok
[16:53] <mgz> didn't they have a non-d vcs already?
[16:53] <bialix> my point not about veracity, but about claim that fast 'hg verify' is what user want to run often
[16:53] <mgz> and yeah, that post is silly, but says something about the different projects
[16:53] <bialix> mgz: yes, replacement for some silly vcs by m$
[16:53] <GaryvdM> mgz: Yes - it was called Vault. I used it for a while
[16:53] <Glenjamin> i think it was more that the poster cares about the results, and if his users wont ever run it then that VCS is ruled out as an option
[16:55]  * bialix is trying to read the article mgz gave about py2exe, black page background kills his eyes
[16:55] <MTecknology> Any idea what's up with this?  Unable to copy ownership from '/home/S6B5B28EB.s' to '/home/S6B5B28EB.s/.bazaar': IOError: [Errno 1] Operation not permitted: '/home/S6B5B28EB.s/.bazaar'.
[16:55] <mgz> turn off author style then bialix :)
[16:56] <bialix> mgz: how
[16:56] <GaryvdM> bialix: In Firefox: View > Page Style > No Style
[16:56] <mgz> ...depends on your browser?
[16:56] <MTecknology> hrm.. I just clobbered permissions and it's working now ;)
[16:56] <bialix> mgz: chrome
[16:57] <bialix> copy-pasting to OOo may help...
[16:58] <mgz> er... chrome doesn't seem to make it easy.
[16:58] <mgz> bialix, the last section talks a bit about manifests, doesn't sound completely correct to me, but might be a starting point.
[16:58] <bialix> ack
[16:59] <GaryvdM> Hmm veracity is free (Apache License).
[17:01] <bialix> mgz: IIRC manifest should be in the same directory as exe
[17:01] <bialix> crazy
[17:03] <mgz> it's changed at least twice since the last time I needed to actually ship any compiled code, so I really have no idea
[17:12] <Glenjamin> So there's only two things veracity does that current tools dont it seems, cross platform C and repo user accounts
[17:13] <bialix> ,gz: http://py2exe.org/index.cgi/Tutorial section 5.2.1
[17:13] <bialix> mgz: http://py2exe.org/index.cgi/Tutorial section 5.2.1
[17:13] <maxb> Python is written in cross platform C.... :-)
[17:13] <Glenjamin> their words: "We love Python too, but C is a lowest common denominator that can be ported or integrated everywhere we need to go."
[17:14] <bialix> mgz: or we should add to installer redistributable installer
[17:14] <Glenjamin> i don't quite see how that doesn't apply to python - the only actual argument is speed i'd have thought. but meh
[17:14] <mgz> no, we want the bundled + manifest way
[17:14] <Glenjamin> does bzr use pyrex/pysco at all?
[17:17] <jam> Glenjamin: we do use pyrex, we don't use psyco
[17:18] <bialix> mgz: then we have to make sure ec2 build host has proprely licensed msvc 2008?
[17:18] <bialix> and then copy required dll as part of py2exe run, oh my...
[17:18] <mgz> I think it did? jam at least had full versions of the compilers I think.
[17:19] <jam> ec2 has the full versions of the compilers
[17:19] <bialix> jam: can I have access to ec2 when GaryvdM will build an installer?
[17:19] <Glenjamin> i'd imagine throwing pscyo at long running operations might speed them up a bit
[17:20] <bialix> at least read-only?
[17:20] <jam> bialix: fine with me, I'll need your ip address
[17:20] <jam> Glenjamin: we rarely have a long running bzr process
[17:20] <jam> at least from the command line point of view
[17:21] <jam> and IIRC, psyco doesn't save state between runs
[17:21] <bialix> jam: my ip address... I don;t have dedicated one
[17:21] <Glenjamin> bzr check springs to mind
[17:21] <bialix> it depends on the i-net provider
[17:22] <jam> bialix: I could potentially use a range, but I can always just set the one you have right now
[17:22] <jam> I'll also need a username/pass for you, but I can generate that
[17:23] <bialix> I see
[17:23] <bialix> I need to get in sync with Gary
[17:25] <bialix> bye for today
[17:34] <Glenjamin> can anyone suggest a good letter to abbreviate the --no-backup option to revert?
[17:37] <mgz> Ω
[17:48] <Glenjamin> UnicodeEncodeError: 'ascii' codec can't encode character u'\u03a9' in position 17: ordinal not in range(128)
[17:48] <Glenjamin> :(
[17:49] <Glenjamin> optparse wigs out on unicode it seems
[17:53] <GaryvdM> Hi roryy. I see you are from South Africa. Where are you base?
[17:53] <GaryvdM> I'm in Randburg.
[17:53] <roryy> hi GaryvdM.  In Centurion
[17:53] <GaryvdM> Oh cool.
[17:53] <roryy> not too far :)
[17:54] <mgz> roryy is the one who fixed two bugs in bzr the other day without changing any code at all
[17:54] <roryy> yers.  look out for my new book, "zen coding"
[17:54] <GaryvdM> roryy: Are you coming to sfd?
[17:55] <roryy> i don't know what sfd is
[17:55] <GaryvdM> Software Freedom day  - I'll find a link with the details .
[17:56] <roryy> ah-ha
[17:57] <roryy> google suggests softwarefreedomday.org
[17:57] <GaryvdM> http://wiki.softwarefreedomday.org/2010/Africa/South%20Africa/Pretoria
[17:59] <roryy> hrm, this w/e
[17:59] <GaryvdM> Yes
[18:01] <roryy> ah - you're doing a python talk
[18:01] <roryy> you work at csir?
[18:02] <GaryvdM> No - I work for lsd.co.za
[18:03] <roryy> an ex-colleague now at csir thinks numpy is awesome
[19:04] <knittl> hm. it says in the source code of testament.py 'indented-text form similar to log; human readable'
[19:04] <knittl> what text?
[20:05] <vila> ping LOSA
[20:06] <mbarnett> hello vila
[20:07] <vila> mbarnett: 2.3b1 will be released tomorrow, sorry for the late query :-(
[20:07] <vila> mbarnett: I need a pqm branch and the corresponding instance
[20:07] <vila> mvo: I just filed a RT ticket for it
[20:07] <vila> mvo: sry, bad Xchat :-/
[20:08] <vila> mbarnett: I just filed a RT ticket for it
[20:08] <mbarnett> what is the RT #?
[20:08]  * vila checks mail
[20:09] <vila> mbarnett: #41434
[20:14] <mbarnett> vila: hmm, this is a non trivial change and I am neck deep in another problem.  Let me see if I another losa might have time to work on this.
[20:15] <mthaddon> vila: what time tomorrow will it be released?
[20:16] <vila> mthaddon: hopefully before 16:00 UTC
[20:16] <mthaddon> vila: ok, in that case I can do it tomorrow before then
[20:16] <mbarnett> yay!
[20:16] <vila> mthaddon: great ! ping me if you need more info
[20:17] <vila> mbarnett: thanks for the chase !
[20:17] <mbarnett> np
[20:17] <vila> mthaddon: one thing I failed to mention is: which branch should you start with
[20:17] <mthaddon> vila: ok, please add that to the RT
[20:18] <vila> mthaddon: I have a question first: can you push this branch later (once) so we start with the "right" revision ?
[20:19] <mthaddon> vila: I'm not sure I understand the question - can you frame it another way for me?
[20:19] <vila> mthaddon:
[20:20] <vila> mthaddon: AIUI, you need to install a pqm instance (handwaving, I've no idea what it requires) including a branch of bzr itself, *and* push this branch to lp
[20:20] <vila> mthaddon: from there we send requests to the pqm instances to merge new revisions
[20:21] <mthaddon> vila: let's back up a bit - I was asking about what you mean by "can you push this branch later (once) so we start with the "right" revision" - I understand how to setup a new branch in PQM
[20:21] <vila> mthaddon: my question is: can you run a 'bzr pull --overwrite' and a 'bzr push lp:2.3' on this branch ?
[20:22] <mthaddon> vila: this is a new branch, so what am I pull --overwriting?
[20:22] <vila> mthaddon: a new branch, yes, but with a content
[20:22] <mthaddon> vila: I'm not sure what  that means...
[20:22] <vila> mthaddon: What I want to avoid is to have to revert some revisions or add fake merges
[20:23] <vila> mthaddon: what will be the revno of lp:bzr/2.3 once you create it ?
[20:23] <mthaddon> vila: so which branch and revision number do you want lp:~bzr-pqm/bzr/2.3 created from
[20:24] <vila> mthaddon: I don't know yet, maybe the current bzr.dev tip, maybe before, maybe after
[20:25] <mthaddon> vila: well I can't really do anything until you tell me that
[20:25] <vila> mthaddon: if you can modify the branch *before* we start using it, the precise revno doesn't matter that much and I can tell you later to modify it
[20:26] <vila> mthaddon: you can duplicate the bzr.dev instance to start with
[20:26] <mthaddon> but I have to create the branch somehow...
[20:26] <mthaddon> ok
[20:27] <vila> mthaddon: that's why I want to know if we can modify it ! So I can tell you either: start with bzr.dev@5430 *or* start with bzr.dev@5420 and we'll fix it later
[20:28] <mthaddon> vila: you can always modify it - it's just a bzr branch
[20:28] <vila> mthaddon: *I* don't have access to this branch :-)
[20:28] <mthaddon> vila: ok, when I say "you" I mean "someone"
[20:29] <mthaddon> i.e. a losa
[20:29] <vila> mthaddon: ok, we are in violent agreement then, I'll update the ticket
[20:36] <lifeless> vila: whats up?
[20:37] <roryy> is there any reason that "aptitude install python-testtools" doesn't give me the package from the bzr PPA?  The package doesn't seem to be listed in http://ppa.launchpad.net/bzr/ppa/ubuntu/dists/karmic/main/binary-i386/Packages (don't know if it should be?)
[20:37] <vila> lifeless: receiving support from losa to create the 2.3 pqm instance :)
[20:37] <lifeless> vila: what do you mean 'instnace'
[20:38] <lifeless> vila: do you mean 'please make a new branch for 2.3' ?
[20:38] <mthaddon> lifeless: he means a PQM managed bzr branch for the 2.3 series
[20:38] <vila> lifeless: whatever setup needed to get a lp:bzr/2.3 branch
[20:38] <lifeless> vila: not an instance, new branch, documented in losa procedures.
[20:38] <lifeless> mthaddon: I was scared for a second :)
[20:38] <mthaddon> heh
[20:38] <vila> lifeless: oh thanks, let me read that, oh wait :)
[20:38] <lifeless> mthaddon: its just branch, push & update the config.
[20:39] <lifeless> vila: you can I believe.
[20:39] <lifeless> IMBW
[20:39] <mthaddon> lifeless: yep
[20:39] <lifeless> mthaddon: great, you may resume sucking eggs at any time ;)
[20:39] <vila> mthaddon, lifeless : sorry guys, RM noob here ;)
[20:39] <mthaddon> :)
[20:41] <mthaddon> vila: have set it up branched off lp:bzr
[20:41] <vila> mthaddon: wow, you rock :)
[20:42] <vila> mthaddon: excellent, I see it on lp
[20:43] <vila> mthaddon: some people than bzr.dev can send their requests there right ? Or should I read those procedures before asking yet another silly question but in that case where ? :)
[20:43] <vila> s/some/same/ of course, the typo
[20:44] <mthaddon> vila: yep, set up with the same group as all other PQM-managed bzr branches
[20:45] <mthaddon> vila: well, it's the bazaar_releasemgr vs. the bzr group: https://pastebin.canonical.com/37310/
[20:45] <vila> mthaddon: great !
[21:54] <GaryvdM> jam: I'm struggling with a problem trying to build the win32 installer on my own host. I seem to remember getting the same error on the ec2 host, and you helped me fix it, but I can't remember how.
[21:54] <GaryvdM> Here is the error: http://pastebin.ubuntu.com/494940z
[21:55] <GaryvdM> sorry: should be http://pastebin.ubuntu.com/494940/
[21:56] <GaryvdM> That file is located here: (sorry - copy paste broken, but I know were the file is on the disk)
[21:57] <jam> GaryvdM: I don't remember fixing that off-hand
[21:57] <jam> did we document it?
[21:57] <jam> we *do* want to bundle that file, right?
[21:57] <jam> we may need to adjust PATH to include it?
[21:58] <GaryvdM> jam: I believe so, let me check if it was in the prev installers
[22:00] <GaryvdM> jam: In the 2.2.0 installer, we have MSVCR90.dll (apposed to MSVCP90.dll
[22:06] <jam> GaryvdM: from what I can tell, MSVCP90.dll is the C++ runtime, which I didn't think we use anywhere
[22:06] <jam> ah, maybe qt needs it?
[22:07] <GaryvdM> jam: Yes - if I py2exe without qbzr, it works - so I think it is a qt dependency.
[22:08] <GaryvdM> I'm going to try copy it to C:\Python26\DLLs
[22:08] <jam> GaryvdM: I would say look for wherever MSVCR90.dll is found
[22:08] <jam> you may also need stuff like MSVCPRT.dll, etc.
[22:08] <NightDog> Hi. From what I can read from bug 109114 bzr kind of has some problems with big(ish) binary files. Is there any way to increase some parameters to keep it from crashing due to out of memory? I got 16Gig RAM on this maching. Ubuntu 10.04, bzr version 2.2.0. Thanks
[22:09] <mgz> I don't see it linked in the process when I run a qbzr command with 2.2 though
[22:09] <mgz> isn't our qt built using mingw?
[22:09] <GaryvdM> Ah - that worked.
[22:10] <GaryvdM> I don't think it gets copied into the installer, just py2exe wants to see it.
[22:11]  * GaryvdM trys a full install build.
[22:11] <vila> GaryvdM: I'm marginally more happy than if you said: "Ha - that failed", but not knowing what 'that' is I refrain myself :)
[22:11] <GaryvdM> vila: that = "I'm going to try copy it to C:\Python26\DLLs"
[22:12]  * GaryvdM puts that in the build host doc
[22:12] <vila> Oh, I missed that one :)
[22:12] <mgz> can you try blacklisting them? I really think you only need the c runtime.
[22:13] <vila> I'm off, tomorrow is release day and I'll start early, good nitght all
[22:13] <mgz> night vila.
[22:13] <GaryvdM> mgz: I don't think it ends up in the installer, but I'm going to dbl check..
[22:13] <GaryvdM> night vila.
[22:19] <GaryvdM> mgz: Do you know what bialix wanted to do re the manifest file?
[22:19] <mgz> yeah, see: http://py2exe.org/index.cgi/Tutorial#Step52
[22:25] <jam> mgz: only 52 steps in? not bad :)
[22:25] <jam> wait
[22:29] <zsquareplusc> i'm going to ask something silly ;-) is it possible to clean up the history, e.g. would it be possible to say it should throw away all logs before a date?
[22:29] <zsquareplusc> i know i can do it with fast export/import at the expense of loosing the ability to compare the old and new tree. but some easier to use frontend/plugin in bzr itself would be practical.
[22:29] <zsquareplusc> maybe something like a "rebase" that merges all changes before a date to create a new base version.
[22:29] <zsquareplusc> i'm aware that such operations do not work well when different versions of the branch are published.
[22:30] <GaryvdM> mgz: We are excluding MSVCP90.dll in setup.py
[22:30] <GaryvdM> http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/annotate/head%3A/setup.py#L691
[22:31] <GaryvdM> But py2exe needs to be able to find it else it errors :-(