[02:27] <tgm4883> So if I'm suppose to put binaries inside this snappy package, does that mean I need multiple packages to be able to support multiple arches?
[07:25] <davidcalle> Good morning
[07:48] <ogra_> tgm4883, you can put all arches into one (in subdirs) at the cost of size ... and have a wrapper script select the right binaries
[08:26] <willcooke> Thinking out loud here; on Desktop with Snappy, once all the apps are moved out of the image and in to Snaps, lets assume that there is a security update required in a particular "thing" in the image.
[08:26] <ogra_> you will get an image upgrade
[08:26] <willcooke> At the moment we can update individual libraries, within reason
[08:27] <willcooke> and so we could be pushing out an update a week on U7/.deb
[08:27] <willcooke> and that might be a few hundred K
[08:27] <willcooke> In the Snappy world, does this mean we would push out a whole new image?
[08:27] <ogra_> on snappy it will be less
[08:27] <willcooke> And if so, it's likely to be large
[08:27] <ogra_> since we provide deltas ...
[08:27] <willcooke> ahh, nice
[08:27] <willcooke> yes
[08:27] <willcooke> deltas FTW
[08:28] <willcooke> thanks ogra_
[08:28] <ogra_> so you only recieve the changes, not a full new package
[08:28] <ogra_> they will be bundled in an image upgarde though, that is indeed right
[08:28] <willcooke> but that upgrade could be tiny
[08:29] <ogra_> it is likely big because we'll collect a bunch of issues in an upgrade ... but the single fix is smaller overall
[08:29] <ogra_> (and for security issues there might be hotfix images with only that one change perhaps)
[08:29] <willcooke> So are you saying it would be upgraded less frequently?
[08:29] <ogra_> on the phone we currently manage 4-6 week cycles
[08:30] <willcooke> oki
[08:30] <willcooke> that's impressive :)
[08:30] <ogra_> but that is with all QA resources used already
[08:30] <ogra_> i suspect we need to get better here as we spread the spectrum of images
[08:31] <willcooke> +1
[08:31]  * willcooke speaks to QA
[08:31] <willcooke> seb128, fyi (but I expect you already knew all this) ^^
[08:31]  * willcooke -> meeting
[08:31] <willcooke> cheers ogra_
[08:31] <willcooke> always a pleasure
[08:31] <ogra_> :)
[08:32] <seb128> willcooke, yeah, but thanks for the ping anyway ;-)
[08:33] <JamesTait> Good morning all; happy I Need A Patch For That Day! 😃
[09:49] <Chipaca> mvo: you around?
[10:19] <Chipaca> mvo: ullo?
[10:19] <mvo> Chipaca: hey
[10:19] <Chipaca> mvo: hiya
[10:19] <Chipaca> mvo: was looking at https://code.launchpad.net/~mvo/snappy/selftest-docker-robustness/+merge/259734 and wondering why you don't use systemctl's pattern instead of passing it through grep?
[10:20] <mvo> Chipaca: I don't know, I guess using systemctl makes way more sense :)
[10:20] <Chipaca> mvo: it's a glob, not a regex, but other than that
[10:21] <mvo> Chipaca: cool, I will update, thanks a bunch
[10:21] <Chipaca> mvo: on the other hand
[10:21] <Chipaca> mvo: systemctl does not fail on no matches
[10:22] <Chipaca> mvo: so you either still need to grep (in which case, meh), or do something like
[10:22] <Chipaca> systemctl show whatever*.service --property 'Id'
[10:22] <Chipaca> and check for empty string
[10:22] <Chipaca> mvo: and at this point i think i'm bikeshedding :)
[10:23] <Chipaca> mvo: sorry. will +1 as is.
[10:24] <Chipaca> there
[10:24] <mvo> Chipaca: :)
[10:24] <mvo> Chipaca: all good, thank you very much
[10:25] <Chipaca> mvo: sergiusens: did you guys see my email wrt tmpreaper?
[10:27] <mvo> Chipaca: yes, I think its a good idea I need to reply properly
[10:27] <Chipaca> ah, ok
[10:27] <mvo> Chipaca: had a bit of a single-minded-hacking morning with the upgrade tests
[10:27] <Chipaca> i'm not impatient about the response, it's that i so rarely shoot off emails like that i wondered if it was still an effective means of communication :)
[10:37] <sergiusens> Chipaca: it is effective at getting to people, not sure about getting back a proper response :P
[10:41] <Chipaca> :)
[11:21] <asac> anyone understands the "Can we make renames work?
[11:21] <asac> "
[11:21] <asac> thread?
[11:21] <asac> is that an issue at all for snappy?
[11:22] <asac> or just phone?
[11:22] <asac> mvo: ?
[11:23] <ogra_> asac, it is an issue with processes trying to create a backup file or some such when you have no writable dir (but only made the file writable via a bind mount)
[11:24] <ogra_> i suppose it affects snappy too if bind mounts are used for wriability
[11:24] <ogra_> *writability
[11:25] <mvo> well, we generally know what wants to write
[11:25] <ogra_> well, for creating a new file we have no concepts with the bind mounts
[11:27] <ogra_> imagine my daemon creates /etc/foo.conf-bak every time it writes to /etc/foo ... if /etc/foo.conf-bak doesnt exist as a bind mounted empty file and /etc isnt writable the daemon will fail to make the backup file
[11:27]  * Laney was summoned
[11:28] <ogra_> so you either need to know in advance how that backup file (or worse, temp file) is called and have an existing bind mount ... or /etc is writable
[11:28] <Laney> renaming a mount point doesn't work
[11:28] <ogra_> right
[11:28] <Laney> that's why we have to have the directory
[11:28] <Chipaca> I think xnox'es “conig-less” efforts line up with this quite nicely, me
[11:28] <ogra_> the directory Laney refers to is /etc/writable ...
[11:28] <Chipaca> config-less*
[11:29] <ogra_> so the hack we currently use is to put /etc files into that dir and add an additional bind mount on top
[11:29] <Laney> kind of, but you still want to have atomic renaming work
[11:29] <ogra_> that way the process finds a writable dir to do its atomic changes and temp file creation etc
[11:31] <sergiusens> ogra_: mvo asac it shouldn't affect snappy core, we have mostly nothing in there
[11:31] <ogra_> asac, effectively it boils down to "we should use overlayfs, but if we cant it would be nice to find something more elegant than bind mounts to allow atomic writes"
[11:31] <ogra_> sergiusens, my mount command disagrees
[11:31] <ogra_> (and my fstab too)
[11:32] <sergiusens> ogra_: your daemon can't create /etc/foo.conf-bak though, that would never be accepted
[11:32] <ogra_> heh, someone tries IRC on his phone :)
[11:32] <mvo> well, I think the end goal is what pitti wrote, move stuff out of etc. and like sergiusens said, not a biggie for us on core yet
[11:32] <ogra_> sergiusens, it can ... if we use the /etc/writable hack
[11:33] <ogra_> that is why we have it :)
[11:33] <ogra_> (amd64)ubuntu@localhost:~$ ls /etc/writable/
[11:33] <ogra_> hostname  localtime  timezone
[11:33] <ogra_> and we even use it on snappy
[11:35] <sergiusens> ogra_: I don't like /etc/writable though
[11:36] <ogra_> sergiusens, nobody does, that is what the discussion is about :)
[11:37] <sergiusens> ogra_: I thought it was more general though, random libraries wanting to do things on read only locations
[11:37] <ogra_> i'd keep /etc writable and put an apparmor profile on top making everything readonly with a whitelist of exceptions ... done
[11:38] <sergiusens> ogra_: the problem of making global locations writable is that you would need to maintain compat, we also need to be able to rollback (for the a/b model)
[11:38] <ogra_> sergiusens, it surely is a wider thing long term ... currently the only big wart we have is /etc/writable ... in the future we would probably end up with /usr/lib/writable, /var/writable and so on
[11:38] <ogra_> before we have to do the latter we should have found a better mechanism ;)
[11:41] <asac> Laney: thanks. i was confused what this rename thing means for snappy
[11:41] <asac> but i think others understand it so i will have them explain it to my small brain :)
[11:42] <Laney> oh yes I think it's a well known problem
[11:42] <Laney> just came up once again so I thought we better think about it systematically :)
[12:58] <jgdx> question, why the xz format for snappy images?
[12:59] <ogra_> size
[12:59] <mvo> jgdx: my guess is best compression ratio, do you see a issue with that or are you just curious?
[13:00] <ogra_> (it comes originally from the size limitation the /cache partition puts upon us on phones)
[13:00] <jgdx> mvo, just curious, but a friend of a friend has an issue with image downloads not being consistent in format
[13:00] <jgdx> device tarballs, ubuntu desktop isos, snappy xz :p
[13:03] <mvo> heh :) fair point
[13:08] <sergiusens> jgdx: well snappy is a deb though ;-)
[13:09] <seb128> sergiusens, mvo, hey, is there any documentation somewhere on installing snappy on a amd64 laptop config (if that's even possible, or if it's not is anyone working on that)?
[13:12] <mvo> seb128: you can just dd the image to a usb stick or hdd and boot from that
[13:12] <sergiusens> seb128: we have nothing yet that can lay it out on your internal disk in an easy way and no docs specifically mentioning laptops but running from a usb drive is possible
[13:12] <seb128> mvo, does that support secure boot/uefi?
[13:13] <sergiusens> it should support uefi (the published images don't yet)
[13:13] <seb128> my test laptop doesn't boot from unsigned device I think
[13:13] <mvo> aha, nice, so u-d-f images can now do uefi? thats cool
[13:13] <seb128> I once tried to boot a i386 desktop iso and the system was not even seeing the key as a boot device
[13:14] <seb128> sergiusens, so I need to use an "unpublished image"? where do I find those?
[13:14] <sergiusens> mvo: yes, slangasek added support for uefi to u-d-f
[13:14] <sergiusens> seb128: you need to create one
[13:15] <elopio> good morning.
[13:15] <seb128> sergiusens, any documentation on how to do that? ;-)
[13:15] <elopio> mvo: want to talk about the tests now? Should we just chat here?
[13:15] <ogra_> sergiusens, i think there is currently a bug with UEFI ... i saw slangasek and tbr discuss it recently
[13:16] <sergiusens> oh
[13:16] <ogra_> bug 1425370
[13:16] <sergiusens> seb128: in theory just running 'u-d-f core 15.04 --output amd64.img' should do the trick
[13:16] <seb128> sergiusens, thanks (let's see if practice matches theory ;-)
[13:17] <sergiusens> seb128: there is documentation but I don't recall where it is, but the bug ogra_ mentions might impact you
[13:17] <seb128> ogra_, that's fix released
[13:17] <mvo> elopio: yes please! we can use whatever medium works best for you, irc, hangouts, mumble
[13:17] <sergiusens> ogra_: yeah, slangasek wrote code to fix that bug ;-)
[13:17] <ogra_> seb128, yeah, 13h ago ... i'm a little behind :P
[13:18] <seb128> ogra_, :-)
[13:18] <ogra_> sergiusens, it was re-opened after that ... but turned out to be the qemu UEFI firmware
[13:18] <sergiusens> ogra_: I wonder who marked it as u-d-f fails to build (snappy changed)
[13:18] <elopio> lets just start here, because I might have to leave for a meeting. Not sure what's the schedule for the sprint today.
[13:18] <ogra_> so it was closed last night again
[13:19]  * sergiusens needs to catch up on the snappy changes for webdm and u-d-f
[13:19] <elopio> I'll just list some things I would like to see. We should probably choose only the ones that allow us to go faster and safer.
[13:19] <rickspencer3> sergiusens, lool, I just set up my rpi2 with sergiusens's latest image, seems to be working perfectly
[13:19] <elopio> the tests should be independent. You should be able to run them in any order, or select only one and get a good result.
[13:20] <lool> rickspencer3: cool
[13:20] <lool> sergiusens: what had you changed? you just included webdm? did you also add fixrtc?
[13:20] <rickspencer3> sadly, it does not respond to ssh ubuntu@webdb.local, but perhaps that is a user error ;)
[13:21] <sergiusens> lool: your image was created a day before release, that same day, mvo made oem package types non forkable removing the .origin from them
[13:21] <elopio> we need a better framework for setups, assertions, and test case definition. Moving to go would solve this, of course. There are also some bash frameworks, but (...)
[13:21] <lool> sergiusens: ah yes, I have to push the renamed oem snap too
[13:21] <sergiusens> lool: webdm was built out of the latest snappy so it rejected that package completely (if the layout is wrong I call it a broken system)
[13:21] <elopio> we need a better report of the results. subunit would be awesome, but junit or anything like that would do.
[13:22] <elopio> the tests should define their own environment as much as possible. Asserting for regular expressions because we don't fully control the versions we are installing or the messages we are getting back is not so good.
[13:24] <elopio> and I would like the tests to be more readable, at least the ones that are end-to-end from the point of view to the user.
[13:25] <elopio> like have every statement in the test be an action, and that would make the test look more like what you get with behaviour-dd.
[13:26] <sergiusens> @reviewlist
[13:26] <nothal> https://code.launchpad.net/~chipaca/ubuntu-core-launcher/unshare/+merge/258367 | Approve: 2 (14 days old)
[13:26] <elopio> finally (for now), we need to start thinking about tests that need actions both from the host and the testbed, like making sure that you can open webdm from your PC.
[13:26] <nothal> https://code.launchpad.net/~sergiusens/webdm/queryPackageNames/+merge/258640 | No reviews (12 days old)
[13:26] <nothal> https://code.launchpad.net/~sergiusens/snappy/ubootNoUnnecessaryRewrites/+merge/259739 | Approve: 1 (less than a day old)
[13:26] <nothal> https://code.launchpad.net/~mvo/snappy/snappy-merge-integration-tests/+merge/259592 | Needs Information: 1, Approve: 1 (less than a day old)
[13:26] <nothal> https://code.launchpad.net/~mvo/snappy/snappy-fix-ftbfs-sbuild/+merge/259479 | Approve: 1 (1 day old)
[13:26] <sergiusens> rsalveti: ^
[13:26] <sergiusens> nothal: help me help you
[13:26] <rsalveti> yeah, that's cool
[13:26]  * Chipaca hugs nothal 
[13:26]  * nothal hugs Chipaca 
[13:27] <Chipaca> was it @help, or was it @list?
[13:27] <Chipaca> @help
[13:27] <nothal> "list" To see the available commands ; "help cmd" for specific command help
[13:27] <Chipaca> @list
[13:27] <nothal> The available commands are: ['bug', 'critical', 'help', 'last', 'list', 'more', 'ping', 'reviewlist', 'seen']
[13:27] <elopio> maybe it's enough to make sure that it works in localhost, and that you can access the board's ip from outside. Or maybe we need an end-to-end test also for that.
[13:27] <Chipaca> @help critical
[13:27] <nothal> show the crtical bugs for self.project (could be a meta project)
[13:27] <Chipaca> @critical
[13:27] <Chipaca> @seen mvo
[13:27] <nothal> Chipaca: [05/21/15 13:17:29] elopio: yes please! we can use whatever medium works best for you, irc, hangouts, mumble
[13:27] <elopio> mvo: do you have any items you would like to see in the tests?
[13:27] <Chipaca> @help last
[13:27] <nothal> Muestra que fue lo último que dijo un usuario.
[13:28] <sergiusens> lol
[13:28] <Chipaca> @last sergiusens
[13:28] <nothal> Chipaca: [05/21/15 13:28:02] lol
[13:28] <sergiusens> translations :-)
[13:28] <Chipaca> hal, dance for us
[13:28] <Chipaca> nothal, dance for us
[13:28] <Chipaca> duurn
[13:28] <Chipaca> not all plugins are there :)
[13:28] <Chipaca> anyway, things like bug #1449032 work
[13:28] <nothal> Bug #1449032: delay when upgrading <Snappy:Triaged> <http://launchpad.net/bugs/1449032>
[13:29] <Chipaca> now now bots, no fighting
[13:30] <elopio> mvo: http://paste.ubuntu.com/11264293/ so you don't have to dig on the backlog.
[13:30] <rsalveti> mvo: do we have any sort of brain dump somewhere that describes our goal for self-tests and so on?
[13:30] <rsalveti> but it seems you're working with elopio already, which is great
[13:31] <rsalveti> just trying to understand the missing pieces :-)
[13:31] <mvo> elopio: thanks a lot, that helps indeed :)
[13:31] <mvo> elopio: and sorry for the delay, was just reading some exciting code from sergiusens and forgot the world around me
[13:32] <mvo> rsalveti: >< thats my brain right now :P but seriously, I don't think we do have something written down, let me add that to the README and I point you it once thats done(?)
[13:32] <elopio> mvo: :) no problem. And feel free to disagree.
[13:32]  * elopio goes to find the exciting code.
[13:34] <mvo> elopio: http://snappy.asac.ws:9001/p/snappy-better-test and I do not disagree at all
[13:37] <sergiusens> mvo: thanks for the review, will fix when i get back
[13:38] <mvo> sergiusens: yeah, no worries, nice to see this branch really
[13:56] <rsalveti> mvo: yeah, nothing formal, most important now would be the stuff we don't yet have for it, so we keep track while elopio gets up to speed
[13:56] <rsalveti> but love what you got already
[14:01] <mvo> has anyone seen "May 21 13:42:07 localhost.localdomain kernel: FAT-fs (mmcblk0p1): IO charset iso8859-1 not found  " before?
[14:01] <mvo> looks like my BBB is broken
[14:01] <ogra_> thats a vfat complaint
[14:02] <ogra_> ppisati, ^^^ do we have the right nls codepages builtin ?
[14:13] <mvo> ogra_, ppisati: I created https://bugs.launchpad.net/snappy/+bug/1457491 to track this
[14:22] <ogra_> mvo, well, your bootloader partition seems to be unreadable now ... how would it recover from that ?
[14:23] <ogra_> (givcen the logic for the roll back is actually inside the file it cant read)
[14:23] <mvo> ogra_: it did recover, i.e. it booted back into r41 after I power-cycled
[14:24] <ogra_> well, one vfat is corrupt here
[14:24] <ogra_> i thought jodh added fsck's all over the place for this in initrd
[14:24] <mvo> right, it seems like it fixed it correctly though
[14:24] <mvo> it == fsck
[14:25] <mvo> I can access /boot/uboot/snappy-system.txt and it looks valid
[14:25] <mvo> and it booted
[14:25] <ogra_> yeah, but that it cant rollback seems pretty normal to me if it cant read the file ... we perhaps need to add hardcoded logic that forces a reboot when that happens
[14:26] <mvo> elopio, rsalveti: http://snappy.asac.ws:9001/p/snappy-better-test is a draft to get some background for why and what for the selftest. I (of course) agree that its not ideal and we want to make it better
[14:27] <mvo> if that looks good I will move it into the snappy-selftest branch
[14:27] <ppisati> mvo: do you hve the modules installed?
[14:27] <mvo> ppisati: I don't know, let me look. this is on snappy
[14:28] <elopio> mvo: what you wrote about running on each MP is gooood.
[14:28] <mvo> elopio: its partly done in https://code.launchpad.net/~mvo/snappy/snappy-merge-integration-tests but probably a bit clumsy, I need to wrap my head around adt harder :)
[14:29] <mvo> elopio: but yeah, I absolutely want this, we had regression before the release that the selftest would have caught if it was run more often (daily is not enough for us, we are a quick bunch :)
[14:29] <mvo> ppisati: eh, I think I have not because the modules are on /boot/uboot and that is the vfat partition that it tries to mount to find the modules …
[14:30] <elopio> I think I would split the suite in two. One for cli conformance, just making sure that the commands can be called and return a sensible message. (now I understand why the regexes are there)
[14:30] <elopio> and one that's end-to-end testing stories, or journeys, or however you want to call them.
[14:31] <elopio> making a note of this.
[14:31] <elopio> mvo: I saw your branch, and loved it.
[14:31] <elopio> Still trying to find some time here to focus and give it a try.
[14:31] <mvo> elopio: I like the idea of splitting this up, thats cool
[14:39] <ppisati> mvo: ???
[14:39] <ppisati> mvo: how can the kernel modules be located on the vfat partition?
[14:39] <ppisati> mvo: they are in /lib/modules/$(uname -m)/kernel/...
[14:40] <mvo> ppisati: meh, nervermind, I am talking nosense
[14:40] <ogra_> no, they should be in the initrd
[14:40] <ogra_> but i think this is rather filesystem corruption, the codepage complaint is just fallout
[14:42] <mvo> ppisati: its availalbe on both partitions AFAICT (the nls_iso8859-1.ko module), let me dig deeper
[17:18] <OerHeks> Is there a snappy core build for this? http://www.nasa.gov/image-feature/ten-engine-electric-plane-prototype-takes-off
[17:19] <ogra_> OerHeks, just send the hardware over to me, i'll port it :)
[17:20] <OerHeks> just asking before i buy one ogra_
[17:20] <OerHeks> But it looks like doable
[17:21] <ogra_> it doesnt really talk about what kind of HW is inside
[18:32] <rickspencer3> is there an easy way I can ssh into two snappy images running at the same time on my laptop?
[18:32] <rickspencer3> I want to develop the client and server bits simultaneously, and test them interacting, etc...
[18:50] <asac> rickspencer3: sure
[18:50] <rickspencer3> hi asac
[18:50] <asac> rickspencer3: you start kvm?
[18:50] <asac> how?
[18:50] <rickspencer3> yes it is running
[18:50] <rickspencer3> I used the command on the web site
[18:50] <asac> right
[18:50] <asac> so
[18:50] <rickspencer3>  kvm -m 512 -redir :8090::80 -redir :8022::22 ubuntu-15.04-snappy-amd64-generic.img
[18:50] <asac> start the second one
[18:50] <rickspencer3> I built the go web server example and snappy remoted to it
[18:50] <asac> with -redir :8091::80 -redir :8023::22
[18:50] <rickspencer3> but I don't know how to find it
[18:51] <asac> then they will listen on different ports
[18:51] <rickspencer3> in my browser, I mean
[18:51] <asac> so your ssh on the second one will be on 8023
[18:51] <rickspencer3> ok, that's cool
[18:51] <asac> and the webser of the second one on 8091
[18:51] <asac> rickspencer3: see how you map those ports to the ports in the VM :)
[18:51] <asac> to :80
[18:51] <asac> and :22
[18:51] <asac> :P
[18:51] <asac> 80 is http
[18:51] <asac> and 22 ssh
[18:51] <rickspencer3> right
[18:52] <rickspencer3> but I don't understand what hte url would be
[18:52] <asac> rickspencer3: what is your current url?
[18:52] <rickspencer3> I woudl have expected that I get the ip address and then just go there
[18:52] <rickspencer3> the ip address of the instance, I mean
[18:52] <asac> ohhhh
[18:52] <asac> you want the client to call the server?
[18:52] <asac> thats trickier
[18:53] <asac> let me check something
[18:53] <rickspencer3> asac, first, I want to call the server from a browser on my desktop so I can confirm my web server is working in teh snappy instance
[18:53] <rickspencer3> then I want to write a program in the second instance that uploads data to the web server in the first instance
[18:53] <rickspencer3> so I can write the code for the device and cloud at the same time :)
[18:54] <asac> should still work
[18:54] <asac> on the first instance you can just then access the second instance through the IP of your host
[18:54] <asac> with the port of the second instance
[18:55] <rickspencer3> ok, for the browser part to confirm the web server is working, I call local host at the mapped port?
[18:55] <rickspencer3> localhost:8090?
[18:55] <asac> yep[... just http://localhost:8091/
[18:55] <asac> right
[18:55] <asac> or your local ip
[18:55] <asac> try witjh your local ip too ... in case the kvm only maps to localhost
[18:56] <asac> then you would have a problem calling from first to second instance like above
[18:57] <rickspencer3> hmmm
[18:57] <rickspencer3> asac, according to snappy list, the web server is installed, do I need to do somehting to start it running?
[18:57] <rickspencer3> I assumed snappy install started it
[18:58] <asac> it should
[18:58] <asac> which one did you install?
[18:58] <asac> the go-example one?
[18:58] <rickspencer3> yes
[18:58] <rickspencer3> I just built it and installed it
[18:58] <asac> rickspencer3: that thing is not listening on :80
[18:58] <asac> let me check
[18:58] <rickspencer3> oh fudge
[18:58] <rickspencer3> it says 8081
[18:58] <asac> rickspencer3: yeah just change the kvm cli
[18:58] <asac> and it will work
[18:59] <asac> so :80 -> :8081
[18:59] <rickspencer3> ok
[19:00] <rickspencer3> asac, sorry, do you mean I should just delete the -redir stanza?
[19:00] <rickspencer3> i.e. not redirect it
[19:00] <asac> rickspencer3: you need to redirect... just to a different port
[19:00] <asac> currently you redirecting to port 80
[19:00] <asac> e.g. :8091::80 -> :8091::8081
[19:01] <rickspencer3> but why redirect at all
[19:01] <asac> rickspencer3: because kvm doesnt export ports at all
[19:01] <rickspencer3> couldn't I just delete it and do localhost:8081 ?
[19:01] <asac> to your host
[19:01] <rickspencer3> ok
[19:01] <rickspencer3> good reason
[19:01] <asac> rickspencer3: you would need to setup bridge networking
[19:01] <asac> then your kvm would get its own ip etc.
[19:01] <asac> dont ask me how :)
[19:02] <rickspencer3> so this should make localhost:8091 work if the web server is working?
[19:02] <rickspencer3> kvm -m 512 -redir :8091::8081 -redir :8022::22 ubuntu-15.04-snappy-amd64-generic.img
[19:03] <asac> rickspencer3: if the webserver listens on port 8081 then yes
[19:03]  * asac installs
[19:05] <asac> rickspencer3: for me it listens to 8081
[19:05] <rickspencer3> asac, not sure what you mean
[19:06] <rickspencer3> are you saying that it jsut works for you?
[19:06] <asac> kvm -m 768 -redir :8080::8081 -redir :8022::22 snappy-amd64.img
[19:06] <asac> browser: http://localhost:8080
[19:06] <asac> -> "Hello World"
[19:08] <rickspencer3> you installed it from the store?
[19:08] <asac> yeah
[19:08] <asac> sudo snappy install go-example-webserver
[19:08] <asac> let me start with a fresh image :)
[19:08] <rickspencer3> ok, I built it and installed it with snappy-remote
[19:09] <asac> rickspencer3: ok lets first check that your system is sane
[19:09] <asac> rickspencer3: stop all KVMs
[19:09] <rickspencer3> done
[19:09] <asac> rickspencer3: netstat -an | grep 8090
[19:09] <asac> should give you zero hits
[19:09] <asac> same for
[19:09] <asac> rickspencer3: netstat -an | grep 8091
[19:10] <asac> then start KVM
[19:10] <asac> and check that
[19:10] <rickspencer3> wqhoops
[19:10] <rickspencer3> rick@rick-dell-11:~/snappy-images$ netstat -an | grep 8091
[19:10] <rickspencer3> unix  2      [ ]         DGRAM                    18091    /var/run/wpa_supplicant/wlan0
[19:10] <asac> right
[19:10] <asac> hmm
[19:10] <asac> thats fine
[19:10] <asac> thats a bad hit :)
[19:10] <asac> but doesnt hurt
[19:10] <rickspencer3> right
[19:10] <asac> so start kvm
[19:10] <asac> the one with 8090
[19:10] <rickspencer3> ima start it with kvm -m 768 -redir :8080::8081 -redir :8022::22
[19:10] <asac> after up check that you see  netstat -an | grep 8090
[19:10] <asac> having a LISTEN
[19:11] <asac> rickspencer3: ok then you should check that 8080 isnt used
[19:11] <asac> before starting
[19:11] <asac> like above
[19:11] <asac> could be something on it and kvm wont complain
[19:11] <asac> netstat -an | grep 8080
[19:11] <rickspencer3> shucks
[19:11] <rickspencer3> ok, I'll start with with kvm -m 768 -redir :8090::8081 -redir :8022::22
[19:12] <asac> :)
[19:12] <asac> ok
[19:12] <asac> check that its listening after its up
[19:12] <asac> netstat -an | grep 8090
[19:12] <rickspencer3> looks right
[19:12] <rickspencer3> rick@rick-dell-11:~/Projects/snappy-examples/go-example-webserver$ netstat -an | grep 8090
[19:12] <rickspencer3> tcp        0      0 0.0.0.0:8090            0.0.0.0:*               LISTEN
[19:13] <asac> good
[19:13] <asac> now ssh into it
[19:13] <asac> check that webserver is running at all :)
[19:13] <asac> or first check that its listening same way there
[19:13] <asac> just with 8081
[19:13] <asac> but pretty sure its not running :/
[19:14] <rickspencer3> k, in
[19:14] <rickspencer3> oh, I did shh -p8022 ubuntu@localhost
[19:14] <asac> yeah thats fine
[19:14] <asac> if you started with :8022::22
[19:15] <asac> netstat -an | grep 8081
[19:15] <asac> if you are in
[19:15] <rickspencer3> nada
[19:15] <asac> yeah
[19:16] <rickspencer3> so, something went wrong somewhere between when I built it and when I snappy-remote installed it, I guess
[19:16] <asac> not sure
[19:16] <asac> rickspencer3: ps -eaf | grep go-ex
[19:16] <rickspencer3> let me uninstall it, install ist from the store, and see what happens
[19:16] <asac> no hit?
[19:16] <asac> yeah you can try that first
[19:16] <rickspencer3> just grep ;)
[19:17] <asac> i think i know what is the problem for ou though
[19:17] <asac> but lets finish
[19:17] <asac> i guess from store it will work
[19:18] <rickspencer3> asac, nope
[19:18] <rickspencer3> http://localhost:8080/ should work?
[19:18] <asac> rickspencer3: how did you start kvm?
[19:19] <rickspencer3> oh fudge
[19:19] <asac> :8090::8081 ? then its :8090 :)
[19:19] <rickspencer3> right, forgot
[19:19] <rickspencer3> works now
[19:19] <asac> right
[19:19] <asac> ok lets check quickly if i am righht :)
[19:19] <rickspencer3> cool
[19:19] <rickspencer3> I am ready
[19:19] <asac> rickspencer3: on yhour host you ahve the go-example-... binary
[19:19] <asac> right?
[19:19] <rickspencer3> I do because I built it, yes
[19:19] <asac> right
[19:20] <asac> run ldd go-exampl*
[19:20] <asac> on it
[19:20] <rickspencer3> I did not bother building the arm one, though
[19:20] <asac> and post
[19:20] <asac> yeah thats fine
[19:20] <rickspencer3> rick@rick-dell-11:~/Projects/snappy-examples/go-example-webserver$  ldd go-exampl*
[19:20] <rickspencer3> go-example-webserver:
[19:20] <rickspencer3> 	linux-vdso.so.1 =>  (0x00007ffdbd3dc000)
[19:20] <rickspencer3> 	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f3265651000)
[19:20] <rickspencer3> 	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f3265287000)
[19:20] <rickspencer3> 	/lib64/ld-linux-x86-64.so.2 (0x00007f326589c000)
[19:20] <rickspencer3> go-example-webserver_1.0.7_multi.snap:
[19:20] <rickspencer3> 	not a dynamic executable
[19:21] <asac> hmm
[19:21] <asac> rickspencer3: did you put it into the magic-bin/... directory?
[19:21] <rickspencer3> nope
[19:21] <asac>  # change to the x86_64 directory and build the binary...
[19:21] <asac>  1. cd magic-bin/x86_64-linux-gnu
[19:21] <asac>  2. go build ../../
[19:21] <asac> thats in README :)
[19:21] <rickspencer3> I followed the readme
[19:21] <rickspencer3> let me delete the executable and try again
[19:22] <asac> rickspencer3: check that its in that magic-bin directory
[19:22] <rickspencer3> I am going to folow the directions again
[19:22] <rickspencer3> hmm, I think I didnt quite follow the directions
[19:23] <asac> ack
[19:23] <asac> magic-bin/go-example-webserver
[19:23] <asac> magic-bin/x86_64-linux-gnu
[19:23] <asac> magic-bin/x86_64-linux-gnu/go-example-webserver
[19:23] <asac> thats what you need
[19:23] <asac> the first one is a script
[19:23] <asac> the second one is the real binary
[19:23] <rickspencer3> asac, I do snappy build in the go-example-web-server dir, right?
[19:23] <asac> the first one is just figuring what architecture you are on and starts the right one
[19:23] <asac> rickspencer3: yeah... thats step 3 in the README
[19:23] <rickspencer3> oh
[19:23] <asac> last step is at top level dir
[19:24] <rickspencer3> let me rebranch and start from scratch :)
[19:25] <asac> rickspencer3: the last step is wrong i think ... cd ../.. it should be
[19:26] <rickspencer3> right
[19:26] <rickspencer3> I'm just rereading, trying to grock
[19:26] <rickspencer3> asac, I don't get what go build ../../ does
[19:27] <rickspencer3> how does that put the binary into magic-bin/x86_64-linux-gnu/go-example-webserver
[19:27] <rickspencer3> ?
[19:27] <asac> it puts the binary in the current directory
[19:27] <rickspencer3> oh
[19:27] <asac> and it uses the name of the directory of the main.go file
[19:27] <asac> its kind of magic :)
[19:27] <rickspencer3> so it's just a feature of go build
[19:28] <asac> but its also very basic
[19:28] <asac> yeah
[19:28] <asac> i think so :)
[19:28] <rickspencer3> ok, let me try snappy-remote again
[19:28] <asac> for anything more complex you would do it different
[19:28] <asac> we need to makea  goo dtutorial for that
[19:29] <rickspencer3> asac, this should work?
[19:29] <rickspencer3> well, there are multiple new concepts that I need to learn
[19:29] <rickspencer3> some are well known to linux engineers
[19:29] <rickspencer3> some are go
[19:29] <rickspencer3> and a few are snappy
[19:29] <rickspencer3> :)
[19:29] <rickspencer3> asac, like this?
[19:29] <rickspencer3> snappy-remote --url:ubuntu@localhost:8022 go-example-webserver_1.0.7_multi.snap
[19:29] <asac> no
[19:30] <rickspencer3> d'oh, forgot a command
[19:30] <asac> --url ssh://localhost:8022
[19:30] <asac> truy that
[19:30] <asac> $ snappy-remote --url=ssh://localhost:8022 install ./hello-world_1.0.5_all.snap
[19:30] <asac> is the one the main tutorial
[19:30] <rickspencer3> snappy-remote --url=ssh://localhost:8022 install go-example-webserver_1.0.7_multi.snap
[19:30] <asac> https://developer.ubuntu.com/en/snappy/tutorials/build-snaps/
[19:30] <rickspencer3> yeah, I get it
[19:30] <asac> right
[19:31] <asac> if you are lucky it starts afterwards
[19:31] <rickspencer3> was just a bunch of cruft I built up :)
[19:31] <asac> :)
[19:31] <rickspencer3> it says it is installing
[19:31] <asac> right
[19:31] <asac> you can be brave and just try the browser
[19:31] <asac> or first check that on the KVM you see now something listening on 8081
[19:31] <rickspencer3> I'll wait until it is done
[19:31] <asac> with the well known netstat grep from above :)
[19:31] <rickspencer3> well, I didn't take down the image
[19:31] <asac> thats fine
[19:31] <rickspencer3> I just uninstalled and then sideloaded
[19:32] <asac> right
[19:32] <asac> should work
[19:32] <asac> but you can check INSIDE the VM
[19:32] <rickspencer3> taking a while to install, thoguh
[19:32] <asac> if  something is listening on 8081
[19:32] <rickspencer3> well, it worked before :)
[19:32] <asac> hehe
[19:32] <asac> yeah
[19:33] <asac> so if you want to do a bit more sophisticaed stuff then just having a main.go (like including external go dependencies)
[19:33] <asac> i highly recommend to read https://golang.org/doc/code.html
[19:34] <rickspencer3> yeah, it's not running :,(
[19:35] <rickspencer3> I'll have to try following the instructions again, though I can't think what I did wrong
[19:35] <asac> :(((
[19:36] <asac> rickspencer3: are you on the system?
[19:36] <rickspencer3> yeah
[19:36] <rickspencer3> I checked netstat, and it's nothing is on port 8081
[19:36] <rickspencer3> snappy list shows it is there, though
[19:36] <asac> rickspencer3: can you directly run:
[19:37] <asac> /apps/go-exampl*/current/magic-bin/x86*/go-example-webserver ?
[19:37] <rickspencer3> sure
[19:37] <asac> what happens?
[19:37] <rickspencer3> works!
[19:38] <rickspencer3> asac, hmmm, I see that there is still a dir for the store version that I installed
[19:38] <rickspencer3> even though I removed it
[19:38] <asac> thats ok
[19:38] <asac> rickspencer3: is your sideloadewd one there?
[19:38] <asac> too?
[19:38] <rickspencer3> yes, and that is what I ran
[19:39] <asac> and what happens?
[19:39] <rickspencer3> it worked
[19:39] <asac> oha
[19:39] <asac> rickspencer3: please see what you get with sudo systemctl status go-example-webserver_webserver_1.0.7.service
[19:39] <rickspencer3> asac, while the server is running?
[19:40] <rickspencer3> this looks not promising
[19:40] <rickspencer3>   Process: 1080 ExecStart=/usr/bin/ubuntu-core-launcher go-example-webserver.sideload go-example-webserver.sideload_webserver_1.0.7 /apps/go-example-webserver.sideload/1.0.7/magic-bin/go-example-webserver (code=exited, status=1/FAILURE)
[19:40] <rickspencer3>  Main PID: 1080 (code=exited, status=1/FAILURE)
[19:41] <rickspencer3> here's the whole thing
[19:41] <rickspencer3> http://pastebin.ubuntu.com/11269852/
[19:43] <asac> rickspencer3: can you make your terminal wider? the last lines are super short
[19:44] <rickspencer3> here ya go
[19:44] <rickspencer3> http://pastebin.ubuntu.com/11269898/
[19:45] <asac> rickspencer3: please add the -l after status
[19:45] <asac> then we get the full lines
[19:45] <asac> i tjhink
[19:45] <rickspencer3> http://pastebin.ubuntu.com/11269916/
[19:45] <rickspencer3> looks the same, but *shrug*
[19:47]  * asac tries himself
[19:47] <Chipaca> /apps/go-example-webserver.sideload/1.0.7/magic-bin/go-example-webserver: line 47: cannot create temp file for here-document: Permission denied
[19:47] <Chipaca> rickspencer3: asac ^
[19:48] <asac> yeah i see that
[19:48] <asac> whast that?
[19:48] <Chipaca> let me look at the code
[19:48] <asac> ok
[19:48] <asac> i have it
[19:48] <Chipaca> is this the regular go-example-wbserver?
[19:48] <asac> mvo broke our example :(
[19:49] <asac> rickspencer3: bzr pull please
[19:49] <rickspencer3> leave it to me make every mistake, hit every bug
[19:49] <asac> and then sanppy build
[19:49] <asac> and then its done
[19:49] <rickspencer3> I really need to be in QA
[19:49] <rickspencer3> kk
[19:49] <rickspencer3> asac, do I need to snappy remove it first?
[19:49] <rickspencer3> on the target, I mean?
[19:50]  * rickspencer3 removes to be sage
[19:50] <rickspencer3> saf
[19:50] <rickspencer3> e
[19:51] <rickspencer3> lol
[19:51] <Chipaca> why is that here document being done at all?
[19:51] <rickspencer3> I removed it, but it is still running
[19:51]  * rickspencer3 reboots
[19:51] <Chipaca> rickspencer3: still running? it wasn't running before
[19:52] <Chipaca> or was it?
[19:52] <rickspencer3> Chipaca, it was running because asac had me start it by running hte binary directly
[19:52]  * Chipaca might be misunderstanding the nature of the problem
[19:52] <Chipaca> ahhh
[19:52] <rickspencer3> it did not start on install
[19:52] <Chipaca> right
[19:52] <asac> Chipaca: look at latest commit i did in examples
[19:53] <Chipaca> asac: how "directly"?
[19:53] <Chipaca> asac: i mean, running it without confinement would not have hit that issue
[19:53] <asac> Chipaca: mvo added code that tells users not to start the magic-bin script through CLI directly
[19:53] <asac> that code just exploded
[19:53] <asac> in real case
[19:53] <Chipaca> right
[19:54] <asac> guess testing code before committing is good :)
[19:54] <asac> hehe
[19:54] <Chipaca> that makes no sense though
[19:54] <asac> guess EOF isnt working that nicely with confinement
[19:54] <Chipaca> if it's directly, it's not confined, tho
[19:54] <asac> Chipaca: EOF seems to create a tmp doc
[19:54] <Chipaca> if it's confined, it should have that env var
[19:55] <rickspencer3> asac, whatever you did fixed it
[19:55] <asac> yeah
[19:55] <rickspencer3> and now I have been through the dev work flow like 10 times :)
[19:55] <asac> the code was wrong also
[19:55] <rickspencer3> and got a lesson in port forwarding
[19:55] <rickspencer3> with kvm at least
[19:56] <asac> rickspencer3: good to see the good side of this. sorry and thanks
[19:56] <rickspencer3> so, now I am too tired to figure out how to communicate from one running kvm instance to another
[19:56] <rickspencer3> will chip at it this weekend
[19:56] <asac> i can imagine
[19:56]  * asac too
[19:56] <asac> cu around
[19:56] <rickspencer3> thanks a lot asac
[19:56] <rickspencer3> it's all good, it takes dopes like me trying this stuff out to make it bullet proof :)
[19:56]  * asac should have tried himself earlier
[19:56] <rickspencer3> I appreciate your patience
[19:57] <asac> i guess you hopefully remember now how to use netstat :)
[19:57] <asac> hehe
[19:58] <asac> Chipaca: so to wrap up ... mvo commited code that wanted to prevent it from running directly, but it was buggy in that it prevented it from running in confinement
[19:58] <asac> and that hit the bail bug
[19:58] <asac> so guess we could bring it back with -n
[19:58] <asac> but not today
[19:59] <rickspencer3> netstat ftw :)
[22:28] <Chipaca> sergiusens: https://code.launchpad.net/~chipaca/webdm/m1777/+merge/259864
[22:28] <Chipaca> because it's truly a single line
[22:28] <Chipaca> and now yes, to bed for me