php: museum.php.net is broken - change recipe SRC_URI?

php: museum.php.net is broken - change recipe SRC_URI?

[Bryan Evenson]

The official PHP archival version download site, http://museum.php.net, has been down at least since the beginning of October.  This is a problem for daisy and older branches if a build attempts to fetch PHP.  I expect this site will be back up again sometime, but from reading the conversation on the related PHP bug report (https://bugs.php.net/bug.php?id=68130) I do not believe http://museum.php.net can be viewed to be a reliable archive in the future.  I see that dizzy changed the SRC_URI to use http://www.php.net/distributions for the main download.  I did some testing and it appears that PHP versions that are about a year old or less are available from http://www.php.net/distributions.  So we can assume that a year from now the dizzy branch SRC_URI will need to change to something else.

I'd propose changing the SRC_URI to something that will not change over time.  My suggestion would be the PHP distributions Git repository located here: http://git.php.net/?p=web/php-distributions.git;a=summary.  This is the path suggested in the related PHP bug mentioned earlier.  The disadvantage is that the SRC_URI would refer to a file on a specific tag, so the SRC_URI would be specific for each PHP version.

Any further suggestions on how to handle this?  If the SRC_URI does get updated, how many branches back should the change be made?

Regards,
Bryan

Re: php: museum.php.net is broken - change recipe SRC_URI?

[Paul Eggleton]

Hi Bryan,

On Monday 03 November 2014 14:03:42 Bryan Evenson wrote:
> The official PHP archival version download site, http://museum.php.net, has
> been down at least since the beginning of October.  This is a problem for
> daisy and older branches if a build attempts to fetch PHP.  I expect this
> site will be back up again sometime, but from reading the conversation on
> the related PHP bug report (https://bugs.php.net/bug.php?id=68130) I do not
> believe http://museum.php.net can be viewed to be a reliable archive in the
> future.  I see that dizzy changed the SRC_URI to use
> http://www.php.net/distributions for the main download.  I did some testing
> and it appears that PHP versions that are about a year old or less are
> available from http://www.php.net/distributions.  So we can assume that a
> year from now the dizzy branch SRC_URI will need to change to something
> else.
> 
> I'd propose changing the SRC_URI to something that will not change over
> time.  My suggestion would be the PHP distributions Git repository located
> here: http://git.php.net/?p=web/php-distributions.git;a=summary.  This is
> the path suggested in the related PHP bug mentioned earlier.  The
> disadvantage is that the SRC_URI would refer to a file on a specific tag,
> so the SRC_URI would be specific for each PHP version.
> 
> Any further suggestions on how to handle this?  If the SRC_URI does get
> updated, how many branches back should the change be made?

So we do have mirrors that can help with this, unfortunately with the OE
mirror (as opposed to the Yocto Project one), its population is not automatic,
so you have to request that new archives get added. I'm not sure it would
be practical to change this either.

Why php thinks it's a good idea to distribute these tarballs in a single place
in a git repository but not in a simple flat HTTP location is a bit beyond me.
Fetching directly from git in this situation wouldn't be ideal as it'll end up
effectively fetching all of the binaries down when cloning the repo; however
I guess you could download a single file with:

SRC_URI = "http://git.php.net/?p=web/php-distributions.git;a=blob;f=php-${PV}.tar.xz"

Cheers,
Paul


-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: php: museum.php.net is broken - change recipe SRC_URI?

[Bryan Evenson]

Paul,

> -----Original Message-----
> From: Paul Eggleton [mailto:paul.eggleton@linux.intel.com]
> Sent: Monday, November 03, 2014 10:46 AM
> To: Bryan Evenson
> Cc: Martin Jansa; koen@dominion.thruhere.net; openembedded-
> devel@lists.openembedded.org
> Subject: Re: [oe] php: museum.php.net is broken - change recipe SRC_URI?
> 
> Hi Bryan,
> 
> On Monday 03 November 2014 14:03:42 Bryan Evenson wrote:
> > The official PHP archival version download site,
> > http://museum.php.net, has been down at least since the beginning of
> > October.  This is a problem for daisy and older branches if a build
> > attempts to fetch PHP.  I expect this site will be back up again
> > sometime, but from reading the conversation on the related PHP bug
> > report (https://bugs.php.net/bug.php?id=68130) I do not believe
> > http://museum.php.net can be viewed to be a reliable archive in the
> > future.  I see that dizzy changed the SRC_URI to use
> > http://www.php.net/distributions for the main download.  I did some
> > testing and it appears that PHP versions that are about a year old or
> > less are available from http://www.php.net/distributions.  So we can
> > assume that a year from now the dizzy branch SRC_URI will need to change
> to something else.
> >
> > I'd propose changing the SRC_URI to something that will not change
> > over time.  My suggestion would be the PHP distributions Git
> > repository located
> > here: http://git.php.net/?p=web/php-distributions.git;a=summary.  This
> > is the path suggested in the related PHP bug mentioned earlier.  The
> > disadvantage is that the SRC_URI would refer to a file on a specific
> > tag, so the SRC_URI would be specific for each PHP version.
> >
> > Any further suggestions on how to handle this?  If the SRC_URI does
> > get updated, how many branches back should the change be made?
> 
> So we do have mirrors that can help with this, unfortunately with the OE
> mirror (as opposed to the Yocto Project one), its population is not automatic,
> so you have to request that new archives get added. I'm not sure it would be
> practical to change this either.
> 
> Why php thinks it's a good idea to distribute these tarballs in a single place in
> a git repository but not in a simple flat HTTP location is a bit beyond me.
> Fetching directly from git in this situation wouldn't be ideal as it'll end up
> effectively fetching all of the binaries down when cloning the repo; however
> I guess you could download a single file with:
> 
> SRC_URI = "http://git.php.net/?p=web/php-distributions.git;a=blob;f=php-
> ${PV}.tar.xz"

Not exactly.  It looks like the old versions that are no longer supported get deleted from php-distributions.git, so HEAD doesn't have knowledge of all PHP versions.  For example, this link: http://git.php.net/?p=web/php-distributions.git;a=blob;f=php-5.4.22.tar.bz2 as of today will download php-5.4.22.  But this link: http://git.php.net/?p=web/php-distributions.git;a=blob;f=php-5.4.21.tar.bz2 just reports that it cannot find the file.

As far as fetching php-5.4.14 (version used for daisy and older) I think this URL will work: http://git.php.net/?p=web/php-distributions.git;a=blob;f=php-5.4.14.tar.bz2;h=0d950f179d586bb1d0e879e0d4aa3a5140e8d5f5;hb=3dd2f12609fc8a730d7cf341a932f6c7b241f03c.  Ugly, but it works.

Would it make more sense to start cloning the source Git repository at https://git.php.net/repository/php-src.git instead of the tarball?  It would download a lot more data, but at least we should be able to use a single SRC_URI for each minor PHP version.

Regards,
Bryan

Re: php: museum.php.net is broken - change recipe SRC_URI?

[Boszormenyi Zoltan]

2014-11-03 17:08 keltezéssel, Bryan Evenson írta:
> Paul,
>
>> -----Original Message-----
>> From: Paul Eggleton [mailto:paul.eggleton@linux.intel.com]
>> Sent: Monday, November 03, 2014 10:46 AM
>> To: Bryan Evenson
>> Cc: Martin Jansa; koen@dominion.thruhere.net; openembedded-
>> devel@lists.openembedded.org
>> Subject: Re: [oe] php: museum.php.net is broken - change recipe SRC_URI?
>>
>> Hi Bryan,
>>
>> On Monday 03 November 2014 14:03:42 Bryan Evenson wrote:
>>> The official PHP archival version download site,
>>> http://museum.php.net, has been down at least since the beginning of
>>> October.  This is a problem for daisy and older branches if a build
>>> attempts to fetch PHP.  I expect this site will be back up again
>>> sometime, but from reading the conversation on the related PHP bug
>>> report (https://bugs.php.net/bug.php?id=68130) I do not believe
>>> http://museum.php.net can be viewed to be a reliable archive in the
>>> future.  I see that dizzy changed the SRC_URI to use
>>> http://www.php.net/distributions for the main download.  I did some
>>> testing and it appears that PHP versions that are about a year old or
>>> less are available from http://www.php.net/distributions.  So we can
>>> assume that a year from now the dizzy branch SRC_URI will need to change
>> to something else.
>>> I'd propose changing the SRC_URI to something that will not change
>>> over time.  My suggestion would be the PHP distributions Git
>>> repository located
>>> here: http://git.php.net/?p=web/php-distributions.git;a=summary.  This
>>> is the path suggested in the related PHP bug mentioned earlier.  The
>>> disadvantage is that the SRC_URI would refer to a file on a specific
>>> tag, so the SRC_URI would be specific for each PHP version.
>>>
>>> Any further suggestions on how to handle this?  If the SRC_URI does
>>> get updated, how many branches back should the change be made?
>> So we do have mirrors that can help with this, unfortunately with the OE
>> mirror (as opposed to the Yocto Project one), its population is not automatic,
>> so you have to request that new archives get added. I'm not sure it would be
>> practical to change this either.
>>
>> Why php thinks it's a good idea to distribute these tarballs in a single place in
>> a git repository but not in a simple flat HTTP location is a bit beyond me.
>> Fetching directly from git in this situation wouldn't be ideal as it'll end up
>> effectively fetching all of the binaries down when cloning the repo; however
>> I guess you could download a single file with:
>>
>> SRC_URI = "http://git.php.net/?p=web/php-distributions.git;a=blob;f=php-
>> ${PV}.tar.xz"
> Not exactly.  It looks like the old versions that are no longer supported get deleted from php-distributions.git, so HEAD doesn't have knowledge of all PHP versions.  For example, this link: http://git.php.net/?p=web/php-distributions.git;a=blob;f=php-5.4.22.tar.bz2 as of today will download php-5.4.22.  But this link: http://git.php.net/?p=web/php-distributions.git;a=blob;f=php-5.4.21.tar.bz2 just reports that it cannot find the file.
>
> As far as fetching php-5.4.14 (version used for daisy and older) I think this URL will work: http://git.php.net/?p=web/php-distributions.git;a=blob;f=php-5.4.14.tar.bz2;h=0d950f179d586bb1d0e879e0d4aa3a5140e8d5f5;hb=3dd2f12609fc8a730d7cf341a932f6c7b241f03c.  Ugly, but it works.

What's wrong with this?

SRC_URI =
"http://php.net/get/php-${PV}.tar.bz2/from/this/mirror;downloadfilename=php-${PV}.tar.bz2"

>
> Would it make more sense to start cloning the source Git repository at https://git.php.net/repository/php-src.git instead of the tarball?  It would download a lot more data, but at least we should be able to use a single SRC_URI for each minor PHP version.
>
> Regards,
> Bryan
>

Re: php: museum.php.net is broken - change recipe SRC_URI?

[Bryan Evenson]

Zoltan,

> -----Original Message-----
> From: openembedded-devel-bounces@lists.openembedded.org
> [mailto:openembedded-devel-bounces@lists.openembedded.org] On
> Behalf Of Boszormenyi Zoltan
> Sent: Monday, November 03, 2014 1:03 PM
> To: openembedded-devel@lists.openembedded.org; Paul Eggleton
> Cc: koen@dominion.thruhere.net
> Subject: Re: [oe] php: museum.php.net is broken - change recipe SRC_URI?
> 
> 2014-11-03 17:08 keltezéssel, Bryan Evenson írta:
> > Paul,
> >
> >> -----Original Message-----
> >> From: Paul Eggleton [mailto:paul.eggleton@linux.intel.com]
> >> Sent: Monday, November 03, 2014 10:46 AM
> >> To: Bryan Evenson
> >> Cc: Martin Jansa; koen@dominion.thruhere.net; openembedded-
> >> devel@lists.openembedded.org
> >> Subject: Re: [oe] php: museum.php.net is broken - change recipe
> SRC_URI?
> >>
> >> Hi Bryan,
> >>
> >> On Monday 03 November 2014 14:03:42 Bryan Evenson wrote:
> >>> The official PHP archival version download site,
> >>> http://museum.php.net, has been down at least since the beginning of
> >>> October.  This is a problem for daisy and older branches if a build
> >>> attempts to fetch PHP.  I expect this site will be back up again
> >>> sometime, but from reading the conversation on the related PHP bug
> >>> report (https://bugs.php.net/bug.php?id=68130) I do not believe
> >>> http://museum.php.net can be viewed to be a reliable archive in the
> >>> future.  I see that dizzy changed the SRC_URI to use
> >>> http://www.php.net/distributions for the main download.  I did some
> >>> testing and it appears that PHP versions that are about a year old
> >>> or less are available from http://www.php.net/distributions.  So we
> >>> can assume that a year from now the dizzy branch SRC_URI will need
> >>> to change
> >> to something else.
> >>> I'd propose changing the SRC_URI to something that will not change
> >>> over time.  My suggestion would be the PHP distributions Git
> >>> repository located
> >>> here: http://git.php.net/?p=web/php-distributions.git;a=summary.
> >>> This is the path suggested in the related PHP bug mentioned earlier.
> >>> The disadvantage is that the SRC_URI would refer to a file on a
> >>> specific tag, so the SRC_URI would be specific for each PHP version.
> >>>
> >>> Any further suggestions on how to handle this?  If the SRC_URI does
> >>> get updated, how many branches back should the change be made?
> >> So we do have mirrors that can help with this, unfortunately with the
> >> OE mirror (as opposed to the Yocto Project one), its population is
> >> not automatic, so you have to request that new archives get added.
> >> I'm not sure it would be practical to change this either.
> >>
> >> Why php thinks it's a good idea to distribute these tarballs in a
> >> single place in a git repository but not in a simple flat HTTP location is a bit
> beyond me.
> >> Fetching directly from git in this situation wouldn't be ideal as
> >> it'll end up effectively fetching all of the binaries down when
> >> cloning the repo; however I guess you could download a single file with:
> >>
> >> SRC_URI =
> >> "http://git.php.net/?p=web/php-distributions.git;a=blob;f=php-
> >> ${PV}.tar.xz"
> > Not exactly.  It looks like the old versions that are no longer supported get
> deleted from php-distributions.git, so HEAD doesn't have knowledge of all
> PHP versions.  For example, this link: http://git.php.net/?p=web/php-
> distributions.git;a=blob;f=php-5.4.22.tar.bz2 as of today will download php-
> 5.4.22.  But this link: http://git.php.net/?p=web/php-
> distributions.git;a=blob;f=php-5.4.21.tar.bz2 just reports that it cannot find
> the file.
> >
> > As far as fetching php-5.4.14 (version used for daisy and older) I think this
> URL will work: http://git.php.net/?p=web/php-
> distributions.git;a=blob;f=php-
> 5.4.14.tar.bz2;h=0d950f179d586bb1d0e879e0d4aa3a5140e8d5f5;hb=3dd2f12
> 609fc8a730d7cf341a932f6c7b241f03c.  Ugly, but it works.
> 
> What's wrong with this?
> 
> SRC_URI =
> "http://php.net/get/php-
> ${PV}.tar.bz2/from/this/mirror;downloadfilename=php-${PV}.tar.bz2"

First, I can't get this SRC_URI to work with the "downloadfilename" addition to the SRC_URI.  I can get php-5.4.33 from http://php.net/get/php-5.4.33.tar.bz2/from/this/mirror.  However, this location has the same problem as the SRC_URI on the dizzy branch; PHP versions that are older than a year are no longer available on the php.net mirrors.  Not a problem (yet) for dizzy or master branches as these branches are using a more recent version of PHP.  For daisy and older branches that are using 5.4.14, this SRC_URI does not work.

Regards,
Bryan 

Re: php: museum.php.net is broken - change recipe SRC_URI?

[Bryan Evenson]

All,

There hasn't been any follow-up on this thread for a couple days.  I'd like to know if there would be an acceptable solution for this issue.  I'd propose changing the SRC_URI for php-5.4.14 to http://git.php.net/?p=web/php-distributions.git;a=blob;f=php-5.4.14.tar.bz2;h=0d950f179d586bb1d0e879e0d4aa3a5140e8d5f5;hb=3dd2f12609fc8a730d7cf341a932f6c7b241f03c, which will directly pull only the tarball we need directly from the PHP Git repository.  I believe it's the only path that would be guaranteed to work long term.

If this change would be acceptable, I can submit a patch that would be for daisy, dora and dylan.

Regards,
Bryan 

> -----Original Message-----
> From: openembedded-devel-bounces@lists.openembedded.org
> [mailto:openembedded-devel-bounces@lists.openembedded.org] On
> Behalf Of Bryan Evenson
> Sent: Monday, November 03, 2014 1:41 PM
> To: openembedded-devel@lists.openembedded.org; Paul Eggleton
> Cc: koen@dominion.thruhere.net
> Subject: Re: [oe] php: museum.php.net is broken - change recipe SRC_URI?
> 
> Zoltan,
> 
> > -----Original Message-----
> > From: openembedded-devel-bounces@lists.openembedded.org
> > [mailto:openembedded-devel-bounces@lists.openembedded.org] On
> Behalf
> > Of Boszormenyi Zoltan
> > Sent: Monday, November 03, 2014 1:03 PM
> > To: openembedded-devel@lists.openembedded.org; Paul Eggleton
> > Cc: koen@dominion.thruhere.net
> > Subject: Re: [oe] php: museum.php.net is broken - change recipe
> SRC_URI?
> >
> > 2014-11-03 17:08 keltezéssel, Bryan Evenson írta:
> > > Paul,
> > >
> > >> -----Original Message-----
> > >> From: Paul Eggleton [mailto:paul.eggleton@linux.intel.com]
> > >> Sent: Monday, November 03, 2014 10:46 AM
> > >> To: Bryan Evenson
> > >> Cc: Martin Jansa; koen@dominion.thruhere.net; openembedded-
> > >> devel@lists.openembedded.org
> > >> Subject: Re: [oe] php: museum.php.net is broken - change recipe
> > SRC_URI?
> > >>
> > >> Hi Bryan,
> > >>
> > >> On Monday 03 November 2014 14:03:42 Bryan Evenson wrote:
> > >>> The official PHP archival version download site,
> > >>> http://museum.php.net, has been down at least since the beginning
> > >>> of October.  This is a problem for daisy and older branches if a
> > >>> build attempts to fetch PHP.  I expect this site will be back up
> > >>> again sometime, but from reading the conversation on the related
> > >>> PHP bug report (https://bugs.php.net/bug.php?id=68130) I do not
> > >>> believe http://museum.php.net can be viewed to be a reliable
> > >>> archive in the future.  I see that dizzy changed the SRC_URI to
> > >>> use http://www.php.net/distributions for the main download.  I did
> > >>> some testing and it appears that PHP versions that are about a
> > >>> year old or less are available from
> > >>> http://www.php.net/distributions.  So we can assume that a year
> > >>> from now the dizzy branch SRC_URI will need to change
> > >> to something else.
> > >>> I'd propose changing the SRC_URI to something that will not change
> > >>> over time.  My suggestion would be the PHP distributions Git
> > >>> repository located
> > >>> here: http://git.php.net/?p=web/php-distributions.git;a=summary.
> > >>> This is the path suggested in the related PHP bug mentioned earlier.
> > >>> The disadvantage is that the SRC_URI would refer to a file on a
> > >>> specific tag, so the SRC_URI would be specific for each PHP version.
> > >>>
> > >>> Any further suggestions on how to handle this?  If the SRC_URI
> > >>> does get updated, how many branches back should the change be
> made?
> > >> So we do have mirrors that can help with this, unfortunately with
> > >> the OE mirror (as opposed to the Yocto Project one), its population
> > >> is not automatic, so you have to request that new archives get added.
> > >> I'm not sure it would be practical to change this either.
> > >>
> > >> Why php thinks it's a good idea to distribute these tarballs in a
> > >> single place in a git repository but not in a simple flat HTTP
> > >> location is a bit
> > beyond me.
> > >> Fetching directly from git in this situation wouldn't be ideal as
> > >> it'll end up effectively fetching all of the binaries down when
> > >> cloning the repo; however I guess you could download a single file with:
> > >>
> > >> SRC_URI =
> > >> "http://git.php.net/?p=web/php-distributions.git;a=blob;f=php-
> > >> ${PV}.tar.xz"
> > > Not exactly.  It looks like the old versions that are no longer
> > > supported get
> > deleted from php-distributions.git, so HEAD doesn't have knowledge of
> > all PHP versions.  For example, this link:
> > http://git.php.net/?p=web/php-
> > distributions.git;a=blob;f=php-5.4.22.tar.bz2 as of today will
> > download php- 5.4.22.  But this link: http://git.php.net/?p=web/php-
> > distributions.git;a=blob;f=php-5.4.21.tar.bz2 just reports that it
> > cannot find the file.
> > >
> > > As far as fetching php-5.4.14 (version used for daisy and older) I
> > > think this
> > URL will work: http://git.php.net/?p=web/php-
> > distributions.git;a=blob;f=php-
> >
> 5.4.14.tar.bz2;h=0d950f179d586bb1d0e879e0d4aa3a5140e8d5f5;hb=3dd2f12
> > 609fc8a730d7cf341a932f6c7b241f03c.  Ugly, but it works.
> >
> > What's wrong with this?
> >
> > SRC_URI =
> > "http://php.net/get/php-
> > ${PV}.tar.bz2/from/this/mirror;downloadfilename=php-${PV}.tar.bz2"
> 
> First, I can't get this SRC_URI to work with the "downloadfilename" addition
> to the SRC_URI.  I can get php-5.4.33 from http://php.net/get/php-
> 5.4.33.tar.bz2/from/this/mirror.  However, this location has the same
> problem as the SRC_URI on the dizzy branch; PHP versions that are older
> than a year are no longer available on the php.net mirrors.  Not a problem
> (yet) for dizzy or master branches as these branches are using a more recent
> version of PHP.  For daisy and older branches that are using 5.4.14, this
> SRC_URI does not work.
> 
> Regards,
> Bryan
> --
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: php: museum.php.net is broken - change recipe SRC_URI?

[Paul Eggleton]

On Wednesday 05 November 2014 13:20:48 Bryan Evenson wrote:
> There hasn't been any follow-up on this thread for a couple days.  I'd like
> to know if there would be an acceptable solution for this issue.  I'd
> propose changing the SRC_URI for php-5.4.14 to
> http://git.php.net/?p=web/php-distributions.git;a=blob;f=php-5.4.14.tar.bz2
> ;h=0d950f179d586bb1d0e879e0d4aa3a5140e8d5f5;hb=3dd2f12609fc8a730d7cf341a932f
> 6c7b241f03c, which will directly pull only the tarball we need directly from
> the PHP Git repository.  I believe it's the only path that would be
> guaranteed to work long term.

Presumably if we did that we will need to keep updating the hash as well 
though?

Looking at the bug there are at least two mirrors mentioned, although those 
may not be reliable on a permanent basis there should be others (e.g. distros 
often provide copies of the upstream sources they use). We could leave the 
museum.php.net URL in place since it does appear it will eventually return, 
and add MIRRORS values to cover the situation while it's unavailable.

Does this sound like a workable plan?

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: php: museum.php.net is broken - change recipe SRC_URI?

[Martin Jansa]

[-- Attachment #1: Type: text/plain, Size: 1580 bytes --]

On Wed, Nov 05, 2014 at 01:32:08PM +0000, Paul Eggleton wrote:
> On Wednesday 05 November 2014 13:20:48 Bryan Evenson wrote:
> > There hasn't been any follow-up on this thread for a couple days.  I'd like
> > to know if there would be an acceptable solution for this issue.  I'd
> > propose changing the SRC_URI for php-5.4.14 to
> > http://git.php.net/?p=web/php-distributions.git;a=blob;f=php-5.4.14.tar.bz2
> > ;h=0d950f179d586bb1d0e879e0d4aa3a5140e8d5f5;hb=3dd2f12609fc8a730d7cf341a932f
> > 6c7b241f03c, which will directly pull only the tarball we need directly from
> > the PHP Git repository.  I believe it's the only path that would be
> > guaranteed to work long term.
> 
> Presumably if we did that we will need to keep updating the hash as well 
> though?
> 
> Looking at the bug there are at least two mirrors mentioned, although those 
> may not be reliable on a permanent basis there should be others (e.g. distros 
> often provide copies of the upstream sources they use). We could leave the 
> museum.php.net URL in place since it does appear it will eventually return, 
> and add MIRRORS values to cover the situation while it's unavailable.
> 
> Does this sound like a workable plan?

We can also send the archive to Tom King to put in in
http://sources.openembedded.org/
(like
http://lists.openembedded.org/pipermail/openembedded-devel/2014-June/096444.html)

We're not changing php version so often, so keeping the tarball there
won't cause so big maintenance burden.

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 188 bytes --]