16:14:52 <abadger1999> #startmeeting fpc
16:14:52 <zodbot> Meeting started Wed Oct 10 16:14:52 2012 UTC.  The chair is abadger1999. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:14:52 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:15:04 <abadger1999> #chair tibbs limburgher Smoother1rOgZ geppetto
16:15:04 <zodbot> Current chairs: Smoother1rOgZ abadger1999 geppetto limburgher tibbs
16:16:20 <abadger1999> rdieter, racor, Rathann, spot: we're going ahea with the FPC meeting if any of you are also here.
16:16:33 <rdieter> abadger1999: oh, hi, here
16:17:08 <abadger1999> #chair rdieter
16:17:08 <zodbot> Current chairs: Smoother1rOgZ abadger1999 geppetto limburgher rdieter tibbs
16:17:30 <Rathann> here here
16:17:42 <abadger1999> #chair Rathann
16:17:42 <zodbot> Current chairs: Rathann Smoother1rOgZ abadger1999 geppetto limburgher rdieter tibbs
16:17:53 <abadger1999> Okay, let's see what we've got since last week...
16:18:19 <abadger1999> .topic using gtk-update-icon-cache -f is wrong(?) - https://fedorahosted.org/fpc/ticket/217
16:18:24 <abadger1999> #topic using gtk-update-icon-cache -f is wrong(?) - https://fedorahosted.org/fpc/ticket/217
16:18:29 <limburgher> Didn't we fix that?
16:18:34 <abadger1999> rdieter: I think we approved this last week
16:18:40 <rdieter> I think so
16:18:49 <abadger1999> rdieter: So go ahead and fix the guideline page.
16:19:07 <abadger1999> and we'll be good to go on that
16:19:18 <abadger1999> #topic Should we require the kernel to note bundled libs? - https://fedorahosted.org/fpc/ticket/218
16:19:23 <rdieter> will do
16:20:02 <abadger1999> I was looking into copylibs and virtual provides and saw that the kernel wasn't including the virtual provide we had approved earlier.
16:20:07 * racor was distracted, but I am here, now.
16:20:08 <abadger1999> and was bundling other code.
16:20:13 <abadger1999> But the kernel is special
16:20:16 <abadger1999> #chair racor
16:20:16 <zodbot> Current chairs: Rathann Smoother1rOgZ abadger1999 geppetto limburgher racor rdieter tibbs
16:20:49 <abadger1999> so it makes sense to me to extend the blanket exception for bundling to also include not needing the virtual provides.
16:21:08 <limburgher> Yeah, and the arguments in the ticket made sense.
16:21:25 <rdieter> agreed
16:21:26 <abadger1999> Here's the diff for anyone who didn't get a chance to read it: https://fedoraproject.org/w/index.php?title=User%3AToshio%2FNo_Bundled_Libs_%28kernel%29&diff=305698&oldid=305691
16:22:07 <tibbs> I'm prepared to let the kernel be special.
16:22:19 <abadger1999> Cool.  Shall we vote?
16:22:27 <geppetto> The provides are just there for when we get a security hit and need to see what might be affected, right?
16:22:34 <abadger1999> geppetto: correct.
16:22:43 <geppetto> So I'm not sure I see the downside for the kernel to provide them.
16:22:44 <limburgher> And the kernel tends to track that pretty well.
16:23:07 <geppetto> Worst case someone pings a kernel dev and they say "yeh, we changed that code a lot so this vuln. can't hit us"
16:23:15 <abadger1999> geppetto: well... the kernel has a lot of bundled code ie: the code comes from other upstreams.  But the code has been changed in large ways.
16:23:32 <abadger1999> including stripping out everything not relevant to what they were included for.
16:23:51 <limburgher> kernel :: flatware drawer
16:23:55 <limburgher> Full of forks.
16:23:57 <abadger1999> example: gpg code is bundled but they've stripped out everything but some multiprecision integer handling.
16:24:07 <geppetto> yeh, but it feels a lot like saying … it's ok because the kernel has 666 devs. so someone will always know and won't need to be pinged.
16:25:03 <limburgher> I'd ideally rather have the provides present, but I feel like they might change a lot and put an unusually large burden on the kernel team.  I could be wrong.
16:26:01 <geppetto> It's not like they are merging lots of new forks every week … and I'm mostly happy to +1 some wording to the affect of "if the code is so different it's not recognizable, you don't need to add provides".
16:26:29 <limburgher> geppetto:  That would be fine with me.
16:26:46 * Rathann seconds geppetto
16:26:53 <geppetto> Again, there are lots of kernel devs. … surely one of them can spend a few hours to "document" what they are forking for everyone else.
16:27:03 <abadger1999> <nod> I can see that... otoh, the kernel bundled code is evolving separately... everything in the kernel is really a fork...
16:27:30 <limburgher> Provides(bundled): minix
16:27:37 <abadger1999> there's a judgement call to that though... what's recognizable?
16:27:38 * limburgher ducks
16:27:57 <racor> abadger1999: I would not grant the kernel an exception, but would propose to restrict the bundled/copylibs rules "user-space" libs.
16:27:58 * Rathann throws Tannenbaum at limburgher
16:27:59 <abadger1999> The gpg code, ofr instance, I only recognize because they leave the copyright information.
16:28:18 <geppetto> abadger1999: Yeh, I understand … I'd hope we could just trust their judgement.
16:28:43 <limburgher> If not, we have bigger issues.
16:28:51 <geppetto> "their" == any Fedora kernel packager/dev.
16:28:57 <abadger1999> racor: <nod>  -- We have already granted the kernel the ability to bundle libraries without consulting us b/c of the userspace/kernelspace split.
16:29:04 <abadger1999> this change would be about documenting.
16:30:19 <jwb> hi
16:30:23 <abadger1999> Hey jwb!
16:30:54 <abadger1999> So we're discussing the draft I made for letting the kernel have an exception from specifying Virtual Provides for bundled code.
16:31:09 <jwb> yep
16:31:39 <abadger1999> geppetto is thinking that there might still be some helpfulness for kernel people to get pinged if a vulnerability is discovered in some of this coe.
16:31:46 <abadger1999> He's proposing something along the lines of
16:32:10 <abadger1999> some wording to the affect of "if the code is so different it's not recognizable, you don't need to add provides".
16:32:32 <abadger1999> where "recognizable" would be left to the kernel team's discretion.
16:32:54 <abadger1999> comments on taking things in that direction?
16:33:06 <racor> abadger1999: Would you mind to explain why the current rules aren't sufficient and need to be extended? IMO, the briefer, the better (less room for misunderstandings).
16:33:38 <abadger1999> racor: currently, we allow the kernel to bundle anything.  But we have not removed the requirement for them to document bundling with Virtual Provides.
16:34:28 <jwb> abadger1999, not really sure that wording helps much to be honest
16:34:35 <abadger1999> racor: But the code the kernel bundles is modified to a very large extent... to me it seems like everythng bundled becomes a fork because their needs are so different from the needs of userspace.
16:34:59 <jwb> without spending time to analyze the code it's going to just get a blanket "yeah, this is unrecognizable" knee-jerk reaction
16:35:15 <abadger1999> racor: So I'm proposing we also give the kernel an exception to the virtual provides requirement.
16:35:22 <abadger1999> <nod>
16:37:04 <abadger1999> geppetto: Does that speak to your concern?
16:38:43 <jwb> i doubt it does.  i could lie and say something else, but then i'd be lying
16:40:36 <geppetto> If you think it's very likely that all of the code is very different … I'd still prefer us to word it like that, and you can exempt everything.
16:41:22 <geppetto> But it would be nice if someone had a look, just so they could say … meh. I guess zlib is pretty close to usptream or whatever.
16:42:07 <jwb> i'm not necessarily disagreeing there.  it'd be fairly low on the todo list at the moment for the kernel team though
16:43:28 * geppetto nods … I understand. Maybe you could float the idea of having a Documention/forks file upstream?
16:44:12 <jwb> hm, that isn't a bad idea
16:44:23 <jwb> i'll look at doing that
16:44:54 <geppetto> thanks.
16:45:04 <Rathann> if security notifications are the only concern then I'd say it's better to notify and have people look at the code anyway
16:45:08 <Rathann> even if it's different
16:45:34 <jwb> that's already done fairly heavily upstream
16:46:04 <abadger1999> How about wording like this: "The kernel maintainers are free to add virtual provides if they think it would be helpful to track security issues in the code in question and but this is left to their judgement."
16:46:13 <rdieter> abadger1999: +1
16:46:21 <jwb> i'm happy with that
16:46:40 <abadger1999> It acknowledges why the virtual provides are useful but also that we're really letting the kernel maintainers decide how useful any notifications would be
16:46:48 <limburgher> <nods>
16:46:52 <tibbs> Still +1 with that change.
16:46:58 <limburgher> +1 also
16:47:10 <abadger1999> +1 with change
16:47:15 <Smoother1rOgZ> +1 with change
16:47:20 <racor> +1
16:47:27 <Rathann> +1 then
16:48:03 <abadger1999> geppetto: Want to cast your vote for the record?
16:48:25 <geppetto> +1
16:49:05 <abadger1999> #info Changes to bundled libs for kernel exception passed (+1: 8, 0:0, -1:0)
16:49:21 <abadger1999> jwb: thanks for the input!
16:49:33 <jwb> no problem.  thanks for the ping
16:50:52 <abadger1999> #topic Bundled lib exception request for libtidy bundled with sigil - https://fedorahosted.org/fpc/ticket/219
16:51:21 <abadger1999> This is a request to bundle a forked version of libtidy in sigil
16:51:30 <abadger1999> The fork handles epub files instead of html
16:51:47 <abadger1999> the markups are similar but not exactly the same.
16:52:41 <limburgher> Pretty forky.
16:52:42 <abadger1999> hansg has answered the standard battery of questions that we ask for in the initial request.
16:52:44 <rdieter> with my libtidy maintainer hat on, I endorse the rationale here
16:53:03 <geppetto> rdieter: Have you looked at their changes?
16:53:12 <Rathann> frankly I don't understand why support for epub format can't be added to libtidy
16:53:18 <geppetto> From what they said they changed it seems like a pretty small set of changes.
16:53:32 <geppetto> Rathann: +1
16:53:37 <limburgher> Isn't epub sort of a superset of html?
16:53:55 <rdieter> I hadn't looked at code, just the rationale.  assumed hans wasn't lying
16:54:21 <Rathann> the behavioural differences seem small enough and I'd wager they could be added with a parameter to relevant functions/calls
16:55:00 <rdieter> considering this has 0 chance of getting upstreamed (upstream is essentially dead), i'm uncomfortable carrying it forward indefinitely downstream
16:55:43 <limburgher> Essentially becoming the new upstream.
16:56:02 <abadger1999> Here's the diff from the bugzilla: https://bugzilla.redhat.com/attachment.cgi?id=576293
16:58:33 <geppetto> really doesn't seem like a big change, to me.
16:58:50 <geppetto> and more than a few of them seem like "this should be in libtidy".
16:58:58 <abadger1999> rdieter: does libtidy make fixes?  Or only suggest fixes?
16:59:03 * Rathann laughs at: +    /* Ugly hack added by Strahinja Markovic */
16:59:09 * abadger1999 nods at al the uint stuff
16:59:28 <rdieter> abadger1999: makes fixes (though can do both, I believe)
16:59:49 <Rathann> so, I'm -1 on the bundling exception, this should go into libtidy
17:00:06 <abadger1999> k.  So the typo fixing portions are also not a conceptual problem.
17:00:58 <abadger1999> rdieter: you said that libtidy is essentially dead upstream... do you know if it would be possible for the sigil upstream to tak it over?
17:01:27 <Rathann> also, this:
17:01:33 <Rathann> +    /* This WILL explode if someone uses an attribute
17:01:33 <Rathann> +    that has more than 50 characters. Fortunately, such
17:01:33 <Rathann> +    attributes don't exist in XHTML, SVG or anything similar.*/
17:02:04 <Rathann> someone can create a malformed file just to exploit this
17:02:35 <Rathann> and I don't see any size check there
17:02:55 <rdieter> abadger1999: that's a thought
17:03:41 <rdieter> still not sure about potential incompatibilities though (or api/abi differences, but don't see any offhand looking at the patch)
17:05:43 <rdieter> not sure if han's comment: "...it changes behavior quite a bit and this may break existing users of libtidy" comes from his own understanding or from sigil upstream.  if true, could definitely be a problem
17:07:33 <rdieter> to complicate matters further, we have tidyp (a fork) too
17:07:40 <abadger1999> <nod> I think that's where the suggestion of a flag in the affected functions comes in.
17:07:42 <abadger1999> hmm..
17:08:44 <Rathann> is the tidyp fork more or less API-compatible?
17:08:52 <Rathann> and actively maintained?
17:09:14 <abadger1999> last commit Oct 2010
17:09:15 <Rathann> if yes, the sigil could switch to it
17:09:21 <rdieter> Rathann: active is relative, it's latest commits are several years newer than tidy
17:09:29 <rdieter> but still 2-3 years old
17:10:22 <abadger1999> Issues with patches reported to tidyp with no comments :-(
17:11:10 <Rathann> hm
17:11:29 <abadger1999> So....  I'll comment on the ticket
17:11:57 <abadger1999> libtidy (and the fork tidyp) seem pretty dead upstream
17:12:20 <limburgher> Yeah,
17:12:25 <abadger1999> FPC wonders if sigil upstream could take over and add the epub changes as flags to the relevant functions
17:12:54 <abadger1999> and see what nasg says for next week.
17:12:59 <abadger1999> *hansg
17:13:18 * geppetto nods
17:13:33 <Rathann> there's tidy-html5 fork, too
17:15:04 <abadger1999> alright.  we're running low on time this week
17:15:06 <abadger1999> #topic Open Floor
17:15:14 <abadger1999> Anything else people want to get out of the way?
17:15:16 <limburgher> Nothing here
17:16:08 <abadger1999> If there's nothing I'll close in 60s
17:17:39 <limburgher> Thanks for chairing abadger1999!
17:17:58 <abadger1999> #endmeeting