Hi Ender, all, On Fri, Feb 28, 2014 at 8:16 PM, David Martínez Moreno <en...@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.
> 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? > 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 <p...@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? 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? 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. Folly is pulled in with a git submodule, but yes, the others are copied in. -- cut -- Those should be ironed out and use the packaged versions expect Folly as an other Facebook employee wrote the following. -- cut -- From: Jordan DeLong <delon...@fb.com> Date: Sat, 4 Jan 2014 19:44:26 -0800 On Sat, Jan 04, 2014 at 11:53:25PM +0100, László Böszörményi (GCS) wrote: > Question is, does Folly maintain ABI compatibility? If it changes > from time-to-time, how often? Yeah, it doesn't attempt to maintain ABI backward compatability, and we haven't done much about tracking when we break source-level backward compatability either. (As Sara said, we don't version it currently... unless you count the submodule in hhvm ;) There are changes probably a few times a week, although I'd suspect few of the changes that aren't to new components (usually in folly/experimental) actually break source backward compat. -- cut -- As such, we have to trust that Folly is as up to date as possible in HHVM and it will be supported for Debian/Ubuntu stable releases (at least five years if I count in Ubuntu LTS releases). I've asked Paul about other embedded libraries, but didn't get an answer. -- cut -- 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. Don't forget the Folly state (no ABI and neither source stability), the history of old libevent version usage, makes me wonder 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. -- cut -- 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. :-( 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. 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? 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? Kind regards, Laszlo/GCS [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?msg=50;bug=727085 [2] https://github.com/facebook/flint/issues -- 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/cakjshr1adoxlxybqq2olte1ydnd_6tk3e6blzf6deau6bef...@mail.gmail.com