updated docker locale

[necrose99]

seems to be working other than emulation , might be able to adapt NeddySeagoon's AMD chroot builder to generic amd64 , for general use via docker. , as docker can be clustered, at use otion.. Dockerhub and quay.io builds the Base Image without to much issues. FS is melded. so even kernels could be likely be built on https://resin.io/ pi image /docker cluster... if you have a few spare pi's about..

[sakaki-]

Hi, I'm working on a new release of this image right now (with weekly autobuild backing for the kernel and binary package set); I'll be happy to take your pr (or tweaked variant thereof) for that, but can you please clean up the comments in there first (e.g. Dockerstuff/Redme.md) to retain only professional or technical commentary (no jokes etc) in as "vanilla" a style as possible. Unfortunately some people have a low tolerance threshold and will easily take offence (as I know from experience!). Thanks!

[necrose99]

np , i tried for a few analogies. as docker when it works it works, not... its a pest. getting emulation to run can be.. only bonus is that the image will re-wind to start. if however can update via make.conf bins on load. and also can be made to watch ie jenkins git... then spawn emerge --pkg... which can make for a weekly packages updater etc..

anyhow readme is (realy) rough draft... however , i can prune a few puns , granted it was aimed more at novices.. /low brow... , I'll chop the borg pun ,

but yes you can use a base docker image as your own , and add to it ... the base os image ie gentoo , etc. add nginx and drupal, add db , vol storage etc.

Russian DOLL /WEDDING cake was an Architectural Analogy and more of a visual... cue.... quick and simple.. was looking more for an expedient means, of docker 101...

, as you can have the de-facto gentoo base docker , and have docker a, b, c,d, (previous build steps) final-product.. From Scratch , then from Gentoo.... , etc. , and also they can test in a sandbox'd-chroot , systemd .. etc , were as under normal use case... may not be terribly healthy.. for the RPI3 image Yet..
i'm getting better at docker but not an expert. but for abusing as a chroot being squashfs takes less room not in use.

if you have a base-tarball of the fs i can tweak the dockerfile to pull the base fs..
so as it builds the docker image gets refreshed. as i can watch the symlinked file ... it's good system isolation , as the container can die/crash , yet not take your box with it.

anyhow if someone has docker , qemu , should be good ,
looking to tweak @snedyseagoon's for perhaps a more portable docker container , however needs generic amd64 insted of AMD-Phenom optimized.. and best yet less emulation requirements. for his cross-builder.. and albeit faster... chroot in a cage...

feel free to raid the add on packages in my [dropbox] (https://www.dropbox.com/sh/gfsfqv3p4lvnzi6/AAAE-Mb_8ko1oX3xSROVkP8ia?dl=0), SYSTEMD --WARNING..... needs udev recompiled, , libav is rather basic but good to go. the system can become unstable and brick the bootloader , and crash , before the re-compile is done.. also you could package pypy from debian and rust debs for bins via overlay.
pypy2 dumped from alien

[necrose99]

sure your welcome to edit away as the base doc is rough draft.

[sakaki-]

OK I will have a look at this when putting out the next (1.1.4) release.

[necrose99]

might have a fix for qemu , then again i can i'll have a few tets. https://github.com/mickael-guene/umeq-static-build/blob/master/bin/umeq-arm64 https://github.com/parazyd/qemu-wrapper https://github.com/multiarch/qemu-user-static/releases/download/v2.9.1/x86_64_qemu-aarch64-static.tar.gz

/*

• parazyd - (c) wtfpl 2016
• pass arguments to qemu binary */

include

include

int main(int argc, char argv, char envp) { char *newargv[argc + 3];

newargv[0] = argv[0];
newargv[1] = "-cpu";
newargv[2] = "cortex-a8"; /* here you can set the cpu you are building for */

memcpy(&newargv[3], &argv[1], sizeof(*argv) * (argc -1));
newargv[argc + 2] = NULL;
return execve("/umeq-arm64", newargv, envp);

}

[necrose99]

necrose99 gentoo-arm64 # mv qemu-wrapper qemu-wrapper-umeq necrose99 gentoo-arm64 # rm x86_64_qemu-aarch64-static.tar.gz necrose99 gentoo-arm64 # leafpad qemu*.c necrose99 gentoo-arm64 # gcc -static qemu-wrapper.c -Os -s -o qemu-wrapper necrose99 gentoo-arm64 # ./qemu-wrapper necrose99 gentoo-arm64 # ./qemu-wrapper && chroot /home/gentoo-arm64 /bin/bash necrose99 gentoo-arm64 # uname -a Linux necrose99 4.12.0-sabayon #1 SMP Sun Sep 24 07:34:35 UTC 2017 x86_64 Intel(R) Core(TM) i7-2630QM CPU @ 2.00GHz GenuineIntel GNU/Linux necrose99 gentoo-arm64 # ./qemu-wrapper necrose99 gentoo-arm64 # chroot /home/gentoo-arm64 /bin/bash necrose99 / # unmae -a bash: unmae: command not found necrose99 / # uname -a Linux necrose99 4.12.0-sabayon #1 SMP Sun Sep 24 07:34:35 UTC 2017 aarch64 GNU/Linux necrose99 / # emerge -webrsync ** ERROR:/var/tmp/portage/app-emulation/qemu-9999/work/qemu-9999/target/arm/translate-a64.c:1038:write_vec_element: code should not be reached

nuts...

[necrose99]

need to squash my commits but i trimmed down a few things.

[sakaki-]

Why not create a small project with just these files (Dockerfile, Dockerstuff/...) and then I can add a link to it in the README (and also add a Docker.readme file or similar in the top level project directory, with a note about your project and the URL to it)... that way you can easily keep it up to date, and make changes, without PRs and so forth?

[sakaki-]

I have linked to your project now in the readme (commit 9d79ec218ebbac7cf29b06dc6c85780e011a5ed3); easiest if you maintain this on your fork, it is changing too rapidly.

[necrose99]

I'm going to Burn my fork , and Hard reset soon ,, and restore from zip... should make less commit spam. git --rebase hard reset to main repo... https://github.com/sakaki-/gentoo-on-rpi3-64bit add new files back.. one nice clean commit.

https://resin.io/blog/building-arm-containers-on-any-x86-machine-even-dockerhub/ works well on arm7hf , however the wall of fubars with arm64 ..

https://quay.io/repository/necrose99/sakaki-distcc/build/4410b976-355f-4390-898a-1dcb5298bf4f the wall of fails .... try , fail warmer , colder hotter.... also has made for commit squash a pest.

trying to Simply the docker build zeroconf , been fiddling with in aws. today ... can drop -introspection etc to get a few deps down as well going to have to use the docker fork A, B, C, D to prep ,

however if I robbed Sabayon's its ready and uses bins , add crossdev , is the other option ...

also easier but some the Purist gentoo devs might also frown... however its maintenance is albeit easier with equo and faster with bins.

and emerge packages since base layout is far faster.

end of the day a crossdev distcc in a cage , zeroconf/ahvi with few deps should let users automatically detect and abuse. pull to local or pull to a cluster.

https://github.com/japaric/cross/files/1967779/cross-0.1.14-dev.ebuild.txt , a rust crosser akin to golang gox... by the look of it. might prove usefull

genup at times i wish genkernel or genkerenel-next ie via use could add shims... pentoo on the rpi3. USE! , if add shim scripts.. else wala..

https://github.com/sakaki-/gentoo-on-rpi3-64bit/pull/15#issuecomment-386158248

https://www.npmjs.com/package/undocker https://github.com/larsks/undocker <-- @mudler was using this for a time. '( https://github.com/mudler/docker-sabayon-spinbase-amd64 )' some Linux distro's are using this to dump a chroot tarball dev-ops etc , to build choot to iso more quickly as most bins are kept built and concurent with git. , when dumped fewer updates , and faster iso squashfs builds.

https://github.com/PagerDuty/Nut https://github.com/deimosfr/lxc-convert

https://gpo.zugaina.org/sys-kernel/armv8multi-sources https://github.com/ksa242/gentoo-cubieboard-overlay simular to rpi akin to orange pi https://github.com/psychedup/gentoo-pine64 and ROCK64 UBOOT /EFI and GRUB2 , very similar to RPI , just video cards and boot differs.
oh and 4k-HDMI ... 4 gigs of ram , so for distcc hosts... other than mask profile arm64-pine (block packagers rpi3 spec) & likewise 90-95% of the rpi3 package will run on Pine64/Rock64-Gentoo-image

[necrose99]

some of the toys I could add to readme.

[necrose99]

Fork Torched and Reborn , Made HX-branch , made testing , copied files Back to Master. should keep commits in master down to a min....

Anyrate these are examples , sooner or later they will build on any Machine ie mkdir arm64-packages docker mount to /usr/portage/package (VM-in-docker) open new x11term tab launch docker run emerge foo , wala packages out... or even Chron job this.

(symlink to /usr/portage/packages @ packages-arm64 ) docker run -v /host/arm64-packages:/container/packages-arm64 -other -privileged image_name emerge pypy or pypy3 RPI sadly has not the juice... 2.5 --lowmem hack , or 3-4 gigs...

converting you image to run Systemd , while you can build in local RPI , the boot Init will Go belly up.. hence why I was trying to dockerize some builds to drop packages to localhost to put on rpi3 kernel compiles also take upto 25 hours , YIKES...