* docs(akmods): Add notice when builds are failing due to upstream issue
* chore: add missing "a"
---------
Co-authored-by: xyny <60004820+xynydev@users.noreply.github.com>
* chore(default-flatpaks): Switch to standardized BlueBuild location
Use
`/usr/etc/bluebuild/default-flatpaks`
location instead of
`/usr/etc/flatpaks`
If possible, we should ideally use this location for system modifications:
`/usr/share/bluebuild/default-flatpaks`
While having user modifications in:
`/usr/etc/bluebuild/default-flatpaks`
But it needs to be figured out how the logic will work for separating system & user modifications this way.
I used this logic in unofficial `initramfs-setup` module & it works well, by merging both system & user files into 1 output.
However, this method can create duplicates if user specified it in it's modification, so I mentioned that user should look if the system entry has modifications they need. Perhaps, array diff can be done, which would circumvent this.
So merge this for start.
Only other module which has potential for migrating to standardized BlueBuild config is yafti (more details in other PR I'll do in some time).
* refactor(default-flatpaks): Make default-flatpaks more robust
Document in detail to user how he can change the config in files itself.
Also document what files do in `/usr/share/bluebuild/default-flatpaks` as well.
Refactor flatpak lists detection to be more reliable by excluding words starting with # symbols, whitelines & duplicate entries. Use `comm` for comparing flatpak list to existing flatpaks output instead of using `grep`, as it's easier to use & it's more reliable.
Separate user's & maintainer's modifications better by utilizing read-only `/usr/share/bluebuild/default-flatpaks` directory for maintainers, while for users we would use `(/usr)/etc/bluebuild/default-flatpaks` directory. Reverting to defaults is more reliable as it would avoid users from touching maintainer's modification directly.
I wouldn't modify repo-info.yml doc content, as we restrict it from user's modification & we wouldn't want to potentially ruin yaml parsing just for that.
Only thing that remains is to test this in a VM. And look to potentially make code cleaner.
* draft(default-flatpaks): Avoid install/remove duplicate loop scenario
I have to figure out this part
* draft(default-flatpaks): Avoid install/remove duplicate loop scenario pt.2
* draft(default-flatpaks): Avoid install/remove duplicate loop scenario pt.3
* fix(default-flatpaks): Avoid install/remove duplicate loop scenario
* chore(default-flatpaks): minor grammar adjustment
* draft(default-flatpaks): Account for scenario...
when user sets the same package in install list that is in maintainer's remove list & vice-versa
* fix(default-flatpaks): Account for scenario when user sets the same package in install list that is in maintainer's remove list & vice-versa
* fix(default-flatpaks): Typo in code for combined install list
* chore(default-flatpaks): Remove unnecessary echo
* chore(default-flatpaks): Make directory for user config
* chore(default-flatpaks): Explain user's vs maintainer's flatpak list situation better
* fix(default-flatpaks): Typo in user's configuration for system flatpaks install
* chore(default-flatpaks): There is no need to mkdir parent folder if child folder is created
* chore(default-flatpaks): Make config organization cleaner
Don't use echos for writing configs, use files instead for easier & more intuitive editing.
* fix(default-flatpaks): Copy notification file properly
Made a mistake in variable name
* docs: README fixes
- don't use ambiguous term "live-user"
- capitalize Flatpak
- grammar and phrasing changes
* docs: grammar and phrasing changes in configuration file docs
- replace "maintainer's config" with "image's default config"
- rewrite flatpak list format explanation
* docs: slightly reword local modification section again
* chore(default-flatpaks): Add a missing newline to system flatpak list
---------
Co-authored-by: xynydev
* chore(gschema-overrides): Get rid of `files` module dependency
Gschema.override files are now placed in /config/gschema-override folder.
* chore(gschema-overrides): Don't use 1st slash for new override location in docs
* chore: Use `zz1-` prefix instead of `z1-`
It ensures that no gschema override will bypass user one with override starting with letter z.
* fix(files): Fix build error on copying dotfiles
Enable dotglob when copying folders/files, disable when it's finished.
* chore(files): Ensure that dotglob is executed outside of loop
* fix(files): Ensure that .gitkeep file is not present in the build image
* fix(files): Ensure that cp command ignores if something is present in directory or not
* feat: signing module
* docs: add docs for `signing` module
* fix(signing.sh): add space to if
Co-authored-by: Gerald Pinder <gmpinder@gmail.com>
* fix(signing): grammar in README and formatting in signing.sh
* fix: only modify image-info.json
* fix: typo in image vendor name
---------
Co-authored-by: Gerald Pinder <gmpinder@gmail.com>
* feat: Add `gschema-overrides` module
* chore: Clarify "including prefix" section better
* chore: Some formatting fix
* chore: Don't mention higher prefix, as it can confuse users
* fix: Add partial troubleshooting of most preferred gschema-overide
It does not support aborting on fail currently, as I have to think on how to implement it when multiple gschema-override files are included in the module.
* Revert "fix: Add partial troubleshooting of most preferred gschema-overide"
This reverts commit 1dde51938e45648c7f53b696e61249339a2eb277.
* fix: Use `z1-` prefix for to avoid future conflict with Universal Blue images
* chore: Fix some README remarks from xynydev
* chore: Note that GTK DEs other than Gnome are also supported
* chore: Be more specific about GTK-based DEs
* chore: Clarify using module section a tiny bit better
* chore: Add editing gschema.overrides section & make README formatting cleaner
* chore: Reword some sentences better
* fix: don't use multiple toplevel headings, replace <br> tags with spammed spaces
---------
Co-authored-by: xyny <60004820+xynydev@users.noreply.github.com>
* feat(default-flatpaks): Support for notifications that inform the user before flatpak install/uninstall procedure begins
This can be implemented to be more readable maybe, but this should work.
* chore(default-flatpaks): There is no need to call notifications true statement twice
* chore(default-flatpaks): Make starting notifications consistent with finished ones
* chore(default-flatpaks): Use "listed" term rather than "some"
* chore(default-flatpaks): Use "some" notification only for uninstalling flatpaks
- i just noticed this is where the container tools for the container tools bling were coming from, but i already removed that...
- ig this wasn't the only place to get container tools
- the devpod bin wasn't used anywhere either and was locked to a specific version (that no-one maintained to update)
