[01:03] <Chipaca> sergiusens: take a poke https://code.launchpad.net/~chipaca/snappy/delayed-service-start/+merge/266166 when you have a bit plz
[01:03] <Chipaca> rsalveti: ^ that's my take on the fix/workaround for bug 1466672
[03:22] <rsalveti> omg, system-image import takes forever, impossible to get the lock
[03:58] <pitti> Chipaca: add an [Install] section to it with WantedBy=
[03:58] <pitti> Chipaca: or just ship the symlink in the deb, as you wish
[04:51] <xaj> Can anyone help me get git installed in ubuntu-15.04-snappy-armhf-rpi2?
[04:51] <xaj> I was able to install wget and I’ve been pulling my hair out trying to get dependencies built with dpkg for git
[04:53] <xaj> aaand nobody gaf >_>
[07:03] <dholbach> good morning
[07:10] <fgimenez> good morning
[09:11] <JamesTait> Good morning all; happy Rain Day! 😃
[09:51] <Chipaca> zyga: finally got round to adding tests and pushing https://code.launchpad.net/~chipaca/snappy/dynamicExclusion/+merge/266199
[09:51] <Chipaca> oh, drat, forgot the prereqs
[09:51] <Chipaca> 1 sec
[09:52] <zyga> Chipaca: hi
[09:52] <zyga> Chipaca: looking
[09:52] <Chipaca> zyga: https://code.launchpad.net/~chipaca/snappy/dynamicExclusion/+merge/266200
[09:52] <zyga> ohhh
[09:52] <zyga> nice
[09:52] <zyga> one tip/request
[09:52] <Chipaca> shoot
[09:52] <zyga> please get into the habit of writing manual pages
[09:53] <zyga> it makes software far far better to discover
[09:53] <Chipaca> we suck at that, don't we
[09:53] <zyga> I'll start using .snapignore right away
[09:53] <Chipaca> systemd puts us to shame
[09:53] <zyga> hehe
[09:53] <zyga> yes
[09:53] <Chipaca> zyga: it's not on trunk yet!
[09:53] <zyga> systemd is really good about this
[09:53] <zyga> Chipaca: we started doing this for plainbox
[09:53] <zyga> Chipaca: and it's really easy actually
[09:54] <zyga> Chipaca: just requires discipline and merge request reviewers to spot
[09:54] <zyga> Chipaca: feel free to copy the sphinx integration bits
[09:54] <zyga> http://bazaar.launchpad.net/~checkbox-dev/checkbox/trunk/files/head:/plainbox/docs/manpages/
[09:55] <zyga> Chipaca: that and the conf.py file for sphinx is all we need
[09:55] <zyga> Chipaca: it's a world of difference for our users
[09:58] <zyga> Chipaca: one more suggestiong
[09:58] <zyga> *on
[09:58] <zyga> Chipaca: perhaps remove the built-in list and create the .snapingore file with that list if missing
[09:58] <zyga> Chipaca: it's better than having two, one secred that nobody knows of, and one in the file
[09:59] <Chipaca> hmm
[09:59] <Chipaca> i see your point
[10:00] <Chipaca> can you make that comment on the merge?
[10:00] <Chipaca> i think it needs sergio or mvo to comment
[10:00] <zyga> sure
[10:01] <Chipaca> zyga: also: http://paste.ubuntu.com/11958678/
[10:01] <zyga> btw, we have some code that automates that :)
[10:02] <Chipaca> missing quite a bit of work still, but that might be a good place to start
[10:02] <zyga> so we get the manual page for plainbox commands (all dozens of them) auto-synchronized with sphinx
[10:02] <Chipaca> zyga: that's produced by "snappy man"
[10:02] <zyga> ah
[10:02] <Chipaca> ... which is not a thing on trunk yet either
[10:02] <zyga> Chipaca: random man page from plainbox
[10:02] <zyga> http://bazaar.launchpad.net/~checkbox-dev/checkbox/trunk/view/head:/plainbox/docs/manpages/plainbox-dev-list.rst
[10:02] <zyga> the ..argparse part is also a plainbox feature though I'm moving that to python-guacamole for anyone to use
[10:04] <zyga> (that example was poor) http://plainbox.readthedocs.org/en/latest/manpages/plainbox-run.html and http://bazaar.launchpad.net/~checkbox-dev/checkbox/trunk/view/head:/plainbox/docs/manpages/plainbox-run.rst
[10:06] <Chipaca> zyga: and this is the code that adds "snappy man": https://code.launchpad.net/~chipaca/snappy/snappy-man/+merge/266203
[10:06] <zyga> looking
[10:06] <zyga> ah, but that's go, I thought this part is written in python
[10:07] <zyga> Chipaca: so it's a feature of the argument parser that go provides
[10:07] <Chipaca> well, of the one we use :)
[10:07] <zyga> right
[10:07] <Chipaca> it also produces bash completion things
[10:07] <Chipaca> which we aren't using (why not? :) )
[10:07] <zyga> nice, it's somewhat similar, we have a sphinx plugin that looks at the parser object
[10:08] <Chipaca> ogra_: why don't we ship bash completion in core?
[10:09] <zyga> Chipaca: bash is not in the core ;-)
[10:09]  * zyga ducks
[10:10] <Chipaca> if it weren't, i'd be happy
[10:10] <Chipaca> but as it is, we might as well use it :)
[10:10] <zyga> hehe
[10:10] <zyga> yeah, I was kidding
[10:10] <Chipaca> me, i'd strip core down so much it would make peoples eyes water
[10:10] <Chipaca> but it's not (yet) my fight
[10:10] <zyga> Chipaca: the 1995 boot floppy!
[10:11] <Chipaca> exactly!
[10:11] <ogra_> Chipaca, we should just drop bash
[10:11] <Chipaca> dhcp in the kernel baby!
[10:11] <ogra_> iirc the completion db isnt actually small ... and it refers to aps
[10:11] <ogra_> *apt
[10:11] <Chipaca> also the kdrive x server, man that thing was sweet
[10:11] <ogra_> !
[10:11] <ogra_> i loved that
[10:15] <Chipaca> ogra_: wrt bash completion, we ship random things in /etc/bash_completion.d, which we should probably look at (wrt apt, etc) and nuke, but we don't ship /etc/bash_completion so even if we ship snappy's completion thing, it won't be picked up
[10:17] <Chipaca> also shipped: 400k in /usr/share/bash-completion/completions
[10:17] <ogra_> hm i thought it was more in the megabytes
[10:18] <Chipaca> ogra_: it can be :)
[10:18] <ogra_> but perhaps i shouldnt justdge by desktop standards ;)
[10:18] <Chipaca> 2.4M on my notebook
[10:18] <zyga> ogra_: we should start measure snappy core image sizes in terms of 720 floppies
[10:18] <ogra_> yeah, thats more like i remember
[10:18] <zyga> ogra_: this will let us see how big we are ;-)
[10:18] <ogra_> +1
[10:18] <ogra_> we are to big ... for sure
[10:18] <Chipaca> right! swapping libc to musl in 3...
[10:18] <ogra_> lol
[10:19] <ogra_> lib modules as squashfs image !
[10:19] <ogra_> err
[10:19] <ogra_> /lib/modules
[10:19] <Chipaca> initrd is whole root system!
[10:20] <Chipaca> go works fine linking with musl, fwiw :)
[10:20] <Chipaca> http://dominik.honnef.co/posts/2015/06/statically_compiled_go_programs__always__even_with_cgo__using_musl/
[10:20] <ogra_> how abouot klibc ?
[10:20] <ogra_> (that is actually well maintained in ubuntu)
[10:20] <Chipaca> http://www.etalabs.net/compare_libcs.html
[10:21] <Chipaca> ah, does not include klibc
[10:21] <Chipaca> ogra_: wasn't klibc kernel-only or something?
[10:21]  * Chipaca reads
[10:21] <ogra_> no,. its a cut down glibc iirc
[10:21] <Chipaca> i don't think systemd will work with that
[10:22] <Chipaca> in fact i think the only one there are patches for systemd to work with is uclibc
[10:22] <ogra_> good !
[10:22] <ogra_> upstart will ;)
[10:22] <Chipaca> ogra_: so you're going to implement socket activation for upstart?
[10:22] <ogra_> we just need to change everything back
[10:22] <Chipaca> \o/
[10:23] <ogra_> we kind of have socket activation in use on the phone ;) (via hacked upstart jobs)
[10:23] <Chipaca> remember when you searched for two words in google, and the first result actually included both words you looked for?
[10:23] <zyga> ogra_: replace socket activation with dip switches
[10:23] <zyga> ;)
[10:23] <Chipaca> google "klibc systemd", first result has no systemd in it :(
[10:24] <ogra_> yeah, dip switzches definitely dont get the attention they deserve anymore ...
[10:24] <Chipaca> nor second, nor third, nor ...
[10:24] <ogra_> jumpers killed the dip switch !
[10:26] <Chipaca> there's a rather dark joke hiding in that statement, but i'm unable to wiggle it out
[10:37] <ogra_> Chipaca, http://lists.freedesktop.org/archives/systemd-commits/2012-June/002047.html is what i hit when searching for klibc and systemd ...
[10:37] <ogra_> but that seems to only refer to udev
[10:38] <ogra_> (and is years old)
[10:39] <shuduo> hi guys, i see someone (seems lool) is working on porting snappy onto edison but i'm not sure where it is. could anyone let me know if there is a  workable image already?
[10:39]  * ogra_ doesnt think there is, but i could be wrong
[10:40] <Chipaca> lool would know, though
[10:40] <ogra_> yeah
[10:55] <Chipaca> how bad would it be if, on installing a snap, all installed snap services restarted?
[11:15] <ogra_> Chipaca, pretty bad i'd say
[11:36] <Chipaca> unfortunately the documentation is unclear on whether that will happen, meaning i need to implement this before knowing
[11:54] <ogra_> well, rolling is expected to break ;)
[12:08] <ogra_> Chipaca, uuuh ... implementing a "phone home" service  to check if the network is up ?
[12:10] <ogra_> Chipaca, how about instead checking if a default route exists ?
[12:15] <sergiusens> morning
[12:26] <Chipaca> ogra_: it's the standard "do you have internets" thing that's used in at least two other places
[12:27] <ogra_> hmm
[12:27] <Chipaca> ogra_: but, um, looking for a default route would work, also :)
[12:27] <Chipaca> ogra_: comment on the mp?
[12:27] <ogra_> just did :)
[12:27] <Chipaca> sergiusens: mo'in!
[12:27] <Chipaca> ogra_: ta
[12:27] <sergiusens> Chipaca: I hink he has
[12:27] <sergiusens> think*
[12:36] <Chipaca> sergiusens: any comment on zyga's comment in the dynamicExclude branch?
[12:37] <Chipaca> on the one hand, putting a file in the user's thing is Not What We Do
[12:37] <Chipaca> on the other hand i see his point about it being magic and obscure and stuff
[12:38] <sergiusens> @activereviews
[12:38] <nothal> sergiusens: No such command!
[12:38] <sergiusens> @activereview
[12:38] <nothal> sergiusens: No such command!
[12:38] <sergiusens> @help
[12:38] <nothal> "list" To see the available commands ; "help cmd" for specific command help
[12:38] <sergiusens> @list
[12:38] <nothal> The available commands are: ['bug', 'critical', 'help', 'last', 'list', 'more', 'ping', 'reviewlist', 'seen']
[12:38] <Chipaca> @reviewlist
[12:38] <nothal> https://code.launchpad.net/~fgimenez/snappy/config-for-remote-testbeds/+merge/266214 | No reviews (less than a day old)
[12:38] <nothal> https://code.launchpad.net/~chipaca/snappy/snappy-man/+merge/266203 | Needs Information: 1 (less than a day old)
[12:38] <nothal> https://code.launchpad.net/~chipaca/snappy/dynamicExclusion/+merge/266200 | Needs Fixing: 1 (less than a day old)
[12:38] <nothal> https://code.launchpad.net/~fgimenez/snappy/generalize-build-tests-across-versions/+merge/266191 | No reviews (less than a day old)
[12:39] <nothal> https://code.launchpad.net/~chipaca/snappy/delayed-service-start/+merge/266166 | Needs Information: 2 (less than a day old)
[12:39] <sergiusens> Chipaca: we should have an alias, it's called activereviews in lp :-P
[12:39] <Chipaca> agreed
[12:39] <sergiusens> Chipaca: and help should just list :)
[12:39] <Chipaca> sergiusens: https://code.launchpad.net/~verterok/lalita
[12:39] <sergiusens> thanks
[13:12] <ted> Morning folks!
[13:21] <Chipaca> ooh, look at that, it *doesn't* restart everything \o/
[13:29] <elopio_> hello, good morning.
[13:32] <elopio> mterry: I did a shortcut to get this merged: https://code.launchpad.net/~elopio/snapcraft/fix1476452-python_log/+merge/265354
[13:32] <elopio> next, if you give me the specs for the logging that you want I can configure the loggers.
[13:33] <mterry> elopio, OK.
[13:33] <mterry> elopio, so was the point of that MP to use loggers or to get rid of common.log?  Because you could have kept common.log and automatically had it add the bold to the message just like before and just done sed s/print/logger.info/
[13:34] <elopio> mterry: the problem with keeping the old common.log is that you can't handle the messages differently depending on their origin and type.
[13:34] <elopio> so I still like this one as a fist step towards using fancier logging.
[13:36] <Chipaca> ogra_: parlez vous ip(8)?
[13:36] <mterry> elopio, that's what arguments to a method are for  :)  but ok
[13:36] <elopio> it handles differently info, error and warning, which we didn't have before. And opens the option to do bold depending on the origin. It's just that current bold rules are not consistent.
[13:36] <mterry> elopio, or even common.info  :)
[13:37] <mterry> elopio, not consistent?  We use them for step declarations and error messages
[13:38] <jdstrand> rsalveti: where is the "user button" on the bbb? I feel silly...
[13:38] <elopio> mterry: well, you can disapprove if you don't like it or don't find it useful. I won't feel bad :)
[13:38] <elopio> mterry: isn't this a step:  print("Installing required packages on the host system: " + ", ".join(newPackages)) ?
[13:39] <mterry> elopio, eh, that's an action inside a step.  we don't bold commands that plugins run
[13:39] <rsalveti> jdstrand: near the sd card
[13:39] <rsalveti> there is only one button
[13:39] <ogra_> Chipaca, "ip -4 route list 0/0"
[13:39] <Chipaca> ogra_: and if they're ipv6-only?
[13:39] <Chipaca> :)
[13:39] <ogra_> Chipaca, thnen you omit -4
[13:39] <rsalveti> jdstrand: https://learn.adafruit.com/system/assets/assets/000/008/680/medium800/beaglebone_BeagleBoneBlack.jpeg
[13:39] <Chipaca> ogra_: nice about 0/0
[13:39] <elopio> mterry: what about snapcraft.common.log(stage + " " + self.part_names[0] + hint) ? Isn't that a command a plugin runs?
[13:39] <mterry> elopio, I'm fine with the idea of loggers in general.  And I don't hugely care how it's implemented.  It just seems like you went out of your way to dismantle central message handling and then bemoan the lack of features that central message handling gives you  :)
[13:40] <mterry> elopio, no that's the 'step declaration'
[13:40] <Chipaca> ogra_: sad that it doesn't error if there's no route to it :)
[13:40] <mterry> elopio, or stage declaration more accurately
[13:40] <ogra_> Chipaca, yeah, it even returns 0
[13:41] <ogra_> you need to check for stdout
[13:41] <Chipaca> mhmm
[13:41] <Chipaca> worse things have come to pass ;)
[13:41] <elopio> mterry: it's more like I got rid of all the things I haven't understood yet, so I could make a transparent change first.
[13:42] <elopio> with these answers you are giving me, I can configure the logging to get rid of the prints. I dislike the central messages because they replace the origin with the common module.
[13:42] <elopio> so maybe if you want, you can wait for me to propose the next couple of branches.
[13:42] <mterry> elopio, makes sense, I'm on board with your changes
[13:43] <mterry> elopio, I'll look at your new branch this morning
[13:44] <jdstrand> rsalveti: boy, not sure I'm coordinated enough to do this (I have mine in the case and turn it on/off by pulling the plug). here goes nothing...
[13:45] <rsalveti> jdstrand: you could as well just erase the internal u-boot (in emmc)
[13:45] <rsalveti> and reboot, that will force it to load the u-boot from the sdcard
[13:46] <jdstrand> rsalveti: it wasn't clear it was possible to do that from my laptop
[13:46] <rsalveti> no, you need do call it on a running system, so under bbb
[13:46] <jdstrand> ie, I thought I might have to actually get into snappy, then erase it
[13:46] <jdstrand> right
[13:46] <jdstrand> hence the being coordinated part :)
[13:46] <rsalveti> so yeah, you'd need to press the user button at least once
[13:46] <jdstrand> anyhoo, I'll figure it out
[13:47] <rsalveti> keep it pressed and then add power to it
[13:47] <rsalveti> reset is not enough
[13:47] <jdstrand> any news on flashing the emmc?
[13:47] <rsalveti> not yet
[13:48] <mterry> elopio, you left fatal in place, which is fine.  But there's a separate bug about snapcraft having too many exit points, and that maybe those fatal calls should be an exception that bubbles up to main() and gets logged there with a sys.exit call there.  Does that ruin your origin info too, or would the exception keeping track of the origin be usable when logging it?  (you don't need to do the exception thing in your branch, just thinking of future ch
[13:48] <mterry> anges)
[13:49] <jdstrand> rsalveti: so, I'm running a 4.2 kernel now (on vivid). I noticed that when I put the sd card in it showed up as /dev/mmcblk0 instead of /dev/sdX
[13:49] <jdstrand> rsalveti: so I just specified /dev/mmcblk0 instead to the dd command. is this something you've seen or think it might be a problem?
[13:50] <jdstrand> rsalveti: I'm talking about the dd to the sd card after creating an image with udf
[13:50] <elopio> mterry: the traces have origin information, but anyway we don't want them to be visible to the user.
[13:50] <ogra_> jdstrand, mmc devices never show up as sdX unless you use a USB reader
[13:50] <rsalveti> jdstrand: yeah, depends on your host
[13:50] <sergiusens> jdstrand: fwiw, my trusty laptop has always had mmcblk nodes
[13:50] <rsalveti> if it's native, it shows up as mmcblk0
[13:50] <jdstrand> ok good to know
[13:50] <sergiusens> depends on how it's connected
[13:50] <elopio> mterry: so the approach I think we should have is replace all those fatal calls by raise. But keep the logging on the module that generates the message.
[13:50] <rsalveti> if under a usb bus, then it shows as /dev/sdX
[13:50] <sergiusens> not sure why it would change though
[13:50] <ogra_> right
[13:50] <jdstrand> before I flashed with a reader in another host. this time I have a slot for the sd card
[13:51] <mterry> elopio, so log the message then raise an error that doesn't include a message (or includes a duplicate, unused message)?
[13:51] <jdstrand> gotcha. I was thinking that was the case but wasn't sure
[13:51] <sergiusens> ogra_: a sw upgrade bringing in a hw upgrade :-P
[13:51] <ogra_> hah
[13:51]  * sergiusens wants his 8 gig of ram sw upgraded to 16!
[13:51] <ogra_> just add zram :P
[13:52] <sergiusens> jdstrand: ah, that explains it
[13:54] <Chipaca> ogra_: better like this?
[13:54] <Chipaca> ogra_: (talking about https://code.launchpad.net/~chipaca/snappy/delayed-service-start/+merge/266166 )
[13:55] <ogra_> Chipaca, beauty !
[13:55]  * Chipaca knows he is
[13:56] <ogra_> :D
[13:56] <Chipaca> one improvement could be to specify /sbin/ip instead of just ip
[13:56] <Chipaca> not sure if i should care :)
[13:56] <elopio> mterry: we can instantiate the exception first, and then use https://docs.python.org/3/library/logging.html#logging.Logger.exception
[13:57] <elopio> we can choose if we want to log immediately after the exception was instantiated, or in a handler in one of the callers.
[13:59] <Chipaca> ogra_: can i say your 'check for default route' insight solved all the ugly/iffy problems in the branch? hence why i say it was brilliant
[13:59] <ogra_> heh, thanks :)
[14:00] <Chipaca> sergiusens: webdm is where the bug is pointed at, but everybody wanting to do multicast will have the same problem
[14:00] <Chipaca> sergiusens: which can be fixed per service by a single setsockopt call before you listen
[14:00] <Chipaca> sergiusens: but golang doesn't let you setsockopt
[14:00] <Chipaca> sergiusens: especially not before listening for multicast udp
[14:00] <Chipaca> sergiusens: youd'd have to rewrite a buuunch of net/
[14:01] <Chipaca> sergiusens: IP_FREEBIND is the sockopt fwiw
[14:01] <sergiusens> Chipaca: yeah, I read the bug report
[14:02] <sergiusens> Chipaca: btw; do we need a separate go bin, or on a different subject, does this need to be a go exec?
[14:06] <Chipaca> sergiusens: webdm -> mdns's openSocket (private) -> net.ListenMulticastUDP[6] -> net.listenIPv{4,6}MulticastUDP (private) -> net.joinIPv{4,6}Group (private)
[14:07]  * Chipaca suddenly feels lagged to the universe
[14:08] <Chipaca> sergiusens: i'm not sure which "this" you mean wrt go exec
[14:08] <Chipaca> sergiusens: you mean, does wait4network have to be go? no
[14:08] <Chipaca> sergiusens: does it need to be separate? well, given it's potentially long lived, i'd rather it weren't all of snappy :)
[14:09] <Chipaca> sergiusens: i could write it in C
[14:09] <Chipaca> sergiusens: it could be sh, also
[14:11] <sergiusens> Chipaca: long lived? doh, didn't see any exit; it's fine as is
[14:11] <Chipaca> sergiusens: I could also stuff it as sh into ExecStart
[14:11] <Chipaca> ExecStart=while ! ip route show 0/0 | grep -q .; do sleep 5; done
[14:12] <Chipaca> dunno what sh systemd uses; if it has builtin [, i could use [ instead of grep for moar cheap
[14:12] <Chipaca> e.g. while [ -z "$(ip route show 0/0)" ]; do sleep 5; done
[14:13] <Chipaca> but that's asking a lot of a random sh
[14:14]  * Chipaca does perf testing of that
[14:17] <elopio> mterry: in this case:
[14:17] <elopio> 133	+    logger.info('Wrote the following as snapcraft.yaml.')
[14:17] <elopio> 134	     print()
[14:17] <elopio> 135	     print(yaml)
[14:17] <elopio> what you want is the first line to be bold, and the rest to be normal? Is that a rule we can apply to all the messages?
[14:17] <jdstrand> rsalveti: sorry for being a pain. are there any known issues with 15.04/edge r132 and bbb? I flashed the sd card and booted holding the button and for sure the emmc didn't load, but neither did snappy
[14:18] <jdstrand> I have udf 0.27-0ubuntu1
[14:18] <rsalveti> jdstrand: hm, did it even boot into u-boot?
[14:19] <rsalveti> U-Boot SPL 2015.07-dirty (Jul 17 2015 - 11:40:49)
[14:19] <rsalveti> that is the boot loader that we are now using
[14:19] <jdstrand> rsalveti: I don't know-- I only ever ssh in. I think I need a cable I don't have
[14:19] <jdstrand> :\
[14:20] <rsalveti> oh, ok, you don't have serial
[14:20] <rsalveti> how did you generate the image?
[14:20] <jdstrand> sudo ubuntu-device-flash core --channel=edge --oem=beagleblack --enable-ssh --output=15.04-edge.bbb 15.04
[14:20] <jdstrand> sudo dd if=15.04-edge.bbb.r132 of=/dev/mmcblk0 bs=32M && sync
[14:21] <mterry> elopio, that case is a little different than the others, a different flow (it's not iterating over parts or whatnot).  So I felt like the 'wrote' message was Snapcraft's top-level "here is what I'm doing" and the yaml was the content (plus it would be too intense if all the yaml was bold)
[14:21] <jdstrand> (I had a mv 15.04-edge.bbb 15.04-edge.bbb.r132 in between)
[14:21] <mterry> elopio, I'm happy to change some of these bold/not-bold decisions.  I just didn't want to block your python logger branch on hashing them out
[14:21] <rsalveti> jdstrand: let me flash it from scratch and see
[14:21]  * mterry is testing your branch right now
[14:22] <elopio> mterry: ok, so what we need is two arguments, a message and a content. Or something like that.
[14:22] <mterry> elopio, except usually the content comes much later (like when running a plugin's step, which has subcommands and all that)
[14:23] <jdstrand> I'm excited to use the snappy-- I think I was affected by the fatwrite stuff cause every once in a while it would upgrade and never come back
[14:23] <elopio> mterry: no, that's alright. We need to figure out a way to make it easier for all the cases. Which is not easy  :)
[14:24] <elopio> there are many ways to do this, with filters, handlers, format and namespaces.
[14:24] <elopio> I'm just trying to figure out which would be clearer.
[14:29] <rsalveti> jdstrand: hm, worked fine in here, got ssh running and was able to get in just fine
[14:29] <rsalveti> took a minute to boot, because of cloud-init, but it was fine
[14:29] <rsalveti> jdstrand: did you put power while pressing the button?
[14:31] <rsalveti> jdstrand: can you also give http://releases.ubuntu.com/15.04/ubuntu-15.04-snappy-armhf+bbb.img.xz a try?
[14:31] <jdstrand> rsalveti: I'll try the whole thing again
[14:31] <rsalveti> this is latest stable
[14:31] <rsalveti> has webdm and ssh by default
[14:31] <jdstrand> I'll try with edge, if that doesn't work, I'll try with stable
[14:32] <jdstrand> thanks
[14:32] <rsalveti> cool
[14:32] <rsalveti> it sucks not having serial easily
[14:32] <jdstrand> and, yes, I held the button down while applying power
[14:32] <rsalveti> jdstrand: can you see blinking leds?
[14:32] <jdstrand> it was difficult, but I mustered the dexterity :)
[14:33] <rsalveti> and the ethernet led as well
[14:33] <rsalveti> just to know if the system booted or not
[14:33] <jdstrand> yeah, all that is illuminated
[14:33] <jdstrand> but it never asked for an ip address
[14:33] <rsalveti> right, so it should be up
[14:34] <jdstrand> actually, there are no blinking leds
[14:34] <jdstrand> there is a solid blue, and then the green for the ethernet
[14:34] <jdstrand> the green is blinking sporadically
[14:34] <jdstrand> anyway, let me try it from scratch
[14:34] <rsalveti> right, the ethernet led is already enabled by u-boot
[14:35] <rsalveti> just the blue leds are the one that actually shows if the kernel booted or not
[14:35] <rsalveti> if it doesn't work, guess you can mount at your host and look for the syslog
[14:35] <ogra_> rsalveti, btw, do we have any docs how we generate that releases.u.c image ?
[14:35] <rsalveti> see if booted in any way
[14:38] <rsalveti> https://trello.com/c/PUpWXouz/89-stable-release-checkpoints
[14:38] <ogra_> (i.e. any ready made scripts or anything)
[14:38] <rsalveti> ogra_: ^
[14:38] <ogra_> ah, k
[14:38] <ogra_> :)
[14:39] <mterry> elopio, you have a conflict on https://code.launchpad.net/~elopio/snapcraft/fix1477638-format_strings-2/+merge/265717
[14:43] <Chipaca> ogra_: sergiusens: http://pastebin.ubuntu.com/11959990/
[14:43] <Chipaca> ogra_: sergiusens: C wins every time :) but sh and go are tied
[14:44] <Chipaca> and they're tied if you're generous towards go ;)
[14:44] <ogra_> heh
[14:44] <Chipaca> go is the only one that made the cpu think
[14:44] <ogra_> yeah
[14:45] <Chipaca> C manages to do it without context major pagefaults \o/
[14:45] <sergiusens> Chipaca: do shell I guess
[14:45] <sergiusens> Chipaca: try python for the kicks :-P
[14:45] <ogra_> lol
[14:45] <Chipaca> i love python, but this is not a dick contest it'd win, ever
[14:46] <ogra_> especially not on arm :)
[14:46] <Chipaca> micropython, however .... :-p
[14:46] <ogra_> hahaha
[14:50] <jdstrand> rsalveti: ok, I have a solid blue led then a couple of rapidly blinking blue leds over the usb port
[14:50] <jdstrand> they are now solid
[14:50] <rsalveti> hm, kernel booted then
[14:50] <ogra_> yeah
[14:50] <jdstrand> and now it is pingable
[14:50] <jdstrand> ok, good!
[14:51] <rsalveti> dholbach: how to change https://developer.ubuntu.com/en/snappy/start/ ?
[14:51] <rsalveti> I get "You do not have permission to edit this plugin"
[14:51]  * jdstrand guesses something went wrong with the initial dd
[14:51] <jdstrand> it's working now though
[14:52] <dholbach> rsalveti, you logged in using /openid/login and all the boxes were ticked?
[14:52] <rsalveti> dholbach: yeah
[14:52] <dholbach> rsalveti, which part of the page are you trying to edit?
[14:53] <rsalveti> dholbach: Getting started with a Beaglebone Black
[14:53] <rsalveti> to add the instruction about the sdcard booting process
[14:54] <dholbach> let me see if I can change it
[14:55] <dholbach> strange, it works for me
[14:55] <rsalveti> hm, let me try to login again
[14:55] <dholbach> mhall119, do you have any idea why rsalveti might get "You do not have permission to edit this plugin" when trying to edit the "Getting started with a Beaglebone Black" section on https://developer.ubuntu.com/en/snappy/start/?
[14:56] <rsalveti> still, even after doing a clean login on another browser
[14:56] <rsalveti> and I was in the developerportal-editors group
[14:57] <mhall119> dholbach: because rsalveti is a suspicious character with questionable motives?
[14:57] <rsalveti> that might be true
[14:57] <rsalveti> :P
[14:57] <mhall119> or because he didn't tell SSO to pass along his team membership?
[14:58] <rsalveti> I did
[14:58] <mhall119> or his session cookie has expired
[14:59] <rsalveti> mhall119: dholbach: so I can change the top part of that page
[14:59] <rsalveti> but not the bbb piece
[14:59] <rsalveti> maybe that is a different page
[14:59] <mhall119> not a different page, but a different content plugin within the page
[14:59] <rsalveti> if I double click at "Getting started with a Beaglebone Black", I get not enough permission
[15:00] <rsalveti> I can change the rpi2 part
[15:00] <mhall119> hmmmm, I can save it (I made no changes)
[15:00] <rsalveti> but not the bbb
[15:00] <rsalveti> the vagrant part is also fine
[15:02] <mhall119> weird...
[15:03] <mhall119> rsalveti: have a call right now,but I'll keep investigating
[15:08] <rsalveti> mhall119: np
[15:33] <Chipaca> pitti: a first pass at moving our services to a generator shows that generators are run before the local fs is mounted
[15:33] <pitti> Chipaca: correct
[15:34] <pitti> they run as pretty much the first thing, as they could (and often do) create early-boot units
[15:34] <Chipaca> pitti: and yet they purport to be for converting one config to systemd services
[15:34] <pitti> like fstab :)
[15:34] <Chipaca> pitti: which is hard to do without a filesystem
[15:34] <pitti> Chipaca: why? the generated units are in /run/
[15:34] <ogra_> tmpfs ftw
[15:34] <Chipaca> pitti: how do you read the config you're trying to convert?
[15:34] <pitti> a generator should *only* create units, it shoudln't actually run logic
[15:35] <pitti> Chipaca: well, you have a r/o root, you can read it?
[15:35] <pitti> oh, unless you need mounts from fstab
[15:35] <Chipaca> i don't seem to have that, no
[15:35] <Chipaca> :)
[15:35] <pitti> we still don't do the writable-mounts from initramfs, but from the running system, don't we
[15:35] <ogra_> yes, you should have the ro root
[15:35] <pitti> Chipaca: ok, if you need info from fstab mounts, you can't use generators, I'm afraid
[15:36] <ogra_> else systemd wouldnt be running ;)
[15:36] <ogra_> the binary was started from that ro root
[15:36] <Chipaca> pitti: can a unit call daemon-reload without the world asploding?
[15:37] <pitti> Chipaca: yes, that should work; daemon-reload is done all the time
[15:37] <Chipaca> that'd work then
[15:37] <pitti> that'll re-run the generators
[15:37] <Chipaca> exactl
[15:37] <Chipaca> y
[15:37] <pitti> but it won't auto-start the new units, as the initial boot transaction already ran; so you need to do that too
[15:38] <pitti> or (and I think that makes much more sense), we move the writable mounts that you need into initramfs
[15:38] <Chipaca> that does sound nicer :)
[15:38] <pitti> booting from a root partition which isn't actually your root partition has caused tons of trouble, you are just experiencing the n+1st one
[15:39] <Chipaca> we'll see; right now i think i need to step away from this for a bit again to do some paperwork
[15:39] <Chipaca> oh man, +1 to initrd-is-root-is-all :)
[15:39] <pitti> yeah, I still remember several hacks because we don't do that, and I'm not even working on snappy :) I guess you guys must have done tons of them
[15:40] <Chipaca> pff
[15:40] <ogra_> pitti, hacks ?
[15:40] <Chipaca> you say hacks, i say flexible engineering
[15:40] <pitti> :)
[15:40] <ogra_> we use the mountroot function of initramfs-tools ... :)
[15:41] <ogra_> (we just replaced all of it, but thats a small detail :P )
[15:43] <Chipaca> that's like saying "oh, no, it's pure regular python; we just patched it to make func_code writable"
[15:43] <ogra_> *g*
[15:43] <Chipaca> ... except in 3.4 func_code *is* writable
[15:43] <Chipaca> hah
[15:44] <longsleep> ogra_: i just got fat corruption with old style u-boot on odroidc ... i guess i should roll a new image asap
[15:45] <ogra_> longsleep, +1 ... stop scaring me like that :)
[15:45]  * ogra_ saw uboot and corruption as first word even before reading the whole line 
[15:45] <longsleep> ogra_: hehe sorry - OLD style uboot only
[15:45] <ogra_> yeah :)
[15:45] <ogra_> *words
[15:46] <longsleep> now of someone would review my OEM snap so i could test with that as well ;-)
[15:46] <ogra_> i wonder if beuno is around to do that :)
[15:56] <longsleep> Now that i am testing again is there something i can do to get rid of all the DISCARD mount output on boot (see http://paste.ubuntu.com/11960346/), or is this normal?
[15:57] <ogra_> i *think* thats a leftover from the phone code
[15:57] <ogra_> but if oyur controller and Sd support it it will speed up your IO
[15:58] <ogra_> we should probably make that configuarable so you can turn it off for HW that doesnt
[15:58] <longsleep> ogra_: yeah - but i think sdcards never support discard
[15:58] <ogra_> i had some (not micro) that did in my ac100 netbook (they made a significant difference on that tiny arm device)
[15:59] <ogra_> not sure if there are any microSDs that support it at all though
[15:59] <ogra_> but i dont think i have seen that error on the BBB
[15:59] <longsleep> oh really - i thought sdcards no matter what size do wear leveling internally
[16:00] <ogra_> http://paste.ubuntu.com/11960398/
[16:01] <longsleep> ok similar
[16:01] <ogra_> no DISCARD messages
[16:01] <longsleep> yes - there are sd controllers pretending to support discard - but still it will not work afaik
[16:02] <ogra_> yeah
[16:02] <longsleep> there is a MMC_ERASE command in the SD spec, not sure how this adapts to discard though
[16:02] <ogra_> the "couldn't mount" thing is fine, thats just the kernel looping over all possible ext filesystems it knows
[16:03] <longsleep> ah ok
[16:03] <longsleep> ogra_: so on the BBB it seems to mount with discard for you?
[16:03] <ogra_> no idea why it first tries ext3, then ext2 and only then ext4
[16:04] <ogra_> yeah, at least it doesnt complain
[16:04] <longsleep> ok let me check that then
[16:04] <longsleep> what card is that ?
[16:04] <ogra_> apw, isnt there a way to turn off that babbling about the kernel trying out filesystems in the logs ?
[16:05] <ogra_> longsleep, some 4GB panasonic one, dunno the exact name ... mediamarkt-cheapo-ware
[16:06] <ogra_> says "made in taiwan" pretty prominently at the front :)
[16:06] <longsleep> ogra_: oh panasonic should be enough, i only seem to have sandisk and sony ones here
[16:07] <ogra_> i dont use the good ones for frequent dd sessions ... i have others indeed
[16:07] <ogra_> 32-128G
[16:07] <ogra_> samsung and lexar
[16:07] <longsleep> ogra_: but even if it would support it, i would still suggest not to use discard mount option. It is much better to regularly run fstrim
[16:07] <longsleep> ogra_: and those mount fine with discard as well?
[16:07] <ogra_> pitti, ^^^ do you know if we do that on snappy
[16:08] <ogra_> longsleep, i have never noticed your error during my boots so i guess they at least hide it well (or i simply never noticed :P )
[16:09] <longsleep> yeah well, some sd controllers just claim they support discard
[16:09] <ogra_> i know we have some userspace stuff to run fstrim regulary ... if the discard option isnt set in fstab
[16:09] <ogra_> but i'm not sure we ship that bit on snapy
[16:09] <longsleep> so when you run fstrim -v /
[16:09] <longsleep> does it trim something ?
[16:10] <ogra_> /: 533 MiB (558919680 bytes) trimmed
[16:10] <ogra_> not bad :)
[16:10] <longsleep> ok - so try again and see if it is zero now
[16:10] <ogra_> yeah, i guess we should make sure to have pitti's fstrim stuff included then
[16:11] <ogra_> yup, it is
[16:11] <longsleep> ok - that seems nice then
[16:11] <ogra_> (and drop discard)
[16:12] <longsleep> mhn no hdparm on snappy :/
[16:12] <ogra_> that was on the list for comfy iirc
[16:19] <longsleep> ogra_: so for your sdcard, can you try to trim system-a from the pc? Also on the pc, what does 'sudo hdparm -I /dev/$sdcard' show for yours if you find the time.
[16:19] <longsleep> ogra_: mine looks like this: http://paste.ubuntu.com/11960496/
[16:19]  * longsleep wants to make sure that it is the sdcard and not the kernel or card reader
[16:21] <ogra_> ogra@anubis:~/Devel/branches/project-rootstock-ng$ sudo fstrim -v /media/ogra/system-a
[16:21] <ogra_> fstrim: /media/ogra/system-a: FITRIM ioctl failed: Vorgang wird nicht unterstützt
[16:21] <ogra_> longsleep, seems my USB reader doesnt hand it through
[16:22] <longsleep> ogra_: so you cannot trim on the PC but on the device?
[16:22] <ogra_> yep
[16:22] <ogra_> might be the cheapo reader i use on the PC
[16:22] <longsleep> ok
[16:22] <ogra_> hdparm isnt helpful either
[16:22] <ogra_> /dev/sdc:
[16:22] <ogra_> SG_IO: bad/missing sense data, sb[]:  70 00 05 00 00 00 00 0a 00 00 00 00 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[16:22] <ogra_> Unknown device type:
[16:22] <ogra_> 	bits 15&14 of general configuration word 0 both set to 1.
[16:23] <ogra_> thats all i get from it
[16:23] <longsleep> oh
[16:23] <longsleep> that is not much - ok so i need to dig deeper and see if i can get this card to trim on another device - thanks for your help
[16:24] <ogra_> thanks or pointin it out, i'll try to catch pitti tomorrow to take a deeper look
[16:25] <longsleep> sounds good thanks
[16:26] <ogra_> *for pointing ...
[16:26]  * ogra_ needs a break :)
[16:26]  * longsleep grabs a Cuba Libre soon :P
[16:26] <ogra_> +1
[16:47] <elopio> mterry: "each part is build" is wrong, right? It should be built, I think.
[16:47] <elopio> english is hard.
[16:47] <mterry> elopio, uh oh, in my docs branch?  Let me see
[16:47] <ogra_> everyone is build !
[16:48] <longsleep> everyone is bluna
[16:48] <mterry> elopio, fixed
[16:48] <ogra_> yummy !
[16:53] <longsleep> New snappy images for ODROID-C1: https://www.stdin.xyz/downloads/snappy/odroidc/20150729/ if anyone wants to try it before i write release notes tomorrow
[16:56] <elopio> mterry: +1, but there seems to be a conflict.
[16:56] <apw> re
[16:56] <elopio> well, a wrong merge actually, you have 415	-<<<<<<< TREE
[16:56] <apw> ogra_, lowering loglevel perhaps, or lowering level logged by syslog
[16:56] <mterry> elopio, in which branch?
[16:57] <mterry> elopio, I just did a merge from trunk, may have screwed up something
[16:57] <ogra_> apw, well, without tweaking the loglevel ... i find this annoying on my desktop too :)
[16:57] <ogra_> couldnt we quieten the driver ?
[16:58] <ogra_> i think it causes a lot of confusion for many people
[16:58] <elopio> mterry: https://code.launchpad.net/~snappy-dev/snapcraft/docs/+merge/266243
[16:58] <ogra_> "i have an error when my rootfs gets mounted"
[16:59] <apw> hmmm really? it has always always done that
[17:00] <mterry> elopio, can you pull or branch again?  I think you have old code?
[17:01] <elopio> mterry: I'm just looking at the MP on launchpad.
[17:01] <elopio> mterry: might be launchpad being crazy.
[17:01] <ogra_> apw, i think it only started with ext4
[17:01] <ogra_> before it didnt loop over ext2 to mount ext3 ... or it simply was quiet when doing that
[17:01] <mhall119> rsalveti: can you try editing the bbb section again?
[17:02] <mterry> elopio, yeah I don't see why it's doing that
[17:02] <mterry> elopio, I mean, I see it doing it.  I just don't understand why
[17:03] <mterry> elopio, ok, merged again from pre-req branch, fixed it
[17:04] <elopio> yes, looks good now.
[18:11] <mterry> lool, when I try your tomcat-webapp-demo, it doesn't seem to run correctly.  journalctl shows "Tomcat started" but no processes are running by the time I get to do a 'ps'
[18:55] <rsalveti> longsleep: still need help with the oem review?
[18:56] <rsalveti> it seems it already landed
[18:56] <rsalveti> so should be all good
[19:09] <rsalveti> mhall119: still can't change it
[19:11] <mhall119> rsalveti: how about now?
[19:12] <rsalveti> mhall119: nops
[19:14] <mhall119> rsalveti: log out and back in?
[19:16] <rsalveti> mhall119: nops
[19:16] <rsalveti> still You do not have permission to edit this plugin
[19:16] <rsalveti> just this part
[19:16] <mhall119> ok...this is very strange indeed
[19:17] <mhall119> rsalveti: ok, one more time, log out and back in, refresh the page (clearing cache) and try it again
[19:18] <rsalveti> mhall119: yay, finally
[19:18] <rsalveti> mhall119: what was it?
[19:18] <mhall119> ok, ok, don't get too excited
[19:19] <mhall119> rsalveti: I made you a super-user, gives all perms to everything, which I'm revoking now
[19:19] <mhall119> rsalveti: log out, back in, and try again please
[19:19] <rsalveti> mhall119: same error
[19:20] <mhall119> heh, well, that narrows it down a little...
[19:20] <mhall119> rsalveti: again please
[19:21] <rsalveti> mhall119: nops
[19:29] <mhall119> rsalveti: again?
[19:29] <mhall119> logging out and back in, refreshing, etc
[19:38] <rsalveti> mhall119: seems to be working
[19:43] <mhall119> getting closer
[20:10] <rsalveti> mhall119: did you fix it or are you trying something else?
[20:11] <mterry> ogra_, OK...  I'm setting up my beaglebone black.  I booted up an sd card with the latest image.  I'm attached via usb.  But when I try to ssh into webdm.local, it isn't responding.  How do I know where I went wrong?
[20:12] <rsalveti> mterry: did you try to boot while holding down the user button?
[20:12] <rsalveti> so it forces it to boot from the sdcard
[20:12] <rsalveti> also, which image are you using?
[20:13] <mterry> rsalveti, one published yesterday or so
[20:13] <mterry> rsalveti, I have to hold down the user button!  didn't know
[20:13] <mhall119> rsalveti: I have you more permissions, now I'm going to take some away until it stops working again
[20:13] <rsalveti> mhall119: alright
[20:13] <rsalveti> mterry: yeah, that's why I'm trying to update our docs :-)
[20:13] <rsalveti> and fighting that over with mhall119
[20:14] <mterry> rsalveti, is it that unlabled button near the sd card?
[20:14] <rsalveti> mterry: https://learn.adafruit.com/system/assets/assets/000/008/680/medium800/beaglebone_BeagleBoneBlack.jpeg
[20:14] <rsalveti> yeah
[20:14] <mterry> rsalveti, ...  that is not user friendly  :)
[20:14] <rsalveti> hold it down and then put power in your board
[20:14]  * mterry loves software
[20:14] <rsalveti> once booted you can erase the u-boot from emmc
[20:14] <rsalveti> then it will automatically load the one from the sdcard
[20:15] <mhall119> rsalveti: try again please
[20:15] <mterry> rsalveti, is there a doc for doing that?  (I have SO little experience with circuit boards)
[20:15] <rsalveti> sudo dd if=/dev/zero of=/dev/mmcblk1 bs=1024 count=1024
[20:15] <rsalveti> once booted
[20:15] <mterry> k
[20:15] <rsalveti> mterry: just the email I sent yesterday atm
[20:16] <rsalveti> mhall119: still fine
[20:16] <mhall119> rsalveti: and now?
[20:17] <rsalveti> mhall119: not anymore
[20:17] <mhall119> rsalveti: how about now, working again?
[20:17] <rsalveti> mhall119: yes
[20:18] <mhall119> ah ha! identified the missing permission
[20:18] <rsalveti> cool, what was it?
[20:19] <mhall119> rsalveti: one last try, I've set the missing permission to the ubuntudeveloperportal-editors group and removed it from your user account, so please try it again and it should (hopefully) still work
[20:20] <rsalveti> mhall119: still working
[20:20] <mhall119> \o/
[20:21] <mhall119> rsalveti: it was the raw HTML plugin permission you didn't have
[20:21] <rsalveti> mhall119: interesting
[20:21] <rsalveti> mhall119: why just that piece?
[20:22] <mhall119> the db setup command gives the editors group permissions to all the Django CMS stuff, but the raw html plugin was something we created, and so it lives outside of the django-cms permissions set
[20:22] <rsalveti> oh, alright
[20:23] <mhall119> so we need to fix the initdb.py command to include that
[20:23] <lool> mterry: Yes, I have to patch the catalina.sh still
[20:23] <mhall119> but for now it's fixed in the production db
[20:23] <lool> mterry: I didn't figure out why exactly, but I need to remove the "&" in the "start" invocations
[20:23] <rsalveti> mhall119: awesome, thanks for helping me out with this
[20:24] <lool> mterry: I couldn't really tell who was at fault, so I didn't examine this further; one way out of it, it to fork catalina.sh into the demo snap, but I had already copied the config and wanted to avoid copying the whole tomcat dist over
[20:24] <mhall119> rsalveti: no problem, thanks for patiently helping me debug it
[20:35] <mterry> Maybe my sd card is bad
[20:36] <mterry> When I press the user button all I ever get is power light on, but no flashing "activity" lights.  and no webdm
[20:42] <mterry> rsalveti, ogra_: ^ tried again with new flashed card.   Is there a way to see what's happening after I boot with the user button pressed?  (definitely different behavior without pressing, but not leading to a working BBB)
[20:43]  * mterry is an idiot!
[20:43] <mterry> BBB isn't connected to ethernet
[20:43] <mterry> I assume I have to do that
[20:45] <rsalveti> if you don't have serial, yes
[20:45] <rsalveti> the only way to access would then be with ssh
[20:46] <rsalveti> without the user button I believe it will end up booting debian instead (which is flashed in the emmc by default)
[20:46] <rsalveti> unless you erased your emmc before
[20:49] <mterry> rsalveti, I think I'm booting off the sd card (I get different light behavior than booting without user button)
[20:49] <rsalveti> right
[20:49] <mterry> rsalveti, ethernet plugged in didn't seem to let me get wedm.local either (and I rebooted the BBB)
[20:49] <rsalveti> might just be missing the ethernet cable :-)
[20:50] <rsalveti> make sure to press the button when powering up the device, only when rebooting is not enough
[20:50] <rsalveti> might take one minute to boot due cloud-init
[20:53] <mterry> rsalveti, powering on is what i meant
[20:53] <mterry> not rebooting
[20:53] <mterry> yeah, i've waited several minutes
[20:53] <mterry> :(
[20:54] <mterry> maybe I will try the raspberry pi
[20:54] <rsalveti> mterry: did you use the pre-built image or did you create one with ubuntu-device-flash?
[20:54] <rsalveti> http://cdimage.ubuntu.com/ubuntu-snappy/15.04/stable/20150729/
[20:55] <mterry> rsalveti, I used http://releases.ubuntu.com/15.04/ubuntu-15.04-snappy-armhf-bbb.img.xz
[20:55] <rsalveti> yeah, should be good
[20:55] <rsalveti> it's the same
[20:55] <rsalveti> that is annoying
[20:56] <rsalveti> when it boots here the blue leds blink for a while
[20:56] <mterry> rsalveti, I'm sure it's user error.  I've just not done this before
[20:56] <mterry> rsalveti, ah interesting.  I get no blinking when I hold down the user button
[20:56] <rsalveti> that means it's not even booting the ubuntu image
[20:57] <mterry> :(
[20:58] <rsalveti> wonder if the default debian image got ssh or some sort of it by default
[20:58] <rsalveti> let me check that
[20:58] <rsalveti> try booting without the sd card to see what happens
[20:59] <mterry> rsalveti, well, booted without the user button anyway.  ethernet in.  Do you know what the default address is?
[21:01]  * mterry will resume this later
[21:02] <rsalveti> Note: Depending on your internal network these may work out of the box
[21:02] <rsalveti> Apache, Port 80: http://arm.local/ (Bone: via usb) http://192.168.7.2
[21:02] <rsalveti> SSH, Port 22: ssh debian@arm.local (Bone: via usb) debian@192.168.7.2
[21:02] <rsalveti> Getty, Serial Port
[21:03] <rsalveti> check http://elinux.org/BeagleBoardDebian as well
[21:03] <mterry> rsalveti, found 192.168.7.2 online yeah
[21:04] <mterry> rsalveti, I can log in to default debian image
[21:04] <rsalveti> nice
[21:04] <mterry> so it's not the board or the ethernet.
[21:04] <rsalveti> sudo dd if=/dev/zero of=/dev/mmcblk1 bs=1024 count=1024
[21:04] <mterry> rsalveti, i checked the shasum of my downloaded image
[21:04] <rsalveti> that will kill the internal emmc u-boot
[21:04] <rsalveti> and will force it to always boot via the sdcard
[21:04] <mterry> rsalveti, ok.  so no user button now
[21:04] <rsalveti> yeah
[21:05] <mterry> rsalveti, hrm.  no blinking lights  :)
[21:06] <rsalveti> makes no sense
[21:06] <rsalveti> maybe try running dd again
[21:06] <rsalveti> sudo dd if=ubuntu-15.04-snappy-armhf-bbb.img of=/dev/mmcblk0 bs=32M
[21:07] <mterry> rsalveti, I already did that over once...  :-/  When I plug it into my laptop, I see all the partitions.  It feels right
[21:07] <mterry> rsalveti, but I can try again, doesn't hurt
[21:08] <rsalveti> unless it's an issue with the sdcard or the reader in the bbb
[21:08] <rsalveti> or a different beagle revision
[21:08] <rsalveti> mterry: give http://cdimage.ubuntu.com/ubuntu-snappy/15.04/stable/20150609/ a try as well
[21:09] <rsalveti> if it doesn't work, that is our previous image
[21:09] <rsalveti> contains a different bootloader