[Ohrrpgce] Distribute Menu problem

[Ralph Versteegen]

On 5 April 2013 04:55, James Paige <Bob at hamsterrepublic.com> wrote:
> On Thu, Apr 04, 2013 at 08:40:05AM -0700, James Paige wrote:
>> On Sat, Mar 30, 2013 at 03:43:24PM -0700, James Paige wrote:
>> > On Sat, Mar 30, 2013 at 03:41:35AM +1300, Ralph Versteegen wrote:
>> > > I've just realised that Custom does not keep track of or check the
>> > > versions of the game players it downloads for creating packages for
>> > > other platforms. If you packaged a game for another platform using
>> > > Alectormancy or any other version/build, upgrade to Beelzebufo (or any
>> > > other version/build) and try to create a package for that platform
>> > > then nothing is downloaded and an out of date version of Game is used,
>> > > which will likely throw an error (definitely for A->B).
>> > >
>> > > We need to fix at least the Alectormancy -> Beelzebufo upgrade before
>> > > release. Handing nightly builds may be more tricky.
>> >
>> > Oh, ouch! I am really glad you caught this bug now before release! :)
>> >
>> > > We only need to keep a single version of Game for each platform,
>> > > updating it if it is older than Custom but accepting newer builds
>> > > (which would probably mean a newer version of Custom has been used).
>> > >
>> > > Also, note that currently Custom will download the latest nightly
>> > > build of Game if it is a nightly. This is not really ideal as
>> > > nightlies sometimes have serious bugs. Custom could download builds
>> > > from the nightly archive built the same day that it was built instead.
>> >
>> > The trouble with that is that the nightly archive isn't super reliable,
>> > and has gaps in it, so that would possibly require stepping through
>> > dates until we find a working one :(
>> >
>> > > However I notice that the ohrrpgce-mac-minimal.tar.gz and
>> > > ohrrpgce-mac-minimal-linkless.tar.gz files aren't being archived at
>> > > http://gilgamesh.hamsterrepublic.com/nightly-archive/
>> > >
>> > > Maybe we should check the modification date on the downloaded files to
>> > > see whether they are out of date, which would help prevent breakage if
>> > > the night builds for a platform haven't been running for a while, as
>> > > often happens. Or should we store the date on which they were
>> > > downloaded in a text file instead?
>> >
>> > Hmm... I am going to have to think about this. My brain is slightly
>> > frazzled after a busy week, and I am in a room of loudly talking people
>> > ;P we can discus this more soon :)
>> >
>> > ---
>> > James Paige
>>
>> Wait a second! As I started to work on fixing this bug today, I read the
>> code, and I cannot understand how this bug could be happening.
>>
>> the relevant code is get_windows_gameplayer() get_linux_gameplayer() and
>> get_mac_gameplayer()
>>
>> All of them unconditionally call either wget or curl to re-download the
>> gameplayer every time, no matter whether or not the gameplayer has
>> already been downloaded.
>>
>> when using wget, the -N command line option is used which causes wget
>> intself to do date-checking on the file, and only downloads it if the
>> file on the server is newer.
>>
>> So based on my reading of the code, I can't understand why the bug is
>> happening... unless maybe the copy of wget.exe we use on windows was
>> somehow compiled with broken -N support?

Err... opps. wget -N fooled me into thinking it only tried to download
it the first time, combined with a misreading of the code. It's nice
that that wget -N avoids that download automatically. It seems that
curl also has an option for this, -z

Although it still would be nice if it downloaded a stable or nightly
build from the same date, we can otherwise forget about this then.

>
> TMC, I do remember that you mentioned previously that
> ohrrpgce-mac-minimal-linkless.tar.gz was not being rebuild. I just
> checked on it, and I see that it was last rebuilt on 2012-07-27
>
> I forced a rebuild now.
>
> I could schedule it in a cron job, but I guess it would be better to
> just fix the regular ohrrpgce-mac-minimal.tar.gz to not need symlinks
>
> ---
> James

Yes, I'll try modifying bundleapp.sh to remove the symlinks.