Plans Going Forward

[perkinslr]

Thank you Sakaki for your long service and amazing "stuff"! Also thank you for not simply vanishing into the night. Too often these sorts of projects die when the original author or principal maintainer leaves because they leave silently, and by the time anyone realises there is a problem, it's impossible to pick up the pieces.

In light of Sakaki's announcement that he can no longer maintain, or even contribute, to open source projects, it falls to us, as the community of users of gentoo-on-rpi-64bit to figure out how to move forward. As someone who uses gentoo on several raspberry Pis professionally, I have no plans to change that. I am sure there are others with the will to see this continue.

There are several considerations moving forward.

First, and most importantly, we need to respect Sakaki's decision to move on, and not do anything to imperil her new career move. If she can transfer the current repository to a new github organization, that'd be a nice surprise, but we should proceed under the assumption that she must maintain radio silence and can't help in any way. I've been through this before with other projects, it's not the end of the world. The biggest pain point is losing the open issues (there are 46 of them), but since the current repository will likely get archived, they'll be available for reference.

Second is community organization and leadership. I've created a discord channel ( https://discord.gg/Eu5D2e5KJQ ) to discuss any issues that arise. I have also taken the liberty of creating an organization here on GitHub, under the ownership of my L.L.C. https://github.com/GenPi64
I do not want this to become my personal project, but there is a bit of urgency in getting something visible up before people wander off and give up. At a minimum, I want two other, known community members who can take an active role in administration of the project. This should help with any personnel issues, and helps if I fail the "autobus test" at some point in the future.

Third is building packages for the binpkg mirror. I have a 16 thread Ryzen machine, and probably can borrow time on two more, already set up with a cross build environment for the Pi (I have several packages customized relative to the stock version). I'm not sure what to do to establish trust, since reproducible builds are not quite there yet in gentoo, but that's something to discuss within the new project.

Fourth is hosting the binpkg server. I have a scratch VM that I can devote to running the package mirror, but it's got pretty low bandwidth and data transfer limits. I don't know how popular this project is, but I think it may exceed what I can provide. We may be able to finagle some space somewhere, but again, we can discuss that elsewhere.

Anyway, I think that's all for now. If you are interested in helping out, come over to discord. I'll also post a message in the Raspberry Pi forum thread. Speaking of which, we'll need to decide if we want to continue the current 22 page forum thread, or start a new one. I don't see a reason to start a new one, but I'm open to convincing.

[perkinslr]

Oh, issue number 5: I have a pi4b, and a pi3b, but if we want to continue to support any other hardware targets (pi4 compute module, pi3, et cetera), we'll need to find people who are willing to test major updates using them.

[samip5]

I think we need to check what would be needed to get the minimal image in a state where it's a lot more like a normal Gentoo ARM64, and not Sakaki specifc version.

I know that sam_c at Freenode (#gentoo-arm) channel is working on getting a working flashable image done for ARM64.

[r7l]

Ya, i can second that request for a less special version of Gentoo. While i am greatful for all the efforts being done here, it would be great to have a less specific version of Gentoo for ARM64 and Raspberry PIs. The downside of all these special ebuilds and customizations are very visible right now. The entire project is shut down and taking it over is a huge amount of work in order to keep up all these included projects.

[necrose99]

I've been moving Forward with Pentoo Linux Plans , slowly for last while ..

even to buy an arm64 Workstation 80 cores NVidia rtx 2070 , etc as a home build server .. https://www.avantek.co.uk/ampere-emag-arm-workstation/ The EOL has most Certainly Thrown in A monkey Wrench as before I only needed to custom rebuild Some packages. and add on pentoo into image.

https://github.com/arm64-gentoo-images

I've added sakaki-'s repos and made an ORG as to make easier to add users Devs etc to repo , and or add similar projects specs etc into a one roof area. and or mirrors , documentation etc , and or places for Wiki Writing under an easy to find org. I'm an enthusiast , Sec-ops Researcher. anyrate much easier to Divide and conquer to multiple contributors than fragment the project over dozens/&/dozens of forks

unfortunately i'm not even sure if being a armchair-Architect of this project via hints tips or being only a mere commentator is even permissible for @sakaki- ,

[tiborh]

Unfortunately, this EOL came too soon for me not to make me abandon the Gentoo or rpi project. (returning to Manjaro and Mate) But it gave me the strength to start installing Gentoo on an old Dell laptop (in place of previous Ubuntu, Manjaro, and Fedora experiments). I'm afraid I would not be too much help in the new gentoo on rpi project, but if there is a new place for it, I intend to follow it and see if there is a point where I will have picked up enough knowledge on the x86 track so that I can join meaningfully. Good luck to all of those who persist on this project. It is well worth it. Finally, thanks to @sakaki- to jumpstarting this project. Good luck to her in her "real life work"! And thanks to all those who helped when I got stuck.

[omkhar]

Sorry if this has already been covered elsewhere, but did we get the build scripts? I might be willing to donate some build time / participate in distro design.

--oa

On Nov 21, 2020, at 16:59, Tibor Harcsa notifications@github.com wrote:

 Unfortunately, this EOL came too soon for me not to make me abandon the Gentoo or rpi project. (returning to Manjaro and Mate) But it gave me the strength to start installing Gentoo on an old Dell laptop (in place of previous Ubuntu, Manjaro, and Fedora experiments). I'm afraid I would not be too much help in the new gentoo on rpi project, but if there is a new place for it, I intend to follow it and see if there is a point where I have picked up enough knowledge on the x86 track so that I can join meaningfully. Good luck to all of those who persist on this project. It is well worth it. Finally, thanks to @sakaki- to jumpstarting this project. Good luck to her in her "real life work"!

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[necrose99]

@omkhar https://github.com/arm64-gentoo-images

i've added sakkaki's items and a few similar items....

i made an org to add devs/ users to further the works..

[samip5]

@omkhar https://github.com/arm64-gentoo-images

i've added sakkaki's items and a few similar items....

i made an org to add devs/ users to further the works..

There is currently two orgs. https://github.com/GenPi64 and that one.

[perkinslr]

@omkhar https://github.com/arm64-gentoo-images i've added sakkaki's items and a few similar items.... i made an org to add devs/ users to further the works..

There is currently two orgs. https://github.com/GenPi64 and that one.

We may want to consolidate them, or we may want to keep them distinct. My plans with GenPi64 is specifically to target the Raspberry Pi ecosystem, while the org name (and contained repository forks) implies arm64-gentoo-images throws a wider net (chromebooks, new apple machines, tablets, loads of other "arm64" things would fit under that umbrella).

In any case, we should try to avoid duplicating effort.

To the best of my knowledge, we did not get any buildscripts, nor any details on how they worked. I don't know if they started from an aarch64 stage3, or started by building the stage1 via crossdev. I am working on a stage3+qemu-user-static grs-based build script, which will be fairly inefficient, but I have a powerful machine that is otherwise currently idle.

[necrose99]

@perkinslr I was using the rpi4 , also , ive also used rock64pro and if the pine team offers 8 gigs on pinebookpro soonish might be of use .. what's the difference ... other than adding panfrost to messa , and boot order not much.

sakkis current binhost just works. however this will need a replacement.

other than trying to leverage some of sabayon linux CI-DI tech , and or thier new pm luet and docker ci ... not much.. @mudler who has taken over Sabayon Linux , wrote most of the docker tool chains. etc.

@MottainaiCI @mocaccinoOS which is @sabayon 's new test bed os i'm not a devops guy but seeing as a secops engineer "seeing the power of the darkside..." which devops can give and the fact its better than me bangig emerge foo libreoffice etc.. all day every day..

I was adding some generic dockers experiments to ie give options to build packages on a thread ripper or etc. fchroot from funtoo is exceptionally useful ...

the fact that other than cpu's are much the same as for compiles , vc4 just add mali / panfrost in vola.. add vulkan etc , as new vulkan+rpi4 gpu drivers are nearing stable.

other than tinkering with an Gentoo add PENTOO flavor ... Base + Pentoo Pentesting packages..

perhaps a Funtoo flavor ( sabayon/Funtoo while maintaining public branding are merging on other so having packages and tool chains are not lost on me. they'd have bins and a binpkg manger and more devs to share upon.

other than tinkering with a test boot iso for Gentoo arm64 , https://www.asacomputers.com/Cavium-ThunderX.html https://www.anandtech.com/show/15733/ampere-emag-system-a-32core-arm64-workstation packaging nvidia geforce / and radeon arm64 drivers ...
Hello my pretty ... with that many arm64 cores a shared binhost
unfortunately this wont be my stalking stuffer , but likely my birthday gift. come feb .. 40 cores 128 gigs of ram SSD.. can fire up various chroot's for boards and or get docker images to build. packages for alike boards.

https://github.com/pftf/RPi4 this has a pc bios menu to pick.. IE grub2 or SSD .. etc.. network

https://stikonas.eu/wordpress/2019/09/15/blobless-boot-with-rockpro64/
https://github.com/necrose99/arm64-portage bit power user ish however just some packages to rebuild were taking quite some time.

https://github.com/Jannik2099/gentoo-pinebookpro/blob/master/prepare.sh this could be moddified with a menu

1) device , device 3 ... etc ie RPI4 / Pinebook pro , rock64 pro .. etc.. GPT uefi/grub etc..

a few packages for rpi4 ie firmware for efi would need modified as to not clobber the RPi4 or RPi3 UEFI loaders . ie /boot//rpi then you'll need to manually move or add symlinks to /boot/efi and or some of the text files append as to not fuck up uefi loader.
however by SWitching to UEFI it would greatly Simplify images as you could make a usb installer image in time.. that would install on multiple systems or boards. or likewise support more boards.

Rock64pro /pinebook pro , 10 megs BIOS grub to embed their sbi loder images in some of the free space , which updates the boot rom sbi chip on board, with u boot which will do uefi by default. which makes for good pci-e-x4 and NAS storage , for putting rpi4 files upon. ie netboot if clustering (https://www.amazon.com/ASUS-M-2-X16-V2-Threadripper/dp/B07NQBQB6Z) a 4x m.2 card

Odroid also makes similar boards.

my aims way to replicate sakaki-'s quite successful binhost , and add trusted users to it. (binpkg-multi-instance) docker for single vanilla packages ie Base / muli as users submit with altered bin pkgs
add systemd , openrc , and overtime offer rpi4 and similar in architecture boards. which can just consume from same binhost.

one could add various repos. on binhost .. base /power user flavors..

Genric-arm64 , rather unoptimized , for users with rather to get up and running.. cortex-a72.cortex-a53 (Rpi3 / RPI4/rock64 & pineboo-pro ) other boards and systems as a dev cares too .. I'll add a repo vola..

in closing. gentoo has many fragmented arm64 aims , while my aims are similar , I figured why not an ORG for all under 1 roof and make easier to find ? board. (or at least mirrors to said boards) other than adding A Lot more packages , and similar to rpi4/3 boards in adjacent architectures ... ie pine64 boards other than gpu having stable binaries means less work. gentoo-bin-kernel , pentoo-binkernel-arm64 , and a more universal baked kernel for more than rpi4 , using grub /uefi https://github.com/git-ftp/git-ftp 740124 to use for user uploads and versoning to ftp server/https server , if only a few packages changed , then any downstream mirrors would only need mirror 5 new packages. and or if users are workspacing likewise. and or less cobbering of files.

other than adding a work space for more boards in future and the like while my aims are marginally broader than just rpi4 ie rock64 , and or a shinny home workstation/server to mash out packages for thus faster.. or a few added flavors...

if some cares to add more than RPi / Rock64 boards hense the org sure thing. I'll just add them to org vola. .

it might be worth merging as my focus is on rpi4 and alike boards , ie rebuild mesa with added GPU's... and use uefi and stock gentoo arm64 install + Binhost and or a menu installer. vola..

[samip5]

Is it just me or was that message by @necrose99 all over the place? Making understanding it quite difficult.

[necrose99]

bit tired prior , i'm trying to write up a far more plan and post it or set up collab etc ,
my adhd dyslexic/hide by video far easier to explain , however , i have had my tentacles in so many pies trying to setup binhost and migrate my arm64 pentoo package built on rpi4 ..
my brain parts move "super luminal" , other parts not at warp drive speeds .. ie typing

hence a more formalized draft/manifesto/mission statement and or mirroring to https://github.com/GenPi64 so i can slow down a touch and be bit more concise , ideas hit at Warp speed with no filter... , so 1st round draft , then revision etc. git a bit of Caffeine to sync the warp speed half to the regular joe half.. drill down on papers wiki etc. force my warp speed brain not to race with it million parallel cores .. and drop to total focus.

got my Tentacles in a lot myself <img src="https://user-images.githubusercontent.com/2396239/100137804-a37ce780-2e52-11eb-9853-4eb9266cd33d.png" alt="" width="145" height="140">

new job , new hire pprk work , 4 work required SIEM certification tests..

ad trying to help <<<shocking!!! clear !!! >>> <img src="https://media3.giphy.com/media/l2Jejt7O03eXaRQre/giphy.gif" alt="" width="159" height="179"> *try and help revive this project

as similar projects ie arm64-pentoo for rpi4 tend to depend on it , and or rock64-pro can re-use same binaries. other than rebuilding mesa and or a few add on's emerge.. vola'..

[omkhar]

hi Michael,

Thanks for offering your suggestions. I'm empathetic to your busy schedule and the challenges you've expressed. I'll ensure I'm sensitive to your communication style in future.

I think there's two related items here:

1. Architecture maintenance - There is effort required to ensure the packages build on Gentoo for this architecture, unmasking new packages etc. Based on how low power it is, this might require QA for cross-compile as well. It may also require maintenance of raspberry-pi specific packages (firmware, kernel-bin, etc).
2. Binary read Gentoo based distro - sakaki's original project was particularly interesting to me, as it provided a means of shooting optimized packages to a system that was notoriously underpowered with poor I/O.

While I haven't been an official gentoo-dev in over 15 years, I believe (1) is currently well handled (plmk if I have this wrong, perhaps we should address this as well). Is everyone focused on (2) or have I bifurcated concerns too far?

--oa

On Tue, Nov 24, 2020 at 2:26 PM Michael L. notifications@github.com wrote:

bit tired prior , i'm trying to write up a far more plan and post it or set up collab etc , my adhd dyslexic/hide by video far easier to explain , however , i have had my tentacles in so many pies trying to setup binhost and migrate my arm64 pentoo package built on rpi4 .. my brain parts move "super luminal" , other parts not at warp drive speeds .. ie typing

hence a more formalized draft/manifesto/mission statement and or mirroring to https://github.com/GenPi64 https://github.com/GenPi64 so i can slow down a touch and be bit more concise , ideas hit at Warp speed with no filter... , so 1st round draft , then revision etc. git a bit of Caffeine to sync the warp speed half to the regular joe half.. drill down on papers wiki etc. force my warp speed brain not to race with it million parallel cores .. and drop to total focus.

got my Tentacles in a lot myself https://user-images.githubusercontent.com/2396239/100137804-a37ce780-2e52-11eb-9853-4eb9266cd33d.png

new job , new hire pprk work , 4 work required SIEM certification tests..

ad trying to help <<<shocking!!! clear !!! >>>

https://camo.githubusercontent.com/c59596314ea8905571de54f21f4dcba77f9ca6d0dd62b19dd7fbcb6328b8102a/68747470733a2f2f6d65646961332e67697068792e636f6d2f6d656469612f6c324a656a74374f3033655861525172652f67697068792e676966 *try and help revive this project

as similar projects ie arm64-pentoo for rpi4 tend to depend on it , and or rock64-pro can re-use same binaries. other than rebuilding mesa and or a few add on's emerge.. vola'..

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/sakaki-/gentoo-on-rpi-64bit/issues/209#issuecomment-733185015, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFM52KQ6DZUZWFNBVZJNN4TSRQCGLANCNFSM4TFXY2ZQ .

[perkinslr]

@omkhar, I believe your two distinct items reasonably break the project in half.

(1) is actually in many ways the larger challenge, as it requires continual maintenance. It is handled by the genpi64-overlay project.
(2) is the more pressing concern. Generating and hosting the binpkgs is reasonably straightforward. In the worst case, you just take an existing Pi, set it to create packages, and then manually keep it up to date. As for hosting, several people have come forward with space to host the package system (I can probably pull some DNS magic to load balance between them too). The other half of (2), creating fresh disk destroyerable images is considerably more difficult, and is where my current effort lies. I want to have build scripts that anyone can run, both so that people whose security model precludes trusting me can still use the project (with their own build server), and so the project can easily continue if I someday fail the "autobus test". The build scripts, and the images generated go in the gentoo-on-rpi-64bit repository (in the .git and releases respectively).

As a (3), relatively minor issue, is the tooling for automating the client-end of (2). genup, showem, emtee and similar utilities are likely to need maintenance at some point in the future. For now they should "just work", so it's very much a future concern. At some point, the repository and overlays should probably get renamed from sakaki-tools, and like the overlay for (1), should probably be ripped apart and sent upstream as much as possible. (most of the tools would be useful for other low power systems, like old core2s or similar).

[necrose99]

@omkhar i had set up images-org and added few related repos however missed the first fork.

docker images to build packages and or "Stealing some bits" of Sabayon Linux Automation (a Gentoo binary fork) and trying to learn a bit of their CI/DI pipelines or eventually collaborate so their kubernetes/dockers etc do more heavy lifting. in time perhaps... they are also merging with Funtoo , so if I paid for funtoo container ... bit of pandering to devs .. or the ability to have builds in their pipelines as to take off some of the workloads... to CI/DI robots.
however looks like we got enough.. ppl to least divvy up workloads

https://github.com/mudler/luet new binary package manager wich uses docker layers and or manages binary gentoo packages. luet is but 1 example of his many golang tools which could make baking images has a few go toys to shove username and password to etc shadow , edits config files based on YML docker to tarball or lxc / lxd automation ... and or docker to tarball to rpi4 boot image... NOT DEVOPS, BUT it is COOL MAKES MY BRAIN ACHE thinking on them too much... but his toys would be of much use as ebuild validation or as gentoo git repo updates or overlay repos update build packages push to binhost automatically. build or fail via their concourse would be know in a few minutes. for devsecops i'm all to aware of the power ,

i'd like to lean just enough devops to help out *i'd like to lean just enough devops to not have to ssh and bang emerge ${somethings} all night every night

however merging the two efforts and or mirroring repos ie merge seems wise , I'm a Security Researcher , Sec engineer , and former Windows /Linux Infrastructure guy... i'm all for DIVIDE and Conquer (i'd like to lean just enough devops to build my security/pentesting tools )

however for Adjacent works and or more Experimental Images , Rock64pro other than say GPU , uses same cpu Architecture as far as GCC is concerned. and or pin repos useful for others doing the same to sbcs over a few years of research

IE RPI4 UEFI / Gentoo , will need to fix a few package build options rpi-firmware USE="efi" DO symlinks , do /boot/rpi user can set symlinks to /boot/efi , and filter files to not goto or append to efi.. as to not kill the uefi build ie use grub etc but add blobs as needed.. ie REAL time clock enable overlay blob etc..

aid in supporting the genpi64 build

Adjacent works : ie RPI ALike Boards , ie the aforementioned rock64pro and or pinebook Pro. or similar Reuse of binhost bins. work to add a profile to filter off RPi packages , add add required packages...

arm64/generic arm64-coretex... rpi3/4 rock64 add build mesa to be more SBC compatible. for rpi /etc. +panfrost +mali BASE shared USER repos ie users /power user features etc.. with ssh or sso ftp/git-ftp could upload packages via multi-instance binhost xpack to not clobber use .. this gives a variety of use cases and solves build power , users can contribute packages back to binhost. basically a "31 Flavors of Ice Cream" , ig packages with every flavoring commonly wanted or used.

BASE repo protected baseline packages.. power user shared repo , respins,,,

PENTOO arm64 repo , its Gentoo Security / Pentesting , main area of research. this requires Gentoo as is. however for tuning rpi4 into a Distributed Pentesting platform. .. fun.. or rpi4 sectest tablet https://raspad.com/ very roomie tablet case war driving or gnuradio car sec testing etc.

amrd64 test iso , mainly for server use.. debian makes an installer iso , however one premade for rebuilding an arm64 server if the WORST happens

however @OUCH 48 core servers going to hit hard on wallet LLC expense so write off $2685 + shipping , just using a rats nest of rpi4's plus MEOW is going to likely kill one of my lap loving house cats.. chewing on wires etc. they already broke the LCD right angle cable for the 8 inch vilrose case / lcd so hiding a pie cluster behind my 4k monitor is were they like to hide.. is not a great idea. and having a monster with 128 gigs of ram and nvidia rtx with arm64/cuda experimental rtx drivers should aid in build. , however for building packages I could likewise use DOCKER to help make repeatable builds for rpi4 etc on this server or sense git/gentoo or other repos

for larger packages ie LIBREOffice etc. this would take very little time .. it could chew on distro in record time for DAILY package updates

[necrose99]

@omkhar, I believe your two distinct items reasonably break the project in half.

(1) is actually in many ways the larger challenge, as it requires continual maintenance. It is handled by the genpi64-overlay project. (2) is the more pressing concern. Generating and hosting the binpkgs is reasonably straightforward. In the worst case, you just take an existing Pi, set it to create packages, and then manually keep it up to date. As for hosting, several people have come forward with space to host the package system (I can probably pull some DNS magic to load balance between them too). The other half of (2), creating fresh disk destroyerable images is considerably more difficult, and is where my current effort lies. I want to have build scripts that anyone can run, both so that people whose security model precludes trusting me can still use the project (with their own build server), and so the project can easily continue if I someday fail the "autobus test". The build scripts, and the images generated go in the gentoo-on-rpi-64bit repository (in the .git and releases respectively).

As a (3), relatively minor issue, is the tooling for automating the client-end of (2). genup, showem, emtee and similar utilities are likely to need maintenance at some point in the future. For now they should "just work", so it's very much a future concern. At some point, the repository and overlays should probably get renamed from sakaki-tools, and like the overlay for (1), should probably be ripped apart and sent upstream as much as possible. (most of the tools would be useful for other low power systems, like old core2s or similar).

@zerochaos- pentoo-updater could be merged with Genup and other scripts and > made one package of gentoo-up and shoved upstream pentoo-updater works much like genup , however genup has a few additional bonus features and switches ie -S to not sync like a auto-emger broke and dont need to rsync repos again yet. the auto-genup cron or systemd it Might be something to ask him if he'd consider. merging into @gentoo itself as a combined package . hover zc is often busy with @pentoo but if he merged to @gentoo genup, showem, emtee into 1 package to rule them all , maintenance could be shared from upstream. and used on every gentoo base. , and possibly 1 less irksome chore for zc to have to grind over in @pentoo .. every few updates as more than 1 dev-gentoo might have a hand in it .

sakaki's tools her repo is more general purpose not just arm64 , between @funtoo and @gentoo @sabayon etc. might be a place for some tools upstreaming ASAP..

[fabianmendes]

Hi, excuse me. Any news?

[necrose99]

Hi, excuse me. Any news?

https://github.com/genpi64