curl / Mailing Lists / curl-library / Single Mail
Buy commercial curl support from WolfSSL. We help you work out your issues, debug your libcurl applications, use the API, port to new platforms, add new features and more. With a team lead by the curl founder himself.

Re: NSS and gskit are getting the axe

From: Timothe Litt <>
Date: Tue, 18 Jul 2023 18:52:29 -0400

With respect to CI:

While I know little about OS400, Perldoc says that you *can *natively
compile Perl with IBM's Visual Age compiler.   Most CPAN modules are
either pure Perl, portable XS (a bunch of C macros), or provide a pure
Perl alternative.  Whether the tests depend on any exceptions would have
to be investigated.

GitHub actions supports self-hosted runners; I don't know what it would
take to port the runner to OS400.
reports that the runner is mostly C# (95%), with a little JS (3.5%) and
Shell (1.3%).   If you do and supply a machine (VMs are fine), Actions
can be told to schedule jobs on your runner.  (And export suitable
environment variables.)


Timothe Litt
ACM Distinguished Engineer
This communication may not represent the ACM or my employer's views,
if any, on the matters discussed.

On 18-Jul-23 18:30, Patrick Monnerat via curl-library wrote:
> On 7/18/23 23:03, Daniel Stenberg wrote:
>> On Tue, 18 Jul 2023, Patrick Monnerat via curl-library wrote:
>>> I have made some local changes to gskit, in hope to save it form
>>> deprecation (modernize, TLS 1.3, ALPN).
>>> It compiles fine, but unfortunately I can't test it as the
>>> certificate store access is denied on pub400. This is why I did not
>>> submit a PR for it yet.
>> I'm a little tired of the fragile gskit situation. I'm willing to
>> re-evaluate once we see a CI job that builds and tests curl with
>> gskit. I want to (continuned to) raise the bar for what is an
>> acceptable level for supported TLS libraries in curl.
>> Because if nobody can make CI builds for gskit, then I don't think it
>> is that important either.
> Yes, it is important because there are no alternative under OS400.
> This is not a gskit problem, rather an OS400 one.
> There's no CI for OS400 because 1) tests do no run on this platform;
> 2) is there an OS400 CI environment available ?
> No tests on OS400: would need perl among other features. These are
> available under PASE which is an AIX emulation, but certainly not
> native OS400.
> For 16 years, the OS400 port has been tested manually to all users'
> satisfaction.
> If you have decided gskit cannot be saved from deprecation, please
> write it explicitly and avoid letting some "hope" on it: from your Jan
> 2 mail "If we get the gskit
> support in shape in time before August 2023, I think that is a working
> argument to *not* deprecate it then". You did not mention a CI. IMO, I
> now have done enough developments that are not accepted, or even ignored.
> Patrick

Received on 2023-07-19