Package Details: acmetool 0.0.67-5

Git Clone URL: (read-only, click to copy)
Package Base: acmetool
Description: An easy-to-use command line tool for automatically acquiring certificates from ACME servers (such as Let's Encrypt)
Upstream URL:
Licenses: MIT
Submitter: Thermi
Maintainer: None
Last Packager: Thermi
Votes: 4
Popularity: 0.000000
First Submitted: 2016-08-26 09:00 (UTC)
Last Updated: 2019-10-25 00:20 (UTC)

Latest Comments

cyqsimon commented on 2022-04-04 08:04 (UTC) (edited on 2022-04-04 08:10 (UTC) by cyqsimon)

I think it's fair to consider acmetool as abandonware for now.

If you (like me) have previously used its redirect feature (handles ACME over HTTP and redirects everything else to HTTPS), you may wish to check out acme-redirect. It's simple, intuitive, configurable, written in Rust, and just overall very comfortable to use. I built it from source and deployed it on my RHEL8 server without trouble within half an hour.

For the moment the only problem I've found is that it doesn't generate a file that contains both the full chain and key (which haproxy prefers), but I have already put in a PR for that.

ammonaur commented on 2022-03-29 00:56 (UTC) (edited on 2022-03-29 00:56 (UTC) by ammonaur)

Build fails, I don't use go so I'm not sure what the fix is, but this looks like a build tool change:

==> Making package: acmetool 0.0.67-5 (Mon 28 Mar 2022 08:55:21 PM EDT)
==> Checking runtime dependencies...
==> Checking buildtime dependencies...
==> Retrieving sources...
  -> Found acmetool-0.0.67.tar.gz
  -> Found LICENSE
  -> Found acmetool.service
  -> Found acmetool.timer
  -> Found acmetool.conf
==> Validating source files with sha256sums...
    acmetool-0.0.67.tar.gz ... Skipped
    LICENSE ... Passed
    acmetool.service ... Passed
    acmetool.timer ... Passed
    acmetool.conf ... Passed
==> Removing existing $srcdir/ directory...
==> Extracting sources...
  -> Extracting acmetool-0.0.67.tar.gz with bsdtar
==> Starting prepare()...
go: go.mod file not found in current directory or any parent directory.
    'go get' is no longer supported outside a module.
    To build and install a command, use 'go install' with a version,
    like 'go install'
    For more information, see
    or run 'go help get' or 'go help install'.
==> ERROR: A failure occurred in prepare().
 -> error making: acmetool

bsdice commented on 2021-05-18 09:42 (UTC)

I also switched, to which I can recommend. A bit quirky with all those options but works for me. Let's Encrypt needs occasional updates for its API but Hugo seems busy otherwise to implement all the changes. +1 abandonware for me as well.

Thermi commented on 2021-05-18 09:16 (UTC)

FredBezies just orphaned the package via an AUR request. I don't use it anymore and the dev, hlandau, is not declaring any stable version, so I won't try to maintain it anymore. From my side, it's basically abandonware now.

Thermi commented on 2020-07-23 23:32 (UTC)

I'll bump the PKG version once the new version is stable.

bsdice commented on 2019-10-25 00:13 (UTC)

Is 0.0.67-4 for anyone else broken? In prepare() I need this now:

... mv "${srcdir}/acmetool-${pkgver}" "${GOPATH}/src/" ...

Sloonz commented on 2019-10-21 12:56 (UTC)

0.2.1 is beta :

grawity commented on 2019-10-21 12:24 (UTC) (edited on 2019-10-21 12:26 (UTC) by grawity)

In that case, it might be better to verify using the SHA1 hash of Git commit (which hopefully isn't going to change no matter what GitHub decides to screw up):


Speaking of which, v0.2.1 appears to have been tagged last week:


(Yes I know the < > are not supposed to be there. I'm not in control of what AUR's markdownifier decides to do.)

Sloonz commented on 2019-10-18 20:10 (UTC)

Checksum for acmetool-0.0.67.tar.gz doesn’t checks. Just downloaded the tarball on, checksum is 45e458f385515b669ade4a8de6dd6800da2b61f4846bd6f573e28c51ca6805ea ; 01f78340006539c62bb86250433d2f819ab529ccd9a0aa74e140ff0fee839073 in the PKGBUILD

zewish commented on 2018-12-20 15:22 (UTC)

Please add aarch64 to the arch list. Just installed it and it works as expected. Thanks!

bsdice commented on 2018-07-26 01:43 (UTC)

@grawity Learn something new every day... thanks!

Any particular reason to go with 0755 in and not 0750 i.e. restricted to root?

No need to push a new release for this, but please close the Contributor line in PKGBUILD with '>' because it triggers a faint ocd. ;)


Thermi commented on 2018-07-25 17:08 (UTC)

Thank you, I removed it.

grawity commented on 2018-07-25 17:05 (UTC) (edited on 2018-07-25 17:05 (UTC) by grawity)

Introduce acmetool.install to run "systemd-tmpfiles --create" on install/upgrade

This has been redundant for quite a while now; new tmpfiles configurations are handled by a global pacman hook. You can safely revert this part.

Thermi commented on 2018-07-24 15:01 (UTC)


I've incorporated the changes.

bsdice commented on 2018-07-24 01:26 (UTC) (edited on 2018-07-24 01:27 (UTC) by bsdice)

Hi, I've made some improvements to your package, diff:


  • Introduce acmetool.install to run "systemd-tmpfiles --create" on install/upgrade

  • Fix dependencies to include only necessary libcap and bash

  • Semantic nitpick acmetool.tmpfile -> acmetool.tmpfiles

  • Split build() into prepare() and build()

  • Simplify prepare() steps

  • Simplify build(), introduce StandardWebrootPath set to /run/acme/acme-challenge (/var/run is just a symlink on Arch)

  • acmetool.tmpfiles has to be named acmetool.conf when installed in /usr/lib/tmpfiles.d/ (only *.conf are recognized by systemd-tmpfiles)

  • Add openresty.service as a dependency to service file

  • Modify ReadWritePaths to allow /run/acme instead of /var/run/acme

  • Modify acmetool.tmpfiles to create /run/acme instead of /var/run/acme, also tighten permissions (only root)

I'd hope you could incorporate the changes. Thanks!

Thermi commented on 2017-02-16 15:00 (UTC)

@kpcyrd I'm trying to adopt many of your changes, but 0.0.58 doesn't build on my system yet. I will update this PKGBUILD when it does. armv7h support will be dropped in the next release, because of the guidelines for PKGBUILDs[1] > If instead a package can be compiled for any architecture, but is architecture-specific once compiled, specify all architectures officially supported by Arch, i.e. arch=('i686' 'x86_64'). [1]

kpcyrd commented on 2017-02-06 07:22 (UTC)

Please see my patch which fixes a bunch of issues: