Aug 28, 2021, I gave a short talk about "Latest topics about fabre.debian.net" at DebConf21.
You can see the presentation slide here:
slide.rabbit-shocker.org
Short talk explanation is here:
debconf21.debconf.org
In this talk, I've explained mainly 3 topics
-vcodec copy option is passed to ffmpeg).182. This version includes the following changes:
[ Chris Lamb ]
* Also ignore, for example, spurious "fwGCC: (Debian ... )" lines in output
from strings(1).
* Only use "java -jar /path/to/apksigner.jar" if we have a .jar as newer
versions of apksigner use a shell wrapper script which will obviously be
rejected by the JVM. Also mention in the diff if apksigner is missing.
* Pass "-f" to apktool to avoid creating a strangely-named subdirectory and
to simplify code.
* If we specify a suffix for temporary file or directory, ensure it starts
with a "_" to make the generated filenames more human-readable.
* Drop an unused File import.
* Update the minimum version of the Black source code formatter.
[ Santiago Torres Arias ]
* Support parsing the return value of squashfs versions which discriminate
between fatal and non-fatal errors.
The Debian Janitor is an automated system that commits fixes for (minor) issues in Debian packages that can be fixed by software. It gradually started proposing merges in early December. The first set of changes sent out ran lintian-brush on sid packages maintained in Git. This post is part of a series about the progress of the Janitor. Linux distributions like Debian fulfill an important function in the FOSS ecosystem - they are system integrators that take existing free and open source software projects and adapt them where necessary to work well together. They also make it possible for users to install more software in an easy and consistent way and with some degree of quality control and review. One of the consequences of this model is that the distribution package often lags behind upstream releases. This is especially true for distributions that have tighter integration and standardization (such as Debian), and often new upstream code is only imported irregularly because it is a manual process - both updating the package, but also making sure that it still works together well with the rest of the system. The process of importing a new upstream used to be (well, back when I started working on Debian packages) fairly manual and something like this:
1 2 | version=4
http://somesite.com/dir/filenamewithversion.tar.gz
|
1 2 3 | ---
Repository: https://www.dulwich.io/code/dulwich/
Repository-Browse: https://www.dulwich.io/code/dulwich/
|
The vcswatch service that regularly
polls packaging repositories to see whether they have changed makes it a lot
easier to consume this information in usable way.
That means about 2300 packages updated, and about 4000 unchanged.
Or 5100 packages updated and 2100 for which there was nothing to do, i.e. no upstream commits since the last Debian upload.
As can be seen, this works for a surprising fraction of packages. It s possible to get the numbers up even higher, by both improving the tooling, the autopkgtests and the metadata that is provided by packages.
1 2 3 4 5 6 | echo deb "[arch=amd64 signed-by=/usr/share/keyrings/debian-janitor-archive-keyring.gpg]" \
https://janitor.debian.net/ fresh-snapshots main sudo tee /etc/apt/sources.list.d/fresh-snapshots.list
echo deb "[arch=amd64 signed-by=/usr/share/keyrings/debian-janitor-archive-keyring.gpg]" \
https://janitor.debian.net/ fresh-releases main sudo tee /etc/apt/sources.list.d/fresh-releases.list
sudo curl -o /usr/share/keyrings/debian-janitor-archive-keyring.gpg https://janitor.debian.net/pgp_keys
apt update
|
1 | apt install -t fresh-snapshots r-cran-roxygen2
|
| [1] | I m not saying that a monoculture is great here, but it does help distributions. |
With the release of Debian/Bullseye last week, we can now support the stable Debian release (Bullseye) as well as Testing and Unstable releases with our build of KDE/Plasma (frameworks, plasma, gears, related programs) on the OBS builds. We used this switch to also consistently support three architectures: amd64, i386, and aarch64.
To give full details, I repeat (and update) instructions for all here: First of all, you need to add my OBS key say in /etc/apt/trusted.gpg.d/obs-npreining.asc and add a file /etc/apt/sources.lists.d/obs-npreining-kde.list, containing the following lines, replacing the DISTRIBUTION part with one of Debian_11 (for Bullseye), Debian_Testing, or Debian_Unstable:
deb https://download.opensuse.org/repositories/home:/npreining:/debian-kde:/other-deps/DISTRIBUTION/ ./
deb https://download.opensuse.org/repositories/home:/npreining:/debian-kde:/frameworks/DISTRIBUTION/ ./
deb https://download.opensuse.org/repositories/home:/npreining:/debian-kde:/plasma522/DISTRIBUTION/ ./
deb https://download.opensuse.org/repositories/home:/npreining:/debian-kde:/apps2108/DISTRIBUTION/ ./
deb https://download.opensuse.org/repositories/home:/npreining:/debian-kde:/other/DISTRIBUTION/ ./
Notes
Bullseye and pinning
These packages are shipped with Distribution: unstable and thus might have a too low pin to be upgraded to automatically. One can fix that by manually selecting the packages, or adjusting the pin priority. One example is given in the comment section below, copied here:
Package: * Pin: origin download.opensuse.org Pin-Priority: 950in
/etc/apt/preferences
Older sets
Note that older sets (plasma521, apps2012 and apps2008) don t support all the different variants and will disappear soon.)
Enjoy.
tools.deps.alpha, a library for dependency graph
resolution and classpath building, and the CLI tool clj, for REPL
interaction. If time permitted, I was also to improve the quality of
both new and existing Clojure packages, and the overall Debian Clojure
packaging process. My mentor was Louis-Louis-Philippe V ronneau, and my
co-mentor was Utkarsh Gupta.clojure-debian-helper). The second reason for which we only
currently have a suboptimal Clojure experience in Debian, and probably
the root of the previous one, is that many core build tools and
libraries for the language have not simply been packaged yet. My project
aimed to attack that seemingly root cause.As I said, another reason for me choosing this project is my own
experience as the Co-founder and Leader of, probably, the first Free
Software Community experience in my hometown of San Juan, Argentina.
That interest in Free Software evolved in a first PhD attempt in what is
now known as the field of Peer Production. A subject that has lived
within me as a research interest during my day job at a University.Being a Clojure fan, it felt only logical combining all those interests
somehow. And this project seemed like the ideal combination.clojure-cli.clojure-cli.clojure to use clojure-cli.clojure-cli scripts.
Continuing with details of the task I left on
extra-apt-sources parameter is added to both API and Self-Service section for the test request object and the part which took some time was deciding on its validation since if you ever deal with apt sources, you would know that there exist a lot of combinations of a valid apt source and in the end, the decision was taken to just add the minimal checks.
private tests, it made sense to have a way of looking them up in the Self-Service section. So a new column is added to the test records in Job-History marking the visibility of a test (private or public) and a new filter to filter out records based on the visibility.
retry tests is also added in Self-Service in the Job-History section so that private tests can also be retried. As earlier, this option was only available in Package History pages but those pages do not show the private tests.
publish these test results of private tests at some point.
For the API section, a new endpoint is added to accept a string of run_ids which is ready to be published, and for the Self-Service , in the Job-History page a Publish button is added to be clicked after check boxing the required tests.
I have been using the GIMP since about 20 years or so, but recently started to also work with Krita since I found it quite nice to work with (besides the text module, which is a pain).
As there came out the first beta of Krita 5, I decided to throw it into my KDE/Plasma OBS builds to try it out. To get it working, add my OBS key say in /usr/local/share/keyrings/obs-npreining.asc and add a file /etc/apt/sources.lists.d/obs-npreining-krita-beta.list, containing the following line:
deb [signed-by=/usr/local/share/keyrings/obs-npreining.asc] https://download.opensuse.org/repositories/home:/npreining:/debian-kde:/krita-beta/Debian_Unstable/ ./
Warning: Krita will also warn you, but files saved with version 5 might not be openable with version 4 of Krita, so be sure to have a backup of your files in case you need to go back to Krita 4.
Enjoy.
YNAB
On the advice of many friends, I tried to use You Need A
Budget. I gave it a seriously long, proper
evaluation: over a year. But I just couldn't get it to work for me. I don't
want to try and explain why. To be honest, those same friends who advocated for
it fairly strongly, also gave me a pretty hard time for giving up on it!
Despite it not clicking for me, there are a few concepts from YNAB that I quite
like:
hledger.
| Publisher: | Tordotcom |
| Copyright: | 2021 |
| ISBN: | 1-250-30112-2 |
| Format: | Kindle |
| Pages: | 151 |
I'm awfully lucky when you think about it. Garbagetown is the most wonderful place anybody has ever lived in the history of the world, even if you count the Pyramids and New York City and Camelot. I have Grape Crush and Big Bargains and my hibiscus flower, and I can fish like I've got bait for a heart so I hardly ever go hungry, and once I found a ruby ring and a New Mexico license plate inside a bluefin tuna. Everyone says they only hate me because I annihilated hope and butchered our future, but I know better, and anyway, it's a lie. Some people are just born to be despised. The Loathing of Tetley began small and grew bigger and bigger, like the Thames, until it swallowed me whole.Garbagetown is a giant floating pile of garbage in the middle of the ocean, and it is, so far as anyone knows, the only "land" left in the world. Global warming has flooded everything until the remaining Fuckwits (as their future descendants call everyone who was alive at the time) took to the Misery Boats and searched hopelessly for land. Eventually they realized they could live on top of the now-massive Pacific Garbage Patch and began the Great Sorting, which is fifty years into Tetley's past. All of the types of garbage were moved into their own areas, allowing small micronations of scavengers to form and giving each area its own character.
Candle Hole is the most beautiful place in Garbagetown, which is the most beautiful place in the world. All of the stubs of candles the Fuckwits threw out piled up into hills and mountains and caverns and dells, votive candles and taper candles and tea lights and birthday candles and big fat colorful pillar candles, stacked and somewhat melted into a great crumbling gorgeous warren of wicks and wax. All the houses are cozy little honeycombs melted into hillside, with smooth round windows and low golden ceilings. At night, from far away, Candle Hole looks like a firefly palace. When the wind blows, it smells like cinnamon, and freesia, and cranberries, and lavender, and Fresh Linen Scent, and New Car Smell.Two things should be obvious from this introduction. First, do not read this book looking for an accurate, technical projection of our environmental future. Or, for that matter, physical realism of any kind. That's not the book that Valente is writing and you'll just frustrate yourself. This is science fiction as concretized metaphor rather than prediction or scientific exploration. We Fuckwits have drowned the world with our greed and left our descendants living in piles of our garbage; you have to suspend disbelief and go with the premise. The second thing is that either you will like Tetley's storytelling style or you will not like this book. I find Valente very hit-and-miss, but this time it worked for me. The language is a bit less over-the-top than Space Opera, and it fits Tetley's insistent, aggressive optimism so well that it carries much of the weight of characterization. Mileage will definitely vary; this is probably a love-it-or-hate-it book. The Past is Red is divided into two parts. The first part is the short story "The Future is Blue," previously published in Clarkesworld and in Valente's short story collection of the same name. It tells the story of Tetley's early life, how she got her name, and how she became the most hated person in Garbagetown. The second part is much longer and features an older, quieter, more thoughtful, and somewhat more cynical Tetley, more life philosophy, and a bit of more-traditional puzzle science fiction. It lacks some of the bubbly energy of "The Future is Blue" but also features less violence and abuse. The overall work is a long novella or very short novel. This book has a lot of feelings about the environment, capitalism, greed, and the desire to let other people solve your problems for you, and it is not subtle about any of them. It's satisfying in the way that a good rant is satisfying, not in the way that a coherent political strategy is satisfying. What saves it from being too didactic or self-righteous is Tetley, who is happy to record her own emotions and her moments of wonder and is mostly uninterested in telling other people what to do. The setting sounds darkly depressing, and there are moments where it feels that way in the book, but the core of the story and of Tetley's life philosophy is a type of personal resilience: find the things that make you happy, put one foot in front of the other, and enjoy the world for what it is rather than what it could be or what other people want to convince you it might be. It's also surprisingly funny, particularly if you see the humor in bizarrely-specific piles of the detritus of civilization. The one place where I will argue with Valente a bit is that The Past is Red thoroughly embraces an environmental philosophy of personal responsibility. The devastating critique aimed at the Fuckwits is universal and undistinguished except slightly by class. Tetley and the other inhabitants of Garbagetown make no distinction between types of Fuckits or attempt to apportion blame in any way more granular than entire generations and eras. This is probably realistic. I understand why, by Tetley's time, no one is interested in the fine points of history. But the story was written today, for readers in our time, and this type of responsibility collapse is intentionally and carefully constructed by the largest polluters and the people with the most power. Collective and undifferentiated responsibility means that we're using up our energy fretting about whether we took two showers, which partly deflects attention from the companies, industries, and individuals that are directly responsible for the vast majority of environmental damage. We don't live in a world full of fuckwits; we live in a world run by fuckwits and full of the demoralized, harried, conned, manipulated, overwhelmed, and apathetic, which is a small but important difference. This book is not the right venue to explore that difference, but I wish the vitriol had not been applied quite so indiscriminately. The rest, though, worked for me. Valente tends to describe things by piling clauses on top of adjectives, which objectively isn't the best writing but it fits everything about Tetley's personality so well that I think this is the book where it works. I found her strange mix of optimism, practicality, and unbreakable inner ethics oddly endearing. "The Future is Blue" is available for free on-line, so if in doubt, read some or all of it, and that should tell you whether you're interested in the expansion. I'm glad I picked it up. Content warning for physical and sexual abuse of the first-person protagonist, mostly in the first section. Rating: 7 out of 10
.zim) files that can be downloaded and viewed entirely offline. You can get the entire text of the English Wikipedia in less than 100GB.
apt install kiwix will get you a graphical desktop application that allows you to download and read ZIMs. apt install kiwix-tools installs kiwix-serve (among others), which serves ZIM files over an HTTP server.
Additionally, there are now tools in Debian that allow you to create your own ZIM files: zimwriterfs and the python3-libzim library.
All of this would not have been possible without the support of the Kiwix developers, who made it a priority to properly support Debian. All of the Kiwix and repositories have a CI process that builds Debian packages for each pull request and needs to pass before it'll be accepted.
Ubuntu users can take advantage of our primary PPA or the bleeding-edge PPA. For Debian users, my goal is that unstable/sid will have the latest verison within a few days of a release, and once it moves into testing, it'll be available in Debian Backports.
It is always a pleasure working with the Kiwix team, who make a point to send stickers and chocolate every year :)
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.
nailing-cargo/1.0.0.
nailing-cargo
is a wrapper around the Rust build tool cargo. nailing-cargo can:
Cargo.toml)
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!| Series: | Between Earth and Sky #1 |
| Publisher: | Saga Press |
| Copyright: | October 2020 |
| ISBN: | 1-5344-3769-X |
| Format: | Kindle |
| Pages: | 454 |
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.
| Series: | Wayfarers #4 |
| Publisher: | Harper Voyager |
| Copyright: | April 2021 |
| ISBN: | 0-06-293605-0 |
| Format: | Kindle |
| Pages: | 325 |
"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
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:/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:/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 ./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./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:/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
pref_names.cc code file:/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,
/etc/chromium/policies/recommended/50_homepage.json file:
"ShowHomeButton": true,
"WelcomePageOnOSUpgradeEnabled": false,
"HomepageLocation": "https://www.example.com"
/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"
/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:
/etc/chromium/master_preferences./etc/chromium/master_preferences.
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.
deb http://security.debian.org/ buster/updates maindeb http://security.debian.org/debian-security bullseye-security main/etc/apt/preferences.d to add something like this stanza:
Explanation: Debian security
Package: *
Pin: release o=Debian,n=bullseye-security
Pin-Priority: 990Next.