Avatar
Ingwie Phoenix (aka. birb)
5e336907a3dda5cd58f11d162d8a4c9388f9cfb2f8dc4b469c8151e379c63bc9
[ENG/GER] NOT a bitcoiner/stacker/maxi. I am here to have a damn good time! Rabbithole conniseur; I enjoy random stuff. :D Ex-Furry, (close to) blind, hobby developer/sysadmin, waifu enjoyer, long hair fetish (#hairjob). I sometimes talk about NSFW stuff; because fucking is fun =) (DMs always open.)

I opened btop and forgot about it while talking to my friends. Then checked back in later.

https://void.cat/d/SmGUz9N2ViRAEFkyEghdKv.webp

Yep, it's in pain.

Hm... I really do lack knowledge about BSD. Most I have got is macOS - which *hardly* counts. x) But man... a good BSD-based router? Would certainly like that. o.o

https://www.cheribsd.org

Heh. Unironically, mood. I have a plan and I am executing on it now. I WILL have my alpine:3.19 image AND a build setup to build whatever I want for the VisionFive2. By the end of the year, an even bigger board is bound to drop and you can bet I will try to get involved there too. I want these things to exist, to work and to be amazing. I am sick and tired of overpriced RasPi's - there are JH7110 boards for 30€ and this really feels like my personal Raspberry Pi moment. And, well, I learn an absurd lot off of this.

#tunestr https://song.link/s/3Lnpa5SFKxO6VSysgenTrQ

https://void.cat/d/T7yKDZ9CcjYMJ6NKSXzCQ4.webp

#devstr #workout

https://void.cat/d/5bFmbshyWhtQNPVhXXCkNW.webp

When I am done with my whole plan, Alpine maintainers CAN NOT deny RISC-V and I would have a strong argument in making them publish official RISC-V images for good. And, with this done, I can get into #armbian and pick up maintainership on VisionFive2 (tbh, idk what that will entail...)

After that, I will see if I can nudge kernel devs into reviewing the StarFive submitted patches to help the JH7110 be even more upstreamed - I hope to use a mainline kernel with this by the end of this year, meaning that SBCs with this particular CPU will have amazing compatibility.

I may talk a lot and I am quite a loud noter. But, do not mistake me - I walk the walk that I talk. =)

So according to Jenkins' antispam bot, the following is ... spam.

ehhh.... x.x

---

Jenkins setup:

```

Jenkins: 2.440.1

OS: Linux - 6.6.0-g076ede06c00a

Java: 23-ea - Debian (OpenJDK 64-Bit Server VM)

---

analysis-model-api:12.1.0

ant:497.v94e7d9fffa_b_9

antisamy-markup-formatter:162.v0e6ec0fcfcf6

apache-httpcomponents-client-4-api:4.5.14-208.v438351942757

authentication-tokens:1.53.v1c90fd9191a_b_

bootstrap5-api:5.3.2-4

bouncycastle-api:2.30.1.77-225.v26ea_c9455fd9

branch-api:2.1152.v6f101e97dd77

build-name-setter:2.4.1

build-timeout:1.32

caffeine-api:3.1.8-133.v17b_1ff2e0599

checks-api:2.0.2

cloudbees-folder:6.901.vb_4c7a_da_75da_3

command-launcher:107.v773860566e2e

commons-lang3-api:3.13.0-62.v7d18e55f51e2

commons-text-api:1.11.0-95.v22a_d30ee5d36

conditional-buildstep:1.4.3

config-file-provider:968.ve1ca_eb_913f8c

configuration-as-code:1775.v810dc950b_514

credentials:1319.v7eb_51b_3a_c97b_

credentials-binding:657.v2b_19db_7d6e6d

dark-theme:416.v535839b_c4e88

dashboard-view:2.508.va_74654f026d1

data-tables-api:1.13.8-4

display-url-api:2.200.vb_9327d658781

docker-commons:439.va_3cb_0a_6a_fb_29

docker-workflow:572.v950f58993843

durable-task:550.v0930093c4b_a_6

echarts-api:5.4.3-4

email-ext:2.104

embeddable-build-status:467.v4a_954796e45d

font-awesome-api:6.5.1-3

forensics-api:2.4.0

git:5.2.1

git-client:4.6.0

git-parameter:0.9.19

git-server:114.v068a_c7cc2574

github:1.38.0

github-api:1.318-461.v7a_c09c9fa_d63

github-branch-source:1772.va_69eda_d018d4

gitlab-plugin:1.8.0

gradle:2.10

gson-api:2.10.1-15.v0d99f670e0a_7

instance-identity:185.v303dc7c645f9

ionicons-api:56.v1b_1c8c49374e

jackson2-api:2.16.1-373.ve709c6871598

jakarta-activation-api:2.0.1-3

jakarta-mail-api:2.0.1-3

javax-activation-api:1.2.0-6

javax-mail-api:1.6.2-9

jaxb:2.3.9-1

jdk-tool:73.vddf737284550

jersey2-api:2.41-133.va_03323b_a_1396

jjwt-api:0.11.5-77.v646c772fddb_0

joda-time-api:2.12.7-29.v5a_b_e3a_82269a_

jquery3-api:3.7.1-2

json-api:20240205-27.va_007549e895c

json-path-api:2.9.0-33.v2527142f2e1d

junit:1259.v65ffcef24a_88

locale:431.v3435fa_8f8445

mailer:463.vedf8358e006b_

mapdb-api:1.0.9-28.vf251ce40855d

matrix-auth:3.2.1

matrix-project:822.824.v14451b_c0fd42

metrics:4.2.21-449.v6960d7c54c69

mina-sshd-api-common:2.12.0-90.v9f7fb_9fa_3d3b_

mina-sshd-api-core:2.12.0-90.v9f7fb_9fa_3d3b_

nodejs:1.6.1

okhttp-api:4.11.0-172.vda_da_1feeb_c6e

pam-auth:1.10

pipeline-build-step:540.vb_e8849e1a_b_d8

pipeline-github-lib:42.v0739460cda_c4

pipeline-graph-analysis:202.va_d268e64deb_3

pipeline-groovy-lib:704.vc58b_8890a_384

pipeline-input-step:491.vb_07d21da_1a_fb_

pipeline-milestone-step:111.v449306f708b_7

pipeline-model-api:2.2175.v76a_fff0a_2618

pipeline-model-definition:2.2175.v76a_fff0a_2618

pipeline-model-extensions:2.2175.v76a_fff0a_2618

pipeline-rest-api:2.34

pipeline-stage-step:305.ve96d0205c1c6

pipeline-stage-tags-metadata:2.2175.v76a_fff0a_2618

pipeline-stage-view:2.34

pipeline-utility-steps:2.16.2

plain-credentials:143.v1b_df8b_d3b_e48

plugin-util-api:4.1.0

prism-api:1.29.0-13

publish-over:0.22

resource-disposer:0.23

role-strategy:689.v731678c3e0eb_

run-condition:1.7

scm-api:683.vb_16722fb_b_80b_

script-security:1326.vdb_c154de8669

snakeyaml-api:2.2-111.vc6598e30cc65

ssh-agent:346.vda_a_c4f2c8e50

ssh-credentials:308.ve4497b_ccd8f4

ssh-slaves:2.948.vb_8050d697fec

sshd:3.322.v159e91f6a_550

structs:337.v1b_04ea_4df7c8

subversion:2.17.3

theme-manager:215.vc1ff18d67920

throttle-concurrents:2.14

timestamper:1.26

token-macro:400.v35420b_922dcb_

trilead-api:2.133.vfb_8a_7b_9c5dd1

variant:60.v7290fc0eb_b_cd

warnings-ng:11.0.0

workflow-aggregator:596.v8c21c963d92d

workflow-api:1291.v51fd2a_625da_7

workflow-basic-steps:1042.ve7b_140c4a_e0c

workflow-cps:3867.v535458ce43fd

workflow-durable-task-step:1331.vc8c2fed35334

workflow-job:1400.v7fd111b_ec82f

workflow-multibranch:773.vc4fe1378f1d5

workflow-scm-step:415.v434365564324

workflow-step-api:657.v03b_e8115821b_

workflow-support:865.v43e78cc44e0d

ws-cleanup:0.45

```

(I am limited to 2 links - apologies for the linkless links!)

Alright, with that done... Hello there!

I am new to Jenkins - but not to CI/CD. Before, I was trying out Laminar, Travis and others over the years. But now, I actually need CI/CD more than ever.

Here's the sitch: I have a VisionFive 2 (RISC-V SBC) that, whilst being [almost upstream](https://rvspace.org/en/project/JH7110_Upstream_Plan) still lacks a few very important things; two, to be precise. One being a variety of OS images, and another being Docker containers.

Since RISC-V is kinda "the new kid on the block" still, there is not that much in terms of OS images, kernel prebuilts and the likes. Well, I would like to change that. Sure, I could go to the Alpine mailing list and moan about the lack of an `alpine:3.19` image (which I might have to do still - but with way more substance behind it all) and hope for the best. But, I would rather not do so immediately, and instead get some work done that can be reused by others in the long-run.

So, I dropped OpenJDK and Jenkins on my VF2, wrote a SystemD unit and aside from TVHeadend and Home Assistant, there is nothing running on this box. Literally, I can actually see the bottom of htop! So there is a whole lot of unused compute that I would like to take advantage of - especially since I have a 1TB NVMe SSD in the box now.

And this is where Jenkins comes in - or, more precisely, a whole lot of pipelines. Basically, I have to build a few things in order to work my way to Alpine's `abuild` with a proper toolchain behind it, to then use those automations to produce packages, that I can then flush into a repository, which I can then use to programmatically create Alpine images - tagged ones, at that, with _their_ build instructions and dependency tracking.

So the structure is effectively this:

1. Build a Buildroot (buildroot/buildroot)

- I chose to pick ucLibc + gcc (c, c++) with Busybox and a few basics; keeping it simple.

2. `FROM scratch; ADD buildroot-sdk.tar.gz /` into a Docker image (let's tag that `buildroot:$git_tag`)

- ... And publish that to my Docker account so others can use it.

3. Tell Jenkins to build a new container `buildroot-abuild` that extends `buildroot` - but only with `abuild`.

4. Create a "dynamic" pipeline, that will start to feed package names from the abuild/aports repo into a pipeline in the sense of `for $pkg in $pkg_list { docker run --rm buildroot-abuild -v $abuild_repo:/abuild /* ... */ }`. The Alpine images for Docker are quite minimal, so I would start with those first. After each image finishes, there should be a couple of package files that can be collected and sent to an upstream repo (probably something like `scp $file user@host:$repo_path/ && ssh user@host rebuild-repo`)

5. Rinse and repeat untill the basics for `alpine:3.19` are satisfied.

6. Use the `alpine-make-rootfs` (alpinelinux/alpine-make-rootfs/tree/master) tool, apply a patch to change the location of `apk-static` and the repository URL and construct the new rootfs - then drop it into a container that we can savely tag `alpine:3.19` and publish!

The buildroot setup is quite easy; specify a repo, specify the config, specify the tag. Though I would like for Jenkins to automatically run new builds against new tags - treating them as releases, as long as they have no `-rcN` suffix (i.e. regEx test?).

Adding `abuild` into this is but a super simple Dockerfile away - however, this SHOULD always run after a new buildroot tag has been built, and should always use the latest version of `abuild` (tagged in the repo as a semver).

`abuild` runs need a working `buildroot-abuild` first and foremost - so once one of these exists and is live and available to be used, I want jenkins to get to work on building those one by one. What I do not know is: How would I actually tell it which packages to build, and which not to? Is there a script that can trigger something like a parameterized pipeline? I.e.: `jenkins-cli run pipeline buildroot-abuild --arg PKG=$pkg_name` would trigger Jenkins to start a job where it spins up an instance of `buildroot-abuild`, mounts the `abuilds` repo and then executes the build and collect/deploy the outputs?

Then, when a certain set of those `buildroot-abuild` builds have produced the neccessary outputs to construct the `alpine:3.19` rootfs, I want Jenkins to pick up on that and construct the container and publish it on my Docker profile.

So... I spent a lot of time planning this in the times I traveled to work and school and back. However, I am a little lost on:

- How do I organize those steps?

- How do I make pipeline B depend on A?

- How do I add parameters to a pipeline and make that part of a dependency? (`buildroot-abuild PKG=libwhatever` as a dependency to `alpine:3.19`, in this case)

- How do I "dynamically" provision agents (which the `buildroot-abuild` containers will be, after all)? Or do I have to wait untill that one is ready, then mark it as an agent and then continue setting up the rest?

I know that this is a lot of questions - and I tried to condense it and hopefuly I posted it into the right forum. I did look into Jenkinsfiles and thought of just making a monolithic repository containing an onslaught of those to describe the whole process.

The long-term goal is to not just build Alpine images, but possibly take advantage of the `buildroot` container to build OS images of other versions; Ubuntu, Debian, NixOS, ... Things, yknow? I have a kernel config, working on openSBI and U-Boot right now, so that I can supply those to create distro packages that can then become part of the built OS image. But - first, I need this Alpine image to make Podman shut up about missing layers. :D Because if I want to add this VF2 into a K3S cluster, I need it to have images it can work with. `alpine:edge` deviates strongly from the idea of a strictly described state - so I want to use a fixed release instead...and since the most common one is 3.19, that is the one I target.

Again, I apologize for this absolute **wall** but I hope I got both the forum and location as well as the structure of this right!

Thank you a lot for reading this whole thing, by the way. ^^

Kind regards,

Ingwie

RIP NVMe SSD. `make V=1 -j$(nproc) sdk`

Let's do this! :D

Started configuring buildroot on my way home via my phone. Protip, don't do that through Termux - it's actually terrible with this xD I wish I have had some kind of gesture controls... Termux is, for all intends and purposes, an "okay" terminal emulator. But once you need to do more than type short commands, it falls apart so fast o.o

Basically, what I am planning to do:

FROM scratch AS buildroot

ADD buildroot-rootfs.tar.gz /

FROM buildroot AS buildroot-apk

ADD abuild.tar.gz /

ADD apk-static.tar.gz /

COMMAND ["/bin/sh"]

This can now be used to put together any abuild-based package ... including Alpine, itself. Now all I have left to do is to automate the building of this, split it into actual containers (buildroot:$version and buildroot-apk:$version) and then use the latter to start building the entirity of Alpine 3.19's rootfs, start to finish and more packages as I am going.

Since I have a kernel config, I will edit that to become modular instead so that I can build kernel module packages, vendor-prefix that so it doesn't collide (i.e. linux-image-vf2ip for VisionFive2 Ingwie Phoenix) and then ... send it. A week or two later, I should have a complete build of Alpine 3.19, that I can then install into a docker container as a new rootfs, and publish, and use for any other container that happens to rely on it. Oh and notify the Alpine guys about it.

Last thing to do is to learn how to automate all of this with Jenkins. I got my configs, I got my storage, and I got my host. So ... let's go!

Oh and while I am at it, I might start making strfry images with complete static linkage and a single layer. The faster we can deploy Nostr tools everywhere, the better. This is effectively a side product. x)

i.e.:

FROM buildroot-apk as build

RUN apk install --no-cache $strfry_dev_deps

RUN make setup-golpe && make -j$(nprocs)

FROM scratch

COPY --from=build .../strfry /strfry

ENTRYPOINT ["/strfry"]

This'd be freaking neat - and it IS possible. PRing that into upstream will be wild. :D

Getting into crosstool-ng; it's pretty nice. But I need a toolchain ON the host... so this is not the tool to use, in this situation. But it will come in handy for other things, that is for sure. So, good to have it on hand. Next: Buildroot!

I snuck out of sports class once my teacher got too hardcore into it to notice. x)

So, time to read more Alpine internals!

...huuuuh? Holup, wait a minute.

https://github.com/torvalds/linux/commit/5cb475174cce1bfedf1025b6e235e2c43d81144f

Did a Huawei dev just fix a jh7110 issue? Hmmmm.... now THAT is interesting. o.o

I mean, to be fair, RISC-V is a way for China to become independent from american corpos; not exactly news. But I wasn't expecting to be reminded of that in some random kernel commit either. o.o

Listening to Eurobeat to wake up.

I need a moodlifter before school o.o...

Like, every time I go to school, I remember that I am 30 years old, and I still have to sit infront of some dude squabbling on about stuff I already know, just to get certified for the crap I've learned a decade ago on my own. Bleh. x.x

I will have to suffer one more month with my half-cooked network infra.

PS5 + FF7R Part 2 has my attention now. My friends are all getting their orders and I completely slept on buying my ps5 on time because I smoked all my funds on network infra e.e

Well... Maybe the Radxa ROCK 5B will drop in price ... perhaps.

I can understand that ... but only to a degree.

Allow me to share my point of view. I am visually impaired, so I can never, and will never, be able to see if people near me are taking photos. In fact, I have accidentially photobombed legitimate PR shoots by just blindly and blisfully unaware walking straight through the shot xD.

If I sit in a car and we drive by a speedometer, can I be sure it isn't taking a picture of me? When I sit in a train and people outside on the platform take a group photo, I might be in that by sheer chance. While I am at a booth at an anime or game convention, someone might be taking press photos - and I would be non the wiser it happened. Either because I literally didn't see it, or because it was taken in stealth on purpose, for some reason.

If you are in public, and I really do mean public, unless you scan your environment like every second, you will never know who or what is or is not taking a photo of you - and unless you become paranoid in a certain way and ask everyone around you to lower their phones, you simply can't cover every circumstance.

Yes, it definitively sucks to have your picture taken without consent - lawfully or not. Yes, it is good ettiquete to not do that, not just in protests, but in general - but not everyone always thinks of this in a perfect fashion; humans aren't perfect after all :).

In these times, where surveiliance becomes more and more of a norm, masking your face is actually the best thing you can do. Doesn't matter if it's a stereotypical Guy Fawkes mask or one of those thin silicone masks to alter your facial features - it will become more important over the years. So if you don't want your picture taken in public, then make it harder to do so. Because you can never truely and fully rule it out. Maybe someone is wearing a prototype gadget as a pin on their suit that happens to have a camera and you never identified it as such? Just saying.

Now, while I understand the desire to stay "anonymous" and not feed "DA BIG CORPOS" with more data... I also have to say: Damnit, grow a pair. Has your state not already forwarded tons of ID photos to them one way or another? Have they not bought data from these firms at some point? I am 100% certain that my face is in multiple databases - not because I am particularily careless (I had posted many photos of myself when I was younger, so that opsec-ship sailed looooong ago xD) but because data exchange between corps and govts is a given now; even slow and sloppy Germany, I am quite sure.

It sucks, it really does. But what are you going to do about it? Punch in every camera and destroy each phone that possibly has caught a glimpse of your face - both from regular people and state owned cams? I mean, you could - it's an option... but - should you?

Kernel devs: We need more people working on the kernel!

Also kernel devs: https://lore.kernel.org/all/877cipamvd.ffs@tglx/

I understand that patches have to be scrutinized on the extreme in the kernel and the formating guidelines have a reason to be there. But I feel like the language used in his third intervention about the hotplug eventing was... very harshly worded. While I understand why he did that, I also understand if people are put off by this kind of response. It's... Unfortunate.