16:02:50 <spot> #startmeeting Fedora Packaging Committee
16:02:50 <zodbot> Meeting started Wed May  1 16:02:50 2013 UTC.  The chair is spot. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:02:50 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:02:52 <spot> #meetingname fpc
16:02:52 <zodbot> The meeting name has been set to 'fpc'
16:03:15 <limburgher> let's get is started (in her)
16:03:18 <tibbs> Howdy.
16:03:20 <limburgher> ^e
16:03:21 <limburgher> Crap.
16:03:24 <limburgher> hi!
16:03:42 <tibbs> Was watching the wrong channel for some reason.
16:04:12 <limburgher> fedora-meeting-1:  More riveting than C-SPAN.
16:04:30 <spot> #topic Roll Call
16:04:34 * limburgher here
16:04:36 <spot> either me or zodbot is riding the lag train.
16:04:39 <Rathann> here
16:04:53 <geppetto> limburgher: sexism typo?
16:04:59 <geppetto> limburgher: :)
16:05:04 * spot counts 6, missing racor, rdieter, SmootherFrOgZ
16:05:05 * geppetto is here
16:05:15 <limburgher> geppetto:  At least.  Apparently i can't make small talk in IRC, either.
16:05:54 <rdieter> hola, I can lame duck it today
16:06:28 <spot> #topic Schedule
16:06:50 <spot> As I sent out in a private email a few minutes ago, there was no time in which all members said they could attend. :/
16:07:08 <spot> There were three "only one cannot attend" options.
16:07:14 <spot> So please look at that and reply.
16:07:46 <spot> And with that, on to the proper agenda!
16:08:27 <spot> #topic Revision to Haskell Guidelines - https://fedorahosted.org/fpc/ticket/194
16:08:51 <spot> https://fedoraproject.org/wiki/PackagingDrafts/Haskell has been reworked to drop the "section spanning" macros
16:09:55 <geppetto> yeh, I think that was our only problem with it, right?
16:09:59 * spot nods
16:10:03 <geppetto> +1
16:10:04 * racor is half absent, half here (Public holiday, family at home)
16:10:12 <spot> the templates (https://git.fedorahosted.org/cgit/haskell-sig.git/tree/templates) look a LOT better, imho
16:10:40 <spot> so i'm +1 on this revised draft as well
16:11:12 <limburgher> +1 also.
16:12:28 <abadger1999> +1 with us pulling  the template links into the guidelines when we move it from drafts.
16:12:32 <spot> sure.
16:12:48 * spot forgot to say that we'd do that
16:12:48 * SmootherFrOgZ here
16:12:54 <tibbs> Total agreement with abadger1999.
16:12:59 <abadger1999> <nod> we discussed it before.
16:13:14 <spot> so i see us at +4
16:13:22 <rdieter> +1
16:13:28 <racor> +1
16:13:57 <spot> #action Haskell Draft (with templates merged into guidelines) approved (+1:6, 0:0, -1:0)
16:14:08 <tibbs> Does that include me?
16:14:13 <tibbs> Sorry, +1 for the record.
16:14:50 <SmootherFrOgZ> +1 for the record.
16:14:55 * SmootherFrOgZ was reading.
16:15:41 <Rathann> +1 from me as well
16:15:55 <spot> okay then. :)
16:16:14 <spot> #topic soft-static uid/gid for sgeadmin - https://fedorahosted.org/fpc/ticket/274
16:16:43 <spot> this is for the "gridengine" package.
16:17:08 <spot> Given that this package is almost always used in an HPC setup involving shared storage (in my limited experience), this request seems sensible.
16:17:13 <tibbs> I'm not sure we're entirely set up to deal with these yet.
16:17:47 <spot> tibbs: why not?
16:18:01 <racor> /usr/share/.. == read only => no need for uids
16:18:08 <tibbs> Have we decided what kind of information we actually want?
16:18:29 <geppetto> spot: On the other side … won't it commonly be used in situations where all the packages on the machine will be installed in the same way/time.
16:18:40 <tibbs> For example, I'd like to know why admin preallocation of uids is not sufficient.
16:18:58 <Rathann> racor: read only, but not necessarily readable by all
16:19:31 <abadger1999> it's interesting -- fedora-usermgmt is a dynamic uid technology so the logical upgrade is to use preallocation and dynamic uids.  But the NFS sharing means this fitsthe current criteria.
16:20:55 <tibbs> Depending on how you look at it, everything potentially involves nfs sharing.
16:21:07 <limburgher> fedora-usermgmt is also gone.
16:21:25 <abadger1999> tibbs: <nod>
16:21:33 <tibbs> Lack of fedora-usermgmt doesn't change anything, though.
16:21:48 <tibbs> I mean, it just means the admin has to do a slightly different thing to preallocate the UID.
16:21:50 <limburgher> Right, just a reminder.
16:22:00 <abadger1999> racor, Rathann: That's a good point.  /me downloads package to look at permissions
16:22:27 <geppetto> yeh, either preallocation or just relying on stuff getting installed the same way seems like it should satisfy 99% of users
16:22:35 <racor> Rathann: The point behind uids/gids is to restrict access. Are they storing passwords or other sensitive information in /usr/share?
16:22:40 * spot still thinks something which is multiple node software by default probably deserves consideration for UID sync across nodes.
16:22:43 <geppetto> I'm at best a 0, leaning heavily towards -1.
16:23:11 <tibbs> spot: I agree, that's why I think the admin should actually set that up if it's what they want.
16:23:33 <limburgher> spot:  Depends how it's implemented.  If it's not sharing a filesystem, it shouldn't matter.
16:23:55 <spot> limburgher: that is true.
16:24:11 <tibbs> But I kind of feel it's pointless to talk about these too much, because that's my opinion for all of these.
16:25:07 <limburgher> I think that in this case, since it doesn't need this out of the box, let the admin do it.
16:25:16 <spot> Honestly, I think HPC applications where shared filesystems and data are much more likely are the only case where I'm reasonably +1 on an exception for simplicity sake.
16:25:54 <limburgher> spot:  Agreed.  For pretty much all other cases, it's not needed.
16:25:57 <geppetto> Personally I'd assume the users should be intelligent enough to make it work without static uids there.
16:26:00 <spot> If a site wanted to incorporate shared storage, they'd have to go through and manually align all the UID/GIDs today.
16:26:14 <spot> because these are being created dynamically now.
16:26:55 * spot is +1 on this exception
16:26:56 <limburgher> spot:  If only there was an easy way to do that en masse at install time. . .to help kickstart the process. . .oh well.
16:27:28 <rdieter> +1
16:27:38 <SmootherFrOgZ> 0
16:27:41 <tibbs> I guess -1 for the record.
16:27:43 <racor> I had a look into the gridengine package and can not spot any reason, why they need a uid/gid for /usr/share. /usr/share is readonly and all files are readable world wide by anybody.
16:27:44 <racor> -1
16:27:48 <limburgher> -1
16:28:20 <spot> fwiw, with three -1 and one 0, this exception does not pass, but lets get everyone's vote on the record.
16:28:47 <spot> err, i suppose it could still pass if everyone else was +1. never mind. math!
16:29:24 <abadger1999> There's /usr/share/gridengine and /var/spool/gridengine.  that are owned by sgeadmin.
16:29:26 <Rathann> +1 from me as well
16:29:59 <spot> missing votes are abadger1999 & geppetto.
16:30:13 <geppetto> -1
16:30:14 <abadger1999> none of the files inside of /usr/share/gridengine are owned by sgeadmin and the dir is 0755 so that doesn't seem to be a concern
16:30:55 <abadger1999> /var/spool/gridengine is a host-writable location so that could need shared uid and gid in an NFS environment
16:31:13 <tibbs> Maybe this is a dumb unrelated question, but doesn't modern NFS use uid names instead of numbers anyway?  Or at least support local mappings?
16:31:48 <geppetto> tibbs: I believe you can remap … but it's about 666 easier to not have to.
16:32:13 * spot is waiting for abadger1999's vote, for the record. :)
16:32:33 <abadger1999> I guess +1.
16:32:43 <spot> #action Soft-static UID/GID request was not approved (+1:4, 0:1, -1:4)
16:32:50 <abadger1999> We're kinda making up the guidelines as we go along though.
16:33:09 <abadger1999> So I see read-write as a criteria I should ad to the guidelines.
16:33:17 <tibbs> I agree.
16:33:34 <abadger1999> Could someone explain what criteria this fails to meet, though?
16:34:25 <geppetto> My criteria it doesn't meet here would be: Should all the users be able to setup/preallocate dynamic uids so this isn't required.
16:34:43 <geppetto> In that they should, so no static alloc.
16:34:54 <abadger1999> geppetto: Hmm... wouldn't that criteria apply to any package though?
16:35:11 <tibbs> I'd just like to see a good reason why admin preallocation doesn't work.  Especially when the package already requires reconfiguration to even use NFS.
16:35:37 <tibbs> Isn't one of the guidelines "actually needs a static UID"?
16:35:38 <abadger1999> I'm not sure I can think of an example where a sysadmin couldn't use preallocation.
16:35:48 <geppetto> abadger1999: I don't think so.
16:35:49 <tibbs> abadger1999: Precisely.
16:36:35 <abadger1999> Okay... If that's the case... should we have approved the soft static guidelines or just said, "static ids are wrong, use dynamic ids instead" ?
16:36:47 <geppetto> abadger1999: There are examples like say "bacula" where you might want to have a shared service over multiple machines, but it's unlikely that all those machiens will be owned by the same person.
16:37:32 <geppetto> abadger1999: I kind of figured that was implied … and that the notes in that were "if you don't meet these guidlines, don't even bother applying"
16:38:05 <limburgher> geppetto:  How would that work, or be needed?  All bacula's daemons communicate over the network, no shared fs needed.
16:38:05 <tibbs> To be entirely fair, smart people who are familiar with the installer should set down and write up something quick to tell admins who want to kickstart how to preallocate things.
16:38:10 <abadger1999> So.. coordinated uids where there's likely to be different sysadmin groups for different boxes using the service.
16:38:20 <tibbs> It's possible that the process could be made simpler.
16:38:42 <abadger1999> Does gridengine fall under that?  ie: university where the computer science dept and the tehcnology services dept both want their computers to participate.
16:38:58 <tibbs> I don't know; that information wasn't presented in the ticket.
16:39:06 <abadger1999> k
16:39:17 <geppetto> limburgher: Yeh, that's why I put it in quotes … I have no idea if bacula needs static uids (I assume not, in fact) … I was just thinking of something where the service might want to have a "backup uid" or whatever, and it would be hard to control all the machines given they'd be owned by different people/etc.
16:39:29 <abadger1999> Well -- if that's a fair summary of the criteria we want to use, I'll ask on the ticket for that information.
16:39:58 <limburgher> geppetto:  Gotcha.  Yeah, static uid would be of no benefit to bacula at all.
16:40:29 <geppetto> It can't hurt them … I mean if enough users say they have multiple clusters that are owned by different people and want to join, I'd change to +1.
16:40:55 * spot feels that is implicit in large HPC installs.
16:41:08 <abadger1999> geppetto: k. I'll ask the question in the ticket -- if you think I mis-state it when I write it, feel free to chinme in :-)
16:41:25 * abadger1999 will work on an update to the guidelines to reflect the criteria we're coming up with too.
16:41:35 <geppetto> really? … My lack of knowledge is that while multiple users might use a big cluster, it's owned/controlled by one entity.
16:41:51 * Rathann afk for a few mins
16:41:55 <tibbs> I don't understand the use case for NFS across diversely-maintained machined.
16:42:18 <tibbs> Unless there is no consideration of security anyway.
16:42:38 <geppetto> tibbs: Well … in the general case … every company I've ever worked for has done it ;)
16:42:55 <tibbs> Which means an overarching admin policy.
16:43:23 <tibbs> I mean, if you're using krb5 then you don't care about UIDs matching anyway.
16:43:41 <tibbs> And if you aren't then you're giving complete access to everything you export.
16:43:58 <tibbs> But that's offtopic.
16:44:00 <spot> can we move on? :) I have a hard stop at 1.
16:44:36 <spot> #topic Bundling libxdiff in libgit2 (and git) - https://fedorahosted.org/fpc/ticket/276
16:45:08 <spot> I dug into this, and I can confirm that both git and libgit2 have their own forked versions of xdiff
16:45:17 <spot> and they are not compatible.
16:45:19 <limburgher> How far forked?
16:45:19 <tibbs> I'm surprised to see the git folks doing this.
16:45:25 <limburgher> Me too.
16:45:38 <tibbs> Also, why would they fork something which seems rather essential for cross-compatibility?
16:45:55 <spot> it probably could be made compatible
16:46:09 <spot> but xdiff is rather small, which is probably why there was no centralization effort.
16:46:28 <limburgher> Better now than later, we don't want Android part II.
16:46:59 <limburgher> "Ok, we've diverged for awhile, ready, set, MERGE!!!!!!"
16:47:08 <limburgher> <boom>
16:47:17 <geppetto> Yeh, they should at least combine their efforts.
16:47:21 <tibbs> So, we generally want some communication with (and hopefully between) upstreams.
16:48:35 <SmootherFrOgZ> can both forked version can be merged into one so that git & libgit2 link against?
16:48:47 <spot> SmootherFrOgZ: maybe. I might be able to hack that together.
16:48:58 <spot> The diff isn't huge, i've done worse in chromium.
16:49:04 <SmootherFrOgZ> :)
16:49:40 <tibbs> It just seems that it's not in anyone's best interest for this to be forked.
16:49:43 <limburgher> spot: You monster.
16:49:45 <spot> so, let me take a crack at trying to make a modern xdiff that both of these can use.
16:50:01 * spot really hopes he doesn't end up being the defacto upstream for that code.
16:50:23 * limburgher snickers
16:51:11 <rdieter> +1 to exception
16:51:25 <spot> we have 10 minutes and two tickets, neither of which I have any real confidence that we'll be able to bang out in 10 minutes.
16:51:30 <SmootherFrOgZ> I'm -1 then. Unless spot fail ;p
16:51:46 <geppetto> spot: touched it last ... you own it!
16:51:54 <Rathann> -1 to exception and file a bug against git to unbundle ;)
16:52:03 <spot> so, lets push 277 and 273 to next week.
16:52:11 <spot> #topic Next week meeting time
16:52:38 <spot> SmootherFrOgZ has indicated that he can make 1500 - 1600 UTC on Thursday
16:52:51 <SmootherFrOgZ> yup!
16:52:53 <Rathann> I can't make 15:00 UTC any day
16:53:00 * spot sighs
16:53:01 <Rathann> I finish work then
16:53:20 <Rathann> so my commute would eat into meeting time
16:53:31 <Rathann> not to mention I sometimes stay late
16:53:32 <spot> Rathann: so the issue with 16:00 is getting home in time?
16:54:19 <SmootherFrOgZ> Rathann: we can setup an hangout if you want :p
16:54:30 <Rathann> on Wednesday my wife is busy until 16:30 and I have to take care of our daughter
16:54:32 <Rathann> so no
16:54:39 <Rathann> SmootherFrOgZ: not sure what you mean
16:55:00 <tibbs> Wednesday is 50x better for me because I work from home then, but I won't object if we move the day.
16:55:01 <SmootherFrOgZ> Rathann: google hangout. was just kidding
16:55:03 <spot> Rathann: how about Thursday at 16:00 ?
16:55:12 <Rathann> Thursday at 16:00 would be ok
16:55:28 <spot> okay, so it looks like Thursday at 16:00 is okay for everyone.
16:55:55 * spot makes sure this channel is available
16:56:14 <Rathann> until we switch back to winter time
16:56:17 <Rathann> ;)
16:57:18 <spot> okay
16:57:31 <spot> #action Meeting Time moved to Thursday at 1600 UTC
16:57:45 <spot> we will not meet tomorrow, lets start it on May 9th.
16:57:54 <spot> this irc channel.
16:58:26 <spot> and with that, thanks everyone.
16:58:34 <Rathann> however I'll miss next meeting because my wife has a conflicting meeting then
16:59:10 <spot> Rathann: thanks for the heads-up
16:59:12 <spot> #endmeeting