I previously wrote some advice for developers and distributions about the upcoming Microsoft CA Rollover, and I hope that was useful for people.
I've now also added some user-facing documentation about the CA rollover in the Debian wiki at https://wiki.debian.org/SecureBoot/CAChanges. I've added guidance on managing certificate updates on Debian systems: how to check if a system needs those updates and various ways to make them happen. If you're running Secure Boot systems, this may be important for you.
While the same event is the primary cause for these docs, they're designed for different people. Again, I hope this new doc is helpful!
Today, we are excited to officially announce that a brand-new map expansion is on the horizon for American Truck Simulator. Get ready to discover the crossroads of the Midwest with the upcoming...
Known as the Hoosier State or Crossroads of America, Indiana is a land shaped by hardworking communities, rich agricultural heritage, iconic motorsports culture, and bustling industry. From scenic rural highways lined with endless cornfields to thriving urban centers filled with towering factories and busy freight depots, Indiana offers truckers a diverse and authentic slice of America waiting to be explored.
You will haul cargo through vibrant cities, each with its own unique atmosphere, landmarks, industries, and opportunities. At the heart of the state lies Indianapolis, home to a world-famous racing culture and a major hub for transportation and logistics. Whether you are navigating busy interstates around the capital or taking quieter roads through small-town America, every mile brings something new to experience.
As you journey across Indiana, you will encounter a wide variety of landscapes and industries. Deliver agricultural equipment and grain from the fertile farmlands, transport steel and heavy machinery through industrial regions, or supply bustling distribution centers. Keep an eye out for iconic water towers, classic red barns, charming downtown districts, and historic covered bridges that help give Indiana its unmistakable character.
Indiana is also home to an impressive network of highways and interstates that play a vital role in American commerce. With the continuation of I-90 through northern Indiana, you can also look forward to trucking all the way to Indianapolis and deeper into the Midwest. Along the way, drivers can expect a blend of open highways, dense urban traffic, industrial zones, and peaceful countryside roads that capture the true spirit of Midwestern trucking.
Our teams are hard at work bringing Indiana to life with the detail and authenticity our community expects, and while there is still a long road ahead before release, we are excited to begin sharing more from this upcoming expansion in the future. Please keep in mind that everything you see here is still a work-in-progress and may change during development.
If you are looking forward to hitting the roads of the Hoosier State, be sure to add the Indiana DLC to your Steam wishlist and show your support for the project!
Don’t forget to follow us on X/Twitter, Instagram, Facebook, Bluesky, and TikTok, or subscribe to our newsletter for the latest updates and behind-the-scenes looks at the development. Until next time, keep on truckin’, and we will see you on the road!
I have just bought a HP Z4 G4 with W-2125 CPU for $320 and I decided it was a good time to do some benchmarks on Debian package building to see which system I should use for that.
The W-2125 CPU scores only 9,954 on the passmark multithread test but scores 2,546 on single thread [1]. Passmark seems to have some limitations as the only DDR3 system that’s important to me at the moment (the HP Z420 workstation my parents use which cost me $750 in 2021) with a E5-2620 CPU scoring 5,325 for multithread and 1,113 for single thread [2]. From the passmark results one would expect that the system is slightly more than twice as fast as the Z420 for operations that involve less than 4 CPU cores.
For the initial tests of the Z4 G4 I ran them with hyper-threading enabled as 4 cores isn’t much by today’s standards and also the machine in question is going to be less exposed to hostile data and contain less secret data than most of my systems so the security risks of hyper-threading are less of a concern.
I did some tests with a couple of tasks that are very important to me, building SE Linux policy packages (something I may do a dozen times in a day) and building Warzone 2100 (which I do less often but is the most intensive build process I regularly run). At the bottom of this post there are tables with the results from building these packages on my Z640 workstation with a E5-2696 v4 CPU [3], the Z420, and the new machine.
For the Warzone 2100 package I tested building on my Z840 dual CPU system [4]. I didn’t test building the SE Linux policy on the Z840 this time because that package can’t take advantage of even 22 cores. When I initially got the Z840 running it built the policy packages faster because the Z640 had an older CPU that was slower for single core operations than the CPUs in the Z840.
For some time I have noticed significant differences in compile time on my workstation, a factor of more than 2. I did more tests and noticed that “top” showed something like the following, those kernel threads are all BTRFS related, except for “gfx” which is probably something graphical caused by running Chrome with about 300 tabs open.
2144316 root 20 0 0 0 0 I 26.6 0.0 0:36.76 kworker/u88:20-btrfs-endio-write 2221470 root 20 0 0 0 0 I 23.7 0.0 0:01.85 kworker/u88:12-gfx 2221436 root 20 0 0 0 0 I 15.1 0.0 0:07.48 kworker/u88:8-btrfs-compressed-write 2166191 root 20 0 0 0 0 I 12.8 0.0 0:15.80 kworker/u88:23-btrfs-compressed-write 2126387 root 20 0 0 0 0 I 10.2 0.0 1:29.11 kworker/u88:4-events_unbound
I had been running BTRFS with the mount option “compress=zstd:15” which caused much of the performance problems when building. It was also a random performance issue which I think happened due to the BTRFS 30 second write-back sometimes taking more than 30 seconds during the build process which then caused a second write-back.
I did tests on ZSTD compression levels 5, 8, 10, and 15. 15 was never good and often really bad. 10 was not unbearable but consistently slower. 8 was sometimes as fast as 5 and sometimes quite a bit slower. I didn’t test levels below 5 because I need to have some compression and it seemed that the benefits of reducing compression were dropping off below 8.
I found that the BTRFS compression delay is not counted in system time for the process. I think it’s the fsync() system calls in the semodule and dpkg-deb programs that cause the delays related to BTRFS compression waiting for kernel threads.
I have all my systems other than laptops running BOINC in the background so that CPU power is used for scientific research when I don’t have any personal use for it [5]. I believe that it’s immoral to waste CPU power when it could be used for research.
In the below table which has test results from building the package with and without BOINC, and with different ZSTD compression levels in BTRFS all the worst entries were from when BOINC was running apart from one where ZSTD level 15 compression was used. The really poor performance with ZSTD level 15 was an outlier, but it wasn’t an uncommon outlier so I left it in.
Running BOINC in the background configured to use all CPU cores caused a significant increase in “user CPU time” (the time a CPU core spent actually running the program). My initial thought was that it’s partly related to “turbo boost”.
The Intel ARK page for the CPU in the Z420 shows that it’s main clock speed is 2.0GHz with a 2.5GHz “turbo boost” [6]. The “turbo boost” is apparently largely based on temperature and apparently limited to one core, so if the other CPU cores are all being used then the CPU will probably be too hot to have the turbo boost and if it happens it might not happen for my compile processes.
The ARK page for the E5-2699 v4 (which is a similar CPU to the E5-2696 v4 that I’m using but is officially documented by Intel) [7] shows that it has a base clock speed of 2.2GHz and a turbo boost speed of 3.6 GHz. 322 vs 244 seconds of user CPU time means running 32% slower which can plausibly be explained by the lack of a 64% turbo boost with a bit of help from the 55MB L3 cache being thrashed.
Turbo boost would only be a noticeable issue for building packages like the SE Linux policy packages which doesn’t take much advantage of multi-core CPUs. For a build process to average at best 362% CPU use there has to be large parts of the process that are limited to one or two cores which can potentially give a benefit from turbo-boost.
When building the Warzone 2100 packages most of the build time is running basis-universal which is a multi-threaded program to compress GPU texture data. This usually causes a load average of 300+ on the Z640 or 600+ on the Z840. But the build time is still increased by more than 50% on both the Z640 and the Z840 when BOINC is running in the background, which seems to be an indication that it’s not related to turbo boost. I verified that BOINC is running at IDLE schedule priority with the following command:
# chrt -p $(pidof -s einstein_O4MD_2.01_x86_64-pc-linux-gnu) pid 2974874's current scheduling policy: SCHED_IDLE pid 2974874's current scheduling priority: 0
In theory this means that BOINC won’t affect foreground processes.
The best claims I’ve seen about HT are 15% to 30% performance boost. The best I’ve actually seen in the past is about 18%. Seeing a 10% benefit for building Warzone 2100 is at the low end of the range I expected. 8 virtual cores is not many for a build process that causes a load average of 600+ when running on a system with 44 real cores.
I was surprised to see a 6% performance benefit in hyper-threading for building the SE Linux policy as I didn’t think there was enough use of threading or multiple processes to allow that.
Many build scripts use a number of processes that match the number of apparent CPU cores. While “make -j 88” might give a theoretical performance benefit on a 44 core system it will also take a lot of RAM and any paging will outweigh the benefits of hyper-threading. On a system with only 4 real cores there’s less potential for using too much RAM and as security isn’t so important on that system I will leave it on.
The best results of the Z640 and Z4G4 are only 50% faster than the best results of the Z420.
The Z420 has a E5-2620 CPU which is far from the fastest CPU available for that system – the E5-2687W has 8 cores and rates 10,021/1,669 on passmark [8] which is far better than the 5,331/1,114 the E5-2620. The E5-2687W is the fastest CPU that HP lists as supported by the Z420 and it supports DDR3-1666 RAM as opposed to the DDR3-1333 that is the fastest that the E5-2620 supports. With suitable hardware upgrades the Z420 would probably only take about 20% longer to do builds of the SE Linux policy and other packages that can’t take advantage of more than 8 CPU cores.
The Z4G4 system has 4 RAM channels which means that you should get some performance benefits from having 4 DIMMs, my system currently has 2 and I haven’t yet managed to get more DDR4-2666 DIMMs. But I’d still expected a W-2125 CPU with 2*DDR4-2666 DIMMs outperform any E5-26xx CPU with 4*DDR4-DDR-2400 DIMMs for tasks that average less than 4 CPU cores.
In retrospect I would have been better off getting a HP Z820 (two socket server with DDR3 RAM) than the first DDR4 systems I got. It seems that for reasonable size builds a two socket system comes close to twice the speed of a single socket system. I did briefly own a HP ML350 two CPU system with DDR3 RAM but it was too noisy for my intended use as a deskside workstation so I sold it.
I plan to do more investigation on BTRFS compression, how to get the best compression without excessive delays and how to recognise when delays are happening. I have some SSDs that have sustained write speeds as low as 15MB/s (Crucial P1 series) so for those I could probably have very high compression levels without slowing the system down.
The fact that BIONC slows things down so much seems to be a bug. When processes are running with the IDLE scheduling class there shouldn’t be such significant delays. Is it due to cache thrashing? How can I best get BOINC suitably throttled when I’m sitting at my workstation, I don’t want BOINC connecting to the local X server (which it repeatedly tries to do). Do I need to tune my kernel for better handling of IDLE scheduling?
When I get more DIMMs in the Z4G4 I need to do more tests to see if it gives an overall performance boost.
Also the Z4G4 system has a BIOS option for “sub NUMA” which basically means treating the different RAM channels on a single CPU as NUMA zones, I enabled that option which does nothing presumably because I only have 2 DIMMs, the results when I have 4 DIMMs will be interesting. I will also do some NUMA tests on the Z840 to see what benefits it gives.
I have a selection of RAM speeds that will work in the Z4G4, if I have enough spare time I’ll test what difference that makes for CPU bound tasks that matter to me.
For package building fsync() is not helpful, if the system crashes before it’s done then I will just do the build again. For a build cluster it is probably a good feature and probably doesn’t affect aggregate performance when multiple packages are built at the same time, but for the single user case probably not. I will investigate libeatmydata for package building [9].
The progress in CPUs seems to have slowed down a lot recently. The main benefits seem to be in more CPU cores and for newer sockets with more RAM channels.
The CPUs that do have improvements in single core performance are the i9 series (which mostly doesn’t come with motherboards supporting ECC) and AMD CPUs (which is rare in enterprise class hardware). Maybe I should get a server with an i9 or AMD CPU for tasks that need a fast turn around with a small number of cores. That would probably outperform any CPU designed for large core counts for things like building the policy and setting up test VMs (which depends on package installation speed that is single core bottlenecked).
The W-21xx CPUs seem to offer little benefit over the E5-26xxv4 CPUs and not a lot of benefit over E5-26xx CPUs (with DDR3). Even the W-22xx CPUs look like they aren’t going to offer a lot as they are only an incremental improvement over the W-21xx series. I had considered making the Z4G4 my main desktop workstation after the high end W CPUs become affordable, but it looks like that won’t be worth it until such CPUs drop from the current ebay price of $900 to $100.
I think I’ll keep waiting for a decent socket LGA3647 or DDR5 based server [10] for my next significant upgrade.
| System | BOINC | Compression | CPU Time | Elapsed | CPU% |
|---|---|---|---|---|---|
| Z640 | no | 8 | 248.82user 55.58system | 1:23.88elapsed | 362%CPU |
| Z4G4 | no | 5 | 245.15user 34.63system | 1:24.93elapsed | 329%CPU |
| Z640 | no | 5 | 244.75user 34.87system | 1:25.98elapsed | 325%CPU |
| Z4G4 | no | 10 | 245.21user 35.64system | 1:29.63elapsed | 313%CPU |
| Z640 | no | 8 | 248.71user 55.90system | 1:33.01elapsed | 327%CPU |
| Z640 | no | 10 | 250.90user 55.78system | 1:42.12elapsed | 300%CPU |
| Z640 | yes | 8 | 298.19user 69.30system | 1:59.77elapsed | 306%CPU |
| Z640 | yes | 10 | 300.58user 68.90system | 2:01.53elapsed | 304%CPU |
| Z420 | no | 5 | 359.01user 44.95system | 2:07.33elapsed | 317%CPU |
| Z640 | yes | 5 | 322.40user 71.82system | 2:34.66elapsed | 254%CPU |
| Z420 | yes | 5 | 372.03user 42.95system | 2:42.15elapsed | 255%CPU |
| Z640 | yes | 15 | 299.26user 67.18system | 2:59.77elapsed | 203%CPU |
| Z640 | no | 15 | 250.05user 54.60system | 3:07.61elapsed | 162%CPU |
| System | BOINC | Compression | CPU Time | Elapsed | CPU% |
|---|---|---|---|---|---|
| Z840 | no | 10 | 6549.21user 89.46system | 4:18.90elapsed | 2564%CPU |
| Z840 | no | 5 | 6533.81user 90.50system | 4:19.24elapsed | 2555%CPU |
| Z640 | no | 5 | 7040.87user 183.12system | 7:13.50elapsed | 1666%CPU |
| Z840 | yes | 5 | 8039.52user 169.62system | 8:02.86elapsed | 1700%CPU |
| Z640 | yes | 5 | 7486.44user 205.03system | 11:09.97elapsed | 1148%CPU |
| Z4G4 | no | 5 | 7891.32user 74.45system | 17:48.03elapsed | 745%CPU |
| Z4G4 | no | 10 | 7942.10user 77.43system | 17:58.72elapsed | 743%CPU |
| Build | HT | Compression | CPU Time | Elapsed | CPU% |
|---|---|---|---|---|---|
| Warzone | yes | 5 | 7891.32user 74.45system | 17:48.03elapsed | 745%CPU |
| Warzone | yes | 10 | 7942.10user 77.43system | 17:58.72elapsed | 743%CPU |
| Warzone | no | 5 | 4492.45user 59.09system | 19:59.01elapsed | 379%CPU |
| Warzone | no | 10 | 4497.28user 59.46system | 20:07.15elapsed | 377%CPU |
| Refpolicy | yes | 5 | 245.15user 34.63system | 1:24.93elapsed | 329%CPU |
| Refpolicy | yes | 10 | 245.21user 35.64system | 1:29.63elapsed | 313%CPU |
| Refpolicy | no | 5 | 180.84user 29.74system | 1:32.30elapsed | 228%CPU |
| Refpolicy | no | 10 | 180.29user 30.07system | 1:35.01elapsed | 221%CPU |
Related posts:
A big chunk of my DH related work went into designing & implementing a search app for the APIS framework. Our goal is to have a way of searching over various types of Django models. The app introduces a search model that indexes all registered models. We use a combination of PostgreSQLs full text search and Trigram Similarity to find the search results. Using a SearchVectorField and GinIndices for the trigram indexed fields we can reach a somewhat acceptable performance.
We released versions 0.63 and 0.64 of the APIS framework. The 0.63 release
introduced the new entities app, which will soon hopefully replace the legacy
apis_entities & apis_metainfo modules. Version 0.64 moved some logic from
the legacy modules the entities module.
We made some progress in defining the endpoints for the PFP API.
Welcome to the May 2026 report from the Reproducible Builds project.
These reports outline what we’ve been up to over the past month, highlighting items of news from elsewhere in the increasingly-important area of software supply-chain security. As ever, if you are interested in contributing to the Reproducible Builds project, please see the Contribute page on our website.
In this month’s report, we cover:
In a huge change in Debian’s reproducibility policy, the Debian Release Team announced that:
… we’ve decided it’s time to say that Debian must ship reproducible packages. Since yesterday, we have enabled our migration software to block migration of new packages that can’t be reproduced [on reproduce.debian.net] or existing packages in testing that regress in reproducibility.
That is to say, if newly-uploaded packages are not reproducible, they won’t be considered candidates for inclusion in the next stable release of Debian codenamed forky. (Some exceptions may be granted.)
This news generated a number of articles and comments in various news outlets:
Reproducible Builds developer Holger Levsen gave a talk at the 2026 Hamburg MiniDebconf this year on the topic of reproduce.debian.net - reproducing what is distributed from ftp.d.o.
Holger’s talk announced that Debian intends to ship only reproducible packages in forky and beyond (see above), but also talked more broadly about reproducible builds, our testing framework and the Debian archive. That is to say, moving away from testing whether a package is reproducible in a theoretical sense (eg. whether we can build it twice in different environments and achieve the same result in our test system), and attempting to reproduce the same .deb files in the official Debian archive itself. This small-sounding distinction is actually essential, as this is the only means through which the reproducible builds technique can determine whether build systems are compromised are not.
A video (32m37s) of the talk is available, as are Holger’s slides.
As initially announced in March 2026, we will be having our yearly Reproducible Builds summit 2026 in Gothenburg Sweden, from September 22 until 24, followed by two days of hacking!
Further information will be provided on our website and on the rb-general mailing list very soon.
André Arko and Amean Asad published a paper this month on Kettle, a build system that “produces cryptographically verifiable provenance for software built inside Trusted Execution Environments”:
A Kettle build records the source commit, dependency set, toolchain, build environment and output artifact digests in a provenance document produced inside a measured confidential VM. The SHA-256 digest of that document is committed to the TEE platform’s attestation report-data field, so the hardware-signed attestation report is itself the signature on the provenance, with the signing identity chaining to the TEE manufacturer’s root of trust rather than to the build infrastructure operator. Because the CVM image is itself reproducible, its launch measurement is public and stable, which lets a build requester pre-attest the CVM before submitting any input and optionally deliver source over a TLS channel terminated inside it, so the build runs end-to-end confidentially without the host ever seeing source code in plaintext.
A PDF of the paper is available online.
rebuilderd, our server designed for monitoring the official package repositories of Linux distributions and attempt to reproduce the observed results there; it powers, amongst other things, reproduce.debian.net.
A new version, 0.27.0, was released this month, with the following headline changes:
Log in.udeb supportAs kpcyrd’s announcement mentions:
The new rebuilderd package is currently available in the
extra-testingrepository. Note the Arch Linux package is upgraded fromv0.25.0fromv0.27.0; please be patient with the database migrations on first restart, and make yourself familiar with the breaking changes in v0.26.0 too.
GitHub developer BarbossHack is maintaining an repository/page on GitHub to “track reproducibility status of open source messengers”.
In Debian this month, the loong64 architecture was added to reproduce.debian.net. This is a 64-bit Reduced Instruction Set Computer (RISC) instruction set architecture developed by Loongson.
Vagrant Cascadian performed Non-Maintainer Uploads (NMUs) in Debian for several packages with outstanding patches over a year old. These included rocdbgapi, onevpl-intel-gpu, python-pytest-shell-utilities, python-mt-940 and pympress.
On tests.reproducible-builds.org, Vagrant Cascadian fixed the huge spike in build failures by adding passwd to the base tarballs, and re-enabled building gcc and binutils packages with PGO (Profile Guided Optimization) and LTO (Link Time Optimization) to avoid giving a false sense of reproducibility.
Inconsistencies on the reproducibility of the condor package were brought up on the Debian reproducible-builds mailing list. Following a hunch, Vagrant Cascadian eventually identified the issue was related to embedded kernel versions which was then fixed upstream and fixed in Debian as well.
Lastly, 40 reviews of Debian packages were added, 68 were updated and 75 were removed this month adding to our knowledge about identified issues. A number of issue types were updated, such as the addition of a new sphinx_reading_durations toolchain issue […], a golang_mango_generates_manpages_with_build_date issue […] and a random_offset_id_in_cython_linetrace […]. In addition, the timestamps_in_qhc issue was “refocused” to timestamps_in_qhc […].
In Fedora, Jelle van der Waa submitted a request for an official Fedora rebuilderd package which was reviewed by Neal Gompa.
Lastly, Bernhard M. Wiedemann posted another openSUSE monthly update for their reproducibility work there.
On our mailing list this month:
cen posted an interesting question to our list regarding “an interesting case of time-based non-reproducibility” after they noticed that Arch Linux’s rebuilderd instance reports the grep package as being reproducible whilst their own is not. Although the root cause of the issue is that various “translations are fetched from a remote location during bootstrap”, cen argues that:
Perhaps rebuilderd needs a feature where
GOODpackages are also periodically rebuilt in exponential back-off style and compared against current upstream build and also our lastGOODbuild. This would confirm whether a package is reproducible if built in a short time window but also help uncover longer time window issues that are currently hidden.
Reproducible Builds developer kpcryd copied-in our mailing list to an existing email thread that was occurring on Debian bug #1137357 regarding deterministic signatures in the Rust-based Sequoia OpenPGP library. This generated some very interesting replies, such as this one by David A. Wheeler on how naïve methods for obtaining determinism in signatures may inadvertently reveal private keys.
Lastly, David A. Wheeler announced that the 2026 Software Supply Chain Offensive Research and Ecosystem Defenses (SCORED ‘26) conference will be held on October 6 2026 in Prague, Czechia. David specifically notes in their announcement that the conference’s Call for Papers (CfP) explicitly includes “Reproducible builds” and that the submission deadline is July 12, 2026.
The Reproducible Builds project detects, dissects and attempts to fix as many currently-unreproducible packages as possible. We endeavour to send all of our patches upstream where applicable or possible. This month, we wrote a large number of such patches, including:
Arnout Engelen (1):
Bernhard M. Wiedemann (5):
Chris Lamb (23):
dkimpy.fortran-stdlib.powerline.pycayennelpp.pycorrfit.sphinx-needs.ruby-otr-activerecord.git-pw.golang-github-akavel-rsrc.pampi.libreoffice-dictionaries.vnu.golang-github-shirou-gopsutil.javacc5.rssguard.golang-github-containerd-accelerated-container-image.docker-credential-gcr.xpenguins.cairocffi.meshy.bingo.golang-github-cyclonedx-cyclonedx-go.nfstest.Paul Gevers (1):
Vagrant Cascadian (2):
Chris Lamb:
+ (plus sign) to the GNU Autotools example on the SOURCE_DATE_EPOCH documentation page. […]Mattia Rizzolo:
Finally, if you are interested in contributing to the Reproducible Builds project, please visit our Contribute page on our website. However, you can get in touch with us via:
IRC: #reproducible-builds on irc.oftc.net.
Mastodon: @reproducible_builds@fosstodon.org
Mailing list: rb-general@lists.reproducible-builds.org
Full Changelog: v1.19.5...v1.20.0
1.20.0
1.20.0
1.20.0
Donations are appreciated. There is now a PayPal option.
Updates:
Fixes:
Subtitle downloads from OpenSubtitles may fail depending on time of day. This is due to our daily download quota being exceeded. Current amount of donations is barely enough to pay for the existing quota. So it is unlikely that quota can be increased and situation will get worse over time.
If you create an OpenSubtitles account and configure it in MPC-HC settings then you may be able to bypass the quota.
Options > Subtitles > Misc > Right-click on OpenSubtitles.com > Setup > Fill in username/password
A lot of people seem to be unaware of some of the awesome features that have been added to MPC-HC in the past years. Here is a list of useful options and features that everyone should know about:
1 (restore normal view with 3).
The Asterisk Development Team would like to announce
release candidate 1 of asterisk-23.4.0.
The release artifacts are available for immediate download at
https://github.com/asterisk/asterisk/releases/tag/23.4.0-rc1
and
https://downloads.asterisk.org/pub/telephony/asterisk
Repository: https://github.com/asterisk/asterisk
Tag: 23.4.0-rc1
This release resolves issues reported by the community
and would have not been possible without your participation.
Thank You!
The Asterisk Development Team would like to announce
release candidate 1 of asterisk-22.10.0.
The release artifacts are available for immediate download at
https://github.com/asterisk/asterisk/releases/tag/22.10.0-rc1
and
https://downloads.asterisk.org/pub/telephony/asterisk
Repository: https://github.com/asterisk/asterisk
Tag: 22.10.0-rc1
This release resolves issues reported by the community
and would have not been possible without your participation.
Thank You!
The Asterisk Development Team would like to announce
release candidate 1 of asterisk-20.20.0.
The release artifacts are available for immediate download at
https://github.com/asterisk/asterisk/releases/tag/20.20.0-rc1
and
https://downloads.asterisk.org/pub/telephony/asterisk
Repository: https://github.com/asterisk/asterisk
Tag: 20.20.0-rc1
This release resolves issues reported by the community
and would have not been possible without your participation.
Thank You!
The PostgreSQL Global Development Group announces that the first beta release of PostgreSQL 19 is now available for download. This release contains PostgreSQL 19 feature previews ahead of general availability, though some details of the release can change during the beta period.
You can find information about all of the PostgreSQL 19 features and changes in the release notes:
https://www.postgresql.org/docs/19/release-19.html
In the spirit of the open source PostgreSQL community, we strongly encourage you to test the new features of PostgreSQL 19 on your systems to help us eliminate bugs and other issues. While we do not advise you to run beta versions in production environments, we encourage you to find ways to run your typical application workloads against this beta release.
Your testing and feedback help the community ensure that PostgreSQL 19 upholds our standards of delivering a stable, reliable release of the world's most advanced open source relational database. Please read more about our beta testing process and how you can contribute:
https://www.postgresql.org/developer/beta/
Below are some of the feature highlights that are planned for PostgreSQL 19. This list is not exhaustive; for the full list of planned features, please see the release notes.
PostgreSQL 19 builds on the asynchronous I/O subsystem introduced in
PostgreSQL 18. In this release, io_method=worker now automatically scales the
number of I/O workers based on the new
io_min_workers
and
io_max_workers
settings.
This release also introduces the
pg_plan_advice
extension, which lets users stabilize and control planner decisions, along with
pg_stash_advice
to apply advice automatically using query identifiers.
This release brings improvements to vacuum and maintenance operations.
Autovacuum can now use parallel workers, which can be configured with the new
autovacuum_max_parallel_workers
setting, and a new autovacuum scoring system
helps prioritize tables to vacuum. PostgreSQL 19 further enhances vacuum with
a new strategy that can automatically reduce future vacuuming work by marking
pages as visible while they're being queried. Additionally, this release
adds the new REPACK
command and its nonblocking CONCURRENTLY
option, which allow tables to be rebuilt with less operational overhead.
PostgreSQL 19 shows up to 2x better performance on inserts when foreign key
checks are present. Additionally, this release improves several areas of
the query planner and executor, including new anti-join optimizations, broader
use of incremental sorts,
eager aggregation
that speeds up row processing,
faster reads from storage during parallel sequential scans, and
simplification of IS DISTINCT FROM
and IS NOT DISTINCT FROM to plain
<> and = operators when the inputs are not nullable. There are also
improvements for
LISTEN/NOTIFY
scalability that impact multi-channel workloads.
PostgreSQL 19 introduces support for
SQL/PGQ,
letting users execute property graph queries using SQL standard syntax. This
release also expands temporal query capabilities with UPDATE and DELETE
support for the
FOR PORTION OF
clause, complementing the temporal constraint support added in
PostgreSQL 18. This release also adds
ALTER TABLE ... MERGE PARTITIONS
and ALTER TABLE ... SPLIT PARTITIONS to make it easier to reorganize
partitioned tables in place. There is now also support for returning rows that
conflict during an upsert operation using
INSERT ... ON CONFLICT DO SELECT ... RETURNING.
PostgreSQL 19 introduces the new
GROUP BY ALL
syntax, making it easy to add
all non-aggregate and non-window output columns as part of the grouping. This
release extends string processing capabilities in
jsonpath
with the addition of
lower(), upper(), initcap(), replace(), split_part(), and the trim()
family of functions.
PostgreSQL 19 makes it easier to adopt "read-your-writes" query patterns
when working with replicas using the new
WAIT FOR LSN
command. This lets a
session wait until changes up to a specific log position (LSN) have been
replayed on the replica before executing a SELECT query.
PostgreSQL 19 also adds new SQL functions to retrieve the
DDL statements
needed to recreate roles, tablespaces, and databases, simplifying
scripting and migration tasks. Additionally, the
random()
function now works
with date and timestamp types, and
PL/Python
now supports event triggers.
PostgreSQL 19 adds server-side support for Server Name Indication (SNI) through
a new
pg_hosts.conf
file, allowing a single PostgreSQL server to present
different TLS certificates based on the hostname requested by the client. There
is also a new
password_expiration_warning_threshold
setting (defaulting to 7 days) to warn users in advance of upcoming password
expirations.
Further to the ongoing deprecation efforts of
md5 authentication,
this release
issues a warning to the client after a successful md5 authentication. This is
controllable via the new
md5_password_warnings
setting.
PostgreSQL 19 introduces the
pg_stat_lock
view, which reports per-lock-type
statistics, and
pg_stat_recovery
which provides detailed visibility into the
state of recovery operations. A stats_reset column is now available across
many statistics views to show when counters were last cleared. The
pg_stat_progress_vacuum
and
pg_stat_progress_analyze
views now include a
started_by column that reports the initiator of the operation, and
pg_stat_progress_vacuum also has a mode column that reports how vacuum
is operating.
This release also allows
log_min_messages
levels to be specified per process
type, giving operators finer control over what each part of the system logs.
Additionally, WAL full page write byte counts are now reported in
VACUUM and
ANALYZE log output,
helping identify maintenance operations that generate large amounts of WAL.
Additionally, EXPLAIN ANALYZE
now supports surfacing asynchronous I/O (AIO) statistics through its IO option,
providing better visibility into how queries are using the AIO subsystem.
In PostgreSQL 19, logical replication now replicates sequence values,
simplifying tasks like online upgrades. Additionally, the new
CREATE PUBLICATION ... EXCEPT
syntax allows you to publish all tables in
a database except for a specified set, while
CREATE SUBSCRIPTION ... SERVER
allows subscriptions to be defined using a foreign server, simplifying
credential management.
PostgreSQL 19 makes it possible to enable logical replication without restarting
a server. Logical replication can now be enabled on demand even when
wal_level
is set to replica, and the new read-only
effective_wal_level
parameter reports the WAL level currently in effect. This reduces the need to
commit upfront to a higher WAL level for clusters that may only occasionally
need it, and avoids disrupting an active workload.
The PostgreSQL foreign data wrapper,
postgres_fdw,
used for query federation, includes several performance improvements, including
pushing down array operations to the remote server, and retrieving and using
statistics from foreign tables to support better local query planning.
The PostgreSQL 19 beta period includes a temporary "grease mode" to try to find protocol compatibility problems in the wider ecosystem. This wiki page contains information on how the campaign works:
https://wiki.postgresql.org/wiki/Grease
PostgreSQL 19 allows data checksums to be enabled or disabled online, without requiring a cluster restart or reinitialization.
There are several notable changes to be aware of in
PostgreSQL 19.
Just-in-time compilation (JIT)
is now disabled by default,
and the
default_toast_compression
setting now defaults to lz4,
providing better default compression and decompression performance. Support for
RADIUS authentication is now removed. Additionally, the
vacuumdb --analyze-only
command by default analyzes partitioned tables.
Many other new features and improvements have been added to PostgreSQL 19. Many of these may also be helpful for your use cases. Please see the release notes for a complete list of new and changed features:
https://www.postgresql.org/docs/19/release-19.html
The stability of each PostgreSQL release greatly depends on you, the community, to test the upcoming version with your workloads and testing tools to find bugs and regressions before the general availability of PostgreSQL 19. As this is a Beta, minor changes to database behaviors, feature details, and APIs are still possible. Your feedback and testing will help determine the final tweaks on the new features, so please test in the near future. The quality of user testing helps determine when we can make a final release.
A list of open issues is publicly available in the PostgreSQL wiki. You can report bugs using this form on the PostgreSQL website:
https://www.postgresql.org/account/submitbug/
This is the first beta release of version 19. The PostgreSQL Project will release additional betas as required for testing, followed by one or more release candidates, until the final release around September/October 2026. For further information please see the Beta Testing page.
It's been ten years since I configured mount on demand backups to reduce
the risk of my backups being zapped by mistake. Way back then I wanted to go
one step further and use dedicated mount namespaces for backup jobs, but
systemd didn't provide the necessary support (and still doesn't, despite the
promisingly-named JoinsNameSpaceOf= configuration option.)
I recently updated my setup to achieve this by hand. All backup jobs now have
an extra pre-start instruction ExecStartPre=mkbackupns which runs a shell
script to either set up a persistent mount namespace, or exit quietly if it
already exists.
#!/bin/bash
set -euo pipefail
nsdir=/var/namespaces
nsfile=$nsdir/backup
nsfilex="$(echo $nsfile | sed 's#/#\\/#'g)"
private_propagation() {
findmnt -o+PROPAGATION "$nsdir" | grep -q private
}
nsfs_is_mounted() {
test "nsfs" = "$(awk "/$nsfilex/ { print \$3 }" /proc/mounts)"
}
if ! nsfs_is_mounted; then
if ! private_propagation; then
mkdir -p "$nsdir"
mount --bind --make-private "$nsdir" "$nsdir"
fi
touch "$nsfile"
unshare --mount="$nsfile" true
nsenter --mount=/var/namespaces/backup mount /dev/phobos_backup/backup /backup
fi
I should note that I don't have the backup filesystem described in /etc/fstab
to reduce the risk of it being mounted errantly in the main namespace.
The other change is to prefix an invocation of nsenter for every backup
job command. E.g.:
ExecStart=/usr/bin/nsenter \
--mount=/var/namespaces/backup \
borgmatic -v 1 prune create
My backup scheme has lasted a decade with few tweaks (I moved it to Borg in 2020) which I am very grateful for. I want reliable, boring and robust.
Persistent mount namespaces are a lot less convoluted if you have a persistent process to associate them with. I didn't, but a subsequent improvement I am making is introducing one, so I will likely simplify the above accordingly.
.eml (message/rfc822) attachments like an emailapi.i18n.t)/api/translate proxy and email body exposed to pluginspasswordHashFile in admin.jsonsessionSecretFile and oauthClientSecretFile for file-based secrets in JSON configFileNode hierarchy, migrate legacy flat-named files on load, and list folders via FileNode/get so they are visible (#379)FileNode as the only folder signal and migrate legacy dir-markershtml/body height: 100%R:/I: subject prefix tokens and deduplicate localized reply/forward prefixesbasePath in the plugin sandbox, http.post proxy, and branding<html lang>, and per-locale <head> description; add missing settings.folders.role_memos keyh-14 height and the account selector header to the search/reply toolbars
We're happy to announce that the Open Beta for the 1.60 update for Euro Truck Simulator 2 is now available for players to try out and test. If you choose to participate, we'd greatly appreciate any feedback, bug reports, or issues you encounter being shared in the appropriate section of our official forums.
Your feedback and reports are incredibly valuable to our team, and we truly appreciate everyone taking the time to help us refine and improve the game experience. Now, without further ado, let's take a closer look at what the 1.60 Open Beta has in store.
With Update 1.60, we are introducing Game Radio, a brand-new in-game radio system designed to make every drive feel more immersive and authentic. Rather than just playing music, Game Radio gives you five stations with their own distinct sounds, identities, and moods, each one built to shape the atmosphere of your journey in a different way.
At launch, players can tune into Rust FM, Escape, PUMP IT!, Pop Gear, and Roadio, spanning guitar-driven rock and American roots music to electronic, pop, and lo-fi. Each station features carefully curated tracks, handpicked to hold up across many hours on the road. Escape is also the only stream-safe station at launch, designed to help content creators avoid copyright claims.
Game Radio also introduces a new in-game widget displaying station info, track titles, and artist names while driving. Players can customize widget behavior through the Widget Options menu (F6). This update also brings a range of improvements to the existing radio and music player systems.
Game Radio arrives with its musical foundation in place, with more planned for future updates. You can find out more information about Game Radio in our dedicated blog post.
The Improved Material System significantly improves the lighting and visual quality of vehicle interiors in selected trucks. Its main focus is to enhance how interior materials react to light, which will result in a more readable, detailed, and visually pleasing cabin environment.
During the development of Project Road Trip, we implemented a wide range of visual and technical improvements. One of the most significant changes was a redesign of the materials used in vehicle interiors. As a result, it makes differences between materials such as leather, fabric, plastic, and metal far more apparent, even in low-light conditions. The new solution uses multiple variants of dynamic cubemaps, allowing all materials to reflect their surroundings more naturally and respond to ambient light in a more realistic way.
The entire system was designed from the start with the interiors of trucks in both games in mind, so the base games and their existing fleets will gradually benefit from these improvements as well. The first trucks to benefit from the Improved Material System in ETS2 will be the DAF NGD and MAN TG3 TGX models. With future updates, we will gradually add this technology for other trucks across both games. You can read more about this feature here.
We have carried out minor adjustments to the global lighting, primarily focused on exposure and contrast balancing, along with subtle visual refinements for bad weather conditions. The work mainly consisted of smoothing out and polishing the overall visuals to achieve a more consistent and refined look.
With this update, truckers will be able to customize their Volvo FH Series 6 with a selection of several new aerodynamic parts, including the newly designed aerodynamic roof deflectors available for the Sleeper Cab, Globetrotter, and Globetrotter XL cab variants. These updated components help create a smoother and more refined roof profile, blending seamlessly into the truck's overall design.
Alongside these additions, all Aero cabin variants will also have the option to add new distinctive black aerodynamic A-Pillar trim, as featured on the newest generation of Volvo FH truck. These new additions reflect Volvo Trucks' ongoing efforts to improve aerodynamic efficiency and optimise airflow around the cab to help enhance energy efficiency and overall vehicle performance.
Based on feedback from our #BestCommunityEver and upcoming widget designs, the Job Details Widget will be introduced with the 1.60 update. Its primary purpose will be to enable a new, more immediate, and concise way of displaying relevant job info. Also, in response to community feedback, the GPS will now display the estimated arrival day and time, along with the remaining travel time and distance.
Once added, you'll be able to enable the Job Details Widget through the Widget Options menu (F6). The widget will display key job information, including cargo type and weight, delivery location, job income (colour-highlighted), and the remaining time to complete the job, so players will have this info available immediately without the necessity to pause the game. You can read more about the feature here.
This new feature gives players greater control over their rest periods by allowing them to choose how long they want to sleep and exactly when they want to wake up, instead of being limited to a predefined rest duration.
Alongside this change, the Fatigue system will now be split into two separate values: Rest State and Mandatory Break, each represented by its own icon in the UI.
The Rest State, symbolised by a bed icon, will now gradually deplete rather than recover over time. Extended periods of driving will steadily reduce the Rest State, while resting will restore it at a faster rate.
The Mandatory Break system, indicated by a "P" icon along with the remaining hours before a required stop, will function more strictly. In Euro Truck Simulator 2, drivers may drive for up to 10 hours before taking a mandatory break, which requires 9 consecutive hours of rest. You can read more about this feature here.
Vehicles
Visual
Sound
UI/UX
So enjoy all the new additions, but please remember: It's only an open beta, not a stable public version - so you may encounter bugs, instability, or crashes. It's completely okay if you want to wait for the final release. But if you're interested in helping us to get there faster, we'd appreciate all of your feedback on our forum and your bug reports in the dedicated section.
Please check our modding wiki to get details pertaining to mods for the game.
If you wish to participate in this Open Beta, you can find this version in the Experimental Beta branch on Steam. The way to access it is as follows: Steam client → LIBRARY → right-click on Euro Truck Simulator 2 → Properties → Betas tab → Beta Participation drop-down menu → public_beta. No password is required. Sometimes you will have to restart your Steam client to see the correct branch name there.
Full Changelog: v4.1.1...v4.1.2
