From rob at landley.net Sat Sep 3 07:14:57 2016 From: rob at landley.net (Rob Landley) Date: Sat, 3 Sep 2016 02:14:57 -0500 Subject: [Aboriginal] musl-cross-make. Message-ID: <424623fc-99ab-94e8-f308-c7a0cb370d52@landley.net> I've gotten a basic build happening using https://github.com/richfelker/musl-cross-make as an externally supplied toolchain, and the result booted to a shell prompt! Now I'm trying to get it to include as a native compiler, and there's the problem that native-compiler.sh is actually two things: 1) the old gplv2 native compiler packages 2) make, bash, and distcc 3) The mounting glue script. The new stuff should be able to replace part 1. For part 2 I still need make and bash to be able to build anything nontrivial: busybox hush isn't a replacement, busybox ash doesn't build on nommu, and toysh isn't there yet. And distcc lets emulated builds access not just the speed of a host compiler, but SMP. (There's some work to finally make qemu multi-threaded, and it's maybe halfway there. lwn.net covered it recently.) Part 3, maybe I can move the script to the host. The point of having it in the image was so that the IMAGE knows how to splice itself into the host, but I can basically do a "cp -rFs /usr/overlay/. /". The OTHER thing it was doing was putting the "Press any key for command line" and running automated build stuff in the tools partition, not the root filesystem." Sigh. Maybe if Rich provides tarballs I can have a repackage.sh that turns it into a squashfs. Except I don't want to require mksquashfs to exist on the target in order to use the... grrrrr. These are the design issues that eat cycles. Not the "how do you make it work" things, the how do you make it CLEAN things... Rob From rob at landley.net Sat Sep 10 00:28:54 2016 From: rob at landley.net (Rob Landley) Date: Fri, 9 Sep 2016 19:28:54 -0500 Subject: [Aboriginal] Refactoring/recycling Message-ID: <1790ba2d-6a47-d006-1202-d3c7f1bfa4ee@landley.net> I've been breaking aboriginal linux down for parts. It's just too much of a giant hairball, despite my attempts to separate it into layers. The thing is, once you take out the toolchain build (and replace it with Rich Felker's musl-cross-make), there's only 5 other packages it builds (toybox, busybox, make, bash, distcc). All of them compile reasonably easily, and as toybox adances at least 2 of them should go away. The infrastructure aboriginal linux provides for them is WAY OVERKILL for what's left for it to do (as evidenced by https:/github.com/j-core.org/mkroot working fine without any of it). What Aboriginal Linux has is: 1) The ./download.sh infrastructure to download and patch source code, and maintain an extracted "package cache" for parallel builds. This includes setup and teardown wrappers to _use_ the package cache (and set up the cross compiler path, and so on). 2) The host-tools.sh "airlock step" and environment sanitization logic (sources/variables.sh) for doing "hermetic builds" (I.E. portable/reproducible builds that provide their own known build environment). 3) target configs with matching gcc tuple (and flags), kernel config (and KARCH), and qemu command line (and kernel command line). 4) Wrapper script to launch qemu with some infrastucture around it (most of which supports build control images; note that http://landley.net/aboriginal/build-control to _create_ build control images is a separate project with its own git repo). 5) Busybox and uClibc config files (now legacy info). 6) A dozen package build recipes (in sources/sections), 2/3 which (ccwrap.sh, gcc.sh, musl.build, uClibc.build, binutils.build, linux-headers.sh, uClibc++.build, elf2flt.sh) are obsolete if we use Rich's toolchain instead of building our own. 7) The miniconfig.sh stuff 8) record-commands.sh I'm still reading through my old stuff, but that seems to be the bulk of it. If you move to musl-cross-make and mkroot.sh, #5 and #6 can pretty much be abandoned. I can extend mkroot.sh to (optionally) build make and distcc for a target, neither is a big deal. I need to get serious about toybox's built-in shell. I can break out #1 into its own project. I hadn't yet because it seems like overkill: mkroot doesn't do it and hasn't needed it? Still, Jeff was hitting the lack of this one last week... I'm already porting #2 (the host-tools.sh stuff) into the toybox build. Maybe there should be a "scripts/hermetic.sh" to set up a hermetic build environment, maybe it should be an install target, not sure yet. (It's not _just_ an install, there's a chroot-like step to change the $PATH and unset all unrecognized environment variables checking the whitelist...) The record-commands.sh stuff should should go in there too, it's separate but related. I should throw miniconfig at the kernel again and see if it sticks. (It won't, but as far as I'm concerned reposting it with explanation annually is probably good enough.) That leaves #3 and #4 which I can maybe wrap up together as their own thing? Haven't decided about that bit yet. Maybe it belongs alongside mkroot? Rob From rob at landley.net Sun Sep 11 05:17:49 2016 From: rob at landley.net (Rob Landley) Date: Sun, 11 Sep 2016 00:17:49 -0500 Subject: [Aboriginal] Refactoring/recycling In-Reply-To: <1790ba2d-6a47-d006-1202-d3c7f1bfa4ee@landley.net> References: <1790ba2d-6a47-d006-1202-d3c7f1bfa4ee@landley.net> Message-ID: <1f6605ab-e32d-f6e8-52e7-02f4a896f799@landley.net> On 09/09/2016 07:28 PM, Rob Landley wrote: > I've been breaking aboriginal linux down for parts. It's just too much > of a giant hairball, despite my attempts to separate it into layers. > > The thing is, once you take out the toolchain build (and replace it with > Rich Felker's musl-cross-make), there's only 5 other packages it builds > (toybox, busybox, make, bash, distcc). All of them compile reasonably > easily, and as toybox adances at least 2 of them should go away. The > infrastructure aboriginal linux provides for them is WAY OVERKILL for > what's left for it to do (as evidenced by > https:/github.com/j-core.org/mkroot working fine without any of it). > > What Aboriginal Linux has is: > > 1) The ./download.sh infrastructure to download and patch source code, > and maintain an extracted "package cache" for parallel builds. This > includes setup and teardown wrappers to _use_ the package cache (and set > up the cross compiler path, and so on). > > 2) The host-tools.sh "airlock step" and environment sanitization logic > (sources/variables.sh) for doing "hermetic builds" (I.E. > portable/reproducible builds that provide their own known build > environment). > > 3) target configs with matching gcc tuple (and flags), kernel config > (and KARCH), and qemu command line (and kernel command line). > > 4) Wrapper script to launch qemu with some infrastucture around it (most > of which supports build control images; note that > http://landley.net/aboriginal/build-control to _create_ build control > images is a separate project with its own git repo). > > 5) Busybox and uClibc config files (now legacy info). > > 6) A dozen package build recipes (in sources/sections), 2/3 which > (ccwrap.sh, gcc.sh, musl.build, uClibc.build, binutils.build, > linux-headers.sh, uClibc++.build, elf2flt.sh) are obsolete if we use > Rich's toolchain instead of building our own. > > 7) The miniconfig.sh stuff > > 8) record-commands.sh And a wrapper that packages up a directory in various formats (squashfs, cpio.gz, gene2fs). That wrapper _used_ to be more interesting, because (unless you wanted to build as root, where you could actually mknod on the host system) you had to add arguments to each of those packaging formats' command lines creating /dev/console in the new root filesystem, or else Linux couldn't launch init. But now there's CONFIG_DEVTMPFS_MOUNT (and I have a patch to make it apply to initramfs, although when I submitted it upstream they didn't want it and I lost interest because it works for me so if they don't want it, I'm ok with that). I suppose I should post miniconfig.sh again too. (Annually if necessary, since they'll never take it and I'm pretty sure the TEN YEARS since my initial 3 posts submitting miniconfig shows I'm not interested in doing morethan I have to inflict something that works fine for me on a community that doesn't want it. Still, the invitation-only kernel summit community hanging out on the private greybeards list.) Rob From alessioigorbogani at gmail.com Mon Sep 12 08:23:43 2016 From: alessioigorbogani at gmail.com (Alessio Igor Bogani) Date: Mon, 12 Sep 2016 10:23:43 +0200 Subject: [Aboriginal] Refactoring/recycling In-Reply-To: <1f6605ab-e32d-f6e8-52e7-02f4a896f799@landley.net> References: <1790ba2d-6a47-d006-1202-d3c7f1bfa4ee@landley.net> <1f6605ab-e32d-f6e8-52e7-02f4a896f799@landley.net> Message-ID: Hi Rob, On 11 September 2016 at 07:17, Rob Landley wrote: > On 09/09/2016 07:28 PM, Rob Landley wrote: >> easily, and as toybox adances at least 2 of them should go away. The >> infrastructure aboriginal linux provides for them is WAY OVERKILL for >> what's left for it to do (as evidenced by >> https:/github.com/j-core.org/mkroot working fine without any of it). [...] I guess it uses a cross-compiler, right? So what if I could want add an autotools based software? Setup qemu and distcc to work side by side is a very good things to me and it isn't an overkill at all. In fact it is the reason I'm still following this project. [...] > launch init. But now there's CONFIG_DEVTMPFS_MOUNT (and I have a patch > to make it apply to initramfs, although when I submitted it upstream > they didn't want it and I lost interest because it works for me so if > they don't want it, I'm ok with that). Could you pinpoint me to the patch? It could be useful for me too. > I suppose I should post miniconfig.sh again too. (Annually if necessary, > since they'll never take it and I'm pretty sure the TEN YEARS since my > initial 3 posts submitting miniconfig shows I'm not interested in doing Have you ever considered to rework it and integrate it to "make tinyconfig"? Thank Rob for all! Ciao, Alessio From tristan.vanberkom at codethink.co.uk Mon Sep 12 11:41:54 2016 From: tristan.vanberkom at codethink.co.uk (Tristan Van Berkom) Date: Mon, 12 Sep 2016 20:41:54 +0900 Subject: [Aboriginal] Refactoring/recycling In-Reply-To: <1790ba2d-6a47-d006-1202-d3c7f1bfa4ee@landley.net> References: <1790ba2d-6a47-d006-1202-d3c7f1bfa4ee@landley.net> Message-ID: <1473680514.3020.1.camel@codethink.co.uk> On Fri, 2016-09-09 at 19:28 -0500, Rob Landley wrote: > I've been breaking aboriginal linux down for parts. It's just too > much > of a giant hairball, despite my attempts to separate it into layers. > Hi Rob, So just to understand, since I have some interesting work based on this by now, what is going to be the end result of using the musl-cross-make approach in Aboriginal ? How much will things change from the perspective of the Aboriginal end user ? If I understand correctly, this will mean: ? o GPLv3 toolchain ? o Less deviation from upstream gcc (as I understand there had been ? ? some patches to make gcc behave differently for aboriginal, while ? ? the musl-cross-make patches are mostly upstreamed) Are you planning to continue with ccwrap.c, allowing for the relocatable cross compiler ? (I think this was a pretty cool feature, although I understand it's painful to keep up with gcc here). In the end, will we have essentially the same bootstrapping procedure ? I think there is a high value in depending on a minimal amount of host tools, building toybox with host tools and isolating the build is great for repeatability and reliability of the build across multiple host OSes. On a side note, I wonder if there is knowledge we can borrow from the openembedded project - particularly where it comes to targeting the compiler for a specific arch, configuring the kernel for that arch and putting the qemu invocation together. See: ??http://git.openembedded.org/openembedded-core/tree/meta/conf/machine/ And the include directory for fun. Honestly there are a variety of reasons why I prefer using an LFS type of build (but automated) based on aboriginal over using the yocto approach of cross compiling all the way up the stack, but I think openembedded have come a long way in terms of configuring the base kernel/compiler/qemu and it would be great to leverage that. It also has a similar approach to aboriginal here (inasmuch as it uses a machine conf, like aboriginals target files). Best Regards, ? ? -Tristan > The thing is, once you take out the toolchain build (and replace it > with > Rich Felker's musl-cross-make), there's only 5 other packages it > builds > (toybox, busybox, make, bash, distcc). All of them compile reasonably > easily, and as toybox adances at least 2 of them should go away. The > infrastructure aboriginal linux provides for them is WAY OVERKILL for > what's left for it to do (as evidenced by > https:/github.com/j-core.org/mkroot working fine without any of it). > > What Aboriginal Linux has is: > > 1) The ./download.sh infrastructure to download and patch source > code, > and maintain an extracted "package cache" for parallel builds. This > includes setup and teardown wrappers to _use_ the package cache (and > set > up the cross compiler path, and so on). > > 2) The host-tools.sh "airlock step" and environment sanitization > logic > (sources/variables.sh) for doing "hermetic builds" (I.E. > portable/reproducible builds that provide their own known build > environment). > > 3) target configs with matching gcc tuple (and flags), kernel config > (and KARCH), and qemu command line (and kernel command line). > > 4) Wrapper script to launch qemu with some infrastucture around it > (most > of which supports build control images; note that > http://landley.net/aboriginal/build-control to _create_ build control > images is a separate project with its own git repo). > > 5) Busybox and uClibc config files (now legacy info). > > 6) A dozen package build recipes (in sources/sections), 2/3 which > (ccwrap.sh, gcc.sh, musl.build, uClibc.build, binutils.build, > linux-headers.sh, uClibc++.build, elf2flt.sh) are obsolete if we use > Rich's toolchain instead of building our own. > > 7) The miniconfig.sh stuff > > 8) record-commands.sh > > I'm still reading through my old stuff, but that seems to be the bulk > of it. > > If you move to musl-cross-make and mkroot.sh, #5 and #6 can pretty > much > be abandoned. I can extend mkroot.sh to (optionally) build make and > distcc for a target, neither is a big deal. I need to get serious > about > toybox's built-in shell. > > I can break out #1 into its own project. I hadn't yet because it > seems > like overkill: mkroot doesn't do it and hasn't needed it? Still, Jeff > was hitting the lack of this one last week... > > I'm already porting #2 (the host-tools.sh stuff) into the toybox > build. > Maybe there should be a "scripts/hermetic.sh" to set up a hermetic > build > environment, maybe it should be an install target, not sure yet. > (It's > not _just_ an install, there's a chroot-like step to change the $PATH > and unset all unrecognized environment variables checking the > whitelist...) The record-commands.sh stuff should should go in there > too, it's separate but related. > > I should throw miniconfig at the kernel again and see if it sticks. > (It > won't, but as far as I'm concerned reposting it with explanation > annually is probably good enough.) > > That leaves #3 and #4 which I can maybe wrap up together as their own > thing? Haven't decided about that bit yet. Maybe it belongs alongside > mkroot? > > Rob > _______________________________________________ > Aboriginal mailing list > Aboriginal at lists.landley.net > http://lists.landley.net/listinfo.cgi/aboriginal-landley.net From rob at landley.net Mon Sep 12 18:02:22 2016 From: rob at landley.net (Rob Landley) Date: Mon, 12 Sep 2016 13:02:22 -0500 Subject: [Aboriginal] Refactoring/recycling In-Reply-To: <1473680514.3020.1.camel@codethink.co.uk> References: <1790ba2d-6a47-d006-1202-d3c7f1bfa4ee@landley.net> <1473680514.3020.1.camel@codethink.co.uk> Message-ID: <6404d250-b06d-9aeb-6ee3-79e74e305a2e@landley.net> On 09/12/2016 06:41 AM, Tristan Van Berkom wrote: > On Fri, 2016-09-09 at 19:28 -0500, Rob Landley wrote: >> I've been breaking aboriginal linux down for parts. It's just too >> much >> of a giant hairball, despite my attempts to separate it into layers. >> > > Hi Rob, > > So just to understand, since I have some interesting work based on this > by now, what is going to be the end result of using the musl-cross-make > approach in Aboriginal ? The project has been mothballed for several months while I tried to decide how to move forward, and now I've got an approach I want to try. So what this means is development is resuming, albeit in a different direction. The fundamental constraints are: 1) I will NEVER host GPLv3 binaries anywhere on my own dime 2) my old toolchain is now far enough behind the kernel build is breaking badly every release 3) LLVM (especialy lld, without which you're stuck using GPLv3 binutils) isn't ready yet When LLVM becomes ready, I may reassemble something like the original aboriginal linux. But for now, I _have_ to break it up into packages I can develop and packages I passively consume (I'll send back bug reports but not code). And if I'm going to break it up anyway, I might as well reexamine the design and see what belongs where. Note: if my aversion to GPLv3 was the kind of thing I "got over", I would be a Windows developer. This is a "hell no, death first" kind of thing. It's 2016 and I don't have a Facebook account because I don't _want_ one. I'll read a facebook page somebody links me to if it lets me without a login, I'll sit down at somebody else's windows machine to web surf or play a game. But I won't create an account or write code that only runs on windows the platform (it can be ported _to_ it). Similarly I won't host GPLv3 binaries on a site I control or write GPLv3 code in a hobbyist context (but an employer can pay me to). Given a choice between shipping GPLv3 code and shutting down Aboriginal Linux... I haven't put out a release since the 4.3 kernel for a reason. > How much will things change from the > perspective of the Aboriginal end user ? I should still provide a turnkey solution for building minimal native development environment system images, but it's going to involve prerequisite packages. One of which is Rich's musl-cross-make. You should still be able to download prebuilt binaries of all the bits, but some of them may be on different sites and require assembly. (I can post a shell script to wget and collate if it comes to that.) > If I understand correctly, this will mean: > > o GPLv3 toolchain I won't host binaries of GPLv3 code, but Rich has agreed to host binaries of both static cross compilers and native compilers, once I've pointed him at the configurations I've made work for the target list I've gotten running. If you remove toolchain building from what Aboriginal Linux does, what's left of the build stages doesn't make design sense, so I'm redesigning it, and moving bits of it into other projects. (Toybox should probably have a "make cross_airlock PREFIX=/path" build target, for example, replacing host-tools.sh. For the moment symlinking host binaries out of your $PATH for what it used to build busybox for, but it does mean that the list of remaining commands toybox needs to replace would be maintained within toybox, which is a step in the right direction.) In a way, toybox becomes a prerequisite on the level of musl-cross-make, but toybox was already a prerequisite. The real difference is musl-cross-make downloads its own source packages, so it's a separate build. Similarly, my new much simpler root filesystem build script, mkroot.sh, also downloads its own packages. https://github.com/j-core/mkroot/blob/master/mkroot.sh I'm also thinking of breaking out the download.sh infrastructure into its own package, so you can use the package cache stuff from other builds: http://landley.net/aboriginal/FAQ.html#debug_package_cache Right now the build control image infrastructure has a hand-copied version that falls out of sync; that should be cleaned up. I can have mkroot.sh try to source an include file (and possibly offer it to Rich as well, and maybe see if buildroot wants to use it), and fall back to the much simpler built-in download function (lines 19-33 of the current script) if it's not found. So musl-cross-make provides the toolchain, mkroot.sh provides the initramfs, and the third part I need is something to provide kernel config and qemu wrapper script for a given target (the sources/targets info in the current stuff) and package everything appropriately. Speaking of system images, there's a glue layer where I get a compiler tarball from Rich and need to repackage it as a squashfs file, which involves having (or building) mksquashfs on the host as a depencency. Possibly I can make puppy eyes at Rich to host system image tarballs too. :) > o Less deviation from upstream gcc (as I understand there had been > some patches to make gcc behave differently for aboriginal, while > the musl-cross-make patches are mostly upstreamed) My compiler was GPLv2. I will never ship GPLv3 binaries. (This is part of the reason I'm slowly switching my interest to Android from conventional Linux: GPLv3 is a proprietary license and I'd only work on code under that license if paid to do so by a large corporation whose legal department stood between me and the FSF loonies. So far, the corporations all feel the same way about it I do.) Your GPLv3 fork is just that: a fork. It's part of the reason I mothballed Aboriginal Linux, I assumed that the userbase would fragment and half the people wouldn't be using my code so why bother fixing up the old toolchains? But if Rich is maintaining a toolchain that can provide working native compilers, then I don't have to deal with that area at all and can wash my hands of it entirely and be a passive consumer of that output, downloading it the same way I download the flash plugin or decss; via an automated script that happens behind the scenes so I don't get any of it on me personally. > Are you planning to continue with ccwrap.c, allowing for the > relocatable cross compiler ? (I think this was a pretty cool feature, > although I understand it's painful to keep up with gcc here). I hadn't planned on it, but I can ask Rich what his opinions are? I _think_ if you download his toolchain binaries they'll automatically sysroot themselves in whatever directory they're running from, but I haven't tried it? > In the end, will we have essentially the same bootstrapping procedure ? In flux at the moment. There should be a turnkey solution ala build.sh, but it may take a while to get back there. > I think there is a high value in depending on a minimal amount of host > tools, building toybox with host tools and isolating the build is great > for repeatability and reliability of the build across multiple host > OSes. Which is why I'm migrating that functionality into toybox itself. :) > On a side note, I wonder if there is knowledge we can borrow from the > openembedded project - particularly where it comes to targeting the > compiler for a specific arch, configuring the kernel for that arch and > putting the qemu invocation together. > > See: > http://git.openembedded.org/openembedded-core/tree/meta/conf/machine/ I've looked at buildroot, at debian's supported targets, and like 5 other places. Never looked at openembedded (outside of drilling down from yocto/tizen) but only because they never had anything particularly interesting target-wise. (It's mostly arm forks, and all that should go device tree and stop being silly.) QEMU really needs to grow a mode where you go "-dtb blah.dtb" and it parses that and emulates the devices described by it, and also passes that same dtb on to the kernel the way bootloaders do so the kernel can bind to devices from the same data file qemu is using to add those devices. And THAT is your entire board emulation, "-M generic" > And the include directory for fun. > > Honestly there are a variety of reasons why I prefer using an LFS type > of build (but automated) based on aboriginal over using the yocto > approach of cross compiling all the way up the stack, but I think > openembedded have come a long way in terms of configuring the base > kernel/compiler/qemu and it would be great to leverage that. It also > has a similar approach to aboriginal here (inasmuch as it uses a > machine conf, like aboriginals target files). If you prefer openembedded, feel free to use it? > Best Regards, > -Tristan Rob From tristan.vanberkom at codethink.co.uk Tue Sep 13 03:32:22 2016 From: tristan.vanberkom at codethink.co.uk (Tristan Van Berkom) Date: Tue, 13 Sep 2016 12:32:22 +0900 Subject: [Aboriginal] Refactoring/recycling In-Reply-To: <6404d250-b06d-9aeb-6ee3-79e74e305a2e@landley.net> References: <1790ba2d-6a47-d006-1202-d3c7f1bfa4ee@landley.net> <1473680514.3020.1.camel@codethink.co.uk> <6404d250-b06d-9aeb-6ee3-79e74e305a2e@landley.net> Message-ID: <1473737542.3020.47.camel@codethink.co.uk> Hi Rob, Thanks for clarifying and answering some of my questions. If Aboriginal cannot continue in it's present form (or at least not for the immediate future), it still has been a great demonstration of how an OS should ideally be bootstrapped and built deterministically. Thank you for this. Few comments in line... On Mon, 2016-09-12 at 13:02 -0500, Rob Landley wrote: > On 09/12/2016 06:41 AM, Tristan Van Berkom wrote: > > > > On Fri, 2016-09-09 at 19:28 -0500, Rob Landley wrote: > > > > > > I've been breaking aboriginal linux down for parts. It's just too > > > much > > > of a giant hairball, despite my attempts to separate it into > > > layers. > > > > > Hi Rob, > > > > So just to understand, since I have some interesting work based on > > this > > by now, what is going to be the end result of using the musl-cross- > > make? > > approach in Aboriginal ? > The project??has been mothballed for several months while I tried to > decide how to move forward, and now I've got an approach I want to > try. > So what this means is development is resuming, albeit in a different > direction. > > The fundamental constraints are: > > 1) I will NEVER host GPLv3 binaries anywhere on my own dime > > 2) my old toolchain is now far enough behind the kernel build is > breaking badly every release > > 3) LLVM (especialy lld, without which you're stuck using GPLv3 > binutils) > isn't ready yet > > When LLVM becomes ready, I may reassemble something like the original > aboriginal linux. But for now, I _have_ to break it up into packages > I > can develop and packages I passively consume (I'll send back bug > reports > but not code). And if I'm going to break it up anyway, I might as > well > reexamine the design and see what belongs where. > > Note: if my aversion to GPLv3 was the kind of thing I "got over", I > would be a Windows developer. This is a "hell no, death first" kind > of > thing. It's 2016 and I don't have a Facebook account because I don't > _want_ one. I'll read a facebook page somebody links me to if it lets > me > without a login, I'll sit down at somebody else's windows machine to > web > surf or play a game. But I won't create an account or write code that > only runs on windows the platform (it can be ported _to_ it). > Similarly > I won't host GPLv3 binaries on a site I control or write GPLv3 code > in a > hobbyist context (but an employer can pay me to). Ok. Rob, I am getting the sense that you misread me as hostile in some way, I really hope not, its was not my intention to be provocative. I really just wanted to get the bottom line of the Aboriginal story and how it can affect end users like myself. When I started my work you made it clear that you would not distribute GPLv3 binaries on infrastructure under your control - It seems this stance of yours has changed, and that now you are unwilling to incorporate and host scripts (under any license) which they themselves provide a mechanism for *building* GPLv3 code. This is your choice and I *really* don't blame you for it, really. I will say though, honestly I find it frustrating that a few times (not every time) I try to have a technically constructive conversation, it seems to side track into a GPL discussion, which frankly does not interest me (I have had my share of heated discussion with rms and this is just not my kind of thing, sorry). [...] > My compiler was GPLv2. I will never ship GPLv3 binaries. (This is > part > of the reason I'm slowly switching my interest to Android from > conventional Linux: GPLv3 is a proprietary license and I'd only work > on > code under that license if paid to do so by a large corporation whose > legal department stood between me and the FSF loonies. So far, the > corporations all feel the same way about it I do.) > > Your GPLv3 fork is just that: a fork. It's part of the reason I > mothballed Aboriginal Linux, I assumed that the userbase would > fragment > and half the people wouldn't be using my code so why bother fixing up > the old toolchains? To be frank here, a large part of my motivation for doing this work in public was due to your stating to me on irc that you would consider including an optional GPLv3 toolchain build in Aboriginal proper, while conceding that the GPLv2 toolchain was bitrotting and users need something more modern. It was certainly _not a fork_ in the traditional sense (only a "fork" as far as github has bastardized the actual meaning of the word). It is in fact only a proposed patch to Aboriginal which you are free to accept or not. Were it a fork, I would not have went to such lengths to allow builds of both toolchains and the scripts would be cleaner this way of course. [...] > > Honestly there are a variety of reasons why I prefer using an LFS > > type > > of build (but automated) based on aboriginal over using the yocto > > approach of cross compiling all the way up the stack, but I think > > openembedded have come a long way in terms of configuring the base > > kernel/compiler/qemu and it would be great to leverage that. It > > also > > has a similar approach to aboriginal here (inasmuch as it uses a > > machine conf, like aboriginals target files). > If you prefer openembedded, feel free to use it? I think I just plainly stated above that I prefer a from scratch approach based on an Aboriginal bootstrap over cross compiling all the way up the stack, sorry if I was not clear enough: I'm only mentioning the openembedded stuff because I think there is some valuable knowledge which can be salvaged from the yocto train wreck while creating a superior solution (to put things a bit more plainly). In any case, I'm *really* not bitter about not landing my patches in Aboriginal proper, and I look forward to seeing what comes together with musl-cross-make and the next generation of Aboriginal, I'm sure it will be great. Best Regards, ? ? -Tristan From rob at landley.net Tue Sep 13 21:40:38 2016 From: rob at landley.net (Rob Landley) Date: Tue, 13 Sep 2016 16:40:38 -0500 Subject: [Aboriginal] Refactoring/recycling In-Reply-To: References: <1790ba2d-6a47-d006-1202-d3c7f1bfa4ee@landley.net> <1f6605ab-e32d-f6e8-52e7-02f4a896f799@landley.net> Message-ID: <1be1f5ab-be5e-4152-38df-5c6f0d71ca2c@landley.net> On 09/12/2016 03:23 AM, Alessio Igor Bogani wrote: > Hi Rob, > > On 11 September 2016 at 07:17, Rob Landley wrote: >> On 09/09/2016 07:28 PM, Rob Landley wrote: >>> easily, and as toybox adances at least 2 of them should go away. The >>> infrastructure aboriginal linux provides for them is WAY OVERKILL for >>> what's left for it to do (as evidenced by >>> https:/github.com/j-core.org/mkroot working fine without any of it). > [...] > > I guess it uses a cross-compiler, right? So what if I could want add > an autotools based software? Do you mean cross compiling something that uses autotools? If so, that's why #2 (breaking out the airlock step and hosting it somewhere) is still interesting. I'm currently trying to merge that into the toybox build. If you mean trying to somehow shove autotools into mkroot itself so that a simple ~200 line shell script that mostly avoids external dependencies grows a dependency on autoconf (which for gcc 4.2.1 turned a 2,483 line configure.in file into a 7,823 line configure script)... that would be completely insane and defeat the purpose of mkroot. > Setup qemu and distcc to work side by side is a very good things to me > and it isn't an overkill at all. In fact it is the reason I'm still > following this project. All those steps are things that still need to be done. I'm trying to break up the project so you can do those things more simply and conveniently. > [...] >> launch init. But now there's CONFIG_DEVTMPFS_MOUNT (and I have a patch >> to make it apply to initramfs, although when I submitted it upstream >> they didn't want it and I lost interest because it works for me so if >> they don't want it, I'm ok with that). > > Could you pinpoint me to the patch? It could be useful for me too. Attached, although I might wind up taking a different approach. (Screw CONFIG_DEVTMPFS_MOUNT buried down in drivers/base and applying to legacy fallback root, what I really want is usr/Kconfig to have a CONFIG_INITRAMFS_AUTOMOUNT that not only mounts the standard filesystems (/dev, /dev/pts, /proc, /sys) but creates directories for them if they're not there. This is bog-standard plumbing, why go halfway? Your init script still needs to bring the network up (and ifconfig lo 127.0.0.1)... >> I suppose I should post miniconfig.sh again too. (Annually if necessary, >> since they'll never take it and I'm pretty sure the TEN YEARS since my >> initial 3 posts submitting miniconfig shows I'm not interested in doing > > Have you ever considered to rework it and integrate it to "make tinyconfig"? Here are a couple long threads where people basically told me "I know it works for you but you must completely rewrite it for me because I say so, and no I won't do it myself that's crazy talk": http://lkml.iu.edu/hypermail/linux/kernel/0511.2/0479.html http://lkml.iu.edu/hypermail/linux/kernel/0511.2/1644.html Here's me coming back a year later to see if they'd changed their minds: http://lkml.iu.edu/hypermail//linux/kernel/0607.0/1714.html Here's somebody's blog entry doing their own writeup on the technique: http://www.brain-dump.org/blog/entry/109/Documenting_kernel_configuration_files_and_using_the_miniconfig_format Here's the FAQ entry i wrote explaining it so I had something to point people at: https://landley.net/aboriginal/FAQ.html#dev_miniconfig Here's where the kernel documentation includes a description of the technique they declined to merge: https://www.kernel.org/doc/Documentation/kbuild/kconfig.txt Moral: Howard Aiken (the guy who was to Grace Hopper what Charles Babbage was to Ada Lovelace) was right: http://www.brainyquote.com/quotes/quotes/h/howardaike101540.html > Thank Rob for all! > > Ciao, > Alessio Rob -------------- next part -------------- A non-text attachment was scrubbed... Name: 1.patch Type: text/x-diff Size: 466 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 2.patch Type: text/x-diff Size: 1030 bytes Desc: not available URL: