[00:23]  * mattman_ is away: 
[00:37] <poolie> mkanat: mwh says if you request access to ~loggerhead-team he will approve it
[00:37] <mkanat> poolie: Okay, will do.
[00:37] <mkanat> Done.
[00:49] <poolie> hi spiv?
[00:52] <mkanat> jam: Thanks for the cvs2bzr recommendation. Worked like a charm.
[00:56] <spiv> Good morning :)
[01:46] <lifeless> spm: are you familiar with the new bazaar website deployment?
[01:47] <spm> lifeless: as in for http://bazaar.canonical.com/ ?
[01:47] <lifeless> yes
[01:48] <spm> heh, no. not familiar with.
[01:48] <lifeless> poolie has asked me to look at why an rss feed cron job in it isn't.
[01:48] <lifeless> and crontab -e as bzr-website on the machine -> empty file
[01:51] <spm> is that the way rss feeds are generated for the site? as in some I've worked with previously (geeklog springs to mind) encode the generation of rss in every home page request (I deliberately disabled THAT gem).
[01:51] <lifeless> :>
[01:51] <lifeless> yeah
[01:52] <lifeless> so I think I have it sorted - thanks
[01:55] <lifeless> ftr, its running from poolies crontab
[01:57] <poolie> thanks for all the reviews jam
[01:57] <poolie> i should migrate them...
[01:58] <spm> lifeless: coolio. possibly we should have a 'bzr' account to run those sorts of things, but that works.
[01:59] <poolie> there is a bzr-web
[01:59] <poolie> (or something like that) role account
[01:59] <poolie> i should migrate the cron jobs to run in that
[02:00] <spm> that works
[02:00] <mtaylor> lifeless: is there a reason you have not merge in my pandora-build packaging updates? or have you just not gotten to it?
[02:10] <lifeless> mtaylor: time, yeah.
[02:12] <mtaylor> lifeless: ok. just wanted to make sure it wasn't blocking on me
[02:15] <lifeless> I don't think so.
[02:15] <lifeless> Was moving country etc.
[02:15] <lifeless> the hits keep on coming ;>
[02:31] <mtaylor> lifeless: you were moving country?
[02:32] <mtaylor> lifeless: where do you live now?
[02:32] <lifeless> NZ
[02:32] <mtaylor> ah.
[02:33] <mtaylor> so you're even closer to my timezone now :)
[02:33] <lifeless> yes
[02:33] <mtaylor> woot
[02:33] <lifeless> except when I'm in .au (now), or europe (week after next)
[02:33] <mtaylor> well right
[02:33] <mtaylor> same goes for when I'm in other places - or when new zealand moves into the indian ocean
[03:03] <lifeless> http://www.paulhammond.org/2010/06/trunk/
[03:06]  * spiv hmms at a stacking test
[03:10] <poolie> spiv :)
[03:10] <poolie> so you're going to tackle those other bugs and then prod merge cleanups?
[03:11] <poolie> (if so that's fine with me)
[03:11] <spiv> poolie: yep, exactly
[03:19] <spiv> Can I get an incremental review of just http://bazaar.launchpad.net/~spiv/bzr/reconfigure-unstacked-551525/revision/5331 ?  I had some minor test fallout.
[03:22] <lifeless> +1
[03:23] <spiv> lifeless: thanks
[03:24] <lifeless> thanks for the direct link
[03:24] <lifeless> I wish that page didn't need a click to see the diff
[03:31] <lifeless> -> fud
[03:31] <parthm> i am trying to deprecate osutils.re_compile_checked. adding @deprecated_function(deprecated_in((2, 2, 0))) produces 'no attribute _format_version_tuple' http://pastebin.com/EeEiLfbx
[03:31] <parthm> should i be doing something differently?
[03:36] <spiv> parthm: argh, imports :/
[03:37] <spiv> parthm: the issue is that _format_version_tuple in bzrlib/__init__.py is defined after the import of bzrlib.lazy_regex
[03:37] <spiv> The fix is probably to move the definition _format_version_tuple above that import.
[03:38] <parthm> spiv: oh. ok. i can fix that and send it separately for merge if that works.
[03:38] <spiv> Or do the deprecation without using the decorator, I suppose.
[03:38] <spiv> (I don't have a strong opinion either way)
[03:41] <parthm> spiv: i will go ahead and am a separate patch for that. its a trivial change anyway. its nicer to use the decorator.
[03:57] <parthm> spiv: https://code.launchpad.net/~parthm/bzr/format_version_tuple_import_order/+merge/28953
[04:07] <spiv> parthm: reviewed, thanks
[04:12] <parthm> spiv: thanks. i fixed the comment. do you think its a small enough change to send to pqm or do we need another review?
[04:18] <spiv> parthm: Fine to send, I think.
[04:19] <parthm> cool. thanks. i will send it.
[04:33] <lifeless> parthm: hi
[04:34] <lifeless> parthm: I gave similar advice to john earlier in the review of your bad ignores branch
[04:34] <lifeless> parthm: Perhaps you missed it? I'd like to help you land that branch.
[04:40] <parthm> lifeless: hi. i might have missed it. what are you referring to?
[04:40] <lifeless> the layering - passing in info about where patterns came from etc
[04:42] <parthm> lifeless: ah. yes. thats probably a good way to go. i might have missed it earlier. the comments on the patches were really growing long :)
[04:43] <parthm> lifeless: i plan to look at that once the current patch (part-1) lands
[04:53] <spiv> Hmm, there are a few TODO comments in chk_map talking about improvements that weren't done because we didn't have a pure-python StaticTuple
[04:54] <spiv> There might be some cheap wins to be found there
[05:01] <lifeless> spiv: revision specs could use cleanups
[05:03] <spiv> lifeless: very much, yes
[05:04] <spiv> lifeless: the trick is doing it without disrupting 3rd party implementations & callers too much, I think
[05:04] <spiv> But right now, lunch!
[05:06] <lifeless> spiv: yes; I made the comment when working on loom.
[07:33] <vila> hi all !
[07:33] <mneptok> vila: salut
[08:01] <lifeless> night all
[08:03]  * poolie is trying to backport python-configobj to dapper in the ppa
[08:03] <poolie> hi there parthm vila
[08:15] <johnf> Say I have to releases trunk and release and I need to fix a bug in release but trunk has moved on. Am I better off fixing it in trunk and then cd release; bzr merge -r REVISION_ID ../trunk
[08:15] <johnf> or fix it in release and merge back into trunk
[08:15] <johnf> or it doesn't matter or some other better way? :)
[08:17] <spiv> If you merge release branches back into trunk (which is how bzr manages its branches), then branch off release and fix it there is typically easiest.
[08:17] <spiv> Because then your fix branch can be merged directly into both your trunk and release branch.
[08:17] <johnf> spiv: ok that's what I thought. Thanks
[08:18] <spiv> But fixing in trunk and then backporting via "bzr merge -c BLAH ../trunk" is not too painful either, although it leaves bzr with slightly less complete information in the revision history.
[08:22] <echo-area> If I'm going to make a repository public for all users on a host, what's the recommended way?  Currently 'chmod -R 777 repo-dir' comes into my mind
[08:23] <poolie> if you want to let them all commit to it?
[08:23] <poolie> that would do
[08:23] <echo-area> poolie: Okay, thank you.
[08:28] <echo-area> And I suddenly find there are very large files (~3.7G) in my ~/.bazaar/svn-cache directory.  Can I delete it?
[08:34] <spiv> You can.
[08:35] <spiv> (But bzr-svn may need regenerate some or all of them later if you access a SVN repo with bzr.)
[08:39] <echo-area> spiv: Fine.  Storage is a more critical factor than speed for me now :)
[08:40] <lifeless> poolie: I was taking a bet with myself whether you'd have finished yet :)
[08:41] <lifeless> mgz: hey, when you get here, it might be nice for us to put heads down and get a subunit + testtools release done
[09:07] <swathanthran> http://pastebin.ca/1892599 what can be the problem?
[09:12] <vila> swathanthran: s/lh/r/
[09:12] <vila> swathanthran: try it with a web browser and you'll realize you're using the wrong url (use 'r' not 'lh')
[09:13] <swathanthran> yeah i guessed that but didn't know what to use instead of lh
[09:13] <swathanthran> and lh is disabled on savannah.
[09:14] <vila> swathanthran: I walked up to the root to find it
[09:15] <vila> swathanthran: I don't know what is going on with lh on savannah
[09:16] <swathanthran> anyway to find out how much size it could be?
[09:17] <vila> what ? savannah ? loggerhead ? the branch ?
[09:17] <swathanthran> sorry, the branch..
[09:17] <vila> swathanthran: 147.685  Transferred: 60985kB (413.9kB/s r:60931kB w:54kB)
[09:17] <swathanthran> to find out how much size it could be to download, before downloading
[09:18] <swathanthran> vila: ok thanks.
[09:18] <vila> swathanthran: there is no easy way to find that without downloading :) It depends on what you want to download and that can be a part of the whole
[09:19] <swathanthran> ah
[09:20] <vila> the bulf of the data is the revisions, but you can branch from an older revision or the branch's repository can containg more revisions that you need to download
[09:20] <vila> and you may already have some revisions locally and don't need to download them
[09:21] <swathanthran> oh yeah, how to download the sources alone?
[09:23] <swathanthran> bzr co --lightweight?
[09:24] <vila> that's one way, another is: bzr export  builder.tgz http://bzr.savannah.gnu.org/r/gnewsense/builder
[09:24] <vila> but the former will allow you to update at will
[09:25] <swathanthran> oh thats great.. i actually wanted just the current version..
[09:27] <vila> swathanthran: right, if it's a one-time only operation it's ok, but you'll pay the full price the next time you need it otherwise
[09:27] <swathanthran> sure, at night, i don't have to pay for the net, to get along with work now, i have ot pay for the bandwidth;-)
[09:27] <swathanthran> bzr export does it without having the branch on our system?
[09:28] <vila> swathanthran: both export and co --lightweight won't store the downloaded revisions, you'll pay at each use :)
[09:29] <vila> swathanthran: if you use a local branch, you'll only need to download the new revisions next time
[09:30] <swathanthran> yeah got that.. i'll do a full branch at night when i have bandwidth..
[09:30] <swathanthran> and cool, i just got builder.tgz and it was like 20mb or so i guess.
[09:31] <spiv> G'night all.
[09:33] <vila> spiv: g'night
[09:34] <swathanthran> vila: thanks !:)
[09:38] <swathanthran> without loggerhead, can i have an http link to just one file on the repo?
[10:44] <Glenjamin> hi guys, i'm wondering if anyone can help me out; i'm getting this traceback http://pastebin.org/369909 whenever I try and checkout some branches from my SVN repo
[10:47] <maxb> Glenjamin: It looks like you might be branching into an existing shared repository.... if so can you try without?
[10:51] <Glenjamin> there's a whole bunch of inconsistent details in skipped record errors along the way - but the checkout appears to have worked.
[10:52] <Glenjamin> does this mean my shared repo is corrupt in some way?
[10:53] <maxb> Sounds like it
[10:54] <maxb> Try 'bzr check' to get more info, and 'bzr reconcile' to try to fix it
[10:59] <Glenjamin> i guess bzr check sitting there not spitting out any output for a while is probably just it working
[10:59] <Glenjamin> seems to be munching cpu, so i'll trust it
[11:03] <lifeless> check is not optimised -> by which I mean its pretty slow compared to many other commands
[11:06] <Glenjamin> fair engouh really
[11:06] <Glenjamin> http://pastebin.org/369954 was my output
[11:06] <Glenjamin> do i just do reconcile on the repo now?
[11:07] <lifeless> reconcile can't fix the ghosts
[11:07] <lifeless> it can fix the parents.
[11:07] <lifeless> that may fix your error
[11:07] <lifeless> have you looked in the bzr-svn bug tracker ?
[11:07] <Glenjamin> i have, the only similar errors are from 2008 and marked as fixed.
[11:07] <lifeless> ok
[11:07] <lifeless> take a backup
[11:08] <lifeless> then give it a shot
[11:10] <Glenjamin> bah, no luck :(
[11:10] <Glenjamin> i guess i'd better post the bug
[11:35] <Glenjamin> cheers for the help guys, fresh repo from SVN seems to be working :)
[15:00] <jam> GaryvdM: are you currently working on desolation?
[15:00] <jam> (no problem if you are, just checking)
[15:09] <GaryvdM> Hi jam
[15:09] <GaryvdM> I am, but am about to go to ice hockey.
[15:09] <GaryvdM> Trying 1 last build
[15:09] <jam> np
[15:10] <GaryvdM> jam: do you normally work in cygwin bash, or window cmd?
[15:10] <jam> GaryvdM: *I* work in cygwin bash
[15:10] <jam> I believe Ian was working under cmd using gnumake for win32
[15:11] <jam> rather than cygwin make
[15:11] <jam> I just find setting up cygwin a whole lot easier
[15:11] <jam> setup.exe is at least a cygwin package manager
[15:11] <GaryvdM> yes
[15:12] <GaryvdM> ok I'm off to ice hockey
[15:13] <jam> GaryvdM: have fun
[16:09] <vila> aaaaargh lp ! come back !
[16:20] <jam> jelmer: when you get this, 'bzr-svn' doesn't seem to have a tag for 1.0.3
[16:20] <jam> vila: hi
[16:20] <jelmer> jam: that's correct, since 1.0.3 is not out yet
[16:21] <jam> ah, I misread your lp page then
[16:21] <vila> hi jam !
[16:21] <jam> building the installer for 2.1.2 and hacking together the old scripts
[16:21] <jam> I think igc's updates were a push in a good direction, but I don't fully understand them, and they aren't working *right now* so easier for me to start with a known place
[16:22] <jam> jelmer: yeah, looking now I see 1.0.3 is an open circle. I missed that the first time
[16:22] <jam> vila: lp seems to be back for me
[16:26] <vila> jam: yup. me too now
[16:39] <jam> anyone know why Launchpad now requires REFERER to be set to upload files?
[16:39] <jam> It is a real pain for me to upload 5 installers using Firefox versus just a plain script
[16:40] <jam> ah, here we go: https://answers.edge.launchpad.net/launchpad/+faq/1024
[16:40] <jam> of course, *curl* has no referrer because I just uploaded it manually
[16:40] <jam> sigh
[16:41] <mwhudson> you can probably set the referrer on the command line for curl?
[16:41] <jam> mwhudson: I assume so, but it feels stupid to fake a referrer
[16:41] <jam> and requires time for me
[16:41] <jam> :)
[16:41] <exarkun> jam: sounds like a good referrer to use
[16:42] <exarkun> 'this feels stupid and is a waste of my time'
[16:42] <jam> exarkun: except since launchpad is trying to validate it, I imagine that won't work. But I'll give it a shot :)
[16:42] <jam> the FAQ I linked claims they use it to avoid cross-site scripting
[16:42] <mwhudson> no
[16:42] <jam> so all POSTs to LP now have to have a Referrer
[16:42] <mwhudson> cross site request forgery
[16:43] <mwhudson> not quite the same
[16:43] <mwhudson> in particular: no scripting
[16:43] <jam> mwhudson: so what is the specific problem if my web page helps you to upload something or update a bug on lp?
[16:43] <jam> is it more of a 'don't send your login credentials to 3rd party sites' ?
[16:44] <maxb> The idea is that javascript on some other site can't trick you into making a POST to launchpad to do something evil, using your cookie
[16:44] <mwhudson> maxb: again, not javascript, javascript already can't do that
[16:44] <mwhudson> boring old html can though
[16:45] <jam> mwhudson: so... will any edge.launchpad.net url work as the referrer?
[16:45] <mwhudson> http://en.wikipedia.org/wiki/Cross-site_request_forgery
[16:45] <exarkun> For that purpose, isn't a missing referrer as good as a correct launchpad.net referrer?
[16:45] <mwhudson> jam: probably
[16:46] <jam> exarkun: some people disable referrers in their web browser
[16:46] <jam> and they want to protect you from yourself
[16:46] <jam> it seem
[16:46] <jam> seems
[16:46] <mwhudson> a better fix is nonces in the form, but that would be considerably harder to trick with curl i guess :)
[16:46] <jam> mwhudson: the best part is because of how http uploads work, you don't find out about the failure until *after* you've upload 4MB of content
[16:46] <mwhudson> and the real real fix for uploads specifically is an api to do it
[16:47] <exarkun> jam: 100 Continue !!!
[16:47] <mwhudson> exarkun: ptth!
[16:47] <exarkun> mwhudson: yea, I was gonna say
[16:47] <exarkun> mwhudson: haha.
[16:48] <jam> and, of course, all of this worked 3 months ago when I was doing it last
[16:49] <jam> like 5+ things broke in the windows installers steps
[16:49] <jam> mwhudson: so --referrer https://edge.launchpad.net worked just fine
[17:19] <jam> vila: true story. Trying to download the svn binaries leads to URL recursion. It seems they redirect you to a second page, which then sets a cookie and redirects you back to the first page. If you don't carry your cookies along, then you get infinite recursion.
[17:19] <jam> *sigh*
[17:23]  * vila bangs head on desk
[17:24] <jam> vila: building the windows installers is being a real joy
[17:24] <jam> ...
[17:24] <jam> I remember why I loved doing them so much in the past
[17:25]  * jelmer sees his sarcasm-o-meter pan out
[17:25] <jam> it seems that everything in the world decided to change in the last 3 months, just to thwart us
[17:25] <jam> zlib has a new release without a similar dll build
[17:25] <jam> lp now requries referrer to be set
[17:26] <jam> ian did a lot of work to update the installer, but I don't quite follow how it should work yet
[17:26] <jam> svn moved to apache
[17:26] <jam> and doesn't have *new* dlls, and now the old dlls have crazy redirects
[17:26] <jam> qbzr didn't tag 0.19b1 in their trunk
[17:26] <jam> ah they did, but as '0.19beta1'
[17:27] <jam> anyway... getting there
[17:28] <jam> we shut down the old desolation instance, and it may have only been working because all the files were already cached in d:
[17:31] <vila> jam: :-/
[17:31] <vila> so before I EOD, you want me to confirm that as soon as the test suite is passing on windows I will set up babune for windows daily builds ? :-D
[17:31] <jam> anybody knows how to fake a buildout signature so that we can manually do the download and work around buildout trying to be extra helpful
[17:33] <vila> err, won't that make the next failure even more horrible to address ?
[17:35] <jam> vila: I don't care, I want to get builds
[17:35] <jam> stuff is der broken
[17:35] <jam> I'm asking sidnei for help, hopefully he can help work out the buildout stuff
[17:36] <jam> vila: right now I'm reverting back to my old code because it actually works
[17:43] <jam> and I'd really like to switch to what Ian was working
[17:43] <jam> on
[17:51] <chaosaddict> it sounds like the fast-import format prefers ASCII with the exception of raw file data. Is it possible to have non-ascii filenames? I've been having a lot of trouble with latin-1 encoded filenames from Perforce importing into Bazaar.
[17:53] <jam> chaosaddict: I believe the data stream is assumed to be in utf-8
[17:53] <jam> any way you can get the perforce output to .decode('latin-1').encode('utf-8') ?
[17:55] <eydaimon> hi. how is this even possible? http://pastie.org/pastes/1026887
[17:55] <chaosaddict> jam: I believe I have that working, and the fast-export-from-p4 part works. However then the fast-import step crashes. I haven't figured out the root cause on that yet.
[17:55] <jam> chaosaddict: tracebacks help
[17:55] <chaosaddict> jam: unfortunately it spits out a parsing error, rather than a crash + traceback.
[17:56] <jam> eydaimon: One side has: "pu = PaymentUser" and the other side only has "PaymentUser"
[17:56] <jam> I don't know what .rvmrc is, but it appears to be something your vim dropped in the current working dir
[17:57] <jam> eydaimon: otherwise I don't really understand your question
[17:57] <eydaimon> jam: The point I'm making is that after modify the file, and I resolve it, there's nothing to check in
[17:57] <eydaimon> jam: and if I merge again, I get exactly the same thing happening
[17:57] <jam> eydaimon: I don't really know. I would think at the least the merge revision would be ready to be committed.
[17:58] <eydaimon> exactly
[17:58] <jam> Though maybe this is because of the "infinite merge request" issue
[17:58] <eydaimon> sounds like
[17:58] <jam> merging a => b creates a commit that can be merged b => a
[17:58] <eydaimon> is that an open bug?
[17:58] <jam> so we probably added code to prevent that
[17:58] <jam> which is triggering here
[17:58] <jam> I don't think this is an open bug
[17:58] <jam> which is
[17:58] <eydaimon> then how can I address it?
[17:58] <jam> conflict resolution leading to know content change is preventing commit
[17:58] <jam> or something along those lines
[17:59] <jam> eydaimon: worse case you can make a trivial change somewhere
[17:59] <eydaimon> I don't want merging with trunk forever more to cause conflicts
[17:59] <jam> but I'm also surprised that 'bzr status' doesn't say anything
[17:59] <jam> can you paste the output of "bzr merge ; bzr status" *before* you resolve the conflicts?
[17:59] <eydaimon> yeah
[18:00] <jam> you might want to use paste.ubuntu.com, your formatting came out a bit weird on pastie
[18:00] <eydaimon> I already show the first merge
[18:01] <jam> eydaimon: you showed the merge, but not 'bzr status' afterwards
[18:02] <eydaimon> reload pastie to see changes
[18:03] <jam> eydaimon: so something is odd about your merge, as it isn't recording a revision to be merged
[18:03] <jam> ahhh
[18:03] <jam> you are doing a single file merge
[18:03] <jam> that doesn't get recorded
[18:03] <jam> you have to do a full tree merge
[18:04] <eydaimon> k
[18:04] <eydaimon> I would do that but there's one of the files I didn't know how to handle
[18:04] <eydaimon> so I was doing a whole directory
[18:04] <eydaimon> ( was using one file as an example here )
[18:07] <mkanat> 6) Important since these often outline the actual changes in a short form or
[18:07] <mkanat> reason for why the commit were done in that specific branch.
[18:07] <mkanat> Oops.
[18:07] <mkanat> Sorry.
[18:07] <mkanat> Drag-and-drop. :-|
[18:19] <mkanat> jam: Do you still need the account on my machine?
[18:19] <jam> mkanat: only if you tell me I do :)
[18:20] <mkanat> jam: Okay, I'll test meliae first. :-)
[18:46] <mgz> garyvdm, jam: thanks for working on packaging 2.2b3 for windows
[18:47] <jam> mgz: well, my version is pretty hack-tastic, but let me know if it works for you
 zlib has a new release without a similar dll build <- you still needed to do this bit? Does svn or something also need the dll?
[18:47] <jam> mgz: since you mention it, probably not. but the build code I was using still did
[18:47] <mgz> I'm going to test it to see if my -OO change does anything bad to plugins, then send a message to list for plugin authors
[18:48] <mgz> lifeless: after I do that, I have an hour out or so for squash, but am then free all evening for testtools/subunit things
[18:50] <mgz> 'd file a bug on the referer thing jam, even though it's easy to work around, it's stupid
[18:50] <mgz> uploading doesn't sign the binaries or anything, right?
[18:50] <jam> mgz: It looks to be a purposeful design thing, so I can file it, but I think the powers-that-be have explicitly requested it
[18:51] <jam> mgz: no, I manually sign them
[18:51] <mgz> it's purposful for editing bugs and so on, but an upload isn't a db-state-changing thing
[18:51] <mgz> it's just moving bits.
[18:56] <mgz> okay, I get API version complaints from svn and rebase
[18:57] <mgz> urk, and this one is my fault:
[18:57] <mgz> ValueError: No help message set for <bzrlib.plugins.explorer.lib.commands.cmd_explorer object at 0x0114ABF0>
[18:57] <jam> dang jelmer already left
[18:57] <mgz> I *thought* I'd avoided that, and the thingy had been changed not to throw any more anyway
[18:57] <jam> send a message to the list
[18:57] <mgz> will do.
[18:57] <jam> mgz: I think it has, but that will be in 2.2b4
[18:57] <jam> which isn't released yet
[18:58] <mgz> okay, so, this is a maximally borked version, that will probably be useful
[18:59] <mgz> these plugins *are* seperate though, and should be compiled differently, I wonder what went wrong
[19:00] <jam> mgz: well, I used some old build tools
[19:00] <mgz> the setup.py is from the bzr you're shipping though, right?
[19:00] <jam> should be
[19:01] <jam> (i'm pretty darn sure it is)
[19:03] <mgz> okay, so the bit that seems not to be working is the install_data_with_bytecompile class ~line 530
[19:03] <mgz> or I misunderstood how it works
[19:03] <mgz> the idea is that things in library.zip should get optimize=2 and things in the plugins dir should get optimize=1
[19:04] <jam> mgz: sure I remember that part of the patch
[19:04] <jam> I don't know what it takes to make it work or not work, though
[19:05] <mgz> ah, urk, problem.
[19:05] <mgz> it seems the pyo files there do contain the docstrings
[19:06] <mgz> so, instead perhaps the problem is when bzr.exe runs, it does in such a way as they're not loaded?
[19:06] <mgz> which would be I need to work out how to seperate the byte compiling of py files from the mode set for the base script
[19:08] <mgz> I'll get something worked out.
[19:10] <jam> mgz: my quick-and-dirty test says it shouldn't matter
[19:10] <jam> if I compile a .py to .pyo and include the docstring
[19:10] <jam> running python -OO main.py still loads the existing .pyo and still has a docstring
[19:11] <mgz> hmpf, so that's what I originally assumed, something else must be going on
[19:11] <jam> so I would guess something else is at fault
[19:11] <jam> mgz: we need a way to get to a python interpreter from the bzr.exe :)
[19:12] <mgz> that would indeed be useful ;)
[19:12] <mgz> bzr interpreterplz
[19:12] <mgz> wait, I already have the machinery for that, have a throwaway plugin to shove arbitrary stuff in
[19:14] <jam> mgz: yeah, here is one option: http://writeonly.wordpress.com/2008/09/08/embedding-a-python-shell-in-a-python-script/
[19:14] <jam> which uses ipython
[19:14] <jam> but I think you could just have something that does "import pdb; pdb.set_trace()" and get something good-enough
[19:15] <mgz> code.interpret is it indeed.
[19:16] <mgz> dammit, we don't bundle that. pdb it is.
[19:17] <mgz> okay, so explorer does have doc strings.
[19:17] <mgz> is this going to be something daft like, that cmd really *doesn't* have one in the source?
[19:17] <mgz> I should have checked that.
[19:18] <mgz> nope, it seems it does.
[19:18] <jam> mgz: it does in my copy
[19:19] <jam> mgz: are you sure it isn't loading your *local* copy of the plugin rather than the bundled one
[19:20] <jam> and because it is running -OO it is stripping them on-the-fly
[19:20] <jam> oooh
[19:20] <mgz> okay, and it really is missing from bzr.exe's perspective, though other bits keep it.
[19:20] <jam> so your code breaks people from installing extra plugins (it would seem)
[19:20] <mgz> it does, if they don't install them correctly
[19:20] <jam> mgz: I mean, if you put something in BZR_PLUGIN_PATH it will get loaded with -OO
[19:20] <mgz> I'll check on the location, but bzr.exe should really get the path right
[19:20] <jam> which will break them
[19:20] <mgz> right.
[19:21] <jam> import bzrlib.plugins.explorer; print bzrlib.plugins.explorer
[19:21] <jam> should tell you what you want to know
[19:21] <mgz> they are all from the right place
[19:22] <jam> mgz: define 'right place'
[19:22] <jam> the bundled plugin
[19:22] <jam> or a user-installed copy
[19:22] <mgz> bundled
[19:22] <mgz> what I don't get is that bzrlib.plugins.explorer isn't stripped, but bzrlib.plugins.explorer.lib.commands is
[19:22] <mgz> and they are both from the installer
[19:22] <mgz> so... one of two things
[19:22] <jam> mgz: and what does bzrlib.plugins.explorer.lib.commands.cmd_explorer.__doc__ say ?
[19:23] <mgz> (None)
[19:23] <jam> mgz: ah, so the sub-dirs are getting stripped
[19:23] <mgz> (as in, it says nothing, because it really is None)
[19:23] <jam> I wonder if they aren't getting anything
[19:23] <mgz> right, so one of two things
[19:23] <jam> aren't-getting pre-compiled because it isn't doing something recursively
[19:23] <mgz> either the installer is being generated with some plugin files stripped and some not
[19:24] <mgz> or the installer isn't generating some plugin files, and it's happening at run time with -OO
[19:24]  * mgz checks timestamps
[19:24] <jam> mgz: I would guess the latter
[19:25] <jam> mgz: I'm going to install here, and see what files end up
[19:25] <mgz> yup, and on quick check, it's only commands.py that's 18:58 rather than 09:31
[19:26] <jam> mgz: C:\Program Files\Bazaar\plugins\qbzr\lib\commands.pyo
[19:26] <jam> exists at install time
[19:26] <mgz> but I also had a problem with qbzr, so this suggests something slightly more systematic than one missing file in a list
[19:26] <mgz> ^ack.
[19:27] <jam> timestamp of commands.py is 9:30am, timestamp of commands.pyo is 9:34 am
[19:27] <mgz> okay, nice little mystery then.
[19:28] <jam> mgz: and the timestamp isn't updated when I run bzr.exe
[19:28] <jam> but it still fails to run bzr explorer because of a missing help text
[19:30] <jam> mgz: opening the commands.pyo in vim shows that the strings are present
[19:30] <mgz> something is certainly causing them to be rewritten here.
[19:31] <mgz> just did bzr lp-propose
[19:31] <mgz> and the stamp on plugins\launchpad\lp_propose.pyo bumped to now
[19:31] <jam> mgz: my user doesn't have rights
[19:31] <jam> so probably they are being rebuilt in memory, but not getting written down
[19:31] <jam> and just not getting used here
[19:31] <mgz> ah, yup, that'd explain it
[19:32] <mgz> so, the last remaining question is why it's not just loading them from disk...
[19:33] <jam> mgz: how are you getting it to run your code? I don't seem to be able to set BZR_PLUGIN_PATH and have it respected
[19:34] <mgz> 's under .\bazaar\2.0\plugins
[19:34] <jam> ah, k
[19:34] <mgz> in BZR_HOME
[19:34] <jam> well, I got it to run, but then it imported -OO and stripped the docstring :)
[19:35] <jam> mgz: also I wouldn't be surprised if the -O setting is stored in the compiled code
[19:35] <jam> and it sees "oh, this is only -1, I'll do -2 and update it"
[19:35] <mgz> I wouldn't be, but I tested previously and it didn't do that
[19:36] <mgz> so, if it's started doing it I'd be suprised
[19:36] <jam> mgz: python2.6 vs python2.5 maybe?
[19:36] <mgz> also... this is interesting
[19:36] <jam> mgz: so that fixed my problem
[19:36] <jam> I was compiling -O in py2.6 and then running bzr.exe which uses py2.5
[19:36] <jam> after doing that
[19:36] <jam> it just loaded the .pyo without recompiling my plugin
[19:37] <mgz> ah, so, that does explain it
[19:37] <mgz> different magic bit, but from the python version not the flag
[19:38] <jam> mgz: but why would we be building them in the installer with the wrong python version
[19:38] <mgz> good news is that fixing that not only unborks me, but will make first run faster all round
[19:38] <mgz> ...and all runs, in your case where you don't have write access
[19:38] <jam> mgz: (Pdb) bzrlib.plugins.explorer.lib.commands
[19:38] <jam> <module 'bzrlib.plugins.explorer.lib.commands' from 'C:/Users/jameinel/dev/bzr/plugins\explorer\lib\
[19:38] <jam> commands.py'>
[19:38] <jam> I'm pretty sure that confirms it is loading the .py directly, and not the extension
[19:38] <mgz> yup.
[19:39] <jam> however, we are shipping .pyo and I don't see any reason why they would be invalid
[19:39] <mgz> okay, I need to leave... now-ish, but this is something worth fixing
[19:39] <GaryvdM> Hi jam, mgz
[19:40] <jam> hi GaryvdM
[19:40] <jam> mgz: well, given the installer is thoroughly broken... I have to agree :)
[19:41] <GaryvdM> jam: I see you also had zlib issues. Thats where I was stuck today.
[19:41] <mgz> well, backing out my setup.py change will unbreak, but not fix the never-using-pyo thing
[19:41] <jam> GaryvdM: yeah, but we should be able to just drop zlib completely now
[19:42] <jam> I don't know when mgz's patch landed, but we shouldn't need it in the build steps for bzr >2.2?
[19:42] <jam> I pushed the builds out by just reverting to old build scripts
[19:42] <mgz> yup, zlib change landed for 2.2b3
[19:42] <jam> which should be okay for 2.1, it looks like it shows a lot of brokenness in 2.2, but I think that is going to be there regardless
[19:42] <mgz> so, deleting it from all remaining build scripts should work
[19:42] <jam> because it is stuff like "bzr-svn 1.0.2 is incompatible with bzr2.2"
[19:43] <jam> mgz: so there is still the concern that this fix will break anyone running custom plugins
[19:43] <jam> though 2.2b4 won't raise an exception
[19:43] <jam> it will still break "bzr help myplugin"
[19:46] <mgz> right, provided they are running from a tree, not installing with setup.py
[19:46] <jam> mgz: right
[19:46] <mgz> hence message to list about this, and seeing how people use the installer with plugins
[19:47] <jam> mgz: already sent
[19:47] <mgz> it's not a big change to put in and back out, I just wanted some testing and feedback with it in
[19:48] <GaryvdM> jam: So should I see if I can make the build script use wget?
[19:48] <mgz> okay, I need to leave... five minutes ago, but will be back in an hour and a bit to help sort this out
[19:48] <jam> GaryvdM: I'm uploading to launchpad
[19:48] <jam> and have us just point there for now
[19:48] <GaryvdM> ok
[19:49] <GaryvdM> jam: If you happen to do another 2.2, please use qbzr trunk.
[19:49] <jam> GaryvdM: bug #600746
[19:49] <jam> GaryvdM: it is a bit tricky to do a "trunk" build without a tag
[19:49] <jam> any chance you could take 0.19b2 ?
[19:50] <GaryvdM> Ok - let me do that.
[19:50] <jam> s/take/tag/
[19:57] <GaryvdM> jam: I still have not worked out, where do you specify the plugin versions.
[19:58] <jam> GaryvdM: have not worked out what?
[19:59] <jam> If you are on the build host, I'm doing the work in "old-windows-installers"
[19:59] <GaryvdM> jam: Where do you specify that it should use version 0.19b1 of qbzr
[20:00] <jam> tools/win32/buildout.cfg
[20:00] <jam> (yeah, ugly place, which is why igc was fixing it)
[20:00] <GaryvdM> Ah - thanks
[20:02] <GaryvdM> jam: can one not put any revision spec in [plugin]-release-tag?
[20:03] <GaryvdM> (still going to to qbzr release
[20:03] <jam> GaryvdM: probably could, but it is pretty set up to do it this way
[20:03] <jam> I think at one point it supported grabbing the latest tip of everything for doing the build
[20:03] <jam> but I've only really done releases
[20:03] <jam> and I prefer to have tagged code in releases anyway
[20:04] <GaryvdM> Ok
[20:04] <GaryvdM> We can try use "-1" for daily builds.
[20:32] <jam> GaryvdM: something like that
[20:36] <jam> GaryvdM: have you tagged 0.19beta2 yet?
[20:37] <GaryvdM> Not yet - Going through the whole release processes
[20:37] <jam> k
[20:37] <GaryvdM> jam: I normaly make sure I can build the installers before I tag and push
[20:38] <jam> sure
[20:38] <jam> as you wish
[20:42] <jam> GaryvdM: so why were you using the ~igc branch rather than lp:bzr-windows-installers?
[20:42] <GaryvdM> jam: I soon realised that lp:bzr-windows-installers was newer, and switched to that.
[20:43] <jam> ah, k
[20:43] <jam> good
[20:46] <mkanat> Hahaha, the page that causes a memory leak in loggerhead also causes a memory leak in Chrome. :-)
[20:48] <jam> mkanat: So it really is just generating too much stuff :)
[20:48] <jam> its not leaking
[20:48] <jam> just over allocating :)
[20:48] <jam> or just showing too much stuff
[20:48] <mkanat> jam: Well, no, it leaks, in loggerhead.
[20:49] <mkanat> jam: Also, I just crashed meliae.
[20:49] <jam> is this the one I commented on? That going to the 'files' page will leak memory if you reload it a few times until gc kicks in and memory drops again
[20:49] <mkanat> jam: No, I don't think so.
[20:49] <jam> k
[20:49] <jam> mkanat: care for more details than "crashed" ?
[20:49] <mkanat> jam: Yeah, getting them. I just want to be absolutely sure that I have 0.2.1rc installed.
[20:51] <jam> mkanat: I don't doubt you've managed to do something, as your machine seems to work differently than all the other ones I've worked with :)
[20:51] <mkanat> jam: lol
[20:53] <mkanat> jam: Exact same bug; no change on my end. Does 0.2.1.candidate.1 have the fix from yesterday, or do I need trunk?
[20:53] <mkanat> jam: Well, exact same original bug.
[20:53] <mkanat> jam: It now does a fair bit of dumping, but it crashes with the same assertion and a core dump. Do you want the core, or do you just want me to give you steps to reproduce and have you log in?
[20:54] <jam> candidate.1 should have the fix
[20:55] <jam> I might have an idea of one more place to check
[20:55] <mkanat> jam: Okay. Do you want a backtrace?
[20:55] <mkanat> It will take about 20 minutes to get, because I have to install a lot of debug symbols.
[20:56] <jam> either way
[20:56] <mkanat> Okay, I'll start the process.
[20:56] <jam> steps to reproduce would be helpful too
[20:56] <jam> I was able to reproduce it before with "python -c "from meliae import scanner; scanner.dump_all_objects()"
[20:56] <jam> but I fixed that
[20:56] <jam> so it seems to depend on something else now
[20:56] <mkanat> jam: Okay. It's: ./serve-branches /mnt/mkanat-hdd/mkanat/bzr/; SIGQUIT;  then the above.
[20:57] <mkanat> jam: But the ability to SIGQUIT serve-branches is a tiny patch of my own.
[20:57] <mkanat> jam: It just adds breakin to serve-branches.
[20:57] <jam> mkanat: bzr serve --http can be SIGQUIT :)
[20:57] <mkanat> jam: Ah, okay. :-)
[20:58] <mkanat> jam: And yeah, it doesn't matter where I point serve-branches.
[20:59] <mkanat> jam: If I install Cython, will it build with it instead?
[20:59] <jam> yes
[20:59] <mkanat> Hmm, maybe I should try that.
[20:59] <jam> but I don't think that is the specific problem
[20:59] <mkanat> Okay
[20:59] <jam> the core-dump is fix #1, the pyrex is fix #2
[20:59] <mkanat> Ahh.
[21:01] <jam> is everything installed globally?
[21:01] <jam> or are you running something from source?
[21:01] <mkanat> Except meliae, now. Meliae was installed globally, but now I'm running it from a build dir.
[21:01] <lifeless> hi jam
[21:01] <mkanat> And I just installed Cython.
[21:01] <lifeless> mkanat:
[21:02] <mkanat> lifeless: ?
[21:03] <jam> mkanat: well, I don't have your install of loggerhead, etc (at least not obviously)
[21:03] <mkanat> jam: Oh, right. Yes, that's from source.
[21:03] <jam> and I don't have perms for /mnt/mkanat-hdd/mkanat
[21:03] <mkanat> jam: You don't need them.
[21:04] <mkanat> jam: Just start: ./serve-branches
[21:04] <lifeless> mkanat: saying hi
[21:04] <jam> mkanat: well, I need loggerhead
[21:04] <jam> hi lifeless
[21:04] <jam> I was hoping to avoid re-downloading it for you
[21:04] <mkanat> jam: Oh. I could branch it over to you.
[21:04] <jam> loggerhead isn't terribly big
[21:04] <mkanat> jam: Yeah, re-downloading it would be fine.
[21:05] <mkanat> lifeless: Ah, okay. :-) Howdy. :-)
[21:06] <jam> mkanat: k, I've reproduced in a slightly different way
[21:07] <jam> mkanat: how would you get a stack trace from the core dump?
[21:07] <mkanat> jam: Well, normally I'd use gdb, and it would ask me if I wanted to use yum to install stuff.
[21:07] <mkanat> Or it would just tell me to.
[21:07] <mkanat> Or there's some tool for analyzing cores.
[21:07] <mkanat> It's too bad this isn't Fedora 13, though--they have something like pygdb built in.
[21:08] <jam> well the last thing in the dump fil is _ctypes.PointerType which is probably a good hint
[21:09] <jam> yep, got a core from: py -c "from meliae import scanner; import ctypes; scanner.dump_all_objects('test.dump')"
[21:09] <mkanat> Okay. I'm installing the debug symbols.
[21:11] <mkanat> Ah, debuginfo-install python.
[21:11] <PDecker> After "bzr pull"-ing updates of my system-wide-plugins, how do I know which ones need me to "python setup.py install"?  Seems some do (like Dulwich) and most others don't.
[21:11] <jelmer> PDecker, dulwich isn't a plugin but rather one of the dependencies
[21:12] <PDecker> jelmer: It's installed in the system plugins directory, at least on this box I got.  How do we know the difference?
[21:13] <jelmer> PDecker: It wouldn't do anything if it's in the system plugin directory - how did you get it there?
[21:13] <PDecker> Took me awhile to figure out why things weren't working, and that I had to do the 'install' step.
[21:13] <jelmer> PDecker, dulwich is used by bzr-git
[21:15] <PDecker> Never used bzr before ...
[21:15] <PDecker> jelmer: *I* didn't do anything.   I got this box -- new job -- with all this biz pre-installed.  Now I'm doing the usual "fix everything that's screwed up by the nitwits in corporate IT" phase
[21:15] <mkanat> jam: Okay, I have a backtrace for you.
[21:15] <jam> mkanat: can you paste it? or copy it into my home dir?
[21:16] <mkanat> jam: I'll paste it.
[21:16] <mkanat> jam: This is the only thread that isn't in sem_wait: http://pastie.org/1027210
[21:17] <GaryvdM> jam: Is there any think I can help with related to win installers?
[21:18] <jam> GaryvdM: any idea where we are supposed to set versions in the new igc code?
[21:18] <jam> I see in 'bazaar_releases.py' that it references qbzr (for example) but nothing where it says "use version X.Y"
[21:19] <mkanat> jam: I wonder if Fedora ships patches with python. I'll go see if they have any that would affect this.
[21:20] <jam> mkanat: well certainly their assert is tripping in a release build which is strange
[21:20] <jam> but I shouldn't be tripping that anyway
[21:20] <GaryvdM> jam: Same as before:  tools/win32/buildout.cfg
[21:20] <mkanat> jam: Okay.
[21:20] <jam> GaryvdM: are you sure? All the other download urls, etc, are in bazaar_releases.py
[21:21] <GaryvdM> jam: Maybe he meant to move it but did not get to it?
[21:21] <jam> GaryvdM: I think he just never removed it
[21:21] <jam> all the stuff in build-win32 seems to be auto-generated
[21:22] <jam> afaict his code *only* builds the latest tip of each branch
[21:22] <jam> look at build-win32/buildout-bzr-2.2.cfg
[21:22] <jam> it doesn't have any versions in there
[21:22] <jam> and just accesses the trunk brancehs
[21:23] <jam> branches
[21:23] <GaryvdM> jam: let me step through the code an see if i can confirm that.
[21:23] <jam> GaryvdM: he seems to be using a jinja2 template
[21:23] <jam> if you look in buildoutgen.py
[21:24] <jam> and then templates/buildout/buildout.cfg
[21:24] <jam> and nowhere in the template does he note a way to specify a version
[21:25] <jam> (I'm getting a failure in qbzr because of a .po being changed, and I think that is because you haven't made a release so the code that generates the .po files from the .mo is actually producing a new update)
[21:25] <jam> and buildout makes sure that trees are clean before building
[21:25] <jam> and so tip of qbzr is not perfectly up-to-date
[21:25] <jam> but regardless of all that
[21:25] <jam> I need a way to force versions of plugins
[21:26] <jam> especially for building the stable releases...
[21:26] <mkanat> jam: There are patches to python, but I don't see any of them that would affect this.
[21:27] <GaryvdM> jam: ok - let me work on that
[21:28] <GaryvdM> jam: I think you tired to do a build in /cygdrive/d/bzr/bzr-windows-installers. Please could you rm /cygdrive/d/bzr/bzr-windows-installers/build-win32 -r
[21:29] <jam> mkanat: so what is the quick way to get a stack trace from a dump?
[21:29] <jam> I'm triggering it differently, but getting the same failure
[21:29] <mkanat> gdb --core=core.12476 --exec=/usr/bin/python2.6 --batch -ex "thread apply all bt" > bt
[21:29] <jam> it looks like it may be a case of a class having its own tp_traverse, but one that calls into the original one
[21:29] <jam> mkanat: and where is the core dumped, because it isn't in '.'
[21:29] <mkanat> jam: And you have to set "ulimit -c unlimited" to get the core, first.
[21:30] <mkanat> jam: Before running bzr serve.
[21:30] <jam> nice of it to say core dumped without actually dumping it :)
[21:32] <GaryvdM> jam: I created the dir, so I was able to mv build-win32 build-win32-old
[21:33] <mgz> am back.
[21:35] <jam> mkanat: so I can certainly work around the obvious bug by just saying "don't dump anything that is considered a heap type"
[21:35] <jam> sorry a 'non-heap' type
[21:35] <jam> however, it means references will be left out
[21:35] <jam> for platforms that don't have the assert tripping them up
[21:36] <jam> anyway, I have to go now
[21:36] <jam> I'll poke back at this later
[21:36] <mkanat> Okay.
[21:36] <jam> the diff is stuff like this: http://paste.ubuntu.com/458000/
[21:36] <jam> in meliae/_scanner_core.c
[21:37] <jam> GaryvdM: it looks like you reverted some of my changes in bzr-windows-installers
[21:38] <jam> namely, pointing the code at the launchpadlibrarian branches
[21:38] <mkanat> jam: I'm not quite sure I understand what leaving out references would entail. I mean, everything is a reference in python, on a high level, isn't it?
[21:38] <jam> and having "strip_..." set to False for zlib
[21:38] <GaryvdM> jam: ah - sorry
[21:38] <GaryvdM> I restore from ~ files
[21:38] <jam> mkanat: the point of meliae is that it walks references to find objects and dumps their info. Not walking references means that we won't find refs and won't dump them
[21:38] <jam> GaryvdM: anyway, I'm done for now
[21:38] <jam> good luck
[21:38] <mkanat> jam: Yeah, that sounds problematic.
[21:39] <jam> mkanat: tp_traverse was originally meant only for the garbage collector
[21:39] <jam> and it doesn't make sense to garbage collect static objects
[21:39] <jam> (non heap objs)
[21:39] <mkanat> Ahh.
[21:39] <jam> however, it is nice to find them
[21:39] <jam> by for now, see you guys tomorrow
[21:42] <jelmer> moin lifeless
[21:42] <lifeless> hi jelmer
[21:42] <lifeless> how are things
[21:43] <mgz> blast, missed jam while catching up on log
[21:43] <mgz> I need to file a bug against the installer, what project should that be?
[21:43] <jelmer> lifeless: well, trying to fix the #1 bzr-svn bug!
[21:43] <lifeless> which installer
[21:43] <lifeless> windows/mac/ubuntu/???
[21:43] <mgz> just checked 2.1.1 installer and it too overwrites pyo files at runtime rather than using the ones on disk
[21:43] <lifeless> jelmer: cool
[21:43] <mgz> win.
[21:43] <lifeless> bzr-windows-installers
[21:43] <GaryvdM> mgz: bzr-windows-installers
[21:43] <lifeless> or something like that
[21:44] <mgz> this is going to hurt perf, even if we avoid my added docstring problem
[21:44] <lifeless> ugh faaail
[21:44] <mgz> badly, for people like jam who install as admin and run with dropped privs
[21:45] <lifeless> ah yes
[21:45] <lifeless> the classic' but I waannnnnnna cache Mommy!'
[21:46] <mgz> well, library.zip avoids this, but it hurts plugins
[21:46] <lifeless> how so?
[21:47] <mgz> well, it seems that (at least some of) the pyo files for plugins shipped in the installer are for python 2.6 but the python is 2.5
[21:47] <mgz> so they need to be recompiled from the py at least once (and every load if you don't have write privs to the dir)
[21:52] <lifeless> 06:46 < mgz> well, library.zip avoids this, but it hurts plugins
[21:52] <lifeless> 06:46 < lifeless> how so?
[21:53] <mgz> pasted what I said pre-ping in /query
[21:53] <lifeless> ah
[21:54] <lifeless> so that would be a bug, not a library.zip thing
[21:54] <mgz> but if you mean the library.zip bit of that question... I presume it's a different path in the building of the installer
[21:54] <mgz> nothing would work at all of the files in the zip had the wrong magic at the start
[21:54] <mgz> (as there are no .py files in there)
[21:54] <mgz> just finishing typing up the bug entry now
[22:04] <mgz> I'm not certain it's down the python version, the shipped and recreated files appear to have the same magic
[22:05] <mgz> and it's not timestamp related... what else can cause recompilation?
[22:05] <lifeless> nothing I've heard of
[22:05] <lifeless> oh
[22:05] <lifeless> if you can't read the file
[22:06] <mgz> oh, wait.
[22:06] <mgz> the timestamp check is != rather than < isn't it?
[22:06] <mgz> that'll be it.
[22:07] <mgz> the pyo files shipped are all from a few seconds later
[22:16] <mgz> wait, I'm wrong about that too. 's the timestamp in the bytecode that matters, not the file timestamp
[22:18] <mkanat> jam: The python-meliae maintainer in Fedora has a patch! :-D
[22:19] <mkanat> I didn't even know there was a python-meliae.
[22:20] <lifeless> mgz: is the timestamp in the bytecode borked perhaps ?
[22:21] <mgz> it is, seven hours out exactly
[22:21] <lifeless> oh joy
[22:21] <mgz> is jam in gmt+7?
[22:21] <lifeless> windows not understanding GMT. again.
[22:21] <mgz> (or whoever built 2.1.1)
[22:21] <lifeless> well
[22:21] <lifeless> I think they are built in a VM on ec2
[22:21] <lifeless> but whatever
[22:28] <mkanat> jam: Anyhow, I'm working it out with the Fedora python maintainer.
[22:30] <mkanat> jam: Okay, problem is that Fedora is unintentionally shipping debug builds of python, somehow.
[22:42] <GaryvdM> mgz: You are good with these things. Any idea how to fix this: http://pastebin.org/371858
[22:43] <GaryvdM> If I run the command manually, then it works. I only fails when the build script runs it.
[22:44] <mgz> hm, funky.
[22:45] <mgz> well, the environment is messed up, I don't seem to have a devenv.com to check out though
[22:45] <GaryvdM> mgz: ok thanks for looking.
[22:46] <mgz> anything more in the buildlog html file?
[22:47] <GaryvdM> mgz: no. Its just the same output nicely formated