Meeting:Packaging IRC log 20060817

(08:54:21) ***f13 runs to nuke lunch
(08:54:44) f13: oh, while I'm gone, does anybody object to moving this meeting one hour earlier or later?
(08:54:54) thimm: later = fesco
(08:55:10) tibbs: And later than that gets into the infrastructure meeting.
(08:55:24) spot: and earlier tends to screw up the west coasters.
(08:55:34) tibbs: I think there is an hour in there somewhere, though.
(08:55:54) thimm: maybe on another day?
(08:55:59) thimm: with more time slots free?
(08:56:22) tibbs: I have no particular attachment to this day.
(08:56:54) tibbs: I would also have no objection to switching between a couple of different times.
(08:59:10) f13: hrm,
(08:59:30) f13: is the FESCO meeting based on UTC or is it based on a timezone that has daylight savings time
(08:59:48) f13: because ours is based on UTC, so if FESCO moves w/ DST and we don't, we'll end up overlaping
(09:00:19) thimm: we'll go with daylight I guess
(09:00:26) tibbs: I imagine the UTC hour would change with the DST stupidity, but not everyone switches at the same time.
(09:00:30) f13: An hour later on Tuesday or Wed would work for me.
(09:01:06) thimm: OK, let's vote
(09:01:11) thimm: Tue +1 We +1
(09:01:22) tibbs: Not nearly enough folks here for voting.
(09:01:24) f13: heh, do we have enough interested parties here?
(09:01:50) tibbs: Especially changing the meeting time should really involve everyone.
(09:02:18) spot: we have 6 people here by my count
(09:02:20) f13: yeah.
(09:02:23) abadger1999: Hmm... Last week fesco asked if we could change the meeting date.
(09:02:26) f13: might want to kick it to mailing list just for some discussion.
(09:02:34) tibbs: Some wiki wiz should set up a table and folks can block out the times that work for them.
(09:02:36) f13: abadger1999: oh?  just to not conflict?
(09:02:45) abadger1999: So that they could get the packaging report via email.
(09:02:52) f13: sounds like tibbs just volunteered (:
(09:03:03) abadger1999: and then just discuss anything they considered controversial.
(09:03:10) tibbs: Note that I said "wiki wiz" which pretty much excludes me.
(09:03:34) f13: abadger1999: heh, its packaging policies.  Pretty much everyting is controversial to somebody (:
(09:03:38) tibbs: Actually the wording was specifically crafted to exclude me.
(09:03:46) tibbs: But I'll start something.
(09:03:49) spot: i don't think we should change the meeting date/time without everyone being present/involved
(09:04:01) f13: me either, which is why email would be better for this.
(09:04:14) tibbs: List discussion with a wiki summary page seems reasonable.
(09:04:18) lutter: sorry for being late
(09:04:36) lutter: I am perfectluy fine with moving it to anotehr day .. an hour earlier would be less than ideal
(09:04:49) f13: lutter: how do you feel about an hour later?
(09:04:52) spot: let's discuss this on the list and get started with the meeting. :)
(09:04:58) f13: spot: WORKSFORME
(09:04:58) lutter: f13: later is always better
(09:05:43) spot: ok, lets start with some of my outstanding items
(09:05:46) f13: spot: whats on the block today Mr Chair?
(09:05:52) spot: - Group setting
(09:06:27) spot: After much research on how we should best use Group, I've come to the conclusion that it is a worthless tag. A relic, even.
(09:06:37) f13: agreed
(09:06:48) spot: I have a one line patch for rpm that makes Group non-mandatory for packages
(09:06:50) tibbs: definitely
(09:07:00) f13: spot: oooh, I like where this is going.
(09:07:14) tibbs: Any chance at all of that patch actually getting in anywhere?
(09:07:16) abadger1999: synaptic still uses it, though....
(09:07:26) thimm: smart, too
(09:07:30) spot: I say that we just let people put whatever they think is valid in the Group tag for now, and by FC-7 (unless we can slip it in FC-6), we don't require it
(09:07:58) f13: smart and synaptic could easily be fixed.
(09:08:10) thimm: By whom?
(09:08:18) thimm: Upstream will point to rpm upstream
(09:08:19) f13: thimm: whoever cares about that software.
(09:08:31) thimm: Will this be patched in rpm upstream?
(09:08:46) f13: thimm: that gets to be a really interesting question really soon now.
(09:08:49) spot: thimm: unknown. i have little time or patience for dealing with the mentally handicapped.
(09:08:58) lutter: since we do compx files now, how about just sticking the name of the comps group into it ?
(09:09:07) f13: spot: should the 'whatever they think' still be one of the official "Groups" provided by the RPM package?
(09:09:22) thimm: OK, I understand that rpm is shortly before a fork
(09:09:24) spot: lutter: i looked into that, but the problem is that the comps mappings can be multiple
(09:09:32) spot: e.g. a package can be in multiple comps groups
(09:09:51) lutter: spot: then the packager should pick whatever they think is the 'primary' group
(09:10:01) spot: lutter: its non-obvious
(09:10:09) spot: some packages are in 5+ groups
(09:10:15) abadger1999: spot: jeremy said that was to be avoided behaviour though.
(09:10:21) abadger1999: because it confuses end users
(09:10:21) f13: yeah, I'm more in favor of ripping Group out since it won't be used by anything.
(09:10:24) thimm: Extend group tag to a list?
(09:10:40) spot: abadger1999: yes, but at the same time, he doesn't think Group should be used for Comps fields
(09:11:06) spot: the one line patch just makes Group non-mandatory
(09:11:17) spot: doesn't remove it altogether
(09:11:27) lutter: ok .. let's just nuke it then. It's probably the least informative field in the header, and has been for a long time
(09:11:42) lutter: (nuke == what spot said)
(09:11:45) f13: spot: sure, but if it isn't used by our supported methods of package presentation, why include it?  ITs just going to be a ever confusing point.
(09:11:52) abadger1999: I like phasing out the Group tag.  But we need to give depsolver authors a chance to figure out what they want to do.
(09:12:02) spot: f13: because its much more intrusive and sudden of a change?
(09:12:04) abadger1999: (Move to comps, no longer support at all, etc)
(09:12:25) f13: spot: make change soon, by FC7 Group not allowed in new packages?
(09:12:28) spot: Both anaconda and yum seem to be using comps for grouping
(09:12:38) f13: spot: by FC8 all packages no group.
(09:12:51) spot: f13: this is pretty much my proposal
(09:13:06) f13: spot: ok.  Note 'no group in new packages' though (:
(09:13:15) f13: different from 'group optional'
(09:13:26) spot: I know.
(09:14:02) thimm: Should we vote?
(09:14:04) spot: So, lets vote on this proposal
(09:14:07) abadger1999: I'd like Group to remain in the guidelines for FC6.
(09:14:13) f13: abadger1999: sure.
(09:14:18) abadger1999: but rpm to be patched.
(09:14:22) tibbs: Folks who want to maintain packages across RHEL and such will still need Group for a long time.
(09:14:41) f13: IF patch gets accepted somewhere, before FC7, then by FC7 New packages must not include Group in spec.
(09:14:46) spot: it may be too late for FC-6 to take the patch, pnasrat was waiting on this vote.
(09:15:05) f13: spot: does my proposal sound fair?
(09:15:13) f13: er line up with what you proposed?
(09:15:25) spot: +1 to f13's proposal
(09:15:30) f13: +1
(09:15:54) lutter: +1
(09:15:59) thimm: -1 (due to tibbs' RHEL remark)
(09:16:16) abadger1999: Is the RHEL ramification that packagers would have to maintain 2 spec files?
(09:16:22) tibbs: Is this "group optional" or "group not allowed"?
(09:16:40) thimm: 'must not include Group in spec.'
(09:16:44) spot: group optional in FC-6, FC-7, not allowed in FC-8
(09:16:50) tibbs: Note that I don't care about RHEL personally, but it always gets brought up as a reason why we can't change things.
(09:17:02) lutter: f13: I was assuming that RHEL would just follow Fedora here .. is that reasonable ?
(09:17:12) thimm: Not for existing RHEL
(09:17:22) f13: lutter: for the most part.  RHEL5 isn't going to be pulling in packages from dist-fc7 so we really don't care there.
(09:17:37) thimm: There is a Fedora goes RHEL initiative
(09:17:46) thimm: Fedora Extras goes RHEL
(09:17:54) f13: thimm: thats goign nowhere in a hurry
(09:17:59) lutter: f13: what about getting the patch that makes group optional into RHEL5 by FC7 time ?
(09:18:20) f13: lutter: up to nasrat, and how he sneaks it in or words the request.
(09:18:30) f13: as it's semi-featury and we're past feature freeze for the most part.
(09:19:13) rdieter: apologies, I was pulled afk, I'm back.
(09:19:30) lutter: I wouldn't want a lot of RHEL vs. Fedora headaches for people because of Group
(09:19:47) spot: yeah. what about if we simply start off by making Group optional
(09:19:56) spot: and we propose to revisit it in the future?
(09:19:58) tibbs: I'm definitely positive for "group optional" as soon as it can get in.
(09:20:06) tibbs: That is imminently reasonable.
(09:20:07) thimm: I'd vote for that, yes
(09:20:14) lutter: and only require no group if that jives with RHEL
(09:20:29) spot: +1 to that
(09:20:33) thimm: +1
(09:20:34) tibbs: I'd even be happy with "group discouraged".
(09:20:54) thimm: no, not until RHEL is solved, please
(09:21:18) f13: if it's optional, do we still want to care whats in the field?
(09:21:30) spot: f13: imho, no.
(09:21:39) thimm: BTW there are two optional:
(09:21:39) abadger1999: +1
(09:21:42) tibbs: It should still make sense, though.
(09:21:44) lutter: something halfway reasonable, i.e. don't say 'Development/Tools' for a game
(09:21:52) thimm: a) in the guidelines, b) in rpm binary
(09:22:04) f13: thimm: we're not going to be able to keep Fedora compatible with RHEL forever.  New macros will appear (already have), etc..  trying to pin down Fedora and policy development because of rhel is a bad thing.
(09:22:26) tibbs: f13: I definitely agree.
(09:22:28) thimm: Agreed, but doubling all of FE for RHEL Extras is even worse
(09:22:37) f13: why would you double it all?
(09:22:39) spot: how about we suggest that packagers use the Groups list already documented in the guidelines where applicable
(09:22:48) thimm: Becasue you would need a specfile w/o and w/o Group
(09:22:49) spot: but no enforcement is necessary
(09:22:51) f13: we're proposing no group in NEW packages.  THat limits the number.
(09:23:06) f13: thimm: you're already going to have to double anything that uses a newer macro
(09:23:14) tibbs: Extras packagers didn't sign up for making things compatible with RHEL.
(09:23:17) thimm: No, you can always coinstall macros
(09:23:29) f13: and if you're packaging for RHEL, RHEL isn't going to want new versions all the time, thats WHY they bought rhel.
(09:23:34) tibbs: If someone wants to take those packages and make them work with RHEL, that's their business.
(09:23:41) f13: so lets stop shooting ourselves in the foot over hyperbole
(09:23:49) thimm: No hyperbole
(09:23:52) spot: Right now, we just need consensus to get this "optional" patch into rpm
(09:23:55) thimm: ATrpms has a very healthy RHEL clientel
(09:24:04) thimm: And it would be nice for FE to do the same
(09:24:04) spot: Paul has said that he's not interested until we agree on that much.
(09:24:07) thimm: Why block it?
(09:24:13) f13: thimm: thats great.  ATrpms isn't Fedora nor is it Fedora Extras.
(09:24:20) thimm: So?
(09:24:24) spot: whoa. everyone calm down.
(09:24:28) spot: take a deep breath.
(09:24:30) thimm: I'm just giving an example that RHEL users would like FE.
(09:24:47) f13: Fedora and RHEL have very different goals.  Shoehorning one into the other is not going to work well for either.
(09:24:52) spot: lets focus on what we can agree on in the here and now
(09:25:07) spot: does anyone here think that we should not have Group: optional by FC-7?
(09:25:18) abadger1999: Group optional +1
(09:25:21) thimm: optional has two meanings: guidelines and rpm
(09:25:26) spot: thimm: in both.
(09:25:27) abadger1999: Both
(09:25:30) f13: Group optional +1
(09:25:33) thimm: -1
(09:25:34) tibbs: Group optional in RPM +1, optional in guidelines +1.
(09:26:07) spot: thimm: ok, i'll bite. why are you opposed?
(09:26:21) thimm: There is a FE->RHEL project on 101
(09:26:29) rdieter: maybe I'm slow, but *why* exactly are we considering dropping(*) Group? (*) or make optional
(09:26:32) thimm: I'm part of it and fesco id on the list, too
(09:26:49) f13: thimm: 108 you mean, and thats Karsten Wade's pet idea that he has done nothing on to speak of (according to him)
(09:26:56) thimm: I'd like to be able to take FE somehwere between FE6->FE7 and rebuild for RHEL
(09:27:11) f13: rdieter: confusing, not used by any supported depsolver or package presenter, conflicts with Comps, etc...
(09:27:11) spot: rdieter: because it serves no useful purpose, and ends up with us wasting time on which group fields are more accurate for things. :)
(09:27:16) thimm: He recently created a list and initated discussion
(09:27:47) spot: f13: is there any chance that Group could be made optional for RHEL 5 if we can get it in FC-6?
(09:27:58) thimm: That would be great
(09:27:59) spot: this is a VERY low impact change to rpm
(09:28:19) rdieter: Why not just standardize/codify Groups and autogenerate Comps from that? (or vice-versa?)
(09:28:29) spot: rdieter: tried it, its a mess.
(09:28:41) spot: spent a week trying to make that work and all i got was ugly.
(09:28:42) rdieter: fair enough
(09:29:14) f13: spot: THere is some possiblity, however I have no idea how this would impact things like RHN, so it could very easily get shot down.
(09:29:15) thimm: I agree, gorpu and comps isn't useful *in* the package
(09:29:41) spot: f13: can you talk to paul and RHN and see?
(09:29:53) spot: and we'll wait to hear on them before we decide?
(09:29:55) f13: spot: the patch could alternatively supplant a generic group into the package so that there is somethign there in the metadata.
(09:30:09) thimm: Yes!
(09:30:12) spot: f13: if Group is unset, it shows up in the metadata as (null)
(09:30:13) f13: spot: waiting a week would suck.
(09:30:25) f13: spot: as a null char or as a string "(null)" ?
(09:30:28) spot: just like Packager does
(09:30:39) f13: some things don't react well to null objects (:
(09:30:50) spot: err..  (none)
(09:30:52) spot: not (null)
(09:30:53) spot: sorry
(09:31:34) spot: [spot@localhost ~] $ rpm -qi rpm
(09:31:34) spot: Name        : rpm                          Relocations: (not
(09:31:34) spot: relocatable)
(09:31:34) spot: Version     : 4.4.2                             Vendor: (none)
(09:31:34) spot: Release     : 31                            Build Date: Fri 04 Aug 2006
(09:31:35) spot: 05:50:48 PM CDT
(09:31:37) spot: Install Date: Fri 04 Aug 2006 05:53:05 PM CDT      Build Host:
(09:31:39) spot: localhost.localdomain
(09:31:41) spot: Group       : (none)                          Source RPM:
(09:31:43) spot: rpm-4.4.2-31.src.rpm
(09:31:45) spot: Size        : 1662182                          License: GPL
(09:31:47) spot: Signature   : (none)
(09:31:49) spot: Summary     : The RPM package management system.
(09:31:51) spot: Description :
(09:31:59) abadger1999: That would be fine by me.
(09:32:08) thimm: Can someone from the RHN people test this in a private RHN channel?
(09:32:39) spot: f13: we can vote on this via email on the list after we know if its possible to go into FC-6 with minimal RHN disruption
(09:32:41) rdieter: afaict, dropping Group induces much pain/breakage, for what I see as little/no gain, you guys still want to drop/optionalize it?
(09:32:59) spot: rdieter: nothing in Fedora is using Group now, not anaconda, not yum.
(09:33:07) spot: everything is using comps
(09:33:33) f13: thimm: RHN moves extremely slowly and is very busy making changes for yum stuff.  I doubt they'd test this any time soon.
(09:33:36) f13: thimm: I can request it though.
(09:33:57) rdieter: doesn't repoview use Group?
(09:34:21) f13: rdieter: it REALLY should use comps
(09:34:23) lutter: thimm: I'll take it up with the RHN folks
(09:34:24) abadger1999: rdieter: No.  It's something that people have been feature requesting since it started :-)
(09:34:25) thimm: synaptic and smart, too, but Jeremy suggested that these will all be fixed, if so cares
(09:34:30) f13: becuse the output from using Group is just silly at times.
(09:34:57) spot: half of Fedora Core has invalid groups, some with typos.
(09:35:05) f13: some really bizarre
(09:35:07) rdieter: ok, I'll play along, make it optional: +1
(09:35:22) thimm: optional in ghuideline, rpm or both? ;)
(09:35:31) spot: f13: can you see if paul can get it in FC-6?
(09:35:52) spot: i think that data point is pivotal to know before we move forwards
(09:35:57) thimm: Let's split the vote, I'd +1 on rpm patching, and want to know about RHEL before guidelines
(09:36:04) abadger1999: Optional in both and the patch to rpm inserts a "(none)" instead of leaving it blank?
(09:36:07) f13: spot: yes, I'm waiting for a pong.
(09:36:19) spot: --- rpm-4.4.2/build/parsePreamble.c.BAD 2006-08-04 17:34:22.000000000 -0500
(09:36:19) spot: +++ rpm-4.4.2/build/parsePreamble.c     2006-08-04 17:34:28.000000000 -0500
(09:36:19) spot: @@ -43,7 +43,6 @@
(09:36:19) spot:      RPMTAG_VERSION,
(09:36:19) spot:      RPMTAG_RELEASE,
(09:36:20) spot:      RPMTAG_SUMMARY,
(09:36:22) spot: -    RPMTAG_GROUP,
(09:36:24) spot:      RPMTAG_LICENSE,
(09:36:26) spot:      0
(09:36:28) spot:  };
(09:36:32) spot: this is the patch
(09:36:34) spot: thats a struct of "mandatory tags"
(09:36:49) spot: anything not in that struct gets auto-filled by rpm with (none) if it is unset
(09:37:29) thimm: Let's vote on a) rpm patch b) guidelines if RHEL can still use FE?
(09:37:48) spot: how about we just vote on the rpm patch
(09:38:01) spot: and we'll try to get it in FC-6 if the vote passes
(09:38:05) thimm: +1 for the rpm patch
(09:38:10) tibbs: +1 for the rpm patch
(09:38:17) spot: +1
(09:38:19) abadger1999: +1
(09:38:45) f13: +1 for the patch.
(09:39:02) rdieter: +1
(09:39:09) spot: ok, it passes
(09:39:23) spot: f13: talk to paul, see if it can go in FC-6, let us know?
(09:39:40) spot: ok, lets try to get one more item off the table
(09:39:45) thimm: kmdls?
(09:39:48) f13: spot: will do.
(09:39:48) thimm: :)
(09:39:56) spot: thimm: no, we're going to do that on Friday
(09:40:06) thimm: Is there a time set?
(09:40:26) spot: 1PM Eastern time
(09:40:34) abadger1999: IRC?
(09:40:38) thimm: That's in UTC?
(09:40:40) ***f13 may be closing on his condo then, and will not be able to make it.  *sigh*
(09:40:52) f13: thimm: 1 hour later than this meeting started
(09:40:56) f13: so 17:00UTC
(09:40:56) thimm: OK
(09:41:09) spot: (ugh, someone just turned on REALLY loud music behind me)
(09:41:18) f13: spot: /. booth?
(09:41:21) spot: ok, one easyfix
(09:41:27) spot: Reword ldconfig guideline
(09:41:58) spot: MUST: Every binary RPM package, which stores shared library files (and not just symbolic links) in any of the dynamic linker's default paths, must call ldconfig in %post and %postun.
(09:42:09) spot: this seems like common sense to me.
(09:42:10) spot: +1
(09:42:14) tibbs: Are there any cons to this?
(09:42:21) thimm: +1 (wasn't that already similar?)
(09:42:26) rdieter: +1
(09:42:32) abadger1999: +1
(09:42:34) tibbs: I can't think of anything; it's what I've been requiring in reviews for ages.
(09:42:38) tibbs: +1
(09:42:42) f13: spot: the (and not just symbolic links) makes it sound like we should run ldconfig on -devel packages that drop a symlink too.
(09:43:02) rdieter: f13: just the opposite...
(09:43:05) spot: f13: maybe s/just/only/g ?
(09:43:19) lutter: +1
(09:43:26) thimm: 6 votes
(09:43:42) f13: "which stores actual shared library files (not symlinks)
(09:43:42) thimm: "only" sounds better :)
(09:43:44) f13: "
(09:43:52) spot: ok, it passes. i think the intent is clear, we can play with the wording.
(09:43:53) abadger1999: s/and// ?
(09:44:08) f13: yeah, the 'and' is confusing.
(09:44:24) spot: thimm: is there any update from the FHS on libexecdir?
(09:44:42) thimm: I had a reply by one of the authors some time back
(09:44:53) thimm: He confused multilib with multiarch
(09:45:10) thimm: It isn't quite known that one can have several libs, but only one bin
(09:45:20) thimm: I was a bit confused
(09:45:33) thimm: I explained the model at FC/RHEL and am waiting for feedback
(09:45:44) spot: thimm: ok, thanks. keep us informed on updates? :)
(09:45:51) thimm: Sure.
(09:45:52) f13: I have a quick thought to discuss.
(09:46:01) f13: may I have the "floor" ?
(09:46:03) spot: f13: as long as it doesn't have the word kernel in it.
(09:46:06) spot: go ahead.
(09:46:48) f13: _IF_ we were to get the filesystem package to own %{_libdir}/pkgconfig/ is there any real reason for packages which contain .pc files to Require: pkg-config ?
(09:47:34) tibbs: I thought there were other reasons for the Require: other than just directory ownership.
(09:47:36) rdieter: I (still) think yes, .pc files are useless without pkgconfig
(09:47:41) spot: well, logic dictates that a package with a .pc file intends it to be queried by pkgconfig
(09:47:49) spot: i'd say the Requires is a good one.
(09:48:07) tibbs: But directory ownership was just the cover we used to say that this was already dealt with in existing guidelines.
(09:48:38) spot: f13: if filesystem required pkg-config... but that makes even les sense. ;)
(09:48:39) f13: Ok.  THere was a lot of grumbling from the Desktop folks regarding this.
(09:48:51) thimm: Why?
(09:48:55) spot: f13: anything specific in that grumbling?
(09:49:05) f13: Mostly because not all packages that have .pc are meant to ONLY be used by .pc
(09:49:06) spot: or do they just have irrational fears of text editing? ;)
(09:49:19) f13: and that -devel packages aren't very useful without say gcc, but we don't Require: gcc
(09:49:32) spot: what else uses .pc files?
(09:49:36) spot: other than pkgconfig ?
(09:49:39) f13: no no..
(09:49:53) f13: just because a package has a .pc file doesn't mean that it should only be developed with via pkgconfig
(09:50:07) f13: in fact I've been told htat some have a .pc file but its never really used.
(09:50:15) thimm: Yes, but then coinstalling pkgconfig doesn't hurt, does it?
(09:50:20) f13: bloat
(09:50:23) spot: yeah, i think this is stupid.
(09:50:33) rdieter: pkgconfig *is* pretty small/innocuous.
(09:50:44) spot: if it has a .pc file that isn't used, and they don't want to Requires: pkgconfig, they should nuke the .pc file
(09:50:51) abadger1999: If the filesystem package owns it does the question become: Requires in providing package or BuildRequires in dependent package?
(09:51:02) thimm: Yes
(09:51:11) thimm: That's the dilemma
(09:51:26) f13: nod.
(09:51:29) thimm: Better in the *-devel package
(09:51:39) tibbs: How is this addressed in other cases?
(09:51:40) spot: i would tend to agree.
(09:51:46) f13: I'm agnostic on this issue.
(09:51:47) thimm: Because if the interface changes and suddenly a package does use the *.pc files, you already have it in place
(09:51:47) spot: pkgconfig should be dragged in by -devel
(09:52:04) f13: tibbs: inconsistantly (:
(09:52:23) tibbs: Does any have any examples?
(09:52:27) f13: Ok, we've discussed it, thats enough for me.  Regardless of directory ownership, .pc should require pkgconfig.
(09:52:39) spot: yep.
(09:52:41) f13: tibbs: I can't think of many off the top of my head.
(09:52:47) tibbs: That's what we voted on already five or six weeks ago.
(09:52:49) thimm: f13: Does the guideline need rewording
(09:52:51) f13: s/many/any/
(09:52:55) f13: thimm: I don't think so.
(09:53:05) thimm: I mean if the directory ownership argument is removed
(09:53:06) spot: ok, very very quickly
(09:53:15) tibbs: Were the guidelines ever updated after that vote?
(09:53:20) spot: as i have to go work the Linuxworld booth in a few minutes
(09:53:36) spot: lutter: did the jpackage folks ever respond to f13's proposal on versioning?
(09:53:52) lutter: spot: not to me, haven't heard from them, really
(09:54:14) f13: and our jpackage fellow claims to be too busy to talk about it until sometime next year.  *GRRR*
(09:54:23) tibbs: So they're just going to ignore the issue and keep up with their bizarre versioning?
(09:54:34) spot: i think we should consider voting on it for Fedora.
(09:54:35) f13: thimm: possibly, I haven't read the rule lately.  Cross that bridge when we come to it?
(09:54:49) f13: spot: won't do any good if they refuse to follow it.
(09:54:53) spot: we've given them a LOT of time and patience to try and work a compromise and i think f13's proposal makes sense.
(09:55:04) thimm: f13: ok
(09:55:13) f13: spot: there is some trouble brewing around tha java team right now anyway, so I'm ok to wait a few.
(09:55:13) spot: well, really, does your proposal require any Fedora changes?
(09:55:27) tibbs: At this point I certainly won't approve any Extras packages with the jpp naming stuff.
(09:55:29) f13: spot: nope.  It just requires them to change the names.
(09:55:47) tibbs: But it looks like all of the Extras Java packages have completely stalled and the maintainers have disappeared.
(09:55:48) spot: then we stick with our policies and deny anything with the jpp naming
(09:55:57) f13: all my proposal was is a way for them to accomplish some of their goals and adhere to EXISTING Fedora guidelines.
(09:56:06) f13: spot: WORKSFORME
(09:56:35) tibbs: Should we try to get the proposal ratified and into the guidelines, at least as an example?
(09:56:37) spot: ok, before we break, are there any issues people want to discuss (quickly)?
(09:56:52) thimm: spot: will the meaating tomorrow be on #fedora-packaging, phone or both?
(09:56:55) abadger1999: ScriptletSnippets:
(09:57:03) tibbs: Can we move forward on the writeup issues?
(09:57:06) abadger1999: II'm going to move it out of drafts and into packaging.
(09:57:14) spot: thimm: irc
(09:57:14) abadger1999: Unless anyone has more issues.
(09:57:22) spot: too much pain over languages
(09:57:34) thimm: ok
(09:57:35) tibbs: And can we move "don't ghost .pyo" from ratify to writeup now?
(09:57:38) spot: abadger1999: i think thats fine, go ahead.
(09:57:45) spot: tibbs: yep.
(09:57:53) f13: agreed.
(09:58:05) thimm: ghost pyos: send notification to fe list?
(09:58:11) thimm: (for old packages)
(09:58:21) thimm: Or was there one already?
(09:58:23) tibbs: Lots of people have already changed their packages.
(09:58:30) abadger1999: Who is responsible for doing writeups?  Owner of the draft?  spot?
(09:58:40) f13: owner of hte draft WORKSFORME
(09:58:42) spot: abadger1999: i think the owner can/should do it
(09:58:52) spot: removes me as a bottleneck
(09:59:01) abadger1999: Sounds good.  Get to work guys :-)
(09:59:11) spot: ok, last but not least,
(09:59:18) spot: who will take this meetings decisions to FESCO?
(09:59:32) f13: -EOTHERMEETING :/
(09:59:34) spot: (Linuxworld is about to open again, so i will be absent)
(09:59:56) abadger1999: I'll do it unless tibbs wants the honor.
(10:00:07) tibbs: Did we actually decide anything of consequence?  RPM group optionality patch and nothing else, really.
(10:00:15) spot: ldconfig
(10:00:20) thimm: pc
(10:00:23) tibbs: doh.
(10:00:30) spot: well, pc is pretty much no change
(10:00:39) thimm: Well a confirmation of our stand ;)
(10:00:44) abadger1999: ldconfig is just a clarification too.
(10:01:01) spot: worth mentioning. we don't want to think that all we do is flame eachother. ;)
(10:01:24) spot: ok guys, thanks for the time and effort.
(10:01:25) abadger1999: We should also mention that the RPM plan is to phase out the RPM Group over time.
(10:01:37) f13: spot: have a good show
(10:01:40) ***f13 steps out
(11:09:04) rdieter is now known as rdieter_away
(11:10:20) rdieter_away is now known as rdieter
(11:15:50) rdieter is now known as rdieter_away
(11:30:04) warren [n=warren]  entered the room.
(11:55:07) rdieter_away is now known as rdieter
(12:16:26) f13_ [n=jkeating]  entered the room.
(12:16:31) f13_ left the room (quit: Client Quit).
(12:16:51) f13: spot: I have feedback from Paul, and it's not good.
(12:17:12) f13: Given the state that RPM is in right now, and our desires to resolve the "upstream" issues, we're not going to make any changes like this to rpm for FC6/RHEL5 timeframe.
(12:17:19) f13: so Groups are as is for now :/
(12:17:44) thimm: How will upstream issues be resolved?
(12:17:47) thimm: rpm fork?
(12:18:05) thimm: Looking for an rpm maintainer? ;)
(12:18:20) warren: thimm, yet to be determined