Re: [PHP-DEV] PHP 7.2.0 Released

[Hannes Magnusson]

> - Improve TLS constants to sane values


This worries me a lot. Last time someone thought it was a good idea they
introduced security vulnerability for all apps that used them.

Do you have a link to this commit ?

-Hannes

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

[Hannes Magnusson]

 how are you trying to subscribe?

Are you submitting the http://php.net/mailing-lists.php form? In which
case, which mirror are you looking at? Could you try another mirror?
If that still doesn't work, try sending empty mail to
-subscr...@lists.php.net
(e.g. internals-subscr...@lists.php.net)

If you are not using that form, but are sending the subscribe email,
please forward the full original reply you get.

-Hannes


On Tue, Aug 15, 2017 at 9:40 AM, Alan Feuerbacher  wrote:
> On 8/3/2017 9:06 AM, Andreas Heigl wrote:
>>
>> Seems like the mailinglist needs some love… again…
>>
>> Cheers
>>
>> Andreas
>>
>>
>> Am 03.08.17 um 17:02 schrieb Alan Feuerbacher:
>>>
>>> I've been trying for several days to subscribe to a PHP mailing list,
>>> but I keep getting the message "We were unable to subscribe you due to
>>> some technical problems. Please try again later."
>>>
>>> Is there any way to fix this?
>>>
>
> Hi,
>
> It has been close to two weeks since I emailed PHP about the mailing lists.
> Has there been any activity getting it working again?
>
> Alan

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

Re: [PHP-DEV] RFC karma?

[Hannes Magnusson]

I've added that user to the rfc group.

I've also added you to the wiki admin group.

-Hannes


On Tue, Mar 21, 2017 at 9:29 PM, Sara Golemon  wrote:

> The author of https://github.com/php/php-src/pull/1927 wants RFC karma
> to propose some dynamic variable enhancements.  Could someone with
> karma karma help them out?
>
> -Sara
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

[PHP-DEV] Re: Generating release verification stub

[Hannes Magnusson]

On Thu, Aug 6, 2015 at 9:47 AM, Anatol Belski anatol@belski.net wrote:

 Hi,

 as we put several verification info into the announcement mails, and after
 doing it a couple of times manually, I've invented this quick solution.

 https://gist.github.com/weltling/2d2972aa5325ee3b530c

 I would suggest to take it into the scripts/ and to adjust the
 corresponding
 release process document part. It's a bit raw yet, but does the job and can
 be improved later. This way we can standardize the matter and avoid c/p
 mistakes.



+1

I think there is a typo on line#30, missing $

-Hannes

[PHP-DEV] Re: use https when downloading the pear installer

[Hannes Magnusson]

On Mon, Jul 27, 2015 at 12:32 AM, Ferenc Kovacs tyr...@gmail.com wrote:
 Hi,

 I've just realized that even thought https://pear.php.net/ is available, we
 are still downloading the install-pear-nozlib.phar via http:// in
 pear/Makefile.frag and makedist
 Do you happen to know any reason for keeping it that way or is this only for
 historical reasons (maybe pear.php.net did not have proper cert or
 configured to accept traffic on 443 originally when the download process was
 created) and should be ok to make this more secure(as it would prevent MITM
 attacks).

 What do you think?

I think nice catch *hat tip*.

I'm pretty sure noone cared when this was written ~10 years ago -- we
didn't even have any certificate issued, not even CAcert at that
point.


-Hannes

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

Re: [PHP-DEV] RFE to allow dirname($foo, 2)

[Hannes Magnusson]

On Wed, Jul 22, 2015 at 4:55 AM, Remi Collet r...@fedoraproject.org wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 See https://bugs.php.net/bug.php?id=70112


 As this a very small self-contained change,
 I don't think it needs a RFE.

 Feedback welcome




Shouldn't you check if you are at the root (or cwd)?
currently dirname(/foo/bar, PHP_INT_MAX); hangs


-Hannes

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

Re: [PHP-DEV] Re: Resetting wiki.php.net password

[Hannes Magnusson]

On Wed, Jul 22, 2015 at 9:34 AM, Christoph Becker cmbecke...@gmx.de wrote:
 Hannes Magnusson wrote:

 On Wed, Jul 22, 2015 at 7:26 AM, Christoph Becker cmbecke...@gmx.de wrote:
 Matt Tait wrote:

 I'm currently trying to reset my wiki.php.net password so I can propose an
 RFC, but unfortunately I'm getting the following error messages when I
 reset it via the page https://wiki.php.net/start?do=resendpwd:

 ! Unable to modify user data. Please inform the Wiki-Admin
 ! error modifying user data

 Who is the Wiki-Admin? How can I go about contacting them so I can gain
 access to the Wiki?

 I think that this functionality is not supposed to work (I'll have a
 look at how to disable it), because the password for the Wiki is the
 password for the general php.net account.  To reset the password follow
 https://master.php.net/forgot.php (which is already linked from the
 Wiki start page).

 He doesn't have PHP karma -- so it should have worked. idk why it didn't.

 But Matt is listed on people.php.net:
 http://people.php.net/user.php?username=matttait. :S



Hah!

Ok. Matt, please use https://master.php.net/forgot.php if you don't
remember your php.net VCS password.

As for your wiki account, its useless.
Please use your php.net VCS account to login to the wiki.
It will override your wiki account as its a dud.

-Hannes

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

Re: [PHP-DEV] Re: Resetting wiki.php.net password

[Hannes Magnusson]

On Wed, Jul 22, 2015 at 7:26 AM, Christoph Becker cmbecke...@gmx.de wrote:
 Matt Tait wrote:

 I'm currently trying to reset my wiki.php.net password so I can propose an
 RFC, but unfortunately I'm getting the following error messages when I
 reset it via the page https://wiki.php.net/start?do=resendpwd:

 ! Unable to modify user data. Please inform the Wiki-Admin
 ! error modifying user data

 Who is the Wiki-Admin? How can I go about contacting them so I can gain
 access to the Wiki?

 I think that this functionality is not supposed to work (I'll have a
 look at how to disable it), because the password for the Wiki is the
 password for the general php.net account.  To reset the password follow
 https://master.php.net/forgot.php (which is already linked from the
 Wiki start page).


He doesn't have PHP karma -- so it should have worked. idk why it didn't.

But he doesn't have wiki karma either, so I'm not sure why he is
resetting the password anyway -- Matt, you can't do anything with that
account.
I think in fact, a loggedout user has more privileges then default
registered wiki account.


-Hannes

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

Re: [PHP-DEV] Re: Resetting wiki.php.net password

[Hannes Magnusson]

On Wed, Jul 22, 2015 at 3:37 PM, Christoph Becker cmbecke...@gmx.de wrote:
 Hannes Magnusson wrote:

 As for your wiki account, its useless.
 Please use your php.net VCS account to login to the wiki.
 It will override your wiki account as its a dud.

 Wouldn't it be reasonable then to disable the password reset
 functionality?  This can easily be done in the admin panel by checking
 Disable DokuWiki Settings - Set new password (see
 https://www.dokuwiki.org/config:disableactions).

 And maybe we should consider to deactivate the Wiki registration
 completely, and instead link to the Git account request page.




Every blue moon there is a person without VCS account that would like
to write an RFC.
That must be possible.

-Hannes

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

Re: [PHP-DEV] Wiki access for ihabunek

[Hannes Magnusson]

Done.

-Hannes


On Thu, Jun 25, 2015 at 8:39 AM, Ivan Habunek ivan.habu...@gmail.com wrote:
 Hello PHP ppl,

 I'd like to update the build instructions for windows for building PHP
 7 with VC14:
 https://wiki.php.net/internals/windows/stepbystepbuild

 For this I would need write access, my wiki username is ihabunek.

 Thanks,
 Ivan

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


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

Re: [PHP-DEV] Headsup: PHP7 feature freeze

[Hannes Magnusson]

On Thu, Jun 25, 2015 at 6:42 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
 Hi all,

 On Fri, Jun 26, 2015 at 12:03 AM, Kalle Sommer Nielsen ka...@php.net
 wrote:

 This is a  quick heads up that we plan to have the next release of
 7.0.0 be Beta 1, this marks a feature freeze and from there on, we
 will switch focus on to stabilization, regressions and other bug
 fixes.

 Beta 1 is schedule to be tagged and packaged on July 7th and released
 on July 9th which is a small 2 weeks from now to get any remaining
 changes of such in.

 If you are in doubt about whether or not your change would be
 considered a 'feature' or have any other questions, then feel free to
 mail us RMs or reply here.


 I would like to rename _undocumented_ method name in Session module.
 http://php.net/manual/en/book.session.php

 The line is this.
 https://github.com/php/php-src/blob/master/ext/session/php_session.h#L334

 create_sid() method should be createSid(). If some users used it, all they
 have
 to do is define copy of create_sid() method and compatibility is kept.
 Any comments?


Why do you think its undocumented?
http://php.net/manual/en/sessionhandler.create-sid.php

-Hannes

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

Re: [PHP-DEV] Announcing PHP 5.5 security-only

[Hannes Magnusson]

On Mon, Jun 22, 2015 at 5:09 AM, Julien Pauli jpa...@php.net wrote:
 Hi internals.


 As you may know/remember , PHP 5.5 has been released two years ago.
 We've released 26 versions so far (24 would be the normal computing, but
 we always got some bad releases, mainly from human failure factor).

 The actual stable 5.5 is PHP 5.5.26.
 This week, I'm going to tag the last 5.5 RC : 5.5.27RC.
 Then will follow the *last* normal process 5.5 release : 5.5.27.

 ***
 The PHP 5.5 branch is going to enter in security only, and in the same
 time, PHP 5.4 will finally die
 ***



You should mail such a headsup to announce@ couple of months before
the final release date.
So if September 14th is the final release date, I'd say sending a
REMINDER: 5.4 GOES SECURITY ONLY SEPT 14th mail to announce@ July
14th (or August 14th?) would be nice.



-Hannes

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

[PHP-DEV] Re: [PHP-CVS] com php-src: PHP7 sounds like a good time to include signatures in announce mails: README.RELEASE_PROCESS

[Hannes Magnusson]

On Wed, Jun 24, 2015 at 11:20 AM, Stanislav Malyshev
smalys...@gmail.com wrote:
 Hi!

 The change sounds reasonable.

 I would like just to ask you for the future - please discuss before
 adding a change to the release process. It were probably also good to
 hear from the other RMs doing the job for longer whether they agree
 with this. Ferenc, Julien, Stas - is such a change ok with you?

 OK with me, though I'd appreciate the notification/discussion - I may
 have easily missed the commit and I don't re-read the README each time,
 so having explicit note would help. Since we want to have uniform
 release policies, I assume this applies to all active branches, not just
 master.

 I'm not sure it also makes sense to include both hashes, sha256 should
 be enough.


I have no preference on what to do with the current 5.x releases.
I think PHP7 is a prefect time to improve our routines and release model.
If I ever find time I'll work on the release box we talked about
earlier. For now, I just want to make sure we publish these things in
as many locations as possible.

-Hannes

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

Re: [PHP-DEV] php 7/git buid on linux/64: fatal error @ 'Installing PEAR environment';

[Hannes Magnusson]

On Tue, Jun 16, 2015 at 9:14 AM, Sebastian Bergmann sebast...@php.net wrote:
 Am 16.06.2015 um 18:10 schrieb Ferenc Kovacs:
 did not have more time to test though, so any feedback is appreciated.

  I still think that the right solution would be to simply not bundle /
  install PEAR anymore.



That probably needs RFC. But we must be able to install pecl
extensions, one way or another.
If the pecl packaging can be replaced with tar archive, or even github
style release downloads, then installing won't require pear.


-Hannes

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

[PHP-DEV] PHP7 releases vs Windows Sources?

[Hannes Magnusson]

What is the difference between Windows Sources and our official releases?

Did windows.php.net fork php or something? Embedded other things?
Are the binaries really not generated from the official sources?
This sounds like a horrible idea if true.


-Hannes


On Mon, Jun 15, 2015 at 5:39 AM, Anatol Belski a...@php.net wrote:
 Commit:9883c8f0bbcb64ad42ce66d694fffd848fc2ebcc
 Author:Anatol Belski a...@php.net Mon, 15 Jun 2015 14:39:31 
 +0200
 Parents:   d7f7d44e25c4bb43de7696db47189026428daaac
 Branches:  master

 Link:   
 http://git.php.net/?p=web/php.git;a=commitdiff;h=9883c8f0bbcb64ad42ce66d694fffd848fc2ebcc

 Log:
 apply patch from bug #69829

 And, we probably should keep this wording in the next announcement

 Bugs:
 https://bugs.php.net/69829

 Changed paths:
   M  archive/entries/2015-06-11-3.xml


 Diff:
 diff --git a/archive/entries/2015-06-11-3.xml 
 b/archive/entries/2015-06-11-3.xml
 index 232dcee..be5d386 100644
 --- a/archive/entries/2015-06-11-3.xml
 +++ b/archive/entries/2015-06-11-3.xml
 @@ -43,7 +43,7 @@

   p
For source downloads of PHP 7.0.0 Alpha 1 please visit
 -  the a href=https://downloads.php.net/ab/;download page/a, Windows 
 binaries
 +  the a href=https://downloads.php.net/ab/;download page/a, Windows 
 sources and binaries
can be found on a 
 href=http://windows.php.net/qa/;windows.php.net/qa//a.
   /p


 --
 PHP Webmaster List Mailing List (http://www.php.net/)
 To unsubscribe, visit: http://www.php.net/unsub.php


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

Re: [PHP-DEV] PHP7 releases vs Windows Sources?

[Hannes Magnusson]

Then this fix doesn't make any sense -- you are saying if I download
the .tar.gz and .zip and extract those two, I will have precisely the
same sources?
Then this fix should be reverted as there is isn't any special Windows
Sources and the official releases should work just fine.

-Hannes


On Mon, Jun 15, 2015 at 7:02 AM, Anatol Belski anatol@belski.net wrote:
 Hi Hannes,

 Nope, it's the same source and the same tag is always used. The tag is the 
 actual reference for any release. But usually people on Windows don't have 
 things like tar,gz and others. Even if they have - the compatibility might be 
 just bad. So it's zipped.

 Regards

 Anatol

 -Original Message-
 From: Hannes Magnusson [mailto:hannes.magnus...@gmail.com]
 Sent: Monday, June 15, 2015 3:52 PM
 To: Anatol Belski; PHP Development
 Cc: PHP Webmaster ML
 Subject: [PHP-DEV] PHP7 releases vs Windows Sources?

 What is the difference between Windows Sources and our official releases?

 Did windows.php.net fork php or something? Embedded other things?
 Are the binaries really not generated from the official sources?
 This sounds like a horrible idea if true.


 -Hannes


 On Mon, Jun 15, 2015 at 5:39 AM, Anatol Belski a...@php.net wrote:
  Commit:9883c8f0bbcb64ad42ce66d694fffd848fc2ebcc
  Author:Anatol Belski a...@php.net Mon, 15 Jun 2015 14:39:31 
  +0200
  Parents:   d7f7d44e25c4bb43de7696db47189026428daaac
  Branches:  master
 
  Link:
 http://git.php.net/?p=web/php.git;a=commitdiff;h=9883c8f0bbcb64ad42ce66d6
 94fffd848fc2ebcc
 
  Log:
  apply patch from bug #69829
 
  And, we probably should keep this wording in the next announcement
 
  Bugs:
  https://bugs.php.net/69829
 
  Changed paths:
M  archive/entries/2015-06-11-3.xml
 
 
  Diff:
  diff --git a/archive/entries/2015-06-11-3.xml
  b/archive/entries/2015-06-11-3.xml
  index 232dcee..be5d386 100644
  --- a/archive/entries/2015-06-11-3.xml
  +++ b/archive/entries/2015-06-11-3.xml
  @@ -43,7 +43,7 @@
 
p
 For source downloads of PHP 7.0.0 Alpha 1 please visit
  -  the a href=https://downloads.php.net/ab/;download page/a,
 Windows binaries
  +  the a href=https://downloads.php.net/ab/;download page/a,
  + Windows sources and binaries
 can be found on a
 href=http://windows.php.net/qa/;windows.php.net/qa//a.
/p
 
 
  --
  PHP Webmaster List Mailing List (http://www.php.net/) To unsubscribe,
  visit: http://www.php.net/unsub.php
 

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



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

Re: [PHP-DEV] PHP7 releases vs Windows Sources?

[Hannes Magnusson]

On Mon, Jun 15, 2015 at 8:38 AM, Anatol Belski anatol@belski.net wrote:
 Hi Johannes,

 -Original Message-
 From: Johannes Schlüter [mailto:johan...@schlueters.de]
 Sent: Monday, June 15, 2015 4:52 PM
 To: Christoph Becker
 Cc: Hannes Magnusson; Anatol Belski; PHP Development; PHP Webmaster ML
 Subject: Re: [PHP-DEV] PHP7 releases vs Windows Sources?

 On Mon, 2015-06-15 at 16:20 +0200, Christoph Becker wrote:
  Hannes Magnusson wrote:
 
   Then this fix doesn't make any sense -- you are saying if I download
   the .tar.gz and .zip and extract those two, I will have precisely
   the same sources?
   Then this fix should be reverted as there is isn't any special
   Windows Sources and the official releases should work just fine.
 
  There is some difference (timestamps?) which causes building from the
  tarred sources to fail on Windows (see bug #69829).

 touching generated files as part of the packaging process is a good idea 
 for all
 platforms.

   Furthermore
  extracting the tarred sources with 7zip (which seems to be a pretty
  common archiver) results in spurious PaxHeaders.# directories,
  what is bug in 7zip[1], and doesn't really affect the build, but is
  confusing nonetheless (and requires more disk space).
 
  At least until these issue are solved, IMO it's better to link to the
  Windows sources packaged as .zip.

 If there is a need for zip archives I'd put them next to tar.gz etc. and 
 distribute
 them via our mirror network.

 Yep, this could work and were probably proper solution. Except we wouldn't 
 add some issue for the non Windows users :) I'm not sure, why is it done so 
 ATM, probably it has its historical reasons. But this would probably cause us 
 need to update the release process procedure? And, for PHP7 or for any other 
 as well? Currently that zipball is just generated with the build process, so 
 it'll need to be sent over somehow. Were anyway doable,  wondering what the 
 other RMs would say. Frankly, I'd leave it as it is - as long as it's 
 reachable and documented.




Thats what we want. We want the official release balls to be generated
by an official server using the official toolchain.
There should never be a time when a Release Manager pulls up his
notebook, does a checkout and packages that and uploads. Its bad
enough we have this for pecl exts, but there is no reason for php-src
to be playing with fire and infiltration agencies.

That has unfortunately happened before, and resulted in us
distributing .orig files (patch conflicts), .exp, .out, .php, ...
(failed tests results) and even wrongly generated artifacts (due to
wrong bison/re2c versions installed locally).

We don't want that happen again.
The official releases should be done on snap box, and be completely
automated with no room for accidents.
It produces several archives, and we can add .zip to that mix if not
already available.

It should be obvious that any binary distribution that aims to be
official PHP.net release should use this official release, not some
custom mix of things.
It is important that these official binaries also don't regenerate the
files in the archive.
If there is an extra file (.w32?), or touching of files, required to
make this archive usable to generate binaries from - then please fix
the root problem; touch the file before the packaging (and update the
README :)).


-Hannes

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

Re: [PHP-DEV] PHP7 releases vs Windows Sources?

[Hannes Magnusson]

On Mon, Jun 15, 2015 at 12:51 PM, Anatol Belski anatol@belski.net wrote:
 Hi Hannes,

 -Original Message-
 From: Hannes Magnusson [mailto:hannes.magnus...@gmail.com]
 Sent: Monday, June 15, 2015 8:34 PM
 To: Anatol Belski
 Cc: Johannes Schlüter; Christoph Becker; PHP Development; PHP Webmaster ML
 Subject: Re: [PHP-DEV] PHP7 releases vs Windows Sources?

 On Mon, Jun 15, 2015 at 8:38 AM, Anatol Belski anatol@belski.net wrote:
  Hi Johannes,
 
  -Original Message-
  From: Johannes Schlüter [mailto:johan...@schlueters.de]
  Sent: Monday, June 15, 2015 4:52 PM
  To: Christoph Becker
  Cc: Hannes Magnusson; Anatol Belski; PHP Development; PHP Webmaster
  ML
  Subject: Re: [PHP-DEV] PHP7 releases vs Windows Sources?
 
  On Mon, 2015-06-15 at 16:20 +0200, Christoph Becker wrote:
   Hannes Magnusson wrote:
  
Then this fix doesn't make any sense -- you are saying if I
download the .tar.gz and .zip and extract those two, I will have
precisely the same sources?
Then this fix should be reverted as there is isn't any special
Windows Sources and the official releases should work just fine.
  
   There is some difference (timestamps?) which causes building from
   the tarred sources to fail on Windows (see bug #69829).
 
  touching generated files as part of the packaging process is a good
  idea for all platforms.
 
Furthermore
   extracting the tarred sources with 7zip (which seems to be a pretty
   common archiver) results in spurious PaxHeaders.# directories,
   what is bug in 7zip[1], and doesn't really affect the build, but is
   confusing nonetheless (and requires more disk space).
  
   At least until these issue are solved, IMO it's better to link to
   the Windows sources packaged as .zip.
 
  If there is a need for zip archives I'd put them next to tar.gz etc.
  and distribute them via our mirror network.
 
  Yep, this could work and were probably proper solution. Except we wouldn't
 add some issue for the non Windows users :) I'm not sure, why is it done so
 ATM, probably it has its historical reasons. But this would probably cause us
 need to update the release process procedure? And, for PHP7 or for any other 
 as
 well? Currently that zipball is just generated with the build process, so 
 it'll need
 to be sent over somehow. Were anyway doable,  wondering what the other
 RMs would say. Frankly, I'd leave it as it is - as long as it's reachable and
 documented.
 



 Thats what we want. We want the official release balls to be generated by an
 official server using the official toolchain.
 There should never be a time when a Release Manager pulls up his notebook,
 does a checkout and packages that and uploads. Its bad enough we have this 
 for
 pecl exts, but there is no reason for php-src to be playing with fire and
 infiltration agencies.

 That has unfortunately happened before, and resulted in us distributing .orig
 files (patch conflicts), .exp, .out, .php, ...
 (failed tests results) and even wrongly generated artifacts (due to wrong
 bison/re2c versions installed locally).

 We don't want that happen again.
 The official releases should be done on snap box, and be completely
 automated with no room for accidents.
 It produces several archives, and we can add .zip to that mix if not already
 available.
 It's a worthy goal IMHO. Currently it all is done manually as you know.


What! No, I didn't know.
I was describing how the process used to be, and I thought it still was.

Apparently this was dropped in December 2013:
http://git.php.net/?p=php-src.git;a=blobdiff;f=README.RELEASE_PROCESS;h=a0c34f8f7aa5bf8782f394572419167e7ff20c7b;hp=6cc9c4e9ab8fc3102f3fe142b100571362af6742;hb=3eb2b1ac4008acd13f51244c7ba009fa381e79f7;hpb=6f739318fd3dc04a01aec762d449949db481bf5d


I think we need to fix this situation.

Now that you have RMd your first release -- you do seem like the best
person to ask for feedback: What were your pain points? What was the
biggest time waste? What should be improved?

I'm sure we can spin up a server and we script it so all you have to
do is click a button. No accidental personal photos in the release
archives or local malicious tool injecting itself into the archive.

-Hannes

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

Re: [PHP-DEV] PHP7 releases vs Windows Sources?

[Hannes Magnusson]

On Mon, Jun 15, 2015 at 3:46 PM, Stanislav Malyshev smalys...@gmail.com wrote:
 Hi!

 It's a worthy goal IMHO. Currently it all is done manually as you know.


 What! No, I didn't know.
 I was describing how the process used to be, and I thought it still was.

 I think making auto-release is a nice idea, but what about signing? I'm
 surely not leaving my personal private key on any commonly accessible
 server, so how would I sign packages? Except for that, making script
 that would do make release or sh scripts/release and complete the
 release cycle (including generating  uploading everything) would be
 nice. Right now we have mkdist but it only takes us half-way.


gpg-agent forwarding over ssh?



- Goto https://release.php.net/
- Login with your master credentials (only allows logins for whitelisted users).
- White page suggest you are creating x.y.z+1 release from branch x_y
- If yes; press MAKE MAGIC
- If no; write the version number in input field, select branch from combobox
- Press; I KNOW WHAT IM DOING

This will trigger generating all files needed, bumping version and
whatever. Tags. Creates archives. All that good stuff.
5 minutes later you get email; release is ready! with links to the archives

You fetch them, explore the archives, run the tests and you the things
we all know we should do but don't :)
Then:

ssh -R ~username/.gnupg/S.gpg-agent -o StreamLocalBindUnlink=yes
release.php.net '/usr/local/bin/confirm x.y.z+1'

It'll sign the git tag (using your forwarded agent), push upstream,
push archives to php-distribution.git

Then. In the next release of the tool:
- The whitepage extracts the NEWS entries and does the html/php
formatting for phpweb
- Gives you checkboxes to choose pick the highlights
- The highlights will be used for the standard phpweb news xml.

- Profit


-Hannes

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

Re: [PHP-DEV] [RFC] Simplified Array API for extensions

[Hannes Magnusson]

\o/ thanks

-Hannes


On Fri, May 29, 2015 at 3:54 PM, Sara Golemon poll...@php.net wrote:
 Not thoroughly tested, but it compiles at least.
 Give the latest commit a shot:
 https://github.com/sgolemon/php-array-api/commit/1274a2bcbc3eca78dbd35702136b0034b67afc8f

 -Sara

 On Fri, May 29, 2015 at 1:25 PM, Sara Golemon poll...@php.net wrote:
 Ah, well that I'll probably do soonish, but as you already know, it
 doesn't need to be in the php-src tree to work. :)

 On Fri, May 29, 2015 at 12:37 PM, Hannes Magnusson
 hannes.magnus...@gmail.com wrote:
 I was hoping someone had ported that header file to PHP7 too, for
 easier upgrade path from PHP5 for projects already using it :]

 -Hannes


 On Fri, May 29, 2015 at 12:33 PM, Sara Golemon poll...@php.net wrote:
 Yeah, way too late for PHP 7.0, but on the plus side the zend hash API
 has changed in ways which make this facade much less necessary.  Not
 redundant, necessarily, but the biggest pain point (getting zval** by
 reference) is gone (we now get zval* via return).

 -Sara

 On Fri, May 29, 2015 at 12:14 PM, Scott Arciszewski sc...@paragonie.com 
 wrote:
 Naive answer: P(inclusion) = 0, due to the feature freeze. Unless I'm
 mistaken.

 If so, you might need to target 7.1 instead of 7.0.

 Scott Arciszewski
 Chief Development Officer
 Paragon Initiative Enterprises https://paragonie.com

 On Fri, May 29, 2015 at 2:56 PM, Hannes Magnusson 
 hannes.magnus...@gmail.com wrote:

 What are the chances anyone updated this to support PHP7 yet?



 -Hannes


 On Mon, Aug 11, 2014 at 5:17 PM, Andrea Faulds a...@ajf.me wrote:
 
  On 12 Aug 2014, at 01:15, Tjerk Meesters tjerk.meest...@gmail.com
 wrote:
 
 
  On 12 Aug, 2014, at 5:03 am, Andrea Faulds a...@ajf.me wrote:
 
 
  On 11 Aug 2014, at 22:00, Hannes Magnusson 
  hannes.magnus...@gmail.com
 wrote:
 
  I think it would be fantastic if this would be included in 5.6.
 
  Too late for 5.6, but 5.7 perhaps (can we please have this? 7 will
 break BC and I’d like to get some stuff in next year, not in 2 years).
 
  Can this API be retained as is when NG gets merged?
 
  I would hate to see developers put in effort to take advantage of this
 simplified API in 5.x only to have to make changes again for 7.
 
  If it can’t, I’d suggest only adding this in ng in the first place.
  --
  Andrea Faulds
  http://ajf.me/
 
 
 
 

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



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

Re: [PHP-DEV] [RFC] Simplified Array API for extensions

[Hannes Magnusson]

What are the chances anyone updated this to support PHP7 yet?



-Hannes


On Mon, Aug 11, 2014 at 5:17 PM, Andrea Faulds a...@ajf.me wrote:

 On 12 Aug 2014, at 01:15, Tjerk Meesters tjerk.meest...@gmail.com wrote:


 On 12 Aug, 2014, at 5:03 am, Andrea Faulds a...@ajf.me wrote:


 On 11 Aug 2014, at 22:00, Hannes Magnusson hannes.magnus...@gmail.com 
 wrote:

 I think it would be fantastic if this would be included in 5.6.

 Too late for 5.6, but 5.7 perhaps (can we please have this? 7 will break BC 
 and I’d like to get some stuff in next year, not in 2 years).

 Can this API be retained as is when NG gets merged?

 I would hate to see developers put in effort to take advantage of this 
 simplified API in 5.x only to have to make changes again for 7.

 If it can’t, I’d suggest only adding this in ng in the first place.
 --
 Andrea Faulds
 http://ajf.me/





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

Re: [PHP-DEV] [RFC] Simplified Array API for extensions

[Hannes Magnusson]

I was hoping someone had ported that header file to PHP7 too, for
easier upgrade path from PHP5 for projects already using it :]

-Hannes


On Fri, May 29, 2015 at 12:33 PM, Sara Golemon poll...@php.net wrote:
 Yeah, way too late for PHP 7.0, but on the plus side the zend hash API
 has changed in ways which make this facade much less necessary.  Not
 redundant, necessarily, but the biggest pain point (getting zval** by
 reference) is gone (we now get zval* via return).

 -Sara

 On Fri, May 29, 2015 at 12:14 PM, Scott Arciszewski sc...@paragonie.com 
 wrote:
 Naive answer: P(inclusion) = 0, due to the feature freeze. Unless I'm
 mistaken.

 If so, you might need to target 7.1 instead of 7.0.

 Scott Arciszewski
 Chief Development Officer
 Paragon Initiative Enterprises https://paragonie.com

 On Fri, May 29, 2015 at 2:56 PM, Hannes Magnusson 
 hannes.magnus...@gmail.com wrote:

 What are the chances anyone updated this to support PHP7 yet?



 -Hannes


 On Mon, Aug 11, 2014 at 5:17 PM, Andrea Faulds a...@ajf.me wrote:
 
  On 12 Aug 2014, at 01:15, Tjerk Meesters tjerk.meest...@gmail.com
 wrote:
 
 
  On 12 Aug, 2014, at 5:03 am, Andrea Faulds a...@ajf.me wrote:
 
 
  On 11 Aug 2014, at 22:00, Hannes Magnusson hannes.magnus...@gmail.com
 wrote:
 
  I think it would be fantastic if this would be included in 5.6.
 
  Too late for 5.6, but 5.7 perhaps (can we please have this? 7 will
 break BC and I’d like to get some stuff in next year, not in 2 years).
 
  Can this API be retained as is when NG gets merged?
 
  I would hate to see developers put in effort to take advantage of this
 simplified API in 5.x only to have to make changes again for 7.
 
  If it can’t, I’d suggest only adding this in ng in the first place.
  --
  Andrea Faulds
  http://ajf.me/
 
 
 
 

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



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

Re: [PHP-DEV] Pull request labels handling

[Hannes Magnusson]

On Wed, May 27, 2015 at 6:29 AM, Anatol Belski anatol@belski.net wrote:
 Hi,

 the PRs on github are already being labeled. Multiple labels are possible.
 However the github ACLs lack on granularity
 https://help.github.com/articles/permission-levels-for-an-organization-repos
 itory/ . Due to that, while being a useful feature, labeling is only
 available for project admins or alike. Now with PHP7 such labeling becomes
 probably even more sense as we'll need to handle BC breaks and other
 situations which would need more testing and care. So the amount of work to
 evaluate and review PRs will grow while the work team probably not.


I don't have time to work on qa.php.net/pulls and add such feature, so
I gave Xinchen and Nikita admin rights for the organization as a
workaround. Stas was already an admin.

We did mention that if labelling is supposed to be integral part of
the workflow this must be available for the normal karma holder and
therefore needs to be integrated somehow.

-Hannes

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

Re: [PHP-DEV] VCS Account Request: matttait

[Hannes Magnusson]

You don't need VCS commit karma to do that.

The code is freely available on http://git.php.net/?p=php-src.git;a=summary

If you find anything - be sure to let secur...@php.net know.

-Hannes


On Wed, May 20, 2015 at 7:25 PM, Matt Tait mattt...@gmail.com wrote:
 Interested in helping security-audit and add security-related features to PHP 
 core.


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


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

[PHP-DEV] Re: PECL install no longer works out of the box

[Hannes Magnusson]

$ sudo pecl install memcached
downloading memcached-2.2.0.tar ...
Starting to download memcached-2.2.0.tar (410,624 bytes)
.done: 410,624 bytes
15 source files, building
running: phpize

\o/ - Thanks

-Hannes



On Fri, Apr 17, 2015 at 4:42 AM, Ferenc Kovacs tyr...@gmail.com wrote:
 Hannes, could you please confirm that you can pecl install memcached?

 On Fri, Apr 17, 2015 at 11:20 AM, Pierre Joye pierre@gmail.com wrote:

 for the record,

  20  Pierre30 done, all
  20  Pierre30 let me know if it works
  18  Tyraelseems to be working fine, thanks


 @Hannes: Please confirm.

 On Fri, Apr 17, 2015 at 9:01 AM, Pierre Joye pierre@gmail.com wrote:
  On Fri, Apr 17, 2015 at 8:30 AM, Pierre Joye pierre@gmail.com
  wrote:
  On Fri, Apr 17, 2015 at 1:41 AM, Pierre Joye pierre@gmail.com
  wrote:
  it is not weird as we still send the tgz not the tar.
 
  try this: https://gist.github.com/pierrejoye/c8677f89159f696d
 
  I cannot test and crafted it a la volee, but it should do it:
 
  $file is used to query the file from the database, which contains only
  filenames with tgz (as we created the .tar manually now)
  $basename is what is used by X-SendFile, this patch fixes it and
  create release.tar instead of release.tgz
 
  tested and improved patch applied.
 
  Adding the uncompressed archive saving on release now.
 
  Done.
 
 
 
  --
  Pierre
 
  @pierrejoye | http://www.libgd.org



 --
 Pierre

 @pierrejoye | http://www.libgd.org




 --
 Ferenc Kovács
 @Tyr43l - http://tyrael.hu

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

[PHP-DEV] Re: PECL install no longer works out of the box

[Hannes Magnusson]

On Thu, Apr 16, 2015 at 10:14 AM, Ferenc Kovacs tyr...@gmail.com wrote:


 On Thu, Apr 16, 2015 at 5:29 PM, Pierre Joye pierre@gmail.com wrote:

 On Thu, Apr 16, 2015 at 10:02 PM, Ferenc Kovacs tyr...@gmail.com wrote:
 
 
 
  As of the uncompressed data, I see something like less 0.01% of the
  requests actually requesting non compressed archives, the box he uses
  must on of the 3-4. We are in the 21st century and compressed output
  is quite a standard. It makes the server serves faster too as we rely
  on X-SendFile, as I reportedly said on this list during the migration,
  and ask for tests.
 
 
  hi Pierre,
 
  where do you get this 0.01%?
  from a quick look:
  root@pecl:~# grep '.tar.gz ' /var/log/apache2/pecl.php.net-access.log|wc
  -l
  242
  root@pecl:~# grep '.tar ' /var/log/apache2/pecl.php.net-access.log|wc -l
  1350
  so the majority of the download requests are looking for the
  uncompressed
  tar file, which is doesn't work now thanks to your changes.
  is there another metric or something that I'm missing?
  it seems that this is something which we should fix/restore even if it
  costs
  us a bit more cpu.

 I check with the whole old log, was low.

 No need to change the download code.

 I will run a script to store both tgz and tar, easier and better. And
 changing the release code to save the uncompressed archive as well.
 Way better than what we had before.  And if we like to be the only one
 to provide uncompressed download of our releases, why not, I do not
 mind much ;-)

 But that's actually not a bug as of now, the SSL thing Hannes was
 experiencing is what I was asking for, it is what I wonder what
 happened to get the installer requesting SSL: in the 1st place and how
 it ends up like that and failed. But Hannes seems to do not care, so I
 will simply enable SSL again and that should be it.

 Cheers,
 --
 Pierre

 @pierrejoye | http://www.libgd.org



 ok, after discussing with Pierre I gunzipped the release tarballs so now
 they are there, Pierre will update the release upload/delete code so that we
 also store/delete the .tar files so they can be also served via sendfile.

$ sudo pecl install memcached
Could not download from http://pecl.php.net/get/memcached-2.2.0.tar;,
cannot download pecl/memcached (File
http://pecl.php.net:80/get/memcached-2.2.0.tar not valid (received:
HTTP/1.0 404 Not Found
))
Error: cannot download pecl/memcached
Download failed
install failed


Still doesn't work... Maybe peclweb hasn't updated yet?


 about the ssl related changes: we should look into the cause and there is a
 chance that we will also need to fix/update the pear installer.


The fix would need to be BC though -- prioritize https, and issue
warning on failure. You cannot just remove http downloads without
announcing it.

You have to be able to install pecl extensions with minimal PHP install:
./configure --disable-all --enable-cli  pecl install foobar

heck, currently even standard PHP-out-of-the-box ./configure is good
enough to install pecl extension because it doesn't even enable zlib
and openssl by default.

So until the zlib and openssl extension become requirements we cannot
screw people over like that.

-Hannes

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

[PHP-DEV] Re: PECL install no longer works out of the box

[Hannes Magnusson]

On Thu, Apr 16, 2015 at 10:43 AM, Hannes Magnusson
hannes.magnus...@gmail.com wrote:
 On Thu, Apr 16, 2015 at 10:14 AM, Ferenc Kovacs tyr...@gmail.com wrote:


 On Thu, Apr 16, 2015 at 5:29 PM, Pierre Joye pierre@gmail.com wrote:

 On Thu, Apr 16, 2015 at 10:02 PM, Ferenc Kovacs tyr...@gmail.com wrote:
 
 
 
  As of the uncompressed data, I see something like less 0.01% of the
  requests actually requesting non compressed archives, the box he uses
  must on of the 3-4. We are in the 21st century and compressed output
  is quite a standard. It makes the server serves faster too as we rely
  on X-SendFile, as I reportedly said on this list during the migration,
  and ask for tests.
 
 
  hi Pierre,
 
  where do you get this 0.01%?
  from a quick look:
  root@pecl:~# grep '.tar.gz ' /var/log/apache2/pecl.php.net-access.log|wc
  -l
  242
  root@pecl:~# grep '.tar ' /var/log/apache2/pecl.php.net-access.log|wc -l
  1350
  so the majority of the download requests are looking for the
  uncompressed
  tar file, which is doesn't work now thanks to your changes.
  is there another metric or something that I'm missing?
  it seems that this is something which we should fix/restore even if it
  costs
  us a bit more cpu.

 I check with the whole old log, was low.

 No need to change the download code.

 I will run a script to store both tgz and tar, easier and better. And
 changing the release code to save the uncompressed archive as well.
 Way better than what we had before.  And if we like to be the only one
 to provide uncompressed download of our releases, why not, I do not
 mind much ;-)

 But that's actually not a bug as of now, the SSL thing Hannes was
 experiencing is what I was asking for, it is what I wonder what
 happened to get the installer requesting SSL: in the 1st place and how
 it ends up like that and failed. But Hannes seems to do not care, so I
 will simply enable SSL again and that should be it.

 Cheers,
 --
 Pierre

 @pierrejoye | http://www.libgd.org



 ok, after discussing with Pierre I gunzipped the release tarballs so now
 they are there, Pierre will update the release upload/delete code so that we
 also store/delete the .tar files so they can be also served via sendfile.

 $ sudo pecl install memcached
 Could not download from http://pecl.php.net/get/memcached-2.2.0.tar;,
 cannot download pecl/memcached (File
 http://pecl.php.net:80/get/memcached-2.2.0.tar not valid (received:
 HTTP/1.0 404 Not Found
 ))
 Error: cannot download pecl/memcached
 Download failed
 install failed


 Still doesn't work... Maybe peclweb hasn't updated yet?


 about the ssl related changes: we should look into the cause and there is a
 chance that we will also need to fix/update the pear installer.


 The fix would need to be BC though -- prioritize https, and issue
 warning on failure. You cannot just remove http downloads without
 announcing it.

 You have to be able to install pecl extensions with minimal PHP install:
 ./configure --disable-all --enable-cli  pecl install foobar

 heck, currently even standard PHP-out-of-the-box ./configure is good
 enough to install pecl extension because it doesn't even enable zlib
 and openssl by default.

Whopsy, typo alert -- that is supposed to say currently even standard
PHP is _NOT_ good enough :)


Before the recent changes during the server move, everything worked just fine.

Thanks for looking at this Martin  Ferenc!

-Hannes

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

[PHP-DEV] Re: PECL install no longer works out of the box

[Hannes Magnusson]

On Thu, Apr 16, 2015 at 11:06 AM, Ferenc Kovacs tyr...@gmail.com wrote:


 On Thu, Apr 16, 2015 at 8:02 PM, Ferenc Kovacs tyr...@gmail.com wrote:



 On Thu, Apr 16, 2015 at 7:43 PM, Hannes Magnusson
 hannes.magnus...@gmail.com wrote:

 On Thu, Apr 16, 2015 at 10:14 AM, Ferenc Kovacs tyr...@gmail.com wrote:
 
 
  On Thu, Apr 16, 2015 at 5:29 PM, Pierre Joye pierre@gmail.com
  wrote:
 
  On Thu, Apr 16, 2015 at 10:02 PM, Ferenc Kovacs tyr...@gmail.com
  wrote:
  
  
  
   As of the uncompressed data, I see something like less 0.01% of the
   requests actually requesting non compressed archives, the box he
   uses
   must on of the 3-4. We are in the 21st century and compressed
   output
   is quite a standard. It makes the server serves faster too as we
   rely
   on X-SendFile, as I reportedly said on this list during the
   migration,
   and ask for tests.
  
  
   hi Pierre,
  
   where do you get this 0.01%?
   from a quick look:
   root@pecl:~# grep '.tar.gz '
   /var/log/apache2/pecl.php.net-access.log|wc
   -l
   242
   root@pecl:~# grep '.tar '
   /var/log/apache2/pecl.php.net-access.log|wc -l
   1350
   so the majority of the download requests are looking for the
   uncompressed
   tar file, which is doesn't work now thanks to your changes.
   is there another metric or something that I'm missing?
   it seems that this is something which we should fix/restore even if
   it
   costs
   us a bit more cpu.
 
  I check with the whole old log, was low.
 
  No need to change the download code.
 
  I will run a script to store both tgz and tar, easier and better. And
  changing the release code to save the uncompressed archive as well.
  Way better than what we had before.  And if we like to be the only one
  to provide uncompressed download of our releases, why not, I do not
  mind much ;-)
 
  But that's actually not a bug as of now, the SSL thing Hannes was
  experiencing is what I was asking for, it is what I wonder what
  happened to get the installer requesting SSL: in the 1st place and how
  it ends up like that and failed. But Hannes seems to do not care, so I
  will simply enable SSL again and that should be it.
 
  Cheers,
  --
  Pierre
 
  @pierrejoye | http://www.libgd.org
 
 
 
  ok, after discussing with Pierre I gunzipped the release tarballs so
  now
  they are there, Pierre will update the release upload/delete code so
  that we
  also store/delete the .tar files so they can be also served via
  sendfile.

 $ sudo pecl install memcached
 Could not download from http://pecl.php.net/get/memcached-2.2.0.tar;,
 cannot download pecl/memcached (File
 http://pecl.php.net:80/get/memcached-2.2.0.tar not valid (received:
 HTTP/1.0 404 Not Found
 ))
 Error: cannot download pecl/memcached
 Download failed
 install failed


 it seems that the two commits (reverts) which should make that error go
 away still not make to the peclweb machine yet.
 I will wait an hour or so, if still not there I will check out the rsync
 box (as I verified that the update-peclweb is executed properly).

 --
 Ferenc Kovács
 @Tyr43l - http://tyrael.hu



 oops, I made a mistake, one of the two reverts was against the wrong hash.
 just fixed it now.



Getting closer :)

$ sudo pecl install memcached
downloading memcached-2.2.0.tar ...
Starting to download memcached-2.2.0.tar (70,449 bytes)
.done: 70,449 bytes
could not extract the package.xml file from
/tmp/pear/download/memcached-2.2.0.tar
Download of pecl/memcached succeeded, but it is not a valid package archive
Error: cannot download pecl/memcached
Download failed
install failed
$ file /tmp/pear/download/memcached-2.2.0.tar
/tmp/pear/download/memcached-2.2.0.tar: gzip compressed data, from
Unix, max compression


It looks like it is actually gzipped?

-Hannes

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

[PHP-DEV] PECL install no longer works out of the box

[Hannes Magnusson]

Hi

Can someone with access to the new pecl box fix the package downloading?
It is totally broken apparently.

On vanilla FreeBSD 10:

$ pecl install memcached
No releases available for package pecl.php.net/memcached
install failed
$ pecl search memcached
Connection to `ssl://pecl.php.net:443' failed: Unable to find the
socket transport ssl - did you forget to enable it when you
configured PHP?
$ php -m | grep -i ssl
openssl
$ php -i | grep -i PHP Streams
Registered PHP Streams = php, file, glob, data, http, ftp, https, ftps
$ php -v
PHP 5.6.7 (cli) (built: Apr  8 2015 15:18:53)
Copyright (c) 1997-2015 The PHP Group
Zend Engine v2.6.0, Copyright (c) 1998-2015 Zend Technologies



The installer doesn't feel very good about the recent unannounced
decision that pecl is now only available on https (which isn't
entirely true -- it answers to http, at which point if there was a
MITM he wouldn't forward you to https and just keep you on http..
so. no win).


I've also seen people complaining over the .tar files now not actually
being .tar files -- they apparently are gzipped, which clearly doesn't
work on all systems -- which is why we provide .tar.

-Hannes

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

Re: [PHP-DEV] Contributing to PHP Wiki

[Hannes Magnusson]

Sure. Custom groups need to be added to
http://git.php.net/?p=web/wiki.git;a=blob;f=dokuwiki/conf/acl.auth.php;h=2b2c7711422cce99e018abb21b7a003b168cf06a;hb=HEAD
and then you can be put into that group from the admin interface.

I'd say however, if Avindra is interested in those docs, I'd bet he'd
be interested in helping with the PHP7 migration chapters in the
manual - so could just as well apply for vcs karma.

-Hannes


On Fri, Mar 27, 2015 at 12:12 AM, Ferenc Kovacs tyr...@gmail.com wrote:


 On Fri, Mar 27, 2015 at 12:02 AM, Avindra Goolcharan aavind...@gmail.com
 wrote:

 I want to help detail the PHP NG build documentation and fix build
 instructions. For example, enabling openssl should not be listed so far
 below in the ./configure command.

 Avindra.


 Hi,

 I don't think that it matters in which line is the --with-openssl listed as
 long as the configure command is otherwise correct.
 You want to have access to the https://wiki.php.net/phpng page, right?
 Hannes, should we grant edit karma for Avindra for that page? (similarly how
 we did for internals:windows:* for the user wintendo)

 --
 Ferenc Kovács
 @Tyr43l - http://tyrael.hu

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

Re: [PHP-DEV] Voting irregularities

[Hannes Magnusson]

I have asked you before to stop harassing me, and stop spreading these
lies and defamation before.
Furthermore I have asked you to stop emailing all together.

I have asked you very politely several times before.

Please refrain for talking about me or to me ever again. I will take
legal actions if this does not stop.
Thank you for your understanding.

-Hannes


On Tue, Mar 17, 2015 at 6:30 PM, Pierre Joye pierre@gmail.com wrote:
 hi,

 On Wed, Mar 18, 2015 at 9:00 AM, Hannes Magnusson
 hannes.magnus...@gmail.com wrote:
 On Tue, Mar 17, 2015 at 2:15 PM, Sebastian B.-Hagensen
 sbj.ml.r...@gmail.com wrote:
 Hi,

 2015-03-17 20:55 GMT+01:00 Hannes Magnusson hannes.magnus...@gmail.com:
 If you need to confirm the statistics, or gather more background data,
 then feel free to contact me privately, off the list, and I'll get you
 the account approval dates (karma and/or wiki).

 While I agree that the issue at hand was not presented in the way it
 should have been may still become a valid issue in the future.
 If you want to prevent situations or even (wrong) ideas and
 accusations like these the dates of account creations have to be
 public and easily accessible by everyone involved (publicly listed on
 people.php.net for example).


 people.php.net are php.net karma holders. We have no responsibility to
 disclose any information about our contributors to anyone.
 It is however fun to do so, so I created people.php.net listing random
 info about our contributors. If you can think of other fun things to
 do with that website, I'd love feedback and contributions!

 The wiki account system is different. php.net karma holders have
 access out-of-the-box using their vcs credentials.
 Then there is a special case where you have to register to the wiki itself.
 Having a wiki account does nothing out-of-the-box.
 You have to ask for specific access.
 Since the inception of the wiki I have been the only one giving out
 wiki credentials. This has mostly been to outsiders wanting to write
 RFCs.
 I have vague memories having given 2-3 people access to
 https://wiki.php.net/usergroups and similar to docs and so on.
 These people still cannot vote.
 A person who maintains popular pecl extension cannot vote either,
 unless the extension is maintained on the php.net infrastructure (and
 therefore requiring php.net account) btw.

 There have been several members from the community that have asked for
 voting privileges, as per the voting rfc. I have arbitrary approved
 maybe 3 or 4 over the years. The other 5-10 did not get voting
 privileges because the authors of the voting rfc didn't care.

 I have absolutely no interest this voting business and and strongly
 disagree with the entire voting rfc idea. I would love to get back to
 http://producingoss.com/en/consensus-democracy.html


 that's your good right to disagree and I respect your opinion in that regard.

 However, as of today, you are the blocking point when it comes to
 improve the wiki RFCs, registration and voting areas.And this is
 really becoming a problem. I am not talking about irregularities and
 the likes and I agree that it may not be fair to start bitching about
 one or another vote, especially for some 1st time voters but oldest
 contributors. While I do see an issue with inactive developers
 suddenly jumping in but not using or contributing to PHP in any form
 since quite long. But this is a totally different issues and I really
 have no idea how to solve that, I do not see it as a big issue either
 so...

 However, the RFCs have been abused in many possible ways where I
 thought common sense will make people act fairly and correctly. I was
 wrong. Having simple technical measures to ensure fairness in
 discussions, voting and end of voting periods will prevent some of
 these abuses to happen again. It is possible to achieve that without
 going down a more drastic road (anonymous votes or other more deep
 changes) but will make things work the same way for everyone.

 The other problem I see, which becomes a habit for a couple of RFC
 authors, is the quality of the RFC. On one hand we have detailed high
 quality RFC, clear communications and flows and on the other hand,
 incomplete, confusing, lack of communications (aka missing the points
 of a Request for Comments completely). And this is a much more bigger
 worry than anything else. We have to fix that and such RFCs must be
 discarded or simply not accepted to vote unless they actually reach a
 certain quality and will to discuss. I will start another separate
 thread about that.

 Now, to be able to actually implement the little technical measure to
 ensure that everyone follows the same rules, I ask you one more time
 to provide the data of the current wiki so patches, changes etc can be
 implemented in a safer way. You know where to reach me to provide it.
 Thanks for your cooperation.

 Cheers,
 --
 Pierre

 @pierrejoye | http://www.libgd.org

-- 
PHP Internals - PHP Runtime Development

Re: [PHP-DEV] Voting irregularities

[Hannes Magnusson]

On Tue, Mar 17, 2015 at 2:15 PM, Sebastian B.-Hagensen
sbj.ml.r...@gmail.com wrote:
 Hi,

 2015-03-17 20:55 GMT+01:00 Hannes Magnusson hannes.magnus...@gmail.com:
 If you need to confirm the statistics, or gather more background data,
 then feel free to contact me privately, off the list, and I'll get you
 the account approval dates (karma and/or wiki).

 While I agree that the issue at hand was not presented in the way it
 should have been may still become a valid issue in the future.
 If you want to prevent situations or even (wrong) ideas and
 accusations like these the dates of account creations have to be
 public and easily accessible by everyone involved (publicly listed on
 people.php.net for example).


people.php.net are php.net karma holders. We have no responsibility to
disclose any information about our contributors to anyone.
It is however fun to do so, so I created people.php.net listing random
info about our contributors. If you can think of other fun things to
do with that website, I'd love feedback and contributions!

The wiki account system is different. php.net karma holders have
access out-of-the-box using their vcs credentials.
Then there is a special case where you have to register to the wiki itself.
Having a wiki account does nothing out-of-the-box.
You have to ask for specific access.
Since the inception of the wiki I have been the only one giving out
wiki credentials. This has mostly been to outsiders wanting to write
RFCs.
I have vague memories having given 2-3 people access to
https://wiki.php.net/usergroups and similar to docs and so on.
These people still cannot vote.
A person who maintains popular pecl extension cannot vote either,
unless the extension is maintained on the php.net infrastructure (and
therefore requiring php.net account) btw.

There have been several members from the community that have asked for
voting privileges, as per the voting rfc. I have arbitrary approved
maybe 3 or 4 over the years. The other 5-10 did not get voting
privileges because the authors of the voting rfc didn't care.

I have absolutely no interest this voting business and and strongly
disagree with the entire voting rfc idea. I would love to get back to
http://producingoss.com/en/consensus-democracy.html

Now. Please go on and become famous by blogging about conspiracy
theories (I've got plenty if you are short of ideas!) or whatever
tickles your fancy - but please don't be dragging this onto the list.

-Hannes

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

Re: [PHP-DEV] VCS Account Request: dustin

[Hannes Magnusson]

On Mon, Mar 16, 2015 at 4:17 AM, Dustin Whtitle
dustin.whit...@gmail.com wrote:
 Maintaining the documentation



Have you seen https://edit.php.net ?
I'd recommend getting involved there and or checkout php...@lists.php.net

-Hannes

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

Re: [PHP-DEV] Voting irregularities

[Hannes Magnusson]

On Sun, Mar 15, 2015 at 7:19 AM, Anthony Ferrara ircmax...@gmail.com wrote:
 All,

 I ran some numbers on the current votes of the dual-mode vote right
 now. There were a number of voters that I didn't recognize. So I
 decided to pull some stats.

 The following voters never voted before the dual-mode RFC went up:



To minimize noise on this list I would appreciate if you stay on
topic, your blog is a better venue then this list.

If you need to confirm the statistics, or gather more background data,
then feel free to contact me privately, off the list, and I'll get you
the account approval dates (karma and/or wiki).

Thanks!

-Hannes

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

Re: [PHP-DEV] Allow dropping typehints during inheritance

[Hannes Magnusson]

On Wed, Feb 4, 2015 at 10:49 AM, Nikita Popov nikita@gmail.com wrote:
 Hi internals!

 Currently we do not allow [1] removing a typehint during inheritance. For
 example the following code is not valid:

 interface A {
 public function method(Typehint $param);
 }
 class B implements A {
 public function method($param);
 }
 // Fatal error: Declaration of B::method() must be compatible with
 A::method(Typehint $param)

 The above code does *not* constitute an LSP violation, because B::method()
 accepts more inputs than A::method(). However we still forbid it.

So what it supports more inputs?
It does constitute an LSP violation. more inputs is not what the
guarantee is at all, if that is what you want you'd typehint on a
interface.


It is a LSP failure to allow a string, or any other scalar value, when
the parent requires a specific type/object.

It sucks that we fail our arginfo very frequently, but this is the way it is :]

-Hannes

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

Re: [PHP-DEV] VCS Account Request: jacob

[Hannes Magnusson]

let me know if you need commit karma for anything.
Saw you were commenting on very old tickets, I'm not going after you to
close them - you can do that yourself now :)

-Hannes


On Sat, Dec 27, 2014 at 9:59 PM, Jacob Bednarz jacob.bedn...@gmail.com
wrote:

 - Triaging bugs, issues and cleaning up bug reports


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

Re: [PHP-DEV] Unable to subscribe to php.net website mailing list

[Hannes Magnusson]

Not all mirrors allow outbound connections, which the form does (reposts to
master).

This form should be moved completely to master.php.net, with a link from
the mailinglist page.


Please keep website related discussions.. on the webmaster list :]

-Hannes


On Mon, Dec 1, 2014 at 1:19 PM, Levi Morrison le...@php.net wrote:

 I suspect this is a problem on certain mirrors. That explains
 intermittent failures, at least.

 On Mon, Dec 1, 2014 at 11:44 AM, Robert Parker rparker@yamiko.ninja
 wrote:
  I recently changed domains and email. I also had this issue for
  unsubscribing my previous email and signing up this one. Tried again a
 few
  hours later and both worked.
 
  Robert Parker
  *Full Stack Developer*
 
  Phone: 360-773-0963
  Twitter: @yamiko_ninja
 
  On Sun, Nov 30, 2014 at 11:44 AM, Ferenc Kovacs tyr...@gmail.com
 wrote:
 
  On Wed, Nov 12, 2014 at 3:49 PM, Thomas Hruska thru...@cubiclesoft.com
 
  wrote:
 
   Posting here because I'm unable to subscribe to the PHP php.net
  internal
   infrastructure discussion mailing list.
  
   http://php.net/mailing-lists.php
  
   I click the Normal radio button next to the list, enter my e-mail
   address, and click Subscribe.  Next I get a message that says, We
 were
   unable to subscribe you due to some technical problems.  Please try
 again
   later.
  
   --
   Thomas Hruska
   CubicleSoft President
  
   I've got great, time saving software that you will find useful.
  
   http://cubiclesoft.com/
  
   --
   PHP Internals - PHP Runtime Development Mailing List
   To unsubscribe, visit: http://www.php.net/unsub.php
  
  
  hi,
 
  sorry for the late response.
  I've tried reproducing your issue, first with my test email, then with
  yours (the one you used to send the mail I'm replying to) and for both
 of
  those, I've got the
  A request has been entered into the mailing list processing queue. You
  should receive an email at thru...@cubiclesoft.com shortly describing
 how
  to complete your request.
  message, and I got the confirmation mail to my test email.
  Tell me if you can somehow still reproduce the problem!

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

Re: [PHP-DEV] [RFC] Simplified Array API for extensions

[Hannes Magnusson]

I think it would be fantastic if this would be included in 5.6.

-Hannes

On Wed, Nov 6, 2013 at 2:14 PM, Hannes Magnusson
hannes.magnus...@gmail.com wrote:
 On Tue, Apr 2, 2013 at 7:52 PM, Sara Golemon poll...@php.net wrote:
 https://wiki.php.net/rfc/php-array-api


 Time to commit?

 -Hannes

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

Re: [PHP-DEV] Using stada...@lists.php.net for spec work

[Hannes Magnusson]

What sort of problems are they having? Not getting the challenge mail?

Even if I'd bulk register some people to this list, they would not be
able to send an email to until they've replied to the 'mail
challenge'..
Please look in their spam folder...

-Hannes


On Thu, Jul 24, 2014 at 11:30 AM, Sara Golemon poll...@php.net wrote:
 On Thu, Jul 24, 2014 at 11:25 AM, Stas Malyshev smalys...@sugarcrm.com 
 wrote:
 I would like to propose to use list standa...@lists.php.net (which has
 been dormant since 2009) for PHP spec work. What do you think?

 Big +1 on this.  btw, a lot of folks on the HHVM team have been having
 trouble getting subcribed to lists.php.net, if I sent you a set of
 email addresses and lists, could you help out with some bulk
 subscriptions (including standards@)?

 -Sara

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


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

Re: [PHP-DEV] php.net - The Website Ahead Contains Malware

[Hannes Magnusson]

On Thu, Oct 24, 2013 at 1:04 AM, Konstantin Leboev
konstantin.leb...@gmail.com wrote:
 I have only this email to contact, but when I opened today php.net in
 Google Chrome I've got next message The Website Ahead Contains Malware.


All we can do is Request a Review, which we have done. If anyone
knows any of the reviewers and wants to bribe them.. Please do so.

-Hannes

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

Re: [PHP-DEV] Fwd: ezmlm warning

[Hannes Magnusson]

On Mon, Sep 23, 2013 at 8:06 AM, Madara Uchiha mad...@tchizik.com wrote:
 What does this mean?
 Is this a one-time error? Did anyone else get it? (Do you even get
 this message, or was I removed already?)

 Anyone familiar with this?

[..]
 Hi! This is the ezmlm program. I'm managing the
 internals@lists.php.net mailing list.

 I'm working for my owner, who can be reached
 at internals-ow...@lists.php.net.


What the hell guys. Please stop this thread right now.

There is nothing to worry about - and the mail clearly asks you to
mail the internals-owner@ lists, not spam thousands member of this
list wasting everyones time.

If you have any worries, then let us know - using the dedicated list
for these issues.
Do not waste everyones time on this list.

But no, there is nothing to worry about. You are not missing out on anything.

-Hannes

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

Re: [PHP-DEV] RFC: constructor argument promotion

[Hannes Magnusson]

On Wed, Aug 7, 2013 at 12:47 PM, Sean Cannella se...@fb.com wrote:
 Everyone -

 Hi! Since this is my first post to this list, I'll introduce myself:
 I'm an engineer who has been working on HipHop VM in New York for the last 
 half year or so after a long time working at Microsoft on business software 
 and services in multiple hemispheres.

 I wanted to get the PHP community's opinion on this feature. See the draft 
 RFC and referenced implementation below:

 https://wiki.php.net/rfc/constructor-promotion


Using private and protected there seems really weird.
From globals scope, I am allowed to set private and protected
properties - but just once?


I would assume __construct(protected $bar) would only allow a child
class to set that property.. which implies the ctor itself is
protected.


Also, this seems like a very bad idea. You are encouraging don't
bother validating your data ideas.

-Hannes

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

Re: [PHP-DEV] crypt() should raise error without 2nd parameter

[Hannes Magnusson]

On Wed, Aug 7, 2013 at 6:20 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
 Hi all,

 It seems there are 2 options for master branch when crypt()'s 2nd parameter
 is omitted.

  - raise E_DEPRECIATED that advice use of stronger salt or password_hash()
and make 2nd parameter required for future release.
  - make crypt() use stronger default salt/hash w/o error

 Since password_hash() is supposed to do better job, first option seems
 better to me.


Deprecating it means it will be removed in the future.

Please leave the function alone. This should be solved with education,
not a gun to peoples head.

-Hannes

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

Re: [PHP-DEV] VCS Account Request: requinix

[Hannes Magnusson]

\o/

I've approved your request, which means you have full karma on
bugs.php.net and wiki.php.net.

If you login on
https://master.php.net/manage/users.php?username=requinix you'll also
be able to approve events in our event calendar, and when you browse
php.net manual pages you'll be able to edit/remove notes.

You have no commit karma, yet. When you need it.. Let us know :)

-Hannes


On Wed, Aug 7, 2013 at 7:29 PM, Damian Wadley p...@requinix.net wrote:
 I like how all the \quot;why I need a Git account\quot; reasons above are 
 copied verbatim from the list of reasons one *doesn\#039;t* need a Git 
 account :)

 Primary reason would be helping with tickets in the bug tracker, but since a 
 lot of bug reports are about the documentation I\#039;ll surely be more 
 active there too.

 PS: johannes suggested I do this.


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


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

Re: [PHP-DEV] Moving PHP documentation to Git repository

[Hannes Magnusson]

On Tue, Jun 25, 2013 at 12:45 AM, Christoph Rosse
cro...@2bepublished.at wrote:
 On 25.06.2013 08:46, Christian Stoller wrote:

 Hi internals.

 What do you think about moving the PHP documentation to a Git repository,
 mirrored on Github? Doing this would make it possible for everybody to
 extend the documentation easily by creating pull requests.

 Today one has to get an SVN account to edit the docu or you have to use
 https://edit.php.net/ which does not work as expected (at least for me when
 I tried to update some German documentation). My changes have not been
 integrated for some months (I had to write an email to somebody of the doc
 team to apply the changes).

 Symfony does it this way (see https://github.com/symfony/symfony-docs/)
 and I like it very much. It is really easy to extend/update parts of the
 docu which are not complete or outdated and I am sure that it is comfortable
 and timesaving for the doc team, too.

 What do you think?

 Best regards
 Christian


 As one who's had very similar experiences when trying to update some
 documentation via. edit.php.net (no feedback, no integration etc.) I would
 really love to see this feature.


Could you guys fill out http://www.php.net/git-php.php please? - It is
also important to use the correct mailinglist :)

As for the move to Git, if someone is willing to do the work then by
all means go for it - but I don't understand how that is some magic
fix?
You are complaining about patches being available but not applied, how
would github fix that?
Doesn't that just add yet another platform that we don't have manpower
to manage?

Also, our current tooling will need a *lot of work*, but the online
editor and our revision control for translations to name two big jobs.

The docs and websites don't operate in the same way as internals@
does. We employ a lot of trust in these neck of the woods, people with
karma to do stuff can actually do what they think is best without
going through daunting process, so once you've been around for a
little while and get a neat idea you want to work on, you don't have
to ask anyone or get permission - just do it!
If you want to work on git support for our tools, go for it.

There isn't any point in discussing things and coming to decisions
when there is noone that is able or willing to do the work. If there
work is there however.. :D

-Hannes

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

Re: [PHP-DEV] VCS Account Request: jas

[Hannes Magnusson]

Any reason why he is not allowed to update NEWS?
You only gave him karma for the openssl dir.

-Hannes

On Wed, May 1, 2013 at 1:15 PM, Pierre Joye pierre@gmail.com wrote:
 you can now merge your PR and maintain it in ext/openssl.

 See the wiki for the howtos about git and PR:

 https://wiki.php.net/vcs/gitworkflow
 https://wiki.php.net/vcs/gitfaq

 Thanks for your work!

 On Wed, May 1, 2013 at 8:21 PM, Jason Gerfen jason.ge...@gmail.com wrote:
 pierrejoye


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




 --
 Pierre

 @pierrejoye | http://blog.thepimp.net | http://www.libgd.org

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


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

Re: [PHP-DEV] Add a constant to reflect --with-curlwrappers

[Hannes Magnusson]

I think by law you have to create a new thread and prefix the subject
line with [VOTE] or something.

-Hannes

On Wed, Apr 17, 2013 at 2:59 PM, Pierrick Charron pierr...@adoy.net wrote:
 Hi,

 Since we are in a tight schedule, I started the vote and it will end in a
 week.

 https://wiki.php.net/rfc/curl-wrappers-removal-rfc#vote

 Pierrick


 On 16 April 2013 09:17, Julien Pauli jpa...@php.net wrote:

 On Tue, Apr 16, 2013 at 3:01 PM, Pierrick Charron pierr...@adoy.netwrote:

 I created a straightforward RFC that you can access here
 https://wiki.php.net/rfc/curl-wrappers-removal-rfc .

 If someone have something more to add in it, feel free. Otherwise I will
 start the vote so that we could remove it in 5.5 ASAP.


 Thx Pierrick, it's ok for me :)

 Julien.Pauli


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

Re: [PHP-DEV] Add a constant to reflect --with-curlwrappers

[Hannes Magnusson]

On Fri, Apr 12, 2013 at 2:00 PM, Stas Malyshev smalys...@sugarcrm.com wrote:
 Hi!

 5.3 users might depend on some part of the behavior and have learned to
 live with bugs. We shouldn't kick features at this stage.

 I agree, for 5.4 too. We had it for a long time, and however buggy or
 broken it is, there might be people that use it, and stable version
 implies promise they can keep using it. So we should leave stable
 versions alone, unless the breakage is so big that it endangers the user
 - which is not the case, AFAIK.


I don't know who suggested getting rid of it in 5.3 or 5.4, that is
ofcourse seriously stupid thing to do.
The original request was to kill it dead in 5.5, and remove the
constant again from 5.3 and 5.4.

-Hannes

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

Re: [PHP-DEV] New wiki article about our extension mechanism

[Hannes Magnusson]

On Wed, Apr 10, 2013 at 6:53 AM, Julien Pauli jpa...@php.net wrote:
 Hello,

 I wrote (its not finished yet) a wiki sheet to detail how our extensions
 mechanism work.
[...]
 As a human, I make mistakes :) Feel free to edit the wiki page and add
 fixes.


I can't seem to find the page.. do you have a link?

-Hannes

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

Re: [PHP-DEV] Proposal to document all of Zend and PHP API andSAPI layers

[Hannes Magnusson]

On Fri, Apr 5, 2013 at 5:48 AM, Joe Watkins krak...@php.net wrote:
 On 04/05/2013 01:23 PM, Johannes Schlüter wrote:

 On Fri, 2013-04-05 at 14:09 +0200, Ferenc Kovacs wrote:


 I think that it everybody would support that idea, unfortunatelly not
 many
 people have the knowledge AND the time to write up that kind of
 documentation.


 That is the key part. There's no worse documentation than wrong
 documentation. Maybe correct documentation only mentioning useless
 information.

 I also think that documenting each and every API leads nowhere, but as
 Ferenc said we have to document the structure and help people tofind
 what they need.

 This all takes time, though, and many seem to prefer adding syntax sugar
 and such things over fixing bugs and documenting things.

 johannes



 http://php.net/manual/en/internals2.php

 This, would be brilliant, if it were anything like complete, and had a
 searchable API reference, rather than an empty section labelled API
 reference.

 What I suggest is that we make an effort to properly define a way to
 document the source code. Each in our own time we can document the things we
 interact with, or pick a file whenever we have a spare ten minutes.

 We might not have a complete set of documentation until version 6 or after,
 it might even never be complete, much like the PHP manual, but at least it
 will be on the way, it shouldn't take long for everyone who needs to be
 aware to become aware, and those that introduce new prototypes or change old
 ones will know what is expected of them.

 I shouldn't have said sub-project, what I should have said was, I propose
 that we define a standard way to document everything internal, if there is
 a standard, and the people working on the source are (made) aware of it, it
 is surely no effort at all to maintain it, once the initial work is done,
 which doesn't have to happen yesterday.

 Along with documenting source, we should of course complete the write up of
 internals2 ...


I don't want to be a party pooper, but we have enough problems of
documenting userland php-src that documenting the internals would
simply never be able to keep up with changes/additions, so always be
incomplete. Not to mention the fact it is gigantic work to even do the
initial docs, and maintaining them no less of a work :)

I would love to get the header files commented, like you seem to be
proposing (which is confusing, do we really need to ask to add
comments? Or an RFC? :)).
And adding header files like Sara proposed the other day, with
extensive comments, is definitively the way to go.

Once the header files are properly documented and understandable by
extension writers we could look into ways of embedding that in the
online manual somehow.

-Hannes

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

Re: [PHP-DEV] Add a constant to reflect --with-curlwrappers

[Hannes Magnusson]

On Fri, Apr 5, 2013 at 7:14 AM, Julien Pauli jpa...@php.net wrote:
 On Fri, Apr 5, 2013 at 12:51 PM, Johannes Schlüter johan...@schlueters.de
 wrote:

 On Fri, 2013-04-05 at 08:01 +0200, Pierre Joye wrote:
   stream_wrapper_unregister(http);
   stream_wrapper_register(http, CurlStreamWrapper);
   and then stream_wrapper_restore(http) to go back to the core
  streams.
  
 
  I wonder what one will do with open streams during the switches. That
  can't go well.

 For open streams there should be no issue - they hold the pointer to
 their respective implementation.

 The issue I see is that libraries might change that for whatever reasons
 and not fix it up before passing control to some other library, thus
 creating a hardly debugable mess.


 I'm feeling like we wont be able to make it stable for 5.5 final.


Right, I don't think its worth actually fixing this for 5.5, the
current experiment should be removed by 5.5 and then the possibility
to register the curl stream wrapper from userland could be introduced
in 5.5.1 for example.

For now, simply removing the config switch would be the quickest way
to achieve progress with minimal changes back and forth if anyone
wants to make that class.

-Hannes

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

Re: [PHP-DEV] Add a constant to reflect --with-curlwrappers

[Hannes Magnusson]

On Thu, Apr 4, 2013 at 11:27 AM, Pierrick Charron pierr...@adoy.net wrote:
 Hi

 I don't think we should remove curlwrappers from 5.5. I do agree that this
 is not yet stable and ready to push as non experimental, but since we plan
 to release 5.5 soon I don't think removing it right now is worth it.

 I started some time ago to maintain the curl extension. I focused mainly on
 adding to ext/curl all options from the libcurl api that were not available
 in PHP userspace. I also fixed some bugs on curlwrappers and will be please
 to fix (or at least try to fix) all bugs that we may have with curl and curl
 wrappers in the hope that it will be stable enough to be release with php
 nexté

 If you have a bug with curlwrapper (or anything related to ext/curl) please
 assign me the bug on the tracker and I will try to look at them ASAP.

Its not only about maintaining it.
This experiment failed a long time ago. Overwriting the core streams
has proven itself to be the wrong way.

If there was a way for userspace to say overload with curl then thats fine.
We already have a procedure for this:

stream_wrapper_unregister(http);
stream_wrapper_register(http, CurlStreamWrapper);
and then stream_wrapper_restore(http) to go back to the core streams.


I would definitely see the benefits in something like that, but as
things are now are simply not working and should be removed.
The real way can be re-implemented later.

-Hannes

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

Re: [PHP-DEV] Add a constant to reflect --with-curlwrappers

[Hannes Magnusson]

On Wed, Apr 3, 2013 at 12:31 AM, Kalle Sommer Nielsen ka...@php.net wrote:
 Hi Laruence

 2013/3/31 Laruence larue...@php.net
I propose to add a constant : bool CURL_WRAPPERS_ENABLE

or, any other better name...

objections?

 I'm a -1 on this, because as we sort of agreed on (like Hannes
 implied), this experimental feature did not turn out as we wanted, its
 buggy and nobody maintains it. Currently to figure out if PHP was
 built with curlwrappers, theres this dirty hack by printing the
 phpinfo() page into an output buffer, to parse it for the build
 string, this sucks.

 However, since this is an experimental feature, we should either:
 1) Make it work (most unlikely)
 2) Remove it

 Instead of adding tiny hacks to make it easier (I know a constant wont
 hurt much). Cross version code is also gonna end up with even more
 clutter, imagine this (if you want to utilize this new constant, which
 is the idea right?):

 $curlwrappers = false;

 if(defined('CURL_WRAPPERS_ENABLED')) {
  $curlwrappers = true;



You'll actually have to assign the value of CURL_WRAPPERS_ENABLED to
$curlwrappers, as defined() only checks if the constant exist.. not if
its set to true :)

-Hannes

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

Re: [PHP-DEV] Add a constant to reflect --with-curlwrappers

[Hannes Magnusson]

On Wed, Apr 3, 2013 at 5:42 AM, Ferenc Kovacs tyr...@gmail.com wrote:
 On Wed, Apr 3, 2013 at 10:37 AM, Laruence larue...@php.net wrote:


 however, you are right, it's not a long time, so if objections becomes
 strong,  I can revert it.


 this is exactly the kind of behavior why we changed from the commit first
 then revert when people complaining to the current approach, where we try
 to reach a concensus (via discussion on the mailing list or voting through
 RFCs) before introducing a change.


I've gotta say, even though I disagree with the commit, writing an RFC
for a new constant is a total WTF.
There is absolutely no need for a RFC for it.
Heck, even that initial curtesy mail was more then I would have expected.



-Hannes

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

Re: [PHP-DEV] Add a constant to reflect --with-curlwrappers

[Hannes Magnusson]

On Wed, Apr 3, 2013 at 2:00 PM, Stas Malyshev smalys...@sugarcrm.com wrote:
 Hi!

 There is absolutely no need for a RFC for it.
 Heck, even that initial curtesy mail was more then I would have expected.

 Agree, no need for full scale RFC for one constant. However, sending an
 email to the list and actually waiting for feedback is exactly what I
 would expect, especially dealing with stable version and feature that it
 is not exactly clear what's going on with it. We're not talking about
 writing RFCs for every minor change, we're talking about teamwork and
 have members of the team be aware of the change and have time to discuss
 it if needed. Nothing bad would happen if the same commit would land a
 week later, after everybody is behind it and every detail is hashed out
 (or not if turns out it is out of consensus). The point here is not to
 impede work but to support teamwork.


There is a thin line between impeding work and team work for such a
trivial change.
This constant is actually really useful.
The entire feature is however unfortunately broken, but had it been in
a working shape then common. Really? Send an email and wait a week
before being able to write a testcase?

Anyway. Lets move on.
I suspect removing an experimental feature in an extension that is
disabled by default and requires external library still requires an
RFC?
And according to the current rules of the game it cannot be removed in
5.5.1, but has to be removed in 5.6.0?

-Hannes

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

Re: [PHP-DEV] Add a constant to reflect --with-curlwrappers

[Hannes Magnusson]

Wait wait wait. You are introducing a constant that is going to be
available as of 5.4.15 to 5.4.2x and then removed (as it looks like we
are agreeing)?

People have been living without this constant forever now so people
have their workarounds in place and no need to complicate their code
to for the existence of this constant which is only available for few
bugfix releases anyway?

-Hannes

On Tue, Apr 2, 2013 at 7:19 PM, Laruence larue...@php.net wrote:
 Added new constant CURL_WRAPPERS_ENABLE  in (include 5.4)
 https://github.com/php/php-src/commit/d7f709a032a40cb475042b43db07a4698a2488b7

 thanks


 On Mon, Apr 1, 2013 at 9:53 PM, Laruence larue...@php.net wrote:




 On Mon, Apr 1, 2013 at 7:18 AM, Hannes Magnusson
 hannes.magnus...@gmail.com wrote:

 On Sun, Mar 31, 2013 at 6:25 AM, Laruence larue...@php.net wrote:
  Hey:
 
 there are some issues when people run some codes in a php which is
  compiled with --with-curlwrappers, like #61336, or the recently test
  script
  for #64433 (failed when curl wrappers enabled).
 
 I know, that the curl wrapper should act the same as php http
  wrapper,
  but for now, we need to provide the ability to user, that they can warn
  if
  they codes can not run with curl wrappers..
 
 here are some really usages:
  https://github.com/UnionOfRAD/lithium/issues/59  and
  http://weizhifeng.net/wrong-with-curlwrappers.html
 
 I propose to add a constant : bool CURL_WRAPPERS_ENABLE

 The curl wrappers have always been a major pain, with plenty of bugs
 and we tend to forget to add context options there to match the
 standard wrapper on new feature.

 It has been marked as experimental since forever, and I think its time
 to face the failed experiment and remove it.


 Hey:

  remove is also okey for me,  but, I think it probably can only happen in
 5.6

  before that,  I think a flag to 5.4+ is a good choice :)

  thanks


 -Hannes




 --
 Laruence  Xinchen Hui
 http://www.laruence.com/




 --
 Laruence  Xinchen Hui
 http://www.laruence.com/

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

Re: [PHP-DEV] Add a constant to reflect --with-curlwrappers

[Hannes Magnusson]

On Sun, Mar 31, 2013 at 6:25 AM, Laruence larue...@php.net wrote:
 Hey:

there are some issues when people run some codes in a php which is
 compiled with --with-curlwrappers, like #61336, or the recently test script
 for #64433 (failed when curl wrappers enabled).

I know, that the curl wrapper should act the same as php http wrapper,
 but for now, we need to provide the ability to user, that they can warn if
 they codes can not run with curl wrappers..

here are some really usages:
 https://github.com/UnionOfRAD/lithium/issues/59  and
 http://weizhifeng.net/wrong-with-curlwrappers.html

I propose to add a constant : bool CURL_WRAPPERS_ENABLE

The curl wrappers have always been a major pain, with plenty of bugs
and we tend to forget to add context options there to match the
standard wrapper on new feature.

It has been marked as experimental since forever, and I think its time
to face the failed experiment and remove it.

-Hannes

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

Re: [PHP-DEV] Optimizer+ bugreps

[Hannes Magnusson]

On Fri, Mar 8, 2013 at 12:56 PM, Christopher Jones
christopher.jo...@oracle.com wrote:


 On 03/02/2013 09:42 AM, Christopher Jones wrote:



 On 3/2/13 3:19 AM, Terry Ellison wrote:

 On 02/03/13 09:34, Pierre Joye wrote:


 Having it in peck right now allows that. But as of now it is not a
 PHP.net project so it makes little sense to have it listed there.

 On Mar 2, 2013 10:33 AM, Terry Ellison te...@ellisons.org.uk
 mailto:te...@ellisons.org.uk wrote:

 At what point is O+ reporting going to be possible through
 https://bugs.php.net/ ?

 I realize that this is a bit of a catch-22, but surely it would be
 better to allow properly tracked open bug reporting sooner rather
 later?


 Thanks Pierre, I understand and that's why I mentioned catch-22. AFAIK,
 there's no open bug and issue reporting available prior to its formal
 adoption, event though we all realize that it's going to be pretty much
 inevitable -- for compelling reasons -- and by the time it is adopted the
 first release will be a fait accompli.


 Bugs can (and have been) reported via
 https://github.com/zend-dev/ZendOptimizerPlus/issues
 I'm sure email reports will also do fine in the interim.

 Chris


 Felipe added ZO+ to the bugs.php.net Package affected drop-down today.


Hmmh.. That shouldn't be there as the current official issue tracker
for it is on github, and is linked from the pecl page..

Once it gets merged into php-src then that package should be created though.

-Hannes

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

Re: [PHP-DEV] VCS Account Request: sverbeek

[Hannes Magnusson]

On Mon, Mar 4, 2013 at 9:57 PM, Steven Verbeek dubcan...@gmail.com wrote:
 Could I get access too
 phpdoc
 php-src/ext/tokenizer

Sure.. But why?
Do you have any patches?
You don't seem to have sent even an email to this list before :]

-Hannes

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

Re: [PHP-DEV] Re: VCS Account Request: ardbiesheuvel

[Hannes Magnusson]

On Sat, Mar 2, 2013 at 7:07 PM, Ard Biesheuvel
ard.biesheu...@linaro.org wrote:
 On 3 March 2013 07:48, Hannes Magnusson hannes.magnus...@gmail.com wrote:
 On Thu, Jan 17, 2013 at 8:18 AM, PHP Group gr...@php.net wrote:
 rasmus approved ardbiesheuvel account request \o/


 Are you a different guy from abies (with an @ewi.tudelft.nl address)?
 Credited as the author of Firebird/InterBase driver for PDO  Interbase...

 The abies account is still active..

 Yes, that is me. I didn't realize the old account was still active
 after all these years.


Do you still have access to that email address ?

We should probably try to migrate your accounts, so if you still have
access to that email address you can reset your password at
https://master.php.net/forgot.php and I'll merge your karma (if there
is any difference) and delete your new account...
Sounds good?

If you'd like to change your username to your new one we can delete
your old account and merge your karma (if there is any difference) to
your new accounts and delete the old account..

-Hannes

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

Re: [PHP-DEV] Re: VCS Account Request: ardbiesheuvel

[Hannes Magnusson]

On Sun, Mar 3, 2013 at 3:25 AM, Ard Biesheuvel
ard.biesheu...@linaro.org wrote:
 On 3 March 2013 18:08, Hannes Magnusson hannes.magnus...@gmail.com wrote:

 If you'd like to change your username to your new one we can delete
 your old account and merge your karma (if there is any difference) to
 your new accounts and delete the old account..


 I am fine using the new account. If there is a need to merge the
 karma, please do so but I think the new account has all the karma I
 need.

You can't really have two open accounts..
Few *random* reasons for that would be;
 - Since we employ seriously crazy strict voting system on every
single change, you currently have two votes..
 - You can pretend to be a 6years old using one accounts and destroy
out system, get your karma revoked, and then do it all again on your
other accounts
 - Code reviewing / commit validation is more difficult.

I'll delete your old account, if for no other reason then just
because I can :)
Let me know if you hit any issues :)

-Hannes

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

Re: [PHP-DEV] Re: VCS Account Request: ardbiesheuvel

[Hannes Magnusson]

On Sun, Mar 3, 2013 at 3:38 AM, Ard Biesheuvel
ard.biesheu...@linaro.org wrote:
 On 3 March 2013 12:36, Hannes Magnusson hannes.magnus...@gmail.com wrote:
 On Sun, Mar 3, 2013 at 3:25 AM, Ard Biesheuvel
 ard.biesheu...@linaro.org wrote:
 I am fine using the new account. If there is a need to merge the
 karma, please do so but I think the new account has all the karma I
 need.

 You can't really have two open accounts..
 Few *random* reasons for that would be;
  - Since we employ seriously crazy strict voting system on every
 single change, you currently have two votes..
  - You can pretend to be a 6years old using one accounts and destroy
 out system, get your karma revoked, and then do it all again on your
 other accounts
  - Code reviewing / commit validation is more difficult.

 I'll delete your old account, if for no other reason then just
 because I can :)
 Let me know if you hit any issues :)


 As I said, I am fine using the new account, so sure, go ahead and
 delete the old one.

Thanks!
I've deleted the old account now and removed his karma (your new
account already has more karma then the previous user anyway).

If something got fuckedup, or you need to verify your previous
username on various social media services (github, ohloh, whatever)..
let me know and we'll figure something out!

-Hannes

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

Re: [PHP-DEV] Re: VCS Account Request: ardbiesheuvel

[Hannes Magnusson]

On Thu, Jan 17, 2013 at 8:18 AM, PHP Group gr...@php.net wrote:
 rasmus approved ardbiesheuvel account request \o/


Are you a different guy from abies (with an @ewi.tudelft.nl address)?
Credited as the author of Firebird/InterBase driver for PDO  Interbase...

The abies account is still active..

-Hannes

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

[PHP-DEV] Re: [PHP-WEBMASTER] Re: [PHP Wiki] new user: fabpot

[Hannes Magnusson]

On Thu, Feb 28, 2013 at 11:10 PM, Fabien Potencier
fabien.potenc...@gmail.com wrote:
 On 2/28/13 10:32 AM, Peter Cowburn wrote:

 cc Fabien

 On 28 February 2013 09:25, Hannes Magnusson hannes.magnus...@gmail.com
 wrote:

 Simply registering for an wiki account doesn't give you any karma to
 edit anything...
 Are you planning on modifying or creating content on the wiki, and if
 so - which namespace?


 I just wanted to vote on some RFCs (as the project leader for Symfony).



I truly don't know how that works. Never understood who are allowed to vote.
Can someone on internals@ please explain that part to me so I can give
Fabien karma (or not)?

-Hannes

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

[PHP-DEV] Re: [PHP-WEBMASTER] Re: [PHP Wiki] new user: fabpot

[Hannes Magnusson]

On Fri, Mar 1, 2013 at 11:20 AM, Pierre Joye pierre@gmail.com wrote:
 On Fri, Mar 1, 2013 at 8:03 PM, Hannes Magnusson
 hannes.magnus...@gmail.com wrote:
 On Thu, Feb 28, 2013 at 11:10 PM, Fabien Potencier
 fabien.potenc...@gmail.com wrote:
 On 2/28/13 10:32 AM, Peter Cowburn wrote:

 cc Fabien

 On 28 February 2013 09:25, Hannes Magnusson hannes.magnus...@gmail.com
 wrote:

 Simply registering for an wiki account doesn't give you any karma to
 edit anything...
 Are you planning on modifying or creating content on the wiki, and if
 so - which namespace?


 I just wanted to vote on some RFCs (as the project leader for Symfony).



 I truly don't know how that works. Never understood who are allowed to 
 vote.
 Can someone on internals@ please explain that part to me so I can give
 Fabien karma (or not)?

 Fabien wants to write a RFC. Anyone can do, simply give him the 'RFC'
 karma, done now.

I am well aware of that as I am the onlyone who is monitoring user
requests to update the wiki.

However when a request comes in, like this one, about the ability to
*vote* I am lost.
I don't understand those voting rules and therefore am asking for
clarification, again.

If anyone understand them, please let me know. The previous guys
asking for vote karma are still in the queue as I never got any
response on the rules.

-Hannes

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

[PHP-DEV] Re: [PHP-WEBMASTER] Re: [PHP Wiki] new user: fabpot

[Hannes Magnusson]

On Fri, Mar 1, 2013 at 11:56 AM, Pierre Joye pierre@gmail.com wrote:
 On Fri, Mar 1, 2013 at 8:44 PM, Hannes Magnusson
 hannes.magnus...@gmail.com wrote:

 I am well aware of that as I am the onlyone who is monitoring user
 requests to update the wiki.

 However when a request comes in, like this one, about the ability to
 *vote* I am lost.

 Project lead can vote yes. Also in the case of Fabien it is even more
 easy, he provided so many tests (directly or via his teams), he is a
 contributor per se.

 I don't understand those voting rules and therefore am asking for
 clarification, again.

 php.net contributors,  project leaders (verified, not random ppl).

How do I verify it, and which projects are applicable?
Does it depend on how many contributors it has? Users? How long it has
been around?
Commercial? OSS? Library? Framework? Applications? Websites?

-Hannes

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

Re: [PHP-DEV] Re: [PHP-WEBMASTER] Re: [PHP Wiki] new user: fabpot

[Hannes Magnusson]

On Fri, Mar 1, 2013 at 1:19 PM, Johannes Schlüter johan...@schlueters.de
wrote:


 Derick Rethans der...@php.net wrote:
Exactly, this random apply rules nonsense needs to stop. I have nothing

against Fabien voting but there is nowhere written who can vote or not
(no, the voting RFC is too vague as well). I for one, would like to see

a much stricter list of people who can vote.

 I often wonder about many names on the list of voters, there are names I
have never seen ... which is really weird in my opinion. Either make it
open for everybody and his dog or make a clear restriction.



Currently the easiest way to get voting karma is to say you'll be creating
an RFC, as anyone with karma in that namespace can automatically vote
because votes happen in that namespace.
Anyones mother can create a RFC (and therefore vote on anything), but if
you just want to vote then you need to get approval from internals@.

That voting RFC is btw really weird, I don't know how it got accepted.
People with php.net SVN accounts that have contributed code to PHP is
particularly funny as it disqualifies everyone working on docs, websites,
infrastructure and whatnot (we don't however have separate roles for your
karma level, so anyone with VCS account has full wiki privileges and can
therefore vote).

And considering the next part:
Representatives from the PHP community, that will be chosen by those with
php.net SVN accounts
Is even more awesome, as the people working on docs, websites and
infrastructure can choose those community representatives - without being
able to vote themselves. All they have to do is I now pronounce you
community representative. Hurray!


I like the old approach better. When no clear consensus were reached, we
would vote. Anyone in the world could vote on the mailinglist, and votes
were creatively interpreted grouping people with karma vs community.

Doing the same with polling is however difficult. Its a whole lot easier to
spot fraud emails then it is to spot people signing up with multiple wiki
accounts with the intentions of skewing the results.

-Hannes

Re: [PHP-DEV] [VOTE] Improved Linux process title support in the CLI SAPI

[Hannes Magnusson]

On Thu, Feb 21, 2013 at 4:42 PM, Keyur Govande keyurgova...@gmail.com wrote:
 Hi everyone,

 With the 2 weeks discussion period up, I'm moving this RFC to the Voting
 stage. I'd like to get this into 5.5.

 Most of the reaction has been positive and is archived here:
 http://marc.info/?t=13602158203r=1w=2

Just out of curiosity, I don't see it covered in the other thread; Is
there a reason why it cannot support sapi/fpm?

-Hannes

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

Re: [PHP-DEV] [VOTE] Improved Linux process title support in the CLI SAPI

[Hannes Magnusson]

On Fri, Feb 22, 2013 at 11:52 AM, Rasmus Lerdorf ras...@lerdorf.com wrote:
 On 02/22/2013 11:48 AM, Hannes Magnusson wrote:
 On Thu, Feb 21, 2013 at 4:42 PM, Keyur Govande keyurgova...@gmail.com 
 wrote:
 Hi everyone,

 With the 2 weeks discussion period up, I'm moving this RFC to the Voting
 stage. I'd like to get this into 5.5.

 Most of the reaction has been positive and is archived here:
 http://marc.info/?t=13602158203r=1w=2

 Just out of curiosity, I don't see it covered in the other thread; Is
 there a reason why it cannot support sapi/fpm?

 fpm has its own implementation already. I suppose we could swap out the
 one in fpm and replace it with this one, but that seems like a separate
 decision.

Right, which makes me worry about the function name.. cli_*.

-Hannes

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

Re: [PHP-DEV] Tokyo/Kyoto Cabinet support in DBA extension

[Hannes Magnusson]

On Tue, Feb 12, 2013 at 11:08 AM, Chris MacPherson ch...@kombine.co.uk wrote:
 Just wondering if anyone can tell me if Kyoto Cabinet support will be added
 to the DBA extension in the near future at all.

 I noticed this thread (
 http://marc.info/?l=php-internalsm=133389756213354w=2http://grokbase.com/t/php/php-internals/119yvjcjwr/tokyo-kyoto-cabinet-in-5-4)
 which mentions that there has been support added but looking in the DBA
 extension README file in the source code I can't see any mention of
 Tokyo/Kyoto Cabinet, just the qdbm predecessor.


Tokyo Cabinet support shipped with PHP 5.4.0.
Enable it by compiling PHP with --with-tcadb

-Hannes

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

Re: [PHP-DEV] Patch: Specify temp directory

[Hannes Magnusson]

On Jan 18, 2013 6:03 AM, ALeX Kazik a...@kazik.de wrote:

 Hi,

 some time ago I created a small patch to make it possible to specify
 the temp dir by the php.ini.

 It can be found here:
 https://bugs.php.net/bug.php?id=60524
 (my latest patch (against 5.4.3) also works for 5.4.11 and 5.5.0a3)

 Now I do wonder if anything will happen or if that's it?

 I would really appreciate if the patch would be included and hopefully
 also some other people.



Wouldn't it make more sense to have the ini consistent with the
function name, sys_temp_dir?

-Hannes

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

Fwd: [PHP-DEV] PHP5.5.0alpha2 release

[Hannes Magnusson]

From: jpauli jpa...@php.net
Date: Thu, Dec 20, 2012 at 9:26 AM
Subject: [PHP-DEV] PHP5.5.0alpha2 release
To: PHP Internals internals@lists.php.net



I would appreciate that you would use your full real name now that you
are representing the project as a release manager.

-Hannes

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

Re: [PHP-DEV] VCS Account Request: sajith

[Hannes Magnusson]

On Mon, Dec 17, 2012 at 12:00 AM, Sajith Thennakoon
sajith.b.thennak...@gmail.com wrote:
 Maintaining an official, bundled PHP extension

Which official bundled extension?


 Maintaining the documentation
 Translating the documentation
 Maintaining php.net

Have you introduced yourself to these guys? Sent any patches yet?
Discussed anything with anyone?

-Hannes

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

Re: [PHP-DEV] VCS Account Request: sajith

[Hannes Magnusson]

You should probably reach out to people who have organized conferences
and user groups before and ask for their experience - this is however
not a topic for the internals development list - and you don't need an
commit access to our repository to do so.

As for translating the docs.. It is a _huge_ task to create a new
translation and not something we recommend a one person to start
doing. You'll need a group of people to get started, which you should
probably coordinate with the local user group.

-Hannes

On Mon, Dec 17, 2012 at 9:43 PM, Sajith Thennakoon
sajith.b.thennak...@gmail.com wrote:
 Hi Hannes,

 I'm Sajith Thennakoon a Sri Lankan php developer and programmer. I need to
 contribute my self to php and php community and want to make php a popular
 open source language in Sri Lanka and I need to translate the php
 documentation into Sinhalese and found the php Sri Lanka Community. Also I
 need to organized the very first php conference in Sri Lanka. What should I
 do? How should I contribute. Pleae guide me.

 Thank you.


 On Tue, Dec 18, 2012 at 3:34 AM, Hannes Magnusson
 hannes.magnus...@gmail.com wrote:

 On Mon, Dec 17, 2012 at 12:00 AM, Sajith Thennakoon
 sajith.b.thennak...@gmail.com wrote:
  Maintaining an official, bundled PHP extension

 Which official bundled extension?


  Maintaining the documentation
  Translating the documentation
  Maintaining php.net

 Have you introduced yourself to these guys? Sent any patches yet?
 Discussed anything with anyone?

 -Hannes



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

Re: [PHP-DEV] Git Access

[Hannes Magnusson]

Which push url are you using?
See https://wiki.php.net/vcs/gitfaq?#clone_url_and_push_url

You may want to upload your key to master and use the ssh urls

-Hannes


On Wed, Dec 5, 2012 at 2:02 PM, Sara Golemon poll...@php.net wrote:
 It's been awhile since I last commited (pre git, in fact) and now I'm
 getting a failure during 'git push'.  It asks for my password, I enter
 it, it asks again, I enter again, and I get a permission denied error.
  Do I need to do something to update my access?  I've done a password
 change on master.php.net hoping that'd propagate out but still no
 love.

 -Sara

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


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

Re: [PHP-DEV] Download mirrors lagging behind

[Hannes Magnusson]

On Fri, Nov 23, 2012 at 5:40 AM, Bostjan Skufca bost...@a2o.si wrote:
 Hi there,

 1. is there any way to get mirrors to sync faster? si1.php.net in lagging
 behind, and there is no way to choose any other mirror (except manipulating
 URI manually).
 This is not the first time though, I've noticed this for the past couple of
 releases, at least.

All mirrors should be updating atleast once an hour, I don't know why
the Slovenian mirror isn't.
The maintainer is CCed and he'll fix it ASAP, or Dan will probably
nuke his mirror :)


 2. Also, when release it not found on the mirror, 200 OK is returned,
 leading installation software to think that archive was downloaded
 sucessfully (fails with md5 or gunzip later on though).


If you open up the file you'll see this is the mirror selection page.
You can pick which mirror you want to download from.

We haven't changed this for years so this method of fetching
/from/a/mirror has never resulted in getting the actual archive..
You need to /from/*this*/mirror or /from/[XXX].php.net/mirror


And please try to use the apropriate mailinglists ... internals@ has
nothing to do with the mirroring or the webiste. The php-mirrors@ and
php-webmaster@ do :]

-Hannes

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

Re: [PHP-DEV] Changing the default value of true for CURLOPT_SSL_VERIFYHOST

[Hannes Magnusson]

On Wed, Oct 24, 2012 at 10:46 PM, JJ ja...@php.net wrote:
 On Wed, Oct 24, 2012 at 10:34 PM, Sherif Ramadan
 theanomaly...@gmail.com wrote:
 I understand there are people out there that don't read the
 documentation and aren't aware of the difference between
 curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, 2); and curl_setopt($ch,
 CURLOPT_SSL_VERIFYHOST, true); but still... I don't think this is a
 good idea either.

 I highly doubt code that sets CURLOPT_SSL_VERIFYHOST = true meant to
 imply CURLOPT_SSL_VERIFYHOST = 1...which essentially bypasses host
 verification.

 According to libcurl, CURLOPT_SSL_VERIFYHOST = 1 is not ordinarily a
 useful setting.


The curl stream wrapper sets this option to 1 when using the
curl_verify_ssl_host context option.
I imagine that should be fixed too then?

-Hannes

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

Re: [PHP-DEV] Wiki account

[Hannes Magnusson]

On Thu, Oct 18, 2012 at 1:08 AM, Marcello Duarte
marcello.dua...@gmail.com wrote:
 On 18 Oct 2012, at 02:20, Hannes Magnusson wrote:

 On Wed, Oct 17, 2012 at 2:49 AM, Pierre Joye pierre@gmail.com wrote:
 Marcello likes to write a RFC

 On Wed, Oct 17, 2012 at 11:28 AM, Marcello Duarte
 marcello.dua...@gmail.com wrote:
 Hi,

 Can I please have a wiki account?


 People who cannot read do not get wiki karma:
 https://wiki.php.net/start?do=register :(


 Ok, ignoring the rudeness...

 I have an account, and I can read (pun intended), however I cannot write or 
 create pages. I assumed it was a privilege issue. That's what I kept 
 repeating to Pierre on twitter, to which he reply: send an email to the 
 internals asking for a wiki account.


I don't know why he is asking you to send an email here. The
registration page I linked to explicitly says php-webmaster@ and the
instruction to get write karma.

-Hannes

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

Re: [PHP-DEV] Wiki account

[Hannes Magnusson]

On Wed, Oct 17, 2012 at 2:49 AM, Pierre Joye pierre@gmail.com wrote:
 Marcello likes to write a RFC

 On Wed, Oct 17, 2012 at 11:28 AM, Marcello Duarte
 marcello.dua...@gmail.com wrote:
 Hi,

 Can I please have a wiki account?


People who cannot read do not get wiki karma:
https://wiki.php.net/start?do=register :(

-Hannes

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

Re: [PHP-DEV] Issue with PHP Documentation Server

[Hannes Magnusson]

On Wed, Oct 10, 2012 at 10:50 PM, Murali Krishna Bachu
murali_nit...@yahoo.co.in wrote:
 Hi,

 Links in PHP Doc page sidebar are pointed to wrong links. They are not 
 accessible.

 http://in2.php.net/curl_version

 One of the Sidebar link : 
 http://in2.php.net/203.199.107.5manual/en/function.curl-close.php

 Can some one check the issue?

Should be fixed now.
In the future. Please file a bug report or notify
php-webmas...@lists.php.net of website related issues.

-Hannes

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

Re: [PHP-DEV] an configure option to enable-all

[Hannes Magnusson]

On Tue, Sep 18, 2012 at 8:59 AM, Pierre Joye pierre@gmail.com wrote:
 hi,

 On Mon, Sep 17, 2012 at 7:54 PM, Hannes Magnusson
 hannes.magnus...@gmail.com wrote:
 Something like the attached patch could work, but that means we would
 have to update all the config.m4s :]

 As far as I remember, the enable/disable option default behavior is
 what is used in the --help. So basically we do have --enable-all as

Its not basically. We *do* have it, it is very explicit in the code.


 the --disable-all being set to false. I would document that as such
 instead of modifying the m4 macros everywhere, much less painful.

That patch introduced --enable-all-available which is completely
different to --enable-all.

--enable-all-available would automatically compile all extensions that
the platform supports (i.e. has the libraries available). For
extensions the platform is missing the library, it would just jump
over it - as aposed to fail and bail out like --enable-all does.

-Hannes

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

Re: [PHP-DEV] clearing up who can propose RFCs

[Hannes Magnusson]

On Fri, Sep 14, 2012 at 10:36 AM, Ferenc Kovacs tyr...@gmail.com wrote:
 Hi,

 I was asked in a private email that it is true or not that *anybody* can
 create an RFC.
 As this isn't the first time to see that question I think that we could
 document that a little bit clearly.
 Here is how I responded to the question, and maybe we could improve on it
 and put that somewhere in the wiki so we can point these kind of questions
 there for the future.

 Anybody can propose an RFC, here are the necessary steps:

Don't we need an RFC for that? ;)

-Hannes

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

Re: [PHP-DEV] an configure option to enable-all

[Hannes Magnusson]

On Mon, Sep 17, 2012 at 9:59 AM, jpauli jpa...@php.net wrote:

 I'm confused.. --enable-all is already supported, just like --disable-all ?

 -Hannes

 AFAIR no :) We have a --disable-all , but no --enable-all.

 I'm +1 to add such an option if possible :)


Can you please explain to me how it is not working?

~/Sources/php/php-5.3 (PHP-5.3) $ ./configure --enable-all
configure: error: Cannot find enchant

And no, ext/enchant is not enabled by default.

-Hannes

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

Re: [PHP-DEV] an configure option to enable-all

[Hannes Magnusson]

On Mon, Sep 17, 2012 at 4:50 PM, Philip Olson phi...@roshambo.org wrote:

 On Sep 17, 2012, at 8:30 AM, jpauli wrote:

 On Mon, Sep 17, 2012 at 2:48 PM, Hannes Magnusson
 hannes.magnus...@gmail.com wrote:
 On Mon, Sep 17, 2012 at 9:59 AM, jpauli jpa...@php.net wrote:

 I'm confused.. --enable-all is already supported, just like --disable-all 
 ?

 -Hannes

 AFAIR no :) We have a --disable-all , but no --enable-all.

 I'm +1 to add such an option if possible :)


 Can you please explain to me how it is not working?

 ~/Sources/php/php-5.3 (PHP-5.3) $ ./configure --enable-all
 configure: error: Cannot find enchant

 And no, ext/enchant is not enabled by default.

 So the answer is : there is --enable-all switch , but it's not listed
 in the --help output

 Hello all,

 Interesting, I didn't think it existed but now realize why. It's not
 documented and it's not very useful.

 There's an old feature request (I wrote it so am surprised I forgot
 this exists) about differentiating between --with and --enable,
 along with checking if those are actually available on the system:

   https://bugs.php.net/24337
   https://bugs.php.net/33186

 Awhile ago Rasmus mentioned an idea about creating a shell script that'd
 check which options do (and do not) pass configure. I'm not sure how to
 do that but maybe someone else does. Just imagine being able to enable
 all possible extensions available on a system.. great for 'make test' :)


Something like the attached patch could work, but that means we would
have to update all the config.m4s :]


-Hannes
diff --git a/acinclude.m4 b/acinclude.m4
index adb9599..dd5af3b 100644
--- a/acinclude.m4
+++ b/acinclude.m4
@@ -2727,8 +2727,8 @@ AC_DEFUN([PHP_CHECK_CONFIGURE_OPTIONS],[
 ;;
 esac
 case $arg_name in
-  # Allow --disable-all / --enable-all
-  enable-all[)];;
+  # Allow --disable-all / --enable-all / --enable-all-available
+  enable-all|enable-all-available[)];;
 
   # Allow certain libtool options
   enable-libtool-lock | with-pic | with-tags | enable-shared | 
enable-static | enable-fast-install | with-gnu-ld[)];;
@@ -2969,3 +2969,20 @@ $ac_bdir[$]ac_provsrc.o: \$(PHP_DTRACE_OBJS)
 
 EOF
 ])
+
+
+dnl
+dnl PHP_EXTTENSION_NOT_AVAILABLE(message)
+dnl
+dnl Wrapper for AC_MSG_[WARN|ERROR] depending if we are trying
+dnl to enable all available extensions on the platform, or explicitly
+dnl enabling the extension.
+dnl 
+AC_DEFUN([PHP_EXTTENSION_NOT_AVAILABLE],[
+  if test $PHP_ENABLE_ALL_AVAILABLE = yes; then
+AC_MSG_WARN($1)
+  else
+AC_MSG_ERROR($1)
+  fi
+])
+  
diff --git a/configure.in b/configure.in
index e5e1cd6..10e4e5f 100644
--- a/configure.in
+++ b/configure.in
@@ -1011,6 +1011,15 @@ AC_ARG_ENABLE(all,
   PHP_ENABLE_ALL=$enableval
 ])
 
+AC_ARG_ENABLE(all-available,
+[ --enable-all-available   Enable all extensions available on the platform
+], [
+  if test $enableval = yes; then
+PHP_ENABLE_ALL=$enableval
+  fi
+  PHP_ENABLE_ALL_AVAILABLE=$enableval
+])
+
 # reading config stubs
 esyscmd(./build/config-stubs ext)
 
diff --git a/ext/enchant/config.m4 b/ext/enchant/config.m4
index cc40d0b..7b2990a 100755
--- a/ext/enchant/config.m4
+++ b/ext/enchant/config.m4
@@ -24,19 +24,19 @@ if test $PHP_ENCHANT != no; then
done
 
if test -z $ENCHANT_DIR; then
-   AC_MSG_ERROR(Cannot find enchant)
-   fi
-
-   ENCHANT_LIBDIR=$ENCHANT_DIR/lib
+   PHP_EXTTENSION_NOT_AVAILABLE(Cannot find enchant)
+else
+   ENCHANT_LIBDIR=$ENCHANT_DIR/lib
 
-   AC_DEFINE(HAVE_ENCHANT,1,[ ])
-   PHP_SUBST(ENCHANT_SHARED_LIBADD)
-   PHP_ADD_LIBRARY_WITH_PATH(enchant, $ENCHANT_LIBDIR, 
ENCHANT_SHARED_LIBADD)
-   PHP_ADD_INCLUDE($ENCHANT_INCDIR)
-   PHP_CHECK_LIBRARY(enchant, enchant_broker_set_param,
-   [
- AC_DEFINE(HAVE_ENCHANT_BROKER_SET_PARAM, 1, [ ])
- AC_DEFINE(ENCHANT_VERSION_STRING, 1.5.x, [ ])
-   ], [], [ -L$ENCHANT_LIB $ENCHANT_SHARED_LIBADD])
+   AC_DEFINE(HAVE_ENCHANT,1,[ ])
+   PHP_SUBST(ENCHANT_SHARED_LIBADD)
+   PHP_ADD_LIBRARY_WITH_PATH(enchant, $ENCHANT_LIBDIR, 
ENCHANT_SHARED_LIBADD)
+   PHP_ADD_INCLUDE($ENCHANT_INCDIR)
+   PHP_CHECK_LIBRARY(enchant, enchant_broker_set_param,
+   [
+ AC_DEFINE(HAVE_ENCHANT_BROKER_SET_PARAM, 1, [ ])
+ AC_DEFINE(ENCHANT_VERSION_STRING, 1.5.x, [ ])
+   ], [], [ -L$ENCHANT_LIB $ENCHANT_SHARED_LIBADD])
+   fi
 
 fi
-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] an configure option to enable-all

[Hannes Magnusson]

On Sun, Sep 16, 2012 at 8:50 PM, Michael Felt mamf...@gmail.com wrote:
 Hi. My apologies if I missed an obvious clue somewhere, but I am looking
 for a configure
 option to enable nearly everything - to be supplemented by select disable
 statements.

 In the past I have had complex configure scripts that I would like to simply
 with selective deletes, rather than discover afterwards that I forgot
 something.
 configure --help does not convince me it is listing all options
 (might be wong, might not be reading carefully enough).

 Thanks (even if just pointing me at what I should have found!).


I'm confused.. --enable-all is already supported, just like --disable-all ?

-Hannes

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

Re: [PHP-DEV] Download PHP binaries

[Hannes Magnusson]

On Sat, Sep 15, 2012 at 8:47 AM, Remi Collet r...@fedoraproject.org wrote:
 Hi,

 I recently noticed that on http://www.php.net/downloads.php,
 Redhat/CentOS Binaries link to a third party repository [1].

 First, this could be confused for users, as this is not a Red Hat or
 CentOS official repository.

None of these links are to any official distro repos as far as I know,
and we do not endorse them or maintain them or even officially support
them. If you know of any other relatively well maintained binaries for
any platforms, please let us know. I don't really see the point in
linking to the 'official distro repos' as the only reason people go to
that page is to either fix the stupid vendor installs, or get more up
to date packages then their distro offers out of the box.

I've added your repo to the list now. In the future, please understand
we have multiple mailinglists for a reason and use the appropriate
list next time around.

-Hannes

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

Re: [PHP-DEV] [VOTE] Add simplified password hashing API

[Hannes Magnusson]

On Mon, Sep 10, 2012 at 3:31 PM, Anthony Ferrara ircmax...@gmail.com wrote:
 Hannes,

 On Sun, Sep 9, 2012 at 12:23 PM, Hannes Magnusson
 hannes.magnus...@gmail.com wrote:

 On Tue, Sep 4, 2012 at 3:16 PM, Anthony Ferrara ircmax...@gmail.com
 wrote:
  Hello all,
 
  I'm opening the vote for the simplified password hashing API indicated
  here:
 
  https://wiki.php.net/rfc/password_hash
 


 I like the idea, but I don't understand why this isn't developed as an
 extension first and then brought into core when it has proven to work
 and actually simplify things for the user?


 First off, this has been discussed on the list for literally months.  Why
 wait until the day before voting can end before bringing this up?

So commenting is strictly forbidden during votes?


 Secondly, the main reason for not developing this as an extension is that
 there's really no benefit to it. There are little to no performance gains to
 be had by the C implementation. It can live quite as easily as a PHP
 library.

The benefit is that it can be tested properly and bugs discovered and
ironed out first.
This is not the sort of thing you want to get security bug reports the
day after its released in core.
If your ego is big enough you can guarantee you have tested this
thoroughly and want it to become the recommended way.. You have to be
damn sure you don't fuck it up.

This is exactly the sort of thing that doesn't need to be developed in
the core tree, but can later be merged in once proven successful.


Like I said, I really like the idea, just don't see why it isn't
tested out as an pecl extension first.


 Especially considering the patch is unfinished.


 Aside from adding a few more tests, what's unfinished? If you're referring
 to the line in the RFC, I just haven't updated it. The patch has been worked
 on and is in a place where I'd be comfortable submitting it...

The test suite seems very limited, and the code seems to be waiting
for more algorithms to be implemented.

-Hannes

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

Re: [PHP-DEV] What is our definition of a Backward Compatibility Break

[Hannes Magnusson]

On Tue, Sep 11, 2012 at 12:08 AM, Stas Malyshev smalys...@sugarcrm.com wrote:
 Hi!

 Based on our recent discussion on #pecl , I'd like we clarify what we
 think is a BCB (Backward Compatibility Break) as well as what only
 minor BC breaks could mean.
 Stas' recent topic on internals On BC and interfaces may serve as a
 reflection basis.
 As our release process told us that we should not add BCB (but only
 minor ones ... hum) in any minor release (nor revision), and as 5.5
 release process is going to start soon, I'd like we try to all agree
 on that point.

 I think first we have to distinguish several levels of BC:

 1. Binary BC
 2. Source-level extension BC
 3. PHP Code (API) BC

 Binary BC means that extension compiled with one version would work with
 another without recompilation. We keep this level of compatibility
 through all minor (5.x) releases and breaking it is an absolute no-no.
 However, between minors (5.5 - 5.5) breaking it is fine.

Typo alert. That should say 5.4 - 5.5 :)

-Hannes

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

Re: [PHP-DEV] [VOTE] Add simplified password hashing API

[Hannes Magnusson]

On Tue, Sep 4, 2012 at 3:16 PM, Anthony Ferrara ircmax...@gmail.com wrote:
 Hello all,

 I'm opening the vote for the simplified password hashing API indicated here:

 https://wiki.php.net/rfc/password_hash



I like the idea, but I don't understand why this isn't developed as an
extension first and then brought into core when it has proven to work
and actually simplify things for the user?
Especially considering the patch is unfinished.

-Hannes

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

Re: [PHP-DEV] [VOTE] Generators

[Hannes Magnusson]

On Wed, Aug 29, 2012 at 10:19 PM, Derick Rethans der...@php.net wrote:
 On Wed, 29 Aug 2012, Nikita Popov wrote:

 On Wed, Aug 29, 2012 at 10:10 PM, Derick Rethans der...@php.net wrote:
  On Wed, 29 Aug 2012, Nikita Popov wrote:
 
   function bind(array $keys, array $row)
   {
   foreach($keys as $key)
   yield $key = $row[$key];
   }
  
   $row = [];
   $it = bind(['a', 'b'], $row);
  
   foreach($it as $key = $ref)
   echo $key;
   echo \n;
   foreach($it as $key = $ref)
   echo $key;
 
  Thanks, this is now fixed. It'll throw an exception now, saying that
  you can't traverse an already closed generator.
 
  Nothing in the core throws an exception, why would this?!

 To my knowledge all iterator-related functionality is supposed to
 throw exceptions (as it is a feature related to the object oriented
 part of PHP). At leas this is what a quick search of the code base
 gave me. (See http://lxr.php.net/xref/PHP_TRUNK/ext/spl/spl_dllist.c#1248
 for example).

 ext/spl - SPL is not *core* language. The generators are. Don't throw
 exceptions from core features!

In general I agree with core language features shouldn't be throwing
exceptions...
But SPL definitely should never have been its own extension and most
of it should have been core language features - and throwing
exceptions in many of those cases makes perfect sense.

We also have the case of IteratorAggregate throwing exception (which
is a *core* language feature, not defined in ext/spl):

$ ./sapi/cli/php -r 'class foo implements IteratorAggregate { function
getIterator() { return new stdclass; } } foreach(new foo as $bar) {}'

Fatal error: Uncaught exception 'Exception' with message 'Objects
returned by foo::getIterator() must be traversable or implement
interface Iterator' in Command line code:1
Stack trace:
#0 Command line code(1): unknown()
#1 {main}
  thrown in Command line code on line 1

-Hannes

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

Re: [PHP-DEV] Re: [VOTE]Call for voting: support use list in foreach

[Hannes Magnusson]

On Sun, Aug 26, 2012 at 2:17 PM, Peter Cowburn petercowb...@gmail.com wrote:
 On 26 August 2012 18:48, Stas Malyshev smalys...@sugarcrm.com wrote:

 I got a PHP Wiki account but couldn't vote. Are you sure the Wiki
 accounts got the permissions to vote?

 Hm... Not sure, maybe somebody has to enable it?

 There is a special group (voting IIRC) for wiki accounts with voting
 rights.  Ordinary (non-php.net) wiki account holders cannot vote.
 Someone with DB access would need to check, but I believe there are
 (were) only a couple of people in this special voting group.


There are 1651 persons with php.net VCS account. There is however no
way to tell how active they are.
There are 2 people with specific voting karma, I think Pierre demanded
they got karma.

Noone else can vote. That should be obvious by looking up the names of
the voters on http://people.php.net.

And why is this discussion buried in a foreach() voting announcement thread?

-Hannes

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

Re: [PHP-DEV] Re: [VOTE]Call for voting: support use list in foreach

[Hannes Magnusson]

On Sun, Aug 26, 2012 at 2:20 PM, Stas Malyshev smalys...@sugarcrm.com wrote:
 Hi!

 And this is how democracy works, Stas. If voters don't bother to turn
 up, too bad.

 Putting aside the fact that democracy has very little to do with what
 we're trying to do here (we're not government, we're opensource
 project), that's how democracy *doesn't work*. As you noticed, it is
 too bad, and it is exactly the problem we're having - without
 participation, votes are decided by a random sample of whoever bothered
 to appear, often on a single vote.
 This is not a way to build consensus.  It is a very unhealthy state of
 things, and it only contributes to the image of PHP as a project having
 no direction, no governance and basically existing in a state of
 brownian motion. I thought we were trying to shed this image.


I couldn't agree more.
Which is why I have been trying to preach
http://producingoss.com/en/consensus-democracy.html

-Hannes

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

Re: [PHP-DEV] Why do disabled functions / classes generate a WARNING.

[Hannes Magnusson]

On Fri, Aug 3, 2012 at 8:08 AM, Leigh lei...@gmail.com wrote:
 Hi all,

 Can anyone explain to me the reason that when a function or class is
 disabled via the ini setting, an attempt to access the disabled item
 generates a non-fatal error?

Because there isn't anything actually wrong.

A fatal error is reserved for things we cannot recover from, but a
disabled function is easily recoverable.

-Hannes

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

Re: [PHP-DEV] VCS Account Request: luballomuyoyo

[Hannes Magnusson]

On Tue, Jul 24, 2012 at 9:35 AM, Jacob Luballo Muyoyo
luballomuy...@gmail.com wrote:
 Developing the PHP runtimeamp;#13;amp;#10;Maintaining an official, bundled 
 PHP extensionamp;#13;amp;#10;Maintaining 
 www.php.netamp;#13;amp;#10;Maintaining the 
 documentationamp;#13;amp;#10;Translating the documentationamp;#13;amp;#10;




Please get in contact with the appropriate groups, introduce yourself,
and participate in their effort before requesting vcs account

-Hannes

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

Re: [PHP-DEV] RFC karma request

[Hannes Magnusson]

On Wed, Jul 18, 2012 at 11:43 PM, Galen Wright-Watson
ww.ga...@gmail.com wrote:
 I'd like to see some version of the null-coalescing ternary operator
 (recently brought up in a thread started by Rafael Dohms) make it into PHP.
 To help it along, may I have RFC karma so I can draft a proposal? My PHP
 wiki account name is outis, e-mail is ww.ga...@gmail.com.

 If there's a better/approved way of getting RFC karma than posting on the
 internals list, please let me know. So far, I haven't been able to find any
 official documentation on how.

The trick is to read the registration page :]

You should now have karma to edit/create stuff in the /rfc namespace.

-Hannes

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

Re: [PHP-DEV] Docs: php.ini vs. parse_ini_file()

[Hannes Magnusson]

On Wed, Jul 18, 2012 at 1:19 AM, Kris Craig kris.cr...@gmail.com wrote:
 I just noticed something that I hadn't really thought about before.  I
 couldn't remember the name of the function for parsing INI files so I did a
 quick search.  It took me straight to the page for php.ini directives.  I
 had to select online documentation from the dropdown and try again, this
 time navigating down to the third result.

 Not overly cumbersome, of course, but I started thinking that maybe this
 could be more difficult for someone who might be newer to PHP.  I also
 tried a Google search for 'php ini' (no quotes) to see what I'd get, and
 the first 15 results (all of the first page and the top half of the second)
 were for php.ini stuff.  The 16th result was finally the parse_ini_file()
 function.  A lot of newbies in particular use Google as their first stop
 when trying to find PHP functions for doing stuff, so this could give some
 people the impression that PHP doesn't even have an INI parsing function.


 Of course, most of this we really have no control over, but I would like to
 propose adding a link to parse_ini_file() on the php.ini man pages (perhaps
 something along the lines of, Are you looking for?).  I can make the
 edits myself but I'd like to see what y'all think first.



I don't understand why on earth your are mailing the PHP *internal
developer mailinglist* with this matter?

If you have any improvement suggestions for the documentations:
https://edit.php.net

-Hannes

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

Re: [PHP-DEV] Docs: php.ini vs. parse_ini_file()

[Hannes Magnusson]

On Wed, Jul 18, 2012 at 1:19 AM, Kris Craig kris.cr...@gmail.com wrote:
 I just noticed something that I hadn't really thought about before.  I
 couldn't remember the name of the function for parsing INI files so I did a
 quick search.  It took me straight to the page for php.ini directives.  I
 had to select online documentation from the dropdown and try again, this
 time navigating down to the third result.

 Not overly cumbersome, of course, but I started thinking that maybe this
 could be more difficult for someone who might be newer to PHP.  I also
 tried a Google search for 'php ini' (no quotes) to see what I'd get, and
 the first 15 results (all of the first page and the top half of the second)
 were for php.ini stuff.  The 16th result was finally the parse_ini_file()
 function.  A lot of newbies in particular use Google as their first stop
 when trying to find PHP functions for doing stuff, so this could give some
 people the impression that PHP doesn't even have an INI parsing function.


 Of course, most of this we really have no control over, but I would like to
 propose adding a link to parse_ini_file() on the php.ini man pages (perhaps
 something along the lines of, Are you looking for?).  I can make the
 edits myself but I'd like to see what y'all think first.



I don't understand why on earth your are mailing the PHP *internal
developer mailinglist* with this matter?

If you have any improvement suggestions for the documentations:
https://edit.php.net

-Hannes

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

Re: [PHP-DEV] Docs: php.ini vs. parse_ini_file()

[Hannes Magnusson]

On Wed, Jul 18, 2012 at 7:26 PM, Kris Craig kris.cr...@gmail.com wrote:

 I don't understand why on earth your are mailing the PHP *internal
 developer mailinglist* with this matter?

 If you have any improvement suggestions for the documentations:
 https://edit.php.net

 -Hannes


 I've seen the docs discussed on this list plenty of times.  We do maintain
 those as well as the code, after all.  Unless you're proposing changing the
 name of this list to *internal code developer mailinglist*, then I really
 don't think there's reason to get butthurt over it.

I cannot say I have seen a single patch from you to the documentations.
And every subproject of PHP.net has its own list, in this case
php...@lists.php.net

And yes. That is _exactly_ what this list is for; the internal code.

This list gets crapload of weird spam, and there are very few people
from phpdoc@ that have the time to read all threads here to spot doc
discussions.

Use the correct list.

-Hannes

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

Re: [PHP-DEV] [proposal + pull request] Replace logo GUIDs with data URIs

[Hannes Magnusson]

On Sat, Jul 14, 2012 at 9:49 PM, Andrew Faulds ajf...@googlemail.com wrote:
 Hi there,

 This is a patch that replaces PHP's infamous logo GUIDs with data URIs
 instead, and also embed PHP credits in the phpinfo() page, hidden
 using JavaScript (but gracefully degrading), to eliminate these GUIDs
 altogether.

 :)

 https://github.com/php/php-src/pull/132


The sapi/cli/tests/php_cli_server_011.phpt testcase looks like a real testcase..
It should probably be rewritten then removed completely.

And I actually know of websites using the functions to display the logo..
Is there some way we could provide a BC function for it somehow?
Maybe rather then removing the functions, make then return the data uris?

-Hannes

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

Re: [PHP-DEV] Re: bug 18556 - tolower locales

[Hannes Magnusson]

On Wed, Jul 11, 2012 at 7:08 PM, Stas Malyshev smalys...@sugarcrm.com wrote:
 Hi!

 Even if the concerns from this thread can be cleared I don't think we
 should change the core language in a version like 5.3. 5.3 users who are
 hit by this have their work-around (I assume), others have a good reason
 to use a more modern PHP.

 OK, I'll leave 5.3 alone then.
 It shouldn't be much of a change unless somebody used non-ASCII class
 names with different cases (which seems to be quite unlikely) but for
 stability's sake we could keep it out of 5.3.


Hang on. Are you really going to push this into 5.4?

-Hannes

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