Re: [PHP-DEV] PHP 8.1 and OpenSSL

[Jan Ehrhardt]

Ben Ramsey in php.internals (Tue, 18 Jul 2023 16:23:02 -0500):
>
>> What’s the process for changing this? Do release managers need to change
>> the way we bundle the packages, or does something need to be merged into
>> the PHP-8.1 branch?
>
>Does anyone know the answer to this question?

Not me. But this is becoming an urgent question now that the EOL of
OpenSSL 1.1.1 is around the corner.

Comparable question: will PHP 8.3 be built with VS17 (Visual Studio 2022)?
PHP 8.3.0 beta 1 is still built with VS16 (Visual Studio 2019):
https://windows.php.net/qa/ 
-- 
Jan

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] PHP 8.1 and OpenSSL

[Jan Ehrhardt]

Ben Ramsey in php.internals (Wed, 5 Jul 2023 10:44:12 -0500):
>> On Jun 13, 2023, at 15:06, Jan Ehrhardt  wrote:
>> 
>> Hi Christoph,
>> 
snip
>>> 
>>> So, if there are no unforeseen problems, I suggest to build PHP
>>> 8.1.16RC1 with OpenSSL 3.0 (PHP 8.1.15RC1 has already been built with
>>> OpenSSL 1.1.1).
>>> 
>>> Thoughts?  Objections?
>>> 
>>> [1] <https://www.openssl.org/policies/releasestrat.html>
>>> [2] <https://www.php.net/supported-versions.php>
>> 
>> I noticed that PHP 8.1.20 at https://windows.php.net/download/ was built
>> with OpenSSL 1.1.1t and PHP 8.2.7 & 8.3.0 Alpha 1 with OpenSSL 3.0.8. What
>> will be the official policy for 8.1, 8.2 and 8.3? All 3 versions with
>> OpenSSL 3.0.x or 8.1 still with OpenSSL 1.1.1? And none of the three
>> versions with OpenSSL 3.1.x? Please clarify.
>
>What’s the process for changing this? Do release managers need to change
>the way we bundle the packages, or does something need to be merged into
>the PHP-8.1 branch?

I really would not know that. Christoph should know what has to be
changed, but he has not been really active on the Windows (and PECL) front
lately.
Just for the record: PHP 8.1.21 on https://windows.php.net/download/ is
yet again built with OpenSSL 1.1.1.
-- 
Jan

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

[PHP-DEV] Re: PHP 8.1 and OpenSSL

[Jan Ehrhardt]

Hi Christoph,

"Christoph M. Becker" in php.internals (Wed, 18 Jan 2023 13:20:41 +0100):
>While the official builds for PHP 8.2 already use OpenSSL 3.0, the PHP
>8.1 builds are still using OpenSSL 1.1.1.  However, OpenSSL 1.1.1 is
>only supported till 2023-09-11[1], while PHP 8.1 is supported till
>2024-11-25[2].  Although I don't like bumping the OpenSSL version in the
>middle of PHP 8.1's lifetime, I suppose it is necessary to avoid falling
>behind security support.  And if we do that bump, we better do it sooner
>than later.
>
>So, if there are no unforeseen problems, I suggest to build PHP
>8.1.16RC1 with OpenSSL 3.0 (PHP 8.1.15RC1 has already been built with
>OpenSSL 1.1.1).
>
>Thoughts?  Objections?
>
>[1] 
>[2] 

I noticed that PHP 8.1.20 at https://windows.php.net/download/ was built
with OpenSSL 1.1.1t and PHP 8.2.7 & 8.3.0 Alpha 1 with OpenSSL 3.0.8. What
will be the official policy for 8.1, 8.2 and 8.3? All 3 versions with
OpenSSL 3.0.x or 8.1 still with OpenSSL 1.1.1? And none of the three
versions with OpenSSL 3.1.x? Please clarify.
-- 
Jan

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

[PHP-DEV] Re: PHP 8.3.0alpha1 is available for testing

[Jan Ehrhardt]

Jakub Zelenka in php.internals (Thu, 8 Jun 2023 20:07:22 +0100):
>PHP 8.3.0alpha1 has just been released and can be downloaded from:
>https://downloads.php.net/~jakub
>Or use the git tag: php-8.3.0alpha1
>
>Windows binaries are available at: https://windows.php.net/qa/
>
>This is the first official release of the PHP 8.3 serial and includes
>an incredible amount of work.
>Please test it carefully, and report any bugs at
>https://github.com/php/php-src/issues

Congrats. First signs are really good. Some of you may know that I have my
own builds for Windows with a lot of extensions. I did not switch yet to
VS17 and OpenSSL 3, but with the dependencies for PHP 8.0/8.1 only 1
extension that compiled for PHP 8.2 did not compile yet for PHP 8.3:
igbinary. Builds are available at Apachelounge:
https://www.apachelounge.com/viewtopic.php?t=6617
See for instance a phpinfo dump for PHP 8.3.0 Alpha 1, x64, nts, VS16:
https://phpdev.toolsforresearch.com/php-8.3.0alpha1-nts-Win32-vs16-x64.htm
-- 
Jan

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

[PHP-DEV] Re: PHP 8.1 and OpenSSL

[Jan Ehrhardt]

"Christoph M. Becker" in php.internals (Wed, 18 Jan 2023 13:20:41 +0100):
>Hi all!
>
>While the official builds for PHP 8.2 already use OpenSSL 3.0, the PHP
>8.1 builds are still using OpenSSL 1.1.1.  However, OpenSSL 1.1.1 is
>only supported till 2023-09-11[1], while PHP 8.1 is supported till
>2024-11-25[2].  Although I don't like bumping the OpenSSL version in the
>middle of PHP 8.1's lifetime, I suppose it is necessary to avoid falling
>behind security support.  And if we do that bump, we better do it sooner
>than later.
>
>So, if there are no unforeseen problems, I suggest to build PHP
>8.1.16RC1 with OpenSSL 3.0 (PHP 8.1.15RC1 has already been built with
>OpenSSL 1.1.1).

I do not mind, but I just noticed that even the official PHP 8.1.19 RC1
still ships with OpenSSL 1.1.1. What is the status?
-- 
Jan

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

[PHP-DEV] Re: PHP 7.4.28 Released!

[Jan Ehrhardt]

"Christoph M. Becker" in php.internals (Fri, 18 Feb 2022 16:26:20 +0100):
>On 18.02.2022 at 16:02, Jan Ehrhardt wrote:
>
>> Derick Rethans in php.internals (Thu, 17 Feb 2022 14:42:47 + (GMT)):
>>> The PHP development team announces the immediate availability of PHP
>>> 7.4.28. This is a security release.
>>
>>> Windows downloads:<https://windows.php.net/download>
>>
>> 7.4.28 is not there. 7.4.27 is there. And even 7.3.33 is still there.
>
>We're having some issues with the PHP 7.4 build VM.  I'm confident that
>the PHP 7.4.28 builds are available soonish.
>
>I'm going to remove the 7.3 downloads right away.

Please also move the 7.3.33 files to
https://windows.php.net/downloads/releases/archives/ 
-- 
Jan

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

[PHP-DEV] Re: PHP 7.4.28 Released!

[Jan Ehrhardt]

Derick Rethans in php.internals (Thu, 17 Feb 2022 14:42:47 + (GMT)):
>The PHP development team announces the immediate availability of PHP
>7.4.28. This is a security release.

>Windows downloads:

7.4.28 is not there. 7.4.27 is there. And even 7.3.33 is still there.
-- 
Jan

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

[PHP-DEV] Re: [RFC] Deprecations for PHP 8.1

[Jan Ehrhardt]

Nikita Popov in php.internals (Mon, 22 Mar 2021 10:24:51 +0100):
>Hi internals,
>
>It's time for another deprecation RFC:
>https://wiki.php.net/rfc/deprecations_php_8_1

FWIW, a quick search returned these results.

ADOdb still uses strftime()
https://adodb.org/dokuwiki/doku.php

2 plugins of Matomo (formerly Piwik) still uses strftime in
Login/PasswordResetter.php and RssWidget/RssRenderer.php

The simplepie library still uses strftime:
https://github.com/simplepie/simplepie/blob/717d9ea4bf1a8533d5a26128b7acc1598388ce66/library/SimplePie/Item.php#L882

Limesurvey still uses strftime, in the ADOdb functions and in the kcfinder
functions:
https://github.com/LimeSurvey/LimeSurvey/blob/6437c998731e1e79da24c394ef205444cfa75cdf/third_party/kcfinder/core/class/browser.php#L784

Drupal 7 uses strftime in the date module and in the views module:
https://www.drupal.org/project/date
See date/date_api/date_api_sql.inc
https://www.drupal.org/project/views
See views/includes/handlers.inc

Drupal 8 uses strftime. Example:
https://api.drupal.org/api/drupal/core!modules!views!src!Plugin!views!query!Sql.php/function/Sql%3A%3AgetDateFormat/8.2.x
-- 
Jan

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

[PHP-DEV] Re: Update on git.php.net incident

[Jan Ehrhardt]

"Christoph M. Becker" in php.internals (Mon, 12 Apr 2021 14:23:33 +0200):
>On 12.04.2021 at 13:51, Jan Ehrhardt wrote:
>
>> Nikita Popov in php.internals (Tue, 6 Apr 2021 20:28:03 +0200):
>>> * Existing passwords were reset (use main.php.net/forgot.php to generate a
>>> new one).
>>
>> The Wiki has another password reset link:
>> https://wiki.php.net/start?do=resendpwd
>>
>> It sends a new password (in plain text), but that password still fails.
>> I had to reset my password at https://main.php.net/forgot.php to be able
>> to login to the Wiki and, for instance, vote for RFC's.
>
>The resendpwd link is for Wiki user accounts, i.e. for users who don't
>have a php.net account, only.

It is confusing, to say the least. You follow a RFC link and notice that
your password does not work any more. So you follow the link after
'Forgotten your password? Get a new one', follow the actions and get a new
password. You try the password and it still does not work. There is no
reference to https://main.php.net/forgot.php anywhere on the login page
for RFC's and the like.
-- 
Jan

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

[PHP-DEV] Re: Update on git.php.net incident

[Jan Ehrhardt]

Nikita Popov in php.internals (Tue, 6 Apr 2021 20:28:03 +0200):
> * Existing passwords were reset (use main.php.net/forgot.php to generate a
>new one).

The Wiki has another password reset link:
https://wiki.php.net/start?do=resendpwd

It sends a new password (in plain text), but that password still fails.
I had to reset my password at https://main.php.net/forgot.php to be able
to login to the Wiki and, for instance, vote for RFC's.
-- 
Jan 

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

[PHP-DEV] Re: Update on git.php.net incident

[Jan Ehrhardt]

Nikita Popov in php.internals (Tue, 6 Apr 2021 20:28:03 +0200):
>Something I was not aware of at the time is that git.php.net
>(intentionally) supported pushing changes not only via SSH (using the
>gitolite infrastructure and public key cryptography), but also via HTTPS.
>The latter did not use gitolite, and instead used git-http-backend behind
>Apache2 Digest authentication against the master.php.net user database. I'm
>not sure why password-based authentication was supported in the first
>place, as it is much less secure than pubkey authentication.

Password-based authentication on Github is deprecated for some time now
and will be disabled on August 13, 2021. See the timeline in
https://github.blog/2020-12-15-token-authentication-requirements-for-git-operations/
-- 
Jan

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

[PHP-DEV] Re: Changes to Git commit workflow

[Jan Ehrhardt]

Nikita Popov in php.internals (Mon, 29 Mar 2021 00:52:24 +0200):
>We're reviewing the repositories for any corruption beyond the two
>referenced commits.

Will PHP 8.0.4 and 7.4.17 be postponed because of this? They haven't been
released yet. The usual day for tagging always was Tuesday or Wednesday.
-- 
Jan

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

[PHP-DEV] Re: PHP 8.0.1 Released!

[Jan Ehrhardt]

"Christoph M. Becker" in php.internals (Fri, 8 Jan 2021 11:37:38 +0100):
>On 08.01.2021 at 10:28, Christian Wenz wrote:
>
>>> The PHP development team announces the immediate availability of PHP 
>>> 8.0.1. This is a security release.
>> 
>> The release page (https://www.php.net/releases/8_0_1.php) states that it's a
>> bug fix release. I assume that's correct?
>
>PHP 7.3.26, 7.4.14 and 8.0.1 fix CVE-2020-7071, so all three releases
>are actually security releases (which also have regular bug fixes).

CVE-2020-7071 has a long history: https://bugs.php.net/bug.php?id=77423 
The strange thing is that the fix was also applied to the official PHP 7.2
branch, which should not receive security fixes anymore.

Would not it be better to keep these kind of security backports limited to
https://github.com/microsoft/php-src/commits/PHP-7.2-Security-backports ?
-- 
Jan

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

[PHP-DEV] Re: PHP-7.3 branch is closed

[Jan Ehrhardt]

"Christoph M. Becker" in php.internals (Tue, 15 Dec 2020 18:30:44
+0100):
>PHP-7.3.26 has been branched and will be the last 7.3 bugfix release.
>PHP-7.3 now enters security support for 1 year, see
>.

Right. I was a bit surprised that PHP 7.3.26 RC1 still was tagged, after
the end of active support. Parting shot for the RC's, I guess.
-- 
Jan

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Microsoft Support of PHP on Windows

[Jan Ehrhardt]

Jan Ehrhardt in php.internals (Fri, 10 Jul 2020 18:52:06 +0200):
>? Good Guy ? in php.windows (Fri, 10 Jul 2020 17:39:54 +0100):
>>On 10/07/2020 17:09, Trevor Holyoak via php-windows wrote:
>>> What does this mean? PHP 8 and forward will not be available for 
>>> Windows? Or is just won't be supported by Microsoft?
>>
>>It's means that Microsoft won't be spending time to create Windows 
>>binaries;  Jan Ehrhardt  is developing for private 
>>consumption so perhaps he should volunteer to upload them on the 
>>official website.  Alternatively, Microsoft could create a document for 
>>users to compile their own binaries using Visual Studio.  Personally, I 
>>would like to compile my own binaries but when I once tried it, it 
>>didn't work correctly because I didn't have all the extensions.  I just 
>>gave up but I would like to try again as Microsoft has given us enough 
>>time to prepare for the future.
>
>For many of the libs for extensions I am also dependent on
>https://windows.php.net/downloads/php-sdk/deps/
>Some of them I am also building them my self, using (sometimes patched)
>versions of the repo's on https://github.com/winlibs

And do not forget that the Windows build environment since PHP 7.2 is
also maintained by Microsoft:
https://github.com/microsoft/php-sdk-binary-tools

If they also stop supporting the build environment they will be really
shooting themselves in the foot.
-- 
Jan

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Re: Microsoft Support of PHP on Windows

[Jan Ehrhardt]

Chase Peeler in php.internals (Fri, 10 Jul 2020 12:43:00 -0400):
>My other fear is that if official support for windows is dropped, PHP
>itself will no longer be developed with windows in mind. One reason
>building it is pretty easy is because it was developed to be built on
>Windows. If that stops happening, then building it myself, with or without
>PGO, will become pretty much impossible as well.

Exactly my thoughts. In the long run it will mark the end of PHP on
Windows Server and on Windows Azure. Microsoft is shooting itself in the
foot.
-- 
Jan

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Microsoft Support of PHP on Windows

[Jan Ehrhardt]

? Good Guy ? in php.windows (Fri, 10 Jul 2020 17:39:54 +0100):
>On 10/07/2020 17:09, Trevor Holyoak via php-windows wrote:
>> What does this mean? PHP 8 and forward will not be available for 
>> Windows? Or is just won't be supported by Microsoft?
>>
>>
>It's means that Microsoft won't be spending time to create Windows 
>binaries;  Jan Ehrhardt  is developing for private 
>consumption so perhaps he should volunteer to upload them on the 
>official website.  Alternatively, Microsoft could create a document for 
>users to compile their own binaries using Visual Studio.  Personally, I 
>would like to compile my own binaries but when I once tried it, it 
>didn't work correctly because I didn't have all the extensions.  I just 
>gave up but I would like to try again as Microsoft has given us enough 
>time to prepare for the future.

For many of the libs for extensions I am also dependent on
https://windows.php.net/downloads/php-sdk/deps/
Some of them I am also building them my self, using (sometimes patched)
versions of the repo's on https://github.com/winlibs

>I believe Jan also creates apache binaries on his official website 
>apachelounge.com but I might be wrong about it as I have seen the name 
>of Steffan or something like that often crops up on some forums.

Apachelounge is not my official website. I am just a 'member' that make
his builds available on https://www.apachelounge.com/viewforum.php?f=6
-- 
Jan

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Re: Microsoft Support of PHP on Windows

[Jan Ehrhardt]

? Good Guy ? in php.internals (Fri, 10 Jul 2020 17:16:07 +0100):
>On 10/07/2020 17:01, Jan Ehrhardt wrote:
>> I am building PHP for Windows myself, but I know from the questions I am
>> getting that a lot of corporate customers of Microsoft are running PHP
>> on Windows Server 2016 or 2019. They are only allowed to use the
>> official binaries that are supplied on windows.php.net or pecl.php.net.
>> These corporate customers surely will not be amused by dropping
>> Microsoft's support for PHP 8.
>
>Have you thought of uploading your binaries on php.net AFTER Microsoft 
>has quit the php support?  Windows binaries were very useful for 
>developing websites on windows system which is still the dominant 
>operating system though, web developers will adapt the workload on 
>ubuntu and Mint.  I still use Windows and I regularly  download Apache 
>from apachelounge and php from the official website.

No. And I will not do that, because I do not want to be liable for any
consequences of using my builds. I am providing them AS IS through links
on Apachelounge: https://www.apachelounge.com/viewforum.php?f=6

Many extensions I am building from git head, not from the official
releases by the extension developers. Sometimes I have to patch them a
little to get them building. The Solr extension for instance does not
build yet for PHP 7.4.

>> Besides that, SMB customers are often using Microsoft Azure for their
>> Windows Server needs. Windows Azure will loose a lot of selling points
>> without supported PHP binaries. A quick search on Azure marketplace
>> revealed as well that some Azure partners will also be left in the cold:
>> https://azuremarketplace.microsoft.com/en-us/marketplace/apps?search=windows+php
>> Are the Azure Sales people already informed about your decision?
>
>I suspect Microsoft wants to market its own product called Blazor 
><https://dotnet.microsoft.com/apps/aspnet/web-apps/blazor>

Microsoft's future is in services like Azure. Development tools are much
less important.
-- 
Jan

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

[PHP-DEV] Re: Microsoft Support of PHP on Windows

[Jan Ehrhardt]

Hi Dale,

"Dale Hirt via internals" in php.internals (Thu, 9 Jul 2020 18:48:44
+):
>My name is Dale Hirt and I am the project manager for PHP inside
>Microsoft.
>
>We currently support PHP with development and build efforts for PHP 7.3,
>and PHP 7.4.  In addition, we help with building PHP 7.2 on Windows
>when security fixes are required..
>
>However, as PHP 8.0 is now ramping up, we wanted to let the community
>know what our current plans are going forward.
>
>We know that the current cadence is 2 years from release for bug fixes,
>and 1 year after that for security fixes.  This means that PHP 7.2 will
>be going out of support in November.  PHP 7.3 will be going into
>security fix mode only in November.  PHP 7.4 will continue to have
>another year of bug fix and then one year of security fixes.  We are
>committed to maintaining development and building of PHP on Windows for
>7.2, 7.3 and 7.4 as long as they are officially supported.
>
>We are not, however, going to be supporting PHP for Windows in any
>capacity for version 8.0 and beyond.

This decision took me by surprise, to say the least. Microsoft's
involvement in developing (thanks, Anatol) and building PHP for Windows
was a huge boost for the PHP on Windows community.

I am building PHP for Windows myself, but I know from the questions I am
getting that a lot of corporate customers of Microsoft are running PHP
on Windows Server 2016 or 2019. They are only allowed to use the
official binaries that are supplied on windows.php.net or pecl.php.net.
These corporate customers surely will not be amused by dropping
Microsoft's support for PHP 8.

Besides that, SMB customers are often using Microsoft Azure for their
Windows Server needs. Windows Azure will loose a lot of selling points
without supported PHP binaries. A quick search on Azure marketplace
revealed as well that some Azure partners will also be left in the cold:
https://azuremarketplace.microsoft.com/en-us/marketplace/apps?search=windows+php
Are the Azure Sales people already informed about your decision?

Please rethink if your decision is really in line with Micrsoft's long
term policy.
-- 
Jan

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Who are the current eligible voters?

[Jan Ehrhardt]

Nikita Popov in php.internals (Thu, 16 Jan 2020 15:51:06 +0100):
>
>If you don't know your php.net account password, request a new one at
>https://master.php.net/forgot.php.

Thanks. That one worked. Just curious: why did the wiki send me an
unusable Wikidocu password?
-- 
Jan

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Who are the current eligible voters?

[Jan Ehrhardt]

"Christoph M. Becker" in php.internals (Thu, 16 Jan 2020 14:16:21
+0100):
>On 16.01.2020 at 13:18, Jan Ehrhardt wrote:
>
>> And I still cannot vote. This discussion prompted me to request a
>> password. I got a DokuWiki password, but logging in on
>> https://wiki.php.net/?do=login resulted in
>>
>> | Sorry, username or password was wrong.
>
>You are supposed to be able to login with your php.net account's password.

I do not have any password. The only one I could request was through
https://wiki.php.net/start?do=resendpwd
Then I got a confirmation link and after that a password in a mail
message. That password did not work with the username 'ehrhardt' (which
is OK, because I used that one for rewuesting the password).
-- 
Jan

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Who are the current eligible voters?

[Jan Ehrhardt]

tyson andre in php.internals (Thu, 16 Jan 2020 03:02:24 +):
> Olumide Samson in php.internals (Wed, 15 Jan 2020 22:06:04 +0100):
>> Wow. From a participation standpoint that seems pretty pathetic. If 30
>> is the average that means most people never vote. 
>>
>> I would have assumed that having a vote would mean that people would be
>> expected to vote periodically or if not then loose the privilege. 
>
>How many of the 1900 are aware that they're eligible to vote?

I was not. To my surprise Rasmus gave me a php.net account back in
November 2019, without a explicit request.

And I still cannot vote. This discussion prompted me to request a
password. I got a DokuWiki password, but logging in on
https://wiki.php.net/?do=login resulted in 

| Sorry, username or password was wrong.
-- 
Jan

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: PHP 7.1.33 Released

[Jan Ehrhardt]

Joe Watkins in php.internals (Fri, 25 Oct 2019 00:33:13 +0200):
>The PHP development team announces the immediate availability of PHP
>7.1.33. This is a security release.
>
>All PHP 7.1 users are encouraged to upgrade to this version.

Please include the Windows builds of PHP 7.1.33 in
https://windows.php.net/downloads/releases/archives/
-- 
Jan

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: Postpone 7.3 (& 7.2) releases by 1 week?

[Jan Ehrhardt]

Jan Ehrhardt in php.internals (Tue, 10 Dec 2019 06:45:56 +0100):
>Let us give the 7.3 RMs a New Years Eve

Let us give the 7.3 RMs a New Year's Eve without obligations.
-- 
Jan

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Postpone 7.3 (& 7.2) releases by 1 week?

[Jan Ehrhardt]

Right now we have this cyclus:

Week 1: 7.3.x RC1
Week 2: 7.4.x RC1
Week 3: 7.3.x Release, maybe 7.2.x Release
Week 4: 7.4.x Release
Week 5: 7.3.x+1 RC1
etc etc

Wouldn't it be better to sync our watches and release new versions of
PHP 7.4, 7.3 and possibly 7.2 at the same date, every 4 weeks?

This can be done by delaying the 7.3 and 7.2 release cycles with one
week. Proposal:

1. Tag PHP 7.3.14RC1 on Tuesday Jan  7, Release on Thursday Jan  9
2. Tag PHP 7.3.14on Tuesday Jan 21, Release on Thursday Jan 23
3. Tag PHP 7.2.27 (if any) on Jan 21, Release on Jan 23

Small changes would be needed to
https://www.php.net/supported-versions.php

Let us give the 7.3 RMs a New Years Eve

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: PHP 7.4.0 Released!

[Jan Ehrhardt]

Congrats!

Derick Rethans in php.internals (Thu, 28 Nov 2019 09:36:15 + (GMT)):
>Release Announcement: 
>Downloads:
>Windows downloads:
>Changelog:
>Migration guide:  

Is not it time to use https in the release announcements?
-- 
Jan

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: PHP 7.2.24 Released

[Jan Ehrhardt]

Sara Golemon in php.internals (Wed, 20 Nov 2019 10:03:24 -0600):
>On Wed, Nov 20, 2019 at 9:28 AM Jan Ehrhardt  wrote:
>
>> Remi Collet in php.internals (Thu, 24 Oct 2019 12:58:01 +0200):
>> >The PHP development team announces the immediate availability of PHP
>> >7.2.24. This is a security release which also contains several minor bug
>> >fixes.
>>
>> Is 7.2.25 stuck somewhere? 7.3.12 was tagged yesterday, but nothing for
>> 7.2.25 yet.
>
>Sorry. I got busy with another matter and lost track of this task.  The
>tags have been pushed and the tarballs are in the distributions repo.

No problem at all. See it as a friendly reminder. Yhanks for all you
work.
-- 
Jan

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: PHP 7.2.24 Released

[Jan Ehrhardt]

Remi Collet in php.internals (Thu, 24 Oct 2019 12:58:01 +0200):
>The PHP development team announces the immediate availability of PHP
>7.2.24. This is a security release which also contains several minor bug
>fixes.

Is 7.2.25 stuck somewhere? 7.3.12 was tagged yesterday, but nothing for
7.2.25 yet.
-- 
Jan

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] configure bug with static openssl 1.1.1? - bugid 77288

[Jan Ehrhardt]

"Helmut K. C. Tessarek" in php.internals (Sun, 27 Oct 2019 22:31:52
-0400):
>Hmm, it does not fail on my machine as you can see from the results I posted
>earler. But I just had an idea:
>The extension is very picky about having a proper ca file. I ran into similar
>issues a while back.
>
>Can you please try to set openssl.cafile in php.ini?
>
>I always get the latest version from http://curl.haxx.se/ca/cacert.pem

Thanks! That did the trick. Silly that OpenSSL 1.0.1e (Centos 6 default)
and OpenSSL 1.0.2-fips did not have the problem. Apparently they found
the ca_bundle.crt in /etc/ssl/ (symlinked to /etc/pki/tls/certs/).

In the mean time I also tried it with a Windows build. It succeeded
without any php.ini. For the interested people:
https://phpdev.toolsforresearch.com/php-7.2.24-static-openssl-1.1.1d.zip
-- 
Jan

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] configure bug with static openssl 1.1.1? - bugid 77288

[Jan Ehrhardt]

Nikita Popov in php.internals (Mon, 14 Oct 2019 11:22:24 +0200):
>./configure --disable-all --with-openssl OPENSSL_LIBS="-l:libssl.a
>-l:libcrypto.a -ldl" CFLAGS="-pthread"
>
>This compiles successfully.
>
>> ldd sapi/cli/php
>linux-vdso.so.1 (0x7ffd1531f000)
>libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x7f04b79a9000)
>librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x7f04b77a1000)
>libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f04b7403000)
>libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f04b71ff000)
>libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
>(0x7f04b6fe)
>libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f04b6bef000)
>/lib64/ld-linux-x86-64.so.2 (0x7f04b8bee000)

I now tried 

#!/bin/sh
./configure \
--prefix=/usr/local/php72 \
--program-suffix=72 \
--enable-fpm \
--with-config-file-scan-dir=/usr/local/php72/lib/php.conf.d \
--disable-all \
--with-openssl=/usr/local/ssl-1.1.1 \
CFLAGS=-I/usr/local/include \
LDFLAGS=-L/usr/local/lib \
LIBS="-ldl -lpthread" \
OPENSSL_LIBS="-L/usr/local/ssl-1.1.1/lib -l:libssl.a -l:libcrypto.a -ldl 
-lpthread" \
OPENSSL_CFLAGS="-I/usr/local/ssl-1.1.1/include"

with this as a result:

ldd /usr/local/php72/bin/php
linux-vdso.so.1 =>  (0x7ffd5bb8b000)
libcrypt.so.1 => /lib64/libcrypt.so.1 (0x7f45d95bc000)
libresolv.so.2 => /lib64/libresolv.so.2 (0x7f45d93a2000)
librt.so.1 => /lib64/librt.so.1 (0x7f45d919a000)
libm.so.6 => /lib64/libm.so.6 (0x7f45d8f16000)
libnsl.so.1 => /lib64/libnsl.so.1 (0x7f45d8cfd000)
libdl.so.2 => /lib64/libdl.so.2 (0x7f45d8af9000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x7f45d88dc000)
libc.so.6 => /lib64/libc.so.6 (0x7f45d8548000)
libfreebl3.so => /lib64/libfreebl3.so (0x7f45d8345000)
/lib64/ld-linux-x86-64.so.2 (0x7f45d97f3000)

But it fails on stream_socket_enable_crypto in the test script in
https://gist.github.com/Jan-E/7f0055624b82c39dee6ae5b712f2c97a

Warning: stream_socket_enable_crypto(): SSL operation failed with code 1. 
OpenSSL Error
messages: error:1416F086:SSL 
routines:tls_process_server_certificate:certificate verify
failed

@Nikita: could you try that test with your build? Thanks.
-- 
Jan

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] configure bug with static openssl 1.1.1? - bugid 77288

[Jan Ehrhardt]

Helmut K. C. Tessarek in gmane.comp.php.devel (Sat, 26 Oct 2019 15:49:30 -0400):
>On 2019-10-26 08:20, Jan Ehrhardt wrote:
>> Fill in a smtp-server of your choice (like smtp.gmail.com) and run it.
>> It is non optimized for speed, so it might take 2 minutes before the
>> results show. @Helmut and @Nikita: could you test this and share your
>> results here?
>
>I ran it on the command line and this was the result:
[snip]
>Turn on encryption for login phase: stream_socket_enable_crypto
>64.233.167.108:587: stream_socket_enable_crypto returned true

For me it still fails, also on the command line. OpenSSL 1.1.1d builds
with 1 subtest failing: test/recipes/20-test_enc.t. A known issue.

OpenSSL 1.1.1c builds with no errors, so to be sure I recompiled
everything with 1.1.1c.

Can you give me your exact configure line? For instance: did your build
include nghttp2? Mine did. This is the output of ldd:

ldd /usr/local/php72/bin/php
linux-vdso.so.1 =>  (0x7ffcf6fb8000)
libcrypt.so.1 => /lib64/libcrypt.so.1 (0x7f67e0e81000)
libz.so.1 => /usr/local/lib/libz.so.1 (0x7f67e0c65000)
libexslt.so.0 => /usr/local/lib/libexslt.so.0 (0x7f67e0a5)
liblzma.so.0 => /usr/lib64/liblzma.so.0 (0x7f67e082f000)
librt.so.1 => /lib64/librt.so.1 (0x7f67e0627000)
libgcrypt.so.11 => /lib64/libgcrypt.so.11 (0x7f67e03b2000)
libdl.so.2 => /lib64/libdl.so.2 (0x7f67e01ae000)
libgpg-error.so.0 => /lib64/libgpg-error.so.0 (0x7f67dffaa000)
libm.so.6 => /lib64/libm.so.6 (0x7f67dfd26000)
libsodium.so.23 => /usr/local/lib/libsodium.so.23 (0x7f67dfad5000)
libstdc++.so.6 => /usr/local/lib/../lib64/libstdc++.so.6 
(0x7f67df73e000)
libjpeg.so.9 => /usr/local/lib/libjpeg.so.9 (0x7f67df504000)
libwebp.so.7 => /usr/local/lib/libwebp.so.7 (0x7f67df296000)
libpcre.so.0 => /usr/local/lib/libpcre.so.0 (0x7f67df029000)
libnsl.so.1 => /lib64/libnsl.so.1 (0x7f67dee1)
libgssapi_krb5.so.2 => /lib64/libgssapi_krb5.so.2 (0x7f67debcc000)
libkrb5.so.3 => /lib64/libkrb5.so.3 (0x7f67de8e5000)
libk5crypto.so.3 => /lib64/libk5crypto.so.3 (0x7f67de6b9000)
libcom_err.so.2 => /lib64/libcom_err.so.2 (0x7f67de4b5000)
libcurl.so.4 => /usr/local/ssl-1.1.1/lib/libcurl.so.4 
(0x7f67ddf4b000)
libnghttp2.so.14 => /usr/local/lib/libnghttp2.so.14 (0x7f67ddd25000)
librtmp.so.0 => /usr/lib64/librtmp.so.0 (0x7f67ddb0d000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x7f67dd8f)
libfreetype.so.6 => /usr/local/lib/libfreetype.so.6 (0x7f67dd649000)
libbz2.so.1 => /lib64/libbz2.so.1 (0x7f67dd438000)
libpng16.so.16 => /usr/local/lib/libpng16.so.16 (0x7f67dd206000)
libicui18n.so.58 => /usr/local/icu/lib/libicui18n.so.58 
(0x7f67dcd8e000)
libicuuc.so.58 => /usr/local/icu/lib/libicuuc.so.58 (0x7f67dc9e4000)
libicudata.so.58 => /usr/local/icu/lib/libicudata.so.58 
(0x7f67daee4000)
libicuio.so.58 => /usr/local/icu/lib/libicuio.so.58 (0x7f67dacd7000)
libxslt.so.1 => /usr/local/lib/libxslt.so.1 (0x7f67daa98000)
libxml2.so.2 => /usr/local/lib/libxml2.so.2 (0x7f67da735000)
libiconv.so.2 => /usr/local/lib/libiconv.so.2 (0x7f67da43a000)
libgcc_s.so.1 => /usr/local/lib/../lib64/libgcc_s.so.1 
(0x7f67da224000)
libc.so.6 => /lib64/libc.so.6 (0x7f67d9e9)
libresolv.so.2 => /lib64/libresolv.so.2 (0x7f67d9c76000)
libfreebl3.so => /lib64/libfreebl3.so (0x7f67d9a73000)
/lib64/ld-linux-x86-64.so.2 (0x7f67e10b8000)
libkrb5support.so.0 => /lib64/libkrb5support.so.0 (0x7f67d9868000)
libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x7f67d9665000)
libgnutls.so.26 => /usr/lib64/libgnutls.so.26 (0x7f67d93b5000)
libselinux.so.1 => /lib64/libselinux.so.1 (0x7f67d9196000)
libtasn1.so.3 => /usr/lib64/libtasn1.so.3 (0x7f67d8f86000)

Curl was included as shared:

perl -pi -e 's|CURL_CHECK_PKGCONFIG\(zlib\)|#CURL_CHECK_PKGCONFIG(zlib)|g' 
configure.ac
LIBS="-ldl" ./configure --prefix=/usr/local/ssl-1.1.1 --with-nghttp2=/usr/local 
--with-ssl=/usr/local/ssl-1.1.1

But I once also tested a curl build with --disable-shared.
-- 
Jan

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] configure bug with static openssl 1.1.1? - bugid 77288

[Jan Ehrhardt]

"Helmut K. C. Tessarek" in php.internals (Tue, 22 Oct 2019 22:33:39
-0400):
>After a few more hours of trial and error I managed to get it working.
>
>However, the `-lpthread` in OPENSSL_LIBS is ignored. I checked the config.log,
> but it wasn't added to the linker command. But adding it to LIBS solved the
>issue.
>
>This is the command that finally worked:
>
>./configure [snip] --with-openssl=/usr/local/ssl-1.1.1 [snip]
>CFLAGS=-I/usr/local/include LDFLAGS=-L/usr/local/lib LIBS="-lpthread"
>OPENSSL_LIBS="-L/usr/local/ssl-1.1.1/lib -l:libssl.a -l:libcrypto.a -ldl
>-lpthread" OPENSSL_CFLAGS="-I/usr/local/ssl-1.1.1/include"
>
>I will also update the bug, so that people have this info on file as a 
>reference.

In my implementation I ran into a serious problem. PHPMailer stopped
sending mails to a remote smtp server over port 587. After really a lot
of debugging I found out that stream_socket_enable_crypto failed:

Warning: stream_socket_enable_crypto(): SSL operation failed with code 1
OpenSSL Error messages: error:1416F086:SSL routines:
tls_process_server_certificate:certificate verify failed

I wrote an example program to illustrate this:
https://gist.github.com/Jan-E/7f0055624b82c39dee6ae5b712f2c97a

Fill in a smtp-server of your choice (like smtp.gmail.com) and run it.
It is non optimized for speed, so it might take 2 minutes before the
results show. @Helmut and @Nikita: could you test this and share your
results here?

I had to revert back to PHP versions, compiled with the system OpenSSL
libs.
-- 
Jan

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] nntp 2 mail gateway for internals broken

[Jan Ehrhardt]

"Christoph M. Becker" in php.internals (Wed, 23 Oct 2019 13:37:54 +0200):
>Was this problem perhaps temporary?  There was a general issue with
>news.php.net yesterday.

Looks like it was temporary indeed. Yesterday's disruption caused this:
https://news-web.php.net/php.internals/107636
-- 
Jan

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] nntp 2 mail gateway for internals broken

[Jan Ehrhardt]

Hi Christoph,

"Christoph M. Becker" in php.internals (Wed, 23 Oct 2019 13:37:54 +0200):
>On 23.10.2019 at 13:34, Jan Ehrhardt wrote:
>
>> Jan Ehrhardt in php.internals (Wed, 23 Oct 2019 07:50:38 +0200):
>>> I was always using nntp://news.php.net to reply to messages in the Internals
>>> list. Sad thing: the syncing from the newsserver to the mailinglist is
>>> currently broken. If that is a permanent situation the newsserver shuld be
>>> rejecting usenet posts, like AFAIK php.internals.win does. Otherwise could
>>> somebody fix the nntp 2 mail sync?
>>
>> Andreas Heigl is looking into this issue. I have a very faint suspicion it 
>> has
>> something to do with the threading level, so I am really curious to see if
>> this message gets synced from nntp to mail.
>
>Was this problem perhaps temporary?  There was a general issue with
>news.php.net yesterday.

I sure hope it was temporary. Strange thing is that I am missing a lot of
replies on externals.io, also older ones like
https://news-web.php.net/php.internals/107545
It is not where it should be: https://externals.io/message/107545
-- 
Jan

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] nntp 2 mail gateway for internals broken

[Jan Ehrhardt]

Jan Ehrhardt in php.internals (Wed, 23 Oct 2019 07:50:38 +0200):
>I was always using nntp://news.php.net to reply to messages in the Internals
>list. Sad thing: the syncing from the newsserver to the mailinglist is
>currently broken. If that is a permanent situation the newsserver shuld be
>rejecting usenet posts, like AFAIK php.internals.win does. Otherwise could
>somebody fix the nntp 2 mail sync?

Andreas Heigl is looking into this issue. I have a very faint suspicion it has
something to do with the threading level, so I am really curious to see if
this message gets synced from nntp to mail.
-- 
Jan

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] configure bug with static openssl 1.1.1? - bugid 77288

[Jan Ehrhardt]

Nikita Popov in php.internals (Wed, 23 Oct 2019 11:08:51 +0200):
>On Mon, Oct 14, 2019 at 1:44 PM Jan Ehrhardt  wrote:
>> Wow. Improvement of a patch back in Jun 13, 2005:
>>
>> https://github.com/php/php-src/commit/54d85cbfdadeca491478e3894707534e2c9ccd1f
>> Original bug: https://bugs.php.net/bug.php?id=31256
>>
>> Thanks. Will you backport the commit to PHP 7.2?
>
>Sorry, I forgot about this. Now backported in
>https://github.com/php/php-src/commit/fa89c41f378894dc623374dd03c36a9fa16410a9

Fine, thanks. In the next releases (7.2.25 and 7.3.12) '-pthread' in
OPENSSL_LIBS will not be ignored any longer for static openssl linking.
Will you update https://bugs.php.net/bug.php?id=77288 with this info?
-- 
Jan

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] nntp 2 mail gateway for internals broken

[Jan Ehrhardt]

I was always using nntp://news.php.net to reply to messages in the Internals
list. Sad thing: the syncing from the newsserver to the mailinglist is
currently broken. If that is a permanent situation the newsserver shuld be
rejecting usenet posts, like AFAIK php.internals.win does. Otherwise could
somebody fix the nntp 2 mail sync?
-- 
Jan

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] configure bug with static openssl 1.1.1? - bugid 77288

[Jan Ehrhardt]

On 2019-10-23 07:01, Jan Ehrhardt wrote:

On 2019-10-23 06:36, Helmut K. C. Tessarek wrote:

On 2019-10-23 00:28, Jan Ehrhardt wrote:


It worked in my PHP 7.2 when I added '-pthread' to CFLAGS:
https://news-web.php.net/php.internals/107632


Hmm, CFLAGS shouldn't be used for linker flags. It should be added to 
LDFLAGS.
In either case, it's possible that it works with those, but I was 
talking

about OPENSSL_LIBS, which was suggested by Nikita and Rainer.


I was just following Nikita's example by using '-pthread' in CFLAGS:
https://news-web.php.net/php.internals/107632


Correct reference should be
https://news-web.php.net/php.internals/107541

It gets confusing when one is following internals via various 
interfaces.

--
Jan

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] configure bug with static openssl 1.1.1? - bugid 77288

[Jan Ehrhardt]

On 2019-10-23 06:36, Helmut K. C. Tessarek wrote:

On 2019-10-23 00:28, Jan Ehrhardt wrote:


It worked in my PHP 7.2 when I added '-pthread' to CFLAGS:
https://news-web.php.net/php.internals/107632


Hmm, CFLAGS shouldn't be used for linker flags. It should be added to 
LDFLAGS.
In either case, it's possible that it works with those, but I was 
talking

about OPENSSL_LIBS, which was suggested by Nikita and Rainer.


I was just following Nikita's example by using '-pthread' in CFLAGS:
https://news-web.php.net/php.internals/107632
--
Jan

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] configure bug with static openssl 1.1.1? - bugid 77288

[Jan Ehrhardt]

On 2019-10-23 06:17, Helmut K. C. Tessarek wrote:

On 2019-10-23 00:03, Jan Ehrhardt wrote:


That is more or less the same answer I posted 13 hours earlier
https://news-web.php.net/php.internals/107628


Darn, that would have saved me a lot of time... ;-)


Yes. Really bad that nntp://news.php.net, https://external.io and
the mailing list are not in sync anymore. First time I experienced
that.


BTW: should not that be '-pthread' in stead of '-lpthread'? It was
stripped from OPENSSL_LIBS as found by Nikita:
https://news-web.php.net/php.internals/107543


Yep, I tried that too. But it didn't work. At least not on 7.2.


It worked in my PHP 7.2 when I added '-pthread' to CFLAGS:
https://news-web.php.net/php.internals/107632
--
Jan

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] configure bug with static openssl 1.1.1? - bugid 77288

[Jan Ehrhardt]

"Helmut K. C. Tessarek" in php.internals (Tue, 22 Oct 2019 22:33:39 -0400):
>Eureka!
>
>After a few more hours of trial and error I managed to get it working.
>
>However, the `-lpthread` in OPENSSL_LIBS is ignored. I checked the config.log,
> but it wasn't added to the linker command. But adding it to LIBS solved the
>issue.
>
>This is the command that finally worked:
>
>./configure [snip] --with-openssl=/usr/local/ssl-1.1.1 [snip]
>CFLAGS=-I/usr/local/include LDFLAGS=-L/usr/local/lib LIBS="-lpthread"
>OPENSSL_LIBS="-L/usr/local/ssl-1.1.1/lib -l:libssl.a -l:libcrypto.a -ldl
>-lpthread" OPENSSL_CFLAGS="-I/usr/local/ssl-1.1.1/include"

That is more or less the same answer I posted 13 hours earlier
https://news-web.php.net/php.internals/107628

Too bad it did not bave seemed to reach the mailinglist and/or
https://externals.io/message/103582

Frustrating that https://news-web.php.net/php.internals is not in sync with
the mailinglist and/or https://externals.io/

BTW: should not that be '-pthread' in stead of '-lpthread'? It was stripped
from OPENSSL_LIBS as found by Nikita:
https://news-web.php.net/php.internals/107543
-- 
Jan

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] configure bug with static openssl 1.1.1? - bugid 77288

[Jan Ehrhardt]

Jan Ehrhardt in php.internals (Tue, 22 Oct 2019 15:04:20 +0200):
>With at least bison 3.0 and re2c 3.14.1 installed this seens to
>work with PHP 7.4.0RC4:
>
>#!/bin/sh
>./configure \
>--with-config-file-scan-dir=/usr/local/lib/php.conf.d \
>--disable-all \
>--with-openssl-dir=/usr/local/ssl-1.1.1 \
>--with-openssl=/usr/local/ssl-1.1.1 \
>CFLAGS=" -I/usr/local/ssl-1.1.1/include " \
>OPENSSL_LIBS="-ldl -pthread -L/usr/local/ssl-1.1.1/lib -l:libssl.a 
>-l:libcrypto.a"

For PHP 7.2 and 7.3 you'll have to replace --with-openssl by

--with-openssl=/usr/local/ssl-1.1.1 \
--with-openssl-dir=/usr/local/ssl-1.1.1 \
CFLAGS="-pthread -I/usr/local/ssl-1.1.1/include" \
OPENSSL_LIBS="-ldl -pthread -L/usr/local/ssl-1.1.1/lib -l:libssl.a 
-l:libcrypto.a" \

Note that the '-pthread' was added to the CFLAGS line as well, because it was 
stripped out
of the OPENSSL_LIB definition. This was fixed by Nikita in PHP 7.4, but that 
fix was not
backported to earlier versions.

# /usr/local/php72/bin/php -i | grep OpenSSL
SSL Version => OpenSSL/1.0.1e-fips
OpenSSL support => enabled
OpenSSL Library Version => OpenSSL 1.1.1d  10 Sep 2019
OpenSSL Header Version => OpenSSL 1.1.1d  10 Sep 2019
OpenSSL support => enabled

The first line with 'OpenSSL/1.0.1e-fips' is what the curl extension reports. I 
will have
to update that as well to OpenSSL 1.1.1 (static).
-- 
Jan

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] configure bug with static openssl 1.1.1? - bugid 77288

[Jan Ehrhardt]

Jan Ehrhardt in php.internals (Tue, 22 Oct 2019 15:04:20 +0200):
>With at least bison 3.0 and re2c 3.14.1 installed this seems to
>work with PHP 7.4.0RC4:
[snip]
With some modules enabled:

#!/bin/sh
./configure \
--disable-all \
--with-openssl-dir=/usr/local/ssl-1.1.1 \
--with-openssl=/usr/local/ssl-1.1.1 \
CFLAGS="-I/usr/local/ssl-1.1.1/include" \
OPENSSL_LIBS="-ldl -pthread -L/usr/local/ssl-1.1.1/lib -l:libssl.a 
-l:libcrypto.a" \
--with-apxs2 \
--enable-pdo \
--with-mhash \
--with-mysql-sock=/var/lib/mysql/mysql.sock \
--with-mysqli=mysqlnd \
--with-pcre-regex=/usr/local \
--with-pdo-mysql=mysqlnd \
--with-png-dir=/usr/local/lib \
--with-webp-dir=/usr/local/lib \
--with-zlib \
--enable-zip \
--enable-bcmath \
--enable-calendar \
--enable-ftp \
--enable-sockets \
--with-gd \
--with-gettext \
--with-jpeg-dir=/usr/local/lib \
--with-freetype-dir=/usr/local/lib

-- 
Jan

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] configure bug with static openssl 1.1.1? - bugid 77288

[Jan Ehrhardt]

"Helmut K. C. Tessarek" in php.internals (Mon, 21 Oct 2019 23:34:58 -0400):
>On 2019-10-14 05:46, Nikita Popov wrote:
>> This should be fixed with
>> https://github.com/php/php-src/commit/c518932c0326a938f0fd0254f2adb03b1cddfbca.
>> Now using just
>> 
>> ./configure --disable-all --with-openssl OPENSSL_LIBS="-l:libssl.a
>> -l:libcrypto.a -ldl -pthread"
>> 
>> works for me.
>
>Hmm, I can't get it to work. My ssl is in: /usr/local/ssl-1.1.1

With at least bison 3.0 and re2c 3.14.1 installed this seens to
work with PHP 7.4.0RC4:

#!/bin/sh
./configure \
--with-config-file-scan-dir=/usr/local/lib/php.conf.d \
--disable-all \
--with-openssl-dir=/usr/local/ssl-1.1.1 \
--with-openssl=/usr/local/ssl-1.1.1 \
CFLAGS=" -I/usr/local/ssl-1.1.1/include " \
OPENSSL_LIBS="-ldl -pthread -L/usr/local/ssl-1.1.1/lib -l:libssl.a 
-l:libcrypto.a"

Tested on Centos 6:

# sapi/cli/php -i | grep OpenSSL
OpenSSL support => enabled
OpenSSL Library Version => OpenSSL 1.1.1d  10 Sep 2019
OpenSSL Header Version => OpenSSL 1.1.1d  10 Sep 2019

# ldd sapi/cli/php
linux-vdso.so.1 =>  (0x7ffee71a5000)
libcrypt.so.1 => /lib64/libcrypt.so.1 (0x7f1341764000)
libresolv.so.2 => /lib64/libresolv.so.2 (0x7f134154a000)
librt.so.1 => /lib64/librt.so.1 (0x7f1341342000)
libm.so.6 => /lib64/libm.so.6 (0x7f13410be000)
libdl.so.2 => /lib64/libdl.so.2 (0x7f1340eba000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x7f1340c9d000)
libz.so.1 => /usr/local/lib/libz.so.1 (0x7f1340a81000)
libc.so.6 => /lib64/libc.so.6 (0x7f13406ed000)
/lib64/ld-linux-x86-64.so.2 (0x7f134199b000)
libfreebl3.so => /lib64/libfreebl3.so (0x7f13404ea000)
-- 
Jan

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] configure bug with static openssl 1.1.1? - bugid 77288

[Jan Ehrhardt]

Nikita Popov in php.internals (Mon, 14 Oct 2019 11:46:57 +0200):
>On Mon, Oct 14, 2019 at 11:30 AM Nikita Popov  wrote:
>
>> On Mon, Oct 14, 2019 at 11:22 AM Nikita Popov 
>> wrote:
>>
>>> The fact that "-pthread" gets stripped from LIBS might be a bug.
>>
>> Looks like the -pthread stripping happens here:
>> https://github.com/php/php-src/blob/5197d0cd5e1f4581db1beca1260e1315368ea911/build/php.m4#L371-L377
>>
>> It doesn't get stripped as much as relocated to EXTRA_LDFLAGS (for static
>> builds, for shared it goes into SHARED_LIBADD). However EXTRA_LDFLAGS is
>> only used when linking libraries, while programs use EXTRA_LDFLAGS_PROGRAM.
>> This seems like an oversight, and it should be added to both.
>
>This should be fixed with
>https://github.com/php/php-src/commit/c518932c0326a938f0fd0254f2adb03b1cddfbca.
>Now using just
>
>./configure --disable-all --with-openssl OPENSSL_LIBS="-l:libssl.a
>-l:libcrypto.a -ldl -pthread"
>
>works for me.

Wow. Improvement of a patch back in Jun 13, 2005:
https://github.com/php/php-src/commit/54d85cbfdadeca491478e3894707534e2c9ccd1f
Original bug: https://bugs.php.net/bug.php?id=31256

Thanks. Will you backport the commit to PHP 7.2?
-- 
Jan

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] configure bug with static openssl 1.1.1? - bugid 77288

[Jan Ehrhardt]

"Helmut K. C. Tessarek" in php.internals (Thu, 7 Feb 2019 13:39:11
+0100):
>On 2018-12-13 17:52, Rainer Jung wrote:
>> I might be wrong, but I vaguely remember that PHp does not call
>> "pkg-config --static --libs openssl" with a correctly setup
>> PKG_CONFIG_PAATZ to get the libs needed for static compilation.
>> Typically OpenSSL installs correct pc files that contain pthread as such
>> a dependency. Without asking pkg-config some fixed decisin logic would
>> need to find all the needed libs.
>
>I'd like to follow up on bug https://bugs.php.net/bug.php?id=77288
>
>It's not stated in the documentation anywhere that a static openssl is
>not supported.
>It's ok, if devs don't have the time to look into it right away, but
>I've opened this bug 2 months ago, and it would be nice, if someone
>could at least acknowledge the bug and/or give some sort of a feedback.
>
>If PHP does not support static openssl, please change the documentation
>accordingly.
>
>However, it's wotking with openssl 1.0.2, so I must assume that there's
>a bug somewhere otherwise it would work with openssl 1.1.1 as well.

Did you ever find a solution to compile PHP with a static OpenSSL 1.1.1?
-- 
Jan

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: PHP 7.4.0beta2 is available for testing

[Jan Ehrhardt]

Sara Golemon in php.internals (Tue, 20 Aug 2019 15:03:07 -0500):
>On Tue, Aug 20, 2019 at 1:58 PM Jan Ehrhardt  wrote:
>
>> Derick Rethans in php.internals (Thu, 8 Aug 2019 09:53:28 +0100 (BST)):
>> >PHP 7.4.0beta2 has just been released and can be downloaded from:
>>
>> Was 7.4.0beta3 skipped? 7.4.0beta4 is now tagged at Github.
>> https://github.com/php/php-src/releases/tag/php-7.4.0beta4
>
>Yes. Counting is hard. Also, skipping version numbers is a proud PHP
>tradition now.  RMs discussed it and we're just gonna roll with it.  There
>are plenty more digits in the computer.

Be glad that Derick's typo was at the end of the version string.
Otherwise we would have had 6.4.0beta3 now ;-)
-- 
Jan

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: PHP 7.4.0beta2 is available for testing

[Jan Ehrhardt]

Derick Rethans in php.internals (Thu, 8 Aug 2019 09:53:28 +0100 (BST)):
>PHP 7.4.0beta2 has just been released and can be downloaded from:

Was 7.4.0beta3 skipped? 7.4.0beta4 is now tagged at Github.
https://github.com/php/php-src/releases/tag/php-7.4.0beta4
-- 
Jan

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: PHP 7.4 FEATURE FREEZE ?

[Jan Ehrhardt]

Remi Collet in php.internals (Wed, 24 Jul 2019 08:15:36 +0200):
>Le 23/07/2019 à 19:13, Jan Ehrhardt a écrit :
>> Derick Rethans in php.internals (Tue, 23 Jul 2019 10:00:12 +0100 (BST)):
>>> DOs:
>>> - Test test test test
>> 
>> There are 2 more extensions broken in beta1 that were OK in alpha3:
>> sqlsrv and pdo_sqlsrv. See
>> https://github.com/microsoft/msphpsql/issues/999#issuecomment-514298284
>
>All extensions implementing streams are affected by the recent changes
>in stream wrapper
>
>  y. The read and write operations of php_stream_ops now return ssize_t,
> with negative values indicating an error.
>
>Sadly this only raise a build warning, but the prototype need top be
>fixed, and sometime the error handling logic review
>(swoole, brotli, sqlsrv, zstd, ...)

In the case of sqlsrv and pdo_sqlsrv on Windows it generated a fatal
error. See the github link above.
-- 
Jan

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: PHP 7.4 FEATURE FREEZE ?

[Jan Ehrhardt]

Derick Rethans in php.internals (Tue, 23 Jul 2019 10:00:12 +0100 (BST)):
>DOs:
>- Test test test test

There are 2 more extensions broken in beta1 that were OK in alpha3:
sqlsrv and pdo_sqlsrv. See
https://github.com/microsoft/msphpsql/issues/999#issuecomment-514298284
-- 
Jan

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: PHP 7.4 FEATURE FREEZE ?

[Jan Ehrhardt]

Derick Rethans in php.internals (Tue, 23 Jul 2019 10:00:12 +0100 (BST)):
>DOs:
>- Test test test test

I did. Compilation of Wincache fails in 7.4-beta1:
https://github.com/php/pecl-caching-wincache/commit/def79d476ccb9ad4987d588adda2fdfbb6a80652#commitcomment-34413735
-- 
Jan

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: PHP 7.4.0alpha1 is available for testing

[Jan Ehrhardt]

Jan Ehrhardt in php.internals (Wed, 19 Jun 2019 03:16:58 +0200):
>Derick Rethans in php.internals (Thu, 13 Jun 2019 12:50:48 +0100 (BST)):
>>PHP 7.4.0alpha1 has just been released and can be downloaded from:
>>
>><https://downloads.php.net/~derick/>
>>
>>Or use the git tag: php-7.4.0alpha1
>>
>>Windows binaries are available at: <https://windows.php.net/qa/>
>>
>>Please test it carefully, and report any bugs in the bug system.
>>7.4.0alpha2 should be expected in 2 weeks, i.e. on June 27th, 2019.
>
>Several PECL extensions suffer from the (afaik undocumented) removal of
>uint (to be replaced by uint32_t) and ulong (to be replaced by
>zend_ulong). I already found 4 extensions that still use these:
>- oauth
>- msgpack
>- mailparse
>- ereg
>And probably there are a lot more out there.

Documented by Christoph in
https://github.com/php/php-src/commit/571c6bc3f3a6e5e2422dd253e04e9dd8dc740f09

See
https://github.com/php/pecl-web_services-oauth/pull/5#issuecomment-503449092
-- 
Jan

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: PHP 7.4.0alpha1 is available for testing

[Jan Ehrhardt]

Derick Rethans in php.internals (Thu, 13 Jun 2019 12:50:48 +0100 (BST)):
>PHP 7.4.0alpha1 has just been released and can be downloaded from:
>
>
>
>Or use the git tag: php-7.4.0alpha1
>
>Windows binaries are available at: 
>
>Please test it carefully, and report any bugs in the bug system.
>7.4.0alpha2 should be expected in 2 weeks, i.e. on June 27th, 2019.

Several PECL extensions suffer from the (afaik undocumented) removal of
uint (to be replaced by uint32_t) and ulong (to be replaced by
zend_ulong). I already found 4 extensions that still use these:
- oauth
- msgpack
- mailparse
- ereg
And probably there are a lot more out there.
-- 
Jan

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] JIT

[Jan Ehrhardt]

Zeev Suraski in php.internals (Sun, 3 Feb 2019 11:02:56 +):
>Jan Ehrhardt in php.internals (Sun, 03 Feb 2019 11:47:09 +0100):
>>Hi Zeev,
>>
>>Zeev Suraski in php.internals (Sun, 3 Feb 2019 07:05:49 +):
>>>2.  Most PHP production workloads are on Linux, and as far as I can tell
>>>this trend is only growing over the years - with virtual machines and
>>>now containers becoming more and more popular - meaning that even
>>>developers with other host OSs still use Linux for the actual PHP
>>>development.
>>
>>I am not sure this really is the case. Depending on which statistics you
>>believe te be true, about a quarter to a third of the Web is powered by
>>Wordpress. Wordpress market share is not diminishing.
>>
>>Do not underestimate the huge amount of Wordpress plugin developers that
>>develop on Windows. Code quality is varying from very low to quite high,
>>but these people are PHP developers as well.
>
>How is that related?

It is directly related with your statement that "developers with other
host OSs still use Linux for the actual PHP development". They don't use
Linux for the actual PHP development. They are using Windows.
-- 
Jan

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] JIT

[Jan Ehrhardt]

Hi Zeev,

Zeev Suraski in php.internals (Sun, 3 Feb 2019 07:05:49 +):
>2.  Most PHP production workloads are on Linux, and as far as I can tell
>this trend is only growing over the years - with virtual machines and
>now containers becoming more and more popular - meaning that even
>developers with other host OSs still use Linux for the actual PHP
>development.

I am not sure this really is the case. Depending on which statistics you
believe te be true, about a quarter to a third of the Web is powered by
Wordpress. Wordpress market share is not diminishing.

Do not underestimate the huge amount of Wordpress plugin developers that
develop on Windows. Code quality is varying from very low to quite high,
but these people are PHP developers as well.
-- 
Jan

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] PHP 7.2.15 RC1?

[Jan Ehrhardt]

Is it on purpose that 7.2.15 RC1 was not released last week? There are
enough changes after 7.2.14:
https://github.com/php/php-src/blob/d978590c745c23940e29d05d612f673ea45f1d91/NEWS
-- 
Jan

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] [VOTE] FFI - Foreign Function Interface

[Jan Ehrhardt]

"Christoph M. Becker" in php.internals (Sat, 29 Dec 2018 12:27:58 +0100):
>As I understand it, the extension would not be compiled by default, but
>rather has to be enabled using an explicit --with-ffi configure
>option[1] (or --enable-ffi on Windows[2]).

A strange difference. Is not the convention that it should be --with-ffi when
external libraries are needed?

>[1]
>
>[2]
>

And as a BTW: in a snapshot build the extension will be enabled by force.
Something like
snapshot: forcing ffi on
-- 
Jan

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: Skip 7.3.0RC6?

[Jan Ehrhardt]

Remi Collet in php.internals (Thu, 25 Oct 2018 07:32:00 +0200):
>https://blog.remirepo.net/post/2018/07/02/PHP-extensions-status-with-upcoming-PHP-7.3

You can move v8js to work-in-progress. There is a 7.2+ branch:
https://github.com/phpv8/v8js/issues/374#issuecomment-421262169

The Appveyor builds pass all applicable tests on Windows:
https://ci.appveyor.com/project/Jan-E/v8js-rx24a/build/1.0.58
-- 
Jan

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: Skip 7.3.0RC6?

[Jan Ehrhardt]

Jan Ehrhardt in php.internals (Thu, 25 Oct 2018 06:02:31 +0200):
>Additional extensions that are not ready for PHP 7.2 yet:
  7.3

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: Skip 7.3.0RC6?

[Jan Ehrhardt]

"Christoph M. Becker" in php.internals (Wed, 24 Oct 2018 19:37:57 +0200):
>I've thought about this as well, but given that some widely used PECL
>extensions are not ready for PHP 7.3 yet (for instance, yaml[1],
>mailparse[2] and uopz[3]) (Remi may have more to say on this), it might
>be better to still have two additional RCs (RC4 has been tagged
>yesterday).

Additional extensions that are not ready for PHP 7.2 yet:
- wincache
- pthreads https://github.com/krakjoe/pthreads/issues/889#issuecomment-412330976
- request https://github.com/pmjones/ext-request/pull/14
- msgpack https://github.com/msgpack/msgpack-php/pull/124
-- 
Jan

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] News and mailing lists were down. Up again?

[Jan Ehrhardt]

Rasmus Lerdorf in php.internals (Wed, 29 Aug 2018 08:07:21 -0700):
>On Tue, Aug 28, 2018 at 2:52 AM, Jan Ehrhardt  wrote:
>
>> https://bugs.php.net/bug.php?id=76743

The newserver has picked up the feed as well.
-- 
Jan

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] News and mailing lists were down. Up again?

[Jan Ehrhardt]

https://bugs.php.net/bug.php?id=76743

Are we back?
-- 
Jan

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: PHP 7.3.0beta1 is available for testing

[Jan Ehrhardt]

Hi Christoph,

Congrats for this milestone!

"Christoph M. Becker" in php.internals (Thu, 2 Aug 2018 12:14:46 +0200):
>For more information on the new features and other changes, you can read
>the NEWS file
>(), or the
>UPGRADING file
>() for a
>complete list of upgrading notes.  These files can also be found in the
>release archive.

For module maintainers the UPGRADING.INTERNALS file is also of interest:
https://github.com/php/php-src/blob/php-7.3.0beta1/UPGRADING.INTERNALS

Would not it be wise to include that in the beta announcements?
-- 
Jan

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: PHP 7.1.21

[Jan Ehrhardt]

"Christoph M. Becker" in php.internals (Tue, 31 Jul 2018 16:59:15
+0200):
>On 31.07.2018 at 16:50, Jan Ehrhardt wrote:
>
>> On github PHP 7.1.21 appeared right now:
>> https://github.com/php/php-src/releases/tag/php-7.1.21
>> Shouldn't that have been PHP 7.1.21RC1?
>
>Joe?

It was not Joe's day:
https://github.com/php/php-src/commit/1891246c6637119e7ff5ab0d9826cf8f19223dac#r29914014
-- 
Jan

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] PHP 7.1.21

[Jan Ehrhardt]

On github PHP 7.1.21 appeared right now:
https://github.com/php/php-src/releases/tag/php-7.1.21
Shouldn't that have been PHP 7.1.21RC1?
-- 
Jan

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] re2c version(s)

[Jan Ehrhardt]

Stanislav Malyshev in php.internals (Fri, 13 Jul 2018 11:40:12 -0700):
>> re2c is widely available on Linux distros nowadays (probably
>
>On Linux distros on common platforms (Intel/AMD) - sure. But what if you
>need an uncommon platform, or one that does not run Linux? It's those
>platforms where you'd have to build PHP from source (after all, PHP is
>also widely available as a package on Linux distros anyway) and adding
>another hassle of figuring out how to build a third-party tool - I don't
>think it's a good service to the community.

Directadmin just makes the tarballs from php.net available at every new
release. re2c is not even installed on my Directadmin powered CentOS 6
systems and bison is not used in the build process.

The Directadmin admins surely will not be happy if the generated files
are removed from the tarballs. And the Directadmin users will probably
not be happy either, because chances are high that new releases will
have a time delay. Currently a new PHP release is distributed through
Directadmin on the day of release.
-- 
Jan

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: libmbfl API changes in PHP 7.3

[Jan Ehrhardt]

Jan Ehrhardt in php.internals (Tue, 10 Jul 2018 15:39:39 +0200):
>"Christoph M. Becker" in php.internals (Tue, 10 Jul 2018 12:04:10
>+0200):
>>Have you tried to convert the first two arguments via mbfl_no2encoding()[1]?
>
>It compiles, but segfaults in 1 test on this line
>https://github.com/php/pecl-mail-mailparse/blob/master/mailparse.c#L1466

For anyone interested: it segfaults on Windows and Linux. No explication
yet:
https://github.com/php/pecl-mail-mailparse/pull/5#issuecomment-403990392
and following comments by Remi.
-- 
Jan

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: libmbfl API changes in PHP 7.3

[Jan Ehrhardt]

"Christoph M. Becker" in php.internals (Tue, 10 Jul 2018 12:04:10
+0200):
>Have you tried to convert the first two arguments via mbfl_no2encoding()[1]?

It compiles, but segfaults in 1 test on this line
https://github.com/php/pecl-mail-mailparse/blob/master/mailparse.c#L1466

Unhandled exception at 0x07FEEC6E83C2 (php7.dll) in php.exe:
0xC005: Access violation reading location 0x00060BE02800.
occurred

Relevant part of the backtrace:

[Inline Frame] php7.dll!zend_mm_alloc_small(_zend_mm_heap *) Line 1285
[Inline Frame] php7.dll!zend_mm_alloc_heap(_zend_mm_heap * heap,
unsigned __int64) Line 1356
php7.dll!_emalloc(unsigned __int64 size) Line 2496
[Inline Frame] php_mailparse.dll!zend_string_alloc(unsigned __int64)
Line 133
[Inline Frame] php_mailparse.dll!zend_string_init(const char *) Line 155
php_mailparse.dll!mailparse_get_part_data(_php_mimepart * part,
_zval_struct * return_value)

It passes all tests in PHP 7.2.8 RC1.

I will make a PR and continue the discussion there.
-- 
Jan

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: libmbfl API changes in PHP 7.3

[Jan Ehrhardt]

Jan Ehrhardt in php.internals (Tue, 10 Jul 2018 10:30:33 +0200):
>The change was introduced in this commit by nikic:
>https://github.com/php/php-src/commit/b3c1d9d1118438a3dae357db2b39ca5cfa25

What strikes me: this change was made to the master branch almost a year
ago, at the time PHP 7.2.0 Beta 1 was released. Weird moment for a BC
break.
-- 
Jan

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] libmbfl API changes in PHP 7.3

[Jan Ehrhardt]

While trying to make the mailparse extension fit for PHP 7.3 I ran into
changes in the libmbfl API. I cannot find any documentation on this
change.

The change was introduced in this commit by nikic:
https://github.com/php/php-src/commit/b3c1d9d1118438a3dae357db2b39ca5cfa25

To be specific:
https://github.com/php/php-src/commit/b3c1d9d1118438a3dae357db2b39ca5cfa25#diff-929fd74a8732776fa8776939a9b907d4L71

It broke the code of the mailparse extension at this line:
https://github.com/php/pecl-mail-mailparse/blob/master/php_mailparse_mime.c#L910

Shouldn't the be documented? And/or is there an easy fix?
-- 
Jan

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: PHP 7.3 zif_handler changes

[Jan Ehrhardt]

"Christoph M. Becker" in php.internals (Thu, 28 Jun 2018 12:56:43
+0200):
>Apparently, zval_ptr_dtor() had to be replaced with
>zval_internal_dtor() to avoid a segfault with PHP 7.3.  Is this caused
>by a change in the engine?  If so, is this change documented?

Another one: some extensioms suffer from the fact that the macro GC_G
was removed from
https://github.com/php/php-src/blob/master/Zend/zend_gc.h
Some of the removed functionality has been reintroduced in gc_status
https://github.com/php/php-src/commits/master/Zend/zend_gc.h

Examples using GC_G: v8js, xdebug, tideways.
v8js was using gc_active to check if garbage collection was running.
I did a wild guess to fix it:
https://github.com/Jan-E/v8js/commit/997df065d3cd06a9b11e399458c391eb797a850e#diff-dc446a69201ccda44a33d52f6c8c

Are the changes to zend_gc.h documneted?
-- 
Jan

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: RFCs �Under Discussion� targeting 7.3

[Jan Ehrhardt]

"Christoph M. Becker" in php.internals (Thu, 28 Jun 2018 15:31:25
+0200):
>There are several RFCs in the “Under Discussion” section[1] which target
>PHP 7.3, even though no discussion had happened during the last weeks if
>not months.  Since the feature freeze is approaching (scheduled for
>June, 17th)

June? Probably July, 17th.
-- 
Jan

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: PHP 7.3 zif_handler changes

[Jan Ehrhardt]

"Christoph M. Becker" in php.internals (Tue, 26 Jun 2018 13:15:32
+0200):
>On 26.06.2018 at 08:42, Jan Ehrhardt wrote:
>
>> https://github.com/php/php-src/blob/php-7.3.0alpha2/UPGRADING.INTERNALS
>>
>> pecl_http:
>> |php_http_client_curl_user.c(190): error C2440: '=': cannot convert from 
>> 'void (__cdecl *)(zend_execute_data *,zval *)' to 'zif_handler'

Mike fixed pecl_http:
https://github.com/m6w6/ext-http/commit/512f733beac73f37ba4acbcf730ebc6c6de849b6

But we ran into another undocumented change:
https://github.com/m6w6/ext-http/commit/377d576a6e68def5708cf1ffcd3c233c4dddf356
`zval_ptr_dtor` had to be replaced by `zval_internal_dtor`.
 
>> taint seems to have comparable errors. See
>> https://github.com/laruence/taint/commit/9debfe9682d22e172906cd2e7754a8380bf13453#commitcomment-29461798

I fixed taint:
https://github.com/laruence/taint/commit/9debfe9682d22e172906cd2e7754a8380bf13453#commitcomment-29510740

>> Can this be fixed and/or added to UPGRADING.INTERNALS?
>
>Apparently, zif_handler() has been changed to use the ZEND_FASTCALL
>calling convention[1] which results in this incompatibility.  Not sure
>if that should be reverted, or just documented in UPGRADING.INTERNALS.

Any news from the RM's on this?
-- 
Jan

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] PHP 7.3 zif_handler changes

[Jan Ehrhardt]

"Christoph M. Becker" in php.internals (Thu, 21 Jun 2018 12:28:49
+0200):
>For more information on the new features and other changes, you can read
>the NEWS file
>(), or the
>UPGRADING file
>() for a
>complete list of upgrading notes.  These files can also be found in the
>release archive.

Apparently, there were changes in the zend internal functions handler
(aka zif_handler), but I cannot find any info on it. Neither in the
linked documents, nor in
https://github.com/php/php-src/blob/php-7.3.0alpha2/UPGRADING.INTERNALS

I ran into this in at least three extensions, while compiling on Windows
(vc15, x64, nts).

pcs:
|PCS_Loader.c(575): error C2440: '=': cannot convert from 'zif_handler' to 
'void (__cdecl *)(zend_execute_data *,zval *)'
|PCS_Loader.c(581): error C2440: '=': cannot convert from 'zif_handler' to 
'void (__cdecl *)(zend_execute_data *,zval *)'
|PCS_Loader.c(587): error C2440: '=': cannot convert from 'zif_handler' to 
'void (__cdecl *)(zend_execute_data *,zval *)'

pecl_http:
|php_http_client_curl_user.c(190): error C2440: '=': cannot convert from 'void 
(__cdecl *)(zend_execute_data *,zval *)' to 'zif_handler'

taint seems to have comparable errors. See
https://github.com/laruence/taint/commit/9debfe9682d22e172906cd2e7754a8380bf13453#commitcomment-29461798

Can this be fixed and/or added to UPGRADING.INTERNALS?
-- 
Jan

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: memcache, without a d, as in Venezuela

[Jan Ehrhardt]

Rowan Collins in php.internals (Fri, 22 Jun 2018 23:40:27 +0100):
>However, it seems that the package without a d is actually abandoned. 
>The official PECL package was last released more than 5 years ago [3], 
>and the bug asking for PHP 7 compatibility is still open [4]. An 
>unofficial fork apparently supports PHP 7 [5] but it in turn hasn't had 
>a commit in 11 months, and has an open bug for 7.2 compatibility [6].

It has some PR's, even a recent one by Remi Collet for 7.3
compatibility.
https://github.com/websupport-sk/pecl-memcache/pull/30

The open bug for 7.2 compatibility seems to be open only because nobody
bothered to close it.

>- Is there any difference, other than API design, between the two 
>packages, which would merit seeking a new maintainer for memcache 
>(without a d)?

The package without a d is AFAIK the only one that runs on Windows:
https://github.com/websupport-sk/pecl-memcache/issues/23#issuecomment-358956029
Client & server updates by 'nono303':
https://www.apachelounge.com/viewtopic.php?t=7919
https://github.com/nono303/PHP7-memcache-dll

>- If not, should the package be officially marked "abandoned" or 
>"deprecated" in PECL, and in the PHP manual?

That would not be a good solution for the (few) Windows users.
-- 
Jan

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: PHP 7.1.13 and 7.2.1 Available

[Jan Ehrhardt]

Hi Chris,

"Christoph M. Becker" in php.internals (Fri, 5 Jan 2018 15:53:23 +0100):
>On 05.01.2018 at 14:55, Jan Ehrhardt wrote:
>
>>>> The main reason why I prefer the github zips over the zips at
>>>> http://windows.php.net/download/ is some kind of mismatch in the UTF-8
>>>> filenames:
>>
>> N:\php-sdk\win32sdk2
>> $ unzip -h
>> UnZip 6.00 of 20 April 2009, by Info-ZIP.  Maintained by C. Spieler.  Send
>> bug reports using http://www.info-zip.org/zip-bug.html; see README for 
>> details.
>
>From the release notes[1]:
>
>| Support for UTF-8 encoded entry names, both through PKWARE's "General
>| Purpose Flags Bit 11" indicator and Info-ZIP's new "up" unicode path
>| extra field. (Currently, on Windows the UTF-8 handling is limited to
>| the character subset contained in the configured non-unicode "system
>| code page".)
>
>So this might be a codepage issue.

The warnings do not occur when processing the zips from
https://github.com/php/php-src/releases so we know it must be possible
to produce zip-files with Unicode filenames without mismatch. Big
question is: how?

Jan

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: PHP 7.1.13 and 7.2.1 Available

[Jan Ehrhardt]

Hi Anatol,

Anatol Belski in php.internals (Fri, 5 Jan 2018 13:56:55 +):
>I don't reproduce this issue using
>http://windows.php.net/downloads/releases/php-7.2.1-src.zip . There is always a
>chance for a tool issue, especially when using an older tool or some without
>Unicode support. For zip, tools that work is the latest 7zip 16.04 or even
>explorer. Also using tar 1.29 and git 2.14.3 from the msysgit package looks
>fine for any tarballs. Seems like a tool issue, for what I could tell.

You can reproduce it, using unzip.exe from the msys2 package in the SDK,
https://github.com/Microsoft/php-sdk-binary-tools/tree/master/msys2/usr/bin

N:\php-sdk\win32sdk2
$ msys2\usr\bin\unzip php-7.2.1-src.zip > tmp.txt
php-7.2.1-src/ext/bz2/tests/003.txt.bz2:  mismatching "local"
filename
(php-7.2.1-src/ext/bz2/tests/003.txt.bz2),
 continuing with "central" filename version

Etc

Jan

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: PHP 7.1.13 and 7.2.1 Available

[Jan Ehrhardt]

Hi Sara,

Sara Golemon in php.internals (Fri, 5 Jan 2018 08:38:57 -0500):
>No, that was an accident.

OK. Next time will be perfect.

>> The main reason why I prefer the github zips over the zips at
>> http://windows.php.net/download/ is some kind of mismatch in the UTF-8
>> filenames:
>
>Wh? That's broken and we should try to fix it.  I'll say that the
>latest php-7.2.1 tarballs unpack fine for me. (e.g.
>ext/bz2/tests/003.txt.bz2) maybe you're missing a locale?
>
>> The "central" filename version is the correct one, like the filename at
>> https://github.com/php/php-src/tree/master/ext/bz2/tests
>>
>Okay, so you end up with the correct file on your filesystem, it's
>just a warning during untarring?

Yes. During un_zip_ping of
http://windows.php.net/downloads/releases/php-7.2.1-src.zip

>For the sake of reproducibility, what's your `tar --version`?

N:\php-sdk\win32sdk2
$ unzip -h
UnZip 6.00 of 20 April 2009, by Info-ZIP.  Maintained by C. Spieler.  Send
bug reports using http://www.info-zip.org/zip-bug.html; see README for details.
-- 
Jan

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: PHP 7.1.13 and 7.2.1 Available

[Jan Ehrhardt]

Jan Ehrhardt in php.internals (Fri, 05 Jan 2018 09:19:46 +0100):
>Sara Golemon in php.internals (Thu, 4 Jan 2018 12:06:59 -0500):
>>I'm happy to announce not one, but two new PHP releases today.
>>PHP 7.1.13 and 7.2.1 are ready to go at http://php.net/downloads.php
>
>Is it on purpose that the release-zip on github contains PHP 7.2.1-dev?
>See the main/php_version.h in the zip at
>https://github.com/php/php-src/releases

The main reason why I prefer the github zips over the zips at
http://windows.php.net/download/ is some kind of mismatch in the UTF-8
filenames:

php-7.2.1-src/ext/bz2/tests/003.txt.bz2:  mismatching
"local" filename (php-7.2
.1-src/ext/bz2/tests/003.txt.bz2),
 continuing with "central" filename version
php-7.2.1-src/ext/exif/tests/bug34704.jpg:  mismatching
"local" filename (php-7
.2.1-src/ext/exif/tests/bug34704.jpg),
 continuing with "central" filename version
php-7.2.1-src/ext/exif/tests/bug68113.jpg:  mismatching
"local" filename (php-7
.2.1-src/ext/exif/tests/bug68113.jpg),
 continuing with "central" filename version
php-7.2.1-src/ext/exif/tests/test2.jpg:  mismatching "local"
filename (php-7.2.
1-src/ext/exif/tests/test2.jpg),
 continuing with "central" filename version
etc.

The "central" filename version is the correct one, like the filename at
https://github.com/php/php-src/tree/master/ext/bz2/tests

The zips at github do not have the mismatch and do contain the correct
filenames. So github seems to handle UTF-8 filenames in better way than
https://github.com/php/php-src/commit/3d3f11ede4cc7c83d64cc5edaae7c29ce9c6986f
-- 
Jan

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: PHP 7.1.13 and 7.2.1 Available

[Jan Ehrhardt]

Sara Golemon in php.internals (Thu, 4 Jan 2018 12:06:59 -0500):
>I'm happy to announce not one, but two new PHP releases today.
>PHP 7.1.13 and 7.2.1 are ready to go at http://php.net/downloads.php

Is it on purpose that the release-zip on github contains PHP 7.2.1-dev?
See the main/php_version.h in the zip at
https://github.com/php/php-src/releases
-- 
Jan

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: Public Tags of Releases

[Jan Ehrhardt]

Anatol Belski in php.internals (Tue, 28 Nov 2017 19:29:41 +):
>By the current terms - there's no release until the announcement. Tags
>are a virtually internal thing. For a number of people the tarball is
>the actual release. The Windows builds are done from the tag, that's
>specific.

FWIW: I am using the zip's at github, like
https://github.com/php/php-src/archive/php-7.2.0.zip
-- 
Jan

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: [PHP-WEBMASTER] Subscribe Function Seems to be down for several days

[Jan Ehrhardt]

Alan Feuerbacher in php.internals (Wed, 16 Aug 2017 15:33:10 -0600):
>On 8/16/2017 10:25 AM, Hannes Magnusson wrote:
>> If that still doesn't work, try sending empty mail to
>> -subscr...@lists.php.net
>> (e.g. internals-subscr...@lists.php.net)
>
>general-subscr...@lists.php.net

Try php-general-subscr...@lists.php.net
-- 
Jan

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: PHP 7.2.0 Beta 1 released

[Jan Ehrhardt]

Rasmus Lerdorf in php.internals (Sat, 22 Jul 2017 09:22:07 -0400):
>Ok, so it is a normal E_WARNING and not the source of the fatal error you
>hit. You must have something else going on. Perhaps a custom error handler
>turning it into a fatal, although that also hasn't changed from 7.1.

Drupal7 has a custom error handler, but I did not expect it to differ
from PHP 7.1 to 7.2. But apparently, it does. Will dig deeper.

As a side note: I could reproduce the fatal error on a CentOS6 machine
with PHP 7.2.0 Beta 1, so it is not Windows-only.
-- 
Jan

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: PHP 7.2.0 Beta 1 released

[Jan Ehrhardt]

Rasmus Lerdorf in php.internals (Sat, 22 Jul 2017 08:07:55 -0400):
>On Sat, Jul 22, 2017 at 12:32 AM, Jan Ehrhardt <php...@ehrhardt.nl> wrote:
>
>> Your example issues an E_STRICT warning, in both PHP 7.2 nts x64 and PHP
>> 7.1 nts x64, so it must be caused by something else.
>
>Are you sure you are even running PHP 7? This type of code hasn't issued an
>E_STRICT since PHP 5.

I am sure I am running PHP 7, not sure it is E_STRICT in 7.0 & 7.1. Just misread
your statement "Even in 5.6 and 5.5 it was an E_STRICT", I suppose.

With the 80-character line-breaks:

C:\phpdev\php72nts.x64>php ..\class.php

C:\phpdev\php72nts.x64>tail -n1 \phpdev\php72nts.x64.log
[22-Jul-2017 14:17:55 Europe/Paris] PHP Warning:  Declaration of C::form(&$form,
 &$form_state, $options = Array) should be compatible with P::form(&$form, &$for
m_state, $options = Array, $iterator = NULL) in C:\phpdev\class.php on line 7

C:\phpdev\php72nts.x64>php -v
PHP 7.2.0beta1 (cli) (built: Jul 21 2017 19:20:33) ( NTS MSVC15 (Visual C++ 2017
) x64 )
Copyright (c) 1997-2017 The PHP Group
Zend Engine v3.2.0-dev, Copyright (c) 1998-2017 Zend Technologies
with Zend OPcache v7.2.0beta1, Copyright (c) 1999-2017, by Zend Technologies
-- 
Jan

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Status of thread safety in PHP 7.0 & 7.1 ZTS?

[Jan Ehrhardt]

Quoting https://twitter.com/krakjoe/status/887743571515912196

>Just FYI ... Thread safety in PHP 7.0 and 7.1 is broken: If you are
>using ZTS upgrade to 7.2 ... peril awaits those who ignore this warning

Should we ditch PHP 7.0 ZTS and PHP 7.1 ZTS?

I ran into this while discussing the pthreads extension:
https://github.com/krakjoe/pthreads/pull/720#issuecomment-317177130
-- 
Jan

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: PHP 7.2.0 Beta 1 released

[Jan Ehrhardt]

Rasmus Lerdorf in php.internals (Fri, 21 Jul 2017 22:15:13 -0400):
>On Fri, Jul 21, 2017 at 9:50 PM, Jan Ehrhardt <php...@ehrhardt.nl> wrote:
>
>> The case: class RulesActionContainerUI has a public function form:
>> > public function form(&$form, &$form_state, $options = array(), $iterator
>> = NULL) {
>>
>> class RulesRuleUI extends RulesActionContainerUI with a public function
>> > public function form(&$form, &$form_state, $options = array()) {
>>
>> Bad programming, but no PHP ever stumbled over it. PHP 7.2.0 Beta 1
>> issues a fatal error that RulesRuleUI::form must be compatible with
>> RulesActionContainerUI::form. IMHO a valid remark, but still a BC break.
>> Is this documented anywhere? Or should the Fatal Error become less
>> fatal?
>
>This sounds strange. This hasn't changed in 7.2. It was the same in 7.1 and
>7.0. Even in 5.6 and 5.5 it was an E_STRICT. Unless the Windows version has
>somehow drifted, but I don't see how that would be possible. Are you sure
>it isn't caused by something else?

Your example issues an E_STRICT warning, in both PHP 7.2 nts x64 and PHP
7.1 nts x64, so it must be caused by something else.

I have no faint idea (yet) what causes it. I am doing exactly the same:
switch the config from PHP 7.1 as mod_fcgid to PHP 7.2 as mod_fcgid (or
vice versa), restart Apache (2.4.27) and run 'Flush all caches'. Under
PHP 7.2 I get a fatal error and under PHP 7.1 I do not even get a
warning.

The php.ini's are exactly the same, except for the location of the
error_log. Under PHP 7.2, I am also getting a lot of warnings for
deprecated things:
- create_function()
- each()
- count() on a non-Countable variable
Those were expected. But why Drupal7 transforms one warning into a fatal
error beats me.

Talking about bad programming, this was the weirdest each(), found in
menu.inc:
> list($function, $args) = each($function);
each() is supposed to advance the array pointer, but for which
$function? The first or the last in the statement?
-- 
Jan

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: PHP 7.2.0 Beta 1 released

[Jan Ehrhardt]

Hi Sara,

Sara Golemon in php.internals (Thu, 20 Jul 2017 08:13:39 -0400):
>The first beta for 7.2.0 was just released and can be downloaded from:
>https://downloads.php.net/~pollita/
[snip]
>Please test it carefully, and report any bugs in the bug system.

I tried running Drupal7 with 7.2.0 Beta 1 and ran into a fatal error,
that does not happen under PHP 7.1.x (Windows, NTS, x64). I do not know
if it is a bug, an omission in UPGRADING or me looking with my nose.
Therefore I did not file a bugreport yet.

The case: class RulesActionContainerUI has a public function form:
> public function form(&$form, &$form_state, $options = array(), $iterator = 
> NULL) {

class RulesRuleUI extends RulesActionContainerUI with a public function
> public function form(&$form, &$form_state, $options = array()) {

Bad programming, but no PHP ever stumbled over it. PHP 7.2.0 Beta 1
issues a fatal error that RulesRuleUI::form must be compatible with
RulesActionContainerUI::form. IMHO a valid remark, but still a BC break.
Is this documented anywhere? Or should the Fatal Error become less
fatal?
-- 
Jan

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: PHP 7.2 forked

[Jan Ehrhardt]

Hi Anatol.

Anatol Belski in php.internals (Wed, 19 Jul 2017 13:37:59 +):
>Hi Jan,
>
>> Congrats. Question, maybe for Anatol: what did change in the Windows Build
>> environment? It was taking ages for 'Generating code', for each extension. 
>> Now
>> it is as fast as building PHP 7.1.
>
>There is no change in the build process, disregarding the requirement on
>the new SDK. The build efficiency usually depends on the power of the
>build host. What I can only guess, is that the removal of /LTCG for non
>PGO build could improve build speed on a less powerful machine. That
>option was added in master, but had to be removed due to compatibility
>issues.

The difference was very substantial on my Lenovo X220 with an Intel Core
i7 2620M (2.7GHz). Of course, I was already using the new SDK.
-- 
Jan

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: Minimum MySQL version

[Jan Ehrhardt]

Nikita Popov in php.internals (Tue, 18 Jul 2017 21:37:07 +0200):
>I just found out that some of the PDO code contains MySQL version checks
>going all the way back to MySQL 3.22.30, which has been released in 2000.
>
>What is the minimum MySQL version we support? can I drop checks for MySQL
>3.x and 4.x?

The Windows builds come bundled with MySQLND 5.0.8-dev (PHP 5.3) up
until MySQLND 5.0.12-dev (PHP 7.2). Even PHP 5.1 was distributed with a
MySQL 5.0.x version, so dropping MySQL 3.x and 4.x seems perfectly
valid.
-- 
Jan

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: PHP 7.2 forked

[Jan Ehrhardt]

Sara Golemon in php.internals (Tue, 18 Jul 2017 10:48:16 -0400):
>That's it! Feature freeze is on.

Congrats. Question, maybe for Anatol: what did change in the Windows
Build environment? It was taking ages for 'Generating code', for each
extension. Now it is as fast as building PHP 7.1.
-- 
Jan

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] [Discussion] UUID

[Jan Ehrhardt]

"Christoph M. Becker" in php.internals (Wed, 24 May 2017 18:35:08
+0200):
>On 24.05.2017 at 18:25, Remi Collet wrote:
>
>> And I also think using system libuuid is better than reinventing the
>> wheel, and having to maintain a uuid algo, when already maintained by
>> someone else, which only work on these algo.
>
>What about Windows support?

UuidCreate:
https://msdn.microsoft.com/en-us/library/windows/desktop/aa379205(v=vs.85).aspx
The Apache Portable Library (APR) uses it for a long, long time:
http://svn.apache.org/viewvc/apr/apr/branches/1.4.x/misc/win32/rand.c?view=markup#l65
-- 
Jan

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: Improve hash_hkdf() parameter

[Jan Ehrhardt]

wout van gils in php.internals (Thu, 13 Apr 2017 15:13:40 +):
>Kan iemand mij eindelijk eens uitschrijven.?

Dat moet je zelf doen:
http://php.net/mailing-lists.php
Onderaan.
-- 
Jan

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: windows.php.net is moving to new IP

[Jan Ehrhardt]

"Anatol Belski" in php.windows (Tue, 17 Jan 2017 20:14:55 +0100):
>I'm writing to inform, that the current Windows infrastructure hosting
>sponsor doesn't plan to support the project anymore. Furthermore, a
>notification was given, that the servers will be taken down within a couple
>of next weeks. Alex Schoenmaker found another sponsor, so all the HW will
>have to be moved to a new place. As a consequence, some shortages are to
>expect. The particular date for the move is 3pm-4pm CET on Friday 20th
>January.

windows.php.net is down at the moment. What is happening?
-- 
Jan

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: windows.php.net is moving to new IP

[Jan Ehrhardt]

"Anatol Belski" in php.internals (Tue, 17 Jan 2017 20:14:55 +0100):
>I'm writing to inform, that the current Windows infrastructure hosting
>sponsor doesn't plan to support the project anymore. Furthermore, a
>notification was given, that the servers will be taken down within a couple
>of next weeks.

Just curious: what kind of boxes are we talking about? Can we get some
insight in CPU's, RAM, OS and storage space and speed?

BTW: kudos for the new sponsor.
-- 
Jan

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Distrust SHA-1 Certificates

[Jan Ehrhardt]

Jakub Zelenka in php.internals (Sun, 27 Nov 2016 19:37:50 +):
>At the time the PHP 7.2 is out, there will be much bigger usage of OpenSSL
>1.1 and the users on lower version could still disable it manually.

I sure hope so. What concerns me is that there is no movement at all to
add OpenSSL 1.1 support to Apache. It could take longer than you think
for a broad support of OpenSSL 1.1.
-- 
Jan

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Distrust SHA-1 Certificates

[Jan Ehrhardt]

Jakub Zelenka in php.internals (Sun, 27 Nov 2016 19:37:50 +):
>On Sun, Nov 27, 2016 at 3:17 PM, Niklas Keller  wrote:
>> That may be true, but we only raised the minimum requirement for newer
>> versions of PHP. If this is going to be backported for PHP 5.6 / 7.0 / 7.1,
>> we have to support those older OpenSSL versions I guess?
>>
>>
>Well it depends if it requires feature available only in the later version
>of OpenSSL  which would be the case for the currently proposed version of
>the RFC that would make use of SSL_CTX_set1_sigalgs_list macro. I don't
>think that we should parse the string of allowed sig algs and re-implement
>it for OpenSSL versions that are EOL anyway. It's not something unusual to
>have a feature dependent on the library version. For example we did exactly
>the some for openssl_pbkdf2 that worked only if it was compiled with
>OpenSSL 1.0.0+. So if you had PHP 7.0 and OpenSSL 0.9.8, it wasn't
>available.

As a side note: I haven't yet met an extension that does not compile
with OpenSSL 1.0.2. For a long time now, all my PHP 5.3, 5.4, 5.5 and
5.6 (Windows) builds are compiled with OpenSSL 1.0.2.
-- 
Jan

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: [RFC] Deprecations for PHP 7.2

[Jan Ehrhardt]

Nikita Popov in php.internals (Fri, 18 Nov 2016 15:55:23 +0100):
>https://wiki.php.net/rfc/deprecations_php_7_2
>
>The RFC combines a number of deprecation and removal proposals. Each one
>will get a separate 2/3 majority vote. The RFC overlaps with some recently
>discussed topics (each, binary strings)

I must have missed the discussion about each(). And this really
surprised me:

> The each() function is inferior to foreach in pretty much every
> imaginable way, including being more than 10 times slower.

But it is mentioned in a 9-year old comment in the manual:
https://php.net/manual/en/function.each.php#75692

A quick grep in my Drupal7 source code showed that not everybody is
aware of that. For instance, even the views module use a list() = each()
construction:
http://cgit.drupalcode.org/views/tree/includes/view.inc#n1740
This means that at least 800,000 sites use list() = each() at the
moment.

I am fine with deprecation, but this may be more wide spread than one
might assume.
-- 
Jan

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PHP-7.1.0RC6

[Jan Ehrhardt]

Stephen Zarkos in php.internals (Wed, 9 Nov 2016 14:44:17 +):
>FYI - the Windows builds for 7.1.0RC6 are uploaded.

This confirms, what I already noticed myself. There has been a change in
the Windows build process: the *.pdb files of the dependencies are added
to the debug pack now. I do not mind, but was surprised to see it
happen.
-- 
Jan

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PHP 5.5 update this week?

[Jan Ehrhardt]

Stanislav Malyshev in php.internals (Mon, 18 Jul 2016 13:49:08 -0700):
>> Excellent, I knew 5.5 was EOL, but with those 2 outstanding commits, I
>> figured a new version would be published.
>
>The next release will be the last planned for 5.5. I assume there will
>be announcement to that effect soon.

Just curious: will there be a fix for CVE-2016-5385 (httpoxy) in PHP? If
so, will it be in PHP 5.5.38 as well?

Details:
https://httpoxy.org/#cve
-- 
Jan

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PHP 7.1.0alpha1 is available for testing

[Jan Ehrhardt]

Remi Collet in php.internals (Sun, 12 Jun 2016 08:17:35 +0200):
>Le 11/06/2016 à 19:01, Jan Ehrhardt a écrit :
>> Probably you know best, but isn't ssh2 ready for PHP7+?
>> http://git.php.net/?p=pecl/networking/ssh2.git;a=summary
>
>IIRC, ssh2 is not yet fully ported to PHP 7

OK, thanks.
 
>> couchbase 2.2.0beta3 has some troubles with xdebug (on Windows). I will
>> have to find out what causes this.

This seems to have been resolved in xdebug 2.5.0-dev, once you get it to
compile: https://github.com/Jan-E/xdebug/commits/master

Other extensions that did compile for PHP 7.0, but failed for PHP 7.1 (on
Windows):

php_astkit.dll 
php_msgpack.dll 
php_rar.dll 
php_v8js.dll

But I now see you have a fix for msgpack:
https://github.com/msgpack/msgpack-php/pull/87

For php7/rar I am using this repo:
https://github.com/esminis/php_pecl_rar

v8js: https://github.com/phpv8/v8js
astkit: https://github.com/sgolemon/astkit
-- 
Jan

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php