Show do you like deploy those justfiles?
Slike
MYou can run just -l to force list recipes
Xwhat do you mean?
Slike could you give your custom justfiles?
Slike the custom.just
Xmain.just is from the main image, nvidia.just is from the nvidia image, custom.just is from startingpoint
Xcustom.just includes bling.just https://github.com/ublue-os/startingpoint/blob/template/usr/share/ublue-os/just/custom.just
Xwhich includes lots of bling justfiles
Sah ok thanks :3
XI'm trying to create an ISO release action for startingpoint based on the examples in isogenerator, release_please, and main, but I can't really figure out how it should work.
Xrelease-please creates a "release PR" that creates a changelog with the commits, but doesn't actually then create a release, and build-iso is skipped because a release wasn't created...
ARelease please will create a release after the release PR has been merged not before
ALet me know if I can help you somehow 
XI did merge it on my testing repo and nothing happened
XWell, you can either cook up a PR for this one or help me figure it out
XThis is the worflow rn https://github.com/EinoHR/linuXYZ/blob/iso/.github/workflows/release-iso.yml
AIt is working?
XOk, I ran it again and apparently it is working now.
XIs the workflow like: run action once, PR gets created, rerun, release gets created, ISO built
AYes
AOn normal commits it will detect changes and add it to the release PR
AWhen you merge that one then the release gets created
XSo the release PR should always exist and then when merged the release action should be ran again to release and create the new PR?
AYes
AActually it will only create the PR on the next commit after it creates a release
ANormal commit -> add to release PR or create one if not exists
Release commit -> create release and trigger iso build
Release commit -> create release and trigger iso build
XSo is there something I should change in the PR to make it do all that automatically so I don't need to workflow_dispatch twice every release? Is it possible to make it so the user of the template can just press one button and the release will be made and ISO built?
XFor most people the release-please convcommits stuff does not really matter, since the ISOs always pull the latest version, correct?
XAlso, the recent action run failed but I'm unable to see what the error is. Or rather; It's a python runtime error in isogenerator, and I don't know what caused it. My understanding is that not providing a boot menu should just use the one in the isogenerator repo, and other than that it's basically the example with the ublue-os org related things replaced with ${{ github.repository_owner }}
XADon't use release please if this is the net result you want imo
ANo you need to provide a boot_menu.yml
AOr maybe that changed 
let me check
let me checkAYeah it is required
XOk
AThat's a very ugly error message huh
XHmm, well, it is useful for some situations, but is there something you recommend instead?
Arelease-please requires understanding git tagging as it is supposed to overtake the entire release process basically
AIf you want a simple "click here to create release" then I think you could just do a workflow with the gh cli
XWell sure. Maybe a short note in the docs that for serious projects you might consider using release_please.
Bany selinux experts here?
Bi layered
podmansh in a bluefin-dx vm, and got it working after some trial and error. The docs (https://docs.podman.io/en/latest/markdown/podmansh.1.html) have some examples, but none of them worked out of the box. I got one working by moving the containerfile into /home/{containeruser}/.config/containers/systemd/podmansh.containerBthe last example on the page says
where the users inside this container are allowed to execute containers with SELinux separation and able to read and write content in the $HOME/data directory. and it gives these arguments: PodmanArgs=--security-opt=unmask=/sys/fs/selinux \
--security-opt=label=nested \
--security-opt=label=user:container_user_u \
--security-opt=label=type:container_user_t \
--security-opt=label=role:container_user_r \
--security-opt=label=level:s0-s0:c0.c1023Blogin fails with this error:
Aug 03 10:04:33 fedora kernel: SELinux: security_context_str_to_sid (container_user_u:object_r:container_file_t:s0-s0:c0.c1023) failed with errno=-22
Aug 03 10:04:33 fedora podman[99965]: 2023-08-03 10:04:33.397114165 -0400 EDT m=+0.138985435 image pull 919a420d29c6f5ae0bdc8d1872387d3a878d7f69debce9e24f3f2e0506b2ba0d registry.fedoraproject.org/fedora
Aug 03 10:04:33 fedora podman[99965]: 2023-08-03 10:04:33.560247123 -0400 EDT m=+0.302118503 container remove 856af025c3595f2ed5c978ad8f98b42b4b0f389d8b2e59f87d080c922db4d203 (image=registry.fedoraproject.org/fedora:latest, name=podmansh, vendor=Fedora Project, version=38, PODMAN_SYSTEMD_UNIT=podmansh.service, license=MIT, name=fedora)
Aug 03 10:04:33 fedora podmansh[99965]: Error: failed to mount shm tmpfs "/var/home/fullu/.local/share/containers/storage/overlay-containers/856af025c3595f2ed5c978ad8f98b42b4b0f389d8b2e59f87d080c922db4d203/userdata/shm": invalid argumentBI suspect the problem is this last line
--security-opt=label=level:s0-s0:c0.c1023
but I don't even know what any of that means.BAny expert help would be appreciated, and of course upstreamed into bluefin
AHave you tried label=disable
Bthat doesn't fail.
Bi'm assuming it also doesn't allow nested confined containers
