Happy solstice, and happy Volunteer Responsibility Amnesty Day! After my inventory of my code today, I have decided it's time to pass on moreutils to someone new. This project remains interesting to people, including me. People still send patches, which are easy to deal with. Taking up basic maintenance of this package will be easy for you, if you feel like stepping forward. People still contribute ideas and code for new tools to add to moreutils. But I have not added any new tools to it since 2016. There is a big collections of ideas that I have done nothing with. The problem, I realized, is that "general-purpose new unix tool" is rather open-ended, and kind of problimatic. Picking new tools to add is an editorial process, or it becomes a mishmash of too many tools that are perhaps not general purpose. I am not a great editor, and so I tightened my requirements for "general-purpose" and "new" so far that I stopped adding anything. If you have ideas to solve that, or fearless good taste in curating a collection, this project is for you. The other reason it's less appealing to me is that unix tools as a whole are less appealing to me now. Now, as a functional programmer, I can get excited about actual general-purpose functional tools. And these are well curated and collected and can be shown to fit because the math says they do. Even a tiny Haskell function like this is really very interesting in how something so maximally trivial is actually usable in so many contexts.

id :: a -> a
id x = x

Anyway, I am not dropping maintenance of moreutils unless and until someone steps up to take it on. As I said, it's easy. But I am laying down the burden of editorial responsibility and won't be thinking about adding new tools to it.

---

Thanks very much to Sumana Harihareswara for developing and promoting the amnesty day idea!

I've been using Vim as my main text editor for 18 years, but for most of that time I've been using something very close to the default configuration: my vimrc contained not much more than preferences for indentation and how to visually indicate white space characters like tabs. Last but not least, I've used a single colour scheme for most of that time: Zenburn. In 2015¹ I started exploring a few Vim plugins². To manage them, I started by choosing a plugin manager, Pathogen³. Recently I noticed that the plugin's author, Tim Pope, now recommends new users just use Vim's built in package management instead. I got curious about Tim Pope's other plugins: He has written a great deal of them. Given I've spent most of two decades with a barely-configured Vim, you can imagine that I don't want to radically alter the way it works, and so I did not expect to want to use a lot of plugins. The utility of a plugin would have to outweight the disadvantages of coming to rely on one. But when browsing Tim's plugins, time and time again, I found myself reacting to description with How did I manage without this?. And so, I've ended up installing all of the following, all by Tim Pope:

• vim-characterize add unicode character names to output of ga
• vim-dispatch An out-of-band system for making ":Make" non-blocking
• vim-fugitive high quality Git integration
• vim-rsi - readline key mappings in a few sensible places
• vim-sleuth Figure out whitespace preferences (tabs, indentation level) from the current buffer
• vim-speeddating handle dates (YYYY-MM-DD) properly with the increment/decrement functions (<C-A>, <C-X>)
• vim-surround mappings to manage "pairs" of characters nicely (e.g. brackets, quotes)
• vim-unimpaired pairs of complementary mappings, e.g. short mappings for :cnext and :cprevious
• vim-vinegar quality-of-live improvements to netrw, Vim's built-in file browser

I've created new ISO images for FAI. Now, they install Debian 11 using kernel 5.10. The ISOs are available from https://fai-project.org/fai-cd There's also a Ubuntu version of the FAI CD which installs Ubuntu LTS 20.04 in two variants. A desktop and a server installation is available. If you want to install the Debian oldstable version (Debian 10), please use the FAI.me service. FAI

After a bit of a delay, WordPress version 5.8.2 packages should be available now. This is a minor update from 5.8.1 which fixes two bugs but not the security bug. The security bug is due to WordPress shipping its own CA store, which is a list of certificates it trusts to sign for websites. Debian WordPress has used the system certificate store which uses /etc/ssl/certs/ca-certificates.crt for years so is not impacted by this change. That CA file is generated by update-ca-certificates and is part of the ca-certificates package. We have also had another go of tamping down the nagging WordPress does about updates, as you cannot use the automatic updates through WordPress but via the usual Debian system. I see we are not fully there as WordPress has a site health page that doesn t like things turned off. The two bugs fixed in 5.8.2 I ve not personally hit, but they might help someone out there. In any case, an update is always good. Next stop 5.9 The next planned release is in late January 2022. I m sure there will be a new default theme, but they are planning on making big changes around the blocks and styles to make it easier to customise the look.

A new maintenance RcppSMC release 0.2.6 arrived at CRAN yesterday. It chiefly updates the code to comply with g++-11 which default to C++17 which brings us std::data(). And if one is not careful, as we weren t in three files, this can clash with other uses of data as I tweeted a good week ago. Otherwise some JSS URLs now sport the preferred shorter doi form. RcppSMC provides Rcpp-based bindings to R for the Sequential Monte Carlo Template Classes (SMCTC) by Adam Johansen described in his JSS article. Sequential Monte Carlo is also referred to as Particle Filter in some contexts. The package features the Google Summer of Code work by Leah South in 2017, and by Ilya Zarubin in 2021. This release is summarized below.

Changes in RcppSMC version 0.2.6 (2021-12-17)

• Updated URLs to JSS for the new DOI scheme upon their request
• Adjusted three source files for C++17 compilation under g++-11

Courtesy of my CRANberries, there is a diffstat report for this release. More information is on the RcppSMC page. Issues and bugreports should go to the GitHub issue tracker. If you like this or other open-source work I do, you can now sponsor me at GitHub.

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

Many developers manage their user-specific application configuration also known as dotfiles in a version control system such as git. This allows for keeping track of changes and synchronizing the dotfiles across different machines. Searching on github, you ll find thousands of dotfile repositories. As your dotfiles are sprinkled all over your home directory, managing them in a single repository is not trivial, i.e. how do you make sure that your .bashrc, .tmux.conf, etc. that life in your dotfile repository appear in the proper places in your home directory? The most common solution is to use symlinks so that the .tmux.conf in your home directory is just a symlink pointing to the appropriate file in your dotfile repository: This leads immediately to another problem: how do you manage the symlinks? For the longest time I just manually maintained the symlinks on the various machines, but this approach does not scale well with the number of dotfiles and machines you re using this repository on. Often, people write their own shell scripts that help them with the maintenance of the symlinks, but at least the solutions I ve seen so far did not convince me. Last year I stumbled upon GNU Stow, an unpretentious little tool that does not reveal at first sight how useful it would be for the job. The description on the website says:

GNU Stow is a symlink farm manager which takes distinct packages of software and/or data located in separate directories on the filesystem, and makes them appear to be installed in the same place.

Right. How does it work? In stow s terminology, a package is a set of files and directories that need to be installed in a particular directory structure. The target directory is the root of the tree in which the package appear to be installed. When you stow a package, stow creates symlinks in the target directory that point into the package. Let s say I have my dotfiles repository in ~/git/dotfiles/. Within this repository, I have a tmux package, containing the .tmux.conf dotfile: The target directory is my home directory, as this is where the symlinks need to be created. I can now stow the tmux package into the target directory like so: and stow will create the appropriate symlinks to the contents of the package into the target directory: Note that the name of the package (i.e. the name of the directory) does not matter as stow points the symlinks into the package, so you can choose it freely. I usually use the name of the program that the configuration belongs to as the package name. Your package can also contain several files or even a complex directory structure. Let s look at the configuration for neovim, which lives below ~/.config/nvim/: At this point we should mention that the target directory for my dotfiles will always be my home directory, so the contents of the packages are either the configuration files or the directory structure as they live in my home directory. Deleting a package from the parent directory You can also remove (unstow) a package from the target directory again, using the --delete parameter: Stowing several packages at once Since your dotfile repository will likely contain more than one package, it makes sense to combine the individual stow commands into one, so instead of stowing everything individually, you can stow everything at once: Note that I use */ instead of * to match all directories (i.e. packages), since my dotfiles repository also contains a README.md and a makefile. Putting it all together My dotfiles repository contains a makefile that allows me to create/update or delete all symlinks at once: The --restow parameter tells stow to unstow the packages first before stowing them again, which is useful for pruning obsolete symlinks from the target directory. Et voil ! Whenever I make a change in my dotfiles repository that involves creating or deleting a dotfile (or a package), I simply call: and everything is updated. To delete all dotfile-related symlinks from this machine, I simply run:

Review: Raybearer, by Jordan Ifueko

Series:	Raybearer #1
Publisher:	Amulet Books
Copyright:	2020
ISBN:	1-68335-719-1
Format:	Kindle
Pages:	308

Tarisai was raised alone in Bhekina House by an array of servants and tutors who were not allowed to touch her. Glimpses of the world were fleeting and sometimes ended by nailed-shut windows. Her life revolved around her rarely-seen mother, The Lady, who treats her with deep affection but rarely offers a word of praise, instead only pushing her to study harder. The servants whispered behind her back (but still in her hearing) that she was not human. At the age of seven, in a child's attempt to locate her absent mother by sneaking out of the house, she finds her father and is told a piece of the truth: she is the daughter of the Lady and a captive ehru, a djinn. At the age of eleven she's sent with two guardians to Oluwan City, the capital of Aritsar, to enter a competition she knows nothing about, for reasons no one has ever explained. Raybearer is a young adult fantasy novel, the first of a duology. Like a lot of young adult novels, it is a coming of age story that follows Tarisai from the end of her highly manipulated childhood through her introduction to a world she was carefully never taught about. Like a lot of young adult fantasy novels, Tarisai has some unusual abilities. What those are, and why she has them, is perhaps less obvious than it may appear at first. Unlike a lot of young adult fantasy novels, Raybearer is not set in a facsimile of Western Europe, the structure of gods and religion is not obviously derived from Christianity or Greek or Norse mythology, and neither Tarisai nor most of the characters of this story are white. Some of the characters are; Ifueko draws from a grab bag of cultures that does include European as well as African, Middle Eastern, and Asian. But the food, the physical descriptions, the landscape, and the hair and hair styles feel primarily African not in the sense of specific identifiable regions, but in the same way that most fantasy feels European even if the map isn't recognizable. That gives this story a freshness that I found delightful. The mythology of this world shares some similarities to standard fantasy tropes, including a bargain with the underworld that plays a similar role to fae bargains in some European fantasy, but it also goes in different directions and finds atypical balances, which gave the story room to catch me by surprise. The magical center of this book (and series), which Tarisai is carefully not told about until the story starts, is a system for anointing and protecting the emperor: selection of people who swear loyalty to him and each other and become his innermost circle, and thereby grant him magical protection. The emperor himself is the Raybearer, possessing an artifact that makes him invulnerable to one form of death for each member of his council he anoints. At eleven council members, he becomes invulnerable to anything but old age, or an attack from one of the council themselves. As the reader learns early in the book, that last part is important. Tarisai is an assassin; her mother's goal is for her to be selected as a member of the council for the prince, who will become the next emperor. But there is rather more to this system of magic than it may first appear, in a way that adds good depth to the mythology. And there is quite a bit more to Tarisai herself than anyone expects. Tarisai as a protagonist follows a more typical young adult pattern, but it's a formula that works for me. Her upbringing isolated from any other children has left her craving connection, but it also made her self-reliant, stubborn, and good at keeping her own counsel. One of the things that I loved about this book is that she's not thrown into a nest of vipers and cynical politics. Some of that is happening in the background, but the first step of her mother's plan is for her to earn the trust of the prince in a competition with other potential council members, all of whom are, well, kids. They fight (some), but they also make friends, helped along by the goal and requirement that they join a cooperative council or be sent home. That gives the plot a more collaborative and social feel than one would otherwise expect from the setup. Ifueko does a great job juggling a challenging cast size by focusing on a few kids with whom Tarisai strikes up a friendship but giving the others distinct-enough personalities that their presence is still felt in the story. There are two character dynamics that stand out: Tarisai's relationship with Prince Ekundayo, and her friendship with Sanjeet. The first carries much of the weight of the plot, of course; Tarisai is supposed to gain his trust and then kill him, and the reader will be unsurprised that this takes twists and turns no one expected. But Ifueko, refreshingly, does not reach for the stock plot development of a romance to complicate matters, even though many of the characters expect that. To the contrary, this is a rare story that at least hints at an acknowledgment that some people are not interested in romance at all, and there are other forms that mutual respect can take. Tarisai's relationship with Sanjeet is a different type of depth: two kids with very different histories finding a common understanding in the ways that they were both abused, and create space for each other. It's a great friendship that includes some deeply touching moments. It took me a bit to get into this book, but once Tarisai starts finding her feet and navigating her new relationships, I was engrossed. The story takes a sharp and nasty turn that was hard to read, but Ifueko chooses to turn it into a story of resiliency rather than survival, which makes it much easier to read than it could have been. She also pulls off the kind of plot that complicates and deepens the motives of the obvious villains in a way that gives the story much greater heft, but without disregarding the damage that they have done. I think the plot did fall apart a bit at the end of the book, with too much quick travel and world-building revelations at the cost of development of the relationships that were otherwise at the center of the book, but I'm hoping the sequel will pull those threads back together. And it's so refreshing to read a fantasy novel of this type with a different setting. It's not perfect: Ifueko falls back on Planet of the Hats regional characterization in a few places, and Songland is so obviously Korea that it felt jarring and out of place. Christianity also snuck its nose into the world-building tent near the end in ways that bugged me a bit, although it was subtle enough that I think most readers won't notice. But compared to most fantasy settings, it feels original and fresh. More of this! Ifueko starts this book with a wonderfully memorable dedication:

For the kid scanning fairy tales for a hero with a face like theirs. And for the girls whose stories we compressed into pities and wonders, triumphs and cautions, without asking, even once, for their names.

I think she was successful on both parts of that promise, and it makes for some great reading. Recommended. Followed by Redemptor. Rating: 8 out of 10

In November I was assigned 0.75 hours of work by Freexian's Debian LTS initiative and carried over 15.25 hours from earlier months. I mistakenly worked 20 hours, which we'll try to resolve. I continued work on an update to the linux (4.9) package, but did not make an upload this month.

We've more or less finished the release of the Debian CD/DVD/Blu-Ray and other media for Bullseye 11.2 release. This is one of the (roughly) quarterly point releases and roll-up releases.Thanks firstly to the developers, users, helpers, bug filers who help to keep Debian moving and working and to the release team and press team who more or less finish their job before the media team start theirs.
Thanks to Sledge and RattusRattus and Isy in Cambridge and to Schweer who single-handedly clears all the Debian-edu testing. This release run seemed to be a bit more slick, a bit faster, a few fewer problems and it's always a joy to work with colleagues who are like family.The last couple of years have been more than a bit difficult: this (should) be more or less the last major action from the release team and others for 2021.I'm going to take the opportunity this gives me to wish all concerned with Debian (and every other Linux) the very best wishes for the year to come. Surely, it can only get better - eventually.

Debian comes with tons of fonts for all kinds of purposes, you can easily list them (almost) all with: apt-cache search ^fonts-. However, sometimes they are not in their latest version, or as a user you would like to get access to new fonts that are not present in Debian stable yet. With the tool fnt you can easily preview, and install fonts from Debian sid and Google Web Fonts (that's about 2,000 fonts that are DSFG compliant). Any user can use the tool to install fonts only for the user itself, or the system administrator can run it as root to install the fonts system wide. The package fnt is already in Bookworm, so if you run Debian testing you can use it to get, test and use many fonts that are in their way of being packaged in Debian: ITP #973779 fnt install scheherazadenew
RFP #944140 fnt install arsenal
RFP #757249 fnt install ekmukta
RFP #724629 fnt install firasans
RFP #766211 fnt install orbitron
RFP #803690 fnt install pompiere
RFP #754784 fnt install raleway
RFP #827735 fnt install reemkufi
RFP #986999 fnt install redhat display,mono,text If you want to learn more you can have a look at the wiki page about fonts (https://wiki.debian.org/Fonts), and if you want to contribute or maintain fonts in Debian, don't hesitate to join the Fonts Team!

This year I finally bought an e-reader: a "Kobo Libra H2O": a 7" 300ppi screen with an adjustable colour temperature front light, waterproof, physical buttons on a "margin"/spine which pushes the case dimensions up to 8", which is sadly a little too big for most jeans pockets. In fact this is the second time I've bought one. Sarah and I bought a pair of Amazon Kindle Paperwhite (2^nd generation) readers as Honeymoon gifts for each other in 2013. Sarah took to hers, but after giving mine a try and reading a couple of books on it I ended up giving it to my Father-in-law. The main problem I had with it was the colour temperature of the backlight: it was too blue and "clinical". It's interesting to me to realise how the environment that I read in can become indelibly linked to the memory of that book. One book in particular that I read on the Kindle was James Smythe's "The Machine", a modern twist on a classic horror story. This was perfectly complemented by the somewhat pallid, sick colour of the backlight, especially on its lowest brightness settings. It didn't go so well with other stories. I got on much better with the Libra H2O. For me, e-books and e-reading has not replaced traditional paper books, but complemented them, giving me an opportunity to read in contexts and situations where I couldn't manage with a real book (such as in the pitch black, lying on my back with a toddler on my chest). I feel that being able to read more often thanks to the e-reader has spurred me on to read even paper books more frequently as well. Unfortunately the screen broke, about 10 months after I bought it! After a bit of soul-searching on what to do about replacing it, and briefly considering the latest Amazon Paperwhite (which now has a 300ppi display and adjustable-colour temperature front-light). This looks like a very nice e-reader: no physical buttons which is a bit of a shame but narrower without the margin/spine of the Kobo, so possibly more pocket-friendly. On the other hand, I really felt that I wanted to avoid giving Amazon the money, for a whole variety of reasons. So I instead settled on the "Kobo Libra 2", which is a slight refresh of the Libra H2O, but almost identical. I'm going to pair it with a nice cover for when its not in use and hopefully it will last longer than its predecessor. My current favourite feature on the Libra 2, that I don't remember on the H2O and I'm fairly sure doesn't exist on Kindles is it supports a "night mode", which is effectively a reverse video, white-on-black mode. This is fantastic for keeping the light levels down at night. I was already using the backlight at about 2% brightness and occasionally found even that too bright.

Armadillo is a powerful and expressive C++ template library for linear algebra aiming towards a good balance between speed and ease of use with a syntax deliberately close to a Matlab. RcppArmadillo integrates this library with the R environment and language and is widely used by (currently) 937 other packages on CRAN, and downloaded over 22 million times (per the partial logs from the cloud mirrors of CRAN). This release brings another bug fix release 10.7.5 by Conrad in the long-term support 10.7.* series we started with 0.10.7.0 on September 30. As the bug fixes can come a little quicker than the desired monthly cadence CRAN aims for, we skipped a few of those release for CRAN only but of course still provide them via the Rcpp drat repo. The full set of changes (since the last CRAN release 0.10.7.3.0) follows. It includes the nice fixes to the fields type mentioned right after the last release.

Changes in RcppArmadillo version 0.10.7.5.0 (2021-12-16)

• Upgraded to Armadillo release 10.7.5
  • fix aliasing bug in diagmat()
  • fix detection of 2x2 triangular matrices

Changes in RcppArmadillo version 0.10.7.4.0 (2021-11-23)

• Upgraded to Armadillo release 10.7.4
  • faster handling of diagonal matrices by inv_sympd(), pinv(), rank()
  • more robust detection of incorrect data format by .load()
• Correct dimensions setting in import/export of arma::field types, protected by #define (Jonathan Berrisch in #352 fixing #351)
• Add unit tests for fields both with and without new #define (Dirk)

Courtesy of my CRANberries, there is a diffstat report relative to previous release. More detailed information is on the RcppArmadillo page. Questions, comments etc should go to the rcpp-devel mailing list off the R-Forge page. If you like this or other open-source work I do, you can sponsor me at GitHub.

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

The diffoscope maintainers are pleased to announce the release of diffoscope version 197. This version includes the following changes: You find out more by visiting the project homepage.

A new release 0.4.18 of RProtoBuf arrived on CRAN earlier today. RProtoBuf provides R with bindings for the Google Protocol Buffers ( ProtoBuf ) data encoding and serialization library used and released by Google, and deployed very widely in numerous projects as a language and operating-system agnostic protocol. This release, the first since March of last year, contains two contributed pull requests improving or extending the package, some internal maintance updating the CI setup as well as retiring an old-yet-unused stub interface for RPC, as well as an update for UCRT builds on Windows. The following section from the NEWS.Rd file has more details.

Changes in RProtoBuf version 0.4.18 (2021-12-15)

• Support string_view in FindMethodByName() (Adam Cozzette in #72).
• CI use was updated first at Travis, later at GitHub and now uses r-ci (Dirk in #74 and (parts of) #76).
• The (to the best of our knowledge) unused minimal RPC mechanism has been removed, retiring one method and one class as well as the import of the RCurl package (Dirk in #76).
• The toJSON() method supports two (upstream) formatting toggles (Vitali Spinu in #79 with minor edit by Dirk).
• Windows UCRT builds are now supported (Jeroen in #81, Dirk and Tomas Kalibera in #82).

Thanks to my CRANberries, there is a diff to the previous release. The RProtoBuf page has copies of the (older) package vignette, the quick overview vignette, and the pre-print of our JSS paper. Questions, comments etc should go to the GitHub issue tracker off the GitHub repo. If you like this or other open-source work I do, you can now sponsor me at GitHub.

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

Boost is a very large and comprehensive set of (peer-reviewed) libraries for the C++ programming language, containing well over 100 individual libraries. The BH package provides a sizeable subset of header-only libraries for (easier, no linking required) use by R. It is fairly widely used: the (partial) CRAN mirror logs (aggregated from the cloud mirrors) show over 28 million package downloads. Version 1.78.0 of Boost was released in a few days ago on their schedule with April, August and December releases. We follow these releases at a lower (annual) cadence, and BH 1.78.0-0 catches up to Boost 1.78 from the 1.75 version packaged last winter. Three reverse-depends checks revealed only minors needs for changes (after I corrected a fat-finger typo, whoops) in a handful of packages whose maintainers I contacted via PRs or emails. With that, CRAN permitted the upload yesterday. My thanks once again to the maintainers of these packages for helping it along promptly, and of course to the CRAN team. This release adds the new header-only library Boost Lambda2 offering simple but functional lambda functions (for C++14 and later), as well as Boost Process to manage system processes.

Changes in version 1.78.0-0 (2020-12-14)

• Incremental updates to README.md and CI setup
• Upgraded to Boost 1.78.0 (#82 closing #80)
• Added process (closing #78)
• Added lambda2 (closing #81)

Via my CRANberries, there is a diffstat report relative to the previous release. Comments and suggestions about BH are welcome via the issue tracker at the GitHub repo. If you like this or other open-source work I do, you can now sponsor me at GitHub.

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

Boost is a very large and comprehensive set of (peer-reviewed) libraries for the C++ programming language, containing well over 100 individual libraries. The BH package provides a sizeable subset of header-only libraries for (easier, no linking required) use by R. It is fairly widely used: the (partial) CRAN mirror logs (aggregated from the cloud mirrors) show over 28 million package downloads. Version 1.78.0 of Boost was released in a few days ago on their schedule with April, August and December releases. We follow these releases at a lower (annual) cadence, and BH 1.78.0-0 catches up to Boost 1.78 from the 1.75 version packaged last winter. Three reverse-depends checks revealed only minors needs for changes (after I corrected a fat-finger typo, whoops) in a handful of packages whose maintainers I contacted via PRs or emails. With that, CRAN permitted the upload yesterday. My thanks once again to the maintainers of these packages for helping it along promptly, and of course to the CRAN team. This release adds the new header-only library Boost Lambda2 offering simple but functional lambda functions (for C++14 and later), as well as Boost Process to manage system processes.

Changes in version 1.78.0-0 (2020-12-14)

• Incremental updates to README.md and CI setup
• Upgraded to Boost 1.78.0 (#82 closing #80)
• Added process (closing #78)
• Added lambda2 (closing #81)

Via my CRANberries, there is a diffstat report relative to the previous release. Comments and suggestions about BH are welcome via the issue tracker at the GitHub repo. If you like this or other open-source work I do, you can now sponsor me at GitHub.

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

Every month we review the work funded by Freexian s Debian LTS offering. Please find the report for November below. Debian project funding

• Our project funding work continues with an active bid on the work of packaging a recent gradle in Debian. This month the bidder has been estimating the scope of the entire project.
• The Grow Your Ideas project page also has some ambitious initiatives that may evolve into a funded project. The project ideas on that page range from a new wiki for Debian, a more efficient reimbursement process, and the implementation of PPAs for Debian.
• In November 2625 was put aside to fund Debian projects.

We continue to looking forward to hearing about Debian project proposals from various Debian stakeholders. This month has seen work on a survey that will go out to Debian Developers to gather feedback on what they think should be the priorities for funding in the project. Learn more about the rationale behind this initiative in this article. Debian LTS contributors In November 13 contributors were paid to work on Debian LTS, their reports are available below. If you re interested in participating in the LTS or ELTS teams, we welcome participation from the Debian community. Simply get in touch with Jeremiah if you are interested in participating.

• Adrian Bunk did 62h out of 56h assigned for November and 6h from October.
• Anton Gladky did 12h out of 12h assigned.
• Ben Hutchings did 20h (out of 16h available, thus anticipating 4h from December).
• Chris Lamb did 18h out of 18h assigned.
• Holger Levsen gave back 3h (out of 3h assigned).
• Jeremiah Foster is coordinating/managing the LTS team did 29h (out of 10h assigned and 10h from October for LTS administration), and spent 9 hours on Projects funded directly through the project funding program.
• Lee Garrett did 9 hours out 60 assigned and carried over 51h into December
• Markus Koschany did 30h out of 30h assigned.
• Neil Williams did 1.5h (out of 11.5h assigned and 28.5h from October). He gave back the remaining hours.
• Roberto C. S nchez did 31.5h (out of 32h assigned), thus carrying over .5h to December.
• Sylvain Beucler did 21.5h (out of 62h assigned), thus carrying over 40.5h to December.
• Thorsten Alteholz did 40h (out of 40h assigned).
• Utkarsh Gupta did 30 (out of 40h assigned), thus carrying over 10h to December.

Evolution of the situation In November we released 31 DLAs. The security tracker currently lists 23 packages with a known CVE and the dla-needed.txt file has 16 packages needing an update. Thanks to our sponsors Sponsors that joined recently are in bold.

• Platinum sponsors:
  • TOSHIBA (for 75 months)
  • GitHub (for 65 months)
  • Civil Infrastructure Platform (CIP) (for 43 months)
• Gold sponsors:
  • Roche Diagnostics International AG (for 86 months)
  • Linode (for 80 months)
  • Babiel GmbH (for 69 months)
  • Plat Home (for 68 months)
  • University of Oxford (for 25 months)
  • Deveryware (for 12 months)
  • VyOS
• Silver sponsors:
  • The Positive Internet Company (for 91 months)
  • Domeneshop AS (for 90 months)
  • Nantes M tropole (for 84 months)
  • Univention GmbH (for 76 months)
  • Universit Jean Monnet de St Etienne (for 76 months)
  • Ribbon Communications, Inc. (for 70 months)
  • Exonet B.V. (for 59 months)
  • Leibniz Rechenzentrum (for 54 months)
  • CINECA (for 43 months)
  • Minist re de l Europe et des Affaires trang res (for 37 months)
  • Cloudways Ltd (for 26 months)
  • Dinahosting SL (for 24 months)
  • Platform.sh (for 19 months)
  • Bauer Xcel Media Deutschland KG (for 18 months)
  • Moxa Intelligence Co., Ltd. (for 13 months)
  • sipgate GmbH (for 10 months)
  • OVH US LLC (for 8 months)
  • Tilburg University (for 8 months)
• Bronze sponsors:
  • Evolix (for 91 months)
  • Seznam.cz, a.s. (for 91 months)
  • Linuxhotel GmbH (for 88 months)
  • Intevation GmbH (for 87 months)
  • Daevel SARL (for 86 months)
  • Bitfolk LTD (for 85 months)
  • Megaspace Internet Services GmbH (for 85 months)
  • Greenbone Networks GmbH (for 84 months)
  • NUMLOG (for 84 months)
  • WinGo AG (for 83 months)
  • Ecole Centrale de Nantes LHEEA (for 80 months)
  • Entr ouvert (for 75 months)
  • Adfinis AG (for 72 months)
  • Laboratoire LEGI UMR 5519 / CNRS (for 67 months)
  • Tesorion (for 67 months)
  • GNI MEDIA (for 66 months)
  • Bearstech (for 58 months)
  • LiHAS (for 58 months)
  • People Doc (for 54 months)
  • Catalyst IT Ltd (for 53 months)
  • Supagro (for 48 months)
  • Demarcq SAS (for 47 months)
  • Universit Grenoble Alpes (for 33 months)
  • TouchWeb SAS (for 25 months)
  • SPiN AG (for 21 months)
  • CoreFiling (for 17 months)
  • Institut des sciences cognitives Marc Jeannerod (for 12 months)
  • Observatoire des Sciences de l Univers de Grenoble (for 8 months)
  • Tem Innovations GmbH (for 3 months)
  • WordFinder.pro (for 3 months)
  • CNRS DT INSU R sif

Another (minor) nanotime release, now at version 0.3.5, just arrived at CRAN. It follows the updates RDieHarder 0.2.3 and RcppCCTZ 0.2.10 earlier today in bringing a patch kindly prepared by Tomas Kalibera for the upcoming (and very useful) UCRT changes for Windows involving small build changes for the updated Windows toolchain. nanotime relies on the RcppCCTZ package for (efficient) high(er) resolution time parsing and formatting up to nanosecond resolution, and the bit64 package for the actual integer64 arithmetic. Initially implemented using the S3 system, it has benefitted greatly from a rigorous refactoring by Leonardo who not only rejigged nanotime internals in S4 but also added new S4 types for periods, intervals and durations. The NEWS snippet adds more details.

Changes in version 0.3.5 (2021-12-14)

• Applied patch by Tomas Kalibera for Windows UCRT under the upcoming R 4.2.0 expected for April.

Thanks to my CRANberries there is also a diff to the previous version. More details and examples are at the nanotime page; code, issue tickets etc at the GitHub repository. If you like this or other open-source work I do, you can now sponsor me at GitHub.

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

A new release 0.2.10 of RcppCCTZ is now on CRAN. RcppCCTZ uses Rcpp to bring CCTZ to R. CCTZ is a C++ library for translating between absolute and civil times using the rules of a time zone. In fact, it is two libraries. One for dealing with civil time: human-readable dates and times, and one for converting between between absolute and civil times via time zones. And while CCTZ is made by Google(rs), it is not an official Google product. The RcppCCTZ page has a few usage examples and details. This package was the first CRAN package to use CCTZ; by now four others packages include its sources too. Not ideal, but beyond our control. This version switches to r-ci, and just like RDieHarder includes a patch kindly prepared by Tomas Kalibera for the upcoming (and very useful) UCRT changes for Windows involving small build changes for the updated Windows toolchain.

Changes in version 0.2.10 (2021-12-14)

• Switch CI use to r-ci
• Applied patch by Tomas Kalibera for Windows UCRT under the upcoming R 4.2.0 expected for April.

We also have a diff to the previous version thanks to my CRANberries. More details are at the RcppCCTZ page; code, issue tickets etc at the GitHub repository. If you like this or other open-source work I do, you can now sponsor me at GitHub.

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

An new version 0.2.3 of the random-number generator tester RDieHarder (based on the DieHarder suite developed / maintained by Robert Brown with contributions by David Bauer and myself) is now on CRAN. This release comes only about one and half months after the previous release 0.2.2 and is once again related to R and CRAN changes. The upcoming (and very useful) UCRT changes for Windows involve small build changes for the updated Windows toolchain so this release includes a patch kindly prepared by Tomas Kalibera. And because compilers get cleverer and cleverer over time, I also address a warning and error found by the newest gcc in what is otherwise unchanged and years old C code In addition, two other warnings were fixed right after the previous release. Thanks to CRANberries, you can also look at the most recent diff. If you like this or other open-source work I do, you can now sponsor me at GitHub.

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