07 Jun 2026

feedPlanet Debian

Dirk Eddelbuettel: RQuantLib 0.4.27 on CRAN: Small Extension

A new minor release 0.4.27 of RQuantLib, the first in over a year, arrived on CRAN a couple of minutes ago, has just now been uploaded to Debian, and is being built for r2u as well.

QuantLib is a rather comprehensice free/open-source library for quantitative finance. RQuantLib connects (some parts of) it to the R environment and language, and has been part of CRAN for nearly twenty-three years (!!) as it was one of the first packages I uploaded to CRAN.

This release of RQuantLib brings an update to the interface for all equity options, vanilla and exotics as well as implied volatilities. We now support the option maturity via either an actual maturity date, or the (fractional business-day years) numeric. This uses a clever little Rcpp trick I should discuss in a separate blog post. We also re-ran compileAttributes() to re-create the RcppExports.cpp file now using a slightly improved way of calling Rf_error for an ongoing Rcpp transition, and did some more standard maintenance. The details from the NEWS file follow as usual.

Changes in RQuantLib version 0.4.27 (2026-06-07)

  • All equity option functions can now take either a (fractional) time span to expiry or a given date, and accept a daycounter setter.

  • Two very old schedule helpers had a superfluous try/catch removed.

  • The continuous integration setup received a minor update.

  • The RcppExports.cpp file was updated to aid a Rcpp transition.

Courtesy of my CRANberries, there is also a diffstat report for the this release. As always, more detailed information is on the RQuantLib page. Questions, comments etc should go to the rquantlib-devel mailing list. Issue tickets can be filed at the GitHub repo.

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.

07 Jun 2026 2:44pm GMT

Vasudev Kamath: debsecan-mcp v0.1.2 released to PyPI

I finally carved out some time today to prepare and release debsecan-mcp v0.1.2 to PyPI. During this release, I integrated PyPI's trusted publisher mechanism, which authenticates directly via GitHub Actions and eliminates the need for manual uploads or static API tokens.

What is New?

There are no feature updates in this release; the changes are strictly focused on PyPI publishing requirements. This was handled entirely within the Antigravity IDE.

The primary change replaces the python-apt dependency with python-debian for version comparison. PyPI rejects packages that reference external Git repositories, and python-apt lacks an official PyPI release. The original python-apt logic remains intact: if the system has python-apt installed, the server defaults to it. Otherwise, it falls back to the comparison logic implemented via the python-debian NativeVersion class.

What Next?

The next release will introduce a standalone CLI utility called debvulns. It mirrors debsecan functionality but surfaces the cleaner, richer vulnerability data already implemented in debsecan-mcp. The code is written, and I will release it once testing is complete.

I also owe a post explaining my rationale for designing a CLI utility alongside the MCP server, and my broader thoughts on CLI vs. MCP workflows. I aim to publish that next week.

07 Jun 2026 12:49pm GMT

Steinar H. Gunderson: Hyperpersonal open source

A while back, I got my first subwoofer (a surprisingly nice addition to the movie experience, just like rear speakers were). But I live in an apartment, and I don't want to annoy my neighbors at night (the speaker cone points literally down into the floor, and I have no idea how much my neighbors get to share in my enjoyment). So, what to do?

It turns out my receiver supports a sort-of documented serial protocol; it doesn't have an actual serial port, but you can telnet into it (only one session at a time!) and get the same two-way stream. (It also has a HTTP version which I find less useful.) So this allows me to impose my own policy, and of course, doing it via an existing Home Assistant adapter or something was no fun and also thoroughly frustrating, so I saw it as an opportunity to keep maintaining my low-key Rust skills. (No, no LLM code generation. If I'm going to spend time on this, at least I can learn something myself. I think I asked one for code critique at some point, but I can't remember.)

The policy is roughly: If I'm watching TV after 22:00, then the subwoofer is either turned off (if possible) or turned down -12 dB (the maximum). But if I'm watching a Blu-ray or another input like that, that's presumably a conscious tradeoff I've made and things are left at normal. Everything gets a bit more complicated by the fact that the receiver tends to lose state when doing certain switches, and when it boots, it takes a minute or two before Telnet responds, and when it shuts down, it goes into this weird limbo state where it doesn't respond to anything but the TCP connection seems still up.

And then I figured out I also wanted to dim the display when watching movies (again, only certain inputs), but not for a couple of seconds after making any adjustments. And after doing that, I figured that my access point LED should also be turned off, which happens to be some SNMP writable stuff against the Cisco wireless controller it hangs on.

So, if you have a Denon or Marantz AVR, a Cisco access point on a controller, and my exact preferences about what to do about the subwoofer, then you are free to download and use my software to impose that policy. It is "is distributed in the hope that it will be useful", as one says. If you have IPv6.

07 Jun 2026 8:15am GMT