Next up for testing: Linux Kernel 6.5!

Please support Fedora with testing the latest kernel from *Sep 10-17*.

We also have Toolbx. 🧰 It has been a made a release-blocking deliverable for Fedora, so we really want to iron out bugs so that it doesn't hold up Fedora 39. Test Day for this is *Sep 14*.

Instructions on how to help can be found below: https://fedoramagazine.org/contribute-at-the-fedora-linux-test-week-for-kernel-6-5-and-toolbx-test-day/

#Fedora #Linux #Toolbx

I have made another release of #Linux Desktop Migration Tool.
You can now easily migrate your #Toolbx containers to a new machine with it! Reinstalling #Flatpak apps is also more robust now.

https://codeberg.org/sesivany/linux-desktop-migration-tool/releases/tag/1.1

Even if you don't run an #immutable system, you can still take advantage of things like #Toolbx and #Distrobox to set up alternate development environments.

My preference is to use Distrobox with a custom home directory so (theoretically anyway) config files don't mix in with those in the main system.

Fooling around with #container technology, #Flatpak and #toolbx again, together with #vscode on #fedora #silverblue. The "current" approaches seem to either be using a lot of custom scripting and hooks with https://github.com/owtaylor/toolbox-vscode/ or try to hook into the toolbx container through VS Code's "Dev Containers" feature using `com.visualstudio.code.tool.podman`. The former is highly complex and (IME) prone to breakage, the latter runs into a lot of limitations. There's finally the option to install VS Code *within* the toolbox but that's kinda... ugh.

While toying around I noticed that I don't actually want to have the VS Code "run" or "connect" to the toolbx. Actually, I only want to have the integrated VS Code terminal "run" in the context of the toolbx, the "actual development" would either happen through the standard Dev Container feature with a container *for that project *(instead of re-using the toolbx container) or using Flatpak SDKs with the Flatpak extension, if publishing directly trough Flatpak like GNOME Builder does.

Prefer using Island Of TeX #container -s for #ConTexT or #TeXLaTeX interactive development but don't want to type that much? You can simply create an alias, shell function or a simple script -- called e.g., `context` -- in your `$PATH`:

```
#! /bin/sh

podman run -v $PWD:$PWD:Z -w $PWD contextgarden/context:lmtx \
context "$@"
```

If, furthermore, your default environment is #toolbx ? Just hook the `podman` binary as well and fallback to `flatpak-spawn` within containers:

```
#! /bin/sh

if [ -f /run/.containerenv ]; then
flatpak-spawn --host podman "$@"
else
/usr/bin/podman "$@"
fi
```

You can now just run `context foo.mkiv` now outside or inside of your toolbx and it just works™

@thelinuxcast What #toolbx doing?

@ebits21 @Fbartels #Silverblue should replace #Toolbx with #Distrobox. Toolbx was first they had the idea, but now it is only inferior. I think Toolbx devolopers should abandon their project and just start to work on Distrobox.

I also agree that Silverblue should become fully declarative so that we can rebuild it with all layered packages, distroboxes, and flatpaks.

Up next at Flock... #Fedora #FlockToFedora #FlockIreland #FedoraServer #Toolbx

Fedora Server - where we are going: https://sched.co/1Or6F

State of Toolbx Project: https://sched.co/1Or7D

I'd like to write migration scripts to move data from the old laptop to the new one. It would move #flatpak app data over, reinstall flatpaks there, move #Toolbx containers, perhaps desktop settings, too.

But maybe something like that already exists and I don't have to start from scratch. Any idea?

#Linux #Fedora #Silverblue

Linux nerd stuff:

I was able to build #darktable from git inside of a #toolbox container and it could even access my system's OpenCL for acceleration!

Pretty impressive for #Podman #Toolbx

(I normally use an overlay for the openSUSE Build Service builds (OBS) on Fedora Silverblue.)

Oh c'mon #toolbx #toolbox, ffs:

```
$ toolbox enter
Error: container fedora-toolbox-37 not found
Use the '--container' option to select a toolbox.
Run 'toolbox --help' for usage.
$ toolbox --container archlinux
Error: unknown flag: --container
Run 'toolbox --help' for usage.
```

File this under curious:

I need to run #MySQL Workbench for a class.

In a #Distrobox with a #Fedora 36 image on a #Debian system, it wouldn't run.

In a #Toolbx with a Fedora 36 image on a Fedora #Silverblue system, it ran fine.

Question for @jorge and other container/immutable distro users:

I get that #Toolbx and #Distrobox are the ways to add CLI apps to your immutable system, and Flatpak is for GUI apps.

What I want to do is have a kind of GUI toolbox -- a containerized desktop that doesn't affect any of my system or user files.

I'm using GNOME Boxes, but it's not robust enough -- it tends to crash if you change virtual desktops.

Any ideas on the best way to run a container with a desktop?

@pro I've done countless rollbacks with #Silverblue, never hit a problem. Apps run in #Flatpak and my work environment is in #Toolbx, stuff in those things doesn't even know I've changed the version of the underlying OS.

@drakulix Hah, update on this! I now have

$ cat ~/.config/containers/toolbox.conf
[general]
distro = "archlinux"
release = "latest"
image = "quay.io/toolbx-images/archlinux-toolbox:latest"

and run #ArchLinux in #Toolbox #Toolbx! Going rolling relieves me of the burden to migrate 0:-)

I'm still a bit unshure how all of this is supposed to be done, since here [1] people claim one should "just" update the image... but this wouldn't carry over the packages. Which, in general, begs the question: How are toolbox'es stored? Are they layered over the base image? In theory, then, one could re-apply this onto the new image, probably breaking everything:tm:

[1]: https://ask.fedoraproject.org/t/how-do-i-update-the-os-in-a-toolbox-container/21440/3

Here's a #Linux oversimplified #hottake:

Container #Toolbx and #Distrobox are basically #WSL for Linux hosts.

https://containertoolbx.org/

Community maintained images for toolbox (and distrobox): https://tim.siosm.fr/blog/2022/12/02/toolbx-community-images/

Explaining how we made community maintained container images for common Linux distributions available for use with toolbox (and distrobox) and why we can not call them “official”.

#toolbox #toolbx #FedoraSilverblue #FedoraKinoite
#Fedora #ubuntu #debian #openSUSE #distrobox

I’m attempting to use Toolbox/toolbx for everything instead of installing native packages on my OS, but I am hitting a snag: I have a command I need to run from in a toolbox that's supposed to write to a USB drive. Right now, I get permission denied.

Is there a straightforward way to give access to the device to my toolbox environment?

#Linux #Fedora #FedoraSilverblue #toolbx #toolbox

Another blog post illustration for https://containertoolbx.org

#toolbx #pixelart #pixaki #animation #illustration

Toolbx blog post pixel illustration.

#pixelart #toolbx #containertoolbx #pixaki