Re: NetBSD 9.0 packages

[John Klos <john%ziaspace.com@localhost>]

Hi,

> Would you mind sharing, how you get those compiled?

Not at all.

> Trying to get some my boxes setup up ...
> (every second has a dead battery)

New-ish DS12887A+ modules can be bought for not all that much money, if 
you're willing to wait for shipping from Asia.

https://www.zia.io/~john/newclock.jpg

Normally, for building pkgsrc packages, I'd set up pbulk, even though it's 
not very friendly towards more modest processors. There are quite a few 
caveats, though.

First, I make a chroot and intall libkver.

Until someone fixes Perl, I've had to build Perl 5.28.2 inside of the 
pkgsrc-2020Q1 tree to get anything to work. This isn't too hard, though.

If I want to use the pbulk tools, then making pbulk requires a few 
changes. One, of course, is making sure older Perl is in the pkgsrc tree. 
Another is to set PKG_DEVELOPER=no in mk/pbulk/pbulk.sh because 
something's broken on a number of archs with regards to detecting the 
binary type. Next, devel/distcc has to be built as part of pbulk.sh, 
otherwise pbulk will never use it properly.

Of course, installing distcc doesn't help unless you have another faster 
machine to run the other end. You can use this guide if you like:

https://hackaday.io/project/218-speed-up-pkgsrc-on-retrocomputers

Then, after chrooting with libkver, I can either run:

/usr/pbulk/bin/bulkbuild-rebuild (package name)

or

cd /usr/pkgsrc/(category)/(package)/ ; make bin-install

The first requires that all prerequisites have been built already - it 
won't build them if they're not. On other platforms, I've simply iterated 
over the output of the success file (in meta, in bulklog) from another 
machine running pbulk, because we know that building in that order will 
take care of dependencies.

Scanning can't happen on our older machines because it'd literally take 
the whole quarter to finish scanning that quarter's tree, and running 
pbulk with scan files from another machine should work, but it'd require a 
minimum of 256 megs to reasonably be able to do anything.

The second option is really the only option right now because so many 
dependencies are broken, particularly devel/automake. Perhaps someone will 
have time soon to look in to workarounds / fixes for Perl, automake and 
python. I used to have my own patches for Python 2.7, but we really need 
Python 3.7.

Long term we need a fixed toolchain, perhaps with optional soft-float for 
packages that do too much floating point checking.

I hope this helps.

John