Four Seventeen...

 ===> build.sh ended:      Fri Feb  5 03:36:39 AKST 2021
===> Summary of results:
         build.sh command:    ./build.sh -j 5 -u -x -X /usr/xsrc release sets sourcesets iso-image-source
         build.sh started:    Thu Feb  4 23:19:31 AKST 2021
         NetBSD version:      9.99.77
         MACHINE:             amd64
         MACHINE_ARCH:        x86_64
         Build platform:      NetBSD 9.99.77 amd64
         HOST_SH:             /bin/sh
         MAKECONF file:       /etc/mk.conf
         TOOLDIR path:        /usr/src/obj/tooldir.NetBSD-9.99.77-amd64
         DESTDIR path:        /usr/src/obj/destdir.amd64
         RELEASEDIR path:     /usr/src/obj/releasedir
         Updated makewrapper: /usr/src/obj/tooldir.NetBSD-9.99.77-amd64/bin/nbmake-amd64
         Successful make release
         Building sets from pre-populated /usr/src/obj/destdir.amd64
         Built sets to /usr/src/obj/releasedir/amd64/binary/sets
         Successful make sourcesets
         Successful make iso-image-source
         build.sh ended:      Fri Feb  5 03:36:39 AKST 2021
===> .
beasty2021$

A more prudent decision ...?

 I just, just wrote my previous blogpost 12 hours ago -and I've already got a good deal of 2020Q4 built on Debian 10.

It ought to go without saying I'm doing all of this in Virtualbox, as I do with 9/10ths of the other things I write about (with the exception of 86box stuff). But the Debian VM I was building in was built wrong -the disk space was split and arranged oddly.

So this morning I packed up what I had built and then remade another VM -this time with 80 odd gigs and all on one partition, and splatted it back on there.

Ncurses, gcc-10, libcups and harfbuzz all built just fine -but it was building harfbuzz that I discovered that I'd run out of room. I had things build while I slept:

gcc-10

clang

LLVM

harfbuzz

...it turns out that clang and LLVM didn't build; presumably because of space issues. 

Basically, my strategy is the get the problematic builds (ncurses, libcups) built, then the larger ones (gcc-10, clang) ...after that, I'll tackle widget libraries (gtk,wxwidgets and qt) and hopefully after that I'll be able to build packages such as codeblocks and libreoffice.

The title refers to my move (back) to building on Debian instead of Centos. I know where Debian is going to be and what they'll be doing 5 years from now. IBM -not so much. I might be more interested in riding out the Centos drama if I was invested in the RedHat ecosystem to begin with -but I'm not. I've always preferred Mint, Debian or Ubuntu (in that order).

Mind you, the Centos VM feels cozy as a desktop, and I can see myself possibly setting up a RHEL or a "Rocky" Or a "AlmaLinux" secondary desktop in the future -but for the purposes of learning pkgsrc on Linux I think my time is better spent getting things working on Debian. Like I say, I know where they'll be 5 or 10 years from now.

Crossing the Stream; pkgsrc and Linux Contrarianism

For the last month the Linux world has been in an uproar about IBM Redhat changing CentOS from a RHEL clone to a RHEL beta. 

We have forks and everything -personally speaking, my money is on this one.

In response Redhat's expanded their developer's program -but that's not really interesting to me. At least not at the moment. I've been sitting on a Redhat Developer account since 2015 or 2016 (when they made it free) but I've never really been thrilled with Redhat -going back to when I bought 5.2 in 1998.

But for some reason I'm uncertain about, I'm interested in seeing if I can use pkgsrc on top of Centos/Streams. 

I'm not sure why, except I like the idea of providing a one-and-done newish platform on top of Centos -which, with streams, honestly won't be terribly different than Ubuntu Server (in terms of stability). I also see it in an odd (and possibly incorrect) hedge against low-level breakage on Streams. 

I'm on my 2nd day of building on here and have already worked some things out:

I've learned that post-install I need to add the ncurses-devel and gcc-c++ packages. 

For libcups/cups to compile I've made the following changes to /usr/pkgsrc/share/mk/platform/Linux.mk

[random@deadrat-localdomain ~]$ cat /usr/pkgsrc/mk/platform/Linux.mk |grep ULI

ULIMIT_CMD_datasize?=   /usr/bin/ulimit -d `/usr/bin/ulimit -H -d`

ULIMIT_CMD_stacksize?=  /usr/bin/ulimit -s `/usr/bin/ulimit -H -s`

ULIMIT_CMD_memorysize?= /usr/bin/ulimit -m `/usr/bin/ulimit -H -m`

ULIMIT_CMD_cputime?=    /usr/bin/ulimit -t `/usr/bin/ulimit -H -t`

Then I build (in order): ncurses, gcc10, clang, python27, python38, python39, flex,bison, gdb, screen,sudo,fonts/harfbuzz 

Doing it randomly seems to cause fonts/harfbuzz to break. 

People complain that RHEL/Centos' packages etc are too old, but that might actually be a mark in their favor when it comes to pkgsrc. At least, I haven't gotten this far before on Debian, Ubuntu or Fedora.

Which makes me nervous for when I try to build this on one of those -I suspect their systems may well be too new.

OI on VB; quick note-to-self

 To get proper graphics, the following need to be done: 

C:\Program Files\Oracle\VirtualBox>VBoxManage.exe setextradata OI-2021 CustomVideoMode1 1920x1080x16

C:\Program Files\Oracle\VirtualBox>VBoxManage modifyvm OI-2021 --graphicscontroller vboxvga

The resolution may/may not need to be adjusted in MATE (preferences -> system -> displays).

The text installer (an option from the mate boot disk) allows you to specify an IP and default router, instead of having it handled by Network Manager. 

ooof. 4 hours and 42 minutes to build 9.99.77!

 mkdir -p -m 0755 /usr/src/obj/releasedir/images

/usr/src/obj/tooldir.NetBSD-9.99.77-amd64/bin/x86_64--netbsd-install -r -p -c -m 444 NetBSD-9.99.77-amd64.iso /usr/src/obj/releasedir/images

iso-image ===> etc

make iso-image-source started at:  Sun Dec 27 07:55:04 AKST 2020

make iso-image-source finished at: Sun Dec 27 07:56:11 AKST 2020

===> Successful make iso-image-source

===> build.sh ended:      Sun Dec 27 07:56:11 AKST 2020

===> Summary of results:

         build.sh command:    ./build.sh -j 4 -u -x -X /usr/xsrc release sets sourcesets iso-image-source

         build.sh started:    Sun Dec 27 03:14:41 AKST 2020

         NetBSD version:      9.99.77

         MACHINE:             amd64

         MACHINE_ARCH:        x86_64

         Build platform:      NetBSD 9.99.77 amd64

         HOST_SH:             /bin/sh

         No $TOOLDIR/bin/nbmake, needs building.

         Bootstrapping nbmake

         MAKECONF file:       /etc/mk.conf

         TOOLDIR path:        /usr/src/obj/tooldir.NetBSD-9.99.77-amd64

         DESTDIR path:        /usr/src/obj/destdir.amd64

         RELEASEDIR path:     /usr/src/obj/releasedir

         Created /usr/src/obj/tooldir.NetBSD-9.99.77-amd64/bin/nbmake

         Updated makewrapper: /usr/src/obj/tooldir.NetBSD-9.99.77-amd64/bin/nbmake-amd64

         Successful make release

         Building sets from pre-populated /usr/src/obj/destdir.amd64

         Built sets to /usr/src/obj/releasedir/amd64/binary/sets

         Successful make sourcesets

         Successful make iso-image-source

         build.sh ended:      Sun Dec 27 07:56:11 AKST 2020

===> .

Command line:  ./build.sh -j 4 -u -x -X /usr/xsrc release sets sourcesets iso-image-source

Virtualbox, 4 cpus, Execution cap 95%, 10248mb of ram

----

Results from 11 Jan 2021:

----

make iso-image-source finished at: Mon Jan 11 03:33:14 AKST 2021

===> Successful make iso-image-source

===> build.sh ended:      Mon Jan 11 03:33:14 AKST 2021

===> Summary of results:

         build.sh command:    ./build.sh -j 4 -u -x -X /usr/xsrc release sets sourcesets iso-image-source

         build.sh started:    Sun Jan 10 23:54:07 AKST 2021

         NetBSD version:      9.99.77

         MACHINE:             amd64

         MACHINE_ARCH:        x86_64

         Build platform:      NetBSD 9.99.77 amd64

         HOST_SH:             /bin/sh

         No $TOOLDIR/bin/nbmake, needs building.

         Bootstrapping nbmake

         MAKECONF file:       /etc/mk.conf

         TOOLDIR path:        /usr/src/obj/tooldir.NetBSD-9.99.77-amd64

         DESTDIR path:        /usr/src/obj/destdir.amd64

         RELEASEDIR path:     /usr/src/obj/releasedir

         Created /usr/src/obj/tooldir.NetBSD-9.99.77-amd64/bin/nbmake

         Updated makewrapper: /usr/src/obj/tooldir.NetBSD-9.99.77-amd64/bin/nbmake-amd64

         Successful make release

         Building sets from pre-populated /usr/src/obj/destdir.amd64

         Built sets to /usr/src/obj/releasedir/amd64/binary/sets

         Successful make sourcesets

         Successful make iso-image-source

         build.sh ended:      Mon Jan 11 03:33:14 AKST 2021

===> .

386BSD at last!

So, Friday I was looking at the 386BSD repository (as you do) and noticed something quite interesting...

boot.exe

...wtf is a boot.exe? It is a DOS utility that allows you to boot an 386bsd kernel. Similar to (and the basis of?) the utility that used to ship in early FreeBSD cds.

After a brief test in VirtualBox (as you do) I set up an 86Box machine to test it out -and then another, and another, and so on.

Ignoring all of the dead ends and tangents, what I did can be summarized thusly:

1. I cloned the 386BSD 1.0 repository inside of WSL
2. I created a tar file (three, actually -a base, X386 and source) and put it on an iso
3. I created a new 86Box machine, with a 504mb (no larger -or 386BSD's install crashes) drive.
4. I added a second 504mb drive to that machine.
5. I attached that drive onto a working FreeBSD 2.0 86Box machine.
6. Booting into FreeBSD, I mounted the iso I created and the 386BSD drive and untarred all of the archives onto it
7. After shutting that down, I booted the 386BSD machine and from dos typed boot 386bsd.sma wd1a
8. I ran through the install process from the secondary hard drive to install 386BSD to the first
9. I "enjoyed" my new 386BSD 1.0 installation!

...mind the quotes. The install is very rough, and I had to do some things I'm not proud of (ln /usr/bin/true /usr/sbin/sendmail) and some things I shouldn't have had to do (cp /etc/MAKEDEV /mnt/etc/MAKEDEV) (cd /mnt/dev;MAKEDEV

...and the included source does NOT compile, though I can't rule out a fuck-up on my part.

There's quite a few subtleties to all of this; missing directories, odd permissions and at this moment it only seems to work with extremely specific 86Box machines (NEC Pentium, to be exact). Also the TERM variable seems to be set to xterm which is a complete W.T.F. Then there's the question of setting the date (you can, but it doesn't persist)

...but at this point, that's all trivia; the important thing is that I have a "working" configuration.

"Working"

Turbo Vision resources

Turbo Vision was a DOS "TUI" (text-based user interface) developed by Borland. It was later made open source. 

It's a bugger to track down!

After some searching I did manage to find this page: http://www.sigala.it/sergio/tvision/index.html which has copies of it on the 'resources' link. 

There's also a "public domain lib" out there somewhere -no luck tracking (the sources to) that down yet!