[00:13] <stgraber> working LXD snap: https://plus.google.com/+St%C3%A9phaneGraber/posts/aX6vogzEQ1X
[00:13] <stgraber> just got to work on making a more restrictive policy so that it's acceptable for the store
[00:29] <miken> Wow, that's pretty exciting stgraber . Nice work!
[02:50] <sergiusens> elopio: for later lp:~sergiusens/snappy/upgradeBlockedSelfTest
[02:50] <sergiusens> elopio: but I can't run adt on trusty
[02:50] <sergiusens> elopio: 2015/06/17 23:49:21 Error while running [adt-run -B --setup-commands touch /run/autopkgtest_no_reboot.stamp --setup-commands mount -o remount,rw / --setup-commands dpkg -i /tmp/snappy-debs/*deb --setup-commands sync; sleep 2; mount -o remount,ro / --override-control debian/integration-tests/control --built-tree /home/sergiusens/go/src/launchpad.net/snappy --output-dir /tmp/snappy-test/output --copy=/tmp/snappy-test/debs:/tmp/snappy-debs --- ss
[03:36] <elopio> sergiusens: you probably need adt from the ppa.
[03:42] <elopio> https://packages.debian.org/sid/autopkgtest
[03:42] <elopio> not the ppa, the deb ^
[04:44] <elopio> sergiusens: I don't fully understand everything you are doing in your test, but instead of writing the installYaml file, can't we call ubuntu-device-flash with a device-part and deploy that to the testbed?
[04:59] <elopio> snappy team, for when you get up, we seem to have a regression: https://bugs.launchpad.net/snappy/+bug/1466311
[05:01] <elopio> @nothal help
[05:01] <nothal> elopio: No such command!
[05:01] <elopio> nothal -h
[05:01] <elopio> @nothal -h
[05:01] <nothal> elopio: No such command!
[05:02] <elopio> @nothal info
[05:02] <nothal> elopio: No such command!
[06:51] <dholbach> good morning
[07:01] <fgimenez> good morning
[09:04] <JamesTait> Good morning all; happy International Picnic Day! 😃
[09:27] <Chipaca> picnic \o/
[09:39] <dholbach> hey JamesTait - picnic today would be fantastic :)
[09:41] <dholbach> JamesTait, I'm looking at the oem snap bits again today and I'm not quite sure how I'm supposed to use the API :)
[09:41] <dholbach> JamesTait, http://pastebin.ubuntu.com/11734613/ is the bits of information I extracted from our discussion yesterday
[09:41] <dholbach> but I'm not quite sure where to go
[09:42] <ogra_> bah, couldnt they pick a day with better weather at least :P
[09:45] <JamesTait> dholbach, what is it you're wanting to find, exactly?
[09:46] <dholbach> all snaps of the type oem
[09:46] <dholbach> (not sure if we're going to rename them to gadget snaps at some stage?)
[09:48] <JamesTait> dholbach, I think `curl https://search.apps.ubuntu.com/api/v1/search?q=content%3Aoem -H 'X-Ubuntu-Frameworks: ubuntu-core-15.04-dev1'` should get what you want?
[09:51] <dholbach> cool thanks JamesTait - I'll play around with that a bit more
[09:54] <JamesTait> dholbach, it's a bit awkward, because we want queries to be additive - adding more terms to the query should match more documents, with those matching more terms scoring higher so coming first in the results (simplifying a bit) - but filters need to be subtractive - i.e. "don't show me anything I can't use with these frameworks/this architecture/etc."
[09:55] <dholbach> yep, ok
[10:03] <Chipaca> anybody know what restrictions apparmor places on package names / versions / etc, if at all?
[10:05] <jjohansen> Chipaca: apparmor it self? minimal if any, however the are guides for what is allowed in the name
[10:05] <jjohansen> https://developer.ubuntu.com/en/snappy/guides/packaging-format-apps/
[10:06] <Chipaca> jjohansen: yep, i'm aware of what we've documented
[10:06] <Chipaca> jjohansen: i'm documenting what we actually restrict
[10:06] <jjohansen> Chipaca: apparmor does have a few limits on its profile names, the first character is restricted and // is used as name separator similar to how / is used in filenames
[10:07] <jjohansen> Chipaca: so I am not sure the exact mapping of snap name to profile name
[10:07] <Chipaca> jjohansen: ok, ta
[10:07] <jjohansen> Chipaca: currently profile names, require an alpha-numeric or '/' start character
[10:08] <jjohansen> \0 is not allowed as a valid character in the name, and // is interpreted as a name separator
[10:08] <jjohansen> eg.  profile_name//child_name
[10:09] <Chipaca> jjohansen: alphanumeric is [a-zA-Z0-9], yes?
[10:09] <jjohansen> +, &, : are allowed as a leading character in some cases (as compound labels) but not actual profile names
[10:09] <jjohansen> so you might seem them reported by say ps -Z
[10:10] <jjohansen> Chipaca: its actually wider than that
[10:10] <Chipaca> what even is ps -Z
[10:10] <Chipaca> not in the manpage :)
[10:10] <jjohansen> Chipaca: ps -Z will show the security label on a process
[10:11] <jjohansen> $ ps -Z
[10:11] <jjohansen> LABEL                             PID TTY          TIME CMD
[10:11] <jjohansen> unconfined                       3253 pts/1    00:00:01 bash
[10:11] <jjohansen> unconfined                       6951 pts/1    00:00:00 ps
[10:11] <Chipaca> yep
[10:11] <Chipaca> jjohansen: how is the security label connected to the apparmor profile?
[10:11] <jjohansen> that label is mostly likely a profile name, but it could be a compound label
[10:12] <jjohansen> a profile is a label, but a label could be composition of multiple profiles
[10:12] <jjohansen> A//&B
[10:13] <jjohansen> is the intersection of profile A and profile B
[10:13] <Chipaca> woh
[10:13] <Chipaca> interesting
[10:13] <jjohansen> this can show up on stacked tasks (not landed yet)
[10:13] <Chipaca> i'm going to just leave it at "starts with alphanumeric or /", and pretend the other cases are for people who know what they're doing
[10:13] <jjohansen> but also on sockets, and files that have been shared between apps
[10:14] <Chipaca> as what i'm trying to document are the limitations and checks put on a package from its metadata
[10:14] <jjohansen> Chipaca: that is a good idea, at least for now
[10:14] <Chipaca> k
[10:24] <rsalveti> sergiusens: ogra_: http://cdimage.ubuntu.com/ubuntu-core/vivid/daily-preinstalled/pending/ seems all good for vivid as well
[10:30] <Chipaca> mvo_: sergiusens: documenting what we actually do with metadata is making me sad
[10:35] <rsalveti> Chipaca: lol, why?
[10:35] <Chipaca> `name`: documented as `[a-z0-9][a-z0-9+-]`. The `package.yaml` parser requires it to be non-empty (all-whitespace is ok) and that it doesn’t contain a `.`, but otherwise doesn’t care. `ubuntu-core-launcher` requires that appname match `^[a-z0-9][a-z0-9+._-]+$` (this includes the origin though). Apparmor requires the profile name (derived from the package name) start with an alphanumeric (or /). Click review checks against `^[a-z0-9][a-z0-9+-]+$`
[10:36] <mvo_> Chipaca: meh, sounds like a good opportunity to fix it
[10:36] <Chipaca> mvo_: concentrating on writing it out
[10:36] <Chipaca> mvo_: then we can see what/how we fix
[10:36] <Chipaca> it's not just name :)
[10:36] <mvo_> Chipaca: ok, thanks for finding that
[10:36] <Chipaca> and arguably, maybe the checks do belong just in the review tools and snappy should be laxer?
[10:37] <Chipaca> i don't know
[10:37] <Chipaca> i'm just documenting so we can have the discussion :)
[10:37] <Chipaca> trying not to get too bogged down though
[10:37] <rsalveti> yeah
[10:37] <Chipaca> but things like the service's name not being required by the tools are already catching people off guard (because things break)
[10:42] <ogra_> rsalveti, yeah !
[11:29] <sergiusens> elopio: that's what I mentioned in the standup; I wanted a full e2e test but how do I trigger this, where do we store the alternate device.tar (it's not small), etc...
[11:36] <sergiusens> elopio: shouldn't we have adt in a ppa?
[11:47] <mvo_> barry: good morning! I'm curious, what happend here https://code.launchpad.net/~barry/ubuntu-system-image/trunk ? it says "
[11:47] <mvo_> This branch has not been pushed to yet." - I wantd to look at fixing this one bug we talked about yesterday
[11:53] <Chipaca> jdstrand: you around?
[12:07] <sergiusens> hmm, I can't run our integration tests/adt on trusty, it logs me out
[12:08] <ogra_> might be a security feature :)
[12:10] <sergiusens> ogra_: right...
[12:10] <sergiusens> fgimenez: any ideas?
[12:11] <sergiusens> fgimenez: btw lp:~sergiusens/snappy/upgradeBlockedSelfTest
[12:11] <sergiusens> fgimenez: but elopio wants to run the E2E test from the start (I guess he wasn't paying attention to what I said during standup :-P)
[12:42] <jdstrand> Chipaca: I am here but I am heading into a meeting in a few minutes. can I circle back to you?
[12:43] <fgimenez> sergiusens, no ideas atm :( we can talk with elopio later
[12:44] <fgimenez> sergiusens, your branch looks great! now we can split the related tests in different files for instance https://code.launchpad.net/~fgimenez/snappy/failover-tests/+merge/262191
[12:47] <sergiusens> Chipaca: you should go back to square one until he circle's back with you :-P
[12:51] <mvo__> rsalveti: could you commit the recent changelog entries from the upload to trunk please? or if you don't have it I handy can do it too, but currently the daily builds are not updated because of the version number difference
[12:51] <rsalveti> mvo__: oh, creap
[12:52] <rsalveti> crap
[12:52] <rsalveti> I always do that
[12:52] <rsalveti> give me a minute
[12:54] <rsalveti> mvo__: done, sorry for that
[12:54] <mvo__> rsalveti: no worries
[12:54] <rsalveti> you get that feeling that dput is the end result and forget to run bzr push :-)
[12:54] <rsalveti> would be better if a bzr push would automatically cause a dput (or similar)
[12:55] <rsalveti> but well :-)
[12:59] <mvo__> rsalveti: yeah or if we could simply sync our ppa version to hte archive or something
[12:59] <mvo__> rsalveti: fwiw, I'm starting the 16.04 filesystem and packaigng format docs, I noticed they are in the sprint agenda with my name on them
[13:01] <Chipaca> sergiusens: you dieded
[13:02] <Chipaca> sergiusens: hangouts don't like people talking nasty things about grub
[13:05] <mvo__> Chipaca: haha - oh grub
[13:05] <mvo__> Chipaca: anything interessting that is more interessting than trying to write about fs layouts?
[13:06] <Chipaca> mvo__: https://plus.google.com/hangouts/_/canonical.com/theGoodTheBadAndTheUgly?authuser=1
[13:07]  * sergiusens suggests mvo__ to run /nick mvo
[13:08] <barry> mvo__: i'm a bad person: https://code.launchpad.net/ubuntu-system-image/+git
[13:08] <davmor2> sergiusens: but he has been growing that pony tail for so long
[13:15] <mvo> barry: heh, excellent
[13:19] <rsalveti> mvo: the problem with package sync is that the archive police will complain that the changelog contains only "auto build"
[13:19] <rsalveti> maybe we could improve that with our build scripts
[13:19] <rsalveti> mvo_: the problem with package sync is that the archive police will complain that the changelog contains only "auto build"
[13:19] <rsalveti> seems you're having a personality issue
[13:20] <rsalveti> barry: nice
[13:20] <rsalveti> mvo: thanks, got a link for the doc?
[13:21] <barry> rsalveti, mvo: yep, it's great until i tried to land the package through the train.  i feel like i've derailed, or more accurately, tried to drive on a railroad with a different gauge ;)
[13:21] <rsalveti> oh right, not train compatible
[13:26] <barry> rsalveti: except that i have a separate packaging branch and that is still bzr.  the problem is that `bzr merge-upstream` on the resulting orig.tar.gz doesn't do the same thing if you can't merge in the upstream branch too, and that's where i'm going off the rails.  I've got one or two more things to try and then i'm going to punt and do a "normal" distro upload
[13:40] <rsalveti> barry: looks painful, wonder how hard would be for the train to actually support git
[13:41] <barry> rsalveti: i got the impression from robru that it wouldn't be terribly difficult, it's just that they really, really, really need to kill the spreadsheet first
[13:41] <rsalveti> hahaha
[13:41] <rsalveti> indeed
[13:41] <sergiusens> killing the spreadsheet is getting old :-P
[13:41] <rsalveti> don't think it will die
[13:41] <sergiusens> seems like a myth
[13:41] <rsalveti> yeah
[13:41] <barry> naw, it just has enough lives to keep 3 or 5 kittens dancing on rainbows
[13:44] <kyrofa> sergiusens, ping
[13:46] <sergiusens> kyrofa: pong
[13:47] <kyrofa> sergiusens, morning! Quick question: the webdm api uses both DownloadSize and InstalledSize. Knowing which to use if the package is either installed or not installed is easy, but which do I use when Installing/Uninstalling?
[13:48] <kyrofa> A quick glance at the code makes me think installed -> InstalledSize, everything else -> DownloadSize
[13:48] <kyrofa> But I wanted to double-check
[13:48] <sergiusens> kyrofa: that is the right logic
[13:48] <sergiusens> kyrofa: btw, do you have time today to discuss the new api?
[13:49] <kyrofa> sergiusens, sure! I have standup at in about 45 minutes, but I'm free otherwise
[13:51] <sergiusens> kyrofa: so in 10'?
[13:53] <kyrofa> sergiusens, sounds good
[13:59] <kyrofa> sergiusens, I sent you an invite with a video link
[14:00] <mvo> hrm, we really need to kill this global lock, autopilot preventing instlaling apps is anoying
[14:01] <sergiusens> kyrofa: one more sec
[14:02] <kyrofa> sergiusens, no hurry :)
[14:02] <sergiusens> kyrofa: btw, you can make up links as you go
[14:03] <kyrofa> sergiusens, you mean for the hangouts? Yeah, I'm still new at this :P
[14:03] <sergiusens> kyrofa: https://plus.google.com/hangouts/_/canonical.com/[whateveryouwant]
[14:03] <kyrofa> sergiusens, heh, good to know, thanks :)
[14:07] <elopio> good morning
[14:07] <elopio> fgimenez: I'm in the call. talky.io seems nicer than firefox hello.
[14:08] <fgimenez> elopio, mine says connecting...
[14:08] <elopio> fgimenez: I can see you... So not much better.
[14:09] <elopio> fgimenez: yes, I can hear  you.
[14:09] <elopio> well, not anymore.
[14:09] <fgimenez> elopio, wait, i'll try again
[14:24] <alecu> tedg: hi! Is there something similar to click hooks in the snap installer?
[14:25] <alecu> tedg: also, is there something preventing snaps from shipping old fashioned .desktop files?
[14:27] <elopio> fgimenez: it could be talky killing my connection :(
[14:37] <tedg> alecu, Not yet, I've made a proposal on that, but it hasn't be ratified.
[14:37] <tedg> alecu, It will definitely be needed for the Ubuntu Personal use-cases
[14:38] <elopio> Team, can you please look at this: https://bugs.launchpad.net/snappy/+bug/1466311
[14:38] <elopio> breaks the selftest
[14:38] <elopio> rsalveti: ^
[14:39] <tedg> alecu, They can ship a desktop file in the package, but it's not clear whether they have to or not. The thing that won't be possible is to write the temporary ones to ~/.local/share/applications/, those will die.
[14:39]  * tedg does a happy dance
[14:39] <rsalveti> elopio: against which image/channel?
[14:39] <elopio> rsalveti: rolling edge.
[14:40] <elopio> doesn't happen on stable 15.04 that was the other I tried.
[14:51] <elopio> Chipaca: you said building the snappy for arm was simple. How do you do it?
[14:56] <Chipaca> elopio: you mean snappy the commandline tool?
[14:56] <elopio> Chipaca: yes.
[14:56] <Chipaca> elopio: http://bazaar.launchpad.net/~snappy-dev/snappy/snappy/view/head:/docs/cross-build.md
[14:57] <elopio> I was looking in the readme :)
[14:57] <Chipaca> elopio: qué bruto, póngale cero
[14:58] <elopio> :D
[14:58] <elopio> Chipaca: but to get the arm deb, well have to make a chroot, right?
[14:59] <Chipaca> elopio: unless you _really_ enjoy playing with ar, yes
[14:59] <Chipaca> well, dpkg-deb could probably do it :)
[15:09] <alecu> tedg: sounds good, thanks!
[15:16] <jdstrand> Chipaca: hey, what's up?
[15:17] <Chipaca> jdstrand: hey! um.... i think i got my questions answered :) thanks!
[15:18] <jdstrand> ok
[15:18] <sergiusens> fgimenez: elopio maybe you ca merge my branch into yours
[15:19] <sergiusens> fgimenez: elopio or maybe move that branch you are working on to be owned by snappy-dev
[15:28] <Chipaca> jdstrand: i think the last one was about click-review, wrt what ran check_framework, but i found the inspect call
[15:29] <elopio> fgimenez: sergiusens: +1 to merge this rev: http://bazaar.launchpad.net/~sergiusens/snappy/upgradeBlockedSelfTest/revision/510
[15:29] <elopio> I would like to keep the test in a separate MP.
[15:29] <sergiusens> elopio: sure
[15:38]  * elopio gets a trusty vm
[15:41] <sergiusens> Laney: http://paste.ubuntu.com/11735924/
[15:42] <sergiusens> can you take a look and fix that please?
[15:47] <fgimenez> sergiusens, elopio ok merged into lp:~fgimenez/snappy/go-functional-tests
[15:48] <roadmr> hey snappers! I hooked up a webcam to my rpi2 and installed the webcam snap but it gives a permission denied error. I already 666'd /dev/video0, where else could I look? http://paste.ubuntu.com/11735959/
[15:49] <sergiusens> roadmr: you need to hw-assign to the snap
[15:50] <sergiusens> roadmr: https://developer.ubuntu.com/en/snappy/guides/appliance-builder-guide-webcam/
[15:50] <roadmr> sergiusens: oh! cool, let me do that
[15:50] <roadmr> sergiusens: haha thanks, that was my next question: "where would one find out about this?"
[15:51]  * roadmr just deleted the webcam snap by mistake - reinstalling haaha
[15:51] <sergiusens> roadmr: I fear we don't have specific docs about security things at a user level, do we jdstrand ?
[15:51] <elopio> sergiusens: but I still need the -uc -us to avoid the signing.
[15:51] <sergiusens> elopio: sure, add that back
[15:52] <jdstrand> sergiusens: we do not afaik. hw-assign should be documented somewhere
[15:52] <jdstrand> (in all its forms)
[15:52] <elopio> fgimenez: and we need a better handling on the command line arguments. For now we could support running in beaglebone by passing the debDir.
[15:53] <sergiusens> elopio: I added the "provide my own bzr bd'ed debs" since this did something weird with my system (http://paste.ubuntu.com/11735996/)
[15:53] <plars> elopio: so I was thinking more about our discussion and got to wondering... could we use the a-b booting of snappy to try new images with automatic recovery if things go badly? Do we have enough control from within snappy to make that happen?
[15:53] <sergiusens> elopio: just use the flags package or what we use
[15:53] <fgimenez> elopio, i had a branch somewhere that used flag, worked pretty well
[15:54] <sergiusens> elopio: http://golang.org/pkg/flag/ or http://godoc.org/github.com/jessevdk/go-flags (which we use everywhere now)
[15:54] <plars> elopio: so in other words, keep system-a as a stable image that we never really need to change, use it to flash the new stuff (even possibly a different channel, release, etc) to system-b, reboot, see if we are in the new one, run tests, and force it back to system-a when we are done?
[15:54] <fgimenez> elopio, http://bazaar.launchpad.net/~fgimenez/snappy/cross-compile-debs/view/head:/_integration-tests/main.go
[15:55] <elopio> plars: we want to test upgrades, so we need to put in a version n-1 and in b version n.
[15:55] <jdstrand> sergiusens: I was going to do an MP for hw-assign and then decided not to because I didn't feel I had all the details for the oem part bits and wasn't sure if there was something beyond oem and the hw-assign command
[15:56] <plars> elopio: oh I see, that would break upgrade testing
[15:56] <elopio> plars: for that to work, we would need a c partition, with the pristine factory approved image. Which is something I think sergiusens is planning for.
[15:56] <roadmr> sergiusens: thanks, it works \o/ I'm now reading that doc you pointed me to
[15:56] <plars> elopio: can we have a system-c for that? :)
[15:56] <plars> hah, that's what I was just wondering
[15:57] <plars> so the pristine image in c would be our "stable" image that we always go back to for flashing the other ones?
[15:57] <plars> sergiusens: how would all that work exactly?
[15:57] <elopio> plars: https://docs.google.com/document/d/15nqsGbqxSzArRoqjnydsUYfbqHDYNtVayo6WlrmVGG0/edit#
[15:57] <plars> sergiusens: right now I'm planning some hard-wired boot control with relays to select whether we boot from emmc or sd on bbb, but something like this would give us a better mechanism that could work even in the absence of emmc
[15:58] <sergiusens> plars: my plan is for a snappy-factory partition
[15:59] <sergiusens> plars: elopio and now I get to say ricmm has ignored my proposal so far ;-)
[16:00]  * sergiusens drops a smoke bomb to go get some lunch
[16:00] <elopio> sergiusens needs a hug. He's feeling ignored often these days :)
[16:00] <Laney> sergiusens: ok, done
[16:01] <sergiusens> Laney: thanks
[16:02] <plars> sergiusens: it sounds like this would give me exactly what I'm looking for, as long as I could force booting into recovery somehow, it can even be used to flash a completely new image on the non-recovery part right?
[16:03] <sergiusens> plars: yeah, it can be a deploy/installer thing as well
[16:03] <sergiusens> plars: and no more u-d-f complications either :-P
[16:03] <plars> ricmm: how many beers can we bribe you with to look at this? ^ :)
[16:06] <plars> sergiusens: elopio: so how does that work if it fails to boot the image that you flash (or upgrade to)? Does it automatically failover or do you have to take some action?
[16:07] <ogra_> plars, beers dont work, try lagavulin
[16:07] <plars> ogra_: that works too, as long as I can help drink it :)
[16:07] <ogra_> :)
[16:07] <elopio> plars: currently, you have to reboot to failover to the good image.
[16:07] <elopio> I think that should happen automatically.
[16:08] <sergiusens> plars: http://blog.sergiusens.org/posts/Snappy_rolling_back_on_kernel_panic/
[16:08] <ricmm> ricmm: this is being looked at and spec'd
[16:08] <ricmm> the factory partition that is
[16:09] <plars> elopio: that could be handled by waiting a reasonable amount of time to boot and triggering the reset if you don't hear back in time. And on reboot it would automatically boot the other one somehow? /me looks at the post
[16:11] <elopio> plars: yup. Or you could even perfor a factory reset by pressing buttons if the board is unresponsive.
[16:12] <fgimenez> nice evening everyone o/
[17:00] <zyga> ogra_: what's needed to get raspberry pi to upgrade normall?
[17:00] <ogra_> zyga, all kernel code upstream, all uboot code upstream
[17:01] <zyga> ogra_: hmm, but if I have a normal os snap and rpi specific snaps for the rest
[17:01] <zyga> ogra_: should it not be possible to upgrade in-image?
[17:01] <zyga> ogra_: I see that the kernel code is not in mainline kernel
[17:01] <ogra_> you could update these two parts manually perhaps
[17:01] <zyga> ogra_: I see, thanks
[17:02] <ogra_> but snappy upgrade will still not give you an upgrade of ubuntu-core via the store
[17:02] <zyga> ogra_: btw, for beagle, have you tried USB-booting?
[17:02] <jkridner> zyga: with BBBlfs?
[17:03] <zyga> jkridner: yes
[17:03] <ogra_> nope, Pi kept me busy the last weeks, i havent touched my beagle for a while
[17:03] <zyga> jkridner: there are other tools but that's the one I thought about
[17:03] <jkridner> zyga: yeah. that's the one I think has the most attention now...
[17:04] <jkridner> I'm in the process of trying to setup a test bench using bbblfs.
[17:04] <ogra_> zyga, it shouodnt be a prob to switch the writable partition to USB actually
[17:04] <ogra_> the initrd mounts everything by labels ...
[17:04] <zyga> ogra_: no, not like that
[17:04] <zyga> ogra_: flash remotely via usb-otg
[17:04] <ogra_> oh
[17:04] <ogra_> like the panda
[17:04] <zyga> jkridner: what are you doing this for?
[17:04] <zyga> ogra_: yes
[17:04] <zyga> ogra_: probably _exactly_ the same ;-)
[17:04] <longsleep> ogra_: Have you looked into available entropy on the RPi2 when it generates ssh keys on first boot?
[17:04] <ogra_> :)
[17:05] <zyga> jkridner: I'n looking at working with a few people to set this up for the testing lab
[17:05] <ogra_> longsleep, not yet, nope
[17:05] <ogra_> i'm still figthing with dtb overlay support ...
[17:05] <ogra_> why cant every board be as nice as the beagle *sniff* :(
[17:05] <longsleep> ogra_: DTB overlay - what do you need it for?
[17:05] <zyga> jkridner: what is your goal?
[17:05] <zyga> jkridner: perhaps we can work together
[17:06] <jkridner> zyga: I'm also looking at using the BeagleBone Black's ability to cut power to the USB.
[17:06] <ogra_> longsleep, the Pi doesnt allow using the extension headers with i2c if you dont add the right dtb overlay ... etc etc ... (there are more overlays for other HW parts)
[17:06] <longsleep> ogra_: well i guess Snappy needs a way to handle any messy U-Boot and Kernel :)
[17:06] <ogra_> yeah
[17:06] <ogra_> thats what i'm fighting with
[17:06] <zyga> ogra_: actually, I was meaning to ask you about one thing
[17:06] <jkridner> I'm trying to build a test infrastructure for the http://github.com/beagleboard/linux and http://builds.beagleboard.org with a bunch of capes attached.
[17:07] <jkridner> beaglebone-per-cape.
[17:07] <zyga> ogra_: can we try to formalize remote flashing for snappy core
[17:07] <jkridner> so that we can make sure all the capes are supported in the mainline kernel.
[17:07] <zyga> ogra_: we'll need that a lot for the lab
[17:07] <zyga> jkridner: oh, fantastic
[17:07] <longsleep> ogra_: I see - i have a similar "problem" - i need to remove certain stuff from the DT based on boot settings - can that be done with overlay too?
[17:07] <zyga> jkridner: so I have to ask, have you tried lava?
[17:07] <zyga> [I used to hack lava a lot in the past]
[17:07]  * jkridner looks around for rcn-ee
[17:07] <ogra_> zyga, well, you wont do it fully remote unless you have some MMC or other storage with the bootloader onboard
[17:07] <zyga> ogra_: for beagle and some others that's true
[17:08] <zyga> ogra_: but let's think big
[17:08] <zyga> ogra_: for products
[17:08] <ogra_> yes, thats the prob :)
[17:08] <zyga> ogra_: something we could require at snappy level
[17:08] <ogra_> thinking big means taking tons of cases into account
[17:08] <zyga> ogra_: android wouldn't go far without fastboot/adb
[17:08] <zyga> ogra_: or forcing standards
[17:08] <ogra_> so we need to start actually small to be flexible ;)
[17:08] <jkridner> we plan to overwrite the bootloader in eMMC using the ROM bootloader.
[17:08] <rcn-ee> jkridner, never touched lava. ;)
[17:08] <ogra_> rcn-ee, its hot !
[17:08] <longsleep> I will be adding a couple of issues to the Snappy tracker soon, regarding entropy, customization of boot and such - or is it too early to push for stuff like this?
[17:09] <zyga> jkridner: I'm starting to build a lab-as-a-service
[17:09] <zyga> jkridner: with a few other people
[17:09] <ogra_> longsleep, no, keep the bugs coming
[17:09] <ogra_> longsleep, we might not solve it immediately, but having it tracked is important
[17:09] <zyga> jkridner: our first use case is exposing beagle's for testing anything
[17:09] <jkridner> right now, we are just trying to establish we can power cycle and boot/flash a downstream board.
[17:09] <ogra_> longsleep, i need to try your image on my odroid too :)
[17:09] <jkridner> trying to minimize cost and complexity, leveraging whatever Beagles give us.
[17:09] <zyga> jkridner: we have a lot of experience with that, plars can tell you about it :)
[17:09] <longsleep> ogra_: Great - then i will just keep adding them once i have understanding what i would need
[17:10] <zyga> jkridner: there's a trick that we used in lava and that works well for mostly anything
[17:10] <longsleep> ogra_: Yeag that would be awesome. I heard reports from all over the world that it seems to be working.
[17:10] <ogra_> well, plars wrote lava ... essentially :)
[17:10] <zyga> jkridner: all that you need is a way to power the board
[17:10] <zyga> ogra_: hey, I wrote a lot of it too :P
[17:10] <ogra_> oh, right :)
[17:10] <plars> indeed, zyga was right there sharing the blame :)
[17:10] <ogra_> i always forget that you were on the other side of the fence for a while
[17:10] <zyga> ogra_: (and gave it the failed launch-control name)
[17:11] <zyga> ogra_: nah, there was no fence
[17:11] <jkridner> rcn-ee: if I reflash bone1 with the 5/1 image, I should at least have a gserial connection, so I'm going to do that now.
[17:11] <ogra_> lol
[17:11] <plars> ogra_: in fact, that's where he started
[17:11] <zyga> yeah
[17:11] <ogra_> oh
[17:11] <ogra_> i thought you started in canonical :)
[17:11] <rcn-ee> jkridner, correct..
[17:11] <jkridner> zyga: yeah, we need some ideas for power.... we can cut USB power, but we'll need some additional juice a couple boards down the test chain.
[17:11] <zyga> ogra_: well, I kind of did start in linaro and canonical but back then linaro didn't have a nme
[17:11] <zyga> name*
[17:12] <ogra_> oh, i remember
[17:12]  * ogra_ is getting old 
[17:12] <zyga> jkridner: I think if you are serious about it you should just get a controllable power strip and focus on the hard bits
[17:12] <Chipaca> hmm, ssh doesn't let me in in rolling/edge #80
[17:13] <plars> jkridner: what are you trying to do exactly? I'm trying to sort through the backscroll. Right now I have a modified uboot on my emmc to use the gpio connected to s2 to boot from the right place. The default gave me some funny behavior where if you pressed s2 it would load uboot from the sd card, and boot the image on emmc, with s2 unpressed it would load
[17:13] <plars> uboot from emmc and boot the image on the sd
[17:13] <plars> zyga: but for snappy purposes, it looks like we may soon have a WAY easier solution to all this, that works even if you don't have emmc
[17:13] <jkridner> rcn-ee: ugh, I just realized 5/1 is a 4GB image. :(
[17:14] <zyga> plars: oh, tell me?
[17:14] <zyga> plars: a-b?
[17:14] <zyga> plars: or something else
[17:14] <plars> zyga: right, I was discussing earlier
[17:14] <plars> zyga: a-b-c actually
[17:14] <zyga> plars: but for
[17:14] <zyga> oooooh
[17:14] <zyga> yes
[17:14] <zyga>  yes
[17:14] <zyga> I see this
[17:14] <plars> zyga: with c being recovery
[17:14] <zyga> well
[17:14] <jkridner> zyga: why shouldn't I try to find something cheaper?
[17:14] <zyga> abc is just master
[17:14] <plars> zyga: http://blog.sergiusens.org/posts/Snappy_rolling_back_on_kernel_panic/
[17:14] <zyga> proper
[17:14] <rcn-ee> jkridner, i'm setting up a 2gb image right now. ;)
[17:14] <zyga> jkridner: it's not expensive and your time is probably always more expensive
[17:14] <plars> zyga: right, done officially rather than hacking around it and screwing with the images like we had to do in linaro
[17:15] <rcn-ee> jkridner, flasher is here: https://rcn-ee.com/rootfs/bb.org/testing/2015-06-17/lxqt-2gb/BBB-eMMC-flasher-debian-8.1-lxqt-2gb-armhf-2015-06-17-2gb.img.xz
[17:15] <zyga> plars: I wrote about something like this
[17:15] <zyga> plars: let me find a link
[17:15] <zyga> (for snappy actually)
[17:15] <zyga> a few months back
[17:15] <plars> zyga: istr at the time telling people it wasn't so crack as they wanted to think - it's what android does too really
[17:15] <jkridner> rcn-ee: downloading.
[17:15] <jkridner> 4.1?
[17:15] <rcn-ee> yeap! ;)
[17:15] <jkridner> sweet.
[17:16] <zyga> plars: do you know when it will be ready
[17:16]  * zyga looks for the link
[17:17] <plars> zyga: no, sergiusens has a proposal but I don't think it's actually been reviewed/approved yet
[17:17] <elopio> Chipaca: let me know if you figure out the ssh in rolling edge. It works from my laptop, but doesn't from my desktop.
[17:17] <plars> writeup of the proposal, not a merge proposal :)
[17:17] <Chipaca> elopio: you broke it!
[17:18] <Chipaca> elopio: personally, i think it's a sign from olympus that i should go get dinner moving
[17:18] <sergiusens> plars: so ricmm owns the solution, I just had a proposal to make thing look a lot simpler from a builders perspective
[17:18] <elopio> some things are broken on my laptop, some things are broken on my desktop.
[17:18] <ogra_> so you just painted it over ?
[17:18] <elopio> why can't they just break equally, so I can go to sleep?
[17:19] <sergiusens> elopio: siesta time?
[17:19] <elopio> sergiusens: no, too early.
[17:19] <sergiusens> lol
[17:19] <zyga> sergiusens: is the solution any different from what plars talked about?
[17:19] <rcn-ee> jkridner, pushed, so the x15 is now set for 2gb/jessie/v4.1.x *.img builds ;)
[17:19] <zyga> gaah
[17:19] <zyga> how do I find a bug
[17:19] <zyga> that I commented on
[17:19] <zyga> a while ago
[17:19] <sergiusens> elopio: I have my siesta when Europe has dinner; but that was when I was the only team member in the americas
[17:19] <zyga> not on checkbox
[17:19] <zyga> probably system-image-server
[17:19] <zyga> google
[17:19] <zyga> damn you
[17:19] <sergiusens> zyga: I can't even find bugs by title sometimes
[17:20] <ogra_> geez ...
[17:20] <sergiusens> zyga: it's like commenting into the void
[17:20] <ogra_> go to your own LP page
[17:20] <sergiusens> or irc... :-P
[17:20] <ogra_> click on bugs ...
[17:20] <ogra_> and then invest 2h
[17:20] <sergiusens> ogra_: bugs you commented on?
[17:20] <zyga> hahahaaha
[17:20] <zyga> ogra_: I've been there
[17:20] <sergiusens> or created?
[17:20] <zyga> ogra_: 2 of 276 pages
[17:20] <zyga> right
[17:20] <ogra_> sergiusens, yes
[17:20] <elopio> sergiusens: I have my siesta after lunch, which should be in an hour.
[17:20] <elopio> but I might have to change my schedule, it feels lonely to work here during my night. I miss veebers.
[17:21] <plars> elopio: what's up with ssh? it's not just the /etc/ssh/sshd_not_to_be_run thing right?
[17:21] <plars> Chipaca: ^
[17:21] <sergiusens> elopio: lol; yeah, rsalveti always wondered why I started to wake up earlier, he's doing the same now :-P
[17:21] <roadmr> zyga: https://bugs.launchpad.net/~zyga/+commentedbugs and then click on "date last updated" to see more recent updates first?
[17:21] <sergiusens> plars: if cloud init runs and ssh: on is not set in meta-data you get that file
[17:21] <sergiusens> fyi
[17:22] <sergiusens> ogra_: Chipaca simple MP https://code.launchpad.net/~sergiusens/goget-ubuntu-touch/warnDevice/+merge/262369
[17:22] <zyga> roadmr: I'm there now, I just also added some advanced options to show closed bugs
[17:22] <roadmr> zyga: awesome :)
[17:22] <zyga> I only wish I could _not_ see checkbox bugs
[17:22] <sergiusens> zyga: please, I want out of that team, it's too verbose :-P
[17:22] <ogra_> sergiusens, approved
[17:23] <zyga> sergiusens: do you get checkbox email traffic?
[17:24] <zyga> found it
[17:24] <zyga> https://bugs.launchpad.net/ubuntu-system-image/+bug/1371703/comments/4
[17:24] <zyga> plars: ^^
[17:25] <rcn-ee> jkridner, can we glue s2 down? or short a pin to always force s2, (for BBBlfs)
[17:25] <zyga> rcn-ee: yes
[17:25] <roadmr> sergiusens: next time you get a checkbox bug, check the headers and let us know the x-launchpad-rationale, we can figure out why you get it and if you can be spared (assuming you really don't want it :)
[17:25] <zyga> roadmr: x-launchpad-rationale: it's a bug
[17:26] <roadmr> x-launchpad-message-rationale zyga haah but yes it'll tell us why he is getting notifs for checkbox bugs. Is he in the checkbox team? he may want out. Is he part of a subteam? he may be in trouble :)
[17:27] <sergiusens> roadmr: I think zyga added me to the team
[17:27]  * sergiusens checks
[17:27] <zyga> sergiusens: I stopped reading most email because of the insane volume of email this generates
[17:27] <plars> rcn-ee: jkridner: I just use a jumper (or relay if I want control) from the lcd_data02 gpio to gnd
[17:28] <zyga> plars: what's the current that this sinks?
[17:28] <rcn-ee> thanks plars, i'm shoving a jumper in it..
[17:28] <jkridner> rcn-ee: like plars said, I think we can tie something else on the board....
[17:28]  * zyga should move his @ss and check
[17:28] <jkridner> but....
[17:28] <zyga> plars: do you think that a small resistor would be safer there?
[17:28] <jkridner> if we just corrupt the image, we should get a USB boot attempt, I believe.
[17:28] <zyga> jkridner: usb and serial boot always take priority
[17:28] <zyga> jkridner: the boot order is AFAIR serial -> usb -> emmc -> sd
[17:29]  * jkridner would need to look at the boot order.
[17:29] <zyga> jkridner: with s2 pressed it is  serial -> usb -> sd -> emmc
[17:29] <jkridner> oh!
[17:29] <jkridner> nice.
[17:29] <zyga> jkridner: the reference manual is huge so I cannot check unless I remember how I found that
[17:29]  * jkridner wonders if bbblfs will catch the USB boot in time.
[17:29] <rcn-ee> weird, i was just referencing bbblfs readme.. ;)
[17:29] <rcn-ee> adding bbblfs to the default build too...
[17:29] <zyga> jkridner: no, I think you need to have something more automated to do that
[17:30] <zyga> jkridner: you have very little time to do the serial boot handshake
[17:30]  * jkridner is dealing with stupid uSD adapter not working on laptop. :(
[17:30] <jkridner> zyga: we are doing USB.
[17:30] <zyga> jkridner: usb is just serial protocol over usb really
[17:30] <jkridner> zyga: not true.
[17:30] <jkridner> zyga: it uses RNDIS.
[17:30] <jkridner> it shouldn't, but it does.
[17:31] <jkridner> it was a silly design decision.
[17:31] <zyga> jkridner: hmm, I'm pretty sure that the usb boot protocol sends a few magic packets
[17:31] <jkridner> it is essentially TFTP over RNDIS.
[17:31] <zyga> jkridner: and later on you do anything from the payload you copied over
[17:31] <jkridner> zyga: if it does, then it'd be breaking RNDIS, but I guess that is possible.
[17:31] <zyga> jkridner: the low level stuff is probably identical to the serial boot
[17:31] <zyga> jkridner: at least it was on panda
[17:31] <jkridner> either way, agreed something has to happen fast.
[17:31] <zyga> jkridner: AFAIR
[17:31] <jkridner> zyga: this is a different bootloader. :(
[17:32] <zyga> (at least TI pulled out of APs so that won't be a problem :P)
[17:32] <zyga> I would worry about all the allwiner, mediatek and whatever boards
[17:33] <jkridner> k, my dd has finally started.
[17:33] <rcn-ee> jkridner, bmap! ;)
[17:33] <rcn-ee> real	2m23.500s
[17:36] <zyga> plars: I think we need to stay on top of this
[17:36] <zyga> plars: the a-b-r model is perfect for our needs
[17:36] <zyga> plars: for certification and automation
[17:36] <zyga> plars: and we should mandate that
[17:36] <zyga> plars: and get it into stone
[17:36]  * jkridner wishes http://www.amazon.com/Mikrotik-5VUSB-power-injector-USB/dp/B00D84L5IQ would cut power when USB power was cut.
[17:36] <plars> zyga: indeed, I just learned about it after asking if it was a possibility this morning. I'm hoping that sergiusens will keep me in the loop :)
[17:36] <zyga> plars: I think he mentioned that ...
[17:37] <zyga> someone
[17:37] <zyga> I cannot find it now
[17:43] <zyga> http://linux-sunxi.org/FEL/USBBoot
[17:43] <zyga> allwinner is good for remote booting
[17:45] <jkridner> rcn-ee, zyga: here's what I want: http://www.eeweb.com/blog/extreme_circuits/usb-power-injector-for-external-hard-drives
[17:46] <jkridner> hmmm... http://www.altronics.com.au/p/k2910-usb-power-injector-kit/
[17:48] <plars> jkridner: these shut down the port completely when you remove the external power source?
[17:49] <jkridner> they shut off power to the port when the upstream power goes away.
[17:49] <jkridner> this way, I can inject one of these every 2-3 boards when power starts to run low and still use BeagleBone's ability to cut power to the USB port to control power to the downstream board.
[17:50] <jkridner> this makes it easy for people to reproduce the test setup in a one-off condition, without buying any special hardware....
[17:50] <jkridner> and still allows me to scale up to as many boards as I want to test.
[17:50] <plars> oh, so you are chaining these together?
[17:50] <jkridner> yes.
[17:50] <plars> interesting
[17:50] <jkridner> i have about 40-50 capes to test.
[17:50] <jkridner> so, I will use a BeagleBone-per-cape.
[17:51] <plars> but what does chaining them together do for you?
[17:51] <jkridner> I really don't want to get a whole mess of expensive power switches.
[17:51] <plars> ah, I see
[17:51] <jkridner> saves me on Ethernet cables, switches, etc.
[17:51] <plars> but if you have problems with an upstream one, that risks taking down everything downstream from it right?
[17:51] <jkridner> yeah, first failure brings down the rest of the chain.
[17:52] <jkridner> so, we'll only know about the first failure...
[17:52]  * plars suddenly has flashbacks of christmas lights
[17:52] <jkridner> then have to fix it before we can test down the line.
[17:52] <jkridner> but, we'll know exactly where the failure is.
[17:52] <plars> true
[17:54] <jkridner> rcn-ee: I'll switch back over to #beagle for more follow-up. Was just thinking for a second there might have been some overlap in what zyga was asking.
[18:23] <stgraber> jdstrand: so say I wanted to make the lxd snap official with the next LXD release (on Tuesday), what would you need from a security point of view to make it acceptable for the store?
[18:23] <stgraber> jdstrand: I can't really give you any seccomp filtering since we need to be able to set our own (and in fact do by default). But I can do something similar to the lxc-start profile and so restrict the lxd process itself.
[18:23] <stgraber> jdstrand: with the understanding that this profile does allow change_profile, so it's of limited value
[18:24] <stgraber> jdstrand: I'd also need to know how to ship extra apparmor profiles as we'll need the usual set of LXC profiles and abstractions in there (currently my hack is to run everything unconfined in userns only, but I'd like to have apparmor support there if possible)
[18:26] <jdstrand> stgraber: I don't think there is anything we can really do for confining lxd itself-- it needs the permissions it needs. however, are you shipping framework-policy for apps to consume?
[18:27] <jdstrand> stgraber: that said, what we did for docker is have a quite lenient policy that I will say 'encourages' honoring the snappy fhs. ie, normal usage under the profile wouldn't allow writing into app directories
[18:28] <jdstrand> stgraber: abviously, 'encourages' because with change_profile, you can hop out of confinement
[18:29] <jdstrand> stgraber: is lxd creating/using apparmor profiles that are named a particular way? eg, we can limit what lxd can change_profile to (but, since these are system containers, that policy is going to be wide open anyway), but it would encourage that it is doing the right thing
[18:32] <stgraber> jdstrand: so we usually ship profiles named lxc-* and that's what we allow in the lxc-start profile
[18:32] <stgraber> jdstrand: however we also do allow unconfined
[18:33] <stgraber> jdstrand: so in effect you can switch to whatever profile you want, or none at all
[18:33] <jdstrand> alright, so bare change_profile
[18:33] <jdstrand> stgraber: what about framework-policy?
[18:33] <jdstrand> are you shipping policy for apps that depend on your framework to consume?
[18:34] <stgraber> jdstrand: not at this point, but we probably should. The only thing we'd have to allow is communication with our unix socket.
[18:34] <jdstrand> so, for tuesday, ok good
[18:34] <jdstrand> stgraber: however, is that unix socket give you full range over lxd? ie, can it handle untrasted, malicious apps?
[18:35] <jdstrand> untrusted*
[18:35] <jdstrand> ie, are you assuming the process connecting to it is trusted?
[18:35] <jdstrand> (eg, an admin on the system)
[18:36] <stgraber> yeah, so I'm not sure about that part yet, we may want to only let apps talk to the tcp socket and not allow communication with the unix socket except for the local shell itself
[18:36] <stgraber> because indeed, having access to the unix socket, lets you reasonably easily escalate to root
[18:36] <stgraber> as you can create containers, execute command in them, change their configuration (including apparmor profile, bind-mounts and turn off userns)
[18:37] <jdstrand> right
[18:37] <stgraber> over the tcp socket, you have to be trusted by using a ssl client certificate which the user has to add to LXD (or provide the client with a password so they can do it themselves)
[18:37] <jdstrand> stgraber: what you expose in framework-policy needs to prevent that. right now, docker is doing that wrong and it needs to be fixed
[18:38] <stgraber> ok, so specifically deny all access to the framework path and data path in the profile?
[18:38] <jdstrand> it sounds like the tcp socket allows everything if the cert verifies?
[18:38] <stgraber> right, protocol is identical but the tcp socket requires SSL auth
[18:38] <jdstrand> stgraber: well, today, you don't have to do anything. apps are already blocked from your socket
[18:39] <jdstrand> stgraber: it is just that when you want to say something like 'We should allow app-store apps to add a container' that things get interesting
[18:39] <stgraber> ok, so not even providing a framework policy would be fine for now
[18:39] <jdstrand> you would probably want a reduced api or something. ie, don't want to allow a malicious app to escalate via lxd
[18:39] <jdstrand> stgraber: yes, exactly
[18:40] <stgraber> we define tcp/8443 as an external port, so presumably apps can talk to this already if they want to and if they have been specifically allowed by the local administrator
[18:40] <jdstrand> stgraber: right, that would all work
[18:40] <jdstrand> and that is fine
[18:40] <stgraber> ok, I think the only question I still have is how do I ship additional raw apparmor profiles
[18:40] <jdstrand> I'm talking about the cool integration stuff people will want to do
[18:41] <jdstrand> like, I'm going to upload this 'app' to the store that will talk to lxd to create a container for me and run stuff
[18:41] <jdstrand> for now, everything is fine
[18:41] <jdstrand> to support that use case, then need to have something that can deal with untrusted users
[18:42] <jdstrand> users, apps, etc, etc
[18:42] <stgraber> so I expect the initial use case to be people using snappy+lxd as a sort of compute node, so install lxd on it, then drive it remotely, using regular LXD images from a LXD image store.
[18:42] <jdstrand> but, thumbs up for no framework-policy and uploading on tuesday
[18:44] <stgraber> jdstrand: ok and how do I ship and get apparmor to load, extra apparmor profiles? Do I need to call apparmor_parser and the usual stuff manually from my startup script?
[18:44] <jdstrand> stgraber: yes
[18:45] <jdstrand> let me get you a link to the docker policy
[18:45] <stgraber> ok
[18:46] <jdstrand> http://bazaar.launchpad.net/~snappy-dev/snappy-hub/docker/files/head:/package-dir/meta/
[18:46] <jdstrand> http://bazaar.launchpad.net/~snappy-dev/snappy-hub/docker/view/head:/package-dir/meta/docker-daemon.apparmor
[18:46] <jdstrand> line 109 should give you a head start
[18:46] <jdstrand> oh but you are unconfined
[18:47] <jdstrand> yeah, you are probably fine. if you go the 'encourage fhs' route, see that ^
[18:47] <stgraber> ok, will look at those, thanks!
[18:48] <jdstrand> np :)
[18:50] <stgraber> I vaguely remember running into troubles manually loading our apparmor profiles in the past, but I'll bug you when I get the error message again :)
[18:50] <barry> mvo: whenever you see this, si 3.0.1 is landing in wily right now
[18:52] <jjohansen> stgraber: it could be that for manual load you need to make sure its a single atomic write
[19:12] <Chipaca> plars: about ssh, i see a sshd running so i presume not
[19:13] <sergiusens> plars: Chipaca check if the host keys were generated
[19:18] <Chipaca> sergiusens: yes, they're there
[19:18] <Chipaca> sergiusens: this was after an upgrade, so i would've hoped so anyway :)
[19:30] <bschaefer> hello, so has there been any work or issues someone has ran into getting a session dbus daemon setup?
[19:38] <tedg> bschaefer, That's not really as much a snappy thing as something that would be implemented by a framework on top. Like Unity8.
[19:38] <tedg> bschaefer, So that's probably handled in the Ubuntu Personal image that is being worked on.
[19:38] <bschaefer> but in a sense we want a bare bone system that runs qml/sdk apps... we'll need a dbus session for that
[19:38] <rsalveti> elopio: yeah, I'm waking up at 6am now (done for 4 days already, big win)
[19:38] <tedg> bschaefer, I'm not sure what state it is in, but it should get to the point of a desktop, which needs a session manager.
[19:39] <bschaefer> tedg, right... is there a simple way to hack a session dbus daemon to start up :)?
[19:39] <tedg> bschaefer, That's a different problem. If it is dependent on system services (i.e. dbus services) it'll need to those to exist in frameworks.
[19:39] <rsalveti> sergiusens: plars: we're going to discuss next week (iom sprint) about the factory image/reset and so on
[19:39] <rsalveti> check the requirements and such we have from other projects, and then try to identify the path we want to take
[19:40] <bschaefer> tedg, i see, yeah that'll have to be looked at...
[19:40] <plars> rsalveti: awesome!
[19:40] <rsalveti> then we can just implement it :-)
[19:40] <bregma> bschaefer, Snappy Personal is using LightDM right now, so it works like the regular desktop in that respect
[19:40] <tedg> bschaefer, So I think that your best bet is to use the personal image today. It should do that for you.
[19:40] <bschaefer> tedg, bregma sweet, thanks! Ill have to find this personal image...
[19:40] <bregma> tedg, we can't use the personal image, that's the whole point
[19:40] <bschaefer> but this will be an issue on arhmf
[19:42] <tedg> bregma, Why not?
[19:42] <bregma> bschaefer, shouldn;t be (any more of) a problem on armhf
[19:42] <bschaefer> bregma, true...i suppose the main issue being getting a bare bone system to run what we need
[19:42] <bschaefer> would be more of the issue here vs a full fledge desktop
[19:42] <bregma> tedg, because we're trying to raise the red-headed bastard stepchild of Snappy Core and Snappy Personal
[19:43] <tedg> bregma, I'm confused, who let them date?
[19:43] <bregma> they kept digging a hole under the fence
[19:45] <tedg> bregma, So what are you trying to build, I'm confused. A snappy core that installs an app that runs in the session?
[19:46] <bregma> tedg, pretty much: a Snappy Core that runs a dedicated GUI-based app, probably in a session because root, well, because root
[19:46] <bregma> no Unity 8, no general-purpose user shell
[19:46] <olli> mterry_, are you around
[19:46] <bschaefer> nothing, just mir + sdk + qml/qt app
[19:46] <mterry_> olli, sure am
[19:46] <tedg> bregma, So I think that kgunn has an app that does that
[19:46] <bschaefer> tedg, its missing the SDK
[19:47] <tedg> I don't think it's running the sdk parts though.
[19:47] <bschaefer> (which requires the session dbus i guess)
[19:47] <bschaefer> yeah
[19:47] <tedg> Yes, the SDK won't really work without the services that it needs behind it.
[19:47] <bschaefer> thats what im working on :)
[19:47] <bregma> tedg, kgunn has a team putting it together.....
[19:47] <olli> mterry_, gto a couple of qmlscene questions/issues, want to do here or in /query?
[19:47] <tedg> So either you have those services (Ubuntu Personal) or you don't (Ubuntu Core)
[19:47] <mterry_> olli, either works
[19:47] <mterry_> olli, there's already a convo here
[19:48] <tedg> I mean if you just want it to error and say "services not found" you could just use dbus-test-runner
[19:48] <bregma> we'll shut up
[19:48] <bschaefer> tedg, i mean...there has to be a way to run a dbus session...or figure out if the SDK *needs* it
[19:48]  * bschaefer be quites
[19:48] <tedg> And that'll wrap it in a session bus, it just won't have the services to make things work.
[19:49] <bschaefer> tedg, cool ill try the test runner...no clue how it works but something will happen :)
[19:49] <bschaefer> thanks!
[19:49] <olli> mterry_, gathering some information, brt
[19:50] <olli> wasn't there a pastebinit on the core image?
[19:50] <tedg> bschaefer, I think it comes down to your desired behavior, if you just want a dummy session bus that's easy. If you need all the services, I think you'll want Ubuntu Personal.
[19:50] <bschaefer> im not sure what the services are
[19:50] <bschaefer> like...talking with unity8? Then i dont need them
[19:51] <bschaefer> or if its talking with the net, then ill need it
[19:51] <tedg> bschaefer, Yes, all the trusted services that are part of a standard unity8 session. Content hub, URL dispatcher, etc, etc
[19:51]  * bschaefer isn't 100% sure what dbus is used for in unity8/sdk
[19:51] <bschaefer> URL dispatcher could be an issue for say, weather
[19:51] <bschaefer> if thats what i think the url dispatcher does... the weather app will fail
[19:51] <tedg> bschaefer, Those features are built into the SDK, so when the SDK has a feature to say "share" it knows how to talk to content hub.
[19:52] <bschaefer> tedg, but requires dbus :) (to work)
[19:52] <tedg> bschaefer, It's just "requires dbus" it is "requires content hub and dbus and configuration" basically "requires a Unity 8 user session".
[19:52] <tedg> DBus is the easiest part of that
[19:53] <bschaefer> tedg, sooo the weather app does not expect to work outside of a unity8 session?
[19:53] <bschaefer> unless a dbus/content hub are all configured correctly?
[19:53] <tedg> bschaefer, I would say no, but it might work for some cases.
[19:53] <bschaefer> out side of the session?
[19:53] <tedg> The SDK is designed to work in a Unity8 session.
[19:53] <bschaefer> tedg, well that'll be the fun part i suppose :)
[19:54] <tedg> Doesn't mean you couldn't use some of the widgets successfully. But it's going to be touch-and-go.
[19:54] <bschaefer> right
[19:54] <tedg> bschaefer, So if you need a Unity8 session, that's what Ubuntu Personal is.
[19:54] <bschaefer> we could attempt to make a new content hub wrapper..
[19:54]  * bregma doesn't like the phrase "touch and go" it sounds like it needs gesture recognition first
[19:54] <bschaefer> tedg, ... well i dont think we *can*
[19:55] <bschaefer> if we want a bare bone kiosk system image
[19:55] <bschaefer> we dont want a unity8 shell session
[19:55] <tedg> You still want to swap out Unity8 for another Mir Server.
[19:55] <tedg> I guess you could use the system compositor.
[19:56] <tedg> But you'll need to avoid the widgets in the SDK that do integration stuff.
[19:56] <tedg> So a "standard app" won't work. That doesn't mean a custom app won't work.
[19:56] <bschaefer> so the system compositor would start up the session but wont do anything kind of unity8 stuff
[19:56] <tedg> No, the system compositor doesn't start a session.
[19:56] <bschaefer> it just starts the server?
[19:57] <tedg> Yes, it just provides a socket that gets routed to HW.
[19:57] <bschaefer> tedg, soo we'll need to figure out what parts of the SDK are off limits
[19:57] <bschaefer> in a sense...
[19:58] <bschaefer> but guessing that a button depends on dbus ... i would assume almost all of the SDK depends on it
[19:58] <tedg> Yeah, you should be fine with buttons and the such, but "smarter" widgets will fail.
[19:58] <tedg> The base application class tries to init dbus.
[19:58] <tedg> So for that you can just do a dbus-test-runner wrap
[19:58] <bschaefer> right cool, ill give that try for now
[19:58] <tedg> It'll init and be happy.
[19:58] <bschaefer> soo pretty much a clock should work
[19:58] <bschaefer> tedg, awesome thanks for all the info! (was missing a pretty bug chunk there)
[19:58] <tedg> Maybe, it sets alarms and such in EDS
[19:59] <tedg> So not the standard clock we ship, but a custom clock would.
[19:59] <bschaefer> hmm
[19:59] <bregma> bschaefer, were you using the Mir demo server?
[19:59] <bschaefer> this will have to be discussed a bit more
[19:59] <bschaefer> bregma, yeah
[19:59] <bregma> ah
[19:59] <bschaefer> bregma, but i have dbus session on my main machine
[19:59] <bschaefer> (which still works
[19:59] <bschaefer> )
[19:59] <bschaefer> on the snappy image the mir demo server fails with the SDK
[20:00] <tedg> Basically if it is an app that we ship on the phone, it probably uses session services as we've fleshed a bunch of those out with those apps :-)
[20:00] <bregma> yeah, there is no argument we'll need a session D-Bus
[20:00] <bschaefer> yeah
[20:00] <bschaefer> some how...
[20:00] <bregma> and all the fun frameworks like content hub
[20:01] <bschaefer> yeah :(
[20:01] <tedg> Do you need content hub?
[20:01] <bregma> tedg, content hub is magically going to appear as a snappy framework
[20:01] <tedg> I mean, it is a pretty advanced interaction.
[20:01] <tedg> bregma, Not anytime soon. 1+ years atleast.
[20:01] <bregma> so if an application snap needs it, it will just add it in its manifest
[20:01] <bregma> and it will all just work
[20:02] <tedg> It's unclear whether content-hub will be it's own framework or we'll just have a mega-Unity8 framework.
[20:02]  * bregma is waving his hands in a "not my job" fashion
[20:02] <bschaefer> haha
[20:02] <tedg> (which would include content-hub)
[20:03] <bregma> we'll worry about niceties like content hub if and when we get paid to worry about that
[20:04]  * tedg saves his loonies
[20:04] <bregma> right now I just need to turn my BBB or Raspi2 into a clock so I can tell the time
[20:04] <kgunn> improvement from paperweight
[20:05]  * bregma needs a nixie tube driver for the BBB
[20:05] <bschaefer> haha
[20:05] <bschaefer> how easy is it to get chrome working on mir?
[20:05] <bschaefer> pretty easy? Try to get netflix working haha...
[20:06] <tedg> Mir → XMir → Chrome
[20:06] <bschaefer> haha, i thought racarr had chrome working directly on mir
[20:06] <bschaefer> maybe that was a long time ago
[20:18] <rickspencer3> Chipaca, https://code.launchpad.net/go-service-template
[20:19] <rickspencer3> ParseDuration turned out to be really useful
[20:19] <rickspencer3> thanks for your help earlier
[20:23] <kgunn> bschaefer: that was ozone-mir, and yeah you could get chrome on mir, chad miller took that over, i know it requires active updates
[20:23] <kgunn> bschaefer: i'm pretty sure willcooke mentioned it was being actively worked too
[20:23] <bschaefer> kgunn, would be interesting to see that on a beaglebone or a raspi
[20:23] <bschaefer> with netflix
[20:24] <kgunn> :)
[20:24] <bschaefer> kgunn, thats just my out side of work want atm haha
[20:26] <olli> not sure if the drm blob is available on arm
[20:28] <bschaefer> :( yeah
[20:29] <olli> kgunn, may I distract you
[20:29] <kgunn> olli: yo
[20:32] <olli> kgunn, nevermind for now
[20:32] <olli> mterry_, ^
[20:32] <mterry_> olli, hah
[20:32] <mterry_> olli, what was the question?
[20:33] <olli> where to export the mir socket env var
[20:33] <mterry_> olli, --mir does that for you
[20:33] <mterry_> olli, did you export LC_ALL=C.UTF-8?
[20:33] <olli> mterry_, I did
[20:33] <mterry_> olli, you will get a socket error if you don't
[20:33] <mterry_> oh huh
[20:34] <mterry_> olli, in your bin/digitalsign that deb2snap put in for you, do you see a mir-run script being used?
[20:34] <mterry_> It should be inserted on your behalf
[20:35] <olli> yep, it's there
[20:41] <Chipaca> rickspencer3: what editor do you use?
[20:42] <olli> kgunn, I got mir running as a process but no socket in /run
[20:42] <olli> from a mir snap that I created from your blog
[20:42] <olli> any thoughts?
[20:44] <kgunn> olli: you're lauching with the "server" script
[20:44] <kgunn> ?
[20:45] <kgunn> olli: you see the black mouse cursor  in the vm ?
[20:45] <olli> kgunn, actually I don't
[20:45] <olli> I have not actively started mir in the vm
[20:45] <olli> I used deb2snap --mir
[20:46] <kgunn> olli: so you didn't build through make ? but did the deb2snap command line ?
[20:46] <olli> kgunn, I built mir.snap as per your blog
[20:47] <olli> kgunn, upon reboot, I have the process running but no socket
[20:47] <kgunn> olli: ok, so you branched lp:~mir-team/mir/snappy-packaging and did make
[20:47] <kgunn> olli: what's the process name running ?
[20:47] <olli> 721 ?        Ss     0:00 /bin/sh /apps/mir/snap1/bin/server.real
[20:47] <kgunn> olli: ok, that's just the script trying to launch it
[20:48] <olli> got a "good" mir.snap lying around?
[20:48] <kgunn> actually :)
[20:49] <kgunn> olli: this should be good
[20:49] <kgunn> https://drive.google.com/a/canonical.com/file/d/0B4GvOYxwuvpFeHVxN0t5UFpua3c/view?usp=sharing
[20:50] <kgunn> olli:  just curious when did you pull and update that branch ?
[20:50] <olli> ~Mo
[20:50] <olli> maybe Tue
[20:50] <olli> kgunn, with your snap I see the same process running
[20:51] <kgunn> ok...there was a moment where i had it confined....
[20:51] <olli> and ... with your .snap I also don't have a /run/*mir* socket
[20:51] <kgunn> olli: what bzr commit are you on ?
[20:51] <kgunn> ok...lemme replicate
[20:51] <olli> I am on your .snap
[20:51]  * kgunn can almost do it in sleep
[20:51] <olli> :)
[20:52] <olli> kgunn, do I need to start the vm differently?
[20:53] <kgunn> olli: did you get any erros when you installed VMM and loaded a vm into it?
[20:53] <kgunn> i do recall getting an odd error, reboot fixed it
[20:53] <kgunn> upon installing VMM and first use
[20:54] <olli> hah
[20:54] <olli> I was using kvm cli
[20:55] <kgunn> olli: ah, yeah, VMM has some gfx voodoo in it
[20:56] <kgunn> vmware also has nice gfx voodoo i believe
[20:56] <olli> yeah
[20:56] <olli> betcha there is no GFX card in my vm ;)
[20:56] <olli> face.palm
[20:57]  * kgunn halts replicant effort
[20:57] <kgunn> and changes dirtied britches
[20:58] <olli> at least we ahve established a POC of gg drive as archive replacement
[20:58] <kgunn> lol
[20:58] <kgunn> olli: call it "kg's store"
[20:58] <olli> beuno, ^
[20:59] <beuno> free store for kgunn?
[21:09] <olli> kgunn, and now we are in business
[21:09] <olli> mterry_, ^
[21:10] <mterry_> olli, yay
[21:10] <mterry_> olli, you see a pretty qml app now?
[21:10] <olli> I see mir
[21:10] <olli> babysteps
[21:12] <olli> mterry_, close
[21:13] <olli> I see a lot of qt modules I am missing
[21:13] <olli> mterry_, I guess that's some additional -p magic for deb2snap
[21:13] <olli> i.e. install/bundle the modules via -p $Mymodule
[21:14]  * olli wanders off for today
[21:14] <olli> will play with it tonight
[21:14] <olli> think I can figure it from here
[21:14] <olli> thx guys!
[21:19] <rickspencer3> Chipaca, gedit
[21:19] <Chipaca> ah
[21:19] <Chipaca> mterry_: you didn't find a good gofmt plugin for gedit in the end?
[21:21] <mterry_> olli, oh yeah, deb2snap doesn't know enough to search your qml files for imports and match them up to debs
[21:21] <mterry_> olli, that would be magic!
[21:21] <mterry_> Chipaca, oh naw didn't try super hard, but no I didn't
[21:22] <Chipaca> k
[21:22] <Chipaca> rickspencer3: you know 'gofmt'?
[21:22] <rickspencer3> Chipaca, nope
[21:22] <sergiusens> gofmt is THE thing!
[21:22] <Chipaca> rickspencer3: check you've got it in your path
[21:23] <rickspencer3> cool
[21:23] <Chipaca> rickspencer3: and then, in the source tree, find -type f -name \*.go -print0 | xargs -0 gofmt -w
[21:23] <Chipaca> rickspencer3: and look at the resulting diff
[21:23] <rickspencer3> Chipaca, ok, I'll check it out tomorrow
[21:24] <rickspencer3> trying to eod here :)
[21:24] <Chipaca> fair :)
[21:26] <rickspencer3> Chipaca, thanks for the tips, though
[21:26] <rickspencer3> Chipaca, what did you think of my code?
[21:26] <rickspencer3> other than the formatting?
[21:27] <Chipaca> only looked at main.go
[21:27] <Chipaca> not bad though