=== JanC is now known as Guest15498 === JanC_ is now known as JanC [01:13] My snap is unable to create files inside its directory in /apps despite its directory having access to anyone. Is there some sort of method I should be following to give it its own directory in a more writable space? [01:16] I changed ownership of it to root, that didn't seem to help. It seems to be root who's running my program [01:33] Would this be something to do with apparmor? [01:41] example6: /apps is readonly. you have to use the writable directory in /var. Since you said /apps, I'm going to assume you are on 15.04, therefore the writable directory is in /var/lib/apps. you can look at $SNAP_APP_DATA_PATH in your environment to see the precise directory to use [01:42] example6: if you are actually on 16.04, the readonly directory is in /snap and the writable in /var/snap and you use $SNAP_DATA in your environment [01:42] * jdstrand was just passing through [01:42] hope that helps! :) [01:47] jdstrand: that helps a ton! Thank you! Do you have any advice on copying my program to /var/lib/apps after installation? it's basically a script that runs a program that creates a few files in the same directory [01:47] I noticed some of the demos (which don't properly start as services most likely since I am indeed on 15.04) had things like var, lib, bin, etc in side their snap/ directory [01:49] example6: you got me before I walked away :) I did something similar in my ufw snap (snappy install ufw.jdstrand). basically, you copy what you need over into /var/lib/apps from /apps. this can be done be a wrapper script that after the copy, runs the real script [01:50] s/be a/by a/ [01:51] example6: though it might be easier to adjust that program to take an optional argument to output to $SNAP_APP_DATA_PATH [01:52] --outdir=$SNAP_APP_DATA_PATH (or similar) [01:52] ok, really gotta run, good luck! :) [01:52] thank you! [02:34] I just tried snappy app calculator on Ubuntu 16.04. However, I cannot find the app in the ubuntu store app. what is the problem for it? https://developer.ubuntu.com/en/desktop/get-started/ === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun [06:49] can someone help me with a question on device tree/dtb/fdt on rpi2? === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun [07:50] I have tried to develop a snappy app for my desktop. every time, when the app is installed, a new version is installed. when I remove it, it only removes the recent one. now the directory is full of different version of the snap app. how can I remove the previous versions of the app. it occupies a lot of space. [07:55] kgunn: hi, i'm following the guide https://goo.gl/4nmG93 to build mir demo. but snapcraft-mir-client building output error like "[Errno 2] No such file or directory: '/home/shuduo/work/snappy/mir- [07:55] demo/snapcraft-mir-client/parts/environment/build/snappy-qt5.conf' [09:38] how to delete a snap on ubuntu 16.04? [09:38] I have tried to use "sudo snapp remove app_name". however, it does not remove the previous versions of the snap apps installed on the system. [10:11] sergiusens: I would love to have easy access to all debugging symbols [10:12] quick break while pulseaudio is building [11:00] Trying to gain some knowledge on the different commands (snap and snappy). When I download an Snappy Ubuntu Core image and run it in KVM it has the snappy command, which seems to handle more than just the packaging (configures the bootloader). "snappy" has an update command, but on 16.04 there is only the "snap" command and it doesn't look like there is "snap update". [11:00] What are the roles of these two applications? [11:02] blackout24: snappy is the old command that is removed in 16 and 16.04 [11:03] ahh thanks [11:03] blackout24: snap is the replacement that uses the REST api (snappy had everything linked in) [11:03] blackout24: update is now called refresh [11:03] When 16.04 downloads a new ubuntu-core snap will it mess with the bootloader? Because 16.04 isn't a snappy system. [11:04] blackout24: no [11:05] blackout24: snappy differentiates between core and classic systems [11:05] I have ported snappy to Arch Linux and everything works, but when it downloads the ubuntu-core image when I try to install the calculator-app it complains that it can't determine the bootloader. How can I tell snap that I'm on a classic system and it should only install it as a framework. [11:06] blackout24: ah, in that case you need to patch the source a little, in the past (2.0.2 release) we checked for dpkg status file, now there's a method (I need to check which) that checks this [11:06] blackout24: I think it should be easy to tweak that to understand arch as well [11:09] blackout24: I can help you out in a moment, just need a second to test something I'm hacking on now [11:10] blackout24: look at release/ look for onClassic [11:11] blackout24: I'm sure we will gladly take patches to detect arch there [11:11] Right now I just pull the 2.0.2 snapd deb file from archive.ubuntu.com and "ar p *.deb data.tar.xz | tar -Jxf -C targetdir" the whole thing in a PKGBUILD. I could also let it build the latest Go sources from github and only extract the systemd unit files from snapd deb. [11:11] blackout24: no that won't work, you really need to rebuild it with a patch [11:11] it behaves differently on classic and on all-snap system [11:11] ok [11:11] blackout24: and get master [11:12] blackout24: (no point in using 2.0.2) we SRU regularly so working on latest version is the best way [11:12] * zyga back to hacking [11:14] Great thanks. I also wanted to see if I can tweak snapcraft to use pyalpm to check if the build-tools and dependencys are installed on an Arch system. [11:15] blackout24: for that look at sergiusens [11:16] blackout24: I can help you out with snappy [12:18] jdstrand: hey, I have some good and some bad news [12:20] zyga: hey [12:20] and here I was trying to sneak in early to get some stuff done... [12:20] hehe [12:20] jdstrand: I got pulseaudio on classic to work [12:21] jdstrand: but this doesn't solve the bigger shm_open problem [12:22] what did you do to get pulseaudio on classic to work? [12:22] jdstrand: http://paste.ubuntu.com/16236835/ [12:22] surprisingly little [12:22] no other changes required [12:22] ok, yeah [12:22] that is what I figured it would look like [12:22] jdstrand: connect is in the base profile I think, I can remove it [12:23] jdstrand: now what is interesting is how pulseaudio would work as a snap itself [12:23] e.g. would it still be +owner /run/user/*/pulse/native rw, [12:23] right [12:23] (i doubt that) [12:23] this is where I was talking about the dichotomy of classic vs core [12:23] still, I think this is better than nothing, I'll iterate to reject pulseaudio slots for now [12:23] and the policy being different [12:24] and propose this, it unlocks a lot of nice apps today [12:24] and we can add slot support later [12:24] zyga: this is exactly the policy I was thinking should be in either unity7 or unity7-(pulse?)audio, etc [12:24] I think it's fine to have a pulseaudio interface [12:25] as a dedicated thing [12:25] I think it is completely fine to have a pulseaudio interface [12:25] for snaps [12:25] for snapped pulseaudio [12:25] we just need to think if the actual interface is portable, I think the only issues is /run/user socket [12:25] I'm very less sure about this [12:25] there's other stuff [12:25] if the socket was provided to the client as an attribute [12:25] yes? [12:25] there is a dbus socket iirc, something else [12:26] I can't recall everything. some are safe some are not [12:26] I'd start with one that just hands access to this socket [12:26] not to dbus (this app doesn't need dbus, it does sound like 90% of apps do) [12:26] I bet pulse has a rich interface but we don't have to support all the bells and whistles (e.g. one that would make the sound indaicator work) [12:26] indicator* [12:27] so this gets back to: are they separate interfaces (pulse for classic and pulse for core) or is it one named interface (pulseaudio) that will output different security policy if on a classic system vs core system [12:27] I think that different policy is okayt [12:27] different behavior is less okay (not okay) [12:27] I don't think we know that this will be for 90% of the apps [12:27] and this if we take a common subset and enforce that, a single interface is okay [12:27] jdstrand: 90% of apps just play sound [12:27] 10% also capture sound [12:27] 0.1 need to manage pulseaudio internals [12:28] ballpark numbers but that's realistic IMHO [12:28] did you know that 85% of statistics are made up on the spot? [12:28] exactly [12:28] :P [12:28] and mine fits [12:28] does it? [12:28] :) [12:28] look at it from another point of view, all apps on all mobile devices can play sound when they run [12:28] supporting that today is very easy and I think that's what we should do [12:28] supporting more is an open question that we don't have to solve now [12:29] we can take an opinionated view that to play sound you must use what is in the interface [12:29] but every time we take an opinionated view on classic, there is pressure to just allow it [12:29] I see what you mean, I think we will need to experiment some more [12:29] perhaps the real issue is the interface name [12:29] zyga: we have an audio policy on Touch that does that safely [12:29] perhaps we should require that the plugs have an attribute "basic" [12:30] or something like that that lets us do more later [12:30] is touch also using pulseaudio? [12:30] yes [12:30] does it differ because of no X, I know pulse uses X for some IPC [12:30] we call the policy group 'audio', but that is pulseaudio [12:30] I don't know anything about that [12:31] where can I look at the policy? [12:31] perhaps that is one of the different optional IPC mechanisms (like the dbus one) [12:32] zyga: http://bazaar.launchpad.net/~ubuntu-security/apparmor-easyprof-ubuntu/1.3-stable-phone-overlay/view/head:/data/policygroups/ubuntu/1.0/audio [12:33] thanks! [12:35] zyga: How does the pulse audio files look like under shm? [12:35] zyga: so, I don't particularly care if we use one interface name with two different policy or two interfaces names. I only care that the policy is appropriate on the target system. that said, once we make the decision, that's it, which is why I'm being cautious [12:36] and I don't have actual stats that the cli and dbus-socket (as opposed to native) aren't legitimately used on classic. on Touch we said "sorry, use 'native'". on classic, I worry someone is going to say "you need to make super important app FOO work and it needs 'cli'" [12:37] but again, if we export two different policies depending on the running system, fine [12:37] it is just we don't have that device introspection in the interface code today [12:38] though, one could argue that we are breaking our contract if when using 'pulseaudio' on classic you also get 'cli' where on core you don't [12:39] blackout24 so you want to use pyalm as build-packages/stage-packages? Look at snapcraft.internal.repo to start out [12:39] perhaps an attribute could help there... but I'm not sure what that would look like [12:39] niemeyer: pulse-shm-$random-number [12:39] good morning [12:40] niemeyer: it would be much nicer for a pulse snap to use pulse-shm-snap.foo.$random-number (or similar) [12:41] then we can have /dev/shm/pulse-shm-snap.@{SNAP}.* rwk, [12:41] jdstrand: How's that better than /dev/shm/${SNAP}.*? [12:42] that would work too [12:42] I think that falls into (or similar) [12:42] niemeyer: I think the question we should be asking is if we should expect to patch applications in any way or not [12:42] niemeyer: if the answer is yes then we can have a nice policy and sensible values everywhere [12:42] niemeyer: if the answer is no, it's complicated [12:42] I betting the client doesn't need patching [12:42] I'm [12:42] because it is a random number [12:43] jdstrand: Hm? [12:43] it is probably talking on the native interface and the server says-- here, use this thing (whether by fd or something else) [12:43] jdstrand: the server probably passes the filename via the socket [12:43] and so the client doesn't care what the file name is. I'm am guessing that is how it works [12:43] jdstrand: though pulse is complex, I bet there are many options thre [12:43] zyga: yes, that is what I'm saying [12:44] so in theory, the pulse snap could be patched [12:44] jdstrand: I was just highlighing the filename vs fd [12:44] jdstrand: the other thing to note is the socket itself [12:44] as in where it is [12:45] we could even SRU a patch so that classic does the same thing [12:45] perhaps the SRU would look at the security label of the connecting application and only do it for clients whose label starts with 'snap.' [12:46] anyhoo [12:46] jdstrand: can apparmor/seccomp do something about connections over unix sockets? [12:46] jdstrand: e.g. constrain connect [12:46] zyga: the socket itself is going to need to be known by the clients [12:46] yes [12:46] sergiusens: kyrofa: developer.ubuntu.com is now syncing snapcraft docs with github every 2h \o/ [12:46] we have unix mediation [12:47] though not for file backed sockets [12:47] this is a named socket so we only have file rules [12:47] ah [12:47] I see [12:47] davidcalle \o/ [12:47] (we'll get full unix mediation semantics for named sockets with future work) [12:48] * sergiusens checks [12:48] jdstrand: I was thinking about patching pulse server but then there are other apps, I don't know how the socket is located today, is that hardcoded somewhere or is that passed by IPC we don't see [12:48] jdstrand: but perhaps that is not needed [12:48] zyga: I think this is like mir-- there is a known location and that's ok [12:48] jdstrand: on classic the /run/users socket is okay [12:48] jdstrand: on snappy we could just make a different policy [12:49] jdstrand: on classic pulse runs as the user [12:49] on core I think we're going to need to let the permanent connected slot to need to use a well-known path [12:49] jdstrand: so that's another complication [12:49] that was a poorly contructed sentence [12:49] jdstrand: at the end of the story we should check if a snap like paplay can work on classic and core [12:49] zyga: on Personal, it will run as the user too [12:49] jdstrand: but perhaps not on core [12:49] jdstrand: it couldn't today, right? [12:50] I'm honestly a bit lost on the conversation by now [12:50] jdstrand: service == root [12:50] zyga: Personal is going to need a lot of work. that would be of session services [12:50] niemeyer: sorry, we're brainstorming what possiblities exist and what implications they might have now, this is specific to pulse, not to shm_open [12:51] is there anyone working on pulseaudio snap for core today? [12:52] zyga: Understood, but I'm kind of missing the high-level conversation we should have [12:52] niemeyer: for the record, I'm completely fine with /dev/shm/${SNAP}.* as that keeps things isolated. if we feel this is a good thing generally, I can propse a change [12:52] zyga: What are the constraints for that design [12:52] niemeyer: that may not help pulse and chromium, but it provides a general 'do this and it will work' mechanism [12:52] I agree with jdstrand's opinion on this [12:53] we can always poke holes with specific interfaces, shouldn't stop us from sane defaults [12:53] not thet the very subtle path that jdstrand proposed does not have subdirectories under /dev/shm as that would not work [12:53] zyga: re who is working on it> no, but it is on the list from phonedations, after bluez, nm, location-service and ofono/modemmanager [12:53] undrstood [12:53] according to I believe, morphis [12:54] niemeyer: quick question, would you be okay with a pulseaudio interface that works on classic only (like x11,unity7) and allows just plugs (no slots)? [12:54] jdstrand: So what is pulse audio trying to do that this would not work? [12:54] zyga: I could allow creation of both a snap-specific file patch and a snap-specific directory in /dev/shm so people are free to use that general mechanism without issues [12:55] jdstrand: except that shm_open rejects subdirectories [12:55] jdstrand: we could allow it but it would be non-trivial to use [12:55] niemeyer: pulseaudio server today does not conform to /dev/shm/${SNAP}.* [12:55] niemeyer: it could be made to do so both in a snap and in SRU [12:55] jdstrand: Ah, ok.. my underslying question was actually: do we know of cases that want to share those files? [12:55] zyga: right, which is why we allow *both*. one that is file for shm_open and one that is directory for people that use open() [12:56] jdstrand: that would work [12:56] but both are app-specific [12:56] jdstrand: app-specific or snap-specific? [12:56] 2016 and mksquashfs freezes my desktop session because scheduling sucks :/ [12:56] niemeyer: honestly, I do not. I was assuming they were client specific (not even session specific) since I see a bunch of them in my session [12:57] Stop using that hardware from 2004 [12:57] zyga: hrmm-- I see similar things :\ [12:57] :) [12:57] ogra_: I have an xps 13! [12:57] not the newest one, but still :) [12:58] The 2004 model ? [12:58] davidcalle looks good, I have a request already though ;-) Can we enhance the code snippets with pygments? [12:58] haha [12:58] * ogra_ grins [12:58] no :) [12:58] 2014 iirc [12:58] yeah, same device here... [12:58] sergiusens: only if markdown has a way to specify language for code snippets [12:58] zyga: What did you find out with pulseaudio? [12:59] do we use xz for squashfs compression ? [12:59] zyga: When you allow it to use shm, but not other processes to see those files, what happened? [12:59] sergiusens: (or we come up with a custom tag, that works too) [12:59] niemeyer, zyga: ok, so, do we agree that I should modify the default policy to allow /dev/shm/${SNAP}.* for files and directories just because that is the correct way to handle shm_open() and open(), regardless of pulse, chromium, etc? [12:59] niemeyer: that pulseaudio on classic can be accomodated with a very simple interface, it needs to access a shared socket (per user) and files named /dev/shm/pulse-shm-* [12:59] jdstrand: +1 [13:00] jdstrand: pulse would work with a simple interface as described [13:00] jdstrand, zyga: Let's consider that for a little while before acting, please [13:00] jdstrand: chromium, I need to analyze still [13:00] standup! [13:01] niemeyer: all that is doing is saying: "the path we said you could use before (/dev/shm/snap/$SNAP/**) we undesrtand to be broken. here is something that will work for you. Next up, design pulseaudio interface (that may or may not comply with that)" [13:02] davidcalle the github extension of markdown does fwiw (and we are using it or were) [13:03] zyga: for pulse, if we are saying "native socket only for both core and classic" and we generate policy for /dev/shm/pulse-shm-* on classic and (perhaps) /dev/shm/$SNAP... on core, then I'm ok with one interface: pulseaudio [13:04] zyga: if we are going to entertain the dbus or cli pulse sockets, those need to be different interfaces/attributes [13:04] that way the default is always the native socket, but (if we decide to support it), you can request cli or dbus-socket [13:05] zyga: oh, and the native socket for the slot is at a well-known path [13:06] though, I think I prefer /dev/shm/snap.$SNAP... to /dev/shm/$SNAP... for namespacing [13:06] we could argue that point in the PR [13:07] Good morning [13:07] davidcalle, awesome!! [13:09] sergiusens, ok [13:09] zyga: in this manner, the contract is always the same for the native socket. we just may (or may not) use a different shm path [13:10] davidcalle hey, I love the fact that they are being updated though!!! \o/ [13:11] jdstrand: hmmm, I'm not sure I understand that correctly, would you mind expresisng that as a plug-side aa policy pseudo code? [13:14] jdstrand: I agree on /dev/shm/snap.$SNAP [13:14] jdstrand: $SNAP_NAME to be precise [13:15] zyga: if we say that the 'pulseaudio' interface uses 'native' socket by default, plug side for classic is what you pasted. plug side for core may drop /dev/shm/pulse-... and rely on only the general /dev/shm/snap.$SNAP (I say may cause let's see how things go with that snap). then, if at some future date someone wants the 'cli' or 'dbus-socket' pulseaudio sockets, we introduce an attribute or pulseaudio-{cli,dbus-socket} interfaces [13:15] jdstrand: I agree with that [13:16] zyga: in this manner, the default pulseaudio interface contract is consistent between classic and snap [13:16] which was my biggest concern [13:16] jdstrand: yes, that's very important [13:16] shuduo: ah...thanks for the catch, i forgot to bzr add that file....added now, should work [13:16] jdstrand: and later on we can do pulseaudo-control interface or use attributes, depending on how things look like precisely [13:16] so if we're pressured to allow cli or whatever, we have a way forward that doesn't break apps (new interface or attribute) [13:16] exactly [13:16] ok, cool [13:17] I think we are in agreement on pulseaudio. I'd like to get to agreement on the paths in /dev/shm for the non-pulseaudio general case too though [13:17] since they are known to be broken [13:17] then we can look at chromium [13:17] oh [13:18] jdstrand: I think /dev/shm/snap.$SNAP_NAME.* [13:18] jdstrand: snap. as that makes it obvious what the culprit is [13:18] jdstrand: no .app as shm is an IPC mechanism and shold work within one snap directly [13:18] jdstrand: and .* to allow those random names [13:19] (to be precise . to termiante $SNAP_NAME * for the random stuff) [13:19] zyga: we talked a long time ago about the 'home-hidden' interface but I think that morphed into (the idea to have) an interface that allows requesting access to file/directory (eg, ~/.mozilla). that could be used for chromium [13:19] zyga: snap.> yes and makes sure a crafted snap name doesn't try to use a well-known path in /dev/shm [13:20] jdstrand: and we could also marry this with a patch to glibc [13:20] zyga: the whole time I was thinking snap.$SNAP_NAME.* since I figured apps within a snap might want to use shm however they want [13:21] jdstrand: to make shm_open() use $SNAP_NAME prefix transparently if SNAP_NAME is defined [13:21] jdstrand: _or_ let people use something like my runtime helper [13:21] that is a possibility [13:21] jdstrand: LD_PRELOAD or linked in [13:21] or they patch the code [13:21] yes, there are options for people [13:21] my helper is actually a nice bit that you can link in or preload and it just works :) [13:21] yeha [13:22] yeah [13:22] I guess that would be part of snapcraft? [13:22] you say, "I want snappy compliant paths in /dev/shm' in snapcraft.yaml and you get that? [13:23] that doesn't help static code, but that's ok. it is handy regardless [13:23] jdstrand: we can make that happen by magic with snapcraft [13:23] jdstrand: just stick it in [13:23] jdstrand: oooor [13:23] jdstrand: actually I have a interesting/cool idea [13:24] jdstrand: what if we had a magic LD_PRELOAD managed by the core snap itself [13:24] jdstrand: where we ship very conservative and non-invasive things like that [13:24] jdstrand: so when policy changes, it still works [13:25] that is an interesting idea. my conservatism says we may want to offer an opt-out though [13:25] sure [13:25] out is okay [13:26] jdstrand: offtopic, are you going to the sprint? [13:27] zyga: what did you think about the comment on the 'path interface' bit for chromium (which uses open()). is that 'path interface' still a thing? (I thought it was needed for things like ~/.mozilla, etc) [13:27] zyga: no. tyhicks will be there. I will be on irc though in my normal timezone [13:28] the path interface is an interesting idea, it's certainly a sprint topic, I was thinking about it from a different POV, .e.g. where you as a user can create a slice of $HOME, create a new slot, and connect it to some slots (typed home-slice perhaps) [13:28] jdstrand: how that might work for non-home directories, I don't know [13:29] zyga: so the spec for that interface is only for non-home? [13:29] err [13:29] only for home? [13:29] there's no spec yet, this was just some speculation [13:29] ok [13:29] jdstrand: I'd like to have one [13:30] jdstrand: it's a simple idea and would let us see how hooks work (it would have to be hook based) [13:30] yeah. my understanding is that it is a requirement [13:30] jdstrand: ok, let's wrap up shm_open and pulseaudio as agreed [13:30] jdstrand: I'll work on pulse now [13:30] jdstrand: I have a lovely snap that just work with this interface, I'd love to put it in the store [13:30] zyga: I can work on the generalized shm [13:31] jdstrand: brilliant, thank you [13:32] zyga: so, I have two simple PRs from yesterday but the intergration tests failed. I don't see how my code could have done that (especially the PR for doc changes :), but I can't see the integration test results to know what is happening [13:33] jdstrand: integration tests are broken now I think [13:33] fgimenez: ^^ are they? [13:33] jdstrand: if you connect to the VPN you can see the results [13:34] jdstrand: let's merge the doc changes after they get the second review [13:34] jdstrand: as for the other PR, I didn't review any yet [13:39] ack, thanks [13:40] zyga: for me at least, this pulseaudio discussion was really good. it solidifies concepts like interfaces contracts, classic vs core vs personal, how attributes might play a part, etc [13:40] which will inform future interface discussions [13:42] yes, FileNotFoundError in the jenkins output. seem broken [13:49] zyga, I changed the release.go code: https://github.com/timjp87/snappy/blob/master/release/release.go#L73 [13:49] Unfortunately I still get "Make snap "ubuntu-core" available to the system (can not set next boot: cannot determine bootloader)" [13:49] blackout24: you also need to patch ubuntu-core-launcher [13:49] ahhh [13:49] blackout24: though wait, where do you see that error? [13:49] blackout24: on snapd start up? snap install? when? [13:50] snapd install [13:50] I try to install the calculator [13:50] and it first fetches ubuntu-core [13:51] I cleaned my previous installation, which just used the precompiled 2.0.2 binaries from xenial and modified my PKGBUILD so that it pulls the source from github and applies the patch before building snap and snapd. [13:51] I also rebooted to make sure [13:52] blackout24: and the error showed up when? [13:52] blackout24: note that snapd also has a few systemd units you need [13:52] blackout24: you may want to look at those [13:52] blackout24: but I don't know arch really so I cannot help there [13:53] shuduo: so it worked ok for you now? [13:53] sergiusens: could snapcraft be very conservative about .debs it downloads so snapcraft clean; snapcraft can reuse them, I still have to do snapcraft clean all the time and downloading debs over and over is the last big slowdown [13:53] blackout24: Please note we'd be happy to take those patches in [13:54] blackout24: Assuming you can make it all actually work [13:54] Thanks. Yes I installed the systemd units from the github.com repo into /usr/lib/systemd/system. Arch has everything in /usr instead of installing stuff to /lib. [13:55] They are the same that are listed as contents of the snapd package in 16.04 [13:55] blackout24: you will also need apparmor and seccomp [13:55] blackout24: and ubuntu-core-launcher actually working [13:55] kgunn: i'm verifying on another laptop. will let me you later. maybe after 30 minutes. thanks. :) [13:55] That's what I wanted to find out if apparmor is a hard dependency [13:55] nw, thanks for trying [13:55] blackout24: yes [13:55] blackout24: and seccomp as well [13:55] but that's hard not to have :) [13:56] blackout24: if you build ubuntu-core-launcher you're 90% closer to running snapd [13:56] zyga: There is an alternative kernel available with the apparmor patches. It's not maintained but should be possible to revive. [13:56] blackout24: you may also need kernel patches but I'll delegate that to some other folks [13:56] zyga: you seem busy, but had a chance to try my fork and get the plug to connect? [13:56] zyga do snapcraft clean --step build [13:56] sergiusens: <3 thank you [13:57] kgunn: not yet, I'll do it today as I'm not going to be involved in UOS as much [13:57] nw [13:57] Right now I only have the userland apparmor libraries installed. They are available through the AUR. [13:57] zyga also, you can most likely get away by using build packages instead of stage-packages in most cases [13:57] jdstrand: How fast can we ship a new glibc for 16.04? [13:58] blackout24 the ubuntu security team has some easy instructions to get different kernel versions patched [13:59] kgunn: how does mir use shared memory? [13:59] blackout24 maybe this can kickstart your work https://wiki.ubuntu.com/SecurityTeam/AppArmorForPhabletKernels [13:59] zyga heh, the shm question is being raised a lot now. I am happy to see this being brought up :-) [14:00] snappy will comb software into looking nice and uniform [14:01] * zyga does a poor man's job of snap try [14:01] sergiusens, thanks [14:01] and ... wow, speedup :) [14:01] niemeyer: the new glibc for shm_open? [14:01] jdstrand: Yeah [14:03] niemeyer: to make shm_open() understand $SNAP_NAME and use it as prefix? [14:04] well, the hardest part would be convincing infinity, but I'm kinda liking zyga's LD_PRELOAD idea since that would work on any glibc system (eg, non-Ubuntu systems) [14:04] jdstrand: I'll refresh my preload library to do that [14:05] jdstrand: we can experiment with it while convincing infinity :) [14:06] zyga: well, but again, if we use your LD_PRELOAD library be default idea, there is no need to convince infinity. snappy can maintain those changes outside of SRUs and those changes propagate to other distros [14:06] s/be/by/ [14:06] hmmm [14:06] not needing it would feel nicer but I agree that it is a simplification [14:06] I can promise you upstream glibc won't take it, so then we have a permanent delta that we ask all other distros to incorporate [14:06] iff it is added by default by snapcraft [14:07] jdstrand: why won't they take it? [14:07] snapcraft or your snapd idea of by default [14:07] ah, right [14:07] zyga, @how mir uses shared memory : It uses it for Mesa s/w clients. Mir client requests it, server allocates it, client renders to it, gives it back to the server, and server posts it on the display [14:07] have you worked with upstream glibc? [14:07] :) [14:07] jdstrand: no :) [14:07] go ahead, float this by infinity right now in #ubuntu-devel :) [14:08] camako: I'd like to know how it allocates shared memory and shares is across processes [14:08] jdstrand: isn't that guy who used to be grumpy off glibc maintenance now :) [14:08] but really, again, regardless of upstream, having this (and perhaps other things) in control of snapd/snapcraft might be better [14:08] jdstrand: yes, I agree on that [14:08] zyga: yes... :) [14:09] jdstrand: looking at how shm_open works, it's actually a bit sucky :/ it's easy to hack and change the directory, harder to convince glibc to just take a non-directory prefix... [14:09] gimme a sec [14:10] * sergiusens starts monitoring #ubuntu-devel with a bucket full of popcorn [14:11] zyga, integration tests infra seem to be fine now [14:11] fgimenez: thank you [14:13] zyga, it allocates using [14:13] auto raw_fd = open("/dev/shm", O_TMPFILE | O_RDWR | O_EXCL | O_CLOEXEC, S_IRWXU); [14:14] it maps using mmap [14:15] zyga, it requires a kernel that supports O_TMPFILE [14:15]