Bootable 64-bit RPi3/Pi4 Gentoo image (OpenRC/Xfce/VC4) Pt 2

[lperkins2]

I can't say I'm a fan of Discord, or their ToS, but they have the advantage of being established, and "just working" (mostly).

I plan on joining the #gentoo-arm channel, but wanted someplace for project-specific discussions (like hosting information for the binpkg mirror and what not) which has a persistent history, and integration with github and other features. I'm also quite open to moving that elsewhere. Once the binpkg host is up and running, it could probably even host something fully under user control, but I don't know what.

lperkins2,

I for one, will not use discord. Their terms of service are offensive to me.
Also, I'm a superannuated canine and I don't want to lean any novel manoeuvrers.

I encourage you and other genpi64 followers to join #gentoo-arm on freenode and join in with the existing gentoo arm and arm64 teams.

[Hu]

I can't say I'm a fan of Discord, or their ToS, but they have the advantage of being established, and "just working" (mostly).

I've tried a couple of times over the years to use Discord for various things, and it's never worked at all. No chat. No history. Nothing. I've never gotten far enough to need to read their terms of service. I'm not specifically interested in the Gentoo/rpi project, so using Discord for it does not impact me personally - but there may be other people who are interested and have had a similar record of failure with Discord.

[lperkins2]

I can't say I'm a fan of Discord, or their ToS, but they have the advantage of being established, and "just working" (mostly).

I've tried a couple of times over the years to use Discord for various things, and it's never worked at all. No chat. No history. Nothing. I've never gotten far enough to need to read their terms of service. I'm not specifically interested in the Gentoo/rpi project, so using Discord for it does not impact me personally - but there may be other people who are interested and have had a similar record of failure with Discord.

Aye, that certainly is a concern... I don't run their desktop Electron package (and would discourage anyone from doing so). Their web version works passably well, and bitlbee works quite well.

If anyone is interested in helping out though, and doesn't want to use discord, be sure to speak up, here or on github, and we can figure out what to use. (Slack or gitter might be options, or something else).

[NeddySeagoon]

lperkins2,

I use the Gentoo Wiki, for static information, email and IRC for general disorganised communication.
I do have a 24/7 quassel server for IRC though so I always have the backlog.

Sign me up, I'll support the helpdesk, if nothing else.

[Sakaki]

First, thanks all for your kind comments ^-^

Second, I understand from lperkins2 that it would be useful to have at least the contents of the sakaki-tools and genpi64 overlays under GPL2, so some ebuilds etc could potentially be upstreamed into ::gentoo over time.

Accordingly, please take this as notice that all and any code under my copyright on GitHub (sakaki- account), which has been released under GPL3+ or GPL3 on or prior to 31 Oct 2020, is hereby relicensed additionally by me under GPL2.

Code released by me outside of that GitHub account, or which was not under GPL3 or GPL3+ originally, or released after 31 Oct 2020 is expressly excluded from this.

Note also that where there have been significant contributions by others (PRs etc), these will generally have been submitted under GPL3{,+}; IANAL, but I guess in such cases you may need to contact those authors additionally to get permission to relicense.

Whoever's going to sue you though it won't be me ^-^

Best of luck taking this forward.

[NeddySeagoon]

Sakaki,

Thank you.

[gtwrek]

lperkins2,

I'm interested in this project as well, and can help where I can. Although I've got a lot to learn. Sakaki's step away from this project comes just when I've gotten back into my Pi hobby. I literally am just finishing setting up two Gentoo Pi's in my house. (Making a total of 3 - the first in my house is running my sprinkler system - running 32-bit - Gentoo too from an earlier version of Sakaki's work)

As said I still have much to learn, but am a reasonable hacker. I can usually puzzle up solutions without messing things up too badly. I'm just starting to learn how to copy existing ebuilds and tweak them to my liking (this requiring me to figure out how to setup my own local overlay repo...)

And Sakaki - thanks for all the work, and good luck in your future endeavors!

Regards,
Mark

[NeddySeagoon]

gtwrek,

Read Proxy Maintainers
A lot of that will apply, even if the ebuilds are never accepted for ::gentoo.
The methods and tooling will be useful.

Don't use Gentoos bugzilla though, unless you find a problem with a ::gentoo package. :)

[jlpoole]

I installed Gentoo on a Dell 17" Inspiron back in 2012 or 2014. At that time I made the election that it would be a Gentoo-only machine and destroyed the already-installed Windows system. About 2 years later, something was broken and could only be fixed using Dell's firmware deployment which required Windows. I vowed then that, if possible, I'd have a dual boot machine on any future Dell computer just so I could service my firmware with Dell.

I've dealt with EFI when installing Xen on an Intel Atom-based Supermicro server... it was extremely painful and took a lot of my time. I curse EFI to this day.

Then 2019, I purchased a newer Dell Inspiron and discovered Sakaki's guide. The install took a long time, but it worked. I was very impressed and I'm very thankful that Sakaki took the time to share something and made sure every detail was attended to. I do have dual boot on my Inspiron now, but just read the news item of Sakaki's discontinuance. I salute her and I remain grateful to her.

At the same time, I'm wondering: does the cessation of this project mean that owners of Dell Laptops cannot maintain a dual-boot system so they can enjoy Gentoo, yet have Windows there for hardware/firmware updates?

[gtwrek]

gtwrek,

Read Proxy Maintainers

Tons of good info there. Will try and take it all in with baby steps...

Regards,
Mark

[flysideways]

Sakaki,

If you see this, thank you very much for your contributions to Gentoo.

I do have a related question. Your documentation was very helpful and concise, but the formatting on github was also very readable. What did you use to create the documentation that was posted?

Thanks.

[spork_kitty]

It's a shame to see the project fall into stasis. Sakaki did pre-built Gentoo better than anyone else.

I'll keep an eye here to see if anyone takes up the torch, but it's looking more and more like I'll have to run my own distro... KISS is quite good and designed to be a one-person project. Could go LFS if that's not simple enough.

[Sakaki]

I do have a related question. Your documentation was very helpful and concise, but the formatting on github was also very readable. What did you use to create the documentation that was posted?

It's all written in GitHub flavoured markdown of course, which is pretty simple to learn & use. You can also clone the gentoo-on-rpi-64bit repo, or its wiki, to see the underlying formatting used on the documentation pages, if that helps.

FWIW, I wrote the documentation in Emacs, using a markdown major mode, and a custom YASnippet set of templates. But I wouldn't recommend anyone go that route unless they were already full-on Emacs users to begin with ^-^

TBH, just using the GitHub preview tools / writing markdown directly via their web interface online, should work fine for most things. There are plenty of markdown editors out there too (with varying degrees of preview fidelity).

[itachiluan]

Sakaki,

Thanks very much for this fantastic project, and thanks so much for helping me setting up mongoDB on my Pi, it's been working really well ever since. I've tried all kinds of 64bit OS for my Raspberry Pi, your distro is the most reliable for me, really appreciate it!
Congratulations on landing the new job, wish you all the best in the future!

Kind Regards,
itachiluan

[NeddySeagoon]

itachiluan,

There are two thrusts going on that I'm aware of.
I'm interested in getting as much as possible upstream, as are some of the users in #gentoo-arm.
That should make maintenance easier but it does almost nothing for a binary distro.

At least one person has expressed an interest in keeping the binary distro alive.
The upstreaming effort will help that too.

I maintain a binhost but its built to do keyword testing, so may not be compatible with Sakakis distro.
Feel free to try though.

[itachiluan]

Hi NeddySeagoon,

Thanks so much for your effort. As much as I'd like to help, I'm just a user and a real noob trying very hard to even understand the documentation on the website
But I do really hope that genpi64 can continue and, even more, I wish Gentoo for ARM could be better in general (you see, I can't even find an official Handbook for Gentoo ARM ).
I'll definitely try the binhost, please feel free to let me know anything I could help with as a user (testing, reporting bugs, up voting for things, etc.)

Thanks!

Kind Regards,
itachiluan

[gtwrek]

Ok, so I'm starting to migrate my builds off of sakaki's repo.
I want to be careful in that I don't want to upgrade some of the ebuilds as there are significant reasons to stay with Sakaki's builds instead of upgrading.
(The ffmpeg example is the canonical use case. I want to continue to use Sakaki's Pi optimized builds for as long as possible - or until someone figures out how to upstream all those patches).

Is there a quick way to have portage tell me what packages current installed on my system are from Sakaki's genpi64-overlay? I know all the information is there, but I'm struggling for an easy way to get it.

My idea here would be to inspect this list, and apply appropriate package.mask for now to keep Sakaki's versions where I think I need it, then start a world upgrade. I've already adjusted my repos.conf to point directly to gentoo mirrors, instead of the isshoni.org mirror (which is no longer being updated)

[NeddySeagoon]

gtwrek,

Its all in /var/db/pkg/... somewhere.
Try

Code: Select all

grep genpi /var/db/pkg/*/*/repository

crabbedhaloablution has done a few PRs. I've done one, for keywording.

I'll be interested to hear what your think you need from Sakakis genpi64 overlay and why.
If you spot dropped patches. That may be bugs. Its also possible that the patches are no longer required.

[gtwrek]

Code: Select all

grep genpi /var/db/pkg/*/*/repository

Perfect! That works wonderfully.
Thanks,
Mark

[gtwrek]

gtwrek,

I'll be interested to hear what your think you need from Sakakis genpi64 overlay and why.
If you spot dropped patches. That may be bugs. Its also possible that the patches are no longer required.

Well, the big one like I alluded to was ffmpeg. One of my Pi4s is a media server running Kodi. From what I understand, and my minor digging through the ebuild, there were significant patches Sakaki maintained for ffmpeg, enabling hardware accelerated playback. I googled around a bit and was able to find some references to the patches, but it wasn't much organized nor described. I think even you implied on this thread (or perhaps another) that these patches were not headed upstream (yet/at all?)

That's the big one. But I'm going to dig through the entire list you help me create to be sure what I need there, what's made it upstream, and what I need to look at closely to determine how much Sakaki's overlay added value over the default gentoo repo sources that I might need.)

Thanks,
Mark

[NeddySeagoon]

gtwrek,

It would be good if you checked https://github.com/NeddySeagoon/genpi64-overlay against https://github.com/sakaki-/genpi64-overlay

My github overly is what I think still adds value.
I'm aware that there is some Pi firmware and binary been upstreamed to ::gentoo that is still in my fork.

Anything that isn't needed, or I removed in error would be good to know about.

As you say, ffmpeg is the biggie.

[gtwrek]

Thanks for starting the overlay Neddy.

Dumb portage question of the day follows.

To point towards your overlay, I created a new repos.conf file entry.
To disambiguate your overlay from Sakaki's I named yours "neddy-genpi64.conf":

Code: Select all

# Overlay for 64-bit Gentoo on the RPi3 and RPi4 SBCs
# Maintainer: (Neddy Seagoon) 
# 
location = /var/db/repos/neddy-genpi64
sync-type = git
sync-uri = https://github.com/NeddySeagoon/genpi64-overlay 
priority = 100
auto-sync = yes

(Note I lowered sakaki's overlay priority, and I'll eventually mask the repo too, before eventually removing it permanently)

However, I'm getting warnings from emerge:

Code: Select all

!!! Section 'neddy-genpi64' in repos.conf has name different from repository name 'genpi' set inside repository

It appears this is telling me that the name from within your repo (I'm assuming the repositories.xml file you maintain within the repo).
So, I cannot control this repo name - it's maintained by the repo owner? So, this name space must be global?

Ignoring the warning (I know, don't do that), I try and emerge your latest ffmpeg:

Code: Select all

emerge -pv1 =media-video/ffmpeg-4.3.1::neddy-genpi64

Nope, that doesn't work. I tried using your defined repo name:

Code: Select all

emerge -pv1 =media-video/ffmpeg-4.3.1::genpi

That didn't work either. Checking emerge --info shows me why - it doesn't show your repo. Even though I cloned your repo, portage isn't seeing things totally correct (as the warning's likely telling me).
So, I got things working by renaming your repo locally to match your name "genpi".

But is this intended behavior? Repo owner controls its naming and the global namespace must not conflict? I see the "alias" Attribute is available from within repos.conf, but it's use is discouraged?

Thanks,
Mark

[NeddySeagoon]

gtwrek,

The combination of my repo and the gentoo repo should be the same or newer as sakakis repo and gentoo.

My ffmpeg-4.3.1 fails with patching as the libreelec patches don't apply.
That's what works the magic for hardware acceleration on the Pi.

I changed my repo name for the same reason you did. My repo isn't new.
Its a fork from the time of sakakis last commit. All I have done is to remove things that I don't intend to support and keyword packages so that they are removed from my fork and in ::gentoo.

Others are upstreaming (into ::gentoo) the equivalent functionality of some of the ebuilds too.
That functionality has been removed from my fork too.

[gtwrek]

I'm following your thought processes on removing things from your repo that have already been upstreamed. That's exactly as it should be.
I'm also not concerned (yet), that your ffmeg-4.3.1 fails. I'm just trying to setup my workflow.

I guess my simple question - I don't like the repo name "genpi" - it's far too generic (in fact I believe Sakaki used this name for the 32-bit builds?). In any case, must I live with the repo name you define?
For my organization purposes I'd like the name to be more specific i.e "neddy-genpi64", but portage didn't like the way I tried to do that. "Alias" within my repos.conf file seems to be the correct path forward, but the gentoo guide seems to discourages its use.

Is there another way of accomplishing what I'm trying to do? (As I've implied, I've a feeling that my basic portage knowledge is masking something that's an obvious solution - just staring me in the face)

Regards,
Mark

[Jarodiv]

With some manual steps involved (kernel, boot-firmware, wifi drivers), it seems to be possible to get Gentoo running on the PI4 using almost only upstream packages. On mine I now have XFCE and only two packages are left from Sakakis overlay ("media-sound/pulseaudio" and "media-libs/raspberrypi-userland").

Not sure about the hardware accelleration for ffmpeg though.I've read that it should work since ffmpeg-4.3 but haven't been able to test it yet.