[07:09] <dholbach> good morning
[07:17] <dholbach> salut davidcalle
[07:17] <dholbach> davidcalle, do you think we're all set with the doc?
[07:19] <didrocks> hey dholbach!
[07:19] <dholbach> salut didrocks
[07:19] <didrocks> davidcalle: dholbach: which doc are you working on?
[07:20] <dholbach> didrocks, one about snappy on classic
[07:20] <didrocks> ah, is there a getting started as well for it? :)
[07:43] <zyga> good morning
[07:43] <didrocks> good morning zyga!
[08:56] <davidcalle> dholbach: I think we are good for the examples, I'm a bit concerned about the security/confinement part
[08:57] <dholbach> I talked to Jamie a few weeks back and he said it'd be updated in due time
[08:57] <dholbach> maybe we should add a note saying that we are going to add a link to updated docs about security once they're available(?)
[09:02] <davidcalle> dholbach: I'm adding a comment about it right now
[09:06] <dholbach> thanks
[12:49] <noizer> Hi short question where can I see the errors of seccomp?
[12:51] <ogra_> syslog
[12:52] <noizer> thx
[13:39] <didrocks> jdstrand: hey, small questions about unconfined app
[13:40] <didrocks> jdstrand: I have an unconfined command which is doing terminal content recording
[13:40] <didrocks> I want to be able to launch other snap commands from
[13:40] <didrocks> but even unconfined, I'm getting when executing another one: aa_change_onexec failed with -1. errmsg: Permission denied
[13:43] <jdstrand> didrocks: you can't launch them from /snaps/bin, you have to launch them from /snaps/<snap>/...
[13:44] <jdstrand> launching apps from /snaps/bin won't work for a ton of reasons
[13:44] <ogra_> why would you define the path at all ?
[13:44] <jdstrand> he wants to launch other snap binaries
[13:45] <ogra_> oh, cheating oyu mean ?
[13:45] <jdstrand> yes
[13:45] <ogra_> heh, k
[13:45] <jdstrand> well, I assume that is what he meant. otherwise, there is perhaps a bug
[13:45] <jdstrand> didrocks: can you be more specific?
[13:46] <jdstrand> davidcalle, dholbach: fyi, the PRs for the new security interfaces are now all acked so hopefully they'll be merged soon
[13:47] <dholbach> jdstrand, awesome!
[13:47] <jdstrand> davidcalle, dholbach: when that happens, the docs can be updated
[13:47] <didrocks> jdstrand: basically, it's a snap to make demos and record talks
[13:47] <didrocks> so, recording the terminal output and show how confinment works
[13:47] <didrocks> and such
[13:47] <jdstrand> didrocks: no, I mean, what are you executing-- your own binaries or binaries from other snaps?
[13:47] <didrocks> my binary is executing a shell recording utility (unconfined)
[13:47] <didrocks> that way, I want to run other commands
[13:48] <didrocks> and record them
[13:48] <didrocks> (from other snaps)
[13:48] <didrocks> hence the unconfined profile
[13:48] <jdstrand> is your binary launching something from /snaps/bin?
[13:48] <didrocks> well, it's a shell, so yeah, I can run some to record how confinement works for other commands
[13:48] <jdstrand> right
[13:48] <jdstrand> that isn't going to work (see above)
[13:49] <didrocks> there isn't any way for making it work? like having a shell capability like this doesn't sound a very crazy requirement
[13:49] <jdstrand> no
[13:49] <didrocks> it's like if I wanted to record the screen and we can't on snappy then
[13:49] <jdstrand> you can record the screen
[13:50] <jdstrand> you just need to do it from within your snap
[13:50] <didrocks> yeah, but from this snap, I can't run a normal shell
[13:50] <jdstrand> the launcher is doing a ton of things
[13:50] <jdstrand> it isn't going to work
[13:50] <didrocks> and no plan to make this kind of use case working in the future?
[13:51] <jdstrand> no
[13:51] <jdstrand> /snaps/bin is not the interface for apps to launch other apps
[13:51] <didrocks> I don't hardcode /snaps/bin
[13:51] <didrocks> I just run $command
[13:51] <didrocks> which is in the PATH of the shell that is executed
[13:51] <jdstrand> it doesn't matter
[13:51] <didrocks> yeah
[13:51] <jdstrand> /snaps/bin is in your PATH so that is what you get
[13:51] <didrocks> but I mean, it's not like I was trying to do something funky there
[13:51] <jdstrand> you are
[13:52] <jdstrand> snaps are not allowed to launch other snap's binaries
[13:52] <didrocks> well, I have things in PATH I can't execute
[13:52] <didrocks> so we should remove it
[13:52] <didrocks> once we launch a command
[13:52] <jdstrand> there are lots of things in your PATH
[13:52] <jdstrand> eg, 'mount'
[13:52] <jdstrand> fsck
[13:52] <jdstrand> you can't run those either
[13:52] <didrocks> yeah, but it's telling permission error and I can run sudo to get access
[13:53] <didrocks> here, it's really you can't do it
[13:53] <didrocks> (in addition to that being a valid use case IMHO)
[13:53] <jdstrand> unconfined is going away anyway
[13:53] <jdstrand> it seems you are going to force me to tell you all the reasons why it won't work
[13:54] <didrocks> I think it has something to do with apparmor and switching profile
[13:54] <didrocks> like encapsulating a profile in a profile
[13:54] <jdstrand> even if that were fixed, there would be something else
[13:54] <jdstrand> there are like 20 things
[13:54] <jdstrand> I'm telling you-- you aren't the first person to try this :)
[13:54] <jdstrand> it is unsupported
[13:54] <didrocks> as I'm not the first person, I think there are valid use cases :)
[13:55] <didrocks> and if we tell snappy is the future of ubuntu, we should maybe think of a way of supporting this
[13:55] <jdstrand> it isn't a valid use case-- apps aren't supposed to be unconfined
[13:55] <didrocks> ok, how would you implement then a shell recorder
[13:55] <didrocks> where you can record what happens on a screen
[13:55] <didrocks> and then, show confinements of apps and such
[13:56] <jdstrand> I want to be clear. I am saying that launching things from /snaps/bin/... will not be supported because the launcher does way too much and things break in all kinds of ways if the launcher launches the launcher
[13:57] <jdstrand> there will be an interface available for people to use other snaps' bits
[13:57] <jdstrand> that interface just won't be via /snaps/bin (it can't be)
[13:57] <jdstrand> that interface is not defined atm
[13:57] <didrocks> that doesn't cover my use case though, right?
[13:57] <didrocks> like recording a talk
[13:57] <didrocks> and having people having access to the shell commands that were ran
[13:58] <jdstrand> I don't know what interfaces will be supported. I'm only saying that launching apps via /snaps/bin won't be. the future may have another mechanism
[13:58] <jdstrand> today, you can launch stuff from /snaps/<other snaps>/current/path/to/whatever
[13:58] <jdstrand> that isn't going to be confined though
[13:58] <didrocks> right, however, that is an implement detail
[13:59] <jdstrand> no it isn't
[13:59] <didrocks> and doesn't show up confinement as intended here
[13:59] <didrocks> (and confined by this snap confinement)
[13:59] <jdstrand> your use case is not currently supported, sorry
[14:00] <jdstrand> when the interfaces work is landed more fully, you can request a new interface to do what you want
[14:00] <didrocks> yeah, I just feel those is dismissed and not going to be supported, which worries me once we switch everything to snappy
[14:00] <jdstrand> and the snappy devs can discuss it
[14:00] <didrocks> so basically, that would be possible through an interface?
[14:00] <didrocks> (technically)
[14:00] <didrocks> sounds like a "superpower one"
[14:00] <jdstrand> no
[14:00] <jdstrand> I'm sorry, I have to go to a meeting
[14:01] <didrocks> "no" -> not possible? /me is puzzled
[14:01] <jdstrand> the way the launcher works, it cannot launch itself
[14:01] <jdstrand> you have a superpower one with unconfined, but the launcher will fail'
[14:01] <didrocks> sounds like I should bring this use case on the ML and see if something can be discussed/planned
[14:01] <jdstrand> snaps driving other snaps is what you want
[14:01] <didrocks> yeah
[14:02] <didrocks> a "shell" interface basically
[14:02] <jdstrand> and that isn't supported in the manner you are trying to implement
[14:02] <jdstrand> don't go to the mailing list yet
[14:02] <jdstrand> let the interfaces stuff all land and then discuss
[14:02] <jdstrand> if you bring it up now no one will be able to do anything about it
[14:03] <jdstrand> what you are asking for is weird though
[14:03] <didrocks> ok, I'll be patient. Quite frustrating though that my first demo snap for developers were already this vlc bug/systemd/snappy that we couln't debug
[14:03] <jdstrand> you are asking for a completely unconfined shell via a snap
[14:03] <didrocks> so I fallbacked to this (I need an demo without any hw and such)
[14:03] <jdstrand> why not just login since you have an unconfined shell?
[14:04] <didrocks> if you tell me how I can run that app directly installable for users on the system, yeah, I don't have any issue :)
[14:04] <jdstrand> what you can do is ship a snap (fine), then launch a script in /snaps/<your snap>/current/... directly via your login shell rather than via /snaps/bin
[14:04] <didrocks> or if we install by default screen recording capability in snappy
[14:05] <didrocks> yeah, sounds like a workaround though
[14:05] <jdstrand> dude :)
[14:05] <didrocks> I'm just coming up with a real snap app and trying to figure out how it can work on this world :)
[14:05] <jdstrand> I'm trying to tell you what you can do now and later you can request screen recording when people are ready to accept interface request
[14:05] <jdstrand> s
[14:06] <jdstrand> it isn't a real app snap
[14:06] <jdstrand> you are totally violating a basec tenant of snappy
[14:06] <didrocks> why, it's not? those kind of functionalities are valid and already running on ubuntu though?
[14:06] <jdstrand> you must be unconfined (strike 1) and you must launch arbitrary commands from other snaps (strike 2)
[14:06] <jdstrand> ubuntu core is not a replacement for classic ubuntu
[14:06] <jdstrand> it is a whole different thing
[14:07] <didrocks> when it's ubuntu personal, it's all snaps though
[14:07] <didrocks> from what I understood
[14:07] <jdstrand> and no snap is allowed to execute arbitrary other snaps :)
[14:07] <jdstrand> snaps are isolated
[14:07] <jdstrand> there will be controlled ways to provide other access
[14:08] <didrocks> but we let bash from the ubuntu core snap, doing it though :p
[14:08] <didrocks> as long as it's discussed and there is a plan, I'm fine
[14:09] <didrocks> jdstrand: thanks for answering (and confirming) the no support for now though :)
[14:39] <dduffey> Does someone have a Snappy 16.04 based image up and running and let me know what version of docker is included?
[14:41] <kgunn> dduffey: is xenial from mar 25 ok?
[14:41] <noizer> Is it possible to do some manual test into a snap?
[14:41] <kgunn> dduffey: ubuntu@localhost:~$ snap find docker
[14:41] <kgunn> Name             Version             Summary
[14:41] <kgunn> docker.canonical 1.6.2.005-16.04.1-1 Docker
[14:42] <dduffey> kgunn, yeah, thanks
[14:43] <noizer> So i can execute some things into my snap for some test. Because its very slow to rebuild it all the time
[14:46] <kgunn> noizer: i think the only way to do this now is something like....
[14:46] <kgunn> unsquashfs foo.snap
[14:46] <kgunn> cd squashfs-root
[14:46] <kgunn> snappy build
[14:46] <didrocks> jdstrand: so, I did try (full of hope ;)) /snaps/terminal-recorder-demo.sideload/current/record-terminal for instance, but then, whatever snap I'm running like (hello-world.echo), I'm getting a "failed to create user data directory. errmsg: Permission denied"
[14:47] <didrocks> jdstrand: any idea?
[14:47] <noizer> kgunn ok I will try it
[14:48] <joc_> kyrofa: i would like to discuss the python problems i was having a bit more, see if i can work out how to handle build-packages etc
[14:56] <didrocks> jdstrand: ah got it, snappy error message isn't accurate, but fixed it :)
[14:57] <jdstrand> that is a different bug. I imagine ~/snaps was created when running a command as root. there is an open bug on that
[15:04] <ZerownZ> yo''ll guys I have fear from you because you all are burro
[15:07] <didrocks> jdstrand: yep, that was it :)
[15:21] <morphis_> jdstrand: how far did you guys come with the new security/interfaces/plugs/ports/.. stuff?
[15:23] <mvip> didrocks yt?
[15:23] <jdstrand> morphis_: the move to replace old-security/caps are all in accepted PRs. they need to land and I was told today by mvo that the state engine changes need to land after that. I'm told in a few days
[15:23] <jdstrand> morphis_: in other words, sit tight still
[15:23] <morphis_> jdstrand: sounds good, so earlier next week it should be done?
[15:24] <jdstrand> I hope so. I'm not driving those landings, but that is my understanding
[15:33] <noizer> kgunn: Does it need to build?
[15:39] <kgunn> noizer: yes this is my understanding...i only knew of this b/c i had asked the same question... so that method is at least a little faster than building on a host then copying over
[15:46] <noizer> kgunn: How can i test it when i build it?
[15:50] <didrocks> mvip: in some meetings, mind talking tomorrow?
[15:55] <kgunn> noizer: not sure what you are trying to do, but you would make sure to stop your service, install your new one, start your service
[16:05] <elopio> good morning
[16:05] <elopio> fgimenez, sergiusens, kyrofa: I'm sorry I didn't make it to the standup.
[16:14] <sergiusens> elopio, you also didn't see I moved it really early today ;-)
[16:15] <sergiusens> elopio, it will happen in 2 hours approx
[16:15] <elopio> so I'm on time!
[16:55] <elopio> sergiusens: I need more details about that match check you want.
[16:55] <elopio> I do the unsquash when there is no snapcraft.yaml, so do you mean you want a new unit test for the case without an argument?
[17:00] <sergiusens> elopio, I'm going for the "else" part where you don't provide a SNAP_FILE
[17:00] <sergiusens> elopio, to make sure name, version matches that of what we want to upload
[17:16] <kyrofa> Hey sergiusens elopio
[17:23] <elopio> sergiusens: like this? https://paste.ubuntu.com/15561413/
[17:29] <sergiusens> elopio, yeah, without the typos ;-)
[17:29] <sergiusens> kyrofa, hello
[17:37] <elopio> taking out the typos is taking out the soul.
[17:43] <wililupy> question: If I have kernel modules source code, do I need to precompile them and then add them to my kernel-device-trees or can I have it compile during the snapping process?
[18:26] <elopio> pindonga: do you know if something changed on staging? I can't log in anymore:
[18:26] <elopio> https://paste.ubuntu.com/15561995/
[18:26] <elopio> oh, he's away. beuno ^
[18:26] <beuno> >> nessita
[18:27] <beuno> elopio, I've seen a bunch of issues with ssl certs on staging services today
[18:27] <beuno> verterok might also have a clue
[18:29] <verterok> o/
[18:29] <verterok> elopio: ssl cert expired, working on fixing it ATM
[18:29] <elopio> verterok: thank you!
[18:29] <elopio> sergiusens: kyrofa: vila: ^ that blocks our landings.
[18:29] <kyrofa> Uh oh
[18:30] <verterok> should be solved shortly
[18:30] <elopio> kyrofa: if we are in a hurry, we can land if the autopkgtest fail only on the login test. But I think we are not in a hurry.
[18:31] <kyrofa> elopio, nah, should be good as long as people are aware :)
[18:31] <nessita> otp but what verterok said
[18:33] <verterok> elopio: try now please
[18:34] <elopio> verterok: um, now it's messier: https://paste.ubuntu.com/15562052/
[18:35] <verterok> elopio: yeah 1'
[18:37] <verterok> fat fingers :P
[18:49] <verterok> elopio: ready, enjoy
[18:54] <elopio> verterok: great!
[19:48] <wililupy> If I want to add kernel modules to my kernel snap, how best do I do that?
[20:31] <josepht> sergiusens: is it possible to alter the PATH via snapcraft.yaml, for git the subcommands are in libexec/git-core.  Or should I be moving those binaries into the snap's path rather than trying to alter the path?
[20:32] <kyrofa> josepht, or write wrapper scripts
[20:33] <sergiusens> josepht, or use organize
[20:37] <josepht> sergiusens, kyrofa: thanks :)
[20:40] <josepht> it's nice that 'organize' works for directories too
[21:33] <kgunn> robert_ancell: hey, sorry to pester, i just know you'll know :)
[21:33] <kgunn> but if i've 2 of the same package installed
[21:33] <kgunn> and i wanna toggle to the other version, what do i do?
[21:33] <robert_ancell> kgunn, two versions of a snap?
[21:33] <kgunn> e.g. i manually installed a deb from mvo
[21:33] <kgunn> well...it's a deb
[21:33] <kgunn> ubunt-core-launcher
[21:34] <kgunn> robert_ancell: actually snaps i totally understand :)
[21:34] <kgunn> i figure there's some dpkg -something i can do
[21:34] <robert_ancell> kgunn, you can't have two versions of a .deb installed AFAIK - do the packages have different names?
[21:35] <robert_ancell> kgunn, oh, do you mean revert to the archive version?
[21:35] <kgunn> robert_ancell: yessir
[21:35] <kgunn> like so
[21:35] <robert_ancell> kgunn, you can do "apt install package=version" if you know the version from the archive
[21:35] <kgunn> ubuntu-core-launcher:
[21:35] <kgunn>   Installed: 1.0.23~mvo1
[21:35] <kgunn>   Candidate: 1.0.23~mvo1
[21:35] <kgunn>   Version table:
[21:35] <kgunn>  *** 1.0.23~mvo1 100
[21:35] <kgunn>         100 /var/lib/dpkg/status
[21:35] <kgunn>      1.0.22 500
[21:35] <kgunn>         500 http://us.archive.ubuntu.com/ubuntu xenial/main amd64 Packages
[21:35] <kgunn> ah
[21:35] <kgunn> thanks robert_ancell
[21:35] <robert_ancell> or if it's a PPA you want to remove, you use ppa-purge to do that automatically
[21:35] <kgunn> nope, not a ppa
[21:36] <kgunn> i just thot maybe apt might not be cool with it
[21:36] <kgunn> since i manually installed dpkg -i style
[21:36] <robert_ancell> I've been meaning to find a command to apt install package=version-in-archive becuase surely it must exist
[21:36] <robert_ancell> But it's normally easy enough to find the version you want
[23:09] <moul> farblue, I work at Scaleway, I'm also interested if someone here had success with snappy on Scaleway (arm or x86_64) so I can package an image for everyone