How much attention do I have to put in a custom fork of bluefin / aurora?

General
1

Only asking this because I got a pull request from the pull bot and it didn’t get merged automatically after 19 hours(supposedly every few hours it merges any PRs automatically from ublue-os:main). And all I did differently was change packages.json. Any answer is appreciated and thank you for your time

2

Before Aurora started, I started my own personal fork of Bluefin based on Kinoite, with a few extra packages installed and with various things deleted which I didn’t need on my laptop. Because of those deletions, the pull bot would often bring in changes from Bluefin which it couldn’t automatically merge into my fork, and then I’d have to manually resolve merge conflicts. This required me to allocate 10-30 minutes of attention once every few weeks just to resolve merge conflicts, which was kind of annoying.

Now that Aurora is part of the Bluefin repo, I’ve restructured my fork to instead just add a few packages as a layer on top of Aurora instead (i.e. using FROM ghcr.io/ublue-os/aurora-dx for my Containerfile). Even though the upstream image from Aurora includes various things I don’t want (e.g. extra fonts, Solaar, and Ptyxis), I no longer need to think about PRs from the pull bot or about merge conflicts, and it requires no attention from me - and the benefit of that totally outweighs the mild annoyance of living with the extra files/packages I don’t want.

3

Yeah, quick straw poll, should we sunset the pull app instructions and go with just recommending forks instead?

4

So if I don’t change anything, it will pull in changes automatically, and what I can do is add more things on top and it will continue to pull. And when I remove things it stops. Did I get that right?

5

Forking I think only really makes sense if you are making significant changes to the desktop. Our Image Template repo covers the vast majority of custom image use cases (IMHO).

1 Like
6

I’d definitely recommend newcomers to start with the container layering approach (e.g. with Image Template) and only break out the power tool (maintaining a fork) if they find they really have to reverse a decision made in bluefin/bazzite/etc. but they are unable to do so via layering (e.g. restoring any of the packages removed with rpm-ostree by bluefin/bazzite/etc.). For anyone who does have to fork, I think the pull bot is slightly useful as a way to get notifications about upstream changes, but (at least in my workflow with pull bot) I discovered two annoying footguns/hidden-complexities with using the pull bot:

  1. Pull bot only understands merge commits; if I accidentally use rebase-merging or squash-merging to merge a PR from pull bot, pull bot’s next PR is opened as if the previous PR hadn’t been merged. I personally prefer to use squash-merging for feature branches where I’m experimenting, so then I had to remember to switch between the different merge strategies for different PRs in my forked repo.
  2. I tried having a “bluefin-main” branch which pull bot would keep synchronized with ublue-os/bluefin:main, and then have pull bot open PRs from my “bluefin-main” branch into my “main” branch (which was for my custom image). But once a pull bot PR started having merge conflict, I couldn’t merge that PR or make changes on it directly, because it was my “bluefin-main” branch which I was trying to keep pristine with ublue-os/bluefin:main; instead, I had to make a branch off bluefin-main to resolve the merge and make another PR for that new branch to merge into my main branch.

I think that’s roughly right, but I never fully understood pull bot’s behavior either :sweat_smile: . In my experience, pull bot would often wait a while (or sometimes indefinitely? idk) before merging a PR which had no merge conflicts. Once a pull bot PR has a merge conflict then future commits from upstream would continue to be added to the PR, but pull bot would not try to merge the PR. The behavior resets after you merge the PR.

1 Like
7

Does it cover installing a custom kernel and selecting it as default? (asking this because I want to have the cachyos kernel with the eevdf scheduler), if there is a way to do it then it would be awesome if you explain how.

Edit: The kernel exists on copr repo just like the fsync kernel

1 Like
8

Bazzite would be a good resource to see how they do a custom kernel there. Bluefin doesn’t do a custom kernel. We tried to keep the image-template as simple as possible.

We are happy to take contributions in documentation regarding doing a custom kernel if that is something that folks are commonly doing!

1 Like
9

Thanks!, will learn how the custom kernel is done in bazzite, and will try adding the custom kernel

10

Just checking in here. How easy would it be to install the Mullvad VPN RPM in something like Bazzite or Aurora? I may be putting Aurora on my Framework 13 soon. Mullvad VPN for Linux

11

@j0rge - I’m facing the issue that I kept having merge conflicts which I had to manually correct (as described above). Life happens, so now (2 months later) my fork was so off-track, that even though I resolved my merge conflicts, my builds no longer run.

At this point, I might need to restart a new fork and re-add my customizations, which were some COPRs in Containerfile, with corresponding installations in packages.json.

Where are the recommended customizations (as described above) supposed to go? I have not been able to find any updated/relevant documentation for customizations.

12

I started doing this for my personal image but haven’t switched it over yet. Basically instead of forking bluefin and dealing with keeping up with it you’re going to FROM bluefin and then add the packages/mods you want in build.sh. This one should be way more hands off than forking:

1 Like
13

Thank you for the recommendation!

I found it’s helpful, especially since I have done similar actions with the form of bluefin-dx:

  • Add cosign public key to base of repo.
  • Add cosign private key to repo under Settings.
  • Look at what you want your base image to be and set image source and suffix in Containerfile:
    • My example:
      • ARG SOURCE_IMAGE="bluefin-dx"
      • ARG SOURCE_SUFFIX="-nvidia"
      • Set version - I chose GTS for stability: ARG SOURCE_TAG="gts"

After, just start adding the packages you need to build.sh

14

That should be it, if you find anything that can be cleared up let us know (file an issue in the repo) and we can add more detailed to the comments so it’s easier for the next person!