maybe they just reduced the root partition from 40gb to 20gb literally, thinking that 1 image won't
maybe they just reduced the root partition from 40gb to 20gb literally, thinking that 1 image won't take more than 10GB?
Athats not what the blog says but thats the only way it works
Goh I can just use
matrix.versionAyup
FLVM doesn't have any relation to this in this case
SHaven't read the blog tbh as Vanilla really doesn't interest me I'm happy where I am with bluefin/kinoite no reason for me to change lol
Galr I'll squash everything and move it out of draft
Ai also think that
Amaybe it breaks in a few months once their image hits 10GB
Splus i find A/B root really offputting, it's worse than trusting BTRFS snapshots like Opensuse uses
Abazzite used to be 12gb so they have a way to go
Athey're probably like 6-7gb
SI do wonder at times if I should save some money and get a multidisk server again to try things like this with LVMRaid/Linuxmd and see how long it takes to totally tear itself to bits lol
FDon't like dosubot closing issues just because they are not active for some time
Most of those automatically closed issues are still related to the project
Most of those automatically closed issues are still related to the project
SSurely you can turn that off though cant you?
SOr is this another "feature not a bug" thing lol
FUblue folks can turn it off, but they turned it on in the 1st place lol
FIt's to manage issues which are low priority & close them
Soh right... erm don't know what to say then
FI just prefer to tag them automatically as low-priority instead & close unrelated issues manually
SWell that would seem a better way of doing it, but I guess with all the other work they already do it may get a bit time consuming?
Fprobably
Jremove the stale tag
FCan do that only for issues which I created
Fnot for all other issues
Jwhich ones do you need reopened?
Fsome issues in main related to useful packages, like python3-validity
Fbut you probably manage issues differently than I do
Fso no strict need
JI mean, it's been sitting for over 90 days and no one PRed it in?
Fno.
Joh it's not in a repo
Pi think it's only i copr
Jyeah, stalebot working as intended, if no one is working on a thing and no one's stepped up then we close
MYeah I unstale or reopen somethings that should not be closed yet.
But there's issues that have been long solved still open and/or ones that weren't our bug
But there's issues that have been long solved still open and/or ones that weren't our bug
Jyeah when you see the 7 day warning pop off, that means "action needed" to me
Jand it's not like the issue is deleted forever, full search is always there
Ghttps://github.com/ublue-os/cosmic/pull/54
I don't see any glaring issues anymore if anyone wants to take a look
I don't see any glaring issues anymore if anyone wants to take a look
GitHub
This PR adds rechunk for reducing image size and fixing existing SELinux issues. Rechunk is very much experimental so I'll continue to test over in: https://github.com/gerblesh/cosmic-rechu...
J
J@Kyle Gospo let's go
MOn Day 2 and haven't seen anything yet that wasn't already caught.
For cosmic, may want to include nmtui since the network manager setting is extremely unfeatured. Everything can be done from nmcli, but nmtui is a little more convenient once things are configured but not exposed graphically by cosmic
For cosmic, may want to include nmtui since the network manager setting is extremely unfeatured. Everything can be done from nmcli, but nmtui is a little more convenient once things are configured but not exposed graphically by cosmic
GAnother thing I'm curious about is the cosmic store, does it work on the cosmic image without rechunk?
GAh OK looks like the store is just broken for now
Gadded nmtui to the PR
Xthis sounds like you're waiting for someone to shill 'my' project: https://blue-build.org/
well, it's not exactly what you want, maybe. you still can't manage disk partitioning, hostnames, etc. in a native container image, since you're building a 'base OS' and not a whole installation like with NixOS.
well, it's not exactly what you want, maybe. you still can't manage disk partitioning, hostnames, etc. in a native container image, since you're building a 'base OS' and not a whole installation like with NixOS.
QSomeone did mention that in general, and there was some discussion there. Some of what I need really is improvements in anaconda or similar. Some is covered by blue-build, and I made some suggestions for possible modules of interest.
Xyou talked about some way to include secrets. we've had tangential discussion recently and you can read more there, but the gist is that the container images are usually published to ghcr.io and are thus public, including secrets in it would not be secure. the images are made such that multiple users could use them (though some personal images definitely stretch that). you might want to sacrifice the thinking that everything (including secrets) would be managed by a single system. you can still technically use home-manager on other atomic systems, and there are other good ways to manage and sync secrets locally too AFAIK.
QI think sops-nix actually hits the sweet spot here. You use a standard tool for secret management (sops) to write encrypted files that can be published publicly, but can only be decrypted on a host using a specific non-published secret (host ssh key most commonly, but something via vault, 1password, etc could also be used). A systemd service does the decryption during boot and writes to somewhere in /run so they're not ever persisted to disk.
Xsounds nice, i'll look into that
MHaven't tried the pop shop out recently
