ublue-os / bluefin Goto Github PK

Looks like this is on it's way to Fedora, we had this in the past but the COPR broke so leaving a note, here's the page to monitor: https://packages.fedoraproject.org/pkgs/input-remapper/input-remapper/

I added this to the FAQ:

https://universal-blue.org/faq/?h=socket#how-do-i-use-tools-that-expect-docker-to-be-available

I was thinking we should have it this way ootb in -dx so that when people install new tools they can work as expected. For example devpod just works instead of us having to ship a custom config to make it work with podman, etc.

Not sure of what this entails as far as having system users so linking this here: ublue-os/yafti#117

Saw this remotely on a friend's clean install but didn't have time to investigate.

The ublue-os/config repo is now doing includes for justfiles, we need to move things that would appropriate for every image there, and then move our bluefin specific stuff into the custom file.

I'd like to get a few nice fonts in the developer experience image,

[ ] Source Code Pro
[ ] Intel Mono

And a few others, feel free to suggest and PR them. I'm thinking something like top 10 of our favorite mono fonts

https://cockpit-project.org/blog/cockpit-294.html

This might be a nice svelte way to manage your clients without having a bunch of extra services installed on each one.

On fresh install when you first launch gnome-software you get this:

This is confusing because we set everything up already, so we need to find a way to disable this dialog. bigpod thinks it might be a dconf key.

Right now I'm inlining rpm-ostree installs into the sections for -dx and -framework. That should really be properly supported in packages.json so it's consistent and clean. If someone wants to take a stab at this I'd appreciate it!

(This is a placeholder in case anyone asks about the wallpaper)

I've commissioned an artist to make us something special. I can't wait for ya'll to see it!

I like the pattern of being able to make your own desktop but then have a heavier version for yourself when making the thing. I basically wanted a Bluefin Developer Edition.

My personal usage of this is having virt-manager and a bunch of other stuff on my main development machine but keeping my other machines with a general purpose image. I've made this here as a seperate image that derives FROM bluefin: https://github.com/castrojo/bluefin-dx

However it'd be nice to just have that pattern here so it can be cloned. Ideally it'd be nice to logically separate this image in a way that let's you have the extras and then spit that out in a bluefin-dx image. I'm looking for ideas on how to implement this as it's beyond my current skill level and would like to understand the approaches involved.

Things to consider:

• A separate package list.
• A separate containerfile or section of the containerfile where those specific changes can be included.
• A space in the repo for payloads specific to that image. For example I'd like to include more fonts for this but can't collide with the existing usr/share/fonts for the base image, that sort of thing.

artifacthub.io is an existing cncf project that indexes deployment artifacts from different registries and projects. It was basically a bunch of helm charts at first and then grew to index all sorts of stuff, including container images like ours!

In order to deploy complex stacks on -dx we'd want to reuse as much as possible, so maybe instead of "let's collect a bunch of yaml and dotfiles from people" the play should be being able to consume those upstream deployment files so that we can do it more efficiently:

Examples:

• https://artifacthub.io/packages/helm/nextcloud/nextcloud
• https://artifacthub.io/packages/helm/bitnami/postgresql

Effectively just lamp-stack would be a synonym for whatever helm install blah is except we'd set it up to run on the local cluster or podman directly. Then we'd effectively have a server-side app store that's already run by a cloud native community. And also it makes sense that cloud native projects will continue to add more deployment artifacts there. Plus we can do webhooks and it's OSS so we can figure out cooler stuff!

But that's also a little overkill. If we can get people more interested in quadlets they'd be perfect for local development, then all we need to do is add quadlets to artifacthub and I mostly know how we can do that.

And then we can concentrate on the glue parts and quality of life!

I recently rebased from bluefin to bluefin-dx-framework (if that matters). I noticed today that the sequence "fi" was being replaced by a phone emoji, as seen in Software:

Gnome tweaks:

I changed the Interface Text font to "Ubuntu Regular" and the font is displaying as expected now.

This used to work but I think when I adjusted the packages I broke something.

We probably want to ship the standalone version:

• https://docs.docker.com/compose/install/standalone/

This should be -dx only.

Describe the package

I'd like distrobox to be updated.

Currently, I am trying to pull off a containerized workflow for gaming and video editing using DaVinci resolve using Distrobox as I recently saw Distrobox supported GPUs.

But, NVIDIA support was only recently added, so Distrobox needs to be updated to include it.

Image

Ubuntu

The keyboard is not functioning on the latest updates, the Fn+escape : "FnLock" and Fn+space : "Backlight switch" (not seen by the system) does respond.
It works just fine after rollback to 2023-08-03.

My laptop: Lenonvo Yoga 7 (14", Gen 7) 14ARB7; french AZERTY layout.

[sisyph@fedora ~]$ rpm-ostree status -v
State: idle
AutomaticUpdates: stage; rpm-ostreed-automatic.timer: no runs since boot
Deployments:
● ostree-image-signed:docker://ghcr.io/ublue-os/bluefin:latest (index: 0)
                   Digest: sha256:20c82bf6ef74a8d3a7e20ad44ccc92381e8957d090287dbd19b08ee3d3f5be78
                Timestamp: 2023-08-05T21:24:15Z
               BaseCommit: ff8fd98b8d8b0bb08663aa33b7ac2a85f8a92df6838811b257b3d942cbdfa781
                   Commit: ced569d725787fb0943b8b06acf2667ed935643c95fc994c7d9e96edd18c4317
                           ├─ copr:copr.fedorainfracloud.org:kylegospo:gnome-vrr (2023-08-05T07:11:02Z)
                           ├─ copr:copr.fedorainfracloud.org:phracek:PyCharm (2023-07-16T06:58:28Z)
                           ├─ fedora (2023-04-13T20:37:10Z)
                           ├─ fedora-cisco-openh264 (2023-03-14T10:56:46Z)
                           ├─ fedora-modular (2023-04-13T20:30:47Z)
                           ├─ google-chrome (2023-08-03T14:54:12Z)
                           ├─ rpmfusion-free (2023-04-14T11:37:11Z)
                           ├─ rpmfusion-free-updates (2023-08-04T00:18:02Z)
                           ├─ rpmfusion-nonfree (2023-04-14T12:02:51Z)
                           ├─ rpmfusion-nonfree-nvidia-driver (2023-08-04T00:55:31Z)
                           ├─ rpmfusion-nonfree-steam (2023-08-04T00:55:39Z)
                           ├─ rpmfusion-nonfree-updates (2023-08-04T00:42:57Z)
                           ├─ updates (2023-08-06T01:31:56Z)
                           ├─ updates-archive (2023-08-06T02:16:22Z)
                           └─ updates-modular (2023-08-05T02:10:48Z)
                   Staged: no
                StateRoot: default
          LayeredPackages: langpacks-en langpacks-fr

  ostree-image-signed:docker://ghcr.io/ublue-os/bluefin:latest (index: 1)
                   Digest: sha256:fad377d43db85fac2ede03bc64bf25bd64013c45c62c3ad780636ae2e1192bb8
                Timestamp: 2023-08-03T12:40:57Z
               BaseCommit: d0a9afcb8b33c320ae7ad259494266e9911a69d9985807ca4991bda3beec2869
                   Commit: 2da14320d89e048ff2ea74c9381a81863cbfb82afffe35674830c58a4cd59994
                           ├─ copr:copr.fedorainfracloud.org:phracek:PyCharm (2023-07-16T06:58:28Z)
                           ├─ fedora (2023-04-13T20:37:10Z)
                           ├─ fedora-cisco-openh264 (2023-03-14T10:56:46Z)
                           ├─ fedora-modular (2023-04-13T20:30:47Z)
                           ├─ google-chrome (2023-07-27T18:05:04Z)
                           ├─ rpmfusion-free (2023-04-14T11:37:11Z)
                           ├─ rpmfusion-free-updates (2023-07-28T19:32:59Z)
                           ├─ rpmfusion-nonfree (2023-04-14T12:02:51Z)
                           ├─ rpmfusion-nonfree-nvidia-driver (2023-07-28T20:19:17Z)
                           ├─ rpmfusion-nonfree-steam (2023-06-23T13:24:43Z)
                           ├─ rpmfusion-nonfree-updates (2023-07-28T20:04:10Z)
                           ├─ updates (2023-08-03T02:09:59Z)
                           ├─ updates-archive (2023-08-03T02:39:09Z)
                           └─ updates-modular (2023-07-29T00:21:17Z)
                StateRoot: default
          LayeredPackages: langpacks-en langpacks-fr

[sisyph@fedora ~]$ rpm-ostree status -v
State: idle
AutomaticUpdates: stage; rpm-ostreed-automatic.timer: no runs since boot
Deployments:
● ostree-image-signed:docker://ghcr.io/ublue-os/bluefin:latest (index: 0)
                   Digest: sha256:552fa45c2432d7760cbde7f5d42ee9fafb83ecd2a868ba603417e1dee6ffb155
                Timestamp: 2023-08-06T22:47:17Z
               BaseCommit: 4b4834894984a22f57c779a1dc84b40bbb28a3b600b76f7604a7076c5ffce24d
                   Commit: 7a0e1073051e147b1d3b131ac309fd93e16ec79f329eb85bb05ea7d6c03765ea
                           ├─ copr:copr.fedorainfracloud.org:kylegospo:gnome-vrr (2023-08-05T07:11:02Z)
                           ├─ copr:copr.fedorainfracloud.org:phracek:PyCharm (2023-07-16T06:58:28Z)
                           ├─ fedora (2023-04-13T20:37:10Z)
                           ├─ fedora-cisco-openh264 (2023-03-14T10:56:46Z)
                           ├─ fedora-modular (2023-04-13T20:30:47Z)
                           ├─ google-chrome (2023-08-04T17:43:39Z)
                           ├─ rpmfusion-free (2023-04-14T11:37:11Z)
                           ├─ rpmfusion-free-updates (2023-08-04T00:18:02Z)
                           ├─ rpmfusion-nonfree (2023-04-14T12:02:51Z)
                           ├─ rpmfusion-nonfree-nvidia-driver (2023-08-04T00:55:31Z)
                           ├─ rpmfusion-nonfree-steam (2023-08-04T00:55:39Z)
                           ├─ rpmfusion-nonfree-updates (2023-08-04T00:42:57Z)
                           ├─ updates (2023-08-07T01:18:24Z)
                           ├─ updates-archive (2023-08-07T01:46:47Z)
                           └─ updates-modular (2023-08-05T02:10:48Z)
                   Staged: no
                StateRoot: default
          LayeredPackages: langpacks-en langpacks-fr

I'd like to ship this in yafti under the office section:

• https://github.com/chmouel/gnome-next-meeting-applet

Easy first PR if someone's looking to practice!

VSCode:

For settings, ship a default config that can be overriden by user choices.

Window > Title Bar Style (custom)
Extension: Dev Containers

What we want:

• #503

There's an issue with throwing you the container in as root but we know how to fix that.

Some of the yafti apps pull in outdated flatpak runtimes.

Ideally we'd pick a set of apps that doesn't pull in outdated runtimes, or at least minimize what we can.

There's likely no long term solution for this since it's up to the flatpak app developers, but maybe for 38 we can have an optimized set.

I've noticed that the codecs flatpak didn't got installed on first boot, even when it is selected.

Similar refs found for ‘org.freedesktop.Platform.ffmpeg-full’ in remote ‘flathub’ (user):
   1) runtime/org.freedesktop.Platform.ffmpeg-full/x86_64/22.08
   2) runtime/org.freedesktop.Platform.ffmpeg-full/x86_64/19.08
   3) runtime/org.freedesktop.Platform.ffmpeg-full/x86_64/20.08
   4) runtime/org.freedesktop.Platform.ffmpeg-full/x86_64/21.08
Which do you want to use (0 to abort)? [0-4]: 0
error: No ref chosen to resolve matches for ‘org.freedesktop.Platform.ffmpeg-full’

This was introduced by #324 and can be fixed by specifying the version within the yafti.yaml like so:
org.freedesktop.Platform.ffmpeg-full//22.08

I've tested this by editing the yafti.yaml file on my system and ran yafti again. This time it installed the flatpak correctly.

Installing runtime/org.freedesktop.Platform.ffmpeg-full/x86_64/22.08
Installation Complete!

Could we add the two older nvidia drivers to the image build? I am running an older video card and need the 470 driver.

Thanks!

I don't think it's worth depending on rpmfusion for non-nvidia machines since we're going all in on flathub anyway. I'd like to find a way to build bluefin-main from upstream silverblue and also spit out the nvidia versions of images from the same repo.

In the meantime I've prototyped an upstream-only version of bluefin here: https://github.com/projectbluefin/bluefin

will leave logs when I'm back at my desk
pmlogger service fails with selinux problems

Browsers probably need their own section in yafti so let's just do that, and then additionally for each one fix their PWA thing like so:

flatpak override --user --filesystem=~/.local/share/applications --filesystem=~/.local/share/icons com.microsoft.Edge

Then we should make a preset list of "Google Workspace", "Microsoft Office Stuff" set of .desktop files and put them in there too so that people can have their cloud calendars, office, mail just ootb and it's just .desktop files so no disk space issues.

When we switched to distrobox assemble it means the box isn't built until you assemble it first. Since ctrl-alt-u runs blackbox with distrobox enter ubuntu it gets confused and tried to make a fedora box named ubuntu.

Running just assemble before hand creates it and does the right thing. Maybe we should add this setup to yafti or something? open to ideas.

I got a tip from someone who is mounting their nix subsystem in a dedicated btrfs subvolume instead of a bind mount, we should look at the implications of this. Service unit looks like this:

[Unit]
Description=Nix mount
After=nix-mkdir.service
Wants=nix-mkdir.service
Before=sockets.target
After=ostree-remount.service

[Mount]
What=/dev/nvme0n1p3
Where=/nix
Options=subvol=nix
Type=btrfs

[Install]
WantedBy=local-fs.target

This might be a better option than shipping the app on the image:

https://github.com/mijorus/webapp-manager

Filing it here as a tracking issue.

Someone showed us a nice "mlbox" distrobox they had made that setups up the official nvidia image to work just right. I'd love to ship examples like this.

Currently we have one in /etc/distrobox/distrobox.ini. I'm wondering if it makes sense to move all of them to /usr/share/distrobox or something similar so that we can have some immutable examples that are community maintained, and that would allow us to ship a bunch of convenience distroboxes for not a lot of disk space, but give people the flexibility to copy it over to their ~ and then modify to their needs. Thoughts?

devpod also looks cool, let's add it: https://github.com/loft-sh/devpod

Between this and devbox this should handle the "portable devenv" use cases.

aka. turbo button. I think a gui app that just let's you toggle it would be awesome but we could start with a quick set of just aliases, something like:

• just devmode-on
• just devmode-off

Then just switch between the images. If someone wants to work on this I think it'd be great!

On a fresh rebase onto bluefin-dx-nvidia:latest, I can no longer just zsh (and also tried just fish)

Pretty sure it's related to #402

Output:

[jeefy@fedora ~]$ just zsh
sudo lchsh -s /usr/bin/zsh $USER
[sudo] password for jeefy: 
Error parsing arguments: unknown option.
Usage: lchsh [-i?] [-i|--interactive] [-?|--help] [--usage]
        [OPTION...] [user]
error: Recipe `zsh` failed on line 262 with exit code 1

Error:
0: Install failure
1: Error executing action configure_nix
2: Child action configure_shell_profile
3: Child action create_or_insert_into_file
4: Open path /usr/share/fish/vendor_conf.d/nix-installer-tmp.4025512441
5: Read-only file system (os error 30)

I got this error

in the best possible way. Thank you.

https://github.com/ublue-os/ubuntu/blob/5bf11e901bc64e8c73c46fb7227339d9027534b5/etc/dconf/db/local.d/01-ublue#L62

This should bind super-e to home, but it's not working.

Chat has decided since we've automated so much out of using Linux desktops that we need a boss key so we look like we're working twice as hard.

Therefore we'll include hollywood as an easter egg: https://github.com/dustinkirkland/hollywood

Distrobox is cool, but a by-default "I open terminal and I'm sandboxed" is better. :) This issue is to track efforts towards getting podmansh as our default shell.

Currently I have podmansh setup with this config:

[Unit]
Description=The Podmansh container
After=local-fs.target

[Container]
Image=ghcr.io/ublue-os/ubuntu-toolbox:latest
ContainerName=podmansh
RemapUsers=keep-id
RunInit=yes

Exec=sleep infinity

[Service]
ExecStartPre=/usr/bin/mkdir -p %h/data

[Install]
RequiredBy=default.target

I set it up with a just command (just podmansh). Initially, because I YOLO things, I got locked out of my own host filesystem, and had to install a different terminal (Konsole) to get back into the host (because podmansh was failing). That's a story we should probably capture and prevent lol.

It'd be nice to note which directories we can exclude in ~ for backups so that users can set up backups without backing up reproducible data like container images, etc.

I'd like to ship a working homebrew config for -dx so people who know homebrew can just use it. Installing it works and I was able to install some small tools but we may need to adjust the prefix, when running homebrew doctor.

Warning: Your Homebrew's prefix is not /home/linuxbrew/.linuxbrew.

Detailed instructions: https://docs.brew.sh/Homebrew-on-Linux

We've added some language things on the base image like npm, cargo, etc. These are to get people working but we need to do this the right way before F39.

Ideally we want to present the upstream method for installing these tools. So likely just shortcuts to get us started, and then maybe a yafti integration point where there's a developer section for each language that you want to pull in.

That will leave dx to be more of the heavy tools that people might want without bundling the universe. So far I have:

• Python - we need pip for other stuff so that comes with it, no reason to change anything.
• golang
• cargo/rust
• homebrew
• devbox/fleek for nix
• whatever other language stacks people want

The nice thing is once we have these anyone can put them in yafti/just and it'd spread the pattern to all the derived images, which is ultimately what we want.

This would be a great convenience shortcut for this audience:

https://www.jetbrains.com/toolbox-app/

and then that app manages the installation and updating of all the jetbrains tools in the user's space. Easy win. 😄

Describe the package

The layered package was removed in #33 but never added back as flatpak in yafti.

The keyboard shortcut and BlackBox config to run distrobox are there in /etc/dconf/db/local.d/01-ublue, works well after installing the flatpak manually.

Image

Silverblue

Describe the package

It confused me when I was looking into how to install Bluefin

Specifically

• v1.1.0
• v1.0.0
• Test ISOs

Originally, in order to switch between bluefin-dx and bluefin as base targets for framework (to avoid having duplicate container snippets in the Containerfile) I attempted to variable-ize the FROM portion. However, once evaluated by buildah-build it resolve the variable and assumes it to be a container registry URL and not a local target. I've included the container file below with some trimming of the intent:

ARG BASE_IMAGE_NAME="${BASE_IMAGE_NAME:-silverblue}"
ARG IMAGE_FLAVOR="${IMAGE_FLAVOR:-main}"
ARG SOURCE_IMAGE="${SOURCE_IMAGE:-$BASE_IMAGE_NAME-$IMAGE_FLAVOR}"
ARG BASE_IMAGE="ghcr.io/ublue-os/${SOURCE_IMAGE}"
ARG FEDORA_MAJOR_VERSION="${FEDORA_MAJOR_VERSION:-37}"
ARG TARGET_BASE="${TARGET_BASE:-bluefin}"

FROM ${BASE_IMAGE}:${FEDORA_MAJOR_VERSION} AS bluefin

ARG IMAGE_NAME="${IMAGE_NAME}"
ARG FEDORA_MAJOR_VERSION="${FEDORA_MAJOR_VERSION}"

COPY etc /etc
COPY usr /usr

ADD packages.json /tmp/packages.json
ADD build.sh /tmp/build.sh

# SNIP

RUN /tmp/build.sh && \
    pip install --prefix=/usr yafti && \
    ostree container commit && \
    mkdir -p /var/tmp && \
    chmod -R 1777 /var/tmp


FROM bluefin AS bluefin-dx

ARG IMAGE_NAME="${IMAGE_NAME}"
ARG FEDORA_MAJOR_VERSION="${FEDORA_MAJOR_VERSION}"

# dx specific files come from the dx directory in this repo
COPY dx/etc /etc
COPY dx/usr /usr
COPY workarounds.sh /tmp/workarounds.sh

# SNIP

RUN rm -rf /tmp/* /var/*
RUN ostree container commit

# Image for Framework laptops
FROM ${TARGET_BASE} AS framework

COPY framework/usr /usr

RUN rpm-ostree install tlp tlp-rdw
RUN rpm-ostree override remove power-profiles-daemon
RUN systemctl enable tlp

RUN rm -rf /tmp/* /var/*
RUN ostree container commit

In an ideal world we'd be able to specific the TARGET_BASE and it be one of bluefin or bluefin-dx to use that prior target as the the FROM line for framework in order to parameterize a framework-dx and framework image. However, as mentioned above this doesn't work. For now, I've used sed to manipulate the Containerfile prior to building for framework matrix but I'd like to find a more concise way to tackle this.

We need to set this, all the fractional scaling stuff falls down for electron apps and we shouldn't go special case the .desktop files. This is way better ootb and can go in the framework-specific dx files:

/org/gnome/desktop/interface/text-scaling-factor
1.25

We're building a toolbox in this repo now so we can have a more tightly coupled experience. It's not working right though even though it's building:

❯ distrobox enter ubuntu-toolbox
Container ubuntu-toolbox is not running.
Starting container ubuntu-toolbox
run this command to follow along:

 podman logs -f ubuntu-toolbox

 Error: could not start entrypoint.
{"msg":"exec container process `/usr/bin/entrypoint`: Too many levels of symbolic links","level":"error","time":"2023-05-03T19:33:05.457826Z"}

Devbox is cool let's add it: https://www.jetpack.io/devbox/

I never filed this because I didn't think people would use this. 😄

If we offered a vanilla GNOME session in GDM that bluefin users can just set after they install they could get the other stuff in bluefin but without the desktop opinion. There's probably dconf madness in there somewhere we'd have to figure out.

"Ubuntu font is now missing". The UI elements and fonts used in other places on the system besides the terminal appear to be fine :) and enabling custom font works to solve it.

here is the image showing how it looks:

It would be useful to have ctrl-alt-f bring up a Fedora userspace.