13:00:10 #startmeeting Fedora Workstation WG 13:00:10 Meeting started Mon May 11 13:00:10 2015 UTC. The chair is stickster. Information about MeetBot at http://wiki.debian.org/MeetBot. 13:00:10 Useful Commands: #action #agreed #halp #info #idea #link #topic. 13:00:16 #meetingname workstation 13:00:16 The meeting name has been set to 'workstation' 13:00:19 #topic Roll call 13:01:01 * Capesteve waves 13:01:11 * mcatanzaro is here. 13:01:35 hi 13:01:40 hello 13:01:46 o/ 13:01:56 /me waves 13:02:17 here 13:02:24 #chair juhp_ kalev mcatanzaro mclasen_ rdieter 13:02:24 Current chairs: juhp_ kalev mcatanzaro mclasen_ rdieter stickster 13:02:54 * mclasen_ still struggling to internalize the new time 13:03:31 I think we have quorum, so let's get started 13:03:43 One quick order of business: 13:03:49 #topic Workstation report for FESCo 13:03:55 #link https://fedoraproject.org/wiki/Workstation/Fedora_22_Workstation_FESCo_report 13:04:24 As seen on the list... I'm making this available to sgallagh following this meeting, so if you have any changes, please edit the wiki or respond to list 13:05:49 In the meantime, we can move on :-) 13:05:55 * mclasen_ admits not having read it until now 13:05:56 #topic F23/F24 Workstation planning 13:07:08 Here's the fun stuff. :-) The existing Workstation PRD is quite broad. So as I was working on that report, it occurred to me that we need to come up with more specific changes that will take developer experience to the next level. 13:09:03 A lot of the changes were inherited from upstream GNOME -- which is great, because Fedora is supposed to collaborate upstream. But IMHO we need additional focus on features that specifically attract relevant folks to Fedora Workstation. 13:10:35 we should look at container tools, maybe 13:10:37 For instance, we have a DevAssistant app which does environment and project setup. But AFAIK there's no seamless way to package up work into a deployable form 13:10:48 mclasen_: *jinx, kinda :-) 13:11:10 stickster: cschalle and I were discussing on Friday a number of improvements we could make to Fedora's behavior within an AD/FreeIPA domain as well. 13:11:25 like, whats it called, the oh my vagrant stuff 13:12:06 SLED has some AD patch for gnome-shell, but I'm not sure exactly what it's for. 13:13:15 mcatanzaro: I'd be very interested to learn about that. Any link? (DDG is failing me at the moment) 13:13:33 * mclasen_ unsure why the shell would need to be involved 13:14:11 mclasen_: sgallagh: Good ideas both... what's the right way to flesh those ideas out? Should we describe what the improvement looks like to the user? 13:14:25 +1 for container tools 13:14:35 My search for a link has led me to believe I am completely crazy, maybe not. :D (Continues to search....) 13:14:59 * mcatanzaro remembers looking at it yesterday, confused. 13:15:47 stickster: On the AD front, I'd say that a major user-experience change would be that users who have authenticated to a machine in a domain should automatically have access to domain-enabled services (such as web applications like SharePoint). 13:16:39 Right now, users have to make manual edits to their browser config to do stuff like that. 13:17:14 stickster: we could reach out to purpleidea - I don't know if his stuff is already in fedora or not 13:17:22 https://build.opensuse.org/package/show/SUSE:SLE-12:Update/gnome-shell 13:17:26 ^gnome-shell-domain.patch 13:17:35 sgallagh: How seamless is the current experience for things like access to file shares, printers, etc. in those domains? 13:18:08 mcatanzaro: Looks like an alternative implementation of the realmd UI. 13:18:22 FWIW access to normal home printers is too hard right now (requires admin authentication) 13:18:26 stickster: The seams are so wide you can't see one side from the other :) 13:18:56 * mclasen_ asks halfline about that domain patch 13:18:58 sgallagh: Ugh :-) but that's what I expected 13:19:18 mcatanzaro: Does that have something to do with the default PolicyKit policies? 13:19:31 stickster: Yes 13:19:45 mcatanzaro: Seems like low-hanging fruit we should fix. 13:20:15 I know this was a firestorm about... I dunno, 4 releases ago? But that was before we broke the editions out 13:20:28 Hey, we need to get these ideas in the minutes. 13:20:36 #idea Improvements to AD/FreeIPA domain behavior (integrate WS into mixed env) 13:20:52 #idea Container tools for developers to use on projects / integrate with DevAssistant 13:20:57 my understanding is that there is at least one part of the cups setup that requires local root auth, that is not yet polkit-ized 13:21:12 #idea Make home printers easier to access without admin authN 13:21:43 rdieter: You can definitely do everything for most printers from gnome-control-center, no root required. 13:22:05 mcatanzaro: that's what I was told when I complained to dev behind kde's printer applet 13:22:21 If you want to access the cups web server that runs locally, then you need to log in as root. 13:22:49 stickster: #idea Access to Active Directory printers and file-shares should be simplified 13:22:52 (I'm not chaired) 13:22:56 #chair sgallagh 13:22:56 Current chairs: juhp_ kalev mcatanzaro mclasen_ rdieter sgallagh stickster 13:23:03 #idea Access to Active Directory printers and file-shares should be simplified 13:24:05 * mclasen_ has little hope for making AD integration work nicely unless we use it internally 13:25:02 mclasen_: simply because we need daily access to a working domain to effectively develop fixes? 13:25:43 dog food'ing stuff never hurts 13:26:12 rdieter: In this case, might be more like s/never hurts/is crucial/ :-) 13:27:29 On a related note, the container/deployment idea might require -- or at least benefit from -- some infrastructure behind it. As the person who manages some folks who work full time on infrastructure, this is of interest to me :-) (Mr. Selfish) 13:28:08 stickster, mclasen_: I'm looking into ways we can work with a partner for dogfooding purposes. 13:28:26 I will report back when I have someone on the line 13:29:01 sgallagh: That would be really helpful. I have no idea whether Fedora infra has the capability to provide (in an easy to provision way) a Windomain -- making it integrate in our process could be doubly as hard as the development work 13:29:38 But for the container stuff -- that seems like a lower bar, at least to my untrained eye 13:31:24 * rdieter trying (and mostly failing) to pull actionable items from recent "Why people are not switching to Fedora" thread 13:31:30 The question is what we want for an end user experience... end-user dev can spin up a container on a choice of (a) self-hosted Box; (b) service-hosted system (EC2, GCE, other?) 13:31:58 rdieter: I haven't yet had time to review the whole thread but I was hoping someone else would have input from it in this discussion. :-) 13:32:49 juhp_: What did you get out of that thread? (/me mercilessly calls on Jens since we are finally meeting when he's available) ;-) 13:32:53 the only thing I can think of is giving help/assistance to make rpmfusion better somehow 13:33:20 Ah, cschalle is here now too 13:33:22 #chair cschalle 13:33:22 Current chairs: cschalle juhp_ kalev mcatanzaro mclasen_ rdieter sgallagh stickster 13:33:35 stickster, I am afraid I haven't read it yet... will try to look over it 13:34:04 rdieter: I didn't see what help people were seeking. Is it a release process issue? 13:34:14 sorry for missing so many meetings - I think I missed the new time 13:34:27 juhp_: We just started this new time a few instances ago :-) 13:34:28 stickster: There is no rpmfusion for F22, and at the rate they're going there will not be. 13:34:33 rdieter: Unfortunately, we can't really do that. We've been told by The Lawyers that providing people with information on how to get to RPMFusion could be construed as "contributory infringement" 13:34:34 okay :) 13:34:50 stickster: nothing specific, just many complaints were that rpmfusion was unsatsifactory, for reasons unknown 13:34:58 mcatanzaro, hmmm 13:35:04 what we can do though, is work with rpmfusion or similar to split out the parts of rpmfusion the lawyers are not worried about 13:35:13 I *do* recall seeing cschalle posted some follow ups noting that the third party issue seems to be a real barrier for people. I also understand the contributory infringement problem and that we need to exercise care here 13:35:17 one relatively frequent complaint is that rpmfusion lags behind 13:35:17 cschalle: Those parts don't exist. 13:35:19 sgallagh: I'm talking more about making rpmfusion itself better, not changing fedora at all 13:35:21 ie no f22 branches yet 13:35:22 Ah, hi cschalle, you can speak for yourself now :-D 13:35:36 If the lawyers weren't worried about it, they'd be in Fedora proper already 13:35:56 sgallagh, they do, there are a lot of stuff in rpmfusion that are not problematic from a legal perspective, Steam client being one example 13:36:10 sgallagh: agreed, fedora itself cannot legally do anything differently (as far as patented stuff goes) 13:36:13 cschalle: Oh, you're talking about the non-free repo 13:36:33 cschalle: Steam is nice to have, but MP3 and H.264 are must-have, so splitting doesn't help much. 13:36:37 cschalle: RPMFusion's "free" repo is all stuff we can't ship because of licensing/patents 13:36:38 Yeah, there's really non-free-but-legal and non-free-but-we-think-legally-questionable 13:36:50 /me nods 13:36:53 mcatanzaro, no, but there we might be able to do something throught Cisco and Fluendo 13:36:59 the 'free' rpmfusion repo has some f22 builds now 13:37:04 The non-free-but-legal situation is one we could do something about, with Council approval 13:37:21 sorry for intruding, but the main problem with rpmfusion lagging is that they are understaffed (1 person is maintaining the build infra and struggling with migration from *plague* to koji) 13:37:23 sgallagh: Only as long as people understand this is not about trying to push Fedora itself toward non-freeness 13:37:30 It's *technically* a violation of ancient Fedora dogma, but maybe it's an acceptable violation. 13:37:40 * mclasen_ throws https://github.com/purpleidea/oh-my-vagrant in for people who might not know what he was talking about earlier 13:38:02 number80: Yeah, I think people understand that well -- it's a struggling volunteer effort, and the nature of rpmfusion makes it difficult for Fedora to commit resources to help 13:38:17 mclasen_, heh, I thought you where trying to be funny by referring to it as 'oh my vagrant' :) 13:38:18 number80: I am not sure we can actually contribute to their efforts without getting fedora/redhat in potential trouble? 13:38:32 cschalle: Cisco and Fluendo both have completely open source codecs that the lawyers would be OK with, but the problem is the license on their binaries is nonfree.... 13:38:42 stickster: question, would it be possible to fund rpmfusion somehow ? 13:38:45 mcatanzaro, yes, but that is not a legal issue 13:38:47 mclasen_: Thanks -- I don't believe that's packaged in Fedora yet, not sure how high a bar that is and whether upstream would be interested, but we should talk to purpleidea about it 13:38:59 kalev: IANAL, but if non-redhat employees were to volunteer their time, I doubt it would reflect on Red Hat 13:39:06 #idea Talk to purpleidea about packaging oh-my-vagrant as part of container tooling 13:39:44 number80: I kind of doubt that. Prima facie sounds like it would run afoul of the "contributory" definition 13:40:05 there are also some parts of the rpmfusion free that it might be time to review again for their freeness, been seeing some claims that the remaining freetype stuff should be mergable for instance 13:40:20 mcatanzaro: there is RPMFusion for F22 13:40:31 and mp3 patents are about to expire, as I keep hearing 13:40:32 Maybe we can get our codec installer to point to Cisco/Fluendo codecs? They would be unacceptable for corporate deployments, but perfectly fine for home users. We just have to make gnome-software show EULAs. 13:40:32 mclasen_, thanks 13:40:41 well, rpmfusion is hosted in France where it complies with our local laws (the only package that couldn't be shipped was libdvdcss) 13:40:47 pingou: There wasn't a week or so ago; that's good. 13:41:19 pingou: ISTR seeing an update to the keys recently, probably that's a sign of the update? 13:41:21 cschalle: did you look back at previous discussion around freetype ? 13:41:34 maybe best to wait until owen is back 13:41:35 cschalle: fwiw, I checked into rpmfusion/freetype recently, there's one remaining patent 13:41:41 stickster, the 'rawhide' repo has f22 builds now 13:41:41 mclasen_, ok, sorry must have missed that 13:41:54 rdieter, is it the MS colour mask thing? 13:42:19 cschalle: I meant old discussion on the mailing lists, not backscroll in this channel, fwiw 13:42:25 cschalle: sorry, I don't recall details, just that it is the last/only thing that rpmfusion's freetype differs compared to fedora's 13:42:27 rpmfusion is also too difficult to install. 13:42:42 (and interestingly, ubuntu enables that feature) 13:42:52 also I asked the graphics guys to investigate the s3TC patent stuff, as it might either be invalid (seems to have been part of some HTC vs Apple lawsuits that HTC lost, or it can be replaced by the new TC API in newer OpenGL) 13:43:04 mcatanzaro: Not only that, but I'm not sure that, once you *do* install it correctly, codec or other capability searches work consistently 13:43:10 rdieter: subpixel rendering? 13:43:16 * rdieter checks 13:43:21 mcatanzaro: 2 links to click on? 13:43:30 mcatanzaro: Hard to tell when the repos themselves are having issues (as number80 correctly pointed out) 13:43:31 stickster: they do afaik 13:43:32 pingou, the problem is arriving to these 2 links 13:43:33 mcatanzaro: yeah, I think that's it 13:43:47 rdieter, ok, because the claim I saw on the freetype website was that the last patent only applied to a very specific algorithm and thus one could use a different one to achieve same/similar results 13:43:57 bochecha: it's just in every howto out there :) 13:44:16 cschalle: which one does freetype use? 13:44:22 rdieter, the MS one 13:44:27 sigh 13:44:29 you guys are really good at pointing out all of the problems, but i'm not seeing any solutions being suggested 13:44:45 cschalle: so... it's fixable, except no one has bothered to do it yet? 13:44:48 As far as the difficulty to install the repo, I'd like to see us work on a mechanism for making repo installation via a browser really easy. 13:44:51 rdieter, I guess so 13:44:52 jwb: +1 13:45:08 pingou: The homepage needs to have the download link, and it should be prominent. Not on a page linked to from the homepage as part of a list of other links. That's hidden. And there should not be any instructions for using the terminal; users get things messed up when they try to use the terminal. 13:45:23 We can install RPMs via browser link, but having a "blessed" mechanism to install both a repo and a package from that repo at the same time would be significantly useful. 13:45:24 mcatanzaro: I'm sure they will welcome this input :) 13:45:26 sgallagh, that shouldn't be hard, but what people seem tired of is needing to go google hunting for their software to begin with 13:45:41 cschalle: People have to do that on Windows and seem to live with it. 13:45:55 It would still be a significant improvement, even if not perfect. 13:45:56 sgallagh, less and less as also windows is moving to the appstore model 13:46:04 (Perfect is the enemy of good, and all that) 13:46:14 windows doesn't have to worry about being freely redistributable either 13:46:52 rdieter, sure, but as long as we don't actually put any of this software into our install media that shouldn't be an issue 13:47:24 Right, which is why reducing the barrier for people to install third-party stuff is still an improvement 13:47:31 Even if we can't show it in GNOME Software itself. 13:47:44 Anyway I think we should aim for having MP3 enabled out-of-the-box in F23. Wikipedia says the last known patents expire in September, so unless our lawyers tell us otherwise, we might as well use the upstream gstreamer MP3 codec. But for H.264, our only option is the Cisco codec, I think. :( 13:47:58 sgallagh: If we don't show something in Software, what is the actual barrier reduction you're proposing? 13:48:06 cschalle: and make sure it's clearly ... deliniated (looking for better term). fedora advertises itself currently as being 100% freely redistributable... adding content like this changes that expectation 13:48:09 * pingou remebers the time where windows' app store was a website where I was reasonably confident I wouldn't get viruses 13:48:30 mcatanzaro: +1 yay 13:48:31 stickster: The ability to click on a single link somewhere on the internet, have that piece of software installed and a repo automatically added that will keep it updated. 13:48:53 We do not have that today. You can either install a repo and then install software from it, or install a single RPM and not have it updated. 13:49:04 (Exception: Chrome which ships the repo file in the RPM) 13:49:10 if you click on the rpmfusion-release rpm from FF, it will ask to install it and you're done, no? 13:49:19 rdieter, agreed, and as Isaid I don't plan on including any such software by default. If people choose to install stuff that hinders them from copying their install to other people freely then that is not our issue (nor a very common usecase I would think) 13:49:26 pingou: he wants software+repo in one click 13:49:29 pingou: Right, but it's still two steps to get whichever software you wanted 13:49:48 ah, install the repo at the same time you install, say vlc 13:49:54 pingou: Precisely 13:49:56 sgallagh, couldn't everyone just do as Google? 13:50:06 cschalle: we're talking 2 different things I think. I'm talking about fedora "as a whole", not just fedora workstation 13:50:09 sgallagh, and bundle the .repo file 13:50:12 I'm curious where the contribution barrier of the RPMFUsion project lies, for the folks that feel that RPMFUsion is inadequate as-is 13:50:15 cschalle: And have *every* package in the repo bundle the repo file? 13:50:24 That's one approach, sure. Kind of ugly, but doable. 13:50:27 cschalle, if both vlc and rpmfusion's freetype provide the rpmfusion repo configuration file, you'll get file conflicts 13:50:48 bochecha: There's no capability in rpm libs to manage that? 13:50:51 bochecha, I was more thinking in the scenarios with 1 app 1 repo 13:50:53 What I'm talking about is figuring out the best way and advertising that so RPMFusion, Steam, etc. can all have one vetted way to accomplish it 13:51:02 sgallagh: +1 13:51:04 bochecha: not of the repo content is identical, but it is problematic and dangerous (ie, if you ever have to modify the .repo playload) 13:51:15 bochecha: Not necessarily, as long as they're all the exact same file with the same timestamp, but that's hard to accomplish. 13:51:23 typos about, s/of/if/ and s/playload/payload/ 13:51:27 cschalle: then you're back to the windows model where each app brings along its update process (here the repo file) 13:51:45 pingou: http://rpmfusion.org/ <-- no F22 there, and none of the links in the matrix are RPMs. That matrix should contain RPMs to install, and all the details should be buried elsewhere. 13:52:03 pingou, sure, but we are already heading that way with the application bundles 13:52:05 sgallagh: Or some wrapper data that Software understands which helps mitigate the problem 13:52:08 it's not the end of the world yet if there's 2 steps (repo + software), I think there are bigger issues to worry about, imo 13:52:08 sgallagh, stickster, cschalle: I didn't mean necessarily conflicts in the sense of rpm refusing to install, but rather all the possible issues that can come out of it (as rdieter mentioned, what if the user modifies that file?) 13:52:18 bochecha: *nod, OK 13:52:32 * rdieter wonders how opensuse one-click stuff works 13:52:33 * stickster considers maybe he just suggested a worse hack, and shuts up. 13:52:50 how is the codec problem solved in RHEL? doesn't RHEL come with a set of non-free codecs out of the box? 13:52:56 kalev, no 13:53:03 arr. :( 13:53:10 kalev, I think it is 'solved' by recommending users to contact Fluendo 13:53:45 mcatanzaro, good point about the front page, even better if you report it appropriately 13:53:48 If you're paying for RHEL, you presumably don't mind paying a fraction of that for Fluendo's codecs. 13:54:03 because that can be fixed easily 13:54:09 perhaps there's some way to advocate unencumbered codecs? 13:54:36 randomuser: been there done that (still doing it) 13:54:44 And yet, the world moves on ;-) 13:54:45 rdieter++ 13:54:50 randomuser: Hopeless, we can't convert all the media on the Internet... unless we convince Google to drop H.264, like they promised to do years ago, which I bet they will never do now. 13:54:57 randomuser, well the problem with codecs is that they are rarely the users decision. They are most likely captive to whatever website xyz are offering 13:55:22 the user doesn't have the same advocacy leverage that we (you, etc) do 13:55:45 * rdieter echos jwb comment earlier, can we focus on actionable stuff? seems like we're going in circles about unfixable things 13:55:47 So we are knee-deep here in the codec problem... understandable, because it's a clearly identified issue 13:55:56 Yeah, what rdieter just said 13:56:24 well as soon as the contract with Cisco is signed and sorted I do plan on proposing a solution based on that 13:56:32 We need to talk to the gstreamer folks about getting the MP3 codec included by default, that is easy and actionable. 13:56:36 so that should be actionable enough :) 13:56:53 stuff I recall: * continue work on including legal (but non-free) stuff in fedora (somehow) 13:57:05 mcatanzaro, it is not a GStreamer issue, we just need an agreement with Fluendo and a yum repository 13:57:44 #proposed Someone knowledgeable in each of the tabled #ideas for improvement to draw up some sort of user story / deeper description of the problem and how we might fix in F23/24 timeframe 13:57:46 cschalle: We don't need to involve Fluendo at all IMO; let's use the upstream gstreamer MP3 codec. 13:58:05 mcatanzaro: it's more than just mp3 at issue here 13:58:10 mcatanzaro, we can not do that without risking patent infringement issues 13:58:23 cschalle: mp3 patent expires soon 13:58:30 mcatanzaro suggested the patents expire in time for f23 13:58:34 OK guys, codecs is just ONE issue -- we have a number of #ideas above, can we agree on how to move forward with all of them, not just beat on codecs? :-) 13:58:51 ah ok, need to recheck then, last time I looked we still seemed to be a couple of years away 13:58:56 There's an idea on container tools / deployment 13:59:15 There's an idea on AD domain integration for easier web service use 13:59:22 stickster, maybe bring that one up with langdon and see how he could help? 13:59:23 There's an idea on AD domain integration for easier file / print service use 13:59:29 cschalle: MP3 is September, according to Wikipedia, so let's include it unless the lawyers tell us otherwise. H.264 is a problem, but for that we need Cisco not Fluendo. 13:59:31 may help to have an advocate/champion for these items, any volunteers for codecs (or even specific items like mp3 alone)? 13:59:44 stickster: Also for easier access to internal [web-]applications 13:59:56 There's an idea on making native printer use easier 14:00:07 Printers should be easy; I will take that. 14:00:14 mcatanzaro, agreed, although we might still want to use the Fluendo implementation simply because of its licensing and non-bundledness 14:00:21 Just changing a couple values in a .policy file. 14:00:28 We are out of time, but I'll make sure each of these has a person assigned 14:00:55 stickster: I'll take the AD stuff at least for investigation (and likely some of the implementation) 14:00:57 #action stickster assign people to each of the #idea parts to make sure we have a better defined problem (and maybe solution ideas?) for next meeting 14:01:03 Thank you sgallagh and mcatanzaro 14:01:17 We need to clear the room, I think randomuser has a meeting in here that we are stomping on 14:01:26 --> #fedora-workstation 14:01:41 #endmeeting