Big Bad Bug - Final uploads

gummbum on 2020/10/01 04:33
— edited on 2020/10/01 04:35

To everyone, and especially Daniel,


Please note I discovered a nasty bug while trying to upload my final entry. I was using Slimjet browser, a Chromium derivative - Windows 10, file format tar.gz made by MobaXterm (a Cygwin derivative).

The issue is this: the upload appeared to work fine. I have had trouble with uploads and archives before, so I downloaded it to test the archive. I found it was corrupt. I retried uploading twice more and they were corrupt. I switched to Internet Explorer and the archive's integrity survived.

Now I have seen this issue twice during the competition. This poor guy is bitten by it: https://pyweek.org/e/LateWarp/. I wouldn't be surprised if there are more to come.

No idea where to start an investigation to stamp this out. For now, spreading awareness seems the best immediate course. Judges, please be gracious if you encounter corrupt final entries during Pyweek 30. Hopefully people provided a repo we can download source and still play 'n judge; or they are reachable somehow, and it can be fixed with Daniel's help.

Maybe there is something more Daniel can do to assist the bug-bitten among us? Thanks for reading. :)

(log in to comment)

Comments

mauve on 2020/10/02 21:29:

I checked both of the .tgz uploads under https://pyweek.org/e/LateWarp/ and they extract and play just fine.

What software are you using to check the archives?

yarolig on 2020/10/03 16:21:

Hi.


Yes.

Looks like a tar-gz archives gets decompressed when downloading from the site.

I checked PyWeek30_LateWarp-0.91.tgz. 

Original md5sum is 5d1ec3b706bfd732b0858628c0da645c, size 11 364 405 bytes, file says.
I have downloaded games using pyweek download 30. All right.
But using browser: md5sum b8b10ad9f372add1f76440c33e3db91b, size 11 468 800 bytes. I checked. It is decompressed original archive.

yarolig on 2020/10/03 16:28:

Decompressed tar archives are fine for judging. It is easy to unpack it with tar xf archive.tgz or rename archive.tgz to archive.tar and open it with GUI programs such as 7-zip.

mauve on 2020/10/03 17:38:

Oh, then the bug is that S3 is sending a Content-Encoding: gzip header, causing the browser to decompress it as it downloads.

mauve on 2020/10/03 18:05:

By the way, does the PyWeek CLI work for downloading these?

gummbum on 2020/10/03 19:21:

@yarolig Thanks for that tip! "tar tf" does indeed work.

gummbum on 2020/10/03 19:28:

@mauve Cool. I didn't know about the CLI. Trying it the first time.

In MobaXterm/Cygwin I had to: py3 /drives/c/Python37/Lib/site-packages/pyweek.py download 30


The CLI downloads tar.gz files without decoding them. "tar tzf" and "tar xzf" works as expected.

Thanks!

gummbum on 2020/10/03 19:31:

TIP: Folks who are looking for info on the CLI go to Help, and search "Pyweek CLI".

gummbum on 2020/10/10 05:52:

Hi @mauve.

Regarding the cli downloader, I have an issue to report. While going through the entries, I noticed two teams that have the same project name "Castaway" on the Entries page:

https://pyweek.org/e/dragdev/
https://pyweek.org/e/castaway/

Search the Entries page for "Castaway —" to see them.

The cli downloader apparently downloaded the finals for the former, but not the latter; or a race condition in the downloader clobbered the directory. Which is to say the download directory "castaway" has these files from the former project:

castaway-master.zip
castaway.zip 

but not this one from the latter project:

castaway_v1.zip

We can still manually download, so it's not a crisis. :)

mauve on 2020/10/10 07:27:

Filed as https://github.com/pyweekorg/cli/issues/1

gummbum on 2021/04/04 02:32:

@mauve I tried the CLI and get this error. Any ideas?
requests.exceptions.SSLError: HTTPSConnectionPool(host='pyweek.org', port=443): Max retries exceeded with url: /31/downloads.json (Caused by SSLError(SSLCertVerificationError(1, '[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:1076)')))