Package Details: python-flake8-polyfill 1.0.2.r18.gb98e6f4-1

Git Clone URL: https://aur.archlinux.org/python-flake8-polyfill.git (read-only, click to copy)
Package Base: python-flake8-polyfill
Description: Polyfill package for Flake8 plugins
Upstream URL: https://github.com/PyCQA/flake8-polyfill
Licenses: LicenseRef-MIT
Submitter: SpotlightKid
Maintainer: gesh
Last Packager: gesh
Votes: 6
Popularity: 0.60
First Submitted: 2016-10-21 14:19 (UTC)
Last Updated: 2024-04-04 13:30 (UTC)

Pinned Comments

gesh commented on 2024-03-27 12:35 (UTC)

Pushed the update, however it broke the build, so I backported a few of the fixes from the Github repo. To ease future maintenance, the last commit effectively turns this into a -git package to pull in the automatic fixes published by Github. This isn't necessary for most usecases -- if the PKGBUILD looks intimidatingly complex to you, you can always git checkout master^ to use the conceptually-simpler backport.

Latest Comments

1 2 3 Next › Last »

petaramesh commented on 2024-03-29 15:08 (UTC)

Well, In the Linux / FOSS universe, it's never “been a problem” to use a different software or distribution. I've been using a couple Arch machines and many more Manjaro machines and also some Debian machines, and some derivatices of them for years, happily.

Manjaro is usually only a few weeks behind Arch in terms of package updates (and this is on the “stable” branch), it's never been an issue for me until... today, and I guess it won't be for a long time again.

Many thanks for your assistance anyway.

gesh commented on 2024-03-29 14:55 (UTC)

And this is why I told you that you being on Manjaro is a problem - I can rely on Arch people being on makepkg 6.1.0 since earlier this month, but the inevitable update delay here between Manjaro and Arch means your usecase breaks my packaging assumptions. Now, you are correct in noting this is usually not a problem as long as the differences aren't relevantly big, but when they are, it's much harder to diagnose, as you've just seen. I don't have answers for you - Arch recommendations make it very likely you'll run into these kinds of problems again unless you pay attention to this gap.

petaramesh commented on 2024-03-29 14:38 (UTC)

That's correct, I have pacman 6.0.2-18 (which makepkg belongs to) :

❯ makepkg --version
makepkg (pacman) 6.0.2

gesh commented on 2024-03-29 14:05 (UTC)

Check your makepkg version - I'm guessing it's 6.0.0, where I have 6.1.0

petaramesh commented on 2024-03-29 13:45 (UTC)

And if I replace the 1st checksum in your PKGBUILD with 'SKIP', then the package compiles and installs allright.

So I guess that it boils down to : How comes makepkg cannot SHA256 verify a complete directory structure on my system, where this seems to work on yours ?

gesh commented on 2024-03-29 13:42 (UTC)

Ah, wait, what version of makepkg are you on? Version 6.1.0 added support for checking checked-out got repos[1] - just replace the first shasum by 'SKIP' and it should work.

[1] - https://gitlab.archlinux.org/pacman/pacman/-/blame/master/NEWS?ref_type=heads#L21

petaramesh commented on 2024-03-29 13:36 (UTC)

I spent a little more time trying to understand what is happening. By doing a manual makepkg (which I am not an expert of), and I get :

❯ makepkg --verifysource
==> Making package: python-flake8-polyfill 1.0.2.r18.gb98e6f4-1 (ven. 29 mars 2024 14:29:57)
==> Retrieving sources...
  -> Updating python-flake8-polyfill git repo...
  -> Found fix-tests.patch
  -> Found version.sh
==> Validating source files with sha256sums...
    python-flake8-polyfill ... NOT FOUND
    fix-tests.patch ... Passed
    version.sh ... Passed
==> ERROR: One or more files did not pass the validity check!

So it is obvious that makepkg is trying to SHA256 verify a file called python-flake8-polyfill and fails, and that is correct because this is not a file but a directory. And AFAIK, makepkg knows how to check files, but not whole directories, and here python-flake8-polyfill is a directory which is a clone of a git repository.

Your PKGBUILD file contains :

source=("$pkgname::git+$url#commit=b98e6f4f6cc90334f4d7040745aee91b4021cc42"
    fix-tests.patch
    version.sh)
sha256sums=('6fa19d5ed3629de90256046c7e848805b90745460296b3b6677b0c61a9af2744'
            '33a28897eda38828c197a6f31e0415a8804209c40f698ca5b5201b7660b65985'
            'd15fca2becb34181a422547a3fed8695f4ff8459753d087aed768d0d010bf5db')

So well, I do understand why my makepkg can't verify a file that doesn't actually exist, but I do not understand how this can work for you. Does your makepkg produce an actual file that passes the verificaton ?

petaramesh commented on 2024-03-28 20:09 (UTC)

Of course I undestand your point very well, and I thank you for your support and assistance so far. I'll try to figure out what's going on here, but I have very limited bandwidth for I'm very busy these days. I will let you know if I find something. Thanks again !

gesh commented on 2024-03-28 16:22 (UTC)

... Then perhaps Manjaro patches makepkg, libalpm, or any of a score of other possibilities. All I know is that with the cleanest configuration I can get here (using stock makepkg, in a clean Arch Linux chroot that only contains the package's dependencies), things build for me, so it is most probably a broken interaction between Manjaro's configuration and this PKGBUILD. I cannot help you further, and can offer no more than to point you at Manjaro's Matrix channel. If they can point to whatever is causing the build to fail on Manjaro, I'll consider editing the PKGBUILD for it, but I can't do remote tech support on such a limited medium.

petaramesh commented on 2024-03-28 16:13 (UTC)

Well, as I tried manually as got the same result, pamac is definitely out of the way...

1 2 3 Next › Last »