[00:00] <kyrofa> LefterisJP, any data directory is persistent across updates
[00:00] <kyrofa> LefterisJP, here's how updates occur on Snappy:
[00:00] <kyrofa> 1. Version A is installed and has data.
[00:00] <kyrofa> 2. Version B is downloaded
[00:01] <kyrofa> 3. Requested to install version B
[00:01] <kyrofa> 4. Copy version A data into version B space
[00:01] <kyrofa>  5. Install version B
[00:02] <kyrofa> LefterisJP, now if version B sucks, you can rollback to version A and its data is still there in the state it was when it was copied
[00:02] <kyrofa> LefterisJP, this applies to both $SNAP_APP_DATA_PATH and $SNAP_USER_DATA_PATH
[00:02] <LefterisJP> hmm so data are first copied? It was suggested to me to use $SNAP_APP_DATA_PATH for the framework to sync the blockchain. This is a database that will practically always grow.
[00:03] <kyrofa> LefterisJP, indeed. Yeah, that sounds like a good spot
[00:03] <kyrofa> LefterisJP, any database will always grow :)
[00:03] <LefterisJP> That's nice then, and do users get some form of cleanup management? So that they can delete old data lying around? Cause at least for sideloading I got lots of directories lying around. I can delete manually but that feels dirty :)
[00:04] <kyrofa> LefterisJP, right now there's `snappy purge`, but that will clear ALL data. We're working on making that a bit better
[00:04] <kyrofa> LefterisJP, `snappy purge <appname>` specifically
[00:06] <LefterisJP> I see. All right thanks that will do for now I guess. In the future having some granularity in the choice of versions to purge would be awesome.
[00:07] <kyrofa> LefterisJP, agreed
[00:56] <adsad> Why doesn't Snappy Ubuntu use apt-get given that apt-get is so friendly to use?
[00:58] <xnox> adsad, well, snappy uses a different model of atomic updates. it's kind of what rpm-ostree is to yum/rpm. But so much more as well, given frameworks, atomic updates, and snaps (aka apps)
[00:59] <xnox> instead of package-per-package update, it's an atomic whole image, a/b updates. or so i understand it.
[00:59] <adsad> What is the advantage of atomic updates? what is so good about it that the proven apt-get is abandoned?
[00:59] <xnox> adsad, the base things are still compiled with apt-get/deb based things. So e.g. all the source packages for ubuntu are still build with dpkg-src.
[00:59] <adsad> if update whole image instead of individual package, wouldn't it take long long time to update?
[01:00] <adsad> am i right to say the right place to use snappy is on IoT gateways?
[01:00] <xnox> adsad, it's actually faster =) because there is no maintainer scripts to run, nor individual packages to update. It's down to byte-wise delta. With apt, one has to download and unpack all the unchanged files. And thanks to reproducible builds, security update of a .deb is actually just a tiny delta =)
[01:01] <adsad> xnox: wow. good to know. impressive. Why not Ubuntu mainstream move to snappy atomic update instead? :)
[01:01] <xnox> adsad, currently snappy is targeted on IoT gateways, but there are plans to use same technology on e.g. ubuntu for phones, and eventually clients/desktops/servers but UX is still to sort out. Cause e.g. people currently used to e.g. removing apps.
[01:02] <xnox> adsad, and not everybody who is using e.g. ubuntu unity desktop experience, wants all the default apps that we provide.
[01:02] <adsad> what are some embedded system boards today that support snappy as iot gateway? I don't think it is suitable for use on desktop and servers, right?
[01:03] <xnox> adsad, eventually, one day, maybe we will have efficient, atomic, delta, snappy based updates for all for factors. But right now, we are looking at embedded space - cause that's kind of how it has always operated. (ie. "flash" firmware whole disk image)
[01:03] <xnox> adsad, there aren't enough frameworks/base-images generated to be a better experience on the desktop/server than the current apt-get offering, that's true.
[01:04] <xnox> adsad, i'm not sure of the current target boards, somebody from snappy team might be able to help you more. I think one can run it in an x86_64 qemu kvm VM to try things out.
[01:04] <adsad> why is snappy suitable for use as iot gateway? I believe mainstream Ubuntu can also work as IoT gateway as long as the gateway has enough RAM. Embedded systems are almost like mini  PCs today
[01:08] <xnox> adsad, because of snaps - there are things being packaged for snappy, to make it more open to the end user. Frequent updates, vendor supported, and customizable. E.g. one can add/remove snaps to configure "gateway" advance functionality. Or so I understand. E.g. a snap to get filesharing configured, securely, updated, supported. snap to get firewall. snap to get QoS. Etc. instead of sub-par experience with existing point-and-click firmware on gateways.
[01:08] <xnox> adsad, look at partners at http://www.ubuntu.com/internet-of-things
[01:08] <xnox> note, i'm just a community member, i don't develop snappy at all. just a user.
[01:09] <adsad> xnox: thanks. u sound highly knowledgeable anyway
[01:09] <adsad> sounds like the main reason for using snappy on Iot is security
[01:09] <xnox> adsad, a while back, i was like "what is this ubuntu core and snappy thing anyway" so did my research.
[01:10] <xnox> adsad, yeah, in a user friendly and actually open way =)
[01:10] <adsad> xnox: yes, that's important with high security stuff. normally, security means developer-unfriendly
[01:11] <adsad> xnox: if u have tried Intel WIndRiver, u will understand what developer-unfriendly means
[01:11] <xnox> true. snappy is all around friendly: manufacturers/partners, developers/deployers, end-users, end-developer (consumer developers)
[01:12] <xnox> adsad, i cannot comment on Intel Windriver at all =) as I used to work for Intel, albeit not at all on windriver products.
[01:12] <adsad> xnox: snappy is lacking with embedded system security compared to other industrial gateways
[01:13] <xnox> not sure, didn't study that deep. On the surface it did appear to utalise priviledge separation a lot, and apparmor.
[01:13] <adsad> xnox: oops.. not to say Intel products are bad. Only WindRiver gave me a terrible experience. Anyway, Intel supports Snappy too. It is a great vote of confidence
[01:13] <xnox> but i'm not a security expert.
[01:15] <adsad> xnox: embedded system security is a hardware thing. There's no way snappy can deal with that because snappy is a software
[01:16] <adsad> xnox: when someone tempers with the hardware, the system can detect that with good embedded system security. I really don't think it is worth paying for this feature anyway
[01:16] <xnox> snappy is software, ubuntu core is a product. And given the list of hardware partners on the website, it's not unreasonable to expect for hardware to be integrated eventually.
[01:16] <xnox> that's the point of hardware partners, no?
[01:17] <adsad> xnox: yes.
[01:18] <adsad> xnox: i'm  a hobbyist. So far, the only hardware for snappy for hobbyist is raspberry pi. poor man's development board
[01:18] <adsad> Some hardware partners charge an arm and a leg. Like WindRiver.
[08:29] <zyga> good morning
[09:18] <JamesTait> Good morning all!  Happy Tuesday, and happy Popcorn Day! 😃
[09:20] <LefterisJP> When doing `sudo snappy-debug.security scanlog` is there anyway to clear the logs? Asking because right now they are kind of spammed by previous denials I have fixed and I would like to make them go away.
[09:39] <mvo> ogra_: hi, is your gadget snap for arm64 available in bzr?
[09:57] <mvo> ogra_: nevermind, I used your dragonboard_0.1_all.snap now and put that into the lp:~snappy-dev/snappy-hub/snappy-systems  tree
[09:58] <mvo> ogra_: btw, I wonder if we should make partition label a property of the gadget snap maybe?
[10:06] <LefterisJP> Hey guys is there any way to regenerate apparmor policies for snapps that use a framework's policy if I change said framework's policy group apparmor profile in place? I want to find faster ways to debug/test things in the framework I am developing.
[10:09] <LefterisJP> I tried sudo snappy-debug.security regenerate SNAPPNAME but that did not do it. (I have edited the framework's policygroup in place, and the snapp uses it so that may introduce extra complexity)
[10:15] <mvo> ogra_: also if you could check https://github.com/ubuntu-core/snappy/pull/337 if that is actually true…
[10:17] <fgimenez> hi mvo :), quick question about https://trello.com/c/tfC2TNsE/291-all-snaps-check-that-boot-grub-does-not-contain-a-kernel-initrd
[10:18] <fgimenez> mvo, do we need to check only /boot/grub or also /boot/grub/a-b for the absence of the initrd.img and vmlinuz files?
[10:19] <mvo_> ogra_: I have created an all-snap dragonboard image, do you have the HW to test it?
[10:20] <mvo_> fgimenez: maybe we can just do a "find /boot/grub -name "vmlinuz" to get it all?
[10:21] <fgimenez> mvo_, ok thx, i hope to have it finished soon
[10:23] <mvo_> fgimenez: \o/
[10:28] <mvo_> ogra_: anyway, please ping me once you are around so that we can talkabout the image
[11:00]  * zyga pused https://github.com/ubuntu-core/snappy/pull/338
[11:43]  * zyga pushed https://github.com/ubuntu-core/snappy/pull/340
[12:28] <pindonga> hi elopio , sorry to be such a nuisance... just wanted to set expectations for this week... do you think it's possible the snappy tests in travis can be run in xenial this week?
[12:40] <kyrofa> Good morning
[13:23] <kyrofa> LefterisJP, if you're still around, the snappy-debug logs come from syslog-- truncate that and you'll be good to go
[13:24] <kyrofa> jdstrand, ping
[13:46] <liuxg> Chipaca, ping
[13:47] <liuxg> what could be the error "required description field not specified snappy-systemd_package_yaml_description_present (piglow)" after I uploaded my snap to the ubuntu core store. I have description field in the snapcraft.yaml file there.
[13:49] <liuxg> kyrofa, ping
[13:50] <kyrofa> liuxg, pastebin your snapcraft.yaml
[13:50] <kyrofa> liuxg, and hi :)
[13:51] <liuxg> kyrofa, this is the snapcraft.yaml http://paste.ubuntu.com/14575220/, and the error is like http://paste.ubuntu.com/14575221/
[13:51] <kyrofa> liuxg, your service requires a description
[13:52] <liuxg> kyrofa, oh, really? I did not notice that. In fact, the snapcraft never complains it when building it.
[13:52] <kyrofa> liuxg, yeah it's just required by the review tools
[13:52] <liuxg> kyrofa, may I think this is a bug for the tool?
[13:52] <kyrofa> liuxg, later versions of snapcraft specify one for you
[13:52] <kyrofa> liuxg, not really-- if you install the review tools locally snapcraft will run them for you
[13:53] <kyrofa> liuxg, but snapcraft isn't really meant to be a review tool
[13:53] <kyrofa> liuxg, make sense?
[13:53] <liuxg> kyrofa, ok. thank you for your help. I will correct it :) by the way, would you please help to review my training slides. thanks a lot for your help.
[13:53] <liuxg> kyrofa, how to use the review tool for snap?
[13:54] <liuxg> kyrofa, I really need it to check it before I upload my snaps to the store.
[13:55] <liuxg> kyrofa, yes, it makes sense, of course :)
[13:56] <kyrofa> liuxg, ah, I forgot, I'm so sorry! Thank you for the reminder-- looking now
[13:57] <liuxg> kyrofa, it is alright. I think you are pretty busy.　Just do it when you are free. Again, thanks for your help!
[13:59] <kyrofa> liuxg, regarding the review tools, I'm not certain. I think it's click-review
[14:00] <kyrofa> liuxg, click-reviewers-tools
[14:01] <kyrofa> liuxg, then run click-review <my snap>
[14:01] <liuxg> kyrofa, ok. thanks a lot. I will take it down, and blog it for the developers :)
[14:29] <elopio> pindonga: let me re-run to see what's the status today.
[14:35] <sergiusens> kyrofa, elopio are you standing up?
[14:36] <kyrofa> sergiusens, yeah, wanna join?
[14:36] <sergiusens> I'll try
[14:36] <elopio> sergiusens: nah, just talking about you.
[14:47] <bladibla> how to get started with snappy
[14:51] <elopio> fgimenez: I'd like to attend pitti's proposed migration call. If you have something to discuss, can we do it here?
[14:52] <liuxg> I just published my snappy apps to the store, then I started to install it. However, it showed me the error like "webcam failed to install: snappy package not found"
[14:53] <sergiusens> elopio, I forgot to ask, do the adt tests work fine for master?
[14:54] <elopio> sergiusens: do you mean integration tests in snappy master? Last time I looked they did.
[14:54] <elopio> I'm about to check again.
[14:56] <fgimenez> elopio, sure np
[14:56] <sergiusens> elopio, snapcraft I mean
[14:56] <sergiusens> elopio, as in atd run snapcraft (or however it was run)
[14:57] <elopio> sergiusens: ah, I know what you mean. I don't know, let me check.
[14:58] <elopio> sergiusens: it fails with snapcraft/tests/test_plugin_catkin.py:334:20: E713 test for membership should be 'not in'
[14:58] <elopio> which means it's taking an old version.
[15:00] <kyrofa> liuxg, slides reviewed. Good presentation!
[15:00] <kyrofa> liuxg, I made a number of comments
[15:01] <liuxg> kyrofa, thanks for your help on this.
[15:02] <kyrofa> liuxg, of course, I'm sorry for taking so long
[15:02] <liuxg> kyrofa, it is so kind of you to help me!
[15:03] <pitti> elopio: FTR, still waiting for my co-sprinters to join
[15:04] <elopio> pitti: are you in an IRC channel?
[15:05] <pitti> elopio: #u-devel and #ubuntu-vsprint
[15:05] <pitti> elopio: or the hangout :)
[15:06] <elopio> pitti: ok, let's wait for them :)
[15:13] <sergiusens> elopio, how does it use an old version?
[15:13] <sergiusens> elopio, or are you looking at update excuses?
[15:18] <elopio> sergiusens: yes, looking here: http://autopkgtest.ubuntu.com/packages/s/snapcraft/xenial/amd64/
[15:18] <sergiusens> elopio, yeah, that's the 1.x branch that wasn't supposed to go to xenial :-P
[15:20] <liuxg> Chipaca, ping
[15:20] <liuxg> elopio, ping
[15:21] <elopio> liuxg: pong.
[15:22] <liuxg> elopio, I have just published 3 snaps into the snappy ubuntu core store. They were successfully published. However, when I tried to install it from my raspberry pi device, it showed me sth like http://paste.ubuntu.com/14575641/. what could be the problem for it?
[15:23] <elopio> liuxg: rolling?
[15:23] <liuxg> elopio, what do you mean?
[15:24] <elopio> liuxg: are you using the rolling release?
[15:24] <liuxg> elopio, do you mean that I need to select "rolling" when publishing?
[15:24] <liuxg> elopio, I am not so sure. How can I check it? I can install the "hello-world" snap without any problems.
[15:24] <elopio> liuxg: I'm just asking if you are in rolling, because things are really different between the two releases.
[15:25] <elopio> liuxg: snappy info
[15:25] <liuxg> elopio, sorry, I do not know much about it. would you please explain it?
[15:26] <liuxg> elopio, http://paste.ubuntu.com/14575656/
[15:27] <liuxg> elopio, I have just published　an app like "piglow-snappy", it is visible in the store, but I cannot install it.
[15:27] <elopio> liuxg: it says that you are using the 15.04 release, stable channel. I haven't tried uploading snaps recently, you can talk to the store team to see if there's something happening in there.
[15:28] <liuxg> elopio, who is the person there in the store team?
[15:29] <elopio> liuxg: join #u1-internal in the canonical IRC.
[15:29] <liuxg> elopio, when I publish the snap, I select "15.04-core". is this right?
[15:30] <beuno> elopio, as you know, we've switched to all snaps
[15:30] <beuno> which are squashfs based
[15:30] <beuno> so you can't use the same snap for both 15.04 *and* rolling/16.04
[15:30] <beuno> you have to use an up to date snapcraft
[15:30] <beuno> and target one or the other
[15:32] <elopio> actually, snapcraft 1.0 for 15.04, and snapcraft 2.0 for rolling.
[15:32] <zyga> jdstrand: quick question, for bool-file, do we need any extra syscalls (seccomp)?
[15:33] <elopio> liuxg: if you are using 2.0 and trying to upload for 15.04, that's likely your problem.
[15:33] <liuxg> beuno, I did not use snapcraft 2.0 in fact.
[15:34] <liuxg> elopio, beuno, i have checked that the snapcraft version is still 1.0.
[15:35] <liuxg> elopio, beuno I can see the snappy app in the store, however, I cannot install it. the app link is https://myapps.developer.ubuntu.com/dev/click-apps/4332/rev/1/
[15:35] <beuno> liuxg, I understand
[15:36] <beuno> as I said, snapcraft built a snap that isn't compatible with rolling
[15:36] <beuno> you need a newer snapcraft
[15:36] <liuxg> beuno, so, do you mean I need to use snapcraft 2.0 for it?
[15:36] <liuxg> beuno, my current snappy system is http://paste.ubuntu.com/14575656/
[15:37] <beuno> liuxg, yes
[15:37] <liuxg> beuno, I can install it using sideload, and it works well for me.
[15:37] <beuno> oh, you're on 15.04
[15:37] <liuxg> beuno, yes, I am on 15.04
[15:37] <beuno> oh, so ignore everything I said
[15:38] <liuxg> beuno, I just want to know what could be problem for it. the apps were successfully published. but they cannot be installed from the store.
[15:38] <jdstrand> zyga: iirc, bool-file is simply a rw rule, so no
[15:38] <matiasb> liuxg, beuno, I guess you need to install piglow-snappy.xiaoguo (you need to use the full name, afaict)
[15:38] <jdstrand> (the default seccomp policy allows you to open/read/write/close files
[15:38] <jdstrand> )
[15:40] <liuxg> matiasb, then I come to another problem http://paste.ubuntu.com/14575725/. it happens the same when I try to install from the store.
[15:41] <matiasb> beuno, fyi, ^ that's because we are not enabling anonymous download there
[15:41] <liuxg> matiasb, it is very strange that for some of the snaps, I do not need to have the domain name. for example, for the case of hello-world http://paste.ubuntu.com/14575730/
[15:41] <beuno> matiasb, but I thought 15.04 still targets the framework?
[15:43] <zyga> jdstrand: right, thanks for confirming this
[15:43] <matiasb> beuno, hmm... in this case, the release is 15.04-core, but no framework was set; we have the auto-enable anonymous for -core frameworks, though
[15:44] <liuxg> beuno, would you please help me on it? I do not know how to get it working. this is another app I published. is there any problem for it? https://myapps.developer.ubuntu.com/dev/click-apps/4342/
[15:44] <fgimenez> elopio, there's a bunch of PRs for you to review https://github.com/ubuntu-core/snappy-jenkins/pulls
[15:44] <beuno> matiasb, ack. Can you enable that for him?
[15:44] <matiasb> beuno, I can, give me a sec
[15:44] <elopio> fgimenez: ok, added to the queue. Will look soon.
[15:45] <matiasb> beuno, done; liuxg, can you try now? (with piglow-snappy.xiaoguo)
[15:46] <fgimenez> elopio, thx, with all of them applied i've redeployed successfully, pls take a look to check if the snapcraft part is in place http://10.55.32.158:8080/, and if you have the time try to redeploy too
[15:46] <liuxg> matiasb, beuno, thanks. However, I still face the same issue http://paste.ubuntu.com/14575769/
[15:47] <elopio> fgimenez: \o/ I'll trigger a test run to see if I missed something.
[15:47] <liuxg> matiasb, beuno, I do need some access for uploading snaps?
[15:48] <fgimenez> elopio, ok, i've added to travis tests for checking the images build and basic connection between them, when you are a owner we need to enable travis on ubuntu-core/snappy-jenkins
[15:48] <liuxg> matiasb, I just rebooted my raspberry pi device, and did it again. it is the same problem here..
[15:50] <matiasb> liuxg, give it a min until update is propagated, it should work if you try in a couple minutes
[15:51] <liuxg> matiasb, may I know what change you made just now? it is good to know it.
[15:52] <liuxg> matiasb, do　I need to let you do some configuration whenever I need to publish an app? will this happen to the rest of the developers? thanks
[15:53] <matiasb> liuxg, this is an internal detail which we should be working around (on our side) soon, related to authentication and downloads from snappy devices; it should be transparent for devs
[15:54] <liuxg> matiasb, so, your team will work this out, right? from developers' point of view, we do not need to do anything?
[15:56] <matiasb> liuxg, from the developer point of view, no, nothing extra will be required
[15:57] <elopio> pindonga: we are closer again: https://travis-ci.org/ubuntu-core/snapcraft/jobs/103364898
[15:57] <liuxg> matiasb, so, for now, it is a bug, right? I just re-tried, it did not work yet. how long should I wait?
[15:58] <matiasb> liuxg, hmm... it should be working now... what are you trying? still 401?
[16:00] <liuxg> matiasb, still the same http://paste.ubuntu.com/14575845/
[16:00] <matiasb> liuxg, but that's another package!
[16:01] <matiasb> :)
[16:01] <liuxg> matiasb, yes, I have 3 apps: grovepi-server, Webcam, piglow-snappy
[16:01] <liuxg> matiasb, so, you need to configure for each of the apps?
[16:02] <matiasb> liuxg, I fixed the status for the piglow-snappy one, I should check the others if needed
[16:03] <liuxg> matiasb, my snappy is being updated "another snappy is running, try again later" :) I need to wait for a while. the other ones are https://myapps.developer.ubuntu.com/dev/click-apps/4341/ https://myapps.developer.ubuntu.com/dev/click-apps/4332/
[16:04] <matiasb> ack, will take a look in a bit
[16:05] <elopio> beuno: mvo mentioned that the store doesn't allow us to name the os snap ubuntu-core for amd64 and armhf, but that's the plan.
[16:05] <elopio> is that happening soon, like this week? The workaround in the tests is not just a couple of lines, so I would like to know if it's worth it.
[16:07] <matiasb> elopio, working on that, trying to get there asap; hopefully before end of next week
[16:07] <liuxg> matiasb, yes, the piglow-snappy works now.
[16:07] <matiasb> liuxg, great
[16:08] <liuxg> matiasb, so, next time when I publish a new one, I still need to look for you to help?
[16:08] <elopio> matiasb: ok, so I will work around. Do you have a bug I can subscribe to?
[16:08] <bellyfeel> Is there a way to add two factor auth to snappy? I see that the files in pam.d are read only...
[16:09] <matiasb> liuxg, maybe, hopefully not, the update to handle this is in progress, afaict
[16:10] <matiasb> elopio, hmm... I think there isn't, but I have a trello card with a hard deadline for Feb 1s
[16:10] <liuxg> matiasb, that sounds good. By the way, when I install the "hello-world", I do not need to have "canonical" there. I just need to sudo snappy install hello-world. But for may case, I need always to have ".xiaoguo"
[16:12] <liuxg> matiasb, for the other two apps, are they ready to check? thanks
[16:14] <matiasb> liuxg, right, there are short names available for some packages (frameworks and canonical pkgs)
[16:14] <matiasb> liuxg, give me a few, I'll let you know when ready
[16:15] <liuxg> matiasb, ok. thanks! I just want to make sure they are in good shape. By the way, if I upgrade them to new versions, do I need to bug you again?
[16:16] <matiasb> liuxg, no, updates should work without any issues
[16:16] <liuxg> matiasb, ok. thanks. it is good to know :)
[16:17] <matiasb> liuxg, ... and updated; try again in a few mins, and the other packages should get installed too
[16:18] <liuxg> matiasb, one more thing, when I publish a snap, if the link is https://vimeo.com/152249451, it is now allowed. However, if the link is http://vimeo.com/152249451. it works fine. is this a bug?
[16:19] <liuxg> matiasb, sorry, the one with "s" is not allowed :)
[16:21] <matiasb> liuxg, sounds like it could be (although the help text example is http), feel free to file a bug for it, if it isn't already there, and it will be eventually triaged
[16:21] <liuxg> matiasb, could you please give me the project name for it?
[16:23] <matiasb> liuxg, software-center-agent
[16:23] <liuxg> matiasb, thanks!
[16:24] <matiasb> np
[16:26] <rickspencer3> jdstrand, can I write a service that shells out "echo 14 > /sys/class/gpio/export", etc...?
[16:27] <rickspencer3> so far, it seems like my service can't really see into /sys/class, but I am not getting back clear error messages from my Go code
[16:31] <liuxg> matiasb, I have filed a bug at https://bugs.launchpad.net/software-center-agent/+bug/1535808
[16:31] <jdstrand> rickspencer3: the /sys/class/gpio/export file can be used with hw-assign
[16:31] <rickspencer3> jdstrand, hmmm
[16:32] <rickspencer3> jdstrand, let me try some more, but I have not made it work
[16:32] <jdstrand> you should be able to hw-assign anything in /sys/class/gpio/
[16:32] <liuxg> matiasb, thanks. the other two apps are fine now. have a nice day!
[16:32] <rickspencer3> also, I noticed that when I am on the cli, just "sudo echo 15 > /sys/class/gpio/export" does not work
[16:32] <rickspencer3> for some reason I have to to do $sudo su
[16:32] <rickspencer3> and then I can do it from #
[16:33] <jdstrand> rickspencer3: try: sudo sh -c 'echo 15 > /sys/class/gpio/export'
[16:33] <rickspencer3> I was wondering if that could be related
[16:33] <jdstrand> rickspencer3: the '>' redirection write is happening under your uid, not root
[16:34] <rickspencer3> interesting
[16:34] <matiasb> liuxg, great! ack, thx for the bug report
[16:34]  * jdstrand needs to step into a meeting but will keep an eye on backscroll
[16:35] <liuxg> matiasb, have a good day. thanks a lot for your help!
[18:26] <rickspencer3> jdstrand, any reason I shouldn't be able to use Go's library for reading files to read /sys/class/gpio/gpio14/value ?
[18:26] <jdstrand> rickspencer3: not otoh if the security perms are granted... maybe mwhudson might have an idea?
[18:27]  * rickspencer3 futzes a bit
[18:49] <rickspencer3> jdstrand, so, when I try to read from the file, I get this?
[18:49] <rickspencer3> Jan 19 18:48:33 localhost kernel: [ 7624.772671] audit: type=1400 audit(1453229313.026:73): apparmor="DENIED" operation="open" profile="rest-button.sideload_rest-cam_IKXIKPPCYFMQ" name="/sys/devices/platform/soc/3f200000.gpio/gpio/gpio14/value" pid=3006 comm="rest-button" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
[18:51] <jdstrand> rickspencer3: ah, you might have tried to read a symlink down in there
[18:51] <rickspencer3> comes from this line of code, I guess
[18:51] <rickspencer3>  /sys/devices/platform/soc/3f200000.gpio/gpio/gpio14/value
[18:51] <rickspencer3> oops
[18:51] <jdstrand> rickspencer3: you can use hw-assign for that
[18:51] <rickspencer3> ioutil.ReadFile("/sys/class/gpio/gpio14/value")
[18:52] <rickspencer3> jdstrand, yeah, I did that
[18:52] <rickspencer3> but, it seems quite idiosyncratic
[18:52] <jdstrand> you did hw-assign for /sys/devices/... too?
[18:52] <rickspencer3> jdstrand, no
[18:52] <rickspencer3> I did not know that would work
[18:52] <jdstrand> right, you need both (or more)
[18:52] <rickspencer3> so, I can hw-assign rest-button /sys/devices/* ?
[18:52] <jdstrand> this is what capabilities will fix
[18:53] <jdstrand> rickspencer3: sure. you can do multiple hw-assign(ments)
[18:53] <rickspencer3> I did hw-assign to the specific file, and that made my code work
[18:53] <rickspencer3> sure, I just didn't know at what level that was requireed
[18:53] <jdstrand> rickspencer3: it seems that the first rule created a situation where you needed a second rule
[18:54] <jdstrand> iiuc, when you gpio export something, new files are created in /sys
[18:55] <jdstrand> rickspencer3: use these with hw-assign: /sys/class/gpio/** and /sys/devices/**/gpio/**
[18:55] <rickspencer3> ok
[18:55] <jdstrand> eg, sudo snappy hw-assign foo /sys/class/gpio/**
[18:55] <rickspencer3> I'll try that next
[18:55] <jdstrand> sudo snappy hw-assign foo /sys/devices/**/gpio/**
[20:11] <mwhudson> jdstrand, rickspencer3: no idea
[20:11] <rickspencer3> fair enough :)
[20:12] <rickspencer3> it seems to be working, actually
[20:12] <rickspencer3> now I am just figuring out how to caste the []byte in the right way
[20:18] <jdstrand> mwhudson: it turned out to be a permission issue
[20:19] <mwhudson> jdstrand: nothing like it being the obvious answer
[20:40] <kyrofa> dholbach, what is this app developer manual you speak of?
[20:40] <dholbach> kyrofa: the "Snappy Ubuntu Core - Application Developer Manual 15.04" doc
[21:13] <dholbach> kyrofa: both PRs updated
[21:14] <dholbach> all of this should probably be in HACKING.md
[21:14] <dholbach> ... or the tools more forgiving
[21:15] <dholbach> and maybe  to make things even more enjoyable we should use bzr on LP, but that's probably just my very own pipe dream
[21:16] <kyrofa> dholbach, when you make a PR, you should see a "read the contribution guidelines" link, no? It links to https://github.com/ubuntu-core/snapcraft/blob/master/CONTRIBUTING.md. See step 3 :)
[21:16] <dholbach> ah sorry - I was just looking at HACKING.md
[21:17] <dholbach> thanks
[21:19] <kyrofa> dholbach, yeah, HACKING will tell you how to actually develop changes, run tests, etc. CONTRIBUTING is how to get changes back IN
[21:19] <dholbach> ok cool
[21:59] <dholbach> kyrofa: I'm not sure what still needs to be done for https://github.com/ubuntu-core/snapcraft/pull/241
[22:01] <kyrofa> dholbach, "Snapcraft can be extended by adding plugins new part plugins" needs to be reworded, and a blank line needs to follow the class definition
[22:01] <dholbach> oops yes, I just saw it
[22:01] <dholbach> sorry
[22:01] <kyrofa> dholbach, no problem :)
[22:01] <dholbach> that's what you get when you try to edit documentation when jetlagged :)
[22:02] <kyrofa> dholbach, what is the time difference for you? And are you already in california?
[22:02] <dholbach> yes
[22:02] <dholbach> 9h
[22:02] <kyrofa> dholbach, blech, you have my pity
[22:04] <dholbach> luckily I came here a few days ago already and visited (and stayed with) the family of my girlfriend's sister, so I'm doing much better already :)
[22:04] <kyrofa> dholbach, oh fun!
[22:04] <kyrofa> dholbach, coffee drinker?
[22:05] <dholbach> I was off of caffeine for quite a while, but that wasn't sustainable here ;-)
[22:08] <kyrofa> dholbach, hahaha
[22:10] <kyrofa> dholbach, I see you updated it. But the extra line I believe elopio is referring to needs to be between the `class` and `def build()` for pep8. Right elopio ?
[22:10] <dholbach> I ran pep8 over that bit
[22:10] <dholbach> but maybe I was doing something wrong
[22:11] <kyrofa> dholbach, you may be fine-- let's just get elopio's OK
[22:11] <dholbach> sure sure
[22:11] <kyrofa> dholbach, he's the python guy
[22:11] <kyrofa> dholbach, I'm definitely not. But I'm trying!
[22:12] <dholbach> kyrofa: how was the ride so far? :-)
[22:13] <kyrofa> dholbach, python? I have mixed feelings about it :P
[22:13] <dholbach> sounds like my feelings about using git :-P
[22:13] <kyrofa> dholbach, :D
[22:16] <kyrofa> dholbach, the include path methodology is nonsense. I still don't understand it
[22:16] <dholbach> I'm sure there's a PEP for that :)
[22:17] <kyrofa> dholbach, also I'll never get used to a whitespace-scoped language. It hurts me a little inside
[22:17] <jerryG> Chipaca: are u there
[22:18] <jerryG> kgunn: are u online?
[22:18] <dholbach> kyrofa: for some reason it was easy enough for me to just accept that - I can't even remember the times before :)
[22:18] <kyrofa> dholbach, yeah I have to tilt my head sideways
[22:18] <jerryG> mterry: can u answer a quick question about xmir?
[22:19] <dholbach> kyrofa: it sounds like a conversation we should have in a hotel bar after hours at some stage :-P
[22:19] <kyrofa> dholbach, sounds like a plan ;)
[22:19] <dholbach> awesome :)
[22:22] <kgunn> jerryG: i happen to be yes
[22:39] <jerryG> kgunn: is any1 at canonical using SDL on snappy?
[22:40] <kgunn> jerryG: not that i'm aware of
[22:40] <kgunn> jerryG: but there's no reason you couldn't
[22:40] <kgunn> snappy is just different way to package
[22:42] <jerryG> kgunn: it should be alright if i just include the .so files for SDL right?
[22:42] <kgunn> yes
[22:44] <jerryG> kgunn: k thx
[23:54] <kyrofa> elopio, you still around?