From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 14195 invoked from network); 25 Feb 2021 18:10:46 -0000 Received: from 1ess.inri.net (216.126.196.35) by inbox.vuxu.org with ESMTPUTF8; 25 Feb 2021 18:10:46 -0000 Received: from mimir.eigenstate.org ([206.124.132.107]) by 1ess; Thu Feb 25 13:07:05 -0500 2021 Received: from abbatoir.fios-router.home (pool-108-41-92-79.nycmny.fios.verizon.net [108.41.92.79]) by mimir.eigenstate.org (OpenSMTPD) with ESMTPSA id 2080daf2 (TLSv1.2:ECDHE-RSA-AES256-SHA:256:NO) for <9front@9front.org>; Thu, 25 Feb 2021 10:06:55 -0800 (PST) Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit To: 9front@9front.org Date: Thu, 25 Feb 2021 10:06:54 -0800 From: ori@eigenstate.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: database hypervisor enhancement realtime-java enhancement replication Subject: Re: [9front] [Patch] APE changes (2019 Lufia patches) Reply-To: 9front@9front.org Precedence: bulk Quoth Aaron : > > I never went as far as the original intent, being Torvalds git, instead > focusing on the dependencies: curl, expat, zlib, and libressl. There are > separate patches specifically for libressl to build, but those patches > were insufficient for me on 9front. I did manage to get libressl to > build but curl still had issues with TLS addresses. At the time I chose > to see the failure as isolated to the libressl patches. The other > packages worked without modification. > > As it stands it is my intention to submit separate diffs for pthread, > include_next, and a third for the remainder (excluding _apetypes). If > this proposal is unacceptable please let me know. If anyone would rather > see further testing then that is perfectly fine as well. I'm not trying to ask about testing. The question is "what will you use this for?" In my opinion, the goal of ape is to accumulate necessary cruft for running programs, and not much more. Adding to ape is a cost we pay to port more tools. http://fqa.9front.org/linuxburden.jpg The plan for getting the code reviewed is fine, and there are APIs that are widely used in the patches, as well as bug fixes for existing APIs that we provide. So I'm ok with going through these. But I'd be far more excited if I heard something like "it makes torvalds git work" or "it allows threads in the ocaml port" or other user visible improvements, rather than "it ticks checkboxes in the posix spec"