On Fri, 2016-07-22 at 17:17 +0300, Antti Järvinen wrote: > Tomas Mraz writes: > > for anybody insterested in testing and/or porting applications to the > > new OpenSSL 1.1.0 API I've prepared a COPR repository: > > Strongly advised, OpenSSL 1.1 API changes slightly compared to 1.0 and > at least in debian the list of packages not compiling any more was rather > impressive, see > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=827061 > and I'd expect something similar in other distributions too. Mostly > this is head-ache of upstreams but it might be good manners to file > upstream error tickets early :) Second, I was given a heads up about failing packages by an Ubuntu maintainer of upstream projects of mine, and I had to change every single one of them. I haven't rebuild all of them yet for Fedora either because the changes do not work at run time, I have to wait until Feodra Rawhide gets 1.1.0 anyway. So please land this as early as possible in Fedora as it will require to

On Pá, 2016-07-22 at 10:24 -0400, Simo Sorce wrote: > On Fri, 2016-07-22 at 10:21 -0400, Simo Sorce wrote: > > > > On Fri, 2016-07-22 at 17:17 +0300, Antti Järvinen wrote: > > > > > > Tomas Mraz writes: > > > > for anybody insterested in testing and/or porting applications > > > to the > > > > new OpenSSL 1.1.0 API I've prepared a COPR repository: > > > > > > Strongly advised, OpenSSL 1.1 API changes slightly compared to > > > 1.0 and > > > at least in debian the list of packages not compiling any more > > > was rather > > > impressive, see > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=827061 > > > and I'd expect something similar in other distributions too. > > > Mostly > > > this is head-ache of upstreams but it might be good manners to > > > file > > > upstream error tickets early :) > > Second, I was given a heads up about failing packages by an Ubuntu > > maintainer of upstream projects of mine, and I had to change every > > single one of them. I haven't rebuild all of them yet for Fedora > > either > > because the changes do not work at run time, I have to wait until > > Feodra > > Rawhide gets 1.1.0 anyway. > > > > So please land this as early as possible in Fedora as it will > > require to > Actually , given how disruptive this is going to be we may want to > think > of creating a separate tag and rebuild the majority of core packages > that break there and only then tag it at once in rawhide, or rawhide > user experience will be miserable until all package maintainers get > around to fix it. My current plan (might be changed) is to: 1. Fill Fedora Change proposal for Fedora 26 very early. 2. Add compat 1.0.2 package which would be used by 3rd party applications and also temporarily by applications that are not yet ported to the new API. However the current plan is to not provide -devel subpackage for 1.0.2 compat packages so if you needed to rebuild something on rawhide you would have to fix the build issues with the new openssl. The tag should not be strictly necessary and I'd like to avoid it as rawhide with the compat package should be installable and relatively usable. Only the developers that use OpenSSL API calls would have to patch their code.

the only safe way to provide a compat openssl package is as a -devel package that only contains a static library :P

On Fri, 2016-07-22 at 19:11 +0200, Michael Stahl wrote: > urgh, yes, that's practically guaranteed to crash LibreOffice which > could pull in openssl via neon, python-stmp, postgresql-libs, > openldap, > curl, librdf, any gnome-vfs backend, and probably other ways i'm not > aware of. As long as the symbols of both libraries are versioned, that should cause no problem (in theory).