Bug#727085: Taking over packaging in Debian.
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
Reply to: