Hi FTP Masters,
Folly is part of HHVM[1] and both used inside Facebook. I wanted a
separate package that HHVM would depend on. With the collate below
with FB developers, I realized it doesn't stand on its own. Please
reject it from the NEW queue.
HHVM will contain the Folly git snapshot that
On 01/05/14 05:44, Jordan DeLong wrote:
On Sat, Jan 04, 2014 at 11:53:25PM +0100, László Böszörményi (GCS) wrote:
Question is, does Folly maintain ABI compatibility? If it changes
from time-to-time, how often?
Yeah, it doesn't attempt to maintain ABI backward compatability, and
we haven't
On Sat, Jan 4, 2014 at 1:51 AM, Paul Tarjan p...@fb.com wrote:
checking whether the Boost::Thread library is available... yes
configure: error: Could not find a version of the library!
It looks like it defaults to looking in /usr/bin instead of where lib
boost is in sid. Try
./configure
On 01/04/14 19:54, László Böszörményi (GCS) wrote:
On Sat, Jan 4, 2014 at 1:51 AM, Paul Tarjan p...@fb.com wrote:
checking whether the Boost::Thread library is available... yes
configure: error: Could not find a version of the library!
It looks like it defaults to looking in /usr/bin instead
On Sat, Jan 4, 2014 at 6:58 PM, Faidon Liambotis parav...@debian.org wrote:
On 01/04/14 19:54, László Böszörményi (GCS) wrote:
Anyway, folly is packaged and uploaded. HHVM is one small step
closer to be part of Debian.
Does folly have a stable ABI? I remember raising this with Paul some time
On Sat, Jan 04, 2014 at 07:07:15PM +0100, László Böszörményi (GCS) wrote:
Does folly have a stable ABI? I remember raising this with Paul some
time
ago and us deciding that embedding folly into the HHVM source would be the
way to go, as there is really no stable interface between them.
I can't
I can't answer this question. Still, I expect that HHVM will follow
ABI changes very fast. Paul?
Anyway, I think having a separate package and let users get knowledge
of that doesn't mean HHVM can't use an embedded copy if it needs to.
But it should be a separate package whenever it's possible.
On 1/4/14 10:33 , Paul Tarjan p...@fb.com wrote:
I can't answer this question. Still, I expect that HHVM will follow
ABI changes very fast. Paul?
Anyway, I think having a separate package and let users get knowledge
of that doesn't mean HHVM can't use an embedded copy if it needs to.
But it should
On Sat, Jan 4, 2014 at 10:52 PM, Sara Golemon sar...@fb.com wrote:
On 1/4/14 10:33 , Paul Tarjan p...@fb.com wrote:
I can't answer this question. Still, I expect that HHVM will follow
ABI changes very fast. Paul?
+Jordan and Sara who know more about the folly process.
Folly doesn't have a
On Sat, Jan 04, 2014 at 11:53:25PM +0100, László Böszörményi (GCS) wrote:
Question is, does Folly maintain ABI compatibility? If it changes
from time-to-time, how often?
Yeah, it doesn't attempt to maintain ABI backward compatability, and
we haven't done much about tracking when we break
On Mon, Dec 30, 2013 at 8:36 PM, Paul Tarjan p...@fb.com wrote:
https://github.com/hhvm/packaging/tree/master/hhvm/deb
Checked wheezy/ which is just wrong. It's a binary debian directory
and not a source one, I think 'Essential' is only used if its value is
'yes'. Standards-Version is missing,
I can use Debian servers or an own GitHub repository for packaging,
no problem. Actually I think I'm ~90% ready with HHVM packaging.
Yay!
checking whether the Boost::Thread library is available... yes
configure: error: Could not find a version of the library!
It looks like it defaults to
On Tue, Dec 31, 2013 at 3:45 AM, Faidon Liambotis parav...@debian.org wrote:
On Mon, Dec 30, 2013 at 12:56:48AM +0100, László Böszörményi (GCS) wrote:
Two weeks is probably too often for Debian but time-based releases in
general (rather than important bugfix) are fairly common. I think the
https://github.com/hhvm/packaging/tree/master/hhvm/deb
Checked wheezy/ which is just wrong. It's a binary debian directory
and not a source one, I think 'Essential' is only used if its value is
'yes'. Standards-Version is missing, no long package description, ...
I would love a pull request,
On Mon, Dec 30, 2013 at 12:56:48AM +0100, László Böszörményi (GCS) wrote:
My opinion for releases follows. Do one if there's an important
bugfix, new feature added, etc. In short, if there's a reason.
On the other hand, there's no problem with releasing every two weeks,
it's just not common. It
On Sun, Dec 22, 2013 at 12:03:38AM +0100, Francesco Poli wrote:
Not really, in my opinion.
I think it's a valid rejection reason for anything that is not the
reference PHP implementation published and copyrighted by the PHP Group.
Personally, I consider the PHP License non-free even for PHP
On Sun, Dec 29, 2013 at 2:46 PM, Faidon Liambotis parav...@debian.org wrote:
On Sun, Dec 22, 2013 at 12:03:38AM +0100, Francesco Poli wrote:
Personally, I consider the PHP License non-free even for PHP itself,
but that's another story:
On Sun, 29 Dec 2013 14:46:50 +0100 Faidon Liambotis wrote:
On Sun, Dec 22, 2013 at 12:03:38AM +0100, Francesco Poli wrote:
Not really, in my opinion.
I think it's a valid rejection reason for anything that is not the
reference PHP implementation published and copyrighted by the PHP Group.
On Sun, 29 Dec 2013 15:22:09 +0100 László Böszörményi (GCS) wrote:
On Sun, Dec 29, 2013 at 2:46 PM, Faidon Liambotis parav...@debian.org wrote:
On Sun, Dec 22, 2013 at 12:03:38AM +0100, Francesco Poli wrote:
Personally, I consider the PHP License non-free even for PHP itself,
but that's
Thanks so much for speaking up Faidon. Francesco, I honestly thought you
were speaking officially and we would be rejected. When you didn't reply
to my email asking What should I do? I didn't know what to think...
I won't stir the pot with any more legal discussion. That isn't my field
and I'm
On Sun, 29 Dec 2013 22:42:43 + Paul Tarjan wrote:
[...]
Francesco, I honestly thought you
were speaking officially and we would be rejected.
Once again, if I gave the impression to speak as an official Debian
Project spokesperson, I apologize for the confusion.
My messages were full of in
On Sun, Dec 29, 2013 at 11:42 PM, Paul Tarjan p...@fb.com wrote:
I won't stir the pot with any more legal discussion. That isn't my field
and I'm just parroting what our legal department tells me anyways. I've
articulated our position before, so I'll just wait until the legal issue
is actually
On Sat, 21 Dec 2013 23:09:18 + Paul Tarjan wrote:
[...]
What would you like me to do?
Since, as you said, hhvm includes code derived from the reference PHP
implementation copyrighted by the PHP Group, I am afraid that it
wouldn't be trivial to get rid of the PHP License...
Would it be
On Mon, 16 Dec 2013 19:43:37 + Paul Tarjan wrote:
I'd like to revive this bug now that our libevent plans are solidified.
Good, thanks for getting back to work on the inclusion of hhvm into
Debian!
[...]
What else should I be doing to get this packaged up for inclusion in
debian?
Do
What else should I be doing to get this packaged up for inclusion in
debian?
Do you mean apart from persuading the copyright holder (Facebook, Inc.)
to re-license hhvm under more general DFSG-free terms, such as the
3-clause BSD license?
Your help in getting this issue solved would be
On Sat, 21 Dec 2013 20:42:37 + Paul Tarjan wrote:
That rejection reason is pretty squarely aimed at people writing
applications in the PHP language and makes sense for them.
Not really, in my opinion.
I think it's a valid rejection reason for anything that is not the
reference PHP
Not really, in my opinion.
I think it's a valid rejection reason for anything that is not the
reference PHP implementation published and copyrighted by the PHP Group.
Personally, I consider the PHP License non-free even for PHP itself,
but that's another story:
I'd like to revive this bug now that our libevent plans are solidified.
With our 2.3.0 release we now support FastCGI and we want to make that the
default method to run HHVM. Our FastCGI server works with the standard
libevent 2.0 library and if that is the only thing present on the
compiling
28 matches
Mail list logo
