16:00:56 <spot> #startmeeting Fedora Packaging Committee
16:01:05 * tibbs here
16:01:25 <tibbs> BTW,  the URL for that command guide would be useful.
16:01:32 <spot> http://wiki.debian.org/MeetBot
16:01:40 * limburgher oh captain, my captain
16:02:25 <spot> abadger1999, SmootherFrOgZ, rdieter ping
16:02:25 <tibbs> Oh, I thought there was something Fedora specific.
16:02:35 * SmootherFrOgZ is here
16:02:39 <spot> tibbs: if so, i don't know about it
16:02:55 <rdieter> here
16:03:06 <tibbs> .nextfpcmeeting
16:03:16 <tibbs> Guess we need to get that fixed.
16:03:38 <spot> tibbs: i didn't know zodbot did that. :)
16:04:05 * abadger1999 here as well
16:04:13 * spot doesn't see Rathann (i think he's still on vacation), racor, or hans
16:04:32 <spot> but, we have quorum
16:04:41 <rdieter> hans pinged me on irc earlier asking about when this was, I'd expect he'll be here
16:04:54 <tibbs> hansg is in #fedora-devel
16:05:54 <spot> okay, thats 7
16:05:57 <hansg> Hi all
16:06:07 <spot> #info FPC has quorum!
16:06:07 <limburgher> hansg: yo.
16:06:24 <hansg> Hi Jon, welcome aboard :)
16:06:31 <limburgher> hansg: thx. :)
16:06:35 <spot> #topic OSGi Packaging Guidelines https://fedoraproject.org/wiki/PackagingDrafts/OSGiGuidelines
16:07:21 <spot> allow me to prefix this discussion with the statement that Java hurts my brain
16:07:29 <rdieter> ditto
16:07:30 <tibbs> I have to admit that no matter how many times I read that draft I still don't understand what's going on.
16:07:43 <limburgher> metoo
16:08:05 <spot> lemme see if overholt is around
16:08:08 <tibbs> I really I thought that I had asked for someone to at least expand "OSGi" at least once in that document.
16:08:17 <limburgher> At first glace it looks like find_lang for jars.
16:09:12 <overholt> hi
16:09:17 <spot> overholt: can you explain what an OSGi bundle is (and what OSGi stands for)?
16:09:29 <overholt> sure
16:09:36 <overholt> OSGi = Open Services Gateway Initiative
16:09:42 <overholt> but that's meaningless
16:09:57 <overholt> an OSGi bundle is a JAR of java bytecode with some metadata
16:10:10 <overholt> OSGi is basically a module system for Java
16:10:17 <spot> are they prebuilt JARs?
16:10:19 <overholt> no
16:10:22 <overholt> well
16:10:25 <overholt> they _can_ be
16:10:35 <overholt> but not in Fedora, obviously
16:10:58 <tibbs> So you take some source, build it in the usual manner, and what comes out is a jar with some metadata embedded?
16:11:03 <overholt> yup
16:11:05 <overholt> we've already got them
16:11:07 <overholt> tonnes of them
16:11:17 <overholt> we just want to use the information in them to generate Provides and Requires
16:11:21 <tibbs> And we want to be able to use that metadata to generate better dependency data .
16:11:22 <overholt> like mono or other languages
16:11:25 <overholt> exactly
16:11:42 <limburgher> So it *is* find_lang for jars.
16:11:46 <overholt> :)
16:11:51 <tibbs> Well, not find_lang.
16:11:53 <overholt> I don't think it's find_lang exactly
16:12:00 <tibbs> More like the perl dependency generator for java.
16:12:05 <overholt> it's like the python and perl and mono generators in RPM
16:12:18 <spot> So, my problem with this draft is that it is extremely difficult to parse. I read it 6 or 7 times and I didn't manage to come anywhere near this conclusion.
16:12:20 <overholt> tibbs: more specifically for OSGi bundles (not general "java")
16:12:22 <limburgher> Gotcha
16:12:27 <tibbs> OK.
16:12:51 <spot> Not to mention that it has three proposed implementation methods
16:12:53 <tibbs> My question is: why is this a guideline?
16:13:04 <tibbs> Why not just turn the stuff on in rpm and be done with it?
16:13:05 <hansg> Well I did understand the this is another dependency generator part of the draft, but then it discusses the problem with sharing bundles and symlink, etc. Names 3 solutions, but does not pick one
16:13:07 <limburgher> I'm with spot.  I'd like to see a concise "how this affects you and what to do about it" section.
16:13:22 <limburgher> +1 hans
16:13:24 <spot> hansg: indeed.
16:13:53 <overholt> Alphonse has told me before he's not terribly comfortable with his English abilities
16:13:53 <hansg> So I have to side with tibbs here this does not feel like a guideline, more like an rpm feature description, which then lists some to be resolved issues without coming to a resolution
16:14:04 <spot> I think this could be massively simplified into "here is how you get deps from OSGi bundles and here is an example of how a Fedora package should use them"
16:14:15 <overholt> I think he assumed he had to get a guidelines in before it could be turned on distro-wide
16:14:18 <hansg> To make this a guideline it should choose one of the 3 solutions and explain how to consistently implement this
16:14:22 <tibbs> Well, we can discuss how we want the deps to look as formatted by the dependency generator.
16:14:53 <tibbs> I think we can all agree that this kind of thing is wanted as long as it's not going to go and generate hundreds of weird dependencies or other random cruft.
16:15:07 * spot nods
16:15:16 <overholt> Alphonse did lots of testing on all packages in the distro with OSGi bundles
16:15:18 <limburgher> Maybe the rest can be a linked-to backgournd page.
16:15:22 <overholt> he was very satisfied with the results
16:15:26 <spot> the spirit of this draft is fine, but it needs to be simplified significantly
16:15:41 <overholt> so perhaps just tell Alphonse that this shouldn't really be a guideline?
16:15:47 <tibbs> Could we see what provides/requires look like for a couple of packages?
16:15:52 <tibbs> Just to make sure that's sane.
16:15:59 <spot> overholt: well, i think there is some guideline material here
16:16:01 <overholt> I don't have one off hand, but IIRC it's osgi(package name)
16:16:11 <spot> unless rpm is handling this all behind the scenes
16:16:15 <overholt> tibbs: it can be changed
16:16:18 <overholt> rpm is handling this
16:16:22 <overholt> it just needs to be turned on
16:16:31 <spot> overholt: in that case, i think we should just have it turned on.
16:16:33 <tibbs> If there's something that packages need to do to interact with the dependency system, then we do need to document that in the guidelines.
16:16:34 <overholt> I guess the part about how to deal with symlinked stuff should be a guideline
16:16:42 <limburgher> overholt: so it's more of a Feature. . .
16:16:43 <overholt> there's nothing packages need to do
16:17:01 <overholt> limburgher: yes.  I originally thought Alphonse was going to propose a Feature for this
16:17:03 <tibbs> "RPM will now automatically generate dependencies for java packages with embedded OSGi metadata."
16:17:13 <overholt> yup
16:17:30 <tibbs> "When creating packages, you need to be aware of the following: symlink issue, etc."
16:17:37 <abadger1999> I think option #3 is the way that has precedent in Fedora.
16:17:39 <overholt> I'll tell Alphonse to simplify it to that part
16:17:57 <spot> overholt: thanks
16:17:58 <overholt> abadger1999: it does
16:18:00 <hansg> overholt, well we do need a guideline for the jar / bundle sharing thingie, although we could point to the regular java guidelines there (which means putting the sharable units directly under %{_javadir} so every normal java app can find it there
16:18:31 <overholt> hansg: yes, a decision should be made on how to handle the symlinked case
16:18:31 <limburgher> hansg: so the text length should drop dramatically. :)
16:18:37 <overholt> _that_ will be a guideline
16:18:43 <overholt> I'll work with Alphonse on this
16:18:45 * limburgher nods
16:18:49 <spot> overholt: i'd strongly suggest that you guys just pick one. :)
16:18:56 <jds2001> I *think* there was such a feature.
16:18:58 <overholt> spot: sure
16:19:11 <jds2001> that we declined, because it seemed more to change java packaging guidelines.
16:19:16 <overholt> ha
16:19:17 <overholt> :)
16:19:20 <jds2001> and we wanted FPC to review that.
16:19:43 <abadger1999> So... just a matter of clarifying what is actually being changed to decide who needs to review what :-)
16:19:48 * limburgher <headdesk>
16:19:53 <jds2001> so now we've officially gone full circle :)
16:19:56 <spot> i think if it is worded more specifically around turning on automatic OSGi dependency capturing in rpm, we shouldn't need to "bless" it
16:20:14 <jds2001> that makes sense.
16:20:14 <overholt> I'll take care of this
16:20:27 <spot> overholt: thank you. :)
16:20:27 * hansg looks at the chairman of this meeting to move to the next agenda item
16:20:52 <spot> #action OSGi enablement to be driven as a feature, new draft coming for Guidelines relevant bits
16:21:14 <spot> #topic filesystem subpackages https://fedoraproject.org/wiki/PackagingDrafts/CreatingFilesystemSubpackages
16:22:13 <spot> I'm not sure about this one, to be honest.
16:22:22 <limburgher> I still don't understand why this is different than -common.
16:22:56 <tibbs> I don't either, honestly.
16:22:59 <rdieter> there's nothing in the guidelines that mention -common is there ?
16:23:02 <hansg> Hmm
16:23:05 <vdw> does this even have to be a guideline, as you'd otherwise end up with file conflicts?
16:23:06 * hansg is not a big fan of this
16:23:11 <spot> rdieter: i don't think so
16:23:21 <rdieter> then it's different than -common. :)
16:23:32 <spot> vdw: well, for files yes, not so much for directories
16:23:41 <hansg> I esp, dislike the "If two or more packages provide ..."
16:24:00 <limburgher> hansg: Indeed, that shouldn't really happen. . .
16:24:03 <spot> hansg: yeah, we generally permit duplicate ownership of directories in several scenarios (e.g. perl)
16:24:49 <tibbs> Is there an actual problem that this guideline is supposed to solve?  Some existing argument over the details that prompted Jochen to write it?
16:24:53 <spot> also, i think if i wanted something like this, i would prefer -common
16:24:55 <rdieter> exactly, The sprit of it is in a good place, but it's lacking justification.
16:25:13 <abadger1999> I'm wondering what the problem being solved is.
16:25:26 <vdw> I'm having trouble seeing what kind of packages only need empty directories; usually there are shared files in them so the logical destination is -common
16:25:27 <SmootherFrOgZ> abadger1999: correct
16:25:30 <abadger1999> heh.  I'm slow on the keyboard today.
16:25:30 <limburgher> spot: In bacula, we had a -common, and had a bug filed to make a -filsystem.
16:25:47 <spot> limburgher: and the reasoning given?
16:25:49 <tibbs> That... makes no sense.
16:25:56 <rdieter> having used both -filesystem and -common myself, I opt for -filesystem if it's mostly/all just directory ownership, if it involves  files, -common
16:26:19 <abadger1999> .whoowns filesystem
16:26:30 <spot> well, filesystem is a "special" package
16:26:30 <rdieter> but -common could work everywhere too, no biggie
16:26:34 <limburgher> rdieter: I like -common generally.
16:26:40 <abadger1999> Do we have any difficulties getting directories added to the base filesystem package?
16:26:43 <tibbs> It seems to me that some packagers just decided to use -filesystem, others use -common.
16:26:49 <rdieter> abadger1999: yes
16:26:52 <abadger1999> k
16:26:55 <tibbs> If we want to standardize how you name those, I guess we could.
16:27:03 <limburgher> tibbs: Is there a need to set a convention, or is that just bikeshedding?
16:27:25 <tibbs> Without knowing why this guideline was written, I can't say.
16:27:28 <spot> I don't think there is any burning need to set a forced convention here.
16:27:30 * nirik notes also bug 501518 that Jochen filed, perhaps this is related to this guideline request?
16:27:31 <buggbot> Bug https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=501518 medium, low, ---, kevin, CLOSED WONTFIX, Rfe: Creating of a filesystem subpackage
16:28:07 <nirik> (in which case we decided we didn't need one and didn't make one)
16:28:15 <tibbs> Well, we do keep running into the directory ownership issue.
16:28:31 <tibbs> I guess that's the source of the MUST in this draft.
16:29:03 <tibbs> Another example is packages that put things in /etc/prelink.conf.d.
16:29:07 <limburgher> tibbs:  I'm not sure I see where this fixes that where -common or simple inclusion in %files wouldn't.
16:29:16 <tibbs> Should they own that directory?  Or require prelink?  Certainly not the latter.
16:29:41 <limburgher> For drupal plugins, they live in a directory owned by drupal, and require drupal.
16:29:51 <tibbs> Smartest solution is to add /etc/prelink.conf.d to the filesystem package.
16:30:26 <spot> Yeah, i'd rather work to improve the system filesystem package to own "common" directories than have lots and lots of little -filesystem packages
16:31:01 <abadger1999> rdieter: Now I'm wondering why we have problems getting things added to filesystem.  Is it b/c filesystem is supposed to stay small?  Maintainer non-responsive to requests?
16:31:14 <tibbs> Do we actually have that problem?
16:31:27 <rdieter> abadger1999: all I know is that the man/locale issue got punted back-n-forth for a long time
16:31:31 <tibbs> I mean, kde-filesystem does make sense to me, but prelink-filesystem certainly wouldn't.
16:32:04 <tibbs> In any case, I don't think there's much chance of this guideline passing as is.
16:32:17 <rdieter> right, I'd propose punting it back asking for justification, or deny it outright.
16:32:17 * limburgher nods
16:32:18 <spot> new maintainer seems much more able
16:32:37 <spot> lets try to drive improvements forward through Ondrej
16:32:58 <rdieter> alright
16:33:01 <spot> #action Draft rejected, prefer to work on improving base filesystem package.
16:33:22 <spot> #topic MPI https://fedoraproject.org/wiki/PackagingDrafts/MPI
16:33:33 <abadger1999> for the record: man, locale bug: https://bugzilla.redhat.com/show_bug.cgi?id=220265
16:33:35 <buggbot> Bug 220265: medium, medium, ---, ovasik, ASSIGNED, Many unowned directories in /usr/share/man
16:33:54 <spot> So, I have a few packages which depend on MPI, so I spent a lot of time looking over these guidelines.
16:34:11 <spot> I actually went ahead and converted them to use this methodology in Rawhide, and they work reasonably well.
16:34:32 <vdw> spot: but the MPI compilers haven't yet been modified for the macros..?
16:34:48 <spot> vdw: i know, i temporarily hardcoded the macros into the spec files
16:35:05 <vdw> spot: OK.
16:35:27 <vdw> So, the open question here is whether to suffix or not
16:35:38 <hansg> This draft seems written by someone who knows a lot about this and who has put a lot of thinking in this, and after a full reason I cannot find any obious faults, so +1
16:35:56 <vdw> having suffixes makes it easier to run the serial (non-MPI) version in combination with the MPI version
16:35:57 <rdieter> vdw: _cc_name_suffix ?
16:36:03 <rdieter> or something else?
16:36:26 <vdw> rdieter: %{_openmpi_load} and so on
16:36:28 <tibbs> If we're going to suffix, I'd much prefer dashes to underscores in the suffix.
16:37:00 <vdw> suffixing should be better also considering libraries
16:37:02 <tibbs> The guideline shows underscores in one place and dashes elsewhere.
16:37:23 <vdw> tibbs: the dash is in package names, the underscore in library and binary names
16:37:24 <tibbs> The binaries MUST be suffixed with $MPI_SUFFIX (e.g. _openmpi for Open MPI, _mpich2 for MPICH2 and _lam for LAM/MPI). T
16:37:28 <spot> tibbs: really? i thought the macros were consistently underscores
16:37:39 <tibbs> Not the macros, the actual suffix.
16:37:41 <spot> ahh, i see
16:38:27 <spot> Yeah, - makes things a bit cleaner there, i suppose.
16:38:49 * vdw thinks _mpi is more standard
16:39:21 <spot> I honestly don't care much, i think that might be bikeshedding to argue - vs _
16:39:26 <abadger1999> Is there anything else that creates a  subdirectory in /usr/bin?
16:39:26 <tibbs> True.
16:39:34 <hansg> spot, ack
16:39:46 <tibbs> I don't know of anything.
16:40:07 <hansg> abadger1999, good point
16:40:11 <vdw> By the way, should I write something about library suffixes? Does libfoo in LD_LIBRARY_PATH take precedence of libfoo in %{_libdir}?
16:40:28 <hansg> vdw,  LD_LIBRARY_PATH takes precedence
16:40:41 <vdw> hansg: OK, so that's not a problem then
16:40:49 <hansg> vdw, did you look at other distro's ?
16:41:04 <spot> Well, i think the subdir in %{_bindir} is to try to keep with the spirit of the FHS
16:41:08 <spot> which i appreciate
16:41:25 <hansg> vdw, abadger1999 remark got me thinking that we may want to handle this more as cross compilers
16:41:57 <vdw> hansg: Yes, I have had a look at how Debian handles things
16:42:23 <abadger1999> spot: <nod>  But I'm not sure what the spirit of the FHS is here....
16:42:41 <spot> well, they can't go into just %{_bindir}, or they'd conflict
16:42:45 <vdw> they actually use .{lam,mpich,openmpi} for binaries and _{lam,mpich,openmpi} for libraries
16:42:48 <hansg> vdw, the again maybe not (handle as cross compilers) having subdirs under /usr/share /usr/share/man /usr/lib[64] and /usr/libdir is quite normal, so I guess having them under /usr/bin too sort of makes sense /  is consistent
16:43:03 <spot> so they either get their own directory, or a suffix
16:43:13 <vdw> and install everything in %{_bindir} and %{_libdir}
16:43:23 <spot> the suffix might be cleaner for the binaries
16:43:28 <tibbs> The only other precedent I can think of is /usr/kerberos/bin.
16:43:31 <abadger1999> subdirectory in /usr/bin is very odd.  Perhaps %{_libdir}/%{name}-%{_arch}%{?_cc_name_suffix}/ or %{_libexecdir}%{name}-%{_arch}%{?_cc_name_suffix}/
16:43:34 * hansg thinks their own dir is better, then one can easily switch changing just PATH
16:43:46 <vdw> I'm not sure how they handle the runtime issue
16:44:12 <hansg> abadger1999, it has not been done before, but it is consistent with how libraries / headers / manpages / etc are handled
16:44:15 * abadger1999 likes dirs as well.
16:45:19 <abadger1999> For instance, firefox puts its binary into /usr/lib/firefox*
16:45:19 <spot> abadger1999: well, the %{_libdir}/%{name}%{?_cc_name_suffix} already exists
16:45:33 <spot> i don't think we need the arch embedding if we're going into libdir
16:45:49 <abadger1999> <nod>
16:46:20 <spot> does anyone think that's a bad idea?
16:46:30 <spot> to put the binaries in  %{_libdir}/%{name}%{?_cc_name_suffix}/
16:46:42 <hansg> either is fine with me
16:46:43 <vdw> spot: that would be kind of against the FHS..
16:46:53 <limburgher> I can't see a problem with it per se. . .
16:47:12 <vdw> A policy is missing on where to put binaries with problematic names
16:47:16 <hansg> vdw, not really we've plenty of cases where executables live under %{_libdir}
16:47:39 <vdw> hansg: yes, but is it *really* the correct place to put them in? :)
16:48:17 <vdw> anyway, I'm fine with  %{_libdir}/%{name}%{?_cc_name_suffix}/ too.
16:48:27 <hansg> vdw, well they are arch dependend so if we cannot put them under /usr/bin /usr/lib[64] is pretty much all that is left
16:48:35 <spot> vdw: i think it is. there is precedent there and it keeps things simple
16:48:43 <spot> if we use libexecdir, we have to embed arch in the name
16:49:00 <limburgher> spot: which is sort of ugly. . .
16:49:17 <spot> exactly, so since we already have this libdir, i propose we use it for the binaries
16:49:30 <hansg> I prefer libdir over libexecdir too, esp. as libexecdir is sort of a Fedora invention (not really FHS)
16:49:44 <mjg59> Well, more of a Unix invention
16:49:44 <vdw> So what's the reason for not using %{_bindir}/%{name}-%{_arch}%{?_cc_name_suffix}/?
16:49:48 <tibbs> It's.... very much not a Fedora invention.
16:50:00 <abadger1999> hansg: It's a GNU invention.
16:50:02 <vdw> not having dirs in /usr/bin at the moment?
16:50:04 <spot> vdw: nothing else does it?
16:50:08 <abadger1999> yeah, or unix before it.
16:50:21 <vdw> spot: ok.
16:50:44 <spot> whereas, we have binaries in %{_libdir}/subdirs for similar reasons now
16:50:48 <tibbs> The thing is, if we want to go endorsing subdirs in bin, which hasn't been done before, I think we probably need to get more public input.
16:51:21 <vdw> OK. Then I'll need to change the location of the libraries as well. So binaries in %{_libdir}/%{name}%{?_cc_name_suffix}/bin and libraries in %{_libdir}/%{name}%{?_cc_name_suffix}/lib
16:51:44 <spot> vdw: why? are you worried about binary/library naming conflicts? :)
16:52:14 <spot> i mean, you could do that, but i don't think it is necessary
16:52:54 <vdw> spot: because AFAIK other packages do it too?
16:53:09 <hansg> I think what vdw proposes so have  %{_libdir}/%{name}%{?_cc_name_suffix}/{bin,lib} makes sense
16:53:40 <hansg> It keeps libs and binaries seperate, so for one it will keep libs out PATH (and binaries out LD_LIBRARY_PATH)
16:53:58 <spot> okay, so there are enough proposed changes here that I think i'd like to see the draft rewritten before we vote on it
16:54:20 <vdw> spot: I can do the changes now
16:54:23 <abadger1999> Also noting that MPI_PYTHON_SITEARCH is a bit strange but setuptools already abuses python_sitearch/lib in a similar manner.
16:54:29 <abadger1999> So I'm okay with it.
16:54:31 <spot> vdw: okay, we'll give you a minute then.
16:56:10 <vdw> OK, should be done
16:56:14 * spot notes that the revisions will also make the example in https://fedoraproject.org/wiki/PackagingDrafts/EnvironmentModules correct... :)
16:57:04 <tibbs> Ancillary question: did the discussion about _fmoddir ever come to a conclusion:?
16:57:08 <SmootherFrOgZ> vdw: hey, did you have a look at mingw32 packages ?
16:57:09 <spot> vdw: i think you need to correct the table entry for MPI_BIN
16:57:43 <spot> ... and MPI_LIB
16:58:41 <vdw> spot: yes, I realized that right after my comment, just click on refresh :)
16:59:07 <vdw> tibbs: No. That should be one of today's topics..
16:59:24 <vdw> SmootherFrOgZ: no, I did not
16:59:35 <tibbs> Well, probably not today.
16:59:52 <spot> well, the value of fmoddir is not necessarily material to this draft as the macro exists today
17:00:06 <tibbs> True.
17:00:15 <tibbs> Which is why it was an ancillary question.
17:00:17 <spot> So, lets vote on the revised draft:
17:00:28 <SmootherFrOgZ> vdw: should have a look when got a momment, they put _arch-_name_cc-suffix in __bindir
17:00:46 <spot> +1 from me
17:01:05 <limburgher> +1
17:01:36 <tibbs> +1
17:01:41 <rdieter> +1
17:01:46 <hansg> vdw, I notice in the environment module draft, that the openmpi version is part of the path there, could it be we would want to support multiple mpifoo versions in one install ?
17:01:52 <hansg> vdw, iow could that be a good idea ?
17:02:04 <tibbs> Although honestly I kind of wish the EPEL-specific stuff could go out to a page on EPEL-specific guidelines.
17:02:10 <spot> tibbs: it will
17:02:16 <abadger1999> +1
17:02:27 * hansg is waiting on an answer from vdw
17:02:37 <vdw> hansg: I just removed the versioning as I don't see any reason why we should support multiple versions of the same MPI runtime
17:02:45 <vdw> we support multiple MPI runtimes
17:02:48 <hansg> vdw, ok, good enough for me
17:02:50 <tibbs> BTW, do we know of Doug Ledford is onboard with these guidelines at all?
17:02:50 <SmootherFrOgZ> +1
17:02:50 <hansg> +1
17:02:52 <vdw> and runtimes compiled with different compilers
17:02:58 <vdw> tibbs: I got an OK from him today
17:03:01 <spot> tibbs: he is, i saw some of this discussion
17:03:11 <tibbs> OK, good.  I'd hate to start a flamewar over that.
17:03:17 <vdw> "The current drafts look good to me.  If the packaging committee
17:03:18 <vdw> approves this stuff, then I'll update lam/openmpi asap."
17:03:31 <spot> #action MPI draft passes, goes to FESCo for ratification
17:03:46 <spot> #topic Environment Modules https://fedoraproject.org/wiki/PackagingDrafts/EnvironmentModules
17:03:59 <spot> i know we're at an hour, but these two are closely related
17:04:21 <vdw> tibbs: the EPEL stuff is just in the "Required changes" part so it won't be visible anywhere after the guidelines have been implemented
17:04:51 <hansg> EnvironmentModules, +1 as is
17:05:00 <spot> +1 from me as well, clean and concise
17:05:11 <SmootherFrOgZ> +1
17:05:12 <rdieter> +1
17:05:12 <tibbs> EnvironmentModules makes sense to me; are these used anywhere else?  Other distros, perhaps?
17:05:24 <limburgher> +1.  Looks neat!
17:05:27 <spot> tibbs: pretty sure debian has this as well
17:05:32 <vdw> tibbs: Supercomputers, mostly
17:05:38 <vdw> and clusters
17:06:28 <spot> i count +5 on the topic, tibbs, abadger1999, want to go on the record? :)
17:07:00 <tibbs> I don't think the "Using environment modules" section belongs in a guideline.
17:07:17 <abadger1999> Looks good and straightforward.  I note that nirik thought it looked good as well.
17:07:18 <abadger1999> +1
17:07:42 <spot> tibbs: i don't think it is necessarily a bad thing to have there, if for no other reason, it will aid reviewers
17:07:46 <hansg> tibbs, true but as background info it helps a lot to understand how they work
17:08:03 <tibbs> So add a link to the documentation.
17:08:13 <abadger1999> Can I get approval to mention this in the conflicts page as well?
17:08:15 <limburgher> tibbs: and using them could save us from some braindeadedness
17:08:26 <abadger1999> (alongside alternatives)
17:08:35 * hansg got to go
17:08:41 <spot> abadger1999: yes, we said that would be fine when we talked about it before
17:08:42 * limburgher waves
17:08:53 <abadger1999> Excellent.
17:09:36 <spot> tibbs: the section is two lines long, one of which is a link to the docs.
17:09:47 <tibbs> Principle, sorry.
17:09:59 <tibbs> We have too much stuff in the guidelines already.
17:10:13 <tibbs> Anyway, it passed without me.
17:10:23 <spot> tibbs: fair enough. this will end up as a separate page anyways, so i think the impact is minimal.
17:10:45 <tibbs> Which gives tacit approval for end user documentation to end up in the guidelines.
17:10:50 <tibbs> Which is why I'm against it.
17:10:56 <spot> #action Environment Modules passes, sent to FESCo for ratification
17:11:23 <tibbs> That stuff belongs in a man page or in the release notes.  It needs to get in there anyway, regardless of what gets in the guidelines.
17:11:40 <spot> A valid point, I suppose.
17:12:08 <spot> should we continue today (we have plenty of items in the queue) or adjourn to next week?
17:12:31 <tibbs> I have a little time.
17:12:33 <limburgher> I can keep on.
17:12:56 <tibbs> Anything non-controversial.
17:12:57 * rdieter can go for a little while
17:13:01 <tibbs> ?
17:13:08 <spot> Well, there are a few easy items
17:13:23 <spot> #topic https://fedoraproject.org/wiki/PackagingDrafts/DropScrollkeeperUpdate
17:13:48 <tibbs> Oh, definitely +1.
17:13:53 <limburgher> Dead simple. +1
17:13:53 <spot> +1
17:13:57 <rdieter> +1
17:14:00 <SmootherFrOgZ> +1
17:14:18 <spot> #action DropScrollkeeperUpdate passes, goes to FESCo for ratification
17:14:31 <spot> #topic https://fedoraproject.org/wiki/ProposalUpdateRGuidelines
17:15:10 <tibbs> +1
17:15:13 <spot> +1
17:15:22 <limburgher> +1
17:15:36 <rdieter> +1
17:15:49 <SmootherFrOgZ> +1
17:16:06 <tibbs> I wonder if it's worth mentioning there that at least bioconductor will only provide the latest version of any particular module.
17:16:07 <spot> #action ProposalIUpdateRGuidelines passes, goes to FESCo for ratification
17:16:09 <tibbs> Probably not.
17:16:25 <tibbs> But that does have implications for nirik's source URL checks.
17:16:27 <spot> #topic https://fedoraproject.org/wiki/PackagingDrafts/JavaAntSampleSpec
17:16:41 <tibbs> +1 how'd we miss that?
17:16:51 <spot> eh, we're only human.
17:16:52 <spot> +1
17:17:06 <tibbs> Which of the options should we pick?
17:17:08 <limburgher> +1, I think the second is clearer to n00bs.
17:17:16 <spot> i prefer the second
17:17:26 <rdieter> +1 (2nd)
17:17:28 <SmootherFrOgZ> +1
17:17:45 * nirik notes if there is no URL in the Source*: line, my script just ignores it since it doesn't know how to check it.
17:17:47 <rdieter> maybe even  rm -fv  so it's verbose about what gets nuked?
17:18:11 <spot> #action JavaAntSampleSpec passes (option 2), goes to FESCo for ratification
17:18:33 <spot> so, i think all of the remaining items are somewhat... controversial
17:18:50 <spot> https://fedoraproject.org/wiki/PackagingDrafts/PythonNumpy might not be
17:18:57 <limburgher> rdieter: not a bad idea
17:19:28 <limburgher> spot: We've been discussing it on -devel.
17:20:15 <spot> limburgher: ajax asked me to put that in the guidelines
17:20:39 <spot> numpy is a rather heavy dependency for a single function
17:20:57 <limburgher> spot: as long as it's not hugely labourious and doesn't horribly break things, I'm ok with it.
17:21:09 <ajax> it requires adding some more deps to a few things
17:21:24 <ajax> my initial estimate of just the one package might not be accurate
17:21:32 <ajax> but it's, like, six.
17:21:42 <tibbs> If the dependency was dropped already, those packages will need to be fixed regardless of what we do to the guidelines.
17:21:46 <spot> ajax: if you can send me a list of the changes, i'll go ahead and make them (assuming this draft is approved)
17:22:41 <ajax> tibbs: it hasn't been dropped yet.
17:22:42 <tibbs> What's the failure mode of those apps if numpy isn't installed?
17:22:50 <ajax> fatal exception
17:22:59 <rdieter> why not "just do it
17:23:01 <tibbs> But it's not necessarily a startup failure, right?
17:24:13 <ajax> tibbs: right.
17:24:22 <rdieter> I mean, this doesn't feel like a packaging guideline to me, just a "we're changing deps" kind of thing.
17:24:26 <limburgher> Shouldn't blow up intill it's called.
17:24:42 <ajax> rdieter: yeah, but it's a strange enough case to be worth writing down.
17:24:45 <ajax> i think, anyway.
17:24:51 <spot> ajax: i agree
17:24:55 <tibbs> rdieter: I'm pondering the same thing, but it does seem sufficiently bizarre that it might be worth noting.
17:25:19 <spot> given that in general, you would expect a library to require all the things necessary to use it
17:25:25 <rdieter> ok, let's "just do it here" then, +1
17:25:29 <spot> +1
17:25:34 <tibbs> +1
17:25:37 <spot> #action https://fedoraproject.org/wiki/PackagingDrafts/PythonNumpy
17:25:38 <limburgher> +1
17:25:55 <spot> err... #topic https://fedoraproject.org/wiki/PackagingDrafts/PythonNumpy
17:25:58 <spot> #topic https://fedoraproject.org/wiki/PackagingDrafts/PythonNumpy
17:26:23 <abadger1999> -1
17:26:36 * abadger1999 sorry didn't think we'd be continuing.
17:26:44 <spot> a -1?
17:26:55 <tibbs> Not worth documenting this?
17:27:02 <abadger1999> It's conceptually wrong at the packaging level.
17:27:12 <tibbs> That's not our decision; that's a maintainer decision.
17:27:16 <abadger1999> true.
17:27:34 <tibbs> Is our opinion of the dependency chain being asked for?
17:27:39 * rdieter wonders if abadger1999 has been possessed by ralf's ghost
17:27:44 <spot> i don't think so...
17:27:51 <tibbs> Or are we just voting on whether to mention this in the guidelines?
17:27:52 <limburgher> As the numpy maintainer, I'd rather have a subpackage for that function, but I don't see a way.
17:28:18 <ajax> i certainly agree that this is better fixed by fixing the pygtk2 API
17:28:18 <spot> or, have that function not use numpy. :)
17:28:20 <abadger1999> When we work around bugs in packaging, programs, rpm, we note that we're writing up a workaround.
17:28:33 <abadger1999> That needs to go in there.
17:28:37 <tibbs> I mean, I agree that it's conceptually wrong at the packaging level, but it's not conceptually wrong at the _distro_ level.
17:28:38 <limburgher> spot: right. :)
17:28:41 <ajax> and i'm happy to pursue that too
17:28:44 <abadger1999> <nod>
17:29:10 * abadger1999 apologizes again -- had to read what's being said as well.
17:29:30 <spot> if we add "NOTE: This is a temporary workaround which will be resolved in the future.", does that clarify things?
17:29:32 <abadger1999> the Guidelines are also not going to be a very good way to announce this.
17:29:51 <spot> abadger1999: no, i think ajax is simply going to refer to the guidelines when he announces it
17:30:03 <abadger1999> Better than nothing but even fedora-devel-announce that no one reads is better.
17:30:10 <limburgher> Plus, he's fixing the packages in question.
17:30:26 <abadger1999> limburgher: No, he's not.  pygtk2 is what needs to be fixed.
17:31:02 <abadger1999> limburgher: The things he's changing are workarounds in packaging (or in some cases making calling code not suck).
17:31:07 <spot> ajax: any chance of fixing pygtk2 to not use numpy for this function?
17:31:24 <limburgher> abadger1999: Will he be filing bugs, at least?
17:32:03 <abadger1999> I hope he'll be filing a bug upstream with pygtk2.  That's what I asked yesterday.
17:32:09 <spot> Well, as is, it does not pass.
17:32:13 <abadger1999> ajax: upstream bug filed?
17:32:25 <limburgher> I meant for the pacakges whose Requires would nee augmenting.
17:32:31 <limburgher> s/nee/need/
17:32:47 <ajax> abadger1999: not yet.  will do though.
17:33:13 <spot> #action PythonNumpy rejected
17:33:14 <abadger1999> cool.  I'll vote +1 with the workaround note and a link to the upstream pygtk2 bug/our tracking bug for it.
17:33:29 <spot> heh. the logs will look fun.
17:33:46 <abadger1999> silly automated meeting bot :-)
17:33:49 <spot> does the changes affect anyone elses votes?
17:34:33 * spot updated https://fedoraproject.org/wiki/PackagingDrafts/PythonNumpy
17:34:39 <rdieter> no, even better now
17:34:44 <tibbs> Still +1.
17:34:49 <spot> +1 from me
17:34:57 <limburgher> +1
17:35:02 <spot> okay.
17:35:16 <spot> #action PythonNumpy modified passes, goes to FESCo for ratification
17:35:32 <spot> okay, i think thats about it for this week
17:35:54 <spot> #info Our next meeting will be Wednesday, Aug 19, 2009 at 1600 UTC
17:36:07 <spot> thanks everyone
17:36:11 <abadger1999> Thanks spot
17:36:15 <limburgher> thx all
17:36:20 <tibbs> Maybe  I can get nirik to tweak the .nextfpcmeeting time.
17:36:27 <spot> #endmeeting