Bullseye has been released, and we are in the post-release rush with lots of changes going on. On the KDE/Plasma side we are trying to move all our accumulated changes to unstable. On the OSC side, frameworks 5.85 and KDE Gears 21.08.0 have been released. Debian Bullseye As mentioned previously, the now released Debian/Bullseye contains KDE Frameworks 5.78, including several backports of fixes from 5.79 to get smooth operation. Plasma 5.20.5, again with several cherry picks for bugs will be in Bullseye, too. The KDE/Apps are mostly at 20.12 level, and the KDE PIM group packages (akonadi, kmail, etc) are at 20.08. Debian unstable (and in time also testing) Frameworks 5.83 and Plasma 5.21.5 have been uploaded to unstable. This is a temporary measure until several necessary packages have cleared the NEW queue. After that we will upload frameworks 5.85 and Plasma 5.22.N. KDE Gears is still at 20.08, but we have 21.04 in experimental, and I am currently preparing to upload 21.08.0, should be done soon. OBS packages The OBS packages as usual follow the latest release, and currently ship KDE Frameworks 5.85, KDE Gears 21.08.0, and Plasma 5.22.4. The package sources are as usual (note the different path for the Plasma packages and the apps packages, containing the release version!), for Debian/unstable:

deb https://download.opensuse.org/repositories/home:/npreining:/debian-kde:/frameworks/Debian_Unstable/ ./
deb https://download.opensuse.org/repositories/home:/npreining:/debian-kde:/plasma522/Debian_Unstable/ ./
deb https://download.opensuse.org/repositories/home:/npreining:/debian-kde:/apps2108/Debian_Unstable/ ./
deb https://download.opensuse.org/repositories/home:/npreining:/debian-kde:/other/Debian_Unstable/ ./

and the same with Testing instead of Unstable for Debian/testing. OBS for bullseye For now, use the Testing packages with the addition dependencies:

deb https://download.opensuse.org/repositories/home:/npreining:/debian-kde:/other-deps/Debian_Testing/ ./
deb https://download.opensuse.org/repositories/home:/npreining:/debian-kde:/frameworks/Debian_Testing/ ./
deb https://download.opensuse.org/repositories/home:/npreining:/debian-kde:/plasma522/Debian_Testing/ ./
deb https://download.opensuse.org/repositories/home:/npreining:/debian-kde:/apps2108/Debian_Testing/ ./
deb https://download.opensuse.org/repositories/home:/npreining:/debian-kde:/other/Debian_Testing/ ./

Sooner or later OBS will offer Debian Bullseye as proper target, and then I will prepare releases for it and write another blog post. Closing Expect continued breakage of the next weeks until the upload storm subsides a bit.

Summary I have just tagged nailing-cargo/1.0.0. nailing-cargo is a wrapper around the Rust build tool cargo. nailing-cargo can:

• Work around cargo's problem with totally unpublished local crates (by temporally massaging your Cargo.toml)
• Make it easier to work in Rust without giving the Rust environment (and every author of every one of your dependencies!) control of your main account. (Privsep, with linkfarming where needed.)
• Tweak a few defaults.

Background and history It's not really possible to make a nontrivial Rust project without using cargo. But the build process automatically downloads and executes code from crates.io, which is a minimally-curated repository. I didn't want to expose my main account to that. And, at the time, I was working on a project which for which I was also writing a library as a dependency, and I found that cargo couldn't cope with this unless I were to commit (to my git repository) the path (on my local laptop) of my dependency. I filed some bugs, including about the unpublished crate problem. But also, I was stubborn enough to try to find a workaround that didn't involve committing junk to my git history. The result was a short but horrific shell script. I wrote about this at the time (March 2019). Over the last few years the difficulties I have with cargo have remained un-resolved. I found my interactions with upstream rather discouraging. It didn't seem like I would get anywhere by trying to help improve cargo to better support my needs. So instead I have gradually improved nailing-cargo. It is now a Perl script. It is rather less horrific, and has proper documentation (sorry, JS needed because GitLab). Why Perl ? Rust would have been my language of choice. But I wanted to avoid a chicken-and-egg situation. When you're doing privsep, nailing-cargo has to run in your more privileged environment. I wanted something easy to get going with. nailing-cargo has to contain a TOML parser; and I found a small one, TOML-Tiny, which was good enough as a starting point, and small enough I could bundle it as a git subtree. Perl is nicely fast to start up (nailing-cargo --- true runs in about 170ms on my laptop), and it is easy to write a Perl script that will work on pretty much any Perl installation. Still unsolved: embedding cargo in another build system A number of my projects contain a mixture of Rust code with other languages. Unfortunately, nailing-cargo doesn't help with the problems which arise trying to integrate cargo into another build system. I generally resort to find runes for finding Rust source files that might influence cargo, and stamp files for seeing if I have run it recently enough; and I simply live with the fact that cargo sometimes builds more stuff than I needed it to. Future There are a number of ways nailing-cargo could be improved. Notably, the need to overwrite your actual Cargo.toml is very annoying, even if nailing-cargo puts it back afterwards. A big problem with this is that it means that nailing-cargo has to take a lock, while your cargo rune runs. This effectively prevents using nailing-cargo with long-running processes. Notably, editor integrations like rls and racer. I could perhaps solve this with more linkfarm-juggling, but that wouldn't help in-tree builds and it's hard to keep things up to date. I am considering using LD_PRELOAD trickery or maybe bwrap(1) to "implement" the alternative Cargo.toml feature which was rejected by cargo upstream in 2019 (and again in April when someone else asked). Currently there is no support for using sudo for out-of-tree privsep. This should be easy to add but it needs someone who uses sudo to want it (and to test it!) The documentation has some other dicusssion of limitations, some of which aren't too hard to improve. Patches welcome!

comments

Review: Black Sun, by Rebecca Roanhorse

Series:	Between Earth and Sky #1
Publisher:	Saga Press
Copyright:	October 2020
ISBN:	1-5344-3769-X
Format:	Kindle
Pages:	454

Serapio has been crafted and trained to be the vessel for a god. He grew up in Obregi land, far from his ancestral home, but he will return to Tova at the appropriate time and carry the hopes of the Carrion Crow clan with him. Xiala is a ship captain, a woman, and a Teek. That means she's a target. Teek have magic, which makes them uncanny and dangerous. They're also said to carry that magic in their bones, which makes them valuable in ways that are not pleasant for the Teek. Running afoul of the moral codes of Cuecola is therefore even more dangerous to her than it would be to others, which is why she accepts a bargain to run errands for a local lord for twelve years, paid at the end of that time with ownership of a ship and crew. The first task: ferry a strange man to the city of Tova. Meanwhile, in Tova, the priestess Naranpa has clawed her way to the top of the Sky Made hierarchy from an inauspicious beginning in the poor district of Coyote's Maw. She's ruthlessly separated herself from her despised beginnings and focused her attention on calming Tova in advance of the convergence, a rare astronomical alignment at the same time as the winter solstice. But Carrion Crow holds a deep-seated grudge at their slaughter by the priesthood during the Night of Knives, and Naranpa's position atop the religious order that partly rules Tova's fractious politics is more precarious than she thinks. I am delighted that more fantasy is drawing on mythologies and histories other than the genre default of western European. It's long overdue for numerous reasons and a trend to be rewarded. But do authors writing fantasy in English who reach for Mesoamerican cultures have to gleefully embrace the excuse to add more torture? I'm developing an aversion to this setting (which I do not want to do!) because every book seems to feature human sacrifice, dismemberment, or some other horror show. Roanhorse at least does not fill the book with that (there's lingering child abuse but nothing as sickening as the first chapter), but that makes the authorial choice to make the torture one's first impression of this book even odder. Our introduction to Serapio is a scene that I would have preferred to have never read, and I don't think it even adds much to the plot. Huge warnings for people who don't want to read about a mother torturing her son, or about eyes in that context. Once past that introduction, Black Sun settles into a two-thread fantasy, one following Xiala and Serapio's sea voyage and the other following Naranpa and the political machinations in Tova. Both the magic systems and the political systems are different enough to be refreshing, and there are a few bits of world-building I enjoyed (a city built on top of rocks separated by deep canyons and connected with bridges, giant intelligent riding crows, everything about the Teek). My problem was that I didn't care what happened to any of the characters. Naranpa spends most of the book dithering and whining despite a backstory that should have promised more dynamic and decisive responses. The other character from Tova introduced somewhat later in the book is clearly "character whose story will appear in the next volume"; here, he's just station-keeping and representing the status quo. And while it's realistic given the plot that Serapio is an abused sociopath, that didn't mean I enjoyed reading his viewpoint or his childhood abuse. Xiala is the best character in the book by far and I was warming to the careful work she has to do to win over an unknown crew, but apparently Roanhorse was not interested in that. Instead, the focus of Xiala's characterization turns to a bad-boy romance that did absolutely nothing for me. This will be a matter of personal taste; I know this is a plot feature for many readers. But it had me rolling my eyes and turning the pages to get to something more interesting (which, sadly, was not forthcoming). It also plays heavily on magical disabled person cliches, like the blind man being the best fighter anyone has met. I did not enjoy this book very much, but there were some neat bits of world-building and I could see why other people might disagree. What pushed me into actively recommending against it (at least for now) is the publishing structure. This is the first book of a trilogy, so one can expect the major plot to not be resolved by the end of the book. But part of the contract with the reader when publishing a book series is that each volume should reach some sense of closure and catharsis. There will be cliffhangers and unanswered questions, but there should also be enough plot lines that are satisfactorily resolved to warrant publishing a book as a separate novel. There is none of that here. This is the first half (or third) of a novel. It introduces a bunch of plot lines, pulls them together, describes an intermediate crisis, and then simply stops. Not a single plot line is resolved. This is made worse by the fact this series (presumably, as I have only seen the first book) has a U-shaped plot: everything gets worse and worse until some point of crisis, and then presumably the protagonists will get their shit together and things will start to improve. I have soured on U-shaped plots since the first half of the story often feels like a tedious grind (eat your vegetables and then you can have dessert), but it's made much worse by cutting the book off at the bottom of the U. You get a volume, like Black Sun, that's all setup and horror and collapse, with no payoff or optimism. After two tries, I have concluded that Roanhorse is not for me. This is clearly a me problem rather than a Roanhorse problem, given how many other people love both Black Sun and her Sixth World series, but this is the second book of hers where I mildly enjoyed the world building but didn't care about any of the characters. Ah well, tastes will differ. Even if you get along with Roanhorse, though, I recommend against starting this book until the second half of it is published (currently scheduled for 2022). As it stands, it's a wholly unsatisfying reading experience. Followed by the not-yet-published Fevered Star. Rating: 4 out of 10

28 today. In a video call for Debian day earlier on, I was reminiscing about the earliest distributions: MCC Interim Linux gave instructions to turn it's final version into Debian. Debian is the second oldest Linux distribution, just behind Slackware.Debian 1.2 was my first Debian: my latest is, obviously, Debian Bullseye. Debian is like a family - often discordant, sometimes dysfunctional but always full of people that care and are cared for. I wish that some of my friends and colleagues no longer with us could be here to see just how well we're doing.This is something that's been with me for so long that I can't imagine life without it: software, obscure hardware but above all friends closer than family. The biggest software project anywhere, potentially, and it's all for free - and 95.7% independently reproducible. Thanks to all my colleagues and co-workers who've become friends over the years without whom none of this would be possible. Oh, and thanks to Ian Murdock - I never got to meet him but I did get to email him when he was in charge of Progeny. Without him, none of this would even have started.

Today is Debian's 28th anniversary. We send all of our gratitude and love to the many Contributors, Developers, and Users who have helped this vision and project. There are many celebrations of #DebianDay happening around the world, perhaps one is local to you? Later this month the celebration continues with #DebConf21 which will be held Online during August 24 through August 28, 2021.

Review: The Galaxy, and the Ground Within, by Becky Chambers

Series:	Wayfarers #4
Publisher:	Harper Voyager
Copyright:	April 2021
ISBN:	0-06-293605-0
Format:	Kindle
Pages:	325

The name of the planet Gora is the Hanto word for useless. It's a bone-dry, resource-poor planet with nothing to recommend it except that it happened to be conveniently located between five other busy systems and had well-established interspacial tunnels. Gora is therefore a transit hub: a place lots of people visit for about half a day while waiting for a departure time, but where very few people stay. It is the interstellar equivalent of an airport. Ouloo is a Laru, a species physically somewhat similar to a giant dog. She is the owner of the Five-Hop One-Stop in a habitat dome on Gora, where she lives with her child (who is not yet old enough to choose a gender). On the day when this novel begins, she's expecting three ships to dock: one Aeluon, one Quelin, and, to Ouloo's significant surprise and moderate discomfort, an Akarak. But apart from that, it's a normal day. A normal day, that is, until maintenance work on the solar satellite array leads to a Kessler syndrome collision cascade that destroys most of the communication satellites and makes it unsafe to leave the surface of the planet. Ouloo and her guests are stuck with each other for longer than they expected. In a typical SF novel, you would expect the characters to have to fix the satellite cascade, or for it to be a sign of something more nefarious. That is not the case here; the problem is handled by the Goran authorities, the characters have no special expertise, and there is no larger significance to the accident. Instead, the accident functions as storm in a very old story-telling frame: three travelers and their host and her child, trapped together by circumstance and forced to entertain each other until they can go on their way. Breaking from the formula, they do not do that primarily by telling stories to each other, although the close third-person narration that moves between the characters reveals their backgrounds over the course of the book. Instead, a lot of this book is conversation, sometimes prompted by Ouloo's kid Tupo (who I thought was a wonderfully-written tween, complete with swings between curiosity and shyness, random interests, occasionally poor impulse control, and intense but unpredictable learning interest). That leads to some conflict (and some emergencies), but, similar to Record of a Spaceborn Few, this is more of a character study book than a things-happen book. An interesting question, then, is why is this story science fiction? A similar story could be written (and has been, many times) with human travelers in a mundane inn or boarding house in a storm. None of the aliens are all that alien; despite having different body shapes and senses, you could get more variation from a group of university students. And even more than with Chambers's other books, the advanced technology is not the point and is described only enough to provide some background color and a bit of characterization. The answer, for me, is that the cognitive estrangement of non-human characters relieves my brain of the baggage that I bring to human characters and makes it easier for me to empathize with the characters as individuals rather than representatives of human archetypes. With human characters, I would be fitting them into my knowledge of history and politics, and my reaction to each decision the characters make would be influenced by the assumptions prompted by that background. I enjoy the distraction of invented worlds and invented histories in part because they're simplified compared to human histories and therefore feel more knowable and less subtle. I'm not trying to understand the political angle from which the author is writing or wondering if I'm missing a reference that's important to the story. In other words, the science fiction setting gives the narrator more power. The story tells me the important details of the background; there isn't some true history lurking beneath that I'm trying to ferret out. When that's combined with interesting physical differences, I find myself imagining what it would be like to be the various aliens, trying to insert myself into their worlds, rather than placing them in a historical or political context. That puts me in a curious and empathetic mindset, and that, in turn, is the best perspective from which to enjoy Chambers's stories. The characters in this story don't solve any large-scale problems. They do make life decisions, some quite significant, but only on a personal scale. They also don't resolve all of their suspicions and disagreements. This won't be to everyone's taste, but it's one of the things I most enjoyed about the book: it shows a small part of the lives of a collection of average individuals, none of whom are close to the levers of power and none of whom are responsible for fixing their species or galactic politics. They are responsible for their own choices, and for how their lives touch the lives of others. They can make the people they encounter happier or sadder, they can chose how to be true to their own principles, and they can make hard choices without right answers. When I describe a mainstream fiction book that way, I often find it depressing, but I came away from The Galaxy, and the Ground Within feeling better about the world and more open-hearted towards other people. I'm not sure what Chambers does to produce that reaction, so I'm not sure if it will have the same effect on other people. Perhaps part of it is that while there is some drama, her characters do not seek drama for its own sake, none of the characters are villains, and she has a way of writing sincerity that clicks with my brain. There is a scene, about two-thirds of the way through the book, where the characters get into a heated argument about politics, and for me this is the moment where you will either love this book or it will not work for you. The argument doesn't resolve anything, and yet it's one of the most perceptive, accurate, and satisfying portrayals of a political argument among normal people that I've seen in fiction. It's the sort of air-clearing conversation in which every character is blunt with both their opinion and their emotions rather than shading them for politeness. Those positions are not necessarily sophisticated or deeply philosophical, but they are deeply honest.

"And you know what? I truly don't care which of them is right so long as it fixes everything. I don't have an... an ideology. I don't know the right terms to discuss these things. I don't know the science behind any of it. I'm sure I sound silly right now. But I just want everyone to get along, and to be well taken care of. That's it. I want everybody to be happy and I do not care how we get there." She exhaled, her broad nostrils flaring. "That's how I feel about it."

I am not Ouloo, but I think she represents far more people than fiction normally realizes, and I found something deeply satisfying and revealing in seeing that position presented so clearly in the midst of a heated argument. If you like what Chambers does, I think you will like this book. If it's not for you, this is probably not the book that will change your mind, although there is a bit less hand-wavy technology to distract the people whom that distracts. The Galaxy, and the Ground Within didn't have the emotional resonance that Record of a Spaceborn Few had for me, or the emotional gut punch of A Closed and Common Orbit. But I loved every moment of reading it. This will apparently be the last novel in the Wayfarers universe, at least for the time being. Chambers will be moving on to other settings (starting with A Psalm for the Wild-Built). Rating: 8 out of 10

After a seven-year break (!!), the RcppBDT packages has been updated on CRAN. The RcppBDT package is an early adopter of Rcpp and was one of the first packages utilizing Boost and its Date_Time library. The now more widely-used package anytime is a direct descentant of RcppBDT. In fact, the last time RcppBDT was released, anytime did not yet exist. And some of the changes now finally released here in this version are some of the first steps made towards what became anytime. RcppBDT is broader in scope and provides a wider range of functionality but in a somewhat rougher form as we never sat down writing higher-end wrappers in R for all the potential use cases. When we wrote the first RcppBDT versions, many other popular date/time packages were all in R code and not compiled, and this package showed how things could be done at the compiled level. Now other packages, including anytime have filled the void so fully polishing RcppBDT may never happen. In any event, this release refreshes the package and brings it to full R CMD check --as-cran compliance. The NEWS entry follows:

Changes in version 0.2.4 (2021-08-15)

• New utility function toPOSIXct which can take multitple input format (integer, floating point or character) vectors and can convert by relying on a wide variety of standard formats. This predates what has long been split off into a new package anytime which is more functional and feaureful.
• New demo 'toPOSIXct' illustrating the feature.
• New demo 'toPOSIXctTiming' benchmarking it.
• Documentation for new functions was added as well.
• CI now uses run.sh from r-ci.
• Functions getLastDayOfWeekInMonth and getFirstDayOfWeekInMonth now use dow argument.
• The shared library is now registered when loaded from NAMESPACE.
• C level entry points are now registered as R now recommends.
• Several badges were added to the README.md file.
• Several fields were added to the DESCRIPTION file, and/or updated.
• Documentation URLs where both updated as needed and converted to https.

Courtesy of my CRANberries, there is also a diffstat report for this release. 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.

Yesterday I upgraded a machine from Debian buster to bullseye without apt-listchanges installed, oops. Here s a way to get new NEWS.Debian entries after the fact.

perl -MDpkg::Changelog::Debian -wE'$parser = Dpkg::Changelog::Debian->new;
    for (</usr/share/doc/*/NEWS.Debian*>)  
        $parser->load($_);
        $_->get_timepiece && $_->get_timepiece->year < 2020 ? last : say
            for $parser->@*  ' 2>&1   mail -s"News for $(hostname)" you@example.com

For a customer project, I recently needed to take a closer look at best strategies of deploying Chromium settings to thrillions of client machines in a corporate network. Unfortunately, the information on how to deploy site-wide Chromium browser policies are a little scattered over the internet and the intertwining of Chromium preferences and Chromium policies required deeper introspection. Here, I'd like to provide the result of that research, namely a list of references that has been studied before setting up Chromium policies for the customer's proof-of-concept. Difference between Preferences and Policies Chromium can be controlled via preferences (mainly user preferences) and administratively rolled-out policy files. The difference between preferences and policies are explained here:
https://www.chromium.org/administrators/configuring-other-preferences The site-admin (or distro package maintainer) can pre-configure the user's Chromium experience via a master preferences file (/etc/chromium/master_preferences). This master preferences file is the template for the user's preferences file and gets copied over into the Chromium user profile folder on first browser start. Note: By studying the recent Chromium code it was found out that /etc/chromium/master_preferences is the legacy filename of the initial preferences file. The new filename is /etc/chromium/initial_preferences. We will continue with master_preferences here as most Linux distributions still provide the initial preferences via this file. Whereas the new filename is already supported by Chromium in openSUSE/SLES, it is not yet support by Chromium in Debian/Ubuntu. (See Debian bug #992178). Difference of 'managed' and 'recommended' Policies The difference between 'managed' and 'recommended' Chromium policies is explained here:
https://www.chromium.org/administrators/configuring-other-preferences Quoting from above URL (last visited 2021/08): Policies that should be editable by the user are called "recommended policies" and offer a better alternative than the master_preferences file. Their contents can be changed and are respected as long as the user has not modified the value of that preference themselves. So, policies of type 'managed' override user preferences (and also lock them in the Chromium settings UI). Those 'managed' policies are good for enforcing browser settings. They can be blended in also for existing browser user profiles. Policies ('managed' and 'recommended') even get blended it at browser run-time when modified. Use case: e.g. for rolling out browser security settings that are required for enforcing a site-policy-compliant browser user configuration. Policies of type 'recommended' have an impact on setting defaults of the Chromium browser. They apply to already existing browser profiles, if the user hasn't tweaked with the to-be-recommended settings, yet. Also, they get applied at browser run-time. However, if the user has already fiddled with such a to-be-recommended setting via the Chromium settings UI, the user choice takes precedence over the recommended policy. Use case: Policies of type 'recommended' are good for long-term adjustments to browser configuration options. Esp. if users don't touch their browser settings much, 'recommended' policies are a good approach for fine-tuning site-wide browser settings on user machines. CAVEAT: While researching on this topic, two problematic observations were made:

1. All setting parameters put into the master preferences file (/etc/chromium/master_preferences) can't be superceded by 'recommended' Chromium policies. Pre-configured preferences are handled as if the user has already tinkered with those preferences in Chromium's settings UI. It also was discovered, that distributors tend to overload /etc/chromium/master_preferences with their best practice browser settings. Everything that is not required on first browser start should be provided as 'recommended' policies, already in the distribution packages for Chromium .
2. There does not seem to be an elegant way to override the package maintainer's choice of options in /etc/chromium/master_preferences file via some file drop-in replacement. (See Debian bug #992179). So, deploying Chromium involves post-install config file tinkering by hand, by script or by config management tools. There is space for improvement here.

Managing Chromium Policy with Files Chromium supports 'managed' policies and 'recommended' policies. Policies get deployed as JSON files. For Linux, this is explained here:
https://www.chromium.org/administrators/linux-quick-start Note, that for Chromium, the policy files have to be placed into /etc/chromium. The example on the above web page shows where to place them for Google Chrome. Good 'How to Get Started' Documentation for Chromium Policy Setups This overview page provides a good get-started-documentation on how to provision Chromium via policies:
https://www.chromium.org/administrators/configuring-policy-for-extensions First-Run Preferences It seems, not every setting can be tweaked via a Chromium policy. Esp. the first-run preferences are affected by this:
https://www.chromium.org/developers/design-documents/first-run-customiza... So, for tweaking the first-run settings, one needs to adjust /etc/chromium/master_prefences (which is suboptimal, again see Debian bug #992179 for a detailed explanation on why this is suboptimal). The required adjustments to master_preferences can be achieved with the jq command line tool, here is one example:

# Tweak chromium's /etc/chromium/master_preferences file.
# First change: drop everything that can be provisioned via Chromium Policies.
# Rest of the changes: Adjust preferences for new users to our needs for all
# parameters that cannot be provisioned via Chromium Policies.
cat /etc/chromium/master_preferences   \
    jq 'del(.browser.show_home_button, .browser.check_default_browser, .homepage)'  
    jq '.first_run_tabs=[ "https://first-run.example.com/", "https://your-admin-faq.example.com" ]'  
    jq '.default_apps="noinstall"'  
    jq '.credentials_enable_service=false   .credentials_enable_autosignin=false'  
    jq '.search.suggest_enabled=false'  
    jq '.distribution.import_bookmarks=false   .distribution.verbose_logging=false   .distribution.skip_first_run_ui=true'  
    jq '.distribution.create_all_shortcuts=true   .distribution.suppress_first_run_default_browser_prompt=true'  
    cat > /etc/chromium/master_preferences.adapted
if [ -n "/etc/chromium/master_preferences.adapted" ]; then
        mv /etc/chromium/master_preferences.adapted /etc/chromium/master_preferences
else
        echo "WARNING (chromium tweaks): The file /etc/chromium/master_preferences.adapted was empty after tweaking."
        echo "                           Leaving /etc/chromium/master_preferences untouched."
fi

The list of available (first-run and other) initial preferences can be found in Chromium's pref_names.cc code file:
https://github.com/chromium/chromium/blob/main/chrome/common/pref_names.cc List of Available Chromium Policies The list of available Chromium policies used to be maintained in the Chromium wiki: https://www.chromium.org/administrators/policy-list-3 However, that page these days redirects to the Google Chrome Enterprise documentation:
https://chromeenterprise.google/policies/ Each policy variable has its own documentation page there. Please note the "Supported Features" section for each policy item. There, you can see, if the policy supports being placed into "recommended" and/or "managed". This is an example /etc/chromium/policies/managed/50_browser-security.json file (note that all kinds of filenames are allowed, even files without .json suffix):

 
  "HideWebStoreIcon": true,
  "DefaultBrowserSettingEnabled": false,
  "AlternateErrorPagesEnabled": false,
  "AutofillAddressEnabled": false,
  "AutofillCreditCardEnabled": false,
  "NetworkPredictionOptions": 2,
  "SafeBrowsingProtectionLevel": 0,
  "PaymentMethodQueryEnabled": false,
  "BrowserSignin": false,
 

And this is an example /etc/chromium/policies/recommended/50_homepage.json file:

 
  "ShowHomeButton": true,
  "WelcomePageOnOSUpgradeEnabled": false,
  "HomepageLocation": "https://www.example.com"
 

And for defining a custom search provider, I use /etc/chromium/policies/recommended/60_searchprovider.json (here, I recommend not using DuckDuckGo as DefaultSearchProviderName, but some custom name; unfortunately, I did not find a policy parameter that simply selects an already existing search provider name as the default :-( ):

 
  "DefaultSearchProviderEnabled": true,
  "DefaultSearchProviderName": "DuckDuckGo used by Example.com",
  "DefaultSearchProviderIconURL": "https://duckduckgo.com/favicon.ico",
  "DefaultSearchProviderEncodings": ["UTF-8"],
  "DefaultSearchProviderSearchURL": "https://duckduckgo.com/?q= searchTerms ",
  "DefaultSearchProviderSuggestURL": "https://duckduckgo.com/ac/?q= searchTerms &type=list",
  "DefaultSearchProviderNewTabURL": "https://duckduckgo.com/chrome_newtab"
 

The Essence and Recommendations On first startup, Chromium copies /etc/chromium/master_preferences to $HOME/.config/chromium/Default/Preferences. It does this only if the Chromium user profile has'nt been created, yet. So, settings put into master_preferences by the distro and the site or device admin are one-time-shot preferences (new user logs into a device, preferences get applied on first start of Chromium). Chromium policy files, however, get continuously applied at browser runtime. Chromium watches its policy files and you can observe Chromium settings change when policy files get modified. So, for continuously provisioning site-wide settings that mostly always trickle into the user's browser configuration, Chromium policies should definitely be preferred over master_preferences and this should be the approach to take. When using Chromium policies, one needs to take into account that settings in /etc/chromium/master_preferences seem to have precedence over 'recommended' policies. So, settings that you want to deploy as recommended policies must be removed from /etc/chromium/master_preferences. Essentially, these are the recommendations extracted from all the above research and information for deploying Chromium on enterprise scale:

1. Everything that's required at first-run should go into /etc/chromium/master_preferences.
2. Everything that's not required at first-run should be removed from /etc/chromium/master_preferences.
3. Everything that's deployable as a Chromium policy should be deployed as a policy (as you can influence existing browser sessions with that, also long-term)
4. Chromium policy files should be split up into several files. Chromium parses those files in alpha-numerical order. If policies occur more than once, the last policy being parsed takes precedence.

Feedback If you have any feedback or input on this post, I'd be happy to hear it. Please get in touch via the various channels where I am known as sunweaver (OFTC and libera.chat IRC, [matrix], Mastodon, E-Mail at debian.org, etc.). Looking forward to hearing from you. Thanks! light+love
Mike Gabriel (aka sunweaver)

Wow. It is 21:49 in the evening here (I am with isy and sledge in Cambridge) and image testing has completed! The images are being signed, and sledge is running through the final steps to push them out to our servers, and from there out onto the mirror and torrent networks to be available for public download.

We have had help testing installation images from the regular team; amacater and schweer. With schweer, as ever, covering the edu images. Thank you. This release we were joined by bitin who kindly ran through a couple of tests of the default netinst image with both UEFI and BIOS based VMs, before joining a release party. Moving onto the live images, linux-fan once again spent time testing i386 images on vintage hardware. Getting a desktop environment to work on a Pentium (4?) machine with 1GiB RAM from a live-image sees the number of desktops that will run in this environment get fewer all the time. Again highvoltage was around to run tests on some of the images.

liz, contributed for the first time indeed raised her first bug report as well. I hope that you had fun thanks for joining us today. smcv, also joined in the testing fun a long time DD is this the first time you have run through image smoke tests on release day? thanks! Many thanks to everyone taking time to test installation and live images. Of cause building and testing images doesn t happen in isolation. There is a huge team that puts together and releases the project that is Debin .
On a release day there are many teams working flat out: dsa, ftp, publicity, release, web, and ourselves as the cd/images team.
But that is just activity on a release day
There are all the other teams that are needed to produce the distribution, who work tirelessly day in, day out. Curating the 1,152,960,944 lines of code in Debian bullseye are over more than 6,208 people!!
Some of the contributors are shown in https://contributors.debian.org/contributors/flat
THANK YOU In the 15 minutes it has taken me to compile this post (many thanks to cnote and jmw for facts and figures they published on debian micronews), the last of the image release process has completed by sledge and that s it. Installation images for Debian 11 Bullseye are out in the big wide world, joining the official archives that became available at 10:35 this morning.

We're happy to announce the release of Debian 11, codenamed bullseye! Want to install it? Choose your favourite installation media and read the installation manual. You can also use an official cloud image directly on your cloud provider, or try Debian prior to installing it using our "live" images. Already a happy Debian user and you only want to upgrade? You can easily upgrade from your current Debian 10 "buster" installation; please read the release notes. Do you want to celebrate the release? We provide some bullseye artwork that you can share or use as base for your own creations. Follow the conversation about bullseye in social media via the #ReleasingDebianBullseye and #Debian11Bullseye hashtags or join an in-person or online Release Party!

It's been quite a long day - last few normal tests are being run through now.Lots more involvement from more people: nothing too catastrophic and a good many installs run through. The usual back and forth and noticing odd things that crop up: it's always interesting to get someone else's viewpoint and second pair of eyes on something.Thanks also to Schweer who's done his usual solo testing of all the Debian-Edu software, quietly and with no fuss.Looking good.

Lots of people - lots of effort - we're gradually closing in on a last few tests.It's been quite a long time but we're significantly ahead of where we would be on many tests for release candidates and main releases. It's always fun to do and chat back and forth. Having new testers check in from tomorrow (Australia) has also been a novelty.It's been a very long wait for this but "This is the best Debian release ever", as they say.

And so we're building CDs / DVDs and larger images. Lots of people joining us, either to say Hi or to actually add to the tests.All of the most common CDs / DVDs have been tested. Not too many obvious bugs found in our processes this time and tests are going well.Some of the usual suspects but also some new testers: Hi to bittin who dropped in before the Stockholm release party, to smcv and to highvoltage and to liz and Linux-Fan
Hope all's going well with everyone.

After nearly two years, the RApiDatetime package on CRAN has received an update, followed-up a quick bug fix. RApiDatetime provides a number of entry points for C-level functions of the R API for Date and Datetime calculations. The functions asPOSIXlt and asPOSIXct convert between long and compact datetime representation, formatPOSIXlt and Rstrptime convert to and from character strings, and POSIXlt2D and D2POSIXlt convert between Date and POSIXlt datetime. Lastly, asDatePOSIXct converts to a date type. All these functions are rather useful, but were not previously exported by R for C-level use by other packages. Which this package aims to change. This pair of releases updates the code to the current R-devel standard, and refreshes a few standard packaging aspects starting from making builds on the Windows UCRT platform possible. And while making an accomodation for one beloved architecture (in release 0.0.5), we introduced another issue on another almost equally beloved platform which 0.0.6 clears up. It should be ready and stable now.

Changes in RApiDatetime version 0.0.6 (2021-08-13)

• Correctly account for SunOS to have it avoid GMTOFF use
• A new test file was added to ensure NEWS.Rd is always at the current release version.

Changes in RApiDatetime version 0.0.5 (2021-08-05)

• Add a few #nocov tags
• Update continuous integration to use r-ci, reenable coverage
• Update DESCRIPTION with URL and BugReports fields
• Add new CI and LastCommitted badges to README.md
• Add compiler flag for Windows UCRT build
• Synchronized datetime function with upstream r-devel code

Courtesy of my CRANberries, there is are comparisons to the previous release 0.0.5, and 0.0.4, respectively. More information is on the rapidatetime page. For questions or comments please use the issue tracker off the GitHub repo.

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

And so it begins
Release of Debian 11 Bullseye is in progress. Building install media is underway, and we ll be downloading and smoke testing these images just as soon as they become available. Want to help test some images? see https://wiki.debian.org/Teams/DebianCD/ReleaseTesting/Bullseye_r0 We expect to be at this until the small hours of Sunday morning

watching the build progress, awaiting images to test

So today is the day when a new Debian release comes out! Congratulations to everybody, and thanks a lot mainly to the Release Team. Lots of very hard work was put into making Debian 11 Bullseye a reality! My very personal way to celebrate this was to do a somewhat different Debian install at home. Why different? Well, I have quite a bit of old, older and frankly elderly laptops at home. And as many of you know, I have done more than my fair share of Raspberry Pi installs I have played and worked with assorted ARM machines at least since 2013, and I cannot consider myself a newbie with them by any means. But this is the first time I installed Debian on a mass-market, decently-specced ARM64-based laptop. Yes, I know the Pinebook has been there like for ages, but it really does feel like a computer to show off and not to use seriously (and I ve seen probably too many people fiddling with it, unable to get $foo to work). So I got myself a used Lenovo Yoga C630. Yes, a discontinued product it seems Lenovo was not able to properly market this machine, and it had a pretty short shelf life the machine was available for samples in late 2018 and for general sale in 2019! The specs are quite decent:

• Snapdraon SDM850 AArch64 8-core CPU. Runs at frequencies between 300 and 2840 MHz.
• 8GB RAM
• 128GB SSD drive
• FHD (1920x1080) 13 screen
• 1.2Kg weight
• Battery life! The supposed capacity of a brand-new system is 22 hours. I don t expect a second-hand computer to achieve that. But I ve been using the system for ~10hr today without a connection, and it still has 22.5% battery!

Installing it via an almost-standard debian-installer is almost straightforward does require the installer to know what he is doing but is not too different from a regular Debian install. The AArch64 laptops project has done quite a feat in getting a d-i image ready to be inserted as a USB drive, and comprehensive instructions to help through the process. The shipped scripts even reap the Windows partition for the firmware images! I have reduced Windows to 25GB, but having only a 128GB drive, it still is a little bit too much.. I guess I ll blow it away sooner rather than later. The installer image has a regular GNOME install, which works beautifully, but I promptly replaced it with i3, as it s fundamental for me to work happily. Of course, the computer has quirks, more than I d expect from a regular x86 system, but well within what I expected to achieve during my first day with it. The issues I have most noted are:

• No HDMI support via the USB-C displayport. While I don t expect to go to conferences or even classes in the next several months, I hope this can be fixed before I do. It s a potential important issue for me.
• I haven t been able to get the sound working. Steev (thanks a lot for all the info and hardware you sent my way!) prepared a 5.12 kernel package that should result in working sound. It hasn t worked. I haven t really debugged it, of course. Sound now works! I was missing the loading of the relevant DTBs. It was just a matter of running /usr/local/bin/install-dtbs.py /usr/lib/linux-image-5.12.19-custom/ /boot/efi/dtb. And this should remain handy, as I ll have to do so for every new kernel I install (hint, hint: It should be called from /etc/kernel/postinst.d or something like that. I should check and propose a patch!)
• Fingerprint reader. Just a novelty I don t really need; my fingers know how to quickly type a long-ish password. But it s a cool item (-:
• I have seen some seemingly random cases where the trackpad freezes after coming back from suspension. Touchscreen mouse support still works (but, of course, sucks and should be used only for backup). Will definitively look into it.
• There are some cases where i3status panics and dies. i3status is a package as simple as can be, so I ll also definitively try and debug what is going wrong. Switched away from i3status (details follow )
• The video output is quite slow. The default install used Wayland, which gets in the way of many of my needed use cases (mainly, screen grabbing/sharing), so I switched to xserer-xorg; according to the logs, I m using the framebuffer device. Will later see if there is support for the Qualcomm Adreno 630GPU. Still, it manages to run some OpenGL xscreensaver hacks at 30FPS, ~40% load But urxvt is dismally slow. Emilio prompted me to give Wayland a shot, specially in this kind of hardware. While I still have to wrap my head around some of the changes it introduces, I am mostly there. I m using Sway instead of my good ol i3, which I love under X, and it feels very much at home. I have some re-learning to do at the stitches between protocols.

Of course, more quirks will surely appear with use. And I ll start trying to address some of them. So Happy Bullseye! Happy Debian 11! Enjoy a great release! \o/

Part 3 is the last part in this short cycle. Here I ll explain all the details around Time-based One-Time Password algorithm. I ll finish up by also elaborating on things common to both, HMAC-Based One-Time Password algorithm: QR Codes used to easily transfer secrets from the server to the Authenticator app Base32 algorithm used to store non-printable secret in a URI (effectively stored by the QR Codes mentioned above). TOTP One way to avoid the problems with lack of feedback between server and the app would be to shift from using a counter that is increasing with every authentication attempt to a counter based on, for example, a time stamp.