build scripts for release image

[powderluv]

Great work. How do I generate an "official" image ? I would like some customizations before deploying. Are there any scripts you use to build the release image ? Couldn't find any poking around your repos.

In a past life I helped ChromeOS move to Gentoo https://chromium.googlesource.com/chromiumos/docs/+/master/developer_guide.md and could help put together a custom build_image script to generate a RPi64 image if there is interest (and nothing exists). We went through great pains to cross compile everything so we can build everything on the host without qemu-static.

[sakaki-]

Hi @powderluv,

thanks for the offer of assistance! Currently my build scripts for the image would need significant cleanup before I'd be happy publishing - you're the first person to express interest in them tbh so cleaning them up isn't something I've spent many cycles on to date ^-^

My current PC build rig does use QEMU (via binfmt_misc, pretty much per these notes, which I presume is what you mean by qemu-static?) to create tbz2 binary packages prior to final image construction; the actual image assembly is then created from these tbz2s on a native RPi4 system. Gentoo upstream use a Cavium ThunderX for native compilation afaik.

[FuyuriSeiichi]

Hello, I'm also very interested in this. I stripped off unnecessary libraries like libnotify, gtk+ and put on KDE plasma instead here. I would really love to have a convenient way to create a backup image.

Simply dd is taking too much extra storage. Thank you.

[jfikar]

For smaller dd image files:

1. prior to backup issue fstrim -va, it converts unused space to 0x00
2. store the image file as a sparse file dd conv=sparse (0x00 will not take any space) or compress it (series of 0x00 will compress well)
3. when writing back to SD card, you probably need to avoid the conv=sparse, as the SD card readers usually do not support TRIM

[daggs1-zz]

same here, I'm intrested to know if the rpi-userland is 64bit full and what it supports

[sakaki-]

Yes, both kernel and userland are 'pure' 64-bit (aarch64/arm64).

You can see a versioned list of all installed packages on the image here.

If you mean the raspberrypi-userland package, then this now includes most things (MMAL, raspivid, vcgencmd etc); only a few elements (such as OpenMAX-IL) are now missing from the 64-bit build.

hth, sakaki

[daggs1-zz]

Yes, both kernel and userland are 'pure' 64-bit (aarch64/arm64).

You can see a versioned list of all installed packages on the image here.

If you mean the raspberrypi-userland package, then this now includes most things (MMAL, raspivid, vcgencmd etc); only a few elements (such as OpenMAX-IL) are now missing from the 64-bit build.

hth, sakaki

where is the ${P}-64-bit-mmal.patch? my tests of compiling rpi-userland with mmal enabled (it is hardcoded disabled) results with this failure: vcos_static_assert(sizeof(mmal_worker_service_closed) <= MMAL_WORKER_MSG_LEN); looking at the code shows that mmal_worker_service_closed is indeed bigger than 28 bytes. have you encountered it?

[daggs1-zz]

btw, accroding to the devs of rpi-userland, OpenMAX will never be ported due to api issues. mmel provides hw decoding

[sakaki-]

@daggs1,

where is the ${P}-64-bit-mmal.patch?

It's here

hth, sakaki

[daggs1-zz]

thanks, will check

[daggs1-zz]

I'm seems to be missing libbrcmEGL, libbrcmGLESv2 and libkhrn_client ideas?

[jonesmz]

I'm also interested in the compilation scripts, I want to work on a net-bootable, systemd based version of this.

[jonesmz]

As a followup on my previous comment, I'm a software engineer and have about 10 years of exp with Gentoo. I'm interested in using Gentoo on raspi for some work related tasks, so I'd be looking to invest several dozen hours worth of work into the build process for this project if the existing setup could be published as a starting point.

[jonesmz]

Sorry to be a bother, I won't poke this issue again unless there's a question or something, but just to reiterate, this is something that I'm very interested in working on.

[sakaki-]

Hi @jonesmz -

thanks for the ping, apologies for my slow response on this ><

It would be nice to open the build scripts I agree, particularly since the platform now appears relatively stable for the RPi4.

A sensible place to begin would probably be the kernel autobuild scripts. I'll have a look at publishing something over the next couple of weeks. Feel free to jump in an clean up once available (I'll post here once they're up).

After that I'll look at structuring the userland build part and putting that out also.

Best, sakaki

[omkhar]

Former gentoo dev, with a ridiculous amount of RPis - would love to contribute as well!

[jonesmz]

I'm saying this here just for keeping the information in one place, not to try to give you a sense of urgency.

One of my goals is to experiment with LTO (Link Time Optimization) for the generated raspberry pi image. This is related to https://github.com/sakaki-/gentoo-on-rpi-64bit/issues/202

[jonesmz]

@sakaki-

Congratulations on your new job, it sounds exciting.

I understand that your new position prevents you from further contributions to open source.

I would ask that if you're allowed to, please share whatever scripts you've used to build release images so that I can attempt to continue your work on a gentoo-on-rpi-64bit project fork.

If you're prohibited from sharing those, it would be sad, but I would understand.

[sakaki-]

@jonesmz -

I am in discussions about this with my new employers now. If possible I will release what I have in its current form; my bad, I should have got something posted earlier. Apologies.

Thanks for your understanding, it has not been an easy decision to make ><

Best, sakaki

[sakaki-]

30 Oct 2020: sadly, due legal obligations arising from a recent change in my 'real world' job, I must announce I am standing down as maintainer of this project with immediate effect. For the meantime, I will leave the repo up (for historical interest, and since the images may be of use still in certain applications); however, there will be no further updates to the underlying binhost etc., nor will I be accepting / actioning further pull requests or bug reports from this point. Email requests for support will also have to be politely declined, so, please treat this as an effective EOL notice.

For further details, please see my post here.

Many thanks for your interest in this project!

With sincere apologies, sakaki ><

[jonesmz]

I am in discussions about this with my new employers now. If possible I will release what I have in its current form; my bad, I should have got something posted earlier. Apologies.

Ok. Thank you for doing your best for the community.

Your work was (and continues to be, even if you have to stop) very valuable.