search

wireservice / leather

Python charting for 80% of humans.
https://leather.readthedocs.io
MIT License
330 stars 30 forks source link

Version 0.4.0 checksum issue in archlinux. #107

Closed kanakshilledar closed 4 months ago

kanakshilledar commented 5 months ago

There exists a checksum issue for this package in arch linux. (here.

I would like to confirm whether the v0.4.0 was re-released? Is there any difference between both the releases? The earlier checksum for the 0.4.0 package was 2bc92e77a2db43b0a0aabdc9ce0893d0728ce0c8098897a55e4c2244bbdc5b0f but now the checksum is 5b4d698e97534a2600150837c2beb446278b7ef276a699768efc5488c88290c3.

The release upgrade for this package on arch linux happened on Feb 20, 2024 but here the actual package release was on Feb 24, 2024

Could you please clarify on this checksum mismatch issue?

jpmckinney commented 5 months ago

Hmm, it’s possible the tag changed on GitHub, but on PyPI there is only ever one version of the code for a given number.

kanakshilledar commented 5 months ago

Was the package re-released? Why is there a checksum mismatch?

jpmckinney commented 5 months ago

I have no idea what ArchLinux is doing, so I can’t really debug from my end. This project does not have anything to do with ArchLinux.

ArchLinux should get releases from PyPI. If it is taking releases from GitHub, that could be the error.

jpmckinney commented 5 months ago

You might need to report your issue to ArchLinux instead

kanakshilledar commented 4 months ago

https://gitlab.archlinux.org/archlinux/packaging/packages/python-leather/-/merge_requests/1 I have created a PR regarding the same issue with Arch Linux.

ArchLinux should get releases from PyPI. If it is taking releases from GitHub, that could be the error.

They are taking releases from GitHub.

jpmckinney commented 4 months ago

My only guess as to why it was retagged is because the release process to PyPI failed when switching over to PyPI's new Trusted Publishers workflow. The release process is trigged by a git tag, and so the git tag had to be reissued.

Like most of the Python ecosystem, we make releases to PyPI. GitHub automatically creates tar.gz files for tags, and this feature cannot be disabled. However, we make no effort to manage releases on GitHub itself.

Also, I'm pretty sure all the other Linux distros that we've interacted with use PyPI – since we've had requests in the past to include/exclude certain files from the artifacts uploaded to PyPI. Same for:

jpmckinney commented 4 months ago

We can continue discussion, but I think we largely answered the question.

alerque commented 4 months ago

and so the git tag had to be reissued.

Not it did not, the workflow runs can be re-triggered other ways or a new tag with an incremented patch number could have been issued. Pulling a release and re-tagging it causes a lot of work for downstream packagers like me. Please don't do that. An incomplete release where some public artifacts have been pushed is merit for fixing the release process and tagging a patch release.

ArchLinux should get releases from PyPI. If it is taking releases from GitHub, that could be the error.

There is a long history of problems pulling releases from PyPI and we're actually moving the opposite way, pulling from project sources where possible. One of the main issues is that there is no transparency or validation for artifacts posted on PyPI. We can't easily verify if the code is even the same as what appears in source repositories, the artifacts aren't signed (and they recently removed sigining mechanisms). Git sources are much easier to monitor the differences from release to release, the artifacts can be signed, they typically include test and license infor authors frequently forget to package in the PyPI manifest, etc.

jpmckinney commented 4 months ago

Thanks for the context. I don't anticipate needing to re-tag anything in future.