BRight. There is still an F38 nokmods image published, but now nokmods is just the default state for F39 but doesn’t have that tag
Jyeah, just trying to understand what's happening there
KLooks to me like they re-based to f39 no kmods when we were still in the middle of setting it up
KAnd then got left behind because that wasn't the direction we decided to go for 39 builds
Jyeah that's my line of thinking too
BThat’s what I’d guess too
BActually they pretty much say they in their follow up comment
Di've added more to this
Dcan someone please rerun the build for my pull request? I think I fixed the syntax https://github.com/ublue-os/config/pull/161
CCNvidia 545 for F39 appears to be up
Edit: at least two of y'all beat me to it. Good to see
Edit: at least two of y'all beat me to it. Good to see
JGitHub
Build every commit into main into
https://copr.fedorainfracloud.org/coprs/g/rhinstaller/Anaconda-webui/
We will use that for cross-project testing (e.g. building ISOs from the main anaconda repo co...
https://copr.fedorainfracloud.org/coprs/g/rhinstaller/Anaconda-webui/
We will use that for cross-project testing (e.g. building ISOs from the main anaconda repo co...
AWhat does this do
Jper commit builds of the anaconda web ui
Dcan someone pls rerun the build to see if my patch works?
DJIt's a holiday weekend in the US
ELooks like 545 isn't quite there yet in spite of showing up on RPM Fusion
EThis needs adjustments for the spec file. I can look into that in a while. I've been pretty busy with family this week
Dwait why does it need adjustments in the spec file?
KIt's built into an rpm
KYou added a new file so the spec that defines the rpm has to be updated
Doh ok
Dthnx
Dyes, that is why I did the PR. I also did it so you can use sudo for things that are installed with nix (default profile only)
Awould it be possible for the surface-specific images to use the refind bootloader instead of grub? refind supports touchscreens, i feel like it'd be a better choice than grub on a tablet
FI think that's hard to implement & requires a lot of maintainance
Aah
Dare the maintainers aware that the bazzite image is five days old?
EYep. Not concerned. Lots of stuff shifted this week
Doh ok. just glad you are aware. I also kept in mimd that the maintainers have life outside of discord and coding.
EIt's all right... I kind of see it like this - even if updates were pushed out only once every two weeks that's still more frequent than a lot of other projects
Dyeah and most of the things that get updated when new images are built are from upstream
DI just need one more person to approve this then it will be ready to merge
Tis there more to this issue that's being done elsewhere? https://github.com/ublue-os/bazzite/issues/237
I ran into this, and manage to rollback a pinned deploy but I'm not sure if the process is a bug or not in ostree or rpm-ostree, because it doesn't make sense and it's not documented AFAICT?
I ran into this, and manage to rollback a pinned deploy but I'm not sure if the process is a bug or not in ostree or rpm-ostree, because it doesn't make sense and it's not documented AFAICT?
Jwhat's the problem?
Bthat is because of the kargs
Bbooted images, setting kargs new image, and normal you only have two, current and rollback. so any non pinned deployment will roll of
Ti rebased to bazzite, it did a second deploy such that a simple 'rpm-ostree rollback' would not have rolled back to my previous deploy that i was at when I rebased
Tyes, the kargs
Tbazzite rebooted with this:
Initramfs: '-I /etc/crypttab /etc/modprobe.d/amdgpu.conf'Byeah so to rollback you can not use rollback, but need todo a rebase instead
Bat least not in the case where kargs have been set
TI ended up doing
ostree admin deploy <commit_id> where commit_id matched the pinned deployment , but I still needed to do a rollbackBpinned deployments are in grub aren't they?
Boh i see
Tyes. I was apprehensive about booting into it with grub because I read that it would only be a temporary fix
