=================================== #fedora-meeting: FESCo (2014-11-12) ===================================
Meeting started by nirik at 18:00:03 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2014-11-12/fesco.2014-11-12-18.00.log.html . Meeting summary --------------- * init process (nirik, 18:00:03) * #1365 A unique system-wide TMP directory for all programs and sane ways to retrieve the default (nirik, 18:02:24) * LINK: https://fedorahosted.org/fesco/ticket/1365 (nirik, 18:02:24) * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=1161110#c4 (nirik, 18:06:18) * AGREED: FESCo does not currently want to mandate $TMPDIR being reliably consistent throughout an user session. If claws-mail requires a consistent place to use, it should use a different mecahnism. (+6,0,0) (nirik, 18:21:26) * #1359 Automatic OpenH264 download by Firefox (nirik, 18:21:47) * LINK: https://fedorahosted.org/fesco/ticket/1359 (nirik, 18:21:48) * AGREED: ask firefox maintainers to disable automatic download of OpenH264 plugin (+6,0,1) (nirik, 18:32:04) * nirik will draft a page (nirik, 18:35:28) * AGREED: will keep ticket open a week for interested parties to propose longer term solutions. (+6, 0, 0) (nirik, 18:48:21) * next weeks chair (nirik, 18:48:33) * t8m to chair next week. (nirik, 18:49:42) * Open Floor (nirik, 18:49:45) Meeting ended at 18:52:35 UTC. Action Items ------------ Action Items, by person ----------------------- * **UNASSIGNED** * (none) People Present (lines said) --------------------------- * nirik (84) * mitr (50) * jwb (43) * t8m (32) * kalev (28) * dgilmore (19) * drago01 (14) * mattdm (12) * thozza (10) * zodbot (6) * mclasen (4) * pjones (2) * mmaslano (0) * sgallagh (0) * stickster (0) -- 18:00:03 <nirik> #startmeeting FESCo (2014-11-12) 18:00:03 <zodbot> Meeting started Wed Nov 12 18:00:03 2014 UTC. The chair is nirik. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:00:03 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic. 18:00:03 <nirik> #meetingname fesco 18:00:03 <nirik> #chair dgilmore jwb kalev mattdm mitr mmaslano nirik sgallagh stickster t8m thozza 18:00:03 <nirik> #topic init process 18:00:03 <zodbot> The meeting name has been set to 'fesco' 18:00:03 <zodbot> Current chairs: dgilmore jwb kalev mattdm mitr mmaslano nirik sgallagh stickster t8m thozza 18:00:10 <thozza> hi 18:00:13 <jwb> hi 18:00:14 <mitr> Hello 18:00:25 <kalev> hi 18:00:38 <nirik> morning everyone. 18:01:01 <mattdm> hello! 18:02:15 <nirik> ok, I guess lets dive in. A pretty short agenda today... 18:02:24 <nirik> #topic #1365 A unique system-wide TMP directory for all programs and sane ways to retrieve the default 18:02:24 <nirik> .fesco 1365 18:02:24 <nirik> https://fedorahosted.org/fesco/ticket/1365 18:02:26 <zodbot> nirik: #1365 (A unique system-wide TMP directory for all programs and sane ways to retrieve the default) – FESCo - https://fedorahosted.org/fesco/ticket/1365 18:02:34 <nirik> this sort of stalled out after last week... 18:03:04 <nirik> firefox folks removed their hack... 18:03:31 <nirik> so they use /tmp again in rawhide. 18:04:14 <kalev> that sounds like a regression 18:04:35 <nirik> regression? 18:04:46 <kalev> downloading multi gigabyte files into /tmp would probably easily fill it up 18:04:48 <mattdm> well, that's going to fill up with big downloads 18:04:59 <nirik> well, only if people don't say where to download them too... 18:05:05 <dgilmore> hola 18:05:07 <t8m> hi, sorry for being late 18:05:15 <nirik> it only uses that until the save dialog not answered. 18:05:46 <nirik> so I guess somone could save an iso and not answer the dialog and fill up space. 18:05:47 <mitr> While I have questions around that, I’m not sure we should be micromanaging individual component’s behavior 18:05:49 <kalev> my understanding is that they should continue using /var/tmp for that purpose 18:06:12 <mitr> If we ended up researching Firefox and proposing Firefox changes today, that would get us no closer to resolving 1365 18:06:18 <nirik> https://bugzilla.redhat.com/show_bug.cgi?id=1161110#c4 18:06:30 * nirik is with mitr 18:06:31 <t8m> mitr, +1 18:06:38 <kalev> which they did previously, but the problem was the way they achieved it, by overriding the TMPDIR variable which incidentally then also override it in the env passed to other programs 18:06:48 <nirik> so do we have some distro wide policy or proposal here? 18:07:04 <mitr> Proposal: design a sane system-wide API with a single implementation. 18:07:09 <mitr> There, that’s going to help, isn’t it? 18:07:09 <t8m> kalev, they want to stop that and use /tmp from now 18:07:12 * mitr shuts up 18:07:23 <nirik> mitr: sure... but then the questions come. ;) 18:07:26 <t8m> mitr, heh 18:07:40 <t8m> mitr, is there actually a way tho get a sane API? 18:08:05 <mitr> t8m: All it would take is FESCo saying Thou Shalt Use $library and “I don’t like it” doesn’ 18:08:09 <mitr> t count as a reason not to. 18:08:17 <mitr> Are we willing to do it and would we want to? 18:08:18 <jwb> wait, what? 18:08:35 <jwb> we have to write a library to have a system-wide tmpdir location? 18:08:38 <dgilmore> I really do not think we can mandate anything that will fix this 18:08:41 <drago01> mitr: well you could avoid that by adding it to libc 18:08:52 <mitr> t8m: Technically this is easy enough, but it would be a very noticeable change to FESCo’s typical role. 18:09:03 <jwb> drago01, no you can't. 18:09:07 <dgilmore> it would need to be something worked on by all upstreams and all other distros also 18:09:19 <t8m> mitr, I am afraid that this change of FESCo's role is not something that would pass 18:09:22 <drago01> jwb: so people complain about having to use libc? 18:09:25 <mitr> drago01: Having it in a library doesn’t yet imply usage. 18:09:35 <jwb> what mitr said 18:10:14 <pjones> mitr: surely that's mkstemp()/mkostemp() and we should mandate using it anyway for the obvious reasons? 18:10:45 <drago01> mitr: oh well misread your comment then ... I though you meant people would say I don't want to use $lib ... which wouldn't happen if $lib is libc but anyway ot 18:10:57 <mitr> jwb: Well, it’s either define a hard-coded convention for a path to use (in some way that promises the /tmp-on-tmpfs app-breaking redefinition will not reoccur), or define a common configuration mechanism to use to determine the path, something different than env variables because they don’t work so well. 18:11:05 <nirik> I think the ticket reporter is looking for something like a "you should use /tmp by default for tmp files and you should honor $TMPDIR to override that" ? 18:11:12 <jwb> or do nothing 18:11:17 <jwb> which is what i think we should do here 18:11:31 <mitr> Note that #1365 has an _underlying assumption_ that the path should be configurable, not hard-coded; I don’t think we have really discussed this. And there is yet one more underlying assumption that claws-mail is using $TMPDIR for its intended purpose, which I’ 18:11:35 <mitr> m not entirely sure about. 18:12:04 <mitr> pjones: AFAICS mkstemp() doesn’ 18:12:18 <t8m> nirik, unfortunately that is broken by the tmp on tmpfs 18:12:19 <mitr> t define the directory, and random names wouldn’t be usable for the claws-mail usage of IPC 18:12:31 <jwb> t8m, no it isn't 18:12:36 <t8m> yes, it is 18:12:38 <nirik> t8m: well, 'broken' isn't what I would say... 18:12:45 <nirik> really it means it's more nuanced... 18:12:47 <drago01> mitr: if its use is ipc it should use /run 18:12:48 <pjones> mitr: okay but they can be fixed at one place for the former case. for the latter, .... 18:12:58 <jwb> no, it isn't. you may have less space, but you still are bounded by however much space is available to /tmp 18:13:00 <t8m> tmp on tmpfs creates artificial limits on /tmp usage 18:13:11 <jwb> that's not "broken" 18:13:16 <t8m> that is broken 18:13:25 <mitr> Let’s forget about /tmp as a _solution_ and instead talk about _requirements_? 18:13:38 <jwb> t8m, we've now reached a pointless point in our conversation so we'll just stop. 18:13:42 <t8m> yes 18:13:49 <nirik> "you should use /tmp for tmpfiles you don't care about keeping accross reboots that are smaller than memory + swap, you should use /var/tmp for tmp files you don't care about keeping accorss reboots that are smaller than your /var/tmp, you should use $HOME/.local/tmp for files you want to keep accross reboots that are smaller than your homedir...etc. etc. 18:14:21 <nirik> ie, there is no answer to "what should tmp files always use all the time" 18:14:38 <mitr> nirik: This is actually a good start, separating the use cases. 18:14:44 <t8m> Proposal: Close the issue as Reject 18:14:58 <mitr> But then, how will a poor newbie programmer (coming from Windows or Android) ever find the convention; hence my talk about an API. 18:15:00 <nirik> right, but then everything gets more complex. ;) and there's likely more use cases. 18:15:17 <jwb> mitr, a poor newbie programmer is not going to be reading Fedora conventions to figure that out. 18:15:35 <t8m> Why do we want a bazillion of tmp directories for god's sake 18:15:41 <mitr> jwb: No, but they _may_ be using devhelp for the library they are already using to open files. 18:15:47 <mitr> t8m: yes, let’; the IPC use case is clearly not the primary use of $TMPDIR, so 18:16:12 <jwb> i'm still of the opinion that we should do nothing here 18:16:18 <kalev> not sure we need to pass a guideline covering the general case 18:16:21 <thozza> I think we can at least agree on that redefining environment variable is not a good approach, right? 18:16:25 <t8m> There should be some directory for IPC and some directory for rest of the TMP usages 18:16:25 <mitr> t8m: +1. claws-mail can store the fixed-path IPC-related files in a hard-coded path (whether /tmp or other is immaterial). 18:16:28 <drago01> well even if fesco decides on something it wont make all developers out there go change their apps 18:16:33 <drago01> so the point is... ? 18:16:45 <mitr> thozza: Yet that is the existing mechanism. 18:16:52 <nirik> right, it would need someone driving it to check and fix apps. 18:17:02 <nirik> and upstream the changes. 18:17:12 <jwb> drago01, exactly 18:17:15 <mitr> jwb: We _have_ a deficiency in the platform, but, realistically, yeah, we are not fixing it here. 18:17:35 <thozza> mitr: ok, so we have to come up with something else as an alternative.... I get it now 18:17:54 <kalev> can we just say something like "FESCo asks Firefox to avoid overriding TMPDIR and to leave it as user configuration" and just close the issue? 18:18:03 <kalev> and that's already implemented too 18:18:08 <mitr> kalev: Well that is not _quite_ the question asked. 18:18:29 <t8m> kalev, as it's already implemented it would be superficial to ask for that 18:18:47 <kalev> even if someone asks us to solve the world hunger, that doesn't mean we can do that 18:18:59 <dgilmore> mitr: the answer to the question asked needs to go somewhere higher than FESCo 18:19:08 <jwb> dgilmore, uh, what? 18:19:09 <kalev> we can possibly pass a general guideline that says where which kind of temporary files could be saved 18:19:10 <jwb> no 18:19:12 <jwb> come on 18:19:14 <t8m> Yes, as we will not come to solution for a single TMP directory we should reject the ticket 18:19:14 <dgilmore> it needs to involve all upstreams and distros 18:19:15 <mitr> Proposal: FESCo does not currently want to mandate $TMPDIR being reliably consistent throughout an user session. If claws-mail requires a consistent place to use, it should use a different mecahnism. 18:19:30 <t8m> mitr, +1 18:19:34 <mattdm> mitr: +1 18:19:38 <jwb> mitr, +1 18:19:43 <dgilmore> mitr: +1 18:19:56 <mitr> dgilmore: No, this _is_ something we could actually solve within Fedora. However, on the list of priorities I think it is too low (without an interested leader at least). 18:20:04 <kalev> mitr: +1 18:20:18 <thozza> mitr: +1 18:20:53 <nirik> sorry, someone at the door here... 18:20:56 <dgilmore> mitr: perhaps. it would take someone interested and commited regardless, and I agree that person does not seem to exist 18:21:26 <nirik> #agreed FESCo does not currently want to mandate $TMPDIR being reliably consistent throughout an user session. If claws-mail requires a consistent place to use, it should use a different mecahnism. (+6,0,0) 18:21:47 <nirik> #topic #1359 Automatic OpenH264 download by Firefox 18:21:48 <nirik> .fesco 1359 18:21:48 <nirik> https://fedorahosted.org/fesco/ticket/1359 18:21:50 <zodbot> nirik: #1359 (Automatic OpenH264 download by Firefox) – FESCo - https://fedorahosted.org/fesco/ticket/1359 18:21:58 * nirik added his proposal in the ticket. 18:23:16 <nirik> comments? discussion? or should we just vote? :) 18:23:42 <jwb> i'm concerned the "accepted upstream" part won't happen 18:23:45 <t8m> Hmmm this is even better example of FESCo's inability to mandate anything :( 18:23:53 <t8m> jwb, +1 18:23:54 <mitr> nirik: I think that (disabling auto-download and asking users to do manual work) would be reasonable for WebRTC only; but this will return the moment Firefox will start using OpenH264 for <video>. Should we today have at least a rough consensus what we will do then? 18:24:15 <jwb> mozilla already begrudgingly conceeded to downloading this. i don't think they want to reopen the issue 18:24:26 <nirik> I think we can take the approach gentoo is. 18:24:36 <t8m> nirik, and that is? 18:24:37 <jwb> which is what? 18:24:38 <nirik> ie, build the thing ourselves as a package and have it use that one 18:24:43 <drago01> mitr: using it for <video> doesn't make sense if you cannot play the audio 18:24:52 <kalev> I know that cschaller has been working with varios parties to solve this issue in some way 18:24:54 <nirik> unless it's unacceptable for fedora. 18:24:58 <kalev> but I don't know the details 18:25:00 * nirik doesn't know off hand 18:25:10 <t8m> nirik, is "the thing" acceptable for fedora? 18:25:11 <jwb> drago01, the audio is opus for webrtc 18:25:16 <jwb> drago01, so audio is fine 18:25:18 <nirik> t8m: I don't know. 18:25:22 <nirik> it would need to pass legal 18:25:32 <t8m> I think there is some problem with the patent license but IANAL 18:25:34 <drago01> jwb: I was replying to mitr "will return the moment Firefox will start using OpenH264 for <video>. " 18:25:37 <mitr> nirik: Mozilla itself isn’t building it for licensing reasons AFAIK. 18:25:39 <drago01> jwb: which is not limited to opus 18:25:43 <jwb> ah 18:25:55 <jwb> mitr, that was my understanding as well 18:26:07 * nirik didn't dive that deeply into it this time... 18:26:14 <dgilmore> nirik: that afaik means we lose the patent rights 18:26:20 <drago01> nirik: afaik if you build it it will be the same as any other open source h264 coded 18:26:21 <drago01> c 18:26:26 <drago01> i.e no patent license 18:26:27 <nirik> ok. 18:26:40 <dgilmore> nirik: afaik you hav eto uses cisco's binary to get the patent grant 18:26:56 <jwb> i like nirik's proposal of the dialog, except i don't think it should be required to be upstream 18:26:58 <nirik> can we at least agree now the autodownload must stop? 18:27:02 <t8m> jwb, +1 18:27:08 <t8m> nirik, +1 18:27:13 <nirik> I like the idea too, but someone has to write it. 18:27:17 * nirik is not it. 18:27:46 <dgilmore> jwb and nirik +1 18:27:53 <t8m> In this case I think that this really really should be the Firefox maintainers in Fedora 18:27:57 <mattdm> more +1 18:28:02 <mitr> nirik: +1 must stop. 18:28:09 <thozza> nirik: +1 18:28:14 <kalev> I'm concerned we're discussing with the relevant parties present 18:28:21 <kalev> *without 18:28:23 <mitr> And, actually, would even opt-in autodownload be consistent with https://fedoraproject.org/wiki/Third_Party_Repository_Policy ? 18:28:42 <t8m> mitr, I think we could give exception for that 18:28:44 <mattdm> mitr: We would have to make an explict exception I think 18:28:52 <nirik> from the bug: 18:28:56 <nirik> "Any of those changes need extra work, it means to add special patches to GUI (create new dialog boxes and so) and should be reviewed by mozilla developers. 18:28:56 <nirik> We can work with upstream on it but it's a long term goal. Any patches here are welcome." 18:29:03 <mitr> t8m, mattdm: where “we” is actually “the board or its successor”? 18:29:16 <t8m> mitr, perhaps 18:29:20 <mattdm> mitr: sure 18:29:58 * nirik isn't sure this is a 'repository' and that policy applies, but ok. 18:30:17 <mattdm> yeah it certainly isn't the case that that policy was written for 18:30:30 <nirik> anyhow to collect clear votes: proposal: ask firefox maintainers to disable automatic download now. 18:30:34 <nirik> +1 18:30:40 <mitr> +1 18:30:41 <dgilmore> +1 18:30:52 <thozza> +1 18:30:55 <kalev> +1 18:30:58 <t8m> +1 18:31:42 <mattdm> 0 -- I don't see anything else we can do, but hope that's only very very temporary 18:32:04 <nirik> #agreed ask firefox maintainers to disable automatic download of OpenH264 plugin (+6,0,1) 18:32:13 <kalev> yes, what mattdm said -- I hope we can solve this in a way that makes the downloads possible 18:32:21 <nirik> ok, what do folks think of the idea of a manual install page for now? 18:32:32 * nirik agrees. 18:33:03 <mattdm> nirik better than nothing 18:33:06 <thozza> I think there should be at least some HOWTO until this is solved properly 18:33:25 <nirik> like the flash one. which I guess has moved to ask... although I am still not sure why 18:33:46 <jwb> it should have been restored in the wiki... 18:33:52 <jwb> if it hasn't been, that's a problem 18:34:04 <dgilmore> nirik: yep. 18:34:10 <nirik> there was some back and forth between spot and mether over it... but I thought they decided it was ok as it is now... 18:34:15 <mitr> nirik: Sure. 18:34:47 <t8m> nirik, manual install page is better than nothing 18:34:49 <nirik> I guess I can write up such a page... it should be simple...read agreement, download file, place in homedir/mozilla/blah 18:35:28 <nirik> #info nirik will draft a page 18:35:39 <nirik> so, what else do we want to do here? anything else? 18:36:11 <mclasen> it will just become another bullet point in fedy... 18:36:17 <dgilmore> we could ask the firefox maintainers to work on a download option like there is for flash 18:36:45 <nirik> dgilmore: yeah, they say that could be a "long term goal" 18:36:52 <nirik> I have no idea what timeframe that is. 18:36:57 <mitr> _We_ should, I think, first determine whether the opt-in dialog, if written, would be permissible. 18:37:27 <mitr> (where “determine” is probably “ask the board/council”, or at least that’s what I have personally promised in the previous elections) 18:38:02 <nirik> ok. I agree it would be good to know that before effort was made to make it exist. 18:38:12 <jwb> if firefox added the dialog themselves, i don't think we'd go asking the board/council if it was permissible 18:38:20 <jwb> so i don't see a reason to ask them if we write it either. 18:38:46 <mitr> Arguably if the current Flash plugin prompt is permissible this should be equally permissible, true. 18:39:02 <mitr> jwb: Well Firefox did add the auto-download and we are taking it out 18:39:46 <jwb> sure. that's no the same thing. 18:39:50 <jwb> s/no/not 18:40:04 <mitr> True 18:40:17 <nirik> mitr: so, I guess if you want to bring it up there, do? IMHO I would think it would be ok as long as the user is deciding, but thats just me. 18:40:42 <dgilmore> nirik: afreed 18:40:44 <jwb> i'm skeptical anyone is actually going to write this code 18:40:47 <dgilmore> agreed 18:40:59 <nirik> hard to say... 18:41:10 <kalev> I would say we need to have cschaller and firefox maintainers here in the meeting to move forward with this 18:41:11 * mattdm wonders what debian is doing 18:41:12 <mitr> nirik: I don’t particularly want to block the effort, no. 18:41:17 <jwb> here's an easy thing to answer: is anyone on FESCo committing to write the dialog code? 18:41:24 <nirik> mattdm: was just wondering that myself. ;) 18:41:30 <nirik> jwb: I am not. ;) 18:42:04 * nirik also wonders if this affects iceweasel? 18:42:08 <jwb> mattdm, they have icecat/weasel/whatever and can add whatever code they want 18:42:25 <kalev> proposal: ask cschaller and firefox maintainers to join next week's FESCo meeting and continue the discussion then 18:42:44 <t8m> kalev, I can be +1 to that 18:43:03 <mitr> kalev: What question would we be discussing precisely? 18:43:08 <nirik> kalev: not sure what will come of that? someone doing the dialog work? 18:43:27 <kalev> first question would be which general direction we should head to 18:43:36 <jwb> that was already decided 18:43:39 <kalev> should we look if legal is OK with autodownloads? 18:43:46 <mitr> 1) can we write the opt-in code? 18:43:49 <mitr> 2) do we want the opt-in code? 18:43:51 <mitr> 3) is the opt-in code permissible? 18:43:52 <kalev> would firefox people be interested in implemented a dialog that asks the user? 18:43:53 <mitr> 4) all of the above with s/opt-in/automatic/ 18:43:55 <kalev> etc 18:43:59 <mattdm> kalev spot at least gave his personal opinion that the diagog was acceptable 18:44:03 <mattdm> (see ticket) 18:44:13 <mitr> kalev: Would a “no” answer change anthing? 18:44:48 <thozza> mitr: I guess we would ended up with disabled downloads and wiki ;) 18:44:53 <nirik> kalev: from the bug they said they were, as long as it was upstreamable. 18:44:57 <kalev> I don't know -- but I do know that cschaller has been working with varios parties to solve this issue and I don't want to descide on how to proceed without hearing his opinions 18:45:18 <jwb> kalev, fesco already decided to not do the autodownload. it's already passed. 18:45:30 <kalev> yes, but that's just a temporary measure 18:45:39 <kalev> what to do next requires some discussion 18:45:45 <jwb> ah, ok 18:45:47 <nirik> I guess I'm fine with leaving the ticket for a week for more input from cschaller or anyone... 18:46:11 <thozza> kalev: but not doing the download automatically is definitive 18:46:17 <jwb> frankly, i'm tired of all of this. i'd rather see someone pay for a license for the various codecs and be done with it. 18:46:17 <mitr> kalev: If there is any conversation to be had, I think it should be between Firefox/cschaller and the Board/Council; FESCo is bound by the Board decisions and the interested of someone to write the code, and beyond that I don’t think we are adding more value beyond the decision already made. 18:47:04 <mclasen> jwb: cisco payed... 18:47:08 <nirik> proposal: keep ticket open for another week, ask any interested parties to propose longer term solutions, revisit next meeting. 18:47:12 <mitr> nirik: *shrug* Yeah, keeping the ticket open for one more week is cheap enough. I don’t see the benefit but perhaps something will happen. 18:47:14 <jwb> mclasen, for one of them :) 18:47:18 <mitr> nirik: +1 18:47:20 <t8m> nirik, +1 18:47:20 <mclasen> apparently, not good enough for us :-( 18:47:25 <kalev> niri
pgpXbML7h6UYN.pgp
Description: OpenPGP digital signature
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
