Package Details: isa-l_crypto 2.26-1

Git Clone URL: https://aur.archlinux.org/isa-l_crypto.git (read-only, click to copy)
Package Base: isa-l_crypto
Description: A collection of optimized low-level functions targeting storage applications
Upstream URL: https://github.com/intel/isa-l_crypto
Licenses: BSD-3-Clause
Submitter: afsio
Maintainer: fft
Last Packager: fft
Votes: 1
Popularity: 0.000000
First Submitted: 2017-10-12 00:15 (UTC)
Last Updated: 2026-03-08 13:05 (UTC)

Dependencies (4)

Required by (1)

Sources (1)

Latest Comments

pobrn commented on 2025-12-17 12:57 (UTC)

@fft Tests run successfully now, thanks.

fft commented on 2025-12-16 16:42 (UTC)

Agreed, package updated. This issue doesn't reproduced for me (un)fortunately, so I can't check, whether this helps. @pobrn inform, whether all ok now, please.

pobrn commented on 2025-12-06 22:15 (UTC)

@fft But the default makepkg.conf enables LTO, so in my opinion one could reasonably expect that all(?) AUR packages build with that successfully.

In any case please see my new comment on the upstream issue: https://github.com/intel/isa-l_crypto/issues/165#issuecomment-3621275482 I believe this is a case of undefined behaviour. So instead of disabling LTO, it would be nice if -fno-strict-aliasing could be added here until an upstream fix.

fft commented on 2025-11-28 07:32 (UTC)

@pobrn, tests work for me both with and without LTO and upstream doesn't force to use LTO also. So I think, that PKGBUILD is not a right place for fixing issue.

As I understand, this -lto=auto was added from makepkg.conf, right? May be you can override it as temp workaround? (I mean something like makepkg CFLAGS="-flto=auto -O3 -g" )

pobrn commented on 2025-11-25 14:49 (UTC)

At least on my machine LTO causes the test failure ( https://github.com/intel/isa-l_crypto/issues/165 ). Could it be disabled until an upstream fix is found?

travisghansen commented on 2025-07-11 16:46 (UTC)

I am guessing it may be connected to specific cpu feature perhaps? I am on an amd machine..

fft commented on 2025-07-03 19:14 (UTC)

@travisghansen, I can't reproduce this. Tried to run this test with valgrind and/or clang. This doesn't look like packaging problem, but let's try to investigate it. Whether this is reproducible behaviour? If yes, whether data in 'ref:' string is always the same?

travisghansen commented on 2025-06-30 23:00 (UTC)

Getting this error trying to install..

=============================================
   libisal_crypto 2.25.0: ./test-suite.log
=============================================

# TOTAL: 37
# PASS:  36
# SKIP:  0
# XFAIL: 0
# FAIL:  1
# XPASS: 0
# ERROR: 0

System information (uname -a): Linux 6.15.4-arch2-1 #1 SMP PREEMPT_DYNAMIC Fri, 27 Jun 2025 16:35:07 +0000 x86_64
Distribution information (/etc/os-release):
NAME="Arch Linux"
PRETTY_NAME="Arch Linux"
ID=arch
BUILD_ID=rolling
ANSI_COLOR="38;2;23;147;209"
HOME_URL="https://archlinux.org/"
DOCUMENTATION_URL="https://wiki.archlinux.org/"
SUPPORT_URL="https://bbs.archlinux.org/"

.. contents:: :depth: 2

FAIL: mh_sha256/mh_sha256_test
==============================

isal_mh_sha256_update_test:
mh_sha256 fail test
ref:  88 f5 d1 50 4c 95 2e f8 ba  e 68 fa c7 86 fd 71 d5 8b 83 d9 a4 4c 8a 10 b9 c9 44  8 cd e0 c3 c4
test:   e  2 f2 30 df 10 2a 99 24  5 5d 80 b7 a5 35 77 8e 60  5 51 9d 9b b8 94 50 79 ec  f 86  1 18 2d
fail rand1 test
isal_mh_sha256_update_test: Fail
FAIL mh_sha256/mh_sha256_test (exit status: 8)

fft commented on 2025-01-27 16:53 (UTC)

Hello, thank you for packaging. v2.25 released.

libisal_crypto.pc is buggy (same issue as for https://aur.archlinux.org/packages/isa-l#comment-1008968). Can you fix this also?