[00:34] sgclark, there are a few here: https://github.com/kyrofa/qt-example-snaps [00:34] Sorry the room is a little quiet-- most of the team is in a team meeting this week [00:35] no worries, tyvm! [00:35] sgclark, they're literally qt examples (from the sdk) [00:35] asac: can you please create a PPA for me in ~snappy-dev called edge? or give me access to do that [00:39] kyrofa: excellent, looks to be exactly what I need. thank you again. [00:39] sgclark, certainly! They aren't perfect-- I'm missing a few stage packages; menus don't work [00:39] sgclark, but elopio will fix that soon [00:41] cool, I have the kde community at my disposal to bug as well :) [00:41] sgclark, I think https://code.launchpad.net/~dpm/ubuntu-calculator-app/snap-all-things will make for a QML example [00:41] sgclark, very receptive to pull requests if you're able to improve things [00:42] excellent, I look forward to some fun. been wanting to work with snappy for some time. [00:57] sgclark, wonderful! This room will be hopping again next week :) === Aria22 is now known as Aria22|away [01:36] * sergiusens waves hello at sgclark [01:36] nice to see you! [01:40] hi sergiusens :) [01:48] sgclark so there is some interesting stuff coming up soon wrt that library snap I mentioned a while back. It should be worked on soon and make getting the full kde stack in fairly easily. In the meantime, I guess I can suggest to create a snap with one app and then continue adding on to it. [01:48] sgclark I am just implying you are doing kde stuff from what I read above :-) [01:49] In any case I hope you find the fun in it. [01:49] :D [01:57] hello [01:58] vzioss, hi! Welcome [01:58] thanks kyrofa! [01:58] I am trying to build a snap package [01:59] having doubts in the parts plugin thing [01:59] vzioss, how can I help? [01:59] If I understood from the your-first-snap help page [02:00] you can write python3 in the plugin section [02:00] and have python3 [02:00] and you can also use source to point to a python3 code [02:00] vzioss, indeed, run `snapcraft list-plugins` to see all the options you could use there [02:01] vzioss, if you want to see how to use the python3 plugin, try `snapcraft help python3` [02:01] but how does one tells that there is dependency on things like pyqt, numpy, and stuff like this ? [02:01] ah [02:01] ok [02:01] vzioss, does that help a bit? [02:01] this help command tells me just that [02:01] vzioss, very good :) [02:01] this is really useful [02:01] thanks [02:03] vzioss, any time! [02:06] vzioss, if you want some examples to refer to, take a look here: https://github.com/ubuntu-core/snapcraft/tree/master/examples [02:10] thanks kyrofa! [02:10] I'm am trying here, I think I can make this work... If it works, this is the most impressive thing I've seen. [02:11] vzioss, then I hope it works! :) [02:21] kyrofa, have you used python3 plugin? [02:21] vzioss, indeed [02:22] kyrofa, I understood that below the line plugin:python3, I should just place a line stating with python-packages: [02:22] the package names [02:22] how do I list them? [02:23] I wrote python-packages:pack1,pack2,pack3 and got "is not of type array" [02:23] vzioss, yeah you need a YAML array [02:23] vzioss, so you have two options: python-packages: [pack1, pack2] [02:23] or [02:23] python-packages: [02:24] - pack1 [02:24] - pack2 [02:24] ah, ok [02:24] This is really my first yaml file in my life [02:25] thanks, stage worked [02:27] damn pillow returns a error. [02:27] is there a plugin for apt ? [02:27] vzioss, you mean you need debs in your snap as dependencies? [02:27] so I could just install python3-pillow from repo instead ? [02:28] vzioss, you can (by using stage-packages), but you should be able to make it work from source as well [02:28] yeah, pip or whatever snapcraft stage call get's an error [02:29] vzioss, is the pip package bad? [02:29] I don't know, let me try to install pillow from pip [02:29] I'm in a clean virtual bo [02:29] x [02:29] vzioss, what error did you get? Maybe pastebin it? [02:30] just a moment [02:33] pastebin.com/EtY2ubiv [02:34] vzioss, ah, looks like you need libjpeg [02:34] vzioss, try adding build-packages: [libjpeg-dev] to your part [02:34] ok [02:35] vzioss, do you see where I got that? [02:35] build packages is nested below my part? [02:36] vzioss, example: https://github.com/ubuntu-core/snapcraft/blob/master/examples/py3-project/snapcraft.yaml [02:37] ok [02:37] it asked my sudo password [02:37] is this normal? [02:37] I gave it [02:37] just found unusual... [02:37] vzioss, indeed, build-packages install on the host [02:37] ok, it build ok [02:37] vzioss, so it just ran `apt install` for you [02:38] I will try adding pyqt4 [02:38] this will be a ride... [02:38] I was never able to install pyqt4 from pip, always used the ubuntu packages [02:39] vzioss, you still can. It looks the same as the build packages, but it's called stage-packages [02:39] vzioss, but oftentimes debs are hard-coded to work in a typical debian system, and snappy is a little different, which is why I typically recommend using source [02:39] vzioss, but wouldn't hurt to try [02:40] if I just add in build-packages [02:40] it should work right? [02:41] ok, it appears it worked [02:41] vzioss, read about the differences between stage- and build-packages: https://github.com/ubuntu-core/snapcraft/blob/master/docs/snapcraft-syntax.md [02:41] build-packages install on the host (and don't make it into the snap), stage-packages are unpacked into the snap [02:42] thanks, I am saving this chat and favoriting those links. [02:43] vzioss, we're working hard on better docs as well, but glad you're asking the questions! [02:46] yeah, I really pyqt, it's really easy to use, being able to hop in the gigantic library of things in python gives faster results [02:46] and the snappy system is really way less daunting than packaging something to be available in debian. [02:48] how do I clean after having made a mistake before stage? [02:48] it should be written here: https://developer.ubuntu.com/en/snappy/build-apps/snapcraft-usage/ [02:49] vzioss, check out `snapcraft -h`. Specifically, you can run `snapcraft clean` to clean completely, or `snapcraft clean --step=stage` to clean only the stage step [02:51] Collecting pyqt4 " Could not find a version that satisfies the requirement pyqt4 (from versions: ) No Matching distribution found for pyqt4 " [02:52] this is a weird error, let me first google this... [03:09] ok, used stage-packages [03:09] does anyone have some docs on the filesets ? [03:10] vzioss, https://github.com/ubuntu-core/snapcraft/blob/master/docs/snapcraft-parts.md [03:12] ok, reading here: https://developer.ubuntu.com/en/snappy/build-apps/your-first-snap/ [03:13] how does the source in the line: source: git://github.com/mikix/golang-static-http [03:13] goes to the right place ? [03:13] I understood filesets does that, but not exactly how [03:14] the source points to a single file, named main.go [03:15] in the filesets there is a entry named go-server [03:16] since this exact name isn't anywhere else I assume this name doesn't matter [03:16] and then there is the line bin/golang-* [03:16] how did it went to the bin folder ? [03:17] vzioss, the go plugin puts it there [03:18] ok, the python plugin creates a folder named build [03:18] but then, I understand that unless I created a setup.py file [03:19] the program won't be in /opt or wherever I want [03:19] is this the correct understanding ? [03:20] I mean, what matters is what ends up in the folder "stage" [03:20] vzioss, what REALLY matters is what ends up in the "snap" folder, but you have the right idea [03:20] vzioss, indeed, the python plugin needs you to tell it somehow what to build, where stuff should go, etc. [03:21] yeah, I didn't get to the snap step yet [03:21] ok [03:21] thanks kyrofa [03:21] It seems I need to take some time with this, but it's very doable [03:21] I really liked [03:21] I am going to sleep because I have to work in 5 hours [03:21] vzioss, just like the make plugin, or cmake-- you need install rules in order for snapcraft to know what is important to go into the snap. You don't want it to just copy everything (object files and whatnot) [03:22] vzioss, alright, sleep well! [03:23] bye, thanks kyrofa! [03:23] vzioss, any time! [03:23] company is CentOs, some day I need to findout how to run this there.. hahaha === chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk [13:09] tyhicks: fyi, https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1576287/comments/7 [13:09] Launchpad bug 1576287 in snapd (Ubuntu) "unity7 plug needs to be updated to allow menus export" [Undecided,Fix released] [13:10] http://paste.ubuntu.com/16388460/ [13:10] any idea what's going on? [13:11] tyhicks: you mentioned appmenu, do you know of a failing app? [13:12] ysionneau: this seems wrong: devpts on /dev/ptmx type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000) [13:12] ah ? [13:13] /dev/ptmx should be a file, not a filesystem [13:13] hmm I wonder who's doing this mount then :o [13:13] it can either be an actual file or a symlink to /dev/pts/ptmx [13:13] aiui [13:14] root@localhost:/etc/apparmor.d# ls -l /dev/ptmx [13:14] c--------- 1 root root 5, 2 Jan 1 1970 /dev/ptmx [13:14] ysionneau: is this on a classic system? [13:14] this is on a Snappy system [13:15] ysionneau: what type of snappy system? [13:15] I took the rpi2 ubuntu-core (+ initrd) and modified it to run on my board [13:15] amd64, rpi2, ... [13:15] I see [13:15] it's running on Tegra X1 [13:15] but it's basically an rpi2 ubuntu-core [13:16] oh, you did it [13:16] root@localhost:/etc/apparmor.d# mount -o bind,rw /dev/pts/ptmx /dev/ptmx [13:16] no that's right [13:16] meh [13:17] nop actually the first line was already there before my mounting try [13:17] ysionneau: looking at the apparmor message, it seems that on your system /dev/ptmx is a directory and not a file [13:17] ysionneau: I suggest rebooting and confirming that [13:17] but ls -l shows a character device :o [13:18] ok let's try that [13:18] ysionneau: perhaps because of the bind mount you did [13:18] (re the ls) [13:18] ah yes [13:19] ysionneau: http://manpages.ubuntu.com/manpages/xenial/en/man4/ptmx.4.html [13:20] "The file /dev/ptmx is a character file..." [13:20] if it comes up as a directory, that is the issue [13:20] after a reboot: http://paste.ubuntu.com/16388554/ [13:21] that all looks fine [13:22] I think it's just apparmor refusing the mount ... but why [13:22] since the apparmor profile looks fine to me [13:22] ysionneau: notice in the denial it said '/dev/ptmx/ [13:23] that trailing '/' indicates that apparmor interpreted the mount as on /dev/ptmx/ not /ev/ptmx [13:23] the apparmor rules allow mounting on the file, not the dire [13:23] ctory [13:23] aaah ok [13:24] why it was a directory at that time, I can't say [13:24] weird because in ubuntu-core-launcher there is no trailing / : http://bazaar.launchpad.net/~snappy-dev/ubuntu-core-launcher/trunk/view/head:/src/main.c#L341 [13:25] ysionneau: right, that all supports what I'm saying [13:25] ysionneau: the launcher just tries to mount on /dev/ptmx [13:26] but *if* /dev/ptmx is a directory at the time that happens, apparmor (the kernel) will interpret that as /dev/ptmx/ [13:26] ah ok [13:26] and the policy doesn't allow mounting on /dev/tpmx/ (a dir), it allows mounting on /dev/ptmx (a file) [13:27] so something might remove the /dev/ptmx file when running ubuntu-core-launcher and replace it with a directory :o [13:27] weird [13:27] again, why it was a directory at the time of the mount is a mystery still. I suggest keeping on eye out for this and if you can find a reproducer, file a bug [13:28] jdstrand: ping [13:28] I'm not able to reproduce it here [13:28] morphis: hey [13:28] jdstrand: hey! [13:28] jdstrand: did you saw my update on the network-manager PR? [13:29] morphis: I just came on and haven't gotten through my email yet. I see the mails [13:29] jdstrand: aye [13:29] jdstrand: if you have a few min I have another quick thing and would like to see if you like it or not [13:30] fire away [13:30] we thought a bit how we could do just in-snap dbus communication [13:30] like we put modem-manager into the same snap than network-manager [13:30] which we require a very specific interface for this [13:31] so instead of crafting a eventual vendor-specific interface here I have two new dbus interfaces: dbus-name and dbus-access [13:31] dbus-name is provided by the OS snap and allows a snap to acquire a dbus name [13:31] dbus-access is another interface to allow dbus communication between two apps on specified object paths [13:32] which then summary allows soemthing like: https://pastebin.canonical.com/156418/ [13:33] dbus-access creates just one slot-side apparmor rule so far: https://paste.ubuntu.com/16388712/ [13:34] Isn't there any other possibility than /dev/ptmx being a directory ? [13:34] 'cause I find this highly unlikely :/ [13:34] morphis: the fact that it slots the service1 and service2 means it would be connectable between snaps (in the current implementation). also, what if I create a snap that does path: /org/freedesktop/NetworkManager ? [13:34] however this introduces one problem: anyone could try to get access to anything if not prohibited in some way [13:34] ysionneau: there could be a bug somewhere-- but I can't reproduce. if you can, please file [13:35] jdstrand: yeah, I see the same problem [13:35] well I can reproduce it but on a hardware I am the only one to possess :p [13:35] I would try on my rpi2 but I guess it won't reproduce [13:36] jdstrand: but I don't see another way so far how we can allow dbus communication between apps of the same snap [13:36] we could limit the dbus-access rule to check for label=snap..* [13:36] let's try on the rpi2 anyway [13:37] morphis: so internal snap communications should be allowed imo, but using dbus in this manner is using a public bus to do internal communication [13:37] sure [13:37] I wonder if you used a private bus? [13:38] then we loose the capability for other snaps to communicate with us [13:38] just spitballing here [13:38] or would require us to proxy between two dbus-daemons [13:38] morphis: but you said modemmanager was only for internla? [13:38] yes [13:39] oh so you are saying nm is external and mm insternal, that is an issue. I can see that [13:39] if we just leave modem-manager running against its own dbus-daemon we introduce a set of complex problems in the interface from network-manager [13:39] if both were internal, maybe a private bus could be used [13:39] yes [13:40] morphis: I'm not sure... I think this needs zyga and niemeyer [13:40] jdstrand: yeah, just wanted to get your first feeling about this [13:41] morphis: well, I think the use case is interesting. I think there are some issues to work through [13:41] jdstrand: basically I would like to escape a bit from the need to write an interface in snappy core for everything [13:41] that slows things terrible down [13:41] I can understand that [13:42] I can say that things should go much faster once we have some experience and have worked through the corner cases [13:42] the thing is now, everything is new and needs to be thought through a lot [13:43] I mean, they'll all need to be thought through a lot, but in the future we will have already thought through big parts [13:43] yeah! [13:43] man, why is my irc so laggy?! [13:45] freenode :-) [13:48] seb128: hi! do you know of something that uses appmenu that I can use for bug #1581191 ? [13:48] bug 1581191 in snapd (Ubuntu) "please add AppMenu to the unity7 interface" [Medium,Triaged] https://launchpad.net/bugs/1581191 [13:53] it seem slibreoffice does [13:53] I'll see if I can work with that [14:12] jdstrand, check with tedg I would say, I'm unsure when/when com.canonical.AppMenu is used [14:13] codesearch indicated libreoffice does. I'll play with that [14:13] seb128: thanks! [14:13] yw [14:13] k === Aria22|away is now known as Aria === Aria is now known as Aria22 [14:27] Is there a solution to have snappy on tablet like Nexus 7 or Aquaris M10 [14:27] ? [14:32] hmmm I can't get the RPI2 to boot anymore with Snappy :o [14:33] I've just generated a brand new rpi2 image using zyga's ubuntu-image [14:33] it says "Starting kernel ..." and nothing more [15:01] seb128: fyi, libreoffice in at least xenial does not use AppMenu [15:01] is the rpi2 port broken as of today? [15:01] tedg: hey, can you give me an example application that uses AppMenu (it could even be a test program) [15:14] jdstrand: I believe that GTK apps do, it's the registration mechanism. [15:15] jdstrand: It'll need to have the unity-menus module loaded [15:15] jdstrand: Which might not be in your snap. [15:17] tedg: so, I've seen some things with dbusmenu and a lot of things for gmenu. global menus seem to work [15:18] tedg: it sounds like perhaps if I add unity-menus to stage-packages in a snap I might start to see AppMenu accesses? [15:18] would it work for say, gnome-calculator-app? [15:18] and ftr, I can't wait for unity8 [15:19] jdstrand: I believe so, it depends on the app. Let me check that one. [15:19] these dbus apis for menus are not very mediation-friendly [15:19] jdstrand: No, they were designed in a simpler time :-) [15:20] I wonder what we are going to do when someone finds a way to attack the menu system of another app... [15:21] jdstrand: It really only tracks by window ID really. So we have no good way to verify either. [15:21] jdstrand: Perhaps with X11 AppArmor stuff? [15:22] nope [15:22] that was ruled out [15:22] (in the sprint this week) [15:22] jdstrand: Ah, makes sense, but not up to date :-) [15:22] if anything is done for X (subject to desktop team priorities) it will be a nested X [15:38] jdstrand: sit tight on the global menu stuff - I'm gathering info [15:38] jdstrand: it sounds like people may be mixing up the global menu and the indicators [15:44] tyhicks: well, I'm still going to fix the things I know are broken. eg, I have a PR for the systray bug for notifications and then preparing another one that makes libreoffice work [15:45] tyhicks: I talked with tedg about AppMenu. See the conclusion: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1581191/comments/1 [15:45] Launchpad bug 1581191 in snapd (Ubuntu) "please add AppMenu to the unity7 interface" [Wishlist,Won't fix] [15:45] tyhicks: I guess that counts as 'sit tight' [15:46] jdstrand: asf far I cheked, the appmenu interface was supported by ubuntu-qt module... [15:47] Trevinho: do you have a snap I could try this on? [15:47] tedg: was that one you looked at? ^ [15:47] jdstrand: No, I was looking at GTK apps, I thought they still used it. [15:47] Didn't think of the Qt one. [15:48] jdstrand: mh, no.. but you can do it with any simple electron app. They are using appmenus (sadly, so I'll probabably fix it upstream), but even the electron simple binary uses it [15:48] tedg: yeah... as for qt btw I (or someone else) will probably move the things to menumodel... most of the pieces are already there [15:49] Trevinho: I'm unfamiliar with electron apps. is there a simply one you can point me to? [15:49] erf, it looks like they embed chromium [15:49] sergiusens: don't you have an electron app? [15:50] jdstrand, yes he does! [15:50] jdstrand, vscode and atom in progress [15:51] jdstrand: I guess snapcrafting https://github.com/electron/electron-quick-start is just enough [16:16] good morning [16:22] so, if it uses chromium, perhaps I can play with chromium to see if it needs the accesses [16:25] chromium works fine with my two PRs [16:34] ogra_: can you please change the daily os snap builds to use the new edge PPA, instead of the image one? [16:34] elopio, where is that ? [16:35] (you also need to let mvo know where to upload to then) [16:37] ogra_: no, I've forbidden mvo to upload here. :) [16:37] ogra_: https://launchpad.net/~snappy-dev/+archive/ubuntu/edge/+packages [16:37] the rc snap will be generated from -proposed. And the stable from the xenial archive. But we can talk about that in a few mins. [16:38] yeah, lets talk [16:38] (there are a bunch of issues since we need the PPA for development) [16:58] jdstrand: my current implementation is now at https://github.com/morphis/snappy/commit/7d4a725b6fa72ee80558fbb1ab19b4340acb8640 (dbus-name) and https://github.com/morphis/snappy/commit/38d60ce083d1684b20d7394ad5f6824a298efd9d (dbus-access) [17:01] jdstrand: which actively prevents the interface connections from plugs/slots which are not part of the same snap: see https://github.com/morphis/snappy/commit/0489b6f23b190d817975247d460990f67e0c4d5c#diff-79bf2731f5c1893501e7731ecbcf7059R58 [17:01] zyga: ^^ you might be interested in that as well, prototyped a quick idea today to enable in-snap dbus communication [17:02] not ready yet for an MP and we should discuss that next week or so a bit more in detail [17:04] jdstrand, zyga: see https://git.launchpad.net/~snappy-hwe-team/snappy-hwe-snaps/+git/examples/tree/ for two snaps which are using those two things [17:04] morphis: interesting [17:04] don't count on any names/patterns or so yet [17:05] well, it is a starting point for discussion [17:05] jdstrand, I tested out https://github.com/ubuntu-core/snappy/pull/1165 and had a question on the PR [17:05] jdstrand: yeah [17:05] so, weekend time :-) [17:06] kyrofa: hmm I didn't play with the indicator bit (I missed it) [17:06] kyrofa: let me look at that [17:06] jdstrand, excellent, thank you! [17:07] ok yes I can confirm [17:11] jdstrand, ping me if/when you add something there and I can retest [17:16] morphis: interesting, let me see [17:21] morphis: that's really cool [17:21] morphis: I think we should explore the attribute matching on slots and plugs [17:22] morphis: so you'd have a slot 'bus-name' with an attribute 'com.example.App' [17:22] morphis: and a slot with something similar [17:22] s/slot/plug/ [17:22] morphis: and only allow the connection to form when those match [17:22] morphis: we need to get a callback for connection attempt [17:23] morphis: by default it should just check the interface name on both ends [17:23] zyga: one thing I'm concerned about is squatting a well-known name [17:23] morphis: but this would need it to match attributes too [17:23] jdstrand: that's a review process [17:23] jdstrand: we'll let people do squatting in private [17:23] jdstrand: then nail it in review [17:23] jdstrand: (stateful review matters) [17:23] brb [17:24] zyga: I think we should discuss this with niemeyer next week [17:24] zyga: (since morphis is eow) [17:24] kyrofa: ok, pushed [17:25] jdstrand, sweet, testing now [17:25] kyrofa: https://github.com/ubuntu-core/snappy/pull/1165/commits/de024b32878e82d8b28e695a83641f2883d3f1f0 [17:28] jdstrand, perfect [17:28] Works great [17:29] jdstrand: that's a plan [17:29] jdstrand: note that we anticipated some of this with the $syntax [17:29] jdstrand: where an attribute starting with the dollar sign was reserved [17:29] kyrofa: \o/ [17:29] zyga: interesting [18:11] jdstrand: mostly eow [18:11] zyga: thanks for a having a first look [18:11] morphis: I'll have to talk to gustavo about the implication of getting the generic IPC interfaces in place [18:12] zyga: thanks [18:12] morphis: and we should open a pull request only after this is done [18:12] zyga: the background for this is basically: [18:12] morphis: one more thing, I think the connection "sanitization" method is needed in the interface [18:12] morphis: so that we can reject right there without a hook [18:12] morphis: and so that it is a natural place to enable hooks later [18:12] we thought this morning about: what if we do a snap which privides modem-manager and network-manager but we only want it for a specific vendor and only want to provide an external interface for network-manager [18:13] putting those bits into a network-manager interface doesn't sound right [18:13] morphis: hmm, maybe [18:13] and we should have a way to allow in-snap IPC communication [18:13] morphis: yes, I agree about the 2nd part for sure [18:13] morphis: still need to think about 1st [18:14] jdstrand I have a vscode one to share with you if you want, give me a sec to upload to the store. Can you see unpublished snaps? [18:14] zyga: for me it does, as we're cluttering a generic network-manager interface then with implementation specifics [18:14] morphis: I need to think if n-m + mm is a special case [18:14] zyga: sure, I am still playing with this, will folow up with you guys next week [18:14] have to leave now! [18:14] bye [18:14] morphis: +1 [18:19] elopio mind testin 2.8.8b when it comes into proposed? [18:20] sergiusens: no problem. [18:26] jdstrand putting the snap somewhere you can get, expect to look at PMs [18:43] sergiusens: ack [19:07] jdstrand: a basic electron app could be just https://code.launchpad.net/~3v1n0/+junk/electron-quick-start-snap [19:08] jdstrand: however, I don't see the menus exported there, but it might be cause of many reasons (electron might think that is not running in unity, or missing some gtk stuff - although adding it didn't change much) [19:10] ok. I'll take a look. tedg said maybe some library just needs to be present === Aria22 is now known as Aria22|away [20:01] jdstrand: yeah, in the past they were doing a check of the presency of libunity I think [20:17] jdstrand: oh, it was just about including libdbusmenu-glib4 as stage package... http://i.imgur.com/RH6Jhgd.png [20:18] nice! [20:18] I'll take a look in a few minutes [20:18] jdstrand: ah, I didn't check the unit7 rules, are the libunity apis already available for users (the ones that add badges and progress bars to the launcher)? [20:19] Trevinho: some are, I'm sure there are some missing (I lacked an example) [20:23] jdstrand: mh, hello-unity should be snappified in the examples, it's a good way to test things [20:24] jdstrand: I mean this one http://bazaar.launchpad.net/~snappers/snappy-playpen/trunk/files/head:/hello-unity/ [20:25] Trevinho: ok. I think I tried that before, but it was weeks ago [20:25] * jdstrand tries again [20:26] Trevinho: did you commit your libdbusmenu-glib4 change to the junk branch? [20:26] jdstrand: the wrapper has i386 arch, so I guess you want to change that [20:26] oh maybe that is all it was [20:26] jdstrand: speaking of which... do we plan to ship better "default" scripts for such cases? [20:27] Trevinho: I think that is a sergiusens question [20:27] and to to use the arch for the builder... [20:27] jdstrand: ah, yeah... [20:27] Also, it would be nice to be able to generate .cache files (such as the mime type or the libgdk pixbuf plugin liest....) from the files installed locally.. So chrooting where the fiels have been eextracted and running thr proper tools at build time [20:28]