[01:16] <noodles775> Hey people. I'm trying to follow the ec2 getting started guide, but ran into a bunch of problems. I've tried to document them at https://bugs.launchpad.net/developer-ubuntu-com/+bug/1456390 , but any help appreciated.
[01:46] <sergiusens> Chipaca: no worries
[06:38] <dholbach> good morning
[06:45] <mvo> hey dholbach, good morning!
[06:46] <dholbach> hey mvo
[07:34] <davidcalle> Morning all o/
[07:36] <davidcalle> rcj, hello, do you mind having a look at https://bugs.launchpad.net/developer-ubuntu-com/+bug/1456390 ?
[07:39] <mvo> hey sergiusens and Chipaca - good morning! reading https://code.launchpad.net/~stephen-stewart/snappy/docs-tidy-up-package-metadata/+merge/259050 I wonder if we should simply standardize on django markdown and put that in the docs? its seems like a good idea to standardize and we love django :) WDYT?
[08:20] <Chipaca> mvo: gooood morning!
[08:21]  * Chipaca remembers he has a "beuno" script just for this
[08:21] <Chipaca> mvo: goooooooooooooooooooooooooooooooooooooooooooooood morning
[08:21] <Chipaca> see?
[08:22] <mvo> Chipaca: hahaha
[08:31] <JamesTait> Good morning all; happy May Ray Day! 😃
[08:38] <beowulf> morning
[08:41] <JamesTait> o/ beowulf
[08:52] <beowulf> dholbach: hey, bugs in the docs, should they be put into snappy rather than developer-ubuntu-com, or does it not matter? (see noodles775 comment ^^)
[08:57] <dholbach> beowulf, I can't see noodles775's comment - I guess I was not online at the time.
[08:57] <dholbach> beowulf, if the bug is in lp:snappy ./docs/ better fix it there
[08:58] <dholbach> we still have to figure out how to keep both in sync - we didn't quite come to a conclusion during UOS
[09:01] <beowulf> dholbach: ah, it was a bug report (https://bugs.launchpad.net/developer-ubuntu-com/+bug/1456390) and i was curious about the best place for same, as the doc src is in lp:snappy
[09:02] <dholbach> there are two sets of docs
[09:02] <dholbach> there are the snappy internal docs (in the branch)
[09:02] <beowulf> i did not know this
[09:02] <dholbach> on developer.u.c we have most of the internal docs plus other stuff (like installation instructions, etc.)
[09:03] <dholbach> as I said above: things grew quickly so we haven't quite figured out how to go about things
[09:05] <mvo> Chipaca, sergiusens: just fyi, I look at the recent fbtfs, I can reproduce it here in a sbuild environment
[09:07] <davidcalle> dholbach, rcj should be able to help, he provided the ec2 images info for duc, I've pinged him about that
[09:11] <dholbach> thanks davidcalle
[10:15] <Chipaca> mvo: do we want the syslog logger to ignore errors?
[10:17] <mvo> Chipaca: how do you mean? I think its ok if syslog can not be initialized, i.e. I don't think snappy should fail entirely in this case. or was the question about something else?
[10:17] <Chipaca> mvo: sergiusens: I can't find a unit test for the "application" -> "app" type serialization, so am writing it. Holler if it does exist and I missed it somehow.
[10:17] <Chipaca> mvo: yeah, that's what i meant
[10:18] <Chipaca> mvo: that is: i too believe that not being able to connect to syslog should continue, perhaps trying to log to stdout instead? or just not logging
[10:18] <mvo> Chipaca: I think its ok unless I miss a strong reason why its not
[10:18] <mvo> and +1 for the test, I don't know that this is tested yet
[10:18] <Chipaca> mvo: on the *other* hand, if snappy is a long-lived daemon, i think it should not start without a working syslog connection (but maybe make it an option because tests?)
[10:19] <ogra_> did you consider to swithc off logging by default ?
[10:19] <mvo> Chipaca: daemon> that is a good reason, we *might* consider just writing to a logfile in this case and yes, for the tests we should be able to disable it syslog or write a mock
[10:20] <mvo> ogra_: whats the use-case?
[10:20] <mvo> ogra_: to avoid spaming the log?
[10:20] <ogra_> appliuances usually have limited diskspace
[10:20] <ogra_> i would turn off loging completely by default and only log if the user supplies a certain flag somehow
[10:20] <mvo> a good point, however I would be suprised if we are the worst offender when it comes to writing logs
[10:21] <ogra_> really depends ...
[10:21] <Chipaca> ogra_: well...
[10:21] <Chipaca> ogra_: that's an argument to turn off logging to syslog by default
[10:21] <ogra_> some BSP kernels throw out 50msgs per second
[10:21] <mvo> Chipaca: actually mocking syslog is probably the best idea
[10:21] <Chipaca> no need, really
[10:21] <Chipaca> well
[10:21] <ogra_> Chipaca, well, all logging preferably ... probably leaving auth.log in place
[10:21] <Chipaca> depends what you mean
[10:22] <Chipaca> :)
[10:22] <Chipaca> ogra_: oh, you're not talking just snappy here
[10:22] <mvo> ogra_: there was a discussion about syslog vs journald (which uses a fixed log space AIUI) a while ago
[10:22] <ogra_> i'm talking "snappy defaults"
[10:22] <ogra_> in general that is ... not just the daemon
[10:23] <ogra_> android actually only uses ringbuffers for logging to get around this ... but ringbuffers are limited (and gone when you reboot) ...
[10:24] <Chipaca> ogra_: so, currently (as of last night (!)) we have a logger that logs things to syslog, and to the user's face (e.g. stderr if they're on console, or something tbd browser-appropriate for web), the in-users-face does not take up disk space
[10:24] <ogra_> no, indeed not ... but the users face also means a console
[10:24] <mvo> ogra_: right, I think we can get the ringbuffer behavior by just removing rsyslog from the image, then journald takes over and we have the behavior you suggest
[10:24] <Chipaca> ogra_: my expectation is that webdm will provide a logger there that'll show the messages to the user
[10:25] <ogra_> ah
[10:25] <ogra_> that makes sensew
[10:25] <ogra_> -w
[10:25] <Chipaca> ogra_: Notices to a popup, Debugs to the console log
[10:25] <Chipaca> sergiusens: ^ :)
[10:26] <Chipaca> anyway, bottom line, we need to disable syslog because it's FTBFMFS
[10:26] <Chipaca> :)
[10:26] <mvo> well, we need to disable it in the tests at least :)
[10:26] <Chipaca> mvo: would journald pretend it's syslog?
[10:31] <mvo> Chipaca: I think so, I haven't looked into the details though, but I think journald just provides /dev/log and forwards to the rsyslog rightnow
[10:31] <mvo> right now
[10:37] <Chipaca> mvo: sergiusens: is it intentional that we write out "app" as the json of something we read in as "application"? beowulf: does webdm expect "app"?
[10:43] <beowulf> Chipaca: not sure i understand, do you mean the type attr?
[10:43] <Chipaca> beowulf: yep
[10:44] <beowulf> Chipaca: webdm would need to know type oem, app, framework to do filtering, that's all
[10:44] <Chipaca> hmm
[10:44] <beowulf> oh, and to prevent installation of types
[10:44] <Chipaca> beowulf: right. the click store knows "application", not "app"
[10:44] <Chipaca> beowulf: so we're translating in snappy
[10:44] <Chipaca> but that translation is currently one-way
[10:44] <Chipaca> and i was wondering if that was design or accident :)
[10:45] <beowulf> Chipaca: fewer words to describe the same things sounds good to me
[10:58] <sergiusens> Chipaca: it's because they didn't want to add type app on the store side
[10:58] <Chipaca> we *do* have unit tests for serialization!
[10:58] <Chipaca> found them fixing up the code after the move :)
[10:58] <Chipaca> sergiusens: i know why it's there
[10:58] <sergiusens> Chipaca: we will need to add the new names anyways
[10:58] <Chipaca> sergiusens: my question is, is it intentional that we deserialize "application" to "app", but serialize "app" to "app"
[10:59] <ogra_> sergiusens, so after staring at http://bazaar.launchpad.net/~ubuntu-system-image/ubuntu-system-image/server/view/head:/lib/systemimage/generators.py#L525 for half my morning, i'm actually wondering why we dont create the respective files, dirs and links in the respecive initrds, what do you think ?
[10:59] <sergiusens> Chipaca: the store marks anything it doesn't know as application
[10:59] <ogra_> there doesnt seem to be a single dir file or link we would actually need to pre-exist for the initrd ...
[11:00] <ogra_> (and additionally system/userdata could just be a link to system/writable on the phone ...)
[11:00] <ogra_> (or bind-mount)
[11:01] <ogra_> that way you wouldnt run into probs once the rootfs is a snap either
[11:01] <Chipaca> sergiusens: and hydrogen is light, but that doesn't answer my question either
[11:01] <Chipaca> sergiusens: :D
[11:01] <sergiusens> mvo: good morning! Welcome back. And I welcome django
[11:01] <ogra_> unchained ?
[11:01] <sergiusens> ogra_: it's too early or I lack context to understand what you want to tell me :-P
[11:02] <ogra_> sergiusens, this is about not re-packing the rootfs tarball on system-image.u.c
[11:02] <mvo> sergiusens: hey, good morning! ok, I will look into md and lint in a bit
[11:02]  * sergiusens understood the unchained joke
[11:02] <ogra_> so you are at least a bit awake :)
[11:03] <sergiusens> ogra_: so, what files, dirs and links are you talking about?
[11:04] <ogra_> sergiusens, line 525 to 565 in the above link
[11:04] <ogra_> (and later also 488 to 523 for the phone)
[11:05] <ogra_> sergiusens, it alters the rootfs ... rsalveti was suggesting to move these bits to the live-build config instead
[11:05] <ogra_> but i think it might make more sense to do it from the respective initrds
[11:07] <sergiusens> ogra_: we already do a bunch of dir creating in initrd, I don't see a problem aside from the "do the least you can in initrd" mantra
[11:07] <ogra_> (talking to you about it because you spoke up when we discussed it yesterday)
[11:07] <Chipaca> i've got a silly question about initrd
[11:08] <ogra_> there are no silly questions about initrds ...
[11:08] <Chipaca> are the contents of the initrd left mounted so we can use them once booted?
[11:08] <ogra_> no
[11:08] <Chipaca> if not, would that not be a good idea?
[11:08] <ogra_> it never gets mounted
[11:08] <Chipaca> explicitly you mean?
[11:08] <ogra_> the kernel unzips it and unpacks it ... once it is done with using it the memory region it lived in gets flushed
[11:08] <Chipaca> the kernel mounts it directly, and then pivots?
[11:09] <Chipaca> ahh, ok
[11:09] <ogra_> it pivots but to /dev/root (which is a ram device)
[11:09] <sergiusens> ogra_: you could create a kernel that wastes memory and keeps it somewhere accessible inside proc maybe :P
[11:09] <ogra_> yeah
[11:09] <Chipaca> but we still have things in initrd duplicated? but gzipped, so binding probably not doable i guess
[11:10] <ogra_> or just mount --move / /myinitrd at the end before calling run-init
[11:10] <ogra_> (or some such)
[11:10] <Chipaca> i may or may not have abused initrd back when kernel+initrd fitted on a single floppy
[11:10] <ogra_> Chipaca, what is duplicated ?
[11:10] <Chipaca> ogra_: sh? some modules?
[11:10] <ogra_> oh, that
[11:10] <ogra_> yeah
[11:11] <Chipaca> nearly all of initrd i guess
[11:11] <ogra_> we could do the same as andrroid and use initrd as / :)
[11:11] <ogra_> it would grow quite a bit then though
[11:12] <ogra_> (android never pivots ... they just use it as / with a minimal install and then mount nearly everything else in subdirs)
[11:12] <Chipaca> i think this ties in with what we tossed around with i think mvo, about having multiple /bins, so we could have kernel snap have its bin and an oem snap have its own, without having to merge things
[11:12] <Chipaca> (or was it kernel and os)
[11:13]  * ogra_ actually likes that initrd as root approach .... but the press would rip us into pieces :P "Ubuntu goes android OMG !!!11one1"
[11:13] <sergiusens> ogra_: but it is rather clever
[11:13] <Chipaca> dude, we were doing that way before android even existed
[11:13] <ogra_> yeah
[11:14] <Chipaca> it's not invented by them :)
[11:14] <ogra_> Chipaca, using the initrd as default / ?
[11:14] <Chipaca> yeah
[11:14] <Chipaca> well
[11:14] <Chipaca> we == the real open source community
[11:14] <Chipaca> not we == ubuntu :)
[11:14] <ogra_> we only use it as jumpstart and pivot out of it
[11:14] <Chipaca> real as opposed to android, which is openish
[11:15] <ogra_> as a buffer for HW compatibility in fact ... if it comes to ubuntu
[11:15] <ogra_> nothing more ...
[11:15] <Chipaca> i'm pretty sure knoppix did it, for a start
[11:15] <ogra_> i know there is a terminal server project where they do it ...
[11:15] <ogra_> TCOS ...
[11:15] <Chipaca> and it was the only way to do rescue diskettes, and single-diskette distros
[11:15] <ogra_> http://www.tcosproject.org/
[11:16] <Chipaca> mhmm
[11:16] <Chipaca> no need for nfs with that
[11:16] <Chipaca> ie just blat the initrd over tftp
[11:16] <ogra_> heh, last commit 8 months ago ... so not completely dead
[11:18] <ogra_> lol, the page offers packages for dapper ... nice :)
[11:18] <Chipaca> anyway, i guess we're not as constrained for disk space as we were back then, when even a 6$ computer comes with zomg space
[11:19] <Chipaca> can i say "6$ computer" again?
[11:20]  * Chipaca shakes his nostalgia off, like a rain-drenched overcoat
[11:33] <dholbach> davidcalle, let me know when you're there - maybe we can have a quick chat to discuss docs :)
[11:34] <davidcalle> dholbach, in ~15 min?
[11:36] <dholbach> sure, wfm
[11:36] <davidcalle> dholbach, ok
[11:40] <Chipaca> sergiusens: you around?
[11:42] <sergiusens> Chipaca: I need to walk the dogs before meeting marathon starts, so in 10' maybe  ;-)
[11:51] <dholbach> davidcalle, so I thought that it might make sense if we would create google docs (or something) for the articles we want to import as tutorials, test them and bring them up for review for the snappy team, so we can see what's missing, what's broken and what needs to be updated
[11:51] <dholbach> davidcalle, we could also open them up for comments by the wider community
[11:51] <dholbach> and maybe do the same for a "tools overview" kind of article
[11:52] <davidcalle> dholbach, I very much agree, except the Google Docs part, GDocs -> d.u.c is quite painful. On the other hand, I don't have a better idea :)
[11:53] <dholbach> right
[11:53] <ogra_> mvo, do you have any idea why we still build vivid images for core ?
[11:53] <dholbach> davidcalle, maybe we just copy in everything and don't do any markup
[11:53]  * ogra_ notices he gets arm64 failure mails for vivid builds
[11:53] <dholbach> davidcalle, and copy in the same from the gdoc into the html view , so we don't get broken/unnecessary injected markup?
[11:55] <davidcalle> dholbach, sure, that works
[11:55] <dholbach> davidcalle, ok... shall I create placeholder docs in a google folder which we can freely share and we then take it from there?
[11:57] <davidcalle> dholbach, yes, I'll probably be head down in scopes tutorials until thursday, but that sounds like a plan
[11:58] <mvo> ogra_: hi, we need to get a updated image at some point, but I guess we don't really need to have a cron job for that currently
[11:58] <mvo> ogra_: there are a number of pending bugfixes
[12:01] <sergiusens> davidcalle: dholbach git branches and people creating MPs which act as comments
[12:01] <ogra_> mvo, yeah, thats what i thought ... we should build them on demand
[12:02] <dholbach> davidcalle, cool
[12:02] <ogra_> wow ...  http://tracker.geops.ch ... thats like the real world in sim city
[12:03] <ogra_> (shows all buses, trains and trams in realtime for nearly the whole world)
[12:03] <dholbach> sergiusens, ... right
[12:05] <davidcalle> sergiusens, maaaaybe, if you take care of merge conflicts
[12:06] <Chipaca> raaaah, raaaah, i am the shredder of go files, fear me
[12:09] <rickspencer3> hi all ... what is the best way for me to start with a snap in Go?
[12:09] <rickspencer3> ideally, I'd love a QtCreator project, but barring that, any suggestions?
[12:10] <sergiusens> rickspencer3: you can look at webdm or the go example server maybe
[12:10] <rickspencer3> sergiusens, webdm sounds rather complext
[12:10] <sergiusens> I don't think we have qtcreator integration at all with snaps
[12:10] <sergiusens> rickspencer3: right, the go example server is a better start
[12:10] <rickspencer3> I need something where it is obvious where to write the code, and where the snap build command just work
[12:11] <Chipaca> rickspencer3: http://bazaar.launchpad.net/~snappy-dev/snappy-hub/snappy-examples/files/head:/go-example-webserver/
[12:11] <Chipaca> rickspencer3: even includes a friendly README
[12:12] <Chipaca> we're getting soft in our old age
[12:12] <rickspencer3> Chipaca, sergiusens thanks gents, I'll give it a try
[12:12] <rickspencer3> next stop: QtCreator integration
[12:12] <rickspencer3> :)
[12:12] <Chipaca> sergiusens: we should probably make that GOARCH=arm GOARM=7
[12:13] <ogra_> whats GOARM ?
[12:13] <ogra_> and why do you need to specify it
[12:13] <Chipaca> ogra_: 5, 6, or 7
[12:13] <Chipaca> ogra_: because it defaults to 6
[12:13] <Chipaca> ogra_: and we don't really support 6 :)
[12:13] <ogra_> it shouldnt :)
[12:13] <ogra_> (on ubuntu that is) ...
[12:13] <sergiusens> Chipaca: for webdm you mean?
[12:13] <ogra_> sounds like a bug to me
[12:13] <Chipaca> GOARCH=arm GOARM=7 GO7=path GOPATH=....
[12:13] <Chipaca> sergiusens: in the README. But everywhere.
[12:14] <Chipaca> if you're setting GOARCH=arm without also setting GOARM=7, it's a bug
[12:14] <Chipaca> support for ARMv8 is in progress, also, fwiw
[12:15] <Chipaca> sergiusens: i fixed it in webdm way back, btw
[12:19] <Chipaca> @reviewlist
[12:19] <nothal_> https://code.launchpad.net/~chipaca/ubuntu-core-launcher/unshare/+merge/258367 | Approve: 1, Needs Fixing: 1 (12 days old)
[12:19] <nothal_> https://code.launchpad.net/~sergiusens/webdm/queryPackageNames/+merge/258640 | No reviews (10 days old)
[12:19] <nothal_> https://code.launchpad.net/~mvo/snappy/snappy-docs-mdlint/+merge/259490 | No reviews (less than a day old)
[12:19] <nothal_> https://code.launchpad.net/~chipaca/snappy/pkg-types/+merge/259485 | No reviews (less than a day old)
[12:19] <nothal_> https://code.launchpad.net/~mvo/snappy/snappy-fix-ftbfs-sbuild/+merge/259479 | No reviews (less than a day old)
[12:19] <Chipaca> verterok: nothal seems to not find git MPs, btw
[12:19] <Chipaca> verterok: compare with code.launchpad.net/snappy/+activereviews
[12:25] <verterok> Chipaca: probably becase those git MPs are against a new branch which isn't configured? :)
[12:25] <Chipaca> orly? ah ok then :)
[12:26] <verterok> Chipaca: what's git master/trunk branch you want to keep track of?
[12:27] <Chipaca> verterok: i dunno :)
[12:27] <Chipaca> verterok: but there is a high chance of us moving to git in the near future, was just checking whether it'd work
[12:27] <verterok> ah, ok
[12:47] <Chipaca> me, refactoring: http://i.imgur.com/t0XHtgJ.gif
[12:48] <Chipaca> mvo: question about iterHooks: is there a reason this is hung onto the click manifest, instead of the package yaml?
[12:52] <beuno> Chipaca, and then mvo is all like: https://31.media.tumblr.com/28c234e45e157b55f923e109bbb9aa75/tumblr_inline_no7omriCW31raprkq_500.gif
[12:53] <ogra_> LOL
[12:53]  * Chipaca reaches for the mind bleach
[12:53] <verterok> Chipaca: FYI just checked launchpadlib/launchpad API, git branches aren't yet supported there (at least I couldn't find a way to get the MPs for a git repo/branch)
[12:53] <Chipaca> verterok: boo, etc
[12:53] <verterok> indeed
[12:54] <Chipaca> verterok: if only we knew somebody who could ask the launchpad guys what's up with that
[12:54] <verterok> Chipaca: indeed...oh wait! beuno might know
[12:55]  * verterok slowly steps back
[12:55]  * Chipaca grins and gets back to work
[12:55] <mvo> Chipaca: I don't think so really, probably a good cleanup opportunity too
[12:55] <mvo> beuno: *ugh* that was a scary gif, NSFW
[12:56] <Chipaca> mvo: that's where these little branches are all popping out of; start reworking things to be the way i think, get stuck because something seems wrong, back everything out and change that, and start over
[12:56] <Chipaca> it gets easier every iteration \o/
[12:56] <beuno> Chipaca, verterok, http://38.media.tumblr.com/d0d80832b4eb32e06deb46d1d1d774f0/tumblr_inline_nmpwjlVg201raprkq_500.gif
[12:57] <Chipaca> beuno: http://i.imgur.com/eTic1wS.jpg
[12:57] <mvo> verterok: have you asked on #launchpad or #launchpad-dev about this?  cjwatson will certainly know I would be suprised if there is really no way to get that info
[12:57] <sergiusens> Chipaca: did you raise those refactor MPs already or are you still changing the light bulb?
[12:58]  * Chipaca checks his pipeline
[12:58] <ogra_> he is cleaning his face from mvo's kisses still :)
[12:58] <Chipaca> sergiusens: debsig-verify-to-clickdeb and pkg-types
[12:58] <Chipaca> sergiusens: now working on reducing click manifest's reach
[12:58] <verterok> mvo: the devel version of the apidocs shows there is a way to get it...just not yet available in edge/production
[12:59] <sergiusens> @reviewlist
[12:59] <nothal_> https://code.launchpad.net/~chipaca/ubuntu-core-launcher/unshare/+merge/258367 | Approve: 1, Needs Fixing: 1 (12 days old)
[12:59] <nothal_> https://code.launchpad.net/~sergiusens/webdm/queryPackageNames/+merge/258640 | No reviews (10 days old)
[12:59] <nothal_> https://code.launchpad.net/~mvo/snappy/snappy-docs-mdlint/+merge/259490 | No reviews (less than a day old)
[12:59] <nothal_> https://code.launchpad.net/~chipaca/snappy/pkg-types/+merge/259485 | No reviews (less than a day old)
[12:59] <nothal_> https://code.launchpad.net/~mvo/snappy/snappy-fix-ftbfs-sbuild/+merge/259479 | No reviews (less than a day old)
[12:59] <Chipaca> sergiusens: the end game is pkg/snap/ (and not sure whether e.g. pkg/snap/oem or pkg/oem)
[12:59] <Chipaca> that's what i'm incrementally getting at at least
[13:00] <Chipaca> then it's just a move/rename if i've chosen bad names :)
[13:00] <Chipaca> s/if/because/
[13:00] <sergiusens> beowulf: ey, you never reviewed the package queries branch ;-) ^
[13:07] <kyrofa> sergiusens, ping
[13:07] <beowulf> sergiusens: oops, sorry, will do this afternoon
[13:22] <sergiusens> kyrofa: pong
[13:25] <elopio> hey team. This cable works to connect to the beagle serial port, right? http://www.amazon.com/Ftdi-TTL-232r-3v3-Serial-Converter-Cable/dp/B00M41OUYA/ref=sr_1_1?ie=UTF8&qid=1432041571&sr=8-1&keywords=FTDI+to+TTL+3.3
[13:25] <kyrofa> sergiusens, as discussed yesterday (with alecu), webdm does indeed handle broken icons, by using http://webdm.local:4200/public/images/default-package-icon.svg . However, that image is completely blank on my install. Can you confirm?
[13:25] <ogra_> elopio, hard to tell if the order in the plug is correct
[13:25] <kyrofa> sergiusens, does this relate to the svg-png weirdness?
[13:26] <ogra_> elopio, i usually buy cables with "flying ends" so i can more easily re-order them for specific boards
[13:27] <ogra_> elopio, like http://www.amazon.de/gp/product/B00KVUSI30?psc=1&redirect=true&ref_=oh_aui_detailpage_o02_s00
[13:27] <tbr> ogra_: if it's the "standard" FTDI order, then it will work
[13:28] <sergiusens> kyrofa: you want beowulf to assist there; but it is for missing icons, not really broken ones
[13:28] <ogra_> tbr, but not all boards use that order
[13:28] <kyrofa> sergiusens, ah indeed missing, not broken-- sorry
[13:28]  * ogra_ has at least two in the most recent batch of boards on his desk that dont 
[13:28] <tbr> ogra_: BBB and MinnowboardMax do. I have two of those FTDI things
[13:29] <noise][> i have http://www.amazon.com/gp/product/B00IJXNE1W/ and works with BBB, but DONT connect the red power line
[13:29] <ogra_> yeah, you usually dont need the power line at all
[13:29] <sergiusens> elopio: it should, you might be better off with one that has all the pins loose so you can plug them in any order (e.g.; banana pro)
[13:29] <noise][> since it doesn't convert down to 3.3v
[13:30] <elopio> ok, makes sense.
[13:30] <sergiusens> I cut the power line just in case (I bought the bad batch 5vcc 3.3v ttl one that they decided to sell anyways)
[13:30]  * tbr has a bucket of jumper wires for cases where he needs to have random layouts
[13:30] <ogra_> well, you never know if you need it some day ... my power line us tape wrapped :)
[13:30] <ogra_> *is
[13:31] <sergiusens> ogra_: you can always reconnect what you cut ;-)
[13:31] <kyrofa> beowulf, any idea why http://webdm.local:4200/public/images/default-package-icon.svg is blank?
[13:31] <ogra_> sure ... but ripping of tape is easier than soldering :)
[13:32] <ogra_> i havent needed it yet anyway ... could as well have cut it i guess :)
[13:32] <ogra_> RX/TX/GND are usually enough
[13:36] <alecu> kyrofa: is it a blank svg, or is it an empty file?
[13:36] <beowulf> kyrofa: it's not blank, it's a white svg on a transparent background on a white body :)
[13:36] <alecu> ah, that.
[13:37] <kyrofa> beowulf, Ah! That would do it!
[13:37] <beowulf> kyrofa: the default body background is a shade of grey :)
[13:38] <kyrofa> Ah, so it paints through on the "home" page, but appears blank in the store
[13:38] <alecu> kyrofa: to be useful on the scope, perhaps we can ask for the shade of gray to be part of the svg
[13:40] <kyrofa> alecu, good idea. beowulf how would you feel about that?
[13:40] <ogra_> make it 50 though ... thats modern :)
[13:41] <beowulf> kyrofa: what are you trying to do?
[13:41] <alecu> kyrofa: beowulf: I think there should not be icons with transparency in the store (at least that was a requirement for click apps)
[13:41] <alecu> beowulf: we are building a unity8 scope to install snappy apps
[13:42] <kyrofa> beowulf, and we're using the webdm API as a starting point
[13:43] <beowulf> alecu: kyrofa: yeah, i can change this to be an actual icon and not a placeholder (the background is the ubuntu.com background which has all sorts of noise and gradients so picking 'grey' will likely look strange)
[13:43] <beowulf> if you see what i mean
[13:43] <alecu> right
[13:43] <beowulf> so what you want is a proper 'missing icon' icon image
[13:43] <kyrofa> beowulf, that makes sense
[13:44] <kyrofa> beowulf, correct, and using the same one between webdm and the scope makes sense
[13:44] <beowulf> kyrofa: does the scope overlay to make a "squircle"?
[13:44] <beowulf> or do you simply take the icon as you find it?
[13:45] <kyrofa> beowulf, it does make a squircle
[13:45] <beowulf> kyrofa: ack
[13:45] <elopio> dholbach: ping. The two first tables in here are almost the same: https://developer.ubuntu.com/en/snappy/guides/filesystem-layout/#partitions
[13:45] <elopio> why do we need the first table?
[13:46] <dholbach> elopio, I don't know... davidcalle: do you know where we inherited these tables from ^?
[13:46] <kyrofa> beowulf, want me to make an issue for it?
[13:48] <davidcalle> dholbach, imported doc from trunk
[13:49] <dholbach> hum, do you know where it's from?
[13:49] <dholbach> I can't find it in the branch
[13:50] <davidcalle> dholbach, https://bazaar.launchpad.net/~snappy-dev/snappy/snappy/view/head:/docs/system-updates.rst
[13:50] <dholbach> oh ok
[13:50] <beowulf> kyrofa: yes please, thanks
[13:51] <dholbach> elopio, ^
[13:52] <elopio> jodh: ^ Do we need the first table in there?
[14:26] <kyrofa> beowulf, done: https://bugs.launchpad.net/webdm/+bug/1456654
[14:26] <elopio> dholbach or davidcalle: where is the source code for https://developer.ubuntu.com/en/snappy/start/#try-beaglebone ?
[14:26] <dholbach> elopio, there is none
[14:26] <beowulf> kyrofa: thank you
[14:26] <davidcalle> elopio, it's not an imported doc, it's only here
[14:26] <elopio> davidcalle, dholbach: I think this:
[14:26] <elopio> unxz -c ubuntu-15.04-snappy-armhf-bbb.img.xz | dd of=/dev/sdX bs=32M
[14:26] <elopio> should be:
[14:26] <elopio> unxz -c ubuntu-15.04-snappy-armhf-bbb.img.xz | sudo dd of=/dev/sdX bs=32M
[14:26] <dholbach> yes
[14:26] <dholbach> I'll fix it
[14:26] <dholbach> done
[14:26] <dholbach> thanks elopio
[14:26] <jodh> elopio: just the first, or tables in general? I think the information is best presented in tabular form, hence rst (since md has poor support for tables)
[14:26] <elopio> dholbach: thanks!
[14:26] <mterry> Do you folks tend to use one GOPATH for all your branches, and just switch which one is the current "src/launchpad.net/snappy"?  Or do you have a new GOPATH for each branch, which you put at "src/launchpad.net/snappy"?
[14:26] <elopio> jodh: I like tables. It's just that the first table is almost the same as the second table.
[14:29] <sergiusens> Chipaca: the pkg branch looks fine, but what is the next step? Just wondering about the layout there
[14:29] <elopio> jodh: I think we can remove the first table, and just leave the uboot and grub ones.
[14:29] <jodh> elopio: yes, we could drop table 1 and add the FS type and description to tables 2+3, but that would make them a lot wider and duplicate the information.
[14:29] <mvo> mterry: I use a single GOPATH and symlink my snappy branch
[14:29] <jodh> elopio: they contain different information if you look carefully.
[14:29]  * elopio looks carefully.
[14:29] <mvo> mterry: git checkout will fix that nicely its really a non-ideal soluation
[14:29] <elopio> jodh: ahh, I see. You are right.
[14:29] <mterry> mvo, hmm makes sense -- the deps in GOPATH aren't going to need to change between branches
[14:29] <mvo> mterry: yep
[14:29] <elopio> might not fit anymore.
[14:29] <mvo> elopio: this makes me wonder if we could make it more obvious why the tables are obvious, just a random thought while reading your conversation
[14:29] <sergiusens> mterry: I use te same GOPATH
[14:29] <sergiusens> mvo: what might fix it better is to use cheney's go get replacement and just vendor
[14:29] <mvo> sergiusens: I still haven't looked at this yet :/
[14:29] <mvo> I was hoping for git :)
[14:29] <sergiusens> mvo: http://getgb.io/ solves a bunch of problems though ;-)
[14:29] <elopio> I hate this network :@ It disconnects my quassel every two minutes.
[14:33] <elopio> mvo: well, there's a note that says: The boot partition must be formatted as a vfat. We could keep that and add another note saying that the rest of the partitions are ext4.
[14:33] <elopio> not sure if that's better than the table.
[14:34] <elopio> I think I would prefer to duplicate the FS column than to have an extra table.
[14:34] <sergiusens> mvo: did you see anything about zfs making it into the linux kernel btw?
[14:35] <mvo> elopio: i have no strong opinion either way, but it seems like a good opportunity to make the doc better because you look at it with fresh eyes now :)
[14:36] <mvo> sergiusens: I have not, that would be exciting, was there anything new about this recently? I thought there were license issues
[14:37] <sergiusens> mvo: I think I heard some lawyers saying that it's not technically a gpl violation to include it, but I can't find any citation about that when googling; but if it becomes so, we will be in an awesome position :-)
[14:38] <sergiusens> mvo: maybe I read too much into this https://lists.debian.org/debian-devel-announce/2015/04/msg00006.html
[14:39] <elopio> I tried to reinstall my beagle with the stable image, and now I get:
[14:39] <elopio> ssh: Could not resolve hostname webdm.local: Name or service not known
[14:39] <mvo> sergiusens: oh, I think thats about shipping it as a dkms module or something
[14:39] <elopio> is there anything I can check while my serial cable arrives?
[14:40] <sergiusens> elopio: you need to install webdm for that avahi name to be exposed
[14:40] <sergiusens> elopio: maybe u-d-f core 15.04 --output bbb.img --install webdm
[14:44] <elopio> downloading...
[14:45] <mvo> sergiusens: fwiw, https://code.launchpad.net/~mvo/ubuntu-cdimage/mvo/+merge/228214 was my attempt to make the image building indepentant of launchpad
[14:45] <mvo> sergiusens: just fyi, we talked about it during the call
[14:46] <sergiusens> mvo: let's see if ogra_ is bold enough to land that ;-)
[14:46]  * sergiusens reads
[14:46] <mvo> sergiusens: heh, I guess it needs some polish first, but thats the direction
[14:46] <sergiusens> mvo: procmail is a requirement? wow
[14:47] <mvo> sergiusens: thats what I mean with "polish", I think we could do something with python here to avoid this dependency
[14:47] <ogra_> haha "HACKING"
[14:47] <mvo> ogra_: I would like to resurrect something like this, wdyt?
[14:49] <ogra_> mvo, looks fine at a first glance, but if you dont add the necessary changes tpo the selftest too i think cjwatson might hunt me down
[14:49] <sergiusens> mvo: it's not even that invasive
[14:52] <mvo> sergiusens, ogra_: thanks, I will try to spend a bit of time on it this week then
[15:29] <elopio> sergiusens: no luck with the --install
[15:29] <sergiusens> elopio: what kind of no luck?
[15:29] <sergiusens> as in what errors
[15:30] <elopio> same: ssh: Could not resolve hostname webdm.local: Name or service not known
[15:33] <sergiusens> elopio: how is the bbb connected to the network?
[15:33] <mvo> elopio: so "bash" in the selftest and the "why"? it was basicly a quick way for me to not have to run these tests manually, but I much agreee, shell is a bad language for this and sergiusens suggested replacing that with something besser. I wonder if we should go with gocheck for the sake of consistency or python-unittest
[15:35] <sergiusens> mvo: elopio I used to just use pythons default unittest module and have it run all when calling it with the if __main__ gimmick
[15:36] <kyrofa> sergiusens, the icon in the snappy webcam-demo does actually seem to be invalid. Is this known?
[15:38] <sergiusens> kyrofa: yeah, we need lool or asac to setup a proper icon in there
[15:38] <kyrofa> sergiusens, okay, as long as it's a known issue :)
[15:43] <sergiusens> kyrofa: it is ;-) and we expose it loud and clear on webdm :-)
[15:43] <sergiusens> Chipaca: can we discuss 'pkg' now?
[15:44] <kyrofa> sergiusens, Ha! I'm doing the same on the scope :)
[15:44] <Chipaca> sergiusens: sure
[15:44] <sergiusens> Chipaca: ho r irc?
[15:44] <Chipaca> sergiusens: irc would be better right now
[15:44] <Chipaca> sergiusens: or ho in 30'
[15:46] <sergiusens> Chipaca: ho in 30'
[15:46] <Chipaca> sergiusens: k
[15:46] <sergiusens> Chipaca: I wrote something down on the review itself, but the direction would be nice
[15:46] <sergiusens> Chipaca: maybe mvo wants in as well
[15:47] <asac> sergiusens: you can make one :)
[15:47] <asac> i think we have svgs
[15:47] <asac> for the snappy log
[15:48] <asac> you can put a nice camera overlayed over it
[15:50] <sergiusens> asac: I don't have the package sources though
[15:51] <Chipaca> sergiusens: responded in the mp also
[15:52] <Chipaca> sergiusens: question for you: how much do we care about returning "invalid part" when it doesn't have a namespace, in places that don't really care about it?
[15:52] <Chipaca> e.g. in partsForGlobExpr
[15:52] <sergiusens> Chipaca: I need to figure out the ripple effect for that
[15:53] <Chipaca> sergiusens: i ask because i'm trying to move all these "if it's a framework or an oem" thing to one or two places at most :)
[15:53] <Chipaca> that's at the top of the stack, previously at the top of the stack was "make things not use the click manifest", which ended up with more namespace checks everywhere
[15:53] <Chipaca> so, new pipe, clean up namespace whatsits
[15:53] <Chipaca> then back to that one
[15:54] <Chipaca> and then not using the click manifest means one step closer to packageYaml being separable
[15:54] <Chipaca> still a ways off though
[15:56] <Chipaca> man, if i were still in córdoba people would be running around like crazy hiding their cars
[15:56] <Chipaca> the sky is that weird green you get before a big hailstorm
[15:56] <Chipaca> zomg, hail :)
[15:56] <Chipaca> hah!
[15:58] <sergiusens> Chipaca: hah, true :-)
[15:58] <sergiusens> Chipaca: let's move that meet a bit, going to run some lunch errands
[16:26] <elopio> sergiusens: mvo: sorry, had a meeting here, and now lunch. I like the idea of writting the tests in the same language you are using, so go sounds nice. But then we would have to build the tests, or tell adt-run to build them on the board.
[16:27] <elopio> I know python better, and that's easy to write.
[16:32] <Chipaca> elopio: OTOH if you do it in python, then you'd have to get python onto the device
[16:32] <Chipaca> elopio: (we hope to remove python entirely at some point)
[16:32] <beowulf> sergiusens: Chipaca: mind you helping me with this, output of webdm ./build.sh http://pastebin.ubuntu.com/11227865/
[16:33]  * Chipaca looks
[16:34] <Chipaca> beowulf: you're building with the system go, and you don't have the arm system go
[16:34] <Chipaca> beowulf: install golang-go-linux-arm
[16:34] <Chipaca> beowulf: and you should be set
[16:35] <beowulf> Chipaca: thanks
[16:35] <Chipaca> beowulf: option b is you're building with your own go, and haven't done an "all" build with GOARCH=arm
[16:35]  * beowulf makes note to fill out readme 
[16:36] <Chipaca> beowulf: if option b sounded like something almost but not quite entirely dissimilar to gibberish, then it's probably the first one
[16:36] <Chipaca> wait, i
[16:36] <Chipaca> 'm missing a negation in there
[16:36]  * Chipaca adds more negations
[16:36] <Chipaca> beowulf: if option b failed to sound like something almost but not quite entirely dissimilar to gibberish, then it's probably the first one
[16:36] <Chipaca> there, now you can go
[16:38] <beowulf> Chipaca: I...
[16:38] <beowulf> Chipaca: Part II of your test http://pastebin.ubuntu.com/11228018/
[16:39] <Chipaca> beowulf: rm -rfv --wtf --bbq /home/sstewart/go/pkg
[16:39] <Chipaca> beowulf: or set it aside if you'd rather be cautious
[16:39] <Chipaca> also maybe without --wtf and --bbq
[16:40] <beowulf> :)
[16:40] <Chipaca> beowulf: but basically you've got compiled pacakges for go 1.2.x and it's looking for 1.3.x
[16:40]  * beowulf regrets the things he did to end up here
[16:40] <beowulf> Chipaca: thanks, works now
[16:40] <Chipaca> beowulf: i'm sorry
[16:41] <beowulf> Chipaca: whyfore?
[16:41] <beowulf> s/e//
[16:42] <Chipaca> beowulf: i accidentally got you unblocked
[16:43] <beowulf> :)
[16:43] <mterry> sergiusens, I see you added python to the ubuntu-core seed.  It never got released as part of the meta package in the archive though.  Should that still be there/be a part of the meta package?
[16:45]  * mterry wants to release a new meta package removing gawk and original-awk
[16:52] <sergiusens> mterry: I think I proposed it against the wrong seed originally
[16:52] <mterry> sergiusens, you did, but it got put in the right seed.  But still, a new meta package was never spun up
[16:52] <mterry> sergiusens, do we want it in the image?
[16:52] <sergiusens> and either slangasek or mvo (gone) took care of it
[16:53] <mterry> sergiusens, oh
[16:53] <mterry> sergiusens, so we don't want it in the ubuntu-core seed at all?
[16:53] <sergiusens> mterry: I hope I described in the MP why it was suppposed to be there
[16:53] <beowulf> sergiusens: when i build lp:~sergiusens/webdm/queryPackageNames and query /api/v2/packages/?q=8nzc1x4iim2xj1g2ul64 i get too many results
[16:53] <mterry> sergiusens, yeah for "Adding python to system-image seeds to support walinuxagent"
[16:53] <sergiusens> beowulf: to be fair, that just uses the search api from the store, what if you search for something more specific?
[16:54] <mterry> sergiusens, it just never got released as far as I can see, so I wanted to make sure it should still be there before I released a new meta
[16:54] <sergiusens> mterry: great, utlemming did the port to python3 ever get done?
[16:55] <utlemming> sergiusens: yeah, I think we're just waiting on some final bits
[16:55] <utlemming> sergiusens: and an sru for cloud-init
[16:55] <sergiusens> utlemming: great
[16:55] <sergiusens> utlemming: but it's in wily already, right?
[16:56] <sergiusens> mterry: if that port is done, we can get rid of the python dep (which I think was also manually setup in livecd-rootfs as well)
[16:56] <beowulf> sergiusens: actually, results are the same every time... (minor lol that you're asking me to search for somethign more specific than '8nzc1x4iim2xj1g2ul64')
[16:56] <sergiusens> beowulf: :-)
[16:57] <sergiusens> beowulf: weird, it was working fine for me when I tried it...
[16:57] <beowulf> sergiusens: i'll check my install again in a bit, going for food now
[16:57] <sergiusens> ack
[16:57] <sergiusens> beowulf: I'll give it a spin
[16:57] <mterry> sergiusens, well the python dep was never a part of the meta package, and if it will go away for wily, I won't add it now.  I'll drop it from the seed
[16:57] <sergiusens> Chipaca: talk talk?
[16:58] <Chipaca> sergiusens: natter natter
[16:58] <sergiusens> mterry: sounds good
[16:58] <Chipaca> sergiusens: https://plus.google.com/hangouts/_/canonical.com/natter-natter?authuser=1
[19:22] <Chipaca> allright, tests pass, ftw, bbq, & etc
[19:25] <Chipaca> sergiusens: https://code.launchpad.net/~chipaca/snappy/reduce-manifest/+merge/259539 for when you're able and willing
[19:30]  * sergiusens doesn't mind a bbq sprint
[19:30] <sergiusens> Chipaca: you have conflicts
[19:30] <Chipaca> yeah, noticed that
[19:32] <sergiusens> Chipaca: the lp preview really makes it hard to see why, but I guess it's obvious to you so I'll wait before doing a local pull
[19:32] <sergiusens> ;-)
[19:33] <Chipaca> sergiusens: i removed files that have changes in them on trunk
[19:34] <Chipaca> sergiusens: there ya go
[20:04] <Chipaca> tyhicks: nudge nudge
[20:09] <tyhicks> Chipaca: ah! sorry! will do it before my eod
[20:09] <Chipaca> tyhicks: wink wink
[20:09] <Chipaca> tyhicks: say no more
[20:10] <sergiusens> rickspencer3: I reproduced your webdm always wants to upgrade problem on the rpi2 with lool's image; I'm guessing this is a framework problem
[20:10] <sergiusens> I'll research this
[20:10] <rickspencer3> hi sergiusens
[20:12] <rickspencer3> so, if someone builds robots and is interested in snappy, which is the best mailing list to recommend they join?
[20:14] <rickspencer3> sergiusens, did webdm actually work for you on the pi2?
[20:14] <sergiusens> rickspencer3: and it's because the img is bad
[20:14] <sergiusens> rickspencer3: it needs to be regenerated
[20:14] <rickspencer3> seems like we need some kind of CI that a community image developer could run
[20:14] <rickspencer3> sergiusens, ah, lool is on holiday until next week
[20:15] <sergiusens> rickspencer3: no, the oem package is bad; it has a namespace which means it probably was created even before the release
[20:15] <rickspencer3> sergiusens, oh
[20:15] <sergiusens> rickspencer3: he is back on thursday; I can generate one with u-d-f, it should work
[20:15] <elopio> Chipaca: right, but adt-run can install the python deps just for the tests in a tmp dir, and then remove them.
[20:15] <rickspencer3> sergiusens, ok, if you are done soonish I can test it
[20:16] <elopio> I think, I haven't tried installing everything, just some packages.
[20:16] <elopio> it will be slower, while it downloads and installs everything.
[20:16] <sergiusens> elopio: Chipaca our tests could very well be written in go then
[20:17] <sergiusens> no need for dep baby sitting there
[20:17] <Chipaca> elopio: go has very good cross-compilation support, meaning that building it for arm on intel is a no-brainer most of the time
[20:18] <sergiusens> rickspencer3: wrt to the skynet creators, snappy-app-devel I think would be the best
[20:18] <elopio> go it is then :)
[20:18] <sergiusens> elopio: you will love go, like it or not(?) :-P
[20:18] <elopio> I'll try to re-write one, to improve my go.
[20:18] <rickspencer3> thanks sergiusens
[20:19] <elopio> sergiusens: I like go. I just need to learn more.
[20:19] <elopio> so if you see on my branches something stupid, please don't be shy...
[20:20] <sergiusens> elopio: I'm never shy with reviews as I hope people are never shy to say I did something wrong ;-)
[20:21] <Chipaca> sergiusens: we should all go have a sprint at elopio's, to help him get up to speed
[20:22] <Chipaca> sergiusens: he just happens to live a stone throw's away from a rather nice bit of beach
[20:22] <elopio> I pay for the first round of beers!
[20:23] <Chipaca> I can see no holes in this plan
[20:24] <sergiusens> Chipaca: sounds like a plan, rsalveti should set it up ;-)
[20:24] <sergiusens> good team building
[20:24] <sergiusens> and... winter is coming (here)
[20:29] <elopio> well, we don't have winter. But we are in the middle of the rainy season.
[20:29] <elopio> you should bring a poncho, or wait a couple of months.
[20:32] <Chipaca> i've got to wait a couple of months for a passport anyways
[20:37] <Chipaca> verterok: https://github.com/wyc/armbot
[20:37] <Chipaca> verterok: just sayin'
[20:38] <Chipaca> verterok: now all you need to do is rewrite launchpadlib in arm assembly, and you're set
[20:52] <verterok> Chipaca: "motivation: lol"
[20:52] <Chipaca> verterok: :)
[21:00] <rsalveti> yeah, wouldn't mind going there either, raining like hell here lately
[21:00] <rsalveti> and, winder is coming
[21:01] <rsalveti> *winter
[21:14] <sergiusens> ricmm: sudo ubuntu-device-flash core rolling --channel edge --oem generic-i386 --output i386.img
[22:38] <tyhicks> Chipaca: I got started on the review but need some more time to finish up - it'll be my top prio tomorrow morning
[22:39] <Chipaca> tyhicks: ok, thanks!
[22:58] <tyhicks> Chipaca: check out the MP - I found an issue
[22:58] <Chipaca> yeah, just reading it
[22:58] <tyhicks> Chipaca: I haven't had time to think of the proper fix yet and still have more review to do
[22:59] <tyhicks> I gotta run
[22:59] <Chipaca> easiest fix is to not make tmpdir predictable
[23:00] <Chipaca> which was a feature maybe, but maybe not
[23:00] <Chipaca> will chat with mvo tomorrow
[23:49] <ricmm> sergiusens: thanks