Table of Contents

1 Ressources

1.1 NetBSD URLs

NetBSD via rsync rsync://
NetBSD via mercurial
NetBSD/src via fossil
NetBSD/xsrc via fossil
PkgSrc via fossil
PkgSrc-WIP via fossil ???
NetBSD mailing lists
NetBSD® Release Engineering Status Site
Summary of daily snapshot builds
The Museum

1.2 PkgSrc-WIP

home git://

Switch an existing submodule's URL:

git submodule set-url wip git://

1.3 Syspkgs

NetBSD wiki / syspkgs
hubertf's NetBSD Blog / syspkg
NetBSD system packages (Experimental stage of syspkg)

1.4 Community

[2020-06-02 Tue]
HTML export of 'naked' irc: links is broken and drops the irc: prefix. Currently repeating the address as description is a workaround.

BSD Forums —▷
IRChat —▷ irc:/
IRChat —▷ irc:/


(20200118) Why you should migrate everything from Linux to BSD
(20200121) Why you should migrate everything from Linux to BSD - part 2

1.9 To Be Sorted In Somewhere Else

The main goal of this repo is to help you to pass the LPI 702-100 exam successfully!
Frederic Cambus / NetBSD
NetBSD on ARM (images)

2 Unsorted

2.1 NetBSD-9.*-{amd64,i386} VMs (I)

Added NetBSD-9_STABLE to my VM OS zoo again after a longer break.


  • No X11 for now.
  • Installed pkgsrc for later curiosity.
  • Users root and yeti (in wheel too) as a start.
  • pkgin install emacs26-nox11-26.3 sudo
  • /usr/pkg/etc/sudoers.d/group-wheel: sudo access for group wheel.

2.2 NetBSD-9.*-{amd64,i386} VMs (II)

My NetBSD-9.0_STABLE VMs (AMD64 and I386) seem healty and feeling well.

  • Updated them more than once via building from source ( and added the X11 related bundles that way.
  • Tried CVS and GIT for the sources (including PkgSrc) and despite it being near to unbearable slow, decided to stay with CVS at least for now.


  • Why is PkgSrc-WIP not available via CVS any more?
    • PkgSrc-WIP as GIT submodule of PkgSrc cloned via GIT would make sense.
    • Switching (back) to GIT probably will happen when my NetBSD guinea pigs no longer are VMs on my main not-eBook.
    • [2020-05-20 Wed]: Pssst! There is too!
    • [2020-05-29 Fri]: Aaand back to GIT. Cannot bear CVS's lack of speed any longer.
  • How should I manage own packages?
    • PkgSrc-Local as GIT submodule of PkgSrc cloned via GIT would make sense.
  • I see GCC44, GCC48 and GCC49 packages in PkgSrc. Will that help building the GCC46 based PropGCC (the toolchain for the Propeller1 chip)? Building PropGCC and the GCC-4.8 based PIC32 toolchain with contemporary GCCs is a major pain or even impossible!
    • [2020-05-21 Thu]: Nah! They are in PkgSrc but aren't installable.

2.3 NetBSD-9.*-{amd64,i386} VMs (III)

  • [X] … built 9.99-i386 ISO image on fresh 9.0_STABLE VM
  • [X] … upgraded 9-0_STABLE VM using 9.99-i386 ISO image
  • [X] … built 9.99-amd64 ISO image on fresh 9.0_STABLE VM
  • [-] … upgraded 9.0_STABLE VM using 9.99-amd64 ISO image

9.0_STABLE differs a lot and the unattended update via sysinst missed some points. A rerun of etcupdate in the running system was needed to fix them.

I previously updated NetBSDs only in place with, so this definitely deserved a try at least once and then I upgraded the 64bit VM using the old way.

2.4 NetBSD-9.*-{amd64,i386} VMs (IV)

In "Use sysupgrade?" I noticed that the release sets get built on 9_CURRENT as .tar.xz balls on amd64 while .tgz is used on i386. I saw that earlier but did not remember on which release, so I retried it on 9.0_STABLE and the outcome is the same.

Two terminal snapshots say more than 2000 pixels?

(ruth@netbsd9-amd64:1)/home/netbsd9$ date
Tue Jun  9 01:29:15 UTC 2020
(ruth@netbsd9-amd64:1)/home/netbsd9$ ls -sh obj/releasedir/amd64/binary/*
total 38M
508B MD5                                7.5M netbsd-INSTALL.gz
1.3K SHA512                             346K netbsd-INSTALL.symbols.gz
9.0M netbsd-GENERIC.gz                  3.6M netbsd-INSTALL_XEN3_DOMU.gz
454K netbsd-GENERIC.symbols.gz          5.5M netbsd-XEN3_DOM0.gz
9.6M netbsd-GENERIC_KASLR.gz            2.3M netbsd-XEN3_DOMU.gz

total 205M
1.0K MD5                                4.0M misc.tar.xz
2.9K SHA512                             8.1M modules.tar.xz
 38M base.tar.xz                        2.6M rescue.tar.xz
 57M comp.tar.xz                        6.5M tests.tar.xz
471K etc.tar.xz                         1.8M text.tar.xz
2.4M games.tar.xz                       5.5M xbase.tar.xz
7.2M kern-GENERIC.tar.xz                6.2M xcomp.tar.xz
7.4M kern-GENERIC_KASLR.tar.xz           24K xetc.tar.xz
4.3M kern-XEN3_DOM0.tar.xz               26M xfont.tar.xz
1.9M kern-XEN3_DOMU.tar.xz               19M xserver.tar.xz
6.9M man.tar.xz
(ruth@netbsd9-i386:3)/home/netbsd9$ ls -sh obj/releasedir/i386/binary/*
total 45M
572B MD5                                3.7M netbsd-INSTALL_XEN3PAE_DOMU.gz
1.4K SHA512                             8.3M netbsd-LEGACY.gz
8.3M netbsd-GENERIC.gz                  8.2M netbsd-MONOLITHIC.gz
447K netbsd-GENERIC.symbols.gz          5.8M netbsd-XEN3PAE_DOM0.gz
7.7M netbsd-INSTALL.gz                  2.4M netbsd-XEN3PAE_DOMU.gz
339K netbsd-INSTALL.symbols.gz

total 308M
1.0K MD5                                 12M man.tgz
3.0K SHA512                             5.1M misc.tgz
 52M base.tgz                            17M modules.tgz
 87M comp.tgz                           3.3M rescue.tgz
644K etc.tgz                             11M tests.tgz
3.2M games.tgz                          2.8M text.tgz
8.3M kern-GENERIC.tgz                   8.1M xbase.tgz
8.3M kern-LEGACY.tgz                     11M xcomp.tgz
8.2M kern-MONOLITHIC.tgz                 27K xetc.tgz
5.8M kern-XEN3PAE_DOM0.tgz               31M xfont.tgz
2.4M kern-XEN3PAE_DOMU.tgz               30M xserver.tgz

So it happens on 9.0_STABLE too and the big "WHY?" remains.

[2020-07-09 Thu]: sysupgrade two 9.99.* VMs by downloading the release files from NetBSD's daily builds showed no surprises.

2.5 NetBSD-9.*-{amd64,i386} VMs (V)

[2020-07-09 Thu]: Since updating to 9.99.69 dhcpcd timeouts. Manually using ifconfig and route yields a working connection. Other VMs don't show problems with 9.0_STABLE and other OSes. This should get noticed by others too. I'll give it some time before diving deeper into it.

[2020-07-10 Fri]: Oh! There were ifconfig.vioif0 files on both VMs just containing up and after removing them, dhcpcd stopped to timeout. So why did it work before? Or when did these files appear? I definitely have no answer!

2.6 NetBSD-9.*-{amd64,i386} VMs (VI)

[2020-10-20 Tue]: The two 9_STABLE VMs now are updated to a self built 9.1 and the update looked smooth.

(ruth@netbsd9-amd64:2)~$ cat /proc/version                                     
NetBSD version 9.1 (netbsd@localhost) (gcc version 7.5.0) NetBSD 9.1 (GENERIC) #2: Mon Oct 19 21:28:08 UTC 2020
(ruth@netbsd9-i386:1)~$ cat /proc/version                                      
NetBSD version 9.1 (netbsd@localhost) (gcc version 7.5.0) NetBSD 9.1 (GENERIC) #10: Mon Oct 19 19:44:29 UTC 2020

2.7 NetBSD-9_STABLE On Raspberry Pi1-{2,3}

[2020-07-23 Thu]: Ugly, ugly, ugly. The downloaded rpi.img does not install a swap, and I really wanted more control, so I tried rpi_inst.img which failed at the install step of formatting /boot complaining about a missing newfs_msdos. I retried with three more of these images from other build dates and the results were consistently disappointing.

[2020-07-24 Fri]: Retry with rpi.img. I decided that a swapfile is ™good enough™ for beginning to explore NetBSD on Pi1 and that I may later migrate the system to a different drive organised to match my preferences.

Finding out how to update the system was a puzzle. I did not expect sysupgrade to work correctly in this nonstandard setup with a different kernel naming and location, so I did not even try it.

A manual kernel install followed by using sysinst at least is a start:



Some questions remain:

  • Install the Pi2 kernel too?
  • When (or always?) update the "firmware" files?
  • It seems possible to rename the kernel to e.g. netbsd and just define this name in /boot/config.txt, but I haven't decided yet to deviate from the information and naming in NetBSD's wiki.

2.8 NetBSD-9_STABLE On Raspberry Pi2-{2,3}

[2020-07-25 Sat]: Basic install using armhf7.img from 2020-07-23. Mostly the same as the previous Pi1 installs.

2.9 NetBSD-9_STABLE On Raspberry Pi3-{2,3}

[2020-07-27 Mon]: Basic install using arm64.img from 2020-07-23. Mostly the same as the previous Pi1/Pi2 installs.

2.10 NetBSD-9_STABLE On Raspberry Pi{1,2,3}-{0,1}

[2020-07-31 Fri]: Another set of Pis (Pi{1,2,3}-{0,1}) got NetBSD9_STABLE today. The 6 Pis which were installed first (Pi{1,2,3}-{2,3}) will be updated to follow NetBSD_CURRENT and the ones from today will track NetBSD_STABLE.

2.11 WIP NetBSD9.99.xx on Pi4-{2,3}


[2020-10-01 Thu]: Got the Pi4/8G which shall get NetBSD, but need some sleep before installing and if Friday is too mean, it might even have to wait until weekend.

[2020-10-04 Sun]: Something is strange. I wrote the NetBSD image to the SD card multiple times with different tools and the Pi4 complained about not seeing a FAT partition.

[2020-10-11 Sun]: Retry. I prepared a RaspiOS-Lite SD card for looking at the boot EEPROM and update it if needed. Using raspi-config to switch the boot EEPROM to the latest version did the trick and the NetBSD image could boot. Probably the older boot EEPROM contents cannot boot from a GPT partition.

[2020-10-12 Mon]: Ok. Getting 🕉mmmptimistic about this and ordered a 2nd Pi4 for experimenting and as hardware backup.

[2020-10-13 Tue]: The 1st sweetie managed to build the 9.99.73 aarch64 release files. I'll delay testing a 9.99.72 to 9.99.73 update until the 2nd Pi4 runs too.

[2020-10-15 Thu]: The 2nd Pi4 arrived and in the late afternoon I'm starting to set 'er up like the 1st one.

[2020-10-16 Fri]: Still in setup mode and doing more testing. Meanwhile both have built 9.99.74 from own git cloned source trees and installing this succeeded. sysupgrade doesn't guess the right kernel for the Pi4, so that step has to be done manually. There are /netbsd and /boot/netbsd.img and sysupgrade upgrades the one in the root FS. This probably will be fixed when Pi4 officially is supported (in NetBSD10?) and sysupgrade (from PkgSrc) gets updated.

pi4-2$ uname -a
NetBSD pi4-2 9.99.74 NetBSD 9.99.74 (GENERIC64) #1: Fri Oct 16 13:46:43 UTC 2020  yeti@pi4-2:/home/netbsd-current/obj/sys/arch/evbarm/compile/GENERIC64 evbarm
pi4-3$ uname -a
NetBSD pi4-3 9.99.74 NetBSD 9.99.74 (GENERIC64) #2: Fri Oct 16 17:35:34 UTC 2020  yeti@pi4-3:/home/netbsd-current/obj/sys/arch/evbarm/compile/GENERIC64 evbarm

[2020-11-04 Wed]: Set up ssh via hidden service V3 (and V2 as long as supported) by enabling including of /usr/pkg/etc/tor/torrc.custom for local changes.

Both ladies in red got updated to a self built 9.99.75 without problems.

Like before sysupgrade installed /netbsd and didn't touch /boot/netbsd.img. Maybe if manually changing /netbsd to /netbsd.img it consequently would update that kernel flavour? Then only copying that one to /boot would be needed as final step. This needs a test run after the next build.

[2020-11-26 Thu]: Re(?)introduced /tmp as tmpfs.

Built 9.99.76 and installed it.

NetBSD pi4-2 9.99.76 NetBSD 9.99.76 (GENERIC64) #6: Thu Nov 26 03:02:11 UTC 2020  ruth@pi4-2:/home/netbsd-current/obj/sys/arch/evbarm/compile/GENERIC64 evbarm
NetBSD pi4-3 9.99.76 NetBSD 9.99.76 (GENERIC64) #7: Thu Nov 26 08:26:08 UTC 2020  ruth@pi4-3:/home/netbsd-current/obj/sys/arch/evbarm/compile/GENERIC64 evbarm

[2020-11-29 Sun]: The USB3-SATA adapters and the SSDs are recognised:

[     2.986446] sd0: fabricating a geometry
[     2.986446] sd0: 111 GB, 114473 cyl, 64 head, 32 sec, 512 bytes/sect x 234441644 sectors
[     2.996446] sd0: fabricating a geometry

Wrote and booted 2020-09-13-netbsd-raspi-aarch64.img.
It works!

I'll temporarily allow root to ssh in for migrating my setup from SD to SSD (after setting the password and giving them individual host names).

[2020-11-30 Mon]: Looks I'm halfway there.

  • [X] - Both Pi4 boot from SSD.
  • [X] - The ssh keys are copied from the old /etc/ssh.
  • [X] - I can work over ssh and mosh on them.
  • [X] - Both standard user accounts and homes are copied over.
  • [X] - src, xsrc, pkgsrc, pkgsrc/wip are present.
  • [X] - They got updated to 9.99.76 which simply was copied over from the previous SD card system.
  • [X] - tor is up and running.

[2020-12-01 Tue]: Just some burn in testing e.g. via and complete rebuild of all installed packages.

[2020-12-03 Thu]: rsync hiccups vanished after complete packages reinstall.

[2020-12-04 Fri]: Installing 1st release built completely in this USB3 SSD setup.

NetBSD pi4-2 9.99.76 NetBSD 9.99.76 (GENERIC64) #0: Thu Dec  3 23:26:12 UTC 2020  ruth@pi4-2:/home/netbsd-current/obj/sys/arch/evbarm/compile/GENERIC64 evbarm
NetBSD pi4-3 9.99.76 NetBSD 9.99.76 (GENERIC64) #0: Thu Dec  3 23:26:53 UTC 2020  ruth@pi4-3:/home/netbsd-current/obj/sys/arch/evbarm/compile/GENERIC64 evbarm

[2021-01-05 Tue]: I thought I previously managed the PkgDB migration, but despite the check script seeing no problem, the directory /var/db/pkg kept reappearing on both Pi4s. Placing symlinks into the old place pointing to the new locations seems to fix it. I'll retry without the symlinks again later.

[2021-01-22 Fri]: Got 9.99.78 now. and sysupgrade-ing the updates completely at home didn't yield surprises for long enough. Maybe it's time to switch to just downloading the updates now?

[2021-02-24 Wed]: Not much happening with my NetBSDish Pi4ers because I'm mainly waiting for NetBSD10 to be released and only then the Pi4ers will turn from lab rats into really used systems. Today just an update to at least somehow keep in touch with them.

No idea what happened: Pi4-2 fails to boot after that update and Pi4-3 is fine. I'll look at it another day. Maybe just copying over the system from the neighbour instead of searching deep and long is the way to go…

2.11.1 NetBSD on Pi4 Open Questions

  • dynamic clock frequency scaling?
  • read out chip temperature?

    While building release with -j4:

    (yeti@pi4-2:2)/home/yeti$ envstat
    		   Current  CritMax  WarnMax  WarnMin  CritMin  Unit
      temperature:    57.000   85.000                             degC
    (yeti@pi4-3:2)/home/yeti$ envstat                                              
    		 Current  CritMax  WarnMax  WarnMin  CritMin  Unit
      temperature:    58.000   85.000                             degC
  • UEFI updates? …
  • TFTP boot?
  • WiFi?
  • BT?
  • GPIO access?
  • how/where define a RTC?
  • when will sysupgrade guess the right kernel?

2.12 NetBSD-9_STABLE On Cubietruck{2,3}


[2020-08-03 Mon]: Installed NetBSD9_STABLE on cubietruck{2,3}. Straight forward, no USB-UART required.

2.14 Use sysupgrade?



upgrades across major binary releases might not work properly because of the lack of a reboot between the kernel installation and the unpacking of the sets.

Test: Upgrading 9.99.x to a newer 9.99.y (x≤y).

3, 2, 1, go!

  • Built ( the releases on 9.99.64/amd64 and 99.9.64/i386.
    On 9.99.64/amd64 the sets got built as *.tar.xz.
    On 9.99.64/i386 the sets got built as *.tgz.
    For a reason?
  • Installed sysupgrade, adapted the config file to the local paths and the sets' extension and enabled running etcupdate in sysupgrade, because needing to do it afterwards is not a win for me. Let it be one wash.
  • Ran sysupgrade -c myconfig auto.
    Watching install=/ is less boring! ;-)
    The etcupdate and postinstall tango in sysupgrade just behaved as expected.

Impressions and conclusions:

  • Going through my usual cheat sheet with the build and install commands from updating the sources over building and installing the kernel and the distribution is more entertaining.
  • Gluing the upgrade steps together in one tool can prevent making mistakes.
  • On a single system updated from sources I see no advantages in building the release first to use sysupgrade.
  • For upgrading from downloaded sets or for upgrading many systems from one self built release set sysupgrade is nice to have.
  • sysupgrade doesn't trigger a reboot after installing the new kernel so incompatibilities between the installed new userland and the still running old kernel can be a problem.

[2020-06-21 Sun]: Starting to use sysupgrade on 9_STABLE too. The aspect that an automatism helps avoiding errors seems to out weight the other aspects. Additionally the distance from building the release to having a matching iso-image too is small and having an uptodate iso is a nice add on.

2.15 TODO RAM disk only NetBSD

…as seen in #Netbsd:

2020-07-25 18:57 <openbsdtai123> A netbsd.rd would be a good idea ;)
2020-07-25 19:00 <Riastradh> openbsdtai123: You can already do that -- create a file system image file, say foo.fs, with makefs, and create a /boot.cfg menu item like
2020-07-25 19:00 <Riastradh> menu=Boot with ramdisk;fs foo.fs;boot
  • [ ] Find docs about this.
  • [ ] Test this.

2.16 Reminder: CA Certificates

pkgin install mozilla-rootcerts

…and read the hints shown at the start of installing mozilla-rootcerts.

2.17 Reminder: WireGuard®

Starting with NetBSD10:

$ man 4 wg

2.18 NetBSD Changes Its Default X11 Window Manager To CTWM

NetBSD Changes Its Default X11 Window Manager After Two Decades

Claude's Tab Window Manager

9.1 changes mention CTWM too

2.20 TODO UUCP on NetBSD

(ruth@netbsdX-i386:1)~$ uname -srm 
NetBSD 9.99.77 i386
(ruth@netbsdX-i386:1)~$ date | mail -s moo localhost!yeti
(ruth@netbsdX-i386:1)~$ sudo -u yeti mail                 
Mail version 9.1alpha 2009-02-25.  Type ? for help.
"/var/mail/yeti": 1 message 1 new
>N  1 ruth@netbsdX-i386.lo  Sat Dec 26 18:54   3/494   "moo"
Message 1:
From ruth@netbsdX-i386.localdomain  Sat Dec 26 18:54:56 2020
X-Original-To: localhost!yeti
Delivered-To: yeti@localhost
To: yeti@localhost
Subject: moo
Date: Sat, 26 Dec 2020 18:54:56 +0000 (UTC)
From: ruth@netbsdX-i386.localdomain

Sat Dec 26 18:54:56 UTC 2020

& q
Saved 1 message in mbox
(ruth@netbsdX-i386:1)~$ █

The default of NetBSD9.99's mail config looks UUCP friendly.

2.21 WIP Per Package ccache

[2020-11-11 Wed]:

Setting CCACHE_DIR in a package dependent way in mk.conf is simple (in .ifdef PKGPATH context):

## experimental per package ccache

That way each package build gets its own CCACHE_DIR location.


Find hooks (in mk/build/ to notice the end of the 1st build and limit the cache size to e.g. 1.5 times the 1st build's size.

2.22 WIP Own Packages Repository For Pkgin


My PkgSrc tree lives in /home/pkg/pkgsrc, so there are some non standard paths involved here.

[2020-12-30 Wed]:

/usr/pkg/etc/pkgin/repositories.conf contains only one active line:


After running …

pkg_bin_summary | gzip -9 > pkg_summary.gz 

… in the /home/pkg/pkgsrc.packages/All directory, pkgin "sees" the files:

$ sudo pkgin up                              
processing remote summary (file:///home/pkg/pkgsrc.packages/All)...
pkg_summary.gz                                100%   27KB  26.8KB/s   00:00    

[2021-01-02 Sat]:

Find a hook to automate updating pkg_summary.gz after package builds.

As a test I added …

## hack warning: build pkg_summary.gz after making a binary package
	( cd ${PACKAGES}/All && pkg_bin_summary | gzip -9 > pkg_summary.gz )    

… to my mk.conf to add a target which updates ${PACKAGES}/All/pkg_summary.gz to packages building.


  • Check for pkg_bin_summary being installed!
  • Updating the index might need to be secured against parallel access?

Stay tuned and 🕉mmmptimistic!

2.23 NetBSD-9.99/Clang (I)

[2021-01-08 Fri]: Building 9.99.77/clang ISO images (amd64 and i386) in 9.99.77/gcc VMs.

.../src$ ./ -c clang -x ...
  timestamp commit comment
src 2021-01-08 00:13:20 UTC (@1610064800) 5ac18f85f3 (-j2) fail in linking gdb
xsrc 2020-12-08 10:33:47 UTC (@1607423627) 09f8ca91  


[2021-01-09 Sat]: Retry after update.

  timestamp commit comment
src 2021-01-09 03:28:47 UTC (@1610162927) 1bdb883802 (-j2) fail in hxtool
xsrc 2020-12-08 10:33:47 UTC (@1607423627) 09f8ca91  

Retry with earlier src commit:

  timestamp commit comment
src 2021-01-06 20:38:09 UTC (@1609965489) 5b96986627 (-j2) fail in linking gdb
xsrc 2020-12-08 10:33:47 UTC (@1607423627) 09f8ca91  

NetBSD-daily/HEAD-llvm/202101062120Z currently is the only entry there, so going back to that date might be worth a try.

[2021-01-10 Sun]: Pull and retry…

  timestamp commit comment
src 2021-01-10 00:58:56 UTC (@1610240336) 95e413262c (-j1) fail in linking gdb
xsrc 2020-12-08 10:33:47 UTC (@1607423627) 09f8ca91  

Ok. No luck several times. I'll revisit this (sources from git) somewhen later.


  • Install 9.99.77/clang ISO images in amd64 and i386 VMs.
  • Built PkgSrc stuff with base clang.
  • Rebuild 9.99.77/clang ISO images on 9.99.77/clang systems. Maybe wait until 9.99.78?


  • Will sysupgrade work?
  • Upgrade via sysinst from a booted install image?

2.24 NetBSD-9.99/Clang (II)

[2021-01-11 Mon]: Retry building NetBSD/Clang using the source sets from NetBSD-daily/HEAD-llvm/202101101020Z fails (linking gdb) too.

[2021-01-13 Wed]: Use a bigger hammer?

...$ ./ -c clang -x -V MKGDB=no ...
#   compile  lint1/scan.o
/home/netbsd-HEAD-llvm/202101101020Z.wrk/usr/src/obj/tooldir.NetBSD-9.99.77-amd64/bin/x86_64--netbsd-clang -O2   -fPIE   -std=gnu99     -Wno-sign-compare -Wno-pointer-sign  -Wall -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-sign-compare    -Wreturn-type -Wswitch -Wshadow -Wcast-qual -Wwrite-strings -Wextra -Wno-unused-parameter -Wno-sign-compare -Werror -Wno-error=implicit-int-float-conversion    --sysroot=/home/netbsd-HEAD-llvm/202101101020Z.wrk/usr/src/obj/destdir.amd64 -I/home/netbsd-HEAD-llvm/202101101020Z.wrk/usr/src/usr.bin/xlint/lint1 -I. -DPASS=\"lint1.h\" -I/home/netbsd-HEAD-llvm/202101101020Z.wrk/usr/src/usr.bin/xlint/lint1/../arch/x86_64 -I/home/netbsd-HEAD-llvm/202101101020Z.wrk/usr/src/usr.bin/xlint/lint1/../common  -c    scan.c -o scan.o.o
/home/netbsd-HEAD-llvm/202101101020Z.wrk/usr/src/usr.bin/xlint/lint1/scan.l:144:29: error: implicit
      conversion from enumeration type 'tspec_t' to different enumeration type 'op_t'
return operator(T_ASTERISK, NOTSPEC);
       ~~~~~~~~             ^~~~~~~
1 error generated.

Ok. No luck again. I'll revisit this (from source sets at NetBSD-daily/HEAD-llvm) somewhen later.

  • Maybe there's a reason that there are only source sets?
  • Maybe I should know more about the development workflow?

[2021-01-14 Thu]: Ok. I'm not alone: only lists failed builds too.

2.25 NetBSD-9.99/Clang (III)

[2021-01-14 Thu]: The lint problem got two commits, retrying with updated 9.99.77 (via git) with ... -c clang -x -V MKGDB=n ... (amd64 & i386).

*** Failed target:  hammer2.o
*** Failed command: /home/netbsd-current/src/../tools/bin/x86_64--netbsd-clang -O2 -DHAVE_ZFS -fPIE -std=gnu99 -Wno-sign-compare -Wno-pointer-sign -Wall -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-sign-compare -Wreturn-type -Wswitch -Wshadow -Wcast-qual -Wwrite-strings -Wextra -Wno-unused-parameter -Wno-sign-compare -Wold-style-definition -Wconversion -Wsign-compare -Wformat=2 -Wpointer-sign -Wmissing-noreturn -Werror -Wno-unknown-pragmas --sysroot=/home/netbsd-current/src/../obj/destdir.amd64 -D_KERNTYPES -c /home/netbsd-current/src/usr.sbin/fstyp/hammer2.c -o hammer2.o.o
*** Error code 1

nbmake[7]: stopped in /home/netbsd-current/src/usr.sbin/fstyp

So I'm in sync with the errors showing up at e.g., and watching what happens there saves time and energy.

[2021-01-16 Sat]: Couldn't resist…

...$ CFLAGS=-Wno-address-of-packed-member ./ -c clang -x -O ../obj -T ../tools -X ../xsrc -V MKGDB=no -U -u release iso-image

Succeeded for amd64 and i386.


But something still is screwed. I cannot get PkgSrc bootstrapped on i386. The compiler thinks cross compiling were be needed.

The amd64 image has minor hiccups but I got PkgSrc up end enough packages installed to try rebuilding this system in place.

2.26 WIP NetBSD-9.99/Clang (IV)

[2021-01-17 Sun]: Crossbuilt a new i386 ISO on SDF-EU. After installing, clang again thinks it cannot generate native binaries.

ENOIDEA - No more ideas for the i386 problems for now.

That's the same misbehaviour as shown by the home built i386 ISO (from NetBSD-9.99/Clang (III)).

The VM installed from the amd64 image could get PkGsrc up and managed to rebuild it's own NetBSD release and ISO as kind of burn in test.

[2021-01-18 Mon]: Used the ISO's update function:

# uname -a
NetBSD netbsdX-llvm-amd64 9.99.77 NetBSD 9.99.77 (GENERIC) #0: Mon Jan 18 04:03:36 UTC 2021  root@netbsdX-llvm-amd64:/usr/src/sys/arch/amd64/compile/obj/GENERIC amd64

[2021-01-20 Wed]: Trying to build current HEAD (9.99.78) on the LLVMish 9.99.77/amd64 floods memory and swap on linking clang/clang.

[2021-02-22 Mon]: I'll watch NetBSD's builders until HEAD-llvm builds stop failing constantly and to definitely do it that way, I'll erase the related VMs.

(-: In his noodly name: Pasta and ramen! :-)

3 Famous Last Words

                         .----+----.       |  The END  |
                         | Repent! |       | is neigh! |
                         ·----+----·       ·-----+-----·
                              |  _    _       _  |
                              |\°v°  °v°     ò.ó/|
                                |_|\/|_|)   /|_|

4 The End