In trunk we have added About section in Settings. Because we have already some plugins on AGPL license we need a place in the UI to provide links to their source code.
All plugin authors are encouraged to create/update packag.xml files.
There's still one issue. How to define URL of plagin source. There's <srcuri> tag which I think we should use. However, I have problems with validation according to defined XSD for this file. Any hints? Till?
On Mon, Nov 28, 2011 at 11:42, A.L.E.C alec@alec.pl wrote:
In trunk we have added About section in Settings. Because we have already some plugins on AGPL license we need a place in the UI to provide links to their source code.
All plugin authors are encouraged to create/update packag.xml files.
There's still one issue. How to define URL of plagin source. There's <srcuri> tag which I think we should use. However, I have problems with validation according to defined XSD for this file. Any hints? Till?
The package.xml validates when adding <srcuri></srcuri> right before
<phprelease/> Your failing validation could be some validation error in the XSD (package-2.0.xsd) itself which my validator (Oxygen) complains about.
~Thomas _______________________________________________ List info: http://lists.roundcube.net/dev/ BT/aba52c80
On 28.11.2011 20:38, Thomas Bruederli wrote:
The package.xml validates when adding <srcuri></srcuri> right before
<phprelease/> Your failing validation could be some validation error in the XSD (package-2.0.xsd) itself which my validator (Oxygen) complains about.
I'm using pear package-validate command, maybe it's using some more logic than just xsd validation. Now the error is:
Error: <phprelease> packages cannot specify a source code package, only extension binaries may use the <srcpackage> tag
On Tue, Nov 29, 2011 at 11:15 AM, A.L.E.C alec@alec.pl wrote:
On 28.11.2011 20:38, Thomas Bruederli wrote:
The package.xml validates when adding <srcuri></srcuri> right before
<phprelease/> Your failing validation could be some validation error in the XSD (package-2.0.xsd) itself which my validator (Oxygen) complains about.
I'm using pear package-validate command, maybe it's using some more logic than just xsd validation. Now the error is:
Error: <phprelease> packages cannot specify a source code package, only extension binaries may use the <srcpackage> tag
Do you have an example I could look at?
List info: http://lists.roundcube.net/dev/ BT/aba52c80
On 30.11.2011 00:22, till wrote:
Error: <phprelease> packages cannot specify a source code package, only extension binaries may use the <srcpackage> tagDo you have an example I could look at?
Just get package.xml file from any of our plugins and try to add <srcuri> tag.
On Tue, Nov 29, 2011 at 11:15, A.L.E.C alec@alec.pl wrote:
On 28.11.2011 20:38, Thomas Bruederli wrote:
The package.xml validates when adding <srcuri></srcuri> right before
<phprelease/> Your failing validation could be some validation error in the XSD (package-2.0.xsd) itself which my validator (Oxygen) complains about.
I'm using pear package-validate command, maybe it's using some more logic than just xsd validation. Now the error is:
Error: <phprelease> packages cannot specify a source code package, only extension binaries may use the <srcpackage> tag
Well, that seems to be an internal pear validation which actually contradicts the XSD. The schema requires the <phprelease> tag to be alway present and allows an optional <srcuri>.
~Thomas _______________________________________________ List info: http://lists.roundcube.net/dev/ BT/aba52c80
On Thu, Dec 1, 2011 at 10:34 AM, Thomas Bruederli thomas@roundcube.netwrote:
On Tue, Nov 29, 2011 at 11:15, A.L.E.C alec@alec.pl wrote:
On 28.11.2011 20:38, Thomas Bruederli wrote:
The package.xml validates when adding <srcuri></srcuri> right before
<phprelease/> Your failing validation could be some validation error in the XSD (package-2.0.xsd) itself which my validator (Oxygen) complains about.
I'm using pear package-validate command, maybe it's using some more logic than just xsd validation. Now the error is:
Error: <phprelease> packages cannot specify a source code package, only extension binaries may use the <srcpackage> tag
Well, that seems to be an internal pear validation which actually contradicts the XSD. The schema requires the <phprelease> tag to be alway present and allows an optional <srcuri>.
~Thomas
Never saw srcuri with PEAR packages: http://pear.php.net/manual/en/guide.developers.package2.pecl.php
It looks like it's pecl related. What are you trying to achieve with it?
Till
List info: http://lists.roundcube.net/dev/ BT/aba52c80
W dniu 02.12.2011 18:05, till wrote:
Never saw srcuri with PEAR packages: http://pear.php.net/manual/en/guide.developers.package2.pecl.php
It looks like it's pecl related. What are you trying to achieve with it?
As stated in my first post in this thread, for AGPL plugins we need to provide a link to source code. So, we need some URL field in package.xml.
On Fri, Dec 2, 2011 at 6:32 PM, A.L.E.C alec@alec.pl wrote:
W dniu 02.12.2011 18:05, till wrote:
Never saw srcuri with PEAR packages: http://pear.php.net/manual/en/guide.developers.package2.pecl.php
It looks like it's pecl related. What are you trying to achieve with it?
As stated in my first post in this thread, for AGPL plugins we need to provide a link to source code.
Reminds me to vote against the AGPL move.
So, we need some URL field in package.xml.
Maybe I don't get it – but a pear package does not compile code. It's zipped up code in tar archive, compressed with gzip. The source is available. Can you explain why this link is necessary or who claims that it's necessary?
Till
List info: http://lists.roundcube.net/dev/ BT/aba52c80
On 03.12.2011, at 20:51, till wrote:
On Fri, Dec 2, 2011 at 6:32 PM, A.L.E.C alec@alec.pl wrote: W dniu 02.12.2011 18:05, till wrote:
Never saw srcuri with PEAR packages: http://pear.php.net/manual/en/guide.developers.package2.pecl.php
It looks like it's pecl related. What are you trying to achieve with it?
As stated in my first post in this thread, for AGPL plugins we need to provide a link to source code.
Reminds me to vote against the AGPL move.
The AGPL suggestion for Roundcube core has actually nothing to do with the requirement of making the source code of plugins available which are published under AGPL-
So, we need some URL field in package.xml.
Maybe I don't get it – but a pear package does not compile code. It's zipped up code in tar archive, compressed with gzip. The source is available. Can you explain why this link is necessary or who claims that it's necessary?
If you install a plugin which in licensed under AGPL you have to provide the source to the users of that system. That's required by the AGPL itself.
We (Roundcube) want to take the burden of collecting the links to all the AGPL sources away from the sysadmins which install Roundcube with AGPL plugins but collect them all in a single place. That's why we want the URL to the source of an AGPL plugin to be stated in the package itself. Of course we could also add some script which collects all the files directly from the Roundcube installation directory but this brings in some security topics which I'd like to avoid.
~Thomas
List info: http://lists.roundcube.net/dev/ BT/aba52c80
On Mon, Dec 5, 2011 at 5:58 PM, Thomas Bruederli roundcube@gmail.comwrote:
On 03.12.2011, at 20:51, till wrote:
On Fri, Dec 2, 2011 at 6:32 PM, A.L.E.C alec@alec.pl wrote: W dniu 02.12.2011 18:05, till wrote:
Never saw srcuri with PEAR packages: http://pear.php.net/manual/en/guide.developers.package2.pecl.php
It looks like it's pecl related. What are you trying to achieve with
it?
As stated in my first post in this thread, for AGPL plugins we need to provide a link to source code.
Reminds me to vote against the AGPL move.
The AGPL suggestion for Roundcube core has actually nothing to do with the requirement of making the source code of plugins available which are published under AGPL-
So, we need some URL field in package.xml.
Maybe I don't get it – but a pear package does not compile code. It's
zipped up code in tar archive, compressed with gzip. The source is available. Can you explain why this link is necessary or who claims that it's necessary?
If you install a plugin which in licensed under AGPL you have to provide the source to the users of that system. That's required by the AGPL itself.
We (Roundcube) want to take the burden of collecting the links to all the AGPL sources away from the sysadmins which install Roundcube with AGPL plugins but collect them all in a single place. That's why we want the URL to the source of an AGPL plugin to be stated in the package itself. Of course we could also add some script which collects all the files directly from the Roundcube installation directory but this brings in some security topics which I'd like to avoid.
Ok, so just to be clear – you want something like a link to e.g. our RoundCube svn repo, or a github repo, or sf, etc. where the source of the package is located?
If so, I think there are two option:
- Create a README and/or LICENSE file which contains the information and
install them with the 'doc' role. 2) Add the link to the package's <description>
Till
List info: http://lists.roundcube.net/dev/ BT/aba52c80
On Mon, Dec 5, 2011 at 19:01, till till@php.net wrote:
On Mon, Dec 5, 2011 at 5:58 PM, Thomas Bruederli roundcube@gmail.com wrote:
On 03.12.2011, at 20:51, till wrote:
On Fri, Dec 2, 2011 at 6:32 PM, A.L.E.C alec@alec.pl wrote: W dniu 02.12.2011 18:05, till wrote:
Never saw srcuri with PEAR packages: http://pear.php.net/manual/en/guide.developers.package2.pecl.php
It looks like it's pecl related. What are you trying to achieve with it?
As stated in my first post in this thread, for AGPL plugins we need to provide a link to source code.
Reminds me to vote against the AGPL move.
The AGPL suggestion for Roundcube core has actually nothing to do with the requirement of making the source code of plugins available which are published under AGPL-
So, we need some URL field in package.xml.
Maybe I don't get it – but a pear package does not compile code. It's zipped up code in tar archive, compressed with gzip. The source is available. Can you explain why this link is necessary or who claims that it's necessary?
If you install a plugin which in licensed under AGPL you have to provide the source to the users of that system. That's required by the AGPL itself.
We (Roundcube) want to take the burden of collecting the links to all the AGPL sources away from the sysadmins which install Roundcube with AGPL plugins but collect them all in a single place. That's why we want the URL to the source of an AGPL plugin to be stated in the package itself. Of course we could also add some script which collects all the files directly from the Roundcube installation directory but this brings in some security topics which I'd like to avoid.
Ok, so just to be clear – you want something like a link to e.g. our RoundCube svn repo, or a github repo, or sf, etc. where the source of the package is located?
Exactly.
If so, I think there are two option:
- Create a README and/or LICENSE file which contains the information and
install them with the 'doc' role. 2) Add the link to the package's <description>
That's the obvious approach but it isn't necessarily machine readable. Roundcube (trunk) lists all activated plugins in an "about" page and we want to show a download link to every AGPL plugin listed there. So what we're looking for is a tag in the xml schema where one can store that url and the <srcuri> seems to be exactly what we need. But what's that <srcuri> actually meant for and why is the package validator complaining if one uses it?
And after all, I actually give a shit about the pear package validator because we're not using pear to maintain and distribute our plugins anyway.
~Thomas _______________________________________________ List info: http://lists.roundcube.net/dev/ BT/aba52c80
On Tue, Dec 6, 2011 at 9:35 AM, Thomas Bruederli roundcube@gmail.comwrote:
On Mon, Dec 5, 2011 at 19:01, till till@php.net wrote:
On Mon, Dec 5, 2011 at 5:58 PM, Thomas Bruederli roundcube@gmail.com wrote:
On 03.12.2011, at 20:51, till wrote:
On Fri, Dec 2, 2011 at 6:32 PM, A.L.E.C alec@alec.pl wrote: W dniu 02.12.2011 18:05, till wrote:
Never saw srcuri with PEAR packages: http://pear.php.net/manual/en/guide.developers.package2.pecl.php
It looks like it's pecl related. What are you trying to achieve with it?
As stated in my first post in this thread, for AGPL plugins we need to provide a link to source code.
Reminds me to vote against the AGPL move.
The AGPL suggestion for Roundcube core has actually nothing to do with
the
requirement of making the source code of plugins available which are published under AGPL-
So, we need some URL field in package.xml.
Maybe I don't get it – but a pear package does not compile code. It's zipped up code in tar archive, compressed with gzip. The source is available. Can you explain why this link is necessary or who claims
that
it's necessary?
If you install a plugin which in licensed under AGPL you have to provide the source to the users of that system. That's required by the AGPL
itself.
We (Roundcube) want to take the burden of collecting the links to all
the
AGPL sources away from the sysadmins which install Roundcube with AGPL plugins but collect them all in a single place. That's why we want the
URL
to the source of an AGPL plugin to be stated in the package itself. Of course we could also add some script which collects all the files
directly
from the Roundcube installation directory but this brings in some
security
topics which I'd like to avoid.
Ok, so just to be clear – you want something like a link to e.g. our RoundCube svn repo, or a github repo, or sf, etc. where the source of the package is located?
Exactly.
If so, I think there are two option:
- Create a README and/or LICENSE file which contains the information and
install them with the 'doc' role. 2) Add the link to the package's <description>
That's the obvious approach but it isn't necessarily machine readable. Roundcube (trunk) lists all activated plugins in an "about" page and we want to show a download link to every AGPL plugin listed there. So what we're looking for is a tag in the xml schema where one can store that url and the <srcuri> seems to be exactly what we need. But what's that <srcuri> actually meant for and why is the package validator complaining if one uses it?
And after all, I actually give a shit about the pear package validator because we're not using pear to maintain and distribute our plugins anyway.
We could decide on a file called SOURCE which contains the link to make it more machine-readable.
I think <srcuri> is for pecl packages. pecl packages are c-extensions.
http://pear.php.net/manual/en/guide.developers.package2.pecl.php
Both pecl and pear packages use a package.xml (2.0 currently) to be installed. But they don't always share the same "elements".
Till
~Thomas
List info: http://lists.roundcube.net/dev/ BT/aba52c80
-
A.L.E.C -
Thomas Bruederli -
Thomas Bruederli -
till