Arch Linux

adigitoleo

Member

From: Australia

Registered: 2020-08-02

Posts: 47

[SOLVED] aerc package version not the same as result of aerc -v

The aerc package, whose PKGBUILD can be found at

https://gitlab.archlinux.org/archlinux/ … type=heads

seems to build a runtime which does not report the correct version when queried with

aerc -v

which may be a result of a missing "main.Version" declaration at build time. I refer here to the Void linux manifest which can be found at

https://github.com/void-linux/void-pack … c/template

For the current aerc package (version 0.16.0-1) on Arch, I observe that aerc -v reports "aerc 0.15.2 +notmuch (go1.21.1 amd64 linux)". I noticed this because I'm also facing another issue with aerc on Arch where I cannot load email contents in this client and am instead presented with the message "waiting for data" indefinitely. I'm not sure if it is related although my issue is more likely a general IMAP/TLS issue. I use identical aerc configs on Arch and Void linux and on the latter everything is and has been working since I began using aerc.

Edit: The other issue was unrelated and not even an IMAP thing, but a simple case of hardcoded paths in a config file which turned out to be void specific.

Last edited by adigitoleo (2024-01-12 03:15:49)

Scimmia

Fellow

Registered: 2012-09-01

Posts: 13,365

Re: [SOLVED] aerc package version not the same as result of aerc -v

This usually happens when upstream forgets to bump their version when releasing. It's down right now, so can't check to be sure.

Edit: github mirror confirms it. https://github.com/rjarry/aerc/blob/0.1 … akefile#L3

Looks like in switching to GNU make only, they missed updating their release script to bump the version in the new file. Fixed later in https://github.com/rjarry/aerc/commit/d … 865e369509

Last edited by Scimmia (2024-01-12 01:30:40)

adigitoleo

Member

From: Australia

Registered: 2020-08-02

Posts: 47

Re: [SOLVED] aerc package version not the same as result of aerc -v

Ah OK, no big deal then, sorry I missed that. Marking as solved since it's fixed upstream and will be correct on next version bump. Up to the package maintainers if they want to add a workaround for now or not.