* php: museum.php.net is broken - change recipe SRC_URI? @ 2014-11-03 14:03 Bryan Evenson 2014-11-03 15:46 ` Paul Eggleton 0 siblings, 1 reply; 8+ messages in thread From: Bryan Evenson @ 2014-11-03 14:03 UTC (permalink / raw) To: openembedded-devel@lists.openembedded.org, Martin Jansa, koen@dominion.thruhere.net 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: php: museum.php.net is broken - change recipe SRC_URI? 2014-11-03 14:03 php: museum.php.net is broken - change recipe SRC_URI? Bryan Evenson @ 2014-11-03 15:46 ` Paul Eggleton 2014-11-03 16:08 ` Bryan Evenson 0 siblings, 1 reply; 8+ messages in thread From: Paul Eggleton @ 2014-11-03 15:46 UTC (permalink / raw) To: Bryan Evenson; +Cc: koen@dominion.thruhere.net, openembedded-devel 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: php: museum.php.net is broken - change recipe SRC_URI? 2014-11-03 15:46 ` Paul Eggleton @ 2014-11-03 16:08 ` Bryan Evenson 2014-11-03 18:03 ` Boszormenyi Zoltan 0 siblings, 1 reply; 8+ messages in thread From: Bryan Evenson @ 2014-11-03 16:08 UTC (permalink / raw) To: Paul Eggleton Cc: koen@dominion.thruhere.net, openembedded-devel@lists.openembedded.org 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: php: museum.php.net is broken - change recipe SRC_URI? 2014-11-03 16:08 ` Bryan Evenson @ 2014-11-03 18:03 ` Boszormenyi Zoltan 2014-11-03 18:40 ` Bryan Evenson 0 siblings, 1 reply; 8+ messages in thread From: Boszormenyi Zoltan @ 2014-11-03 18:03 UTC (permalink / raw) To: openembedded-devel, Paul Eggleton; +Cc: koen@dominion.thruhere.net 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 > ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: php: museum.php.net is broken - change recipe SRC_URI? 2014-11-03 18:03 ` Boszormenyi Zoltan @ 2014-11-03 18:40 ` Bryan Evenson 2014-11-05 13:20 ` Bryan Evenson 0 siblings, 1 reply; 8+ messages in thread From: Bryan Evenson @ 2014-11-03 18:40 UTC (permalink / raw) To: openembedded-devel@lists.openembedded.org, Paul Eggleton Cc: koen@dominion.thruhere.net 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: php: museum.php.net is broken - change recipe SRC_URI? 2014-11-03 18:40 ` Bryan Evenson @ 2014-11-05 13:20 ` Bryan Evenson 2014-11-05 13:32 ` Paul Eggleton 0 siblings, 1 reply; 8+ messages in thread From: Bryan Evenson @ 2014-11-05 13:20 UTC (permalink / raw) To: openembedded-devel@lists.openembedded.org, Paul Eggleton Cc: koen@dominion.thruhere.net 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: php: museum.php.net is broken - change recipe SRC_URI? 2014-11-05 13:20 ` Bryan Evenson @ 2014-11-05 13:32 ` Paul Eggleton 2014-11-05 14:25 ` Martin Jansa 0 siblings, 1 reply; 8+ messages in thread From: Paul Eggleton @ 2014-11-05 13:32 UTC (permalink / raw) To: Bryan Evenson; +Cc: koen@dominion.thruhere.net, openembedded-devel 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: php: museum.php.net is broken - change recipe SRC_URI? 2014-11-05 13:32 ` Paul Eggleton @ 2014-11-05 14:25 ` Martin Jansa 0 siblings, 0 replies; 8+ messages in thread From: Martin Jansa @ 2014-11-05 14:25 UTC (permalink / raw) To: openembedded-devel; +Cc: koen@dominion.thruhere.net [-- 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 --] ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2014-11-05 14:25 UTC | newest] Thread overview: 8+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2014-11-03 14:03 php: museum.php.net is broken - change recipe SRC_URI? Bryan Evenson 2014-11-03 15:46 ` Paul Eggleton 2014-11-03 16:08 ` Bryan Evenson 2014-11-03 18:03 ` Boszormenyi Zoltan 2014-11-03 18:40 ` Bryan Evenson 2014-11-05 13:20 ` Bryan Evenson 2014-11-05 13:32 ` Paul Eggleton 2014-11-05 14:25 ` Martin Jansa
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.