Description of problem: FTPS tests are now skipped in Koji. On s390(x), they are sometimes not skipped, which causes the build to fail: http://s390.koji.fedoraproject.org/koji/taskinfo?taskID=511457 Version-Release number of selected component (if applicable): curl-7.23.0-2.fc17 Actual results: http://s390.koji.fedoraproject.org/koji/taskinfo?taskID=511457 Expected results: FTPS regression tests passing Additional info: Originally reported by Daniel Horák.
Although I am able to reproduce the issue locally, I was not able to find out the root cause yet. Here is my up to now investigation: - on a RHEL-6 machine, I am able to run the FTPS tests for all supported RHEL-6/Fedora versions of curl - on a rawhide machine, I am not able to run the FTPS tests on any supported RHEL-6/Fedora versions of curl - installing RHEL-6 stunnel on the rawhide machine did not change anything - switching SELinux to permissive mode on the rawhide machine did not change anything I am quite sure that it was not caused by any change in curl itself, but will need some additional time to narrow it down.
After downgrading nss{,-sysinit,-devel} to 3.12.x, everything started to work again. As there are no related changes in libcurl, I am switching the component to nss. Version-Release number of selected component (if applicable): nss-3.13.1-9.fc17
Following http://s390.koji.fedoraproject.org/koji/taskinfo?taskID=511457 I see "BuildError: error building package (arch s390x), mock exited with status 1; see build.log for more information" But there is no build.log file for one to examine.
Kamil, should Elio see the failures in FTPS on any arch or does he need s390(x) which I can provide if needed? The original logs were deleted on the s390x koji hub.
(In reply to comment #4) > I'm curious whether the problem shows up with nss-3.13.1-7.fc17 as well. Good point. nss-3.13.1-7.fc17 indeed works much better. The FTPS tests are started and, with valgrind disabled, they pass with no problems. With valgrind enabled, they fail because of bug 769616, but that seems to be an orthogonal issue. Elio, are you aware of any related changes between -7 and -9? (In reply to comment #5) > Kamil, should Elio see the failures in FTPS on any arch or does he need s390(x) > which I can provide if needed? Nope, I can repeat the problem on an x86_64 rawhide machine. It does not seem to be s390(x) specific at all.
Created attachment 549228 [details] changes made from nss-3.13.7-7 to nss-3.13.1-9 (In reply to comment #6) > Elio, are you aware of any related changes between -7 and -9? Yes, I added one patch going from -7 to -8 and dropped one patch from -8 to -9 as the attached diff file shows. The nss-3.13.1-7 build forms the basis for the merge to the new git repo for rhel. It has a patch, nosha224.path, to account for the fact that the sha224 algorithm isn't available in the old softoken from 3.12.9 that we are required to use in RHEL. It was used for the merge for the new git repo for future rhel. Going to nss-3.13.1-8 I added your patch to fix Bug 754744 "- Resolves: Bug 754771 - [PEM] an unregistered callback causes a SIGSEGV" 3) For nss-3.13.1-9 I droppped the previously mentioned nosha224.patch as in fedora we do have, and want to, use the latest softoken from nss-3.13.1.
Reviewing attachment 549228 [details], a big change is the softoken version we are using. From -7 and -8 where we have Requires: nss-softokn%{_isa} >= %{nss_softokn_fips_version} to -9 that has Requires: nss-softokn%{_isa} >= %{nss_softokn_version} where nss_softokn_fips_version = 3.12.9 and nss_softokn_version = 3.13.3
Ooops, now I am confused as it does not work for me with nss-3.13.1-7.fc17 any more :-/ Either my previous testing was bogus, or the big update of packages meanwhile took effect. I will need to check yum.log and figure out what happened...
Are all nss-related pacakses present in the buildroot override? I ask because Jan had problems trying some rebuilds for a firefox/thunderbid/xulrunner/nss/softokn/util bundle for bodhi because some of the lower level nss packages (nss-softokn and nss-util) buildroot overrides where expiring while nss was still there.
Ah, this refers to tests failing not the build, if I understand previous comments correctly. Pardon my ignorance, but what does FTPS mean?
Simply speaking, it is an FTP protocol that runs over TLS: http://tools.ietf.org/html/rfc4217
This bug is caused by the following commit: https://bugzilla.mozilla.org/show_bug.cgi?id=665814#c112
I have pushed a workaround that allows to run the FTPS tests during build: http://pkgs.fedoraproject.org/gitweb/?p=curl.git;a=commitdiff;h=4baedf3
Switching back to curl. I have proposed a solution upstream: http://curl.haxx.se/mail/lib-2011-12/0291.html
fixed in curl-7.23.0-5.fc17