Board Activity

We need to delete/remove all of the things that we're not using from ublue-os/packages

In order to track work we need to assign the person who submits/merges the PR to the issue, this looks popular: https://github.com/marketplace/actions/assign-author We should set up autoassign for the PR and then if it fixes an issue it should also assign the issue to that person?

We're adding containerd (and soon docker) to the base image since it's not that big and we could cut the build matrix in half between aurorafin. Most of this stuff can be done in userspace now so let's take a look: - [x] add containerd - [ ] add docker with the service off by default - [ ] add group config so that users are in the docker group ootb - [ ] Figure out what to do about incus - [ ] QEMU Changes needed to the `ujust devmode`: - [ ] Fire off `ujust bbrew` with the IDE list so the user can choose: - [x] Jetbrains toolbox via brew - [x] VSCode via brew - [x] vscodium via brew - [ ] Enable/start the docker service The other stuff we'd leave, Podman Desktop should remain installed by default when the user turns on devmode, and the existing dev flatpaks are great. Things we don't have that would be nice: - [ ] 🔥 Move the `Containers` logomenu option to devmode only. We should remove the distrobox/shelf link from the logomenu on the non-dev image, people can just turn it on if they need it. We'd leave distrobox on disk of course, we want to make stock Bluefin less nerdy. - [ ] 🔥 Something logomenu related for dev mode - The original intent was for dev mode to [feel like this](https://www.youtube.com/watch?v=E7-o6a0OUHY), like when you engage sport mode in your car. Some visual cue that you're in devmode would be nice, but it should be super subtle. - [ ] Things in the experimental tap: - [ ] The individual jetbrains IDEs. Apparently jetbrains ships these too along side the all-in-one-toolbox. - [ ] Emacs - we need an emacs power user to tell us if this is the way to go. - [ ] antigravity - [ ] cursor - [ ] nvim from brew - [ ] helix from brew K8s things - [ ] k0s and/or k3s with an opinionated config for a local dev cluster - [ ] Ensure `kind` is included ootb For qemu the flatpak for virt-manager is fine but I'm not sure of what's needed for command line stuff for it (I don't use it). This one is pretty big so open for discussion. Also would like to stretch goal `lima` along with it for a nicer container/vm bridge. The brewfiles are easy to update so adding a bunch more IDEs and tools is easy and we should probably do that. We should however be careful about adding more things to the tap unless we know people want them.

This is currently automerging, needs to be setup to only merge when the PR is merged.

Sync with with what aurora is doing

I merged something into `main` but no builds fired off, they should build and push into `:lts-testing`.

We need an emoji chooser thing, let's ship this https://flathub.org/en/apps/it.mijorus.smile This should be bound to the keybinding as `super`+`.` We tried this before but didn't get the keybinding to stick, so let's try again.

This should be done in all Bluefin repos, just link to the centralized one at https://docs.projectbluefin.io/contributing Repo-specific information should remain in that repo's CONTRIBUTING.md. Example: ``` # Contributing Checkout the [Bluefin Contributor Guide](https://docs.projectbluefin.io/contributing) for project-wide contribution information. Thanks! ## Contributing to this repo (repo-specific instructions go here) ```

Looks like this is inprogress, we can drop our backport and just roll with these instead! - https://issues.redhat.com/browse/RHEL-124219 - https://gitlab.com/redhat/centos-stream/rpms/gnome-shell/-/merge_requests/123

This is to ensure all our issues and consistent across repos and should help dosu autolabel better. also better tracking on the board.

### Describe the bug Attempting to restart or power off Bluefin LTS yields the following error message <img width="1920" height="1200" alt="Image" src="https://github.com/user-attachments/assets/d1d5bafe-3431-44d6-972a-d0755f5e183f" /> ### What did you expect to happen? I expected the system to reboot and power off without any GNOME shell issues ### Output of `bootc status` ```shell ● Booted image: ghcr.io/ublue-os/bluefin-dx:lts Digest: sha256:b4ef882ed49aa5bb80b75bcf6b97a89eae4474c99fd0233f165b2ab5a61a6e1f (amd64) Version: stream10.1 (2025-12-31T02:59:28Z) Rollback image: ghcr.io/ublue-os/bluefin-dx:lts Digest: sha256:eaa55a27ed0a65c161378f2965a704bc7e5c7b31c1a390547f0bcda6a9fb3fc9 (amd64) Version: stream10.1 (2025-12-30T14:40:17Z) ``` ### Output of `groups` ```shell mgopal wheel docker ``` ### Extra information or context # System Details Report --- ## Report details - **Date generated:** 2026-01-01 22:47:37 ## Hardware Information: - **Hardware Model:** Lenovo ThinkPad T16 Gen 3 - **Memory:** 16.0 GiB - **Processor:** Intel® Core™ Ultra 5 125U × 14 - **Graphics:** Intel® Graphics (MTL) - **Disk Capacity:** 512.1 GB ## Software Information: - **Firmware Version:** N47ET23W (1.12 ) - **OS Name:** Bluefin LTS - **OS Build:** fb5c0c2 - **OS Type:** 64-bit - **GNOME Version:** 48 - **Windowing System:** Wayland - **Kernel Version:** Linux 6.12.0-174.el10.x86_64

This is a regression, `ujust rebase-helper` should show LTS images, not fedora ones

### Describe the bug I wanted to try to rebase to the hwe kernel, as stated in the docs, by using ujust rebase-helper. None of the given options sound like the one I need. ``` ❯ ujust rebase-helper Current image: bluefin:lts (Fedora null) Select your Bluefin image: > bluefin bluefin-dx bluefin-nvidia-open bluefin-dx-nvidia-open cancel ``` ### What did you expect to happen? I expected an option like bluefin-lts-hwe ### Output of `bootc status` ```shell ● Booted image: ghcr.io/ublue-os/bluefin-dx:lts Digest: sha256:889373f746a7eccd0613dd10426cc4c660d0b68d7499f1f11ef6db7a408b74c6 (amd64) Version: stream10.1 (2025-12-04T17:41:54Z) Rollback image: ghcr.io/ublue-os/bluefin:lts Digest: sha256:9986acb32fa3655be416fcaad7959eddfcdff2616e33c06467ab316e94cc8723 (amd64) Version: stream10.1 (2025-12-04T17:40:03Z) ``` ### Output of `groups` ```shell istvan wheel dialout docker ``` ### Extra information or context _No response_

`sudo bootc switch --enforce-container-sigpolicy ghcr.io/ublue-os/$IMAGE_NAME:lts.20251214` I needed to revert and ran this command as documented in the release notes and it took me off of the hwe image and onto the stock image. We probably need to account for hwe in the release notes thing?

We need to move @projectbluefin/iso to production. This new builder is decoupled from the bluefin repos. It is the centralized place to build all the ISOs and push to Cloudflare. Currently it pushes to the `testing` bucket in cloudflare and populates this page: https://docs.projectbluefin.io/downloads-testing The production ISO builder for LTS/stable/gts is in @ublue-os/bluefin and pushes to the `bluefin` bucket in cloudflare and populates this page: https://docs.projectbluefin.io/downloads and the website. In production this repo should only every push to the `testing` bucket, we need a github action to do a cloudflare r2 server side copy using rclone to promote ISOs from the testing bucket to production. Then a maintainer can decide when to push to prod based on testing. After we make tests we'll automate promotion. This is currently blocked by a bug in bootc, so work on this shouldn't start before EOY.

This is blocked by gnomeos-bootc not being able to update yet. This is an upstream issue, and why we're concentrating on projectbluefin/common, which makes this one very easy to implement.

I hate that I need to `sudo bootc status`. Anything that doesn't need sudo should "just run" or prompt me to do the priviledged operation.

From chat, let's go with: next -> testing -> stable With pullapp PRs to gate. But we don't need to set that up now, filing this to track it tho.

Use an rclone action to copy the ISOs from `testing` to `production`. We'll keep old ISOs in the `bluefin` bucket for a while as a hot backup while we migrate.

This doesn't need to be an issue

Ship `bluefin-cli` on homebrew for macs. It should feel the same!

Let's remove this by default: https://universal-blue.discourse.group/t/aurora-cli-atuin-broken/11373 It's just been too broken for too long and it makes me want to turn off bluefin-cli entirely. People can opt in and we can revisit later.

## "Bluespeed" Mission: Drive open source AI adoption by delivering a kickass community driven desktop experience. Initial cut: `ujust bluefin-ai` top level just like `bluefin-cli` to turn all of this on. - [ ] Include goose cli - [ ] Include goose desktop? - [ ] Light shell integration (needs details) - [ ] Pulls small LLMs for on-device work - [ ] "Some sort of goose config" that has this work ootb. It should also be trivial for me to connect anything goose supports. Awesome things we want that should be scoped out seperately: - [ ] "Ask Bluefin" chatbot that talks to local llm. This should be exposed via a ramalama openai endpoint so that the user can swap in an LLM of their choice - [ ] dosu cli or some other desktop integration - [ ] Figure out how to ship/use the linux system MCP RH is working on: https://github.com/rhel-lightspeed/linux-mcp-server. Anything agentic should be a "power mode" since it changes the safety model. Readonly for diagnostics and introspection is a clear boundary that we should enforce. Users are using general LLMs for Bluefin and those won't be as nice as a custom solution. With Ask Bluefin you can use it for everything. For example I don't think I've written a service unit by hand in like 6 months, everyone should have this. ## Ideas ### Hosted Ones They don’t need to be perfect, they just need to be better than the average redditor. This is mostly done. 🙂 These are fantastic tools but we also need to: - Ensure local first OSS is the halo experience, remove third party dependencies - Give our experts a platform to experiment - Align with Red Hat’s AI initiatives to share resources - Do for RHEL Lightspeed what Universal Blue does for bootc - Build a community - We can curate some awesome OSS stuff since we can curate our user experience - Brings more open source AI people into this, we’re selling the idea so we need everybody. - We can help GNOME by proposing that desktops should have API standards around AI so developers can build applications ### Bluespeed Local AI controlled by the user, (spiel). We build on ramalama and have the capability to ship custom OCI images from ghcr already, infrastructure is in place! Ideally the tools install cleanly, no background services unless enabled, endpoint is local-only by default, and the uninstall path leaves no surprises. - We already ship ramalama - We declare that our images will have standardized API endpoints driven by ramalama, opt in due to tech (llm size, etc) - We pick a base model to ship, small because laptops - We RAG in official docs, source code of everything, Homebrew docs, Flathub, Bazaar, ramalama, podman, podman desktop, bootc, devcontainers, vscode, etc. You get the idea. The RAG should probably be a seperate deliverable, `bluefin-knowledge` or something. - Final goal of proposing AI endpoints to the major desktops for standardization. - We maintain the prompt in github to be community maintained: This also means the pattern can be templated. Imagine the universal blue custom image template having this ootb - an organization’s custom image could ingest everything and they have the structure in place to do what they want. Bazzite could ingest sites like: https://steamdb.info/ and https://www.protondb.com/ so that users can have fresh information on things -- these are crucial resources for new users! ### Implementation We add “Ask Bluefin…” to the menu. We use alpaca or another GTK chat app thing, user hits enter to accept the thing so that it downloads the right LLM stuff, managed by ramalama in the backend. We bind this to a copilot key if it exists, and bind it to F1 or some other help shortcut. We include a PDF of the docs on the installation anyway. And yelp was removed from GNOME, this is the replacement. #### Shell and Other Shell integrations We should strive for “enthusiast driven version of RHEL Lightspeed”. Light shell completion perhaps? Open to ideas. Should be very light, don’t push it, they need to be *softly onramped*. They are probably anxious. Pros should be able to “opt-in” to powerful mode that can prototype ideas and go full hog. Ideas proven in Bluefin could be useful to use somewhere else. We need to find and ship the best VSCode extension out of the box on our developer images. Something like continue? But then the pile of 3rd party deps piles up. Needs discussion ### Why? We will earn a great reputation with open source AI experts, this is a huge growth area. Those hills are rich in new open source contributors waiting for the right messaging: - We will stick to enabling APIs with Ramalama and not building wiz bang products, we offer an AI API for app developers - we want more alpacas and Jans. - We’ll ship enough oss goodies so that other OSS vendors can get wins as well, we’re trying to lift all boats here. - Distros gonna distro, none of them are going to touch this stuff because they’re going after 1990s linux guy as their user base and they have no clue how quickly open source AI has already surpassed the free desktop world. Sigh. - We don’t even call it AI, we just talk about the features, aka “Ask Bluefin”, there’s nothing for them to argue about. - We repel the usual suspects - Ramalama hardware accelerates a ton of stuff ootb, it’s a breeze to get it up and running vs. ollama. - Since it’s containers all the cuda/rocm containers get updated via the existing update tools transparently to the user anyway - All those security benefits of doing it the container way. - What's the tldr on this at RH now that Dan is retired? Is there a champion? Find them. ## Not Interested In - AI bro tech, we should scheme with people who are OSS-first. - Arguing with 1990s Linux guy. - Shipping image gen AI things. The artists paid for Bluefin’s artwork have had their lives affected by AI, it’s the only reason I can afford them. I want to make an implied statement that we provide API endpoints and drive open source, and yet Bluefin is a human creation -- how you view this is your decision to make, not ours.

https://github.com/ublue-os/bluefin/blob/1e2c836ee21e193baf4bb3bfe85b82eec217ffd2/system_files/dx/usr/share/ublue-os/user-setup.hooks.d/10-vscode.sh#L5 ^^^ we should use the `vscode` things in the Brewfiles to do this, then all we need to ship for vscode is the settings.json and that would be much simpler!

https://podman-desktop.io/blog/2025/05/05/vs-code-with-podman-desktop ^^^ Let's ship this as an ootb experience. And if we can cover jetbrains as well that'd be awesome, I am pretty sure you can manage jetbrains extensions via Brewfiles, worth investigating! Let's keep it decoupled from the IDE, I think the tagline would be something like "A CNCF-compliant stack" since we'll also have a k8s option so you can slice and dice it however you want. This is also a nicer option for new people who might not want to drop into k8s right away.

We need to recommend this but it's not production ready yet.

The rebase helper needs to be more generalistic and needs a few bug fixes.

We tried this in the past but couldn't get the keybindings to work, now this should work with our clean setup. Basically have gradia be the default screenshot when you hit printscreen, and all the modifiers for the key should work as well.

The rebase helper needs to be able to switch people to and from a testing image.

More OCI-ification, this should simplify things: https://github.com/ublue-os/brew

Move from the packages repo to: https://github.com/ublue-os/brew

This is missing in LTS and should be done at the projectbluefin/common level.

Fixes: https://github.com/ublue-os/bluefin/issues/3794 Requires: https://github.com/projectbluefin/branding/pull/2

Parity issue, we should set this in projectbluefin/common and not set this per image: https://github.com/ublue-os/bluefin/blob/033f6cf8347f623d58278d75f2250a8a83c3b39c/build_files/base/05-override-install.sh#L46

We should make it so a rebase errors out with a similar warning to #1651 - that way gts users without signed keys don't rebase and boot into a busted system, helps mitigate: https://github.com/ublue-os/bluefin/issues/1636

### Discussed in https://github.com/ublue-os/bluefin/discussions/2891 <div type='discussions-op-text'> ^{Originally posted by **JohnAtl** July 31, 2025} I'm on GTS. VSCode isn't debugging, and I need to rebase to last week's release as a test. ``` ❯ ujust rebase-helper Choose your action. Which Tag would you like to rebase to? The default selection is gts, stable (weekly builds) and stable-daily (daily builds) are for enthusiasts, and latest is for testers Choose: > date latest (F42) stable (F42) stable-daily (F42) gts (F41) cancel ``` If I select '>date', I am warned that I will rebase off of GTS. If I select 'gts', I am not given a choice of dates to rebase to. (An assumption, as I abort at the request for root privileges.) Or am I holding it wrong?</div>

Only issue is bluefin-nvidia and related packages aren't part of rebase-helper. I copied `/usr/bin/ublue-rollback-helper` to my home drive and changed line 36 to `IMAGE_OPTIONS=(bluefin bluefin-dx $IMAGE_NAME cancel)`. This will ensure the installed image is always an option to rebase back to an older version. _Originally posted by @dukrous in https://github.com/ublue-os/bluefin/issues/3018#issuecomment-3199058614_

We refer to these files from the <https://github.com/ublue-os/packages> repo on the <https://github.com/projectbluefin/iso> repo Sister PR: https://github.com/projectbluefin/iso/pull/11

### Describe the bug Launching an AppImage brings up the Disk Imager, dropping the user into somewhat dangerous waters. This behavior should be broken.. <img width="1374" height="924" alt="Image" src="https://github.com/user-attachments/assets/2f8f2186-bea9-46b9-8493-b40790e786b3" /> ### What did you expect to happen? I'm not sure what should happen when I double-click an AppImage, but I bet the current behavior is surprising to everyone. ### Output of `bootc status` ```shell ``` ### Output of `groups` ```shell ``` ### Extra information or context _No response_

The steps are disabled currently due to an issue with Syft using more memory than is available on our runners. See https://github.com/anchore/syft/issues/3800.

## Summary - Add NewsFlash to system Flatpaks with preinstall protection - Ship OPML configuration with Bluefin Discourse news + GitHub releases feeds - Add build validation tests for required files ## Dependency **Requires ublue-os/Logomenu#19** to add the "News..." menu item to the logo menu. Once that PR is merged, I'll update this PR to include the submodule reference. ## Current Status - ✅ NewsFlash added to system flatpaks - ✅ Preinstall protection (prevents auto-removal) - ✅ OPML file shipped at `/usr/share/ublue-os/newsflash/bluefin-feeds.opml` - ✅ Build tests added - ⏳ Logo menu "News..." item (waiting on Logomenu PR) ## User Experience 1. NewsFlash is pre-installed on all Bluefin systems 2. Users can import Bluefin feeds via File > Import OPML in NewsFlash 3. (After Logomenu PR) Users can click "News..." in logo menu to launch NewsFlash ## Questions for Maintainers See my comment on #1485 - waiting for clarification on whether manual OPML import is acceptable or if auto-configuration is expected. Closes #1485

We should copy the pattern from bluefin and make the GNOME extensions follow a submodule setup with renovate. This has to be done per image so that we can follow the GNOME version in CentOS, which is currently upgrading to GNOME 49, it doesn't make sense to grab these from packages.

https://github.com/ublue-os/aurora/issues/1470 https://coreos.github.io/rpm-ostree/build-chunked-oci/ https://gitlab.com/fedora/bootc/base-images/-/blob/main/bootc-base-imagectl we need the hacky sysusers workaround to get off of the hhd/rechunker If we don't do this we may get users with blackscreens -> no sddm group/user -> no SDDM - [ ] test rechunker fix on as much systems as possible - [ ] ~~filter non-rpm content (mostly our stuff anyway) put it in it's own layer~~ Don't bother for now, reasons listed here: https://github.com/ublue-os/aurora/issues/1470 - [x] implement a workaround for [this podman bug](https://github.com/containers/podman/issues/27796), We need a super recent podman version for this as older versions don't push the annotations at all and newer ones push them if the registry already has the layer present, just use podman from brew HAHA - [x] pull old production image (rpm-ostree rechunked) before rechunking so we don't unnecessarily reshuffle layers, resulting in sometimes re-downloading layers, this old image has to have the same ref as the new rechunked target image - [ ] https://github.com/get-aurora-dev/aurora-test/issues/1

## Summary Adds automatic wallpaper switching based on hemisphere location detection using GeoClue. The wallpaper changes based on whether you're in the northern or southern hemisphere. **This PR continues the work from #2661** - all credit goes to: - **@dae3** - Original implementation - **@m2Giles** - Hook script improvements The original PR was approved (lgtm) but stalled waiting on feedback. This PR addresses @castrojo's feedback by removing the unnecessary `.desktop` file since the feature runs automatically via systemd timer. ## Changes - Adds `bluefin-dynamic-wallpaper` script that detects hemisphere via GeoClue - Adds `get-geoclue-latitude.py` helper for location detection - Adds systemd service and timer (runs daily + 1 min after boot) - Adds user setup hook to enable the service - **Removes `.desktop` file** - not needed since feature is automated ## Test plan - [ ] Verify systemd timer activates after boot - [ ] Verify wallpaper changes based on detected hemisphere - [ ] Verify graceful handling when location services unavailable Closes #1594 Supersedes #2661

This new brew version also includes those 2 changes: https://github.com/ublue-os/brew/pull/2 https://github.com/ublue-os/brew/pull/1 Brew binaries have less priority than system binaries now. This will also make our image update deltas 120MiB bigger as hhd/rechunker doesn't handle non-RPM content at all, unlike the rpm-ostree compose build-chunked-oci. It's gonna suck until the blockers are resolved for this to be properly handled. https://github.com/ublue-os/brew <!-- ## Thank you for contributing to the Universal Blue project! Please [read the Contributor's Guide](https://docs.projectbluefin.io/contributing) before submitting a pull request. -->

From ki in discord and modified by me a bit. We can tweak the final wording later: - Getting Started - Welcome to Bluefin - Which Bluefin is right for you?^ - Installation - Frequently Asked Questions - Get Your Apps - Flathub & Bazaar - Command Line & Brew - Gaming - GNOME Extensions - Develop in Bluefin - Developer Mode - Devcontainers Quickstart Guide - GDX for CUDA Machines - AI and Machine Learning - bluefin-cli Everywhere - Explore Further - Values and Mission - Dinosaurs - Music - Tips and Tricks - Recycle Your T2 Macs - Downloads - Driver Versions - Analytics - Press Kit - Connect with Bluefin^^ - Contributing - Code of Conduct - Contributor's Guide - Build Locally - ISO Testing - Donations & Credits - Contributors - Projects ^regular vs LTS vs distroless.., release cadence, link to -dx & -gdx pages. Reducing needs for a dedicated Bluefin LTS page, but it could be easily inserted in Explore Further section ^^ formerly Communication Channels - this could just be a part in Installation/Introduction though, plus all links were on the footer already Some things to add here: - We _must_ preserve the old URLs, server side redirects aren't possible with githubpages so we may need to use [plugin-client-redirects](https://docusaurus.io/docs/api/plugins/@docusaurus/plugin-client-redirects) - This will involve splitting some pages so it might be worth moving the common sense ones first.