Debian Bug report logs - #727085
ITP: hhvm -- Virtual Machine, Runtime, and JIT for the PHP language

Package: wnpp; Maintainer for wnpp is wnpp@debian.org;

Reported by: Paul Tarjan <pt@fb.com>

Date: Tue, 22 Oct 2013 06:45:02 UTC

Owned by: László Böszörményi (GCS) <gcs@debian.org>

Severity: wishlist

Merged with 570709

Reply or subscribe to this bug.

Toggle useless messages

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to debian-bugs-dist@lists.debian.org, pt@fb.com, debian-devel@lists.debian.org, wnpp@debian.org:
Bug#727085; Package wnpp. (Tue, 22 Oct 2013 06:45:07 GMT) Full text and rfc822 format available.

Acknowledgement sent to Paul Tarjan <pt@fb.com>:
New Bug report received and forwarded. Copy sent to pt@fb.com, debian-devel@lists.debian.org, wnpp@debian.org. (Tue, 22 Oct 2013 06:45:07 GMT) Full text and rfc822 format available.

Message #5 received at submit@bugs.debian.org (full text, mbox):

From: Paul Tarjan <pt@fb.com>
To: Debian Bug Tracking System <submit@bugs.debian.org>
Subject: ITP: hhvm -- Virtual Machine, Runtime, and JIT for the PHP language
Date: Mon, 21 Oct 2013 23:43:49 -0700
Package: wnpp
Severity: wishlist
Owner: Paul Tarjan <pt@fb.com>

* Package name    : hhvm
  Version         : 2.2.0
  Upstream Author : Paul Tarjan <pt@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



Information forwarded to debian-bugs-dist@lists.debian.org, wnpp@debian.org, Paul Tarjan <pt@fb.com>:
Bug#727085; Package wnpp. (Tue, 22 Oct 2013 21:51:11 GMT) Full text and rfc822 format available.

Acknowledgement sent to Antoine Musso <hashar@free.fr>:
Extra info received and forwarded to list. Copy sent to wnpp@debian.org, Paul Tarjan <pt@fb.com>. (Tue, 22 Oct 2013 21:51:11 GMT) Full text and rfc822 format available.

Message #10 received at 727085@bugs.debian.org (full text, mbox):

From: Antoine Musso <hashar@free.fr>
To: Paul Tarjan <pt@fb.com>, 727085@bugs.debian.org
Subject: Re: ITP: hhvm -- Virtual Machine, Runtime, and JIT for the PHP language
Date: Tue, 22 Oct 2013 23:50:15 +0200
Le 22/10/13 08:43, Paul Tarjan a écrit :
> Package: wnpp
> Severity: wishlist
> Owner: Paul Tarjan <pt@fb.com>
> 
> * Package name    : hhvm
>   Version         : 2.2.0
>   Upstream Author : Paul Tarjan <pt@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

Hello Paul,

Would you be so kind to produce a source package and publish the Debian
source somewhere?  Maybe it could be provided in a Debian branch in the
github repository?

-- 
Antoine "hashar" Musso



Information forwarded to debian-bugs-dist@lists.debian.org, wnpp@debian.org, Paul Tarjan <pt@fb.com>:
Bug#727085; Package wnpp. (Thu, 24 Oct 2013 08:15:16 GMT) Full text and rfc822 format available.

Acknowledgement sent to László Böszörményi (GCS) <gcs@debian.org>:
Extra info received and forwarded to list. Copy sent to wnpp@debian.org, Paul Tarjan <pt@fb.com>. (Thu, 24 Oct 2013 08:15:16 GMT) Full text and rfc822 format available.

Message #15 received at 727085@bugs.debian.org (full text, mbox):

From: László Böszörményi (GCS) <gcs@debian.org>
To: Paul Tarjan <pt@fb.com>
Cc: 570709@bugs.debian.org, 727085@bugs.debian.org
Subject: packaging hhvm
Date: Thu, 24 Oct 2013 10:12:00 +0200
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



Information forwarded to debian-bugs-dist@lists.debian.org, wnpp@debian.org:
Bug#727085; Package wnpp. (Thu, 24 Oct 2013 09:12:10 GMT) Full text and rfc822 format available.

Acknowledgement sent to Paul Tarjan <pt@fb.com>:
Extra info received and forwarded to list. Copy sent to wnpp@debian.org. (Thu, 24 Oct 2013 09:12:10 GMT) Full text and rfc822 format available.

Message #20 received at 727085@bugs.debian.org (full text, mbox):

From: Paul Tarjan <pt@fb.com>
To: László Böszörményi (GCS) <gcs@debian.org>
Cc: "570709@bugs.debian.org" <570709@bugs.debian.org>, "727085@bugs.debian.org" <727085@bugs.debian.org>
Subject: Re: packaging hhvm
Date: Thu, 24 Oct 2013 08:27:15 +0000
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)" <gcs@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




Information forwarded to debian-bugs-dist@lists.debian.org, wnpp@debian.org, Paul Tarjan <pt@fb.com>:
Bug#727085; Package wnpp. (Thu, 24 Oct 2013 12:24:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to László Böszörményi (GCS) <gcs@debian.org>:
Extra info received and forwarded to list. Copy sent to wnpp@debian.org, Paul Tarjan <pt@fb.com>. (Thu, 24 Oct 2013 12:24:04 GMT) Full text and rfc822 format available.

Message #25 received at 727085@bugs.debian.org (full text, mbox):

From: László Böszörményi (GCS) <gcs@debian.org>
To: Paul Tarjan <pt@fb.com>
Cc: "570709@bugs.debian.org" <570709@bugs.debian.org>, "727085@bugs.debian.org" <727085@bugs.debian.org>
Subject: Re: packaging hhvm
Date: Thu, 24 Oct 2013 14:22:56 +0200
On Thu, Oct 24, 2013 at 10:27 AM, Paul Tarjan <pt@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 .

> 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?

> 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.

> 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.

> 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.

> 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.

> 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.

Laszlo/GCS
> [3] https://github.com/facebook/hhvm/wiki/Prebuilt-Packages-on-Debian-7



Information forwarded to debian-bugs-dist@lists.debian.org, wnpp@debian.org:
Bug#727085; Package wnpp. (Thu, 24 Oct 2013 21:27:11 GMT) Full text and rfc822 format available.

Acknowledgement sent to Paul Tarjan <pt@fb.com>:
Extra info received and forwarded to list. Copy sent to wnpp@debian.org. (Thu, 24 Oct 2013 21:27:11 GMT) Full text and rfc822 format available.

Message #30 received at 727085@bugs.debian.org (full text, mbox):

From: Paul Tarjan <pt@fb.com>
To: László Böszörményi (GCS) <gcs@debian.org>
Cc: "570709@bugs.debian.org" <570709@bugs.debian.org>, "727085@bugs.debian.org" <727085@bugs.debian.org>
Subject: Re: packaging hhvm
Date: Thu, 24 Oct 2013 21:23:03 +0000
>On Thu, Oct 24, 2013 at 10:27 AM, Paul Tarjan <pt@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




Information forwarded to debian-bugs-dist@lists.debian.org, wnpp@debian.org, Paul Tarjan <pt@fb.com>:
Bug#727085; Package wnpp. (Tue, 05 Nov 2013 21:45:08 GMT) Full text and rfc822 format available.

Acknowledgement sent to László Böszörményi (GCS) <gcs@debian.org>:
Extra info received and forwarded to list. Copy sent to wnpp@debian.org, Paul Tarjan <pt@fb.com>. (Tue, 05 Nov 2013 21:45:08 GMT) Full text and rfc822 format available.

Message #35 received at 727085@bugs.debian.org (full text, mbox):

From: László Böszörményi (GCS) <gcs@debian.org>
To: Paul Tarjan <pt@fb.com>, 570709@bugs.debian.org, "727085@bugs.debian.org" <727085@bugs.debian.org>
Subject: Re: Bug#570709: packaging hhvm
Date: Tue, 5 Nov 2013 22:43:12 +0100
Hi Paul,

I'd other things, but back on track.

On Thu, Oct 24, 2013 at 11:23 PM, Paul Tarjan <pt@fb.com> wrote:
>>On Thu, Oct 24, 2013 at 10:27 AM, Paul Tarjan <pt@fb.com> wrote:
>> 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 Facebook do the fork then? 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".

> 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.
 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.

> 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.

>> 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.

Regards,
Laszlo/GCS
[1] dget -x http://www.barcikacomp.hu/gcs/libevent_1.4.14b-stable-1.dsc
[2] http://software.schmorp.de/pkg/libeio.html
[3] http://software.schmorp.de/pkg/libev.html



Information forwarded to debian-bugs-dist@lists.debian.org, wnpp@debian.org:
Bug#727085; Package wnpp. (Tue, 05 Nov 2013 22:30:13 GMT) Full text and rfc822 format available.

Acknowledgement sent to Paul Tarjan <pt@fb.com>:
Extra info received and forwarded to list. Copy sent to wnpp@debian.org. (Tue, 05 Nov 2013 22:30:13 GMT) Full text and rfc822 format available.

Message #40 received at 727085@bugs.debian.org (full text, mbox):

From: Paul Tarjan <pt@fb.com>
To: László Böszörményi (GCS) <gcs@debian.org>, "570709@bugs.debian.org" <570709@bugs.debian.org>, "727085@bugs.debian.org" <727085@bugs.debian.org>
Subject: Re: Bug#570709: packaging hhvm
Date: Tue, 5 Nov 2013 22:26:46 +0000
>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




Information forwarded to debian-bugs-dist@lists.debian.org, wnpp@debian.org, Paul Tarjan <pt@fb.com>:
Bug#727085; Package wnpp. (Wed, 06 Nov 2013 13:51:08 GMT) Full text and rfc822 format available.

Acknowledgement sent to László Böszörményi (GCS) <gcs@debian.org>:
Extra info received and forwarded to list. Copy sent to wnpp@debian.org, Paul Tarjan <pt@fb.com>. (Wed, 06 Nov 2013 13:51:08 GMT) Full text and rfc822 format available.

Message #45 received at 727085@bugs.debian.org (full text, mbox):

From: László Böszörményi (GCS) <gcs@debian.org>
To: Paul Tarjan <pt@fb.com>
Cc: "570709@bugs.debian.org" <570709@bugs.debian.org>, "727085@bugs.debian.org" <727085@bugs.debian.org>
Subject: Re: Bug#570709: packaging hhvm
Date: Wed, 6 Nov 2013 14:47:14 +0100
On Tue, Nov 5, 2013 at 11:26 PM, Paul Tarjan <pt@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



Information forwarded to debian-bugs-dist@lists.debian.org, wnpp@debian.org:
Bug#727085; Package wnpp. (Wed, 06 Nov 2013 16:54:07 GMT) Full text and rfc822 format available.

Acknowledgement sent to Paul Tarjan <pt@fb.com>:
Extra info received and forwarded to list. Copy sent to wnpp@debian.org. (Wed, 06 Nov 2013 16:54:07 GMT) Full text and rfc822 format available.

Message #50 received at 727085@bugs.debian.org (full text, mbox):

From: Paul Tarjan <pt@fb.com>
To: László Böszörményi (GCS) <gcs@debian.org>
Cc: "570709@bugs.debian.org" <570709@bugs.debian.org>, "727085@bugs.debian.org" <727085@bugs.debian.org>
Subject: Re: Bug#570709: packaging hhvm
Date: Wed, 6 Nov 2013 16:51:46 +0000
>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::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.

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.




Information forwarded to debian-bugs-dist@lists.debian.org, wnpp@debian.org, Paul Tarjan <pt@fb.com>:
Bug#727085; Package wnpp. (Wed, 06 Nov 2013 20:09:07 GMT) Full text and rfc822 format available.

Acknowledgement sent to László Böszörményi (GCS) <gcs@debian.org>:
Extra info received and forwarded to list. Copy sent to wnpp@debian.org, Paul Tarjan <pt@fb.com>. (Wed, 06 Nov 2013 20:09:07 GMT) Full text and rfc822 format available.

Message #55 received at 727085@bugs.debian.org (full text, mbox):

From: László Böszörményi (GCS) <gcs@debian.org>
To: Paul Tarjan <pt@fb.com>
Cc: "570709@bugs.debian.org" <570709@bugs.debian.org>, "727085@bugs.debian.org" <727085@bugs.debian.org>
Subject: Re: Bug#570709: packaging hhvm
Date: Wed, 6 Nov 2013 21:03:47 +0100
On Wed, Nov 6, 2013 at 5:51 PM, Paul Tarjan <pt@fb.com> wrote:
>>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.
 Please do realize we are talking about a FB fork. Reasons are:
- upstream moved forward (rewrote the API and has 2.x version)
- upstream no longer support 1.y, but FB still needs it -> 'owner' of
the code transition to FB
- 1.y is for FB only, any compile or runtime bug affects its source: HHVM
- need a central place to report bugs to FB without mixing original
upstream (2.x) bugs.
Considering the above, FB needs an own place to host 1.y source.

>>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?
 Will do. As I see, the first step should be to package folly.

>>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.
 Removed that chroot, but can be recreated anytime. But please,
remember that all uploads go to unstable and should be built in an
up-to-date unstable chroot. It makes the mentioned page highly
outdated as Sid has gcc/g++ 4.8, PHP5 5.5.5 (not 5.4.4) and Boost
libraries 1.54 (not 1.49) among others.

>>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.
 I don't know (yet) if any patch is needed to use the external
libraries; but 'rm -rf hphp/third_party/' would be the start. For me
several libraries can be installed with apt-get like:
apt-get install liblz4-dev libsqlite3-dev libdouble-conversion-dev
... maybe others as well. Thus they are available easily.



Information forwarded to debian-bugs-dist@lists.debian.org, wnpp@debian.org, Paul Tarjan <pt@fb.com>:
Bug#727085; Package wnpp. (Sat, 09 Nov 2013 20:33:07 GMT) Full text and rfc822 format available.

Acknowledgement sent to Francesco Poli <invernomuto@paranoici.org>:
Extra info received and forwarded to list. Copy sent to wnpp@debian.org, Paul Tarjan <pt@fb.com>. (Sat, 09 Nov 2013 20:33:07 GMT) Full text and rfc822 format available.

Message #60 received at 727085@bugs.debian.org (full text, mbox):

From: Francesco Poli <invernomuto@paranoici.org>
To: 727085@bugs.debian.org, Paul Tarjan <pt@fb.com>, 570709@bugs.debian.org, László Böszörményi (GCS) <gcs@debian.org>
Subject: hhvm / hiphop-php: will it be rejected by Debian due to inappropriate licensing?
Date: Sat, 9 Nov 2013 21:28:59 +0100
[Message part 1 (text/plain, inline)]
Hello Paul and hello László,
I've just stumbled upon your ITP bugs about hhvm and hiphop-php.

First of all, are these two bugs about the same piece of software?
Should the two bugs be merged?

This piece of software seems to be interesting: thanks for working
on its inclusion into Debian.

I have a concern, though.
If I understand correctly, this project is an interpreter or (JIT)
compiler for the PHP language, but is not PHP itself (that is to say,
it's not the reference implementation of the PHP language, developed
and copyrighted by the PHP Group).
Nonetheless, it is released under the terms of the PHP License v3.01
and the Zend Engine License.

As far as I know, this is ground for a reject from Debian.
Please see https://ftp-master.debian.org/REJECT-FAQ.html
("PHP License" point).

I would strongly recommend to persuade the copyright holder (Facebook,
Inc.) to re-license under more general DFSG-free terms, such as the
3-clause BSD license: https://spdx.org/licenses/BSD-3-Clause

Please let me know.

Thanks for your time!
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
[Message part 2 (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, wnpp@debian.org, Paul Tarjan <pt@fb.com>:
Bug#727085; Package wnpp. (Mon, 11 Nov 2013 09:54:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to László Böszörményi (GCS) <gcs@debian.org>:
Extra info received and forwarded to list. Copy sent to wnpp@debian.org, Paul Tarjan <pt@fb.com>. (Mon, 11 Nov 2013 09:54:04 GMT) Full text and rfc822 format available.

Message #65 received at 727085@bugs.debian.org (full text, mbox):

From: László Böszörményi (GCS) <gcs@debian.org>
To: Francesco Poli <invernomuto@paranoici.org>, Paul Tarjan <pt@fb.com>
Cc: "727085@bugs.debian.org" <727085@bugs.debian.org>, Debian Bug Tracking System <control@bugs.debian.org>
Subject: Re: hhvm / hiphop-php: will it be rejected by Debian due to inappropriate licensing?
Date: Mon, 11 Nov 2013 10:51:56 +0100
merge 570709 727085
thanks

On Sat, Nov 9, 2013 at 9:28 PM, Francesco Poli
<invernomuto@paranoici.org> wrote:
> I've just stumbled upon your ITP bugs about hhvm and hiphop-php.
>
> First of all, are these two bugs about the same piece of software?
> Should the two bugs be merged?
 The bugs were left separated so users can find it with both names
(HHVM and hiphop-php). But well, merging now.

> This piece of software seems to be interesting: thanks for working
> on its inclusion into Debian.
 Sure, but it seems it won't make it. libevent 1.x needs a real
maintainer. Until now, I don't see Facebook takes any step towards it.
Is there any update, Paul?

> I have a concern, though.
> If I understand correctly, this project is an interpreter or (JIT)
> compiler for the PHP language, but is not PHP itself (that is to say,
> it's not the reference implementation of the PHP language, developed
> and copyrighted by the PHP Group).
> Nonetheless, it is released under the terms of the PHP License v3.01
> and the Zend Engine License.
 Good catch. The original bugreport (#727085) states BSD licensing as
well, but the source tree shows PHP License v3.01 only.

> I would strongly recommend to persuade the copyright holder (Facebook,
> Inc.) to re-license under more general DFSG-free terms, such as the
> 3-clause BSD license: https://spdx.org/licenses/BSD-3-Clause
>
> Please let me know.
 It's up to Paul if he can make it inside Facebook.

Regards,
Laszlo/GCS



Owner changed from Paul Tarjan <pt@fb.com> to László Böszörményi (GCS) <gcs@debian.org>. Request was from László Böszörményi (GCS) <gcs@debian.org> to control@bugs.debian.org. (Mon, 11 Nov 2013 12:39:08 GMT) Full text and rfc822 format available.

Merged 570709 727085 Request was from László Böszörményi (GCS) <gcs@debian.org> to control@bugs.debian.org. (Mon, 11 Nov 2013 12:39:09 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, wnpp@debian.org, László Böszörményi (GCS) <gcs@debian.org>:
Bug#727085; Package wnpp. (Mon, 16 Dec 2013 20:30:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Paul Tarjan <pt@fb.com>:
Extra info received and forwarded to list. Copy sent to wnpp@debian.org, László Böszörményi (GCS) <gcs@debian.org>. (Mon, 16 Dec 2013 20:30:04 GMT) Full text and rfc822 format available.

Message #74 received at 727085@bugs.debian.org (full text, mbox):

From: Paul Tarjan <pt@fb.com>
To: "727085@bugs.debian.org" <727085@bugs.debian.org>
Subject: Now we don't depend on the weird libevent patch
Date: Mon, 16 Dec 2013 19:43:37 +0000
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




Information forwarded to debian-bugs-dist@lists.debian.org, wnpp@debian.org, László Böszörményi (GCS) <gcs@debian.org>:
Bug#727085; Package wnpp. (Sat, 21 Dec 2013 17:09:09 GMT) Full text and rfc822 format available.

Acknowledgement sent to Francesco Poli <invernomuto@paranoici.org>:
Extra info received and forwarded to list. Copy sent to wnpp@debian.org, László Böszörményi (GCS) <gcs@debian.org>. (Sat, 21 Dec 2013 17:09:09 GMT) Full text and rfc822 format available.

Message #79 received at 727085@bugs.debian.org (full text, mbox):

From: Francesco Poli <invernomuto@paranoici.org>
To: Paul Tarjan <pt@fb.com>
Cc: 727085@bugs.debian.org, László Böszörményi (GCS) <gcs@debian.org>
Subject: Re: Now we don't depend on the weird libevent patch
Date: Sat, 21 Dec 2013 17:59:55 +0100
[Message part 1 (text/plain, inline)]
On Mon, 16 Dec 2013 19:43:37 +0000 Paul Tarjan wrote:

> I'd like to revive this bug now that our libevent plans are solidified.

Good, thanks for getting back to work on the inclusion of hhvm into
Debian!

[...]
> 
> 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.

> 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.

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.

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
[Message part 2 (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, wnpp@debian.org, László Böszörményi (GCS) <gcs@debian.org>:
Bug#727085; Package wnpp. (Sat, 21 Dec 2013 21:15:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Paul Tarjan <pt@fb.com>:
Extra info received and forwarded to list. Copy sent to wnpp@debian.org, László Böszörményi (GCS) <gcs@debian.org>. (Sat, 21 Dec 2013 21:15:04 GMT) Full text and rfc822 format available.

Message #84 received at 727085@bugs.debian.org (full text, mbox):

From: Paul Tarjan <pt@fb.com>
To: Francesco Poli <invernomuto@paranoici.org>
Cc: "727085@bugs.debian.org" <727085@bugs.debian.org>, László Böszörményi <gcs@debian.org>
Subject: Re: Now we don't depend on the weird libevent patch
Date: Sat, 21 Dec 2013 20:42:37 +0000
>> 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



Information forwarded to debian-bugs-dist@lists.debian.org, wnpp@debian.org, László Böszörményi (GCS) <gcs@debian.org>:
Bug#727085; Package wnpp. (Sat, 21 Dec 2013 23:09:09 GMT) Full text and rfc822 format available.

Acknowledgement sent to Francesco Poli <invernomuto@paranoici.org>:
Extra info received and forwarded to list. Copy sent to wnpp@debian.org, László Böszörményi (GCS) <gcs@debian.org>. (Sat, 21 Dec 2013 23:09:09 GMT) Full text and rfc822 format available.

Message #89 received at 727085@bugs.debian.org (full text, mbox):

From: Francesco Poli <invernomuto@paranoici.org>
To: Paul Tarjan <pt@fb.com>
Cc: 727085@bugs.debian.org, László Böszörményi <gcs@debian.org>
Subject: Re: Now we don't depend on the weird libevent patch
Date: Sun, 22 Dec 2013 00:03:38 +0100
On Sat, 21 Dec 2013 20:42:37 +0000 Paul Tarjan wrote:

> That rejection reason is pretty squarely aimed at people writing
> applications in the PHP language and makes sense for them.

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

[...]
> 
> 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.

Please let me understand: do you mean that hhvm includes code derived
from the reference PHP implementation published and copyrighted by the
PHP Group?


-- 
 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



Information forwarded to debian-bugs-dist@lists.debian.org, wnpp@debian.org, László Böszörményi (GCS) <gcs@debian.org>:
Bug#727085; Package wnpp. (Sat, 21 Dec 2013 23:12:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to Paul Tarjan <pt@fb.com>:
Extra info received and forwarded to list. Copy sent to wnpp@debian.org, László Böszörményi (GCS) <gcs@debian.org>. (Sat, 21 Dec 2013 23:12:05 GMT) Full text and rfc822 format available.

Message #94 received at 727085@bugs.debian.org (full text, mbox):

From: Paul Tarjan <pt@fb.com>
To: Francesco Poli <invernomuto@paranoici.org>
Cc: "727085@bugs.debian.org" <727085@bugs.debian.org>, László Böszörményi <gcs@debian.org>
Subject: Re: Now we don't depend on the weird libevent patch
Date: Sat, 21 Dec 2013 23:09:18 +0000
>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




Information forwarded to debian-bugs-dist@lists.debian.org, wnpp@debian.org, László Böszörményi (GCS) <gcs@debian.org>:
Bug#727085; Package wnpp. (Sun, 22 Dec 2013 11:12:09 GMT) Full text and rfc822 format available.

Acknowledgement sent to Francesco Poli <invernomuto@paranoici.org>:
Extra info received and forwarded to list. Copy sent to wnpp@debian.org, László Böszörményi (GCS) <gcs@debian.org>. (Sun, 22 Dec 2013 11:12:09 GMT) Full text and rfc822 format available.

Message #99 received at 727085@bugs.debian.org (full text, mbox):

From: Francesco Poli <invernomuto@paranoici.org>
To: Paul Tarjan <pt@fb.com>
Cc: "727085@bugs.debian.org" <727085@bugs.debian.org>, László Böszörményi <gcs@debian.org>
Subject: Re: Now we don't depend on the weird libevent patch
Date: Sun, 22 Dec 2013 12:08:01 +0100
[Message part 1 (text/plain, inline)]
On Sat, 21 Dec 2013 23:09:18 +0000 Paul Tarjan wrote:

[...]
> What would you like me to do?

Since, as you said, hhvm includes code derived from the reference PHP
implementation copyrighted by the PHP Group, I am afraid that it
wouldn't be trivial to get rid of the PHP License...

Would it be feasible to replace the code derived from the official PHP
with an independent clean room re-implementation released under the
terms of the 3-clause BSD license?

Otherwise, I don't see many other strategies, unless you manage to
persuade the PHP Group to re-license the official PHP under more
general and DFSG-free terms, such as the 3-clause BSD license...


That's my own viewpoint on this subject.


-- 
 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
[Message part 2 (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, wnpp@debian.org, László Böszörményi (GCS) <gcs@debian.org>:
Bug#727085; Package wnpp. (Sun, 29 Dec 2013 14:24:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Faidon Liambotis <paravoid@debian.org>:
Extra info received and forwarded to list. Copy sent to wnpp@debian.org, László Böszörményi (GCS) <gcs@debian.org>. (Sun, 29 Dec 2013 14:24:05 GMT) Full text and rfc822 format available.

Message #104 received at 727085@bugs.debian.org (full text, mbox):

From: Faidon Liambotis <paravoid@debian.org>
To: Francesco Poli <invernomuto@paranoici.org>, 727085@bugs.debian.org
Cc: Paul Tarjan <pt@fb.com>, László Böszörményi <gcs@debian.org>
Subject: Re: Bug#727085: Now we don't depend on the weird libevent patch
Date: Sun, 29 Dec 2013 14:46:50 +0100
On Sun, Dec 22, 2013 at 12:03:38AM +0100, Francesco Poli wrote:
>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

Just to clarify, since Paul may not be accustomed with Debian's
structure or your involvement: this is your opinion but you're not a
member of the Debian project and you're certainly not the decision maker
for DFSG-freeness.

The maintainer (and, possibly, sponsoring Debian Developer) is the first
line of defense, and ultimately the decision is up to the ftp-master
team[1] as part of the power of processing the NEW queue and accepting
packages into Debian, a power that is delegated from the project leader.

PHP is in the archive and is licensed under the PHP License to my
knowledge, so the current ftp-masters' stance is that it's a perfectly
acceptable license for inclusion into Debian.

There is zero evidence suggesting that HHVM is not going to be accepted
in Debian for the licensing reasons that you stated and there is, in
fact, evidence to the contrary. Please avoid suggesting so -or if you
do, explain that you're not part of the decision process- and possibly
frightening perfectly good upstreams, or asking them to do more work,
especially when they've proved themselves to be very willing to
collaborate with us.

Regards,
Faidon

1: https://wiki.debian.org/Teams/FTPMaster



Information forwarded to debian-bugs-dist@lists.debian.org, wnpp@debian.org:
Bug#727085; Package wnpp. (Sun, 29 Dec 2013 14:27:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to László Böszörményi (GCS) <gcs@debian.org>:
Extra info received and forwarded to list. Copy sent to wnpp@debian.org. (Sun, 29 Dec 2013 14:27:05 GMT) Full text and rfc822 format available.

Message #109 received at 727085@bugs.debian.org (full text, mbox):

From: László Böszörményi (GCS) <gcs@debian.org>
To: Faidon Liambotis <paravoid@debian.org>
Cc: Francesco Poli <invernomuto@paranoici.org>, "727085@bugs.debian.org" <727085@bugs.debian.org>, Paul Tarjan <pt@fb.com>
Subject: Re: Bug#727085: Now we don't depend on the weird libevent patch
Date: Sun, 29 Dec 2013 15:22:09 +0100
On Sun, Dec 29, 2013 at 2:46 PM, Faidon Liambotis <paravoid@debian.org> wrote:
> On Sun, Dec 22, 2013 at 12:03:38AM +0100, Francesco Poli wrote:
>> 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
 That's seems to be an old email, things may changed a bit since then.

> Just to clarify, since Paul may not be accustomed with Debian's
> structure or your involvement: this is your opinion but you're not a
> member of the Debian project and you're certainly not the decision maker
> for DFSG-freeness.
 It seems he _is_ connected with Debian. At least apt-listbugs[1]
developed and maintained by him.

> PHP is in the archive and is licensed under the PHP License to my
> knowledge, so the current ftp-masters' stance is that it's a perfectly
> acceptable license for inclusion into Debian.
 I think he meant PHP License is not free for _other_ software than
PHP itself. But I'm neither a legal person and will let the FTP
Masters decide on this. I know one of them personally, may ask him in
advance for a legal standpoint.
I'm still interested about HHVM, will retry its packaging next year.

Regards,
Laszlo/GCS
[1] http://packages.qa.debian.org/a/apt-listbugs.html



Information forwarded to debian-bugs-dist@lists.debian.org, wnpp@debian.org, László Böszörményi (GCS) <gcs@debian.org>:
Bug#727085; Package wnpp. (Sun, 29 Dec 2013 14:54:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Francesco Poli <invernomuto@paranoici.org>:
Extra info received and forwarded to list. Copy sent to wnpp@debian.org, László Böszörményi (GCS) <gcs@debian.org>. (Sun, 29 Dec 2013 14:54:04 GMT) Full text and rfc822 format available.

Message #114 received at 727085@bugs.debian.org (full text, mbox):

From: Francesco Poli <invernomuto@paranoici.org>
To: Faidon Liambotis <paravoid@debian.org>
Cc: 727085@bugs.debian.org, Paul Tarjan <pt@fb.com>, László Böszörményi <gcs@debian.org>
Subject: Re: Bug#727085: Now we don't depend on the weird libevent patch
Date: Sun, 29 Dec 2013 15:50:30 +0100
[Message part 1 (text/plain, inline)]
On Sun, 29 Dec 2013 14:46:50 +0100 Faidon Liambotis wrote:

> On Sun, Dec 22, 2013 at 12:03:38AM +0100, Francesco Poli wrote:
> >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
> 
> Just to clarify, since Paul may not be accustomed with Debian's
> structure or your involvement: this is your opinion

Sure, that's why I said "personally".

I also added "but that's another story", meaning that my side-note
talked about a fact that will probably have *no* effect on Debian
decision-making process. 

> but you're not a
> member of the Debian project

True: I could have said that more explicitly, even though I have never
claimed otherwise.
I apologize if the lack of explicit clarification caused any
confusion about this.

> and you're certainly not the decision maker
> for DFSG-freeness.

Once again true: I just pointed out a well known rejection reason that,
*in my own personal opinion*, could apply to the present case.

> 
> The maintainer (and, possibly, sponsoring Debian Developer) is the first
> line of defense, and ultimately the decision is up to the ftp-master
> team[...] as part of the power of processing the NEW queue and accepting
> packages into Debian, a power that is delegated from the project leader.

That's my understanding of Debian procedures, too.

> 
> PHP is in the archive and is licensed under the PHP License to my
> knowledge, so the current ftp-masters' stance is that it's a perfectly
> acceptable license for inclusion into Debian.

Yes, ftp-masters clearly think that the reference PHP implementation
copyrighted by the PHP Group is acceptable for Debian main.
I personally disagree, but, as I said, that's another story...

> 
> There is zero evidence suggesting that HHVM is not going to be accepted
> in Debian for the licensing reasons that you stated and there is, in
> fact, evidence to the contrary. Please avoid suggesting so -or if you
> do, explain that you're not part of the decision process- and possibly
> frightening perfectly good upstreams, or asking them to do more work,
> especially when they've proved themselves to be very willing to
> collaborate with us.

I am not sure I agree with you on this.
In my *own personal* opinion, there's a possibility that something which
is not the reference implementation of the PHP language (the
implementation developed and copyrighted by the PHP Group) could be
rejected, if licensed under the terms of the PHP License.
It's true that the cited reject FAQ talks about "PHP add-on packages",
but then explains that the problem is that "this license talks only
about PHP, the PHP Group, and includes Zend Engine, so its not
applicable to anything else".
See again https://ftp-master.debian.org/REJECT-FAQ.html

Hence, I expressed my concern about this *possible* rejection reason.

That fact that the parts licensed under the terms of the PHP License
are derived from PHP itself may mitigate the issue or even eliminate
it, from the ftp-masters' point of view.
But please note that this fact surfaced *after* I had expressed my
concern.

Frankly speaking, I don't see any clear evidence that this issue is
non-existent. I was concerned about it, so I thought I could warn
people upfront and see whether it could be (more or less easily) solved
or worked around.

Once again, I apologize if anything I said was not crystal clear and
generated any confusion.

I reiterate my gratitude to the friendly and helpful upstream
developers.


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
[Message part 2 (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, wnpp@debian.org, László Böszörményi (GCS) <gcs@debian.org>:
Bug#727085; Package wnpp. (Sun, 29 Dec 2013 15:21:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Francesco Poli <invernomuto@paranoici.org>:
Extra info received and forwarded to list. Copy sent to wnpp@debian.org, László Böszörményi (GCS) <gcs@debian.org>. (Sun, 29 Dec 2013 15:21:04 GMT) Full text and rfc822 format available.

Message #119 received at 727085@bugs.debian.org (full text, mbox):

From: Francesco Poli <invernomuto@paranoici.org>
To: László Böszörményi (GCS) <gcs@debian.org>
Cc: Faidon Liambotis <paravoid@debian.org>, "727085@bugs.debian.org" <727085@bugs.debian.org>, Paul Tarjan <pt@fb.com>
Subject: Re: Bug#727085: Now we don't depend on the weird libevent patch
Date: Sun, 29 Dec 2013 16:17:17 +0100
[Message part 1 (text/plain, inline)]
On Sun, 29 Dec 2013 15:22:09 +0100 László Böszörményi (GCS) wrote:

> On Sun, Dec 29, 2013 at 2:46 PM, Faidon Liambotis <paravoid@debian.org> wrote:
> > On Sun, Dec 22, 2013 at 12:03:38AM +0100, Francesco Poli wrote:
> >> 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
>  That's seems to be an old email, things may changed a bit since then.

Not much, as far as I know.

The current version of the PHP License is still 3.01 and I am not aware
of any other licensing exception or additional permission granted by
the PHP Group over their PHP reference implementation.

I think that my old license analysis still holds.

> 
> > Just to clarify, since Paul may not be accustomed with Debian's
> > structure or your involvement: this is your opinion but you're not a
> > member of the Debian project and you're certainly not the decision maker
> > for DFSG-freeness.
>  It seems he _is_ connected with Debian. At least apt-listbugs[...]
> developed and maintained by him.

Yes, I am the current maintainer and developer of apt-listbugs, but
I am *not* a Debian Project member: I am an external contributor.

> 
> > PHP is in the archive and is licensed under the PHP License to my
> > knowledge, so the current ftp-masters' stance is that it's a perfectly
> > acceptable license for inclusion into Debian.
>  I think he meant PHP License is not free for _other_ software than
> PHP itself.

Actually, I personally think even PHP itself is non-free.
But, as previously mentioned, ftp-masters disagree with me: they think
the reference PHP implementation is acceptable for Debian main.

> But I'm neither a legal person and will let the FTP
> Masters decide on this. I know one of them personally, may ask him in
> advance for a legal standpoint.
> I'm still interested about HHVM, will retry its packaging next year.

Good, thanks again.

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
[Message part 2 (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, wnpp@debian.org, László Böszörményi (GCS) <gcs@debian.org>:
Bug#727085; Package wnpp. (Sun, 29 Dec 2013 22:45:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to Paul Tarjan <pt@fb.com>:
Extra info received and forwarded to list. Copy sent to wnpp@debian.org, László Böszörményi (GCS) <gcs@debian.org>. (Sun, 29 Dec 2013 22:45:05 GMT) Full text and rfc822 format available.

Message #124 received at 727085@bugs.debian.org (full text, mbox):

From: Paul Tarjan <pt@fb.com>
To: Francesco Poli <invernomuto@paranoici.org>, László Böszörményi <gcs@debian.org>
Cc: Faidon Liambotis <paravoid@debian.org>, "727085@bugs.debian.org" <727085@bugs.debian.org>
Subject: Re: Bug#727085: Now we don't depend on the weird libevent patch
Date: Sun, 29 Dec 2013 22:42:43 +0000
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




Information forwarded to debian-bugs-dist@lists.debian.org, wnpp@debian.org, László Böszörményi (GCS) <gcs@debian.org>:
Bug#727085; Package wnpp. (Sun, 29 Dec 2013 23:00:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Francesco Poli <invernomuto@paranoici.org>:
Extra info received and forwarded to list. Copy sent to wnpp@debian.org, László Böszörményi (GCS) <gcs@debian.org>. (Sun, 29 Dec 2013 23:00:04 GMT) Full text and rfc822 format available.

Message #129 received at 727085@bugs.debian.org (full text, mbox):

From: Francesco Poli <invernomuto@paranoici.org>
To: Paul Tarjan <pt@fb.com>
Cc: László Böszörményi <gcs@debian.org>, Faidon Liambotis <paravoid@debian.org>, "727085@bugs.debian.org" <727085@bugs.debian.org>
Subject: Re: Bug#727085: Now we don't depend on the weird libevent patch
Date: Sun, 29 Dec 2013 23:57:05 +0100
[Message part 1 (text/plain, inline)]
On Sun, 29 Dec 2013 22:42:43 +0000 Paul Tarjan wrote:

[...]
> Francesco, I honestly thought you
> were speaking officially and we would be rejected.

Once again, if I gave the impression to speak as an official Debian
Project spokesperson, I apologize for the confusion.
My messages were full of "in my opinion", "I think", "Personally", and
so forth: I thought it was clear I was just expression my own personal
viewpoint.

> When you didn't reply
> to my email asking "What should I do?" I didn't know what to think...

I think I did reply...

Anyway, sorry if anything I said caused confusion.


-- 
 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
[Message part 2 (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, wnpp@debian.org:
Bug#727085; Package wnpp. (Mon, 30 Dec 2013 00:00:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to László Böszörményi (GCS) <gcs@debian.org>:
Extra info received and forwarded to list. Copy sent to wnpp@debian.org. (Mon, 30 Dec 2013 00:00:04 GMT) Full text and rfc822 format available.

Message #134 received at 727085@bugs.debian.org (full text, mbox):

From: László Böszörményi (GCS) <gcs@debian.org>
To: Paul Tarjan <pt@fb.com>, "727085@bugs.debian.org" <727085@bugs.debian.org>
Cc: Francesco Poli <invernomuto@paranoici.org>, Faidon Liambotis <paravoid@debian.org>
Subject: Re: Bug#727085: Now we don't depend on the weird libevent patch
Date: Mon, 30 Dec 2013 00:56:48 +0100
On Sun, Dec 29, 2013 at 11:42 PM, Paul Tarjan <pt@fb.com> wrote:
> 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?
 This is correct.

> 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
 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, ...

> 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.
 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.

> Lastly, Laszlo, we should talk about how I can help with packaging.
 Do you have a packager position there, at FB? :) At least ATM I've
two places to work for. At Debian I've more than a hundred packages
and twenty to do. Especially that I have to work more or less constant
from 31st 06:00 am to 2nd 04:20 pm. Will be hard, thus I'll start
again with HHVM next year. 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):
-- 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 --

> 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?
 I've a GitHub account, can follow your release cycle. Debian can
automatically track upstream releases even.

> Or should I setup a mailing list and
> always email that when I push?
 That's up to you, several projects have an announce mailing list. I
don't need it strictly.

> 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 made one or two packages for CentOS in the past, but we'll see
that later.

I'm off for sleeping.
Laszlo/GCS



Information forwarded to debian-bugs-dist@lists.debian.org, wnpp@debian.org, László Böszörményi (GCS) <gcs@debian.org>:
Bug#727085; Package wnpp. (Mon, 30 Dec 2013 19:39:15 GMT) Full text and rfc822 format available.

Acknowledgement sent to Paul Tarjan <pt@fb.com>:
Extra info received and forwarded to list. Copy sent to wnpp@debian.org, László Böszörményi (GCS) <gcs@debian.org>. (Mon, 30 Dec 2013 19:39:15 GMT) Full text and rfc822 format available.

Message #139 received at 727085@bugs.debian.org (full text, mbox):

From: Paul Tarjan <pt@fb.com>
To: László Böszörményi (GCS) <gcs@debian.org>, "727085@bugs.debian.org" <727085@bugs.debian.org>
Cc: Francesco Poli <invernomuto@paranoici.org>, Faidon Liambotis <paravoid@debian.org>
Subject: Re: Bug#727085: Now we don't depend on the weird libevent patch
Date: Mon, 30 Dec 2013 19:36:29 +0000
>> 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




Information forwarded to debian-bugs-dist@lists.debian.org, wnpp@debian.org, László Böszörményi (GCS) <gcs@debian.org>:
Bug#727085; Package wnpp. (Tue, 31 Dec 2013 02:48:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to Faidon Liambotis <paravoid@debian.org>:
Extra info received and forwarded to list. Copy sent to wnpp@debian.org, László Böszörményi (GCS) <gcs@debian.org>. (Tue, 31 Dec 2013 02:48:05 GMT) Full text and rfc822 format available.

Message #144 received at 727085@bugs.debian.org (full text, mbox):

From: Faidon Liambotis <paravoid@debian.org>
To: László Böszörményi (GCS) <gcs@debian.org>
Cc: Paul Tarjan <pt@fb.com>, 727085@bugs.debian.org
Subject: Re: Bug#727085: Now we don't depend on the weird libevent patch
Date: Tue, 31 Dec 2013 03:45:23 +0100
On Mon, Dec 30, 2013 at 12:56:48AM +0100, László Böszörményi (GCS) wrote:
> 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.

Two weeks is probably too often for Debian but time-based releases in
general (rather than "important bugfix") are fairly common. I think the
original idea of accumulating multiple sprints into one "community"
release is a great path forward. The proposal for 8-week releases sounds
just fine to me.

Looking a bit further ahead, Debian will release a new stable in
something like a year from now, and will have to support whatever
happens to be in testing by November 6th, for at least the release of
next stable + one year (i.e. for about 3-4 years), without the ability
to bump into newer HHVM versions. Some upstreams tend to release some
"LTS" releases for such uses, potentially labeling one of their
incremental releases as LTS. This isn't a prerequisite, but it's good to
actually have some longer stable/security management in mind when
planning your release schedule.

>> Lastly, Laszlo, we should talk about how I can help with packaging.
> Do you have a packager position there, at FB? :) At least ATM I've
>two places to work for. At Debian I've more than a hundred packages
>and twenty to do. Especially that I have to work more or less constant
>from 31st 06:00 am to 2nd 04:20 pm. Will be hard, thus I'll start
>again with HHVM next year. 

Well, noone really forced you to ITP this :) You definitely seem to have
your hands full, there's no need for you to take on more than you're
able to handle. If you're too busy, I can just takeover this ITP, just
say so.

>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):

Which section of the policy mandates that? I'd be very suprised if the
existing PHP policy covers alternative interpeters.

>-- cut --
> HipHop VM (HHVM) is a new open-source virtual machine designed for executing

s/a new/an/ (redundant for the description)

> 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.

The last two lines are incorrect considering the new FastCGI mode of
operation, which AIUI will be the only one actually offered by the
package, as the embedded standalone webserver requires patches to
libevent.

> 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. 

Ubuntu automatically syncs from Debian, there's no need for Ubuntu
maintainers to do anything. And yes, there's tons of other Debian &
Ubuntu derivatives that also regularly sync from those two.

Regards,
Faidon



Information forwarded to debian-bugs-dist@lists.debian.org, wnpp@debian.org:
Bug#727085; Package wnpp. (Tue, 31 Dec 2013 10:03:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to László Böszörményi (GCS) <gcs@debian.org>:
Extra info received and forwarded to list. Copy sent to wnpp@debian.org. (Tue, 31 Dec 2013 10:03:04 GMT) Full text and rfc822 format available.

Message #149 received at 727085@bugs.debian.org (full text, mbox):

From: László Böszörményi (GCS) <gcs@debian.org>
To: Faidon Liambotis <paravoid@debian.org>
Cc: Paul Tarjan <pt@fb.com>, "727085@bugs.debian.org" <727085@bugs.debian.org>
Subject: Re: Bug#727085: Now we don't depend on the weird libevent patch
Date: Tue, 31 Dec 2013 10:59:55 +0100
On Tue, Dec 31, 2013 at 3:45 AM, Faidon Liambotis <paravoid@debian.org> wrote:
> On Mon, Dec 30, 2013 at 12:56:48AM +0100, László Böszörményi (GCS) wrote:
> Two weeks is probably too often for Debian but time-based releases in
> general (rather than "important bugfix") are fairly common. I think the
> original idea of accumulating multiple sprints into one "community"
> release is a great path forward. The proposal for 8-week releases sounds
> just fine to me.
 I meant there's no force on FB to do "community" releases. Two weeks
releases is a bit fast, right. On the other hand as I see the releases
get QA care. Upload bigger changes (8 weeks time) may be worse as they
may contain more backward incompatible changes. Also the maintainer
can decide how s/he uploads those releases. Maybe those will go to
experimental and say, every month after one more week test time the
package would be uploaded to Sid. Then users can get the fast moving
package in experimental with the more tested, monthly updates in Sid.
Maybe just follow upstream changelog and upload new releases when s/he
thinks so (new feature, bugfix needed for Debian - but maybe just
backport that fix), etc.

> Some upstreams tend to release some
> "LTS" releases for such uses, potentially labeling one of their
> incremental releases as LTS. This isn't a prerequisite, but it's good to
> actually have some longer stable/security management in mind when
> planning your release schedule.
 +1 on LTS releases; like Ubuntu does with its distribution.

> Well, noone really forced you to ITP this :) You definitely seem to have
> your hands full, there's no need for you to take on more than you're
> able to handle. If you're too busy, I can just takeover this ITP, just
> say so.
 I realize my lines sound worse than I wanted to. Yes, it's a bit hard
now, but my second work is project based and I expect to finish it in
a month or two. Some of my packages are team or co-maintained. I work
48 hours + a normal day because we had too many free days left for
December. It's me who let others go on holiday and take off their free
days. We are a group of eight persons, but due to the reason
mentioned, today only two of us are working. Tomorrow only me, but
from the 2nd of January everyone will be back on track.
Even today I've time to make a tea and drink it passionate or answer
my mails. Last but not least I've a half-baken package already.

>> 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):
>
> Which section of the policy mandates that? I'd be very suprised if the
> existing PHP policy covers alternative interpeters.
 To match _generic_ package names. It doesn't have any part about
interpeter. Also as Paul noted, the package should be named HHVM now.
The php-hhvm package name comes to my mind or just hhvm.

> The last two lines are incorrect considering the new FastCGI mode of
> operation, which AIUI will be the only one actually offered by the
> package, as the embedded standalone webserver requires patches to
> libevent.
 Sure, I've mentioned it was the _previous_ package description.

>> 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.
>
> Ubuntu automatically syncs from Debian, there's no need for Ubuntu
> maintainers to do anything.
 As I heard, it's semi-automatic. They have their transitions when
they don't sync everything and changes over Debian packaging that
needs manual adjustments. Also my package delaboratory is not in
Ubuntu for an unknown reason to me. It doesn't have any RC bug, not a
big or unsupportable one, built on all archs, etc.

Laszlo/GCS



Information forwarded to debian-bugs-dist@lists.debian.org, wnpp@debian.org:
Bug#727085; Package wnpp. (Fri, 03 Jan 2014 08:39:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to László Böszörményi (GCS) <gcs@debian.org>:
Extra info received and forwarded to list. Copy sent to wnpp@debian.org. (Fri, 03 Jan 2014 08:39:04 GMT) Full text and rfc822 format available.

Message #154 received at 727085@bugs.debian.org (full text, mbox):

From: László Böszörményi (GCS) <gcs@debian.org>
To: Paul Tarjan <pt@fb.com>
Cc: "727085@bugs.debian.org" <727085@bugs.debian.org>, Faidon Liambotis <paravoid@debian.org>
Subject: Re: Bug#727085: Now we don't depend on the weird libevent patch
Date: Fri, 3 Jan 2014 09:37:13 +0100
On Mon, Dec 30, 2013 at 8:36 PM, Paul Tarjan <pt@fb.com> wrote:
>>> 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.
 I can use Debian servers or an own GitHub repository for packaging,
no problem. Actually I think I'm ~90% ready with HHVM packaging. But
I've one problem with one of its dependency, folly. Steps to
reproduce:
1) Get an up-to-date Sid install.
2) git clone https://github.com/facebook/folly.git folly
3) as root:
apt-get install autoconf automake libtool
apt-get install libgoogle-glog-dev libgtest-dev
libdouble-conversion-dev libboost-thread-dev libboost-system-dev
4) cd folly/folly/
5) autoreconf -i
6) ./configure
[...]
checking for openlog in -lglog... yes
checking for getenv in -lgflags... yes
checking for boostlib >= 1.20.0... yes
checking whether the Boost::Thread library is available... yes
configure: error: Could not find a version of the library!

I can't make it go forward. :( It seems configure has an option
(--with-boost=no) to disable Boost libraries usage, but even then I
have the same output. I wonder if it finds the Boost::Thread library,
then what's version couldn't be found?
config.log does not help more:
[...]
configure:16701: checking whether the Boost::Thread library is available
configure:16733: g++ -c -pthread -std=gnu++0x -g -O2   conftest.cpp >&5
configure:16733: $? = 0
configure:16748: result: yes
configure:16921: error: Could not find a version of the library!

I think the conftest.cpp is this:
-- cut --
#include <boost/thread/thread.hpp>
int
main ()
{
boost::thread_group thrds;
  return 0;
  ;
  return 0;
}
-- cut --
While it has two return statements, it compiles just fine with:
$ g++ -o conftest conftest.cpp -lboost_thread -lboost_system
$ ./conftest
$

As last resort tried it with all Boost libraries installed, ie after:
# apt-get install libboost-all-dev

But it has the same error as a result. Any help is appreciated.
Laszlo/GCS



Information forwarded to debian-bugs-dist@lists.debian.org, wnpp@debian.org, László Böszörményi (GCS) <gcs@debian.org>:
Bug#727085; Package wnpp. (Sat, 04 Jan 2014 00:54:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Paul Tarjan <pt@fb.com>:
Extra info received and forwarded to list. Copy sent to wnpp@debian.org, László Böszörményi (GCS) <gcs@debian.org>. (Sat, 04 Jan 2014 00:54:04 GMT) Full text and rfc822 format available.

Message #159 received at 727085@bugs.debian.org (full text, mbox):

From: Paul Tarjan <pt@fb.com>
To: László Böszörményi (GCS) <gcs@debian.org>
Cc: "727085@bugs.debian.org" <727085@bugs.debian.org>, Faidon Liambotis <paravoid@debian.org>
Subject: Re: Bug#727085: Now we don't depend on the weird libevent patch
Date: Sat, 4 Jan 2014 00:51:38 +0000
> 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




Information forwarded to debian-bugs-dist@lists.debian.org, wnpp@debian.org:
Bug#727085; Package wnpp. (Sat, 04 Jan 2014 17:57:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to László Böszörményi (GCS) <gcs@debian.org>:
Extra info received and forwarded to list. Copy sent to wnpp@debian.org. (Sat, 04 Jan 2014 17:57:04 GMT) Full text and rfc822 format available.

Message #164 received at 727085@bugs.debian.org (full text, mbox):

From: László Böszörményi (GCS) <gcs@debian.org>
To: Paul Tarjan <pt@fb.com>
Cc: "727085@bugs.debian.org" <727085@bugs.debian.org>, Faidon Liambotis <paravoid@debian.org>
Subject: Re: Bug#727085: Now we don't depend on the weird libevent patch
Date: Sat, 4 Jan 2014 18:54:32 +0100
On Sat, Jan 4, 2014 at 1:51 AM, Paul Tarjan <pt@fb.com> wrote:
>>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/
 Thanks, it helped. I used $BOOST_LDFLAGS for testing, but that didn't
work. Anyway, folly is packaged and uploaded. HHVM is one small step
closer to be part of Debian.

Laszlo/GCS



Information forwarded to debian-bugs-dist@lists.debian.org, wnpp@debian.org, László Böszörményi (GCS) <gcs@debian.org>:
Bug#727085; Package wnpp. (Sat, 04 Jan 2014 18:00:07 GMT) Full text and rfc822 format available.

Acknowledgement sent to Faidon Liambotis <paravoid@debian.org>:
Extra info received and forwarded to list. Copy sent to wnpp@debian.org, László Böszörményi (GCS) <gcs@debian.org>. (Sat, 04 Jan 2014 18:00:07 GMT) Full text and rfc822 format available.

Message #169 received at 727085@bugs.debian.org (full text, mbox):

From: Faidon Liambotis <paravoid@debian.org>
To: "László Böszörményi (GCS)" <gcs@debian.org>, Paul Tarjan <pt@fb.com>
Cc: "727085@bugs.debian.org" <727085@bugs.debian.org>
Subject: Re: Bug#727085: Now we don't depend on the weird libevent patch
Date: Sat, 04 Jan 2014 19:58:29 +0200
On 01/04/14 19:54, László Böszörményi (GCS) wrote:
> On Sat, Jan 4, 2014 at 1:51 AM, Paul Tarjan <pt@fb.com> wrote:
>>> 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/
>   Thanks, it helped. I used $BOOST_LDFLAGS for testing, but that didn't
> work. Anyway, folly is packaged and uploaded. HHVM is one small step
> closer to be part of Debian.

Does folly have a stable ABI? I remember raising this with Paul some 
time ago and us deciding that embedding folly into the HHVM source would 
be the way to go, as there is really no stable interface between them.

Also, you're really supposed to file separate ITPs for separate packages 
(and file them *before* you make an upload).

Regards,
Faidon



Information forwarded to debian-bugs-dist@lists.debian.org, wnpp@debian.org:
Bug#727085; Package wnpp. (Sat, 04 Jan 2014 18:09:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to László Böszörményi (GCS) <gcs@debian.org>:
Extra info received and forwarded to list. Copy sent to wnpp@debian.org. (Sat, 04 Jan 2014 18:09:04 GMT) Full text and rfc822 format available.

Message #174 received at 727085@bugs.debian.org (full text, mbox):

From: László Böszörményi (GCS) <gcs@debian.org>
To: Faidon Liambotis <paravoid@debian.org>
Cc: Paul Tarjan <pt@fb.com>, "727085@bugs.debian.org" <727085@bugs.debian.org>
Subject: Re: Bug#727085: Now we don't depend on the weird libevent patch
Date: Sat, 4 Jan 2014 19:07:15 +0100
On Sat, Jan 4, 2014 at 6:58 PM, Faidon Liambotis <paravoid@debian.org> wrote:
> On 01/04/14 19:54, László Böszörményi (GCS) wrote:
>> Anyway, folly is packaged and uploaded. HHVM is one small step
>> closer to be part of Debian.
>
> Does folly have a stable ABI? I remember raising this with Paul some time
> ago and us deciding that embedding folly into the HHVM source would be the
> way to go, as there is really no stable interface between them.
 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.

> Also, you're really supposed to file separate ITPs for separate packages
> (and file them *before* you make an upload).
 ??? Please see its ITP[1]. I just noted the upload here. It's closed
by the changelog in the folly package if that will be accepted into
the archive.

Laszlo/GCS
[1] http://bugs.debian.org/734188



Information forwarded to debian-bugs-dist@lists.debian.org, wnpp@debian.org, László Böszörményi (GCS) <gcs@debian.org>:
Bug#727085; Package wnpp. (Sat, 04 Jan 2014 18:36:21 GMT) Full text and rfc822 format available.

Acknowledgement sent to Faidon Liambotis <paravoid@debian.org>:
Extra info received and forwarded to list. Copy sent to wnpp@debian.org, László Böszörményi (GCS) <gcs@debian.org>. (Sat, 04 Jan 2014 18:36:21 GMT) Full text and rfc822 format available.

Message #179 received at 727085@bugs.debian.org (full text, mbox):

From: Faidon Liambotis <paravoid@debian.org>
To: László Böszörményi (GCS) <gcs@debian.org>
Cc: Paul Tarjan <pt@fb.com>, 727085@bugs.debian.org, 734188@bugs.debian.org
Subject: Re: Bug#727085: Now we don't depend on the weird libevent patch
Date: Sat, 4 Jan 2014 20:28:24 +0200
On Sat, Jan 04, 2014 at 07:07:15PM +0100, László Böszörményi (GCS) wrote:
>> Does folly have a stable ABI? I remember raising this with Paul some 
>> time
>> ago and us deciding that embedding folly into the HHVM source would be the
>> way to go, as there is really no stable interface between them.
> 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.

If the ABI isn't stable, HHVM is the least of your problems. Non ABI 
stable libraries have really no place in Debian: you have to bump the 
SONAME, rename the package, go through NEW, binNMU all reverse 
dependencies, go through a testing transition etc. every time and that's 
*if* you detect the ABI breakage and it doesn't get silently undetected 
crashing reverse dependencies (= RC bug).

Check with your upstream (Paul? someone else?) if they're guranteeing 
ABI, and preferrably also tag versions rather than packaging random git 
snapshots, *then* upload it. Otherwise it's a pretty pointless exercise 
and I'm sure it'll get REJECTed from NEW.

For HHVM, embedding the folly source as the upstream build does seems 
like the best course of action to me, especially since folly isn't a 
library that we expect to see wide adoption for other packages out 
there.

>> Also, you're really supposed to file separate ITPs for separate packages
>> (and file them *before* you make an upload).
> ??? Please see its ITP[1]. I just noted the upload here. It's closed
>by the changelog in the folly package if that will be accepted into
>the archive.

The reason ITPs exist and policy mandates that they are Cc'ed to 
debian-devel is so that all developers have a chance to raise issues 
(such as naming conflicts, ABI stability, package descriptions, previous 
work etc.).  Filing the ITP and uploading <= 30mins later is a really 
bad practice and doesn't really count, it feels like working around 
Policy to me. (it also hasn't even reached my debian-devel inbox yet, 
did you X-Debbugs-Cc it?)[1]

Regards,
Faidon

1: You're not the first person that I've told that :) cf.  
https://lists.debian.org/debian-devel/2013/06/msg00666.html



Information forwarded to debian-bugs-dist@lists.debian.org, wnpp@debian.org, László Böszörményi (GCS) <gcs@debian.org>:
Bug#727085; Package wnpp. (Sat, 04 Jan 2014 18:36:24 GMT) Full text and rfc822 format available.

Acknowledgement sent to Paul Tarjan <pt@fb.com>:
Extra info received and forwarded to list. Copy sent to wnpp@debian.org, László Böszörményi (GCS) <gcs@debian.org>. (Sat, 04 Jan 2014 18:36:24 GMT) Full text and rfc822 format available.

Message #184 received at 727085@bugs.debian.org (full text, mbox):

From: Paul Tarjan <pt@fb.com>
To: László Böszörményi (GCS) <gcs@debian.org>, "Faidon Liambotis" <paravoid@debian.org>
Cc: "727085@bugs.debian.org" <727085@bugs.debian.org>, Jordan DeLong <delong.j@fb.com>, Sara Golemon <SaraMG@fb.com>
Subject: Re: Bug#727085: Now we don't depend on the weird libevent patch
Date: Sat, 4 Jan 2014 18:33:47 +0000
> 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




Information forwarded to debian-bugs-dist@lists.debian.org, wnpp@debian.org, László Böszörményi (GCS) <gcs@debian.org>:
Bug#727085; Package wnpp. (Sat, 04 Jan 2014 22:33:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Sara Golemon <SaraMG@fb.com>:
Extra info received and forwarded to list. Copy sent to wnpp@debian.org, László Böszörményi (GCS) <gcs@debian.org>. (Sat, 04 Jan 2014 22:33:04 GMT) Full text and rfc822 format available.

Message #189 received at 727085@bugs.debian.org (full text, mbox):

From: Sara Golemon <SaraMG@fb.com>
To: Paul Tarjan <pt@fb.com>, László Böszörményi (GCS) <gcs@debian.org>, "Faidon Liambotis" <paravoid@debian.org>
Cc: "727085@bugs.debian.org" <727085@bugs.debian.org>, Jordan DeLong <delong.j@fb.com>
Subject: Re: Bug#727085: Now we don't depend on the weird libevent patch
Date: Sat, 4 Jan 2014 21:52:55 +0000
On 1/4/14 10:33 , "Paul Tarjan" <pt@fb.com> wrote:
>>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.

Folly doesn't have a version release process, actually.  It's just
continuous master branch development, no tagging, no branches.

-Sara


Information forwarded to debian-bugs-dist@lists.debian.org, wnpp@debian.org:
Bug#727085; Package wnpp. (Sat, 04 Jan 2014 22:57:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to László Böszörményi (GCS) <gcs@debian.org>:
Extra info received and forwarded to list. Copy sent to wnpp@debian.org. (Sat, 04 Jan 2014 22:57:04 GMT) Full text and rfc822 format available.

Message #194 received at 727085@bugs.debian.org (full text, mbox):

From: László Böszörményi (GCS) <gcs@debian.org>
To: Sara Golemon <SaraMG@fb.com>
Cc: Paul Tarjan <pt@fb.com>, Faidon Liambotis <paravoid@debian.org>, "727085@bugs.debian.org" <727085@bugs.debian.org>, Jordan DeLong <delong.j@fb.com>
Subject: Re: Bug#727085: Now we don't depend on the weird libevent patch
Date: Sat, 4 Jan 2014 23:53:25 +0100
On Sat, Jan 4, 2014 at 10:52 PM, Sara Golemon <SaraMG@fb.com> wrote:
> On 1/4/14 10:33 , "Paul Tarjan" <pt@fb.com> wrote:
>>>I can't answer this question. Still, I expect that HHVM will follow
>>>ABI changes very fast. Paul?
>>
>>+Jordan and Sara who know more about the folly process.
>
> Folly doesn't have a version release process, actually.  It's just
> continuous master branch development, no tagging, no branches.
 Question is, does Folly maintain ABI compatibility? If it changes
from time-to-time, how often?

Laszlo/GCS



Information forwarded to debian-bugs-dist@lists.debian.org, wnpp@debian.org, László Böszörményi (GCS) <gcs@debian.org>:
Bug#727085; Package wnpp. (Sun, 05 Jan 2014 03:51:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to Jordan DeLong <delong.j@fb.com>:
Extra info received and forwarded to list. Copy sent to wnpp@debian.org, László Böszörményi (GCS) <gcs@debian.org>. (Sun, 05 Jan 2014 03:51:05 GMT) Full text and rfc822 format available.

Message #199 received at 727085@bugs.debian.org (full text, mbox):

From: Jordan DeLong <delong.j@fb.com>
To: László Böszörményi (GCS) <gcs@debian.org>
Cc: Sara Golemon <SaraMG@fb.com>, Paul Tarjan <pt@fb.com>, Faidon Liambotis <paravoid@debian.org>, "727085@bugs.debian.org" <727085@bugs.debian.org>
Subject: Re: Bug#727085: Now we don't depend on the weird libevent patch
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.

I do think it'd be nice to have folly packages some day, but mostly
the value there would be making it easier to use folly (in other C++
projects).  I don't think it's going to be all that helpful for people
who just want to use hhvm: it's largely a header-only library, so even
if there are nice folly-dev packages with .h's and .a's, I'd hope a
pre-built hhvm package wouldn't depend on a folly package being
installed, since it makes more sense to statically link it.

(Actually there's probably not much point to having a non-development
folly package containing .so's for most reasonable use cases w/ the
library as it is today---maybe if it grows significantly in the
non-header-only portion in the future, but probably not anytime soon.)

-Jordan



Information forwarded to debian-bugs-dist@lists.debian.org, wnpp@debian.org, László Böszörményi (GCS) <gcs@debian.org>:
Bug#727085; Package wnpp. (Sun, 05 Jan 2014 23:42:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Faidon Liambotis <paravoid@debian.org>:
Extra info received and forwarded to list. Copy sent to wnpp@debian.org, László Böszörményi (GCS) <gcs@debian.org>. (Sun, 05 Jan 2014 23:42:04 GMT) Full text and rfc822 format available.

Message #204 received at 727085@bugs.debian.org (full text, mbox):

From: Faidon Liambotis <paravoid@debian.org>
To: Jordan DeLong <delong.j@fb.com>, "László Böszörményi (GCS)" <gcs@debian.org>
Cc: Sara Golemon <SaraMG@fb.com>, Paul Tarjan <pt@fb.com>, "727085@bugs.debian.org" <727085@bugs.debian.org>
Subject: Re: Bug#727085: Now we don't depend on the weird libevent patch
Date: Mon, 06 Jan 2014 01:39:35 +0200
On 01/05/14 05:44, Jordan DeLong wrote:
> 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.
>
> I do think it'd be nice to have folly packages some day, but mostly
> the value there would be making it easier to use folly (in other C++
> projects).  I don't think it's going to be all that helpful for people
> who just want to use hhvm: it's largely a header-only library, so even
> if there are nice folly-dev packages with .h's and .a's, I'd hope a
> pre-built hhvm package wouldn't depend on a folly package being
> installed, since it makes more sense to statically link it.
>
> (Actually there's probably not much point to having a non-development
> folly package containing .so's for most reasonable use cases w/ the
> library as it is today---maybe if it grows significantly in the
> non-header-only portion in the future, but probably not anytime soon.)

Thanks a lot for the clarifications, Jordan and Sara. These seem to 
confirm my (educated :) guesses about folly's release model.

László, given the above, are you going to inform the ftp-masters to 
REJECT the package from NEW right away?

Regards,
Faidon



Information forwarded to debian-bugs-dist@lists.debian.org, wnpp@debian.org:
Bug#727085; Package wnpp. (Mon, 06 Jan 2014 09:15:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to László Böszörményi (GCS) <gcs@debian.org>:
Extra info received and forwarded to list. Copy sent to wnpp@debian.org. (Mon, 06 Jan 2014 09:15:05 GMT) Full text and rfc822 format available.

Message #209 received at 727085@bugs.debian.org (full text, mbox):

From: László Böszörményi (GCS) <gcs@debian.org>
To: Debian FTP Masters <ftpmaster@ftp-master.debian.org>, 734188@bugs.debian.org
Cc: Sara Golemon <SaraMG@fb.com>, Jordan DeLong <delong.j@fb.com>, Paul Tarjan <pt@fb.com>, Faidon Liambotis <paravoid@debian.org>, "727085@bugs.debian.org" <727085@bugs.debian.org>
Subject: Re: Bug#727085: Now we don't depend on the weird libevent patch
Date: Mon, 6 Jan 2014 10:12:13 +0100
Hi FTP Masters,

Folly is part of HHVM[1] and both used inside Facebook. I wanted a
separate package that HHVM would depend on. With the collate below
with FB developers, I realized it doesn't stand on its own. Please
reject it from the NEW queue.
HHVM will contain the Folly git snapshot that works for them. Neither
the best path, but I do hope it will be mature with time. I will
package it then.

Thanks and sorry for the noise.
Laszlo/GCS
[1] http://www.hhvm.com/blog/

On Sun, Jan 5, 2014 at 4:44 AM, Jordan DeLong <delong.j@fb.com> wrote:
> 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.
>
> I do think it'd be nice to have folly packages some day, but mostly
> the value there would be making it easier to use folly (in other C++
> projects).  I don't think it's going to be all that helpful for people
> who just want to use hhvm: it's largely a header-only library, so even
> if there are nice folly-dev packages with .h's and .a's, I'd hope a
> pre-built hhvm package wouldn't depend on a folly package being
> installed, since it makes more sense to statically link it.
>
> (Actually there's probably not much point to having a non-development
> folly package containing .so's for most reasonable use cases w/ the
> library as it is today---maybe if it grows significantly in the
> non-header-only portion in the future, but probably not anytime soon.)



Information forwarded to debian-bugs-dist@lists.debian.org, wnpp@debian.org, László Böszörményi (GCS) <gcs@debian.org>:
Bug#727085; Package wnpp. (Wed, 29 Jan 2014 00:42:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to Paul Tarjan <pt@fb.com>:
Extra info received and forwarded to list. Copy sent to wnpp@debian.org, László Böszörményi (GCS) <gcs@debian.org>. (Wed, 29 Jan 2014 00:42:05 GMT) Full text and rfc822 format available.

Message #214 received at 727085@bugs.debian.org (full text, mbox):

From: Paul Tarjan <pt@fb.com>
To: "727085@bugs.debian.org" <727085@bugs.debian.org>
Subject: Any news?
Date: Wed, 29 Jan 2014 00:38:14 +0000
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




Information forwarded to debian-bugs-dist@lists.debian.org, wnpp@debian.org, László Böszörményi (GCS) <gcs@debian.org>:
Bug#727085; Package wnpp. (Fri, 28 Feb 2014 19:18:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to David Martínez Moreno <ender@debian.org>:
Extra info received and forwarded to list. Copy sent to wnpp@debian.org, László Böszörményi (GCS) <gcs@debian.org>. (Fri, 28 Feb 2014 19:18:04 GMT) Full text and rfc822 format available.

Message #219 received at 727085@bugs.debian.org (full text, mbox):

From: David Martínez Moreno <ender@debian.org>
To: 727085@bugs.debian.org
Cc: David Martínez Moreno <ender@debian.org>
Subject: Taking over packaging in Debian.
Date: Fri, 28 Feb 2014 11:16:04 -0800
[Message part 1 (text/plain, inline)]
	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'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.

	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.

	Best regards,


		Ender.

[1]: http://git.debian.org/?p=collab-maint/hhvm.git;a=summary

[signature.asc (application/pgp-signature, attachment)]

Information forwarded to debian-bugs-dist@lists.debian.org, wnpp@debian.org:
Bug#727085; Package wnpp. (Sat, 01 Mar 2014 06:15:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to László Böszörményi (GCS) <gcs@debian.org>:
Extra info received and forwarded to list. Copy sent to wnpp@debian.org. (Sat, 01 Mar 2014 06:15:04 GMT) Full text and rfc822 format available.

Message #224 received at 727085@bugs.debian.org (full text, mbox):

From: László Böszörményi (GCS) <gcs@debian.org>
To: David Martínez Moreno <ender@debian.org>, "727085@bugs.debian.org" <727085@bugs.debian.org>
Cc: Ondřej Surý <ondrej@sury.org>, Faidon Liambotis <paravoid@debian.org>
Subject: Re: Bug#727085: Taking over packaging in Debian.
Date: Sat, 1 Mar 2014 07:10:48 +0100
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.

>         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 <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?
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 <delong.j@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



Information forwarded to debian-bugs-dist@lists.debian.org, wnpp@debian.org, László Böszörményi (GCS) <gcs@debian.org>:
Bug#727085; Package wnpp. (Mon, 03 Mar 2014 22:03:16 GMT) Full text and rfc822 format available.

Acknowledgement sent to David Martínez Moreno <ender@debian.org>:
Extra info received and forwarded to list. Copy sent to wnpp@debian.org, László Böszörményi (GCS) <gcs@debian.org>. (Mon, 03 Mar 2014 22:03:16 GMT) Full text and rfc822 format available.

Message #229 received at 727085@bugs.debian.org (full text, mbox):

From: David Martínez Moreno <ender@debian.org>
To: "László Böszörményi (GCS)" <gcs@debian.org>, "727085@bugs.debian.org" <727085@bugs.debian.org>
Cc: David Martínez Moreno <ender@debian.org>, Ondřej Surý <ondrej@sury.org>, Faidon Liambotis <paravoid@debian.org>
Subject: Re: Bug#727085: Taking over packaging in Debian.
Date: Mon, 03 Mar 2014 14:01:06 -0800
[Message part 1 (text/plain, inline)]
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.

[signature.asc (application/pgp-signature, attachment)]

Information forwarded to debian-bugs-dist@lists.debian.org, wnpp@debian.org:
Bug#727085; Package wnpp. (Tue, 04 Mar 2014 00:21:10 GMT) Full text and rfc822 format available.

Acknowledgement sent to László Böszörményi (GCS) <gcs@debian.org>:
Extra info received and forwarded to list. Copy sent to wnpp@debian.org. (Tue, 04 Mar 2014 00:21:11 GMT) Full text and rfc822 format available.

Message #234 received at 727085@bugs.debian.org (full text, mbox):

From: László Böszörményi (GCS) <gcs@debian.org>
To: David Martínez Moreno <ender@debian.org>, "727085@bugs.debian.org" <727085@bugs.debian.org>
Cc: Ondřej Surý <ondrej@sury.org>, Faidon Liambotis <paravoid@debian.org>
Subject: Re: Bug#727085: Taking over packaging in Debian.
Date: Tue, 4 Mar 2014 01:19:44 +0100
On Mon, Mar 3, 2014 at 11:01 PM, David Martínez Moreno <ender@debian.org> wrote:
> On 2/28/14, 10:10 PM, László Böszörményi (GCS) wrote:
>> On Fri, Feb 28, 2014 at 8:16 PM, David Martínez Moreno <ender@debian.org> wrote:
>>  Can you share those decisions?
>
>         Don't act as we have some hidden agenda, please.
 I referred only to the "some decisions that we made as a team" part,
inside at Facebook and not yet public.

>         I hadn't pushed some of my changes to git... architecture and additional fixes
> are now in.
 Will check them. It's midnight here. :(

>         Again the list was incomplete (not pushed) [...]
 Referred to the fact there was no build dependencies at all. OK.

>> 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.
 This is good news. The build system should check for proper versions
installed and not including them.

>         The rest of them (if they're released as normal packages) will follow.
 Several of them are packaged already. See double-conversion, sqlite3 and lz4.
I've packaged libafdt and libmbfl and of course folly. I'm not sure
all of them are correct and I know that folly doesn't stand on its
own.

>         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.
 It's not just that. Its upstream is died five years ago and its 0.1.0
version number[1] doesn't suggest that it's stable and ready.

>         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.
 Sure, this should be done first before packaging. This is what I
wanted from Paul in my private email.
For me it seems Facebook just put the sources on GitHub, but don't
play well that boxes can have the dependent libraries installed, maybe
with newer versions that included in HHVM this time.

>> 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.
 Again, I meant it in a different context. Can HHVM team support Folly
on the long run (say, Ubuntu LTS releases) when its not their work and
it doesn't have any 'stable', versioned release (ie, even its team may
not remember why something was solved that way in a moment of time)
and someone may look for a mistic FTBFS problem or needs a security
fix somewhen?

>> 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.
 I wrote _history_. Referred to how Facebook follows other upstream
sources. Embedding and not updating them for more than a year is a
problem. I know that the libevent 1.x problem is gone. Just a friendly
reminder, under hphp/third_party/ there's still a patch for libevent
1.4.14 which can be removed.

>         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.
 According to my records[2], sqlite3 has version 3.7.13 in stable and
as a backport in oldstable as well. You may use backports as well I
guess. But I doubt you use oldstable.

> 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'm mostly arguing against embed several other upstream packages in
HHVM. Then it's hard to follow which one may have newer security /
important bugfix release, what patches Facebook has on them, etc.
That's maybe impossible in the current situation. I even doubt that
the security team will allow HHVM in as it's today. Embedding several
other sources and make an inside build is a security nightmare.

>         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.
 I don't think they are subscibed, but get mails by Cc.

>         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.
 Yes, it's partly my problem. I've a workplace and in my spare time
I'm always invited to somewhere. The previous weekend was about the
party of tenth birthday of the Fedora project with the release of
Fedora 20. This weekend was an international MSSQL education and new
features event. I know, Fedora is not related to Debian and MSSQL
doesn't even run on Linux. Blame me if you want.
I wrote you didn't ask me, didn't used the word 'hostile'. In short,
we could have found out what the current problem is. I do wait for
Paul's answer and as it seems he didn't get my mail for some reason,
you may have helped to continue with the solution.
Which is to move third party sources out before packaging.

>> 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?
 Oh, yes. Not in the bugreport, but in php-maint maillist[3] and Paul
was Cc-d. So he knows.

>> An other project from Facebook, Flint also have some issues
>> unanswered[3] from a Debian Developer. May you route those to someone
>> with proper knowledge?
>
>         Who is the developer, sylvestre? jmh045000?
 The main developer is Sylvestre Ledru and maybe Lucas Nussbaum is
also in that project.

>         I will do my best to route your request once I understand the problem :-).
 Flint looks like a project that was put on GitHub and that's all. For
example it doesn't have documentation[4]. You mix this. It's the
request of Sylvestre, not mine.

Laszlo/GCS
[1] http://sourceforge.net/projects/libafdt/files/?source=directory
[2] http://packages.qa.debian.org/s/sqlite3.html
[3] http://lists.alioth.debian.org/pipermail/pkg-php-maint/2014-February/013069.html
[4] https://github.com/facebook/flint/issues/6



Information forwarded to debian-bugs-dist@lists.debian.org, wnpp@debian.org, László Böszörményi (GCS) <gcs@debian.org>:
Bug#727085; Package wnpp. (Tue, 04 Mar 2014 09:27:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Faidon Liambotis <paravoid@debian.org>:
Extra info received and forwarded to list. Copy sent to wnpp@debian.org, László Böszörményi (GCS) <gcs@debian.org>. (Tue, 04 Mar 2014 09:27:04 GMT) Full text and rfc822 format available.

Message #239 received at 727085@bugs.debian.org (full text, mbox):

From: Faidon Liambotis <paravoid@debian.org>
To: David Martínez Moreno <ender@debian.org>
Cc: "László Böszörményi (GCS)" <gcs@debian.org>, "727085@bugs.debian.org" <727085@bugs.debian.org>, Ondřej Surý <ondrej@sury.org>
Subject: Re: Bug#727085: Taking over packaging in Debian.
Date: Tue, 04 Mar 2014 10:42:14 +0200
On 03/04/14 00:01, David Martínez Moreno wrote:
> 	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.

\o/ This list is awesome David, as is the rest of your work so far. 
Let's document this and others under debian/TODO.

Thanks for this and apologies to you, Paul & team for not having made 
much progress on this since we last spoke.

I took a look at the collab-maint repository and submitted a bunch of 
commits -- I had already prepared a very similar list of Build-Depends 
myself in the early work I had locally, so I merged mine into yours and 
fixed some other collateral issues I found. Please review!

Thanks again and I hope we can find ways to collaborate to make an 
awesome HHVM package in Debian :)

Best,
Faidon



Information forwarded to debian-bugs-dist@lists.debian.org, wnpp@debian.org, László Böszörményi (GCS) <gcs@debian.org>:
Bug#727085; Package wnpp. (Mon, 31 Mar 2014 11:03:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to David Martínez Moreno <ender@debian.org>:
Extra info received and forwarded to list. Copy sent to wnpp@debian.org, László Böszörményi (GCS) <gcs@debian.org>. (Mon, 31 Mar 2014 11:03:04 GMT) Full text and rfc822 format available.

Message #244 received at 727085@bugs.debian.org (full text, mbox):

From: David Martínez Moreno <ender@debian.org>
To: "727085@bugs.debian.org" <727085@bugs.debian.org>
Cc: "László Böszörményi (GCS)" <gcs@debian.org>, David Martínez Moreno <ender@debian.org>, Ondřej Surý <ondrej@sury.org>, Faidon Liambotis <paravoid@debian.org>, Paul Tarjan <pt@fb.com>
Subject: An HHVM-in-Debian State of the Union (was Re: Bug#727085: Taking over packaging in Debian.)
Date: Mon, 31 Mar 2014 04:01:14 -0700
[Message part 1 (text/plain, inline)]
On 3/3/14, 2:01 PM, David Martínez Moreno wrote:
> 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.

	Hello, I just wanted to update everyone on this thread with respect to the
Debian packaging.

	I have been working (with some help from Faidon) to bring the 2.4.1 tarball to
Debian standards.  The git repo (remember,
http://anonscm.debian.org/gitweb/?p=collab-maint/hhvm.git;a=summary) 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.

	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.

	In the meantime, Facebook has released HHVM 3.0.0 with Hack support (a superset
of PHP with gradual typing, collections and more stuff - http://hacklang.org).
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.

	All in all, the ball keeps rolling, and hopefully in another month or so I hope
to have a package ready in the archives.  Call me an optimist.

	Best regards,


		Ender.

[signature.asc (application/pgp-signature, attachment)]

Information forwarded to debian-bugs-dist@lists.debian.org, wnpp@debian.org, László Böszörményi (GCS) <gcs@debian.org>:
Bug#727085; Package wnpp. (Mon, 31 Mar 2014 20:06:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Paul Tarjan <pt@fb.com>:
Extra info received and forwarded to list. Copy sent to wnpp@debian.org, László Böszörményi (GCS) <gcs@debian.org>. (Mon, 31 Mar 2014 20:06:04 GMT) Full text and rfc822 format available.

Message #249 received at 727085@bugs.debian.org (full text, mbox):

From: Paul Tarjan <pt@fb.com>
To: David Martínez Moreno <ender@debian.org>, "727085@bugs.debian.org" <727085@bugs.debian.org>
Cc: László Böszörményi (GCS) <gcs@debian.org>, Ondřej Surý <ondrej@sury.org>, Faidon Liambotis <paravoid@debian.org>
Subject: Re: An HHVM-in-Debian State of the Union (was Re: Bug#727085: Taking over packaging in Debian.)
Date: Mon, 31 Mar 2014 19:36:28 +0000
>	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




Send a report that this bug log contains spam.


Debian bug tracking system administrator <owner@bugs.debian.org>. Last modified: Sun Apr 20 09:01:24 2014; Machine Name: buxtehude.debian.org

Debian Bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.