share.icloud.com/photos/039JzB1oLFocCfHEV2ShkJ8OA whole 205MB :)

tsoome, wow, my first impression now was a pressure cooker ;) Anyway, about uefi smbios address I am here to see to debug it, when rmustacc available.

nikolam are the smbios.* entries present in output of tr '\0' '\n' < /system/boot/environment ?

tsoome, mega.nz/file/od8EATpB#HAJFbnrZIMnf629VNTrOyuYO_wVOW5vyPEhbrweuJI0

could you use the tr command ?:)

smbios.system.uuid=a1d11000-ee9b-11e1-0000-24be051f4a38 is listed there.

aha ia see, tsoome mega.nz/file/NZViRYLL#XoQ9JP-zZSKSttvzIItStp11OzKzTEsDw8LCEbtCkjA

yet, sysinfo says, "UUID": "",

well, it means, the bootloader was able to get this data, so it is there and present, but somehow we fail to either find or inpterpret it with os tools.

os tools got to be getting info directly .. or through kernel. Maybe os tools have older code and loader has a newer one

tsoome: I know I've used a VAX with an RA60 in the late 1980's (but most of the systems there were set up with non-removable RA80 & RA81 disks)

jperkin: does it matter for building a new package if the latest lts or trunk is used?

jbk: depends if it has newer dependency requirements, if it's mostly standalone then you can probably get away with either

it requires various autotools, but the only runtime dependency is json-c which appears to be in pkgsrc since at least 2021 (probably earlier)

2012 yeh

specifically i wanted to get tpm2-tss in there

it requires a few patches to build on illumos

which i've done

(hopefully they can get upstream at some point, but i'll worry about that later)

ok cool, happy to review and commit once you have something

should adding the url2pkg package be done inside or outside the sandbox?

I'd do everything inside

hrm.. configure is failing with the automatic dependency tracking.. which seems to be explicitly enabled when called.. it looks like maybe it needs gmake as a build dependency (the configure script is running sed on Makefile and piping it to make, and the resulting (massive) makefile is failing

does adding teh buildlink includes sort out both build and runtime dependencies?

buildlink is for headers/libraries and will ensure they are runtime dependencies (unless BUILDLINK_DEPMETHOD=build but that's not recommended)

things like gmake are done via USE_TOOLS

ahh ok....

that worked

thanks

now it's to the point where I can apply my patches

the biggest one is the lack of file types with struct dirent.. it sucks I don't think there's a way to fix that w/o breaking ABI compat

(so patch works around that w/ calling stat(2))

jbk: Hmm. Maybe a new open flag for directories that selects a different dirent structure.

Is anyone else having problems pushing to gerrit?

or squeeze a flag into the getdents() syscall signature to indicate "new dirent" (in the high order bits of the length, perhaps?)

or get everyone to migrate to posix_getdents() instead

See pg 50 of opengroup.org/austin/docs/austin_1110.pdf

and of course, someone would have to add that to your libc first

jbk: anything that uses d_type should be prepared for an UNKNOWN type to be returned, though - if the type is not UNKNOWN you can rely on it but you should be prepared to stat anyway..

this code (tpm2-tss) is basically looking for either regular files or directories

right. on some systems that have d_type, you might get DT_UNKNOWN in some directories (not all filesystems might support d_type, and not all filesystems may have the information populated in all directories)

if you get DT_REG, you've got a file, If you get DT_UNKNOWN, you might have a file, or a directory, or something else, so you have to stat if you get DT_UNKNOWN

hrm.. somehow the pkgsrc is invoking libtool thats making it try to symlink itself..