@jrm, reasonable points. Thank you!

Builds for me as well. Will commit to main.

I am still waiting for qt6-webengine-6.11.1 to complete...

In D56835#1321082, @vsasjason_gmail.com wrote:

Will it help sshd to start without being indefinitely blocked by e.g. mysqld? That would be enough of a reason for me personally to switch to this thing immediately.

GUI does not configure for me, qmake is missing:

===>  Configuring for seafile-gui-9.0.18_1
===>  Performing out-of-source build
/bin/mkdir -p /wrkdirs/usr/ports/net-mgmt/seafile-gui/work/.build
CMake Deprecation Warning at CMakeLists.txt:1 (CMAKE_MINIMUM_REQUIRED):
  Compatibility with CMake < 3.10 will be removed from a future version of
  CMake.

In D57610#1321001, @d.stoye_cms.hu-berlin.de wrote:

update metadata

Can you fix metadata on your patch while I am running in poudriere: Author: Charlie Root <root@bsdell.fritz.box>?

Any chance to upstream your inline patches?

I'd like to share some more comments based you @bapt's post here: lists.freebsd.org/archives/freebsd-hackers/2026-June/006427.html

This is much better, though, there are still issues left I have commented before.

Yet another usecase currently support by RC script is to have multiple instances of a service with a profile, see postgresql, tomcat, apache. Works perfectly:

root@deblndw013x1j:~
# sysrc local_startup
local_startup: /usr/local/etc/rc.d /usr/local/ldacafe/etc/rc.d
root@deblndw013x1j:~
# ll /usr/local/ldacafe/etc/rc.d
total 1
lrwxr-xr-x  1 ldacafe ldacafe 27 2026-03-24 19:42 tomcat_scs_dev@ -> /usr/local/etc/rc.d/tomcat9
lrwxr-xr-x  1 ldacafe ldacafe 27 2026-03-24 19:49 tomcat_scs_prod@ -> /usr/local/etc/rc.d/tomcat9

or

root@deblndw013x5j:~
# sysrc local_startup
local_startup: /usr/local/etc/rc.d /usr/local/fkminator/etc/rc.d /usr/local/barista/etc/rc.d
root@deblndw013x5j:~
# ll /usr/local/fkminator/etc/rc.d
total 1
lrwxr-xr-x  1 fkminator fkminator 55 2026-05-27 20:46 fkminatorbeat@ -> /usr/local/fkminator/app/.deployment/rc.d/fkminatorbeat
lrwxr-xr-x  1 fkminator fkminator 57 2026-05-27 20:46 fkminatorworker@ -> /usr/local/fkminator/app/.deployment/rc.d/fkminatorworker
root@deblndw013x5j:~
# ll /usr/local/barista/etc/rc.d
total 5
-r-xr-xr-x  1 barista barista 701 2026-05-19 21:24 barista*

This should also work.

1.6.0 is incomplete reported by me, therefore 1.6.1 is in the vote and then autoreconf can be removed.

Drop archive

In D57335#1314151, @diizzy wrote:

Maintainers need to keep their ports working properly, adding band-aids to work around the issues isn't a proper solution.

In D57335#1314141, @diizzy wrote:

archive.apache.org was removed because it's simply wrong in the context of mirror(s) and shouldn't be in the list
See https://cgit.freebsd.org/ports/commit/Mk/bsd.sites.mk?id=34197c5c60d360ad5af37c3e8aaf4d18176d4f3b

For reference, here are the UEFI firmware parser dumps of both produces. Slight differences, I have no clue wether they are relevant.

In D57357#1314101, @aokblast wrote:

In D57357#1314094, @michaelo wrote:

Yeah, finally! I tried myself recently and assumed it only to be CLANG, didn' think about the dwarfs at all.
Did you compare the resuting output files, are thy binary identical?

I think it is impossible for the to have same output as they have different way to generate and optimize the code.

Don't forget to bump the port revision.

Yeah, finally! I tried myself recently and assumed it only to be CLANG, didn' think about the dwarfs at all.
Did you compare the resuting output files, are thy binary identical?

Ran these two successfully:

grep -r --include=Makefile -E -e 'MASTER_SITES=.+APACHE' . -l | cut -d / -f 2-3 | xargs -I% make -C % makesum
grep -r --include=Makefile -E -e 'APACHE/' . -l | cut -d / -f 2-3 | xargs -I% make -C % makesum

Only www/archiva failed because it has been moved to attic years ago and defunct. Latest release in ports tree is several years old. DL CDN does not host the dist file anymore. This port needs to be deprecated and removed sooner or later.

In D57187#1312379, @fuz wrote:

No objections, I just committed and had little input into the contents of the patch. Please ask the uboot group.

Bump revision and MFH as well

In D57187#1311138, @bz wrote:

In D57187#1310524, @michaelo wrote:

Guys, I don't really know who to add as reviewer. As far as I can see that GCC it not required at runtime at all. This seems to be an oversight or relic from the past.

The change was done by the latest update from @fuz if I remember correctly looking a few days ago and I was wondering the same. You can always add Ports Committers to see if anyone helps reviewing.

In D56835#1311669, @bapt wrote:

In D56835#1311163, @michaelo wrote:

There is one thing I'd really love to see what RC does not have at all: user units like systemd has. It often happens that our users want to run something in the background and I cannot offer anything, but to create an RC for them, install doas, delegate, etc. Too complex. For k5start on AL8 for a specific user I have created a user unit and it does what it should do: keep the Kerberos ticket cache alive. I'd love to hear your opinion on it.

The way I would see it in this case is a new /var/rcd similar to /var/cron/ and people would rcctl user add ./myunit, it will parse and validate and if ok will move it to /var/cron, with rcctl user list and rcctl user del

What do you think?

In D56835#1311274, @kib wrote:

In D56835#1311164, @imp wrote:

I'd like to echo the user requirement. I have not current need for it at $WORK, but can see a need in the future. Having the ability for users to tie into the startup, running as themselves, much like we allow users to add jobs to cron, at, etc would be a useful, but not gating, feature.

There is a @reboot keyword support in our crontab, working for user's crontab.

There is one thing I'd really love to see what RC does not have at all: user units like systemd has. It often happens that our users want to run something in the background and I cannot offer anything, but to create an RC for them, install doas, delegate, etc. Too complex. For k5start on AL8 for a specific user I have created a user unit and it does what it should do: keep the Kerberos ticket cache alive. I'd love to hear your opinion on it.

In D56835#1310138, @bapt wrote:

if you question is can I overrite/extend the predefined provide/requires, not it is not covered, by design, it can be done by accident, but that is a good idea, and probably easy addon, which we may add after.

I am fine with this change, but I am not an official src comitter. @bapt I think this is also covered as oneshot with your proposed rcd(8).

Fix intro

Bump date

Guys, I don't really know who to add as reviewer. As far as I can see that GCC it not required at runtime at all. This seems to be an oversight or relic from the past.

Yet another question which is current not solvable with rc(8) from a real-world example: www/apache24 comes with an RC script. I run www/mod_wsgi, the application requires databases/valkey. This means that valkey has to start before HTTPd, but I cannot change the RC script to do that. Can this be solved with this rcd(8)? Has this been considered?

Closing since this has been overcome already.

Huge respect for the amount of work done. While I cannot properly judge on the actual code, I still dare to ask:

I have worked on node a couple of months ago and verified in its codebase that it does the right thing with OpenSSL, see my ports commits. I am surprised about the finding mentioned here.

Although I don't acces to such a controller, aber the actual bits described in the manpage which you can set at runtime?

In D56753#1300105, @ziaee wrote:

In D56753#1300071, @michaelo wrote:

When comparing with other drivers they say how to compile into the kernel. Is this not relevant?

It's not just irrelevant, it's completely wrong and undermines the entire structure of the manual pages. Think about it. In every section, SYNOPSIS does not contain prose. It enumerates all available options, which should be described in DESCRIPTION. Drivers should also do that. We have almost 200 manuals in the tree following the format I use here, and I intend to standardize upon this. I proposed this on arch@ in January with no objections -- https://marc.info/?l=freebsd-arch&m=176782215606871

When comparing with other drivers they say how to compile into the kernel. Is this not relevant?

Abandoing in favor of D56753.