| mup | PR snapcraft#1276 closed: sources: validate unknown source-type in yaml <Created by EduardoVega> <Closed by EduardoVega> <https://github.com/snapcore/snapcraft/pull/1276> | 02:02 |
|---|---|---|
| mup | Bug #1688103 opened: Classic confinement should allow preservation of $HOME <Snapcraft:New> <Snappy:New> <https://launchpad.net/bugs/1688103> | 02:55 |
| mup | PR snapcraft#1297 opened: sources: validate unknown source-type in yaml <Created by EduardoVega> <https://github.com/snapcore/snapcraft/pull/1297> | 03:26 |
| mup | PR snapcraft#1298 opened: Reroll of proposed JHBuild plugin <Created by diddledan> <https://github.com/snapcore/snapcraft/pull/1298> | 03:35 |
| === chihchun_afk is now known as chihchun | ||
| === chihchun is now known as chihchun_afk | ||
| === chihchun_afk is now known as chihchun | ||
| pstolowski | morning | 07:07 |
| zyga | good morning! | 07:33 |
| * zyga will be back soon, just overslept; | 07:34 | |
| * Chipaca looks around for a zyga | 09:38 | |
| mup | PR snapcraft#1299 opened: asset-tracking: save the dependencies of build packages <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1299> | 09:59 |
| Son_Goku | niemeyer: yo | 10:38 |
| mup | PR snapd#3266 closed: interfaces: allow plugging DBus clients to introspect the slot service <Created by jdstrand> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3266> | 10:46 |
| Chipaca | zyga: un zyga! | 10:48 |
| Chipaca | zyga: hello, you | 10:48 |
| zyga | Chipaca: hey, I was sleeping :/ | 10:48 |
| Chipaca | zyga: excellent | 10:48 |
| * zyga feels dizzy today, perhaps it is a sign to take a day off | 10:48 | |
| Chipaca | zyga: if you're not feeling well, get out of here | 10:49 |
| Chipaca | zyga: don't want to get internet cooties | 10:49 |
| zyga | Chipaca: I just flet sleepy | 10:50 |
| zyga | I'll file half a day off and take it slow | 10:50 |
| Chipaca | zyga: how many hours did you sleep? | 10:50 |
| zyga | not sure, I just got back here | 10:51 |
| Chipaca | 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 |
| zyga | no, last night my daughter decided to stuff instead of behaving like a normal child, she was up way past 1AM | 10:51 |
| Chipaca | daughters gonna daught | 10:52 |
| zyga | haha | 10:53 |
| zyga | nice :) | 10:53 |
| Chipaca | zyga: i've addressed your concerns in etelpmoc i think | 10:55 |
| Chipaca | zyga: fwiw ${!x} is variable indirection | 10:55 |
| Chipaca | i.e. if $x is foo, ${!x} is $foo | 10:55 |
| zyga | indirection? so like ${${x}} ? | 10:55 |
| zyga | a | 10:55 |
| zyga | ah | 10:55 |
| zyga | wow | 10:55 |
| zyga | I didn't know that | 10:55 |
| * zyga does that in make but not in bash | 10:55 | |
| * zyga hugs make | 10:55 | |
| Chipaca | 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 |
| zyga | Chipaca: looking | 11:01 |
| zyga | Chipaca: though it should no longer time out AFAIK | 11:02 |
| zyga | ha | 11:02 |
| * zyga looks at details | 11:02 | |
| zyga | ah, yes | 11:02 |
| zyga | perhaps master is not merged into this yet? | 11:02 |
| Chipaca | zyga: that's correct, this is merging release/2.25 back into master | 11:06 |
| Chipaca | all it is is the changelogs | 11:06 |
| Chipaca | as such, I'm merging them even though travis is grumpy | 11:07 |
| Chipaca | zyga: ok? | 11:07 |
| Chipaca | agj! i can't | 11:07 |
| Chipaca | well... not on the website anyway | 11:07 |
| Chipaca | :-) | 11:07 |
| zyga | Chipaca: I think we can merge master into that branch | 11:08 |
| zyga | Chipaca: then it will merge | 11:08 |
| zyga | Chipaca: it's silly but should work | 11:08 |
| * zyga tries | 11:08 | |
| Chipaca | zyga: i can do this | 11:08 |
| Chipaca | already have the branch | 11:08 |
| zyga | ok | 11:08 |
| zyga | Chipaca: question about the oldish PRs | 11:09 |
| zyga | Chipaca: I feel we should fork and close the old PRs where we cannot push into them directly | 11:09 |
| zyga | Chipaca: and take them over | 11:09 |
| Chipaca | there, merged master | 11:09 |
| zyga | Chipaca: thanks! | 11:09 |
| Chipaca | zyga: which ones can't we push into directly? | 11:09 |
| Chipaca | zyga: (yes, fork and close those, but which?) | 11:10 |
| zyga | Chipaca: those that do not belong to team members, e.g. https://github.com/snapcore/snapd/pull/2869 | 11:11 |
| mup | PR snapd#2869: interfaces/builtin: add online-accounts-service interface <Created by mardy> <https://github.com/snapcore/snapd/pull/2869> | 11:11 |
| Chipaca | zyga: that one says i can push to it | 11:11 |
| zyga | Chipaca: oh? maybe bad example | 11:12 |
| * zyga looks | 11:12 | |
| zyga | yes | 11:12 |
| Chipaca | they would've had to manually untick the "let team members push" for it to be the case | 11:12 |
| zyga | ah, that's good then | 11:13 |
| zyga | maybe it's a new thing; I didn't see this before on those branches | 11:13 |
| zyga | or maybe they ticked that back in between :) | 11:13 |
| Chipaca | zyga: what do you want to do with snapd#3264? | 11:13 |
| mup | PR snapd#3264: tests: remove quoting from [[ ]] when globs <Created by zyga> <https://github.com/snapcore/snapd/pull/3264> | 11:13 |
| zyga | Chipaca: yeah, I'll look | 11:14 |
| zyga | Chipaca: I think you are right | 11:14 |
| zyga | Chipaca: and it might explain why it worked before | 11:14 |
| zyga | Chipaca: the test was buggy twice | 11:14 |
| Chipaca | zyga: morphis replied there | 11:14 |
| zyga | Chipaca: so it worked | 11:14 |
| zyga | Chipaca: oh, looking | 11:14 |
| Chipaca | hehe | 11:14 |
| zyga | haha | 11:15 |
| zyga | nice | 11:15 |
| zyga | morphis: thanks; I'll correct that | 11:15 |
| zyga | done | 11:16 |
| Chipaca | I'm still disappointed [[ doesn't properly ligature into 〚 | 11:16 |
| zyga | oh | 11:17 |
| zyga | it does :) | 11:17 |
| zyga | btw, I have to show this to you | 11:17 |
| zyga | if you like things like that | 11:17 |
| zyga | https://github.com/tonsky/FiraCode | 11:18 |
| Chipaca | there's a emacs mode that does that sort of thing when writing haskell | 11:18 |
| zyga | if you work in atom | 11:18 |
| zyga | it works in any language | 11:18 |
| zyga | and I must say it does look very pretty and readable | 11:18 |
| zyga | I use it | 11:18 |
| Chipaca | i tried atom, but no | 11:18 |
| Chipaca | muscle memory is a good thing to have, and it's wasted in atom | 11:18 |
| zyga | you can use any editor that can grok font features like that | 11:18 |
| Chipaca | (also, if i use emacs instead of atom, i can finally point at it and laugh about memory usage!) | 11:19 |
| zyga | it's juts that only atom did (for the set that I tried) | 11:19 |
| zyga | terminal is too dumb | 11:19 |
| zyga | and I bet emacs (which I dind't try, or I'd be still trying to close it ;-) can too | 11:19 |
| zyga | hahaha | 11:19 |
| zyga | well | 11:19 |
| zyga | I hate atom for constantly using 5-15% CPU | 11:19 |
| zyga | for whatever | 11:19 |
| zyga | and using 1.5GB of ram | 11:20 |
| Chipaca | closing emacs is really hard: File -> Quit | 11:20 |
| Chipaca | :-P | 11:20 |
| Chipaca | (but, yeah, muscle memory) | 11:20 |
| zyga | oh, it seems to work in kde kosole | 11:20 |
| zyga | I know ^C^X | 11:20 |
| zyga | or something like that | 11:20 |
| zyga | ^X^C | 11:21 |
| Chipaca | half of the time if i have to think of it i don't get it | 11:21 |
| Chipaca | like, the combo for making a paragraph of text justified to a certain width | 11:21 |
| zyga | I ran vim to try | 11:21 |
| zyga | vim prints :quit instructions if you do :) | 11:21 |
| zyga | I know how to use emacs but I just prefer vim | 11:22 |
| Chipaca | :-) | 11:22 |
| zyga | yeah | 11:22 |
| zyga | I know how to do that in vim but I cannot remember, I have to just do it by trying | 11:22 |
| Chipaca | yeap. And that's great :-) | 11:22 |
| Chipaca | so why waste it | 11:22 |
| Chipaca | anyway. lunch. | 11:23 |
| zyga | ok, we have 30 branches | 11:23 |
| zyga | I'm taking oldest one | 11:23 |
| zyga | ok, let's skip that one | 11:23 |
| zyga | I'll take 2nd oldest (mine) | 11:23 |
| * 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:24 | |
| Chipaca | didrocks: when it's in a snap i'll try it :-) | 11:28 |
| mup | PR snapd#3270 opened: adjust Nice and oom_score levels for snapd <Created by ogra1> <https://github.com/snapcore/snapd/pull/3270> | 11:29 |
| zyga | Chipaca: there's a snap | 11:33 |
| zyga | Chipaca: sergio uses it | 11:33 |
| zyga | didrocks: I love visual studio code btw | 11:33 |
| zyga | didrocks: I really wish some of the new editors could be used on windows with ubuntu for windows | 11:33 |
| zyga | (but if you do your files are wasted, poor implementation from microsoft) | 11:33 |
| didrocks | zyga: yeah, I don't personnally have that issues, but indeed, this is one I imagine | 11:36 |
| zyga | didrocks: well, on real ubuntu I just use vim :) | 11:38 |
| * didrocks would miss sourcegraph on pure vim | 11:39 | |
| * ogra_ is always annoyed ending up with all the ":wq"'s in non vim edited files :P | 11:40 | |
| zyga | didrocks: what is sourcegraph? | 11:41 |
| zyga | hehe | 11:41 |
| mup | PR snapd#3271 opened: cmd/snap-confine: use /etc/ssl from the core snap <Created by morphis> <https://github.com/snapcore/snapd/pull/3271> | 11:42 |
| morphis | zyga: ^^ | 11:42 |
| zyga | morphis: +1 | 11:44 |
| zyga | morphis: could we reuse the /etc/alternatives test | 11:44 |
| zyga | morphis: and use environment trick to multiply it? | 11:44 |
| zyga | morphis: I think it largely does this already | 11:44 |
| morphis | zyga: sure | 11:44 |
| zyga | morphis: can you please? | 11:44 |
| zyga | morphis: (feel free to rename it to something appropriate) | 11:44 |
| zyga | morphis: and this is very nice, it should fix docker on openssl! | 11:45 |
| zyga | er | 11:45 |
| zyga | opensuse :D | 11:45 |
| zyga | openthis openthat | 11:45 |
| morphis | docker and lxd :-) | 11:45 |
| morphis | zyga: there is something still wrong in the test, however enough for a first review :-) | 11:46 |
| didrocks | 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 |
| didrocks | doesn't work in all languages, but quite awesome in Go :) | 11:51 |
| zyga | didrocks: interesting | 11:59 |
| zyga | Chipaca: question, I need to teach interfaces about "snap try" | 12:02 |
| zyga | Chipaca: we have snap.ConfinementType | 12:02 |
| zyga | Chipaca: but that doesn't feel quite right | 12:03 |
| Chipaca | zyga: tell me more -- why does snap try affect interfaces? | 12:03 |
| zyga | Chipaca: because in try mode on encrypted $HOME we need special internal snippet | 12:04 |
| zyga | Chipaca: I see that we also have interfaces.ConfinementOptions | 12:04 |
| zyga | Chipaca: and that feels good, it's a struct with booleans | 12:04 |
| Chipaca | try is not a confinement type | 12:04 |
| zyga | Chipaca: it's not a type | 12:05 |
| Chipaca | if you need it exposed, doing it via ConfinementOptions feels better, yes | 12:05 |
| zyga | Chipaca: (not ConfinementType, ConfinementOptions) | 12:05 |
| zyga | yeah | 12:05 |
| Chipaca | zyga: yeah, was responding to your "we have snap.ConfinementType" | 12:05 |
| zyga | I'll do that | 12:05 |
| zyga | right | 12:05 |
| zyga | IRC :) | 12:05 |
| zyga | thanks! | 12:05 |
| zyga | I didn't remember we have COptions | 12:05 |
| zyga | crypted home is funky | 12:30 |
| zyga | Chipaca: it's funny that all the work that went into update-ns can be reused from snapd now | 12:31 |
| zyga | Chipaca: (as in looking for mounted cyptfs in /home) | 12:31 |
| Chipaca | zyga: hilarious | 12:31 |
| zyga | Chipaca: well, unexpected benefit of writing it in go | 12:31 |
| Chipaca | :-) | 12:32 |
| Chipaca | i think i need a nap | 12:32 |
| * Chipaca grumpy | 12:32 | |
| zyga | Chipaca: do! I feel better after! | 12:33 |
| zyga | Chipaca: siesta :) | 12:33 |
| zyga | Chipaca: still here? | 12:41 |
| * zyga traces the code from daemon to see what's happening | 12:42 | |
| Chipaca | zyga: yes | 12:46 |
| zyga | 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:48 | |
| Chipaca | zyga: just hit the rest api :-) | 12:49 |
| Chipaca | http snapd:///v2/snaps/thesnap | 12:49 |
| zyga | ah | 12:49 |
| * zyga tries | 12:49 | |
| zyga | hmm | 12:50 |
| Chipaca | zyga: the "trymode" in the rest api is gotten from snapstate | 12:50 |
| zyga | seems not :/ | 12:50 |
| zyga | I need the actual directory | 12:50 |
| Chipaca | ah! you need the actual directory? | 12:50 |
| zyga | yep | 12:51 |
| zyga | I might infer that from bind mount data | 12:51 |
| zyga | but scary | 12:51 |
| * zyga looks at state | 12:52 | |
| niemeyer | Son_Goku: Heya | 12:52 |
| niemeyer | Hi all | 12:53 |
| ogra_ | yo | 12:53 |
| zyga | Chipaca: ah, we dont store that at all! | 12:53 |
| zyga | Chipaca: it's thrown out after the change is done | 12:53 |
| zyga | hey niemeyer | 12:53 |
| Chipaca | zyga: it's SnapPath in the SnapSetup | 12:53 |
| zyga | Chipaca: yes but that's in a change | 12:54 |
| zyga | Chipaca: not in the state :/ | 12:54 |
| zyga | Chipaca: (snap state) | 12:54 |
| Son_Goku | niemeyer: hey, so the snappy sprint date sounds good to me | 12:56 |
| Son_Goku | but I need to first see if I can get the vacation block ;) | 12:56 |
| niemeyer | Son_Goku: Sounds good, fingers crossed | 12:56 |
| Chipaca | zyga: sounds like maybe we should store it in there if it's needed | 13:00 |
| morphis | 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:00 |
| morphis | zyga: that is with my PR and latest snap-confine from master | 13:01 |
| zyga | morphis: can you join our standup maybe? | 13:03 |
| morphis | zyga: in another meeting right now | 13:03 |
| mup | PR snapd#3249 closed: releasing package snapd version 2.25 <Created by mvo5> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/3249> | 13:03 |
| morphis | zyga: anything important or you just want to talk about the error above? | 13:04 |
| zyga | morphis: no, just wanted to have you in our standup | 13:04 |
| morphis | zyga: ah :-) | 13:04 |
| morphis | zyga: then feel free to put me on the attendees list | 13:04 |
| morphis | if we're over here soon I will join | 13:05 |
| zyga | ok | 13:05 |
| zyga | I cannot do that thou | 13:05 |
| ogra_ | morphis, i think zyga meant "join it on a regular base" ... is the meeting you have right noow reguar at this time ? | 13:11 |
| morphis | ogra_: just every thursday, ever other day is fine | 13:12 |
| ogra_ | ah, cool | 13:12 |
| zyga | 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 | |
| fgimenez | zyga: not sure, running in qemu right now, will let you know how it goes | 13:16 |
| fgimenez | zyga: looks like a timing issue, from the debug console after the error "docker info" works just fine http://paste.ubuntu.com/24511102/ | 13:19 |
| zyga | yeah, it looks ok | 13:20 |
| zyga | I wonder if this is intentional: Debug Mode (server): true | 13:20 |
| mpt | <https://snapcraft.io/> 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:32 |
| davidcalle | mpt, c | 13:33 |
| zyga | mpt: c, it's a file read by snapd | 13:33 |
| zyga | mpt: it's a file that describes a built snap | 13:33 |
| mpt | aha | 13:33 |
| mpt | davidcalle, zyga: Thanks. So does snapcraft (for example) produce the meta/snap.yaml as part of its output? | 13:34 |
| pachulo | kyleN: are you around? | 13:34 |
| pachulo | sorr, i meant kyrofa | 13:35 |
| davidcalle | mpt, it's part of the produced snap | 13:35 |
| zyga | mpt: yes | 13:35 |
| zyga | mpt: it should be in prime/ | 13:35 |
| === chihchun is now known as chihchun_afk | ||
| === jospoortvliet_ is now known as jospoortvliet | ||
| mpt | zyga, so meta/ is old-and-busted, and prime/ is new-hotness? | 13:41 |
| zyga | mpt: no | 13:41 |
| zyga | mpt: after you build something with snapcraft you should be able to see the unpacked snap in prime | 13:42 |
| zyga | mpt: including snap.yaml in prime/meta/snap.yaml | 13:42 |
| zyga | mpt: sorry, I didn't mean to imply that it is in a wrong place | 13:42 |
| mpt | zyga, ok, so if snapcraft isn’t involved then there’s no prime/ directory? | 13:42 |
| morphis | 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:43 |
| zyga | mpt: yes | 13:44 |
| zyga | mpt: prime is just a way that snapcraft implements its internal things | 13:44 |
| zyga | mpt: snapd only looks at the build artefacts that are placed into the squashfs | 13:45 |
| zyga | morphis: yes | 13:45 |
| zyga | morphis: make hack works wonders :) | 13:45 |
| * zyga uses it all the time | 13:45 | |
| zyga | morphis: note that you need to bind mount it to core too | 13:45 |
| zyga | morphis: or use the version that ties this into the reexec flag | 13:45 |
| zyga | morphis: or snapd will still load snap-confine from core | 13:45 |
| mpt | zyga, understood, thank you. (Asking these questions because I have the job of reviewing+tweaking the snapcraft.io front page.) | 13:45 |
| zyga | mpt: great, I'm glad to help | 13:47 |
| zyga | jdstrand: hey, do you remember by any chance how 14.04 style encrypted home directory looked like | 13:47 |
| zyga | jdstrand: what kind of filesystem was thta? | 13:47 |
| * zyga looks for 14.04 iso | 13:47 | |
| morphis | zyga: something like `SNAP_REEXEC=0 snap run --shell hello-world` shoudl work? | 13:51 |
| zyga | morphis: perhaps, just check if SNAP_REEXEC is the right variable | 13:51 |
| zyga | morphis: or just to be sure | 13:51 |
| zyga | morphis: bind mount snap-confine from distro over that in core | 13:52 |
| zyga | morphis: then it always works | 13:52 |
| morphis | zyga: if I add printf statements in snap-confine, should I see the output? | 13:52 |
| mup | PR snapd#3272 opened: add interfaces-shutdown-introspection spread test <Created by jdstrand> <https://github.com/snapcore/snapd/pull/3272> | 13:53 |
| zyga | morphis: yes | 13:53 |
| zyga | btw I was looking at systemd apis | 13:53 |
| zyga | I may start using them to log errors | 13:54 |
| zyga | they are really lovely! | 13:54 |
| jdstrand | zyga: like on all releases, it is a stacked filesystem | 13:54 |
| zyga | jdstrand: right but I recall it was different in 14.04 | 13:54 |
| zyga | I checked how it looks like in 16.04 | 13:54 |
| jdstrand | zyga: you mean the apparmor paths? | 13:54 |
| zyga | jdstrand: no, I mean how it is reapresented | 13:54 |
| zyga | jdstrand: I want to look through the mount tables to check if there's an encrypted home in use | 13:55 |
| jdstrand | zyga: what you are describing I don't know what you are talking about. I know this: | 13:55 |
| jdstrand | # encrypted ~/.Private and old-style encrypted $HOME | 13:55 |
| jdstrand | owner @{HOME}/.Private/** mrixwlk, | 13:55 |
| jdstrand | # new-style encrypted $HOME | 13:55 |
| jdstrand | owner @{HOMEDIRS}/.ecryptfs/*/.Private/** mrixwlk, | 13:55 |
| zyga | jdstrand: I know that too :) | 13:55 |
| zyga | jdstrand: on 16.04 there's en "ecryptfs" mounted | 13:55 |
| zyga | jdstrand: what is used on 14.04? | 13:55 |
| * zyga checks anywy | 13:55 | |
| zyga | jdstrand: no worries, I'll find out soon enough :) | 13:56 |
| jdstrand | zyga: so if it is other than that, 'no, I don't remember' (I never knew ;) | 13:56 |
| jdstrand | zyga: you might ask Tyler (he is sprinting) if you can't get to the bottom of it | 13:56 |
| zyga | nah I will know in 15 minutes | 13:56 |
| zyga | just installing 14.04 | 13:57 |
| zyga | Chipaca: question/suggestion, I think we ought to track "snap-try" origin in state | 13:57 |
| zyga | Chipaca: now where is the question? in side-info? feels icky | 13:57 |
| jdstrand | 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:58 |
| morphis | jdstrand: hm | 13:59 |
| zyga | morphis: ah, you may need to do one more thing | 13:59 |
| zyga | morphis: you may need to bind mount the apparmor profile | 13:59 |
| morphis | jdstrand: I got that with a simple $ snap run --shell | 13:59 |
| zyga | morphis: from the distro onto the core snap | 13:59 |
| morphis | zyga: bind mount? | 13:59 |
| zyga | morphis: then restart snapd | 13:59 |
| jdstrand | morphis: what distro? | 13:59 |
| morphis | jdstrand: Ubuntu 16.04 but with a self-build snap-confine | 13:59 |
| * jdstrand wonders why people are bind mounting apparmor profiles... | 13:59 | |
| zyga | 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 |
| jdstrand | ah | 14:00 |
| zyga | jdstrand: deelopment | 14:00 |
| zyga | ;) | 14:00 |
| jdstrand | yes | 14:00 |
| zyga | :D | 14:00 |
| morphis | zyga: why is that needed at all? | 14:00 |
| Chipaca | zyga: (thinking) | 14:00 |
| morphis | if I set SNAP_REEXEC=0 | 14:00 |
| zyga | morphis: because snapd creates a new profile at runtime | 14:00 |
| zyga | morphis: any SNAP_REEXEC is probably not working :) | 14:00 |
| zyga | (just guessing) | 14:00 |
| zyga | I bet it's not working and then you get the wrong snap-confine and the wrong profle | 14:00 |
| morphis | zyga: when I call $ snap run --shell .. how is snapd then involved? | 14:00 |
| zyga | if it did work you would not need to bind mount anything | 14:00 |
| zyga | morphis: snapd compiles the apparmor profile of snap-confine from core on startup | 14:01 |
| zyga | morphis: maaaagic ;) | 14:01 |
| zyga | morphis: look at /etc/apparmor.d | 14:01 |
| morphis | zyga: hm, I have snapd already running, calling `make hack` and then immediately `snap run --shell` afterwards | 14:01 |
| zyga | morphis: do the bind mount | 14:02 |
| zyga | morphis: reload snapd | 14:02 |
| zyga | morphis: it'll work | 14:02 |
| zyga | or check what really controls reexec | 14:02 |
| jdstrand | 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 |
| zyga | morphis: AFAIR there's a patch that fixes some of that (maybe reexec is unconditional) | 14:02 |
| jdstrand | morphis: so if you bind mount over the one in /snap/core, you trick snapd to load your profile | 14:02 |
| morphis | jdstrand, zyga: I still don't get how snapd is involved when I run $ snap run --shell | 14:03 |
| zyga | morphis: it isnt | 14:03 |
| zyga | morphis: but ... if snap run doesn't grok reexec feature | 14:03 |
| zyga | morphis: and for whatever reason goes to "reexec" (not really) by running snap-confine from the core snap | 14:03 |
| morphis | from what I read in the code it shouldn't with SNAP_REEXEC=0 | 14:03 |
| zyga | morphis: then the apparmor profile for snap-confine in the core snap applies | 14:03 |
| zyga | morphis: well, debug away :) | 14:04 |
| zyga | morphis: note: snap also reexecs | 14:04 |
| zyga | morphis: so your snap reexes into core "snap" then runs snap-confine from either core or distro | 14:04 |
| jdstrand | 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 |
| morphis | ok, I see | 14:04 |
| zyga | 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:04 |
| zyga | morphis: (for the snap-confine from /snap/core/123/usr/lib/snaps/snap-confine) | 14:05 |
| jdstrand | 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 |
| zyga | 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:05 | |
| morphis | 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:08 |
| zyga | morphis: does it show when you run it manually? | 14:09 |
| zyga | morphis: did you forget to make hack again? | 14:09 |
| zyga | morphis: note that after you bind mount I think make hack does weired stuff | 14:09 |
| zyga | morphis: not sure | 14:09 |
| zyga | weird* | 14:10 |
| zyga | morphis: also journal has useful hints on reexec | 14:10 |
| morphis | zyga: no I didn't, also verified with strace, however let me play a bit more | 14:13 |
| pcercuei | hi | 14:13 |
| pcercuei | I'm trying to package an app that requires a specific udev rule | 14:13 |
| pcercuei | is there support for that? | 14:13 |
| zyga | pcercuei: can you tell me more about the rule | 14:19 |
| zyga | pcercuei: it is possible but it requires an interface | 14:19 |
| zyga | pcercuei: that is merged in upstream snapd | 14:19 |
| pcercuei | SUBSYSTEM=="usb", PROGRAM=="/bin/sh -c '/usr/bin/iio_info -s | grep %s{idVendor}:%s{idProduct}'", RESULT!="", TAG+="uaccess" | 14:22 |
| pcercuei | that's my rule right now. "iio_info -s" scans the compatible USB devices, the udev rule gives users access to those | 14:23 |
| pcercuei | the 'iio_info' tool would be inside my snap | 14:23 |
| zyga | pcercuei: hmm, that would not work then | 14:23 |
| zyga | (we don't have support for running helper progams from snaps) | 14:23 |
| pcercuei | I can change the rule for a standard idVendor/idProduct check without calling an external program | 14:23 |
| zyga | but we may have something else... | 14:24 |
| zyga | pcercuei: so | 14:24 |
| zyga | pcercuei: do you have your own gadget snap? | 14:24 |
| zyga | pcercuei: we have the iio interface | 14:24 |
| zyga | pcercuei: your gadget can describe such devices | 14:24 |
| zyga | pcercuei: and then your app can have a plug to consume it | 14:25 |
| pcercuei | it's a bit more complicated than that | 14:25 |
| zyga | 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:25 |
| pcercuei | IIO is a kernel framework, so I assume the 'iio' interface of snaps grant access to /dev/iio:deviceX and /sys/bus/iio/* | 14:26 |
| pcercuei | however here, I'm doing IIO over USB | 14:26 |
| pcercuei | with a server that uses FunctionFS on the USB device, and acts as a RPC more or less | 14:27 |
| pcercuei | the client is libiio, which uses libusb to communicate with the server | 14:27 |
| pcercuei | So the 'raw-usb' plug works fine in my snap, as long as the udev rule is installed | 14:28 |
| zyga | it adds access to /sys/bus/iio/devices/$specific_device/ | 14:28 |
| zyga | pcercuei: the problem is that we don't have any hotplug capability in snapd yet | 14:29 |
| zyga | pcercuei: and thus any such iio slot must be declared statically by the gadget snap | 14:29 |
| zyga | pcercuei: the rest should work OK | 14:29 |
| morphis | zyga, jdstrand: ok got it working now, not sure what my problem was before | 14:30 |
| morphis | zyga, jdstrand: thanks anyway! | 14:30 |
| pcercuei | I don't really care about hotplug - but when my snap starts, it should be able to see an already-plugged compatible device | 14:30 |
| pcercuei | otherwise that means I have to ask my users to install a .deb so that the udev rule is installed, which defeats the purpose of having a one-file package | 14:32 |
| zyga | pcercuei: not that your app, to get that permission needs an interface connection | 14:32 |
| zyga | pcercuei: something on the system must show that there's a "iio" slot available | 14:33 |
| zyga | pcercuei: and your app (and the snap containing it) must declare an "iio" plug | 14:33 |
| zyga | pcercuei: and something must make the connection between the two | 14:33 |
| zyga | pcercuei: only then can your app actually use that device | 14:33 |
| zyga | pcercuei: and note that this only works in a core system with just snaps (no debs) so that you can use a gadget snap | 14:33 |
| zyga | pcercuei: does that make sense to you? | 14:34 |
| === fede2_ is now known as fede2 | ||
| pcercuei | not really | 14:35 |
| zyga | pcercuei: ok, let's start from one basic thing | 14:35 |
| pcercuei | what on the system would say that there's a 'iio-usb' slot available? | 14:35 |
| zyga | pcercuei: snaps get permissions only when an interface is connected | 14:35 |
| zyga | pcercuei: (we'll get to that) | 14:35 |
| zyga | pcercuei: a connection is made between a plug (consumer) and a slot (provider) that are compatible | 14:36 |
| zyga | pcercuei: any snap can declare a iio plug | 14:36 |
| zyga | pcercuei: but iio slots can only come from gadget or core snaps | 14:36 |
| pcercuei | Yes; in my case, I plug to the 'usb-raw' slot | 14:36 |
| zyga | pcercuei: becase there is no hot-plug detection the core snap does not declare any iio slots | 14:36 |
| zyga | pcercuei: that leaves us with the gadget snap | 14:36 |
| zyga | pcercuei: I'm unsure I understand how usb-raw and iio interplay here | 14:37 |
| pcercuei | forget about IIO | 14:37 |
| pcercuei | I'm just trying to communicate with a USB device; the data I transfer is related to IIO, but that's not relevant here | 14:38 |
| zyga | pcercuei: so when you use usb-raw what denials are you getting? | 14:39 |
| pcercuei | The problem I have, is that while I plug to 'usb-raw', I still can't communicate with the USB device, because it belongs to the 'root' user and isn't accessible by other users of the system, unless a udev rule is here to say so | 14:40 |
| zyga | aha | 14:40 |
| pcercuei | if I run my snap app with sudo, the USB device is properly detected | 14:40 |
| zyga | so the app itself runs as an ordidinary user? | 14:40 |
| zyga | ok | 14:40 |
| zyga | I get it now | 14:40 |
| zyga | this is a different issue, sorry for the confusin | 14:40 |
| zyga | confusion*, one sec | 14:40 |
| pcercuei | no problem :) | 14:40 |
| Chipaca | zyga: wrt trymode, i think it's right that it goes in SnapState's Sequence | 14:40 |
| Chipaca | zyga: what's more, i think trymode as a flag on SnapState itself is wrong | 14:41 |
| zyga | Chipaca: yep, I agree | 14:41 |
| Chipaca | zyga: (it's wrong, and results in buggy output in "snap list --all" when you have a snap installed and then do 'snap try' of the same snap | 14:41 |
| Chipaca | ) | 14:41 |
| zyga | pcercuei: https://forum.snapcraft.io/t/snappy-and-users-and-groups/331 | 14:42 |
| zyga | pcercuei: have a look at this thread please | 14:42 |
| zyga | pcercuei: it describes where we are with that | 14:42 |
| pcercuei | thanks | 14:43 |
| * zyga is starving but will be back soon | 14:43 | |
| zyga | pcercuei: 2. supporting device access via ACLs for granting access of devices to (non-root) users. https://launchpad.net/bugs/1646144 | 14:43 |
| mup | Bug #1646144: ACLs to devices need to be supported in core <Canonical System Image:Confirmed for pat-mcgowan> <Snappy:Fix Committed by ogra> <ubuntu-core-meta (Ubuntu):Fix Committed by ogra> <https://launchpad.net/bugs/1646144> | 14:43 |
| ogra_ | thats fixed in edge | 14:43 |
| zyga | ogra_: that's just a sliver of the problem | 14:43 |
| zyga | ogra_: the whole thing is not implemented | 14:43 |
| ogra_ | yeah | 14:45 |
| pcercuei | ah, that's unfortunate | 14:45 |
| ogra_ | well, using a gadget and adding the rule there would work though ... | 14:45 |
| ogra_ | as well as adding the rule manually to an image | 14:45 |
| ogra_ | (its just linux after all ... ) | 14:46 |
| kuhlmant | I have submitted for a name in the Ubuntu Store, 'mojo' to be used for a snap. This was a couple of days ago and I'm wondering what the process is and the expected processing time? | 14:51 |
| zyga | ogra_: not sure, can a gadget add arbitrary udev rules? | 14:52 |
| zyga | ogra_: the problem is that the user running this isn't root | 14:52 |
| ogra_ | well, the rule is run by udev | 14:53 |
| zyga | ogra_: which rule? can a gadget add arbitrary unconfined rules? | 14:53 |
| ogra_ | and i think you are able to ship anything in system-data/etc/ | 14:53 |
| ogra_ | iirc ubuntu-image has code to copy all such stuff | 14:54 |
| morphis | zyga: updated https://github.com/snapcore/snapd/pull/3271 and combined both test cases | 14:55 |
| mup | PR snapd#3271: cmd/snap-confine: use /etc/ssl from the core snap <Created by morphis> <https://github.com/snapcore/snapd/pull/3271> | 14:55 |
| Chipaca | kuhlmant: i think you need to start a forum thread about it | 14:56 |
| pcercuei | ogra_: gadget snaps look like something to generate OS images | 14:59 |
| kuhlmant | Chipaca: I guess I can do that, I didn't think there as much to discuss so haven't. If starting a forum thread is the standard process though I will. What is next typically? | 14:59 |
| pcercuei | ogra_: my snap would run on Ubuntu, Debian, Fedora etc. | 14:59 |
| ogra_ | pcercuei, yes, indeed they are ... zyga mentioning the gadget above made me think you were on UbuntuCore, sorry | 15:00 |
| pcercuei | ok | 15:00 |
| ogra_ | (i could have asked :P ) | 15:00 |
| ogra_ | though i couldnt imagine an UbuntuCore multi-user system ... that could have told me what you want :) | 15:01 |
| morphis | zyga: you remember when you looked into https://bugs.launchpad.net/snappy/+bug/1644573 which parts of the go std library were trying to use IPv6? | 15:02 |
| mup | Bug #1644573: snapctl causes hooks to attempt to open ip/ipv6 tcp connection <Snappy:Triaged by zyga> <https://launchpad.net/bugs/1644573> | 15:02 |
| station | can ubuntu core be instaled as an Gateway/Router/Server or is it a bad idea, is there a tut | 15:23 |
| station | +firewall | 15:23 |
| mup | PR snapd#3273 opened: tests: wait for the docker socket to be listening <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3273> | 15:27 |
| Chipaca | station: yes it can (dell is shipping such a thing for example) | 15:27 |
| station | well I cnow but is there a DIY Tut? | 15:28 |
| station | if I set to grab a firewal Docker Image and sow on, would't that either take for ages or function like crap at the moment | 15:30 |
| station | or can I plunge myself into the unknown and be a happy Firewall/ Gateway /Router/Server user in like 5h | 15:32 |
| Chipaca | station: I don't think there's a tutorial aimed at that specifically | 15:45 |
| Chipaca | station: but if what you're looking for is to create a one-off thing, as opposed to a product, it's merely a question of installing the right snaps | 15:46 |
| ogra_ | there should be a ufw snap | 15:54 |
| ogra_ | and there is a wifi-ap snap | 15:54 |
| ogra_ | so a firewall and an AP are definitely possible | 15:55 |
| * ogra_ wouldnt put docker in the loop ... thats just useless overhead | 15:55 | |
| kyrofa | Hey pachulo, did you need me? | 15:58 |
| mup | Bug #1688103 changed: Classic confinement should allow preservation of $HOME <Snapcraft:Invalid> <Snappy:Invalid> <https://launchpad.net/bugs/1688103> | 16:03 |
| mup | PR snapd#3264 closed: tests: remove quoting from [[ ]] when globs <Created by zyga> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/3264> | 16:10 |
| mup | PR snapd#3267 closed: cmd: make rst2man optional <Created by morphis> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/3267> | 16:10 |
| mup | PR snapd#3254 closed: tests: re-enable and moderninze /media sharing test <Created by zyga> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/3254> | 16:11 |
| Chipaca | zyga: super easy review: snapd#3270 | 16:13 |
| mup | PR snapd#3270: adjust Nice and oom_score levels for snapd <Created by ogra1> <https://github.com/snapcore/snapd/pull/3270> | 16:13 |
| Chipaca | pstolowski: zyga: and please finish your reviews of my completion branches... | 16:17 |
| pstolowski | Chipaca, will do tomorrow first thing in the morning, sorry about that | 16:18 |
| Chipaca | morphis: thanks! | 16:22 |
| mup | PR snapd#3270 closed: adjust Nice and oom_score levels for snapd <Created by ogra1> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/3270> | 16:22 |
| morphis | Chipaca: np | 16:23 |
| mup | PR snapd#3240 closed: snap: add `snap refresh --time` option <Created by mvo5> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/3240> | 16:24 |
| * ogra_ hugs Chipaca | 16:26 | |
| diddledan | what should I put in the CLA form for "Canonical Project Manager or contact" so that my snapcraft submission can be accepted? | 16:28 |
| * zyga will soon return to code reviews | 16:32 | |
| Chipaca | diddledan: what options are there? | 16:34 |
| diddledan | it's a blank text field | 16:34 |
| diddledan | but it won't accept a blank entry | 16:34 |
| Chipaca | diddledan: ah. Jamie Bennet | 16:35 |
| diddledan | ok I took that. agreement now signed \o/ | 16:35 |
| diddledan | s/I/it/ | 16:35 |
| Chipaca | :-) | 16:36 |
| === daniel1 is now known as Odd_Bloke | ||
| jdstrand | zyga: hew, fyi, be87d017 broke 'make check' on (at least) xenial and earlier because it doesn't support -x | 17:05 |
| jdstrand | zyga: 'make check' for snap-confine when shellcheck is installed that is | 17:06 |
| jdstrand | hey* | 17:06 |
| jdstrand | zyga: and uninstalling shellcheck makes 'make check' fail | 17:08 |
| jdstrand | zyga: ugh, all the annotations need a newer shellcheck | 17:11 |
| jdstrand | well, maybe not all, but a bunch | 17:11 |
| jdstrand | workaround seems to be to install shellcheck from zesty | 17:13 |
| jdstrand | zyga: does this ^ mean 'make check' isn't run during the LP builds? that would be unfortunate | 17:14 |
| jdstrand | zyga: it seems the fix would be to check if '-x' is supported and if not, skip the syntax check | 17:15 |
| jdstrand | zyga: or checking 'shellcheck --version' | 17:16 |
| jdstrand | zyga: or shipping shellcheck in the sources so it is always the same | 17:16 |
| jdstrand | anyway, I'm not blocked | 17:17 |
| zyga | re | 17:31 |
| zyga | jdstrand: ay, I know about shellckeck, unfortunate :/ | 17:31 |
| zyga | jdstrand: you can make it pass by re-running autogen.sh | 17:32 |
| zyga | jdstrand: shellcheck is written in haskell so insane to ship | 17:32 |
| zyga | jdstrand: I thought about it and my secret desire is to have a shellcheck backport as everything else is hard (including shellcheck as a snap) | 17:32 |
| zyga | jdstrand: or alternatively do a non-backport update of shellcheck | 17:34 |
| zyga | jdstrand: but that's something foundations would have to comment on | 17:34 |
| zyga | slangasek: hey | 17:34 |
| jdstrand | interesting | 17:34 |
| zyga | slangasek: quick question; what is easier, backport newer shellcheck to xenial or use shellcheck as a snap while building snapd? | 17:34 |
| zyga | slangasek: interestingly we could move the package from xenial to, say, zesty, and then do xenial backports | 17:35 |
| jdstrand | afaik the former since the latter isn't supported (declaring Build-Deps on snaps) | 17:35 |
| zyga | slangasek: then zesty shellcheck is good | 17:35 |
| jdstrand | you also can't do LP builds for the archive against -backports | 17:36 |
| zyga | jdstrand: aww :/ | 17:36 |
| jdstrand | archive builds* | 17:36 |
| zyga | jdstrand: right | 17:36 |
| zyga | jdstrand: well | 17:36 |
| zyga | jdstrand: I think it's semi-ok | 17:36 |
| zyga | jdstrand: what need to change | 17:36 |
| zyga | jdstrand: is that >16.04 builds should pull in shellcheck | 17:36 |
| jdstrand | sru 0.4.4 to xenial would be fine | 17:36 |
| zyga | jdstrand: then we'll know during daily CI via adt | 17:36 |
| zyga | jdstrand: yeah? I'll check if it builds quickly | 17:37 |
| jdstrand | but, really, as you say, just skipping the shellcheck where the version is known not to work is fine | 17:37 |
| jdstrand | it is just we don't want to disable all of 'make check' to avoid the shellcheck issue | 17:37 |
| * zyga has a love hate relationship with shellcheck, it's amazing and haskel is interesting but man, haskel toolchain stuff is terribly annoying to work with | 17:37 | |
| zyga | jdstrand: oh, I think it's not that, we just skip shellcheck | 17:37 |
| zyga | jdstrand: we still run other checks | 17:37 |
| zyga | jdstrand: (for sure) | 17:37 |
| zyga | one thing we should do soon is to enable hard error checking on valgrind | 17:38 |
| jdstrand | imho, it is fine to not run check-syntax-sh on 16, since we are getting all the benefits from the versions of Ubuntu with the used shellcheck | 17:38 |
| zyga | but some of that is hard as there's plenty of false positives because we fork/exec and use glib for testing | 17:38 |
| zyga | yes, I agree | 17:38 |
| jdstrand | it's kind of funny to implement a tool in a rather niche language to syntax check a ubiquitous language | 17:40 |
| * jdstrand didn't realize it was haskell | 17:40 | |
| zyga | jdstrand: yeah, I read the implementation, it is really beautiful | 17:42 |
| zyga | jdstrand: hey | 18:19 |
| zyga | jdstrand: can you have a look at https://github.com/snapcore/snapd/pull/2837/files | 18:20 |
| mup | PR snapd#2837: interfaces/apparmor: allow reading from ecryptfs <Created by zyga> <https://github.com/snapcore/snapd/pull/2837> | 18:20 |
| zyga | jdstrand: not a detailed review | 18:20 |
| zyga | jdstrand: I'm still working on extra tests | 18:20 |
| zyga | jdstrand: just tell me if that fits your idea | 18:20 |
| jdstrand | zyga: there was another conversation on that somewhere... | 18:23 |
| jdstrand | zyga: I'm not imagining that am I? | 18:23 |
| jdstrand | zyga: oh, heh, nm | 18:24 |
| mup | PR snapd#3273 closed: tests: wait for the docker socket to be listening <Created by fgimenez> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3273> | 18:24 |
| jdstrand | the conversation was in that PR-- I was thinking this was a brand new PR :) | 18:24 |
| zyga | jdstrand: :D | 18:29 |
| zyga | jdstrand: it's my oldest PR ever | 18:29 |
| zyga | jdstrand: there's one obvious nastiness there | 18:29 |
| zyga | jdstrand: _any_ ecryptfs gives _any_ try mode snaps the extra snippet | 18:29 |
| zyga | jdstrand: but we can remove that nastiness soon, chipaca said we should rework the state a little to store trymode flag in a per-revision thing | 18:30 |
| zyga | jdstrand: and then we can also store the path | 18:30 |
| zyga | jdstrand: (currently snapd just doesn't know) | 18:30 |
| jdstrand | I'm actually already commenting on that | 18:32 |
| zyga | thank you! | 18:32 |
| zyga | jdstrand: thanks! | 18:48 |
| jdstrand | np | 18:49 |
| === JanC is now known as Guest75375 | ||
| === JanC_ is now known as JanC | ||
| slangasek | zyga: you can't build-depend on snaps at all currently | 19:34 |
| Chipaca | ogra_: you around? | 22:04 |
| mup | PR snapd#3268 closed: interfaces/browser-support: deny read on squashfs backing files and LVM vg names <Created by jdstrand> <Merged by jdstrand> <https://github.com/snapcore/snapd/pull/3268> | 22:11 |
| Son_Goku | niemeyer: so I've made the vacation request | 22:50 |
| Son_Goku | fingers crossed! | 22:50 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!