Arch Linux User Repository

And now I notice upstream acknowledged this two days ago initial report fixing commit release notes my ticket

I haven't paid enough attention, I guess. Moreover, checking the diffoscope output, I misread it, flipping the old and new tarball -- the old tarball was the one overwritten by a nightly, the new tarball corrects this. Releasing a pkgrel correcting the checksum.

... Turns out that's against policy, checking again to see if eg Debian still has an intact copy

@Atraii -- I unflagged too soon, you're correct. It seems upstream has accidentally overwritten their 1.51.2 tarball with a nightly (notice that the linux tarball is marked as updated two days ago, in contrast to the others updated last week) I've contacted upstream, hopefully they fix it soon. In the meantime, I'm uploading a pkgrel with the old tarball embedded.

Package updated, thanks @solipsist for the reminder!

At a guess, the problem is pacman notices it has local files named after the manual pages and tries to use them, instead of redownloading and checking against checksums.

Will push a fix giving the manpage files version-unique names to avoid this later tonight. Hopefully, once https://github.com/simonmichael/hledger/issues/2309 is fixed this can be entirely ignored.

As a sanity check, I too am seeing this breakage -- the sha256sums I have for the 1.40 manpages here are

cb37c183da683bd6031c881272998f994a60ead08b25e61c4698d6cbc3269968  /home/gesh/.local/var/cache/pacman/sources/hledger.1
7a789e1a2b82f0e250efb5ec0d1b630a6053cabb2912bccddee7f65fc08fe992  /home/gesh/.local/var/cache/pacman/sources/hledger-ui.1
cfd949b03ce0a0ce20d7ab1e99173456465d02716cc3ad472a4be7bc2e31d325  /home/gesh/.local/var/cache/pacman/sources/hledger-web.1

and checking against the hledger git repo, the files in pacman's cache are indeed the manuals as of 1.40 whereas the ones at the url I'm pointing to are the manuals as of 1.41

I think some checksums failed when I tried to update.

==> Making package: hledger-bin 1.41-1 (Sat 22 Feb 2025 08:41:35 GMT)
==> Retrieving sources...
-> Found hledger-1.41.tar.zip
-> Found hledger.1
-> Found hledger-ui.1
-> Found hledger-web.1
==> Validating source files with sha256sums...
hledger-1.41.tar.zip ... Passed
hledger.1 ... FAILED
hledger-ui.1 ... FAILED
hledger-web.1 ... FAILED
==> ERROR: One or more files did not pass the validity check!

@alerque Done, though I'm a little confused as to how you're using this?

Also, this feels like something a clever enough pacman should be able to do itself, I've raised this upstream: https://gitlab.archlinux.org/pacman/pacman/-/issues/225

Would you mind fixing the provide declarations (in 3 places of course) with version specs:

- provides=(hledger)
+ provides=("hledger=$pkgver")

This will make builds of this package easier to manage as project dependencies so it can resolve whether to prefer the (frequently OOD) official hledger package or this one. Thanks.

@zibolo That's odd -- I'm guessing I mistakenly ldd'd hledger-git, which yielded these false positives. Checking the archives, I can confirm what you're saying, and indeed dropping all depends lines yields a seemingly-working binary even when building in a clean chroot.

Indeed, checking upstream, the release is built against musl in an Alpine Linux container. Thanks for pointing it out, I'll be using upstream's config to fix my -static packages.

Hello @gesh! I'm not an expert and I'm curious how did you determine gmp and ncurses dependencies.

By downloading the latest (1.41) prebuilt binaries, all executables seems to be "fully" statically linked, indeed ldd hledger* returns "not a dynamic executable".

file says hledger: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked [...].