• I wanted to upgrade my internet connection, but:
• My router wasn t fast enough, so:
• I bought a new one and:
• Proceeded to help work on mainline Linux support, and:
• Did some tweaking of my Debian setup to allow for a squashfs root, and:
• Upgraded it to Debian 11 (bullseye) in the process, except:
• It turned out my home automation devices weren t happy, so:
• I dug into some memory issues on my ESP8266 firmware, which:
• Led to diagnosing some TLS interaction issues with the firmware, and:
• I had an interlude into some interrupt affinity issues, but:
• I finally got there.

The desire for a faster connection When I migrated my home connection to FTTP I kept the same 80M/20M profile I d had on FTTC. I didn t have a pressing need for faster, and I saved money because I was no longer paying for the phone line portion. I wanted more, but at the time I think the only option was for a 160M/30M profile instead and I didn t need it and it wasn t enough better to convince me. Time passed and BT rolled out their GigE (really 900M) download option. And again, I didn t need it, but I wanted it. My provider, Aquiss, initially didn t offer this (I think they had up to 330M download options available by this point). So I stayed on 80M/20M. And the only time I really wanted it to be faster was when pushing off-site backups to rsync.net. Of course, we ve had the pandemic, and that s involved 2 adults working from home with plenty of video calls throughout the day. The 80M/20M connection has proved rock solid for this, so again, I didn t feel an upgrade was justified. We got a 4K capable TV last year and while the bandwidth usage for 4K streaming is noticeably higher, again the connection can handle it no problem. At some point last year I noticed Aquiss had added speed options all the way to 900M down. At the end of the year I accepted a new role, which is fully remote, so I had a bit of an acceptance about the fact that I wasn t going back into an office any time soon. The combination (and the desire for the increased upload speed) finally allowed me to justify the upgrade to myself.

Testing the current setup for bottlenecks The first thing to do was see whether my internal network could cope with an upgrade. I m mostly running Cat6 GigE so I wasn t worried about that side of things. However I m using an RB3011 as my core router, and while it has some coprocessors for routing acceleration they re not supported under mainline Linux (and unlikely to be any time soon). So I had to benchmark what it was capable of routing. I run a handful of VLANs within my home network, with stateful firewalling between them, so I felt that would be a good approximation of the maximum speed to the outside world I might be able to get if I had the external connection upgraded. I went for the easy approach and fired up iPerf3 on 2 hosts, both connected via ethernet but on separate networks, so routed through the RB3011. That resulted in slightly more than a 300Mb/s throughput. Ok. I confirmed that I could get 900Mb/s+ on 2 hosts both on the same network, just to be sure there wasn t some other issue I was missing. Nope, so unsurprisingly the router was the bottleneck. So. To upgrade my internet speed I need to upgrade my router. I could just buy something off the shelf, but I like being able to run Debian (or OpenWRT) on the router rather than some horrible vendor firmware. Lucky MikroTik launched the RB5009 towards the end of last year. RouterOS is probably more than capable, but what really interested me was the fact it s an ARM64 platform based on an Armada 7040, which is pretty well supported in mainline kernels already. There s a 10G connection from the internal switch to the CPU, as well as a 2.5Gb/s ethernet port and a 10G SFP+ cage. All good stuff. I ordered one just before the New Year. Thankfully the OpenWRT folk had done all of the hard work on getting a mainline kernel booting on the device; Sergey Sergeev and Robert Marko in particular fighting RouterBoot and producing a suitable device tree file to get everything up and running. I ended up soldering a serial console connection up to aid debugging, and lightly patching Rob s u-boot to fix the incorrect RAM size reported by RouterBoot. A few kernel tweaks were necessary to make the networking entirely happy and at that point it was time to think about actually doing a replacement.

Upgrading to Debian 11 (bullseye) My RB3011 is currently running Debian 10 (buster); an upgrade has been on my todo list, but with the impending replacement I decided I d hold off and create a new Debian 11 (bullseye) image for the RB5009. Additionally, I don t actually run off the internal NAND in the RB3011; I have a USB flash drive for the rootfs and just the kernel booting off internal NAND. Originally this was for ease of testing, then a combination of needing to figure out a good read-only root solution and a small enough image to fit in the 120M available. For the upgrade I decided to finally look at these pieces. I ve ended up with a script that will build me a squashfs image, and the initial rootfs takes care of mounting this and then a tmpfs as an overlay fs. That means I can easily see what pieces are being written to. The RB5009 has a total of 1G NAND so I m not as space constrained, but the squashfs ends up under 50M. I ve added some additional pieces to allow me to pre-populate the overlay fs with updates rather than always needing to rebuild the squashfs image. With that done I decided to try it out on the RB3011; I tweaked the build script to be able to build for armhf (the RB3011) or arm64 (the RB5009) and to deal with some slight differences in configuration between the two (e.g. interface naming). The idea here was to ensure I d got all the appropriate configuration sorted for the RB5009, in the known-good existing environment. Everything is still on a USB stick at this stage and the new device has an armhf busybox root meaning it can be used on either device, and the init script detects the architecture to select the appropriate squashfs to mount.

A problem with ESP8266 home automation devices Everything seemed to work fine - a few niggles with the watchdog, which is overly sensitive on the RB3011, but I got those sorted (and the build script updated) and the device came up and successfully did the PPPoE dance to bring up external connectivity. And then I noticed that my home automation devices were having problems connecting to the mosquitto MQTT server. It turned out it was only the ESP8266 based devices that were failing, and examining the serial debug output on one of my test devices revealed it was hitting an out of memory issue (displaying E:M 280) when establishing the TLS MQTT connection. I rolled back to the Debian 10 image and set about creating a test environment to look at the ESP8266 issues. My first action was to try and reduce my RAM footprint to try and ensure there was enough spare to establish the connection. I moved a few functions that were still sitting in IRAM into flash. I cleaned up a couple of buffers that are on the stack to be more correctly sized. I tried my new image, and I didn t get the memory issue. Instead I progressed a bit further and got a watchdog reset. Doh! It was obviously something related to the TLS connection, but I couldn t easily see what the difference was; the same x509 cert was in use, it looked like the initial handshake was the same (and trying with openssl s_client looked pretty similar too). I set about instrumenting the ancient Mbed TLS used in the Espressif SDK and discovered that whatever had changed between buster + bullseye meant the EPS8266 was now trying a TLS-DHE-RSA-WITH-AES-256-CBC-SHA256 handshake instead of a TLS-RSA-WITH-AES-256-CBC-SHA256 handshake and that was causing enough extra CPU usage that it couldn t complete in time and the watchdog kicked in. So I commented out MBEDTLS_KEY_EXCHANGE_DHE_RSA_ENABLED in the config_esp.h for mbedtls and rebuilt things. Hacky, but I ll go back to trying to improve this generally at some point.

A detour into interrupt load Now, my testing of the RB3011 image is generally done at weekends, when I have enough time to tear down and rebuild the connection rather than doing it in the evening and having limited time to get things working again in time for work in the morning. So at the point I had an image ready to go I pulled the trigger on the line upgrade. I went with the 500M/75M option rather than the full 900M - I suspect I d have difficulty actually getting that most of the time and 75M of upload bandwidth seems fairly substantial for now. It only took a couple of days from the order to the point the line was regraded (which involved no real downtime - just a reconnection in the night). Of course this happened just after the weekend I d discovered the ESP8266 issue. This provided an opportunity to see just what the RB3011 could actually manage. In the configuration I had it turned out to be not much more than the 80Mb/s speeds I had previously seen. The upload jumped from a solid 20Mb/s to 75Mb/s, so I knew the regrade had actually happened. Looking at CPU utilisation clearly showed the problem; softirqs were using almost 100% of a CPU core. Now, the way the hardware is setup on the RB3011 is that there are two separate 5 port switches, each connected back to the CPU via a separate GigE interface. For various reasons I had everything on a single switch, which meant that all traffic was boomeranging in and out of the same CPU interface. The IPQ8064 has dual cores, so I thought I d try moving the external connection to the other switch. That puts it on its own GigE CPU interface, which then allows binding the interrupts to a different CPU core. That helps; throughput to the outside world hits 140Mb/s+. Still a long way from the expected max, but proof we just need more grunt.

Success Which brings us to this past weekend, when, having worked out all the other bits, I tried the squashfs root image again on the RB3011. Success! The home automation bits connected to it, the link to the outside world came up, everything seemed happy. So I double checked my bootloader bits on the RB5009, brought it down to the comms room and plugged it in instead. And, modulo my failing to update the nftables config to allow it to do forwarding, it all came up ok. Some testing with iperf3 internally got a nice 912Mb/s sustained between subnets, and some less scientific testing with wget + speedtest-cli saw speeds of over 460Mb/s to the outside world. Time from ordering the router until it was in service? Just under 8 weeks

• In January we saw a new funded project proposed. The project is meant to bring in a number of changes to the Tryton modules and packages in Debian. Tryton, a full featured, entirely open source business software platform, is supported by its own foundation. You can track the current status of all our funded projects at its dedicated web page.
• Folks continue to add to the Grow Your Ideas project page, that s great.
• In January 2550 was put aside to fund Debian projects.

• Abhijith Pa worked 5 hours out of 5 available.
• Anton Gladky worked 12 hours out of 12 available.
• Ben Hutchings worked 16 hours out of 24 available and carried over 8 for February.
• Chris Lamb worked 18 hours out of 18 available.
• Emilio Pozuelo Monfort worked 55 hours out of 58.25 available and carried over 3.25 for February
• Jeremiah Foster worked 20 hours out of 20 available on LTS administration and 8.3 hours on funded projects.
• Lee Garrett didn t spend any hours in January and carries over 39.25 hours to February
• Markus Koschany worked 34 hours out of 40 available and carried over 6 for February.
• Ola Lundqvist reported via email that they didn t spend any hours in January and carries over 11 from December for a total of 12 hours for February.
• Roberto C. Sanchez worked 9 hours out of 32 available and carried over 23 for February
• Sylvain Beucler worked 22 hours out of 40 available and carried over 14 for February
• Thorsten Alteholz worked 40 hours out of 40 available.
• Utkarsh Gupta worked 58.25 hours out of 58.25 available.

• Platinum sponsors:
  • TOSHIBA (for 77 months)
  • GitHub (for 68 months)
  • Civil Infrastructure Platform (CIP) (for 45 months)
• Gold sponsors:
  • Roche Diagnostics International AG (for 88 months)
  • Linode (for 82 months)
  • Babiel GmbH (for 71 months)
  • Plat Home (for 71 months)
  • University of Oxford (for 27 months)
  • Deveryware (for 14 months)
  • VyOS Inc (for 9 months)
• Silver sponsors:
  • The Positive Internet Company (for 93 months)
  • Domeneshop AS (for 92 months)
  • Nantes M tropole (for 86 months)
  • Univention GmbH (for 78 months)
  • Universit Jean Monnet de St Etienne (for 78 months)
  • Ribbon Communications, Inc. (for 72 months)
  • Exonet B.V. (for 62 months)
  • Leibniz Rechenzentrum (for 56 months)
  • CINECA (for 45 months)
  • Minist re de l Europe et des Affaires trang res (for 39 months)
  • Cloudways Ltd (for 29 months)
  • Dinahosting SL (for 27 months)
  • Bauer Xcel Media Deutschland KG (for 21 months)
  • Platform.sh (for 21 months)
  • Moxa Intelligence Co., Ltd. (for 15 months)
  • sipgate GmbH (for 12 months)
  • OVH US LLC (for 10 months)
  • Tilburg University (for 10 months)
  • GSI Helmholtzzentrum f r Schwerionenforschung GmbH
  • Telecats BV
• Bronze sponsors:
  • Evolix (for 93 months)
  • Seznam.cz, a.s. (for 93 months)
  • Intevation GmbH (for 90 months)
  • Linuxhotel GmbH (for 90 months)
  • Daevel SARL (for 88 months)
  • Bitfolk LTD (for 87 months)
  • Megaspace Internet Services GmbH (for 87 months)
  • Greenbone Networks GmbH (for 86 months)
  • NUMLOG (for 86 months)
  • WinGo AG (for 86 months)
  • Ecole Centrale de Nantes LHEEA (for 82 months)
  • Entr ouvert (for 77 months)
  • Adfinis AG (for 74 months)
  • GNI MEDIA (for 69 months)
  • Laboratoire LEGI UMR 5519 / CNRS (for 69 months)
  • Tesorion (for 69 months)
  • Bearstech (for 60 months)
  • LiHAS (for 60 months)
  • People Doc (for 57 months)
  • Catalyst IT Ltd (for 55 months)
  • Supagro (for 50 months)
  • Demarcq SAS (for 49 months)
  • Universit Grenoble Alpes (for 35 months)
  • TouchWeb SAS (for 27 months)
  • SPiN AG (for 24 months)
  • CoreFiling (for 19 months)
  • Institut des sciences cognitives Marc Jeannerod (for 14 months)
  • Observatoire des Sciences de l Univers de Grenoble (for 11 months)
  • Tem Innovations GmbH (for 6 months)
  • WordFinder.pro (for 5 months)
  • CNRS DT INSU R sif (for 4 months)

John Grisham The King of Torts Lots of things have been happening and I have been unable to be on top of things. There are so many things that happen and keep on happening and a lot of it is just not in control. For those who are watching Brexit, India is going through the same/similar phenomena just without Brexit. I would not like to delve much into Indian happenings as there is no sweet story to tell. Mum is in hospital (diabetic foot) so a lot of time to read books. So I have been making use of the time and at the same time learning or making connections from what I know of the history of the world which goes on enriching what I read all the time. For e.g. in this book, opens up with people who are on Crack. Now while the book is set in 2003, it is still relevant today for a lot of things. There have been rumors and whatnot that the President of the United States, Ronald Reagan supplied a lot of cocaine to black folks in the early 1980s. While that has never been proved, it has been proved somewhat that the CIA and even people in the state department were part of providing crack cocaine to African Americans (as they refer to blacks) in those days. Whether this was because of black power rising or non-profits like ACLU or other organizations is beyond me. I had also read that the GOP (Republicans/Grand Old Party) in the 1970s itself when computers became fast and could do a lot of processing, came to know if education would be as it is, then soon they would no voters. hence they decided to defund education in America, the end result being massive education loans to prospective students and perhaps partly the reason why China produces more than enough STEM graduates than the total number of Americans who become graduates. It is a shame nonetheless, that education in the U.S. is never top . This is somewhat from a Republican perspective. That is also the reason they are much anti-science.

Tort Cases India doesn t have either class-action suits or tort cases. But before we go headlong, this is what tort means. The book however is not about general tort cases but medical tort cases. The idea is that medical companies often produce medicines claiming they solve x or y issues but more often than not they take short-cuts to get approval from FDA and other regulators. And sooner or later those medicines can and do have harmful effects on the body, sometimes resulting in death. One of the more interesting articles that I read and probably also shared is the work done by Mr. Rob Bilott. While it is a typical David and Goliath story once you read the book, you realize that there are and were many difficulties in Mr. Rob s path that are never fully appreciated or even worked out. The biggest issue is the 8 years that he paid out of his own pocket to get the hundreds and thousands of people tested. How many of us would do that? And this is before proving causation of any disease, illness or anything to a particular environment, pollution etc. is hard even then and even now. Whatever money the victims receive afterward and whatever went to Mr. Rob Bilott would never compensate for the stress faced by him. And lawyers have to be careful, if they ask too little, they are not hurting the company and there is no change in its behavior. If they ask too much, the company can declare Chapter 11, bankruptcy so they have to keep the balance. There is also a lot of greed shown by the tort lawyer and while at the end he does tell about a company s nefarious activities that he suspects he could share his opinion only after giving up his law career. There is and was talk of tort-reform in the book but as can be seen if you reform tort there is just no way to punish such companies but that is in the U.S. There is also some observations that I have shared over the years, for e.g. Europe bans far more drugs than the U.S. does. A major part of it is perhaps due to the fact that Europe has 26/27 independent medical regulators and one country bans medicine for one or the other reason, the rest of Europe also bans the same. In the U.S. it is only the FDA. I have read they have had both funding and staffing issues for years and this is from before the pandemic. The Indian regulators are much worse. One could follow Priyanka Pulla s articles in Mint and others where she has shared how the regulator is corrupt and lazy and a combo of both. And all of this is besides how doctors are corrupted in India by marketing executives of pharma companies. That would be a whole article in itself. In short, when you read this book, there are so many thoughts that come alive when you are reading the book. The sad part is the book doesn t offer any solutions at all. John Grisham s books are usually legal thrillers and courtroom exchanges, this one though is and was very different. This one sadly doesn t take one to any conclusion apart from the fact that we live in an imperfect world and there don t seem to be any solutions. This was even shared by Rep. Katie Porter in her pinned tweet. The Abbvie s of the world will continue to take common people like you and me for a ride.

Changes in version 0.1.7 (2022-02-18)

• Two URLs were updated in 'README.md', and Travis artifacts and badges have been removed (Dirk).
• One unit test file was updated to not trigger a 'LENGTH_1' warning (Dirk closing #76).

This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. Please report excessive re-aggregation in third-party for-profit settings.

• Improved public perception of GNOME as a desktop and GTK as a development platform, helping to align interests between key contributors and wider ecosystem stakeholders and establishing an ongoing collaboration with KDE around the Linux App Summit.
• Worked with the board to improve the maturity of the board itself and allow it to work at a more strategic level, instigating staggered two-year terms for directors providing much-needed stability, and established the Executive and Finance committees to handle specific topics and the Governance committees to take a longer-term look at the board s composition and capabilities.
• Arranged 3 major grants to the Foundation totaling $2M and raised a further $250k through targeted fundraising initiatives.
• Grown the Foundation team to its largest ever size, investing in staff development, and established ongoing direct contributions to GNOME, GTK and Flathub by Foundation staff and contractors.
• Launched and incubated Flathub as an inclusive and sustainable ecosystem for Linux app developers to engage directly with their users, and delivered the Community Engagement Challenge to invest in the sustainability of our contributor base the Foundation s largest and most substantial programs outside of GNOME itself since Outreachy.
• Achieved a fantastic resolution for GNOME and the wider community, by negotiating a settlement which protects FOSS developers from patent enforcement by the Rothschild group of non-practicing entities.
• Stood for a diverse and inclusive Foundation, implementing a code of conduct for GNOME events and online spaces, establishing our first code of conduct committee and updating the bylaws to be gender-neutral.
• Established the GNOME Circle program together with the board, broadening the membership base of the foundation by welcoming app and library developers from the wider ecosystem.

Conferences No surprise, I didn t attend any in-person conferences in 2021. I find virtual conferences don t do a lot for me (a combination of my not carving time out for them in the same way, because not being at the conference means other things will inevitably intrude, and the lack of the social side) but I did get to attend a few of the DebConf21 talks, which was nice. I m hoping to make it to DebConf22 this year in person.

Debian Most of my contributions to Free software continue to happen within Debian. As part of the Data Protection Team I responded to various inbound queries to that team. Some of this involved chasing up other project teams who had been slow to respond - folks, if you re running a service that stores personal data about people then you need to be responsive to requests about it. Some of this was dealing with what look like automated scraping tools which send no information about the person making the request, and in all the cases we ve seen so far there s been no indication of any data about that person on any systems we have access to. Further team time was wasted dealing with the Princeton-Radboud Study on Privacy Law Implementation (though Matthew did the majority of the work on this). The Debian Keyring was possibly my largest single point of contribution. We re in a roughly 3 month rotation of who handles the keyring updates, and I handled 2021.03.24, 2021.04.09, 2021.06.25, 2021.09.25 + 2021.12.24 For Debian New Members I m mostly inactive as an application manager - we generally seem to have enough available recently. If that changes I ll look at stepping in to help, but I don t see that happening. I continue to be involved in Front Desk, having various conversations throughout the year with the rest of the team, but there s no doubt Mattia and Pierre-Elliott are the real doers at present. I did take part in an NM Committee appeals process. In terms of package uploads I continued to work on gcc-xtensa-lx106, largely doing uploads to deal with updates to the GCC version or packaging (8 + 9). sigrok had a few minor updates, libsigkrok 0.5.2-3, pulseview 0.4.2-3 as well as a new upstream release of sigrok CLI 0.7.2-1. There was a last minute pre-release upload of libserialport 0.1.1-4 thanks to a kernel change in v5.10.37 which removed termiox support. Despite still not writing any VHDL these days I continue to keep an eye on ghdl, because I found it a useful tool in the past. Last year that was just a build fix for LLVM 11.1.0 - 1.0.0+dfsg+5. Andreas Bombe has largely taken over more proactive maintenance, which is nice to see. I uploaded OpenOCD 0.11.0~rc1-2, cleaning up some packaging / dependency issues. This was followed by 0.11.0~rc2-1 as a newer release candidate. Sadly 0.11.0 did not make it in time for bullseye, but rc2 was fairly close and I uploaded 0.11.0-1 once bullseye was released. Finally I did a drive-by upload for garmin-forerunner-tools 0.10repacked-12, cleaning up some packaging issues and uploading it to salsa. My Forerunner 305 has died (after 11 years of sterling service) and the Forerunner 45 I ve replaced it with uses a different set of tools, so I decided it didn t make sense to pick up longer term ownership of the package.

Linux My Linux contributions continued to revolve around pushing MikroTik RB3011 support upstream. There was a minor code change to Set FIFO sizes for ipq806x (which fixed up the allowed MTU for the internal switch + VLANs). The rest was DTS related - adding ADM DMA + NAND definitions now that the ADM driver was merged, adding tsens details, adding USB port info and adding the L2CC and RPM details for IPQ8064. Finally I was able to update the RB3011 DTS to enable NAND + USB. With all those in I m down to 4 local patches against a mainline kernel, all of which are hacks that aren t suitable for submission upstream. 2 are for patching in details of the root device and ethernet MAC addresses, one is dealing with the fact the IPQ8064 has some reserved memory that doesn t play well with AUTO_ZRELADDR (there keeps being efforts to add some support for this via devicetree, but unfortunately it gets shot down every time), and the final one is a hack to turn off the LCD backlight by treating it as an LED (actually supporting the LCD properly is on my TODO list).

Personal projects 2021 didn t see any releases of onak. It s not dead, just resting, but Sequoia PGP is probably where you should be looking for a modern OpenPGP implementation. I continued work on my Desk Viking project, which is an STM32F103 based debug tool inspired by the Bus Pirate. The main addtion was some CCLib support (forking it in the process to move to Python 3 and add some speed ups) to allow me to program my Zigbee dongles, but I also added some 1-Wire search logic and some support for Linux emulation mode with VCD output to allow for a faster development cycle. I really want to try and get OpenOCD JTAG mode supported at some point, and have vague plans for an STM32F4 based version that have suffered from a combination of a silicon shortage and a lack of time. That wraps up 2021. I d like to say I m hoping to make more Free Software contributions this year, but I don t have a concrete plan yet for how that might happen, so I ll have to wait and see.

Debian There was a significant progress made in the Debian Linux distribution this month, including:

• Roland Clobus continued work on reproducible live images in the past month, and some of his work was merged into live-build itself. The ReproducibleInstalls/LiveImages page on the Debian Wiki as well as the existing/custom Jenkins hooks were updated to match.
• Related to this, it is now possible to create a bit-by-bit reproducible chroots using mmdebstrap when SOURCE_DATE_EPOCH is set. As of Debian 11 Bullseye, this works for all variants, except for the variant that includes all so-called Priority: standard packages where fontconfig caches, *.pyc files and man-db index.db are unreproducible. (These issues have been addressed in Tails and live-build by removing *.pyc files, in addition to removing index.db files as well. (Whilst index.db files can be regenerated, there is no straightforward method to re-creating *.pyc files, and the resulting installation will suffer from reduced performance of Python scripts. Ideally, no removal would be necessary as all files would be created reproducibly in the first place.)
• Further to this work, Roland wrote up a comprehensive status update about live-build ISO images to our mailing list as well.
• The PackageRebuilder instance running at beta.tests.reproducible-builds.org is now aware/capable of building packages for Debian bookworm.
• A longstanding issue around fontconfig s cache files being unreproducible saw some progress this month. Debian bug number #864082 (originally filed in June 2017) was NMU d by josch, although this resulted in a small number of minor side-effects which have already been addressed with a follow-up patch.
• 120 reviews of Debian packages were added, 272 were updated and 31 were removed this month, all adding to our index of identified issues. A number of issue types were updated too [ ][ ][ ][ ].
• kpcyrd blogged this month about Debian binary NMUs and .buildinfo files in a post entitled, Reproducible Builds: Debian and the case of the missing version string.

Other distributions kpcyrd reported on Twitter about the release of version 0.2.0 of pacman-bintrans, an experiment with binary transparency for the Arch Linux package manager, pacman. This new version is now able to query rebuilderd to check if a package was independently reproduced.
In the world of openSUSE, however, Bernhard M. Wiedemann posted his monthly reproducible builds status report.

diffoscope diffoscope is our in-depth and content-aware diff utility. Not only can it locate and diagnose reproducibility issues, it can provide human-readable diffs from many kinds of binary formats. This month, Chris Lamb prepared and uploaded versions 199, 200, 201 and 202 to Debian unstable (that were later backported to Debian bullseye-backports by Mattia Rizzolo), as well as made the following changes to the code itself:

• New features:
  • First attempt at incremental output support with a timeout. Now passing, for example, --timeout=60 will mean that diffoscope will not recurse into any sub-archives after 60 seconds total execution time has elapsed. Note that this is not a fixed/strict timeout due to implementation issues. [ ][ ]
  • Support both variants of odt2txt, including the one provided by the unoconv package. [ ]
• Bug fixes:
  • Do not return with a UNIX exit code of 0 if we encounter with a file whose human-readable metadata matches literal file contents. [ ]
  • Don t fail if comparing a nonexistent file with a .pyc file (and add test). [ ][ ]
  • If the debian.deb822 module raises any exception on import, re-raise it as an ImportError. This should fix diffoscope on some Fedora systems. [ ]
  • Even if a Sphinx .inv inventory file is labelled The remainder of this file is compressed using zlib, it might not actually be. In this case, don t traceback and simply return the original content. [ ]
• Documentation:
  • Improve documentation for the new --timeout option due to a few misconceptions. [ ]
  • Drop reference in the manual page claiming the ability to compare non-existent files on the command-line. (This has not been possible since version 32 which was released in September 2015). [ ]
  • Update X has been modified after NT_GNU_BUILD_ID has been applied messages to, for example, not duplicating the full filename in the diffoscope output. [ ]
• Codebase improvements:
  • Tidy some control flow. [ ]
  • Correct a recompile typo. [ ]

In addition, Alyssa Ross fixed the comparison of CBFS names that contain spaces [ ], Sergei Trofimovich fixed whitespace for compatibility with version 21.12 of the Black source code reformatter [ ] and Zbigniew J drzejewski-Szmek fixed JSON detection with a new version of file [ ].

Testing framework The Reproducible Builds project runs a significant testing framework at tests.reproducible-builds.org, to check packages and other artifacts for reproducibility. This month, the following changes were made:

• Fr d ric Pierret (fepitre):
  • Add Debian bookworm to package set creation. [ ]
• Holger Levsen:
  • Install the po4a package where appropriate, as it is needed for the Reproducible Builds website job [ ]. In addition, also run the i18n.sh and contributors.sh scripts [ ].
  • Correct some grammar in Debian live image build output. [ ]
  • Shell monitor improvements:
    • Only show the offline node section if there are offline nodes. [ ]
    • Colorise offline nodes. [ ]
    • Shrink screen usage. [ ][ ][ ]
  • Node health check improvements:
    • Detect if live package builds encounter incomplete snapshots. [ ][ ][ ]
    • Detect if a host is running with today s date (when it should be set artificially in the future). [ ]
  • Use the devscripts package from bullseye-backports on Debian nodes. [ ]
  • Use the Munin monitoring package bullseye-backports on Debian nodes too. [ ]
  • Update New Year handling, needed to be able to detect real and fake dates. [ ][ ]
  • Improve the error message of the script that powercycles the arm64 architecture nodes hosted by Codethink. [ ]
• Mattia Rizzolo:
  • Use the new --timeout option added in diffoscope version 202. [ ]
• Roland Clobus:
  • Update the build scripts now that the hooks for live builds are now maintained upstream in the live-build repository. [ ]
  • Show info lines in Jenkins when reproducible hooks have been active. [ ]
  • Use unique folders for the artifacts from each live Debian version. [ ]
• Vagrant Cascadian:
  • Switch the Debian armhf architecture nodes to use new proxy. [ ]
  • Misc. node maintenance. [ ].

Upstream patches The Reproducible Builds project attempts to fix as many currently-unreproducible packages as possible. In January, we wrote a large number of such patches, including:

• Leonidas Spyropoulos:
  • freeplane (timestamps, file order)
  • opensearch (timestamps, file order)
• Bernhard M. Wiedemann:
  • cosign (date)
  • gnome-todo (discover fix for single-CPU build failure)
  • gstreamer-plugins-good (build fails without debuginfo)
  • jogl2 (parallelism-related issue)
  • libkolabxml (ASLR)
  • monero-gui (CPU)
  • python-pyudev (date)
  • rekor (date)
  • rivet (FTBFS-j1 has unreleased fix upstream)
  • skaffold (date)
• Chris Lamb:
  • #1003159 filed against dh-raku.
  • #1003203 filed against libgtkdatabox.
  • #1003385 filed against qcelemental.
  • #1003646 filed against node-ramda.
  • #1003929 filed against ncurses.
  • #1004391 filed against python-fluids (forwarded upstream).
  • #1004676 filed against node-istanbul.
• Johannes Schauer Marin Rodrigues:
  • MR !9 filed against dash
  • #1004557 filed against dpkg.
  • #1004558 filed against python3.10.
• Roland Clobus:
  • #1003449 filed against texlive-base.
• Vagrant Cascadian:
  • #1003316 filed against python-cooler.
  • #1003319 filed against insighttoolkit5.
  • #1003368 filed against dino-im.
  • #1003370 filed against libxtrxll.
  • #1003371 filed against libavif.
  • #1003373 filed against go-for-it.
  • #1003375 filed against clfft.
  • #1003379 filed against last-align.
  • #1003430 filed against gkrellm-leds.
  • #1003488 and #1003489 filed against last-align.
  • #1003494 filed against binutils-xtensa-lx106.
  • #1003495 filed against gcc-xtensa-lx106.
  • #1003500 and #1003501 filed against gcc-sh-elf.
  • #1003787 filed against pesign.
  • #1003802 filed against upb.
  • #1003803 filed against paho.mqtt.c.
  • #1003804 filed against imath.
  • #1003808 filed against libvcflib.
  • #1003809 filed against pkg-js-tools.
  • #1003912 filed against vdeplug4.
  • #1003914 filed against kget.
  • #1003915 filed against mathgl.
  • #1003919 filed against apulse.
  • #1003920 filed against akonadi.
  • #1003922 filed against recastnavigation.
  • #1003923 filed against soundkonverter.
  • #1003924 filed against indi.
  • #1003978 filed against akonadi-mime.
  • #1003980 filed against akonadi-import-wizard.
  • #1003992 filed against akonadi-contacts.
  • #1003993 filed against cryptominisat.
  • #1003995 filed against hipercontracer.
  • #1003997 filed against libksba.
  • #1003999 filed against leatherman.
  • #1004002 filed against segyio.
  • #1004004 filed against darkradiant.
  • #1004005 filed against openmm.
  • #1004034 filed against bagel.
  • #1004053 filed against kallisto.
  • #1004057 filed against evolution-ews.

And finally If you are interested in contributing to the Reproducible Builds project, please visit our Contribute page on our website. However, you can get in touch with us via:

• IRC: #reproducible-builds on irc.oftc.net.
• Twitter: @ReproBuilds
• Mailing list: rb-general@lists.reproducible-builds.org

• [1] https://etbe.coker.com.au/2022/01/26/australia-nz-linux-meetings/
• [2] https://flounder.coker.com.au/2022/02/01/first-meeting-agenda/

This is a program visualization tool aimed at concurrent programs and related issues. The tool itself is mostly language agnostic, and relies on Storm to compile the provided code and provide basic debug information. The generated code is then inspected and instrumented to provide an experience similar to a basic debugger. The tool emphasizes a visual representation of the object hierarchy that is manipulated by the executed program to make it easy to understand how it looks. In particular, a visual representation is beneficial over a text representation since it makes it easier to find shared data that might need to be synchronized in a concurrent program. As mentioned, the tool is aimed at concurrent programs. Therefore, it allows spawning multiple threads running the same program to see if that affects the program s execution (this is mostly interesting if global variables are used). Furthermore, any spawned threads also appear in the tool, and the user may control them independently to explore possible race conditions or other synchronization errors. If enabled from the menu bar, the tool keeps track of reads and writes to the data structure in order to highlight basic race conditions in addition to deadlocks.

• Understanding pointers and indirection
• How strings are handled
• Heap allocation vs. stack allocation
• Shared access to global data

Changes in RcppArmadillo version 0.10.8.1.0 (2022-01-23)

• Upgraded to Armadillo release 10.8.1 (Realm Raider)
  • fix interaction between OpenBLAS and LAPACK
  • emit warning if find() is incorrectly used to locate NaN elements

Changes in RcppArmadillo version 0.10.8.0.0 (2022-01-02)

• Upgraded to Armadillo release 10.8 (Realm Raider)
  • faster handling of symmetric matrices by pinv() and rank()
  • faster handling of diagonal matrices by inv_sympd(), pinv(), rank()
  • expanded norm() to handle integer vectors and matrices
  • added datum::tau to replace 2

This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. Please report excessive re-aggregation in third-party for-profit settings.

import os
with open('non-utf-8-paths.bin', 'wb') as f:
    for root, folders, files in os.walk(b'/srv/sources.debian.org/sources/'):
        for path in folders + files:
            try:
                path.decode('utf-8')
            except UnicodeDecodeError:
                f.write(root + b'/' + path + b'\n')

• File names that are not valid UTF-8, but are valid in a different charset. Not all software is developed in English or on UTF-8 systems.
• File names that can't be decoded to UTF-8 on purpose, to be used as input to test suites, and assert resilience of the software to non-UTF-8 data.

It can synchronise the system clock with NTP servers, reference clocks (e.g. GPS receiver), and manual input using wristwatch and keyboard. It can also operate as an NTPv4 (RFC 5905) server and peer to provide a time service to other computers in the network. It is designed to perform well in a wide range of conditions, including intermittent network connections, heavily congested networks, changing temperatures (ordinary computer clocks are sensitive to temperature), and systems that do not run continuosly, or run on a virtual machine. Typical accuracy between two machines synchronised over the Internet is within a few milliseconds; on a LAN, accuracy is typically in tens of microseconds. With hardware timestamping, or a hardware reference clock, sub-microsecond accuracy may be possible.

My problem with OpenNTPd Following concerns surrounding the security (and complexity) of the venerable ntp program, I have, a long time ago, switched to using openntpd on all my computers. I hadn't thought about it until I recently noticed a lot of noise on one of my servers:

jan 18 10:09:49 curie ntpd[1069]: adjusting local clock by -1.604366s
jan 18 10:08:18 curie ntpd[1069]: adjusting local clock by -1.577608s
jan 18 10:05:02 curie ntpd[1069]: adjusting local clock by -1.574683s
jan 18 10:04:00 curie ntpd[1069]: adjusting local clock by -1.573240s
jan 18 10:02:26 curie ntpd[1069]: adjusting local clock by -1.569592s

You read that right, openntpd was constantly rewinding the clock, sometimes in less than two minutes. The above log was taken while doing diagnostics, looking at the last 30 minutes of logs. So, on average, one 1.5 seconds rewind per 6 minutes! That might be due to a dying real time clock (RTC) or some other hardware problem. I know for a fact that the CMOS battery on that computer (curie) died and I wasn't able to replace it (!). So that's partly garbage-in, garbage-out here. But still, I was curious to see how chrony would behave... (Spoiler: much better.) But I also had trouble on another workstation, that one a much more recent machine (angela). First, it seems OpenNTPd would just fail at boot time:

anarcat@angela:~(main)$ sudo systemctl status openntpd
  openntpd.service - OpenNTPd Network Time Protocol
     Loaded: loaded (/lib/systemd/system/openntpd.service; enabled; vendor pres>
     Active: inactive (dead) since Sun 2022-01-23 09:54:03 EST; 6h ago
       Docs: man:openntpd(8)
    Process: 3291 ExecStartPre=/usr/sbin/ntpd -n $DAEMON_OPTS (code=exited, sta>
    Process: 3294 ExecStart=/usr/sbin/ntpd $DAEMON_OPTS (code=exited, status=0/>
   Main PID: 3298 (code=exited, status=0/SUCCESS)
        CPU: 34ms
jan 23 09:54:03 angela systemd[1]: Starting OpenNTPd Network Time Protocol...
jan 23 09:54:03 angela ntpd[3291]: configuration OK
jan 23 09:54:03 angela ntpd[3297]: ntp engine ready
jan 23 09:54:03 angela ntpd[3297]: ntp: recvfrom: Permission denied
jan 23 09:54:03 angela ntpd[3294]: Terminating
jan 23 09:54:03 angela systemd[1]: Started OpenNTPd Network Time Protocol.
jan 23 09:54:03 angela systemd[1]: openntpd.service: Succeeded.

After a restart, somehow it worked, but it took a long time to sync the clock. At first, it would just not consider any peer at all:

anarcat@angela:~(main)$ sudo ntpctl -s all
0/20 peers valid, clock unsynced
peer
   wt tl st  next  poll          offset       delay      jitter
159.203.8.72 from pool 0.debian.pool.ntp.org
    1  5  2    6s    6s             ---- peer not valid ----
138.197.135.239 from pool 0.debian.pool.ntp.org
    1  5  2    6s    7s             ---- peer not valid ----
216.197.156.83 from pool 0.debian.pool.ntp.org
    1  4  1    2s    9s             ---- peer not valid ----
142.114.187.107 from pool 0.debian.pool.ntp.org
    1  5  2    5s    6s             ---- peer not valid ----
216.6.2.70 from pool 1.debian.pool.ntp.org
    1  4  2    2s    8s             ---- peer not valid ----
207.34.49.172 from pool 1.debian.pool.ntp.org
    1  4  2    0s    5s             ---- peer not valid ----
198.27.76.102 from pool 1.debian.pool.ntp.org
    1  5  2    5s    5s             ---- peer not valid ----
158.69.254.196 from pool 1.debian.pool.ntp.org
    1  4  3    1s    6s             ---- peer not valid ----
149.56.121.16 from pool 2.debian.pool.ntp.org
    1  4  2    5s    9s             ---- peer not valid ----
162.159.200.123 from pool 2.debian.pool.ntp.org
    1  4  3    1s    6s             ---- peer not valid ----
206.108.0.131 from pool 2.debian.pool.ntp.org
    1  4  1    6s    9s             ---- peer not valid ----
205.206.70.40 from pool 2.debian.pool.ntp.org
    1  5  2    8s    9s             ---- peer not valid ----
2001:678:8::123 from pool 2.debian.pool.ntp.org
    1  4  2    5s    9s             ---- peer not valid ----
2606:4700:f1::1 from pool 2.debian.pool.ntp.org
    1  4  3    2s    6s             ---- peer not valid ----
2607:5300:205:200::1991 from pool 2.debian.pool.ntp.org
    1  4  2    5s    9s             ---- peer not valid ----
2607:5300:201:3100::345c from pool 2.debian.pool.ntp.org
    1  4  4    1s    6s             ---- peer not valid ----
209.115.181.110 from pool 3.debian.pool.ntp.org
    1  5  2    5s    6s             ---- peer not valid ----
205.206.70.42 from pool 3.debian.pool.ntp.org
    1  4  2    0s    6s             ---- peer not valid ----
68.69.221.61 from pool 3.debian.pool.ntp.org
    1  4  1    2s    9s             ---- peer not valid ----
162.159.200.1 from pool 3.debian.pool.ntp.org
    1  4  3    4s    7s             ---- peer not valid ----

Then it would accept them, but still wouldn't sync the clock:

anarcat@angela:~(main)$ sudo ntpctl -s all
20/20 peers valid, clock unsynced
peer
   wt tl st  next  poll          offset       delay      jitter
159.203.8.72 from pool 0.debian.pool.ntp.org
    1  8  2    5s    6s         0.672ms    13.507ms     0.442ms
138.197.135.239 from pool 0.debian.pool.ntp.org
    1  7  2    4s    8s         1.260ms    13.388ms     0.494ms
216.197.156.83 from pool 0.debian.pool.ntp.org
    1  7  1    3s    5s        -0.390ms    47.641ms     1.537ms
142.114.187.107 from pool 0.debian.pool.ntp.org
    1  7  2    1s    6s        -0.573ms    15.012ms     1.845ms
216.6.2.70 from pool 1.debian.pool.ntp.org
    1  7  2    3s    8s        -0.178ms    21.691ms     1.807ms
207.34.49.172 from pool 1.debian.pool.ntp.org
    1  7  2    4s    8s        -5.742ms    70.040ms     1.656ms
198.27.76.102 from pool 1.debian.pool.ntp.org
    1  7  2    0s    7s         0.170ms    21.035ms     1.914ms
158.69.254.196 from pool 1.debian.pool.ntp.org
    1  7  3    5s    8s        -2.626ms    20.862ms     2.032ms
149.56.121.16 from pool 2.debian.pool.ntp.org
    1  7  2    6s    8s         0.123ms    20.758ms     2.248ms
162.159.200.123 from pool 2.debian.pool.ntp.org
    1  8  3    4s    5s         2.043ms    14.138ms     1.675ms
206.108.0.131 from pool 2.debian.pool.ntp.org
    1  6  1    0s    7s        -0.027ms    14.189ms     2.206ms
205.206.70.40 from pool 2.debian.pool.ntp.org
    1  7  2    1s    5s        -1.777ms    53.459ms     1.865ms
2001:678:8::123 from pool 2.debian.pool.ntp.org
    1  6  2    1s    8s         0.195ms    14.572ms     2.624ms
2606:4700:f1::1 from pool 2.debian.pool.ntp.org
    1  7  3    6s    9s         2.068ms    14.102ms     1.767ms
2607:5300:205:200::1991 from pool 2.debian.pool.ntp.org
    1  6  2    4s    9s         0.254ms    21.471ms     2.120ms
2607:5300:201:3100::345c from pool 2.debian.pool.ntp.org
    1  7  4    5s    9s        -1.706ms    21.030ms     1.849ms
209.115.181.110 from pool 3.debian.pool.ntp.org
    1  7  2    0s    7s         8.907ms    75.070ms     2.095ms
205.206.70.42 from pool 3.debian.pool.ntp.org
    1  7  2    6s    9s        -1.729ms    53.823ms     2.193ms
68.69.221.61 from pool 3.debian.pool.ntp.org
    1  7  1    1s    7s        -1.265ms    46.355ms     4.171ms
162.159.200.1 from pool 3.debian.pool.ntp.org
    1  7  3    4s    8s         1.732ms    35.792ms     2.228ms

It took a solid five minutes to sync the clock, even though the peers were considered valid within a few seconds:

jan 23 15:58:41 angela systemd[1]: Started OpenNTPd Network Time Protocol.
jan 23 15:58:58 angela ntpd[84086]: peer 142.114.187.107 now valid
jan 23 15:58:58 angela ntpd[84086]: peer 198.27.76.102 now valid
jan 23 15:58:58 angela ntpd[84086]: peer 207.34.49.172 now valid
jan 23 15:58:58 angela ntpd[84086]: peer 209.115.181.110 now valid
jan 23 15:58:59 angela ntpd[84086]: peer 159.203.8.72 now valid
jan 23 15:58:59 angela ntpd[84086]: peer 138.197.135.239 now valid
jan 23 15:58:59 angela ntpd[84086]: peer 162.159.200.123 now valid
jan 23 15:58:59 angela ntpd[84086]: peer 2607:5300:201:3100::345c now valid
jan 23 15:59:00 angela ntpd[84086]: peer 2606:4700:f1::1 now valid
jan 23 15:59:00 angela ntpd[84086]: peer 158.69.254.196 now valid
jan 23 15:59:01 angela ntpd[84086]: peer 216.6.2.70 now valid
jan 23 15:59:01 angela ntpd[84086]: peer 68.69.221.61 now valid
jan 23 15:59:01 angela ntpd[84086]: peer 205.206.70.40 now valid
jan 23 15:59:01 angela ntpd[84086]: peer 205.206.70.42 now valid
jan 23 15:59:02 angela ntpd[84086]: peer 162.159.200.1 now valid
jan 23 15:59:04 angela ntpd[84086]: peer 216.197.156.83 now valid
jan 23 15:59:05 angela ntpd[84086]: peer 206.108.0.131 now valid
jan 23 15:59:05 angela ntpd[84086]: peer 2001:678:8::123 now valid
jan 23 15:59:05 angela ntpd[84086]: peer 149.56.121.16 now valid
jan 23 15:59:07 angela ntpd[84086]: peer 2607:5300:205:200::1991 now valid
jan 23 16:03:47 angela ntpd[84086]: clock is now synced

That seems kind of odd. It was also frustrating to have very little information from ntpctl about the state of the daemon. I understand it's designed to be minimal, but it could inform me on his known offset, for example. It does tell me about the offset with the different peers, but not as clearly as one would expect. It's also unclear how it disciplines the RTC at all.

Compared to chrony Now compare with chrony:

jan 23 16:07:16 angela systemd[1]: Starting chrony, an NTP client/server...
jan 23 16:07:16 angela chronyd[87765]: chronyd version 4.0 starting (+CMDMON +NTP +REFCLOCK +RTC +PRIVDROP +SCFILTER +SIGND +ASYNCDNS +NTS +SECHASH +IPV6 -DEBUG)
jan 23 16:07:16 angela chronyd[87765]: Initial frequency 3.814 ppm
jan 23 16:07:16 angela chronyd[87765]: Using right/UTC timezone to obtain leap second data
jan 23 16:07:16 angela chronyd[87765]: Loaded seccomp filter
jan 23 16:07:16 angela systemd[1]: Started chrony, an NTP client/server.
jan 23 16:07:21 angela chronyd[87765]: Selected source 206.108.0.131 (2.debian.pool.ntp.org)
jan 23 16:07:21 angela chronyd[87765]: System clock TAI offset set to 37 seconds

First, you'll notice there's none of that "clock synced" nonsense, it picks a source, and then... it's just done. Because the clock on this computer is not drifting that much, and openntpd had (presumably) just sync'd it anyways. And indeed, if we look at detailed stats from the powerful chronyc client:

anarcat@angela:~(main)$ sudo chronyc tracking
Reference ID    : CE6C0083 (ntp1.torix.ca)
Stratum         : 2
Ref time (UTC)  : Sun Jan 23 21:07:21 2022
System time     : 0.000000311 seconds slow of NTP time
Last offset     : +0.000807989 seconds
RMS offset      : 0.000807989 seconds
Frequency       : 3.814 ppm fast
Residual freq   : -24.434 ppm
Skew            : 1000000.000 ppm
Root delay      : 0.013200894 seconds
Root dispersion : 65.357254028 seconds
Update interval : 1.4 seconds
Leap status     : Normal

We see that we are nanoseconds away from NTP time. That was ran very quickly after starting the server (literally in the same second as chrony picked a source), so stats are a bit weird (e.g. the Skew is huge). After a minute or two, it looks more reasonable:

Reference ID    : CE6C0083 (ntp1.torix.ca)
Stratum         : 2
Ref time (UTC)  : Sun Jan 23 21:09:32 2022
System time     : 0.000487002 seconds slow of NTP time
Last offset     : -0.000332960 seconds
RMS offset      : 0.000751204 seconds
Frequency       : 3.536 ppm fast
Residual freq   : +0.016 ppm
Skew            : 3.707 ppm
Root delay      : 0.013363549 seconds
Root dispersion : 0.000324015 seconds
Update interval : 65.0 seconds
Leap status     : Normal

Now it's learning how good or bad the RTC clock is ("Frequency"), and is smoothly adjusting the System time to follow the average offset (RMS offset, more or less). You'll also notice the Update interval has risen, and will keep expanding as chrony learns more about the internal clock, so it doesn't need to constantly poll the NTP servers to sync the clock. In the above, we're 487 micro seconds (less than a milisecond!) away from NTP time. (People interested in the explanation of every single one of those fields can read the excellent chronyc manpage. That thing made me want to nerd out on NTP again!) On the machine with the bad clock, chrony also did a 1.5 second adjustment, but just once, at startup:

jan 18 11:54:33 curie chronyd[2148399]: Selected source 206.108.0.133 (2.debian.pool.ntp.org) 
jan 18 11:54:33 curie chronyd[2148399]: System clock wrong by -1.606546 seconds 
jan 18 11:54:31 curie chronyd[2148399]: System clock was stepped by -1.606546 seconds 
jan 18 11:54:31 curie chronyd[2148399]: System clock TAI offset set to 37 seconds 

Then it would still struggle to keep the clock in sync, but not as badly as openntpd. Here's the offset a few minutes after that above startup:

System time     : 0.000375352 seconds slow of NTP time

And again a few seconds later:

System time     : 0.001793046 seconds slow of NTP time

I don't currently have access to that machine, and will update this post with the latest status, but so far I've had a very good experience with chrony on that machine, which is a testament to its resilience, and it also just works on my other machines as well.

Extras On top of "just working" (as demonstrated above), I feel that chrony's feature set is so much superior... Here's an excerpt of the extras in chrony, taken from the comparison table:

• source frequency tracking
• source state restore from file
• temperature compensation
• ready for next NTP era (year 2036)
• replace unreachable / falseticker servers
• aware of jitter
• RTC drift tracking
• RTC trimming
• Restore time from file w/o RTC
• leap seconds correction, in slew mode
• drops root privileges

I even understand some of that stuff. I think. So kudos to the chrony folks, I'm switching.

Caveats One thing to keep in mind in the above, however is that it's quite possible chrony does as bad of a job as openntpd on that old machine, and just doesn't tell me about it. For example, here's another log sample from another server (marcos):

jan 23 11:13:25 marcos ntpd[1976694]: adjusting clock frequency by 0.451035 to -16.420273ppm

I get those basically every day, which seems to show that it's at least trying to keep track of the hardware clock. In other words, it's quite possible I have no idea what I'm talking about and you definitely need to take this article with a grain of salt. I'm not an NTP expert. Update: I should also mentioned that I haven't evaluated systemd-timesyncd, for a few reasons:

1. I have enough things running under systemd
2. I wasn't aware of it when I started writing this
3. I couldn't find good documentation on it... later I found the above manpage and of course the Arch Wiki but that is very minimal
4. therefore I can't tell how it compares with chrony or (open)ntpd, so I don't see an enticing reason to switch

It has a few things going for it though:

• it's likely shipped with your distribution already
• it drops privileges (possibly like chrony, unclear if it also has seccomp filters)
• it's minimalist: it only does SNTP so not the server side
• the status command is good enough that you can tell the clock frequency, precision, and so on (especially when compared to openntpd's ntpctl)

So I'm reserving judgement over it, but I'd certainly note that I'm always a little weary in trusting systemd daemons with the network, and would prefer to keep that attack surface to a minimum. Diversity is a good thing, in general, so I'll keep chrony for now. It would certainly nice to see it added to chrony's comparison table.

Switching to chrony Because the default configuration in chrony (at least as shipped in Debian) is sane (good default peers, no open network by default), installing it is as simple as:

apt install chrony

And because it somehow conflicts with openntpd, that also takes care of removing that cruft as well.

Update: Debian defaults So it seems like I managed to write this entire blog post without putting it in relation with the original reason I had to think about this in the first place, which is odd and should be corrected. This conversation came about on an IRC channel that mentioned that the ntp package (and upstream) is in bad shape in Debian. In that discussion, chrony and ntpsec were discussed as possible replacements, but when we had the discussion on chat, I mentioned I was using openntpd, and promptly realized I was actually unhappy with it. A friend suggested chrony, I tried it, and it worked amazingly, I switched, wrote this blog post, end of story. Except today (2022-02-07, two weeks later), I actually read that thread and realized that something happened in Debian I wasn't actually aware of. In bookworm, systemd-timesyncd was not only shipped, but it was installed by default, as it was marked as a hard dependency of systemd. That was "fixed" in systemd-247.9-2 (see bug 986651), but only by making the dependency a Recommends and marking it as Priority: important. So in effect, systemd-timesyncd became the default NTP daemon in Debian in bookworm, which I find somewhat surprising. timesyncd has many things going for it (as mentioned above), but I do find it a bit annoying that systemd is replacing all those utilities in such a way. I also wonder what is going to happen on upgrades. This is all a little frustrating too because there is no good comparison between the other NTP daemons and timesyncd anywhere. The chrony comparison table doesn't mention it, and an audit by the Core Infrastructure Initiative from 2017 doesn't mention it either, even though timesyncd was announced in 2014. (Same with this blog post from Facebook.)

Changes in RQuantLib version 0.4.15 (2022-01-19)

• Changes in RQuantLib code:
  • Calendar support has been updated and completed to current QuantLib standards (Dirk in #161)
  • More daycounters have been added (Kai Lin in #163 fixing #162, #164)
  • The bonds pricers were update to changes in QuantLib 1.25 (Dirk)
• Changes in RQuantLib package and setup:
  • Some package metadata was removed from the README.md (Dirk)

This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. Please report excessive re-aggregation in third-party for-profit settings.