[02:42] <ash_charles> hello---I'm new to snappy and just learning my way around.
[02:46] <ash_charles> I see an error "beagleboneblack_1.0_all.snap failed to install: Signature verification failed with exit status 10" when playing with the beaglebone example oem package
[02:46] <ash_charles> any hints?
[03:05] <ash_charles> Ah---the magic seems to be adding the '--developer-mode' argument for locally built packages
[06:28] <D_Cent> hi, i installed java on my snappy ubuntu and now wrote a bash script which starts a java application which should be running as a service. the problem is that apparmor won't let me execute java, it says "Operation not permitted". can i allow java to be called somehow?
[06:29] <D_Cent> (the service was installed as a snap)
[07:00] <Chipaca> D_Cent: what exactly is getting blocked?
[07:00] <D_Cent> Chipaca: the java call itself
[07:00] <Chipaca> D_Cent: dmesg | grep DENY
[07:01] <D_Cent> Chipaca: hm... that doesn't give me anything
[07:01] <Chipaca> D_Cent: then it isn't apparmor
[07:01] <D_Cent> Chipaca: systemctl status says: Apr 24 07:01:04 localhost.localdomain ubuntu-core-launcher[1318]: /apps/rda-watchdog.sideload/0.1/bin/rda-watchdog: line 4: /usr/bin/java: Operation not permitted
[07:02] <Chipaca> D_Cent: wait, you installed java to /usr/bin/?
[07:02] <D_Cent> Chipaca: well, I basically just installed the raspbian debian package - I didn't find a snap or anything for snappy
[07:02] <Chipaca> haha
[07:03] <Chipaca> D_Cent: how did you install a package from a different architecture? isn't raspbian armel?
[07:03] <D_Cent> Chipaca: i've got "oracle-java8-jdk_8_armhf.deb", so i guess not ;)
[07:04] <Chipaca> D_Cent: looks like there is an armhf raspbian. fair enough.
[07:04] <D_Cent> Chipaca: so why is the call getting blocked? is there another way to get java working?
[07:05] <Chipaca> D_Cent: it's not getting blocked; it's probably entirely broken
[07:05] <Chipaca> D_Cent: can you run java from the terminal?
[07:05] <D_Cent> Chipaca: but i can execute the script when not using systemd
[07:05] <D_Cent> Chipaca: exactly
[07:06] <Chipaca> D_Cent: once you've installed a debian package onto a snappy system it is not a snappy system any more, you're pretty much on your own there. have you looked into whether seccomp is blocking it somehow?
[07:06] <Chipaca> i've got to go, but can probably help you a bit further when i return in an hour and half or so
[07:07] <D_Cent> Chipaca: okay, thank you!
[07:07] <Chipaca> D_Cent: meanwhile, look into seccomp
[07:07] <D_Cent> I'll do
[07:17] <ogra_> D_Cent,  you either need to put the java install inside your snap or you need to create a framework package if you actually need to consume java from multiple snaps ... installing a deb will be reverted completely on updates
[07:18] <dholbach> good morning
[07:18] <ogra_> Chipaca, raspbian is armhf but ARMv6 ...
[08:08] <D_Cent> ogra_: okay, so this will be a problem for me then... for example, i need wi-fi (wpa_supplicant) and that doesn't come with ubuntu core, so i installed that with dpkg, too
[08:19] <davidcalle> dpm, when trying the appliance guide last night, have you been hitted by this (second part of the bug) ? https://bugs.launchpad.net/snappy-ubuntu/+bug/1447724
[08:19] <dpm> davidcalle, that's the bug that I fixed
[08:20] <davidcalle> dpm, oh! Cool :)
[08:20] <dpm> davidcalle, the .sideload references are now .canonical
[08:20] <davidcalle> dpm, ok, makes sense
[08:21] <dpm> davidcalle, I think it's because the original version of the guide was written with a locally-installed snapp, whereas a store snapp was made available afterwards. At least that's what I think
[08:21] <dpm> after changing the instructions to .canonical, the guide worked for me
[08:22]  * davidcalle should get a bbb
[08:26] <mhall119> davidcalle: dholbach: did rcj's changes to the snappy docs get made yesterday?
[08:26] <davidcalle> mhall119, yep
[08:27] <dholbach> mhall119, davidcalle responded at 23:54 CET
[08:35] <JamesTait> Good morning all; happy Friday and happy Teach Your Children to Save Day! :-D
[08:54] <Chipaca> D_Cent: so if you need to use something like wap_supplicant, i think you need to create a framework package with that, and then make your package depend on the framework
[08:54] <Chipaca> D_Cent: however, i do believe the intention is for core to have some kind of wifi story soon :)
[08:55] <Chipaca> it might just mean that we're going to create that framework package ourselves
[08:57] <D_Cent> Chipaca: that would be great :)
[08:58] <Chipaca> D_Cent: meanwhile you might need to muddle through it on your own though :)
[08:58] <Chipaca> it's not even on the trello yet
[08:58] <Chipaca> afaik :)
[08:58] <D_Cent> Chipaca: so now i'm trying to put java directly into the snap and it *seems* to work. Now I have to deal with other issues that the usb4java library has ;) (temporary directory creation)
[08:58] <Chipaca> D_Cent: temp dir should be set up properly though
[08:59] <D_Cent> Chipaca: i guess it tries to create that directory right where you call the java command from, but i guess i can fix that :) i just hope that i won't run into problems when accessing usb devices
[09:00] <Chipaca> D_Cent: what directory is it trying to create?
[09:00] <Chipaca> D_Cent: wrt usb devices, that's what “snappy hw-assign” is for
[09:00] <D_Cent> Chipaca: it should be /apps/rda-watchdog/watchdog/usb4java
[09:01] <Chipaca> D_Cent: your thing is a framework?
[09:01] <D_Cent> Chipaca: right now it's just an app
[09:01] <Chipaca> D_Cent: that's not the path of an app though
[09:02] <D_Cent> Chipaca: ah wait...
[09:02] <D_Cent> Chipaca: /apps/rda-watchdog.sideload/current/watchdog/usb4java is the correct path
[09:02] <Chipaca> better :)
[09:02] <D_Cent> :)
[09:02]  * Chipaca hadn't even notice the missing version in the first one
[09:03] <Chipaca> D_Cent: your app is trying to write there?
[09:03] <D_Cent> Chipaca: the usb4java framework wants to extract a jar file temporarily to get access to a native library which it then wants to load
[09:04] <ogra_> so you need to ship that library inside
[09:05] <Chipaca> ogra_: java doesn't give you too much control over that, does it?
[09:05]  * Chipaca doesn't know
[09:05] <D_Cent> i'll try that :)
[09:06] <ogra_> Chipaca, i think java uses enmv vars you can shufflke around
[09:06] <Chipaca> D_Cent: if your java thing expects PWD to be writeable, better cd to $SNAP_APP_DATA_PATH (or $SNAP_APP_TMPDIR ?) before starting it
[09:07] <Chipaca> ogra_: or -Xeogijuoifvhiofiodsfqrigikvnueoicodifighiu43
[09:07] <Chipaca> or maybe it was 44, and 43 was "go buy beer"
[09:07] <Chipaca> hard to know
[09:08] <D_Cent> Chipaca: aah thanks, that's a better idea
[09:09] <Chipaca> D_Cent: if you're running on an arm board, and you know that extracion is happening every time your app starts, and you can instead ship things unextracted, go with that
[09:09] <Chipaca> D_Cent: save yourself some time
[09:11] <Chipaca> s/arm/low power/
[09:11] <Chipaca> probably same applies for the intel thingamajig
[09:11] <D_Cent> Chipaca: hmmm 2cd: /tmp/snaps/rda-watchdog.sideload/0.1/tmp: No such file or directory"
[09:12] <D_Cent> Chipaca: that happens when trying "cd $SNAP_APP_TMPDIR"
[09:12] <Chipaca> D_Cent: hm. maybe you need to mkdir -p it first?
[09:12] <Chipaca> if that doesn't work, double-hm :)
[09:13] <D_Cent> okay, double hmm ;) "mkdir: cannot create directory ‘/tmp/snaps’: Permission denied"
[09:13] <Chipaca> tee, hee. ok. that's a Bug
[09:14] <Chipaca> D_Cent: hm. the code to make it is there.
[09:14] <Chipaca> D_Cent: maybe you're running something old/ancient?
[09:15] <Chipaca> D_Cent: there's a mkdir in the wrapper in /apps/bin/<your app>
[09:15] <D_Cent> Chipaca: i just build my image yesterday with ubuntu-device-flash
[09:15] <D_Cent> *built
[09:15] <Chipaca> D_Cent: could you pastebin the wrapper?
[09:16] <D_Cent> Chipaca: you mean my script which starts the java process?
[09:17] <Chipaca> D_Cent: no, i mean the wrapper that's created for the binaries declared in your package.yaml and placed in /apps/bin/
[09:17] <Chipaca> D_Cent: which is what sets up the environ for your app before calling it with ubuntu-core-launcher
[09:17] <D_Cent> Chipaca: aah sure, just a sec
[09:18] <D_Cent> Chipaca: http://pastebin.com/sszsfZGt
[09:20] <Chipaca> D_Cent: so, that fine; that creates the directory
[09:21] <D_Cent> Chipaca: okay, but i start that as a service
[09:21] <Chipaca> D_Cent: you .. what?
[09:21] <D_Cent> Chipaca: it is supposed to be started by systemd
[09:22] <Chipaca> D_Cent: but then it's not a binary, it's not in /apps/bin/
[09:22] <Chipaca> i'm making you look in the wrong place :)
[09:23] <D_Cent> Chipaca: hehe so basically, i just run "sudo systemctl start rda-watchdog_rda-watchdog_0.1" and that runs the systemd script in /etc/systemd/system - seems like that doesn
[09:23] <D_Cent> * doesn't use /apps/bin
[09:23] <Chipaca> D_Cent: so, could you pastebin the service file from /etc/systemd/system/ ?
[09:24] <Chipaca> D_Cent: should be something like rda-watchdog_yourservice_yourversion.service
[09:24] <D_Cent> Chipaca: sure :) http://pastebin.com/jN2Gq3SK
[09:25] <Chipaca> hmmmm :)
[09:25] <Chipaca> dunno why i asked you to do that. no surprises there.
[09:26]  * Chipaca digs into it
[09:26] <D_Cent> hehe thanks :)
[09:26] <Chipaca> pitti: i've got a systemd question for you when you're around
[09:30] <D_Cent> Chipaca: now i see what it is trying to do - app armor reports: "audit: type=1400 audit(1429867806.982:39): apparmor="DENIED" operation="mknod" profile="rda-watchdog.sideload_rda-watchdog_0.1" name="/tmp/usb4java2636409983806462228.tmp" pid=2021 comm="java" requested_mask="c" denied_mask="c" fsuid=0 ouid=0"
[09:31] <Chipaca> D_Cent: good. now you need to find out what env var is needed so that it uses the "right" tmpdir
[09:32] <Chipaca> D_Cent: while i sort out that right tmpdir getting created, you should be able to create it yourself from outside
[09:33] <D_Cent> Chipaca: for the moment, i just use $SNAP_APP_DATA_PATH which exists and is writable
[09:33] <Chipaca> D_Cent: ok :)
[09:34] <Chipaca> mvo: sergiusens: I *think* we need to put something in tempfiles.d so the services get their tmpdir. Waiting for confirmation from pitty wrt that.
[09:35] <pitti> Chipaca: just shoot
[09:36] <Chipaca> pitti: we're telling services they should use a given TMPDIR
[09:37] <Chipaca> pitti: that TMPDIR does not exist
[09:37] <Chipaca> pitti: poking around a little it seems we need to drop a file in one of the tempfiles.d
[09:37] <Chipaca> pitti: is that the right way?
[09:41] <Chipaca> pitti: so a file named like the package, with one line of the form “d $TMPDIR 1777 ubuntu ubuntu” per service
[09:44] <pitti> Chipaca: that works, but TBH I'd rather set this up in ubuntu-app-launcher
[09:45] <pitti> Chipaca: i. e. just mount  a private /tmp/ into the app's namespace, so that you don't need a $TMPDIR at all
[09:45] <Chipaca> pitti: that sounds a lot better; a lot of code doesn't check TMPDIR anyway.
[09:46] <pitti> Chipaca: yeah, that was my concern
[09:46] <pitti> Chipaca: I noticed that with the ROS snap, I had to sed its code to make it respect TMPDIR
[09:46] <ogra_> can you actually call mount from a snap ?
[09:46] <Chipaca> ogra_: not on my watch :)
[09:46] <pitti> ogra_: no, you don't need to, just the launcher
[09:47]  * Chipaca doesn't actually have a watch
[09:47] <ogra_> ah, so systemd then
[09:47] <pitti> ?
[09:47] <Chipaca> ogra_: no, ubuntu-core-launcher
[09:47] <pitti> (not related to that)
[09:47] <ogra_> oh, thats a new thing ...
[09:47] <Chipaca> ogra_: maybe. it's also setuid.
[09:47]  * ogra_ only has dones service snaps yet
[09:47] <pitti> at least in my PoC I already create a new namespace for mounting a private /dev/pts/
[09:47] <pitti> it's trivial to add a tmpfs /tmp/ there
[09:48] <pitti> I think that might not yet be in mvo's C implementation in vivid, but at some point we want to add it
[09:48] <Chipaca> pitti: is that PoC on the launcher, or is it something else?
[09:48] <Chipaca> ah
[09:48] <Chipaca> ok :)
[09:48] <pitti> Chipaca: on ubuntu-core-launcher, yes
[09:49] <Chipaca> so, we probably want to do that soon
[09:49] <Chipaca> because services have no tmpdir right now
[09:51] <pitti> yeah, agreed
[09:51] <pitti> and also the /dev/pts/ so that apps can't spy on each other's terminals (well, apparmor would/should prevent that too, but it's still cleaner)
[09:53] <Chipaca> pitti: sgtm. asac also wanted private /dev/, but that's hairier
[09:54] <Chipaca> anyway, sounds like we have a plan for this, and either you or mvo are on it already. I'll go back to worrying about obscure error cases.
[09:54] <Chipaca> D_Cent: meanwhile, you'll have to create the directory by hand every time (or create a file in /etc/tmpfiles.d; man tmpfiles.d)
[09:55] <pitti> Chipaca: we have restricted device access already
[09:55] <pitti> Chipaca: private /dev/ was teh original plan and PoC, but we have something better now (using the devices cgroup)
[09:59] <D_Cent> Chipaca: alright, thank you!
[10:01] <Chipaca> pitti: ok :) i thought we'd had to go back on that for now, but glad to be wrong
[10:02] <Chipaca> pitti: added a comment on the /dev/pts card so we don't forget
[10:17] <mvo> yeah, private /tmp and /dev/pts is planed just not done yet and will be added soon(ish)
[11:47] <D_Cent> hm... got another problem now. i put java into an own framework package and it works completely. now i have an app, set java as a framework for the app and tried calling "java". without mentioning the path "/apps/bin/java" it doesn't find the executable. if i use that path directly, i get an "operation not permitted" error
[11:48] <sergiusens> fwiw, and executable shouldn't be a framework
[11:48] <sergiusens> a framework should be something that mediates resources
[11:50] <D_Cent> hm.. okay, the documentation mentions i could put binaries and services into frameworks
[11:51] <ogra_> sergiusens, an interpreter isnt a resource ?
[11:51] <sergiusens> ogra_: i felt that was coming
[11:51] <ogra_> lol
[11:52] <sergiusens> it will be very hard to claim the 'java' namespace in any case
[13:07] <D_Cent> can somebody explain what exactly java tries doing here so it gets killed? "[24632.544408] audit: type=1326 audit(1429880585.774:262): auid=1000 uid=0 gid=0 ses=25 pid=4173 comm="java" exe="/apps/rda-watchdog.sideload/0.1/java/bin/java" sig=31 arch=40000028 syscall=370 compat=0 ip=0x76ede622 code=0x0"
[13:38] <jdstrand> pitti: fyi, the private /dev conversation was because cgroups don't block what the app sees, only what the app accesses. so, ls /dev shows everything even if the app can only access /dev/foo. personally, I think that is fine. we aren't trying to reimplement container solutions-- if people want containers, they can use them
[13:55] <mvo> D_Cent: try scmp_sys_resolver 370
[13:55] <mvo> D_Cent: this looks like there is a missing syscall in our seccomp whitelist
[13:57] <ogra_> well, he is using an ARMv6 binary ...
[13:57] <ogra_> could be related
[13:58] <mvo> yeah, we had issue with the arm private syscalls before
[13:58] <mvo> libseccomp did not implement them all, jdstrand send a patch upstream, maybe there are more private arm syscalls (but really I'm no expert for this)
[13:59] <jdstrand> I haven't sent one yet
[13:59] <jdstrand> err
[13:59] <jdstrand> haven't sent it upstream yet
[14:00] <jdstrand> there were 5 listed in the kernel sources and confirmed in other seccomp implementations (firefoxos, minijail)
[14:00] <jdstrand> we shouldn't have any more missing syscalls. our template might be missing one
[14:01] <jdstrand> the private syscalls have a much higher number. 370 is in the normal range and not a private arm syscall
[14:02] <mvo> ahah, ok
[14:02] <mvo> sorry
[14:02] <jdstrand> on bbb:
[14:02] <jdstrand> $ scmp_sys_resolver 370
[14:02] <jdstrand> name_to_handle_at
[14:03] <jdstrand> name_to_handle_at is explicitly denied due to "a history of vulnerabilities and are not widely used"
[14:04] <jdstrand> tyhicks: can you look at backscroll for 1 hour and advise?
[14:05] <jdstrand> tyhicks: it appears java is trying to use name_to_handle_at
[14:07] <D_Cent> mvo: thanks a bunch! can you also tell me how to enable the syscall by default?
[14:08] <jdstrand> D_Cent: please read my comments
[14:08] <jdstrand> this is a problematic syscall and we've disabled it
[14:09] <D_Cent> jdstrand: ah okay, i'm sorry
[14:10] <jdstrand> you now, you can add it manually to /var/lib/snappy/seccomp/profiles/<yourapp>
[14:10] <jdstrand> but it will be lost on upgrade
[14:10] <D_Cent> jdstrand: that's what i did for now :/
[14:11] <jdstrand> you might be able to avoid it in your java code
[14:11] <D_Cent> jdstrand: it's actually not my code - it happens in the usb4java library (which basically is based on a C library)
[14:12] <jdstrand> this gives some information on the call: http://manpages.ubuntu.com/manpages/utopic/man2/open_by_handle_at.2.html
[14:16] <jdstrand> D_Cent: perhaps there is a way to disable it at compilation. It was introduced in 2.6.39 kernel (~4 years ago). if this library is meant to be used on older kernels...
[14:18] <tyhicks> I'm looking at how/why usb4java is using that syscall
[14:18] <D_Cent> jdstrand: i didn't compile it myself yet, so i guess i should do that now. the library i use now was built on GCC: (Debian 4.6.3-14+rpi1) 4.6.3
[14:18] <jdstrand> tyhicks: hi! (and thanks)
[14:18] <tyhicks> jdstrand: hey :)
[14:19] <jdstrand> D_Cent: you might wait for tyhicks' response
[14:20] <tyhicks> D_Cent: hi - I've cloned the libusb4java and usb4java git trees and I'm not finding where that syscall is being made in either of them
[14:21] <tyhicks> D_Cent: can you give me some more info? (is it a specific version of libusb4java?)
[14:21] <ogra_> tyhicks, he is grabbing the binaries from raspbian ...
[14:21] <ogra_> which is a hacked up armhf, forced to ARMv6 instead of v7 ...
[14:22] <D_Cent> tyhicks: i can't find it either by just grepping, so it must be an indirect call i think
[14:22] <ogra_> (so they rebuild the debian archive with different compile options)
[14:22] <tyhicks> hrm
[14:22] <D_Cent> tyhicks: the function is called once i call "UsbHostManager.getUsbServices()"
[14:22] <tyhicks> this is really odd
[14:22] <tyhicks> I've never heard of anything needing that syscall other than an nfs server that was implemented in userspace
[14:24] <D_Cent> tyhicks: i'm also very confused. everything else in my java code is working, just not that usb library call
[14:29] <jdstrand> tyhicks: fyi, https://codesearch.debian.net/results/name_to_handle_at/
[14:29] <tyhicks> jdstrand: I'm on page 8 :)
[14:30] <tyhicks> btw, "UsbHostManager.getUsbServices()" is from javax-usb and I pulled down their git tree and don't see it being called in there
[14:32] <jdstrand> oh, interesting
[14:32] <tyhicks> jdstrand: I didn't see any packages actually using name_to_handle_at... only things that need to enumerate the syscall table
[14:32] <jdstrand> http://sources.debian.net/src/docker.io/1.3.3~dfsg1-2/contrib/mkseccomp.sample/?hl=393#L393
[14:32] <D_Cent> i wish i could track that system call down a bit more, like with a call stack or something
[14:32] <jdstrand> docker blocks it by default. of course, they have a way to add it
[14:33]  * jdstrand notes we have a way to add blocked syscalls to via the "security-override" mechanism, however, this particular one is explicitly denied
[14:33] <jdstrand> too*
[14:33] <D_Cent> :(
[14:34] <tyhicks> I'm wondering if the "hacked up armhf, forced to ARMv6 instead of v7" part is the problem
[14:35] <tyhicks> maybe the syscall number is different somehow??
[14:35] <ogra_> that was what i thought ...
[14:35] <D_Cent> tyhicks: the oracle JVM runs fine on raspbian on the same machine (raspberry pi 2)
[14:35] <tyhicks> D_Cent: what is the oracle JVM version?
[14:36] <D_Cent> tyhicks: they only put the major version (8) into the package name
[14:36] <tyhicks> ok
[14:40] <tyhicks> D_Cent: I pulled down the tip of the jdk8u tree (http://hg.openjdk.java.net/jdk8u/jdk8u/) and I'm still not seeing open_by_handle_at() being used
[14:41] <tyhicks> D_Cent: I'm pretty convinced that nothing is using that syscall and there are other low level issues at play around syscall numbering
[14:42] <D_Cent> tyhicks: is there a way to make sure?
[14:43] <tyhicks> D_Cent: I can try to find the source of the kernel that you're running
[14:43] <D_Cent> tyhicks: or i'll try the openjdk package from here: https://launchpad.net/ubuntu/+source/openjdk-8
[14:44] <tyhicks> D_Cent: you can try that but don't spend too much time on it
[14:44] <blackout24> Hello, I'm trying to get a better understanding of Ubuntu Snappy. I'd like to know how the system image is put together (I guess this is made from debs) and how the "ubuntu-core" package that list listed by "snappy list" is created. I looked around on launchpad, but I'm a bit lost.
[14:44] <tyhicks> D_Cent: I don't think it'll help since I think the problem is lower in the stack than openjdk
[14:44] <jdstrand> tyhicks: fyi, http://paste.ubuntu.com/10879065/
[14:45] <jdstrand> tyhicks: do you have a moment to go through that with me?
[14:46] <nessita> mvo, hey, you around?
[14:46] <jdstrand> tyhicks: well, a few moments
[14:46] <tyhicks> jdstrand: yeah, we should talk through that diff soon
[14:46] <tyhicks> D_Cent: what kernel version? `uname -r`
[14:46] <nessita> jdstrand, o/ do you know, by any chance, if the snaps define "hooks" in their manifest, or the "hooks" is just a click thing?
[14:46] <ogra_> tyhicks, he is not using openjdk but oracles java for RPi ... ;)
[14:47] <jdstrand> nessita: hooks are click only
[14:47] <nessita> jdstrand, great, thanks
[14:47] <jdstrand> (white lie-- click-apparmor is still a hook, but that will be removed in coming weeks
[14:47] <jdstrand> )
[14:47] <tyhicks> ogra_: uhh... happen to have a link to that source?
[14:48] <D_Cent> thecomedian: 3.19.1-4-generic-bcm2709
[14:48] <D_Cent> woops
[14:48] <ogra_> tyhicks, no, i just followed the conversation before you joined ... i guess D_Cent has one though
[14:48] <D_Cent> thecomedian: 3.19.1-4-generic-bcm2709
[14:48] <D_Cent> tyhicks: 3.19.1-4-generic-bcm2709 - now i got that right
[14:48] <ogra_> (and i doubt there is source .... being oracle )
[14:48] <thecomedian> lol
[14:49] <D_Cent> thecomedian: sorry, auto completion by irssi ;)
[14:49] <thecomedian> np :)
[14:49] <ogra_> tyhicks, next time you need to know D_Cent's kernel version, ask thecomedian ... he has it spare ... twice :)
[14:49] <tyhicks> :)
[14:50] <thecomedian> :-P
[14:50] <D_Cent> hehe
[14:50] <D_Cent> tyhicks: okay, the openjdk doesn't make it better
[16:00] <D_Cent> bbl
[16:01] <vmayoral|pc> greetings
[16:03] <vmayoral|pc> asac: We keep finding the issues with the boot partition getting corrupted in Snappy. Has someone addressed this in newer versions of snappy for the BBB?
[16:08] <jodh> davidcalle: hi - I've just noticed that https://developer.ubuntu.com/en/snappy/guides/filesystem-layout/ is outdated. The latest details are in http://bazaar.launchpad.net/~snappy-dev/snappy/snappy/view/head:/docs/system-updates.rst
[16:09] <jodh> davidcalle: do we plan to put that doc up as a separate one at some point?
[16:13] <jodh> davidcalle: bug raised - https://bugs.launchpad.net/snappy-ubuntu/+bug/1448203
[16:47] <jdstrand> sergiusens: hey, can you add this to your webdm profile: '@{PROC}/sys/net/core/somaxconn r,'
[16:47] <jdstrand> sergiusens: see snappy-dev@
[16:48] <jdstrand> sergiusens: there is another denial that we should address as well
[16:53] <jdstrand> slangasek: fyi:
[16:53] <jdstrand> $ sudo snappy update
[16:53] <jdstrand> Installing ubuntu-core (36)
[16:53] <jdstrand> Starting download of ubuntu-core
[16:53] <jdstrand> 136.29 KB / 136.29 KB [[16:53] <jdstrand> Done
[16:53] <jdstrand> Failed to run command '/bin/mount -obind /boot/uboot /writable/cache/system/boot/uboot': mount: mount point /writable/cache/system/boot/uboot does not exist
[16:53] <jdstrand>  (exit status 32)
[16:54] <jdstrand> I think that might be what is reported in the bug on upgrade problems
[16:54] <jdstrand> (that is a bbb)
[17:00] <slangasek> jdstrand: yes, it's certainly the same bug.  what was your upgrade path on this system?
[17:01] <slangasek> after one update on the stable channel, I've got /boot/efi and /writable/cache/system/boot/efi which I don't think were there before.  I also have /boot/uboot still correctly in place
[17:01] <jdstrand> slangasek: r33 trying to go to r36
[17:02] <slangasek> jdstrand: and r33 was the initially installed version?
[17:02] <jdstrand> slangasek: note, I've tried several times to upgrade
[17:02] <slangasek> ok
[17:03] <jdstrand> slangasek: actually, I think I started on r30, got to r33, then tried r36
[17:03] <jdstrand> slangasek: not sure if you say my other comments in that bug-- previous attempts had umount errors and autopilot errors in syslog
[17:04] <jdstrand> s/say/saw/
[17:05] <slangasek> ok
[18:01] <yngves> What is the intended behaviour if an app specifies a framework that is not installed? Resolve the dependency by installing the missing framework? Fail, and inform the user what is missing?
[18:34] <tyhicks> D_Cent: Hi - I got pulled into something else for a while but I just got a chance to look at the kernel sources that you're running
[18:35] <tyhicks> D_Cent: it looks like name_to_handle_at is syscall 370 there, too
[18:35] <tyhicks> D_Cent: however, I still think something odd is going on and don't feel comfortable white listing that syscall until we see the same behavior on one of the officially supported platforms
[18:36] <tyhicks> D_Cent: could you please file a bug against ubuntu-core-security so that we can track the issue?
[18:39] <HoloIRCUser2> Hi, can anyone hell me? I tried snappy 15.04 stable and edge (in kvm). And i want to try the webdm, but there is no service which listen in a TCP port except ssh.
[18:39] <asac> vmayoral|pc: not sure which version you are using
[18:39] <asac> vmayoral|pc: but we surely invested into making this pretty reliable
[18:40] <asac> HoloIRCUser2: we are working on making webdm work on 15.04 right now... in a couple days an update will be in sotre that will bring the webserver back
[18:40] <HoloIRCUser2> Help not hell ^^
[18:40] <asac> HoloIRCUser2: its fine... i didnt even read "hell" until you mentioned it
[18:41] <asac> HoloIRCUser2: https://developer.ubuntu.com/en/snappy/guides/webdm/ read the box on the right
[18:42] <asac> :)
[18:42] <HoloIRCUser2> ADAC: thank you very mich!
[18:42] <davmor2> HoloIRCUser2: in kvm you need to set the port,  you'll see other examples of it.
[18:42] <asac> welcome!
[18:42] <HoloIRCUser2> Lool, German Android keyboard
[18:42] <asac> davmor2: that too, but webdm we preinstall doesnt start the server because its not compatible with latest snappy tooling yet... had to make that decision to get base system rock solid for release
[18:43] <asac> buut couple days it will all look great and even better than before
[18:43] <davmor2> asac: yeah I got hit installing it and couldn't figure out why I couldn't access it
[18:43] <asac> HoloIRCUser2: android keyboard? wow... guess you try snappy on your laptop right now? :)
[18:44]  * asac uses his laptop for ubuntu core amd64 now
[18:44] <asac> davmor2: i am sure sergio is hacking on the plane right now to get us stuff back
[18:44] <asac> :)
[18:44] <asac> vmayoral|pc: would you mind trying with the released image?
[18:44] <asac> or rather 15.04/edge
[18:44] <asac> if you want bleeding edge from stable
[18:45] <asac> vmayoral|pc: so many things did land in last couple weeks that you surely want to update
[18:45] <HoloIRCUser2> davmor2: i connected to the console and searched with netstat for listening ports. I know what you mean. I am using bridge and not a internal network for the guests
[18:45] <asac> jdstrand: what was your upgrade series to get into that state?
[18:46] <asac> slangasek: you think you can try the upgrade path 30 -> 33 -> 36? i think its about the same kickinz1 had
[18:47] <asac> jodh: can you provide an update to just filesystem doc? and at best integrate that as a separet md
[18:47] <asac> we want one that is just about that
[18:47] <asac> the system upgrade is good, but should refer to the spec that is just about that at best
[18:47] <asac> thx
[18:48] <asac> btw, interesting discussion going on here: http://www.phoronix.com/forums/showthread.php?117235-Ubuntu-s-Desktop-Next-Switching-From-DEBs-To-Snappy
[18:48] <jdstrand> asac: sorry was in a meeting
[18:48] <asac> some folks seems to get it
[18:48] <asac> jdstrand: i just asked 2 minutes ago :)
[18:48] <jdstrand> asac: flash r30, upgrading to r33, tried to get to r36
[18:49] <jdstrand> I noticed autopilot errors after r33
[18:49] <jdstrand> r30 to r33 was ok
[18:49] <jdstrand> if there were errors, I didn't see them
[18:49] <jdstrand> (there weren't on the console for sure)
[18:49] <asac> right we must not send an update to the stable channel until we have figured
[18:49] <asac> slangasek: did you pull 3?
[18:50] <asac> just triple checking :)
[18:50] <jdstrand> I would agree with that
[18:50] <jdstrand> (being cautious)
[18:56] <HoloIRCUser2> asac: which box do you mean, I can't find such box ^^
[19:02] <D_Cent> tyhicks: hey, thank you very much for your help! of course, i'll do that as soon as possible!
[19:02] <tyhicks> D_Cent: thanks!
[19:16] <blackout24> Hi, is there any place where I can learn how the ubuntu-core system image is put togehter? I have been looking for a launchpad repo that has all the tools that are used, but could not find anything.
[19:47] <asac> blackout24: so we use our official infra to do that which is not very nicely documented
[19:47] <asac> nor available
[19:48] <asac> blackout24: we use livecd-rootfs
[19:48] <asac> afaik
[20:36] <asac> sorry, didnt see any pings if there were any :)
[20:55] <asac> slangasek: so i am in a armhf click chroot ... and i have libssl-dev:armhf installed and i have an autoconf/make project that doesnt find it without me giving very strong hints...
[20:55] <asac> slangasek: isnt there some magic supposed to be that does all that for me? like setting CONFIG_SITE=/etc.. ?
[20:55] <asac> this doesnt do anything for me ;/
[20:56] <asac> i even ran autoreconf to ensure i ahve all the latest stuff
[20:56] <asac> but nothing
[20:58] <asac> ok guess i really have to set libdir manually
[21:21] <asac> slangasek: figured it. ignore