[00:21] <sergiusens> kgunn, I am back if you still have issues or a question
[00:21] <Domi> Does anyone use Ubuntu Snappy on a Raspberry Pi 3?
[00:51] <sergiusens> kgunn, here's the solution http://paste.ubuntu.com/15680718/
[00:51] <sergiusens> kgunn, but fwiw, you can also just move those stage-packages to build-packages
[00:51] <sergiusens> kgunn, also, mircommon should provide a .pc file ;-)
=== chihchun_afk is now known as chihchun
[03:28] <robert_ancell> Is there a method to extract metadata from a .snap file?
=== kickinz1|eod is now known as kickinz1
[09:23] <vila> kyrofa, sergiusens: https://github.com/ubuntu-core/snapcraft/pull/427 should be mergeable now
[09:53] <vila> sergiusens: and https://github.com/ubuntu-core/snapcraft/pull/428 has been rebased
[09:56] <vila> sergiusens: huh ? You're up ?!?
[09:58] <sergiusens> 7am
[09:58] <sergiusens> yes
[09:58] <sergiusens> just a bit before coffeee :-)
[10:04] <vila> sergiusens: haaaa ! ok ;-)
[10:04] <vila>  https://github.com/ubuntu-core/snapcraft/pull/428 has been re-rebased
[10:05] <vila> sergiusens: enjoy coffee ;-)
[10:10] <vila> sergiusens: a bit of advice needed: https://pastebin.canonical.com/153789/ the second chunk breaks the alignment of command descriptions, should I just fix them (no tests are failing is that expected ?)
[10:30] <sergiusens> vila, yeah, just shove the rest so they are aligned
[10:31] <sergiusens> vila, leave 2 spaces between the command and desc (it is not parsed by docopts but is consistent with Options)
[10:31] <vila> sergiusens: ha ! 2 space, ack, will do
[11:24] <kyrofa> Good morning
[11:44] <sergiusens> kyrofa, mind reviewing the geoip branch?
[11:44] <kyrofa> sergiusens, sure!
[11:45] <sergiusens> kyrofa, thanks!
[11:45] <sergiusens> kyrofa, and I didn't say good morning as I thought you weren't in yet :-P
[11:46] <sergiusens> sort of a fire and forget thing ;-)
[11:46] <kyrofa> sergiusens, haha, I'm offended
[11:46] <kyrofa> Good morning ;)
[12:08] <zyga> jdstrand: I got interfaces to work
[12:08] <zyga> jdstrand: I have a pile of patches, some will need your approval
=== chihchun is now known as chihchun_afk
[13:01] <jdstrand> zyga: ack-- I've got a number of things going on this morning. I can probably start looking at stuff in ~4 hours
[13:09] <kyrofa> sergiusens, our commit messages are garbage with this squash thing. We need to keep the wrap at 72
[13:11] <zyga> jdstrand: ok
[13:16] <seb128> is the "snap" command supposed to work out of the box?
[13:16] <seb128> or what is it used for?
[13:16] <seb128> is that a snappy tool? :p the manpage doesn't even introduce/describe it
[13:16] <ogra_> it is supposed to replace the "snappy" command
[13:16] <seb128> no description
[13:16] <seb128> just the arguments
[13:17] <ogra_> something at least :P
[13:17] <kyrofa> seb128, snap is the snappy commands successor. snappy makes direct function calls, whereas I believe snap uses snapd
[13:17] <kyrofa> seb128, I'm surprised there's a manpage at all :P
[13:17] <seb128> on a fresh xenial install, "snap find" gives a "error: cannot list snaps: cannot communitcate with server: Get http://localhost... /run/snapd.socket no such file or directory"
[13:18] <ogra_> kyrofa, for archive inclusion you need it :)
[13:18] <kyrofa> ogra_, ahhhh
[13:18] <ogra_> seb128, what arch is that ?
[13:18] <seb128> i386
[13:18] <ogra_> native or vm ?
[13:18] <seb128> virtualbox
[13:18] <ogra_> looks like there is something with your network
[13:18] <seb128> desktop install
[13:18] <ogra_> so snapd didnt start
[13:19] <ogra_> oh, desktop install
[13:19] <ogra_> i wonder if mvo removed to much from the ubuntu-snappy-cli command ... we definitely need the snapd systemd unit
[13:19] <ogra_> s/command/package/
[13:20] <mvo> ogra_: I got a report like this yesterday too
[13:20] <mvo> ogra_: I'm not sure, something is broken
[13:20] <seb128> the systemd job is loaded but inactive
[13:21] <ogra_> aha
[13:21] <jdstrand> zyga: if it would help, feel free to send an email, otherwise I'll circle back
[13:21] <ogra_> i see something similar on a rpi3 where i manually need to start the snapd service ... might be some race
[13:21] <zyga> jdstrand: it's okay, no rush :)
[13:22] <seb128> ogra_, mvo, works after a "systemctl start ubuntu-snappy.snapd"
[13:22] <ogra_> yeah
[13:22] <seb128> so the job is not active by default?
[13:23] <ogra_> well, i see it active on a dragonboard and pi2 ... i dont see it active on a pi3
[13:23] <ogra_> which makes me suspect some race with i.e. network bringup
[13:29] <seb128> ogra_, mvo, ubuntu-snappy.snapd has a After=...firstboot which is an unit in ubuntu-snappy not -cli
[13:29] <seb128> unsure if that's the issue
[13:29] <seb128> I don't remember what systemd does in those cases
[13:29] <seb128> there is no Requires so does it prevent start anyway?
[13:31] <ogra_> thats most likely the issue, i think firstboot moved to ubuntu-snappy
[13:32] <seb128> right
[13:32] <seb128> also firstboot fails to start
[13:33] <seb128> "Unknown interface unp0s3"
[13:33] <seb128> "no gadget snap"
[13:33] <seb128> is what is in the status log
[13:39] <ogra_> fun
[13:54] <cjwatson> ogra_: archive inclusion> erm, not true, not that I object to stuff having man pages
[13:55] <cjwatson> it's recommended but not a requirement
[13:55] <ogra_> isnt that linitian complaint a blocker ?
[13:55] <cjwatson> no
[13:55] <ogra_> oh, i thought it was
[13:56] <cjwatson> don't let me discourage you from writing man pages, of course, but it has never been a blocker :)
[13:56] <ogra_> heh
[13:56] <ogra_> i usually try to get my new submissions linitian clean ... (though i usually also only do that for the first upload)
[13:57] <ogra_> (like most people i guess  .... :P )
[14:09] <elopio> sergiusens: kyrofa: this is finally ready for a review: https://github.com/ubuntu-core/snapcraft/pull/418
[14:26] <Domi> Hello, does ubuntu core work on Rasbpery pi 3?
[14:27] <ogra_> Domi, still experimental but here is an image http://people.canonical.com/~ogra/snappy/all-snaps/rpi3/
[14:29] <Domi> ogra_ I have to write a paper on ubuntu core. Will it boot and work so that I'm able to get an impression ?
[14:29] <ogra_> yes, but be aware there might still be bugs
[14:33] <Domi> ok I just have to decide if I buy a Raspberry pi 2 or 3 but my mentor at the universtiy would favor the raspberry pi 3.
[14:34] <ogra_> that image works on both ;)
[14:35] <Domi> ok but is it alpha, beta or close to release on the rpi3?
[14:35] <ogra_> somewhere between alpha and beta i'd say
[14:38] <Domi> ok then I will go with the raspberry pi 3. Thank you for your support. I think there is a post that offical support of the raspberry pi 3 will start on 16.04 is that correct?
[14:58] <zyga> jdstrand: okay, I'm close to having something for you to review
[15:03] <zyga> jdstrand: https://github.com/ubuntu-core/snappy/pull/838
[15:19] <zyga> jdstrand: https://github.com/ubuntu-core/snappy/pull/840
[15:19] <zyga> jdstrand: I'd like to change template.go so that we don't have all those confusing old variable names for 16.04
[15:20] <zyga> jdstrand: and keep just SNAP_NAME, SNAP_REVISION and APP_NAME
[15:20] <zyga> jdstrand: if you agree I'll do the branch
[15:31] <sergiusens> kgunn, hey, did you catch my response on irc last night?
[15:31] <kgunn> sergiusens: yes i did and thank you!
[15:31] <kgunn> just haven't had a chance yet to follow up
[15:31] <sergiusens> kgunn, great
[15:32] <sergiusens> kgunn, also, qml plugin; I want to get rid of it but I saw you use it or some form of it still so maybe it shouldn't go away; I do want to reform it though
[15:33] <sergiusens> the main thing it has is setting up config and envvars,  right?
[15:34] <ogra_> YAAAY ... !
[15:34] <ogra_> snappy build all gone from the image builds !
[15:35] <ogra_> (all snapcraft now)
[15:35] <sergiusens> \o/
[15:40] <netphreak> hi, guys!
[15:54] <netphreak> How do i install latest snap craft..
[15:54] <netphreak> appears i only have 1.1.0
[15:57] <zyga> netphreak: you need to use ubuntu 16.04 daily images for that
[15:57] <netphreak> makes sense
[15:57] <netphreak> thx
[15:58] <kgunn> sergiusens: wrt qml plugin, do you mean qtmir? that is the plugin i/f for qml to render on mir surfaces...so don't think we can get rid of that
[15:58] <kgunn> or did you mean something else?
[16:00] <sergiusens> kgunn, the snapcraft qml plugin
[16:00] <sergiusens> kgunn, an in ref to the example client you have which has a local plugin there doing sort of what the qml plugin does
[16:02] <kgunn> sergiusens: oh!!
[16:02] <kgunn> :)
[16:02] <kgunn> yeah, if you wanted to drop qml plugin, we could easily move anything i'm relying on into the local pluing of my snap
[16:03] <kgunn> it's an example anyhow...and should be used as a template to fork
[16:03] <kgunn> by other qml/mir client app devs
[16:11] <zyga> jdstrand: I've sent you two pings on github
[16:12] <zyga> jdstrand: if you follow on them quickly we _might_ merge the switch to interfaces today
[16:21] <mhall119> sergiusens: I need help with snapcraft and the python2 plugin
[16:21] <mhall119> I'm trying to package a simple python2/gtk3 app
[16:22] <mhall119> and I get this: http://paste.ubuntu.com/15691803/
[16:29] <zyga> mhall119: that looks like distutils vs setuptools
[16:32] <netphreak> I'm trying to build a gadget, with a built-in snap, and get the following error:
[16:32] <netphreak> http://pastebin.ubuntu.com/15692050/
[16:33] <ogra_> is system-status.victor in the store (for the channel you build for)
[16:33] <ogra_> the snaps get pulled from there :)
[16:37] <netphreak> It's located in the store here:
[16:37] <netphreak> https://uappexplorer.com/app/system-status.victor
[16:38] <netphreak> i set the channel to victor
[16:40] <ogra_> netphreak, you set the channel to "victor" ?
[16:40] <ogra_> it needs to be in the channel you use for your ubuntu-device-flash command ... i.e. "rolling --channel=edge"
[16:41] <ogra_> (that would be the 16.04 "edge" channel)
[16:45] <netphreak> failed to install "system-status.victor" from "edge": system-status.victor failed to install: snap not foundfailed to install "system-status.victor" from "edge": system-status.victor failed to install: snap not found
[16:45] <netphreak> failed to install "system-status.victor" from "edge": system-status.victor failed to install: snap not foundfailed to install "system-status.victor" from "edge": system-status.victor failed to install: snap not found
[16:45] <netphreak> failed to install "system-status.victor" from "edge": system-status.victor failed to install: snap not found
[16:45] <netphreak> sorry
[16:45] <mhall119> zyga: what would my fix be in that case?
[16:46] <zyga> mhall119: fork that code for a sec and use setuptools in setup.py; if that fixes it then you are good to go
[16:46] <zyga> mhall119: if not then ignore me
[16:46] <zyga> mhall119: the error you're seeing is because (apparently) snapcraft uses something that's setuptools-specific (which is sensible because disttools are terrible)
[16:47] <zyga> s/disttools/distutils/
[16:47] <mhall119> hmmm, I think quickly used distutils :(
[16:48] <zyga> mhall119: it might be possible to support distutils in the plugin; you'd have to check with sergiusens
[16:49] <zyga> jdstrand: around?
[16:51] <netphreak> ogra_: I want to preinstall/make my own app built-in - was using the system-status.victor app for that.
[16:51] <ogra_> netphreak, sure, i get what you want ... but your app needs to be in the right place for that
[16:53] <netphreak> eg. in edge?
[16:54] <ogra_> in myapps.developer.ubuntu.com the "Supprted Releases" bit needs to list "rolling-core" ... and the Channel shoudl eb the same as the one you use in ubuntu-device-flash when building
[16:55] <netphreak> Ok..
[16:55] <netphreak> Was there support for private snaps?
[16:56] <ogra_> (most likely edge since thats the only one you can get the recent image bits from)
[16:56] <ogra_> dunno, thats a question to the store people
[16:57] <kyrofa> matiasb, do you know anything about private snaps? ^^
[17:16] <jdstrand> zyga: just got out of my meeting. I have to do a followup real quick. feel free to ask questions, but I also have backscroll
[17:17] <zyga> jdstrand: thanks for responding; I have a pair of small branches ready for review; one bigger branch and one upcoming branch because snappy just switched to revisions
[17:17] <zyga> jdstrand: with some luck we'll still land interface switch today
[17:17] <zyga> jdstrand: I also wanted to catch up on apparmor template variable names; I think we could do a simple pass that renames them to be more sensible and to drop unused ones
[17:18] <zyga> jdstrand: that's all I had; no need to look at backlog (for me)
[17:18] <zyga> jdstrand: :-)
[17:22] <netphreak> ogra_: tried with webdm - and it appears to work. Though browsing https://system-image.ubuntu.com/ubuntu-core/rolling/edge/ i do not see anything about webdm?
[17:40] <matiasb> kyrofa, netphreak, sorry, was otp; there is support for private snaps, server side at least (not sure that's being handled in the client though)
[17:40] <netphreak> any docs or description?
[17:41] <mhall119> zyga: ok, switching to setuptools made snapcraft happy
[17:41] <mhall119> I built my snap and installed it
[17:41] <mhall119> but I can't run *any* snap
[17:41] <mhall119> $ ubuntu-core-launcher foo foo foo
[17:41] <mhall119> unable to bind /snaps/ubuntu-core.canonical/current//lib64 to /lib64. errmsg: No such file or directory
[17:41] <mhall119> I always get the same error
[17:41]  * mhall119 is on i386 still
[17:42] <mhall119> it seems like ubuntu-core-launcher tries to use 64bit stuff regardless
[17:43] <zyga> mhall119: image is out of date perhaps
[17:43] <zyga> mhall119: you really really want to wait till next week
[17:44] <zyga> mhall119: so many big features are landing
[17:44] <zyga> mhall119: (revisions, interfaces, snappy removal, new fs layout)
[17:44] <mhall119> zyga: that will be true again next Friday though :-P
[17:44] <zyga> (from the top of my head)
[17:44] <zyga> mhall119: we're building the image tonight
[17:44] <zyga> mhall119: I showed working interfaces this morning; most of the stuff on this list is merged now
[17:46] <mhall119> zyga: will interfaces make it easier to build desktop app packages?
[17:46] <zyga> mhall119: perhaps
[17:46] <zyga> mhall119: the biggest thing we've been busy lately is fighting cruft in the code
[17:46] <zyga> mhall119: so that we can make changes
[17:46] <zyga> mhall119: one thing we might explore for the desktop is library interface
[17:47]  * mhall119 looks forward to having reasonable-sized desktop app packages
[17:47] <zyga> mhall119: e.g. to share some big snap with libraries across other snaps
[17:47] <zyga> mhall119: but this requires careful planning
[17:48] <mhall119> zyga: I just want a "GTK" and "Qt" thing apps can depend on, so they don't have to include all that
[17:48] <zyga> mhall119: e.g. by starting with one big fat library (SDK runtime perhaps)
[17:48] <kyrofa> mhall119, yeah the ROS folks are wanting that as well
[17:50] <mhall119> zyga: yeah, something like that
[17:50] <zyga> mhall119: I suspect that's not something we can make in one week though
[17:50] <mhall119> kyrofa: I'm not surprised, a "platform" snap that apps can target just makes sense
[17:50] <zyga> mhall119: smells like SRU
[17:50] <mhall119> zyga: SRU? Just snap-package it and deliver updates through the store ;)
[17:51] <zyga> mhall119: interfaces are in the snappy codebase
[17:51] <zyga> mhall119: you'd have to release new snappy first
[17:51] <zyga> mhall119: metaphorical SRU
[17:51] <kyrofa> mhall119, the OS snaps are still based on the archives
[17:53] <mhall119> kyrofa: I was mostly joking :)
[18:34] <elopio> ogra_: the PPA has the new snapd package that mvo wanted to publish. Can you please trigger the image generation?
[18:39] <ogra_> elopio, mvo said there might be seed changes needed
[18:39] <elopio> ogra_: the deb is now called snapd instead of ubuntu-snappy. Could it be related to that?
[18:39] <ogra_> (but yes, I can trigger a build if that makes sense)
[18:41] <ogra_> elopio, https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/xenial/ubuntu-core-system-image/ ... building
[18:42]  * ogra_ vanishes back to the TV
[18:44] <ogra_> Oh, that was a quick build
[18:45] <elopio> hash mismatch :(
[18:45] <ogra_> elopio, looks like the builders are borked atm... Seems cjwatson is working on a fix according to #ubuntu-devel
[18:47] <ogra_> or rather waiting for infinity to do it :)
[18:48] <elopio> got it.
[18:52] <sergiusens> mhall119, zyga kyrofa even if you have the infra, given he have no real design for this, developer tools that use this will come much later
[18:53] <sergiusens> you will have to snap craft your own stuff when using the "shared content" interface
[18:53] <zyga> sergiusens: totally agreed
[19:02] <dtoebe> hey guys, I am getting snappy-tools not found on 16.04 (https://developer.ubuntu.com/en/snappy/guides/) I also looked at the ppa I used from 15.10 and filtered for Xenial, and no snappy-tools build... Is there snappy-tools for xenial yet?
[19:03] <kyrofa> dtoebe, just install snapcraft directly (assuming that's what you're going for)
[19:04] <dtoebe> kyrofa, thanks doing it now... whats the difference between the 2
[19:05] <kyrofa> dtoebe, snappy-tools was a meta package that pulled in some other things. It seems to be PPA-specific
[19:05] <kyrofa> (pre-xenial)
[19:06] <dtoebe> kyrofa,  oh ok... Then the url I ref'ed should be updated... Who do I contact?
[19:07] <kyrofa> dtoebe, hold on, let's get to the bottom of this. sergiusens do you know if we ever plan on shipping snappy-tools in xenial?
[19:07] <kyrofa> sergiusens, or should we update that document to only mention snapcraft?
[19:07] <ogra_> We should, but only after release day
[19:08] <kyrofa> elopio, also, according to some bug responses I've seen from you snappy-remote isnt in the xenial archives either. Can you confirm?
[19:08] <kyrofa> ogra_, should what-- ship snappy-tools or update the document?
[19:17] <sergiusens> kyrofa, ogra_ I say we copy package it in the ppa but also remove it from the documentation
[19:19] <dtoebe> sergiusens, should I watch for it in the ppa then?
[19:31] <kyrofa> sergiusens, just mention snapcraft in that doc, then?
[19:38] <elopio> I can't install snappy-tools because I don't have snappy-remote. And I can't install snappy-remote because it doesn't exist.
[19:39] <sergiusens> kyrofa, yeah
[19:39] <elopio> I think we need to rewrite our strategy related to that. Instead of snappy-remote, I think we should have something like snappy try and snappy install --ip, or something
[19:40] <kyrofa> elopio, it depends on how snappy try is implemented. Right now no one has the snappy-cli, right? That's not a dependency of snapcraft anymore
[19:46] <dtoebe> kyrofa, I have the `snappy` command after I installed snapcraft `--help` has `[activate, booted, build ...]`
[19:46] <dtoebe> ^ is that what you wereasking?
[19:46] <dtoebe> * were asking
[19:46] <kyrofa> dtoebe, which version of snapcraft?
[19:47] <dtoebe> kyrofa, 2.7
[19:47] <kyrofa> dtoebe, huh, I don't see it in debian/control
[19:48] <dtoebe> kyrofa, I got it from http://us.archive.ubuntu.com/ubuntu xenial/universe amd64 Packages
[19:48] <zyga> jdstrand: around?
[19:49] <jdstrand> yes, I will be looking at that stuff very soon
[19:49] <jdstrand> as for the variables. I think it is fine to get rid of the old ones, but I'm going to need to review the policy. are you planning on doing the policy updates?
[19:50] <jdstrand> I'm pretty sure we are going to want a SNAP_NAME_DBUS at a minimum if not SNAP_NAME_DBUS_CMD
[19:50] <zyga> jdstrand: yes
[19:50] <zyga> jdstrand: can we do dbus variables when we have real dbus interface
[19:50] <zyga> jdstrand: I'm trying to trim anything unsed and minimze what needs testing
[19:50] <jdstrand> I might mention that with frameworks gone, these variables are really just an implementation detail internal to snappy
[19:51] <zyga> jdstrand: yep, that's why I'd like to postpone those
[19:51] <jdstrand> didn't I see bluez just float by?
[19:51] <zyga> jdstrand: I'd like a quick eye on https://github.com/ubuntu-core/snappy/pull/838
[19:51] <zyga> jdstrand: bluez can wait a week :)
[19:51] <jdstrand> well, if you prefer to remove them and adjust the policy, I can then do the review of that
[19:51] <zyga> jdstrand: 16.04 can ship without it
[19:52] <zyga> jdstrand: I'll change policy next week; today just this please
[19:52] <zyga> jdstrand: and review earlier pings on github, we landed revisions
[19:52] <zyga> jdstrand: and dropped .developer entirely
[19:52] <jdstrand> what 'this' in 'just this'? the other commits not related to variables?
[19:54] <zyga> jdstrand: today is a bit crazy
[19:54] <zyga> jdstrand: various things have landed that relate to security
[19:54] <zyga> jdstrand: but mostly marginal
[19:55] <zyga> jdstrand: the branch I linked to above is the one that's not merged that I'd like a real review on
[19:55] <jdstrand> zyga: is there more than the branches you referenced earlier and github email?
[19:56] <zyga> jdstrand: not related to security
[19:56] <jdstrand> ok
[19:56] <zyga> jdstrand: look at git log, crazy day :)
[19:56] <jdstrand> nice!
[19:58] <zyga> jdstrand: I'm about to post the ifaces switch branch now
[20:09] <zyga> jdstrand: https://github.com/ubuntu-core/snappy/pull/854
[20:25] <elopio> kyrofa: sorry, you lost me. You can install ubuntu-snappy-cli in classic, and then you'll be able to run snap install.
[20:26] <kyrofa> elopio, yeah my comment was kind of pointless-- you can safely ignore it
[20:27] <jdstrand> zyga: 838 and 840 reviewed with comments
[20:33] <zyga> jdstrand: thanks!
[20:33] <zyga> jdstrand: fixed to 0644
[20:57] <jdstrand> zyga: oh wow, dropping .developer breaks list
[20:57] <jdstrand> $ /tmp/snappy list
[20:57] <jdstrand> Can not get the installed snaps: broken snap directory path: "/snaps/cap-test.mvo/2.2b1-3.16.04.5"
[20:57] <mvo> jdstrand: yes, sorry
[20:57] <mvo> jdstrand: its all broken
[20:57]  * jdstrand manually uninstalls everything
[20:57] <mvo> jdstrand: and its getting worse
[20:57] <jdstrand> heh
[20:57] <mvo> jdstrand: revisions are also landing
[20:57] <mvo> but at some point it will get better
[20:57] <mvo> it must!
[20:58] <jdstrand> yes! :)
[20:58]  * jdstrand hugs mvo, zyga, niemeyer and Chipaca` 
[20:58] <jdstrand> I know I missed people
[20:58] <zyga> jdstrand: snappy?
[20:58] <zyga> jdstrand: snappy is gone
[20:58] <zyga> jdstrand: try snap list
[20:59] <jdstrand> the README.md still says to build snappy
[20:59]  * jdstrand builds snap
[21:00] <jdstrand> $ /tmp/snap list
[21:00] <jdstrand> error: cannot list snaps: not found
[21:00] <jdstrand> zyga: I may have some trouble testing your overload branch at this point. I don't mean to distract you
[21:00] <jdstrand> overlord*
[21:00] <zyga> jdstrand: yes, it's all broken-ish
[21:00] <zyga> jdstrand: I can tell you how to test it in a sec
[21:06] <zyga> jdstrand: okay
[21:07] <zyga> jdstrand: I'm using github.com/zyga/devtools
[21:07] <jdstrand> I have that branch here. never used it
[21:07] <zyga> jdstrand: pull it and try
[21:07]  * jdstrand pulled
[21:08] <zyga> jdstrand: build a pc image and run a pc vm
[21:08] <zyga> jdstrand: then run ./refresh-bits snap snapd setup run-snapd
[21:08] <zyga> jdstrand: with a fresh pull of the branch we're talking about (pull just in case, I push --forced it once or more)
[21:09] <zyga> jdstrand: then in another tty ssh to the box (ssh snappy-vm if you do follow ssh configuration instruction)
[21:09] <zyga> jdstrand: and run sudo ./snap install hello-world
[21:09] <zyga> jdstrand: then play with security files and see what's going on
[21:09] <zyga> jdstrand: ask me anything anytime
[21:10] <jdstrand> Failed to verify integrity of http://people.canonical.com/~mvo/all-snaps/ubuntu-device-flash
[21:11] <mvo> jdstrand: yes, zyga needs to update his script
[21:11] <zyga> mvo: oh, sorry, I just noticed
[21:11] <zyga> mvo: what's the new hash?
[21:12] <jdstrand> 5702008cf61124d7a44f9a0fddc6e466b8a87d3d0e7d3fe04993081986e190c4080ebcd402b720fc4033c988667d9cd623c37ac44ee34fd3daae1ae398797fd1
[21:13] <zyga> jdstrand: thanks, pushed
[21:13]  * zyga is building a new image now
[21:17]  * jdstrand is tapping fingers
[21:18] <jdstrand> ok, finally a login
[21:18] <zyga> jdstrand: cool
[21:18] <zyga> jdstrand: try it :)
[21:18] <jdstrand> no network
[21:18] <mvo> jdstrand: run sudo snap firstboot
[21:18] <mvo> jdstrand: did I mention that its all broken?
[21:19] <jdstrand> mvo: you did, and then zyga convinced me to keep going :)
[21:22] <zyga> jdstrand: note that connect/disconnect/interfaces are detached from reality
[21:22] <zyga> jdstrand: but security policy generation is okay (except that there are no connections yet)
[21:23] <zyga> jdstrand: and I got connect/disconnect/interfaces done but with broken tests that need some love to show the code really works
[21:23] <zyga> jdstrand: I'll do that tomorrow
[21:23] <zyga> jdstrand: next week it should start to look norma
[21:23] <zyga> normal*
[21:25] <jdstrand> cool
[21:28] <zyga> jdstrand: did you get to install hello-world?
[21:28] <jdstrand> no
[21:28] <jdstrand> I can't get networking to work
[21:28] <zyga> jdstrand: ah
[21:28]  * zyga tries
[21:28] <jdstrand> I have an ip, but I can't ssh into it
[21:29] <jdstrand> the device can't ping either
[21:29] <zyga> jdstrand: can you login from the console?
[21:29] <jdstrand> yes
[21:29] <jdstrand> hmm, but snap find from the device works, so some networking is there
[21:30] <zyga> jdstrand: mvo just merged that!
[21:30] <zyga> jdstrand: we'll patch up the remaining issues over the next few days
[21:31] <jdstrand> ok, well, if I can't login I can't update snap and snappy
[21:31] <jdstrand> I think maybe I'll circle back around
[21:31] <zyga> jdstrand: it's one of the things that cannot be done cleanly without a lot of time
[21:31] <jdstrand> that's fine. I'm not complaining
[21:31] <jdstrand> just trying to help. seems I'm distracting more than helping
[21:31] <jdstrand> so I'll leave it alone for the moment and put it through its paces next week
[21:32] <zyga> jdstrand: your help is much appreciated; I'm sorry you cannot test this reliably right now
[21:32] <zyga> jdstrand: thanks!
[21:32] <jdstrand> like I said, it's fine :)
[21:32] <jdstrand> you're more than welcome :)
[21:32] <jdstrand> thanks for all the hard work on all of this :)
[21:33] <jdstrand> like mvo said, it'll be better soon (of course, I'm talking about more than just the image :)
[21:33] <mvo> jdstrand: I fixed the firstboot thing
[21:34] <jdstrand> cool
[22:39] <cjwatson> ogra_: no, that wasn't "the builders are borked", that was "there is a relatively rare race condition that isn't totally fixed until infinity rebuilds the chroots, but it's nothing new and in the meantime just retry the build"
[22:39] <cjwatson> not every build problem is "the builders are borked"
[22:46] <oparoz> Could someone please confirm that the builders don't prompt for a password when using sudo in a Makefile?
[22:49] <cjwatson> oparoz: In a package build?  Nack - you don't get root.
[22:50] <cjwatson> oparoz: Classically all you need is fakeroot to make tar think files are owned by root and suchlike.
[22:51] <cjwatson> oparoz: Hm, I think we may run snapcraft as root though.  Should probably fix that to avoid accidents.
[22:51] <oparoz> cjwatson: Ah, thanks cjwatson. I need to add a symlink to /lib because libtool freaks out. Travis allows sudo, but maybe they don't allow /lib hacking
[22:51] <cjwatson> oparoz: I've spent a lot of time with libtool and never ever ever seen that actually being necessary.  I suspect other solutions are available.
[22:53] <oparoz> cjwatson: Probably hacking the configure script, but I don't have the knowledge to do it. The libs are in the staging area, -I and -L include all the needed paths and yet the script ends up trying to do something with /lib
[22:54] <cjwatson> snapcraft pull may require sudo, maybe that's why we called it as root in the first place.  But now that we run the pull phase separately anyway ...
[22:54] <cjwatson> maybe LD_LIBRARY_PATH?
[22:54] <cjwatson> I'd suggest arranging for libtool to run with set -x.  You'll get a ton of output but it's generally at least possible to debug it from that
[22:54] <oparoz> cjwatson: I tried that and everything I could think of in terms of switches, but it always fail with a grep error
[22:55] <cjwatson> Hacking /lib is very very evil and we should go to all lengths not to need that
[22:55] <cjwatson> Anyway, /me -> bed
[22:55] <oparoz> cjwatson: I agree :). That was a temp solution while I wait to see if the project can fix its builder, if possible
[22:57] <oparoz> cjwatson: But thanks for the tip about -x. I did try to use a different shell for the Makefile, but al I get is the list of calls, but no debud info