[00:03] PR snapcraft#1527 closed: repo: Use os-release(5) to detect supported Linux distributions === JoshStrobl|AFK is now known as JoshStrobl [02:15] PR snapcraft#1518 closed: project: introduce build-snaps === JoshStrobl is now known as JoshStrobl|zzz [06:00] PR snapd#3847 opened: tests: run the tests/unit/go everywhere [06:12] mvo: hey [06:12] mvo: no luck with static go + c [06:12] mvo: I'll iterate shortly, just need to send kids to school [06:13] hey zyga-ubuntu [06:13] zyga-ubuntu: ok, good luck [06:17] fwiw, I enabled an arful-i386 autopkgtest (outcome of the 2.27 cycle retrospect) [06:18] PR snapd#3839 closed: docs: use abolute path in PULL_REQUEST_TEMPLATE.md [07:07] mvo: thanks, I had a question at the last stand-up, what happened to our ppc adt tests? [07:08] morning [07:10] hey pstolowski [07:10] rainy day, eh? [07:10] uhm [07:20] zyga-ubuntu: we only have a ppc64, not powerpc itself [07:20] zyga-ubuntu: is that what you mean? [07:24] aha, I see [07:25] mvo: I recall you ran into an issue that only affected a weird arch during the last cycle [07:25] and I was wondering if we missed or ignored the adt data [07:25] or if we simply didn't have any data [07:25] pstolowski: hey, I looked at your huge branch [07:26] pstolowski: that was a painful patch to write, I presume [07:26] zyga-ubuntu, a little bit, yes ;) [07:26] zyga-ubuntu, and it breaks every now and then when something new lands ;) [07:27] zyga-ubuntu: hm, I need to look into the PRs/error logs, I don't remember that one off-ahdn [07:35] mvo: can you please look at the general design of https://github.com/snapcore/snapd/pull/3810 since you requested those changes [07:35] PR #3810: interfaces/hooks: PlugData and SlotData wrappers [07:36] mvo: I will then work with pawel on reviweing that branch and landing it [07:36] zyga-ubuntu, and it breaks every now and then when something new lands ;) [07:36] ups, wrong window ;) [07:37] zyga-ubuntu, thanks for looking at this [07:37] zyga-ubuntu: yeah, in a short while, just lookiing into 2.28 breakage on artful/i386,s390x [07:37] zyga-ubuntu: fwiw s/requested/suggested/ [07:46] mvo: sure, no rush and indeed :) [07:48] * zyga-ubuntu managed to link statically now [07:48] whee :) [07:52] mvo: are you looking into "./get-deps.sh: 10: ./get-deps.sh: go: not found" ? [07:56] zyga-ubuntu: yes, that too [08:12] mvo: will not running the unit tests everywhere increase our test run time too much ? [08:19] pedronis: that might be a problem yes, i can try to figure out other ways to run them but right now there is a gap in our testing, e.g. unit tests failed on trusty but we don't test for this anywhere [08:33] PR snapd#3848 opened: snap-seccomp: check for negative syscalls in runBpf() and skip those tests [08:34] meh, stuff like: "/tmp/go-build037063724/github.com/snapcore/snapd/cmd/snap-seccomp/_test/snap-seccomp.test: error while loading shared libraries: R_PPC64_ADDR16_HA re13f596af8 for symbol `' out of range [08:34] exit status 127" (in the zesty/ppc64el build) make me weep hard [08:34] pstolowski: is #3810 so big because of the changes in snap/ ? [08:34] PR #3810: interfaces/hooks: PlugData and SlotData wrappers [08:36] were they strictly necessary? [08:38] mvo: hmmm, symbol "empty string" [08:38] pedronis, yes, it's because the change in snap/; the change is trivial but affected lots of tests [08:39] pstolowski: is it needed though? [08:39] it doesn't make much sense on its own [08:39] pedronis, not strictly neccessary, but mvo suggested a nice change to avoid code repetition in the new API [08:39] yes, but that's internal [08:39] PlugSlotData vs plugSlotData [08:39] a world of difference [08:39] yes, you noticed by needing to change so much [08:41] pstolowski: I don't think mvo suggestion extended to snap, it was about the new stuff [08:47] PR snapd#3849 opened: tests: fix unit tests on Ubuntu 14.04 [08:48] pedronis: when I looked into this iirc I had to exend it to snap/ but I only looked briefly its probalby worth exploring options here [08:49] pedronis, it did, I merged mvo's branch with these refactoring changes, I fixed all the tests [08:49] pedronis, perhaps I accepted it too quick, not denying that, if this can be avoided then I'm ok to revert/redo this [08:50] pstolowski: well I data *snap.PlugSlotData [08:50] will probably confuse us [08:50] because it recreates the problems we are trying to get away from [08:50] s/I data/I think data/ [08:51] we should really treat the Info stuff as immutable [08:51] PR snapd#3848 closed: snap-seccomp: check for negative syscalls in runBpf() and skip those tests [08:52] pstolowski: to be clear I'm not against a shared plugSlotData in the new stuff, I'm not thrilled by snap.PlugSlotData and even less so by sharing it with plugSlotData by reference [08:52] PR snapd#3849 closed: tests: fix unit tests on Ubuntu 14.04 [08:52] PR snapd#3850 opened: tests: check for negative syscalls in runBpf() and skip those tests [08:53] PR snapd#3851 opened: tests: fix unit tests on Ubuntu 14.04 [08:54] pstolowski: using mutated or not copies of *Info is our current confusion/problem [08:54] this particular changes doesn't seem to address that [08:56] pstolowski: I expect some changes coming from addressing that, but the massive rework seems to not help to me [08:59] pstolowski: sorry for having made your life more complicated [09:00] pstolowski: I'm happy to have a HO if this is unclear [09:00] mvo: did you suggest to change snap.PlugInfo ? I saw your suggestion about the new stuff, not those [09:01] pedronis: when I played with code I did add a snap.PlugSnapData so that it could be embedded into the new stuff [09:01] pedronis: maybe that was wrong [09:01] yes, it is [09:01] pedronis, thanks for the feedback, really appreciate it! i'm often missing the big picture when it comes to how the structures we have fit rogether [09:01] I mean, it's not wrong [09:01] pedronis: I was mostly trying to the duplication [09:01] but it tempts bad stuff [09:01] mvo, don't worry :) [09:01] and it's a massive rework [09:01] that muds things [09:02] pedronis: ok, do you see another way to avoid the duplication or is that just something we need to accept if we don't want to go down the other route? [09:02] * mvo hasn't looked into the branch since a couple of days so will have to refresh his memory [09:03] pedronis, i need to revisit this branch to refresh my brain, currently finishing some other PR; will let you know later if I need more clarification [09:03] mvo: pstolowski: I think the main point is that NewPlug/SlotData need to really copy stuff out of Info [09:03] and then we need to live with the consequences [09:03] of that [09:03] right now because we didn't have dynamic attrs [09:04] we use *Info either fromt he repo or the snap [09:04] in slightly mixed up ways [09:04] we cannot afford that once we have dynamic attrs [09:05] hmm [09:05] so we do need big changes, but more about how the repository store stuff [09:07] zyga-ubuntu: the PlugInfo and SlotInfo in repo are sanitized, the ones from the snaps aren't, it seems we have no bugs yet, but super unclear if just chance [09:08] anyway the use of the same type makes unclear why using the wrong one would be a problem [09:09] pedronis: indeed [09:09] given that go has types we might as well use them to our advantage, especially now we are adding the complexity of dynamic attrs [09:14] pedronis, got you. that's a good point [09:19] pstolowski: notice that we still need to think a bit about Plug vs PlugInfo vs PlugData [09:20] pstolowski: as I said happy to chat a bit about options when you have time [09:21] o/ [09:24] PR snapd#3852 opened: hooks: commands for controlling own services from snapctl [09:26] * zyga-ubuntu reboots [09:27] Chipaca: hi [09:29] pedronis, ack, thanks [09:30] * zyga-ubuntu walks his son to school, brb [09:39] Hello, I think I found an issue with snap and AppArmor, I tried sending an email to the list [09:39] but it bounced back [09:40] mwhudson: hey, I ran into /tmp/go-build407282108/github.com/snapcore/snapd/cmd/snap-seccomp/_test/snap-seccomp.test: error while loading shared libraries: R_PPC64_ADDR16_HA re110ef6af8 for symbol `' out of range in zesty/ppc64el package building. that looks very much like bug 1711935 which you marked fix released but I see it. if it is PIE related I can try to disable PIE on ppc64el maybe? [09:40] anywhere else? [09:40] Bug #1711935: failing to start on ppc64el: R_PPC64_ADDR16_HA 277ef287d88 for symbol `' out of range [09:40] Jasem[m]: the forum? [09:40] Chipaca: ok will try there [09:41] Jasem[m]: you're in the right place for the chitchat around snapd, for what it's worth [09:42] Chipaca: well, it's an odd problem. I made a snap package for KStars about a year ago, it includes INDI server. So I forgot about the package and today I found that my INDI server (not related to the one in the snap package) was crashing. Turns out it was permission issue, and it only when away to I removed the snap from the system. [09:42] Chipaca: so for some reason, the AppArmor stuff was being applied to things outside of the snap in the reuglar system [09:43] Jasem[m]: that sounds awfully like one of those "that's not how this works" memes [09:43] Jasem[m]: how does the client talk to the server? [09:44] Chipaca: you can image frustration of troubleshooting this.. 2 hours I wasn't going anywhere it was driving me insane. I think a recent update to snap or apprmor changed things. I forgot about the snap package installed last year as I was testing snap packaging. [09:49] Jasem[m]: yes, i can imagine! [09:49] Jasem[m]: did you see my question? [09:49] Chipaca: the server crashes after a few seconds without any client [09:50] Jasem[m]: hey [09:50] JamieBennett: can you please open a bug or a forum thread? [09:50] er [09:50] Jasem[m]: ^ [09:50] heh, I can ;-) [09:51] Jasem[m]: sorry, I meant you above :) [09:51] Jasem[m]: do you see any apparmor denials? dmesg | grep DENIED [09:51] zyga-ubuntu: I didn't check that, but problem went away after the kstars snap was removed. [09:53] Ok I don't see any DENIED related to indiserver. [09:54] Chipaca: do you want to give a look at #3780 again, it was rebased , also #3727 needs a 2nd review [09:54] PR #3780: many: configure store from state, reconfigure store at runtime [09:54] PR #3727: daemon, snapstate: move ensureCore from daemon/api.go into snapstate.go [09:55] pedronis: also a deconflict [09:55] Jasem[m]: please try to reproduce the issue, collect any data such as journal logs and denials or messages from the service [09:55] Jasem[m]: and let's chat [09:55] pedronis: was looking at 3870 already [09:55] Jasem[m]: in the end lets please open a forum topic with all the facts you managed to collect [09:56] mvo: #3727 needs a deconflict it seems [09:56] PR #3727: daemon, snapstate: move ensureCore from daemon/api.go into snapstate.go [10:06] pedronis: opinions on snapd#3845? [10:06] PR #3845: osutil: AtomicWriter (an io.Writer), and io.Reader versions of AtomicWrite* [10:07] it's got 1.66… reviews already fwiw [10:12] I'll look in a sec [10:12] Chipaca: I can have a look too [10:13] mvo: you already did, twice, and you're doing the release [10:13] pedronis: I will work on my branches next [10:13] pedronis: still fighting some annoying issues with our matrix of (arch,release) [10:13] Chipaca: good point [10:16] Chipaca: fwiw, looks very nice, thanks for improving the tests btw [10:19] mvo: btw, does that mean we do 2.27.6 with build fixes? [10:26] Chipaca: looked at it, mostly comments on comments and names [10:27] * Chipaca looks === ShalokShalom_ is now known as ShalokShalom [10:31] pedronis: Commit/Cancel? Commit/Abort? [10:31] mvo: WDYT? [10:32] mvo: (re pedronis' comment that Finalize is bad because Go uses it for something else, and we already use Commit for things that can't be re-committed -- and sql transactions usually can't commit twice) [10:34] Chipaca: usually for files the thing you can do many times is "flush" [10:34] mhmm [10:34] which isn't this [10:34] that's called Sync in go, and you can do that on these [10:34] what where you thinking about commit and many times? [10:34] s/where/were/ [10:34] pedronis: mvo said he'd expect to be able to call Commit piecewise [10:35] I don't know why [10:35] anyway either Cancel or Abort are fine by me [10:35] pedronis: I think it's the bread. Germans do crazy stuff with the bread. [10:35] Chipaca: piecewise shouds like flush [10:36] except here we commit to the name [10:36] with the rename [10:36] * Chipaca awaits mvo's feedback [10:38] Chipaca, pedronis: maybe its because of vcs commit that I had a mental "commit, commit" model [10:38] the bread is another possiblity [10:40] Chipaca, pedronis: "submit()"? "finish()"? but I have no super strong objection against commit(), just felt a bit odd to not be able to repeat it [10:40] we have already two Commit in the codebase [10:41] nobody liked Enfeoff() [10:41] my brain admittedly happily keeps vcs commit and transactional commit separate [10:42] ok, commit it is then [10:42] does core 16, all-snappy systems, use resolved in xenial? [10:43] ogra@nanopi-air:~$ ps ax|grep resolv [10:43] 1618 pts/0 S+ 0:00 grep --color=auto resolv [10:43] xnox, ^^ does that answer it ? :) [10:44] ogra_, no, but this would $ systemctl status systemd-resolved [10:44] xnox, we do use networkd [10:44] pedronis: I've flip-flopped over having AtomicWriter being the real thing, and it being an interface. Advantage of the interface is that it's a lot easier to document. Advantage of the real thing is that e.g. you get Sync() for free (because I'd embed *os.File) [10:44] pedronis: do you have an opinion on that? [10:44] ogra@nanopi-air:~$ systemctl status systemd-resolved [10:44] ● systemd-resolved.service - Network Name Resolution [10:44] Loaded: loaded (/lib/systemd/system/systemd-resolved.service; disabled; vendor preset: enabled) [10:44] ack, thanks [10:47] PR snapd#3850 closed: tests: check for negative syscalls in runBpf() and skip those tests [10:49] PR snapd#3851 closed: tests: fix unit tests on Ubuntu 14.04 [11:23] Chipaca: the interface is ok [11:24] Chipaca: do you have a use case for doing more File stuff ? [11:24] pedronis: no [11:25] pedronis: pushed an iteration [11:26] pedronis: most notably i've rejiggered commit so the only thing that can fail once the file is in place is the final dir sync [11:26] pedronis: and i've chosen to silently ignore that error [11:27] (if power dies after a failed dir sync, you either have the old or the new thing -- atomicity is there) [11:27] and, reasons for a failing dir sync after everything else worked, are really hard to come up with without it involving filesystem failure [11:28] Chipaca: wondering a bit about the flags, should we have a mutex? are there patterns where Cancel for example could come from a different goroutine than Commit? [11:29] pedronis: one of the cancels will fail with one of the appropriate errors [11:29] or one of the cancel / commits [11:29] er [11:29] let me look at it just to be sure, but i _think_ all you get is a werider error than is user-friendly [11:30] (granted that the _expected_ outcome of calling cancel and commit in different goroutines is unknown) [11:30] gah [11:31] i've done that thing again where i think just because something is a boolean, concurrent accesses will only get booleans [11:31] pedronis: would it be fair to say, if you use these things from different goroutines, add a mutex? [11:32] yea, it's fair [11:32] maybe just a matter to write it somewhere [11:33] pedronis: OK. If that's the only issue with the code as it stands, I'll address it in the first PR that actually uses these :-) [11:34] BTW last night I found a place where we're doing something similar to the old "compile a constant regexp every time a function is called" [11:35] (that'll be addressed in the first PR that uses this as well) [11:37] Chipaca: any particular reasons to stop returning the dir.Sync() error? [11:37] pedronis: there's nothing useful you can do with it [11:38] you can't cancel the commit [11:38] you can't re-commit [11:38] you disk is bad and you go ahead [11:38] the filesystem is probably consistent, but fucked because otherwise why would it error [11:39] pedronis: stated like that, it sounds like maybe I shouldn't [11:39] it's a change [11:39] if you are worried about Cancel [11:39] you can save the error [11:39] and return that instead of [11:39] pedronis: but if I do I feel compelled to make the wording around the interface a lot more convoluted than is probably needed [11:40] just cannot canccle [11:40] I'm going to go make lunch and think about it [11:41] ok, anyway not giving it a +1 yet [11:41] do you need an explicit -1 ? [11:52] jdstrand: hello! [11:53] jdstrand: if you are around today, can you please have a look at https://github.com/snapcore/snapd/pull/3621 again, I have added a child profile and massaged things into compliance build-wise [11:53] PR #3621: cmd/snap-{confine,update-ns}: apply mount profiles using snap-update-ns [11:53] jdstrand: as a small note, we now have snap-exec and snap-update-ns as statically linked executables [11:53] jdstrand: I kept the are-we-reexecing-function in the PR even though I don't need it yet because it may come in handy later [12:09] * zyga-ubuntu sighs [12:12] pedronis: another attempt :-) [12:19] zyga-ubuntu: hey, I'll try to get to it. I need to figure out the cgroup issue and haven't been through my inbox yet, but it is very high on the list [12:21] Chipaca: just reverted that bit of change? [12:21] pedronis: and added docs [12:23] Jasem[m]: I'll just reiterate what zyga-ubuntu said and ask for more information (eg any security denials in journactl at the time the application was crashing)-- the security confinement shouldn't leak out to other processes in the way you described, and if it did, there would be logs [12:25] Jasem[m]: depending on the architecture of how the client interacts with the server, or if you had a deb client and a snap client, or a deb server and a snap server installed at the same time, then there could be conflicts (not necessarily security sandbox related) [12:25] jdstrand: thank you, I'm trying to sort out last packaging quirk there [12:28] Chipaca: matt changed #3780, it looks reasonable/consistent now, don't know if you want to look again [12:28] PR #3780: many: configure store from state, reconfigure store at runtime [12:36] pedronis: i'll take a look [12:42] jdstrand: hi, this seems something for you: https://forum.snapcraft.io/t/sandboxing-in-general/1984 [12:53] pedronis: yep, just came online, I'll get to it in a bit [12:53] pedronis: thanks [13:37] sborovkov, https://github.com/snapcore/pi2-gadget/pull/9 ;) [13:37] PR pi2-gadget#9: add splash support [13:42] For fun last weekend, I wrote a little snap store/repo. I downloaded the signed hello-world snap from the official store and was able to install it from my store. The question is, would it be possible to trust my own sign key and selfsign my own snaps and install them from my local store? Or is there something hardcoded in snapd that would prevent that? === cachio__ is now known as cachio [13:48] nsg: there is a chain of trust from the root key, yes [13:48] mvo, did you see the error in the base snaps test? [13:48] nsg: there's a forum thread about that today, I would suggest you catch up first [13:48] * zyga-ubuntu needs to pick up his son from school, brb [13:51] zyga-ubuntu: will do! [13:51] cachio: I saw it but have not looked deeper yet, I had some vague idea, let me look again [13:51] cachio: I spend my morning with seccomp and similar failures in the unittests on s390x and pppc64el :) [13:51] mvo, ahh, ok [13:52] mvo, btw, i am ponderring if the new libssecomp should be backported from artful to xenial, to support newer kernels etc. [13:52] and s390x [13:52] mvo, np, I am still researching the issues that I see in the results [13:52] cachio: the error looks a bit like something is wrong with the branch that ubuntu-core-16-arm-32 runs from, the snapbuild version looks outdated [13:53] mvo, after I finish beta for 2.28 I'll create a job to run the tests on core i386 and amd64 [13:55] jdstrand, regarding the opengl stuff, note that mir works fine with the fixed udev rule (but we perhaps still want to allow access to these platform paths for other apps that rely on them) [13:58] ogra_: yeah, read the thread. those other paths seem reasonable for the interface though [13:58] ogra_: thanks [13:58] :) [13:59] mvo, I already reviewed that but it is using the release/2.28 in all the cases [14:01] mvo, and the version that is running in the devices is correct too [14:04] cachio: aha, thanks. strange, I have a look at the snapbuild code, wonder what is going on there [14:06] hm, I can't find any forum tread from the last day discussing snap selfsigning ... I'm missing something? Any pointers of what to search for? :) [14:09] cachio: a PR for you: https://github.com/snapcore/spread-cron/pull/41 :) [14:09] PR spread-cron#41: trigger builds for zesty,artful,trusty as well as xenial [14:09] (I'm up2date on the "External repositories" thread, if that was the one you was talking about.) [14:13] mvo, looking === JoshStrobl|zzz is now known as JoshStrobl [14:30] PR snapd#3853 opened: corecfg: mock "systemctl" in all corecfg tests [14:32] ogra_: saw the PR, does this one work on the first boot? [14:36] mvo: "add --last to snap abort and snap watch" [14:36] mvo: Slightly surprised to see this one in the notes [14:36] mvo: Is it just --last, or --last=foo? [14:36] * niemeyer checks [14:36] sborovkov, on every boot (including the first) ... i added a pre-made snap to your bug for testing [14:37] niemeyer: its "snap --last={install,refresh,remove,try,...} [14:37] niemeyer: so yes, sorry for that, that should have at least an example [14:37] mvo: Ah, okay, no worries.. I'll put an example in [14:37] zyga-ubuntu: please test the new snapd release for Fedora [14:38] I'd like for it to make its way through rather quickly [14:39] ogra_: when you say pre-made snap, you mean gadget snap? Anyway I will pull it and try it out. Thanks a lot! Now there is much better user experience with this. We got a bunch of bugs filed when people ran the image for the first time and it was stuck on login page for a very long time, everone was writing to us that it's broken [14:40] PR snapd#3853 closed: corecfg: mock "systemctl" in all corecfg tests [14:40] sborovkov, yes, a gadget snap with the PR included [14:40] sborovkov, fro userspace you can additionally use the psplash snap to run as a service [14:41] the system will switcxh over from one splash to the other [14:42] ok that's great. this PR is for pi2-gadget only though? [14:46] PR snapd#3854 opened: corecfg: mock "systemctl" in all corecfg tests [14:47] cachio: fwiw, I can reproduce the error, looking now [14:47] ogra_: and I see that while pi3-gadget is still getting new commits, it does not have your commit that allow to build uboot from source for instance? Are they kinda diverging now? [14:48] sborovkov, pi2 and pi3 both have the build-from-source commit ... i dont have the splash PR ready for pi3 yet though [14:49] cachio: I think I know what is going on - we need an update to test-snapd-snapbuild [14:50] ogra_: ah, alright sorry. How different is pi3 gadget snap? If I tried to apply your changes from pi2 PR would it work? We only use pi3 :-( [14:50] cachio: I'm on it [14:50] mvo, nice [14:50] sborovkov, oops, i should have started with pi3 then (i actually thought you do pi2 ... heh) ... i guess it should apply [14:51] mvo, I am going to push a fix for lxd tests [14:51] mvo, testing it now [14:51] cachio: sweet, thank you! [14:51] mvo, it is quite slow here [14:51] cachio: yeah, sorry for that :/ [14:51] cachio: you raised concerns in the PR [14:51] mvo, np :) [14:51] cachio: happy to move it to the nightly suite or something, I just think we need it tested :) [14:52] niemeyer: good news, CE already did the automated test for 2.28~rc1 [14:52] mvo, yes, the idea is to run the whole test suite inside a vm with ubuntu core [14:52] I have to see how to reuse the nested suite [15:01] Pharaoh_Atem: hello, gladly, I'll test it ASAP [15:01] nsg: not about self-signing but about federated / external repositories [15:01] nsg: that topic is related so please look for "external repositories" [15:03] cachio: the base test should work now on the external backends, I will rerun on my sysem [15:03] system [15:03] great [15:04] PR snapd#3845 closed: osutil: AtomicWriter (an io.Writer), and io.Reader versions of AtomicWrite* [15:08] zyga-ubuntu: "the store signs them with an archive key so they can be verified (assertions)" ... I have seen that code from the source but my go skills are not the best so it's a little hard to follow. I guess there must be a public or a key signature somewhere on my computer and/or inside the snapd binary to validate the signature? My question is, where is it and can it be replaced with my own? [15:09] mvo: \o/ [15:10] hm, maybe it's better to ask that instead in the thread... I will do that later :) [15:11] mvo: I'm about half-way though the list, writing a section for each item [15:12] mvo: Will have lunch now and do the rest afterwards [15:13] nsg: its baked into snapd binary [15:13] nsg: you can replace it but then none of the existing snaps will validate === cachio_ is now known as cachio_lunch [15:16] niemeyer: thanks a lot [15:18] I see, so I need to build my own snapd then. In this case it's a feature that no other snaps validate :) (need to re-sign the core snap of course). I will see if I take the time to do this (probably not) ... the alternatives are just "wget ... && snap install --dangerous ..." but that sounded so hacky and I liked to avoid it by making a store for my self. [15:18] nsg, it *is* super hacky, dont do it :) [15:19] yeah, but the other alternatives are to not use snaps at all :\ [15:19] need to have a local repo [15:20] nsg: why do you need this? [15:20] nsg: we understand that some people feel strong about it but most people don't need a local repo today [15:20] nsg: you can create private snaps today [15:21] I like to use snaps at work for example, I must host them inside the network [15:21]