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