powerpc – GeekLAN

05/12/2023

Portable Legacy – Part 2

When I wrote up the previous post, there was a couple of points which I forgot to cover and since then a few more things have come up on the same subject that I want to go over here as a follow up.

I’ve been carrying on with the package building since the previous article and keeping on the same theme of old computer, old OS, old compiler, what can I build? (PowerPC mac, running OS X 10.4, with GCC 4.0.1). I resort to GCC 5 if I need C11 support & can go up to GCC 7 if needed. Have not yet attempted to package a newer version of GCC yet but after a certain point beyond GCC 7, the currently supported versions of GCC (11 and above?) require interim toolchain builds to go from a system with only GCC 4.x to 10+. Taking around 24 hours to build GCC 5 alone on the hardware I have at hand, I’m putting off attempting toolchain related changes as much as possible.

One thing I seem to spend a lot of time doing is trying to dig into finding requirements for software since the current trend is at most to list the names of components, without any version info. There are a couple of scenarios where the requirements are skewed indirectly.
The software I want to build has modest requirements, but they require a critical 3rd party component which depends on newer tooling, thus setting a higher requirement and sometimes it’s just the build infrastructure which has a far higher system requirement.
Of course if I was working on a modern systems with current hardware it wouldn’t be a problem since either binaries would be readily available or building would not take much time, but perhaps if you’re going to strive for minimalism, avoid requiring build tools which need the latest and greatest language support and beyond.
No matter how much of a time the shiny new build infra will save, it would take many days for me to get up to having the tooling in place in order to attempt building your project.

I find myself in the situatio where I now appreciate autoconf in these scenarios and think that projects should carry the infra for both autotools & more fancy tooling.
Autoconf may be old, odd, and slow, but it has been dragged through many scenarios and systems and has built up knowledge of edge cases, and in the world of old machines and uniprocessors, something that reduces down to a shell script and make files is just fine for such systems. A PowerBook would appreciate it, an iBook definitely would.
Hence, I’ve been holding back versions in some cases where the projects have moved on to different infrastructure, pinning things to the last version to support autotools, for now. Through doing this, I discovered that sometimes there were no mirrors kept for the source files, the source archives are published on their repo but it’s an archive generated from the source tag, not the bootstrapped release archive which would’ve been published originally, resulting in a detour to bootstrapping before attempting to build and additional build dependencies to pull in autotools. I guess I could patch that infrastructure in, having bootstrapped separately, but that would be a hefty diff.

Whilst making progress with packages, I made a discovery as to the source of my troubles with pthread support detection, that I wrote about in the previous post, the common failure is to just check for the presence of the header file and not checking for the implementation details. It turns out, this is largely due to gnulib, the GNU portability library that is vastly used in the GNU ecosystem. The issue there is the detection of pthread support is split across several modules which cover different aspects such as “is there a pthread.h?”, “is there support for rwlock?” and in this fragmented way, it is possible to misdetect functionality, since projects are selective in what they import from the library. One issue, now fixed, was the miss detection of support for rwlock, which OS X Tiger & prior lack. If projects import all of the pthread components from gnulib, detection of pthread support works correctly and gnulib build process makes the correct substitutions and then its tests suite passes ok. If only some parts have been imported things fail when running the test suite since for example the test for pthread support tries to make use of rwlock support in the testcase. There are many other issues with gnulib and its test suite broadly, completely separate from pthread support that for now I’ve skipped on running the gnulib tests. I am unaware of the scope of breakage in the library since attempting to generate a library comprised of all components in gnulib take some time and disk space to generate (documentation states 512MB disk space but I crossed a couple of gigabytes before aborting). I have been working my way through the GNU software projects to see what’s broken in the current versions related to gnulib. I’m sad to say GNU Hello is a casualty and currently unbuildable on OS X Tiger. There is a lot more work related to gnulib that I haven’t even started on.

Technical aspects of building software aside, one thing that is re-occurring is peoples response to legacy systems. On the plus side folks work on restoring functionality on old systems and others question the age of the system and whether it is time to rip out support for them. I can’t help to wonder if this is conditioning from the Apple side, since there is often support for other long dead operating systems from extinct companies/products that remain in a projects codebase. I was once asked if I try new software and technology as soon as it becomes available for a vacancy with them. As a user of an iPod Classic, PowerBook G4 running OS X Tiger, a 2007 17″ MacBook Pro, and a resume mentioning packaging for legacy OS X, I answered yes & awaited to hear back from them.

08/07/202308/07/2023

Portable Legacy

Something I’ve been thinking over on and off for a while, is the meaning of portability claimed by folks regarding software.
Fish out an old computer with a matching vintage closed source operating system, how does the portable software fair in such a situation?
Supporting an ancient operating systems when building recent software is enlightening, there’s so much room for dependencies to creep in, only to realise it when the dependencies are not there. Ideally, at the least, documentation would cover when said functionality was introduced so you have a vague idea in advance if something will work, but an exact idea of dependencies is needed to catalogue what is required.

Easy to deploy. Just add monocypher.c and monocypher.h to your project. They compile as C99 or C++ and are dedicated to the public domain (CC0-1.0, alternatively 2-clause BSD).
Portable. There are no dependencies, not even on libc.

I’ve been wading through building things on OS X Tiger again and looking for low hanging fruit to tick off. Armed with the stock version of GCC 4.0.1 from XCode 2.5, I’ve been avoiding going down the newer toolchain route and attempting to build anything which lists needing nothing more than C99/C++98 as I want to get as much done with the stock toolchain as possible since it reduces time starting with a fresh setup.

GCC 4.0.1 supports C99 and C++98, though according to the GCC wiki, C99 support was not completed in GCC until v4.5. GCC 4.0.1 defaults to C89, unless a standard via -std is specified. I can define __DARWIN_UNIX03 if I want to kick it up a notch for modernity, but that’s at least one version of SUS behind, implementing changes to existing functionality from IEEE Std 1003.1-2001 (defaults being older behaviour in some cases to accommodate migration to the then new behaviour, which has now become the expected behaviour).
Still, I have a compiler which recognises -std=gnu99 and a system which was on the way to UNIX03 certification but not (first reached in Leopard). See compat(5) from Tiger, Leopard, Catalina.
On my quest for low hanging fruit for things, I keep on getting caught out by software which claim to require just language support but really needing functionality beyond language support and 3rd party libraries from the the system.
Some examples of things which have tripped my up like

Stating -std=c89 and requiring a C11 supported compiler.
Claiming just C99 support but requiring POSIX functionality from IEEE Std 1003.1-2008.
With a C11 compiler installed (GCC 5), missing POSIX functionality from IEEE Std 1003.1-2008.
The assumption that PowerPC hardware means host is running Linux.
Python modules with Rust dependency (luckily that is a quick, hard failure on PowerPC OS X 🙂 )

More than just language support aside, another common issue is the misdetection of functionality through the test being too broad. Usually see this with pthread support, where more recent pthread support is required but all that happens from the build side is a check for the presence of pthread.h header file rather than checking for required functions like pthread_setname_np(3) / pthread_getname_np(3). Luckily, from the lacking user-space aspect there is help at hand, either via libraries which provide an implementation of missing functionality, or re-implement the functionality as a wrapper around existing functionality.
Sometimes there’s advice on how to use existing functionality for things which haven’t already been provided by compatibility libraries from the Windows community since they still have portability related issues on current OS versions.
Just stuck with things which need hardware/kernel support – memory atomic operations?
Going lower level, since the tooling is now so ancient, functionality which allows things to be treated generically across platforms hadn’t cross-pollinated. Non-platform specific mnemonics for assembler are lacking, and flags for linker to generate shared objects are missing.
Luckily the linker fixes is easy to patch and forward compatible with newer OS versions since they have retained backwards compatibility for the old way, specifying -dynamiclib instead of -shared which is what is now commonly used.

The Practice of Programming, written in the late 1990s, before C99 was standardised, has a chapter on portability.

It’s hard to write software that runs correctly and efficiently. So once a program works in one environment, you don’t want to repeat much of the effort if you move it to a different compiler or processor or operating system. Ideally, it should need no changes whatsoever. This ideal is called portability. In practice, “portability” more often stands for the weaker concept that it will be easier to modify the program as it moves than to rewrite it from scratch. The less revision it needs, the more portable it is.

Of course the degree of portability must be tempered by reality. There is no such thing as an absolutely portable program, only a program that hasn’t yet been tried in enough environments. But we can keep portability as our goal by aiming towards software that runs without change almost everywhere. Even if the goal is not met completely, time spent on portability as the program is created will pay off when the software must be updated. Our message is this: try to write software that works within the intersection of the various standards, interfaces and environments it must accommodate. Don’t fix every portability problem by adding special code; instead, adapt the software to work within the new constraints. Use abstraction and encapsulation to restrict and control unavoidable non-portable code. By staying within the intersection of constraints and by localizing system dependencies, your code will become cleaner and more
general as it is ported.
The Practice of Programming, Introduction to Chapter 8, Portability

When building Monocypher, I needed to drop -march=native from CFLAGS, s/-shared/-dynamiclib, and remove -Wl,-soname,$(SONAME) from the makefile in order for it to build on OS X Tiger. As stated on their homepage, there were no external dependencies.

Portable code is an ideal that is well worth striving for, since so much time is wasted making changes to move a program from one system to another or to keep it running as it evolves and the systems it runs on changes.
Portability doesn’t come for free, however. It requires care in implementation and knowledge of portability issues in all the potential target systems. We have dubbed the two approaches to portability union and intersection. The union approach amounts to writing versions that work on each target, merging the code as much as possible with mechanisms like conditional compilation. The drawbacks are many: it takes more code and often more complicated code, it’s hard to keep up to date, and it’s hard to test.
The intersection approach is to write as much of the code as possible in a form that will work without change on each system. Inescapable system dependencies are encapsulated in single source files that act as an interface between the program and the underlying system. The intersection approach has drawbacks too, including potential loss of efficiency and even of features, but in the long run, the benefits out weigh the costs
The Practice of Programming, Summary of Chapter 8, Portability

I guess the union approach is what you would call the autoconf workflow: test for the required functionality and generate definitions, based on the test results. Those definitions can then be checked for in the codebase to steer the build process.

It seems today portable software in most cases means with the listed requirements, you have a chance to build given an up to date, current, operating system, rather than building on the earliest version of where requirements are available.
For portability, in terms of future proofing, being explicit in expectations helps prevent breakage caused by riding defaults when in time defaults change.
As proof of portability, test, test, test, beyond current version of mainstream systems.
If not for extending support, to bring clarity to expectations of where the software will be able to run.

19/05/202319/05/2023

Running Uxn on Mac OS X Tiger

The road to Uxn started off with getting SDL2 built on OS X Tiger. Not being familiar with SDL at all I went in at the deep end with the latest and greatest release. As the bludgeoning progressed and the patches stacked up, I took a step back and wondered what’s been done already to get SDL2 installed elsewhere.

SDL2 has moved forward with targetting features found in newer OS releases so there’s a world of difference in functionality found lacking in OS X Tiger and SDL2’s expectations, sometimes it’s just been a gratuitous bump imposed by external factors. Consulting MacPorts and Tigerbrew to see how they handled packaging SDL2 I noticed that Tigerbrew had a patched version of SDL2 2.0.3 for Tiger specifically. Great, that’s a start. I knew that Uxn required SDL2, but wasn’t sure if it was a specific version or 2.0.3 would qualify. After some time compiling things (because a PowerPC G4 is mighty and slow) I had a version of SDL2. To be honest, I veered off into having the latest version of deps to compile against. Building latest release of FFTW on Tiger took some time due to a buggy m4 macro for autoconf which broke the configure stage on legacy OS X with GCC. At some point the FFTW’s build process needed to differentiate between compilers on OS X and adjust flags for linker and assembler but the two offending tests didn’t work on Tiger’s mighty compiler, since the test for assembler flag causes compiler to print an error saying flags are not supported but return 0, passing the test, and for the linker flags, compiler would error out but the test passed, resulting in subsequent tests failing due to unsupported flags being used. I initially tried to get autoconf to restrict the tests to newer versions of OS X but failed in getting it to do that. Searching around I discovered the autoconf-archive project which is a community contributed archive of macros to extend autoconf tests. Replacing the macro included in FFTW for the compiler flag checks with copies from the autoconf-archive resolved the build issue. There isn’t yet a script for invoking the compiler with flags for the assembler to test with (-Wa) but there is a separate script for invoking the compiler with linker flags (-Wl) and that’s sufficient to move forward, since the issue with assembler flags is specific to GCC 4.0.1 and did not occur on newer versions of OS X with a newer compiler when I tested.

With SDL 2.0.3 built from the patches Tigerbrew used, it was time to try Uxn. Invoking the build.sh script soon started spitting out errors, again, Tiger’s compiler was too mighty. Uxn relies on type redefinition and so requires a compiler with C11 support so that -Wno-typedef-redefinition will work. I used GCC 5 but according to the GCC wiki, anything since 4.6 should suffice. With a new compiler, the build progressed and errored out at the linking stage with one missing symbol. It was looking for SDL_CreateRGBSurfaceWithFormat and SDL 2.0.3 was too old. The function was introduced in SDL 2.0.5, looking into the source of 2.0.5, they raised the OS version requirement. 2.0.4 and prior had a Leopard minimum requirement and 2.0.5 targets Snow Leopard. Wanting to avoid a fight with a new release of SDL I looked into what alternative functionality was there in the version of SDL that I could use. SDL_CreateRGBSurfaceWithFormat was created to make it easier for the programmer to create surfaces, by specifying a single parameter value for pixel format. A successor to SDL_CreateRGBSurface which instead of a single parameter require each parameter of the pixel format to be specified individually. Though SDL_CreateRGBSurfaceWithFormat was introduced in SDL 2.0.5, SDL_CreateRGBSurface shipped with SDL 2.0, so I switched Uxn to use SDL_CreateRGBSurface and the build succeeded and then promptly failed to run when the build finished. Turns out Uxn requires joystick support but the SDL patch for 2.0.3 does not cover joystick support nor haptic feedback support due to the reliance in a newer functionality which is lacking in Tiger’s mighty ageing USB stack. This wasn’t so much of an issue since Uxn supports keyboard. Removing joystick support from SDL’s initialisation list and rebuilding Uxn resulting in a successful build and the emulator starting up with the piano rom (build script does this by default unless you tell it to not run the emulator with --no-run). Cool! lets play keyboard! *cue harsh noises emitting from laptop speakers* (following video link warning: turn sound volume down, don’t use headphones, link).

Problem Report window for OS X following a uxnemu crash

At this point I wasn’t sure if the issue was with the patched SDL build or Uxn. I chose first to rule out SDL and see if it’s possible to generate sounds ok with a simple test case. I found the Simple SDL2 Audio repo which I used as my test case. The source is just a couple of .c files and a header, leaving you to assemble things however you choose. This was my first time hand assembling a library then linking to it.

gcc audio.c -I/path/to/sdl2/headers/include -I. -c
ar -r audio.a audio.o
ranlib audio.a
gcc test.c -I/path/to/sdl2/headers/include -Xlinker /path/to/sdl2/lib/libSDL2.dylib audio.a

The test tool executed fine on my PowerBook and the wave files the tool played sounded as they should, so the issue was not with the patched version of SDL. I started to compare how things were done regarding the SDL API in Uxn and the Simple SDL2 Audio example, it seemed that endianness of audio format is a parameter and while the example code explicitly specifies a little endian format, the Uxn codebase uses an alias which defaults to the same little endian format. So SDL has the concept of endianness but the two codebases are trying to play different sound files, Uxn is playing PCM files, where as the example project is playing wav files which are little endian. Switching Uxn to use a big endian audio format resulted in the piano rom sounding correctly on my PowerBook since it’s booted in big endian mode. According to the SDL_Audiospec there are formats which default to the byte order of the system being built on. Using that instead resulted in correct playback regardless of endianness of the host system.

With Uxn working on my PowerBook running OS X Tiger, it was time to upstream the changes. As the project is hosted on sr.ht, I needed to become familiar with git’s email workflow by following the tutorial on git-send-email.io. Given an up to date version of OpenSSL, Perl, and git, I was able to upstream the changes to Uxn using my 12″ PowerBook G4 running OS X Tiger (look ma! no web browser!).

With the exception of skipping joystick support in SDL everything is upstream, but that’s a trivial one word deletion. So as it stands, to run Uxn on OS X Tiger, one needs to install SDL 2.0.3 and GCC 4.6 or newer (I used 5). Edit uxn/src/uxnemu.c and remove the SDL_INIT_JOYSTICK flag from SDL_Init() statement, then run Uxn’s build.sh.
See the Awesome Uxn list for links to get started once everything is built and ready to go.

10/04/202312/04/2023

Emacs builds for Mac OS X on PowerPC

Mac OS X has always come bundled with a version of Emacs, I see a copy of a binary named emacs-20.7 on the OS X 10.0 installation CD. On a fully patched version Mac OS X 10.4 Tiger, the version of Emacs is 21.2.1, 22.1.1 on Leopard and on more recent versions of macOS since Catalina it has been replaced by mg.

Screenshot of Terminal on OS X Tiger, running Emacs 21.2.1 as bundled with OS

I wondered what the most recent version of Emacs would run on Tiger. The Emacs for Mac OS X project maintained builds at some point and has copies to the most recent builds and impressively all their builds going back to 2009. Great, I fetched both the nightly and 24.5-1 build for Tiger and tried them, only to be presented with errors regarding _getrlimit$UNIX2003 symbol not being found when running the Emacs-powerpc-10_4 binary inside the Emacs.app. Double clicking on the Emacs icon attempts to launch the application and an icon appears on the dock before disappearing again. I left it there and started looking at building the most recent version which I could myself.

Screenshot of Emacs 22.1.1 running on OS X Leopard

Support for OS X prior to 10.6 Snow Leopard was dropped with Emacs 25 which is why the most recent builds were of version 24.5. I managed to build 24.5 on Tiger without issue, running the result not so much. It turns out that 24.x to 25 was a turbulent time for OS X support in Emacs. My build of 24.5 would launch, a blank window would show, CPU usage would spike and eventually crash and disappear.
Same result for 24.4.
On 24.3 things things were a little more compact but same crashing behaviour after a short period.

Screenshot of what's meant to be Emacs 24.3 running on OS X Tiger. There's just a thing bin of several sliders on top of one another.

The issue was apparently resolved in Emacs 25 but there’s more required than just this change for 24.5 as cherry picking It didn’t resolve the crashes and I didn’t investigate any further.

Emacs 23 was good. I had a working application on Tiger with 23.4.1.

Screenshot of Emacs 23.4.1 running on OS X Tiger

I headed back to Emacs 24 and built 24.2, and that was good too. Currently, I’m stuck on that version and haven’t yet investigated where things broke on the road to 24.3. Emacs 24 introduced support for installing packages from a remote repository. Due to its age, its concept of handling encrypted connections via TLS wont work with newer versions of OpenSSL since it tries to invoke s_client with SSLv2 turned off which of course is no longer a supported feature. Another option is to use GnuTLS but I haven’t yet managed to build a new version of GnuTLS on Tiger to use with it since GnuTLS has grown another TLS requirement which requires a compiler with C11 support. This is not so much of an issue for connecting to Elpa, but Melpa requires HTTPS and given a recent version of OpenSSL and Emacs 24.2 built with a modified lisp/net/tls.el to drop -no_ssl2, it’s still not happy about something and will sit there for some time and fail. I sidestepped the issue for now by using a Melpa mirror which works via HTTP, and needed a couple of changes from from Emacs 25 to packages.el for version handling, otherwise it would fetch the repository metadata and fail due to an invalid version.

Screenshot of OS X Tiger desktop, running Emacs 24.2 displaying the message buffer. There are messages of failed connection attempts with gnutls and opennsl s_client

If you’re looking for a newer version of Emacs with GUI support to run on your PowerPC Mac, I’ve posted the binaries here. The binaries were built on OS X Tiger 10.4.11 PowerPC with ./configure --enable-ns-self-contained --with-ns and run tested on OS X Tiger & Leopard PowerPC. No idea if/when another build will be, but they’ll end up in /files/macosx-powerpc-emacs/ if I do.

29/07/201903/08/2019

Something blogged (on pkgsrcCon 2019)

pkgsrcCon 2019 was held in Cambridge this year. The routine as usual was social on the Friday evening, day of talks on the Saturday, hacking on things on the Sunday.
Armed with a bag of bits to record the talks, I headed up to Cambridge on Friday evening to meet up with sborrill before heading to the Castle Inn. Not much to report from Friday night, drinks were drunk, food was ate, PowerPC hardware was passed on.

Saturday morning started off with a brief intro by sborrill and pr1w1, followed by the first talk of the day by nia about audio(9) in NetBSD and her work to improve support in 3rd party software. [slides]

bsiegert was next, speaking about spellcheckers and how without careful consideration when developing an API, one can prevent downstream consumers from moving forward with a project. [slides]

Those best practices, in slide form pic.twitter.com/Xs2lYR4KJ2
— mökki Suomessa (@bentsukun) July 15, 2019

This was preceeded by agc who gave the first of two talks on the work and methodoligies the team working on the OpenConnect appliances at Netflix use – life consuming FreeBSD-CURRENT and their development model (regular releases from the bleeding edge). The release they produce caters for several generation of hardware which is continuosly evolving, ranging from appliances based on conventional hard disk drives to all flash SSD appliances, and now, nvme based appliances.

We breaked for lunch at this point and went for a wonder to find the canteen.
First talk after lunch was by Natasa Milic-Frayling on Software preservation and digital continuity and the challenges with keeping legacy software running. Having successfully virtualised Windows based systems running all the way back to Windows 95, there were other challenges such as archiving distributed systems where proprietory software to be archived ran on one workstation, but data was sourced from other systems such as via ODBC or Active Directory (LDAP), increasing the scope of systems required to be archived in order for an application to function. As we move forward in time, legacy hardware becomes more fragile and harder to source parts for, unmaintained software which is no longer supported becomes a growing security risk, so, system get decommissioned but the data that lived on such systems may still be useful for reference.

After Natasa’s talk it was my turn to speak, I gave an update on the state pkgsrc support on OS X Tiger, followed by various books I’d read over the last 8 months and what I’d been working on in $dayjob, linking things back to Cambridge one way or another, turns out I had been reading about folks in Cambridge doing incredible work, it just happened that they were in Cambridge, Massachusetts along with the Mac Mini I was working form 🙂 [slides]

wiz followed on after me and spoke about the various groups in The NetBSD Foundation and the role they play in the day to day running of the project. From the board to the pkg-bug-handler teams and many others. [slides]

schmonz was our remote speaker, he gave a status update on the qmail distribution in pkgsrc and a new project called notqmail which provides a home as the upstream of this initiative. [demo and further info]

khorben revisited the topic of package signing with the work that happened in the past such as in EdgeBSD, improvements in NetBSD which could ease it such as developments in ptrace(2), and then opened up to a discussion around what’s required to provide signed packages.

agc wrapped up the day with the final talk, “large scale packaging” about how the packages which are shipped to the OpenConnect appliances are put together, using a cut back version of FreeBSD ports containing just the packages required.

Saturday night I headed back to London as I had a club night to attend before heading back on the Sunday. Somewhat drained, I made it home with the kit I’d carried up, showered, changed, and was back in Farringdon before midnight.

Advanced tickets for tomorrow night’s All Night Long @fabriclondon are SOLD OUT. Tickets available on the door for those who missed out. See you on the dancefloor open to close ? pic.twitter.com/Q2ghz69ud4
— Sasha (@sashaofficial) July 12, 2019

Come 2:30am, there was a powercut and that was the end of the night. I was a bit miffed as I missed the same event the previous year due to a clash of events so I was really looking forward to this.

20+ year wait to see Sasha at Fabric and the power goes out in the nightclub at 2:30am midway through his set… blerg @sashaofficial @fabriclondon pic.twitter.com/9mYsvGdgpF
— Chris MacPhee (@fingersmacphee) July 14, 2019

1/08/19 – The recording of the set is now available

I got some rest and made it back to Cambridge for lunch on Sunday. We then headed back to the Centre for Computing History for the last part of the con. I spent some time looking at the machines on display, played Sonic the Hedgehog and Street Fighter 2 both of which I hadn’t done in a long while and then helped debug an issue with booting NetBSD on QEMU as a guest when QEMU is invoked with --cpu=host. The host system in this case was flashed with libreboot which lacks microcode for the CPU and NetBSD crashes on probing the CPU. Explicitly specifying a CPU as a workaround in this case allowed the system to boot e.g --cpu=coreduo.

IBM ThinkPad X61s without microcode update

cpu0 at mainbus0 apid 0
cpu0: Genuine Intel(R) CPU 1400 @ 1.66GHz, id 0x6e8
cpu1 at mainbus0 apid 1
cpu1: Genuine Intel(R) CPU 1400 @ 1.66GHz, id 0x6e8

IBM ThinkPad X61s with microcode update

cpu0 at mainbus0 apid 0
cpu0: Genuine Intel(R) CPU L2400 @ 1.66GHz, id 0x6e8
cpu1 at mainbus0 apid 1
cpu1: Genuine Intel(R) CPU L2400 @ 1.66GHz, id 0x6e8

Post con, I spent a couple of days gallivanting around London with wiedi, weather was really hot but we managed to get a lot of milage down, from Brick Lane to Notting Hill Gate via the South Bank and Maida Vale, followed by a visit to Wembley for the London Hack Space. As always, it was a fun few days.

03/10/201806/10/2018

EuroBSDcon 2018

Last year for EuroBSDcon 2017 in Paris, I caught a horrendous cold on the first day and spent the week in a fragile state, this year I was well prepared and caught the terrible cold in advance. Things kicked off on Monday when I had to go and see a man about a goat at the train station as I was the chosen mule for this leg of the conference. No curried goat for dinner that night.

This was to be my first time in Bucharest and also the first time flying from London Luton Airport. I packed the goat and cough medicine and headed for the train station again on Wednesday morning. By lunch time I had met up with sborrill from the NetBSD release engineering team, we discussed the changes happening in NetBSD-HEAD and the tooling built on top of NetBSD at Precedence before setting off.

Thursday was about the FreeBSD devsummit for me or at least it was meant to be. For the flexibility of being able to use any computer without having to spread keys everywhere and the safety of travelling lightly without important keys, I use a Yubikey which contains a key that provides access to a few non-critical systems. At the devsummit, when it came time for our first break, I unloaded my key from the system and ejected the Yubikey, I don’t know what happened next in my head but when I came back I tried to load my key again from the Yubikey and entered an incorrect pin consecutively until the device was locked. This was a total disaster as I was not carrying the admin pin to unlock the Yubikey and I wasn’t sure what I had done at the time. I spent most of the devsummit trying to understand why I was unable to load my key and how to tell if the device was actually locked or not, documentation is pretty sparse and somewhat poor. It doesn’t help that there are multiple components required to use and manage a security token, all of which are independently developed with separate sets of documentation.

My favourite piece of documentation was from GnuPG.

PIN retry counter

This field saves how many tries still are left to enter the right PIN. They are decremented whenever a wrong PIN is entered. They are reset whenever a correct AdminPIN is entered. The first and second PIN are for the standard PIN. gpg makes sure that the two numbers are synchronized. The second PIN is only required due to peculiarities of the ISO-7816 standard; gpg tries to keep this PIN in sync with the first PIN. The third PIN represents the retry counter for the AdminPIN.

Hopefully, it might be edited at some point in the future.

I eventually gave up, conceding that I am locked out until I get home.

On the Friday, it was time for the NetBSD devsummit. We first covered hypervisors and support of different types of virtualisation in Xen, joerg gave a status update on his ongoing repository conversion work and what avenues it could potentially enable as well as a core and TNF board status update which segued into more technical details such as the DRM update. It was a fun day as we had the opportunity to ask questions and cover the answer in detail, something which is not possible in the conference talk setting. The discussion continued over dinner and late into the night.

For the first day of the conference, I spent the day in room 2. I heard the first of a series of talks on sanitisers, David Carlier and kamil co-presented on the state of sanitiser support. Sanitisers featured heavily at the conference this year which shows the importance of such tooling. Kristaps Dzonsons gave a talk about trying to utilise an open source stack for use with diving, from photo and video management to GPS and the rough edges with some options. Andrew von Dollen gave a talk about utilising the NPF Lua binding to provide a simple high-level interface to the firewall and in the spirit of the Scriptable Operating Systems with Lua paper, using the interface to explore different filtering scenarios with ease. NPF scripting with Lua was previously presented at EuroBSDcon 2014.

I was the last speaker of the day in room 2, I had hoped to present off NetBSD/macppc 8.0 on my 12″ G4 iBook but was unable to get it working with the projector due to genfb(4) not recognising it as connected. Instead I presented using maya‘s Dell XPS 15″ using the latest DRM update in NetBSD-HEAD and everything just worked. In hindsight I should have booted a kernel from HEAD to get radeonfb(4) and try again, but at the time I was actually thinking about recompiling my kernel! 🙂

The day wrapped up with the second keynote by Ron Broersma, he came equipped with a lot of historical memorabilia, It was cool to see a first edition copy of Computer Lib (you can order a copy from Ted Nelson here).

Ron spoke about the evolution of ARPANET & The Internet with an emphasis on the use of Berkeley UNIX. It was amusing to hear how UNIX tape images had been provisioned out to sites from government agencies, Bob Morris also mentioned the subject in An Oral History of UNIX and getting the initial image to the agencies.

The actually, pieces of the government, peddled the idea of using UNIX to
national security agencies. I kind of laughed at the people there. Because, are
they aware of the fact that the UNIX that they are now running actually got to
NSA in the trunk of my car.

As with Ted Nelson, Ron mentioned priesthoods which I believe is still prevalent in tech communities especially networking. Me and khorben discussed Patterns in Network Architecture: A Return to Fundamentals by John Day which provides insights about how things came to be and an alternative approach to address technical issues in modern day networking.

My favourite historical tidbit from the keynote was that in the pre DNS era when a hosts file was circulated, unofficial revisions were a thing and Berkeley hosts also appeared as Berserkeley on some. 🙂

Day two of the conference began with a heavy dose of sanitisers, kamil this time speaking about finding kernel bugs through the use of sanitisers followed by Yang Zheng on integrating libfuzzer with the NetBSD userland for Google Summer of Code and some of the bug he’d found in NetBSD as a result.

After lunch, khorben spoke about how he got into operating system development, his DeforaOS project and the approach in simplicity it takes with reference to John Day’s Pattern in Network Architecture book.

With a quick change over, maya spoke of the various bugs she ran into on NetBSD and her approach to debug them, covering everything from bugs on DEC Alpha to MIPS to drivers.

For the last stretch of the conference, I headed down to Being a BSD user by Roller Angel. It was a talk about growing within a community and the personal challenges one goes through as they develop. Roller also provided support for users in a technical role and covered the tooling he used to help users learn, such as screen-casting. Afterwards, I headed back up to room 2 for agc‘s talk on source code tracking and the experience with various tools used over the years at Netflix. Things starting life as a bunch of scripts which were added to subversion, migrated to mercurial and now stored in git. Of the dingbats in the talk, my favourite was Jose which the intro for the section on OCA. When the conference finished, we headed out for dinner. Having heard Scott Long’s talk about Netflix at NYCBSDCon 2014, I asked agc about his experiences in the early days of the appliance project, over dinner we heard about suffering disk firmware issues and building a strategy to re-flash appliances, extending tooling like camcontrol(8) and improving build performance.

Snapped in London, when I returned on Monday:

maya & kamil also wrote up about their experiences here and here.

Slides for my talk “What’s in store for NetBSD 9.0” are available here.

21/07/201821/07/2018

Something blogged (on pkgsrcCon 2018)

For this years pkgsrcCon, the baton was passed on to Pierre Pronchery & Thomas Merkel, location Berlin. It wasn’t clear whether I would be able to attend this year until the very last minute, booking plane tickets and accommodation a couple of days before. The day before I flew out was really hectic and I did not get any sleep. I left home around 1:30am and made my way to St Pancras for the train to the airport as It was an early morning flight. Once we’d boarded the flight, I passed out without any recollection and came to just before we were going to descend. With less than two hours sleep and plenty of time to spare until the evening social I slowly made my way from the airport to the city centre. I roamed the city centre looking at the street art and jumping on and off metro stations between Jannowitzbruke and Westkreuz.

In the evening I headed to the social event and met up with others. I heard about the state of The Unleashed Operating System, the latest buzzword soup to add to current projects for instant success (block chain, AI and something else I forgot the to note down), debug work flow and lots of other things over food and drinks. I had taken my ThinkPad X60s alongside a 12″ iBook G4 to Berlin, with the plan to see if jdolecek with the machine in person could shed any light on a deadlock issue I experience when hammering the CPU with a kernel build while 2 or more CVS operations are in progress and to also get setup with Yubikey on NetBSD so I could commit from any machine with a USB port without having to copy my keys around to different machines.

On the first day of talks, between preparing slides, spz pointed out what I needed to get the Yubikey working with SSH on NetBSD. The current Yubikeys support multiple features (U2F, OTP, CCID). In order to use a Yubikey as a CCID device with pcscd, pcscd expects a ugen(4) device which doesn’t work on NetBSD because the USB keyboard driver ukbd(4) attaches to the Yubikey and prevents other modes of access. The workaround is to roll a new kernel with the device explicitly hard coded to use ugen(4). With that in place, I was able to checkout the developers source repo on the iBook. For the X60s, jdolecek rolled a fresh kernel with with the DIAGNOSTIC and LOCKDEBUG which we booted and reproduced the deadlock, unfortunately, there was no new information provided by these option, possibly indicating that it’s not a locking issue. A new kernel was rolled with an extra printf() which I tested with, however I couldn’t reproduce the issue with this change. Instead the CVS update just got slower and slower while the system operated normally (without deadlock). Unsure if it was the lack of bandwidth or a new behaviour, I gave up after several hours of the cvs update running. To rule out connectivity, my next plan is to test locally using a mirror of the repository using rsync and perform the CVS operations from that source instead.

I gave a talk titled “Something Old, Something New, Something Borrowed”. Something Old was about NetBSD/macppc, a homage to my first pkgsrcCon back in 2014 where I gave a short talk about pkgsrc on Tiger PowerPC with my 12″ PowerBook, Something New was about Upspin, Something Borrowed was about Minix3. Slides.

For coverage of the different talks and leot‘s experience in Berlin, see this blog post.

After a day of presentations we headed over to a restaurant where we chatted some more over dinner. While we waited for our food to arrive, we were given a demo of the J programming language by Martin, he described J as a pocket calculator on drugs. I’d previously heard of the K programming language and its cryptic syntax but had not seen anything with such a minimal and cryptic syntax in action.

For the following morning, uwe gave a talk about the Forth programming language and experiences with it, especially with OpenFirmware which originates from Sun Microsystems and was also used by Apple on the PowerPC based Macs. The cool thing about OpenFirmware is that hardware can itself contain a driver for OpenFirmware which gets loaded when the device is initialised, making OpenFirmware aware of how to interact with the device without any manual loading of software by the operator.uwe mentioned NetBSD/ofppc which builds on that by having a kernel without drivers for on-board hardware, instead relying on OpenFirmware to communicate with devices instead. He also described how it is possible to learn about how a system works by using the ccommand in OpenFirmware to disassemble modules, though he warned that unfortunately this didn’t work so well on Macs as symbols had been stripped from OpenFirmware environment. There was lots of references to follow up material to read up on, from The Evolution of Forth paper to uwe‘s notes.

After lunch time, we packed up and headed to a computer museum. On the way we spoke about emacs and workflows like using M-x make-frame-on-display.

On the Monday, I met up with sborrillfor breakfast before heading to the spy museum and doing some sightseeing. I headed back to c-base where I met Pierre, Youri & Sebastian. As it approached the evening, It was time to make way to the airport again. I was back home by around 1am, Tuesday morning, so glad I went 🙂

21/07/18 10:20BST – There has been backlash from residents to stop Google from setting up a new campus in Kreuzberg, Berlin.

04/03/2018

A week of NetBSD #1

I wanted to resume writing up notes about what I’d been working on as with the “A week of pkgsrc” series, this actually spans the last few weeks. 🙂

Things basically came together around the event of a late 2009 13″ MacBook entering my life. First port of call was to see state of NetBSD support since I last visited it.
I’m still running FreeBSD on my 11″ Air and so was keen to see if there had been any progress in NetBSD with regards to supporting the Intel based Macs. Unfortunately the same issue is still present, the system panics very early in the boot process kern/52229 when using the UEFI image and fails when enumerating CPUs present. I was able to get the system to boot using the conventional (non-UEFI) image by opting to boot without SMP & ACPI enabled. I used the MacBook install wiki article as a rough guide on gpt partitioning and got a daily image installed. The wiki article needed some attention as the syntax for commands did not apply but through this process I discovered a crash in gpt where a missing check in the source means that a null pointer is passed to one of the gpt commands.
e.g gpt show -a

Running the system without ACPI was not a good idea, turns out the thermal management does not get initialised and the system eventually switches off as a failsafe measure. I found this out through leaving the machine bulk building some of my packages, only to return to a machine that’s powered off.

GCC 6 has landed in NetBSD-HEAD and work is in progress to bring things into shape as the next revision of GCC shipped in NetBSD. Unfortunately cross compilation from macOS does not work at the moment (toolchain/53013) which limited my ability to experiment with different NetBSD kernel configuration while I was trying to look into the MacBook issue.

The one frustration with crash was that when the system panicked, the system would drop to DDB (the kernel debugger) but the keyboard would not be functioning. I realised that when running into panics on NetBSD/macppc in the past I’d always have a backtrace to include in my bug report. This was because the macppc kernel was built with the option to execute a backtrace command when entering the debugger and the amd64 one wasn’t. Asking on the tech-kern list to enable this option across the board I learnt of the shortfall of this approach and received suggestion on extending ddb, thus the dumpstack option was born and enabled by default. With this, setting ddb.onpanic sysctl to 2 for backtraces went away as well as setting the DDB_COMMANDONENTER option to run backtrace explicitly in kernel configuration files. The next step now is to extend DDB to show the panic message after the backtrace so that the panic message and the tail end of potentially lengthy trace is visible.

Up until very recently there was only support for PCIe based G5 PowerMacs using the POWERMAC_G5_11_2 kernel configuration in NetBSD, I am lacking such a system but do have a first gen G5 iMac which is PCI-X based. The initial work to bring up NetBSD on the G5 was actually done on a PCI-X based system long ago so I was curious what had diverged since then. Previous GSoC project participants used a repo in the NetBSD-gsoc sourecforge project to share their work, the two G5 related GSoC projects are there in a single repo. Some further work also took place on the port-macppc mailing list in 2013. It was a fun weekend albeit no further progress to seeing even a copyright notice on my part. However I learnt lots about the kernel build process, poked at lowcore.S and the boot process. I also learnt of an emulator called Mambo. Mambo was a full PowerPC system simulator, produced by IBM research. There are kernel configuration files to support Mambo (theoretically) in NetBSD & FreeBSD but unfortunately, I couldn’t find any binaries to try Mambo, along with that I also found the links for the PowerPC 970FX (G5 CPU) documentation all dead and the documentation removed from the IBM site. 🙁
To rule out the kernel working on a G5 but console being an issue, I tried experimenting with different frame buffers and found macofcons(4) broke the build (port-macppc/53004). After discussing with macallan@, macofcons(4) and the OFB_ENABLE_CACHE option have now been removed [1] [2], on the basis that though they may have worked at one point they cause more problems that solve.

macallan@ has been working on extending support for the G5 based systems and it is now possible to boot NetBSD on both the early PCI-X based systems as well as the PCIe models thanks to his work. I was finally able to netboot NetBSD on my first gen G5 iMac, this should come in very handy for pkgsrc work.

The NetBSD/macppc website has a supported system page which was due a review. After a call for feedback on any discrepancies , the awacs(4) soundcard driver is now enabled and I’m looking for a source to find out which systems shipped with which chipsets. Along the way NetBSD gained modem drivers for some of these systems but the page still states they are not supported.

In NetBSD, there is support for different buffer queue strategies for disk I/O, on the tier 1 ports such as i386 & amd64, the per-priority cyclical scan strategy is enabled by default, to bring macppc on par, it is now also enabled there by default too. Now to document the option so that it’s somewhat like the description of another strategy for read priority. See BUFQ_READPRIO and BUFQ_PRIOCSCAN in options(4).

This weekend I’ve been testing the HEAD-llvm builds on i386 & macppc as well as ATF testing, but I’ll write about that in another time.

Thanks to jmcneil, martin, mrg, pgoyette, uwe for the help and suggestions.

01/02/201701/02/2017

Lessons learnt from adding OpenBSD/x86_64 support to pkgsrc

Before even getting into the internals of operating systems to learn about differences among a group of operating systems, It’s fairly evident that something as simple as naming is different between operating systems.

For example, the generations of trusty 32bit x86 PC is commonly named i386 in most operating systems, FreeBSD may also refer to it as just pc, Solaris & derivatives refer to it as i86pc, Mac OS X refers to it as i486 (NeXTSTEP never ran on a 386, it needed a minimum of a 486 and up until Sierra, machine(1) would report i486 despite being on a Core i7 system), this is one of the many architectures which needed to hadled within pkgsrc. To simplify things and reduce lengthy statements, all variants for an arch are translated to a common name whiche is then used for reference in pkgsrc. This means that all the examples above are grouped together under the MACHINE_ARCH i386. In the case of 64bit x86 or commonly referred to as amd64, we group under x86_64 or at least tried to. The exception to this grouping was OpenBSD/amd64, this resulted in the breakage of many packages because any special attention required was generally handled under the context of MACHINE_ARCH=x86_64. In some packages, developers had added a new exception for MACHINE_ARCH=amd64 when OPSYS=OPENBSD but it was not a sustainable strategy because to be affective, the entire tree would need to be handled. I covered the issue at the time in A week of pkgsrc #11 but to summarise, $machine_arch may be set at the start in the bootstrap script but as the process works through the list of tasks, the value of this variable is overriden despite being passed down the chain at the begining of a step. After some experimentation and the help of Jonathan Perkin, the hurdles were removed and thus OpenBSD/x86_64 was born in pkgsrc 😉

The value of this exercise for me was that I learnt the number of places within the internals of pkgsrc I could set something (by the nature of coupling components which share the same conventions (pkgtools, bsd make)) and really the only place I should be seeking to set something is at the start of the process and have that carry through, rather than trying to short circuit the process and repeat myself.

Thanks to John Klos, I was given control of a IBM Power 8+ S822LC running Ubuntu, which started setting up for pkgsrc bulk builds.
First issue I hit was pkgsrc not being able to find libc.so, this turned out to be the lack of handling for the multilib paths found on Debian & derivates for PowerPC based systems.
This system is a little endian 64bit PowerPC machine which is a new speciality in itself and so I set out to make my first mistake. Adding a new check for the wrong MACHINE_ARCH, long forgotten about the previous battle with OpenBSD/x86_64 I added a new statment to resolve the relevant paths for ppc64le systems. Bootstrap was happy with that & things moved forward. At this point I was pointed to lang/python27 most likely being borken by Maya Rashish, John had previously reported the issue and we started to poke at things. As we started rummaging through the internals of pkgsrc (pkgsrc/mk) I started to realise we’re heading down the wrong path of marking things up in multiple places again, rather than setting things once & propogating through.

It turned out that I only need to make 3 changes to add support for Linux running on little endian 64bit PowerPC to pkgsrc (2 additions & 1 correction 😉 )
First, add a case in the pkgsrc/bootstrap/bootstrap script to set $machine_arch to what we want to group under when the relevant machine type is detected. In this case it was when Linux running on a ppc64le host, set $machine_arch to powerpc64le. As this is a new machine arch, also ensure it’s listed in the correct endianness category of pkgsrc/mk/bsd.prefs.mk, in this case add powerpc64le to _LITTLEENDIANCPUS.
Then correct the first change to replace the reference to ppc64le for handling the multilib paths in pkgsrc/mk/platform/Linux.mk.

The bulkbuild is still in progress as I write this post but 5708/18148 packages in an the only fall out so far appears to be the ruby interepreters.

07/01/2017

12″ PowerBook G4 PT5 – Electronic Battle Weapon

Preparation for a trip started off a little earlier this christmas. I planned to take my PowerBook on the road with me to Hamburg for 33c3. Previous attempts to use this machine as my primary system on the road in the past had been thwarted by leaving too little time to build & prepare before departure.
The system has been dual booting NetBSD & Mac OS X Tiger for some time now, recently I’ve been doing almost daily upgrades to NetBSD-HEAD on the system using the generated iso images from NYFTP.
My plan was to get the machine installed with a current build FireFox on NetBSD & bring the existing installed packages up to date. I managed to update the existing packages without any problems but it didn’t look like FireFox was going to build successfully. The package as-is currently in pkgsrc does not build on NetBSD/macppc. I was pointed to a patch in pkg/48595 which was pending commit and required testing. It cleared up the initial issue I ran into but the build still failed (see previous link on updates about the failure), though it took a little longer to fail in the day. After several days of failed build attempts I made sure I had an up to date copy of TenFourFox installed on Tiger and settled for Dillo on NetBSD instead.

My usage of Dillo stayed somewhat basic during the trip, despite having the Mozilla certificate bundle installed, I could see any obvious way to point Dillo to it & have it use it. Hence, any site using SSL I visited generated a certificate warning. Perhaps the config should’ve been done in wget?

Alexander Nasonov created packages for Dillo & Links-gui targeted for running under a minimal chroot but I did not get around to trying them out. There are chrooted browser packages for other browsers in his pkgsrc github repo. The screenshot above shows the www/dillo package’s dependencies, generated using pkgtools/pkgdepgraph

Moving on, the AirPort Extreme card in the laptop is based on a Broadcom chipset which has a flaw, it’s incapable of addressing memory above 1GB (30 bits) which means the driver needs to care for that or else the card doesn’t work. This is not unique to this Broadcom chipset, the BCM4401 10/100 ethernet interfaces which use the bce(4) driver also suffer from the same problem (unable to address memory allocated above 30 bits), the BCM580x ethernet interfaces which use the bge(4) driver suffer from not being able to address more than 40 bits. Going back to the wireless chipset, the bwi(4) driver which is used in the BSDs, originated from DragonFly BSD. This driver was put together by Sepherosa Ziehau using the documentation from a reversing effort in the Linux community. The bwi driver was then imported in to Free/Open/NetBSD and was eventually removed from DragonFly BSD. A new wireless subsystem was introduced in DragonFly which required change to drivers to work again and the bwi driver was never adapted. It now lives on in the other BSDs.

The version of bwi(4) driver came to NetBSD from OpenBSD, ported by Taylor R. Campbell back in 2009. At the time neither version of drivers could handle the 30 bit bug so you either ran with less than 1GB of RAM or used another card. In 2014 Stefan Sperling committed a workaround for this in OpenBSD. I wanted this fix in NetBSD so my wifi could also work & asked the NetBSD developers if such a change was appropriate in NetBSD. I was introduced to bus_dma(9) and the bus_dmatag_subregion() function, the bce(4) driver was my reference on how to use the function. Looked fairly straight forward, a single call this function and off you go, wasn’t too sure how it would fit into the bwi driver but I thought I’d have a go.

This was one of the things I was hoping to work on during my trip but It turned out to be the only thing I attempt. I happened to meet Stefan at 33c3 and we discussed the driver, the work around and the mighty days of the past when Damien Bergamini was hacking on the OpenBSD WiFi stack. In the OpenBSD driver Stefan had opted to deal with the issue of allocating memory in a specific region directly in the driver rather than adding a new interface to the kernel for such a task so with a bit of thought about the past and a review of the driver, I was given a diff of the changes and suggestions about where I could start making changes.

I still don’t know yet if it’s possible to lift the changes from OpenBSD and apply them to the NetBSD version of the driver, because the DMA framework is different between the systems.
Partially implementing the change Stefan made without all the bounce buffers he’d added in the OpenBSD driver didn’t work and using the bus_dmatag_subregion() function didn’t work either. I pursued the bus_dmatag_subregion() path during 33c3 and didn’t get anywhere. At this point I started looking deeper in the system by looking at the implementation. It was at this point that I discovered this function was defined to EOPNOTSUPP on PowerPC based systems. No matter what I had tried with this function it was a waste of time^W^W^Wvaluable learning experience about keeping documentation up to date & consistent.

sevan: share/man/man9: bus_dma.9: Give a heads up about bus_dmatag_subregion()

— NetBSD Src Changes (@netbsdsrc) January 2, 2017

At this point I started looking into adding support for tagged subregions so I could make use of the function. The implementation is fairly simple, a public function for a developer to use which performs various tests and a private function which is called to deal with the memory allocation. Unfortunately there were some missing members from the data structure on the powerpc side of NetBSD which needed further investigation and I stopped there for the time being.

For the trip I relied on a tiny Realtek RTL8188CUS based wifi adapter to get me network access. The card worked on the 802.1x enabled SSID at 33c3 using wpa_supplicant(8) on NetBSD/maccppc.

urtwn0 at uhub4 port 5 urtwn0: Planex Communications Inc. GW-USNANO2, rev 2.00/2.00, addr 2 urtwn0: MAC/BB RTL8188CUS, RF 6052 1T1R, address 00:22:cf:xx:xx:xx urtwn0: 1 rx pipe, 2 tx pipes urtwn0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps urtwn0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps

The driver for this card is now enabled by default in the GENERIC config file for NetBSD/macppc along with a group of other drivers for USB peripherals.

sevan: sys/arch/macppc/conf: GENERIC: Enable axen, cdce, run, upgt, urtw, urtwn, uchcom, uslsa, u3ginit, u3g, ugensa in the GENERIC kernel.

— NetBSD Src Changes (@netbsdsrc) January 2, 2017

Thanks to Stefan for his help and advice with the bwi driver and Alex for the chrooted browser packages! 🙂

23/02/201503/04/2015

A week of pkgsrc #7

Time again to write up what’s been happening on the pkgsrc front since last time, this time the focus hasn’t been so much around pkgsrc on Darwin/PowerPC but more about pkgsrc in general & not necessarily code related.
At the end of the last post I mentioned a gentleman who’d been working on pkgsrc/Haiku and posting videos of his progress, I managed to make contact with him (James) & discussed his work that he’d been doing on pkgsrc. He sent me copy of the repo he’d be working off so I could assist with the aim of getting everything upstreamed as in the current state everything would need to be reintegrated per quarterly release rather than only having to pay attention if a new issue has arisen.
After getting the correct version of Haiku installed in virtualbox, I discovered a nasty bug in the Haiku network kit, it was unable to detect when the end of the file had been reached & would continue (restart?), this was revealed when I tried to download the pkgsrc tar ball from via WebPositive, ftp from the terminal was not affected however. pkgsrc bootstrapped unprivileged without issue. Hint: use the nightly snapshots until there is a newer release than Alpha 1 available.
The integration of pkgsrc into the user-land on Haiku is not currently possible due to the way the user-land is constructed, from what I understood, each Haiku package contains a piece of the filesystem, all the packages are union mounted to construct the user-land dynamically when the system comes up. That aside, with my system bootstrapped, I attempted to build Perl and ran into another bug, it seems that the library path for libperl is not populated on haiku hence perl is able to “build” but unable to run, the workaround for this in the tree I was given was to symlink libperl into ~/pkg/lib & move on. I tried various things but was unsuccessful, I believe the problem is pkgsrc specific as the version of Perl available in haikuports do not need any special treatment and the rpath is passed in correctly.
The problem was trying to isolate the required change to fix the problem, whereas in pkgsrc a policy file is passed to the build to set how Perl should be built, haikuports clobbers the source & patches in a replacement, I stopped at that point.

At around about this time I received the good news about the NetBSD Foundation membership and commit bit so my focus moved to reading the various developer documentation & getting familiar with processes.

sevan.mit.edu finished a bulkbulid attempt of the entire tree which took the longest time so far to complete, through all the build attempts I uncovered a new bug, the range to use for numerical IDs of UID/GID, is not sufficient to cover all the packages in the tree that need to create an account. On further discussion with asau@, it was suggested the IDs are allocated randomly and should be fixed for consistency across builds. I started doing bulkbuilds of the entire tree on FreeBSD 10.1-RELEASE and stumbled across a very nasty bug. There is a version of tcsh package in the pkgsrc tree called shells/standalone-tcsh, this is tcsh built as a static binary & set to install to /bin (the only package in the pkgsrc tree which violates the rules and places files outside of $PREFIX by default?), this ended up overwriting the system bundled version of tcsh in FreeBSD & then deleting /bin/tcsh when the package is removed, this was fixed promptly by dholland@. It was also discovered that Python’s configure script had not been changed when FreeBSD switched to elf binaries and so still trimmed the name of libraries to account for the old linker which could not handle a minor version in a libraries filename (libpython.so.1, not libpython.so.1.0). All versions of Python had been patched in the pkgsrc tree to remove this change so that it used a consistent naming convention across all platforms. After discussing this with bapt@ (FreeBSD) at FOSDEM, it turned out to be bug and should be fixed in future Python versions once the fixes are upstreamed.

Koobs@ (FreeBSD) dug out the commit which introduced the change & the bug report.

The opportunity to join the pkg-security team came up & for the past few weeks I’ve been getting familiar with the processes of dealing with security advisories & listing them so that users who fetch the pkg-vulnerabilities database are notified if they have any vulnerable packages installed. The general advisory process is a little infuriating, based on my recent experience I’d say at the top of my list are the Oracle security advisories as they do not divulge any details other than “unknown” in version(s) X, PHP for the frequency, OpenSSL for the impact. On the one hand I was quite impressed that CVE IDs were becoming so familiar that I could spot, on the fly, an advisory that had been accounted for, but on the other hand quite upset that I was using brain capacity on this. The availability of information is quite frustrating too, issues which are assigned an ID but cannot by checked on Mitre’s site take extra effort to find the necessary information to include (Mitre are responsible for allocating the CVEs!), I should note that this is from public advisories, say from a distribution. Example, CVE-2015-0240 was announced today, the Redhat security team published a blog post covering the issue, the Mitre site at present says:
“** RESERVED ** This candidate has been reserved by an organisation or individual that will use it when announcing a new security problem. When the candidate has been publicised, the details for this candidate will be provided.”
The wording & the lack of information can also be frustrating because it’s not clear what is affected. Looking at it positively, the requirement for clarification on these discrepancies means I get lots of opportunities to approach new people in different communities to ask questions.

I created a new wiki article on the NetBSD wiki to start documenting the bootstrap process of pkgsrc on Solarish, Illumos based distributions. At present the article covers what’s required to bootstrap successfully on OmniOS, Tribblix, OpenIndiana and OpenSXCE.

One thing that’s clearly evident is my workflow needs attention, at the moment things are very clumsy, involving lots of switching around but hopefully that will be addressed in the coming month. The first thing I’ve done is setup templates for emails with the correct preferences specified so that I just need to fill the necessary information & hit send, the necessary settings are automatically applied. Still thinking about how to deal with the scenario where the system that work is being carried out on is different to the system where the patch is going to be committed from, this also happens to be a different system which a developer is using. How to deal with that in as few steps from reading, say a bug report, to generating a patch, testing it & committing a fix.

For testing patches on Mac OS X, I revisited running OS X as guest on a Mac running OS X with virtualbox. Attempts in the past had not been successful & it seemed from search results that the only approach taken was to use modified OS images for hackintosh which I did not want to take. I have a genuine machine & genuine license, I shouldn’t have to resort to 3rd party images to run this. After whinging on twitter & referencing some older links I was able to successfully virtualise Mac OS X 10.7 to 10.10 in virtualbox. Will follow up with the details on that in a separate post.

07/01/2015

A week of pkgsrc #6

Since the last post I’ve made some further progress with pkgsrc on Darwin/PowerPC again, the biggest achievement was fixing lang/ruby19-base, lang/ruby200-base and lang/ruby21-base which accounted for the breakage of some 1500 packages (variation of 500 or so modules for each version of Ruby). This was caused by the failure to build the DBM module, which on OS X required the inclusion of dbm.h as well as ndbm.h otherwise all tests fail and the module is not built. The frustrating thing is that there appears to be no documentation for the build process of Ruby, luckily, by Ruby 2.0 there was a comment added to ext/db/extconf.rb to shed some light on the issue:
# Berkeley DB's ndbm.h (since 1.85 at least) defines DBM_SUFFIX. # Note that _DB_H_ is not defined on Mac OS X because # it uses Berkeley DB 1 but ndbm.h doesn't include db.h.
pkg/49508 was committed prior to the 2014Q4 pkgsrc release but
pkg/49511 and pkg/49512 did not.

cross/h8300-hms-gcc, databases/java-tokyocabinet devel/py-argh lang/smalltalk net/ser include some additional files which weren’t accounted for previously pkg/49473 & pkg/49474 pkg/49476 pkg/49478 pkg/49496 pkg/49498 fixed that.

devel/commit-patch used the -a flag for cp(1) which isn’t available on older operating systems, pkg/49475 switched to the use of -pPR instead (which -a is an alias of).

graphics/ivtools failed to build successfully due to a packing issue due to the explicit specification of operating system in the name of one of the generated files. pkg/49497 switched the use of the LOWER_OPSYS & added missing item which addressed the issue.

security/CSP failed at the installation stage due to the target directory not existing, pkg/49499 fixed that.

mail/nullmailer referenced uid_t & guid_t but did not include sys/types.h, pkg/49523 fixed that.

net/dnsmasq referenced SIOCGIFAFLAG_IN6, IN6_IFF_TENTATIVE, IN6_IFF_DEPRECATED & SIOCGIFALIFETIME_IN6 but did not include netinet6/in6_var.h when building on OS X which broke the build. pkg/49524 fixed that.

lang/lua52 failed to build on Tiger due to sys/types.h, pkg/49526 fixed that.

lang/php55 bundles its own version of sqlite and requires the necessary flags to disable features not available pkg/49527 fixed that but the correct fix is to not build an entire new version solely for PHP’s use. I began to look but had flashbacks of dealing with the same issue in TCL.

For graphics/MesaLib I looked to build it using a newer version of binutils but it appears that support for Darwin/OS X/iOS and Mach-o is rudimentary and hence missing support in most of the tools. Support began being added upstream to binutils back in 2011 but is still not complete.

For devel/cmake supports the ability to specify the location of library & header files, this can be done by creating a file which includes the necessary declaration that is passed to the configuration process using the --init flag. Indeed when the configuration process displayed the correct versions of OpenSSL, CURL, Zlib, BZip among others from pkgsrc rather than the older system bundled versions, unfortunately the build still failed when it came to the linking stage as the paths to the libraries was prefixed with /Developer/SDKs/MacOSX10.4u.sdk, as a kludge just to progress with the builds, I symlinked /usr/pkg to /Developer/SDKs/MacOSX10.4u.sdk/usr, the build then succeeded without issue. Next task is to work out how to drop the /Developer/SDKs/MacOSX10.4u.sdk prefix correctly.

There are currently 11132 packages available on sevan.mit.edu for Mac OS X/PowerPC with a new bulkbuild of the entire tree in progress. There are also Intel builds of the entire tree being attempted by Save OS X (64-bit packages) and Jonathan Perkin (32-bit packages) which should further improve support for OS X in pkgsrc.

Whilst browsing I discovered a series of videos on youtube by DisneyDumbazz, he has also been covering his work on improving support for Haiku in pkgsrc at length.
He was also struggling with issue in Ruby, QT4 & Mesa it seems.

30/11/2014

A week of pkgsrc #5

Definitely more than a week, I’ve not had a chance to devote much time to this over the past few months due but have made sufficient progress to qualify another post.
The most import thing is apart from one PR, all previously submitted patches have now been committed to pkgsrc-current, pkg/49082 still remains.

With the introduction of GCC 4.9, the same changes needed to be applied to lang/gcc49 as with previous versions, pkg/49178 took care of that, however this highlighted another problem. 32bit & 64bit hosts running Darwin both identify themselves as powerpc in the uname(1) output which means that GCC is always built with multilib support disabled, even when building on a 64bit host.

The pkgsrc guide pdf now has the correct date since pkg/49216, previously it reported 18/09/2007.

Some of the cross compilation tools for micro controllers were hardcoded to use ksh to build with when in fact it was only required for NetBSD >= 5, this caused the build to break on Tiger (assuming because of the old version of bundled ksh), pkg/49311 fixed that for cross/binutils but the changes were also applied to cross/freemint-binutils and devel/binutils by the maintainer.

cross/avr-libc was previously broken because it was using the system compiler & headers instead of avr-gcc and the headers installed in pkgsrc during builds. pkg/49316 fixed this issue and upgraded the version to v1.81 of avr-libc.

It’s no longer a requirement to declare the MACOSX_DEPLOYMENT_TARGET environment variable to build lang/perl5. By default Perl declares this to be 10.3 which is no longer applicable on modern systems and when building with clang mmacosx-version-min is specified, making it redundant. This had been removed in pkgsrc via a patch and it broke the build for GCC users as without this variable the target defaults to 10.1 and Perl needs specific attention for versions prior to Panther. pkg/49349 added this variable back in for Darwin 9 and prior which were GCC only releases. Bug #117433 in the Perl RT was the source of the patch proposed to resolve the issue.

lang/ocaml now builds on Tiger, the workaround for the lack of support for -no_compact_unwind in the shipped linker was applicable to prior releases and not just specifically Leopard, pkg/49417 fixed that.

devel/py-py2app previously failed to build on PowerPC OS X due to an error in the PLIST, the use of the MACHINE_ARCH variable would expand to powerpc which raised a packing error. pkg/49418 fixed that.

graphics/MesaLib and devel/cmake still remain broken in the pkgsrc tree for Darwin PowerPC, I was able to generate a MesaLib package successfully by forcing static binaries which allowed the previously unattempted packages to be tried in a bulk build of the entire tree. Unfortunately I hadn’t caught a merge conflict from when pkg/49077 was committed and so devel/icu was not built, this caused a another large subset of packages to not be built.

Thanks to the pointer from Jonathan Perkin, after I’d resolved the merge conflict I removed the entry in /mnt/bulklog/meta/error and ran bulkbuild-restart to re-attempt building devel/icu & those which depended on it.

With these changes, there were over 10000 packages available on sevan.mit.edu but unfortunately that included lots of duplicate packages from previous bulk builds. pkgtools/pkglint has the ability to scan packages against a pkgsrc tree & remove duplicate/stale packages. Running lintpkgsrc -K /mnt/packages -pr took the number of packages down to 9200. There is an AWK based solution but I’ve not had a chance to try it.

I was able to get devel/cmake to build successfully by removing the references to /Developer/SDKs in Modules/Platform/Darwin.cmake and subsequently build packages such as databases/mysql56-client but I’ve not added the changes to the tree yet. Will look to add this in a future bulk build, I want to get MesaLib linking correctly first before adding more kludges into the mix. The next thing I want to try is using a newer version of linker from devel/binutils instead of the one bundled with Xcode.

25/08/2014

A week of pkgsrc #4

Shortly after the last blog post I had access to a couple of AIX LPAR. This would be my first time on a IBM PowerPC system and AIX, I’d applied for two AIX 7.1 instances, one defined as “AIX 7.1 Porting Image” and the other as plain “AIX 7.1”. The difference at a glance seemed to be the porting image had more gnu / common open source tools e.g GNU/Tar though both images had a version of GCC installed.

Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/local/bin/../libexec/gcc/powerpc-ibm-aix7.1.0.0/4.6.0/lto-wrapper Target: powerpc-ibm-aix7.1.0.0 Configured with: ./configure --disable-multilib --with-cpu=powerpc --enable-debug=no --with-debug=no --without-gnu-ld --with-ld=/usr/bin/ld --with-pic --enable-threads=aix --with-mpfr=/opt/freeware/lib --with-gmp=/opt/freeware/lib --with-system-zlib=/opt/freeware/lib --with-mpc=/opt/freeware/lib --with-mpicc=mpcc_r --with-libiconv-prefix=/usr --disable-nls --prefix=/software/gnu_c/bin --enable-languages=c,c++ Thread model: aix gcc version 4.6.0 (GCC)

The stock version came with GCC 4.2 built on AIX 6.1 whereas the porting image came with GCC 4.6.
Alongside the open source tools each instance also had proprietary tools installed including IBM’s compiler XLC, cc without any options invokes a man page which describes the different commands that represent a language at a level.

c99 – Invokes the compiler for C source files, with a default language level of STDC99 and specifies compiler option -qansialias (to allow type-based aliasing). Use this invocation for strict conformance to the ISO/IEC 9899:1999 standard..

The pkgsrc bootstrap process didn’t work too well by trying to allow it to workout things out for itself via cc so opted to use GCC specifically.

export CC=gcc

pkgsrc happily bootstrapped without privilege and I proceeded to install misc/tmux and shells/pdksh on AIX.

security/openssl comes with 4 different configuration settings for AIX, a pair of settings for the XLC & GCC compilers with a 32bit or 64bit target. It turned out that in pkgsrc it just defaulted to aix-cc (XLC with a 32bit target), pkg/49131 is now committed so the correct configuration is used, XLC successfully builds OpenSSL with a 32bit or 64bit ABI but GCC is only able to manage a 32bit target.

To switch compiler to xlc, declare it as the value to PKGSRC_COMPILER in your mk.conf.

Over the week I attempted to compile components of GCC 4.8 without much success, starting off with lang/gcc48-cc++ & falling back to lang/gcc48-libs.
The build process was very unstable, again as with the Tiger/PowerPC, the build would spin off & hang, pegging the CPU until killed. Attempting to restrict the processor time via ulimit didn’t have much effect.

Alongside trying to get GCC built on AIX, I kicked off building meta-pkgs/bulk-medium on sevan.mit.edu, the previously reported unfixed components prevented some of the packages from building again (ruby, MesaLib, cmake).

I began looking into fixing devel/cmake so that it would link against the correct version of curl libraries & use the matching header files, Modules/FindCURL.cmake in the cmake source references 4 variables which provide some control but I was unsuccessful in being able to pass these to the pkgsrc make process. While trying to resolve this issue I also discovered that on more recent version of Mac OS, the dependencies from pkgsrc ignored, opting for the use of the Apple supplied versions even though the pkgsrc version would be installed.

-- Found ZLIB: /usr/lib/libz.dylib (found version "1.2.5") -- Found CURL: /usr/lib/libcurl.dylib (found version "7.30.0") -- Found BZip2: /usr/lib/libbz2.dylib (found version "1.0.6") -- Looking for BZ2_bzCompressInit in /usr/lib/libbz2.dylib -- Looking for BZ2_bzCompressInit in /usr/lib/libbz2.dylib - found -- Found LibArchive: /usr/lib/libarchive.dylib (found version "2.8.4") -- Found EXPAT: /usr/lib/libexpat.dylib (found version "2.0.1") -- Looking for wsyncup in /usr/lib/libcurses.dylib -- Looking for wsyncup in /usr/lib/libcurses.dylib - found -- Looking for cbreak in /usr/lib/libncurses.dylib -- Looking for cbreak in /usr/lib/libncurses.dylib - found

mail/mailman had a missing README in PLIST which was handled differently between Tiger & newer releases. pkg/49143 was committed to fix that.

19/08/201425/08/2014

A week of pkgsrc #3

Didn’t uncover anything new in pkgsrc last week as my attention was more on coreboot, I had previously been building different parts of the tree on a couple of Mac’s which where disconnected from each other & copying packages to sevan.mit.edu manually for serving, as a first off this was a good idea but bad as an ongoing thing. What ends up happening is stale packages become left behind as they are unaccounted for, luckily there aren’t too many duplicates currently but it’s something which needs to be addressed in the set of packages currently available.

There is now a page on the NetBSD wiki to keep note of issues & ideas.

To test the status of AIX support in pkgsrc I joined the IBM Power Developer Platform which provides access to Power7/7+/8 systems running AIX 6.1 & 7.1 to build software on. This’ll be my first time on a Power system & AIX, looking forward to seeing what the OS is like.

With the addition of a G5 iMac to the effort kindly donated again by Thomas Brand, I started testing builds of lang/gcc48 on sevang5.mit.edu. Next step will be to get the two systems at MIT working together to build packages once I’ve been able to get GCC 4.8 to build successfully.

11/08/201420/01/2015

A week of pkgsrc #2

Following on from last week, I worked on components which caused large numbers of packages not to build.
textproc/icu failed to build due to localtime_r() not being used if either _ANSI_SOURCE or _POSIX_C_SOURCE is defined & using an opcode that the shipped version of assembler didn’t understand. Ticket #9367 provided fixes for both issues spanning over 2 years, pkg/49077 covers this but has not been committed.
databases/sqlite3 failed to link with ld: Undefined symbols: _OSAtomicCompareAndSwapPtrBarrier error, this is due to the lack of zone memory allocator, PR #49081 fixed this issue by defining -DSQLITE_WITHOUT_ZONEMALLOC for OS X releases prior to Leopard. This is PR was committed. A subsequent PR (pkg/49082) was raised to do the same for lang/tcl which also bundles its own copy of sqlite3 for its sqlite module, but has not been committed.

devel/pango was broken on OS X releases prior to Leopard as the package enabled the CoreText option by default but failed due to packing errors (CoreText is not available hence the .la file not existing when build has completed). pkg/49090 resolved the issue & was committed.

Packages for GCC 4.4 to 4.6 are now available, lang/gcc47 failed to build successfully with sh consumed all resources on a CPU before being terminated manually.

sh(22232) malloc: *** error for object 0x34e340: incorrect checksum for freed object - object was probably modified after being freed, break at szone_error to debug sh(22232) malloc: *** set a breakpoint in szone_error to debug sh(22232) malloc: *** Deallocation of a pointer not malloced: 0x34d7ab; This could be a double free(), or free() called with the middle of an allocated block; Try setting environment variable MallocHelp to see tools to help debug sh(22232) malloc: *** Deallocation of a pointer not malloced: 0x34e340; This could be a double free(), or free() called with the middle of an allocated block; Try setting environment variable MallocHelp to see tools to help debug checking sys/time.h usability... Makefile:16170: recipe for target 'configure-stage2-target-libgomp' failed gmake[2]: *** [configure-stage2-target-libgomp] Error 137

This behaviour has previously been observed when attempting to build GCC on the PowerBook

The stability of sevan.mit.edu was improved by re-applying the 10.4.11 combo update.

Currently in the process of fixing devel/cmake, cmake now get through most of the build (it was previously failed at 3%) but fails at the linking stage due to path issues. It picks up the pkgsrc version of CURL as /usr/pkg/bin/curl but tries to link against libraries in /Developer/SDKs/MacOSX10.4u.sdk/usr/pkg/lib which doesn’t exist.

The TenFourFox blog mentioned the effort thanks to Cameron Kaiser of Floodgap.

04/08/201411/08/2014

A week of pkgsrc #1

This is summary of the things I worked on along with the help of others over the last week on pkgsrc.
With the donation of sevan.mit.edu along with a G4 Mac Mini at pksrcCon 2014 I setup bulk package builds as per chapter 7 of the pkgsrc guide to generate packages for OS X.
The bootstrap process is now able to differentiate between gcc & clang, as clang tries to be GCC compatible it tries to pass itself as GCC in tests, this would cause an issue where the bootstrap would use /usr/bin/clang for some parts of the build & /usr/bin/gcc for others, on top of that, the bootstrap process was hardcoded to use gcc on Darwin. The bootstrap process now defaults to using cc & correctly detects if that is clang or gcc.

By default git attempts to use the Apple CommonCrypto framework which meant it would only build successfully on Leopard or newer, devel/git-base now links against openssl instead which means it’s consistent with other platforms using pkgsrc as well as being able to build on older releases of Mac OS X. Unprivileged builds of this are still currently broken on Tiger as tar tries to set the group ownership of files to wheel, a patch to fix the issue is awaiting to be committed.

security/sudo now builds on Darwin (confirmed on Tiger PowerPC & Mavericks), the no_exec module doesn’t build on Darwin & is switched off in the Apple supplied build of sudo, this wasn’t switched off in pkgsrc & caused the build to fail. There are more options set in the Apple build to improve posture which are not set in pkgsrc version, that needs looking into further & is on the TODO list.

The new release of help2man committed last week broke on Tiger due to NLS being switched off & the new version introducing additional translations of info pages. The patch in pkg/49059 fixes things so shared libraries are taken care of as with Leopard & the package is built with NLS support.

Currently working on trying to get graphics/MesaLib building with XQuartz, the version shipped with Tiger is based on XFree86 & MesaLib fails to link libraries, macports seem to have some fixes related to building on Tiger which I’m hoping may fix some of the issues.

Will also be looking at devel/cmake as it’s currently broken on Tiger which means things such as mysql server cannot be built at the moment.

Through the existence of a directory called devel in /tmp which was owned by a user other than the the one pbulk runs under, some critical components such as autoconf & tradcpp did not build on the Mac Mini, this caused many builds to fail, that aside, the Mini has managed to build 1064 out of a queue of 2083 packages over the last week.
sevan.mit.edu is currently down (due to possible hardware issues) & awaiting a reboot.

02/08/201417/02/2023

Packages for PowerPC Mac OS X with pkgsrc

Post is here for historical context, package builds are no longer maintained.

In pkgsrc there’s a facility which allows you to perform bulk builds of packages called pbulk.
Using this facility on a couple of donated systems I have started to generate packages for PowerPC OS X. Currently builds are performed on 32bit PowerPC Macs running OS X with pkgsrc-current. The binaries should in theory work on 64bit PowerPC systems and on Leopard but have not tested to confirm.
~~The packages are made available at sevan.mit.edu~~.
To utilise the packages on your system, fetch & uncompress the bootstrap archive which contains the pkgsrc tools.
curl -s http://sevan.mit.edu/packages/bootstrap.tar.gz | sudo tar -zxpf - -C /

Update your PATH & MANPATH variables
PATH=/usr/pkg/sbin:/usr/pkg/bin:$PATH
On Tiger
MANPATH=/usr/pkg/man can be declared in /usr/share/misc/man.conf
On Leopard use path_helper(8) and create a file in /etc/manpaths.d which just contains /usr/pkg/man.
This can also be extended to PATH by creating a file in /etc/paths.d/ containing one path element per line. This requires testing however as the impact is system wide.

Set PKG_PATH to http://sevan.mit.edu/packages/All/

Packages can then be installed using the pkg_add command, for example to install wget
pkg_add wget

This service is very much in its infancy & not stable yet, the current offering of packages is small but more packages are building on a daily basis albeit very slowly due to the age of the hardware.

If you’re interested in pkgsrc on Intel Macs try the Save OS X blog and Joyent packages which offer packages for Ilumos derivatives, Linux as well as OS X on Intel hardware.

Thanks to the generosity of David Brownlee, Thomas Brand & Justin Cormack for their generous donation of hardware.

27/05/201427/05/2014

12″ PowerBook G4 PT 4

Due to various factors, I’ve not had much of a chance to play with the PowerBook much this month, earlier this moth a follow up to PR/48740 happened, requesting feedback on new changes which had been committed that I’ve not had a chance to test yet.
One thing I did do tonight was to re-flash the SuperDrive with a RPC-1 firmware image which turns the DVD drive region-free.
The firmware images are hosted on MacBook.fr and cover Macs all the way back to G3’s.
Flashing was straightforward though I could only re-flash with the version currently on the drive. It was not possible to flash a newer stock or region-free image on the drive.
Aside from the firmware on the DVD drive, Mac OS also tries to enforce region locking, the Region X utility can reset the Mac OS related setting regarding content region.

09/05/2014

12″ PowerBook G4 PT 3

Since I last posted about dealing with pkgsrc on my PowerBook earlier this week, a patch has been committed which solves the linker issue on lang/gcc45 along with another fix related to how stripping of binaries is handled on Darwin. Unfortunately PR/48740 mentioned gcc44 to 46 suffer from the same issue but the patch has not been applied to gc44 or 46, I’m waiting to hear back from the committer.
One thing I forgot to mention in the previous post is that there is another issue with build process for GCC. There appears to be a deadlock issue where sh sits there chewing up CPU & context switching, at this point, aborting the build with & restarting again allows the build to continue.
Attaching to sh with gdb does not give any further insight as to what’s going on 🙁