NetBSD stuff

 mk.conf:

MAKE_JOBS=      4
DEPENDS_TARGET= bin-install

 ---

VBoxManage setextradata "NetBSD-92amd" CustomVideoMode1 1920x1080x32

 vesa list

vesa 0x160

---

 

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.

Long time, no nix!

Actually, that's not exactly true. I've been playing with the usual things and not really treading any new ground to speak of.

I've been playing off-and-on with NetBSD 8 in a virtualbox VM since May.

It's gotten a lot better (from my point of view). It's almost nearly useable as a replacement for Mint 18 ...almost. The performance isn't really there.

...and it wouldn't be, since there are no guest additions.

There are two tricks I've learned that makes life in VB a lot better for NetBSD 8:

1)SetExtras;
From the hosts' commandline:

VBoxManage setextradata $VMNAME CustomVideoMode1 1920x1080x16 

The "x16" is important. Your instinct will be to choose a color depth of 24, but it won't work. 16 will.

2)Use a custom xorg.conf in the guest:

I'm still working on this (is there a way to make Xorg see more ram? There's gotta be!), but this is what I have to date:

Section "ServerLayout"
    Identifier     "X.org Configured"
    Screen      0  "Screen0" 0 0
    InputDevice    "Mouse0" "CorePointer"
    InputDevice    "Keyboard0" "CoreKeyboard"
EndSection

Section "Files"
    ModulePath   "/usr/X11R7/lib/modules"
    FontPath     "/usr/X11R7/lib/X11/fonts/misc/"
    FontPath     "/usr/X11R7/lib/X11/fonts/TTF/"
    FontPath     "/usr/X11R7/lib/X11/fonts/Type1/"
    FontPath     "/usr/X11R7/lib/X11/fonts/75dpi/"
    FontPath     "/usr/X11R7/lib/X11/fonts/100dpi/"
EndSection

Section "Module"
    Load  "dri"
    Load  "dri2"
    Load  "glx"
    Load  "shadow"
EndSection

Section "InputDevice"
    Identifier  "Keyboard0"
    Driver      "kbd"
EndSection

Section "InputDevice"
    Identifier  "Mouse0"
    Driver      "mouse"
    Option        "Protocol" "wsmouse"
    Option        "Device" "/dev/wsmouse"
    Option        "ZAxisMapping" "4 5 6 7"
EndSection

Section "Monitor"
    Identifier   "Monitor0"
    VendorName   "Monitor Vendor"
    ModelName    "Monitor Model"
    HorizSync    31-80
    VertRefresh  30-100
EndSection

Section "Device"
        ### Available Driver options are:-
        ### Values: : integer, : float, : "True"/"False",
        ### : "String", : " Hz/kHz/MHz",
        ### : "%"
        ### [arg]: arg optional
        #Option     "ShadowFB"               # []
        #Option     "DefaultRefresh"         # []
        #Option     "ModeSetClearScreen"     # []
    Identifier  "Card0"
    Driver      "vesa"
    BusID       "PCI:0:2:0"
EndSection

Section "Screen"
    DefaultDepth 16
    Identifier "Screen0"
    Device     "Card0"
    Monitor    "Monitor0"
    SubSection "Display"
        Viewport   0 0
        Depth     16
    EndSubSection
#    SubSection "Display"
#        Viewport   0 0
#        Depth     24
#        Modes     "1920x1080"
#    EndSubSection
EndSection

I've also found that setting RAM between 4G and 6G is needed for larger apps (CLang, GCC) to finish compiling.




I've managed to compile xfce4 and MATE; Mate works well enough to use as a desktop.

Most applications I've tried so far work, with some exceptions:
1)Firefox "nightly" randomly crashes.
2)Codeblocks stalls and never completely starts
3)htop doesn't seem to report free RAM correctly
4)closing apps sometimes crashes MATE
5)vlc player doesn't handle videos as well as gnome-mplayer (it's unwatchable).

Again, it's very much a case of "so near and yet so far". All said and done though, after three days of compiling everything (source, pkgsrc) I have a reasonably functional desktop with most of the comforts of home.

NetBSD 8 is still in beta, of course -and it shows. But I'm having better luck with it and pkgsrc (under virtualbox) than I have with NetBSD 7.x, so I'm optimistic this will be a keeper once it's done!