15:57:54 <spot> #startmeeting Fedora Packaging Meeting
15:57:54 <zodbot> Meeting started Wed May 16 15:57:54 2012 UTC.  The chair is spot. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:57:54 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:57:57 <spot> #meetingname fpc
15:57:57 <zodbot> The meeting name has been set to 'fpc'
15:58:03 <spot> #topic Roll Call
15:58:31 * geppetto is here
15:58:37 * limburgher w00t
15:59:46 <tibbs> Howdy.
15:59:49 * racor is here
16:01:24 * abadger1999 here
16:02:19 <spot> okay
16:03:10 <spot> rdieter_work, SmootherFrOgZ, if you see this, just let us know that you're here.
16:03:36 <spot> #topic Bundled b64_ntop.c in nc - https://fedorahosted.org/fpc/ticket/172
16:03:54 <tibbs> Doesn't look like it's worth talking about this until I hear back from the nc maintainer.
16:03:56 <rdieter_work> spot: here
16:04:09 * abadger1999 is initially leaning towards using hte glibc version instead of the file that we're adding as a downstream
16:04:16 <tibbs> Basically I was just wondering if FPC thought this would require a bundling exception.
16:04:28 <limburgher> I'm with abadger1999.
16:04:36 <abadger1999> yeah - it would probably require a copylib exception.
16:04:39 <tibbs> I lean towards yes since we have equivalent-sized md5 implementations.
16:04:53 <abadger1999> If it was embedded from upstream, I think I'd be more relaxed about it.
16:05:02 * rdieter_work is with tibbs
16:05:06 <spot> we add this as a downstream?
16:05:10 <tibbs> But if it's in glibc already then I don't see the point.
16:05:18 <tibbs> Yes, there's just a C source file checked into git.
16:05:19 <geppetto> tibbs: It's not officially in glibc.
16:05:33 <abadger1999> but since we're bundling it downstream, I definitely think it would need an exception.
16:05:34 <limburgher> geppetto: ?
16:05:49 <tibbs> It's in the exposed API.  I don't know what makes things official if that's not.
16:06:29 <abadger1999> /usr/include/resolv.h defines it.  It's undocumented beyond that.  Don't know what status that gives it.
16:06:35 <geppetto> tibbs: It's "exposed" … but it's not public, or documented.
16:06:45 <limburgher> If abadger1999's test program, and nc, work with what's in glibc on installed systems, that seems good enough.
16:06:59 <limburgher> geppetto: Any particular reason for that?
16:07:19 <tibbs> I'd just leave this up to the nc maintainer.
16:07:23 <geppetto> limburgher: My guess is that they didn't want to make it public, but had to due to libresolve being a separate library.
16:07:33 <tibbs> Either he can use what's in glibc, or he can get a bundling exception.
16:07:46 <geppetto> I'd just give an exception for base64.
16:08:01 <spot> well. i think base64 is probably as common as md5
16:08:02 <geppetto> It's even easier to reimplement than md5 … and has been done many times.
16:08:02 <Rathann> geppetto: if it's in public header then it's public
16:08:19 <geppetto> Rathann: No.
16:08:34 <Rathann> why not?
16:09:12 <limburgher> Am I sensing a "not public"=="we might change it without warning" issue?
16:09:16 <tibbs> I still cannot fathom where there is no system library containing things like this.
16:09:28 <geppetto> Rathann: Because if some newer version of glibc needs change … there is nothing stopping them from moving it, marking it private or just removing it … and I'm pretty sure they'll tell you to take a long walk off a short pier.
16:09:58 <spot> i think we're seeing glibc "bundling" a base64 impl, not really meaning to "provide" one
16:10:06 <geppetto> yeh
16:10:07 <limburgher> <headdesk>
16:10:25 <spot> which lends more weight to the prevalence of b64 in existing packages
16:10:29 <limburgher> tibbs:  Someone should cobble one together.
16:10:42 <spot> so i propose we just go ahead and grant base64 implementations an exception
16:10:53 <limburgher> <sigh>  Yeah.  Ugh.  +1
16:11:15 <rdieter_work> +1
16:11:19 <spot> +1
16:11:29 <abadger1999> -0.5
16:11:41 <spot> abadger1999: come on now, use ints, please. ;)
16:11:44 <geppetto> limburgher: 2 Options … 1) link against openssl and provide a nicer API(s) … then noone will use it due to deps. … or 2) write your own, and then nobody will use it because they don't trust it :)
16:11:47 <rdieter_work> - pi/4
16:11:48 <abadger1999> it's the bundling by us (vs upstream) that makes me slightly negative i nthis case.
16:11:56 <geppetto> +1
16:12:14 <tibbs> To be fair, upstream is one of the BSDs.
16:12:17 <spot> abadger1999: so try to talk the nc maintainer into not doing that. ;)
16:12:21 <limburgher> geppetto:  Damned if we do, damned if we do.
16:12:23 <tibbs> And we all know how terrible they are about this sort of thing.
16:12:27 <geppetto> limburgher: yeh
16:12:49 <limburgher> tibbs:  Speaking of.  .  .:)
16:12:50 <rdieter_work> abadger1999 has a point, but meh.  however nc maintainer wants to handle it, more power to 'em.
16:12:56 <tibbs> limburgher: Yeah.
16:13:00 <spot> we're at +4 on the bundling exception.
16:13:11 <geppetto> I don't think we need to worry much about updates to base64 anyway … much like md5.
16:13:27 <Rathann> +1 for temporary exception, provided a bug report is filed against glibc to either make its implementation public and documented or hide it
16:14:13 <geppetto> Rathann: I have no objects to creating a BZ … but I bet the response you get back is "it's not public, but we can't hide it anymore than we do currently, due to technical limitations."
16:14:17 <tibbs> I just don't know.  Pragmatism should probably win here, but the situation is just so dumb.
16:14:34 <limburgher> Yup.
16:14:46 <geppetto> tibbs: I don't see how this is significantly different than all the md5 situations.
16:15:02 <tibbs> Well, there's not an md5 implementation exposed by glibc, for one.
16:15:08 <geppetto> Although I also agree with everything you said.
16:15:11 <tibbs> But yes, the md5 situation is dumb.
16:15:35 <tibbs> At least with md5, all of the implementations don't have the same API.
16:15:38 <racor> +1 for exception
16:15:45 <tibbs> All of these are the same damn source file.
16:15:45 <Rathann> geppetto: by the way, the functions have been there since at least glibc 2.3 (I suspect much earlier)
16:15:57 <spot> okay. i see +5 for the general exception.
16:16:14 <spot> Rathann: feel free to file a bug with glibc. i'm not volunteering to get kicked in the face. ;)
16:16:22 <Rathann> heh
16:16:43 <tibbs> glibc maintenance is supposed to be getting better.
16:16:44 <limburgher> g++ -o foo -lchunk_norris
16:16:46 <geppetto> Rathann: *nods*, probably inherited from where libresolv came form originally.
16:16:59 <spot> #action General exception for base64 implementations approved (+1:5, 0:1, -1:0)
16:17:17 <geppetto> spot: abadger1999 did a -0.5
16:17:31 <tibbs> Maybe spot's rounding-to-even.
16:17:32 <spot> geppetto: yes, but i chose to round it up. :P
16:17:32 <limburgher> rdieter_works
16:17:41 <limburgher> 's first vote was irrational.
16:17:42 <geppetto> Fair enough :)
16:17:43 <abadger1999> heh :-)  works for me
16:17:48 <racor> spot: I'd also be OK with nc using the glibc implementation - The function is there for ages and people are free to use whatever it provides - Be it hidden/documented or not ;)
16:17:59 * spot also has no issue with nc using the glibc impl
16:18:13 <tibbs> What bundled(foo) should they use?
16:18:15 <rdieter_work> limburgher: nice
16:18:26 <limburgher> rdieter_work: :)
16:18:44 <spot> tibbs: bundled(base64-att)
16:19:11 <tibbs> Any "att"?
16:19:32 <tibbs> The source file is copyright ISC and IBM.
16:19:38 <spot> oh. sorry.,
16:19:47 <spot> then pick one. i don't care what color the shed is.
16:19:47 <tibbs> base64-isc makes sense, I guess.
16:20:06 <tibbs> Let's just use that.
16:20:10 <geppetto> yeh, I'm sure IBM own about 666 implementations of base64 :)
16:20:21 <limburgher> base64-ICBM?
16:21:00 <spot> #topic New Policy on GCC and alternative compilers - https://fedorahosted.org/fpc/ticket/173
16:21:16 <spot> there is no real need to vote here, FESCo wrote a policy, we're just going to codify it verbatim.
16:21:29 <spot> if anyone disagrees, feel free to talk to FESCo.
16:21:57 <spot> #topic Please make the no-bundled-libraries exception requirements more clear - https://fedorahosted.org/fpc/ticket/174
16:22:26 <spot> abadger1999: is there anything we need to do on this ticket?
16:22:47 <limburgher> It looks like it's still cooking, I don't see new text agreed on.
16:23:12 <abadger1999> I'm not sure why tmraz is objecting...
16:23:31 <abadger1999> Seems like we should reconfirm the wildcard exceptions that were granted by fesco.
16:23:47 <geppetto> We could change the text to say we don't care about the ticket# for wildcard exceptions.
16:23:49 <spot> abadger1999: i'd rather just grandfather them and move on, to be honest.
16:23:54 <abadger1999> then add the links for those to the wiki table so that people know what to list in the spec file comment
16:23:55 <geppetto> But, meh.
16:24:10 <abadger1999> spot: sure.  Just vote on that? and all of them can share that ticket?
16:24:20 <limburgher> Works for me.
16:24:29 <spot> Proposal: All old FESCo wildcard exceptions are grandfathered in.
16:24:34 <abadger1999> +1
16:24:37 <rdieter_work> +1
16:24:37 <spot> +1
16:24:43 <tibbs> +1
16:24:44 <geppetto> +1
16:24:48 <limburgher> +1
16:25:01 <Rathann> +1
16:25:48 <spot> racor: would you like to vote for the record?
16:26:14 <racor> +1 ... sorry, I was reading the ticket ...
16:26:22 <spot> #action All old FESCo wildcard exceptions are grandfathered in. (+1:8, 0:0, -1:0)
16:26:48 <spot> #topic Permission to build mod_auth_xradius with bundled libraries - https://fedorahosted.org/fpc/ticket/175
16:27:20 <limburgher> spot: This is the one I asked you about yesterday WRT the new md5 implementation.
16:27:28 <limburgher> libradius is the other problem.
16:27:34 <spot> so, i'm not sure why http://portal-to-web.de/tacacs/libradius.php isn't just packaged up as a BR
16:27:52 <geppetto> spot: Yeh, that was roughly my feeling.
16:28:08 <spot> yeah, its crufty and old (2004) but so is radius. :P
16:28:17 <geppetto> yeh
16:28:37 <limburgher> I didn't know about it.  I can package it up and have Simone test it with mod_auth_xradius.
16:28:59 <spot> limburgher: okay, lets do that. close it out if that works, or put some more details in the ticket if it doesn't
16:29:13 <limburgher> Will do.
16:29:29 <spot> #topic Updated tmpfiles.d guidelines - https://fedorahosted.org/fpc/ticket/176
16:29:53 <tibbs> I didn't even see this one yet.
16:29:55 <spot> Diff: https://fedoraproject.org/w/index.php?title=User%3AMichich%2Fdraft-tmpfiles.d&action=historysubmit&diff=288074&oldid=288058
16:30:08 <spot> tibbs: i didn't see it email out, but it came up when i ran the report
16:30:35 <Rathann> are the 2004 sources bundled as-is, with no modifications?
16:30:56 <Rathann> surely there must have been some vulnerabilities found in there over the years
16:30:56 <tibbs> I don't disagree with the list of changes in the ticket.
16:31:40 <geppetto> A lot of minor changes … although I think it still needs an example for the permissions.
16:31:50 <spot> yeah, i'm fine with it. the %{_prefix}/lib nonsense continues to annoy me, but i'm not going to fight that battle today
16:31:54 <geppetto> Esp. if it really needs to be 0710 and not just 710
16:32:48 <spot> i don't think it matters
16:32:49 <limburgher> Rathann: I'll check it out.
16:32:52 <spot> all the ones i have are 0644
16:33:10 <abadger1999> upstart should stay for now -- it's still a maintained package in F16
16:33:34 <tibbs> We don't need to mention an init system at all.
16:33:51 <abadger1999> /run isn't in the FHS
16:33:51 <tibbs> Just another thing we have to update when something unrelated gets changed.
16:33:52 <spot> i agree with tibbs, there is no need to mention it, which is what this change does
16:34:23 <abadger1999> eh.  But something has to provide the tmpfiles.d feature otherwise you have to create a different method of managing the files.
16:34:58 <tibbs> What provides it is not really necessary to the guidelines.
16:35:16 <tibbs> As long as something processes the tmpfiles.d settings, the guidelines shouldn't care.
16:35:31 <spot> i don't think either 0710 or 0755 is correct here
16:35:43 <spot> there is no reason for these files to be +x
16:36:24 <spot> 0644 should be fine.
16:36:27 <Rathann> aren't these directories, however?
16:36:42 <abadger1999> Should the hardcoded config file go into %{_datadir}/tmpfiles.d ?
16:36:58 <spot> abadger1999: thats the battle i'm not going to fight.
16:37:09 <abadger1999> and... I don't know calling htese types of files data seems more and more inappropriate as time goes on.
16:38:18 <abadger1999> is the intention of FHS really that ideally, vendors ship with an empty /etc/ that sysadmins copy files into from /usr/share /usr/lib or /usr/lib64 depending on the upstream software?
16:38:53 <spot> abadger1999: can't speak for the ghosttown that is FHS upstream, but that is certainly systemd's mechanism
16:39:55 <spot> Rathann: you're right. those dirs _do_ need +x
16:40:00 <abadger1999> I'm beginning to think conf should be shipped in /etc/ and then a software provider can establish best practices like "You have /etc/tmpfiles.d/vendor for packaged config and /etc/tmpfiles.d/local for local modifications"
16:40:05 <spot> so 0755 makes sense
16:40:12 <abadger1999> but sysadmins are free to shoot themselves in the foot.
16:40:32 <spot> abadger1999: i think that sort of decision is going to have to come out of FESCo
16:40:49 * rdieter_work doesn't care where default configurations come from really
16:40:54 <abadger1999> It's interpretation of FHS... it can come from us.
16:41:06 <rdieter_work> I think we can agree customized ones probably do belong in /etc
16:41:15 <abadger1999> Of course -- it might then be escalated to fesco :-)
16:41:21 <abadger1999> rdieter_work: <nod>
16:41:23 <spot> abadger1999: if we tell systemd that they can't put their configs in /usr/lib/whatever, they're just going to go to FESCo
16:41:41 <spot> so just take it to FESCo and save me the migraine. ;)
16:43:18 <spot> So, i'm +1 here, as it matches reality on the ground and is an improvement over what we have now
16:44:16 <limburgher> Yeah.
16:44:17 <limburgher> +1
16:44:21 <racor> -1
16:44:27 <rdieter_work> +1
16:44:40 <tibbs> +1
16:44:49 <geppetto> +1
16:44:54 <tibbs> The original is messy, this only cleans it up a bit.
16:45:19 <abadger1999> +1 to the "D/d" and perms cleanup -- -1 to everything else.
16:45:21 <geppetto> racor: did I miss something … why?
16:45:49 <racor> I am not willing to nod off bad designs ;)
16:46:03 <spot> #action Draft changes approved (+1:5, 0:0, -1:2)
16:46:12 <racor> ... just because it's reality ....
16:46:22 <spot> i encourage those who feel the FHS issues are noteworthy to address them with FESCo.
16:46:34 <spot> #topic Open Floor
16:46:49 <racor> ... it's only reality, because similar previous proposals where nodded off by FESCO and by us.
16:47:26 <tibbs> spot: Did you see someone submitted an exfat implementation?
16:47:35 <spot> no...
16:48:11 <abadger1999> Oops -- I forgot that we passed a FHS exception for /run -- I'm okay with those changes as well.
16:48:37 <racor> tibbs: yes. I was inclined to block exFAT FE_LEGAL ;)
16:48:53 <tibbs> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=822046
16:48:56 <spot> racor: please do, i dont think it can go in
16:49:06 <abadger1999> So I'm just -1 on the conf file stuff.
16:50:02 <spot> nm, i just did it
16:50:28 <spot> well, if there is nothing else, it looks like i need to make an appt with the lawyers
16:50:33 <spot> thanks everyone
16:50:36 <spot> #endmeeting