[01:31] <mup> PR snapd#3941 closed: overlord/snapstate: prefer a smaller corner case for doing the wrong thing <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/3941>
[10:00] <mup> PR snapd#3987 closed: packaging/fedora: Add Fedora 26, 27, and Rawhide symlinks <Created by Conan-Kudo> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3987>
[10:01] <mup> PR snapd#3974 closed: Recognise Solus as a classic Linux distribution <Created by ikeydoherty> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3974>
[10:03] <mup> PR snapd#3975 closed: snap-confine: Only attempt to copy/mount NVIDIA libs when NVIDIA is used <Created by ikeydoherty> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3975>
[11:49] <mup> PR snapd#3988 opened: Added note in HACKING file  <Created by rmescandon> <https://github.com/snapcore/snapd/pull/3988>
[12:26] <mup> PR snapcraft#1577 opened: lxd: don't inject local snaps on a different arch <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1577>
[13:30] <mup> PR snapd#3977 closed: interfaces: Enhance full-confinement support for biarch distributions <Created by ikeydoherty> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3977>
[13:44] <mup> PR snapd#3989 opened: client, daemon: rest api to configure store api <Created by atomatt> <https://github.com/snapcore/snapd/pull/3989>
[13:44] <mup> PR snapd#3990 opened: cli: configure/revert store <Created by atomatt> <https://github.com/snapcore/snapd/pull/3990>
[14:08] <ogra_> cachio, https://code.launchpad.net/~snappy-dev/core-snap/trunk
[14:09] <ogra_> cachio, lp-build-core and the README for it are in the cron-scripts subdir
[14:14] <kyrofa> nessita, are you in IRC?
[14:24] <nessita> kyrofa, I am!
[14:28] <coreycb> 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] <kyrofa> coreycb, are you sure it's registered, or simply reserved?
[14:29] <ogra_> cachio, so ignore the above branch, the right one is  https://github.com/snapcore/core/tree/master/cron-scripts
[14:29] <coreycb> kyrofa: i'm not sure
[14:29] <kyrofa> nessita, you guys have worked out snap renames to be an easier process, is that right?
[14:29] <kyrofa> coreycb, one moment
[14:29] <kyrofa> nessita, if I rename snap A to B, what happens to those who have A installed?
[14:31] <kyrofa> 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] <coreycb> kyrofa: ok, thanks for checking. is there a way to see who registered it?
[14:33] <kyrofa> coreycb, not other than talking to the store folks
[14:34] <kyrofa> coreycb, if something had been published you could use `snap info`, but without that, it's only available to the store
[14:34] <coreycb> kyrofa: alrighty thanks
[14:56] <jdstrand> 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] <zyga-ubuntu> jdstrand: hey
[14:59] <zyga-ubuntu> jdstrand: thank you, I understand you are busy this week
[14:59] <zyga-ubuntu> jdstrand: I hope you had a chance to discuss user mount namespaces
[15:00] <zyga-ubuntu> jdstrand: and other aspects that will help to implement various features next week
[15:00] <zyga-ubuntu> jdstrand: thank you for the note :)
[15:03] <jdstrand> 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] <zyga-ubuntu> jdstrand: thank you for sharing that, I was wondering what's the likely outcome of the current PR
[15:11] <nessita> kyrofa, we have no support for snap renames
[15:11] <nessita> kyrofa, what we can offer easily is snap owner transfer
[15:11] <kyrofa> nessita, huh, maybe it was owner transfer
[15:11] <kyrofa> Ah, yeah
[15:11] <kyrofa> nessita, I'm getting old :(
[15:11] <nessita> kyrofa, yeah :-)
[15:11] <nessita> we both!
[15:11] <kyrofa> Hahaha
[15:11] <kyrofa> nessita, ignore me then!
[15:12] <nessita> ack!
[15:12] <kyrofa> 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] <mup> PR snapcraft#1578 opened: project_loader: quote more environment variable values <Created by malept> <https://github.com/snapcore/snapcraft/pull/1578>
[16:16] <apol> kyrofa: ping?
[17:45] <kyrofa> cratliff, https://forum.snapcraft.io/t/bug-with-cleaning-snap-data-in-home-dirs-proposed-solution/1201
[17:47] <cachio> mvo, https://paste.ubuntu.com/25640466/
[17:57] <apol> kyrofa: https://github.com/snapcore/snapcraft/pull/1579
[17:57] <mup> PR snapcraft#1579: Make it possible to use the cmake ninja generator <Created by aleixpol> <https://github.com/snapcore/snapcraft/pull/1579>
[17:57] <kyrofa> apol, awesome, thank you!
[17:57] <mup> PR snapcraft#1579 opened: Make it possible to use the cmake ninja generator <Created by aleixpol> <https://github.com/snapcore/snapcraft/pull/1579>
[18:12] <kalikiana_> \o
[18:19] <kyrofa> 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] <kyrofa> ogra_, each core updates moves the content forward?
[18:19] <ogra_> kyrofa, well, my /root dir at home started that thread
[18:19] <ogra_> and an update of core should definitely migrate data forward
[18:20] <ogra_> as well as a removal of core should remove the data alongside
[18:20] <ogra_> so if you have 120 core subdirs there, only the last three should actually have content
[18:20] <ogra_> the rest are just leftover empty dirs
[18:20] <ogra_> if thats not the case we have a more serious bug
[18:22] <kyrofa> ogra_, definitely not the case
[18:22] <ogra_> bug then
[18:22] <ogra_> raise that on the forum thread too please
[18:23] <kyrofa> ogra_, done
[18:23] <ogra_> yep, seen :D
[18:23] <kyrofa> ogra_, so to be clear: you're saying every time core updates, it tries to clean those dirs for all snaps?
[18:27] <ogra_> 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] <kyrofa> ogra_, note that I'm not talking about core, but a ROS app snap
[18:27] <ogra_> 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] <kyrofa> ogra_, SNAP_USER_DATA is fine as long as it's /home/. But /root/ is broken
[18:28] <kyrofa> Yes indeed, exactly
[18:28] <ogra_> right, it shouldnt matter what snap it is
[18:28] <kyrofa> Yes, /home-based SNAP_USER_DATA is fine
[18:28] <ogra_> well, /root will be treated the same
[18:29] <ogra_> existing data will be migrated forward to the newer subdir, the oldest sudbdir (current - 3) should be removed
[18:30] <ogra_> so that you only ever have 3 dirs there and the latest always has the latest set of content
[18:33] <kyrofa> ogra_, it SHOULD be ;)
[18:34] <mup> PR snapd#3986 closed: wrappers: fail install if exec-line cannot be re-writen <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/3986>
[18:34] <mup> PR snapd#3991 opened:  wrappers: fail install if exec-line cannot be re-write <Created by mvo5> <https://github.com/snapcore/snapd/pull/3991>
[18:36] <ogra_> 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] <nacc> lol
[18:37]  * nacc can picture it
[18:37] <mup> PR snapd#3992 opened: asserts: add cross-checking for snap-build <Created by pedronis> <https://github.com/snapcore/snapd/pull/3992>
[18:38] <apol> anyone konws what's the status of this bug? https://bugs.launchpad.net/snappy/+bug/1588192
[18:38] <mup> Bug #1588192: GL interfaces seem wedged for Krita on nvidia <patch> <Snappy:In Progress> <nvidia-graphics-drivers-304 (Ubuntu):In Progress by albertomilone> <nvidia-graphics-drivers-340 (Ubuntu):Won't Fix by albertomilone> <nvidia-graphics-drivers-361 (Ubuntu):Won't Fix by albertomilone>
[18:38] <mup> <nvidia-graphics-drivers-304 (Ubuntu Xenial):In Progress by albertomilone> <nvidia-graphics-drivers-340 (Ubuntu Xenial):Won't Fix by albertomilone> <nvidia-graphics-drivers-361 (Ubuntu Xenial):Won't Fix by albertomilone> <https://launchpad.net/bugs/1588192>
[18:52] <mup> PR snapd#3983 closed: snap-confine: is_running_on_classic_distribution() looks into os-release <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/3983>
[18:52] <mup> PR snapd#3993 opened: snap-confine: is_running_on_classic_distribution() looks into os-release <Created by mvo5> <https://github.com/snapcore/snapd/pull/3993>
[19:02] <mup> PR snapd#3994 opened: tests: fix revert test when a new core image is on current channel <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/3994>
[19:48] <mup> PR snapd#3922 closed: snapstate: deal with snap user data in the /root/ directory <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3922>
[19:58] <mup> PR snapcraft#1580 opened: cli: setup gitignore when working from git directory at init <Created by msis> <https://github.com/snapcore/snapcraft/pull/1580>
[21:48] <nacc> 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] <nacc> is that on the roadmap?
[21:48] <nacc> sergiusens: --^