[01:31] PR snapd#3941 closed: overlord/snapstate: prefer a smaller corner case for doing the wrong thing === Josh|Gaming is now known as JoshStrobl|zzz === slangase` is now known as slangasek === JanC_ is now known as JanC === JoshStrobl|zzz is now known as JoshStrobl === JoshStrobl is now known as sotrhaven === sotrhaven is now known as JoshStrobl [10:00] PR snapd#3987 closed: packaging/fedora: Add Fedora 26, 27, and Rawhide symlinks [10:01] PR snapd#3974 closed: Recognise Solus as a classic Linux distribution [10:03] PR snapd#3975 closed: snap-confine: Only attempt to copy/mount NVIDIA libs when NVIDIA is used [11:49] PR snapd#3988 opened: Added note in HACKING file [12:26] PR snapcraft#1577 opened: lxd: don't inject local snaps on a different arch === Sir_Gallantmon is now known as Conan_Kudo === Conan_Kudo is now known as Son_Goku [13:30] PR snapd#3977 closed: interfaces: Enhance full-confinement support for biarch distributions === JoshStrobl is now known as JoshStrobl|Work [13:44] PR snapd#3989 opened: client, daemon: rest api to configure store api [13:44] PR snapd#3990 opened: cli: configure/revert store === ShalokShalom_ is now known as ShalokShalom [14:08] cachio, https://code.launchpad.net/~snappy-dev/core-snap/trunk [14:09] cachio, lp-build-core and the README for it are in the cron-scripts subdir [14:14] nessita, are you in IRC? [14:24] kyrofa, I am! [14:28] hi all, is there a way to find out who registered the gnocchi snap name? i'm getting a store upload failure for it. [14:28] coreycb, are you sure it's registered, or simply reserved? [14:29] cachio, so ignore the above branch, the right one is https://github.com/snapcore/core/tree/master/cron-scripts [14:29] kyrofa: i'm not sure [14:29] nessita, you guys have worked out snap renames to be an easier process, is that right? [14:29] coreycb, one moment [14:29] nessita, if I rename snap A to B, what happens to those who have A installed? [14:31] coreycb, there's no gnocchi in any channel, so I suspect it's simply reserved. Although it's possible that someone has registered it and uploaded nothing [14:33] kyrofa: ok, thanks for checking. is there a way to see who registered it? [14:33] coreycb, not other than talking to the store folks [14:34] coreycb, if something had been published you could use `snap info`, but without that, it's only available to the store [14:34] kyrofa: alrighty thanks [14:56] zyga-ubuntu: hey, we've been missing each other. I saw your requests for review on 3963 and 3973. I haven't had time to do an in depth review of either, but on my list for next week [14:59] jdstrand: hey [14:59] jdstrand: thank you, I understand you are busy this week [14:59] jdstrand: I hope you had a chance to discuss user mount namespaces [15:00] jdstrand: and other aspects that will help to implement various features next week [15:00] jdstrand: thank you for the note :) [15:03] zyga-ubuntu: we did a bit, yes. I think jhenstridge is going to continue on the current path for his PoC, then see discuss with us the end (blackboxed) result and how that would impact the layouts feature. iterate on that and then when happy with the end result, discuss the correct implementation for him to take, then he'll make a proper PR [15:06] jdstrand: thank you for sharing that, I was wondering what's the likely outcome of the current PR [15:11] kyrofa, we have no support for snap renames [15:11] kyrofa, what we can offer easily is snap owner transfer [15:11] nessita, huh, maybe it was owner transfer [15:11] Ah, yeah [15:11] nessita, I'm getting old :( [15:11] kyrofa, yeah :-) [15:11] we both! [15:11] Hahaha [15:11] nessita, ignore me then! [15:12] ack! [15:12] Thanks for your time :) [15:38] * zyga-ubuntu supper [15:41] <__chip__> cjwatson: jdstrand: bug report filed. And it's a prime number. [15:41] <__chip__> the omen is clear [16:00] PR snapcraft#1578 opened: project_loader: quote more environment variable values [16:16] kyrofa: ping? [17:45] cratliff, https://forum.snapcraft.io/t/bug-with-cleaning-snap-data-in-home-dirs-proposed-solution/1201 [17:47] mvo, https://paste.ubuntu.com/25640466/ [17:57] kyrofa: https://github.com/snapcore/snapcraft/pull/1579 [17:57] PR snapcraft#1579: Make it possible to use the cmake ninja generator [17:57] apol, awesome, thank you! [17:57] PR snapcraft#1579 opened: Make it possible to use the cmake ninja generator === JoshStrobl|Work is now known as JoshStrobl|AFK [18:12] \o [18:19] ogra_, I'm super confused by your response to https://forum.snapcraft.io/t/bug-with-cleaning-snap-data-in-home-dirs-proposed-solution/1201/12 :P [18:19] ogra_, each core updates moves the content forward? [18:19] kyrofa, well, my /root dir at home started that thread [18:19] and an update of core should definitely migrate data forward [18:20] as well as a removal of core should remove the data alongside [18:20] so if you have 120 core subdirs there, only the last three should actually have content [18:20] the rest are just leftover empty dirs [18:20] if thats not the case we have a more serious bug [18:22] ogra_, definitely not the case [18:22] bug then [18:22] raise that on the forum thread too please [18:23] ogra_, done [18:23] yep, seen :D [18:23] ogra_, so to be clear: you're saying every time core updates, it tries to clean those dirs for all snaps? [18:27] kyrofa, no, there should always be only three installs of any snap ... if core updates that means a new core gets installed, data gets migrated forward and the oldest snap gets removed ... on removal the dirs should be cleared [18:27] ogra_, note that I'm not talking about core, but a ROS app snap [18:27] kyrofa, /root is a bit special here but i'm told by the guys sitting to my left that there is a PR that fixes this [18:28] ogra_, SNAP_USER_DATA is fine as long as it's /home/. But /root/ is broken [18:28] Yes indeed, exactly [18:28] right, it shouldnt matter what snap it is [18:28] Yes, /home-based SNAP_USER_DATA is fine [18:28] well, /root will be treated the same [18:29] existing data will be migrated forward to the newer subdir, the oldest sudbdir (current - 3) should be removed [18:30] so that you only ever have 3 dirs there and the latest always has the latest set of content [18:33] ogra_, it SHOULD be ;) [18:34] PR snapd#3986 closed: wrappers: fail install if exec-line cannot be re-writen [18:34] PR snapd#3991 opened: wrappers: fail install if exec-line cannot be re-write [18:36] kyrofa, right, the PR will fix that ... as soon as the guys next to me are done with pushing the blame for not revieweing back and forth :P [18:37] lol [18:37] * nacc can picture it [18:37] PR snapd#3992 opened: asserts: add cross-checking for snap-build [18:38] anyone konws what's the status of this bug? https://bugs.launchpad.net/snappy/+bug/1588192 [18:38] Bug #1588192: GL interfaces seem wedged for Krita on nvidia [18:38] [18:52] PR snapd#3983 closed: snap-confine: is_running_on_classic_distribution() looks into os-release [18:52] PR snapd#3993 opened: snap-confine: is_running_on_classic_distribution() looks into os-release [19:02] PR snapd#3994 opened: tests: fix revert test when a new core image is on current channel === JoshStrobl|AFK is now known as JoshStrobl [19:48] PR snapd#3922 closed: snapstate: deal with snap user data in the /root/ directory [19:58] PR snapcraft#1580 opened: cli: setup gitignore when working from git directory at init [21:48] given the perspective that cleanbuild is the 'only' safe way to ensure proper development of a snap, it feels like it should take options like other tools do (preserve build env on failure), only do stage, only build some specific part, etc. [21:48] is that on the roadmap? [21:48] sergiusens: --^