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%3Dsummary&k=ZVNjlDMF0FElm4dQtryO4A%3D%3D% >0A&r=KbCGvs3NEqqV%2FJZMWI0xxA%3D%3D%0A&m=Cc%2BuMlf3PVOorM33Udvk4tQyoMy%2Bt >%2BAWYxrtpFKq1%2BA%3D%0A&s=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%0A&r=KbCGvs3NEqqV%2FJZMWI0xxA%3D%3D%0A&m=Cc%2BuMlf3PV >OorM33Udvk4tQyoMy%2Bt%2BAWYxrtpFKq1%2BA%3D%0A&s=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
>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
>> 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
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::allocator > >::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
>On Thu, Oct 24, 2013 at 10:27 AM, Paul Tarjan 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#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)" 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#727085: ITP: hhvm -- Virtual Machine, Runtime, and JIT for the PHP language
Package: wnpp Severity: wishlist Owner: Paul Tarjan * Package name: hhvm Version : 2.2.0 Upstream Author : Paul Tarjan * 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
