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 works
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 done
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 sourc
On Sat, Jan 4, 2014 at 10:52 PM, Sara Golemon wrote:
> On 1/4/14 10:33 , "Paul Tarjan" 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 version releas
On 1/4/14 10:33 , "Paul Tarjan" 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 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 possib
On Sat, Jan 4, 2014 at 6:58 PM, Faidon Liambotis 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
> ago and us
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 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
On Sat, Jan 4, 2014 at 1:51 AM, Paul Tarjan 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 --with-b
> 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 Mon, Dec 30, 2013 at 8:36 PM, Paul Tarjan 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, no l
On Tue, Dec 31, 2013 at 3:45 AM, Faidon Liambotis 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
> original idea of
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 m
>> 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 reques
On Sun, Dec 29, 2013 at 11:42 PM, Paul Tarjan 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 blockin
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 "i
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 j
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 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 Grou
On Sun, Dec 29, 2013 at 2:46 PM, Faidon Liambotis 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:
>> https://lists.debian.org/debian-legal/2005/11/msg00272.html
That's see
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 itse
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 feas
>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:
>https://lists.debian.org/deb
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 impleme
>> 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 woul
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?
D
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 machi
28 matches
Mail list logo
