[00:10] Hello, is it possible to use a package form pip in a snap? [00:55] sergiusens: nobody reads my mails :( [00:56] 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:57] i'm not sure how we should add something like nss beyond making up an artificial dep in one of the packages [00:59] ogra_ false warning, not needed [00:59] ok [00:59] And not my idea [00:59] sergiusens: doesnt fix the base problem though ... [00:59] i'm sure the next nss is around the corner :) [01:00] But I did read your email. I wanted you to tell zyga what you just told me 😌 [01:00] desktop support landed too close to release [01:00] i suspect we could make ubuntu-core-config kind of a meta package ... to get such deps in [01:00] yeah, it did ... [01:01] And this is what we get [01:01] and really broke to much of the IoT side [01:01] You don't say [01:01] heh [01:01] well, we'll dig our butts out of this ... as we always do :) [01:01] * sergiusens needs a telgram sticker now [01:02] hah === chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun [07:02] Hello, I am trying to create my first snap but have some issue. (I already read some doc, and tried the opencv example). [07:03] I build SDL2 example, with cmake. But it fails to execute as a snap [07:03] because some shared libs are missing. SDL2 tries to dlopen some libs, like mirclient.so, and probably some other .. [07:04] should I put all those shared libs into the snap package ? [07:05] (I think CMake is putting the libSDL2 into the snap package, but not libmirclient.so for instance) [07:05] good morning [07:06] mvo, wow, you're improving your bug karma :) [07:36] good morning [07:37] 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:52] dholbach: hey, good morning. indeed, bug triage ftw! [08:03] https://github.com/ubuntu-core/snappy/pull/1080 [08:08] 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:14] 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] s/how/our/ [08:16] 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:24] 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:26] slvn: hey, is the x11 interface connected? can you pastebin your snapcraft.yaml please [08:28] zyga, probably not since this is my first snap ... http://paste.ubuntu.com/16076031/ [08:28] slvn: no worries, please add this uner "command:", "plugs: [unity7]" [08:29] slvn: and perhaps add opengl there (after unity7) if that doesn't work still [08:29] slvn: http://www.zygoon.pl/2016/04/snappy-interfaces-plugs-slots-connections.html [08:31] zyga, seems to work better ! (though I have another error now) [08:32] slvn: cool, what's the next error? [08:32] 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:33] slvn: I think you should bundle them but I'm not 100% sure [08:33] slvn: there are some special provisions for opengl apps [08:33] slvn: what error do you see now? [08:33] dholbach: ^^ do you know if those libs should be bundled? [08:34] zyga, SDL2, has started to communicate with x11. (through libX11.so), now it requires to load libGL.so. [08:34] it fails because it cannot dlopen libGL.so [08:36] (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:37] slvn: try adding the package that has libgl.so to stage-packages [08:41] zyga, I have no idea - dpm: ^ what's your experience? [08:41] do we have any opengl apps? [08:42] zyga, dholbach, ubuntu-clock-app, ubuntu-calculator-app and notes all use the opengl interface [08:43] IIRC they install the required libraries via dependencies in stage-packages [08:45] https://github.com/ubuntu-core/snappy/pull/1081 [08:53] 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:55] 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] slvn: but I don't know how this works, sorry, I cannot help you [08:58] zyga, thanks anyway :) because you fixed me, in 5 min, a few issues I spent 2 hours yesterday [08:58] slvn: I'll look at SDL/opengl apps more closely soon (~ days) [08:58] slvn: I'll be blogging about how to snap them correctly [08:59] zyga, I'll send you my snap package if I can make it work correctly [08:59] slvn: sure === JamesTait is now known as Guest50895 [09:02] 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 === Guest50895 is now known as JamesTait [09:05] wesleymason: no, it's something that snapcraft needs to learn/deal with, maybe a snapscraft bug report could help there [09:07] 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] will fil the bug [09:16] 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:17] popey, I didn't, so I ran the "wipe out the world" script and filed bug 1575550 :) [09:17] bug 1575550 in Snappy "Snap removal while snap is running prevents subsequent removal or installation" [Undecided,New] https://launchpad.net/bugs/1575550 [09:17] dpm: which wipe the world script did you use? I have seen a few [09:18] the one you pasted a while ago [09:18] let me re-paste [09:18] * popey confirms the bug [09:18] it's worse if your app launches a binary which isn't even graphical [09:19] you have no idea it's running without hunting it down with lsof and friends [09:19] oh, I see, so you don't notice easily if it's running or not [09:19] yeah [09:19] http://pastebin.ubuntu.com/16076306/ <- that wfm [09:19] i had a random binary called "--debug" running :) [09:19] ta [09:19] * popey saves as nuke_snap_from_orbit.sh [09:28] dpm, popey: please don't use that [09:28] use this instead: https://github.com/zyga/devtools/blob/master/reset-state [09:28] run this script as the pastebin above is incomplete and leaves some stuff behind [09:28] feel free to spread the link, I maintaing that script to work as snappy evolves [09:30] thanks zyga - does the system need to be rebooted after runing the script? E.g. for mounts and such [09:33] dpm: I don't believe so [09:33] dpm: though if you find a corner case do let me know [09:33] dpm: and I will gladly take pull requests [09:34] dpm: to improve on the wording, behavior, etc [09:38] thanks zyga [09:39] zyga: though the goal is not to need the script :) [09:39] pedronis: hehe :) I wonder if dpkg had a 'wipe.pl' script in the early days ;) [09:39] pedronis: I fully agree though :) [09:40] after the first sru the number of breaking bugs will certainly be much lower [09:46] 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] dragly: zygoon.pl, also on planet.ubunt.com [09:46] 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] thanks [09:47] slvn: does it work when you install the snap with --devmode (remove it first please) [09:48] slvn: please report a bug on snappy with the log you see above and with syslog output (journalctl -n 1000,) [09:48] slvn: we won't "fix" it immediately but it will help us to track it [09:48] slvn: please include your snapcraft file / sources as well (as links or attachments) [09:50] Adding --devmode won't help [09:51] also, I have the swarst_dri in the ./snap/ see : http://paste.ubuntu.com/16076518/ [09:51] I'll report the issue ... [09:58] 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:59] slvn: including, perhaps, more libraries [09:59] dholbach, is https://github.com/ubuntu-core/snapcraft/blob/master/docs/your-first-snap.md uptodate? [10:00] 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] zyga, what does devmode does ? [10:00] slvn: http://www.zygoon.pl/2016/04/snap-install-devmode.html [10:07] 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:10] that's what subset of libs we mount, not a security one [10:10] I suspect [10:13] zyga, still want me to enter a bug report ? (https://launchpad.net/snapcraft ?) [10:13] slvn: yes please [10:15] seb128, it should be - if it's not, that's a bug [10:15] dholbach, ok, good, just checking before starting reading it ;-) [10:15] dholbach, thanks [10:16] seb128, https://github.com/ubuntu-core/snapcraft/pull/454 is a pending change I know of [10:16] dholbach, danke [10:16] kyrofa, ^ can we land this one soon? [10:17] dholbach, I started by reading https://github.com/ubuntu-core/snapcraft/blob/master/docs/get-started.md [10:17] which states [10:17] "This is the most important selection of tools you will get after installation: [10:17] snappy try - try snaps from a .snap, the [stage] or [snap] dir" [10:17] but "snappy" is command-not-found [10:18] so I was wondering if the rest was updated [10:18] going to read more and see if I find issues [10:23] dholbach, k, that pending change address that one [10:24] zyga, there https://bugs.launchpad.net/snapcraft/+bug/1575582 [10:24] Launchpad bug 1575582 in Snapcraft "Snap package, using SDL2, needs access to libGL.so and DRI dependencies" [Undecided,New] [10:25] slvn: thanks, checking [10:25] zyga, the attachment is the SDL2 helloworld .. [10:26] slvn: the attachment looks good, thanks for reporting this === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun [10:45] 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] when I add the "plug" unity7, I can get access to mirclient I guess? [10:45] but when I add the plug "opengl" I dont get access to libGL ! [10:45] that would be unity8 :) [10:46] (there is no expectation for mir on unity7 i thinnk) [10:46] to get access to libGL, I need to add the stage-package libgl1-mesa [10:47] slvn: that much is true but which *actual* libraries are provided by the snap and which are provided by the os is tricky [10:48] slvn: from a particular GL call in your code to, say, nvidia userspace blob doing something is a long path [10:48] slvn: a similar thing happens with openCL but there it, at least, was designed correctly up front [10:48] 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] slvn: so you can query available drivers and pick the right one [10:49] slvn: there is no unity8 interface yet [10:51] Hello, how do I pack packages form pip in my snap? [10:52] Domi: hey, look at snapcraft examples, there are some pip-based python demos there [10:53] 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] how can I know that the "plug" "opengl" do ? [10:54] zyga: I just see the python example with spongeshaker and github [10:54] https://github.com/ubuntu-core/snapcraft/blob/master/examples/py3-project/snapcraft.yaml [10:54] slvn: look at snappy source code, today there's little docs on interfaces [10:54] slvn: I'm writing some but they are not ready yet [10:55] zyga, np, I will have a look :) [11:25] snapcraft snap fails because the python installation. Her is the output http://pastebin.com/GmZB6v4D can anyone help me? [11:33] can snapcraft.yaml use a dynamic version? [11:39] like version: "version: `bzr revno`" [11:51] seb128: nope [11:51] seb128: not that I know of at least [11:56] :-( [12:01] <_morphis> zyga: you saw my comment about moving the security label building code somewhere else where every interface implementation can consume it? [12:01] _morphis: no, not yet [12:02] _morphis: though I think it makes a lot of sense :) [12:02] <_morphis> ok [12:02] <_morphis> :-) [12:02] _morphis: I was thinking if n-m would use it [12:02] Good morning [12:02] <_morphis> zyga: for sure [12:03] dholbach, I was hoping to wait until snappy was in sync across the desktop and ubuntu core, but perhaps that's not necessary === chihchun is now known as chihchun_afk [12:11] hi there [12:13] 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:14] 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:16] can I have "private" snaps on the store? === chihchun_afk is now known as chihchun [12:22] loic_m: I'm sure you can :-) [12:23] _morphis: I'm looking at one more thing and then I'll switch focus to n-m [12:25] <_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:45] kyrofa I have another morning gift for you https://bugs.launchpad.net/bugs/1575628 [12:45] Launchpad bug 1575628 in Snapcraft ""copy" plugin symlinks whole snap folder when no source is given" [Undecided,New] [12:46] sergiusens, yeah I'm discussing it now in another channel [12:46] did anyone looked at making snaps load locale .mo translations? [12:46] dpm, ^ do you know? [12:46] 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] also to get locales generated in the snap [12:47] seb128, tl;dr, I did, it didn't work [12:47] did you file a bug about it? [12:47] seb128, the clock app is an example: [12:47] it builds and ships the .mo files [12:47] but the UI toolkit does not find them [12:48] well, non english locales are not even available right? [12:48] we would need to generate locales on the core image [12:48] 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] or to include locales in the snap [12:48] and generate those in some way [12:49] 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] 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] sergiusens: this is ready to review though [12:49] sergiusens, what does bzr export (or similar) get us? [12:49] vila well we do block on low unit test coverage ;-) [12:50] kyrofa exporting the pure sources without generated artifacts [12:50] sergiusens, assuming the snap is in version control? [12:50] sergiusens, what if we disallowed specifying '.' as the source? We could get rid of the build step's filtering that way [12:50] sergiusens: well, you want me to require a dev setup including sso, sca, cpi and updown servers ? ;-) [12:51] kyrofa yeah, that's why I said, if nothing is possible, default to plain copy (depending on the plugin) [12:51] Ah [12:51] 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] sergiusens, that also means we can't run if one hasn't committed to git (or bzr, whatever)... [12:52] sergiusens: the coverage decreased is caused by the implementation change and by replacing mocked tests by tests against real code [12:52] mocked requests/response bitrot faster than the server evolves, especially here for macaroons [12:52] http://www.zygoon.pl/2016/04/anatomy-of-snappy-interface.html [12:53] heh, zyga playing doctor :) [12:54] :-) [12:54] vila so this is not specced? Chipaca are you testing the macaroons implementation with unit tests in snapd? [12:54] vila this is also why we need both in any case, integration tests and unit [12:56] sergiusens: what do you mean by speceed ? [12:56] vila client/server interaction [12:56] kyrofa, probably not [12:57] dholbach, alright, I'll write it for the desktop, since that'll be valid soon for ubuntu core [12:58] dholbach: note, I won't be able to attend the snappy community sync [12:58] sergiusens, alright with you if we get https://github.com/ubuntu-core/snapcraft/pull/454 into the SRU as well? [12:58] sergiusens: it is, that didn't mean there is no bugs (we've fixed several along the way) [12:58] dholbach: unless you want me to dial-in from a classic mobile [12:58] zyga, no worries [12:59] dpm, ^ looks like zyga and niemeyer can't make it for the sync [12:59] maybe we should set up a separate meeting to discuss interfaces/playpen? [12:59] I could have otherwise just not today (I learned a moment ago) [12:59] niemeyer, zyga, would another day this week work better for you? [13:00] dpm: any, sorry, I'm usually free at this time [13:01] dpm: Not at this time [13:02] dpm: I mean, not if the slot is at the same time of the day [13:07] dholbach, niemeyer, zyga, would tomorrow, 30 mins later than the original time work? [13:08] I'm looking at the calendars and I don't see any conflicting calls [13:08] earlier would work, I'm free at all times except for the stand-up call we have right now [13:09] 1h earlier, then? [13:09] kyrofa yeah, it is fine [13:12] is plugs security enoug to let a snap access to the network? [13:14] yes [13:14] 'network' plug gives you client access [13:15] zyga, niemeyer, so would tomorrow, 13:30 UTC work for you, right after your standup? [13:16] dholbach, I'm otp atm, if that works for everyone, would you mind moving the meeting? ^ [13:16] dpm: Yeah, that works [13:16] excellent [13:16] dpm, hohum... that won't work for me [13:16] I have an appointment from which I have to get back home [13:17] I'd be late quite a bit [13:17] maybe I should make that clearer in my calendar [13:17] dholbach, dpm: Done, thanks! [13:17] or hang on [13:17] UTC [13:17] nevermind [13:17] ignore me [13:17] dholbach, ok, cool :) [13:18] sorry, I didn't want to complicate things additionally :-) [13:18] all good now :) [13:43] jdstrand: about x11, can we do anything about that untrusted client thing that mjg59 mentioned? [13:49] 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:54] sergiusens, well, through the normal SRU process [13:55] have bugs ... subbscribe the SRU team ... upload to -proposed with the bugs mentioned in the changelog ... [13:57] 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] zyga: all options require engineering effort [13:58] zyga: but the main thing is that this is a strategic decision and a transition, and messaging should reflect that [14:00] zyga: and messaging beyond what has been messaged is being discussed with olli, jamiebennett, etc [14:02] sergiusens, get all fixes into yakkety first [14:03] 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] sergiusens, let me know if you need any help with that [14:10] jdstrand, hey, can you tell us how snap is blocking syscalls? seems to block "socketcall" on my i386 install for some reason [14:12] seb128, via seccomp [14:13] ogra_, any idea about it blocking "socketcall" on i386? [14:13] (there used to be ways to exclude syscalls from it ... not sure that still exists with the switch to interfaces though) [14:13] well, it will most likely block creation of system sockets outside of the confined snap area [14:14] (you should be able to create session related sockets in your rw space though) [14:17] 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:18] seb128: you can manually add them to the seccomp filter in /var/lib/snapd/seccomp/profiles/... to temporarily unblock yourself [14:18] jdstrand, is there still a way via snap.yaml ? [14:18] jdstrand: the problem is that the syscalls for individual socket APIs are very new on i386 [14:18] and glibc still doesn't implement them via the new calls [14:19] so on i386 we need to allow socketcall() for any network access [14:19] but unfortunately that will also open up bind() listen() etc [14:19] this is more or less why they introduced the new calls.... [14:19] seb128: socketcall is included in the 'network' plug. add 'plugs: [ network ]' to your yaml [14:19] (for the sake of seccomp) [14:19] jdstrand: we already have that :/ [14:19] seb128: it's possible you have that and it isn't autoconnecting. sergiusens saw that yesterday [14:19] desrt: ^ [14:20] I think zyga is aware of the issue [14:20] really, we need a new glibc... [14:20] desrt, just ship it in your snap ;) [14:21] oh, no I lied [14:21] socketcall is commented out [14:21] it is intentionally blocked [14:21] could we at least get it with network-bind? [14:22] probably [14:22] if we have network-bind then clearly the whole range of socket calls is OK... [14:22] let me look into it [14:22] thx! [14:22] for now, to unblock yourselves while I look at that, add it to /var/lib/snapd/seccomp/profiles/... [14:22] thanks for the help :) [14:23] jdstrand, thanks [14:23] you might want to let socketcall() happen for 'network' if we're on x86.... [14:23] 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:25] 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:36] 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:37] jdstrand, is there a way to allow dbus communication between unity and confined softwares? [14:37] jdstrand desrt yes, after multiple install/uninstalls will eventually casuse this [14:39] 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:40] slvn, sounds like an okayish way to me [14:41] apps also need to be able to own a specific bus name [14:41] ogra_, ok :) [14:42] ogra_, maybe a magic CMake instruction, to automate the copy of images to ./snap :/ ? [14:43] * ogra_ would just use the copy plugin to copy the dir [14:45] ok! [14:45] slvn, indeed, that's what the copy plugin is for [14:47] dpm can I have comment permissions to your "Snap this!" doc? [14:47] dpm thanks! [14:47] sergiusens, done [14:55] dpm yeah, I said thanks when I saw I had access :-) [14:55] dpm fully commented, every bullet ;-) [15:02] ogra_, kyrofa, in fact, I use "install(FILES ${IMAGES} DESTINATION .)" because COPY copy in build/... [15:02] sergiusens: hey, how can I get snapcraft to be more verbose (or a plugin to be)? [15:03] slvn, ah, we meant the copy plugin in snapcraft [15:03] slvn, but doing it in cmake works as well :) [15:04] Trevinho --debug [15:04] yeah, indeed [15:04] kyrofa, :) well .. since it's now written in the cmakefile .. I'll keep it there.. [15:04] Trevinho we still have an action to add --verbose which would enable verbose builds for everything that supports it [15:05] slvn long term, doing it in the build system is the better option [15:05] sergiusens: ok, thanks [15:05] sergiusens: it would be cool [15:05] seb128: sorry, was in several meetings [15:05] 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:06] 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] Trevinho two parts should work [15:06] slvn, great! [15:06] Trevinho what are you doing out of curiosity? [15:06] sergiusens: mh well... it almost does... but then I've an error in looking for files [15:06] 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] dbus, [15:06] Trevinho I have multiple additions for the nodejs plugin (among those, being able to use gulp as the driver) [15:06] sergiusens: then do: sudo apparmor_parser -r /var/lib/snapd/apparmor/profiles/... [15:07] err [15:07] seb128: ^ [15:07] err [15:07] :-) [15:07] sergiusens: as experiment https://github.com/Aluxian/Whatsie [15:07] seb128: that will allow all dbus calls until you reboot [15:07] jdstrand: the changes are http://paste.ubuntu.com/16081259/ [15:07] jdstrand, thanks [15:07] jdstrand: very hacky though [15:07] seb128: actually, until snapd updates the file, which I think is on reboot but might happen every 12 hours [15:08] there are hardcoded archs... or [15:08] cahce files with are not generated [15:08] cache* [15:08] oh, you are doing this on i386 and not amd64? [15:08] jdstrand, the pastebin from trevinho are our hacks from the day [15:08] I am [15:08] my laptop is 6 years old never reinstalled [15:08] I see [15:08] I could easily adjust locally [15:08] Trevinho you might want to wait for my gulp branch [15:08] but we have people who tried on amd64 [15:08] well, yeah... but also in a brandnew VM things do the same [15:08] right [15:09] Trevinho: that is a diff to my junk branch? [15:09] sergiusens, gulp? [15:09] sergiusens: ah, ok... [15:09] jdstrand: yes [15:09] jdstrand, yes [15:09] ok, I have another meeting in a few minutes but will start playing with this after [15:09] sergiusens, are you telling us we shouldn't have started working on a gnome example because we dup work with you? [15:09] seb128 no, I am talking to Trevinho ;-) [15:09] jdstrand, k, we are mostly done for today here [15:10] jdstrand: this is for x86-64 http://paste.ubuntu.com/16082479/ [15:10] jdstrand: and... you need to copy there /usr/share/mime/mime.cache [15:10] seb128 carry on with gtk :-) [15:10] sergiusens, well, Trevinho is with us at a team sprint where we collectively work together [15:10] seb128 oh, well he is looking at a nodejs project [15:10] ah ok [15:10] * Trevinho too [15:10] so other thing :-) [15:10] jdstrand, you should just declare it "notabug" and blame seb128 for skipping laptop refreshes twice already :P [15:10] ah yes the loaders cache. I would've forgotten about that [15:10] * Trevinho multi-tasking [15:10] Trevinho: thanks! [15:11] ogra_: hehe [15:11] seb128 and I've just added gulp support (a nodejs build driver) to the nodejs plugin [15:11] still missing grunt [15:11] jdstrand, we got gnome-calcultor to work including icons and exported menus and theme (unrestricted), in restricted menus are missing [15:11] seb128: willcooke said something about you guys pushing a branch somewhere at some point. can you ping me whenever that happens? [15:11] and the G is not related to glib, gtk or gnome :-) [15:12] sergiusens: that is great! I have some policy for menus but lacked an app to verify it [15:12] jdstrand, sure, I need to clean up the diff in the pastebin and replace the arch encoded bits [15:12] darn it [15:12] seb128: ^ [15:12] k [15:12] great :-) [15:13] 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:14] be introducing postinst in snaps ? [15:14] that wouldn't help [15:15] 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] you don't want each app to ship the glib locales and have to do e.g locale-gen [15:17] sergiusens: the only thing I did was a simple http://pastebin.ubuntu.com/16082644/ [15:17] seb128: oh for sure. that is rather icky. but one step at a time :) [15:18] seb128: curious if you think that means changes to gtk to support snaps (whether that is a plugin or something else) [15:18] jdstrand, are we going to recommend upstream to copy our hacks to include gio, etc caches? [15:18] seb128: no, I mean design a solution that can work with it [15:19] basically, I'm curious if you have ideas on what the proper solution will be [15:19]