Ahhh okay that explains where this change is coming from. Thanks a lot, Dan!
I wonder if this side effect ("all dependencies are iterated also
during "make install") is intentional.
Maybe Niki can chime in on GitHub; I'll ping him there, as well as the
original author.
Thanks a lot!
David
P.S.
REFIX directory that, in its
entirety, can be compressed into an archive for distribution of only
that extension's files.
Does that make sense?
On Thu, Dec 9, 2021 at 8:28 PM Dan Ackroyd wrote:
>
> On Wed, 8 Dec 2021 at 15:25, David Zuelke via internals
> wrote:
> >
> >
for PHP.
David
On Thu, Dec 9, 2021 at 6:14 PM Glash Gnome wrote:
>
> Right.
> > configure && make && make install
> works.
>
> For my personal information : Now which command should I use to get the error
> ?
>
>
> Le jeu. 9 déc. 2021 à 17:34,
can't reproduce the error with my build procedure.
> But, if I use "make -d install' insteadof "make && make install' I get errors.
>
> Can you confirm it ?
>
>
>
>
>
> Le jeu. 9 déc. 2021 à 03:19, David Zuelke a écrit :
>>
>> Ye
Glash Gnome wrote:
>
> Thanks, I'll check it out.
>
> I'm confused. Can you tell me if you have this problem with this extension
> (PHP8 / 7/5>):
> https://github.com/gtkphp/php-ext-cairo-src checkout PHP-8.0
>
> At the moment I need to check some depen
Dec 9, 2021 at 12:33 AM Glash Gnome wrote:
>
> Hello,
>
> Can you tell me what the program is in step 7)
>
> > package up
>
> Thanks you,
>
>
> Le mer. 8 déc. 2021 à 16:25, David Zuelke via internals
> a écrit :
>>
>> Hi all,
>>
>&g
Hi all,
When building shared extensions for PHP for the purpose of packaging
and distributing the builds, the build environment obviously needs PHP
installed in the destination directory structure (for headers, phpize,
and so forth).
But the resulting archive of the built extension should only co
The 7.4.7 release post on php.net links to
http://www.php.net/ChangeLog-7.php#7.4.6 for the changelog.
On Thu, Jun 11, 2020 at 4:16 PM Derick Rethans wrote:
>
> The PHP development team announces the immediate availability of PHP
> 7.4.7. This is a security bug fix release.
>
> All PHP 7.4 users
You're listing libsodium versions 0.15 and 0.13 there, but it should
be 1.0.15 and 1.0.13.
Maybe for everyone's reference: Ubuntu 16.04 LTS comes with no
libargon2, and with libsodium 1.0.8; 18.04 LTS comes with libargon2
and with libsodium 1.0.16.
Debian Stretch has 1.0.11, and 1.0.17 in backpor
Hi all,
Would it not be lovely to have, say, two new constants, that contain
the date (ISO, UTC, I guess) of when the running PHP series will be
end-of-maintenance and end-of-life?
Of course PHP_VERSION_SERIES_EOM_DATE and PHP_VERSION_SERIES_EOL_DATE
are a little verbose, but...
It would be real
I agree this should be fixed. It's pretty hilarious how this exact
case (fiddling with the xmlns prefix) is the only comment for
DOMElement::setAttributeNS:
http://php.net/manual/en/domelement.setattributens.php (although
unnecessary, as you don't have to "add namespaces" to a document, that
automa
On Tue, Jun 26, 2018 at 6:32 PM Kalle Sommer Nielsen wrote:
>
> Hi
>
> Den søn. 24. jun. 2018 kl. 18.47 skrev Nikita Popov :
> > If you have a minor deprecation in mind, but were too lazy to write an RFC
> > for it, please write me a mail until tomorrow, so that it might be included
> > as part of
Yeah I was going to say: work with Jakub, he has some good stuff in flight! :)
On Wed, Feb 21, 2018 at 11:52 AM, Jakub Zelenka wrote:
> Hey
>
> On Wed, Feb 21, 2018 at 12:42 AM, Stanislav Malyshev
> wrote:
>
>> Hi!
>>
>> I'd like to raise the question of FPM SAPI maintainership. Is it still
>> m
I'm trying to understand this one: https://bugs.php.net/bug.php?id=75837
Is that related to the optimizations in 7.2 around unused local
variables? Can that somehow be triggered by the @ operator? It's such
a trivial reproduce case, it seems almost silly that this hasn't come
up during testing...
Is it really going to be Nov 30, or Nov 23?
On Thu, Nov 9, 2017 at 2:36 PM, Sara Golemon wrote:
> The sixth (and likely final) release candidate for 7.2.0 was just
> released and can be
> downloaded from:
> https://downloads.php.net/~pollita/
> Or using the git tag: php-7.2.0RC6
>
> The Windows b
Hi all,
The standalone sodium extension has been changed a few days ago to require
libsodium 1.0.9:
https://github.com/jedisct1/libsodium-php/commit/e4d6d281cf197deb0086b592a72f282905ba7ead
Will this version requirement also be ported to the PHP-7.2 branch?
The reason I'm asking is because the
The changelog is incomplete; stops at iconv.
https://github.com/php/php-src/commit/330a7b62c3558aa987ee80e12f1914347d3a9eee
is also missing from NEWS for 7.1.3
> On 13. Apr 2017, at 18:43, Joe Watkins wrote:
>
> Evening,
>
> The PHP development team announces the immediate availability of PH
Thanks; NEWS entry is missing though!
And it unfortunately *just* missed the 7.0.18 branch cutoff :(
Or can it be merged to PHP-7.0.18, given how problems would be caught in
7.1.4RC1 testing? ;)
> On 28. Mar 2017, at 22:10, Nikita Popov wrote:
>
> On Mon, Mar 27, 2017 at 10:58
Just another poke to surface it, in case this should be merged into the 7.0
branch as well :)
https://bugs.php.net/bug.php?id=74250
> On 19. Mar 2017, at 23:39, David Zuelke wrote:
>
> Thanks for the fixes, Nikita!
>
> Will they be merged to the PHP-7.0 branch as well?
>
On 14 Mar 2017, at 16:39, Nikita Popov wrote:
>
> On Tue, Mar 14, 2017 at 11:29 AM, David Zuelke wrote:
>> Hi all,
>>
>> There appears to be a performance regression in the CFG and DFA based
>> optimization passes of OPcache in PHP 5.6+ when loading huge classe
Hi all,
There appears to be a performance regression in the CFG and DFA based
optimization passes of OPcache in PHP 5.6+ when loading huge classes (such as
those generated by Symfony's routing component) for the first time.
The issue does not occur on PHP 5.5. Tests below are with 5.6.30, 7.0.1
Will there be a renaming of the "libsodium" extension on PECL to "sodium" as
well, and will the two codebases be kept in sync?
Otherwise, libraries cannot, using Composer, express a dependency on
"ext-sodium".
> On 10.02.2017, at 22:04, Scott Arciszewski wrote:
>
> The vote for the Libsodium
> On 17.01.2017, at 15:58, Remi Collet wrote:
>
> Le 17/01/2017 à 15:44, David Zuelke a écrit :
>> Hi all,
>>
>> https://github.com/php/php-src/pull/694 and
>> https://github.com/php/php-src/pull/765 brought support for Apache's
>> "
Hi all,
https://github.com/php/php-src/pull/694 and
https://github.com/php/php-src/pull/765 brought support for Apache's
"SetHandler" based mod_proxy_fcgi-to-FPM interface.
Recently, a change in Apache
(https://github.com/apache/httpd/commit/cab0bfbb2645bb8f689535e5e2834e2dbc23f5a5)
broke thi
Happy new year everyone!
I haven't seen this mentioned here on the list, and figured I'd ask, as it
makes some people's lives a bit easier to know this... :)
What's the schedule/plan for the next point releases for PHP? The last ones
were four weeks ago, but there haven't been the usual RC tags
On 14.12.2016, at 16:15, Dennis Clarke wrote:
>
> On 12/14/2016 06:35 AM, Kalle Sommer Nielsen wrote:
>> Hi
>>
>> On Dec 14, 2016 12:23, "Christoph M. Becker" wrote:
>>>
>>> Hi!
>>>
>>> The end of active support for PHP 5.6 is documented to be on December,
>>> 31th[1]. Does that mean that th
On 13.12.2016, at 11:31, Niklas Keller wrote:
>
> OpenSSL support for 1.0.1 will end this year.
>
> Support for version 1.0.1 will cease on 2016-12-31. No further releases of
>> 1.0.1 will be made after that date. Security fixes only will be applied to
>> 1.0.1 until then.
>> Version 1.0.0 is no
On 22.11.2016, at 19:36, Joe Watkins wrote:
> Evening internals,
>
> I'm excited to announce that PHP 7.1.0 will be GA on December 1st.
>
> It has taken a lot of hard work from a lot of people, so stop whatever you
> are doing and give those people a round of applause.
>
> Cheers
> Joe
Good s
I think it should not. Your pull request fixes a problem in that WSDL.
The WSDL is located at the URL
`https://pg.eet.cz/eet/services/EETServiceSOAP/v3?wsdl`.
It references an XML Schema file at `EETXMLSchema.xsd`, which is a relative
location, so it's looked for relative to the containing docu
On 20.03.2016, at 22:10, David Zuelke wrote:
>
> On 10.03.2016, at 16:56, David Zuelke wrote:
>>
>>> On 08.03.2016, at 16:18, Andrea Faulds wrote:
>>>
>>> Hi,
>>>
>>> David Zuelke wrote:
>>>> Is this intentional? Relate
I think this solution is merely a band-aid for a more profound architectural
weakness of current PHP setups, where a web server call out to the engine (via
embedding or FastCGI) to execute a script, which causes this recurring
initialization overhead in the first place.
The future is (or should
On 21.03.2016, at 23:44, Anatol Belski wrote:
>
> What I'm suggesting to do is using a bit finer comb checking with the real
> life situations. Fe what would be the win for the user, either having to
> enable JIT by hand, or to disable it in a rare case. Currently, as for me,
> the latter seems s
On 21.03.2016, at 19:41, Anatol Belski wrote:
> I've just pushed a fix for this issue, could you please check? A global
> stack space
> Is used in a thread safe manner. I was first setting max to 256K, then
> decreased it
> To 64K for now. My tests on Linux and Windows show your snippet passing,
>
On 21.03.2016, at 19:54, Nikita Popov wrote:
>
> On Mon, Mar 21, 2016 at 7:41 PM, Anatol Belski wrote:
>> The issue I have with more increasing the stack is that - while as we see
>> till today
>> the default stack size of 32K is enough in the common case, the max of it
>> will be
>> reserved. S
> On 20.03.2016, at 22:41, Anatol Belski wrote:
>
> Hi,
>
>> -Original Message-----
>> From: David Zuelke [mailto:d...@heroku.com]
>> Sent: Sunday, March 20, 2016 10:10 PM
>> To: Anatol Belski
>> Cc: Christoph Becker ; Pierre Joye
>> ; P
On 10.03.2016, at 16:56, David Zuelke wrote:
>
>> On 08.03.2016, at 16:18, Andrea Faulds wrote:
>>
>> Hi,
>>
>> David Zuelke wrote:
>>> Is this intentional? Related to opcache's "can only be built shared"
>>> status? But
> On 17.03.2016, at 05:22, David Zuelke wrote:
>
>> On 16.03.2016, at 21:38, Anatol Belski wrote:
>>
>> Hi,
>>
>>> -----Original Message-
>>> From: David Zuelke [mailto:d...@heroku.com]
>>> Sent: Tuesday, March 15, 2016 11:58 PM
On 20.03.2016, at 20:50, Jakub Zelenka wrote:
>
> Hi,
>
> I just wanted to send a quick update about my recent work on openssl ext in
> case someone else wanted to start something similar so we don't have a
> wasted effort on that. :)
>
> 1. Error queueing
>
> I'm more or less done with a patc
> On 16.03.2016, at 21:38, Anatol Belski wrote:
>
> Hi,
>
>> -Original Message-----
>> From: David Zuelke [mailto:d...@heroku.com]
>> Sent: Tuesday, March 15, 2016 11:58 PM
>> To: Anatol Belski
>> Cc: Christoph Becker ; Pierre Joye
>> ; P
I think I've said this before; please call it ext-sodium, not ext-libsodium.
David
> On 15.03.2016, at 18:40, Scott Arciszewski wrote:
>
> Link to RFC: https://wiki.php.net/rfc/libsodium
>
> I'd like to bump the RFC to make Libsodium a core extension, as per
> Ferenc's suggestion on the mcryp
On 15.03.2016, at 21:18, Anatol Belski wrote:
>
> Hi,
>
>> -Original Message-
>> From: David Zuelke [mailto:d...@heroku.com]
>> Sent: Sunday, March 13, 2016 6:09 AM
>> To: Anatol Belski
>> Cc: Christoph Becker ; Pierre Joye
>> ; PHP intern
Just wanted to resurrect this thread... I just got a JIT stack size limit error
(which Composer reports as "unknown error" because it has no logic for the new
constant) while running "composer require somepackage" with PHP 7 and JIT
enabled.
IMO, a pattern modifier would be good so that applica
> On 08.03.2016, at 16:18, Andrea Faulds wrote:
>
> Hi,
>
> David Zuelke wrote:
>> Is this intentional? Related to opcache's "can only be built shared" status?
>> But why would that trigger static builds? Or is it a bug?
>
> While we'
Hi all,
I've been trying to get to the bottom of why even a minimal PHP build (any 5.x
or 7 release, or a fresh e.g. 7.0 branch checkout after buildconf) creates .a
versions of all shared extensions in addition to .so modules.
I've narrowed it down to opcache:
$ ./configure --disable-all
...
c
On 28.02.2016, at 13:24, Tom Sommer wrote:
>
> I'm reading the 7.0.4 NEWS file[1] and I get the policy of just writing the
> bug number and headline, but in a lot of cases the bug report headline says
> nothing about the actual problem, or the actual fix.
>
> For instance:
>
> Fixed bug #7155
On 09.02.2016, at 15:33, Derick Rethans wrote:
>
> On Tue, 9 Feb 2016, Zeev Suraski wrote:
>
>> 1. "Debate the technical issues, and never attack a person's opinion.
>> People will disagree, so be it."
>>
>> I think this sentence is problematic. Not that I'm pro-attacks, but
>> opinions - a
Thanks for the work, Derick. Looks good!
(aaand I just top-replied :p)
> On 09.02.2016, at 13:33, Derick Rethans wrote:
>
> Hello!
>
> Things have quieted down around the Code of Conduct and Contributor
> Guidelines process, but I have not been sitting still. In the last week,
> the followi
On 22.01.2016, at 17:43, Florian Anderiasch wrote:
>
> On 22.01.2016 15:29, Pierre Joye wrote:
>>
>> Freshly adopted:
>>
>> http://rubyonrails.org/conduct/
>> https://golang.org/conduct
>>
>
> Ruby (the language) is discussing the adoption of a Code of Conduct
> right now, and several people
On 19.01.2016, at 02:36, Yasuo Ohgaki wrote:
>
> Hi David,
>
> On Tue, Jan 19, 2016 at 2:31 AM, David Zuelke wrote:
>>
>> I have customers running into this too. I have not yet had time to pick up
>> that patch - AFAICT, it's incomplete (see comments).
>
> On 18.01.2016, at 03:03, Yasuo Ohgaki wrote:
>
> Hi openssl module maintainers,
>
> This bug https://bugs.php.net/bug.php?id=68276 is categorized
> as pgsql bug, but it would be more appropriate if categorized as
> openssl bug.
>
> This bug report includes PR https://github.com/php/php-src/pu
On 14.01.2016, at 13:18, Zeev Suraski wrote:
> The way I see it, we don't need to acknowledge having a problem in order to
> want to improve. I'm sure that resonates with most developers on this list -
> wanting to continuously improve does not mean you're saying that things were
> problemati
On 11.01.2016, at 12:31, Anthony Ferrara wrote:
> Actually, asking for proof and denying are the same thing. If they
> weren't, then why would you be asking for proof unless you believed it
> didn't happen?
They are not the same thing. If you make a claim, then the onus of proof is on
you, and
Can we call that extension "sodium" please without the "lib" prefix?
David
> On 07.01.2016, at 08:26, Scott Arciszewski wrote:
>
> Hi everyone,
>
> I've updated the RFC to make libsodium a core PHP extension in 7.1, to
> include references to the online documentation.
>
> https://wiki.php.ne
On 09.01.2016, at 19:48, Anthony Ferrara wrote:
>
> All,
>
>> I was not hesitant (or, let's maybe call it "intentionally procrastinating")
>> to post on this topic because I felt unsafe on this list or in the general
>> realm of the PHP community; I simply was in no mood to deal with a mob of
(Thank you for this write-up, Brandon. It's good to hear an opinion from
someone who's a bit closer to that "field". I'll ignore netiquette and top-post
because it feels like a good point to pick up from and share my general
thoughts on this)
Personally, I don't disagree with the idea of having
+1 to all the points below; pretty much my concerns and thoughts exactly.
> On 08.01.2016, at 08:30, Zeev Suraski wrote:
>
>> We've seen time and time again that the court of public opinion is a
>> horrific
>> judge for these style issues.
>
> This sentence has me worried in several different w
On 06.01.2016, at 03:58, Kevin Smith wrote:
>
>> You state this like some kind of self-evident truth. Understand that not
>> everybody agrees with you, and scorn is not generally something that wins
>> people round to your argument.
>
> If a code of conduct so broad and invasive that it seeks
On 06.01.2016, at 07:21, Anthony Ferrara wrote:
>
> Stas,
>
> I wanted to avoid citing personal examples for personal reasons. But
> since you refuse to read between the lines, here it goes:
>
> I have received no less than 4 direct threats of violence that were
> directly due to my involvement
On 08.01.2016, at 07:09, Anthony Ferrara wrote:
>
> I think if the current RFC went to vote, it would come very close to
> passing as-is. But as I've said before, I don't think it's anywhere
> near ready to vote on. Larry has started a discussion with the people
> behind Drupal's CoC, and I hope
On 08.01.2016, at 07:47, Anthony Ferrara wrote:
>
> I don't think anything in this thread warrants the term "attack" or
> "harassment". While I strongly don't agree with the tone being used
> nor the tactics being used, I don't think they warrant any sort of CoC
> violation.
But who gets to deci
On 06.01.2016, at 12:31, Rowan Collins wrote:
>
> On 6 January 2016 19:42:29 GMT, Stanislav Malyshev
> wrote:
>> I love it how The Law spends so much text and yet leaves so much
>> unspecified and open to interpretation.
>
> Welcome to Common Law. Defining the details is basically the job of j
Lester, we are software developers. not fortune tellers.
Stop speculating. Gather data. Profile your stuff and look where the
bottlenecks are.
> On 10.12.2015, at 12:16, Lester Caine wrote:
>
> On 10/12/15 11:02, Björn Larsson wrote:
>> Just noticed that Smarty team is working on a 3.1.28 re
Then do a trace with xhprof/xdebug/blackfire and see where the time is spent.
How should we magically know the answers?
> On 09.12.2015, at 20:02, Lester Caine wrote:
>
> On 09/12/15 16:24, Rowan Collins wrote:
>>> So as somebody already said, maybe your code or setup is really busted.
>>
>> R
;>
>> https://wiki.php.net/rfc/php56timeline
>>
>> Thanks to Ferenc Kovacs and David Zuelke for reviewing it for any glaring
>> omissions.
>>
>> Let the discussion continue…
>
> I think you're making the voting too complicated :-) In the case th
>
> https://wiki.php.net/rfc/php56timeline
>
>
>
> Thanks to Ferenc Kovacs and David Zuelke for reviewing it for any glaring
> omissions.
>
>
>
> Let the discussion continue…
>
>
>
> Zeev
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 08.12.2015, at 13:32, Lester Caine wrote:
> Bottom line is that given the real world loading on my sites, the
> differences are probably in the noise of network transit times so not
> impressive at all :(
... or you have a bunch of very slow queries in there that are eating up the
majority o
On 06.12.2015, at 20:38, Anatol Belski wrote:
> From today's perspective, I'd suggest to extend the security only period of
> 5.6.
That would be my suggestion too.
End "full" support in, say, December 2016 (a year after 7.0.0), but then give
it two years of security fixes instead of just one.
On 24.11.2015, at 12:57, Leigh wrote:
> I prefer a over c.
>
> As you said, we can deliver a stable and high quality 7.0.0 today. An RC
> period where you expect no bugs does not sound productive to me.
That is exactly the point of an RC. No show-stoppers means you then roll the RC
out as the
On 23.11.2015, at 22:10, Anatol Belski wrote:
> So in the end, a solution is wanted. I don't think any opinion is allowed to
> be ignored for such a topic. So options
>
> a) release on 26th including all known bug fixes
> b) do RC8, assume there are no bugs, so target 10th for RTM
> c) do RC8,
On 23.11.2015, at 04:02, Rasmus Lerdorf wrote:
>
> On Nov 23, 2015, at 00:48, Adam Harvey wrote:
>>
>> Here's an alternative suggestion: we've previously switched to one
>> week RC cycles late in the piece when trying to get major releases
>> stabilised and we're at the point of only fixing one
Should this be in the UPGRADING notes?
> On 10.11.2015, at 20:45, Nikita Popov wrote:
>
> On Tue, Nov 10, 2015 at 5:48 PM, Philip Hofstetter <
> phofstet...@sensational.ch> wrote:
>
>> Hi,
>>
>> I'm having a cause of slightly ugly code that runs differently from PHP 5.6
>> to PHP 7 and I don'
On 10.11.2015, at 10:26, Lester Caine wrote:
>
> On 10/11/15 00:49, Rasmus Lerdorf wrote:
>>> November 30 is Cyber Monday, where people are either
a) focused on maxing out their credit cards on every possible e-commerce
site, or
b) unable to roll out PHP 7 because their cust
November 30 is Cyber Monday, where people are either
a) focused on maxing out their credit cards on every possible e-commerce site,
or
b) unable to roll out PHP 7 because their customers are busy with a)
At least at Heroku we have a blackout policy around Thanksgiving and Christmas
for platform
On 06.10.2015, at 19:28, Pierre Joye wrote:
> The license cannot be changed without approvals of every contributor
> to date. I very much doubt they will. And to make that point clear for
> me, if they do and come with anything but the PHP license, I can
> already say that I won't accept it.
Fir
On 24.07.2015, at 09:33, Adam Harvey wrote:
>
> On 23 July 2015 at 11:47, Christoph Becker wrote:
>
>> Therefore I tend to prefer a new ini setting (say, pcre.jitstack_limit).
>> That would mean, however, to add yet another ini setting, of which
>> there are already so many.
>
> I'm not a big
Since I'm working on something related... what's the verdict here? :)
> On 20.04.2015, at 20:00, Jakub Zelenka wrote:
>
> Hi,
>
> On Thu, Apr 16, 2015 at 1:21 PM, Pierre Joye wrote:
>
>> On Thu, Apr 16, 2015 at 6:27 PM, François Laupretre
>> wrote:
De : Pierre Joye [mailto:pierre@
But an alpha timeline sounds good ;)
> On 13.05.2015, at 16:32, Pierre Joye wrote:
>
> On May 13, 2015 7:57 PM, "Julien Pauli" wrote:
>>
>> Hello people.
>>
>> Time is going, and summer is coming.
>>
>> I think we must have branched 7.0 until end of May, and have our 2 RMs
>> elected.
>>
>
I feel like this one is different though, because there already was consensus
that the current naming isn't the best, and there was support for Throwable,
while voting on the "original" RFC was still open.
To adhere to the RFC process, the open RFC wasn't changed accordingly, because
voting was
Why not wait with the merge until a consensus emerges regarding Throwable?
> On 09.03.2015, at 05:26, Nikita Popov wrote:
>
> On Mon, Feb 23, 2015 at 7:15 PM, Nikita Popov wrote:
>
>> Hi internals!
>>
>> Voting on the engine exceptions RFC, which proposes to convert existing
>> fatal and rec
+1000 on this; so much better than the BaseException stuff!
> On 27.02.2015, at 15:31, Sebastian Bergmann wrote:
>
> Am 23.02.2015 um 19:15 schrieb Nikita Popov:
>> Voting on the engine exceptions RFC, which proposes to convert existing
>> fatal and recoverable fatal errors into exceptions, has
Hi,
Currently, some directives such as "expose_php" or "allow_url_fopen" can only
be changed on the PHP_INI_SYSTEM level, which in some cases apparently even
means through php.ini only.
Wouldn't it make sense to allow "tightening" of these values in, say, a PERDIR
contexts? So "expose_php" can
On 06.01.2015, at 05:42, Pierre Joye wrote:
> I am not sure about that. Introducing a not easy to catch BC break for
> 0.1% gain on function (or even for the whole app) is not very
> appealing.
>
> However, there is nothing in the documentation actually describing how
> it works and there are cl
This sounds reasonable, because given how the sort is *not* stable, there will
be other cases (totally made up, but let's say ["a", "o", "O"]) where the swap
does *not* happen. Consistency, and thus a stable sort, is better.
But you're saying your patch is "kind of a" stable sorting algo, so is
Well, there are two changes there (not sure why "move zlog_set_level() again
shows up twice in the log"?)
One changes the pm.start_servers calculated default message to a notice (makes
total sense IMO).
The other moves zlog_set_level() so it's called earlier, or else the log level
isn't set ye
On 05.09.2014, at 10:54, Remi Collet wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Le 05/09/2014 15:52, David Zuelke a écrit :
>
>> People should simply use the SetHandler approach instead.
>
> I agree, see https://bugzilla.redhat.com/1136290
>
The fix is not broken. He's describing a different/additional issue. Things
have always been shaky with ProxyPass (that's
https://bugs.php.net/bug.php?id=65641) because it's a bag of hurt. That's the
whole reason Apache now has SetHandler for proxies!
On 08.09.2014, at 22:54, Stas Malyshev wr
The fixes in that ticket were pretty risky as they very late in the game
fiddled with strings. That was brittle should have been fixed earlier during
request processing.
The new patch
(https://bugs.php.net/patch-display.php?bug=65641&patch=Another_fix_for_mod_proxy_fcgi.patch&revision=140992288
I'd like to see https://github.com/php/php-src/pull/694 /
https://github.com/php/php-src/pull/765 in so FPM in 5.4 will work properly
with Apache 2.4.10+'s mod_proxy_fcgi.
David
On 19 Aug 2014, at 01:59, Stas Malyshev wrote:
> Hi!
>
> Moving this out of other topics into its own: according
On 17 Aug 2014, at 22:55, Chris Wright wrote:
> On 17 August 2014 11:49, David Zuelke wrote:
>> That does not make any sense; applications could accept XML, CSV or whatever
>> else just as well.
>>
>> The original proposal is not very useful. $_GET contains p
That does not make any sense; applications could accept XML, CSV or whatever
else just as well.
The original proposal is not very useful. $_GET contains parsed query string
info, $_POST contains parsed HTTP request body information if the media type is
application/x-www-urlencoded or multipart/
On 22 Jul 2014, at 21:10, Stas Malyshev wrote:
> Hi!
>
>> not sure, have you seen https://bugs.php.net/bug.php?id=67606 ?
>
> This is worrying. Looks like the patch is not as safe as we've hoped,
> and causes BC issues for mod_fastcgi, so maybe we should not get it into
> 5.3. Once it stabilize
91 matches
Mail list logo
