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
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Timothe Litt <litt_at_acm.org>
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.
https://perldoc.perl.org/perlos400
GitHub actions supports self-hosted runners; I don't know what it would
take to port the runner to OS400. https://github.com/actions/runner
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.)
FWIW
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 https://curl.se/mail/lib-2023-01/0003.html "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
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.
https://perldoc.perl.org/perlos400
GitHub actions supports self-hosted runners; I don't know what it would
take to port the runner to OS400. https://github.com/actions/runner
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.)
FWIW
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 https://curl.se/mail/lib-2023-01/0003.html "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
>
-- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.html
- application/pgp-signature attachment: OpenPGP digital signature