[02:02] PR snapcraft#1276 closed: sources: validate unknown source-type in yaml [02:55] Bug #1688103 opened: Classic confinement should allow preservation of $HOME [03:26] PR snapcraft#1297 opened: sources: validate unknown source-type in yaml [03:35] PR snapcraft#1298 opened: Reroll of proposed JHBuild plugin === chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun [07:07] morning [07:33] good morning! [07:34] * zyga will be back soon, just overslept; [09:38] * Chipaca looks around for a zyga [09:59] PR snapcraft#1299 opened: asset-tracking: save the dependencies of build packages [10:38] niemeyer: yo [10:46] PR snapd#3266 closed: interfaces: allow plugging DBus clients to introspect the slot service [10:48] zyga: un zyga! [10:48] zyga: hello, you [10:48] Chipaca: hey, I was sleeping :/ [10:48] zyga: excellent [10:48] * zyga feels dizzy today, perhaps it is a sign to take a day off [10:49] zyga: if you're not feeling well, get out of here [10:49] zyga: don't want to get internet cooties [10:50] Chipaca: I just flet sleepy [10:50] I'll file half a day off and take it slow [10:50] zyga: how many hours did you sleep? [10:51] not sure, I just got back here [10:51] zyga: (if you're late from sleeping too much because the other days you were working late instead of sleeping, i don't think you should file half a day) [10:51] no, last night my daughter decided to stuff instead of behaving like a normal child, she was up way past 1AM [10:52] daughters gonna daught [10:53] haha [10:53] nice :) [10:55] zyga: i've addressed your concerns in etelpmoc i think [10:55] zyga: fwiw ${!x} is variable indirection [10:55] i.e. if $x is foo, ${!x} is $foo [10:55] indirection? so like ${${x}} ? [10:55] a [10:55] ah [10:55] wow [10:55] I didn't know that [10:55] * zyga does that in make but not in bash [10:55] * zyga hugs make [11:01] zyga: i suspect https://travis-ci.org/snapcore/snapd/builds/228530132?utm_source=github_status&utm_medium=notification is the hook timeout thing [11:01] Chipaca: looking [11:02] Chipaca: though it should no longer time out AFAIK [11:02] ha [11:02] * zyga looks at details [11:02] ah, yes [11:02] perhaps master is not merged into this yet? [11:06] zyga: that's correct, this is merging release/2.25 back into master [11:06] all it is is the changelogs [11:07] as such, I'm merging them even though travis is grumpy [11:07] zyga: ok? [11:07] agj! i can't [11:07] well... not on the website anyway [11:07] :-) [11:08] Chipaca: I think we can merge master into that branch [11:08] Chipaca: then it will merge [11:08] Chipaca: it's silly but should work [11:08] * zyga tries [11:08] zyga: i can do this [11:08] already have the branch [11:08] ok [11:09] Chipaca: question about the oldish PRs [11:09] Chipaca: I feel we should fork and close the old PRs where we cannot push into them directly [11:09] Chipaca: and take them over [11:09] there, merged master [11:09] Chipaca: thanks! [11:09] zyga: which ones can't we push into directly? [11:10] zyga: (yes, fork and close those, but which?) [11:11] Chipaca: those that do not belong to team members, e.g. https://github.com/snapcore/snapd/pull/2869 [11:11] PR snapd#2869: interfaces/builtin: add online-accounts-service interface [11:11] zyga: that one says i can push to it [11:12] Chipaca: oh? maybe bad example [11:12] * zyga looks [11:12] yes [11:12] they would've had to manually untick the "let team members push" for it to be the case [11:13] ah, that's good then [11:13] maybe it's a new thing; I didn't see this before on those branches [11:13] or maybe they ticked that back in between :) [11:13] zyga: what do you want to do with snapd#3264? [11:13] PR snapd#3264: tests: remove quoting from [[ ]] when globs [11:14] Chipaca: yeah, I'll look [11:14] Chipaca: I think you are right [11:14] Chipaca: and it might explain why it worked before [11:14] Chipaca: the test was buggy twice [11:14] zyga: morphis replied there [11:14] Chipaca: so it worked [11:14] Chipaca: oh, looking [11:14] hehe [11:15] haha [11:15] nice [11:15] morphis: thanks; I'll correct that [11:16] done [11:16] I'm still disappointed [[ doesn't properly ligature into 〚 [11:17] oh [11:17] it does :) [11:17] btw, I have to show this to you [11:17] if you like things like that [11:18] https://github.com/tonsky/FiraCode [11:18] there's a emacs mode that does that sort of thing when writing haskell [11:18] if you work in atom [11:18] it works in any language [11:18] and I must say it does look very pretty and readable [11:18] I use it [11:18] i tried atom, but no [11:18] muscle memory is a good thing to have, and it's wasted in atom [11:18] you can use any editor that can grok font features like that [11:19] (also, if i use emacs instead of atom, i can finally point at it and laugh about memory usage!) [11:19] it's juts that only atom did (for the set that I tried) [11:19] terminal is too dumb [11:19] and I bet emacs (which I dind't try, or I'd be still trying to close it ;-) can too [11:19] hahaha [11:19] well [11:19] I hate atom for constantly using 5-15% CPU [11:19] for whatever [11:20] and using 1.5GB of ram [11:20] closing emacs is really hard: File -> Quit [11:20] :-P [11:20] (but, yeah, muscle memory) [11:20] oh, it seems to work in kde kosole [11:20] I know ^C^X [11:20] or something like that [11:21] ^X^C [11:21] half of the time if i have to think of it i don't get it [11:21] like, the combo for making a paragraph of text justified to a certain width [11:21] I ran vim to try [11:21] vim prints :quit instructions if you do :) [11:22] I know how to use emacs but I just prefer vim [11:22] :-) [11:22] yeah [11:22] I know how to do that in vim but I cannot remember, I have to just do it by trying [11:22] yeap. And that's great :-) [11:22] so why waste it [11:23] anyway. lunch. [11:23] ok, we have 30 branches [11:23] I'm taking oldest one [11:23] ok, let's skip that one [11:23] I'll take 2nd oldest (mine) [11:24] * didrocks is really happy about Visual Studio Code for any Go development. Doesn't use (from my testing) as much memory or CPU that atom, more feature, and font ligature with Fira Code as mentioned ;) [11:28] didrocks: when it's in a snap i'll try it :-) [11:29] PR snapd#3270 opened: adjust Nice and oom_score levels for snapd [11:33] Chipaca: there's a snap [11:33] Chipaca: sergio uses it [11:33] didrocks: I love visual studio code btw [11:33] didrocks: I really wish some of the new editors could be used on windows with ubuntu for windows [11:33] (but if you do your files are wasted, poor implementation from microsoft) [11:36] zyga: yeah, I don't personnally have that issues, but indeed, this is one I imagine [11:38] didrocks: well, on real ubuntu I just use vim :) [11:39] * didrocks would miss sourcegraph on pure vim [11:40] * ogra_ is always annoyed ending up with all the ":wq"'s in non vim edited files :P [11:41] didrocks: what is sourcegraph? [11:41] hehe [11:42] PR snapd#3271 opened: cmd/snap-confine: use /etc/ssl from the core snap [11:42] zyga: ^^ [11:44] morphis: +1 [11:44] morphis: could we reuse the /etc/alternatives test [11:44] morphis: and use environment trick to multiply it? [11:44] morphis: I think it largely does this already [11:44] zyga: sure [11:44] morphis: can you please? [11:44] morphis: (feel free to rename it to something appropriate) [11:45] morphis: and this is very nice, it should fix docker on openssl! [11:45] er [11:45] opensuse :D [11:45] openthis openthat [11:45] docker and lxd :-) [11:46] zyga: there is something still wrong in the test, however enough for a first review :-) [11:51] zyga: https://sourcegraph.com/, you can look up for references, how certain APIs are used in the wild (on github in particular), have the documentation and referenced linked to any usage, even in a PR on GH [11:51] doesn't work in all languages, but quite awesome in Go :) [11:59] didrocks: interesting [12:02] Chipaca: question, I need to teach interfaces about "snap try" [12:02] Chipaca: we have snap.ConfinementType [12:03] Chipaca: but that doesn't feel quite right [12:03] zyga: tell me more -- why does snap try affect interfaces? [12:04] Chipaca: because in try mode on encrypted $HOME we need special internal snippet [12:04] Chipaca: I see that we also have interfaces.ConfinementOptions [12:04] Chipaca: and that feels good, it's a struct with booleans [12:04] try is not a confinement type [12:05] Chipaca: it's not a type [12:05] if you need it exposed, doing it via ConfinementOptions feels better, yes [12:05] Chipaca: (not ConfinementType, ConfinementOptions) [12:05] yeah [12:05] zyga: yeah, was responding to your "we have snap.ConfinementType" [12:05] I'll do that [12:05] right [12:05] IRC :) [12:05] thanks! [12:05] I didn't remember we have COptions [12:30] crypted home is funky [12:31] Chipaca: it's funny that all the work that went into update-ns can be reused from snapd now [12:31] Chipaca: (as in looking for mounted cyptfs in /home) [12:31] zyga: hilarious [12:31] Chipaca: well, unexpected benefit of writing it in go [12:32] :-) [12:32] i think i need a nap [12:32] * Chipaca grumpy [12:33] Chipaca: do! I feel better after! [12:33] Chipaca: siesta :) [12:41] Chipaca: still here? [12:42] * zyga traces the code from daemon to see what's happening [12:46] zyga: yes [12:48] Chipaca: I'm trying to grok if snap.Info is sufficient to know where snap try is coming from (where's the directory) [12:48] * zyga would like to have a nice "snap list --internal" or something that showes all the data without any transformation but with mimimal pretty printing [12:49] zyga: just hit the rest api :-) [12:49] http snapd:///v2/snaps/thesnap [12:49] ah [12:49] * zyga tries [12:50] hmm [12:50] zyga: the "trymode" in the rest api is gotten from snapstate [12:50] seems not :/ [12:50] I need the actual directory [12:50] ah! you need the actual directory? [12:51] yep [12:51] I might infer that from bind mount data [12:51] but scary [12:52] * zyga looks at state [12:52] Son_Goku: Heya [12:53] Hi all [12:53] yo [12:53] Chipaca: ah, we dont store that at all! [12:53] Chipaca: it's thrown out after the change is done [12:53] hey niemeyer [12:53] zyga: it's SnapPath in the SnapSetup [12:54] Chipaca: yes but that's in a change [12:54] Chipaca: not in the state :/ [12:54] Chipaca: (snap state) [12:56] niemeyer: hey, so the snappy sprint date sounds good to me [12:56] but I need to first see if I can get the vacation block ;) [12:56] Son_Goku: Sounds good, fingers crossed [13:00] zyga: sounds like maybe we should store it in there if it's needed [13:00] zyga: any idea why I get: [ 306.778066] audit: type=1400 audit(1493902786.616:133): apparmor="DENIED" operation="mkdir" profile="/usr/lib/snapd/snap-confine" name="/run/snapd/lock/" pid=8144 comm="snap-confine" requested_mask="c" denied_mask="c" fsuid=0 ouid=0 [13:01] zyga: that is with my PR and latest snap-confine from master [13:03] morphis: can you join our standup maybe? [13:03] zyga: in another meeting right now [13:03] PR snapd#3249 closed: releasing package snapd version 2.25 [13:04] zyga: anything important or you just want to talk about the error above? [13:04] morphis: no, just wanted to have you in our standup [13:04] zyga: ah :-) [13:04] zyga: then feel free to put me on the attendees list [13:05] if we're over here soon I will join [13:05] ok [13:05] I cannot do that thou [13:11] morphis, i think zyga meant "join it on a regular base" ... is the meeting you have right noow reguar at this time ? [13:12] ogra_: just every thursday, ever other day is fine [13:12] ah, cool [13:16] fgimenez: so the logs there have little information, perhaps the test needs to be tweaked to connect plugs/start docker some way? [13:16] * zyga is unsure [13:16] zyga: not sure, running in qemu right now, will let you know how it goes [13:19] zyga: looks like a timing issue, from the debug console after the error "docker info" works just fine http://paste.ubuntu.com/24511102/ [13:20] yeah, it looks ok [13:20] I wonder if this is intentional: Debug Mode (server): true [13:32] is full of references to meta/snap.yaml. Is that (a) an old name for snapcraft.yaml, (b) a replacement for snapcraft.yaml, or (c) something else entirely? [13:33] mpt, c [13:33] mpt: c, it's a file read by snapd [13:33] mpt: it's a file that describes a built snap [13:33] aha [13:34] davidcalle, zyga: Thanks. So does snapcraft (for example) produce the meta/snap.yaml as part of its output? [13:34] kyleN: are you around? [13:35] sorr, i meant kyrofa [13:35] mpt, it's part of the produced snap [13:35] mpt: yes [13:35] mpt: it should be in prime/ === chihchun is now known as chihchun_afk === jospoortvliet_ is now known as jospoortvliet [13:41] zyga, so meta/ is old-and-busted, and prime/ is new-hotness? [13:41] mpt: no [13:42] mpt: after you build something with snapcraft you should be able to see the unpacked snap in prime [13:42] mpt: including snap.yaml in prime/meta/snap.yaml [13:42] mpt: sorry, I didn't mean to imply that it is in a wrong place [13:42] zyga, ok, so if snapcraft isn’t involved then there’s no prime/ directory? [13:43] zyga: I am struggeling a bit to work with a self-build snap-confine, what is the best way to test one? just running $ make hack? [13:44] mpt: yes [13:44] mpt: prime is just a way that snapcraft implements its internal things [13:45] mpt: snapd only looks at the build artefacts that are placed into the squashfs [13:45] morphis: yes [13:45] morphis: make hack works wonders :) [13:45] * zyga uses it all the time [13:45] morphis: note that you need to bind mount it to core too [13:45] morphis: or use the version that ties this into the reexec flag [13:45] morphis: or snapd will still load snap-confine from core [13:45] zyga, understood, thank you. (Asking these questions because I have the job of reviewing+tweaking the snapcraft.io front page.) [13:47] mpt: great, I'm glad to help [13:47] jdstrand: hey, do you remember by any chance how 14.04 style encrypted home directory looked like [13:47] jdstrand: what kind of filesystem was thta? [13:47] * zyga looks for 14.04 iso [13:51] zyga: something like `SNAP_REEXEC=0 snap run --shell hello-world` shoudl work? [13:51] morphis: perhaps, just check if SNAP_REEXEC is the right variable [13:51] morphis: or just to be sure [13:52] morphis: bind mount snap-confine from distro over that in core [13:52] morphis: then it always works [13:52] zyga: if I add printf statements in snap-confine, should I see the output? [13:53] PR snapd#3272 opened: add interfaces-shutdown-introspection spread test [13:53] morphis: yes [13:53] btw I was looking at systemd apis [13:54] I may start using them to log errors [13:54] they are really lovely! [13:54] zyga: like on all releases, it is a stacked filesystem [13:54] jdstrand: right but I recall it was different in 14.04 [13:54] I checked how it looks like in 16.04 [13:54] zyga: you mean the apparmor paths? [13:54] jdstrand: no, I mean how it is reapresented [13:55] jdstrand: I want to look through the mount tables to check if there's an encrypted home in use [13:55] zyga: what you are describing I don't know what you are talking about. I know this: [13:55] # encrypted ~/.Private and old-style encrypted $HOME [13:55] owner @{HOME}/.Private/** mrixwlk, [13:55] # new-style encrypted $HOME [13:55] owner @{HOMEDIRS}/.ecryptfs/*/.Private/** mrixwlk, [13:55] jdstrand: I know that too :) [13:55] jdstrand: on 16.04 there's en "ecryptfs" mounted [13:55] jdstrand: what is used on 14.04? [13:55] * zyga checks anywy [13:56] jdstrand: no worries, I'll find out soon enough :) [13:56] zyga: so if it is other than that, 'no, I don't remember' (I never knew ;) [13:56] zyga: you might ask Tyler (he is sprinting) if you can't get to the bottom of it [13:56] nah I will know in 15 minutes [13:57] just installing 14.04 [13:57] Chipaca: question/suggestion, I think we ought to track "snap-try" origin in state [13:57] Chipaca: now where is the question? in side-info? feels icky [13:58] morphis: to answer your question, your denial for 'c' on '/run/snapd/lock/' is because in whatever mount namespace snap-confine is currently running in, that dir doesn't exist [13:59] jdstrand: hm [13:59] morphis: ah, you may need to do one more thing [13:59] morphis: you may need to bind mount the apparmor profile [13:59] jdstrand: I got that with a simple $ snap run --shell [13:59] morphis: from the distro onto the core snap [13:59] zyga: bind mount? [13:59] morphis: then restart snapd [13:59] morphis: what distro? [13:59] jdstrand: Ubuntu 16.04 but with a self-build snap-confine [13:59] * jdstrand wonders why people are bind mounting apparmor profiles... [14:00] morphis: mount --bind /etc/apparmor.d/usr.lib.snapd.snap-confine.real /snap/core/current/etc/apparmor.d/usr.lib.snapd.snap-confine.real [14:00] ah [14:00] jdstrand: deelopment [14:00] ;) [14:00] yes [14:00] :D [14:00] zyga: why is that needed at all? [14:00] zyga: (thinking) [14:00] if I set SNAP_REEXEC=0 [14:00] morphis: because snapd creates a new profile at runtime [14:00] morphis: any SNAP_REEXEC is probably not working :) [14:00] (just guessing) [14:00] I bet it's not working and then you get the wrong snap-confine and the wrong profle [14:00] zyga: when I call $ snap run --shell .. how is snapd then involved? [14:00] if it did work you would not need to bind mount anything [14:01] morphis: snapd compiles the apparmor profile of snap-confine from core on startup [14:01] morphis: maaaagic ;) [14:01] morphis: look at /etc/apparmor.d [14:01] zyga: hm, I have snapd already running, calling `make hack` and then immediately `snap run --shell` afterwards [14:02] morphis: do the bind mount [14:02] morphis: reload snapd [14:02] morphis: it'll work [14:02] or check what really controls reexec [14:02] morphis: to be more clear. if there is a bug in reexec, then snapd is loading the profile from /snap/core/current/etc/apparmor.d/... and not one that you may have loaded [14:02] morphis: AFAIR there's a patch that fixes some of that (maybe reexec is unconditional) [14:02] morphis: so if you bind mount over the one in /snap/core, you trick snapd to load your profile [14:03] jdstrand, zyga: I still don't get how snapd is involved when I run $ snap run --shell [14:03] morphis: it isnt [14:03] morphis: but ... if snap run doesn't grok reexec feature [14:03] morphis: and for whatever reason goes to "reexec" (not really) by running snap-confine from the core snap [14:03] from what I read in the code it shouldn't with SNAP_REEXEC=0 [14:03] morphis: then the apparmor profile for snap-confine in the core snap applies [14:04] morphis: well, debug away :) [14:04] morphis: note: snap also reexecs [14:04] morphis: so your snap reexes into core "snap" then runs snap-confine from either core or distro [14:04] morphis: like zyga says, it doesn't. but, if you restart snapd for some reason and this reexec logic isn't right, then the profile in /snap/core gets loading into the kernel [14:04] ok, I see [14:04] morphis: and to finish that sentence, snapd on startup generates and loads the apparmor profile for snap-confine based on what is stored in the core snap [14:05] morphis: (for the snap-confine from /snap/core/123/usr/lib/snaps/snap-confine) [14:05] morphis: you should be able to apparmor_parser -r /path/to/the/profile/you/want/loaded and *not* restart snapd and have it work too [14:05] morphis: each copy of snap-confine has a distinct profile [14:05] * jdstrand is assuming there is a bug in reexec, as zyga guessed [14:08] zyga, jdstrand: ok leaving the profile beside, I've added a few printf statements to my self-build snap-confine binary and then don't show up when I run snap run, bind mounts in place etc. [14:09] morphis: does it show when you run it manually? [14:09] morphis: did you forget to make hack again? [14:09] morphis: note that after you bind mount I think make hack does weired stuff [14:09] morphis: not sure [14:10] weird* [14:10] morphis: also journal has useful hints on reexec [14:13] zyga: no I didn't, also verified with strace, however let me play a bit more [14:13] hi [14:13] I'm trying to package an app that requires a specific udev rule [14:13] is there support for that? [14:19] pcercuei: can you tell me more about the rule [14:19] pcercuei: it is possible but it requires an interface [14:19] pcercuei: that is merged in upstream snapd [14:22] SUBSYSTEM=="usb", PROGRAM=="/bin/sh -c '/usr/bin/iio_info -s | grep %s{idVendor}:%s{idProduct}'", RESULT!="", TAG+="uaccess" [14:23] that's my rule right now. "iio_info -s" scans the compatible USB devices, the udev rule gives users access to those [14:23] the 'iio_info' tool would be inside my snap [14:23] pcercuei: hmm, that would not work then [14:23] (we don't have support for running helper progams from snaps) [14:23] I can change the rule for a standard idVendor/idProduct check without calling an external program [14:24] but we may have something else... [14:24] pcercuei: so [14:24] pcercuei: do you have your own gadget snap? [14:24] pcercuei: we have the iio interface [14:24] pcercuei: your gadget can describe such devices [14:25] pcercuei: and then your app can have a plug to consume it [14:25] it's a bit more complicated than that [14:25] pcercuei: note that I have no idea what iio is in practice, I read the kernel docs about that a while ago but I never tried using anything like that [14:26]