| zyga | good morning | 06:54 |
|---|---|---|
| mvo | 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:25 |
| zyga | hey mvo | 07:26 |
| pstolowski | 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:28 |
| JamieBennett | hey jibel, how did testing snapd 2.23.6 go last week, I didn't hear anything back. | 07:29 |
| mvo | pstolowski: ok, then I will wait with the merge | 07:32 |
| mvo | hey zyga! | 07:32 |
| jibel | 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:35 |
| fgimenez | 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:45 |
| zyga | fgimenez: I think I have a branch like that ... | 07:46 |
| zyga | https://github.com/snapcore/snapd/pull/3063 | 07:46 |
| mup | PR snapd#3063: tests: re-enable tests for /dev/pts on core <Created by zyga> <https://github.com/snapcore/snapd/pull/3063> | 07:46 |
| zyga | fgimenez: feel free to take it :) | 07:47 |
| fgimenez | 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:49 |
| mvo | fgimenez: thanks, just looked over it and it looks like it needs more investigation. the expect output seems to be slightly different :/ ? | 07:50 |
| zyga | fgimenez: right, I my branch didn't have the expect snap | 07:51 |
| fgimenez | 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:52 |
| morphis | Son_Goku: great work on getting all the bodhi requests up for snapd! | 07:58 |
| morphis | zyga: you have some time testing snapd on fedora 24/25/26 in the next days? | 07:58 |
| morphis | Son_Goku, zyga: would like to send out a call-for-testing on forum.snapcraft.io soon, what do you guys think? | 07:59 |
| zyga | morphis: yes | 08:00 |
| morphis | great! | 08:00 |
| fgimenez | 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 |
| fgimenez | confine nor ubuntu-core-launcher) | 08:06 |
| mvo | 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 |
| morphis | mvo: can you tag https://github.com/snapcore/snapd/pull/3089 for inclusion in 2.24? | 08:09 |
| mup | PR snapd#3089: interfaces: drop udev tagging from framebuffer interface <Created by chunsangjeong> <https://github.com/snapcore/snapd/pull/3089> | 08:09 |
| mvo | morphis: sure | 08:10 |
| morphis | mvo: and didn't know about exec.LookPath, nice one :-) | 08:10 |
| mvo | morphis: its very well hidden | 08:10 |
| morphis | yeah .. | 08:10 |
| mvo | morphis: like google golang find path will not find anything | 08:11 |
| fgimenez | 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 |
| morphis | mvo: yeah, did exactly that | 08:11 |
| mvo | fgimenez: where are we getting it currently from? its a ppa? | 08:11 |
| mvo | fgimenez: or do we build it? (pardon my ignorance here) | 08:12 |
| mvo | 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:12 |
| morphis | mvo: no problem, much appreciated :-) | 08:13 |
| fgimenez | 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:16 |
| zyga | mvo: thanks for the review, I'm still working on that code | 08:42 |
| zyga | mvo: trying to make cgo/go parts work nicely with testing | 08:42 |
| zyga | hmmm | 08:45 |
| zyga | 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:46 |
| mup | PR snapd#3089 closed: interfaces: drop udev tagging from framebuffer interface <Created by chunsangjeong> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3089> | 08:47 |
| zyga | go/cgo bridge has some rough edges :/ | 08:48 |
| zyga | mvo: I need to *not* run the bootstrap code for testing | 08:51 |
| zyga | mvo: but *do* run it in production | 08:51 |
| zyga | mvo: cgo cannot be used in tests | 08:51 |
| zyga | mvo: we cannot do anything in Go land to enable/disable the C code | 08:52 |
| zyga | mvo: I tried setting a flag to zero and hang the bootstrap code on that value being 1 | 08:52 |
| zyga | mvo: (so it would never run by default or in testing) | 08:52 |
| zyga | mvo: and then use a 2nd constructor, with higher priority, in the main code to actually set the flag to 1 | 08:52 |
| zyga | 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 |
| zyga | mvo: I'll try putting this all in one package next | 08:53 |
| === JanC_ is now known as JanC | ||
| morphis | zyga: about the xauth thing, it would be the best if we loop through each xauth cookie in the file XAUTHORITY points | 08:56 |
| morphis | 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 |
| zyga | morphis: hmm, lovely | 08:57 |
| zyga | morphis: let's start a thread about this | 08:58 |
| morphis | 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 |
| zyga | morphis: my 0.02 is to implement this in go | 08:58 |
| morphis | zyga: yeah wnated to do this | 08:58 |
| zyga | morphis: and call a helper if needed | 08:58 |
| morphis | from snap-confine? | 08:58 |
| zyga | morphis: we can _maybe_ exec a helper in go | 08:58 |
| zyga | morphis: or do this in snap-run even | 08:58 |
| morphis | snap-run is before snap-confine in the chain, right? | 08:59 |
| zyga | morphis: we probably cannot fork too much from snap-confine in case that systemd expects a forking daemon | 08:59 |
| zyga | yes | 08:59 |
| zyga | morphis: I'd do it like this though: | 08:59 |
| zyga | morphis: think of snap-confine as one thing | 08:59 |
| zyga | morphis: and think about some parts that you can write in go | 08:59 |
| zyga | morphis: before/after the main low-level part | 08:59 |
| zyga | morphis: if we do it like this we may write a go program | 08:59 |
| zyga | morphis: that execs a helper in C | 09:00 |
| zyga | morphis: that helper execs the go program again (after setting a flag or something) | 09:00 |
| zyga | morphis: so you can do all go code | 09:00 |
| zyga | morphis: and a predictable system level code in the middle | 09:00 |
| morphis | 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 |
| zyga | morphis: I think that is sufficient for snap-confine | 09:00 |
| zyga | morphis: yes, /run is one such place | 09:00 |
| zyga | morphis: we have /run/snapd/ns today | 09:00 |
| morphis | zyga: do we have a private dir in there? | 09:01 |
| morphis | ah | 09:01 |
| morphis | a per app dir? | 09:01 |
| zyga | morphis: does it have to be per app? | 09:01 |
| zyga | morphis: (it can be) | 09:01 |
| morphis | it has to | 09:01 |
| zyga | morphis: we can make a per-app file | 09:01 |
| zyga | morphis: and restrict it with apparmor | 09:01 |
| morphis | think about multi-user systems | 09:01 |
| morphis | then doing this inside snap-run sounds like a good idea | 09:02 |
| mup | PR snapd#3121 closed: WIP: cmd/snap-confine: always pass xauth file through regardless where it is located <Created by morphis> <Closed by morphis> <https://github.com/snapcore/snapd/pull/3121> | 09:03 |
| mup | PR snapd#3125 opened: tests: download and install additional dependencies when using prepackaged snapd <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3125> | 09:05 |
| fgimenez | mvo: ^ should fix the dependency problems in the 2.21 -> edge reexec scenario, thanks | 09:05 |
| zyga | morphis: aha | 09:05 |
| zyga | morphis: so it has to be in xdg somewhere | 09:05 |
| zyga | morphis: there's unfinished code that sets XDG_RUNTIME_DIR | 09:06 |
| zyga | morphis: I think it fits there | 09:06 |
| zyga | morphis: (mkdir the XDG_RUNTIME_DIR, somewhat tricky because part needs to run as root, part as user) | 09:06 |
| fgimenez | 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 |
| mup | PR snapd#3105: tests: download previous snapd package from published versions instead of specific PPA <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3105> | 09:07 |
| morphis | zyga: who says the auth file needs to be in XDG_RUNTIME_DIR? | 09:07 |
| mvo | fgimenez: excellent, thank you. I have a look | 09:08 |
| mvo | zyga: thank for the update on the cgo stuff, this does indeed sound tricky :/ | 09:09 |
| morphis | zyga: who sets up /run/snapd/ns at the moment? | 09:12 |
| zyga | morphis: I think it makes sense as that is per user and ont in home | 09:14 |
| zyga | mvo: I have a hacky solution | 09:14 |
| zyga | mvo: just commiting now | 09:14 |
| zyga | morphis: only snap-confine | 09:14 |
| morphis | zyga: I think the copy needs to be more per instance | 09:16 |
| morphis | rather than per app | 09:16 |
| morphis | 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:16 |
| morphis | 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 |
| zyga | morphis: why per instance? | 09:17 |
| zyga | morphis: aha | 09:17 |
| zyga | morphis: we can overwrite the old value too | 09:17 |
| morphis | yes | 09:17 |
| zyga | morphis: (since apps probably just read it on startup) | 09:17 |
| zyga | morphis: if you do it per instance there's no easy way to clean up | 09:18 |
| morphis | if you do per instance you have it in /tmp | 09:18 |
| zyga | morphis: note that /tmp is per-snap, not per user or instance | 09:18 |
| morphis | ah | 09:18 |
| morphis | zyga: quick and dirty fix would be a bind-mind into /run/snapd | 09:18 |
| morphis | s/mind/mount/ | 09:18 |
| morphis | + setenv("XAUTHORITY", "/run/snapd/xauth.<uid>") | 09:19 |
| morphis | if we want parsing of that file + skipping cookies for remote X11 instances then we need more logic | 09:19 |
| zyga | morphis: wait, bind mount what into that? | 09:19 |
| zyga | morphis: I think bind mount of anything is tricky | 09:20 |
| morphis | whatever XAUTHORITY points to on /run/snapd/xauth.<uid> | 09:20 |
| zyga | 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:20 |
| zyga | morphis: why does flatpak filter remote connections? | 09:21 |
| morphis | yeah .. that's why I said quick and dirty | 09:21 |
| morphis | zyga: to make the app local-bound | 09:21 |
| zyga | morphis: I'd rather just copy it to /run/user/$UID/snap.$SNAP_NAME/.Xauthority | 09:21 |
| morphis | hm | 09:22 |
| morphis | zyga: let me play with that and then start a discussion | 09:24 |
| zyga | morphis: sounds good, thank you | 09:24 |
| zyga | mvo: morphis: can you please have a 2nd look at https://github.com/snapcore/snapd/pull/3095/files | 09:29 |
| mup | PR snapd#3095: cmd/snap-update-ns: add C preamble for setns <Created by zyga> <https://github.com/snapcore/snapd/pull/3095> | 09:29 |
| morphis | sure | 09:31 |
| zyga | 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:31 |
| zyga | pstolowski: hey, I think you need to merge master into: https://github.com/snapcore/snapd/pull/3119 | 09:32 |
| mup | PR snapd#3119: interfaces: API additions for interface hooks <Created by stolowski> <https://github.com/snapcore/snapd/pull/3119> | 09:32 |
| zyga | fgimenez: should I close https://github.com/snapcore/snapd/pull/3063 ? | 09:32 |
| mup | PR snapd#3063: tests: re-enable tests for /dev/pts on core <Created by zyga> <https://github.com/snapcore/snapd/pull/3063> | 09:32 |
| fgimenez | zyga: yes please, we need to use the expect snap for that to work, it is covered in my branch | 09:33 |
| mup | PR snapd#3123 closed: osutil: introducing GetenvInt64, like GetenvBool but Int64er <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/3123> | 09:36 |
| zyga | fgimenez: ok, thank you | 09:38 |
| mup | PR snapd#3063 closed: tests: re-enable tests for /dev/pts on core <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/3063> | 09:39 |
| fgimenez | zyga: np thx :) | 09:39 |
| mup | PR snapd#3087 opened: overlord/snapstate: introduce tasks for aliases v2 semantics with temporary names for now (aliases v2) <Critical> <Created by pedronis> <https://github.com/snapcore/snapd/pull/3087> | 09:48 |
| mvo | 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 |
| pstolowski | zyga, indeed, will do in a moment, thanks | 09:48 |
| fgimenez | mvo: yes, we are building spread on each autopkgtest execution, and this started to fail on friday | 09:49 |
| mvo | fgimenez: oh, ok | 09:49 |
| fgimenez | 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 |
| mvo | fgimenez: and I see there is a branch already | 09:49 |
| mvo | fgimenez: hrm, hrm, ok | 09:49 |
| fgimenez | yep | 09:49 |
| fgimenez | mvo: maybe there's a better approach of course, not sure of what is the root cause | 09:50 |
| fgimenez | 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:51 |
| * zyga fires spread tests for snap-update-ns and takes a break | 09:52 | |
| mvo | fgimenez: ta | 09:52 |
| morphis | Son_Goku: we have to fix all the rpmlint/rpmgrill errors, right? | 09:53 |
| mvo | 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:53 |
| pedronis | mvo: hi, btw Gustavo has asked to turn them off (the autopkgtest) if we don't find a quick solution | 09:54 |
| mvo | pedronis: ok | 10:02 |
| zyga | pstolowski: can you review https://github.com/snapcore/snapd/pull/3095 again please | 10:23 |
| mup | PR snapd#3095: cmd/snap-update-ns: add C preamble for setns <Created by zyga> <https://github.com/snapcore/snapd/pull/3095> | 10:23 |
| pstolowski | zyga, will do in a bit.. running to school in a moment | 10:25 |
| pstolowski | hah, I think I got the the bottom of EOFs in store/retries | 10:26 |
| morphis | zyga: https://forum.snapcraft.io/t/migrate-x11-authentication-cookies-into-snap-environment/116 | 10:26 |
| zyga | pstolowski: oh, what was it? | 10:28 |
| pstolowski | zyga, we get url.Error, need to convert into that an inspect its Err member | 10:30 |
| pstolowski | crazy | 10:30 |
| zyga | pstolowski: aha | 10:30 |
| zyga | pstolowski: well, I'm +100 on having sane downloads :) | 10:31 |
| pstolowski | the simple return err == io.ErrUnexpectedEOF || err == io.EOF check we have doesn't cut it | 10:31 |
| pstolowski | bbiab | 10:31 |
| nanodrone | whats the smallest sized snap ever? do snaps share installed libraries between packages? | 10:32 |
| clobrano | hey there, I was wondering where is the best place to submit a (possible) bug in konversation snap package | 10:35 |
| zyga | 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 |
| ogra | nanodrone, the smallest one is probably a few bytes | 10:36 |
| zyga | nanodrone: snaps don't share anything unless that is designed by snap author | 10:36 |
| ogra | well | 10:36 |
| ogra | they all use libc and some basics from the core snap | 10:36 |
| zyga | 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 |
| nanodrone | but they can cut down on their size if needed? | 10:37 |
| ogra | 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 |
| zyga | ogra: iff they want to :) | 10:37 |
| nanodrone | i dont understand the security part... :( | 10:37 |
| zyga | nanodrone: note that you may be limited by the size of an empty squashfs file :) | 10:37 |
| ogra | nanodrone, a snap can only see its own parts of the system | 10:38 |
| zyga | nanodrone: I can explain that if you want to | 10:38 |
| ogra | nanodrone, there is a mechanism called interfaces that allows to extend this | 10:38 |
| ogra | 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 |
| nanodrone | please do | 10:38 |
| clobrano | zyga, thanks! | 10:39 |
| zyga | nanodrone: snapd uses several kernel mechanisms to constrain what application code can do | 10:39 |
| zyga | nanodrone: we limit the system calls you can use | 10:39 |
| zyga | nanodrone: we limit some of the arguments to some of the system calls | 10:39 |
| morphis | 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 |
| zyga | nanodrone: and we limit the set of files you can read, write, map, lock, etc on | 10:39 |
| ogra | ppisati, soo ... no broccoli for me regarding bluetooth ... not even with your new kernel :( | 10:39 |
| zyga | nanodrone: we also limit the IPC between all the apps and the rest of the system | 10:39 |
| zyga | nanodrone: so by default every application gets a sane set of rules that define the sandbox | 10:40 |
| nanodrone | that sounds nice. can i package a node app using snap | 10:40 |
| zyga | nanodrone: if the app tries to use more it either gets an error or gets killed (depending on some technical details) | 10:40 |
| zyga | nanodrone: yes | 10:40 |
| zyga | nanodrone: the system of "interfaces" is how we model extensions to the default sanbox | 10:40 |
| ogra | 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 |
| zyga | nanodrone: you can say that your application needs to talk to the network by adding a "network" plug in your applicatoin | 10:41 |
| zyga | nanodrone: interfaces work in pairs "plug" wants to consume something that a "slot" provides | 10:41 |
| nanodrone | how do i update the snap... | 10:41 |
| zyga | nanodrone: only when a plug is connected to a slot is the actual permission granted | 10:41 |
| zyga | 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 |
| nanodrone | also, do i have to publish the snap somewhere or can i distribute it offline | 10:42 |
| zyga | nanodrone: that's the overview, let me know if you have any questions | 10:42 |
| zyga | nanodrone: you can publish your snap into the store, if you push more versions everyone will update automatically | 10:42 |
| zyga | 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 |
| zyga | nanodrone: if you publish your snap e.g. on a 3rd party web server anyone can download it and install locally | 10:43 |
| zyga | nanodrone: but that means there will be no updates | 10:43 |
| zyga | nanodrone: and that removes the possiblity of using some more privlieged interfaces | 10:43 |
| nanodrone | like? | 10:43 |
| zyga | nanodrone: in the store your snap can be free (gratis) or priced, so you can also sell it | 10:44 |
| ogra | and you can indeed also install local snaps during development ... | 10:44 |
| zyga | nanodrone: all that require an assertion (a signed document) saying that your snap can use a given privileged interface | 10:44 |
| nanodrone | i dont think i'll need too many privileges, just like internet/network access and filesystem access.. | 10:44 |
| zyga | nanodrone: some interfaces give a lot of power so we want to control who has access to them | 10:44 |
| zyga | nanodrone: "filesystem access" is very broad | 10:44 |
| zyga | nanodrone: each snap gets a portion of the filesystem it can access by default | 10:45 |
| nanodrone | i just need to write/read files from the app's own directory | 10:45 |
| zyga | nanodrone: that is placed inside each users home directory | 10:45 |
| zyga | nanodrone: that's allowed by default | 10:45 |
| nanodrone | yup that'll suffice | 10:45 |
| zyga | nanodrone: but you won't be able to read arbitrary user files this way | 10:45 |
| nanodrone | arbitrary user files? | 10:46 |
| nanodrone | you mean i'll be limited to my own files? | 10:46 |
| zyga | nanodrone: yes | 10:46 |
| nanodrone | that's ok i dont need that. | 10:47 |
| zyga | nanodrone: your application will not see any user files that don't belong to your snap | 10:47 |
| zyga | nanodrone: great, good luck :) | 10:47 |
| zyga | 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 |
| nanodrone | but i can optionally access user files somehow? | 10:47 |
| zyga | nanodrone: if you use the home interface you can access certain files | 10:47 |
| nanodrone | all my "app users" have ubuntu. | 10:48 |
| zyga | nanodrone: we're looking at allowing file-picker like thing as well but that's not implemented | 10:48 |
| zyga | nanodrone: your app will also work on fedora, suse, debian and other distributions though, | 10:48 |
| zyga | nanodrone: and it will be visible in things like gnome-software there (if it is properly described in the desktop file) | 10:48 |
| morphis | mvo: btw. do we have milestones on launchpad for snapd releases? | 10:48 |
| zyga | morphis: nope | 10:48 |
| nanodrone | here's a scenario, like the user puts files in a user specified directory and the app can access just that directory. | 10:48 |
| zyga | morphis: we stopped using those | 10:48 |
| zyga | morphis: I think we could / should do that and mirror github milestones | 10:49 |
| zyga | nanodrone: yes | 10:49 |
| morphis | zyga: so how do we know when a bug is fixed / targetted to be fixed? | 10:49 |
| nanodrone | thats all i need. | 10:49 |
| zyga | nanodrone: yes, e.g. $HOME/snap/yoursnapame/common | 10:49 |
| zyga | morphis: I spoke with mvo about this but we don't usually say when it was fixed | 10:49 |
| nanodrone | network access plus file access like that. i can't think of anything else. | 10:49 |
| zyga | morphis: I'd love to have those milestones | 10:49 |
| nanodrone | can i still show my app's indicator or menu entries in the sound/messaging menu + notifications? | 10:50 |
| zyga | nanodrone: note that if you upload your snap to the store it will be far easier to install | 10:50 |
| morphis | zyga: yeah .. | 10:50 |
| zyga | nanodrone: we have mpris interface for that | 10:50 |
| zyga | nanodrone: notifications are probably handled by the unity interface | 10:50 |
| zyga | nanodrone: give that a try | 10:50 |
| nanodrone | it's using notify osd for basic notifications for now. | 10:50 |
| zyga | nanodrone: in your app you can say: plugs: [network, unity7] | 10:50 |
| zyga | nanodrone: for mpris there's a more interesting example to look at AFAIR | 10:51 |
| zyga | nanodrone: i think `vlc' snap uses it | 10:51 |
| nanodrone | is snap = ubuntu or is it available on arch and gentoo as well | 10:51 |
| zyga | nanodrone: it's available in many distributions, have a look at https://github.com/snapcore/snapd/wiki/Distributions | 10:52 |
| zyga | morphis: ^^ that is out of date | 10:52 |
| zyga | nanodrone: fedora and opensuse are now supported | 10:52 |
| ogra | and should move to the forum :) | 10:52 |
| zyga | morphis: can you edit and fix that quickly | 10:52 |
| zyga | ogra: yeah, I think that's sensible as long as it is up-to-date | 10:53 |
| nanodrone | 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 |
| nanodrone | putting #snappy on autojoin haha | 10:53 |
| morphis | zyga: Fedora rawhide is supported now, yes | 10:53 |
| ogra | yeah, it is more likely that it is kept up to date in the forum i guess :) | 10:53 |
| ogra | (more eyes) | 10:53 |
| zyga | nanodrone: good luck :) | 10:53 |
| nanodrone | thanks everyone. zyga ogra... | 10:53 |
| ogra | :) | 10:53 |
| nanodrone | truly grateful convert. | 10:54 |
| morphis | zyga: however supported == included in the distribution archive, isn't it? | 10:55 |
| morphis | zyga: https://bugs.launchpad.net/snapd/+bug/1657100 can be closed with the work Son_Goku did, right? | 11:01 |
| mup | Bug #1657100: snapd needs a SELinux profile to run on Fedora <snapd:Confirmed> <https://launchpad.net/bugs/1657100> | 11:01 |
| zyga | morphis: no, supported is something we just support | 11:04 |
| zyga | morphis: feel free to make that clearer | 11:04 |
| zyga | morphis: it's an arbitrary choice | 11:04 |
| zyga | morphis: (of words) | 11:05 |
| morphis | ok | 11:05 |
| morphis | something I need to work through, don't feel well maintain all these version numbers etc. on a wiki page | 11:06 |
| zyga | morphis: yes, I wanted a dynamically generated table but the wiki lets us start with something quickly | 11:07 |
| morphis | zyga: I think we need to drop the version numbers there alltogether at one point in the near future | 11:07 |
| === hikiko is now known as hikiko|ln | ||
| zyga | mvo: can you re/review https://github.com/snapcore/snapd/pull/3114 please | 11:42 |
| mup | PR snapd#3114: interfaces/mount: add function for saving fstab-like file <Created by zyga> <https://github.com/snapcore/snapd/pull/3114> | 11:42 |
| zyga | mvo: if you want I can make the extra rename | 11:42 |
| zyga | mvo: I'd like to propose more useful stuff on top | 11:42 |
| mvo | zyga: I would like the naming part for gustavo, I'm not great at names | 11:47 |
| zyga | mvo: ok, let's wait for a 2nd review for it | 11:51 |
| mvo | zyga: but I will go over it again | 11:53 |
| Son_Goku | morphis: rpmgrill errors can be fixed later, some of them can be ignored too | 12:00 |
| mup | PR snapd#3126 opened: store: handle EOF via url.Error check <Created by stolowski> <https://github.com/snapcore/snapd/pull/3126> | 12:04 |
| pstolowski | mvo, this should be the final blow at EOFs, hopefully ^ | 12:04 |
| zyga | Chipaca: hey | 12:06 |
| zyga | Chipaca: do you know any snaps that use ubuntu-app-platform | 12:06 |
| zyga | Chipaca: I'm looking and snap-update-ns hand-testing | 12:06 |
| morphis | Son_Goku: ok, good to hear | 12:06 |
| Chipaca | zyga— I don't, but give me a mo' | 12:06 |
| mvo | pstolowski: very nice! | 12:06 |
| zyga | 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 |
| zyga | Chipaca: I don't know if there's a way to ask the store "what works with this snap" | 12:07 |
| morphis | Son_Goku: so anyone we need to fix before the first release? | 12:07 |
| Son_Goku | I think I fixed all the things that were actually important, I think | 12:07 |
| zyga | morphis: \o/ | 12:08 |
| morphis | Son_Goku: nice! | 12:08 |
| Son_Goku | * Fri Mar 31 2017 Neal Gompa <ngompa13@gmail.com> - 2.23.6-2 | 12:08 |
| Son_Goku | - Fix the overlapping file conflicts between snapd and snap-confine | 12:08 |
| Son_Goku | - Rework package descriptions slightly | 12:08 |
| Son_Goku | * Sat Apr 01 2017 Neal Gompa <ngompa13@gmail.com> - 2.23.6-3 | 12:08 |
| Son_Goku | - Fix profile.d generation so that vars aren't expanded in package build | 12:08 |
| morphis | Son_Goku: are you ok with me writing a call-for-testing on forum.snapcraft.io? | 12:08 |
| Son_Goku | please do | 12:08 |
| Son_Goku | I'm so tired... | 12:08 |
| morphis | get some sleep :-) | 12:09 |
| Son_Goku | I spent literally all weekend hacking at this, because snapd is too complex for its own good... | 12:09 |
| zyga | Son_Goku: thank you! You made a lot of this happen! | 12:10 |
| morphis | Son_Goku: great work! | 12:10 |
| Son_Goku | :/ | 12:10 |
| zyga | hmm | 12:10 |
| zyga | mvo: `- core:core-support | 12:10 |
| zyga | mvo: I didn't do anything | 12:10 |
| zyga | mvo: and it got disconnected | 12:10 |
| zyga | mvo: when core support is disconnected snapd is really wonky | 12:11 |
| zyga | mvo: like a "be broken" switch | 12:11 |
| Chipaca | zyga— lonewolf, neverbore, extia-webapp, mendiapp, facebook-webapp-mardy, chronoburn, soracom-console | 12:11 |
| Son_Goku | zyga, morphis: there's still so much to go | 12:11 |
| mvo | zyga: core:core-support got disconnected? | 12:11 |
| zyga | mvo: yes | 12:11 |
| zyga | Chipaca: thanks!! | 12:11 |
| morphis | 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 |
| mvo | zyga: out of the blue? geh | 12:12 |
| Son_Goku | 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 |
| mvo | zyga: what if this happens in the wild? | 12:12 |
| zyga | mvo: not sure, I just noticed now | 12:12 |
| Chipaca | zyga— curl to get the raw yaml, python to filter | 12:12 |
| zyga | mvo: yeah | 12:12 |
| zyga | mvo: ensure connecting core:core-support? | 12:12 |
| Son_Goku | and of course, nobody can create snaps on Fedora :( | 12:12 |
| zyga | Son_Goku: base/core will happen as we approach 18 | 12:12 |
| Son_Goku | that's far too long from now | 12:13 |
| zyga | Son_Goku: and once we have that we may try fedora-based sonps | 12:13 |
| zyga | snaps | 12:13 |
| morphis | Son_Goku: there is a snapcrat snap already these days, something you can use | 12:13 |
| zyga | Son_Goku: not when 18 hits, I'm sure it will be started soon | 12:13 |
| Chipaca | 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 |
| Chipaca | zyga— and then | 12:13 |
| Son_Goku | morphis: can't, because lxd doesn't work | 12:13 |
| Chipaca | ", ".join([i["package_name"] for i in json.load(sys.stdin)["_embedded"]['clickindex:package'] if "ubuntu-app-platform" in i.get("snap_yaml_raw", "")]) | 12:13 |
| Son_Goku | morphis: the problem with snaps right now is that everything has a built-in assumption for Ubuntu | 12:14 |
| morphis | Son_Goku: sounds like we need another backend in snapcraft for cleanbuild | 12:14 |
| Son_Goku | and that makes things more rickety than I wish it did | 12:14 |
| mvo | fgimenez, pedronis: fwiw, I'm investigating the autopkgtest issues | 12:14 |
| Chipaca | probably expressable in jq, but ¯\_(ツ)_/¯ | 12:14 |
| zyga | Chipaca: thanks, this will make my experiements happy! | 12:14 |
| Chipaca | hth | 12:14 |
| Chipaca | zyga— also there's probably more, as that's just looking at the first page of results | 12:15 |
| Chipaca | bah, might as well get the whole thing | 12:15 |
| * Chipaca tweaks | 12:15 | |
| morphis | Son_Goku: yeah that is really a problem but something we need to work torwards too, however lets fix the basic things first | 12:15 |
| Chipaca | zyga— lonewolf, neverbore, extia-webapp, mendiapp, facebook-webapp-mardy, chronoburn, soracom-console, wuziqi, google-webapp, fcole90-hexgl-webapp, volleyball2d, qcheckers, ubuntu-app-platform, quassel-kalikiana, ubuntu-calculator-app | 12:16 |
| pstolowski | zyga, looking ar 3095 now; quick question - did you decide not to be paranoid wrt close(fd) return values after all? | 12:18 |
| fgimenez | mvo: thanks, greaat finding in https://forum.snapcraft.io/t/autopkgtest-broken/121 | 12:19 |
| mup | PR snapd#3127 opened: use github.com/mvo5/spread/cmd/spread until https://github.com/snapco… <Created by mvo5> <https://github.com/snapcore/snapd/pull/3127> | 12:20 |
| morphis | Son_Goku: one thing I've found is the that snapd.socket isn't started after I've installed the snapd pkg, is that expected? | 12:23 |
| Son_Goku | no | 12:23 |
| zyga | pstolowski: no | 12:23 |
| zyga | pstolowski: because of what I referenced | 12:23 |
| zyga | pstolowski: close return values are bogus | 12:23 |
| Son_Goku | it's supposed to be started, since zyga and I got it added to the preset for Fedora 25 | 12:23 |
| zyga | pstolowski: and checking them makes no sense | 12:23 |
| Son_Goku | actually, no | 12:24 |
| Son_Goku | it's just enabled | 12:24 |
| Son_Goku | morphis: afaik, you shouldn't need anything more than enabling a socket for it to work? | 12:25 |
| Son_Goku | hmm, I guess not | 12:26 |
| morphis | Son_Goku: I had to start it | 12:27 |
| Son_Goku | morphis: fixed | 12:28 |
| morphis | Son_Goku: great! | 12:28 |
| morphis | mwhudson: ping | 12:28 |
| morphis | zyga: so just confirmed, we have: INFO: snap "core" has bad plugs or slots: core-support (unknown interface) on debian too | 12:30 |
| ogra | mvo, a second review for the PRs at https://github.com/snapcore/core-build/pulls would be appreciated (if you find a spare minute) | 12:36 |
| mvo | ogra: sure, I have a look. I can't merge there it seems | 12:42 |
| ogra | mvo, only niemeyer can, i hope we get that fixed today ... i want to merge the initrd scripts source into that tree after we got thie set of PRs in | 12:42 |
| === hikiko|ln is now known as hikiko | ||
| zyga | morphis: yeah, expected | 12:53 |
| Son_Goku | morphis, hughsie has discovered issues with the snap backend in gnome software and is hacking on that now | 12:53 |
| Son_Goku | I expect he'll enable it in gnome software shortly after snapd lands in the repos | 12:54 |
| Chipaca | everything is terrible. Let's go back to netbsd. | 12:56 |
| ogra | +1 | 12:57 |
| mup | PR snapcraft#1227 closed: docs: remove docs and link to snappy-docs <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1227> | 12:57 |
| Son_Goku | also, why is snappy-docs in Canonical's github org rather than the snapcore one? | 12:58 |
| Son_Goku | that's not an obvious place at all | 12:58 |
| niemeyer | Mornings | 12:58 |
| morphis | Son_Goku: great! | 12:58 |
| Son_Goku | niemeyer: morning | 12:58 |
| morphis | niemeyer: morning! | 12:58 |
| niemeyer | ogra: Ah, sorry, let me get that fixed | 12:58 |
| * Son_Goku grumbles | 12:58 | |
| * ogra hugs niemeyer | 12:58 | |
| morphis | Son_Goku: good question for davidcalle | 12:58 |
| * Son_Goku jumps off a cliff | 12:58 | |
| niemeyer | ogra: Should be working now | 12:59 |
| ogra | Son_Goku, video or it didnt happen (and we want to see some fancy gymnastics !) | 13:00 |
| niemeyer | Just added the usual snapd-committers team there | 13:00 |
| Son_Goku | ogra: I'm too fat for that | 13:00 |
| ogra | Son_Goku, nah, that just makes it extra funny (i'm not much slimmer than you iirc :P ) | 13:00 |
| Son_Goku | haha | 13:00 |
| ogra | niemeyer, yep, worked, thanks | 13:00 |
| niemeyer | Sweet, np | 13:01 |
| mup | PR core-build#4 closed: Remove snapd.generate-network-conf.service <Created by zyga> <Merged by ogra1> <https://github.com/snapcore/core-build/pull/4> | 13:01 |
| ogra | niemeyer, i'll creat an initrd/ subdir in there this afternoon to merge the initramfs-tools-ubuntu-core source in there then ... or would you prefer a different dir name ? | 13:02 |
| mup | PR core-build#3 closed: Remove 10-ubuntu-core-secure-path <Created by zyga> <Merged by ogra1> <https://github.com/snapcore/core-build/pull/3> | 13:02 |
| mup | PR core-build#1 closed: adjust README file to proper reflect repo content <Created by ogra1> <Merged by ogra1> <https://github.com/snapcore/core-build/pull/1> | 13:03 |
| mup | PR core-build#2 closed: Rename snappy-set-hostname to snapd-set-hostname <Created by zyga> <Merged by ogra1> <https://github.com/snapcore/core-build/pull/2> | 13:03 |
| davidcalle | Son_Goku: because it predates it :) But this will be fixed, agreed | 13:14 |
| mup | PR snapcraft#1228 opened: nodejs plugin: switch to the newer LTS <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1228> | 13:15 |
| Son_Goku | niemeyer: what happens to "channel" in a snapd json blob when someone sideloads a snap? | 13:27 |
| jdstrand | cachio: did someone answer your question re reinstalling without downloading? | 13:31 |
| niemeyer | Son_Goku: On the standup call.. will be with you shortly | 13:33 |
| mup | PR snapd#3127 closed: use github.com/mvo5/spread/cmd/spread until https://github.com/snapco… <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/3127> | 13:36 |
| niemeyer | Son_Goku: Okay, so.. can you open a topic in the forum with more details about the question? (not sure about what "snapd json blob" means there) | 13:44 |
| Son_Goku | niemeyer: hughsie is asking me about this for gnome-software in the #gnome-software channel on gimpnet | 13:44 |
| niemeyer | Son_Goku: Easier to explain things there and sticks around for others to participate and learn from | 13:44 |
| Son_Goku | he's trying to fix the snappy integration in gnome-software | 13:44 |
| zyga | niemeyer: I could use a simple review on https://github.com/snapcore/snapd/pull/3114 | 13:45 |
| mup | PR snapd#3114: interfaces/mount: add function for saving fstab-like file <Created by zyga> <https://github.com/snapcore/snapd/pull/3114> | 13:45 |
| Son_Goku | it's not really forum appropriate since the target audience isn't there | 13:45 |
| niemeyer | Son_Goku: Chicken and egg | 13:45 |
| Son_Goku | in this case, the chicken won't go across the road :) | 13:45 |
| niemeyer | Son_Goku: It's okay, they don't have to.. they can simply learn from what the two of us discuss there | 13:46 |
| niemeyer | Son_Goku: And others will too | 13:46 |
| niemeyer | Son_Goku: The important thing is not losing these interesting discussions to IRC logs | 13:46 |
| Son_Goku | is this really all that interesting? | 13:47 |
| niemeyer | zyga: Looking | 13:47 |
| zyga | Son_Goku: I think thre are other front-ends to install stuff | 13:47 |
| zyga | Son_Goku: I bet it will be interesting | 13:47 |
| * Son_Goku sighs | 13:47 | |
| niemeyer | Son_Goku: if you don't want to, I'm happy to make a monologue there.. just provide more details about the question and I'll write it all | 13:48 |
| Son_Goku | sure, one sec | 13:48 |
| mup | PR snapd#3128 opened: interfaces/mount: fix golint issues <Created by zyga> <https://github.com/snapcore/snapd/pull/3128> | 13:49 |
| cachio | jdstrand, the solution I got is to download the snap and then install as many times as I want | 13:52 |
| cachio | jdstrand, is it the best way to do it? | 13:52 |
| Son_Goku | niemeyer: here: https://forum.snapcraft.io/t/how-to-determine-source-of-snap/125 | 13:53 |
| jdstrand | cachio: that is the way to do it. snap download foo. sudo snap ack ./foo*.assert ; sudo snap install ./foo*.snap | 13:53 |
| niemeyer | Son_Goku: Thanks so much | 13:53 |
| niemeyer | Son_Goku: Going there right now | 13:53 |
| * Son_Goku is tired | 13:53 | |
| jdstrand | cachio: if you ack the assertion, you don't need --dangerous | 13:53 |
| niemeyer | Son_Goku: I've heard you did some great work over the weekend.. thanks a lot for that! | 13:54 |
| cachio | jdstrand, great, I'll do that | 13:54 |
| * Son_Goku sighs | 13:54 | |
| cachio | jdstrand, tx | 13:54 |
| jdstrand | I'm not sure if you were told that, but that is handy and is equivalent to an install from the store | 13:54 |
| Son_Goku | niemeyer: I really hope it isn't going to be as hellish in the future | 13:54 |
| Son_Goku | I spent all weekend on it :( | 13:54 |
| jdstrand | where --dangerous is not in terms of base declaration checks | 13:54 |
| niemeyer | Son_Goku: Yeah, it probably won't.. the integration points with the distribution don't really change all that often.. very seldom we need to touch the package | 13:55 |
| === lazyPower is now known as lp|swap | ||
| Son_Goku | niemeyer: of course, that's easy for you, since you mainly care about it working on Ubuntu and Ubuntu Core | 13:56 |
| Son_Goku | :) | 13:56 |
| Chipaca | https://go-review.googlesource.com/c/39207/ <- log.Fatal(http.Serve(autocert.NewListener("example.com"), handler)) <- i.e. letsencrypt oneliner | 13:56 |
| Son_Goku | zyga: did you see my response to the cgroups bug? | 13:57 |
| niemeyer | Son_Goku: That's misjudging what I care about.. :) | 13:57 |
| zyga | Son_Goku: not yet, I just replied to it in the morning | 13:57 |
| * zyga looks | 13:57 | |
| zyga | Son_Goku: noted | 13:58 |
| zyga | morphis: I think we want to talk to Zbigniew there to understand what we need to do | 13:58 |
| zyga | morphis: https://bugs.launchpad.net/snappy/+bug/1678342 | 13:58 |
| mup | Bug #1678342: snapd udev rules are incompatible with unified cgroup hierarchy <Snappy Launcher:New> <snapd:New> <Snappy:Incomplete by zyga> <snapd (Fedora):Unknown> <https://launchpad.net/bugs/1678342> | 13:58 |
| zyga | morphis: if you initiate the conversation I'm happy to make all the changes required | 13:58 |
| Son_Goku | zyga: he's zbyszek in #fedora-devel | 13:58 |
| Son_Goku | morphis ^ | 13:58 |
| zyga | morphis: maybe Zybszek is on IRC around as he seems to be in the same timezone | 13:58 |
| zyga | :D | 13:58 |
| zyga | Son_Goku: I was typing the same thing :) | 13:59 |
| jdstrand | kyleN: I answered on the list | 13:59 |
| kyleN | thanks jdstrand | 13:59 |
| jdstrand | pekkari: hey, 'ubuntu-kernel' is a very official sounding name for a kernel snap. you might want to run the name of your snap by JamieBennett, et al | 14:02 |
| morphis | zyga, Son_Goku: yeah saw that bug earlier today, and its on my list to look into | 14:03 |
| Son_Goku | mvo: is the focus now on snapd 2.24? | 14:03 |
| jdstrand | pekkari: I put a comment in the snap asking for feedback | 14:03 |
| jdstrand | in the store* | 14:03 |
| pekkari | jdstrand: got it, thanks for reviewing! | 14:04 |
| pekkari | I'll ask Jamie | 14:04 |
| zyga | Son_Goku: yes | 14:06 |
| Son_Goku | zyga: does snapd-login-service require snapd to be installed? | 14:07 |
| mup | PR snapd#3129 opened: interfaces/mount: add InfoEntry type <Created by zyga> <https://github.com/snapcore/snapd/pull/3129> | 14:07 |
| zyga | Son_Goku: I don't know, I think it talks to snapd over the socket | 14:08 |
| Son_Goku | hmm | 14:08 |
| zyga | Son_Goku: if you just install it those calls will fail | 14:08 |
| zyga | Son_Goku: but it should be OK | 14:08 |
| Son_Goku | then I should drop the Requires | 14:08 |
| Son_Goku | because Fedora Workstation is going to be pissed if gnome-software pulls in snapd when they don't want it | 14:09 |
| zyga | Son_Goku: what happens when you don't have snapd and you have the login package | 14:11 |
| Son_Goku | I have no idea | 14:11 |
| zyga | Son_Goku: does gnome-software work correctly? | 14:11 |
| Son_Goku | again, no idea | 14:12 |
| zyga | morphis: ^ something to try | 14:12 |
| zyga | Son_Goku: as long as it just works droping the Requires is correct | 14:13 |
| zyga | Son_Goku: if it breaks we should see so that it doesn't | 14:13 |
| jdstrand | ogra: hi! I see linux-generic-bbb has 71 in edge-- when do you plan to release that to stable? | 14:13 |
| Son_Goku | well, the Requires was originally written by you, I think, so hell if I know | 14:13 |
| zyga | Son_Goku: (maybe offer a GUI action to install snapd) | 14:13 |
| Son_Goku | zyga, uhh wut? [10:15:49 AM] <hughsie>Son_Goku, so, a packaging error? http://imgur.com/a/CowmR | 14:16 |
| Son_Goku | any explanation for the random Turkish? | 14:17 |
| zyga | Son_Goku: woah | 14:20 |
| zyga | Son_Goku: no, something very very weird indeed | 14:20 |
| ogra | jdstrand, oh, sorry, forgot about the extra click ... doing now | 14:20 |
| * zyga waves hi to Richard and his fantastic hardware :) | 14:21 | |
| Son_Goku | zyga: morphis: someone needs to hop into #gnome-software on irc.gimp.org | 14:21 |
| ogra | jdstrand, done | 14:21 |
| zyga | I think we should find Robert that wrote that part | 14:21 |
| morphis | Son_Goku: I am on the way | 14:22 |
| jdstrand | ogra: thanks! | 14:22 |
| zyga | morphis: ^ can you hop into #g-s there | 14:22 |
| zyga | morphis: thanks! | 14:22 |
| zyga | Son_Goku: meanwhile I'll be working with mount more until it works | 14:22 |
| Son_Goku | I gotta go to work, but I can't leave hughsie hanging | 14:22 |
| zyga | Son_Goku: I think morphis will take over, thank you for keeping an eye out for this! | 14:23 |
| morphis | Son_Goku: #g-s or #gnome-software? | 14:24 |
| morphis | ah have the right one | 14:24 |
| niemeyer | Son_Goku: Answered | 14:31 |
| niemeyer | Son_Goku: Sorry, answering it properly took a little while.. | 14:31 |
| niemeyer | morphis, zyga: ^ | 14:32 |
| morphis | niemeyer: an answer to what? :-) | 14:32 |
| niemeyer | morphis: Sorry, I thought you were following the conversation.. I suggest reading the backlog from 1h10min ago that we had here, as that's relevant for the conversation you'll have in #g-s | 14:33 |
| morphis | niemeyer: ah I see, you're referring to the "How to determine “source” of snap?" thread | 14:37 |
| niemeyer | morphis: Are you on top of these exchanges? | 14:38 |
| mvo | Son_Goku: yes, the next release will be 2.24, 2.23.6 is hopefully in good shape now. if you have anything that you need in there, please add a reply to the topic | 14:38 |
| morphis | niemeyer: I am on it, yes | 14:38 |
| Son_Goku | mvo: I'll add a reply soonish, as there's *a lot* I need to be in 2.24 | 14:38 |
| mvo | Son_Goku: oh, ok :) | 14:39 |
| Son_Goku | mvo: http://pkgs.fedoraproject.org/cgit/rpms/snapd.git/tree/snapd.spec#n52 :) | 14:39 |
| Son_Goku | actually, not so much I guess | 14:40 |
| Son_Goku | just a couple more PRs | 14:40 |
| Son_Goku | anyway, bye for now | 14:41 |
| morphis | mvo: 2.24 is targetted for this thursday? | 14:43 |
| mvo | morphis: no ETA yet, we should discuss that | 14:44 |
| mvo | morphis: we can target anything that Son_Goku needs in GH so that its on the radar | 14:45 |
| mup | PR snapd#3130 opened: overlord/devicestate: switch to keygen for device key generation <Created by vosst> <https://github.com/snapcore/snapd/pull/3130> | 14:45 |
| pedronis | mvo: are we cutting 2.24 tomorrow? | 14:45 |
| morphis | mvo: there are some he has in his list I am currently prepping to be ready | 14:46 |
| mvo | pedronis: I think we should discuss in the standup, JamieBennett also has a say in this of course. | 14:46 |
| * zyga goes to merge https://github.com/snapcore/snapd/pull/3114 with 2 +1 already | 14:46 | |
| mup | PR snapd#3114: interfaces/mount: add function for saving fstab-like file <Created by zyga> <https://github.com/snapcore/snapd/pull/3114> | 14:46 |
| mup | PR snapd#3114 closed: interfaces/mount: add function for saving fstab-like file <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3114> | 14:47 |
| JamieBennett | mvo: pedronis:, morphis: Well, it would be good to push out this release asap as it contains a lot of changes, so sooner rather than later. What is a sensible cut off day for the release? | 14:47 |
| pedronis | mvo: zesty will not have 2.24 either way out of the door right? | 14:48 |
| morphis | JamieBennett: if there are more important things we don't have to block on the PRs King_InuYasha pointed out, having them included would only allow us to drop all these patches on the distro packages | 14:49 |
| JamieBennett | morphis: what is the eta for these landing? | 14:49 |
| morphis | JamieBennett: I am trying to finish these as we speak | 14:50 |
| mup | PR snapd#3131 opened: interfaces/mount: add OptsToFlags for converting arguments to syscall… <Created by zyga> <https://github.com/snapcore/snapd/pull/3131> | 14:50 |
| morphis | niemeyer: https://github.com/snapcore/snapd/pull/3039 needs another review from your side | 14:51 |
| mup | PR snapd#3039: many: add support for partially static builds <Created by zyga> <https://github.com/snapcore/snapd/pull/3039> | 14:51 |
| mup | PR snapcraft#1077 closed: Shout -> Lounge, the official fork <Created by MaxLeiter> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/1077> | 14:51 |
| mup | PR snapcraft#1225 closed: channels: Fix staging store test for Tracks <Created by josepht> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1225> | 14:51 |
| mvo | pedronis: probably not, final freeze is thursday, highly unlikely. I'm pretty sure there will be a 0-day SRU for this one | 14:55 |
| pedronis | mvo: anyway if we cut it tomorrow is unlikey that new aliases will make it, maybe slightly more likely if Thu, but not sure (depends on reviews) | 14:56 |
| pedronis | otherwise they will be in 2.25 | 14:57 |
| mvo | pedronis: ok, thank you. we can hear what JamieBennett thinks about cutting the release thur/fri, preparing everything in beta and moving forward with candidate on monday maybe? if it means that new aliases may make it this way | 14:58 |
| niemeyer | morphis: Reviewed | 15:06 |
| niemeyer | and lunch time.. back in a bit | 15:06 |
| mup | Bug #1679210 opened: snap install --revision tracks stable by default <Snappy:New> <https://launchpad.net/bugs/1679210> | 15:10 |
| morphis | niemeyer: thanks! | 15:12 |
| zyga | niemeyer: can I get a trivial review for: https://github.com/snapcore/snapd/pull/3131/files | 15:51 |
| mup | PR snapd#3131: interfaces/mount: add OptsToFlags for converting arguments to syscall… <Created by zyga> <https://github.com/snapcore/snapd/pull/3131> | 15:51 |
| zyga | I could use a review of https://github.com/snapcore/snapd/commit/26ebf0c2866e14ab14099d550e723dc78561536d | 16:01 |
| zyga | I'll propose it after https://github.com/snapcore/snapd/pull/3131 lands | 16:01 |
| mup | PR snapd#3131: interfaces/mount: add OptsToFlags for converting arguments to syscall… <Created by zyga> <https://github.com/snapcore/snapd/pull/3131> | 16:01 |
| niemeyer | zyga: I need to have a look at pending topics and PRs first, but will be there soon | 16:01 |
| zyga | niemeyer: sure, thanks! | 16:01 |
| zyga | niemeyer: I'll take a break now, I have a few more useful bits and I'll try to land most that I wrote today | 16:01 |
| zyga | niemeyer: if you can please focus on https://github.com/snapcore/snapd/pull/3095 | 16:02 |
| mup | PR snapd#3095: cmd/snap-update-ns: add C preamble for setns <Created by zyga> <https://github.com/snapcore/snapd/pull/3095> | 16:02 |
| zyga | niemeyer: after that in any order | 16:02 |
| zyga | pstolowski: ^^ can you please review this again as well | 16:02 |
| zyga | pstolowski: you are also blocking it ATM | 16:02 |
| pstolowski | k | 16:02 |
| pstolowski | zyga, blocking? i aproved it last time | 16:03 |
| zyga | pstolowski: oh, I need to refresh :) | 16:05 |
| pedronis | niemeyer: it seems we never had to delete a top key in state, is there a use case for state.Set(key, nil) not to mean delete? | 16:06 |
| zyga | pstolowski: indeed, thank you :) | 16:06 |
| pstolowski | zyga, :) | 16:06 |
| niemeyer | pedronis: Ideally those would mean the same thing | 16:08 |
| pedronis | niemeyer: it's not implemented like that atm, but it seems the right thing (instead of growin state.Del or state.Delete) | 16:08 |
| * zyga -> off | 16:11 | |
| niemeyer | pedronis: https://forum.snapcraft.io/t/should-missing-state-keys-and-null-keys-be-the-same/128 | 16:13 |
| morphis | zyga, King_InuYasha, Pharaoh_Atem: if you don't follow the conversation in | 16:16 |
| morphis | #gnome-software, looks like we miss gettext support in policykit on other distros | 16:16 |
| morphis | zyga, King_InuYasha, Pharaoh_Atem: https://bugs.freedesktop.org/show_bug.cgi?id=29639 | 16:17 |
| morphis | Robert filed that ages ago | 16:18 |
| morphis | will go a little bit more in the details tomorrow but the easiest we can do is dropping all other languages from the .policy file and only keep en there | 16:18 |
| morphis | as it always picks the last one | 16:18 |
| morphis | (which is turkish in the default case) | 16:18 |
| ogra | morphis, how lame, so fedora has no zulu translations ? | 16:20 |
| ogra | :) | 16:20 |
| cmars | is it possible to publish snaps in such a way that they're private to a list of users, or maybe a LP team? | 16:25 |
| === elfgoh_ is now known as elfgoh | ||
| mup | PR snapd#3132 opened: overlord/state: make sure that setting to nil a state key is equivalent to deleting it <Created by pedronis> <https://github.com/snapcore/snapd/pull/3132> | 16:48 |
| ogra | pedronis, http://paste.ubuntu.com/24307672/ thats an image using ssh-keygen i just tested ... 17:08:57 Generate device key ... 17:09:45 Mark system seeded ... lots faster :) | 17:19 |
| * ogra goes afk | 17:20 | |
| mup | PR snapcraft#1221 closed: pluginhandler: factor out state bits into the state package <Created by josepht> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1221> | 17:27 |
| mup | PR snapcraft#1226 closed: Better check of the error code in StatusTracker <Created by facundobatista> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1226> | 17:30 |
| === JanC_ is now known as JanC | ||
| niemeyer | Taking a break for exercising, then back for more reviews.. | 19:04 |
| datajerk | hi all, i'm trying to get snaps working on the nvidai tx2, i patch the kernel config so that snap would mount, etc..., but am now getting the following error with snap install hello-world: Run configure hook of "core" snap if present (run hook "configure": execv failed: No such file or directory). Google not much help with this one. Thanks. | 19:31 |
| datajerk | from syslog: /usr/lib/snapd/snapd[3391]: snapmgr.go:807: Reported problem as c3074eec-18a3-11e7-a49b-fa163ebeb28a OOPSID | 19:32 |
| mup | PR snapd#3128 closed: interfaces/mount: fix golint issues <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3128> | 19:33 |
| kyrofa | datajerk, does the kernel include apparmor? | 19:40 |
| zyga | datajerk: hey | 19:42 |
| zyga | datajerk: can you tell me more about your system, I assume you have the tx2 devkit (nice, how did you get one?) | 19:42 |
| zyga | datajerk: can you tell me if this is a classic system? (with apt-get and such) and snapd as an extra or just snapd (no apt, dpkg, just snaps) | 19:43 |
| datajerk | CONFIG_SECURITY_APPARMOR=y | 19:43 |
| datajerk | CONFIG_SECURITY_APPARMOR_BOOTPARAM_VALUE=1 | 19:43 |
| datajerk | CONFIG_SECURITY_APPARMOR_HASH=y | 19:43 |
| datajerk | CONFIG_DEFAULT_SECURITY_APPARMOR=y | 19:43 |
| datajerk | kyrofa ^^ | 19:43 |
| zyga | datajerk: which kernel are you running? | 19:44 |
| zyga | datajerk: and which version of snapd? | 19:44 |
| datajerk | zyga tx2 devkit, yes, ubuntu classic 16.04.02. nvidia kernel 4.4.15, patch kernel to support docker and snap (just .config). | 19:44 |
| zyga | datajerk: aha | 19:44 |
| zyga | datajerk: so | 19:45 |
| zyga | datajerk: you need either bleeding edge snapd that understands you don't have the full apparmor patchset | 19:45 |
| zyga | datajerk: or you need to patch the nvidia kernel to contain all the apparmor ubuntu sause | 19:45 |
| kyrofa | datajerk, snapd requires apparmor patches that aren't available upstream just yet | 19:46 |
| kyrofa | Yeah, that | 19:46 |
| datajerk | zyga which is recommended, faster? | 19:46 |
| datajerk | URLs? | 19:46 |
| zyga | datajerk: I think trying to get apparmor patches may be better, one sec | 19:47 |
| zyga | datajerk: http://kernel.ubuntu.com/git/ubuntu/ubuntu-xenial.git/log/ | 19:47 |
| zyga | datajerk: try to see what's in security/apparmor that is not in 4.4 | 19:48 |
| zyga | datajerk: the execve failure is very curious though | 19:49 |
| zyga | datajerk: I think we should see that error report | 19:49 |
| zyga | datajerk: can you run "snap changes" and then "snap change 123" where 123 is the ID of latest change | 19:49 |
| zyga | datajerk: quick search shows about three pages of apparmor patches http://kernel.ubuntu.com/git/ubuntu/ubuntu-xenial.git/log/security/apparmor?qt=grep&q=SAUCE:+apparmor&ofs=100 | 19:51 |
| jdstrand | tyhicks: iirc you have a more up to date list? ^ | 19:51 |
| zyga | jdstrand: oh, thank you | 19:51 |
| zyga | jdstrand: I'd love to have this | 19:51 |
| zyga | tyhicks: if you have a better list can you please post that on a forum and refer to the forum here | 19:52 |
| jdstrand | well, I think the canonical (little 'c') list of patches is in the porting guide | 19:52 |
| tyhicks | jdstrand: I don't have a list | 19:52 |
| zyga | jdstrand: where is the porting guide? | 19:53 |
| zyga | jdstrand: last time I looked at sample kernels it was vary out of date | 19:53 |
| zyga | very* | 19:53 |
| Pharaoh_Atem | there's a porting guide? | 19:53 |
| tyhicks | a list isn't really maintainable because the patches needed are ever-changing | 19:53 |
| jdstrand | tyhicks: I actually meant the porting guide | 19:53 |
| zyga | tyhicks: yes, exactly | 19:53 |
| * jdstrand is looking | 19:53 | |
| zyga | tyhicks: I think having a branch against 4.x (some important releases) would be fantastic | 19:54 |
| tyhicks | oh, that's not really helpful | 19:54 |
| tyhicks | https://github.com/snapcore/sample-kernels/blob/master/README.md | 19:54 |
| tyhicks | that's the porting guide | 19:54 |
| Pharaoh_Atem | that's not helpful at all | 19:54 |
| tyhicks | zyga: that's what the samples-kernel tree is supposed to be but it would take quite a bit of time to backport, maintain and test | 19:54 |
| zyga | tyhicks: I think what people start with is a kernel (various versions) and they keep asking "how do we get apparmor support in this kernel" | 19:55 |
| jdstrand | that's it. jeez, I could not find it :P | 19:55 |
| zyga | tyhicks: aha | 19:55 |
| zyga | tyhicks: is there more than the apparmor sauce required? | 19:55 |
| tyhicks | zyga: yes, depending on what kernel version you're backporting to | 19:55 |
| datajerk | zyga changes output: http://termbin.com/8esh | 19:56 |
| zyga | tyhicks: we commonly see 4.x (including mainline) and 3.4 (some android support kernel I suspect) | 19:56 |
| Pharaoh_Atem | zyga: for example, depending on which point in time of the CentOS 7 kernel you're porting to, you may or may not have to just do apparmor stuff | 19:56 |
| kyrofa | seccomp filters was only v3.5, but I think it's its own config option | 19:56 |
| zyga | datajerk: thank you, checking | 19:56 |
| Pharaoh_Atem | and 3.4 is the ancient kernel required for loads of old Android devices :( | 19:57 |
| tyhicks | zyga: I doubt 3.4 is possible without serious amounts of work | 19:57 |
| kyrofa | Pharaoh_Atem, yeah I backported seccomp filters to v3.4. Super fun | 19:57 |
| zyga | datajerk: huh, that's curious | 19:57 |
| sborovkov | jdstrand: Hi. I answered your request for clarification about dbus issue in the mailing list. Could you take a look when you have time please. | 19:57 |
| zyga | datajerk: I'd love to see what is there (the error report) | 19:57 |
| zyga | tyhicks: and mainline? | 19:57 |
| Pharaoh_Atem | kyrofa: the only time I have to work with v3.4 is when some ass decides that Android hardware is Good for Regular Linux(TM) | 19:57 |
| zyga | tyhicks: (this will be often the story of another distribution that may choose to take our patches) | 19:58 |
| kyrofa | Haha | 19:58 |
| zyga | Pharaoh_Atem: android hardware is, android software is not | 19:58 |
| datajerk | zyga location of error report? | 19:58 |
| Pharaoh_Atem | right, but uninformed people confuse and conflate | 19:58 |
| tyhicks | zyga: maineline should be possible | 19:58 |
| Pharaoh_Atem | tyhicks: last I checked (4.9), it wasn't | 19:58 |
| zyga | datajerk: I'm afraid I cannot see that, it goes to errors.ubuntu.com, it's pretty restricted as some reports may be sensitive | 19:59 |
| zyga | tyhicks: I think that would be very useful | 19:59 |
| zyga | tyhicks: who is maintaining sample kernels? kernel or security team? | 19:59 |
| jdstrand | sborovkov: you have two services? that offer dbus interfaces? | 19:59 |
| Pharaoh_Atem | zyga: according to readme, no one? | 19:59 |
| tyhicks | zyga: kernel team set it up - nobody is maintaining it | 19:59 |
| zyga | aha | 19:59 |
| zyga | perhaps jjohansen could maintain a mainline + patches branch as he probably has that already for upstreaming | 20:00 |
| tyhicks | he periodically does that | 20:00 |
| zyga | tyhicks: do you think that would be low cost? | 20:00 |
| zyga | (useful without a lot of extra burden on the security team) | 20:00 |
| sborovkov | jdstrand: well one exposes it. the second one just does some IPC calling those methods from system bus. I actually have more services that expose dbus interfaces. But they are in another branch at the moment. | 20:00 |
| tyhicks | jjohansen: let me save you some backscroll reading - zyga and Pharaoh_Atem were curious if you have the apparmor kernel delta forward ported to Linus' tree anywhere? | 20:01 |
| sborovkov | jdstrand: I meant only one exposes dbus interfaces :-) | 20:01 |
| zyga | tyhicks: thank you! :) | 20:02 |
| Pharaoh_Atem | :) | 20:02 |
| jdstrand | sborovkov: so you have something like a <-> b <-> c, where 'a' is a dbus service that binds to a well-known name, 'b' talks to it and exposes to other things, like 'c'? | 20:02 |
| NicolinoCuralli | hi all i need to chanche the systemd timer for snap.refresh: is it possibile by setting a configuration option with snap set command? | 20:03 |
| jdstrand | datajerk: to circle back to you, what kernel are you wanting patches for? | 20:03 |
| jdstrand | datajerk: 3.4 based, 3.10, 4.4, ...? | 20:03 |
| sborovkov | jdstrand: I am not familiar with dbus therminology, so I've got this basically. Service 1 - exposes interface. Service 2 - gets the bus and makes a call to the exposed interface | 20:03 |
| jdstrand | sborovkov: so, client and server, nothing else? | 20:03 |
| datajerk | jdstrand 4.4.15 is what nvidia provides with *their* patches, so i have to patch that kernel, cannot use stock | 20:04 |
| jdstrand | sborovkov: service 1 binds to com.screenly.playlist and service 2 talks to it? | 20:04 |
| sborovkov | jdstrand: at the moment, nothing else. In the future there will be a few more services that will be client and the server at the same time, i.e. expose some stuff and call some other stuff. | 20:04 |
| sborovkov | jdstrand: correct | 20:04 |
| jdstrand | datajerk: ok, so with 4.4 you can look at the Ubuntu delta for 16.04, since that is a 4.4 kernel | 20:04 |
| datajerk | jdstrand thanks, do you happen to have a url for that, i'm not familiar with where ubuntu stores all their patches and deltas, thanks | 20:05 |
| jdstrand | sborovkov: ok, and in your yaml, playlist binds to the well-known name and websocket talks to it? | 20:05 |
| jdstrand | sborovkov: I thought I saw a url go by. I'll refer you to tyhicks to verify | 20:06 |
| sborovkov | jdstrand: yes, see my first mail I quoted that yaml subsections | 20:06 |
| jdstrand | sborovkov: right, I am looking at that email. I wanted to verify your code did that too | 20:06 |
| Pharaoh_Atem | jjohansen: main reason for this is because I considered pushing for AppArmor to be enabled in 4.9 for Mageia | 20:06 |
| Pharaoh_Atem | but there's no value if the patches aren't upstreamed | 20:06 |
| zyga | Pharaoh_Atem: they are, look at mainline man, it's just not _all_ ready | 20:07 |
| Pharaoh_Atem | zyga: I don't know what to look for | 20:07 |
| tyhicks | Pharaoh_Atem: 60 patches went up for 4.11 and some more should go up soon for 4.12 | 20:08 |
| zyga | Pharaoh_Atem: changes in security/apparmor | 20:08 |
| tyhicks | Pharaoh_Atem: good progress is being made | 20:08 |
| Pharaoh_Atem | excellent | 20:08 |
| jdstrand | sborovkov: I was a bit confused about the phrasing in the last email. I don't understand how websocket, ie, service 2 (the client of playlist) can 'get system bus without any issues' if service 1, playlist, can' | 20:08 |
| Pharaoh_Atem | then that means that when the next longterm kernel rolls around this fall, it'll all be there | 20:08 |
| jdstrand | t register on dbus | 20:08 |
| sborovkov | jdstrand: well second service obtains system bus. When it tries to call method from "com.screenly.playlist" I get an exception that the name was not provided by any service file. In the server though the same line bus = SystemBus() triggers an exception (I am using pydbus) | 20:09 |
| NicolinoCuralli | all: Hi, a question about snapd.refresh timer: is it possibile by setting a configuration option with snap set command? | 20:10 |
| sborovkov | jdstrand: https://hastebin.com/lezozujaxi.sql | 20:10 |
| jdstrand | sborovkov: ok, so playlist didn't start because of an apparmor denail, and then websocket can't connect to it because it didn't start? | 20:10 |
| sborovkov | jdstrand: yup | 20:10 |
| zyga | NicolinoCuralli: hey, no but that timer has a purpose differen from what you may think | 20:11 |
| tyhicks | datajerk: the patches for a 4.4 are here: http://kernel.ubuntu.com/git/ubuntu/ubuntu-xenial.git/log/security/apparmor | 20:11 |
| jdstrand | sborovkov: what is the apparmor denial you see when playlist doesn't start? | 20:11 |
| zyga | NicolinoCuralli: that is a failover refresh | 20:11 |
| Pharaoh_Atem | zyga: the other reason is for figuring out if I wanted to attempt the backport, what I need to look for to get enough working for snapd | 20:11 |
| jdstrand | sborovkov: let's look at playlist first, then look at websocket | 20:11 |
| zyga | NicolinoCuralli: snapd does refresh internally and there's work (branches) in progress that will allow to configure how / when the refresh happens | 20:11 |
| tyhicks | datajerk: you'll need them all back to "UBUNTU: SAUCE: (no-up) apparmor: add parameter to control whether policy hashing is used" | 20:11 |
| sborovkov | jdstrand: https://hastebin.com/pakuciqide.go | 20:12 |
| sborovkov | jdstrand: and this is from python: GLib.GError: g-dbus-error-quark: GDBus.Error:org.freedesktop.DBus.Error.AccessDenied: An AppArmor policy prevents this sender from sending this message to this recipient; type="method_call", sender=":1.7" (uid=0 pid=1478 comm="python3 -m screenly.client.playlist -c /var/snap/s") interface="org.freedesktop.DBus.Introspectable" member="Introspect" error name="(unset)" requested_reply="0" destination="org.freedesktop.DBus" ( | 20:12 |
| sborovkov | bus) (9) | 20:12 |
| jdstrand | why is there an overlay in the upper right that is covering important info?... | 20:13 |
| sborovkov | you mean on hastebin? I have 2560x1440 resolution so I never noticed that | 20:14 |
| jdstrand | sborovkov: can you paste the denial here? | 20:14 |
| jdstrand | line 2 | 20:14 |
| jdstrand | sborovkov: nm, I went to https://hastebin.com/raw/pakuciqide | 20:16 |
| NicolinoCuralli | zyga: i need to understand the algorithm used for update the snap : after a publication on store how many time i need to wait for update on my board? i just test it and no autoupdate happen | 20:16 |
| mup | Bug #1679295 opened: Interface to access /sys filesystem <snapd-interface> <Snappy:New> <https://launchpad.net/bugs/1679295> | 20:17 |
| tyhicks | jdstrand: it looks like an incomplete paste to me | 20:17 |
| jdstrand | sborovkov: well, I take that back. it seems the log entry was truncated | 20:17 |
| jdstrand | sborovkov: look at interface="org.freedesktop. | 20:17 |
| zyga | NicolinoCuralli: I think it is randomized 6 hours | 20:17 |
| zyga | NicolinoCuralli: you can refresh manually | 20:17 |
| jdstrand | sborovkov: that is incomplete. can you paste the complete denial? | 20:17 |
| NicolinoCuralli | zyga: my board run unattended: it is not possibile to run manually snap refresh on the board | 20:19 |
| sborovkov | jdstrand: oh one sec | 20:20 |
| sborovkov | jdstrand: https://hastebin.com/nijayemime.scala | 20:21 |
| zyga | NicolinoCuralli: setup ssh and log in | 20:22 |
| zyga | NicolinoCuralli: you had to install your snap somehow right? | 20:22 |
| jdstrand | sborovkov: that denial is saying an unconfined process is trying to introspect the playlist. is this on Ubuntu classic distro or all snaps? | 20:25 |
| sborovkov | jdstrand: it's on core | 20:25 |
| NicolinoCuralli | zyga: yes, my problem is after first installation : after this moment i can't login on board | 20:25 |
| jdstrand | sborovkov: ok. what is introspecting playlist? | 20:25 |
| zyga | NicolinoCuralli: did you setup ssh on your launchpad account? | 20:25 |
| NicolinoCuralli | yes | 20:26 |
| jdstrand | sborovkov: (because on core there are no rules allowing introspection by unconfined) | 20:26 |
| zyga | NicolinoCuralli: can you ssh ubuntu@IP-of-the-board? | 20:26 |
| sborovkov | jdstrand: I've no idea. I have nothing else running there especially in unconfined. Image was created by ubuntu-image. With confinement set to strict in screenly-client snap | 20:27 |
| jdstrand | it looks like maybe dbus-daemon is introspecting it | 20:27 |
| NicolinoCuralli | zyga: i will have several board ( thousand ) i can't ssh into all of them: this is the reason about my question on snap refresh mechanism | 20:28 |
| jdstrand | sborovkov: does your playlist code Introspect()? | 20:30 |
| sborovkov | jdstrand: not manually. pydbus might be doing that I guess? | 20:30 |
| jdstrand | maybe | 20:31 |
| sborovkov | jdstrand: yeah I am pretty sure it does that, because it required library that supported introspection. gio something. or it's dependency. | 20:31 |
| jdstrand | sborovkov: can you add to /var/lib/snapd/apparmor/profiles/snap.screenly-client.playlist this rule before the ending '}' | 20:32 |
| jdstrand | sborovkov: http://paste.ubuntu.com/24308617/ | 20:33 |
| datajerk | tyhicks thanks! | 20:33 |
| tyhicks | np! | 20:33 |
| jdstrand | sborovkov: after you add that you need to load it into the kernel with: sudo apparmor_parser -r /var/lib/snapd/apparmor/profiles/snap.screenly-client.playlist | 20:33 |
| sborovkov | trying | 20:34 |
| jdstrand | sborovkov: after you do that, please stop and start your service (eg, sudo service snap.screenly-client.playlist stop ; sudo service screenly-client.playlist start | 20:35 |
| zyga | NicolinoCuralli: the mechanism is as I described, for development you should have one board with working ssh | 20:35 |
| jdstrand | sborovkov: and let me know if there are any more denials | 20:35 |
| jdstrand | sborovkov: whoops, I meant: sudo service snap.screenly-client.playlist stop ; sudo service snap.screenly-client.playlist start | 20:35 |
| sborovkov | jdstrand: why not just restart it? | 20:36 |
| sborovkov | is there any difference? | 20:36 |
| jdstrand | sborovkov: I just wanted to make sure of a clean start. it shouldn't matter | 20:36 |
| sborovkov | jdstrand: getting the same denial it seems. | 20:36 |
| jdstrand | sborovkov: you loaded the profile with apparmor_parser? | 20:37 |
| sborovkov | yes | 20:37 |
| jdstrand | sborovkov: can you paste the new denial as well as /var/lib/snapd/apparmor/profiles/snap.screenly-client.playlist? | 20:37 |
| sborovkov | jdstrand: sure one moment | 20:38 |
| jjohansen | Pharaoh_Atem, zyga, tyhicks: they exist again 4.10 in the bacport tree http://kernel.ubuntu.com/git/jj/linux-apparmor-backports/log/?h=v4.10-aa3.6-backport-base | 20:38 |
| jjohansen | I have not done an updated diff to 4.11 yet | 20:38 |
| NicolinoCuralli | zyga: i want to use snappy on a production environment : i tested it on my development board and i find that snapd don't upgrade automatically after publication on store ; what mean it? | 20:38 |
| sborovkov | jdstrand: Denial - https://hastebin.com/jahisohuba.scala apparmor file - https://hastebin.com/upuminowup.pl | 20:39 |
| jjohansen | the plan is to maintain a backwards/forwards port until everything lands upstream, then well just backports | 20:40 |
| jdstrand | sborovkov: oh, well, yes, the rule I gave was for 'receive', it should've been for send. let me rewrite the rule | 20:42 |
| Pharaoh_Atem | jjohansen: is aa3.6 referring to userspace utils version? | 20:45 |
| Pharaoh_Atem | I don't recall a 3.x series existing | 20:45 |
| sborovkov | jdstrand: after replacing receive with send it works. Or does it need more changes? | 20:45 |
| jjohansen | Pharaoh_Atem: no, its the versioning for the dev kernels | 20:46 |
| jdstrand | sborovkov: it needs an additional change. please remove that rule and try: http://paste.ubuntu.com/24308686/ | 20:46 |
| NicolinoCuralli | zyga: i would like understand that what happen is it a bug? how could I help you to understand? | 20:46 |
| jjohansen | Pharaoh_Atem: it wasn't supposed to be that way, and we will get back to things being more in sync, | 20:47 |
| Pharaoh_Atem | jjohansen: any idea on the timeline for that? as it is, I get pretty confused trying to figure out what I need for aa | 20:47 |
| sborovkov | jdstrand: done. it works. | 20:48 |
| jjohansen | Pharaoh_Atem: hrmmm, this year sometime, we have agreed in principle to spin a 4.0 release for userspace, and what goes into upstream will be referred to as 4.x | 20:49 |
| jdstrand | sborovkov: ok, this is a bug in snapd. I'll prepare a PR and respond to the list | 20:49 |
| sborovkov | jdstrand: thanks for your assistance! Is there some workaround meanwhile? | 20:49 |
| jdstrand | sborovkov: in the meantime, you can workaround the issue by adding that rule and loading the policy. note that snapd occasionally refreshes the security policy so your changes may disappear at any time | 20:49 |
| jjohansen | I am hoping for 4.13, for everything landed | 20:50 |
| jdstrand | jjohansen: everything? that would be awesome :) | 20:50 |
| sborovkov | jdstrand: hmm, I can't use that. Since we would distribute images created with ubuntu-image to clients who don't have access to it. Guess I will need to wait for snapd update. | 20:51 |
| Pharaoh_Atem | jjohansen: that would make things really nice | 20:51 |
| Pharaoh_Atem | openSUSE Leap will rebase on the next summer longterm kernel for 42.3 | 20:52 |
| Pharaoh_Atem | or actually, it might be frozen now, I'd have to check | 20:52 |
| jdstrand | sborovkov: like I said, I'll have the PR up in a few minutes and it should be in 2.24. you can go through your normal channels and see if someone wants to backport it to 2.23 | 20:52 |
| Pharaoh_Atem | but openSUSE Leap 43.1 and SLE 13 would be in good shape (both are under development now) | 20:52 |
| sborovkov | jdstrand: understood. thanks again :-) | 20:53 |
| jdstrand | sborovkov: I don't know the snappy team's plans for 2.23 update vs 2.24 otherwise I could be more specific | 20:53 |
| * jdstrand goes to fix the bug | 20:53 | |
| jjohansen | Pharaoh_Atem: I have been meaning to provide a kernel for suse in the obs, would that be of interest to you? | 20:55 |
| Pharaoh_Atem | jjohansen: for my purpose of figuring out AppArmor, yes | 20:55 |
| sborovkov | jdstrand: At least I can go to sleep knowing that this is going to be resolved. Just 5 minutes from midnight here :-) | 20:55 |
| Pharaoh_Atem | jjohansen: good news is, openSUSE maintains their kernel tree publicly in git, so you can work from it | 20:56 |
| jjohansen | Pharaoh_Atem: okay, I'll see what I can do sooner than later | 20:56 |
| Pharaoh_Atem | jjohansen: https://github.com/openSUSE/kernel-source | 20:56 |
| Pharaoh_Atem | https://github.com/openSUSE/kernel | 20:56 |
| jjohansen | Pharaoh_Atem: hehe, yeah I know though its only sort of git, they still use the old build patch queue system, they just shoved that into git. Well at least for the obs build sources I have played with, when building test kernels for cboltz | 20:57 |
| Pharaoh_Atem | jjohansen: yeah, it's really weird | 20:57 |
| jjohansen | its okay, I understand the old system, I used to work for suse on the kernel :) | 20:58 |
| Pharaoh_Atem | jjohansen: it's good someone understands it | 21:05 |
| Pharaoh_Atem | I certainly don't | 21:05 |
| mup | PR snapd#3133 opened: interfaces: allow slot to introspect dbus-daemon in dbus interface, allow /usr/bin/arch by default <Created by jdstrand> <https://github.com/snapcore/snapd/pull/3133> | 21:08 |
| jdstrand | ondra: fyi, https://github.com/snapcore/snapd/pull/3133 has the 'arch' fix | 21:11 |
| mup | PR snapd#3133: interfaces: allow slot to introspect dbus-daemon in dbus interface, allow /usr/bin/arch by default <Created by jdstrand> <https://github.com/snapcore/snapd/pull/3133> | 21:11 |
| zyga | niemeyer: any chanece for a re-review on https://github.com/snapcore/snapd/pull/3095 ? | 21:23 |
| mup | PR snapd#3095: cmd/snap-update-ns: add C preamble for setns <Created by zyga> <https://github.com/snapcore/snapd/pull/3095> | 21:23 |
| === JanC is now known as Guest6267 | ||
| === JanC_ is now known as JanC | ||
| ondra | jdstrand o/ thanks! | 21:32 |
| mup | PR snapd#3133 closed: interfaces: allow slot to introspect dbus-daemon in dbus interface, allow /usr/bin/arch by default <Created by jdstrand> <Merged by jdstrand> <https://github.com/snapcore/snapd/pull/3133> | 22:09 |
| mup | PR snapcraft#1229 opened: source: add bazaar tracking <Created by josepht> <https://github.com/snapcore/snapcraft/pull/1229> | 22:18 |
| mup | Bug #1679432 opened: Bluetooth SCO connections don't work on Dragonboard 410c <Snappy:New> <https://launchpad.net/bugs/1679432> | 23:36 |
| === wxl is now known as lubot | ||
| === lubot is now known as wxl | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!