[02:07] <mup> PR snapcraft#1288 opened: store: collaboration UI for snaps <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1288>
[03:31] <mup> PR snapcraft#1289 opened: beta <Created by snappy-m-o> <https://github.com/snapcore/snapcraft/pull/1289>
[05:43] <mup> PR snapcraft#1289 closed: beta <Created by snappy-m-o> <Closed by elopio> <https://github.com/snapcore/snapcraft/pull/1289>
[05:43] <mup> PR snapcraft#1290 opened: tests: refactor tests with build and stage packages <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1290>
[06:42] <mvo> Pharaoh_Atem: hey, I'm working on a new snapd release currently and you mentioned you wanted some tarballs with vendor removed, do I remember this correctly?
[07:07] <pedronis> mvo: hi, is the release draft missing mentioning release.schedule ?
[07:07] <pedronis> sorry refresh.schedule
[07:17] <mvo> pedronis: yes indeed, I need to add that
[07:23] <zyga> o/
[07:23] <zyga> mvo: hey, how are you feeling
[07:23] <zyga> mvo: ready for the sprint?
[07:24] <mvo> zyga: yes
[07:24] <mvo> fgimenez: new beta snaps available for an early smoke test of 2.25
[07:25] <fgimenez> mvo: great thanks! on it, will let you know how it goes
[07:25] <mvo> fgimenez: and ubuntu-core as well
[07:26] <fgimenez> mvo: ack, we have spread tests for it too, but yet no spread-cron branches up, i'll trigger them manually
[07:30] <mup> PR snapd#3246 closed: cmd/snap-confine: remove obsolete debug message <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3246>
[07:41] <mup> PR snapd#3249 opened: releasing package snapd version 2.25 <Created by mvo5> <https://github.com/snapcore/snapd/pull/3249>
[07:41] <zyga> pstolowski: can you have a 2nd look on https://github.com/snapcore/snapd/pull/3225 - I think I addressed your questions
[07:41] <mup> PR snapd#3225: cmd/snap-update-ns: add actual implementation <Created by zyga> <https://github.com/snapcore/snapd/pull/3225>
[07:42] <zyga> pstolowski: if not just comment and I'll do my best
[07:42] <zyga> I could also use a 2nd review on (trivial) https://github.com/snapcore/snapd/pull/3234
[07:42] <mup> PR snapd#3234: overlord/snapstate/backend,interfaces/mount: move ns management code <Created by zyga> <https://github.com/snapcore/snapd/pull/3234>
[07:42] <pstolowski> zyga, sure, will do in a moment
[07:53]  * zyga -> breakfast
[07:53] <zyga> day of code reviews
[07:58] <mup> PR snapd#3250 opened: store: fix TestDownloadSyncFails for go1.8 <Created by mvo5> <https://github.com/snapcore/snapd/pull/3250>
[08:01] <abeato> ogra_, how is the initrd for a kernel snap built? where does snapcraft pull the sources from?
[08:19] <mup> PR snapd#3251 opened: packaging: cleanup how built-using is generated  <Created by mvo5> <https://github.com/snapcore/snapd/pull/3251>
[08:22] <zyga> re
[08:27] <fgimenez> mvo: i'm getting an error with econnreset on all the platforms http://paste.ubuntu.com/24471739/ the timeout makes the execution stop, i'll retrigger all of them removing this test
[08:30] <mvo> fgimenez: uh, strange
[08:30] <mvo> fgimenez: strange because this was/is working ok in qemu and linode, wonder whats the difference with external
[08:34] <fgimenez> mvo: let me run it isolated with -debug on amd64 to seee what's going on
[08:36] <zyga_> pstolowski: some comments on https://github.com/snapcore/snapd/pull/3217#pullrequestreview-35302363
[08:36] <mup> PR snapd#3217: snap: support for snap tasks --last= <Created by stolowski> <https://github.com/snapcore/snapd/pull/3217>
[08:36] <pstolowski> thanks
[08:39] <zyga_> Chipaca: hey, I see lots of completion failures on Debian: https://github.com/snapcore/snapd/pull/3150
[08:39] <mup> PR snapd#3150: In-snap bash tab completion <Created by chipaca> <https://github.com/snapcore/snapd/pull/3150>
[08:44] <mvo> pedronis: if you could have a look at 3241 that would be great. it misses tests but I would love to get a early sanity check of the idea. we may need it soon to help CE
[08:44] <zyga_> mvo: sorry for my naive question but in https://github.com/snapcore/snapd/pull/3241#discussion_r113743668 does that mean the process could work offline?
[08:44] <mup> PR snapd#3241: snap: make `snap prepare-image` read .assert files for local snaps <Created by mvo5> <https://github.com/snapcore/snapd/pull/3241>
[08:44] <mvo> zyga_: not quite
[08:44] <mvo> zyga_: it could with some more work
[08:45] <zyga_> aha, so this would just prime the rest of the code to do the right thing
[08:45] <zyga_> ?
[08:45] <mvo> zyga_: right now the way it works is that snap prepare-image gets some data from the store and then later fetches the assertions from the store
[08:45] <mvo> zyga_: my branch just makes the code fish out most of the store info from the assertion. however it will still later contact the store
[08:46] <mvo> zyga_: exactly
[08:46] <zyga_> mvo: understood, thanks!
[08:46] <mvo> zyga_: this is a bit of a quick fix for CE, I think we can do it fully offline with a bit more work
[08:46] <zyga_> I just never looked at that code
[08:46] <zyga_> mvo: one thing that I think would be interesting is a way to reproduce an image build given a manifest (with offline snaps and assertions)
[08:47] <zyga_> mvo: but no ad-hoc design on IRC :)
[08:47] <mvo> zyga_: yeah, I think with full offline capability this would be almost there
[08:48] <pedronis> zyga_: we disussed that when discussing improving prepare-image (I have an email thread with Gustavo that I need to port to the forum), he wasn't too keen on having a manifest on top of model assertions
[08:48] <pedronis> though
[08:48] <zyga_> pedronis: manifest could only capture a snapshot of what the model describes
[08:48] <zyga_> pedronis: not as a way to create other things
[08:49] <zyga_> pedronis: I think that it will be a common request from CE, to be able to reproduce image builds exactly, at specific revisions
[08:49] <pedronis> zyga_: well a manifest is not enough (given how the store works atm and rules), you really need to cache what prepare-image used
[08:51] <zyga_> pedronis: yes, I was thinkin about a full cache
[08:51] <zyga_> pedronis: with all the snaps and assertions
[08:51] <pedronis> ok
[08:52] <pedronis> it's all a bit odd because if you don't change anything then it's pointless
[08:52] <pedronis> you get the image you already got once
[09:11] <zyga> Son_Goku: hey, how are you doing
[09:19] <zyga> pstolowski: https://github.com/snapcore/snapd/pull/3119 has two reviews
[09:19] <mup> PR snapd#3119: interfaces: API additions for interface hooks <Created by stolowski> <https://github.com/snapcore/snapd/pull/3119>
[09:19] <zyga> pstolowski: can we merge it?
[09:19] <pstolowski> zyga, no, I'd like niemeyer's +1
[09:19] <mup> PR snapd#3252 opened: tests,cmd/snap-confine: port older snapd-discard-ns tests <Created by zyga> <https://github.com/snapcore/snapd/pull/3252>
[09:19] <zyga> pstolowski: ok
[09:20] <Chipaca> ooh, el reg article mentioning snaps
[09:20] <zyga> Chipaca: can you share the URL please
[09:20]  * Chipaca clutches it close to his chest
[09:20] <Chipaca> NO
[09:20] <zyga> aww :-(
[09:20] <Chipaca> zyga— http://www.theregister.co.uk/2017/04/28/snap_flatpacks_the_future_of_desktop_linux/
[09:22] <Chipaca> shame it sounds like they've only actually tried flatpaks
[09:22] <Chipaca> ¯\_(ツ)_/¯
[09:26] <zyga> "the kernel is not going to be a flatpak any time soon"
[09:26] <zyga> yeah, because it's a snap already
[09:26] <ogra_> abeato, during the core snap build ....
[09:26] <fgimenez> mvo: about the error on the boards using the external backend it turns out that now the files under /home/gopath/src/github.com/snapcore/snapd belong to the user created with console-conf and not to the "test" user, not sure why, a week ago this wasn't happen, i'll continue digging
[09:28] <ogra_> abeato, https://github.com/snapcore/core/blob/master/live-build/hooks/25-create-generic-initrd.chroot
[09:29] <abeato> ogra_, are not initramfs images built with the kernel?
[09:29] <abeato> I mean, when building the kernel snaps
[09:29] <ogra_> abeato, nope, it is generic ...
[09:30] <ogra_> abeato, long term we want two initrds, a generic one with all scripts shipped in core and a specific one with only /lib/modules|firmware that the kernel ships
[09:30] <mvo> fgimenez: thank you
[09:31] <ogra_> abeato, currently the snapcraft kernel plugin still adds the modules to the generic one at build time though, downloading the core snap and pulling it from there
[09:31] <abeato> ogra_, so how does it work to add those kernel specific files in the initrd? I see there is a "kernel-initrd-modules" list in kernel snapcraftyaml files
[09:32] <ogra_> abeato, depends, do you need something specific  the official kernels work slightly different (not using the kernel plugin actually)
[09:33] <Son_Goku> zyga, the kernel as a snap is pretty useless from a multi-distro point of view
[09:33] <ogra_> if it is for your build, the kernel plugin simply re-packs it ... for official kernels we include whats needed in the /etc/initramfs-tools/modules file at build time
[09:33] <zyga> Son_Goku: I didn't mean the corss distro POV, snapd itself is cross distro as it aims to liberalize what a distribution is
[09:33] <ogra_> abeato, all managed via the initramfs-tools-ubuntu-core package from the PPA
[09:34] <zyga> Son_Goku: and who knows, maybe we can teach snapd to install kernels on classic :)
[09:34] <abeato> ogra_, no, just wondering how things are built, thanks for the info
[09:34] <zyga> Son_Goku: it's just software
[09:34]  * Son_Goku wonders what problem is being solved at that point
[09:34] <abeato> ogra_, ok so we can add things for android-boot in that package as you suggested
[09:35] <ogra_> abeato, the official kernels actually use the linux debs from the archive, install them in a chroot and copy the deb contents into the snap ...
[09:35] <zyga> Son_Goku: common packaging environment, I could boot fedora kernels and you could boot ubuntu kernels without any repackaging :)
[09:35] <ogra_> abeato, right, just another script
[09:35] <Son_Goku> zyga: if the Linux world wanted that, we would have had a common packaging environment already
[09:35] <ogra_> abeato, and a simple switch on the kernel cmdline to pick that instead of the default for booting recovery
[09:35] <Son_Goku> God knows people tried
[09:35] <zyga> Son_Goku: that's totally untrue ;)
[09:36] <abeato> ogra_, why this difference between official kernels and what the kernel pluin does? Which approach should I take to build for a new board?
[09:36] <zyga> Son_Goku: the linux world cannot want anything as there are always polarized opinions
[09:36] <Son_Goku> at least we're down to ~4 systems instead of ~20
[09:36] <zyga> Son_Goku: I'd say that technically it wasn't done correctly before
[09:36] <zyga> Son_Goku: but it's not about desire at all
[09:36] <ogra_> abeato, for secureboot we need the kernel binary signed by the archive key, using the existing deb is the easiest way for that
[09:36] <pstolowski> zyga, addressed your comments to #3217
[09:37] <zyga> Son_Goku: just add hrw and any other person into the "linux world" and they will disagree ;)
[09:37] <zyga> pstolowski: thanks! looking
[09:37] <Son_Goku> zyga: that's unfair
[09:37] <Son_Goku> hrw complains about everything :)
[09:37] <zyga> Son_Goku: see
[09:37] <abeato> ogra_, got it, so if secureboot is not involved, it would be better to use kernel plugin, right?
[09:37] <zyga> Son_Goku: "linux world" is not a measure of anything
[09:38] <Son_Goku> zyga: If I *really* wanted to, i could boot Ubuntu kernels on Fedora
[09:38] <zyga> Son_Goku: but the effort is non-trivial
[09:38] <Son_Goku> yes
[09:38] <Son_Goku> but snaps don't make that better
[09:38] <zyga> Son_Goku: if you had any kenrel in a snap you could just do it casually
[09:38] <Son_Goku> they make the process more opaque
[09:38] <pstolowski> zyga, looking at your 3225, sorry it took so long
[09:38]  * Chipaca sharpens his Stick of Poking and pokes at spread
[09:38] <zyga> Son_Goku: I don't understand how
[09:38] <Son_Goku> fundamentally, the kernel has to know a lot about what it's being built for
[09:38] <ogra_> abeato, for everything but our default set of boards (for which we theoretically also have classic images and want to use the same kernel in both)... i.e. amd64, i386, rpi2/3 and dragonboard, you should use the kernel plugin
[09:39] <Son_Goku> and things like rewriting how the version is constructed, what subsystems are enabled, what monkeypatching was done, etc. affect how it will work on a given userland
[09:39] <abeato> ogra_, I see, thanks!
[09:39] <ogra_> abeato, really depends if you want/need to build from source or can actually use an existing deb based kernel
[09:39] <zyga> Son_Goku: I'm not sure I agree
[09:39] <Son_Goku> the kernel influences the userland and vice versa, so changing expectations can have odd effects
[09:39] <zyga> Son_Goku: if that were the case we didn't have generic x86 kernels
[09:40] <Son_Goku> I'm not talking about at the hardware level
[09:40] <ogra_> abeato, i.e. for the beaglebone community image i also use the linux-generic kernel simply because it fully supports the borad
[09:40] <Son_Goku> I'm talking purely software interfaces
[09:40] <abeato> ogra_, source-based in this case
[09:40] <Son_Goku> and some of them are non-obvious ones
[09:40] <ogra_> right, there you want the kernel plugin
[09:40] <Son_Goku> for example, Ubuntu rewrites the version and bludgeons the upstream kernel version out of the kernel version
[09:40] <Son_Goku> Fedora doesn't
[09:40] <abeato> great
[09:41] <zyga> Son_Goku: so what/
[09:41] <Son_Goku> if tooling in a Fedora userland expects to check based on the upstream kernel version, that might have unexpected side effects with an Ubuntu kernel
[09:41] <zyga> Son_Goku: sure but that's very unlikely
[09:41] <Son_Goku> is it?
[09:42] <zyga> Son_Goku: and totally irrelevant, every distributor did something similar for whatever reasons
[09:42] <zyga> Son_Goku: yes, it's a nitpick, totally
[09:42] <Son_Goku> but the point is that expectations are set based on a distribution convention
[09:42] <zyga> what expectations?
[09:42] <zyga> the version string, please!
[09:42] <Son_Goku> hey, I know of plenty of scripts and things that check it
[09:43] <Son_Goku> I personally had to write one for blacklisting bad kernel versions
[09:43] <zyga> will a system stop booting because of those scripts?
[09:43] <zyga> amyway
[09:43] <Son_Goku> no, but maybe something will fire that shouldn't or something
[09:43] <zyga> that was not the point
[09:43] <zyga> (that's always possible anyway because FOSS has terrible QA)
[09:43] <zyga> the point is that snaps have this already
[09:43] <Son_Goku> but another thing is that Ubuntu kernels are unsigned and Fedora ones are
[09:44] <Son_Goku> so a Fedora boot system wouldn't boot an Ubuntu kernel anyway
[09:44] <Son_Goku> on UEFI
[09:44] <zyga> you are looking for problems, not solutions IMO
[09:44] <zyga> and ubuntu kernels are signed too AFAIK
[09:44] <zyga> there are two sets
[09:44] <Son_Goku> as far as I knew, on Ubuntu, only shim and grub are signed
[09:44] <Son_Goku> maybe even only shim
[09:45] <Son_Goku> I know in Fedora, we sign everything up to the kernel
[09:45] <zyga> Son_Goku: no, the kernel is signed too
[09:45] <Son_Goku> hm, then does Ubuntu's kernel just not do signature checking for kernel modules?
[09:46] <zyga> Son_Goku: it does
[09:46] <zyga> Son_Goku: you remember 14.04 stuff
[09:46] <Son_Goku> ah
[09:46] <Son_Goku> so this changed after then
[09:46] <zyga> Son_Goku: FYI I had to sign vmware modules to load them on my machine
[09:46] <Son_Goku> ah, so that's good
[09:46] <zyga> Son_Goku: then enroll the key in UEFI
[09:46] <Son_Goku> yeah, I know that process well :P
[09:47] <zyga> mvo: artful-amd64?
[09:48] <Son_Goku> zyga: anyway, I need to take a nap, and then I'll come back and start rolling 2.25
[09:48] <Son_Goku> I've been up for too long
[09:49] <zyga> Son_Goku: rest well :-)
[09:49] <mvo> zyga: oh yes!
[09:49] <zyga> Son_Goku: I'm cleaning up stuff in anticipation for 2.25
[09:49] <zyga> mvo: what is artful? :D
[09:49] <mvo> Son_Goku: rest well indeed
[09:49] <zyga> mvo: what is that test about?
[09:49] <mvo> zyga: its for 17.10
[09:49] <Son_Goku> mvo: I hate live-build, so much
[09:49] <zyga> aaah
[09:49] <Son_Goku> debugging that makes me want to murder things
[09:49] <mvo> zyga: its failing left and right
[09:49] <zyga> 17.10 is artful something
[09:49] <zyga> I forgot
[09:49] <mvo> Son_Goku: everybody hates it
[09:50] <mvo> Son_Goku: I would really like to kill it with fire
[09:50] <Son_Goku> mvo: we were trying to use it for a project but it's horrible
[09:50] <Son_Goku> so now I've moved onto fixing the Ubuntu support in KIWI and build things that way
[09:50] <mvo> Son_Goku: :/ maybe we can chat after your nap, there must be better ways
[09:51] <Son_Goku> it's not brain-dead and doesn't make me feel murderous
[09:51] <Son_Goku> mvo: sure
[09:51] <mvo> zyga: snapd tests are broken in 17.10, i.e. with go1.8 this is why I added the test machinery for it
[09:51] <Son_Goku> zyga: Artful Aardvark
[09:51] <zyga> Son_Goku: aaaaaaaaaaa-distribution
[09:52] <mvo> zyga: to avoid getting a gazillion FTBFS mails when we try to build there
[09:52] <mvo> plus I'm sure somewhere is a distro that already moved to go1.8 too
[09:52] <zyga> mvo: are you on artful already?
[09:52] <pedronis> mvo: well to be honest I would like us to use 1.8 everywhere ;)
[09:53]  * zyga spends all of today in github.com/notifications and pull requests
[09:53] <zyga> pedronis: yes, +100 on 1.8
[09:53] <zyga> goodies all around
[09:53] <pedronis> (because go doesn't care at mantaining old releases)
[09:53] <zyga> Son_Goku: would fedora accept 1.8 toolchain for fc25?
[09:54] <mvo> pedronis: look at it this way - adding artful tests is the first step towards this goal
[09:54] <zyga> Son_Goku: e.g. if we wanted to build snapd with a more recent version
[09:54] <mvo> also the go snap \o/
[09:55] <zyga> mvo: go snap is an interesting concept but for building classic packages we need to do some heavy lifting to allow building a package with snap as a dependency
[09:55] <pedronis> mvo: did you autopkgtests or something else?  (me is not paying attention, also I have started to have strong mixed feelings about ever slower tests yesterday)
[09:55] <pedronis> s/did you/did you add/
[09:55] <mvo> mwhudson: I love your go snap (I think its yours, right?)
[09:55] <mvo> pedronis: autopkgtest
[09:55] <mvo> pedronis: so things will run in parallel at least
[09:56] <mvo> pedronis: but we should definitely brainstorm during the sprint
[09:56] <pedronis> ok
[09:56] <mvo> pedronis: about the tests
[09:56] <pedronis> yes, they get pretty terrible, especially around release
[09:56] <pedronis> making your life not so fun I think
[09:56] <mvo> pedronis: did you see my earlier question about 3241?
[09:56] <mvo> pedronis: absolutely, plus travis seems to take a nap in between sometimes too
[09:57] <mvo> pedronis: i.e. we hit some limits there too it seems
[09:57] <pedronis> yes
[09:57] <pedronis> a mixture of things
[09:57] <pedronis> but we need to do something, I think I was starting to have stockholm syndrom but the pain is real
[09:58] <mvo> lol
[09:58]  * mvo hugs pedronis
[09:58] <pedronis> mvo: what's the question 3241, I think I missed it?
[09:58] <pedronis> *about
[09:58] <zyga> pedronis: if something hurts we should do it more so it stops and we fix and warts, I agree that tests are pretty unreliable now but the only answer is to fix them and get better infra if needed
[09:59] <pedronis> well, I don't think the issue is just unreliable
[09:59] <mvo> pedronis: I was wondering if you could have a quick look at #3241 as a sanity check. if the approach looks ok-ish, I will write more tests etc. mostly asking because this allows us to move forward with CE
[09:59] <pedronis> they are also too slow for something we run for each commit in the universe
[09:59] <pedronis> I think
[09:59] <zyga> morphis_: I'll re-review /usr/lib/linux/vmlinuz-4.8.0-46-generic.efi.signature
[09:59] <zyga> er
[09:59] <pedronis> slow+unreliable = the worst
[09:59] <zyga> copy-paste fail
[09:59] <mvo> yeah, its tricky to find the right balance
[09:59] <zyga> https://github.com/snapcore/snapd/pull/3222
[09:59] <mup> PR snapd#3222: many: fix test cases to work with different DistroLibExecDir <Created by morphis> <https://github.com/snapcore/snapd/pull/3222>
[10:00] <zyga> morphis_: just let me know when you are don with it
[10:00] <pedronis> mvo: I'll try to look after lunch, I also need to do some sprint prep (both travel but also writing some gdoc)
[10:00] <zyga> pedronis: I wonder if it would make sense for spread to retry individual failing tests (say up to 5 times)
[10:00] <zyga> but we'd have to fix travis time limit
[10:00] <mvo> pedronis: thank you
[10:00] <zyga> and really work on making tests better for a cycle
[10:01] <morphis_> zyga: I just fixed the failing unit test
[10:01] <zyga> morphis_: thanks
[10:02] <zyga> ENOSERVERS
[10:02] <zyga> throw more $$$ at linode
[10:02] <zyga> in samsung we had a very nice system
[10:02] <zyga> since any avereage office had easily about a thousand laptops/desktops for devlopers
[10:03] <zyga> and they were mostly idle all day (editing = low cpu)
[10:03] <zyga> they were all wired to gigantic distributed task system for compiling software
[10:03] <zyga> so when you hit build, it'd really use 100s of machines around you for fantastic speedups
[10:03] <zyga> I wonder if we could tap into our machines at home, to send tasks and distribute them among ephemeral test VMs
[10:03] <zyga> so travis and linode are not that critical
[10:07] <zyga> mvo: question about go 1.8, why did you have to switch to DeepContains?
[10:07] <zyga> because of the pointer?
[10:08] <mvo> zyga: I don't know
[10:08] <zyga> mvo: aha, ok
[10:09] <mvo> zyga: looking at this rightnow, but wanted to see if that is the only remaining failure
[10:09] <zyga> mvo: yeah, testing on 1.8 is important, I wonder what else awaits us
[10:11] <mup> PR snapd#3253 opened: cmd/snap-confine/spread-tests: discard useless --version test <Created by zyga> <https://github.com/snapcore/snapd/pull/3253>
[10:13] <zyga> why is econnreset failing all the time?
[10:17] <abeato> ogra_, did you remember to update core-build repo? it looks like some files are still missing
[10:18] <ogra_> abeato, i am waiting for a second review for the tests PR, i wanted to use your change as an exercise for it once that landed
[10:18] <abeato> ogra_, ok, please let me know when I can  propose the MP
[10:19] <ogra_> oh, i have it locally already no need for yopu to do anything
[10:19] <abeato> great :)
[10:20] <ogra_> is there anything urgent ?
[10:20] <abeato> no no
[10:20] <ogra_> k
[10:20] <abeato> just wanted to make sure this is not lost
[10:20] <ogra_> nah
[10:20]  * ogra_ loses keys and lighters, but rarely code ;)
[10:21] <abeato> lol
[11:17] <mup> PR core#36 opened: drop remaining dpkg binary (LP: #1686106) <Created by ogra1> <https://github.com/snapcore/core/pull/36>
[11:20] <mup> PR snapd#3254 opened: tests: re-enable and moderninze /media sharing test <Created by zyga> <https://github.com/snapcore/snapd/pull/3254>
[11:30] <robje> how to fix "cannot create user data directory: $path : Permission denied"
[11:30] <Chipaca> robje— hey. Where are you getting this?
[11:30] <zyga> robje: ls -ld ~/snap/
[11:30] <zyga> robje: is that owned by root?
[11:31] <zyga> robje: or is the home directory somewhere unusual?
[11:31] <Chipaca> zyga— ooh, maybe you should ask these same questions on #1686852
[11:31] <mup> Bug #1686852: Can only run hello snap as root <Snappy:New> <https://launchpad.net/bugs/1686852>
[11:31] <Chipaca> :-)
[11:31] <ogra_> heh, i was about to paste the same :P
[11:31] <robje> all files and dirs owned by my user and group.
[11:31] <zyga> thanks, asking!
[11:31] <robje> home is on NFS
[11:32] <ogra_> aha
[11:32] <zyga> robje: ok, can you please pastebin `dmesg | grep DENIED`
[11:32] <zyga> robje: and `snap version`
[11:32] <ogra_> "somewhere unusual" :)
[11:32] <robje> and snap is a symlink to local storage
[11:32] <Chipaca> people still use NFS <3
[11:32] <robje> [ 1250.129323] audit: type=1400 audit(1493378981.364:156): apparmor="DENIED" operation="sendmsg" profile="/usr/lib/snapd/snap-confine" pid=24796 comm="snap-confine" laddr=172.28.4.67 lport=1003 faddr=172.28.4.7 fport=2049 family="inet" sock_type="stream" protocol=6 requested_mask="send" denied_mask="send"
[11:32] <robje> [ 1250.129473] audit: type=1400 audit(1493378981.364:157): apparmor="DENIED" operation="mkdir" profile="/usr/lib/snapd/snap-confine" name="/home/r.epping/" pid=24796 comm="snap-confine" requested_mask="c" denied_mask="c" fsuid=2124 ouid=2124
[11:33] <zyga> robje: are you using NFS?
[11:33] <zyga> oh
[11:33] <zyga> you have a dot in your username?
[11:33] <ogra_> zyga, he said so above :)
[11:33] <zyga> robje: aha
[11:33] <zyga> robje: that's unsupported, let me find you a bug report with a lot of details
[11:33] <robje> yes I have a dot in my username
[11:33] <zyga> robje: unfortunately there's a kernel limitation here
[11:33] <zyga> robje: you can kind of work around this but I'm not sure if that's even possible now
[11:34] <zyga> https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1662552
[11:34] <mup> Bug #1662552: snaps don't work with NFS home <snapd (Ubuntu):Triaged> <https://launchpad.net/bugs/1662552>
[11:35] <ogra_> Chipaca, a second checkmark on https://github.com/snapcore/core/pull/36 would be appreciated (one line change)
[11:35] <mup> PR core#36: drop remaining dpkg binary (LP: #1686106) <Created by ogra1> <https://github.com/snapcore/core/pull/36>
[11:35] <zyga> robje: have a look at that report, let me know if you think I can help you somehow
[11:35] <Chipaca> ogra_— what was it that had made us leave the binary last time?
[11:35] <zyga> robje: the root issue is nfs leaks to various parts of LSM so confinement cannot be the same
[11:35] <zyga> robje: the differences in where user directories are are easier to work around
[11:35] <Chipaca> but
[11:36] <Chipaca> zyga— he doesn't have /snap in nfs
[11:36] <Chipaca> his home is
[11:36] <Chipaca> but /snap is a symlink
[11:36] <Chipaca> now I know _that_ won't work :-) but
[11:36] <zyga> Chipaca: NFS leaks everyhwere
[11:36] <Chipaca> would it work to change it to be a bind mount?
[11:36] <zyga> Chipaca: if you have something on NFS your process will be blocked by seccomp on sendmsg
[11:36] <ogra_> Chipaca, no idea ... i think it was for some code in 15.04
[11:36] <zyga> Chipaca: apart from that apparmor doesn't look at symlinks but at actual files
[11:37] <zyga> Chipaca: so some things may need tuning
[11:37] <robje> Chipaca $home/snap is a symlink to /local/snap
[11:37] <zyga> Chipaca: and lastly snap-confine's appramor profile is special
[11:37] <robje> i.e. on local hdd
[11:37] <Chipaca> zyga— 💩
[11:37] <zyga> Chipaca: all in all it's not trivial to fix everything
[11:37] <ogra_> Chipaca, iirc some snap code used to call dpkg --compare-versions
[11:37] <zyga> Chipaca: I wish someone had fixed the kernel side
[11:37] <zyga> Chipaca: before that I can really do little :/
[11:38] <zyga> Chipaca: (or allow all network traffic to everything by default, but even then snapd doesn't control the apparmor profile of snap-confine)
[11:38] <Chipaca> robje— right, but as zyga says as soon as there's a nfs element in the path that needs to be traversed to get to wherever, you sendmsg, and that's blocked
[11:40] <ogra_> yay, time travellers!
[11:40] <mup> PR core#36 closed: drop remaining dpkg binary (LP: #1686106) <Created by ogra1> <Merged by ogra1> <https://github.com/snapcore/core/pull/36>
[11:41] <zyga> ogra_: ?
[11:41] <ogra_> zyga, i was commenting on Chipaca's PR comment :)
[11:41] <jdstrand> the only somewhat approaching reasonable thing we could do is detect if /home is on nfs, if so, add snippets to default policy (with logging) allowing snap-confine to work
[11:42] <robje> applied workaround in #1662552. now get "Too many levels of symbolic links"
[11:42] <mup> Bug #1662552: snaps don't work with NFS home <snapd (Ubuntu):Triaged> <https://launchpad.net/bugs/1662552>
[11:42] <jdstrand> that's still not great cause if an admin wants a cli command from a snap and doesn't actually need the nfs /home, they still get it
[11:42] <zyga> robje: that's a symlink loop then
[11:42] <zyga> jdstrand: hey!
[11:42] <jdstrand> it would perhaps be possible to have that opt-outtable
[11:42] <jdstrand> zyga: hey :)
[11:43] <zyga> jdstrand: are you going to the sprint next week?
[11:43] <jdstrand> no
[11:43] <zyga> jdstrand: aha, me neither, I plan to do some cleanups this cycle
[11:43] <zyga> jdstrand: tests and cleanups
[11:43] <zyga> jdstrand: all the interface PRs
[11:43] <jdstrand> cool :)
[11:43] <zyga> jdstrand: and more interface tests :)
[11:43] <zyga> mvo: quick question about 17.10
[11:43] <zyga> + /tmp/go/bin/spread -v autopkgtest:ubuntu-17.10-amd64
[11:43] <zyga> 2017-04-28 11:09:50 Found /tmp/autopkgtest.vpoFef/build.lb0/snapd/spread.yaml.
[11:43] <zyga> error: nothing matches provider filter
[11:44] <zyga> mvo: does this make any sense to you?
[11:44] <robje> moved $home/snap back to nfs home. now works, THNX
[11:44] <zyga> it seems ubuntu-17.10-amd64 is not a spread target
[11:44] <Chipaca> zyga— tyler and emily are
[11:44] <jdstrand> zyga: I still have a few sizeable reviews/investigations. hopefully no new ones will come in and I can get back to wayland
[11:44] <zyga> jdstrand: can you summarize what we need to suppor wayland?
[11:44] <Chipaca> zyga— 1. eat humble pie
[11:45] <zyga> jdstrand: can we "just open it" using unprivileged iface?
[11:45] <Chipaca> zyga— 2. more pie?
[11:45] <zyga> Chipaca: as long as it has strawberries
[11:45] <zyga> oh, btw, I have plenty of strawberries, home grown, on the terrace :)
[11:45] <zyga> I need to ask the kids to eat them
[11:45] <Chipaca> zyga— are they tart?
[11:45] <zyga> Chipaca: tart?
[11:45] <Chipaca> if they're tart, make brexit
[11:45] <jdstrand> zyga: well, some of this stuff is sprinkled in the forum, is this an official summary or just otoh between you and me?
[11:45] <Chipaca> zyga— acidic?
[11:45] <zyga> Chipaca: no, sweet like crazy :)
[11:46] <Chipaca> aw, boo
[11:46] <Chipaca> :-)
[11:46] <jdstrand> (eg, cause you're curious)
[11:46] <zyga> Chipaca: if brexit strikes, move here :)
[11:46] <zyga> jdstrand: beween us
[11:46] <zyga> jdstrand: I can read the forum too
[11:46] <zyga> I didn't know there was a thread
[11:46] <zyga> jdstrand: I'm curious and I'm considering switching to 17.10
[11:46] <Chipaca> zyga— http://www.bbc.co.uk/food/recipes/etonmess_81082
[11:47] <jdstrand> zyga: ok, so so far I've only looked at wayland and gnome-shell. there is one application, ghex that I've been focusing on as the start. the plan is to look at 'calculator-like' things (in terms of application simplicity) for gnome-shell, plasma and sway (all wayland DEs)
[11:47] <zyga> Chipaca: strawberries :-)~~~
[11:47]  * zyga nods
[11:48] <Chipaca> works best when they are tart, to my tastebuds, but then i remembered some of the sweets my polish neighbour gave me and reckoned maybe sweet with extra sugar is more to your taste anyway
[11:48] <jdstrand> zyga: gnome-shell uses this thing called mutter, which is gnome's compositor (ie, gnome-shell doesn't use weston, it uses mutter)
[11:49] <zyga> Chipaca: I cannot imagine eating tart strawberries, are they like that because they are grown in cloudy places?
[11:49] <jdstrand> mutter is not complete yet
[11:49] <Chipaca> zyga— different varieties
[11:49] <zyga> jdstrand: aha, I didn't know mutter is still a thing, I thought all the magic moved to gnome-shell
[11:49] <jdstrand> for example, mutter requires launching an XWayland for things such as input
[11:49] <jdstrand> zyga: gnome-shell talks to mutter
[11:49] <zyga> jdstrand: aha, interesting, so each app has its own xwayland wrapper?
[11:49] <zyga> jdstrand: or is there one that just runs for whole shell?
[11:50] <jdstrand> zyga: no. there is one shared Xwayland for all applications
[11:50] <jdstrand> so, security wise there are a few things
[11:50] <zyga> jdstrand: and do actual apps see X11 and DISPLAY or is that gone now and xwayland is hidden somehow?
[11:51] <jdstrand> in terms of input, gnome-shell/mutter/wayland is ok about separating wayland client from each other and from fallback X clients
[11:51] <jdstrand> because mutter requires X for somethings, all native wayland clients in gnome require X
[11:51] <jdstrand> this means that native wayland cannot snoop each other, but they can snoop all fallback X clients
[11:52] <jdstrand> and fallback X clients can all snoop each other
[11:52] <zyga> jdstrand: but native wayland clients talk to any X parts or is that transparently done using wayland protocols now and X is just in the back as an indirect dep?
[11:52] <zyga> jdstrand: aha
[11:52] <jdstrand> native clients don't do anything with X directly
[11:52] <zyga> jdstrand: well, I guess that depends on how many things are in the latter pool
[11:52] <jdstrand> this is a mutter thing
[11:52] <zyga> jdstrand: is a gnome-calculator-like app native now?
[11:53] <jdstrand> so like ghex won't have the code to snoop on Xwayland clients, but a malicious ghex could and because Xwayland is required, we can't stop that
[11:53] <zyga> jdstrand: I think that's fine, it's a progression of the concept
[11:53] <jdstrand> zyga: ghex is the calculator-app I am targeting cause it is in the store
[11:54] <zyga> jdstrand: over time there will be less of X around
[11:54] <jdstrand> zyga: for some definition of 'fine'. it is better, but things get worse
[11:54] <zyga> jdstrand: and if needed, we might think about that X proxy that
[11:54] <ogra_> heh, high hopes
[11:54] <zyga> worse?
[11:54] <jdstrand> (eg, currently the browsers all need Xwayland. the browser is the single most important piece of desktop software, so wayland can sniff browsers)
[11:55] <jdstrand> I guess epiphany...
[11:55] <jdstrand> anyhoo
[11:55] <jdstrand> not worse
[11:55] <jdstrand> the other thing is the clipboard
[11:55] <jdstrand> unfortunately, mutter is not handling the clipboard well at all
[11:55]  * zyga nods
[11:55] <zyga> heh
[11:55] <zyga> all the modern software :)
[11:55]  * zyga hugs all mutter devs
[11:56] <jdstrand> there is a wayland clipboard, but mutter keeps things in sync (mostly) and it doesn't regulate who can grab the clipboard by focus, like unity8/mir did
[11:56] <jdstrand> s/did/do/
[11:56] <ogra_> just make the snapd conflict with all browsers ... problem solved ;)
[11:56] <ogra_> *the snapd deb
[11:57] <jdstrand> so, an x client can grab stuff from the clipboard in the background from a native wayland client
[11:57] <jdstrand> so password managers are safe atm
[11:57] <jdstrand> mutter could be changed to enforce focus, which is something I am going to be knocking on the desktop team's door about
[11:58] <jdstrand> but atm, because all native wayland clients on gnome need X cause of mutter, it is basically a shared clipboard
[11:58] <jdstrand> no worse than X, but that literally is saying nothing :)
[11:59] <zyga> jdstrand: hehe, I see
[11:59] <zyga> jdstrand: well
[11:59] <zyga> jdstrand: little by little
[11:59] <jdstrand> so, as a whole, it is a step in the right direction, but security-wise, mutter/wayland is not as far along as unity8/mirr
[11:59] <jdstrand> mir*
[11:59] <zyga> well
[12:00] <zyga> maybe mir community will actually make more progress now
[12:00] <zyga> I wound't be surprised
[12:00] <ogra_> zyga, you mean with the attempt to port everything to wayland ? :P
[12:00] <jdstrand> mir could go farther, sure. I don't see gnome porting mutter to mir
[12:01] <jdstrand> and kde was pretty clear on that point too
[12:01] <ogra_> (all unity8 community projects work towards having mir on top of wayland now)
[12:01] <mup> PR snapd#3217 closed: snap: support for snap tasks --last= <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/3217>
[12:01] <zyga> ogra_: no, I mean by having a nice technology stack that has a nice desktop shell on top
[12:01] <zyga> ogra_: real mir+unity8 (maybe sans the name)
[12:01] <jdstrand> I'll also note that mutter is not bug free (what is!), but it can be challenging to use
[12:01] <ogra_> zyga, i know what you mean ... i meant to point out that everyone moves in exactly the other direction
[12:02] <zyga> ogra_: aha, I didn't know that
[12:02] <ogra_> making mir a wayland client
[12:02]  * zyga looks up magic fs 6e736673
[12:02] <zyga> aha
[12:02] <zyga> nsfs
[12:02] <jdstrand> sometimes it gets confused by input events and you'll see stuff splatted out to different ttys on shutdown, and even worse, things like 'alt' and 'ctrl-c' end up going to the wrong place. I think they may have some invisible surface issues
[12:03] <jdstrand> mutter/wayland has an interesting characteristic of not being able to be restarted (unlike mutter/X)
[12:03] <jdstrand> so if mutter under wayland dies, your whole session goes *poof* and you login to a fresh new sesson
[12:04] <jdstrand> ok, so, you are using gnome-terminal and all of a sudden ctrl-c isn't going to it, but somewhere else and your session goes *poof*
[12:04] <jdstrand> let me tell you. *that* is very annoying
[12:05] <mvo> zyga: it does, I will add this too
[12:05] <zyga> mvo: thanks!
[12:05]  * zyga breaks for quick lunch
[12:05] <jdstrand> this doesn't happen all the time. I've not been able to reproduce reliably
[12:06] <jdstrand> I've been running gnome-shell/wayland since before 17.04 release and yes, I'm reporting bugs upstream
[12:06] <jdstrand> and lastly, I've not looked at plasma or sway yet
[12:07] <jdstrand> and and lastly lastly, XDG_RUNTIME_DIR is all wrong for wayland and we have to rethink that (there is a forum topic)
[12:08] <jdstrand> oh, and lastly lastly lastly, when I set everything up correctly to work around XDG_RUNTIME_DIR, gnome apps (ie, ghex) crash as snaps when run under wayland. guessing there is some desktop part stuff that needs to be added
[12:08] <jdstrand> zyga: so, you asked a question and then left. don't think I didn't notice :P
[12:09] <jdstrand> but that is my unofficial report as of today
[12:13] <ogra_> zyga, or mvo, a second checkmark on https://github.com/snapcore/core-build/pull/8 would really be nice
[12:13] <mup> PR core-build#8: add shellcheck test, fix code for shellcheck <Created by ogra1> <https://github.com/snapcore/core-build/pull/8>
[12:14] <jdstrand> mvo: hi! btw, you mentioned talking about wayland at the sprint in the forum. did you see my reply in the forum? if you want a more complete (if informal) status, read backscroll here (also ratliff and tyhicks)
[12:19] <jdstrand> mvo: though, what I said in the forum I think is sufficient for any discussions surrounding discussing wayland at the sprint (ie, backscroll is only if you are interested in excrutiating context, but it is unfiltered and unformatted :)
[12:24] <mup> PR snapd#3255 opened: tests: set ownership of $PROJECT_PATH for the external backend <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3255>
[12:24] <morphis_> zyga: spread passed on https://github.com/snapcore/snapd/pull/3222 now, would be nice to get another review
[12:24] <mup> PR snapd#3222: many: fix test cases to work with different DistroLibExecDir <Created by morphis> <https://github.com/snapcore/snapd/pull/3222>
[12:52] <zyga> morphis_: ack
[12:56] <jdstrand> zyga, Chipaca: fyi, https://forum.snapcraft.io/t/snaps-and-nfs-home/438
[12:56] <Chipaca> heh
[12:56] <Chipaca> "no NFS here", they say
[12:57] <Chipaca> “foo.bar.baz:/share 54G 2.1G 52G 4% /share” says mount
[12:57] <Chipaca> or df is it
[12:57] <Chipaca> anyway
[12:57] <Chipaca> ~_~
[12:58] <Chipaca> funny how these things come in waves
[13:00] <zyga> jdstrand: niceee!
[13:01] <zyga> niiiiice
[13:11] <ogra_> jdstrand, i'm battling with the serial-port interface on the pi3 (for BT) ... but it doesnt get picked up somehow ... http://paste.ubuntu.com/24472828/
[13:12] <ogra_> any idea why that could be hidden (all the gpio interfaces are listed in snap interfaces)
[13:18] <jdstrand> ogra_: can you paste the complete yaml?
[13:20] <ogra_> jdstrand, http://paste.ubuntu.com/24472859/ the inoput is at https://github.com/snapcore/pi3-gadget/blob/master/snapcraft.yaml
[13:22] <jdstrand> ogra_: and 'snap interfaces' doesn't show pi-bluetooth but does show all those bcm-gpio-# interfaces?
[13:23] <ogra_> jdstrand, right
[13:23] <jdstrand> regexp.MustCompile("^/dev/tty(USB|ACM|XRUSB|S|O)[0-9]+$")
[13:23] <jdstrand> that doesn't have AMA
[13:25] <jdstrand> ogra_: https://github.com/snapcore/snapd/blob/master/interfaces/builtin/serial_port.go#L53
[13:25] <jdstrand> ogra_: is SanitizeSlot that is checked. You probably have "serial-port path attribute must be a valid device node" in your logs somewhere
[13:25] <jdstrand> s/is/in/
[13:28] <ogra_> Apr 28 12:57:00 localhost /usr/lib/snapd/snapd[1243]: task.go:303: DEBUG: 2017-04-28T12:57:00Z INFO snap "pi3" has bad plugs or slots: pi-bluetooth (serial-port path attribute must be a valid device node)
[13:28] <ogra_> jdstrand, correct ...
[13:28] <ogra_> and i was battling with gustavo to get some more generic regex there ... boooo
[13:29] <ogra_> (he denied it)
[13:31] <ogra_> zyga, ^^^ myth solved ...
[13:32] <zyga> ogra_: nice
[13:32] <ogra_> (but thatks for offering help)
[13:34] <zyga> ogra_: review done
[13:34]  * ogra_ hugs zyga 
[13:35] <mup> PR core-build#8 closed: add shellcheck test, fix code for shellcheck <Created by ogra1> <Merged by mvo5> <https://github.com/snapcore/core-build/pull/8>
[13:35] <ogra_> and mvo
[13:35] <ogra_> :)
[13:35] <mvo> yw
[13:37] <ogra_> jdstrand, funny ... looking at the code it seems the USB part of it simply accepts any device name, only the raw device code has such a check
[13:40] <zyga> jdstrand: you may be interested in approving some of the snap-confine spread tests that I didn't port earlier
[13:40] <jdstrand> ogra_: that's because the path attribute when using usb attributes isn't the same. it is the name of the symlink, not the device the symlink points to.
[13:40] <ogra_> ah, k
[13:41] <Chipaca> the PATH
[13:41] <jdstrand> serialUDevSymlinkPattern is used for those
[13:41] <Chipaca> the PPAAAATHTHTHHTHHHTHTHT </spittle>
[13:41] <Chipaca> debian does not have the snippet that lets /snap/bin survive sudo
[13:41] <ogra_> https://github.com/snapcore/snapd/pull/3256
[13:41] <mup> PR snapd#3256: add ttyAMA0 to allowed devices, needed for pi3 BT <Created by ogra1> <https://github.com/snapcore/snapd/pull/3256>
[13:41] <jdstrand> zyga: I'll add to the list, but I already have several other reviews in from of that
[13:41] <Chipaca> morphis_—
[13:42] <zyga> jdstrand: no worries, they are not high-priority
[13:42] <zyga> jdstrand: I just decided to use the next week for things like that
[13:42] <zyga> Chipaca: ah
[13:42] <zyga> Chipaca: indeed!
[13:42] <mup> PR snapd#3256 opened: add ttyAMA0 to allowed devices, needed for pi3 BT <Created by ogra1> <https://github.com/snapcore/snapd/pull/3256>
[13:42] <zyga> Chipaca: it's good (tm) to test on !ubuntu :)
[13:42] <zyga> Chipaca: (wait until we get to fedora)
[13:42] <Chipaca> morphis_— is that a you thing, or is it a somebody else thing?
[13:43] <zyga> Chipaca: it may not be approved in the end because 9 is frozen and people may nack it in sid
[13:43] <Chipaca> zyga— you only say that because it wasn't _your_ morning wasted :-P
[13:43] <Chipaca> zyga— https://www.youtube.com/watch?v=wTDUuBWGtpU
[13:43] <jdstrand> ogra_: I commented
[13:44] <ogra_> oh, tests ...
[13:44] <zyga> Chipaca: not wasted, imagine all the happy people using debian that will benefit from _you_ finding this and not them having to find it
[13:46]  * zyga searches youtube history for an appropriate response
[13:52] <cwayne> zyga: heya, our fix in edge?
[13:53] <zyga> cwayne: yes
[13:53] <zyga> cwayne: in beta
[13:53] <zyga> cwayne: it's in 2.25 now
[13:53] <zyga> :-)
[13:53] <zyga> cwayne: give it a try!
[13:53] <cwayne> :D
[14:00] <morphis_> Chipaca: which thing do you mean?
[14:35] <jdstrand> Trevinho: hey, looking at your PR. how do I apply your patch to a snapcraft build?
[14:35] <jdstrand> like, what's the proper way to do that?
[14:36] <cwayne> zyga: yay, calling snaps from snaps seems to work :D :D :D
[14:36] <zyga> cwayne: wooot :D
[14:36] <zyga> let's hope it stays that way!
[14:36] <cwayne> zyga: :)
[14:36] <cwayne> if it does, I owe you many beers at the next sprint we're both at :)
[14:36] <zyga> cwayne: I really hope this will ease the work for you guys
[14:37] <zyga> I think this is the longest patch ever
[14:37] <cwayne> zyga: it will indeed, well even more so for QA team, we can automate the crap out of testing now :)
[14:50] <mup> PR snapd#3257 opened: tests: specify the auto-refreshable snap being tested <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3257>
[14:56] <pstolowski> pedronis, can you have one more look at #3235? i did the simple renaming you requested
[14:57] <pedronis> pstolowski: in a little bit
[14:58]  * Pharaoh_Atem sighs
[14:58]  * kyrofa sighs louder
[14:58] <Pharaoh_Atem> zyga: welp, apparently I can't take vacations until *at least* June 9th
[14:59] <Pharaoh_Atem> company mandate
[14:59] <Pharaoh_Atem> starting from May 22
[14:59] <Pharaoh_Atem> so no vacation allowed for May 22 - June 8
[15:00] <zyga> Pharaoh_Atem: hmm hmm
[15:04] <Pharaoh_Atem> zyga: so if there's a sprint in the first week of June and you guys want me there, I can't be there :(
[15:05] <zyga> Pharaoh_Atem: add this to the forum, I think nothing is set in stone yet
[15:28] <Pharaoh_Atem> zyga: done
[15:29] <zyga> thanks
[15:54] <pedronis> pstolowski: I looked at it, it seems fine, but not sure whether Gustavo wanted to insist about the other test being done a bit differently
[15:55] <pstolowski> pedronis, yes, i'm not clear on that either. i don't intend to land this without his +1
[16:22] <Chipaca> morphis_— compare /etc/sudoers.conf on debian and ubuntu
[16:22] <Chipaca> morphis_— in ubuntu we added /snap/bin to secure_path
[16:23] <morphis_> Chipaca: hm, something we should better change
[16:24] <morphis_> Chipaca: we should talk slangasek and mwhudson about that, they maintain snapd in debian
[16:34] <ogra_> morphis_, well, it is a patch to ubuntus sudo ... thats nothing snapd can provide ... i fear the chances are rather low that debian would accept this
[16:35] <morphis_> ogra_: hm
[16:35] <morphis_> ogra_: what do we loose with not having it?
[16:35] <ogra_> you need to give the full /snap/bin path when calling snap apps as sudo
[16:37] <ogra_> the prob is that you cant really append anything to secure_path via a sudoers.d confiig snippet, so the change needs to be in the sudo config itself, cant just be shipped from snapd
[16:37] <morphis_> hm
[16:38] <ogra_> so the path really only exists for ubuntus sudo ... not sure if Pharaoh_Atem and zyga found any other way for fedora that you could use in debian
[16:41] <Pharaoh_Atem> ogra_: since sudoers doesn't allow path expansion, there's no nice way to do it
[16:41] <Pharaoh_Atem> otherwise we could have a drop in file in fedora that would allow it
[16:41] <ogra_> Pharaoh_Atem, yeah ... except for the sudo package itself ... i suspected it is the same in fedora
[16:47] <Pharaoh_Atem> ogra_: yep
[16:47] <Pharaoh_Atem> sudo is one of those catch-22 programs
[16:48] <ogra_> well, it is also more security relevant than others ... so in some places hardcoding is a given
[16:48] <Pharaoh_Atem> I knew about it being an issue from my own testing, but given that classic snaps and so many other things for snappy don't work on Fedora due to no path relocation support for classic confinement, I figured it's fine that you can't sudo a snapped binary
[16:48] <ogra_> except for a binary that wants sudo :)
[16:49] <Pharaoh_Atem> but there's no chance of that existing in a snap that expects strict confinement
[16:49] <jdstrand> kyrofa: I think Trevinho is eow, perhaps you could answer my question to him from earlier? Ie, I'd like to test https://github.com/sergiusens/snapcraft-preload/pull/14, but how do I do that in my snap using snapcraft?
[16:49] <mup> PR sergiusens/snapcraft-preload#14: preload: don't cut the last char of the redirected path <Created by 3v1n0> <Merged by sergiusens> <https://github.com/sergiusens/snapcraft-preload/pull/14>
[16:49] <ogra_> indeed there is
[16:49] <Pharaoh_Atem> what?
[16:49] <ogra_> we have lots of them
[16:49] <Pharaoh_Atem> welp, they're broken then
[16:49] <ogra_> on core ...
[16:49] <ogra_> nope they arent
[16:50] <ogra_> if youneed some administrative tool being run by the system user, you use sudo
[16:50] <kyrofa> jdstrand, using the remote/cloud part (whatever we're calling them these days)
[16:50] <jdstrand> kyrofa: or more specifically. I need to apply a patch to a part before the build
[16:50] <kyrofa> jdstrand, oh
[16:51] <morphis_> Pharaoh_Atem: somehing like sudo /snap/bin/nmcli
[16:51] <kyrofa> jdstrand, what patch? You mean you want to test out his branch?
[16:51] <ogra_> yeah
[16:51] <kyrofa> Or something else?
[16:51] <ogra_> or the wifi ap setup wizard
[16:51] <morphis_> Pharaoh_Atem: there are a lot snaps which do that
[16:51] <Pharaoh_Atem> sure, but none of them are for classic distros
[16:51] <morphis_> or better said, the snaps don't do that itself
[16:51] <morphis_> Pharaoh_Atem: ?
[16:51] <ogra_> even on desktop distros ...
[16:52] <jdstrand> kyrofa: I can do 'snapcraft' and that'll give me the parts directory and I can find preload.c fine, but I'm not sure the sequence of snapcraft commands to get the parts before building them
[16:52] <jdstrand> kyrofa: https://github.com/sergiusens/snapcraft-preload/pull/14/commits/0675d4cba6f7cc2df2505d2aad1737a373e469ea
[16:52] <mup> PR sergiusens/snapcraft-preload#14: preload: don't cut the last char of the redirected path <Created by 3v1n0> <Merged by sergiusens> <https://github.com/sergiusens/snapcraft-preload/pull/14>
[16:52] <jdstrand> oh, it is merged already
[16:52] <jdstrand> nm then :)
[16:52] <kyrofa> jdstrand, yeah just rebuild using the remote part and it'll be picked up
[16:52] <morphis_> jdstrand: NetworkManager, ModemManager, bluez snaps, all can be used on classic too
[16:52] <jdstrand> kyrofa: it was still open when I initially asked
[16:53] <morphis_> jdstrand: sorry, was for Pharaoh_Atem :-)
[16:53] <kyrofa> Hmm, yeah looks like it was just merged
[16:53] <jdstrand> kyrofa: anyway, yeah, I know what to do know. I just wasn't sure how to get parts/, patch, then build
[16:53] <Pharaoh_Atem> morphis_: well, then, they're broken on Fedora
[16:53] <morphis_> Pharaoh_Atem: we didn't invested much time it making that use case working well yet but there is nothing which prevents you from using them on a classic desktop
[16:53] <Pharaoh_Atem> nothing I can do about it
[16:53] <jdstrand> now*
[16:53] <morphis_> Pharaoh_Atem: why?
[16:53] <ogra_> Pharaoh_Atem, why ?
[16:54] <ogra_> lol
[16:54] <morphis_> :-)
[16:54] <Pharaoh_Atem> because if they need sudo powers, then I need to get the maintainer of sudo to change sudo
[16:54] <morphis_> the only thing which is broken that you need to call them with an absolute path when you want to call them with sudo
[16:54] <Pharaoh_Atem> and he's not going to want to do that unless confinement works for snaps
[16:54] <kyrofa> jdstrand, but for future reference, try creating a part named the same as the remote part, but don't specify a plugin
[16:54] <ogra_> Pharaoh_Atem, you cn always call sudo /snap/bin/nmcli
[16:54] <Pharaoh_Atem> ogra_: right, but you want sudo nmcli to work :P
[16:54] <ogra_> Pharaoh_Atem, you can just not use sudo binaries without using the full path
[16:54] <Pharaoh_Atem> not having people call /var/lib/snapd/snap/bin/nmcli
[16:54] <kyrofa> jdstrand, then you might be able to use the prepare/build/install scriptlets to modify it. That's untested, but I think it'll work
[16:54] <morphis_> Pharaoh_Atem: true, and that is what we have to fix
[16:55] <ogra_> Pharaoh_Atem, but the snaps are not broken ... just harder to use
[16:55] <Pharaoh_Atem> ogra_: the expectation is busted
[16:55] <Pharaoh_Atem> and that's arguably worse
[16:55] <ogra_> its a usability issue ...
[16:55] <jdstrand> kyrofa: interesting
[16:59] <slangasek> morphis_, Chipaca, ogra_: I don't see any way to get this added without patching the Debian sudo package; with Debian in freeze right now I think this is unlikely to land before release.  We could file a bug on Debian's sudo package, but I wouldn't push on it right now.
[17:00] <morphis_> slangasek: but would it be generally possible even after the release as a bug fix?
[17:00] <slangasek> morphis_: as a stable update? almost certainly not
[17:00] <morphis_> slangasek: ok
[17:41] <mup> Bug #1687079 opened: cannot change profile for the next exec call: No such file or directory <Snappy:New> <https://launchpad.net/bugs/1687079>
[18:33] <zyga> re
[18:43] <Chipaca> yusss! completion branch green again except for artful autosomal tests
[18:57] <zyga> mvo: hey
[18:57] <zyga> mvo: still around?
[19:10] <zyga> mvo: anyway, I corrected #3250
[19:21] <mup> PR snapd#3256 closed: add ttyAMA0 to allowed devices, needed for pi3 BT <Created by ogra1> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3256>
[19:27] <stokachu> Facu: it happened again
[19:28] <stokachu> Facu: just uploaded beta3 of conjure-up via launchpad and now the stable/candidate channels are not seen
[19:28] <stokachu> snap info conjure-up
[19:28] <stokachu> so i dont know what's going on
[19:35] <stokachu> anyway i can't wait around for you guys i have to try and republish it
[19:49] <ryebot> I'm trying to push a ppc64le snap with snapcraft, which snapcraft built, but the store isn't accepting the snap, saying "Invalid architecture specified in the manifest: ppc64le"
[19:52] <nacc> ryebot: shouldn't it be ppc64el for debian/ubuntu ?
[19:52] <stgraber> ryebot: I suspect the store expects to see "ppc64el" rather than "ppc64le"
[19:53] <ryebot> fair enough -- any reason snapcraft doesn't seem to care during the build?
[19:53] <nacc> ryebot: that i don't know :)
[19:53] <ryebot> +1
[19:53] <xMudrii> hi everybody!
[19:53] <ryebot> thanks guys
[19:53] <xMudrii> can I ask here a question about go plugin for snapcraft?
[19:56] <xMudrii> anyways - i have snapcraft.yaml that I want to build using snapcraft. i'm planning to use it only for testing (for now) and not for releasing.
[19:57] <xMudrii> problem is, when I run snapcraft, it tries to fetch golang-1.6 from ubuntu's repo
[19:57] <xMudrii> can I set path to golang? i want to build it using 1.8.1 not with 1.6
[20:02] <Facu> stgraber, I see 2.1.15 in stable & candidate
[20:03] <stgraber> Facu: was that meant for stokachu?
[20:03] <Facu> stgraber, yes, sorry
[20:04] <stokachu> Facu: yea me too
[20:04] <stokachu> Facu: is snap info arch dependant on host?
[20:04] <Facu> stokachu, IIRC yes
[20:04] <stokachu> hmm ok
[20:05] <stokachu> lemme find out what arch they are on
[20:58] <mup> PR snapd#3250 closed: many: fix tests with go1.8 / artful <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3250>
[22:01] <cachio> jdstrand, hey, do you know if there is any way to delete an extrauser in ubuntu core?
[22:02] <jdstrand> cachio: iirc, deluser doesn't undestand --extrauser yet (this is a foundations thing)
[22:02] <jdstrand> cachio: you'd have to modify the files directly
[22:02] <cachio> jdstrand, you mean make the deletion manually
[22:02] <cachio> ?
[22:03] <jdstrand> cachio: yes
[22:03] <jdstrand> cachio: in /var/lib/extrausers/
[22:05] <jdstrand> cachio: I'm eow and need to step away, but I'll check backscroll if you have other questions
[22:05] <cachio> jdstrand, sure, thanks
[22:05] <cachio> nice weekend