Syea
EOkay
Salso
Scould you help with this? https://discord.com/channels/1072614816579063828/1084120222400774325/1134140475272605716
XI was thinking for the system76-scheduler service, does that need to be layered or can it instead run inside a container and by passing through the host dbus socket?
KI haven't tried, but applications like btop work great in a container
Kit's fairly likely it'd work fine
Xit seems to work if I pass
/run/dbus/system_bus_socket into the container, although I had to create /etc/dbus-1/system.d/com.system76.Scheduler.conf on the host firstKvery nice
Bthat's pretty cool
KGitHub
Reduce the amount of layers by keeping RUN and COPY to a minimum
Kwould love some extra eyes on this, big change from how we were doing things and I'm only going off what I've read so far regarding layer count & size
JI don't know enough to know other than I am very interested in the resulting difference
KBefore (Saving this for when I can get an after)
message.txt5.45KB
KLayers data for this
message.txt16.93KB
RWhen proper support for handling the OCI layers is implemented in whatever package, wouldn't you want to have multiple layers so you're only pulling the changed layers, rather than everything?
E.g. pulling the 20MB for that added package rather than all 3GB of the image each day
E.g. pulling the 20MB for that added package rather than all 3GB of the image each day
Kthere an issue for this?
Kmuch prefer that
GI'd check out bootc
GIdk if they will do it there but that's the future of ostree native containers
RThe closest I could find:
https://github.com/coreos/rpm-ostree/issues/4012
But I think it's already partially implemented already.
If you add a new package now in a RUN statement at the end of the Containerfile and run
If you bundled all package installs together, you will have to download the entire layer/chunk containing not only your change, but all other packages installed in that layer.
I seem to remember there was some talk about how to handle this better since daily updates (updates in the base image) require the full 3gb or so to be downloaded
https://github.com/coreos/rpm-ostree/issues/4012
But I think it's already partially implemented already.
If you add a new package now in a RUN statement at the end of the Containerfile and run
rpm-ostree update, you will have a single small chunk/layer to download.If you bundled all package installs together, you will have to download the entire layer/chunk containing not only your change, but all other packages installed in that layer.
I seem to remember there was some talk about how to handle this better since daily updates (updates in the base image) require the full 3gb or so to be downloaded
GitHub
Today, the algorithm backing rpm-ostree compose container-encapsulate (and rpm-ostree compose image) is pretty simplistic. It basically tries to stick the largest RPMs in layers, and then "spi...
Kyeah, right now most updates are 1.5GB which is just massive for the changes being made
Kthat's with it split up though
RI guess that's after the daily rebuilds? Where the base is changed and therefore all subsequent steps have changed - meaning you must download all layers after the changed bit.
I thought there was an issue somewhere about how to prevent this upstream, but couldn't find it
I thought there was an issue somewhere about how to prevent this upstream, but couldn't find it
RI might be wrong with all of this. I'm going off best practices for building images for K8s, which is quite different to what we're doing with bootc or whatever.
J@Gerblesh did you ever figure anything else more about this selinux issue? https://github.com/ublue-os/main/issues/223 i bothered two incorrect upstreams, so i appreciate you filing the issue 
GitHub
this issue is detailing the repeated problems we had with greetd and SELinux in the discord, don't know if this will ever be solved or if it can be solved but it's good to have it as an iss...
GNot really
AThe last error message in that issue can probably be worked around by specifiying the full selinux label the file should have
AThis is probably a bug in rpm-ostree ultimately because the rpm package has the correct things set 
GIt works when layering in a booted image
GBut not when layering in the image
Ji feel like i layered it initially and still had a problem, perhaps i'm misremembering
Jalso tuigreet package maintainer said it wasn't a problem on his Sericea system, so that makes me think it's not an rpm-ostree issue
AWe should try having a minimum verified compilable/runnable example
Aif we do like:
ADoes it have the right label or not?
AIf we do
rpm-ostree install -y greetd does it work ok or not?J
Jyields system_u:object_r:container_file_t:s0:c119,c174. seems wrong, but i don't know what i'm talking about on this.
AIt is wrong indeed
Acontainer_file_t is the default label for files created by a container
AAsystem_u:object_r:xdm_exec_t,s0
Shey? when updating my distrobox fedora 39 container it says: Unpack error: shadow-utils-2:4.13-8.fc39.x86_64 and in the logs its cpio: cap_set_file failed - No data available
Jright, well i suppose we have our reproducer then
ACould you try
rpm -E '%{with selinux}' inside the container?AI’m looking at different ways that this could be skipped
AIf that commands prints 0 then that could be the reason
Jit does print 0
ACould you try on your fedora system? It should print 1
