ograkyrofa, they go into edge daily and after manual testing into stable ... in the future we will have different builds for different channels, today edge is the same as stable, just untested00:27
mupPR snapcraft#757 opened: Export important project variables <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/757>01:05
sergiusenskyrofa https://github.com/snapcore/snapcraft/pull/757 tell me what you think01:52
mupPR snapcraft#757: Export important project variables <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/757>01:52
sergiusenselopio ^01:52
=== JanC is now known as Guest36120
=== JanC_ is now known as JanC
liuxgelopio, ping02:15
liuxgpreviously, on 15.04 ubuntu core, I used the command "sudo snappy hw-assign piglow.sideload /dev/i2c-1" to assign the hw to access the i2c device. On the series 16, we need to use interface, how can I assign the hardware? thank02:17
liuxgdoes anyone know how to assign a hw on series 16? I used to do on 15.04 like "sudo snappy hw-assign piglow.sideload /dev/i2c-1". thanks02:21
kyrofaliuxg, no such capability exists right now. It will probably utilize hooks in some fashion, which also don't exist right now :)03:06
kyrofaliuxg, that said, you can access to some things via interfaces, as long as the paths don't change03:07
liuxgkyrofa, in that case, I cannot do anything for the moment. I want to get the piglow working. my app is running, but it does not access the hardwware.03:07
liuxgkyrofa, thanks for your reply on this.03:08
kyrofaliuxg, take a look here: https://github.com/snapcore/snapd/blob/master/docs/interfaces.md03:09
kyrofaDo any of those cover your use-case?03:09
liuxgkyrofa, for the i2c-1 device, it seems that it is not covered there. also for the current raspberry pi 2 device, the interfaces are http://paste.ubuntu.com/23087199/. previously, on 15.04, it seems to be more dynamic. as long as the device is available, we can always do the assignment.03:12
kyrofaliuxg, yeah, we'll get there03:13
liuxgkyrofa, so, there will be a way to do that right? I think it should be generic instead of defining an interface for every device on the system. For example, I want to make use of the camera, the camera is there, but we cannot forecast how many more devices are there. on the contrary, the one on 15.04 is more flexible, and the command works for all03:14
kyrofaliuxg, I can't speak for the overall design, but things will definitely get more flexible with hooks03:16
=== chihchun_afk is now known as chihchun
mupPR snapcraft#738 closed: nodjs, gulp plugins: use http_proxy to connect npm registry <Created by m-shibata> <Closed by m-shibata> <https://github.com/snapcore/snapcraft/pull/738>05:47
mupPR snapd#1753 opened: asserts: Add an account-key-request assertion <Created by cjwatson> <https://github.com/snapcore/snapd/pull/1753>06:51
mupPR snapd#1754 opened: tests: fix "tests/main/ack" to not break if asserts are alreay there <Created by mvo5> <https://github.com/snapcore/snapd/pull/1754>07:04
mupPR snapd#1754 closed: tests: fix "tests/main/ack" to not break if asserts are alreay there <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1754>07:34
=== ant_ is now known as Guest56195
mwhudsonmorning zyga08:56
mupPR snapd#1755 opened: tests: remove snap confine workaround <Created by mvo5> <https://github.com/snapcore/snapd/pull/1755>09:17
ograubuntu@dragonboard:~$ snap --version09:18
ograsnap    2.12+ppa199-109:18
ograsnapd   2.12+ppa199-109:18
ograseries  1609:18
ograubuntu  16.0409:18
ogramvo, ^^^^ is that right ?09:19
ogra(i see 2.13+ppa206-1 on rpi)09:19
zygamwhudson: good morning09:22
zygamwhudson: I'm working on the namespace sharing feature in snap-confine09:22
zygamwhudson: interested in reviewing the idea?09:22
mvoogra: looks wrong, we should be on snapd 2.1309:22
mvoogra: I can have a look in a bit to ensure we really have 2.13 (or 2.13+something)09:23
mvoogra: did the /etc/systemd/system.conf.d dir make it?09:23
ograwell, i just did an ubuntu-core rebuild since i thought it was a glitch in the edge PPA ...09:23
ograyeah, the dirs are in09:23
ogra("user" too)09:23
mvoogra: yay!09:24
mvoogra: thanks a bunch, plano people will love you for this09:25
ogramvo, there you go https://launchpad.net/~snappy-dev/+archive/ubuntu/edge/+packages?field.name_filter=&field.status_filter=published&field.series_filter=xenial09:25
ogradoesnt build for all arches09:25
ogra(only amd64, armhf and i386)09:25
mvoogra: oh, meh :(09:25
ogramvo, i changed the arch list for that PPA, but s390x is missing yet ... (i guess i need to ping the LP team)09:28
ogramvo, do you know how we can trigger a build ?09:28
mvoogra: cool, I think thats not too terrible09:28
ogramvo, oh, and btw, kernel snap builds work end to end too now, incvluding auto-upload and publishing (with a hacked snapcraft in the PPA though)09:30
newcomer25The whole Law is fulfilled in one statement: ‘You’ll love your neighbour as much as yourself’ - Galatians 5:1409:32
newcomer25God bless you all and have fun using snappy!09:32
ograwhat was that ?09:35
mupPR snapd#1756 opened: asserts: add some stricter checks around format <Created by pedronis> <https://github.com/snapcore/snapd/pull/1756>09:40
mvoogra: yay09:42
mupBug #1616833 opened: need new interface: time-hardware <snapd-interface> <Snappy:New> <https://launchpad.net/bugs/1616833>09:50
mupBug #1616834 opened: need new interface: time-adjust <snapd-interface> <Snappy:New> <https://launchpad.net/bugs/1616834>09:50
cpaelzeris there a "show me the generated apparmor and seccomp profile" shortcut - like being in tempfiles or even a command to show them?09:52
youminHi, I tried to disable getty on tty1 with: systemctl disable getty@tty1.service but it doesn't work, of course, previously I remounted filesystem on write mode. Ideas?10:04
youminsorry,  but is anybody there10:15
mupPR snapd#1755 closed: tests: remove snap confine workaround <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/1755>10:16
ograyoumin, only 290 people, why ?10:20
cpaelzeryoumin: sure there are, but most are busy hacking and only loock sometimes on chat :-)10:20
youminok, sorry... but I think I have a simple issue10:21
youminwhen I disable getty on tty1 and I restart the system my configuration is lost, and of course I remounted the root partition10:21
youminanybody has ideas about why?10:22
cpaelzeryoumin: I can only speak for myself that I don't know the answer - sorry - how is that snap related, do you do that from "iniside" your snap?10:22
youminyes, I'm using dell gateway with snap10:22
cpaelzerI'm afaraid you need to highlight a few more experienced users that can help or point you further - ogra zyga ^^ ?10:24
ogracpaelzer, no idea about that, i would have to dig deep into ancient code, the dell gateways still run 15.04 i think10:24
ograyoumin, you could try to manually depete /etc/systemd/system/getty.target.wants/getty@tty1.service10:26
youminorga: I did it, but I don't know why it appears again10:27
ograelopio, can you trigger a snapd build in the edge channel, we just noticed it never built for all arches, i cahcnged that but dont know how to triggera build for the missing ones10:35
philrocheI have created a snap for fswebcam (https://launchpad.net/ubuntu/+source/fswebcam) but it is a reserved name. I am not the project maintainer. Should I request the reserved name and transfer later if the maintainer wishes or use a new unique name like philroche-fswebcam?10:39
Son_Gokuzyga: ping10:45
mupPR snapd#1746 closed: many: have AuthContext expose device store-id, serial and serial-proof signing to the store <Critical> <Reviewed> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/1746>10:59
mupPR snapd#1756 closed: asserts: add some stricter checks around format <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/1756>11:00
zygaSon_Goku: hello11:04
zygaSon_Goku: I saw your review, thank you11:04
zygaSon_Goku: I will do an upstream release rather than to switch to a snapshot if I can avoid it11:04
Son_Gokuzyga, also how are the patches coming for moving /snap?11:09
zygaSon_Goku: yes, all done, I just need to merge them upstream11:09
Son_Gokuhit the green button already then :P11:10
zygaSon_Goku: then I'll combine them into one patch to ship before the next release11:10
zygaSon_Goku: we just released last night but not everthing landed yet11:10
=== hikiko is now known as hikiko|ln
zygaSon_Goku: my patches are just for tests, everything else shoud be easy11:10
zygaSon_Goku: I need to look at snap-confine next, that is still a TODO11:10
zygaSon_Goku: but today I need to finish one feature (small but important), so I'm looking at snap-confine 1.0.41 and snapd 2.14 as the fedora target :)11:11
=== chihchun is now known as chihchun_afk
cpaelzernotadeveloper: ho11:23
notadeveloperhi cpaelzer11:24
mupPR snapd#1743 closed: many: use make StripGlobalRootDir public <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/1743>11:39
mupPR snapd#1738 closed: tests: the stable ubuntu-core snap has snap run support now <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1738>11:43
mupPR snapd#1751 closed: tests: add workaround for u-d-f to unblock all-snap image tests <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1751>11:44
=== hikiko|ln is now known as hikiko
iceyI've uploaded a snap to myapps.developer.ubuntu.com (yesterday afternoon, 16 hours ago?) but can't snap install it yet; it's in devmode so I'm trying to install it with --beta but all I keep getting is snap not found12:15
=== plars_ is now known as plars
iceyhow does one add dependencies (curl) to a plugin?12:25
=== mup_ is now known as mup
mupPR snapd#1757 opened: asserts: authority-id and brand-id of serial must match <Created by pedronis> <https://github.com/snapcore/snapd/pull/1757>12:30
ograicey, are you installing with --beta or with --devmode ?12:36
iceyorga the snap is (I think) published on the beta channel12:36
ograso you need both then12:37
ogra(you pshould know which channel you published to though ... the UI shows it on myapps...)12:37
iceyok, it finds it now, but I get a 401 when downloading :)12:37
ograthat sounds like a bug ... is it actually published ?12:38
iceymyapps.delevelop.. says yes12:40
iceyogra: ^12:41
ograwhats the package name ?12:41
* ogra will try to confirm your error12:41
iceyogra:  rust-coreutils12:41
=== Tristit1a is now known as Tristitia
ograicey, looks fine to me http://paste.ubuntu.com/23088826/12:43
iceyogra: maybe I just tried too fast?12:43
ogra(apart from the fact thet the daemon cant start)12:43
iceyogra: shouldn't be a daemon :) I'm working through my first snap :)12:43
iceygah I stillg et a 40112:43
ograwell, the systemd units :)12:44
ograare you behind a proxy ?12:44
iceyogra: https://paste.ubuntu.com/23088828/12:44
iceyshouldn't be behind a proxy12:44
ograicey, hmm, are you logged in (note that i am not and used sudo)12:46
ograperhaps thats the deifference12:46
iceyI am logged in, and no sudo12:46
iceyso almost exactly different :-P12:46
iceylet me pop up a container12:46
ograwell, just use sudo12:47
ograi guess that simply overrides the liogin12:47
iceyseems happy when not logged in, as root12:49
ograso there is something with the login credentials then i guess12:50
ogranot sure whom you need to poke for this12:50
iceyogra: I'll just raise a bug :)12:51
morphisniemeyer: ping12:51
iceythat's why I'm snapping things anyway eh :)12:51
mvopitti: can you help with a netplan question? https://github.com/snapcore/snapd/pull/1731/files#diff-52d12b07d34f6f20ac6190c87c325f8eR52 is the config what we generate (mwhduson to be precise), I use that and boot the system but no eth0 is coming up, how can I debug this? I fixed the verison:2 line?12:55
mupPR snapd#1731: firstboot: generate netplan config rather than ifupdown <Blocked> <Created by mwhudson> <https://github.com/snapcore/snapd/pull/1731>12:55
pittimvo: I already replied to mwhudson about that12:58
mvopitti: oh, ok. where can I read that reply?12:58
pittioh, he fixed the bad "dhcp4:"12:58
pittimvo: oh, good point, that's another bug; "ethernets:" is on the same level as "version 2:"12:59
pittimvo: easiest to just run "netplan generate" in the system and walk through the error messages13:00
mvopitti: cool, thanks, that was all I needed13:00
mvopitti: test is running now and will drop me in a debug shell in a minute, will figure it out, thanks for your help13:00
mvopitti: yay, just the indent13:03
pittimvo: Yet Another Moaning Language :)13:04
ograswitch to ini :P13:04
mupPR snapd#1758 opened: Use netplan <Created by mvo5> <https://github.com/snapcore/snapd/pull/1758>13:04
pittiogra: and call them .network!13:05
zygajdstrand: hey13:06
zygajdstrand: around?13:06
zygatyhicks: or you? :)13:06
ogramvo, that snapd package in the image PPA seems to come from some autobuild, do you know why ?13:06
mupBug #1614177 changed: Can not connect cups-control interface  <snapd-interface> <Snappy:Invalid> <https://launchpad.net/bugs/1614177>13:07
ogramvo, that looks like dupplication since elopio  already builds it in the edge PPA13:07
jdstrandzyga: yes13:07
ograsergiusens, your link is 404 (from the mail you just sent)13:14
ograoh, because fo the spasec13:15
zygajdstrand: I'd like to discuss the namespace sharing thing13:15
ograhow crazy is that ....13:15
zygajdstrand: can we do it here on irc with you and gustavo?13:15
zygajdstrand: https://docs.google.com/document/d/13OoZKmVC-u3N-RskWTZeeZaO8Oz7N857bKnNA2RN-VQ/edit13:17
zygajdstrand: this is my idea of how we can do this13:17
jdstrandzyga: yes, but I think tyhicks will want to be present too. he comes online in ~45 minutes13:17
zygajdstrand: that's fine, we can postpone until he is around13:17
ograpitti, we have a bunch of boards with wlan only or with wlan and eth ... we dont ship NM on ubuntu-core. will netplan be able to handle that (we use wpa-supplicant via ifupdown there atm)13:18
mvopitti: could you please add http://paste.ubuntu.com/23088949/ to nplan? that would help snapd13:19
mvoogra: in a meeting right now, we can talk later13:19
pittiogra: not ATM, wlan/wwan was supposed to be handled by NM13:20
ograthats not really mebedded firendly13:20
ogra*embedded friendly13:21
ogra(where size matters a lot)13:21
morphisogra: we have a network-manager snap ready in the store you can just use for that13:21
ogramorphis, i dont want to use NM13:21
morphisand modem-manager as well13:21
pittiogra: well, these discussion results are never final -- we build netplan as we want/need it, so it's certainly worth to file a bug at least and I'll check with slangasek/rharper etc.13:21
morphisogra: what is wrong with it?13:21
ograand i guess 90% f the embedded devs that use core wont want to use NM either13:21
ogramorphis, overheard ...13:22
pittiI thought the general direction was "drop ifupdown"13:22
ogramorphis, you have a constantly running dbus service etc13:22
pittimvo: hm, shipping empty directories? I don't mind much, but how does that help OOI?13:22
ograram, and disk space might be very limited13:22
morphisogra: that is a froth and back discussion, but in the end you want something which does some more management than just a few shells cripts13:22
morphiseven on IoT devices13:23
mvopitti: its about the writable path handling, we can workaround this if you want (or if you don't want the empty dir)13:23
morphisNest is using connman for a very good reason on their devices13:23
pittiogra: if you only need a static configuration, it might just be enough to drive wpasupplicant, not necessarily ifupdown or NM, I figure?13:23
ogramorphis, well, adding wpa-ssid and wpa-psk to /e/n/i is enough mgmt for such devices usually13:23
pittiogra: i. e. some people actually do use networkd with wifi, it's just not very user friendly (no GUI etc.) -- but we don't care about that, and we don't have a gui with ifupdown either13:23
pittimvo: oh, I see13:23
mvopitti: for ubuntu-core we create a writable directory in the writable space and we need a mountpoint, this is why we need the dir, but I can workaround if needed13:24
ograpitti, well, it isnt static usually but dhcp ... but yeah, indeed ssid and psk need to be seeded13:24
mvopitti: one more hack in livecd-rootfs :)13:24
morphisogra: that still does the case where you want a lot more extended features13:24
* ogra cries a little reading mvo's last line 13:24
morphisogra: but I agree, its a per use case decision13:24
mvoogra: I cry a lot everytime I look at this code ;)13:24
pittiogra: sorry, I meant "static" in the sense of "fixed config files with fixed AP and password"13:24
ogramorphis, right, i think netplan should support the non-NM case for wlan too13:24
ograpitti, yeah13:25
mvoogra: any concerns about the netplan landing? I'm keen to get it in today13:25
pittidrwxr-xr-x root/root         0 2016-08-19 19:10 ./etc/netplan/13:25
ogramvo, not beyond ... "hey, i'm just trying to SRU livecd-rootfs" :)13:25
morphismvo, ogra, pitti: not sure, but did you do any testing with netplan and the nm snap to ensure both work fine together?13:25
ograand the patch will be gigantic, infinity will hate me forever13:26
pittimvo: https://git.launchpad.net/~netplan-developers/netplan/commit/?id=3ec75ae513:26
ogramorphis, not me13:26
pittimvo: but I can't upload it right now due to beta freeze13:26
mvopitti: \o/ - no worries13:26
ograpitti, we have our own archive ;)13:26
pittimvo, ogra: heh -- if you upload  it to that, please don't call it 0.10, but 0.9something13:27
ogra(and are focused on xenial ... landing yakkety later is always fine)13:27
pittinote that xenial's NM does NOT work with netplan13:27
ograpitti, x.y.z-0ubuntuX+ppaX13:28
ograis what we usually do13:28
pittithe package has Breaks: network-manager (<< 1.2.2-0ubuntu4~) for a good reason13:28
pittiso we need to backport a couple of fixes and adjustments for that13:28
ograi doubt we can easily SRU the new NM ?13:28
pittis_langasek mentioned yesterday that we want to do that13:28
pittioh, we can13:28
ograheh, k13:28
iceyany good documentation on the interfaces available to snaps, or ways to access more unrestricted things (without --devmode)?13:28
pittiit's nothing earthshattering, just a bug fix or two and adding support for /run/NetworkManager/ config files13:28
zygaicey: hey, you can look at docs/interfaces.md13:29
pittiogra: well, not really "P"rogramming, more like "P"aperwork :)13:29
zygaicey: you can request any interface, right now that will block you in the store for a manaul review if the interface is too "powerful:13:29
zygaicey: I believe soon we will also use assertions for that13:29
ograpitti, heh, yeah, i know what you mean ... tyring to SRUall of https://launchpad.net/~snappy-dev/+archive/ubuntu/image/+packages?field.name_filter=&field.status_filter=published&field.series_filter=xenial13:29
iceyzyga: the thing I'm trying to snap is the rust coreutils package, which ( I think) basically means it needs the world13:29
mupPR snapd#1750 closed: store: request device session macaroon from store <Critical> <Reviewed> <Created by matiasb> <Merged by matiasb> <https://github.com/snapcore/snapd/pull/1750>13:29
pittiogra: can you please file a wishlist bug about wifi support?13:30
pittithis hasn't come up so far13:30
zygaicey: world?13:30
zygaicey: what does it need13:30
ograpitti, netplan package or is there an upstream project ?13:30
pittiogra: nplan package is fine; https://bugs.launchpad.net/netplan also exists13:30
iceyzyga: look through the list of folders at https://github.com/uutils/coreutils/tree/master/src ; it's a cross platform implementation of all of those13:31
pittibut distro package is usually better, auto-closing of bugs and you knwo when it is really "in"13:31
iceycomplete filesystem access, for one13:31
ograpitti, uuuh ... there is a binary called netplan (from petter's "plan" package), did you know that ?13:33
pittiogra: I do, that's why the package is called "nplan" :(13:33
zygaicey: that can be done with a sufficiently strong interface13:34
pittilong discussion, executive decision etc. pp.13:34
zygaicey: but also, remember about the chroot13:34
pittiogra: in the end it doesn't matter that much as nplan is installed by default13:34
mupBug #1602845 changed: unity7 interface does not work with libnotify <snapd-interface> <Snappy:Fix Released by jdstrand> <https://launchpad.net/bugs/1602845>13:34
ograi just remember all the issues we have with the snappy mediaplayer :)13:34
iceyzyga: would it be possible for the command snapped to use something like $(pwd) as the run location? MOST of the coreutils act on either the specified location, or .13:34
zygaicey: http://www.zygoon.pl/2016/08/snap-execution-environment.html13:35
zygaicey: they all do13:35
zygaicey: but read that first please13:35
iceyzyga will do :)13:35
iceyI'm sure I'll be back in a bit :)13:35
zygaicey: one thing has changed since, we now chdir to /var/lib/snapd/void instead of refusing to run when we cannot preserve the working directory13:36
zygaicey: it's better in practice13:36
* zyga -> coffee break13:38
ograpitti, bug 161692813:39
mupBug #1616928: netplan should support managing wlan devices via wpasupplicant and ifupdown <nplan (Ubuntu):New> <https://launchpad.net/bugs/1616928>13:40
pittiogra: I suppose ifupdown is not actually a requirement (I'd really rather not have that), just "get my effing wifi working"13:40
ograpitti, yeah, just without any overhead13:40
josvazquestion on snap daemons, how do you stop a daemon:forking snap from the command line?13:41
ogra(if you have only 128MB ram you really dont want to have NM and dbus running all the time13:41
josvazuse the snap binary or systemd (I don't see my snap listed in services --all-status)13:41
pittiogra: yep, agreed; I'll have a look how this can be made to work13:41
pittilittle reason to have the ifupdown wrapper around it, it could just generate a wpasupplicant conf directly13:42
ograjosvaz, systemct ...13:42
ograthere used to be a "snap service" command, but that got dropped (i think it will return eventually, but is currently not there)13:43
iceythis doesn't even seem to be happy in devmode: http://pastebin.ubuntu.com/23089017/13:45
ckingcan somebody review my "sluice" snap, it's been pending since monday13:51
pittiogra: https://bbs.archlinux.org/viewtopic.php?id=178625 sounds promising -- apparently Arch has a wpasupplicant@<iface>.service which DTRT (we don't, but I can't imagine it is rocket science)13:59
pittiogra: essentially, we just need to start it once the interface comes up, which can be done with a relatively simple udev rule even13:59
pittiOdd_Bloke: so, this seems doable indeed13:59
pittiOdd_Bloke: sorry, meant ogra14:00
Odd_Blokepitti: :)14:00
pittiIRC <tab> clearly isn't clever enough -- what is all this talk about smart devices??14:00
sergiusensogra_ you can thank dekko from breaking urls ;-)14:01
=== al_ is now known as Guest37767
Guest37767I have a question regarding the connection of my snap to a USB flash drive. With the "strict confinement" option, using the plugs "home", I can't access to the usb flash drive. Is there an other interface to connect to the usb ports ?14:29
mupPR snapd#1731 closed: firstboot: generate netplan config rather than ifupdown <Created by mwhudson> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1731>14:31
mupPR snapd#1757 closed: asserts: authority-id and brand-id of serial must match <Created by pedronis> <Conflict> <https://github.com/snapcore/snapd/pull/1757>14:31
zygatyhicks, jdstrand: do you have a moment to discuss the ns sharing design14:33
jdstrandmhall119: hey, didrocks seems afk, is there someone who can look at https://github.com/ubuntu/snapcraft-desktop-helpers/pull/7 ?14:33
mupPR ubuntu/snapcraft-desktop-helpers#7: common/desktop-exports: don't dereference target symlink on upgrades <Created by jdstrand> <https://github.com/ubuntu/snapcraft-desktop-helpers/pull/7>14:33
tyhickszyga: yes, I'm reviewing the doc now14:34
jdstrandmhall119: feel free to direct me to whoever14:34
zygatyhicks: thank you, we don't have to have a hangout or anything, just give me feedback and suggestions please14:34
mhall119jdstrand: not sure I'm qualified to give a "looks good" on that, but your explanation of the issue and fix sounds reasonable14:35
niemeyerzyga: This is significantly more complex than what I hoped for14:38
niemeyercc jdstrand tyhicks14:38
zyganiemeyer: ideas welcome, this is the most basic version that lets us share the mount namespace IMHO14:39
jdstrandzyga: can you make that a numbered list so it is easier to speak to?14:40
zygayes, sure14:40
jdstrandso the gist of this is 4 and 614:41
jdstrand4 gets us what to give to 614:41
zygathe rest is just implementation detail, apart from the fork that is mandatory14:42
jdstrandand the rest is how to get there safely and cleanup14:42
zyga(because of how the mount namespace is diffrent from other namespaces, apparently)14:42
zyga(i.e. you cannot just bind mount it directly unlike the others)14:42
tyhickswill snapd know which snaps need to share namespaces?14:44
jdstrandso, 1 is about creating the mountpoint in a non-racy way. if I am in 1b, what is the next step?14:44
zygatyhicks: AFAIK the design is that all processes belonging to a given snap share a namespace, if desired this can be delegated to an interface later14:44
zygajdstrand: if you "lose" you spin lock on the files you'd open in 6 to become symlinks and then proceed14:45
zygajdstrand: we can switch from spinlock to anything that lets them coordinate14:45
jdstrandzyga: so, once symlink is there, go to step 614:46
jdstrand(might be nice to capture that)14:46
zygajdstrand: correct, assuming 3.8 or more recent kernel14:46
zygajdstrand: done14:46
jdstrandah, well, 3.8-- there are 3.4 kernels out there-- maybe call that out in a comment as something that should be changed for 3.4 or to add a patch to the list for 3.4 backports14:47
zygagood point14:47
zygajdstrand: hmm, which version of ubuntu had a 3.4 kernel? I'll use that for testing14:48
cpaelzerelopio: hi, just saw your feedback on PR 71614:48
jdstrandI suspect you have to unshare() in a forked process because this is after this process' unshare() and unshare() twice is not allowed14:48
cpaelzerelopio: what do you suggest with "waf part in the wiki instead of putting it in our integration test" ?14:49
cpaelzerelopio: I surely can add stuff to the wiki, but I don't get the "instead of integration test" part of it yet14:49
zygajdstrand: no, it is just because of how it doesn't work otherwise for the mount namespace, it you cannot bind mount /proc/self/ns/mnt unless under some extra conditions that are not captured by the manual page IMHO14:49
zygajdstrand: I found this by googling and experimenting,14:49
zygajdstrand: you have to be in another namespace14:49
zygajdstrand: to do the bind mount14:50
zygajdstrand: odd but ... well14:50
zygajdstrand: so the parent is in the vanilla namespace, the child sits in the new namespace(s) and the parent does the bind mount14:50
jdstrandzyga: precise has 3.2. not sure otoh what had 3.4-- I don't think anything in Ubuntu iirc. android bsps of course (eg, touch kernels)14:50
zygajdstrand: 3.2 is good14:50
zygajdstrand: the pivot point is 3.814:50
* zyga fetches precise14:51
mupPR snapd#1757 closed: asserts: authority-id and brand-id of serial must match <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/1757>14:51
jdstrandzyga: 2b should say 'waits to be killed in step 5'14:52
jdstrandI know I'm being pedantic, but trying to make sure we understand what each step is doing14:52
mhall119what does the new browser-support interface provide?14:52
jdstrandmhall119: it's in docs/interfaces.md: "Can access files and IPC needed by modern browsers. This interface is14:54
jdstrandintended to be used when using an embedded Chromium Content API or using the14:54
jdstrandsandboxes in major browsers from vendors like Google and Mozilla. The14:54
jdstrand``allow-sandbox`` attribute may be used to give the necessary access to use14:54
jdstrandthe browser's sandbox functionality."14:54
zygajdstrand: done14:54
zygajdstrand: I'm very grateful for this!14:55
jdstrandmhall119: basically, electron works without specifying allow-andbox and people like google and mozilla can use it with allow-sandbox: true for chrome and firefox respectively14:55
mhall119jdstrand: ah, ok14:55
zygajdstrand, tyhicks: if you don't mind I'd like to change the directory a little to .../$SNAP_NAME/mnt so that we can have .../$SNAP_NAME/mutex explicitly14:56
zygaand use openat() easily14:56
jdstrandzyga: super pedantic: 'snap-confine parent waits for the eventfd event created in step 2b'14:56
zygajdstrand: done14:56
jdstrandzyga: step 4: 'when the eventfd event is received, ...14:56
* zyga would like to have "anhor references" so that 2b can be auto-numerated 14:56
zygajdstrand: done, correct me if anything is wrong (I think you can also do suggestions in the doc)14:57
jdstrandzyga: so, if step 2 fails, a losing process in 1b will spin forever?14:59
zygajdstrand: yes15:00
zygajdstrand: hmm15:00
zygajdstrand: if only IPC was easy15:00
jdstrandwell, that's what reviews are for15:00
zygajdstrand: hmmm, maybe an IPC (dbus?) service for making namespaces?15:00
zygajdstrand: then everone just calls a method on the bus and gets an FD back15:01
zygajdstrand: or an error15:01
jdstrandI don't think we want dbus15:01
zygajdstrand: sockets are good too :)15:01
zygajdstrand: do we need that to stay reliable?15:01
jdstrandlet me rephrase15:01
tyhicksI'd rather not have the setuid root snap-confine get as complicated as talking over dbus15:02
jdstrandadding dbus as a requirement means that 14.04 cloud images will pull in dbus15:02
jdstrandand they'd probably prefer not to do that15:02
jdstrandplus that15:02
zygajdstrand: that's a fair point15:02
* zyga thinks15:02
lazyPowe_lool o/ hey there15:02
zygajdstrand: if 2 fails we could remove the mutex15:02
zygajdstrand: and fail in that process15:02
loollazyPowe_: Hi!15:02
zygajdstrand: and other processes could restart the attempt15:03
zygajdstrand: with inotify they could observe the directory15:03
zygajdstrand: to know mutex is gone (no spinlock)15:03
loollazyPowe_: the docker snap will likely not be sufficient for kubernetes15:03
loollazyPowe_: it's WIP at https://github.com/snapcore/snapd/pull/161915:03
mupPR snapd#1619: Add initial "docker" interface based on some of 15.04's privileges <Blocked> <Created by tianon> <https://github.com/snapcore/snapd/pull/1619>15:03
zygajdstrand: this could be done by snap-confine-ns, to have less stuff in snap-confine itself15:03
zygajdstrand: which could be confined very strictly to do that one thing (share or setup the ns)15:04
lazyPowe_lool - well, thats fine by me for now :) I was just noticing this is you https://github.com/lool15:04
elopiocpaelzer: hello. Have you seen https://wiki.ubuntu.com/snapcraft/parts ? You can put in there a part to be reused. I thought waf would be a good case for that.15:04
loollazyPowe_: it is me, what did I do again?15:04
looland before anyone ask, I certainly didn't reboot it15:04
elopioinstead of copying the waf source in your snap, you would use: after: [waf], and snapcraft will bring it from the wiki.15:04
jdstrandremoving the mutex and allowing losing process to try to win seems reasonable15:04
lazyPowe_lool - i found this https://github.com/infosiftr/snap-docker/tree/docker-interface15:05
zygatyhicks: how do you feel about the whole design?15:05
lazyPowe_is this the snap and code in reference on the list / snapcore/snapd15:05
elopioogra_: hey, answering the old ping. There is a button in launchpad called trigger build, do you mean that?15:06
tyhickszyga: well, I don't prefer snap-confine having to do all of this work15:06
loollazyPowe_: not sure what you mean with reference on the list / snapcore/snapd, but it's the only repo we use for docker snap; I believe master branch is the current series 16 one though15:06
lazyPowe_ok, i was looking for some prelim work. I'd like to help collab/contribute15:06
zygatyhicks: would you feel better if this was a separate executable?15:06
zygatyhicks: it would still be running as root (via snap-confine)15:06
ogra_elopio, i dont have it15:07
jdstrandzyga: perhaps: '2c. if 2, 2a or 2b fail, remove the mutex so losing processes in 1b can compete for 1a)15:07
tyhickszyga: I'm not against the design but it sure seems like it'd be nicer if snapd could prepopulate the namespace directories15:07
zygatyhicks: hmmm15:07
cpaelzerelopio: I've seen that in the past, but it appeared to me a bit too "unofficial" and since I want to get an external project to use snaps I'd prefer to have waf "properly" in snapcraft15:07
zygatyhicks: can we rely on this? snapd may not be up15:07
zygajdstrand: ^ ?15:07
lazyPowe_lool - i'm mostly interested in tracking the progress so I can maybe contribute whats needed to run k8s on top of a docker snap. Thanks for confirming that is the upstream15:08
cpaelzerelopio: I might not see the whole of it - could I use that mechanism to "just keep the integration test" in such a part, but let the rest be in "official" snapcraft?15:08
tyhickszyga: oh... if that's true, then we probably can't rely on it15:08
ogra_elopio, but it seems a new build is ongoing anyway now ... so no worries15:08
loollazyPowe_: did you start with a k8s snap already?15:08
zygatyhicks: I can move the code into any other process but it has to do the thing anyway, yes, we could pre-populate the namespaces a little but I suspect it's going to be more complex this way (what if the group allocation changes, etc)15:08
jdstrandtyhicks: doesn't the unshare() require root?15:09
loollazyPowe_: so status is that it's mostly done, but there is some pending feedback on the interface and final tweaks to make; waiting on the pull request to be unblocked15:09
jdstrandtyhicks: in 2a15:09
lazyPowe_lool - i've got the client snap completed, i'm now on to trying to stand up a stand-alone snap15:09
tyhicksjdstrand: yes, it does for certain namespaces15:09
tyhicksjdstrand: why do you ask?15:09
jdstrandtyhicks: I was trying to think through your suggestion of moving it somewhere else15:10
tyhicks(it definitely does for mount namespace)15:10
loollazyPowe_: cool; would be happy to hear news on progress of this effort, and perhaps even contribute if I find the time  :-)15:10
loollazyPowe_: how do you use k8s BTW?15:10
lazyPowe_lool - juju deploy kubernetes-core usually15:11
tyhicksjdstrand, zyga: I was just thinking that sorting out all of this lock contention stuff is a pain to get right and it'd be nice if something else had already populated the namespaces15:11
jdstrandI was thinking maybe snap run could do it, but then I said "no, it can't"15:11
loollazyPowe_: BTW one thing we have been debating is location of docker socket for the snap; ISTR k8s has two docker daemons; it would be interesting to hear if you run into issues with this and the snap15:11
tyhicksjdstrand, zyga: however, that'd have to be done in early boot15:11
jdstrandlets take a step way back15:11
zygatyhicks: whoever does it has to solve the same problem15:11
jdstrandthe snap can't run unless the squashfs is mounted15:11
jdstrandsnapd is mounting the snaps15:12
zygatyhicks: that cannot be done in early boot because groups are dynamic and will change as snaps are added or removed15:12
lazyPowe_lool - we would favor bins on disk over another engine bridge using the snap delivery method15:12
jdstrandafter it mounts the snaps, couldn't it create what is needed for snap-confine to setns into?15:12
zygajdstrand: that's not true, systemd does it15:12
zygajdstrand: even withou snadp running on the next boot15:12
lazyPowe_that primary bridge is used in 1 of 2 cases - to isolate the control plane, or to provide ancilliary components to the "workload" docker instance. Such as SDN through Flannel in a container.15:12
jdstrandthat's fine. a systemd unit could do it15:12
jdstrandI'm not saying it should. just talking here15:13
tyhickszyga: if a snap is installed, snapd could set up the namespaces before mounting the newly installed snap15:13
zygatyhicks: that's true15:13
zygatyhicks: snapd could manage all of this in /run/snapd/ns15:13
tyhickszyga: if a snap is uninstalled, and there are no more users of the $SNAP_NAME group identifier, then the namespaces can be torn down after the last snap in the $SNAP_NAME group is unmounted15:14
zygatyhicks: but we need something that pre-populates that after reboot15:14
elopioogra_: https://code.launchpad.net/~snappy-dev/+snap/ubuntu-core/+request-builds15:14
zygatyhicks: I like how this gives us a nice way to clean up, yes15:14
ogra_elopio, i developed that part :P i'm talking about https://launchpad.net/~snappy-dev/+archive/ubuntu/edge/+packages and the snapd package in there15:14
zygatyhicks: and a way to correctly depend on the thing that creates those namespaces to run before snap-confine15:15
ogra_elopio, (i do know how to trigger an ubuntu-core snap build :) )15:15
tyhickszyga: right - so then snap-confine just needs to look in /run/snapd/ns/$SNAP_NAME/* and start calling setns()15:15
elopiocpaelzer: the wiki is pretty official. You would keep the waf plugin in snapcraft, and a waf part in the wiki. The part will just contain the waf python files you are putting in the integration test.15:15
niemeyerzyga: Yes, I can surely have ideas.. I was hoping someone else would also have some of those so we could find something simple that works15:15
tyhickszyga: there's no need to worry about locking and coordinating with other processes15:15
jdstrandthe after reboot scenario could be handled by a systemd unit that runs before any of the snap mounts15:16
niemeyerzyga: Let's park that change until someone can have more ideas, please15:16
ogra_elopio, the prob was that the snapd package in the edge PPA was only built for x86 and armhf ... not for the other arches ... so they ended up with an old snapd15:16
tyhicksniemeyer: we're discussing another option right now15:16
jdstrandit just goes through all the installed snaps and sets up the namesapces. then snap install/remove handles while the system is running15:16
niemeyertyhicks: Nice, thanks!15:16
elopioogra_: :) now I understand you15:16
ogra_its all fine now15:17
elopioogra_: it has 6 architectures selected.15:17
ogra_(well, someone needs to request s390x for the edge PPA still )15:17
ogra_elopio, yes, i selected them today butt could not trigger a rebuild15:17
jdstrandso, one disadvantage of this is that you have namespaces setup with nothing going into them. this would only affect snaps with no daemons15:17
cpaelzerelopio: uh I see so it would only hold the extra stuff I've moved from the waf upstream into the integration test and that way "stay out of tree"15:18
jdstrandI'm not saying this is necessarily a problem, just that it should be called out15:18
elopioogra_: and how did you solve it? I see the build queue has only 2 archs.15:18
tyhicksjdstrand: yes, I don't like that aspect of it15:18
cpaelzerelopio: I guess the integration test then is the one using the after [waf] - yeah if that works I'm good15:18
zygajdstrand: yes, that's true, this brings me to my other point, if this was managed through interfaces then we could have more control over which processes share what15:18
cpaelzerelopio: I'm giving it a try til the next meeting starts15:18
zygajdstrand: and perhaps, no lurking namespaces that are never used15:18
zyga(well, never is inaccurate)15:18
elopiocpaelzer: yes, thanks.15:18
ogra_elopio, i didnt ... i enabled all the other arches i could (except for s390x for which we'll need domeone like cjwatson ) ... thats all ... now the daily build job seems to have kicked in15:18
tyhicksjdstrand: it parallels the fact that we have a ton of mounts set up that may not be in use but it is just adding to that problem...15:18
zygatyhicks: technically snapd reads the meta file from all the snaps almost all the time15:19
zygatyhicks: but I agree15:19
jdstrandzyga: well, niemeyer and I discussed the option of exposing this to the developer, but we felt this was a confusing choice of an implementation detail to have to deal with15:19
ogra_elopio, so the "i can not trigger a build" issue has resolved itself due to the daily job15:19
jdstrandtyhicks: that is an extremely fair point15:20
zygajdstrand: which developer? this would be an implementation detail in snapd interfaces, not something anyone can change willy nilly15:20
elopioogra_: but I think we are still missing something: https://launchpad.net/~snappy-dev/+archive/ubuntu/edge/+builds15:20
jdstrandtyhicks: this is a process though that needs to stick around, no?15:20
jdstrandzyga: but the developer has to know to opt into the interface15:20
cjwatsonogra_: https://answers.launchpad.net/launchpad for that kind of request15:20
zygajdstrand: ah, understood, yes15:20
jdstrandzyga: plus, this is trying to solve a devmode issue15:20
zygajdstrand: as a counter point, will we ever have to share the mount namespace across snaps for any reason?15:20
jdstrand(as well as strict)15:21
ogra_elopio, https://launchpad.net/~snappy-dev/+archive/ubuntu/edge/+packages i see armhf, arm64 and ppc64el binaries if i expand the snapd package ... and amd64/i386 waiting for a free buildd15:21
elopioogra_: oh, scratch that. It's because the others already build.15:21
tyhickszyga: does the process that created these namespaces have to stick around or can the namespaces persist without a process?15:21
jdstrandzyga: that would I think definitely need to be exposed in an interface15:21
ogra_cjwatson, thx15:21
zygatyhicks: well, they persist here15:21
jdstrandzyga: but there is no consensus on if we should support that15:21
zygatyhicks: through the bind mount15:21
zygatyhicks: (here the child that created the process dies before we setns)15:21
elopioogra_: great, you solved it and I just came late to make a mess. Please continue :)15:21
tyhicksjdstrand: so no process needs to stick around after 10:17 < elopio> ogra_: it has 6 architectures selected.15:22
jdstrandin fact, architects I've spoken to are leaning against sharing the mount namespace between snaps, even of the same publisher15:22
tyhickscopy and paste fail15:22
zygajdstrand: ack, then we can use systemd and other units15:22
zygajdstrand: hmm, will this be a problem for 14.04 support?15:22
elopioogra_: for the record, the way I trigger a build is to push to the ppa. You can do that manually triggering
* ogra_ feels honored, tyhicks picked my line for his paste error :D15:23
tyhicksjdstrand: no process needs to stick around after /run/snapd/ns/$SNAP_NAME.NS is created15:23
zygajdstrand: there are two actions that would have to happen if snap-confine just consumes pre-made namespaces15:23
zygajdstrand: snapd would have to run a tool/service that creates/remvoes them on demand on install/remove15:23
jdstrandoh, huh. they persist through the bind mount. that clarifies something with ip netns for me15:23
zygajdstrand: and the said tool would have to run with system startup before snapd itself is up15:23
zygajdstrand: or more accurately, before the .mount units are preocessed)15:23
ogra_elopio, aha, that was the button i was missing this morning ... noted for next time15:23
zygajdstrand: (this will be interesting when we have snap name renames15:24
zyga(perhaps it could be based on snap ids)15:24
zyga(but this is not a major point)15:25
jdstrandok, then tyhicks' point re this is inline with all our bind mounts is even more salient15:25
zygahmm, wait15:25
zygait cannot fully inline with our bind mounts15:25
zygabecause bind mount is just the persistence mechanism15:25
zygasetns is the actual thing, this would still be separate15:26
jdstrandthat's note really what I meant15:26
ogra_jdstrand, tyhicks zyga, i saw you guys talking about creating groups .... of thats user groups, please take into account that we have two group DBs when you design anything around it, one is readonly with static GIDs and the other is dynamic ... the static one might grow over time, so if you create dynamic groups, please leave a large enough gap15:26
jdstrandtyhicks was just saying having this extra thing laying around is not much different than having extra things hanging around elsewhere15:26
tyhicksogra_: we're talking about groups of kernel namespaces15:26
tyhicksogra_: that are shared among commands in snap15:27
ogra_tyhicks, that doesnt relate to userspace groups ?15:27
zygajdstrand: as in mounted snaps just being there?15:27
tyhicksogra_: nope15:27
ogra_(i,e /etc/group )15:27
ogra_then ignore me :)15:27
jdstrandzyga: that, but more everything snap-confine sets up that the snap may not strictly need15:27
tyhicksogra_: it was worth mentioning :)15:27
zygajdstrand: right15:27
zygajdstrand: so how can we simplify this15:27
ogra_yeah, i have a mental highlight on such stuff :)15:27
jdstrandall I was saying is that if there is no process sticking around, I find this more compelling and am less bothered by this thing that is there15:28
mupPR snapd#1759 opened: asserts: fix GPG key generation parameters <Created by cjwatson> <https://github.com/snapcore/snapd/pull/1759>15:28
jdstrandone could argue for the shared mount namespace pre-setup with the same logic as pre-mounting snaps15:29
jdstrandsnap-confine *could* do the mounts of snaps if they aren't already there, but it doesn't15:29
jdstrandzyga: I'm not sure it needs to be simplified15:29
qenghoSo, when do snaps refresh? My small experimental set suggests it's automatic on snappy images and manual on snappy-on-classic.15:30
zygajdstrand, tyhicks: have a look at the 2nd attempt below15:30
zygaqengho: look at the snapd.refresh.timer15:32
jdstrandzyga: in this manner, snap install doesn't have to do anything15:32
zygajdstrand: correct15:32
mupPR snapd#1760 opened: overlord/state: prevent change ready => unready <Created by niemeyer> <https://github.com/snapcore/snapd/pull/1760>15:32
zygajdstrand: can the mount unit describe post-unmount actions15:32
zygajdstrand: so that we can clean up those files?15:32
jdstrandmaybe. let me look15:32
tyhickszyga: hmm, I think there's still a race here :(15:33
tyhickszyga: so this solved the race problem of the namespace creation and other processes joining the newly created namespace15:34
jdstrand(not directly)15:34
tyhickszyga: but now we have to solve the problem of actually setting up the mounts in the namespace15:34
zygatyhicks: oh15:34
zygatyhicks: fair point15:34
zygatyhicks: actually, more complex15:34
zygatyhicks: it's not just a race15:34
zygatyhicks: it's a wtf do we do?15:34
zygatyhicks: because some things are common across snaps15:35
zygatyhicks: (and those should not be re-done)15:35
zygatyhicks: but some depend on interfaces15:35
tyhickszyga: I think this problem is present in both first and second attempt, right?15:35
zygatyhicks: so now one process can change behavior based on the interfaces of another process15:35
zygatyhicks: yes15:35
zygatyhicks: but it's a very serious problem15:35
zygatyhicks: (feature)15:35
* tyhicks thinks15:36
zygatyhicks: so, going back to snap-confine-does-all idea, this is easy to make race-free15:36
jdstrandcan one of you describe the problem with an example? (this may have already been considered)15:36
zygajdstrand: sure, two things start up, they have the same mount namespace and then start to apply all the mounts and bind mounts that snap-confine does15:37
zygajdstrand: so they cannot assume they start with a well-defined state15:37
zygajdstrand: so they probably don't do what people intended15:37
zygalet's get back to the original problem15:38
zygawhat was desired? so that two processes share the filesystem15:38
tyhicksonly one process should set up the bind mounts and others must wait before their snap command is started15:38
zygacan we unshare twice?15:38
zygaif we can setns() and then unshare()15:38
zygawe can do the rest with the fstab interface15:39
jdstrandright, so in the initial thoughts on this, it was 'if shared mount not there, set it up and do all the mounts, then pivot_root ; else, setns and pivot_root'15:39
zygajdstrand: except that the two processes may have different .fstab files15:39
tyhicksif they have different fstab files, they can't share the same mount namespace15:39
zygaor new conditions on the hostfs would result in different mounts (lxd quirk)15:39
tyhicksit is as simple as that15:39
zygawell, not entirely15:39
jdstrandzyga: wrt the content interface, we said it would necessarily have to be snap-global and that would be covered in documentation15:40
zygabut perhaps they can share a part they care about15:40
zygajdstrand: oh, we did? I wasn't aware of that15:40
jdstrandyes, it should be in the bug15:40
zygajdstrand: note that right now it is just the content interface but any future interface can use the mount backend15:40
jdstrandsure. I brought up content because we want to make sure we consider the future .fstab stuff15:41
jdstrandI think that .fstab ends up also being global, but I don't know everything we're thinking of putting there15:42
zygajdstrand: what if we did this, setns(), unshare(), process all the stuff15:42
zygawould that be sufficient for the network thing15:42
zygawith a shared subtree at the right spot, they would see what they want15:43
zygaand fstab is still per process15:43
zygamount namespace is not really fully 'unshared' because of shared subtrees and how that mixes everything up15:44
tyhickshow do you make sure that one snap's fstab doesn't stomp on the shared subtree with a mount that isn't in the other snap's fstab?15:45
zygatyhicks: you don't but we control the fstabs, it's about how we make the sharing sensible15:45
zygatyhicks: you can stump if that's the idea15:45
tyhickszyga: ok, so it is handled by interface code reviews15:46
tyhicksthat's acceptable15:46
tyhickspossibly error prone but still perfectly acceptable15:46
zygajdstrand: how do you feel about this?15:46
jdstrandzyga: note from 'man ip-netns': http://paste.ubuntu.com/23089359/15:46
* zyga reads15:46
jdstrandzyga: (that was in response to an earlier question)15:46
zygaby creating a mount namespace15:47
zyga       and bind mounting all of the per network namespace configure files into15:47
zyga       their traditional location in /etc15:47
zygajdstrand: thanks, I see15:48
zygajdstrand: so as long as we don't do funny stuff to /etc/netns or /etc, it would be OK15:48
zygajdstrand: (we do bind mount /etc from the host)15:48
zygajdstrand: but that mount won't be seen by the host (mount done by ip-netns)15:49
zygajdstrand: and thus won't be seen by separate processes ran by snap-confine15:49
zygajdstrand: so unless I'm mistaken, we have to share the actual namespace after it is initialized for this to work15:49
jdstrandwell, I want to be sure we  think about handling this for anything that might use a mount namespace. ip netns exec is just one thing15:49
zygajdstrand: agreed15:49
zygathe fstab handling could be split into global and per-process, the global one would be shared by the namespace sharing15:50
zygathe local one could do anything extra needed15:50
jdstrandok, so can someone clarify option #3 for me?15:50
zygaand the global one would have to be pre-made by the snap-namespace tool15:50
zygajdstrand: option #?15:51
* zyga is amazed that this all works in the kernel and it doesn't leak memory15:51
jdstrandit sounds like you and tyhicks came up with a different variation15:51
jdstrandcan you explain that variation?15:51
zygatyhicks: can you just write your idea down in the sname doc15:52
zygatyhicks: you can now edit15:52
zygajdstrand: this also gets tricky15:53
tyhickszyga: I didn't come up with an idea about how to handle the fstab processing race15:53
zygajdstrand: whenever .fstab changes we have to invalidate15:53
zygajdstrand: and more races show up15:53
argeshi. how long does the typical published snappy app take to show up via 'snap find' ?15:53
tyhicksarges: immediate in the snaps that I've published15:54
argestyhicks: that's what i've been told. Trying to determine if I screwed something up.15:54
zygaarges: snap find doesn't look at snaps in channels other than stable AFAIK15:54
argeszyga: ah. yea i published to edge.15:54
jdstrandarges: do you have a link to the page in the store and I can look15:55
jdstrandarges: if it fails automated review, then it won't publish15:55
jdstrandarges: and a human needs to look at it15:55
argesjdstrand: it says 'published' and passed the reviews, but it may be because its in edge15:55
argesbut no idea how to install an edge snap from the store15:56
tyhicksarges: snap install --edge SNAP15:56
argestyhicks: didn't work for me15:56
jdstrand--channel=edge ?15:56
argesjdstrand: nope15:56
arges: )15:56
arges$ sudo snap install --channel=edge crash-arges15:57
argeserror: cannot install "crash-arges": snap not found15:57
jdstrandarges: what is the name of the snap or the url in the store15:57
ogra_arges, confinement strict or devmode ?15:57
argesogra_: devmode15:57
ogra_then add --devmode to that line15:57
ogra_else it wont find it15:57
argesogra_: magic. it works15:57
jdstrandzyga, tyhicks: ok, I'm kinda confused where we are15:58
argesjdstrand: tyhicks ogra_ zyga thanks all15:58
zygajdstrand: I think I'm at the point where I see that it is more complex to correctly share the mount namespace (after it is configured)15:58
jdstrandwhat option are we talking about, what are we changing and why, how is it implemented?15:58
zygajdstrand: so the simplistic snap-namespace idea from "2nd attempt" part of the document is not sufficient15:58
jdstrandzyga: can you explain why given the understanding that things like 'content' are snap-global?15:59
zygajdstrand: because you have to start to invalidate those now as interface are changed15:59
jdstrandcan you give a concrete example?15:59
zygajdstrand: sure, we pre-share a namespace with (hypothetical) snap-namespace, and save the ns to a file as we were planning to, now processes are starting that are racing to open that file while you are racing to create a new namespace because of interface connection changes16:00
zyga(and replace the old one without stacking them forever, we have to unlink or unmount the old one)16:01
tyhicksso I understand the problem of racing on initial fstab processing but I don't know enough to reason about the interface connection changing problem16:03
jdstrandok. so a snap plugs the content interface. snap-namespace creates the shared mount. the use disconnects the content interface, we have to handle the namespace created by snap-namespace while snap.app2 may be accessing it16:03
sborovkovHi. Couple of questions - I noticed that snap login eventually expires. Is there recommended mechanism I am supposed to use to handle that? Also I have snap in edge channel - so I have to use snap --refresh --edge screenly - to update it - does that mean I should add cronjob to get new updates from store for it?16:03
jdstrandzyga: something like that ^16:04
zygajdstrand: actually I think the old namespace will run fine until the process quits, it is about /run/snapd/ns/foo/mnt that has to be unmounted / unlinked and re-created in a race-free way16:04
zygajdstrand: though nothing today protects us from concurrent interface reconfigurations and snap-confine reading those files so maybe that's not a new problem16:05
zygajdstrand: so my point is that the perceived simplification with out-of-bound setup is not really there16:06
zygajdstrand: because that tool has to solve the same problem16:06
zygajdstrand: and that tool has to process a large chunk of what snap-confine does now (set up all mounts)16:07
tyhicksit doesn't have to set up all the mounts16:07
jdstrandzyga: yeah. another option would be snapd would have to go in and setns() and umount16:07
jdstrandwhich also isn't easier16:07
tyhicksthere could be a simple lock file that all snap-confine processes take before setting up the mounts16:08
zygatyhicks: how much processing do you think is required there (in snap-namespace) given that snap-confine does pivot_root and a lot of mounts16:08
zygatyhicks: can you detail how you'd see the initially (shared) namspace and the per-snap-confine mount operations to happen16:09
zygatyhicks: what would each of those do?16:09
elopioping mwhudson: what are the plans for go 1.7? will it get to xenial? yakkety?16:10
tyhickszyga: well the locking problem is easy - have an advisory lock file that must be help before setting up the mounts16:10
tyhickszyga: what I don't have an answer to is how to different between different fstab files16:10
zygatyhicks: different fstab files can be ignored for now, how would the lock file help given the fact that we now start with a non-pristine mount envinronment?16:11
zygatyhicks: can you write down how that would work, I bet I'm missing something you are thinking about16:11
tyhicksyes, give me a minute to think through the details16:12
tyhickszyga: see the bottom of the dock16:17
zygatyhicks: so that would be all-in snap-confine?16:19
tyhickszyga: yes16:19
tyhicksheh... s/dock/doc/ all this container-like talk has docker in my head :)16:20
tyhickszyga: it works with either "1st attempt" or "2nd attempt"16:21
tyhicksagain, what it doesn't solve is differences in two fstab files16:21
zygatyhicks: yep16:22
zygatyhicks: that's fine16:22
zygatyhicks: I think this is doable, I'd deal away with the .complete file16:22
zygatyhicks: so that it just looks nicer in the FS16:22
jdstrandtyhicks: can you give a concrete example with two .fstab files? (I think this is covered by documenting these are snap-global)16:22
zygatyhicks: but that's a minor point (the actual namespace file can be the complete file_16:23
zygajdstrand: hmmm16:23
tyhickszyga: I think you need .complete but we can talk about that later16:23
zygatyhicks: one hole: the lxd quirk16:23
zygatyhicks: look at quirks.c please16:23
tyhicksjdstrand: I don't know enough about snap-global to give you an answer16:24
jdstrandtyhicks: you misunderstand16:24
jdstrandtyhicks: what I mean by 'snap global' is that you don't differentiate between commands in a snap. all the commands get the same set of mounts. so if one command plugs content (a consumer of .fstab), all commands gets content16:25
tyhicksjdstrand: nice, so that solves that problem16:25
jdstrandtyhicks: so all the mounts are global to the snap. we simply document that16:25
* tyhicks looks at quirks.c now16:25
zygatyhicks: this part specifically: https://github.com/snapcore/snap-confine/blob/master/src/quirks.c#L13816:26
zygatyhicks: if /var/lib/lxd didn't exist when we first start a process but gets created later, the mount namespace won't have that16:27
zygatyhicks: if the fstab profile changes, we also have to invalidate the mount namespace (I guess snapd can do that by unlinking the file)16:27
zygatyhicks: so we have to take that into account (the unlink) but I guess this is simple16:28
tyhickszyga: the mount namespace is shared so wouldn't future processes see the bind mounted /var/lib/lxd? (depending on mount propagation, of course)16:28
zygaif we can open() we win and we got a fd for setns16:28
zygatyhicks: no, because that if won't run initially16:28
tyhickszyga: why not?16:29
jdstrandtyhicks: I think zyga's point is that a snd app invocation skips step 516:29
zygatyhicks: because if is is not there initially (/var/lib/lxd) then nothing will create the bind mount later16:29
zygatyhicks: because in this design the .complete file says "the mount namespace is ready, just use it"16:30
jdstrandzyga: quirks could be handled as part of step 4-- it would just need to see if the quirked mount point is already mounted16:30
zygatyhicks: and the namespace that was initially created may have been done some before (or worse, after) the directory changed the state of its existence16:30
jdstrandwell, 4 and 616:31
zygajdstrand: 4 in the new design?16:31
jdstrandbut you get the idea16:31
zygajdstrand: hmm16:31
tyhicksman, I'm confused about the quirks problem16:31
* zyga doesn't get the idea16:31
zygalet me re-read16:31
jdstrandalways try to run the quirks code16:31
zygawould that be safe?16:31
jdstrandzyga: imagine app 1 starts and a quirk is present, it gets mounted16:31
zygawe'd stack the quirk mount16:31
jdstrandthat's easy16:31
jdstrandimagine app 1 starts and the quirk mount isn't present, ekip it16:32
tyhicks(if you two are close to identifying a solution for the quirks problem, it is probably better to work towards that instead of explaining the problem to me)16:32
jdstrandapp 2 starts and the quirk mount point is present but not mounted. mount it16:32
zygajdstrand: so the idea is that quirks have to be aware of this16:32
jdstrandI guess you can put it that way16:33
zygajdstrand: and do the right thing (whatever it is) in presence of the shared mount namespace16:33
zygajdstrand: e.g. it is not in /var/lib/lxd on the host, unmount it16:33
jdstrandie, decouple quirks from the shared mount16:33
zygajdstrand: and rmdir the thing16:33
zygajdstrand: that's more complex but doable16:33
zygajdstrand: but somewhat less nice because it would require code that runs very rarely and might be buggy16:34
jdstrandso long as the shared mount namespace is there, the quirks code can figure out something to do16:34
jdstrandwe can think through other options wrt that, but I think this keeps the thorniest part, the locking, simple16:34
zygajdstrand: I think we're back to the original plan with a few tweaks on locking but nothing major16:35
tsimonq2whoops sorry16:36
zygatyhicks, jdstrand: do you want me to prototype this?16:36
zygaor are we putting this back on the feature shelf16:37
jdstrandzyga: this is important16:37
jdstrandas evidenced by sabdfl's comments in the bug and to me16:38
zyganiemeyer: ^^16:38
jdstrandwe need to fix ip netns exec in devmode snaps. shared mounts is the path to do that16:38
zyganiemeyer: I'd like your ack to start working on this16:38
jdstrand(fyi, niemeyer is aware of the importance)16:38
niemeyerzyga: Ack on what?16:39
jdstrandbut I think what would benefit a conversation with niemeyer is a cleaned up proposal with the new locking16:39
jdstrand(not to mention, JamieBennett said this was prioritized)16:39
zyganiemeyer: to work on the snap-confine changes required to implement mount namespace sharing as described by the "3rd attempt" in the docs16:39
zygajdstrand: good point, let me do that16:39
zyganiemeyer: sorry to ask prematurely, I'll write a doc that describes what we discussed and how it would work16:40
zyganiemeyer: and aks you to review it then16:40
jdstrandzyga: also, why attempt #2 was rejected would be good16:40
niemeyerjdstrand: Yes, that'd be appreciated, thank you16:41
niemeyerzyga: Sounds good, thanks16:41
zygajdstrand: I think we rejected it because it'd effectivly do much of what snap-confine does, and would not win us anything; what do you think?16:42
zygaand it had more complex locking16:42
zygathouh 3rd attempt has yet to implement asynchronous invalidation done by snapd when interfaces are changed16:42
zygaok, I'll start writing something16:44
tyhickszyga: no matter what, a combination of (1 or 2) and 3 is needed16:45
zygatyhicks: yeah, I think we agree on how this must work16:47
zygatyhicks, jdstrand: thanks for your time16:47
zygaI'll write a new proposal and share it16:47
jdstrandzyga: one way to solve the async problem is for snap-confine to notice that if mnt.complete exists, see if anything is in the mount point. if nothing, tear it down and start anew. this has the advantage of not messing with running processes16:48
mhall119mvo: ping, can I set runtime envvars for a snap yet?16:48
jdstrandthat should probably be handled in a future commit16:48
zygajdstrand: yes, essentially either we reach .complete and see the mnt file (and by see I mean we opened both) or we tear-and-restart16:48
* jdstrand nods16:49
zygait's somewhat confusing in semantics as two processes can be in one snap and not share a namespace though16:49
zygathat is pretty annoying :/16:49
* zyga thinks if that means we're back to the drawing board16:49
jdstrandthis is precisely why for a system like snappy avoiding use of namespaces is a good thing. the mount one is arguably the easiest to deal with and look how hard it is! :)16:50
zyga1: a mount namespace that cannot be invalidated; 2: a set of mounts to process that can be safely undone; that would let us still share one namespace across fstab changes16:50
zygajdstrand: I fully agree16:50
mupPR snapd#1761 opened: integration-tests: remove them in favour of the spread tests <Created by mvo5> <https://github.com/snapcore/snapd/pull/1761>16:50
zygajdstrand: and I bet I still don't grok shared subtrees with all their subtle details correctly16:50
jdstrand(ie, being in teh global namespace and mediating through other means is is way simpler)16:50
jdstrandzyga: who does? :P16:50
zygajdstrand: don't you and tyhicks? :-)16:51
jdstrandI'll defer to tyhicks :)16:51
zygathe fact that you can bind mount *a symlink* over somewhere to share a namespace was my "o_O" moment of the day16:51
jdstrandI find myself always reminding myself with man pages, etc16:51
zygaor that you can bind mount over files to make symlinks16:51
zygathat's damn powerful16:51
zygaI'd love to see an atomic mount flag that unbinds anything present there16:52
zygatyhicks: is that just MS_REMOUNT?16:52
tyhickszyga: that would probably work but we'd have to test16:54
zygatyhicks: no worries, I'll explore this myself16:54
zygacool stuff :)16:54
mhall119jdstrand: I'm trying to snap qupzilla, a qtwebengine based browser, and I'm getting: http://paste.ubuntu.com/23089689/16:54
zygathis is why I love this work :)16:55
mhall119jdstrand: is that a problem with the browser-support sandboxing?16:55
mhall119http://paste.ubuntu.com/23089692/ is the snap.yaml, I wasn't entirely sure how to set allow-sandbox:true16:56
mvomhall119: almost, #1254  needs to land16:56
mhall119mvo: ack, how close is that?16:56
mvomhall119: it could land today, except there are test failures that need to be debugged16:57
mvomhall119: but days16:57
mvomhall119: not weeks like before, the big pre-requiste (new ubuntu-core) has landed16:57
jdstrandmhall119: use either the 'allow-sandbox' attribute or launch with --disable-setuid-sandbox17:00
mupPR snapd#1735 closed: tests: fixes to make the ubuntu-core-16 image usable with -keep/-reuse <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1735>17:00
jdstrandmhall119: note that 'allow-sandbox: true' is going to require manual approval and is only meant as transitional policy for official upstream like mozilla and google until they modify their sandboxes to work with snappy17:01
jdstrandmhall119: qtwebengine may have some other way to disable it. I don't know17:02
mhall119jdstrand: is my snap.yaml correct to set allow-sandbox: true?17:04
zygajdstrand: unrelted question, is the apparmor process label in any way related to cgroups?17:04
jdstrandmhall119: yes17:05
jdstrandmhall119: oh, your snap doesn't have the sandbox as setuid17:05
mhall119what does that mean?17:05
jdstrandmhall119: your only option is --disable-setuid-sandbox17:05
jdstrandmhall119: chromium uses a setuid sandbox to setup stuff17:06
jdstrandmhall119: snaps aren't allowed to ship setuid binaries17:06
mhall119wasn't this interface created to support chromium's use case?17:06
jdstrandmhall119: I'm sure there is a configuration option for qtwebengine to compile without it. electron does this for example17:07
jdstrandmhall119: the interface was created to support mozilla and google's official browsers with their privileged sandbox mode, and the chromium content api without the privileged sandbox mode17:07
jdstrandmhall119: you should update to not use the privileged sandbox mode17:08
jdstrandmhall119: this is a transitional interface to block these companies while they adjust their implementations to work with snappy17:08
jdstrandto unblock*17:09
jdstrandmhall119: just do like electron and it'll be fine17:09
mhall119jdstrand: where can I find how electron does it?17:09
jdstrandcompile it without the setuid sandbox17:09
jdstrandthat's all electron does17:10
jdstrandyou'll have to look at qupzilla's build options17:10
mupPR snapd#1762 opened: Spread cups control <Created by mvo5> <https://github.com/snapcore/snapd/pull/1762>17:10
mvoogra_: just fyi, I prepare new images currently - with the new netplan stuff and for the first time from the beta channel :)17:11
mhall119jdstrand: it does say "Running without the SUID sandbox!" in the output...so maybe it's something else?17:13
jdstrandmhall119: I thought you were asking about the setuid sandbox. what is your question?17:14
jdstrandfailed to execvp:17:15
mhall119jdstrand: trying to track down the error17:15
mhall119yeah, just found that it was a bad envvar value17:15
mhall119I have lots of other errors now, but at least that one is resolved :)17:16
mhall119thanks jdstrand17:16
jdstrandcool :)17:16
smoserhey, i have an snapcraft.yaml that is building a nodejs thing happily.17:33
smoserhowever, i'd like to add a symlink as part of that build.17:33
smoserwhat i need to do is just execute: ln -s azure-cli bin/azure17:34
zygajdstrand, tyhicks: can you please re-review the document I shared earlier17:39
mhall119smoser: I think you can create the symlink first, put it in the same directory as your snapcraft.yaml, and then use a copy plugin to put it where you want it17:39
smoserbut how do i "create the symlink first"17:39
mhall119with your command above17:39
zygajdstrand, tyhicks: I've switched the docs to comment mode, please feel free to comment or suggest changes17:40
zygawhen you ack on it I will share it with gustavo again17:40
tyhickszyga: I already left one comment17:40
* tyhicks reviews the rest17:40
smoserbut that breaks the idea that you just run 'snapcraft'17:41
cjwatsonogra_: you said "all arches" but you didn't list powerpc and that's not currently enabled; do you want that too?17:41
smoserand probably breaks anything that would do that for me in an automated fashion17:41
smoserbecause i then have to tell it "run 'ln' first"17:41
smoseror maybe i'm  missing something.17:42
zygatyhicks: thinking about it, we could keep the .lock file global, if there are more namespaces to share we'll just use one file to protect them all17:43
zygatyhicks: this feels better because we either use one set or anther set of namespaces, not some random collection from the first set and second set together17:43
zygatyhicks: I won't make the change back unless you say so though17:44
tyhickszyga: if we use a global lock file, how do we indicate that all namespaces are initialized?17:47
zygatyhicks: you can only look for them when they are initialized17:48
zygatyhicks: just set them up17:48
zygatyhicks: and then bind mount them17:49
zygatyhicks: not before17:49
zygatyhicks: you can set them up without that file being there17:49
zygatyhicks: the only thing that can happen is snapd unmounting them as we do17:49
zygatyhicks: but that's a failure case that brings us back to the "let's do everything separately and cache if I can with the lock held" problem17:49
tyhickszyga: ok, you can change it back to a global lock17:50
zygatyhicks: OK17:50
tyhickszyga: ack from me17:51
zygatyhicks: thank you!17:52
tyhickszyga: thank you!17:52
zygatyhicks: do you feel that we will support more namespaces as time progresses?17:54
zygatyhicks: (that we will unshare more?)17:54
tyhickszyga: I think it is something that we will need to be prepared to do17:54
zygajdstrand: given tyler's ack I'll share this with gustavo18:00
zyganiemeyer: please re-review if you can (same URL, also linked from bug repott)18:01
tyhickszyga: there's one thing that I just realized I'm not clear on: how does snap-confine know when to set up the shared namespace?18:02
zygatyhicks: when it cannot setns() one18:03
tyhickszyga: so it will do this routine for every snap that gets launched?18:04
tyhicksI guess Design Requirement #1 makes that clear18:05
tyhicksI have no problem with that18:05
tyhicksI just wasn't clear18:05
jdstrandzyga: sorry got pulled aside. couple of typo/clarifications in the doc. ack from me18:22
=== mup_ is now known as mup
blackboxsw hmm, is snappy-playpen supposed to be examples of best practices? Trying to run snapcraft v2.15.1 doesn't build  for multiple qt-based example snaps such as texworks, 2048, qownnotes, vlc etc. Snapcraft chokes on the after clause containing a shared remote part desktop/*  the slash causes processing to barf with \u29f8' in position 48: ordinal not in range(128)18:43
blackboxswit seems in some cases (like game-2048) I'm able to replace the nasty '/' with a hyphen because there are not desktop-qt5 and desktop-qt4 shared remote parts published at https://wiki.ubuntu.com/snapcraft/parts18:45
mupPR snapcraft#758 opened: Add an integration test for parts with filesets <Created by jocave> <https://github.com/snapcore/snapcraft/pull/758>18:45
qenghoblackboxsw: It's not Best, not necessarily. It lags behind snapcraft by a bit.18:45
blackboxswshall we push changes to snappy-playpen to resolve these build issues for the time being?18:46
qenghoblackboxsw: Yes. Or file bugs reports.18:46
wililupyQuestion: After I build my image and install it on my device, I run snap list and it doesn't show any snaps. Is this normal?18:46
blackboxswqengho, I've been watching https://bugs.launchpad.net/snapcraft/+bug/1607015 in hopes that it'll get addressed, but I'm not certain when that would be.18:47
mupBug #1607015: 'ascii' codec can't encode character '\u29f8' in position 19: ordinal not in range(128) <Snapcraft:Confirmed> <https://launchpad.net/bugs/1607015>18:47
qenghoblackboxsw: yep. Me either.18:47
qenghowililupy: I think you should see at least ubuntu-core package. :\18:49
wililupyubuntu@localhost:~$ snap list18:50
wililupyNo snaps are installed yet. Try 'snap install hello-world'.18:50
Pharaoh_Atemzyga: how are you progressing on the removal of /snap?18:51
=== mup_ is now known as mup
ogra_cjwatson, no, i was referring to the arches snappy supports, sorry ... only s390x19:12
qenghoblackboxsw: I don't know a lot here, or if this will help, but I think you should use parts as they're named in  https://parts.snapcraft.io/v1/parts.yaml19:15
blackboxsw+1 qengho. I think so too, I *think* we probably need to remove the unusable desktop/* parts though as it seems like they cannot be sourced as a "remote part" in the after clause of snapcraft.yaml. It seems the desktop/(qt4|qt5|gtk2|gtk3)  is replaced with a snapcraft parseable desktop-(qt4|qt5|gtk2|gtk3) etc.19:18
ogra_qengho, blackboxsw see bug 160701519:20
mupBug #1607015: 'ascii' codec can't encode character '\u29f8' in position 19: ordinal not in range(128) <Snapcraft:Confirmed> <https://launchpad.net/bugs/1607015>19:20
ogra_(thats the reason for the breakage)19:21
blackboxswogra_, I commented on that bug ;)19:21
ogra_ah, that was you :)19:21
blackboxsws/blackboxsw/Chad Smith/ :)19:21
ogra_well, the playpen guys are most active on gitter19:21
ogra_https://gitter.im/ubuntu/snappy-playpen to be precise19:22
blackboxswyeah I had filed the duplicate https://bugs.launchpad.net/snappy/+bug/161244119:22
mupBug #1612441: Cannot include wiki-defined part desktop/gtk2 in after clause <landscape> <Snappy:New> <https://launchpad.net/bugs/1612441>19:22
blackboxswthx for the pointer  ogra_19:22
josepht'/' is going to be deprecated in snapcraft 2.16.  The wiki has been updated with the '-' version of those parts as has the origin repo.19:26
mupPR snapd#1763 opened: many: clarify/tie down model assertion <Critical> <Created by pedronis> <https://github.com/snapcore/snapd/pull/1763>19:36
mupPR snapd#1760 closed: overlord/state: prevent change ready => unready <Created by niemeyer> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1760>19:53
mupPR snapd#1722 closed: many: support install and remove by revision <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/1722>20:04
naccdid anything change recently for local plugins?20:09
nacc(in 16.10's snapcraft, i guess)20:09
nacci keep getting 'unknown plugin: glide', even though i have parts/plugins/glide.py ?20:10
qenghonacc: Did it work before?20:16
naccqengho: similar syntax has worked before, yeah20:16
naccthe 'glide' plugin i have locally is a pretty trivial subclass of the go plugin20:17
qenghonacc: Try with "strace -e trace=file -f -o snapcraft.strace snapcraft". Then, "grep glide snapcraft.strace".20:17
mupPR snapd#1703 closed: tests: test all snap ubuntu core upgrade <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1703>20:20
naccqengho: hrm, i see it looking (stat'ing) parts/plugins, but not even trying to open said file20:20
qenghonacc: I remember that the plugins were supposed to start with "x-". Maybe that matters?20:20
naccqengho: just tried changing that locally, still no dice20:21
naccqengho: x-glide.py and x-glide in yaml20:21
qenghoEr, "glide" in yaml. "x-glide.py" on filesystem.20:21
naccqengho: it must be a search thing, as i'm using cleanbuild and it's not even kicking off the container, it would be nice to know what it's searching for20:21
naccqengho: oh really?20:21
nacclet me try that20:21
naccqengho: still says 'unknown plugin' :/20:22
naccqengho: ah but that did change the strace! :)20:23
qenghonacc: pastebin that grep.20:23
mupPR snapd#1761 closed: integration-tests: remove them in favour of the spread tests <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1761>20:24
naccqengho: http://paste.ubuntu.com/23090363/20:24
qenghostat but no open. Huh.20:25
naccyeah, weird20:25
qenghonacc: Now pastebin "20:29
qenghonacc: Now pastebin "grep plugins snapcraft.strace"20:30
naccqengho: bah, i figured it out20:31
naccqengho: it was a mistake in the import20:31
naccqengho: but since importerrors are suppressed...20:31
naccqengho: thanks for the help!20:31
qenghoAh hah.20:32
naccthis feels like a common thing (and python will raise a far more helpful ImportError than 'unknown plugin' :)20:33
qenghonacc: Yeah, maybe that ImportException suppression should check the stack depth. Mind filing a bug?20:33
naccqengho: yep, will do20:33
qenghonacc: Thank you.20:33
jcastrorcj: Hey I could only get your cloudprint snap to work when I installed it in devmode20:34
naccqengho: summarized at LP: #161705220:36
mupBug #1617052: snapcraft: do not suppress ImportErrors for top-level exceptions with local plugins <Snapcraft:New> <https://launchpad.net/bugs/1617052>20:36
jcastrorcj: nm, I didn't read your instructions in the yaml file20:37
mupPR snapd#1764 opened: Mvo's snap-download2++ <Created by chipaca> <https://github.com/snapcore/snapd/pull/1764>20:38
=== al_ is now known as Guest94467
Guest94467Hi ! I have a short question: Is it possible to access a mounted USB drive from a snap using a "strict" confinement ?20:43
rcjjcastro, good to hear that you got it working.  sorry I didn't see this earlier to help you out21:11
mupPR snapd#1724 closed: snap: add  `snap download` implementation <Created by mvo5> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/1724>21:23
mupPR snapd#1763 closed: many: clarify/tie down model assertion <Critical> <Created by pedronis> <Conflict> <https://github.com/snapcore/snapd/pull/1763>21:23
jhobbsi'm trying to package a snap made from two python2 parts, each of which includes some .so depenencies that are built during the packaging21:28
jhobbssome of the .so's are for the same packages and so are at the same path, but have some small differences in them, because they were built at different paths, and at different times maybe - non functional differences21:28
jhobbsI end up with an error like this "Parts 'tempest' and 'ceilometer' have the following file paths in common which have different contents:"21:29
jhobbsI would like to exclude those paths from one of the parts and keep it in the other - is filesets the right way to do that?21:29
kyrofajhobbs, yes, though the real keywords you're looking for are stage and/or snap (which can use filesets if you like, but don't require them)21:33
jhobbsah stage is doing it! yay!21:34
jhobbsthanks kyrofa21:34
kyrofajhobbs, sure thing!21:37
Guest94467To access to the USB ports from a snap (strict confinement), is there a way to create an interface (plug/slot) ? or something else ?21:43
mwhudsonelopio: it's in yakkety already, i should think about making it the default soon i guess21:59
mwhudsonelopio: not going to SRU it to xenial, you can add ppa:gophers/archive though21:59
elopiomwhudson: thanks! I wanted to make a snap that requires go1.7. snapcraft doesn't support PPAs yet, but today we were talking about adding build deps as parts instead.22:02
elopiomwhudson: would you be insterested in making parts for go?22:02
mwhudsonelopio: i guess so, i'm not very familiar with how that end of things works22:05
mwhudsoncan you just download the deb and unpack it with dpkg-deb? :)22:06
mwhudsonso i see a long conversation about netplan in the scrollback, i guess i should read it22:10
elopiomwhudson: we could, yes. That's the cool thing about the parts. We could have go1.7-from-deb, go1.7-from-archive, go1.7-build-from-source. If we do this nicely, then the part that depends on go could use them interchangeably.22:17
elopioit's late and I'm hungry. I'll bbs.22:18
cjwatsonogra_: ta22:41
wililupyHow can I verify snap env variables?23:11
wililupyI think my $SNAP_APP_PATH and $SNAP_APP_DATA_PATH are incorrect for my startup script.23:11
kyrofawililupy, those are 15.04 variables. Are you using 15.04?23:44
wililupykyrofa: no, 16.04. I changed them in my script to $SNAP and $SNAP_DATA23:50
wililupyre-compiling and building now....23:50
kyrofawililupy, yeah that's what you need23:58

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