Description of problem: The package p11-kit-trust (i686) is not signed, and therefore yum fails to update the p11-kit packages. It is the only p11-kit unsigned package for i686; they are all signed for x86_64.
Bummer. Not sure why that's the case. Reassigning, as the maintainers don't sign our own individual packages.
Can you provide the output and exact version of the package you are seeing?
It was about version 0.18.5-1.fc19.i686 Now yum cannot even find it. Downloading it directly from download.fedoraproject.org, checking it and... it is signed! Well, after dowloading the packages, I can install them. But yum still does not find p11-kit-trust.i686. Even after a 'yum clean all', the output of the command 'yum reinstall p11-kit-trust.i686' is Installed package p11-kit-trust-0.18.5-1.fc19.i686 (from /p11-kit-trust-0.18.5-1.fc19.i686) not available. Error: Nothing to do I have updated the summary. Actually, the problem is that I cannot get this package with yum, even on another machine. Does it work for you, or is it just me?
Are you on a x86_64 install there? The 32bit p11-kit-trust is not shipped in the x86_64 repos. At least not currently. Why do you need it? The "from /p11-kit-trust-0.18.5-1.fc19.i686" also implies that you manually downloaded and installed it, or it would say "from updates" or the like. IMHO, you can safely 'yum remove p11-kit-trust-0.18.5-1.fc19.i686'
It's needed for the use of 'Shared System Certificates' in nss.i686 See: https://fedoraproject.org/wiki/Features/SharedSystemCertificates p11-kit-trust.i686 should be available in x86_64. How can we accomplish this in Fedora?
Yes, it is an x86_64 installation. After searching through yum history, it was indeed installed manually. I cannot find why it was required, and I cannot remember what required it. Ok, I have removed it (no dependancies, great!). Thank you very much for the help. You can close this report for my part.
great. Thanks!
It *is* a bug that p11-kit-trust.i686 is not available in Fedora. This will continue to come up.
ok, can you explain why? Where do you use 32bit nss on 64 bit fedora installs?
(In reply to Kevin Fenzi from comment #9) > ok, can you explain why? > > Where do you use 32bit nss on 64 bit fedora installs? Lots of packages depend on either nss.i686 and gnutls.i686. I've put together a rough list below, using repoquery on my x86_64 machine. As far as an actual use case, I know that 'yum install wine' requires a bunch of the i686 stack, including gnutls.i686. That's just one use case I've personally bumped into. In order to work with the 'Shared System Certificates' both nss and gnutls (optionally) use p11-kit-trust to provide Certificate Anchor data. It is a module that provides a store of trust data. The list: 389-admin-0:1.1.31-1.fc19.2.i686 389-adminutil-0:1.1.15-3.fc19.1.i686 389-ds-base-libs-0:1.3.1.2-1.fc19.i686 389-ds-base-libs-0:1.3.1.3-1.fc19.i686 bitlbee-0:3.2-3.fc19.i686 canl-c++-0:1.0.0-2.fc19.i686 connman-0:1.13-1.fc19.i686 coolkey-0:1.1.0-23.fc19.i686 corosynclib-0:2.3.0-3.fc19.i686 corosynclib-0:2.3.1-1.fc19.i686 cups-libs-1:1.6.2-9.fc19.i686 ecryptfs-utils-0:103-2.fc19.i686 evolution-0:3.8.3-2.fc19.i686 evolution-0:3.8.4-2.fc19.i686 evolution-data-server-0:3.8.3-1.fc19.i686 evolution-data-server-0:3.8.4-1.fc19.i686 evolution-ews-0:3.8.3-1.fc19.i686 evolution-mapi-0:3.8.3-1.fc19.i686 evolution-mapi-0:3.8.4-1.fc19.i686 folks-1:0.9.2-3.fc19.i686 freeDiameter-0:1.1.6-1.fc19.i686 freetds-0:0.91-6.gitf3ae29d.fc19.i686 ggz-base-libs-0:0.99.5-12.fc19.i686 giggle-0:0.7-2.fc19.i686 gloox-1:1.0-5.11.fc19.i686 gnustep-base-libs-0:1.24.4-7.fc19.i686 gnutls-c++-0:3.1.11-1.fc19.i686 gnutls-dane-0:3.1.11-1.fc19.i686 gnutls-devel-0:3.1.11-1.fc19.i686 gtk-vnc-0:0.5.2-1.fc19.i686 gtk-vnc2-0:0.5.2-1.fc19.i686 gvnc-0:0.5.2-1.fc19.i686 gvncpulse-0:0.5.2-1.fc19.i686 gwenhywfar-0:4.3.3-1.fc19.i686 gwenhywfar-gui-qt4-0:4.3.3-1.fc19.i686 iksemel-0:1.4-6.fc19.i686 jana-0:0.4.5-0.30.20100520gitacd72f2.fc19.i686 lftp-0:4.4.6-1.fc19.i686 lftp-0:4.4.8-1.fc19.i686 libcacard-2:1.4.2-3.fc19.i686 libcacard-2:1.4.2-4.fc19.i686 libcurl-0:7.29.0-6.fc19.i686 libcurl-0:7.29.0-7.fc19.i686 libepc-0:0.4.0-5.fc19.i686 libepc-ui-0:0.4.0-5.fc19.i686 libetpan-0:1.1-5.fc19.i686 libfprint-0:0.5.0-2.fc19.i686 libgadu-0:1.11.2-1.fc19.1.i686 libgpod-0:0.8.2-9.fc19.i686 libguestfs-1:1.22.2-1.fc19.i686 libguestfs-1:1.22.5-1.fc19.i686 libimobiledevice-0:1.1.5-1.fc19.i686 libinfinity-0:0.5.3-2.fc19.i686 libinfinity-gtk-0:0.5.3-2.fc19.i686 libmicrohttpd-0:0.9.27-1.fc19.i686 liboauth-0:0.9.7-2.fc19.i686 libprelude-1:1.0.0-17.fc19.i686 libpreludedb-1:1.0.0-16.fc19.i686 libprelude-devel-1:1.0.0-17.fc19.i686 libpurple-0:2.10.7-2.fc19.i686 libpurple-0:2.10.7-3.fc19.i686 libtpms-0:0.5.1-17.fc19.i686 libvirt-client-0:1.0.5.1-1.fc19.i686 libvirt-client-0:1.0.5.4-1.fc19.i686 libvmime-0:0.9.2-0.6.20130320git.fc19.i686 libvncserver-0:0.9.9-7.fc19.i686 libxradius-0:0.4.6-17.fc19.i686 loudmouth-0:1.4.3-12.fc19.i686 mate-settings-daemon-0:1.6.0-2.fc19.i686 mate-settings-daemon-0:1.6.1-2.fc19.i686 mod_revocator-0:1.0.3-15.fc19.i686 mod_revocator-0:1.0.3-17.fc19.i686 neon-0:0.29.6-6.fc19.i686 net6-0:1.3.14-4.fc19.i686 NetworkManager-1:0.9.8.2-2.fc19.i686 NetworkManager-1:0.9.8.2-8.git20130709.fc19.i686 NetworkManager-glib-1:0.9.8.2-2.fc19.i686 NetworkManager-glib-1:0.9.8.2-8.git20130709.fc19.i686 nntpgrab-core-0:0.7.2-4.fc19.i686 nordugrid-arc-0:3.0.1-1.fc19.i686 nordugrid-arc-0:3.0.2-1.fc19.i686 nordugrid-arc-plugins-globus-0:3.0.1-1.fc19.i686 nordugrid-arc-plugins-globus-0:3.0.2-1.fc19.i686 nss_compat_ossl-0:0.9.6-5.fc19.i686 nss-devel-0:3.15.1-2.fc19.i686 nuxwdog-0:1.0.1-7.fc19.i686 openconnect-0:5.01-1.fc19.i686 openldap-0:2.4.35-4.fc19.i686 openldap-0:2.4.35-5.fc19.i686 openvas-libraries-0:6.0-3.beta5.fc19.i686 pacemaker-cluster-libs-0:1.1.9-0.1.70ad9fa.git.fc19.i686 pacemaker-cluster-libs-0:1.1.9-3.fc19.i686 pacemaker-libs-0:1.1.9-0.1.70ad9fa.git.fc19.i686 pacemaker-libs-0:1.1.9-3.fc19.i686 pam_pkcs11-0:0.6.2-10.fc19.i686 pcp-libs-0:3.8.0-1.fc19.i686 pcp-libs-0:3.8.2-1.fc19.i686 pki-tps-0:10.0.3-1.fc19.i686 qpid-cpp-client-ssl-0:0.20-6.fc19.i686 qpid-cpp-client-ssl-0:0.22-1.1.fc19.i686 redhat-lsb-submod-security-0:4.1-14.fc19.i686 rpm-build-libs-0:4.11.0.1-2.fc19.i686 rpm-build-libs-0:4.11.1-1.fc19.i686 rpm-devel-0:4.11.0.1-2.fc19.i686 rpm-devel-0:4.11.1-1.fc19.i686 rpm-libs-0:4.11.0.1-2.fc19.i686 rpm-libs-0:4.11.1-1.fc19.i686 spice-glib-0:0.19-1.fc19.i686 spice-glib-0:0.20-2.fc19.i686 spice-gtk-0:0.19-1.fc19.i686 spice-gtk-0:0.20-2.fc19.i686 spice-gtk3-0:0.19-1.fc19.i686 spice-gtk3-0:0.20-2.fc19.i686 suricata-0:1.4.1-1.fc19.i686 svrcore-0:4.0.4-9.fc19.i686 syncevolution-libs-1:1.3.99.3-1.fc19.i686 systemtap-devel-0:2.2.1-1.fc19.i686 volume_key-libs-0:0.3.9-3.fc19.i686 wine-core-0:1.5.27-1.fc19.i686 wine-core-0:1.6-1.fc19.i686 wireshark-0:1.10.0-2.fc19.i686 xmlsec1-gnutls-0:1.2.18-4.fc19.i686 xmlsec1-nss-0:1.2.18-4.fc19.i686 xulrunner-0:21.0-8.fc19.i686 xulrunner-0:22.0-4.fc19.i686
it will be included in the tree if its needed by dependencies. if nss or gnutls need it they need to require it.
Dennis, PKCS#11 modules are like plugins. They provide functionality to PKCS#11 consumers. In this case the p11-kit-trust PKCS#11 module provides support for enumerating installed anchors and blacklists.
Is there a way to explicitly declare a package multilib (in comps or somewhere else?).
Yes, in mash. See: https://git.fedorahosted.org/cgit/mash/tree/mash/multilib.py Looks like we want to mark any package that places files in /usr/lib{,64}/pkcs11/ ?
We had failed to follow up after Bill's comment, and to confirm his question. Sorry. This issue just came up again in bug 1060764. Yes, I'd agree with comment 14, any package that places files into /usr/lib{,64}/pkcs11/ should be build for all arches on a multilib arch. How can we make that happen? Who is able to make that change to the mash multilib.py script? Thanks in advance!
*** Bug 1060764 has been marked as a duplicate of this bug. ***
This message is a notice that Fedora 19 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 19. It is Fedora's policy to close all bug reports from releases that are no longer maintained. Approximately 4 (four) weeks from now this bug will be closed as EOL if it remains open with a Fedora 'version' of '19'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 19 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.
This issue still frustrates me, so I'll open it. The issue is the inconsistency. We advertise the ability to install a CA for systemwide use by most applications, but because p11-kit-trust.i686 is missing, NSS.i686 and GnuTLS.i686 applications don't get the CAs the admin has installed. I wonder why we haven't gotten more bug reports about this issue. Is nobody using 32-bit applications any more for SSL/TLS? Let's try the suggestion from comment 11. I see that on Fedora 25, it's no longer possible to uninstall the primary p11-kit-trust.rpm package, as several important packages depend on it (sudo/systemd/dnf/systemd-udev). How about a new "dummy" nss subpackage, that installs nothing, but requires p11-kit-trust? Would that be sufficient to get it into the compose, even if that NSS subpackage usually isn't installed?
Created attachment 1304347 [details] experimental patch v1 Daiki, how about adding something like this attachment to the nss package (rawhide for testing it)? Here is a scratch build: https://koji.fedoraproject.org/koji/taskinfo?taskID=20725696 I was able to install it locally in a rawhide VM (excluding the new dummy package). If I understand correctly, as soon as we build this in koji, the fedora compose will include p11-kit-trust.i686?
So, this is actually in the pungi whitelist, so it should be included: https://pagure.io/pungi-fedora/blob/master/f/fedora.conf#_182 and indeed I see it there: http://dl.fedoraproject.org/pub/fedora/linux/development/rawhide/Everything/x86_64/os/Packages/p/p11-kit-0.23.7-1.fc27.i686.rpm So, whats still wrong here?
It was fixed recently by rel-eng as part of bug 1456239: https://pagure.io/releng/issue/6855 though it's only for Fedora 26 or later. The dependency based approach was also attempted in the gnutls package, but it apparently didn't work and caused some other issues, according to Nikos: http://pkgs.fedoraproject.org/cgit/rpms/gnutls.git/commit/?id=5651d6db313d5d2a15f7efe6b05c7eb85cfdb30b I would suggest to ensure that the dependency based approach is supposed to work and doesn't cause any problem, if the approach is preferable. On a bit different note, I think every package which contains a PKCS#11 module (i.e. *.so file under %_libdir/pkcs11/) should be marked as multilib. Isn't it possible to implement it in the compose tool?
And isn't the situation such that adding the requires to a package is not sufficient for making the package multilib - but that was already solved by the pungi whitelist. And now we actually need to pull the package in on the install - which basically means the gnutls and/or nss should now get the arch specific requires and it should not cause any problems anymore because the package is now in the repository.
This bug is currently reported against a Fedora version which is already unsuported. I am changing the version to '27', the latest supported release. Please check whether this bug is still an issue on the '27' release. If you find this bug not being applicable on this release, please close it.
Now that the i686 package is available in the repo, I am closing this.