| === 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 | ||
| genii | Is there someplace a comprehensive UOS schedule or itinerary? | 15:23 |
|---|---|---|
| TJ- | http://summit.ubuntu.com | 15:25 |
| dholbach | genii, http://summit.ubuntu.com/uos-1511/ - and for today that's http://summit.ubuntu.com/uos-1511/2015-11-03/ | 15:27 |
| dholbach | genii, if you log into summit and "star" sessions, you can even have your own schedule | 15:27 |
| genii | dholbach: 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 enabled | 15:29 |
| dholbach | that's weird | 15:29 |
| dholbach | #ubuntu-uos is the general UOS channel | 15: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 diagnosis | 15:30 |
| TJ- | What is weird is, it plays now it isn't live | 15: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/ | ||
| dholbach | hey hey... frameworks session coming up in a bit | 15:54 |
| dholbach | ping me if you want to contribute to and join the session | 15:55 |
| dholbach | as the other snappy session started a bit late, I guess we can wait for more snappy folks to turn up here | 16:00 |
| dholbach | we'll start shortly | 16:01 |
| dholbach | anyone else here who wants to join the conversation about frameworks? | 16:01 |
| dholbach | ^ (and come on to the video feed?) | 16:01 |
| lool | dholbach: who's leading the session? | 16:03 |
| dholbach | lool, mvo and I are there | 16:03 |
| dholbach | can you all join as well? | 16:03 |
| dholbach | happy to share the link | 16:03 |
| lool | I will join in a couple minutes | 16:03 |
| lool | dholbach: what's the link? | 16:06 |
| dholbach | lool, https://plus.google.com/hangouts/_/hoaevent/AP36tYfTPVxSDasP04fkgsxqqZjoaFtPsUX-CGILTyRwImLH6MtzNQ | 16:06 |
| kyrofa | Does mir count since it's only available on amd64? | 16:08 |
| dholbach | kyrofa, ah yes - I'll note that down | 16:08 |
| dholbach | noting down things on http://pad.ubuntu.com/uos-1511-core-1511-new-snappy-frameworks | 16:09 |
| dholbach | if you have questions or suggestions, please bring them up | 16:11 |
| tedg | kyrofa: It's still a framework, even if it's not on all archs :-) | 16:11 |
| tedg | I think it's important to note that an individual snap could do its own overlay internally. | 16:18 |
| tedg | So each framework/snap developer can choose how she wants to handle the issue. | 16:18 |
| tedg | Doing something universally don't seem to make as much sense as letting a framework make its own choices. | 16:18 |
| asac_online | think overlayfs was 3.18 iirc | 16:21 |
| asac_online | overlayfs could be made an opt in feature that prevents snaps from isntalling on systems that do not have that CAPABILITY | 16:22 |
| tedg | Frameworks could make their own preload bin for the snap as well. | 16:22 |
| tedg | That is scary universally, but doing it for a specific case isn't as big of worry. | 16:23 |
| asac_online | however, core frameworks that should enable our ecosystem shouldnt rely on that :) | 16:23 |
| 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 | 16:24 |
| asac_online | lool: mvo: ^ | 16:24 |
| lool | I wish you were on the ho to say it :-) | 16:25 |
| asac_online | still believe for key things we should just invest and make them relocatable | 16:25 |
| asac_online | :) | 16:25 |
| tedg | I think that is generally just additions to the service declaration. | 16:26 |
| 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. | 16:27 |
| asac_online | you express with capabilities :) | 16:28 |
| Chipaca | doesn't 3.18 already leave odroid out? | 16:28 |
| asac_online | 3.18 leaves many things out | 16:28 |
| Chipaca | k | 16:28 |
| ogra_ | yeah :((( | 16:28 |
| asac_online | i think overlayfs should be an option | 16:28 |
| asac_online | but not for the main framewroks | 16:29 |
| ogra_ | if we want to support phones ever we need to support 3.10 | 16:29 |
| asac_online | sure | 16:29 |
| asac_online | but phone vertical doesnt necessarily have that problem | 16:29 |
| kyrofa | ogra_, and that's only arale | 16:30 |
| asac_online | the apps are already relocatable | 16:30 |
| ogra_ | kyrofa, really ? you know what kind of weird BSP kernels future devices will have ? | 16:30 |
| ogra_ | :P | 16:30 |
| kyrofa | ogra_, I mean krillin and vegetahd are even older, haha | 16:30 |
| ogra_ | yeah | 16:30 |
| ogra_ | but for them there are lollipop trees, i would assume they also have newer kernels we could use | 16:31 |
| diwic | I'm here and I heard the word "PulseAudio" | 16:31 |
| dobey | what kerenel are we using on mako? | 16:31 |
| diwic | :-) | 16:31 |
| ogra_ | dobey, i think thats also 3.10 | 16:32 |
| ogra_ | not sure though ... apt could tell you, it is in the archive ;) | 16:32 |
| diwic | But I don't quite follow enough of difference between frameworks and snaps and inter-framework dependencies and whatnot | 16:32 |
| dobey | 3.4.0-7-mako | 16:32 |
| diwic | to know what to do if I should do something | 16:32 |
| dobey | 3.4 apparently :) | 16:32 |
| dobey | uname -r tells me that anyway | 16:32 |
| Chipaca | diwic: there are no inter-fwk deps | 16:32 |
| kyrofa | dobey, 3.4 | 16:33 |
| kyrofa | dobey, mako, krillin and vegetahd are all 3.4, arale is 3.10 | 16:33 |
| diwic | Chipaca, but if we have one bluetooth framework and one audio framework, how can we get bluetooth audio? | 16:33 |
| tedg | User switching, sessions. | 16:33 |
| Chipaca | diwic: presumably, if they're built that way, you could have those frameworks cooperate, as long as they don't depend on eachother | 16:34 |
| 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 | 16:34 |
| tedg | I imagine there'll need to be a framework for switching which user is using the display, keyboard and mouse. | 16:34 |
| Chipaca | diwic: exactly | 16:34 |
| tedg | And then if you have a user session, then which application is shown or managed. | 16:34 |
| tedg | Basically lightdm and unity8. | 16:34 |
| dobey | we should probably update the mako kernel to the newer version | 16:34 |
| tedg | But we'll need to be more than just that project. | 16:34 |
| dobey | if we can | 16:34 |
| niemeyer_ | I think eventually we'll have dependencies between snaps, and potentially frameworks, via the capability system | 16:35 |
| niemeyer_ | B | 16:35 |
| niemeyer_ | But it's still a bit early for details on that | 16:36 |
| kyrofa | dobey, not sure who's decision that is. But yeah, it's pretty old | 16:36 |
| kyrofa | dobey, it's our reference kernel, though. I'm not sure mako can be updated without the others | 16:36 |
| dobey | kyrofa: we should update the others too. :) | 16:37 |
| 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. | 16:37 |
| morphis | dobey, kyrofa: we can't update any of those | 16:37 |
| morphis | without spending a lot of time getting them running again | 16:38 |
| diwic | Another question is Gstreamer - is that a framework or snap? And what does it depend on w r t audio/video frameworks etc? | 16:38 |
| morphis | they are heavily customized kernels for products | 16:38 |
| tedg | diwic: Generally, it should be a library included by the app. The hard part there is the HW enabled plugins. | 16:38 |
| diwic | tedg, hmm | 16:38 |
| diwic | tedg, same goes for qtmultimedia then? Also included by the app? | 16:39 |
| tedg | diwic: Correct | 16:39 |
| kyrofa | diwic, snapcraft should help you there | 16:40 |
| tedg | Nothing is a framework, except the things that are :-) | 16:40 |
| tedg | lool: The problem is that there are some specific GStreamer programs for DSPs. i.e. optimized MPEG 4 | 16:42 |
| lool | good point | 16:42 |
| * diwic tries to google for "snapcraft" and finds that top 5 results for "snapcraft" are all minecraft related | 16:42 | |
| dholbach | developer.ubuntu.com/snappy/build-apps | 16:43 |
| dholbach | or snapcraft on github | 16:43 |
| tedg | https://github.com/ubuntu-core/snapcraft | 16: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 depends | 16:43 |
| * tedg has that link ready for later ;-) | 16:43 | |
| kyrofa | diwic, heh, always prepend your Google's regarding snappy with "ubuntu" | 16:43 |
| niemeyer__ | honest truth | 16:43 |
| diwic | thanks | 16:43 |
| alecu | QUESTION: 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_online | video is good here | 16:47 |
| alecu | niemeyer__: I can see it ok here | 16:47 |
| dholbach | niemeyer__, for me it's been fine all the time | 16:47 |
| niemeyer__ | Ok, thanks | 16:47 |
| 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. | 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 nature | 16:48 |
| tedg | Clearly every rule has some exceptions, but we can't expect good things to happen without some guides. | 16:48 |
| lool | https://developer.ubuntu.com/en/snappy/guides/frameworks/ | 16:49 |
| 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 | 16:49 |
| tedg | +1 dholbach | 16:49 |
| niemeyer__ | alecu: OpenGL is the API.. not a good framework by itself.. | 16:50 |
| lool | https://code.launchpad.net/~snappy-dev/snappy-hub/snappy-examples | 16:51 |
| Chipaca | lool: the dbus fwk example isn't there, fwiw | 16:52 |
| tedg | Seems like something we need to prioritize. | 16:52 |
| lool | Chipaca: oh no | 16:52 |
| 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 | 16:52 |
| Chipaca | there's a framework-template though | 16:52 |
| lool | Chipaca: isn't that http://bazaar.launchpad.net/~snappy-dev/snappy-hub/snappy-examples/files/head:/hello-dbus/package-dir-fwk/ ? | 16:52 |
| Chipaca | also, they're also on github: https://github.com/ubuntu-core/snappy-testdata | 16:52 |
| diwic | Chipaca, that's a more interesting one. Can we get bluetooth framework without dbus framework? | 16:53 |
| lool | Chipaca: it's dbus based AFAIK | 16:53 |
| alecu | niemeyer__: and I'll need to use that from my QML apps | 16:53 |
| Chipaca | alecu: we've got the same problem with mir | 16:53 |
| asac_online | thx | 16:53 |
| alecu | niemeyer__: anyway, this is the kind of things I'd like to discuss in the "Snaps for the Phone" session later today :-) | 16:53 |
| Chipaca | alecu: where the client-side libraries depend on the server abi | 16:53 |
| lool | Chipaca: bus-name: "com.canonical.hello-dbus-fwk" | 16:54 |
| Chipaca | alecu: no really good answer for that and opengl yet, however | 16:54 |
| alecu | Chipaca: right | 16:54 |
| Chipaca | alecu: (IOW: feedback needed!) | 16:54 |
| tedg | Chipaca: Well hopefully that one can be solved with capabilities? Where you put the mir protocols you're capable of. | 16:54 |
| lool | it's the example I had in mind, but you might know of nicer ones | 16:54 |
| diwic | morphis, bluez is quite useless without d-bus, right? | 16:55 |
| alecu | thanks 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 | ||
| Chipaca | ok, bye people | 17: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 skynet | 19:00 |
| udsbotu | I have no seen command | 19:00 |
| snappy_car | :( | 19:00 |
| dholbach | if anyone of you wants join the conversation or the hangout, ping me and I'll give you the link to the hangout | 19:02 |
| dholbach | if you have any questions, I can relay them | 19:03 |
| snappy_car | QUESTION: when will the phones use snaps? | 19:03 |
| dobey | as soon as there's enough feature parity in snaps to transition from clicks by default | 19:04 |
| snappy_car | i see, thanks | 19:04 |
| 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 | 19:05 |
| snappy_car | can clicks and snaps coexist? | 19:06 |
| tedg | So do you pull in the required dependencies when you convert the click to a snap? | 19:07 |
| tedg | QUESTION: So do you pull in the required dependencies when you convert the click to a snap? | 19:07 |
| snappy_car | omg you sust installed a click on the desktopm? | 19:07 |
| snappy_car | OMG | 19:07 |
| snappy_car | a snap | 19:07 |
| snappy_car | so that snap is x86? | 19:08 |
| snappy_car | right? | 19:08 |
| nhaines | snappy_car: yes. | 19:09 |
| nhaines | Although I think they can be fat, too. | 19:09 |
| snappy_car | nice, now i need crackly | 19:09 |
| nhaines | Actually, the calculator might be universal (QML + JS) | 19:10 |
| nhaines | But if it's C++, it has to be cross-compiled. :) | 19:10 |
| snappy_car | right :D | 19:10 |
| bobolopolis | Is Mir planned for ARM? | 19:12 |
| kyrofa | snappy_car, it's a QML app, so cross-platform | 19:12 |
| dobey | the plan is to switch the phone to snaps completely, so yes, the frameworks will have to be on ARM | 19:12 |
| kyrofa | nhaines, ^^ | 19:12 |
| nhaines | bobolopolis: Mir's been running on ARM for 3 years and was released in a retail product in March. | 19:12 |
| nhaines | I'm looking forward to Mir and Unity 8 on RPi2. :D | 19:13 |
| bobolopolis | I thought Kyle just said it wasn't on ARM, maybe I misunderstood | 19:13 |
| dobey | snaps are still a little weird, because they don't have the distinction between all archs and multi-arch packages | 19:13 |
| === robobuilder_ is now known as robobuilder | ||
| dobey | bobolopolis: the mir snap framework isn't on ARM yet | 19:13 |
| dobey | which is what kyrofa was talking about | 19:13 |
| bobolopolis | Ah, okay | 19:14 |
| tedg | I think that, for example you want QML and Qt inside the snap. | 19:15 |
| dobey | right | 19:15 |
| dobey | i don't think so | 19:15 |
| dobey | we don't want every gnome app to have the entire gnome stack in each app's snap, for example | 19:15 |
| alecu | https://docs.google.com/document/d/1BqJr8de5rr6s0NGm6BEsM3Yc8FCyLODGnCDFp_Y0Mxs/edit?ts=5633d6d8# | 19:15 |
| tedg | If you want to patch it, or choose a version, you need to do that at build time. Not install. | 19:15 |
| snappy_car | i don't want Qt inside the snap, ewww | 19:16 |
| dobey | having to include the full stack in every package is not reasonable | 19:16 |
| alecu | https://docs.google.com/document/d/1xwHIt5FLjrNur59Kh7aMB4SNzPTpTyhy-tkPchTxT0k/edit?ts=5637c5ca# | 19:16 |
| snappy_car | it's also silly | 19:16 |
| 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 | 19:16 |
| dobey | right, we need a solution to the binary incompatibility issues of frameworks too | 19:17 |
| 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 | 19:17 |
| tedg | So we think that on the phone devs shouldn't get to choose the versions of all their deps? ;-) | 19:17 |
| kyrofa | That first link ^^ will walk you through the demo I just gave | 19:18 |
| dobey | tedg: they can already do that if they want | 19:18 |
| tedg | i.e. you're just recreating the debian repository problem | 19:18 |
| tedg | Then developers can build their own PyPi for Snaps! | 19:18 |
| 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 | 19:19 |
| lool | while Ubuntu for Phone is an opinonated view of what a phone image should be | 19:19 |
| lool | with a standard set of permissions and frameworks and libraries and a SDK etc. | 19:19 |
| tedg | I think that opinionated view is implemented in the gadget snap of the image. | 19:19 |
| tedg | You 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 |
| 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 | 19:20 |
| 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. | 19:20 |
| 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) | 19:20 |
| ogra_ | i would see the phone as ubuntu-core + ubuntu-phone-ui (framework) | 19:20 |
| lool | ogra_: we *can* but it's not desirable due to the stupid size and embedded bug copies it creates | 19:20 |
| lool | it's the same story as shipping an embedded interpreter for each snap | 19:21 |
| lool | it makes sense in snappy Ubuntu Core because it's meant to be thin and nude | 19:21 |
| tedg | We can make an SDK snapcraft plugin that handles it easily enough. | 19:21 |
| ogra_ | why ? ubuntu-phone-ui provides the ubuntu framework | 19:21 |
| ogra_ | it is essentially everything we have on the phone today minus ubuntu-core :) | 19:21 |
| 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 :-) | 19:21 |
| 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. | 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 image | 19:22 |
| asac-phone | lool: what about a third party that wants to build something like a phone? | 19:22 |
| lool | tedg: well, we don't have that I'm afraid | 19:22 |
| lool | tedg: also, it still prevents fixing in a single place bugs that are part of your runtime | 19:22 |
| niemeyer__ | We can always fix it so that it remains a usable subset of both environments | 19:22 |
| tedg | lool: We shouldn't break the Snappy architecture because we don't have it. | 19:22 |
| asac-phone | our architecture should support building something like the phone ... otherwise its not clean yet | 19:22 |
| ogra_ | +1 | 19:22 |
| tedg | lool: Yes, single place is the problem. It's the Debian repo problem :-) | 19:23 |
| 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 | 19:23 |
| dobey | tedg: we shouldn't break phones, because snappy doesn't have what the phones currently do, either | 19:23 |
| * ogra_ notes that asac-phone is very wasteful with irc nicks today | 19:23 | |
| tedg | dobey: We're not shipping a Snappy phone today :-) | 19:23 |
| lool | tedg: well precisely, we get to decide, product by product / image by image, where we draw the line between supported and unsupported | 19:23 |
| lool | with a clear interface | 19:23 |
| dobey | tedg: exactly because snappy isn't ready for phones | 19:23 |
| tedg | dobey: Not saying it is, but it is a target :-) | 19:23 |
| lool | for instance: "here's your scope API, write this bit in this language and bundle it as a snap in the store" | 19:23 |
| dholbach | does anyone want to join the hangout? | 19:23 |
| lool | same for QML apps | 19:23 |
| dobey | *sigh* | 19:23 |
| tedg | lool: No, developers get to decide. We don't. | 19:24 |
| lool | tedg: well you describe something else | 19:24 |
| lool | tedg: it's a "create your own phone platform with random opensource components" version of snappy | 19:24 |
| lool | tedg: today, Ubuntu for phones is a toplevel product that we maintain with a vision of how the user experience should be like | 19:24 |
| asac-phone | lool:so you say "create your own platform" is out of scope for snappy core? | 19:24 |
| 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 | 19:25 |
| 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. | 19:25 |
| lool | asac-phone: it's not, but it's not the same goal | 19:25 |
| dobey | tedg: there's nothing preventing you from doing that | 19:25 |
| lool | for me, Ubuntu for phones is [ OS snap + phone frameworks + Ubuntu snaps + 3rd party snaps ] | 19:25 |
| dobey | tedg: but just because your special case is special, doesn't mean all users and developers should have to suffer for every app | 19:25 |
| lool | with a vision of what goes into OS snap / phone frameworks (I dont care how it's split) | 19:26 |
| tedg | There is a difference between recreating everything and including the in-memory dependencies of the app in the snap. | 19:26 |
| lool | but | 19:26 |
| lool | you can still create your [ Ubuntu Core snap + random frameworks + other snaps ] platform if you care | 19:26 |
| lool | it's a different exercize | 19:26 |
| lool | say, you could ship a Plasma phone with [ Ubuntu Core snap + Plasma framework(s) + Plasma apps + 3rd party snaps ] | 19:27 |
| lool | and that's a different border / split | 19:27 |
| ogra_ | lool, that sounds like what i imagine too | 19:28 |
| lool | what's not good to deliver a good phone product is [ Ubuntu Core snap + random snaps embedding everything ] | 19:28 |
| 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. | 19:28 |
| 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 | 19:28 |
| tedg | We want to create the consistency with great snapcraft plugins, not with framework snaps that share files. | 19:28 |
| dobey | "we" | 19:28 |
| 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" | 19:28 |
| asac-phone | lool: sure :) ... making a platform is not done by just providig parts to incude in snaps :) | 19:28 |
| 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 | 19:29 |
| lool | it would have an unacceptable cost though | 19:29 |
| lool | hence why I think we should not embed Qt/QML in Ubuntu for phones | 19:29 |
| asac-phone | lool:ok didnt get that.. think we agree :) | 19:30 |
| lool | but you're welcome to do it in your "MyKiosk" use case, running Ubuntu Core + yourkiosk snap | 19:30 |
| asac-phone | lool:but do we have what it takes to do such opinionated platform on top of core? | 19:30 |
| lool | asac-phone: we have the opinonated view already: it's the current phone design | 19:30 |
| ogra_ | we will need a single versioned dependency towards the framework | 19:30 |
| ogra_ | to make sure your snaps actually find the right env | 19:31 |
| asac-phone | lool:you mean making a big personal OS snap? | 19:31 |
| asac-phone | or is thre a new design based on core? | 19:31 |
| ogra_ | asac-phone, a framework on top of ubuntu-core | 19:31 |
| lool | for 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 snap | 19:31 |
| lool | e.g. we could ship #!/bin/env qmlviewver <QML contents goes here> global files | 19:31 |
| ogra_ | s/i/a | 19:32 |
| lool | or, nicer, some kind of snap hook to pickup your QML files/Qt files and expose them in the launcher | 19:32 |
| lool | asac-phone: well there are multiple options on how we can approach the internal split | 19:32 |
| lool | is it one big snap with all phone middlewares | 19:32 |
| lool | or do we make each a framework | 19:33 |
| lool | lots of possibilities; not sure which is best personally | 19:33 |
| dobey | framework-15.04.snap | 19:33 |
| 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? | 19:33 |
| lool | tedg: sure, this was just to illustrate the point | 19:33 |
| dholbach | any 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 dependencies | 19:33 |
| tedg | ubuntuqmlplayer, we could add a debian-alternatives implementation | 19:33 |
| lool | tedg: perhaps it would ubuntu-for-phones-qml-launcher | 19:33 |
| 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 | 19:33 |
| ogra_ | asac-phone, on a phone, yes | 19:34 |
| lool | guys, I'm sorry the IRC conversation diverged from the hangouts; I feel I've not paid enough attention to the hangout | 19:34 |
| lool | sorry! | 19:34 |
| asac-phone | hehe | 19:34 |
| asac-phone | lool: guess sorry to the hangout crew :) | 19:34 |
| dholbach | anything in specific you'd like to see discussed? | 19:34 |
| dholbach | or an open question? | 19:34 |
| tedg | I think that everything in the base user session needs to be a big snap. | 19:34 |
| tedg | But that doesn't mean that apps need to share files with that. | 19:34 |
| mvo | so any questions for the people in the hangout? | 19:35 |
| * jdstrand just arrived-- were there any questions for me? | 19:35 | |
| tedg | jdstrand: Just action items, don't worry. | 19:35 |
| jdstrand | heh | 19:35 |
| lool | asac-phone: no strong opinion there; I'm not sure it's ok to have the requirements that all frameworks can be coinstalled | 19:35 |
| jdstrand | I good at deferring those | 19:35 |
| jdstrand | I'm* | 19:35 |
| tedg | Heh, managers. | 19:36 |
| lool | dholbach: I'm happy to join :-) | 19:36 |
| kyrofa | We'll hang here for any questions | 19:36 |
| jdstrand | lool: did the definition of frameworks change? | 19:36 |
| dholbach | lool, NOW... :) | 19:36 |
| lool | jdstrand: it did not | 19:36 |
| niemeyer__ | Wrong button.. | 19:36 |
| lool | dholbach: sorry :-) | 19:36 |
| niemeyer__ | alecu: Thanks for mediating it | 19:36 |
| asac-phone | thanks! | 19:36 |
| kyrofa | Yeah thanks alecu! | 19:36 |
| * asac-phone dinner | 19:36 | |
| willcooke | thanks guys | 19:37 |
| lool | alecu: <3 | 19:37 |
| alecu | thank you guys, and keep up the good work! | 19:37 |
| alecu | I'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 |
| alecu | that sounds exactly like what we'd like | 19: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!