Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

md5 missmatch. #164

Open
gregtap opened this issue Jun 19, 2015 · 4 comments
Open

md5 missmatch. #164

gregtap opened this issue Jun 19, 2015 · 4 comments
Labels
Milestone

Comments

@gregtap
Copy link

gregtap commented Jun 19, 2015

On the current develop branch using Docker compose my local python lib gets uploaded with:

python setup.py sdist upload -r local

The source file is in my local directory (dist) and it ends up on the web container root folder. Something like <repo_name>/source/o/<package_name>.

So far so good.

However during the installation I get a md5 missmatch error.
After some digging my source md5 is indeed different than the file in the container. The file in the container is corrupted and I can not introspect it. Yet the file size seems to be close to the original.

Am I the only one experiencing such issues?

I am going to add some debug on the upload method but its hard to tell where the issue could be.

@gregtap
Copy link
Author

gregtap commented Jun 24, 2015

I have redone an installation from scratch on a Vagrant vm with ansible and still experience the same issue.

@mvantellingen
Copy link
Owner

Ok, will try to reproduce. I assume the filesize doesn't match either?

@mvantellingen mvantellingen added this to the 0.10 milestone Jun 24, 2015
@gregtap
Copy link
Author

gregtap commented Jun 24, 2015

Right they do not. I digged a bit deeper and at one point I thought it was the distutils upload method from Python 2.7.8 on Mac going wrong during the multipart upload.

I finally gave up and setup pypiserver for now. The upload step worked well and did not corrupt the tar gz.

@eisensheng
Copy link

I'm also affected by this.

I put a bit of research into it and it appears that there is an unnecessary UTF-8 encoding happening somewhere. An ZIP archive starting with

000000 50 4b 03 04 14 00 00 00 08 00 c5 6e 65 47 cb af  >PK.........neG..<

becomes when uploaded

000000 50 4b 03 04 14 00 00 00 08 00 c3 85 6e 65 47 c3  >PK..........neG.<

Notice that the byte sequence 00 c5 6e 65 changed to the sequence 00 c3 85 6e 65. The byte sequence c3 85 is the UTF-8 encoded value for the character Å which has the code point 197 or to express it in hexadecimal c5, the byte of the original input.

I can't tell who's here the one to be blamed though.

Edit:
It appears to be working with twine though. So it's highly likely that distutils/setuptools is the one to be blamed here. But then again why is it working with other implementations of the PYPI?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants