Re: Unannounced soname bump: openssl-pkcs11 (libp11.so.3 -> libp11.so.4) affects nextcloud-client-libs, rng-tools
Jakub Jelen via devel <[email protected]> Wed, 29 Jul 2026 12:29:29 +0200
| Newsgroups | gmane.linux.redhat.fedora.devel |
|---|---|
| Message-ID | <CAHrFiA-S5D-1U6CxXzmCtXZ+xZ0fEhMh4-1NKg_DTW2GFmbJhA@mail.gmail.com> |
--===============0766125163130639729== Content-Type: multipart/alternative; boundary="000000000000df4d990657bd6e1a" --000000000000df4d990657bd6e1a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks, I pushed the update of openssl-pkcs11 and rng-tools from the side tag now: https://bodhi.fedoraproject.org/updates/FEDORA-2026-de533c0933 The nextcloud-client will still likely have some issues as it will build against openssl3, but use the libp11 built against openssl4, but I am really not sure if it will explode already during the build or some time later at runtime. Jakub On Tue, Jul 28, 2026 at 5:04=E2=80=AFPM Adam Williamson <adamwill@fedorapro= ject.org> wrote: > On Tue, 2026-07-28 at 14:12 +0200, Jakub Jelen wrote: > > Thank you! > > > > Given that we still did not hear from the nextcloud-client maintainer > over > > the last week, to unblock this we will need either proven packager or t= he > > co-maintainer to get this merged and built. > > You're allowed to just go ahead and do the update with only openssl- > pkcs11 and rng-tools if you can't get nextcloud-client done after > reasonable effort (btw, this is the sort of situation that makes me > hesitant to gate Rawhide on rmdepcheck results). But I'll go ahead and > use pp powers to deal with it today I guess. > -- > Adam Williamson (he/him/his) > Fedora QA > Fedora Chat: @adamwill:fedora.im | Mastodon: @[email protected] > https://www.happyassassin.net > > > > --000000000000df4d990657bd6e1a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div>Thanks,</div><div><br></div><div>I pushed the update = of openssl-pkcs11 and rng-tools from the=C2=A0side tag now:</div><div><br><= /div><div><a href=3D"https://bodhi.fedoraproject.org/updates/FEDORA-2026-de= 533c0933">https://bodhi.fedoraproject.org/updates/FEDORA-2026-de533c0933</a= ></div><div><br></div><div>The nextcloud-client will still likely have some= issues as it will build against openssl3, but use the libp11 built against= openssl4, but I am really not sure if it will explode already during the b= uild or some time later at runtime.</div><div><br></div><div>Jakub</div></d= iv><br><div class=3D"gmail_quote gmail_quote_container"><div dir=3D"ltr" cl= ass=3D"gmail_attr">On Tue, Jul 28, 2026 at 5:04=E2=80=AFPM Adam Williamson = <<a href=3D"mailto:[email protected]">[email protected]= g</a>> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin= :0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"= >On Tue, 2026-07-28 at 14:12 +0200, Jakub Jelen wrote:<br> > Thank you!<br> > <br> > Given that we still did not hear from the nextcloud-client maintainer = over<br> > the last week, to unblock this we will need either proven packager or = the<br> > co-maintainer to get this merged and built.<br> <br> You're allowed to just go ahead and do the update with only openssl-<br= > pkcs11 and rng-tools if you can't get nextcloud-client done after<br> reasonable effort (btw, this is the sort of situation that makes me<br> hesitant to gate Rawhide on rmdepcheck results). But I'll go ahead and<= br> use pp powers to deal with it today I guess.<br> -- <br> Adam Williamson (he/him/his)<br> Fedora QA<br> Fedora Chat: @adamwill:<a href=3D"http://fedora.im" rel=3D"noreferrer" targ= et=3D"_blank">fedora.im</a> | Mastodon: @<a href=3D"mailto:adamw@fosstodon.= org" target=3D"_blank">[email protected]</a><br> <a href=3D"https://www.happyassassin.net" rel=3D"noreferrer" target=3D"_bla= nk">https://www.happyassassin.net</a><br> <br> <br> <br> </blockquote></div> --000000000000df4d990657bd6e1a-- --===============0766125163130639729== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline LS0gCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCmRldmVs IG1haWxpbmcgbGlzdCAtLSBkZXZlbEBsaXN0cy5mZWRvcmFwcm9qZWN0Lm9yZwpUbyB1bnN1YnNj cmliZSBzZW5kIGFuIGVtYWlsIHRvIGRldmVsLWxlYXZlQGxpc3RzLmZlZG9yYXByb2plY3Qub3Jn CkZlZG9yYSBDb2RlIG9mIENvbmR1Y3Q6IGh0dHBzOi8vZG9jcy5mZWRvcmFwcm9qZWN0Lm9yZy9l bi1VUy9wcm9qZWN0L2NvZGUtb2YtY29uZHVjdC8KTGlzdCBHdWlkZWxpbmVzOiBodHRwczovL2Zl ZG9yYXByb2plY3Qub3JnL3dpa2kvTWFpbGluZ19saXN0X2d1aWRlbGluZXMKTGlzdCBBcmNoaXZl czogaHR0cHM6Ly9saXN0cy5mZWRvcmFwcm9qZWN0Lm9yZy9hcmNoaXZlcy9saXN0L2RldmVsQGxp c3RzLmZlZG9yYXByb2plY3Qub3JnCkRvIG5vdCByZXBseSB0byBzcGFtLCByZXBvcnQgaXQ6IGh0 dHBzOi8vZm9yZ2UuZmVkb3JhcHJvamVjdC5vcmcvaW5mcmEvdGlja2V0cy9pc3N1ZXMvbmV3Cg== --===============0766125163130639729==--