[00:18] <sergiusens> elopio: I hinted earlier that if we get the right mocking level I don't mind extending the unit tests for snapcraft itself
[00:19] <sergiusens> elopio: but there is no test code for that in there and I didn't want to deviate from the current status quo in my first contribution ;-)
[00:21] <sergiusens> elopio: and you last comment taken into account
[00:23] <elopio> sergiusens: top-approved.
[00:23] <elopio> sergiusens: I think I wouldn't want to mock hg, or git. But I don't like the tests written in those plainbox commands.
[00:23] <sergiusens> elopio: \o/ one more MP and I can build py2 and hg projects from the ether
[00:23] <elopio> I would prefer to have integration tests written in python.
[00:24] <sergiusens> elopio: heh, feel free to change it all ;-)
[00:24] <sergiusens> elopio: would it be python snippets given plainbox?
[00:24] <elopio> well, I first need a good reason to re-do all the work.
[00:25] <elopio> I'm not sure why do we want plainbox here. So I'll wait for our qa meeting next week to talk about it with zyga.
[00:25] <sergiusens> elopio: what I like of it being a script is that I can read all about it when it fails really easily, aside from that, nothing else; I prefer compiled languages these days to not run things and find typos along the way ;-)
[00:25] <elopio> he did a lot of work to get it working with plainbox, so...
[00:26] <elopio> what I don't like is the lack of cleanups, fixtures, assertions.
[00:46] <sergiusens> elopio: latest snapcraft is broken for me, can you check? I think it's 'self.recommends = options.recommends or False' whereas we probably want getattr there
[00:48] <elopio> sergiusens: what command are you running? Some commands work for me using trunk.
[00:49] <sergiusens> elopio: right, it's when executing certain projects that use the ubuntu plugin
[00:49] <sergiusens> elopio: http://paste.ubuntu.com/12010834/
[00:50] <sergiusens> elopio: that's what I mean
[00:50] <elopio> right, that looks good.
[00:50] <elopio> sergiusens: + one test, it would look perfect :)
[00:50] <sergiusens> elopio: let me propose an MP and see if I can write a small test
[00:52] <elopio> sergiusens: there's test_ubuntu_plugin.py
[00:55] <sergiusens> elopio: is there an assertNotRaises?
[00:56] <elopio> sergiusens: no, for that case what I do is just to end the test with the call.
[00:56] <elopio> if it raises something, the test will fail.
[00:57] <elopio> a comment saying like # The call should not raise an error. would be nice.
[01:02] <sergiusens> elopio: https://code.launchpad.net/~sergiusens/snapcraft/recommendedOptions/+merge/267119
[01:02] <sergiusens> elopio: took a slightly different approach
[02:16] <sergiusens> elopio: https://code.launchpad.net/~sergiusens/snapcraft/setuptools/+merge/267121
[02:16] <sergiusens> see if you have a better idea there
[03:39] <elopio> sergiusens: can't you specify the python-setuptools dependency in the yaml of your package?
[03:40] <elopio> there are other setup packages, so not all will require setuptools.
[03:43] <sergiusens> elopio: I can, but I thought it be pretty common
[03:44] <sergiusens> elopio: well now that I know about the 'after' keyword; but the PYTHONPATH gimmick would go where?
[03:44] <sergiusens> anyways, bed time :-)
[04:06] <ToyKeeper> Snapcraft looks very helpful...  am hoping to try it this week.  :)
[04:07] <ToyKeeper> (building and packaging a python-based network game)
[07:05] <fgimenez> good morning
[07:13] <dholbach> good morning
[08:54] <JamesTait> Good morning all; happy Fresh Breath Day! 😃
[10:29] <longsleep> i think i have found a bug in snapcraft ubuntu plugin, it does not fix up symlinks to folders, but it seems that os.walk does list symlinks to directories which exist in dirs rather than in files and the plugin only checks the files.
[10:29] <ogra_> well, i guess at this state snapcraft bugs are still pretty expected ;)
[10:30] <ogra_> file it :)
[10:30] <longsleep> right - my Python got a little rusty since Go is around ..
[11:17] <hio> what is the ETA?
[11:18] <ogra_> 7am on a sunday
[11:18] <hio> i mean the ETA of snappy
[11:18] <ogra_> for what exactly ?
[11:18] <hio> so that i can use it as my production server environment
[11:19] <ogra_> snappy is out there and is used by projects already ...
[11:20] <hio> ogra_: i cant find the iso download?
[11:20] <ogra_> really depends what you want to do with it
[11:20] <hio> well i told you: server for my webapps
[11:20] <sergiusens> hio: it's available on the major cloud envs already fwiw
[11:20] <hio> well i have a VPS / root server
[11:21] <hio> i need to install it there with an ISO
[11:21] <longsleep> ogra_: made a patch instead https://code.launchpad.net/~longsleep/snapcraft/snapcraft-dirs-symlink/+merge/267176
[11:21] <hio> and on vmplayer too
[11:21] <ogra_> there is no installer yet and it is currently mainly focusing on IoT, cloud and embedded
[11:22] <ogra_> you would have to boot from some other media and then dd the img file to disk ... not sure that will work with a VPS at all though ... since you often dont have control over the kernel in such setups
[11:22] <ogra_> and snappy has pretty specific requirements on the kernel config
[11:23] <ogra_> (and on the bootloader for all the rollback functionality)
[11:53] <Mikaela> hio: https://developer.ubuntu.com/en/snappy/start/
[12:44] <longsleep> So, someone would be so kind to review https://code.launchpad.net/~longsleep/snapcraft/snapcraft-dirs-symlink/+merge/267176 please
[13:50] <sergiusens> mterry: do you have your snapcraft project for the webcam thing available anywhere?
[13:53] <mterry> sergiusens, my own code for the demo is lp:~mterry/snapcraft/mitdemo (mostly just trunk's webcam-webui example + go-on-arm branch + a couple change to the webcam code to work in my case)
[14:00] <longsleep> mterry: have you seen https://code.launchpad.net/~longsleep/snapcraft/snapcraft-dirs-symlink/+merge/267176 - i think it is important to merge that asap to avoid problems with absolute directory links with the ubuntu plugin.
[14:01] <mterry> longsleep, yeah I did, thanks!  Good catch.  I approved it, but then noted that I realized that you weren't in the contributor agreement LP team.  Have you signed the contributor agreement?
[14:01] <longsleep> mterry: no i did not - can it be signed on compay level?
[14:02] <longsleep> company
[14:02] <mterry> longsleep, yes -- I gave a link in the MP
[14:02] <mterry> longsleep, www.ubuntu.com/legal/contributors
[14:02] <longsleep> oh i missed that sorry
[14:02] <mterry> longsleep, no worries, LP mail gets delayed or filtered weird sometimes  :)
[14:15] <longsleep> mterry: I gave the contributor agreement to my boss and he will eventually sign it. I think the symlink patch is trivial and you can just merge that. I will let you know when the agreement is signed. Let me know if you have any further comments to the debs plugin.
[14:16] <mterry> longsleep, I'm off tomorrow (and am switching teams shortly) -- you may want to poke mvo or rsalveti after today.  Just heads up  :)
[14:16] <mterry> longsleep, but understood re: symlink
[14:43] <longsleep> anyone got thoughts how to run multiple services from a single snap? I consider to use supervisord similar like it is used with Docker. What do you think?
[14:46] <ogra_> ARGH !
[14:46] <ogra_> (RaspberryPi2)ubuntu@localhost:~$ ifconfig
[14:46] <ogra_> enxb827eb04db1c Link encap:Ethernet  HWaddr b8:27:eb:04:db:1c
[14:46] <ogra_>           inet6 addr: fe80::ba27:ebff:fe04:db1c/64 Scope:Link
[14:46] <ogra_> yay for discoverable interface names
[14:47] <longsleep> lol
[14:47] <ogra_> but even worse :/
[14:47] <ogra_> (RaspberryPi2)ubuntu@localhost:~$ fw_printenv
[14:47] <ogra_> Warning: Bad CRC, using default environment
[14:47] <ogra_> damn
[14:48] <longsleep> 4 byte 5 byte problem?
[14:48] <longsleep> check the hexdump
[14:48] <ogra_> could be, not sure
[14:48] <ogra_> though no, the snappy code fails too
[14:49] <ogra_> and that should be safe against the header byte issues
[14:49] <longsleep> how did you create the file? saveenv?
[14:49] <ogra_> mkenvimage -s 131072 -o uboot.env uboot.env.in
[14:49] <longsleep> uh
[14:49] <ogra_> well, it works just fine in uboot
[14:50] <ogra_> and i see onyl 4 bytes in hexedit
[14:50] <longsleep> ogra_: try adding -r parameter to mkenvimage
[14:51] <ogra_> then uboot doesnt accept it anymore
[14:51] <longsleep> but the snappy tool loads it?
[14:51] <ogra_> though let me try again, might have been the other build
[14:51] <longsleep> then you have 4 bytes header if you did not add -r
[14:51] <longsleep> you have to use 5 bytes to make fw_* tools work
[14:52] <longsleep> (or change their config)
[14:52] <ogra_> reading uboot.env
[14:52] <ogra_> *** Warning - bad CRC, using default environment
[14:53] <longsleep> right, make sure you have #define CONFIG_ENV_SIZE                 (128 * 1024) and #define CONFIG_SYS_REDUNDAND_ENVIRONMENT in your u-boot config
[14:54] <longsleep> then you will have 5 bytes header and i guess it will just work
[14:54] <ogra_> ah, the latter was missing
[14:54] <ogra_> thanks !
[14:54] <longsleep> i hope that was it
[14:55] <joc_> could someone provide some assistance in checking whether an app we have snapped is running unconfined? (app is plainbox)
[14:55] <longsleep> ogra_: still trouble that the snappy tool fails to parse the env file with 4 byte though
[15:01] <ogra_> longsleep, thanks, that helped, looks all fine now
[15:02] <longsleep> ogra_: great
[15:06] <ogra_> so what the heck do i do with the NIC now :/
[15:07] <joc_> ogra_: ricmm might one you be able to help with the above please?
[15:08] <ogra_> joc_, sorry, i dont know how to determine that, perhaps from syslog
[15:08] <longsleep> ogra_: where does that name come from? Check /etc/udev/rules.d/70-persistent-net.rules i think it should define the name alias there
[15:09] <ogra_> well, where would that file come from on a readonly system ? :)
[15:09] <longsleep> that file is writable
[15:09] <ogra_> hmm, true
[15:09] <longsleep> if you do not have it, it explains the strange name
[15:10] <ogra_> right
[15:10] <ogra_> so why dont i have it :P
[15:10] <longsleep> now you are closer to the solution :D
[15:11] <longsleep> but it is good that you have a problem with that file, because i have one too :P
[15:11] <longsleep> (my nic is there twice with the same MAC)
[15:13] <longsleep> elopio: Hi, the symlink directory problem can be seen in openssl for example. I pull in the openssl debs file with my debs plugin.
[15:18] <joc_> hmm i'm seeing a lot of..
[15:18] <joc_> Aug  6 15:14:12 localhost kernel: [ 8857.835029] audit: type=1400 audit(1438874052.138:70): apparmor="DENIED" operation="open" profile="plainbox.sideload_plainbox_0.23.dev0" name="/proc/1162/fd/" pid=1162 comm="python3.4" requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000
[15:19] <elopio> longsleep: ok, let me see if I can reproduce it.
[15:19] <elopio> thanks for the patch btw.
[15:21] <ogra_> joc_, that looks like confined (and with wrong profile actually)
[15:23] <longsleep> elopio: sure, to reproduce just add openssl package to a snapcraft file using the ubuntu plugin
[15:23] <joc_> ogra_: what looks wrong about the profile?
[15:23] <ogra_> you get denials
[15:28] <sergiusens> ogra_: seb128 is input known to not work in a kvm for ubuntu personal?
[15:28] <ogra_> worked for me ... but i last tested a month ago or so
[15:29] <ogra_> (mouse input)
[15:29] <sergiusens> ogra_: yeah, thats what I recall too, not anymore it seems :-P
[15:42] <ogra_> pitti, bah ... i cant get the network on my rpi 15.04 imae up anymore ... what was the magic incarnation to force it to be called eth0 ?
[15:43] <pitti> ogra_: see /usr/share/doc/udev/README.Debian.gz
[15:43] <ogra_> hmpf
[15:43] <pitti> ogra_: either boot with net.ifnames=0, or touch /etc/udev/rules.d/80-net-setup-link.rules
[15:43] <pitti> whatever is better
[15:44] <ogra_> i cant really fiddle with udev rules, this is a released image
[15:44] <ogra_> ah, that was what i was lookin for
[15:44] <ogra_> kernel cmdline ;)
[15:44] <ogra_> (for this image i can only change the bootloader setup actively )
[15:47] <longsleep> ogra_: Starting with v197 systemd/udev will automatically assign predictable, stable network interface names for all local Ethernet, WLAN and WWAN interfaces. This is a departure from the traditional interface naming scheme ("eth0", "eth1", "wlan0", ...), but should fix real problems.
[15:47] <longsleep> ogra_: haha - "should fix real problems"
[15:47] <ogra_> http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/
[15:47] <ogra_> i got that in front of me :)
[15:48] <longsleep> interesting read
[15:48] <ogra_> doesnt mention the boot option at all !
[15:48] <longsleep> i wonder why the odroid does get named eth0
[15:48] <ogra_> oh, it does
[15:48] <longsleep> it does
[15:48] <ogra_> i just gave up reading to the end :P
[15:49] <longsleep> ogra_: why do you need to change it by the way, or why does the interface need to be named eth0?
[15:50] <ogra_> because the 15.04 image has /etc/network/interfaces.d/etc0 hardcoded by default
[15:50] <ogra_> *eth0
[15:50] <longsleep> ah
[15:50] <ogra_> that was only fixed in the rolling image
[15:51] <ogra_> (RaspberryPi2)ubuntu@localhost:~$ fw_printenv board
[15:51] <ogra_> board=rpi_2
[15:51] <ogra_> :D
[15:51] <longsleep> (ODROIDC)root@odroid:~# fw_printenv board
[15:51] <longsleep> ## Error: "board" not defined
[15:51] <longsleep> should i have that?
[15:51] <ogra_> (RaspberryPi2)ubuntu@localhost:~$ cat /proc/cpuinfo |grep erial
[15:51] <ogra_> Serial          : 000000008b04db1c
[15:51] <ogra_> \o/
[15:52] <ogra_> i doubt the odroid uses board= anywhere
[15:52] <ogra_> (i even doubt the rpi does :P but it is in teh default env)
[15:52] <longsleep> (ODROIDC)root@odroid:~# cat /proc/cpuinfo |grep Serial
[15:52] <longsleep> Serial		: 1b00000000000000
[15:52] <longsleep> i am not sure that serial of mine makes any sense
[15:53] <ogra_> well, nothing you need it for, do you ?
[15:53] <ogra_> rpi needs it for the codecs
[15:53] <longsleep> yes - well some snaps might want it
[15:53] <ogra_> mine here gets seeded from the binary blob bootloader
[15:55] <longsleep> mhm in u-boot i have a more complicated serial
[15:56] <ogra_> the rpi kernel accepts a cmdline option to set it
[15:56] <ogra_> perhaps the odroid has somethin similar
[15:57] <longsleep> no - i think the kernel has the means to read the serial directly
[15:58] <longsleep> what i do not understand why i get eth0 in my image
[15:58] <longsleep> shouldnt i have some other name as well ?
[16:01] <longsleep> well the serial is the same for the stock kernels from Hardkernel - at least its not my fault :)
[16:03] <longsleep> dpkg -l|grep systemd
[16:03] <longsleep> sorr
[16:03] <longsleep> y
[16:06] <ogra_> while you say systemd http://blog.darknedgy.net/technology/2015/08/05/0-androidinit/
[16:06] <ogra_> :D
[16:06] <ogra_> such an awesome trolling attempt :)
[16:06] <longsleep> ahaha
[16:06] <longsleep> nice
[16:22] <sergiusens> stgraber: hey, do you have an lxd snap for armhf?
[16:27] <cwayne> barry: hiya, was it you that was working on snaps based on .pex files?
[16:32] <cwayne>  barry: hiya, was it you that was working on snaps based on .pex files?
[16:32] <cwayne> (sorry if that repeated, my irc's been a bit wonky lately)
[16:33] <ogra_> ( RaspberryPi2)ubuntu@localhost:~$ cat /proc/device-tree/soc/i2c\@7e804000/status
[16:33] <ogra_> okay
[16:33] <ogra_> \o/
[16:48] <barry> cwayne: yep: http://www.wefearchange.org/2015/04/creating-python-snaps.html
[16:52] <cwayne_> barry, yeah, so I believe we'd basically followed that, and we seem to be having some confinement issues :/  getting the following denial: Aug  6 15:14:12 localhost kernel: [ 8857.835029] audit: type=1400 audit(1438874052.138:70): apparmor="DENIED" operation="open" profile="plainbox.sideload_plainbox_0.23.dev0" name="/proc/1162/fd/" pid=1162 comm="python3.4" requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000
[16:52] <cwayne_> was wondering if that looked familiar
[16:56] <ogra_> tyhicks might be able to help
[16:57] <ogra_> being our fake jdstrand this week :)
[16:58] <tyhicks> I can but I'll need a bit so I can finish something up
[16:58] <cwayne_> tyhicks, hiya :)  any advice ^  I think we have security_template: unconfined set, so i imagine we should have access
[16:58] <cwayne_> ah, ok
[17:20]  * ogra_ tries snappy update on the rpi and crosses fingers
[17:21] <ogra_> (using image 8 from 15.04 alpha)
[17:24] <elopio> mterry: longsleep: https://code.launchpad.net/~elopio/snapcraft/symlinks/+merge/267218
[17:24] <elopio> there are tests that check symlinks to directories. I think your bug is slightly different to that.
[17:25] <ogra_> yay, boots from b :D
[17:26]  * ogra_ tries rollback
[17:28] <barry> cwayne: yeah, that doesn't ring a bell.  must be a new constraint since i wrote that blog
[17:34] <tyhicks> cwayne_: ok, looking now
[17:38] <elopio> longsleep: these are your problematic links, right?
[17:38] <elopio> /tmp/stage/usr/lib/ssl/private
[17:38] <elopio> /tmp/stage/usr/lib/ssl/certs
[17:39] <elopio> um, no, those should work fine too.
[17:39] <elopio> I'm confused.
[17:41] <stgraber> sergiusens: sorta. I have one but it doesn't work. It's on my todo for next week to fix.
[17:55] <elopio> ahh, I get it.
[17:55] <elopio> the link destination must be an existing directory.
[17:55] <longsleep> elopio: yes
[17:55] <elopio> that's the bug in the original test.
[17:55] <longsleep> if it is existing (means not broken) then it ends up as dir
[17:57] <sergiusens> stgraber: thanks for the update!
[17:57] <longsleep> elopio: and for openssl these dirs probably always exist
[18:00] <longsleep> other question, snappy port conflicts - is the negotiable key actually implemented? How do i know which port i should listen?
[18:02] <cwayne_> tyhicks, the thing we're talking about is plainbox btw, (lp:checkbox, then the manifest is in checkbox/plainbox/Makefile)
[18:13] <ogra_> elopio, if you feel like http://people.canonical.com/~ogra/snappy/test/ has two rpi images, one built from stable 15.04 that i plan to release and one built from the 15.04 alpha channel with --revision=-1 for testing upgrade/rollback
[18:14] <ogra_> (not urgent, but i would like someone else but me test it additionally before i release ... as extra datapoint)
[18:14] <ogra_> kivi, ^^^
[18:14] <kivi> ogra_, ?
[18:14] <elopio> longsleep: sorry for being so dense. This should expose the bug and confirm your fix:
[18:14] <elopio> https://code.launchpad.net/~elopio/snapcraft/symlinks-2/+merge/267240
[18:15] <ogra_> kivi, err, ignore that ... tab mistmatch :)
[18:15] <ogra_> kyrofa, ^^^
[18:15] <elopio> ogra_: ok, I'll check after lunch.
[18:15] <elopio> ogra_: I thought updates were not psosible with rpi.
[18:15] <ogra_> i plan to release it tomorrow, so no hurry
[18:16] <ogra_> elopio, kernel/oem updates arent
[18:16] <ogra_> ubuntu-core wasnt until we fixed our uboot setup to use the uboot.env file ;)
[18:16] <ogra_> so now pi users can at least get rootfs updates :)
[18:16] <elopio> I see, that's nice.
[18:17] <ogra_> yep
[18:17] <ogra_> i2c should work too
[18:17] <ogra_> (not that we ship any tools to test it actually though :P )
[18:19] <elopio> woot for i2c.
[18:19] <elopio> now I don't want to have lunch.
[18:20] <ogra_> lol
[18:20] <ogra_> there is also a way to use pverlay DTBs but i need to document that ... it isnt straightdforward until sergio adds directory support for oem snaps to u-d-f
[18:21] <ogra_> *overlay
[18:21] <kivi> ogra_, Aww... I thought I was special...
[18:21]  * ogra_ hugs kivi 
[18:23] <kivi> !hugs
[18:23] <kivi> ubottu can't hug...
[18:41] <tyhicks> cwayne_: my apologies, too many distractions for me today
[18:42] <tyhicks> cwayne_: can you paste the relevant plainbox file in /var/lib/apparmor/profiles/ ?
[18:43] <tyhicks> cwayne_: there should be 1 per binary but it looks like you only have 1 binary
[19:34] <cwayne_> tyhicks, sorry, was afk for a bit: http://paste.ubuntu.com/12013969/
[19:35] <tyhicks> cwayne_: ah, that's definitely not the unconfined template
[19:35] <tyhicks> # Description: default AppArmor template
[19:40] <cwayne_> ah, so are we setting it incorrectly?
[19:41] <tyhicks> cwayne_: that's what I'm looking into
[19:42] <tyhicks> https://wiki.ubuntu.com/SecurityTeam/Specifications/SnappyConfinement
[19:43] <tyhicks> cwayne_: ^ that page suggests that security-template is specified underneath 'binaries:'
[19:43] <tyhicks> (all the examples show it underneath 'services:' but I think that should be interchangeable)
[19:57] <cwayne_> tyhicks, hm ok, i think that may be it then, will play around with it
[19:57] <cwayne_> tyhicks, thanks for taking a look!
[20:01] <tyhicks> cwayne_: no problem - let me know if you still have trouble and I can dig some more