Plans Going Forward #209
Comments
|
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. |
|
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. |
|
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. |
|
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://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 , unfortunately i'm not even sure if being a armchair-Architect of this project via hints tips or being only a mere commentator |
|
Unfortunately, this EOL came too soon for me not to make me abandon the Gentoo or rpi project. (returning to Manjaro and Mate) |
|
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 ***@***.***> 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.
|
|
@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 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. |
|
@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 .. 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 ... @MottainaiCI @mocaccinoOS which is @Sabayon 's new test bed os 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.. other than tinkering with an Gentoo 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://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/Jannik2099/gentoo-pinebookpro/blob/master/prepare.sh this could be moddified with a menu
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 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) 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 one could add various repos. on binhost .. base /power user flavors.. Genric-arm64 , rather unoptimized , for users with rather to get up and running.. 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 work space for more boards in future and the like while my aims are marginally broader than just rpi4 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.. |
|
Is it just me or was that message by @necrose99 all over the place? Making understanding it quite difficult. |
|
bit tired prior , i'm trying to write up a far more plan and post it or set up collab etc , hence a more formalized draft/manifesto/mission statement and or mirroring to https://github.com/GenPi64 got my Tentacles in a lot myself new job , new hire pprk work , 4 work required SIEM certification tests.. ad trying to help as similar projects ie arm64-pentoo for rpi4 |
|
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. ***@***.***> 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>
.
|
|
@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. As a (3), relatively minor issue, is the tooling for automating the client-end of (2). |
|
@omkhar docker images to build packages and or "Stealing some bits" of Sabayon Linux Automation (a Gentoo binary fork) 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 i'd like to lean just enough devops to help out 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 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 IE RPI4 UEFI / Gentoo , will need to fix a few package build options rpi-firmware USE="efi" aid in supporting the genpi64 build Adjacent works : ie RPI ALike Boards , ie the aforementioned rock64pro and or pinebook Pro. or similar arm64/generic BASE repo protected baseline packages.. PENTOO arm64 repo , its Gentoo Security / Pentesting , main area of research. this requires Gentoo as is. 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. for larger packages ie LIBREOffice etc. this would take very little time .. it could chew on distro in record time for DAILY package updates |
@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 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.. |
|
Hi, excuse me. Any news? |
|
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.
The text was updated successfully, but these errors were encountered: