Don't use release please if this is the net result you want imo
Don'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
podmanshthe 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
Any 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
JI'm done with my sabbatical and my job will have me on the road a ton, you don't need my permission to fix anything, Just Do It(tm).
JSomeone was sitting next to me and saw my framework with bluefin and was like "what is that?!?!?!"
A
EI really want to get a 16
Jyeah then I fired up a cluster and everyone was like "what?!"
Jme too, i just can't justify it right now
BI wonder if I need to do the podman-system-generator dance?
Bthis issue mentions it
BGitHub
Issue Description I copypasted .container file from podmansh man page but the way I did it, it added some trailing whitespaces and lines containing only whitespaces: [Unit] Description=The podmansh...
AThis is setting the last component of the selinux label which corresponds to the "level" - this is technically only relevant on systems with multi-level security
AFor nested containers you're supposed to be able to do
label=nested - I am not sure why they're manually setting the context to container_t
AYou also need a recent podman version for this to work. I'm currently semi-engaged with upstream troubleshooting some selinux issues in ublue
AThe main issue is that podman mounts the rootfs layer with a
context= flag and this causes the selinux operations to fail because the selinux context is hardcoded by podman and can't be modified in the overlayfs layerAlabel=nested changes this behavior so that the overlayfs will be mounted with
rootcontext= instead which only sets the selinux context of the rootfs inode