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
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.
#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!

More relevant than ever
#tunestr https://open.spotify.com/track/50gbFx4EWSd9SlE06drfGU?si=3YmOcvxLQsmcUMw5ZDxXqw
...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.
The last OS install off a CD I did was Win98
The last DVD was WinXP.
I'm sorry #plebs, he's not pro #Bitcoin at all. Just another political whore out there.
https://video.nostr.build/b797e051968ce22029296bff917efba399965119f5843627082049c2139afcd9.mp4
ain't they all tho?
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?
It isn't about how high or low the BTC/USD price is, it is about the people.
If I were to visit a bitcoin con, it wouldn't be to get prepped for a bull run or whatevertheheck - but rather to see the atmosphere, talk to people and hear their stories.
At least, that is what I think a good conference is all about. Having some damn good fun. =)
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.
Iunno why, this song just makes me happy. ^^