Plugin pyo files may be ignored and recreated from source

John thought this might be Python version related, but both before and after pyo files seem to have '\xb3\xf2\r\n' as the magic. Rather, it seems to be timestamps. Bazaar 2.1.1 has plugin py files from 2010-03-26 00:44 but pyo files from 2010-03-26 00:50 and the check is != rather than > for recompilation.

That's still slightly wrong, it's the timestamp in the bytecode vs. the timestamp of the py file that matters, but that *is* seven hours out for 2.1.1 so must be the cause.

The shipped pyo files:

    >>> time.gmtime(struct.unpack("<i", "\xc4e\xacK")[0])
    (2010, 3, 26, 7, 44, 4, 4, 85, 0)

After recompilation:

    >>> time.gmtime(struct.unpack("<i", "T\x03\xacK")[0])
    (2010, 3, 26, 0, 44, 4, 4, 85, 0)

Yeay for timezones?

So -7 matches exactly the TZ offset of the build host. So I'm wondering if somewhere along the line someone is getting a localized timestamp, and someone else is treating it as a Unix timestamp (since epoch, no tz).

We're going to try setting the TZ for the machine to UTC, and see if that works.

Unfortunately it seems just changing the build host's timezone wasn't enough, with the change it's an hour out (as I'm on summertime). It seems the installer is mapping the localtime of packed files to the localtime of the target machine.

Likely upstream bug for this sort of problem with NSIS:
<http://sourceforge.net/tracker/index.php?func=detail&aid=2581469&group_id=22049&atid=373085>

Bazaar uses Inno Setup installer, not NSIS one.

Er, oh, whoops. I did sort of ask what installer was used on IRC but assumed wrongly.

With Inno the fix might be easy then:
<http://www.jrsoftware.org/ishelp/topic_setup_timestampsinutc.htm>

Can I just add that to tools/win32/bzr.iss.cog? In the bzr project or the bzr-windows-installers project or both?

So, Inno also create another problem for us by rounding the timestamp to the nearest even second, in the name of FAT compat:
<http://www.jrsoftware.org/ishelp/topic_setup_timestamprounding.htm>

Disabling that as well should finally fix this bug... for everyone except those still on FAT filesystems. To cover them as well, we'd have to round the timestamps of all plugin py files prior to bytecode compilation.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Martin [gz] wrote:
> Er, oh, whoops. I did sort of ask what installer was used on IRC but
> assumed wrongly.
>
> With Inno the fix might be easy then:
> <http://www.jrsoftware.org/ishelp/topic_setup_timestampsinutc.htm>
>
> Can I just add that to tools/win32/bzr.iss.cog? In the bzr project or
> the bzr-windows-installers project or both?
>

that should work in bzr-windows-installers.

John
=:->

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkwvufIACgkQJdeBCYSNAAN5kwCgsDwcxWi6BylW6opnK7swL3BA
GKAAnjkUdeBqg5NypoZETXoQYGRw7pMA
=LBli
-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Martin [gz] wrote:
> So, Inno also create another problem for us by rounding the timestamp to the nearest even second, in the name of FAT compat:
> <http://www.jrsoftware.org/ishelp/topic_setup_timestamprounding.htm>
>
> Disabling that as well should finally fix this bug... for everyone
> except those still on FAT filesystems. To cover them as well, we'd have
> to round the timestamps of all plugin py files prior to bytecode
> compilation.
>

Why does that matter, given that the stored value in the .pyo is an
integer? Is it because it rounds rather than truncates?

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkwvuhoACgkQJdeBCYSNAAPEuACfY/Zp1F0mhti7UZSjYX/VigHl
Hv0An0TC5/nGPCsP1IFUJ6ubqA2sdlM+
=LFYc
-----END PGP SIGNATURE-----

It matters because if we're building on NTFS we can have a py file with an odd timestamp, which is correctly put in the pyo file as an odd integer. On unpacking to a FAT drive the py file mtime is evened due to the 2 second resolution, and no longer matches the pyo timestamp.

The linked branch now also disables the Inno rounding, and optionally lp:~gz/bzr/installer_plugin_script_timestamp_rounding covers the corner case of installing onto FAT.

I reported the duplicate bug https://bugs.launchpad.net/bugs/601225
I just removed 2.2b3-1, installed 2.2b3-2. I'm pleased to report Bazaar is working OK and no more crashes at startup.
Thankyou to all who helped.

Lewis

Revisions with the fixes appear to be on trunk now.