[04:44] <tbr> bjf: does your particular NUC have a legacy bios mode or only UEFI? UEFI doesn't work quite yet.
[04:47] <tbr> bjf: In my case to get the latest tools and preliminary UEFI support I did on 15.04: "apt-add-repository ppa:snappy-dev/tools" "sudo ubuntu-device-flash core rolling --output amd64.img --developer-mode --channel edge" only works on 15.04 tho for uefi
[05:03] <rsalveti> tbr: mind updating the bug with the issues you still had with latest u-d-f that is available at this ppa?
[05:03] <rsalveti> and yeah, this extra logic is not part of the rootfs, so we need to change the flashing tool
[05:04] <tbr> rsalveti: I'm still unclear about the underlying issues, but yeah, will do
[05:04] <tbr> if it would be more clear I'd have done already
[05:05] <rsalveti> thanks, yeah, not so familiar with that setup still, maybe slangasek can help you a bit more with that
[05:05] <rsalveti> since he did the initial uefi support
[05:07] <slangasek> UEFI does work, for 64-bit systems that don't require secureboot and if you're using the right udf
[05:09] <tbr> slangasek: for me 'works' means in a very narrow context: in qemu with UEFI firmware and by manually executing grubx64.efi or writing a startup.nsh
[05:09] <slangasek> https://launchpad.net/~snappy-dev/+archive/ubuntu/tools/+packages shows that goget-ubuntu-touch has only been updated for vivid, not for trusty or utopic; that's a sergiusens question
[05:09] <tbr> on a minnowboardmax however boot fails and I'm not sure why
[05:10] <slangasek> tbr: no, udf installs the bootloader to /EFI/boot/bootx64.efi
[05:10] <slangasek> which is the path UEFI expects to find for a removable disk
[05:11] <slangasek> you shouldn't even have a grubx64.efi installed by udf
[05:11] <tbr> or it was called bootx64.efi
[05:11] <bjf> tbr, got part of my question answered earlier. thanks.
[05:12] <tbr> anyway, both on qemu and on minnow I end up in the EFI shell with the image
[05:12] <tbr> if I then run it manually it will boot in qemu, but not on the minnow
[05:15] <slangasek> well I can't reproduce the behavior you're describing under qemu, the images booted straightaway for me with no configuration required
=== erkules_ is now known as erkules
=== dholbach_ is now known as dholbach
[07:16] <dholbach> good morning
[07:28] <tbr> slangasek: well, something is obviously different then. I've documented what I did in the bug.
[07:32] <tbr> the qemu is 2.0.0+dfsg-2ubuntu1.10 and ovmf 0~20131112.2590861a-2  - though that shouldn't matter as behaviour is the same on the minnowmax too.
[08:36] <JamesTait> Good morning all; happy Alison Hargreaves Day! 😃
[08:46] <ogra_> beowulf, oooh, thanks, fixing
[09:12] <beowulf> ogra_: i was wondering if node-snapper should look in package.json (or npm-shrinkwrap) to find deps, at correct semver, and maybe the easiest way to do that would be to allow passing in package.json as an argument and using that in the chroot where 'npm install' is called? does that sound ok?
[09:13] <ogra_> beowulf, do you mean .deb deps or npm deps ?
[09:13] <beowulf> ogra_: i mean npm deps
[09:14] <ogra_> ah, yeah, sounds sane
[09:17] <beowulf> parsing package.json could MY_EXECUTABLE from "main"
[09:24] <ogra_> yeah
[09:25] <ogra_> if you use paths from there you need to substitute them thouh
[09:25] <ogra_> *though
[09:36] <vmayoral|pc> hey there, I'm trying to get snappy-tools set up in and amrhf chroot running something like https://gist.github.com/vmayoral/b9d84522e1b28b54f028
[09:36] <vmayoral|pc> however it seems like: "E: Unable to locate package snappy-tools"
[09:37] <vmayoral|pc> the package is available though http://ppa.launchpad.net/snappy-dev/tools/ubuntu/dists/vivid/main/, right?
[10:03] <ogra_> vmayoral|pc, hmm, i fear there is no armhf deb for them
[10:04] <ogra_> (are you running that on armhf ?)
[10:04] <vmayoral|pc> ogra_: yes
[10:04] <ogra_> http://ppa.launchpad.net/snappy-dev/tools/ubuntu/pool/main/s/snappy-tools/
[10:11] <ogra_> vmayoral|pc, bug 1454619
[10:11] <ogra_> (why is there no ubottu here ... tsk)
[10:12] <vmayoral|pc> thanks ogra_
[10:17] <vmayoral|pc> ogra_: i got the tools from the BBB image you guys released but this is hardly scalable for other developers. Until there're armhf devs, is there a simpler way to get snappy-tools? Maybe from the sources? If so i'd really appreciate if you could walk me through
[10:18] <ogra_> you could do "apt-get build-dep snappy-tools && apt-get source -b snappy-tools"
[10:18] <ogra_> with the ppa enabled ... on an armhf device
[10:19] <ogra_> (not sure how well that works, theoretically it should though :) )
[10:20] <ogra_> (armhf chroot *should* work, but i'm not sure how the go compiler will behave in a qemu chroot)
=== bigcat_ is now known as bigcat
[13:12] <ogra_> bug 1454619
[13:12] <ubottu> bug 1454619 in snappy-ubuntu "snappy PPAs should provide armhf packages" [Undecided,New] https://launchpad.net/bugs/1454619
[13:13] <ogra_> \o/
=== alexabreu is now known as alex-abreu
=== dholbach_ is now known as dholbach
[15:08] <beowulf> dpm: hi! would you be interested in a couple of typos i spotted while reading https://developer.ubuntu.com/en/snappy/guides/config-command/?
[16:19] <dpm> beowulf, definitely (sorry, I'Ve been in calls until now). Would you mind pointing them out to me and davidcalle? ^
[16:21] <davidcalle> dpm, beowulf, actually that means they are in snappy trunk as well, since that's a doc we imported. I'll make a mp with what you have found.
[16:27] <beowulf> dpm: davidcalle: not sure what's the best way to do this, but...
[16:27] <beowulf> " The application is repsonsible to provide a configuration handler that can transform yaml into the apps native configuration format. "
[16:27] <beowulf> responsible*
[16:27] <beowulf> app's*
[16:28] <beowulf> and i'd argue it should read "is responsible for providing a configuration handler"
[16:29] <beowulf> " The current list of values that must be supported (if the feature is used:"
[16:29] <beowulf> missing closing para?
[16:30] <beowulf> " When the configuratin is applied the service will be restarted by snappy automatically(?). "
[16:30] <beowulf> configuration*
[16:30] <beowulf> and not sure about that "(?)"
[16:31] <beowulf> dpm: davidcalle: also i wasn't sure about the config examples, they confused me a little
[16:32] <beowulf> but the last one:
[16:32] <beowulf> " snappy calls meta/hooks/config with empy input "
[16:32] <beowulf> empty*
[16:33] <beowulf> dpm: davidcalle: if you want to point me at somewhere i can branch and propose an mp i'm happy to do that
[16:35] <davidcalle> beowulf, snappy trunk https://code.launchpad.net/snappy the text is in docs/config.md
[16:37] <davidcalle> beowulf, thanks :)
[16:51] <beowulf> davidcalle: https://code.launchpad.net/~stephen-stewart/snappy/fix-typos-in-config-docs/+merge/259027
[16:55] <davidcalle> beowulf, super nitpicking, but do you mind dropping the extra space between sentences on l18 of the diff ? "editing of config.  The format"
[17:03] <davidcalle> beowulf, I'm going to apply these changes to the website a bit later today, since they LGTM, thanks again
[17:03]  * davidcalle relocates
[17:22] <dpm> thanks beowulf!
[20:55] <mterry> To run ./run-checks from lp:snappy, do I need to install into GOPATH first?
=== j12t_ is now known as j12t
=== genii_ is now known as genii
[23:00] <Chipaca> mterry: I think you need to work in a go workspace
[23:01] <Chipaca> mterry: e.g., mkdir -p ~/canonical/snappy/src/launchpad.net && cd ~/canonical/snappy/src/launchpad.net && bzr branch lp:snappy && cd snappy && GOPATH=~/canonical/snappy ./run-checks
[23:06] <mterry>  Chipaca: Oh hmm, OK.  I have to be *inside* GOPATH for it to work then?
[23:07] <Chipaca> mterry: it needs a hand in finding itself, yes