Hello again! This new year's update announces some interesting new beginnings for the FreeCAD project, though it's a little short since I got some much needed vacation time over the last two months.

OpenFOAM on One Core? Only 92 Hours! (for mipsel) In November a strange bug was found in the OpenFOAM package which led to only one core being used during builds, even though the logs reported an N core build. In the worst case scenario, on the mipsel architecture, this led to an increase in build times from 17 to 92 hours! I did some troubleshooting on this but found it a bit difficult since OpenFOAM uses a bespoke build system called wmake . I found myself wishing for the simplicity of CMake, and found there was an experimental repo implementing support for it but it didn't seem to work out of the box or with a bit of effort. I wonder if there's any consideration amongst OpenFOAM developers in moving away from wmake ? Anyway, OpenFOAM ended up getting removed from Debian Testing, but thankfully Adrian Bunk identified the problem, which is that the environment variable MAKEFLAGS was getting set to 'w' for some reason, and thus falling through the wmake code block that set up a proper parallel build for OpenFOAM. So, unsatisfyingly, as a workaround I uploaded the latest OpenFOAM version, 1906.191111, with unexport MAKEFLAGS . It would be nice to find an explanation, but I didn't spend much more time digging. So, to end on the good news, the newest bugfix version of the OpenFOAM 1906 release, from November 11th 2019, is available for use going into 2020!

Trip to FOSDEM 2020 and MiniDebCamp at the Hackerspace Brussels It was a bit last minute, but I finally decided to attend FOSDEM 2020. I had balked a bit at the cost since flights from the US are around $900, but decided it would be an important opportunity for FreeCAD developers and community to get together and possibly do some important work. Thankfully, Yorik and other senior FreeCAD developers thought it would be a good use of the project's Bountysource money to cover the cost of one ticket, split in half between myself and sliptonic, a developer from Missouri. He focuses on the Path workbench and FreeCAD in CAM applications, an area I'm interested in moving into as I now have such machining equipment available to me through my local ATX Hackerspace. The three of us will be giving a talk, "Open-source design ecosystems around FreeCAD", at 11:20 on Saturday, so please come by and say hi if you're able to! I'll be staying for a few days before and after FOSDEM, including attending the MiniDebCamp at Hackerspace Bruxelles on Thursday & Friday, interested in anything Debian/FreeCAD related, so I look forward to getting a lot of work done indeed!

Looking at BRL-CAD for Debian For the past several summers, FreeCAD has participated in the Google Summer of Code program under an umbrella organization led by Sean Morrison of BRL-CAD. BRL-CAD is a very interesting bit of software with a long history, in fact the oldest known public version-controlled codebase in the world still under development, dating back to 1983-12-16 00:10:31 UTC. It is inspired by the development ideas of the era, a sort of UNIX philosophy for CAD, made up of many small tools doing one thing well and meant to be used in a normal UNIXy way, being piped into one another and so forth, with a unifying GUI using those tools. Since it's made up of BSD/LGPL licensed code, it ought to be available as part of the Debian Science toolkit, where it may be useful for FreeCAD as an included alternative CAD kernel to the currently exclusive OpenCASCADE. For example, fillets in OpenCASCADE are somewhat buggy and unmaintainably implemented such that an upstream rewrite is the only hope for long-term improvement. BRL-CAD could potentially improve FreeCAD in areas like this. It turns out a Debian Request for Packaging bug for BRL-CAD has been open since 2005. I plan to close it! It turns out there's already existing Debian packaging work, too, though it's quite a few years old and thus some adaptation still is required.