Problem

I've been experimenting with GNU Guix lately, a potent & multipurpose "distribution of the GNU operating system." I typically use KDE's Plasma as a desktop environment, and Guix offers a plasma package for this, but it's not offered by the installer, being a little more experimental, so I've been using GNOME, but in doing so, I ran into an issue with the default power-saving configuration.

My test device was a laptop left at home, so waking the device while away was not straightforward. My first pass led me to the Power section of GNOME's Settings app, where the 'Automatic Suspend' option can be disabled to prevent suspending after a period of inactivity. I found that even this was not enough to disable suspend altogether. So long as I logged in first, the laptop would not go to sleep, but after updating the system with e.g. guix system reconfigure /etc/config.scm and rebooting, the system would soon enough become inaccessible to remote access.

It turns out this behavior is controlled by GDM. In Debian and other traditional systems, this might be resolved by editing a configuration file in /etc, but Guix is different. Here's the idiomatic fix for the Guix System.

Solution

A default /etc/config.scm will have a (services) section that might look something like this:

;; Below is the list of system services.  To search for available
;; services, run 'guix system search KEYWORD' in a terminal.
(services
 (append (list (service gnome-desktop-service-type)

               ;; To configure OpenSSH, pass an 'openssh-configuration'
               ;; record as a second argument to 'service' below.
               (service openssh-service-type)
               (service network-manager-service-type)
               (service wpa-supplicant-service-type)
               (service ntp-service-type))

         ;; This is the default list of services we
         ;; are appending to.
         %base-services))

Summarizing, we have (services (append (...) %base-services)), where the default GDM configuration is contained within %base-services. Replace %base-services with a call along the lines of (modify-services %desktop-services (config overrides)), specifically setting the gdm-configuration option auto-suspend to #f, like so:

(modify-services %desktop-services
   (gdm-service-type config => (gdm-configuration
      (inherit config)
      (auto-suspend? #f))))

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.

PySide 2 and KDE Maintenance in Debian

Recently, FreeCAD has been unbuildable in Debian Sid because of issues related to PySide 2 and the Python 3.8 migration. This is complicated by the fact that the upstream fix has been released but in version 5.14.0, which builds fine with Qt 5.14, although Sid currently has 5.12. Furthermore, the PySide 2 package itself isn't building at the moment either! Since FreeCAD depends on PySide 2 and Qt, and I use the Qt-based KDE as my desktop, it seems like taking on maintenance of PySide 2 is something I should do to get started in this realm. However, the Qt/KDE Team's packaging practices and tools are rather different than the ones I'm used to for Science Team packages. This makes sense: Science Team packages are very often a single Git repo, but Qt5 for example is really 44 Git submodules smushed together. As such, things are a bit different! Once I get things taken care of for the package, I will try to write up some notes to help others interested in getting started, especially since KDE packaging could use some help.

FreeCAD Sysadmin Woes Begone: DigitalOcean Sponsorship

I'm very happy to announce that the FreeCAD project is now among the many open source software sponsorships by DigitalOcean.

One of the first things I did when interested in FreeCAD was to try to take on the responsibility of maintaining the project's infrastructure, since that would free up time for people to work on FreeCAD itself. FreeCAD's 17 years old now, and some of our infrastructure stack is about as dated. However, it isn't easy to just move things, I had to get things up to speed first and try to minimize disruption, so it's been a slow process. I'll go into more details in a technical blog post on the matter after I've finished our migration, hopefully by the end of this month, including details on our new setup, with the goal of allowing people to get set up with a dev environment of our project tools so you can do some hacking on things yourself and help out if possible.

Thanks for your support

I appreciate any feedback you might have.

You can get in touch with me via Twitter @thekurtwk.

If you'd like to donate to help support my work, there are several methods available on my site.

Staging & Merging App::Link Functionality

In August, a major milestone towards unified, mainline mechanical assembly functionality in FreeCAD was reached.

One of the core challenges in implementing assembly functionality is the problem of topological naming. In a CAD model there are topological entities, such as solids, faces, edges, and vertices. We must choose some algorithm to name them so that you can refer to relationships to make an assembly. A simple example would be two cubes, connected by touching faces. If a parameter in your model changes, and after recalculation, your "Face_N" is on the wrong side of the cube, your assembly may break, or not be what you are expecting. Without a good approach to topological naming, parametric FreeCAD models won't be robust to changes and recalculations, which defeats the purpose of parametric modeling.

Because this is such a difficult problem, progress has been slow. However, recently a relatively new FreeCAD developer, 'realthunder', put significant work towards this problem, with a solution finally on the horizon. Because it required major changes to FreeCAD's internals, the review and testing period was and continues to be lengthy.

The milestone in particular was merging of a large chunk of this code, referred to in short as "App::Link functionality". This diff is huge: +70,441 -14,562 lines of C++. You can read more about it on the pull request itself.

I only played a minor contributing role in this effort, preparing a short-lived staging PPA to provide a package for testers after the pull request was opened in July, but it's rather significant news in terms of the project and so worth spreading. Mechanical assembly is (no surprise) a must-have for mechanical engineers interested in FreeCAD, and it's considered by some to be the last remaining blocker for FreeCAD's 1.0 release.

Extra links: notes for code reviewers from the PR author, for the dedicated readers out there.

• https://github.com/realthunder/FreeCAD_assembly3/wiki/Concepts

• https://github.com/realthunder/FreeCAD_assembly3/wiki/Core-Changes

FreeCAD Python 2 removal in Debian Testing

The Python 2 removal in Debian Testing continues, and with it, FreeCAD's Python 2 package is gone. However, upon upload, several new build failures appeared on the i386, mipsel, and s390x platforms. Turns out there was a regression in dwz, a software I had never heard of before. I tried troubleshooting but unfortunately had FreeCAD drop out of testing due to the Python 2 removal bug filed against it.

Luckily, when I filed a bug against dwz, Matthias Klose and Tom de Vries helped isolate and upstream the problem, with Tom even bisecting the regressing commit in the upstream bug. Thank you, you two!

After adding a workaround to fix those build failures, the new Python 3-only FreeCAD package is on its way to Debian Testing.

FreeCAD Python 3 support added for Ubuntu 16.04

Qt 5 & Python 3 builds for FreeCAD have been available on Ubuntu 18.04 and newer and Debian 10 and newer platforms for some time now. However, Ubuntu 16.04 was problematic due to its old Qt version, which meant a Qt 4, Python 3 build had to be produced. This had been on the back burner for a while because when I initially attempted backporting the necessary packages, I encountered some friction.

However, since it's the last holdout Python 2 platform, I took another look at things to try to speed up the "py2ectomy". It turns out that the missing package needed for a Python 3 build, pivy, was failing to build because of "PIE hardening", a Debian security hardening flag. I had all such flags turned on, so I just had to disable that particular one to get things going.

So, Python 3 builds are now available for Ubuntu 16.04 in the FreeCAD Daily Builds PPA, and they will be coming soon to the stable PPA as well. A new bugfix release has been made for stable, 0.18.4, so I am working on that first, and the Python 3 package will come with it.

Netgen and Pybind11 Builds

Good news for users of FreeCAD's finite element modeling workbench!

Integration with Netgen, a mesh generator, has long been an optional but off-by-default build option for FreeCAD, due to packaging difficulties. However, since I have taken over things in recent years, I have finally gotten things to the state where we can turn this back on by default. As part of this change, I am also building FreeCAD with Pybind11 instead of Boost.Python, marking another milestone in managing FreeCAD's dependencies.

Since this may introduce bugs, I've started by making this change for all of FreeCAD's daily builds in the Ubuntu PPA, as well as the package currently in Debian Unstable. Eventually, this change may come to the stable PPA.

OpenCASCADE 7.4.0

After more than a year of development (PDF warning), a new minor version of OpenCASCADE Technology (OCCT) has been released.

OCCT is the geometry & topology kernel of FreeCAD, and it is also a dependency for several related projects including Gmsh, IFCOpenShell, Netgen, and OpenCAMLib. New releases in OCCT generally herald stability and performance upgrades for core behavior. However, there are some breaking changes and so these improvements are yet to be seen.

For the time being, OCCT 7.4.0 packages are available in my OpenCASCADE PPA and by building the package directly from https://salsa.debian.org/science-team/opencascade.

OpenFOAM 1906

I uploaded the latest version of OpenFOAM, the toolbox for computational fluid dynamics. It's now available in Ubuntu 19.10, Debian Testing, and via the FreeCAD Community Extras PPA.

Gmsh 4.4.1

The latest version of Gmsh, a 3D finite element mesh generator, is also in Ubuntu 19.10, Debian Testing, and the Community Extras PPA. Thanks to Nico Schlömer for helping maintain this package.

Netgen 6.2.1905

This version of Netgen is only available via the FreeCAD Daily and Community Extras PPAs. Unfortunately Netgen has been stuck in the Debian NEW queue for over 8 months now.

GitHub Sponsors Program

I was accepted into the GitHub Sponsors program! GitHub is matching donations for the first year. Hopefully this helps fund my FOSS work, and FOSS work in general.

Thanks for your support

I appreciate any feedback you might have.

You can get in touch with me via Twitter @thekurtwk.

If you'd like to donate to help support my work, there are several methods available on my site.

FreeCAD 0.18 Release & Debian 10 Full Freeze Timing

The official release date of FreeCAD 0.18 ( release notes ) is March 12, 2019, although the git tag for it wasn't pushed until March 14th. This timing was a bit unfortunate as the full freeze for Debian 10 went into effect March 12th, with a de-facto freeze date of March 2nd due to the 10 day testing migration period. To compound things, since this was my first Debian release as a packaging contributor, I didn't do things quite right such that while I probably could have gotten FreeCAD 0.18 into Debian 10, I didn't. Instead, what's available is a pre-release version from about a month before the release which is missing a few bugfixes and refinements.

On the positive side, this is an impetus for me to learn about Debian Backports, a way to provide non-bugfix updates to Debian Stable users. The 0.18 release line has already had several bugfix releases; I've currently got Debian Testing/Unstable as well as the Ubuntu Stable PPA up-to-date with version 0.18.3. As soon as I'm able, I'll get this version into Debian Backports, too.

FreeCAD PPA Improvements

Another nice improvement I've recently made is migrating the packaging for the Ubuntu Stable and Daily PPAs to Debian's GitLab instance at https://salsa.debian.org/science-team/freecad by creating the ppa/master and ppa/daily branches. Having all the Debian and Ubuntu packaging in one place means that propagating updates has become a matter of git merging and pushing. Once any changes are in place, I simply have to trigger an import and build on Launchpad for the stable releases. For the daily builds, changes are automatically synced and the debian directory from Salsa is combined with the latest synced upstream source from GitHub, so daily builds no longer have to be triggered manually. However, this has uncovered another problem in our process which being worked on at the FreeCAD forums. (Thread: Finding a solution for the 'version.h' issue

Science Team Package Updates

The main Science Team packages I've been working on recently have been OpenCASCADE, Netgen, Gmsh, and OpenFOAM.

For OpenCASCADE, I have uploaded the third bugfix release in the 7.3.0 series. Unfortunately, their versioning scheme is a bit unusual, so this version is tagged 7.3.0p3. This is unfortunate because dpkg --compare-versions 7.3.0p3+dfsg1 gt 7.3.0+dfsg1 evaluates to false. As such, I've uploaded this package as 7.3.3, with plans to contact upstream to discuss their bugfix release versioning scheme. Currently, version 7.4.0 has an upstream target release date for the end of August, so there will be an opportunity to convince them to release 7.4.1 instead of 7.4.0p1. If you're interested in the changes contained in this upload, you can refer to the upstream git log for more information.

In collaboration with Nico Schlömer and Anton Gladky, the newest Gmsh, version 4.4.1, has been uploaded to wait in the Debian NEW queue. See the upstream changelog for more information on what's new.

I've also prepared the package for the newest version of Netgen, 6.2.1905. Unfortunately, uploading this is blocked because 6.2.1810 is still in Debian NEW. However, I've tested compiling FreeCAD against Netgen, and I've been able to get the integration with it working again, so once I'm able to do this upload, I'll be able to upload a new and improved FreeCAD with the power of Netgen meshing.

I've also begun working on packaging the latest OpenFOAM release, 1906. I've gotten a little sidetracked, though, as a pecularity in the way upstream prepares their tarballs seems to be triggering a bug in GNU tar. I should have this one uploaded soon. For a preview in what'll be coming, see the release notes for version 1906.

GitLab CI Experimentation with salsa.debian.org

Some incredibly awesome Debian contributors have set up the ability to use GitLab CI to automate the testing of Debian packages (see documentation.)

I did a bit of experimentation with it. Unfortunately, both OpenCASCADE and FreeCAD exceeded the 2 hour time limit. There's a lot of promise in it for smaller packages, though!

Python 2 Removal in Debian Underway

Per pythonclock.org, Python 2 has less than 5 months until it's end-of-life, so the task of removing it for the next version of Debian has begun. For now, it's mainly limited to leaf packages with nothing depending on them. As such, I've uploaded Python 3-only packages for new upstream releases of python-fluids (a fluid dynamics engineering & design library) and python-ulmo (provides clean & simple access to public hydrology and climatology data).

Debian Developer Application

I've finally applied to become a full Debian Developer, which is an exciting prospect. I'll be more able to enact improvements without having to bug, well, mostly Anton, Andreas, and Tobias. (Thanks!) I'm also looking forward to having access to more resources to improve my packages on other architectures, particularly arm64 now that the Raspberry Pi 4 is out and potentially a serious candidate for a low-powered FreeCAD workstation.

The process is slow and calculating, as it should be, so it'll be some time before I'm officially in, but it sure will be cause for celebration.

Google Summer of Code Mentoring

I'm mentoring a Google Summer of Code project for FreeCAD this year! (See forum thread.) My student is quite new to FreeCAD and Debian/Ubuntu, so the first half of the project has involved relatively the deep-end topics of using Debian packaging to distribute bugfixes for FreeCAD and to learn by exploring related packages in its ecosystem. In particular, focus was given to OpenCAMLib, since there is a lot of user and developer interest in FreeCAD's potential for generating toolpaths for machining and manufacturing the models created in the program.

Now that he's officially swimming and not sinking, the next phase is working on making development and packaging-related improvements for FreeCAD on Windows, which is in even rougher shape than Debian/Ubuntu, but more his area of familiarity. Stay tuned for the final results!

Thanks to my sponsors

This work is made possible in part by contributions from readers like you! You can send moral support my way via Twitter @thekurtwk. Financial support is also appreciated at any level and possible on several platforms: Patreon, Liberapay, and PayPal.

Intro

Hello all and welcome again to another of my monthly summary posts on my work in free software, with a focus on open engineering in Debian & Ubuntu. I'm fortunate to have the February 12th Debian 10 soft freeze deadline to scapegoat for my missed January update, and thanks too to February for being short enough to postpone it further and combine the two updates.

I've decided to go with a bit of a dryer chronological approach to this update as there's lots to cover. Worth highlighting, however:

Highlights

• New Debian upload for a FreeCAD 0.18 pre-release

• New Debian upload for OpenFOAM. An upstream switch from openfoam.org to openfoam.com and a different versioning scheme results in a massive version bump, 4.1 to 1812. That's over 1800 versions better. (Seriously though, it's about a 2 year bump in changes.)

• New Debian uploads for mesh generation softwares Gmsh 4.1.3 and Netgen 6.2.1810 -- though Netgen might miss Debian 10? It's stuck in the NEW queue.

• FreeCAD is participating in Google Summer of Code and I'm looking for a student to mentor

Timeline

Sponsorship

Verbal support by way of my contact info below is greatly appreciated, but if you want to help support my free software & open engineering work financially, I've made it easy with several options:

• Patreon

• PayPal

• Liberapay

• Wispay (cryptocurrency)

Any level of support is appreciated!

Contact

You can follow me on Twitter @thekurtwk.

I'm also now on Matrix, an open network for secure, decentralized communication, @kkremitzki:matrix.org.

gmsh bugfix; no gmsh 4 yet

At the beginning of the month, I uploaded gmsh 3.0.6+dfsg1-4. This had a patch submitted by Joost van Zwieten (thanks!) to fix Debian bug #904946 which was preventing gmsh usage in FreeCAD, as well as adding an autopkgtest to make sure that behavior remains.

New Coin3D transition; Pivy uploaded!

Near the middle of the month, Leo Palomo-Avellaneda, Anton Gladky, and I finished the transition for the coin3 package, which is a scene graph library and high-level wrapper of OpenGL. The new version is a pre-release coin3 4.0.0 which adds CMake support. It also fixes Debian bug #874727 which caused FreeCAD to segfault when importing an SVG. FreeCAD also uses pivy, a Python wrapper for coin, as a runtime dependency, and completing this transition has finished the last blocker for a Python 3 FreeCAD package, so thanks to Leo and Anton!

New release for med-fichier (not by me)

Another FreeCAD dependency had a new release this month, med-fichier 4.0.0. This software is developed by Électricité de France and built on the HDF5 library and file format but is specialized for mesh data. It is also a dependency of gmsh which introduced some difficulty for the gmsh package.

OpenFOAM upstream switch; from openfoam.org to openfoam.com

The final noteworthy item for this month was an interesting bit of correspondence I received concerning the OpenFOAM package. As I had mentioned in previous posts, the current OpenFOAM version in Debian is 4.x, and I had worked on updating the package for OpenFOAM 6.x. My packaging was working and complete last summer, but for an inexplicable reason it stopped building late summer, started building again for about a week in September, and then stopped again. I would really like an up-to-date OpenFOAM in Debian 10, and so when I received an email from the people at openfoam.com about packaging their version, I was very intrigued. You see, the version in Debian is currently from openfoam.org. Besides the TLD difference, there is a bit of history between the two versions, but for end users there should major difference. If you're interested in more background, you can consult this video by József Nagy.

Similarly, it seems likely that the OpenFOAM package will be changing over to the openfoam.com version soon. I've already succesfully built the latest OpenFOAM from this source, version 1812, and plan to submit it soon.

Thanks to my sponsors

This work is made possible in part by contributions from readers like you! You can send moral support my way via Twitter @thekurtwk. Financial support is also appreciated at any level and possible on several platforms: Patreon, Liberapay, and PayPal.

Intro

Welcome to another of my monthly summaries on my work in the free software world. My mission is to make engineering and science available for everyone, and Debian, the Universal Operating System, is my weapon of choice.

I received some feedback on my last post that I made it seem I would be stepping away from my role maintaining FreeCAD and other packages on the Debian Science Team, which was an unfortunate miscommunication on my part. Mainly, I just would like to reduce the proportion of my overall free software time on it, from its current amount, nearly 100%, to a roughly even 1/3rd split between Debian Science, FreeCAD, and PostCAD. The latter is a promising personal project to make an OpenCASCADE-powered CAD extension for PostgreSQL, bringing support for CAD file formats, datatypes, and algorithms to the powerful Postgres ecosystem, similar to what PostCAD has done for geospatial analysis. This could serve as a backend for both FreeCAD in the short term, and in the long term, it could power a web-based version of FreeCAD, perhaps with some Django-powered middleware serving a REST API for some WebGL-based frontend.

So, besides summarizing my work this month, I also plan to give a synopsis on my Debian packaging, for both what's in-progress and on my wishlist. As you'll see, it's quite extensive. My hope is that by whittling away at both lists, my Debian Science work can focus more on maintenance of existing packages, and free up some time for other things.

Sponsors

My work on Debian Science, FreeCAD, and PostCAD is supported by my patrons on Patreon <https://patreon.com/kkremitzki>. While I had created a Liberapay a while back, I never got any traction with it, and I found out recently that it was because I had not set it up to actually receive payments. So, if you don't like Patreon for whatever reason, you can also support me on Liberapay. Just to round things out, if you don't like either of those platforms, you can also help support my work via PayPal.

Transition for coin3

Coin3D is a scene graph library and a fundamental part of FreeCAD. Unfortunately, it hasn't had a release since 2011, but development has been picking up recently, so it's likely that a release is not too far off. Even without a formal release, several improvements have been made including CMake support, so it's time to prepare a transition in advance of the Debian 10 release. Luckily, Leo Palomo-Avellaneda has taken the initiative of getting this transition started.

Currently, the new Coin3D package is available in Debian Experimental as we prepare the reverse-dependencies to build against it. For FreeCAD, we directly depend on Pivy, which are Python bindings for Coin. Pivy, in turn, depends on Coin and SoQt, which is a Qt GUI component toolkit library for Coin. A pre-release version of SoQt is also being packaged since, like Coin, CMake support has been added, as well as support for Qt 5.

Unfortunately, I've been grinding my gears on building Pivy against the new Coin and SoQt for a good part of this month, which is especially troublesome since FreeCAD's transition to Python 3 is blocked by the upload of a new Pivy, which I prepared earlier this year.

With any luck, I'll be able to help Leo finish the Coin and SoQt transition and have Pivy prepared in December.

Gmsh Update

Gmsh is a 3D finite element mesh generator with built-in pre- and post-processing facilities. It's also one of the main meshers used by FreeCAD's Finite Element Modeling Workbench, besides Netgen.

Currently Debian has Gmsh 3.0.6, but a new major version was released in August. I've already prepared this new major version for testing in FreeCAD's Community Extras PPA, but I hadn't cleaned up the packaging yet to submit to Debian. However, in November, there were two point releases, 4.0.5 and 4.0.6, so I wasn't able to complete this work this month, but I'm sure it'll be done in early December.

One major piece of information regarding Gmsh 4 is a change in the API: the libjava-gmsh3 package in Debian was never meant to be a public API, and so Gmsh upstream has requested that we no longer ship it. To offset this, there have been refinements for the actual public API, which officially comes in C, Python 3 and (new) Julia flavors. However, I haven't found much information on Julia packaging in Debian, so I'll likely hold off on that package.

PySide 2 Rebuild & PPA Plans

Since FreeCAD is an LGPL-licensed Qt project, we must use PySide and not PyQt to do Qt things with Python. Because of this, the FreeCAD migration to Qt 5 on Debian was blocked by the packaging of PySide 2, which was completed by Freexian SARL over the summer. In Debian, we now have a Qt 5-enabled FreeCAD, although our daily builds PPA is still using Qt 4.

Besides the Qt 4->5 transition, we're also finishing up a Python 2->3 transition. At the end of the summer I published a freecad-python3 package in the PPA which also used Qt 5. However, it wasn't really fully usable, moreso a proof-of-concept that such a build indeed buildable.

At this point, the Debian FreeCAD package has begun to diverge from the FreeCAD PPAs; besides Qt 5 builds not being available currently, the Debian package has also been split into several packages (e.g. libfreecad, freecad-common, etc. packages) in order to better comply with Debian Policy and the Filesystem Hierarchy Standard.

So, there's a bit of work to do to catch the PPAs up. First, the package split needs to be done. Then, I need to upload an alternative freecad-daily package for Qt 5 builds, separate from Python 3. Once that is done and has undergone some testing, freecad-daily can be replaced by it, and it in turn can be replaced by a freecad-python3 package for further testing. Since FreeCAD's 0.18 release is imminent, I'll need to get this taken care of during December, so stay tuned.

Packaging in Progress

My first packaging list is all the software I've already started packaging. For some, it's almost complete, and for others, I've only just begun.

The purpose of these lists is not to give status updates, but to announce what all I'm interested in to anyone reading this, and to give an idea of how much packaging work I have in mind to improve this usage of Debian.

Wishlist Packages

Conclusion

So, there you have it! My mostly complete list of in-progress and wishlist items for Debian packaging. If you have any feedback on packages on the list, or want to get in touch with me, you can find me on Twitter or send me an email at kurt at kwk.systems. I'll also be starting to stream my Debian & FreeCAD work very soon, subscribe to me on Twitch to get notified when I go live.

Intro

Welcome to another monthly summary of my free software work. Currently I'm focusing on improving the state of packaging for FreeCAD and its ecosystem of dependencies and related packages in Debian Science. Additionally, I recently revived the FreeCAD Community Extras PPA as a way of staging these packages out to users for testing. If you are a FreeCAD user, developer, or simply a user of one of these packages, I would greatly appreciate your feedback and testing to identify bugs while my packages wait to make it into the Debian archive.

However, in the long-term, I plan to move away from spending so much time on Debian packaging and returning to FreeCAD core development, and a special not-so-secret related project: PostCAD, providing OpenCASCADE geometry & topology bindings plus CAD data and filetype format support for PostgreSQL, a la PostGIS. The goal is to build this out as a rich backend which FreeCAD can talk to about neat CAD stuff. It's a heaping of work, though, so I don't expect to have a public release until mid or late 2019.

I would like to find others who are interested in contributing to FreeCAD ecosystem packaging for mentorship. That way, my efforts are maintained by the community and the quality and availability of packages won't wane with my attention on them. Since FreeCAD participates in Google Summer of Code, this would be a great opportunity for interested university students to learn Debian packaging and improve the state of science & engineering software on Debian.

Anyway, on to my summary!

Debian News

This month, I officially became a Debian Maintainer. This is a basic level of formal membership in the Debian project, and it comes with limited upload rights to the archive. I can only upload packages for which I am marked as a maintainer, for example FreeCAD.

I took advantage of this to upload some improvements for FreeCAD which I had been sitting on. After a few tweaks, the package was ready for an upgraded upload from Experimental to Unstable, which begins the process of candidacy for Testing, the release pocket for the upcoming Debian 10.

Debian FreeCAD Gets Qt 5

Most important about this upload, though was that FreeCAD is finally being built with Qt 5 support. While Qt 5 had been working for quite a while, we were waiting on a dependency to be uploaded to Debian, PySide 2, which finally was uploaded this summer. Because this is a big switch to flip, any testing and reporting of bugs for this Debian package would be appreciated!

FreeCAD Package Structure Reorganization

One of the other major packaging changes for FreeCAD 0.17 is that the package is no longer a single, monolithic freecad package. We now have:

• a freecad metapackage, which installs the other packages

• common files and resources (e.g. images) in freecad-common

• freecad-runtime contains Python 2/3 compatible runtime files

• the executable built against Python 2, freecad-python2

• and the library files used by the executable, libfreecad-python2-0.17

There are several advantages to this approach. The first is that since freecad-common and freecad-runtime are just pictures, Python scripts, and the like, we can save space in the archive by only needing one copy of the package, instead of one for each supported architecture. For freecad-python2 and libfreecad-python2-0.17, one can see the advantage in the name: since these are Python 2 specific, we will soon be able to provide their Python 3 counterparts.

Ideally, by the time of the Debian 10 release, the FreeCAD 0.17 package will provide both Python 2 and 3 supported versions, and which one you want to use can be switched between using the alternatives system, which I will explain later in this post.

FreeCAD Python 3 Imminent

Like Qt 5, FreeCAD has supported Python 3 for quite some time. (Workbenches and 3rd party code are another story.) However, in Debian, a Python 3-enabled FreeCAD package is blocked by the pending upload of pivy 0.6. I helped coordinate the upstream release of this package but due to issues with its dependency Coin3D the upload is stalled until those issues are resolved.

Community Extras PPA - Early Packge Previews

Now that we have the Community Extras PPA, it serves as a convenient location for me to upload packages as soon as I have one completed and ready for testing. Here are my uploads this month.

Gmsh 4

Gmsh has released a major version upgrade, which includes removing the experimental Java API and introducing Julia bindings, although this package doesn't do anything with them. The current version in the Debian archives is 3.0.6.

This package is only available on Bionic (Ubuntu 18.04) due to its dependencies. I hadn't tried on Cosmic (Ubuntu 18.10) since I worked on this in the beginning of October and it wasn't released yet.

Calculix 2.14

CalculiX in Debian is currently several versions behind (2.11) so I got a request to package this. However, CalculiX actually spans several packages, but calculix-ccx, the solver, is the only one used by FreeCAD, so unlike the other packages, this one is not quite ready for Debian until the other ones are done as well, since they are separate source packages.

This package is available on Bionic and Xenial (Ubuntu 16.04).

PyCOLLADA 0.6, now with Python 3!

Another package which is fairly out of date in Debian (version 0.4 present), I decided to update it since pycollada is a dependency of FreeCAD and I am intrigued by the possibilities of the COLLADA (COLLAborative Design Activity) format. This allows for interchange with interactive 3D applications like Blender.

The big news with this package is that Python 3 support is now available, so I updated the source packaging to provide both Python 2 and 3 packages.

Again due to dependencies, it's only available on Cosmic and Bionic.

Sponsors

My work on Debian Science and FreeCAD is supported by my patrons at https://patreon.com/kkremitzki. Thank you all very much!

If you appreciate my work as described in this post, any level of support is greatly appreciated, including moral support!

Social Media

You can follow me on Twitter at @thekurtwk. I'm also currently working on a Twitch streaming setup, which I hope to have ready by the end of the year! I'll be trying out some live programming, engineering, and Linux gaming. You can find me at twitch.tv/kkremitzki.

python-fluids

I made a new upload for this package to correct several issues. Here's an excerpt from the changelog:

* [1215102] Make python-fluids-doc Multi-Arch: foreign
* [eb610fd] Correct Vcs-* fields
* [62570cd] Updated to Standards-Version 4.2.0, no change required
* [29e96a7] Correct debian/watch
* [3e90d05] Add missing scipy dependency
* [cd776a2] Add lintian override for
  package-contains-documentation-outside-usr-share-doc

The package still fails some reproducibility tests on i386 and could use a standards version bump, but other than that, this package is almost completely clean now! It's quite satisfying cleaning up these packages.

python-ulmo

I made an upload for this package as well:

* [7150daa] Correct Vcs-* fields
* [027b50b] Mark python-ulmo-doc as Multi-Arch: foreign
* [d72b6f6] Add patch to fix FutureWarning

The package was failing its autopkgtests because Python was emitting a FutureWarning onto stderr. This package is actually fully reproducible, and only needs a standards version bump to be fully clean.

gmsh

On August 22nd, Gmsh 4.0.0 was released! The Java API was removed and a Julia one added. This is a nice release because in Debian bug #904946 it was found that the Gmsh package, after being updated to be built against OCCT instead of OCE, actually no longer worked when used in FreeCAD, giving the error:

Error   : Gmsh requires OpenCASCADE to import shape

My hope was that by updating to the new Gmsh version, this problem would resolve itself. However, I ran into a few problems and had to postpone finishing up.

netgen

On August 19th, Debian bug #906619 was reported against Netgen, which was an occasion to look at the state of the package. I noticed that upstream had released version 6.2.1807 (versus the current .1804) but it was not tagged in the Netgen repository, only as a submodule of the Ngsolve repository.

On August 31st, I packaged the new version and resolved the bug in science-team/netgen PR #9.

salome-smesh

Although technically not August, on September 3rd I pushed the nearly finished package for a standalone salome-smesh on Salsa which is fully functional except for an issue with the CMake config file. I submitted a pull request to support multi-arch for the package but forgot to update the path in the CMake config file, so the variables therein have to be manually set, or the file edited.

cantera

On August 24th, Cantera 2.4.0 was released:

Cantera is an open-source suite of tools for problems involving chemical kinetics, thermodynamics, and transport processes.

Previously there had been an issue with the build, where the packages would be made successfully, but attempting to import cantera in Python would error out, presumably due to the way an included copy of libfmt was handled during the build. However, the issue is no longer present, so I now have a working Cantera 2.4.0 package! The only shortcoming is that I don't have working docs build yet, so this package didn't make it in time for August.

openfoam

Previously I had submitted a pull request for OpenFOAM 6 to the Debian Science Team, but spontaneously the package began to fail, presumably due to some change in a dependency. I spent some time troubleshooting this issue but haven't found a resolution yet. Here's a snippet of the build failure:

Allwmake src/Pstream
wmake dummy
wmakeLnIncludeAll: running wmakeLnInclude on dependent libraries:
    wmakeLnInclude: linking include files to /build/openfoam-6.20180805+dfsg1/src/OpenFOAM/lnInclude
    wmakeLnInclude: linking include files to /build/openfoam-6.20180805+dfsg1/src/OSspecific/POSIX/lnInclude
make[2]: Entering directory '/build/openfoam-6.20180805+dfsg1/src/Pstream/dummy'
wmakeLnInclude: linking include files to ./lnInclude
make[2]: Leaving directory '/build/openfoam-6.20180805+dfsg1/src/Pstream/dummy'
make[2]: Entering directory '/build/openfoam-6.20180805+dfsg1/src/Pstream/dummy'
Making dependency list for source file UOPwrite.C
realloc(): invalid next size
make[2]: *** Deleting file '/build/openfoam-6.20180805+dfsg1/platforms/linux64GccDPInt32Opt/src/Pstream/dummy/UOPwrite.C.dep'
Making dependency list for source file UIPread.C
realloc(): invalid next size
make[2]: *** Deleting file '/build/openfoam-6.20180805+dfsg1/platforms/linux64GccDPInt32Opt/src/Pstream/dummy/UIPread.C.dep'
Making dependency list for source file UPstream.C
realloc(): invalid next size
make[2]: *** Deleting file '/build/openfoam-6.20180805+dfsg1/platforms/linux64GccDPInt32Opt/src/Pstream/dummy/UPstream.C.dep'

I'll have to continue investigating this one.

pyside2

I reported Debian bug #906020 about missing Python 3 CMake config files, which was fixed Aug 28th. I began investigating how this would Pivy builds, but got sidetracked by a problem with the med-fichier package.

freecad

I ran into some build issues trying to update the package now that my Debian Unstable workstation is running Qt 5.11:

error: invalid use of incomplete type ‘class QAction’
     QAction* action = new QAction(tr("Remove"), this);

There are several instances of this throughout the codebase that can basically be fixed with by adding some #include s.

projectchrono

There was a bit of discussion about utilization of Project Chrono, an open source multi-physics simulation engine, in FreeCAD. One problem with pursuing this is that it isn't packaged at all for Debian, which is rather surprising! It seems like high-quality software. I began looking at packaging it and it actually doesn't seem that bad. One of the main issues is actually the naming: it's really long! There's also a bit of worry about naming collisions I'll have to look into. As of now, I have a working package except for the Python bindings. Enabling them results in this failure in the build process:

[ 53%] Building CXX object src/demos/irrlicht/CMakeFiles/demo_IRR_soilbin.dir/demo_IRR_soilbin.cpp.o
cd /build/project-chrono-3.0.0/obj-x86_64-linux-gnu/src/demos/irrlicht && /usr/lib/ccache/c++  -DBP_USE_FIXEDPOINT_INT_32 -I/build/project-chrono-3.0.0/src -I/build/project-chrono-3.0.0/obj-x86_64-linux-gnu -I/build/project-chrono-3.0.0/src/chrono -I/build/project-chrono-3.0.0/src/chrono/collision/bullet -I/build/project-chrono-3.0.0/src/chrono/collision/gimpact -I/build/project-chrono-3.0.0/src/chrono/collision/convexdecomposition/HACD -I/usr/include/irrlicht  -g -O2 -fdebug-prefix-map=/build/project-chrono-3.0.0=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -pthread -fopenmp  -march=native -msse4.2 -mfpmath=sse  -march=native -mavx2  -march=native -mfma  -std=c++14 -pthread -fopenmp  -march=native -msse4.2 -mfpmath=sse  -march=native -mavx2  -march=native -mfma    -std=c++14 -pthread -fopenmp  -march=native -msse4.2 -mfpmath=sse  -march=native -mavx2  -march=native -mfma  -o CMakeFiles/demo_IRR_soilbin.dir/demo_IRR_soilbin.cpp.o -c /build/project-chrono-3.0.0/src/demos/irrlicht/demo_IRR_soilbin.cpp
/build/project-chrono-3.0.0/obj-x86_64-linux-gnu/swig/ChModuleCorePYTHON_wrap.cxx: In member function 'virtual void chrono::ChLogPython::Output(const char*, size_t)':
/build/project-chrono-3.0.0/obj-x86_64-linux-gnu/swig/ChModuleCorePYTHON_wrap.cxx:7610:23: error: format not a string literal and no format arguments [-Werror=format-security]
     PySys_WriteStdout(buffer);
                       ^~~~~~

opencamlib

There was a problem with this package's doc depends, which I fixed at the end of August. However, it's still awaiting sponsorship to be uploaded into the Debian archives.

med-fichier

The med-fichier package in Debian currently is built with autotools but somewhat supports CMake builds, which would be nice to switch to as it would provide CMake configuration files in libmedc-dev. I worked on updating the package, but currently building docs is broken, and for some reason, the Fortran library is being statically linked.

Planet FreeCAD

The planet-venus package in Debian is available for running your own RSS feed aggregation service. I wanted to set up a planet.freecad.io to provide exactly that. However, the current version of the package is broken, and it only works in Debian 7, a.k.a. old-old-stable.

I spent some time researching the state of the package, but it's fairly rough, and most importantly, upstream is far from active. I'd like to run the RSS service but fixing the package seems like a tall order.

freecad.io

We previously had two servers available to run some of the web services for the FreeCAD project, but sadly they rebooted but never came back online.

I'm now paying for a VPS in Frankfurt using the money from my Patreon. Unfortunately, it's a bit resource-strained from the FreeIPA server hogging things.

If you like my work as described above and would like to support me continuing to improve the state of open engineering on Linux, please contribute to my Patreon!