Building with meson still fails with util-linux 2.40.x and building with autotools is now broken. Hooray...
Edit: Okay.. Building from the repo is broken. Tarball works for the time.
Git Clone URL: | https://aur.archlinux.org/util-linux-aes.git (read-only, click to copy) |
---|---|
Package Base: | util-linux-aes |
Description: | Miscellaneous system utilities for Linux, with loop-AES support |
Upstream URL: | https://github.com/util-linux/util-linux |
Licenses: | ISC, BSD-3-Clause, BSD-2-Clause, GPL-3.0-or-later, GPL-2.0-only, GPL-2.0-or-later, LGPL-2.1-or-later, BSD-4-Clause-UC, LicenseRef-PublicDomain |
Conflicts: | hardlink, rfkill, util-linux |
Provides: | hardlink, rfkill, util-linux |
Replaces: | hardlink, rfkill |
Submitter: | None |
Maintainer: | TrialnError |
Last Packager: | TrialnError |
Votes: | 6 |
Popularity: | 0.000000 |
First Submitted: | 2011-03-02 21:16 (UTC) |
Last Updated: | 2024-08-01 16:33 (UTC) |
Building with meson still fails with util-linux 2.40.x and building with autotools is now broken. Hooray...
Edit: Okay.. Building from the repo is broken. Tarball works for the time.
Luckily there is a new update for loop-aes (3.8c), vaygr. It may now be possible to update this to 2.40.x. I hope upstream added support for meson. Without it will be harder to follow Arch changes... and autotools may be dropped sometime in the future...
I'm not a fan of pkgrel bumps in favour of aur helpers. And not required to do so.
In general it could trigger/remind some of the needed rebuild. But for others it will be an unnecessary one as they covered it themselves. When someone uses software from the AUR he needs to look after it.
TrialInError that's fine, but it needs a rebuild against Python 3.11 so pkgrel
could trigger it.
This package stays at 2.38 until the mess is resolved which got introduced with 2.39.
I wonder if we could make asciidoctor optional since it's required only for manual pages. On my system it requires a zoo of ruby dependencies which I'd like to avoid.
Hello vaygr.
Fair point you're mentioning. Didn't thought of those lines in loop-aes.
So let's remove it from this and maybe change loop-aes such that the modules handling is moved to a separate file and more visible as such.
Thanks for the heads up
TrialInError am I missing something or "util-linux-aes.modules" file should be dropped from here?
I think both loop-aes and loop-aes-dkms set up module loading properly and this one just duplicates what's already there + leaves some old cruft that's not relevant anymore:
systemd-modules-load[262]: Failed to find module 'aes-i586'
Not the first to mention this :D
Yes, I indeed overlooked this detail. I was under the impression the loop-aes files come with a sig. Well, apparantly not..
TrialInError seems Jari's key needs to be added to validpgpkeys for successful build.
Which is '12D64C3ADCDA0AA427BDACDFF0733C808132F189'.
Pinned Comments
TrialnError commented on 2020-06-12 15:49 (UTC)
This package should only be flagged out of date if there is a release of loop-aes which offers a new diff.