Extras/SteeringCommittee/Meeting-20070524

2007 May 17 FESCo Meeting

Members

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)

Summary

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