Errors creating ports index with make

I have a real machine (server) and two virtual machines (desktops) with FreeBSD at the latest release and updated to the latest patch:

Code:
FreeBSD ambaxtos 15.0-RELEASE-p4 FreeBSD 15.0-RELEASE-p4 GENERIC amd64 (server - real machine)
FreeBSD iantomarus 15.0-RELEASE-p4 FreeBSD 15.0-RELEASE-p4 GENERIC amd64 (desktop - VirtualBox guest on Windows host)
FreeBSD elopao-vm 15.0-RELEASE-p4 FreeBSD 15.0-RELEASE-p4 GENERIC amd64 (desktop - VirtualBox guest on Windows host)

Running the command on the server (server only):

Code:
make -C /usr/ports index

I get the following result

Code:
...
--- describe.lang ---
--- describe.mail ---
--- describe.math ---
--- describe.misc ---
--- describe.multimedia ---
--- describe.net ---
--- describe.math ---
/rescue/sh: gcc14: not found
make[4]: /usr/ports/Mk/Uses/compiler.mk:86: warning: Command "gcc14 --version" exited with status 127
make[4]: /usr/ports/Mk/Uses/compiler.mk:134: warning: Command "g++14 -### /dev/null 2>&1" exited with status 127
--- describe.net-im ---
--- describe.net-mgmt ---
...

The difference is that on desktop machines it is installed lang/gcc14 while it is not on the server. Installing lang/gcc14 on the server makes this error go away.

It could be a bug. May I open a PR? If yes, in what category?
Thank you all
 
Why are you generating INDEX in the first place? It often breaks and you don't actually need it.
 
The index is not accurate for some port, very few, I see one but I do not remember which. What I remember is that it was for 32bit instead of 64bit, not a big issue, but my program to manage ports marked it 'out-of-date' (stale) or differences between pkg installed and port. The second reason is that I have some personal ports in the ports tree, that is they are not part of the official FreeBSD ports and for that they are not in the downloaded index.

Edit: comes in mind, the port was misc/compat13x that has flavors or watch the platforms, in index the package name for 32bit. The day the system was 14.x-RELEASE
 
but my program to manage ports marked it 'out-of-date' (stale) or differences between pkg installed and port.
Still don't actually need the INDEX.

Code:
     The database of available packages and versions to compare against the
     installed packages may be chosen by specifying one of -P, -R or -I or by
     setting VERSION_SOURCE in pkg.conf(5).  If not specified then the ports
     index file will be used if it exists (-I).  Otherwise, should a ports
     tree exist that will be used to compare versions (-P).  Failing either of
     those two choices, the repository catalogue will be used (-R).
pkg-version(8)

pkg version -vP will compare against port versions, not INDEX.
 
Still don't actually need the INDEX.

Code:
     The database of available packages and versions to compare against the
     installed packages may be chosen by specifying one of -P, -R or -I or by
     setting VERSION_SOURCE in pkg.conf(5).  If not specified then the ports
     index file will be used if it exists (-I).  Otherwise, should a ports
     tree exist that will be used to compare versions (-P).  Failing either of
     those two choices, the repository catalogue will be used (-R).
pkg-version(8)

pkg version -vP will compare against port versions, not INDEX.
Yes, I know that. I took in account several things to write my program, the first was speed. Loading and parsing the index is very fast, all the info needed to build a map of ports tree in memory can be done with index, so if you want to make a simple search into the ports tree it happens near instantly, but the informations about the found ports may involve runnings other commands (pkg or make commands) but only for the found ports and if you want to display port info that are not present in index file. However it does not matter, I can install gcc14 to make make happy, but /usr/ports/Mk/Uses/compiler.mk should not raise an error if a port is not installed, or may ask to install it (or ignore the error and take the right decision about the situation).
 
I have to adjust many things to be really usable. It's a CLI and GTK3 program with common ports management module and trying to make a TUI too, all in node and gjs JavaScript with no npm packages. Then (as last step) move all work on a daemon that execute commands from the above programs. I'm just getting started, I'm doing it in my spare time (I think I'll die before I finish it).
 
Have a go. Like i said. But don't expect answers here. Unless you make a port ,porters handboo & People use your port.
I want to understand , cli ,gtk , node these can be different. Try to consolidate to one framework. It makes life easier.
Me i ditched node , i create my own html ,css, and use npm/npx for very good linting of these html,css
 
A node CLI program is a program written in javascript that run in console using node.js interpreter. a gjs GTK3 program is a program written in javascript that run in GUI using gjs (Gnome JavaScript) interpreter. Both interpreters are ECMAScript compatible. They have nothing to do with HTML, CSS, JS, you can use it in web (node.js), but it is not mandatory. JavaScript is a programming language born for the web, but extended to use it like any other. The first that implemented using in system was Windows (WSH) for write complex script for system admins, before PowerShell was born, it used COM components for managing system object (using batch scripts was a pain).
 
Experts here say/imply the INDEX file is useless, error prone, frequently broken etc. If that's the case then why do we support "make index" or "make fetchindex" at all?

We won't even get into those CRAZY people that actually want to compile their own stuff from the ports collection....! What do these people think they're doing anyway?
 
Running "pkg version -l '<' -v" is a hell of a lot faster when there's an index file. The index file is periodically built and updated in the GIT repo. This dedication of official resources lends an implication of legitimacy which you say doesn't exist. The messaging is inconsistent...
 
Experts here say/imply the INDEX file is useless, error prone, frequently broken etc. If that's the case then why do we support "make index" or "make fetchindex" at all?

We won't even get into those CRAZY people that actually want to compile their own stuff from the ports collection....! What do these people think they're doing anyway?
We all use poudriere :).
And for finding a package i ports there is "psearch"
 
cd /usr/ports
git branch
---> 2026Q1
git pull
make index
....
>>> make_index: links-2.30_1,1: no entry for /usr/ports/devel/directfb
>>> make_index: links-2.30_1,1: no entry for /usr/ports/devel/directfb
>>> make_index: linux-vdbench-5.04.07: no entry for /bin/java:
Finished succesfully.

cat /etc/os-release
NAME=FreeBSD
VERSION="15.0-RELEASE-p4"
VERSION_ID="15.0"
 
Running "pkg version -l '<' -v" is a hell of a lot faster when there's an index file.
Is it faster, yes, is it required, no.

pkg version -Pvl'<'

The index file is periodically built and updated in the GIT repo.
Yes, and it's built based on default values. If you have local DEFAULT_VERSIONS that INDEX file isn't going to match with your local defaults. I haven't built an INDEX file in eons.
 
I will work on changing these old habits and ceasing to use the index. I've been using the index file for a very long time.

There's really not much indication externally that the index should be avoided. Right now building it (on my 14stable machine) produces truncated output -- an INDEX-14 file that doesn't contain 'the whole story.' A run of pkg version -Pvl '<' or pkg version -Rvl '<' shows outdated packages that aren't shown in my old standby pkg version -l '<' .

The FreeBSD Handbook still tells new users to use pkg version -l "<" though, so perhaps I should try to write/contribute something to prevent others falling into the trap of thinking these old features actually work. Then the docs people can tell me what I'm doing wrong..
 
The index file is periodically built and updated in the GIT repo.
Oh, and the INDEX file isn't in Git. It never was, not in SVN either and even futher back, not in CVS. portsnap(8) pulled it in though, but that entire infrastructure will disappear very soon (when the 13 major branch is EoL).
 
Well, I actually use pkg -L '=' to check which ports (packages) to update (`-I` is implicit). However, I use the index to display the entire ports tree, not just the installed ones. Even if a lot of information is missing from the index file, it's retrieved with make -V var -V var ....There's also the `make` command to create the index file in JSON format, which contains much more information, but it takes too long. I don't remember how long, but I'd say about twenty times longer (maybe more).
 
Back
Top