fidzu : debian

Welcome to post 58 in the R⁴ series.

R and the CRAN repositories maintain a very high level of what we might call "quality assurrance" by requiring that newly-added code does not break any existing dependencies. This is frequently called a "reverse-dependency check". For any given CRAN package one can quickly determine it reverse dependencies. Calling tools::package_dependencies(pkgName, reverse=TRUE) will for a scalar or vector-valued argument return a named list with the reverse dependencies. It is then a matter of looping over this list. There are helper functions in base R as well as in contributed packages on and off CRAN. I also wrote my own with package prrd which, while possibly a wee bit specialised and under-documented has served me well to check on Rcpp and related packages which can indeed have a large number of reverse dependencies.

I recently looked into one of these contributed runner packages, and while I will refrain from naming its implementation language let me just mention that the term "cargo cult" may be a real thing here. What go me interested in this was the fact that if one has a simple-to-use runner then the fact that r2u makes it "fast, easy, reliable: pick all three" (to borrow its slogan) to deal with actual depencies if Ubuntu has indeed been selected as the host. We will maintain the position that if you can in fact integrate with the system-wide package management then any alternative per-repo package management approach not doing so will likely be dominated by an approach that does integrate with the system facilities. Which is what precisely what r2u does, and offers. And why it is used enough to by now have shipped eighty eight million binary packages. So I tested it for the reverse-dependency check task.

What I learned by looking into the (much more complicated) runner was that it at the end of the day it hands the actual task of running the reverse dependecies off to a helper function rev_check that is part of the xfun package by Yuhui. I quickly found that besides xfun we would also need its suggested dependency tinytex which in turn would error unless the tlmgr binary was present. So as the sole requirement (on an Ubuntu system with r2u) turns out to be

$ apt install r-cran-xfun r-cran-tinytex texlive-base

where we do it all in one apt call (as root in the container). (Given r2u we could also call install.packages(c("xfun","tinytext")) followed by apt install texlive-base but it is simpler for this setup step to be just one call).

With that we are basically done. I did this (twice) using a rocker/r2u container with r2u preinstalled, mounting a local work and scrap directory for the container. In it we expand the package to be tested (i.e. tar xaf pkgName_*tar.gz for a given source package pkgName from CRAN) and then just call with the package name and expanded direcrtory. I.e. I used this call to test my package AsioHeaders (which has just three reverse dependencies) to both name it and to point to the expanded source directory created for this purposed:

> system.time( res <- xfun::rev_check("AsioHeaders", src="AsioHeaders") )
## ... earlier output omitted for brevity here ...
   user  system elapsed 
 35.732   3.333 149.683 
> res
   httpgd ipaddress websocket 
        0         0         0 
> 

and about a good two minutes later I would get the timing result and the summary in variable res. As I checked the current CRAN version, the check was as expected free of concerns or issues.

To support this, r2u did indeed go off and install about sixty seven binary packages (and the total includes all binary dependencies fully resolved) delivering on the 'just works' promise by the r2u documentation.

As another check, I did the same for RcppAnnoy which has seven reverse dependencies and needed about two hundred CRAN packages to be installed. The full test took just over four minutes with the timing function reporting some nice gains from parallelisation as total user compute time was on the order of just under eight minutes. Again, test results were clean and free of worries as expected:

> system.time( res <- xfun::rev_check("RcppAnnoy", src="RcppAnnoy") )
## ... earlier output omitted for brevity here ...
   user  system elapsed 
471.765 378.220 266.855 
> res
   bbknnR  bigANNOY  blocking     scDHA    Seurat      uwot VectrixDB 
        0         0         0         0         0         0         0 
> 

Overall this was a rather useful quick excursion as it demonstrates that - existing functions can be used to orchestrate a reverse dependency check - with 'reasonable' dependency scale we can do this on a single machine quite easily taking advantage of parallel computing on multi-core machines - using r2u gives us fast, easy, reliable package installation making testing of packages we might not otherwise use or know a breeze - doing this in an ephemeral Docker container facilitates easy build-up of required resources and leaves no side effects behind which might affect our normal development environment

This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. If you like this or other open-source work I do, you can now sponsor me at GitHub.

04 Aug 2026 5:22pm GMT

After seeing a video a few months ago demonstrating how a proprietary CAM solution uses machine learning and large language models to automatically generate CNC instructions, and successfully testing it on a real CNC, I began wondering if the same could be achieved with free software. I still do not know the answer, but I may be getting closer to finding out. Two weeks ago, I came across the video "I Connected Claude AI to FreeCAD (And It Models Parts Like an Engineer)" by Make Form, which introduced me to the FreeCAD MCP project. Even though the video creator apparently believes it is acceptable to download and run random binaries from the Internet on a local machine (his setup uses UCX), I do not. I would probably have left the project alone entirely if I had not noticed that all of its dependencies are already available in Debian. This significantly boosted my motivation, so I set out to test it using packages built from source on Debian rather than relying on untrusted binaries.

The first hurdle was that the MCP SDK for Python was not present on my Debian Forky test machine. I initially believed it was missing from Debian altogether, but it has been available in Debian Unstable for about a month and is only absent from Forky because some automated tests fail on architectures like riscv64 and s390. Fortunately, backporting it was straightforward using `apt-get source -b python3-mcp`. The next hurdle involved an outdated version of the Validators Python library. Since I am a member of Debian's Python team, which maintains this package, updating it to a sufficient version for FreeCAD MCP was relatively easy. I could not upgrade to the latest upstream release due to a new dependency on an Ethereum-related library, so I settled on a 2024 version.

With those dependencies in place, I proceeded to create a Debian package for FreeCAD MCP. I had previously submitted a request for packaging of FreeCAD MCP to gauge interest while deciding whether to prioritize maintaining it myself. Because salsa.debian.org blocks access from Tor users like myself, I published my draft packaging scripts in a Git repository on Codeberg as the Debian FreeCAD MCP project and got it working with the FreeCAD 1.1 version in Forky. I initially struggled with the button controls for the MCP feature, which led me to submit a pull request titled "Fixed startup sync of checkable toolbar buttons" proposing a fix. Once this confusion was resolved and the MCP setup was enabled via the GUI, I was able to run FreeCAD completely headless using `xvfb-run` on a machine without an X server to generate models. I am using a private LLM service running the Debian package of llama.cpp with the Qwen 3.6 model downloaded from Hugging Face, configured with a maximum context window of 105k tokens. I also tested the Bonsai model on my test laptop; initially, its context window was too small (8k and 16k could not accommodate the FreeCAD MCP instructions), but even after increasing it to 32k, it proved useless for generating FreeCAD models so far. I've used Claw Code, Aider and Open Code with my server so far, and for this test I ended up with OpenCode because it was easy to set up to use an MCP. Because none of my LLM services are set up to be multimodal (capable of processing both text and images in this case), I configured the MCP to return only textual feedback from FreeCAD. I am unsure if this is a major limitation, though I suspect it might be.

My testing experience remains limited, with no clear successes yet. Part of the issue likely stems from my ability to provide effective instructions for modeling 3D objects (I am relatively new to FreeCAD, English is not my first language, and I lack a precise vocabulary for describing construction features to an LLM). Nevertheless, the LLM has demonstrated the capacity to create 3D models in FreeCAD. In one of my first tests, I asked it to generate a cube and then produce CAM/G-code instructions for a CNC machine. It did output G-code (which remains untested), but I was surprised to find that it bypassed FreeCAD's built-in CAM module entirely and instead generated an external Python script to produce the code. This was not quite what I intended, though my instructions were probably unclear. The Qwen model with OpenCode seems to strongly prefer programming directly; it frequently executes Python snippets inside FreeCAD to achieve its goals rather than using the standard sketch-and-extrude workflow I am accustomed to. In another test, I asked the LLM to create a parameterized pipe assembly to see which of FreeCAD's parametric tools it would choose, but found no evidence of traditional parametric features in the output. When prompted, the LLM explained that the parameters were embedded directly in the Python script used to generate the model, rather than in native FreeCAD features. With more explicit instructions, it eventually created a FreeCAD spreadsheet to manage the parameters. The resulting model looked much closer to my expectations and could have been useful with further refinement. My so far last experiment was less successful: I asked it to design a pipe clamp, but the LLM repeatedly failed to position the clamping screws in a way that would actually secure the brackets around the pipe. It is unclear whether this limitation lies with the model, my prompt, or other factors.

Based on my testing so far, I am uncertain whether FreeCAD MCP is merely a fun toy or a genuinely useful tool. I will only commit time to maintaining it in Debian if it proves to be practically valuable. I would welcome feedback from anyone who has experience with the project, preferably via the original request-for-packaging mailing list thread. Alternatively, I am available in the FreeCAD and Debian AI IRC channels for further discussion.

As usual, if you use Bitcoin and wish to support my activities, please send donations to 15oWEoG9dUPovwmUL9KWAnYRtNJEkP1u1b.

04 Aug 2026 9:00am GMT

Summer Holiday. Busy time as a parent.

03 Aug 2026 10:03pm GMT