[06:45] <dholbach> good morning
[08:10] <zyga> good morning
[09:49] <JamesTait> Good morning all!  Happy Thursday, and happy Get Out Your Guitar Day! 😃
[10:45] <diwic> hi, I'm having trouble with my mirror, can I redirect snapcraft 2.2 (when pulling) to use the main archive instead?
[10:46] <asac> whats the new SNAP_APP_DATA_PATH env?
[10:46] <asac> hm. guess i would need to upload hello world again
[10:47] <asac> didrocks: you made a central place for examples in github right?
[10:52] <diwic> okay, the mirror is up again now
[11:01] <noizer> Hi guys is nginx supported on snappy?
[11:01] <ogra_> Chipaca, tickle
[11:02] <ogra_> noizer, if you manage to package it, it is supported :)
[11:02] <noizer> nicee :D just i can't get it started xD
[11:03] <noizer> ogra_ where can we find the image for the dragonboard for snappy?
[11:03] <ogra_> are you not on the mailing list ?
[11:04] <noizer> oooh ok sorry i didn't have time to look at it the last couple of days
[11:04] <ogra_> http://people.canonical.com/~ogra/snappy/all-snaps/dragonboard/
[11:04] <ogra_> i mailed yesterday ;)
[11:04] <ogra_> (snappy-devel that is)
[11:05] <ogra_> as for ngnix ... i think the spreedbox guys use it in their spreedbox snap in the store
[11:05] <ogra_> no idea where their code is (and this is for 15.04 only iirc)
[11:05] <ogra_> you could install their snap on a 15.04 armhf install and inspect the installed snap though
[11:06] <noizer> ok thx ogra_
[11:40] <Chipaca> ogra_, tockle
[11:46] <sergiusens> asac, he has, but it seems bare bones now https://github.com/ubuntu-core/demos
[11:50] <ogra_> Chipaca, damn, i forgot what i wanted to ask you now :(
[11:51] <Chipaca> ogra_, \o/
[11:51] <ogra_> Chipaca, oooh ... ubuntu-snappy ftbfs on arm64 since a while again, i need to re-build images after fixing the resizing for dragonboard setups
[11:52] <ogra_> would be good if someone could take a look (and since mvo is away ...)
[11:52] <Chipaca> ogra_, ouch
[11:53] <Chipaca> i'll take a look in a bit
[11:53] <ogra_> thanks ... take your time though ... i'm still working on the resize fixes
[11:57] <asac> sergiusens: ok thats demos then... guess moving snappy-examples to 16.04 in its current place is worthwhile then still...
[12:07] <didrocks> asac: yeah, it needs sorting, and it quite empty, but it should be a central place
[12:07] <didrocks> the difference I see is that demos will be more complete real pieces
[12:07] <didrocks> and snapcraft should keep examples separated
[12:07] <didrocks> (as more "simple way of doing X")
[12:11] <zyga> noizer: try https://github.com/zyga/devtools/blob/master/ubuntu-image and tell me if it works for you
[12:12] <noizer> zyga what is that?
[12:13] <noizer> is that for the dragon board or is that for my nginx
[12:13] <joc__> ogra_: hi, i'm trying to boot the new all-snap dragonboard image, but i'm not seeing any output on hdmi. do you have any ideas on why not?
[12:14] <joc__> ogra_: same setup works ok with the install image from 96board website
[12:14] <ogra_> joc__, because the boot console still points to serial ... once it booted you should get a login prompt on hdmi though
[12:14] <ogra_> (i definitely do here)
[12:14] <ogra_> joc__, also regard the big fat warning in the readme
[12:14] <ogra_> (to not use a card bigger than 4GB)
[12:16] <joc__> ogra_: will it resize and reboot before the hdmi login prompt?
[12:17] <ogra_> it resizes before it mounts anything
[12:17] <ogra_> (so thats a yes)
[12:18] <ogra_> i'm hoping to have that bit fixed today :)
[12:18] <joc__> ok thank you, plars was saying that he had one successful boot before the resize would stop his board working so I was hoping for that - he may have been using serial though
[12:18] <sergiusens> kyrofa, when you get on, mind looking at https://launchpad.net/snapcraft/+milestone/2.2.1 ?
[12:20] <ogra_> joc__, i havent tried booting without the serial board attached, perhaps that blocks somewhere else though ...
[12:20]  * ogra_ gives that a try 
[12:24] <zyga> noizer: that's for building images easily
[12:24] <zyga> noizer: including dragonborad
[12:26] <noizer> zyga can I make then custom images for myself?
[12:27] <noizer> zyga ps I will first make my nginx up and running
[12:28] <noizer> Who will also join the clinic tommorow?
[12:28] <zyga> noizer: depends on what you mean by custom
[12:28] <zyga> noizer: anyway, have a look, the tool is _tiny_
[12:29] <noizer> zyga ok
[12:29] <ogra_> joc__, hmm, yeah, looks like it hangs somewhere at the bootloader if the serial board isnt attached ....
[12:30] <kyrofa> Good morning
[12:30] <ogra_> joc__, so for now, please attach the serial board, i'll research that
[12:31] <noizer> Good morning kyrofa
[12:32] <kyrofa> sergiusens, what should I be looking at here?
[12:39] <didrocks> good morning kyrofa!
[12:40] <sergiusens> kyrofa, the PRs :-)
[12:40] <kyrofa> Hey noizer, didrocks :)
[12:40]  * sergiusens needs to go to the bank, will bbl
[12:40] <kyrofa> sergiusens, ah, that's what I'm on now
[12:40] <kyrofa> sergiusens, alright, seeya!
[12:41] <noizer> ogra_ What is the name of the application of spreedbox?
[12:41] <ogra_> noizer, spreedbox :)
[12:41] <ogra_> (iirc )
[12:41] <noizer> kyrofa Hi do you know where I can get more information about netwerk listeners etc
[12:42] <ogra_> ppisati, did you ever try to boot without serial board attached ? seems it hangs at the bootloader
[12:42] <kyrofa> noizer, you mean what permissions are encompassed by it?
[12:42] <noizer> yes
[12:42] <ogra_> ppisati, dragonboard that is
[12:42] <ppisati> ogra_: uhm no, i never trie
[12:42] <ppisati> d
[12:42] <ppisati> let me tru
[12:42] <ppisati> let me try
[12:42] <noizer> kyrofa its for the rolling version. Or will it be explained tomorrow on the clinic?
[12:42] <ogra_> seems to not be kernel related ... i just did set console=tty0 and it still hangs
[12:44] <noizer> ogra_ I installed the 15.04 version on my Raspberry Pi 2 and tried to install spreedbox with the following command: sudo snappy install spreedbox but he dont find it
[12:45] <ogra_> ppisati, wow .... trying to set "stdin, stdout or stderr" at the uboot prompt with setenv actually complains
[12:46] <ogra_> i cant set it to serial,lcd
[12:46] <kyrofa> noizer, I'm not aware of any documentation on each one. jdstrand might know more
[12:48] <ppisati> ogra_: ## Error inserting "stdin" variable, errno=22
[12:48] <ppisati> :O
[12:48] <ogra_> yeah
[12:49] <ogra_> i know i can set that var on the rpi
[12:49] <ogra_> i did that multiple times
[12:49] <ppisati> ogra_: i was using https://github.com/hallor/u-boot.git / dragonboard-for-mainline-v2
[12:50] <ppisati> ogra_: i just did a git fetch, and there's a 'dragonboard-for-mainline-v3'
[12:50] <ppisati> let's see
[12:51] <ogra_> ah
[12:52] <ogra_> though i fear there is some build time hardcoding going on here
[12:56] <ppisati> ogra_: same story, doesn't boot and you can't set stdin&c
[12:57] <ogra_> yeah, i suspected that
[12:57] <ogra_> i just pinged in #96boards ... lets see, perhaps a known issue
[12:57] <Chipaca> ogra_, i can't find the build failure email, could you fwd it me?
[12:58] <ogra_> i have to dig it up
[12:58] <ogra_> Cghbtw, vivid failed too (on arm64, powerpc and ppc64el)
[12:59] <ogra_> https://launchpad.net/~snappy-dev/+archive/ubuntu/image/+packages
[12:59] <ogra_> arm64 xenial is here https://launchpad.net/~snappy-dev/+archive/ubuntu/image/+build/8962323
[13:01] <ogra_> => setenv stdout serial,lcd
[13:01] <ogra_> ## Error inserting "stdout" variable, errno=22
[13:01] <ogra_> => setenv stdout serial
[13:01] <ogra_> =>
[13:01] <ogra_> ppisati, ^^^
[13:01] <ogra_> so its the parameter
[13:01] <ogra_> just setting it to serial works
[13:01] <ppisati> oh ok
[13:01] <noizer> kyrofa did you already installed an apache in a snap?
[13:02] <ogra_> i guess we miss a build time option somewhere in uboot to enable lcd at all
[13:02] <kyrofa> noizer, indeed, yes
[13:02] <kyrofa> noizer, that owncloud snap uses apache
[13:02] <ogra_> though i still dont get why it hangs hard ... it shoudlnt
[13:03] <diwic> general question: if the app has some files in /usr/share/ - but with snappy, they're instead in $SNAP/share or $SNAP/usr/share, what's the smartest way to have the app (or one of its library dependencies) look there instead of in /usr/share ?
[13:03] <noizer> kyrofa owkay i will look for the yaml because I can't run nginx :s
[13:03] <kyrofa> noizer, how come?
[13:03] <kyrofa> noizer, I can share my plugin with you if you like
[13:04] <noizer> yea i would like that maybe i can get some info for my nginx from there
[13:05] <kyrofa> noizer, alright. It's still a work-in-progress, no decent documentation or anything, but it works: https://github.com/kyrofa/owncloud-snap/blob/apache_plugin/parts/plugins/x_apache.py
[13:05] <ogra_> ppisati, ah, seems we just need to set CONFIG_LCD in dragonboard.h
[13:06] <noizer> kyrofa You didn't installed it with stage-packages? why?
[13:06] <kyrofa> noizer, you give it a source (like any other plugin) and it'll unpack it into htdocs. You also specify the modules you want built/enabled, and you can specify some sections of the config and a startup script if you want
[13:07] <kyrofa> noizer, because debian packaging uses a different apache layout than the standard, and it's all setup in a post-inst
[13:07] <kyrofa> postinst, rather
[13:07] <noizer> kyrofa ok.
[13:07] <kyrofa> noizer, since Snapcraft only unpacks debs, that stuff never gets run
[13:08] <kyrofa> noizer, so it led to a lot of hackery. Not to mention this way I could tune it exactly the way I wanted and get it down to a few megs
[13:08] <noizer> so nginx won't run with the deb package?
[13:08] <kyrofa> noizer, it might, it might not. Depends on how it's packaged
[13:08] <ppisati> ogra_: let m,e try that
[13:09] <kyrofa> noizer, that was the first lesson I learned making that massive snap: debian packages only get you so far in snappy
[13:09] <noizer> ok so maybe the best way is from source code.
[13:09] <kyrofa> noizer, indeed
[13:11] <noizer> kyrofa, ok thats a lot harder then using a deb package :p
[13:11] <noizer> kyrofa lets give it a try
[13:11] <kyrofa> noizer, yeah it's a bit complex. Apache was particularly painful because it writes its prefix _everywhere_, config files, scripts, etc
[13:12] <noizer> hopefully is nginx not so painful :p
[13:12] <ppisati> ogra_: nope, it doesn't compile with only CONFIG_LCD
[13:12] <kyrofa> noizer, heh, good luck
[13:12] <noizer> kyrofa thx. if I succeed maybe then i will post an easy example of it for other users of Snappy
[13:13] <ogra_> ppisati, how does it fail ?
[13:13] <kyrofa> noizer, the way snapcraft works requires software that can be configured and built in one location, and run in a complete different location, with different paths. Some software works fine that way. Some though, like apache, do not
[13:13] <ppisati> ogra_: http://pastebin.ubuntu.com/15015948/
[13:14] <ppisati> ogra_: CONFIG_LCD is just the machine independent code, every hw needs some specific bits to make it work
[13:14] <ogra_> crap
[13:14] <ppisati> ogra_: we should talk to guy who ported uboot to this board
[13:15] <ogra_> ppisati, thats hallor in #96boards i think
[13:18] <noizer> kyrofa is that not a good idea to use docker in the snap. Because docker have already a build with nginx?
[13:19] <kyrofa> noizer, hmm... I'm not sure I understand
[13:19] <noizer> Ok you know docker? So when I'm installing docker and on the docker side you can install nginx easily (normally)
[13:20] <kyrofa> noizer, alright, I'm with you so far
[13:21] <noizer> So when im installing nginx on docker. into my snap then can I maybe refer to my data in my nginx.conf?
[13:22] <kyrofa> noizer, that's where you lose me. How does docker relate to your snap?
[13:22] <noizer> hmm i don't know is it possible to use docker and nginx into my snap?
[13:22] <noizer> kyrofa i didn't use docker before so I'm really noob at docker
[13:24] <kyrofa> noizer, okay so you're thinking "It's easy to put nginx on docker. It's hard to put nginx into the snap. So can I get docker into my snap instead and put nginx on there?"
[13:24] <kyrofa> noizer, sound about right?
[13:24] <noizer> kyrofa yes :p
[13:24] <kyrofa> noizer, I know a docker framework exists on 15.04, though I'm not sure what the plans are for 16.04
[13:25] <noizer> oooh ok xD i will do it the hard way and I think the best way then :D
[13:25] <kyrofa> noizer, you'd have to depend on the docker framework and make your .snap that way. I've not done that, though there are people here that have
[13:26] <kyrofa> noizer, yeah, there's non-negligible overhead associated with things like docker. You don't want it if you don't need it
[13:27] <noizer> kyrofa ok. I will you update on my status of nginx. If you want that :D
[13:27] <kyrofa> noizer, sure :) . It may not be as bad as you think!
[13:28] <noizer> kyrofa ok hopefully xD
[13:30] <kyrofa> noizer, I strongly suggest you experiment with it outside of snapcraft until you understand the build process
[13:32] <noizer> kyrofa
[13:32] <noizer> ok i will do that first
[13:33] <ogra_> ppisati, try bui9lding with CONFIG_USB_KEYBOARD (and perhaps with CONFIG_SYS_USB_EVENT_POLL_VIA_CONTROL_EP)
[13:36] <ppisati> ogra_: compiling...
[13:40] <ppisati> dragonboard410c => setenv stdin serial,usbkbd
[13:40] <ppisati> ## Error inserting "stdin" variable, errno=22
[13:40] <ppisati> ogra_: ^
[13:40] <ogra_> bah
[13:40] <ppisati> with these:
[13:40] <ogra_> ok, i gues si have to disable bootdelay then
[13:40] <ppisati> +#define CONFIG_USB_KEYBOARD
[13:40] <ppisati> +#define CONFIG_SYS_STDIO_DEREGISTER
[13:40] <ppisati> ogra_: you mentioned something else before
[13:40] <ppisati> ogra_: setenv stdin ...
[13:41] <ogra_> i only know serial.usbkbd
[13:41] <ogra_> err ... comma indeed
[13:41] <ppisati> ogra_: oh ok
[13:42]  * ogra_ tries the evil way
[13:42] <ogra_> ubuntu@localhost:~$ sudo fw_setenv stdin serial,usbkbd
[13:42] <ogra_> ubuntu@localhost:~$
[13:42] <ogra_> muhahaha !
[13:42] <ppisati> oh
[13:42] <ppisati> did it work?
[13:42] <ogra_> ubuntu@localhost:~$ fw_printenv |grep stdin
[13:42] <ogra_> stdin=serial,usbkbd
[13:42] <ogra_> ubuntu@localhost:~$
[13:42] <ogra_> it sets it
[13:43] <ogra_> weather it will boot is another question :)
[13:43] <ogra_> reading uboot.env
[13:43] <ogra_> In:    serial
[13:43] <ogra_> Out:   serial
[13:43] <ogra_> nope
[13:43] <ogra_> ignores it
[13:43] <ppisati> doh :(
[13:44] <ogra_> Environment size: 4424/131067 bytes
[13:44] <ogra_> => printenv stdin
[13:44] <ogra_> stdin=serial
[13:44] <ogra_> wow
[13:44] <ogra_> it even unsets it during boot
[13:44] <ogra_> (it accepted my bootdelay change)
[13:45] <ogra_> well, people wanting to debug the bootloader can always set bootdelay from the running system, so i guess i'll default to bootdelay=0
[13:46] <ppisati> ogra_: k, i sent an email to the uboot guy, just in case (you are in cc:)
[13:46] <ogra_> thanks
[13:47] <ogra_> he already said there might be a bug in hserial
[13:48] <ogra_> joc__, thanks a lot for bringing that up !!!
[13:48] <ogra_> (no dev would ever have catched it since we all boot with serial board attached )
[13:55] <joc__> ogra_: np, thanks for the info
[14:04] <jdstrand> noizer: re documentation, install snappy-debug then do 'snappy-debug list -i'
[14:04] <jdstrand> noizer: the 16.04 names will be changing based on skills work though
[14:05] <jdstrand> hopefully those will be settled within the next couple weeks
[14:13] <kyrofa> noizer, questions over here please :)
[14:15] <noizer> jdstrand ok
[14:16] <Chipaca> ogra_, https://launchpad.net/~snappy-dev/+archive/ubuntu/image/+build/8962323
[14:19] <Chipaca> ogra_, the good news is, I did nothing more than rebuild
[14:19] <Chipaca> ogra_, but that is also the bad news
[14:19] <Chipaca> ogra_, there are tests in there i'm not proud of :-(
[14:19] <Chipaca> that depend on the test starting and ending the same minute
[14:46] <ogra_> Chipaca, well, at least we have a binary now to make the image build, thanks a lot !
[14:46] <d2388> Hi I have a question about Ubuntu as an OS
[14:58] <kyrofa> sergiusens, FYI, as soon as netbase is in an all-snaps image I'll make MOOS an example. Until then, if you're curious: https://rainveiltech.com/posts/that-s-one-snappy-moos
[15:00] <sergiusens> kyrofa, nice
[15:00] <ogra_> kyrofa, oh, thanks for the reminder :P
[15:00]  * ogra_ hacks the seeds
[15:00] <kyrofa> ogra_, ha! Thanks again on that :)
[15:01] <sergiusens> ogra_, can you upload new OS images? or is it only mvo? or does slangasek have the priv as well?
[15:01]  * sergiusens heads back home
[15:01] <kyrofa> sergiusens, walk safely. Look both ways
[15:02] <ogra_> sergiusens, i dont know what account mvo used for them ... i'd rather have hiom do it
[15:03] <elopio> fgimenez: why do we have offline slaves? Did I break something?
[15:03] <ogra_> kyrofa, seeded and pushed, next image should have it
[15:04]  * kyrofa hugs ogra_
[15:04] <fgimenez> elopio, i have no idea, was waiting to ask you :)
[15:04] <elopio> I don't know. Didn't notice yesterday.
[15:05] <fgimenez> i'll remove them
[15:08] <kyrofa> Hey didrocks I wanted to ping you regarding the owncloud snap. Is that in a good state for demo? We still have some time to fix things if necessary
[15:08] <ogra_> kyrofa, an arm64 buiold would be so awesome :)
[15:08] <noizer> kyrofa where can i see the deamons running in a snap?
[15:08] <kyrofa> ogra_, ha! I'm working on it, the dragon keeps dying
[15:09] <ogra_> noizer, snappy service status <packagename>
[15:09] <ogra_> kyrofa, even with the new image ?
[15:09] <kyrofa> ogra_, ah, I haven't tried yet. I'll get back to you
[15:09] <ogra_> great
[15:11] <didrocks> kyrofa: I guess it's good enough for the demo, I played with it and didn't spot anything bad :)
[15:12] <didrocks> thanks for pushing this btw!
[15:12] <kyrofa> didrocks, you GUESS? Psshh
[15:12] <kyrofa> didrocks, and no problem, it's nice to get it some exercise
[15:13] <didrocks> kyrofa: I still think (but maybe once 16.04 is out) we need to centralize all those "demos" in the git repo
[15:13] <didrocks> but I tend to wait for 16.04 for now (at least, that it starts to stabilize with snapcraft 2)
[15:13] <didrocks> so I hope for end of March/early April :)
[15:13] <kyrofa> didrocks, yeah it's too much of a moving target right now
[15:14] <didrocks> seen that :p
[15:14] <kyrofa> ogra_, nooo, I don't have a 4GB SD card
[15:14] <kyrofa> didrocks, heh, yeah I bet you have :P
[15:14] <ogra_> kyrofa, you can resize the writable partition before first boot
[15:14] <ogra_> just use gparted
[15:15] <noizer> ogra_ can I see why it is inactive my service?
[15:15] <ogra_> or gnome-disks
[15:15] <ogra_> noizer, snappy service logs <packagename> ?
[15:15] <kyrofa> ogra_, your README leads me to believe there will be nothing to resize?
[15:15] <ogra_> or something along these lines
[15:15] <kyrofa> noizer, the only reason it would be down is if it crashed. Check the syslog for reasons (or your application's log, if any)
[15:16] <kyrofa> noizer, or yeah, snappy service logs
[15:16] <ogra_> kyrofa, dd to a big SD ... then re-plug and open gnome-disks ... pick the writable partition and resize it to occupy all free space ... then  the resite on boot wont kick in
[15:16] <kyrofa> I keep forgetting about that command
[15:16] <ogra_> *resize
[15:16] <kyrofa> ogra_, ahhh, okay
[15:17] <ogra_> it checks for more than 10% free space on the SD ... if thats not there it wont run
[15:17] <kyrofa> ogra_, kinda neat that it's there at all, honestly
[15:17] <ogra_> yeah, i just wish i had picked the right partition tool from the start
[15:18] <ogra_> (who would have thuoght we ever have u-boot devices with GPT partitions !)
[15:18] <kyrofa> ogra_, it gets ingrained and it's difficult to switch, eh?
[15:18] <noizer> ogra_ i got no error in my syslog or in my log of the service
[15:18] <ogra_> well, it needs a bunch of code changes ... it is just annoying to test since you need to dd all images for all devices to SD multiple times
[15:19] <ogra_> enervingly time consuming
[15:19] <kyrofa> ogra_, ah, sure
[15:30]  * zyga reflashed his BBBs
[15:35] <elopio> fgimenez: hangout.
[15:36] <fgimenez> elopio, yep omw
[15:56] <kyrofa> ogra_, do I need to do anything fancy with these switches on the dragon to boot?
[15:57] <ogra_> you need to turn the SD one on
[15:57] <ogra_> and leave all others off
[16:03] <asac> could it be taht running udf as root (not sudo)... is not working at all?
[16:04] <asac> i get weird error that it cannot create /root/.cache etc.
[16:07] <kyrofa> noizer, by the way, if you're curious about the actual apparmor snippets relating to each capability, check out /usr/share/apparmor/easyprof/policygroups/ubuntu-core/16.04/
[16:09] <noizer> okey i see
[16:09] <noizer> ps i tried to run the standard nginx ( installed with stage-packages) and it do not work at all :s
[16:09] <kyrofa> noizer, /usr/share/seccomp/policygroups/ubuntu-core/16.04 for seccomp filters
[16:10] <ogra_> asac, i never ran it as root, might interfere on some levels
[16:10] <kyrofa> noizer, yeah, not surprising
[16:10] <noizer> kyrofa i can see it start but not that it crashes in the logs :s
[16:11] <kyrofa> ogra_, gnome-disk is just showing be a bunch of unknown partitions. I'm in trusty... too old?
[16:11] <kyrofa> s/showing be/showing me/
[16:11] <noizer> kyrofa so i need to compile it myself
[16:11] <ogra_> kyrofa, you should see at least two usable ones (the last two)
[16:11] <noizer> but so I can see it says make serve
[16:11] <noizer> to build it
[16:11] <kyrofa> ogra_, nope... everything is unknown
[16:12] <ogra_> kyrofa, the rest will most likely still be unknown today, they are part of the bootloader and use very specific IDs
[16:12] <ogra_> thats weird
[16:12] <kyrofa> noizer, maybe. You might be able to get away with some sed magic
[16:12] <ogra_> the last two are just vfat and ext4
[16:12] <ogra_> with no special signature
[16:13] <kyrofa> gparted sees that, but then gets super confused when I try to resize the ext4 saying the partition doesn't exist
[16:13] <ogra_> hmpf
[16:13] <kyrofa> gnome-disk doesn't actually show the last two at all, now that I look closer
[16:13] <kyrofa> ogra_, just 1-7
[16:13] <noizer> kyrofa sed magic?
[16:13] <ogra_> well, you can always use gdisk on the cmdline
[16:14] <kyrofa> ogra_, ah, I didn't actually know about gdisk. Tried using fdisk to obvious dispair
[16:14] <ogra_> yeah, the old tools all kind of lack if it comes to GPT
[16:15] <kyrofa> noizer, if for example it's dying because it's trying to save logs in a non-writable place, you can try copying a new config file over the top that uses the right paths
[16:15] <asac> hmmm. running bluetoothctl hangs my pi2 ... or at least my ssh session goes down
[16:16] <zyga> woot, all boards operational :)
[16:17] <noizer> ok i will do that first
[16:20] <zyga> asac: maybe get beefier psu
[16:20] <zyga> asac: I'm using a big 5-port 10A supply
[16:20] <zyga> asac: works great for a small farm
[16:21] <asac> hmm. you say this could be power?
[16:21] <asac> it happens even without a dongle attached
[16:21] <zyga> hmmmmm
[16:22] <ogra_> asac, anything in syslog or dmesg ?
[16:23] <asac> ogra_: not really
[16:23] <asac> let me see after this reboot
[16:23] <asac> the last two times nothing was written
[16:23] <asac> even though i had entries from yesterday in there
[16:23] <asac> so something got persistet, but not these boots it seems
[16:23] <ogra_> also try to use serial to make sure its only ssh/network that goes down
[16:24] <asac> yeah it seems to really not persist the syslog
[16:24] <ogra_> culd be your USB hub dying ... (since everything on the rpi is USB)
[16:24] <asac> if it dowenst shut down cleanly
[16:24] <asac> guess thats a bit of a bad feature :)
[16:24] <asac> ogra_: could be, but i dont attach anything and just run bluetoothctl
[16:24] <asac> and it dies
[16:24] <asac> my pi2 is in an orange box
[16:24] <asac> cant connect serial
[16:25] <asac> if you have a pi2 with 16.04 just install bluez5
[16:25] <ogra_> asac, you have a USB NIC ...
[16:25] <asac> anywsay, i connectd it now to strong USB power supply
[16:25] <asac> let me try again
[16:25] <asac> nope same... with 4A
[16:25] <ogra_> yeh
[16:25] <asac> just dead the second i run bluetoothctl
[16:25] <asac> without attaching any dongle and nothing
[16:25] <asac> k... llet me try to find my other pi2 where i can make a serial avail
[16:26] <asac> i think i had another one
[16:26] <asac> ogra_: which pins do i connect the ttl to?
[16:27] <ogra_> ugh ... i dont have my rpi nearby
[16:28] <ogra_> asac, http://workshop.raspberrypiaustralia.com/assets/console-cable-connections.jpg
[16:28] <ogra_> (you dont need VCC usually)
[16:29] <asac> yay, i like raw boards with serial console :OP
[16:29] <asac> works
[16:29] <asac> lets see what happens there
[16:29] <asac> they look so nice on the desk
[16:29] <ogra_> yeah, my desk is plastered with them :)
[16:30] <asac> right, but its your life style to have raw boards on your desk ... i am trying to get to a clean desk (not succeeded yet)
[16:30] <asac> hehe
[16:30] <ogra_> my desk is clean !
[16:30] <ogra_> (everything around it is a mess admittedly)
[16:31] <asac> ok first thing i notice is: http://paste.ubuntu.com/15017149/
[16:31] <asac> lol
[16:31] <asac> so thats probably not the best indicuation of successful bluez5 usage
[16:31] <ogra_> ouch
[16:31] <ogra_> yeah
[16:31] <asac> yeah
[16:31] <asac> dead
[16:31] <ogra_> morphis, ^^
[16:31] <asac> console dead when running bluetoothctl
[16:31] <asac> no oops
[16:31] <asac> nothing
[16:31] <asac> end of life
[16:31] <asac> bang
[16:31] <asac> guess this is bogus stuff
[16:31] <ogra_> thts with a USB dongle ?
[16:31] <asac> no
[16:32] <asac> nothign attached but serial, power through USB and LAN cable
[16:32] <ogra_> is tere any BT onboard on the rpi ?
[16:32] <asac> i dont think so
[16:32] <ogra_> right, so why would it start then :)
[16:32] <sergiusens> kyrofa, elopio here's a weird one https://github.com/ubuntu-core/snapcraft/pull/316
[16:32] <asac> ogra_: what would start? bluez5?
[16:32] <ogra_> yeah
[16:32] <asac> i think its a deamon that should just there
[16:32] <asac> until something gets plugged in
[16:32] <ogra_> if there isnt a BT device there is nothing to attch to
[16:32] <asac> also how can bluetoothctl binary just crash everything
[16:33] <asac> sure, but its a service
[16:33] <asac> no?
[16:33] <ogra_> ask the kernel :)
[16:33] <asac> the kernel doesnt even spit out anything before it dies
[16:33] <asac> ppisati: ^^
[16:33] <asac> 16.04 pi2 ... install bluez5 and run bluetoothctl
[16:33] <asac> it will be dead without oops
[16:33] <ogra_> do you get the obex messages too if you have a BT dongle pluggged in ?
[16:33] <asac> ok let me reboot and plug it in
[16:34] <asac> well, powercycle ... rather than reboot :)
[16:34] <ogra_> yeah
[16:34] <ppisati> asac: but is the board dead? led blinking? can you still ping it? ssh-in?
[16:35] <ogra_> ssh dies
[16:35] <plars> noise][: I think I hit the same issue as you were discussing yesterday, but I didn't understand what it was until now. I specified the release for my product as "rolling" instead of "rolling-core". Is there an easy way for me to edit the product?
[16:35] <asac> ppisati: ssh is dead ... thats how i noticed and connected serial
[16:35] <asac> serial also dead
[16:35] <asac> i will check LEDs next time
[16:35] <asac> give me 1 sec
[16:35] <ogra_> yeah, we have heartbeat on by default
[16:35] <ogra_> leds should tell you something
[16:35] <asac> obey is not starting
[16:35] <asac> even with dongle
[16:36] <asac> bluez still fails even with dongle plugged while booting
[16:36] <ogra_> sounds broken :)
[16:36] <ogra_> do you see the right driver being loaded on plug/unplug ?
[16:36] <ogra_> (in dmesg)
[16:36] <asac> ok so right now the led is red
[16:36] <asac> i can still use console
[16:36] <asac> i am typuing bluetoothctl again
[16:36] <asac> (nothing is blinking though even though it works)
[16:37] <asac> the LED is still red
[16:37] <ogra_> hmm, i thought the rpi kernel had heartbeat on by default
[16:37] <asac> no blinks
[16:37] <ppisati> me too
[16:37] <ogra_> thast 16.04 ?
[16:37] <asac> yeah
[16:37] <ppisati> 4.4 kernel?
[16:37] <asac> ok let me reboot from scratch and try the pinging of iface
[16:37] <ogra_> can you ckeck the kernel version with uname ?
[16:37] <asac> can also do that
[16:37] <asac> [    0.000000] Linux version 4.3.0-1006-raspi2 (buildd@kishi13) (gcc version 5.3.1 20151206 (Ubuntu/Linaro 5.3.1-2ubuntu2) ) #6-Ubuntu SMP Tue D)
[16:38] <asac> ppisati: ogra_:^
[16:38] <asac> seems disk io makes the LED blink
[16:38] <asac> its blinking right now
[16:38] <asac> while booting
[16:38] <ppisati> asac: so i just start bluetoothctl and the board dies, correct?
[16:38] <asac> yeah
[16:38] <asac> just do that
[16:38] <asac> dead
[16:38] <asac> no dongle needed
[16:38] <ppisati> ok, let me try
[16:38] <asac> end of day :P
[16:38] <asac> lol
[16:38] <ppisati> end of life :)
[16:39] <plars> noise][: otherwise I can just delete it, just checking first if there's a better way
[16:39] <asac> yeah, wanted to write that, but then i can still  powercycle, so i think its more like a day... :)
[16:39] <asac> but guess every boot is a life
[16:39] <asac> then its fine
[16:40] <asac> guess i could also have fun and bring another board to my desk ... my good old bbb
[16:40] <ogra_> really depends on the game though
[16:43] <ppisati> asac: so, i just tested on a 4.2 raspi system
[16:43] <ppisati> asac: if i start blueoothctl, it takes over the tty and i loose it
[16:43] <ppisati> asac: e.g. if i'm in a ssh connection, it freeze
[16:43] <ppisati> asac: but the board is ok
[16:43] <ppisati> asac: serial works, and the heartbeat led keeps beating
[16:44] <ppisati> asac: indeed if from serial i kill the bluetoothctl process, i'm back in business
[16:44] <asac> oh... so it might also take the tty on our serial for snappy?
[16:44] <asac> let me ping to test
[16:44] <ppisati> asac: actually even the ssh is still up
[16:44] <ppisati> asac: this on a 4.2 kernel
[16:45] <ppisati> i shall try with a 4.3
[16:45] <ppisati> just in case
[16:45] <ppisati> asac: i guess so
[16:45] <ppisati> oh, it might a bug tough
[16:45] <ppisati> i'm no ruling out that
[16:45] <ppisati> just that the board is alive, use ssh and then try with the serial
[16:45] <asac> ping still works indeed
[16:45] <asac> but my serial is down too
[16:45] <ppisati> ssh in, bluetoothctl over ssh and it freeze
[16:46] <ppisati> than try the serial
[16:46] <ppisati> system is ok
[16:46] <ppisati> *then
[16:46] <ogra_> asac, try changing the kernel commandline
[16:46] <ogra_> and drop the console=tty0
[16:46] <ogra_> (with fw_printenv and fw_setenv)
[16:46]  * ppisati tries with a 4.3 kernel, you never know
[16:47] <ogra_> snappy has two console= options on the cmdline
[16:47] <asac> ogra_: from userspace? fw_printenv is not there in uboot
[16:47] <ogra_> asac, indeed from userspace
[16:47] <ogra_> in uboot just use setenv and saveenv
[16:48] <asac> yeah only that uboot dies when running printenv alone :( ... doesnt return to prompt after its finished
[16:48] <asac> let me boot this thing to linux then
[16:49] <ogra_> huh ?
[16:49] <ogra_> definitely works here
[16:49] <asac> ogra_: isnt that somewhere in a file in /boot?
[16:49] <asac> that i can edit rather than running fw_ ?
[16:49] <ogra_> no
[16:49] <ogra_> it is a file in system-boot but it is binary
[16:50] <asac> ogra_: so i run fw_setenv 'mmcargs=setenv bootargs "${args} console=ttyAMA0 root=${mmcroot}"'
[16:50] <asac> ?
[16:51] <asac> that wiped the whole mmcargs line :(
[16:51] <ogra_> yeah, wrong quoting
[16:51]  * asac hopes he can fix it before reboot
[16:52] <ogra_> fw_setenv mmcargs 'setenv bootargs "${args} console=ttyAMA0 root=${mmcroot}"'
[16:52] <asac> ok
[16:52] <ogra_> and check with fw_printenv
[16:53] <asac> ok that looks better
[16:53]  * asac crosses fingers and reboots
[16:54] <asac> ogra_: didnt help
[16:54] <asac> seems to highjack all ttys
[16:55] <asac> that i have
[16:55] <asac> what a beast
[16:55] <ogra_> well, was worth a try
[16:56] <asac> so what now? guess coffee and break
[16:57] <ogra_> yeh, and a cigraette
[16:57] <ogra_> +r
[16:57] <kyrofa> ogra_, gdisk won't let me create a partition of type FFFF... know any workarounds?
[16:58] <ogra_> kyrofa, the type deosnt matter
[16:58] <kyrofa> ogra_, oh, okay
[16:58] <ogra_> not rfor the last two
[16:58] <genii> mmm coffee
[16:58] <ogra_> just make sure to not touch the first ones
[16:58] <elopio> fgimenez: is it safe to restart a slave?
[16:59] <elopio> ah nevermind, It's not needed :D
[16:59] <fgimenez> elopio, sure, docker restart will give you a pristine one
[16:59] <fgimenez> elopio, ok :)
[17:00] <elopio> we are missing update-ca-certificates -f in the slaves
[17:00] <ogra_> uncertified slavery !
[17:01] <elopio> all our papers are in order. This is legal.
[17:01] <ogra_> hah
[17:01] <elopio> fgimenez: should I put it in the swarm-slave?
[17:02]  * ogra_ sends khaleesi and the dragons to check that 
[17:03] <elopio> ogra_: this totally badass scary guy will be waiting for you: https://wiki.jenkins-ci.org/download/attachments/2916393/logo.png?version=1&modificationDate=1302753947000
[17:03] <fgimenez> elopio, mm i thought this was done in an ancestor of that images, let me check
[17:03] <ogra_> OMG !
[17:03] <ogra_> he will treat us with extensive friendlyness !
[17:04] <fgimenez> elopio, ogra_ careful sometimes he gets angry https://raw.githubusercontent.com/jenkinsci/jenkins/master/war/src/main/webapp/images/rage.png
[17:04] <elopio> lol, that should be our default logo.
[17:04] <ogra_> hah, i picked up a sticker of that at SCaLE :)
[17:05] <fgimenez> if you manage to get a java exception on the server you'll see him like that :)
[17:06] <elopio> challenge accepted!
[17:08] <fgimenez> elopio, it's done only on the master https://github.com/ubuntu-core/jenkins-ubuntu/blob/master/Dockerfile#L5
[17:09] <asac> 2016-02-04T21:26:39.484191Z ubuntu-core-launcher cp: cannot create regular file
[17:09] <asac> ��‘/etc/dbus-1/system.d/bluez5_bluez_5.37-1-armhf.conf��’: Permission denied
[17:09] <asac> think thats not good
[17:09] <ogra_> yeah, your UTF-8 is broken :P
[17:10] <asac> well, the fac that it cannot put that stuff there
[17:10] <asac> is ther eason why bluez is not activated
[17:10] <asac>   # Allow replacing our dbus policy configuration file until
[17:10] <asac>   # snappy has a better way to do this.
[17:10] <asac>   /etc/dbus-1/system.d/bluez_* rw,
[17:10] <asac> is in apprmor profile
[17:10] <ogra_> yes,, it has a hacked up sercurity template iirc
[17:10] <elopio> fgimenez: I know. What I'm not sure is if I should add it to the two slaves, or to the swarm.
[17:10] <asac> ogra_: right, which seems to not work well
[17:11] <Guest91403> Hey I just installed snappy on my  RPi and then instakk thexkcd-webserver.  How do I start xkcd?
[17:11] <ogra_> asac, probably because snappy moved a lot since the package was uploaded
[17:11] <ogra_> asac, especially the security/skills stuff
[17:11] <ogra_> Guest91403, it starts automatically
[17:11] <asac> jdstrand: did we drop support for the old way to do profiles now?
[17:12]  * ogra_ forgot on which port ... might be 8080
[17:12] <Guest91403> Thats what I read online so how do I view it then?
[17:12] <asac> i am on ubuntu-core         2016-02-03 16.04.0-7.armhf canonical
[17:12] <ogra_> Guest91403, point a browser at your rpi
[17:12] <Guest91403> okay
[17:13] <ogra_> http://webdm.local:8080/
[17:13] <ogra_> that might work
[17:13] <asac> ok i manually copied the dbus conf there now
[17:13] <asac> ets see
[17:14] <whizzo> Hi all, I have a snap for both the amd64 and armhf architectures that needs a Java JRE. It looks like there's a "jdk" part but it's unclear what plugin it should use.
[17:15] <asac> whizzo: java plugin or maven plugin should do the trick in snapcraft
[17:15] <kyrofa> ogra_, no that's webdm
[17:15] <kyrofa> Guest91403, xkcd is just on port 80
[17:15] <ogra_> kyrofa, on 8080 ?
[17:15] <kyrofa> ogra_, yeah
[17:15] <asac> whizzo: err jdk plugin
[17:15] <ogra_> since when
[17:15] <asac> or maven or ant
[17:16] <kyrofa> ogra_, no
[17:16] <ogra_> it used to be 4200
[17:16] <kyrofa> ogra_, 4200 or something, sorry
[17:16] <ogra_> yeah :)
[17:16] <kyrofa> ogra_, 8080 isn't anything unless you're using kvm
[17:16] <asac> 4200 isa webdm
[17:16] <asac> you can go to the app there and there is a link to its real port
[17:16] <kyrofa> ogra_, and forwarded 80 to 8080
[17:16] <ogra_> kyrofa, right, i wasnt sure if the xkcd demo runs on 80 or 8080
[17:16] <whizzo> asac, when I try part "jdk" with plugin "jdk" I get an error that 'source' is a required property
[17:16] <kyrofa> ogra_, yeah, just 80
[17:16] <ogra_> k
[17:16] <kyrofa> ogra_, last time I tried anyway
[17:17] <asac> whizzo: yeah you need to do something there
[17:17] <whizzo> asac, does it matter what?
[17:17] <ogra_> source: .
[17:17] <ogra_> that might work
[17:18] <asac> whizzo: try to just specify .
[17:18] <asac> its a bug
[17:18] <ogra_> (it works with the python plugin ... )
[17:18] <asac> not sure if jdk plugin is suposed to be use standalone
[17:18] <asac> if you use ant or mavent as build system just go for thse directly
[17:19] <asac> ogra_: so after putting the dbus file in blace, bluez and obex daemons are happy
[17:19] <asac> but bluetoothctl still highjacks everything
[17:19] <ogra_> heh
[17:19] <whizzo> asac, it seems to be building with that change.
[17:19] <asac> man what nasty stuyff does this thing do
[17:19] <ogra_> yeah
[17:19] <asac> whizzo: cool. lets hope it also works :)
[17:19] <whizzo> asac, thanks for the help... i'll see if it actually works properly
[17:19] <asac> whizzo: what build system are you using?
[17:20]  * asac wonders if there is anything beyond ant and maven used in java world
[17:20] <whizzo> asac: I'm using maven but my maven build is above snapcraft -- it builds for several platforms.
[17:20] <asac> ic so you need multi arch/cross feature
[17:21] <asac> whizzo: so you have JNI bindings?
[17:21] <whizzo> asac: the maven build lays down the directory that I run snapcraft against
[17:21] <asac> i think you might run better with doing one snap for amd64 and another for armhf for now
[17:21] <whizzo> asac: did something change? I used to be able to build a snap that included both archs...
[17:21] <asac> yeah i get it. think best if maven could just be used tip to tail, but then, give it a try. the jdk plugin surely will get you the jre bits
[17:22] <asac> whizzo: yeah you can still do that, but snapcraft doesnt support doign that
[17:22] <asac> in the sense of building two runs with different toolchains
[17:22] <asac> i think what you try to do could work
[17:22] <asac> just need to add the magic wrappers etc. in place
[17:22] <asac> but you cant get multiple archs for jre
[17:22] <ogra_> yeah, snapcrft definitely supports just copying binaries around
[17:22] <asac> in one build
[17:22]  * ogra_ does that all the time
[17:22] <whizzo> asac: ok, i'll give the snap that just built a try
[17:22] <asac> so you might want to use the multi-arch syntax and see if that explodes
[17:22] <asac> :)
[17:23] <asac> right
[17:23] <asac> hmm. wonder why we build bluez5 without-systemd
[17:24] <asac> or rather what would happen if its build that way
[17:24] <ogra_> ask tony or morphis
[17:24]  * asac kind of suspects it might be interfering with auto tty by systemd
[17:24] <ogra_> but i guess it would need even more apparmor hackery
[17:24] <asac> not even sure what systemd would bring in ... shrug :)
[17:24]  * asac will try to look at code
[17:24] <asac> but has not high hopes
[17:25] <asac> hmmmmmm
[17:26] <asac> let me try to do two ssh logins
[17:26] <ogra_> dont overload the poor board !
[17:26] <plars> elopio: zyga: either of you (or anyone else) ever see this error when building an x86 image with mvo's udf?
[17:26] <plars> snap unpack failed with: exec: "unsquashfs": executable file not found in $PATH ()
[17:26] <ogra_> :)
[17:26] <asac> so yeah its just that its bogus
[17:26] <asac> readline
[17:26] <asac> doesnt return
[17:26] <plars> oh
[17:26] <plars> *sigh* I realized what's up with it as soon as I pasted it
[17:26] <plars> :)
[17:26] <ogra_> heh
[17:26] <elopio> :)
[17:27] <asac> ok got it... dbus permissions are not granted, hence bluetoothctl just sits there forever waiting for a dbus response
[17:27] <asac> yay
[17:28] <ogra_> lol
[17:28] <asac> looking at code can be revealing :P
[17:28] <asac> hehe
[17:28] <Guest91403> how do you know which port an app will use?
[17:28] <asac> Guest91403: if you go to webdm you can find a link there afer navigating to the app itself
[17:29] <asac> Guest91403: otherwise check the package.yaml in the snap and look for port
[17:29] <asac> some are nice and specify which port they want to use
[17:29] <asac> in 15.04
[17:29] <asac> if all that fails run sudo lsof | grep LISTEN
[17:29] <asac> and you will see what it listens to
[17:29]  * ogra_ thinks having a "snappy list-ports" command would be nice 
[17:30] <ogra_> listing yll the ports assigned to the packages
[17:30] <ogra_> *all
[17:30] <asac> snappy list-ports doign a magic lsof would work yeah.
[17:30] <ogra_> yeah, or netstat
[17:30] <asac> netstat doesnt help you finding the ports for a procss, no?
[17:30] <asac> i can only see all ports open
[17:30] <asac> but not figure who is doing what
[17:31] <ogra_> it lists the binary if you use the right options
[17:31] <asac> zyga: so how can i give my bluez5 snap powers to use dbus?
[17:31] <asac> it has amigration-skill etc.
[17:31] <asac> but taht seems to not work
[17:31] <ogra_> ubuntu@localhost:~$ sudo netstat -tulp
[17:31] <ogra_> Active Internet connections (only servers)
[17:31] <ogra_> Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
[17:31] <ogra_> tcp        0      0 *:22                    *:*                     LISTEN      981/sshd
[17:32] <Guest91403> you mean go to webdm.local in my browser and then there will be a link?
[17:32] <asac> Guest91403: http://webdm.local:4200 -> navivate to the app
[17:32] <asac> and then there is a link at the top\
[17:32] <ogra_> Guest91403, go to http://webdm.local:4200/
[17:32] <Guest91403> ya i did that
[17:32] <asac> ogra_: ok didnt nkow about -tulp i guess
[17:32] <asac>  :)
[17:32] <ogra_> there is a link in the details page of the app
[17:32] <Guest91403> I see it install on my RPi but when I click it I just see information about it
[17:32] <whizzo> asac: is there a log to check to see why my app didn't start once the snap was installed?
[17:33] <asac> whizzo: snappy service logs PACKAGENAME
[17:33] <asac> has the logs
[17:33] <asac> hast the aggregate of systemd logs for services
[17:33] <asac> :)
[17:33] <ogra_> we also still have good old /var/log/syslog if you prefer fishing ;)
[17:34] <asac> whizzo: for debugging its sometimes easier to not use service: but rather binaries:
[17:34] <asac> and then see how it explodes when running that command
[17:34] <asac> sandbox env etc. should be same, so when that starts working you can make it a service again
[17:34] <asac> but service logs should have all
[17:34] <whizzo> asac: It says Unknown command 'service'
[17:34] <ogra_> hmm, is that 15.04 ?
[17:34] <asac> whizzo: post: snappy list
[17:35] <asac> right
[17:35] <asac> if you are on an ancient 15.04 build you wont have snappy service... but recent 15.04 has it
[17:35] <ogra_> yep
[17:35] <whizzo> asac: ubuntu-core   2015-07-29 4       ubuntu
[17:35] <asac> yeah thats too ancient
[17:35] <ogra_> wow
[17:35] <Guest91403> I click on the app and I see links for Details, which has a small description, and then settings and reviews, which have nothing.
[17:35] <ogra_> thats oooold
[17:35] <asac> whizzo: what board are you on?
[17:36] <asac> if its a pi2 i would just update to latest
[17:36] <ogra_> Guest91403, ah, if the app would have declared a port there would be some link called "Open"
[17:36] <whizzo> asac: I downloaded the latest OVA from the snappy site.
[17:36] <asac> ok OVA is utlemming
[17:36] <asac> utlemming: :)?
[17:36] <asac> whizzo: can you just snappy update that thing?
[17:36] <asac> sudo snappy update
[17:36] <asac> and see if it explodes
[17:37] <asac> (back up first) :)
[17:37] <whizzo> asac: yep, doing it now
[17:37] <asac> ok lets cross fingers
[17:38] <whizzo> asac: when I run the snappy update, it looks like it pulls down 2016-01-20, but when I reboot it still comes up as 2015-07-29
[17:39] <asac> yeah, could be thats OVA
[17:39] <asac> whizzo: you run on a mac?
[17:39] <whizzo> asac: yes
[17:39] <asac> if you are on linux just go for a normal qemu
[17:39] <asac> so yeah, i am not sooo sure what to do there. guess wait for utlemming to get back to you and for now test on the arm board
[17:39] <asac> rather than the amd64 virt thingy
[17:40] <whizzo> asac: ok, will try on an ARM board.
[17:41] <asac> whizzo: curious, did you see anything about grub when OVA booted?
[17:42] <asac> or is that thing not using grub?
[17:43] <whizzo> asac: it boots so fast its impossible to read the startup messages. Is there something in the filesystem I can check?
[17:43] <jdstrand> asac: all the old ways are still there via the migration skill. the goal is to have them be gone though. see https://bugs.launchpad.net/snappy/+bug/1543220
[17:44] <ogra_> jdstrand, yeah, but a snap that was built before the skills appeared will be broken
[17:44] <jdstrand> those are broken regardless
[17:44] <jdstrand> snap.yaml
[17:44] <ogra_> well, it installs
[17:44] <ogra_> but doesnt seem to apply the apparmor rules
[17:44] <jdstrand> no
[17:45] <jdstrand> there is no compat in 16.04 for the old stuff
[17:45] <ogra_> yeah
[17:45] <jdstrand> ie, if you used 'caps' you must move to the migration skill format
[17:45]  * ogra_ desnt know what the blues5 package uses though 
[17:45] <ogra_> but timely it fits into the big changes with its upload
[17:46] <jdstrand> it uses the new format
[17:46] <ogra_> then it isnt complete or something
[17:47] <jdstrand> I tested package install on a vm, all the profiles were added
[17:47] <ogra_> apparmor seems to have " /etc/dbus-1/system.d/bluez_* rw," ... but the package cant create its dbus file
[17:47] <ogra_> (teh service one)
[17:47] <jdstrand> he forgot to add that rule to the policy
[17:47] <ogra_> /etc/dbus-1/system.d/bluez5_bluez_5.37-1-armhf.conf: Permission denied
[17:48] <ogra_> ah
[17:48] <ogra_> thats what you get when pushing someone to do last minute uploads before his vacation :)
[17:58] <asac> jdstrand: well, so i have the bluez5 snap installed from store
[17:58] <asac> jdstrand: it uses migration-skill
[17:58] <asac> buit all those seem to not work anymore
[17:58] <asac> jdstrand: i am on ubuntu-core         2016-02-03 16.04.0-7.armhf canonical
[17:58] <jdstrand> see above
[17:58] <jdstrand> there is a missing rule
[17:59] <jdstrand> that will make it fail to work
[17:59] <jdstrand> I suspect
[17:59] <asac> jdstrand: hmm. so can i just fix the snapy.yaml?
[17:59] <asac> or you say it wont work in all cases?
[18:00] <asac> jdstrand: http://paste.ubuntu.com/15017801/
[18:00] <asac> is the current one
[18:01] <jdstrand> you need to adjust meta/bluez.apparmor to have:  /etc/dbus-1/system.d/bluez5_bluez_* rwk,
[18:01] <asac> ok one sec
[18:01] <jdstrand> asac: are you repacking the snap?
[18:01] <asac> jdstrand: it currently has:
[18:01] <asac>  # Allow replacing our dbus policy configuration file until
[18:01] <asac>   # snappy has a better way to do this.
[18:01] <asac>   /etc/dbus-1/system.d/bluez_* rw,
[18:01] <asac> jdstrand: no i am not
[18:01] <jdstrand> right
[18:01] <asac> i am trying to assess whether there is hope to use this
[18:01] <asac> ah i see
[18:02] <asac> let me fix it
[18:02] <asac> bluez5
[18:02] <jdstrand> ok, I guess I didn't adjust the rule properly when moving from bluez to bluez5
[18:02] <asac> jdstrand: so the other thing i get is even nastier :)
[18:02] <Guest91403> when I try to ssh into my RPi I just get permission denied.  I am using the same password that I login with though
[18:02] <jdstrand> but it is going back to bluez aiui after awe returns from vacation
[18:02] <jdstrand> that is still tbd aiui
[18:02] <Guest91403> nevermind
[18:02] <asac> jdstrand: the whole dbus stuff [  297.130585] audit: type=1107 audit(1455211145.162:20): pid=724 uid=100 auid=4294967295 ses=4294967295 msg='apparmor="DENIED" operation="dbus_method_call"  bus="system" path="/" interface="org.freedesktop.DBus.ObjectManager" member="GetManagedObjects" mask="send" name="org.bluez" pid=966 label="bluez5_bluetoothctl_5.37-1-armhf" peer_pid=894 peer_label="bluez5_bluez_5.37-1-armhf"
[18:02] <Guest91403> i forgot the ubuntu@
[18:02] <asac> is jdstrand is that also caused by that line?
[18:03] <asac> if so i will repack it now
[18:03] <jdstrand> not by that line, but the same reason
[18:03] <jdstrand> let me look at it
[18:04] <asac> maybe the dbus paths also have 5 now?
[18:04] <asac> like /org/bluez5?
[18:04] <asac> and interface org.bluez5 ?
[18:05] <jdstrand> no
[18:05] <jdstrand> this is in meta/framework-policy/policygroups/client
[18:05] <jdstrand> where it says 'label=bluez_bluez_*'
[18:06] <jdstrand> it should be label=bluez5_bluez_*
[18:06] <ogra_> what a mess :(
[18:06] <jdstrand> asac: are you planning to upload? I think I should clean this up if not
[18:07] <asac> jdstrand: i dont plan to upload, just unblock
[18:07] <jdstrand> asac: ok, so adjust your policy for that. I'll upload after my meeting in a few minutes
[18:07] <asac> jdstrand: there is no meta/framework-policy/policygroups/client
[18:07] <asac> just seccomp
[18:08] <asac> nevermind
[18:08] <asac> found it
[18:08] <jdstrand> asac: sorry, meta/framework-policy/apparmor/policygroups/client
[18:09] <asac> garbage collection impossible: prerequisites untrue: remove /snaps/bluez5/5.37-1-armhf/command-bluetoothctl.wrapper: read-only file system
[18:09] <jdstrand> that is copied to /var/lib/snappy/apparmor/policygroups
[18:10] <jdstrand> and then on policy compile, the contents of that put in the app's profile in /var/lib/snappy/apparmor/profiles
[18:11] <asac> works :)
[18:11] <asac> you are rockstar for me jdstrand  :)
[18:11] <ogra_> damn ...
[18:11] <jdstrand> nice!
[18:11] <asac> wonder why this got uploaded without working :)
[18:11] <jdstrand> that is a long story
[18:11] <ogra_> so the dragonboard always changes its MAC until i put it in a txt file somewhere on disk
[18:12] <asac> hehe
[18:12] <asac> dont worry. i know why i think
[18:12]  * ogra_ hatse the world 
[18:12] <ogra_> *hates
[18:12] <jdstrand> awe had a working snap when named 'bluez'
[18:12] <asac> jdstrand: let me know when you uploaded the clean version so i can validate
[18:12] <asac> i am mostly interested how i can then allow a snap to use the RFCOMM devices
[18:12] <jdstrand> store stuff, I renamed, fixed a few things but not all, but couldn't test locally due to lack of hw
[18:12] <asac> so i will need your help sooner or later i guess
[18:13] <asac> i hope its a rfcomm tty
[18:13] <jdstrand> it will probably be in ~1 hour
[18:13] <ogra_> so this makes me thingk we cant easily get away with only attaching the modules to a generic initrd :(
[18:13] <asac> yeah no hurry. have to go for lunch now taht bluetoothctl is not hanging anuymore :)
[18:13] <asac> ogra_: what?
[18:13] <asac> we can
[18:13] <ogra_> asac, well, not if you want a persistent MAC on the dragonboard
[18:13] <asac> changing macs is normal in these worlds :)
[18:14] <ogra_> not in my world !
[18:14] <asac> ogra_: do you want a persistent mac that is the same everywhere?
[18:14]  * ogra_ stomps foot 
[18:14] <ogra_> !
[18:14] <asac> if not then no initrd will help you :)
[18:14] <asac> otherwise putting a txt file is fine
[18:14] <ogra_> i want a MAC like MACs are defined
[18:14] <asac> in kernel snap ... just dont want the bootlogic in there
[18:14] <ogra_> unique in the world
[18:14] <asac> modules + hacked stuff for the board is ok
[18:14] <asac> or for the series of boards :)
[18:15] <ogra_> and you can only read it from the kernel cmdline that the lk sets
[18:15] <asac> we could also do the text file in the gadget?
[18:15] <ogra_> so i need to parse /proc/cmdline and extract it from there
[18:15] <ogra_> and then write to a txt file
[18:15] <ogra_> and i cant really do that from the rootfs
[18:15] <asac> yeah thats fine
[18:15] <asac> thats db specific hackery
[18:15] <ogra_> (well, i could, but that would even be more ugly)
[18:15] <asac> like in init-bottom dir
[18:16] <asac> or something
[18:16] <ogra_> asac, exactly ... so we need an opportunity to inject device specific scripts into the initrd
[18:16] <ogra_> from the non-generic side
[18:16] <asac> ogra_: yeas, but all the initrd merging does
[18:16] <asac> is adding stuff to the OS one
[18:16] <asac> so you can add other files there too
[18:16] <asac> \beyond modules
[18:16] <ogra_> well, that wasnt really the plan
[18:16] <asac> just put the file you want in the kernel snap initrd and thats cool
[18:16] <asac> its fine
[18:16] <ogra_> but yes, we will have to
[18:16] <asac> the plan can be adjusted
[18:16] <asac> and its also in the spirit
[18:16] <ogra_> yeah, but it gets more complex
[18:16] <asac> as long as all the platform indpendent stuff goes into OS initrd i am happy
[18:17] <asac> dont think it does
[18:17] <ogra_> just merging (or even loop mounting) /lib/modules is a lot easier
[18:17] <asac> we need scripts for firmware upload hackery sometimes too there etc.
[18:17] <asac> we dont want to do that
[18:17] <asac> we want to concat the initrds
[18:17] <ogra_> i do
[18:17] <asac> taht was plan from day one
[18:17] <ogra_> yeah, thats messy
[18:17] <asac> yeah, better drop that idea and join us concat folks
[18:17] <asac> :)
[18:17] <ogra_> but anyway
[18:18] <ogra_> i guess i'll be overruled ...
[18:18] <asac> well, you overruled yourself :)
[18:18] <asac> hehe
[18:18] <asac> ok dinner
[18:18]  * ogra_ used a VHS as well ... even though there was betamax
[18:18] <asac> ttyl
[18:18] <asac> haha
[18:18] <asac> yeah loop moubnting modules feels similar to betamax
[18:18] <ogra_> it does
[18:18] <ogra_> and drops all the duplication :)
[18:25] <sergiusens> kyrofa, did it work for you?
[18:25] <sergiusens> elopio, want to give the PR a look?
[18:25] <kyrofa> sergiusens, oh I didn't notice the new push
[18:27] <sergiusens> kyrofa, I suppose it does given the tests pass, but I'll leave it up to you ;-)
[18:29] <kyrofa> sergiusens, indeed, that works :) . I'll let elopio take a look before merging
[18:30] <elopio> sergiusens: oh, sorry. Got too deep debugging in the cloud.
[18:30] <elopio> give me a minute.
[18:36] <sergiusens> kyrofa, yeah, a release comes after this; I hope we get a green adt run
[18:36] <aatchison> Hello! It's Arron from the Mycroft team.
[18:37] <aatchison> I was wondering a few things, how might we integrate continuous integration when building snaps for the raspberry pi via Jenkins?
[18:38] <sergiusens> aatchison, oh hello; your mere presence reminds me I need to pick something up
[18:38] <aatchison> hehe
[18:39] <sergiusens> aatchison, you can look at snapcraft itself; we build a ton of snaps with travis; it shouldn't differe much; elopio is working on building that stuff on jenkins fwiw
[18:39] <aatchison> ok, cool
[18:39] <aatchison> I'm jsut wondering about cross-compilation
[18:39] <elopio> but we are building for amd64 here.
[18:40] <aatchison> I tried to attach to openvpn via an lxd container, but there is no tun device...not sure how to create one
[18:40] <elopio> yeah, we currently don't have cross-compilation. You would need an armhf machine to build for rpi.
[18:40] <aatchison> my thought was, jenkins slave in lxd -> push via ssh to the host snappy-core host machine via ssh?
[18:41] <aatchison> I saw a similar thing with docker containers,we already have a server
[18:41] <ogra_> hey aatchison !
[18:41] <aatchison> Hey!
[18:42]  * ogra_ feels the same as sergiusens 
[18:42] <ogra_> oh the guilt !
[18:42] <aatchison> lol
[18:42] <aatchison> no worries or hurries
[18:42] <ogra_> i have the mycroft snapcraft.yaml ope in a terminal though :)
[18:42] <ogra_> *open
[18:42] <aatchison> awesome!
[18:42] <ogra_> (didnt close it since SCaLE :P )
[18:42] <aatchison> hahaha
[18:42] <elopio> aatchison: https://github.com/ubuntu-core/snapcraft/blob/master/examples_tests/tests.py#L293
[18:43] <aatchison> ahh, thanks:D
[18:43] <elopio> if you run this in an armhf machine, and your testbed is the ip to the rpi, you will have it working.
[18:43] <elopio> aatchison: what I didn't get was your lxd comment. Where are you missing the tun device?
[18:44] <sergiusens> aatchison, is your jenkins local?
[18:45] <elopio> aatchison: this is what I'm struggling to fix today: https://github.com/ubuntu-core/snappy-jenkins/blob/master/containers/jenkins-master/config/jobs/github-snapcraft-integration-tests-cloud/config.xml
[18:45] <elopio> jenkins, docker, snappy on the cloud. Maybe you'll find it useful.
[18:45] <sergiusens> oh elopio don't get distracted :-P
[18:46] <elopio> sergiusens: I'm so close... I test to fix.
[18:46] <aatchison> well, I was trying to connect to openvpn ( our jenkins server connects to slaves that way), there is no tun device in /dev/net/ in an lxd container
[18:46] <elopio> but I need to make your review... agh. I'm trying :)
[18:46] <aatchison> nice. I'll take a look at that script and see if I could push via another pi on the local network
[18:48] <elopio> aatchison: we have a reverse proxy that solves the communication between github and the lab that's behind vpn.
[18:48] <morphis> ogra_, asac: no real reason
[18:48] <morphis> ogra_, asac: and other than startup support isn't special in bluez for systemd
[18:48] <ogra_> morphis, yeah, was a packaging error it seems (due to the bluez5 rename)
[18:48] <aatchison> elopio: that's a good idea
[18:48] <morphis> ogra_: possible
[18:48] <ogra_> looks like asac and jdstrand solved it
[18:54] <elopio> aatchison: what we haven't solved yet is the provisioning of the rpis. http://linux.codehelp.co.uk/?p=235
[18:55] <aatchison> hmm
[18:58] <aatchison> I'm using SPI to burn Arduinos via Raspberry Pi GPIO, we are actually wondering if a small bootloader could be written to the SD card the other direction
[19:02] <elopio> aatchison: ogra_ is the bootloader guy. And plars is the hardware lab guy.
[19:02] <elopio> they might have tips. At least about things that didn't work :)
[19:07] <aatchison> haha, cool
[19:29] <sergiusens> elopio, add comments ;-)
[19:41] <jdstrand> ogra_, morphis_: fyi, out of my meeting now and will work on getting a fixed up bluez5
[19:41] <jdstrand> uploaded
[19:42] <morphis_> jdstrand: oh, is something wrong with the snap?
[19:42] <jdstrand> in the apparmor policy
[19:43] <jdstrand> two rules need to be updated
[19:43] <jdstrand> it is what ogra_ was saying as ac and I worked out
[19:43] <jdstrand> I'm just saying, I'm going to get that into the store
[20:07] <robert_ancell> is 'snappy login' persistent - i.e. you just do it once on install and then never again?
[20:09] <sergiusens> robert_ancell, yes, I don't think we kill expired keys though
[20:09] <robert_ancell> sergiusens, thanks
[20:10] <robert_ancell> sergiusens, and it does use a standard token? So it could be integrated with Ubuntu Online Accounts?
[20:10] <sergiusens> robert_ancell, not using online accounts, something closer to click-toolbelt (just like snapcraft)
[20:11] <sergiusens> robert_ancell, this is the gist of it https://github.com/ubuntu-core/snappy/blob/master/snappy/auth.go
[20:12] <robert_ancell> sergiusens, thanks
[20:15] <sergiusens> robert_ancell, if you want to runtime check on some online account features that would be sweet; we have some go code you can copy/paste or be inspired from in lp:account-polld even though we use the glib api instead of the new qt one
[20:16] <robert_ancell> sergiusens, so you think it would be appropriate for snappy to check u-o-a for credentials?
[20:16] <robert_ancell> and fall back to ~/snaps/snappy/auth/sso.json if u-o-a is not there?
[20:16] <sergiusens> robert_ancell, yes; a runtime thing I guess would be valid; although I am not core to snappy anymore so maybe ask Chipaca first
[20:17] <sergiusens> robert_ancell, or wait until Monday where we will be in the same room ;-)
[20:17] <robert_ancell> yeah, will do that too!
[20:17] <sergiusens> unless this is pre flight home work :-P
[20:17] <robert_ancell> it is
[20:18] <Chipaca> um
[20:18] <sergiusens> so either runtime or though configuration
[20:18] <Chipaca> 'snappy login' is going away, at least in its current form
[20:18] <Chipaca> you want to talk with facu about that
[20:18] <sergiusens> Chipaca, oh, right
[20:18] <sergiusens> he is not here
[20:18] <Chipaca> and unless online accounts support macaroons already you want to talk with facu and/or beuno *stat* :-)
[20:21] <sergiusens> elopio, kyrofa https://github.com/ubuntu-core/snapcraft/pull/319
[20:22] <beuno> robert_ancell, Chipaca, so
[20:22] <beuno> I don;t understand why online accounts comes into play
[20:23] <sergiusens> elopio, kyrofa just in case I pushed a tentative deb for that here https://launchpad.net/~snappy-dev/+archive/ubuntu/snapcraft-daily/+packages?field.name_filter=snapcraft&field.status_filter=published&field.series_filter=xenial
[20:23] <Chipaca> beuno, robert_ancell is trying to tie snappy into the authentication, access and secrets storage (and more?) that exist already on the desktop
[20:24] <Chipaca> at least that's my understanding of what he's doing :-D
[20:28] <jdstrand> JamesTait: fyi in case you are looking for something to do, https://code.launchpad.net/~jdstrand/click-reviewers-tools/lint-snapv2/+merge/285666 is ready for review
[20:56] <whizzo> asac: I installed my snap on a BBB running 2016-01-20 and it doesn't appear to install java
[20:58] <whizzo> asac: I take that back, it installs java but I get an "Exec format error" when trying to run the java executable
[21:01] <elopio> kyrofa: wtf catkin? It generates a bash file and a python file from templates, and then calls the python file from the bash file, and the python file calls python -c with a script in a string.
[21:01] <elopio> whyyy???
[21:02] <elopio> I had to put like 30 echos to understand that, and I'm still not close to understand the error.
[21:10] <sergiusens> elopio, fwiw, is my changelog good to land? just asking since the last one was waiting on you without notice ;)
[21:15] <whizzo> Has anyone else seen an issue with building a Java-based snap for BBB (specifying armhf as the architecture in snapcraft.yaml) and the java that is installed says "Exec format error" when you try to run it?
[21:18] <whizzo> It looks like it installed the amd64 version instead of the armhf one
[21:30] <jdstrand> asac: fyi, updated bluez5 in the store
[22:18] <elopio> cd
[23:28] <asac> whizzo: exec format error means you included binaries fro different architecture
[23:28] <asac> you need to build on arm for arm and on x86 fof x86
[23:28] <asac> as i said, snapcraft desnt support crossing
[23:28] <asac> so best off make two snaps really
[23:29] <asac> then you can probably just use the maven
[23:29] <asac> plugin as well
[23:29] <whizzo> asac: I got that error when building a snap specifically for armhf only
[23:30] <whizzo> asac: oh, I see, you're saying I can't build an armhf snap on an amd64 ubuntu machine?
[23:35] <whizzo> asac: It seems that even though the only architecture in the snapcraft.yml file is armhf, the jdk part still lays down the amd64 version of the JVM