I posted to pkgsrc-users, received and tried some great suggestions, but the xf86-video-openchrome error continued.
I reverted to my Linveo backup from November 5, which I had imagined to be the last good build. However, the error was present in the November 5 build and also was present in the next previous October 26 build. I just didn't notice.
When the build errors out, and the compiler errors scroll off the terminal, the only remaining visible clue seems to be the minus sign ahead of the last line of output. There is no additional error message at the end. And time completes as expected. Obviously I would have seen the prominent compiler errors if I had scrolled up even a little bit through the output. Clueless™
chronos@penguin:~/servers/linveo$ `head -n 1 login`
Last login: Wed Nov 5 17:04:13 2025 from xxx.xxx.xxx.xxx
NetBSD 11.99.3 (GENERIC) #3: Tue Nov 4 03:43:15 UTC 2025
linveo# cd /usr/pkgsrc
linveo# ls -l no*
-rw------- 1 root wheel 3909356 Nov 4 05:05 nohup.out
-rw------- 1 root wheel 5198871 Oct 26 20:21 nohup.out-old
linveo# tail nohup.out-old
+ polkit
+ pulseaudio
+ py313-cython
+ py313-setuptools_scm
+ raqm
+ rust
+ vala
+ xf86-video-savage
- xf86-video-openchrome
9226.38 real 8076.45 user 805.59 sys
linveo#
What now? I still haven't figured out exactly why and where xf86-video-openchrome comes into the picture. As mentioned above, I installed the modular xorg meta-package. So I am guessing xf86-video-openchrome derives from the meta-package.
Besides looking at the meta-package, additional options include @angstrom's suggestion to change a makefile to exclude xf86-video-openchrome, maybe adding a cast to fix the type mismatch error, and maybe deleting all the modular X packages and rebuilding with precisely specified packages instead of meta-packages.
I could go back to the X which is in /usr/xsrc, as part of the regular NetBSD distribution, instead of the X which is in pkgsrc. Or just leave X entirely out and concentrate on command line serial stuff.
Since @Crab is here maybe I should try FreeBSD again? Since @AuroraZero is here, maybe I should try Slackware again?
@Not_Oles said:
I posted to pkgsrc-users, received and tried some great suggestions, but the xf86-video-openchrome error continued.
I reverted to my Linveo backup from November 5, which I had imagined to be the last good build. However, the error was present in the November 5 build and also was present in the next previous October 26 build. I just didn't notice.
When the build errors out, and the compiler errors scroll off the terminal, the only remaining visible clue seems to be the minus sign ahead of the last line of output. There is no additional error message at the end. And time completes as expected. Obviously I would have seen the prominent compiler errors if I had scrolled up even a little bit through the output. Clueless™
I was surprised when you said that the build succeeded as recently as the end of October, but I didn't want to question you on this
What now? I still haven't figured out exactly why and where xf86-video-openchrome comes into the picture. As mentioned above, I installed the modular xorg meta-package. So I am guessing xf86-video-openchrome derives from the meta-package.
Yes, as I said above, it's a dependency of the meta-package "modular-xorg-drivers"
Besides looking at the meta-package, additional options include @angstrom's suggestion to change a makefile to exclude xf86-video-openchrome,
If I may say so, this would be the simplest thing to try!
As I also said above, it's telling that xf86-video-openchrome isn't present in the pkgsrc binary repository, which indicates that it currently fails to build
I could go back to the X which is in /usr/xsrc, as part of the regular NetBSD distribution, instead of the X which is in pkgsrc. Or just leave X entirely out and concentrate on command line serial stuff.
I'm not sure that I fully understand why you're trying to build the package "modular-xorg", but if it's just for fun, then I (kind of) understand
Since @Crab is here maybe I should try FreeBSD again? Since @AuroraZero is here, maybe I should try Slackware again?
For what it's worth, I don't find the package "xf86-video-openchrome" in the FreeBSD ports and packages collection either:
"A single swap file or partition may be up to 128 MB in size. [...] [I]f you need 256 MB of swap, you can create two 128-MB swap partitions." (M. Welsh & L. Kaufman, Running Linux, 2e, 1996, p. 49)
@angstrom said: I was surprised when you said that the build succeeded as recently as the end of October, but I didn't want to question you on this
One of the best ways to be my friend is to catch and post about my mistakes. The more quickly I learn about my mistakes, the better off I am! Thanks for your wonderfully positive and helpful motivation toward questioning me about something I said that seemed wrong!
@angstrom said: Yes, as I said above, it's a dependency of the meta-package "modular-xorg-drivers"
@angstrom said: As I also said above, it's telling that xf86-video-openchrome isn't present in the pkgsrc binary repository, which indicates that it currently fails to build
It seems like everyone who currently installs X via pkgsrc on any architecture with the pkgsrc "x11/modular-xorg" meta-package receives a dependency that doesn't compile.
@angstrom said: I'm not sure that I fully understand why you're trying to build the package "modular-xorg", but if it's just for fun, then I (kind of) understand
This very fast Linveo VPS is just for fun! It has given me the opportunities to
@Not_Oles said: just leave X entirely out and concentrate on command line serial stuff.
Pkgsrc modular X is now removed. Of course, we could add the main distribution's /usr/xsrc X or restore pkgsrc modular X if somebody comes aboard and wants it.
What I did procedurally was make a backup and then remove all pkgsrc packages with
linveo# cat delete-all-packages.sh
for pkg in $(pkg_info | awk '{print $1}')
do
pkg_delete $pkg
done
linveo#
Just run this a few times until there are no more "still needed dependencies" in the output. I had 517 packages. I ran delete-all-packages.sh about six times.
Once all the packages were gone, I reinstalled /www/lynx, /www/curl, /www/tinyproxy, and /devel/git. Including their dependencies, these 4 packages resulted in 75 installed packages.
linveo# pkg_info | wc -l
75
linveo#
linveo# pkg_info
libnbcompat-20251029 Portable NetBSD compatibility library
cwrappers-20220403 pkgsrc compiler wrappers
mktools-20250213 Collection of pkgsrc mk infrastructure tools
digest-20220214 Message digest wrapper utility
m4-1.4.19nb1 GNU version of UNIX m4 macro language processor
libtool-base-2.4.7nb1 Generic shared library support script (the script itself)
gettext-lib-0.22.5 Internationalized Message Handling Library (libintl)
gettext-tools-0.22.5nb1 Tools for providing messages in different languages
lynx-2.9.2nb5 Alphanumeric display oriented World-Wide Web Client
pkgconf-2.4.3nb1 API-driven pkg-config replacement
gmake-4.4.1 GNU version of 'make' utility
libffi-3.5.2 Foreign function interface
libuuid-2.40.2 Generate unique identifiers for objects
mpdecimal-4.0.1 C/C++ arbitrary precision decimal floating point libraries
readline-8.3nb1 GNU library that can recall and edit previous input
sqlite3-3.51.0 SQL Database Engine in a C Library
python313-3.13.9 Interpreted, interactive, object-oriented programming language
py313-flit_core-3.12.0 Distribution-building parts of Flit
py313-installer-0.7.0nb3 Library for installing Python wheels
py313-pyparsing-3.2.5 Parsing module for Python
py313-packaging-25.0 Core utilities for Python packages
py313-pyproject_hooks-1.2.0nb1 Wrappers to call pyproject.toml-based build backend hooks
py313-build-1.3.0 Simple, correct PEP517 package builder
py313-setuptools-80.9.0 New Python packaging system
xmlcatmgr-2.2nb1 XML and SGML catalog manager
docbook-xml-4.5 XML DTD designed for computer documentation
perl-5.42.0 Practical Extraction and Report Language
docbook-xsl-1.79.2nb7 Docbook XSL modular stylesheet
getopt-1.1.6 Program to help shell scripts parse command-line parameters
libgpg-error-1.56 Definitions of common error values for all GnuPG components
libgcrypt-1.11.2 GNU cryptographic library
libxml2-2.14.6 XML parser library from the GNOME project
libxslt-1.1.43nb4 XSLT parser library
asciidoc-10.2.1nb5 ASCII to formatted document converter
gperf-3.2nb1 GNU perfect hash function generator
tinyproxy-1.11.2 Lightweight HTTP/SSL proxy
libunistring-1.2 Unicode string library
libidn2-2.3.7 Convert internationalized domain names to/from ASCII Encoding
nghttp2-1.68.0 Implementation of HTTP/2 in C
curl-8.17.0 Client that groks URLs
pcre2-10.47 Perl Compatible Regular Expressions library (major version 2)
git-base-2.52.0 GIT Tree History Storage Tool (base package)
p5-gettext-1.07nb10 Perl5 module interface to C I18N functions
help2man-1.49.3 Generate simple manual pages from program output
autoconf-2.72 Generates automatic source code configuration scripts
automake-1.18 GNU Standards-compliant Makefile generator
xmlto-0.0.29 Tool to help transform XML documents into other formats
git-contrib-2.52.0 GIT Tree History Storage Tool (contrib)
git-docs-2.52.0 GIT Tree History Storage Tool (documentation)
p5-DBI-1.647nb1 The database-independent Perl database access API
p5-DBD-SQLite-1.76nb6 Perl DBI/DBD driver for sqlite databases (self contained)
p5-Error-0.17030nb1 Perl extension module for try/throw/catch exception handling
p5-Capture-Tiny-0.50nb1 Capture STDOUT and STDERR from Perl, XS or external programs
p5-Net-3.15nb3 Perl5 modules to access and use network protocols
p5-TimeDate-2.33nb5 Perl5 TimeDate distribution
p5-MailTools-2.22nb1 Perl5 modules related to mail applications
p5-Digest-HMAC-1.05nb2 Perl5 module for HMAC
p5-Net-IP-1.26nb13 Perl extension for manipulating IPv4/IPv6 addresses
p5-Socket6-0.29nb7 Perl5 module to support getaddrinfo() and getnameinfo()
p5-IO-Socket-INET6-2.73nb4 Perl object interface for AF_INET/AF_INET6 domain sockets
p5-Net-DNS-1.53 Perl5 module for DNS resolution
p5-Net-Domain-TLD-1.75nb9 Work with TLD names
p5-Email-Valid-1.204nb2 Perl5 module for testing validity of an email address
gsed-4.9nb1 GNU implementation of sed, the POSIX stream editor
libidn-1.42 Internationalized Domain Names command line tool
p5-Net-LibIDN-0.12nb17 Perl bindings for GNU Libidn
p5-Net-SSLeay-1.94nb2 Perl5 module for using OpenSSL
p5-Mozilla-CA-20250602nb1 Mozilla's CA cert bundle for Perl
p5-IO-Socket-SSL-2.095 Perl5 SSL socket interface class
p5-Net-SMTP-SSL-1.04nb9 Perl5 module providing SSL support for Net::SMTP
p5-Crypt-URandom-0.54nb1 Perl5 module to provide non blocking randomness
p5-GSSAPI-0.28nb18 Perl extension providing access to the GSSAPIv2 library
p5-Authen-SASL-2.1900 Perl module to handle SASL authentication
git-perlscripts-2.52.0 Git commands that rely on Perl
git-2.52.0 GIT version control suite meta-package
linveo#
Thanks again for helping me understand the dependencies of pkgsrc's modular xorg!
@angstrom said: I'm a long-term NetBSD user -- but not exclusively NetBSD -- but I don't like living on the edge, so I've always just used NetBSD stable (now: 10.1) and pkgsrc stable
May I please ask, how did you get started with NetBSD? Thanks!
@Not_Oles said:
Pkgsrc modular X is now removed. Of course, we could add the main distribution's /usr/xsrc X or restore pkgsrc modular X if somebody comes aboard and wants it.
What I did procedurally was make a backup and then remove all pkgsrc packages with
linveo# cat delete-all-packages.sh
for pkg in $(pkg_info | awk '{print $1}')
do
pkg_delete $pkg
done
linveo#
Just run this a few times until there are no more "still needed dependencies" in the output. I had 517 packages. I ran delete-all-packages.sh about six times.
I sometimes need (or prefer) to delete all of the pkgsrc binaries in order to start afresh, and the following command does this quickly:
# pkg_delete -ff '*-*'
As you yourself have experienced, pkgsrc current -- but even pkgsrc stable -- can be a wild ride, and it's sometimes useful to start afresh. I find that this is often true after a few pkgsrc-stable releases in a row. (A pkgsrc-stable release takes place at the end of every quarter)
The fact is that NetBSD is (and was always) a small project comparatively, and they simply don't have person power to test everything well in pkgsrc. Things break, especially in pkgsrc current, but even pkgsrc stable includes anomalies that vary between pkgsrc-stable releases. As I said above, I mostly keep to pkgsrc stable because pkgsrc stable is generally much safer to use
"A single swap file or partition may be up to 128 MB in size. [...] [I]f you need 256 MB of swap, you can create two 128-MB swap partitions." (M. Welsh & L. Kaufman, Running Linux, 2e, 1996, p. 49)
@Not_Oles said:
What happens if I get rid of the modular xorg meta-package plus all the other X packages, and install just
wm/twm
If it's twm that you're after, twm is in the base distribution
"A single swap file or partition may be up to 128 MB in size. [...] [I]f you need 256 MB of swap, you can create two 128-MB swap partitions." (M. Welsh & L. Kaufman, Running Linux, 2e, 1996, p. 49)
Will this give me a minimal, but working X via VNC?
Do you know if the above short list of packages is sufficient for a working X? Thanks so much!
@Not_Oles , I'm afraid that I don't have a ready answer to this question. As I said earlier, I've never tried to build modular-xorg, so I don't have a good sense of how all of the dependencies are structured. In order to obtain an answer to your question, I would need to look at the dependencies, I'm afraid. Ultimately, the question is how pkgsrc has organized the packages and their dependencies
"A single swap file or partition may be up to 128 MB in size. [...] [I]f you need 256 MB of swap, you can create two 128-MB swap partitions." (M. Welsh & L. Kaufman, Running Linux, 2e, 1996, p. 49)
I might be wrong, but I think it is complaining about elf.h being a file and not a sym link as it apparently is expecting. Since you have been having so much fun with NetBSD and building stuff, perhaps there are some old files that need to be cleaned up.
In NetBSD‑current, usr/include/elf.h is a symlink to ../sys/elf.h. Modify that and see if it helps. Alternatively you could just remove everything under destination directory and build it from the scratch.
@Neat321 said:
What's the point of using NetBSD instead of FreeBSD?
Back in the 1990s I started using NetBSD because, with some help, I managed to run it on the x86, MIPS, and Power machines I had at that time.
@Crab recently helped me try FreeBSD, which is equally great.
For me it's very fun to try different OSes. My suggestion is that you try NetBSD, OpenBSD, and FreeBSD in addition to Linux, and see which one you like best for your equipment and workflow.
Can you check what's under cd /usr/src/distrib/sets? I am not super familiar with NetBSD, but I don't believe that leading dot is there for no reason making it a relative directory to some other location than root (/). Can you check with find command if there's another elf.h somewhere else under /usr/src?
linveo# cd /usr/include/
linveo# ls -l elf.h
lrwxr-xr-x 1 root wheel 14 Oct 17 01:12 elf.h -> sys/exec_elf.h
linveo#
What's in $DESTDIR is different. It seems now a real file instead of a symlink.
linveo# pwd
/usr/obj/destdir.amd64/usr/include
linveo# ls -l elf.h
-r--r--r-- 1 tom wheel 1723 Dec 14 00:27 elf.h
linveo#
Here is the file pointed to by the symlink:
linveo# pwd
/usr/include/sys
linveo# ls -l elf.h
ls: elf.h: No such file or directory
linveo# ls -l exec_elf.h
-r--r--r-- 1 root wheel 55842 Dec 11 01:14 exec_elf.h
linveo#
Maybe I could replace the present symlink with the present pointed-to file? Then the new file would not be a different type of file but would have different content.
I am missing out on understanding how the difference is detected by pax(1).
The error refers to "line 110:"
pax: line 110: ./usr/include/elf.h: type mismatch: specfile link, tree file
🔎 What the error means
• During installsets, the build system uses pax together with the METALOG spec file to copy files into the DESTDIR.
• The spec file says that ./usr/include/elf.sh should be a symlink (usually pointing to ../sys/elf.h).
• In your actual DESTREE tree, elf.h is a regular file instead of a symlink.
• pax detects this mismatch and aborts with:
pax: line 110: ./usr/include/elf.h: type mismatch: specfile link, tree file
⚙️ Why this happens
• Stale DESTDIR: If you’ve run builds before, leftover files in may not match the current source tree’s expectations.
• Header reorganization: NetBSD’s source tree sometimes changes headers from files to symlinks (or vice versa). If your tree is mid‑upgrade, you can get mismatches.
• Partial rebuild: Running "build.sh install=/" without a clean DESTDIR can leave behind old files.
🛠 How to fix
1. Clean DESTDIR completely
rm -rf ../obj/destdir.amd64
Then rerun your build.sh command. This ensures no stale headers remain.
Rebuild includes explicitly
From /usr/src :
./build.sh -O ../obj -T ../tools -U -D ../obj/destdir.amd64 includes
This regenerates symlinks like usr/include/elf.h.
Check expected state
In NetBSD‑current, usr/include/elf.h is a symlink to ../sys/elf.h. Verify in your source tree:
ls -l /usr/src/include/elf.h
It should show elf.h -> ../sys/elf.h.
✅ Summary
Your build failed because elf.h in DESTDIR is a file, but the spec expects a symlink. The cure is to wipe DESTDIR and rebuild includes so the symlink is created correctly.
🛠 How to fix
1. Clean DESTDIR completely
rm -rf ../obj/destdir.amd64
Then rerun your build.sh command. This ensures no stale headers remain.
It seemed like a good idea to clean DESTDIR.amd64, which is inside /obj. So, I moved /usr/obj to /usr/obj-broken and made a new, empty /usr/obj directory:
linveo# pwd
/usr
linveo# ls -l | grep obj
drwxr-xr-x 23 tom wheel 512 Dec 16 00:11 obj
drwxr-xr-x 23 tom wheel 512 Dec 15 20:02 obj-broken
linveo#
I started a new CVS update and build.sh. We will see what happens. . . .
To begin checking on what Co-pilot said, as the new build proceeds:
@Crab's Co-pilot said: • During installsets, the build system uses pax together with the METALOG spec file to copy files into the DESTDIR.
What is the "line 110" in the error that started all this? It's not line 3827 in METALOG.sanitized. . . .
pax: line 110: ./usr/include/elf.h: type mismatch: specfile link, tree file
@Crab's Co-pilot said: • In your actual DESTREE tree, elf.h is a regular file instead of a symlink.
linveo# cd obj-broken/destdir.amd64/usr/include/
linveo# ls -l elf.h
-r--r--r-- 1 tom wheel 1723 Dec 14 00:27 elf.h
linveo# file elf.h
elf.h: C source, ASCII text
linveo#
Let's see what happens when the new build is done. Thanks!
Hey! The build and installs of NetBSD-current kernel and userland plus reboots completed without apparent issue. Thanks to Linveo for a fast VPS! <3 Thanks to @cmeerw for the NetBSD image that got me started!
Looks like completely cleaning the /usr/obj directory worked okay! Thanks to your Co-pilot for the hint about cleaning!
As time goes on, maybe I can understand more about exactly what happened and how and why. Maybe I need to incorporate more cleaning?
In other news, I have been doing a few OpenBSD builds from source. Maybe I am going to try FreeBSD builds too. . . .
@Neat321 said:
What's the point of using NetBSD instead of FreeBSD?
Back in the 1990s I started using NetBSD because, with some help, I managed to run it on the x86, MIPS, and Power machines I had at that time.
@Crab recently helped me try FreeBSD, which is equally great.
For me it's very fun to try different OSes. My suggestion is that you try NetBSD, OpenBSD, and FreeBSD in addition to Linux, and see which one you like best for your equipment and workflow.
@Not_Oles said:
Looks like completely cleaning the /usr/obj directory worked okay! Thanks to your Co-pilot for the hint about cleaning!
Excellent! I thanked my Co-pilot and got a response:
That’s fantastic news! 🎉. I’m glad the cleanup and header rebuild sorted out the mismatch — those lingering DESTDIR artifacts can be sneaky. It’s always satisfying when a stubborn build error finally gives way to a clean run.
Going back to your original problem, I think it is a good habit to clean your env before doing any recompilation. You never know what type of clutter is left behind and potentially throwing you off just like what happened here now.
About compiling FreeBSD, years ago I used to manage multiple production FreeBSD systems using ports which meant that every single update had to be compiled from the sources including the kernel. Yes it took a while, but it was working great and depending on your software needs could provide much more compact and tighter installation than you'd get with pkg. Definitely give it a try!
Here are this morning's results from the NetBSD-current build while I was sleeping. This is with a new, empty /use/obj directory. Maybe I will start replacing /usr/tools as well.
Kernel
===> Summary of results:
build.sh command: /usr/src/build.sh -j 2 -O ../obj -T ../tools -U kernel=GENERIC
build.sh started: Sat Dec 27 07:00:57 UTC 2025
NetBSD version: 11.99.4
MACHINE: amd64
MACHINE_ARCH: x86_64
Build platform: NetBSD 11.99.4 amd64
HOST_SH: /bin/sh
share/mk MAKECONF: /etc/mk.conf
MAKECONF file: /etc/mk.conf
TOOLDIR path: /usr/src/../tools
DESTDIR path: /usr/src/../obj/destdir.amd64
RELEASEDIR path: /usr/src/../obj/releasedir
Updated makewrapper: /usr/src/../tools/bin/nbmake-amd64
Building kernel without building new tools
Building kernel: GENERIC
Build directory: /usr/src/../obj/sys/arch/amd64/compile/GENERIC
Kernels built from GENERIC:
/usr/src/../obj/sys/arch/amd64/compile/GENERIC/netbsd
build.sh ended: Sat Dec 27 07:07:04 UTC 2025
===> .
Build Tools and Userland Distribution
===> Successful make distribution
===> build.sh ended: Sat Dec 27 07:00:57 UTC 2025
===> Summary of results:
build.sh command: /usr/src/build.sh -j 2 -O ../obj -T ../tools -U distribution
build.sh started: Sat Dec 27 05:34:33 UTC 2025
NetBSD version: 11.99.4
MACHINE: amd64
MACHINE_ARCH: x86_64
Build platform: NetBSD 11.99.4 amd64
HOST_SH: /bin/sh
share/mk MAKECONF: /etc/mk.conf
MAKECONF file: /etc/mk.conf
TOOLDIR path: /usr/src/../tools
DESTDIR path: /usr/src/../obj/destdir.amd64
RELEASEDIR path: /usr/src/../obj/releasedir
Updated makewrapper: /usr/src/../tools/bin/nbmake-amd64
Successful make distribution
build.sh ended: Sat Dec 27 07:00:57 UTC 2025
===> .
After installing new kernel, rebooting, installing new userland, and rebooting again
NetBSD 11.99.4 (GENERIC) #0: Sat Dec 27 07:06:47 UTC 2025
linveo# uname -r
11.99.4
linveo# uptime
7:04PM up 1 min, 1 user, load averages: 0.02, 0.01, 0.00
linveo# ls -l /bin | head
total 1942
-r-xr-xr-x 2 root wheel 22056 Dec 27 07:00 [
-r-xr-xr-x 1 root wheel 22024 Dec 27 07:00 cat
lrwxr-xr-x 1 root wheel 11 Dec 27 07:00 chgrp -> /sbin/chown
-r-xr-xr-x 1 root wheel 22240 Dec 27 07:00 chio
-r-xr-xr-x 1 root wheel 17584 Dec 27 07:00 chmod
-r-xr-xr-x 1 root wheel 33528 Dec 27 07:00 cp
-r-xr-xr-x 1 root wheel 57720 Dec 27 06:59 cpio
-r-xr-xr-x 1 root wheel 194992 Dec 27 07:00 csh
-r-xr-xr-x 1 root wheel 27272 Dec 27 07:00 date
linveo#
Next, pkgsrc is updated with pkg-rolling_replace and a full backup is made.
Until recently, this build was running redundantly on two separate servers at separate providers. But right now there is only one server, at Linveo. Is there another server out there? Thanks @linveo!
This morning's NetBSD-current compile completed successfully following a NetBSD source code commit which seemed to fix a compile error first seen yesterday evening.
Both this morning's commit and yesterday evening's error transcript are below.
Is this the commit which fixed the error?
How does the fix work?
Why did the compile error transcript show several compiler flags being repeated within a single command?
Thanks to @linveo for the test VPS! Thanks in advance for any help understanding this error and its fix!
Commit
To: source-changes%NetBSD.org@localhost
Subject: CVS commit: src/tools/compat
From: "Nia Alarie" <nia%netbsd.org@localhost>
Date: Sun, 11 Jan 2026 10:37:46 +0000
Module Name: src
Committed By: nia
Date: Sun Jan 11 10:37:46 UTC 2026
Modified Files:
src/tools/compat: compat_defs.h configure configure.ac
Log Message:
tools build fixes for <sys/endian.h> changes, from skrll
To generate a diff of this commit:
cvs rdiff -u -r1.130 -r1.131 src/tools/compat/compat_defs.h
cvs rdiff -u -r1.110 -r1.111 src/tools/compat/configure
cvs rdiff -u -r1.112 -r1.113 src/tools/compat/configure.ac
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
Error Transcript
1 --- dependall ---
2 --- atoll.lo ---
3 --- basename.lo ---
4 --- atoll.lo ---
5 # compile compat/atoll.lo
6 cc -O -I. -I./include -I/usr/src/tools/compat -I/usr/src/tools/compat/sys -DHAVE_NBTOOL_CONFIG_H=1 -D_FILE_OFFSET_BITS=64 -I. -I./include -I/usr/src/tools/compat -I/usr/src/tools/compat/sys -DHAVE_NBTOOL_CONFIG_H=1 -D_FILE_OFFSET_BITS=64 -D__DBINTERFACE_PRIVATE -c -o atoll.lo.o /usr/src/tools/compat/../../lib/libc/stdlib/atoll.c
7 --- basename.lo ---
8 # compile compat/basename.lo
9 cc -O -I. -I./include -I/usr/src/tools/compat -I/usr/src/tools/compat/sys -DHAVE_NBTOOL_CONFIG_H=1 -D_FILE_OFFSET_BITS=64 -I. -I./include -I/usr/src/tools/compat -I/usr/src/tools/compat/sys -DHAVE_NBTOOL_CONFIG_H=1 -D_FILE_OFFSET_BITS=64 -D__DBINTERFACE_PRIVATE -c -o basename.lo.o /usr/src/tools/compat/../../lib/libc/gen/basename.c
10 --- atoll.lo ---
11 In file included from ./nbtool_config.h:987,
12 from /usr/src/tools/compat/../../lib/libc/stdlib/atoll.c:33:
13 /usr/src/tools/compat/compat_defs.h: In function 'be16enc':
14 /usr/src/tools/compat/compat_defs.h:1138:25: error: implicit declaration of function 'bswap16' [-Wimplicit-function-declaration]
15 1138 | #define htobe16(x) bswap16((u_int16_t)(x))
16 | ^~~~~~~
17 /usr/src/tools/compat/compat_defs.h:1179:13: note: in expansion of macro 'htobe16'
18 1179 | u = hto ## endian ## bits (u); \
19 | ^~~
20 /usr/src/tools/compat/compat_defs.h:1183:1: note: in expansion of macro '__GEN_ENDIAN_ENC'
21 1183 | __GEN_ENDIAN_ENC(16, be)
22 | ^~~~~~~~~~~~~~~~
23 /usr/src/tools/compat/compat_defs.h: In function 'be32enc':
24 /usr/src/tools/compat/compat_defs.h:1141:25: error: implicit declaration of function 'bswap32' [-Wimplicit-function-declaration]
25 1141 | #define htobe32(x) bswap32((u_int32_t)(x))
26 | ^~~~~~~
27 /usr/src/tools/compat/compat_defs.h:1179:13: note: in expansion of macro 'htobe32'
28 1179 | u = hto ## endian ## bits (u); \
29 | ^~~
30 /usr/src/tools/compat/compat_defs.h:1186:1: note: in expansion of macro '__GEN_ENDIAN_ENC'
31 1186 | __GEN_ENDIAN_ENC(32, be)
32 | ^~~~~~~~~~~~~~~~
33 /usr/src/tools/compat/compat_defs.h: In function 'be64enc':
34 /usr/src/tools/compat/compat_defs.h:1144:25: error: implicit declaration of function 'bswap64' [-Wimplicit-function-declaration]
35 1144 | #define htobe64(x) bswap64((u_int64_t)(x))
36 | ^~~~~~~
37 /usr/src/tools/compat/compat_defs.h:1179:13: note: in expansion of macro 'htobe64'
38 1179 | u = hto ## endian ## bits (u); \
39 | ^~~
40 /usr/src/tools/compat/compat_defs.h:1189:1: note: in expansion of macro '__GEN_ENDIAN_ENC'
41 1189 | __GEN_ENDIAN_ENC(64, be)
42 | ^~~~~~~~~~~~~~~~
43
44 *** Failed target: atoll.lo
45 *** In directory: /usr/src/tools/compat
46 *** Failed commands:
47 ${_MKTARGET_COMPILE}
48 => @echo '# ' "compile " compat/atoll.lo
49 ${HOST_COMPILE.c} -o ${.TARGET}.o ${COPTS.${.IMPSRC:T}} ${CPUFLAGS.${.IMPSRC:T}} ${CPPFLAGS.${.IMPSRC:T}} ${.IMPSRC}
50 => cc -O -I. -I./include -I/usr/src/tools/compat -I/usr/src/tools/compat/sys -DHAVE_NBTOOL_CONFIG_H=1 -D_FILE_OFFSET_BITS=64 -I. -I./include -I/usr/src/tools/compat -I/usr/src/tools/compat/sys -DHAVE_NBTOOL_CONFIG_H=1 -D_FILE_OFFSET_BITS=64 -D__DBINTERFACE_PRIVATE -c -o atoll.lo.o /usr/src/tools/compat/../../lib/libc/stdlib/atoll.c
51 ${MV} ${.TARGET}.o ${.TARGET}
52 => mv -f atoll.lo.o atoll.lo
53 *** [atoll.lo] Error code 1
54
55 nbmake[6]: stopped making "realall" in /usr/src/tools/compat
56 --- basename.lo ---
57 In file included from ./nbtool_config.h:987,
58 from /usr/src/tools/compat/namespace.h:9,
59 from /usr/src/tools/compat/../../lib/libc/gen/basename.c:37:
60 /usr/src/tools/compat/compat_defs.h: In function 'be16enc':
61 /usr/src/tools/compat/compat_defs.h:1138:25: error: implicit declaration of function 'bswap16' [-Wimplicit-function-declaration]
62 1138 | #define htobe16(x) bswap16((u_int16_t)(x))
63 | ^~~~~~~
64 /usr/src/tools/compat/compat_defs.h:1179:13: note: in expansion of macro 'htobe16'
65 1179 | u = hto ## endian ## bits (u); \
66 | ^~~
67 /usr/src/tools/compat/compat_defs.h:1183:1: note: in expansion of macro '__GEN_ENDIAN_ENC'
68 1183 | __GEN_ENDIAN_ENC(16, be)
69 | ^~~~~~~~~~~~~~~~
70 /usr/src/tools/compat/compat_defs.h: In function 'be32enc':
71 /usr/src/tools/compat/compat_defs.h:1141:25: error: implicit declaration of function 'bswap32' [-Wimplicit-function-declaration]
72 1141 | #define htobe32(x) bswap32((u_int32_t)(x))
73 | ^~~~~~~
74 /usr/src/tools/compat/compat_defs.h:1179:13: note: in expansion of macro 'htobe32'
75 1179 | u = hto ## endian ## bits (u); \
76 | ^~~
77 /usr/src/tools/compat/compat_defs.h:1186:1: note: in expansion of macro '__GEN_ENDIAN_ENC'
78 1186 | __GEN_ENDIAN_ENC(32, be)
79 | ^~~~~~~~~~~~~~~~
80 /usr/src/tools/compat/compat_defs.h: In function 'be64enc':
81 /usr/src/tools/compat/compat_defs.h:1144:25: error: implicit declaration of function 'bswap64' [-Wimplicit-function-declaration]
82 1144 | #define htobe64(x) bswap64((u_int64_t)(x))
83 | ^~~~~~~
84 /usr/src/tools/compat/compat_defs.h:1179:13: note: in expansion of macro 'htobe64'
85 1179 | u = hto ## endian ## bits (u); \
86 | ^~~
87 /usr/src/tools/compat/compat_defs.h:1189:1: note: in expansion of macro '__GEN_ENDIAN_ENC'
88 1189 | __GEN_ENDIAN_ENC(64, be)
89 | ^~~~~~~~~~~~~~~~
90
91 *** Failed target: basename.lo
92 *** In directory: /usr/src/tools/compat
93 *** Failed commands:
94 ${_MKTARGET_COMPILE}
95 => @echo '# ' "compile " compat/basename.lo
96 ${HOST_COMPILE.c} -o ${.TARGET}.o ${COPTS.${.IMPSRC:T}} ${CPUFLAGS.${.IMPSRC:T}} ${CPPFLAGS.${.IMPSRC:T}} ${.IMPSRC}
97 => cc -O -I. -I./include -I/usr/src/tools/compat -I/usr/src/tools/compat/sys -DHAVE_NBTOOL_CONFIG_H=1 -D_FILE_OFFSET_BITS=64 -I. -I./include -I/usr/src/tools/compat -I/usr/src/tools/compat/sys -DHAVE_NBTOOL_CONFIG_H=1 -D_FILE_OFFSET_BITS=64 -D__DBINTERFACE_PRIVATE -c -o basename.lo.o /usr/src/tools/compat/../../lib/libc/gen/basename.c
98 ${MV} ${.TARGET}.o ${.TARGET}
99 => mv -f basename.lo.o basename.lo
100 *** [basename.lo] Error code 1
101
102 nbmake[6]: stopped making "realall" in /usr/src/tools/compat
103 nbmake[6]: 2 errors
104
105 nbmake[6]: stopped making "realall" in /usr/src/tools/compat
106
107 nbmake[5]: stopped making "dependall" in /usr/src/tools/compat
108
109 nbmake[4]: stopped making "dependall-compat dependall-binstall dependall-host-mkdep" in /usr/src/tools
110
111 nbmake[3]: stopped making "build_install" in /usr/src/tools
112
113 nbmake[2]: stopped making "do-tools" in /usr/src
114
115 nbmake[1]: stopped making "build" in /usr/src
116
117 nbmake: stopped making "distribution" in /usr/src
118
119 ERROR: Failed to make distribution
120
121 *** BUILD ABORTED ***
122 40.75 real 26.97 user 24.87 sys
123
124 ========
VPS Share
Would anybody be interested in sharing my free Linveo AMD Ryzen 9 9950X NetBSD VPS in Arizona? It's open to friends who want to help me learn.
In my Chromebook's Linux container's servers directory, each provider has its own subdirectory, inside of which each server has its own directory.
The individual server directories each have a file named login. The first line of each login file (output by head -n 1) is the IPv4 ssh login command and the last line of each login file (output by tail -n 1) is the IPv6 ssh login command.
As long as I am in the right directory, and using sh or bash, I almost always can log in by ssh to any server with the same two keystrokes: Ctrl+r (reverse search through previous commands) and then backtick (`).
As you know, the backticks tell sh and bash to run as a command the output of what is between the backticks.
Of course, as you know, ssh has it's own built-in shortcut procedure that can be set up in a configuration file.
The new pcc seems to bootstrap successfully on NetBSD-current. The Github pcc sources were compiled first using NetBSD's native gcc, and then compiled again using the gcc-built pcc as the compiler to get a pcc-compiled, bootstrapped pcc.
netbsd$ date
Sun Apr 5 16:33:42 UTC 2026
netbsd$ pwd
/home/tom/PortableCC-compiles-itself/bin
netbsd$ ls
hello.c p++ pcc pcpp
netbsd$ cat hello.c
#include <stdio.h>
int main() {
printf("Hello from bootstrapped PCC!\n");
return 0;
}
netbsd$ ./pcc -o hello hello.c
netbsd$ ./hello
Hello from bootstrapped PCC!
netbsd$ ./pcc -v
Portable C Compiler 1.2.0.DEVEL 20231021 for x86_64-unknown-netbsd11.99
error: no input files
netbsd$
Thanks to Anders Magnusson, the recent main pcc developer! Thanks to Linveo for sponsoring my NetBSD-current VPS!
My sponsored Linveo VPS continues to compile NetBSD-current every few days. No issues, certainly no problems!
I like Linveo so much that I actually bought and continue to pay for two additional VPSes from them, one for FreeBSD-current and another for OpenBSD-current.
This thread's offer of a free share of this thread's sponsored NetBSD-current VPS remains open. Please check the OP for details!
Happy Sunday! Happy Fathers Day to fellow fathers!
For the last year, going on two now, NetBSD-current updates and recompiles, almost always flawlessly, sometimes while I am sleeping. The setup here is mostly generic and unmodified, just to track what's going on in the neighborhood, and to have the sources handy and available.
This brings back memories of running and rebuilding NetBSD-current -- was it thirty years ago?
Comments
I posted to pkgsrc-users, received and tried some great suggestions, but the xf86-video-openchrome error continued.
I reverted to my Linveo backup from November 5, which I had imagined to be the last good build. However, the error was present in the November 5 build and also was present in the next previous October 26 build. I just didn't notice.
When the build errors out, and the compiler errors scroll off the terminal, the only remaining visible clue seems to be the minus sign ahead of the last line of output. There is no additional error message at the end. And time completes as expected. Obviously I would have seen the prominent compiler errors if I had scrolled up even a little bit through the output. Clueless™
What now? I still haven't figured out exactly why and where xf86-video-openchrome comes into the picture. As mentioned above, I installed the modular xorg meta-package. So I am guessing xf86-video-openchrome derives from the meta-package.
Besides looking at the meta-package, additional options include @angstrom's suggestion to change a makefile to exclude xf86-video-openchrome, maybe adding a cast to fix the type mismatch error, and maybe deleting all the modular X packages and rebuilding with precisely specified packages instead of meta-packages.
I could go back to the X which is in /usr/xsrc, as part of the regular NetBSD distribution, instead of the X which is in pkgsrc. Or just leave X entirely out and concentrate on command line serial stuff.
Since @Crab is here maybe I should try FreeBSD again? Since @AuroraZero is here, maybe I should try Slackware again?
Thanks to @linveo for the nice, very fast VPS!
I was surprised when you said that the build succeeded as recently as the end of October, but I didn't want to question you on this
Yes, as I said above, it's a dependency of the meta-package "modular-xorg-drivers"
If I may say so, this would be the simplest thing to try!
As I also said above, it's telling that xf86-video-openchrome isn't present in the pkgsrc binary repository, which indicates that it currently fails to build
I'm not sure that I fully understand why you're trying to build the package "modular-xorg", but if it's just for fun, then I (kind of) understand
For what it's worth, I don't find the package "xf86-video-openchrome" in the FreeBSD ports and packages collection either:
https://ports.freebsd.org/cgi/ports.cgi?query=xf86-video-openchrome&stype=all&sektion=all
But the good news is that it's available in Slackware current:
https://packages.slackware.com/?r=slackware64-current&p=xf86-video-openchrome-0.6.0-x86_64-6.txz
"A single swap file or partition may be up to 128 MB in size. [...] [I]f you need 256 MB of swap, you can create two 128-MB swap partitions." (M. Welsh & L. Kaufman, Running Linux, 2e, 1996, p. 49)
One of the best ways to be my friend is to catch and post about my mistakes. The more quickly I learn about my mistakes, the better off I am! Thanks for your wonderfully positive and helpful motivation toward questioning me about something I said that seemed wrong!
Yes. So, if I understand right, "x11/modular-xorg-drivers" is a dependency of "x11/modular-xorg" and "x11/xf86-video-openchrome" is a dependency of "x11/modular-xorg-drivers"
It seems like everyone who currently installs X via pkgsrc on any architecture with the pkgsrc "x11/modular-xorg" meta-package receives a dependency that doesn't compile.
This very fast Linveo VPS is just for fun! It has given me the opportunities to
Pkgsrc modular X is now removed. Of course, we could add the main distribution's /usr/xsrc X or restore pkgsrc modular X if somebody comes aboard and wants it.
What I did procedurally was make a backup and then remove all pkgsrc packages with
Just run this a few times until there are no more "still needed dependencies" in the output. I had 517 packages. I ran delete-all-packages.sh about six times.
Once all the packages were gone, I reinstalled /www/lynx, /www/curl, /www/tinyproxy, and /devel/git. Including their dependencies, these 4 packages resulted in 75 installed packages.
Following the reinstall I made another backup.
@angstrom
Thanks again for helping me understand the dependencies of pkgsrc's modular xorg!
May I please ask, how did you get started with NetBSD? Thanks!
Checked to make sure that the delete-all-packages.sh script mentioned above does delete all the old, earlier than today binaries from /usr/pkg/bin.
In case anyone might be interested, here is the full /usr/pkg/bin directory listing:
I sometimes need (or prefer) to delete all of the pkgsrc binaries in order to start afresh, and the following command does this quickly:
# pkg_delete -ff '*-*'As you yourself have experienced, pkgsrc current -- but even pkgsrc stable -- can be a wild ride, and it's sometimes useful to start afresh. I find that this is often true after a few pkgsrc-stable releases in a row. (A pkgsrc-stable release takes place at the end of every quarter)
The fact is that NetBSD is (and was always) a small project comparatively, and they simply don't have person power to test everything well in pkgsrc. Things break, especially in pkgsrc current, but even pkgsrc stable includes anomalies that vary between pkgsrc-stable releases. As I said above, I mostly keep to pkgsrc stable because pkgsrc stable is generally much safer to use
"A single swap file or partition may be up to 128 MB in size. [...] [I]f you need 256 MB of swap, you can create two 128-MB swap partitions." (M. Welsh & L. Kaufman, Running Linux, 2e, 1996, p. 49)
If it's twm that you're after, twm is in the base distribution
"A single swap file or partition may be up to 128 MB in size. [...] [I]f you need 256 MB of swap, you can create two 128-MB swap partitions." (M. Welsh & L. Kaufman, Running Linux, 2e, 1996, p. 49)
@angstrom
Thanks for telling me that TWM is in the main distribution.
Do you know if the above short list of packages is sufficient for a working X? Thanks so much!
@Not_Oles , I'm afraid that I don't have a ready answer to this question. As I said earlier, I've never tried to build modular-xorg, so I don't have a good sense of how all of the dependencies are structured. In order to obtain an answer to your question, I would need to look at the dependencies, I'm afraid. Ultimately, the question is how pkgsrc has organized the packages and their dependencies
"A single swap file or partition may be up to 128 MB in size. [...] [I]f you need 256 MB of swap, you can create two 128-MB swap partitions." (M. Welsh & L. Kaufman, Running Linux, 2e, 1996, p. 49)
My friend you cannot pass FreeBSD 15!
Someone mention Slackware????
The Yeti has left the building.
How to understand and fix this error, "type mismatch: specfile link, tree file"?
Thanks for any hints and help!
I might be wrong, but I think it is complaining about elf.h being a file and not a sym link as it apparently is expecting. Since you have been having so much fun with NetBSD and building stuff, perhaps there are some old files that need to be cleaned up.
In NetBSD‑current, usr/include/elf.h is a symlink to ../sys/elf.h. Modify that and see if it helps. Alternatively you could just remove everything under destination directory and build it from the scratch.
Hey, hey, hey @Crab!
FWIW, I haven't changed anything yet.
Hmm . . . October.
Do you think sys/exec_elf.h is now wrong as the target object?
Do you mean that the target should be /usr/include/../sys/elf.h? There doesn't seem to be a /usr/sys directory.
Thank you, as always!
See the path has a dot in front so it is a relative path to your current path at /usr/src and not pointing to /, right?
./usr/include/elf.h
What's the point of using NetBSD instead of FreeBSD?
Yes, but if I am in /usr/src, then ./usr/include/elf.h would refer to /usr/usr/include/elf.h.
But /usr/src has no /usr/src/usr subdirectory. There are /usr/src/usr.bin and /usr/src/usr.sbin.
I am still confused. . . .
Back in the 1990s I started using NetBSD because, with some help, I managed to run it on the x86, MIPS, and Power machines I had at that time.
@Crab
recently helped me try FreeBSD, which is equally great.
For me it's very fun to try different OSes.
My suggestion is that you try NetBSD, OpenBSD, and FreeBSD in addition to Linux, and see which one you like best for your equipment and workflow. 
Can you check what's under cd /usr/src/distrib/sets? I am not super familiar with NetBSD, but I don't believe that leading dot is there for no reason making it a relative directory to some other location than root (/). Can you check with find command if there's another elf.h somewhere else under /usr/src?
I checked the /usr/src/UPDATING file, which says nothing about the issue on the table here.
Previously in this thread I listed what's currently installed:
What's in $DESTDIR is different. It seems now a real file instead of a symlink.
Here is the file pointed to by the symlink:
Maybe I could replace the present symlink with the present pointed-to file? Then the new file would not be a different type of file but would have different content.
I am missing out on understanding how the difference is detected by pax(1).
The error refers to "line 110:"
But line 110 of what?
I gave this to Co-pilot and this is what it says.
Here’s what’s happening in your NetBSD build:
🔎 What the error means
• During installsets, the build system uses pax together with the METALOG spec file to copy files into the DESTDIR.
• The spec file says that ./usr/include/elf.sh should be a symlink (usually pointing to ../sys/elf.h).
• In your actual DESTREE tree, elf.h is a regular file instead of a symlink.
• pax detects this mismatch and aborts with:
⚙️ Why this happens
• Stale DESTDIR: If you’ve run builds before, leftover files in may not match the current source tree’s expectations.
• Header reorganization: NetBSD’s source tree sometimes changes headers from files to symlinks (or vice versa). If your tree is mid‑upgrade, you can get mismatches.
• Partial rebuild: Running "build.sh install=/" without a clean DESTDIR can leave behind old files.
🛠 How to fix
1. Clean DESTDIR completely
From /usr/src :
In NetBSD‑current, usr/include/elf.h is a symlink to ../sys/elf.h. Verify in your source tree:
✅ Summary
Your build failed because elf.h in DESTDIR is a file, but the spec expects a symlink. The cure is to wipe DESTDIR and rebuild includes so the symlink is created correctly.
Co-pilot said
It seemed like a good idea to clean DESTDIR.amd64, which is inside /obj. So, I moved /usr/obj to /usr/obj-broken and made a new, empty /usr/obj directory:
I started a new CVS update and build.sh. We will see what happens. . . .
To begin checking on what Co-pilot said, as the new build proceeds:
What is the "line 110" in the error that started all this? It's not line 3827 in METALOG.sanitized. . . .
pax: line 110: ./usr/include/elf.h: type mismatch: specfile link, tree fileLet's see what happens when the new build is done. Thanks!
Extra thanks to @Crab!
@Crab
Hey! The build and installs of NetBSD-current kernel and userland plus reboots completed without apparent issue. Thanks to Linveo for a fast VPS! <3 Thanks to @cmeerw for the NetBSD image that got me started!
Looks like completely cleaning the /usr/obj directory worked okay!
Thanks to your Co-pilot for the hint about cleaning! 
As time goes on, maybe I can understand more about exactly what happened and how and why. Maybe I need to incorporate more cleaning?
In other news, I have been doing a few OpenBSD builds from source. Maybe I am going to try FreeBSD builds too. . . .
Thanks again for helping @Crab!
Thank you for your reply!
Excellent! I thanked my Co-pilot and got a response:
Going back to your original problem, I think it is a good habit to clean your env before doing any recompilation. You never know what type of clutter is left behind and potentially throwing you off just like what happened here now.
About compiling FreeBSD, years ago I used to manage multiple production FreeBSD systems using ports which meant that every single update had to be compiled from the sources including the kernel. Yes it took a while, but it was working great and depending on your software needs could provide much more compact and tighter installation than you'd get with pkg. Definitely give it a try!
How many make targets does NetBSD offer?
Here are this morning's results from the NetBSD-current build while I was sleeping. This is with a new, empty
/use/objdirectory. Maybe I will start replacing/usr/toolsas well.Kernel
Build Tools and Userland Distribution
After installing new kernel, rebooting, installing new userland, and rebooting again
Next, pkgsrc is updated with
pkg-rolling_replaceand a full backup is made.Until recently, this build was running redundantly on two separate servers at separate providers. But right now there is only one server, at Linveo. Is there another server out there?
Thanks @linveo! 
Thanks @linveo! Happy New Year 2026!
This morning's NetBSD-current compile completed successfully following a NetBSD source code commit which seemed to fix a compile error first seen yesterday evening.
Both this morning's commit and yesterday evening's error transcript are below.
Thanks to @linveo for the test VPS!
Thanks in advance for any help understanding this error and its fix! 
Commit
Error Transcript
NetBSD recompiled itself last night while I was sleeping!
The new kernel install followed by reboot, the new userland install, and another reboot happened a few moments ago.
Now all the packages were rebuilt by
pkg_rolling-replace -rsuv:I recently was looking at the history of compilers (for example,
pcc) and themakeandbmakecommands.According to its Wikipedia article
makewill be 50 years old next month!As mentioned in the OP,
The offer is still open!
Thanks @Linveo!
I remember building a NetBSD 1.x kernel on my Vaxstation 3100. It recompiled itself over several nights of sleep.
"It's a hard life- to be a stick insect." - Karl Pilkington
https://gunkies.org/wiki/VAXstation_3100_series
Today's rebuild of NetBSD-current is now running!
As mentioned at https://lowendspirit.com/discussion/comment/228322/#Comment_228322 today's rebuild has a fix for a bug found by LES' esteemed @cmeerw!
Yet another successful rebuild of NetBSD-current!
Thanks to @linveo for a whole year 🎂 of fast, free Ryzen 9 9950X VPS!
As I said a year ago today in the OP:
I put this offer up on Nodeseek.
Wow, that
got me confused for a bit. Had never thought you could use it in that context.
Hi @cmeerw!
In my Chromebook's Linux container's servers directory, each provider has its own subdirectory, inside of which each server has its own directory.
The individual server directories each have a file named login. The first line of each login file (output by head -n 1) is the IPv4 ssh login command and the last line of each login file (output by tail -n 1) is the IPv6 ssh login command.
As long as I am in the right directory, and using sh or bash, I almost always can log in by ssh to any server with the same two keystrokes: Ctrl+r (reverse search through previous commands) and then backtick (`).
As you know, the backticks tell sh and bash to run as a command the output of what is between the backticks.
Of course, as you know, ssh has it's own built-in shortcut procedure that can be set up in a configuration file.
Thanks!
Tom
Hopefully cmeerw's fix gets into NetBSD 11 so I could finally see a login prompt on my Linveo Intel VM
It is working amazingly on FreeBSD though and the uptime has been impeccable.
There seems to be a new version of the venerable pcc compiler available on Github at https://github.com/PortableCC.
The new pcc seems to bootstrap successfully on NetBSD-current. The Github pcc sources were compiled first using NetBSD's native gcc, and then compiled again using the gcc-built pcc as the compiler to get a pcc-compiled, bootstrapped pcc.
Thanks to Anders Magnusson, the recent main pcc developer!
Thanks to Linveo for sponsoring my NetBSD-current VPS! 
My sponsored Linveo VPS continues to compile NetBSD-current every few days. No issues, certainly no problems!
I like Linveo so much that I actually bought and continue to pay for two additional VPSes from them, one for FreeBSD-current and another for OpenBSD-current.
This thread's offer of a free share of this thread's sponsored NetBSD-current VPS remains open. Please check the OP for details!
Looks like my sponsored Linveo NetBSD-current VPS has the wapbl(4) journal that @cmeerw mentioned in the BSD thread:
It's been longer than usual since I updated and recompiled.
A little more up to date now. . . .
Happy Sunday! Happy Fathers Day to fellow fathers!
For the last year, going on two now, NetBSD-current updates and recompiles, almost always flawlessly, sometimes while I am sleeping. The setup here is mostly generic and unmodified, just to track what's going on in the neighborhood, and to have the sources handy and available.
This brings back memories of running and rebuilding NetBSD-current -- was it thirty years ago?
Thanks to Linveo for sponsoring the build VPS.
If someone wants to share this fine, free VPS . . . teach me something . . . please ask.
July 4 edition, everything renewed! Thanks to @linveo!
Free share of this fine, fast, Ryzen VPS is still available!
Best wishes!
Qemu-guest-agent installed! Can now reboot from the web Control Panel! Thanks @linveo!