On 2/28/14, 10:10 PM, László Böszörményi (GCS) wrote:
> Hi Ender, all,
>
> On Fri, Feb 28, 2014 at 8:16 PM, David Martínez Moreno <ender@debian.org> wrote:
>> Hello all. My name is Ender, I have been a Debian developer for quite some
>> time and I work for Facebook, so I decided to do proper packaging of hhvm in
>> Alioth, as having this done properly is a goal for the team in the first part of
>> the year.
> I was wondering if one of us is working for Facebook or not. I
> suspected yes, as we are everywhere and I'm right.
Of course we are everywhere! :-)
>> I've read the entire thread to become familiar with everything discussed so
>> far, and I will be incorporating some of the suggestions discussed here as well
>> as some decisions that we made as a team.
> Can you share those decisions?
Don't act as we have some hidden agenda, please. There are several things that
I'm putting work on like dropping support for the forked libevent HTTP server,
using alternatives for the php5-cli/cgi binaries to be able to replace them, no
init scripts for now, compiling folly statically (or at the very least not as a
different package), getting rid of third-party stuff, releasing proper tarballs
in hhvm.com, merging the nightly packages with my work, and those are off the
top of my head.
>> All the development for now is happening on collab-maint/hhvm [1], as the
>> current Github repo structure does not fit really well the layout of
>> git-buidpackage.
> Quickly peeking into your packaging I do wonder if you read the
> entire bug thread.
> For example I've discussed architecture support with Paul Tarjan
> (message 50)[1]:
> -- cut --
> From: Paul Tarjan <pt@fb.com>
> Date: Wed, 6 Nov 2013 16:51:46 +0000
>> 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.
> -- cut --
> Still, you put the binary package architecture any, instead of only
> amd64. Does Facebook supports for example mips now?
I hadn't pushed some of my changes to git... architecture and additional fixes
are now in.
> In that mail you can also read that I've identified most of the build
> dependencies. May I ask why you don't use any of that?
Again the list was incomplete (not pushed) and I was just walking through the
CMake packaging and getting familiar with it. Our list of dependencies are
different. Apart from the fact that you made yours 5 months ago (which is
actually a lot of time for the HHVM team), there are some differences, like you
depending on the 1.54 version of libboost vs. my packaging depending on the
general -dev packages.
Without wanting this to become a blame game, my list of dependencies is much
more specific than yours, adding also missing libraries, for example:
chrpath
libexpat1-dev
libfreetype6-dev
libpng12-dev
libvpx-dev
pkg-config
unixodbc-dev
And those are only some of them. I'm not blaming you, because I didn't take
the time to verify that at that time the dependencies were those, but on the
contrary I preferred to carefully add everything the HHVM sources depended on.
> Can it be that you use the embedded sources, those as Paul acknowledged:
> -- cut --
>> 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.
[...]
> I've asked Paul about other embedded libraries, but didn't get an answer.
No, I'm not. The code *wants* to use them but I'm as an example writing a
patch to remove completely the libzip dependency (which is more harmful than
normal because we also install it in the "make install" phase) not only from the
open source one but from our internal code repository.
The rest of them (if they're released as normal packages) will follow.
> But problems arise with other libs as well. For example libafdt is
> version 0.1.0 (hardly a version number to call it final and stable),
> which was last released in 2009 (yes, almost five years ago!). I've a
> package ready, but it doesn't build a shared library, just a static
> one and it has only one header file. I may upload it if you really
> want, but I don't see a reason for that. I've a package of libmbfl as
> well, version 1.3.2 , which is 'just' two years old. The version
> included in HHVM is 1.0.2 (according to
> hphp/third_party/libmbfl/mbfl.rc) and I don't want to think about how
> old is it.
Let's go piece by piece. As I see it for libafdt, if no one has felt the need
to package that, we can just embed that in the sources.
The issue with libmbfl is a bit more concerning, and I appreciate that you
already made the work. What I have to do as part of the packaging work i to
make sure that we haven't patched those sources, then I'll update them here and
will use the same logic in a backported patch. You have to think that the HHVM
has quite a bunch of technical debt around some edges. Quoting Paul Tarjan, "I
think we just brought something from the outside to third-party and that gate
kept open forever."
This is fine, because what we are trying to do is not just a Debian packaging
but also fix HHVM for the greater good. It's the HHVM team's desire and my own
goal to make this monster more palatable.
> Don't forget the Folly state (no ABI and neither source
Dismissed, as folly is going compiled in the blob as it comes from the internal
repos.
> stability), the history of old libevent version usage, makes me wonder
Dismissed as well. Paul stated it before, but I will say it again: we won't
support the libevent-based server and it won't be compiled in. The preferred
(and only supported mode) will be FastCGI-based.
> how HHVM works in the long run, how supportable is it. There's 'good'
> news of course, like Sqlite3 is version 3.7.15.2 which is 'just' one
> year old. While its homepage shows that the last release is 3.8.2 and
> upgrading from versions before 3.8.1 is strongly recommended due to
> the number of bugs fixed. OK, the only one database corruption bug
> fixed (in 3.7.16.2) since the included 3.7.15.2 is a rare one.
> Still, forgive me Paul for asking but why do you include and use well
> rotten, quite old versions of libraries? Several of them are packaged
> in modern distributions and kept fresh and clean.
> May you answer this part? For example Sqlite3 became more than a year
> old in HHVM now. Upstream version is 3.8.3.1 ATM. Paul didn't answer
> this for a while now. :-(
Because in Facebook we don't have the luxury of having up to date distributions
in the servers. The last one available IIRC is 3.7.9, so the HHVM team decided
to put an updated one and then no one took the time to update it, I guess. It's
not something that I am particularly proud of, but again, you don't seem to see
that we are pushing these packages from internal repositories where they don't
have the same level of scrutiny about "updated versions of packages". It will
take some time to get there.
> I accept the fact that Facebook wants this packaged for Debian in the
> first half of 2014 and you take over the packaging without asking me
> (probably ignoring Ondřej and Faidon as I didn't see them as Cc in
> your mail), but as you read in the mails you mentioned and I already
> put enough hours into this, at least set the architecture right to
> amd64 only.
Again, László, don't blame a which is just an artifact of development.
I just replied to the bug report where all this people are subscribed, which
forwarded them a copy of my mail. I don't see the problem here.
And about the "hostile takeover", you stated that you didn't have much time,
there was no activity in the bug report in the lat two months, Paul Tarjan asked
if there was any news about the package a month ago and he got no reply. So I
continued where the rest of you left.
> Last, but not least did you read the message from Ondřej Surý that
> HHVM should be packaged under pkg-php-maint? Any reason to just use
> collab-maint?
That message is not copied in the bug report, so I couldn't know about it.
Would you mind to point me to the archives?
> An other project from Facebook, Flint also have some issues
> unanswered[2] from a Debian Developer. May you route those to someone
> with proper knowledge?
Who is the developer, sylvestre? jmh045000?
I will do my best to route your request once I understand the problem :-).
Best regards,
Ender.
Attachment:
signature.asc
Description: OpenPGP digital signature