Meeting:Packaging IRC log 20060629

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