Bug 1332456 - Build java-1.8.0-openjdk-1.8.0.91-2.b14.fc23 breaks tomcat startup for FreeIPA when nss is not upgraded as well
Summary: Build java-1.8.0-openjdk-1.8.0.91-2.b14.fc23 breaks tomcat startup for FreeIP...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: java-1.8.0-openjdk
Version: 23
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: jiri vanek
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 1332867 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-05-03 09:03 UTC by Jan Pazdziora
Modified: 2016-05-16 16:19 UTC (History)
12 users (show)

Fixed In Version: java-1.8.0-openjdk-1.8.0.91-5.b14.fc23 java-1.8.0-openjdk-1.8.0.91-5.b14.fc24
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-05-15 05:24:46 UTC


Attachments (Terms of Use)

Description Jan Pazdziora 2016-05-03 09:03:38 UTC
Description of problem:

On my FreeIPA installation (which happens to be in container but that should not matter), packages used are

nss-3.22.2-1.0.fc23.x86_64
java-1.8.0-openjdk-1.8.0.91-2.b14.fc23

With them, tomcat does not start so pki-ca-spawn fails.

Version-Release number of selected component (if applicable):

nss-3.22.2-1.0.fc23.x86_64
java-1.8.0-openjdk-1.8.0.91-2.b14.fc23

How reproducible:

Deterministic.

Steps to Reproduce:
1. Install freeipa-server, make sure you have the package versions as above.
2. Run ipa-server-install.

Actual results:

Configuring certificate server (pki-tomcatd). Estimated time: 3 minutes 30 seconds
  [1/27]: creating certificate server user
  [2/27]: configuring certificate server instance
ipa.ipaserver.install.cainstance.CAInstance: CRITICAL Failed to configure CA instance: Command ''/usr/sbin/pkispawn' '-s' 'CA' '-f' '/tmp/tmpQSaQPY'' returned non-zero exit status 1
ipa.ipaserver.install.cainstance.CAInstance: CRITICAL See the installation logs and the following files/directories for more information:
ipa.ipaserver.install.cainstance.CAInstance: CRITICAL   /var/log/pki-ca-install.log
ipa.ipaserver.install.cainstance.CAInstance: CRITICAL   /var/log/pki/pki-tomcat
  [error] RuntimeError: CA configuration failed.
ipa.ipapython.install.cli.install_tool(Server): ERROR    CA configuration failed.

Expected results:

Configuring certificate server (pki-tomcatd). Estimated time: 3 minutes 30 seconds
  [1/27]: creating certificate server user
  [2/27]: configuring certificate server instance
  [3/27]: stopping certificate server instance to update CS.cfg
  [4/27]: backing up CS.cfg
  [5/27]: disabling nonces
  [6/27]: set up CRL publishing
  [7/27]: enable PKIX certificate path discovery and validation
  [8/27]: starting certificate server instance
  [9/27]: creating RA agent certificate database

Additional info:

I was able to make things work by either

- downgrade to java-1.8.0-openjdk-1.8.0.91-1.b14.fc23, or
- upgrade to nss-3.23.0-1.0.fc23.x86_64.

So it seems java build -2.b14 is not happy with nss 3.22.2. Either java changed something (and potentially should require the new nss to force upgrade), or nss changed something (and perhaps should have bumped soname).

Comment 1 Jan Pazdziora 2016-05-03 09:07:52 UTC
Adding Elio for awareness.

Comment 2 jiri vanek 2016-05-03 09:34:22 UTC
Openjdk packages should depend exactly on the same version of NSS they were build against. Currently I don't know how to implement this properly automatically. 
Appearently rpms autogenerated soname depndenci is not enough

Second - more serious issue is, what troubles can cause dependency on exact version of NSS. At worst, It may lock system to prevent updates of NSS.  If >= will be used, then it may hit this bug again.

Comment 3 jiri vanek 2016-05-03 10:49:25 UTC
Testing with:


--- a/java-1.8.0-openjdk.spec
+++ b/java-1.8.0-openjdk.spec
@@ -95,6 +95,8 @@
 %global NSS_LIBDIR %(pkg-config --variable=libdir nss)
 %global NSS_LIBS %(pkg-config --libs nss)
 %global NSS_CFLAGS %(pkg-config --cflags nss-softokn)
+# see https://bugzilla.redhat.com/show_bug.cgi?id=1332456
+%global NSS_BUILDTIME_VERSION %(rpm -q nss | grep `uname -i` | sed s/.`uname -i`//  | sed s/nss-//)
 
 # fix for https://bugzilla.redhat.com/show_bug.cgi?id=1111349
 %global _privatelibs libmawt[.]so.*
@@ -666,6 +668,8 @@ Requires: javapackages-tools
 Requires: tzdata-java >= 2015d
 # libsctp.so.1 is being `dlopen`ed on demand
 Requires: lksctp-tools
+# there is need to depnd on exact version of nss
+Requires: nss >= %{NSS_BUILDTIME_VERSION}
 # tool to copy jdk's configs - should be Recommends only, but then only dnf/yum eforce it, not rpm transaction and so no configs are persisted when pure rpm -u is run. I t may be consiedered as regression
 Requires:      copy-jdk-configs >= 1.1-3
 OrderWithRequires: copy-jdk-configs

Comment 4 Andrew John Hughes 2016-05-03 11:54:55 UTC
(In reply to jiri vanek from comment #3)
> Testing with:
> 
> 
> --- a/java-1.8.0-openjdk.spec
> +++ b/java-1.8.0-openjdk.spec
> @@ -95,6 +95,8 @@
>  %global NSS_LIBDIR %(pkg-config --variable=libdir nss)
>  %global NSS_LIBS %(pkg-config --libs nss)
>  %global NSS_CFLAGS %(pkg-config --cflags nss-softokn)
> +# see https://bugzilla.redhat.com/show_bug.cgi?id=1332456
> +%global NSS_BUILDTIME_VERSION %(rpm -q nss | grep `uname -i` | sed
> s/.`uname -i`//  | sed s/nss-//)
>  
>  # fix for https://bugzilla.redhat.com/show_bug.cgi?id=1111349
>  %global _privatelibs libmawt[.]so.*
> @@ -666,6 +668,8 @@ Requires: javapackages-tools
>  Requires: tzdata-java >= 2015d
>  # libsctp.so.1 is being `dlopen`ed on demand
>  Requires: lksctp-tools
> +# there is need to depnd on exact version of nss
> +Requires: nss >= %{NSS_BUILDTIME_VERSION}
>  # tool to copy jdk's configs - should be Recommends only, but then only
> dnf/yum eforce it, not rpm transaction and so no configs are persisted when
> pure rpm -u is run. I t may be consiedered as regression
>  Requires:      copy-jdk-configs >= 1.1-3
>  OrderWithRequires: copy-jdk-configs


%global NSS_BUILDTIME_VERSION %(pkg-config --modversion nss-softokn) would be simpler. Either way, we need to check nss-softokn as well, as the two can be different, and it's softokn that provides the freebl library.

$ rpm -q nss-softokn
nss-softokn-3.16.2.3-13.el7_1.x86_64
$ rpm -q nss
nss-3.19.1-19.el7_2.x86_64

SunEC link step:

/usr/bin/g++ -Wl,--as-needed -Wl,-O1 -Wl,--hash-style=gnu -Wl,--sort-common -fuse-ld=gold -Xlinker -z -Xlinker defs -Xlinker -O1 -shared -L/home/andrew/builder/icedtea8/openjdk.build-boot/jdk/lib/amd64 -L/home/andrew/builder/icedtea8/openjdk.build-boot/jdk/lib/amd64/server   -Xlinker -version-script=/home/andrew/builder/icedtea8/openjdk-boot/jdk/make/mapfiles/libsunec/mapfile-vers -Xlinker -soname=libsunec.so -o /home/andrew/builder/icedtea8/openjdk.build-boot/jdk/lib/amd64/libsunec.so /home/andrew/builder/icedtea8/openjdk.build-boot/jdk/objs/libsunec/ECC_JNI.o  -lstdc++  -lc -lfreebl -lssl3 -lsmime3 -lnss3 -lnssutil3 -lplds4 -lplc4 -lnspr4

Comment 5 jiri vanek 2016-05-03 12:01:40 UTC
(In reply to jiri vanek from comment #2)
> Openjdk packages should depend exactly on the same version of NSS they were
> build against. Currently I don't know how to implement this properly
> automatically. 
> Appearently rpms autogenerated soname depndenci is not enough
> 
> Second - more serious issue is, what troubles can cause dependency on exact
> version of NSS. At worst, It may lock system to prevent updates of NSS.  If
> >= will be used, then it may hit this bug again.

Another danger is, that once openjdk is built in brew agianst some exactversion of NSS, then one can not update Openjdk, before also NSS reach stbale. And NSS is updated pretty often...

Comment 6 jiri vanek 2016-05-03 12:03:29 UTC
> %global NSS_BUILDTIME_VERSION %(pkg-config --modversion nss-softokn) would

Thanx

> be simpler. Either way, we need to check nss-softokn as well, as the two can
> be different, and it's softokn that provides the freebl library.

Are you sure with "as well"? I would say only nss-softokn, then?
> 
> $ rpm -q nss-softokn
> nss-softokn-3.16.2.3-13.el7_1.x86_64
> $ rpm -q nss
> nss-3.19.1-19.el7_2.x86_64
> 

Still I'm very afraid to push this change.

Comment 7 jiri vanek 2016-05-03 12:26:23 UTC
diff --git a/java-1.8.0-openjdk.spec b/java-1.8.0-openjdk.spec
index 1bb855a..c372812 100644
--- a/java-1.8.0-openjdk.spec
+++ b/java-1.8.0-openjdk.spec
@@ -95,6 +95,9 @@
 %global NSS_LIBDIR %(pkg-config --variable=libdir nss)
 %global NSS_LIBS %(pkg-config --libs nss)
 %global NSS_CFLAGS %(pkg-config --cflags nss-softokn)
+# see https://bugzilla.redhat.com/show_bug.cgi?id=1332456
+%global NSSSOFTOKN_BUILDTIME_VERSION %(pkg-config --modversion nss-softokn)
+%global NSS_BUILDTIME_VERSION %(pkg-config --modversion nss)
 
 # fix for https://bugzilla.redhat.com/show_bug.cgi?id=1111349
 %global _privatelibs libmawt[.]so.*
@@ -666,6 +669,9 @@ Requires: javapackages-tools
 Requires: tzdata-java >= 2015d
 # libsctp.so.1 is being `dlopen`ed on demand
 Requires: lksctp-tools
+# there is need to depnd on exact version of nss
+Requires: nss >= %{NSS_BUILDTIME_VERSION}
+Requires: nss-softokn >= %{NSSSOFTOKN_BUILDTIME_VERSION}
 # tool to copy jdk's configs - should be Recommends only, but then only dnf/yum eforce it, not rpm transaction and so no configs are persisted when pure rpm -u is run. I t may be consiedered as regression
 Requires:      copy-jdk-configs >= 1.1-3
 OrderWithRequires: copy-jdk-configs

Comment 8 jiri vanek 2016-05-03 12:27:45 UTC
This approach
> +# see https://bugzilla.redhat.com/show_bug.cgi?id=1332456
> +%global NSSSOFTOKN_BUILDTIME_VERSION %(pkg-config --modversion nss-softokn)
> +%global NSS_BUILDTIME_VERSION %(pkg-config --modversion nss)
> +# there is need to depnd on exact version of nss
> +Requires: nss >= %{NSS_BUILDTIME_VERSION}
> +Requires: nss-softokn >= %{NSSSOFTOKN_BUILDTIME_VERSION}

Do not count release flag of package. Form the locking restrictions it is much better, but from point of this bug.. hard to say if it can bait again.

Comment 9 jiri vanek 2016-05-03 13:42:59 UTC
oook.. pushed to f25. Lest see

Comment 10 Andrew John Hughes 2016-05-03 16:41:54 UTC
(In reply to jiri vanek from comment #6)
> > %global NSS_BUILDTIME_VERSION %(pkg-config --modversion nss-softokn) would
> 
> Thanx
> 
> > be simpler. Either way, we need to check nss-softokn as well, as the two can
> > be different, and it's softokn that provides the freebl library.
> 
> Are you sure with "as well"? I would say only nss-softokn, then?
> > 
> > $ rpm -q nss-softokn
> > nss-softokn-3.16.2.3-13.el7_1.x86_64
> > $ rpm -q nss
> > nss-3.19.1-19.el7_2.x86_64
> > 
> 
> Still I'm very afraid to push this change.

I'm not in favour of it either, I was just making sure you covered all bases if you did push this. Such a change is a kludge to fix what is inherent breakage in the packaging system.

For a package, x, there is a set of build dependencies, y. As I understand it, the issue here is that x was built against y, a subset of which, z, were not yet released in Fedora. Package x was then released before the full set, y, and thus you end up with this problem that x is being run against versions of packages in y that were not those that it was built against.

That's the problem. The fact that, in many cases, problems don't appear because of sonames, missing symbols or just pure luck, is really a band aid around this underlying issue. It's not specific to OpenJDK, nor to Fedora, but a potential problem you will run into in any situation where you run a binary against a different set of dependent binaries to those it was built against.

In contrast, RHEL packages are built against a known set of *released* packages. Exceptions are occasionally made to this, but they come either from a build being pushed to the buildroot from an erratum (which means it's scheduled to go out as part of the associated release) or release management (which I presume know what they're doing in such cases). This bug suggests that Fedora isn't as strict in this regard.

In this case, we know NSS is part of z, but there could be other packages too. The reason we see a problem with NSS is because SunEC is built from a strange cocktail of static and linked libraries. freebl, from nss-softokn, is statically compiled into the provider because that's the only way the EC routines used are provided. However, these routines then called out to shared code in the NSS libraries. Thus, you get an issue like this where the newer freebl used by the OpenJDK build is calling out to an older set of shared NSS libraries.

That wouldn't be possible if OpenJDK wasn't being built against a nss-softokn that hadn't yet been released, as the correct NSS would be picked up either before or at the same time as the OpenJDK update. There are other possible cases where this could cause issues. Imagine some code has behaviour which is dependent on a define in a header file. In many cases, this would be for a new API call and so would be caught by a missing symbol, but it could also be because they wanted to implement different behaviour depending on whether the symbol was present or not, or had a specific value. If one decision is made at build-time based on one header, and then you try to use it at run-time against a different version, you'll again get problems. Not everything can be caught by symbols and sonames, especially as more packages use languages other than C and C++.

What your fix is essentially doing is providing the beginnings of a guarantee that at least the version used to build will be available. That shouldn't be something individual packagers need to do, but something that should be inherent in the way Fedora provides packages to users.

Comment 11 Andrew John Hughes 2016-05-03 16:44:27 UTC
(In reply to jiri vanek from comment #8)
> This approach
> > +# see https://bugzilla.redhat.com/show_bug.cgi?id=1332456
> > +%global NSSSOFTOKN_BUILDTIME_VERSION %(pkg-config --modversion nss-softokn)
> > +%global NSS_BUILDTIME_VERSION %(pkg-config --modversion nss)
> > +# there is need to depnd on exact version of nss
> > +Requires: nss >= %{NSS_BUILDTIME_VERSION}
> > +Requires: nss-softokn >= %{NSSSOFTOKN_BUILDTIME_VERSION}
> 
> Do not count release flag of package. Form the locking restrictions it is
> much better, but from point of this bug.. hard to say if it can bait again.

If something important is differing merely because of the release number, then I'd suggest some serious words with the maintainer of that package. That suggests a significant derivation from the reported upstream version, which I believe goes against Fedora policy.

Comment 12 jiri vanek 2016-05-04 08:34:37 UTC
The mock build did nto behaved as expected. The rewuires are counted in during srpm cration, and in such, no NSS is on the system. Different way must be found.

Comment 13 jiri vanek 2016-05-04 08:41:33 UTC
(In reply to Andrew John Hughes from comment #10)
> (In reply to jiri vanek from comment #6)
> > > %global NSS_BUILDTIME_VERSION %(pkg-config --modversion nss-softokn) would
> > 
> > Thanx
> > 
> > > be simpler. Either way, we need to check nss-softokn as well, as the two can
> > > be different, and it's softokn that provides the freebl library.
> > 
> > Are you sure with "as well"? I would say only nss-softokn, then?
> > > 
> > > $ rpm -q nss-softokn
> > > nss-softokn-3.16.2.3-13.el7_1.x86_64
> > > $ rpm -q nss
> > > nss-3.19.1-19.el7_2.x86_64
> > > 
> > 
> > Still I'm very afraid to push this change.
> 
> I'm not in favour of it either, I was just making sure you covered all bases
> if you did push this. Such a change is a kludge to fix what is inherent
> breakage in the packaging system.
> 
> For a package, x, there is a set of build dependencies, y. As I understand
> it, the issue here is that x was built against y, a subset of which, z, were
> not yet released in Fedora. Package x was then released before the full set,
> y, and thus you end up with this problem that x is being run against
> versions of packages in y that were not those that it was built against.
> 

Yes, that was I realised initial comments.

> That's the problem. The fact that, in many cases, problems don't appear
> because of sonames, missing symbols or just pure luck, is really a band aid
> around this underlying issue. It's not specific to OpenJDK, nor to Fedora,
> but a potential problem you will run into in any situation where you run a
> binary against a different set of dependent binaries to those it was built
> against.
> 
> In contrast, RHEL packages are built against a known set of *released*
> packages. Exceptions are occasionally made to this, but they come either
> from a build being pushed to the buildroot from an erratum (which means it's
> scheduled to go out as part of the associated release) or release management
> (which I presume know what they're doing in such cases). This bug suggests
> that Fedora isn't as strict in this regard.
> 
> In this case, we know NSS is part of z, but there could be other packages
> too. The reason we see a problem with NSS is because SunEC is built from a
> strange cocktail of static and linked libraries. freebl, from nss-softokn,
> is statically compiled into the provider because that's the only way the EC
> routines used are provided. However, these routines then called out to
> shared code in the NSS libraries. Thus, you get an issue like this where the
> newer freebl used by the OpenJDK build is calling out to an older set of
> shared NSS libraries.
> 
> That wouldn't be possible if OpenJDK wasn't being built against a
> nss-softokn that hadn't yet been released, as the correct NSS would be
> picked up either before or at the same time as the OpenJDK update. There are
> other possible cases where this could cause issues. Imagine some code has
> behaviour which is dependent on a define in a header file. In many cases,
> this would be for a new API call and so would be caught by a missing symbol,
> but it could also be because they wanted to implement different behaviour
> depending on whether the symbol was present or not, or had a specific value.
> If one decision is made at build-time based on one header, and then you try
> to use it at run-time against a different version, you'll again get
> problems. Not everything can be caught by symbols and sonames, especially as
> more packages use languages other than C and C++.
> 
> What your fix is essentially doing is providing the beginnings of a
> guarantee that at least the version used to build will be available. That
> shouldn't be something individual packagers need to do, but something that
> should be inherent in the way Fedora provides packages to users.

Well, yes. Yo are right.  As my hack did not worked, I'm currently out of ideas how to fix it.

I dont know if fedora is capable of what you suggested. To restrict buildroots to known released software may be really tricky.

Comment 14 Severin Gehwolf 2016-05-04 11:54:43 UTC
(In reply to jiri vanek from comment #12)
> The mock build did nto behaved as expected. The rewuires are counted in
> during srpm cration, and in such, no NSS is on the system. Different way
> must be found.

Can you clarify what you mean by this? What exactly breaks?

Comment 15 Severin Gehwolf 2016-05-04 11:59:23 UTC
$ rpm -q --requires java-1.8.0-openjdk-headless | grep nss
libnss3.so()(64bit)
libnss3.so(NSS_3.2)(64bit)
libnssutil3.so()(64bit)
libnssutil3.so(NSSUTIL_3.12)(64bit)
$ rpm -q --whatprovides 'libnss3.so()(64bit)'
nss-3.23.0-1.0.fc23.x86_64
$ rpm -q --whatprovides 'libnssutil3.so()(64bit)'
nss-util-3.23.0-1.0.fc23.x86_64
$ rpm -q --whatprovides 'libnssutil3.so(NSSUTIL_3.12)(64bit)'
nss-util-3.23.0-1.0.fc23.x86_64
$ rpm -q --whatprovides 'libnss3.so(NSS_3.2)(64bit)'
nss-3.23.0-1.0.fc23.x86_64

So the auto-requires are not enough, because nss-softokn is not required.

Comment 16 jiri vanek 2016-05-04 12:02:29 UTC
I dont have logs anymore, but generally this is what happened:
declared are:
%global NSS_BUILDTIME_VERSION %(pkg-config --modversion nss)
...
Requires: nss >= %{NSS_BUILDTIME_VERSION}

However - the Requires are recognized during srpm creation, and that is done in minimal buildroot, before buildrequires are installed.
So pkg-config --modversion nss exit with error, no nss installed, and build fails.

if changed to something like:
%global NSS_BUILDTIME_VERSION >= %(pkg-config --modversion nss ||:)
Requires: nss %{NSS_BUILDTIME_VERSION}

Then builds pass, but no correct nss requirement is there.  Ihave now few more ideas to try, so I will investigate.

Generally, what do you think about this issue?

(In reply to Severin Gehwolf from comment #14)
> (In reply to jiri vanek from comment #12)
> > The mock build did nto behaved as expected. The rewuires are counted in
> > during srpm cration, and in such, no NSS is on the system. Different way
> > must be found.
> 
> Can you clarify what you mean by this? What exactly breaks?

Comment 17 jiri vanek 2016-05-04 12:03:15 UTC
(In reply to Severin Gehwolf from comment #15)
> $ rpm -q --requires java-1.8.0-openjdk-headless | grep nss
> libnss3.so()(64bit)
> libnss3.so(NSS_3.2)(64bit)
> libnssutil3.so()(64bit)
> libnssutil3.so(NSSUTIL_3.12)(64bit)
> $ rpm -q --whatprovides 'libnss3.so()(64bit)'
> nss-3.23.0-1.0.fc23.x86_64
> $ rpm -q --whatprovides 'libnssutil3.so()(64bit)'
> nss-util-3.23.0-1.0.fc23.x86_64
> $ rpm -q --whatprovides 'libnssutil3.so(NSSUTIL_3.12)(64bit)'
> nss-util-3.23.0-1.0.fc23.x86_64
> $ rpm -q --whatprovides 'libnss3.so(NSS_3.2)(64bit)'
> nss-3.23.0-1.0.fc23.x86_64
> 
> So the auto-requires are not enough, because nss-softokn is not required.

If I read the versions correctly, then adding requires nss-softoken will not be enough. Why do you think it will be?

Comment 18 jiri vanek 2016-05-04 12:34:20 UTC
jsutfyi:

trying something like:
+# see https://bugzilla.redhat.com/show_bug.cgi?id=1332456
+%global NSSSOFTOKN_BUILDTIME_NUMBER %(pkg-config --modversion nss-softokn || : )
+%global NSS_BUILDTIME_NUMBER %(pkg-config --modversion nss || : )
+#this is worakround for processing of requires during srpm creation
+%global NSSSOFTOKN_BUILDTIME_VERSION %(if [ "x%{NSSSOFTOKN_BUILDTIME_NUMBER}" == "x" ] ; then echo "" ;else echo ">= %{NSSSOFTOKN_BUILDTIME_NUMBER}" ;fi)
+%global NSS_BUILDTIME_VERSION %(if [ "x%{NSS_BUILDTIME_NUMBER}" == "x" ] ; then echo "" ;else echo ">= %{NSS_BUILDTIME_NUMBER}" ;fi)
+
 
 # fix for https://bugzilla.redhat.com/show_bug.cgi?id=1111349
 %global _privatelibs libmawt[.]so.*
@@ -666,6 +673,9 @@ Requires: javapackages-tools
 Requires: tzdata-java >= 2015d
 # libsctp.so.1 is being `dlopen`ed on demand
 Requires: lksctp-tools
+# there is need to depnd on exact version of nss
+Requires: nss %{NSS_BUILDTIME_VERSION}
+Requires: nss-softokn %{NSSSOFTOKN_BUILDTIME_VERSION}


As I'm really not sure how macros are cached between srpm ops, and final rpm ops.

Comment 19 Severin Gehwolf 2016-05-04 12:38:06 UTC
(In reply to jiri vanek from comment #16)
> I dont have logs anymore, but generally this is what happened:
> declared are:
> %global NSS_BUILDTIME_VERSION %(pkg-config --modversion nss)
> ...
> Requires: nss >= %{NSS_BUILDTIME_VERSION}
> 
> However - the Requires are recognized during srpm creation, and that is done
> in minimal buildroot, before buildrequires are installed.
> So pkg-config --modversion nss exit with error, no nss installed, and build
> fails.

I'd think this is because the pkg-config runs as part of the preamble (i.e. when the spec file gets parsed). That makes some sense, thanks.

> if changed to something like:
> %global NSS_BUILDTIME_VERSION >= %(pkg-config --modversion nss ||:)
> Requires: nss %{NSS_BUILDTIME_VERSION}
> 
> Then builds pass, but no correct nss requirement is there.  Ihave now few
> more ideas to try, so I will investigate.
> 
> Generally, what do you think about this issue?

Not sure, really. It sounds like we need to hard-code the required version and manually update it when deps change and openjdk gets rebuilt.

Comment 20 Severin Gehwolf 2016-05-04 12:53:25 UTC
(In reply to jiri vanek from comment #17)
> (In reply to Severin Gehwolf from comment #15)
> > $ rpm -q --requires java-1.8.0-openjdk-headless | grep nss
> > libnss3.so()(64bit)
> > libnss3.so(NSS_3.2)(64bit)
> > libnssutil3.so()(64bit)
> > libnssutil3.so(NSSUTIL_3.12)(64bit)
> > $ rpm -q --whatprovides 'libnss3.so()(64bit)'
> > nss-3.23.0-1.0.fc23.x86_64
> > $ rpm -q --whatprovides 'libnssutil3.so()(64bit)'
> > nss-util-3.23.0-1.0.fc23.x86_64
> > $ rpm -q --whatprovides 'libnssutil3.so(NSSUTIL_3.12)(64bit)'
> > nss-util-3.23.0-1.0.fc23.x86_64
> > $ rpm -q --whatprovides 'libnss3.so(NSS_3.2)(64bit)'
> > nss-3.23.0-1.0.fc23.x86_64
> > 
> > So the auto-requires are not enough, because nss-softokn is not required.
> 
> If I read the versions correctly, then adding requires nss-softoken will not
> be enough. Why do you think it will be?

Having an un-versioned requirement on nss-softokn is an improvement. I was merely pointing out that we don't have any requires on nss-softokn as of yet (but understanding the issue correctly, we should have a requirement on it).

Comment 21 Michael Simacek 2016-05-04 13:32:45 UTC
You can alter the requires generator to output what you want:
%global _use_internal_dependency_generator 0
%global __find_requires bash -c '%{__find_requires} && echo "nss >= `pkg-config --modversion nss`"'

I don't know how much of a hack it is, though. Use with caution.

Comment 22 jiri vanek 2016-05-04 15:32:04 UTC
(In reply to jiri vanek from comment #18)
> jsutfyi:
> 
> trying something like:
> +# see https://bugzilla.redhat.com/show_bug.cgi?id=1332456
> +%global NSSSOFTOKN_BUILDTIME_NUMBER %(pkg-config --modversion nss-softokn
> || : )
> +%global NSS_BUILDTIME_NUMBER %(pkg-config --modversion nss || : )
> +#this is worakround for processing of requires during srpm creation
> +%global NSSSOFTOKN_BUILDTIME_VERSION %(if [
> "x%{NSSSOFTOKN_BUILDTIME_NUMBER}" == "x" ] ; then echo "" ;else echo ">=
> %{NSSSOFTOKN_BUILDTIME_NUMBER}" ;fi)
> +%global NSS_BUILDTIME_VERSION %(if [ "x%{NSS_BUILDTIME_NUMBER}" == "x" ] ;
> then echo "" ;else echo ">= %{NSS_BUILDTIME_NUMBER}" ;fi)
> +
>  
>  # fix for https://bugzilla.redhat.com/show_bug.cgi?id=1111349
>  %global _privatelibs libmawt[.]so.*
> @@ -666,6 +673,9 @@ Requires: javapackages-tools
>  Requires: tzdata-java >= 2015d
>  # libsctp.so.1 is being `dlopen`ed on demand
>  Requires: lksctp-tools
> +# there is need to depnd on exact version of nss
> +Requires: nss %{NSS_BUILDTIME_VERSION}
> +Requires: nss-softokn %{NSSSOFTOKN_BUILDTIME_VERSION}
> 
> 
> As I'm really not sure how macros are cached between srpm ops, and final rpm
> ops.



Ok. This worked. Macro is really expanded second times after the build.

I will push this to rawhide. Still the main question - whether to do this at all, remains...

Comment 23 Severin Gehwolf 2016-05-04 17:16:29 UTC
(In reply to Andrew John Hughes from comment #10)
> In this case, we know NSS is part of z, but there could be other packages
> too. The reason we see a problem with NSS is because SunEC is built from a
> strange cocktail of static and linked libraries. freebl, from nss-softokn,
> is statically compiled into the provider because that's the only way the EC
> routines used are provided. However, these routines then called out to
> shared code in the NSS libraries. Thus, you get an issue like this where the
> newer freebl used by the OpenJDK build is calling out to an older set of
> shared NSS libraries.

This suggests that only a runtime requirement on nss is needed, right? Since freebl from nss-softokn is compiled in statically its not needed at runtime. If so, "Requires: nss-softokn %{NSSSOFTOKN_BUILDTIME_VERSION}" is now there incorrectly. We'd only need "Requires: nss %{NSS_BUILDTIME_VERSION}". Andrew, can you confirm?

Comment 24 Andrew John Hughes 2016-05-04 17:41:43 UTC
I haven't looked at what's been added, but comment #18 looks correct; for safety, both packages should match the version they were built against as a minimum.

I think it would be a lot clearer if >= were retained in the Requires rather than the variables, but maybe that's a side-effect of how it's been generated.

Comment 25 jiri vanek 2016-05-05 10:04:45 UTC
> I think it would be a lot clearer if >= were retained in the Requires rather
> than the variables, but maybe that's a side-effect of how it's been
> generated.

It cant, in intial srpm rebuild, it evaluates to "". So it would be `requires: nss >= ` which is error.

Comment 26 Andy Sh 2016-05-06 19:27:50 UTC
In Fedora with openjdk version "1.8.0_91", only inside docker, (!) any crypto operation, ex SSLContext.getDefault() fails with

Exception in thread "main" java.lang.InternalError
        at sun.security.ec.SunEC.initialize(Native Method)
        at sun.security.ec.SunEC.access$000(SunEC.java:49)
        at sun.security.ec.SunEC$1.run(SunEC.java:61)
        at sun.security.ec.SunEC$1.run(SunEC.java:58)
        at java.security.AccessController.doPrivileged(Native Method)
        at sun.security.ec.SunEC.<clinit>(SunEC.java:58)
        at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
        at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
        at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
        at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
        at java.lang.Class.newInstance(Class.java:442)
        at sun.security.jca.ProviderConfig$2.run(ProviderConfig.java:221)
        at sun.security.jca.ProviderConfig$2.run(ProviderConfig.java:206)
        at java.security.AccessController.doPrivileged(Native Method)
        at sun.security.jca.ProviderConfig.doLoadProvider(ProviderConfig.java:206)
        at sun.security.jca.ProviderConfig.getProvider(ProviderConfig.java:187)
        at sun.security.jca.ProviderList.getProvider(ProviderList.java:233)
        at sun.security.jca.ProviderList.getService(ProviderList.java:331)
        at sun.security.jca.GetInstance.getInstance(GetInstance.java:157)
        at javax.net.ssl.SSLContext.getInstance(SSLContext.java:156)
        at javax.net.ssl.SSLContext.getDefault(SSLContext.java:96)
        at Test.main(Test.java:12)

Workaround was to also update nss libs.  Latest openjdk 1.8.0_91 broke this

Comment 27 jiri vanek 2016-05-09 12:19:33 UTC
*** Bug 1332867 has been marked as a duplicate of this bug. ***

Comment 28 jiri vanek 2016-05-09 12:20:09 UTC
(In reply to Andy Sh from comment #26)
> In Fedora with openjdk version "1.8.0_91", only inside docker, (!) any
> crypto operation, ex SSLContext.getDefault() fails with
> 
> Exception in thread "main" java.lang.InternalError
>         at sun.security.ec.SunEC.initialize(Native Method)
>         at sun.security.ec.SunEC.access$000(SunEC.java:49)
>         at sun.security.ec.SunEC$1.run(SunEC.java:61)
>         at sun.security.ec.SunEC$1.run(SunEC.java:58)
>         at java.security.AccessController.doPrivileged(Native Method)
>         at sun.security.ec.SunEC.<clinit>(SunEC.java:58)
>         at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
>         at
> sun.reflect.NativeConstructorAccessorImpl.
> newInstance(NativeConstructorAccessorImpl.java:62)
>         at
> sun.reflect.DelegatingConstructorAccessorImpl.
> newInstance(DelegatingConstructorAccessorImpl.java:45)
>         at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
>         at java.lang.Class.newInstance(Class.java:442)
>         at sun.security.jca.ProviderConfig$2.run(ProviderConfig.java:221)
>         at sun.security.jca.ProviderConfig$2.run(ProviderConfig.java:206)
>         at java.security.AccessController.doPrivileged(Native Method)
>         at
> sun.security.jca.ProviderConfig.doLoadProvider(ProviderConfig.java:206)
>         at
> sun.security.jca.ProviderConfig.getProvider(ProviderConfig.java:187)
>         at sun.security.jca.ProviderList.getProvider(ProviderList.java:233)
>         at sun.security.jca.ProviderList.getService(ProviderList.java:331)
>         at sun.security.jca.GetInstance.getInstance(GetInstance.java:157)
>         at javax.net.ssl.SSLContext.getInstance(SSLContext.java:156)
>         at javax.net.ssl.SSLContext.getDefault(SSLContext.java:96)
>         at Test.main(Test.java:12)
> 
> Workaround was to also update nss libs.  Latest openjdk 1.8.0_91 broke this

See https://bugzilla.redhat.com/show_bug.cgi?id=1332867#c5

Comment 29 jiri vanek 2016-05-11 15:50:44 UTC
How will the fix to this issue change, if 
Requires nss >= XXX wil change to 
Recommends nss >= XXX wil change to 

It will update if possible, but not break system when the requested NSS is still in testing repo. However, is it then fix?

Comment 31 Severin Gehwolf 2016-05-11 16:21:26 UTC
(In reply to jiri vanek from comment #29)
> How will the fix to this issue change, if 
> Requires nss >= XXX wil change to 
> Recommends nss >= XXX wil change to 
> 
> It will update if possible, but not break system when the requested NSS is
> still in testing repo. However, is it then fix?

It will break when installed via RPM, AFAIK.

The scenario of the built-against version of NSS (or any version greater than it) not hitting stable while that version of openjdk hitting stable seems the more unlikely case than somebody installing via RPM directly. Note that this case should even get caught via Taskotron[1][2]. Formerly AutoQA.

I'd vote for keeping it with Requires.

[1] https://fedoraproject.org/wiki/Taskotron
[2] https://fedoraproject.org/wiki/Taskotron/Tasks/depcheck

Comment 32 Andrew John Hughes 2016-05-11 17:20:28 UTC
It should be Requires. If the version of NSS it was built against is unavailable, then not installing the new version of OpenJDK is the correct behaviour.

Comment 33 Fedora Update System 2016-05-12 06:35:01 UTC
java-1.8.0-openjdk-1.8.0.91-5.b14.fc24 has been submitted as an update to Fedora 24. https://bodhi.fedoraproject.org/updates/FEDORA-2016-6747aa8f70

Comment 34 Fedora Update System 2016-05-12 06:35:20 UTC
java-1.8.0-openjdk-1.8.0.91-5.b14.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2016-3ae0ad53b2

Comment 35 Fedora Update System 2016-05-12 22:27:15 UTC
java-1.8.0-openjdk-1.8.0.91-5.b14.fc24 has been pushed to the Fedora 24 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-6747aa8f70

Comment 36 Fedora Update System 2016-05-13 05:32:23 UTC
java-1.8.0-openjdk-1.8.0.91-5.b14.fc23 has been pushed to the Fedora 23 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-3ae0ad53b2

Comment 37 Fedora Update System 2016-05-15 05:24:41 UTC
java-1.8.0-openjdk-1.8.0.91-5.b14.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.

Comment 38 Fedora Update System 2016-05-16 16:19:17 UTC
java-1.8.0-openjdk-1.8.0.91-5.b14.fc24 has been pushed to the Fedora 24 stable repository. If problems still persist, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.