Bug 2070926

It's already branched, but keepassxc cannot build because following dependencies are missing
libyubikey-devel
ykpers-devel

https://koji.fedoraproject.org/koji/taskinfo?taskID=85007268

Germano(In reply to Germano Massullo from comment #1)
> It's already branched, but keepassxc cannot build because following
> dependencies are missing
> libyubikey-devel
> ykpers-devel
> 
> https://koji.fedoraproject.org/koji/taskinfo?taskID=85007268

Germano, just wondering, have you tried compiling it with -DWITH_XC_YUBIKEY=OFF ... that should exclude the ykcore code, and allow for a release without Yubikey support, at least until the ykcore issue is resolved.

(In reply to Ladar Levison from comment #2)
> Germano(In reply to Germano Massullo from comment #1)
> > It's already branched, but keepassxc cannot build because following
> > dependencies are missing
> > libyubikey-devel
> > ykpers-devel
> > 
> > https://koji.fedoraproject.org/koji/taskinfo?taskID=85007268
> 
> Germano, just wondering, have you tried compiling it with
> -DWITH_XC_YUBIKEY=OFF ... that should exclude the ykcore code, and allow for
> a release without Yubikey support, at least until the ykcore issue is
> resolved.

No I will not do that, I am sorry.

Germ(In reply to Germano Massullo from comment #3)
> No I will not do that, I am sorry.

I can certainly empathize with why, as users accustomed to YubiKey support won't know why it isn't working, and that could mean additional bug reports.

Can you tell me if the blockers are being actively worked on by someone, and if there is a guesstimate on when those issues will be overcome?

This is one of several critical packages for myself, and the people I work with and it's keeping us from migrating from v8 to v9. Having a time frame will make it easier to decide if I should dive into the rabbit hole, and build a substitute, or just delay the migration until these blockers are resolved, and an EPEL package is available.

Thanks.

For what it is worth, I installed keepassxc on EL9 via flatpak.  ( org.keepassxc.KeePassXC )

I had to modify the launcher and drop they db on it the first time.
/usr/bin/flatpak run --branch=stable --arch=aarch64 --command=keepassxc --filesystem=/path/to/keepass/key/dbs --file-forwarding org.keepassxc.KeePassXC @@ %f @@

After that it remembered it.

I noticed that libyubikey and ykpers bugs have been resolved, so I attempted another scratch build.

https://koji.fedoraproject.org/koji/taskinfo?taskID=88622686

It failed because of minizip-devel not being available, so I've linked that request to this bug.

The good news is that new people have stepped up to maintain the minizip package. They were approved, and given access early this morning, so it shou;dn't be much longer (hopefully). 

But I had an issue arise, that wouldn't wait. So I built the RPMs myself. I'm attaching those RPMs, and a script, in case you want to build these RPMs yourself. I used the generic/alma9 Vagrant box (aka virtual machine image) for libvirt to run the attached script, but any of the images available here should work:

https://app.vagrantup.com/generic/boxes/alma9/versions/4.0.2

L~

Created attachment 1895256 [details]
keepassxc-2.7.1-4.el9.x86_64.rpm

Created attachment 1895257 [details]
minizip-3.0.2-6.el9.x86_64.rpm

Created attachment 1895258 [details]
minizip-devel-3.0.2-6.el9.x86_64.rpm

Created attachment 1895260 [details]
The script used to build the previously uploaded RPMs.

Germano Massullo, you might want to take note that I had define the fedora RPM macro to make it work. When you goto build the official packages, you'll want to add a logic branch to the SPEC file instead.

(In reply to Ladar Levison from comment #11)
> Created attachment 1895260 [details]
> The script used to build the previously uploaded RPMs.
> 
> Germano Massullo, you might want to take note that I had define the fedora
> RPM macro to make it work. When you goto build the official packages, you'll
> want to add a logic branch to the SPEC file instead.

I don't understand, I am sorry

I believe Ladar is pointing out that the current rawhide spec file doesn't build for el9 due to logic such as `%if 0%{?fedora}`.  Defining the fedora macro is a workaround to avoid editing the spec file.  I've sent a pull request to fix the spec file so it can be built directly for epel9.

https://src.fedoraproject.org/rpms/keepassxc/pull-request/3

Carl is correct - and far better at specfile macro logic than myself. So thank you. 

P.S. Carl, did you get my email on Friday, or did it goto your spam folder?

Yessir, I got it, just haven't had a chance to reply yet.

FEDORA-EPEL-2022-847391ca13 has been submitted as an update to Fedora EPEL 9. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-847391ca13

FEDORA-EPEL-2022-847391ca13 has been pushed to the Fedora EPEL 9 testing repository.

You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-847391ca13

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-EPEL-2022-847391ca13 has been pushed to the Fedora EPEL 9 stable repository.
If problem still persists, please make note of it in this bug report.