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 }}
X
ADon'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
BI can't figure out how to give the user sudo access inside the container
EThis is why Nvidia 37 is failing. Asus Linux Copr dropped 37
https://copr.fedorainfracloud.org/coprs/lukenukem/asus-linux/
https://copr.fedorainfracloud.org/coprs/lukenukem/asus-linux/
Jwhat's in there that we use?
Joh, that thing, sorry I'm on mobile
Jcan we skip that build just for 37?
EI think just supergfxctl
EWe can skip it
EOr I can rebuild it and add 37 back
JI don't know how the nvidia repo works, was hoping we had sections in in main's packages.json
Jso we could exclude it for 37
Jbut whatever works, it's been three days so whatever gets them green so it unblocks you for bazzite
EWe don't have that. These packages get installed via install.sh by invoking rpm-ostree
Jah ok
EIn that case, can I get a supergfxctl project created on Copr? I'll build supergfxctl, the plasmoid, and GNOME shell extension out of that
Jyeah that's probably the best long term plan
EAwesome. Thank you!
J"do the kyle"
ELol
