From Newsgroup: muc.lists.freebsd.ports

Hey there folks.
I mentioned this on the FreeBSD discord (and some of it in my BSDCan talk). IrCOve had a PR in place to generate a port that basically extracts a single binary and library from the dell Linux RPMs. Because linux-c7 is going unmaintained, this PR should probably not use the .shar files that are up there.
Yes, .shar files, because this bug is 10 years old, and that was the style at the time. I wasnrCOt the original person to open it, that was someone at the Cybersecurity firm Norse. (I think Adrian Chadd worked there), but dayjob is a very much dell shop and we use it heavily.
IrCOve redone the dance with a current version of Racadm, confirmed that this works on a FreeBSD 14.3 machine (packages are not working right now for 15, so canrCOt test there), but I havenrCOt updated the PR yet, because after ten years, I donrCOt understand why IrCOm putting forth the effort.
This is a package that installs a closed-source tool onto your servers. I am not sure what restrictions committers would want the port to have.
Desire for this comes up periodically, including for us, and IrCOm quite sad that IrCOm maintaining an Ubuntu machine, complete with systemd, to manage our iDracs.
One example of the clamoring: https://freebsd-hackers.freebsd.narkive.com/1yTOsvcA/can-we-please-finally-solve-dell-s-racadm-for-freebsd-advice-needed (7 years ago). There were comments on the bug asking what can be done a few weeks ago.
IrCOve dropped an entry on to my blog about both my experiences, and an FAQ what the differences are about the various racadm/iDrac modes of operation: https://gushi.medium.com/a-story-about-racadm-and-freebsd-95f9beaf3995
That page also tells you how to install racadm under FreeBSD without the port, if you need to, because I want it to be a comprehensive reference. I need to translate the steps there into rCLMakefilerCY, which is just a shell script with weirder formatting. But IrCOd really like to see this port/pkg go live.
===
HererCOs what I need:
1) Can someone please tell me if it makes sense to kill off this bug or start a new one, or if I should just take the hint and let this die?
2) Last I checked, poudriere had some brokenness with the Linuxulator where it would just die and report an unclean exit. If thatrCOs still broken, can I get someone to acknowledge that thatrCOs a thing and give me a pass? (It was Kurt Jaeger who told me about the issue).
3) What workflow should I use for my new submissions if I make them? PR? Github? Semafore?
4) IrCOd love to hear from a port maintainer that has a little bit of understanding about how the Linuxulator works and how Linux ports might be different with regard to shared libraries and the like. For example, if yourCOre installing a linux port, you put it in /compat/linux/usr/bin rCo do you create a symlink into /usr/local/bin as well? Questions of that nature that arenrCOt covered by the porterrCOs handbook, but probably should be.
5) Working 15 packages so I can test there.
Thanks in advance.
-Dan
--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: muc.lists.freebsd.ports

On Sep 1, 2025, at 04:29, Marcin Cieslak <saper@saper.info> wrote:

Dear Dan,

as some who has had a pull request open with some open source
project for 11 years I share your frustration.

I have you have dealt with all of the legalese stuff properly in your recent shar file.

Somewhat. When you search around for racadm license, what you get is info about how to use racadm to upload a license key file to a machine. I havenrCOt found a proper license file per-se.

In the Yocto Linux build tree of iDRAC 7.20.30.50 (available from opensource.dell.com) they download argtable 2.13 from Sourceforge
and simply build it without any change. The RPM files you have contain probably argtable 2.11 from the year 2009. But given you need
a Linux build anyway, this is of no help here.

In the blog entry I linked, I point out that dell ships a copy of argtable.

racadm seems to be embargoed, i.e. the iDRAC tree contains some binary components pre-built by Dell.

I think it perfectly makes sense to use the old bug and submit the
git diff there (as an attachment), you can also push the patch to https://reviews.freebsd.org/differential/

Probably it might be worth switching to the Red Hat 9 userland
instead of the already dead CentOS 7.

Yes, I said that as well. Also, the current port wonrCOt work with any of the current openssl stuff, so a new version needs to be pulled in.

But there is also one more possibility to deal with the Dell machines:

https://github.com/dell/iDRAC-Redfish-Scripting provides the information
how to script some functionality of iDRAC using the Redfish protocol.

There is even a guide mapping some racadm commands to the Redfish APIs available.

Yes, but most of the guides out there and a lot of the tooling out there, and *all* the dell documentation talk about racadm.
https://xkcd.com/927/

But a full racadm port can be useful anyway.. I think we are pretty
close to get this committed....

LetrCOs hope.

Marcin

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: muc.lists.freebsd.ports

On Sep 1, 2025, at 03:53, Kurt Jaeger <pi@freebsd.org> wrote:

Hi!

IrCOve had a PR in place to generate a port that basically extracts
a single binary and library from the dell Linux RPMs.

I think it is this PR:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=201799

and I looked at it in 2021. At that time it failed to build
using poudriere.

I have not found the time to look at it again since then.

I found the old conversation rCo it wasnrCOt with you, it was bdrewery. It was that poudriere tries at the end to delete files it has installed in the jail, specifically it tries to remove /compat/linux and the like as part of the cleanup step, and something with those failed because the file was in use somehow. (i.e. nothing was broken with my port, it was entirely a poudriere bug related to Linux). Brian offered a poudriere bulk command that could be used to force it to build when testport wouldnrCOt return clean at the time.
You wouldnrCOt want to use whatrCOs there, it wonrCOt dlopen a modern ssl library anyway, so at most it would run and produce some output, but would fail when you told it to connect to something. I donrCOt know if this issue is now fixed, but when I remake the makefile with linux-rl7 and modern versions of the dell RPMrCOs, werCOll find out.
This sort of relies on packages being built for 15, which theyrCOre not yet. Right now, I cannot on my 15 box do a pkg install linux_base-rl7, nothing is found.
Watch this space for more details.
-Dan--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: muc.lists.freebsd.ports

On Sep 1, 2025, at 12:03, Kurt Jaeger <pi@freebsd.org> wrote:

Hi!

You wouldnrCOt want to use whatrCOs there, it wonrCOt dlopen a modern
ssl library anyway, so at most it would run and produce some output,
but would fail when you told it to connect to something. I donrCOt
know if this issue is now fixed, but when I remake the makefile
with linux-rl7 and modern versions of the dell RPMrCOs, werCOll find
out.

The most recent version is linux-rl9, there's no linux-rl7 anymore in the ports tree -- does your patch work with rl9 ?

Yeah, that was a typo. Linux moved from linux_base-c7 (centos) to linux_base-rl9 (rocky linux). I think rl7 never existed.
The patch will work, but that racadm presently ported wonrCOt. It needs a complete redo, and I want to greatly simplify the makefile so the number of files it installs are basically two binaries, plus a few symlinks to keep hardcoded dlopens happy.
But until I can test this on my poudriere machine, which runs 15, werCOre in a holding pattern. The tests IrCOve done have been on 14.3 but theyrCOve been manual. I suspect more work in a day or three, werCOre at the mercy of the package building clusters.
-Dan

--
pi@FreeBSD.org +49 171 3101372 Now what ?

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: muc.lists.freebsd.ports

I needed a few minor tweaks to get it to pass portlint (needed to add a www line, needed to add a carriage return or two.
I hit the same error with poudriere testport:
[freebsd:14:x86:64-default_git] Fetching linux_base-rl9-9.6.pkg: 100% 59 MiB 30.9MB/s 00:02
[00:00:19] Package fetch: Using cached copy of linux_base-rl9-9.6
[00:00:19] Sanity checking the repository
[00:00:19] Checking packages for incremental rebuild needs
[00:00:19] Deleting stale symlinks... done
[00:00:19] Deleting empty directories... done
[00:00:19] Package fetch: Generating logs for fetched packages
[00:00:20] Unqueueing existing packages
[00:00:20] Unqueueing orphaned build dependencies
[00:00:20] Sanity checking build queue
[00:00:20] Processing PRIORITY_BOOST
[00:00:20] Balancing pool
[00:00:20] Recording filesystem state for prepkg... done
[00:00:20] Committing packages to repository: /usr/local/poudriere/data/packages/freebsd:14:x86:64-default_git/.real_1756772595 via .latest symlink
[00:00:20] Removing old packages
[00:00:20] Building with flags: PREFIX=/compat/linux
[00:00:20] Removing existing /compat/linux
rm: /usr/local/poudriere/data/.m/freebsd_14_x86_64-default_git/ref/compat/linux/proc: Device busy
rm: /usr/local/poudriere/data/.m/freebsd_14_x86_64-default_git/ref/compat/linux: Directory not empty
[ERROR] Unhandled error!
[00:00:20] Cleaning up
[00:00:20] Unmounting file systems
Exiting with status 1
But poudriere bulk does work, logs are here: https://poudriere-src.isc.org/build.html?mastername=freebsd%3A14%3Ax86%3A64-default_git&build=2025-09-02_00h29m45s
=====
However, when I try to build and run it on a 15.x machine, it bombs out, because racadm looks for libraries in a weird placerCa
ERROR: RAC1170: Unable to find the SSL library in the default path.
If a SSL library is not installed, install one and retry the
operation. If a SSL library is installed, create a soft-link of the
installed SSL library to "libssl.so" using the linux "ln" command
and retry the operation.
I need to go build a copy of strace to chase this down. OR it might mean that I previously contaminated my /compat/linux previously and need to clean it out.
-Dan

On Sep 1, 2025, at 16:48, Marcin Cieslak <saper@saper.info> wrote:

Dear Dan,

can you check if the port below works?

I don't have any Dell machines around but it established an SSL
connection to my port 443 successfully.

Marcin

# This is a shell archive. Save it in a file, remove anything before
# this line, and then unpack it by entering "sh file". Note, it may
# create directories; files and directories will be owned by you and
# have default permissions.
#
# This archive contains:
#
# racadm9
# racadm9/Makefile
# racadm9/pkg-plist
# racadm9/distinfo
# racadm9/pkg-descr
# racadm9/pkg-message
#
echo c - racadm9
mkdir -p racadm9 > /dev/null 2>&1
echo x - racadm9/Makefile
sed 's/^X//' >racadm9/Makefile << '747e38b00e309df20a6f016e31b0a896'
X# $FreeBSD$
X
XPORTNAME= racadm
XPORTVERSION= 11.3
XCATEGORIES= sysutils linux
XMASTER_SITES= https://linux.dell.com/repo/hardware/DSU_25.08.25/os_dependent/RHEL9_64/racadm/
XDISTNAME= srvadmin-idracadm7-11.3.0.0-795
XDISTFILES= srvadmin-argtable2-11.3.0.0-795.el9.x86_64.rpm \
X srvadmin-idracadm7-11.3.0.0-795.el9.x86_64.rpm
X XMAINTAINER= dmahoney@isc.org
XCOMMENT= Dell remote access controller admin utility
X
XLICENSE= DELL
XLICENSE_NAME= Dell Proprietary License
XLICENSE_TEXT= This program is NOT in the public domain.\
X Dell allows free downloads and mirroring of the linux RPMs this port is based on,\
X but you should read the full license here:\
X https://www.dell.com/learn/us/en/uscorp1/legal_terms-conditions_dellgrmwebpage/art-software-license-agreements\
X and determine if it is right for you or your organization.
XLICENSE_PERMS= dist-mirror no-dist-sell pkg-mirror no-pkg-sell auto-accept X
XONLY_FOR_ARCHS= amd64
XWRKSRC= ${WRKDIR}/${PORTNAME}
XNO_WRKSUBDIR= yes
X
XRUN_DEPENDS= linux_base-rl9>=0:emulators/linux_base-rl9
X
XUSE_LINUX= rl9
XUSE_LINUX_PREFIX=YES
XUSE_LINUX_RPM=YES
XNO_BUILD=YES
X
Xdo-install:
X cd ${WRKSRC}; ${CP} -pR * ${STAGEDIR}${PREFIX}
X ${RLN} ${PREFIX}/lib64/libssl.so.3 ${STAGEDIR}${PREFIX}/opt/dell/srvadmin/lib64/openmanage/private/libssl.so
X
X.include <bsd.port.mk>
747e38b00e309df20a6f016e31b0a896
echo x - racadm9/pkg-plist
sed 's/^X//' >racadm9/pkg-plist << '1cc4b16233ee29344102051bde6b0bae' Xetc/ld.so.conf.d/srvadmin-idrac7.conf
Xopt/dell/srvadmin/bin/idracadm7 Xopt/dell/srvadmin/lib64/openmanage/private/libargtable2.so.0 Xopt/dell/srvadmin/lib64/openmanage/private/libargtable2.so.0.1.6 Xopt/dell/srvadmin/lib64/openmanage/private/libssl.so Xopt/dell/srvadmin/sbin/racadm-wrapper-idrac7 Xopt/dell/srvadmin/share/man/man3/argtable.3 Xopt/dell/srvadmin/share/man/man3/argtable2.3 Xusr/lib/.build-id/ca/690910e69bfe67f0f4bd2e4b155adfcf8627d3 Xusr/lib/.build-id/51/8f7b88f8e092b14c16c3454fa89b3e0541645f Xusr/share/doc/srvadmin-argtable2/AUTHORS Xusr/share/doc/srvadmin-argtable2/COPYING Xusr/share/doc/srvadmin-argtable2/ChangeLog Xusr/share/doc/srvadmin-argtable2/README
1cc4b16233ee29344102051bde6b0bae
echo x - racadm9/distinfo
sed 's/^X//' >racadm9/distinfo << '4146598f28ba0d447745a4554e995d8b' XTIMESTAMP = 1756768563
XSHA256 (srvadmin-argtable2-11.3.0.0-795.el9.x86_64.rpm) = 1db4a3431dd6b90a668467a0e623961f8bde9d975f268f6dbb59fde10bece165
XSIZE (srvadmin-argtable2-11.3.0.0-795.el9.x86_64.rpm) = 66651
XSHA256 (srvadmin-idracadm7-11.3.0.0-795.el9.x86_64.rpm) = 9aaa86556fba84088494618d58a92d0e9ab0949eeb201ec7b0d91d17ffce9047
XSIZE (srvadmin-idracadm7-11.3.0.0-795.el9.x86_64.rpm) = 1142062 4146598f28ba0d447745a4554e995d8b
echo x - racadm9/pkg-descr
sed 's/^X//' >racadm9/pkg-descr << '60f89da3ebc0f64cfdeec27b55288bef' XLinux's cli to interface with Dell's Remote Access Controller (DRAC).
X
XThis is probably only useful in "remote" mode. 60f89da3ebc0f64cfdeec27b55288bef
echo x - racadm9/pkg-message
sed 's/^X//' >racadm9/pkg-message << '3c369757d3be1edeaff655d0e079611f'
X[
X{ type: install
X message: <<EOM
Xracadm7 has been installed under the linux "compat" tree:
X(by default, /compat/linux/opt/dell/srvadmin/bin/idracadm7) due to linux library dependencies.
X
XIt is left to the user to alias/symlink this path in their scripts.
XNote that under FreeBSD this will not work as a "local" racadm (to operate on an iDrac installed in the machine where it is run).
XEOM
X}
X]
3c369757d3be1edeaff655d0e079611f
exit

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: muc.lists.freebsd.ports

Hi!

can you check if the port below works?

I don't have any Dell machines around but it established an SSL
connection to my port 443 successfully.

Testbuild on 14.3 and 15.0 was fine.

Well, as building works, someone needs to test on a Dell box
with that stuff. Anyone ?
--
pi@FreeBSD.org +49 171 3101372 Now what ?


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: muc.lists.freebsd.ports

On Sep 2, 2025, at 12:56, Kurt Jaeger <pi@freebsd.org> wrote:

Hi!

can you check if the port below works?

I don't have any Dell machines around but it established an SSL
connection to my port 443 successfully.

Testbuild on 14.3 and 15.0 was fine.

Well, as building works, someone needs to test on a Dell box
with that stuff. Anyone ?

TLDR: Yes, and it works.
Did my last message not go through? I pasted some redacted command output where I had it query one of my personal machines. (And also detailed some weird problems with poudriere, linux, and symlinks, so it was long and I apologize if you missed it).
(Also note that any usernames/passwords I pasted in there are the dell default ones just to show the toolrCOs failure mode).
The hardware on the machine where racadm runs is inconsequential rCo this is a remote control device that speaks network protocols to a foreign idrac, and even on a modern machine running a supported OS, it would speak those same protocols to a USB network port on the same machine, if you were trying to affect the local management board.
Just like ipmitool, racadm can (on linux and windows) speak to either your local hardware, or a hardware elsewhere. On BSD, unless yourCOre talking to it on ue0, itrCOs only useful in the remote sense. I do cover this in the FAQ I wrote.
-Dan--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: muc.lists.freebsd.ports

Hi!

can you check if the port below works?

I don't have any Dell machines around but it established an SSL
connection to my port 443 successfully.

Testbuild on 14.3 and 15.0 was fine.
--
pi@FreeBSD.org +49 171 3101372 Now what ?


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: muc.lists.freebsd.ports


--Apple-Mail=_E46BEEED-B090-4201-8981-75956467E88D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=utf-8

TLDR: New .shar attached to fix a few port weirdnesses involving what =
looks like specifically a weird interaction between poudriere, the linux = emulation layer and long symlinks. I think we=E2=80=99re ready to go, =
but people should read the following.

(If the list eats the .shar, let me know and I=E2=80=99ll upload it to =
the PR).

Long Version:

So, in my initial ask to help fix this port, I asked for someone who = understands the nuances of how Linux ports especially work.

I=E2=80=99m still hitting an issue with the binaries not actually =
working correctly. The dell programs don=E2=80=99t ship a libssl.so =E2=80= =94 they try looking for it in a bunch of places, but untimately = they=E2=80=99re looking for a file called libssl.so (not libssl.so.3 or = libssl.so.3.2.2, just libssl.so).

These are not linked into the program, they=E2=80=99re dynamiclly loaded =
via dlopen() when the code needs them. (This makes it way easier for =
dell to ship a binary for lots of systems, especially without shipping =
crypto software and dynamically linking it to one exact specific =
version).

If for some reason, when I try to use this, it can=E2=80=99t find that = library, it returns this error:

[dmahoney@poudriere-src ~]$ =
/compat/linux/opt/dell/srvadmin/bin/idracadm7 -r = mgmt.oak1f.f.root-servers.org -u root -p calvin getsysinfo
ERROR: RAC1170: Unable to find the SSL library in the default path.
If a SSL library is not installed, install one and retry the
operation. If a SSL library is installed, create a soft-link of =
the
installed SSL library to "libssl.so" using the linux "ln" command
and retry the operation.

My port line has a ${RLN} block to attempt to install this, but it tries =
to be too clever, and creates a symlink to something with way too many = ../../=E2=80=99s, so much that it seems to confuse the linux =
compatibility layer (perhaps because it traverses past the filesystem =
root?)

When I strace it, the linux libraries get =E2=80=9Cno such file or = directory=E2=80=9D.

Here are the broken symlinks that are created, and the fixed symlinks =
that are created:

root@poudriere-src:/compat/linux/opt/dell/srvadmin/lib64 # ls -al
total 3
drwxr-xr-x 3 root wheel 5 Sep 2 06:48 .
drwxr-xr-x 6 root wheel 6 Sep 2 06:46 ..
lrwxr-xr-x 1 root wheel 37 Sep 2 06:48 libssl.so -> = ../../../../usr/lib64/libssl.so.3.2.2 (four .. up is /compat/linux, six =
up is /)
lrwxr-xr-x 1 root wheel 77 Sep 2 06:44 libssl.so.old -> = ../../../../../../../../../../../../../compat/linux/usr/lib64/libssl.so.3.=
2.2
drwxr-xr-x 3 root wheel 3 Sep 2 06:46 openmanage root@poudriere-src:/compat/linux/opt/dell/srvadmin/lib64 # md5 libssl.so
MD5 (libssl.so) =3D 5fc94e90aff79602689b8453d7c0909c root@poudriere-src:/compat/linux/opt/dell/srvadmin/lib64 # md5 =
libssl.so.old
MD5 (libssl.so.old) =3D 5fc94e90aff79602689b8453d7c0909c

These are links to the *SAME FILE*. One works, the other doesn=E2=80=99t,=
and I don=E2=80=99t quite understand the mechanics that the ${rln} =
function uses and why it needs to traverse 10 levels beyond the top of =
my filesystem. (I suspect it=E2=80=99s something having to do with the = staging directories as part of the build system?)

I suspect that since the port works okay if you just cd = /usr/ports/sysutils/racadm, that this is being exacerbated by =
poudriere-bulk. Poudriere creates a relative symlink that=E2=80=99s way =
too long, and the linuxulator can=E2=80=99t follow it. I might poke = bdrewery/bapt about this.

Ergo, I=E2=80=99ve changed the ${rln} in the Makefile to =E2=80=9Cln = -s=E2=80=9D. The symlink is being dropped into a directory only =
consumed by this tool, thus it only affects this one binary, and it=E2=80=99=
s a fairly safe bet that your linux install will always be located in = /compat/linux. The porter=E2=80=99s handbook says =E2=80=9Crelative =
links are strongly recommended=E2=80=9D but not =E2=80=9Crequired=E2=80=9D=
and I think I=E2=80=99ve found an edge case where you=E2=80=99d want to =
just use a real link. (I=E2=80=99ve confirmed that it=E2=80=99s =
properly created, and removed when the port=E2=80=99s removed).

=3D=3D=3D

Also, because this feels important to do, I actually had it query a =
real-life iDrac (on a personal machine):

[dmahoney@poudriere-src ~]$ =
/compat/linux/opt/dell/srvadmin/bin/idracadm7 -r x.x.x -u root -p xxxxx = getsysinfo
Security Alert: Certificate is invalid - EE certificate key too weak
Continuing execution. Use -S option for racadm to stop execution on = certificate-related errors.

RAC Information:
RAC Date/Time =3D Tue Sep 2 07:09:48 2025
[redacted]
Common settings:
Register DNS RAC Name =3D 0
DNS RAC Name =3D idrac-97GZQ22
Current DNS Domain =3D
Domain Name from DHCP =3D Disabled
[more redacted]

(For reference, this is an iDrac 7 on a dell R420 with an iDRAC =
enterprise license).

Yay!

=3D=3D=3D

The new .shar file is attached with minor changes. (One other change = =E2=80=94 I don=E2=80=99t want to use my work email for this, even if = it=E2=80=99s well-known who I work for, if god-forbid someone does =
something dumb with this, I=E2=80=99d rather not have it implicate the = dayjob).

-Dan


--Apple-Mail=_E46BEEED-B090-4201-8981-75956467E88D
Content-Disposition: attachment;
filename=racadm.shar
Content-Type: application/octet-stream;
x-unix-mode=0644;
name="racadm.shar"
Content-Transfer-Encoding: 7bit

# This is a shell archive. Save it in a file, remove anything before
# this line, and then unpack it by entering "sh file". Note, it may
# create directories; files and directories will be owned by you and
# have default permissions.
#
# This archive contains:
#
# Makefile
# distinfo
# pkg-descr
# pkg-message
# pkg-plist
#
echo x - Makefile
sed 's/^X//' >Makefile << 'b67911656ef5d18c4ae36cb6741b7965'
XPORTNAME= racadm
XPORTVERSION= 11.3
XCATEGORIES= sysutils linux
XMASTER_SITES= https://linux.dell.com/repo/hardware/DSU_25.08.25/os_dependent/RHEL9_64/racadm/
XDISTNAME= srvadmin-idracadm7-11.3.0.0-795
XDISTFILES= srvadmin-argtable2-11.3.0.0-795.el9.x86_64.rpm \
X srvadmin-idracadm7-11.3.0.0-795.el9.x86_64.rpm
X
XMAINTAINER= freebsd@gushi.org
XCOMMENT= Dell remote access controller admin utility
XWWW= https://www.dell.com/support/home/en-us/drivers/driversdetails?driverId=MFV7T
X
XLICENSE= DELL
XLICENSE_NAME= Dell Proprietary License
XLICENSE_TEXT= This program is NOT in the public domain.\
X Dell allows free downloads and mirroring of the linux RPMs this port is based on,\
X but you should read the full license here:\
X https://www.dell.com/learn/us/en/uscorp1/legal_terms-conditions_dellgrmwebpage/art-software-license-agreements\
X and determine if it is right for you or your organization. XLICENSE_PERMS= dist-mirror no-dist-sell pkg-mirror no-pkg-sell auto-accept
X
XONLY_FOR_ARCHS= amd64
XWRKSRC= ${WRKDIR}/${PORTNAME}
XNO_WRKSUBDIR= yes
X
XRUN_DEPENDS= linux_base-rl9>=0:emulators/linux_base-rl9
X
XUSE_LINUX= rl9
XUSE_LINUX_PREFIX=YES
XUSE_LINUX_RPM=YES
XNO_BUILD=YES
X
Xdo-install:
X cd ${WRKSRC}; ${CP} -pR * ${STAGEDIR}${PREFIX}
X ln -s /compat/linux/usr/lib64/libssl.so.3.2.2 ${STAGEDIR}${PREFIX}/opt/dell/srvadmin/lib64/libssl.so
X
X.include <bsd.port.mk>
b67911656ef5d18c4ae36cb6741b7965
echo x - distinfo
sed 's/^X//' >distinfo << '57677d168a5ec21bdf22c9501f075a8f'
XTIMESTAMP = 1756768563
XSHA256 (srvadmin-argtable2-11.3.0.0-795.el9.x86_64.rpm) = 1db4a3431dd6b90a668467a0e623961f8bde9d975f268f6dbb59fde10bece165
XSIZE (srvadmin-argtable2-11.3.0.0-795.el9.x86_64.rpm) = 66651
XSHA256 (srvadmin-idracadm7-11.3.0.0-795.el9.x86_64.rpm) = 9aaa86556fba84088494618d58a92d0e9ab0949eeb201ec7b0d91d17ffce9047
XSIZE (srvadmin-idracadm7-11.3.0.0-795.el9.x86_64.rpm) = 1142062 57677d168a5ec21bdf22c9501f075a8f
echo x - pkg-descr
sed 's/^X//' >pkg-descr << '7f9555c3c1089940396b503dd37f3979'
XLinux's cli to interface with Dell's Remote Access Controller (DRAC).
X
XThis is probably only useful in "remote" mode. 7f9555c3c1089940396b503dd37f3979
echo x - pkg-message
sed 's/^X//' >pkg-message << '90c81c06929c43140502a9f17b449376'
X[
X{ type: install
X message: <<EOM
Xracadm7 has been installed under the linux "compat" tree:
X(by default, /compat/linux/opt/dell/srvadmin/bin/idracadm7) due to linux library dependencies.
X
XIt is left to the user to alias/symlink this path in their scripts.
XNote that under FreeBSD this will not work as a "local" racadm (to operate on an iDrac installed in the machine where it is run).
XEOM
X}
X]
90c81c06929c43140502a9f17b449376
echo x - pkg-plist
sed 's/^X//' >pkg-plist << '842cde48cf18b70a11b15515ca566742' Xetc/ld.so.conf.d/srvadmin-idrac7.conf
Xopt/dell/srvadmin/bin/idracadm7 Xopt/dell/srvadmin/lib64/openmanage/private/libargtable2.so.0 Xopt/dell/srvadmin/lib64/openmanage/private/libargtable2.so.0.1.6 Xopt/dell/srvadmin/lib64/libssl.so Xopt/dell/srvadmin/sbin/racadm-wrapper-idrac7 Xopt/dell/srvadmin/share/man/man3/argtable.3 Xopt/dell/srvadmin/share/man/man3/argtable2.3 Xusr/lib/.build-id/ca/690910e69bfe67f0f4bd2e4b155adfcf8627d3 Xusr/lib/.build-id/51/8f7b88f8e092b14c16c3454fa89b3e0541645f Xusr/share/doc/srvadmin-argtable2/AUTHORS Xusr/share/doc/srvadmin-argtable2/COPYING Xusr/share/doc/srvadmin-argtable2/ChangeLog Xusr/share/doc/srvadmin-argtable2/README
842cde48cf18b70a11b15515ca566742
exit


--Apple-Mail=_E46BEEED-B090-4201-8981-75956467E88D
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
charset=us-ascii

On Sep 1, 2025, at 22:38, Kurt Jaeger <pi@freebsd.org> wrote:

Hi!

can you check if the port below works?

I don't have any Dell machines around but it established an SSL
connection to my port 443 successfully.

Testbuild on 14.3 and 15.0 was fine.

--
pi@FreeBSD.org +49 171 3101372 Now what ?

--Apple-Mail=_E46BEEED-B090-4201-8981-75956467E88D--


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: muc.lists.freebsd.ports

On Sep 2, 2025, at 15:54, Marcin Cieslak <saper@saper.info> wrote:

On Tue, 2 Sep 2025, Dan Mahoney (Ports) wrote:

TLDR: New .shar attached to fix a few port weirdnesses involving what looks like specifically a weird interaction between poudriere, the linux emulation layer and long symlinks. I think werCOre ready to go, but people should read the following.

You .shar file had Windows CRLF at the end.

My bad, because you sent it in-line, I just copy-pasted into the shell. YourCOve also rewritten the symlink back to relative, and itrCOs working for you, but not for me, and I canrCOt figure out why.

I have also installed linux-rl9-ca-certificates package.

Since I don't have any iDRAC, I have tested it via

# /compat/linux/opt/dell/srvadmin/bin/idracadm7 -r localhost getsysinfo

connecting to "openssl s_server -port 443 -key key -cert cert" running on localhost

given that my certificate is signed by Let's Encrypt,
I get no warnings from racadm and the SSL connection is established.

That strange relative symbolic link seeps to work:

I am sure it didnrCOt previously, but letrCOs see what happens when I build this with poudriere bulkrCa.
No. It doesnrCOt work.
[dmahoney@poudriere-src ~]$ /compat/linux/opt/dell/srvadmin/bin/idracadm7 -r ... -u root -p apassword getsysinfo
ERROR: RAC1170: Unable to find the SSL library in the default path.
If a SSL library is not installed, install one and retry the
operation. If a SSL library is installed, create a soft-link of the
installed SSL library to "libssl.so" using the linux "ln" command
and retry the operation.
HererCOs some strace output that shows it searching for the libraries: openat(AT_FDCWD, "/opt/dell/srvadmin/lib64/libssl.so.1.0.1e", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/opt/dell/srvadmin/lib64/openmanage/private/libssl.so.1.0.1e", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=9927, ...}) = 0
mmap(NULL, 9927, PROT_READ, MAP_PRIVATE, 3, 0) = 0x800548000
close(3) = 0
openat(AT_FDCWD, "/lib64/glibc-hwcaps/x86-64-v2/libssl.so.1.0.1e", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
newfstatat(AT_FDCWD, "/lib64/glibc-hwcaps/x86-64-v2", 0x7fffffff2940, 0) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/lib64/tls/x86_64/x86_64/libssl.so.1.0.1e", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
newfstatat(AT_FDCWD, "/lib64/tls/x86_64/x86_64", 0x7fffffff2940, 0) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/lib64/tls/x86_64/libssl.so.1.0.1e", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
newfstatat(AT_FDCWD, "/lib64/tls/x86_64", 0x7fffffff2940, 0) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/lib64/tls/x86_64/libssl.so.1.0.1e", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
newfstatat(AT_FDCWD, "/lib64/tls/x86_64", 0x7fffffff2940, 0) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/lib64/tls/libssl.so.1.0.1e", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
newfstatat(AT_FDCWD, "/lib64/tls", 0x7fffffff2940, 0) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/lib64/x86_64/x86_64/libssl.so.1.0.1e", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
newfstatat(AT_FDCWD, "/lib64/x86_64/x86_64", 0x7fffffff2940, 0) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/lib64/x86_64/libssl.so.1.0.1e", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
newfstatat(AT_FDCWD, "/lib64/x86_64", 0x7fffffff2940, 0) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/lib64/x86_64/libssl.so.1.0.1e", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
newfstatat(AT_FDCWD, "/lib64/x86_64", 0x7fffffff2940, 0) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/lib64/libssl.so.1.0.1e", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
newfstatat(AT_FDCWD, "/lib64", {st_mode=S_IFDIR|0755, st_size=210, ...}, 0) = 0 openat(AT_FDCWD, "/usr/lib64/glibc-hwcaps/x86-64-v2/libssl.so.1.0.1e", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
newfstatat(AT_FDCWD, "/usr/lib64/glibc-hwcaps/x86-64-v2", 0x7fffffff2940, 0) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/lib64/tls/x86_64/x86_64/libssl.so.1.0.1e", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
newfstatat(AT_FDCWD, "/usr/lib64/tls/x86_64/x86_64", 0x7fffffff2940, 0) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/lib64/tls/x86_64/libssl.so.1.0.1e", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
newfstatat(AT_FDCWD, "/usr/lib64/tls/x86_64", 0x7fffffff2940, 0) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/lib64/tls/x86_64/libssl.so.1.0.1e", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
newfstatat(AT_FDCWD, "/usr/lib64/tls/x86_64", 0x7fffffff2940, 0) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/lib64/tls/libssl.so.1.0.1e", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
newfstatat(AT_FDCWD, "/usr/lib64/tls", 0x7fffffff2940, 0) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/lib64/x86_64/x86_64/libssl.so.1.0.1e", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
newfstatat(AT_FDCWD, "/usr/lib64/x86_64/x86_64", 0x7fffffff2940, 0) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/lib64/x86_64/libssl.so.1.0.1e", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
newfstatat(AT_FDCWD, "/usr/lib64/x86_64", 0x7fffffff2940, 0) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/lib64/x86_64/libssl.so.1.0.1e", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
newfstatat(AT_FDCWD, "/usr/lib64/x86_64", 0x7fffffff2940, 0) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/lib64/libssl.so.1.0.1e", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
newfstatat(AT_FDCWD, "/usr/lib64", {st_mode=S_IFDIR|0755, st_size=210, ...}, 0) = 0
munmap(0x800548000, 9927) = 0
openat(AT_FDCWD, "/opt/dell/srvadmin/lib64/libssl.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/opt/dell/srvadmin/lib64/openmanage/private/libssl.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=9927, ...}) = 0
mmap(NULL, 9927, PROT_READ, MAP_PRIVATE, 3, 0) = 0x800548000
close(3) = 0
openat(AT_FDCWD, "/lib64/libssl.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/lib64/libssl.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
munmap(0x800548000, 9927) = 0
brk(0x551000) = 0x551000
write(2, "ERROR: RAC1170: Unable to find t"..., 318ERROR: RAC1170: Unable to find the SSL library in the default path.
If a SSL library is not installed, install one and retry the
operation. If a SSL library is installed, create a soft-link of the
installed SSL library to "libssl.so" using the linux "ln" command
and retry the operation.) = 318
write(2, "\n", 1
) = 1
brk(0x541000) = 0x541000
exit_group(12 <unfinished ...>
+++ exited with 12 +++
The line where it looks at openat(AT_FDCWD, "/opt/dell/srvadmin/lib64/openmanage/private/libssl.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) *should* find it, but something about that symlink (on my system, at least) fails, and it *doesnrCOt* with a non-relative symlink.
And I am not sure why.
What version of the OS are you running, what version of poudriere, and how are you building?
[dmahoney@poudriere-src ~]$ poudriere version
poudriere-git-3.4.2
[dmahoney@poudriere-src ~]$ uname -a
FreeBSD poudriere-src.isc.org 15.0-PRERELEASE FreeBSD 15.0-PRERELEASE #0 main-n279782-b6ea2513f776: Thu Aug 21 20:52:52 UTC 2025 dmahoney@poudriere-src.isc.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64
This also breaks on my 14.x system (with a poudriere build on the 15.x system, but with a 14.x build jail):
root@srt:/home/dmahoney # /compat/linux/opt/dell/srvadmin/bin/idracadm7 -r localhost -u root -p xxx getsysinfo
ERROR: RAC1170: Unable to find the SSL library in the default path.
If a SSL library is not installed, install one and retry the
operation. If a SSL library is installed, create a soft-link of the
installed SSL library to "libssl.so" using the linux "ln" command
and retry the operation.
root@srt:/home/dmahoney # uname -a
FreeBSD srt.isc.org 14.3-RELEASE FreeBSD 14.3-RELEASE releng/14.3-n271432-8c9ce319fef7 GENERIC amd64
Would you care to pass me a copy of a .pkg yourCOve built on 14.x or 15.x for science? IrCOll happily spin up a new VM.
Alternatively, my packages are at: https://poudriere-src.isc.org/packages/main-default_git/All/ (15.x) or https://poudriere-src.isc.org/packages/freebsd:14:x86:64-default_git/All/ (14.x) if yourCOd like to see if they break for you.
-Dan

# find /compat/linux -name 'libssl*' -ls
599103 1266 -rwxr-xr-x 1 root wheel 1023516 Feb 11 2025 /compat/linux/usr/lib/libssl.so.3.2.2
599102 1 lrwxr-xr-x 1 root wheel 15 Feb 11 2025 /compat/linux/usr/lib/libssl.so.3 -> libssl.so.3.2.2
599722 1161 -rwxr-xr-x 1 root wheel 957488 Feb 11 2025 /compat/linux/usr/lib64/libssl.so.3.2.2
599721 1 lrwxr-xr-x 1 root wheel 15 Feb 11 2025 /compat/linux/usr/lib64/libssl.so.3 -> libssl.so.3.2.2
603089 1 lrwxr-xr-x 1 root wheel 83 Sep 2 22:48 /compat/linux/opt/dell/srvadmin/lib64/openmanage/private/libssl.so -> ../../../../../../../../../../../../../../../compat/linux/usr/lib64/libssl.so.3.2.2<racadm3.shar>

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: muc.lists.freebsd.ports

On Sep 2, 2025, at 18:05, Marcin Cieslak <saper@saper.info> wrote:

On Tue, 2 Sep 2025, Dan Mahoney (Ports) wrote:

On Sep 2, 2025, at 17:15, Marcin Cieslak <saper@saper.info> wrote:

find /compat/linux -name 'libssl*' -ls

root@poudriere-pkb:/home/dmahoney # find /compat/linux -name 'libssl*' -ls >> 227550 1201 -rwxr-xr-x 1 root wheel 957488 Feb 11 2025 /compat/linux/usr/lib64/libssl.so.3.2.2
227549 1 lrwxr-xr-x 1 root wheel 15 Feb 11 2025 /compat/linux/usr/lib64/libssl.so.3 -> libssl.so.3.2.2
226805 1 lrwxr-xr-x 1 root wheel 15 Feb 11 2025 /compat/linux/usr/lib/libssl.so.3 -> libssl.so.3.2.2
226806 1305 -rwxr-xr-x 1 root wheel 1023516 Feb 11 2025 /compat/linux/usr/lib/libssl.so.3.2.2
241928 1 lrwxr-xr-x 1 root wheel 83 Sep 2 23:17 /compat/linux/opt/dell/srvadmin/lib64/openmanage/private/libssl.so -> ../../../../../../../../../../../../../../../compat/linux/usr/lib64/libssl.so.3.2.2

And it does not stat? Maybe there is some another symbolic link accross the tree...
What does the realpath say>

Realpath works:
root@poudriere-pkb:/etc/pkg # realpath /compat/linux/opt/dell/srvadmin/lib64/openmanage/private/libssl.so
/compat/linux/usr/lib64/libssl.so.3.2.2
And again, if I use something like md5 (ignoring weaknesses in md5) it shows the same checksum as /compat/linux/usr/lib64/libssl.so.3.2.2
HererCOs my current mysteries:
1) Why am I hitting this and you arenrCOt?
2) Why does the hard link work and this not?
3) Why does it work if I add the *correct* number of ../?
-Dan
--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: muc.lists.freebsd.ports

Marcin or Kurt,
Can one of you please try using our most current shar to do a pkg build so I can test? IrCOd like to eliminate any weirdness with my own poudriere setup. I have a dell machine and can test on either 14 or 15 amd64.
-Dan

On Sep 2, 2025, at 18:21, Dan Mahoney (Ports) <freebsd@gushi.org> wrote:

On Sep 2, 2025, at 18:05, Marcin Cieslak <saper@saper.info> wrote:

On Tue, 2 Sep 2025, Dan Mahoney (Ports) wrote:

On Sep 2, 2025, at 17:15, Marcin Cieslak <saper@saper.info> wrote:

find /compat/linux -name 'libssl*' -ls

root@poudriere-pkb:/home/dmahoney # find /compat/linux -name 'libssl*' -ls >>> 227550 1201 -rwxr-xr-x 1 root wheel 957488 Feb 11 2025 /compat/linux/usr/lib64/libssl.so.3.2.2
227549 1 lrwxr-xr-x 1 root wheel 15 Feb 11 2025 /compat/linux/usr/lib64/libssl.so.3 -> libssl.so.3.2.2
226805 1 lrwxr-xr-x 1 root wheel 15 Feb 11 2025 /compat/linux/usr/lib/libssl.so.3 -> libssl.so.3.2.2
226806 1305 -rwxr-xr-x 1 root wheel 1023516 Feb 11 2025 /compat/linux/usr/lib/libssl.so.3.2.2
241928 1 lrwxr-xr-x 1 root wheel 83 Sep 2 23:17 /compat/linux/opt/dell/srvadmin/lib64/openmanage/private/libssl.so -> ../../../../../../../../../../../../../../../compat/linux/usr/lib64/libssl.so.3.2.2

And it does not stat? Maybe there is some another symbolic link accross the tree...
What does the realpath say>

Realpath works:

root@poudriere-pkb:/etc/pkg # realpath /compat/linux/opt/dell/srvadmin/lib64/openmanage/private/libssl.so
/compat/linux/usr/lib64/libssl.so.3.2.2

And again, if I use something like md5 (ignoring weaknesses in md5) it shows the same checksum as /compat/linux/usr/lib64/libssl.so.3.2.2

HererCOs my current mysteries:

1) Why am I hitting this and you arenrCOt?

2) Why does the hard link work and this not?

3) Why does it work if I add the *correct* number of ../?

-Dan

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: muc.lists.freebsd.ports

Hi!

While I'm very glad you're doing this work (thank you!) Would you mind providing something other than a .shar (that's quite "old-school" and no longer suggested.) Maybe a git diff? Or, really, any diff/patch would be easier to test with these days (at least for me.)

The format of the patch should be the least of our problems 8-}
--
pi@FreeBSD.org +49 171 3101372 Now what ?


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: muc.lists.freebsd.ports

I didn't read the whole thread, sorry upfront. Just want to point out that
1. poudriere-devel now handle linuxulator ports correctly
2, Some care should be taken to make Linux binaries act on
${LINUXBASE} rather than native files. I mainly talk about the FS
paths resolution algorithm there.
3. Symlinks are the pain and should be treated with extreme care.
Here's an example that took me a while to fix properly: https://github.com/freebsd/freebsd-ports/blob/6b4bc2602018ec1d81800bb1fb22ef55fc0b814c/security/linux-rl9-ca-certificates/Makefile#L60-L63

Let me know if you still have a problem with your port and need help with that.


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: muc.lists.freebsd.ports

On Sep 4, 2025, at 23:01, Gleb Popov <arrowd@freebsd.org> wrote:

I didn't read the whole thread, sorry upfront. Just want to point out that
1. poudriere-devel now handle linuxulator ports correctly
2, Some care should be taken to make Linux binaries act on
${LINUXBASE} rather than native files. I mainly talk about the FS
paths resolution algorithm there.
3. Symlinks are the pain and should be treated with extreme care.
Here's an example that took me a while to fix properly: https://github.com/freebsd/freebsd-ports/blob/6b4bc2602018ec1d81800bb1fb22ef55fc0b814c/security/linux-rl9-ca-certificates/Makefile#L60-L63

Let me know if you still have a problem with your port and need help with that.

Okay. I originally read the -devel in poudriere-devel as sort of rCLbetarCY but itrCOs pretty clear that itrCOs what I should be using. (Maybe the porterrCOs handbook should recommend this, in case a person hits a problem).
Are the various hoops the linuxulator jumps through to resolve things documented somewhere? Right now this is a black box to me.
-Dan--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: muc.lists.freebsd.ports

On Sep 4, 2025, at 22:22, Janky Jay, III <jankyj@unfs.us> wrote:

Hi Dan,

While I'm very glad you're doing this work (thank you!) Would you mind providing something other than a .shar (that's quite "old-school" and no longer suggested.) Maybe a git diff? Or, really, any diff/patch would be easier to test with these days (at least for me.)

https://users.isc.org/~dmahoney/racadm.tar.gz
Untar to ports/sysutils and test the build. If yourCOre getting what IrCOm getting, racadm will run but will print an error telling you to create a symlink to libssl.so, even though it seems to exist.
-Dan

On 9/4/25 10:05PM, Dan Mahoney (Ports) wrote:

Marcin or Kurt,

Can one of you please try using our most current shar to do a pkg build so I can test? IrCOd like to eliminate any weirdness with my own poudriere setup. I have a dell machine and can test on either 14 or 15 amd64.

-Dan

Regards,
Janky Jay, III

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de
--- Synchronet 3.21a-Linux NewsLink 1.2