[00:06] kyrofa, well it is all by convention, defacto status quo [00:06] sergiusens, seriously, who writes a tool with this as the setup guide? https://github.com/kyrofa/fboss/blob/master/fboss/agent/tools/README.md [00:07] sergiusens, also: ZERO INSTALL RULES [00:07] omg :-P [00:08] sergiusens, I'm not sure how to make this thing shippable :P [00:08] sergiusens, but it's very close. Every prepreq worked more or less fine [00:08] And this builds fine [00:09] kyrofa, sounds good enough; a custom plugin is what makes it work and patches upstream of course [00:10] sergiusens, yeah [00:28] sergiusens, https://github.com/ubuntu-core/snapcraft/pull/354 [00:37] sergiusens, as soon as that changelog is given the go-ahead I'll release and email out an update [00:45] kyrofa, +1; going to call it in since I'll be back here in no more than six or seven hours ;-) [00:46] sergiusens, sounds good, thanks! [01:12] kyrofa, no need for an announcement on the mailing list or at least not needed for today ;-) [06:16] ping pitti: our autopkgtests on armhf are failing because: "sudo: no tty present and no askpass program specified". But they pass in amd64. [06:16] Do you know what's different in the testbeds? [06:27] elopio: armhf and s390x run in LXC, the other three arches in a full VM (in ova) [06:27] "nova" [06:27] elopio: if you have to call sudo in a test, please always call it with -n, to avoid blocking indefinitiely [06:27] and use SSH_ASKPASS [06:28] (this is usually already set in the test env, but you might change the environment) [06:29] pitti: ack. I'll get a lxc tomorrow to give it a try. [06:43] good morning [06:50] stgraber: hey! do you mind answering to that one (as you did the snap), please? http://askubuntu.com/questions/740692/lxd-snappy-add-and-run-continer [07:49] good morning [07:51] hey dholbach! How are you? [07:51] hey didrocks - doing well, just need to catch up with an avalanche of emails I got over night :) [07:51] how about you? [07:52] dholbach: quite similar! but I think I'll have time to continue on the importer :) [07:52] also, freezing here === sourcef_ is now known as sourcef === JerryKao is now known as JerryKao_mtg [08:47] morning [08:48] morning [08:52] is there some documentation somewhere on how to build an armhf snap from an ubuntu xenial amd64? [08:52] I guess I need some qemu debootstrap stuff [08:52] but I'm wondering if the exact instructions are listed somewhere [08:58] davidcalle, dholbach, do you happen to know if we've got any docs for that? ^ [08:58] and good morning all :) [09:01] morning mvo, while trying to get my calculator desktop snap running I hit an issue that robertancell mentioned you also had with cap-test: "could not connect to display :0". He was saying that "you got a private /tmp directory but the X socket (/tmp/.X11-unix/X0) was not added into the snaps tmp" [09:01] dpm: could you push the snap somewhere? happy to have a look [09:01] sure [09:02] mvo, http://bazaar.launchpad.net/~dpm/+junk/calculator-snap/files (see the README too) [09:02] dpm, in terms of docs there's just https://github.com/ubuntu-core/snappy/blob/master/docs/cross-build.md (and building on a device) [09:02] ta [09:02] ysionneau, ^ [09:02] thanks dholbach [09:04] dpm dholbach thanks! :) [09:04] dpm: try this //paste.ubuntu.com/15251748/ [09:04] dpm: for now, we will need a desktop profile for the security or rather a X11 interface etc [09:05] dholbach: this tutorial takes for granted that I already created an arm chroot and that I'm running in it? [09:05] mvo, cool thanks, let me have a try [09:05] ysionneau, I'm sorry - I didn't write the tutorial... let me see if I can find more information... [09:06] dpm: the syntax for this snippet will change very soon but I will send you a diff once it does [09:06] mvo, thanks a lot, building the snap now [09:12] ogra_, which doc do we currently recommend for building arm snaps? [09:14] mvo, that definitely brought me forward, but now opengl is not happy at all. Do you have any ideas what could be happening here? https://paste.ubuntu.com/15252031 [09:20] dpm: indeed, you need some more libraries in the snap for now, we need to work on this and solve this problem in a generic way because we can't have all apps ship all opengl implementations [09:20] good morning [09:20] hey zyga [09:21] mvo: don't we want to ship opengl in the kernel snap and use the (forgot the name) library as a dynamic adapter that apps link to? [09:21] (so apps just link to that and ship it but that thing actually opens gl libs that live in the kernel snap) [09:21] zyga: yes, but not on the desktop :) [09:22] oh [09:22] zyga: we need to sit down and solve this problem there too, its a bit unclear what the best path forward is right now [09:22] mvo, in the interim, while there is not a generic solution, any tips on which libs/packages I should add to snapcraft.yaml for the calculator app? [09:23] I'm hoping getting the app running might help to the discussion too [09:24] dpm: you will need to put dri/swrast_dri.so into your snap for now [09:24] dpm: as dri/swrast_dri.so [09:24] with the copy plugin, I guess? [09:24] dpm: and export LIBGL_DRIVERS_PATH=$(pwd)/dri [09:24] dpm: in your run wrapper [09:25] right [09:25] dpm: sorry, we are still at a early stage when it comes to convinicence of this process :/ [09:25] mvo, no worries, looking forward to get my first desktop snap running :) [09:28] mvo: thinking about it for a second I have a naive idea that might work [09:28] mvo: we can do the same thing [09:29] mvo: snappy on the desktop can just depend on a GL implementation [09:29] mvo: and the same flow from apps shipping the gl shim to the system library will follow [09:30] zyga: yeah, I think this is what we will do [09:31] mvo, two questions -> 1) on that pastebin, libGL also complains about the i965 driver not being found, so I guess I should include that in addition to swrast_dri.so as well? And 2) those libs are already in the generated snap, under ./usr/lib/x86_64-linux-gnu/dri, so I guess I don't need to actually include any and simply update my wrapper with the env variable? [09:32] dpm: yeah, if the libs are already there, just add the env var [09:32] yeah, tryint that now [09:33] ok, so I'm going to give this a go: "export LIBGL_DRIVERS_PATH=$SNAP/usr/lib/$ARCH/dri" [09:41] mvo, success! :-) [09:43] yay [09:44] mvo, thanks so much! I'll test the store upload now. There is just one small glitch: https://paste.ubuntu.com/15252970 - line 2 where it complains about not being able to write to that location to create the local database. Any ideas? [09:44] dpm, can you tell it where to save its data? [09:45] you can use $SNAP_USER_DATA env variable [09:45] dpm: what dholbach said, this location is inside the squashfs so we can not write there. it should use SNAP_DATA or SNAP_USER_DATA to write its database [09:46] dholbach, mvo, the database location is set by Qt/QML IIRC, I'll have to find out if it's possible to redefine that, as I think we do with click [09:48] dpm, maybe upstream would accept a patch to check if SNAP_USER_DATA is set and if so, use it? [09:48] (if there's no command line switch or anything) [09:49] I'm trying to ask the sdk guys. I used to know how LocalStorage for clicks worked, but I can't remember now [09:50] dpm: I'm sure we can do something, we did something similar for other packages, just an environment var to redirect the file location is usually accepted upstream [10:08] dholbach, mvo, so I've got the following variables defined for my appXDG_DATA_HOME data locations, which I copied from the snapcraft plugin: http://pastebin.ubuntu.com/15253544 - the sdk guys tell me I can override XDG_DATA_HOME. So in principle, I think I'll try an "export XDG_DATA_HOME=$SNAP_USER_DATA". Does that sound sensible? [10:11] dholbach, we have a doc ? [10:12] (i mean an arch specific one ) [10:12] ogra_, I could imagine that the question on how to build stuff for arm was not brought up the first time :) [10:12] dholbach, no, but i dont know about a doc [10:12] ok... [10:13] typically we walk people through here (starting by telling them to use a chroot, container or the classic dimension) [10:13] ysionneau asked earlier [10:13] nothing beyond that should be arch specific [10:14] (create the right snapcraft.yaml, run "snpacraft snap" ) [10:17] so far I've been using my own cross compilation tool, but I am starting to doubt that my stuff work correctly (related to my dlopen segfault from yesterday) [10:17] so I'm willing to do it "your way" to test and compare [10:18] that's why I asked how you would do an arm snap [10:18] if I've got an snap that I'm creating from fetching e.g. a repo or a .deb package, which already contains an icon, is there a way to get snapcraft.yaml to reference that fetched icon instead of copying it over to the top directory and pointing to that? I can do that, I'm just thinking in terms of unneeded duplication. [10:18] well, if you use snapcraft the only difference is that you need to emulate the other arch or build natively on your snappy install [10:19] (i usually prefer the latter nowadays, that rules out potential probs by emulation or chroot usage) [10:20] hmm ok so I should create an ubuntu arm image from a debootstrap, boot it with qemu, and use it like a developer machine to build my snap [10:28] ysionneau, you dont have an armhf device ? [10:29] (how will you test your snaps ?) [10:29] right now no, but I could ask for one, but I prefer testing using qemu [10:29] this will be horridly slow [10:29] so far I've done all my tests on qemu [10:30] slower than an arm board with eMMC memory? [10:30] definitely [10:31] I have access to a Tegra X1 board but it's a bit of a nightmare to boot ubuntu on it, I have not succeeded yet to do it [10:31] i thought there are pre-made ubuntu images from nvidia [10:31] because of the partitionning of this thing which needs tens of paritions for bootloaders etc [10:35] the tegra X1 will fly compared to qemu ... it will be a lot faster even if you just run from SD card [10:36] so i'd grab whatever nvidia provides and use debootstrap to create a xenial chroot on that system ... then build my snaps in there [10:36] (or just grab the classic ubuntu-core tarball, thats faster than debootstrap) [10:37] yeah would be cool to have ubuntu running on the X1 board [10:37] https://developer.nvidia.com/embedded/linux-tegra [10:37] I should try again, when the hardware department find one without buggy gpu or buggy pci-e to give me [10:38] buggy GPU should be fine for headless ;) [10:38] yeah but it caused some kernel panics at boot because the firmware it had was running some gstreamer stuff at boot [10:39] I thought it was a good idea to complain to hw department so that they give me another board... [10:39] bad idea. now I have no board =) [10:42] anyway, I'll use qemu for now, it's not *that* slow [10:43] it allowed me to play with ubuntu-core and make some snaps, install them, play with them [10:46] ok :) [10:47] anyone up for a quick review (tiny) https://github.com/ubuntu-core/snappy/pull/547 [11:07] zyga, mvo https://github.com/ubuntu-core/snapcraft/pull/356 [11:07] sergiusens: looking [11:07] sergiusens: " coverage/coveralls — Coverage decreased (-83.09%) to 11.657% " hu? [11:08] mvo, look at my comment :-) [11:08] mvo, or at the end of https://travis-ci.org/ubuntu-core/snapcraft/jobs/112805796 ;-) [11:10] sergiusens: nice [11:57] Hi folks. Is it possible to have a private snappy store ? [12:11] Good morning! [12:22] * zyga goes to fight with his failing hardware for a few moments [12:29] kyrofa, morning! I have something for you https://github.com/ubuntu-core/snapcraft/pull/355 [12:29] sergiusens, gifts? How nice! [12:33] kyrofa, there's also https://github.com/ubuntu-core/snapcraft/pull/356 which I don't mind more comments for as it will need a rebase anyways ;-) [12:33] anyone home ? [13:08] dpm, mvo: I added a few tasks to our coard on snappy on classic to review these apps. it may happen today, but more likely tomorrow [13:18] jdstrand, which apps? [13:19] calculator, caps-test, moonbuggy (already had libreoffice and firefox, but I don't think they are ready yet) [13:19] and by review, I don't mean store review-- I mean test them out and adjust security policies, etc [13:21] jdstrand, gotcha, thanks! Let me know if there is anything I can do on my end for calculator. As far as I can tell, everything is working except for the LocalStorage/XDG/Fontconfig issue I mentioned on the e-mail [13:22] and probably the list of packaged libs can be trimmed, but my main goal was to just get it to a point it worked, tools were exercised and I could do an upload to the store [13:26] * jdstrand nods [13:27] jdstrand: I would love to talk to you soon about desktop files and snappy [13:28] there is a 'Snaps on desktop' catchup later that I was invited to. I wonder if it would make sense to add you to that [13:28] tedg: opinion? ^ [13:29] jdstrand: yeah [13:29] well, dont we have all that stuff in the phone already ? [13:29] (generating .desktop files that use a wrapper (aa-exec) and all that stuff) [13:30] technically it should only be translated o the new world order [13:42] * zyga has another broken hdd, eh :/ [13:42] spinnig disk of eventual doom [13:43] stop using these mechanical drives :) [13:44] one by one [13:47] heh, seeing all the bugs from SweetShark it seems snapcraft is getting a reality check now :) [13:50] run-parts: /etc/network/if-up.d/ubuntu-fan exited with return code 1 [13:50] hmm, this happens on each ifup [13:50] and the network interface is really up but ifupdown thinks it is not [13:53] where should I report this bug, on ubuntu-fan or on snappy? [13:56] reported as https://bugs.launchpad.net/snappy/+bug/1551747 [13:56] Launchpad bug 1551747 in Snappy "ubuntu-fan causes issues during network configuration" [Undecided,New] [13:58] zyga, agains ubuntu-fan i guess [13:58] not sure how wlan capable it is at all [14:06] ogra_: fan has no upstream project, just a package, [14:08] yeah, weird [14:09] jdstrand: mvo: That is fine with me, it's kinda kgunn's meeting so I don't know how many guests I'm allowed to bring though :-) [14:10] tedg: it's definitely open to whomever has an impact/interest there [14:10] Cool, I'll add mvo [14:10] jdstrand: mvo welcome [14:11] willcooke: ^ :) [14:11] kgunn, strikes me ... we might also want to discuss how to ship graphics drivers on arm/arm64 ... i dont exactly know whats needed we need to ship [14:11] The meeting has been vogtted (sp?) ;-) [14:12] (not actually related to .desktop files etc ... probably deserves its own discussion) [14:12] ogra_: what do you mean? i mean it's just another arch [14:13] or am i missing something [14:13] kgunn, well, the RPi has its own binary blob ... most likely shipping libEGL ... do we need mesa too, could the free driver work etc etc ... same goes for the dragonbaord [14:14] i simply dont know what works and what doesnt ... and how i should ship it (most likely inside the kernel snap, butu i dont think we have any common setup for that yet) [14:14] ogra_: so it's an either or...mir/qtmir will work on either [14:14] ogra_: i will say, mesa is a little nicer being open source and all [14:14] altho... [14:15] hwc usually has some optimizations based on it's specific chipset [14:15] hwc ? [14:15] i'm talking about linux :) [14:15] we have no andfroid container [14:15] hwc= android's hardware composer [14:15] ah [14:15] and nobody worked on such a thing [14:16] ogra_: oh i'm sure chipset vendor's have it... :) [14:16] de facto [14:16] i was assuming we use the open or closed linux drivers ... and there i dont know what to ship and what we need additionally [14:16] ogra_: who's producing the closed ones ? [14:17] i would presume better maintenance/living deliveries [14:17] for the close ones [14:17] depends on the board ... dragonboard comes with adreno chipset, rpi with some proprietary broadcom [14:17] both have open alternatives ... [14:17] (but i dont know the state of either regarding Mir's needs) [14:17] ogra_: are there any complaints regarding the open alternatives ? [14:17] no idea [14:18] thats pretty much the end of my knowledge :) [14:18] ogra_: basically if there is gles/egl/drm/kms/gbm following the mesa interface model then we are good to go [14:18] currently both boards are competely headless, we dont ship anything [14:18] but given they are aour reference platforms i guess we should ship some way for people to run graphical stuff [14:19] ogra_: i'm keen on getting that on dragonboard [14:19] well, RPi is the typical kodi device ... i guess there too ;) [14:20] ogra_: in theory this is totally possible...i've run mir on dragonboard on regular ubuntu distro [14:20] aha ! [14:20] using which driver then ? [14:20] ogra_: mesa [14:20] uuh [14:20] SW rendering ? [14:21] that doesnt sound like something i'd want to do in production :) [14:21] ogra_: nope, it's hw accel gl [14:21] oh [14:21] ogra_: i just shared a doc with you [14:21] ogra_: I have the pi camera [14:21] ok [14:21] ogra_: trying to get it to work [14:21] ogra_: do you know if anyone tried that? [14:21] ogra_: I know what to do, I'm just curious [14:21] zyga, nope [14:21] (i dont know) [14:22] ogra_: so in my simple understanding of looking over at the core image side of the house...do you just need to seed the image with packages from that dragonboard distro? [14:23] then i magically get gl/display drivers as part of the core image? [14:23] kgunn, well, i dont know which ... you surely need either the closed adreno or the open freedreno driver to serve mesa [14:24] ogra_: k [14:24] ogra_: if the drivers themselves are closed...i don't really care, as long as the i/fs are conformant to what we need [14:24] and perhaps also kernel config we might not have enabled atm [14:24] (kms and friends) [14:25] ack [14:25] and specifically for the RPi2 i guess also the video codecs to make things like kodi work [14:25] ogra_: oh...and that distro is vivid...but i wanna be on xenial [14:26] indeed [14:26] we dont do non xenial for dragon atm :) [14:26] ogra_: how to change that ? [14:26] change what ? you want vivid for dragon ? [14:26] * kgunn chants "xenial, xenial, xenial..." [14:27] Has anyone seen "Bad system call" crashes in snap apps? I'm just beginning to debug one. [14:27] i want xenial for dragon...but with all the gpu goodies [14:28] qengho, grep for syscall in syslog ... then use "scmp_sys_resolver $syscall-id" [14:28] kgunn, right ... me too i guess :) [14:28] "sigaltstack" [14:28] what i meant to say above is ... nobody cares for 15.04 anymore ... only for potential security updates until 16.04 release ... then 15.04 will be gone anyway [14:29] qengho, that might be a seccomp filter denial [14:29] kgunn, i guess we need to drag some low level specialist in to tell us what we need seeded/added [14:30] (my knowledge here is rather limited and ends at: you need a driver with EGL support ... and perhaps MESA) [14:33] what's the package to install on ubuntu-core to have the snapcraft tool? [14:34] ysionneau, snapcraft :) [14:35] ubuntu@localhost:~$ sudo snap find snapcraft [14:35] error: no snaps found for "snapcraft" [14:36] (16.04) [14:36] ysionneau, ah, no, thats not possible [14:36] sudo snappy enable-classic [14:36] snappy shell classic [14:36] that gets you an apt capable environment [14:36] what are those command doing? [14:36] oh [14:37] (an lxc container that adds the apt bits to the system ... there you can do normal apt-get update and install commands) [14:37] awesome! [14:37] thanks [14:39] ogra_: i bet camako or similar could help us... [14:39] cool [14:39] camako: basically what would we need to seed from a dragonboard port to get our mir-server snap up and running [14:40] camako: in terms of pkgs [14:40] that need to be in the core image [14:40] well, even without pkgs :) [14:40] kgunn, ummm lemme context switch my brain [14:40] camako: lol...i know...vulkan...now snappy [14:40] sorry [14:40] :-) [14:42] kgunn, sorry what's the problem we are solving (quite a bit of scrollback to read) [14:42] camako, snappy on arm/arm64 is currently focused on headless [14:42] camako: right, so ogra_ was asking what exactly is needed to be added to the arm snappy image in order to get mir up [14:42] camako, we will surely have users that want to run graphical stuff on RPi2 and dragonboard [14:42] hmm zyga when using your ubuntu-image script to generate a 16.04 rpi2 image, if I try to do "sudo snappy enable-classic" , then I get write /tmp/classic193779427: no space left on device after some time [14:42] e.g. kms, drm, gbm, display driver/fb, gles, egl [14:43] camako: i think that's it ^ [14:43] I guess the disk image is not big enough to enable the "classic" mode [14:43] camako, for that i need to know what we need to include in the kernel (device) snap [14:44] i know there is an open driver for the rpi but have no clue if thats sufficient for mir yet ... and the same goes for the dragonboard, there is freedreno but i'm not sure thats enough [14:45] the new snap.yaml skill->interfaces change has landed [14:45] mvo, scary [14:45] mvo: cool, thanks for doing this [14:45] kgunn, ogra, dragonboard runs mesa (not android) right? [14:45] re-learning the world again :P [14:46] camako, snappy doesnt have any android container (yet) [14:46] ogra_: there's a wayland demo on raspberry pi foundation github account, perhaps mir could be there too [14:46] so normal linux drivers for now i guess [14:47] ogra, ok let me find out and will get back to you [14:47] camako: right atm [14:47] (i guess there is also the input side we need to cover somehow) [14:47] ogra_: libinput and usb drivers there... [14:48] camako, cool, thanks ... i know RAOF has looked into rpi a while ago, but we havent talked about it in months [14:48] kgunn, the other issue is if we actually want that in the core rootfs itself (not sure libinput is actually desired by default for example) [14:48] i guess that needs wider discussion [14:49] i know that sabdfl wants us to base the images on the cloud builds, the question is what we can/want to add on top without harming the IoT usecase [14:49] ogra_: ah yeah...true...might just be part of mir snap [14:50] (device specifics like drivers should indeed go into the kernel snap ... but the layer above where bits are semi-generic might not) [14:51] i'll send a mail before EOD so we can get a discussion running about that [15:05] mvo: fyi, we are in the meeting now [15:06] yay [15:07] ogra, kgunn, so I am told dragonboard uses freedreno drivers in mesa... and of course libinput for input... The mir-graphics-drivers-desktop in xenial pulls everything needed in. [15:07] mir-graphics-drivers-desktop package, that is [15:07] mvo: you should have an invite [15:07] so our kernel snap should inclide the freedreno driver then, ok [15:07] *include [15:07] thats a first step ... [15:08] for libinput and mesa itself i guess we need more discussion how/where they should be shipped [15:10] ogra_: why not make the dragon board image seeding the equivalent to what is amd64 core image today? [15:10] just thinking like a caveman [15:10] because the rootfs is completely generic [15:11] ogra_: i dunno what that means.... [15:11] it needs to run on all arm64 boards ... and it needs to still fully support the embedded, robotics and IoT usecases without shipping to much bloat [15:12] dont forget that snappy allows you to update the rootfs completely independently from the device bits, so all device specific stuff needs to be in kernel or gadget snap ... the rootfs can only ship pieces that are completely device independent (i.e. generic) [15:16] ths is why i think we need some wider discussion [15:16] (where/if to seed stuff in core etc) [15:24] ok, I thik I know what the next step is [15:27] kyrofa: https://github.com/ubuntu-core/snapcraft/pull/327 please. [15:27] elopio, I'll trade you for https://github.com/ubuntu-core/snapcraft/pull/357 [15:28] kyrofa: I'm looking at it already. Unfair trade, I demmand compensation. [15:28] elopio, :D [15:31] elopio, looks good-- is it ready to ship? Or are you still tweaking? [15:31] kyrofa: ready! [15:33] ogra_: wondering, would it be too much to have 3 images effectively... core-headless, core-headed, personal [15:33] altho core-headed and personal might start to approach each other... [15:33] ? [15:33] kgunn, thats a sabdfl question :) [15:33] as i said "wider discussion" :) [15:33] ;) === rcj` is now known as rcj [15:33] ricmm: ^ [15:34] i know you follow the mir-on-core discussion... [15:34] yeah, he probably even has concrete plans or knows more than us :) [15:35] * tedg got dropped because of "an error" [15:35] tedg, just fix it then :P [15:38] ogra_: so it seems our kernel is missing a few modules [15:38] ogra_: do you know who knows about pi2 kernel maintenance? [16:03] So dduffey, you need the agent and fboss_route.py, right? Anything else? [16:04] ogra_: Apparently logging in and out fixed it, but I got 2FA, so I think I was probably kicked by beuno :-) [16:04] mvo (beuno and zyga you may be interested in this): the way I see it is there is some sort of 'X' interface that snaps declare (fine-- we need that for the security perms any way) [16:05] kyrofa, config files [16:06] dduffey, alright, any other executables? [16:06] https://github.com/opennetworklinux/fboss-package/tree/master/etc/fboss [16:06] mvo (beuno, zyga): then either gnome software has a little indication that if the app declares it, it mentions that it needs expanded access to your session, or on first launch of the app we say it needs expanded access to the session [16:06] kyrofa, not that I am aware of [16:06] basically everything from the repo you have, plus this repo (minus the kernel modules and /dev entries) https://github.com/opennetworklinux/fboss-package [16:07] dduffey, okay so those json files aren't included in fboss? [16:07] dduffey, is that something you would want to ship yourself? [16:08] mvo (beuno, zyga): I don't like click-through security though, and that is all this is, but if we must allow all devs access to X in this manner, I think this is the best we can do. both sides have merit. what is intersting about the wrapper approach is that it sort of feels like a trust prompt [16:09] kyrofa, I would like then in the fboss snap so they are there already [16:09] yeah, they don't look to be in the fboss repo itself [16:10] dduffey, ah, I wasn't clear. I mean do you want to use exactly those (i.e. make a part pulling down that repo and copying those json files over), or would it be better to ship your own json file(s) specific to this snap? [16:10] dduffey, even if you manually copied them [16:11] dduffey, I suspect manually copying them and maintaining them as part of the recipe would be best, but it's up to you [16:11] kyrofa, I would just like to use the unmodified for now [16:11] there are some changes I need to make to the initscript to work [16:11] but those json's worked fine on ubuntu 14.04 for the purposes of the demo [16:11] mvo (and beuno): if first launch only-- it is easy to imagine a prompt that says something like "This application is requesting privileged access to your desktop session". Then say 'Allow', 'Temporarily allow', 'Deny' (or something). if 'allow'ed, then touch a file somewhere outside of the app's perms such that if that file exists on next run, the prompt is skipped [16:12] dduffey, do you envision ever needing to change them? [16:12] kyrofa, not over the next two week :) [16:13] mvo (beuno): this generalizes beyond 'X' which I think is good. since there will be no content-hub, in addition to X apps need to have access to (almost) all non-hidden directories in the user's home [16:13] dduffey, alright [16:13] ATM I just want to make it so if we install the snap we get to a working demo state, even if it is a fixed config [16:14] dduffey, so in order to fetch those configs (where they don't have a build system) you'll need to create a `make` part, with a Makefile to pull them down and copy them appropriately. Refer to the OpenNSL one [16:15] dduffey, whereas if you copied them in manually you could use the `copy` plugin to move them into the snap. Make sense? [16:16] kyrofa, got it [16:16] kyrofa, thanks for pointing to an example [16:17] dduffey, no problem. Particular pointer to the use of DESTDIR [16:17] (that'll be the root of the snap) [16:17] kyrofa, can you point to a "copy" example? [16:18] dduffey, https://github.com/ubuntu-core/snapcraft/blob/1.x/examples/shout/snapcraft.yaml [16:18] dduffey, you should checkout the entire examples/ dir when you're able [16:19] kyrofa, thanks [16:19] zyga, it is the archive kernel, maintained by the kernel team (mainly ppisati ) [16:20] zyga, file a bug against linux-raspi2 [16:26] jdstrand: I think implementing this is straightforward [16:27] kyrofa, snapcraft stops on failing to make install (i.e. no .snap) ... [16:27] dduffey, yup, exactly [16:27] dduffey, lack of install rules [16:28] ls [16:28] file not found [16:32] dduffey, so the cmake plugin is super simple. It calls cmake, make, and make install with a DESTDIR pointing into the snap [16:33] dduffey, that leaves it up to the codebase to determine what should go in the snap. Unfortunately, fboss doesn't specify anything [16:33] kyrofa, the only think I think I used/copied was "wedge_agent" although it looks like there may be a sim_agent binary as well [16:34] dduffey, indeed, there seems to be a few things in there [16:35] dduffey, and from the README, the process of making fboss_route.py actually workable is terrible [16:36] kyrofa, yeah, it looks like they are abusing cmake [16:36] but folling there directions it does build [16:36] and then I manually copied the agent over into place (on 14.04) [16:37] dduffey, so is it statically linked, then? [16:37] dduffey, you don't have to run it out of the source tree or anything? [16:38] kyrofa, I would have to go back and review ... I think I installed .debs, then I build it from source, and then I copied over the build agent to verify it would work ... so half/half [16:38] dduffey, blech :P [16:39] dduffey, it does seem to be a rather large executable, so it may very well be static [16:41] elopio, the credentials in the tarmac server are the scalingstack ones, for accessing the host we were using so far the canonistack ones (where the host is created), the key filename in my case looks like ues-snappy-integration-tests_lcy02.key [16:42] elopio, i'll upload them there too [16:46]