[00:20] <bush> is there a set of comprehensive documentation on creating a ubuntu core port for a custom board that anyone knows of?
[00:21] <frecel> bush: I couldn't find anything, it would be nice if something like this existed
[00:22] <bush> I'm stuck trying to figure out how to include device specific bootloaders (FSBL, u-boot, etc.)
[00:22] <frecel> bush: what device are you working on?
[00:22] <bush> zynq
[00:23] <frecel> bush: https://developer.ubuntu.com/en/snappy/guides/porting/
[00:23] <bush> the target is ARM Cortex-A9, similar to BBB and RPi
[00:23] <frecel> I managed to find something
[00:24] <bush> I've followed that and exhausted a few other (outdated) guides, blogs, etc.
[00:25] <bush> It seems the documentation isn't moving as quickly as the development, as I'm sure we've all been guilty of.
[00:27] <frecel> yeah, this seems to be the common case for fast moving projects
[01:21] <sergiusens> bush, where are you stuck wrt bootloader setup?
[01:21] <jeffesquivels> bush: zynq? that's cool... I'm interested in the FPGA part of it
[01:21] <jeffesquivels> bush: I think that's what the snickerdoodle has
[01:22] <jeffesquivels> (sorry about being OT, he he)
[01:35] <bush> sergiusens: I can't figure out how to specify a bootloader or .dtb within a device package when building an image with 'ubuntu-device-flash'
[01:43] <sergiusens> bush, you need to create an oem snap and pass --oem to u-d-f
[01:43] <sergiusens> one sec
[01:44] <sergiusens> bush, something like http://bazaar.launchpad.net/~snappy-dev/snappy-hub/snappy-systems/files/head:/beagleblack/
[01:58] <bush> sergiusens: I just include the oem snap within the device package under /assets?
[02:24] <sergiusens> bush, hmm, /assets in a device package is long gone
[02:24] <sergiusens> bush, where is this info coming from?
[02:24] <sergiusens> jdstrand, do you know why I get this http://paste.ubuntu.com/13222977/ ?
[02:25] <bush> sergiusens: One of the outdated guides I've been disecting: https://ograblog.wordpress.com/2015/01/25/porting-ubuntu-snappy-to-a-yet-unsupported-armhf-board/
[02:25] <sergiusens> bush, oh, that is indeed old
[02:26] <sergiusens> ogra_, add a not mentioning it is outdated :-P
[02:27] <bush> sergiusens: Exploring the BBB package made me think the format was still relevant: https://developer.ubuntu.com/en/snappy/guides/porting/
[02:27] <sergiusens> bush, you need to create a snap out of what I just gave you and do ubuntu-device-flash ... --oem <thesnap> ...
[02:28] <sergiusens> the yaml is indeed outdated
[02:29] <sergiusens> bush, use this as a base http://cdimage.ubuntu.com/ubuntu-core/daily-preinstalled/current/xenial-preinstalled-core-armhf.device.tar.gz
[02:30] <bush> seriusens: awesome, thanks.
[02:30] <sergiusens> change $arch if relevant
[04:16] <soffokl> Hey guys, we still have big problems with disk IO on Ubuntu Snappy for virtualbox.
[04:16] <soffokl> Disk blocked sometimes without any reasons, even just copying file.
[04:16] <soffokl> http://s23.postimg.org/byhfb9g57/Screenshot_from_2015_11_11_10_03_18.png
[04:16] <soffokl> dmesg shows following http://pastebin.com/M96u8Che
[04:16] <soffokl> We are using SSD only systems and disk on host system not loaded.
[04:16] <soffokl> There is no such problems with other OS on virtualbox.
[04:16] <soffokl> Checked on different hardware with 15.04, 15.10, 14.04, same results.
[04:17] <soffokl> ogra_, Chipaca please help us, we have no idea about direction to dig
[06:39] <liuxg> I have a simple snappy project at https://github.com/liu-xiao-guo/go-webserver. If I do not want to use "source: git://github.com/liu-xiao-guo/golang-http" in the snapcraft.yaml to compile the go. Instead, I want to make the source code locally.  how can I modify the snapcraft.yaml file?
[06:47] <mvo> liuxg: hm, does the line "source: /home/liuxg/path/to/golang-http" work?
[06:48] <liuxg> mvo, I am not sure about it. Let me try it. thanks
[06:51] <liuxg> mvo, it does not seem to work http://paste.ubuntu.com/13225257/
[06:52] <liuxg> mvo, we have examples to show how to pull the sources, but it does not show how to compile a project whose sources are local.
[06:54] <mvo> liuxg: interessting, what version of snapcraft is that? the code has examples for local sources, e.g. "source: ." or "source: my-app". however no absolute paths in the examples, so maybe thats the problem
[06:54] <mvo> liuxg: could you try a relative path and put the source inside the dir? let me try to find you an example
[06:55] <liuxg> mvo, snapcraft (0.4). it shall be latest.
[06:55] <mvo> liuxg: yeah, that should be fine. here is a trivial example with local source https://github.com/ubuntu-core/snapcraft/tree/master/integration-tests/data/local-source
[06:56] <mvo> liuxg: and here is one that uses a subdir https://github.com/ubuntu-core/snapcraft/tree/master/integration-tests/data/simple-maven
[06:56] <mvo> liuxg: maybe thats helpful? i.e. put the snapcraft.yaml directly into your go source and use "source: ."?
[06:57] <liuxg> mvo, this is the result of it http://paste.ubuntu.com/13225279/
[06:58] <liuxg> mvo, do you mean that i need to move my snapcraft to the source code directory?
[06:59] <liuxg> mvo, for go, I need to have a directory name to come out the final binary name, right?
[07:00] <mvo> liuxg: hm, something funny is going on there, let me finish my current task and branch your code, it really should not crash like this
[07:01] <liuxg> mvo, ok. thanks for your help. I think it is a common practice to have the code locally. Once everything is fine, then it is pushed to the github or whatever.
[07:02] <mvo> liuxg: yeah and its supported in general, seems like there is a bug in the detection of whats local
[07:03] <liuxg> mvo, right. please let me the result of your testing.  thanks
[07:37] <dholbach> good morning
[07:44] <liuxg> mvo, do you have any findings?
[08:06] <mvo> liuxg: sorry, got distracted. I think its a bug in the go plugin code, I'm investigating a bit now
[08:08] <liuxg> mvo, oK. thanks for the help. by the way, do we need to report a bug for it?
[08:08] <mvo> liuxg: I think a bugreport is prudent, yes. at least it should not crash
[08:09] <liuxg> mvo, OK. so, I just report a bug against for snapcraft at https://bugs.launchpad.net/snapcraft/+filebug
[08:09] <mvo> ta
[08:13] <liuxg> mvo, I have reported the bug at https://bugs.launchpad.net/snapcraft/+bug/1515132
[08:14] <dholbach> liuxg, I think snapcraft might more be a thing for sergiusens and tedg to answer
[08:14] <liuxg> dholbach, it is alright. I will check it with them later on :)
[08:16] <mvo> liuxg: yeah, I poked it a bit but it seems like there is more to it, i.e. seting up a go workspace or copying it into the go workspace etc
[08:17] <liuxg> mvo, setting a go env is straightforward. apt-get install golang, it will install everything, I think.
[10:09] <JamesTait> Good morning all; happy Wednesday, and happy Armistice Day! 😃
[10:26] <longsleep> What is the best way to report and discuss security issues with Snappy?
[10:36] <ogra_> file bugs
[10:49] <Chipaca> longsleep: use the 'security' flag when filing the bug
[10:49] <Chipaca> soffokl: uh, ouch?
[10:50] <Chipaca> soffokl: are these errors in the host's dmesg, or in the vm's dmesg?
[11:04] <soffokl> Chipaca, on vm's dmesg
[11:07] <Chipaca> soffokl: from googling the error it seems to have something to do with weird disc configurations
[11:07] <Chipaca> bah. "weird" for a vm or an iot thing
[11:07] <Chipaca> like raid 6 on sas
[11:08] <Chipaca> soffokl: e.g. http://unix.stackexchange.com/questions/34173/mptscsih-ioc0-task-abort-success-rv-2002-causes-30-seconds-freezing
[11:10] <ogra_> especially since you wouldnt have a raid6 in snappy :)
[11:11] <ogra_> why is that driver even loaded inside the VM
[11:11] <Chipaca> dunno if it's raid6 :)
[11:11] <Chipaca> but it seems to be sas
[11:11] <Chipaca> which, sure, should work, but no idea how good/bad virtualbox's sas driver thing is
[11:12] <Chipaca> also, always be suspicious of expensive storage hardware that just happens to have the same name as a secret agency
[11:12] <Chipaca> :-p
[11:13] <soffokl> my vm is just OVA from Snappy website
[11:14] <soffokl> on the host system only single ssd
[11:15] <Chipaca> soffokl: i don't know who or how we build those; could you look up how it's set up? in the vb settings i mean?
[11:17] <soffokl> Chipaca, I tried to change every settings that i found in vm configuration, nothing changed
[11:18] <soffokl> Actually, we found workaround, we converting img for KVM from Snappy page to vmdk and using it for virtual box. And it works fine :)
[11:19] <ogra_> hmm, interesting
[11:22] <soffokl> for OVA even copying 500MB file into VM freeze several times
[11:23] <Chipaca> ogra_: do you know who builds the ova?
[11:23] <Chipaca> sounds like something they need to know about
[11:24] <Chipaca> aha!
[11:24] <Chipaca> soffokl: bug in virtualbox
[11:24] <Chipaca> https://www.virtualbox.org/ticket/10031
[11:25] <ogra_> Chipaca, no, i dont
[11:25] <ogra_> i'd expect the cloud people
[11:25] <soffokl> Chipaca, Opened 4 years ago, hmmm
[13:13] <frecel> ogra_: do you know anything about anyone actively working on a snappy build for intel edison?
[13:13] <ogra_> frecel, nope, i dont ... i know that lool took a look at it ages ago and there were probs
[13:16] <frecel> do you know when loop tends to hang out on irc?
[13:20] <longsleep> Is there some gear so a snap can run its own config hook, or should that be handled by the snap internall?
[13:20] <longsleep> i have a chicken egg issue, and need to make sure the config hook was run at least once before start
[13:20] <longsleep> before start of a service in the snap i mean
[13:25] <ogra_> longsleep, make it touch a stampfile, add a check for the stampfile to the startup script
[13:26] <longsleep> ogra_: yeah, but how do i run the config hook from the startup script? Directly?
[13:27] <ogra_> thats what i do
[13:27] <ogra_> if there is no initial config file i run the config.sh script once in my snap
[13:27] <longsleep> ok, i was wondering if there is a way to trigger whatever "snappy config" is doing
[13:28] <longsleep> yeah makes sense, i can certainly do that
[13:28] <ogra_> snappy config only pipes strings into your hook anyway
[13:28] <ogra_> or rather "a string"
[13:28] <ogra_> :)
[13:28] <longsleep> right, but maybe it does or will do something more
[13:29] <ogra_> i think there was a bug open to restart the service once it applies a config, but that wont affect you on first start
[13:29] <ogra_> thats the only planned enhancement i know about
[13:29] <longsleep> ogra_: yes, i think i created that bug
[13:29] <longsleep> ok
[13:29] <longsleep> fair enough
[13:29] <ogra_> ask Chipaca, he migh know more :)
[13:35] <Chipaca> me? i know nothing
[13:35]  * Chipaca <- in a meeting
[14:28] <jdstrand> sergiusens: it might be a bug in the review tools. there is some pretty ugly code due to the click compat bits that I think might be getting confused (ie, it is trying to detect if the yaml and the click compat manifest are in sync cause if they aren't, the snap could be crafted)
[14:29] <jdstrand> sergiusens: this won't be any issue once the pending feature branch mvo and I are working on lands (and I make the corresponding change to the review tools)
[14:29] <jdstrand> sergiusens: Chipaca saw this too the other day. I think something changed in snappy that started triggering this issue
[14:29] <jdstrand> sergiusens: can I have the snap?
[14:30] <Chipaca> about what?
[14:30] <Chipaca> jdstrand: is it about network-client?
[14:32] <jdstrand> http://paste.ubuntu.com/13222977/
[14:33] <jdstrand> it seems like snappy build isn't generating the compat apparmor profile correctly
[14:33] <jdstrand> when you specify nothing, you are supposed to have the default template and 'network-client'
[14:33] <jdstrand> oh, actually, I think I may know the issue
[14:34] <jdstrand> this might be related to the networking -> network-client change
[14:34] <jdstrand> I'll fix that real quick
[14:34] <jdstrand> but again, all this compat code will be leaving both snappy and the review tools once mvo and I are down with the policy regeneration branch
[14:35] <jdstrand> done*
[14:36] <mvo> jdstrand: :-D indeed, thats going to be a glorious day. let me know how I can help further, I prepared the warning for the compatitbility if security-override.apparmor,seccomp is used and I wrote the ubuntu-core-launcher upate
[14:36] <jdstrand> mvo: I saw! I think that is perfect. just ignore that it is there
[14:37] <jdstrand> mvo: I'm preparing an apparmor upload that is related to snappy image policy uploads and the new /var/lib/snappy/apparmor/profiles dir
[14:37] <jdstrand> mvo: I will have that done this morning and then get back to reviewing your changes
[14:38] <mvo> yay!
[14:38] <rickspencer3> stgraber, so, lxc is not working for me on my up to date (version 9) Beagle Bone Black: http://pastebin.ubuntu.com/13227521/
[14:41] <jdstrand> man I hate this compat code in the review tools...
[14:43] <mvo> jdstrand: it will be over soon
[14:44] <mvo> jdstrand: soon we have it all replaced
[14:45] <jdstrand> \o/
[14:48] <sergiusens> mvo, well, well; there will be one more point of sync as snapcraft would be assembling the snap
[15:29] <stgraber> rickspencer3: hmm, not completely clear what's the problem there. It looks like something's failing with lxc-net in there but then lxd itself is running or lxd-images would have failed differently...
[15:29] <rickspencer3> stgraber, ok, what should I do?
[15:29] <stgraber> rickspencer3: I'd recommend doing a reboot if you haven't yet, see if that gets things back in working order. If not, another possibility for that error would be that you're running out of disk space somehow.
[15:30] <rickspencer3> stgraber, I did reboot
[15:30] <rickspencer3> stgraber, what's a good way to check disk space?
[15:31] <stgraber> rickspencer3: "df -a | grep writable" may do it, it's a bit of a mess with all the bind-mounts though
[15:31] <rickspencer3> stgraber, http://pastebin.ubuntu.com/13227923/
[15:32] <stgraber> that should be fine
[15:32] <stgraber> ok, let me try to reproduce that issue on my beaglebone black here
[15:33] <rickspencer3> thanks stgraber
[15:41] <jdstrand> beuno: can you pull r543 to the store. this is needed to address the error in things like https://myapps.developer.ubuntu.com/dev/click-apps/3675/seq/4/
[15:42] <jdstrand> beuno: beuno more review tools changes will be coming in the next week or so, but this one is kinda needed now
[15:44] <beuno> jdstrand, yeap. cc/ pindonga
[15:44] <jdstrand> beuno: also, I don't seem to be able to waive https://myapps.developer.ubuntu.com/dev/click-apps/3675/seq/4/ through
[15:45] <sergiusens> jdstrand, beuno let me calm eveyone a bit though; only us devs see that as it is only in the tools-proposed area or xenial at most
[15:45] <jdstrand> beuno: the first failure is what I fixed in the review tools. the second is Chipaca wanting access to snapd and I'm presuming he knows what he is doing :)
[15:55] <stgraber> rickspencer3: fyi, I did manage to reproduce the issue here on my bbb, I'm trying to figure out what's going on now
[15:55] <rickspencer3> thanks stgraber
[15:55] <rickspencer3> stgraber, if you give me a link to the project, I will log a bug for you if you want
[15:56] <stgraber> doh, found the issue
[15:56] <stgraber> MemoryError
[15:56] <stgraber> the bbb doesn't have enough RAM to process the cloud image :)
[15:57] <rickspencer3> stgraber, ouch
[15:59] <stgraber> looks like we could change lxd-images to use less RAM, it'd use more I/O though but probably still worth doing
[15:59] <stgraber> I'll file an upstream bug for that
[16:02] <stgraber> rickspencer3: https://github.com/lxc/lxd/issues/1300
[16:03] <rickspencer3> stgraber, ok, doesn't sound like it will be fixed quickly
[16:03] <rickspencer3> keep me posted
[16:05] <stgraber> rickspencer3: fix should be pretty straight forward but it'll take another couple of weeks before it's in a release that hits snappy
[16:05] <rickspencer3> stgraber, ack, I get it
[16:05] <rickspencer3> np
[16:05] <stgraber> rickspencer3: though you'll be able to grab the lxd-images script from git and manually use it until then
[16:06] <rickspencer3> stgraber, ooh
[16:06] <rickspencer3> ok, just let me know when you have something for me to try
[16:07] <jdstrand> beuno, pindonga: actually, can you make that r544? r544 has the vendor checks removed too
[16:07] <jdstrand> bug #1510522
[16:29] <jdstrand> beuno, pindonga: heh, make that r545 -- I missed sergiusens branch which I just merged
[16:33] <stgraber> rickspencer3: https://github.com/lxc/lxd/pull/1301
[16:34] <rickspencer3> stgraber, nice
[16:34] <stgraber> testing on my bbb now (prepared it on x86 obviously :))
[16:34] <rickspencer3> I'm working on something else right now, but if you want me to try your fix later, just post me some instructions
[16:38] <stgraber> doh, /tmp is a tmpfs on snappy, so that's not helping much as it still ends up in memory
[16:38] <stgraber> pretty sure /tmp on tmpfs is a bad idea for low-memory devices...
[16:38] <stgraber> mvo: ^
[16:39] <stgraber> rickspencer3: sure enough, the MemoryError is now replaced by a No space left on device :)
[16:39] <rickspencer3> um
[16:39] <rickspencer3> stgraber, so, I guess we need an image for a bigger sd card?
[16:40] <stgraber> what we'd need is for snappy to detect that the board has low memory and setup /tmp as a path on /writable instead of an in-memory tmpfs
[16:40] <stgraber> I'm basically doing that manually here now to confirm that this then all works
[16:51] <mvo> stgraber: thanks! indeed, thats our default setup
[16:51] <mvo> stgraber: i.e. use tmpfs
[17:03] <stgraber> rickspencer3: http://paste.ubuntu.com/13228814/ <- confirmed that this works fine here
[17:04] <stgraber> rickspencer3: so moving forward, hopefully snappy won't be using tmpfs for /tmp on beagleboneblack and LXD 0.23 will contain the lxd-images fix, at which point everything should just work (albeit very slowly, but that's because of the hardware)
[23:01] <jerryG> how do i start mir manually?
[23:50] <csanders> I'm running through the "your first app" tutorial. After building the example webcam .snap, can I locally install this on my Snappy Ubuntu Core VM?
[23:50] <csanders> The guide moves on to "publishing apps" but doesn't mention installing this to test that it built correctly.