[08:43] <ogra> xnox, the original idea was that (on core) you always keep the originally seeded (or the ferv first version) of a snap around for "factory reset" of the images ... that the three-snaps setup is also used on desktop is because nobody implemented a way to only keep "current and last" instead of "current, last and first" ... there is some TODO somewhere on niemeyers list to fix that, but i think it is super low prio
[08:43] <ogra> s/ferv/very/
[09:17] <ogra> xnox, along with that there is indeed no reason to have any snaps mounted beyond the one in use, but thats also not high prio i guess
[10:51] <xnox> slangasek, so yeah three things make sense "current, rollback to last known, and all the way back to the factory image"
[10:51] <xnox> but as I said, three copies sounds like an "iot-ish" req, rather than desktop/server/cloud. In cloud we can rollback the whole cloud image.
[10:51] <xnox> ogra, also i see 6 things 3xcore 3xcore18, unless i'm doing something really wrong.
[10:52] <xnox> ogra, complaint we have is that it takes too much "space", disk-space for sure, but uncertain re RAM
[10:58] <ogra> xnox, well, the loop mounts shouldnt occupy any ram until you access them i guess ...
[10:58] <ogra> the "limit to two" is a re-occuring request that shows up on the forum every few months but nobody really attacked it yet
[10:59] <xnox> ogra, how do I escalate it then?
[10:59] <ogra> xnox, core18 gets automatically pulled i if a snap that uses 18.04 as base gets installed ... and indeed that core18 again falls under the 3 snaps rule
[10:59] <xnox> Beret is not in this group chat =))))
[11:00] <ogra> well, only gustavo makes the decisions ... forum and being pushy is one way ... another would be to establish a joined meeting with the core team and foundations where you bring up such requests and have them prioritized
[11:01] <xnox> ogra, there is a core sync for years now.
[11:02] <ogra> well, then bring it up there and have some prio applied to it
[11:03] <ogra> you could try a snapd bug and set it to critical or something but i'm not sure how well that would work
[11:16] <xnox> ogra, also, one more thing. on the desktop i see $HOME/snap is used
[11:17] <xnox> ogra, i find that very "servery" and not at all "desktopy", how come e.g. $HOME/.local/snap was not used? which is approximate freedesktop.org equivalent of a global /snap
[11:21] <ogra> xnox, there is an endless bug open about it ... snap packages that do not use any interfaces use $HOME/snap/<snapname>/current/ as their work and home dir ... to make things like downloads or files an app works with discoverable the dir can not be hidden
[11:21] <ogra> bug 1575053
[11:21] <ubottu> bug 1575053 in snapd (Ubuntu) "Please move the "$HOME/snap" directory to a less obtrusive location" [Wishlist,Confirmed] https://launchpad.net/bugs/1575053
[11:23] <ogra> that design pre-dates interfaces, nowadays you can indeed simply use the home interface to have access to the XDG dirs and $HOME so apps can now use this ... when the design was created such interfaces did not exist ...
[11:23] <ogra> and now the migration is rather painful since all snaps use this setup
[11:24] <xnox> fun, argh
[11:24] <ogra> heh, yeah
[11:24] <ogra> it would also have been nicer to call it "Apps" or some such to make the purpose a bit more clear
[11:25] <ogra> (i think apple does that actually)
[11:32] <juliank> FWIW, I added snap/ to $HOME/.hidden
[11:32] <juliank> ogra: What is terrible is that I see the Downloads directory multiple times in gnome-shell
[11:32] <juliank> one for each snap
[11:34] <juliank> and those are all symlinks to the main directory
[11:34] <ogra> juliank, ithats actually a bug in the desktop helpers, not really snapd's fault but a remotely included tool thats adds them
[11:35] <ogra> oh, wait, in gnome-shell ?
[11:35] <ogra> i havent seen that yet
[11:35] <juliank> Just searched for Downloads, for example
[11:35] <ogra> i know there was (and probably still is) a bug that creates them multiple times in $HOME
[11:35] <juliank> Might depend on if you have tracker installed
[11:36] <ogra> seems the desktop helper doesnt get along with translated XDG dirs there
[11:36] <juliank> like this: https://imgur.com/a/8d7Zabc
[11:36] <ogra> wheer exactly do they point to ? $HOME/snap/foo ? or $HOME/Downloads ?
[11:36]  * ogra looks
[11:37] <juliank> $HOME/snap/spotify/16/Downloads is a symlink to $HOME/Downloads
[11:37] <juliank> same for every snap and xdg directory
[11:37] <juliank> which makes sense, as it's their $HOME
[11:37] <ogra> hmm, is that for all snaps you have installed or only --classic ones ?
[11:38] <ogra> that seems to be a classic specific bug and i dont think thats known yet
[11:38] <juliank> Definitely also non-classic ones
[11:38] <juliank> see gnome-calculator
[11:38] <ogra> interesting ... you should definitely file it
[11:38] <ogra> yeah, indeed
[11:39] <ogra> i guess tracker should ignore them or so
[11:39] <juliank> If I start gnome-logs I see /home/jak/snap/gnome-logs/40/Desktop was removed, reassigning DESKTOP to homedir
[11:39] <juliank> and strangely enough
[11:39] <juliank> ln: failed to create symbolic link '/home/jak/snap/gnome-logs/40/snap/gnome-logs/40': No such file or directory
[11:40] <ogra> likely because 40 isnt there anymore
[11:40] <ogra> thats all desktop-helper stuff ...
[11:40] <juliank> 40 is installed
[11:40] <ogra> (desktop team maintained)
[11:40] <ogra> https://github.com/ubuntu/snapcraft-desktop-helpers.git
[11:42] <ogra> i assume filing a bug for them goes via https://github.com/ubuntu/snapcraft-desktop-helpers/issues
[11:44] <ogra> the gnome-shell/tracker issue surely deserves a normal distro bug on LP
[11:44] <ogra> i guess thats something they'd want to fix in upstream gnome
[11:46] <juliank> this is bug 1791289
[11:46] <ubottu> bug 1791289 in tracker (Ubuntu) "Shows duplicate xdg directories for snaps" [Undecided,New] https://launchpad.net/bugs/1791289
[11:46] <juliank> now
[11:46] <juliank> :)
[11:52] <ogra> :)
=== CyberHacker_ is now known as CyberHacker
[16:18] <xnox> ogra, i agree with current|past|factory copies, but it seems like we have current|past|very-past versions. Ie. factory version does not get pinned to e.g. first installed copy
[16:18] <xnox> ogra, we only have preseeded snaps.
[16:18] <xnox> ogra, or am I wrong? cause it seems like we should just drop the third copy. Cause it ain't factory-reset.
=== jdstrand_ is now known as jdstrand
[16:36] <ogra> xnox, well, afaik factory should be pinned to "whatever was installed first" but thats indeed a moving target depending on the point in time you roll the image
[16:36] <ogra> seeding doesnt allow picking particular revisions
[16:37] <ogra> if you drop the third copy it will automatically come back with the next silent auto-refresh that snapd does
[16:37] <ogra> (btw, should we probably find a better channel ? :) )
[16:39] <ogra> er ... wait ... if you define "third copy" as what is supposed to be "factory", then yes, that should be droppable ... but i'm not sure how snapd reacts to that ... i't might just blantly count to three and simply add one
[16:40] <ogra> (and i think thats very likely)