Bug#727085: Now we don't depend on the weird libevent patch
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 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.) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#727085: Now we don't depend on the weird libevent patch
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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#727085: Now we don't depend on the weird libevent patch
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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#727085: Now we don't depend on the weird libevent patch
On Sat, Jan 4, 2014 at 10:52 PM, Sara Golemon wrote: > On 1/4/14 10:33 , "Paul Tarjan" 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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#727085: Now we don't depend on the weird libevent patch
On 1/4/14 10:33 , "Paul Tarjan" 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
Bug#727085: Now we don't depend on the weird libevent patch
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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#727085: Now we don't depend on the weird libevent patch
> I can't answer this question. Still, I expect that HHVM will follow >ABI changes very fast. Paul? >Anyway, I think having a separate package and let users get knowledge >of that doesn't mean HHVM can't use an embedded copy if it needs to. >But it should be a separate package whenever it's possible. We pin HHVM to certain git hashes. If there is a folly change we need (which is rare) we will update the hash of the git submodule. I don't know the details of how folly does backwards compatibility but if the hashes we have correspond to folly package version, then you could just pin our hhvm versions to folly versions, right? +Jordan and Sara who know more about the folly process. Paul -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#727085: Now we don't depend on the weird libevent patch
On Sat, Jan 4, 2014 at 6:58 PM, Faidon Liambotis 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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#727085: Now we don't depend on the weird libevent patch
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 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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#727085: Now we don't depend on the weird libevent patch
On Sat, Jan 4, 2014 at 1:51 AM, Paul Tarjan 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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#727085: Now we don't depend on the weird libevent patch
> I can use Debian servers or an own GitHub repository for packaging, >no problem. Actually I think I'm ~90% ready with HHVM packaging. Yay! >checking whether the Boost::Thread library is available... yes >configure: error: Could not find a version of the library! It looks like it defaults to looking in /usr/bin instead of where lib boost is in sid. Try ./configure --with-boost-libdir=/usr/lib/x86_64-linux-gnu/ Paul -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#727085: Now we don't depend on the weird libevent patch
On Mon, Dec 30, 2013 at 8:36 PM, Paul Tarjan 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
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
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#727085: Now we don't depend on the weird libevent patch
On Tue, Dec 31, 2013 at 3:45 AM, Faidon Liambotis 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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#727085: Now we don't depend on the weird libevent patch
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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#727085: Now we don't depend on the weird libevent patch
>> https://github.com/hhvm/packaging/tree/master/hhvm/deb
> Checked wheezy/ which is just wrong. It's a binary debian directory
>and not a source one, I think 'Essential' is only used if its value is
>'yes'. Standards-Version is missing, no long package description, ...
I would love a pull request, or if you get really into this I'm happy to
make you a co-author on the repo.
>My opinion for releases follows. Do one if there's an important
>bugfix, new feature added, etc. In short, if there's a reason.
>On the other hand, there's no problem with releasing every two weeks,
>it's just not common. It matches with Debian standards, meaning that
>normally ten days needed for unstable -> testing migration.
Excellent. We move pretty fast and are constantly making performance
improvements which is why we release internally every 2 weeks. I'll float
it with the rest of the team. If we do 26 releases this year we'll be at
2.30.0 by the end of the year. Is that weird?
>Do you have a packager position there, at FB? :)
Short term, yes, but long term we would much rather the community take
over packaging.
On my team it wouldn't be a full time job, but I'm filling the role right
now and would love you to do it instead ;) You'd just have to find other
good things to do too. https://www.facebook.com/careers/
>Now my previous package section for HHVM,
>which I've named hiphop-php (to match the PHP policy of Debian, but
>will re-check that):
Our project used to be named hiphop-php when it was a PHP to C++
translator. We decommissioned it in February once the JIT was faster. The
JIT was codenamed HHVM so we've taken that on as the project's main name
since it is the only runtime we support now.
>-- cut --
>Package: hiphop-php
>Architecture: any
>Depends: ${misc:Depends}
>Description: HipHop VM for PHP
> HipHop VM (HHVM) is a new open-source virtual machine designed for
>executing
> programs written in PHP. HHVM uses a just-in-time compilation approach to
> achieve superior performance while maintaining the flexibility that PHP
> developers are accustomed to. HipHop VM (and before it HPHPc) has
>realized
> > 5x increase in throughput for Facebook compared with Zend PHP 5.2.
> HipHop is most commonly run as a standalone server, replacing both Apache
> and modphp.
>-- cut --
Should I use this? Again a pull request would be awesome.
>> I'll probably still have to keep packaging
>> it for other distros since you're only going to do debian, right? Or is
>> there an easy way for you to also do it in other debian-based distros
>> (ubuntu, mint). Can you also do yum based distros or do you know what I
>> should do for inclusion there?
> I think packaging for Debian is a good step. Then Ubuntu maintainers
>will pick it up and as I know, Mint based on Ubuntu, they will have it
>as well. I've experience with Red Hat and Fedora packaging as well.
>You may know that the transition is Fedora -> Red Hat from time to
>time.
I would be elated for any help you can offer here. And even if you can't
do it, guide me on the steps I need to do and I'll do everything in my
power to help. We are very excited about being in every distro.
One other thing I haven't brought up and probably should, is we are trying
to be a drop-in replacement for all facets of php. For example, if our
binary is named "php" then it will accept the same command line args that
php-src accepts. For now, the packages I've made have left our binary
named hhvm since I don't know how it will interact with the php-src
package, but if there is an easy way to use "alternates" or something we
can drop in and replace the system binary too (and give a big speed boost
to user's scripts).
Paul
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#727085: Now we don't depend on the weird libevent patch
On Sun, Dec 29, 2013 at 11:42 PM, Paul Tarjan 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
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#727085: Now we don't depend on the weird libevent patch
On Sun, 29 Dec 2013 22:42:43 + 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 pgpzeVfQ0R84o.pgp Description: PGP signature
Bug#727085: Now we don't depend on the weird libevent patch
Thanks so much for speaking up Faidon. Francesco, I honestly thought you were speaking officially and we would be rejected. When you didn't reply to my email asking "What should I do?" I didn't know what to think... I won't stir the pot with any more legal discussion. That isn't my field and I'm just parroting what our legal department tells me anyways. I've articulated our position before, so I'll just wait until the legal issue is actually blocking our adoption. Ok? Since my last email, I put a bunch of effort into my packaging script. Now they are signed correctly, there is a main skeleton and then overrides for each version, and it updates the version files for me. Feel free to make pull requests or use this as a basis: https://github.com/hhvm/packaging/tree/master/hhvm/deb Internally at FB we release a new version of HHVM every 2 weeks. We cut the branch on Monday and then do lots of rigorous testing and ship it 10 days later on Thursday morning. I'd like to exactly mirror the internal releases since they are well tested instead of just arbitrarily cutting trunk. Many people voiced opinions that every 2 weeks was too fast for major open source releases so we agreed on mirroring every 4 releases (8 weeks). How does that sound? It is easy to make it faster or slower by 2 week increments if anyone has opinions. Lastly, Laszlo, we should talk about how I can help with packaging. I currently make a new branch for major versions and tags for each point release on our github repo. Do you want me to email you when I do this or can you subscribe to github easily? Or should I setup a mailing list and always email that when I push? I'll probably still have to keep packaging it for other distros since you're only going to do debian, right? Or is there an easy way for you to also do it in other debian-based distros (ubuntu, mint). Can you also do yum based distros or do you know what I should do for inclusion there? Paul -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#727085: Now we don't depend on the weird libevent patch
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 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 pgpvWXkolaTEG.pgp Description: PGP signature
Bug#727085: Now we don't depend on the weird libevent patch
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 pgpuwo1bVi3RL.pgp Description: PGP signature
Bug#727085: Now we don't depend on the weird libevent patch
On Sun, Dec 29, 2013 at 2:46 PM, Faidon Liambotis 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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#727085: Now we don't depend on the weird libevent patch
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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#727085: Now we don't depend on the weird libevent patch
On Sat, 21 Dec 2013 23:09:18 + 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 pgpFPd2d75CMO.pgp Description: PGP signature
Bug#727085: Now we don't depend on the weird libevent patch
>Not really, in my opinion. >I think it's a valid rejection reason for anything that is not the >reference PHP implementation published and copyrighted by the PHP Group. > >Personally, I consider the PHP License non-free even for PHP itself, >but that's another story: >https://lists.debian.org/debian-legal/2005/11/msg00272.html What would you like me to do? >Please let me understand: do you mean that hhvm includes code derived >from the reference PHP implementation published and copyrighted by the >PHP Group? Yes. You can see our source code at https://github.com/facebook/hhvm -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#727085: Now we don't depend on the weird libevent patch
On Sat, 21 Dec 2013 20:42:37 + 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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#727085: Now we don't depend on the weird libevent patch
>> What else should I be doing to get this packaged up for inclusion in >> debian? > > Do you mean apart from persuading the copyright holder (Facebook, Inc.) > to re-license hhvm under more general DFSG-free terms, such as the > 3-clause BSD license? > Your help in getting this issue solved would be highly appreciated, I > think. > Please re-read http://bugs.debian.org/727085#60 > for further details on the licensing issue. That rejection reason is pretty squarely aimed at people writing applications in the PHP language and makes sense for them. We are an alternative to php-src mostly coded in C++ and x86 assembly. (and after we prove ourselves I'll petition to be marked as an alternative for the php package). As for the direct question. Much of our extension code was directly imported from php-src so we will absolutely be unable to relicense that portion. Untangling our contributions from the php-src ones is a very arduous task since there are many bug fixes to their code (some upstreamed, some not) as well as API changes and data structure replacements. We are happy with the php license so releasing the whole package under the same umbrella makes development much easier. We are willing to relicense our portions under BSD but the technical splitting of the files into us vs them is just too much to ask. Again, we are the first viable runtime alternative to php-src so I would argue that the rejection paragraph does not apply to us and didn't even consider us. > I think László (who reads us in Cc) is still interested in packaging > hhvm for inclusion in Debian. > At least the bug is still an ITP bug and still owned by László, hence, > unless he has just changed his mind, he should be still willing to work > on the packaging... > > I suggest you to get in touch with László and ask him whether and how > you can help. Laszlo, if you are listening out there please build us a package. You can see what I was doing at http://github.com/hhvm/packaging > Thanks for being a Debian-friendly upstream developer and for offering > to help! > > Bye. > > > -- > http://www.inventati.org/frx/frx-gpg-key-transition-2010.txt > New GnuPG key, see the transition document! > . Francesco Poli . > GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#727085: Now we don't depend on the weird libevent patch
On Mon, 16 Dec 2013 19:43:37 + 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 pgpqupZ4PDzVn.pgp Description: PGP signature
Bug#727085: Now we don't depend on the weird libevent patch
I'd like to revive this bug now that our libevent plans are solidified. With our 2.3.0 release we now support FastCGI and we want to make that the default method to run HHVM. Our FastCGI server works with the standard libevent 2.0 library and if that is the only thing present on the compiling machine, then the standalone HTTP server support won't be available and you can only use FastCGI. This is the mode we expect to become the default with a future release (probably 2.5.0 in 4 months). What else should I be doing to get this packaged up for inclusion in debian? My method of packaging our release is very clowny (I compile the binary and then copy it into a directory with the skeleton for the package and then build that with dpkg -b) so I'd rather someone else with more debian experience build a proper package for us. You can find me on IRC on freenode in #hhvm if you prefer real-time. Paul -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
