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> nirik: +1
18:47:45 <dgilmore> nirik: +1
18:47:58 <thozza> nirik: +1
18:48:00 <jwb> mclasen, the license aspect wasn't really the issue.  legal was objecting to the 'build from source' aspect
18:48:15 <dgilmore> mclasen: while its open source you can not comile it yourself and be covered
18:48:21 <nirik> #agreed will keep ticket open a week for interested parties to propose longer term solutions. (+6, 0, 0)
18:48:22 * mclasen won't comment further
18:48:28 <dgilmore> compile
18:48:28 <drago01> jwb: thats not a legal but a policy issue
18:48:33 <nirik> #topic next weeks chair
18:48:38 <nirik> who wants it next week?
18:48:40 <drago01> jwb: there is no "you must build from source" law ;)
18:48:44 <nirik> it will be fun and exciting!
18:48:48 <mitr> jwb: Hm, actually… if we could reuse the Mozilla’s process for verifying the build process, would that be an acceptable replacement?
18:48:59 <jwb> drago01, fair.  though it was a policy instituted for sound legal reasons
18:49:10 <t8m> nirik, I will chair next week
18:49:13 <jwb> mitr, good question, and i don't know
18:49:27 <nirik> mitr: IMHO no. :) because there's also things like no commercial use...
18:49:35 <nirik> thanks t8m
18:49:42 <nirik> #info t8m to chair next week.
18:49:45 <nirik> #topic Open Floor
18:49:47 <kalev> mitr: that's a good question and it's the kind of direction I'm hoping we can take, instead of just taking the codec out
18:49:51 <nirik> anyone have anything for open floor?
18:51:03 <dgilmore> seems no
18:51:52 <nirik> ok, will close in a minute if nothing more.
18:52:32 <nirik> Thanks for coming everyone!
18:52:35 <nirik> #endmeeting