/srv/irclogs.ubuntu.com/2017/04/28/#snappy.txt

=== bdx_ is now known as bdx
=== mup_ is now known as mup
=== JanC_ is now known as JanC
mupPR snapcraft#1288 opened: store: collaboration UI for snaps <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1288>02:07
mupPR snapcraft#1289 opened: beta <Created by snappy-m-o> <https://github.com/snapcore/snapcraft/pull/1289>03:31
mupPR snapcraft#1289 closed: beta <Created by snappy-m-o> <Closed by elopio> <https://github.com/snapcore/snapcraft/pull/1289>05:43
mupPR snapcraft#1290 opened: tests: refactor tests with build and stage packages <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1290>05:43
mvoPharaoh_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?06:42
=== chihchun is now known as chihchun_afk
pedronismvo: hi, is the release draft missing mentioning release.schedule ?07:07
pedronissorry refresh.schedule07:07
=== chihchun_afk is now known as chihchun
mvopedronis: yes indeed, I need to add that07:17
zygao/07:23
zygamvo: hey, how are you feeling07:23
zygamvo: ready for the sprint?07:23
mvozyga: yes07:24
mvofgimenez: new beta snaps available for an early smoke test of 2.2507:24
fgimenezmvo: great thanks! on it, will let you know how it goes07:25
mvofgimenez: and ubuntu-core as well07:25
fgimenezmvo: ack, we have spread tests for it too, but yet no spread-cron branches up, i'll trigger them manually07:26
mupPR snapd#3246 closed: cmd/snap-confine: remove obsolete debug message <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3246>07:30
mupPR snapd#3249 opened: releasing package snapd version 2.25 <Created by mvo5> <https://github.com/snapcore/snapd/pull/3249>07:41
zygapstolowski: can you have a 2nd look on https://github.com/snapcore/snapd/pull/3225 - I think I addressed your questions07:41
mupPR snapd#3225: cmd/snap-update-ns: add actual implementation <Created by zyga> <https://github.com/snapcore/snapd/pull/3225>07:41
zygapstolowski: if not just comment and I'll do my best07:42
zygaI could also use a 2nd review on (trivial) https://github.com/snapcore/snapd/pull/323407:42
mupPR snapd#3234: overlord/snapstate/backend,interfaces/mount: move ns management code <Created by zyga> <https://github.com/snapcore/snapd/pull/3234>07:42
pstolowskizyga, sure, will do in a moment07:42
* zyga -> breakfast07:53
zygaday of code reviews07:53
mupPR snapd#3250 opened: store: fix TestDownloadSyncFails for go1.8 <Created by mvo5> <https://github.com/snapcore/snapd/pull/3250>07:58
abeatoogra_, how is the initrd for a kernel snap built? where does snapcraft pull the sources from?08:01
mupPR snapd#3251 opened: packaging: cleanup how built-using is generated  <Created by mvo5> <https://github.com/snapcore/snapd/pull/3251>08:19
zygare08:22
fgimenezmvo: 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 test08:27
mvofgimenez: uh, strange08:30
mvofgimenez: strange because this was/is working ok in qemu and linode, wonder whats the difference with external08:30
fgimenezmvo: let me run it isolated with -debug on amd64 to seee what's going on08:34
zyga_pstolowski: some comments on https://github.com/snapcore/snapd/pull/3217#pullrequestreview-3530236308:36
mupPR snapd#3217: snap: support for snap tasks --last= <Created by stolowski> <https://github.com/snapcore/snapd/pull/3217>08:36
pstolowskithanks08:36
zyga_Chipaca: hey, I see lots of completion failures on Debian: https://github.com/snapcore/snapd/pull/315008:39
mupPR snapd#3150: In-snap bash tab completion <Created by chipaca> <https://github.com/snapcore/snapd/pull/3150>08:39
mvopedronis: 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 CE08: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
mupPR 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
mvozyga_: not quite08:44
mvozyga_: it could with some more work08:44
zyga_aha, so this would just prime the rest of the code to do the right thing08:45
zyga_?08:45
mvozyga_: 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 store08:45
mvozyga_: my branch just makes the code fish out most of the store info from the assertion. however it will still later contact the store08:45
mvozyga_: exactly08:46
zyga_mvo: understood, thanks!08:46
mvozyga_: this is a bit of a quick fix for CE, I think we can do it fully offline with a bit more work08:46
zyga_I just never looked at that code08: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:46
zyga_mvo: but no ad-hoc design on IRC :)08:47
mvozyga_: yeah, I think with full offline capability this would be almost there08:47
pedroniszyga_: 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 assertions08:48
pedronisthough08:48
zyga_pedronis: manifest could only capture a snapshot of what the model describes08:48
zyga_pedronis: not as a way to create other things08:48
zyga_pedronis: I think that it will be a common request from CE, to be able to reproduce image builds exactly, at specific revisions08:49
pedroniszyga_: well a manifest is not enough (given how the store works atm and rules), you really need to cache what prepare-image used08:49
zyga_pedronis: yes, I was thinkin about a full cache08:51
zyga_pedronis: with all the snaps and assertions08:51
pedronisok08:51
pedronisit's all a bit odd because if you don't change anything then it's pointless08:52
pedronisyou get the image you already got once08:52
=== chihchun is now known as chihchun_afk
zygaSon_Goku: hey, how are you doing09:11
=== chihchun_afk is now known as chihchun
zygapstolowski: https://github.com/snapcore/snapd/pull/3119 has two reviews09:19
mupPR snapd#3119: interfaces: API additions for interface hooks <Created by stolowski> <https://github.com/snapcore/snapd/pull/3119>09:19
zygapstolowski: can we merge it?09:19
pstolowskizyga, no, I'd like niemeyer's +109:19
mupPR 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
zygapstolowski: ok09:19
Chipacaooh, el reg article mentioning snaps09:20
zygaChipaca: can you share the URL please09:20
* Chipaca clutches it close to his chest09:20
ChipacaNO09:20
zygaaww :-(09:20
Chipacazyga— http://www.theregister.co.uk/2017/04/28/snap_flatpacks_the_future_of_desktop_linux/09:20
Chipacashame it sounds like they've only actually tried flatpaks09:22
Chipaca¯\_(ツ)_/¯09:22
zyga"the kernel is not going to be a flatpak any time soon"09:26
zygayeah, because it's a snap already09:26
ogra_abeato, during the core snap build ....09:26
fgimenezmvo: 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 digging09:26
ogra_abeato, https://github.com/snapcore/core/blob/master/live-build/hooks/25-create-generic-initrd.chroot09:28
abeatoogra_, are not initramfs images built with the kernel?09:29
abeatoI mean, when building the kernel snaps09:29
ogra_abeato, nope, it is generic ...09:29
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 ships09:30
mvofgimenez: thank you09:30
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 there09:31
abeatoogra_, 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 files09:31
ogra_abeato, depends, do you need something specific  the official kernels work slightly different (not using the kernel plugin actually)09:32
Son_Gokuzyga, the kernel as a snap is pretty useless from a multi-distro point of view09: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 time09:33
zygaSon_Goku: I didn't mean the corss distro POV, snapd itself is cross distro as it aims to liberalize what a distribution is09:33
ogra_abeato, all managed via the initramfs-tools-ubuntu-core package from the PPA09:33
zygaSon_Goku: and who knows, maybe we can teach snapd to install kernels on classic :)09:34
abeatoogra_, no, just wondering how things are built, thanks for the info09:34
zygaSon_Goku: it's just software09:34
* Son_Goku wonders what problem is being solved at that point09:34
abeatoogra_, ok so we can add things for android-boot in that package as you suggested09:34
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
zygaSon_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 script09:35
Son_Gokuzyga: if the Linux world wanted that, we would have had a common packaging environment already09:35
ogra_abeato, and a simple switch on the kernel cmdline to pick that instead of the default for booting recovery09:35
Son_GokuGod knows people tried09:35
zygaSon_Goku: that's totally untrue ;)09:35
abeatoogra_, 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
zygaSon_Goku: the linux world cannot want anything as there are always polarized opinions09:36
Son_Gokuat least we're down to ~4 systems instead of ~2009:36
zygaSon_Goku: I'd say that technically it wasn't done correctly before09:36
zygaSon_Goku: but it's not about desire at all09:36
ogra_abeato, for secureboot we need the kernel binary signed by the archive key, using the existing deb is the easiest way for that09:36
pstolowskizyga, addressed your comments to #321709:36
zygaSon_Goku: just add hrw and any other person into the "linux world" and they will disagree ;)09:37
zygapstolowski: thanks! looking09:37
Son_Gokuzyga: that's unfair09:37
Son_Gokuhrw complains about everything :)09:37
zygaSon_Goku: see09:37
abeatoogra_, got it, so if secureboot is not involved, it would be better to use kernel plugin, right?09:37
zygaSon_Goku: "linux world" is not a measure of anything09:37
Son_Gokuzyga: If I *really* wanted to, i could boot Ubuntu kernels on Fedora09:38
zygaSon_Goku: but the effort is non-trivial09:38
Son_Gokuyes09:38
Son_Gokubut snaps don't make that better09:38
zygaSon_Goku: if you had any kenrel in a snap you could just do it casually09:38
Son_Gokuthey make the process more opaque09:38
pstolowskizyga, looking at your 3225, sorry it took so long09:38
* Chipaca sharpens his Stick of Poking and pokes at spread09:38
zygaSon_Goku: I don't understand how09:38
Son_Gokufundamentally, the kernel has to know a lot about what it's being built for09: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 plugin09:38
Son_Gokuand 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 userland09:39
abeatoogra_, 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 kernel09:39
zygaSon_Goku: I'm not sure I agree09:39
Son_Gokuthe kernel influences the userland and vice versa, so changing expectations can have odd effects09:39
zygaSon_Goku: if that were the case we didn't have generic x86 kernels09:39
Son_GokuI'm not talking about at the hardware level09:40
ogra_abeato, i.e. for the beaglebone community image i also use the linux-generic kernel simply because it fully supports the borad09:40
Son_GokuI'm talking purely software interfaces09:40
abeatoogra_, source-based in this case09:40
Son_Gokuand some of them are non-obvious ones09:40
ogra_right, there you want the kernel plugin09:40
Son_Gokufor example, Ubuntu rewrites the version and bludgeons the upstream kernel version out of the kernel version09:40
Son_GokuFedora doesn't09:40
abeatogreat09:40
zygaSon_Goku: so what/09:41
Son_Gokuif tooling in a Fedora userland expects to check based on the upstream kernel version, that might have unexpected side effects with an Ubuntu kernel09:41
zygaSon_Goku: sure but that's very unlikely09:41
Son_Gokuis it?09:41
zygaSon_Goku: and totally irrelevant, every distributor did something similar for whatever reasons09:42
zygaSon_Goku: yes, it's a nitpick, totally09:42
Son_Gokubut the point is that expectations are set based on a distribution convention09:42
zygawhat expectations?09:42
zygathe version string, please!09:42
Son_Gokuhey, I know of plenty of scripts and things that check it09:42
Son_GokuI personally had to write one for blacklisting bad kernel versions09:43
zygawill a system stop booting because of those scripts?09:43
zygaamyway09:43
Son_Gokuno, but maybe something will fire that shouldn't or something09:43
zygathat was not the point09:43
zyga(that's always possible anyway because FOSS has terrible QA)09:43
zygathe point is that snaps have this already09:43
Son_Gokubut another thing is that Ubuntu kernels are unsigned and Fedora ones are09:43
Son_Gokuso a Fedora boot system wouldn't boot an Ubuntu kernel anyway09:44
Son_Gokuon UEFI09:44
zygayou are looking for problems, not solutions IMO09:44
zygaand ubuntu kernels are signed too AFAIK09:44
zygathere are two sets09:44
Son_Gokuas far as I knew, on Ubuntu, only shim and grub are signed09:44
Son_Gokumaybe even only shim09:44
Son_GokuI know in Fedora, we sign everything up to the kernel09:45
zygaSon_Goku: no, the kernel is signed too09:45
Son_Gokuhm, then does Ubuntu's kernel just not do signature checking for kernel modules?09:45
zygaSon_Goku: it does09:46
zygaSon_Goku: you remember 14.04 stuff09:46
Son_Gokuah09:46
Son_Gokuso this changed after then09:46
zygaSon_Goku: FYI I had to sign vmware modules to load them on my machine09:46
Son_Gokuah, so that's good09:46
zygaSon_Goku: then enroll the key in UEFI09:46
Son_Gokuyeah, I know that process well :P09:46
zygamvo: artful-amd64?09:47
Son_Gokuzyga: anyway, I need to take a nap, and then I'll come back and start rolling 2.2509:48
Son_GokuI've been up for too long09:48
zygaSon_Goku: rest well :-)09:49
mvozyga: oh yes!09:49
zygaSon_Goku: I'm cleaning up stuff in anticipation for 2.2509:49
zygamvo: what is artful? :D09:49
mvoSon_Goku: rest well indeed09:49
zygamvo: what is that test about?09:49
mvozyga: its for 17.1009:49
Son_Gokumvo: I hate live-build, so much09:49
zygaaaah09:49
Son_Gokudebugging that makes me want to murder things09:49
mvozyga: its failing left and right09:49
zyga17.10 is artful something09:49
zygaI forgot09:49
mvoSon_Goku: everybody hates it09:49
mvoSon_Goku: I would really like to kill it with fire09:50
Son_Gokumvo: we were trying to use it for a project but it's horrible09:50
Son_Gokuso now I've moved onto fixing the Ubuntu support in KIWI and build things that way09:50
mvoSon_Goku: :/ maybe we can chat after your nap, there must be better ways09:50
Son_Gokuit's not brain-dead and doesn't make me feel murderous09:51
Son_Gokumvo: sure09:51
mvozyga: snapd tests are broken in 17.10, i.e. with go1.8 this is why I added the test machinery for it09:51
Son_Gokuzyga: Artful Aardvark09:51
zygaSon_Goku: aaaaaaaaaaa-distribution09:51
mvozyga: to avoid getting a gazillion FTBFS mails when we try to build there09:52
mvoplus I'm sure somewhere is a distro that already moved to go1.8 too09:52
zygamvo: are you on artful already?09:52
pedronismvo: well to be honest I would like us to use 1.8 everywhere ;)09:52
* zyga spends all of today in github.com/notifications and pull requests09:53
zygapedronis: yes, +100 on 1.809:53
zygagoodies all around09:53
pedronis(because go doesn't care at mantaining old releases)09:53
zygaSon_Goku: would fedora accept 1.8 toolchain for fc25?09:53
mvopedronis: look at it this way - adding artful tests is the first step towards this goal09:54
zygaSon_Goku: e.g. if we wanted to build snapd with a more recent version09:54
mvoalso the go snap \o/09:54
zygamvo: 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 dependency09:55
pedronismvo: 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
pedroniss/did you/did you add/09:55
mvomwhudson: I love your go snap (I think its yours, right?)09:55
mvopedronis: autopkgtest09:55
mvopedronis: so things will run in parallel at least09:55
mvopedronis: but we should definitely brainstorm during the sprint09:56
pedronisok09:56
mvopedronis: about the tests09:56
pedronisyes, they get pretty terrible, especially around release09:56
pedronismaking your life not so fun I think09:56
mvopedronis: did you see my earlier question about 3241?09:56
mvopedronis: absolutely, plus travis seems to take a nap in between sometimes too09:56
mvopedronis: i.e. we hit some limits there too it seems09:57
pedronisyes09:57
pedronisa mixture of things09:57
pedronisbut we need to do something, I think I was starting to have stockholm syndrom but the pain is real09:57
mvolol09:58
* mvo hugs pedronis09:58
pedronismvo: what's the question 3241, I think I missed it?09:58
pedronis*about09:58
zygapedronis: 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 needed09:58
pedroniswell, I don't think the issue is just unreliable09:59
mvopedronis: 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 CE09:59
pedronisthey are also too slow for something we run for each commit in the universe09:59
pedronisI think09:59
zygamorphis_: I'll re-review /usr/lib/linux/vmlinuz-4.8.0-46-generic.efi.signature09:59
zygaer09:59
pedronisslow+unreliable = the worst09:59
zygacopy-paste fail09:59
mvoyeah, its tricky to find the right balance09:59
zygahttps://github.com/snapcore/snapd/pull/322209:59
mupPR snapd#3222: many: fix test cases to work with different DistroLibExecDir <Created by morphis> <https://github.com/snapcore/snapd/pull/3222>09:59
zygamorphis_: just let me know when you are don with it10:00
pedronismvo: I'll try to look after lunch, I also need to do some sprint prep (both travel but also writing some gdoc)10:00
zygapedronis: I wonder if it would make sense for spread to retry individual failing tests (say up to 5 times)10:00
zygabut we'd have to fix travis time limit10:00
mvopedronis: thank you10:00
zygaand really work on making tests better for a cycle10:00
morphis_zyga: I just fixed the failing unit test10:01
zygamorphis_: thanks10:01
zygaENOSERVERS10:02
zygathrow more $$$ at linode10:02
zygain samsung we had a very nice system10:02
zygasince any avereage office had easily about a thousand laptops/desktops for devlopers10:02
zygaand they were mostly idle all day (editing = low cpu)10:03
zygathey were all wired to gigantic distributed task system for compiling software10:03
zygaso when you hit build, it'd really use 100s of machines around you for fantastic speedups10:03
zygaI wonder if we could tap into our machines at home, to send tasks and distribute them among ephemeral test VMs10:03
zygaso travis and linode are not that critical10:03
zygamvo: question about go 1.8, why did you have to switch to DeepContains?10:07
zygabecause of the pointer?10:07
mvozyga: I don't know10:08
zygamvo: aha, ok10:08
mvozyga: looking at this rightnow, but wanted to see if that is the only remaining failure10:09
zygamvo: yeah, testing on 1.8 is important, I wonder what else awaits us10:09
=== chihchun is now known as chihchun_afk
mupPR snapd#3253 opened: cmd/snap-confine/spread-tests: discard useless --version test <Created by zyga> <https://github.com/snapcore/snapd/pull/3253>10:11
zygawhy is econnreset failing all the time?10:13
abeatoogra_, did you remember to update core-build repo? it looks like some files are still missing10:17
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 landed10:18
=== chihchun_afk is now known as chihchun
abeatoogra_, ok, please let me know when I can  propose the MP10:18
ogra_oh, i have it locally already no need for yopu to do anything10:19
abeatogreat :)10:19
ogra_is there anything urgent ?10:20
abeatono no10:20
ogra_k10:20
abeatojust wanted to make sure this is not lost10:20
ogra_nah10:20
* ogra_ loses keys and lighters, but rarely code ;)10:20
=== fnordahl_ is now known as fnordahl
abeatolol10:21
mupPR core#36 opened: drop remaining dpkg binary (LP: #1686106) <Created by ogra1> <https://github.com/snapcore/core/pull/36>11:17
mupPR snapd#3254 opened: tests: re-enable and moderninze /media sharing test <Created by zyga> <https://github.com/snapcore/snapd/pull/3254>11:20
robjehow to fix "cannot create user data directory: $path : Permission denied"11:30
Chipacarobje— hey. Where are you getting this?11:30
zygarobje: ls -ld ~/snap/11:30
zygarobje: is that owned by root?11:30
zygarobje: or is the home directory somewhere unusual?11:31
Chipacazyga— ooh, maybe you should ask these same questions on #168685211:31
mupBug #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 :P11:31
robjeall files and dirs owned by my user and group.11:31
zygathanks, asking!11:31
robjehome is on NFS11:31
ogra_aha11:32
zygarobje: ok, can you please pastebin `dmesg | grep DENIED`11:32
zygarobje: and `snap version`11:32
ogra_"somewhere unusual" :)11:32
robjeand snap is a symlink to local storage11:32
Chipacapeople still use NFS <311: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=212411:32
zygarobje: are you using NFS?11:33
zygaoh11:33
zygayou have a dot in your username?11:33
ogra_zyga, he said so above :)11:33
zygarobje: aha11:33
zygarobje: that's unsupported, let me find you a bug report with a lot of details11:33
robjeyes I have a dot in my username11:33
zygarobje: unfortunately there's a kernel limitation here11:33
zygarobje: you can kind of work around this but I'm not sure if that's even possible now11:33
zygahttps://bugs.launchpad.net/ubuntu/+source/snapd/+bug/166255211:34
mupBug #1662552: snaps don't work with NFS home <snapd (Ubuntu):Triaged> <https://launchpad.net/bugs/1662552>11:34
ogra_Chipaca, a second checkmark on https://github.com/snapcore/core/pull/36 would be appreciated (one line change)11:35
mupPR core#36: drop remaining dpkg binary (LP: #1686106) <Created by ogra1> <https://github.com/snapcore/core/pull/36>11:35
zygarobje: have a look at that report, let me know if you think I can help you somehow11:35
Chipacaogra_— what was it that had made us leave the binary last time?11:35
zygarobje: the root issue is nfs leaks to various parts of LSM so confinement cannot be the same11:35
zygarobje: the differences in where user directories are are easier to work around11:35
Chipacabut11:35
Chipacazyga— he doesn't have /snap in nfs11:36
Chipacahis home is11:36
Chipacabut /snap is a symlink11:36
Chipacanow I know _that_ won't work :-) but11:36
zygaChipaca: NFS leaks everyhwere11:36
Chipacawould it work to change it to be a bind mount?11:36
zygaChipaca: if you have something on NFS your process will be blocked by seccomp on sendmsg11:36
ogra_Chipaca, no idea ... i think it was for some code in 15.0411:36
zygaChipaca: apart from that apparmor doesn't look at symlinks but at actual files11:36
zygaChipaca: so some things may need tuning11:37
robjeChipaca $home/snap is a symlink to /local/snap11:37
zygaChipaca: and lastly snap-confine's appramor profile is special11:37
robjei.e. on local hdd11:37
Chipacazyga— 💩11:37
zygaChipaca: all in all it's not trivial to fix everything11:37
ogra_Chipaca, iirc some snap code used to call dpkg --compare-versions11:37
zygaChipaca: I wish someone had fixed the kernel side11:37
zygaChipaca: before that I can really do little :/11:37
zygaChipaca: (or allow all network traffic to everything by default, but even then snapd doesn't control the apparmor profile of snap-confine)11:38
Chipacarobje— 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 blocked11:38
ogra_yay, time travellers!11:40
mupPR core#36 closed: drop remaining dpkg binary (LP: #1686106) <Created by ogra1> <Merged by ogra1> <https://github.com/snapcore/core/pull/36>11:40
zygaogra_: ?11:41
ogra_zyga, i was commenting on Chipaca's PR comment :)11:41
jdstrandthe 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 work11:41
robjeapplied workaround in #1662552. now get "Too many levels of symbolic links"11:42
mupBug #1662552: snaps don't work with NFS home <snapd (Ubuntu):Triaged> <https://launchpad.net/bugs/1662552>11:42
jdstrandthat'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 it11:42
zygarobje: that's a symlink loop then11:42
zygajdstrand: hey!11:42
jdstrandit would perhaps be possible to have that opt-outtable11:42
jdstrandzyga: hey :)11:42
zygajdstrand: are you going to the sprint next week?11:43
jdstrandno11:43
zygajdstrand: aha, me neither, I plan to do some cleanups this cycle11:43
zygajdstrand: tests and cleanups11:43
zygajdstrand: all the interface PRs11:43
jdstrandcool :)11:43
zygajdstrand: and more interface tests :)11:43
zygamvo: quick question about 17.1011:43
zyga+ /tmp/go/bin/spread -v autopkgtest:ubuntu-17.10-amd6411:43
zyga2017-04-28 11:09:50 Found /tmp/autopkgtest.vpoFef/build.lb0/snapd/spread.yaml.11:43
zygaerror: nothing matches provider filter11:43
zygamvo: does this make any sense to you?11:44
robjemoved $home/snap back to nfs home. now works, THNX11:44
zygait seems ubuntu-17.10-amd64 is not a spread target11:44
Chipacazyga— tyler and emily are11:44
jdstrandzyga: I still have a few sizeable reviews/investigations. hopefully no new ones will come in and I can get back to wayland11:44
zygajdstrand: can you summarize what we need to suppor wayland?11:44
Chipacazyga— 1. eat humble pie11:44
zygajdstrand: can we "just open it" using unprivileged iface?11:45
Chipacazyga— 2. more pie?11:45
zygaChipaca: as long as it has strawberries11:45
zygaoh, btw, I have plenty of strawberries, home grown, on the terrace :)11:45
zygaI need to ask the kids to eat them11:45
Chipacazyga— are they tart?11:45
zygaChipaca: tart?11:45
Chipacaif they're tart, make brexit11:45
jdstrandzyga: well, some of this stuff is sprinkled in the forum, is this an official summary or just otoh between you and me?11:45
Chipacazyga— acidic?11:45
zygaChipaca: no, sweet like crazy :)11:45
Chipacaaw, boo11:46
Chipaca:-)11:46
jdstrand(eg, cause you're curious)11:46
zygaChipaca: if brexit strikes, move here :)11:46
zygajdstrand: beween us11:46
zygajdstrand: I can read the forum too11:46
zygaI didn't know there was a thread11:46
zygajdstrand: I'm curious and I'm considering switching to 17.1011:46
Chipacazyga— http://www.bbc.co.uk/food/recipes/etonmess_8108211:46
jdstrandzyga: 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
zygaChipaca: strawberries :-)~~~11:47
* zyga nods11:47
Chipacaworks 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 anyway11:48
jdstrandzyga: gnome-shell uses this thing called mutter, which is gnome's compositor (ie, gnome-shell doesn't use weston, it uses mutter)11:48
zygaChipaca: I cannot imagine eating tart strawberries, are they like that because they are grown in cloudy places?11:49
jdstrandmutter is not complete yet11:49
Chipacazyga— different varieties11:49
zygajdstrand: aha, I didn't know mutter is still a thing, I thought all the magic moved to gnome-shell11:49
jdstrandfor example, mutter requires launching an XWayland for things such as input11:49
jdstrandzyga: gnome-shell talks to mutter11:49
zygajdstrand: aha, interesting, so each app has its own xwayland wrapper?11:49
zygajdstrand: or is there one that just runs for whole shell?11:49
jdstrandzyga: no. there is one shared Xwayland for all applications11:50
jdstrandso, security wise there are a few things11:50
zygajdstrand: and do actual apps see X11 and DISPLAY or is that gone now and xwayland is hidden somehow?11:50
jdstrandin terms of input, gnome-shell/mutter/wayland is ok about separating wayland client from each other and from fallback X clients11:51
jdstrandbecause mutter requires X for somethings, all native wayland clients in gnome require X11:51
jdstrandthis means that native wayland cannot snoop each other, but they can snoop all fallback X clients11:51
jdstrandand fallback X clients can all snoop each other11:52
zygajdstrand: 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
zygajdstrand: aha11:52
jdstrandnative clients don't do anything with X directly11:52
zygajdstrand: well, I guess that depends on how many things are in the latter pool11:52
jdstrandthis is a mutter thing11:52
zygajdstrand: is a gnome-calculator-like app native now?11:52
jdstrandso 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 that11:53
zygajdstrand: I think that's fine, it's a progression of the concept11:53
jdstrandzyga: ghex is the calculator-app I am targeting cause it is in the store11:53
zygajdstrand: over time there will be less of X around11:54
jdstrandzyga: for some definition of 'fine'. it is better, but things get worse11:54
zygajdstrand: and if needed, we might think about that X proxy that11:54
ogra_heh, high hopes11:54
zygaworse?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:54
jdstrandI guess epiphany...11:55
jdstrandanyhoo11:55
jdstrandnot worse11:55
jdstrandthe other thing is the clipboard11:55
jdstrandunfortunately, mutter is not handling the clipboard well at all11:55
* zyga nods11:55
zygaheh11:55
zygaall the modern software :)11:55
* zyga hugs all mutter devs11:55
jdstrandthere 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 did11:56
=== tinwood is now known as tinwood_lunch
jdstrands/did/do/11:56
ogra_just make the snapd conflict with all browsers ... problem solved ;)11:56
ogra_*the snapd deb11:56
jdstrandso, an x client can grab stuff from the clipboard in the background from a native wayland client11:57
jdstrandso password managers are safe atm11:57
jdstrandmutter could be changed to enforce focus, which is something I am going to be knocking on the desktop team's door about11:57
jdstrandbut atm, because all native wayland clients on gnome need X cause of mutter, it is basically a shared clipboard11:58
jdstrandno worse than X, but that literally is saying nothing :)11:58
zygajdstrand: hehe, I see11:59
zygajdstrand: well11:59
zygajdstrand: little by little11:59
jdstrandso, as a whole, it is a step in the right direction, but security-wise, mutter/wayland is not as far along as unity8/mirr11:59
jdstrandmir*11:59
zygawell11:59
zygamaybe mir community will actually make more progress now12:00
zygaI wound't be surprised12:00
ogra_zyga, you mean with the attempt to port everything to wayland ? :P12:00
jdstrandmir could go farther, sure. I don't see gnome porting mutter to mir12:00
jdstrandand kde was pretty clear on that point too12:01
ogra_(all unity8 community projects work towards having mir on top of wayland now)12:01
mupPR snapd#3217 closed: snap: support for snap tasks --last= <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/3217>12:01
zygaogra_: no, I mean by having a nice technology stack that has a nice desktop shell on top12:01
zygaogra_: real mir+unity8 (maybe sans the name)12:01
jdstrandI'll also note that mutter is not bug free (what is!), but it can be challenging to use12:01
ogra_zyga, i know what you mean ... i meant to point out that everyone moves in exactly the other direction12:01
zygaogra_: aha, I didn't know that12:02
ogra_making mir a wayland client12:02
* zyga looks up magic fs 6e73667312:02
zygaaha12:02
zygansfs12:02
jdstrandsometimes 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 issues12:02
jdstrandmutter/wayland has an interesting characteristic of not being able to be restarted (unlike mutter/X)12:03
jdstrandso if mutter under wayland dies, your whole session goes *poof* and you login to a fresh new sesson12:03
jdstrandok, 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
jdstrandlet me tell you. *that* is very annoying12:04
mvozyga: it does, I will add this too12:05
zygamvo: thanks!12:05
* zyga breaks for quick lunch12:05
jdstrandthis doesn't happen all the time. I've not been able to reproduce reliably12:05
jdstrandI've been running gnome-shell/wayland since before 17.04 release and yes, I'm reporting bugs upstream12:06
jdstrandand lastly, I've not looked at plasma or sway yet12:06
jdstrandand and lastly lastly, XDG_RUNTIME_DIR is all wrong for wayland and we have to rethink that (there is a forum topic)12:07
jdstrandoh, 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 added12:08
jdstrandzyga: so, you asked a question and then left. don't think I didn't notice :P12:08
jdstrandbut that is my unofficial report as of today12:09
ogra_zyga, or mvo, a second checkmark on https://github.com/snapcore/core-build/pull/8 would really be nice12:13
mupPR core-build#8: add shellcheck test, fix code for shellcheck <Created by ogra1> <https://github.com/snapcore/core-build/pull/8>12:13
jdstrandmvo: 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:14
=== chihchun is now known as chihchun_afk
jdstrandmvo: 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:19
mupPR 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 review12:24
mupPR snapd#3222: many: fix test cases to work with different DistroLibExecDir <Created by morphis> <https://github.com/snapcore/snapd/pull/3222>12:24
zygamorphis_: ack12:52
=== tinwood_lunch is now known as tinwood
jdstrandzyga, Chipaca: fyi, https://forum.snapcraft.io/t/snaps-and-nfs-home/43812:56
Chipacaheh12:56
Chipaca"no NFS here", they say12:56
Chipaca“foo.bar.baz:/share 54G 2.1G 52G 4% /share” says mount12:57
Chipacaor df is it12:57
Chipacaanyway12:57
Chipaca~_~12:57
Chipacafunny how these things come in waves12:58
zygajdstrand: niceee!13:00
zyganiiiiice13:01
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:11
ogra_any idea why that could be hidden (all the gpio interfaces are listed in snap interfaces)13:12
jdstrandogra_: can you paste the complete yaml?13:18
ogra_jdstrand, http://paste.ubuntu.com/24472859/ the inoput is at https://github.com/snapcore/pi3-gadget/blob/master/snapcraft.yaml13:20
jdstrandogra_: and 'snap interfaces' doesn't show pi-bluetooth but does show all those bcm-gpio-# interfaces?13:22
ogra_jdstrand, right13:23
jdstrandregexp.MustCompile("^/dev/tty(USB|ACM|XRUSB|S|O)[0-9]+$")13:23
jdstrandthat doesn't have AMA13:23
jdstrandogra_: https://github.com/snapcore/snapd/blob/master/interfaces/builtin/serial_port.go#L5313:25
jdstrandogra_: is SanitizeSlot that is checked. You probably have "serial-port path attribute must be a valid device node" in your logs somewhere13:25
jdstrands/is/in/13:25
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 ... boooo13:28
ogra_(he denied it)13:29
ogra_zyga, ^^^ myth solved ...13:31
zygaogra_: nice13:32
ogra_(but thatks for offering help)13:32
zygaogra_: review done13:34
* ogra_ hugs zyga 13:34
mupPR 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 mvo13:35
ogra_:)13:35
mvoyw13:35
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 check13:37
zygajdstrand: you may be interested in approving some of the snap-confine spread tests that I didn't port earlier13:40
jdstrandogra_: 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, k13:40
Chipacathe PATH13:41
jdstrandserialUDevSymlinkPattern is used for those13:41
Chipacathe PPAAAATHTHTHHTHHHTHTHT </spittle>13:41
Chipacadebian does not have the snippet that lets /snap/bin survive sudo13:41
ogra_https://github.com/snapcore/snapd/pull/325613:41
mupPR snapd#3256: add ttyAMA0 to allowed devices, needed for pi3 BT <Created by ogra1> <https://github.com/snapcore/snapd/pull/3256>13:41
jdstrandzyga: I'll add to the list, but I already have several other reviews in from of that13:41
Chipacamorphis_—13:41
zygajdstrand: no worries, they are not high-priority13:42
zygajdstrand: I just decided to use the next week for things like that13:42
zygaChipaca: ah13:42
zygaChipaca: indeed!13:42
mupPR snapd#3256 opened: add ttyAMA0 to allowed devices, needed for pi3 BT <Created by ogra1> <https://github.com/snapcore/snapd/pull/3256>13:42
zygaChipaca: it's good (tm) to test on !ubuntu :)13:42
zygaChipaca: (wait until we get to fedora)13:42
Chipacamorphis_— is that a you thing, or is it a somebody else thing?13:42
zygaChipaca: it may not be approved in the end because 9 is frozen and people may nack it in sid13:43
Chipacazyga— you only say that because it wasn't _your_ morning wasted :-P13:43
Chipacazyga— https://www.youtube.com/watch?v=wTDUuBWGtpU13:43
jdstrandogra_: I commented13:43
ogra_oh, tests ...13:44
zygaChipaca: not wasted, imagine all the happy people using debian that will benefit from _you_ finding this and not them having to find it13:44
* zyga searches youtube history for an appropriate response13:46
cwaynezyga: heya, our fix in edge?13:52
zygacwayne: yes13:53
zygacwayne: in beta13:53
zygacwayne: it's in 2.25 now13:53
zyga:-)13:53
zygacwayne: give it a try!13:53
cwayne:D13:53
morphis_Chipaca: which thing do you mean?14:00
jdstrandTrevinho: hey, looking at your PR. how do I apply your patch to a snapcraft build?14:35
jdstrandlike, what's the proper way to do that?14:35
cwaynezyga: yay, calling snaps from snaps seems to work :D :D :D14:36
zygacwayne: wooot :D14:36
zygalet's hope it stays that way!14:36
cwaynezyga: :)14:36
cwayneif it does, I owe you many beers at the next sprint we're both at :)14:36
zygacwayne: I really hope this will ease the work for you guys14:36
zygaI think this is the longest patch ever14:37
cwaynezyga: it will indeed, well even more so for QA team, we can automate the crap out of testing now :)14:37
=== jgrimm is now known as jgrimm-away
mupPR snapd#3257 opened: tests: specify the auto-refreshable snap being tested <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3257>14:50
pstolowskipedronis, can you have one more look at #3235? i did the simple renaming you requested14:56
pedronispstolowski: in a little bit14:57
* Pharaoh_Atem sighs14:58
* kyrofa sighs louder14:58
Pharaoh_Atemzyga: welp, apparently I can't take vacations until *at least* June 9th14:58
Pharaoh_Atemcompany mandate14:59
Pharaoh_Atemstarting from May 2214:59
Pharaoh_Atemso no vacation allowed for May 22 - June 814:59
zygaPharaoh_Atem: hmm hmm15:00
Pharaoh_Atemzyga: so if there's a sprint in the first week of June and you guys want me there, I can't be there :(15:04
zygaPharaoh_Atem: add this to the forum, I think nothing is set in stone yet15:05
Pharaoh_Atemzyga: done15:28
zygathanks15:29
pedronispstolowski: I looked at it, it seems fine, but not sure whether Gustavo wanted to insist about the other test being done a bit differently15:54
pstolowskipedronis, yes, i'm not clear on that either. i don't intend to land this without his +115:55
Chipacamorphis_— compare /etc/sudoers.conf on debian and ubuntu16:22
Chipacamorphis_— in ubuntu we added /snap/bin to secure_path16:22
morphis_Chipaca: hm, something we should better change16:23
morphis_Chipaca: we should talk slangasek and mwhudson about that, they maintain snapd in debian16:24
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 this16:34
morphis_ogra_: hm16: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 sudo16:35
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 snapd16:37
morphis_hm16:37
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 debian16:38
Pharaoh_Atemogra_: since sudoers doesn't allow path expansion, there's no nice way to do it16:41
Pharaoh_Atemotherwise we could have a drop in file in fedora that would allow it16:41
ogra_Pharaoh_Atem, yeah ... except for the sudo package itself ... i suspected it is the same in fedora16:41
Pharaoh_Atemogra_: yep16:47
Pharaoh_Atemsudo is one of those catch-22 programs16:47
ogra_well, it is also more security relevant than others ... so in some places hardcoding is a given16:48
Pharaoh_AtemI 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 binary16:48
ogra_except for a binary that wants sudo :)16:48
Pharaoh_Atembut there's no chance of that existing in a snap that expects strict confinement16:49
jdstrandkyrofa: 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
mupPR 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 is16:49
Pharaoh_Atemwhat?16:49
ogra_we have lots of them16:49
=== kay is now known as Guest29450
Pharaoh_Atemwelp, they're broken then16:49
ogra_on core ...16:49
ogra_nope they arent16:49
ogra_if youneed some administrative tool being run by the system user, you use sudo16:50
kyrofajdstrand, using the remote/cloud part (whatever we're calling them these days)16:50
jdstrandkyrofa: or more specifically. I need to apply a patch to a part before the build16:50
kyrofajdstrand, oh16:50
morphis_Pharaoh_Atem: somehing like sudo /snap/bin/nmcli16:51
kyrofajdstrand, what patch? You mean you want to test out his branch?16:51
ogra_yeah16:51
kyrofaOr something else?16:51
ogra_or the wifi ap setup wizard16:51
morphis_Pharaoh_Atem: there are a lot snaps which do that16:51
Pharaoh_Atemsure, but none of them are for classic distros16:51
morphis_or better said, the snaps don't do that itself16:51
morphis_Pharaoh_Atem: ?16:51
ogra_even on desktop distros ...16:51
jdstrandkyrofa: 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 them16:52
jdstrandkyrofa: https://github.com/sergiusens/snapcraft-preload/pull/14/commits/0675d4cba6f7cc2df2505d2aad1737a373e469ea16:52
mupPR 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
jdstrandoh, it is merged already16:52
jdstrandnm then :)16:52
kyrofajdstrand, yeah just rebuild using the remote part and it'll be picked up16:52
morphis_jdstrand: NetworkManager, ModemManager, bluez snaps, all can be used on classic too16:52
jdstrandkyrofa: it was still open when I initially asked16:52
morphis_jdstrand: sorry, was for Pharaoh_Atem :-)16:53
kyrofaHmm, yeah looks like it was just merged16:53
jdstrandkyrofa: anyway, yeah, I know what to do know. I just wasn't sure how to get parts/, patch, then build16:53
Pharaoh_Atemmorphis_: well, then, they're broken on Fedora16: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 desktop16:53
Pharaoh_Atemnothing I can do about it16:53
jdstrandnow*16:53
morphis_Pharaoh_Atem: why?16:53
ogra_Pharaoh_Atem, why ?16:53
ogra_lol16:54
morphis_:-)16:54
Pharaoh_Atembecause if they need sudo powers, then I need to get the maintainer of sudo to change sudo16: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 sudo16:54
Pharaoh_Atemand he's not going to want to do that unless confinement works for snaps16:54
kyrofajdstrand, but for future reference, try creating a part named the same as the remote part, but don't specify a plugin16:54
ogra_Pharaoh_Atem, you cn always call sudo /snap/bin/nmcli16:54
Pharaoh_Atemogra_: right, but you want sudo nmcli to work :P16:54
ogra_Pharaoh_Atem, you can just not use sudo binaries without using the full path16:54
Pharaoh_Atemnot having people call /var/lib/snapd/snap/bin/nmcli16:54
kyrofajdstrand, then you might be able to use the prepare/build/install scriptlets to modify it. That's untested, but I think it'll work16:54
morphis_Pharaoh_Atem: true, and that is what we have to fix16:54
ogra_Pharaoh_Atem, but the snaps are not broken ... just harder to use16:55
Pharaoh_Atemogra_: the expectation is busted16:55
Pharaoh_Atemand that's arguably worse16:55
ogra_its a usability issue ...16:55
jdstrandkyrofa: interesting16:55
slangasekmorphis_, 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.16:59
morphis_slangasek: but would it be generally possible even after the release as a bug fix?17:00
slangasekmorphis_: as a stable update? almost certainly not17:00
morphis_slangasek: ok17:00
mupBug #1687079 opened: cannot change profile for the next exec call: No such file or directory <Snappy:New> <https://launchpad.net/bugs/1687079>17:41
zygare18:33
Chipacayusss! completion branch green again except for artful autosomal tests18:43
zygamvo: hey18:57
zygamvo: still around?18:57
zygamvo: anyway, I corrected #325019:10
mupPR 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:21
stokachuFacu: it happened again19:27
stokachuFacu: just uploaded beta3 of conjure-up via launchpad and now the stable/candidate channels are not seen19:28
stokachusnap info conjure-up19:28
stokachuso i dont know what's going on19:28
stokachuanyway i can't wait around for you guys i have to try and republish it19:35
ryebotI'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:49
naccryebot: shouldn't it be ppc64el for debian/ubuntu ?19:52
stgraberryebot: I suspect the store expects to see "ppc64el" rather than "ppc64le"19:52
ryebotfair enough -- any reason snapcraft doesn't seem to care during the build?19:53
naccryebot: that i don't know :)19:53
ryebot+119:53
xMudriihi everybody!19:53
ryebotthanks guys19:53
xMudriican I ask here a question about go plugin for snapcraft?19:53
xMudriianyways - 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:56
xMudriiproblem is, when I run snapcraft, it tries to fetch golang-1.6 from ubuntu's repo19:57
xMudriican I set path to golang? i want to build it using 1.8.1 not with 1.619:57
Facustgraber, I see 2.1.15 in stable & candidate20:02
stgraberFacu: was that meant for stokachu?20:03
Facustgraber, yes, sorry20:03
stokachuFacu: yea me too20:04
stokachuFacu: is snap info arch dependant on host?20:04
Facustokachu, IIRC yes20:04
stokachuhmm ok20:04
stokachulemme find out what arch they are on20:05
=== pbek_ is now known as pbek
mupPR snapd#3250 closed: many: fix tests with go1.8 / artful <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3250>20:58
=== JanC_ is now known as JanC
cachiojdstrand, hey, do you know if there is any way to delete an extrauser in ubuntu core?22:01
jdstrandcachio: iirc, deluser doesn't undestand --extrauser yet (this is a foundations thing)22:02
jdstrandcachio: you'd have to modify the files directly22:02
cachiojdstrand, you mean make the deletion manually22:02
cachio?22:02
jdstrandcachio: yes22:03
jdstrandcachio: in /var/lib/extrausers/22:03
jdstrandcachio: I'm eow and need to step away, but I'll check backscroll if you have other questions22:05
cachiojdstrand, sure, thanks22:05
cachionice weekend22:05

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!