[01:47] PR snapcraft#3945 closed: requirements: craft-store 2.3.0 for new credentials [09:05] do the packages on snap get added only on release time or can be added before a new release is done? [10:32] PR snapd#12246 opened: tests: add encrypted fakeinstaller spread test [12:27] Bug #1992240 opened: Can't initialize on Raspberry Pi Compute Module 4 [12:51] Bug #1992240 changed: Can't initialize on Raspberry Pi Compute Module 4 [12:54] Bug #1992240 opened: Can't initialize on Raspberry Pi Compute Module 4 [12:56] Are seeds documented anywhere? [12:56] I'm trying to figure out how to safely remove things from /var/lib/snapd/seed [13:07] vancz, probably in the code in livecd-rootfs [13:09] I don't know my way around this infrastructure at all, what am I looking for? [13:09] I thought seeds are a snap thing? or are they only important when an image is first created? [13:09] do they just assume youll leave a gig of all your old seeds around forever? [13:13] ?? [13:13] on a desktop install snap keeps exactly 2 revisions of each snap [13:15] though the seed directory is for initial seeding i think ... and gets copied 1:1 from the install media [13:16] ok thats roughly what I guessed so far [13:16] I did see mentions of deleting old revisions [13:16] does that also apply to the seed directory? [13:17] lets take a step back ... what exactly do you want to achieve and why ? whats your goal [13:17] meanwhile, im poking around the source [13:17] my goal is to remove gnome and firefox from the seed directory to decrease space usage so I can fit the system in RAM [13:18] well, then you'd need to build an image from scratch and modify livecd-rootfs first i think [13:18] without reinstalling [13:18] ?? [13:18] this is an installed system [13:18] and you want to fit that into ram ? how [13:19] its not _that_ big (yet) [13:19] note that not even the live images "fit the raw system in ram" [13:19] the usage is around 12 gigs right now, I can definitely shave a few more off [13:19] it ias all compressed squashfses ... [13:20] this should really have been a server install but whoever installed the system *shrug* [13:21] ok, and that implies...? it ias all compressed squashfses ... [13:21] that the rootfs is massively smaller than what you currently try to fit into ram [13:22] I think I'm not understanding you [13:22] a higly compressed squashfs can shrink the whole thing to 1/3 of its original size ... depending on the chosen copression [13:22] you'd simply never put a raw ext4 rootfs into ram [13:22] ok, so my plan is to do weird hacks and I'm not sure I can squeeze in a squashfs layer [13:22] this isnt a long term thing but an intermediate step [13:23] why exactl do you want to put it into rm in the first place ? [13:23] *ram [13:23] * ogra needs a new laptop kbd 😞 [13:23] gonna try to live migrate to zfs :D [13:24] (testing if its even feasible on a local vm first anywaY) [13:24] well, do that from an initrd shell [13:24] I dont want to reboot [13:24] lol [13:24] you will have to reboot at some point ... likely quite a few times [13:25] If I end up having to reboot im not sure ill be able to get it to come up again without someone having to intervene. i plan to test the disk with the running system on a read only root and run a full boot in a vm and reboot once that succeeds [13:25] i'd not waste that much time, a re-install of -server with zfs support would already be done since you asked first above [13:25] something like taht [13:25] yeah this is a stupid weekend project, i dont have access to the adminstrative interface of the cm [13:25] * vm [13:26] it is also likely to fail (r at least to result in an unexpectsd and unstable setup) [13:26] hence local testing [13:26] but anyway [13:26] anyway ... sudo apt purge snapd ... [13:27] haha [13:27] and afterwards you can remove the seed dir [13:27] well Id love to but im running a service on a snap [13:27] later just re-install snapd and the firefox and lxd snaps [13:27] gitea was easy enough to install [13:27] or can i export it or something and just add it back once ive done the reinstall of snapd? [13:27] snap help save [13:27] cool thanks, ill take a look at that [13:28] and snap help restore indeed 🙂 [13:28] snaps have builtin backups [13:29] yeah there is some nice stuff here and there [13:29] yup 🙂 [13:29] i wish i could have nixos with all the work in ubuntu and debian [13:29] is it save to try to find a way to remove the stuff in /usr/lib/x86_64-linux-gnu/dri ? if im not using graphics I expect I dont need that? [13:30] (not a snap issue ofc) [13:30] wait these are almost all the same size..wonder if its a bunch of hardlinks to something [13:31] removing files underneath the packagin system is always very risky in deb based systems ... bu you can use "apt-file search ..." to find the package names for files you delete temporary and use "apt install --reinstall ... " to reinstal the package later [13:31] (or simply remove the packages instead of the files) [13:32] ok thanks [13:32] just removing files obviously pulls out the carpet underneath the package db (which keeps track of every packaged file) [13:32] yeah i meant removing the packages I just dont know which they correspond to [13:32] but the search will help with that [13:32] yep [13:32] apt-file is your friend [13:33] the other half of the question was "do i need these drivers" [13:33] note though that some dri bits might be used for console output in the new kms based world [13:33] unless that breaks boot, i expect ssh should still work though [13:35] they have different inode numbers but they are literally the same files, I wonder if I'm missing something [13:36] so this directory is reported as using a gig, but is it actually? [13:37] $ du -hcs /usr/lib/x86_64-linux-gnu/dri [13:37] 90M /usr/lib/x86_64-linux-gnu/dri [13:37] not here [13:38] youre right, i wasnt reading carefully, its actually 384mb here [13:39] wow, still a lot more than it should be [13:39] https://bpa.st/7LCQ [13:39] on my other (desktop) machine it is 61MB [13:41] you seem to have a lt more drivers there than i got on my default desktop installs [13:41] yeah I have no idea [13:41] im waiting for apt then ill search them all to make sure they all come from libgl1-mesa-dri [13:41] that was the package for one of them [13:42] where do yours come from? [13:42] dunno, havent checked [13:43] ok about five are from libgl1-amber-dri [13:45] might be able to get rid of these https://bpa.st/EVPQ [13:45] also i guess this isnt the kernel component either so it shouldnt result in graphics problems? [13:46] for file in /usr/lib/x86_64-linux-gnu/dri/*; do apt-file search $file; done | sed 's/: .*$//'|sort|uniq [13:46] https://termbin.com/4cpp [13:46] yeah thats what I did [13:46] these are the ones installed here [13:46] hi, I thought this is the best place to ask. Why snap is using keyword "refresh" instead of "update" to actually update it's packages? Everything else is using... update, upgrade or something similar. it's kind of counter intuitive. What was the reasoning behind this decision? [13:47] lolek, because canonicals CTO felt it was the better term 😛 [13:47] ogra: weird, looks like you even have a superser of what i do [13:47] *superset [13:47] so the logic was like "hey, let's make it the most confusing tool people has to use"? [13:48] *will need [13:48] lolek, well, i think the logic was "lets make it distinct from the other tools to indicate it is different" [13:48] start a thread on forum.snapcraft.io to discuss it though ... [13:50] lolek, also i think the idea was that "snap refresh" should hint towards "snap revert" since these two go hand in hand together [13:50] well for me snap itself and they way it works is totally frustrating... and using different word for update doesn't make things any better [13:52] right, as i said, feel free to open a forum topic ... that way more people will actually see it ... [14:05] ogra: do you know what snaps like core20 and core18 are? [14:05] well, I seem to have purged the dri directory [14:07] hm, guess I cant get rid of llvm, postgres seems to depend on it [14:08] core snaps are the bases the other snaps run on top [14:08] i.e. your execution environment to run snaps at all [14:11] ok so its not ubuntu itself, good :pű [14:11] * :P [14:11] lets see if the whole thing doesnt break after this autoremove (lots of graphical stuff) [14:12] will purging snapd not delete the snapshots dir? [14:15] you should indeed capture the arballs from it, yeah [14:15] *tarballs [14:21] ok, doing that now [14:24] ogra: ok, I've backed up and saved the backup of the one snap service im running, I just apt remove --purge snapd? [14:28] disk usage down from 11g to 8 :p [14:32] ogra: ok how do I deal with this?: [14:32] # snap install gitea --revision 6097 [14:32] error: cannot install "gitea": Access by specifying a revision is not allowed for this Snap. [14:32] I want to install the revision the backup is for [14:39] ogra: coincidentally if you give apt-file search a directory it will to it for all the files in it [15:07] ogra: I have an old kernel version installed but I dont see its package, any idea why?: apt-file search /usr/lib/modules/5.15.0-47-generic/kernel/drivers/thunderbolt/thunderbolt.ko doesnt output anything [20:19] PR snapd#12223 closed: many: add support for setting up encryption from installer