On Tue, Nov 5, 2013 at 11:26 PM, Paul Tarjan <p...@fb.com> wrote: >>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. 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. 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
> 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. Still, I've read somewhere that FB has its own C event library. > 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. Sure, no problem with this. > 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 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. 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? 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. 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[_ZN5folly9TypeErrorC5ERKSsNS_7dynamic4TypeE]+0x2a): undefined reference to `folly::dynamic::TypeInfo<std::vector<folly::dynamic, std::allocator<folly::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. 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. Regards, Laszlo/GCS [1] https://github.com/facebook/folly -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
