#ubuntu-uos-core 2015-11-02
* You're now known as ubuntulog2
<Pici> .
#ubuntu-uos-core 2015-11-03
* ChanServ changed the topic of #ubuntu-uos-core to: Currently no events are active in this room - http://summit.ubuntu.com/uos-1511/core/ - http://irclogs.ubuntu.com/2015/11/03/%23ubuntu-uos-core.html
<genii> Is there someplace a comprehensive UOS schedule or itinerary?
<TJ-> http://summit.ubuntu.com
<dholbach> genii, http://summit.ubuntu.com/uos-1511/ - and for today that's http://summit.ubuntu.com/uos-1511/2015-11-03/
<dholbach> genii, if you log into summit and "star" sessions, you can even have your own schedule
<genii> dholbach: Excellent, thanks!
<TJ-> dholbach: do we have any IRC location for resolving issues? I found that Firefox 41.0.2 on 15.10 couldn't show the Plenary video from Youtube, despite HTML5/Video enabled
<dholbach> that's weird
<dholbach> #ubuntu-uos is the general UOS channel
<TJ-> Hmmm, I'll try that then. I couldn't find out what the encoding was when it reported it wasn't supported, which didn't really help diagnosis
<TJ-> What is weird is, it plays now it isn't live
* ChanServ changed the topic of #ubuntu-uos-core to: Track: Core | Creating more Snappy frameworks | Url: http://summit.ubuntu.com/uos-1511/meeting/22596/core-1511-new-snappy-frameworks/
<dholbach> hey hey... frameworks session coming up in a bit
<dholbach> ping me if you want to contribute to and join the session
<dholbach> as the other snappy session started a bit late, I guess we can wait for more snappy folks to turn up here
<dholbach> we'll start shortly
<dholbach> anyone else here who wants to join the conversation about frameworks?
<dholbach> ^ (and come on to the video feed?)
<lool> dholbach: who's leading the session?
<dholbach> lool, mvo and I are there
<dholbach> can you all join as well?
<dholbach> happy to share the link
<lool> I will join in a couple minutes
<lool> dholbach: what's the link?
<dholbach> lool, https://plus.google.com/hangouts/_/hoaevent/AP36tYfTPVxSDasP04fkgsxqqZjoaFtPsUX-CGILTyRwImLH6MtzNQ
<kyrofa> Does mir count since it's only available on amd64?
<dholbach> kyrofa, ah yes - I'll note that down
<dholbach> noting down things on http://pad.ubuntu.com/uos-1511-core-1511-new-snappy-frameworks
<dholbach> if you have questions or suggestions, please bring them up
<tedg> kyrofa: It's still a framework, even if it's not on all archs :-)
<tedg> I think it's important to note that an individual snap could do its own overlay internally.
<tedg> So each framework/snap developer can choose how she wants to handle the issue.
<tedg> Doing something universally don't seem to make as much sense as letting a framework make its own choices.
<asac_online> think overlayfs was 3.18 iirc
<asac_online> overlayfs could be made an opt in feature that prevents snaps from isntalling on systems that do not have that CAPABILITY
<tedg> Frameworks could make their own preload bin for the snap as well.
<tedg> That is scary universally, but doing it for a specific case isn't as big of worry.
<asac_online> however, core frameworks that should enable our ecosystem shouldnt rely on that :)
<asac_online> i dont like moving baseline to 3.18 for all systems. its nice, but then there will always be neat new things in latest kernels. if we can combine such features with capabilities it might work, but then we fragment the app ecosystem
<asac_online> lool: mvo: ^
<lool> I wish you were on the ho to say it  :-)
<asac_online> still believe for key things we should just invest and make them relocatable
<asac_online> :)
<tedg> I think that is generally just additions to the service declaration.
<tedg> I don't think it's as much a dependency issue, as much as, if you give people access how the lifecycle of your processes are done.
<asac_online> you express with capabilities :)
<Chipaca> doesn't 3.18 already leave odroid out?
<asac_online> 3.18 leaves many things out
<Chipaca> k
<ogra_> yeah :(((
<asac_online> i think overlayfs should be an option
<asac_online> but not for the main framewroks
<ogra_> if we want to support phones ever we need to support 3.10
<asac_online> sure
<asac_online> but phone vertical doesnt necessarily have that problem
<kyrofa> ogra_, and that's only arale
<asac_online> the apps are already relocatable
<ogra_> kyrofa, really ? you know what kind of weird BSP kernels future devices will have ?
<ogra_> :P
<kyrofa> ogra_, I mean krillin and vegetahd are even older, haha
<ogra_> yeah
<ogra_> but for them there are lollipop trees, i would assume they also have newer kernels we could use
<diwic> I'm here and I heard the word "PulseAudio"
<dobey> what kerenel are we using on mako?
<diwic> :-)
<ogra_> dobey, i think thats also 3.10
<ogra_> not sure though ... apt could tell you, it is in the archive ;)
<diwic> But I don't quite follow enough of difference between frameworks and snaps and inter-framework dependencies and whatnot
<dobey> 3.4.0-7-mako
<diwic> to know what to do if I should do something
<dobey> 3.4 apparently :)
<dobey> uname -r tells me that anyway
<Chipaca> diwic: there are no inter-fwk deps
<kyrofa> dobey, 3.4
<kyrofa> dobey, mako, krillin and vegetahd are all 3.4, arale is 3.10
<diwic> Chipaca, but if we have one bluetooth framework and one audio framework, how can we get bluetooth audio?
<tedg> User switching, sessions.
<Chipaca> diwic: presumably, if they're built that way, you could have those frameworks cooperate, as long as they don't depend on eachother
<diwic> Chipaca, actually, that's a bad example because the audio framework can look if the bluez stuff is on d-bus and act accordingly
<tedg> I imagine there'll need to be a framework for switching which user is using the display, keyboard and mouse.
<Chipaca> diwic: exactly
<tedg> And then if you have a user session, then which application is shown or managed.
<tedg> Basically lightdm and unity8.
<dobey> we should probably update the mako kernel to the newer version
<tedg> But we'll need to be more than just that project.
<dobey> if we can
<niemeyer_> I think eventually we'll have dependencies between snaps, and potentially frameworks, via the capability system
<niemeyer_> B
<niemeyer_> But it's still a bit early for details on that
<kyrofa> dobey, not sure who's decision that is. But yeah, it's pretty old
<kyrofa> dobey, it's our reference kernel, though. I'm not sure mako can be updated without the others
<dobey> kyrofa: we should update the others too. :)
<tedg> Not sure how we can exactly handle the case of not having the framework, but having a soft dependency. As the framework installs the security configuration for accessing it, but it is built and install time. So I guess we'll need to make those much more dynamic if we want to be able to support that.
<morphis> dobey, kyrofa: we can't update any of those
<morphis> without spending a lot of time getting them running again
<diwic> Another question is Gstreamer - is that a framework or snap? And what does it depend on w r t audio/video frameworks etc?
<morphis> they are heavily customized kernels for products
<tedg> diwic: Generally, it should be a library included by the app. The hard part there is the HW enabled plugins.
<diwic> tedg, hmm
<diwic> tedg, same goes for qtmultimedia then? Also included by the app?
<tedg> diwic: Correct
<kyrofa> diwic, snapcraft should help you there
<tedg> Nothing is a framework, except the things that are :-)
<tedg> lool: The problem is that there are some specific GStreamer programs for DSPs. i.e. optimized MPEG 4
<lool> good point
 * diwic tries to google for "snapcraft" and finds that top 5 results for "snapcraft" are all minecraft related 
<dholbach> developer.ubuntu.com/snappy/build-apps
<dholbach> or snapcraft on github
<tedg> https://github.com/ubuntu-core/snapcraft
<niemeyer__> Frameworks are a big gun.. they can do anything.. I feel like people are curious to what is the proper way to integrate or design a framework, and the honest true unfortunately is that it depends
 * tedg has that link ready for later ;-)
<kyrofa> diwic, heh, always prepend your Google's regarding snappy with "ubuntu"
<niemeyer__> honest truth
<diwic> thanks
<alecu> QUESTION: is OpenGL a framework, or should it be considered a dependency?
<niemeyer__> The video stream is breaking down often for me.. is it just me?
<asac_online> video is good here
<alecu> niemeyer__: I can see it ok here
<dholbach> niemeyer__, for me it's been fine all the time
<niemeyer__> Ok, thanks
<tedg> niemeyer__: I think that generally, we need to provide some design guidelines at least for the main cases. Otherwise we'll continually have the same discussions.
<niemeyer__> tedg: It's really hard to have design guidelines for this, because in general frameworks mediate access to resources which tend to be very different in nature
<tedg> Clearly every rule has some exceptions, but we can't expect good things to happen without some guides.
<lool> https://developer.ubuntu.com/en/snappy/guides/frameworks/
<diwic> I think that if we have like 10-15 examples of what is a framework and what is a snap, that should give people a gut feeling for what something is
<tedg> +1 dholbach
<niemeyer__> alecu: OpenGL is the API.. not a good framework by itself..
<lool> https://code.launchpad.net/~snappy-dev/snappy-hub/snappy-examples
<Chipaca> lool: the dbus fwk example isn't there, fwiw
<tedg> Seems like something we need to prioritize.
<lool> Chipaca: oh no
<alecu> niemeyer__: so, should I ship client side libraries for OpenGL in my snap? I ask because client side OpenGL libraries usually depend on each specific hardware
<Chipaca> there's a framework-template though
<lool> Chipaca: isn't that http://bazaar.launchpad.net/~snappy-dev/snappy-hub/snappy-examples/files/head:/hello-dbus/package-dir-fwk/ ?
<Chipaca> also, they're also on github: https://github.com/ubuntu-core/snappy-testdata
<diwic> Chipaca, that's a more interesting one. Can we get bluetooth framework without dbus framework?
<lool> Chipaca: it's dbus based AFAIK
<alecu> niemeyer__: and I'll need to use that from my QML apps
<Chipaca> alecu: we've got the same problem with mir
<asac_online> thx
<alecu> niemeyer__: anyway, this is the kind of things I'd like to discuss in the "Snaps for the Phone" session later today :-)
<Chipaca> alecu: where the client-side libraries depend on the server abi
<lool> Chipaca:    bus-name: "com.canonical.hello-dbus-fwk"
<Chipaca> alecu: no really good answer for that and opengl yet, however
<alecu> Chipaca: right
<Chipaca> alecu: (IOW: feedback needed!)
<tedg> Chipaca: Well hopefully that one can be solved with capabilities? Where you put the mir protocols you're capable of.
<lool> it's the example I had in mind, but you might know of nicer ones
<diwic> morphis, bluez is quite useless without d-bus, right?
<alecu> thanks all for the session! I need to catch up with the first half, since I had a conflicting meeting though :-)
* ChanServ changed the topic of #ubuntu-uos-core to: Currently no events are active in this room - http://summit.ubuntu.com/uos-1511/core/ - http://irclogs.ubuntu.com/2015/11/03/%23ubuntu-uos-core.html
<niemeyer__> alecu, Chipaca: Yes, indeed it's a good case to study.. part of it is definitely within a framework as there's sharing to be done (we don't want the GPU taken over by a single snap)
<Chipaca> ok, bye people
* ChanServ changed the topic of #ubuntu-uos-core to: Track: Core | Snap packages for phone and desktop apps  | Url: http://summit.ubuntu.com/uos-1511/meeting/22639/snap-packages-for-phone-and-desktop-apps/
<snappy_car> !seen skynet
<udsbotu> I have no seen command
<snappy_car> :(
<dholbach> if anyone of you wants join the conversation or the hangout, ping me and I'll give you the link to the hangout
<dholbach> if you have any questions, I can relay them
<snappy_car> QUESTION: when will the phones use snaps?
<dobey> as soon as there's enough feature parity in snaps to transition from clicks by default
<snappy_car> i see, thanks
<dobey> it'll be possible to install snaps before everything is switched over, and it'll be possible to install clicks for a bit after everything is switched over, i think
<snappy_car> can clicks and snaps coexist?
<tedg> So do you pull in the required dependencies when you convert the click to a snap?
<tedg> QUESTION: So do you pull in the required dependencies when you convert the click to a snap?
<snappy_car> omg you sust installed a click on the desktopm?
<snappy_car> OMG
<snappy_car> a snap
<snappy_car> so that snap is x86?
<snappy_car> right?
<nhaines> snappy_car: yes.
<nhaines> Although I think they can be fat, too.
<snappy_car> nice, now i need crackly
<nhaines> Actually, the calculator might be universal (QML + JS)
<nhaines> But if it's C++, it has to be cross-compiled.  :)
<snappy_car> right :D
<bobolopolis> Is Mir planned for ARM?
<kyrofa> snappy_car, it's a QML app, so cross-platform
<dobey> the plan is to switch the phone to snaps completely, so yes, the frameworks will have to be on ARM
<kyrofa> nhaines, ^^
<nhaines> bobolopolis: Mir's been running on ARM for 3 years and was released in a retail product in March.
<nhaines> I'm looking forward to Mir and Unity 8 on RPi2.  :D
<bobolopolis> I thought Kyle just said it wasn't on ARM, maybe I misunderstood
<dobey> snaps are still a little weird, because they don't have the distinction between all archs and multi-arch packages
<dobey> bobolopolis: the mir snap framework isn't on ARM yet
<dobey> which is what kyrofa was talking about
<bobolopolis> Ah, okay
<tedg> I think that, for example you want QML and Qt inside the snap.
<dobey> right
<dobey> i don't think so
<dobey> we don't want every gnome app to have the entire gnome stack in each app's snap, for example
<alecu> https://docs.google.com/document/d/1BqJr8de5rr6s0NGm6BEsM3Yc8FCyLODGnCDFp_Y0Mxs/edit?ts=5633d6d8#
<tedg> If you want to patch it, or choose a version, you need to do that at build time. Not install.
<snappy_car> i don't want Qt inside the snap, ewww
<dobey> having to include the full stack in every package is not reasonable
<alecu> https://docs.google.com/document/d/1xwHIt5FLjrNur59Kh7aMB4SNzPTpTyhy-tkPchTxT0k/edit?ts=5637c5ca#
<snappy_car> it's also silly
<lool> my understanding was that phone snaps would rely on the stack being available on the phone image; today we have a single Ubuntu Core OS image, but the phone image would have a different seed and would provide different base frameworks
<dobey> right, we need a solution to the binary incompatibility issues of frameworks too
<lool> it's not clear whether we'd actually rely on the OS snap to be identical between core and phone, and find a way to expose qt in the phone case, but clearly we can't duplicate the whole phone libs in each snap
<tedg> So we think that on the phone devs shouldn't get to choose the versions of all their deps? ;-)
<kyrofa> That first link ^^ will walk you through the demo I just gave
<dobey> tedg: they can already do that if they want
<tedg> i.e. you're just recreating the debian repository problem
<tedg> Then developers can build their own PyPi for Snaps!
<lool> tedg: they can still do so for other stacks, but the point is to integrate with the main phone stack; the difference in my eyes is that snappy Ubuntu Core is a blank sheet where you create the architecture of your platform on top of something thin
<lool> while Ubuntu for Phone is an opinonated view of what a phone image should be
<lool> with a standard set of permissions and frameworks and libraries and a SDK etc.
<tedg> I think that opinionated view is implemented in the gadget snap of the image.
<tedg> You still want it on the same core.
<ogra_> lool, any why cant we create "architecture of your platform on top of something thin" on the phone too ?
<lool> I'm not opposed to using a single OS image for core and phone images, it might be hard to achieve in the short term
<tedg> For instance, on the phone you could do A/B partitions of the kernel/OS then. And not have to for all the rest of the frameworks that are larger.
<cm-t> I followed the mycroft topic on mailling list, there were python3 and snappy package issue, including a package for the phone.  I i remember the anwser was to use an uconfinned .click for the while. what would be the target in the long therme (for python3  apps)
<ogra_> i would see the phone as ubuntu-core + ubuntu-phone-ui (framework)
<lool> ogra_: we *can* but it's not desirable due to the stupid size and embedded bug copies it creates
<lool> it's the same story as shipping an embedded interpreter for each snap
<lool> it makes sense in snappy Ubuntu Core because it's meant to be thin and nude
<tedg> We can make an SDK snapcraft plugin that handles it easily enough.
<ogra_> why ? ubuntu-phone-ui provides the ubuntu framework
<ogra_> it is essentially everything we have on the phone today minus ubuntu-core :)
<lool> but a product like a QML phone image with an opinionated view on how all apps should look like, should behave, which services they might access etc. should commonize the commonalities  :-)
<tedg> lool: That's where concepts like intra-package deduplication comes into play. So it appears small on the disk, but each snap appears complete.
<niemeyer__> Yes, ideally we'd use exactly the same OS snap, which by itself is also built as a subset from a standard Ubuntu image
<asac-phone> lool: what about a third party that wants to build something like a phone?
<lool> tedg: well, we don't have that I'm afraid
<lool> tedg: also, it still prevents fixing in a single place bugs that are part of your runtime
<niemeyer__> We can always fix it so that it remains a usable subset of both environments
<tedg> lool: We shouldn't break the Snappy architecture because we don't have it.
<asac-phone> our architecture should support building something like the phone ... otherwise its not clean yet
<ogra_> +1
<tedg> lool: Yes, single place is the problem. It's the Debian repo problem :-)
<lool> we don't want to be in charge of the whole opensource world today, but rather express which subset is maintained on a per product/image basis
<dobey> tedg: we shouldn't break phones, because snappy doesn't have what the phones currently do, either
 * ogra_ notes that asac-phone is very wasteful with irc nicks today 
<tedg> dobey: We're not shipping a Snappy phone today :-)
<lool> tedg: well precisely, we get to decide, product by product / image by image, where we draw the line between supported and unsupported
<lool> with a clear interface
<dobey> tedg: exactly because snappy isn't ready for phones
<tedg> dobey: Not saying it is, but it is a target :-)
<lool> for instance: "here's your scope API, write this bit in this language and bundle it as a snap in the store"
<dholbach> does anyone want to join the hangout?
<lool> same for QML apps
<dobey> *sigh*
<tedg> lool: No, developers get to decide. We don't.
<lool> tedg: well you describe something else
<lool> tedg: it's a "create your own phone platform with random opensource components" version of snappy
<lool> tedg: today, Ubuntu for phones is a toplevel product that we maintain with a vision of how the user experience should be like
<asac-phone> lool:so you say "create your own platform" is out of scope for snappy core?
<lool> tedg: what you describe would make sense if e.g. I wanted to allow taking a phone and turn it into a kiosk or a drone or whatever
<tedg> No, not a platform. But what libraries your application uses are very different. If I get Digia to produce a Qt patch for me, I should be able to ship with it.
<lool> asac-phone: it's not, but it's not the same goal
<dobey> tedg: there's nothing preventing you from doing that
<lool> for me, Ubuntu for phones is [ OS snap + phone frameworks + Ubuntu snaps + 3rd party snaps ]
<dobey> tedg: but just because your special case is special, doesn't mean all users and developers should have to suffer for every app
<lool> with a vision of what goes into OS snap / phone frameworks (I dont care how it's split)
<tedg> There is a difference between recreating everything and including the in-memory dependencies of the app in the snap.
<lool> but
<lool> you can still create your [ Ubuntu Core snap + random frameworks + other snaps ] platform if you care
<lool> it's a different exercize
<lool> say, you could ship a Plasma phone with [ Ubuntu Core snap + Plasma framework(s) + Plasma apps + 3rd party snaps ]
<lool> and that's a different border / split
<ogra_> lool, that sounds like what i imagine too
<lool> what's not good to deliver a good phone product is [ Ubuntu Core snap + random snaps embedding everything ]
<tedg> Sure, but if you say that the libraries exist outside of the snap you can no longer talk about testing your snap being the same way it gets deployed either.
<lool> even if you throw a random set of frameworks in there, the duplication and lack of clear SDK / user experience guidelines kills the product
<tedg> We want to create the consistency with great snapcraft plugins, not with framework snaps that share files.
<dobey> "we"
<lool> you want to be able to say things like "apps are allowed to work in the background and access this always available services / middleware"
<asac-phone> lool: sure :) ... making a platform is not done by just providig parts to incude in snaps :)
<lool> this why I dont see the *value* in embedding the runtime in snaps each time when the point of your opionated platform is precisely to say what's common and always there
<lool> it would have an unacceptable cost though
<lool> hence why I think we should not embed Qt/QML in Ubuntu for phones
<asac-phone> lool:ok didnt get that.. think we agree :)
<lool> but you're welcome to do it in your "MyKiosk" use case, running Ubuntu Core + yourkiosk snap
<asac-phone> lool:but do we have what it takes to do such opinionated platform on top of core?
<lool> asac-phone: we have the opinonated view already: it's the current phone design
<ogra_> we will need a single versioned dependency towards the framework
<ogra_> to make sure your snaps actually find the right env
<asac-phone> lool:you mean making a big personal OS snap?
<asac-phone> or is thre a new design based on core?
<ogra_> asac-phone, a framework on top of ubuntu-core
<lool> for instance, we could say "when using ubuntu-for-phone-framework, your snap should rely on qmlviewer to launch"
<ogra_> but yeah, i big snap
<lool> e.g. we could ship #!/bin/env qmlviewver <QML contents goes here> global files
<ogra_> s/i/a
<lool> or, nicer, some kind of snap hook to pickup your QML files/Qt files and expose them in the launcher
<lool> asac-phone: well there are multiple options on how we can approach the internal split
<lool> is it one big snap with all phone middlewares
<lool> or do we make each a framework
<lool> lots of possibilities; not sure which is best personally
<dobey> framework-15.04.snap
<tedg> lool: There is no qmlscene anymore they changed that in a version of Qt. Perhaps we could abstract which version of Qt is being used?
<lool> tedg: sure, this was just to illustrate the point
<dholbach> any more specific questions you'd like to see discussed?
<ogra_> while it would be much nicer to have many frameworks it will also lead to needing dependencies
<tedg> ubuntuqmlplayer, we could add a debian-alternatives implementation
<lool> tedg: perhaps it would ubuntu-for-phones-qml-launcher
<asac-phone> so the problem i have with one big snap is that our current guidelines say that all frameworksneed to be coinstallable... so that big framework would probably include pulse etc. and others couldnt ship their own pulse
<ogra_> asac-phone, on a phone, yes
<lool> guys, I'm sorry the IRC conversation diverged from the hangouts; I feel I've not paid enough attention to the hangout
<lool> sorry!
<asac-phone> hehe
<asac-phone> lool: guess sorry to the hangout crew :)
<dholbach> anything in specific you'd like to see discussed?
<dholbach> or an open question?
<tedg> I think that everything in the base user session needs to be a big snap.
<tedg> But that doesn't mean that apps need to share files with that.
<mvo> so any questions for the people in the hangout?
 * jdstrand just arrived-- were there any questions for me?
<tedg> jdstrand: Just action items, don't worry.
<jdstrand> heh
<lool> asac-phone: no strong opinion there; I'm not sure it's ok to have the requirements that all frameworks can be coinstalled
<jdstrand> I good at deferring those
<jdstrand> I'm*
<tedg> Heh, managers.
<lool> dholbach: I'm happy to join  :-)
<kyrofa> We'll hang here for any questions
<jdstrand> lool: did the definition of frameworks change?
<dholbach> lool, NOW... :)
<lool> jdstrand: it did not
<niemeyer__> Wrong button..
<lool> dholbach: sorry  :-)
<niemeyer__> alecu: Thanks for mediating it
<asac-phone> thanks!
<kyrofa> Yeah thanks alecu!
 * asac-phone dinner
<willcooke> thanks guys
<lool> alecu: <3
<alecu> thank you guys, and keep up the good work!
<alecu> I'm catching up with the backlog, and I noticed this:
<alecu> "16:19:15 <lool> while Ubuntu for Phone is an opinonated view of what a phone image should be"
<alecu> that sounds exactly like what we'd like
* ChanServ changed the topic of #ubuntu-uos-core to: Currently no events are active in this room - http://summit.ubuntu.com/uos-1511/core/ - http://irclogs.ubuntu.com/2015/11/03/%23ubuntu-uos-core.html
#ubuntu-uos-core 2015-11-04
* ChanServ changed the topic of #ubuntu-uos-core to: Currently no events are active in this room - http://summit.ubuntu.com/uos-1511/core/ - http://irclogs.ubuntu.com/2015/11/04/%23ubuntu-uos-core.html
<dholbach> slangasek, do you know who's running the node.js/libv8 session?
* ChanServ changed the topic of #ubuntu-uos-core to: Track: Core | node.js and libv8 for 16.04 | Url: http://summit.ubuntu.com/uos-1511/meeting/22590/nodejs-and-libv8-for-1604/
<dholbach> slangasek, ping?
<dholbach> alecu, do you maybe know who's running the next session?
<alecu> dholbach: it says "Created by: Matthias Klose"
<dholbach> ok... but he's not online
<dholbach> slangasek, ^
<dholbach> I can set the session up
<dholbach> but I'm not sure what to say.................
<ogra_> you could show a slideshow of nice V8 cars :P
<alecu> dholbach: I guess somebody from distro and the people in security team that are marked as attending the session need to be in that
<dholbach> setting it up now
<alecu> dholbach: I'm joining because we are using node.js and v8 for the new scope bindings.
<dholbach> ok, give me another sec or two
<tyhicks> can chrisccoulson and I join the hangout?
<dholbach> sure
<dholbach> https://plus.google.com/hangouts/_/hoaevent/AP36tYeYeH42x7l09uefcnXCEwsjsCdU5h69oxDhB-7mgeYodV05bA
<alecu> great
<slangasek> dholbach: sorry, was working on getting it set up; I'll join that one
<dholbach> we'll start in a minute
<dholbach> Notes are up here: http://pad.ubuntu.com/uos-1511-nodejs-and-libv8-for-1604
<marcustomlinson> yes node embeds v8 it does not depend on a shared v8
<marcustomlinson> we are embedding node into our own binary
<marcustomlinson> as it is not available in universe or main
<marcustomlinson> our executable embeds node and is shipped within a scope click
<marcustomlinson> we take on the responsibility of keeping the node we embed up to date
<marcustomlinson> we update node, we fix our internals, and our API/ABI to remain stable
<dholbach> marcustomlinson, if you want to join the hangout, let me know
<marcustomlinson> (sorry I have bronchitis, voice is broken)
<dholbach> ok, no worries
<dholbach> I relayed your comment
<marcustomlinson> yes, v8 code is litterally part of the node source tree
<marcustomlinson> https://github.com/nodejs/node/tree/master/deps/v8
<marcustomlinson> they pull it in statically, no dynamic linking
<tyhicks> get to feeling better, marcustomlinson :)
<marcustomlinson> tyhicks: will do
<marcustomlinson> :)
<dholbach> yeah, all the best!
<dholbach> doko, do you know if barry is running the next session?
<doko> dholbach, we will be both there, he created https://blueprints.launchpad.net/ubuntu/+spec/foundations-x-python3-only
<dholbach> ok... is anyone of you setting up and running the session?
<dholbach> https://wiki.ubuntu.com/UDS/Sessions
<dholbach> hey barry
<dholbach> are you setting up and running the session?
<barry> dholbach: hi
<dholbach> https://wiki.ubuntu.com/UDS/Sessions
<barry> yeah, i guess i should go to the other room now (we're sprinting
<dholbach> ok cool
<dholbach> let me know if you need help
<barry> dholbach: technically it's doko's session :)
* ChanServ changed the topic of #ubuntu-uos-core to: Track: Core | Python3 Only on the images | Url: http://summit.ubuntu.com/uos-1511/meeting/22568/python3-only-on-the-images/
<dholbach> ok...
<dholbach> I asked doko earlier
<dholbach> I wasn't quite sure who was running it
<slangasek> https://plus.google.com/hangouts/_/hoaevent/AP36tYdzlG929T3_3v8ifrDi3Hp2h0Tz8wZVRcdk07fcQA61nJdA6g?hl=en&authuser=0
<dholbach> I think the time of the session was set wrong
<dholbach> the video currently says 9:00:45
<slangasek> barry: ^^
<dholbach> but maybe it doesn't matter and you can just hit start and it'll just work
<slangasek> dholbach: hmmm I said 'starting now' :)
<dholbach> I don't know <3
<dholbach> oh ok
<dholbach> that's on http://summit.ubuntu.com/uos-1511/meeting/22568/python3-only-on-the-images/?
<dholbach> 8:59:50 now
<slangasek> dholbach: when creating the hangout
<slangasek> so anyway, I don't know
<dholbach> maybe just start the hangout and see if it works
<doko> https://bugs.launchpad.net/ubuntu/+bugs?field.tag=python3
<barry> https://blueprints.launchpad.net/ubuntu/+spec/foundations-x-python3-only
<dholbach> ok, seems to be working :)
<dholbach> yes
<dholbach> can hear you
<dholbach> go go go
<dholbach> :)
<dholbach> https://docs.google.com/spreadsheets/d/1PnPLZRM2hu7ucv1yuq7Fd5hjNw_DYupHIYZpoP4-xHk/edit?pli=1#gid=1918227221
<smadden_landscap> landscape-client-ui-install can be purged.  It is unsupported today
<slangasek> smadden_landscap: oh great :)
<slangasek> smadden_landscap: did you want to join us on the hangout, or are you just delivering the good news?
<smadden_landscap> sure, I'd like to join
<slangasek> smadden_landscap: //plus.google.com/hangouts/_/hoaevent/AP36tYdzlG929T3_3v8ifrDi3Hp2h0Tz8wZVRcdk07fcQA61nJdA6g?hl=en&authuser=0
<willcooke> Trevinho, any ideas on what Python2 is needed by U7?
<Trevinho> willcooke: it's needed by Autopilot, but not by unity itself I think
<Trevinho> let me check whether the unity script needs, it but  I don't think so
<Trevinho> or the migration scripts..
<barry> willcooke: tools/unity.cmake
<jrjrtgerg> the unity scope depends on software-center in my testing (or at least apt daemon)
<barry> willcooke: LP: #1512909
<barry> (there's a patch for that but it doesn't build yet for unrelated reasons i think)
<willcooke> Trevinho, ^^
<demmot> you can authenticate to the rnr server and or the store without using the ubuntu-sso-client fairly easily
<demmot> it's a few oauth calls
<demmot> unity scope applications gets its data from the software-center database though..
<willcooke> thanks demmot
<willcooke> seb128, I'll speak to robert_ancell about that ^^
<seb128> willcooke, k, thanks
<smoser> rdepends also shows python-apt
<Laney> hi
<Laney> yes I think that g-s uses xapian
<Laney> via libappstream
<Laney> you can see they are linked
<Laney> seb128: slangasek
<slangasek> Laney: thanks
<seb128> Laney, thanks
<dholbach> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=781913
<dholbach> ?
<doko> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=781913
<slangasek> barry, doko: we seem to have skipped over system-config-printer on the desktop?
<slangasek> sorry, my hangouts connection failed, so the broadcast will have been interrupted
<zyga> hey
<smoser> oh.. to come back to it.
<smoser> cloud images were free of python2.7
<zyga> about checkbox
<smoser> but not libpython2.7
<zyga> python2 is only needed by one test
<smoser> there was a vim bug /dep on libpython2.7
<zyga> we can drop that test from the desktop
<zyga> it's OpenCV related AFAIR
<seb128> https://bugs.launchpad.net/bugs/1512642
<willcooke> https://bugs.launchpad.net/ubuntu/+source/checkbox/+bug/1512641
<zyga> we can easily separate that as checkbox and the tests are separate packages
<willcooke> https://bugs.launchpad.net/ubuntu/+source/checkbox/+bug/1512642
<zyga> checkbox and plainbox are pure python3
<seb128> https://bugs.launchpad.net/bugs/1512641
<doko> smoser, we could just build vim with python3 bindings
<smoser> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=729924
<zyga> we requested the removal of the checkbox package to replace it with a new stack that uses SDK apis
<smoser> infinity had some comments on that (vim and python3)
<zyga> so please stay reassured that checkbox will by python3 clean :)
<barry> zyga: thanks
<zyga> :-)
<doko> https://bugs.launchpad.net/ubuntu/+source/libpeas/+bug/1440504
<yofel> Well, from a kubuntu side we can look at things ourselves, but we're also affected by stuff like apt-xapian-index or ubuntu-sso-client, so some coordination place would be nice
<dholbach> barry, there's delay
<smoser> (i've verified and updated etherpad. 15.10 server install with default ends up with only libpython2.7-*, and that is rdpended on only by vim)
<smoser>  http://paste.ubuntu.com/13102639/
<smoser> cloud image now has lxd -> lxc -> cloud-image-utils . and smoser will drop/fix cloud-image-utils need of python2
<jrjrtgerg> plan is to drop ubuntu software center really soon?
<yofel> nah, the bugs are probably enough
<yofel> we can just mark those as affecting it
<barry> yofel: cool thanks
<yofel> *affecting us
<jrjrtgerg> lubuntu bug - https://bugs.launchpad.net/ubuntu/+source/lubuntu-meta/+bug/1465313
<jrjrtgerg> samba and system-config-printer seem like the big ones that are cross flavor issues
<smoser> https://gist.github.com/smoser/8904199bb8f00a90dd04
<slangasek> are you familiar with this technique? http://paste.ubuntu.com/13102740/
<slangasek> (we may have talked about this before, smoser ?)
<smoser> i did see that.
<smoser> slangasek, yeah.
<smoser> its interesting.
<smoser> curtin has a solution too
* ChanServ changed the topic of #ubuntu-uos-core to: Currently no events are active in this room - http://summit.ubuntu.com/uos-1511/core/ - http://irclogs.ubuntu.com/2015/11/04/%23ubuntu-uos-core.html
<barry> >
* ChanServ changed the topic of #ubuntu-uos-core to: Track: Core | EFI Capsule Update and Fallback | Url: http://summit.ubuntu.com/uos-1511/meeting/22637/core-1511-efi-capsule-and-fallback/
<cyphermox> http://youtu.be/I4ci-GeJIQw
<cyphermox> ^ for anyone who wants to follow, we'll watch questions on IRC too of course
<cyphermox> who is here for this session
<cyphermox> ?
<slangasek> cyphermox: can we share the hangout url here too for anyone else who wants to join the discussion?
<cyphermox> yeah I was just grabbing that
<cyphermox> https://plus.google.com/hangouts/_/qmal77cb6ezen6vpzuovvs3lkua
<cyphermox> ^ the hangout URL
<cyphermox> I won't make it broadcast unless we aren't the only ones here for the session though
<slangasek> cmagina: hi, here to talk about capsule updates?
<ogra_> nespresso !
<cyphermox> ogra_: ?
<ogra_> (no, wait , different capsules)
<slangasek> heh, nespresso capsules
<ogra_> :)
<cyphermox> eep.
<TJ-> I'm here :) but not on hangouts/whatever
<cmagina> slangasek: curious about it :)
<pjones> cyphermox: turns out I can't watch it anyway due to some video compat problem :P
<slangasek> sorry this capsule is not signed with the right key
<cyphermox> alright, let's give it a go then
<ogra_> haha
<slangasek> pjones: shoulda run Ubuntu
<slangasek> ;)
<TJ-> Interested in this since I've had some experience with capsule updates - painful
<pjones> slangasek: oh yeah, that's probably the issue :P
<cyphermox> http://pad.ubuntu.com/uos-1511-core-1511-efi-capsule-and-fallback
<TJ-> I looked at the blueprint; i'd suggest the capsule path be /usr/share/uefi/capsule/ or similar, rather like /usr/share/misc/, rather than /opt/<vendor>/
<cyphermox> https://blueprints.launchpad.net/ubuntu/+spec/core-1511-efi-capsule-and-fallback
<cyphermox> https://blueprints.launchpad.net/ubuntu/+spec/foundations-w-uefi-capsule-update
<superm1> https://secure-lvfs.rhcloud.com/
<superm1> is the URL
<TJ-> Also, with the fwupdate tool, some easy-to-use mechanism to delegate the update work to a BIOS vendor's own tooling, such as H2O-FFT
<superm1> fwupd puts it the appstream data in /var/cache
<pjones> (also https://beta-lvfs.rhcloud.com/ may be more interesting)
<superm1> and of course http://www.fwupd.org/ being most interesting
<superm1> gnome-software
<superm1> has support for fwupd
<superm1> already
<superm1> once fwupd clears NEW in debian we were planning to enable it in Debian with gnome-software too
<superm1> the vendor specific tooling isn't supposed to be activated until UpdateCapsule() is called.  it's all a vendor specific implementation at that point
<cyphermox> TJ-: do you have more questions?
<cyphermox> quigley: and you?
<TJ-> Idea rather than question: Being able to preload a portable image with many capsules and use it on multiple systems should be a use-case to cover. Enterprises may not want to risk their users handling/invoking a firmware update, but have it done either remotely, by PXE boot image, or USB mass-storage
<superm1> mass storage is already supported
<superm1> fwupdmgr install blah.cab
<quigley> I don't see why that wouldn't just work
<cyphermox> you could already do that, as long as the device loads the efi binary for fwupdate
<pjones> TJ-: from an upstream perspective, we've been assuming the enterprise will have the ability to remotely schedule it without the user involved, but it still runs through the local userland software
<TJ-> Good. just didn't see anything specific mentioning it
<superm1> at least today most BIOS'es don't support PXE in UEFI mode
<superm1> you have to load a CSM
<pjones> (pxe booting it won't *quite* work yet; we need a local filesystem currently.  but it's on my todo without a lot more work to do on it.)
<cyphermox> but it can be done
<pjones> superm1: lots do support dhcp+tftp (as opposed to the bios "pxe" api), but yeah.
<cyphermox> oh right, because we look locally for the firmware images?
<pjones> cyphermox: right; right now we don't support network device paths
<cyphermox> yeah
<superm1> yeah, but that's also assuming a working network stack in the BIOS at that time too
<pjones> I have like 80% of that in my local tree from this friday.
<pjones> superm1: yes, it is.
<TJ-> The only thing that occurs to me, based on the Whiteboard... is there a Process: Option 0 = a check-script that looks up the system ID against available updates and lets the user know... which would lead to Options 1/2
<TJ-> in other words, prior to a download action by the user, to make them aware without them needing to initiate
<cyphermox> TJ-: right now you need to run fwupdmgr refresh to look for updates, it could be cronned
<cyphermox> but in the future we might want to get that done graphically/automatically some other way
<pjones> I think if you're using gnome-software it'll do that for you?
<cyphermox> ie. gnome-software that we mentioned earlier
<slangasek> well, and in fact if this is going to be using the appstream service and using gnome-software, there will need to be integration for that
 * pjones isn't really sure about that end of the stack
<slangasek> today we use a cronjob + update-notifier to display the status of update availability
<zyga> superm1: hey, I'm curious about pxe and uefi mode, why is that not supported?
<cyphermox> slangasek: it's not like we couldn't do what software updates do already, look every once in a while and ask the user ifthey want to apply the new updates
<slangasek> I don't know in the gnome-software world what polls for updates, but that would surely need to poll this service
<pjones> zyga: many firmwares don't support it, and those that do typically only recognize the addressing if they've been configured to boot via the network
<pjones> zyga: so even if they know about it, using the network to fetch the image without actually /booting/ from it won't work without a lot more code.
<cyphermox> right
<zyga> I see
<pjones> zyga: so basically because hardware vendors believe netboot is a value add and don't support it on their low-end machines.
<superm1> zyga: traditional PXE support as we all know and love comes from the CSM generally (legacy boot mode)
<superm1> UEFI netboot operates a bit differently in what you'll actually be booting
<zyga> I'm interested in using the UEFI network stack
<zyga> to do $stuff
<zyga> where stuff is related to replacing what I'm booting
<pjones> zyga: at the risk of being too helpful to ubuntu people, https://fedoraproject.org/wiki/QA:Testcase_UEFI_pxeboot :)
<pjones> except that was written for our hacked up grub 0.97 efi binary; substitute a grub.cfg for the obvious difference.
<zyga> pjones: interesting, I was thinking about something slightly different but I will check it out to lear more about it
<zyga> pjones: I was thinking about using the network stack to boot one or other local disk
<zyga> pjones: not about complete netboot
<TJ-> cron-job + update-notifier approach would be good especially for headless hardware, and to support non-gnome flavours
<superm1> TJ-: yeah a script around fwupdmgr refresh and grep fwupdmgr get-updates would be sufficient for that.  when you want to do an update it's just fwupdmgr update
<TJ-> longer-term, something like the debian/control Modaliases: might be useful too, to search archive packages using ubuntu-drivers
<pjones> TJ-: superm1: if either of you wanted to help with that in fwupd , a "give me esrt info for this system" and a "look up info for this arbitrary ESRT dataset" call would let you split that up pretty nicely...
<TJ-> Good to see the progress on this; seeing far too much firmware-bug induced user issues the past 12 months - that combined with ACPI firmware bugs
<superm1> it would be easier to teach ubuntu-drivers to parse appstream data in my opinion
<pjones> so you could connect to dbus with whatever remote agent you have and ask for details, and then grab stuff on a common server end.
<superm1> than to repackage all the data into dummy debian packages
<TJ-> superm1: right, just thinking about the common tool and how it currently works
<pjones> Well, write what you like.  I just hope we can avoid too much unneeded duplication of effort.
<superm1> Yeah agree
* ChanServ changed the topic of #ubuntu-uos-core to: Currently no events are active in this room - http://summit.ubuntu.com/uos-1511/core/ - http://irclogs.ubuntu.com/2015/11/04/%23ubuntu-uos-core.html
<h4ck3r> secureboot sign for ubuntu EFI
<h4ck3r> is there any method to implements signature for EFI with ubuntu EFI file?
#ubuntu-uos-core 2015-11-05
* ChanServ changed the topic of #ubuntu-uos-core to: Currently no events are active in this room - http://summit.ubuntu.com/uos-1511/core/ - http://irclogs.ubuntu.com/2015/11/05/%23ubuntu-uos-core.html
* ChanServ changed the topic of #ubuntu-uos-core to: Track: Core | Your feedback counts: the Snappy onboarding experience | Url: http://summit.ubuntu.com/uos-1511/meeting/22593/core-1511-snappy-onboarding-feedback/
<dholbach> does anyone of you want to join the hangout?
<dholbach> (starting in a minute or two)
<dholbach> ok... if you want to join the conversation later on, let me know
<elopio> o/
<dholbach> which experience have you had with snappy so far and what have you done with it?
<dholbach> it'd be great if you could join the hangout, so we could hear more about your thoughts
<dholbach> anyone?
<Thibautr> I have tried Snappy on Raspberry Pi, BeagleBone, VM, mainly trying initially to play with it and installing apps.
<sergiusens> dholbach, how do I join? or should I join?
<kyrofa> My biggest issue with the on-boarding process was that the documentation online was terribly out-of-date and I was pointed to the src to read ITS docs since they're more up-to-date
<Thibautr> https://plus.google.com/hangouts/_/hoaevent/AP36tYeI_Q90YrhaSHfFTnhJ0s6x6TqDm3zADvBsnxoBU1t5JqoerA
<Thibautr> this is the link to the hangout
<ogra_> yeah, sadly snappy is still moving very fast with things changing at times
<ogra_> and docs only being updated subsequently
<kyrofa> ogra_, and that's understandable, but it would be great to change the docs at the same pace
<kyrofa> Maybe it should be more automated
<dholbach> https://plus.google.com/hangouts/_/hoaevent/AP36tYeI_Q90YrhaSHfFTnhJ0s6x6TqDm3zADvBsnxoBU1t5JqoerA
<ogra_> there are attempst to do that by maintaining the docs inside the code
<dholbach> ^if you want to join
<ogra_> and by automatically aggregating them
<kyrofa> Ah, that would be great :)
<ogra_> it already happens for some documentation
<dholbach> kyrofa, which docs were out-of-date?
<elopio> what we are missing is an integration test for docs. If the test fails, the docs and the test need to be updated.
<dholbach> taking notes here: http://pad.ubuntu.com/uos-1511-core-1511-snappy-onboarding-feedback
<ali1234> i'm an ubuntu user but frankly snappy is so different and weird that it doesn't help at all
<dholbach> ali1234, what is confusing or bewildering?
<kyrofa> Is that... sergiusens??
<elopio> ali1234: tell us more about your use case.
<ogra_> ali1234, depends what you want to do :)
<kyrofa> He's alive!
<ogra_> kyrofa, he pretends to
<kyrofa> Hahaha
<ogra_> (in reality he is lying in bed and only driving that puppet on a stick that you see in the HO
<ogra_> )
<sergiusens> kyrofa, yes
<ali1234> elopio: i don't have a use case, i don't even know enough about snappy to know if it would be useful to me or not
<sergiusens> no, I am better :-)
<sergiusens> kyrofa, from tuesday, s/sick/ill/
<elopio> ali1234: try installing the lxd snap, and deploy a ubuntu wily container.
<ogra_> ali1234, did you take a look at snapcraft already ? (the "apt-get for github" as someone called it recently)
<ali1234> ogra_: i googled it about half an hour ago, all i found was stuff about minecraft
<ogra_> heh
<ogra_> i guess we need to do better with google scoring
<kyrofa> ali1234, I always suggest prepending your search with "ubuntu"
<Thibautr> Who's got a Raspberry Pi?
<ali1234> i do
<jrwren> I do
<sergiusens> Thibautr, i don't see your lower third :-)
<ogra_> ali1234, there are definitely a bunch of tutorials on youtube how to use it
<elopio> Thibautr: I like that. I want my rpi to be my kodi box.
<jrwren> elopio: openelec makes that very easy and awesome.
<alecu> I own several raspis, but only one is model 2
 * ogra_ wants his rpi to steer his heating and solar power system
<Thibautr> What would you like to use your Raspberry Pi for?
<elopio> I like my bbb better, but I want to use it to hack.
<ali1234> i use mine as a jtag debugger and i2c sniffer
<alecu> elopio: the advantage of the raspi over other boards is availability
<jrwren> garage door open detector/alarm
<alecu> elopio: it's much easier to get your hands on a raspi
<Thibautr> Who's using their Rpi2 on a daily basis?
<elopio> and I would like to replace the openwrt on my router with ubuntu.
<willcooke> Thibautr, I have a use case we could use
<jrwren> rpi2 - yes, daily - openelec/kodi
<elopio> no, not daily yet.
<jrwren> garage door open detector - unsure about power requirements and which sensors would be best. Little time.
<elopio> jrwren: how easy is to update your openelec?
<alecu> QUESTION: I'd love to use my raspi2 with snappy for my electromechanical games, but I need sound support. Are audio drivers supported already? Is that already using pulse or plain alsa?
<lool> wililupy: snap services run as root any way
<lool> err sorry willcooke
<ogra_> willcooke, on snappy you always run everything as root ...
<lool> willcooke: but you'll need to give access to /sys files to your snap
<ogra_> i mean your snap does
<lool> rick and jamie wrote stuff on this
<lool> ogra_: (commands run as the user who runs them though)
<ogra_> oh, right, but services dont
<ogra_> i can definitely include needed bits indeed
<ogra_> if there is anythin to include
<willcooke> Thibautr, https://github.com/8none1/thermostat
<willcooke> NO LAUGHING!
 * tedg can't stop laughing
<ogra_> giggling allowwed ?
<tedg> Why are their sunny icons? I thought you were in England?
<tedg> there
<ali1234> QUESTION: how will development look when the tools themselves are packaged in snaps?
<elopio> all code and no pep8 makes /me a dull boy :)
<jrwren> elopio: very easy. copy files into place and restart and the system updates itself.
<ogra_> ali1234, you will have a "classic" mode on snappy
<ogra_> ali1234, meanin you can install a developer snap that gets you a deb based container
<ali1234> i wanted to use snappy on my robot but it is built around the pi A+ so that was a none starter
<wililupy> I had an issue with snapcraft .3 where I built a snap and it would fail saying it couldn't find /dev/null, but it seems to be fixed in .4 I successfully built my snap last night.
<ogra_> in which you then can use snapcraft
<sergiusens> kyrofa, want to share anything ros and ubuntu core?
<ali1234> ogra_: so basically if i'm a developer i will not ever use snap packages myself?
<ogra_> you will use them as the end result
<ogra_> to run and test them
<ali1234> what if i only write development tools?
<ogra_> you might be able to roll your own classic mode for this and provide it in the store,
<kyrofa> sergiusens, I have no snappy+ROS experience to share, I'm afraid. I'd love to but I don't have any robotic hardware around here :(
<ali1234> say i write a tool like cmake
<sergiusens> wililupy, good to know, feel free to log any bugs or send email to snappy-app-devel@ or #snappy with any issues; blockers for adoption we look at solving quicker than others
<ali1234> do i have to bundle gcc and every other compiler ever into the biggest snap ever in order to make it work?
<ogra_> ali1234, then you will provide a snapcraft plugin for it and perhaps your own classic mode snap that includes it by default (or get it included into the existing one)
<ogra_> ali1234, for development you will likely simply not use snappy itself, it is rather a delivery thing, your development happens outside of the deployment (in a classic container, on a desktop etc)
<ali1234> ogra_: i thought the plan was to convert the desktop to snaps?
<ogra_> it is
<sergiusens> https://linuxcontainers.org/lxd/getting-started-cli/
<ogra_> and there you will also use a classic container to develop ;)
<ali1234> ogra_: i saw the session yesterday about legacy apps
<ogra_> yeah, classic mode is a bit more than that
<ali1234> libertine i think it's called?
<ogra_> libertine adds confinement to not confined apps
<ogra_> by wrapping a chroot or container
<ali1234> okay
<ogra_> classic gives youa complete dev env in a container
<ali1234> so if i have to always work inside a classic container to do anything, why should i care about snappy?
<ogra_> that enables you to have it spit out a snap you can immediately install on your desktop
<ogra_> because snappy is your base system
<ali1234> but i cant do anything with it without a classic container
<ogra_> if you want to install your produced binary you will have to generate a snap
<ali1234> so i might as well just install my software inside the container and use it that way
<ogra_> you can indeed :)
<ali1234> it seems like most of the software i write would not work in a snap
<wililupy> QUESTION: How do I get my snap to show the correct version instead of random letters? Does it not get this from the version: flag in the snapcraft.yaml?
<ogra_> but if you want to deliver it to others whats easier ? telling them "select this snap from the snap store on your PC" or "read and follow this howto to set up a container and install these 25 debs inside"
<dholbach> wililupy, that's if you use a side-loaded version
<Chipaca> wililupy: not when sideloading
<dholbach> if it comes from the store, it gets a proper version number
<Chipaca> dholbach: for now :)
<Chipaca> bah
<Chipaca> wililupy: the "for now" is because, what do you need the "proper" version number for?
<Chipaca> wililupy: often it's to hardcode the version in a path somewhere
<Chipaca> wililupy: and you shouldn't do that
<wililupy> It was for a demo, I just wanted to clean it up.
<ogra_> ali1234, right, if you only work on core build tools or some such you are definitely better off with debs ... but perhaps in contexxxt of a classic mode that already contains yoyur tools (and your preferred IDE and all libs your tools consume etc)
<ogra_> so you might want a snap to make it easier for other devs to make use of your tool
<ogra_> ali1234, and you want snappy for your OS because a release to release upgrade will take 2min vs 2h, it will automatically roll back in case somethin went wrong etc etc
<Chipaca> wililupy: to support rapid dev iterations where you change something, rebuild, install, repeatedly on the device _without having to bump the version every time_, the version when sideloaded is ~random
<Chipaca> it's actually a timestamp, but same thing
<wililupy> Thank you all for the information.
<dholbach> mvo_, sergiusens, Chipaca: do you have an answer for alecu and his audio framework? :)
<Chipaca> i missed the question
<alecu>  QUESTION: I'd love to use my raspi2 with snappy for my electromechanical games, but I need sound support. Are audio drivers supported already? Is that already using pulse or plain alsa?
<dholbach> or ogra^
<Chipaca> ah!
<Chipaca> alecu: just plain alsa should work
<alecu> great!
<Chipaca> alecu: as long as it's a single snap wanting to use sound
<Chipaca> alecu: and you do the hw-assign dance, i imagine (try it and tell us :)
<alecu> Chipaca: yes, that sounds perfect
<ali1234> ogra_: my concern is that i'll end up with a huge amount of stuff installed manually in classic mode, and upgrading the base OS won't magically upgrade all that stuff
<alecu> Chipaca: I will
<ogra_> ali1234, well, then snappy is probably only interesting for users of your stuff
<ogra_> and not for yourself
<ali1234> ogra_: i am the only user for 99% of the software i write
<ogra_> right
<ogra_> so the more interesting thng for you might to provide a snapcraft plugin for users that acually want to use your tools and youself stay with deb
<ogra_> (if you actually want users :) )
<dholbach> nice one
<dholbach> thanks everyone
<wililupy> Thanks!
<willcooke> thanks
<elopio> thank you!
<ogra_> thanks !
 * ali1234 goes to #snappy
* ChanServ changed the topic of #ubuntu-uos-core to: Track: Core | Snappy Developer Community Resources | Url: http://summit.ubuntu.com/uos-1511/meeting/22592/core-1511-snappy-developer-community-resources/
<dholbach> all right... does anyone want to join the hangout?
<dholbach> this session is about snappy (online) resources
<Thibautr> Who uses primarily Stack Overflow when trying to solve a problem?
<ali1234> it depends on the problem
<ali1234> if it is very very technical and ubuntu-specific i have not had much luck with AU
<ali1234> actually that gos for pretty much anything very technical
<Thibautr> So do you switch to Google?
<Thibautr> I mean googling your problem?
<ali1234> no, i start with google
<Thibautr> OK :D
<ali1234> if that fails i will either ask on SO if it's something ... i dunno how to say it but kind of "mid level"
<ali1234> if it's extremely technical i look at the source and then go and ask the person on irc
<ali1234> often google leads me to an existing answer on SO!
<ali1234> that's why i start there
<tedg> Really SO is an excellent SEO job :-)
<ali1234> i don't care where the answer is as long as google can find it :)
<Thibautr> aahaha
<ali1234> the only thing i don't really like is mailing lists because the archives are hard to read and failing that you have to subscribe etc
<sergiusens> can someone write a telegram plugin so I get pinged about askubuntu questions tagged snapcraft?
<tedg> That would be cool
<sergiusens> QUESTION ^
<tedg> Hmm, searching Google for anything about stack overflow doesn't get what you watn.
<ali1234> sergiusens: i could probably hack that together
<sergiusens> ali1234, that would be nice :-)
<sergiusens> askubuntu only has one snapcraft question
<sergiusens> from dpm
<tedg> Oh, we'll need it to filter out questions from dpm ;-)
<Thibautr> SO to RSS , RSS to telegram?
<sergiusens> Thibautr, there's already an irc bot that spits questions from askubuntu for ubunut-touch
<sergiusens> I just want to transform that to telegram ;-)
<Thibautr> SO to RSS , RSS to IRC, IRC to Telegram :D
<ali1234> there's bots for telegram apparently
<Thibautr> mmm
<sergiusens> ali1234, yup, we have one for lp bug reports already
<ali1234> so all the code exists, just a matter of merging it together... that's pretty much my specialty
<sergiusens> if we need a list, what better that SO ?
<sergiusens> keep it dynamic
<dholbach> do you have a feel for what might be more popular or a better venue? SO or AU?
<sergiusens> askubuntu
<sergiusens> I was conflating SO as the same thing
<ali1234> that's a really difficult one. i feel like on one hand AU makes more logical sense, but AU has always seemed to be end-user focused
<zyga> hey
<tedg> Gonna have to figure out how to log into AU again...
<ali1234> tedg: i use launchpad openid
<tedg> ali1234: I used my own, then they dropped V1 and I haven't upgraded.
<ali1234> doh
<Thibautr> Looks like you can only do SO to email
<sergiusens> no
<sergiusens> ah, I don't at least
<Thibautr> you can't do it?
<Thibautr> http://stackexchange.com/filters/210379/ubuntu-core
<ogra_> Thibautr, i definitely dont want to get all 750 IRC pings i get per day piped to telegram on my phone :P
<Thibautr> ahah
<Thibautr> email it can be
<tedg> For workshops generally, I think that virt-manager is better.
<tedg> Everyone can use that and get it running, they don't need specific hardware.
<tedg> Besides the docker snap failing, I think I had a good one put together :-)
<Thibautr> I would do a workshop for non Ubuntu users too :D
<tedg> Wait, who are these people you speak of?
<ali1234> QUESTION: any plans for webinar style demos? like the ubuntu learning week? haven't seen one of those for a while
<tedg> We do snappy clinics
<ogra_> Thibautr, then you likely want virtualbox
<tedg> ali1234: They're on the ubuntu-on-air schedule
<ogra_> ali1234, yes, they happen recular
<ogra_> *regular
<tedg> ali1234: https://www.youtube.com/playlist?list=PL-qBHd6_LXWYm8qttcXaosAIzejTa5IPj
<ali1234> those seem more question-and-answer?
<tedg> dholbach: Can we get the ROS UOS session in that playlist?
<tedg> Oh, I was just joking about non-Ubuntu users.
<Thibautr> ali1234 , would you like us to do more show and tell part of the Snappy Clinic?
<ogra_> ali1234, it is tutorials but people ask questions on IRC while they happen :)
<ali1234> i'd like to see someone install snappy core on a raspberry pi, then install a very simple snap like a LED blinker, all in one session, no interruptions, demo problems etc :)
<ali1234> not just show-and-tell but actually showing every command run to achieve it
<ali1234> i remember seeing a juju demo along those lines once
<dholbach> tedg, can you drop me a mail with that, so I don't forget? I can try to get it on there
<Thibautr> ubuntu-core TV!
<tedg> dholbach: sent
* ChanServ changed the topic of #ubuntu-uos-core to: Track: Core | Porting popular apps/software to Snappy | Url: http://summit.ubuntu.com/uos-1511/meeting/22591/core-1511-porting-raspberry-pi-apps-to-snappy/
<dholbach> anyone who wants to join the porting session?
<elopio> I want to.
<zt> me
<dholbach> cool
<dholbach> https://plus.google.com/hangouts/_/hoaevent/AP36tYcfsOpn06JCaJMFwxKzAv0Yel_ooGg-QnomzZA7SO2Y9ZLKvg
<dholbach> the notes ar up on http://pad.ubuntu.com/uos-1511-core-1511-porting-raspberry-pi-apps-to-snappy
<elopio> I will take notes
<dholbach> if anyone of you wants so add more thoughts to it, please go ahead
<dholbach> zt, ^ there's the link for the hangout
<dholbach> does that work for you?
<tedg> I think the real question comes down to graphics. How do we expect people to use a display on the Raspberry Pi2?
<ali1234> i see a list of various libraries on the pad... gstreamer is conspicuously absent, and it's without doubt the best way to stream video out of the pi camera
<ali1234> and especially when used with gst-rpicamsrc - which unfortunately does not seem to be even packaged
<kyrofa> tedg, ooo yeah, good question
<dholbach> ali1234, adding gstreamer
<ali1234> (i actually use gstreamer in my robot)
<ali1234> the most popular apps if you asked every rpi user would be kodi, emulation-station, and some generic NAS software
<ali1234> personally i'd like to see mythtv-backend
<elopio> ali1234: emulation station, like a play station emulator?
<ali1234> emulation-station is like a front end for every emulator
<tedg> I think an interesting example might be a Deb repo mirror. It is one that a lot of Ubuntu power users/devs might find very practical. :-)
<ali1234> tedg: oooh that's a good one yeah
<elopio> tedg: yeah, cache.
<kyrofa> I agree with kodi, that seems to be a big rpi thing
<ali1234> http://emulationstation.org/
<tedg> Squid with adblock might also be popular with folks.
<tedg> I think that mzagnetti did a Guh snap. Might be interesting to promote that more.
<kyrofa> Is there a way to run multiple websites behind apache or nginx yet?
<dholbach> tedg, what's Guh?
<tedg> dholbach: https://github.com/guh/guh/wiki/Getting-started-snappy
<dholbach> ok :)
<thibautr> http://notyetthere.org/snap-up-your-home/
<lool> I dont know whether we still want openwrt as a snap
<lool> it's more inspiration for what we'd want to provide in terms of features
<kyrofa> I'd love to make a few web app snaps but I figure a bundled apache won't allow for multiple of those snaps being installed
<lool> lucy is the web UI of openwrt
<thibautr> hi mkarliner!
<mkarliner> hi
<dholbach> hey hey
<mkarliner> +1 for mosquitto 1.4!!!
<mkarliner> There is an issue with the underlying websockets on 1.4
<mkarliner> ah thanks
<mkarliner> Its an MQTT broker 1.4 supports websockets
<ali1234> +1 for arduino/avr development
<mkarliner> use node-red on RPi...
<mkarliner> With arduino plugin
<ali1234> there's more to AVR than just arduino... tools like dfu-update and avrdude for ICSP
<ali1234> there's a raspberry pi utility that turns it into a logic analyser that streams to your PC
<ali1234> that's what i use for i2c sniffing as well
<thibautr> https://www.kickstarter.com/projects/ncubehome/ncube-the-only-app-youll-need-for-your-smart-home
<tedg> thibautr: Is that this guy? http://samnazarko.co.uk/about/
<thibautr> http://www.bloomberg.com/news/videos/b/2cec897a-1bec-4e17-9168-304c2afb6902
<thibautr> this guy ... the UK alternative to Nest :D
<ali1234> everyone will vote for kodi :)
<ali1234> there's an entire raspberry distribution for kodi
<ali1234> like a whole disk image
<dholbach> thanks everyone!
<tedg> I'd like to see us get it as a release target for the kodi upstream
<tedg> Rather than someone in our community doing a package.
<lool> thibautr: it's team maintained in Debian
<lool> dunno in Ubuntu
<lool> Balint Reczey seems to be the recurring uploader
<tedg> thibautr: ncube is pretty interesting.
* ChanServ changed the topic of #ubuntu-uos-core to: Currently no events are active in this room - http://summit.ubuntu.com/uos-1511/core/ - http://irclogs.ubuntu.com/2015/11/05/%23ubuntu-uos-core.html
<dholbach> slangasek, do you know who'll run the F2FS session?
<dholbach> the summary of the python3 session also is still missing
<slangasek> dholbach: I do not; I didn't approve/schedule this session, did you?
<dholbach> sorry, I did - I put it on the schedule since it seemed like it was forgotten - I can remove it though
<dholbach> popey, ^ do you know if Martin wanted to run this?
* ChanServ changed the topic of #ubuntu-uos-core to: Track: Core | F2FS support for Ubiquity installer in 16.04 | Url: http://summit.ubuntu.com/uos-1511/meeting/22645/f2fs-support-for-ubiquity-installer-in-1604/
<popey> dholbach, i don't
<dholbach> hum......
<dholbach> anyone who's running this session?
<popey> did martin ask for it?
 * popey pings him on telegram
<dholbach> attendees of the session are: Teg, Martin Wimpress, Jorge O. Castro, Alan Pope ã
<dholbach> and as I didn't know Teg....
<dholbach> if nobody shows up to lead the session, we could still make it a discussion on the mailing list
<dholbach> ok... I'll remove it from the schedule
<dholbach> slangasek, ^
<slangasek> dholbach: fine with me
<slangasek> thanks
<popey> checked with martin, he didn't make it
<popey> no idea who did
<slangasek> teg made it
<slangasek> but I don't know teg
<slangasek> not here and no email listed in lp
* ChanServ changed the topic of #ubuntu-uos-core to: Currently no events are active in this room - http://summit.ubuntu.com/uos-1511/core/ - http://irclogs.ubuntu.com/2015/11/05/%23ubuntu-uos-core.html
