Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
49 changes: 49 additions & 0 deletions content/blog/2024/01/dont-call-me-mate/index.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,49 @@
---
authors:
- image: https://avatars.githubusercontent.com/u/23007135?v=4
link: https://github.com/DavidJHarder
name: David Harder
tags:
- devlog
- mate
date: '2024-01-29'
title: 'Dont Call Me MATE, pal!'
url: /2024/01/29/dont-call-me-mate
---

Back in our [4.4 release post](/2023/07/08/solus-4-4-released) we announced that Solus would stop shipping a MATE ISO, mostly because MATE showed no signs of moving away from X11 and towards wayland. At the beginning of this year, we shipped our new Xfce ISO as a beta. And now we're getting ready to ship the _Solus MATE Transition Tool_ to move existing users off of MATE.

<!-- truncate -->

## The problem

MATE and Xfce are similar enough that eager Solusians can, and have, installed XCFE on their MATE machines with nothing more than a couple of `eopkg` commands. We're pretty sure our resident `bash` script enthusiast (ermo) could hammer out a working transition script in an evening. But we want a more polished experience. We know _you_ follow Solus news; after all, you're reading this. However, we assume there are users who dutifully update their systems, but have no interest in keeping up with our blog posts. How do we get their attention and prompt them to move away from MATE?

## Introducing the Solus MATE Transition Tool

We're pleased to show off the _MATE Transition Tool_, which we plan to include in normal updates to MATE systems in the coming weeks. Most of the work on this tool was done by Joey; more on his efforts in the section below. Here's how MATE users will encounter the tool:

:::note

These screenshots are current as of the publishing of this post, we may change things as we continue testing.

:::

1. Users will get a notification on every start-up informing them that they need to transition away from MATE.

![Notification: Solus Transition Service](notification.png)

2. Clicking on that notification will launch the Solus MATE Transition Tool.

![MATE Transition Tool Launch](MTT-launch.png)

3. Users select either Solus Budgie or Solus Xfce. The tool installs the selected edition, removes MATE, and prompts for a reboot
4. The tool removes itself after a successful transition.

Simple. At least, that's what we want users to think.

## How the Mate Transition Tool is actually part of our Python2 work

The story of the MATE Transition Tool is actually tied up in our fight to drag `eopkg` into the current decade. As I wrote previously, we're somewhat embarrassed by the amount of Solus tooling which _still_ relies on Python2. One such tool is the Solus Software Center `solus-sc`. A while back, the team decided the sane thing to do was to ditch `solus-sc` in favor of _KDE Discover_ and _GNOME Software_ . This would have the additional benefit of promoting flatpak applications to first-class citizens. The problem is _Discover_ and _Software_ have no way to talk to our package manager `eopkg`. We need an API. Luckily, other projects have encountered the same issue, leading to [`packagekit`](https://www.freedesktop.org/software/PackageKit/pk-intro.html).

Joey has been doing the dirty work of bolting `packagekit` support onto `eopkg`, and saw an opportunity: If `eopkg` could be upgraded to understand some of `packagekit`, then he could write a special-purpose application to move users off MATE without asking them to run scary bash scripts (sorry ermo). We're rather pleased with this solution. MATE users get a simple transition and Solus gets closer to checking `solus-sc` off [the list](https://github.com/getsolus/packages/issues/270).
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
32 changes: 32 additions & 0 deletions content/blog/2024/01/eopkg-is-dead/index.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,32 @@
---
authors:
- image: https://avatars.githubusercontent.com/u/23007135?v=4
link: https://github.com/DavidJHarder
name: David Harder
tags:
- devlog
- eopkg
- moss
date: '2024-01-19'
title: 'Eopkg Is Dead, Long Live Eopkg'
url: /2024/01/19/eopkg-is-dead
---

Close watchers of our [packages repository](https://github.com/getsolus/packages) may have noticed some strange looking items:

- [Initial inclusion of eopkg4-bin](https://github.com/getsolus/packages/pull/1305)
- [Testing the eopkg4-bin package](https://github.com/getsolus/packages/issues/1316) Warning: Minions GIF

It's a long story.

Our package manager `eopkg` is written in Python2. Python2 was originally planned to hit end-of-life all the way back in 2015! So Solus contributors past and present have wrestled with three thorny issues:

- Do we really want to just port `eopkg` to python3? Surely we could build something newer and shinier.
- How exactly do we want to port `eopkg` to Python3? (We'll call this ported version `eopkg3` for short)
- How do we make sure `eopkg3` works even if something goes wrong with the Python3 libraries on someone's machine?

Here's the plan to solve this: Ikey and friends over at Serpent OS are actively building a new package manager [_moss_](https://github.com/serpent-os/moss) that we are excited about. And they're building it with Solus in mind as an eventual user. This will be our fix for the first problem. In the meantime, we're taking a pragmatic approach to the last two issues so that (frankly) we can do more exciting things.

Sheepman, Livingsilver, and others completed a [direct Python3 port](https://github.com/getsolus/eopkg/commits/python3), which we never expect our users to actually run directly like a traditional Python program. Instead, that port will be compiled into a _binary_ using [nuitka](https://nuitka.net/doc/download.html). We're calling this compiled `eopkg3` binary `eopkg4-bin` for now. Critically, this binary will have _no dependencies_ other than `libc`. If we can successfully swap `eopkg` with `eopkg4-bin` on user's machines, then we've solved the last issue: Python3 can be updated without worrying about also wrecking the package manager. Got it?

But what about Python2? Well, now that Evan and Joey have seen off a [successful ISO release](https://getsol.us/2024/01/08/solus-4-5-released/) with a `calamares` based installer, we can cross `os-installer` [off the list](https://github.com/getsolus/packages/issues/270). And `eopkg4-bin` will let us cross off a whole bunch more. The rest of that list is a story for another day.
27 changes: 27 additions & 0 deletions content/blog/2024/01/welcome-devlog/index.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,27 @@
---
authors:
- image: https://avatars.githubusercontent.com/u/5338090?v=4
link: https://github.com/joebonrichie
name: Joey Riches
tags:
- devlog
date: '2024-01-13'
title: 'Welcome to the Solus Devlog'
url: /2024/01/13/welcome-devlog
---

Welcome to the Solus Development Log.

The Solus Development Log will be used by Solus Staff and outside contributors to highlight wins and changes in Solus. Keep an eye on this space.

<!-- truncate -->

The Solus DevLog has been setup to facilitate improved communication with the outside world; wins, significant changes, as well as challenges, within Solus. Solus Staff and contributors are encouraged to use this space.

The DevLog has been setup as a separate entity to the [Solus Blog](https://getsol.us/blog/) to encourage more short form development content that doesn't require the same level of polish as an official blog post.

It is hoped that this will be used to help communicate what's going on in Solus such that our short-term and medium-term progress, goals, and ambitions are less of a black box to the outside world.

Additionally, we believe it will help provide context to any of our murmurings for any users who keep an eye on the [getsolus](https://github.com/getsolus/) GitHub organization page and the [Solus](https://matrix.to/#/#solus:matrix.org) Matrix channels.

Hope to see you back at this space soon with more content!
Loading