=== chihchun_afk is now known as chihchun === _longines_ is now known as _longines [09:42] Today's "Snaps on classic Ubuntu Q&A with Olli Ries" is missing from On-Air's calendar [09:42] can anyone fix that? === mariogrip_ is now known as mariogrip [14:28] Hello [14:29] Hallo === Me is now known as Guest35364 [14:55] hey all [14:55] everyone up for the q&A [14:56] o/ [14:57] o/ [14:57] dpm: the timing of this video sucks for me. :) 10:00 am should be reserved for mid morning naps [14:58] MichaelTunnell: go back to sleep, I'll phone you at 3am with the details [14:58] lol deal === bob is now known as Guest78236 [15:00] This is the first time I've been able to watch one of these things live. [15:00] time to start the show! [15:00] MichaelTunnell, the more we appreciate you coming :) [15:01] we'll be starting shortly, getting people situated :) [15:02] * kenvandine blames popey === olli| is now known as olli [15:02] \o/ [15:03] and we're live! [15:03] let us know if you can see the video feed [15:03] dpm: :) [15:03] hi everyone o/ [15:03] hello [15:03] remember to prepend the questions with QUESTION: [15:03] hey hey [15:04] QUESTION: Testing how yellow this is on mhall119's screen. [15:04] QUESTION: Does this rely entirely on a projects willingness to add snaps to their available delivery options? [15:04] popey: it's green, because you mentiond my nick :-P [15:05] QUESTION: Is there any indication whether any popular projects are investigating or already planning on providing snaps? [15:05] hey to all latecommers, welcome! o/ [15:05] QUESTION: how do I serve updates for a snap package that I've provided, and how does snappy know that there's an update? [15:06] magic ;) [15:06] QUESTION: what's he difference between snaps and clicks? [15:06] aquarius, just upload a new version to the store [15:06] QUESTION: what does the term Frameworks refer to on this page http://www.ubuntu.com/cloud/snappy [15:06] kyrofa, that's only if it's in the store, though :) [15:06] QUESTION: Easy one, for you. When? And can we that don't mind breaking our systems get it early? [15:07] aquarius, the only way to deliver them .... if users sideload your snaps you need to blog about updates or so :) [15:07] * beuno will take aquarius's question [15:07] QUESTION: do snaps have to go into the Canonical store for people to get them? Or can I just serve a snap on my website? (And how do updates work, then?) [15:07] ogra_, hrm. really? that's a bit poor :( [15:07] aquarius: goes in the store [15:07] QUESTION: is it possible to snap android games? even if you have to include the kernel [15:07] brokemeeleg, you wouldnt have to include the kernel ... but the whole jvm [15:08] ogra_: omg! it is possible! :D [15:08] (if you can make it work with the display there is surely nothing stopping you though) [15:08] cool [15:08] QUESTION: there is a certain "runtime" that my app is allowed to assume exists. How can I find details of this, and what are your policies around changing the runtime, adding new things to it, removing things from it, versioning it, deprecating existing parts of it, and so on? [15:08] brokemeeleg, also, clicks are one evolutionary step before snaps :) [15:09] QUESTION: Does this mean that snaps are completely isolated? | What about apps that rely on stuff like X for keyboard input? | Does this also mean that snaps don't need to ask for passwords when they are installed? | Are snaps only allowed to be installed from controlled sources? [15:09] QUESTION: does snappy works on windows 10? [15:09] snaps are the next iteration [15:09] ogra_: click v2, got it [15:09] Hi. Missed the start of the talk. Is this going to run X apps on X, rather than on Mir? Doesn't this negate the security advantages being promoted for Mir? Surely snaps cannot be trusted in a X environment? [15:10] It will be possible to keep the fglrx drivers with 16.04? [15:10] QUESTION: Is it possible to create a snap of a windows application running in WINE ? [15:10] mcphail, Javo please make sure to prepend the text 'QUESTION:' before your questions. [15:10] QUESTION: will multiple developers, like a team, be able to work on the same Snap? [15:11] I missed the 5 minute sales pitch too. Is it sort of like virtualenv in Python world? [15:11] QUESTION: Hi. Missed the start of the talk. Is this going to run X apps on X, rather than on Mir? Doesn't this negate the security advantages being promoted for Mir? Surely snaps cannot be trusted in a X environment? [15:11] om26er: ta! === chihchun is now known as chihchun_afk [15:11] QUESTION: I'm running snappy core on a RasPi2, and currently there's no Mir or X support (to my knowledge). Will there be (or is there) some sort of desktop environment for snappy core? [15:11] QUESTION: when will the phones be snapped? [15:11] QUESTION: are you seriously suggesting that if I snap anything that I didn't myself develop, that I have to invent a new name for it and not name it after the project? I make a snap of ffmpeg and I shoudl call it "stuarts-ffmpeg", so nobody can find it? Are you planning on namespacing by uploader, or similar? [15:12] hey beuno :) [15:13] QUESTION: does the snappy runtime environment still "cd" to the install directory before running the binary? This is annoying if you pass a relative path as a parameter for the binary. Is there a workaround for that? [15:13] here is the thing ^^ [15:13] QUESTION: what is the eta for diff based updates between two snaps versions ? [15:14] ahem. If you need to "inspect" a snap to confirm that it's properly confined, then your confinement needs fixing. The whole point of confinement is that it confines my app whether I want it to or not :-) [15:14] aquarius, but something needs to check if you try to break out of that [15:15] and that happens during store upload [15:15] QUESTION: Once I upgrade to 16.04, what will it take to switch a particular package to a snappy version, and will the original still exist on the system? [15:15] ogra_, certainly, but it needs to check *at runtime*. Not at upload time. [15:15] the speed of updates is why I am interested in Snappy. :) Waiting 2 years for replies on Launchpad has not been fun. :) [15:16] ogra_, there's been a bunch of talk about how snappy might show up on other distros. You can't imagine that, say, Red Hat are gonna ship a thing where software uploads are controlled by Canonical :) [15:16] aquarius, bahm you think they wont collaborate ... evil guys :P [15:16] ogra_, I think they'll be happy to collaborate. "We run a store, and you are allowed to access it" is not collaboration ;) [15:17] pfft :) [15:17] also, if I ship a drone which can install snaps, I want it to access *my* store. Not Canonical's. :) [15:17] you can have your store inside the cnaonical store server [15:17] aquarius, we provide brand-stores :) [15:17] how generous of you :) [15:18] QUESTION: should a python binding to something like libgphoto2 include what it is binding in the snap package too (in addition to the python code)? [15:18] so the honest policy is: everything goes in the Canonical store, and if you don't wanna be in that store, you're on your own. OK [15:18] aquarius, correct [15:18] cheers for clarifying! [15:18] I didn't realise that :) [15:19] beuno, would we provide a redhat branded store (for aquarius' rpm re-packs ) ? :) [15:19] Sounds good, thanks. [15:19] question above about runtimes and the deprecation policy still stands, though; I want to know that my snap will keep working even after you change the runtime, because you release runtime 1.1 and runtime 1.0 is still on peolpe's machines. :) [15:20] aquarius what runtime? your snap will have the runtime [15:20] sergiusens, libc ? [15:20] yeah [15:20] sergiusens, you must provide *something*. [15:20] only snappy itself [15:21] right, 16.04 ubuntu-core is api/abi stable which would be the "runtime" [15:21] QUESTION: Can other distributions run an implimentation of the snap concept. If they did is there a scenerio that multiple distros could run the exact same snap package. [15:21] libc. ldd. X. etc. What's in "16.04 ubuntu-core"? Where's that documented? [15:21] you can ship your own of everything ... including your opwn libc ... or your wine wrapper for your free windows app :) [15:22] QUESTION: what if someone were to install a DEB for an app and then a SNAP becomes available? Will there be a process for SNAPs to overwrite the DEBs or would it be a case of "uninstall DEB and install the SNAP"? [15:22] aquarius, ubuntu-core contains everything to manage the snaps ... nothing more [15:22] execution happens inside the confinement ... with whatever you ship inside there [15:22] ogra_, so... I don't have a pty? :) [15:22] QUESTION: how will snappy/snaps work with different users on a system? Will the same snap have to be installed repeatedly for example? [15:23] lots of good questions from everyone! [15:23] ogra_, I can't assume that X is present, so I have to ship my own X server? Etc. [15:23] aquarius, correct ... you would need an interfaces stanza in your snap.yaml to even allow that ... and the user would have to confirm access to it on first run of the app [15:23] (the pty that is) [15:23] (no idea about how we interface with X actually) [15:24] ogra_, see, this is what I want you to have an idea about, and document it somewhere ;) [15:24] not me :P [15:24] but yeah :) [15:25] and remember that I'm a phone app developer, so I've seen the existing components stuff and how the version numbering has worked or not worked; I would like there to be documentation on what you promise about version numbers, how long before you remove an interface will you mark it as deprecated, etc [15:25] hi guys :D.. I have a question. I need to install a browser plugin I made. Is it posible with snaps? [15:26] all good, thanks [15:26] QUESTION: LTS vs Non-LTS? How will the current 6 month release cycle be affected by Snappy? If Snappy is on 16.04 LTS then the biggest reason for users to jump is gone. [15:26] QUESTION: what does "reserved" mean under Usage in an interface definition, such as https://developer.ubuntu.com/en/snappy/guides/interfaces/ ? Does that mean that releasing an app with any "reserved" interface will need explicit manual approval, or something else? [15:27] Nice, David answered a question that I hadn't considered but very important. Thanks for that. :) [15:27] beuno: MS says they'll update to 16.04 as part of their summer update. So whatever they define as "summer". [15:27] wine apps should definitely be possible ... [15:28] you might need to jump through some hoops though [15:28] "Let us know" I like that answer. [15:28] lol [15:28] summer has just ended, winter is comming! [15:28] sergiusens, wrong side of the world :P [15:28] sergiusens, I wish [15:28] just move north and you keep summer ;) [15:28] * sergiusens notices that Game of Thrones is aligned with the southern hemishpere [15:28] the show, not the books :-P [15:28] so summer in Washington state. :) [15:29] QUESTION: I am devloping a browser plugin for firefox. The plugin starts another local app of mine. It is posible to package this too apps in a snap? I think the problem is the plugin [15:29] are we meant to call the desktop we're all using "classic Ubuntu" now? :-) [15:29] this two apps!!! not too! :D [15:29] aquarius ask zyga or jdstrand on #snappy for a detailed answer to the `reserved` question [15:30] QUESTION: for an application like a photo importer, where you want the user to be able to save photos pretty much wherever they have write-access on the file system, how will the confinement policy affect that? [15:30] ogra_ wine apps might just work if they are "bottled" up correctly [15:30] *burp* [15:30] :) [15:30] almejo: FlashGot addon :) [15:30] MichaelTunnell, you're welcome :) [15:31] Mir is definitely planned ... [15:31] at least for kiost apps [15:31] *kiosk [15:31] sergiusens, basically everything except network access is "reserved", so if that's manual review, then that's a really important point; in particular, manual review hasn't worked well in the past, and I think that'll be important for people to know if they might have to wait three months for a review. So this seems like a business thing that olli would know, rather than a deep technical question for jdstrand [15:31] aquarius, as I said, we'll be flexible for now [15:32] * ogra_ pokes beuno and watches him wobble [15:33] MichaelTunnell: flashgot? isnt it a downloader? [15:33] beuno, yeah, but I don't know if that means "permissive" or "capricious" :) Does "flexible" mean that all this stuff just gets automated review, or is there a manual queue involved? [15:33] aquarius, permissive :) [15:33] almejo: FlashGet is a downloader FlashGot is an addon in Firefox that allows you to integrate with other applications on a system. [15:33] on a per-interface basis [15:34] I use it for my app. It's pretty cool. [15:34] almejo: FlashGot is a terrible name, yes. :) [15:34] beuno, ok (I think it's entirely fair to take a closer look at a snap which wants permission to edit other snaps, for example). It would be good to document this. [15:35] aquarius, that wont happen [15:35] beuno, no, no, hang on, this is not a fork! I'm not talking about me forking ffmpeg! [15:35] one snap cant really manage another snap [15:35] I'm making a snap of it becuase the upstream project haven't decided to do so [15:35] ogra_, there is a specific snap-control permission precisely for it ;) [15:35] aquarius: try FFJPEG [15:36] aquarius, i dont think that is for one snap contolling the other ... (ICBW) [15:36] aquarius, well, technically, anything that isn't upstream is a fork :) [15:36] aquarius, check out lp:snappy-playpen :) [15:36] ogra_, "Can manage snaps via snapd.", so perhaps it's for an app pretending to be gnome software centre :) [15:37] aquarius, ah, well, that means your snap has a REST api that snapd will expose [15:37] for conmfiguration etc [15:37] beuno, true, but I'm talking here about things that I'm snappifying because upstream haven't yet, not because I want to compete. :) Is there a mechanism for transferring snap ownership between accounts? (There isn't for clicks, I don't believe.) [15:37] I think this is not the right channel for this kind of questions... which one should i go [15:37] hey guys ^^ [15:37] ? [15:38] almejo: #snappy [15:38] aquarius, yeah, we have ways to re-assign [15:38] aquarius, that use case is what we'd really like to help people with [15:38] QUESTION: if I install five different versions of inkscape as snaps, and then type "inkscape" in a terminal, which one runs? Is there some sort of Debian-ish "alternatives" approach? [15:38] the official one [15:39] all others would be inkscape.foo [15:39] changing the package manager is a good idea because its in general good to try new things(innovation) [15:39] aquarius, they will all be called different things, given we won't have actual namespaces for a while [15:39] ogra_, ^ [15:39] ah [15:40] * ogra_ is still thinking the "old" way from last weeks snappy :P [15:40] He's talking about the OS Snap. [15:40] how will upgrades (between major ubuntu versions) be handled? [15:40] Apps can see anything on the OS Snap, so are we guaranteeing the API of the libs in that snap? [15:40] I heard snappy packs comes with all needed libs, true or false? [15:40] ABI really. [15:40] tedg, the opposite ... [15:41] they cant see anything by default [15:41] ogra_: No, they can see everything in /usr/lib last I checked. [15:41] but not use [15:41] ogra_: So no libc? [15:41] oh, lib ... yeah ... [15:42] but not /dev or /etc or some such [15:42] So we're effectively saying that the OS Snap has an ABI. That's the runtime that aquarius is talking about. [15:42] beuno, I think I'm not explaining this deprecation question correctly. Yes, 16.04 will stay valid. But will 16.10 ship both the 16.04 Ubuntu Core *and* the 16.10 Ubuntu Core? Or will I have to build a new version of my app for each Ubuntu release? [15:42] /usr/lib and /lib of the OS are indeed in the library path [15:42] (this is my first ubuntuonair visit, thanks for making this!! ^-^!) [15:43] tedg, it doesnt, since it isnt versioned or reliable ... if you are really concerned you should ship your own klibc [15:43] *libc [15:43] beuno, alternatively, you might mean that every Ubutnu release will be built on the same Ubuntu Core as 16.04 from now on, which is also fine, but I bet you're not saying that. [15:44] aquarius, general rule on snappy "dont rely on anything from the OS" [15:44] Unless snapcraft enforces that, effectively all snaps do. [15:44] And snapcraft only filters a fixed list of packages, which includes libc. [15:44] i.e. there is currently a python interpreter inside the OS snap ... but we might just drop it if nothing in snappy depends on python [15:44] So snaps built with debs using snapcraft use libraries in the OS Snap. [15:45] tedg, which apparently might disappear at any time, because you weren't supposed to rely on them :) [15:45] so if you want your snap to actually be independent, you ship *all* deps [15:45] Ubuntu runns 3 package manager now.... (APT, Clickpackages(ubuntu phone apps) snappy) are plans to unify them??? [15:45] all the other reasons are covered by lxd IMO [15:45] QUESTION: Do all these answers also apply to Ubuntu server? [15:45] ogra_: You actually can't effect that list in snapcraft.yaml :-) [15:45] tedg, sure i can [15:46] take a look at the copy plugin ;) [15:46] dshimer, no, to snappy on any ubuntu [15:46] ogra_: Sure, using stage-packages though, which is the recommended way to use debs. [15:46] sure [15:48] thanks for your answer! [15:49] hang on [15:49] every executable in every snap has to have a globally unique name/ [15:49] ? [15:49] not the snap names themselves, but all the executables? [15:49] aquarius, inkscape.binary [15:50] aquarius: package_bin, but if they're the same, then it gets smaller. [15:50] "inkscape" being the unique bit [15:51] Uhm, my understanding was that a snap had to be targetted at a specific version of core, no? [15:51] no [15:51] QUESTION: if 16.04 snap needs GTK 3.18 and 16.10 has GTK 3.20, how would the snap handle the toolkit update [15:51] So you'd need to have a snap for each version of core you wanted to support. [15:51] QUESTION: Is there a setup on the store similar to the click validation for the phone? If a snap fails automatic snap validation, is there going to be a _real_ chance of manual review (as failing clicks don't get reviewed manually) [15:51] tedg, that was my point above :) [15:51] ogra_: Hmm, I thought that was a requirement... [15:51] MichaelTunnell, you bundle GTK into your app [15:52] MichaelTunnell, the snap doesn't "see" what's in 16.04 or .10 [15:52] will snappy eat its own dogfood and become a snap itself? or due to the nature of snappy isolation will it not be possible? [15:52] QUESTION: for a Qt-based application, should the snap include it's own Qt too? [15:52] mcphail, failed clicks indeed can get a manual review, you just have to request it [15:52] olli: beuno so you bundle GTK regardless? [15:52] ngaio, yes [15:52] MichaelTunnell, correct [15:52] olli: No, it can use the /lib and /usr/lib of the OS Snap today. [15:52] oh ok cool, got it [15:52] beuno, thanks [15:53] tedg, right and snapcraft in Z will need to make sure that libs that arent in X have to be shipped [15:53] beuno: not really. That isn't happening in practice as no-one has time [15:53] QUESTION If all dependencies are being included, will this cause 'bloat'' [15:53] if your snap needs a newer libc, snapcraft will have to include it [15:53] mcphail, I'm staring at the queue, it's empty :) [15:53] TonyP, a little bit indeed [15:53] ogra_: So that's why it needs to target a specific version of the OS Snap. It shouldn't make a *big* difference, but it needs to know. [15:53] mcphail, the click/snaps queue, not the deb queue [15:54] QUESTION: does snapcraft create architecture specific binaries? Can I use one snap YAML to create a snap for ARM and x86? [15:54] tedg, no, the other way round :) [15:54] beuno: That's because we are all giving up, and the ultimate answer is always negative as they have failed automatic validation! [15:54] MichaelTunnell, we can expand that in a minute, but effectively, yes :) [15:54] QUESTION: On upgrading, will I have to install snappy, or can I just start "snap installing"? And will available snap packages be easily discoverable? [15:54] mcphail, right. So if it fails the automated tests, it means it usually shouldn't be distributed :) [15:54] dpm :) [15:54] QUESTION: Is the snaps [15:55] awesome! :) [15:55] thanks for answering [15:55] MichaelTunnell, snapcraft doesnt support cross building ... (except for kernel snaps) ... you can use the same snapcraft.yaml across multiple arches but need to build natively on each of them [15:55] beuno: I'm not sure there is a single example of a non-blessed user getting a failing app into the store, which is rather unfair as most of the core apps fail click validation... [15:55] QUESTION: on my xenial system the binaries are in /snap/blah/, but that isn't added to my path, I take it that's a bug? [15:55] jcastro, no [15:56] MichaelTunnell, but the recommended way is to use that single .yaml file with Launchpad's builders to create the snaps for the different arches for you, as you probably don't want to cross-compile locally [15:56] Thats amazing [15:56] ok so it is expected for snaps to just bundle .desktop files? [15:56] ogra_: ideally, yes. practically, no. Because the libs in the OS Snap are usable by apps. Which is fine, but it's important to realize it does create a relationship between the two. [15:56] ogra_: makes sense and yea dpm totally dont want to do it locally :) [15:56] jcastro, no, but /snaps/foo isnt the right path ... [15:57] Arriving late :-( [15:57] Q: Should an entire desktop environment be bundled as a single snap? [15:57] flexiondotorg, to late now, we just re-packed ubuntu-mate in snappy :P [15:57] :-) [15:58] flexiondotorg, i dont think full desktiop envs have been considered yet ... [15:58] there are plans to have library snaps that would provide the lower level to your desktop though [15:58] Cool. [15:58] but thats all not fully fleshed out yet [15:58] So a runtime of sorts? [15:58] right [15:59] And should that just be toolkits and such or include stuff like session managers. [15:59] The former seems cleaner. [15:59] i dont think that has been properly defined yet ... first step is apps [16:00] And promotes potential reuse. [16:00] full desktop env will need more planning [16:00] ogra_, OK. [16:00] Wow! Thanks, this has been great. Can't wait! [16:00] bye and thanks ! [16:00] mhall119: did you already know how to say my name or did you guess? It wasn't perfect but it was surprisingly close. :) [16:01] bye [16:01] best guess, I'm glad I was close :) [16:01] see you all in #snappy! [16:01] :) [16:01] flexiondotorg: they did mention something about it in the terms of reserves [16:02] some things will have exceptions to the confinement like X so maybe DEs could as well once snapped [16:03] I totally want a day where I install Kubuntu and then KDE 5.8 drops and I just download and run a new snap for it [16:03] maybe not GNOME like that though :) [16:05] MichaelTunnell, Thanks. And sf. [16:11] OwnCloud plus snappy makes a lot of sense to me [16:31] flexiondotorg: :) sf [16:45] will run snappy packages in other distro ? === chihchun_afk is now known as chihchun [16:54] sidro: not yet because no other distro has it but in theory yea it could [16:55] but is not docker apps ? [16:55] this packages [16:55] if yes why not ? [16:56] That would be good to see as a user as well [16:56] snappy apps == docker apps ? [17:18] no, because docker is not the same infrastructure and not really that good [17:19] look up all the security and structure problems of docker articles :) sidro [17:41] snappy don't use docker ? [17:44] what framework will use snappy packages ? [17:51] IS snappy an virtual env with minimal OS tree ? [17:51] like an OS chrooted or virtual machine? [17:55] sidro: snappy is a really minimal operating system just enough to get to a command line effectively. Then other snaps then create a usable system so a snap effectively is a debian package only it contains everything it needs to run. [18:01] hah [18:01] is an minimal os in virtual env [18:01] It is a minimal os in virtual env [18:03] are isolated that snaps from other snaps? [18:06] davmor2: more than debian packages but yes essentially [18:06] sidro: snappy is not virtual no [18:06] yes snaps are isolated from other snaps [18:06] you should just watch the Q&A most of that was covered in the video [18:07] sidro: https://www.youtube.com/watch?v=lHO8j8uo5Z4 [18:07] snappy use or not docker ? [18:10] I already answered that, Snappy does not use docker [18:11] ok [18:11] do you know what a DMG file is? [18:11] ok [18:11] I know [18:12] but this have a core OS [18:12] is not like dmg [18:12] need terminal and runc core-os [18:12] need terminal and run in core-os [18:12] this is not like core-os, dmg is not even a Linux thing [18:13] I know [18:13] this is good maybe for a phone os [18:13] or mobile os [18:13] this is good for everything [18:13] for desktop ..... [18:14] I am actually working on something to explain what Snappy is in a broader scope. Subscribe to my YouTube channel if you want to watch it. http://tuxdigital.com/youtube [18:14] but in the meantime the Q&A from today is linked above [18:14] ok [18:33] I share a video MichaelTunnell [18:33] I like apt [18:33] :) thanks === howefield is now known as howefield_afk === Richard is now known as Guest44241