#ubuntu-uds-platform-1 2014-06-10 <CodePulsar> What is the password for joining the IRC channels? <CodePulsar> I've registered at LaunchPad <CodePulsar> How can I join the sessions? <tsimpson-uds> CodePulsar: there is no password <CodePulsar> tsimpson-uds: so is the channel #ubuntu-uos-platform1 or #unbuntu-uds-platform1 ? <CodePulsar> I can't join the former <tsimpson-uds> CodePulsar: just replace -uos- with -uds- for now * ChanServ changed the topic of #ubuntu-uds-platform-1 to: Track: Ubuntu Development | KDE Frameworks - Libraries for all Qt users. | Url: http://summit.ubuntu.com/uos-1406/meeting/22262/kde-frameworks-libraries-for-all-qt-users/ <d_ed> good afternoon all. <d_ed> I'm the host of the first session in 5 minutes <d_ed> please let me know if there are any problems with the audio/video etc. <CodePulsar> I hear <d_ed> brb, technical difficultied <Trevinho> d_ed: it was working actually... <d_ed> yeah... <d_ed> I realised that afterwards <theretard> Hey guys! <Trevinho> d_ed: you probably need mhall119 to create a new one <d_ed> done <d_ed> ok, please refresh <d_ed> ok, starting <d_ed> Ask me questions here: https://plus.google.com/hangouts/_/gwkgcskau3hdgbwzseyhezgew4a <kdeuser56> d_ed: anyway to relink it on http://summit.ubuntu.com/uos-1406/meeting/22262/kde-frameworks-libraries-for-all-qt-users/? <d_ed> I put it in the notes <CodePulsar> QUESTION: Is there a roadmap for the KDE Frameworks modularization process? What has been done, what's being worked on now, who is working on what, what needs to be done in the future, etc. <d_ed> CodePulsar: good question <d_ed> CodePulsar: mostly it's all done <d_ed> we're in our 3rd beta <d_ed> everything is already split <d_ed> and about to be released. <kdeuser56> d_ed: is it planned to merge trier 1 frameworks in Qt in the future? what about the whole k-naming in the classes? <d_ed> we tried where possible to merge <d_ed> we merged a lot <kdeuser56> d_ed: so after all a lot of the k-names remain, which wont change due to the api stability ... wont that cause problems? <CodePulsar> d_ed: awesome, I've found this page: https://community.kde.org/Frameworks/Epics/Splitting_kdelibs which also says "DONE" according to the definition mentioned there. <d_ed> kdeuser56: so anything still in KDE Frameworks still has a K prefix <d_ed> just like Qt stuff has a Q prefix <d_ed> we have a layer for people porting Qt4->Qt5 called KDE4LibsSupport <d_ed> which still has the K* class <d_ed> I can see some more stuff moving into Qt eventually <d_ed> but Qt will never contain everything, Qt would just become too big and clunky. <CodePulsar> From what I understand the definition of Tier1 modules is that they depend only on Qt modules, what is the definition of Tier 2/3/4 modules? <mgraesslin> Tier 2 may only depend on Tier 1 <mgraesslin> + Tier 1 deps <mgraesslin> Tier 3 on Tier 2 and Tier 3 frameworks <d_ed> so KTextWidgets which contains a QTextEdit with spellchecking cannot be tier1 because it depends on Sonnet in tier 1 <kdeuser56> d_ed: what about high resolution support in the gui related libraries? <d_ed> When Qt patches land that provide the devicePixelRatio then we should "just work" <d_ed> as most the changes happen in QStyle <d_ed> If anything is broken, we'll fix it there and then. <d_ed> CodePulsar: does that answer your question? <CodePulsar> d_ed: yes, thanks <kdeuser56> d_ed: how do you see the relation of stuff ubuntusdk introduced like conditional layouts and kde frameworks related stuff in the future? will stuff play together well, so that one can use the best of both worlds, without being limited to one platform? <d_ed> kdeuser56: with 95% of stuff, they're completely unrelated. <d_ed> kdeuser56: in the case of plasma-framework, they might clash a bit, but I can't imagine anyone using those two together <d_ed> the whole point of frameworks isn't that you'd want to use all of them, it's to select the bits you do want <d_ed> ok, any more questions? <CodePulsar> d_ed: Where can we find the notes for the talk? <d_ed> it's on the right on http://summit.ubuntu.com/uos-1406/meeting/22262/kde-frameworks-libraries-for-all-qt-users/ <d_ed> the link to the API is the super useful one <mgraesslin> the apidocs work great - I work with them every day <mgraesslin> (even for the API I maintain) <CodePulsar> OpenID Authentication Required loop <d_ed> CodePulsar: on the summit page? <d_ed> I'll post a direct link here <CodePulsar> yes, when trying to access the pad <d_ed> API docs: http://api.kde.org/frameworks-api/frameworks5-apidocs/ <d_ed> lists what tier everything is in <d_ed> and the cross-platformability of it <d_ed> Article about Frameworks in general: http://dot.kde.org/2013/09/25/frameworks-5 <CodePulsar> great <d_ed> CodePulsar: mind if I ask what you work on? * ChanServ changed the topic of #ubuntu-uds-platform-1 to: Track: Ubuntu Development | Unity8 Desktop Preview Image | Url: http://summit.ubuntu.com/uos-1406/meeting/22308/unity8-desktop-preview-image/ <CodePulsar> d_ed: I haven't worked on the development of KDE as of yet, but I'm a financial contributor. I've used and use Qt at work extensively and I'm interested in contributing back to KDE, development wise. <d_ed> we should take this discussion outside of this channel now <rickspencer3> o/ <bregma> sorry folks, looks like some technical issues are happeining.... <FunnyLookinHat> Has the hangout video started for anyone else? * lool switches to looking at some container demo :-) <lool> FunnyLookinHat: 18:04 < bregma> sorry folks, looks like some technical issues are happeining.... <FunnyLookinHat> lool, ty <lool> FunnyLookinHat: will certaily start in a couple of minutes <seb128> if we find somebody able to host a live hangout <seb128> seems like most of us got kicked out by google <dholbach> sorry for the delay - hangout should be up in a bit <Laney> could we do it from a personal account? <seb128> shrug <seb128> I can't even join one! <seb128> it's not only hosting <dholbach> seb128, can you use your normal @gmail.com account? <dholbach> everyone: ^ :) <bregma> have you tried turning it off and then back on? <bschaefer> bregma, that should work <seb128> let me try <seb128> bregma, turn what off and on? <Laney> haha <dshimer> live <Laney> I think that was a troll <seb128> oh, it works after a "clear recent activity" and log in again <Laney> link? <seb128> Laney, see query <Laney> thanks <Laney> twice even! <seb128> hum, I'm alone in there <seb128> that looks wrong <robruos> seb128: I see dholbach and mterry and bregma but not you <dholbach> finally! <dholbach> it just took 13 minutes to get us going! <dholbach> is mterry breaking up for anyone else as well? <bschaefer> mterry, you're going down <Laney> yep <rickspencer3> o/ <mterry> seb128, can you hear me? <seb128> indeed <rickspencer3> maybe seb128 can take over? <seb128> http://cdimage.ubuntu.com/ubuntu-desktop-next/daily-live/ <seb128> blueprint https://blueprints.launchpad.net/ubuntu/+spec/client-1410-unity8-desktop-iso * Laney DONEs some items ;-) <rickspencer3> rats, I was looking forward to trying it out soon :) <Laney> it got blocked in the train by some other things <Laney> I think those other items are going to be flushed through quite soon <mterry> :( <mterry> :( I keep losing connection <lool> seb128: FYI there's another system-image for servers session later today <seb128> lool, thanks <hanswurst> where will I be able to download the new iso? Will I be able to run it in Virtualbox in order to test it and report bugs? <dholbach> notes: http://pad.ubuntu.com/ep/pad/view/uos-1406-unity8-desktop-preview-image/latest <mterry> I'm back! <dholbach> sorry, http://pad.ubuntu.com/uos-1406-unity8-desktop-preview-image <Laney> http://cdimage.ubuntu.com/ubuntu-desktop-next/daily-live/ <Laney> still bad <dholbach> mterry, you're still breaking up <seb128> mterry, no luck :/ <mterry> You can't hear me? <mterry> I can hear you, weird <mterry> Well, give me the greeter work items anyway :) <dholbach> mterry, I believe that's what's happening in the pad already :-P <xnox> hello? <rickspencer3> seems that mterry is not having good luck with hanging out today :) <xnox> is this thing on?! <rickspencer3> xnox, you forgot to tap it first * rickspencer3 tap tap tap <dshimer> QUESTION: When will this be at a point where a casual but interested user could download install (or run from a live ISO) and report experiences on varying hardware? * xnox I LOVE ROCK&ROLL <mterry> Guh, there goes my video <Guest22379> Am I understanding correctly, that there will be 2 Ubuntu "Desktop" Versions for 14.10, one running Unity7 and one running Unity8 (Ubuntu Desktop Next)? <dholbach> xnox, want to join the hangout too? * mterry gives up <bregma> dshimer, "soon" but with the caveat that Mir is still not yet supported on proprietary binary video drivers <xnox> Laney: installer tests would be easy to test -> cause it would be ubiquity preseeding and AP tests <Laney> xnox: what does the pending stuff? <dholbach> Guest22379, unity8 currently just works on the phone and tablet, the discussion is about offering an optional desktop session image for the release, so we can test and play around with this more easily, etc <Laney> or, what tests does it run? <xnox> Laney: desktop live-session is never tested, but rather a system is installed, booted and then after the reboot the "typical user account" is tested for basic functionality <xnox> Laney: yes, some of these tests block pending -> current migration <Laney> no testing of live? <xnox> Laney: all automated preseeding must pass <xnox> Laney: plus desktop tests post install must also pass <xnox> (which also includes e.g. OEM) <xnox> Laney: there is no way to test live-session (try-ubuntu) at the moment. <xnox> bregma: correct <Laney> okay <Laney> I think installing should work <Laney> so it's probably alright to re-use some of this <xnox> bregma: i can work on the installer <dholbach> xnox, want to join the session? <xnox> bregma: Laney: .... if gtk3-mir support is built into that image, e.g. via a ppa?! <xnox> dholbach: nah, i have bad hair day <Guest22379> will there be a session dedicated to the visual design of unity8 on the desktop. I take it there will be some changes compared to unity7 <Laney> installing in only-ubiquity by now <dholbach> oh well, I tried <Laney> s/by/for/ <xnox> seb128: feel free to give some of them to me (e.g. installer / testing etc....) <seb128> xnox, thanks <Laney> I don't know when gtk3 will be ready, but I don't expect installnig from the live session to be a priority at the start <xnox> Guest22379: this is pure engineering session, rather than design/ux/etc <seb128> mterry, do you plan to look at making the phone greeter work on desktop? <seb128> the few bugs we talked about in Malta that need to be fixed at least <mterry> seb128, I added a work item to the BP for it <seb128> mterry, ok, I'm taking notes on http://pad.ubuntu.com/uos-1406-unity8-desktop-preview-image <seb128> workitems as well <mterry> seb128, priority is phone, but I want to fix this for desktop too obvi <mterry> seb128, oh ok <seb128> k <seb128> that didn't seem to be too much work, we just tweaked the qpa and some other minor things <xnox> Laney: does desktop-next image auto-logins now? (as in did your patches land?!) <Laney> not yet <Laney> train delays <Laney> leaves on the line or something like that <xnox> Laney: ack, but i guess it can't boot into "only-ubiquity" can it? <Laney> can't? <Guest22379> how can I help with testing? <Laney> it probably can, you select that before booting <Laney> but I haven't tried it I'm afraid <xnox> Laney: because there is no X & ubiquity doesn't have X dependency <Laney> no X ?http://cdimage.ubuntu.com/ubuntu-desktop-next/daily-live/pending/utopic-desktop-amd64.manifest <xnox> Laney: (even if that would be on the image only and not actually installed to disk, nor runable in the live-session) <xnox> Laney: ok. <xnox> Laney: so i should get cracking on the installation front. <Guest22379> is there a version of apport or similiar for this image? <xnox> bregma: $ ubuntu-bug ubiquity <xnox> bregma: if the iso doesn't boot, doesn't install, crashes live session ^ <leftyfb> I'm just jumping into the session now .... will MIR be able to do X forwarding? As in over ssh? That's a feature I use very often. <xnox> bregma: all should go to ubiquity, and then redirect =) <seb128> dholbach, thanks for hosting <dholbach> leftyfb, not sure if people know, but you could try asking on #ubuntu-mir as well <seb128> mterry, way to sneak out! <dholbach> seb128, anytime <mterry> :) <mterry> seb128, dholbach: sorry about that! Thanks for saving me * mterry goes to a coffee shop for better internet :( <rtwert> is there a login and pw for the new image <rtwert> i just installed it and can't get past the greeter * ChanServ changed the topic of #ubuntu-uds-platform-1 to: Currently no events are active in this room - http://summit.ubuntu.com/uos-1406/platform-1/ - http://irclogs.ubuntu.com/2014/06/10/%23ubuntu-uds-platform-1.html * ChanServ changed the topic of #ubuntu-uds-platform-1 to: Track: Ubuntu Development | system images for servers | Url: http://summit.ubuntu.com/uos-1406/meeting/22271/development-1406-server-system-images/ <stgraber> https://plus.google.com/hangouts/_/hoaevent/AP36tYdKGQui2ypMnKFITIpq_WXCp2VL6hBywLvxBs38a4xtIRLfVw?authuser=0&hl=en <jamespage> o/ <stgraber> hangout url is https://plus.google.com/hangouts/_/hoaevent/AP36tYdKGQui2ypMnKFITIpq_WXCp2VL6hBywLvxBs38a4xtIRLfVw?authuser=0&hl=en <cjwatson> Do we have a G+ link? <stgraber> https://plus.google.com/hangouts/_/hoaevent/AP36tYdKGQui2ypMnKFITIpq_WXCp2VL6hBywLvxBs38a4xtIRLfVw?authuser=0&hl=en <barry> stgraber: i got an error with that one <cjwatson> wfm <barry> dang <asac> o/ <stgraber> https://plus.google.com/hangouts/_/hoaevent/AP36tYdKGQui2ypMnKFITIpq_WXCp2VL6hBywLvxBs38a4xtIRLfVw?authuser=0&hl=en <dholbach> you are live! :) <barry> yeah, it keeps erroring on me. guess i'll just particpate this way <lool> I also have bandwidth issue <lool> cant open the ho, but will see the yt stream <lool> cant we handle everything from a specific initrd rather than relying on bootloader? <lool> like, checking system files to decide between recovery and regular boor <lool> *boot <lool> stgraber: is it worth discussing the UID changes issue? this happened again in recent images <stgraber> lool: I don't think so, this isn't really server specific but a generic issue we need to resolve <gQuigs> I don't quite understand the benefit of this for the server... we want servers to go towards no reboots as opposed to more... <lool> gQuigs: the point is avoiding the random combinations of packages breaking the upgrade <lool> a single wholesale upgrade from v1 of the OS to v2 <gQuigs> lool: oh <gQuigs> can we do kexec to the next image then? <lool> also, more efficient as you're not running all the upgrade scripts, just applying a big OS delta <lool> gQuigs: linux is just one thing, most of the system image bits are to update all OS files <gQuigs> lool: this only works if people are upgrading in about the same timeframe? <lool> gQuigs: we keep a set of deltas; this is flexible to any base version scheme we want to support; worst case you download a full image <lool> that is, you download the whole v2 files <gQuigs> lool: cool :) <cjwatson> I think in general FWIW this is mainly aimed at some very limited use cases, certainly for now <cjwatson> more like the kind of embedded server arena <gQuigs> cjwatson: ah, ok <barry> the question then is whether the embedded server target market will have that slow bios step <cjwatson> not that I want to limit people's creativity but it might help to keep the scope fairly narrow so that it's achieveable ... <barry> not that embeddeds are super fast rebooters <lool> barry: server BIOSes are not super fast <barry> lool: right <cjwatson> understatement <barry> but e.g. your fridge might not have a bios :) <lool> perhaps I'm unlucky, but it seems to me server boot is designed to be debuggable and reliable and hence is slow <gQuigs> +1 on the LXC juju idea <lool> I wonder whether we ought to design something more along the lines of super minimal linux + initrd that is only rarely rebooted, and system-image updates of containers started by this minimal linux + initrd; linux+initrd only updated/restarted less frequently <lool> ah well, I'm lagging I guess :) <gQuigs> would one of the goals be to make it easy for an end user to customize an image to their need? <gQuigs> (aka for a deployment to 1000 embeded nodes) <barry> gQuigs: not a goal per se, but doable <barry> we already have people experimenting with custom images for touch <gQuigs> barry: awesome :) <lool> do we have the list of clicks we want to demo this way? <jdstrand> that is what we do with apparmor <jdstrand> (use an intermediate format for something on the system) <cjwatson> right <cjwatson> lool: well, I doubt any existing click packages would be appropriate <lool> cjwatson: sorry, I was asking which services we would want to clickify (see pad) <jdstrand> currently, apps must do upgrades themselves <jdstrand> (eg, if an app changes frameworks, it is expected to handle that upgrade itself) <jdstrand> (eg, db formot change) <jdstrand> s/formot/format/ <asac> jdstrand: iirc we said click might grow hooks for this stuff, yes <jdstrand> sure, just saying what the state is now <asac> for restart, data migration etc. <lool> hmm <asac> right, for daemons we surely need to do something <jdstrand> yeah <asac> lool: you disagree? <cjwatson> right, though I want to steer away from the maintainer script path <asac> :) <asac> yes!! <asac> please no free form scripts :) <jdstrand> indeed <cjwatson> but we need something for data migration <asac> just export: i am a daemon that needs restart :) <cjwatson> no there definitely has to be some capability for free-form <cjwatson> but just not in the same way <asac> yeah, data migration for sure <cjwatson> I don't think we can do fully declarative data migration :) <cjwatson> restart of course can be declarative and in fact shouldn't even need declaring <cjwatson> if your package ships a service and it's upgraded, it fairly obviously wants to be restarted IMO <cjwatson> and we just delegate the hard work of that to systemd <barry> cjwatson: it's possible you want to apply update now but reboot at a more convenient time <barry> *restart <cjwatson> reboot yes, restart individual service I don't really think so <cjwatson> we restart services on dpkg upgrades today <barry> true. yeah possibly so <cjwatson> and it's generally a lot less confusing than not doing so :) <asac> cjwatson: right, but arent there services that need to be stopped before the unpack (preinst) and other services that just get restarted after? <cjwatson> it's more a question of services that need to stay down for only short periods of time if at all, and ones where it doesn't matter <lool> hmm should be different dirs anyway <cjwatson> I think in the system-image/click model, just restarting everything after upgrade would be fine <cjwatson> bearing in mind that the library linkage graph is much simpler <cjwatson> any libraries you need are either in the click package, or they're applied en masse by the system-image upgrade <asac> just note down what needs doing and who would be best, we figure out priority etc. later :) <lool> happy to help there <rsalveti> yup, would be fine to do some clean up <rsalveti> but it'll change a bit as well once we start supporting the device with a proper partitioning scheme * ChanServ changed the topic of #ubuntu-uds-platform-1 to: Currently no events are active in this room - http://summit.ubuntu.com/uos-1406/platform-1/ - http://irclogs.ubuntu.com/2014/06/10/%23ubuntu-uds-platform-1.html <asac> yeah, idea was to get a fully usable system on usb key (including upgrades) <asac> thanks! <rsalveti> thanks <asac> stgraber: slangasek: mvo: jamespage: cjwatson: ^ thanks ^ <asac> have to review notes if something big was missing :) #ubuntu-uds-platform-1 2014-06-11 * ChanServ changed the topic of #ubuntu-uds-platform-1 to: Currently no events are active in this room - http://summit.ubuntu.com/uos-1406/platform-1/ - http://irclogs.ubuntu.com/2014/06/11/%23ubuntu-uds-platform-1.html * ChanServ changed the topic of #ubuntu-uds-platform-1 to: Track: Ubuntu Development | How to get your patch into Debian & ubuntu | Url: http://summit.ubuntu.com/uos-1406/meeting/22303/how-to-get-your-path-into-debian-ubuntu/ <xnox> Hello <cjwatson> Dia dhuit <xnox> cjwatson: how to best do google doc presentations? * xnox is doing it via screenshare so far <sil2100> o/ <cjwatson> Not sure, I expect I'll find out tomorrow <cjwatson> I think I used screenshare last time ... <xnox> where are hangout urls in this thing? <xnox> or i don't think people want to join, as it's a presentation <cjwatson> Even with a presentation sometimes it's easier to take questions with people on a hangout <cjwatson> Since youtube lag <xnox> https://docs.google.com/presentation/d/10SbMhkHuTpgVEncv8Fp_A8is0stDKwuMiCAYEFNiw40/edit?usp=sharing <xnox> Question time =) <xnox> I know there are at least 7 live viewers and a few people here =) <cjwatson> (The stream has caught up with your request for questions) <sil2100> No questions from my side, it was a nice overview of the process :) <xnox> cjwatson: yeap, quite a lag <xnox> sil2100: cool. <cjwatson> OK, I'll hop over and see what's going on elsewhere then :) <cjwatson> Thanks <xnox> Btw, sil2100 will be participating in the next session in community-1 talking about CI-train / merge-proposals and etc =) * ChanServ changed the topic of #ubuntu-uds-platform-1 to: Track: Ubuntu Development | Webapps Roadmap | Url: http://summit.ubuntu.com/uos-1406/meeting/22300/webapps-roadmap/ <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. <xnox> i think for next session, i'll join into the hangout from another hangout to act as the "presenter screen" * dbarth waves <dbarth> please prefix you questions with QUESTION <dbarth> and we'll take them in order <ogra_> QUESTION: will the new header be "suppressable" for webapps that use their own header already ? <ogra_> (like 80% of the ones we have today) <ogra_> thanks ! that answers my question <dbarth> yw :) * ChanServ changed the topic of #ubuntu-uds-platform-1 to: Track: Ubuntu Development | Utopic UE-Core Roadmap | Url: http://summit.ubuntu.com/uos-1406/meeting/22264/utopic-ue-core-roadmap/ <asac> o/ <ogasawara> yo, just waiting for the crew to file into the hangout... * rsalveti waves <asac> yes <asac> it works <barry> yes <dholbach> go go go! :) <fossterer> We can hear you <dholbach> lag of 10s ;-) <arges> that plant dancing in the background is hilarious <zyga> ogasawara: ack <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" <asac> cant see the slide :) <asac> ogasawara: ^ <dholbach> no, keep the "phonedations team" name! <ogasawara> asac: thanks <asac> hmm. still not, but guess its lag <asac> ah now! <asac> thanks! <ogra_> thats dholbach's fault ... he did set the lag above <ogra_> :) <dholbach> ogra_, and I thought there'd be one day where I'm not trolled by someone :-P <asac> never! <dholbach> not with ogra_ around :-P <ogra_> haha <xnox> OMG, I have MMS =) <xnox> *hate <ogra_> xnox, sending a UPS parcel is cheaper in germany :) <xnox> ogra_: and it actually may arrive! <ogra_> ++ <xnox> ogra_: i once sent an MMS, which arrived as an SMS with a url to open on the other end. <ogra_> haha <xnox> ogra_: cause the receiving operator did not support delivering MMS at all! <ogra_> yeah, MMS are actually SMS with a download link ... but you usually have a provider proxy that hands you the data then <ogra_> via the shipped URL <ogasawara> asac: can you see ev's slides? just want to make sure <asac> ogasawara: yes :) <ogasawara> thanks <cjwatson> xnox: sometimes you get a URL, sometimes you get raw control metadata on your screen <cjwatson> it's awesome <xnox> cjwatson: =)))))) <cjwatson> to be fair that last has only happened to me once * ChanServ changed the topic of #ubuntu-uds-platform-1 to: Currently no events are active in this room - http://summit.ubuntu.com/uos-1406/platform-1/ - http://irclogs.ubuntu.com/2014/06/11/%23ubuntu-uds-platform-1.html <asac> thanks ogasawara slangasek ChickenCutlass ev!! awesome! <asac> ogasawara: you think we can link the slides from the youtube video description? <asac> ogasawara: and insert links to the start of each team for convenience? <asac> dholbach: who can edit those video descriptions? <asac> http://www.youtube.com/watch?v=d5AjUo9K-yQ <ogasawara> asac: hrm, not sure <ogasawara> asac: I'm planning at the very least to link the decks from the description in summit.ubuntu.com <asac> right. think for the world the video descriptio would be better <asac> :) <asac> let me try to find out <dholbach> asac, whoever kicked off the hangout - it's in their youtube channel AFAIK * ChanServ changed the topic of #ubuntu-uds-platform-1 to: Track: Ubuntu Development | Language packs for touch devices | Url: http://summit.ubuntu.com/uos-1406/meeting/22302/development-1406-touch-language-packs/ <dpm> pitti, I'm not sure if anyone else is going to, but I can start the hangout <pitti> dpm: ok; you'll just toss the URL here? <dpm> yeah * ogra_ has some bandwith issues today and will follow via IRC <dpm_> hi everyone, here's the hangout URL for the langpacks session for anyone wanting to join: https://plus.google.com/hangouts/_/hoaevent/AP36tYcxsbVRdlmAOBPlxgkDxqUqcnxSlHfEMOMlyeuQpxURZHb84A <dpm_> seb128, here's the hangout link https://plus.google.com/hangouts/_/hoaevent/AP36tYcxsbVRdlmAOBPlxgkDxqUqcnxSlHfEMOMlyeuQpxURZHb84A <dpm_> http://pad.ubuntu.com/uos-1406-development-1406-touch-language-packs <ogra_> thats an evil color you have <ogra_> :) <dpm_> http://pad.ubuntu.com/uos-1406-development-1406-touch-language-packs <GunnarHj> Anybody who could provide the link to the hangout? <ogra_> https://plus.google.com/hangouts/_/hoaevent/AP36tYcxsbVRdlmAOBPlxgkDxqUqcnxSlHfEMOMlyeuQpxURZHb84A <GunnarHj> ogra_: Thanks! <ogra_> pitti, pfft ... developers are on tehir own :P <ogra_> dpm_, pitti, the rw mode is kind of a developer mode anyway ... dont worry to much about it <pitti> ogra_: *nod* <pitti> just mentioning it for completeness <ogra_> ++ <ogra_> GunnarHj, notes are at http://pad.ubuntu.com/uos-1406-development-1406-touch-language-packs <seb128> ogra_, don't hate on developers! <ogra_> haha, i dont <ogra_> but i expect them to be capable of working with LANG=C <seb128> sure they are <ogra_> (apart from the french ones perhaps :P ) <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 <seb128> which is quite a step back from what we have today <dobey> QUESTION: will we also include the spelling/grammar dictionaries, and keyboard layouts with the lang packs? <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 <ogra_> dobey, currently these come as deps of the OSK <dobey> ogra_: right, but do those aling with the 20+ languages that are >50% coverage? <dobey> align even <asac> ogasawara: seems you should be able to change video description etc. <asac> oh sorry if there was a sesion :) ... ignore <ogra_> dobey, not atm ... up to us to align the seeds <ogasawara> asac: ack, I'll investigate <ogra_> pitti, we dont care about anything that is not UI <seb128> ogra_, that is again a shortcoming when you think about convergence <ogra_> seb128, i think about RTM only currently <seb128> ogra_, we should design something that's futurproof <ogra_> seb128, i agree but for RTM (which is essentially also 14.10) we can easily go with seed syncs <dobey> yeah, it would be nice to have some way to install additional languages, without having to totally break the phone to do it <seb128> ogra_, are we discussing RTM or futur there? <ogra_> dobey, you wotn be able to if they are deb <ogra_> seb128, no idea ... i thought 14.10 <dobey> ogra_: yes, i know that. but i think we need to solve that <ogra_> dobey, right, see my comment on the notes <dobey> whether or not it is done for RTM is separate from how we get there <ogra_> if we want to be able to update/install individual langs they must be click <dobey> what is the pad url? <ogra_> http://pad.ubuntu.com/uos-1406-development-1406-touch-language-packs <infinity> pitti: I've missed half this session, but are you considering having another lookup location? <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 <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 craighoward@example.net. <seb128> infinity, what for? somewhere in a system-image rw location you mean? <pitti> for now they just Conflicts: each other <dpm_> pitti, https://wiki.ubuntu.com/Translations/TemplatesPriority <dobey> how often do we need to update translations separate from the packages that own those translations now? <pitti> infinity: we haven't talked about click at all yet <pitti> (and I don't think langpacks would be a particualrly good idea for them) <dobey> could we just get rid of langpacks, and include all the translations directly in the packages? <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. <ogra_> pitti, it think they would <ogra_> (thats why i added that to the notes too) <ogra_> at least if you want to be able to update them out of the system image <pitti> infinity: oh, you mean langpacks AS click packags, not FOR <dobey> ogra_: i'm less concerned about updating, than wanting to use a language that is available, but not on the image <infinity> pitti: Right! <ogra_> dobey, well, at the size that pitti can squeeze them we could easily ship all we have <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. <dobey> ogra_: right. so why have lang packs at all? :) <ogra_> dobey, ? <pitti> infinity: right, and we can certainly keep that idea <ogra_> infinity, but the touch only ones are really small <dobey> ogra_: if we are going to ship all the translations anyway, why have langpacks? <ogra_> dobey, maintenance reasons <ogra_> you could as well just have one giant one <dobey> ogra_: it seems like having langpackas is more work, not less <seb128> dobey, that's how we land updated translations <seb128> on the system image <seb128> which is then shipped to users <dobey> the problem with the current langpacks is that they have lots of things we don't have on the phone <ogra_> dobey, we have an infrastructure <ogra_> dobey, do you listen to the hangout ? <pitti> dobey: not the language-pack-touch-* ones, they have exactly the stuff that's on the image <ogra_> the touch ones are stripped for touch only stuff <dobey> ogra_: yes <pitti> and we can avoid shipping really badly translated languages with that, too <ogra_> they dont ship anything we dont need <pitti> i. e. "most" <dobey> ogra_: those are on the phone already? <dobey> ogra_: i'm talking about a different solution to -touch only langpacks (by just not having langpacks) <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. <ogra_> dobey, we ship 6 languages atm <ogra_> due to space constraints <ogra_> with the touch packs we will be able to ship all <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. <dobey> ogra_: i feel like we are talking past each other :-/ <infinity> Assuming those lookups aren't hideously expensive... <ogra_> infinity, we should definitely make them co-installable <ogra_> dobey, we can not not have langpacks <pitti> infinity: well, "super tiny" is an exaggeration, they are ~ 800 kB each (.deb size) <dobey> ogra_: why not? <ogra_> dobey, unless we are inventing a completely new infra <pitti> uncompressed ~ 3 MB <infinity> pitti: Oh. That's pretty huge, IMO. <dobey> ogra_: there's nothing to invent <infinity> pitti: So, install-on-demand as clicks would make a lot of sense, in that case, IMO. <ogra_> dobey, our current infra creates them automatically from translations <dobey> ogra_: yes. but disabling the langpack magic just means putting the translations in the binary packages that own them instead <ogra_> infinity, all of them will be like 50-60M vs 150M for six lands we whip today <ogra_> *langs <pitti> infinity: well, the current packs are ~ 30 MB uncompressed :) <pitti> (per language) <ogra_> dobey, oh, *thats* what you mean <infinity> ogra_: Sure, but I'm all for shrinking further. <ogra_> dobey, that wont work in convergence <dobey> ogra_: why not? <ogra_> infinity, yeah, i wouldnt mind having them as clicks <dobey> it worked perfectly fine before we had langpacks :) <seb128> ogra_, pitti: we should keep in mind that langpacks are likely to increase over time, as our softwares become more complete <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 <ogra_> dobey, right, but your desktop langpacks wont be able to update your translations after release <ogra_> asac, not talking about apps here <asac> ogra_: the youtube channel talks about click though? <dobey> ogra_: they would update the same as they would update on the phone <ogra_> asac, taalking about the mechanism to ship languages <ogra_> asac, click vs deb <asac> ah <asac> :) <seb128> asac, right, but that's translations for the default image <seb128> not for clicks <asac> seb128: well, there is an overlap. we hav clicks in defult image too <ogra_> dpm_, ++ <ogra_> sounds good <seb128> well, "default image, deb+click+whatever else" <asac> seb128: imo those should use the same mechanism as the other clicks <ogra_> asac, and the langpacks ship their translations currently <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 :) <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? <ogra_> asac, right, but i dont think this is about click translations at all atm <asac> ogra_: right, thats a bandaid, but feel we need a click translation story :_) ... anyway, if thats not on topic i will wait :P <ogra_> just about the default langs we ship <ogra_> dpm_, yes, i was referring to RTM <asac> again, i dont think thats an independent topic as we ship clicks by default :P <dobey> pitti: i don't understand what you're asking about with that argv[0] comment <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. <dpm> ogra_, ack, cool <ogra_> asac, right, but we dont have anything for click translations yet <asac> i will put that on beuno's list :) ... one sec <ogra_> :) <asac> lol <ogra_> click does not know dependencies <infinity> pitti: Ahh, I hadn't thought about wordlists and such. <ogra_> pitti, ^^ <ogra_> *everything* (wordlists, translations, kbd layouts) would have to be inside the language click <ogra_> pitti, OSK uses hunspell <pitti> infinity: how can click install into a well-known path? <pitti> ogra_: thanks <ogra_> for word suggestions <pitti> ogra_: so we need to pre-install a reasonable set of hunspell-* <ogra_> yes :( <infinity> pitti: I've never looked at the implementation, but I assume clicks install to sane paths, somehow? <ogra_> the kbd language packages depend onthat <dobey> pitti: it can't. it can only install to /opt/click.ubuntu.com/${package_name} <infinity> pitti: Like com.canonical/langpack-foo or whatever? <ogra_> dobey, preinstalled clicks can install differently <infinity> dobey: That sounds like a well-known path to me. <dobey> ogra_: they install to /usr/share, but updates to go /opt/click.ubuntu.com/ <ogra_> oh, right <dobey> infinity: one well-known path per language <pitti> infinity: oh, you mean within the click pkg namespace, yes <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. <infinity> pitti: So, yeah, interesting thought exercise, probably not worth it for RTM. <dobey> infinity: yeah, a hook could handle creating symlinks inside a well-known path <dobey> infinity: that also opens up the can-of-worms of third-party langpacks, though :) <infinity> dobey: Does the click infra have no provision for validating origin? :/ <dobey> infinity: not at the moment. don't know when we'll get signed click packages <infinity> Whee. Fun. <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 <ogra_> seb128, pitti, even if we provided click packages for them we would need to initially ship them <ogra_> (like we do with the other preinstalled clicks) <seb128> ogra_, why? <seb128> ogra_, we could do "install spell suggestion from the store" and send people to the click lens or something <ogra_> seb128, youwill likely run the welcome wizard in the right language <asac> thats a factory thing <asac> factory install <ogra_> *before* connecting to WLAN or creating the U1 account <seb128> ogra_, we are discussing spell checking there <seb128> not language <ogra_> oh, sorry <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. <ogra_> infinity, perhaps ... <pitti> so if spell checking is working already, then that means we are shipping at least some (my|hun)spell-XX packages, no? <ogra_> but it will fork out into apps too <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 <ogra_> like the WLAN dialog <asac> some languages should be installed by default though <ogra_> or the U1 account setup <ogra_> asac, if we can fit them, *all* languages should be installed by default IMHO <asac> nah <seb128> ogra_, do you know if the current touch image includes hunspell binaries? <asac> just the most common ones. the rest is a factory problem <seb128> or myspell ones <ogra_> seb128, yes, it does <seb128> which ones? <ogra_> hmm <asac> infinity: you can guess language from the way people look. i swear i can recognize how the french look :P <asac> lol <infinity> asac: That's just because you're German, and all French people look frightened to you. <dobey> lol <asac> hehe <ogra_> seb128, http://paste.ubuntu.com/7629917/ <seb128> pitti, dpm ^ <ogra_> pulled in by the kbd packages <seb128> ogra_, thanks <pitti> ogra_: ah, thanks; so we are missing spanish and maybe a few others <ogra_> yep <ogra_> not sure why they are not there <dobey> let's just build different system images for different languages <ogra_> we surely ship the matching kbd packages <pitti> not sure why we need fr-classical <dobey> ubuntu-device-flash --language ja_US <seb128> dobey, not an option <infinity> dobey: That's a nightmare to QA, which is why we don't do it for desktop ISOs. <dobey> i was being facetious :) <ogra_> thanks !! <ogra_> :D <dobey> but it does get us the smallest images, available for the most languages :) <dpm_> thanks everyone! <pitti> thanks folks * ChanServ changed the topic of #ubuntu-uds-platform-1 to: Track: Ubuntu Development | click packages for the desktop | Url: http://summit.ubuntu.com/uos-1406/meeting/22312/development-1406-click-ftd/ <ogra_> asac, can we just move dobey to QA to implement that ? :P <pitti> dpm_: I put the gist into the BP whiteboard <pitti> dpm_: will you target that to utopic/milestone/etc, so that it appears properly on status and +upcomingwork? <pitti> dpm_: I put it to 14.06 for now <dpm> awesome, thanks pitti <asac> ogra_: who is dobey reporting into? <ogra_> dunno <asac> ogra_: if he is somewhere under olli then its easy :) <pitti> it's mvo TV! <mvo_> click for the desktop is at https://plus.google.com/hangouts/_/hoaevent/AP36tYdXzLigR8oAWSWyhsXq6IW0UXY4aBx8mc_bgDL1Kyj5sUb2iA?authuser=0&hl=en <asac> dobey: just kidding btw <pitti> mvo_: is that supposed to be live already? :-) <mvo_> pitti: yes, was testing but I stoped it now again <mvo_> eh, how can I start it again? <mdeslaur> mvo_: you're live for me <mdeslaur> oh, gone now <barry> back now <mvo_> can someone join? I feel a bit lonley <barry> the feed is not marked "live" and keeps ending after 1:15 <lool> mvo_: perhaps ping the subscribers <xnox> so the link on the summit needs updating <xnox> to the youtube url <xnox> i can join you <lool> barry: ah I guess broadcast was stopped <seb128> yes <seb128> mvo is starting a new one <seb128> you can't start again after stopping <mvo_> lets try again: https://plus.google.com/hangouts/_/hoaevent/AP36tYfd3PMw1nB_D9YbppXQYAASnq1k8GKDuIxM6FGGwOjQPGUAyQ?authuser=0&hl=en <mvo_> hrm, it still says off-air <xnox> mvo_: correct, start it <mvo_> xnox: but how? <seb128> mvo_, you didn't try starting that one yet though? <xnox> mvo_: there is a button <pitti> mvo_: it's live already, we can see you <pitti> on http://summit.ubuntu.com/uos-1406/meeting/22312/development-1406-click-ftd/ <seb128> mvo_, weird, the hangout says "off" <dpm> pitti, I think that's a failed old recording <seb128> pitti, that's the recording from the first one? <cjwatson> summit still seems to have the old hangout url <dpm> it's not live <pitti> oh, right <dpm> it's just 1:15 long <xnox> mvo_: http://summit.ubuntu.com/uos-1406/meeting/22312/development-1406-click-ftd/ <cjwatson> I got told I was the first one here when I tried it <xnox> STAND BY, restarting soon =) * sil2100 sigh <mvo_> we should be on air now <dholbach> mvo_, having fun? :-P <sil2100> It seems that this part is not really well supported * dholbach hugs mvo_ <barry> hey, reload! it's live now (but not feeding yet) <cjwatson> still says first one here for me <cjwatson> could somebody post the hangout url? <barry> \o/ <xnox> cjwatson: one sec. <ogra_> https://plus.google.com/hangouts/_/hoaevent/AP36tYfd3PMw1nB_D9YbppXQYAASnq1k8GKDuIxM6FGGwOjQPGUAyQ?authuser=0&hl=en <cjwatson> ta <dholbach> live! <xnox> cjwatson: ^ yeap above is correct. <asac> hmm. the youtube stream isnt online anymore? <xnox> asac: yes it is, it was restarted. You may need to reload the summit page <xnox> Youtube to watch is <xnox> https://www.youtube.com/watch?v=jj8gqeHXwCA#t=100 <asac> ah <asac> xnox: thx :) <dobey> or if you load plug-ins <mvo_> if you have questions, please ask them here <mhall119> QUESTION: Why can't we offer Click packages on X11 with a giant "Use at your own risk" disclaimer? <mhall119> it would still be better than telling them to use a PPA <cjwatson> disclaimers don't work <cjwatson> it is always more interesting to get your work done than to care about a disclaimer <mhall119> even when it's not enabled by default? <cjwatson> yes <cjwatson> we talked about this in Oakland and definitively ruled it out :) <dobey> mhall119: clicks can be installed already and run on x11. <mdeslaur> we don't want people to start uploading apps that specifically try and escape confinement with X11 <mhall119> but the alternative is still to use a PPA right? <mdeslaur> it would be trivial <dobey> but we don't support it <cjwatson> you can install click packages by hand, but we won't offer any UI for it <cjwatson> on X11 <cjwatson> and indeed PPAs work <xnox> mhall119: use ppa and normal deb. There is no gain in using click for an X11 app. <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 <mhall119> could we offer supported click packages from the store if they had the same level of review as deb packages in extras? <mhall119> QUESTION: could we offer supported click packages from the store if they had the same level of review as deb packages in extras? <xnox> mhall119: no, because we don't scale enough. <xnox> mhall119: get your X11 apps into universe. <xnox> mhall119: or a ppa. <cjwatson> it would be better to spend that time on making things work with mir/unity8 <cjwatson> it's a LOT of time <mhall119> xnox: that's a good deal harder than making a click package <asac> right. we want to get exactly out of the business provding the middleman service <asac> to review etc. <cjwatson> actually non-trivially expensive <mhall119> cjwatson: my concern is what we do to support 3rd party desktop apps over the next year before Mir replaces X11 as default <cjwatson> multiple full-time people to deliver even a pretty small trickle of review in the grand scheme of things <cjwatson> and we have tried the review path in the past and it has spectacularly not worked <mhall119> yes, I'm painfully aware of that <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 <mhall119> ^^ that would make me happy <dobey> asac: we already have that. i don't know if we'll provide any UI for it though <xnox> asac: deb based installations are still supported. <xnox> asac: bringing click to the desktop does not exclude running .debs <asac> of course <cjwatson> clicks don't have signatures yet :) <mhall119> but clicks are easier to make <cjwatson> so yes <asac> but i hear that you can install clicks even if they are not in store <cjwatson> you can do this by hand today <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 <cjwatson> but I'm not prepared to offer something that will be a malware vector for people <cjwatson> for developers, absolutely <mhall119> cjwatson: from the commandline only though, so it's not an ideal way for a 3rd party dev to distribute to end users <dobey> we don't have signature checks <xnox> mhall119: "clicks are easier to make" -> that's not true =) making binary debs are also easy. (e.g. with dpkg-deb -b) <asac> cjwatson: right. its like "developer mode" <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 <asac> ack <cjwatson> for developers testing things I have no issue <mhall119> cjwatson: but if you s/click/deb/ we already do <dobey> xnox: making the metadata to build a deb is harder (especially to do it properly) <cjwatson> mhall119: no, because of the review path <cjwatson> anything that we offer by default in the software centre is reviewed by people in Canonical or in the Ubuntu community <mhall119> sorry, didn't mean to sidetrack the session <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. <xnox> dobey: e.g. plex server, google chrome, and a lot of other ISVs provide debs, in simplistic ways without being policy compliant. <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 :) <xnox> dobey: e.g. CPack from cmake can spit out .debs for you. <dobey> xnox: you're overestimating the ability of 3rd party devs to understand and use cmake or such :) <asac> QUESTION: what is the plan on a build system for open source / distro software that we want to put into a click? <cjwatson> can we table that for later? <asac> (hope thats on topic here even not strictly desktop <cjwatson> I don't think it really fits here <asac> cjwatson: yes <asac> cjwatson: if time is left would be cool to here the story, otherwise later <cjwatson> (I've had some discussions with William on this but they're pretty early stage) <asac> ok <dobey> cjwatson: we're going to build an install manager service, which will do purchasing, download, and install <cjwatson> right but click should be able to call out to it <cjwatson> the layering is wrong right now IMO <cjwatson> or at least the PK plugin for click <dobey> right. the click store requires authentication though <cjwatson> sure <mvo_> dobey: do you want to join the hangout maybe :) would be easier for the people listening <mdeslaur> is someone playing the recorder? :) <mvo_> and watching <cjwatson> callout makes sense, I just want the requests to click to be of the form "install this package" not "install this file" <cjwatson> i.e. like apt rather than dpkg <cjwatson> iyswim <dobey> maybe we need to discuss that more outside this session then <asac> i assume desktop shoots for multi user support from day 1 right? Is it maybe feasible to allow per-user install of click? <cjwatson> I think these two things are compatible <cjwatson> asac: designed that way from the start :) <cjwatson> all works today <asac> cjwatson: so you can do user or system wide? nice!! <asac> if i run click install as root it goes system wide or how does that work? <cjwatson> the installation is done as root in order to make sure that you can't write to the app directory as your user <cjwatson> but packages are registered per-user, or registered "for all users" (effectively system-wide but overrideable) <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 <asac> cool stuff <mhall119> pre-install the core apps <mhall119> terminal :) <asac> thanks! :) <barry> yes, it would be really nice to be able to generate both a click and deb at the same time <asac> why would want produce both? <barry> both locally and in a ppa <asac> yeah kind of :) <asac> more discussion needed <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 <cjwatson> like I say a bit handwavy as yet <cjwatson> it would be a relatively easy place to start though <asac> yeah its fine <lool> mvo_: source packages are reproducible, but in practice we build them in special ways all the time <lool> like from bzr branches, git branches, with orig tarball etc. <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 <lool> so it's still a bit of a complex situation there too <asac> so kind of a "agreed best practice" for ubuntu supported clicks :) - whatever that might be <cjwatson> right, I think we need to step back and survey what people are doing some months into click packages <asac> right. is the current jenkins infrastructure good enough to gain time to think and observe? <cjwatson> the internal use thing is my main driver right now <asac> i dont think we have a solution for building for multiple archs <cjwatson> that's fine for internal use, says nothing about apps
{'channel': 'ubuntu-uds-platform-1', 'month': 6}