[06:22] <murphylaw>  /msg nickserv register clobrano irc*10QpAlZm
[06:54] <dholbach> good morning
[07:14] <fgimenez> good morning
[08:33] <admcleod1> hi guys, deplying docker containers in bridge mode, looks like im hitting a veth (or mac address? limit) seems to be ~50: systemd-udevd[5378]: Could not generate persistent MAC address for veth8aed386: No such file or directory
[08:33] <admcleod1> is it code or config?
[08:50] <JamesTait> Good morning all; happy Cheesecake Day! 😃
[09:16] <vmayoral> ogra_: ping
[09:16] <ogra_> hey vmayoral
[09:17] <vmayoral> ogra_: greetings :), could you please point out which config file you guys use to compile BBB kernels?
[09:17] <ogra_> vmayoral, oh, thats ppisati  land :)
[09:18] <vmayoral> ogra_: great, thanks for referring
[09:18] <ogra_> effectively it should be in /boot by default though
[09:18] <ogra_> (BeagleBoneBlack)ubuntu@localhost:~$ uname -a
[09:18] <ogra_> Linux localhost.localdomain 3.19.0-23-generic #24-Ubuntu SMP Tue Jul 7 18:56:34 UTC 2015 armv7l armv7l armv7l GNU/Linux
[09:18] <ogra_> (BeagleBoneBlack)ubuntu@localhost:~$ ls /boot/config*
[09:18] <ogra_> /boot/config-3.19.0-23-generic
[09:18] <vmayoral> ppisati: true! found it, thanks a lot
[09:19] <vmayoral> i was fighting with "omap2plus_defconfig" but didn't looked there. Great, thanks!
[09:19] <ogra_> make sure the version matches ... that only works on installs that havent seen a kernel upgrade yet
[09:19] <ogra_> (its a bug, we need to actually ship the config in the a/b subdirs)
[09:20] <ogra_> pitti, hey ho ....
[09:28] <ogra_> pitti, in the systemd world, which parts of the system are responsible for fstrim ?
[09:28] <pitti> hey ogra_
[09:28] <ogra_> we moount with discard by default currently ... but that seems to be a no-op on most SDs
[09:28] <ogra_> (and i bet on many USB sticks too if it comes to x86)
[09:29] <pitti> ogra_: it's not really init system specific -- util-linux has /etc/cron.weekly/fstrim which regularly calls it
[09:29]  * ogra_ checks if we ship that
[09:29] <ogra_> yeah, we seem to
[09:29] <pitti> ogra_: it seems regularly calling fstrim is preferred over "discard", at least on desktop-ish use cases
[09:29] <pitti> it's a "performance sucks once a week" vs. "performance sucks a little all the time" tradeoff mostly
[09:29] <ogra_> pitti, yeah, discard comes from our phone install
[09:29] <pitti> but at least in the past there were also some actual bugs with discard
[09:30] <ogra_> the MMCs fully support it so we preferred to not have a userspace process consuming extra cycles IIRC
[09:30] <pitti> (back in 20 mins)
[09:30] <ogra_> for snappy we should drop the discard though i think
[09:30] <pitti> ogra_: yeah, the tradeoff might be different on a phone; discard might make sense there, then the cronjob ought to be a no-op (and we could even disable it)
[09:30] <ogra_> and rely on fstrim
[09:31] <pitti> I agree
[09:31] <pitti> snappy usually runs all the time, phones are often suspended etc, so cron jobs don't work well on a phone
[09:31] <pitti> ... until we snappify the phone of course :)
[09:32] <ogra_> yep
[09:40] <ogra_> bug 1479711
[09:40] <ogra_> pitti, ^^^
[09:41] <longsleep> yay +1
[09:42]  * ogra_ will collect some more freedback and then just drop it from the initrd if nobody objects
[09:45] <ogra_> ooooh ... new splash screen on my phone, nice !
[09:57] <longsleep> quick snapcraft questin - can i just add a plugins into my project or do i need to att them to snapcraft plugins folder?
[09:58] <clobrano> hi guys, I'm trying to package some simple utilities like minicom/wget, but I don't get how to declare their shared libraries dependencies
[09:58] <ogra_> you dont, you ship them in the snap
[09:59] <ogra_> under usr/lib/<arch_triplet>/
[09:59] <clobrano> I though it was like this, but still get errors like "error while loading shared libraries"
[10:00] <clobrano> ogra_: ah sorry, didn't read the last message, I'll try that
[10:32] <longsleep> anyone can point me on an example snap which starts a service with a configuration file, preferrably created on first start or something?
[10:32]  * longsleep wonders if he is the first one who needs to do that
[10:57] <clobrano> ogra_: thank you, that worked
[10:57] <ogra_> :D
[10:59] <clobrano> ;)
[11:19] <Chipaca> longsleep: what do you mean?
[11:21] <Chipaca> longsleep: you've got $SNAP_APP_DATA_PATH
[11:21] <Chipaca> longsleep: you can write to that, if that's what you mean
[11:21] <Chipaca> (and if you can't, that's a bug :) )
[11:21] <longsleep> Chipaca: yes - i learned a lot about this the last hour - though i was wondering if i have to write all the scripts myself or if there is some generic scripting somewhere to do this
[11:22] <longsleep> i mean, i was looking for something similar to the postinst preinst stuff from debian packages
[11:22] <Chipaca> longsleep: i'm not sure what scripts you mean, here
[11:22] <Chipaca> ahhh
[11:22] <Chipaca> no such thing
[11:22] <Chipaca> so, atm, yes you write your own thing
[11:23] <Chipaca> i'd be glad to help
[11:23] <longsleep> all right - thats what i figured - so i was wondering if someone else already did something
[11:24] <longsleep> any help would be very welcome, i can easily script the stuff but i would prefer to know something about why my script is started
[11:24] <longsleep> was it the first install
[11:24] <longsleep> what was the old version
[11:24] <longsleep> stuff like that
[11:25] <Chipaca> yes, i was just thinking about that a bit
[11:25] <Chipaca> i don't have anything particularly insightful yet :)
[11:25] <longsleep> also there seems to be a folder "current" inside /writable/system-data/apps/spreed-webrtc/
[11:25] <Chipaca> but i suspect a lot of people will need to have something like a "run once" or "run on version change" script
[11:25] <longsleep> can you tell me if that is always the case?
[11:26] <Chipaca> longsleep: if the current symlink isn't there, the app isn't "installed"
[11:26] <Chipaca> longsleep: (you can have it present but not installed)
[11:26] <longsleep> Chipaca: ok - so i should always use the current path in anything i need to access from there?
[11:27] <Chipaca> longsleep: anything where you don't care about the version, yes
[11:27] <longsleep> ok that is helpful already :)
[11:27] <Chipaca> ogra_: do you know if Bad Things happen if I reference a mounted partition from g_multi?
[11:27] <Chipaca> longsleep: note you've got a bunch of environment variables to help you with this
[11:27] <Chipaca> longsleep: hello-world.env prints them out
[11:28] <Chipaca> the ones starting with SNAPP_ are deprecated ;)
[11:28] <longsleep> Chipaca: yes - i saw that one - i will check it out
[11:28] <longsleep> Chipaca: oh - all right so i will try to avoid those
[11:29] <longsleep> Chipaca: what about calling system utilities in general, how should i call to those, full path, expect them to be in $PATH, do not call them, ship them?
[11:29] <longsleep> for example openssl
[11:29] <ogra_> Chipaca, hmm, for what usecase with the g_milti module ?
[11:30] <Chipaca> ogra_: i'm testing it out on snappy bbb; main thing i want is to have network (& serial?) but if it also gives me safe access to a partition that's a win
[11:31] <Chipaca> longsleep: try it and tell us? it should work unless you're reading/writing things you shouldn't (or we forgot about :) )
[11:31] <ogra_> you want to expose it as usb device to be able to mount it ?
[11:31] <Chipaca> ogra_: g_multi lets me do that, apparently. I'm asking if it's safe :)
[11:31] <ogra_> that should be possible ... the MMC debian install does it, i bet just stealing the config from there would work ;)
[11:32] <longsleep> Chipaca: so the question is what i can expect for tools like sed, grep, awk, openssl and possibly other stuff. I mean for debian packages i have dependencies on those. What if one of these tools are suddenly gone in newer images?
[11:32] <ogra_> (since that seems to be tested and proven already)
[11:32] <Chipaca> ogra_: but the debian mmc seems to reference the sd card
[11:32]  * Chipaca looks
[11:32] <ogra_> and you dont want that ?
[11:32] <Chipaca> sudo modprobe g_multi bcdDevice=0 cdrom=N file=/dev/mmcblk0p1 host_addr=D0:5F:B8:A3:92:81 iManufacturer=Circuitco iProduct=BeagleBoneBlack iSerialNumber=C0-3614BBBK6053 idProduct=0 idVendor=0 luns=0 nofua=Y num_buffers=2 qmult=5 removable=Y stall=N
[11:32] <ogra_> i think it even only references /boot currently
[11:33] <Chipaca> ^ that's what debian does, translated into modprobe
[11:33] <Chipaca> i need to boot back into debian to see if mmcblk0 is the sd card or not
[11:33] <ogra_> yeah, so just copy it and use whatever file= option you like :)
[11:33] <Chipaca> longsleep: sed, grep, awk should work
[11:33] <ogra_> i think it is the MMC in debian
[11:33] <Chipaca> longsleep: openssl should work afaik
[11:34] <Chipaca> longsleep: when i say "should" i mean "it's a bug if it doesn't", and also that we're using some of those in e.g. hello-world stuff
[11:34] <longsleep> Chipaca: yes they all work at the moment, though i could not find a list of "save to use tools from the system". It is probably something which should be created.
[11:34] <Chipaca> longsleep: that is: you can execute anything in the usual system path
[11:35] <Chipaca> longsleep: some things, like python :), will go away at some point (from core)
[11:35] <longsleep> Chipaca: right, but how do snaps handle it when they depend on a tool which went away?
[11:35] <Chipaca> longsleep: we might at some point go crazy and replace all the rest with busybox, but it's unlikely :)
[11:36] <Chipaca> hmm.
[11:36] <Chipaca> longsleep: that's a good question
[11:37] <Chipaca> longsleep: the quick and wrong answer is that they shouldn't depend on things that're going to away
[11:37] <Chipaca> :)
[11:37] <longsleep> right :)
[11:37] <Chipaca> the true answer is probably "we need to write some kind of thing that promises what won't go away"
[11:38] <Chipaca> longsleep: for a start, everything POSIX asks for, will be there always
[11:38] <Chipaca> longsleep: that leaves out, i think, awk, perl, and python
[11:39] <Chipaca> and iptables, say :)
[11:39] <longsleep> Chipaca: Perl and Python should be frameworks if you ask me
[11:39] <Chipaca> longsleep: well, except frameworks don't work like that, but yes
[11:40] <longsleep> Chipaca: awk is nice to have, for my use case, i need to make sure i got openssl
[11:40] <Chipaca> longsleep: the expectation right now is that if you're building using perl or python, you should ship those in your snap
[11:42] <longsleep> Chipaca: all right, thanks - lets see what i can do with some script fu
[11:42] <Chipaca> ogra_: rsalveti: we need to make a list of things that are not going away :)
[11:42] <longsleep> Chipaca: what about the shell, is it bash, dash, whatever else?
[11:42] <Chipaca> ogra_: rsalveti: and pretty pleas let's have openssl on that
[11:42] <Chipaca> longsleep: /bin/sh is dash
[11:43] <longsleep> Chipaca: ok, any plans to change that?
[11:43] <longsleep> or rather, dropping /bin/bash ?
[11:44] <Chipaca> longsleep: i don't know about bash
[11:44] <Chipaca> longsleep: in my mind, it's huge and bloated and i love it
[11:44] <Chipaca> :)
[11:45] <Chipaca> longsleep: so once things settle and we start paring down, it's a candidate to go
[11:45] <Chipaca> longsleep: in my mind
[11:45] <Chipaca> longsleep: but note we have not discussed this at all
[11:45] <longsleep> well, i might be able to use dash only - though i do not really like it
[11:45]  * Chipaca is aware
[11:46]  * ogra_ would like to see bash moved to comfy 
[11:47] <ogra_> longsleep, https://wiki.ubuntu.com/DashAsBinSh has some hints for scripters :)
[11:47] <Chipaca> we should go make our own distro, call it uubuntu (because u- is for µ; also because the long first vowel is distinctive of my Córdoba roots)
[11:47] <longsleep> ogra_: yeah - i had some fun in the past porting scripts to upstart
[11:48] <Chipaca> dash and busybox's ash are essentially the same, yes?
[11:48] <longsleep> Chipaca: so the hello world example showing the variables you mean http://bazaar.launchpad.net/~snappy-dev/snappy-hub/snappy-examples/files/head:/hello-world/meta/ right?
[11:49] <Chipaca> with all the bling turned on in busybox that is
[11:49] <Chipaca> longsleep: i mean if you install it and run hello-world.env it'll print them out for you
[11:49]  * longsleep has no idea about the differences between dash and busybox
[11:49] <longsleep> Chipaca: right - let me try that
[11:49] <Chipaca> we could sort the output, that would be nice of us
[11:50] <Chipaca> ogra_: any idea whether i can read the bbb's serial number from anywhere?
[11:51] <Chipaca> ogra_: also, any idea for generating a stable random mac on the bbb :)
[11:52] <longsleep> Chipaca: well anyone can |sort
[11:52] <Chipaca> longsleep: yes. But if the script did it itself, you'd know more about what tools you can use :)
[11:53] <longsleep> right, what is the history of the SNAPP double P vars?
[11:53] <ogra_> Chipaca, no, i just noticed it isnt set ... usually from /proc/cpuinfo
[11:54] <Chipaca> longsleep: snappy app -> snapp
[11:54] <Chipaca> longsleep: somebody thought it was a good idea
[11:54] <ogra_> with the latest image you should definitely have afixed MAC though
[11:54] <Chipaca> longsleep: they changed their mind :)
[11:54] <ogra_> i surely do here
[11:54] <Chipaca> ogra_: i meant for g_multi
[11:55] <Chipaca> ogra_: because the bbb has *two* ethernets! one is hidden inside g_multi :D
[11:55]  * Chipaca loves all the ethernets
[11:55] <ogra_> oh
[11:55] <ogra_> hmm, probably there is something hidden in sysfs
[11:55] <Chipaca> ogra_: i'll grep
[11:56] <longsleep> for the ODROID, the serial is available in U-Boot and could be passed as parameter to the kernel.
[11:56] <longsleep> maybe it is similar with the bbb
[11:57] <Chipaca> looks like it
[11:57] <ogra_> yes, i just dont get why it doesnt end up where it should
[11:58]  * ogra_ will have to dig
[11:58] <Chipaca> eeee
[11:58]  * Chipaca just mounted /writable on his host
[11:59] <davmor2> ogra_: I don't know how often I can explain this, but technology hates us, you have to hate it back, it doesn't help the issue but it makes you feel a lot better ;)
[11:59] <Chipaca> ogra_: i could also just let g_multi assign random things, that works
[12:00] <ogra_> well, i dont really think it matters since the USB cable will never see a real ethernet :)
[12:00] <ogra_> so theoretically your MAC can be whatever you want it :)
[12:00] <Chipaca> ogra_: it only matters if you're doing fancy firewally stuff
[12:01] <ogra_> 00:11:22:DE:AD:BE:EF
[12:01] <ogra_> :)
[12:01] <ogra_> doews that MAC matter for firewalling over USB ? i'd expect that to hook into a higher layer
[12:02] <ogra_> it might matter for IP assignment
[12:03] <longsleep> Chipaca: so where should i create the config file, in the environment i only see folders which contain the version. I need to store stuff which is independent from version.
[12:03] <longsleep> Chipaca: i see this SNAP_APP_DATA_PATH=/var/lib/apps/hello-world.canonical/1.0.18
[12:03] <longsleep> but i would need /var/lib/apps/hello-world.canonical/
[12:04] <longsleep> (assuming it is writable)
[12:04] <Chipaca> longsleep: the data path is always versioned
[12:04] <longsleep> Chipaca: mhm so where do i store stuff i want to keep across versions then?
[12:04] <Chipaca> longsleep: you should have /var/lib/apps/, and it should be writable by your service
[12:04] <Chipaca> longsleep: on upgrade, the data directory is copied
[12:05] <longsleep> Chipaca: ah ok
[12:05] <Chipaca> longsleep: service stopped, data directory copied, current symlink redirected, service started
[12:05] <longsleep> Chipaca: sounds good thanks
[12:05] <Chipaca> longsleep: um
[12:06] <ogra_> AHA
[12:06] <Chipaca> longsleep: if the user rolls back, and then rolls forward, things get iffy
[12:06] <ogra_> usbnet_devaddr=78:a5:04:f4:c1:00
[12:06] <ogra_> seems uboot has it
[12:06] <ogra_> how do we get it across to the kernel now ?
[12:06] <longsleep> just add some parameter and parse /proc/cmdline in user space
[12:07] <longsleep> (that is how android does it)
[12:07] <ogra_> well, i would be hoping there is no need to parse anything if we use the right cmdline option
[12:07] <longsleep> ogra_: yeah - you might have a driver in place which does it already
[12:08] <Chipaca> ogra_: sudo modprobe g_multi bcdDevice=0 cdrom=N file=/dev/mmcblk0p4 iManufacturer=Circuitco iProduct=BeagleBoneBlack idProduct=0 idVendor=0 luns=0 nofua=Y qmult=5 removable=Y stall=N
[12:08] <Chipaca> ogra_: check if that gives you the right mac (in dmesg)
[12:09] <Chipaca> i wonder what it used iSerialNumber for; it isn't complaining without it
[12:09] <Chipaca> ogra_: i say we add that to bbb's modprobe.d :)
[12:11]  * ogra_ twiddles thumbs waiting for cloud-init again 
[12:11] <Chipaca> then i can ditch the clumsy ethernet cable! woo :)
[12:11] <Chipaca> grmbl grmbl cloud-init
[12:12] <ogra_> hmm, no, the MAC doesnt match anything from uboot
[12:12] <sergiusens> Chipaca: implement https://trello.com/c/W5WiZQM7/117-core-config-for-cloud-init ;-)
[12:13] <Chipaca> ogra_: ah well
[12:13] <Chipaca> ogra_: i still say we add that to the modprobe
[12:13] <Chipaca> can figure out the serial number and mac later
[12:13] <Chipaca> it doesn't seem like anything breaks without 'em
[12:13] <ogra_> yeah
[12:14] <Chipaca> note that modprobe lets you mount writable on the host
[12:14] <Chipaca> which is pretty sweet, if you ask me :)
[12:14] <Chipaca> sergiusens: i'd love to
[12:15] <Chipaca> rsalveti: ^ put me down for core-config-for-cloud-init when i return from my holidays
[12:15] <Chipaca> pretty please :D
[12:28] <Chipaca> things i learned while having lunch and looking into mac addresses: osteodiastasis is nasty
[12:31] <rsalveti> Chipaca: sure :-)
[12:33] <elopio> good morning.
[12:37] <rsalveti> elopio: good morning
[13:12] <longsleep> Another snapcraft question, any ideas if someone tried to do cross snapcraft, eg. create a snap for armhf on amd64?
[13:13]  * longsleep wonders how multi arch snaps work anyway
[13:14] <ogra_> longsleep, i guess thats a mterry or ted question
[13:14] <ogra_> (like all snapcraft questions somehow :) )
[13:14] <ogra_> both are in US TZ ...
[13:15] <mterry> longsleep, I'm up
[13:15] <longsleep> great :D
[13:15] <ted> longsleep, We're gonna initially target people building an arm snap on arm.
[13:15] <ted> Which isn't ideal, but that's phase 1.
[13:15] <mterry> longsleep, plan right now is you build on the target platform.  Future plan is to use comfy to make that much easier
[13:15] <longsleep> ted: all right, i guess i can do some chroot stuff then
[13:15] <ogra_> the magical comfy
[13:15] <longsleep> mterry: i still do not know what comfy is
[13:16]  * ogra_ adjusts his macros from "snappy will fix everything" to "comfy will fix everythng" :)
[13:16] <mterry> ogra_, :)
[13:16] <longsleep> ted, mterry, ogra_ and what about the multi arch. Do i have to build multiple snaps for each arch and somehow can upload them all into the store?
[13:16] <mterry> longsleep, it's basically "normal Ubuntu embedded in Snappy for developers' benefit"
[13:17] <ogra_> longsleep, i think thats possible, yup
[13:17] <longsleep> ok - so the file name of the snap should include the architecture?
[13:17] <mterry> longsleep, the current only way to do that is embed multiple binaries in one snap (which is gross and tooling isn't great).  Future plan is to allow uploading multiple snaps, one per arch, for one store item.  Or you could upload them as separate store items now
[13:17] <ogra_> (i personally prefer one snap for all arches, but then you cant use snapcraft atm as i understand)
[13:18] <longsleep> oh - so i have to put them all into one snap :/ that is unfortunate
[13:18] <ogra_> no, you dont
[13:18] <mterry> longsleep, it's a store limitation right now
[13:18] <sergiusens> ogra_: you flip flopped the preference it seems ;)
[13:18] <mterry> ogra_, did store grow support for multiple snaps?
[13:18] <ogra_> sergiusens, after using the model, yes :)
[13:19] <sergiusens> ogra_: it is easier in some aspects, just not ideal for huge snaps
[13:19] <ogra_> mterry, hmm, not sure about package namin, but you can surely upload for a specific arch ... would likely have to be $snapname-$arch.snp then though
[13:20] <ogra_> i know i can upload armhf only or amd64 only for one snap
[13:20] <ogra_> sergiusens, indeed, size matters :)
[13:20] <mterry> ogra_, yeah but you have to upload each arch as a separate store item right now
[13:20] <ogra_> right
[13:20] <mterry> ogra_, which is gross is all  :(
[13:20] <longsleep> what does it mean separate store item? Can it use the same name then?
[13:20] <ogra_> yeah, surely not idea
[13:20] <ogra_> l
[13:21] <mterry> longsleep, I'm meaning separate names when I mean separate store item
[13:21] <mterry> longsleep, store can't handle multiple arch-specific snaps for same name yet
[13:21] <ogra_> longsleep, myshinysnap-armhf_1.2.3.snap ... and myshinysnap-amd64_1.2.3.snap
[13:22] <longsleep> yes file names are good, though regarding the store i am unsure
[13:22] <ogra_> that will be two separate store items with separate metadata pages in the store
[13:22] <longsleep> is there an example in the store already?
[13:22] <ogra_> (and two different places to upload to etc)
[13:22] <longsleep> i think i can be ok with that
[13:23] <longsleep> but probably will only create armhf then for now
[13:26] <longsleep> mterry: how do you folks manage that for webdm? Does it have a different name for other archs?
[13:27] <mterry> longsleep, I don't know...  I don't manage that myself
[13:34] <mterry> rsalveti, tried old BBB image, still didn't work!  So it's either user error, messed up SD card, or messed up BBB (though all are new...).  I'm going with user error...  Trying my raspberry pi2 just in case
[13:38] <sergiusens> mterry: after dd'ing make sure records out and in match ;-)
[13:40] <mterry> sergiusens, interesting...  but looking at scrollback, it seems fine
[13:58] <Chipaca> longsleep: i like your case, btw :)
[14:00] <rsalveti> mterry: makes no sense
[14:01] <rsalveti> guess we can only know for real with a serial console
[14:01] <rsalveti> like http://elopio.net/en/node/1042
[14:02] <rsalveti> mterry: is yours also bbb rev c?
[14:02] <rsalveti> should have a bit C in one of the stickers
[14:02] <rsalveti> *big
[14:02] <ogra_> mterry, can we see your serial output during boot ?
[14:12] <Chipaca> sergiusens: where was it golang-uboot-go-dev was at?
[14:12] <Chipaca> and how do i add that to a schroot
[14:14] <sergiusens> Chipaca: in the ppa:snappy-dev/image
[14:15] <sergiusens> Chipaca: https://wiki.ubuntu.com/SimpleSbuild#Temporarily_adding_PPAs
[14:15] <Chipaca> yep, just found that
[14:15] <Chipaca> thanks
[14:15] <sergiusens> Chipaca: you could add it permanently into a snappy branded schroot as it is the base of our builds anyways
[14:16] <Chipaca> yep, am doing so :)
[14:20] <ogra_> longsleep, https://insights.ubuntu.com/2015/07/30/spreedbox-most-private-video-chat-and-file-exchange/
[14:20] <ogra_> ;)
[14:31] <mterry> rsalveti, ogra_: sorry was in meeting about this MIT demo.  rsalveti: it is rev C.  ogra_: I've moved on to trying with the raspberry pi2 but can go back and try to get more output later
[14:31] <rsalveti> ogra_: nice
[14:32] <rsalveti> same rev we all use, weird
[14:32] <rsalveti> yeah, but you'd need a serial cable around
[14:33] <ogra_> well, we should somehow make clear that a serial cable is kind of expected on embedded HW :)
[14:34]  * ogra_ gives up trying to re-share rsalveti's Win10 post on the phone and does it from the PC 
[14:35] <ogra_> unbelivabe ... i cant switch back and forth between browser and G+ to actually type one sentence off the website into my post
[14:35] <longsleep> ogra_: very nice thanks!
[14:35] <ogra_> either G+ or the browser goes white
[14:35]  * ogra_ wants 4GB on phones :P
[14:36] <ogra_> (that will at least allow me two apps at the samer time :P )
[14:36] <Chipaca> ogra_: unless one of them is a browser ;)
[14:37] <ogra_> yeah, then you need 8GB
[14:37] <longsleep> is there any phone which actually can use more than 3GB ?
[14:37] <longsleep> i read somewhere that the oneplus 2 should have 4GB
[14:37] <sergiusens> ogra_: yeah, I have this problem when attaching a photo through the content hub as well, the app that requested the content hub ceases to exist on return :P
[14:37] <ogra_> i dont think there are actual 64bit phones ...
[14:38] <ogra_> the 64bit ones i know all run in a 32bit compatibility mode
[14:38] <ogra_> which would limit your to 3G
[14:38] <sergiusens> ogra_: mem management is atrocious on the phone lately
[14:38] <sergiusens> ogra_: I don't use g+ on it anymore, too depressing
[14:38] <ogra_> sergiusens, well, i see people complaining about that photo thing all the time ... works for me ... but then i only use G+ to share stuff
[14:38] <ogra_> (and very rarely telegram)
[14:39] <sergiusens> ogra_: right, my use case is untappd (take photo and return to nothing)
[14:39] <ogra_> (and indeed i use my G+ app, not that official canonical thing :) )
[14:39] <sergiusens> ogra_: now I take the photo just in case I lose it ;-)
[14:39] <sergiusens> and then open the hub
[14:39] <ogra_> ah, so you share from the camera app
[14:40] <ogra_> i always pick gallery (and make sure the camera is closed when i do)
[14:40] <ogra_> seems thats less memory hungry
[14:40] <sergiusens> ogra_: oh, good point
[14:50] <mterry> ogra_, rsalveti: now...  with pi2, my first ssh attempt is reset by peer and the second hangs.  :-/  but that's further than bbb...
[14:55] <ogra_> mterry, and you dont have a serail cable ?
[14:55] <mterry> ogra_, no, I'm connecting over local network (ethernet on pi2 and wifi on laptop)
[14:56] <ogra_> ah, well, that wont give us many meaningful infos ...
[14:56] <ogra_> try pulling the syslog off the writable partition (but i guess thats to late to catch boot inssies)
[14:57] <mterry> ogra_, but might help for pi2... i could get openssh logs
[14:58] <ogra_> well, you can just pull the log from the SD directly
[14:58] <mterry> ogra_, that's what I meant, get the openssh logs from the SD
[14:58] <mterry> since I can't ssh in
[14:58] <ogra_> well, syslog would be more interesting ... the only "ssh log" we have is auth.log
[14:59] <ogra_> (and that usually hasnt mugh meaningful to debug anything beyond login issues)
[14:59] <ogra_> *much
[15:00] <mterry> ogra_, http://paste.ubuntu.com/11967112/
[15:00] <ogra_> mterry,  looks like cloud-init didnt generate the keys properly
[15:25] <mterry> ogra_, is something like a "USB to Serial adapter" what I want?
[15:25] <ogra_> one sec
[15:25] <ogra_> http://www.amazon.de/SainSmart-Serial-Debug-Console-Raspberry/dp/B00KVUSI30/ref=sr_1_1?ie=UTF8&qid=1417690697&sr=8-1&keywords=FTDI+Cable+3.3
[15:25] <ogra_> that is what i got here
[15:26] <ogra_> you want one with the flying cablöes at one end so you can use it on boards that have different order
[15:26] <ogra_> (instead of a fixed 4-prong thinie)
[15:26] <mterry> ogra_, haha, little tentacle cables.  OK
[15:27] <ogra_> yeah :D
[15:27] <mterry> ogra_, will search for one at my local store
[15:39] <fgimenez> Chipaca, can you give me a hand with a failing service test?
[15:39] <Chipaca> sure
[15:39] <fgimenez> Chipaca, not sure if fails the service or the test :)
[15:40] <fgimenez> Chipaca, here's the error http://10.55.61.165:8080/job/snappy-integration-tests-canonistack-1504-edge/35/console
[15:40] <fgimenez> Chipaca, you can search for FAIL:
[15:40] <fgimenez> and here's the test's code http://bazaar.launchpad.net/~snappy-dev/snappy/snappy/view/head:/_integration-tests/tests/installFramework_test.go
[15:42] <fgimenez> Chipaca, it fails eventually, usually all is fine
[15:44] <Chipaca> fgimenez: could you pastebin console? i don't have my vpn setup working for some reason
[15:45] <fgimenez> Chipaca, sure http://paste.ubuntu.com/11967413/
[15:46] <Chipaca> fgimenez: can you get more logs than that? it looks like your app is panic'ing
[15:47] <fgimenez> Chipaca, yes, that's because this failed assert http://bazaar.launchpad.net/~snappy-dev/snappy/snappy/view/head:/_integration-tests/tests/installFramework_test.go#L86
[15:47] <fgimenez> Chipaca, the problem is the output of "systemctl status docker_docker-daemon_1.6.1.002.service"
[15:48] <Chipaca> fgimenez: is this with snappy trunk?
[15:48] <fgimenez> it expects to find the service active
[15:48] <fgimenez> Chipaca, yes
[15:50] <fgimenez> Chipaca, the test usually passes but 10% of the time fails
[15:50] <Chipaca> fgimenez: is network up on the kvm?
[15:50] <Chipaca> fgimenez: is this recent?
[15:50] <Chipaca> fgimenez: wrt "network up", i'm asking if there is a default route, fwiw
[15:51] <fgimenez> Chipaca, the network is up, it is being tested against a 15.04 image, and the code has been there for some time
[15:51] <Chipaca> fgimenez: i mean, are the failures recent
[15:51] <Chipaca> but if it's 15.04 then it's not what i thought it might be
[15:52] <fgimenez> Chipaca, not afaic, we are checking if the service is up after a reboot, maybe we are asking for it too soon?
[15:53] <Chipaca> fgimenez: give me a sec
[15:53] <Chipaca> systemctl show -p ActiveState network-online.target
[15:53] <Chipaca> fgimenez: delay the check until that^
[15:53] <Chipaca> fgimenez: returns "ActiveState=active"
[15:53] <Chipaca> fgimenez: and let me know how it goes
[15:54] <Chipaca> (even better if you wait a bit *after* it got to "active")
[15:54] <Chipaca> fgimenez: if you need to cap it, that should not be more than say 3 minutes after boot
[15:54] <fgimenez> Chipaca, ah! ok that makes sense, i'll try that thanks a lot! :)
[15:54] <Chipaca> as even in the worst case the network-online thing will only wait 2 minutes, as things stand
[15:55] <Chipaca> fgimenez: also
[15:55] <Chipaca> fgimenez: this check might be overkill right now (maybe with a sleep you'll have enough)
[15:55] <fgimenez> Chipaca, yes, i was going to ask you about that
[15:55] <Chipaca> fgimenez: but there'll be code in 15.04 soon that will break if you don't wait for this, so you might as well do it now
[15:55] <Chipaca> fgimenez: but, your choice, really
[15:57] <fgimenez> Chipaca, ok i'll go for checking the state, thanks!
[16:43] <ogra_> rsalveti, hmmm ... i was just looking closer at mterry's log ....
[16:43] <ogra_> Feb 16 20:55:26 localhost systemd[1]: Starting Initial cloud-init job (metadata service crawler)...
[16:43] <ogra_> Jul 30 14:41:40 localhost systemd[1]: Time has been changed
[16:43] <ogra_> Jul 30 14:41:42 localhost cloud-init[722]: Cloud-init v. 0.7.7 running 'init' at Mon, 16 Feb 2015 20:55:35 +0000. Up 51.59 seconds.
[16:43] <rsalveti> right
[16:43] <ogra_> seems the time gets updated in the middle of cloud-init runnign
[16:44] <rsalveti> that is indeed interesting
[16:44] <ogra_> and cloud-init still keeps the old time cached somehow
[16:45] <ogra_> it is also weird that the last mount time doesnt seem to have been updated between the two boots ... they both start at feb 16th
[17:02] <ogra_> rsalveti, hmm, did you do a vivid build tonight ?
[17:03]  * ogra_ just notices an arm64 build failure mail from 7am this morning for a vivid build
[17:03] <ogra_> i wonder if someone played with the crontab commants on nusakan
[17:03] <ogra_> *comments
[17:32] <admcleod1> so.... any ideas why i cant create more than 50 veth's with docker in snappy on an rpi2? :}
[17:33] <ogra_> kirkland, any idea ? ^^
[17:33] <ogra_> (or any idea whom to point admcleod1 to ? )
[17:39] <longsleep> is there a way to directly use git with launchpad?
[17:41] <ogra_> longsleep, yeah, i think so ... ask in #launchpad though
[17:41]  * ogra_ still uses bzr if he can choose :) 
[17:42] <longsleep> right, i want to add a simplified plugin to snapcraft which can directly use a .deb file
[17:59] <mterry> ogra_, rsalveti: ok, back from a long trek to find serial cables and lunch.  Everywhere is out of them, so I ordered an overnight amazon cable
[18:01]  * mterry will try again on current devices / work on other aspects of presentation
[18:02] <ogra_> mterry, yeah, lets look tomorrow then ... but see above, there is something going on with the clock and last mount time it seems
[18:03] <mterry> ogra_, huh, I don't know what to do with that information...  :)  but interesting clue
[18:03] <mterry> ogra_, does ethernet need to be plugged in at boot for it to work?
[18:03] <ogra_> mterry, nothing ... lets inspect it deeper tomorrow :)
[18:04] <mterry> maybe I can plug it in later to avoid updating time in middle of boot
[18:04] <ogra_> well, therenet is needed by cloudinit i think
[18:04] <ogra_> *ethernet
[18:05] <ogra_> the thing is, cloud-init generates your ssh keys ... i'm not sure what actually happens if the clock gets changed in the middle of generating them
[18:06] <ogra_> (i'm also not sure why your last mount time (which is what fixrtc sets the system time to if there is no rtc) is feb 16th ... that kind of predates the released image)
[18:10] <mterry> ogra_, I hate hardware.  Why can't everything just be ethereal bits?
[18:11] <ogra_> haha
[18:35] <ted> Man, I looked and look at what I did wrong. Turns out just needed to fix the expected result of the test, it changed.
[18:36] <mterry> ogra_, rsalveti: my third rewritten sd card worked for pi2....
[18:36] <mterry> I don't get it, but I'm not asking questions
[18:44] <rsalveti> mterry: weeeird
[18:44] <rsalveti> ogra_: I enabled the cronjob for 15.04/edge again
[18:44] <rsalveti> since the release is out
[18:44] <mterry> rsalveti, not confidence inspiring for sure
[18:45] <rsalveti> do you have any external usb-sd card reader?
[18:45] <sergiusens> mterry: maybe get a new sdcard?
[18:45] <rsalveti> or that
[19:14] <mterry> ogra_, people have used this webcam-demo.canonical app and it works and all that?  I'm getting "GD Error: gd-jpeg: JPEG library reports unrecoverable error: Not a JPEG file: starts with 0x26 0x81" -- trying to figure out if it is the snap or something else
[19:45] <ogra_> rsalveti, what for ? the archive wont change, dailies dont really make sense for 15.04
[19:46] <rsalveti> ogra_: does change, -updates and -security
[19:46] <ogra_> well, true indeed
[19:47] <rsalveti> I think federico tested the webcam demo with latest release, maybe elopio gave that a try as well
[19:48] <elopio> I haven't tried that one for a month, at least.
[19:49]  * ogra_ knows that asac tested it too not to far ago
[19:49] <ogra_> but probably before QA did
[21:01] <mterry> OK...  what's the best way to run a native go arm executable?  We have golang-go for armhf.  But running under qemu dies (known bug).  Is there anything like comfy that I can fake to get an armhf deb-based system running on my board?  using docker and installing a cloud image in that?
[21:01] <rsalveti> yeah, docker and an ubuntu image
[21:01] <rsalveti> ted probably got something
[21:02] <rsalveti> since he's working at the comfy idea
[21:02] <mterry> rsalveti, I'm having a hard time finding an armhf image that isn't our "cloud" image.  Is that fine?  ubuntu-server and ubuntu-desktop don't seem to publish normal everyday armhf images
[21:02] <rsalveti> it should be fine
[21:02]  * mterry has never used cloud before, but assumes it's close to server
[21:03] <ted> Yeah, I think there's another image that people seem to be using, but not an official one.
[21:03] <ted> Let me find it.
[21:03]  * ted is curious why we don't seem to have an official one.
[21:04] <mterry> rsalveti, I realized that our current Go plugin in snapcraft is amd64-only and expanding it to armhf is easy, but hard to actually test.  :)  Most of our fun examples for snappy involve Go
[21:04] <rsalveti> yeah :-)
[21:04] <rsalveti> and why ted is fixing that issue for us :-)
[21:04] <mterry> Three cheers for ted!  :)
[21:04] <ted> Heh
[21:06] <ted> mterry, https://registry.hub.docker.com/u/armbuild/ubuntu/
[21:07] <mterry> ted, I don't like downloading things from non-ubuntu.com sites  :)  feels dirty
[21:09] <ted> mterry, It is, but make sure to not put important stuff on that device :-)
[21:09]  * mterry scp's private gpg keys
[21:09]  * mterry needs to probably update my gpg key to something new....  I haven't done that in 15 years
[21:10] <mterry> I'm probably using md5 as the core key mechanism
[21:15] <ted> Yeah, I updated mine a while ago for that reason. I choose a really big number for the new key.
[21:15] <ted> I'm sure that makes it perfect for another 20 years.
[21:28] <mwhudson> hey can i trick someone into looking at https://bugs.launchpad.net/snappy/+bug/1478736
[21:44] <rsalveti> elopio: Chipaca: ^
[21:46] <elopio> mwhudson: that's definitely not happening on trusty, because that's what our tarmac runs.
[21:46] <mwhudson> elopio: no it's definitely not
[21:46] <elopio> and it's not happening for me on vivid, probably not either on wily because that's what federico uses.
[21:46] <mwhudson> elopio: context https://wiki.ubuntu.com/MichaelHudsonDoyle/Go15Preparation#preview
[21:46] <elopio> mwhudson: please give us as many information about your environment as possible. I'll try to reproduce it when I return.
[21:46]  * mwhudson edits bug summary
[21:46] <elopio> oh, I see.
[21:47] <elopio> mwhudson: I need a couple of hours in the scary outside world. I'll reply to the bug when I come back.
[21:47] <mwhudson> :-)
[21:47] <mwhudson> thanks