Planet Debian

Subscribe to Planet Debian feed
Planet Debian -
Updated: 1 hour 43 min ago

Bits from Debian: Debian celebrates our 28th Anniversary!

16 August, 2021 - 16:01

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.

Russ Allbery: Review: The Galaxy, and the Ground Within

16 August, 2021 - 09:21

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

Dirk Eddelbuettel: RcppBDT 0.2.4 on CRAN: Updates

16 August, 2021 - 05:20

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 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 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.

Sean Whitton: Post hoc apt-listchanges

16 August, 2021 - 04:55

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 -MIO::Zlib -MDpkg::Changelog::Debian -wE'$parser = Dpkg::Changelog::Debian->new; for (</usr/share/doc/*/NEWS.Debian*>) { $parser->parse(IO::Zlib->new($_, "rb")); $_->get_timepiece && $_->get_timepiece->year < 2020 ? last : say for $parser->@* }' 2>&1 | mail -s"News for $(hostname)"

Steinar H. Gunderson: Baseus 65W USB charger

15 August, 2021 - 21:15

There's an evolution in charger technology going on right now; gallium nitride (GaN) technology promises smaller and more efficient chargers than the older all-silicon designs. I was curious at whether it was actually good or not, so after a recommendation, I bought a Baseus Pro 65W charger off AliExpress.

Now, high-voltage stuff is normally the last thing you should be buying from unknown Chinese brands, but the Baseus charger is actually CE-marked (and no, not the dodgy “China Export” version), and there's a Chargerlab teardown that seems to indicate it's of good quality all over, so I'm much less worried about it catching fire or otherwise doing dodgy stuff to my devices. But you should keep this in mind with charger technology in general; not to mention that the PSU is the last place you should try to save money when building a PC.

The charger is, as promised, fairly small and light; it's not tiny, but it's about half the size of e.g. my Lenovo 65W USB-C charger, and has three ports (two USB-C and one USB-A). I'd actually love for it to have another USB-A port, since most of the devices I have still are USB-A, but for that, you'd seemingly need to get the larger 100W version.

USB power delivery is a complex topic; you can get 5W right off the bat, but more than that, and you'd need to negotiate through the actual data pins, not to mention a cable that contains the proper resistors and such to mark how much it's designed to carry. The Baseus supports a bazillion proprietary USB fast charge protocols (different for USB-C and USB-A, of course), and seems to even charge my old CX405 camcorder (I've never seen anything except the included Sony USB charger actually do this—it would accept running on other power sources, but refuse to charge). Another tricky detail is that while the charger can deliver 65W in total, each port can ask for more than 65W in sum. This leads to strange situations where, if I have my laptop plugged in and then plug my phone into another port, the laptop will lose power briefly, then the phone will get power, then the laptop will come back, the phone will lose power again but then regain it, and so on maybe two or three times until everything converges. (My best guess here is that it gives the entire 65W to the laptop and has to unplug it to be able to give the phone the 5W for the initial talking, and then the dance starts again when the phone asks for more power for quick charging?)

Getting good USB cables is becoming a huge headache. USB-C is actually a bunch of different standards that happen to share the same plug, and it's hard to know what can transport what. Since the charger is a wall-wart (so there's zero extension cable on the AC side), it means you will probably need a fairly long cable to use it comfortably with a laptop. There's a 1m cable included that is fairly nice, but for me, a 3m cable is really a necessity. I would have loved to get one that could also double as USB 3.2, but it seems that it really expensive (think €150 or so). It seems to me like the newer USB/Thunderbolt standards are simply way too ambitious; you're trying to squeeze 40 Gbit/sec and 100 W of power through a tiny plug with all sorts of backwards compatibility demands, and that makes for hugely expensive cables. (Also, there's a lot of crap out there that's poorly designed and/or dangerous; Beson Leung of the Google Pixel team used to test standard conformance for cables and chargers, but evidently, he doesn't anymore, and is gone and not really available from I settled for these Amazon-branded cables; buying a 5-pack in a group-buy, they were very affordable, and they've got a positive review from Benson, but they're somewhat inflexible and can only transport USB 2.0 (480 Mbit/sec). (Also, they're nine feet and not three meters, and even without remembering that, I literally said to myself “hm, I wish this cable was 30 centimeters longer”!) I'm very glad I don't need a long cable that can power an external display and also transport the display signal!

So, overall, it's a really neat device. I instantly find myself wishing all of my small electrical appliances (e.g. my electric toothbrush) were USB-chargable, so I could just bring one or two of these and no other chargers. The only reason now to bring more than one charger when traveling feels like redundancy, and I know a few people who would roll their eyes at even thinking about that. :-)

Mike Gabriel: Chromium Policies Managed under Linux

15 August, 2021 - 17:09

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:

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:

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:

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:

First-Run Preferences

It seems, not every setting can be tweaked via a Chromium policy. Esp. the first-run preferences are affected by this:

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=[ "", "" ]' |
    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
        echo "WARNING (chromium tweaks): The file /etc/chromium/master_preferences.adapted was empty after tweaking."
        echo "                           Leaving /etc/chromium/master_preferences untouched."

The list of available (first-run and other) initial preferences can be found in Chromium's code file:

List of Available Chromium Policies

The list of available Chromium policies used to be maintained in the Chromium wiki:

However, that page these days redirects to the Google Chrome Enterprise documentation:

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": ""

And for defining a custome 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",
  "DefaultSearchProviderIconURL": "",
  "DefaultSearchProviderEncodings": ["UTF-8"],
  "DefaultSearchProviderSearchURL": "{searchTerms}",
  "DefaultSearchProviderSuggestURL": "{searchTerms}&type=list",
  "DefaultSearchProviderNewTabURL": ""
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.

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 IRC, [matrix], Mastodon, E-Mail at, etc.). Looking forward to hearing from you. Thanks!

Mike Gabriel (aka sunweaver)

Andy Simpkins: Debian Bullseye Released

15 August, 2021 - 04:46

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

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.

Andrew Cater: Vanilla Debian on a Raspberry Pi 4 with UEFI

15 August, 2021 - 04:39

Thanks to the good folk who put the hard work into building a UEFI implementation for the Raspberry Pi 4 which "just works", allowing you to install Debian straightforwardly, and especially to Pete Batard who has written up the process and collected a zip file together. 

Not quite so straightforward ...

I have an early model Raspberry Pi 4. I wanted to install Debian on an SSD  connected via a cable to a USB3 port. It turned out that the version of the software in the EEPROM would not boot reliably so the first task was to update this with the latest stable EEPROM available from the Raspberry Pi downloads.

The easiest way to do this was to boot an SD card with Raspbian on. Once that was done, I had a Pi that would boot from an SSD.

Untar the files

A tarball of UEFI from Pete's Github repository at - latest is v 1.29 as at 20210814.

Plugging in the SSD to another machine to format the drive: msdos format, one ESP partition in FAT32 and marked bootable and the rest of the drive blank.

One aarch64 DVD image from the usual place. 

Untar the UEFI  tarball into the ESP partition you've just made

 Plug the SSD into a USB3 port on the RPi using a USB -> SATA cable

Write the aarch image to a USB stick using dd and place that into one of the other USB ports. Add a keyboard.


Power up the RPi4, hit Esc and work your way through UEFI to select a boot device and go, save the settings and go.

The install is almost identical to any Debian d-i install.

There is a setting in UEFI to reclaim the 1G of memory that was masked out, there's a setting for control of the fan shim if you have that style of fan.

End result - happiness

Done the other day and sitting next to me on the desktop.


Bits from Debian: Debian 11 "bullseye" has been released!

15 August, 2021 - 04:30

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!

Andrew Cater: And we're almost there with media testing - 202108142013

15 August, 2021 - 03:13

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.

Andrew Cater: Still chasing through release testing Debian media for Bullseye release 202108141655

15 August, 2021 - 00:00

 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.

Andrew Cater: Bullseye - Centre of release is going on.

14 August, 2021 - 20:39

 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.

Hope all's going well with everyone

Dirk Eddelbuettel: RApiDatetime 0.0.5 (and 0.0.6): Updated (Twice)

14 August, 2021 - 19:52

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

  • 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.

Andy Simpkins: Bullseye release – part 1

14 August, 2021 - 18:36

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


We expect to be at this until the small hours of Sunday morning…

watching the build progress, awaiting images to test

Clint Adams: upgrayedd

14 August, 2021 - 18:27


When you upgrade to bullseye, you need to change your security source from

deb buster/updates main


deb bullseye-security main

However, that will silently fail to work if you forget to update the file in /etc/apt/preferences.d to add something like this stanza:

Explanation: Debian security
Package: *
Pin: release o=Debian,n=bullseye-security
Pin-Priority: 990
Posted on 2021-08-14 Tags: quanks

Gunnar Wolf: Bullseye arrives. Private ARM64 install fest!

14 August, 2021 - 11:20

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.
  • 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.
  • 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.

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/

Patryk Cisek: How does Google Authenticator work? (Part 3)

13 August, 2021 - 22:30
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.

Junichi Uekawa: openvpn client configuration with systemd.

13 August, 2021 - 15:54
openvpn client configuration with systemd. Spent a while trying to figure out why my configuration file /etc/openvpn does not take effect. It was because I needed to tell systemd to reload the daemon stuff and trying to restart openvpn only did not have any meaningful effect. After I learnt how things work it made some sense, but I expected /etc/init.d/openvpn restart to do the right thing.

Leandro Doctors: Clojure CLI Tools in Debian - GSoC 2021 Partial Evaluation Report

13 August, 2021 - 10:00

NOTE: this blog post is based on my "Clojure CLI Tools in Debian" GSoC 2021 project Partial Evaluation Report.

Hi, everybody!

For those who don't know me, my name is Leandro Doctors (allentiak on IRC), and I'm the Debian Clojure Team's GSoC 2021 intern. My mentor is Louis-Philippe Véronneau[*] (pollo on IRC). My co-mentor is Utkarsh Gupta (utkarsh2102 on IRC). My 'no-mentor' :) is Elana Hashman (ehashman on IRC).

In this message, I will summarize what I've been up to during the Coding I period (June 7th - July 16th).

TL;DR: my updated data-xml-clojure package was accepted[1] in experimental on Wednesday night :-)


Now, let's tell the full story.

During the first days of the "Coding I" phase, I did some research on the clj dependencies. And after the precious feedback from Louis-Philippe, Elana, Utkarsh, and Alex Miller (the upstream developer of clj, among many other libraries), I came up with the following packaging strategy.

  1. update org.clojure:data.xml (data-xml-clojure) to 0.2.0-beta6.
  2. package org.clojure:tools.gitlibs (tools-gitlibs-clojure).
  3. consider updating libjsch-agent-proxy-java, jgit, libtools-cli-clojure (all of them already in Debian).
  4. consider packaging* packages.

According to my original proposal, I should have completed all four tasks during Coding I. Looking back, the main lesson from these past weeks is a known classic: my timeline was too optimistic: I definitely underestimated the difficulty of the packaging process. Out of the four tasks, I only finished the first one.

There were many challenges I had to overcome in order to update the library from version 0.0.8 to 0.2.0-alpha6:

This what I did:

First, I patched the source code so:

    • we avoid needlessly packaging data-codec-clojure (not currently in Debian).
    • we can ignore Clojure-Script-related dependencies.

Then, I completely overhauled the packaging code (this is, what goes inside debian/).

    • added support for automatically tracking newer releases.
    • the package now builds with Leiningen, instead of plain Java.
    • it now actually supports autopkgtest (the existing test was trivial).

All this improved the quality of the package.

I also improved the Clojure Packaging Tutorial[2] to make the process easier to follow.


Looking back, it is almost as if I had started packaging the library from scratch...

But, more that what I produced, I think the most important part of all this is what I learned during these weeks.

As it was the first time I ever packaged anything in Debian, I had to learn the basics, bump by bump. (And, oh my, I surely did bump quite a few times!)

    • Basic packaging workflow.
    • Setup sbuild[3] to make it work with gbp[4] (when I had rebuilt bidi-clojure from scratch, I had used plain sbuild.)
    • Learn how to patch upstream files with quilt[5] (actually, via the dquilt frontend). This was the first really difficult task to do, since it took me quite some time to grasp it. Looking back, I think I was simply scared of breaking something :)
    • Understanding debian/ files.
    • Understanding debian/tests (autopkgtest) files. This was particularly difficult, since the doc wasn't clear about it. So I then improved the Clojure Packaging Tutorial[2] to make the process easier to follow.





Definitely, all this was worth it. After all, my updated data-xml-clojure package was accepted[1] in experimental on Wednesday :-)


Now that I've learned the basics of packaging bumped enough to get my package accepted, I'm hopeful I can ramp up and catch up with (at least most of) my original schedule during Coding II.

tools-gitlibs-clojure, you're next :-)

Thank you very much Louis-Philippe, Elana, and Utkarsh (plus a special mention to Alex) for your precious support during the last few weeks!


Creative Commons License ลิขสิทธิ์ของบทความเป็นของเจ้าของบทความแต่ละชิ้น
ผลงานนี้ ใช้สัญญาอนุญาตของครีเอทีฟคอมมอนส์แบบ แสดงที่มา-อนุญาตแบบเดียวกัน 3.0 ที่ยังไม่ได้ปรับแก้