[06:36] <dholbach> good morning
[06:58] <clobrano> good morning all
[07:28] <fgimenez> good morning
[08:03] <ogra_> mvo, the resize script logs to /run/initramfs/resize-writable.log
[08:07] <mvo> ogra_: right, I don't get a shell when this happens. is there a way to make it dump the log on the screen or the serial port?
[08:07] <ogra_> hmm, no
[08:07] <mvo> ok, not important right now, its a bit of a courner case that partition in the middle of the disk disappear
[08:08] <ogra_> (i mean, beyond hacking the script indeed)
[08:08] <ogra_> thats on a GPT system i assume ?
[08:25] <Chipaca> mvo: mo'in!
[08:25] <Chipaca> mvo: wrt "autovivifying", is it the word you didn't know of, or the concept?
[08:35] <mvo> hey Chipaca - a word I did not know of
[08:35] <Chipaca> ah :)
[08:36] <Chipaca> i blame perl
[08:36] <mvo> indeed
[08:41] <ogra_> poor perl
[08:55] <JamesTait> Good morning all; happy Wednesday, and happy Back To The Future Day! 🙌 The future is now!
[08:55] <ogra_> not only now ... it is TODAY !
[08:59] <Chipaca> everybody's going on about hoverboards, and all i want is climate control
[09:00]  * Chipaca tweets it
[09:00] <ogra_> you could team up and do climate controlled hoverboards though
[09:03] <Chipaca> sell hoverboards to londoners, with a note saying they only actually hover when it's dry
[09:03] <Chipaca> rake in millions
[09:03] <Chipaca> actually be selling roof tiles
[09:09] <morphis> anybody had time to have a look at https://bugs.launchpad.net/snappy/+bug/1501638?
[09:12] <morphis> with that we see also https://bugs.launchpad.net/snappy/+bug/1452848
[09:14] <morphis> joc_: ^^
[09:17] <dpm> davidcalle, morning!
[09:17] <dpm> davidcalle, do you have everything you need to start with the snappy docs IA work?
[09:17] <davidcalle> dpm o/
[09:17] <davidcalle> dpm, yep
[09:19] <dpm> davidcalle, excellent, thanks
[09:21] <asac> ogra_: mvo: anything i need to do on milestone creation still?
[09:25] <ogra_> asac, not really
[09:25] <ogra_> and welcome back daddy !
[09:26] <Chipaca> morphis: do you have steps to reproduce bug 1452848?
[09:26] <morphis> Chipaca: yes
[09:27] <Chipaca> morphis: could you add them to the bug please?
[09:27] <morphis> yes
[09:28] <morphis> joc_: does https://bugs.launchpad.net/snappy/+bug/1452848/comments/4 apply to what you did to end up with that bug?
[09:29] <morphis> Chipaca: what about https://bugs.launchpad.net/snappy/+bug/1501638 ?
[09:31] <joc_> morphis: yes sounds about right
[09:31] <morphis> good
[09:32] <Chipaca> morphis: i haven't looked
[09:35] <Chipaca> morphis: can you put the generated snap somewhere? I don't have vivid.
[09:37] <ogra_> mvo, i uploaded an initramfs-tool-ubuntu-core to the PPA that will print all resize output to the console if "debug" is set on the kernel cmdline
[09:37] <ogra_> (next image should have it)
[09:38] <Chipaca> morphis: I'm not seeing that, here
[09:38] <Chipaca> morphis: what are you running it on?
[09:39] <morphis> Chipaca: joc_ saw it
[09:41] <Chipaca> joc_: what are you running it on?
[10:09] <miken> dholbach: Hi there! mvo says you're the person to chat with about getting a click-reviewers-tools branch landed? I've got this MP which intended to just add a new test which *didn't* use any mocks, but ended up refactoring the test base class to get rid of a small test isolation issue. More details on the MP if you've time: https://code.launchpad.net/~michael.nelson/click-reviewers-tools/add-test-without-mocks/+merge/274509
[10:28] <asac> ogra2: thx :)
[10:39] <dholbach> miken, I'll have a chat with jdstrand about landing it later on
[10:43] <miken> Great, thanks dholbach
[13:12] <Chipaca> fgimenez: which is the image that doesn't bring up eth on first boot in kvm?
[13:13] <fgimenez> Chipaca, 15.04/edge from 212 at least, 209 was good
[13:42] <dholbach> jdstrand, are https://code.launchpad.net/click-reviewers-tools/+activereviews MPs you want to give an extra thorough review yourself or are you fine with maybe pindonga and myself reviewing them?
[13:53] <dholbach> sergiusens, tedg: shall we do a clinic at UOS?
[14:00] <tedg> sergiusens: Does that make sense? I thought UOS was for planning?
[14:00] <sergiusens> tedg, uos has evolved
[14:01]  * tedg can't keep track of what the kids are doing these days
[14:16] <jdstrand> dholbach: they all either have issues I need to comment on or need a thorough review
[14:16] <dholbach> ok
[14:16] <dholbach> thanks jdstrand
[14:17] <dholbach> miken, mvo, shawnwang: ^
[14:17] <mvo> wuuut, issue :P ?
[14:18] <mvo> my branch has no issues
[14:18] <dholbach> mvo, typos maybe :-P
[14:18] <mvo> lol
[14:18]  * dholbach hugs mvo
[14:33] <dholbach> tedg, sergiusens: so yeah, there's planning and there's "show & tell" sessions
[14:34] <dholbach> I think at UOS we're going to get some additional eyeballs
[14:45] <ogra_> crap
[14:45] <ogra_> seems snappy update on the rpi is not so happy
[15:12] <Chipaca> pitti: you got a bit?
[15:15] <ogra_> or a byte :)
[15:21] <mvo> pitti: hi, can I ask silly systemd questions again? so I have a snappy system (wily) here that tells me startup has finished but I get no getty on tty1, only on 2-6. should I be concerned?
[15:38] <cmk> any1 get snappy GUI on snappy desktop to work?
[15:40] <ogra_> cmk, i think tedg did a QML app on top of Mir once
[15:40] <ogra_> and no. desktop is still a bit away
[15:41] <tedg> Yeah, but that wasn't snappy desktop.
[15:41] <tedg> Just snappy core.
[15:41] <ogra_> well, it was a snappy GUI :)
[15:41] <ogra_> (app)
[15:42] <ogra_> ppisati, hmm ... i just accidentially flashed a rpi image that still had 3.19 ... ran snappy upgrade which worked fine, but after reboot i end up with: http://paste.ubuntu.com/12886195/
[15:42] <ogra_> doesnt even uncompress 4.2
[15:43] <ppisati> ogra_: 99% you have to update the dtb
[15:43] <cmk> k thx
[15:43] <ogra_> ppisati, hrm
[15:44] <ogra_> thats tricky since the dtb doesnt actually liuve in the device tarball but in the oem (bootloader) snap
[15:44] <ogra_> also then we wouldnt be able to roll back
[15:45] <ogra_> mvo, sergiusens ^^^ thats a problem
[15:45] <ogra_> (nothing we need to tackle today but the RPi HW reqs wont work with the current snappy design as soon as we get a major bump of the kernel)
[15:46] <ppisati> ogra_: don't we handle the rollback via the a/b thing?
[15:46] <ogra_> and thanks to vfat i cant just use a link to the a or b dtb
[15:46] <ogra_> ppisati, yes, after the blob loaded the dtb
[15:46] <ppisati> ogra_: and since a/b doesn't work in rpi2 due to the bcm bootloader
[15:47] <ogra_> a b works fine
[15:47] <ogra_> this is why we have uboot
[15:47] <ogra_> it handles all that
[15:47] <ogra_> but the blob loads the dtb before we load uboot
[15:47] <ogra_> and it doesnt load it from a or b either but from /boot
[15:47] <ppisati> ogra_: right, so my point was that we hanlded going back and forth using two different kernels/initrd/dtb
[15:48] <ogra_> not on the Pi
[15:48] <ppisati> right
[15:48] <ogra_> because the dtb is loaded by the blob
[15:48] <ppisati> since we use the bcm bootloader
[15:48] <ogra_> yeah
[15:48] <ppisati> so that feature is broken there
[15:48] <ogra_> which isnt acceptable for a fully supported snappy arch
[15:49] <ogra_> rollback needs to work
[15:49]  * ogra_ sighs
[15:50] <ogra_> the blob also doesnt knwo if we boot a or b ... because the logic for that happens later
[15:52] <tedg> vmayoral: Trying to think about how we explain better the whole deb vs. snap thing on the mailing list. Here's my thought dump as a graphic, thoughts?  https://usercontent.irccloud-cdn.com/file/26hwfJt2/deb-vs-snap
[15:54] <vmayoral> hi tedg, that's good one
[15:54] <vmayoral> tedg: in a general way, that's what Snappy (AFAIK) is doing
[15:55] <ogra_> ppisati, oh ! ignore me, thats probably a red herring ... i just see it installed the -generic kernel during the upgrade :P
[15:56] <vmayoral> tedg: ROS-wise, there's the  issue of "extending" a robot's behavior based on other snaps. I've been doing a bit of thinking on that but haven't been able to come up with anything solid but a few hacks
[15:56] <vmayoral> tedg: will keep thinking though :)
[15:56] <ogra_> so the hard hang at uncompressing  definitely comes from that
[15:56] <ogra_> (wont fix the dtb issue indeed)
[15:56] <vmayoral> tedg: thanks for clarifying the OSRF claim btw, appreciate that.
[15:59] <tedg> vmayoral: Cool, no problem, sorry I misspoke originally.
[15:59] <vmayoral> tedg: I'm interested about your thoughts on the snappy environment for ROS
[15:59] <tedg> Overally I'm worried people are mis-understanding Snappy and so we're not communicating.
[16:00] <tedg> Overall
[16:00] <tedg> Feel like we need some new language there.
[16:01] <tedg> vmayoral: For ROS I'm kinda leaning towards thinking about ROS2 and keeping ROS1 contained in a snap. Which we can then support for ROS2 (i.e. bundle the bridge)
[16:03] <vmayoral> tedg: that'll be sweet and pretty smart. ROS 2 is still on its infancy but it'll take over really soon and will define the next 10 years of robotics
[16:03] <vmayoral> (that's my personal thinking at least)
[16:04] <vmayoral> tedg: my feeling is that there're some things that quite don't fully match, how do you see the following scenario: "Erle-Spider is delivered based on Snappy with a single snap containing roscore and our ROS packages. A developer in Japan wants to create a visual odometry snap and make money out of it. How can he do it without hacking the snap released by us?"
[16:05] <tedg> vmayoral: I'll start by saying I'm relatively new to ROS :-)
[16:05] <tedg> vmayoral: But it seems to me that's basically the problem ROS2 is trying to solve.
[16:05] <tedg> vmayoral: In that in ROS1 you need all kinds of access and assumptions about the underlying system to do that.
[16:06] <tedg> vmayoral: Where ROS2 seems to think about associations and connection points between robots, which could be internally as well.
[16:07] <vmayoral> tedg: i'd say the same applies to RO2. ROS 2 replaces the communication layer by DDS and adopts a standard but several problems still will apply with the snappy aproach
[16:07] <vmayoral> let me put it this way:
[16:09] <vmayoral> tedg: "Erle-Spider is delivered based on Snappy with a single snap containing roscore and our ROS packages to make it move around. In a later stage, Erle Robotics deliver a 'visual_odometry' snap that provides odometry information to developers exposed in a new ROS node. A developer in Japan wants to create an app with Erle-Spider an for that he wants to use visual the odometry snap released by Erle Robotics."
[16:09] <vmayoral> How do you see this happening?
[16:10] <ogra_> your odometry data would have to be exposed on a (domain|network) socket ... from where he picks it up
[16:10] <vmayoral> ogra_: but since snaps can't depend on snaps, there should be a way to enforce it, shouldn't it?
[16:11] <tedg> vmayoral: So I think that there will have to be some amount of frameworks, and frameworks are going to have to know something about the applications that use them.
[16:11] <vmayoral> ogra_: i mean, right, UDP comms should be allowed between snaps, but dependencies aren't AFAIK.
[16:11] <ogra_> right
[16:11] <tedg> vmayoral: For instance, an app on the desktop needs to install and setup its icon. Same idea.
[16:12] <tedg> vmayoral: There'll be a certain amount of "handshaking," declarative of course, between the two.
[16:19] <vmayoral> tedg: mmm well that convinces a bit. Not sure, i'd like to do more thinking about it
[16:19] <vmayoral> what seems clear to me are the benefits of adopting Snappy on a final (commercial) product.
[16:19] <vmayoral> The fact that you guys deal with security is actually a great complement to the lack of it in ROS
[16:27] <tedg> Yes, I was a little shocked by that when I started researching how ROS works :-)
[16:28] <ogra_> well, dont blame ROS
[16:28] <ogra_> after all this is how *all* embedded development worked for the past 20-30 years
[16:29] <ogra_> (which is why it is so easy to hack into nuclear power plants or industrial controllers today :P )
[16:36] <tedg> Let's not talk about that, I want to sleep tonight :-)
[16:37] <ogra_> haha
[16:44] <ogra_> http://themcphails.uk/snappy.jpg
[16:47] <kgunn> tedg: ok, back to our discussion yday, configflags is supported by cmake....so i'd suppose i type something like snapcraft build Boost_DIR=./parts/mir-demo-server/install/usr/lib/x86_64-linux-gnu/
[16:47] <kgunn> just checking incantation syntax
[16:47] <kgunn> what would it be
[16:47] <tedg> kgunn: No, no, a field in the snapcraft.yaml
[16:48] <tedg> kgunn: plugin: cmake\nconfigflags:\n-Boost_DIR=./parts/mir-demo-server/install/usr/lib/x86_64-linux-gnu/
[16:48] <tedg> kgunn: (whitespace left as an exercise for the reader)
[16:48] <kgunn> tedg: lol @whitespace
[16:48] <kgunn> thanks
[16:53] <kgunn> tedg: so i added like so  https://pastebin.canonical.com/142330/ but got a
[16:53] <kgunn> Issues while validating snapcraft.yaml: mapping values are not allowed here on line 18 of snapcraft.yaml
[16:53] <kgunn> so possibly failed your whitespace quiz :)
[16:53] <tedg> kgunn: Yes, you did :-)
[16:54] <ogra_> heh
[16:54] <tedg> kgunn: Two spaces away from configflags.
[16:54] <ogra_> and you thought python was insane, eh ?
[16:55] <tedg> Yeah, I find writing YAML so error prone. I really don't like it most of the time.
[16:55] <ogra_> well, json isnt that much better
[16:55] <kgunn> tedg: 2 spaces away from configflags ? sorry...more context?
[16:55] <ogra_> unless you have a properly highlightingv editor that shows the matching bracket .... and a gigantically big screen
[16:57] <tedg> kgunn: http://pastebin.ubuntu.com/12886920/
[16:57] <tedg> ogra_: Being able to use '%' in VIM helps me there.
[16:57] <kgunn> tedg: damn it! :)
[16:57] <ogra_> yep
[16:57] <tedg> Though, I have a gigantically big screen too ;-)
[16:58] <ogra_> i only have three vertically small ones
[16:58] <ogra_> which doesnt exactly help with that issue
[17:09] <pitti> mvo: "systemctl status -l getty@tty1.service"?
[17:54] <lool> sergiusens: do you have a recent example of custom plugin?
[17:55] <lool> sergiusens: I've put x_custom.py under parts/plugins, but it's not finding the custom_cmd option in self.options at runtime
[18:01] <mvo> pitti: many thanks, I think I found the underlying issue, has to do with writable-paths
[18:19] <sergiusens> lool, look at the last snappy clinic
[18:19] <sergiusens> :-)
[18:19] <sergiusens> lool, name the module x_custom.py but call it plugin: custom
[18:19] <lool> sergiusens: I figured the schema thing out
[18:19] <sergiusens> lool, show me your plugin
[18:20] <lool> sergiusens: I  needed a schema
[18:20] <sergiusens> lool, ah, there we go
[18:20] <sergiusens> lool, yeah
[18:20] <lool> I took it from the autotools plugin
[18:20] <sergiusens> lool, the base plugin is a lot more simple in 0.4 btw
[18:20] <sergiusens> lool, http://bazaar.launchpad.net/~snappy-dev/snapcraft/core/view/head:/snapcraft/__init__.py
[20:23] <sergiusens> elopio, https://code.launchpad.net/~sergiusens/snapcraft/1481122/+merge/275237 mind looking at that?
[21:20] <jdstrand> Chipaca: hey, fyi, I had some time today to look at the click-apparmor removal. I decided to go with the go rewrite in the same pass since it occurred to my that cranking up the python interpreter twice (once for apparmor and once per seccomp) was going to really stink on arm
[21:20] <jdstrand> twice per app within the snap
[21:21] <jdstrand> that was not going to be nice
[21:22] <jdstrand> Chipaca: so, I have some code, nowhere near ready for merging, that actually generates apparmor and seccomp policy for security-template/caps and security-policy
[21:24] <jdstrand> Chipaca: but when I'm done, .click/ will be gone, the .json files will be gone, aa policy will move to /var/lib/snappy, and in general everything is going to be clean and nice
[21:25] <jdstrand> like how seccomp is now. but even that is going to be better cause we won't use sc-filtergen any more and the policy generation logic will have a clean internal api
[21:25] <Chipaca> jdstrand: yaaay!
[21:25] <jdstrand> so snappy install is cleaned up too
[21:25] <Chipaca> jdstrand: i needed this news :)
[21:25] <Chipaca> not because i was this desperate for click-apparmor removal
[21:25] <Chipaca> but because it's been a long, sucky day
[21:25] <Chipaca> and this is good :)
[21:25] <jdstrand> :(
[21:26] <jdstrand> glad I could give you some good news
[21:26] <jdstrand> it is going to take quite a bit of work for me to get everything in order, but I have a plan and even some code that is doing good things
[21:27] <jdstrand> so, hopefully in a couple weeks I'll have something to review
[21:28] <jdstrand> Chipaca: oh, and the weird security-override is going to be revamped
[21:28] <jdstrand> Chipaca: you won't specify a json file any more. you'll express the overrides directly in the package.yaml
[21:28] <jdstrand> eg:
[21:28] <Chipaca> jdstrand: that sounds nice
[21:28] <jdstrand> binaries:
[21:28] <jdstrand>   foo:
[21:28] <jdstrand>     security-override:
[21:29] <jdstrand>       apparmor:
[21:29] <jdstrand>         read-paths: [ /foo, /bar ]
[21:29] <jdstrand> that sort of thing
[21:29] <jdstrand> so it is all going to be nice and clean :)
[21:29] <Chipaca> excellent
[21:30] <jdstrand> security-override has been bugging me for a while
[21:30] <jdstrand> well, really, all of it has
[21:30] <jdstrand> anyhoo
[21:30] <jdstrand> :)
[21:30] <Chipaca> :)
[21:30] <Chipaca> thanks
[21:31] <Chipaca> ogra_: elopio: so, wrt 15.04 edge not bringing up eth0, i have a fix
[21:31] <Chipaca> ogra_: elopio: https://code.launchpad.net/~chipaca/snappy/firstboot-ordering/+merge/275244
[21:31] <Chipaca> ogra_: elopio: but that's not the whole story
[21:31] <Chipaca> we also need to tweak cloud-init's service file
[21:32] <Chipaca> ogra_: that's where i think you come in? (not sure) (i know you just luuurve cloud-init)
[21:32] <Chipaca> i'll comment on that mp so it isn't lost
[21:32] <Chipaca> and then zz
[21:51] <cmk> hi
[21:52] <cmk> ogra are you online?
[21:56] <lool> sergiusens, beuno: what's the quickest way to download a snap from the public store?
[21:59] <Chipaca> lool: do you know the package name?
[22:00] <Chipaca> lool: if you do, then, https://search.apps.ubuntu.com/api/v1/package/hello-world.canonical
[22:00] <Chipaca> lool: and look for anon_download_url
[22:00] <lool> Chipaca: yup
[22:01] <Chipaca> lool: GET $( GET https://search.apps.ubuntu.com/api/v1/package/mir.mvp-demo | jq -r .anon_download_url )
[22:01] <Chipaca> lool: for example
[22:01] <lool> Chipaca: thanks
[22:02] <Chipaca> lool: not a long-term solution as anon downloads should go away at some point
[22:04] <manik> Chipaca: there's no URL to download from at the hello-world link
[22:04] <manik> it just begins downloading directly
[22:04] <Chipaca> manik: sorry, what?
[22:05] <cmk> anon_download_url: "https://public.apps.ubuntu.com/anon/download/canonical/hello-world.canonical/hello-world.canonical_1.0.18_all.snap",
[22:05] <manik> Chipaca: my bad, found it
[22:05] <Chipaca> k. g'night.
[22:07] <cmk> on ubuntu core 14.04 edge... i can see a cursor, but the screen is black
[22:07] <cmk> *snappy ubuntu core
[22:07] <cmk> suggestions?