elopiosergiusens: 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/148459604:09
ubottuLaunchpad bug 1484596 in PlainBox (Toolkit) "tests print a lot of warnings when they leave files on the working directory" [Undecided,Triaged]04:09
=== chihchun_afk is now known as chihchun
sergiusenselopio: bummer, it is so annoying :)04:20
sergiusenselopio: here's another one https://code.launchpad.net/~sergiusens/snapcraft/testing-fixes/+merge/26914604:23
sergiusens3rd and last04:23
* sergiusens goes for some zzzzz04:23
=== shuduo_afk is now known as shuduo
zygamvo: hey07:28
zygamvo: around?07:28
=== guest42315 is now known as o
=== o is now known as Guest39201
mvohey zyga, good morning07:33
zygamvo: hey, I'm trying to understand how a part of snapcraft you wrote works07:34
zygamvo: I'm thinking of the python3-project plugin07:34
zygamvo: specifically it seems to be a bit broken IMHO, but perhaps I'm missing something07:35
mvozyga: ok, what part is unclear? or everything :) ?07:35
zygamvo: could you please show me how to use two python3-project parts where A depends on B?07:35
zygamvo: how it's supposed to work, I already read the code and patched a few things07:35
zygamvo: but before I patch more, I want to see if I'm doing something sane07:36
zygamvo: 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 process07:36
zygamvo: (I wasn't thinking of using virtualenv, just to follow the same principle)07:36
zygamvo: also, from what I see, setuptools depenencies are not followed at all, so the developer has to put everything together manually, right?07:37
mvozyga: yeah, so dependencies are not resolved (yet) thats something that must be done manually right now07:38
zygaright, thanks for confirming that07:38
mvozyga: 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
zygamvo: ok, thanks, so currently it just crashes trying to run the setup of the 2nd part as it cannot import the 1st part07:39
zygamvo: what I'm doing now, is to change how setup is invoked07:39
zygamvo: I'm using --root relative to installdir and a fixed prefix07:40
zygamvo: and I'll be probably using a different layout, but I need to see how to control the environment first07:40
zygamvo: 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 dots07:40
zygamvo: I want to write an env function there that uses PYTHON* viariables to set everything up07:41
mvozyga: 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 another07:41
zygamvo: 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
zygamvo: and I want to make sure it's working regardless of that fact07:41
zygamvo: I added env() but it's not getting called yet07:42
zygaas in ...07:42
mvozyga: right07:42
zygamvo: I'll dig through this and improve it anyway I can07:43
zygamvo: 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 go07:44
mvozyga: 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 expect07:45
zygamvo: thanks07:45
zygasmall fix is to use /usr/bin/python3 instead of python307:46
zygathat addresses the virtualenv factor07:46
zygamvo: are you using virtualenv for development?07:47
mvozyga:  I don't use virtualenv07:52
zygamvo: how do you develop snapcraft then?07:58
mvozyga: in my normal wily env07:59
zygamvo: just running it straight from the tree?07:59
zygamvo: ok, thanks for the tip07:59
zygamvo: is python 3.5 default there?07:59
zygamvo: I'm on vivid07:59
mvozyga: its available but not default (yet)08:04
mvozyga: 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 aiui08:04
ogra_mvo, i see you closed bug 1479711 ... do we consider bugs "fix released" if the fix is only in wily ?08:13
ubottubug 1479711 in initramfs-tools-ubuntu-core (Ubuntu) "snappy should not mount with "discard" option" [Undecided,Fix released] https://launchpad.net/bugs/147971108:13
ogra_(just a general question)08:13
zygaogra_: o/08:13
ogra_hey zyga08:14
mvoogra_: I would say yes unless there is a 15.04 task, feel free to add one though08:14
ogra_k, thanks08:15
mvoogra_: 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 discussion08:15
ogra_well, would that work ? given the potential differences in both releases (newer go version, gcc5 etc)08:16
ogra_if that doesnt get in our way, yeah sure08:17
mvoogra_: 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:17
zygasmall bug in logging in snapcraft :)08:18
ogra_yeah, it definitely makes sense for stabilizing the stable image08:19
ogra_to keep the focus there ...08:19
ogra_(and it will make everyone more cautious sbout landing his changes as a nice sideefect :) )08:19
zygaand perhaps some more in various places, logging is broken wrt all arguments08:19
mvoyeah, 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.0408:20
* zyga starts proposing fixes08:20
zygamvo: who's the lead reviewer for snapcraft?08:28
mvozyga: sergio right now, but let me have a look, I can cover TZ wise08:28
zygamvo: cool, you can expect a lot of patches from me soon :)08:29
mvozyga: cool :)08:29
zygamvo: btw, do you want to use git with snapcraft (I am)08:29
zygamvo: it's pretty cool :)08:29
zygahelps sorting through patches a lot08:29
mvois the tarmac problem solved? that was the only thing holding us back08:30
zygamvo: bzr on the server08:30
zygamvo: git locally08:30
zygamvo: I'm using git-lp that I wrote (and I'm using all the time for the past three years)08:30
mvozyga: nice, where can I find it?08:33
zygamvo: https://github.com/zyga/git-lp08:34
zygamvo: if you have any issues just ping me08:35
* mvo looks08:35
zygamvo: it's just a single file, drop it in $PATH somewhere08:35
zygamvo: apply the damn patch to bzr and you're all set08:35
zyga(instructions on the wiki might be a bit stale, I wrote them at around 12.04 time frame)08:36
mvouh, I vaguely remember the patch08:36
zygamvo: how often does snapcraft merge processor (tarmac?) runs?08:49
mvozyga: should be every 10min, but I think there was a commit message missing, I set one now08:49
zygamvo: ah, sorry, I'm used to autogenerated commit messages08:51
mvono worries08:51
mvoand yes, that is (much) nicer08:51
zygaok, the other half of the change is now pushed08:53
zygamvo: https://code.launchpad.net/~zyga/snapcraft/fix-logging-calls/+merge/26916708:53
mvomeh, its still updating the diff08:58
* mvo waits (im)patiently08:58
zygamvo: yeah, is is oddly slow08:58
zygamvo: I have another branch to sweeten the wait08:59
* zyga cannot wait till he gets to the part of improving plainbox-based tests08:59
zygamvo: https://code.launchpad.net/~zyga/snapcraft/fix-process-leak/+merge/26917209:00
zygait's pretty odd because all the delta shows up fine http://bazaar.launchpad.net/~zyga/snapcraft/fix-logging-calls/revision/13609:00
zygaand the one on the 2nd branch is already generated09:01
zygamvo: both branches are reviewable now09:06
mvozyga: and are reviewed :P09:06
zygaoh, sorry :)09:06
mvothanks again zyga, much appreciated!09:06
zygathank you :)09:06
zygamvo: I have plenty more :-)09:06
mvothats good09:06
mvokeep them coming and we will name the next release after you :)09:07
zygahahaha :-009:07
zygawhen I'll run out of ideas I'll start fixing pep-8 issues and adding docstrings everywhere09:07
ogra_ricmm, any luck with the sfdisk hacking ?09:09
ogra_mvo, so i guess we can create a raspberry subtree on snappy-hub to push the RPi setup to  ?09:11
mvoogra_: its seems to be, yes09:11
mvoogra_: thats what I heard yesterday :)09:11
imuguruzalongsleep: just one rapid question: device tree needs to recompile for exposin /dev/spidev0.0 right??10:20
imuguruzaThanks in advance!10:20
imuguruza(Talking about your OdroidC1 Snappy image)10:21
imuguruzaI meant /dev/spidev0.110:21
zygamvo: I have a bigger one now10:28
mvozyga: nice10:28
zygamvo: https://code.launchpad.net/~zyga/snapcraft/fix-1486659/+merge/26919010:29
zygamvo: have look, I tested it obviously but there are no tests for that yet10:29
zygamvo: 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 automatically10:30
zygamvo: 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 yet10:32
zygamvo: also, if you want me to split this branch into separate branches & file bugs for various sub-issues, I can do that easily10:33
mvozyga: 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:37
zygamvo: thanks10:40
zygasergiusens: ping10:44
zygasergiusens: around? :-)10:44
sergiusenszyga: yeah, but need to get some coffee, so start typing and I'll get back to you ;-)10:46
zygasergiusens: thanks, I have a few ideas I want to discuss with you10:46
plarszyga: hey11:34
zygaplars: hey11:35
ricmmogra_: nothing yet ;) working on that this afternoon11:35
zygaplars: in a meeting11:35
zygaplars: I got your message11:35
plarszyga: I'm still not having much luck getting chainloading to work with inception in kvm, and still issues with mountpoints11:35
plarszyga: sure, np... just sometime today, maybe we can walk through it11:35
zygaplars: I will fix that today11:35
ogra_ricmm, so should we start in parallel on two approaches (me going the parted route) ? just to be safe ?11:36
zygaplars: I'm working on some improvements though they also intersect with other parts of the stack11:36
zygaplars: I'll tell you more later today11:36
plarszyga: 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 find11:36
zygaplars: I'll make one shortly11:36
zygaplars: right now you can just push it to any git repo11:36
zygaplars: I can work with that11:37
ricmmogra_: yea take a look at doing it with parted11:38
ogra_great ...11:38
ricmmif I get something for this we can change to it due to size improvements I guess11:38
ricmmbut you already know how to do it with parted, so best to move forward11:38
ogra_it also seems like you cant really resize GPT partitions at all ...11:38
ogra_all docs i can find delete the old one and create a new one with all tools11:38
ogra_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:39
ogra_silly GPT !11:40
ogra_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 there11:51
ogra_(not sure how hard that is to do in grub ... in uboot it is surely possible to check the size and file existence)11:52
emileboschhi 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
zygasergiusens, 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/26919011:53
zygaif you are blocked/cannot review things/disagree with the changes, i'd like this feeback sooner rather than later11:53
ogra_emilebosch, take a look at snapcraft https://developer.ubuntu.com/en/snappy/snapcraft/your-first-snap/11:54
ogra_(it is still very young and rough on the edges, please file bugs if you find issues)11:54
emileboschogra_: 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:55
ogra_if you define a service in the package.yaml a systemd unit is created for it, yes11:56
emileboschogra, ok so are snaps than basically lxd containers?11:57
emileboschwith a systemd as init?11:57
ogra_no, there are no containers ...11:57
ogra_a snap runs natively on your system but wrapped by a launcher and confined by apparmor11:58
emileboschhuh.  now i am confused. ok i need to read about the internals instead of annoying you guys, where can i find it11:58
emileboschfeels a bit weird now since ubuntu is moving to lxd/lxd11:58
ogra_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 use11:59
ogra_but by default snaps are just jailed on the system without containers around them11:59
emileboschogra 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:02
ogra_your snap has a data dir where it stores such stuff ... that data dir is migrated (copied for now) durinng upgrades12:03
ogra_it is reflected in the $SNAP_APP_DATA_DIR env var that is exported to your snaps environment when things start12:04
emileboschok awesome. is ther emore in-depth documentation avialable?12:05
ogra_that should list all the vars ...12:06
ogra_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:06
ogra_and a very basic tutorial at https://developer.ubuntu.com/en/snappy/tutorials/build-snaps/12:07
emileboschawesome thanks ogra_12:10
ogra_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:12
mvoogra_: that is moved earlier unless I miss something12:17
ogra_i did only see the patch ... slightly out of context indeed12:22
mvozyga: sorry for the delay, all approved now12:23
zygamvo: thanks a lot, no need to worry :-)12:23
zygamvo: a related question, where should *.snap files go?12:24
zygaare they expected to build to current working directory?12:24
mvozyga: I think that was the plan, mterry was working on this part, I need to check the source/spec to be certain12:33
zygamvo: if you have a link handy I'd like to see as well12:33
zygajoc_: https://code.launchpad.net/~zyga/snapcraft/extra-run-features have a look at this please12:34
zygajoc_: get this branch somwehere on the side and tell me if that lets you run snapcraft run to play with real wifi12:34
zygathe corresponding MR is https://code.launchpad.net/~zyga/snapcraft/extra-run-features/+merge/26920212:35
mvozyga: I look at this now12:37
zygamvo: thanks12:37
zygamvo: the use case is this12:37
zygamvo: well, it's all explained there :)12:37
zygamvo: but it makes development faster as you can just assemble/run12:38
zygamvo: and often you don't need to involve real hardware12:38
zygamy usb wifi dongle stopped working12:39
zygaor maybe not?12:39
* zyga tries12:39
cwaynei havent been able to get mine working on rpi2 with the newer image12:41
cwaynezyga: ^ not sure if thats related at all, but fyi  :)12:41
ogra_cwayne, oh, ?12:41
zygacwayne: I don't have a rpi212:41
cwayneogra_: 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 correct12:42
ogra_cwayne, if the driver is in the kernel/modules it should just work by adding the necessary data to /etc/network/interfaces12:42
zygayes it's dead12:42
cwayneogra_: i've even copied the /etc/network/interfaces from my rpi1 with raspbian with the same dongle and it works there12:42
* zyga needs to buy another wifi eh12:43
ogra_smells like a driver issue then ... i know others use wlan dongles just fine ... do you know what driver it usually uuses ?12:43
cwaynei'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
zygaogra_: which dongle are you using?12:43
zygaogra_: amazon links appreciated12:44
ogra_zyga, i dont :P12:44
* ogra_ has wires 12:44
zygawhy do we always have to be on the front lines ;-)12:44
ogra_zyga, iirc rickspencer3 uses one on his BBB12:44
rickspencer3hi ogra_12:44
ogra_hey rickspencer312:45
* rickspencer3 looks for context12:45
ogra_rickspencer3, you use a wlan dongle on your BBB, dont you ?12:45
rickspencer3ogra_, no, I could not get either of mine to work12:45
ogra_zyga, looks for recommendations for buying one that works12:45
zygaogra_: see12:45
rickspencer3zyga, if you get one that definitively works, can you let me know?12:45
ogra_yeah :(12:45
zygaogra_: I'll buy you one12:46
zygarickspencer3: absolutely rick12:46
cwaynei got this one: http://www.amazon.com/gp/product/B00FWMEFES?psc=1&redirect=true&ref_=oh_aui_detailpage_o03_s0012:46
zygarickspencer3: I'll get a few and try what works12:46
cwayneand it did work before12:46
cwaynemaybe i just need to move it or something.. who knows12:46
zygacwayne: 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+usb12:46
zygacwayne: I wonder what's the chipset inside12:46
zygaanyway, cha-ching, let's get an see12:46
ogra_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:47
zygaogra_: there's just one rpi2 now, right?12:48
zygaanyone that I get is good12:48
zygajoc_: any luck?12:49
zygajoc_: does it work for you12:49
ppisatiogra_: yeah12:49
ppisatiogra_: my point there was that12:50
ppisatiogra_: the hack that i implemented in uboot12:50
ppisatiogra_: is that, either you boot the kernel12:50
ppisatiogra_: or it forcefully reboots the board12:50
ppisatiogra_: so the a/b logic has another chance to run or whatever we put there12:50
ppisatiogra_: and once the kernel takes over12:51
ppisatiogra_: uboot can't do anything12:51
* zyga looks for a master bug to get python3-project projects to see each other 12:51
mvoppisati: 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
ubottuLaunchpad bug 1471868 in Snappy "automatic reboot fails with non executable empty systemd" [Critical,Triaged]12:52
ppisatiwell, the kernel can't do anything12:53
ogra_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 loop12:53
ppisatiif there's no init12:53
ppisatiit doesn't know what to do12:53
ppisatiiirc it even looks in a couple of places12:54
ppisatifor alternate inits12:54
ppisatibut if the fs is corrupted12:54
ogra_4 or 5 even12:54
ppisatiand it cannot exec any of time12:54
ppisatiyou are screwed12:54
ppisatiit can probably panics and reboot12:54
ppisatibut i've to check12:54
mvoppisati: so this is a test when its broken and I think its doing the right thing on arm (panics) but not on amd6412:54
ogra_it should panic12:54
mvoppisati: we broke init deliberately for the test of course12:55
mvoppisati: feel free to downgrade/comment if there is nothng that the kernel can do of course, its all part of the robustness dance :)12:55
ppisatiogra_: well, the watchdog sets a timer in hw12:56
ppisatiogra_: and if it expires, it restes the board12:56
ppisatiogra_: i mean, i cant change a var in the exec12:56
ppisatiogra_: because the reset is done in hw, i can't run a trigger for example12:57
ppisatimvo: that's weird, i've to test it12:57
mvoppisati: thanks! no real rush, I'm mostly curious about it12:58
mvo(well, we should fix it eventually but its not omg-now priority or anything)12:59
ppisatimvo: can you make a list of all these 'robustness thing' bugs?12:59
mvoppisati: sure, I think I subscribed you to all of them, but I'm happy to add a tag, is "failover-robustness" good?12:59
mvo(as tagname?)12:59
ppisatimvo: snappy robustness or something like that?13:00
mvoppisati: works for me, so snappy-robustness as tag in LP and I send you the url that shows all such bugs?13:01
ppisatimvo: that would be perfect13:01
ogra_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:01
ppisatiogra_: once mvo is done collecting all the robustenss bugs, we can discuss about it13:02
rickspencer3arg, I can't remember how to hw-assing to the gpio pins13:12
rickspencer3(BeagleBoneBlack)ubuntu@localhost:~$ sudo snappy hw-assign bike-and-bus-sensor.sideload '/sys/class/gpio/'13:12
rickspencer3invalid hardware device13:12
ogra_didnt you open a bug about it yesterday ?13:12
zygajoc_: ha, the option is already very seful13:13
rickspencer3ogra_, differnet bug13:13
zygajoc_: SNAPCRAFT_RUN_QEMU_ARGS="-smp 2" snapcraft run13:13
zygajoc_: and you can write a simple "amd I SMP" test case13:13
zygajoc_: go for it!13:13
rickspencer3ogra_, yesterday I figured out how to do hw-assign for the pins, but now I forget :/13:13
joc_zyga: just trying the wifi thing - bit of pain cos think need root to access the wifi dev13:14
zygajoc_: oh13:15
zygajoc_: hmm13:15
zygajoc_: patch snapcraft to use sudo there13:15
zygajoc_: or13:15
zygajoc_: add yourself to the appropriate group13:15
zygajoc_: (2nd thing should be better but requires you to login again)13:15
ogra_rickspencer3, https://bugs.launchpad.net/bugs/148861813:16
ubottuLaunchpad bug 1488618 in Snappy trunk "cannot specify /sys/class/gpio/export with hw-assign" [Critical,In progress]13:16
ogra_(there is a workaround)13:16
rickspencer3ogra_, yeah, that's a different bug, actually13:16
joc_zyga: the device is root:root13:16
zygajoc_: ah, I see13:17
zygajoc_: that's crap13:17
rickspencer3and I've applied the work around :)13:17
zygajoc_: you an try an udev rule to change permissions13:17
zygajoc_: but I think running it via rut is easier13:17
zygajoc_: just patch cmd.py to have sudo there13:17
ogra_rickspencer3, hmm, looks to me like the worakaround should give you full access13:17
zygajoc_: I'll add an option to make that a possible choice on command line13:17
ogra_without even needing to call hw-assin again13:17
rickspencer3ogra_, the work around gives me access only to export13:18
rickspencer3so it provides access to the program that creates gpio files13:18
rickspencer3but hten I need access to those files once created13:18
rickspencer3which, I think, worked yesterday13:18
rickspencer3but today I can't figure out that I did13:18
ogra_rickspencer3, well, just add more lines for the other nodes in there13:18
ogra_whatever you need13:18
rickspencer3yeah, I can hack around it, but I swear I could just use hw-assign yesterday, so I think I am doing something silly13:19
ogra_well, the bug says /sys/class is generally denied ... so i would be surpised if you got it working yesterday without hacksd13:20
ogra_probably jdstrand can clearify13:21
rickspencer3well, all I can say is, I had it working with a different snap yesterday13:22
joc_zyga: seemed to work ok with a sudo added to the kvm call13:22
rickspencer3it could have been a fluke, i.e. something else I didn't do wrong yesterday that I did wrong today :)13:22
ogra_func validDevice(device string) bool {13:22
ogra_ return strings.HasPrefix(device, "/dev") || strings.HasPrefix(device, "/sys/devices")13:22
ogra_these are the only two allowed paths when using hw-assign13:23
zygajoc_: cool, thanks for confirming this13:25
cwayneogra_: so i moved my rpi2 physically closer to the AP and now it connects, so there's that :)13:29
ogra_cwayne, yay13:30
cwaynezyga: ^13:30
zygacwayne: coool13:30
jdstrandrickspencer3, ogra_: currently we should allow access to the devices that are exported. the problem was that we blocked export/unexport13:35
rickspencer3jdstrand, well, today I am getting blocked on the exported device :(13:36
jdstrandrickspencer3: so once you exported, hw-assign should work as expected (hw-assign foo /sys/devices/...)13:36
jdstrandrickspencer3: what is the denial?13:36
ogra_jdstrand, /sys/class ...13:36
ogra_not /sys/devices :)13:36
rickspencer3jdstrand, I have 213:37
rickspencer3 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=013:37
jdstrandok, that one should work with hw-assign13:37
rickspencer3jdstrand, can you give me the command for hw-assign, I couldn't make it work13:38
jdstrandsudo hs-assign bus-and-bike-sensor.sideload '/sys/devices/platform/ocp/481ac000.gpio/**'13:40
jdstrandsudo snappy hw-assign bus-and-bike-sensor.sideload '/sys/devices/platform/ocp/481ac000.gpio/**'13:40
jdstrandnow, the /sys/devices/... could be just /sys/devices/platform/ocp/481ac000.gpio/gpio/gpio68/direction13:40
rickspencer3wow, taking a while :)13:40
emileboschis there anywhere a git repo wiht sample snaps?13:41
emileboschor just some apps snappyfied?13:41
jdstrandbut with the glob you shouldn't have to do extra stuff13:41
rickspencer3let me try rebooting and see what happened13:41
jdstrandrickspencer3: don't reboot13:41
rickspencer3too late13:41
jdstranddid the command complete?13:41
rickspencer3jdstrand, yes13:41
jdstrandok that's fine13:41
rickspencer3I waited for the command to complete :)13:41
rickspencer3for once I was not too impatient13:41
jdstrandrickspencer3: did it work?13:43
rickspencer3so, here I am again13:43
rickspencer3: 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=013:43
rickspencer3I thought I fixed that in the apparmour file13:43
jdstrandok, yes, that is what requires the workaround rule13:43
jdstrandoh, I know what happened13:43
ogra_emilebosch, bzr branch lp:~snappy-dev/snappy-hub/snappy-examples13:44
jdstrandyou added the workaround rule to the profile, then used hw-assign which rewrote the profile13:44
ogra_(no git ... but bzr :) )13:44
jdstrandrickspencer3: ^13:44
emileboschok berw install bzr13:44
rickspencer3jdstrand, I did, but, looks like the apparmor profile got regenerated13:44
jdstrandthe good news is, it sounds like mvo was going to hop on this so the workaround rule won't be needed13:44
jdstrandrickspencer3: yes. the hw-assign blew it away13:45
* jdstrand adds comment to the bug13:45
rickspencer3ok, I fixed the file and reran the parser13:45
* rickspencer3 reboots13:45
rickspencer3thanks jdstrand that got it working again13:47
jdstrandthat 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 down13:48
jdstrandrickspencer3: sure, np. sorry I forget to mention/didn't think about the fact that hw-assign regenerates the profile yesterday13:48
rickspencer3I would have gotten there since the same app armor denial came back13:48
rickspencer3now I have a happily blinking led again :)13:49
* rickspencer3 moves on to controlling it from a web api :)13:49
ogra_rickspencer3, next step, phone webapp ?13:58
ogra_(though that might be tricky without avahi )13:59
rickspencer3ogra_, I am going to get the next bus prediction from my local transport companies api13:59
rickspencer3and first blink a light depending on when the next bus is coming14:00
rickspencer3then do something similar for the city bikes near me14:00
rickspencer3then I will add some info the lcd screen14:00
ogra_so you dont want a webapp but integration with the phone notifications !14:00
rickspencer3yeah, phone notifications could be next14:01
rickspencer3but, I was just thinking it would be like ambient information14:01
rickspencer3"oh, bikes are running low, maybe I should leave now instead"14:01
rickspencer3"hmmm looks like we can take our time, it will be a while before the next bus"14:01
rickspencer3that kind of thing\14:01
rickspencer3I'm thinking that if I get really tricky, I can make a web config UI, then other people in DC can make their own, just add their stop and bike station ids :)14:02
mvoppisati: https://bugs.launchpad.net/snappy/+bugs?field.tag=snappy-robustness <- the list we talked about earlier14:07
ppisatiogra_: ^14:09
mvopitti: silly question, how can I see if m systemd "ubuntu-snappy.boot-ok.service" was executed before or after the "rc.local" script? and if it was run before, is there a way to ensure that ubuntu-snappy.boot-ok.service is run last (ideally very last :) ?14:16
pittihey mvo14:16
pittimvo: there is no "very last" concept in any recent init system, I'm afraid (not even in SysV with insserv)14:17
mvopitti: hm, do you have a idea what might be the closest approximation?14:17
pittimvo: you can check systemctl show -p ExecMainStartTimestampMonotonic ubuntu-snappy.boot-ok.service14:17
mvopitti: after getty is run or something?14:17
pitti(that gives you subsecond precision)14:17
pittimvo: and compare that to the time stamp in rc-local.service14:18
pittimvo: or just check the journal which one was starting/started after which14:18
mvopitti: yeah, thats helpful14:18
pittimvo: After=multi-user.target is fairly late14:18
mvopitti: I think thats the culprit, our book-ok script runs before rc.local14:19
mvopitti: cool, let me try this14:19
pittimvo: I've heard of several people wanting their unit to be the "very last", they can't *all* be that :)14:19
mvopitti: ahah, if its late enough thats ok14:19
pittimvo: but most stuff runs < multi-user.target, at that point you can definitively call the boot a "success"14:19
mvopitti: I just want to be sure that it made it to the prompt14:19
mvopitti: thanks (as always!) for you great and prompt help :)14:19
pittimvo: soif that's the intention ("is my boot okay?), then After=multi-user.target sounds about right14:19
* mvo will add it14:20
* pitti hugs mvo14:20
* mvo hugs pitti14:20
mvoand one more bug down14:20
pittimvo: FTR, I saw LP #1457491, still in my queue; sorry for the delay14:20
ubottuLaunchpad bug 1457491 in Snappy "Upgrade from r41 to r55 on BBB failed to boot and also to failover (drops into rescue systemd mode)" [High,Triaged] https://launchpad.net/bugs/145749114:20
mvopitti: aha, yeah, thats another one where I would prefer if it could go to auto-reboot if a certain kernel cmdline is set14:21
mvopitti: i.e. I guess I just need something like a custom preexec script or something14:21
pittimvo: probably just OnFailure=reboot.target14:21
pitti(or something such; I haven't checked the details yet)14:22
mvoaha, cool14:22
mvothats pretty amazing if its that simple14:22
pittiand I'm not very familiar with the OnFailure= bit yet, need to test this14:22
* pitti tries hard to catch up with mail/bug/IRC queue14:22
mvopitti: no worries, not urgent really :) I can dig with the new OnFailure info a bit more myself14:23
ogra_ppisati, gigantic :P14:41
=== chihchun is now known as chihchun_afk
=== jkridner|work is now known as jkridner
elopiomvo: I don't get why snappy-from-branch is not working for your branch. When I pring $(which snappy) it shows /tmp/adt-run.wnFI56/tree/_integration-tests/bin/snappy16:38
elopioah, sudo which snappy prints /usr/bin/snappy16:44
=== mrjazzcat is now known as mrjazzcat-afk
mvoelopio: ohhh, of course, thanks!17:50
mvoelopio: I fix tomorrow then, have you commented in the mp already? if not, please do so that I don't forget about it agian :)17:51
elopiomvo: I can't preserve the user path. An alias doesn't work, because ExecCommand adds the full path to the binary. And go doesn't seem to like passing PATH=$PATH in the command args.17:51
sergiusenselopio: tell sudo not to wipe the env17:57
elopiosergiusens: -E doesn't work. -i doesn't work.17:58
rickspencer3I seem to recall that there was some kind of cli command that I could issue that would let systemd tell me what messages my app wrote out18:04
rickspencer3does anyone remember what I mean?18:05
elopiosergiusens: https://code.launchpad.net/~elopio/snappy/sudo_path/+merge/26925218:22
elopiothat's the only way I could make it work.18:22
rickspencer3jdstrand, if I am seeing this:18:29
rickspencer3Aug 26 18:26:45 localhost kernel: [   74.556368] audit: type=1400 audit(1440613605.338:11): apparmor="DENIED" operation="capable" profile="bus-and-bike-sensor.sideload_bus-and-bike-sensor_0.1" pid=1561 comm="bus-and-bike-se" capability=12  capname="net_admin"18:29
rickspencer3can I just add net_admin to my caps or something?18:29
jdstrandthis is that bug from before18:29
rickspencer3this is being hit when I write Go code that accesses an https resource18:29
* jdstrand finds it18:29
ubottuLaunchpad bug 1465724 in Snappy "net_admin apparmor denial when using Go" [Undecided,Incomplete]18:30
rickspencer3jdstrand, so, this seems like a common thing to do, no?18:30
rickspencer3use Go to access an https resource?18:31
* rickspencer3 thought this was fixed a while ago18:31
jdstrandyes, but the denial should be harmless. is it keeping your app from running?18:31
jdstrandwe reviewed it and it is just an out of order check in the kernel18:31
jjohansenjdstrand: no cap net_admin should not be handed out like candy18:32
rickspencer3jdstrand, yes, it keeps my app from running18:32
jjohansenit allows modifying routing tables, interface config, masquerading18:32
rickspencer3so far as I can tell, anyway18:32
jdstrandjjohansen: no one is proposing that18:32
jjohansenjdstrand: give it out to every go app is handing it out like candy18:33
jdstrandjjohansen: no one is proposing doing that :)18:33
jdstrandjjohansen: it is a kernel bug18:33
jdstrandjjohansen: see https://bugs.launchpad.net/snappy/+bug/1465724/comments/918:33
ubottuLaunchpad bug 1465724 in Snappy "net_admin apparmor denial when using Go" [Undecided,Incomplete]18:33
rickspencer3jdstrand, maybe it isn't keeping my app from running, hard to say18:34
jdstrandrickspencer3: ok, for now you have to modify the profile to add 'capability net_admin,' to unblock you. the bug was deprioritized because we thought it was a harmless denial. we'll up the priority18:34
elopiorickspencer3: fwiw, we have this card: https://trello.com/c/V5pmALwm/197-document-the-files-and-logs-that-help-to-diagnose-problems-in-a-snap18:34
rickspencer3jdstrand, I just add that to the end of the app armor profile?18:35
rickspencer3I can try it, and see if it fixes my app18:35
jdstrandrickspencer3: ah, well, if you add that rule and it starts working, then it likely is the cause, but if it still doesn't work, then it probably isn't18:35
jdstrandrickspencer3: yes, before the trailing '}', like before18:35
sergiusenselopio: here you go: https://code.launchpad.net/~sergiusens/snapcraft/validation/+merge/26912018:36
sergiusenselopio: I'll trade ;-)18:36
rickspencer3elopio, right, so I am printing debug information from my code, but I forget how to read it18:37
rickspencer3I recall there is some trick to telling journalctl how to look at your debug output18:37
elopiosergiusens: wait on mine, because it stopped working :/18:37
elopiosergiusens: and you probably owe me like 400 lines. This is not fair trade ;)18:38
jdstrandsudo journalctl --unit <name of file in /etc/systemd/system>18:38
rickspencer3jdstrand, for what it is worth, adding the cap didn't fix my app ;)18:39
tyhicksrickspencer3: that's good to know - I was fairly sure that the AppArmor denial wouldn't affect go apps but I wasn't 100% sure18:41
jdstrandrickspencer3: ok, thank you for the feedback18:42
sergiusenselopio: it's mostly tests ;-)18:42
elopiosergiusens: ready now. I forgot to make it writable.18:42
jdstrandtyhicks: we might want to reconsider the current priority of that bug because it is confusing to the developer18:42
tyhicksjdstrand: I agree that it is confusing18:43
elopiosergiusens: tests are also code!18:54
elopioIf you prick them, do they not bleed?18:54
sergiusenselopio: not in production ;-)18:56
elopiosergiusens: I don't understand why you have to quote the version.19:27
sergiusenselopio: because if not, it is not a string according to the yaml spec19:32
sergiusenselopio: and python assigns an int to it for things like '1', '2'19:33
elopiosergiusens: but isn't the vendor a string? And it has no quotes.19:33
sergiusenselopio: if it can detect it is a string, it will be a string19:33
sergiusenselopio: there are no letters in 119:33
elopioI find it confusing. Can't we overwrite the parsing to make the version always a string?19:34
sergiusenselopio: notice that if it were 1.1 it would also be an int, but maybe 1.1.1 would be a string19:34
elopioyeah, I understand now.19:34
sergiusenselopio: maybe, I need to look into the engine a bit more19:34
elopiobut I wonder if this is a common practice in yamls. Or just something that's forced on us because of python being too smart.19:35
sergiusenselopio: well I know how to fix this in go :-)19:35
sergiusenselopio: I bet there is a way in python and I have it somewhere to check; in any case, version is deprecated19:36
elopiosergiusens: we are not going to have versions?19:43
elopiothat's enough for my back this morning, I'll have lunch and take a break. bbl.19:48
sergiusenselopio: is python 3.4 available for trusty?20:41
sergiusenselopio: and yeah, versions are meaningless, at least manual ones; just look at all our packages ;-)20:42
=== blr_ is now known as blr

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!