This helper was removed in 1password 8.10.28.
I've managed to deploy this script onto my ublue-derived system, and 1password system auth and browser integration works great.
* chore: cleanup build.yml run conditions
- run on all branches
- no need to run on schedule, since there's nothing external pulled in the image build
* chore: change workflow name
* fix: tag non-main-branch builds correctly
* docs: yafti module explain what yafti is
* ci: fix globs in website rebuild action
* ci: only rebuild website if in official module repository
* ci: fix globs being invalid yaml
* Revert "docs: yafti module explain what yafti is"
This reverts commit 7d5295cd9f9ea7d0f6a45ce227da6d699973cf2f.
* feat(systemd): Add support for including systemd units
This also gets rid of `files` module dependency & exposes this function better to the users.
Related issue:
https://github.com/ublue-os/bling/issues/143
* fix(systemd): Make included systemd unit check better
It doesn't fail now if there is systemd folder present without any files.
* chore(systemd): Code spacing fixes
* chore(systemd): Disable dotglob, as it's not needed for systemd units
* docs(systemd): Remove inclusion term
* chore: update file readme
* fix: broken link due to bad markdown formatting
---------
Co-authored-by: xyny <60004820+xynydev@users.noreply.github.com>
It is no longer needed, since get_yaml_array uses `readarray -t` command
now instead of regular `readarray`.
It may also fix rare parsing issue some user had (array element looks
fine, but it's still not parsed properly).
Note that this is a speculated issue, not something we're 100% sure of.
Merge this after BlueBuild transition period, since legacy build.sh
doesn't have get_yaml_array fix.
Alternatively, I can define custom get_yaml_array function here, with
note for supporting legacy templates.
It is no longer needed, since get_yaml_array uses `readarray -t` command now instead of regular `readarray`.
It may also fix rare parsing issue some user had (array element looks fine, but it's still not parsed properly). Note that this is a speculated issue, not something we're 100% sure of.
Merge this after BlueBuild transition period, since legacy build.sh doesn't have get_yaml_array fix.
Alternatively, I can define custom get_yaml_array function here, with note for supporting legacy templates.
* 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
