15:08:31 <abadger1999> #startmeeting fpc
15:08:31 <zodbot> Meeting started Wed Sep 28 15:08:31 2011 UTC.  The chair is abadger1999. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:08:31 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:09:16 <abadger1999> #meetingname fpc
15:09:16 <zodbot> The meeting name has been set to 'fpc'
15:09:24 <rdieter> yo
15:09:37 <abadger1999> #chair limburgher racor geppetto tibbs|h rdieter spot SmootherFrOgZ
15:09:37 <zodbot> Current chairs: SmootherFrOgZ abadger1999 geppetto limburgher racor rdieter spot tibbs|h
15:11:19 <abadger1999> #topic non-official Fedora repo files in packages   https://fedorahosted.org/fpc/ticket/106
15:11:36 <abadger1999> We're close on this one so let's start there
15:12:26 <tibbs|h> I'm behind the original proposal.  The stricter one, not so much.
15:13:05 <abadger1999> at the end of last meeting spot brought up that we still can't ship repofiles that point to repos that contain software that's illegal in the US so the question is whether we can work those into the guidelines sensibly.
15:13:22 <abadger1999> spot and I both added proposed revisions to the ticket to try to address that.
15:13:38 <tibbs|h> There are all sorts of things we can't do for legal reasons.
15:14:05 <tibbs|h> I'd rather the lawyerly folks work out some description of the things that can't be done for legal reasons and stick those in the legal guidelines.
15:14:13 <geppetto> I'm most happy with spots "do not do that" revision
15:14:27 <rdieter> tibbs|h: +1
15:14:55 <tibbs|h> I just do not see the point in banning a huge class of things just because some portion of them might cause someone some legal problems.
15:15:00 <geppetto> But I'll +1 one of the "you can sort of do that, but you must never do …" texts, if everyone prefers to be "nice"
15:15:27 <limburgher> I don't see the problem with "we can't do that or we'll get sued".
15:15:32 * abadger1999 would also like to keep the legal definition out of the Packaging Guidelines but is okay with explicitly linking to them from here.
15:15:34 <tibbs|h> I mean, be don't ban the mention of all web sites, even though some of those sites might host patented content.
15:16:04 <abadger1999> (linking to the legal definition)
15:16:11 <abadger1999> <nod>
15:17:06 <limburgher> Right, but I'd argue that a repo config is a step closer to inclusion than a description/mention.  Though IANAL.
15:17:09 <tibbs|h> The other problem is that the stricter definition seems to ban the mention of kopers or anything like that, and it seems odd that we wouldn't be able to talk about our own services.
15:17:17 <rdieter> So, in short, I'm a-ok +1 with the initial proposal.
15:17:37 <rdieter> but not so much with the stricter one, personally.
15:18:03 <limburgher> Why not the stricter one?  Curious.
15:18:19 <rdieter> it's overly strict
15:18:28 <limburgher> Right.  How so?
15:18:32 <abadger1999> rdieter, tibbs|h: +1
15:18:48 <rdieter> limburgher: see tibbs|h example about koper's foe one
15:18:57 <rdieter> for one even
15:19:32 <geppetto> Even with the strict one I'm really not sure it's a good idea for us to encourage repos. on random websites … I'd much rather it be limited to repos.fedorapeople.org or something
15:19:33 <limburgher> What is kopers?
15:19:37 <rdieter> now, if legal really wants to add more restrictions, that's fine (we can link to the legal namespace, whatever)
15:19:43 <rdieter> limburgher: repos.fedorapeople.org
15:20:13 <limburgher> OIC
15:20:30 <limburgher> Hmm.
15:21:11 <abadger1999> Note, these aren't repos that are enablable right off... they're in %docdir so they have to be copied... I'd argue that it's no worse to have sample repofiles in the %docdir than it is to have README or README.fedora that has the same information.
15:21:29 <limburgher> How about Spot's, sans "unofficial" in the last line?  That would block third party and allow r.fp.o
15:21:39 <rdieter> imo, going beyond the initial proposal goes beyond the scope of guidelines, and more into policy and/or legal (both of which are outside our jurisdiction)
15:22:06 <abadger1999> So I don't see the point of banning beyond pointing people at the legal issues that they should keep in mind.
15:22:55 <rdieter> abadger1999: that's my gut feeling too
15:22:56 <limburgher> abadger1999: If we accomplish that I'm happy. The only concern is that someone may want to include a config for 3rd-party with no legal issues.
15:23:26 <limburgher> Do we audit 3rd-party repos for legal issues?  We can't, practically speaking.
15:24:04 <abadger1999> limburgher: I have no problem with that as long as it's in %docdir.  I don't want them live but I think even the original draft takes care of that.
15:24:27 <abadger1999> limburgher: We don't audit unless it comes up I believe.
15:24:52 <geppetto> Right, the three issues for me are that with 3-party repos. we have no control so: 1) They can screw up the legal things randomly. 2) They can screw up the packages technically. 3) They can screw up the security of their server. … and in all cases we just have to send a message to Fedora announce saying "you are screwed"
15:25:09 <limburgher> abadger1999:  In docdir, and with a caveat indicating that we don't support that repo?
15:25:21 <geppetto> Whereas if we limited it to repos.f.o we could at least stop the pain
15:25:21 <tibbs|h> So, what, patch vi and cat and cp to not touch anything in /etc/yum.repos.d?
15:25:27 <limburgher> gepetto: Bingo.
15:25:49 <limburgher> tibbs|h: LOL  and joe and moe and emacs and peppy pantpantpant
15:26:00 <rdieter> reminder (for better or worse, imo, ianal, yada):  legal issues really aren't in our (fpc) purview anyway.
15:26:04 <abadger1999> limburgher: eh... I sorta like that caveat but -- we don't require that of the same information in a README from upstream so....
15:26:12 <geppetto> tibbs|h: If we allow .repo files in packages there is going to be a workflow for enabling them … maybe even a GUI
15:26:24 <geppetto> tibbs|h: And it will be assumed we are at least partly responsible
15:26:47 <geppetto> tibbs|h: That's far removed from using vi following instructions on a webiste, IMO
15:26:51 <limburgher> abadger1999:  But in a README, the implicit assumption is we accept BZ against that software.  No such assumption should be made for a repo or it's content.
15:27:06 <tibbs|h> So we invent a whole "you can't even talk about this" scheme to try and prevent users from doing bad things to their machines?
15:27:07 <limburgher> geppetto: +45 bajillion
15:27:10 <tibbs|h> I just don't see the point.
15:27:38 <tibbs|h> You can't install repo files to the place where yum would see them.
15:27:46 <limburgher> tibbs|h:  I don't think that's what he's getting at.  I think we just say, "go ahead, but it's not supported by Fedora since it's not part of Fedora."
15:27:46 <tibbs|h> Note that the stricter guideline bans mock, too.
15:27:51 <abadger1999> geppetto: It's debatable if an application can operate on things marked %doc.... If the application fails if the %doc stuff isn't there, it would be a violation of guidelines.
15:27:57 <tibbs|h> Because there are repo files in the configuration files.
15:28:11 <abadger1999> If it didn't fail... then you might be able to fit it through a loophole.
15:28:22 <tibbs|h> Unless you go and redefine those as "official" somehow.
15:28:23 <limburgher> tibbs|h:  How so?  My /etc/mock only includes Fedora and EPEL.
15:28:25 <abadger1999> but it would clearly be a loophole in this case...
15:28:51 <geppetto> tibbs|h: Not directly, no. … but if we approve this then it's almost inevitable that people will want an "easy" workflow … which should be fine, assuming a user is still in the mix
15:28:55 <tibbs|h> limburgher: So baseurl=http://kojipkgs.fedoraproject.org/repos/dist-f16-build/latest/x86_64/ is "official"?
15:29:01 <tibbs|h> I don't think so.
15:29:34 <limburgher> tibbs|h: Eventually.  No less than f15 updates-testing.  Moreso than rpmfusion.
15:29:59 <tibbs|h> Now this is just getting hilarious.
15:30:08 <abadger1999> geppetto: I don't really see the point in banning repo files as %doc in %docdir if you're worried about a potential future GUI that copies the files to /etc/yum.repos.d ... after all, nothing in the current guidelines prevents that same GUI from existing just creating the repo config files from internal data rather than copying a file on disk.
15:30:12 <tibbs|h> Anyway, it's obvious that we're not getting anywhere.
15:30:40 <abadger1999> So...
15:30:53 <geppetto> abadger1999: I think it would be assumed the app. wouldn't be appreciated … but, meh
15:31:23 <limburgher> I can support the original proposal, but would prefer the stricter one.
15:31:24 <abadger1999> geppetto: Just as I think an app that copied files from %docdir to /etc/yum.repos.d wouldn't be appreciated either.
15:31:24 <geppetto> as I said, I'll +1 abadger1999 version, even allowing random internet URLs … I just don't see the need for the risk
15:31:44 <abadger1999> So... can we all live with: https://fedorahosted.org/fpc/ticket/106#comment:3
15:32:03 <abadger1999> which is the original proposal plus a sentence linking to the legal guidelines that may be relevant?
15:32:03 <geppetto> abadger1999: That's different though … once we've approved shipping .repo files, it's much less obvious the app. is "bad" IMO
15:32:15 <geppetto> abadger1999: yeh, at least here
15:32:33 <tibbs|h> Can you ship rot13 repo files?
15:32:52 <geppetto> I think we are doing a negative freeroll … but I don't want to -1 it on that basis
15:32:52 <limburgher> tibbs|h: Why not, we ship complied binaries. :)
15:33:04 <limburgher> abadger1999: Probably.
15:33:24 <racor> I regret, today's meeting doesn't work out for me ... I've got leave.
15:33:26 <geppetto> tibbs|h: I assume not … at least try shipping rpmfusion rot13'd and see how fast spot/legal hurt you :)
15:34:18 <geppetto> Do we have enough +1's for abadger1999 text now?
15:34:22 <tibbs|h> Mentioning rpmfusion is really bad for any counterargument.
15:34:41 <tibbs|h> Because it would be banned under any guideline we make, due to legal reasons.
15:35:00 <tibbs|h> Nobody's talking about allowing rpmfusion here.
15:35:23 <geppetto> Yes, but what I'm saying is that I think rot13'd .repo files would be banned under the same conditions as non-rot13'd .repo files
15:35:24 <limburgher> No.  But the point is that foorepo in the future might have similar content.
15:35:34 <limburgher> geppetto: <nod>
15:35:40 <tibbs|h> That is the business of the lawyers, not us.
15:36:00 * abadger1999 Agrees with tibbs
15:36:11 <limburgher> I think if we mention the legal guidelines, we're cool.
15:36:13 <tibbs|h> If you want to ban everything that might get into trouble with some lawyer, we should close up shop now because we obviously can't ship a distro.
15:36:19 <rdieter> +1 for abadger1999's version too, fwiw.
15:36:40 <geppetto> again, dito +1 abadger1999 version
15:36:43 <limburgher> +1
15:36:50 <abadger1999> +1
15:37:06 <abadger1999> My version is https://fedorahosted.org/fpc/ticket/106#comment:3
15:37:19 <limburgher> tibbs|h: Not saying we should do that, but we can at least avoid stepping on exposed mines.
15:37:56 <tibbs|h> abadger1999: +1 to that version.
15:38:58 <abadger1999> #action repository file treatment Approved (+1:5, 0:0, -1:0)
15:39:19 <abadger1999> #topic Open Floor
15:39:29 <tibbs|h> What about 107?
15:39:36 <tibbs|h> https://fedorahosted.org/fpc/ticket/107
15:40:02 <tibbs|h> This seems reasonable to me, but I'm not exactly familiar with MPI these days.
15:40:02 <abadger1999> #topic Ban autoloading of MPI environment   https://fedorahosted.org/fpc/ticket/107
15:41:04 <tibbs|h> The draft adds one line to the MPI guidelines:
15:41:09 <tibbs|h> MUST: If the maintainer wants to provide autoloading support for the MPI environment, it must be placed in a separately installable subpackage.
15:41:13 <limburgher> Seems ok.  Not harmful, just explicitifies things.
15:41:19 <rdieter> seems reasonable, and in the spirit of how things should work.
15:41:26 <tibbs|h> Unfortunately I'm not sure if "autoloading support" is clearly defined.
15:41:53 <rdieter> .bug 647147
15:41:56 <zodbot> rdieter: Bug 647147 Violation of MPI packaging guidelines: automatic loading of module in main package - https://bugzilla.redhat.com/show_bug.cgi?id=647147
15:41:59 <tibbs|h> Does it make sense in context?  "autoload" isn't mentioned anywhere else in the guideline.
15:41:59 <rdieter> ^^ some of the disagreement going on...
15:42:54 <tibbs|h> I think the point about the MPI stuff is that there are various mpi-specific commands with common names, and the user is supposed to be able to choose from the available versions with some profile magic.
15:43:14 <rdieter> that's my general understanding too
15:43:20 <tibbs|h> But mpich2 forces its variants to be used if it's installed because it installs the profile magic globally.
15:43:31 <tibbs|h> Which seems antisocial at best.
15:43:59 <abadger1999> <nod>
15:44:14 <geppetto> seems fine to require a sub-package to me
15:45:13 <tibbs|h> I agree with what's being done; I just want to make sure that the wording won't generate more questions than it solves.
15:46:06 <limburgher> Yeah.
15:46:23 <tibbs|h> What does "autoloading support" mean in this context?
15:47:35 <abadger1999> I'd even be okay with telling people not to "autoload" the modules.
15:48:14 <limburgher> abadger1999: <nods>
15:49:17 <rdieter> well, loading and unloading is defined in the mpi guidelines, so maybe rephrase it as something like:  If the maintainer wants to provide support for automatically loading an MPI environment, it must be placed in a separately installable subpackage."
15:49:31 <tibbs|h> Oh, wow, the profile.d stuff in the mpich2 package just does "module load mpich2-i386".
15:49:46 <tibbs|h> That does seem kind of antisocial.
15:50:02 <limburgher> Yikes.
15:50:24 <abadger1999> nirik: If I could ask you, is there a way to specify a default set of environment-modules to load?  In the case we're looking at, we have multiple mpi variations.
15:50:49 <nirik> not sure off hand.
15:50:53 <tibbs|h> OK, what I think I'd do is move the new "MUST" down underneath the stuff it's talking about.
15:51:02 <abadger1999> k
15:51:05 <nirik> I don't think anything loads by default unless you specifically load it.
15:51:11 <abadger1999> <nod>
15:51:38 <abadger1999> nirik: Yeah... so one maintainer is creating a profile.d script that does exactly that.... which seems to defeat the purpose.
15:52:04 <nirik> yeah, then it's always on when installed...
15:52:04 <rdieter> this is in the same spirit as shipping non-default .repo files.  :)  you can ship them, just don't enable it by default...
15:52:47 <limburgher> <headdesk>
15:54:32 <tibbs|h> So push the new line down a few lines, and change it to: If the maintainer wishes for the "module load" to happen automatically, by use of the /etc/profile.d mechanism, this MUST be done in a subpackage.
15:54:41 <tibbs|h> Or is this too specific?
15:55:13 <rdieter> ... by the use of /etc/profile.d/ scriptlet (or some other mechanism)
15:55:23 <rdieter> keep it open ended
15:55:32 <tibbs|h> Sure.
15:56:27 <rdieter> there's already a section about alternatives similarly:  MUST: By default, NO files are placed in /etc/ld.so.conf.d. If the packager wishes to provide alternatives support, it MUST be placed in a subpackage along with the ld.so.conf.d file so that alternatives support does not need to be installed if not wished for.
15:57:24 <rdieter> so maybe we can be specific here
15:58:05 * rdieter doesn't care much either way
15:58:42 <tibbs|h> Yeah, and directly under that is where the new line is.
15:59:20 <tibbs|h> Anyway, we're out of time, I think.
15:59:36 <rdieter> worksforme, can we vote on it quickly?
15:59:49 <limburgher> +1
15:59:53 <tibbs|h> +1
15:59:59 <abadger1999> +1
16:00:01 <rdieter> +1
16:00:41 * abadger1999 might like to have the environment modules guideline enhanced in the future to account for default and no-default cases but this is good for now.
16:00:51 <abadger1999> geppetto: ?
16:02:52 <abadger1999> well, we're stuck at +4 unless geppetto votes.
16:03:20 <abadger1999> I'll record our +4 in the ticket and say that we're looking for the remaining votes.
16:03:30 <Southern_Gentlem> carry over till next meeting
16:03:45 <abadger1999> tibbs|h: Would you update the draft page to reflect the updated wording?
16:03:55 * abadger1999 will update the other ticket/guidelines
16:03:57 <Southern_Gentlem> abadger1999,  no Fudcon Blacksburg meeting today
16:04:25 <abadger1999> Southern_Gentlem: Ah.  thanks for letting us know!
16:04:35 <Southern_Gentlem> so no rush
16:04:40 <abadger1999> I think we're about done, though.... we've lost quorum apparently.
16:04:47 <limburgher> bummer
16:04:58 <tibbs|h> abadger1999: Sure.
16:05:07 <abadger1999> Alright.  Thanks everyone!
16:05:16 <abadger1999> #endmeeting