Skip to content

Sunday, 16 January 2022

At Akademy in Milan – I’m pretty sure it was then – I gave a talk about “Managing meeting in Matrix”. The Blue Systems crew has a kind of weekly stand-up over text chat to coordinate things and to keep everyone in the loop. That meeting is managed by a Bot, which I call QuatBot. Only two years after my talk about it, I’ve gotten around to doing an actual release.

No Screenshots

QuatBot is a Bot for use in text-chat. So there are no pretty screenshots of it in action, or what the UI looks like: pick your favorite Matrix client (I switch between nheko and neochat depending on which has a more recent release fixing bugs that annoy me).

Getting the Source

QuatBot isn’t a KDE project, so it lives over on GitHub.

Now that I write it like that, I’m starting to wonder why it is not-a-KDE-project. It could easily live in KDE’s Invent, gaining the ability to be translated and possibly attracting a few more users.

Building QuatBot takes a since-2019-era collection of dependencies. Nothing bleeding edge. If you can build some KDE applications, you can build QuatBot. The more detailed requirements are in the README and the CMake output.

Using QuatBot

The heart of the application is the meeting module (but there are other modules, which we’ll get to). Running a meeting means someone is the chair, and they shout ~rollcall in the channel to get things started. That does a roll call of everyone in the channel, and people who shout (respond at all) are added to the agenda. After that it’s a matter of discussing and the chair saying ~next to move on to the next person, until everyone’s had their say.

There is support for breakouts, and re-ordering people, and some basic meeting maintainence. It does the job for the weekly status chat quite well.

The fun bits of the application live in other modules. One is the coffee module, inspired by the KoffiePot bot on IRC (which was around 1996, I guess). QuatBot can keep track of cups of coffee consumed and maintains a cookie jar, which magically regenerates cookies every hour.

In this initial release, I finally added a ~tea command because not everyone likes coffee. It does roughly the same as ~coffee. Because QuatBot keeps track of how many beverages are consumed, this required an upgrade to track tea and coffee separately, and a database schema update, and .. well, over-engineering FTW.

The Future

The bot does the things I need it for. It massages our meetings and helps run them smoothly and quickly. Looking at the code makes me think it could use a going-over with a little more C++17, and there’s a missing CONTRIBUTING.md and .. well, if I wanted to put a lot more time into building meeting-management bots for Matrix, I could. I don’t, particularly, so it’s just going to sit there unless people show up with pull requests or specific issues (either would be great, since then there would be a user besides myself).

 

https://phabricator.kde.org/source/latte-dock/

Hello everyone,

This is a long awaited feature for multi-screens users. In Latte upcoming v0.11 users can now choose their docks and panels to be on all screens or on all secondary screens. Docks and panels will be up to date in such case and it is also easier for users to make changes to them and use them in general.


- youtube presentation -

Information

  • Users can now choose for their docks and panels to belong at various screen groups. The first two screen groups introduced are AllScreensGroup and AllSecondaryScreensGroup. In the future it might be possible to provide CustomScreensGroup that the user will be able to define specific screens in which a dock or panel should be always present.
  • Current solution specifies an Original dock or panel and clones/copies itself automatically to other screens. So docks and panels in other screens are just real docks and panels that reference themselves to original docks and panels.
  • Clones are destroyed during layout startup and are automaticaly recreated. It is suggested to export your layouts through the official Layouts Editor in order to share them because in that case clones are not included in the new generated layout file. If in any case you do not follow previous steps and you share your layout at previous Latte versions then your clones will just appear as separate docks and panels that belong to specific screens.
  • Automatic syncing was introduced in order to keep up-to-date the configuration of Original docks and panels with their referenced Clones.
  • Automatic syncing currently works for all docks and panels settings, for all normal applets configurations and for all subcontaiments configuration such as systrays.
  • Automatic syncing does not work for applets inside subcontainments such as Group Plasmoid. In such case it is suggested to configure your applets inside your Group Plasmoid in the original dock or panel and afterwards to trigger a recreation for the relevant clones.
  • Manual recreation of clones is easily possible by just choosing the dock or panel to be OnPrimary or OnSpecificScreen and rechoosing afterwards the AllScreensGroup or AllSecondaryScreensGroup.


References


Donations
You can ping me at https://www.reddit.com/user/psifidotos in order to give you my paypal account.

or you can split your donation between my active projects in kde store.
-----
 
* archive has been signed with gpg key: 325E 97C3 2E60 1F5D 4EAD CF3A 5599 9050 A2D9 110E

I’ve been incredibly happy with the very early success and interest with the videos produced the past couple weeks… Both of them. While I think the attention received may have been oddly disproportionate to the quality of the content, I feel I can do far better and will be stepping up my video game!

First, I’m going to be breaking up my current YouTube account into 3 distinct channels outside of my personal videos; “Kver Create!”, “Kver Play!” and “Kver Workshop!”. I’m furiously trying to get everything ready, but here’s what everyone can expect:

Kver Create!

Will focus on work, and will be mostly livestreams. This is where I’ll be doing things like wallpapers, icons, other art, development, and even personal projects. It’s also where I’ll publish excerpts of the previously recorded livestreams when there’s interesting segments. In the future it might be neat to feature other artists and developers as well. Expect regular KDE content here.

Kver Play!

May or may not have a future, but if my first livestreams taught me anything it’s that I’m not yet comfortable with the mic, so what’s a better teacher than a more casual and fun environment while I rehabilitate my voicebox? This will probably have the most livestreams out-of-gate, but I imagine it will slow down in favour of other channels as time goes on.

Kver Workshop!

This is by far the channel I’m most excited for. It’s also going to be the last to see published videos, as I want to put the most branding, thought, and production effort into it before content start rolling out. Workshop! will cover a variety of topics, such as digital art, development, and even just using the various desktops in Linux.

For every topic there will be two types of videos: The first is short sweet to-the-point tutorials showing you how to use a tool or accomplish a goal in a program. That might include showing you the snapping tools in Inkscape, the animation docker in Krita, or the web inspector in your browser. The second type of videos will be “Advanced Workshops”, and I’m giddy over what I have planned! When a workshop is scheduled a series of tutorials will be produced in advance, the workshop will list those videos in the lead-up, then the workshop itself will put that knowledge into practice. Workshops will always be livestreamed so participants can ask questions, interact, and learn how to push their software to the limits. Once the format is fully ironed out I really want to bring in other experts, but that’s down the road.

An example of what sort of thing you might expect to learn in a workshop is how to draw semi-realistic hardware such as the laptop featured on the kde.org homepage – with leading tutorials covering things like the perspective tool and keeping vector art web-friendly. Another example of a workshop might be how to make KDE Plasma icons to standard, and down the road I’m even thinking of getting in touch with Gnome/Elementary/etc folks to see if they want workshops run to make assets in their standards.

What’s coming up?

I’m still working on making everything reasonably presentable, so the first videos will be rolling out a bit later towards the end of this upcoming week, but once it’s all up-and-running I’ll aim for an initial schedule of 4 livestreams/week, and once the Workshop! fiddlybits are sorted out we’ll trade in a livestream or two for more tutorial content. Here’s the schedule for next week:

  • Thursday January 20th at 12:00PM EST on the Create! channel: a two-to-four-hour livestream where I work on various icons in Inkscape and Python. I’ll be starting with application icons, and follow the chat if they want me to work on mimetypes and the Iconoclast pipeline. The main stream will be two hours, and I’ll do another two in an “aftershow” after a short break.
  • Thursday January 20th at 5:00PM EST on the Play! channel: is going to be a fun livestream where I game on Linux! While for me the goal is to be less awkward and more open on mic, I’m sure everybody tuning in will enjoy the fact that I – a total wuss – will be playing a scary game. I do not do well with scary games. Fine with movies. Very poorly with games. The name of the game is Outlast. I hear it is a pleasant walk in the asylum park.
  • Friday January 21st at 12:00PM EST on the Create! channel: will be livestreaming work on an in-development game built using Godot and entirely FLOSS applications. The livestream itself will be mostly work in Krita. This is very much a personal passion project, and for those interested I’ll be talking about the lore of the game and the overall intended design.
  • Friday January 21st at 5:00PM EST on the Play! channel: another scary game livestream. Probably a continuation of Outlast assuming it’s appropriately torturous fun, but I’ll take requests if people want me to mix it up.

I’m going to be re-evaluating the streams on a week-by-week basis. Mostly right now I’m just trying to get used to the mic while I work on overlays and such. There’s nothing slated for Workshop! yet, again, because I want everyone who wants to learn and participate to get a truly gold-standard experience. The kind of thing that you might pay a premium for – but for free. Part of this is planning and building out interactive overlays that will be specific to that channel, I want the interactive component to be nothing like anything else available today.

Once I finish up the basics for the channels, I’ll post the links in an update. Expect them in a few days!

Dear digiKam fans and users, After one month of active maintenance and a huge bug triage, the digiKam team is proud to present version 7.5.0 of its open source digital photo manager. This new version arrives with more than 700 files closed in bugzilla and main improvements about usability. See below the list of most important features coming with this release. Translations, Internationalizations, Localizations, and RTL Support digiKam and Showfoto have been internationalized by the KDE translators team since the start of the project.

Saturday, 15 January 2022

Just a month ago we had the first KDE Framework build against Qt6 without requiring local modifications. Things progressed rapidly from there, just with 2021 ending Kate has been seen running with proper styling and proper file dialogs. And by now we also have KF6 continuous integration for a number of Frameworks modules.

Building against Qt6

More than 40 frameworks are meanwhile building out of the box, close to 60 build with pending merge requests applied or individual problematic parts commented out.

To support this kdesrc-build now also provides initial configuration files for KF6 development builds, covering Frameworks and their dependencies as far as available already.

Note that this is all experimental and only meant for KF6 development. It uses the latest development branches as well as a number of changes still in review or not even submitted to review yet. Do not try to use this yet.

Running applications

Having libraries build and unit tests run is nice, but ultimately we need real applications to see how well things work.

Screenshot of Kate built against Qt6 using the Breeze style.
Kate built against Qt6.

My test subject has been KWrite and, as things progressed, Kate. That’s working well enough to even use it for creating smaller KF6 patches, and uses the Breeze style and proper KIO file dialogs already. A few other widget-based applications have also been seen running. While there is still plenty of work to do of course, overall this seems to be in a much better state than we have been at previous major version transitions at this point.

QML applications are still slightly behind, but things are also starting up there.

Screenshot of Kirigami Gallery built against Qt6 using the Material style.
Kirigami Gallery built against Qt6.

Custom scene graph items are still missing, which shows in the absence of card shadows for example, as well as the Breeze style, as the most visually notable things. But at least we don’t have to work blindly here either.

Continuous integration

We meanwhile also have initial support for KF6 CI builds. This can be enabled as easily as the KF5 CI by just including the linux-qt6.yml template in the .gitlab-ci.yml file of a repository.

Only Linux is supported at this point, the image used for KF6 is essentially the same as used for KF5 just with all dependencies removed that would still pull in Qt5. Not all possible dependencies provide Qt6 support yet, so we might still miss a few things.

KF6 CI builds are not only interesting to verify if things build against Qt6. They also check that we aren’t using any deprecated API scheduled for removal anywhere in KF5.

The CI is also running unit tests, so we can also already identify and fix runtime issues that arise from the Qt6 migration. Most of the tests just worked, which is very promising.

Issues

One of the main goals of doing pilot ports of applications at this stage is identify gaps or problems we missed so far, or that would otherwise block a KF6 release. Here are some examples:

  • Qt6 removed support for arbitrary text codecs (ie. QTextCodec). That’s not a problem for dealing with local input/output, all platforms use some form of Unicode nowadays. However we still need the full set of codecs for text editors and email applications, where we have to read all kinds of legacy formats. A way forward for our use-cases and APIs for this has yet to be determined.

  • Some of Framework’s C++ header install location turned out to rely on include search paths that were only set for backward compatiblity with the 4 series and thus fail to work in a 6 setup. In particular, this affects the version headers, and modules that conflate module and C++ namespace prefixes. This is being addressed in KF 5.91.

  • While the preprocessor gives us means to deal with (limited) C++ API breaks without branching, we have no such tools for QML. In some places of high-impact QML API changes it might therefore be useful to look into implementing forward-compatibility for the new API in the 5 codebase. Kirigami.AbstractListItem.icon looks like such a case, which in 6 will inherit the icon property with a different API from its Qt base class. If possible this would ease the transition, as applying QML changes that typically only fail at runtime is much easier to do step by step while you can fully test the component or application at hand.

Contribute

Obviously all of the above is the result of a big team effort, and you can be part of that!

The KF6 workboard is the central place for coordinating the work related to Frameworks 6. There’s also a weekly one hour call on Tuesday 17:00 CET. It’s also worth joining the kde-frameworks-devel mailing list and the #kde-devel channel on Matrix.

This week we released the Plasma 5.24 beta, so go check it out and file bug reports! We spent most of the week preparing for it and fixing bugs, which we’ll continue to do for the next month in preparation for the final release.

New Features

The Disks & Devices applet now offers you the option to open Partition Manager with the specified partition (me: Nate Graham, Partition Manager 22.04):

You can now configure which apps handle geo:// and tel:// links (Volker Krause and Kai Uwe Broulik, Plasma 5.24):

Bugfixes & Performance Improvements

Gwenview no longer sometimes crashes when you zoom out on an image while in full screen mode (Nicolas Fella, Gwenview 21.12.2)

Elisa no longer sometimes crashes when trying to enqueue files (Yerrey Dev, Elisa 21.12.2)

The overwrite dialog shown when extracting files using Ark that have the same name as other files already there no longer always misleadingly says, “The files are identical” (Albert Astals Cid, Ark 22.04)

Taking a screenshot with Spectacle using the terminal flags (e.g. spectacle -bc) no longer causes two notifications to be shown (Antonio Prcela, Spectacle 22.04)

The System Settings Printers page no longer displays long printer names in an ugly pixelated way when using a high DPI scale factor (Kai Uwe Broulik, print-manager 22.04)

In the Plasma Wayland session, fixed a case where KWin could randomly crash (Vlad Zahorodnii, Plasma 5.24)

In the Plasma Wayland session, the System Settings Font Management is now available (David Edmundson, Plasma 5.24)

Turning off a monitor no longer sometimes causes your panels to disappear (Marco Martin, Plasma 5.24)

Fixed various graphical glitches with multi-monitor setups (Xaver Hugl, Plasma 524)

Close buttons on tabs no longer inappropriately always have circles around their “X” symbol (Luke Horwell, Plasma 5.24)

Initials text in the System Settings Users page no longer sometimes overflow (me: Nate Graham, Plasma 5.24)

Downloading “Get New <stuff>” items with dependencies once again works (Alexander Lohnau, Frameworks 5.91, though distros should be backporting the fix ASAP for 5.90)

In the Plasma Wayland session, Help Center should no longer sometimes randomly crash when moving the cursor or hovering over links (Christoph Cullmann, Frameworks 5.91)

In the Plasma Wayland session, opening and closing the Widget Explorer sidebar no longer rearranges your windows (David Edmundson, Frameworks 5.91)

System Settings pages with “Get new <stuff>” buttons now use less memory (Alexander Lohnau, Frameworks 5.91)

User Interface Improvements

You can now find System Settings and Info Center pages by searching for their keywords in KRunner-powered searches in KRunner, Kickoff, the Overview effect, etc. (Alexander Lohnau, Plasma 5.24)

Plasma Folder View now always shows tooltips for items whose titles are elided, just like Dolphin does (me: Nate Graham, Plasma 5.24):

You can now middle-click on the Bluetooth applet to turn Bluetooth on or off (me: Nate Graham, Plasma 5.25)

Search fields in Kirigami-using apps now have a little magnifying glass in them, and it even has an animated disappearance effect when you focus the search field (Carl Schwan, Frameworks 5.91):

The Places Panel (including in Dolphin!) now has a little Eject button in it next to ejectable/unmountable disks (Kai Uwe Broulik, Frameworks 5.91):

KHamburgerMenu menus now have a simpler design for the bottom items: there is now a “More” item at the very end that shows you all the rest of the menu items, and the “Help” item is right above it, and both have proper icons (Mufeed Ali, Frameworks 5.91):

Bottom navigation bars now use the new selection style (Felipe Kinoshita, Frameworks 5.91):

…And everything else

Keep in mind that this blog only covers the tip of the iceberg! Tons of KDE apps whose development I don’t have time to follow aren’t represented here, and I also don’t mention backend refactoring, improved test coverage, and other changes that are generally not user-facing. If you’re hungry for more, check out https://planet.kde.org/, where you can find blog posts by other KDE contributors detailing the work they’re doing.

How You Can Help

Have a look at https://community.kde.org/Get_Involved to discover ways to be part of a project that really matters. Each contributor makes a huge difference in KDE; you are not a number or a cog in a machine! You don’t have to already be a programmer, either. I wasn’t when I got started. Try it, you’ll like it! We don’t bite!

Finally, consider making a tax-deductible donation to the KDE e.V. foundation.

Friday, 14 January 2022

SFXR-Qt screenshot

Last release of SFXR-Qt was in September 2019. I kept using it for Pixel Wheels, it had its quirks and bugs but I did not have the time and motivation to work on it, so the poor app was left on its own for more than two years.

Fast forward to November 2021: SFXR-Qt was added to Debian! It always feels good to see an app getting more widespread, with the minor issue that I learned about it because tests did not pass on big-endian machines... Working on that bug was a bit frustrating because I do not own a big-endian machine and failed to setup a working big-endian VM to test my changes on, but after a few blind fixes I eventually got it fixed. Kudos to Alex Myczko, the bug reporter, for the responsiveness in testing my changes.

Entering Debian probably gave a bit more exposure to the app, because I then received a bug report for that crash I had known for a long time but never got to fix... Now that someone else reported it, I finally fixed it.

Then I received a nice pull request from Linus Vanas implementing command-line export. After a few iterations it got merged, so you can now export sounds from your terminal:

$ sfxr-qt --export tests/fixtures/synthesizer/input/power-up.sfxj --help
Usage: sfxr-qt [options] sound_file

Options:
  -h, --help           Displays this help.
  -v, --version        Displays version information.
  --export             Creates a wav file from the given SFXR file and exits.
  -o, --output <path>  Specifies the path for the file created with --export.
  -b, --bits <number>  Specifies the bits per sample for the wav file created
                       with --export. Supported values are 8 and 16.
  -r, --rate <number>  Specifies the samplerate for the wav file created with
                       --export. Supported values are 22050 and 44100.

Arguments:
  sound_file           File to load.

$ sfxr-qt --export --bits 16 --rate 44100 --output power-up.wav power-up.sfxj

$ mediainfo power-up.wav
General
Complete name                            : power-up.wav
Format                                   : Wave
File size                                : 46.9 KiB
Duration                                 : 544 ms
Overall bit rate mode                    : Constant
Overall bit rate                         : 706 kb/s

Audio
Format                                   : PCM
Format settings                          : Little / Signed
Codec ID                                 : 1
Duration                                 : 544 ms
Bit rate mode                            : Constant
Bit rate                                 : 705.6 kb/s
Channel(s)                               : 1 channel
Sampling rate                            : 44.1 kHz
Bit depth                                : 16 bits
Stream size                              : 46.9 KiB (100%)

I also made some infrastructure improvements, mainly aligning the project structure with the way cookiecutter-qt-app generates projects, so that future improvements to the cookiecutter can be applied to SFXR-Qt as well.

Finally SFXR-Qt gained a "Randomize" button, based on the same feature from the original SFXR.

That's it for this release, sources are available here. There are also deb and rpm packages on the release page. I hope you enjoy creating fun retro sound effects with SFXR-Qt!

Let’s go for my web review for the week 2022-02.


Facebook collecting people’s data even when accounts are deactivated

Tags: tech, facebook, gafam, surveillance

Ever had a Facebook account? Deactivated it since then? Well apparently the surveillance anti-feature is for life… Don’t be fooled, just delete it, which is apparently harder than it sounds.

https://digiday.com/media/why-facebook-keeps-collecting-peoples-data-and-building-their-profiles-even-when-their-accounts-are-deactivated/


Is Google Search Deteriorating? Measuring Google’s Search Quality in 2022

Tags: tech, google, bing, search

Interesting look at the results from two search engines and seeing where they’re good and where they fail.

https://www.surgehq.ai/blog/is-google-search-deteriorating-measuring-search-quality-in-2022


UltraRAM Breakthrough Brings New Memory and Storage Tech to Silicon | Tom’s Hardware

Tags: tech, memory, storage, performance

Still very early days, but if that gets industrialized and the prices are not too horrible, this could bridge the gap in access times between memory and storage.

https://www.tomshardware.com/news/ultraram-implemented-in-silicon-for-first-time


Simplicity of IRC - Susam’s Maze

Tags: tech, irc, low-tech, simplicity

Don’t use it much anymore for various reasons, but I still find the simplicity of IRC still appealing and elegant. It is a really neat protocol.

https://susam.net/maze/simplicity-of-irc.html


Make the Internet Yours Again With an Instant Mesh Network | The Changelog

Tags: tech, networking, ip, decentralized

Looks like a very interesting approach. This is still clearly for techies though, but time will tell.

https://changelog.complete.org/archives/10319-make-the-internet-yours-again-with-an-instant-mesh-network


Perspective · Streaming Analytics via WebAssembly

Tags: tech, data-visualization, web

This looks like a very interesting dataviz framework.

https://perspective.finos.org/


The Optional Chaining Operator, “Modern” Browsers, and My Mom - Jim Nielsen’s Blog

Tags: tech, web, obsolescence, javascript

Or why upgrades need to happen with care, especially with an open platform like the web…

https://blog.jim-nielsen.com/2022/a-web-for-all/


Who wrote this shit? | Philip Heltweg

Tags: tech, programming

Always remember the human beings and the context behind the code you are looking at.

https://www.heltweg.org/posts/who-wrote-this-shit/


The 7 Code Review Manners. Not the code review we need but the code review we deserve

Tags: tech, programming, codereview

Not very profound but definitely useful tips on how to handle reviews.

https://reutsharabani.medium.com/the-7-code-review-manners-f0f0eef4d3e5


Haskell for all: Funding isn’t the problem with open source

Tags: tech, free-software, ethics

Interesting piece which points out (despite its title) that it’s not simply about funding, this is also about the relationship between projects and large companies which try to squeeze value out of them.

https://www.haskellforall.com/2021/12/funding-isnt-problem-with-open-source.html


Toxic Culture Is Driving the Great Resignation

Tags: management, hr, culture

Interesting exploration on why we see a large resignation movement (at least in the US, the study is US centric anyway). It’s clearly not only about wages and they are other even more powerful forces at play. First and foremost: mind your corporate culture.

https://sloanreview.mit.edu/article/toxic-culture-is-driving-the-great-resignation/



Bye for now!

After having been (again) demoted (timed perfectly to my round birthday!) based on flimsy arguments, I have been forced to rethink the level of contribution I want to do for Debian. Considering in particular that I have switched my main desktop to dual-boot into Arch Linux (all on the same btrfs fs with subvolumes, great!) and have run Arch now for several days exclusively, I think it is time to review the packages I am somehow responsible for (full list of packages).

After about 20 years in Debian, time to send off quite some stuff that has accumulated over time.

KDE/Plasma, frameworks, Gears, and related packages

All these packages are group maintained, so there is not much to worry about. Furthermore, a few new faces have joined the team and are actively working on the packages, although mostly on Qt6. I guess that with me not taking action, frameworks, gears, and plasma will fall back over time (frameworks: Debian 5.88 versus current 5.90, gears: Debian 21.08 versus current 21.12, plasma uptodate at the moment).

With respect to my packages on OBS, they will probably also go stale over time. Using Arch nowadays I lack the development tools necessary to build Debian packages, and above all, the motivation.

I am sorry for all those who have learned to rely on my OBS packages over the last years, bringing modern and uptodate KDE/Plasma to Debian/stable, please direct your complaints at the responsible entities in Debian.

Cinnamon

As I have written already here, I have reduced my involvement quite a lot, and nowadays Fabio and Joshua are doing the work. But both are not even DM (AFAIR) and I am the only one doing uploads (I got DM upload permissions for it). But I am not sure how long I will continue doing this. This also means that in the near future, Cinnamon will also go stale.

TeX related packages

Hilmar has DM upload permissions and is very actively caring for the packages, so I don’t see any source of concern here. New packages will need to find a new uploader, though. With myself also being part of upstream, I can surely help out in the future with difficult problems.

Calibre and related packages

Yokota-san (another DM I have sponsored) has DM upload permissions and is very actively caring for the packages, so also here there is not much of concern.

Onedrive

This is already badly outdated, and I recommend using the OBS builds which are current and provide binaries for Ubuntu and Debian for various versions.

ROCm

Here fortunately a new generation of developers has taken over maintenance and everything is going smoothly, much better than I could have done, yeah to that!

Qalculate related packages

These are group maintained, but unfortunately nobody else but me has touched the repos for quite some time. I fear that the packages will go stale rather soon.

isync/mbsync

I have recently salvaged this package, and use it daily, but I guess it needs to be orphaned sooner or later.

CafeOBJ

While I am also part of upstream here, I guess it will be orphaned.

Julia

Julia is group maintained, but unfortunately nobody else but me has touched the repo for quite some time, and we are already far behind the normal releases (and julia got removed from testing). While go stale/orphaned. I recommend installing upstream binaries.

python-mechanize

Another package that is group maintained in the Python team, but with only me as uploader I guess it will go stale and effectively be orphaned soon.

xxhash

Has already by orphaned.

qpdfview

No upstream development, so not much to do, but will be orphaned, too.


Thursday, 13 January 2022

It’s the start of a new year, which means some retrospective – let’s look at what happened in Calamares in 2021. Calamares is an independent Linux system installer. Independent in the sense that it is developed outside of any specific distribution, but it supports Arch derivatives, Debian, Fedora derivatives, and openSUSE derivatives. KDE Neon and KaOS. Probably Gentoo and Slackware and Nix, also, although I haven’t heard of any. Some day it will install FreeBSD, as well.

Calamares was started in 2014, back then mostly by Teo, Anke, Aurélien, with a changing cast of characters. I can find over 100 different contributors in the git history.

Commit Stats

Not that commits are all that interesting, but:

  • 31 different contributors in 2021
  • 1200 commits during the year.

One of the things to conclude from that is “it’s not just me”, but there is an active community of contributors. If I had to characterize us all, I’d say that I’m the janitor, plugging away on internals and infrastructure and making sure the parts all play together, while other people contribute neat features and bugfixes.

I don’t anticipate what distro’s want; I do listen to what they ask for and try to build things that the distro’s can then innovate with.

Releases

Calamares releases on a short-cycle. That is, roughly every two weeks there is a release regardless of what has landed. I wrote about the development process on the Calamares site a while back, but I realise I didn’t particularly write down what the development cadence is.

  • git alligator branches,
  • it’s always summer in trunk (well, in branch calamares which is the primary development branch),
  • automated releases by script, whenever I press the button.

Basically every two weeks I run RELEASE.sh and the things happen. All I need to do then is upload a tarball. These regular releases mean that new things arrive relatively quickly, and we don’t end up bogged down by long-slow-moving-branches that tackle difficult bugs. It also means that a particular bug might be serious, and still not fixed over several releases because it doesn’t land until it’s fixed in some issue-branch.

There were 22 releases of Calamares in 2021. And one release of Calamares-Extensions. That’s roughly every two weeks, allowing for some summer vacation and the like. Sometimes hotfixes happenend: only days between releases. Sometimes things were slow, or unintentionally bogged down: may and june saw no releases at all.

Community

Notable new names in the community are Evan, who has recently submitted lots of new feature work around ZFS, followed by bugfixing all over, Artem who shows up with interesting UI improvements, and Matti who wrote BTRFS things. Anke continues to be a prolific bug-fixer and chaser-of-reported-issues.

In May there was some shake-up in the community as the communications-channels moved from one IRC network to another, and then primarily to Matrix. Thanks to KDE community supervision, there’s pretty good bridging between the Libera.chat IRC and the Matrix channels for Calamares. A couple of have-been-idling-forever accounts went away, but the discussion is still going on (slowly: really most of what needs to be said happens in issues and pull requests).

For 2022

Let’s keep doing the thing.

For releases and versioning, there is a rough plan as follows:

  • the 3.2 series (now at 3.2.50) is going to come to an end,
  • a 3.3 series will be released as an LTS version,
    • this will bump the requirements for Calamares from 2014-era to 2022-era
    • ABI stability checking
    • bugfix-only releases
  • a 3.4 series will follow the same style as 3.2 did: short-cycle

The big-ticket item before 3.3 is really one of cleaning up the internals of libcalamares so that it “feels right” to have it as an LTS. I do not have a handle yet on how long it will take for that stability to be reached.