[02:07] <Pharaoh_Atem> Hey everyone, if there's anyone interested in trying out snappy on Fedora, it'd be great if you could test out snapd
[02:07] <Pharaoh_Atem> more details here: https://forum.snapcraft.io/t/call-for-testing-snapd-2-23-on-fedora/127/6
[03:47] <olympionex> does anybody know if there has been any other progress on this snap download connection reset bug? https://bugs.launchpad.net/software-center-agent/+bug/1617765
[03:47] <mup> Bug #1617765: Connections reset when downloading snaps from CDN <Snapcraft:New> <Software Center Agent:New> <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1617765>
[03:49] <olympionex> my experience is similar to the comments from others on that bug, it seems to affect snapcraft being run inside containers in particular
[03:50] <olympionex> have tried both building inside lxd and docker containers and the core snap fails to download the vast majority of the time
[05:04] <morphis_> mwhudson: ping
[05:04] <mup> PR snapd#3151 opened: Small adjustments for debian deb builds and packaging symlink for Debian Sid <Created by morphis> <https://github.com/snapcore/snapd/pull/3151>
[05:15] <mup> PR snapd#3151 closed: Small adjustments for debian deb builds and packaging symlink for Debian Sid <Created by morphis> <Closed by morphis> <https://github.com/snapcore/snapd/pull/3151>
[06:43] <zyga> o/
[06:44] <zyga> mvo: I will take a small detour to check something that gustavo requested (build system tweaks)
[06:44] <zyga> mvo: meanwhile can you do a review on updates to https://github.com/snapcore/snapd/pull/3145
[06:44] <mup> PR snapd#3145: overlord/ifacestate: fix auto-connect during core snap transition <Created by zyga> <https://github.com/snapcore/snapd/pull/3145>
[06:44] <zyga> mvo: and let's plan how to change the plug names on core
[06:44] <zyga> mvo: (i.e. how to test that)
[06:45] <zyga> mvo: so that we don't cauese any regressions with this move
[06:45] <zyga> mvo: after the build system detour I will look at ensuring plug/slot name uniqueness validation
[06:45] <zyga> mvo: we have code for that but apparently it's not used or working
[06:45] <zyga> mvo: (I suspect the way implicit slots are added side-steps that)
[06:46] <mup> PR snapd#3152 opened: store: make hash error message more accurate <Created by mvo5> <https://github.com/snapcore/snapd/pull/3152>
[06:46] <mvo> zyga: ok
[06:57] <sabdfl> mcphail, we will figure out security in wayland
[06:57] <sabdfl> we need to do that anyway to get snaps to be amazing on a GNOME desktop
[06:58] <sabdfl> but we will keep Mir for IoT projects where security and simplicity are the main requirement
[06:58] <zyga> about wayland, I think we could use a test on fedora 25 + wayland to see how the interface shoud look like, I think it will be relatively straightforward
[06:59] <zyga> and try the same on ubuntu with apparmor to see what's to do with confinement
[06:59] <zyga> morphis was recently working on better X11 auth support for snaps
[06:59] <zyga> and that feels in line with similar work for wayland
[07:05] <zyga> mvo: ok, experiment done
[07:06] <zyga> now looking at plut/slot uniqueness again
[07:06] <mvo> thanks zyga
[07:07] <mvo> fgimenez: could you please have a look at 3148? it needs a second review and is pretty simple (I hope :)
[07:07] <Aimilius> Hello, I'm trying to update the snapd PKGBUILD on archlinux form 2.21 to 2.23.6. I removed the biuld patches that move the /snap dir to /var/lib/snapd/snap and updated the verison number. Everytime I would try to build snapd, I would get a linking error I cannot resolve. https://pastebin.com/YY3Pa3U8
[07:07] <fgimenez> mvo: sure on it
[07:08] <mvo> fgimenez: btw, is the re-exec spread-cron happy now? with the new snapd now being build?
[07:08] <zyga> Aimilius: hello! welcome :-) looking at the diff
[07:08] <zyga> er, log :)
[07:09] <zyga> Aimilius: aha, I think I know what's wrong
[07:09] <Aimilius> That was quick :)
[07:09] <zyga> Aimilius: can you do a master snapshot pleaes
[07:09] <zyga> Aimilius: I landed a PR that makes the build system more flexible
[07:09] <zyga> Aimilius: look at cmd/autogen.sh
[07:10] <fgimenez> mvo: nope it seems to have the same errors https://travis-ci.org/snapcore/spread-cron/builds/219549331
[07:10] <zyga> Aimilius: the problem is related to the set of libraries that are linked into snap-confine statically
[07:10] <zyga> Aimilius: in master each library (that can) has a knob to control if it is linked dynamically or statically
[07:10] <zyga> Aimilius: and the defaults are all dynamically as that is most easy to compile on all distributions
[07:10] <zyga> Aimilius: in 2.23.6 that wasn't the case
[07:11] <zyga> Aimilius: we are working on 2.24 now (not sure if it goes out today as we found some old bugs last night and want to fix them) but if you take master you will have a better chance at building it
[07:11] <Aimilius> zyga: I'm trying to rebuild now
[07:11] <zyga> Aimilius: excellent!
[07:12] <fgimenez> mvo: snapd 2.23.6+201704061805.git.996da23~ubuntu16.04.1 in that execution, is that ok?
[07:13] <mvo> fgimenez: that sounds good
[07:15] <Aimilius> Master builds fine, though some checks fail
[07:17] <Aimilius> I believe they are about apparmor confinement (test_restrictions test_complain_missed and test_unrestriced_missed, so I didn't excpect that would work
[07:17] <mvo> zyga: one quick question in your 3145 PR - if correct I can quickly push a branch for core
[07:18] <zyga> mvo: looking
[07:18] <Aimilius> Oh, they're about the linux-grsec restrictions
[07:18] <Aimilius> So everything works fine
[07:18] <zyga> mvo: yes, that's correct, also replied there
[07:18] <zyga> Aimilius: those are about seccomp I think
[07:18] <zyga> Aimilius: aha
[07:19] <zyga> Aimilius: interesting, feel free to report those on the forum, I'm sure the security team will be interested in them
[07:19] <Aimilius> zyga: I've got linux-grsec installed, that blocks unpriviliged dmesg access
[07:19] <zyga> aha
[07:19] <Aimilius> zyga: The test-suites try to access dmesg, so that doesn't work
[07:19] <mvo> zyga: ta, I will push a branch for core with that fix
[07:19] <zyga> mvo: OK
[07:20] <Aimilius> zyga: I think on plain linux (without grsecurity) it'll work fine
[07:21] <zyga> mvo: branch with plug/slot uniqueness enforcement on AddPlug/AddSlot is almost ready
[07:28] <mvo> zyga: it looks like snapcraft.yaml does not allow to use: "plugs: network-bind-hook: interface: network-bind" :/
[07:29] <mvo> zyga: the valications allows only flat strings arrays
[07:29] <mvo> zyga: whichi is very stange
[07:29] <kristbaum_> jdstrand I have had an "review pending" on my snap for five or six days. Is this normal, should I change something? I just wanted to try and upload an beta of mdt for testing.. it's namespace is mdt.kristbaum.
[07:30] <mvo> zyga: hm, looks like its just a bit of a strange syntax
[07:31] <zyga> mvo: no, you need to spell that differently
[07:31] <zyga> mvo: like this:
[07:31] <mvo> zyga: yeah, silly me
[07:31] <zyga> mvo: plugs:\n  network-bind-plug:\n    interface: network-bind
[07:33] <Aimilius> zyga: After a build on clean linux (without-grsecurity) the tests still fail. https://pastebin.com/WH1JBmMe
[07:34] <mup> PR core#32 opened: Rename core-support,network-bind plugs to make them unique <Created by mvo5> <https://github.com/snapcore/core/pull/32>
[07:35] <zyga> mvo: have a look at https://github.com/snapcore/snapd/pull/3153 please
[07:35] <mup> PR snapd#3153: interfaces: validate plug/slot uniqueness <Created by zyga> <https://github.com/snapcore/snapd/pull/3153>
[07:36] <mup> PR snapd#3153 opened: interfaces: validate plug/slot uniqueness <Created by zyga> <https://github.com/snapcore/snapd/pull/3153>
[07:36] <zyga> Aimilius: hmm, can you please open a topic for that on https://forum.snapcraft.io/ - make sure to report the kernel version used
[07:36] <zyga> Aimilius: we may carry some seccomp fixes
[07:36] <zyga> Aimilius: not sure yet, we'll check it out
[07:36] <Aimilius> Ok, I'll open a topic
[07:36] <zyga> morphis: ^^ have a look please
[07:36] <Aimilius> zyga: uname -a Linux glorfindel 4.9.20-1-lts #1 SMP Fri Mar 31 15:23:31 CEST 2017 x86_64 GNU/Linux
[07:37] <zyga> mvo: note that this branch may be a flag day for core revert
[07:37] <zyga> mvo: as previous core won't validate and because the plugs are explicitly defined and slots are implicitly added later, may be dysfunctional (no network-bind slot, no core-support slot)
[07:38] <zyga> mvo: I can do a separate patch that fixes this by detecting it and changing the snap via implicit.go
[07:38] <zyga> mvo: let me know what you think
[07:39] <zyga> mvo: I also thing we could use a `snap --validate ./path/to/file.snap` command
[07:39] <zyga> (^ internal hidden thing maybe)
[07:40] <mvo> zyga: hm, if we need a flag day we need to think about this more carefully, maybe a HO in a bit for some brainstorm?
[07:41] <zyga> mvo: yes
[07:41] <zyga> mvo: I think we can avoid it
[07:41] <zyga> mvo: if we teach snapd to just rename those two plugs
[07:41] <zyga> mvo: (core:network-bind -> core:network-bind-plug) (same for core-support)
[07:41] <zyga> mvo: then no flag day needed
[07:41] <zyga> mvo: do you want to jump into a HO to discuss?
[07:43] <zyga> mvo: I'm in the standup HO if you want to
[07:44] <mvo> zyga: yes, one minute, just addressing some things
[07:44] <zyga> mvo: though sligthly complex, depending on where we do this exactly
[07:44] <mup> PR core#32 closed: Rename core-support,network-bind plugs to make them unique <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/core/pull/32>
[07:52] <morphis> Aimilius, zyga: looking
[07:54] <Aimilius> I posted a topic on the forum here: https://forum.snapcraft.io/t/checks-fail-on-arch-linux/200/1
[07:58] <morphis> Aimilius: thanks, will respond there once I find something
[07:58] <Aimilius> morphis: thanks for your effort
[07:58] <morphis> np
[08:00] <morphis> Aimilius: you're not building on a kernel with AppArmor support, right?
[08:01] <Aimilius> zgrep APPARMOR /proc/config.gz # CONFIG_SECURITY_APPARMOR is not set
[08:01] <Aimilius> morphis: though I do use apparmor
[08:01] <morphis> Aimilius: ok, then you should compile snap-confine with --disable-apparmor
[08:01] <morphis> Aimilius: how when the kernel side support is disabled?
[08:02] <Aimilius> I normally run linux-grsecurity with apparmor compiled
[08:02] <Aimilius> But the tests didn't like the dmesg restrictions so I booted my normal kernel without grsecurity and apparmor
[08:03] <morphis> Aimilius: ok, when you don't have AppArmor in the kernel you should build with --disable-apparmor --disable-seccomp
[08:03] <Aimilius> morphis: I'm running this command to build snap-confine ./autogen.sh --prefix=/usr --disable-apparmor --enable-merged-usr
[08:03] <morphis> we don't have runtime detection (yet)
[08:03] <morphis> please add --disable-seccomp too
[08:03] <zyga> morphis: without apparmor the seccomp tests wont run either, I think the logic there assumes both
[08:04] <Aimilius> morphis: does snap-confine depend on out-of-tree seccomp patches
[08:04] <Aimilius> morphis: because the arch kernel does support seccomp
[08:04] <Aimilius> morphis; and I have libseccomp installed
[08:04] <morphis> Aimilius: the problem is that only using seccomp will unhide a few problems nobody didn't look into yet
[08:04] <morphis> safest is to disable both right now
[08:05] <Aimilius> Ok, rebuilding
[08:06] <Aimilius> morphis: if I add --disable-seccomp, the checks still fail
[08:06] <morphis> Aimilius: ok
[08:06] <morphis> Aimilius: can you paste the log output for that?
[08:06] <Aimilius> morphis: sure
[08:07] <mcphail> sabdfl: thanks. Sorry Plan A didn't work out. Loved what you were trying to do
[08:07] <Aimilius> morphis: https://pastebin.com/v2sh2f7Z
[08:10] <morphis> Aimilius: will look in a bit
[08:11] <Aimilius> morphis: I'll have to go leave soon
[08:11] <morphis> Aimilius: ok
[08:11] <Aimilius> But I'll look at the forum this afternoon
[08:11] <morphis> Aimilius: I will see that I get an Arch setup and try to reproduce
[08:12] <Aimilius> morphis: Shall I post my PKGBUILD?
[08:12] <morphis> Aimilius: please!
[08:13] <Aimilius> morphis: https://pastebin.com/qRRNSYmz
[08:13] <Aimilius> I use a ugly hack to install the systemd unit files
[08:13] <morphis> Aimilius: ok, we have something better for this in 2.24
[08:13] <Aimilius> morphis: But with the --nocheck option, it appears to install
[08:13] <Aimilius> morphis: great to hear
[08:14] <morphis> Aimilius: something like make -C data/systemd DESTDIR=... install will do the job then
[08:14] <Aimilius> morphis: that was what I did
[08:14] <morphis> ah
[08:14] <Aimilius> morphis: with SYSTEMDUNITDIR=/usr/lib/systemd/system, because of the usr merge
[08:14] <morphis> ok, that is then what you should do
[08:15] <Aimilius> But it felt like I shouldn't use a Makefile there
[08:18] <zyga> mvo: have a look a tthis please https://github.com/snapcore/snapd/compare/master...zyga:rename-clashing-core-plugs?expand=1
[08:18] <zyga> mvo: that's what I was thinking about (tests WIP)
[08:18] <zyga> mvo: essentially this is the essence: https://github.com/snapcore/snapd/commit/59ae873d82883f8887ac7c55bead62e60ab749f6
[08:18] <zyga> (the last two patches are new in this brancH)
[08:34] <Kristbaum__> Is somebody here that is responsible for manual reviews in the snap store?
[08:39] <zyga> Kristbaum__: I think so
[08:40] <zyga> Kristbaum__: I think you may have better luck on forum.snapcraft.io, using the "store" category
[08:40] <zyga> Kristbaum__: as they are in different timezones
[08:40] <zyga> Kristbaum__: and you may get more organized replies there
[08:43] <Kristbaum__> zygra okay will try that
[08:45] <zyga> Kristbaum__: thanks!
[09:03] <zyga> mvo: I'm adding tests to RenamePlug
[09:09] <zyga> mvo: adding tests to ifacestate
[09:11] <morphis> actually running snapd spread tests in QEMU doesn't look much reliable these days ..
[09:12] <zyga> morphis: why? what are you getting?
[09:12] <zyga> morphis: I sometimes get startup errors but if it runs, it is quite reliable
[09:12] <morphis> timeouts for apt-get
[09:12] <morphis> ala "running late"
[09:12] <morphis> sometimes network connectivity dies
[09:12] <morphis> but could be that I have a debian container I am trying to run the tests in
[09:12] <zyga> morphis: late is normal
[09:12] <zyga> morphis: aha, I dind't try it that way
[09:13] <morphis> zyga: should the lxd backend work these days?
[09:13] <Chipaca> morphis— apt update/upgrade the base image to keep the time in check
[09:13] <Chipaca> otherwise each test run does that, and it's hella slow :-)
[09:14] <morphis> Chipaca: yeah doing that right now
[09:14] <Chipaca> (that's a technical term)
[09:14] <pstolowski> mvo, #3070 failed again, the failures seem to be unrelated to the branch, i.e. snap confine test failures, gccgo failures
[09:14] <Chipaca> morphis— niemeyer has a cron job for this, but not sure if it's reusable for qemu
[09:14] <morphis> Chipaca: let me check
[09:15] <zyga> morphis: I don't know
[09:15] <zyga> morphis: we don't exercise it I think
[09:18] <morphis> zyga: ok, worth a try later
[09:18] <morphis> zyga: but I must say using the debian openstack images is working like a charm so far
[09:24] <zyga> morphis: nice!
[09:24] <zyga> morphis: can you add instructions on how to get them to spread-qemu-images please?
[09:24] <morphis> zyga: had to modify the adt-* script a bit but will send a PR for your spread images repo later today or on monday
[09:27] <morphis> zyga: you had a chance to test snapd on fedora yesterday again?
[09:29] <morphis> Son_Goku: any more testing from your side happend? I've added +1 to all three bodhi requests now
[09:30] <zyga> morphis: nice
[09:30] <zyga> morphis: no, I didn't we found a new set of bugs that delayed 2.24 release
[09:30] <zyga> morphis: I'm still working on fixing them
[09:30] <morphis> ok
[09:30] <morphis> zyga: what kind of bugs?
[09:32] <zyga> morphis: https://forum.snapcraft.io/t/duplicate-plug-slot-names-inside-the-core-snap/184/7
[09:34] <zyga> mvo: ok, I'm adding one more correction, I will migrate connection state as well
[09:34] <zyga> mvo: that is done, just adding tests
[09:36] <morphis> zyga: I see
[09:38] <mup> PR snapd#3148 closed: errtracker: never send errtracker reports when running under SNAPPY_TESTING <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3148>
[09:41] <zyga> mvo: ok ready
[09:42] <zyga> mvo: let me open a PR
[09:48] <mvo> pstolowski: some of the test failures in 3070 look real
[09:48] <mvo> zyga: ok
[09:50] <mup> PR snapd#3154 opened: many: rename two core plugs that clash with slot names <Created by zyga> <https://github.com/snapcore/snapd/pull/3154>
[09:50] <zyga> Chipaca: hey, mvo is off now
[09:50] <zyga> Chipaca: I need a hand with critical 2.24 reviews
[09:51] <Chipaca> zyga— shoot
[09:51] <Chipaca> zyga— or i can look myself :-)
[09:51] <Chipaca> on it
[09:52] <zyga> Chipaca: https://github.com/snapcore/snapd/milestone/6
[09:52] <zyga> Chipaca: there are two approaches used
[09:52] <zyga> Chipaca: (and both should land)
[09:52] <zyga> Chipaca: I added one more branch to 2.24
[09:54] <zyga> Chipaca: - rename everything when starting so even old core snap is correct
[09:54] <Chipaca> why is our test suite brittle all of a sudden :-(
[09:54] <zyga> Chipaca: this is done in https://github.com/snapcore/snapd/pull/3154
[09:54] <mup> PR snapd#3154: many: rename two core plugs that clash with slot names <Created by zyga> <https://github.com/snapcore/snapd/pull/3154>
[09:55] <zyga> Chipaca: - validate everything so it doesn't happen again
[09:55] <zyga> Chipaca: https://github.com/snapcore/snapd/pull/3153
[09:55] <mup> PR snapd#3153: interfaces: validate plug/slot uniqueness <Created by zyga> <https://github.com/snapcore/snapd/pull/3153>
[09:55] <zyga> Chipaca: and lastly because we found this by fixing a bug in core transition
[09:55] <Chipaca> snapd#3145 needs niemeyer to re-review i guess
[09:55] <mup> PR snapd#3145: overlord/ifacestate: fix auto-connect during core snap transition <Created by zyga> <https://github.com/snapcore/snapd/pull/3145>
[09:56] <zyga> Chipaca: this branch fixes the damage done there https://github.com/snapcore/snapd/pull/3145/files
[09:56] <Chipaca> (as he marked it as Changes Needed)
[09:57] <zyga> yep
[09:57] <zyga> that's fine
[09:57] <zyga> I want to go through the first round on the two new PRs
[10:03] <Chipaca> zyga— wouldn't it make sense, in snapd#3154, for you to also test RenamePlug for a case where a plug and slot have the same name?
[10:03] <mup> PR snapd#3154: many: rename two core plugs that clash with slot names <Created by zyga> <https://github.com/snapcore/snapd/pull/3154>
[10:03] <tvoss> pedronis: hey there, I was looking into replacing the exec'ing of ssh-keygen with using openssl via CGO as in: http://pastebin.ubuntu.com/24333148/
[10:03] <zyga> Chipaca: sure, can do
[10:03]  * zyga does
[10:03] <tvoss> pedronis: do you have any guidelines on how to use CGo? Like place actual implementation into .c file or some such?
[10:06] <zyga> tvoss: look at...
[10:06] <zyga> tvoss: https://github.com/snapcore/snapd/pull/3095
[10:06] <mup> PR snapd#3095: cmd/snap-update-ns: add C preamble for setns <Created by zyga> <https://github.com/snapcore/snapd/pull/3095>
[10:06] <zyga> Chipaca: ha, I cannot
[10:06] <zyga> Chipaca: it's validated now
[10:07] <zyga> Chipaca: http://pastebin.ubuntu.com/24333233/
[10:09] <tvoss> zyga: ack
[10:09] <Chipaca> zyga— state twiddling direclty?
[10:10] <Chipaca> zyga— or make a for-testing way of overriding the validation
[10:10] <Chipaca> because clearly you can be in that state
[10:10] <Chipaca> so we need to test it
[10:11] <zyga> Chipaca: I'll think of something
[10:11] <zyga> Chipaca: good point about being able to be in that state
[10:11] <Chipaca> zyga— I'm now wanting to check it even more, to make sure we don't break people that are in that state already
[10:12] <zyga> Chipaca: look at the other branches and suggest ideas
[10:13] <zyga> Chipaca: note that it is not strictly speaking "hurtful" to have clashing names
[10:13] <zyga> Chipaca: but we want to get away from that
[10:13] <pedronis> I think it's a matter of order of things in the other branch fixing this
[10:13] <pedronis> but we need to be able to load the state to fix it
[10:13] <Chipaca> zyga— idea: make space probes look futuristic to trick aliens into thinking we're more advanced than we are
[10:13] <zyga> pedronis: state is not validated there (just connections are changed)
[10:14] <zyga> pedronis: and interfaces.ConnRef has no validation
[10:14] <Chipaca> zyga— or did you mean ideas that were relevant to the branch
[10:14] <pedronis> don't we do a big add all the snaps thing
[10:14] <mvo> Chipaca: re brittle> https://forum.snapcraft.io/t/hashsum-failures-during-tests/198 is what I see in a bunch of them
[10:14] <pedronis> zyga: initializes does addSnaps, no?
[10:15] <zyga> pedronis: aha, good point
[10:16] <pedronis> I don't see the aha there but yes, bit of a chicken and egg problem
[10:16] <zyga> Chipaca: ok, I have something for that now
[10:16] <zyga> pedronis: well, if we load core snap and validate it
[10:16] <Chipaca> mvo— D:
[10:16] <zyga> pedronis: it won't reach that point
[10:16] <pedronis> so it explodes
[10:16] <pedronis> is that aha?
[10:17]  * pedronis has probably no sense of humur today
[10:17] <zyga> Chipaca: have a look, just pushed
[10:17]  * Chipaca hugs pedronis 
[10:17] <pedronis> anyway I agree with Gustavo's yesterday point that we need to tread carefully through these fixes
[10:17] <zyga> pedronis: yes, I totally agree
[10:18] <pedronis> will one of our spread tests exercise thiss? like the upgrade one?
[10:18] <zyga> pedronis: spread tests do exercise this already
[10:19] <zyga> pedronis: well, not directly this
[10:19]  * pedronis anyway, lunch
[10:19] <zyga> pedronis: but the branch that adds validation is all read
[10:19] <zyga> red*
[10:19] <zyga> pedronis: because now core doesn't validate anymore
[10:20] <Chipaca> zyga— dude, stop with the Not(IsNIl) :-)
[10:21] <pshod> any way to create env variables or signals that can be accessed by two different processes inside a snap env?
[10:21] <zyga> Chipaca: how should I do it?
[10:21] <Chipaca> zyga— NotNil
[10:22] <Chipaca> zyga— compare the failing output and you'll see what i mean
[10:22] <zyga> Chipaca: oooh, didn't know about it :)
[10:22] <zyga> Chipaca: ack, will do
[10:22] <pshod> my snap exposes a noejs app which spawns a sh script which fires a banary
[10:22] <pshod> binary
[10:23] <Chipaca> pshod— one easy way is to use the filesystem
[10:23] <Chipaca> pshod— that includes, for example, a unix socket
[10:23] <pshod> i am notifying the event by writing into a file
[10:23] <pshod> and then if the file has a particular content
[10:24] <pshod> i close my watch in the node app
[10:24] <pshod> chipaca : the sh script should write unto a socket and the node app listens on the socket?
[10:25] <pshod> zyga: help help help!
[10:25] <Chipaca> pshod— it depends on what you need to do, etc etc
[10:25] <Chipaca> pshod— please tell us more
[10:25] <pshod> ill try to be concise
[10:26] <zyga> pshod: so
[10:26] <zyga> pshod: if you set environment from a running process
[10:26] <Chipaca> pstolowski— “- Download snap "core" (1577) from channel "stable" (unexpected EOF)” <- just got that :-(
[10:26] <pshod> snap exposes a node app -> spawns a sh script that fires a binary->binary reads data from a sensor and writes into a file in SNAP_COMMON->node app reads the file and posts to a REST server
[10:26] <zyga> pshod: you cannot just "see" that easily in other processes without looking at /proc
[10:27] <zyga> pshod: not sure what you meant by a signal
[10:27] <zyga> pshod: tell me what you want to achieve
[10:27] <Chipaca> pshod— with you so far
[10:27] <zyga> pshod: (not how)
[10:27] <zyga> pshod: and we'll recommend osmething
[10:27] <pstolowski> Chipaca, is this with current code, or latest release?
[10:27] <Chipaca> pstolowski— https://travis-ci.org/snapcore/snapd/builds/219327815
[10:28] <pshod> no the node app is configurable..we pass the number of tmes the binary writes into the fuke
[10:28] <pshod> file*
[10:28] <Chipaca> pstolowski— upgrade/basic failed with that
[10:28] <pshod> now what I have done is, i modifies the sensor binary so that after writing the said "n" observations into the file
[10:28] <zyga> Chipaca: https://github.com/snapcore/snapd/pull/3154#discussion_r110359632 (updated and added tests)
[10:28] <mup> PR snapd#3154: many: rename two core plugs that clash with slot names <Created by zyga> <https://github.com/snapcore/snapd/pull/3154>
[10:28] <pshod> overwriting*
[10:28] <pshod> it writes "Closing Session"
[10:29] <pshod> so when i read the file from SNAP_COMMON
[10:29] <pshod> and see it's contents as "Clossing Session" I remove the watch from SNAP_COMMON and my node app exits gracefully
[10:29] <pstolowski> Chipaca, uhm. not good. would be great to find out how to provoke 'unexpected eof' in the test. what I did recently was a test with closing client connections, and that triggers normal EOF
[10:30] <pshod> people dont like this design and I am not pretty confident about it too
[10:30] <pshod> :|
[10:30] <Chipaca> pstolowski— send a RST
[10:30] <zyga> pshod: today I'm focusing on 2.24 release and I don't have much time to help
[10:30] <Chipaca> pshod— ah, so this is what you're doing now and you need to improve it?
[10:30] <zyga> pshod: maybe ask on the forum and we'll get to that
[10:31] <Chipaca> pshod— yeah, maybe it's better as a forum question, rather long-winded for here
[10:31] <pshod> zyga : hey thank you!
[10:31] <Chipaca> pshod— nothing wrong with the file-based approach as long as you're using locking appropriately
[10:31] <Chipaca> pshod— but there are other ways, sure
[10:31] <pshod> zyga: have gotten much help from you in the past :D
[10:32] <zyga> pshod: I'll gladly help next week but I need to focus on fixing something we just found out that is affecting core
[10:32] <zyga> pshod: namely https://forum.snapcraft.io/t/duplicate-plug-slot-names-inside-the-core-snap/184/6
[10:32] <Chipaca> pstolowski— no i don't know *how* to send a RST, i know a RST is the usual cause for that unexpected eof
[10:32] <zyga> pshod: we won't release today (Friday = bad idea) but I want it to be ready
[10:32] <pshod> chipaca : locking is done properly, I suggested we just update a variable which gets updated when API for posting is called
[10:32] <zyga> pstolowski: network throttling things sent RSTs to kill connections
[10:32] <pstolowski> Chipaca, exactly... i'll look into that later, thanks. in the meantime - E_TOOMANYISSUES_ATM
[10:32] <pshod> but that was rejected too.
[10:33] <pshod> zyga : duplicate plug names
[10:33] <Chipaca> pshod— ok, open a forum thread, write everything out there please
[10:33] <pshod> zyga: sounds too much of fun :P
[10:33] <pshod> chipaca : on it
[10:34] <Chipaca> pshod— what you want to achieve, what you are doing now, why it was rejected/requested to be improved, what other things were proposed but also rejected
[10:34] <zyga> pedronis, Chipaca, pstolowski, mvo: I'm looking for proposals on how to fix the chicken/egg problem on core's snap.yaml: we need to load an invalid file to fix it
[10:34] <Chipaca> pshod— the 'what you want to achieve' there is missing in what you've written so far, afaict
[10:34] <zyga> my naive idea is to add a way to load snap.Info that's invalid
[10:34] <zyga> use that on the core snap only
[10:34] <zyga> and apply the fix right there
[10:34] <zyga> (the fix is currently in interface manager but it should move to snap manager)
[10:35] <mvo> zyga: how about a forum.snapcraft.io topic? to have an archived discussion?
[10:35] <zyga> mvo: +1
[10:35] <pshod> chipaca : will do it like that
[10:36] <mup> PR core#32 opened: Rename core-support,network-bind plugs to make them unique <Created by mvo5> <https://github.com/snapcore/core/pull/32>
[10:38] <zyga> commented on the forum about it
[10:38] <zyga> https://forum.snapcraft.io/t/duplicate-plug-slot-names-inside-the-core-snap/184/9?u=zyga
[10:39] <pshod> chipaca : wont i be able to register using my company id?
[10:40] <Chipaca> pshod— I don't know. It's not (yet) tied into login.ubuntu.com, if that is what you mean
[10:50] <Chipaca> zyga— what calls snap.Validate on startup?
[10:56] <mikeb_> Hi, I need some help with snapcraft.yaml syntax.  I'm trying to implement a command wrapper to start my apps.  I'm trying to pass a command and its arguments to the wrapper, but I can't get the syntax correct.  For example -  command: usr/bin/mywrapper --wrapper-arg1 --wrapper-arg2  --exec '$SNAP/usr/bin/cmd --cmd-arg1 --cmd-arg2'.  Snapd parses cmd-arg1 and cmd-arg2 as arguments to usr/bin/mywrapper.  What is the syntax to put them al
[10:56] <mikeb_> What is the syntax to put them all in the string as the --exec argument?
[10:57] <zyga> Chipaca: when you load the state, I think that's in snapmgr somewhere
[10:57] <zyga> Chipaca: look at the interface manager, it asks for all the snaps and adds active ones to the repository
[10:57] <zyga> Chipaca: with the validation code in place we will naver reach that spot
[10:57] <zyga> Chipaca: as we will crash and burn on invalid core
[10:57] <Chipaca> mikeb_— can you share the yaml in a pastebin?
[10:58] <mikeb_> Chipaca: sure
[10:59] <Chipaca> zyga— I see interface/repo.go:73 calling ValidateName, but no Validate call
[10:59] <Chipaca> interfaces*
[10:59] <pshod> chipaca : i should tag my entry as "other"?
[11:00] <mikeb_> https://pastebin.com/GhCBe4Gd
[11:01] <Chipaca> mikeb_— ok, that seems alright. Can you show me the .service file that gets generated?
[11:03] <mikeb_> Chpaca: is the generate service file located in the prime area? Or is it generated at snap install time?
[11:05] <Chipaca> mikeb_— it'll be in /etc/systemd/system
[11:05] <Chipaca> mikeb_— called something obvious
[11:05] <Chipaca> mikeb_— ah, at install itme
[11:05] <Chipaca> time*
[11:06] <mikeb_> Chipaca: my install is failing, so I can't get to it.
[11:07] <Chipaca> ah
[11:07] <Chipaca> mikeb_— how is it failing?
[11:07] <mikeb_> Chpaca: https://pastebin.com/4Ufw8WcE
[11:10] <Chipaca> mikeb_— that happens on 'snap install', i take it
[11:10] <Chipaca> or snap try
[11:10] <mikeb_> Chipaca: snap install
[11:11] <mikeb_> Chipaca: on a Ubuntu-core system
[11:11] <Chipaca> mikeb_— so, what's *probably* happening is that the quoting there reaches the .service file intact, and then systemd reads it wrong
[11:11] <Chipaca> I need to test this
[11:11] <Chipaca> give me a bit
[11:11] <Chipaca> (it's a bug at our end, but there's a workaround if this is the case)
[11:11] <mikeb_> Chipaca: okay.  Thanks!
[11:13]  * zyga will work on fixing the migration situation after lunch
[11:13] <zyga> ttyl!
[11:14] <pedronis> zyga: rememeber that we setup-profiles twice for core
[11:14] <pedronis> the first time with old snapd code
[11:14] <pedronis> the 2nd with new snapd code
[11:14] <pedronis> and that one has passed managers init at that point
[11:14] <zyga> pedronis: good point
[11:14] <zyga> pedronis: thank you!
[11:15] <pedronis> so need to think a bit exactly what sees what here
[11:15] <zyga> pedronis: let's discuss this at the call, I think (all) of PRs are unlikely to land today
[11:15] <Chipaca> mikeb_— huh, that's strange. When trying to do this myself I get an error.
[11:15] <Chipaca> mikeb_— in that the command can't contain quotes
[11:16] <Chipaca> mikeb_— so maybe you're in an older version that didn't validate this? i'd say move the long command into a shell script and use that as the command in the yaml
[11:16] <mikeb_> Chipaca: FYI context - I have a snap that is made up of many .deb packages all with services to start up.  I'm trying to come up with a wrapper that will deal with service before/after/wants/requires/etc as well as the various preinst/postinst/prerm/postrm/etc
[11:18] <pedronis> zyga: I mean it might turn out that is less to do that we think,  (some fixes don't make sense), though there's the no reexec case as well to keep in mind, we don't reexec everywhere yet, do we?
[11:18] <mikeb_> Chipaca: I'm running snapcraft 2.28
[11:18] <Chipaca> mikeb_— sound slike fun
[11:19] <Chipaca> mikeb_— I get this: error: cannot read snap info for /home/john/canonical/snappy/src/github.com/snapcore/snapd/tests/lib/snaps/test-snapd-service: app description field 'command' contains illegal "bin/start foo bar \"baz quux\"" (legal: '^[A-Za-z0-9/. _#:-]*$')
[11:20] <mikeb_> Chipaca:  The upstream packages are still changing a lot.  It's more fun to try to manually translate all the service and inst files to snapcraft apps:
[11:21] <pedronis> Chipaca: seems indeed that we don't support quotes in commands
[11:21] <pedronis> (never did I think,  maybe we need to ? )
[11:21] <mikeb_> Chipaca: That's unfortunate...
[11:23] <Chipaca> mikeb_— however, note you can set a per-app 'environment' entry that does have quotes
[11:24] <pedronis> Chipaca: not sure though that env var in a command do the right thing
[11:25] <Chipaca> pedronis— they get set in the environ of the service
[11:25] <mikeb_> Chipaca: I hadn't thought to escape my quotes in the yaml file.  That actually seems to be working... almost.  Give me a few to play around a bit more.
[11:25] <pedronis> though you can always use a wrapper
[11:25] <Chipaca> Apr 07 12:25:33 fogey snap[17032]: FOO=$'there once was a man from nantucket\nwho was very bad at limericks\n'
[11:26] <Chipaca> ^ that's from
[11:26] <Chipaca>   environment:
[11:26] <Chipaca>     FOO: |
[11:26] <Chipaca>       there once was a man from nantucket
[11:26] <Chipaca>       who was very bad at limericks
[11:26] <Chipaca> makes it all the way through, newlines and all
[11:27] <pedronis> Chipaca: sorry, what I was saying is that I don't know if:  command: bin/x $FOO   works
[11:27] <pedronis> (I suspect not, might be wrong)
[11:27] <Chipaca> pedronis— no because $ is not in [A-Za-z0-9/. _#:-]
[11:27] <pedronis> even if it were
[11:28] <Chipaca> mikeb_— what version of snapd are you on? (output of “snap version”)
[11:29] <Chipaca> pedronis— and, no, environment key is applied by snap run, not by systemd
[11:30] <pedronis> Chipaca: I don't I understand your suggestion, I mean, it's not a direct transformation
[11:30] <pedronis> Chipaca: cannot tunr    bin/x "a b"   into   FOO="a b"  bin/x $FOO
[11:30] <Chipaca> pedronis— mikeb_ is writing a wrapper for a bunch of services
[11:31] <Chipaca> pedronis— for a single snap to handle ordering of services itself
[11:31] <mikeb_> Chipaca: snapd 2.23.6
[11:31] <Chipaca> as we don't expose ordering
[11:31] <mikeb_> among other things...
[11:31] <pedronis> Chipaca: I think I should give up helping, I don't have context
[11:31] <Chipaca> pedronis— as such, he's currently taking a bunch of options to his script from the commandline itself
[11:32] <Chipaca> but we dont' support that (and apparently we've introduced a breaking change around this between 2.23.6 and now? i need to dig a little)
[11:32] <pedronis> ah, ok, I though it was tryign to call directly something not under his control
[11:32] <Chipaca> pedronis— but instead they *could* take it from environ
[11:32] <pedronis> yes
[11:32] <Chipaca> it's probably not as nice
[11:33] <Chipaca> k? k.
[11:33] <Chipaca> :-)
[11:33] <pedronis> working beats nice, I suppose
[11:33] <Chipaca> mikeb_— I'm on 2.23.6 as well. something doesn't add up :-/
[11:33] <Chipaca> ah
[11:33] <pedronis> seems there's confusion around env from yaml working or not
[11:33] <Chipaca> mikeb_— what's in your *snap.yaml*?
[11:33] <Chipaca> mikeb_— in prime/meta/snap.yaml
[11:34] <pedronis> I have seen an open topic about that
[11:34] <Chipaca> mup— poke kyrofa
[11:34] <Chipaca> ah, no ldap
[11:34] <pedronis> https://forum.snapcraft.io/t/declaratively-defining-environment-variables/175/3
[11:35] <Chipaca> it's 4am for kyle, i'll ask later
[11:35] <pedronis> it actually pings you at the end
[11:35] <pedronis> that topic
[11:35] <Chipaca> me? nevah!
[11:35] <pedronis> fwiw
[11:35]  * Chipaca looks
[11:35] <pedronis> well Gustavo does
[11:35] <mikeb_> Chipaca: With the escaped quotes, it seems to be working as I intended.  I'm trying to fix some bugs in my test code right now, but the '--cmd' seems to be getting through now.
[11:36] <Chipaca> mikeb_— i suspect snapcraft might be helping, hence me asking for your snap.yaml :-)
[11:41] <mikeb_> Chipaca: Sorry, had to deal with an interrupt.  snap.yaml on the way.
[11:41] <Chipaca> mikeb_— no worries
[11:41] <Chipaca> speaking of interrupts, lunch would be nice sometime
[11:41] <Son_Goku> anyone have any idea why I'm getting this error?
[11:41] <Son_Goku> - Download snap "core" (1577) from channel "stable" (sha3-384 mismatch after patching "core": got 3ca758bb05ff3a422fffa2c02018aaf63909417180b3e902eaddcf0cbc4d4c317bfe26ac5c39567bc69abb94ece0d1e8 but expected cbdff81206101ef7063f2f91a4c3f36e1ad946fe8a809eca4c21fa5335968dfc0c696e5f364cbc9a4c83590aceb3fc15)
[11:41] <Chipaca> Son_Goku— in tests, or in real life?
[11:41] <zyga> re
[11:41] <Son_Goku> real life
[11:41] <Chipaca> whee
[11:42] <Son_Goku> I'm trying to do "sudo snap install hello-world"
[11:42] <Son_Goku> snapd 2.23.6 + Fedora 25
[11:42] <Chipaca> Son_Goku— you crazy bleeding-edger you
[11:42] <zyga> pedronis: we don't reexec everywhere (reading backlog and responding)
[11:42] <Chipaca> :-)
[11:42] <Chipaca> Son_Goku— can you pastebin `journalctl -u snapd`? the bit around the install in particular, not the whole thing :-)
[11:43] <zyga> Son_Goku: I think there's some issue in deltas
[11:43] <zyga> Son_Goku: I saw michael do some changes there today
[11:43] <Chipaca> zyga— michael's change is around the error, which always mentions deltas even if it's not a delta
[11:43] <zyga> Son_Goku: hey man :) nice to see you today
[11:43] <zyga> hah
[11:44] <zyga> I mean, "aha"
[11:44] <Chipaca> zyga— you can mean both
[11:44] <mikeb_> Chipaca:  https://pastebin.com/fc9jN3wd - I added prime/command-test-daemonize-notify.wrapper to the end of the paste.
[11:44] <Chipaca> riiight
[11:44] <zyga> ok, I'll get back to the key issue at hand
[11:44] <Chipaca> mikeb_— so snapcraft is wrapping things for you
[11:44] <Chipaca> mikeb_— that's why you're not seeing the error about using quotes in there :-)
[11:44] <Chipaca> but it's doing a bad job of it
[11:45] <Chipaca> :-)
[11:45] <Son_Goku> Chipaca, zyga: https://paste.fedoraproject.org/paste/hzxtldZltZyI94LRqVeKr15M1UNdIGYhyRLivL9gydE=
[11:45] <mikeb_> Chipaca: yes, wrapper for a wrapper for a command.  Fun.  Doesn't snapcraft always generate wrappers for commands?
[11:46] <Chipaca> mikeb_— probably, yes
[11:46] <zyga> mikeb_: there's a plan to stop that eventually
[11:47] <morphis> Son_Goku: doesn't look good but maybe because of a network error?
[11:47] <morphis> didn't had problems here switching between different core's
[11:47]  * Son_Goku shrugs
[11:47] <zyga> how do we compute the has? internally?
[11:48] <zyga> maybe bug in golang that's fixed in ubuntu or maybe different (subtly) output in an external program?
[11:48] <zyga> maybe delta?
[11:48] <Son_Goku> well, we're on golang 1.7.5 on Fedora 25
[11:49] <zyga> Son_Goku: the reverse may be true :-)
[11:49] <Son_Goku> it could also just be this VM, but I doubt it
[11:50] <Son_Goku> well fuck it
[11:50] <Son_Goku> a reboot fixed everything
[11:50]  * Son_Goku shrugs
[11:51] <Son_Goku> Chipaca: lol i dunno anymore
[11:51] <Son_Goku> maybe my VM was screwy?
[11:51] <morphis> possible
[11:51] <morphis> seeing some network issues from time to time here
[11:51] <Son_Goku> I could have just been lucky, I guess
[11:52] <Chipaca> fwiw
[11:52] <Chipaca> we're getting that error in tests
[11:52] <Chipaca> occasionally
[11:52] <Chipaca> i suspect the cdn
[11:52] <Son_Goku> huh
[11:52] <Son_Goku> maybe related, then
[11:52] <Son_Goku> well, that would explain corruption in the core snap download
[11:52] <Chipaca> mhmm
[11:52] <Son_Goku> and when I tried to fetch it myself, nothing happened :?
[11:53] <Son_Goku> it timed out
[11:53] <Chipaca> encouraging
[11:53] <Son_Goku> well, it worked this time
[11:53] <davidcalle> Can someone on 16.04 check if snap:// links work? http://www.omgubuntu.co.uk/2017/02/snap-url-support-coming-ubuntu-software-app-plus-love-news
[11:53] <Son_Goku> so at least it passed the smell test
[11:53] <Chipaca> Son_Goku— that does not make it better (in fact, the opposite :) )
[11:54] <Son_Goku> Chipaca: I know :(
[11:54] <Son_Goku> but I'm trying to make sure I didn't screw up everything with my Fedora packaging changes
[11:54] <Son_Goku> ;)
[11:54] <Chipaca> davidcalle— I'm on 16.04, clicked the snap link, it went to xdg-open, which laughed a very deep laugh
[11:55] <Son_Goku> haha
[11:55] <Son_Goku> actually, this is interesting
[11:55] <Chipaca> davidcalle— actually it returned 0, no error output, so it seems to *think* it worked
[11:55] <Son_Goku> snapd forced my VM's resolution down to 800x600
[11:55] <Son_Goku> wtf
[11:55] <davidcalle> Chipaca, ahaha, ok, no software center popping up?
[11:55] <Chipaca> davidcalle— correct
[11:56] <Chipaca> Son_Goku— you need to scale the qubit's strangeness down a notch
[11:56] <Chipaca> damn quantum-entangled snapd
[11:56] <morphis> Son_Goku: really?
[11:57] <davidcalle> Chipaca: thanks for the gunea pigging :)
[11:57] <Son_Goku> morphis: yes really
[11:57] <morphis> Son_Goku: do you have the vbox drivers installed?
[11:57] <Son_Goku> it happened the moment the core snap finished installing
[11:57] <morphis> Son_Goku: anything in dmesg/journal?
[11:57] <Son_Goku> no, this is VMware Fusion, so open-vm-tools and regular vmware drivers are used
[11:58] <zyga> Son_Goku: log out and log in without wayland
[11:58] <Son_Goku> I'm using Plasma, with Xorg
[11:59] <zyga> Son_Goku: hmm, then no idea
[11:59] <zyga> Son_Goku: snapd doesn't touch anything X related
[11:59] <zyga> Son_Goku: does it work if you remove snapd and reboot?
[11:59] <Son_Goku> well, everything is fine *after* installing the core snap
[12:00] <Son_Goku> it's just the act of installing the core snap seems to snap the resolution down to what it is when sddm is launched
[12:00] <Chipaca> davidcalle— oink oink (or, rather, squee squee)
[12:00] <Son_Goku> sddm is Wayland, I think
[12:00] <zyga> sddm?
[12:00] <Son_Goku> sddm, Simple Desktop Display Manager
[12:00] <Son_Goku> from the Hawaii OS (now Liri OS) guys
[12:00] <Son_Goku> it replaced kdm for Plasma 5
[12:01]  * zyga says "maaagic"
[12:01] <zyga> no idea,
[12:02] <morphis> Son_Goku: btw. can you check with a gui snap too on KDE
[12:02] <Son_Goku> lol i dunno
[12:02] <morphis> Son_Goku: like krita
[12:02] <Son_Goku> morphis: I'm playing ohmygiraffe :)
[12:03] <morphis> Son_Goku: good, so we're not affected by https://bugzilla.opensuse.org/show_bug.cgi?id=1031501#c3
[12:04] <Son_Goku> we probably will be once Fedora 25 transitions to Plasma 5.9
[12:05] <Son_Goku> morphis: Plasma 5.9 tightens the security a little bit
[12:05] <Son_Goku> I'm still on Plasma 5.8
[12:06] <Son_Goku> it'll probably fail on Fedora 26 KDE, you should try
[12:06] <morphis> Son_Goku: yeah maybe
[12:06] <morphis> Son_Goku: if it does we have a fix for that upcoming
[12:06] <morphis> not 2.24 bur 2.25 maybe
[12:06] <morphis> jdstrand: ping
[12:08] <Son_Goku> morphis, zyga: anyway, I can't give karma for the snapd updates, so I need you guys to do so and find someone get it up to +3 across the board
[12:09] <Son_Goku> and it has to be someone with a FAS account, because anonymous karma doesn't count for karma :/
[12:09] <morphis> Son_Goku: yes, I gave +1 already
[12:09] <morphis> Son_Goku: you think you can find someone
[12:09] <Son_Goku> I'm going to try
[12:11] <Son_Goku> morphis: zyga's karma was zeroed out, so he has to do it again
[12:14] <morphis> yes
[12:14] <morphis> Son_Goku: I've asked him already but he seems to be under time pressure to get things fixed for 2.24
[12:14] <zyga> yes, sorry
[12:14] <morphis> np
[12:14] <Son_Goku> it only takes a couple of minutes to hit +1s for everything, since he's already tested it :)
[12:14] <zyga> the clashing names need to be fixed really urgently
[12:14] <zyga> Son_Goku: I didn't really test the new packages
[12:15] <zyga> Son_Goku: I'd like to really test them before +1
[12:15] <zyga> Son_Goku: (I mean after the next upload)
[12:15] <Son_Goku> the only change is that I added the scriptlet to autostart them
[12:15] <zyga> ah
[12:15] <Son_Goku> well, and I bumped to snapd-glib 1.10, but we can't really test that with anything
[12:15] <zyga> well, I'll +1 after testing it at least once still :)
[12:15] <zyga> that's the point of the process
[12:15] <Son_Goku> right
[12:16] <Son_Goku> I just bundled that update with it because I want the buildsystem error emails to go away...
[12:16] <Son_Goku> err, dependency error emails
[12:16] <zyga> (not talking about glib specifically)
[12:17] <Son_Goku> right
[12:18] <Son_Goku> well, the sooner snapd and snapd-glib hit stable, the sooner that gnome-software can move to using it entirely
[12:18] <Son_Goku> (snapd-glib, I mean)
[12:18] <Son_Goku> because then hughsie will be able to test against it
[12:22] <zyga> pedronis: looking at snap/*.go, we don't seem to validate loaded yaml's
[12:23] <zyga> pedronis: validation is in ReadInfoFromSnapFile but I don't see any calls to that yet
[12:24] <zyga> pedronis: specifically if you look at ReadInfo which is defined just above
[12:24] <zyga> pedronis: we just don't validate it
[12:24] <zyga> pedronis: and ReadInfo is used in readInfoAnyway
[12:24] <zyga> pedronis: which in turn powers CurrentInfo
[12:25] <zyga> pedronis: so this is both good and bad
[12:25] <zyga> pedronis: it's bad for obvious reason, we should validate
[12:25] <zyga> pedronis: it's good that maybe the rollback is "easier" as ... we don't validate
[12:25] <zyga> pedronis: but I'd like to ask you if this is for a reason, the missing validation
[12:26] <Chipaca> zyga— validation is done on ingestion
[12:26] <Chipaca> currently
[12:27] <Chipaca> zyga— which, not as good, we should do it on load, but it's there
[12:28] <zyga> Chipaca: hmmm
[12:28] <zyga> Chipaca: any reason not to always validate?
[12:28] <Chipaca> zyga— validation needs to be versioned?
[12:28] <Chipaca> other than that, no
[12:28] <zyga> Chipaca: I also worry that some "fixups" (see broken.go) are done in other places, it feels like this is responsibility for snap/ (package) to hide and do this internally
[12:28] <Chipaca> zyga— i mean, changing validation means patching
[12:28] <zyga> Chipaca: why?
[12:29] <zyga> Chipaca: patching as in overlord patches?
[12:29] <Chipaca> zyga— because valid state suddenly can become invalid without it
[12:29] <Chipaca> zyga— yes
[12:29] <zyga> aha
[12:29] <jdstrand> morphis: hey
[12:29] <zyga> but we don't store info in state?
[12:29] <morphis> jdstrand: hey!
[12:29] <zyga> Chipaca: so "state" is still valid
[12:30] <zyga> Chipaca: we may just notice disk is (and was) invalid
[12:30] <morphis> jdstrand: I've pushed up an initial version of the Xauthority handling at https://forum.snapcraft.io/t/migrate-x11-authentication-cookies-into-snap-environment/116/10
[12:30] <jdstrand> morphis: I'll add it to my list
[12:30] <morphis> jdstrand: and implemented simple parsing of the Xauthority file, is that ok for you to do validation of that file?
[12:31] <morphis> jdstrand: we don't have the xauth binary everywhere so need another way to handle this
[12:31] <jdstrand> morphis: I think simple parsing is good enough. I mean, X is supposed to handle it itself and we aren't trying to protect the user from herself
[12:31] <morphis> right
[12:32] <morphis> jdstrand: then let me go and prep a PR for this then we can do a proper review
[12:32] <jdstrand> ok
[12:36] <ogra_> niemeyer, your opinion on bug 1674509 (regarding the last four/five comments) would be valuable ...
[12:36] <mup> Bug #1674509: Unable to find bluetooth device on RPi3 running Ubuntu Core 16 <snapd-interface> <Snappy:Confirmed> <linux-raspi2 (Ubuntu):Invalid by p-pisati> <https://launchpad.net/bugs/1674509>
[12:41] <mikeb_> Chipaca: Just a follow up. It looks like surrounding my command arguments with escaped quote does, in fact, work as expected.  Now I have to figure out why my wrapper'daemonization is not
[12:41] <mikeb_> working.
[13:00] <zyga> tvoss: some small reviews on the rsa branch
[13:02] <zyga> pstolowski: standup?
[13:03] <tvoss> zyga: thanks, looking
[13:11] <Son_Goku> zyga: all we need is one more +1 and then snapd rolls out to stable for F25
[13:11] <Son_Goku> https://bodhi.fedoraproject.org/updates/FEDORA-2017-37a7331620
[13:11] <zyga> Son_Goku: just after my standup
[13:12] <zyga> Son_Goku: I'll boot my VMs and try
[13:12] <zyga> Son_Goku: thanks for tracking this!
[13:12] <Son_Goku> excellent
[13:12] <Son_Goku> mhall119: it's happening! :D
[13:13] <Son_Goku> zyga: if you do it quick enough, it might even sync out today!
[13:15] <zyga> Son_Goku: I didn't buy 16GB of ram (it's 250 euro) so I'm still on 4G, with that and firefox and chrome I cannot do it now
[13:16] <Son_Goku> damn
[13:30] <zyga> Son_Goku: testing f25 server now
[13:38]  * zyga hugs "dnf install --enablerepo=updates-testing snapd"
[13:53] <zyga> morphis: F25 server is good to go
[13:54] <morphis> zyga: great!
[13:55] <zyga> morphis: added my +1
[13:55] <zyga> going to try F24 while I wait for 26 alpha to download
[13:56] <morphis> zyga: what a wonderful weekend present
[13:56] <zyga> morphis: indeed
[14:05] <pedronis> niemeyer: it might be easier to do a separate preparatory branch though, because with these decisions AliasesStatus the type goes ways, that's a boring but big diff in itself I think
[14:06] <mup> PR snapcraft#1242 opened: kernel_plugin: use CROSS_COMPILE to override the default toolchain <Created by piso77> <https://github.com/snapcore/snapcraft/pull/1242>
[14:06] <niemeyer> pedronis: Happy to follow your guidance on how to organize the changes in the easiest way
[14:06] <Chipaca> SLIGHTLY_UPSET_COMPILE
[14:06] <pedronis> niemeyer: thanks, I'll try and see just how big that is and go fromt there
[14:11] <zyga> Chipaca: ?
[14:12] <Chipaca> zyga— CROSS_COMPILE?
[14:12] <ogra_> zyga, that was a reaction to the PR line i think :)#
[14:12] <zyga> ah
[14:12] <zyga> I missed that :)
[14:12] <zyga> (got used to ignoring what humble mup says)
[14:14] <zyga> does ext4 do background initialization
[14:14] <zyga> so you can format quickly
[14:14] <zyga> and it will finish it in the background over time?
[14:15] <niemeyer> ogra_: Replied in the bug
[14:24] <morphis> zyga, niemeyer: what kind of ubuntu images are you using on Linode as a base? regular cloud images?
[14:28] <Pharaoh_Atem> zyga: snapd for Fedora 24 needs +1 karma to go stable: https://bodhi.fedoraproject.org/updates/FEDORA-2017-ce0fdd87a4
[14:28] <zyga> morphis: we use ubuntu images that were modified to be like vanilla ubunut, that is booting with grub and with ubuntu kernel
[14:28] <zyga> Pharaoh_Atem: 24 is next on my list
[14:28] <Pharaoh_Atem> F25 and F26 have the karma to go stable
[14:28] <Pharaoh_Atem> so F24 is key now
[14:29] <zyga> Pharaoh_Atem: oh great, I will test 24 and skip 26 then
[14:29] <zyga> I reverted to the initial install snapshot
[14:29] <zyga> so "dnf update" takes a long while
[14:30] <tvoss> pedronis: so I'm looking into the BIO mem_buf stuff, encoding the key to a mem_buf BIO fails (not due to insufficient memory). Investigating
[14:31] <morphis> zyga: ok, wondering if we can just use the official openstack debian images as a base and initialize them once via cloud-init
[14:31] <morphis> Pharaoh_Atem: looks like F25 is close now :-)
[14:32] <morphis> Pharaoh_Atem: who is the third one who gave +1 for F25?
[14:32] <zyga> morphis: seems very sensible
[14:32] <morphis> ok
[14:32] <Pharaoh_Atem> morphis: decathorpe (Fabio Valentini)
[14:33] <Pharaoh_Atem> he's the guy packaging Pantheon Desktop for Fedora
[14:33] <Pharaoh_Atem> I asked him to test it out :)
[14:33] <Pharaoh_Atem> GL is busted with nvidia on Fedora, though
[14:33] <Pharaoh_Atem> it crashed for him when he tried to use ohmygiraffe
[14:33] <pedronis> tvoss: ok, I hope it can be made to work
[14:34] <zyga> Pharaoh_Atem: that's expected :/
[14:34] <zyga> Pharaoh_Atem: we need to redesign that
[14:35]  * zyga wishes he had more ram and maybe dedicated, non-spare-junk HDD for the VMs
[14:36] <morphis> Pharaoh_Atem: nvidia is still broken?
[14:36] <Pharaoh_Atem> Yep
[14:37] <zyga> morphis: yes, there was never support for fedora+nvidia
[14:37] <zyga> Pharaoh_Atem: tell me, is Fabio using drivers from the archive (if so, which package) or from nvidia directly?
[14:37] <Pharaoh_Atem> from the negativo17 repository, I believe
[14:37] <Pharaoh_Atem> or rpmfusion
[14:37] <Pharaoh_Atem> one of the two
[14:37] <zyga> Pharaoh_Atem: ok
[14:37] <zyga> I know how to fix it, just not a high priority (yet)
[14:37] <zyga> and no time (yet)
[14:38] <zyga> first need to get mount world in order
[14:38] <morphis> zyga: feel free to give me pointers for a fix
[14:39] <zyga> morphis: we don't print anything useful on isntall
[14:39] <zyga> morphis: we should say "please log out to get PATH updates"
[14:39] <zyga> or similar useful advice
[14:41] <zyga> morphis, Pharaoh_Atem: there are selinux denials because of loopback mounted snaps
[14:41] <zyga> for the gnome-shell
[14:41] <Pharaoh_Atem> :/
[14:42]  * Pharaoh_Atem makes a note to set up a Fedora Workstation system
[14:42] <zyga> type=AVC msg=audit(1491576072.251:282): avc:  denied  { getattr } for  pid=1044 comm="gnome-shell" path="/dev/loop-control" dev="devtmpfs" ino=16235 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:loop_control_device_t:s0 tclass=chr_file permissive=0
[14:42] <zyga> can we correct that from snapd-selinux
[14:42] <zyga> I suspect it should go to gnome-shell selinux directly too
[14:43] <Pharaoh_Atem> we cannot
[14:43] <Pharaoh_Atem> well, we *could*
[14:43] <Pharaoh_Atem> the gnome guys would kill us, though
[14:43] <morphis> :-D
[14:43] <morphis> I think there is a reason why this is denied for gnome-shell
[14:43] <Pharaoh_Atem> yeah
[14:43] <Pharaoh_Atem> it's out of scope for snapd-selinux anyway
[14:43] <morphis> but why is it trying to do this at all?
[14:44] <Pharaoh_Atem> maybe it's probing disks?
[14:44] <zyga> morphis, Pharaoh_Atem: let's file a bug and correct this in the main policy
[14:44] <zyga> Pharaoh_Atem: yes, I suspect so
[14:45] <zyga> type=AVC msg=audit(1491575811.619:770): avc:  denied  { create } for  pid=39655 comm="systemctl" name="var-lib-snapd-snap-hello\x2dworld-27.mount" scontext=system_u:system_r:snappy_t:s0 tcontext=system_u:object_r:systemd_unit_file_t:s0 tclass=lnk_file permissive=1
[14:45] <zyga> I have 50 selinux denials after installing hello-world and rebooting in workstation
[14:45] <morphis> Pharaoh_Atem, zyga: yeah lets get a bug and lets see why this happens and where we fix the best way
[14:45] <zyga> Pharaoh_Atem: shall I report those on bugzilla now?
[14:45] <Pharaoh_Atem> Yes
[14:45] <zyga> kk
[14:46] <zyga> Pharaoh_Atem: on redhat bugzilla, under fedora?
[14:46] <Pharaoh_Atem> yes
[14:46] <Pharaoh_Atem> component would be the source package name
[14:47] <zyga> ok
[14:47] <Pharaoh_Atem> well, at least the snappy denials are occurring permissively :D
[14:48] <zyga> Pharaoh_Atem: yeah but for gnome-shell it is a real denial
[14:48] <Pharaoh_Atem> yeah
[14:51] <morphis> zyga: yeah something we need to fix
[14:51] <zyga> morphis: I would love to get rid of the myriad of denials too
[14:51] <zyga> morphis: even if they are in complain mode
[14:51] <zyga> morphis: 100% of the users will see that
[14:51] <zyga> and it's just annoying
[14:51] <morphis> yes
[14:52] <morphis> Pharaoh_Atem, zyga: so do we hold the release back until early next week?
[14:52] <zyga> https://bugzilla.redhat.com/show_bug.cgi?id=1440207
[14:53] <zyga> morphis: no, I think we can release
[14:53] <zyga> morphis: release, iterate
[14:54] <morphis> zyga: fine for me
[14:54] <zyga> morphis: can you install f25 workstation
[14:54] <zyga> morphis: snapshot it, install snapd + hello-world
[14:54] <zyga> morphis: and file all the bugs (on snapd in bugzilla) for each unique denial
[14:55] <zyga> morphis: it will be a while but I think that's the way to track them
[14:55] <zyga> morphis: I can help this weekend as I was hoping to see something selinux for a while
[14:55] <zyga> morphis: maybe I can squash one or two
[14:55] <morphis> zyga: can do this on monday, for today I want to finish what I have currently
[14:56] <zyga> morphis: ok
[14:56] <zyga> morphis: let me do one as an example
[14:57] <morphis> ok
[14:59] <zyga> Pharaoh_Atem, morphis: https://bugzilla.redhat.com/show_bug.cgi?id=1440208
[15:00] <zyga> suggestions on how to report those are welcome
[15:01] <zyga> morphis: fixing those might take a while but we should at least fix the majority that may be as easy as a few extra rules in the policy
[15:01] <morphis> yeah
[15:01] <zyga> ok, booting f24 now
[15:01] <morphis> zyga: can you add them to https://trello.com/c/Fvtml6A1/26-fedora-fix-selinux-denials ?
[15:01] <morphis> zyga: the bug links I mean
[15:02] <zyga> morphis: trello
[15:02] <zyga> morphis: no, trello is dead
[15:02] <morphis> zyga: it isn't :-)
[15:02] <morphis> that is for my cross-distro work
[15:02] <morphis> nothing else
[15:02] <zyga> morphis: let's be consistent
[15:02] <zyga> morphis: if anything use the forum
[15:03] <morphis> zyga: lets not discuss this here, this has a different scope but I am fine with a forum post for this too
[15:04] <zyga> morphis: +
[15:04] <zyga> morphis: +1
[15:10] <Pharaoh_Atem> zyga: are you able to give the F24 update a +1 yet?
[15:10] <zyga> Pharaoh_Atem: yes, now mid way dnf update
[15:10] <zyga> Pharaoh_Atem: at 335/763 updates
[15:11]  * Pharaoh_Atem is trying to beat the clock for when bodhi mash starts
[15:11] <zyga> Pharaoh_Atem: when is that?
[15:11] <zyga> Pharaoh_Atem: I will be ready in 10-15 minutes
[15:12] <zyga> (437 now)
[15:12] <Pharaoh_Atem> I don't know
[15:12] <Pharaoh_Atem> it's usually around now
[15:12] <zyga> aha
[15:12] <zyga> well
[15:12] <zyga> if we miss it, when is the next one?
[15:12] <zyga> daily
[15:12] <zyga> ?
[15:12] <Pharaoh_Atem> lemme check
[15:12] <zyga> thank you
[15:13] <tvoss> pedronis: I'll take a quick break
[15:13] <zyga> 500/763 updates
[15:14] <zyga> some updates are bigger than others...
[15:14] <ogra_> thanks for implanting sesame street music in my head now...
[15:15] <Pharaoh_Atem> zyga: it's irregular, but it happens about once a day
[15:15] <zyga> 620 now
[15:15] <zyga> still more than 10 minutes away I suspect, then all the disk IO starts and reboot and more installs
[15:16] <Pharaoh_Atem> you know, you didn't have to do a full update...
[15:16] <zyga> this is f24 vanilla iso install
[15:16] <zyga> I wanted it to be more realistic
[15:16] <Pharaoh_Atem> oh dear
[15:16] <Pharaoh_Atem> wow
[15:16] <Pharaoh_Atem> you reset all the way back to GA?
[15:16] <zyga> (as I said, snapshot :)
[15:16] <zyga> 741 now
[15:18] <zyga> DRPMs now
[15:25] <pedronis> pstolowski: I tried quickly, the issue is simply that json doesn't work with map[interface{}]interface{}
[15:26] <pedronis> (even if the value have correct types)
[15:27] <pstolowski> pedronis, yes, in fact json spec says only strings can be used as keys
[15:28] <jfmcarreira> heyyy guys
[15:28] <jfmcarreira> any help on this error? cannot create user data directory: /nfs/home/jcarreira.it/snap/vlc/x1: Read-only file system
[15:29] <zyga> jfmcarreira: hey
[15:29] <ogra_> jfmcarreira, looks like you are not trying to write to $SNAP_DATA but to $SNAP
[15:29] <zyga> to put your home directory on NFS you need to do some extra things
[15:29] <zyga> jfmcarreira: there's a bug report with details on launchpad
[15:29] <ogra_> (or rather $SNAP_USER_DATA in your case)
[15:29] <ogra_> oh
[15:29] <zyga> jfmcarreira: I cannot find it now (busy)
[15:29] <ogra_> ignore me
[15:30] <zyga> jfmcarreira: but quick suggestion:
[15:30] <ogra_> zyga, is right
[15:30] <zyga> jfmcarreira: for now you will have issues with network denials and this is a kernel/nfs limitation
[15:30] <zyga> jfmcarreira: if you --bind mount your home directory under /home/ you will have a better experience
[15:30] <zyga> jfmcarreira: but it won't work really
[15:30] <pedronis> pstolowski: yes, but this is an implementation detail, it could go over the key and still do the job if they are strings, but it doesn't
[15:30] <pedronis> pstolowski: anyway wrote a bit more in the forum
[15:32] <pstolowski> pedronis, ty
[15:37] <jfmcarreira> zyga: ok thanks for the help.. but i only have ubuntu on a NFS system
[15:39] <zyga> Pharaoh_Atem: finally updated
[15:44] <zyga> hmm, I don't get tab-completion on fc24
[15:45] <zyga> morphis, Pharaoh_Atem: we don't install tab completion files
[15:45] <Pharaoh_Atem> do we have tab completion files to install?
[15:46] <morphis> Pharaoh_Atem: yes
[15:46] <zyga> Pharaoh_Atem: yes
[15:46] <zyga> Pharaoh_Atem: I do that in suse
[15:46] <zyga> Pharaoh_Atem: it's just one file really
[15:46] <Pharaoh_Atem> well gee, I wish I had known :/
[15:46] <morphis> Pharaoh_Atem: no bad, lets do it with the next release :-)
[15:46] <zyga> Pharaoh_Atem: (and thanks to Chipaca's magic) they will now tab complete into snaps with confinement (really nice code to read)
[15:47] <Chipaca> *blush*
[15:47]  * zyga hugs Chipaca 
[15:47] <zyga> really great stuff!
[15:48] <zyga> Pharaoh_Atem: +1 to release
[15:49] <Pharaoh_Atem> doesn't help me here :)
[15:49] <Pharaoh_Atem> https://bodhi.fedoraproject.org/updates/FEDORA-2017-ce0fdd87a4
[15:49] <zyga> Pharaoh_Atem: I was typing it there already :D
[15:50] <zyga> Pharaoh_Atem: saved
[15:50] <zyga> Pharaoh_Atem: after this is out I'll gladly get my feet wet and make a few trivial suggestions
[15:50] <zyga> Pharaoh_Atem: do we need +3 for F24 / F26?
[15:50] <Pharaoh_Atem> nope
[15:51] <Pharaoh_Atem> I lowered the karma req so that they'd all make it
[15:51] <zyga> ok
[15:51] <Pharaoh_Atem> though feel free to add feedback there too :)
[15:51] <zyga> I'll test 26 now
[15:51] <zyga> and EOD
[15:51] <Pharaoh_Atem> okay
[15:51] <zyga> the 2.24 issues are for next week or this evening, I have some ideas but too taxed mentally today
[15:52] <zyga> oh one more thing
[15:52] <zyga> Pharaoh_Atem, morphis: do you have any fedora booted?
[15:52] <zyga> I just shut down to install 26
[15:53] <zyga> what does "snap version" say?
[15:53] <zyga> is it correct?
[16:02] <zyga> Pharaoh_Atem: release release release
[16:07] <Pharaoh_Atem> zyga: looks like it already mashed... https://bodhi.fedoraproject.org/masher/
[16:07] <Pharaoh_Atem> :(
[16:08] <Pharaoh_Atem> zyga: it'll mash again early tomorrow, I think
[16:08] <Pharaoh_Atem> though it may happen earlier, who knows
[16:09] <zyga> Pharaoh_Atem: that's fine
[16:09] <zyga> Pharaoh_Atem: so once this is out can we do the tab completion and some tweaks over weekend?
[16:10] <Pharaoh_Atem> zyga: yeah
[16:10] <zyga> Pharaoh_Atem: great, I'll do that
[16:27] <mup> PR snapcraft#1240 closed: cli: improve push output <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1240>
[16:29] <jdstrand> niemeyer: hi! :) re 'I'd put that ahead of pretty much anything else'> were you talking to me or Sergio?
[16:29] <niemeyer> Oops.. fixing :)
[16:30] <jdstrand> ok. I'll get to that other bit. it is slowly moving up the list
[16:30] <niemeyer> Thanks
[16:36] <mup> PR snapd#3155 opened: snapstate: simplify AliasesStatus down to just an AutoAliasesDisabled bool flag (aliases v2) <Created by pedronis> <https://github.com/snapcore/snapd/pull/3155>
[16:37]  * zyga takes a break now
[16:39] <pedronis> niemeyer: created snapd#3155 and then used it to simplify snapd#3087
[16:39] <mup> PR snapd#3155: snapstate: simplify AliasesStatus down to just an AutoAliasesDisabled bool flag (aliases v2) <Created by pedronis> <https://github.com/snapcore/snapd/pull/3155>
[16:39] <mup> PR snapd#3087: overlord/snapstate: introduce tasks for aliases v2 semantics with temporary names for now (aliases v2) <Critical> <Created by pedronis> <https://github.com/snapcore/snapd/pull/3087>
[17:09] <niemeyer> pedronis: Thanks!
[17:46] <niemeyer> pedronis: Tests filaed on 3155.. the issue mvo reported with checksum problems on partial downloads
[17:46] <niemeyer> Retrying
[17:46] <pedronis> thanks
[17:47] <morphis> zyga: https://paste.ubuntu.com/24335332/ doesn't look bad for the first day working on this :-)
[18:03] <niemeyer> Taking a break
[18:13] <Guest123> Is it possible to install Ubuntu Core without an Ubuntu One account?
[18:18] <kyrofa> Guest123, install, yes. SSH into, no
[18:30] <Guest123> Is it possible to install Ubuntu Core without an Ubuntu One account?
[19:58] <coreycb> sergiusens_, hi, i added some details to bug 1675479. i have a work around but i'm not sure what's different in our environments that you weren't able to reproduce.
[19:58] <mup> Bug #1675479: python plugin doesn't work for namespace packages <openstack> <plugin> <Snapcraft:New> <https://launchpad.net/bugs/1675479>
[19:59] <coreycb> sergiusens_, probably can lower that from high though since i have a workaround
[20:30] <tvoss> okay, when using unsafe.Pointer, is ownership transferred to the go runtime?
[20:30] <tvoss> s/unsafe.Pointer/C.GoBytes/
[20:56] <tvoss> pedronis: done,just updated the PR with changes to avoid file operations
[20:59] <jdstrand> sabdfl: fyi, I already started poking at wayland: https://forum.snapcraft.io/t/wayland-dconf-and-xdg-runtime-dir/186/2
[21:00] <jdstrand> sabdfl: I've got gnome/wayland now running on my laptop and plan to work on the initial interfaces
[21:01] <kyrofa> jdstrand, nice
[21:02] <jdstrand> sabdfl: (fyi based on backscroll from earlier today)
[21:03] <jdstrand> it's kinda interesting cause snaps with gnome/wayland/portals should be a nice desktop security story
[21:09] <mup> PR snapcraft#1243 opened: tests: update the location of the upstream retry autopkgtests script <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1243>
[21:19] <sabdfl> hi jdstrand, thank you
[21:19] <sabdfl> yes i think we can bring those two ideas together very neatly
[21:20] <sabdfl> portals bear a startling resemblance to helpers so all the concepts are in place
[21:20] <sabdfl> and i'll be glad to have snaps be first class across all the major desktops
[21:20] <jdstrand> indeed
[21:21] <jdstrand> and they do bear a startling resemblance to helpers-- they were clearly inspired by our work :)
[21:29] <ahoneybun> sabdfl: are you taking about the flavors?
[21:30] <sabdfl> ahoneybun, and upstream
[21:30] <ahoneybun> right other distros too then
[21:31]  * ahoneybun dreams of a snap that can detect the desktop (gtk, qt) and change the UI to that
[22:15] <mup> PR snapcraft#1243 closed: tests: update the location of the upstream retry autopkgtests script <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1243>
[22:39] <lutostag> anybody know how to set dns servers on core 16?