=== 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
=== hikiko|ln is now known as hikiko
geniiIs there someplace a comprehensive UOS schedule or itinerary?15:23
dholbachgenii, http://summit.ubuntu.com/uos-1511/ - and for today that's http://summit.ubuntu.com/uos-1511/2015-11-03/15:27
dholbachgenii, if you log into summit and "star" sessions, you can even have your own schedule15:27
geniidholbach: Excellent, thanks!15:27
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 enabled15:29
dholbachthat's weird15:29
dholbach#ubuntu-uos is the general UOS channel15:30
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 diagnosis15:30
TJ-What is weird is, it plays now it isn't live15:33
=== 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/
dholbachhey hey... frameworks session coming up in a bit15:54
dholbachping me if you want to contribute to and join the session15:55
dholbachas the other snappy session started a bit late, I guess we can wait for more snappy folks to turn up here16:00
dholbachwe'll start shortly16:01
dholbachanyone else here who wants to join the conversation about frameworks?16:01
dholbach^ (and come on to the video feed?)16:01
looldholbach: who's leading the session?16:03
dholbachlool, mvo and I are there16:03
dholbachcan you all join as well?16:03
dholbachhappy to share the link16:03
loolI will join in a couple minutes16:03
looldholbach: what's the link?16:06
dholbachlool, https://plus.google.com/hangouts/_/hoaevent/AP36tYfTPVxSDasP04fkgsxqqZjoaFtPsUX-CGILTyRwImLH6MtzNQ16:06
kyrofaDoes mir count since it's only available on amd64?16:08
dholbachkyrofa, ah yes - I'll note that down16:08
dholbachnoting down things on http://pad.ubuntu.com/uos-1511-core-1511-new-snappy-frameworks16:09
dholbachif you have questions or suggestions, please bring them up16:11
tedgkyrofa: It's still a framework, even if it's not on all archs :-)16:11
tedgI think it's important to note that an individual snap could do its own overlay internally.16:18
tedgSo each framework/snap developer can choose how she wants to handle the issue.16:18
tedgDoing something universally don't seem to make as much sense as letting a framework make its own choices.16:18
asac_onlinethink overlayfs was 3.18 iirc16:21
asac_onlineoverlayfs could be made an opt in feature that prevents snaps from isntalling on systems that do not have that CAPABILITY16:22
tedgFrameworks could make their own preload bin for the snap as well.16:22
tedgThat is scary universally, but doing it for a specific case isn't as big of worry.16:23
asac_onlinehowever, core frameworks that should enable our ecosystem shouldnt rely on that :)16:23
asac_onlinei 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 ecosystem16:24
asac_onlinelool: mvo: ^16:24
loolI wish you were on the ho to say it  :-)16:25
asac_onlinestill believe for key things we should just invest and make them relocatable16:25
tedgI think that is generally just additions to the service declaration.16:26
tedgI 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.16:27
asac_onlineyou express with capabilities :)16:28
Chipacadoesn't 3.18 already leave odroid out?16:28
asac_online3.18 leaves many things out16:28
ogra_yeah :(((16:28
asac_onlinei think overlayfs should be an option16:28
asac_onlinebut not for the main framewroks16:29
ogra_if we want to support phones ever we need to support 3.1016:29
asac_onlinebut phone vertical doesnt necessarily have that problem16:29
kyrofaogra_, and that's only arale16:30
asac_onlinethe apps are already relocatable16:30
ogra_kyrofa, really ? you know what kind of weird BSP kernels future devices will have ?16:30
kyrofaogra_, I mean krillin and vegetahd are even older, haha16:30
ogra_but for them there are lollipop trees, i would assume they also have newer kernels we could use16:31
diwicI'm here and I heard the word "PulseAudio"16:31
dobeywhat kerenel are we using on mako?16:31
ogra_dobey, i think thats also 3.1016:32
ogra_not sure though ... apt could tell you, it is in the archive ;)16:32
diwicBut I don't quite follow enough of difference between frameworks and snaps and inter-framework dependencies and whatnot16:32
diwicto know what to do if I should do something16:32
dobey3.4 apparently :)16:32
dobeyuname -r tells me that anyway16:32
Chipacadiwic: there are no inter-fwk deps16:32
kyrofadobey, 3.416:33
kyrofadobey, mako, krillin and vegetahd are all 3.4, arale is 3.1016:33
diwicChipaca, but if we have one bluetooth framework and one audio framework, how can we get bluetooth audio?16:33
tedgUser switching, sessions.16:33
Chipacadiwic: presumably, if they're built that way, you could have those frameworks cooperate, as long as they don't depend on eachother16:34
diwicChipaca, actually, that's a bad example because the audio framework can look if the bluez stuff is on d-bus and act accordingly16:34
tedgI imagine there'll need to be a framework for switching which user is using the display, keyboard and mouse.16:34
Chipacadiwic: exactly16:34
tedgAnd then if you have a user session, then which application is shown or managed.16:34
tedgBasically lightdm and unity8.16:34
dobeywe should probably update the mako kernel to the newer version16:34
tedgBut we'll need to be more than just that project.16:34
dobeyif we can16:34
niemeyer_I think eventually we'll have dependencies between snaps, and potentially frameworks, via the capability system16:35
niemeyer_But it's still a bit early for details on that16:36
kyrofadobey, not sure who's decision that is. But yeah, it's pretty old16:36
kyrofadobey, it's our reference kernel, though. I'm not sure mako can be updated without the others16:36
dobeykyrofa: we should update the others too. :)16:37
tedgNot 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.16:37
morphisdobey, kyrofa: we can't update any of those16:37
morphiswithout spending a lot of time getting them running again16:38
diwicAnother question is Gstreamer - is that a framework or snap? And what does it depend on w r t audio/video frameworks etc?16:38
morphisthey are heavily customized kernels for products16:38
tedgdiwic: Generally, it should be a library included by the app. The hard part there is the HW enabled plugins.16:38
diwictedg, hmm16:38
diwictedg, same goes for qtmultimedia then? Also included by the app?16:39
tedgdiwic: Correct16:39
kyrofadiwic, snapcraft should help you there16:40
tedgNothing is a framework, except the things that are :-)16:40
tedglool: The problem is that there are some specific GStreamer programs for DSPs. i.e. optimized MPEG 416:42
loolgood point16:42
* diwic tries to google for "snapcraft" and finds that top 5 results for "snapcraft" are all minecraft related 16:42
dholbachor snapcraft on github16:43
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 depends16:43
* tedg has that link ready for later ;-)16:43
kyrofadiwic, heh, always prepend your Google's regarding snappy with "ubuntu"16:43
niemeyer__honest truth16:43
alecuQUESTION: is OpenGL a framework, or should it be considered a dependency?16:47
niemeyer__The video stream is breaking down often for me.. is it just me?16:47
asac_onlinevideo is good here16:47
alecuniemeyer__: I can see it ok here16:47
dholbachniemeyer__, for me it's been fine all the time16:47
niemeyer__Ok, thanks16:47
tedgniemeyer__: 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.16:47
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 nature16:48
tedgClearly every rule has some exceptions, but we can't expect good things to happen without some guides.16:48
diwicI 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 is16:49
tedg+1 dholbach16:49
niemeyer__alecu: OpenGL is the API.. not a good framework by itself..16:50
Chipacalool: the dbus fwk example isn't there, fwiw16:52
tedgSeems like something we need to prioritize.16:52
loolChipaca: oh no16:52
alecuniemeyer__: so, should I ship client side libraries for OpenGL in my snap? I ask because client side OpenGL libraries usually depend on each specific hardware16:52
Chipacathere's a framework-template though16:52
loolChipaca: isn't that http://bazaar.launchpad.net/~snappy-dev/snappy-hub/snappy-examples/files/head:/hello-dbus/package-dir-fwk/ ?16:52
Chipacaalso, they're also on github: https://github.com/ubuntu-core/snappy-testdata16:52
diwicChipaca, that's a more interesting one. Can we get bluetooth framework without dbus framework?16:53
loolChipaca: it's dbus based AFAIK16:53
alecuniemeyer__: and I'll need to use that from my QML apps16:53
Chipacaalecu: we've got the same problem with mir16:53
alecuniemeyer__: anyway, this is the kind of things I'd like to discuss in the "Snaps for the Phone" session later today :-)16:53
Chipacaalecu: where the client-side libraries depend on the server abi16:53
loolChipaca:    bus-name: "com.canonical.hello-dbus-fwk"16:54
Chipacaalecu: no really good answer for that and opengl yet, however16:54
alecuChipaca: right16:54
Chipacaalecu: (IOW: feedback needed!)16:54
tedgChipaca: Well hopefully that one can be solved with capabilities? Where you put the mir protocols you're capable of.16:54
loolit's the example I had in mind, but you might know of nicer ones16:54
diwicmorphis, bluez is quite useless without d-bus, right?16:55
alecuthanks all for the session! I need to catch up with the first half, since I had a conflicting meeting though :-)16:55
=== 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)16:57
=== hikiko-lpt is now known as hikiko
Chipacaok, bye people17:01
=== 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 skynet19:00
udsbotuI have no seen command19:00
dholbachif anyone of you wants join the conversation or the hangout, ping me and I'll give you the link to the hangout19:02
dholbachif you have any questions, I can relay them19:03
snappy_carQUESTION: when will the phones use snaps?19:03
dobeyas soon as there's enough feature parity in snaps to transition from clicks by default19:04
snappy_cari see, thanks19:04
dobeyit'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 think19:05
snappy_carcan clicks and snaps coexist?19:06
tedgSo do you pull in the required dependencies when you convert the click to a snap?19:07
tedgQUESTION: So do you pull in the required dependencies when you convert the click to a snap?19:07
snappy_caromg you sust installed a click on the desktopm?19:07
snappy_cara snap19:07
snappy_carso that snap is x86?19:08
nhainessnappy_car: yes.19:09
nhainesAlthough I think they can be fat, too.19:09
snappy_carnice, now i need crackly19:09
nhainesActually, the calculator might be universal (QML + JS)19:10
nhainesBut if it's C++, it has to be cross-compiled.  :)19:10
snappy_carright :D19:10
bobolopolisIs Mir planned for ARM?19:12
kyrofasnappy_car, it's a QML app, so cross-platform19:12
dobeythe plan is to switch the phone to snaps completely, so yes, the frameworks will have to be on ARM19:12
kyrofanhaines, ^^19:12
nhainesbobolopolis: Mir's been running on ARM for 3 years and was released in a retail product in March.19:12
nhainesI'm looking forward to Mir and Unity 8 on RPi2.  :D19:13
bobolopolisI thought Kyle just said it wasn't on ARM, maybe I misunderstood19:13
dobeysnaps are still a little weird, because they don't have the distinction between all archs and multi-arch packages19:13
=== robobuilder_ is now known as robobuilder
dobeybobolopolis: the mir snap framework isn't on ARM yet19:13
dobeywhich is what kyrofa was talking about19:13
bobolopolisAh, okay19:14
tedgI think that, for example you want QML and Qt inside the snap.19:15
dobeyi don't think so19:15
dobeywe don't want every gnome app to have the entire gnome stack in each app's snap, for example19:15
tedgIf you want to patch it, or choose a version, you need to do that at build time. Not install.19:15
snappy_cari don't want Qt inside the snap, ewww19:16
dobeyhaving to include the full stack in every package is not reasonable19:16
snappy_carit's also silly19:16
loolmy 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 frameworks19:16
dobeyright, we need a solution to the binary incompatibility issues of frameworks too19:17
loolit'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 snap19:17
tedgSo we think that on the phone devs shouldn't get to choose the versions of all their deps? ;-)19:17
kyrofaThat first link ^^ will walk you through the demo I just gave19:18
dobeytedg: they can already do that if they want19:18
tedgi.e. you're just recreating the debian repository problem19:18
tedgThen developers can build their own PyPi for Snaps!19:18
looltedg: 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 thin19:19
loolwhile Ubuntu for Phone is an opinonated view of what a phone image should be19:19
loolwith a standard set of permissions and frameworks and libraries and a SDK etc.19:19
tedgI think that opinionated view is implemented in the gadget snap of the image.19:19
tedgYou still want it on the same core.19:19
ogra_lool, any why cant we create "architecture of your platform on top of something thin" on the phone too ?19:19
loolI'm not opposed to using a single OS image for core and phone images, it might be hard to achieve in the short term19:20
tedgFor 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.19:20
cm-tI 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)19:20
ogra_i would see the phone as ubuntu-core + ubuntu-phone-ui (framework)19:20
loologra_: we *can* but it's not desirable due to the stupid size and embedded bug copies it creates19:20
loolit's the same story as shipping an embedded interpreter for each snap19:21
loolit makes sense in snappy Ubuntu Core because it's meant to be thin and nude19:21
tedgWe can make an SDK snapcraft plugin that handles it easily enough.19:21
ogra_why ? ubuntu-phone-ui provides the ubuntu framework19:21
ogra_it is essentially everything we have on the phone today minus ubuntu-core :)19:21
loolbut 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  :-)19:21
tedglool: That's where concepts like intra-package deduplication comes into play. So it appears small on the disk, but each snap appears complete.19:22
niemeyer__Yes, ideally we'd use exactly the same OS snap, which by itself is also built as a subset from a standard Ubuntu image19:22
asac-phonelool: what about a third party that wants to build something like a phone?19:22
looltedg: well, we don't have that I'm afraid19:22
looltedg: also, it still prevents fixing in a single place bugs that are part of your runtime19:22
niemeyer__We can always fix it so that it remains a usable subset of both environments19:22
tedglool: We shouldn't break the Snappy architecture because we don't have it.19:22
asac-phoneour architecture should support building something like the phone ... otherwise its not clean yet19:22
tedglool: Yes, single place is the problem. It's the Debian repo problem :-)19:23
loolwe 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 basis19:23
dobeytedg: we shouldn't break phones, because snappy doesn't have what the phones currently do, either19:23
* ogra_ notes that asac-phone is very wasteful with irc nicks today 19:23
tedgdobey: We're not shipping a Snappy phone today :-)19:23
looltedg: well precisely, we get to decide, product by product / image by image, where we draw the line between supported and unsupported19:23
loolwith a clear interface19:23
dobeytedg: exactly because snappy isn't ready for phones19:23
tedgdobey: Not saying it is, but it is a target :-)19:23
loolfor instance: "here's your scope API, write this bit in this language and bundle it as a snap in the store"19:23
dholbachdoes anyone want to join the hangout?19:23
loolsame for QML apps19:23
tedglool: No, developers get to decide. We don't.19:24
looltedg: well you describe something else19:24
looltedg: it's a "create your own phone platform with random opensource components" version of snappy19:24
looltedg: today, Ubuntu for phones is a toplevel product that we maintain with a vision of how the user experience should be like19:24
asac-phonelool:so you say "create your own platform" is out of scope for snappy core?19:24
looltedg: 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 whatever19:25
tedgNo, 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.19:25
loolasac-phone: it's not, but it's not the same goal19:25
dobeytedg: there's nothing preventing you from doing that19:25
loolfor me, Ubuntu for phones is [ OS snap + phone frameworks + Ubuntu snaps + 3rd party snaps ]19:25
dobeytedg: but just because your special case is special, doesn't mean all users and developers should have to suffer for every app19:25
loolwith a vision of what goes into OS snap / phone frameworks (I dont care how it's split)19:26
tedgThere is a difference between recreating everything and including the in-memory dependencies of the app in the snap.19:26
loolyou can still create your [ Ubuntu Core snap + random frameworks + other snaps ] platform if you care19:26
loolit's a different exercize19:26
loolsay, you could ship a Plasma phone with [ Ubuntu Core snap + Plasma framework(s) + Plasma apps + 3rd party snaps ]19:27
looland that's a different border / split19:27
ogra_lool, that sounds like what i imagine too19:28
loolwhat's not good to deliver a good phone product is [ Ubuntu Core snap + random snaps embedding everything ]19:28
tedgSure, 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.19:28
looleven if you throw a random set of frameworks in there, the duplication and lack of clear SDK / user experience guidelines kills the product19:28
tedgWe want to create the consistency with great snapcraft plugins, not with framework snaps that share files.19:28
loolyou want to be able to say things like "apps are allowed to work in the background and access this always available services / middleware"19:28
asac-phonelool: sure :) ... making a platform is not done by just providig parts to incude in snaps :)19:28
loolthis 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 there19:29
loolit would have an unacceptable cost though19:29
loolhence why I think we should not embed Qt/QML in Ubuntu for phones19:29
asac-phonelool:ok didnt get that.. think we agree :)19:30
loolbut you're welcome to do it in your "MyKiosk" use case, running Ubuntu Core + yourkiosk snap19:30
asac-phonelool:but do we have what it takes to do such opinionated platform on top of core?19:30
loolasac-phone: we have the opinonated view already: it's the current phone design19:30
ogra_we will need a single versioned dependency towards the framework19:30
ogra_to make sure your snaps actually find the right env19:31
asac-phonelool:you mean making a big personal OS snap?19:31
asac-phoneor is thre a new design based on core?19:31
ogra_asac-phone, a framework on top of ubuntu-core19:31
loolfor instance, we could say "when using ubuntu-for-phone-framework, your snap should rely on qmlviewer to launch"19:31
ogra_but yeah, i big snap19:31
loole.g. we could ship #!/bin/env qmlviewver <QML contents goes here> global files19:31
loolor, nicer, some kind of snap hook to pickup your QML files/Qt files and expose them in the launcher19:32
loolasac-phone: well there are multiple options on how we can approach the internal split19:32
loolis it one big snap with all phone middlewares19:32
loolor do we make each a framework19:33
loollots of possibilities; not sure which is best personally19:33
tedglool: There is no qmlscene anymore they changed that in a version of Qt. Perhaps we could abstract which version of Qt is being used?19:33
looltedg: sure, this was just to illustrate the point19:33
dholbachany more specific questions you'd like to see discussed?19:33
ogra_while it would be much nicer to have many frameworks it will also lead to needing dependencies19:33
tedgubuntuqmlplayer, we could add a debian-alternatives implementation19:33
looltedg: perhaps it would ubuntu-for-phones-qml-launcher19:33
asac-phoneso 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 pulse19:33
ogra_asac-phone, on a phone, yes19:34
loolguys, I'm sorry the IRC conversation diverged from the hangouts; I feel I've not paid enough attention to the hangout19:34
asac-phonelool: guess sorry to the hangout crew :)19:34
dholbachanything in specific you'd like to see discussed?19:34
dholbachor an open question?19:34
tedgI think that everything in the base user session needs to be a big snap.19:34
tedgBut that doesn't mean that apps need to share files with that.19:34
mvoso any questions for the people in the hangout?19:35
* jdstrand just arrived-- were there any questions for me?19:35
tedgjdstrand: Just action items, don't worry.19:35
loolasac-phone: no strong opinion there; I'm not sure it's ok to have the requirements that all frameworks can be coinstalled19:35
jdstrandI good at deferring those19:35
tedgHeh, managers.19:36
looldholbach: I'm happy to join  :-)19:36
kyrofaWe'll hang here for any questions19:36
jdstrandlool: did the definition of frameworks change?19:36
dholbachlool, NOW... :)19:36
looljdstrand: it did not19:36
niemeyer__Wrong button..19:36
looldholbach: sorry  :-)19:36
niemeyer__alecu: Thanks for mediating it19:36
kyrofaYeah thanks alecu!19:36
* asac-phone dinner19:36
willcookethanks guys19:37
loolalecu: <319:37
alecuthank you guys, and keep up the good work!19:37
alecuI'm catching up with the backlog, and I noticed this:19:44
alecu"16:19:15 <lool> while Ubuntu for Phone is an opinonated view of what a phone image should be"19:44
alecuthat sounds exactly like what we'd like19:44
=== 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

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!