| Domi | Hello, is it possible to use a package form pip in a snap? | 00:10 |
|---|---|---|
| ogra_ | sergiusens: nobody reads my mails :( | 00:55 |
| ogra_ | sergiusens: we are past release, we cant change seeds (unless we apply gross hacks) | 00:56 |
| * ogra_ wrote a long mail about that topic, but nobody reacted | 00:56 | |
| ogra_ | i'm not sure how we should add something like nss beyond making up an artificial dep in one of the packages | 00:57 |
| sergiusens | ogra_ false warning, not needed | 00:59 |
| ogra_ | ok | 00:59 |
| sergiusens | And not my idea | 00:59 |
| ogra_ | sergiusens: doesnt fix the base problem though ... | 00:59 |
| ogra_ | i'm sure the next nss is around the corner :) | 00:59 |
| sergiusens | But I did read your email. I wanted you to tell zyga what you just told me 😌 | 01:00 |
| sergiusens | desktop support landed too close to release | 01:00 |
| ogra_ | i suspect we could make ubuntu-core-config kind of a meta package ... to get such deps in | 01:00 |
| ogra_ | yeah, it did ... | 01:00 |
| sergiusens | And this is what we get | 01:01 |
| ogra_ | and really broke to much of the IoT side | 01:01 |
| sergiusens | You don't say | 01:01 |
| ogra_ | heh | 01:01 |
| ogra_ | well, we'll dig our butts out of this ... as we always do :) | 01:01 |
| * sergiusens needs a telgram sticker now | 01:01 | |
| ogra_ | hah | 01:02 |
| === chihchun_afk is now known as chihchun | ||
| === chihchun is now known as chihchun_afk | ||
| === chihchun_afk is now known as chihchun | ||
| slvn | Hello, I am trying to create my first snap but have some issue. (I already read some doc, and tried the opencv example). | 07:02 |
| slvn | I build SDL2 example, with cmake. But it fails to execute as a snap | 07:03 |
| slvn | because some shared libs are missing. SDL2 tries to dlopen some libs, like mirclient.so, and probably some other .. | 07:03 |
| slvn | should I put all those shared libs into the snap package ? | 07:04 |
| slvn | (I think CMake is putting the libSDL2 into the snap package, but not libmirclient.so for instance) | 07:05 |
| dholbach | good morning | 07:05 |
| dholbach | mvo, wow, you're improving your bug karma :) | 07:06 |
| zyga | good morning | 07:36 |
| stevebiscuit | https://code.launchpad.net/~stevenwilkin/webdm/use-snapcraft-to-snap/+merge/293053 # should get WebDM in shape to be put back on the store | 07:37 |
| mvo | dholbach: hey, good morning. indeed, bug triage ftw! | 07:52 |
| zyga | https://github.com/ubuntu-core/snappy/pull/1080 | 08:03 |
| dpm | hi all - does anyone know if there is a workaround for this error, other than wiping out the whole snap installation again? http://pastebin.ubuntu.com/16075906 | 08:08 |
| pedronis | dpm: mvo is looking into those kind of issues, how theory is that Notes was running? that issue is local to the snap so in principle it doesn't need wiping out everything | 08:14 |
| pedronis | s/how/our/ | 08:14 |
| dpm | pedronis, yes, I think it was running at the time of install, but it was on a different workspace and I hadn't noticed it. However, even after closing it the uninstall error remains. If the issue is local to the snap, is there a way to fix it, though? | 08:16 |
| slvn | Hello ! My snap package needs to access to X11. but it fails because of apparmor (?). (syslog: apparmor="DENIED" ... operation="connect" ... requested_mask="send receive connect" denied_mask="send connect" addr=none peer_addr="@/tmp/.X11-unix/X0" peer="unconfined" ) | 08:24 |
| zyga | slvn: hey, is the x11 interface connected? can you pastebin your snapcraft.yaml please | 08:26 |
| slvn | zyga, probably not since this is my first snap ... http://paste.ubuntu.com/16076031/ | 08:28 |
| zyga | slvn: no worries, please add this uner "command:", "plugs: [unity7]" | 08:28 |
| zyga | slvn: and perhaps add opengl there (after unity7) if that doesn't work still | 08:29 |
| zyga | slvn: http://www.zygoon.pl/2016/04/snappy-interfaces-plugs-slots-connections.html | 08:29 |
| slvn | zyga, seems to work better ! (though I have another error now) | 08:31 |
| zyga | slvn: cool, what's the next error? | 08:32 |
| slvn | zyga, my first snap tries to use SDL2. but SDL2 can require libmirclient.so or libX11.so. or now libGL.so ... should I all add them to the snap, with cmake. or should I let the snap access the system lib ? | 08:32 |
| zyga | slvn: I think you should bundle them but I'm not 100% sure | 08:33 |
| zyga | slvn: there are some special provisions for opengl apps | 08:33 |
| zyga | slvn: what error do you see now? | 08:33 |
| zyga | dholbach: ^^ do you know if those libs should be bundled? | 08:33 |
| slvn | zyga, SDL2, has started to communicate with x11. (through libX11.so), now it requires to load libGL.so. | 08:34 |
| slvn | it fails because it cannot dlopen libGL.so | 08:34 |
| slvn | (btw, cmake doesn't include by itself libX11.so, so I need to make a *fake* call to a x11 lib, so that the libGL.so is include in snap/ ) (maybe there is a correct command to tell cmake to include it ...) | 08:36 |
| zyga | slvn: try adding the package that has libgl.so to stage-packages | 08:37 |
| dholbach | zyga, I have no idea - dpm: ^ what's your experience? | 08:41 |
| zyga | do we have any opengl apps? | 08:41 |
| dpm | zyga, dholbach, ubuntu-clock-app, ubuntu-calculator-app and notes all use the opengl interface | 08:42 |
| dpm | IIRC they install the required libraries via dependencies in stage-packages | 08:43 |
| zyga | https://github.com/ubuntu-core/snappy/pull/1081 | 08:45 |
| slvn | zyga, now it looks for another lib :/ "libGL error: unable to load driver: swrast_dri.so", "libGL error: failed to load driver: swrast", "DEBUG: Could not create GL context: BadValue" | 08:53 |
| zyga | slvn: that tells you it cannot load software rendering for opengl, I think there's some magic you have to do to make it use system-wide opengl libraries (that snappy provides) | 08:55 |
| zyga | slvn: but I don't know how this works, sorry, I cannot help you | 08:55 |
| slvn | zyga, thanks anyway :) because you fixed me, in 5 min, a few issues I spent 2 hours yesterday | 08:58 |
| zyga | slvn: I'll look at SDL/opengl apps more closely soon (~ days) | 08:58 |
| zyga | slvn: I'll be blogging about how to snap them correctly | 08:58 |
| slvn | zyga, I'll send you my snap package if I can make it work correctly | 08:59 |
| zyga | slvn: sure | 08:59 |
| === JamesTait is now known as Guest50895 | ||
| wesleymason | Question: is it possible to define post-install hooks in a snap? My problem: pkg_resources in python are incredibly dumb, and usually get generated with full paths in them..which means they end up with the "install" part path on my filesystem embedded at the point snapcraft runs, and completely fails when invoked in the installed snap | 09:02 |
| === Guest50895 is now known as JamesTait | ||
| pedronis | wesleymason: no, it's something that snapcraft needs to learn/deal with, maybe a snapscraft bug report could help there | 09:05 |
| wesleymason | pedronis: *nod*..might not be entirely possible for snapcraft to fix itself, as some of the pkg_resources import hooks rely on non-rel paths (it's why the --relative option to virtualenv is deprecated and used to break a lot)..and obviously you can't rely on knowing the path a snap will be installed at I don't think | 09:07 |
| wesleymason | will fil the bug | 09:07 |
| popey | dpm: did you get an answer to your problem of not being able to uninstall a snap if there was a process running, and leaving you in an inconsistent state? | 09:16 |
| dpm | popey, I didn't, so I ran the "wipe out the world" script and filed bug 1575550 :) | 09:17 |
| ubottu | bug 1575550 in Snappy "Snap removal while snap is running prevents subsequent removal or installation" [Undecided,New] https://launchpad.net/bugs/1575550 | 09:17 |
| popey | dpm: which wipe the world script did you use? I have seen a few | 09:17 |
| dpm | the one you pasted a while ago | 09:18 |
| dpm | let me re-paste | 09:18 |
| * popey confirms the bug | 09:18 | |
| popey | it's worse if your app launches a binary which isn't even graphical | 09:18 |
| popey | you have no idea it's running without hunting it down with lsof and friends | 09:19 |
| dpm | oh, I see, so you don't notice easily if it's running or not | 09:19 |
| popey | yeah | 09:19 |
| dpm | http://pastebin.ubuntu.com/16076306/ <- that wfm | 09:19 |
| popey | i had a random binary called "--debug" running :) | 09:19 |
| popey | ta | 09:19 |
| * popey saves as nuke_snap_from_orbit.sh | 09:19 | |
| zyga | dpm, popey: please don't use that | 09:28 |
| zyga | use this instead: https://github.com/zyga/devtools/blob/master/reset-state | 09:28 |
| zyga | run this script as the pastebin above is incomplete and leaves some stuff behind | 09:28 |
| zyga | feel free to spread the link, I maintaing that script to work as snappy evolves | 09:28 |
| dpm | thanks zyga - does the system need to be rebooted after runing the script? E.g. for mounts and such | 09:30 |
| zyga | dpm: I don't believe so | 09:33 |
| zyga | dpm: though if you find a corner case do let me know | 09:33 |
| zyga | dpm: and I will gladly take pull requests | 09:33 |
| zyga | dpm: to improve on the wording, behavior, etc | 09:34 |
| dpm | thanks zyga | 09:38 |
| pedronis | zyga: though the goal is not to need the script :) | 09:39 |
| zyga | pedronis: hehe :) I wonder if dpkg had a 'wipe.pl' script in the early days ;) | 09:39 |
| zyga | pedronis: I fully agree though :) | 09:39 |
| zyga | after the first sru the number of breaking bugs will certainly be much lower | 09:40 |
| dragly | zyga: You mentioned blogging about it when OpenGL apps are working properly. Where's your blog? I'd like to follow the progress on this :) | 09:46 |
| zyga | dragly: zygoon.pl, also on planet.ubunt.com | 09:46 |
| slvn | zyga, just to let you know. snap package works when the SDL2 renderer is set as software (no GL libs). Using opengl renderer, libGL.so can't load libswards_dri.so. Verbose log http://paste.ubuntu.com/16076481/ | 09:46 |
| dragly | thanks | 09:46 |
| zyga | slvn: does it work when you install the snap with --devmode (remove it first please) | 09:47 |
| zyga | slvn: please report a bug on snappy with the log you see above and with syslog output (journalctl -n 1000,) | 09:48 |
| zyga | slvn: we won't "fix" it immediately but it will help us to track it | 09:48 |
| zyga | slvn: please include your snapcraft file / sources as well (as links or attachments) | 09:48 |
| slvn | Adding --devmode won't help | 09:50 |
| slvn | also, I have the swarst_dri in the ./snap/ see : http://paste.ubuntu.com/16076518/ | 09:51 |
| slvn | I'll report the issue ... | 09:51 |
| zyga | slvn: if --devmode doesn't help then you need to tweak your snap to have the right settings to intialize GL (I cannot help there unfortunately) | 09:58 |
| zyga | slvn: including, perhaps, more libraries | 09:59 |
| seb128 | dholbach, is https://github.com/ubuntu-core/snapcraft/blob/master/docs/your-first-snap.md uptodate? | 09:59 |
| slvn | zyga, I continue investigating before reporting (or not) the issue. it seem dri/swrast.so is there, but libGL.so is not finding it :/ | 10:00 |
| slvn | zyga, what does devmode does ? | 10:00 |
| zyga | slvn: http://www.zygoon.pl/2016/04/snap-install-devmode.html | 10:00 |
| slvn | zyga, ok! strange because with "--devmode" but no plug x11/opengl and no stage package libgl1-mesa-glx, it still cannot find libGL.so. | 10:07 |
| pedronis | that's what subset of libs we mount, not a security one | 10:10 |
| pedronis | I suspect | 10:10 |
| slvn | zyga, still want me to enter a bug report ? (https://launchpad.net/snapcraft ?) | 10:13 |
| zyga | slvn: yes please | 10:13 |
| dholbach | seb128, it should be - if it's not, that's a bug | 10:15 |
| seb128 | dholbach, ok, good, just checking before starting reading it ;-) | 10:15 |
| seb128 | dholbach, thanks | 10:15 |
| dholbach | seb128, https://github.com/ubuntu-core/snapcraft/pull/454 is a pending change I know of | 10:16 |
| seb128 | dholbach, danke | 10:16 |
| dholbach | kyrofa, ^ can we land this one soon? | 10:16 |
| seb128 | dholbach, I started by reading https://github.com/ubuntu-core/snapcraft/blob/master/docs/get-started.md | 10:17 |
| seb128 | which states | 10:17 |
| seb128 | "This is the most important selection of tools you will get after installation: | 10:17 |
| seb128 | snappy try - try snaps from a .snap, the [stage] or [snap] dir" | 10:17 |
| seb128 | but "snappy" is command-not-found | 10:17 |
| seb128 | so I was wondering if the rest was updated | 10:18 |
| seb128 | going to read more and see if I find issues | 10:18 |
| seb128 | dholbach, k, that pending change address that one | 10:23 |
| slvn | zyga, there https://bugs.launchpad.net/snapcraft/+bug/1575582 | 10:24 |
| ubottu | Launchpad bug 1575582 in Snapcraft "Snap package, using SDL2, needs access to libGL.so and DRI dependencies" [Undecided,New] | 10:24 |
| zyga | slvn: thanks, checking | 10:25 |
| slvn | zyga, the attachment is the SDL2 helloworld .. | 10:25 |
| zyga | slvn: the attachment looks good, thanks for reporting this | 10:26 |
| === chihchun is now known as chihchun_afk | ||
| === chihchun_afk is now known as chihchun | ||
| slvn | zyga, my opinion is that GL libs should not be provided in the snap package. But the SDL2 should require an access to a subset of system libs. | 10:45 |
| slvn | when I add the "plug" unity7, I can get access to mirclient I guess? | 10:45 |
| slvn | but when I add the plug "opengl" I dont get access to libGL ! | 10:45 |
| ogra_ | that would be unity8 :) | 10:45 |
| ogra_ | (there is no expectation for mir on unity7 i thinnk) | 10:46 |
| slvn | to get access to libGL, I need to add the stage-package libgl1-mesa | 10:46 |
| zyga | slvn: that much is true but which *actual* libraries are provided by the snap and which are provided by the os is tricky | 10:47 |
| zyga | slvn: from a particular GL call in your code to, say, nvidia userspace blob doing something is a long path | 10:48 |
| zyga | slvn: a similar thing happens with openCL but there it, at least, was designed correctly up front | 10:48 |
| slvn | ogra_, yep unity8 :) but that's probably a typo .. btw, if I put unity8, I get an error at runtime "Bad system call". | 10:48 |
| zyga | slvn: so you can query available drivers and pick the right one | 10:48 |
| zyga | slvn: there is no unity8 interface yet | 10:49 |
| Domi | Hello, how do I pack packages form pip in my snap? | 10:51 |
| zyga | Domi: hey, look at snapcraft examples, there are some pip-based python demos there | 10:52 |
| slvn | zyga, yep tricky choice of lib to include or not ... Best case: the snap contains only the Application. Worse case: it contains the whole distribution ... | 10:53 |
| slvn | how can I know that the "plug" "opengl" do ? | 10:53 |
| Domi | zyga: I just see the python example with spongeshaker and github | 10:54 |
| Domi | https://github.com/ubuntu-core/snapcraft/blob/master/examples/py3-project/snapcraft.yaml | 10:54 |
| zyga | slvn: look at snappy source code, today there's little docs on interfaces | 10:54 |
| zyga | slvn: I'm writing some but they are not ready yet | 10:54 |
| slvn | zyga, np, I will have a look :) | 10:55 |
| Domi | snapcraft snap fails because the python installation. Her is the output http://pastebin.com/GmZB6v4D can anyone help me? | 11:25 |
| seb128 | can snapcraft.yaml use a dynamic version? | 11:33 |
| seb128 | like version: "version: `bzr revno`" | 11:39 |
| zyga | seb128: nope | 11:51 |
| zyga | seb128: not that I know of at least | 11:51 |
| seb128 | :-( | 11:56 |
| _morphis | zyga: you saw my comment about moving the security label building code somewhere else where every interface implementation can consume it? | 12:01 |
| zyga | _morphis: no, not yet | 12:01 |
| zyga | _morphis: though I think it makes a lot of sense :) | 12:02 |
| _morphis | ok | 12:02 |
| _morphis | :-) | 12:02 |
| zyga | _morphis: I was thinking if n-m would use it | 12:02 |
| kyrofa | Good morning | 12:02 |
| _morphis | zyga: for sure | 12:02 |
| kyrofa | dholbach, I was hoping to wait until snappy was in sync across the desktop and ubuntu core, but perhaps that's not necessary | 12:03 |
| === chihchun is now known as chihchun_afk | ||
| loic_m | hi there | 12:11 |
| loic_m | I work on a project where I'll have raspberryPis running various applications (deal with a central API, and run a chrome-browser in kiosk mode to display an html app displayed on a screen plugged-in by hdmi) | 12:13 |
| loic_m | I'm discovering Snappy and I wonder if it could be a great tool to manage my applications and their deployment accros all the devices | 12:14 |
| loic_m | can I have "private" snaps on the store? | 12:16 |
| === chihchun_afk is now known as chihchun | ||
| zyga | loic_m: I'm sure you can :-) | 12:22 |
| zyga | _morphis: I'm looking at one more thing and then I'll switch focus to n-m | 12:23 |
| _morphis | zyga: ok, just moving those bits into a specific function is enough for me, I can adjust the n-m interface implementation then | 12:25 |
| sergiusens | kyrofa I have another morning gift for you https://bugs.launchpad.net/bugs/1575628 | 12:45 |
| ubottu | Launchpad bug 1575628 in Snapcraft ""copy" plugin symlinks whole snap folder when no source is given" [Undecided,New] | 12:45 |
| kyrofa | sergiusens, yeah I'm discussing it now in another channel | 12:46 |
| seb128 | did anyone looked at making snaps load locale .mo translations? | 12:46 |
| seb128 | dpm, ^ do you know? | 12:46 |
| kyrofa | sergiusens, the problem is that built snaps are copied if the source is '.'. Which is a problem with all plugins that accept the source keyword | 12:46 |
| seb128 | also to get locales generated in the snap | 12:46 |
| dpm | seb128, tl;dr, I did, it didn't work | 12:47 |
| seb128 | did you file a bug about it? | 12:47 |
| dpm | seb128, the clock app is an example: | 12:47 |
| dpm | it builds and ships the .mo files | 12:47 |
| dpm | but the UI toolkit does not find them | 12:47 |
| seb128 | well, non english locales are not even available right? | 12:48 |
| seb128 | we would need to generate locales on the core image | 12:48 |
| sergiusens | kyrofa yeah, I am not a fan of source: '.'; we could be smarter about this and do a `bzr export`, `git whatever` and then default to a plain copy (depending on the plugin of course) | 12:48 |
| seb128 | or to include locales in the snap | 12:48 |
| seb128 | and generate those in some way | 12:48 |
| dpm | seb128, for the toolkit, apparently setting https://github.com/sergiusens/qt5conf/blob/master/qt5-launch#L55 should take care of it, but it didn't work. And yeah, good point, if they're not generated, they won't be recognized | 12:49 |
| vila | sergiusens: yeah, coverage is not such a big deal for me... as long as you don't block on that ;-) The integration tests cover the parts that the unit test don't | 12:49 |
| vila | sergiusens: this is ready to review though | 12:49 |
| kyrofa | sergiusens, what does bzr export (or similar) get us? | 12:49 |
| sergiusens | vila well we do block on low unit test coverage ;-) | 12:49 |
| sergiusens | kyrofa exporting the pure sources without generated artifacts | 12:50 |
| kyrofa | sergiusens, assuming the snap is in version control? | 12:50 |
| kyrofa | sergiusens, what if we disallowed specifying '.' as the source? We could get rid of the build step's filtering that way | 12:50 |
| vila | sergiusens: well, you want me to require a dev setup including sso, sca, cpi and updown servers ? ;-) | 12:50 |
| sergiusens | kyrofa yeah, that's why I said, if nothing is possible, default to plain copy (depending on the plugin) | 12:51 |
| kyrofa | Ah | 12:51 |
| sergiusens | vila I say talk to elopio; he's the master of test; but we mock server requests/responses for these cases in general | 12:51 |
| kyrofa | sergiusens, that also means we can't run if one hasn't committed to git (or bzr, whatever)... | 12:51 |
| vila | sergiusens: the coverage decreased is caused by the implementation change and by replacing mocked tests by tests against real code | 12:52 |
| vila | mocked requests/response bitrot faster than the server evolves, especially here for macaroons | 12:52 |
| zyga | http://www.zygoon.pl/2016/04/anatomy-of-snappy-interface.html | 12:52 |
| ogra_ | heh, zyga playing doctor :) | 12:53 |
| zyga | :-) | 12:54 |
| sergiusens | vila so this is not specced? Chipaca are you testing the macaroons implementation with unit tests in snapd? | 12:54 |
| sergiusens | vila this is also why we need both in any case, integration tests and unit | 12:54 |
| vila | sergiusens: what do you mean by speceed ? | 12:56 |
| sergiusens | vila client/server interaction | 12:56 |
| dholbach | kyrofa, probably not | 12:56 |
| kyrofa | dholbach, alright, I'll write it for the desktop, since that'll be valid soon for ubuntu core | 12:57 |
| zyga | dholbach: note, I won't be able to attend the snappy community sync | 12:58 |
| kyrofa | sergiusens, alright with you if we get https://github.com/ubuntu-core/snapcraft/pull/454 into the SRU as well? | 12:58 |
| vila | sergiusens: it is, that didn't mean there is no bugs (we've fixed several along the way) | 12:58 |
| zyga | dholbach: unless you want me to dial-in from a classic mobile | 12:58 |
| dholbach | zyga, no worries | 12:58 |
| dholbach | dpm, ^ looks like zyga and niemeyer can't make it for the sync | 12:59 |
| dholbach | maybe we should set up a separate meeting to discuss interfaces/playpen? | 12:59 |
| zyga | I could have otherwise just not today (I learned a moment ago) | 12:59 |
| dpm | niemeyer, zyga, would another day this week work better for you? | 12:59 |
| zyga | dpm: any, sorry, I'm usually free at this time | 13:00 |
| niemeyer_ | dpm: Not at this time | 13:01 |
| niemeyer_ | dpm: I mean, not if the slot is at the same time of the day | 13:02 |
| dpm | dholbach, niemeyer, zyga, would tomorrow, 30 mins later than the original time work? | 13:07 |
| dpm | I'm looking at the calendars and I don't see any conflicting calls | 13:08 |
| zyga | earlier would work, I'm free at all times except for the stand-up call we have right now | 13:08 |
| dpm | 1h earlier, then? | 13:09 |
| sergiusens | kyrofa yeah, it is fine | 13:09 |
| seb128 | is plugs security enoug to let a snap access to the network? | 13:12 |
| zyga | yes | 13:14 |
| zyga | 'network' plug gives you client access | 13:14 |
| dpm | zyga, niemeyer, so would tomorrow, 13:30 UTC work for you, right after your standup? | 13:15 |
| dpm | dholbach, I'm otp atm, if that works for everyone, would you mind moving the meeting? ^ | 13:16 |
| niemeyer_ | dpm: Yeah, that works | 13:16 |
| dpm | excellent | 13:16 |
| dholbach | dpm, hohum... that won't work for me | 13:16 |
| dholbach | I have an appointment from which I have to get back home | 13:16 |
| dholbach | I'd be late quite a bit | 13:17 |
| dholbach | maybe I should make that clearer in my calendar | 13:17 |
| niemeyer_ | dholbach, dpm: Done, thanks! | 13:17 |
| dholbach | or hang on | 13:17 |
| dholbach | UTC | 13:17 |
| dholbach | nevermind | 13:17 |
| dholbach | ignore me | 13:17 |
| dpm | dholbach, ok, cool :) | 13:17 |
| dholbach | sorry, I didn't want to complicate things additionally :-) | 13:18 |
| dpm | all good now :) | 13:18 |
| zyga | jdstrand: about x11, can we do anything about that untrusted client thing that mjg59 mentioned? | 13:43 |
| sergiusens | ogra_ dholbach how would we SRU snapcraft when needed? We have some bug fixes around for a 2.8.5; and later on I'd like to get 2.9 with support for gulp to be able to build some node/electron apps | 13:49 |
| ogra_ | sergiusens, well, through the normal SRU process | 13:54 |
| ogra_ | have bugs ... subbscribe the SRU team ... upload to -proposed with the bugs mentioned in the changelog ... | 13:55 |
| jdstrand | zyga: its being discussed in another thread. there are options. untrusted isn't likely one of them since it doesn't actually block key sniffing (it only blocks one way to sniff) | 13:57 |
| jdstrand | zyga: all options require engineering effort | 13:57 |
| jdstrand | zyga: but the main thing is that this is a strategic decision and a transition, and messaging should reflect that | 13:58 |
| jdstrand | zyga: and messaging beyond what has been messaged is being discussed with olli, jamiebennett, etc | 14:00 |
| dholbach | sergiusens, get all fixes into yakkety first | 14:02 |
| dholbach | sergiusens, then file a bug report listing with the stuff that's fixed in the SRU, and add the https://wiki.ubuntu.com/StableReleaseUpdates description to the bug | 14:03 |
| dholbach | sergiusens, let me know if you need any help with that | 14:03 |
| seb128 | jdstrand, hey, can you tell us how snap is blocking syscalls? seems to block "socketcall" on my i386 install for some reason | 14:10 |
| ogra_ | seb128, via seccomp | 14:12 |
| seb128 | ogra_, any idea about it blocking "socketcall" on i386? | 14:13 |
| ogra_ | (there used to be ways to exclude syscalls from it ... not sure that still exists with the switch to interfaces though) | 14:13 |
| ogra_ | well, it will most likely block creation of system sockets outside of the confined snap area | 14:13 |
| ogra_ | (you should be able to create session related sockets in your rw space though) | 14:14 |
| jdstrand | seb128: via seccomp. the launcher sets up a list of allowed syscalls. you can use 'scmp_sys_resolver ##' on the target system to see what the syscall is | 14:17 |
| jdstrand | seb128: you can manually add them to the seccomp filter in /var/lib/snapd/seccomp/profiles/... to temporarily unblock yourself | 14:18 |
| ogra_ | jdstrand, is there still a way via snap.yaml ? | 14:18 |
| desrt | jdstrand: the problem is that the syscalls for individual socket APIs are very new on i386 | 14:18 |
| desrt | and glibc still doesn't implement them via the new calls | 14:18 |
| desrt | so on i386 we need to allow socketcall() for any network access | 14:19 |
| desrt | but unfortunately that will also open up bind() listen() etc | 14:19 |
| desrt | this is more or less why they introduced the new calls.... | 14:19 |
| jdstrand | seb128: socketcall is included in the 'network' plug. add 'plugs: [ network ]' to your yaml | 14:19 |
| desrt | (for the sake of seccomp) | 14:19 |
| desrt | jdstrand: we already have that :/ | 14:19 |
| jdstrand | seb128: it's possible you have that and it isn't autoconnecting. sergiusens saw that yesterday | 14:19 |
| jdstrand | desrt: ^ | 14:19 |
| jdstrand | I think zyga is aware of the issue | 14:20 |
| desrt | really, we need a new glibc... | 14:20 |
| ogra_ | desrt, just ship it in your snap ;) | 14:20 |
| jdstrand | oh, no I lied | 14:21 |
| jdstrand | socketcall is commented out | 14:21 |
| jdstrand | it is intentionally blocked | 14:21 |
| desrt | could we at least get it with network-bind? | 14:21 |
| jdstrand | probably | 14:22 |
| desrt | if we have network-bind then clearly the whole range of socket calls is OK... | 14:22 |
| jdstrand | let me look into it | 14:22 |
| desrt | thx! | 14:22 |
| jdstrand | for now, to unblock yourselves while I look at that, add it to /var/lib/snapd/seccomp/profiles/... | 14:22 |
| desrt | thanks for the help :) | 14:22 |
| seb128 | jdstrand, thanks | 14:23 |
| desrt | you might want to let socketcall() happen for 'network' if we're on x86.... | 14:23 |
| desrt | on account of the fact that that's probably more reasonable than listing network-bind in every app that uses the network and doesn't want to be aborted on 32bit | 14:23 |
| desrt | strictly, it's a leak of additional privilege... but considering the alternative (ie: all apps effectively have to list network-bind everywhere) it seems fairly reasonable | 14:25 |
| slvn | quick question, my snap application needs images. I copy them directly in the "./snap" folder and open them with the path "$env(SNAP)/foo.png". Is there a better way to do that ? | 14:36 |
| seb128 | jdstrand, is there a way to allow dbus communication between unity and confined softwares? | 14:37 |
| sergiusens | jdstrand desrt yes, after multiple install/uninstalls will eventually casuse this | 14:37 |
| desrt | specifically, unity needs to make a method call, the app needs to reply, and then the app needs to be able to broadcast signals that unity can see | 14:39 |
| ogra_ | slvn, sounds like an okayish way to me | 14:40 |
| desrt | apps also need to be able to own a specific bus name | 14:41 |
| slvn | ogra_, ok :) | 14:41 |
| slvn | ogra_, maybe a magic CMake instruction, to automate the copy of images to ./snap :/ ? | 14:42 |
| * ogra_ would just use the copy plugin to copy the dir | 14:43 | |
| slvn | ok! | 14:45 |
| kyrofa | slvn, indeed, that's what the copy plugin is for | 14:45 |
| sergiusens | dpm can I have comment permissions to your "Snap this!" doc? | 14:47 |
| sergiusens | dpm thanks! | 14:47 |
| dpm | sergiusens, done | 14:47 |
| sergiusens | dpm yeah, I said thanks when I saw I had access :-) | 14:55 |
| sergiusens | dpm fully commented, every bullet ;-) | 14:55 |
| slvn | ogra_, kyrofa, in fact, I use "install(FILES ${IMAGES} DESTINATION .)" because COPY copy in build/... | 15:02 |
| Trevinho | sergiusens: hey, how can I get snapcraft to be more verbose (or a plugin to be)? | 15:02 |
| kyrofa | slvn, ah, we meant the copy plugin in snapcraft | 15:03 |
| kyrofa | slvn, but doing it in cmake works as well :) | 15:03 |
| sergiusens | Trevinho --debug | 15:04 |
| ogra_ | yeah, indeed | 15:04 |
| slvn | kyrofa, :) well .. since it's now written in the cmakefile .. I'll keep it there.. | 15:04 |
| sergiusens | Trevinho we still have an action to add --verbose which would enable verbose builds for everything that supports it | 15:04 |
| sergiusens | slvn long term, doing it in the build system is the better option | 15:05 |
| Trevinho | sergiusens: ok, thanks | 15:05 |
| Trevinho | sergiusens: it would be cool | 15:05 |
| jdstrand | seb128: sorry, was in several meetings | 15:05 |
| Trevinho | sergiusens: also, what if a nodejs package needs to do npm i multiple dirs (like parent and child folder)? adding two parts does work? | 15:05 |
| jdstrand | seb128: so, what I told willcooke was that if you give me the snap, I can work through the policy issues and update the unity7 interface security policy | 15:06 |
| sergiusens | Trevinho two parts should work | 15:06 |
| kyrofa | slvn, great! | 15:06 |
| sergiusens | Trevinho what are you doing out of curiosity? | 15:06 |
| Trevinho | sergiusens: mh well... it almost does... but then I've an error in looking for files | 15:06 |
| jdstrand | seb128: in the meantime, you can temporarily adjust things in /var/lib/snapd/apparmor/profiles/... then add this rule in between the curly brackets: | 15:06 |
| jdstrand | dbus, | 15:06 |
| sergiusens | Trevinho I have multiple additions for the nodejs plugin (among those, being able to use gulp as the driver) | 15:06 |
| jdstrand | sergiusens: then do: sudo apparmor_parser -r /var/lib/snapd/apparmor/profiles/... | 15:06 |
| jdstrand | err | 15:07 |
| jdstrand | seb128: ^ | 15:07 |
| sergiusens | err | 15:07 |
| sergiusens | :-) | 15:07 |
| Trevinho | sergiusens: as experiment https://github.com/Aluxian/Whatsie | 15:07 |
| jdstrand | seb128: that will allow all dbus calls until you reboot | 15:07 |
| Trevinho | jdstrand: the changes are http://paste.ubuntu.com/16081259/ | 15:07 |
| seb128 | jdstrand, thanks | 15:07 |
| Trevinho | jdstrand: very hacky though | 15:07 |
| jdstrand | seb128: actually, until snapd updates the file, which I think is on reboot but might happen every 12 hours | 15:07 |
| Trevinho | there are hardcoded archs... or | 15:08 |
| Trevinho | cahce files with are not generated | 15:08 |
| Trevinho | cache* | 15:08 |
| jdstrand | oh, you are doing this on i386 and not amd64? | 15:08 |
| seb128 | jdstrand, the pastebin from trevinho are our hacks from the day | 15:08 |
| seb128 | I am | 15:08 |
| seb128 | my laptop is 6 years old never reinstalled | 15:08 |
| jdstrand | I see | 15:08 |
| jdstrand | I could easily adjust locally | 15:08 |
| sergiusens | Trevinho you might want to wait for my gulp branch | 15:08 |
| seb128 | but we have people who tried on amd64 | 15:08 |
| Trevinho | well, yeah... but also in a brandnew VM things do the same | 15:08 |
| seb128 | right | 15:08 |
| jdstrand | Trevinho: that is a diff to my junk branch? | 15:09 |
| seb128 | sergiusens, gulp? | 15:09 |
| Trevinho | sergiusens: ah, ok... | 15:09 |
| Trevinho | jdstrand: yes | 15:09 |
| seb128 | jdstrand, yes | 15:09 |
| jdstrand | ok, I have another meeting in a few minutes but will start playing with this after | 15:09 |
| seb128 | sergiusens, are you telling us we shouldn't have started working on a gnome example because we dup work with you? | 15:09 |
| sergiusens | seb128 no, I am talking to Trevinho ;-) | 15:09 |
| seb128 | jdstrand, k, we are mostly done for today here | 15:09 |
| Trevinho | jdstrand: this is for x86-64 http://paste.ubuntu.com/16082479/ | 15:10 |
| Trevinho | jdstrand: and... you need to copy there /usr/share/mime/mime.cache | 15:10 |
| sergiusens | seb128 carry on with gtk :-) | 15:10 |
| seb128 | sergiusens, well, Trevinho is with us at a team sprint where we collectively work together | 15:10 |
| sergiusens | seb128 oh, well he is looking at a nodejs project | 15:10 |
| seb128 | ah ok | 15:10 |
| * Trevinho too | 15:10 | |
| seb128 | so other thing :-) | 15:10 |
| ogra_ | jdstrand, you should just declare it "notabug" and blame seb128 for skipping laptop refreshes twice already :P | 15:10 |
| jdstrand | ah yes the loaders cache. I would've forgotten about that | 15:10 |
| * Trevinho multi-tasking | 15:10 | |
| jdstrand | Trevinho: thanks! | 15:10 |
| jdstrand | ogra_: hehe | 15:11 |
| sergiusens | seb128 and I've just added gulp support (a nodejs build driver) to the nodejs plugin | 15:11 |
| sergiusens | still missing grunt | 15:11 |
| seb128 | jdstrand, we got gnome-calcultor to work including icons and exported menus and theme (unrestricted), in restricted menus are missing | 15:11 |
| jdstrand | seb128: willcooke said something about you guys pushing a branch somewhere at some point. can you ping me whenever that happens? | 15:11 |
| sergiusens | and the G is not related to glib, gtk or gnome :-) | 15:11 |
| jdstrand | sergiusens: that is great! I have some policy for menus but lacked an app to verify it | 15:12 |
| seb128 | jdstrand, sure, I need to clean up the diff in the pastebin and replace the arch encoded bits | 15:12 |
| jdstrand | darn it | 15:12 |
| jdstrand | seb128: ^ | 15:12 |
| seb128 | k | 15:12 |
| seb128 | great :-) | 15:12 |
| seb128 | jdstrand, we hope that the "have to ship precompiled cache, pixbuf loaders, etc" is going to get replaced by proper solutions over time though | 15:13 |
| ogra_ | be introducing postinst in snaps ? | 15:14 |
| seb128 | that wouldn't help | 15:14 |
| Trevinho | sergiusens: however, in these cases, I should do a custom plugin or is there another way to run gulp? Actually it seems to build the src though | 15:15 |
| seb128 | you don't want each app to ship the glib locales and have to do e.g locale-gen | 15:15 |
| Trevinho | sergiusens: the only thing I did was a simple http://pastebin.ubuntu.com/16082644/ | 15:17 |
| jdstrand | seb128: oh for sure. that is rather icky. but one step at a time :) | 15:17 |
| jdstrand | seb128: curious if you think that means changes to gtk to support snaps (whether that is a plugin or something else) | 15:18 |
| seb128 | jdstrand, are we going to recommend upstream to copy our hacks to include gio, etc caches? | 15:18 |
| jdstrand | seb128: no, I mean design a solution that can work with it | 15:18 |
| jdstrand | basically, I'm curious if you have ideas on what the proper solution will be | 15:19 |
| seb128 | well it's a design choice | 15:19 |
| Trevinho | sergiusens: but then I get something like | 15:19 |
| Trevinho | https://www.irccloud.com/pastebin/1tASMLIM/ | 15:19 |
| seb128 | I think e.g image loaders should be part of the core | 15:19 |
| seb128 | not something appdevs are interested to have a custom copy of | 15:19 |
| jdstrand | seb128: I would tend to agree. ie, ubuntu personal has all these kinds of things, like how touch does | 15:20 |
| seb128 | right | 15:20 |
| seb128 | then things like schemas, etc we need to resolve | 15:20 |
| ogra_ | seb128, i really dont want image loaders in my IoT device :P | 15:20 |
| seb128 | that's why you would install core and not personal | 15:20 |
| ogra_ | (unless its some camera IoT think perhaps) | 15:20 |
| jdstrand | seb128: now whether that is a separate os snap or a special snap that works with the os snap, idk. that is for the architects to decide | 15:20 |
| seb128 | right | 15:21 |
| jdstrand | ok | 15:21 |
| ogra_ | i guess we need some low level library snap from canonical that provides the bits and pieces | 15:21 |
| === oparoz_ is now known as oparoz | ||
| Trevinho | and... with other files... Here's the deubg output | 15:21 |
| * ogra_ would have it called a framework snap :P | 15:21 | |
| Trevinho | https://www.irccloud.com/pastebin/1dNpAbUr/ | 15:21 |
| Trevinho | ogra_: yeah, a framework for gtk/gnome is really needed... | 15:22 |
| ogra_ | except that we killed frameworks with snappy 2.0 | 15:23 |
| ogra_ | (thus the :P above ) | 15:23 |
| Trevinho | yeah, that's what I was worried about.... | 15:23 |
| Trevinho | so, we're going to ship a 66Mb snap for the calculator, and other hundreads of apps? | 15:23 |
| Trevinho | ogra_: ^ | 15:24 |
| ogra_ | and buy stocks of some SSD manufacturer, yeah | 15:24 |
| Trevinho | al least if deduplication was still something we cared about... | 15:24 |
| ogra_ | (i know the prob is known ... but the former solutions were abandoned .... not sure whats in the pipe for that in the future ) | 15:25 |
| oparoz | library snap? | 15:25 |
| ogra_ | that only helps within one namespace | 15:25 |
| ogra_ | per definition | 15:26 |
| oparoz | I thought the goal of the library snap was to offer common tools and space? | 15:27 |
| slvn | Got an apparmor issue "shm_open() failed" when initializing audio. Syslog: apparmor="DENIED" operation="open" name="/dev/shm/pulse-shm-4267673202 | 15:27 |
| seb128 | jdstrand, sergiusens, ogra_, do we have a plug for sound? | 15:27 |
| ogra_ | oparoz, withing your namespace, yes | 15:27 |
| ogra_ | seb128, not yet ... | 15:27 |
| oparoz | ogra_, what do you call the namespace? dev ID? | 15:27 |
| slvn | :( | 15:27 |
| ogra_ | oparoz, yes | 15:28 |
| oparoz | ogra_, makes sense | 15:28 |
| kyrofa | slvn, I don't think we have any audio interfaces yet. I think zyga is working on it | 15:28 |
| slvn | kyrofa, ok np, I will just skip the audio initialization for the moment .. | 15:29 |
| jdstrand | seb128: not yet. zyga and I discussed it a bit yesterday but need niemeyer_'s input | 15:30 |
| ogra_ | just deliver some sheet music alongside your app ... | 15:30 |
| seb128 | k | 15:30 |
| jdstrand | this is again, due to not having a working snap | 15:30 |
| seb128 | well no need of that for calculator | 15:30 |
| seb128 | I've just been playing a bit more, including pulseaudio in a snap and trying paplay | 15:31 |
| jdstrand | seb128: is there an app that is using it? | 15:31 |
| jdstrand | I see | 15:31 |
| jdstrand | seb128: so there are two things at play here (fyi niemeyer_): 1) a pulseaudio snap that works on core proper and 2) pulseaudio access for snaps on classic | 15:32 |
| jdstrand | I foresee the policies to actually be different | 15:32 |
| _morphis | jdstrand, awe_: updated https://github.com/ubuntu-core/snappy/pull/1036 today, would be great if you guys can have another look | 15:33 |
| jdstrand | so we need to work out if for the transition perid of snaps on classic if pulseaudio should just be included in unity7 or maybe a new unity7-audio, and then have the pulseaudio interface for a pulseaudio snap | 15:33 |
| jdstrand | seb128, niemeyer_: ^ | 15:33 |
| seb128 | jdstrand, right | 15:33 |
| jdstrand | niemeyer_: perhaps you have other opinions. personally, I'm leaning towards unity/unity7-audio | 15:33 |
| jdstrand | niemeyer_: but I'm totally open to other options | 15:34 |
| jdstrand | s#unity/unity7-audio#unity7/unity7-audio# | 15:34 |
| seb128 | do we have an human-description of the current plugs? | 15:34 |
| _morphis | jdstrand: sounds good to me as we will use an actual "pulseaudio" interface for the real pulseaudio snap we're doing for core | 15:34 |
| jdstrand | seb128: in docs/interfaces.md. that will be updated on the website in the coming days | 15:35 |
| seb128 | _morphis, how is that going to work? does it mean an app that needs audio is going to be able to depends on the pulseaudio one? | 15:35 |
| * ogra_ wonders if such a setup can even work when pulse runs as a session thing (vs a system daemon) | 15:35 | |
| slvn | also .. SDL_Init(SDL_INIT_JOYSTICK) will say "Can't init SDL JOYSITCK: Could not initialize UDEV: | 15:35 |
| _morphis | seb128: for ubuntu-core not desktop we're going to make an pulseaudio snap | 15:35 |
| ogra_ | i assume the pulse snap will spawn a system process ... | 15:35 |
| ogra_ | (have to) | 15:36 |
| seb128 | _morphis, but can snaps have depends on other snaps/share resources? | 15:36 |
| jdstrand | _morphis: yes. are you guys planning on picking up diwic's work? /me notes that the pulseaudio discussion applies equally to network-manager and bluez | 15:36 |
| _morphis | which will use a "pulseaudio" itnerface to provide slots for other snaps to connect to | 15:36 |
| seb128 | we start having frameworks then? | 15:36 |
| jdstrand | seb128: no, frameworks are dead | 15:36 |
| _morphis | jdstrand: we do but its the last item in the list | 15:36 |
| ogra_ | we just abandoned them :) | 15:36 |
| _morphis | seb128: the only thing you need in your app is a plug using the "pulseaudio" interface | 15:36 |
| seb128 | _morphis, then installation your application would install the other snap? | 15:37 |
| _morphis | and for sure a client lib inside your snap to connect to pulse | 15:37 |
| seb128 | e.g sort of depends? | 15:37 |
| ogra_ | no | 15:37 |
| ogra_ | no depends | 15:37 |
| ogra_ | the interface would simply not be there and you wouldnt get sound | 15:37 |
| seb128 | so your users might get sound working or not | 15:38 |
| ogra_ | yeah | 15:38 |
| _morphis | yes | 15:38 |
| seb128 | "great" | 15:38 |
| seb128 | :-) | 15:38 |
| jdstrand | seb128: instead there are interfaces. a pulseaudio interface can be used on the slot side (server) or the plugs side (client). a pulseaudio snap would declare it provides the pulseaudio slot for apps to connect to. clients declare to use the pulseaudio slot. then UX defines how to surface snaps that plug pulseaudio if you have the pulseaudio snap installed or not (ie, the slot is available for use) | 15:38 |
| jdstrand | s/clients declare to use the pulseaudio slot/clients declare to use the pulseaudio slot via 'plugs'/ | 15:39 |
| _morphis | seb128: could be that we do different pulseaudio itnerface for different use cases if we have to limit certain aspects for security reasons or so | 15:39 |
| seb128 | jdstrand, any dev/snap is going to be able to provide slot side? | 15:39 |
| jdstrand | seb128: that is a pure ubuntu core system. not sdoc | 15:39 |
| ogra_ | _morphis, well, i'm still curious about system daemon vs session daemon ... | 15:39 |
| _morphis | ogra_: I suspect we will only have a system instance on core | 15:40 |
| ogra_ | today every user has his own pulse daemon on a per session base | 15:40 |
| jdstrand | seb128: yes, but if you are declare a slot and the slot is deemed dangerous, then the snap will be flagged for manual review (eventually handled via assertions) | 15:40 |
| jdstrand | seb128: today, all snaps that declare slots are flagged. that will evolve | 15:40 |
| awe_ | ogra_, sure and every user has it's own obexd | 15:42 |
| jdstrand | seb128 (and niemeyer_): as for pulseaudio on sdoc, you can see that there is an interplay there that we need to consider. the ubuntu-core os snap doesn't provide pulseaudio, but it is magically provided by how snappy on classic is implemented. and the pulseaudio on classic is different (and would certainly conflict with) a pulseaudio snap | 15:42 |
| awe_ | ogra_, for snappy, this was changed to work on the system bus | 15:42 |
| jdstrand | so there are questions to be solved | 15:42 |
| awe_ | ogra_, not saying it won't take work... | 15:42 |
| jdstrand | answered* | 15:43 |
| ogra_ | awe_, well, if i look at NM i have a proper split ... might make sense to have that everywhere | 15:43 |
| awe_ | not sure what you mean? | 15:43 |
| awe_ | by NM split? | 15:43 |
| seb128 | jdstrand, thanks, direction looks good :-) it just feels weird that a dev can't declare that his app requires e.g an audio slot | 15:43 |
| ogra_ | NM has a system process and a session process ... | 15:43 |
| ogra_ | pulse currently doesnt allow that | 15:44 |
| seb128 | jdstrand, it means device users might be able to install video player and not be able to get sound which makes the app looks buggy | 15:44 |
| jdstrand | slvn: as for joysticks-- that is going to need an interface. once you figure out what it is that need and perhaps how to get there, please file a bug against snappy and add the snapd-interface tag | 15:44 |
| awe_ | ogra_, there's only one NM | 15:44 |
| awe_ | and it's system | 15:44 |
| jdstrand | seb128: apps do declare it. eg, a game might 'plugs [ network, unity7, pulseaudio ]' | 15:44 |
| ogra_ | awe_, but there is a system wide daemon and there are user-session clients using it | 15:45 |
| awe_ | sure, and on snappy.. there'll be a system-wide daemon, and one or more snaps using it via interfaces | 15:45 |
| jdstrand | seb128 (and niemeyer_): in the pure ubuntu-core system. in the sdoc system, maybe that is 'plugs: [ network, unity7 ]', maybe 'plugs: [network, unity7, unity7-audio ]', maybe something else (that is the discussion | 15:45 |
| ogra_ | awe_, right, but thats not how pulse works atm | 15:46 |
| ogra_ | it hogs the device from userspace via a session daemon | 15:46 |
| jdstrand | niemeyer_: note, I'm effectively CCing you on the conversation but not because we need to have it this second, just so that you have context in the future conversation | 15:46 |
| awe_ | jdstrand, can snaps be restricted from running on a sdoc system? | 15:46 |
| seb128 | jdstrand, thanks | 15:46 |
| awe_ | I don't see any possible use case for a NM snap to be installed there | 15:46 |
| jdstrand | awe_ (and niemeyer_): there is no mechanism for that atm afaik. I guess you are thinking about blocking network-manager from an sdoc system. that is something else to consider for sure (and I think niemeyer_ may be thinking about that already) | 15:47 |
| jdstrand | awe_ (and niemeyer_): it sorta feels like ubuntu-core os snap should only expose certain interfaces on sdoc (eg, unity7, x11) and filter other (network-manager, bluez, pulseaudio, etc). that needs to be worked through | 15:49 |
| awe_ | yea, I've seen enough odd requests to make NM co-exist with other pseudo 'network-managers', but two NMs on the same device seems a super bad idea | 15:49 |
| awe_ | jdstrand, +1 | 15:49 |
| jdstrand | indeed :) | 15:49 |
| ogra_ | awe_, if you hide it and someone is insane enough to upload a wicd snap to the store you get into the same trouble though (and you might not have any control over the person providing the wicd one to sdoc) | 15:50 |
| ogra_ | sounds like a very tricky problem | 15:51 |
| jdstrand | I think snappy could handle that | 15:51 |
| jdstrand | ie, wicd would need an interface too | 15:51 |
| jdstrand | so if network-manager was installed, wicd would not be available | 15:51 |
| ogra_ | well, some standard network-device-access thing | 15:51 |
| jdstrand | and vice versa | 15:51 |
| jdstrand | if neither were installed, both would | 15:52 |
| ogra_ | jdstrand, i'm talking about hiding NM on sdoc | 15:52 |
| awe_ | well... out interface is *very* specific to NM | 15:52 |
| ogra_ | you wont block people from pushing other stuff that breaks this | 15:52 |
| awe_ | I suppose a wicd snap might be able to use it | 15:52 |
| awe_ | however if wicd provided a DBus API it wouldn't work | 15:53 |
| awe_ | but in the end | 15:53 |
| ogra_ | (and you wouldnt block me from providing a naetwork-manager.ogra either) | 15:53 |
| slvn | jdstrand, I'll debug the joystick (and fill a bug report if needed) another day :) | 15:53 |
| awe_ | if they do all the work to create a wicd iface | 15:53 |
| awe_ | then they can upload right? | 15:53 |
| awe_ | and we have the same conflict problem on an sdoc system | 15:53 |
| ogra_ | thats my point :) | 15:53 |
| awe_ | I think if any package is valid example | 15:54 |
| awe_ | it's be commman | 15:54 |
| awe_ | s/it's/it'd/ | 15:54 |
| jdstrand | the idea with interfaces is that they are a sort of contract | 15:54 |
| awe_ | unfortunately bound a little too tight IMHOP | 15:54 |
| jdstrand | if something declares it provides the slor for network-manager, it is network-manager to any clients that connect to it | 15:54 |
| jdstrand | so if wicd can't do that, it needs its own interface | 15:55 |
| awe_ | right, definitely not usable to any other package | 15:55 |
| awe_ | ...but to ogra's point | 15:55 |
| awe_ | there's no reason why we wouldn't upload a connman snap at some point | 15:55 |
| awe_ | and it would have the same issues on an sdoc system | 15:55 |
| jdstrand | yes | 15:55 |
| ogra_ | right ... so how would you filter all of these snaps ... you cant just only forbid n-m on sdoc | 15:56 |
| jdstrand | that will need to be discussed | 15:56 |
| awe_ | the question is where's the line... do we assume people won't do such dumb things, or do we need to add a mechanism to prevent? | 15:56 |
| jdstrand | but connman would have its own interface, so it could be added to the filter | 15:56 |
| jdstrand | (on an sdoc system) | 15:56 |
| awe_ | right | 15:56 |
| jdstrand | (if that is how it is implemented) | 15:56 |
| awe_ | I mean we are reviewing | 15:56 |
| ogra_ | someone would have to maintain all these filter rules then | 15:56 |
| ogra_ | that might become a huge thing | 15:56 |
| jdstrand | maybe | 15:57 |
| ogra_ | given that anyone can invent interfaces | 15:57 |
| jdstrand | no | 15:57 |
| jdstrand | all interfaces go through ubuntu core | 15:57 |
| ogra_ | for the client side ? | 15:57 |
| jdstrand | a snap can't ship an interface | 15:57 |
| ogra_ | ah, i thought i can offer a foobar interface to others when i package foobar | 15:57 |
| jdstrand | it can only implement it (it slots) or consume it (it plugs) | 15:57 |
| awe_ | but it's all in the one interface added to core | 15:58 |
| jdstrand | Ubuntu Core controls the types | 15:58 |
| ogra_ | ok | 15:58 |
| jdstrand | the types are bluez, network-manager, wicd, connman, pulseaudio, etc | 15:58 |
| awe_ | wicd??? really? | 15:58 |
| jdstrand | you can p[rovide an implementation (slots) that uses that type | 15:58 |
| jdstrand | awe_: wicd isn't there now. I was just creating a list based on this conversation | 15:59 |
| jdstrand | ok, I have a meeting | 15:59 |
| awe_ | are we going to provide oss too? | 15:59 |
| awe_ | thanks jdstrand | 15:59 |
| awe_ | ttyl | 15:59 |
| === chihchun is now known as chihchun_afk | ||
| _morphis | ogra_, awe_: we can run pulseaudio easily as system daemon | 16:01 |
| _morphis | pulseaudio --system is all you need | 16:01 |
| ogra_ | _morphis, i thought there were mutil-user reasons to do it the way we do it today | 16:01 |
| _morphis | ogra_: sure | 16:02 |
| ogra_ | like ... not freeing up the interface when you switch users etc | 16:02 |
| _morphis | ogra_: on a multi user system you really don't want --system | 16:02 |
| ogra_ | right | 16:02 |
| _morphis | but on a ubuntu-core system you do | 16:02 |
| _morphis | as we don't have multiple users there anyway | 16:02 |
| awe_ | _morphis, that's what I said earlier | 16:02 |
| awe_ | just like we do with obexd | 16:02 |
| _morphis | yeah | 16:03 |
| _morphis | we will do this with all daemons we're putting on ubuntu-core | 16:03 |
| _morphis | no session bus | 16:03 |
| awe_ | again, we may need to run things differently on core | 16:03 |
| awe_ | this is all new ground | 16:03 |
| jdstrand | _morphis: you mentioned pulse as last on the list. what is the list? I know bluez nm and pulse | 16:03 |
| _morphis | jdstrand: nm, bluez, ofono, modemmanager, pulseaudio | 16:04 |
| jdstrand | cool | 16:04 |
| jdstrand | thanks! | 16:04 |
| _morphis | jdstrand: which includes interconnections between them | 16:04 |
| awe_ | and possibley "rild" | 16:04 |
| _morphis | like we need the nm snap to work with both ofono and modemmanager | 16:04 |
| awe_ | but we may just bundle as part of ofono | 16:04 |
| _morphis | jdstrand: ah not to forget location-service | 16:04 |
| awe_ | still tbd | 16:04 |
| seb128 | calling it a day here | 16:05 |
| seb128 | good evening everyone | 16:05 |
| seb128 | jdstrand, I'm going to clean up things and push tomorrow morning | 16:05 |
| jdstrand | seb128: thanks! hopefully once I'm done with my meetings today I can play with the paste | 16:06 |
| jdstrand | seb128: have a nice evening :) | 16:06 |
| seb128 | cool, let me know tomorrow or it goes (or feel free to drop an email | 16:06 |
| seb128 | thanks | 16:06 |
| seb128 | see you tomorrow! | 16:06 |
| ogra_ | _morphis, user management is on the TODO for core ... so i wouldnt count on single-user-forever | 16:07 |
| awe_ | for s16? | 16:07 |
| awe_ | that's all we care about atm | 16:08 |
| awe_ | can't worry about future problems yet | 16:08 |
| awe_ | ;)- | 16:08 |
| ogra_ | i know mark is pushy to get rid of the ubuntu user | 16:08 |
| ogra_ | but i dont know if for 16 | 16:08 |
| qengho | Er, should sound work from within a snap? Should one use pulseaudio client libraries? | 16:11 |
| ogra_ | LOL !!!! | 16:11 |
| ogra_ | looks like someone missed all the fun of the last 2h backlog in this channel :) | 16:11 |
| ogra_ | qengho, no audio yet | 16:12 |
| qengho | Oh. I did. I saw "kodi" had new release, thought I'd try something ambitious. | 16:14 |
| geneios | Hi guys, I have a question about the python2 plugin. Is there a way to tell the setup.py to include a path? i.e I have a package that depends on a certain numpy version, which requires python-dev, but the path Python.h from python-dev isn't getting included. | 16:15 |
| ogra_ | qengho, if you are really ambitious, try it with Mir as standalone snap ;) | 16:16 |
| niemeyer_ | jdstrand: Sorry for not paying too much attention to the conversations this morning | 16:17 |
| niemeyer_ | jdstrand: Have been in calls for the last several hours | 16:18 |
| niemeyer_ | jdstrand: I think we want network-manager to be a slot offered by ubuntu-core itself in sdoc | 16:18 |
| * niemeyer_ => late lunch | 16:19 | |
| slvn | Install a snap package once, it works fine. But twice (event with version increment), it says : /bin/sh: 0: Can't open /snap/myapp/100002/command-example.wrapper | 16:22 |
| jdstrand | niemeyer_: no worries at all, I was in calls all morning before that, so, I can relate. mostly I wanted you to be aware of the conversations | 16:27 |
| jdstrand | niemeyer_: I can say that if network-manager is a slot in sdoc, then we are going to want to consider different slot and plug policy depending on if running on sdoc or not | 16:28 |
| jdstrand | niemeyer_: in fact, we'll have to cause the security label for network-manager will be 'unconfined' on an sdoc system whereas on a pure core system it will be 'snap.network-manager...'. I know there will be different policy for pulseaudio too | 16:29 |
| jdstrand | niemeyer_: anyway, we can discuss at a more convenient time | 16:29 |
| zyga | jdstrand: I wasn't aware of issues specific to i386, is there a bug open on this? | 16:35 |
| wililupy | So who is a good Snappy Kernel expert? | 17:02 |
| niemeyer_ | wililupy: It's generally easier to shoot question and see who picks it than to fish for self-appointed experts :) | 17:07 |
| wililupy | That's true. niemeyer_ | 17:08 |
| ogra_ | wililupy, ricmm or asac perhaps (asac wrote the basic plugin, and i know ricmm used it quite a lot in the past) | 17:08 |
| wililupy | I'm hitting a brick wall when my kernel snap. I can get it to build, but when I try to boot it fails. | 17:08 |
| ogra_ | how does the boot fail | 17:09 |
| wililupy | I've made it work in the past, but since 2.5 I haven't been able to get one to boot. | 17:09 |
| ogra_ | what are the symptoms then | 17:09 |
| wililupy | When I use it as the kernel in u-d-f it won't boot. It starts grub, I see writable, it tries to boot and I get error: not a regular file | 17:11 |
| wililupy | error: disk 'loop' not found | 17:12 |
| === rcj` is now known as rcj | ||
| ogra_ | ohm that grub thing | 17:12 |
| wililupy | error: you need to load the kernel first and then back to the grub menu | 17:12 |
| === rcj is now known as Guest12905 | ||
| ogra_ | i remember ... but have not much more help to offer ... apart from ... make sure your kernel has all bits builtin the ubuntu kernel also uses | 17:12 |
| ogra_ | the ubuntu kernel has loop device support built in | 17:13 |
| wililupy | If I install the .snap in a working instance, it installs, but never boots to that. | 17:13 |
| wililupy | I verified that, it is a module. | 17:13 |
| wililupy | I'm basically using the 4.4.0-21-generic config | 17:13 |
| ogra_ | ogra@styx:~$ grep DEV_LOOP /boot/config-4.4.0-21-generic | 17:14 |
| ogra_ | CONFIG_BLK_DEV_LOOP=y | 17:14 |
| ogra_ | CONFIG_BLK_DEV_LOOP_MIN_COUNT=8 | 17:14 |
| ogra_ | CONFIG_AUFS_BDEV_LOOP=y | 17:14 |
| ogra_ | not a module here | 17:14 |
| ogra_ | so i'd start there :) | 17:15 |
| wililupy | This is what I have. | 17:15 |
| wililupy | CONFIG_BLK_DEV_LOOP=y | 17:15 |
| wililupy | CONFIG_BLK_DEV_LOOP_MIN_COUNT=8 | 17:15 |
| wililupy | CONFIG_BLK_DEV_CRYPTOLOOP=m | 17:15 |
| ogra_ | ok | 17:16 |
| wililupy | CONFIG_AUFS_BDEV_LOOP=y | 17:16 |
| ogra_ | and you have the squashfs module in your initrd modules ? | 17:16 |
| wililupy | in my snapcraft.yaml yes. | 17:16 |
| wililupy | I tried adding loopback, but snapcraft failed to build with that option so I removed it. | 17:17 |
| ogra_ | (and you also build it i assume ) | 17:17 |
| wililupy | Yep. Snapcraft builds successfully. | 17:17 |
| wililupy | I also have this in my config file for squashfs: | 17:19 |
| wililupy | CONFIG_SQUASHFS=m | 17:19 |
| ogra_ | right, else snapcraft would fail | 17:19 |
| wililupy | CONFIG_SQUASHFS_FILE_DIRECT=y | 17:19 |
| ogra_ | (trying to add a nonexisting module to the initrd) | 17:19 |
| wililupy | CONFIG_SQUASHFS_DECOMP_MULTI_PERCPU=y | 17:19 |
| wililupy | CONFIG_SQUASHFS_XATTR=y | 17:19 |
| wililupy | CONFIG_SQUASHFS_ZLIB=y | 17:19 |
| wililupy | CONFIG_SQUASHFS_LZ4=y | 17:19 |
| wililupy | CONFIG_SQUASHFS_LZO=y | 17:19 |
| wililupy | CONFIG_SQUASHFS_XZ=y | 17:19 |
| jdstrand | zyga: wrt i386> I didn't mean to refer to that. I meant the fact that autoconnect doesn't seem to always work. I noticed it, sergiusens did, seb128 did, kgunn may have, etc. I don't have a reproducer. sergiusens thought it might have to do with uninstalling/installing the same version over and over again | 17:20 |
| === Guest12905 is now known as rcj | ||
| zyga | hmmmmm | 17:20 |
| zyga | interesting | 17:20 |
| zyga | there is a mechanism that blacklists auto-connection | 17:20 |
| zyga | I'll add logging there so that at least we can know it is responsible | 17:20 |
| jdstrand | zyga: for example, I've had 3 different pings on things in the network policy that people were hitting, but they plugged network | 17:20 |
| wililupy | I've used this config in the past with this same kernel and it worked. | 17:21 |
| zyga | jdstrand: there's a bug (now fixed) in 2.0.2 that makes upgrades 100% broken | 17:21 |
| zyga | jdstrand: until we SRU we'll see plenty of intertwined bugs | 17:21 |
| jdstrand | perhaps its that | 17:21 |
| ogra_ | wililupy, and you use the very latest u-d-f ? | 17:21 |
| jdstrand | zyga: though I think kgunn needs some help which looked like a locking issue. he sent an email last night | 17:22 |
| zyga | jdstrand: oh? I need to check | 17:22 |
| jdstrand | zyga: note, I answered kgunn's final slots question in a hangout today | 17:23 |
| wililupy | ogra_ yes. | 17:23 |
| zyga | ok | 17:23 |
| zyga | was the hangout recorded? | 17:23 |
| ogra_ | and also the canonical-pc gadget from the "16" series in the store ? | 17:23 |
| wililupy | I updated it yesterday just to be sure. | 17:24 |
| wililupy | yes, my u-d-f is sudo ./ubuntu-device-flash core 16 --channel=edge --kernel=my-kernal.snap --gadget=canonical-pc --os=ubuntu-core -o my-snappy.img | 17:25 |
| ogra_ | yeah, that should be all fine | 17:25 |
| zyga | jdstrand: I see his email now, I'll work on that next | 17:25 |
| wililupy | However, if I install the snap in the base snappy instance, it installs, I can go to /writable/snaps/my-kernel/ and everything is there, but the system never boots to it, it still says 4.4.0-18-generic instead of 4.4.6 when I do uname -r | 17:26 |
| jdstrand | zyga: cool. fyi, I think I finally have some time to do some policy updates. I have around 10. it would be easiest for my to group at least some of them in the same PR, but is there a commit policy where I need them all separate? | 17:27 |
| zyga | jdstrand: that's up to you, a branch with 10 commits with descriptions is perfect for mew | 17:27 |
| zyga | me* | 17:27 |
| jdstrand | that'll work | 17:27 |
| jdstrand | thanks! | 17:27 |
| zyga | jdstrand: but if you think it would be easier to review separate branches I'm fine with that as well | 17:27 |
| wililupy | And i do that with just scping the .snap to the system, and running sudo snap install my-kernel.snap and it shows up with snap list | 17:28 |
| ogra_ | wililupy, well, you should see why it doesnt boot on the console ... does it actually attempt to boot and just fall back to the other kernel ... does it not attempt the new one at all etc | 17:28 |
| wililupy | It doesn't even attempt the new one. | 17:28 |
| wililupy | No rollback error or anything. | 17:28 |
| ogra_ | right, not sure sideloading lkernel snaps still works with 2.x | 17:28 |
| ogra_ | but it should definitely work with u-d-f | 17:29 |
| ogra_ | i fear you need mvo ... i'm not really good with the grub mishmash we have on the images (it is quite a mess) | 17:29 |
| wililupy | Thats fine ogra_, when does mvo come on? | 17:30 |
| ogra_ | i think he ended his day (i'm not on the internal channel atm, see if you find him there perhaps) | 17:30 |
| wililupy | He's not on the internal channel atm. | 17:31 |
| ogra_ | yeah, thought so | 17:31 |
| wililupy | I'll send him a quick email and see if he has any pointers. I'm getting close to my deadline with this device and I want to be able to give them something besides a procedure that doesn't work. | 17:32 |
| ogra_ | i think wed. is his hockey day | 17:32 |
| zyga | kgunn: hey | 18:04 |
| zyga | kgunn: I'm looking at your branch | 18:04 |
| almejo_ | Hi.. someone has time for a question about packaging a snap app? | 18:06 |
| MichaelTunnell | almejo_: wont know until you ask your question? | 18:07 |
| * zyga was about to reply with the don't ask if you can ask, just ask | 18:08 | |
| MichaelTunnell | :) | 18:08 |
| zyga | kgunn: just FYI, you probably saw this already but just in case: http://www.zygoon.pl/2016/04/anatomy-of-snappy-interface.html | 18:08 |
| kgunn | zyga: nope, so i'll read that in a moment | 18:15 |
| zyga | nothing revolutionary there :) | 18:15 |
| ChrisTownsend | Hi! I guess I need to get the security team's input on https://bugs.launchpad.net/snapcraft/+bug/1575188 ? | 18:26 |
| ubottu | Launchpad bug 1575188 in Snapcraft "Fix for bug #1572664 had broken my snap package build" [Undecided,Incomplete] | 18:26 |
| almejo_ | haha.. thanks. I am trying to package a qml app. It is written in python for the phone. I am traying to figure out the dependencies and I can not find an example of how to do it.. i found something about a qml plugin but it is not listed in snapcraft list-plugins | 18:27 |
| ChrisTownsend | Comment #5 hopefully explains my use case. | 18:27 |
| almejo_ | My last output from starting my app is "qmlscene: could not find a Qt installation of ''" | 18:38 |
| almejo_ | in stage-packages i have: qmlscene, libxcb1, libqtcore5a, libqtgui5, libqtgui5-gles, libpulse0 | 18:39 |
| jdstrand | beuno: hey, can you have someone pull r638 of the review tools for opengl bug #1572140 | 18:40 |
| ubottu | bug 1572140 in Canonical Click Reviewers tools "click-reviewers-tools don't know opengl interface" [Medium,Fix committed] https://launchpad.net/bugs/1572140 | 18:40 |
| sergiusens | jdstrand this is for you https://bugs.launchpad.net/snapcraft/+bug/1575188 | 18:44 |
| ubottu | Launchpad bug 1575188 in Snapcraft "Fix for bug #1572664 had broken my snap package build" [Undecided,Incomplete] | 18:44 |
| sergiusens | jdstrand even thought it will eventually build, not sure it would be a good idea as the next step would be to block it | 18:44 |
| sergiusens | jdstrand as in for you, waiting for your input | 18:44 |
| sergiusens | almejo_ look at dpm's clock app work | 18:45 |
| beuno | jdstrand, sure. cc/ roadmr ^ | 18:45 |
| jdstrand | sergiusens: yes, I added it to my list of things to look at this week | 18:45 |
| roadmr | beuno, jdstrand : no problem, I'm on it | 18:45 |
| jdstrand | roadmr: thanks! | 18:46 |
| jdstrand | roadmr: fyi, that has no code changes, just a change to a data file for the store to consume (not sure how far back the store is at this point, so maybe it is a super fast pull-- up to you) | 18:46 |
| almejo_ | sergiusens ¿dpm clock? the one in snap find? The phone clock? | 18:46 |
| roadmr | jdstrand: we're at 636, have been since Monday | 18:47 |
| jdstrand | oh yes | 18:47 |
| almejo_ | I would love to see the snapcraft.yaml of the app | 18:47 |
| jdstrand | then this is fast | 18:47 |
| roadmr | jdstrand: yes :) it's just a matter of negotiating the test -> land -> CI -> staging -> production pipeline | 18:47 |
| jdstrand | roadmr: not sure what your processes are, but extremely low risk | 18:47 |
| jdstrand | ack | 18:48 |
| jdstrand | I'll leave it in your capable hands :) | 18:48 |
| roadmr | jdstrand: so I point a config file to the desired revno, commit, wait ~40 minutes for it to be on staging, test manually, if all is OK request a prod deployment | 18:48 |
| jdstrand | nice | 18:48 |
| roadmr | jdstrand: (btw, my manual test is just uploading a package and checking the c-r-t version reported is the expected one. If ever you want more detailed testing, let me know, I can check for more specifics if needed) | 18:49 |
| jdstrand | roadmr: ack, good to know | 18:49 |
| sergiusens | almejo_ yeah, clock or calculator, I forget | 18:50 |
| almejo_ | I know the apps and I can browse de app.. but I can not find the snapcraft.yaml. It seems that it is not part of the project... | 18:51 |
| ogra_ | http://bazaar.launchpad.net/~snappers/snappy-desktop-examples/trunk/files/head:/ubuntu-clock-app/ | 18:53 |
| sergiusens | almejo_ this might be an abandoned branch, but here you go bzr+ssh://bazaar.launchpad.net/~dpm/ubuntu-clock-app/snap-all-things/ | 18:53 |
| almejo_ | thanks!!! exactly what i was looking for! | 18:53 |
| almejo_ | thanks for your time :D | 18:54 |
| sergiusens | almejo_ the `environment` part can probably replaced by an `after` like in https://github.com/dplanella/snappy-playpen/blob/master/notes/snapcraft.yaml | 18:54 |
| almejo_ | thanks again | 18:55 |
| sergiusens | np | 18:57 |
| zyga | roadmr: hey | 19:01 |
| zyga | roadmr: I'll be in canada next week | 19:01 |
| roadmr | hello zyga ! | 19:01 |
| zyga | next +1 | 19:01 |
| roadmr | zyga: awesome! it's across the country from me | 19:02 |
| zyga | roadmr: yeah, I tried to have a 24 layover in montreal but no luck | 19:02 |
| roadmr | zyga: :( well bummer, but I've heard good things about where you're going :) | 19:03 |
| roadmr | zyga: (I've never been there - maybe some day) | 19:03 |
| roadmr | zyga just vanished haha | 19:03 |
| * zyga always suspends with some darn shortcut when switching keyboards | 19:04 | |
| zyga | roadmr: are you sprinting anytime soon? I heard that some people from your team are going too | 19:04 |
| roadmr | zyga: yes! not me though, sorry :( recently-arrived baby means I have to stay here and help | 19:05 |
| zyga | ah, the fantastic and terrible things that await you :) | 19:05 |
| zyga | I'm trying to convince my son to finish his english homework :-/ | 19:05 |
| roadmr | zyga: yes, he's 3 months old and it's felt like 5 minutes... (underwater haha) | 19:05 |
| zyga | he loves spanish, doesn't digest english | 19:06 |
| zyga | it gets easier after three years | 19:06 |
| roadmr | zyga: YEARS!?! NOOOO /o\ | 19:06 |
| zyga | ...after they move out ;-) | 19:06 |
| zyga | oops, weren't supposed to tell you so quickly ;) | 19:06 |
| roadmr | zyga: http://theoatmeal.com/pl/minor_differences4/kids | 19:07 |
| zyga | ohhh yes | 19:07 |
| zyga | I know that by the URL :D | 19:07 |
| roadmr | :) | 19:07 |
| zyga | reality is much worse | 19:07 |
| zyga | much more subtle :) | 19:07 |
| roadmr | yeah heh | 19:09 |
| roadmr | zyga: I didn't tell you - *I* was doing it wrong, that's why I couldn't build the image, remember I had that weird "0 partitions found" error? | 19:09 |
| zyga | roadmr: yeah, what was the problem? | 19:10 |
| roadmr | zyga: it's because I was trying it inside an lxc. Once I did it natively, it worked. | 19:10 |
| zyga | ah, yes, I head that people bumped into this before | 19:10 |
| zyga | layers of layers of software | 19:10 |
| roadmr | zyga: I've also been unable to snap install inside an lxc, even with a privileged, nesting container. I wonder if we'll ever want snap to work inside containers, I imagine so :) | 19:10 |
| zyga | I wonder if it is because of older kernel or because of something that lxc does itself | 19:10 |
| roadmr | zyga: it's a xenial system so I don't think it's an old kernel :D | 19:11 |
| zyga | roadmr: I know this too, this will need lots of work on the kernel and snappy side first | 19:11 |
| zyga | roadmr: apparmor namespaces are required first (those are under way as the security savvy people tell me) | 19:11 |
| roadmr | yay :) | 19:11 |
| zyga | roadmr: right now kvm works very well but lxc won't for 16.04 | 19:12 |
| roadmr | zyga: yes, I'm running stuff under virtualbox and/or kvm for snap work | 19:12 |
| zyga | roadmr: running natively on xenial is also an option, it's usually not a disastrer if it breaks | 19:13 |
| roadmr | usually? /o\ haha :) | 19:13 |
| zyga | no bank account interface yet ;) | 19:13 |
| roadmr | 'show-me-the-money' as a plug? | 19:13 |
| zyga | no, that's flashlight app 2.0 | 19:14 |
| zyga | "flashlight needs access to your bank account, allow or deny?" | 19:14 |
| roadmr | haha :) | 19:15 |
| zyga | next to the "deny" button there is a nice animated icon saying "don't miss out on mr flashy" | 19:16 |
| zyga | nah, that was android | 19:16 |
| zyga | we're better :) | 19:16 |
| sergiusens | zyga roadmr lxc and u-d-f might just probably fail due to kpartx and needing access to kernely things to map that | 19:22 |
| jdstrand | zyga and roadmr: fyi, a lot of work happened with what is called apparmor stacking to support just that. it didn't all land by 16.04 release, but we hope to have enough of it completed by 16.04.1 so that you can run one level deep. Ie, running a full system (ie Ubuntu Core) in lxd so you can install snaps. however, running lxd inside of lxd or snappy in lxd on ubuntu core will not be supported since those required 2 levels deep | 19:32 |
| jdstrand | tyhicks: please correct me ^ | 19:32 |
| roadmr | jdstrand: cool!! | 19:32 |
| jdstrand | zyga and roadmr: when implemented nesting > 1 may be possible to backport to 16.04, at least with a backport kernel | 19:32 |
| roadmr | jdstrand: yes, I imagine if we're to push snaps as a format going forward, it makes sense to ensure they work inside lxd, which we're also pushing :) | 19:32 |
| jdstrand | yes | 19:33 |
| roadmr | jdstrand: not sure "all the way down" will be so useful, but at least one level deep should be | 19:33 |
| jdstrand | people will then want to run snappy in lxd on snappy, but that is a bit farther out. it requires upstream kernel changes and a few other things | 19:33 |
| roadmr | jdstrand: thanks for the info! at least I know this is known and I'm not crazy :) | 19:33 |
| jdstrand | it is very much known and you are not crazy | 19:34 |
| jdstrand | at least not because of this ;) | 19:34 |
| tyhicks | jdstrand: I think "snappy in lxd on ubuntu core" should only require 1 level deep container | 19:35 |
| jdstrand | tyhicks: well... remember, lxd will be running under a label that is not unconfined | 19:36 |
| jdstrand | tyhicks: I'm not sure how that plays into it, but snappy in lxd on snappy would certainly be nice to have in 16.04 | 19:37 |
| jdstrand | tyhicks: I guess it would be one level though cause lxd is still in the global namespace | 19:37 |
| tyhicks | right | 19:37 |
| jdstrand | ok, even better :) | 19:38 |
| tyhicks | only one thing is stacking and that's lxd | 19:38 |
| jdstrand | roadmr: ^ | 19:38 |
| jdstrand | tyhicks: thanks :) | 19:38 |
| wililupy | ogra_ This is interresting, looking at my grubenv on sda2, I don't have a reference to snappy_kernel. I have one for snappy_os. | 19:38 |
| tyhicks | jdstrand: np - it is very confusing to think of the profile transitions and stacks involved there.. | 19:38 |
| ogra_ | wililupy, looks like u-d-f doesnt pick up your kernel snap properly then :/ | 19:38 |
| ogra_ | it should put that variable in place at image creation time | 19:39 |
| wililupy | ogra_ I'm going to manually add it and see what that does... | 19:39 |
| ogra_ | (probably u-d-f has an issue with your version string ? ... ) | 19:40 |
| jdstrand | tyhicks: indeed. I need to focus on the policy namespaces involved and then I should be able to remember | 19:40 |
| ogra_ | (wild guessing here) | 19:40 |
| wililupy | or possiably the name? | 19:40 |
| ogra_ | did you use any unusual chards in the name ? | 19:40 |
| ogra_ | **chars | 19:40 |
| ogra_ | (writing it in arabic or chinese ? ) | 19:41 |
| ogra_ | :P | 19:41 |
| wililupy | no | 19:41 |
| ogra_ | yeah, i thought so | 19:41 |
| wililupy | well, it finds my kernel and tries to boot now, but it hangs after running /scripts/local-premount ... grep: /proc/device-tree/model: no such file or direcotry | 19:45 |
| pedronis | ogra_: u-d-f doesn't care much about the names, it cares very much about being able to open the snaps and the type in them | 19:47 |
| wililupy | findfs: unabled to resolve 'LABEL=writable' | 19:47 |
| ogra_ | pedronis, well, it calls snap install ... and that has issues with certain version strings ... (like ... yu cant use colons for example) | 19:47 |
| pedronis | ogra_: is this 15.04? | 19:48 |
| ogra_ | wililupy, ignore the device-tree thing ... | 19:48 |
| ogra_ | pedronis, nope | 19:48 |
| pedronis | we don't care about versions anymore much in 2.0 | 19:48 |
| ogra_ | wililupy, ext4 compiled in ? | 19:48 |
| wililupy | Yeah, it just looked like it hung, it just popped up the latest error for findfs | 19:48 |
| ogra_ | pedronis, ah, cool | 19:48 |
| pedronis | because the logic is about revisions now | 19:48 |
| pedronis | and from sideloaded stuff in u-d-f you just get revision== | 19:49 |
| pedronis | 0 | 19:49 |
| ogra_ | yeag | 19:49 |
| wililupy | ogra_ yes | 19:49 |
| pedronis | (bit of a corner case that will be different with ubuntu-image) | 19:49 |
| ogra_ | wililupy, you should have an initrd shell now | 19:49 |
| wililupy | CONFIG_EXT4_FS=y | 19:49 |
| wililupy | CONFIG_EXT4_USE_FOR_EXT2=y | 19:49 |
| wililupy | CONFIG_EXT4_FS_POSIX_ACL=y | 19:49 |
| wililupy | CONFIG_EXT4_FS_SECURITY=y | 19:49 |
| wililupy | CONFIG_EXT4_ENCRYPTION=m | 19:49 |
| wililupy | CONFIG_EXT4_FS_ENCRYPTION=y | 19:49 |
| ogra_ | so you can inspect further | 19:49 |
| wililupy | now I'm bumped to busybox... | 19:50 |
| ogra_ | yeah | 19:50 |
| ogra_ | check /proc/modules and see if squashfs is loaded | 19:50 |
| pedronis | ogra_: anyway getting one boot var set and not the other afaict is a bit of a corner case, staring at code you will need something like the kernel not having the right type set in snap.yaml | 19:50 |
| pedronis | or something like that | 19:50 |
| pedronis | looking it doesn't like u-d-f checks that the things have passed have the right types | 19:51 |
| pedronis | it will just skip setting the boot var though | 19:51 |
| pedronis | for maximum confusion | 19:51 |
| wililupy | cat /proc/modules: | 19:51 |
| ogra_ | pedronis, well, wililupy uses snapcraft to roll the kernel snap ... i'D expect the snap.yaml to be fine | 19:51 |
| wililupy | squashfs 49152 0 - Live 0xffffffffc0000000 | 19:52 |
| ogra_ | looks good | 19:52 |
| pedronis | the other chance is that u-d-f does the right thing but firstboot unsets it | 19:53 |
| ogra_ | nah | 19:53 |
| ogra_ | the issue shows on freshly built imgs as i understand it | 19:54 |
| pedronis | it has logic to swap things around for crash fallbacks | 19:54 |
| wililupy | pedronis, that is interresting, becuase after first boot, I get my error message, then it says that it is going to trial reboot and then it gives me the same error message. | 19:54 |
| ogra_ | before firstboot ran | 19:54 |
| pedronis | ah | 19:54 |
| ogra_ | wililupy, huh ? | 19:54 |
| pedronis | but IÂ don't know what it does if there's no fallback | 19:54 |
| ogra_ | wililupy, are we talking about the same thing then ? | 19:54 |
| ogra_ | wililupy, i thought you use your kernel snap with u-d-f | 19:54 |
| wililupy | ogra_ yes. After first boot after building with u-d-f I get my three error: messages, it then says it is going to trial reboot, and i get the three error: messages and then it takes me to the grub menu. After that, I just get the same three error messages, and that only happens after I do a fresh image using u-d-f | 19:55 |
| ogra_ | (dont tinker with instaled systems and trying to sideload your kernel ... that might hit other issues which we wont really resolve) | 19:55 |
| wililupy | ogra_ np. I'm just working with my u-d-f image now. | 19:56 |
| kgunn | zyga: hey, so i get the point of having plugs and slots in the same interface for a server/client...but just for development, i can just populate the slot side to get the server going right? (and just leave the plug stuff empty for the moment) | 19:56 |
| pedronis | that's actually boot-ok to be precise, anyway this may be the bootloader part of that logic | 19:56 |
| pedronis | which I don't know about | 19:57 |
| ogra_ | that part is pretty trivial actually | 19:57 |
| ogra_ | (lives in https://code.launchpad.net/~snappy-dev/snappy-hub/snappy-systems in the grub.cfg or uboot.env.in files) | 19:57 |
| wililupy | I added snappy_kernel=im-kernel_0.snap in the (hd,1)/EFI/grub/grubenv | 19:58 |
| wililupy | which now I get my kernel to load up, but now I get initramfs errors and dumped into busybox. | 19:59 |
| wililupy | I got this problem before due to now having squashfs in my initrd module in my snapcraft.yaml, but that is fixed now. | 19:59 |
| ogra_ | yeah, but it obviously cant find the label for the writable partition | 20:00 |
| ogra_ | which is a bit strange | 20:00 |
| wililupy | The last error I got before this was findfs: unabled to resolve 'LABEL=writable' | 20:00 |
| pedronis | ogra_: anyway IÂ checked nothing except install (which would be u--d-f) sets those vars in snappy itself | 20:00 |
| ChrisTownsend | I have the home interface included in the plugs in my yaml and once I have the connection made. However, the binary wrapper script that is used has $HOME re-exported to a different location. How am I supposed to access things in ~/ ? | 20:00 |
| ogra_ | wililupy, right ... | 20:01 |
| ogra_ | it is like the label is missing or some such | 20:02 |
| ogra_ | (which i dont belive) | 20:02 |
| pedronis | ChrisTownsend: there's been a bit of discussion around that, atm home means that if you get a path to something there you can access it, doesn't quite mean you get a handle to it, unless you go from user id to its value | 20:03 |
| ogra_ | wait-for-root "LABEL=$label" "${ROOTDELAY:-180}" | 20:03 |
| ogra_ | thats the code we call ... | 20:04 |
| ChrisTownsend | pedronis: Ah, ok, well, I guess there is no way to map in the common XDG directories to the app in the snap. | 20:05 |
| pedronis | ChrisTownsend: maybe there's already a bug that zyga knows about, otherwise we probably need one, there's a bunch of requirements a bit colliding with each other at moment in that area | 20:06 |
| ChrisTownsend | pedronis: As the thing I'm working on would like to use ~/Documents, ~/Music, etc. | 20:06 |
| ChrisTownsend | pedronis: Ok, thanks. | 20:06 |
| ogra_ | hmm | 20:07 |
| zyga | kgunn: yes, just have the other unused methods return nil, nil | 20:09 |
| kgunn | cool | 20:10 |
| kgunn | swamped today with manager stuff...but will get on this more tomorrow | 20:10 |
| wililupy | Is there a reason system-boot is fat32? Is it due to it being the EFI partition? | 20:20 |
| ogra_ | yes | 20:20 |
| ogra_ | it also guarantees to work with all bootloaders across the board | 20:21 |
| wililupy | ogra_ gotcha. I'm looking at the partition layout right now. I have three partitions on /dev/sda sda1 is labeled grub unknown fs | 20:21 |
| wililupy | sda1 is labeled system-boot fat32 | 20:21 |
| ogra_ | and writable | 20:21 |
| ogra_ | thats about right | 20:22 |
| wililupy | and sda3 is writable | 20:22 |
| wililupy | ext4 | 20:22 |
| ogra_ | right | 20:22 |
| wililupy | labels are right | 20:23 |
| ogra_ | well, but findfs doesnt find it | 20:23 |
| wililupy | Thats funny, from my ubuntu rescue session on my device, findfs LABEL=writable, it finds /dev/sda3 | 20:25 |
| almejo_ | Guys... another question if someone can help me. I need to run 'pip3 install hangups' in my snap. Is it possible in snapcraft right now? | 20:25 |
| ogra_ | wililupy, tyr the same in the initrd shell on teh image ... perhaps yu get more interesting errors | 20:26 |
| wililupy | ogra_ I'm booting it up right now, waiting for it to timeout... | 20:27 |
| ogra_ | the fun thing is ... | 20:27 |
| ogra_ | in the code we first call | 20:27 |
| ogra_ | wait-for-root "LABEL=$label" "${ROOTDELAY:-180}" | 20:28 |
| ogra_ | and then | 20:28 |
| ogra_ | findfs LABEL=$label | 20:28 |
| ogra_ | the first one doesnt seem to fail | 20:28 |
| ogra_ | (since that would spit out a different error) | 20:28 |
| sergiusens | elopio for some reason I cannot see http://162.213.35.179:8080/job/github-snapcraft-autopkgtest-cloud/600/ | 20:29 |
| sergiusens | mind giving me some crumbs to look at? | 20:29 |
| geneios | alemjo, I think you can use the "python-packages:" keyword with "hangups" as the value | 20:30 |
| almejo_ | thanks!!! :D | 20:30 |
| geneios | I was able to use it to pip install some dependencies in my snap, but I am still struggling if python-dev is required | 20:31 |
| almejo_ | and last question about the life cicle of snaps. If i build a snap, and then I add a new dependency, the only way to build the package again is to do a snap clean? | 20:31 |
| almejo_ | I am a little tired of cleaning every time and wait for all the packages to download | 20:32 |
| LinuxGuy2020 | Hello I was trying to follow the snapcraft tutorial online and got the snap to build but I'm wondering how to skip the publication step and just install it for personal use only or just to test it out before publishing. Is there a way? | 20:32 |
| almejo_ | LinuxGuy2020, snap install app.snap | 20:32 |
| niemeyer_ | jdstrand: About the networkmanager interface, where do we stand? | 20:32 |
| niemeyer_ | jdstrand: I was a bit surprised by the comment that this should be black listed on 16.04.. why isn't it a slot on the os snap? | 20:33 |
| ogra_ | niemeyer_, what do you do if someone installs the NM snap on a desktop ? | 20:34 |
| jdstrand | niemeyer_: the actual mp I think is blocked on you deciding the name and zyga refactoring the bluez code for the slot side dbus apparmor label. I do plan to also look at the latest comments regarding bus policy | 20:34 |
| ogra_ | (where you already have NM running) | 20:34 |
| wililupy | same error, unable to resolve 'LABEL=writable' | 20:34 |
| niemeyer_ | ogra_: See above.. the point isn't to install the snap on the desktop, but to make the interface available in the os snap | 20:34 |
| jdstrand | niemeyer_: then there is that question-- how to handle nm on classic vs nm on core+snap | 20:35 |
| ogra_ | niemeyer_, ah, sorry, i thought it was the same "blacklisting" we talked about above | 20:35 |
| ogra_ | now jamie brought it into the discussion :) | 20:35 |
| * jamiebennett hides | 20:35 | |
| jamiebennett | What did I do? | 20:35 |
| jdstrand | jamiebennett: me :) | 20:35 |
| ogra_ | jamiebennett, the other one ;) | 20:36 |
| * jamiebennett dodges another | 20:36 | |
| jdstrand | niemeyer_: so, if we do as you suggest, then snapd needs to be adjusted to create different snippets if it is running on classic vs pure core | 20:36 |
| LinuxGuy2020 | almejo_: Thats what I tried the other day but it attempted to download something first and failed.Maybe I didnt build the snap correctly or something. I'm just trying to make snaps for packages that are already available as debs. That way I can use store them on local drives more easily than a boat load of debs. Is there a better tutorial explaining just converting pre-existing debs to snaps? | 20:37 |
| wililupy | Here's a new error: | 20:37 |
| niemeyer_ | jdstrand: Yeah, that seems appropriate | 20:37 |
| jdstrand | niemeyer_: cause at a minimum the labels will be wrong | 20:37 |
| LinuxGuy2020 | Or should I just keep trying the way I was before. | 20:37 |
| niemeyer_ | jdstrand: Well | 20:37 |
| LinuxGuy2020 | I was following this https://developer.ubuntu.com/en/snappy/build-apps/your-first-snap/ | 20:37 |
| niemeyer_ | jdstrand: This is the same story we discussed for the bluez snap | 20:37 |
| wililupy | findfs [ 383.689847] random: nonblocking pool is initialized | 20:37 |
| jdstrand | niemeyer_: but I know for a fact we will have different actual policy for pulseaudio on classic vs core | 20:37 |
| niemeyer_ | jdstrand: It's bogus to cook a snippet hardcoding the name of the snap | 20:37 |
| LinuxGuy2020 | It seems very vague though. | 20:37 |
| jdstrand | niemeyer_: no, you misunderstand | 20:37 |
| niemeyer_ | jdstrand: Ah..? | 20:38 |
| ogra_ | wililupy, thats just mess-up of the console messages ... | 20:38 |
| jdstrand | niemeyer_: I'm assuming that patch will be committed | 20:38 |
| ogra_ | wililupy, not an error | 20:38 |
| wililupy | ogra_ ack | 20:38 |
| niemeyer_ | jdstrand: Sorry, I don't understand the idea about the labels being wrong then? | 20:38 |
| jdstrand | niemeyer_: what I'm saying is that the label of the slot side on sdoc would be 'unconfined' but on pure core it will be the slot side snap (ie, snap.nm...) | 20:39 |
| jdstrand | niemeyer_: but beyond that, we will likely want different rulesets on sdoc vs pure core | 20:39 |
| almejo_ | LinuxGuy2020: That tutorial is about dowloading a .deb form the archives and packaging it with other tools. is that what you want? I know other tutorial in www.zygoon.pl/2016/04/snappy-snapcraft-and-interfaces.html | 20:40 |
| jdstrand | niemeyer_: for example, on core, there is no policykit, on sdoc there is. this affects the policy. there will be cases where the rules aren't strictly additive so we need to consider that when deciding on this | 20:40 |
| niemeyer_ | jdstrand: Well, I think on sdoc we don't even need a snippet at all, do we? | 20:40 |
| niemeyer_ | jdstrand: On the slot side, that is | 20:41 |
| jdstrand | niemeyer_: if there is no snippet there is no access | 20:41 |
| jdstrand | there is a slot side and a plug side | 20:41 |
| niemeyer_ | jdstrand: nm is running already, unconfined | 20:41 |
| wililupy | ogra_ I'm not seeing any sd* in /dev... | 20:41 |
| LinuxGuy2020 | almejo_: I just need a tutorial to make a snap out of lets say the ardour3.deb thats in the repos already. But of course the snap would have all the dependencies included. Thats all Im looking for. | 20:41 |
| jdstrand | the plug side needs the label of the slot side | 20:41 |
| ogra_ | wililupy, aha | 20:42 |
| ogra_ | wililupy, so still some kernnel config bit missing i guess | 20:42 |
| niemeyer_ | jdstrand: So how would that work? | 20:42 |
| niemeyer_ | jdstrand: nm is already running.. | 20:42 |
| ogra_ | wililupy, do you have devtmpfs enabled ? | 20:42 |
| jdstrand | niemeyer_: I'm not talking about nm being confined. I'm talking about the plug side snippet a) needed label=unconfined on sdoc vs label=snap.whatever on pure core and b) different apparmor rules on sdoc vs on pure core | 20:42 |
| LinuxGuy2020 | almejo_: What would be the best tutorial for me to follow for that? | 20:43 |
| wililupy | CONFIG_DEVTMPFS=y | 20:43 |
| wililupy | CONFIG_DEVTMPFS_MOUNT=y | 20:43 |
| ogra_ | wililupy, oooooh ! i know what it is !!!! | 20:43 |
| jdstrand | niemeyer_: sdoc and ubuntu core are radically different and the security policy is going to have to deal with that sort of thing | 20:43 |
| wililupy | ogra_ please tell please tell please tell..... | 20:43 |
| almejo_ | LinuxGuy2020 I followed the second one and it builds ok. Also, that one teaches you about plugs and slots, something absolutly necesary | 20:44 |
| niemeyer_ | jdstrand: Yeah, absolutely | 20:44 |
| ogra_ | wililupy, add ahci to your initrd modules (or compile it in) | 20:44 |
| jdstrand | on sdoc nm is unconfined and has one label, on pure core it is confined and has snap...., on sdoc it is compiled with polkit, on pure core not, etc, etc | 20:44 |
| almejo_ | LinuxGuy2020, the firstone is also good. Read both :D | 20:44 |
| niemeyer_ | jdstrand: So is "unconfined" a magic label to tell the process has no labels? | 20:44 |
| ogra_ | wililupy, and perhaps also libahci | 20:44 |
| wililupy | ogra_ I have this in my config: | 20:45 |
| wililupy | CONFIG_SATA_AHCI=m | 20:45 |
| wililupy | CONFIG_SATA_AHCI_PLATFORM=m | 20:45 |
| wililupy | CONFIG_SATA_INIC162X=m | 20:45 |
| wililupy | CONFIG_SATA_ACARD_AHCI=m | 20:45 |
| wililupy | CONFIG_SATA_SIL24=m | 20:45 |
| jdstrand | niemeyer_: if a process is launched without using aa_change_profile/aa_change_on_exec and there is no binary attach policy for it in /etc/apparmor.d, then it automatically defaults to have the unconfined label (and policy) | 20:45 |
| wililupy | CONFIG_ATA_SFF=y | 20:45 |
| ogra_ | wililupy, right, it is a module ... and you need it in the initrd | 20:45 |
| LinuxGuy2020 | almejo_: ok thanks. Should the system need to download any files before it actually installs the snap? Cause the ones I built were trying to download something like 64.64MB or something like that. No idea what it was. | 20:45 |
| niemeyer_ | jdstrand: Gotcha | 20:45 |
| ogra_ | wililupy, or compile it in | 20:45 |
| jdstrand | eg, most process on desktop are 'unconfined' (see ps auxZ) | 20:45 |
| jdstrand | most on snappy are confined (well, depending how many snaps you have installed :) | 20:46 |
| almejo_ | LinuxGuy2020, When you build a snap, it downloads all the dependecies specified in snapcraft.yaml. Then it build the snap using ALL the dependencies creating a really big .snap file | 20:46 |
| wililupy | I gotcha I see,so add ahci to the kernel_initrd_modules in snapcraft.yaml? | 20:46 |
| niemeyer_ | Nice | 20:46 |
| almejo_ | LinuxGuy2020, then, you have to install that snap. It will not dowload other files | 20:46 |
| ogra_ | wililupy, right ... | 20:46 |
| niemeyer_ | THe output, not the fact they're unconfined :) | 20:46 |
| jdstrand | niemeyer_: so, we can do it your way, but if we do, then snapd needs to make decisions about the system at runtime. in some ways that is nice, but in others it is pretty magical and adding complexity | 20:47 |
| LinuxGuy2020 | almejo_: Right. Then I got the *.snap file and tried the sudo snap install *.snap whatever the name was. Ill just try again and see exactly what happens at that point. | 20:47 |
| niemeyer_ | jdstrand: Well, I don't see it as magical, or even as adding relevant complexity | 20:47 |
| almejo_ | LinuxGuy2020, yes. The snap will be installed in /snap/ | 20:47 |
| niemeyer_ | jdstrand: The whole point of the interface system is to enable snaps to interoperate in the different enviornments | 20:48 |
| pedronis | niemeyer_: it seems we need some internal blessed way to know if we are on sdoc vs other scenarios (we need to cleanup firstboot and friends also) | 20:48 |
| almejo_ | LinuxGuy2020, you can go to /snap/bin and see the executable files | 20:48 |
| jdstrand | niemeyer_: an alternate approach would be what I was saying before-- implement nm, bluez, et al as pure core interfaces, then filter them out on sdoc systems. then adjust unity7(*) accordingly for common policy (since it is transition policy) | 20:48 |
| niemeyer_ | jdstrand: having a network-manager interface that works only on devices would be super awkward | 20:48 |
| jdstrand | niemeyer_: I didn't think interfaces really solved anything with pure core vs sdoc. I thought it solved snaps slotting interfaces and connecting in arbitrary ways | 20:49 |
| pedronis | niemeyer_: we need *it* to cleanup firstboot | 20:49 |
| wililupy | ogra_ I'll give it a shot and see what happens. | 20:49 |
| niemeyer_ | pedronis: Hmm.. tell me more? | 20:49 |
| niemeyer_ | jdstrand: Isn't that what we're talking about? | 20:49 |
| pedronis | niemeyer_: we need to know to skip firstboot code etc when setting up from empty state | 20:49 |
| jdstrand | niemeyer_: I think it is a bit awkward that nm is considered part of the os snap on sdoc but it needs a snap on pure core | 20:50 |
| niemeyer_ | jdstrand: We have a network manager process in the system, and a network-manager interface.. why would it work on one device and not the other | 20:50 |
| niemeyer_ | ? | 20:50 |
| pedronis | seems we need it now also to drive interface behavior | 20:50 |
| jdstrand | niemeyer_: sorta, but an area we never really explored | 20:50 |
| niemeyer_ | jdstrand: That sounds like a misunderstanding about interfaces | 20:50 |
| LinuxGuy2020 | almejo_: Ok im starting with a clean install on my laptop instead of using the live environment. Ill try again and come back if I have issues. Thanks. | 20:50 |
| pedronis | the all point is that you don't need to know what providing the slot | 20:51 |
| jdstrand | niemeyer_: there is also the issue of not wanting to install the nm snap on an sdoc system. that is perhaps solved if snapd blocks installing multiple snaps that slot the network-manager type, and ths os snap is shown to slot that on sdoc | 20:51 |
| almejo_ | LinuxGuy2020, great!!! But I am going home now.. I hope someone else can help you... or maybe tomorrow | 20:51 |
| LinuxGuy2020 | almejo_: thats cool | 20:51 |
| niemeyer_ | pedronis: Right, exactly | 20:51 |
| niemeyer_ | jdstrand: That's a good idea | 20:52 |
| jdstrand | niemeyer_: I see where you are coming from, but the network-manager interface on sdoc will be different because it is on sdoc (ie, the security policy will be different). I thought that the interface provides a contract between the client and the slot | 20:52 |
| niemeyer_ | jdstrand: The security policy is the implementation | 20:52 |
| jdstrand | niemeyer_: therefore a snap plugging nm may work on core but not on sdoc, or vice versa, because it is a different contract | 20:53 |
| niemeyer_ | jdstrand: It's a bit like saying the bits on amd64 need to be different than on arm to provide the same CLI experience | 20:53 |
| jdstrand | I don't think that is an apt analogy | 20:53 |
| niemeyer_ | jdstrand: Surely they must be different.. what we're trying to preserve is the paltform behaivor, not how it is implemented | 20:53 |
| pedronis | jdstrand: sounds more like it shouldn't be one interface then but needs more granularity, no? | 20:53 |
| pedronis | if it's really diverging that much | 20:53 |
| jdstrand | pedronis: that is another option, arguably also awkward | 20:53 |
| jdstrand | really, all of the options have warts | 20:53 |
| jdstrand | cause we are shoehorning classic into the new world | 20:54 |
| jdstrand | or the new world onto classic | 20:54 |
| niemeyer_ | What's the wart? I couldn't see it yet | 20:54 |
| niemeyer_ | Having different security policy to implement the same behavior is expected and not actually a wart | 20:54 |
| jdstrand | if we have one interface, but different policy on sdoc vs pure core, and a plugging app works on one and not the other because of the policy | 20:55 |
| pedronis | niemeyer_: I think jdstrand is saying that behavior will be different | 20:55 |
| pedronis | so my remark about granularity | 20:55 |
| niemeyer_ | jdstrand: Why would a plugging app work differently? | 20:56 |
| jdstrand | one could argue that the policy should encompass everything, but that may not be appropriate-- it might be too wide on pure core since things in classic aren't designed for snappy | 20:56 |
| jdstrand | niemeyer_: the plugging app would try to work the same, but perhaps break in one | 20:56 |
| niemeyer_ | pedronis: Yeah, I just didn't see the actual relevant difference as far as the snap perception is concerned | 20:56 |
| jdstrand | I have a feeling in the nm case in particular, we could probably make it work. nm is always going to be reserved since it offers a lot of privilege | 20:57 |
| jdstrand | but, for pulseaudio we will have the same issue | 20:57 |
| jdstrand | and that one I know we want different policy | 20:57 |
| jdstrand | because desktop pulseaudio access is different than say Touch access | 20:58 |
| niemeyer_ | jdstrand: How is it different? | 20:58 |
| jdstrand | Touch is much more limited (it uses the safe apis and apps may only use those), whereas on desktop apps, they will not | 20:58 |
| jdstrand | because desktop apps weren't designed for that-- they expect to be able to use everything | 20:59 |
| jdstrand | but Touch apps are designed for that | 20:59 |
| jdstrand | so to be clear | 20:59 |
| jdstrand | we *can* do this if we allow for different policies if snapd detects what can of system it is running on | 21:00 |
| jdstrand | the question is then if we should or not | 21:00 |
| niemeyer_ | jdstrand: That sounds like two different interfaces then | 21:00 |
| jdstrand | and I'm not convinced it is a good idea | 21:00 |
| wililupy | ogra_ It's interresting, in the grubenv file, there is no value for snappy_kernel | 21:00 |
| jdstrand | niemeyer_: indeed. with pulseaudio in particular I was considering siply adding it to unity7. we could alternatively create unity7-audio (or similar) | 21:01 |
| ogra_ | wililupy, right, that was the initial prob ... but it should now boot if you add the var | 21:01 |
| niemeyer_ | jdstrand: We need to look into this in more detail, but if the protocol the applications use to communicate is actually different, then they're of course incompatible, which implies two interfaces rather than one | 21:01 |
| ogra_ | i.e. the initrd bug should be gone | 21:01 |
| niemeyer_ | jdstrand: We shoulld call it out for what it is | 21:02 |
| jdstrand | niemeyer_: right. so with nm, one is a subset of the other. the desktop nm is a superset of the pure core nm | 21:02 |
| niemeyer_ | jdstrand: If it is pulseaudio-simplified or similar, than that's what it is | 21:03 |
| jdstrand | niemeyer_: I think bluez is also going to fall into that category. what gets interesting again is Personal may have a different subset | 21:03 |
| niemeyer_ | jdstrand: We can also start exploring interface attributes | 21:04 |
| jdstrand | niemeyer_: I don't disagree, but then that has warts too cause we have a bunch of different interfaces that people may not know what to use | 21:04 |
| niemeyer_ | jdstrand: But I really need to understand more details before being able to recommend something sensible | 21:04 |
| niemeyer_ | jdstrand: Well, we *will* have a bunch of different interfaces :) | 21:04 |
| niemeyer_ | jdstrand: In fact, we do already | 21:04 |
| niemeyer_ | jdstrand: Conveying what those are and when to use them is an important issue to address properly | 21:05 |
| jdstrand | niemeyer_: really it boils down to the characteristics of the device. sdoc has one set of characterists, pure core another and personal possibly another. depending on the device, the policy may or may not be different | 21:05 |
| niemeyer_ | jdstrand: Yeah, and that's all okay | 21:06 |
| niemeyer_ | jdstrand: Different policy just means a different implementation to the same result | 21:06 |
| niemeyer_ | jdstrand: Different protocol means something else | 21:06 |
| jdstrand | niemeyer_: I think we should be striving for just enough interfaces and no more. we've seen other platforms make this mistake and developer's getting confused and asking for too much, etc. with user's connecting it then gets confusing, etc | 21:06 |
| jdstrand | I should rephrase | 21:07 |
| jdstrand | we haven't made a mistake | 21:07 |
| niemeyer_ | jdstrand: Just enough interfaces to do what.. | 21:07 |
| niemeyer_ | jdstrand: Of course we shouldn't be producing interfaces just because it's fun to do so :) | 21:07 |
| jdstrand | we've seen other platforms offer too many similar choices... | 21:07 |
| jdstrand | niemeyer_: hehe | 21:07 |
| jdstrand | no | 21:07 |
| jdstrand | but if we are in pulseaudio-simplified vs pulseaudio-complex, it makes me wonder | 21:08 |
| jdstrand | because complex would (possibly) always work so no one would choose pulseaudio-simplified, but pulseaudio-simplified is actually 'the good one' | 21:09 |
| jdstrand | it is an interesting problem | 21:09 |
| wililupy | ogra_ I think I'm going to have to rebuild my whole snap. I tried just adding ahci to my snapcraft yaml, but cat /proc/modules doesn't show it. | 21:09 |
| jdstrand | I may be coming around to your thinking (I was never really opposed to it), but perhaps there is something with attributes there that I haven't considered that would make it really good | 21:09 |
| wililupy | I'll give it a run since it takes about 2 hours to complete and I'll update you tomorrow. | 21:10 |
| wililupy | thanks for all your help ogra_ | 21:10 |
| niemeyer_ | Yeah, let's understand better how pulseaudio is organized so we can have a more informed position | 21:10 |
| ogra_ | wililupy, you will need to run whatever step megres the modules into the initrd | 21:10 |
| niemeyer_ | jdstrand: Need to step out now, but let's follow on later/tomorrow | 21:10 |
| ogra_ | wililupy, good luck then, i'm sure the initrd side is fixed | 21:10 |
| jdstrand | niemeyer_: sure, np. I can fill you in on the pusleaudio differences tomorrow | 21:11 |
| niemeyer_ | jdstrand: Thanks, and thanks for the chat | 21:11 |
| jdstrand | niemeyer_: my pleasure :) | 21:12 |
| jdstrand | niemeyer_: have a good evening :) | 21:12 |
| elopio | sergiusens: I can see it. Failed to clone the git repo. | 21:14 |
| elopio | I'd say retest. | 21:15 |
| sergiusens | elopio thanks | 21:23 |
| * sergiusens is so tired of resetting snapd | 21:32 | |
| Laxman | where to find sources for raspberry pi 2 ubuntu snappy | 22:15 |
| geneios | Where should snapcraft issues be filed? At https://launchpad.net/snapcraft? I didn't see an issues section on the github repo. | 22:24 |
| Domi | Hello snapcraft snap fails because the python installation. Her is the output http://pastebin.com/GmZB6v4D can anyone help me? | 22:58 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!