at first look, i can make some suggestions

• there is no parabola port for 'aarch64'; so {libre,}makepkg would never use it - it would be useful only on an archlinuxarm system

• regarding the license, 'GPL2' means GPL2-only - if it is GPL2-or-later, use 'GPL'

• 'make' and 'gcc' do not need to be in makedepends - those are included in base-devel - the arch convention/policy is that all PKGBUILDs assume 'base' and 'base-devel' to be installed - base-devel is always installed in librechroots

WRT BR #2885 - should this package be a dependency of 'tp_smapi' and 'tp_smapi-lts' ? - #2885 suggests that it is essential for them (broken without it)

or vice-versa? - does this program expect that one of 'tp_smapi' or 'tp_smapi-lts' is installed ?

GPL2 is intentional.
I'll fix the rest later today and update it.

is there any relationship with 'tp_smapi', or does this program replace some functionality of 'tp_smapi'?

if they cooperate, one or both may be optdepends of the other, even if they are not essential to one another

They're incompatible:
tp-smapi requires that the SMAPI be implemented, which Coreboot doesn't implement.
Conversely, ectool is almost useless for a system that doesn't run (some distro of) Coreboot.

if the other tools are made from the same sources (https://coreboot.org/releases/coreboot-${pkgver}.tar.xz), it would be best as one single split-package PKGBUILD

see /usr/share/pacman/PKGBUILD-split.proto

some notes:

WRT pkgrel:¶

pkgrel=1.parabola${PARABOLA_RELEASE_COUNT}

PKGBUILDS should not depend on anything in the local environment - PARABOLA_RELEASE_COUNT is guaranteed to be undefined in librechroots

the '.parabola' extension to pkgrel is to indicate a replacement for a package in arch - replacement packages would never be in the PCR repo - for a PCR package, pkgrel is a single number:

pkgrel=1

like 'make' and 'gcc' before, 'pciutils' does not need to be in makedepends - pciutils is included in base - the arch convention/policy is that all PKGBUILDs may assume 'base' and 'base-devel' to be installed - 'base' and 'base-devel' are always installed in librechroots

WRT source filenames:¶

source=("coreboot-${pkgver}.tar.gz::https://coreboot.org/releases/coreboot-${pkgver}.tar.xz")

there are two thing wrong with that line - the filename preceding '::' is needed only when it is desired to rename the downloaded file - tarballs from github for example, either do not indicate the project name, or do not indicate the version - every one of them will be named like: foo-master.tar.gz or v0.1.2.tar.gz -
that makes it very difficult to distinguish from others in the sources cache, or simply over-writes the last downloaded github file with the same (non-unique) filename

in this case, the name of the file being downloaded is: coreboot-4.15.tar.xz, which is uniquely identifiable; so there is no reason to rename it

secondly, it is being renamed from .xz to .gz, which is technically incorrect

did you try building this for i686? - it fails to build for me

that is not a 32bit build - AFAIK, linux32 (setarch) only tricks the environment into believing that a foreign-arch kernel is running - it would not cross-compile for a foreign arch - there is a big difference, which this situation is illuminating

you can verify that yourself by interrogating the binary

$ linux32 makepkg -sr
$ file pkg/coreboot-util/usr/bin/ectool
pkg/coreboot-util/usr/bin/ectool: ELF 64-bit LSB pie executable, x86-64, ....

also, the filename of the produced package is coreboot-util-4.15-1-x86_64.pkg.tar.xz; librerelease would put it in the x86_64 repo - but even if it were installed on a i686 system, it would not run, because it is a 64bit binary

anything that is destined for the parabola repos, must be built with libretools; so we attempt to ensure that is possible, or to leave a 'FIXME:' note in the PKGBUILD, describing the failure

create an i686 chroot:

$ sudo librechroot -n i686 -A i686 make

$ sudo libremakepkg -n i686

bear in mind that arch32 is less than perfect - some of the dependencies will be in a non-standard repos: testing, staging or build-support; and often a build will need to downgrade a dependency manually from the archive - usually one of those combinations will work; but there is often nothing we can do about failures, other than report them to arch32

iceweasel is one example currently (and anything else written in rust) - the current i686 rust package is useless - v96 was the last version that i was able to compile - in other words, with i686 and armv7h, give it a reasonable try, but dont try too hard

it looks like there are multiple versions of the EC firmware to consider - is this compatible with the firmware upgrade mentioned on the libreboot website (and whatever version it was replacing)?

https://libreboot.org/docs/hardware/#ec-update-on-i945-x60-t60-and-gm45-x200-x301-t400-t500-r400-w500-r500

When it comes to i686 and armv7h, I'll give it a shot now.
And as for the EC firmware itself, there are two distinctions to be made here:
On the x86 targets supported by Libreboot, all EC firmware is proprietary, but can only be updated through the official proprietary BIOS only anyway, in effect, once the machine has Libreboot installed that firmware is basically stuck in ROM, to quote from the RYF guidelines:
"However, there is one exception for secondary embedded processors. The exception applies to software delivered inside auxiliary and low-level processors and FPGAs, within which software installation is not intended after the user obtains the product. This can include, for instance, microcode inside a processor, firmware built into an I/O device, or the gate pattern of an FPGA. The software in such secondary processors does not count as product software."
https://ryf.fsf.org/about/criteria

ECtool merely provides a free as in freedom way to interface with that code, much like one can say that an HDD's or SSD's firmware is proprietary but the Linux (Libre) kernel still provides an interface (in this case over SATA) to that firmware.
ECtool does not allow updating or replacing said firmware, and as such in no way does it aid in the installation of potentially non-free software.

ok thats progress - i deleted the source package - we need to
work on either using the libreboot sources, or pre-cleaning the
coreboot sources in a mksource() function

if that takes too long, we should pull the binary package too;
because we really should not have it without sources

Hi,

Thanks a lot for the work on this package.

Before merging the PKGBUILD, it would be easier for us if you could attach a git patch (This can be done with git format-patch -1). This way we could have the proper authorship and so on in the patch.

Since the various utilities are independent but come from the same source release, if it's easy for you, it would be a good idea to split the utilities in several packages inside that PKGBUILD. If not it can also be done later on in subsequent patches.

Splitting in various packages would also enable to upgrade from the nvramtool package I made to the nvramtool built from your package more easily. For that you'll also need to increase the pkgrel from 1 to 2 and to delete the nvramtool PKGBUILD in your patch. This way people and 'git show' will also understand that the coreboot-utils PKGBUILD is the "next version" of the nvramtool PKGBUILD.

In addition, splitting packages would also allow to have more precise licensing information (if PKGBUILDs support that): all the packaged utilities but superiotool are GPLv2-only. superiotools is GPLv2-or-later. So if adding a license in a package works, it would be nice to have that change too.

In addition some of the utilities like me_cleaner or bucts have several upstreams: me_cleaner is available both on github in a separate repository and in Coreboot. Bucts is also available separately. So if we need to change upstream later on, having split packages would make the upgrade totally transparent.

Denis.

edit1: added rationale with me_cleaner

wael wrote:
[...]

Sidenote: the upstream URL is pulled from Libreboot's testing release but the packaged software is stable, "testing" in this case refers to Libreboot's ROMs (which we aren't dealing with here).

It's also possible to send patches in Libreboot upstream to add support for releasing a deblobbed coreboot tarball. For instance we could have one tarball for each coreboot release in the same spirit of what linux-libre does. I did something similar for u-boot as Libreboot is also interested in using u-boot for supporting some computers.

The downside of going that route is that not only it would probably take a lot more time and work but also, if instead we stick to the Libreboot releases that people are using, it increases a lot the probability of having the tools work well with these Libreboot releases.

And supporting Libreboot well is more important than supporting Coreboot well.

That makes me think that having this package named libreboot-utils instead of coreboot-utils would make that more clear.

Supporting both could also be done but it would increase a lot the complexity and the time and work needed.

edit1: added rename

if this package produces the same 'nvramtool' binary, then it
is the obvious option to delete the 'nvramtool' package; but
i would not be too concerned with the upgrade path - the
'nvramtool' package is only a few days old - it is not likely
that anyone knows it exists yet

otherwise, we end up carrying a 'replaces' entry that will
probably never be removed

a split package was considered - i suggested not doing it, only
for simplicity - this package is also very new - we could just
split it without any 'replaces' or 'provides' litter

i think the priority here is to get it to build from pre-cleaned
sources

im not sure if wael is comfortable with git - the pagure repo
could also be used though - whatever workflow is best for the
packager, is fine by me - if even just dumping another PKGBUILD
to this ticket

im not sure if wael is comfortable with git - the pagure repo could also be used though - whatever workflow is best for the packager, is fine by me - if even just dumping another PKGBUILD to this ticket

Supporting both could also be done but it would increase a lot the complexity and the time and work needed.

which reminds me, i forgot to mention that having multiple packages, built from the same sources, doubles the disk space used in the repos - that is the best reason to merge the PKGBUILDs (and to choose only one of libreboot or coreboot)

I agree with bill-auger on the splitting part, these binaries are all inter-related anyway (chances are, if you use one you're going to use the others), the only exception is bucts (it is x60(s)/t60(s) specific) but that is small anyway.
If you want I can post a git patch of the PKGBUILD to the mailing list.

If you want I can post a git patch of the PKGBUILD to the mailing list.

Yes, that would be great.

As for the upgrade path, I also agree with bill auger. I also wanted to avoid keep custom (replace= conflict=) code forever.

As for splitting the package, while I find it useful, it can also be done later on.

I may give it a try at some point if I can find the time.

libreboot-util is in pcr now - please do try it out

if it has a problem on one arch you can still build it for the other arches

[[ "${CARCH}" != i686 ]] && do_something

case "${CARCH}" in
armv7h) do_something
#i686)  do_nothing   # this is broken today
x86_64) do_something_else_maybe
done

i dont care how the patches come in - i watch everything - gnutoo asked for it on the mailing list - i thought he was going to review it - the package is already published now so theres no urgency

just let me know if the package in libre is good; and the ticket can be closed - i have a thinkpad but i dont know how to use these tools to test them - would these be useful for a T500 ?

try to work on deleting as much of the unused sources as possible - it may be easy - take your time - i dont know how often libreboot releases; but youd have at least that much time before a new PKGBUILD would be needed

I tested the package that's currently in the repos, all seems fine.
As for usefulness for a T500: if it is currently librebooted/corebooted, then ectool can be used to directly communicate with the EC (instead of using SM-API, which coreboot doesn't implement), I've detailed some examples in the Wiki (T400 article).
Some of the stuff that can be done through that is setting charge thresholds, toggling the thinklight on and off (I use it in a notification script for example), or changing mute button status.
The rest of the tools are more specific for certain tasks: nvramtool for changing data in the NV-RAM, cbfstool for modifying the CoreBoot File System within a Coreboot ROM, superiotool for detecting and modifying superio ports, and bucts is strictly useful for X60 ThinkPads as far as I can tell (needed to flash a modified ROM, e.g.: when installing/upgrading Libreboot).
As for the sources, I added a few lines that attempt to remove payloads, board configs and docs (all useless for this package's purpose), but I'll check later if I can just do a sparse clone from Libreboot sources, though it isn't very straightforward as there are some inter-dependencies (otherwise I would've just left the util directory and deleted everything else).

I'm adding this here even though it might warrant a different thread down the road:
https://notabug.org/osboot/nvmutil
As this should allow one to more easily set a libreboot/coreboot system.