On 2025-04-21 Andreas Metzler <ametz...@bebt.de> wrote:
> Source: gpgme1.0
[...]
> FAIL! : AddExistingSubkeyJobTest::testAddExistingSubkeyWithExpiration()
> Compared values are not the same
> Actual (result.code()) : 0
> Expected (static_cast<int>(GPG_ERR_INV_TIME)): 161
> Loc: [../../../../lang/qt/tests/t-addexistingsubkey.cpp(238)]
[...]
> This shows up on all 32 bit archs with 64bit time that had the build-deps
> (armhf, armel and as non-relase arch powerpc).
[...]
Hello,
I think this is probably a real 64bit time issue with gpgmeqt on 32 bit
archs. Adding a debugging
printf("DEBUG1 sourceSubkey.expirationTime=%lli\n",
sourceSubkey.expirationTime());
to lang/qt/tests/t-addexistingsubkey.cpp L268 after
const auto result = job->exec(key, sourceSubkey);
shows this output:
amd64
DEBUG1 sourceSubkey.expirationTime=4102488000
i386
DEBUG1 sourceSubkey.expirationTime=-18348044646416448
i386 with -D_TIME_BITS=64
DEBUG1 sourceSubkey.expirationTime=-192479296
armhf
DEBUG1 sourceSubkey.expirationTime=-192479296
Looking at the respective key we find on amd64 and armhf:
pub ed25519 2022-01-13 [SC]
1CB8C6A0317AA83F44FE009932392C82B814C8E0
uid [ unknown] source-...@example.net
sub cv25519 2022-01-13 [E]
sub cv25519 2022-01-13 [E] [expires: 2100-01-01]
which matches
ametzler@amdahl:~$ LANG=C date -d @4102488000
Fri Jan 1 12:00:00 UTC 2100
(gnupg on i386 says [expires: ????-??-??])
The tests passes on amd64 and i386 and fails on armhf.
It also succeeds on i386 with -D_TIME_BITS=64 but I somehow doubt its
worth investigating deeper there, since I only rebuilt gpgme* itself
with -D_TIME_BITS=64 but not its rdeps or the gnupg and its rdeps I
would not expect totally sane behavior.
cu Andreas
--
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'
