Bug#727085: An HHVM-in-Debian State of the Union (was Re: Bug#727085: Taking over packaging in Debian.)
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% 0Ar=KbCGvs3NEqqV%2FJZMWI0xxA%3D%3D%0Am=Cc%2BuMlf3PVOorM33Udvk4tQyoMy%2Bt %2BAWYxrtpFKq1%2BA%3D%0As=d572db8992a4b95f8b27e56fa11dde396e7881c8bda6de8 a2c441adc3e61b428) reflects right now three major operational changes: integration of system's libzip, integration of system's libsqlite3 and the removal of several libraries that added useless dependencies to the package. Yay. Apart from that, the debian/copyright work is, as you may imagine, a three-ring circus. Apart from the huge list of contributors and different licenses, there is a big showstopper that I found so far, which is that a couple of files are licensed under the (in)famous JSON.org license (Software has to be used for Good not Evil). I'm doing my best to convince the in-house developers that switching to pecl-json-c (from Remi Collet) is the best approach as we are not bug-compatible anymore with the two main Linux families out there (Debian and RedHat) since the end of May 2013, but at the same time they want to stay close to PHP for good reasons. There is an endless debate^W^W^Wmore information at PHP#63520. This one is fun. We've chatted a bunch and the general consensus is that the optimal outcome would be to be as compatible with php5 as possible. This means we would like to use remi's extension (assuming all our unit tests and the big framework tests pass). We actually don't care too much about staying close to PHP5 at the source level since many more people are using our packages as building from source. It also is pretty bad to have the developers using the source be using a different library than the uses who use the package. So Ender, if you can get remi's extension ported to us, then we'd take it upstream. In the meantime, Facebook has released HHVM 3.0.0 with Hack support (a superset of PHP with gradual typing, collections and more stuff - https://urldefense.proofpoint.com/v1/url?u=http://hacklang.org/k=ZVNjlDMF 0FElm4dQtryO4A%3D%3D%0Ar=KbCGvs3NEqqV%2FJZMWI0xxA%3D%3D%0Am=Cc%2BuMlf3PV OorM33Udvk4tQyoMy%2Bt%2BAWYxrtpFKq1%2BA%3D%0As=9398e7801cd780c0445cf51e09 28831d9065d9f94a050e88fe6c5477e456bb46). While I'm all for packaging that version, I'm trying to stay close to 2.4.1 as I already know my troubles with this version and I don't want to add more logs to the fire, so I'm not updating the upstream version yet. Also the 3.0.0 adds dependencies like some OCaml code analysis tools depending on other stuff that is not even nearly packaged, so...you know. As far as source goes, 3.0.0 isn't much of a change. It optionally builds the type checker if you have ocaml on your machine but happily ignores it if you don't. So I bet if you drop it into your workflow it will 'just work'. Paul -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/cf5effcc.6555e...@fb.com
Bug#727085: Any news?
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-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cf0d8d71.5d2b4...@fb.com
Bug#727085: Now we don't depend on the weird libevent patch
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. We pin HHVM to certain git hashes. If there is a folly change we need (which is rare) we will update the hash of the git submodule. I don't know the details of how folly does backwards compatibility but if the hashes we have correspond to folly package version, then you could just pin our hhvm versions to folly versions, right? +Jordan and Sara who know more about the folly process. Paul -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/ceed92c6.57f27...@fb.com
Bug#727085: Now we don't depend on the weird libevent patch
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 looking in /usr/bin instead of where lib boost is in sid. Try ./configure --with-boost-libdir=/usr/lib/x86_64-linux-gnu/ Paul -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/ceec9aba.57e8b...@fb.com
Bug#727085: Now we don't depend on the weird libevent patch
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, or if you get really into this I'm happy to
make you a co-author on the repo.
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 matches with Debian standards, meaning that
normally ten days needed for unstable - testing migration.
Excellent. We move pretty fast and are constantly making performance
improvements which is why we release internally every 2 weeks. I'll float
it with the rest of the team. If we do 26 releases this year we'll be at
2.30.0 by the end of the year. Is that weird?
Do you have a packager position there, at FB? :)
Short term, yes, but long term we would much rather the community take
over packaging.
On my team it wouldn't be a full time job, but I'm filling the role right
now and would love you to do it instead ;) You'd just have to find other
good things to do too. https://www.facebook.com/careers/
Now my previous package section for HHVM,
which I've named hiphop-php (to match the PHP policy of Debian, but
will re-check that):
Our project used to be named hiphop-php when it was a PHP to C++
translator. We decommissioned it in February once the JIT was faster. The
JIT was codenamed HHVM so we've taken that on as the project's main name
since it is the only runtime we support now.
-- cut --
Package: hiphop-php
Architecture: any
Depends: ${misc:Depends}
Description: HipHop VM for PHP
HipHop VM (HHVM) is a new open-source virtual machine designed for
executing
programs written in PHP. HHVM uses a just-in-time compilation approach to
achieve superior performance while maintaining the flexibility that PHP
developers are accustomed to. HipHop VM (and before it HPHPc) has
realized
5x increase in throughput for Facebook compared with Zend PHP 5.2.
HipHop is most commonly run as a standalone server, replacing both Apache
and modphp.
-- cut --
Should I use this? Again a pull request would be awesome.
I'll probably still have to keep packaging
it for other distros since you're only going to do debian, right? Or is
there an easy way for you to also do it in other debian-based distros
(ubuntu, mint). Can you also do yum based distros or do you know what I
should do for inclusion there?
I think packaging for Debian is a good step. Then Ubuntu maintainers
will pick it up and as I know, Mint based on Ubuntu, they will have it
as well. I've experience with Red Hat and Fedora packaging as well.
You may know that the transition is Fedora - Red Hat from time to
time.
I would be elated for any help you can offer here. And even if you can't
do it, guide me on the steps I need to do and I'll do everything in my
power to help. We are very excited about being in every distro.
One other thing I haven't brought up and probably should, is we are trying
to be a drop-in replacement for all facets of php. For example, if our
binary is named php then it will accept the same command line args that
php-src accepts. For now, the packages I've made have left our binary
named hhvm since I don't know how it will interact with the php-src
package, but if there is an easy way to use alternates or something we
can drop in and replace the system binary too (and give a big speed boost
to user's scripts).
Paul
--
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/cee6eb13.57a8c...@fb.com
Bug#727085: Now we don't depend on the weird libevent patch
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 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 blocking our adoption. Ok? Since my last email, I put a bunch of effort into my packaging script. Now they are signed correctly, there is a main skeleton and then overrides for each version, and it updates the version files for me. Feel free to make pull requests or use this as a basis: https://github.com/hhvm/packaging/tree/master/hhvm/deb Internally at FB we release a new version of HHVM every 2 weeks. We cut the branch on Monday and then do lots of rigorous testing and ship it 10 days later on Thursday morning. I'd like to exactly mirror the internal releases since they are well tested instead of just arbitrarily cutting trunk. Many people voiced opinions that every 2 weeks was too fast for major open source releases so we agreed on mirroring every 4 releases (8 weeks). How does that sound? It is easy to make it faster or slower by 2 week increments if anyone has opinions. Lastly, Laszlo, we should talk about how I can help with packaging. I currently make a new branch for major versions and tags for each point release on our github repo. Do you want me to email you when I do this or can you subscribe to github easily? Or should I setup a mailing list and always email that when I push? I'll probably still have to keep packaging it for other distros since you're only going to do debian, right? Or is there an easy way for you to also do it in other debian-based distros (ubuntu, mint). Can you also do yum based distros or do you know what I should do for inclusion there? Paul -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cee5b819.57975...@fb.com
Bug#727085: Now we don't depend on the weird libevent patch
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 highly appreciated, I think. Please re-read http://bugs.debian.org/727085#60 for further details on the licensing issue. That rejection reason is pretty squarely aimed at people writing applications in the PHP language and makes sense for them. We are an alternative to php-src mostly coded in C++ and x86 assembly. (and after we prove ourselves I'll petition to be marked as an alternative for the php package). As for the direct question. Much of our extension code was directly imported from php-src so we will absolutely be unable to relicense that portion. Untangling our contributions from the php-src ones is a very arduous task since there are many bug fixes to their code (some upstreamed, some not) as well as API changes and data structure replacements. We are happy with the php license so releasing the whole package under the same umbrella makes development much easier. We are willing to relicense our portions under BSD but the technical splitting of the files into us vs them is just too much to ask. Again, we are the first viable runtime alternative to php-src so I would argue that the rejection paragraph does not apply to us and didn't even consider us. I think László (who reads us in Cc) is still interested in packaging hhvm for inclusion in Debian. At least the bug is still an ITP bug and still owned by László, hence, unless he has just changed his mind, he should be still willing to work on the packaging... I suggest you to get in touch with László and ask him whether and how you can help. Laszlo, if you are listening out there please build us a package. You can see what I was doing at http://github.com/hhvm/packaging Thanks for being a Debian-friendly upstream developer and for offering to help! Bye. -- http://www.inventati.org/frx/frx-gpg-key-transition-2010.txt New GnuPG key, see the transition document! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/efc6a867-a559-4bb2-bb51-9d73f30e0...@fb.com
Bug#727085: Now we don't depend on the weird libevent patch
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/debian-legal/2005/11/msg00272.html What would you like me to do? Please let me understand: do you mean that hhvm includes code derived from the reference PHP implementation published and copyrighted by the PHP Group? Yes. You can see our source code at https://github.com/facebook/hhvm -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cedb5f05.571d6...@fb.com
Bug#727085: Now we don't depend on the weird libevent patch
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 machine, then the standalone HTTP server support won't be available and you can only use FastCGI. This is the mode we expect to become the default with a future release (probably 2.5.0 in 4 months). What else should I be doing to get this packaged up for inclusion in debian? My method of packaging our release is very clowny (I compile the binary and then copy it into a directory with the skeleton for the package and then build that with dpkg -b) so I'd rather someone else with more debian experience build a proper package for us. You can find me on IRC on freenode in #hhvm if you prefer real-time. Paul -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/ced497e6.565ef...@fb.com
Bug#570709: packaging hhvm
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 first. You can create a basic Debian chroot environment
with:
debootstrap --arch selected_arch sid /place/the/chroot/dir/here/
http://http.debian.net/debian/
Where selected_arch can be i386 or amd64 (or any architecture FB may use).
Then download, build and install my patched libevent 1.4.x to that
chroot environment.
The following build dependencies are identified for HHVM 2.0:
cmake
binutils-dev
libevent-dev
libreadline-dev
libedit-dev
libncurses5-dev
libbz2-dev
libxml2-dev
libmemcached-dev
libicu-dev
libgd-dev
libcap-dev
libmcrypt-dev
libcurl4-gnutls-dev
libtbb-dev
libc-client2007e-dev
libpcre3-dev
libinotifytools0-dev
libmysqld-dev
libboost1.54-dev
libboost-system1.54-dev
libboost-program-options1.54-dev
libboost-filesystem1.54-dev
libboost-regex1.54-dev
libgoogle-glog-dev
libelf-dev
libdwarf-dev
libonig-dev
Yes, that page is highly outdated. I think Standards-Version 3.9.2 is
obsoloted now (the current one is 3.9.5) and that page uses 3.8.1!
Debhelper level should be 9 and not 7, debian/rules may use the short
debhelper format.
Yikes. Can yo update it please?
Last but not least that wiki forces HHVM to be amd64
only. Any reason to do that? Any known problem to run HHVM on
kfreebsd-*, mips{,el}, sparc or any other archs that Debian supports?
Absolutely. HHVM is a Just-In-Time compiler which emits assembly code into
memory then executes it. We currently only emit 64bit x86. We are looking
at other backends, but they require a lot of effort to implement and
optimize.
To answer your question, the proper package build is using pbuilder or
sbuild (I prefer the former). But until I can't build HHVM by hand, I
don't want to put time into packaging. I've just realized that HHVM
embeds other codes under hphp/third_party/ , even folly which is an
other FB FOSS software and should be packaged separately.
Folly is pulled in with a git submodule, but yes, the others are copied in.
Especially
that now (for me) building HHVM fails with:
Linking CXX executable gen-class-map
CMakeFiles/gen-class-map.dir/gen-class-map.cpp.o: In function
`folly::TypeError::TypeError(std::string const,
folly::dynamic::Type)':
gen-class-map.cpp:(.text._ZN5folly9TypeErrorC2ERKSsNS_7dynamic4TypeE[_ZN5f
olly9TypeErrorC5ERKSsNS_7dynamic4TypeE]+0x2a):
undefined reference to
`folly::dynamic::TypeInfostd::vectorfolly::dynamic,
std::allocatorfolly::dynamic ::name'
[...and so on...].
But the embedded folly was compiled normally (the problem can be that
it's a static library but gen-class-map linking may look for a dynamic
one):
Linking CXX static library ../../../bin/libfolly.a
[ 3%] Built target folly
This further emphasize that folly[1] should be packaged separately.
Hmm, try
rm CMakeCache.txt
And follow the instructions
https://github.com/facebook/hhvm/wiki/Building-and-installing-HHVM-on-Debia
n-7 . That worked for me last week.
System libsqlite3-dev should be used as well, instead of embedding it
and so on. An other library which is in my hand in Debian and some
extra compilation options may be discussed if needed.
Sure, we¹d be happy to take patches to do that. I think they are embedded
since those libraries aren¹t readily available easily and this is the best
way to alleviate developer pain.
--
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/ce9fa909.51a93...@fb.com
Bug#727085: Bug#570709: packaging hhvm
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 that other event libraries are exist as well[2][3]? The latter states that it's a full-featured and high-performance event loop that is loosely modelled after libevent, but without its limitations and bugs. We haven¹t put the effort into any other event library. Our web server is already a pretty small proportion of our request time so inventing time in it is less impactful than HHVM optimizations. But it would be better on the long run. If you stick with version 1.x, you need to support an obsoleted version. With the 2.x switch, you'd get development (possibly performance increase with time) for free. Anyway, some weeks ago I've read that FB has its own event library, coded in plain C. Even faster a bit than libevent in certain workloads. Can't find it now. :( But maybe that would be a better dependency for HHVM. Yes, at some point we will switch our server to us it and open source it. No ETA on that project though and I¹d rather not gate the packaging of this on it. I was packaging for Debian 7 but I see it on Debian 8. Should we just target 8? Uploads in Debian can go to two 'branches'. The first is Sid, the everytime unstable and to experimental. All development happens in unstable. Experimental is used for playing and testing with packages that may break the system hard. Packages goes to testing after a specific time is passed without serious bug reported against it (default to ten days). To stable versions (currently version 7.1, codenamed Wheezy) only the security team can upload. Cool, thanks. I've a working and up-to-date setup of course. I don't know the problem you refer to. Most of the packages builds inline with the source files I think. It's the job of '$(MAKE) clean' to delete all build generated files between rebuilds. It's the time to force an old and patched version of libevent to my setup and check the build process of HHVM. Nice! Can you share that with me somehow? I¹d love to see how yours and mine differ. I don¹t want to steal any credit and I¹m more than happy for you to be the packager, I just want to learn. The internet is full with howtos on this topic. Keywords are debootstrap and/or pbuilder. I can write you specific URLs with detailed steps if needed. Last time I was very close to compile HHVM, but it still failed with some 'this library needs a specific patch' error message as far as I can remember. My main problem is getting the compile to be automatic and clean up correctly. Starting from your working copy would help me understand the correct way to do it. I was originally following [4] but then I was told it was outdated so I¹m fighting through another version. [4] https://github.com/facebook/hhvm/wiki/Build-Packages-for-Debian -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/ce9eae97.518aa...@fb.com
Bug#570709: packaging hhvm
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 hhvm (which I do for the one on [3]) 3) something else? A similar thing will have to happen for libglog. That one doesn¹t need any patches and we work on anything 0.3.1 and higher so it might just be a straightforward requirement to package. As for the status of the ITP, I¹ve been trying to package it the correct way, and our build environment wants to create all the temporary files inline with the build instead of a subdirectory, so dpkg-buildpackage doesn¹t like all the new files around. If you have a functioning packaging environment I would be more than happy to hand off the packaging to you. Paul [3] https://github.com/facebook/hhvm/wiki/Prebuilt-Packages-on-Debian-7 On 10/24/13, 1:12 AM, László Böszörményi (GCS) g...@debian.org wrote: Hi Paul, I think I've already contacted you or someone else from Facebook about packaging HHVM for Debian. I own the ITP with its previous name, hiphop-php . At the moment it can't be packaged for Wheezy and newer because HHVM needs a libevent patch not available for the current releases. Couldn't find the error message from configure/cmake that it needs a patched version of libevent ATM, still you can see the patching line[1]. But Wheezy and later has a much newer[2] version (2.0.19+) than the patch would like to extend (version 1.4.14). If this can be solved, I would be happy to finish its packaging. Regards, Laszlo/GCS [1] https://github.com/facebook/hhvm/blob/master/configure_ubuntu_12.04.sh#L79 [2] http://packages.debian.org/source/stable/libevent -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/ce8e26ab.50745...@fb.com
Bug#570709: packaging hhvm
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, sorry. Sadly, HHVM doesn¹t work on libevent 2. It was a total rewrite of the API and doesn¹t meet our needs. That's very bad and raises several issues. The main one is that who will support the old libevent version? Will you maintain it for functional and/or build problems (Debian has several architectures to support) including patches for security related bugs? Yes, we will have to. It will be our fork. We have a vested interest in it too since facebook.com runs on that too. Can we either: 1) distribute a libevent1.4-hhvm package with the patched .so files in /var/lib/hhvm/ Can be, but it needs precaution that other binaries don't have an easy way to find it and try to link with it at run time. The other way HHVM needs to be patched to look for libevent under that directory and don't get confused with the system installed version 2 of that lib. If you point the CMAKE_LIBRARY_PATH to that directory then it should work. 2) bundle the patched .so into hhvm (which I do for the one on [3]) Hiding it under/in HHVM makes things even worse. It would make Debian FTP Masters very upset I think. K, nixed. 3) something else? Is it something like impossible to get the required functionality to version 2.x of libevent or it needs just too much work? Can the changes be generalized and make it viable to other programs as well? That way upstream may accept it for inclusion. Sadly we can’t switch to 2.x without a ton of effort. The API model is callback based instead of buffer based. Our .so is generalized enough that others can use, but we don’t really want to maintain it for external includes. A similar thing will have to happen for libglog. That one doesn¹t need any patches and we work on anything 0.3.1 and higher so it might just be a straightforward requirement to package. Version 0.3.3 is in the archive. Simple dependency will be enough. If you need something with it, feel free to ask me. I'm its uploader in Debian. I was packaging for Debian 7 but I see it on Debian 8. Should we just target 8? As for the status of the ITP, I¹ve been trying to package it the correct way, and our build environment wants to create all the temporary files inline with the build instead of a subdirectory, so dpkg-buildpackage doesn¹t like all the new files around. If you have a functioning packaging environment I would be more than happy to hand off the packaging to you. I've a working and up-to-date setup of course. I don't know the problem you refer to. Most of the packages builds inline with the source files I think. It's the job of '$(MAKE) clean' to delete all build generated files between rebuilds. It's the time to force an old and patched version of libevent to my setup and check the build process of HHVM. Nice! Can you share that with me somehow? I’d love to see how yours and mine differ. I don’t want to steal any credit and I’m more than happy for you to be the packager, I just want to learn. paul -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/ce8edc72.508e0...@fb.com
Bug#727085: ITP: hhvm -- Virtual Machine, Runtime, and JIT for the PHP language
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 : Virtual Machine, Runtime, and JIT for the PHP language I already distrubute the packages using our own repo https://github.com/facebook/hhvm/wiki/Prebuilt-Packages-on-Debian-7 but I'd rather them included directly in Debian and derivatives -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131022064349.30467.639.reportbug@debian
