Extras/SteeringCommittee/Meeting-20070524

= 2007 May 17 FESCo Meeting =

Present

 * Brian Pepple 	(bpepple)
 * Jason Tibbitts	(tibbs)
 * Jesse Keating	(f13)
 * Toshio Kuratomi	(abadger1999)
 * Bill Nottingham	(notting)
 * Kevin Fenzi 		(nirik)
 * Dennis Gilmore	(dgilmore)
 * Jeremy Katz		(jeremy)
 * Tom Callaway		(spot)
 * Rex Dieter  	(rdieter)
 * Christian Iseli	(c4chris)

Absent

 * Warren Togami	(warren)
 * Josh Boyer		(jwb)

Static libs packaging guidelines changes

 * FESCo had no objections to the changes to the static libs packaging guideline changes by the Packaging Committee. https://www.redhat.com/archives/fedora-maintainers/2007-May/msg00926.html

Static libs package- cernlib & paw

 * It's was alright to statically link paw, but it needs a blocker bug opened on it, so that it can be fixed in the near future.
 * cernlib should conform to the packaging guidelines for static libs, namely that it's static libs be in a -static subpackage.

Proposal on how to handle violations of the packaging guideline

 * FESCo approved pjones proposal. https://www.redhat.com/archives/fedora-maintainers/2007-May/msg00634.html

Log
--- bpepple has changed the topic to: FESCo meeting -- Meeting rules at http://www.fedoraproject.org/wiki/Extras/Schedule/MeetingGuidelines -- Init process FESCo meeting ping -- abadger1999, bpepple, c4chris, dgilmore, f13, jeremy, jwb, notting, rdieter, spot, nirik, tibbs, warren Hi everybody; who's around? nirik is here. notting is here spot is here abadger1999 here here soon (2 mins...) here waiting for jeremy to fix a couple blockers so I can go back to testing trees (: ok, looks like most folks are here so we can probably get started. --- bpepple has changed the topic to: FESCo meeting -- Any objection to this week's report from FPC at https://www.redhat.com/archives/fedora-maintainers/2007-May/msg00926.html Just some static library packaging guideline tweaks Any objections to the static libs changes? bpepple doesn't have any either. nirik thinks it looks good. seems ok ok, I don't hear any objections here or on the mailing list, so I think we can safely say this was approved. Note that we're prepping for ocaml packages as well. ocaml as a language doesn't really support dynamic linking of most things. But that's more fun for next time. --- bpepple has changed the topic to: FESCO-Meeting -- packages with static libs approval -- cernlib requested by Patrice Dumas - https://www.redhat.com/archives/fedora-maintainers/2007-May/msg00947.html ugh Ugh to Patrice or ugh to ocaml? since we're talking about static libs we should probably go to this item. so according to the guidelines, he should make a -static subpackage there? maybe we should let uli be the ack/nack for all static libs... (: f13: that's evil :-) his rationale seems ok to me. +1 spot: I agree. I don't understand if he's asking for not having to put things in a -static subpackage.  (btw i did have an outstanding question on whether to use a static libgcrypt on gaim-otr, but no one on the list answered) LetoTo: we can talk about that next. no, he's asking to produce a statically linked binary We want to see those so that we can immediately see when something links statically so we know what must be rebuilt. With other packages wouldn't we say "ExcludeArch x86_64" ? um if statc libs break on *64, that should be fixed. that's a *bug* sorry, dynamic libs, but same difference It's dynamic linking that's not working on x86_64. yes, and that's a bug. that should have *zero* effect on execution Well, anything like that is a bug, I guess. It would be nice to understand what's actually breaking here. yup  (my question is more on what should a packager do when no one answers) abadger1999: yes what I'd like to be able to say is: fine for this release, but please fix it for the next... but I'm not sure how to track that in a meaningful way... So there seem to be two issues: 1) What's the source of this bug that requires the static link on *64? 2) Can he ship a static library regardless because that matches user expectations and upstream's desires? yes, we agreed we can ship static libs for our user's enjoyment we just don't like statically linked *executables* I have no problem with #2. The static link in #1 to work around the bug is OK with me as well as long as someone's actually looking at the bug. c4chris: Well, "In general, packagers are strongly encouraged not to ship static libs unless a compelling reason exists." tibbs: right  http://www.redhat.com/archives/fedora-extras-list/2007-February/msg00425.html there's another problem with #2 He wants to ship the static lib inside the -devel When he needs to ship it inside a -static. yea I phrased that badly tibbs: yeah, but i'm not sure that 'upstream code is buggy' counts as 'compelling' notting: The issue here is user expectations, though. afaiu, upstream only cares about static libs which puts all the dyn linking burden on the packager... including debugging the issue, I guess Looks like the upstream situation is a little confusing... There's upstream and there's Debian. Debian cares about dynamic libraries but true upstream does not. yes bpepple agrees with notting c4chris nods :-) The user argument is sufficiently compelling to me, though. But I still don't know if Patrice is refusing to put the static libs in a -static subpackage. I would say shipping static should be allowed, but yeah, they should be in a -static subpackage. nirik: yea, in teh hope there'll be a dynamic lib available at some point are there both shared *and* static libs?  If so static ones should be separated, yes. Hmm... true upstream also only cares about x86 and IBM ppc. there are both, but dynamic doesn't work on x86_64? (from what I can gather... could be wrong) If *only* static, then -devel, with Provides: *-static is ok (ins't it?) rdieter: Yes. rdieter: yes, there is that was yes to "shared *and* static libs" nirik: the thing is, you have to go out of your way to make something that breaks dynamically but works statically so -static is mandatory I think ok, then, -static it is (if easliy possible, some packages make this difficult). yeah, odd alright. ;( ok, so we think that patrice just needs to use -static instead of -devel? both -devel and -static rdieter: +1 per the guidelines. rdieter: right. I was just assuming he would keep the devel. rdieter: +1 anything else? or should we move on. Do we need to vote here, are are we just waiting for dissent? Do we want to vote on the paw issue? tibbs|h tibbs (statically linking paw on x86_64) tibbs: I was waiting for any dissent. abadger1999: you right, I forgot about the paw issue. s/you/your/ Is it alright to statically link paw to x86_64? when cernlib has -static it should at least be detectable that it's doing that. I'm -1 on linking paw statically as it seems like it should be treated as a bug and fixed or ExcludeArched until fixed. I have no issues as long as its recognized that it's a temporary issue and someone's trying to figure out how to fix it. But I won't object strenuously to the workaround.  ( I also wouldnt mind feedback on static link of gcrypt on gaim-otr as references with my above url, since the mail to the list got no responses) tibbs: +1 tibbs: I don't see any bug tracker that's tracking the issue. The primary motivator behind static library exclusion seems to be security, and that shouldn't really be an issue here. LetoTo: we can get to that later. at the end of the meeting in the free discussion. Is this package actually in the distro or just in review? LetoTo: I'm inclined to revisit when the case at hand happens  bpepple: oh ok. thought we were doing all static lib issues now.  c4chris: yes, me too. Seems to be in the distro. How on earth did it pass review like that? LetoTo: this was something that Patrice wanted added to today's agenda. tibbs: no pcc64 at th etime. I thought it was an x86_64 issue as well. now I'm confused, i thought it was ppc64 only. arg. The email says: paw is linked statically against the cern libraries. Otherwise it fails on 64 bit platforms ok I'm making the assumption that includes x86_64. maybe teh failure was reported after the package went in? imo: blocker bug, ExcludeArch rdieter: +1 rdieter: So you're against allowing a static link in this case? tibbs: yeah, think so. give bugfixing a chance first. So I guess it's +1 (me) and -3 (abadger1999, bpepple, rdieter) at this point. I think it should be allowed as long as it's being worked on (bug filed, etc) other FESCo members thoughts? so +2 and -3. +1, but expecting bug tracking/fixing i think its ok as long as there is an open, active issue. +4 and -3 I think we can all agree a block bug is required, yes? Yes. rdieter: yes yes yep yep rdieter: yes then, consider me "on the fence" whether to allow static in the meantime (I don't feel strongly one way or the other really). yes ok, so it sounds like we're ok with paw being statically linked, but a blocker bug needs to be opened on it. yea, the only thing I feel strongly about is tracking and fixing the issue asap ok, I think we can probably move on now. --- bpepple has changed the topic to: FESCO-Meeting -- MISC -- proposal to answer the guidelines question -- https://www.redhat.com/archives/fedora-maintainers/2007-May/msg00634.html Everyone get a chance to read pjones proposal? yup, liked it +1 here also. Yes, but don't forget the "who is allowed to change which packages" doctrine bit. +1 +1 +1 +1 +1 (common sense rocks all) Because frankly I'd just go in and fix the problem myself if it was easy. +1 I think this goes beyond that to the maintainer actively is refusing to do the right thing.  is this the proposal with the "..orphan process" or "...fesco then decides" as step 5? The one thing that wasn't in his proposal was a bit about who FESCo chooses as an arbitrator. cweyl|work: yup  c4chris: that was an either or question :) I think a fundamental issue for me is that I'd choose not having the packages over having bad packages. bpepple: "someone FESCo trusts..." oh the latter for me please :-)  :) rdieter: right, but probably not someone on FESCo I was thinking.  or someone on FPC. cweyl: right. bpepple: does it matter? (imo, it shouldn't) should be FESCo's judgement on whether the arbitrator has a conflict of interest or not. rdieter: +1 It would avoid the suggestion of impropriety if the arbitrator was not the person who authored the guideline, I suppose.  it should be someone "disinterested" -- that is, competent and trusted to "do the right thing", but having no personal stake in the outcome :) tibbs: right. I don't have an issue either way but some people on the mailing list brought it up. sorry im late guys The arbitrator will need to understand the spirit of the guideline that the two parties are in disagreement about which could be someone on FESCo or the FPC sometimes.  I mean, this is a method of last resort. it's good to be very careful who's picked The thing is, I think we've illustrated our willingness to change the guidelines when someone brings up a real issue. no need to overengineer this with needless extra baggage, rules, regulations, beuracracy. rdieter: I agree. It's usually best to keep it simple. Yes, let's just try to be smart and defuse arguments. let's wait for a first issue which pjones' proposal is, as-is.  well, the problem with picking someone from fesco or or FPC to be this sort of last-resort moderator is that it could just _look_ bad. if they're supposed to be impartial, then picking people with strong ties to either fesco or FPC doesn't seem to be a good idea. IMHO. Which means that when the issue actually comes up, we'll try to find something who isn't contentious. Then FESCo should be smart enough to know better when the time comes. yup tibbs: +1 if FESCo isn't trustworty, we have bigger problems. cweyl|work: Only if it's seen as FESCo vs the packager or FPC vs packager. If it's two packagers with disagreements then it should be ok. rdieter: agreed. I'm fine with leaving pjones proposal as is, but I did want to bring up Hans point. It'll have to be an arbitrator picked on a case-by-case basis.  abadger1999: point taken. Anyone have an issue with pjones proposal as is? Otherwise, I think we can consider it accepted. accept++ +1 +1 +1 +1 +1 +1 +1 +1 Ok, I think we can move on then. --- bpepple has changed the topic to: FESCO-Meeting -- MISC -- F7 Prep anything we need to discuss regardig F7?  let's see 1) names are headed for legal clearance  didnt that happen already before voting? preliminary clearance happened. final clearance now. :/ notting: (I thought the names all cleared?) see above notting: see max's mail from this morning Isn't naming really the least of the issues, though? jeremy: ok, i'm behind on some things Fedora 7 is Moonshine tibbs: well, it's a blocker we have more blockers that we are working through. last i heard was that go/no go for the 31st date will be decided tomorrow tomorrow at 2pm EDT to be precise. yep notting: cool. <LetoTo> so rc1 happens today ? current blockers are: anaconda/rhpl locale. mdraid. I'm sending an update to fedora-devel list. LetoTo: looks like /late/ today. meeting here on IRC? is iwl3945 at this point 'as good as it's going to be for final'? LetoTo: which would really mean rawhide tomorrow for most cases, perhaps a torrent of DVD isos for media installs. <LetoTo> cool. there are still a few broken deps, and a number of evr issues left. ;( notting: There haven't even been any upstream changes in the last two days to the iwlwifi drivers, so probably. nirik: which broken deps? nirik: is there a current list somewhere of the broken deps. I'll have some free time tomorrow to help out. http://www.scrye.com/~kevin/broken-deps-20070523.txt (from yesterday, might be fixed now?) nirik: thanks. the kmods need the final kernel. the php packages need rebuilding or removal. is gaim-gaym gone now? nirik: I believe so. looks like it should be blocked, yes ok, so those 2 php packages, the kmods, and on ppc there is still: package: glest-data - 2.0.0-2.fc7.noarch from development unresolved deps: glest = 0:2.0.0 glest == excudearch ppc? yep. anything else regarding F7?  Or should we move on? nirik: so, we would need to rebuild glest-data to add an exclusivearch to the noarch, or just let itgo broken EVR list from last night is: http://www.scrye.com/~kevin/evr-list.txt notting: correct. i'm inclined to let it go rather than force a 64MB download on all users yeah, it's probibly pretty minor. Still anoying tho. who wants to tackle syck? What's wrong with syck (again)? thats tibbs fav package. ;) broken deps tibbs: Same ol' same ol' broken dep with php... again ... on php = 0:5.2.1 why does it hardcode the version? No reason to break with tradition. I'll look at it. LetoTo: we LetoTo: we're running out of time for this week. Do you mind if we discuss your issue at next week's meeting? <LetoTo> nope. just makea reference of the url LetoTo: no problem. looks like the other one was built, needs tagging? http://koji.fedoraproject.org/koji/buildinfo?buildID=6644 or my mirror is out of date. it's tagged. it's tagged f7-final I think LetoTo's issue need some consideration and discussion on-list. tibbs: that's fine w/ me. But yes, libgcrypt's behavior here is really poor. Ok, we should probably start to wrap up for this week.  Anything else folks want to discuss before calling it quits? <LetoTo> tibbs: yeah and has been an outstanding bug for ages :( nothing more here Nothing from me. bpepple will end the meeting in 60 spot: no food for you bpepple will end the meeting in 15 -- MARK -- Meeting End
 * tibbs here.
 * jeremy is here-ish (looking at a cluster of f7 blockers, but also trying to pay attention here)
 * c4chris here
 * c4chris has none
 * c4chris hopes things get sorted out why 64-bit doesn't work, but in the meantime: ok
 * cweyl|work settles into his rabble seat
 * notting mutters about physicists :)
 * jeremy just mutters
 * jeremy is overall more neutral
 * dgilmore is ok with it
 * bpepple will be pretty glad when F7 is out the door.
 * spot is ready for lunch
 * bpepple will end the meeting in 30