Notices by Leah Rowe is not a Rowebot (libreleah@mas.to), page 4

@tlaurion @mkukri tl;dr - we already discussed yoru concerns in #libreboot earlier. As Mate said, the upstreaming will be done at a later date when he feels like it. We're not in any rush . You just have to wait.

By the way: there's also the S model. T480s. your initial patch for Heads seemed to only focus on T480, but there's also T480s. so that ifdef should also handle T480s.

Perhaps a better way is this:

Define HAVE_H8S_EC or something, on the other thinkpads. Because T480 doesn't have it.

@tlaurion @mkukri So with my design, it's easy to maintain like 50 coreboot revisions if I wanted to, in the future.

See the "trees" script in lbmk. And read up about "mkhelper", "premake" and "postmake" in that guide.

With few variations in code, Libreboot can build every project in the same script. GRUB, coreboot, SeaBIOS, U-Boot - all completely unified.

I advise that the Heads design be audited - your issue in the T480 context is one of code repetition maintaining a separate tree, right?

@tlaurion @mkukri And Libreboot is dealing with a lot more revs. It has a completely unified build system design. The same script is used for every tree of coreboot, indeed every *project*. There are 7 shell scripts; this is the result of 6 audits spanning 2023 and 2024 where I removed 80% of the build system logic. See:

https://libreboot.org/docs/maintain/

This contrasts the Heads design. Having audited your build system, I can see that you do repeat a lot of (Makefile-based) logic per board/tree/project.

@tlaurion @mkukri By the way, did you see what I said? You can just use an ifdef, if it's just the thermal asl thing or whatever. Someone kept pinging me about that on IRC and I assumed it was spam. Sorry!

Regardless of your stated position, I'd still like to see Heads merge this board. It shouldn't be too much effort.

Don't you already have a multi-tree build system? For example you have a separate setup for KGPE-D16.

And Heads is entirely source-based too. No binary releases. So it's fine.

@tlaurion @mkukri My policy is the opposite:

I rule the Libreboot project with pretty much an iron fist and will happily maintain 100+ patches out-of-tree which includes consulting with maintainers of patches when feasible. I hack around any breakage as desired.

From my point of view, Libreboot is #1. It's "Libreboot First".

I prefer upstreaming, but for example GRUB is really bad at merging patches. It often literally taken years. So, I essentially maintain a semi-fork of GRUB, in Libreboot.

@crabmusket For example I heard some rumblings recently that the European Union is exploring the possibility of a new competitor to Star Link (which someone very wise called "FashNet").

US monopolies have got to go.

It's not just tech, it's practically everything. Take medicine for example.

Even in countries with universal healthcare, they are still using a lot of licensed American drugs that still cost a lot of money. Perhaps European and Asian markets may now produce cheaper, generic drugs.

I've used OpenWRT, and variants of it, since about 2014. I most recently purchased an ASUS TUF AX6000 and installed OpenWRT on it, to run a wireguard client; I need a fast router for encrypted VPN at 1Gbps.

OpenWRT supports *hundreds* of routers. You get a lot more fine grained control.

For example, you can better customise SQM traffic shaping e.g. Cake/fq_codel. It has nice VLAN features...

I mean. It's Linux. It's the power of Linux. They make running a Linux router easier for mere mortals.

I feel like randomly promoting a Free and Open Source Software (FOSS) project, that I use:

That project is OpenWRT, a Linux distro for routers:

https://openwrt.org/

This replaces the usual proprietary bloat, offering better customisation and security features. They also make money from selling their own preloaded router:

https://openwrt.org/toh/openwrt/one

OpenWRT is a member of Software Freedom Conservancy:

https://sfconservancy.org/projects/current/

There are others too, like pfSense and OPNsense, based on FreeBSD.

@TheyCallMeHacked They've been talking about that for ages now. I hope it merges too, and I understand their reasoning for holding off on merging the PHC patches, because they wanted to update libgcrypt instead.

But they could have merged the PHC-based patches too, the ones by Patrick Steinhardt.

It would also be nice if they'd merge Patrick Rudolf's native xHCI patches. That would be pretty cool, actually.

And merge Vladimir Serbinenko's NVMe driver - or the one Mate Kukri did independently.

Two thoughts are in my head, both equally valid:

OpenSSD port tunneling is the best thing ever. It's the reason I can do a lot of things that I do.

It's stupid that Debian's installer doesn't let you continue after partitioning when putting /boot inside an encrypted volume; you have to manually change it after the fact. Which makes sense, they want to prevent you from making an unbootable setup, right?

Except that encrypted /boot is fully bootable in Libreboot. See:

https://libreboot.org/docs/linux/grub_hardening.html

@tlaurion @mkukri also, couldn't you just use an ifdef or something? just a small patch. instead of commenting out that asl file, just add a define

if not defined (THINKPAD_T480) or something like that. i did look at the file.

hacking on top of a already admitedly hacky patch isn't ideal, but you'll just have to do it for now. heads already has a design similar to lbmk and it can easily patch whatever it wants.

@tlaurion @mkukri i keep coming to irc just as you're leaving! yes, basically the t480 patch in lbmk is in a tree where that is the only thinkpad at the moment, so it can just hack up coreboot whatever it wants. mate has told me he will tidy up the t480 patch as part of general upstreaming efforts. libreboot uses a different coreboot tree for all other thinkpads. libreboot is a multi-tree build system design, where coreboot is concerned:

https://libreboot.org/docs/maintain/

perhaps do the same in heads?

"Why read fiction, when you can read factual manpages?"

Quoted from FingerlessGloves, who said this on AAISP's IRC channel today.

I couldn't have said it better. Such profound wisdom; this has made my day.

@kaia because the screws don't anchor anything. but there would be bigger holes otherwise. the glue (2-part epoxy) stops the port from moving!

@izzy i'll probably just get lazy and do debian again

@izzy literally what i'm planning to do, though i'm considering an openbsd-based setup

@izzy yes optiplexes (libreboot). i put some realtek ethernet card i bought in the m2 wifi slot. it's on a little ribbon at the back, going to the m2 slot.

this photo shows the same sort of thing, but on a lenovo thinkcentre m920q - which i failed again tonight to get working on libreboot yet.

the wifi one (3rd pic) will be used at home for a wifi->ethernet bridge setup cuz no ethernet at home

gonna do some new tunnel routing setups and i'm experimenting with it on the optiplexes this weekend

More networking shenaginans planned for this weekend.

Zoë Kooyman really impressed me. Much more intelligent and thoughtful than her predecessor, in an email she sent me. FSF has begun linking Canoeboot on its site.

I've rewarded Zoe's courage and integrity with these Libreboot/Canoeboot website changes:

https://codeberg.org/libreboot/lbwww/commit/e484a829e39bde74806c376455ca47d6718595c0

https://codeberg.org/libreboot/lbwww/commit/40ca3087b78ad30e1309371d5319cbdf1d6de73d

https://codeberg.org/libreboot/lbwww/commit/02f623491b575a57af4db52f391a55d81dd912f7

https://codeberg.org/canoeboot/cbwww/commit/0ccecdf730bf9042c68a6ff5da5255ca28bba341

https://codeberg.org/canoeboot/cbwww/commit/0ccecdf730bf9042c68a6ff5da5255ca28bba341

https://codeberg.org/canoeboot/cbwww/commit/177b2a87b8663b061e9c6de96321835d5c2723c0

https://codeberg.org/canoeboot/cbwww/commit/8d64acfd4441cb7f3794a7b41de7c07230e4e52e

https://codeberg.org/canoeboot/cbwww/commit/66522009eb8b3cd857126d6e0153809f5725cc8e

https://codeberg.org/canoeboot/cbwww/commit/91ec37c3c2e7cb9690a3d11c714199081251c9d4

Here's to the future!

@vitali64sur no u