Normale weergave

Dirk Eddelbuettel: #057: Conditionally Quieten Compilers

28 Juli 2026 om 00:40

Welcome to post 57 in the R4 series.

R packages with compiled codes can use the file src/Makevars to set compilation flags. We often rely on this to set libraries, include directories or compilation options. When using external libraries, be it header-only or via headers and linking, we are often experiencing ‘compilation noise’ when these libraries tickle warnings under generally-recommended flags such as -Wall -pedantic. Two packages I maintain are clearly repeat offenders here: Eigen, and BH. Both cam generate pages and pages of compiler output. This is generally not great as it may hide genuine warnings from our own code.

What makes matters worse is that some of the available and specific options for the compilers are treated by R CMD check as ‘non-portable’ leading to a nag on package checking. Examples are -Wno-parentheses, -Wno-maybe-uninitialize or -Wno-nunnull.

I have long resorted to adding these to my per-user ~/.R/Makevars. When added there, compilation is quieter, but R CMD check still nags here where the option is set but not at CRAN or r-universe. A situation that is not ideal but what somewhat ‘stable’.

More recently, I realized there was an available check we can use to conditionally add extra compilation flags but leave them off by default. That makes local development quiet allowing us to focus on the quality of our additions here without noise from third-party libraries we may use. At the same time we do not need to do anything else to let CRAN do its work.

The check we now use is whether there is a .git/ directory present. If so, we are indeed building from local sources and can add extra flags. If not, we are likely building from a tar.gz source archive—which is the case for CRAN—and hence do not set these.

An example use is this recent additional to package qlcal where this bit of R code is invoked from a minimal shell script configure and replaces the stub @XTRAFLAGS@ in src/Makevars.in (or src/Makevars.win.in)

if (dir.exists(".git")) {
    ## development from a .git directory can use these flags
    xtraflags <- "-Wno-nonnull -Wno-deprecated-declarations"
} else {
    ## else build from tarball so stick with existing flags
    xtraflags <- ""
}
win <- if (Sys.info()[["sysname"]] == "Windows") ".win" else ""
infile <- file.path("src", paste0("Makevars", win, ".in"))
outfile <- file.path("src", paste0("Makevars", win))
lines <- readLines(infile)
lines <- gsub("@XTRAFLAGS@", xtraflags, lines)
writeLines(lines, outfile)

With this change, local compilation is quiet, yet CRAN has nothing to nag about (as seen at the qlcal results page).

Similarly, one can also check from an actual configure file written in autoconf. Here is a similar example from RcppEigen (showing some relevants parts of the whole file)

# PKG_CXXFLAGS initialized earlier ...

## Check if building locally
AC_MSG_CHECKING([whether .git/ exists])
if test -d "$srcdir/.git"; then
    AC_MSG_RESULT([yes, adding extra flags])
    AC_SUBST([PKG_CXXFLAGS],["${PKG_CXXFLAGS} -Wno-ignored-attributes -Wno-maybe-uninitialized"])
else
    AC_MSG_RESULT([no, consider adding '-Wno-ignored-attributes -Wno-maybe-uninitialized' to ~/.R/Makevars])
fi

AC_SUBST([PKG_CXXFLAGS], ["${PKG_CXXFLAGS}"])
AC_CONFIG_FILES([src/Makevars])
AC_OUTPUT

Once again, with this change compilation is quiet locally, yet unaffected at CRAN. Just what we want. Give it a try in your packages.

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.

  •  

Jonathan Carter: DebConf26 – Santa Fe, Argentina

27 Juli 2026 om 22:12

TL;DR: What a great DebConf! I managed to recharge my Debian batteries, and my talks / BoF sessions all went fine. Already looking forward to DebConf in Japan next year!

DebCamp

The evening before DebCamp started, we had a nice bbq (we taught some locals to call it a “braai” at an organiser’s house and went for a walk around the river as the sun set. It was a very peaceful lead-in to DebCamp.

  • I set up and sent out the call for Forky desktop artwork:
  • Had many nice discussions about various Debian topics with all the Debian people around. It’s really fun being around people who are natural problem solvers who care deeply about both technical and social issues. At one point Jonas told me “Holy shit, these people are motivated!” and I appreciate that so much too!

Debian LTS wine

  • Most of my DebCamp was dedicated to preparing for my demo and main talk that followed at DebConf.
  • Sadly, we had no loopy this year, I just didn’t have the time, and the people who stepped up to help last year were either overwhelmed with other issues or couldn’t make it. I’ll try to make it happen again for next year by kicking it off long before DC27.

View of Santa Fe city from hotel

DebConf

Talk – Is it even possible to build a truly universal system installer?

In this talk I do a very quick comparison of system installers based on my experience with them. It’s hard to directly compare all of them, since there are so many, and each have their own niche that they attempt to satisfy.

I also introduce Yasi – my attempt to answer the question of whether we could build a universal installer, which can also better cover advanced installations, automated installations and niche setups.

It’s very early days for the project, and I didn’t quite feel ready to share the code with the world, but it was nice that I did a quick demo where I could install a Debian system… and the resulting system actually booted up. *phew*.

This is also going to be my main focus for the mid-term future. I aim to have all the basic partitioning options working by the time Debian 14 (Forky) is released, and by the time Debian 15 is released, I have a long list of features that I aim to have working. So, my timeline for having something that’s generally useful is around a year from now, and in around 3 years it should be a fully fledged installer that should cover a very large amount of Debian use cases and architectures.

Day Trip

For the day trip, we did a tour across Santa Fe, visited Constitución de la Nación Argentina, had lunch where we tried various dishes based on local fish from the river, and then went on a boat ride on the river.

BoF Sessions:

Funding in Free Software Projects: I initially registered this BoF because I’m increasingly concerned about how upstreams are asking for donations in their software. I increased the scope to talk about funding in free software in general. It followed Marga’s talk about funding, which focussed more about how developers are funded in general. We didn’t dive very deep into this, but we certainly need some further discussion (and action) on this within Debian.

Debian Social Team: My most important issue for this team is a carry-over from last year, I want to set up barman (packaged in Debian) for live postgres syncing for our larger databases. For the smaller DBs, doing a daily dump is quite cheap. But for Matrix, it’s very expensive in terms if i/o and CPU, so it would be ideal to do less regular complete dumps and use live replication for the first line of redundancy instead.

Images Team: I wasn’t initially planning to say much during this session, I have some ideas to reduce both size and count of images, without losing any benefits, but I don’t have any work to show for that yet. I ended up talking a lot more than I anticipated, the topics covered were quite good and representative of the current state of Debian images built. I don’t have time to create a full summary, so I suggest checking the etherpad / video recording if you’re interested.

Some more wine variety during the conference dinner

Debianites in the main hacklab

Rosario

I’m spending two days in Rosario before I head home. Exploring a bit, catching up with sleep, finishing this blog post, signing keys and exploring some ideas I made note of during DebConf.

Thank you to the DebConf26 Team!

It was a little surreal not being part of any DebConf team for the first time ever, I’ve just been too focussed on getting Yasi ready for my talk (no regrets!). I hope to be more involved again next year, in the meantime, I’m very grateful to everyone who has made this happen, you did a stellar job! I hope to see many of you again next year in Japan!

  •  

Valhalla's Things: Late Victorian Vampire Shirt

27 Juli 2026 om 02:00
Posted on July 27, 2026
Tags: madeof:atoms, craft:sewing, FreeSoftWear

A woman wearing an old-style white shirt with lots of fullness, wide and long sleeves and ruffles at the collar that spread out framing the neck, down the center front to underbust height, covering the slit and at the cuffs, reaching to mid-hand. The shirt is gathered at the waist with a belt, and worn over the bottom garment to show that it reaches to mid tight. Drama levels in the pose are pretty low.

The recurring joke is that because of some health issues, in summer I dress like a Victorian Vampire.

But how would an actual Late Victorian Vampire dress? Picture her, she would look like some kind of eccentric gentlewoman, as vampires usually do, probably with a style that is a bit conservative, rather than following the latest fashions.

Same woman, same shirt, posing as a vampire ready to attack a victim. Drama levels increasing.

Now, she wouldn’t probably wear men’s shirts. But what if she was a lesbian1 vampire? Wouldn’t she need a fancy, frilly shirt to go with her tailored cycling suit when she’s out seducing the more active ladies in the neighbourhood?

Or maybe not. It’s not making a lot of sense, is it? But I do have a lot of shirt fabric in my stash2, and I could use a few more shirts that were practical and comfortable, but also somewhat over the top.

For the practical and comfortable I went to my trusted 1880s shirt, while for the over the top part I looked at inspiration from the earlier 18th century frilly shirts, and their later imitations.

I decided to use some nice cotton batiste I had bought quite a few years ago to make one of my first historically inspired shirtwaists: I may have a tendency to buy a bit more fabric than actually needed by the pattern, but that’s what everybody does, right?

For the ruffles I decided to use a lighter weight cotton voile, also from the stash.

the top edge of a ruffle being whipstitched over some gathered fabric; the rest of the unfinished shirt is visible in the background.

At the front, I wanted the ruffle to be inserted in the yoke, but I was also whipstitching the gathers to it to make them neater, so I started bu attaching the yoke lining to the gathered front, then I whipstitched the ruffle to the front, catching each gather, and finally I whipstitched the other yoke on the ruffle and the rest of the gathered front.

The front of a shirt: the body was gathered into a yoke, but it has been unpicked and pulled out to extend a bit past the end of it, into where the collar will be sewn.

And then after sewing the collar, I realized that this way the slit would have remained open in the front (or the collar too narrow), so I had to unpick the front part of the yoke, and sew it again, this time leaving an excess of fabric as wide as half the placket width from the pattern, to be sewn directly in the collar band.

From then, things progressed smoothly, with some interruptions, until I got to the first sleeve, which I failed to insert twice, as one does.

The same shirt worn without the ruffle at the collar, with just what looks like a mandarin collar, closed with a clip with an amethyst. Drama levels have gone way down.

On the third attempt, with a different method, I succeeded, I tried the shirt on, and it already felt extra.

Close up of the collar on a table: at the center back of the shirt collar there is a buttonhole, and a double button is used to keep the detached collar in place, while at the front both the shirt collar and the detached collar have buttonholes.

But it could be even more extra. With some ruffles also at the collar.

Same close up, but now the collar has been closed with a clip-on earring with an amethyst and some small fake clear stones, and it looks as if the skirt had a ruffle collar and a jewel button (or a pin).

The shirt had been made with a simple collar band, and I could have just added the ruffle to it, but I also wanted to be able to wear it with other detachable collars, so I decided to make another collar band with ruffles, to wear on top.

And that was mostly it, except for the reinforcement patches at the side seams and cuffs: I love having them, because they make the seam end neater and stronger, but they are a bit of a hassle to make, so they got postponed a few days.

Same woman and shirt, back with the ruffled collar, in a pose like that of an artist that is fainting for futile reasons. Drama levels over the top.

But finally, the shirt was done.

And I tried it on, and it was good.

But now I really need a pair of cycling breeches, don’t I?


  1. ok, maybe straight passing bi? anyway.↩︎

  2. I have no idea how they got there.↩︎

  •  

Freexian Collaborators: Monthly report about Debian Long Term Support, June 2026 (by Thorsten Alteholz)

22 Juli 2026 om 02:00

The Debian LTS Team, funded by [Freexian’s Debian LTS offering] (https://www.freexian.com/lts/debian/), is pleased to report its activities for June.

Activity summary

During the month of June, 20 contributors have been paid to work on Debian LTS (links to individual contributor reports are located below).

The team released 48 DLAs fixing 231 CVEs.

Debian 12 (“bookworm”) has been handed over to the LTS Team on June 11th. During this handover Sylvain helped to update relevant tools and documentation. If you benefit from Debian, especially during the full 5-year lifecycle, please consider subscribing as a sponsor of Debian LTS: https://www.freexian.com/lts/debian/.

Moreover, Debian 11 (“bullseye”) will reach the end of the Debian LTS period on August 31st. After that, Freexian will continue the security support under the Extended LTS offer.

The team published several notable updates:

  • haveged update (DLA-4616-1), prepared by Thorsten, to address local privilege escalation.
  • tomcat9 update (DLA-4619-1), prepared by Markus, to address, among others, an authentication bypass.
  • apache2 update (DLA-4620-1), prepared by Bastien, to address a HTTP/2 bomb.
  • apache2 update (DLA-4629-1), prepared by Bastien, to address, among others, remote code execution and privilege escalation.
  • libinput update (DLA-4626-1), prepared by Santiago, to address local privilege escalation and arbitrary code execution.
  • asterisk update (DLA-4631-1), prepared by Thorsten, to address, among others, wrong processing of invalid or untrusted certificates.
  • nginx update (DLA-4634-1), prepared by Charles, to address a remote code execution and denial of service.
  • firefox-esr update (DLA-4635-1), prepared by Emilio, to address dozens of CVEs, among other things, related to arbitrary code execution and privilege escalation.
  • thunderbird update (DLA-4636-1), prepared by Emilio, to address dozens of CVEs, among other things, related to arbitrary code execution.
  • chromium update (DLA-4654-1), prepared by Emilio, to address dozens of CVEs, among other things, related to arbitrary code execution.

Contributions from outside the LTS Team:

We are greatly thankful for the contributions from people outside the LTS Team:

  • Salvatore Bonaccorso prepared a libhttp-daemon-perl update, that was released by Santiago as DLA-4639-1.
  • Salvatore also directly uploaded libgd-perl DLA-4638-1 and libconfig-inifiles-perl DLA-4637-1.
  • Peter Palfrader prepared a tor update, that was released by Santiago as DLA-4656-1.
  • Pieter Lenaerts prepared a beets update, that was released by Emmanuel as DLA-4641-1.
  • Noah Meyerhans prepared a cloud-init update DLA-4645-1.

The LTS Team has also contributed with updates to the latest Debian releases:

  • Besides publishing DLA-4642-1 for package u-boot Andreas also prepared an NMU for an upload to sid and prepared a stable-proposed-update (SPU) bug for trixie, which was already acknowledged by a stable release manager (SRM).
  • Andreas also prepared an upload of package atril for trixie, which was handled by the security team as DSA-6349-1.
  • Besides publishing DLA-4620-1 for package apache Bastien also prepared an upload for trixie, which was handled by the security team as DSA-6323-1.
  • Tobi uploaded package mesa to trixie and bookworm.
  • Thorsten fixed some (not security related but RC) issues in package dahdi-linux. This was in preparation to fix lots of security issues in asterisk. Unfortunately the maintainer ignored the corresponding debdiff and prefered to upload a new upstream version. Anyway, the concerns of the security team about security support of asterisk could be overcome and asterisk can migrate to tesing and again be part of a Debian release.

Individual Debian LTS contributor reports

Thanks to our sponsors

Sponsors that joined recently are in bold.

  •  
❌