Nabble - Pecl - Dev

Politics

2008-10-10T05:03:09Z

limiting sfla deni lenat networked gets huskies nerd fflush

--
PECL development discussion Mailing List (http://pecl.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[ANNOUNCEMENT] svn-0.5.0 (beta) Released.

2008-10-09T10:23:45Z

The new PECL package svn-0.5.0 (beta) has been released at http://pecl.php.net/.

Release notes
-------------
- Add svn_lock()/svn_unlock()
- Add svn_config_ensure() for setting up a .svn storage directory
- Disable password storing unless a password is explicitly set
- Allow svn_auth_set_parameter() to unset an option with NULL
- svn_blame() returned -1 for a revision number
- Fix segfault caused by using an already destroyed pool
- Fix segfault when certain data types aren't returned from a commit
- Add check on module load that the APR version matches.
- Fix fatal error when the location of the HOME enviromental variable can't be read

Package Info
-------------
Bindings for the Subversion revision control system, providing a method for manipulating
a working copy or repository with PHP.

Related Links
-------------
Package home: http://pecl.php.net/package/svn
Changelog: http://pecl.php.net/package-changelog.php?package=svn
Download: http://pecl.php.net/get/svn-0.5.0.tgz

Authors
-------------
Alan Knowles <alan@...> (lead)
Wez Furlong <wez@...> (lead)
Scott MacVicar <scottmac@...> (lead)

--
PECL development discussion Mailing List (http://pecl.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Re: APC - User Cache Entries Vanish Upredictably

2008-10-07T05:52:11Z

-----Original Message-----
<snip>

>> Anyone know anything about this type of issue?
>
>Not that I'm aware of this problem at all. Can you give me more
>information on your set-up so that I can try to reproduce the
>issues? My test set up is as follows
>
>Ubuntu 8.04/32 bit + apache2 + (prefork mpm?) + 5.3.6-dev mod_php5.so
>
>which I tested with apc-3.0.19 and 3.1.x branches.
>
>Cheers,
>Gopal
>
>
>
>--
>PECL development discussion Mailing List (http://pecl.php.net/)
>To unsubscribe, visit: http://www.php.net/unsub.php
>

Sure. It is happening most predictably on a pair of production servers as follows:

Ubuntu 8.04 / 64 bit
Apache2 2.2.8; prefork
PHP 5.2.4 (shared) (5.2.4-2ubuntu5.3)
APC 3.0.19 configured as follows:

apc.cache_by_default 1
apc.coredump_unmap 0
apc.enable_cli 0
apc.enabled 1
apc.file_update_protection 2
apc.filters
apc.gc_ttl 3600
apc.include_once_override 0
apc.max_file_size 1M
apc.mmap_file_mask
apc.num_files_hint 1000
apc.report_autofilter 0
apc.rfc1867 0
apc.rfc1867_freq 0
apc.rfc1867_name APC_UPLOAD_PROGRESS
apc.rfc1867_prefix upload_
apc.shm_segments 1
apc.shm_size 30
apc.slam_defense 0
apc.stat 1
apc.stat_ctime 0
apc.ttl 0
apc.user_entries_hint 4096
apc.user_ttl 0
apc.write_lock 1

APC cache currently running at about 50% full; 99+% hit rate. This problem happens when adding keys (under load) to the User Cache following a "Clear User Cache" request. Keys are set to "no timeout" yet are removed almost immediately resulting in the application continuing to repopulate them. This seems to stabilize between 10-15 minutes following the user-cache flush; at which point the entries seem to hang around normally.

Apache error logs show nothing APC related. Interestingly, using apc.php, it shows apc running for significantly less time than apache has been running (apc=2days, apache=30days). I think this may be related to a full cache-flush, however.

If you need more info, let me know. Any suggestions would be appreciated.

--
PECL development discussion Mailing List (http://pecl.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Re: Apache Error accessing Subversion

2008-10-06T18:06:56Z

This doesn't work. The same error is generated - it's still trying to
access root.

svn_auth_set_parameter(): svn error(s) occured\n13 (Permission denied)
Can't open file '/root/.subversion/servers': Permission denied

On 2008-10-05 22:12:30 -0600, cyberlot@... (Richard Thomas) said:

> This isn't a bug but an environment issue.
>
> Do some googling for that error string and you will find a lot on the subject
>
> Basically Apache is started by root and assigned the proper user, When
> svn trys to run it ends up pulling roots enviromental variables
> including HOME which is /root
>
> One solution that I am not sure if it will work in with pecl svn, have
> only used it with the running svn through exec is to set your HOME value
>
> Try setting this using exec('HOME="/home/userx"');
>
>
>
> Andy Czerwonka wrote:
>> I've logged a bug at http://pecl.php.net/bugs/bug.php?id=14749
>>
>> On 2008-10-05 19:22:42 -0600, czerwonka@... (Andy Czerwonka) said:
>>
>>> I've got a PHP script being executed by Apache (www user) :
>>>
>>> <?php
>>> echo 'SVN Client is ' . svn_client_version();
>>> svn_auth_set_parameter(SVN_AUTH_PARAM_DEFAULT_USERNAME,
>>> "aczerwon");
>>> ?>
>>>
>>> I'm getting an error on the second line (first on reports 1.4.0
>>> correctly) saying:
>>>
>>> svn_auth_set_parameter(): svn error(s) occured\n13 (Permission denied)
>>> Can't open file '/root/.subversion/servers': Permission denied
>>>
>>> All other commands, svn_log() etc., generate the exact same error.
>>> This has got to be a common use case for the subversion extension. Can
>>> anyone point to what I'm doing wrong?
>>>
>>>
>>> openSUSE 10.2
>>> Apache 2
>>> Subversion 2.4
>>>
>>>
>>> -andy

--
PECL development discussion Mailing List (http://pecl.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: APC - User Cache Entries Vanish Upredictably

2008-10-06T08:47:36Z

Robert Rothe wrote:

> This same thing happens if I use the APC.PHP control panel and flush only the user cache.
>
> IF, however, I flush both the op-code and user caches, then go on to repopulate, the user cache items do not vanish.
>
> Anyone know anything about this type of issue?

Not that I'm aware of this problem at all. Can you give me more
information on your set-up so that I can try to reproduce the
issues? My test set up is as follows

Ubuntu 8.04/32 bit + apache2 + (prefork mpm?) + 5.3.6-dev mod_php5.so

which I tested with apc-3.0.19 and 3.1.x branches.

Cheers,
Gopal

--
PECL development discussion Mailing List (http://pecl.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[ANNOUNCEMENT] timezonedb-2008.7 (stable) Released.

2008-10-06T07:30:36Z

The new PECL package timezonedb-2008.7 (stable) has been released at http://pecl.php.net/.

Release notes
-------------
Updated to version 2008.7 (2008g)

Package Info
-------------
This extension is a drop-in replacement for the builtin timezone database that
comes with PHP. You should only install this extension in case you need to get
a later version of the timezone database than the one that ships with PHP.

The data that this extension uses comes from the "Olson" database, which is
located at ftp://elsie.nci.nih.gov/pub/.

Related Links
-------------
Package home: http://pecl.php.net/package/timezonedb
Changelog: http://pecl.php.net/package-changelog.php?package=timezonedb
Download: http://pecl.php.net/get/timezonedb-2008.7.tgz

Authors
-------------
Derick Rethans (lead)

--
PECL development discussion Mailing List (http://pecl.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Re: Apache Error accessing Subversion

2008-10-05T21:30:12Z

except that the command line version has a good work around for this issue
--config-dir=.....

which can be implemented with svn_config_ensure(config_dir, pool)

I think it's a valid request.
Regards
Alan

Richard Thomas wrote:

> This isn't a bug but an environment issue.
>
> Do some googling for that error string and you will find a lot on the
> subject
>
> Basically Apache is started by root and assigned the proper user, When
> svn trys to run it ends up pulling roots enviromental variables
> including HOME which is /root
>
> One solution that I am not sure if it will work in with pecl svn, have
> only used it with the running svn through exec is to set your HOME value
>
> Try setting this using exec('HOME="/home/userx"');
>
>
>
> Andy Czerwonka wrote:
>> I've logged a bug at http://pecl.php.net/bugs/bug.php?id=14749
>>
>> On 2008-10-05 19:22:42 -0600, czerwonka@... (Andy
>> Czerwonka) said:
>>
>>> I've got a PHP script being executed by Apache (www user) :
>>>
>>> <?php
>>> echo 'SVN Client is ' . svn_client_version();
>>> svn_auth_set_parameter(SVN_AUTH_PARAM_DEFAULT_USERNAME,
>>> "aczerwon");
>>> ?>
>>>
>>> I'm getting an error on the second line (first on reports 1.4.0
>>> correctly) saying:
>>>
>>> svn_auth_set_parameter(): svn error(s) occured\n13 (Permission
>>> denied) Can't open file '/root/.subversion/servers': Permission denied
>>>
>>> All other commands, svn_log() etc., generate the exact same error.
>>> This has got to be a common use case for the subversion extension.
>>> Can anyone point to what I'm doing wrong?
>>>
>>>
>>> openSUSE 10.2
>>> Apache 2
>>> Subversion 2.4
>>>
>>>
>>> -andy
>>
>>
>>
>

--
PECL development discussion Mailing List (http://pecl.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Re: Apache Error accessing Subversion

2008-10-05T21:12:30Z

This isn't a bug but an environment issue.

Do some googling for that error string and you will find a lot on the
subject

Basically Apache is started by root and assigned the proper user, When
svn trys to run it ends up pulling roots enviromental variables
including HOME which is /root

One solution that I am not sure if it will work in with pecl svn, have
only used it with the running svn through exec is to set your HOME value

Try setting this using exec('HOME="/home/userx"');

Andy Czerwonka wrote:

> I've logged a bug at http://pecl.php.net/bugs/bug.php?id=14749
>
> On 2008-10-05 19:22:42 -0600, czerwonka@... (Andy
> Czerwonka) said:
>
>> I've got a PHP script being executed by Apache (www user) :
>>
>> <?php
>> echo 'SVN Client is ' . svn_client_version();
>> svn_auth_set_parameter(SVN_AUTH_PARAM_DEFAULT_USERNAME,
>> "aczerwon");
>> ?>
>>
>> I'm getting an error on the second line (first on reports 1.4.0
>> correctly) saying:
>>
>> svn_auth_set_parameter(): svn error(s) occured\n13 (Permission denied)
>> Can't open file '/root/.subversion/servers': Permission denied
>>
>> All other commands, svn_log() etc., generate the exact same error.
>> This has got to be a common use case for the subversion extension.
>> Can anyone point to what I'm doing wrong?
>>
>>
>> openSUSE 10.2
>> Apache 2
>> Subversion 2.4
>>
>>
>> -andy
>
>
>

--
PECL development discussion Mailing List (http://pecl.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Apache Error accessing Subversion

2008-10-05T20:40:42Z

I've logged a bug at http://pecl.php.net/bugs/bug.php?id=14749

On 2008-10-05 19:22:42 -0600, czerwonka@... (Andy Czerwonka) said:

> I've got a PHP script being executed by Apache (www user) :
>
> <?php
> echo 'SVN Client is ' . svn_client_version();
> svn_auth_set_parameter(SVN_AUTH_PARAM_DEFAULT_USERNAME, "aczerwon");
> ?>
>
> I'm getting an error on the second line (first on reports 1.4.0
> correctly) saying:
>
> svn_auth_set_parameter(): svn error(s) occured\n13 (Permission denied)
> Can't open file '/root/.subversion/servers': Permission denied
>
> All other commands, svn_log() etc., generate the exact same error.
> This has got to be a common use case for the subversion extension. Can
> anyone point to what I'm doing wrong?
>
>
> openSUSE 10.2
> Apache 2
> Subversion 2.4
>
>
> -andy

--
PECL development discussion Mailing List (http://pecl.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Apache Error accessing Subversion

2008-10-05T18:22:42Z

I've got a PHP script being executed by Apache (www user) :

<?php
echo 'SVN Client is ' . svn_client_version();
svn_auth_set_parameter(SVN_AUTH_PARAM_DEFAULT_USERNAME, "aczerwon");
?>

I'm getting an error on the second line (first on reports 1.4.0
correctly) saying:

svn_auth_set_parameter(): svn error(s) occured\n13 (Permission denied)
Can't open file '/root/.subversion/servers': Permission denied

All other commands, svn_log() etc., generate the exact same error.
This has got to be a common use case for the subversion extension. Can
anyone point to what I'm doing wrong?

openSUSE 10.2
Apache 2
Subversion 2.4

-andy

--
PECL development discussion Mailing List (http://pecl.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

APC - User Cache Entries Vanish Upredictably

2008-10-02T12:37:24Z

Running APC 3.0.19, PHP 5.2.4, Ubuntu Server 64 bit 8.04

APC Settings: All Default

APC running fine. Op-code is caching fine. I add a few user cache entries and they appear, and live, normally.

Then, I flush the user cache in code using: apc_clear_cache('user');

The user cache entries disappear, as expected. The application then goes on to repopulate certain user cache items with the same key names (and perpetual life) as those deleted in the previous step. However, these new items randomly vanish from the user cache -- lasting only a minute or two.

This cycle repeats for at least 10 minutes or so... then the subsequently added keys begin to stick.

This same thing happens if I use the APC.PHP control panel and flush only the user cache.

IF, however, I flush both the op-code and user caches, then go on to repopulate, the user cache items do not vanish.

Anyone know anything about this type of issue?

Thanks.

--
PECL development discussion Mailing List (http://pecl.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Adding pecl/http to core

2008-09-30T00:20:59Z

Ralph Schindler wrote:
> Mike,
>
> I have a few questions about the API and target use cases. What is the
> best medium to ask these questions and document them? This thread
> certainly is not the best place im sure of.

I'm moving this to php.pecl.dev then. That should be the right place.

Regards,
Mike

--
PECL development discussion Mailing List (http://pecl.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Account Request

2008-09-26T03:00:54Z

On Fri, 2008-09-26 at 11:50 +0200, Lukas Kahwe Smith wrote:

> On 26.09.2008, at 11:43, Alexander Kahl wrote:
> >>
> >> By the way, we do have a yaml extension already which is used by many
> >> frameworks.
> > I know (php-pecl-)syck well, Alexey Zakhlestin actually encouraged
> > me to
> > use his implementation as an inspiration. Still, I haven't heard of
> > any
> > plans to have syck support YAML 1.1 and libyaml was written for this
> > purpose and does its job really well so IMO it deserves PHP
> > integration.
>
>
> Aside from the legal stuff, for me the C based YAML parsers are not
> useable, because we require full merge-key support [1],

Full merge-key support? Like what?

The only missing feature I could identify for production software is
post-deserialization merging of files loaded dependently from each other
which can be done later in-code by different means.

> which is not
> part of the standard. This actually seems to be a requirement for most
> PHP frameworks I have seen.
Well but non-machine code yaml processors are so fucking slow their
overhead is actually unbearable if you really so heavily on yaml as I
do; and, no, caching is not always the right solution as long as yaml is
used as a data storage layer in between different access layers.

--
alexander kahl _ developer

signature.asc (204 bytes) Download Attachment

Re: Account Request

2008-09-26T02:50:19Z

On 26.09.2008, at 11:43, Alexander Kahl wrote:

>>
>> By the way, we do have a yaml extension already which is used by many
>> frameworks.
> I know (php-pecl-)syck well, Alexey Zakhlestin actually encouraged
> me to
> use his implementation as an inspiration. Still, I haven't heard of
> any
> plans to have syck support YAML 1.1 and libyaml was written for this
> purpose and does its job really well so IMO it deserves PHP
> integration.

Aside from the legal stuff, for me the C based YAML parsers are not
useable, because we require full merge-key support [1], which is not
part of the standard. This actually seems to be a requirement for most
PHP frameworks I have seen.

regards,
Lukas Kahwe Smith
mls@...

[1] http://yaml.org/type/merge.html

--
PECL development discussion Mailing List (http://pecl.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Account Request

2008-09-26T02:43:39Z

Hi,

On Fri, 2008-09-26 at 11:16 +0200, Pierre Joye wrote:

> hi,
>
> On Fri, Sep 26, 2008 at 10:21 AM, Alexander Kahl <akahl@...> wrote:
> > Hi Stanislav!
> >
> > Thank you for providing this clear statement.
> > I'd like both, using a copyleft license and hosting within the PHP
> > community infrastructure, but since they contradict, I have to trade
> > them off against each other.
> > Are there alternatives to pecl without such restrictions? I know a lot
> > of different pear channels but never heard of any other for extensions
> > than pecl..
>
> Not dedicated to PHP Extensions only and not with the visibility we have.

Of course, pecl is the no. 1 address for PHP extensions, who doesn't

know? ;)

> Otherwise, you can use sf.net, savahna, googlecode or any other site
> providing these services. I have to say that I find amazing (in a not
> so positive way) how hard you are making it given that the main tool
> (PHP) you use clearly shows that the PHP/BSD licenses work very well.
They do work in a very different way. Copyleft is actually the reason
the BSD License, PHP, free operating systems etc. exist at all. The idea
of Free Software motivates me to write software at all, not just the fun
of it (of course it's a lot of fun nevertheless).

> By the way, we do have a yaml extension already which is used by many
> frameworks.
I know (php-pecl-)syck well, Alexey Zakhlestin actually encouraged me to
use his implementation as an inspiration. Still, I haven't heard of any
plans to have syck support YAML 1.1 and libyaml was written for this
purpose and does its job really well so IMO it deserves PHP integration.

--
alexander kahl _ developer

signature.asc (204 bytes) Download Attachment

Re: Account Request

2008-09-26T02:16:12Z

hi,

On Fri, Sep 26, 2008 at 10:21 AM, Alexander Kahl <akahl@...> wrote:
> Hi Stanislav!
>
> Thank you for providing this clear statement.
> I'd like both, using a copyleft license and hosting within the PHP
> community infrastructure, but since they contradict, I have to trade
> them off against each other.
> Are there alternatives to pecl without such restrictions? I know a lot
> of different pear channels but never heard of any other for extensions
> than pecl..

Not dedicated to PHP Extensions only and not with the visibility we have.

Otherwise, you can use sf.net, savahna, googlecode or any other site
providing these services. I have to say that I find amazing (in a not
so positive way) how hard you are making it given that the main tool
(PHP) you use clearly shows that the PHP/BSD licenses work very well.

By the way, we do have a yaml extension already which is used by many
frameworks.

Cheers,
--
Pierre

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

--
PECL development discussion Mailing List (http://pecl.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Account Request

2008-09-26T01:21:25Z

Hi Stanislav!

Thank you for providing this clear statement.
I'd like both, using a copyleft license and hosting within the PHP
community infrastructure, but since they contradict, I have to trade
them off against each other.
Are there alternatives to pecl without such restrictions? I know a lot
of different pear channels but never heard of any other for extensions
than pecl..

On Thu, 2008-09-25 at 11:08 -0700, Stanislav Malyshev wrote:

> Hi!
>
> > But it's not copyleft. Anyone can take your code and make something
> > proprietary with it, not contributing back to the community.. see
>
> You see, many people in PHP don't care as much for politics as some
> other people in other projects do. Of course, nobody is going to say you
> how to license your code, but if you want to use PHP community
> infrastructure, you've got to play by the rules set by the community.
>
> That said, of course, nothing is to prevent you from hosting any
> PHP-related code on any other resources.

alexander kahl _ developer

iconmobile GmbH _ methfesselstr. 30-36 _ 10965 berlin _ germany
phone +49 30 886633 212 _ fax +49 30 886633 150 _ mobile +49 178 8279256
akahl@... _ www.iconmobile.com

local court charlottenburg _ hrb 88308
managing directors _ thomas fellger | stefan kirschke

signature.asc (204 bytes) Download Attachment

Re: Account Request

2008-09-25T11:08:14Z

Hi!

> But it's not copyleft. Anyone can take your code and make something
> proprietary with it, not contributing back to the community.. see

You see, many people in PHP don't care as much for politics as some
other people in other projects do. Of course, nobody is going to say you
how to license your code, but if you want to use PHP community
infrastructure, you've got to play by the rules set by the community.

That said, of course, nothing is to prevent you from hosting any
PHP-related code on any other resources.
--
Stanislav Malyshev, Zend Software Architect
stas@... http://www.zend.com/
(408)253-8829 MSN: stas@...

--
PECL development discussion Mailing List (http://pecl.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Account Request

2008-09-25T08:34:45Z

On Thu, Sep 25, 2008 at 5:09 PM, Alexander Kahl <akahl@...> wrote:
> On Thu, 2008-09-25 at 15:35 +0200, Pierre Joye wrote:
>> Now, can we move on please? We have proposes alternatives, choose one
>> and let move back to code :)
>
> Am I allowed to use the LGPLv2 at least now? Or just BSD/PHP?

It makes no sense. The libYAML is under the MIT License (BSDish).

Cheers,
--
Pierre

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

--
PECL development discussion Mailing List (http://pecl.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Account Request

2008-09-25T08:09:28Z

On Thu, 2008-09-25 at 15:35 +0200, Pierre Joye wrote:
> Now, can we move on please? We have proposes alternatives, choose one
> and let move back to code :)

Am I allowed to use the LGPLv2 at least now? Or just BSD/PHP?

--
alexander kahl _ developer

signature.asc (204 bytes) Download Attachment

Re: Account Request

2008-09-25T06:35:18Z

On Thu, Sep 25, 2008 at 3:04 PM, Alexander Kahl <akahl@...> wrote:

> On Thu, 2008-09-25 at 13:39 +0200, Pierre Joye wrote:
>> On Thu, Sep 25, 2008 at 12:42 PM, Alexander Kahl <akahl@...> wrote:
>>
>> >> And not the underlying libraries. A library can be lgpl (2 or 3), BSD,
>> >> MIT or the likes (but not GPL), and the PHP extension can be under the
>> >> PHP or BSD License. There is absolutely no problem in such cases.
>> >
>> > Excuse me if I churn up questions that have been discussed before but
>> > where lies the actual problem of allowing developers which license to
>> > choose for their own code as long as it's compatible with the PHP
>> > License and a Free Software License itself?
>>
>> BSD *IS* Free and *IS* compatible with the FSF Licenses.
> But it's not copyleft. Anyone can take your code and make something
> proprietary with it, not contributing back to the community.. see
> MS-Windows' TCP/IP stack or MacOS (both built on BSD code). MS didn't
> even care to give credit to the original author(s) as the license
> demands.
> Why should I write code for corporates in my free time?

How do you think PHP and PECL has been developed? In our free time and
anyone is Free to use it how and where he likes to. That's true
Freedom (</pollitics>).

Now, can we move on please? We have proposes alternatives, choose one
and let move back to code :)

Cheers,
--
Pierre

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

--
PECL development discussion Mailing List (http://pecl.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Account Request

2008-09-25T06:04:18Z

On Thu, 2008-09-25 at 13:39 +0200, Pierre Joye wrote:

> On Thu, Sep 25, 2008 at 12:42 PM, Alexander Kahl <akahl@...> wrote:
>
> >> And not the underlying libraries. A library can be lgpl (2 or 3), BSD,
> >> MIT or the likes (but not GPL), and the PHP extension can be under the
> >> PHP or BSD License. There is absolutely no problem in such cases.
> >
> > Excuse me if I churn up questions that have been discussed before but
> > where lies the actual problem of allowing developers which license to
> > choose for their own code as long as it's compatible with the PHP
> > License and a Free Software License itself?
>
> BSD *IS* Free and *IS* compatible with the FSF Licenses.

But it's not copyleft. Anyone can take your code and make something

proprietary with it, not contributing back to the community.. see
MS-Windows' TCP/IP stack or MacOS (both built on BSD code). MS didn't
even care to give credit to the original author(s) as the license
demands.
Why should I write code for corporates in my free time?

> > Excluding the question about "free" licenses, where is the freedom for
> > the developer here? Is hijack-able code the price to pay to have it
> > published on pecl?
>
> PHP License is not compatible with the GPL License (all versions) and
> that's why we don't accept any binding using GPL code in PECL (even if
> the extension is under BSD/PHP license).

The GPL was never part of the discussion.. I know the GPL is
incompatible with the PHP License (sadly).
The LGPLvN licenses are both copyleft and allow to link with
GPL-incompatible code, even proprietary one, not affecting it - the
scope of the license ends there. I'm positive that allowing or even
encouraging PHP extension developers to use the LGPL (and other copyleft
licenses) for their code would boost development and community
collaboration a lot.

Regards

--
alexander kahl _ developer

signature.asc (204 bytes) Download Attachment

Re: Account Request

2008-09-25T04:39:26Z

On Thu, Sep 25, 2008 at 12:42 PM, Alexander Kahl <akahl@...> wrote:

>> And not the underlying libraries. A library can be lgpl (2 or 3), BSD,
>> MIT or the likes (but not GPL), and the PHP extension can be under the
>> PHP or BSD License. There is absolutely no problem in such cases.
>
> Excuse me if I churn up questions that have been discussed before but
> where lies the actual problem of allowing developers which license to
> choose for their own code as long as it's compatible with the PHP
> License and a Free Software License itself?

BSD *IS* Free and *IS* compatible with the FSF Licenses.

> Excluding the question about "free" licenses, where is the freedom for
> the developer here? Is hijack-able code the price to pay to have it
> published on pecl?

PHP License is not compatible with the GPL License (all versions) and
that's why we don't accept any binding using GPL code in PECL (even if
the extension is under BSD/PHP license).

Cheers,
--
Pierre

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

--
PECL development discussion Mailing List (http://pecl.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Account Request

2008-09-25T03:54:20Z

On Thu, Sep 25, 2008 at 11:42 AM, Alexander Kahl <akahl@...> wrote:
> Excluding the question about "free" licenses, where is the freedom for
> the developer here? Is hijack-able code the price to pay to have it
> published on pecl?

My personal opinion on the issue is that by unifying the licenses
every developer knows that he can work on the code without consulting
his/her lawyer first. This makes sure that if a maintainer becomes
unactive anyone can carry on the work without worrying about licenses
too deeply.

--
Mikko Koppanen

--
PECL development discussion Mailing List (http://pecl.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Account Request

2008-09-25T03:42:49Z

On Thu, 2008-09-25 at 00:34 +0200, Pierre Joye wrote:

> hi Olivier,
>
> 2008/9/24 Olivier Hill <olivier.hill@...>:
> > Hello Pierre
> >
> > What kind of problems??
> >
> > I don't like LGPL, but sometimes you can't escape it
>
> It could be important to remember what we are talking about: the PHP
> extension, the binding itself.
>
> And not the underlying libraries. A library can be lgpl (2 or 3), BSD,
> MIT or the likes (but not GPL), and the PHP extension can be under the
> PHP or BSD License. There is absolutely no problem in such cases.

Excuse me if I churn up questions that have been discussed before but
where lies the actual problem of allowing developers which license to
choose for their own code as long as it's compatible with the PHP
License and a Free Software License itself?
Excluding the question about "free" licenses, where is the freedom for
the developer here? Is hijack-able code the price to pay to have it
published on pecl?
Although I have to accept your decision I'm unable to understand it. Is
it a question of business-friendliness?

Regards

--
alexander kahl _ developer

signature.asc (204 bytes) Download Attachment

Re: Account Request

2008-09-24T15:34:05Z

hi Olivier,

2008/9/24 Olivier Hill <olivier.hill@...>:
> Hello Pierre
>
> What kind of problems??
>
> I don't like LGPL, but sometimes you can't escape it

It could be important to remember what we are talking about: the PHP
extension, the binding itself.

And not the underlying libraries. A library can be lgpl (2 or 3), BSD,
MIT or the likes (but not GPL), and the PHP extension can be under the
PHP or BSD License. There is absolutely no problem in such cases.

Cheers,
--
Pierre

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

--
PECL development discussion Mailing List (http://pecl.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Account Request

2008-09-24T14:45:45Z

Hello Pierre

What kind of problems??

I don't like LGPL, but sometimes you can't escape it. As far as I'm
concerned the v3 is even less virulent than v2.

Regards,
Olivier

Le 08-09-24 à 07:59, "Pierre Joye" <pierre.php@...> a écrit :

> On Wed, Sep 24, 2008 at 3:51 PM, Lars Strojny <lstrojny@...>
> wrote:
>> Hi Joe, hi Pierre,
>>
>> Am Dienstag, den 23.09.2008, 08:29 -0700 schrieb Joe Stump:
>> [...]
>>> I agree with Pierre. And, to be honest, the most free license on the
>>> planet is public domain (which, unfortunately, isn't legal in all
>>> countries). The community has decided that LGPLv2, New BSD and PHP
>>> licenses are the only acceptable ones we'll accept to PEAR/PECL.
>>
>> To be fair, the decision was made when LGPL v3 wasn't even planned,
>> am I
>> right? So I guess it would be good to start a discussion about LGPL
>> v3
>> and PECL but for now the license thing is fixed.
>
> I was not clear. The decision was made to stick to:
>
> 1. PHP License
> 2. BSD-like
>
> and at the very least if the other two cannot be used:
>
> 3. LGPL v2
>
> 3. does not apply in this case and I already vote -1 on lgplv3 in PECL
> (enough troubles/pains already).
>
> Cheers,
> --
> Pierre
>
> http://blog.thepimp.net | http://www.libgd.org
>
> --
> PECL development discussion Mailing List (http://pecl.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>

--
PECL development discussion Mailing List (http://pecl.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Account Request

2008-09-24T06:59:16Z

On Wed, Sep 24, 2008 at 3:51 PM, Lars Strojny <lstrojny@...> wrote:

> Hi Joe, hi Pierre,
>
> Am Dienstag, den 23.09.2008, 08:29 -0700 schrieb Joe Stump:
> [...]
>> I agree with Pierre. And, to be honest, the most free license on the
>> planet is public domain (which, unfortunately, isn't legal in all
>> countries). The community has decided that LGPLv2, New BSD and PHP
>> licenses are the only acceptable ones we'll accept to PEAR/PECL.
>
> To be fair, the decision was made when LGPL v3 wasn't even planned, am I
> right? So I guess it would be good to start a discussion about LGPL v3
> and PECL but for now the license thing is fixed.

I was not clear. The decision was made to stick to:

1. PHP License
2. BSD-like

and at the very least if the other two cannot be used:

3. LGPL v2

3. does not apply in this case and I already vote -1 on lgplv3 in PECL
(enough troubles/pains already).

Cheers,
--
Pierre

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

--
PECL development discussion Mailing List (http://pecl.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Account Request

2008-09-24T06:51:01Z

Hi Joe, hi Pierre,

Am Dienstag, den 23.09.2008, 08:29 -0700 schrieb Joe Stump:
[...]
> I agree with Pierre. And, to be honest, the most free license on the
> planet is public domain (which, unfortunately, isn't legal in all
> countries). The community has decided that LGPLv2, New BSD and PHP
> licenses are the only acceptable ones we'll accept to PEAR/PECL.

To be fair, the decision was made when LGPL v3 wasn't even planned, am I
right? So I guess it would be good to start a discussion about LGPL v3
and PECL but for now the license thing is fixed.

cu, Lars
--
Jabber: lars@...
Weblog: http://usrportage.de

signature.asc (852 bytes) Download Attachment

[ANNOUNCEMENT] hidef-0.1.1 (alpha) Released.

2008-09-24T04:05:37Z

The new PECL package hidef-0.1.1 (alpha) has been released at http://pecl.php.net/.

Release notes
-------------
- hidef_fetch()/frozenarray data stores

Package Info
-------------
Allow definition of user defined constants in simple ini files,
which are then processed like internal constants, without any
of the usual performance penalties.

Related Links
-------------
Package home: http://pecl.php.net/package/hidef
Changelog: http://pecl.php.net/package-changelog.php?package=hidef
Download: http://pecl.php.net/get/hidef-0.1.1.tgz

Authors
-------------
Gopal Vijayaraghavan (lead)

--
PECL development discussion Mailing List (http://pecl.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Account Request

2008-09-23T08:29:33Z

On Sep 23, 2008, at 5:34 AM, Pierre Joye wrote:

>> Why should the LGPLv3 make a difference here? Both licenses (v2 and
>> v3)
>> express the same exception on their scopes for the binary results
>> after
>> linking to software under a different license.
>> I don't like paper tiger ("liberal") licenses because they don't
>> ensure
>> perpetual protection of the freedom of software users. Either one
>> of the
>> BSD license and PHP license enables entities to republish / reuse
>> code
>> under arbitrary conditions, i.e. non-free software licenses. It's
>> impossible for me to justify that.
>
> I'm not willing to argue about true Freedom here. I will not agree to
> introduce yet another license in pecl. Please choose between PHP,
> (new) BSD or at the very least case, LGPLv2. If you won't any of
> those, then you can always go in any of these OSS hosting sites like
> sourcefourge.

I agree with Pierre. And, to be honest, the most free license on the
planet is public domain (which, unfortunately, isn't legal in all
countries). The community has decided that LGPLv2, New BSD and PHP
licenses are the only acceptable ones we'll accept to PEAR/PECL. If
you don't agree with those terms you can choose between a few options:

1.) Set up your own PECL/PEAR channel and distribute your package that
way under whatever license you choose.
2.) Host it on SF, Google Code, etc.
3.) Submit an RFC to accept different licenses, reasons why that makes
sense, etc. and put it to a vote.

--Joe

--
PECL development discussion Mailing List (http://pecl.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Account Request

2008-09-23T05:34:28Z

hi,

On Tue, Sep 23, 2008 at 10:17 AM, Alexander Kahl <akahl@...> wrote:

>> I would rather go with another license. As lgplv2 is fine (not desired
>> but fine), I really have doubts about the v3. If you like a very
>> liberal license, use the BSD one. But I still one question, what's the
>> problem with the PHP License 3.01?
>
> Why should the LGPLv3 make a difference here? Both licenses (v2 and v3)
> express the same exception on their scopes for the binary results after
> linking to software under a different license.
> I don't like paper tiger ("liberal") licenses because they don't ensure
> perpetual protection of the freedom of software users. Either one of the
> BSD license and PHP license enables entities to republish / reuse code
> under arbitrary conditions, i.e. non-free software licenses. It's
> impossible for me to justify that.

I'm not willing to argue about true Freedom here. I will not agree to
introduce yet another license in pecl. Please choose between PHP,
(new) BSD or at the very least case, LGPLv2. If you won't any of
those, then you can always go in any of these OSS hosting sites like
sourcefourge.

Cheers,
--
Pierre

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

--
PECL development discussion Mailing List (http://pecl.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: CVS Account Request: krimpet

2008-09-23T04:00:12Z

On Fri, Sep 12, 2008 at 12:01 AM, Pierre Joye <pierre.php@...> wrote:

> On Thu, Sep 11, 2008 at 9:46 PM, Fran Rogers <frogers@...> wrote:
>> I am interested in applying for a PECL CVS account to host development in the PECL repository of a new extension I have been working on, "ecmascript", which embeds an ECMAScript interpreter into PHP, allowing PHP code to execute ECMAScript code and access and manipulate the environment it runs in.
>>
>> More information on the features and implementation of the package is in the PECL-DEV mailing list discussion: http://marc.info/?l=pecl-dev&m=122101294107306&w=2
>>
>> Mr. Pierre Joye approved my PECL account request, and instructed me to submit this application as the next step.
>
> You can call me Pierre :-D
>
> and I confirm this request, if any cvs admins read it, please approve :)

any news on this?
Pierre, should we bug someone specific?

--
Alexey Zakhlestin
http://blog.milkfarmsoft.com/

--
PECL development discussion Mailing List (http://pecl.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Account Request

2008-09-23T01:17:23Z

Hi Pierre,

On Mon, 2008-09-22 at 23:51 +0200, Pierre Joye wrote:

> > There is one caveat on this submission however:
> > You're encouraging people to use the PHP License for their extensions. I
> > feel deeply repelled by non-copyleft ("viral") licenses and cannot
> > square publishing non-copyleft code with my conscience. If you don't
> > mind I'd like to use the LGPLv3+ for this submission.
>
> I would rather go with another license. As lgplv2 is fine (not desired
> but fine), I really have doubts about the v3. If you like a very
> liberal license, use the BSD one. But I still one question, what's the
> problem with the PHP License 3.01?

Why should the LGPLv3 make a difference here? Both licenses (v2 and v3)
express the same exception on their scopes for the binary results after
linking to software under a different license.
I don't like paper tiger ("liberal") licenses because they don't ensure
perpetual protection of the freedom of software users. Either one of the
BSD license and PHP license enables entities to republish / reuse code
under arbitrary conditions, i.e. non-free software licenses. It's
impossible for me to justify that.

--
alexander kahl _ developer

iconmobile GmbH _ methfesselstr. 30-36 _ 10965 berlin _ germany
phone +49 30 886633 212 _ fax +49 30 886633 150 _ mobile +49 178 8279256
akahl@... _ www.iconmobile.com

local court charlottenburg _ hrb 88308
managing directors _ thomas fellger | stefan kirschke

signature.asc (204 bytes) Download Attachment

Re: Account Request

2008-09-22T14:51:02Z

hi,

On Mon, Sep 22, 2008 at 10:29 PM, Alexander Kahl <akahl@...> wrote:

> I'd like to submit my first PHP extension to pecl, php-(pecl)-yaml. The
> project is adapted from php_yaml originally written by rsky (Ryusuke
> Sekiyama) who doesn't reply to any patch submissions so I've decided to
> take over and add all missing basic parts.
> The extension acts as a binding between LibYAML[1] and PHP enabling the
> user to process YAML serialized data from and to native PHP data types,
> basically just like you can do with syck/php-pecl-syck but LibYAML
> supports YAML version 1.1.
> Although LibYAML is declared alpha I couldn't find any flaws so far, not
> even in productive usage.
>
> There is one caveat on this submission however:
> You're encouraging people to use the PHP License for their extensions. I
> feel deeply repelled by non-copyleft ("viral") licenses and cannot
> square publishing non-copyleft code with my conscience. If you don't
> mind I'd like to use the LGPLv3+ for this submission.

I would rather go with another license. As lgplv2 is fine (not desired
but fine), I really have doubts about the v3. If you like a very
liberal license, use the BSD one. But I still one question, what's the
problem with the PHP License 3.01?

Cheers,
--
Pierre
http://blog.thepimp.net | http://www.libgd.org

--
PECL development discussion Mailing List (http://pecl.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php