No longer relevant as this has been committed.

Fixed at https://cgit.freebsd.org/ports/commit/?id=ba7961f454325f729d11785e2f4a12ddff5b0f33

I will take care of it during my weekend port rampage.

• Split into different files
• As I am also here mention about multiple staffs in CI and also all of the CI works are mentioned in the CI status report. So refer to them.
• Added a ports file where I have mentioned the work I have done for the ports.
• Added a cluster file where I have mentioned about deploying the Grimoirelab.
• Totally skipped mentioning about CIS as it does not fall in any groups.

In D48392#1103774, @jrm wrote:

In D48392#1103769, @bofh wrote:

In D48392#1103768, @jrm wrote:

This was submitted based on a miscommunication. I'm preparing the Foundation entry, but waiting on some authors to share their contributions. @bofh, could you please close this revision?

I am working on an updated patch as suggested by you. Or do you want me to close the revision and send you the text?

I requested that you submit one or more report entries that are specific to your work like the other Foundation developers. For example:

• https://cgit.freebsd.org/doc/tree/website/content/en/status/report-2024-10-2024-12/suspend.adoc
• https://cgit.freebsd.org/doc/tree/website/content/en/status/report-2024-10-2024-12/wireless-iwx.adoc
• https://cgit.freebsd.org/doc/tree/website/content/en/status/report-2024-10-2024-12/audio.adoc
• https://cgit.freebsd.org/doc/tree/website/content/en/status/report-2024-10-2024-12/foundation-security.adoc

...

If you plan to completely overwrite this review with your content, that also works.

In D48392#1103768, @jrm wrote:

This was submitted based on a miscommunication. I'm preparing the Foundation entry, but waiting on some authors to share their contributions. @bofh, could you please close this revision?

Committed at 521c4c6e650075b92d0f9e9256af54c9b8913732.

Rebasing doesn't necessarily imply that you have to resubmit the patch. It's just a warning so that you don't make a mistake while committing depending on your workflow. Somehow I have a big list of tasks for a new comer when I mentor someone and I always do something to create a conflict so that they know how to fix it. I indeed missed the part of Approved by: as I normally don't bother about it too much; but yes make sure with others as it might make some people upset.

@kiwi Just to let you know that I have updated the ports in the meantime. So make sure to rebase. And I think you don't the need the portlint/portclippy part anymore.

Oh sorry I wasn't aware that you were actually awaiting for my approval because these are new ports. Feel free to shoot at will.

I do have the necessary CHANGES entry just not attached it here for keeping it clutter free. I will rerun one more mini exp tomorrow and commit.

I do have the necessary CHANGES entry just not attached it here for keeping it clutter free. I will rerun one more mini exp tomorrow and commit.

In D48245#1100190, @dch wrote:

fixed sorting inside a jail. No amount of LC_ALL and related settings makes it work outside. thanks!

Ah sorry I am not sure why the wrong line was copied. It should be:

Build failed for target 'images' in configuration 'bsd-x86-server-release'`

This is really weird. Can you run the following and see what happens:

In D48245#1100172, @dch wrote:

In D48245#1100054, @bofh wrote:

I don't think this is the correct approach for dns/p5-Zonemaster-Backend port. This port should have flavors; if not at least options to configure DB backends like sqlite, mysql and pgsql. A quick example for flavors might be postfix or freeradius.

The rest looks alright to me.

The DB configurations requires a post-install task that alters the ini file.
Given the very small user base, building flavours seems a bit gratuitous. I
would prefer to commit as-is and work through the alternatives afterwards,
as I will not have time to test the variants for a while.

Is that ok?

In D48201#1099478, @mat wrote:

It would be nice to really make use of the USES framework by using arguments, I think the JAVA_VERSION, JAVA_BUILD, JAVA_EXTRACT, JAVA_RUN and probably the USE_ANT variable should be turned into USES=java arguments, like USES=java:18+,build.

Converted some of the keywords to args. USE_ANT, JAVA_BUILD, JAVA_RUN and JAVA_EXTRACT has been converted to respected keywords ant, build, extract and run. The version scheme has not been handled in this case. The version handling needs some discussion with other developers as there are corner cases of using disperse versioning which requires space separated version number and does not really align with our USES framework versioning like <version>+ or -<version> or <min>-<max> scheme.

In D48201#1100095, @rene wrote:

I can hold off branching 2025Q1

In D48227#1100097, @rene wrote:

I can hold off branching 2025Q1

I don't think this is the current approach for dns/p5-Zonemaster-Backend port. This port should have flavors; if not at least options to configure DB backends like sqlite, mysql and pgsql. A quick example for flavors might be postfix or freeradius.

There are also a huge list of sysrc <service>_enable commands which I believe we should convert to service <service> enable.

Was closed by a partial commit.

In D48227#1099753, @freebsd_dev.thsi.be wrote:

I've created https://reviews.freebsd.org/D48228
You can see there how I intended to re-do the USE_OCAML_LDCONFIG. I've been testingthat patch on 15amd64 and 13.3 armv7, everything build fine with the exception of math/coq which fails to build the documentation on armv7...

One other thing in that patch is the removal of USE_OCAMLFIND_PLIST, which make the bsd.ocaml.mk to Uses/ocaml.mk transistion less complicated. USE_OCAMLFIND_PLIST isn't really that useful, to the contrary it makes packaging error more likely (e.g. disabling a feature, not noticing less files are packages), so i think it is better to remove it.

Here is the updated patch which converts everything from bsd.ocaml.mk to args for USES=ocaml. See the summary.

We should have moved out of Mk/bsd.*.mk (except the obvious ones) maybe a decade ago and these are just some technical debts in the Mk directory. :)

Just to add to my comments we need to do the following:

In D48201#1099478, @mat wrote:

It would be nice to really make use of the USES framework by using arguments, I think the JAVA_VERSION, JAVA_BUILD, JAVA_EXTRACT, JAVA_RUN and probably the USE_ANT variable should be turned into USES=java arguments, like USES=java:18+,build.

In D48201#1099460, @mat wrote:

This looks promising.
Could you update the diff with either using arcanist or git diff -U9999 so we get context ?