[04:09] sergiusens: I didn't look for a way to remove the leftover messages. I just filed a bug for zyga: https://bugs.launchpad.net/plainbox/+bug/1484596 [04:09] Launchpad bug 1484596 in PlainBox (Toolkit) "tests print a lot of warnings when they leave files on the working directory" [Undecided,Triaged] === chihchun_afk is now known as chihchun [04:20] elopio: bummer, it is so annoying :) [04:23] elopio: here's another one https://code.launchpad.net/~sergiusens/snapcraft/testing-fixes/+merge/269146 [04:23] 3rd and last [04:23] * sergiusens goes for some zzzzz === shuduo_afk is now known as shuduo [07:28] mvo: hey [07:28] mvo: around? === guest42315 is now known as o === o is now known as Guest39201 [07:33] hey zyga, good morning [07:34] mvo: hey, I'm trying to understand how a part of snapcraft you wrote works [07:34] mvo: I'm thinking of the python3-project plugin [07:35] mvo: specifically it seems to be a bit broken IMHO, but perhaps I'm missing something [07:35] zyga: ok, what part is unclear? or everything :) ? [07:35] mvo: could you please show me how to use two python3-project parts where A depends on B? [07:35] mvo: how it's supposed to work, I already read the code and patched a few things [07:36] mvo: but before I patch more, I want to see if I'm doing something sane [07:36] mvo: I was trying to structure the plugin after virtualenv, so that each subseqeuent part, after it's staged, can be imported by the rest of the snapcraft assembly process [07:36] mvo: (I wasn't thinking of using virtualenv, just to follow the same principle) [07:37] mvo: also, from what I see, setuptools depenencies are not followed at all, so the developer has to put everything together manually, right? [07:38] zyga: yeah, so dependencies are not resolved (yet) thats something that must be done manually right now [07:38] right, thanks for confirming that [07:39] zyga: we haven't used it in the scenario you describe, it may well be broken for that, how do you patches look right now? and in what way does it break exactly? code crashes or files not copied ? [07:39] mvo: ok, thanks, so currently it just crashes trying to run the setup of the 2nd part as it cannot import the 1st part [07:39] mvo: what I'm doing now, is to change how setup is invoked [07:40] mvo: I'm using --root relative to installdir and a fixed prefix [07:40] mvo: and I'll be probably using a different layout, but I need to see how to control the environment first [07:40] mvo: I found plugin.env() but it's not being called, I saw it's something related to handler.code but I've yet to connect the dots [07:41] mvo: I want to write an env function there that uses PYTHON* viariables to set everything up [07:41] zyga: aha, I see. there is a env() method that is available to add e.g. PYTHONPATH, there is also the after= directive to ensure on part is build before another [07:41] mvo: it also may be a factor that I'm working from a virtualenv in the first place (snapcraft itself is in a virtualenv) [07:41] mvo: and I want to make sure it's working regardless of that fact [07:42] mvo: I added env() but it's not getting called yet [07:42] as in ... [07:42] zyga: right [07:43] ttp://paste.ubuntu.com/12197674/ [07:43] mvo: I'll dig through this and improve it anyway I can [07:44] mvo: I need the plugin to work with roughly anything I can throw at it for an active project we're doing in cert so I'll probably ask you for a few reviews as I go [07:45] zyga: sure, thanks. sergio will also be around later to help with that, once I finish my current snappy branch I can take a deeper look to see why env() is not doing what you expect [07:45] mvo: thanks [07:46] ah [07:46] small fix is to use /usr/bin/python3 instead of python3 [07:46] that addresses the virtualenv factor [07:47] mvo: are you using virtualenv for development? [07:52] zyga: I don't use virtualenv [07:58] mvo: how do you develop snapcraft then? [07:59] zyga: in my normal wily env [07:59] mvo: just running it straight from the tree? [07:59] mvo: ok, thanks for the tip [07:59] mvo: is python 3.5 default there? [07:59] mvo: I'm on vivid [08:04] zyga: its available but not default (yet) [08:04] zyga: not sure what the plans of the distro team are, I assume they want to make it default but its a rc at this point aiui [08:13] mvo, i see you closed bug 1479711 ... do we consider bugs "fix released" if the fix is only in wily ? [08:13] bug 1479711 in initramfs-tools-ubuntu-core (Ubuntu) "snappy should not mount with "discard" option" [Undecided,Fix released] https://launchpad.net/bugs/1479711 [08:13] (just a general question) [08:13] ogra_: o/ [08:14] hey zyga [08:14] ogra_: I would say yes unless there is a 15.04 task, feel free to add one though [08:15] k, thanks [08:15] ogra_: I wonder if we should maybe do a 15.10 "release" and move current trunk to 15.04, nothing radical in there AFAICS and mostly useful and stable for 15.04 people. but this of course needs wider discussion [08:16] well, would that work ? given the potential differences in both releases (newer go version, gcc5 etc) [08:17] if that doesnt get in our way, yeah sure [08:17] ogra_: that we need to explore, but it might be good enough to just build trunk on 15.04 and some specific packages (like the initramfs improvements) [08:18] ha [08:18] small bug in logging in snapcraft :) [08:19] yeah, it definitely makes sense for stabilizing the stable image [08:19] to keep the focus there ... [08:19] (and it will make everyone more cautious sbout landing his changes as a nice sideefect :) ) [08:19] and perhaps some more in various places, logging is broken wrt all arguments [08:20] yeah, thats my goal, optimize our time and spend less time porting, either via developing for 15.04 and merging from that into trunk or by moving trunk closer to 15.04 [08:20] * zyga starts proposing fixes [08:27] https://code.launchpad.net/~zyga/snapcraft/fix-logging-setup/+merge/269163 [08:28] mvo: who's the lead reviewer for snapcraft? [08:28] zyga: sergio right now, but let me have a look, I can cover TZ wise [08:29] mvo: cool, you can expect a lot of patches from me soon :) [08:29] zyga: cool :) [08:29] mvo: btw, do you want to use git with snapcraft (I am) [08:29] mvo: it's pretty cool :) [08:29] helps sorting through patches a lot [08:30] is the tarmac problem solved? that was the only thing holding us back [08:30] mvo: bzr on the server [08:30] mvo: git locally [08:30] mvo: I'm using git-lp that I wrote (and I'm using all the time for the past three years) [08:33] zyga: nice, where can I find it? [08:34] mvo: https://github.com/zyga/git-lp [08:34] https://github.com/zyga/git-lp/wiki [08:35] mvo: if you have any issues just ping me [08:35] * mvo looks [08:35] mvo: it's just a single file, drop it in $PATH somewhere [08:35] mvo: apply the damn patch to bzr and you're all set [08:36] (instructions on the wiki might be a bit stale, I wrote them at around 12.04 time frame) [08:36] uh, I vaguely remember the patch [08:36] :D [08:49] mvo: how often does snapcraft merge processor (tarmac?) runs? [08:49] zyga: should be every 10min, but I think there was a commit message missing, I set one now [08:51] mvo: ah, sorry, I'm used to autogenerated commit messages [08:51] thanks [08:51] no worries [08:51] and yes, that is (much) nicer [08:53] ok, the other half of the change is now pushed [08:53] mvo: https://code.launchpad.net/~zyga/snapcraft/fix-logging-calls/+merge/269167 [08:58] meh, its still updating the diff [08:58] * mvo waits (im)patiently [08:58] mvo: yeah, is is oddly slow [08:59] mvo: I have another branch to sweeten the wait [08:59] * zyga cannot wait till he gets to the part of improving plainbox-based tests [09:00] mvo: https://code.launchpad.net/~zyga/snapcraft/fix-process-leak/+merge/269172 [09:00] it's pretty odd because all the delta shows up fine http://bazaar.launchpad.net/~zyga/snapcraft/fix-logging-calls/revision/136 [09:01] and the one on the 2nd branch is already generated [09:06] mvo: both branches are reviewable now [09:06] zyga: and are reviewed :P [09:06] oh, sorry :) [09:06] thanks again zyga, much appreciated! [09:06] thank you :) [09:06] mvo: I have plenty more :-) [09:06] thats good [09:07] keep them coming and we will name the next release after you :) [09:07] hahaha :-0 [09:07] :-) [09:07] when I'll run out of ideas I'll start fixing pep-8 issues and adding docstrings everywhere [09:08] lol [09:09] ricmm, any luck with the sfdisk hacking ? [09:11] mvo, so i guess we can create a raspberry subtree on snappy-hub to push the RPi setup to ? [09:11] ogra_: its seems to be, yes [09:11] ogra_: thats what I heard yesterday :) [10:20] longsleep: just one rapid question: device tree needs to recompile for exposin /dev/spidev0.0 right?? [10:20] Thanks in advance! [10:21] (Talking about your OdroidC1 Snappy image) [10:21] I meant /dev/spidev0.1 [10:28] mvo: I have a bigger one now [10:28] zyga: nice [10:29] mvo: https://code.launchpad.net/~zyga/snapcraft/fix-1486659/+merge/269190 [10:29] mvo: have look, I tested it obviously but there are no tests for that yet [10:30] mvo: I'll get to add tests but I'm not familiar with how to do it yet and I still think it's important to merge fixes for real issues, even if they are not tested automatically [10:32] mvo: there's one more issue that i didn't know how to fix, if the selected key is encrypted and there's no agent around, it will propmt the user, I wanted to prevent that somehow but I'm not sure how yet [10:33] mvo: also, if you want me to split this branch into separate branches & file bugs for various sub-issues, I can do that easily [10:37] zyga: thanks, I think its fine and I agree with the reasoning , I have a look now (or maybe after lunch if I don't finish in time :) [10:40] mvo: thanks [10:44] sergiusens: ping [10:44] sergiusens: around? :-) [10:46] zyga: yeah, but need to get some coffee, so start typing and I'll get back to you ;-) [10:46] sergiusens: thanks, I have a few ideas I want to discuss with you [11:34] zyga: hey [11:35] plars: hey [11:35] ogra_: nothing yet ;) working on that this afternoon [11:35] plars: in a meeting [11:35] plars: I got your message [11:35] zyga: I'm still not having much luck getting chainloading to work with inception in kvm, and still issues with mountpoints [11:35] zyga: sure, np... just sometime today, maybe we can walk through it [11:35] plars: I will fix that today [11:36] ricmm, so should we start in parallel on two approaches (me going the parted route) ? just to be safe ? [11:36] plars: I'm working on some improvements though they also intersect with other parts of the stack [11:36] plars: I'll tell you more later today [11:36] zyga: I also have some other stuff I was changing in my local branch, but wasn't sure where to push it to. There's no project that I could find [11:36] plars: I'll make one shortly [11:36] plars: right now you can just push it to any git repo [11:37] plars: I can work with that [11:38] ogra_: yea take a look at doing it with parted [11:38] great ... [11:38] if I get something for this we can change to it due to size improvements I guess [11:38] but you already know how to do it with parted, so best to move forward [11:38] it also seems like you cant really resize GPT partitions at all ... [11:38] all docs i can find delete the old one and create a new one with all tools [11:39] i have to test what resize in parted actually does ... if we need to delete and re-add that means even more math and scripting :/ [11:40] silly GPT ! [11:51] ppisati, btw, i dont think a watchdog will help with the 0byte kernel and dtb files ... we should have checks in the bootloaders and do the auto-fallback there [11:52] (not sure how hard that is to do in grub ... in uboot it is surely possible to check the size and file existence) [11:53] hi guys, can someone tell me a little bit how to create a snappy package with postgreql and rails in it., are there any examples online somewhere? [11:53] sergiusens, mvo: I would appreciate feedback on this mr, I have more things in the pipe and I (_crazy_ schedule) need to know I can land things effectively https://code.launchpad.net/~zyga/snapcraft/fix-1486659/+merge/269190 [11:53] if you are blocked/cannot review things/disagree with the changes, i'd like this feeback sooner rather than later [11:54] emilebosch, take a look at snapcraft https://developer.ubuntu.com/en/snappy/snapcraft/your-first-snap/ [11:54] (it is still very young and rough on the edges, please file bugs if you find issues) [11:55] ogra_: thanks, i just want to know a bit on the internals in order to understand how the services work. are they converted to systemd targets? [11:56] if you define a service in the package.yaml a systemd unit is created for it, yes [11:57] ogra, ok so are snaps than basically lxd containers? [11:57] with a systemd as init? [11:57] no, there are no containers ... [11:58] a snap runs natively on your system but wrapped by a launcher and confined by apparmor [11:58] huh. now i am confused. ok i need to read about the internals instead of annoying you guys, where can i find it [11:58] aaah [11:58] feels a bit weird now since ubuntu is moving to lxd/lxd [11:59] there is an lxc/lxd framework in the works and there is also a docker framework in the snap store ... but you would have to explicitly depend on them and have them installed for contsainer use [11:59] but by default snaps are just jailed on the system without containers around them [12:02] ogra what would be the upgrade scenario’s for snaps? in the sense lets say i have an app that runs a database then in release a new version how would it be upgraded? [12:03] your snap has a data dir where it stores such stuff ... that data dir is migrated (copied for now) durinng upgrades [12:03] thanks [12:04] it is reflected in the $SNAP_APP_DATA_DIR env var that is exported to your snaps environment when things start [12:05] ok awesome. is ther emore in-depth documentation avialable? [12:05] https://developer.ubuntu.com/en/snappy/guides/security-policy/ [12:06] that should list all the vars ... [12:06] and indeed there are https://developer.ubuntu.com/en/snappy/guides/package-metadata/ and https://developer.ubuntu.com/en/snappy/guides/packaging-format-apps/ [12:07] and a very basic tutorial at https://developer.ubuntu.com/en/snappy/tutorials/build-snaps/ [12:10] awesome thanks ogra_ [12:12] mvo, looking at http://bazaar.launchpad.net/~ubuntu-core-dev/livecd-rootfs/trunk/revision/1196 ... doesnt the build also create an initrd.img that should be deleted ? [12:17] ogra_: that is moved earlier unless I miss something [12:22] ok [12:22] i did only see the patch ... slightly out of context indeed [12:23] zyga: sorry for the delay, all approved now [12:23] mvo: thanks a lot, no need to worry :-) [12:24] mvo: a related question, where should *.snap files go? [12:24] are they expected to build to current working directory? [12:33] zyga: I think that was the plan, mterry was working on this part, I need to check the source/spec to be certain [12:33] mvo: if you have a link handy I'd like to see as well [12:34] joc_: https://code.launchpad.net/~zyga/snapcraft/extra-run-features have a look at this please [12:34] joc_: get this branch somwehere on the side and tell me if that lets you run snapcraft run to play with real wifi [12:35] the corresponding MR is https://code.launchpad.net/~zyga/snapcraft/extra-run-features/+merge/269202 [12:37] zyga: I look at this now [12:37] mvo: thanks [12:37] mvo: the use case is this [12:37] mvo: well, it's all explained there :) [12:38] mvo: but it makes development faster as you can just assemble/run [12:38] mvo: and often you don't need to involve real hardware [12:39] my usb wifi dongle stopped working [12:39] or maybe not? [12:39] * zyga tries [12:41] i havent been able to get mine working on rpi2 with the newer image [12:41] zyga: ^ not sure if thats related at all, but fyi :) [12:41] cwayne, oh, ? [12:41] cwayne: I don't have a rpi2 [12:42] ogra_: yeah, it keeps saying that it failed to associate with the driver and there's auth failures, even though i've looked over the psk 10,000 times and its correct [12:42] cwayne, if the driver is in the kernel/modules it should just work by adding the necessary data to /etc/network/interfaces [12:42] sigh [12:42] yes it's dead [12:42] ogra_: i've even copied the /etc/network/interfaces from my rpi1 with raspbian with the same dongle and it works there [12:43] * zyga needs to buy another wifi eh [12:43] smells like a driver issue then ... i know others use wlan dongles just fine ... do you know what driver it usually uuses ? [12:43] i'd had it working on an older image, but i've also physcially moved it, maybe its not getting a strong enough signal.. [12:43] ogra_: which dongle are you using? [12:44] ogra_: amazon links appreciated [12:44] zyga, i dont :P [12:44] * ogra_ has wires [12:44] why do we always have to be on the front lines ;-) [12:44] zyga, iirc rickspencer3 uses one on his BBB [12:44] hi ogra_ [12:45] hey rickspencer3 [12:45] * rickspencer3 looks for context [12:45] rickspencer3, you use a wlan dongle on your BBB, dont you ? [12:45] ogra_, no, I could not get either of mine to work [12:45] zyga, looks for recommendations for buying one that works [12:45] oh [12:45] ogra_: see [12:45] zyga, if you get one that definitively works, can you let me know? [12:45] yeah :( [12:45] :) [12:46] ogra_: I'll buy you one [12:46] rickspencer3: absolutely rick [12:46] i got this one: http://www.amazon.com/gp/product/B00FWMEFES?psc=1&redirect=true&ref_=oh_aui_detailpage_o03_s00 [12:46] rickspencer3: I'll get a few and try what works [12:46] and it did work before [12:46] maybe i just need to move it or something.. who knows [12:46] cwayne: looks like http://www.amazon.es/TP-LINK-TL-WN725N--Nano-Adaptador-garant%C3%ADa/dp/B008IFXQFU/ref=sr_1_1?ie=UTF8&qid=1440593083&sr=8-1&keywords=wifi+usb [12:46] cwayne: I wonder what's the chipset inside [12:46] anyway, cha-ching, let's get an see [12:47] zyga, hmm, i havent seen one of these NANO adapters tht had a linux supported chipset (though that was like 1.5y ago when i looked at them last) [12:48] ogra_: there's just one rpi2 now, right? [12:48] anyone that I get is good [12:49] joc_: any luck? [12:49] joc_: does it work for you [12:49] ogra_: yeah [12:50] ogra_: my point there was that [12:50] ogra_: the hack that i implemented in uboot [12:50] ogra_: is that, either you boot the kernel [12:50] ogra_: or it forcefully reboots the board [12:50] ogra_: so the a/b logic has another chance to run or whatever we put there [12:51] ogra_: and once the kernel takes over [12:51] ogra_: uboot can't do anything [12:51] * zyga looks for a master bug to get python3-project projects to see each other [12:52] ppisati: hi, I hope I don't get on your nerves yet but did you had a chance to check https://bugs.launchpad.net/snappy/+bug/1471868 - its a bit confusing, looks like the kernel is doing funny stuff if init is broken (and it seems to be different depending on architecture) [12:52] Launchpad bug 1471868 in Snappy "automatic reboot fails with non executable empty systemd" [Critical,Triaged] [12:53] well, the kernel can't do anything [12:53] ppisati, well, just blindly resetting wont make the ab switch ... you need to actively set snappy_ab to the opposite value too ... else you just create a loop [12:53] if there's no init [12:53] it doesn't know what to do [12:54] iirc it even looks in a couple of places [12:54] for alternate inits [12:54] yeah [12:54] but if the fs is corrupted [12:54] 4 or 5 even [12:54] and it cannot exec any of time [12:54] you are screwed [12:54] it can probably panics and reboot [12:54] but i've to check [12:54] ppisati: so this is a test when its broken and I think its doing the right thing on arm (panics) but not on amd64 [12:54] it should panic [12:55] ppisati: we broke init deliberately for the test of course [12:55] ppisati: feel free to downgrade/comment if there is nothng that the kernel can do of course, its all part of the robustness dance :) [12:56] ogra_: well, the watchdog sets a timer in hw [12:56] ogra_: and if it expires, it restes the board [12:56] ogra_: i mean, i cant change a var in the exec [12:57] ogra_: because the reset is done in hw, i can't run a trigger for example [12:57] mvo: that's weird, i've to test it [12:58] ppisati: thanks! no real rush, I'm mostly curious about it [12:59] (well, we should fix it eventually but its not omg-now priority or anything) [12:59] mvo: can you make a list of all these 'robustness thing' bugs? [12:59] ppisati: sure, I think I subscribed you to all of them, but I'm happy to add a tag, is "failover-robustness" good? [12:59] (as tagname?) [13:00] mvo: snappy robustness or something like that? [13:01] ppisati: works for me, so snappy-robustness as tag in LP and I send you the url that shows all such bugs? [13:01] mvo: that would be perfect [13:01] ppisati, right, thats why i mean a watchdog is the wrong approach, since we need to switch over from a to b (or the opposite) [13:02] ogra_: once mvo is done collecting all the robustenss bugs, we can discuss about it [13:02] yeah [13:12] arg, I can't remember how to hw-assing to the gpio pins [13:12] (BeagleBoneBlack)ubuntu@localhost:~$ sudo snappy hw-assign bike-and-bus-sensor.sideload '/sys/class/gpio/' [13:12] invalid hardware device [13:12] ? [13:12] didnt you open a bug about it yesterday ? [13:13] joc_: ha, the option is already very seful [13:13] useful [13:13] ogra_, differnet bug [13:13] joc_: SNAPCRAFT_RUN_QEMU_ARGS="-smp 2" snapcraft run [13:13] joc_: and you can write a simple "amd I SMP" test case [13:13] joc_: go for it! [13:13] ogra_, yesterday I figured out how to do hw-assign for the pins, but now I forget :/ [13:14] zyga: just trying the wifi thing - bit of pain cos think need root to access the wifi dev [13:15] joc_: oh [13:15] joc_: hmm [13:15] joc_: patch snapcraft to use sudo there [13:15] joc_: or [13:15] joc_: add yourself to the appropriate group [13:15] joc_: (2nd thing should be better but requires you to login again) [13:16] rickspencer3, https://bugs.launchpad.net/bugs/1488618 [13:16] Launchpad bug 1488618 in Snappy trunk "cannot specify /sys/class/gpio/export with hw-assign" [Critical,In progress] [13:16] (there is a workaround) [13:16] ogra_, yeah, that's a different bug, actually [13:16] zyga: the device is root:root [13:17] joc_: ah, I see [13:17] joc_: that's crap [13:17] and I've applied the work around :) [13:17] joc_: you an try an udev rule to change permissions [13:17] joc_: but I think running it via rut is easier [13:17] joc_: just patch cmd.py to have sudo there [13:17] k [13:17] rickspencer3, hmm, looks to me like the worakaround should give you full access [13:17] joc_: I'll add an option to make that a possible choice on command line [13:17] without even needing to call hw-assin again [13:18] ogra_, the work around gives me access only to export [13:18] so it provides access to the program that creates gpio files [13:18] but hten I need access to those files once created [13:18] which, I think, worked yesterday [13:18] but today I can't figure out that I did [13:18] rickspencer3, well, just add more lines for the other nodes in there [13:18] whatever you need [13:19] yeah, I can hack around it, but I swear I could just use hw-assign yesterday, so I think I am doing something silly [13:20] well, the bug says /sys/class is generally denied ... so i would be surpised if you got it working yesterday without hacksd [13:20] *hacks [13:21] probably jdstrand can clearify [13:22] well, all I can say is, I had it working with a different snap yesterday [13:22] zyga: seemed to work ok with a sudo added to the kvm call [13:22] it could have been a fluke, i.e. something else I didn't do wrong yesterday that I did wrong today :) [13:22] func validDevice(device string) bool { [13:22] return strings.HasPrefix(device, "/dev") || strings.HasPrefix(device, "/sys/devices") [13:22] } [13:23] these are the only two allowed paths when using hw-assign [13:25] joc_: cool, thanks for confirming this [13:29] ogra_: so i moved my rpi2 physically closer to the AP and now it connects, so there's that :) [13:30] cwayne, yay [13:30] zyga: ^ [13:30] cwayne: coool [13:35] rickspencer3, ogra_: currently we should allow access to the devices that are exported. the problem was that we blocked export/unexport [13:36] jdstrand, well, today I am getting blocked on the exported device :( [13:36] rickspencer3: so once you exported, hw-assign should work as expected (hw-assign foo /sys/devices/...) [13:36] rickspencer3: what is the denial? [13:36] jdstrand, /sys/class ... [13:36] not /sys/devices :) [13:37] jdstrand, I have 2 [13:37] audit: type=1400 audit(1440595711.301:11): apparmor="DENIED" operation="open" profile="bus-and-bike-sensor.sideload_bus-and-bike-sensor_0.1" name="/sys/devices/platform/ocp/481ac000.gpio/gpio/gpio68/direction" pid=726 comm="bus-and-bike-se" requested_mask="wr" denied_mask="wr" fsuid=0 ouid=0 [13:37] ok, that one should work with hw-assign [13:38] jdstrand, can you give me the command for hw-assign, I couldn't make it work [13:40] sudo hs-assign bus-and-bike-sensor.sideload '/sys/devices/platform/ocp/481ac000.gpio/**' [13:40] err [13:40] ug [13:40] sudo snappy hw-assign bus-and-bike-sensor.sideload '/sys/devices/platform/ocp/481ac000.gpio/**' [13:40] now, the /sys/devices/... could be just /sys/devices/platform/ocp/481ac000.gpio/gpio/gpio68/direction [13:40] wow, taking a while :) [13:41] is there anywhere a git repo wiht sample snaps? [13:41] or just some apps snappyfied? [13:41] but with the glob you shouldn't have to do extra stuff [13:41] let me try rebooting and see what happened [13:41] rickspencer3: don't reboot [13:41] too late [13:41] sorry [13:41] did the command complete? [13:41] jdstrand, yes [13:41] ok that's fine [13:41] I waited for the command to complete :) [13:41] for once I was not too impatient [13:41] hehe [13:43] rickspencer3: did it work? [13:43] so, here I am again [13:43] : type=1400 audit(1440596552.734:17): apparmor="DENIED" operation="open" profile="bus-and-bike-sensor.sideload_bus-and-bike-sensor_0.1" name="/sys/class/gpio/export" pid=1142 comm="bus-and-bike-se" requested_mask="w" denied_mask="w" fsuid=0 ouid=0 [13:43] I thought I fixed that in the apparmour file [13:43] ok, yes, that is what requires the workaround rule [13:43] oh, I know what happened [13:44] emilebosch, bzr branch lp:~snappy-dev/snappy-hub/snappy-examples [13:44] you added the workaround rule to the profile, then used hw-assign which rewrote the profile [13:44] (no git ... but bzr :) ) [13:44] aarg [13:44] rickspencer3: ^ [13:44] ok berw install bzr [13:44] oh [13:44] jdstrand, I did, but, looks like the apparmor profile got regenerated [13:44] the good news is, it sounds like mvo was going to hop on this so the workaround rule won't be needed [13:45] rickspencer3: yes. the hw-assign blew it away [13:45] * jdstrand adds comment to the bug [13:45] ok, I fixed the file and reran the parser [13:45] * rickspencer3 reboots [13:47] \o/ [13:47] thanks jdstrand that got it working again [13:48] that reboot shouldn't be required if you are restarting the correct service. if you feel compelled to try to chase that down, please file a bug and we can chase it down [13:48] rickspencer3: sure, np. sorry I forget to mention/didn't think about the fact that hw-assign regenerates the profile yesterday [13:48] meh [13:48]