Arch Linux User Repository

code burg appears to be down so you cant clone

@gesh Thanks for the report, I updated the checksums.

https://gitlab.archlinux.org/pacman/pacman/-/commit/9548d6cc765b1a8dcf933e8b1b89d0bcc3e50209 changed the checksum calculation for repos with .gitattributes -- the checksums need to be updated.

python-setuptools Ah, supposed that'd be the case. In fact, I was so surprised by the edit I tried building in a clean chroot. To my surprise, it worked. I've been bitten before by this - I initially thought PEP517 meant packages didn't require a build backend installed, and failed to recognize my packages kept building due to python-setuptools being already installed on my system.

Avoiding the fate of XZ Ah, forgot that wrinkle in the saga - I'd only remembered the injection-via-Makefile part. In that case, agreed - until we have some guarantees on the contents of the release tarballs, they should be considered less trusted than the repository itself. Thanks for the reminder! Perhaps you could raise the topic on the relevant Discussion page on the Wiki?

@gesh Thanks for the report, I added python-setuptools to makedepends.

Any reason the python-setuptools dep was removed in the latest commit?

Version 2.2.1 had a runtime dependency on python-setuptools, which was removed in 2.3.0 so I removed it from depends. I didn't realize that it was also a build time dependency, because it built successfully in a clean chroot because of python-setuptools-scm pulling it in.

Also, why is the package pulling in the entire git history of the project

This is because of better supply chain security. Like the XZ incident has shown, very few people (if any) validate that the tarball contents actually match the contents of the git repository. By pulling the source directly from git we eliminate the need for that extra validation step.

The risk with the tarball in this specific case is admittedly quite small, because Codeberg autogenerates it from the git tag, so compromising it would require compromising the Codeberg infrastructure. However, using git sources still eliminates that small risk.

I would prefer more packages adopting git sources for these reasons, or even adding it as a recommendation to the Arch Package Guidelines, but so far most non-VCS packages are using tarballs as sources.

Any reason the python-setuptools dep was removed in the latest commit? I can understand and would support making it a makedep, but relying on python-setuptools-scm pulling it in seems wrong.

Also, why is the package pulling in the entire git history of the project, instead of the source tarball at https://codeberg.org/miurahr/pykakasi/archive/v${pkgver}.tar.gz ? Not that it matters much (the entire repo is just 28M), but it's slightly weird to see a non-VCS package using VCS makedeps.

@RockhopperP No problem. You can also build in a clean chroot to avoid locale issues.

@pekkar It seemed to be a problem with my locale. KDE doesn't properly change locale settings for an individual user. When I set everything to US, I can install. Thanks answering!

@RockhopperP You don't need to manually patch anything. The prepare function inside the PKGBUILD applies the patch, and makepkg runs it automatically. The package should build just fine with makepkg -C

I'm lost how do I patch it? I manually tried to replace ["setuptools>=42", "wheel", "setuptools_scm[toml]>=3.5.0", "klepto"] with ["setuptools>=42", "wheel", "setuptools_scm[toml]>=3.5.0"] but that did not do the trick.

I need this for python-spotdl. Any help would be appreciated!