From r.majdodin at gmail.com Fri Mar 2 10:56:40 2018 From: r.majdodin at gmail.com (Ruhollah Majdoddin) Date: Fri, 2 Mar 2018 11:56:40 +0100 Subject: [mkroot] Contribution Message-ID: Hello, I have spent the past month over mkroot (and native build with QEMU), now I have free time for one or two months. Where can I contribute? If toybox has more priority now (I see more activity there) please tell me where can I contribute there (I have browsed through the roadmap and other documentation). Regards Ruhollah -------------- next part -------------- An HTML attachment was scrubbed... URL: From rob at landley.net Sat Mar 3 19:19:21 2018 From: rob at landley.net (Rob Landley) Date: Sat, 3 Mar 2018 13:19:21 -0600 Subject: [mkroot] State of the whatsis. Message-ID: I haven't posted here much because I wanted to migrate the old mailing list membership to the new one first, and I finally sat down spent the 45 minutes cutting and pasting individual email addresses in dreamhost's web interface to do that. (No I don't have access to the command line tools for this, because Dreamhost). I gave an ELC talk about mkroot last year: https://www.youtube.com/watch?v=Sk9TatW9ino But I was soooo jetlagged I only I covered maybe half the material I meant to. I'm thinking is trying to do a series of shorter videos covering portions of this material, maybe with corresponding text writeups for the people who prever reading to videos. (The limiting factor on my work time is generally eyestrain, so stuff with an audio component where I don't have to focus too clearly on the screen work pretty well for me as a break from real work, and youtube lets you speed them up all the way to 2x if you want to, which is fine if the speaker doesn't have a strong accent. But I'm aware some people have strong opinions the other way.) Anyway, I'm ready to cut a mkroot release with the 4.14 kernel and toybox 0.76. I haven't yet because I'm poking at the x32 stuff, but I should probably punt that to next release. Anybody want to give feedback about what they want out of the next version? I haven't hooked up the native toolchains yet or reproduced aboriginal linux's build control image infrastructure yet, I've got a few things competing for my attention there: 1) Replace the remaining busybox commands with toybox. (If that includes the shell and ash, it's a big deal. If the first pass doesn't, much less work.) 2) Reproduce full linux from scratch build with current(ish) LFS, and then maybe some BLFS stuff too. 3) Extend the toybox test suite to have tests that run as root in a known environment. (Testing stuff like "top" is kinda crazy however you go about it...) 4) Wire up the distcc infrastructure again (I tried and current distcc has fallen off a cliff of gratuitous complexity, it's easier to write my own in tobyox). 5) Add a simple strace to toybox. (Static native binaries last time were dropbear and strace, 90% of the complexity of strace is decoding structures and such, a quick version that gives you a hex dump of that sort of thing would be a lot easier. But it's still probably going to use a file produced from the kernel source code with an evil "sed" invocation since there's no proper syscall list exported by that, and I need to make sure that's squashed to a scenes a faire representation like the headers are...) So, new list, big roadblock removed and I'm trying to be more active here now. (I should explain more personal work-related context on my patreon. I'm already trying to catch my blog up because I promised that there...) Rob From rob at landley.net Sat Mar 3 19:22:38 2018 From: rob at landley.net (Rob Landley) Date: Sat, 3 Mar 2018 13:22:38 -0600 Subject: [mkroot] x32 mcm-buildall.sh final patch In-Reply-To: <1519761729.26577.19.camel@vocatus.pub> References: <1519761729.26577.19.camel@vocatus.pub> Message-ID: <3e529b48-f5e2-f94a-784e-71d8ec8ad2af@landley.net> On 02/27/2018 02:02 PM, Alain Toussaint wrote: > Hi, > > Here's the final patch. Tested, work as intended for mcm-buildall.sh and build both variants of > x86_64 ABI (64bits and x32). > > Minor issue with cross.sh is that it doesn't distinguishes between both ABI: > > testbuild at johnson:~/git/mkroot$ ./cross.sh? > aarch64 armv5l armv7l armv7m armv7r i486 i686 microblaze mips mips64 mipsel powerpc powerpc64 > powerpc64le s390x sh2eb sh4 x86_64 Yeah, a while back I started fiddling with manually setting CROSS_SHORT. Needed a bit of passthrough to do it at all: --- a/mkroot.sh +++ b/mkroot.sh @@ -18,7 +18,7 @@ fi # Clear environment variables by restarting script w/bare minimum passed throug [ -z "$NOCLEAR" ] && exec env -i NOCLEAR=1 HOME="$HOME" PATH="$PATH" \ - CROSS_COMPILE="$CROSS_COMPILE" "$0" "$@" + CROSS_COMPILE="$CROSS_COMPILE" CROSS_SHORT="$CROSS_SHORT" "$0" "$@" # Parse arguments: assign NAME=VALUE to env vars and collect rest in $MODULES [ "$1" == "-n" ] && N=1 && shift @@ -50,7 +50,7 @@ else echo "Cross compiling" CROSS_PATH="$(dirname "$(which "${CROSS_COMPILE}cc")")" CROSS_BASE="$(basename "$CROSS_COMPILE")" - CROSS_SHORT="${CROSS_BASE/-*/}" + [ -z "$CROSS_SHORT" ] && CROSS_SHORT="${CROSS_BASE/-*/}" if [ -z "$CROSS_PATH" ] then echo "no ${CROSS_COMPILE}cc in path" >&2 Mostly prompted by aarrcchh6644 being a really stupid name and I'm not humoring it. But now I'm thinking maybe I should have some sort of CROSS=short/long-name- syntax instead? The larger question here is "toolchain the kernel builds with and toolchain userspace builds with are different". Which is a recurring problem, and will probably require some design work. And the OTHER problem is that x86_64-*-native now resolves to two toolchains. (Which was already kind of a problem for architectures that want both a nommu version and a with-mmu version for otherwise the same processor. Sometimes you have "armv7r" distinguishing that, and sometimes you don't ala microblaze.) Rob From rob at landley.net Sat Mar 3 20:05:07 2018 From: rob at landley.net (Rob Landley) Date: Sat, 3 Mar 2018 14:05:07 -0600 Subject: [mkroot] Contribution In-Reply-To: References: Message-ID: <4325287b-4b0c-07e4-2508-a47e5d6c41f6@landley.net> On 03/02/2018 04:56 AM, Ruhollah Majdoddin wrote: > Hello, > I have spent the past month over mkroot (and native build with QEMU), now I have What do you think of it so far? (I need to figure out where to stick more documentation. Possibly github's project wiki? I'm trying to do this one as an actual github project, because I've never properly familiarized myself with all the plumbing they offer...) > free time for one or two months. Where can I contribute? > If toybox has more priority now (I see more activity there)? please tell me > where can I contribute there (I have browsed through the roadmap and other > documentation). > Regards > Ruhollah Hooking up the native toolchains here would be nice, but the lack of a non-gpl "make" is why I haven't so far. (Eventually I need to implement make for toybox but that's a solid couple months work. It's also possible I'll need to implement cmake and/or ninja, but I hope not.) Getting mkroot to build with alternative toolchains (such as the Android NDK or https://toolchains.bootlin.com/ or http://ellcc.org or https://www.kernel.org/pub/tools/crosstool/) might be nice tool. (I'm aware most of those don't provide native compilers, and yes it is sad.) What would be really nice for me personally is if you could figure out what's wrong with qemu's console I/O when serial points to stdin and I do echo/sleep/echo/sleep chains at it. I want to smoketest mkroot with something vaguely like: for i in $(./cross); do (sleep 5; echo date; sleep 1; echo tail '/dev/?da' ; sleep 1; echo ifconfig; sleep 1; echo exit; sleep 1) | ./run.sh $i -hda log.txt | tee $i-testlog.txt ; done But when I try it, current qemu built from git hangs after a command or two. :( (In theory, driving a qemu child process via tcl/expect or similar is really useful. In practice it's never quite worked right whenever I've tried it and I've had to do ssh or booted with an init script that told it what to do and then to shut down at the end, ala the old https://landley.net/aboriginal/control-images stuff.) Rob From rob at landley.net Sat Mar 3 20:06:08 2018 From: rob at landley.net (Rob Landley) Date: Sat, 3 Mar 2018 14:06:08 -0600 Subject: [mkroot] [Aboriginal] Migrating aboriginal->mkroot list. In-Reply-To: <1519252311.1610.8.camel@vocatus.pub> References: <1519252311.1610.8.camel@vocatus.pub> Message-ID: On 02/21/2018 04:31 PM, Alain Toussaint wrote: > Le mercredi 21 f?vrier 2018 ? 16:25 -0600, Rob Landley a ?crit?: >> I'm going to try to get a second mkroot release out this weekend, and as part of >> that I'm shutting down the old aboriginal list and migrating the subscribers >> here to the mkroot list. > > Go right ahead :) > >> >> ? https://twitter.com/landley/status/964620648050982912 >> > > No big issue here, I've been on gcc 7+ (LFS-SVN) for over a year and a half. head> Did you see the "arm requires perl again", "x86-64 doesn't build without libtool" bits earlier in that twitter thread? The kernel is growing dependencies faster than I've had a chance to go in and trim them. :( The comment at the end about toolchains is because I defended the 4.2.1 toolchain for a long time, ala https://github.com/landley/aboriginal/blob/master/sources/patches/linux-hack.patch and https://github.com/landley/aboriginal/blob/master/sources/patches/gcc-core-macrosity.patch and https://github.com/landley/aboriginal/blob/master/sources/patches/linux-fixsh4.patch and so on. When you _stop_ defending this sort of thing, problems accumulate. Bit rot is a real thing when one half an interface changes and the other doesn't and there's no regression testing, the old code no longer works in the new environment. It could be an API subtly changing, a tool that processes input data to produce output data having the input _or_ output formats change, or you could have a tool/api/format get replaced by a different one and the world migrating en masse so your old code no longer _applies_. And of course there's the problem of basically the same (or equivalent) code accumulating new "required" dependencies that your environment doesn't have/want. (I.E. "The systemd problem.") Rob From alain at vocatus.pub Sat Mar 3 20:29:07 2018 From: alain at vocatus.pub (Alain Toussaint) Date: Sat, 03 Mar 2018 15:29:07 -0500 Subject: [mkroot] [Aboriginal] Migrating aboriginal->mkroot list. In-Reply-To: References: <1519252311.1610.8.camel@vocatus.pub> Message-ID: <1520108947.32478.1.camel@vocatus.pub> > Did you see the "arm requires perl again", "x86-64 doesn't build without > libtool" bits earlier in that twitter thread? Yep. > The kernel is growing dependencies > faster than I've had a chance to go in and trim them. :( Indeed but I haven't a clue what to do next. Al From alain at vocatus.pub Sat Mar 3 20:38:58 2018 From: alain at vocatus.pub (Alain Toussaint) Date: Sat, 03 Mar 2018 15:38:58 -0500 Subject: [mkroot] x32 mcm-buildall.sh final patch In-Reply-To: <3e529b48-f5e2-f94a-784e-71d8ec8ad2af@landley.net> References: <1519761729.26577.19.camel@vocatus.pub> <3e529b48-f5e2-f94a-784e-71d8ec8ad2af@landley.net> Message-ID: <1520109538.32478.3.camel@vocatus.pub> > The larger question here is "toolchain the kernel builds with and toolchain > userspace builds with are different". Yeah, on that count, I need to do a patch for the x86_64 kernel build to include the x32 compatiblities settings. That being said, when I was hacking the prototype, the kernel got built by the x32 toolchain but I don't know (yet) if a kernel built by the x32 toolchain would see past 4GB. It did build fine and worked under qemu. For bare metal, I already had a 64bit kernel with the suitable options on a multiboot usb key. > And the OTHER problem is that x86_64-*-native > now resolves to two toolchains. That is the bit I was refering to which is why I set the x86_64 arch to x32 on the first patch so that running ./cross.sh x86_64 ./mkroot dynamic kernel built an x32 kernel and userspace. Alain From rob at landley.net Mon Mar 5 16:36:06 2018 From: rob at landley.net (Rob Landley) Date: Mon, 5 Mar 2018 10:36:06 -0600 Subject: [mkroot] Contribution In-Reply-To: References: Message-ID: On 03/02/2018 04:56 AM, Ruhollah Majdoddin wrote: > Hello, > I have spent the past month over mkroot (and native build with QEMU), What do you think of it so far? (It's a newish project I haven't gotten too much feedback on yet...) > now I have > free time for one or two months. Where can I contribute? > If toybox has more priority now (I see more activity there)? please tell me > where can I contribute there (I have browsed through the roadmap and other > documentation). Mkroot needs a lot of work. I haven't got the native toolchain working under it yet (partly for design reasons, there's no non-gpl make, and should ninja or cmake be in there too?), the old build control image infrastructure at https://landley.net/aboriginal/control-images needs to be redone in the new context, the old Linux From Scratch build image there needs to be recreated using current LFS... But I'm not sure any of that's a good starting place for a new developer? Reproducing the existing build with other toolchains might be nice too (android NDK, bootlin's toolchains, the crosstool images on kernel.org, https://ellcc.org and so on), but none of them provide native compilers, but they might start and it would be very nice to have an llvm build baseline. For toybox I want to use mkroot as a way to run tests requiring root access and a known build environment, but again that's not necessarily a good starting point for new developers. (How you do proper "top" tests is a hard problem.) Fixing existing test failures might be, though? (Or at least diagnosing them, I haven't had time to even sort which test scripts pass and which fail, and which ones are actually providing reasonable test coverage and which aren't yet. It's on the todo list...) Something I've hit that might be worth a look is actually a qemu issue. I test new mkroot builds with something like: for i in $(./cross.sh); do (sleep 5; echo date; sleep 1; echo ifconfig; sleep 1; echo tail /dev/?da; sleep 1; echo exit; sleep 2) | ./run.sh qemu-$i | smokelog-$i.txt; done But when I do that, qemu often _hangs_ with current -git. Something about qemu's stdio console handling is wonky when dealing with pipes instead of pty instances, and I'm not sure what. Thanks for your interest, Rob From rob at landley.net Mon Mar 5 22:55:48 2018 From: rob at landley.net (Rob Landley) Date: Mon, 5 Mar 2018 16:55:48 -0600 Subject: [mkroot] [Aboriginal] Building a floppy rescue set like BG did? + "Android self-hosting" idea In-Reply-To: <1b22ac5e8ce9bb25f452bbd0d7ce7084@pricom.com.au> References: <20170314120349.4577e7be@monolith.infinux.org> <7306b0a4c6d37a77f60c873895ca8f28@pricom.com.au> <8d1392c0-0554-7db5-a4ca-3fe50e434d4c@landley.net> <983bfd081c5978e7942581289361c03e@pricom.com.au> <3d0dad55-d768-9c9e-7f66-39131e456bcc@landley.net> <096155cda8bf79de3d226697b4e35904@pricom.com.au> <1b22ac5e8ce9bb25f452bbd0d7ce7084@pricom.com.au> Message-ID: <4ccb2e6f-5e40-1940-d6c7-7368de74b442@landley.net> On 03/04/2018 11:53 PM, Philip Rhoades wrote: > Rob, > > I am just replying to something from a year ago for a potential restart - it > appears that things are making slow progress with mkroot? - is it worth me > testing this stuff out again from scratch? > > Regards, > > Phil. I hope mkroot just got unblocked. I switched jobs to something with more defined hours (so I have evenings and weekends when I'm NOT working) in January, and migrated the aboriginal mailing list to mkroot this past weekend. The restart from aboriginal to mkroot happened because somebody did an external toolchain builder that actually gives usable native compilers, which is the missing part of bootlin/buildroot/crosstool/ellcc/android ndk... The old last gplv2 releases were getting progressively more out of date even before the kernel moved its compiler requirements (the last gplv2 release was 4.2.1, now it's gcc 4.5 ala http://lkml.iu.edu/hypermail/linux/kernel/1802.1/02253.html) Making the old tools build new software was constant work, which I didn't have time to keep up with. I'm still spread thinner than I like, but moving forward again. Rob > On 2017-03-25 04:56, Philip Rhoades wrote: >> Rob, >> >> >> On 2017-03-25 03:54, Rob Landley wrote: >>> On 03/24/2017 09:36 AM, Philip Rhoades wrote: >>>> Rob, >>>> On 2017-03-24 06:56, Rob Landley wrote: >>>>> On 03/14/2017 06:11 PM, Philip Rhoades wrote: >>>>>> Even if netcat works - I am still interested in building a floppy-booted >>>>>> AL system! >>>>> >>>>> You're not fitting the native toolchain on a floppy (the /usr/include >>>>> headers alone _compress_ to multiple megabytes), and if you skip the >>>>> native toolchain you might as well use the much simpler >>>>> https://github.com/landley/mkroot build. >>>> >>>> >>>> Thanks for that but see output below - although running make in the >>>> ./build/toybox-0.7.3 dir worked OK . . >>> >>> Let's see, that would be... >>> >>>> Error output: >>>> >>>> scripts/make.sh >>>> Generate headers from toys/*/*.c... >>>> Make generated/config.h from .config. >>>> generated/flags.h Compile >>>> >>> toybox......................................................................................................................................................../home/floppy_booted/toybox/airlock/ld: >>> >>>> cannot find -lselinux >>>> /home/floppy_booted/toybox/airlock/ld: cannot find -lcrypto >>> >>> Huh. What distro are you building this on? >> >> >> Fedora 25 x86_64 >> >> >>> I'd like to try to reproduce >>> it here. In scripts/make.sh toybox does test builds to see which >>> libraries are there, and only adds the ones it can find to the link. >>> This implies that it's seeing different libraries at probe time than it >>> is at build time. >> >> >> Right. >> >> >>> When I build here, I get: >>> >>> scripts/make.sh >>> Generate headers from toys/*/*.c... >>> generated/newtoys.h Library probe......... >>> Make generated/config.h from .config. >>> generated/flags.h generated/globals.h generated/tags.h generated/help.h >>> >>> Which is 3 more headers being generated at the end than yours showed. >>> This implies that something did a build in build/toybox-0.7.3 (filling >>> it with temporary files) and _then_ ran mkroot.sh? >> >> >> I just deleted the created dirs and ran the script again to be sure >> that it wasn't a different result from manually running the make in >> between running the script twice but I got the same problem . . so I >> am definitely just running "mkroot.sh" in an otherwise empty >> directory. >> >> >>> Also, you deleted context: is this the airlock build or is it the target >>> build you're seeing this one? (It says "airlock" before the airlock >>> build.) Did you speciry a cross compiler? (Guessing no since the page of >>> "glibc doesn't support static linking!" warnings shouldn't happen with >>> basically any cross compiler, since none of them use glibc.) >> >> >> Attached is the full output - does that help? >> >> >>> (The airlock step is basically a smaller host-tools from aboriginal, I >>> merged it into toybox as "make install_airlock".) >> >> >> Right. >> >> >>>>> I need to finish implementing the various targets' kernel builds, do a >>>>> proper release of that, write up better documentation for it (probably a >>>>> big README since github displays that), and get the control images to >>>>> run under it. >>>> >>>> Right. >>> >>> That's basically my todo list before I have big announcements, I've just >>> been distracted by a half-dozen other things. (Bug reports from toybox >>> in android, j-core.org stuff, so far this year I've had to fly to >>> portland, tasmania, tokyo, and san francisco. Add december and I was in >>> minneapolis and san diego.) >> >> >> Tasmania!? If I had known you were in Oz it would have been good to catch up . . >> >> >>>>> I also need to update the aboriginal linux website to say that the >>>>> project's concluded and mkroot is the successor. I keep starting a >>>>> writeup and it goes off into long explanations of the history and what I >>>>> was trying to accomplish and so on... I should just finish >>>>> http://landley.net/aboriginal/history.html >>>> >>>> I think I have read that before but I will have another look to see if >>>> there is an updated version. >>> >>> There is but it's not uploaded yet since it _also_ trails off >>> midsentence. :) >> >> >> No worries . . >> >> >>>> Also, have you thought about updating your comments in a blog or >>>> something re Android from the "Embedded Linux Conference 2013"?? I find >>>> your "Android self-hosting" argument very compelling and interesting and >>>> wonder how you feel about the situation now after a few years have >>>> passed since you made that talk. >>> >>> Android merged toybox at the start of 2015, it first shipped in Marshmallow: >>> >>> ? https://lwn.net/Articles/629362/ >> >> >> Will check it out. >> >> >>> The #2 contributor to toybox is Elliott Hughes, Android's toolbox and >>> bionic maintainer, who has committed to replacing toolbox entirely with >>> toybox: >>> >>> http://lists.landley.net/pipermail/toybox-landley.net/2016-June/008484.html >> >> >> Ditto. >> >> >>> He updates the toybox roadmap more often than I do: >>> >>> ? https://github.com/landley/toybox/commits/master/www/roadmap.html >> >> >> Ditto again . . >> >> >>> Alas, I'm the bottleneck on finishing off toolbox, $DAYJOB and life have >>> been hugely distracting for the past ~8 months. (Trying to dig out of >>> that, but I need to be in San Diego again a week from monday...) >> >> >> No worries . . >> >> >>> Still, let's try to track down the failure you're seeing with mkroot. I >>> want that to work for everybody. I haven't moved over the environment >>> variable whitelisting yet, although it's basically something like: >>> >>> ? [ ! -z "$TERM" ] && exec env -i "PATH=$PATH" "$0" >> >> >> Aha!? Before I was running the script in a tmux tab and getting the >> results that I have attached.? I just tried running the line above in >> the tmux tab and the tab disappeared! - so I tried opening a new xterm >> with no tmux and running the script from there and got a different >> result: >> >> toybox-0.7.3/www/ >> toybox-0.7.3/www/about.html >> toybox-0.7.3/www/cleanup.html >> toybox-0.7.3/www/code.html >> toybox-0.7.3/www/design.html >> toybox-0.7.3/www/ext2.html >> toybox-0.7.3/www/faq.html >> toybox-0.7.3/www/footer.html >> toybox-0.7.3/www/header.html >> toybox-0.7.3/www/index.html >> toybox-0.7.3/www/license.html >> toybox-0.7.3/www/news.html >> toybox-0.7.3/www/oldnews.html >> toybox-0.7.3/www/roadmap.html >> toybox-0.7.3/www/status.html >> toybox-0.7.3/www/toycans.png >> cc -o kconfig/conf kconfig/conf.c kconfig/zconf.tab.c -DKBUILD_NO_NLS=1 \ >> ????-DPROJECT_NAME=\"ToyBox\" >> ccache: error: Could not find compiler "cc" in PATH >> kconfig/Makefile:65: recipe for target 'kconfig/conf' failed >> make: *** [kconfig/conf] Error 1 >> >> >>> (Modulo "$TERM" being reliably set in the host environment and NOT set >>> by magic /etc/profile stuff that runs even for shell scripts. I dunno, >>> maybe $USER would be better? Tested to work with my bash on ubuntu != >>> and this won't screw up on some obscure distro like RHELL 9...) >> >> >> Well not exactly RHELL 9 but still Fedora 25 . . I think the last RH I >> used was 5.2 (ie a still "free" version before RHE). >> >> >>> P.S. I'm not sure if I should get mkroot a new list, or move this one >>> over to a new name. At the moment there's not enough to see to take >>> action on either way. Working on it, but juggling 9 other things at the >>> same time... >> >> >> I am in a similar position but I am interested in making more progress >> with this stuff whenever I can so I will just try things whenever you >> have time to look at it and can suggest something. >> >> Regards, >> >> Phil. >> _______________________________________________ >> Aboriginal mailing list >> Aboriginal at lists.landley.net >> http://lists.landley.net/listinfo.cgi/aboriginal-landley.net > From phil at pricom.com.au Mon Mar 5 23:56:00 2018 From: phil at pricom.com.au (Philip Rhoades) Date: Tue, 06 Mar 2018 10:56:00 +1100 Subject: [mkroot] [Aboriginal] Building a floppy rescue set like BG did? + "Android self-hosting" idea In-Reply-To: <4ccb2e6f-5e40-1940-d6c7-7368de74b442@landley.net> References: <20170314120349.4577e7be@monolith.infinux.org> <7306b0a4c6d37a77f60c873895ca8f28@pricom.com.au> <8d1392c0-0554-7db5-a4ca-3fe50e434d4c@landley.net> <983bfd081c5978e7942581289361c03e@pricom.com.au> <3d0dad55-d768-9c9e-7f66-39131e456bcc@landley.net> <096155cda8bf79de3d226697b4e35904@pricom.com.au> <1b22ac5e8ce9bb25f452bbd0d7ce7084@pricom.com.au> <4ccb2e6f-5e40-1940-d6c7-7368de74b442@landley.net> Message-ID: Rob, On 2018-03-06 09:55, Rob Landley wrote: > On 03/04/2018 11:53 PM, Philip Rhoades wrote: >> Rob, >> >> I am just replying to something from a year ago for a potential >> restart - it >> appears that things are making slow progress with mkroot? - is it >> worth me >> testing this stuff out again from scratch? >> >> Regards, >> >> Phil. > > I hope mkroot just got unblocked. I switched jobs to something with > more defined > hours (so I have evenings and weekends when I'm NOT working) in > January, and > migrated the aboriginal mailing list to mkroot this past weekend. > > The restart from aboriginal to mkroot happened because somebody did an > external > toolchain builder that actually gives usable native compilers, which is > the > missing part of bootlin/buildroot/crosstool/ellcc/android ndk... > > The old last gplv2 releases were getting progressively more out of date > even > before the kernel moved its compiler requirements (the last gplv2 > release was > 4.2.1, now it's gcc 4.5 ala > http://lkml.iu.edu/hypermail/linux/kernel/1802.1/02253.html) Making the > old > tools build new software was constant work, which I didn't have time to > keep up > with. > > I'm still spread thinner than I like, but moving forward again. However, that all sounds positive - I will keep watching and jump back in when it seems appropriate. Regards, Phil. > Rob > >> On 2017-03-25 04:56, Philip Rhoades wrote: >>> Rob, >>> >>> >>> On 2017-03-25 03:54, Rob Landley wrote: >>>> On 03/24/2017 09:36 AM, Philip Rhoades wrote: >>>>> Rob, >>>>> On 2017-03-24 06:56, Rob Landley wrote: >>>>>> On 03/14/2017 06:11 PM, Philip Rhoades wrote: >>>>>>> Even if netcat works - I am still interested in building a >>>>>>> floppy-booted >>>>>>> AL system! >>>>>> >>>>>> You're not fitting the native toolchain on a floppy (the >>>>>> /usr/include >>>>>> headers alone _compress_ to multiple megabytes), and if you skip >>>>>> the >>>>>> native toolchain you might as well use the much simpler >>>>>> https://github.com/landley/mkroot build. >>>>> >>>>> >>>>> Thanks for that but see output below - although running make in the >>>>> ./build/toybox-0.7.3 dir worked OK . . >>>> >>>> Let's see, that would be... >>>> >>>>> Error output: >>>>> >>>>> scripts/make.sh >>>>> Generate headers from toys/*/*.c... >>>>> Make generated/config.h from .config. >>>>> generated/flags.h Compile >>>>> >>>> toybox......................................................................................................................................................../home/floppy_booted/toybox/airlock/ld: >>>> >>>>> cannot find -lselinux >>>>> /home/floppy_booted/toybox/airlock/ld: cannot find -lcrypto >>>> >>>> Huh. What distro are you building this on? >>> >>> >>> Fedora 25 x86_64 >>> >>> >>>> I'd like to try to reproduce >>>> it here. In scripts/make.sh toybox does test builds to see which >>>> libraries are there, and only adds the ones it can find to the link. >>>> This implies that it's seeing different libraries at probe time than >>>> it >>>> is at build time. >>> >>> >>> Right. >>> >>> >>>> When I build here, I get: >>>> >>>> scripts/make.sh >>>> Generate headers from toys/*/*.c... >>>> generated/newtoys.h Library probe......... >>>> Make generated/config.h from .config. >>>> generated/flags.h generated/globals.h generated/tags.h >>>> generated/help.h >>>> >>>> Which is 3 more headers being generated at the end than yours >>>> showed. >>>> This implies that something did a build in build/toybox-0.7.3 >>>> (filling >>>> it with temporary files) and _then_ ran mkroot.sh? >>> >>> >>> I just deleted the created dirs and ran the script again to be sure >>> that it wasn't a different result from manually running the make in >>> between running the script twice but I got the same problem . . so I >>> am definitely just running "mkroot.sh" in an otherwise empty >>> directory. >>> >>> >>>> Also, you deleted context: is this the airlock build or is it the >>>> target >>>> build you're seeing this one? (It says "airlock" before the airlock >>>> build.) Did you speciry a cross compiler? (Guessing no since the >>>> page of >>>> "glibc doesn't support static linking!" warnings shouldn't happen >>>> with >>>> basically any cross compiler, since none of them use glibc.) >>> >>> >>> Attached is the full output - does that help? >>> >>> >>>> (The airlock step is basically a smaller host-tools from aboriginal, >>>> I >>>> merged it into toybox as "make install_airlock".) >>> >>> >>> Right. >>> >>> >>>>>> I need to finish implementing the various targets' kernel builds, >>>>>> do a >>>>>> proper release of that, write up better documentation for it >>>>>> (probably a >>>>>> big README since github displays that), and get the control images >>>>>> to >>>>>> run under it. >>>>> >>>>> Right. >>>> >>>> That's basically my todo list before I have big announcements, I've >>>> just >>>> been distracted by a half-dozen other things. (Bug reports from >>>> toybox >>>> in android, j-core.org stuff, so far this year I've had to fly to >>>> portland, tasmania, tokyo, and san francisco. Add december and I was >>>> in >>>> minneapolis and san diego.) >>> >>> >>> Tasmania!? If I had known you were in Oz it would have been good to >>> catch up . . >>> >>> >>>>>> I also need to update the aboriginal linux website to say that the >>>>>> project's concluded and mkroot is the successor. I keep starting a >>>>>> writeup and it goes off into long explanations of the history and >>>>>> what I >>>>>> was trying to accomplish and so on... I should just finish >>>>>> http://landley.net/aboriginal/history.html >>>>> >>>>> I think I have read that before but I will have another look to see >>>>> if >>>>> there is an updated version. >>>> >>>> There is but it's not uploaded yet since it _also_ trails off >>>> midsentence. :) >>> >>> >>> No worries . . >>> >>> >>>>> Also, have you thought about updating your comments in a blog or >>>>> something re Android from the "Embedded Linux Conference 2013"?? I >>>>> find >>>>> your "Android self-hosting" argument very compelling and >>>>> interesting and >>>>> wonder how you feel about the situation now after a few years have >>>>> passed since you made that talk. >>>> >>>> Android merged toybox at the start of 2015, it first shipped in >>>> Marshmallow: >>>> >>>> ? https://lwn.net/Articles/629362/ >>> >>> >>> Will check it out. >>> >>> >>>> The #2 contributor to toybox is Elliott Hughes, Android's toolbox >>>> and >>>> bionic maintainer, who has committed to replacing toolbox entirely >>>> with >>>> toybox: >>>> >>>> http://lists.landley.net/pipermail/toybox-landley.net/2016-June/008484.html >>> >>> >>> Ditto. >>> >>> >>>> He updates the toybox roadmap more often than I do: >>>> >>>> ? https://github.com/landley/toybox/commits/master/www/roadmap.html >>> >>> >>> Ditto again . . >>> >>> >>>> Alas, I'm the bottleneck on finishing off toolbox, $DAYJOB and life >>>> have >>>> been hugely distracting for the past ~8 months. (Trying to dig out >>>> of >>>> that, but I need to be in San Diego again a week from monday...) >>> >>> >>> No worries . . >>> >>> >>>> Still, let's try to track down the failure you're seeing with >>>> mkroot. I >>>> want that to work for everybody. I haven't moved over the >>>> environment >>>> variable whitelisting yet, although it's basically something like: >>>> >>>> ? [ ! -z "$TERM" ] && exec env -i "PATH=$PATH" "$0" >>> >>> >>> Aha!? Before I was running the script in a tmux tab and getting the >>> results that I have attached.? I just tried running the line above in >>> the tmux tab and the tab disappeared! - so I tried opening a new >>> xterm >>> with no tmux and running the script from there and got a different >>> result: >>> >>> toybox-0.7.3/www/ >>> toybox-0.7.3/www/about.html >>> toybox-0.7.3/www/cleanup.html >>> toybox-0.7.3/www/code.html >>> toybox-0.7.3/www/design.html >>> toybox-0.7.3/www/ext2.html >>> toybox-0.7.3/www/faq.html >>> toybox-0.7.3/www/footer.html >>> toybox-0.7.3/www/header.html >>> toybox-0.7.3/www/index.html >>> toybox-0.7.3/www/license.html >>> toybox-0.7.3/www/news.html >>> toybox-0.7.3/www/oldnews.html >>> toybox-0.7.3/www/roadmap.html >>> toybox-0.7.3/www/status.html >>> toybox-0.7.3/www/toycans.png >>> cc -o kconfig/conf kconfig/conf.c kconfig/zconf.tab.c >>> -DKBUILD_NO_NLS=1 \ >>> ????-DPROJECT_NAME=\"ToyBox\" >>> ccache: error: Could not find compiler "cc" in PATH >>> kconfig/Makefile:65: recipe for target 'kconfig/conf' failed >>> make: *** [kconfig/conf] Error 1 >>> >>> >>>> (Modulo "$TERM" being reliably set in the host environment and NOT >>>> set >>>> by magic /etc/profile stuff that runs even for shell scripts. I >>>> dunno, >>>> maybe $USER would be better? Tested to work with my bash on ubuntu >>>> != >>>> and this won't screw up on some obscure distro like RHELL 9...) >>> >>> >>> Well not exactly RHELL 9 but still Fedora 25 . . I think the last RH >>> I >>> used was 5.2 (ie a still "free" version before RHE). >>> >>> >>>> P.S. I'm not sure if I should get mkroot a new list, or move this >>>> one >>>> over to a new name. At the moment there's not enough to see to take >>>> action on either way. Working on it, but juggling 9 other things at >>>> the >>>> same time... >>> >>> >>> I am in a similar position but I am interested in making more >>> progress >>> with this stuff whenever I can so I will just try things whenever you >>> have time to look at it and can suggest something. >>> >>> Regards, >>> >>> Phil. >>> _______________________________________________ >>> Aboriginal mailing list >>> Aboriginal at lists.landley.net >>> http://lists.landley.net/listinfo.cgi/aboriginal-landley.net >> -- Philip Rhoades PO Box 896 Cowra NSW 2794 Australia E-mail: phil at pricom.com.au From r.majdodin at gmail.com Tue Mar 6 13:50:04 2018 From: r.majdodin at gmail.com (Ruhollah Majdoddin) Date: Tue, 6 Mar 2018 14:50:04 +0100 Subject: [mkroot] Contribution In-Reply-To: References: Message-ID: 2018-03-05 17:36 GMT+01:00 Rob Landley : > On 03/02/2018 04:56 AM, Ruhollah Majdoddin wrote: > > Hello, > > I have spent the past month over mkroot (and native build with QEMU), > > What do you think of it so far? (It's a newish project I haven't gotten > too much > feedback on yet...) > > I started in 2015 with Aboriginal Linux. I was searching for such a thing to avoid Yocto for arm embedded devices. I got a linux and compiled Lighttpd and White-Rabbit PTP natively. My chef was satisfied. Last month, in my new job, I tried it again. Your tutorial presentation was very informative (I wish you could do more like that). There was two issues. 1- The company runs a lot of software on their embedded device. So it seemed that we needed a Linux-Distribution to manage package dependencies. 2- Mkroot still does not provide a native build system. Therefore I tactically decided to use Debain Arm ports with QEMU. I got a running Debian-Linux on QEMU, with that I used Gnu toolchaing to compil the kernel from Boundary-Devices for the I.MX6 chip and run Debian with it (I had to append the defconfig of mkroot when compiling the kernel, to be able to run the image on the QEMU with Arm virt machine). Finally I compiled and installed some modules from the company, I got the system-image and installed it on the embedded device. But the chef and other colleagues were not very excited (they feel comfortable with Yocto/OE) and I got fired. I can say that your presentation and mkroot, served as a guide and test bench, to say the least. > > now I have > > free time for one or two months. Where can I contribute? > > If toybox has more priority now (I see more activity there) please tell > me > > where can I contribute there (I have browsed through the roadmap and > other > > documentation). > > Mkroot needs a lot of work. I haven't got the native toolchain working > under it > yet (partly for design reasons, there's no non-gpl make, and should ninja > or > cmake be in there too?), the old build control image infrastructure at > https://landley.net/aboriginal/control-images needs to be redone in the > new > context, the old Linux From Scratch build image there needs to be recreated > using current LFS... But I'm not sure any of that's a good starting place > for a > new developer? > > Reproducing the existing build with other toolchains might be nice too > (android > NDK, bootlin's toolchains, the crosstool images on kernel.org, > https://ellcc.org > and so on), but none of them provide native compilers, but they might > start and > it would be very nice to have an llvm build baseline. > This is interesting, it seems crosstool images are derived from bootlin. Is Compert-C also an option? http://compcert.inria.fr/compcert-C.html Although it is just a (formally verified) compiler, no assember and no linker. > For toybox I want to use mkroot as a way to run tests requiring root > access and > a known build environment, but again that's not necessarily a good starting > point for new developers. (How you do proper "top" tests is a hard > problem.) > Fixing existing test failures might be, though? (Or at least diagnosing > them, I > haven't had time to even sort which test scripts pass and which fail, and > which > ones are actually providing reasonable test coverage and which aren't yet. > It's > on the todo list...) > This is also interesting. I think you mean the scripts under toybox/tests. Something I've hit that might be worth a look is actually a qemu issue. I > test > new mkroot builds with something like: > > for i in $(./cross.sh); do (sleep 5; echo date; sleep 1; echo ifconfig; > sleep 1; > echo tail /dev/?da; sleep 1; echo exit; sleep 2) | ./run.sh qemu-$i | > smokelog-$i.txt; done > > But when I do that, qemu often _hangs_ with current -git. Something about > qemu's > stdio console handling is wonky when dealing with pipes instead of pty > instances, and I'm not sure what. > The Qemu problem is what I have been working on the last two days, my laptop is not fast, it got 9 hours to build musl. Actually, I could not reproduce the problem, it worked for me (but see below). My system: x86_64 Sony Vaio Laptop $ uname -a Linux ruhollah 4.9.0-4-amd64 #1 SMP Debian 4.9.65-3+deb9u1 (2017-12-23) x86_64 GNU/Linux I cloned QEMU from git, compiled the Master branch with GCC (Does the toolchain matter?) ~/qemu/build/x86_64-softmmu$ ./qemu-system-x86_64 --version QEMU emulator version 2.11.50 (v2.11.0-1911-g136c67e078-dirty) I built mkroot for x86_64 with GCC from debian, and mkroot for armvl with musl, and did similar tests with similar results. ~/mkroot/output/armv7l$ (sleep 7; echo ls; sleep 1; echo date; sleep 1; echo tail '/dev/pts' ; sleep 1; echo ifconfig; sleep 1; echo exit; sleep 1) | ./qemu-armv7l.sh . . . This architecture does not have kernel memory protection. random: fast init done Type exit when done. / # ^[[50;5Rls bin dev etc home init lib mnt proc root sbin sys tmp usr var / # ^[[50;5Rdate Tue Mar 6 11:11:23 UTC 2018 / # ^[[50;5Rtail /dev/pts / # ^[[50;5Rifconfig eth0 Link encap:Ethernet HWaddr 52:54:00:12:34:56 Driver virtio_net inet addr:10.0.2.15 Bcast:10.255.255.255 Mask:255.0.0.0 inet6 addr: fec0::5054:ff:fe12:3456/64 Scope: Site inet6 addr: fe80::5054:ff:fe12:3456/64 Scope: Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:1 errors:0 dropped:0 overruns:0 frame:0 TX packets:6 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:134 TX bytes:512 / # ^[[50;5Rexit reboot: Restarting system ~/mkroot/output/armv7l$ ;5R;5R;5R;5R;5R As you see it does not hang, but there is always a "^[[50;5R" on the QEMU prompt. Afterwards I got some ";5R" on the prompt and I have problems with my bash settings (I? use Konsole): a long line does not wrap and overruns itself. If I redirect the output of QEMU to a file, ~/mkroot/output/armv7l$./qemu-armv7l.sh > log.txt ^C $vi log.txt then I? see other characters at prompt. I?f I do it with mkroot for x86_64 I get ^M (carriage return) on end of lines. It seems to be a problem with stty (and $PS1 ?) settings. Any suggestions? > Thanks for your interest, > > Rob > Many Thanks, Ruhollah -------------- next part -------------- An HTML attachment was scrubbed... URL: From rob at landley.net Tue Mar 6 17:45:10 2018 From: rob at landley.net (Rob Landley) Date: Tue, 6 Mar 2018 11:45:10 -0600 Subject: [mkroot] Contribution In-Reply-To: References: Message-ID: <36d8b631-4811-f3e0-b1e8-511938c39b70@landley.net> On 03/06/2018 07:50 AM, Ruhollah Majdoddin wrote: > > 2018-03-05 17:36 GMT+01:00 Rob Landley >: > > On 03/02/2018 04:56 AM, Ruhollah Majdoddin wrote: > > Hello, > > I have spent the past month over mkroot (and native build with QEMU), > > What do you think of it so far? (It's a newish project I haven't gotten too much > feedback on yet...) > > I started in 2015 with Aboriginal Linux. I was searching for such a thing to > avoid Yocto for arm embedded devices. > I got a linux and compiled Lighttpd and White-Rabbit PTP natively. My chef was > satisfied. > > Last month, in my new job, I tried it again. Your tutorial presentation was very > informative (I wish you could do more like that). > There was two issues. > 1- The company runs a lot of software on their embedded device. So it seemed > that we needed a Linux-Distribution to manage package dependencies. > 2- Mkroot still does not provide a native build system. > > Therefore I tactically decided to use Debain Arm ports with QEMU. > I got a running Debian-Linux on QEMU, with that I used Gnu toolchaing to compil > the kernel from Boundary-Devices for the I.MX6 chip and run Debian with it (I > had to append the defconfig of mkroot when compiling the kernel, to be able to > run the image on the QEMU with Arm virt machine). > Finally I compiled and installed some modules from the company, I got the > system-image and installed it on the embedded device. But the chef and other > colleagues were not very excited (they feel comfortable with Yocto/OE) and I got > fired. > I can say that your presentation and mkroot, served as a guide and test bench, > to say the least. > ? > > > now I have > > free time for one or two months. Where can I contribute? > > If toybox has more priority now (I see more activity there)? please tell me > > where can I contribute there (I have browsed through the roadmap and other > > documentation). > > Mkroot needs a lot of work. I haven't got the native toolchain working under it > yet (partly for design reasons, there's no non-gpl make, and should ninja or > cmake be in there too?), the old build control image infrastructure at > https://landley.net/aboriginal/control-images > needs to be redone in the new > context, the old Linux From Scratch build image there needs to be recreated > using current LFS... But I'm not sure any of that's a good starting place for a > new developer? > > > Reproducing the existing build with other toolchains might be nice too (android > NDK, bootlin's toolchains, the crosstool images on kernel.org > , https://ellcc.org > and so on), but none of them provide native compilers, but they might start and > it would be very nice to have an llvm build baseline. > > This is interesting, it seems crosstool images are derived from bootlin. Crosstool-ng is a longstanding project, although it looks like http://crosstool-ng.org redirects to github now. They're build seemed hugely overcomplicated to me last time I looked at it, but people have gotten it to work. > Is Compert-C also an option? http://compcert.inria.fr/compcert-C.html > Although it is just a (formally verified) compiler, no assember and no linker. Personally I consider formal verification a downside (it means you're dealing with math people who think that helps), but sure? There's a bunch of compilers out there, from the amsterdam compiler kit to https://github.com/drh/lcc and http://open-watcom.github.io/open-watcom/ and https://developer.amd.com/x86-open64-compiler-suite/ and http://pcc.ludd.ltu.se/ and https://github.com/libfirm/cparser and so on. However, there are four compilers I'm aware of that have built a bootable linux kernel, and of those https://bellard.org/tcc/tccboot.html last did so in 2004 and https://software.intel.com/sites/default/files/article/146679/linuxkernelbuildwhitepaper.pdf is a proprietary intel thing. That leaves gcc and http://llvm.linuxfoundation.org. And the interesting part about llvm is that Apple sponsored its development (I think it was some grad student project, but when gcc when gplv3 apple froze xcode on the last gplv2 versions of gcc and binutils for 5 years while they threw money at a replacement, and wrote their own samba from scratch and so on, ala http://meta.ath0.com/2012/02/05/apples-great-gpl-purge/). Along the way Google picked it up and has been building Android with it (including the kernel) for years now. The two compilers were available alongside each other for a while, but android deprected gcc in 2015: https://news.ycombinator.com/item?id=10772826 You'll notice the toolchains I pointed at are all gcc or llvm based. (More or less "toolchain distros" of those two base packages.) It's a bit like "I've gotten linux and freebsd to work" and you going "how about irix?" Um... technically yes? Good luck with it? I think you'll have a hard time. > For toybox I want to use mkroot as a way to run tests requiring root access and > a known build environment, but again that's not necessarily a good starting > point for new developers. (How you do proper "top" tests is a hard problem.) > Fixing existing test failures might be, though? (Or at least diagnosing them, I > haven't had time to even sort which test scripts pass and which fail, and which > ones are actually providing reasonable test coverage and which aren't yet. It's > on the todo list...) > > This is also interesting. I think you mean the scripts under toybox/tests. Yeah, "make tests" and "make test_sed" and so on. It's all calls to scripts/test.sh (which calls scripts/runtest.sh) to call those scripts. The most interesting controlknobx are TEST_HOST=1 and VERBOSE=fail, ala: VERBOSE=fail TEST_HOST=1 make tests Which when I tried it just went: FAIL: blkid file echo -ne '' | blkid temp.img --- expected 2018-03-06 11:27:47.092149228 -0600 +++ actual 2018-03-06 11:27:47.100149229 -0600 @@ -1 +1 @@ -temp.img: TYPE="squashfs" +temp.img: TYPE="squashfs" make: *** [tests] Error 1 Because the host version of blkid outputs a trailing space and mine doesn't. (Technically that's a bug in the host blkid, but sometimes I need to filter the output so they match. That said, trailing whitespace doesn't come up much because it generally IS a bug and if _mine_ was doing it I'd wanna know...) The toybox test suite is an ENORMOUS time sink, and part of it's figuring out if you're testing the right stuff (what tests are missing, is this test meaningful...) And I have lots of stuff that needs root access to test, and more that needs a known environment (ifconfig against which interface names, is the dummy driver loaded, etc?) which is why I'm setting up a VM for it. > Something I've hit that might be worth a look is actually a qemu issue. I test > new mkroot builds with something like: > > for i in $(./cross.sh); do (sleep 5; echo date; sleep 1; echo ifconfig; sleep 1; > echo tail /dev/?da; sleep 1; echo exit; sleep 2) | ./run.sh qemu-$i | > smokelog-$i.txt; done > > But when I do that, qemu often _hangs_ with current -git. Something about qemu's > stdio console handling is wonky when dealing with pipes instead of pty > instances, and I'm not sure what. > > > The Qemu problem is what I have been working on the last two days, my laptop is > not fast, it got 9 hours to build musl. Actually, I could not reproduce the > problem, it worked for me (but see below). > > My system: x86_64 Sony Vaio Laptop > $ uname -a > Linux ruhollah 4.9.0-4-amd64 #1 SMP Debian 4.9.65-3+deb9u1 (2017-12-23) x86_64 > GNU/Linux > > I cloned QEMU from git, compiled the Master branch with GCC (Does the toolchain > matter?) > > ~/qemu/build/x86_64-softmmu$ ./qemu-system-x86_64 --version > QEMU emulator version 2.11.50 (v2.11.0-1911-g136c67e078-dirty) > > I built mkroot for x86_64 with GCC from debian, ? and mkroot for armvl with > musl, and did similar tests with similar results. > > ~/mkroot/output/armv7l$ (sleep 7; echo ls; sleep 1; echo date; sleep 1; echo > tail '/dev/pts' ; sleep 1; echo ifconfig; sleep 1; echo exit; sleep 1) |? > ./qemu-armv7l.sh > . > . > . > This architecture does not have kernel memory protection. > random: fast init done > Type exit when done. > / # ^[[50;5Rls > bin dev etc home init lib mnt proc root sbin sys tmp usr var > / # ^[[50;5Rdate > Tue Mar? 6 11:11:23 UTC 2018 > / # ^[[50;5Rtail /dev/pts > / # ^[[50;5Rifconfig > eth0????? Link encap:Ethernet? HWaddr 52:54:00:12:34:56? Driver virtio_net > ????????? inet addr:10.0.2.15? Bcast:10.255.255.255? Mask:255.0.0.0 > ????????? inet6 addr: fec0::5054:ff:fe12:3456/64 Scope: Site > ????????? inet6 addr: fe80::5054:ff:fe12:3456/64 Scope: Link > ????????? UP BROADCAST RUNNING MULTICAST? MTU:1500? Metric:1 > ????????? RX packets:1 errors:0 dropped:0 overruns:0 frame:0 > ????????? TX packets:6 errors:0 dropped:0 overruns:0 carrier:0 > ????????? collisions:0 txqueuelen:1000 > ????????? RX bytes:134 TX bytes:512 > > / # ^[[50;5Rexit > reboot: Restarting system > ~/mkroot/output/armv7l$ ;5R;5R;5R;5R;5R > > As you see it does not hang, but there is always a "^[[50;5R" on the QEMU > prompt. That's busybox attempting to probe the terminal size using ANSI sequences, and technically it's my fault. :) http://lists.busybox.net/pipermail/busybox/2009-May/069314.html It can't tell _not_ to do that because inside the vm /dev/console looks like a tty. (It should figure out it doesn't get a response and remember it, but nobody implemented that. It's on my todo list for toysh but I need to clear space to work on that which means shoveling out the backlog of so much _else_ first...) > Afterwards I got some ";5R" on the prompt and I have problems with my > bash settings (I? use Konsole): a long line does not? wrap and overruns itself. If the ansi probe makes it to your terminal, your terminal will respond basically pasting an ansi escape sequence in as if you'd typed it. But since qemu's input isn't coming from the keyboard it gets buffered until something listens to the keyboard again... (The probe is "query cursor position". You can query terminal size by saving the cursor position, moving to the bottom right corner, querying position, and returning to saved position.) See https://github.com/landley/toybox/blob/master/lib/interestingtimes.c#L49 for sending the probe and https://github.com/landley/toybox/blob/master/lib/interestingtimes.c#L164 (Of course you can't tell the difference between the return string from querying the screen size and querying the cursor position, so you have to remember what probe you sent...) > If I redirect the output of QEMU to a file, > > ~/mkroot/output/armv7l$./qemu-armv7l.sh > log.txt > ^C > $vi log.txt > > then I? see other characters at prompt. I?f I do it with mkroot for x86_64 I get > ^M (carriage return) on end of lines. > It seems to be a problem with stty (and $PS1 ?) settings. Any suggestions? Nah, that's not the problem I'm seeing. But I'm only seeing it on one machine and not the other, something's different about build environment. I'll try to track it down here... You could try getting the microblaze target to work? Something's wrong with the ELF parser, the kernel refuses to launch init. Not quite sure why, I was planning on drilling down through the kernel's load_elf_binary() (https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/fs/binfmt_elf.c#n685) to see if I can figure it out... That might be throwing you in the deep end a bit. :) Rob From rob at landley.net Tue Mar 6 21:32:41 2018 From: rob at landley.net (Rob Landley) Date: Tue, 6 Mar 2018 15:32:41 -0600 Subject: [mkroot] x32 mcm-buildall.sh final patch In-Reply-To: <1520109538.32478.3.camel@vocatus.pub> References: <1519761729.26577.19.camel@vocatus.pub> <3e529b48-f5e2-f94a-784e-71d8ec8ad2af@landley.net> <1520109538.32478.3.camel@vocatus.pub> Message-ID: <2f25c479-7ba9-d004-7e99-bf3419f23b55@landley.net> On 03/03/2018 02:38 PM, Alain Toussaint wrote: > >> The larger question here is "toolchain the kernel builds with and toolchain >> userspace builds with are different". In general infrastructure to build kernel with one toolchain and userspace with another is probably good to have... > Yeah, on that count, I need to do a patch for the x86_64 kernel build to include the x32 > compatiblities settings. That being said, when I was hacking the prototype, the kernel got built by > the x32 toolchain but I don't know (yet) if a kernel built by the x32 toolchain would see past 4GB. > It did build fine and worked under qemu. Libtomcrypt in dropbear couldn't cope. Possibly I should be using a version newer than 2016? :) Hmmm... I wonder if it's the same kernel or a different kernel? (If it's defaulting to 32 bit and sticking the long prefix in front of everything it'd work the same but the code would be enormous. That's _probably_ not what's happening but I'd wanna diff the binaries to be sure...) The x32 bzImage is 2420688 bytes, the x86_64 bzImage is 2428880 bytes. About an 8k difference in a 2.4 megabyte file. I'd dig deeper but I need the vmlinux (not the bzImage) to do that properly. In the meantime, maybe I need an option for keeping the vmlinux files around for study after the build? (Back in aboriginal linux I had NO_CLEANUP=1, and I can add that back here, but (It's a pity that qemu can't universally boot a vmlinux on all targets. The plumbing's sort of there but qemu -kernel has definite format expectations that vary from target to target. Sigh...) > For bare metal, I already had a 64bit kernel with the suitable options on a multiboot usb key. > >> And the OTHER problem is that x86_64-*-native >> now resolves to two toolchains. > > That is the bit I was refering to which is why I set the x86_64 arch to x32 on the first patch so > that running ./cross.sh x86_64 ./mkroot dynamic kernel built an x32 kernel and userspace. Yeah, needs some new design work. (The user interface is harder to get right than the plumbing.) Hmmm... what I'd like to do is rename the toolchain at build time so it's x32-linux-musl-cross, assuming that doesn't confuse autoconf? (It shouldn't.) Literally all the cross.sh script does is set CROSS_COMPILE to the prefix (with path) of a cross compiler, and then CROSS_SHORT is re-derived from that in mkroot.sh... That's still building the kernel and userspace with the same toolchain, but if it works in this case I can defer adding better infrastructure until I hit a case that doesn't. (I should still fix this for mmu and nommu versions of the same architecture, ala microblaze.) > Alain Rob From rob at landley.net Thu Mar 8 17:52:33 2018 From: rob at landley.net (Rob Landley) Date: Thu, 8 Mar 2018 11:52:33 -0600 Subject: [mkroot] To the people who keeping pinging me off list... Message-ID: <3b76943b-a3cf-38c6-5e95-bb433c49739a@landley.net> If you let me know what your requirements are, I can probably get it doing what you need. I've been going for breadth first (supporting as many targets as possible, which is mostly fiddling with kernel and qemu and libc stuff) than getting the "and now we build linux from scratch and beyond linux from scratch natively under the result" infrastructure back in place, but it's not hard to go the other way. Just haven't had users standing by waiting for it, and finite time that's mostly been going to toybox. (Right now the limiting factor on target support is what musl-libc's implemented support for. I've _almost_ got all those targets working, which includes things like s390x that didn't work under aboriginal linux. That's time consuming because my definition of success there isn't just "boots to a shell prompt" but also shuts down cleanly, has a working network, working block device, and the clock's set properly (make gets really unhappy if the system clock's older than the source you're trying to build).) And of course the kernel guys keep breaking stuff: https://twitter.com/landley/status/964618029119295488 I should just cut a release where my tree is now (with the 4.14 kernel) before trying to tackle that pile. (And the initramfs devtmpfs automount stuff. And the initramfs xattr stuff. And...) Rob From alain at vocatus.pub Thu Mar 8 20:03:18 2018 From: alain at vocatus.pub (Alain Toussaint) Date: Thu, 08 Mar 2018 15:03:18 -0500 Subject: [mkroot] To the people who keeping pinging me off list... In-Reply-To: <3b76943b-a3cf-38c6-5e95-bb433c49739a@landley.net> References: <3b76943b-a3cf-38c6-5e95-bb433c49739a@landley.net> Message-ID: <1520539398.1370.1.camel@vocatus.pub> > getting the "and now we build linux from scratch and beyond linux from scratch > natively under the result" infrastructure back in place I'd be the one in favor of that. I have been accepted as editor of BLFS and even though I'm knee deep into build replicability territory (build LFS --> boot LFS --> build second LFS under first LFS --> see if it barf) so that I haven't been able to contribute to the 8.2 release, we do have request for 686 build and I do know that mkroot even support 486 and build a kernel for it (I myself would be curious to find a 486 able to boot LFS 8,2). Al From onefang at gmail.com Thu Mar 8 20:52:28 2018 From: onefang at gmail.com (David Seikel) Date: Fri, 9 Mar 2018 06:52:28 +1000 Subject: [mkroot] To the people who keeping pinging me off list... In-Reply-To: <1520539398.1370.1.camel@vocatus.pub> References: <3b76943b-a3cf-38c6-5e95-bb433c49739a@landley.net> <1520539398.1370.1.camel@vocatus.pub> Message-ID: <20180309065228.2fac58ef.onefang@gmail.com> On Thu, 08 Mar 2018 15:03:18 -0500 Alain Toussaint wrote: > > > getting the "and now we build linux from scratch and beyond linux > > from scratch natively under the result" infrastructure back in place > > I'd be the one in favor of that. I have been accepted as editor of > BLFS and even though I'm knee deep into build replicability territory > (build LFS --> boot LFS --> build second LFS under first LFS --> see > if it barf) so that I haven't been able to contribute to the 8.2 > release, we do have request for 686 build and I do know that mkroot > even support 486 and build a kernel for it (I myself would be curious > to find a 486 able to boot LFS 8,2). I might be able to help with that. If I recall correctly, I was responsible for adding the original Aboriginal Linux support, and I still have the 486 device I needed that for. Building LFS and BLFS is on my TODO, and is near the top of that TODO. -- A big old stinking pile of genius that no one wants coz there are too many silver coated monkeys in the world. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 181 bytes Desc: OpenPGP digital signature URL: From rob at landley.net Thu Mar 8 21:51:01 2018 From: rob at landley.net (Rob Landley) Date: Thu, 8 Mar 2018 15:51:01 -0600 Subject: [mkroot] To the people who keeping pinging me off list... In-Reply-To: <1520539398.1370.1.camel@vocatus.pub> References: <3b76943b-a3cf-38c6-5e95-bb433c49739a@landley.net> <1520539398.1370.1.camel@vocatus.pub> Message-ID: On 03/08/2018 02:03 PM, Alain Toussaint wrote: > >> getting the "and now we build linux from scratch and beyond linux from scratch >> natively under the result" infrastructure back in place > > I'd be the one in favor of that. Not the only one. :) > I have been accepted as editor of BLFS and even though I'm knee > deep into build replicability territory (build LFS --> boot LFS --> build second LFS under first LFS > --> see if it barf) Back in 2010 I had a 6 month contract to help port Linux to the hexagon with qualcomm, and I wrote plumbing that built rather a lot of BLFS after the aboriginal linux LFS build finished. (Basically it was another build control image, but the base it ran in was the LFS build control image output.) For a demo I got x11 running (well, the client layer, there was no graphics hardware in the comet boards so we connected through the network to an x11 display on another machine) and got xeyes and xchess and so on running. I remember the xterm I built wasn't the stock one but a simpler one with fewer dependencies (might have been rxvt? These days I'd probably try https://git.musl-libc.org/cgit/uuterm/ ) And yes, you can genericize a build invocation for the 37 metastatic components of modern x11 and just run through them with a for loop. I know because I did it. Alas since I did it behind closed doors in a corporation, I didn't write about it in my blog and didn't check it in to the open source project. I kept meaning to redo it but never got around to it... > so that I haven't been able to contribute to the 8.2 release, we do have request > for 686 build and I do know that mkroot even support 486 and build a kernel for it (I myself would > be curious to find a 486 able to boot LFS 8,2). Sigh, I thought there was an open 486 but https://en.wikipedia.org/wiki/Zet_(hardware) is 16 bits only. Alas ancient technology can be a minefield long after the IP claims _should_ have expired if a current company pumps money into a legal department continuing to spray uncertainty over it. (See also https://www.ncbi.nlm.nih.gov/pmc/articles/PMC3614593/ and https://atp.orangenius.com/how-mickey-mouse-keeps-changing-copyright-law/ for how IP law is generally evil and needs to go away.) This is also why https://en.wikipedia.org/wiki/Amber_(processor_core) goes up to armv2a but _NOT_ armv3 (which is the oldest one compatible with the modern arm instructions, and basically what you need to run Linux). Notice how the Amber verilog was written in 2001 and that's long enough ago that patents issued THEN should have expired, and yet development's basically abandoned because if they take one more step they'll get sued, regardless of patent expiration or prior art... > Al Rob From alain at vocatus.pub Thu Mar 8 22:04:06 2018 From: alain at vocatus.pub (Alain Toussaint) Date: Thu, 08 Mar 2018 17:04:06 -0500 Subject: [mkroot] To the people who keeping pinging me off list... In-Reply-To: References: <3b76943b-a3cf-38c6-5e95-bb433c49739a@landley.net> <1520539398.1370.1.camel@vocatus.pub> Message-ID: <1520546646.1370.11.camel@vocatus.pub> > Sigh, I thought there was an open 486 but > https://en.wikipedia.org/wiki/Zet_(hardware) is 16 bits only. Forget about x86 for new designs. I'd be more interested into putting to good uses what are deemed useless boxes. New designs of anything, I'd base it on risc-v or any of its spinoff (lowrisc for example) upon which, I'd plug in coprocessors to do the necessary calculations to do drug development and build a cluster of compute boxes in a rack using said design to work on drug development. I do have the Harris & Harris book but I'm still a long way to go from designing such coprocessor. Alain From rob at landley.net Thu Mar 8 22:48:28 2018 From: rob at landley.net (Rob Landley) Date: Thu, 8 Mar 2018 16:48:28 -0600 Subject: [mkroot] To the people who keeping pinging me off list... In-Reply-To: <1520546646.1370.11.camel@vocatus.pub> References: <3b76943b-a3cf-38c6-5e95-bb433c49739a@landley.net> <1520539398.1370.1.camel@vocatus.pub> <1520546646.1370.11.camel@vocatus.pub> Message-ID: On 03/08/2018 04:04 PM, Alain Toussaint wrote: > >> Sigh, I thought there was an open 486 but >> https://en.wikipedia.org/wiki/Zet_(hardware) is 16 bits only. > > Forget about x86 for new designs. I'd be more interested into putting to good uses what are deemed > useless boxes. For regression testing on real hardware, being able to load a 486 into an FPGA would be useful. (In the meantime there's qemu, but qemu often runs stuff real hardware won't.) > New designs of anything, I'd base it on risc-v or any of its spinoff (lowrisc for example) upon > which, I'd plug in coprocessors to do the necessary calculations to do drug development and build a > cluster of compute boxes in a rack using said design to work on drug development. I do have the > Harris & Harris book but I'm still a long way to go from designing such coprocessor. I've worked on https://j-core.org since 2014 so I may be biased, but I have zero interest in risc-v. It's the itanium of the open hardware world. Where they're light years ahead of everybody else is _marketing_, not technology. Every time somebody points out a new corner case they lose at (even against x86 or arm) they invent another instruction set extension or mode that's incompatible with the previous ones just to win THAT benchmark, which don't combine in any useful way but they win each and every benchmark one by one, in isolation, essentially with different compiler options. And then they go "look how simple we are, you can build this chip to exclude the extensions you're not using! Compatibility? What's that?" *shrug* I expect a large wave of dot-com style investment in them, and to see it crash and burn in 5-7 years, and then maybe something useful will emerge from the wreckage? (I doubt it, but it's possible.) It's sort of an https://www.joelonsoftware.com/2000/05/12/strategy-letter-i-ben-and-jerrys-vs-amazon/ thing where they are so desperate to emerge as the new STANDARD and drive everyone else from the field, except open source and webassembly (heck, it was the point of java's "write once run anywhere") erode the importance of a specific instruction set, and the dominant one by unit volume is going to be arm for at least the next decade anyway (not just installed base but new deployments) because things like raspberry pi are leveraging the unit volume of phones (the way a "blade server" was a laptop chipset stuck in a server rack) and semiconductor manufacturing cost is almost entirely a question of unit volume and ASIC fabs continue to be large proprietary multi-billion dollar assets where the mask layout software is essentially a giant proprietary hand-rolled VHDL/verilog compiler that's different for every single fab (the old "every hardware platform has its own C compiler and libc provided by the vendor" days) they won't even let you see the SPECS for until you sign an NDA, and they have a dialect of java that generates verilog as an output... Sigh. Can of worms. Linux has 30 architectures, this one has a microsoft-style marketing campaign behind it but so did itanium, what got microsoft its monopoly was the predatory distribution contracts it negotiated tying up the supply chain, and pushing back against that linux development didn't have to spend 6 figures to compile a kernel but even as a free download we had 20 consecutive "year of the linux desktop"s with <2% market share on that because it couldn't get preinstalls... Ahem. Can. Of. Worms. > Alain Rob P.S. Did the US Navy ever work its way through their stockpile of HST modems? http://tycho.usno.navy.mil/ads.html says it's still using them... From rob at landley.net Thu Mar 8 22:53:04 2018 From: rob at landley.net (Rob Landley) Date: Thu, 8 Mar 2018 16:53:04 -0600 Subject: [mkroot] How silly would it be if I renamed the project "hermetic"? Message-ID: <7c1d8ec1-6d4c-c08f-701a-19b78c0abc6d@landley.net> Because hermetic builds are what I'm trying to accomplish, and the concept is sadly hard to google for. (I got that phrase from the android guys, but they apparently only discuss it on their internal boards.) Of course it would be kinda unfair to make everybody change their email filters _again_... :P Rob From onefang at gmail.com Thu Mar 8 23:09:31 2018 From: onefang at gmail.com (David Seikel) Date: Fri, 9 Mar 2018 09:09:31 +1000 Subject: [mkroot] How silly would it be if I renamed the project "hermetic"? In-Reply-To: <7c1d8ec1-6d4c-c08f-701a-19b78c0abc6d@landley.net> References: <7c1d8ec1-6d4c-c08f-701a-19b78c0abc6d@landley.net> Message-ID: <20180309090931.2275d6e4.onefang@gmail.com> On Thu, 8 Mar 2018 16:53:04 -0600 Rob Landley wrote: > Because hermetic builds are what I'm trying to accomplish, and the > concept is sadly hard to google for. (I got that phrase from the > android guys, but they apparently only discuss it on their internal > boards.) > > Of course it would be kinda unfair to make everybody change their > email filters _again_... :P I only just changed my email system for mkroot a few hours ago. :-P And still not sure if my 486 reply got through. -- A big old stinking pile of genius that no one wants coz there are too many silver coated monkeys in the world. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 181 bytes Desc: OpenPGP digital signature URL: From alain at vocatus.pub Thu Mar 8 23:29:38 2018 From: alain at vocatus.pub (Alain Toussaint) Date: Thu, 08 Mar 2018 18:29:38 -0500 Subject: [mkroot] How silly would it be if I renamed the project "hermetic"? In-Reply-To: <20180309090931.2275d6e4.onefang@gmail.com> References: <7c1d8ec1-6d4c-c08f-701a-19b78c0abc6d@landley.net> <20180309090931.2275d6e4.onefang@gmail.com> Message-ID: <1520551778.1370.12.camel@vocatus.pub> > And still not sure if my 486 reply got through. It did :) Al From rob at landley.net Thu Mar 8 23:35:41 2018 From: rob at landley.net (Rob Landley) Date: Thu, 8 Mar 2018 17:35:41 -0600 Subject: [mkroot] How silly would it be if I renamed the project "hermetic"? In-Reply-To: <20180309090931.2275d6e4.onefang@gmail.com> References: <7c1d8ec1-6d4c-c08f-701a-19b78c0abc6d@landley.net> <20180309090931.2275d6e4.onefang@gmail.com> Message-ID: <52b65854-13e6-7dba-2959-0f38555dca43@landley.net> On 03/08/2018 05:09 PM, David Seikel wrote: > On Thu, 8 Mar 2018 16:53:04 -0600 Rob Landley wrote: > >> Because hermetic builds are what I'm trying to accomplish, and the >> concept is sadly hard to google for. (I got that phrase from the >> android guys, but they apparently only discuss it on their internal >> boards.) >> >> Of course it would be kinda unfair to make everybody change their >> email filters _again_... :P > > I only just changed my email system for mkroot a few hours ago. :-P > > And still not sure if my 486 reply got through. It did, I just hadn't replied to it yet. I have a failure mode of "Ooh, I did a proof of concept of that once, I know how to do it, I have plans to do that properly in my todo list with a text file somewhere with 20 lines of design notes..." and then not doing it for 4 years. But if somebody else wants to do it I have to bite back the urge to bikeshed about it at huge length. (If I didn't have a day job and could just do open source programming full-time, I _might_ be able to ekep up with the rate at which my todo list spins off tangents. I doubt it, but it would at least be conceivable. As it is, my todo list composts and forms archaeological layers.) But yeah, as I replied to the other post: I did a blfs builder once. x11 crushes down to a shell for loop quite nicely. (The trick is you can feed them all a common command line option set, and the ones that don't need it will ignore it. Or would in 2010, I haven't been defending against bit-rot on that so for all I know it's developed a perl dependency...) Rob * Perl has no standard, there's a single magic implementation and whatever that does is the definition of "perl". People objected when it was Microsoft World or Excel whose bugs and corner cases defined a file format, but perl gets a pass. Oh well. ** https://news.ycombinator.com/item?id=14858143 *** Not my _only_ obvious failure mode, no: https://www.quora.com/Who-wrote-the-quote-If-I-had-more-time-I-would-have-written-you-a-shorter-letter From paul.sherwood at codethink.co.uk Thu Mar 8 23:36:03 2018 From: paul.sherwood at codethink.co.uk (Paul Sherwood) Date: Thu, 08 Mar 2018 23:36:03 +0000 Subject: [mkroot] How silly would it be if I renamed the project "hermetic"? In-Reply-To: <7c1d8ec1-6d4c-c08f-701a-19b78c0abc6d@landley.net> References: <7c1d8ec1-6d4c-c08f-701a-19b78c0abc6d@landley.net> Message-ID: Not silly at all. In other contexts I've been pushing towards self-hosted, reproducible, deterministic builds. But now you've proposed this word, I think it's better :-) br Paul On 2018-03-08 22:53, Rob Landley wrote: > Because hermetic builds are what I'm trying to accomplish, and the > concept is > sadly hard to google for. (I got that phrase from the android guys, but > they > apparently only discuss it on their internal boards.) > > Of course it would be kinda unfair to make everybody change their email > filters > _again_... :P > > Rob > _______________________________________________ > mkroot mailing list > mkroot at lists.landley.net > http://lists.landley.net/listinfo.cgi/mkroot-landley.net From alain at vocatus.pub Thu Mar 8 23:44:27 2018 From: alain at vocatus.pub (Alain Toussaint) Date: Thu, 08 Mar 2018 18:44:27 -0500 Subject: [mkroot] To the people who keeping pinging me off list... In-Reply-To: References: <3b76943b-a3cf-38c6-5e95-bb433c49739a@landley.net> <1520539398.1370.1.camel@vocatus.pub> <1520546646.1370.11.camel@vocatus.pub> Message-ID: <1520552667.1370.14.camel@vocatus.pub> > I've worked on https://j-core.org since 2014 so I may be biased, but I have zero > interest in risc-v. It's the itanium of the open hardware world. Where they're > light years ahead of everybody else is _marketing_, not technology. The road to hell is paved with good intentions and indeed, itanic and risc-v are good intentions in that regard. That said, I'd be okay with jcore along with parallella for some kind of prototype chemoinformatics system. Whatever get the ball rolling. Alain p.s. jcore.org doesn't load here. ping get through but traceroute show stars at around the 17th hop. Alain From onefang at gmail.com Thu Mar 8 23:47:17 2018 From: onefang at gmail.com (David Seikel) Date: Fri, 9 Mar 2018 09:47:17 +1000 Subject: [mkroot] How silly would it be if I renamed the project "hermetic"? In-Reply-To: <1520551778.1370.12.camel@vocatus.pub> References: <7c1d8ec1-6d4c-c08f-701a-19b78c0abc6d@landley.net> <20180309090931.2275d6e4.onefang@gmail.com> <1520551778.1370.12.camel@vocatus.pub> Message-ID: <20180309094717.6af2a4cf.onefang@gmail.com> On Thu, 08 Mar 2018 18:29:38 -0500 Alain Toussaint wrote: > > > And still not sure if my 486 reply got through. > > It did :) I guess my usual trick of subscribing two separate gmail addresses, one read only, the other write only, is now failing to push my own emails through the broken for ever gmail filter system. Meh, it's probably time to migrate a few more mailing lists away from gmail. -- A big old stinking pile of genius that no one wants coz there are too many silver coated monkeys in the world. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 181 bytes Desc: OpenPGP digital signature URL: From rob at landley.net Thu Mar 8 23:56:33 2018 From: rob at landley.net (Rob Landley) Date: Thu, 8 Mar 2018 17:56:33 -0600 Subject: [mkroot] To the people who keeping pinging me off list... In-Reply-To: <1520552667.1370.14.camel@vocatus.pub> References: <3b76943b-a3cf-38c6-5e95-bb433c49739a@landley.net> <1520539398.1370.1.camel@vocatus.pub> <1520546646.1370.11.camel@vocatus.pub> <1520552667.1370.14.camel@vocatus.pub> Message-ID: <6c5a9daf-42f8-7b05-91c7-87c9313fc416@landley.net> On 03/08/2018 05:44 PM, Alain Toussaint wrote: > >> I've worked on https://j-core.org since 2014 so I may be biased, but I have zero >> interest in risc-v. It's the itanium of the open hardware world. Where they're >> light years ahead of everybody else is _marketing_, not technology. > > The road to hell is paved with good intentions and indeed, itanic and risc-v are good intentions in > that regard. > > That said, I'd be okay with jcore along with parallella for some kind of prototype chemoinformatics > system. Whatever get the ball rolling. > > Alain > > p.s. jcore.org doesn't load here. ping get through but traceroute show stars at around the 17th hop. Sigh, they moved the infrastructure out of the canada office a couple days ago, it's supposed to be hosted on some google cloud service by now but it looks like something hasn't updated. I'll ping 'em, thanks for the heads up, Rob From onefang at gmail.com Fri Mar 9 00:00:16 2018 From: onefang at gmail.com (David Seikel) Date: Fri, 9 Mar 2018 10:00:16 +1000 Subject: [mkroot] To the people who keeping pinging me off list... In-Reply-To: <1520552667.1370.14.camel@vocatus.pub> References: <3b76943b-a3cf-38c6-5e95-bb433c49739a@landley.net> <1520539398.1370.1.camel@vocatus.pub> <1520546646.1370.11.camel@vocatus.pub> <1520552667.1370.14.camel@vocatus.pub> Message-ID: <20180309100016.51c2bb28.onefang@gmail.com> For the record on the 486 question, https://www.icop.com.tw/ make 486 based tiny PCs for embedded work. I have one sitting on my desk. They are quite capable of running the various tiny Linux distros, and I sometimes do development work on it using Aboriginal Linux as the base. Likely it will run LFS and BLFS fine, I suspect I'll find out next week. -- A big old stinking pile of genius that no one wants coz there are too many silver coated monkeys in the world. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 181 bytes Desc: OpenPGP digital signature URL: From rob at landley.net Fri Mar 9 00:08:23 2018 From: rob at landley.net (Rob Landley) Date: Thu, 8 Mar 2018 18:08:23 -0600 Subject: [mkroot] How silly would it be if I renamed the project "hermetic"? In-Reply-To: <20180309094717.6af2a4cf.onefang@gmail.com> References: <7c1d8ec1-6d4c-c08f-701a-19b78c0abc6d@landley.net> <20180309090931.2275d6e4.onefang@gmail.com> <1520551778.1370.12.camel@vocatus.pub> <20180309094717.6af2a4cf.onefang@gmail.com> Message-ID: <86495398-575c-6ff8-72e5-98087acf7875@landley.net> On 03/08/2018 05:47 PM, David Seikel wrote: > On Thu, 08 Mar 2018 18:29:38 -0500 Alain Toussaint > wrote: > >> >>> And still not sure if my 486 reply got through. >> >> It did :) > > I guess my usual trick of subscribing two separate gmail addresses, one > read only, the other write only, is now failing to push my own emails > through the broken for ever gmail filter system. Meh, it's probably > time to migrate a few more mailing lists away from gmail. Ah, gmail. I still need to deal with https://twitter.com/landley/status/970785241051910144 Rob From alain at vocatus.pub Fri Mar 9 00:28:01 2018 From: alain at vocatus.pub (Alain Toussaint) Date: Thu, 08 Mar 2018 19:28:01 -0500 Subject: [mkroot] gmail, was Re: How silly would it be if I renamed the project "hermetic"? In-Reply-To: <86495398-575c-6ff8-72e5-98087acf7875@landley.net> References: <7c1d8ec1-6d4c-c08f-701a-19b78c0abc6d@landley.net> <20180309090931.2275d6e4.onefang@gmail.com> <1520551778.1370.12.camel@vocatus.pub> <20180309094717.6af2a4cf.onefang@gmail.com> <86495398-575c-6ff8-72e5-98087acf7875@landley.net> Message-ID: <1520555281.1370.16.camel@vocatus.pub> > Ah, gmail. I still need to deal with > https://twitter.com/landley/status/970785241051910144 Speaking about gmail, I have no issues sending mail to all the differents free email providers, maybe except that my host is listed in the spamhaus database so some hosts are offlimit (higgs.linuxfromscratch.org among others). I must say that linode is very popular wrt spam sendings and address collections which is unfortunate. That said, I did include all the major spam control measures such as spf and dkim (not shown below but my dkim record do validate fine) and CAA ressources records except dmarc (this one's not ready for prime time): ;; QUESTION SECTION: ;vocatus.pub. IN ANY ;; ANSWER SECTION: vocatus.pub. 3600 IN CAA 0 iodef "alain at vocatus.pub" vocatus.pub. 3600 IN CAA 0 issuewild "letsencrypt.org" vocatus.pub. 3600 IN CAA 0 issue "\;" vocatus.pub. 3600 IN AAAA 2600:3c02::f03c:91ff:fed1:c12d vocatus.pub. 3600 IN TXT "v=spf1 mx a ip4:50.116.46.176/32 ip6:2600:3c02::f03c:91ff:fed1:c12d/128 -all" vocatus.pub. 3600 IN MX 1 vocatus.pub. vocatus.pub. 10000 IN SOA dns.rebel.com. noc.rebel.com. 3 10800 3600 604800 3600 vocatus.pub. 3600 IN A 50.116.46.176 vocatus.pub. 3600 IN NS dns2.rebel.com. vocatus.pub. 3600 IN NS dns.rebel.com. ;; AUTHORITY SECTION: vocatus.pub. 3600 IN NS dns.rebel.com. vocatus.pub. 3600 IN NS dns2.rebel.com. ;; ADDITIONAL SECTION: vocatus.pub. 3600 IN A 50.116.46.176 dns.rebel.com. 239 IN A 54.236.227.139 dns.rebel.com. 239 IN A 54.236.79.66 dns2.rebel.com. 9340 IN A 54.200.36.152 dns2.rebel.com. 9340 IN A 54.200.67.125 Rob, maybe it would help to have that set up and I can help in that regard. Alain From r.majdodin at gmail.com Fri Mar 9 17:16:48 2018 From: r.majdodin at gmail.com (Ruhollah Majdoddin) Date: Fri, 9 Mar 2018 18:16:48 +0100 Subject: [mkroot] Contribution In-Reply-To: <36d8b631-4811-f3e0-b1e8-511938c39b70@landley.net> References: <36d8b631-4811-f3e0-b1e8-511938c39b70@landley.net> Message-ID: 2018-03-06 18:45 GMT+01:00 Rob Landley : > You could try getting the microblaze target to work? Something's wrong > with the > ELF parser, the kernel refuses to launch init. Not quite sure why, I was > planning on drilling down through the kernel's load_elf_binary() > (https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/ > linux.git/tree/fs/binfmt_elf.c#n685) > to see if I can figure it out... > > That might be throwing you in the deep end a bit. :) > I am working on that. > Rob > Ruhollah -------------- next part -------------- An HTML attachment was scrubbed... URL: From phil at pricom.com.au Sun Mar 11 06:54:58 2018 From: phil at pricom.com.au (Philip Rhoades) Date: Sun, 11 Mar 2018 17:54:58 +1100 Subject: [mkroot] sbase In-Reply-To: <81a727f6-ebc3-4ef5-6a29-66036b9fd3db@landley.net> References: <81a727f6-ebc3-4ef5-6a29-66036b9fd3db@landley.net> Message-ID: <2bb438c2f0b6cb4c898d29e8d103e2f3@pricom.com.au> Rob, On 2018-03-11 12:18, Rob Landley wrote: > Did you mean to send this to mkroot-bounces? :) No, sorry, just clicked on a "From:" from the previous email without looking too closely . . > Yes I've encountered sbase. > > http://landley.net/toybox/roadmap.html#sbase Will have a look. > It wasn't interesting to me. Right - I might respond more after reading the link, Thanks, Phil. >> Subject: sbase >> From: Philip Rhoades >> Date: 03/10/2018 08:33 AM >> To: mkroot >> >> Rob, >> >> I came across this on another list: >> >> https://core.suckless.org/sbase >> >> - comments? >> >> P. -- Philip Rhoades PO Box 896 Cowra NSW 2794 Australia E-mail: phil at pricom.com.au From rob at landley.net Mon Mar 12 18:11:52 2018 From: rob at landley.net (Rob Landley) Date: Mon, 12 Mar 2018 13:11:52 -0500 Subject: [mkroot] To the people who keeping pinging me off list... Message-ID: FYI, I disabled all the subscriptions to the old aboriginal linux mailing list when I moved 'em over (and made new subscriptions require approval), so if you send a message there it goes into moderation. > Subject: Re: [mkroot] To the people who keeping pinging me off list... > From: David Seikel > Date: 03/08/2018 02:16 PM > To: aboriginal at lists.landley.net > > On Thu, 08 Mar 2018 15:03:18 -0500 Alain Toussaint > wrote: > >> >>> getting the "and now we build linux from scratch and beyond linux >>> from scratch natively under the result" infrastructure back in place >> >> I'd be the one in favor of that. I have been accepted as editor of >> BLFS and even though I'm knee deep into build replicability territory >> (build LFS --> boot LFS --> build second LFS under first LFS --> see >> if it barf) so that I haven't been able to contribute to the 8.2 >> release, we do have request for 686 build and I do know that mkroot >> even support 486 and build a kernel for it (I myself would be curious >> to find a 486 able to boot LFS 8,2). > > I might be able to help with that. If I recall correctly, I was > responsible for adding the original Aboriginal Linux support, and I > still have the 486 device I needed that for. Building LFS and BLFS is > on my TODO, and is near the top of that TODO. I'm pretty sure 486 support works properly in mkroot? But you're right, I do not have actual 486 hardware to test it on, just qemu... Rob From onefang at gmail.com Mon Mar 12 19:43:57 2018 From: onefang at gmail.com (David Seikel) Date: Tue, 13 Mar 2018 05:43:57 +1000 Subject: [mkroot] To the people who keeping pinging me off list... In-Reply-To: References: Message-ID: <20180313054357.4f711d39.onefang@gmail.com> On Mon, 12 Mar 2018 13:11:52 -0500 Rob Landley wrote: > FYI, I disabled all the subscriptions to the old aboriginal linux > mailing list when I moved 'em over (and made new subscriptions > require approval), so if you send a message there it goes into > moderation. My current "mkroot" email folder is still called "FWL". I've been around here for a while. lol > > Subject: Re: [mkroot] To the people who keeping pinging me off > > list... From: David Seikel > > Date: 03/08/2018 02:16 PM > > To: aboriginal at lists.landley.net > > > > On Thu, 08 Mar 2018 15:03:18 -0500 Alain Toussaint > > wrote: > > > >> > >>> getting the "and now we build linux from scratch and beyond linux > >>> from scratch natively under the result" infrastructure back in > >>> place > >> > >> I'd be the one in favor of that. I have been accepted as editor of > >> BLFS and even though I'm knee deep into build replicability > >> territory (build LFS --> boot LFS --> build second LFS under first > >> LFS --> see if it barf) so that I haven't been able to contribute > >> to the 8.2 release, we do have request for 686 build and I do know > >> that mkroot even support 486 and build a kernel for it (I myself > >> would be curious to find a 486 able to boot LFS 8,2). > > > > I might be able to help with that. If I recall correctly, I was > > responsible for adding the original Aboriginal Linux support, and I > > still have the 486 device I needed that for. Building LFS and BLFS > > is on my TODO, and is near the top of that TODO. > > I'm pretty sure 486 support works properly in mkroot? But you're > right, I do not have actual 486 hardware to test it on, just qemu... I started building LFS 8.1 on Sunday, and later today (Tuesday my time) I'll continue. I'm starting with the "build it manually yourself" method suggested in the automated LFS page, and scripting it myself as I go along. I'm up to the beginning of chapter 6, I'll likely start on bits of BLFS after finishing that. Chapter 6 should go quickly, half of it is building the stuff already built with some minor variations. Today I downloaded the 8.2 stuff, I'll switch over to that next, I was trying 8.1 first coz I had downloaded it's source some time ago. Bandwidth in Australia is expensive, I have to carefully ration out things like downloading 7 GB of LFS + BLFS source code, and 8.2 was only recently released. Then I'll move to using Aboriginal Linux for the job, which I have experience with, or skip straight to mkroot which I haven't tried yet. Currently building it on my x86_64 test box natively, I will at some point tell it to build for 486. Then I can test things on my real 486 hardware, which my old Aboriginal Linux build still works fine on. Earlier this year the 486 device was being audited by the government test labs, as it's the sort of device that requires that sort of thing. I did have the idea while working on this, that the various test suites that LFS builds for all the software that toybox replaces, might be a good idea to see if we can get them to test toybox. Dunno if you have tried that yet. -- A big old stinking pile of genius that no one wants coz there are too many silver coated monkeys in the world. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 181 bytes Desc: OpenPGP digital signature URL: From rob at landley.net Tue Mar 13 14:43:09 2018 From: rob at landley.net (Rob Landley) Date: Tue, 13 Mar 2018 09:43:09 -0500 Subject: [mkroot] To the people who keeping pinging me off list... In-Reply-To: <20180313054357.4f711d39.onefang@gmail.com> References: <20180313054357.4f711d39.onefang@gmail.com> Message-ID: <2df12f63-fac2-15d1-d513-8a25c7e3ddf2@landley.net> On 03/12/2018 02:43 PM, David Seikel wrote: > On Mon, 12 Mar 2018 13:11:52 -0500 Rob Landley wrote: > >> FYI, I disabled all the subscriptions to the old aboriginal linux >> mailing list when I moved 'em over (and made new subscriptions >> require approval), so if you send a message there it goes into >> moderation. > > My current "mkroot" email folder is still called "FWL". I've been > around here for a while. lol Ok, yes, that was a while ago. :) (And like that project, I may still rename this one. I should decide that this week...) > I started building LFS 8.1 on Sunday, and later today (Tuesday my time) > I'll continue. I'm starting with the "build it manually yourself" > method suggested in the automated LFS page, and scripting it myself as > I go along. I'm up to the beginning of chapter 6, I'll likely start on > bits of BLFS after finishing that. Chapter 6 should go quickly, half > of it is building the stuff already built with some minor variations. > > Today I downloaded the 8.2 stuff, I'll switch over to that next, I was > trying 8.1 first coz I had downloaded it's source some time ago. > Bandwidth in Australia is expensive, I have to carefully ration out > things like downloading 7 GB of LFS + BLFS source code, and 8.2 was > only recently released. Fun trick, git ls-remote and then fetch to a tag: git ls-remote git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux git fetch git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux v4.16-rc5 This not only lets you grab in smaller chunks (possibly spreading the bandwidth over multiple billing periods), but it also checkpoints the "download stopped halfway and it threw out the partial results so you need to restart" problem. (It'll still do it, but you only regress to the last checkpoint.) It'd be nice if there was a way to log remotely with better granularity, but the git developers have been asked for that repeatedly for a decade now and still can't undrstand why anyone would want to. (In general git has some of the same problems as android does: it's made by privileged people for whom certain resources are basically free. Can't log the repo without fetching gigabytes of data? Why would you ever _not_ spend gigabytes of data and disk space to produce 200k of text? Doesn't _everyone_ have a multi-terrabyte ssd they can afford to replace annually hooked up to unmetered fiber?) > Then I'll move to using Aboriginal Linux for the job, which I have > experience with, or skip straight to mkroot which I haven't tried yet. As with aboriginal, if you have the downloads directory already populated with the right tarballs mkroot won't re-download them. (Or if you have a git repo checked out in there.) This time around I didn't implement the fallback mirrors, patches directory, or package cache. But it's got the basics. :) > Currently building it on my x86_64 test box natively, I will at some > point tell it to build for 486. Then I can test things on my real 486 > hardware, which my old Aboriginal Linux build still works fine on. > Earlier this year the 486 device was being audited by the government > test labs, as it's the sort of device that requires that sort of thing. > > I did have the idea while working on this, that the various test suites > that LFS builds for all the software that toybox replaces, might be a > good idea to see if we can get them to test toybox. Dunno if you have > tried that yet. I have not but it sounds like fun. Rob From phil at pricom.com.au Tue Mar 13 16:28:18 2018 From: phil at pricom.com.au (Philip Rhoades) Date: Wed, 14 Mar 2018 03:28:18 +1100 Subject: [mkroot] To the people who keeping pinging me off list... In-Reply-To: <20180313054357.4f711d39.onefang@gmail.com> References: <20180313054357.4f711d39.onefang@gmail.com> Message-ID: David, On 2018-03-13 06:43, David Seikel wrote: > On Mon, 12 Mar 2018 13:11:52 -0500 Rob Landley wrote: > >> FYI, I disabled all the subscriptions to the old aboriginal linux >> mailing list when I moved 'em over (and made new subscriptions >> require approval), so if you send a message there it goes into >> moderation. > > My current "mkroot" email folder is still called "FWL". I've been > around here for a while. lol > >> > Subject: Re: [mkroot] To the people who keeping pinging me off >> > list... From: David Seikel >> > Date: 03/08/2018 02:16 PM >> > To: aboriginal at lists.landley.net >> > >> > On Thu, 08 Mar 2018 15:03:18 -0500 Alain Toussaint >> > wrote: >> > >> >> >> >>> getting the "and now we build linux from scratch and beyond linux >> >>> from scratch natively under the result" infrastructure back in >> >>> place >> >> >> >> I'd be the one in favor of that. I have been accepted as editor of >> >> BLFS and even though I'm knee deep into build replicability >> >> territory (build LFS --> boot LFS --> build second LFS under first >> >> LFS --> see if it barf) so that I haven't been able to contribute >> >> to the 8.2 release, we do have request for 686 build and I do know >> >> that mkroot even support 486 and build a kernel for it (I myself >> >> would be curious to find a 486 able to boot LFS 8,2). >> > >> > I might be able to help with that. If I recall correctly, I was >> > responsible for adding the original Aboriginal Linux support, and I >> > still have the 486 device I needed that for. Building LFS and BLFS >> > is on my TODO, and is near the top of that TODO. >> >> I'm pretty sure 486 support works properly in mkroot? But you're >> right, I do not have actual 486 hardware to test it on, just qemu... > > I started building LFS 8.1 on Sunday, and later today (Tuesday my time) > I'll continue. I'm starting with the "build it manually yourself" > method suggested in the automated LFS page, and scripting it myself as > I go along. I'm up to the beginning of chapter 6, I'll likely start on > bits of BLFS after finishing that. Chapter 6 should go quickly, half > of it is building the stuff already built with some minor variations. > > Today I downloaded the 8.2 stuff, I'll switch over to that next, I was > trying 8.1 first coz I had downloaded it's source some time ago. > Bandwidth in Australia is expensive, I have to carefully ration out > things like downloading 7 GB of LFS + BLFS source code, and 8.2 was > only recently released. > > Then I'll move to using Aboriginal Linux for the job, which I have > experience with, or skip straight to mkroot which I haven't tried yet. > > Currently building it on my x86_64 test box natively, I will at some > point tell it to build for 486. Then I can test things on my real 486 > hardware, which my old Aboriginal Linux build still works fine on. > Earlier this year the 486 device was being audited by the government > test labs, as it's the sort of device that requires that sort of thing. > > I did have the idea while working on this, that the various test suites > that LFS builds for all the software that toybox replaces, might be a > good idea to see if we can get them to test toybox. Dunno if you have > tried that yet. Where are you in Australia? If you were nearby I could probably help with downloading - I also have a working 486 (JPG attached) for which I want to make an image of its old SCSI drive to see if I can virtualise it. If it were possible, this is also the machine I would like to make some mkroot boot / root floppies for - although that seems too hard . . I have been trying to find the time for ages to do the LFS thing on my newer / faster workstations. I was in Sydney (still go back there occasionally) but now I am in a little country town (see below). Regards, Phil. -- Philip Rhoades PO Box 896 Cowra NSW 2794 Australia E-mail: phil at pricom.com.au -------------- next part -------------- A non-text attachment was scrubbed... Name: 20180314_022950t.jpg Type: image/jpeg Size: 154565 bytes Desc: not available URL: From rob at landley.net Tue Mar 13 16:45:54 2018 From: rob at landley.net (Rob Landley) Date: Tue, 13 Mar 2018 11:45:54 -0500 Subject: [mkroot] Submitted a dreamhost ticket about changing the mailing list name. Message-ID: (Honestly I probably should have done that for the aboriginal list, but I really don't want to cut and paste 100+ email addresses again. :) I think I do want to call the project "hermetic", because hermetic system builds are the point of the exercise. Dunno if that makes it "hermetic linux" or not... Anyway, I can rename the github this weekend, _and_ cut the new release so I can start tackling the new kernel nonsense in 4.15. In the near term I'd like to get the remaining busybox stuff out so the cpio.gz files have no gpl code in them. (The kernel images still would, but they have an official policy now about not being lawsuit-happy if you're hosting unmodified vanilla versions and _say_ so. Pity I lost my kernel.org directory or I'd just host the suckers _there_...) Rob From onefang at gmail.com Tue Mar 13 17:04:14 2018 From: onefang at gmail.com (David Seikel) Date: Wed, 14 Mar 2018 03:04:14 +1000 Subject: [mkroot] To the people who keeping pinging me off list... In-Reply-To: References: <20180313054357.4f711d39.onefang@gmail.com> Message-ID: <20180314030414.216ae8c4.onefang@gmail.com> On Wed, 14 Mar 2018 03:28:18 +1100 Philip Rhoades wrote: > David, > > > On 2018-03-13 06:43, David Seikel wrote: > > On Mon, 12 Mar 2018 13:11:52 -0500 Rob Landley > > wrote: > > > >> FYI, I disabled all the subscriptions to the old aboriginal linux > >> mailing list when I moved 'em over (and made new subscriptions > >> require approval), so if you send a message there it goes into > >> moderation. > > > > My current "mkroot" email folder is still called "FWL". I've been > > around here for a while. lol > > > >> > Subject: Re: [mkroot] To the people who keeping pinging me off > >> > list... From: David Seikel > >> > Date: 03/08/2018 02:16 PM > >> > To: aboriginal at lists.landley.net > >> > > >> > On Thu, 08 Mar 2018 15:03:18 -0500 Alain Toussaint > >> > wrote: > >> > > >> >> > >> >>> getting the "and now we build linux from scratch and beyond > >> >>> linux from scratch natively under the result" infrastructure > >> >>> back in place > >> >> > >> >> I'd be the one in favor of that. I have been accepted as editor > >> >> of BLFS and even though I'm knee deep into build replicability > >> >> territory (build LFS --> boot LFS --> build second LFS under > >> >> first LFS --> see if it barf) so that I haven't been able to > >> >> contribute to the 8.2 release, we do have request for 686 build > >> >> and I do know that mkroot even support 486 and build a kernel > >> >> for it (I myself would be curious to find a 486 able to boot > >> >> LFS 8,2). > >> > > >> > I might be able to help with that. If I recall correctly, I was > >> > responsible for adding the original Aboriginal Linux support, > >> > and I still have the 486 device I needed that for. Building LFS > >> > and BLFS is on my TODO, and is near the top of that TODO. > >> > >> I'm pretty sure 486 support works properly in mkroot? But you're > >> right, I do not have actual 486 hardware to test it on, just > >> qemu... > > > > I started building LFS 8.1 on Sunday, and later today (Tuesday my > > time) I'll continue. I'm starting with the "build it manually > > yourself" method suggested in the automated LFS page, and scripting > > it myself as I go along. I'm up to the beginning of chapter 6, > > I'll likely start on bits of BLFS after finishing that. Chapter 6 > > should go quickly, half of it is building the stuff already built > > with some minor variations. > > > > Today I downloaded the 8.2 stuff, I'll switch over to that next, I > > was trying 8.1 first coz I had downloaded it's source some time ago. > > Bandwidth in Australia is expensive, I have to carefully ration out > > things like downloading 7 GB of LFS + BLFS source code, and 8.2 was > > only recently released. > > > > Then I'll move to using Aboriginal Linux for the job, which I have > > experience with, or skip straight to mkroot which I haven't tried > > yet. > > > > Currently building it on my x86_64 test box natively, I will at some > > point tell it to build for 486. Then I can test things on my real > > 486 hardware, which my old Aboriginal Linux build still works fine > > on. Earlier this year the 486 device was being audited by the > > government test labs, as it's the sort of device that requires that > > sort of thing. > > > > I did have the idea while working on this, that the various test > > suites that LFS builds for all the software that toybox replaces, > > might be a good idea to see if we can get them to test toybox. > > Dunno if you have tried that yet. > > Where are you in Australia? I'm in Brisbane, so not nearby to Cowra. > If you were nearby I could probably help with downloading The 13th is my ISP roll over date for the month, and I had been good over the last month not using much bandwidth, so I had enough to download the 8.2 versions of LFS and BLFS books and source code, plus a few other big but unrelated things. I have now done so. > I also have a working 486 (JPG attached) for which > I want to make an image of its old SCSI drive to see if I can > virtualise it. If it were possible, this is also the machine I would > like to make some mkroot boot / root floppies for - although that > seems too hard . . I pointed out the ICOP people before, http://www.icop.com.tw/ that make the 486 board I use for some embedded work. (Note that I said https:// last time, then found out they don't respond so well to https, though that might be some oddness in my proxy, I didn't investigate further.) It's a tiny board (fits in the palm of your hand) that is almost a complete PC, including lots of GPIO pins for embedded work, VGA / LCD video out, USB 2, serial ports, PS2, audio, 256 MB RAM, and we add on a 512 MB flash disk. For many years we have been using Aboriginal Linux + control images (Robs pre cursor to mkroot) to build an embedded device that is subject to lengthy government regulations. This is where Aboriginals 486 support came from in the first place, we needed it, I wrote it, and sent it to Rob who included it. So I'm well versed in getting Aboriginal Linux and the rest of the OS needed to support the device running on it. All heavily scripted, I start the complete build on my workstation, come back in an hour and dd the completed disk image onto a USB stick that I then boot the 486 with for testing. Getting the basic Aboriginal Linux up and running on it is no longer hard now that it has 486 support. I've only glanced at mkroot, and it seems to be similar to parts of Aboriginal Linux, so I expect I'll be able to use it easily. I don't think I even have any floppy disk or SCSI equipment anymore, so you are on your own with that. My career is long enough that I have used such extensively far too many decades ago. > I have been trying to find the time for ages to do the LFS thing on > my newer / faster workstations. So have I, that time for me started last Sunday. If nothing else swallows my spare time like it did yesterday, I'll likely have a mkroot based LFS running on my 486 board at the end of next weekend. > I was in Sydney (still go back there occasionally) but now I am in a > little country town (see below). Sydney is a one hour flight from Brisbane, and you would know how long it takes you to get to Sydney from Cowra. Likely still too far just to drop off a USB stick, which I no longer need now anyway. Thanks for the offer though. -- A big old stinking pile of genius that no one wants coz there are too many silver coated monkeys in the world. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 181 bytes Desc: OpenPGP digital signature URL: From onefang at gmail.com Tue Mar 13 17:17:48 2018 From: onefang at gmail.com (David Seikel) Date: Wed, 14 Mar 2018 03:17:48 +1000 Subject: [mkroot] To the people who keeping pinging me off list... In-Reply-To: <2df12f63-fac2-15d1-d513-8a25c7e3ddf2@landley.net> References: <20180313054357.4f711d39.onefang@gmail.com> <2df12f63-fac2-15d1-d513-8a25c7e3ddf2@landley.net> Message-ID: <20180314031748.3c3b3b05.onefang@gmail.com> On Tue, 13 Mar 2018 09:43:09 -0500 Rob Landley wrote: > (In general git has some of the same problems as android does: it's > made by privileged people for whom certain resources are basically > free. Can't log the repo without fetching gigabytes of data? Why > would you ever _not_ spend gigabytes of data and disk space to > produce 200k of text? Doesn't _everyone_ have a multi-terrabyte ssd > they can afford to replace annually hooked up to unmetered fiber?) Yeah, I had that problem when a client wanted me to switch their 3D virtual world viewer to the latest at the time Google embedded web browser. The viewer includes a web browser for mostly trivial things, but something small like Netsurf isn't god enough for them. Luckily the client was paying well, so I just ate the cost of a weeks worth of downloads to get Google's embedded web browser build environment. That's a weeks worth in bandwidth quota cost, I have a fibre connection, it only took a few hours to actually download. Yes, I could blow my entire months quota in a single day, and still have time for meals and sleep. I dread the day some one aims a DDOS at my home while I'm out. Don't get me started on replacing expensive high capacity ssd. There's a reason why I keep my TBs on spinning rust. -- A big old stinking pile of genius that no one wants coz there are too many silver coated monkeys in the world. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 181 bytes Desc: OpenPGP digital signature URL: From rob at landley.net Tue Mar 13 18:28:33 2018 From: rob at landley.net (Rob Landley) Date: Tue, 13 Mar 2018 13:28:33 -0500 Subject: [mkroot] To the people who keeping pinging me off list... In-Reply-To: <20180314030414.216ae8c4.onefang@gmail.com> References: <20180313054357.4f711d39.onefang@gmail.com> <20180314030414.216ae8c4.onefang@gmail.com> Message-ID: <8cedd7a3-e3b1-c1b0-24aa-5084c7322343@landley.net> On 03/13/2018 12:04 PM, David Seikel wrote: > I've only glanced at mkroot, and it seems to be similar to parts of > Aboriginal Linux, so I expect I'll be able to use it easily. The general idea is hermetic (I.E. mkroot) doesn't build its own toolchains, and with that moved out the remaining aboriginal linux infrastructure was way too heavyweight for what it did, so I started over. Rich Felker (the musl-libc maintainer) created his own toolchain build (https://github.com/RichFelker/musl-cross-make) using current packages (gcc/binutils, musl, etc). And I gave him a lot of feedback along the way (no the kernel headers in /usr/include/linux aren't optional, please add native compilers), and the result was something usable. I make an mcm-buildall.sh script to build all the cross and native compilers musl-cross-make currently supports (that I know of). I'd like to push that script upstream but Rich wants to do things his own way. :) The new build is intentionally minimalistic. The basic root filesystem build is "mkroot.sh" by itself (which I should rename build.sh this weekend when it becomes hermetic). Additional build scripts can go in modules/ to compile more packages, the most interesting of which is "kernel" to build a linux kernel. You can copy mkroot.sh and modules/kernel.sh into their own directory and run them by themselves, they have no external dependencies except bash and some standard commands out of the $PATH. Eacy is about 200 lines of bash. The airlock step is now part of toybox (make install_airlock). If you look in toybox's scripts/install.sh you'll see: # The following are commands toybox should provide, but doesn't yet. # For now symlink the host version. This list must go away by 1.0. PENDING="bunzip2 bzcat dd diff expr ftpd ftpget ftpput gunzip less ping route tar test tr vi wget zcat awk bzip2 fdisk gzip sh sha512sum unxz xzcat bc" # "gcc" should go away for llvm, but some things still hardwire it TOOLCHAIN="ar as nm cc make ld gcc objdump" The TOOLCHAIN line is the toolchain binaries the build needs in the host $PATH. The first are the remaining things we copy out of the host $PATH which toybox should provide. The PENDING list is stuff toybox should be providing, but isn't yet. About half of it's in the pending directory but hasn't been cleaned up and promoted yet. Hermetic is still building a busybox binary, mostly for the command shell. (Doing a proper toybox shell is the single largest remaining todo item. Doing ask and vi are fighting for second place.) That busybox binary has: bunzip2, bzcat, bzip2, gunzip, gzip, hush, ping, route, sh, tar, unxz, vi, wget, xzcat, zcat Which I believe is entirely encapsulated by the "pending" list, above. I've been chipping away at the $PENDING list, but should probably context switch to getting the native toolchains plugged in. At the moment this involves adding a modules/make.sh because I haven't got make in toybox yet. (It's another biggish one. Less big than awk, probably around about sed's complexity.) In theory the native toolchain should just extract and run, but I need to figure out how to package it. (Aboriginal had a squashfs and some symlinks, I may do something similar. It's too big to go in the cpio.gz with the rest of the filesystem, it extracts tond half a gigabyte.) Right now I've been getting kernel+initramfs to build and boot on as many qemu targets as possible, with one block device. Back under aboriginal build control images needed _three" block devices (root filesystem, writeable /home, source and build scripts. When the root filesystem moved to initramfs, /dev/hda because the toolchain squashfs, still requiring three block devices.) I could package them together into a partitioned image, but all three partitions kinda want to be independent at a design level (native toolchain, writeable scratch space, build control image.) I'm considering trying to do a network filesystem instead? The SMB 3.0 protocol's posix mode sounds sane (more so than nfs or older smb; alas 9p is basically dead). I have a todo item to make an smb3 server in toybox and have that available for mounting on the host. (And if you loopback mount a file from the smb server, it's not going to care what's crazy about the actual protocol...) I could also try to use qemu's built-in virtfs, but it's 9p based and kinda crazy-ish. (Requires extra host libraries during the build because the qemu guys thing extended attributes require a shared library to use, so most people won't have it enabled...) Or I could just go back to "let's mount 3 block devices". (Maybe I can use virtual USB disks? Except then it's hard to control what order they go in, and each serves a different function and needs a unique identifier...) So there are still some design decisions to make here. :) Rob From onefang at gmail.com Tue Mar 13 19:30:16 2018 From: onefang at gmail.com (David Seikel) Date: Wed, 14 Mar 2018 05:30:16 +1000 Subject: [mkroot] To the people who keeping pinging me off list... In-Reply-To: <8cedd7a3-e3b1-c1b0-24aa-5084c7322343@landley.net> References: <20180313054357.4f711d39.onefang@gmail.com> <20180314030414.216ae8c4.onefang@gmail.com> <8cedd7a3-e3b1-c1b0-24aa-5084c7322343@landley.net> Message-ID: <20180314053016.3eed629d.onefang@gmail.com> On Tue, 13 Mar 2018 13:28:33 -0500 Rob Landley wrote: > On 03/13/2018 12:04 PM, David Seikel wrote: > > I've only glanced at mkroot, and it seems to be similar to parts of > > Aboriginal Linux, so I expect I'll be able to use it easily. > > The general idea is hermetic (I.E. mkroot) doesn't build its own > toolchains, and with that moved out the remaining aboriginal linux > infrastructure was way too heavyweight for what it did, so I started > over. > > Rich Felker (the musl-libc maintainer) created his own toolchain build > (https://github.com/RichFelker/musl-cross-make) using current packages > (gcc/binutils, musl, etc). And I gave him a lot of feedback along the > way (no the kernel headers in /usr/include/linux aren't optional, > please add native compilers), and the result was something usable. > > I make an mcm-buildall.sh script to build all the cross and native > compilers musl-cross-make currently supports (that I know of). I'd > like to push that script upstream but Rich wants to do things his own > way. :) > > The new build is intentionally minimalistic. The basic root > filesystem build is "mkroot.sh" by itself (which I should rename > build.sh this weekend when it becomes hermetic). Additional build > scripts can go in modules/ to compile more packages, the most > interesting of which is "kernel" to build a linux kernel. You can > copy mkroot.sh and modules/kernel.sh into their own directory and run > them by themselves, they have no external dependencies except bash > and some standard commands out of the $PATH. Eacy is about 200 lines > of bash. > > The airlock step is now part of toybox (make install_airlock). If you > look in toybox's scripts/install.sh you'll see: > > # The following are commands toybox should provide, but doesn't yet. > # For now symlink the host version. This list must go away by 1.0. > > PENDING="bunzip2 bzcat dd diff expr ftpd ftpget ftpput gunzip less > ping route tar test tr vi wget zcat awk bzip2 fdisk gzip sh sha512sum > unxz xzcat bc" > > # "gcc" should go away for llvm, but some things still hardwire it > TOOLCHAIN="ar as nm cc make ld gcc objdump" > > The TOOLCHAIN line is the toolchain binaries the build needs in the > host $PATH. The first are the remaining things we copy out of the > host $PATH which toybox should provide. > > The PENDING list is stuff toybox should be providing, but isn't yet. > About half of it's in the pending directory but hasn't been cleaned > up and promoted yet. > > Hermetic is still building a busybox binary, mostly for the command > shell. (Doing a proper toybox shell is the single largest remaining > todo item. Doing ask and vi are fighting for second place.) That > busybox binary has: > > bunzip2, bzcat, bzip2, gunzip, gzip, hush, ping, route, sh, > tar, unxz, vi, wget, xzcat, zcat > > Which I believe is entirely encapsulated by the "pending" list, above. > > I've been chipping away at the $PENDING list, but should probably > context switch to getting the native toolchains plugged in. At the > moment this involves adding a modules/make.sh because I haven't got > make in toybox yet. (It's another biggish one. Less big than awk, > probably around about sed's complexity.) > > In theory the native toolchain should just extract and run, but I > need to figure out how to package it. (Aboriginal had a squashfs and > some symlinks, I may do something similar. It's too big to go in the > cpio.gz with the rest of the filesystem, it extracts tond half a > gigabyte.) > > Right now I've been getting kernel+initramfs to build and boot on as > many qemu targets as possible, with one block device. Back under > aboriginal build control images needed _three" block devices (root > filesystem, writeable /home, source and build scripts. When the root > filesystem moved to initramfs, /dev/hda because the toolchain > squashfs, still requiring three block devices.) > > I could package them together into a partitioned image, but all three > partitions kinda want to be independent at a design level (native > toolchain, writeable scratch space, build control image.) > > I'm considering trying to do a network filesystem instead? The SMB 3.0 > protocol's posix mode sounds sane (more so than nfs or older smb; > alas 9p is basically dead). I have a todo item to make an smb3 server > in toybox and have that available for mounting on the host. (And if > you loopback mount a file from the smb server, it's not going to care > what's crazy about the actual protocol...) > > I could also try to use qemu's built-in virtfs, but it's 9p based and > kinda crazy-ish. (Requires extra host libraries during the build > because the qemu guys thing extended attributes require a shared > library to use, so most people won't have it enabled...) > > Or I could just go back to "let's mount 3 block devices". (Maybe I > can use virtual USB disks? Except then it's hard to control what > order they go in, and each serves a different function and needs a > unique identifier...) > > So there are still some design decisions to make here. :) Sounds like my goal of having mkroot produce a 486 LFS 8.2 bootable image by the end of next weekend might not be such a good idea if you are gonna change it next weekend anyway. I'll switch to 486 Aboriginal Linux + LFS for this week then, and switch to mkroot / hermetic later when the dust settles. So I get to play with your lfs-bootstrap control image after all. The LFS build scripts I have been writing should slot into that easily enough anyway, they are using similar concepts. Common infrastructure to get and unpack the package tarballs, then call build scripts named after the packages to actually build them. LFS has it's own airlock step, chapter 5. -- A big old stinking pile of genius that no one wants coz there are too many silver coated monkeys in the world. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 181 bytes Desc: OpenPGP digital signature URL: From rob at landley.net Tue Mar 13 19:53:19 2018 From: rob at landley.net (Rob Landley) Date: Tue, 13 Mar 2018 14:53:19 -0500 Subject: [mkroot] To the people who keeping pinging me off list... In-Reply-To: <20180314053016.3eed629d.onefang@gmail.com> References: <20180313054357.4f711d39.onefang@gmail.com> <20180314030414.216ae8c4.onefang@gmail.com> <8cedd7a3-e3b1-c1b0-24aa-5084c7322343@landley.net> <20180314053016.3eed629d.onefang@gmail.com> Message-ID: On 03/13/2018 02:30 PM, David Seikel wrote: > On Tue, 13 Mar 2018 13:28:33 -0500 Rob Landley wrote: >> So there are still some design decisions to make here. :) > > Sounds like my goal of having mkroot produce a 486 LFS 8.2 bootable > image by the end of next weekend might not be such a good idea if you > are gonna change it next weekend anyway. I'll switch to 486 Aboriginal > Linux + LFS for this week then, and switch to mkroot / hermetic later > when the dust settles. My worry would be that aboriginal's toolchains are really old now (something like 11 years), and I'm not sure all the current packages will build with them. (Mostly it's the kernel that complains. Userspace doesn't care.) > So I get to play with your lfs-bootstrap control > image after all. The LFS build scripts I have been writing should slot > into that easily enough anyway, they are using similar concepts. Common > infrastructure to get and unpack the package tarballs, then call build > scripts named after the packages to actually build them. LFS has it's > own airlock step, chapter 5. Linux From Scratch is where I got the idea from. I just ratcheted it up a bit. :) Rob From alain at vocatus.pub Tue Mar 13 20:06:24 2018 From: alain at vocatus.pub (Alain Toussaint) Date: Tue, 13 Mar 2018 16:06:24 -0400 Subject: [mkroot] To the people who keeping pinging me off list... In-Reply-To: References: <20180313054357.4f711d39.onefang@gmail.com> <20180314030414.216ae8c4.onefang@gmail.com> <8cedd7a3-e3b1-c1b0-24aa-5084c7322343@landley.net> <20180314053016.3eed629d.onefang@gmail.com> Message-ID: <1520971584.2049.0.camel@vocatus.pub> > My worry would be that aboriginal's toolchains are really old now (something > like 11 years), and I'm not sure all the current packages will build with them. > > (Mostly it's the kernel that complains. Userspace doesn't care.) Latest kernel require gcc 4.9 as a minimum. Alain From onefang at gmail.com Tue Mar 13 20:22:28 2018 From: onefang at gmail.com (David Seikel) Date: Wed, 14 Mar 2018 06:22:28 +1000 Subject: [mkroot] To the people who keeping pinging me off list... In-Reply-To: References: <20180313054357.4f711d39.onefang@gmail.com> <20180314030414.216ae8c4.onefang@gmail.com> <8cedd7a3-e3b1-c1b0-24aa-5084c7322343@landley.net> <20180314053016.3eed629d.onefang@gmail.com> Message-ID: <20180314062228.5f1cbea1.onefang@gmail.com> On Tue, 13 Mar 2018 14:53:19 -0500 Rob Landley wrote: > On 03/13/2018 02:30 PM, David Seikel wrote: > > On Tue, 13 Mar 2018 13:28:33 -0500 Rob Landley > > wrote: > >> So there are still some design decisions to make here. :) > > > > Sounds like my goal of having mkroot produce a 486 LFS 8.2 bootable > > image by the end of next weekend might not be such a good idea if > > you are gonna change it next weekend anyway. I'll switch to 486 > > Aboriginal Linux + LFS for this week then, and switch to mkroot / > > hermetic later when the dust settles. > > My worry would be that aboriginal's toolchains are really old now > (something like 11 years), and I'm not sure all the current packages > will build with them. Which is why I'm starting with a by the book build. Figure out how it's supposed to work first, get that right, then screw with it to get what I want. "What I want" in this case is two final goals. One is a BLFS build suitable for what I call my "Magic Pixie Dust" micro SD card, a currently 200 GB micro SD card with over 20 different OSes (and other stuff) on it, giving me a useful tool to carry around with a tiny USB micro SD card adapter, that I can plug into any random computer people ask me to do tricky things on. Also a learning / teaching tool. I'm thinking swapping to a 256 GB micro SD card might be worthwhile, dunno yet. The second goal is a BLFS build for my embedded 486, mostly as an experiment to try out mkroot, see if it's suitable for the next version of my clients embedded device. For both goals replacing things with toybox is part of it. The journey is as important as the destination here. > (Mostly it's the kernel that complains. Userspace doesn't care.) > > > So I get to play with your lfs-bootstrap control > > image after all. The LFS build scripts I have been writing should > > slot into that easily enough anyway, they are using similar > > concepts. Common infrastructure to get and unpack the package > > tarballs, then call build scripts named after the packages to > > actually build them. LFS has it's own airlock step, chapter 5. > > Linux From Scratch is where I got the idea from. I just ratcheted it > up a bit. :) Maybe a second airlock step might do the job. Build Aboriginal Linux first, boot it up in qemu, use that to build the LFS airlock step, including the newer toolchain. I'll see when I get there. Depends on timing. So far this week lots of unexpected busy work has come my way, and I'm now two days behind in my LFS project. Which really only matters coz I've posted my plans for this week to this list, people might be watching. lol If that continues, you might get the hermetic change over done to a point where it's suitable for my use on this project before I get around to trying LFS under Aboriginal Linux builds. -- A big old stinking pile of genius that no one wants coz there are too many silver coated monkeys in the world. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 181 bytes Desc: OpenPGP digital signature URL: From rob at landley.net Tue Mar 13 20:41:17 2018 From: rob at landley.net (Rob Landley) Date: Tue, 13 Mar 2018 15:41:17 -0500 Subject: [mkroot] To the people who keeping pinging me off list... In-Reply-To: <20180314062228.5f1cbea1.onefang@gmail.com> References: <20180313054357.4f711d39.onefang@gmail.com> <20180314030414.216ae8c4.onefang@gmail.com> <8cedd7a3-e3b1-c1b0-24aa-5084c7322343@landley.net> <20180314053016.3eed629d.onefang@gmail.com> <20180314062228.5f1cbea1.onefang@gmail.com> Message-ID: <212c4614-b06a-0632-ef04-bd532fb3960b@landley.net> On 03/13/2018 03:22 PM, David Seikel wrote: >> Linux From Scratch is where I got the idea from. I just ratcheted it >> up a bit. :) > > Maybe a second airlock step might do the job. Build Aboriginal Linux > first, boot it up in qemu, use that to build the LFS airlock step, > including the newer toolchain. I was considering that, but architecture support (armv8) and the ability to run current kernels kinda threw a wrench in that. I'm still thinking something like an extended xv6 might be a reasonable approach. People keep telling me to look at netbsd but I think I'm biologically incapable of caring about them after https://lwn.net/Articles/197748/ given that _microsoft_ was the company that stepped up to bail them out. Besides, netbsd isn't an improvement on http://landley.net/notes-2014.html#11-09-2014 http://landley.net/notes-2014.html#18-06-2014 http://landley.net/notes-2014.html#01-04-2014 http://landley.net/notes-2013.html#15-09-2013 http://landley.net/notes-2012.html#20-12-2012 And there are a bunch of alternatives probably farther along than xv6, http://landley.net/notes-2017.html#22-02-2017 But for the moment: Linux. Rob From phil at pricom.com.au Tue Mar 13 21:35:55 2018 From: phil at pricom.com.au (Philip Rhoades) Date: Wed, 14 Mar 2018 08:35:55 +1100 Subject: [mkroot] Fwd: Re: To the people who keeping pinging me off list... In-Reply-To: <87cf1bb32dbda9ca31eb0cfda2cce4b8@pricom.com.au> References: <20180313054357.4f711d39.onefang@gmail.com> <20180314030414.216ae8c4.onefang@gmail.com> <87cf1bb32dbda9ca31eb0cfda2cce4b8@pricom.com.au> Message-ID: <4875fa59d15ed72ceddc030a8af237ad@pricom.com.au> Sorry, should have replied to all . . -------- Original Message -------- Subject: Re: [mkroot] To the people who keeping pinging me off list... Date: 2018-03-14 08:33 From: Philip Rhoades To: David Seikel Reply-To: phil at pricom.com.au David, On 2018-03-14 04:04, David Seikel wrote: > On Wed, 14 Mar 2018 03:28:18 +1100 Philip Rhoades > wrote: > >> David, >> >> >> On 2018-03-13 06:43, David Seikel wrote: >> > On Mon, 12 Mar 2018 13:11:52 -0500 Rob Landley >> > wrote: >> > >> >> FYI, I disabled all the subscriptions to the old aboriginal linux >> >> mailing list when I moved 'em over (and made new subscriptions >> >> require approval), so if you send a message there it goes into >> >> moderation. >> > >> > My current "mkroot" email folder is still called "FWL". I've been >> > around here for a while. lol >> > >> >> > Subject: Re: [mkroot] To the people who keeping pinging me off >> >> > list... From: David Seikel >> >> > Date: 03/08/2018 02:16 PM >> >> > To: aboriginal at lists.landley.net >> >> > >> >> > On Thu, 08 Mar 2018 15:03:18 -0500 Alain Toussaint >> >> > wrote: >> >> > >> >> >> >> >> >>> getting the "and now we build linux from scratch and beyond >> >> >>> linux from scratch natively under the result" infrastructure >> >> >>> back in place >> >> >> >> >> >> I'd be the one in favor of that. I have been accepted as editor >> >> >> of BLFS and even though I'm knee deep into build replicability >> >> >> territory (build LFS --> boot LFS --> build second LFS under >> >> >> first LFS --> see if it barf) so that I haven't been able to >> >> >> contribute to the 8.2 release, we do have request for 686 build >> >> >> and I do know that mkroot even support 486 and build a kernel >> >> >> for it (I myself would be curious to find a 486 able to boot >> >> >> LFS 8,2). >> >> > >> >> > I might be able to help with that. If I recall correctly, I was >> >> > responsible for adding the original Aboriginal Linux support, >> >> > and I still have the 486 device I needed that for. Building LFS >> >> > and BLFS is on my TODO, and is near the top of that TODO. >> >> >> >> I'm pretty sure 486 support works properly in mkroot? But you're >> >> right, I do not have actual 486 hardware to test it on, just >> >> qemu... >> > >> > I started building LFS 8.1 on Sunday, and later today (Tuesday my >> > time) I'll continue. I'm starting with the "build it manually >> > yourself" method suggested in the automated LFS page, and scripting >> > it myself as I go along. I'm up to the beginning of chapter 6, >> > I'll likely start on bits of BLFS after finishing that. Chapter 6 >> > should go quickly, half of it is building the stuff already built >> > with some minor variations. >> > >> > Today I downloaded the 8.2 stuff, I'll switch over to that next, I >> > was trying 8.1 first coz I had downloaded it's source some time ago. >> > Bandwidth in Australia is expensive, I have to carefully ration out >> > things like downloading 7 GB of LFS + BLFS source code, and 8.2 was >> > only recently released. >> > >> > Then I'll move to using Aboriginal Linux for the job, which I have >> > experience with, or skip straight to mkroot which I haven't tried >> > yet. >> > >> > Currently building it on my x86_64 test box natively, I will at some >> > point tell it to build for 486. Then I can test things on my real >> > 486 hardware, which my old Aboriginal Linux build still works fine >> > on. Earlier this year the 486 device was being audited by the >> > government test labs, as it's the sort of device that requires that >> > sort of thing. >> > >> > I did have the idea while working on this, that the various test >> > suites that LFS builds for all the software that toybox replaces, >> > might be a good idea to see if we can get them to test toybox. >> > Dunno if you have tried that yet. >> >> Where are you in Australia? > > I'm in Brisbane, so not nearby to Cowra. Yep, bit of a trek from here . . although I do have relatives at Byron Bay that I visit every now and then . . which is a fair bit closer . . >> If you were nearby I could probably help with downloading > > The 13th is my ISP roll over date for the month, and I had been good > over the last month not using much bandwidth, so I had enough to > download the 8.2 versions of LFS and BLFS books and source code, plus a > few other big but unrelated things. I have now done so. > >> I also have a working 486 (JPG attached) for which >> I want to make an image of its old SCSI drive to see if I can >> virtualise it. If it were possible, this is also the machine I would >> like to make some mkroot boot / root floppies for - although that >> seems too hard . . > > I pointed out the ICOP people before, http://www.icop.com.tw/ that make > the 486 board I use for some embedded work. I did look at that stuff and it IS interesting - it would be good to explore that at some time too - I have been meaning to look RPis ever since they came out and still haven't managed to get around to it . . so I am interested to see how things go for you with mkroot . . > (Note that I said https:// > last time, then found out they don't respond so well to https, though > that might be some oddness in my proxy, I didn't investigate further.) > It's a tiny board (fits in the palm of your hand) that is almost a > complete PC, including lots of GPIO pins for embedded work, VGA / LCD > video out, USB 2, serial ports, PS2, audio, 256 MB RAM, and we add on a > 512 MB flash disk. Yes, it is very cool and I am greatly motivated to have a closer look . . > For many years we have been using Aboriginal Linux + > control images (Robs pre cursor to mkroot) to build an embedded device > that is subject to lengthy government regulations. This is where > Aboriginals 486 support came from in the first place, we needed it, I > wrote it, and sent it to Rob who included it. I would be interested in hearing more about that project - by direct mail if others would prefer for it not to be on this list . . > So I'm well versed in getting Aboriginal Linux and the rest of the OS > needed to support the device running on it. All heavily scripted, I > start the complete build on my workstation, come back in an hour and > dd the completed disk image onto a USB stick that I then boot the 486 > with for testing. Getting the basic Aboriginal Linux up and running on > it is no longer hard now that it has 486 support. Very interesting . . > I've only glanced at mkroot, and it seems to be similar to parts of > Aboriginal Linux, so I expect I'll be able to use it easily. Certainly let us know how it goes. > I don't think I even have any floppy disk or SCSI equipment anymore, so > you are on your own with that. My career is long enough that I have > used such extensively far too many decades ago. I have still have a working Exidy Sorcerer (audio tape based) and Osborne luggable . . my (current) place is turning into a museum . . >> I have been trying to find the time for ages to do the LFS thing on >> my newer / faster workstations. > > So have I, that time for me started last Sunday. If nothing else > swallows my spare time like it did yesterday, I'll likely have a mkroot > based LFS running on my 486 board at the end of next weekend. Excellent . . >> I was in Sydney (still go back there occasionally) but now I am in a >> little country town (see below). > > Sydney is a one hour flight from Brisbane, and you would know how long > it takes you to get to Sydney from Cowra. Likely still too far just to > drop off a USB stick, which I no longer need now anyway. Thanks for > the > offer though. Good that you don't need the downloading help now but it would be good to chat one day - but it sounds like the 486 stuff is at work and they may not appreciate visitors I suppose? Regards, Phil. -- Philip Rhoades PO Box 896 Cowra NSW 2794 Australia E-mail: phil at pricom.com.au From onefang at gmail.com Tue Mar 13 21:52:40 2018 From: onefang at gmail.com (David Seikel) Date: Wed, 14 Mar 2018 07:52:40 +1000 Subject: [mkroot] To the people who keeping pinging me off list... In-Reply-To: <212c4614-b06a-0632-ef04-bd532fb3960b@landley.net> References: <20180313054357.4f711d39.onefang@gmail.com> <20180314030414.216ae8c4.onefang@gmail.com> <8cedd7a3-e3b1-c1b0-24aa-5084c7322343@landley.net> <20180314053016.3eed629d.onefang@gmail.com> <20180314062228.5f1cbea1.onefang@gmail.com> <212c4614-b06a-0632-ef04-bd532fb3960b@landley.net> Message-ID: <20180314075240.2a854e6c.onefang@gmail.com> On Tue, 13 Mar 2018 15:41:17 -0500 Rob Landley wrote: > On 03/13/2018 03:22 PM, David Seikel wrote: > >> Linux From Scratch is where I got the idea from. I just ratcheted > >> it up a bit. :) > > > > Maybe a second airlock step might do the job. Build Aboriginal > > Linux first, boot it up in qemu, use that to build the LFS airlock > > step, including the newer toolchain. > > I was considering that, but architecture support (armv8) and the > ability to run current kernels kinda threw a wrench in that. Current kernels is where I want to go, and the client is considering switching from the 486 to some ARM based Olimex board for the new project, but keeping the 486 for the old one. The new project is basically an enhanced version of the old one, but for a different regulatory jurisdiction. Luckily both jurisdictions share most of their relevant laws, and I had those laws in mind while designing the old one. > I'm still thinking something like an extended xv6 might be a > reasonable approach. People keep telling me to look at netbsd but I > think I'm biologically incapable of caring about them after > https://lwn.net/Articles/197748/ given that _microsoft_ was the > company that stepped up to bail them out. > > Besides, netbsd isn't an improvement on > http://landley.net/notes-2014.html#11-09-2014 > http://landley.net/notes-2014.html#18-06-2014 > http://landley.net/notes-2014.html#01-04-2014 > http://landley.net/notes-2013.html#15-09-2013 > http://landley.net/notes-2012.html#20-12-2012 > > And there are a bunch of alternatives probably farther along than xv6, > http://landley.net/notes-2017.html#22-02-2017 > > But for the moment: Linux. I have tried getting some version of BSD onto my Magic Pixie Dust, but none of them seem to like living on a GPT partitioned micro SD card, sharing partitions with a variety of Linux OSes, a FAT partition for sharing data, and whatever UEFI magic partition I'll have to add to get the thing to boot on Macs. Looks like I haven't looked at as many BSD variants as you have. I've currently put Magic Pixie Dust's BSD on hold. From your notes above, 50 GB? Wont work under a VM? Must use ZFS? BSD might just end up in the too hard basket for both of us. Until just now I had not heard of xv6, it looks to mostly be an educational tool, so might be suitable for adding to my Magic Pixie Dust. If it's more cooperative than the BSDs I have tried so far. -- A big old stinking pile of genius that no one wants coz there are too many silver coated monkeys in the world. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 181 bytes Desc: OpenPGP digital signature URL: From onefang at gmail.com Tue Mar 13 22:15:39 2018 From: onefang at gmail.com (David Seikel) Date: Wed, 14 Mar 2018 08:15:39 +1000 Subject: [mkroot] Fwd: Re: To the people who keeping pinging me off list... In-Reply-To: <4875fa59d15ed72ceddc030a8af237ad@pricom.com.au> References: <20180313054357.4f711d39.onefang@gmail.com> <20180314030414.216ae8c4.onefang@gmail.com> <87cf1bb32dbda9ca31eb0cfda2cce4b8@pricom.com.au> <4875fa59d15ed72ceddc030a8af237ad@pricom.com.au> Message-ID: <20180314081539.414182a3.onefang@gmail.com> On Wed, 14 Mar 2018 08:35:55 +1100 Philip Rhoades wrote: > Sorry, should have replied to all . . > > > -------- Original Message -------- > Subject: Re: [mkroot] To the people who keeping pinging me off list... > Date: 2018-03-14 08:33 > From: Philip Rhoades > To: David Seikel > Reply-To: phil at pricom.com.au > > David, > > > On 2018-03-14 04:04, David Seikel wrote: > > On Wed, 14 Mar 2018 03:28:18 +1100 Philip Rhoades > > wrote: > > > >> I also have a working 486 (JPG attached) for which > >> I want to make an image of its old SCSI drive to see if I can > >> virtualise it. If it were possible, this is also the machine I > >> would like to make some mkroot boot / root floppies for - although > >> that seems too hard . . > > > > I pointed out the ICOP people before, http://www.icop.com.tw/ that > > make the 486 board I use for some embedded work. > > > I did look at that stuff and it IS interesting - it would be good to > explore that at some time too - I have been meaning to look RPis ever > since they came out and still haven't managed to get around to it . . > so I am interested to see how things go for you with mkroot . . As I just mentioned in my last email to this list, there is also Olimex, similar to RPis, but the hardware side is more open. Which is why my client is interested in it, maybe use one of their open source designs and modify it to suit. It's still being evaluated. https://www.olimex.com/ > > (Note that I said https:// > > last time, then found out they don't respond so well to https, > > though that might be some oddness in my proxy, I didn't investigate > > further.) It's a tiny board (fits in the palm of your hand) that is > > almost a complete PC, including lots of GPIO pins for embedded > > work, VGA / LCD video out, USB 2, serial ports, PS2, audio, 256 MB > > RAM, and we add on a 512 MB flash disk. > > > Yes, it is very cool and I am greatly motivated to have a closer > look . . > > > > For many years we have been using Aboriginal Linux + > > control images (Robs pre cursor to mkroot) to build an embedded > > device that is subject to lengthy government regulations. This is > > where Aboriginals 486 support came from in the first place, we > > needed it, I wrote it, and sent it to Rob who included it. > > > I would be interested in hearing more about that project - by direct > mail if others would prefer for it not to be on this list . . I'd have to ask the client for permission to talk about that first. And yes, direct email, that's definitely going off topic. Though on this list; that has changed it's name a few times, and looks like changing once more, plus the toybox list; I've mentioned this project a few times in the past. > > So I'm well versed in getting Aboriginal Linux and the rest of the > > OS needed to support the device running on it. All heavily > > scripted, I start the complete build on my workstation, come back > > in an hour and dd the completed disk image onto a USB stick that I > > then boot the 486 with for testing. Getting the basic Aboriginal > > Linux up and running on it is no longer hard now that it has 486 > > support. > > > Very interesting . . > > > > I've only glanced at mkroot, and it seems to be similar to parts of > > Aboriginal Linux, so I expect I'll be able to use it easily. > > > Certainly let us know how it goes. > > > > I don't think I even have any floppy disk or SCSI equipment > > anymore, so you are on your own with that. My career is long > > enough that I have used such extensively far too many decades ago. > > > I have still have a working Exidy Sorcerer (audio tape based) and > Osborne luggable . . my (current) place is turning into a museum . . Most of my museum pieces are likely in storage at some random siblings house in Melbourne. I'm not sure where that all ended up after I moved from there. I have a historically significant Amiga in that lot. On my desk is a historically significant Sony PlayStation 3, but I've not turned it on for years. Last time I turned it on I saw bit rot in the graphics memory, some pixels are stuck in some random colours. First time I have seen actual bit rot on screen. > >> I have been trying to find the time for ages to do the LFS thing on > >> my newer / faster workstations. > > > > So have I, that time for me started last Sunday. If nothing else > > swallows my spare time like it did yesterday, I'll likely have a > > mkroot based LFS running on my 486 board at the end of next weekend. > > > Excellent . . Or not, see the other emails. lol I'll try to get some sort of LFS system running on the 486 by the end of the weekend, it may just be raw LFS though. I'll see what happens. My mkroot / hermetic hacking will wait until after Robs planned changes for next weekend. > >> I was in Sydney (still go back there occasionally) but now I am in > >> a little country town (see below). > > > > Sydney is a one hour flight from Brisbane, and you would know how > > long it takes you to get to Sydney from Cowra. Likely still too > > far just to drop off a USB stick, which I no longer need now > > anyway. Thanks for the > > offer though. > > > Good that you don't need the downloading help now but it would be > good to chat one day - but it sounds like the 486 stuff is at work > and they may not appreciate visitors I suppose? The client is in Melbourne, I mostly work from home in Brisbane, the market for the current device is Queensland, the new one is for the Victorian market. I usually have at least one 486 board and other parts of the device sitting on my desk, enough for me to do development. Sometimes I have other bits of the device as needed. The finished product is a bit large for squeezing into my small home office, but there's a factory full of them elsewhere in Brisbane. And one in a local government test lab that I can walk to from here, they don't like random drop ins. I don't mind visitors, though that usually means I'll have to put on some clothes if it's in summer. -- A big old stinking pile of genius that no one wants coz there are too many silver coated monkeys in the world. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 181 bytes Desc: OpenPGP digital signature URL: From phil at pricom.com.au Wed Mar 14 07:03:25 2018 From: phil at pricom.com.au (Philip Rhoades) Date: Wed, 14 Mar 2018 18:03:25 +1100 Subject: [mkroot] Fwd: Re: To the people who keeping pinging me off list... In-Reply-To: <20180314081539.414182a3.onefang@gmail.com> References: <20180313054357.4f711d39.onefang@gmail.com> <20180314030414.216ae8c4.onefang@gmail.com> <87cf1bb32dbda9ca31eb0cfda2cce4b8@pricom.com.au> <4875fa59d15ed72ceddc030a8af237ad@pricom.com.au> <20180314081539.414182a3.onefang@gmail.com> Message-ID: David, On 2018-03-14 09:15, David Seikel wrote: > The client is in Melbourne, I mostly work from home in Brisbane, the > market for the current device is Queensland, the new one is for the > Victorian market. I usually have at least one 486 board and other > parts > of the device sitting on my desk, enough for me to do development. > Sometimes I have other bits of the device as needed. The finished > product is a bit large for squeezing into my small home office, but > there's a factory full of them elsewhere in Brisbane. And one in a > local government test lab that I can walk to from here, they don't > like random drop ins. I don't mind visitors, though that usually means > I'll have to put on some clothes if it's in summer. Ha! For Summers I was forced to install a solar-powered AC when I got to Cowra in the West facing bedroom / office - so I understand . . P. -- Philip Rhoades PO Box 896 Cowra NSW 2794 Australia E-mail: phil at pricom.com.au From phr at philiprhoades.org Tue Mar 13 21:34:59 2018 From: phr at philiprhoades.org (Philip Rhoades) Date: Wed, 14 Mar 2018 08:34:59 +1100 Subject: [mkroot] Fwd: Re: To the people who keeping pinging me off list... In-Reply-To: <87cf1bb32dbda9ca31eb0cfda2cce4b8@pricom.com.au> References: <20180313054357.4f711d39.onefang@gmail.com> <20180314030414.216ae8c4.onefang@gmail.com> <87cf1bb32dbda9ca31eb0cfda2cce4b8@pricom.com.au> Message-ID: <9d777384065923a41d71806b9d8fd987@philiprhoades.org> Sorry, should have replied to all . . -------- Original Message -------- Subject: Re: [mkroot] To the people who keeping pinging me off list... Date: 2018-03-14 08:33 From: Philip Rhoades To: David Seikel Reply-To: phil at pricom.com.au David, On 2018-03-14 04:04, David Seikel wrote: > On Wed, 14 Mar 2018 03:28:18 +1100 Philip Rhoades > wrote: > >> David, >> >> >> On 2018-03-13 06:43, David Seikel wrote: >> > On Mon, 12 Mar 2018 13:11:52 -0500 Rob Landley >> > wrote: >> > >> >> FYI, I disabled all the subscriptions to the old aboriginal linux >> >> mailing list when I moved 'em over (and made new subscriptions >> >> require approval), so if you send a message there it goes into >> >> moderation. >> > >> > My current "mkroot" email folder is still called "FWL". I've been >> > around here for a while. lol >> > >> >> > Subject: Re: [mkroot] To the people who keeping pinging me off >> >> > list... From: David Seikel >> >> > Date: 03/08/2018 02:16 PM >> >> > To: aboriginal at lists.landley.net >> >> > >> >> > On Thu, 08 Mar 2018 15:03:18 -0500 Alain Toussaint >> >> > wrote: >> >> > >> >> >> >> >> >>> getting the "and now we build linux from scratch and beyond >> >> >>> linux from scratch natively under the result" infrastructure >> >> >>> back in place >> >> >> >> >> >> I'd be the one in favor of that. I have been accepted as editor >> >> >> of BLFS and even though I'm knee deep into build replicability >> >> >> territory (build LFS --> boot LFS --> build second LFS under >> >> >> first LFS --> see if it barf) so that I haven't been able to >> >> >> contribute to the 8.2 release, we do have request for 686 build >> >> >> and I do know that mkroot even support 486 and build a kernel >> >> >> for it (I myself would be curious to find a 486 able to boot >> >> >> LFS 8,2). >> >> > >> >> > I might be able to help with that. If I recall correctly, I was >> >> > responsible for adding the original Aboriginal Linux support, >> >> > and I still have the 486 device I needed that for. Building LFS >> >> > and BLFS is on my TODO, and is near the top of that TODO. >> >> >> >> I'm pretty sure 486 support works properly in mkroot? But you're >> >> right, I do not have actual 486 hardware to test it on, just >> >> qemu... >> > >> > I started building LFS 8.1 on Sunday, and later today (Tuesday my >> > time) I'll continue. I'm starting with the "build it manually >> > yourself" method suggested in the automated LFS page, and scripting >> > it myself as I go along. I'm up to the beginning of chapter 6, >> > I'll likely start on bits of BLFS after finishing that. Chapter 6 >> > should go quickly, half of it is building the stuff already built >> > with some minor variations. >> > >> > Today I downloaded the 8.2 stuff, I'll switch over to that next, I >> > was trying 8.1 first coz I had downloaded it's source some time ago. >> > Bandwidth in Australia is expensive, I have to carefully ration out >> > things like downloading 7 GB of LFS + BLFS source code, and 8.2 was >> > only recently released. >> > >> > Then I'll move to using Aboriginal Linux for the job, which I have >> > experience with, or skip straight to mkroot which I haven't tried >> > yet. >> > >> > Currently building it on my x86_64 test box natively, I will at some >> > point tell it to build for 486. Then I can test things on my real >> > 486 hardware, which my old Aboriginal Linux build still works fine >> > on. Earlier this year the 486 device was being audited by the >> > government test labs, as it's the sort of device that requires that >> > sort of thing. >> > >> > I did have the idea while working on this, that the various test >> > suites that LFS builds for all the software that toybox replaces, >> > might be a good idea to see if we can get them to test toybox. >> > Dunno if you have tried that yet. >> >> Where are you in Australia? > > I'm in Brisbane, so not nearby to Cowra. Yep, bit of a trek from here . . although I do have relatives at Byron Bay that I visit every now and then . . which is a fair bit closer . . >> If you were nearby I could probably help with downloading > > The 13th is my ISP roll over date for the month, and I had been good > over the last month not using much bandwidth, so I had enough to > download the 8.2 versions of LFS and BLFS books and source code, plus a > few other big but unrelated things. I have now done so. > >> I also have a working 486 (JPG attached) for which >> I want to make an image of its old SCSI drive to see if I can >> virtualise it. If it were possible, this is also the machine I would >> like to make some mkroot boot / root floppies for - although that >> seems too hard . . > > I pointed out the ICOP people before, http://www.icop.com.tw/ that make > the 486 board I use for some embedded work. I did look at that stuff and it IS interesting - it would be good to explore that at some time too - I have been meaning to look RPis ever since they came out and still haven't managed to get around to it . . so I am interested to see how things go for you with mkroot . . > (Note that I said https:// > last time, then found out they don't respond so well to https, though > that might be some oddness in my proxy, I didn't investigate further.) > It's a tiny board (fits in the palm of your hand) that is almost a > complete PC, including lots of GPIO pins for embedded work, VGA / LCD > video out, USB 2, serial ports, PS2, audio, 256 MB RAM, and we add on a > 512 MB flash disk. Yes, it is very cool and I am greatly motivated to have a closer look . . > For many years we have been using Aboriginal Linux + > control images (Robs pre cursor to mkroot) to build an embedded device > that is subject to lengthy government regulations. This is where > Aboriginals 486 support came from in the first place, we needed it, I > wrote it, and sent it to Rob who included it. I would be interested in hearing more about that project - by direct mail if others would prefer for it not to be on this list . . > So I'm well versed in getting Aboriginal Linux and the rest of the OS > needed to support the device running on it. All heavily scripted, I > start the complete build on my workstation, come back in an hour and > dd the completed disk image onto a USB stick that I then boot the 486 > with for testing. Getting the basic Aboriginal Linux up and running on > it is no longer hard now that it has 486 support. Very interesting . . > I've only glanced at mkroot, and it seems to be similar to parts of > Aboriginal Linux, so I expect I'll be able to use it easily. Certainly let us know how it goes. > I don't think I even have any floppy disk or SCSI equipment anymore, so > you are on your own with that. My career is long enough that I have > used such extensively far too many decades ago. I have still have a working Exidy Sorcerer (audio tape based) and Osborne luggable . . my (current) place is turning into a museum . . >> I have been trying to find the time for ages to do the LFS thing on >> my newer / faster workstations. > > So have I, that time for me started last Sunday. If nothing else > swallows my spare time like it did yesterday, I'll likely have a mkroot > based LFS running on my 486 board at the end of next weekend. Excellent . . >> I was in Sydney (still go back there occasionally) but now I am in a >> little country town (see below). > > Sydney is a one hour flight from Brisbane, and you would know how long > it takes you to get to Sydney from Cowra. Likely still too far just to > drop off a USB stick, which I no longer need now anyway. Thanks for > the > offer though. Good that you don't need the downloading help now but it would be good to chat one day - but it sounds like the 486 stuff is at work and they may not appreciate visitors I suppose? Regards, Phil. -- Philip Rhoades "Life is too short . . we should be reducing suffering wherever we can while we explore the rest of The Universe - instead of destroying this beautiful and unique Pale Blue Dot". PO Box 896 Cowra NSW 2794 Australia Web: http://philiprhoades.org E-mail: phr at philiprhoades.org Chat with my Avatar on FB here: https://www.facebook.com/PhiRhoChat From rob at landley.net Fri Mar 16 16:31:54 2018 From: rob at landley.net (Rob Landley) Date: Fri, 16 Mar 2018 11:31:54 -0500 Subject: [mkroot] Project rename. Message-ID: <96cf3c65-99b7-ca21-c35b-e0c119e5e903@landley.net> The problem with renaming the github is it's not obvious where to find the new one (the old one's just a 404). So I think what I should do is: 1) Cut a release under the current name, but announce the project will rename _next_ release. 2) Leave the mailing list under the current name, with the current archive repository URL. That sound like a reasonable approach? (This has been holding up the release because I didn't know whether I should do the release under the new name or the old name...) Rob From rob at landley.net Sun Mar 18 01:48:01 2018 From: rob at landley.net (Rob Landley) Date: Sat, 17 Mar 2018 20:48:01 -0500 Subject: [mkroot] Tagged and pushed 0.5.0. Message-ID: Arbitrarily numered, I haven't hooked up the native build plumbing yet so this is about half of what I mean to do, so... I'm looking at the Open Source Summit Japan CFP which closes tomorrow: https://linuxfoundation.smapply.io/prog/open_source_summit_japan_2018/ And wondering if I can get the rest of the LFS native plumbing in place in time to give a talk about it there. I suppose I can submit the talk and see if it's accepted, and then do the work if they say yes. :) I tested the following architectures under qemu 2.11.0: aarch64 mips x86_64 armv5l i486 s390x armv7l i686 mipsel powerpc sh4 And they all booted and ran, although sh4 is a bit broken (serial UART buffer doesn't generate an interrupt unless it's full so you only get input you type in blocks of 16 characters, there's no battery backed up clock, and the emulated board only has 64 megs of ram). There are several more mcm-buildall.sh architectures that don't finish building, and those don't work yet. I need to replace the rest of busybox with toybox. I need to get the kernel configs doing the notick thing so qemu isn't eating CPU when idle. I need to install make on the target and the native builds. I need to redo the And I need to rename the project to "hermetic", although my current unicycle-shedding (I.E. bikeshedding with _myself_ because the stakes are too small to make a clear winner obvious) is whether I should call it just hermetic or "hermetic linux". (Or hermetic linux builder...) Anyway, much todo. But it's checkpointed, so I can go start tackling the kernel breakage in the newer versions, and... Sigh. Rob From rob at landley.net Sun Mar 18 16:35:44 2018 From: rob at landley.net (Rob Landley) Date: Sun, 18 Mar 2018 11:35:44 -0500 Subject: [mkroot] And my tags are crazy. In-Reply-To: References: Message-ID: <73a88865-9847-e4b3-9c97-7855b0d8f9c3@landley.net> On 03/17/2018 08:48 PM, Rob Landley wrote: > Arbitrarily numered, I haven't hooked up the native build plumbing yet so this > is about half of what I mean to do, so... Except I was testing in the "clean" directory, and when you locally clone it doesn't copy the tags because git, so I went "I didn't tag last version? huh" and picked a number. Right, I'm calling this 0.9.1, I'm going to push it to "hermetic" with the correct tag, and I'll turn the "mkroot" repo into an empty one with a README that says where it went. Juggling too many balls, as usual... Rob From alain at vocatus.pub Sun Mar 18 19:53:16 2018 From: alain at vocatus.pub (Alain Toussaint) Date: Sun, 18 Mar 2018 15:53:16 -0400 Subject: [mkroot] Tagged and pushed 0.5.0. In-Reply-To: References: Message-ID: <1521402796.8323.1.camel@vocatus.pub> > There are several more mcm-buildall.sh > architectures that don't finish building, and those don't work yet. Speaking about mcm-buildall.sh, have you tried building x32? I'll do a patch for the kernel config tonight. The rest built fine in my tests. Alain From rob at landley.net Sun Mar 18 20:34:10 2018 From: rob at landley.net (Rob Landley) Date: Sun, 18 Mar 2018 15:34:10 -0500 Subject: [mkroot] Tagged and pushed 0.5.0. In-Reply-To: <1521402796.8323.1.camel@vocatus.pub> References: <1521402796.8323.1.camel@vocatus.pub> Message-ID: On 03/18/2018 02:53 PM, Alain Toussaint wrote: > >> There are several more mcm-buildall.sh >> architectures that don't finish building, and those don't work yet. > > Speaking about mcm-buildall.sh, have you tried building x32? Yes I did. I couldn't get userspace to run, but I should try it in a chroot under x86-64 with the extra stuff switched on. I wanted to get a checkpoint release out before opening the can of worms of changing the shortname/fullname toolchain mapping (because x32 isn't an x32-blah-cross prefix, the toolchain name is x86_64-blahx32-cross so either it needs to be renamed when it's built or it needs an explicit short name. I'm leaning towards the latter.) > I'll do a patch for the kernel config tonight. The rest built fine in my tests. Let me know if you can get it to run, my first stab at it didn't but I spent like 10 minutes... Thanks, Rob From scsijon at lamiaworks.com.au Sun Mar 18 21:28:28 2018 From: scsijon at lamiaworks.com.au (scsijon) Date: Mon, 19 Mar 2018 08:28:28 +1100 Subject: [mkroot] hermatic In-Reply-To: References: Message-ID: /cut > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sat, 17 Mar 2018 20:48:01 -0500 > From: Rob Landley > To: mkroot at lists.landley.net > Subject: [mkroot] Tagged and pushed 0.5.0. > Message-ID: > Content-Type: text/plain; charset=utf-8 > > Arbitrarily numered, I haven't hooked up the native build plumbing yet so this > is about half of what I mean to do, so... > > I'm looking at the Open Source Summit Japan CFP which closes tomorrow: > https://linuxfoundation.smapply.io/prog/open_source_summit_japan_2018/ > > And wondering if I can get the rest of the LFS native plumbing in place in time > to give a talk about it there. I suppose I can submit the talk and see if it's > accepted, and then do the work if they say yes. :) > > I tested the following architectures under qemu 2.11.0: > > aarch64 mips x86_64 armv5l i486 s390x armv7l i686 mipsel powerpc sh4 > > And they all booted and ran, although sh4 is a bit broken (serial UART buffer > doesn't generate an interrupt unless it's full so you only get input you type in > blocks of 16 characters, there's no battery backed up clock, and the emulated > board only has 64 megs of ram). There are several more mcm-buildall.sh > architectures that don't finish building, and those don't work yet. > > I need to replace the rest of busybox with toybox. I need to get the kernel > configs doing the notick thing so qemu isn't eating CPU when idle. I need to > install make on the target and the native builds. I need to redo the > > And I need to rename the project to "hermetic", although my current > unicycle-shedding (I.E. bikeshedding with _myself_ because the stakes are too > small to make a clear winner obvious) is whether I should call it just hermetic > or "hermetic linux". (Or hermetic linux builder...) One vote for "hermatic linux", hermatic, by itself, is too close to hermetic for the trademarks and copywrite people to allow, and Hermetic GmbH has a world registration on their name. Trust me, you DON'T want to get on Trademarks and Copywrite Registration's bad side! scsijon > > Anyway, much todo. But it's checkpointed, so I can go start tackling the kernel > breakage in the newer versions, and... Sigh. > > Rob > > /cut From rob at landley.net Mon Mar 19 00:23:18 2018 From: rob at landley.net (Rob Landley) Date: Sun, 18 Mar 2018 19:23:18 -0500 Subject: [mkroot] hermatic In-Reply-To: References: Message-ID: <3595d491-dec2-a731-6ce4-04a7fc7093fb@landley.net> On 03/18/2018 04:28 PM, scsijon wrote: > /cut >> >> >> ---------------------------------------------------------------------- >> >> Message: 1 >> Date: Sat, 17 Mar 2018 20:48:01 -0500 >> From: Rob Landley >> To: mkroot at lists.landley.net >> Subject: [mkroot] Tagged and pushed 0.5.0. >> Message-ID: >> Content-Type: text/plain; charset=utf-8 >> >> Arbitrarily numered, I haven't hooked up the native build plumbing yet so this >> is about half of what I mean to do, so... >> >> I'm looking at the Open Source Summit Japan CFP which closes tomorrow: >> https://linuxfoundation.smapply.io/prog/open_source_summit_japan_2018/ >> >> And wondering if I can get the rest of the LFS native plumbing in place in time >> to give a talk about it there. I suppose I can submit the talk and see if it's >> accepted, and then do the work if they say yes. :) >> >> I tested the following architectures under qemu 2.11.0: >> >> ? aarch64 mips x86_64 armv5l i486 s390x armv7l i686 mipsel powerpc sh4 >> >> And they all booted and ran, although sh4 is a bit broken (serial UART buffer >> doesn't generate an interrupt unless it's full so you only get input you type in >> blocks of 16 characters, there's no battery backed up clock, and the emulated >> board only has 64 megs of ram). There are several more mcm-buildall.sh >> architectures that don't finish building, and those don't work yet. >> >> I need to replace the rest of busybox with toybox. I need to get the kernel >> configs doing the notick thing so qemu isn't eating CPU when idle. I need to >> install make on the target and the native builds. I need to redo the >> >> And I need to rename the project to "hermetic", although my current >> unicycle-shedding (I.E. bikeshedding with _myself_ because the stakes are too >> small to make a clear winner obvious) is whether I should call it just hermetic >> or "hermetic linux". (Or hermetic linux builder...) > > One vote for "hermatic linux", I'm not making up a spelling, no. > hermatic, by itself, is too close to hermetic for > the trademarks and copywrite people to allow,> and Hermetic GmbH has a world > registration on their name. Trust me, you DON'T want to get on Trademarks and > Copywrite Registration's bad side! Trademarks have categories. Richard Garriot's computer game "Ultima II" didn't stop a lipstick manufacturer from producing "Ultima II" lipstick a few years later. I don't intend to ever make pumping equipment, and if I did obviously I wouldn't call it something somebody who did was already using, so this wasn't an issue. Wasn't, past tense. Thank you for doing the trademark equivalent of attempting to make infringement willful by pointing out every patent I'm violating to triple the damages. http://lkml.iu.edu/hypermail/linux/kernel/0208.1/0768.html I'd never heard of this company before and honestly could say that, but now you've gone "ooh, your name puts 3 consecutive letters together and somebody somewhere uses that as an acronym, let me make sure if they google their own full name including the legal entity type, this message comes up talking about their need to defend their trademarks!" You think there's a dictionary word that ISN'T trademarked out there? Anywhere? Trademarks having rigid limits which is why Cory Doctorow could do http://locusmag.com/2012/05/cory-doctorow-a-prose-by-any-other-name/ . The Alamo Drafthouse in Austin had a live comedy troupe called "mister sinus theatre" for over 10 years, doing commentary over movies, until an idiot laywer ASKED BEST BRAINS if they had an objection to the name (trying to clear the way to put out recordings of the comedy that you'd play along with the movie, ala rifftrax a few years later) and the best brains laywers aid "well we WERE ignoring you, but now that you've forcibly brought it to our attention and started the clock on potentially losing the trademark if we don't defend it, no we can't allow you to use it anymore" and the drafthouse made them change their name and they're "master pancake theatre" now. After 10 years of it being OK, because some idiot aggro'd a lawyer. https://www.bizjournals.com/austin/stories/2004/08/30/daily16.html I WAS NOT ASKING FOR LEGAL ADVICE FROM A NON-LAWYER. If that company's lawyers google the company's full legal name, now they find your message saying they need to defend their trademark. Thank you EVER SO MUCH. I wasn't looking to pick a fight, but now using that name WOULD be picking a fight. And now any other name I choose, anyone can assume I did a full trademark search on it when the whole POINT is not to (Linus's policy) and... Ugh. You know what? I've lost interest in this project now. I don't care what it's called. I'll let you know if I start caring again, but it seems unlikely. I'm just going to build my own systems in my own my little corner and not publish any of it to anyone else so they CAN'T MAKE THIS KIND OF PROBLEM FOR ME. Rob From rob at landley.net Mon Mar 19 01:16:16 2018 From: rob at landley.net (Rob Landley) Date: Sun, 18 Mar 2018 20:16:16 -0500 Subject: [mkroot] hermatic In-Reply-To: <3595d491-dec2-a731-6ce4-04a7fc7093fb@landley.net> References: <3595d491-dec2-a731-6ce4-04a7fc7093fb@landley.net> Message-ID: <324255ab-25af-656f-829f-bde884e5dec3@landley.net> On 03/18/2018 07:23 PM, Rob Landley wrote: > You know what? I've lost interest in this project now. I don't care what it's > called. I'll let you know if I start caring again, but it seems unlikely. I'm > just going to build my own systems in my own my little corner and not publish > any of it to anyone else so they CAN'T MAKE THIS KIND OF PROBLEM FOR ME. I have been reminded that I've probably caught Fade's cold, and maybe should not be making project direction decisions right now. But a non-lawyer giving legal advice to a guy who won't merge MIT licensed code into toybox because of license compatibility issues, who walked away from busybox maintainership because fighting Bruce reminded him too much of fighting SCO and just took all the fun out of it, and who has collected links like https://www.bell-labs.com/usr/dmr/www/otherunix.html for years? An australian giving a US citizen advice about german (EU) trademark law. It made me very, very tired. And headachey. And I'm going to step away from the keyboard now. Rob From christopher.r.barry at gmail.com Mon Mar 19 03:12:55 2018 From: christopher.r.barry at gmail.com (Christopher Barry) Date: Mon, 19 Mar 2018 03:12:55 +0000 Subject: [mkroot] Hermetic and possible trademark issue... Message-ID: How about Hermes Linux? It is from him and his alchemy that the word originates. Plus, 'alchemy' is really what you're doing... :-D -C -------------- next part -------------- An HTML attachment was scrubbed... URL: From alain at vocatus.pub Mon Mar 19 03:56:46 2018 From: alain at vocatus.pub (Alain Toussaint) Date: Sun, 18 Mar 2018 23:56:46 -0400 Subject: [mkroot] hermatic In-Reply-To: <324255ab-25af-656f-829f-bde884e5dec3@landley.net> References: <3595d491-dec2-a731-6ce4-04a7fc7093fb@landley.net> <324255ab-25af-656f-829f-bde884e5dec3@landley.net> Message-ID: <1521431806.8323.3.camel@vocatus.pub> Guys, pardon me if I top post. Rob, When I registered for Vocatus, I asked a trademark lawyer about the name (Vocatus in latin == Alcohol in English or Alcool in French). Such a name, isn't trademarkable in French Canada or English Canada. I don't know about USA but any names which are direct translation of other languages (such as latin == French or latin == English) are not trademarkable (if that is a word). Check for USA. Alain Le dimanche 18 mars 2018 ? 20:16 -0500, Rob Landley a ?crit?: > On 03/18/2018 07:23 PM, Rob Landley wrote: > > You know what? I've lost interest in this project now. I don't care what it's > > called. I'll let you know if I start caring again, but it seems unlikely. I'm > > just going to build my own systems in my own my little corner and not publish > > any of it to anyone else so they CAN'T MAKE THIS KIND OF PROBLEM FOR ME. > > I have been reminded that I've probably caught Fade's cold, and maybe should not > be making project direction decisions right now. > > But a non-lawyer giving legal advice to a guy who won't merge MIT licensed code > into toybox because of license compatibility issues, who walked away from > busybox maintainership because fighting Bruce reminded him too much of fighting > SCO and just took all the fun out of it, and who has collected links like > https://www.bell-labs.com/usr/dmr/www/otherunix.html for years? An australian > giving a US citizen advice about german (EU) trademark law. > > It made me very, very tired. And headachey. And I'm going to step away from the > keyboard now. > > Rob > _______________________________________________ > mkroot mailing list > mkroot at lists.landley.net > http://lists.landley.net/listinfo.cgi/mkroot-landley.net From scsijon at lamiaworks.com.au Mon Mar 19 05:35:51 2018 From: scsijon at lamiaworks.com.au (scsijon) Date: Mon, 19 Mar 2018 16:35:51 +1100 Subject: [mkroot] hermatic In-Reply-To: <1521431806.8323.3.camel@vocatus.pub> References: <3595d491-dec2-a731-6ce4-04a7fc7093fb@landley.net> <324255ab-25af-656f-829f-bde884e5dec3@landley.net> <1521431806.8323.3.camel@vocatus.pub> Message-ID: <6577406b-8962-a98a-30a0-fb31f6338801@lamiaworks.com.au> top posting also. And the only reason I popped into it to start with, was because I was contacted some 10 - 12 years ago from an American Trademarks Lawyer asking for permission to create and use llamaworks for a client expanding into the USA from South America. Written permission was needed because it was vocally close to mine (lamiaworks) and therefore could be confused even though the product was different, (llama wool processing va Leadlight Pannel Cartooning (drawings)). And I thought the origonal post was asking for opinions on which of the three sugestions should be considered the better so I was sending what I thought an answer with a reason why. And here is where I will end this topic as far as i'm concerned. scsijon On 03/19/2018 02:56 PM, Alain Toussaint wrote: > Guys, pardon me if I top post. > > Rob, When I registered for Vocatus, I asked a trademark lawyer about the name (Vocatus in latin == > Alcohol in English or Alcool in French). Such a name, isn't trademarkable in French Canada or > English Canada. > > I don't know about USA but any names which are direct translation of other languages (such as latin > == French or latin == English) are not trademarkable (if that is a word). > > Check for USA. > > Alain > > > Le dimanche 18 mars 2018 ? 20:16 -0500, Rob Landley a ?crit : >> On 03/18/2018 07:23 PM, Rob Landley wrote: >>> You know what? I've lost interest in this project now. I don't care what it's >>> called. I'll let you know if I start caring again, but it seems unlikely. I'm >>> just going to build my own systems in my own my little corner and not publish >>> any of it to anyone else so they CAN'T MAKE THIS KIND OF PROBLEM FOR ME. >> >> I have been reminded that I've probably caught Fade's cold, and maybe should not >> be making project direction decisions right now. >> >> But a non-lawyer giving legal advice to a guy who won't merge MIT licensed code >> into toybox because of license compatibility issues, who walked away from >> busybox maintainership because fighting Bruce reminded him too much of fighting >> SCO and just took all the fun out of it, and who has collected links like >> https://www.bell-labs.com/usr/dmr/www/otherunix.html for years? An australian >> giving a US citizen advice about german (EU) trademark law. >> >> It made me very, very tired. And headachey. And I'm going to step away from the >> keyboard now. >> >> Rob >> _______________________________________________ >> mkroot mailing list >> mkroot at lists.landley.net >> http://lists.landley.net/listinfo.cgi/mkroot-landley.net From onefang at gmail.com Mon Mar 19 05:51:36 2018 From: onefang at gmail.com (David Seikel) Date: Mon, 19 Mar 2018 15:51:36 +1000 Subject: [mkroot] hermatic In-Reply-To: <6577406b-8962-a98a-30a0-fb31f6338801@lamiaworks.com.au> References: <3595d491-dec2-a731-6ce4-04a7fc7093fb@landley.net> <324255ab-25af-656f-829f-bde884e5dec3@landley.net> <1521431806.8323.3.camel@vocatus.pub> <6577406b-8962-a98a-30a0-fb31f6338801@lamiaworks.com.au> Message-ID: <20180319155136.51fcb909.onefang@gmail.com> I seem to be missing Robs actual posts to this thread, only seeing them in other peoples replies. So I might have missed other stuff. Um, roll a dice to pick the name if there's no clear winner. Or just leave it at mkroot if it's too much trouble to change. Or maybe Air Lock Linux, so I can change the name of the folder this is in from FWL to ALL, and better represent it's actual contents (ALL of Robs OS building tools). Get well soon Rob. -- A big old stinking pile of genius that no one wants coz there are too many silver coated monkeys in the world. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 181 bytes Desc: OpenPGP digital signature URL: From contact at carldong.me Thu Mar 22 16:23:25 2018 From: contact at carldong.me (Carl Dong) Date: Thu, 22 Mar 2018 12:23:25 -0400 Subject: [mkroot] Project location? Message-ID: Hey all, Perhaps I missed something but I can no longer find the project? Not even under: https://github.com/landley I know there was talk of some rename... Has the repo been moved? ?Cheers, Carl Dong contact at carldong.me "I fight for the users"? From rob at landley.net Sun Mar 25 21:34:28 2018 From: rob at landley.net (Rob Landley) Date: Sun, 25 Mar 2018 16:34:28 -0500 Subject: [mkroot] mkroot went missing? In-Reply-To: References: Message-ID: On 03/25/2018 01:00 PM, Buck Evan wrote:> On Mar 25, 2018 9:16 AM, "Rob Landley" > wrote: > > On 03/24/2018 05:41 PM, Buck Evan wrote: > > I was going to dig into your project today, for my own edification, but I > got a > > 404. Is this a GitHub error, or are you renaming it, or something else? > > > > https://github.com/landley/mkroot > > I ended it as a separate project because somebody who wasn't a lawyer tried to > be, and caused me legal problems I don't feel like dealing with. > > http://lists.landley.net/pipermail/mkroot-landley.net/2018-March/000093.html > > > The last version of the repository is available at: > > https://landley.net/mkroot.tar.gz > > Rob > > I saw that. I'm sorry you got fed up, and I hope that you feel differently > when/if you recover from your cold :) > > Do you mind if I show the list this conversation? They're asking too. Sure, I'll cc them here. I'm not trying to hide it, I'm just... tired. I just got https://landley.net/notes.html caught up to the start of November, so who knows when it'll see the light of day, but here's what I wrote in the local file for Friday. Rob March 23 End of the "sprint" at work, meaning deadlines. I worked extra hours to catch up from monday (contractor, paid for hours not accomplishments, no vacation or sick days; can't complain because the hourly rate's pretty good). So I've gotten very little open source stuff done this week. Friday: time to catch up on open source stuff! Starting with design work. After the mess on the mkroot list, renaming the project "hermetic" would be gratuitously picking a fight with a large corporation. But _not_ doing so would be backing down from my legal rights in the face of shadows that _might_ turn into empty threats that _might_ turn into a battle I could almost certainly win. So I took the project down, because I don't like either option. Now it doesn't matter what it's called, and armchair lawyers can't empty chamberpots over it again. I gave it a week to stew, and it turns out somebody did notice it was down. I should send him a tarball. (As with busybox, the work I did is out there open source, I'm just not continuing it as a separate project that would need a name. Yes, there are still scars from SCO and bruce. Work is assigning me to work on systemd configuration, my "this is not fun" bandwidth is accounted for these days, thanks. My open source work is either because I enjoy playing with it or because I'm trying to accomplish something specific.) There were two near-term use cases for mkroot: 1) better toybox test suite, 2) natively compiling stuff. Making the second work without plugging the gaps with busybox is significantly more work than the first, but the biggest single blocker to either is the lack fo toysh. Then again I don't need every toysh corner case to get something that can run the init script and toybox's scripts/test.sh and so on... Ok, if I'm going to merge a subset of mkroot.sh into toybox as scripts/mkroot.sh or similar, I should merge the modules/kernel and modules/native scripts into the main file (those are the only part that can't build natively under qemu with some control-image plumbing, even the dynamic libraries can be added by rebuilding libc natively). I no longer need it arbitrarily third-party extensible if it's not going to be its own project. I also need to rip out the busybox build. (I've kept an air gap between toybox and busybox ever since I stopped maintaining busybox, originally because of Bruce contamination, then because license. I've contributed things like toybox patch _to_ busybox, but nothing comes back the other way except bug reports.) Ripping busybox out of mkroot leaves a largeish hole, although all of those commands are also in "make install_airlock" so it's part of an existing todo list. That said, I can't bring networking up without a "route" command (toybox's is in pending), and it really needs a command shell to run (which can handle the init script). The rest is there for native builds (wget and tar most obviously). There are two near-term use cases: 1) better toybox test suite, 2) natively compiling stuff. Making the second work without busybox is significantly more work, but the biggest blocker to both is really the lack fo toysh.