From Fedora Project Wiki
Jun 29 11:04:41 spot we're only missing Jesse and Michael now. i've left Jesse a message on ICQ, so lets get started
Jun 29 11:05:11 spot first order of business is how we are going to decide on things
Jun 29 11:05:31 spot imho, a majority vote seems to be the most obvious way
Jun 29 11:05:43 lutter yeah, sounds good to me
Jun 29 11:05:57 spot does anyone disagree with that?
Jun 29 11:06:03 thimm As long as we remain an odd number :)
Jun 29 11:06:20 tibbs That means six for votes to pass. Assuming we actually have eleven members.
Jun 29 11:06:21 lutter will we require majority of everybody or only of everybody in a meeting as long as there's a minimum number of people (say 6 or 7) ?
Jun 29 11:06:34 * scop is back
Jun 29 11:06:47 spot i think we have 10 members right now
Jun 29 11:06:55 spot since michael never replied and i know he's alive
Jun 29 11:07:02 racor I'd say absolute majority, i.e. at least 6 votes
Jun 29 11:07:12 spot at least 6 votes seems ok to me
Jun 29 11:07:23 scop ditto, no matter how many are present
Jun 29 11:07:34 abadger1999 Makes sense to me
Jun 29 11:07:35 spot thus, if less than 6 are present, we'll not be able to get much done. :)
Jun 29 11:07:43 racor right
Jun 29 11:07:55 abadger1999 Can we have votes on list as well as in IRC?
Jun 29 11:08:01 spot I don't see why not.
Jun 29 11:08:15 spot irc merely makes a discussion flow a little faster
Jun 29 11:08:20 tibbs Do we need a quorum rule?
Jun 29 11:08:31 racor can't that FESCO voting system be applied?
Jun 29 11:08:37 thimm Isn't that the quorum rule (6 persons)?
Jun 29 11:08:45 spot i think 6 people is the quorum rule
Jun 29 11:09:06 tibbs Sounds good to me.
Jun 29 11:09:09 lutter do we need to make things that formal ? I hope packaging topics won't be so controversial that we have to go through a big voting process
Jun 29 11:09:21 scop lutter++
Jun 29 11:09:21 spot lutter: packaging is controversy. :)
Jun 29 11:09:51 lutter (I meant using the FESCO system)
Jun 29 11:09:51 scop let's just try KISS now, formalize later if it doesn't Just Work
Jun 29 11:10:01 lutter sounds good to me
Jun 29 11:10:15 spot alright, so that is settled
Jun 29 11:10:20 thimm Let's stick with quorum of six as long as we are 10 members in total.
Jun 29 11:10:20 spot next item: meeting date/time
Jun 29 11:10:38 spot thimm: yep. if we gain/lose members, we'll revisit quorum
Jun 29 11:10:44 lutter how does this time work for everybody ?
Jun 29 11:10:46 tibbs This time is quite good for me.
Jun 29 11:10:55 scop works for me
Jun 29 11:11:01 thimm OK for me, too
Jun 29 11:11:02 spot this time is good for me as well, since i have the FESCO meeting right after it
Jun 29 11:11:08 racor Not bad, one hour earlier would be better.
Jun 29 11:11:37 jpo this time also works for me
Jun 29 11:12:04 abadger1999 This is good. One hour earlier puts me into my commute to work.
Jun 29 11:12:15 lutter racor: one earlier makes it kinda early for abadger1999 and me
Jun 29 11:12:41 spot alright, sounds like we're sticking with this day/time.
Jun 29 11:12:46 spot is weekly ok for everyone?
Jun 29 11:13:06 rdieter aok for me (sorry was awol there for a bit... back now)
Jun 29 11:13:11 abadger1999 fine here
Jun 29 11:13:15 thimm ok
Jun 29 11:13:18 jpo ok
Jun 29 11:13:19 lutter works
Jun 29 11:13:29 scop by default yes, but of course it should depend on open issues
Jun 29 11:13:31 tibbs Good for me. Hopefully we won't have too much to discuss once we work through what's currently on the list.
Jun 29 11:13:54 spot alright. lets get to the list then. i'm just going to go down from the top.
Jun 29 11:14:07 spot the list of todo items is here:
Jun 29 11:14:08 spot http://www.fedoraproject.org/wiki/Packaging/GuidelinesTodo
Jun 29 11:14:17 spot First item: libexecdir
Jun 29 11:14:31 spot is libexecdir in the FHS?
Jun 29 11:14:36 scop no
Jun 29 11:14:45 racor defect of the FHS
Jun 29 11:14:50 spot i would tend to agree
Jun 29 11:14:54 tibbs +1
Jun 29 11:14:55 thimm It was removed at some time
Jun 29 11:15:09 scop I think the issues are:
Jun 29 11:15:16 thimm We should try to reintroduce it upstream
Jun 29 11:15:19 scop wordsize of an invoking program should match the libexec one
Jun 29 11:15:47 scop and if %{_libdir}/NAME is used instead of libexec, noarch packages can't be noarch and call these executables
Jun 29 11:16:10 tibbs libexec should match bin, definitely.
Jun 29 11:16:19 spot tibbs: within a package, yes.
Jun 29 11:16:19 thimm +1
Jun 29 11:16:38 rdieter yup, +1
Jun 29 11:16:39 spot all of these seems to make sense to me
Jun 29 11:16:40 spot +1
Jun 29 11:16:42 abadger1999 +1
Jun 29 11:16:56 tibbs Does the second rule impact any currently existing packages?
Jun 29 11:17:10 scop what if let's say on x86_64 a 32-bit lib calls a libexec binary
Jun 29 11:17:13 thimm which is "the second rule"?
Jun 29 11:17:25 tibbs "and if %{_libdir}/NAME is used instead of libexec, noarch packages can't be noarch and call these executables"
Jun 29 11:17:32 spot 1. wordsize of an invoking program should match the libexec one
Jun 29 11:17:40 spot 2. if %{_libdir}/NAME is used instead of libexec, noarch packages can't be noarch and call these executables
Jun 29 11:18:09 thimm I think scop didn't meant 2. to be a rule
Jun 29 11:18:20 rdieter (not that comments about %{_libdir}/name really have anything to do with _libexecdir directly... (: )
Jun 29 11:18:21 thimm He was just giving an example of havoc :)
Jun 29 11:18:29 racor disagree with 1. libexec/* contains executables.
Jun 29 11:18:29 spot scop: i think we can only enforce bit size parity inside a package
Jun 29 11:18:49 rdieter racor: why?
Jun 29 11:18:58 scop yep, those were just random issues off the cuff, not meant as rules
Jun 29 11:19:25 spot well, lets make some rules then.
Jun 29 11:19:27 racor wordsizes don't matter on executables
Jun 29 11:19:28 scop spot, in that case, 2) wouldn't be an issue
Jun 29 11:19:37 * f13 (n=me@fedora/ender) has joined #fedora-packaging
Jun 29 11:20:07 f13 sorry, I'm on the phone a bit.
Jun 29 11:20:08 spot Rule 1: %{_libexecdir} is permitted for use by packages, even though it is not in the FHS
Jun 29 11:20:20 thimm f13=Jesse?
Jun 29 11:20:23 spot thimm: yep
Jun 29 11:20:30 f13 thimm: indeed.
Jun 29 11:20:33 scop s|%{_libexecdir}|/usr/libexec|
Jun 29 11:20:58 rdieter I suppose we could go with the ml suggestion, that %_libexecdir must contain only binaries that match those in %_bindir
Jun 29 11:21:08 spot is libexecdir ever not /usr/libexec ?
Jun 29 11:21:19 spot _libexecdir %{_exec_prefix}/libexec
Jun 29 11:21:19 f13 spot: I've never seen it that.
Jun 29 11:21:19 thimm scop: why not a macro?
Jun 29 11:21:32 scop we're not discussing a macro here
Jun 29 11:21:39 scop FHS doesn't have macros
Jun 29 11:22:07 rdieter afaik, by default, %_libexexdir expands to %_exec_prefix/libexec (ie, they end up being the same, unless packager overrides it)
Jun 29 11:22:10 scop %configure --libexecdir=%{_libdir}/%{name} ...
Jun 29 11:22:12 spot Rule 1: /usr/libexec (aka %{_libexecdir} in Fedora rpm) is permitted for use by packages, even though it is not in the FHS
Jun 29 11:22:15 thimm Well, we're extending the FHS to include /usr/libexec, but should use %{_libexec} in packages
Jun 29 11:22:17 f13 right, but we're discussing what makes sense for Fedora.
Jun 29 11:22:47 scop spot++
Jun 29 11:22:52 f13 I agree with spot.
Jun 29 11:23:05 * lutter nods
Jun 29 11:23:20 spot everyone chime in on that one so we can move on?
Jun 29 11:23:21 scop by the way, packaging guidelines doesn't really mention FHS much at all
Jun 29 11:23:28 scop +1
Jun 29 11:23:29 abadger1999 Good rule: +1
Jun 29 11:23:29 tibbs +1
Jun 29 11:23:31 thimm +1
Jun 29 11:23:32 jpo +1
Jun 29 11:23:32 rdieter +1
Jun 29 11:23:42 spot ok, thats 6.
Jun 29 11:24:13 thimm BTW since FHS doesn't give rationale for libexec the guideline should mention a small definition
Jun 29 11:24:13 scop spot, if you add that to guidelines, could you add a small blurb about following the FHS in general?
Jun 29 11:24:44 spot i think it is worth adding some text above following the FHS and have this as the exception
Jun 29 11:24:46 racor IIRC, libexecdir is defined by the GCS
Jun 29 11:24:58 abadger1999 Yes, it is in there.
Jun 29 11:25:07 spot racor: we're already violating the GCS in a few places
Jun 29 11:25:22 tibbs Glasgow Coma Scale?
Jun 29 11:25:26 spot and i really dont want to step in the middle of that flamewar
Jun 29 11:25:32 racor GNU Coding Standards
Jun 29 11:25:33 spot Gnu Coding Standards
Jun 29 11:25:51 spot ok, do we want to add any other rules around libexecdir?
Jun 29 11:25:52 scop GCS on libexecdir: http://www.gnu.org/prep/standards/html_node/Directory-Variables.html#Directory-Variables
Jun 29 11:26:16 lutter right .. the thing I was supposed to print out and burn ;)
Jun 29 11:26:32 spot libexecdir, going once, going twice...
Jun 29 11:26:43 spot ok. mono.
Jun 29 11:26:47 f13 who can we get to fix up rpmlint to accept libexec?
Jun 29 11:26:51 scop hold on just a sec
Jun 29 11:26:55 scop f13 I can and will
Jun 29 11:26:56 spot scop: hmm?
Jun 29 11:27:08 scop do we want to say something about subdirs in libexec or not?
Jun 29 11:27:22 thimm Let this be a packager's choice
Jun 29 11:27:25 scop GCS says add subdirs, but peeking into my /usr/libexec says otherwise
Jun 29 11:27:36 spot i think this is ok for "up to packager"
Jun 29 11:27:43 scop works for me
Jun 29 11:27:45 rdieter I suppose we could "recommend" use of subdirs.
Jun 29 11:27:51 rdieter it'll be cleaner
Jun 29 11:27:59 spot i'm also not opposed to recommending subdirs
Jun 29 11:28:04 scop +1
Jun 29 11:28:17 abadger1999 Recommends +1
Jun 29 11:28:18 f13 +1
Jun 29 11:28:20 thimm I'd recommend: If upstream already used libexecdir, follow upstream, otherwise recommend subdirs
Jun 29 11:28:22 jpo subdirs++
Jun 29 11:28:26 rdieter +1
Jun 29 11:28:36 spot ok, thats 6
Jun 29 11:28:42 spot any other libexecdir?
Jun 29 11:28:49 f13 thimm: that falls under 'packager preference'
Jun 29 11:29:04 spot i'll write up the libexecdir stuff and add it today
Jun 29 11:29:14 f13 YaY Progress
Jun 29 11:29:17 spot mono:
Jun 29 11:29:42 spot there seem to be three open mono issues
Jun 29 11:29:49 spot 1. Redefining libdir for mono packages
Jun 29 11:29:59 thimm Sorry, just a last thing about libexec: anyone going to try to fix next FHS?
Jun 29 11:30:14 spot thimm: want to take it to the FHS on our behalf?
Jun 29 11:30:26 scop anyone know why/when it was dropped?
Jun 29 11:30:34 spot i can also try to get red hat to drive it forward via LSB
Jun 29 11:30:41 thimm OK, will try. And will also find out why dropped and report
Jun 29 11:30:44 abadger1999 scop: It never made it into a final (was only in a draft)
Jun 29 11:30:53 spot thimm: thanks
Jun 29 11:30:54 scop all I can find is some bitter statements about the reasons being political rather than technical
Jun 29 11:31:03 spot ok, lets move on to mono
Jun 29 11:31:17 f13 spot: do we have to? (;
Jun 29 11:31:19 spot most of the mono issues focus on one big question:
Jun 29 11:31:21 * scop is more or less clueless about mono stuff
Jun 29 11:31:26 spot Are mono DLLs arch independent?
Jun 29 11:31:45 spot i think the end result answer is "yes"
Jun 29 11:32:02 thimm Any mono expert around?
Jun 29 11:32:27 abadger1999 thimm: We'd have to subpoena someone :-)
Jun 29 11:32:36 thimm If it's arch independent, what is it doing in %{_libdir}, and not in %{_datadir}?
Jun 29 11:32:47 tibbs That's the question, isn't it?
Jun 29 11:32:47 rdieter from my reading of the summary, it appears most folks see the the .so's as arch independant
Jun 29 11:32:51 abadger1999 spot: My latest research supports that except for Ahead of time compilation limitations
Jun 29 11:33:07 rdieter but... the ahead-of-time compiling makes arch-dependant bits, which by default, end up in the same dir
Jun 29 11:33:08 abadger1999 .so's != arch independent -- .dlls == arch indep.
Jun 29 11:33:27 rdieter oops, I had it backward, abadger1999 is right.
Jun 29 11:33:28 lutter so .dll's are like .jars ?
Jun 29 11:33:29 spot and since a lot of the mono apps need the files in the same directory.
Jun 29 11:33:43 tibbs lutter: That seems to be the best meme.
Jun 29 11:33:49 rdieter I'd say that until .dlls and .so's can be separated, use %_libdir
Jun 29 11:34:10 spot i think as much as it is icky, we do need to use %{_libdir}
Jun 29 11:34:27 abadger1999 mono itself needs the ahead of time compiled files in the same dir if it is to find and use them.
Jun 29 11:34:30 f13 I can accept that as a failing of mono.
Jun 29 11:34:45 abadger1999 spot: I tnd to agree with sentiment and placement.
Jun 29 11:34:48 spot OK, so how about this as a rule:
Jun 29 11:34:51 scop do these paths propagate into other mono things (executables, config files)?
Jun 29 11:34:51 tibbs I think we may have to just accept it.
Jun 29 11:34:51 abadger1999 s/tnd/tend/
Jun 29 11:34:56 spot mono apps without .so files should be noarch
Jun 29 11:35:18 abadger1999 scop: They definitely go into pkgconfig files.
Jun 29 11:35:28 spot all mono apps should use %{_libdir}, without redefining it
Jun 29 11:35:40 f13 how is this different from python files that get .pyc? are not .pyc arch dependent?
Jun 29 11:35:53 scop no, .pyc and .pyo are noarch
Jun 29 11:36:01 scop abadger1999, that's ok
Jun 29 11:36:06 f13 ah ok.
Jun 29 11:36:29 lutter I don't see how mono can use %{_libdir} and build noarch packages; %{_libdir} is arch dependent
Jun 29 11:36:31 scop just thinking about real %config files, that could cause some pain if the dirs change afterwards
Jun 29 11:36:40 spot lutter: _libdir on noarch is /usr/lib
Jun 29 11:37:02 lutter spot: oops .. thanks
Jun 29 11:37:13 abadger1999 spot: Err... Then what happens to ahead of time (aot) compiled files?
Jun 29 11:37:20 tibbs I think we need to pick apart a couple of real Mono packages. Otherwise I simply have no idea what it really wants to put where.
Jun 29 11:37:23 rdieter lutter: mono apps that use %_libdir then ought not be .noarch.
Jun 29 11:37:26 spot abadger1999: i've not see an aot file without .so files
Jun 29 11:37:34 thimm # uname -m; find /usr/lib/mono/ -name \*.dll \! -type l | xargs file|awk -F: '{print $2}' | sed -e's, *, ,g' | sort | uniq -c | sort -n
Jun 29 11:37:34 thimm x86_64
Jun 29 11:37:34 thimm 174 MS-DOS executable PE for MS Windows (DLL) (console) Intel 80386 32-bit
Jun 29 11:37:47 thimm does that make sense???
Jun 29 11:37:47 spot thimm: file is lying there, it doesn't know any better
Jun 29 11:37:53 thimm ok
Jun 29 11:37:59 abadger1999 spot: Yes. But the aot's can be generated by the system administrator.
Jun 29 11:38:16 thimm Are aots part of the dlls?
Jun 29 11:38:30 thimm Or part of the so?
Jun 29 11:38:31 abadger1999 No -- aot's get created as .so's by mono.
Jun 29 11:38:32 tibbs abadger1999: Really? Should the package %ghost them?
Jun 29 11:38:36 lutter are we sure that aot's and dll's never get mixed in the same package ?
Jun 29 11:38:45 abadger1999 tibbs... Hmm.. I'd say yes.
Jun 29 11:38:50 thimm So then, dlls era indeed noarch
Jun 29 11:38:56 thimm s/era/are/
Jun 29 11:39:16 abadger1999 lutter: they can be created by the packager.
Jun 29 11:39:19 spot so, with ghosted .so files, we're ok to be noarch
Jun 29 11:39:30 spot if they're actually present, then we're not noarch
Jun 29 11:39:36 abadger1999 lutter: I don't think they're created by default in most packages
Jun 29 11:39:41 tibbs DLLs are noarch but something may come through and create AOTs which have to be in the same place and are NOT noarch.
Jun 29 11:39:45 tibbs Is that accurabe?
Jun 29 11:39:46 * scop is confused
Jun 29 11:39:55 abadger1999 tibbs: Yes. accurate.
Jun 29 11:40:08 f13 ugh, thats still gross.
Jun 29 11:40:10 abadger1999 too me it's a tool problem.
Jun 29 11:40:11 spot can we force all .so to be ghosted? will they be created later?
Jun 29 11:40:23 tibbs So unless we symlink or forbid AOTs, DLLs cannot be in /usr/share.
Jun 29 11:40:26 spot perhaps run mono in %post to create them?
Jun 29 11:40:42 scop but they can't be in _datadir
Jun 29 11:40:42 thimm What happens with aots when on y86_64 you call a mono bin with setarch i386?
Jun 29 11:40:45 abadger1999 mono will not search for AOTs in other places so they can't be separated.
Jun 29 11:40:50 thimm Will it suddenly create aots for 32 bits?
Jun 29 11:41:07 spot thimm: i don't know.
Jun 29 11:41:16 rdieter yucky alright.
Jun 29 11:41:17 tibbs Mono can be made to do anything if someone's willing to hack it.
Jun 29 11:41:33 spot tibbs: upstream isn't willing to take those patches as far as i can see
Jun 29 11:41:36 thimm Maybe aots need to go to /var?
Jun 29 11:41:46 thimm We want /usr to be stateless
Jun 29 11:41:57 tibbs thimm: They MUST be in the same directory according to upstream.
Jun 29 11:41:58 lutter I thought .dll and aot's need to be in the same dir ?
Jun 29 11:42:02 spot thimm: doesn't python screw with that? :)
Jun 29 11:42:12 thimm I thought "Mono can be made to do anything" :)
Jun 29 11:42:29 tibbs And if upstream won't take patches then either Red Hat deviates or we just punt.
Jun 29 11:42:41 thimm Yes, python would also violate that
Jun 29 11:42:44 rdieter by punt, meaning just use %_libdir?
Jun 29 11:42:46 lutter the requirement that .dll and aot's need to be in the same dir mean that ther can't be noarch mono packages
Jun 29 11:43:08 rdieter right. not .noarch and use %_libdir (afaik)
Jun 29 11:43:13 spot lutter: there are some mono apps that don't use aot .so files
Jun 29 11:43:22 spot or don't package them
Jun 29 11:43:26 f13 I'm seeing a rule htere.
Jun 29 11:43:32 lutter but if they depend on packages that do, they won't work
Jun 29 11:43:33 abadger1999 spot: Actually no mono package has to use aot iles.
Jun 29 11:43:47 spot thus, if your package has no .so files, its _libdir and noarch
Jun 29 11:43:47 abadger1999 spot: The .so's that we are seeing in packages are mostly glue libraries.
Jun 29 11:43:51 f13 1) If your mono package creates AOT .sos from .dll files, your package cannot be noarch and you must use %{_libdir} for dlls
Jun 29 11:44:07 abadger1999 Between .dlls and system libraries written in C.
Jun 29 11:44:12 f13 2) If your mono package does NOT create AOT .sos, your package _can_ be noarch and should use datadir
Jun 29 11:44:26 abadger1999 AOT libraries are separate rom those.
Jun 29 11:44:32 abadger1999 s/rom/from/
Jun 29 11:44:37 scop can the packager always control whether *.so are created or not?
Jun 29 11:44:55 scop (think eg. *.pyc, *.pyo)
Jun 29 11:45:17 spot we're running out of time here... who wants to dig into this issue some more?
Jun 29 11:45:31 abadger1999 scop: The packager can control whether AOT's are controlled during the build. Glue libraries have to be built. And the sys admin can choose to build A$
Jun 29 11:45:42 scop ok
Jun 29 11:45:54 spot abadger1999: can you write up a recommendation for next week?
Jun 29 11:45:59 thimm Should we ask alexl@redhat.com (mono packager)?
Jun 29 11:46:13 f13 i thin kthis needs more discussion on list before a proposal can be made.
Jun 29 11:46:16 spot thimm: i did, he doesn't want to get in it because hes not going to own mono much longer
Jun 29 11:46:28 abadger1999 I have two recommendations: Either we make them arch specific OR we pretend AOTs don't exist.
Jun 29 11:46:45 scop but no matter how the AOTs (== *.so???) are built, during package build or afterwards, they must not end up in _datadir if they're arch dependent
Jun 29 11:46:48 spot if they're arch specific, they all use %{_libdir}
Jun 29 11:46:59 thimm If we force them to be arch specific we are at least on the safe side ... :/
Jun 29 11:47:06 thimm Until we know better
Jun 29 11:47:08 abadger1999 What are the questions about AOTs/DLLs? I'll write a summary with answers.
Jun 29 11:47:10 abadger1999 To the list.
Jun 29 11:47:31 f13 abadger1999: are AOTs always created from DLLs at mono runtime?
Jun 29 11:47:38 f13 (if they don't exist already)
Jun 29 11:47:57 abadger1999 f13: No.
Jun 29 11:48:17 abadger1999 f13: it has to be a conscious choice to compile them from the DLLs
Jun 29 11:48:24 spot ok, before we leave mono behind, should we just hold our nose and say "arch specific, use libdir"
Jun 29 11:48:32 abadger1999 +1
Jun 29 11:48:35 lutter +1
Jun 29 11:48:37 scop +1
Jun 29 11:48:37 abadger1999 :-)
Jun 29 11:48:38 thimm +1
Jun 29 11:48:39 f13 spot: I'm seeing that it could go either way.
Jun 29 11:48:43 spot +1
Jun 29 11:48:45 f13 but sure, why not, thats the easy answer.
Jun 29 11:48:53 rdieter +1
Jun 29 11:48:57 spot ok, thats 6.
Jun 29 11:49:04 tibbs +1
Jun 29 11:49:07 racor 0
Jun 29 11:49:14 spot lets just not smell the pile here and shove it aside. windows crap.
Jun 29 11:49:16 abadger1999 One thing about that -- will Core mono packages change directories as well?
Jun 29 11:49:24 * scop giggles
Jun 29 11:49:34 spot there are two items i want to get done today
Jun 29 11:49:36 f13 abadger1999: they should ues.
Jun 29 11:49:38 spot ruby
Jun 29 11:49:47 abadger1999 Core mono currently uses /usr/lib/mono rather than %{_libdir}
Jun 29 11:49:54 tibbs Ruby should be done now.
Jun 29 11:50:08 spot %{_libdir}/%{name} is ok
Jun 29 11:50:10 f13 abadger1999: bugs are good, once we write up the rule.
Jun 29 11:50:17 abadger1999 f13: Sounds god.
Jun 29 11:50:25 spot i meant _libdir vs _datadir
Jun 29 11:51:03 spot i think the ruby guidelines at http://www.fedoraproject.org/wiki/Packaging/Ruby are fine
Jun 29 11:51:11 rdieter +1
Jun 29 11:51:20 tibbs +1
Jun 29 11:51:21 * f13 knows not ruby, but if its working currently, might as well add them
Jun 29 11:51:28 f13 I have a question about this though.
Jun 29 11:51:31 rdieter It's certainly a very good start, much better than what we have now (nothing).
Jun 29 11:51:49 spot we can always make changes later
Jun 29 11:51:53 tibbs f13?
Jun 29 11:52:05 f13 when we accept one of these sub things as policy, do we move it under the umbrella of the read-only packaging stuff so that random users can't make a change to it?
Jun 29 11:52:23 spot yeah. Packaging/ is protected for change only by us
Jun 29 11:52:23 tibbs Currently all of Packaging is read-only except for us.
Jun 29 11:52:38 f13 should we have a PackagingProposal/Foo to get it worked on, and then moved under Packaging/ later ?
Jun 29 11:52:48 f13 tibbs: not ScriptletSnippits (:
Jun 29 11:52:49 spot +1 to f13's proposal
Jun 29 11:53:03 scop could someone who knows the current status of ruby packaging well submit a patch for the ruby spec template in fedora-rpmdevtools?
Jun 29 11:53:12 tibbs That's "Drafts Hierarchy" on the schedule.
Jun 29 11:53:12 spot lutter: that would be you. :)
Jun 29 11:53:17 lutter scop: I will do that as soon as the guidelines are approved
Jun 29 11:53:21 f13 tibbs: oh ok, sorry (:
Jun 29 11:53:22 scop lutter, tia
Jun 29 11:53:26 spot ok folks, vote on the ruby guidelines
Jun 29 11:53:32 spot we still need a few more +s there. ;)
Jun 29 11:53:33 abadger1999 tibbs, lutter: So ruby requires ruby and ruby-libs?
Jun 29 11:53:35 f13 +1 if its currently working.
Jun 29 11:53:37 rdieter +1
Jun 29 11:53:43 tibbs +1 for Ruby.
Jun 29 11:53:44 lutter abadger1999: yes
Jun 29 11:53:47 thimm 0
Jun 29 11:53:52 lutter +1
Jun 29 11:53:55 scop +0
Jun 29 11:54:01 spot with my +1, thats 5...
Jun 29 11:54:01 racor 0
Jun 29 11:54:05 jpo 0
Jun 29 11:54:21 tibbs abadger1999: ruby requires ruby-libs
Jun 29 11:54:30 thimm One is missing, we have 9 votes
Jun 29 11:54:43 abadger1999 Right.. So why do we say require both ruby and ruby(abi) which is in ruby-libs?
Jun 29 11:54:53 abadger1999 Why not just ruby(abi)?
Jun 29 11:54:57 tibbs Note that the Ruby guidelines were developed in concert with Red Hat's Ruby maintainer, who made many changes to accommodate us.
Jun 29 11:55:01 spot ruby(abi) should be sufficient
Jun 29 11:55:10 lutter lemme check
Jun 29 11:55:24 rdieter ruby(abi)++
Jun 29 11:55:26 tibbs You're right; I thought the statement about requiring Ruby had gone.
Jun 29 11:55:39 spot lutter: nuke that first line then
Jun 29 11:55:44 tibbs It was needed before the core Ruby package had included the ABI provide.
Jun 29 11:55:51 abadger1999 Okay.
Jun 29 11:55:53 abadger1999 +1
Jun 29 11:55:58 lutter if you have any scripts in the package that want to run /usr/bin/ruby, youy need ruby
Jun 29 11:56:00 thimm That's 6
Jun 29 11:56:05 spot ok, ruby is approved.
Jun 29 11:56:08 spot lutter: make it go
Jun 29 11:56:17 lutter spot: will do
Jun 29 11:56:20 spot last ASAP item: php
Jun 29 11:56:38 spot http://www.fedoraproject.org/wiki/Packaging/PHP
Jun 29 11:57:12 tibbs Did we hear back fro Joe Orton about the proposed core package changes?
Jun 29 11:57:26 spot i didn't.
Jun 29 11:57:45 spot tibbs: can you take this as your action item?
Jun 29 11:57:51 spot i'll try to get Joe's attention on this
Jun 29 11:58:17 tibbs Sorry, take what? Hammering on the PHP guidelines more?
Jun 29 11:58:20 spot tibbs: yes
Jun 29 11:58:26 spot resolving the open issues
Jun 29 11:58:30 rdieter Packaging/PHP look like a good start to me... might as well "bless" it. +1
Jun 29 11:58:47 tibbs We have many unanswered questions there.
Jun 29 11:58:52 thimm php- prefix in php-pear-... and php-pecl-... seems superfluous
Jun 29 11:59:07 spot thimm: yeah, but it helps end-users
Jun 29 11:59:20 tibbs Note also that people are currently submitting and aproving PHP packages.
Jun 29 11:59:34 tibbs Should we declare a moratorium on PHP package approvals?
Jun 29 11:59:35 spot tibbs: do they meet these guidelines?
Jun 29 11:59:48 tibbs Yes, they are meeting the draft guidelines as far as I can tell.
Jun 29 12:00:19 scop then proceed and improve them as the guidelines improve?
Jun 29 12:00:21 spot should we approve the draft guidelines, with the notes that issues remain to be resolved?
Jun 29 12:00:31 spot and resolve the issues as quickly as possible? :)
Jun 29 12:00:41 tibbs Really the guidelines are good, but no php(abi) provide from the core PHP package, and
Jun 29 12:01:04 tibbs no module-compat thing.
Jun 29 12:01:24 thimm Can't php be rebuilt with these Provides:?
Jun 29 12:01:34 tibbs Until we get that, requiring the base PHP version works as well as it can.
Jun 29 12:01:34 rdieter imo, we should either 'halt php package approvals' or 'bless guidelines'
Jun 29 12:01:41 spot i vote we move the open issue to the bottom and approve the php guidelines.
Jun 29 12:01:53 tibbs thimm: That's what we're trying to talk to Joe Orton about; he maintains core PHP.
Jun 29 12:02:02 tibbs Seconded.
Jun 29 12:02:04 spot tibbs and i will work on getting joe to add the abi bits to php
Jun 29 12:02:31 f13 +1
Jun 29 12:02:33 tibbs spot: Agreed.
Jun 29 12:02:39 tibbs +1 for PHP guidelines as is.
Jun 29 12:02:41 spot +1
Jun 29 12:02:43 rdieter +1
Jun 29 12:02:46 abadger1999 +1
Jun 29 12:03:09 spot thats 5...
Jun 29 12:03:10 lutter 0
Jun 29 12:03:17 thimm 0
Jun 29 12:03:27 scop 0
Jun 29 12:03:37 racor 0, don't see no need to vote, let things evolve.
Jun 29 12:03:44 spot ok, its tabled.
Jun 29 12:03:51 spot put it back on the agenda for next week
Jun 29 12:03:57 tibbs So moratorium on PHP approvals?
Jun 29 12:04:03 spot tibbs: yep.
Jun 29 12:04:20 spot tibbs: can you email fedora-extras & maintainers?
Jun 29 12:04:20 tibbs OK, I'll try to keep up with bugzilla to make sure everyone holds off.
Jun 29 12:04:28 tibbs Yes.
Jun 29 12:04:37 spot alright. thats all the time we've got for this week.
Jun 29 12:04:49 spot i'll post the logs on the mailing list.
Jun 29 12:04:53 spot thanks for the time guys.
Jun 29 12:05:41 scop thanks
Jun 29 12:05:52 lutter cool .. thanks
Jun 29 12:06:58 * spot has changed the topic to: Channel for Fedora packaging related discussion | Next Meeting: Thursday, July 6th, 2006 16:00 UTC