[02:15] -SwissBot:#ubuntu-news- ::Planet:: Lubuntu Blog: Lubuntu Development Newsletter #9 @ https://lubuntu.me/lubuntu-development-newsletter-9/
[02:16] <tsimonq2> >_>
[02:17] <tsimonq2> krycek: Ooh ooh ooh, can it be included?
[02:18] <krycek> Yeep, already noticed - and since it's way in time, of course!
[02:18] <tsimonq2> ...but it's always on time. :D
[02:18] <krycek> Yes, on yours.. :P
[02:19] <tsimonq2> Is there any other time? ;)
[02:19] <krycek> "Woop, we forgot - sooorry!"
[13:15] -SwissBot:#ubuntu-news- ::Planet:: Valorie Zimmerman: Akademy: closing time @ http://linuxgrandma.blogspot.com/2018/08/akademy-closing-time.html (by<EMAIL_ADDRESS>(Valorie Zimmerman))
[14:11] -SwissBot:#ubuntu-news- ::OMG!Ubuntu:: Linux Release Roundup: Communitheme, Cantata & VS Code @ https://www.omgubuntu.co.uk/?p=134352 (by Joey Sneddon)
[14:29] -SwissBot:#ubuntu-news- ::Planet:: Ubuntu Podcast from the UK LoCo: S11E23 â Twenty-Three Tales - Ubuntu Podcast @ http://ubuntupodcast.org/2018/08/17/s11e23-twenty-three-tales/


[13:58] <xnox> Hello
[13:58] <cjwatson> Dia dhuit
[13:59] <xnox> cjwatson: how to best do google doc presentations?
[13:59]  * xnox is doing it via screenshare so far
[13:59] <sil2100> o/
[13:59] <cjwatson> Not sure, I expect I'll find out tomorrow
[13:59] <cjwatson> I think I used screenshare last time ...
[14:00] <xnox> where are hangout urls in this thing?
[14:00] <xnox> or i don't think people want to join, as it's a presentation
[14:00] <cjwatson> Even with a presentation sometimes it's easier to take questions with people on a hangout
[14:00] <cjwatson> Since youtube lag
[14:01] <xnox> https://docs.google.com/presentation/d/10SbMhkHuTpgVEncv8Fp_A8is0stDKwuMiCAYEFNiw40/edit?usp=sharing
[14:18] <xnox> Question time =)
[14:19] <xnox> I know there are at least 7 live viewers and a few people here =)
[14:19] <cjwatson> (The stream has caught up with your request for questions)
[14:19] <sil2100> No questions from my side, it was a nice overview of the process :)
[14:19] <xnox> cjwatson: yeap, quite a lag
[14:20] <xnox> sil2100: cool.
[14:20] <cjwatson> OK, I'll hop over and see what's going on elsewhere then :)
[14:20] <cjwatson> Thanks
[14:20] <xnox> Btw, sil2100 will be participating in the next session in community-1 talking about CI-train / merge-proposals and etc =)
[14:56] <xnox> cjwatson: yeah screenshare is the only way to "present" the presentation. The "drive" app in the hangout is for collaborative editing of the documents inside the hangout, it's not for "on-air" presenting.
[14:56] <xnox> i think for next session, i'll join into the hangout from another hangout to act as the "presenter screen"
[15:17]  * dbarth waves
[15:17] <dbarth> please prefix you questions with QUESTION
[15:17] <dbarth> and we'll take them in order
[15:18] <ogra_> QUESTION: will the new header be "suppressable" for webapps that use their own header already ?
[15:18] <ogra_> (like 80% of the ones we have today)
[15:23] <ogra_> thanks ! that answers my question
[15:24] <dbarth> yw :)
[15:57] <asac> o/
[15:59] <ogasawara> yo, just waiting for the crew to file into the hangout...
[16:00]  * rsalveti waves
[16:07] <asac> yes
[16:07] <asac> it works
[16:07] <barry> yes
[16:07] <dholbach> go go go! :)
[16:07] <fossterer> We can hear you
[16:07] <dholbach> lag of 10s ;-)
[16:07] <arges> that plant dancing in the background is hilarious
[16:07] <zyga> ogasawara: ack
[16:07] <xnox> ogasawara: I thought you would finish "good morning, good afternoon, good evening wherever you are" with "this is the BBC world service" cause they always use that phrase with "wherever you are"
[16:32] <asac> cant see the slide :)
[16:32] <asac> ogasawara: ^
[16:32] <dholbach> no, keep the "phonedations team" name!
[16:33] <ogasawara> asac: thanks
[16:33] <asac> hmm. still not, but guess its lag
[16:33] <asac> ah now!
[16:33] <asac> thanks!
[16:33] <ogra_> thats dholbach's fault ... he did set the lag above
[16:33] <ogra_> :)
[16:34] <dholbach> ogra_, and I thought there'd be one day where I'm not trolled by someone :-P
[16:34] <asac> never!
[16:34] <dholbach> not with ogra_ around :-P
[16:34] <ogra_> haha
[16:36] <xnox> OMG, I have MMS =)
[16:36] <xnox> *hate
[16:37] <ogra_> xnox, sending a UPS parcel is cheaper in germany :)
[16:38] <xnox> ogra_: and it actually may arrive!
[16:38] <ogra_> ++
[16:38] <xnox> ogra_: i once sent an MMS, which arrived as an SMS with a url to open on the other end.
[16:38] <ogra_> haha
[16:38] <xnox> ogra_: cause the receiving operator did not support delivering MMS at all!
[16:39] <ogra_> yeah, MMS are actually SMS with a download link ... but you usually have a provider proxy that hands you the data then
[16:39] <ogra_> via the shipped URL
[16:40] <ogasawara> asac: can you see ev's slides?  just want to make sure
[16:41] <asac> ogasawara: yes :)
[16:41] <ogasawara> thanks
[16:41] <cjwatson> xnox: sometimes you get a URL, sometimes you get raw control metadata on your screen
[16:41] <cjwatson> it's awesome
[16:43] <xnox> cjwatson: =))))))
[16:43] <cjwatson> to be fair that last has only happened to me once
[17:00] <asac> thanks ogasawara slangasek ChickenCutlass ev!! awesome!
[17:00] <asac> ogasawara: you think we can link the slides from the youtube video description?
[17:00] <asac> ogasawara: and insert links to the start of each team for convenience?
[17:00] <asac> dholbach: who can edit those video descriptions?
[17:00] <asac> http://www.youtube.com/watch?v=d5AjUo9K-yQ
[17:00] <ogasawara> asac: hrm, not sure
[17:01] <ogasawara> asac: I'm planning at the very least to link the decks from the description in summit.ubuntu.com
[17:01] <asac> right. think for the world the video descriptio would be better
[17:01] <asac> :)
[17:01] <asac> let me try to find out
[17:17] <dholbach> asac, whoever kicked off the hangout - it's in their youtube channel AFAIK
[17:54] <dpm> pitti, I'm not sure if anyone else is going to, but I can start the hangout
[17:54] <pitti> dpm: ok; you'll just toss the URL here?
[17:55] <dpm> yeah
[17:55]  * ogra_ has some bandwith issues today and will follow via IRC
[17:56] <dpm_> hi everyone, here's the hangout URL for the langpacks session for anyone wanting to join: https://plus.google.com/hangouts/_/hoaevent/AP36tYcxsbVRdlmAOBPlxgkDxqUqcnxSlHfEMOMlyeuQpxURZHb84A
[17:59] <dpm_> seb128, here's the hangout link https://plus.google.com/hangouts/_/hoaevent/AP36tYcxsbVRdlmAOBPlxgkDxqUqcnxSlHfEMOMlyeuQpxURZHb84A
[17:59] <dpm_> http://pad.ubuntu.com/uos-1406-development-1406-touch-language-packs
[18:00] <ogra_> thats an evil color you have
[18:00] <ogra_> :)
[18:01] <dpm_> http://pad.ubuntu.com/uos-1406-development-1406-touch-language-packs
[18:06] <GunnarHj> Anybody who could provide the link to the hangout?
[18:06] <ogra_> https://plus.google.com/hangouts/_/hoaevent/AP36tYcxsbVRdlmAOBPlxgkDxqUqcnxSlHfEMOMlyeuQpxURZHb84A
[18:07] <GunnarHj> ogra_: Thanks!
[18:07] <ogra_> pitti, pfft ... developers are on tehir own :P
[18:09] <ogra_> dpm_, pitti, the rw mode is kind of a developer mode anyway ... dont worry to much about it
[18:09] <pitti> ogra_: *nod*
[18:09] <pitti> just mentioning it for completeness
[18:09] <ogra_> ++
[18:10] <ogra_> GunnarHj, notes are at http://pad.ubuntu.com/uos-1406-development-1406-touch-language-packs
[18:10] <seb128> ogra_, don't hate on developers!
[18:10] <ogra_> haha, i dont
[18:10] <ogra_> but i expect them to be capable of working with LANG=C
[18:11] <seb128> sure they are
[18:11] <ogra_> (apart from the french ones perhaps :P )
[18:11] <seb128> but if you keep using that argument, it means devs are going to need 150 manual steps to make the system usable for their usecase
[18:11] <seb128> which is quite a step back from what we have today
[18:11] <dobey> QUESTION: will we also include the spelling/grammar dictionaries, and keyboard layouts with the lang packs?
[18:12] <ogra_> seb128, there will be a UI option to enable adb ... and there will be a switch to ubuntu-device-flash to install with dev mode and writability
[18:12] <ogra_> dobey, currently these come as deps of the OSK
[18:13] <dobey> ogra_: right, but do those aling with the 20+ languages that are >50% coverage?
[18:13] <dobey> align even
[18:13] <asac> ogasawara: seems you should be able to change video description etc.
[18:13] <asac> oh sorry if there was a sesion :) ... ignore
[18:13] <ogra_> dobey, not atm ... up to us to align the seeds
[18:13] <ogasawara> asac: ack, I'll investigate
[18:14] <ogra_> pitti, we dont care about anything that is not UI
[18:14] <seb128> ogra_, that is again a shortcoming when you think about convergence
[18:14] <ogra_> seb128, i think about RTM only currently
[18:14] <seb128> ogra_, we should design something that's futurproof
[18:15] <ogra_> seb128, i agree but for RTM (which is essentially also 14.10) we can easily go with seed syncs
[18:15] <dobey> yeah, it would be nice to have some way to install additional languages, without having to totally break the phone to do it
[18:15] <seb128> ogra_, are we discussing RTM or futur there?
[18:15] <ogra_> dobey, you wotn be able to if they are deb
[18:16] <ogra_> seb128, no idea ... i thought 14.10
[18:16] <dobey> ogra_: yes, i know that. but i think we need to solve that
[18:16] <ogra_> dobey, right, see my comment on the notes
[18:16] <dobey> whether or not it is done for RTM is separate from how we get there
[18:16] <ogra_> if we want to be able to update/install individual langs they must be click
[18:16] <dobey> what is the pad url?
[18:17] <ogra_> http://pad.ubuntu.com/uos-1406-development-1406-touch-language-packs
[18:17] <infinity> pitti: I've missed half this session, but are you considering having another lookup location?
[18:17] <pitti> infinity: for a world where we want language-pack-gnome and language-pack-touch installable side by side this seems like the best solution indeed
[18:17] <infinity> pitti: Cause we could just have glibc have another lookup location, and clickify touch langpacks to install to a click-friendly location, and not ship desktop langpacks at all.
[18:18] <seb128> infinity, what for? somewhere in a system-image rw location you mean?
[18:18] <pitti> for now they just Conflicts: each other
[18:20] <dpm_> pitti, https://wiki.ubuntu.com/Translations/TemplatesPriority
[18:20] <dobey> how often do we need to update translations separate from the packages that own those translations now?
[18:20] <pitti> infinity: we haven't talked about click at all yet
[18:20] <pitti> (and I don't think langpacks would be a particualrly good idea for them)
[18:21] <dobey> could we just get rid of langpacks, and include all the translations directly in the packages?
[18:21] <infinity> pitti: Well, click seems like the obvious choice for people wanting to install more language support.  Android usually doesn't ship with all translations either.
[18:21] <ogra_> pitti, it think they would
[18:21] <ogra_> (thats why i added that to the notes too)
[18:21] <ogra_> at least if you want to be able to update them out of the system image
[18:22] <pitti> infinity: oh, you mean langpacks AS click packags, not FOR
[18:22] <dobey> ogra_: i'm less concerned about updating, than wanting to use a language that is available, but not on the image
[18:22] <infinity> pitti: Right!
[18:23] <ogra_> dobey, well, at the size that pitti can squeeze them we could easily ship all we have
[18:23] <infinity> pitti: So, the argument for having langpacks out of band (as click) is so that we don't actually have to ship them all.
[18:23] <dobey> ogra_: right. so why have lang packs at all? :)
[18:24] <ogra_> dobey, ?
[18:24] <pitti> infinity: right, and we can certainly keep that idea
[18:24] <ogra_> infinity, but the touch only ones are really small
[18:24] <dobey> ogra_: if we are going to ship all the translations anyway, why have langpacks?
[18:24] <ogra_> dobey, maintenance reasons
[18:24] <ogra_> you could as well just have one giant one
[18:24] <dobey> ogra_: it seems like having langpackas is more work, not less
[18:24] <seb128> dobey, that's how we land updated translations
[18:25] <seb128> on the system image
[18:25] <seb128> which is then shipped to users
[18:25] <dobey> the problem with the current langpacks is that they have lots of things we don't have on the phone
[18:25] <ogra_> dobey, we have an infrastructure
[18:25] <ogra_> dobey, do you listen to the hangout ?
[18:25] <pitti> dobey: not the language-pack-touch-* ones, they have exactly the stuff that's on the image
[18:25] <ogra_> the touch ones are stripped for touch only stuff
[18:25] <dobey> ogra_: yes
[18:25] <pitti> and we can avoid shipping really badly translated languages with that, too
[18:25] <ogra_> they dont ship anything we dont need
[18:25] <pitti> i. e. "most"
[18:26] <dobey> ogra_: those are on the phone already?
[18:26] <dobey> ogra_: i'm talking about a different solution to -touch only langpacks (by just not having langpacks)
[18:27] <infinity> pitti: So, if the touch ones are super tiny and no one cares about us shipping all of them, whether they're click or deb is a less interesting discussion, perhaps.
[18:27] <ogra_> dobey, we ship 6 languages atm
[18:27] <ogra_> due to space constraints
[18:27] <ogra_> with the touch packs we will be able to ship all
[18:27] <infinity> pitti: But giving them another path and extending the glibc lookup patch makes sense, so someone flipping a phone to r/w and then wanting to install a full langpack won't end up with a conflict they need to resolve.
[18:27] <dobey> ogra_: i feel like we are talking past each other :-/
[18:27] <infinity> Assuming those lookups aren't hideously expensive...
[18:27] <ogra_> infinity, we should definitely make them co-installable
[18:28] <ogra_> dobey, we can not not have langpacks
[18:28] <pitti> infinity: well, "super tiny" is an exaggeration, they are ~ 800 kB each (.deb size)
[18:28] <dobey> ogra_: why not?
[18:28] <ogra_> dobey, unless we are inventing a completely new infra
[18:28] <pitti> uncompressed ~ 3 MB
[18:28] <infinity> pitti: Oh.  That's pretty huge, IMO.
[18:28] <dobey> ogra_: there's nothing to invent
[18:28] <infinity> pitti: So, install-on-demand as clicks would make a lot of sense, in that case, IMO.
[18:29] <ogra_> dobey, our current infra creates them automatically from translations
[18:29] <dobey> ogra_: yes. but disabling the langpack magic just means putting the translations in the binary packages that own them instead
[18:29] <ogra_> infinity, all of them will be like 50-60M vs 150M for six lands we whip today
[18:29] <ogra_> *langs
[18:29] <pitti> infinity: well, the current packs are ~ 30 MB uncompressed :)
[18:29] <pitti> (per language)
[18:30] <ogra_> dobey, oh, *thats* what you mean
[18:30] <infinity> ogra_: Sure, but I'm all for shrinking further.
[18:30] <ogra_> dobey, that wont work in convergence
[18:30] <dobey> ogra_: why not?
[18:30] <ogra_> infinity, yeah, i wouldnt mind having them as clicks
[18:30] <dobey> it worked perfectly fine before we had langpacks :)
[18:30] <seb128> ogra_, pitti: we should keep in mind that langpacks are likely to increase over time, as our softwares become more complete
[18:30] <asac> (joining late) i believe click packages should ship languages on their own and if they get too big, the store should grow support for hosting translations and shipping translations for apps :) - maybe store could offer community translationm feature as a big +1 over apple/android
[18:30] <ogra_> dobey, right, but your desktop langpacks wont be able to update your translations after release
[18:31] <ogra_> asac, not talking about apps here
[18:31] <asac> ogra_: the youtube channel talks about click though?
[18:31] <dobey> ogra_: they would update the same as they would update on the phone
[18:31] <ogra_> asac, taalking about the mechanism to ship languages
[18:31] <ogra_> asac, click vs deb
[18:31] <asac> ah
[18:31] <asac> :)
[18:31] <seb128> asac, right, but that's translations for the default image
[18:31] <seb128> not for clicks
[18:31] <asac> seb128: well, there is an overlap. we hav clicks in defult image too
[18:31] <ogra_> dpm_, ++
[18:31] <ogra_> sounds good
[18:32] <seb128> well, "default image, deb+click+whatever else"
[18:32] <asac> seb128: imo those should use the same mechanism as the other clicks
[18:32] <ogra_> asac, and the langpacks ship their translations currently
[18:32] <asac> seb128: right, but if we invent something for those clicks that ship on image, its not good. we should invent something for all clicks :)
[18:32] <pitti> infinity: the lookups aren't trivial, given that clicks can live in a lot of places, but computing based on argv[0] and its path should hopefully be doable?
[18:32] <ogra_> asac, right, but i dont think this is about click translations at all atm
[18:32] <asac> ogra_: right, thats a bandaid, but feel we need a click translation story :_) ... anyway, if thats not on topic i will wait :P
[18:32] <ogra_> just about the default langs we ship
[18:33] <ogra_> dpm_, yes, i was referring to RTM
[18:33] <asac> again, i dont think thats an independent topic as we ship clicks by default :P
[18:33] <dobey> pitti: i don't understand what you're asking about with that argv[0] comment
[18:33] <infinity> pitti: Well, we should be able to install to a well-known-path, I'd assume.  Unless we also want third-party langpacks, which seems a bit potentially scary.
[18:33] <dpm> ogra_, ack, cool
[18:33] <ogra_> asac, right, but we dont have anything for click translations yet
[18:33] <asac> i will put that on beuno's list :) ... one sec
[18:33] <ogra_> :)
[18:33] <asac> lol
[18:34] <ogra_> click does not know dependencies
[18:34] <infinity> pitti: Ahh, I hadn't thought about wordlists and such.
[18:34] <ogra_> pitti, ^^
[18:35] <ogra_> *everything* (wordlists, translations, kbd layouts) would have to be inside the language click
[18:35] <ogra_> pitti, OSK uses hunspell
[18:35] <pitti> infinity: how can click install into a well-known path?
[18:35] <pitti> ogra_: thanks
[18:35] <ogra_> for word suggestions
[18:36] <pitti> ogra_: so we need to pre-install a reasonable set of  hunspell-*
[18:36] <ogra_> yes :(
[18:36] <infinity> pitti: I've never looked at the implementation, but I assume clicks install to sane paths, somehow?
[18:36] <ogra_> the kbd language packages depend onthat
[18:36] <dobey> pitti: it can't. it can only install to /opt/click.ubuntu.com/${package_name}
[18:36] <infinity> pitti: Like com.canonical/langpack-foo or whatever?
[18:36] <ogra_> dobey, preinstalled clicks can install differently
[18:37] <infinity> dobey: That sounds like a well-known path to me.
[18:37] <dobey> ogra_: they install to /usr/share, but updates to go /opt/click.ubuntu.com/
[18:37] <ogra_> oh, right
[18:37] <dobey> infinity: one well-known path per language
[18:37] <pitti> infinity: oh, you mean within the click pkg namespace, yes
[18:38] <infinity> pitti: So, I guess to make that work, you'd also need a hook that creates a link farm to somewhere else, so we wouldn't have to walk that whole namespace.
[18:38] <infinity> pitti: So, yeah, interesting thought exercise, probably not worth it for RTM.
[18:38] <dobey> infinity: yeah, a hook could handle creating symlinks inside a well-known path
[18:38] <dobey> infinity: that also opens up the can-of-worms of third-party langpacks, though :)
[18:39] <infinity> dobey: Does the click infra have no provision for validating origin? :/
[18:39] <dobey> infinity: not at the moment. don't know when we'll get signed click packages
[18:39] <infinity> Whee.  Fun.
[18:40] <dobey> infinity: you could hard-code the namespace to be "com.ubuntu.langpack" or whatever, and only create symlinks for languages in packages under that namespace though
[18:43] <ogra_> seb128, pitti, even if we provided click packages for them we would need to initially ship them
[18:43] <ogra_> (like we do with the other preinstalled clicks)
[18:43] <seb128> ogra_, why?
[18:44] <seb128> ogra_, we could do "install spell suggestion from the store" and send people to the click lens or something
[18:44] <ogra_> seb128, youwill likely run the welcome wizard in the right language
[18:44] <asac> thats a factory thing
[18:44] <asac> factory install
[18:44] <ogra_> *before* connecting to WLAN or creating the U1 account
[18:44] <seb128> ogra_, we are discussing spell checking there
[18:44] <seb128> not language
[18:44] <ogra_> oh, sorry
[18:44] <infinity> ogra_: The welcome wizard can't know what language you speak before you tell it, but it would also ship with all translations unstripped, I'd assume.
[18:45] <ogra_> infinity, perhaps ...
[18:45] <pitti> so if spell checking is working already, then that means we are shipping at least some (my|hun)spell-XX packages, no?
[18:45] <ogra_> but it will fork out into apps too
[18:45] <infinity> ogra_: Anything that leads you to how to install a new language always needs to be unstripped, this isn't a new concept. :P
[18:45] <ogra_> like the WLAN dialog
[18:45] <asac> some languages should be installed by default though
[18:45] <ogra_> or the U1 account setup
[18:46] <ogra_> asac, if we can fit them, *all* languages should be installed by default IMHO
[18:46] <asac> nah
[18:46] <seb128> ogra_, do you know if the current touch image includes hunspell binaries?
[18:46] <asac> just the most common ones. the rest is a factory problem
[18:46] <seb128> or myspell ones
[18:46] <ogra_> seb128, yes, it does
[18:46] <seb128> which ones?
[18:46] <ogra_> hmm
[18:46] <asac> infinity: you can guess  language from the way people look. i swear i can recognize how the french look :P
[18:46] <asac> lol
[18:47] <infinity> asac: That's just because you're German, and all French people look frightened to you.
[18:47] <dobey> lol
[18:47] <asac> hehe
[18:47] <ogra_> seb128, http://paste.ubuntu.com/7629917/
[18:47] <seb128> pitti, dpm ^
[18:47] <ogra_> pulled in by the kbd packages
[18:48] <seb128> ogra_, thanks
[18:50] <pitti> ogra_: ah, thanks; so we are missing spanish and maybe a few others
[18:50] <ogra_> yep
[18:50] <ogra_> not sure why they are not there
[18:50] <dobey> let's just build different system images for different languages
[18:50] <ogra_> we surely ship the matching kbd packages
[18:50] <pitti> not sure why we need fr-classical
[18:50] <dobey> ubuntu-device-flash --language ja_US
[18:50] <seb128> dobey, not an option
[18:50] <infinity> dobey: That's a nightmare to QA, which is why we don't do it for desktop ISOs.
[18:51] <dobey> i was being facetious :)
[18:52] <ogra_> thanks !!
[18:52] <ogra_> :D
[18:53] <dobey> but it does get us the smallest images, available for the most languages :)
[18:53] <dpm_> thanks everyone!
[18:53] <pitti> thanks folks
[18:55] <ogra_> asac, can we just move dobey to QA to implement that ? :P
[18:57] <pitti> dpm_: I put the gist into the BP whiteboard
[18:58] <pitti> dpm_: will you target that to utopic/milestone/etc, so that it appears properly on status and +upcomingwork?
[18:59] <pitti> dpm_: I put it to 14.06 for now
[18:59] <dpm> awesome, thanks pitti
[18:59] <asac> ogra_: who is dobey reporting into?
[18:59] <ogra_> dunno
[19:00] <asac> ogra_: if he is somewhere under olli then its easy :)
[19:00] <pitti> it's mvo TV!
[19:00] <mvo_> click for the desktop is at https://plus.google.com/hangouts/_/hoaevent/AP36tYdXzLigR8oAWSWyhsXq6IW0UXY4aBx8mc_bgDL1Kyj5sUb2iA?authuser=0&hl=en
[19:00] <asac> dobey: just kidding btw
[19:00] <pitti> mvo_: is that supposed to be live already? :-)
[19:00] <mvo_> pitti: yes, was testing but I stoped it now again
[19:01] <mvo_> eh, how can I start it again?
[19:01] <mdeslaur> mvo_: you're live for me
[19:01] <mdeslaur> oh, gone now
[19:01] <barry> back now
[19:01] <mvo_> can someone join? I feel a bit lonley
[19:03] <barry> the feed is not marked "live" and keeps ending after 1:15
[19:03] <lool> mvo_: perhaps ping the subscribers
[19:03] <xnox> so the link on the summit needs updating
[19:03] <xnox> to the youtube url
[19:03] <xnox> i can join you
[19:03] <lool> barry: ah I guess broadcast was stopped
[19:03] <seb128> yes
[19:03] <seb128> mvo is starting a new one
[19:04] <seb128> you can't start again after stopping
[19:04] <mvo_> lets try again: https://plus.google.com/hangouts/_/hoaevent/AP36tYfd3PMw1nB_D9YbppXQYAASnq1k8GKDuIxM6FGGwOjQPGUAyQ?authuser=0&hl=en
[19:05] <mvo_> hrm, it still says off-air
[19:05] <xnox> mvo_: correct, start it
[19:05] <mvo_> xnox: but how?
[19:05] <seb128> mvo_, you didn't try starting that one yet though?
[19:05] <xnox> mvo_: there is a button
[19:06] <pitti> mvo_: it's live already, we can see you
[19:06] <pitti> on http://summit.ubuntu.com/uos-1406/meeting/22312/development-1406-click-ftd/
[19:06] <seb128> mvo_, weird, the hangout says "off"
[19:06] <dpm> pitti, I think that's a failed old recording
[19:06] <seb128> pitti, that's the recording from the first one?
[19:06] <cjwatson> summit still seems to have the old hangout url
[19:06] <dpm> it's not live
[19:06] <pitti> oh, right
[19:07] <dpm> it's just 1:15 long
[19:07] <xnox> mvo_: http://summit.ubuntu.com/uos-1406/meeting/22312/development-1406-click-ftd/
[19:07] <cjwatson> I got told I was the first one here when I tried it
[19:07] <xnox> STAND BY, restarting soon =)
[19:07]  * sil2100 sigh
[19:07] <mvo_> we should be on air now
[19:07] <dholbach> mvo_, having fun? :-P
[19:07] <sil2100> It seems that this part is not really well supported
[19:07]  * dholbach hugs mvo_
[19:07] <barry> hey, reload!  it's live now (but not feeding yet)
[19:08] <cjwatson> still says first one here for me
[19:08] <cjwatson> could somebody post the hangout url?
[19:08] <barry> \o/
[19:08] <xnox> cjwatson: one sec.
[19:08] <ogra_> https://plus.google.com/hangouts/_/hoaevent/AP36tYfd3PMw1nB_D9YbppXQYAASnq1k8GKDuIxM6FGGwOjQPGUAyQ?authuser=0&hl=en
[19:08] <cjwatson> ta
[19:08] <dholbach> live!
[19:08] <xnox> cjwatson: ^ yeap above is correct.
[19:09] <asac> hmm. the youtube stream isnt online anymore?
[19:09] <xnox> asac: yes it is, it was restarted. You may need to reload the summit page
[19:09] <xnox> Youtube to watch is
[19:09] <xnox> https://www.youtube.com/watch?v=jj8gqeHXwCA#t=100
[19:10] <asac> ah
[19:11] <asac> xnox: thx :)
[19:13] <dobey> or if you load plug-ins
[19:13] <mvo_> if you have questions, please ask them here
[19:14] <mhall119> QUESTION: Why can't we offer Click packages on X11 with a giant "Use at your own risk" disclaimer?
[19:14] <mhall119> it would still be better than telling them to use a PPA
[19:15] <cjwatson> disclaimers don't work
[19:15] <cjwatson> it is always more interesting to get your work done than to care about a disclaimer
[19:15] <mhall119> even when it's not enabled by default?
[19:15] <cjwatson> yes
[19:15] <cjwatson> we talked about this in Oakland and definitively ruled it out :)
[19:15] <dobey> mhall119: clicks can be installed already and run on x11.
[19:15] <mdeslaur> we don't want people to start uploading apps that specifically try and escape confinement with X11
[19:15] <mhall119> but the alternative is still to use a PPA right?
[19:15] <mdeslaur> it would be trivial
[19:15] <dobey> but we don't support it
[19:16] <cjwatson> you can install click packages by hand, but we won't offer any UI for it
[19:16] <cjwatson> on X11
[19:16] <cjwatson> and indeed PPAs work
[19:16] <xnox> mhall119: use ppa and normal deb. There is no gain in using click for an X11 app.
[19:16] <dobey> cjwatson: well, you can run unity8 under x11 and do it (but it's still massively annoying to do); and anyone could easily write an app store app to do it, too
[19:16] <mhall119> could we offer supported click packages from the store if they had the same level of review as deb packages in extras?
[19:17] <mhall119> QUESTION: could we offer supported click packages from the store if they had the same level of review as deb packages in extras?
[19:17] <xnox> mhall119: no, because we don't scale enough.
[19:17] <xnox> mhall119: get your X11 apps into universe.
[19:17] <xnox> mhall119: or a ppa.
[19:17] <cjwatson> it would be better to spend that time on making things work with mir/unity8
[19:17] <cjwatson> it's a LOT of time
[19:17] <mhall119> xnox: that's a good deal harder than making a click package
[19:17] <asac> right. we want to get exactly out of the business provding the middleman service
[19:17] <asac> to review etc.
[19:17] <cjwatson> actually non-trivially expensive
[19:18] <mhall119> cjwatson: my concern is what we do to support 3rd party desktop apps over the next year before Mir replaces X11 as default
[19:18] <cjwatson> multiple full-time people to deliver even a pretty small trickle of review in the grand scheme of things
[19:18] <cjwatson> and we have tried the review path in the past and it has spectacularly not worked
[19:18] <mhall119> yes, I'm painfully aware of that
[19:18] <asac> QUESTION: will we have developer mode that allows to install clicks without trusted signature? if so anyone can just put their click somewhere and doesnt need a ppa/store
[19:19] <mhall119> ^^ that would make me happy
[19:19] <dobey> asac: we already have that. i don't know if we'll provide any UI for it though
[19:19] <xnox> asac: deb based installations are still supported.
[19:20] <xnox> asac: bringing click to the desktop does not exclude running .debs
[19:20] <asac> of course
[19:20] <cjwatson> clicks don't have signatures yet :)
[19:20] <mhall119> but clicks are easier to make
[19:20] <cjwatson> so yes
[19:20] <asac> but i hear that you can install clicks even if they are not in store
[19:20] <cjwatson> you can do this by hand today
[19:20] <asac> so anyone could just ship a X11 app and folks need to disable signature check and can install it. i agree we shouldnt host them in an official place
[19:20] <cjwatson> but I'm not prepared to offer something that will be a malware vector for people
[19:20] <cjwatson> for developers, absolutely
[19:20] <mhall119> cjwatson: from the commandline only though, so it's not an ideal way for a 3rd party dev to distribute to end users
[19:20] <dobey> we don't have signature checks
[19:20] <xnox> mhall119: "clicks are easier to make" -> that's not true =) making binary debs are also easy. (e.g. with dpkg-deb -b)
[19:20] <asac> cjwatson: right. its like "developer mode"
[19:21] <cjwatson> I do not think it is ethical to offer something as a distribution channel to end users that is trivial to turn into a malware channel
[19:21] <asac> ack
[19:21] <cjwatson> for developers testing things I have no issue
[19:21] <mhall119> cjwatson: but if you s/click/deb/ we already do
[19:21] <dobey> xnox: making the metadata to build a deb is harder (especially to do it properly)
[19:21] <cjwatson> mhall119: no, because of the review path
[19:22] <cjwatson> anything that we offer by default in the software centre is reviewed by people in Canonical or in the Ubuntu community
[19:22] <mhall119> sorry, didn't mean to sidetrack the session
[19:22] <xnox> dobey: we are talking about 3rd party debs, they don't have to be policy compliant. And a bunch of third parties provide those.
[19:23] <xnox> dobey: e.g. plex server, google chrome, and a lot of other ISVs provide debs, in simplistic ways without being policy compliant.
[19:23] <dobey> xnox: sadly aware they don't have to be policy compliant. which is why there are so many questions on askubuntu when software-center complains about them :)
[19:23] <xnox> dobey: e.g. CPack from cmake can spit out .debs for you.
[19:23] <dobey> xnox: you're overestimating the ability of 3rd party devs to understand and use cmake or such :)
[19:25] <asac> QUESTION: what is the plan on a build system for open source / distro software that we want to put into a click?
[19:25] <cjwatson> can we table that for later?
[19:25] <asac> (hope thats on topic here even not strictly desktop
[19:25] <cjwatson> I don't think it really fits here
[19:25] <asac> cjwatson: yes
[19:25] <asac> cjwatson: if time is left would be cool to here the story, otherwise later
[19:25] <cjwatson> (I've had some discussions with William on this but they're pretty early stage)
[19:26] <asac> ok
[19:30] <dobey> cjwatson: we're going to build an install manager service, which will do purchasing, download, and install
[19:30] <cjwatson> right but click should be able to call out to it
[19:30] <cjwatson> the layering is wrong right now IMO
[19:30] <cjwatson> or at least the PK plugin for click
[19:30] <dobey> right. the click store requires authentication though
[19:31] <cjwatson> sure
[19:31] <mvo_> dobey: do you want to join the hangout maybe :) would be easier for the people listening
[19:31] <mdeslaur> is someone playing the recorder? :)
[19:31] <mvo_> and watching
[19:31] <cjwatson> callout makes sense, I just want the requests to click to be of the form "install this package" not "install this file"
[19:31] <cjwatson> i.e. like apt rather than dpkg
[19:31] <cjwatson> iyswim
[19:32] <dobey> maybe we need to discuss that more outside this session then
[19:33] <asac> i assume desktop shoots for multi user support from day 1 right? Is it maybe feasible to allow per-user install of click?
[19:33] <cjwatson> I think these two things are compatible
[19:33] <cjwatson> asac: designed that way from the start :)
[19:33] <cjwatson> all works today
[19:33] <asac> cjwatson: so you can do user or system wide? nice!!
[19:33] <asac> if i run click install as root it goes system wide or how does that work?
[19:34] <cjwatson> the installation is done as root in order to make sure that you can't write to the app directory as your user
[19:35] <cjwatson> but packages are registered per-user, or registered "for all users" (effectively system-wide but overrideable)
[19:35] <cjwatson> https://click.readthedocs.org/en/latest/databases.html has an ill-formed brain-dump on the subject which needs to be turned into proper docs
[19:38] <asac> cool stuff
[19:42] <mhall119> pre-install the core apps
[19:42] <mhall119> terminal :)
[19:43] <asac> thanks! :)
[19:45] <barry> yes, it would be really nice to be able to generate both a click and deb at the same time
[19:45] <asac> why would want produce both?
[19:45] <barry> both locally and in a ppa
[19:46] <asac> yeah kind of :)
[19:46] <asac> more discussion needed
[19:46] <cjwatson> initially for experimentation, but it's probably easier to install a click package built against a series later than the one you're running than it is a .deb, because of the library bundling thing
[19:46] <cjwatson> like I say a bit handwavy as yet
[19:47] <cjwatson> it would be a relatively easy place to start though
[19:47] <asac> yeah its fine
[19:47] <lool> mvo_: source packages are reproducible, but in practice we build them in special ways all the time
[19:47] <lool> like from bzr branches, git branches, with orig tarball etc.
[19:47] <asac> i think we need something for our own internal use. if possible that thing would then also be useful for companies that want some infra for automating builds, but in general we dont want to standardize the build process of all clicks i agree
[19:48] <lool> so it's still a bit of a complex situation there too
[19:48] <asac> so kind of a "agreed best practice" for ubuntu supported clicks :) - whatever that might be
[19:48] <cjwatson> right, I think we need to step back and survey what people are doing some months into click packages
[19:49] <asac> right. is the current jenkins infrastructure good enough to gain time to think and observe?
[19:49] <cjwatson> the internal use thing is my main driver right now
[19:50] <asac> i dont think we have a solution for building for multiple archs
[19:50] <cjwatson> that's fine for internal use, says nothing about apps outside Canonical
[19:50] <cjwatson> mm, we sort of do but it's rubbish.  we could do much better with something that was attached to builders
[19:50] <asac> i assume we have someting because we have the emulatro?
[19:50] <cjwatson> no, it involves cross-building
[19:50] <asac> right. well, its good to keep it rubbish and not invest until we know what to do :)
[19:50] <cjwatson> which is fine by itself, the rubbish bit is that you have to do the assembly/merge step yourself
[19:50] <asac> as long as its effective :)
[19:51] <asac> ok thanks folks!
[19:51] <cjwatson> so wgrant and I were thinking of having some standard way to merge the result of multiple builds into a single package
[19:51] <cjwatson> which would involve some path conventions etc.
[19:51] <asac> many more things i would ask, but the session is dubbed "desktop", so i wait for another opportunity :()
[19:52] <ogra_> the people creating the session were clever ;)
[19:52] <cjwatson> gotta scope things
[19:52] <cjwatson> otherwise you die
[19:52] <cjwatson> one dies I mean.  not a threat ;-)
[19:52] <pitti> mvo_: FYI, packagekit with aptcc doesn't implement our hooks for installing missing language support and missing drivers; language-selector and ubuntu-drivers-common only provide Python plugins
[19:52] <ogra_> lol
[19:53] <cjwatson> I *think* those would be doable with PK plugins, which are in some ways more flexible
[19:53] <lool> ++
[19:53] <mvo_> asac: do we need another session with the thing you want to discuss?
[19:53] <asac> i dont know
[19:53] <cjwatson> but I've added a note to consider those plugins, thanks
[19:53] <asac> i dont like to record my insane state of mind on youtube :P
[19:54] <mvo_> pitti: good point
[19:54] <asac> i think we can discuss after UOS more and then have another session in 3 month :)
[19:54] <mvo_> cjwatson, lool it seems like even if they are doable we still need to do some work here
[19:54] <mvo_> but I guess its always work, one way or the other :)
[19:54] <asac> thx mvo_ seb128 cjwatson xnox ... good session to end the day :)
[19:54] <cjwatson> asac: I think wgrant and I can probably pursue that to some extent, but we probably ought to get our critical-path stuff for RTM done first :)
[19:55] <mvo_> thanks asac
[19:55] <asac> yeah, lets not focus on that
[19:55] <cjwatson> anyway, thanks, that was very useful, apologies for having to try to prune the lines of discussion a bit
[19:56] <asac> cjwatson: the main problems i currently have are the click things we discussed in the core v2 thread :), but talk more later about that
[19:56] <asac> have a great evening :)
[19:56] <mvo_> thanks cjwatson!
[19:56] <mvo_> asac: yeah, lets talk more another day, it was a long day already
[19:56] <asac> ok tomorrow 8am sharp
[19:56] <asac> :)
[19:56] <mvo_> asac: I will be up at 6:30 am ;)
[19:56]  * cjwatson breaks asac's alarm clock
[19:56] <asac> before-day-starts-standup
[19:56] <asac> hehe
[19:56] <mvo_> asac: shall I call you ;) ?
[19:56] <asac> oh right
[19:56] <cjwatson> oh wait, the phone developers already did
[19:56] <asac> that will only work next week
[19:57] <asac> alarms are broken, i hope the fix gets promoted tomorrow :)
[19:57] <mvo_> lol
[19:57] <asac> its true. i am an avenger and cannot schedule calls in the morning anymore because of that
[19:57] <asac> ok cu folks
[23:31] <pathos> Anyone have screenshots of the daily build?


[00:11] -queuebot:#ubuntu-release- New: accepted libopenhmd [amd64] (zesty-proposed) [0.2.0-2]
[00:11] -queuebot:#ubuntu-release- New: accepted libopenhmd [armhf] (zesty-proposed) [0.2.0-2]
[00:11] -queuebot:#ubuntu-release- New: accepted libopenhmd [powerpc] (zesty-proposed) [0.2.0-2]
[00:11] -queuebot:#ubuntu-release- New: accepted libopenhmd [s390x] (zesty-proposed) [0.2.0-2]
[00:11] -queuebot:#ubuntu-release- New: accepted libopenhmd [arm64] (zesty-proposed) [0.2.0-2]
[00:11] -queuebot:#ubuntu-release- New: accepted libopenhmd [ppc64el] (zesty-proposed) [0.2.0-2]
[00:11] -queuebot:#ubuntu-release- New: accepted libopenhmd [i386] (zesty-proposed) [0.2.0-2]
[09:32] <LocutusOfBorg> doko, pitti doxygen is sad because it tries to apt-get source [removed package from zesty]
[09:32] <LocutusOfBorg> please hint autpkgtestsuite :)
[09:32] <LocutusOfBorg> also fixing it might be nice
[09:32] <LocutusOfBorg> ;p
[12:01] -queuebot:#ubuntu-release- New binary: lubuntu-artwork [amd64] (zesty-proposed/universe) [0.65] (lubuntu)
[16:42] -queuebot:#ubuntu-release- New: accepted lubuntu-artwork [amd64] (zesty-proposed) [0.65]
[21:43] -queuebot:#ubuntu-release- Unapproved: glib2.0 (yakkety-proposed/main) [2.50.0-1 => 2.50.2-2ubuntu1] (core)


 Use a framework, and potentially increase productivity, but sever all possible performance; or, use libraries like Zend, take more time on code, and have higher performing code.
[06:08] <Takyoji> http://talks.php.net/show/drupal08/24 (until slide 32)


[18:09] <cjp256> holmanb:  i noticed that with the ds_detect changes that the datasource no longer will fall back to None as it had with is_platform_viable() check in get_data().  Specifically in the case of Azure, the ds-identify or user ds config would be [Azure, None] and get_data would bail if detection failed with something like "No local datasource found".   End result is customers using that config on non-Azure platforms now end up
[18:09] <cjp256> executing the _get_data() path as if on Azure, causing some issues
[18:11] <cjp256> I notice that ds-identify detection for Azure is broader than the ds_detect method, which I think we need to unify too
[18:42] <holmanb> cjp256: agreed on ds-identify / ds_detect disparity - those should match
[18:44] <holmanb> cjp256: iirc checking datasource_list in override_ds_detect was proposed during review as an optimization do avoid re-checking what ds-identify already checked - in that case [Azure, None] is expected I think
[18:46] <holmanb> cjp256: if [Azure, None], I believe it will still fall back to None whenever get_data() times out
[18:46] <holmanb> *to avoid re-checking
[18:52] <holmanb> cjp256: When customer provides [Azure, None] and cloud-init runs _get_data() is this just a change in expected behavior in a failure path? Or is fallback to DataSourceNone a normal behavior in user workflow?
[18:52] <cjp256> normal behavior if image is used outside Azure
[18:54] <cjp256> right now that timeout is a pretty long wait so ideally we’d like to go back to skipping that path if detection determines it won’t (shouldn’t) work
[21:09] <cjp256> holmanb: what do you think about https://github.com/canonical/cloud-init/pull/4426
[21:45] <holmanb> cjp256: seems reasonable to me, I think