I have been working (with some help from Faidon) to bring the 2.4.1
tarball to
Debian standards. The git repo (remember,
https://urldefense.proofpoint.com/v1/url?u=http://anonscm.debian.org/gitwe
b/?p%3Dcollab-maint/hhvm.git%3Ba%3Dsummaryk=ZVNjlDMF0FElm4dQtryO4A%3D%3D%
Any news on HHVM packaging? I'd love to keep this ball rolling. I'm about
to release 2.4.0 on Thursday so that might be a nice release to target if
we can. 2.5.0 will be 8 weeks after that.
Paul
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe.
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.
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
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,
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
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
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
You have access to upstream source VCS? If not, an own Git repository
under the hood of GitHub would be nice. It has the advantage that
users may report bugs directly to FB.
Ok, let me look into it. I liked pulling from theirs in the build
instructions and it looked official.
But let me rewind
Can Facebook do the fork then?
Sure. How do you want us to fork it? Our current method is pinning to a
tag in their branch and a .patch file.
Meanwhile I've packaged the latest 1.x
release with the HHVM patch applied[1]. I need to check if v1.x and
v2.y can live together though.
Does FB know
It wasn¹t me, but I¹m happy to take over the conversation.
Sadly, HHVM doesn¹t work on libevent 2. It was a total rewrite of the API
and doesn¹t meet our needs.
Can we either:
1) distribute a libevent1.4-hhvm package with the patched .so files in
/var/lib/hhvm/
2) bundle the patched .so into
On Thu, Oct 24, 2013 at 10:27 AM, Paul Tarjan p...@fb.com wrote:
It wasn¹t me, but I¹m happy to take over the conversation.
Checked my sent-mail folder and it was you. The email I had is github
[at] paulisageek.com .
That’s me. I checked and it came in as a notification which was filtered
Package: wnpp
Severity: wishlist
Owner: Paul Tarjan p...@fb.com
* Package name: hhvm
Version : 2.2.0
Upstream Author : Paul Tarjan p...@fb.com
* URL : http://www.hhvm.com/
* License : PHP and Zend and BSD
Programming Lang: C++ and PHP
Description
14 matches
Mail list logo
