[00:56] <jam> mgz: ** Bug watch added: SourceForge.net Tracker #2581469    http://sourceforge.net/support/tracker.php?aid=2581469
[00:56] <jam> I think it worked
[00:58] <jam> ubot5: the bug is 1.5years old, surely you can find it
[01:11] <jam> mgz: well, in Vim I have !M<enter> as a macro to fill out all of the def main() import Optparse sort of stuff
[01:11] <jam> so it is pretty trivial
[01:11] <jam> I really don't like top-level scripting
[01:12] <lifeless> why not use bzr's command infrastructure?
[01:12] <lifeless> I do, or the stuff I put into testrepository
[01:12] <jam> lifeless: I certainly could, and just write a plugin, I just started as a script here
[01:12] <jam> both work
[01:12] <jam> main is pretty trivial to get up and running
[01:12] <jam> and I don't always depend on bzrlib
[01:13] <jam> lifeless, mgz: http://paste.ubuntu.com/458547/
[01:13] <jam> I set that up before bzr existed I believe
[01:14] <jam> anyway, back to family time
[02:55] <lifeless> vila: are you around perchance?
[15:35] <mgz> not had to read pascal for a long time
[15:36] <mgz> seems the right fix for installer bug is easy though, once I actually er... got the right bit of software
[20:01] <GaryvdM> Hi mgz
[20:01] <mgz> good timing.
[20:02] <GaryvdM> I'll do a build with your patch now.
[20:02] <mgz> can I twist your arm to try...
[20:02] <mgz> right, that.
[20:02] <mgz> thanks!
[20:05] <GaryvdM> Bla - I have all sorts of uncommited channges - need to deal with them before I merge your branch...
[20:05] <mgz> shelve!
[20:06] <GaryvdM> Shelving some of it, commiting some of it.
[20:07] <mgz> bad habit forming that, I have too much stuff stashed in pseudo-diffs in a hidden folder rather than getting finished
[20:07] <mgz> I did only use it with hg, but have started using with with bzr as well.
[20:15] <GaryvdM> I'm not sure how well the build script handles changes, so I'm doing a full build, rather than a incremental, just to be sure.
[20:15] <GaryvdM> So it will take about 10min
[20:28] <GaryvdM> mgz:http://dl.dropbox.com/u/4494367/bzr-2.2~bzr.dev~3-setup.exe
[20:28] <mgz> getting.
[20:30]  * GaryvdM tests using wine...
[20:32] <GaryvdM> Bla fix for tbzr not working...
[20:34] <mgz> meh, and seems timestamps ar still messed up
[20:36] <GaryvdM> mgz: my branch that I am building with: lp:~garyvdm/bzr-windows-installers/maybe
[20:36] <mgz> oddly, it's an hour *and a minute* out...
[20:36] <mgz> >>> time.gmtime(struct.unpack("<2i", file(r"C:\Program Files\BazaarBeta\plugins\bzrtools\__init__.pyo", "rb").read(8))[1])
[20:36] <mgz> (2010, 7, 3, 19, 17, 43, 5, 184, 0)
[20:36] <mgz> >>> time.gmtime(os.stat(r"C:\Program Files\BazaarBeta\plugins\bzrtools\__init__.py").st_mtime)
[20:36] <mgz> (2010, 7, 3, 18, 17, 42, 5, 184, 0)
[20:37] <mgz> *second
[20:37] <GaryvdM> mgz: maybe useful for debugging: http://innounp.sourceforge.net/
[20:38] <mgz> will check, but I looked at their source and it seemed like the flag would do the right thing
[20:39] <mgz> oaaaa... I have a bad feeling
[20:39] <mgz> I'm going to try running the setup again, but this time setting TMP to my main NTFS drive first
[20:42] <mgz> nope, still a second out.
[20:43] <mgz> back to the pascal...
[20:44] <GaryvdM> mgz: I thing you have made the change in the wrong place.
[20:44] <mgz> this is possible, I hate build stuff.
[20:44] <GaryvdM> mgz: templates/inno/bzr.iss
[20:44] <mgz> it's not even clear to me if that was the input of a script or the output
[20:45] <GaryvdM> Don't worry - I'm just as confused....
[20:45] <mgz> the one-second problem won't be helped though... is the build slave on FAT rather than NTFS?
[20:45] <GaryvdM> I'll check
[20:46] <mgz> no... that wouldn't explain it either I don't think... grrr
[20:46] <GaryvdM> NTFS, on both drives
[20:48] <mgz> C:\>innounp -v bzr-2.2~bzr.dev~3-setup.exe | grep bzrtools.__init__
[20:48] <mgz>       3689  2010.07.03 19:17  {app}\plugins\bzrtools\__init__.py
[20:48] <mgz>       3249  2010.07.03 19:24  {app}\plugins\bzrtools\__init__.pyo
[20:48] <mgz> so, it's stored as the right hour, but doesn't give me the seconds to check
[20:50] <GaryvdM> mgz: let me know If I can run things on the build host to debug.
[20:50] <mgz> well, did that cog thing get overwritten by the build process?
[20:50] <mgz> should I try moving the change to the templates dir?
[20:51] <mgz> that would at least fix the hours-out problem
[20:51] <GaryvdM> I don't think that the cog file gets used at all.
[20:51] <mgz> uuuu.
[20:51] <mgz> okay, I'll move it, push, and if you could try again...
[20:52] <GaryvdM> See Ian's comment here: https://bugs.edge.launchpad.net/bzr-windows-installers/+bug/569077
[20:52] <mgz> actually, I'm going to uncommit, I've made enough recored dumb mistakes on this bug already
[20:52] <GaryvdM> https://bugs.edge.launchpad.net/bzr-windows-installers/+bug/569077/comments/7
[20:53] <mgz> can we not just... delete things that aren't used any more... why else do we use version control...
[20:53] <GaryvdM> mgz: I've just stated doing the builds...
[20:53] <mgz> I'm not blaming you
[20:54] <GaryvdM> mgz: yes - I agree..
[20:54] <mgz> but, speaking of blame, there's blame in that cog file from Ian,
[20:54] <mgz> Date:
[20:54] <mgz> 07/03/2010 11:54:07
[20:54] <mgz> which is ... dammit!
[20:54] <mgz> not a US date.
[20:54] <mgz> so, it's not today ;)
[20:55] <GaryvdM> lol ...
[20:57] <mgz> okay, pushed the move, if you could pull and try that...
[20:57] <GaryvdM> mgz: ok
[20:58] <GaryvdM> I also want to try a different fix for the tbzr issue.
[21:01] <mgz> if we have to add code to do % 2 on every py file mtime, I'm going to be annoyed
[21:07] <mgz> http://www.jrsoftware.org/ishelp/topic_setup_timestamprounding.htm
[21:07] <mgz> okay, that's to blame for the rounding
[21:08] <mgz> just changing that would fix the issue fully for nearly everyone, but potentially screw fat people
[21:08] <mgz> seems like and improvement though so I'll add it to my existing branch
[21:13] <mgz> pushed that as well if you've not started the new build yet
[21:13] <GaryvdM> mgz: http://dl.dropbox.com/u/4494367/bzr-2.2~bzr.dev~4-setup.exe (without time stamp rounding)
[21:13] <mgz> will test that, thanks.
[21:14] <mgz> don't worry about the new change yet.
[21:14] <GaryvdM> mgz: I'll kick off a another build
[21:16] <GaryvdM> mgz: that was an incremental build. Let me know if you don't see any change.
[21:16] <mgz> will do, nearly downloaded
[21:18] <GaryvdM> Maybe later we can look at trying to make the install smaller. I think there are some pyqt .pyd files we don't need.
[21:19] <mgz> excluding stuff like that script you mentioned yesterday and seeing if that helps sounds worthwhile
[21:19] <mgz> okay, that build has the right hour.
[21:20] <mgz> so incremental seems to be fine, as does my FAT tmp drive
[21:20] <mgz> just need to see if my last push also sorts out the second
[21:20] <GaryvdM> \o/ TortoiseOverlays bug fixed.
[21:21] <mgz> go gary.
[21:27] <GaryvdM> mgz: http://dl.dropbox.com/u/4494367/bzr-2.2~bzr.dev~5-setup.exe
[21:28] <mgz> wgetting
[21:31] <GaryvdM> We can remove 6mb (uncompressed) unneeded pyqt files
[21:32] <GaryvdM> But other things first.
[21:32] <mgz> works.
[21:32] <mgz> timestamp matches, qbzr help displays
[21:33] <mgz> pipeline-launchpadlib issue still needs fixing
[21:34] <mgz> was sure Aaron had another crack at making that lazy-loaded, is there not a pending rev to pull or something?
[21:34] <GaryvdM> mgz: But what functionality do we lose buy not having the lib?
[21:35] <GaryvdM> mgz: I thing better to just add the lib.
[21:35] <mgz> lp-propose and some other bits I think
[21:35] <mgz> the problem is it's not just the lib
[21:36] <mgz> it's a maze of setuptools dependencies and related mess spanning eight or so packages
[21:36] <mgz> it doesn't even *let* you install it by the normal methods
[21:37] <mgz>   File "C:/Program Files/BazaarBeta/plugins\pipeline\__init__.py", line 161, in <module>
[21:37] <mgz>   File "C:/Program Files/BazaarBeta/plugins\launchpad\lp_api.py", line 43, in <module>
[21:37] <mgz> DependencyNotPresent: Unable to import library "launchpadlib": No module named launchpadlib
[21:37] <mgz> (with -Derror so pipeline has an indirect need via launchpad plugin apparently)
[21:39] <GaryvdM> mgz: Bug  569717
[21:39] <mgz> okay, that's trivial, he's catching the wrong error
[21:39] <mgz> it's in an except ImportError wrapper, but launchpad plugin is reraising as bzrlib.errors.DependencyNotPresent
[21:41] <mgz> I can fix that in pipeline and defer the should-and-how over launchpadlib
[21:41] <GaryvdM> mgz: I think better to put effort in adding launchpadlib to the installer.
[21:41] <mgz> bzrlib.errors isn't something we try and load lazily is it? comes under huge-but-essential.
[21:42] <mgz> by all means have a look at it, but... I bet it won't be fun.
[21:42] <GaryvdM> mgz: Making it lazy import is tricky.
[21:43] <GaryvdM> mgz: I have a branch which dose it. I did not submit - to hackey.
[21:43] <mgz> right, so I can just import and not worry.
[21:47] <GaryvdM> mgz: lp:~garyvdm/bzr/more_lazy
[21:48] <mgz> ...think I should file a new bug against bzr-pipeline or add the project to the existing bug/
[21:48] <mgz> don't know launchpad ettiquette here
[21:48] <mgz> /=?
[21:49] <GaryvdM> First check for existing bugs in pipeline...
[21:49] <mgz> didn't find anything searching for "launchpadlib"
[21:50] <GaryvdM> mgz: I would say they are 2 different bugs.
[21:50] <GaryvdM> installer does not have launchpadlib
[21:51] <GaryvdM> pipeline does not lazy import launchpadlib
[21:51] <GaryvdM> So IMO log a new pipeline bug.
[21:51] <mgz> k, will file new bug against pipeline.
[21:59] <mgz> can you try an installer build with a bzr-pipeline from my branch rather than trunk, or is that hard to do?
[22:01] <GaryvdM> I can do that. Branch lp url?
[22:02] <GaryvdM> mgz ^
[22:02] <mgz> lp:~gz/bzr-pipeline/no_launchpadlib_needed_601466
[22:23] <GaryvdM> mgz: http://dl.dropbox.com/u/4494367/bzr-2.2~bzr.dev~4-setup.exe
[22:23] <GaryvdM> mgz: http://dl.dropbox.com/u/4494367/bzr-2.2~bzr.dev~5-setup.exe
[22:23] <GaryvdM> 5 not 4
[22:24] <mgz> the last one was also ~5?
[22:24] <mgz> that is, I have a ~5 on disk already
[22:24] <GaryvdM> Oh - opps - sorry
[22:25] <GaryvdM> Here I am, building a version control system , and I can't count...
[22:26] <mgz> it's a different size so I'm guessing it is actually a new build :)
[22:27] <GaryvdM> Yes
[22:27] <GaryvdM> Drop box did not warn me that I was overwriting :-(
[22:31] <mgz> that seems to have worked
[22:32] <mgz> no more pipeline complaints.
[22:32] <GaryvdM> Cool - I'm going home shortly. I'll be around tomorrow morning.
[22:34] <mgz> I'm out of problems to make you test.
[22:34] <GaryvdM> :-)
[22:35] <mgz> I'll throw up a branch with a bzr setup.py change that's easy but ugly, but doesn't need experimenting with.
[22:38] <GaryvdM> mgz: I need to make the new scripts accept a taged revision, try bundle launchpad lib, remove unneeded pyqt revisions, find a better solution to the PyQt.uic.port_v3 problem, create a test build with bzrw.exe, try removing unused build code (such as the cog files).....
[22:38] <GaryvdM> *unneeded pyqt files
[22:38] <GaryvdM> :-)
[22:41] <mgz> lp:~gz/bzr/installer_plugin_script_timestamp_rounding <- the change
[22:41] <mgz> not sure it's really a good idea, and that py2exe stuff all needs to live in bzr-windows-installers rather than core, but hey
[22:41] <GaryvdM> Yes Yes Yes
[22:42] <GaryvdM> Or in plugin setup.py
[22:42] <mgz> simple enough to write that having thought of it earlier as an option may as well just propose and let others decide
[22:43] <GaryvdM> You rock.
[22:49] <GaryvdM> Cheers mgz.
[22:49] <mgz> evenin'