[06:54] good morning [07:25] hey pstolowski! I'm keen to land #3119 (once tests are green). I assume the API is alreaady agreed on with niemeyer? i.e. the high level part does not need review? [07:26] hey mvo [07:28] mvo, hey! thanks for looking at it. well, it was briefly discussed long time ago. I think niemeyer may still want to take one more look at it [07:29] hey jibel, how did testing snapd 2.23.6 go last week, I didn't hear anything back. [07:32] pstolowski: ok, then I will wait with the merge [07:32] hey zyga! [07:35] JamieBennett, we had some tests to re-run due to the issue with the kernel in candidate, but everything should be ok by now. I'm checking the results [07:45] hey mvo good morning :) now that we have the expect snap in the staging store i'm preparing a branch for enabling the tests that use it and were disabled for ubuntu-core systems, these are the initial results with some errors http://paste.ubuntu.com/24305344/ could you please take a look when you have a moment? [07:46] fgimenez: I think I have a branch like that ... [07:46] https://github.com/snapcore/snapd/pull/3063 [07:46] PR snapd#3063: tests: re-enable tests for /dev/pts on core [07:47] fgimenez: feel free to take it :) [07:49] zyga: thanks! in my case we actually install the expect snap, this is the current wip https://github.com/snapcore/snapd/compare/master...fgimenez:expect-snap?expand=1 [07:50] fgimenez: thanks, just looked over it and it looks like it needs more investigation. the expect output seems to be slightly different :/ ? [07:51] fgimenez: right, I my branch didn't have the expect snap [07:52] mvo: yep, in some cases it seems to wait for more input, looking into it right now, you can reproduce with "SPREAD_REMOTE_STORE=staging spread -v ..." [07:58] Son_Goku: great work on getting all the bodhi requests up for snapd! [07:58] zyga: you have some time testing snapd on fedora 24/25/26 in the next days? [07:59] Son_Goku, zyga: would like to send out a call-for-testing on forum.snapcraft.io soon, what do you guys think? [08:00] morphis: yes [08:00] great! [08:06] mvo: superlow priority but we are getting errors in the 2.21 -> edge reexec scenario about missing dependencies https://travis-ci.org/snapcore/spread-cron/builds/216619076#L376 in this case we get snapd from a ppa but i get the same error getting it from https://launchpad.net/ubuntu/+source/snapd/2.21, snap-confine and ubuntu-core-launcher are requested as dependencies of snapd at the same version of the latter (which doesn't exist for snap- [08:06] confine nor ubuntu-core-launcher) [08:09] fgimenez: oh, of course. we need to tweak our tests to install those two (snap-confine,ubuntu-core-launcher) when testing with older versions of snapd [08:09] mvo: can you tag https://github.com/snapcore/snapd/pull/3089 for inclusion in 2.24? [08:09] PR snapd#3089: interfaces: drop udev tagging from framebuffer interface [08:10] morphis: sure [08:10] mvo: and didn't know about exec.LookPath, nice one :-) [08:10] morphis: its very well hidden [08:10] yeah .. [08:11] morphis: like google golang find path will not find anything [08:11] mvo: ok, but the requested version, in the 2.21 case, is (= 2.21), where can we get that version of snap-confine? [08:11] mvo: yeah, did exactly that [08:11] fgimenez: where are we getting it currently from? its a ppa? [08:12] fgimenez: or do we build it? (pardon my ignorance here) [08:12] morphis, zyga: my reviews this morning were a bit over nitpicky, sorry for that, I guess I need to switch to a stronger type of tea or something :) [08:13] mvo: no problem, much appreciated :-) [08:16] mvo: np :) we are getting it from https://launchpad.net/~snappy-dev/+archive/ubuntu/snapd-2.21/+packages, i see the additional packages there, thanks! [08:42] mvo: thanks for the review, I'm still working on that code [08:42] mvo: trying to make cgo/go parts work nicely with testing [08:45] hmmm [08:46] mvo: do you have an idea why .a file is not made in $GOPATH/pkg/$arch/... if I "go build" something that uses cgo? [08:47] PR snapd#3089 closed: interfaces: drop udev tagging from framebuffer interface [08:48] go/cgo bridge has some rough edges :/ [08:51] mvo: I need to *not* run the bootstrap code for testing [08:51] mvo: but *do* run it in production [08:51] mvo: cgo cannot be used in tests [08:52] mvo: we cannot do anything in Go land to enable/disable the C code [08:52] mvo: I tried setting a flag to zero and hang the bootstrap code on that value being 1 [08:52] mvo: (so it would never run by default or in testing) [08:52] mvo: and then use a 2nd constructor, with higher priority, in the main code to actually set the flag to 1 [08:53] mvo: but whatever go does to link things it doesn't seem to allow any C symbols to be seen in other go packages [08:53] mvo: I'll try putting this all in one package next === JanC_ is now known as JanC [08:56] zyga: about the xauth thing, it would be the best if we loop through each xauth cookie in the file XAUTHORITY points [08:57] zyga: which would either require us to link against libx11 (not what we want) or to reimplement functions like XauReadAuth (https://www.x.org/archive/X11R6.7.0/doc/Xau.3.html) [08:57] morphis: hmm, lovely [08:58] morphis: let's start a thread about this [08:58] zyga: flatpak does a few more things and also ensures that the confined app only gets access to cookies for local X11 servers [08:58] morphis: my 0.02 is to implement this in go [08:58] zyga: yeah wnated to do this [08:58] morphis: and call a helper if needed [08:58] from snap-confine? [08:58] morphis: we can _maybe_ exec a helper in go [08:58] morphis: or do this in snap-run even [08:59] snap-run is before snap-confine in the chain, right? [08:59] morphis: we probably cannot fork too much from snap-confine in case that systemd expects a forking daemon [08:59] yes [08:59] morphis: I'd do it like this though: [08:59] morphis: think of snap-confine as one thing [08:59] morphis: and think about some parts that you can write in go [08:59] morphis: before/after the main low-level part [08:59] morphis: if we do it like this we may write a go program [09:00] morphis: that execs a helper in C [09:00] morphis: that helper execs the go program again (after setting a flag or something) [09:00] morphis: so you can do all go code [09:00] morphis: and a predictable system level code in the middle [09:00] so point is that we need to have a place we can share data through, do we have a dir which is available in the confinement and outside? [09:00] morphis: I think that is sufficient for snap-confine [09:00] morphis: yes, /run is one such place [09:00] morphis: we have /run/snapd/ns today [09:01] zyga: do we have a private dir in there? [09:01] ah [09:01] a per app dir? [09:01] morphis: does it have to be per app? [09:01] morphis: (it can be) [09:01] it has to [09:01] morphis: we can make a per-app file [09:01] morphis: and restrict it with apparmor [09:01] think about multi-user systems [09:02] then doing this inside snap-run sounds like a good idea [09:03] PR snapd#3121 closed: WIP: cmd/snap-confine: always pass xauth file through regardless where it is located [09:05] PR snapd#3125 opened: tests: download and install additional dependencies when using prepackaged snapd [09:05] mvo: ^ should fix the dependency problems in the 2.21 -> edge reexec scenario, thanks [09:05] morphis: aha [09:05] morphis: so it has to be in xdg somewhere [09:06] morphis: there's unfinished code that sets XDG_RUNTIME_DIR [09:06] morphis: I think it fits there [09:06] morphis: (mkdir the XDG_RUNTIME_DIR, somewhat tricky because part needs to run as root, part as user) [09:07] mvo: i've updated https://github.com/snapcore/snapd/pull/3105 to download the additional dependencies too (with this branch we don't need to maintain ppas for specific old versions), it works fine on local executions [09:07] PR snapd#3105: tests: download previous snapd package from published versions instead of specific PPA [09:07] zyga: who says the auth file needs to be in XDG_RUNTIME_DIR? [09:08] fgimenez: excellent, thank you. I have a look [09:09] zyga: thank for the update on the cgo stuff, this does indeed sound tricky :/ [09:12] zyga: who sets up /run/snapd/ns at the moment? [09:14] morphis: I think it makes sense as that is per user and ont in home [09:14] mvo: I have a hacky solution [09:14] mvo: just commiting now [09:14] morphis: only snap-confine [09:16] zyga: I think the copy needs to be more per instance [09:16] rather than per app [09:16] what if the XAUTHORITY file changes over time and a second instance of an app is started, then we would override that file in /run/snapd [09:17] so I think putting this into snap-confine makes most sense and then placing the content after parsing in the snap own /tmp [09:17] morphis: why per instance? [09:17] morphis: aha [09:17] morphis: we can overwrite the old value too [09:17] yes [09:17] morphis: (since apps probably just read it on startup) [09:18] morphis: if you do it per instance there's no easy way to clean up [09:18] if you do per instance you have it in /tmp [09:18] morphis: note that /tmp is per-snap, not per user or instance [09:18] ah [09:18] zyga: quick and dirty fix would be a bind-mind into /run/snapd [09:18] s/mind/mount/ [09:19] + setenv("XAUTHORITY", "/run/snapd/xauth.") [09:19] if we want parsing of that file + skipping cookies for remote X11 instances then we need more logic [09:19] morphis: wait, bind mount what into that? [09:20] morphis: I think bind mount of anything is tricky [09:20] whatever XAUTHORITY points to on /run/snapd/xauth. [09:20] morphis: I'm -1.5 on bind mount as that tends to make /home live forever and I'm not sure if systemd will untangle this [09:21] morphis: why does flatpak filter remote connections? [09:21] yeah .. that's why I said quick and dirty [09:21] zyga: to make the app local-bound [09:21] morphis: I'd rather just copy it to /run/user/$UID/snap.$SNAP_NAME/.Xauthority [09:22] hm [09:24] zyga: let me play with that and then start a discussion [09:24] morphis: sounds good, thank you [09:29] mvo: morphis: can you please have a 2nd look at https://github.com/snapcore/snapd/pull/3095/files [09:29] PR snapd#3095: cmd/snap-update-ns: add C preamble for setns [09:31] sure [09:31] offtopic: somewhate appropriate now that we are doing all the mount craze: https://lwn.net/Articles/718638/ -- I'm looking forward to see this evolve [09:32] pstolowski: hey, I think you need to merge master into: https://github.com/snapcore/snapd/pull/3119 [09:32] PR snapd#3119: interfaces: API additions for interface hooks [09:32] fgimenez: should I close https://github.com/snapcore/snapd/pull/3063 ? [09:32] PR snapd#3063: tests: re-enable tests for /dev/pts on core [09:33] zyga: yes please, we need to use the expect snap for that to work, it is covered in my branch [09:36] PR snapd#3123 closed: osutil: introducing GetenvInt64, like GetenvBool but Int64er [09:38] fgimenez: ok, thank you [09:39] PR snapd#3063 closed: tests: re-enable tests for /dev/pts on core [09:39] zyga: np thx :) [09:48] PR snapd#3087 opened: overlord/snapstate: introduce tasks for aliases v2 semantics with temporary names for now (aliases v2) [09:48] fgimenez: do you have any idea what is going on with the autopkgtest currently? looks like all are failing. do you know if anyone has looked into this yet? [09:48] zyga, indeed, will do in a moment, thanks [09:49] mvo: yes, we are building spread on each autopkgtest execution, and this started to fail on friday [09:49] fgimenez: oh, ok [09:49] mvo: i've proposed a branch for using spread from the snap, but this only works for amd64, no spread snap on i386 nor ppc [09:49] fgimenez: and I see there is a branch already [09:49] fgimenez: hrm, hrm, ok [09:49] yep [09:50] mvo: maybe there's a better approach of course, not sure of what is the root cause [09:51] mvo: fwiw it seems that if you try to build spread in an up to date xenial, the resulting binary is not able to ssh to the testbed [09:52] * zyga fires spread tests for snap-update-ns and takes a break [09:52] fgimenez: ta [09:53] Son_Goku: we have to fix all the rpmlint/rpmgrill errors, right? [09:53] fgimenez: I wonder if we can just mirror spread and lp build snaps - but we need gustavo to share the snap with us or ask him to setup the snap build recipe [09:54] mvo: hi, btw Gustavo has asked to turn them off (the autopkgtest) if we don't find a quick solution [10:02] pedronis: ok [10:23] pstolowski: can you review https://github.com/snapcore/snapd/pull/3095 again please [10:23] PR snapd#3095: cmd/snap-update-ns: add C preamble for setns [10:25] zyga, will do in a bit.. running to school in a moment [10:26] hah, I think I got the the bottom of EOFs in store/retries [10:26] zyga: https://forum.snapcraft.io/t/migrate-x11-authentication-cookies-into-snap-environment/116 [10:28] pstolowski: oh, what was it? [10:30] zyga, we get url.Error, need to convert into that an inspect its Err member [10:30] crazy [10:30] pstolowski: aha [10:31] pstolowski: well, I'm +100 on having sane downloads :) [10:31] the simple return err == io.ErrUnexpectedEOF || err == io.EOF check we have doesn't cut it [10:31] bbiab [10:32] whats the smallest sized snap ever? do snaps share installed libraries between packages? [10:35] hey there, I was wondering where is the best place to submit a (possible) bug in konversation snap package [10:36] nanodrone: smallest size is the size of snap/meta.yaml + empty application that may be a tiny elf file or a shell script saying "hi" [10:36] nanodrone, the smallest one is probably a few bytes [10:36] nanodrone: snaps don't share anything unless that is designed by snap author [10:36] well [10:36] they all use libc and some basics from the core snap [10:37] clobrano: I think you can to that on the forum, using the "snap" category: https://forum.snapcraft.io/t/about-the-snap-category/55/2 [10:37] but they can cut down on their size if needed? [10:37] but usually snap dont chare anything among each other ... that would break the security model ... you *can* make them share bits on purposes though [10:37] ogra: iff they want to :) [10:37] i dont understand the security part... :( [10:37] nanodrone: note that you may be limited by the size of an empty squashfs file :) [10:38] nanodrone, a snap can only see its own parts of the system [10:38] nanodrone: I can explain that if you want to [10:38] nanodrone, there is a mechanism called interfaces that allows to extend this [10:38] nanodrone, one of these interfaces is the content interface ... that would for example allow you to have a shared library snap that your apps can make use of [10:38] please do [10:39] zyga, thanks! [10:39] nanodrone: snapd uses several kernel mechanisms to constrain what application code can do [10:39] nanodrone: we limit the system calls you can use [10:39] nanodrone: we limit some of the arguments to some of the system calls [10:39] Son_Goku: I've snapd now building with relro, a bit hacky but works: https://paste.fedoraproject.org/paste/TcD8VNEWY~aV9-0eW~wUIF5M1UNdIGYhyRLivL9gydE= [10:39] nanodrone: and we limit the set of files you can read, write, map, lock, etc on [10:39] ppisati, soo ... no broccoli for me regarding bluetooth ... not even with your new kernel :( [10:39] nanodrone: we also limit the IPC between all the apps and the rest of the system [10:40] nanodrone: so by default every application gets a sane set of rules that define the sandbox [10:40] that sounds nice. can i package a node app using snap [10:40] nanodrone: if the app tries to use more it either gets an error or gets killed (depending on some technical details) [10:40] nanodrone: yes [10:40] nanodrone: the system of "interfaces" is how we model extensions to the default sanbox [10:41] nanodrone, if you want to dig really deep into the security models ... https://developer.ubuntu.com/en/snappy/guides/security-whitepaper/ has all the dirty details ;) [10:41] nanodrone: you can say that your application needs to talk to the network by adding a "network" plug in your applicatoin [10:41] nanodrone: interfaces work in pairs "plug" wants to consume something that a "slot" provides [10:41] how do i update the snap... [10:41] nanodrone: only when a plug is connected to a slot is the actual permission granted [10:42] nanodrone: once connected (some are auto connected, some need to be connected by the user) your app can just access more of the system [10:42] also, do i have to publish the snap somewhere or can i distribute it offline [10:42] nanodrone: that's the overview, let me know if you have any questions [10:42] nanodrone: you can publish your snap into the store, if you push more versions everyone will update automatically [10:43] nanodrone: you can use channels (stable, candiate, beta, edge) to publish multiple stability levels at the same time; everyone installs stable by default [10:43] nanodrone: if you publish your snap e.g. on a 3rd party web server anyone can download it and install locally [10:43] nanodrone: but that means there will be no updates [10:43] nanodrone: and that removes the possiblity of using some more privlieged interfaces [10:43] like? [10:44] nanodrone: in the store your snap can be free (gratis) or priced, so you can also sell it [10:44] and you can indeed also install local snaps during development ... [10:44] nanodrone: all that require an assertion (a signed document) saying that your snap can use a given privileged interface [10:44] i dont think i'll need too many privileges, just like internet/network access and filesystem access.. [10:44] nanodrone: some interfaces give a lot of power so we want to control who has access to them [10:44] nanodrone: "filesystem access" is very broad [10:45] nanodrone: each snap gets a portion of the filesystem it can access by default [10:45] i just need to write/read files from the app's own directory [10:45] nanodrone: that is placed inside each users home directory [10:45] nanodrone: that's allowed by default [10:45] yup that'll suffice [10:45] nanodrone: but you won't be able to read arbitrary user files this way [10:46] arbitrary user files? [10:46] you mean i'll be limited to my own files? [10:46] nanodrone: yes [10:47] that's ok i dont need that. [10:47] nanodrone: your application will not see any user files that don't belong to your snap [10:47] nanodrone: great, good luck :) [10:47] nanodrone: note that your snap will work on many distributions but you will most likely need to use ubuntu or debian to build it (for now, we're working on making this better) [10:47] but i can optionally access user files somehow? [10:47] nanodrone: if you use the home interface you can access certain files [10:48] all my "app users" have ubuntu. [10:48] nanodrone: we're looking at allowing file-picker like thing as well but that's not implemented [10:48] nanodrone: your app will also work on fedora, suse, debian and other distributions though, [10:48] nanodrone: and it will be visible in things like gnome-software there (if it is properly described in the desktop file) [10:48] mvo: btw. do we have milestones on launchpad for snapd releases? [10:48] morphis: nope [10:48] here's a scenario, like the user puts files in a user specified directory and the app can access just that directory. [10:48] morphis: we stopped using those [10:49] morphis: I think we could / should do that and mirror github milestones [10:49] nanodrone: yes [10:49] zyga: so how do we know when a bug is fixed / targetted to be fixed? [10:49] thats all i need. [10:49] nanodrone: yes, e.g. $HOME/snap/yoursnapame/common [10:49] morphis: I spoke with mvo about this but we don't usually say when it was fixed [10:49] network access plus file access like that. i can't think of anything else. [10:49] morphis: I'd love to have those milestones [10:50] can i still show my app's indicator or menu entries in the sound/messaging menu + notifications? [10:50] nanodrone: note that if you upload your snap to the store it will be far easier to install [10:50] zyga: yeah .. [10:50] nanodrone: we have mpris interface for that [10:50] nanodrone: notifications are probably handled by the unity interface [10:50] nanodrone: give that a try [10:50] it's using notify osd for basic notifications for now. [10:50] nanodrone: in your app you can say: plugs: [network, unity7] [10:51] nanodrone: for mpris there's a more interesting example to look at AFAIR [10:51] nanodrone: i think `vlc' snap uses it [10:51] is snap = ubuntu or is it available on arch and gentoo as well [10:52] nanodrone: it's available in many distributions, have a look at https://github.com/snapcore/snapd/wiki/Distributions [10:52] morphis: ^^ that is out of date [10:52] nanodrone: fedora and opensuse are now supported [10:52] and should move to the forum :) [10:52] morphis: can you edit and fix that quickly [10:53] ogra: yeah, I think that's sensible as long as it is up-to-date [10:53] okay this is enough reading for me for today. i'll be back later ( i didn't think i'd get this quick an answer to all of my questions ) [10:53] putting #snappy on autojoin haha [10:53] zyga: Fedora rawhide is supported now, yes [10:53] yeah, it is more likely that it is kept up to date in the forum i guess :) [10:53] (more eyes) [10:53] nanodrone: good luck :) [10:53] thanks everyone. zyga ogra... [10:53] :) [10:54] truly grateful convert. [10:55] zyga: however supported == included in the distribution archive, isn't it? [11:01] zyga: https://bugs.launchpad.net/snapd/+bug/1657100 can be closed with the work Son_Goku did, right? [11:01] Bug #1657100: snapd needs a SELinux profile to run on Fedora [11:04] morphis: no, supported is something we just support [11:04] morphis: feel free to make that clearer [11:04] morphis: it's an arbitrary choice [11:05] morphis: (of words) [11:05] ok [11:06] something I need to work through, don't feel well maintain all these version numbers etc. on a wiki page [11:07] morphis: yes, I wanted a dynamically generated table but the wiki lets us start with something quickly [11:07] zyga: I think we need to drop the version numbers there alltogether at one point in the near future === hikiko is now known as hikiko|ln [11:42] mvo: can you re/review https://github.com/snapcore/snapd/pull/3114 please [11:42] PR snapd#3114: interfaces/mount: add function for saving fstab-like file [11:42] mvo: if you want I can make the extra rename [11:42] mvo: I'd like to propose more useful stuff on top [11:47] zyga: I would like the naming part for gustavo, I'm not great at names [11:51] mvo: ok, let's wait for a 2nd review for it [11:53] zyga: but I will go over it again [12:00] morphis: rpmgrill errors can be fixed later, some of them can be ignored too [12:04] PR snapd#3126 opened: store: handle EOF via url.Error check [12:04] mvo, this should be the final blow at EOFs, hopefully ^ [12:06] Chipaca: hey [12:06] Chipaca: do you know any snaps that use ubuntu-app-platform [12:06] Chipaca: I'm looking and snap-update-ns hand-testing [12:06] Son_Goku: ok, good to hear [12:06] zyga— I don't, but give me a mo' [12:06] pstolowski: very nice! [12:07] Chipaca: I'll write spread test based on the existing content stuff next but I want to have something at hand to play with [12:07] Chipaca: I don't know if there's a way to ask the store "what works with this snap" [12:07] Son_Goku: so anyone we need to fix before the first release? [12:07] I think I fixed all the things that were actually important, I think [12:08] morphis: \o/ [12:08] Son_Goku: nice! [12:08] * Fri Mar 31 2017 Neal Gompa - 2.23.6-2 [12:08] - Fix the overlapping file conflicts between snapd and snap-confine [12:08] - Rework package descriptions slightly [12:08] * Sat Apr 01 2017 Neal Gompa - 2.23.6-3 [12:08] - Fix profile.d generation so that vars aren't expanded in package build [12:08] Son_Goku: are you ok with me writing a call-for-testing on forum.snapcraft.io? [12:08] please do [12:08] I'm so tired... [12:09] get some sleep :-) [12:09] I spent literally all weekend hacking at this, because snapd is too complex for its own good... [12:10] Son_Goku: thank you! You made a lot of this happen! [12:10] Son_Goku: great work! [12:10] :/ [12:10] hmm [12:10] mvo: `- core:core-support [12:10] mvo: I didn't do anything [12:10] mvo: and it got disconnected [12:11] mvo: when core support is disconnected snapd is really wonky [12:11] mvo: like a "be broken" switch [12:11] zyga— lonewolf, neverbore, extia-webapp, mendiapp, facebook-webapp-mardy, chronoburn, soracom-console [12:11] zyga, morphis: there's still so much to go [12:11] zyga: core:core-support got disconnected? [12:11] mvo: yes [12:11] Chipaca: thanks!! [12:12] Son_Goku: yeah, one of the next major milestones after this one is that we get CI up and running for fedora so nothing breaks it [12:12] zyga: out of the blue? geh [12:12] snapd needs to properly support generating selinux policies at runtime for snaps... splitting base from core and being able to swap both of those is also missing [12:12] zyga: what if this happens in the wild? [12:12] mvo: not sure, I just noticed now [12:12] zyga— curl to get the raw yaml, python to filter [12:12] mvo: yeah [12:12] mvo: ensure connecting core:core-support? [12:12] and of course, nobody can create snaps on Fedora :( [12:12] Son_Goku: base/core will happen as we approach 18 [12:13] that's far too long from now [12:13] Son_Goku: and once we have that we may try fedora-based sonps [12:13] snaps [12:13] Son_Goku: there is a snapcrat snap already these days, something you can use [12:13] Son_Goku: not when 18 hits, I'm sure it will be started soon [12:13] zyga— more exactly, curl -H "Accept:application/hal+json" -H "X-Ubuntu-Wire-Protocol:1" "https://search.apps.ubuntu.com/api/v1/snaps/search?q=&fields=package_name,snap_yaml_raw" [12:13]