The most of #autotools based open source software is sort of anti-pattern for QA/CI because the test suite is hard-bound to the source project. This is the reason why I rarely (or almost never) run TPM2 TSS test suite.

I wonder if #rustlang continues to follow this anti-pattern or is there cargo install for the test?

It is sort of thing that has been always bad for anything with disjoint host and target system but is part of “craftmanship” because things has been done that way long enough :-)

I think I will aim at building OS image per CI cycle for keyutils. This guarantees a kernel with configuration options to provide maximum coverage.

For .gitlab-ci.yml I guess it makes sense to then just limit to the branch master i.e. review is manual but red flags will rise up if the reviewer was sloppy :-)

For both integration tests of my #ZMODEM crate and also for keyutils Gitlab #CI I’ve been looking for solution to implement transparent serial file transfer.

#QEMU allows trivially to convert serial port to UNIX domain socket but it is not natively supported by sz but with a little bit of socat magic it can be apparently converted quite easily again to PTY:

socat -d UNIX-CONNECT:output/images/serial.sock  PTY,raw,echo=0,link=output/images/ptyC0

This allows to drop SSH support completely from BuildRoot config, which makes it much more appealing for automated CI.

For using #QEMU in #CI generating ephemeral #SSH key pair is one option but after playing for a while with that option I realised that you can create named pipes:

mkfifo tty.{in,out}

And then pass -serial pipe:tty to QEMU. After this commands can be emitted to tty.in and the output can be read from tty.out.

I think this a quite good strategy when having to orchestrate headless QEMU instances without any high-level infrastructure, such as libvirt.

I packed swtpm for the #QEMU build so it does not have to be installed to the system:

https://github.com/jarkkojs/tpmdd-buildroot-external

start-qemu.sh will automatically setup shenanigans so that swtpm will work as TPM emulation host for QEMU.

After build there’s three options:

1. TPM2 TIS/FIFO: output/build/images/start-qemu.sh
2. TPM2 TIS/CRB: output/build/images/start-qemu.sh --tpm-crb
3. TPM1 TIS/FIFO: output/build/images/start-qemu.sh --tpm1

Right, and neither QEMU needs to be installed to the host. I’m trying to sort of construct this in a way that it would become as CI friendly as possible so that this could be in addition used as a CI workload for keyutils.

#BuildRoot #linux #kernel #tpm

My new (WiP) orchestrator for building test image for testing my #kernel tree is fully implemented with GNU make:

# SPDX-License-Identifier: MIT

ROOT			:= $(dir $(abspath $(firstword $(MAKEFILE_LIST))))
BUILDROOT_VERSION	:= 2023.11
OUTPUT			:= $(ROOT)output
BUILDROOT_URL		:= https://buildroot.org/downloads/buildroot-$(BUILDROOT_VERSION).tar.gz
EXTERNAL_URL		:= https://github.com/jarkkojs/tpmdd-buildroot-external/tarball/main

define make-buildroot
	make -C "$(OUTPUT)/buildroot" BR2_EXTERNAL="$(OUTPUT)/external" O="$(OUTPUT)/build" $(1)
endef

define download-package
	mkdir -p $(2)
	curl -sL "$(1)" | tar -zxv -C "$(2)" --strip-components=1
endef

all: buildroot

.PHONY: buildroot
buildroot: $(OUTPUT)/download-stamp
	$(call make-buildroot,tpmdd_qemu_x86_64_defconfig)
	$(call make-buildroot,all)

.PHONY: buildroot-menuconfig
buildroot-menuconfig: $(OUTPUT)/download-stamp
	$(call make-buildroot,tpmdd_qemu_x86_64_defconfig)
	$(call make-buildroot,menuconfig)
	$(call make-buildroot,savedefconfig)

.PHONY: linux-menuconfig
linux-menuconfig: $(OUTPUT)/download-stamp
	$(call make-buildroot,tpmdd_qemu_x86_64_defconfig)
	$(call make-buildroot,linux-menuconfig)
	$(call make-buildroot,linux-savedefconfig)

$(OUTPUT)/download-stamp: 
	$(call download-package,"$(BUILDROOT_URL)","$(OUTPUT)/buildroot")
	$(call download-package,"$(EXTERNAL_URL)","$(OUTPUT)/external")
	touch $@

.PHONY: clean
clean:
	rm -rf "$(OUTPUT)"

It is pretty robust structure because I can e.g. easily add packages (like maybe host swtpm) in a robust manner to buildroot.

#buildroot #linux

To test latest linux-tpmdd changes:

git clone https://github.com/jarkkojs/test-tpmdd
cd test-tpmdd
make

Then:

1. TPM2 TIS/FIFO: output/images/start-qemu.sh --swtpm
2. TPM2 TIS/CRB: output/images/start-qemu.sh --swtpm --tpm-crb
3. TPM1 TIS/FIFO: output/images/start-qemu.sh --swtpm --tpm1

Tools for testing (more in future):

• keyutils for testing keyring and trusted keys
• /usr/lib/kselftests/run_selftests.sh

Requires swtpm to be installed (but not QEMU, it will build one).

#linux #kernel #buildroot

took sort of more productized approach by using `BR2_EXTERNAL` so that I don't have to touch #BuildRoot's Git history: https://github.com/jarkkojs/test-tpmdd

I'll focus on x86_64 first and then work on adding Raspberry Pi 3B+ support back.

https://github.com/jarkkojs/test-tpmdd

#linux #kernel

Work Hard. Play Hard.

Zuckerberg heading into 2024

What is a good strategy when having a C project and you'd want to start converting subportions of it to Rust? The project in question uses just plain makefiles and glibc.

Looking for some idiomatic patterns if such have been invented and documented.

#rustlang #posix

"easter eggs" in #Xfer #Serum and #SerumFX

Linus might be willing to drop support for i486-class machines[1] from the #Linux #kernel.

No, nobody asked for that directly; he brought that up in a discussion himself: https://lore.kernel.org/all/CAHk-%3DwhESMW2v0cd0Ye%2BAnV0Hp9j%2BMm4BO2xJo93eQcC1xghUA@mail.gmail.com/ #LinuxKernel

[1] and a couple of processors which _claimed_ to be Pentium class, but weren't

In my work (or more like home office) desktop I started to use #sway (#i3 #wayland replica). Works for that really well, would not put it to my casual/studio desktop tho (which is mac mini anyway). i.e. you can use it make your console like you had your power plant or something :-) my friend tuomo.wrote the original #ion3 window manager, which influenced this and few others back in the day.

more direct ion3 derivative also continues to live on as https://notionwm.net/ and i've heard that there is also wayland replica of this.

lol what #Trump #NFT cards. when the comedy writes itself https://www.youtube.com/watch?v=fBTmZHcjDgQ

Scumm Bar 3D technique explained and open-sourced! ⌨️🗒️📺

Apologies it took so long and thank you to everyone chasing me to make this follow-up ❤️‍🔥

RVX Projector:
https://github.com/mausimus/rvx-projector

#voxel #monkeyisland #retro #pixelart

so yasm vs. nasm? :-) confusing, i was aware only of latter and that's what i've been using in the past (not very recently, mostly just gas).

Do not know much about #oauth2 but I wonder if I could extract from #Thunderbird the login certificate and re-use that in #aerc?

#email

katsoin tyttöystävän kanssa #leijonanluola:n ekan jakson. OK, myönnetään se itse keksintö oli vähän mitä nyt oli mut se tilitys sen jälkeen kuinka rauta on niin vaikeeta, että ei sellaista bisnestä Suomeen. Thanks Nokia but no thanks ja sillein.

Sit tulee jotain lääkehourusen kuulosta hölinää kaarnan nuuhkimisesta ja metsässä sekoilusta. Ei mitään teknokraatteja ainakaan nämä puunhalaajaleijonat.

Tajuun kyl tod että ei tollaista keksintöä kukaan alaa rahoittaa, mut siis en yhtään ymmärtänyt sitä taantumuksellista läpän heittoa sen jälkeen.

Tervetuloa appi- ja konsulttisuomeen.

#leijonat #nokia #startup #slush #app #tieto #valueforlife

Mark your calendars: vger migration is being finalized this Thursday!

https://lore.kernel.org/linux-kernel/20231212-unselfish-real-myna-67e444@lemur/