From Fedora Project Wiki
< Extras | SteeringCommittee
Summary
Present from FESco -- scop, warren, mschwendt, skvidal, jpo, skvidal
- Weekly sponsorship nomination
- we need more reviewers.
- "Education" is key to getting more reviewers.
- tibbs and warren will improve the docs in the wiki
- Incompatible package upgrade policy
- that's a old item in the schedule -- we didn't talk about this for months. See full log for details (19:21 - 19:47). But the problem isn't that big, so we don't need to hurry (this was before the directfb update happened)
- Define rules how SIGs should work
- also on the schedule for a long time already. It was agreed on that we don't want to define anything ATM. Just let them work as they like. We can revisit this later if we want/have to.
- other discussions (see full log for details):
- 19:02 permissions problems with the extras-push scripts should be fixed (mostly)
- 19:51 what do people think about multiple maintainers for a single package?; lack of a proposal how to do it exactly
- 19:52 emacsen/muse
- 19:58 it is not possible to CC the fedora-security mailing list from bugzilla
- 20:00 thl, as far as the voting system goes... i have yet to hear anything back from Sopwith
Full log
19:00 --- | thl has changed the topic to: FESCo meeting in progress
19:00 * | thl looks around
19:00 * | jima scurries away again
19:00 --- | Users 70 nicks
19:00 < mschwendt> | Note to all: FE repodata for 3|4|5|development has been recreated on the master server. Sync happening right now. -- The next push will break again, though, unless the remaining permission problems get fixed. ;)
19:01 < jpo> | thanks Michael
19:01 * | jima applauds mschwendt
19:01 * | thl sees scop, warren, mschwendt, skvidal, jpo -- anyone else from FESCo around?
19:02 < thl> | seems not
19:02 --- | thl has changed the topic to: FESCo meeting in progress - Broken deps report
19:02 < thl> | mschwendt, skvidal that's the status? does it run on buigl64 already?
19:03 < mschwendt> | no
19:03 < warren> | mschwendt, remaining permission problems?
19:03 < thl> | well, is there anything new that needs to be discussed?
19:04 < mschwendt> | warren: not for repoclosure script, but for the extras-push scripts
19:04 < thl> | mschwendt, or do we simply wait until you and skvidal find time for it
19:04 * | warren looks at extras64
19:05 < warren> | mschwendt, I fixed this again 2 days ago, who owned files that had wrong permissions today?
19:05 < mschwendt> | you and scop
19:05 < warren> | 644 and 755 permission?
19:05 < mschwendt> | extras-repobuild.py terminates with a bad shell exit code, which is not recognised by the push script
19:06 < mschwendt> | I've fixed this in CVS already and up'ped the scripts on the server
19:06 < mschwendt> | warren: see /tmp/repomd-cache
19:06 < warren> | mschwendt, btw, what do you use to upload scripts to the server?
19:06 < warren> | mschwendt, do you sync it from cvs, or just upload manually
19:06 < mschwendt> | I sync them
19:06 < warren> | how?
19:06 < scop> | FWIW, my last login to buildsys was two days ago, and IIRC I didn't even do a push back then
19:06 < mschwendt> | warren: cvs up from within extras_signers group
19:07 < warren> | ah
19:07 < mschwendt> | scop: these files are from May 7th and older!
19:07 < mschwendt> | repodata has NOT been created since then
19:09 < thl> | do you guys want to dicuss this further?
19:09 < thl> | or can we move on?
19:09 < mschwendt> | let's move
19:09 < mschwendt> | we have a separate list for this
19:09 < thl> | k
19:09 --- | thl has changed the topic to: FESCo meeting in progress -- Weekly sponsorship nomination
19:09 < thl> | any new nominations?
19:09 < thl> | while on the topic:
19:10 < thl> | did evereyone notice the fedora-music-list and the plans to get lots of stuiff from Planet CCRMA into extras?
19:10 < thl> | that will probably a lot of reviewing work
19:10 < che> | thl, awesome though
19:11 < tibbs> | Yes, we need more reviewers.
19:11 < warren> | did we have any resolution on the alternative kernel thing?
19:11 < thl> | warren, that's more on the fab list currently
19:11 < warren> | And is he submitting everything through the review process like normal?
19:11 < noa> | thl, yup.. I'm wondering.. how is that intitiative related to what monty talked about over at fudcon?
19:11 < thl> | warren, it seems jack currently is the bottleneck
19:11 < warren> | who is jack?
19:12 * | skvidal just got back
19:12 < mschwendt> | a package in the queue
19:12 < noa> | jack is a real time audio pipeline
19:12 < thl> | jack-audio-connction-foo
19:12 < warren> | oh
19:12 < warren> | noa, Noa Resare?
19:12 < tibbs> | https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=183912
19:12 < noa> | warren, yup :)
19:12 < noa> | warren, long time
19:12 < warren> | noa, welcome back! You were one of our original contributors.
19:12 * | noa remembers setting up a bugzilla for fedora in the early days :)
19:13 < warren> | noa, still running with no security updates! =)
19:13 < thl> | noa, btw, I don't know "what monty talked about over at fudcon"
19:13 < noa> | unfortunatly I was sucked up in work and family life for a months
19:13 < thl> | noa, did I miss anything important?
19:14 < noa> | thl, it was one of the videos, it seems like he has gotten the task to design an audio daemon that will try to fix many of the problems with audio on linux
19:14 < warren> | noa, you came to Boston?
19:14 < warren> | thl, noa: I suspect this has nothing to do with what monty talked about.
19:14 < noa> | warren, no, i saw the videos over here in sweden
19:14 < warren> | ah
19:15 < thl> | noa, k
19:15 < thl> | anyway, back to the topic
19:15 < noa> | sorry :)
19:15 < thl> | tibbs> | Yes, we need more reviewers.
19:15 < thl> | that's IMHO one crucial point
19:15 < tibbs> | I'm trying to do at least two a day, but lately the list has been growing.
19:15 < che> | thl, what are the requirements for a reviewer?
19:15 < mschwendt> | thl: the problem with jack is not that we need more reviewers, but that it is not ready. Fernando has commented on the package already.
19:15 < thl> | and related to " Encourage Extras reviews " -- that's still on the schedule
19:16 < warren> | thl, adn again I say, "Education" is key to getting more reviewers.
19:16 < bpepple> | warren: +1
19:16 < thl> | warren, that's why I brought " Encourage Extras reviews " onto the table
19:16 < thl> | that's assigned to you warren
19:16 < thl> | you had plans to update the docs in the wiki
19:16 < tibbs> | che: you need cvsextras membership, which means package maintainership, which means sponsorship.
19:17 < warren> | unfortunately I've been unable to prioritize the necessary work to rewrite that entirely myself
19:17 < tibbs> | Well, fedorabugs membership, but cvsextras is the prerequisite for that.
19:17 < mschwendt> | tibbs: in short "you need a sponsor" -- package maintainership is not needed
19:17 < cweyl> | well, "anyone can review", if I recall correctly... it's the _approving_ part that requires cvsextras
19:17 < thl> | warren, any timeframe when to get this done?
19:17 < thl> | or is anyone else interested in improving our docs?
19:18 < warren> | I think it will be an incremental process, and I will need help.
19:19 < thl> | warren, could you find time to lay down a small and rough plan and ask for help on f-extrs-list?
19:19 < tibbs> | I'd like to help
19:19 < warren> | How about I work with tibbs.
19:19 < thl> | tibbs, can you take care of that together with warren?
19:19 < warren> | and we create a plan, and ask the list
19:19 < thl> | warren, tibbs, thx
19:20 < tibbs> | Sure. Email OK?
19:20 < warren> | okk
19:20 < thl> | k, then let's move on
19:20 < thl> | we'll see if we later if we need more reviews and/or sponsors for the stuff from Planet CCRMA
19:21 --- | thl has changed the topic to: FESCO Meeting -- Incompatible package upgrade policy
19:21 < thl> | warren, that's still on the schedule and assigned to you
19:21 < warren> | Have we really had problems with this?
19:21 < scop> | yes
19:22 < scop> | not recently AFAIK, though
19:22 < tibbs> | One came up last week. Let me think...
19:22 < warren> | I think "do the right thing" and improved tools to tell us when things break gives us a nice balance between freedom and control.
19:22 < thl> | improved tools sound like a good idea
19:22 < tibbs> | I think it was "pan", the newsreader.
19:23 * | mschwendt must leave for a few mins
19:23 < warren> | We need the ability to upgrade stuff, because that is the easiest way to fix problems sometimes. At the same time we need the tools to support this, and enforce rebuilding deps when you make such changes.
19:23 < thl> | I also dislike the plague part in each of the broken deps report for FC3
19:23 < scop> | tools tend to help within FE only
19:23 < scop> | thl, so poke the maintainer to do something about it?
19:23 < thl> | dcbw build plague for FC3 but the dep "createrepo >= foo" is not resolvable
19:24 < thl> | scop, such packages probably shouldn't even hit the repo
19:24 < thl> | (in an ideal world)
19:24 < scop> | right, but if something's broken, it needs to be fixed
19:25 < warren> | Idea
19:25 < scop> | "not liking" seeing someting in breakage reports doesn't help alone ;)
19:25 < thl> | scop, in the case of plague it would require a updated createrepo released as update from core
19:25 < thl> | scop, sure ;-)
19:25 < scop> | thl, I know, https://bugzilla.redhat.com/170531
19:25 < warren> | Should the package sign & push process resolve deps and exclude things that break deps?
19:25 < thl> | warren, yeah, maybe
19:27 < thl> | scop, thx, didn#t know there was a bug for it open
19:27 < thl> | warren, would that be possible and easy to do?
19:27 < noa> | warren, if there is a good mechanism for notifying the affected maintainers I think that would be good
19:28 < skvidal> | thl: no, it wouldn't be
19:28 < warren> | per-package CC lists that people can subscribe to would help
19:28 * | warren files that idea...
19:28 < scop> | but that's no substitute for a policy
19:29 < mschwendt> | thl: there is no way to withdraw a built package as it was made available to the build system already
19:29 < thl> | mschwendt, also true
19:30 < thl> | maye plague could check if all deps are resolved before pushing a package to the needsign repo
19:30 < thl> | or does that sound completely silly ?
19:30 < skvidal> | how about make the pkg owner check for closure before they push out a package
19:30 < tibbs> | You couldn't rebuild a dependency chain that way, could you?
19:31 < thl> | and is the problem big enough to discuss it?
19:31 < scop> | not completely silly, but something that could cause problems in complex build dependency chains
19:31 < thl> | scop, true
19:31 < mschwendt> | sounds like we need a QA Checklist again :)
19:32 < thl> | anyway, back to the original topic: Incompatible package upgrade policy
19:32 < scop> | no, we need that policy :)
19:32 < thl> | that what is written in the wiki:
19:32 < thl> | Seems like we need tools that will allows packagers to 1. notify others when the packager breaks something that others depend on; 2. notify the packager when he's about to break somwthing that others depend on. Warren is working on a proposal.
19:32 < thl> | anyone any idea how this could be done?
19:33 * | scop brb
19:33 < mschwendt> | if you are aware of your package's deps, why not mail the other package owners?
19:33 < warren> | Combination of written process and automated detection
19:34 < thl> | "automated detection" seems crucial
19:34 < jima> | mschwendt: i thought the problem was more not being aware of the dependency problem.
19:34 < jima> | thl: exactly.
19:34 < skvidal> | the problem will be two people submitting at the same time
19:34 < warren> | although skvidal has a good point
19:34 < skvidal> | you could make them both check for closure
19:35 < skvidal> | but due to their two pkgs coming out at the same time
19:35 < skvidal> | they'd have no way of knowing about new deps
19:35 < skvidal> | or the removal, thereof
19:36 < thl> | :-/
19:36 < thl> | so what do we do? we ignored it for months already
19:36 < thl> | do we want to continue so?
19:37 < thl> | and try to fix the things one by one when they show up the next time?
19:37 < warren> | it hasn't been as much of a problem lately
19:37 < thl> | agreed
19:37 < tibbs> | Is it possible to track dependencies and alert maintainers when something new depends on their packages?
19:37 < jima> | oooo.
19:37 < mschwendt> | probably with a front-end for repoquery
19:38 < XulChris> | heya tibbs got your comments on my package, thanks
19:38 < warren> | basic building blocks like: per package CC list would allow otehr infrastructure to build on top of it.
19:38 < skvidal> | tibbs: and display it where?
19:38 < tibbs> | Email? Or just a command-line tool to list stuff that depends on me.
19:38 < tibbs> | It would at least tell me who I need to keep updated.
19:38 < skvidal> | tibbs: just add a command to the makefile system to look for what depends on their package
19:38 < jima> | i'd think email; there's probably no incentive/reminder to run the command.
19:39 < skvidal> | then they maybe could do: make whatrequires
19:39 < skvidal> | jima: right, b/c MORE email makes people pay attention
19:39 < skvidal> | </sarcasm>
19:39 < tibbs> | Imagine you're Rex. All kinds of stuff is going to depend on Qt4 once it gets in, plus he has like 50 other packages.
19:39 < XulChris> | tibbs: your comments said my package didnt have a %check section, but it does
19:40 < tibbs> | XulChris: I'm prone to idiocy. Shoot me the bug #.
19:40 < thl> | well, I'll mention this discussion in the summary
19:40 < thl> | maybe some other people have an idea
19:40 < mschwendt> | Does repoquery have an option to examine _all_ dependencies?
19:41 < thl> | I'll leave it on the schedule for now
19:41 < |Jef|> | mschwendt: --alldeps
19:41 < mschwendt> | And this doesn't suffice?
19:41 < mschwendt> | Sure, one could evaluate owners.list, too, but why?
19:43 * | thl waits 15 more seconds for further input and will move on if nothing shows up
19:43 < |Jef|> | mschwendt: hmmm alldeps might not be what you want... "check non-explicit dependencies as well" may not mean "walk the dep tree"
19:43 --> | Eva42 (Unknown) has joined #fedora-extras
19:43 * | thl waits 20 seconds before moving on
19:43 < mschwendt> | Walking the entire dep tree is not needed
19:44 < mschwendt> | Just a beautified display of "my package is used by: A B C D" possibly with owners' email addr in brackets
19:44 < thl> | mschwendt, maybe we can have that in the planed web-interface
19:44 * | scop wants to note that no tool the packager can run will help with locally installed stuff or unconfigured 3rd party repos
19:44 < jima> | no, because the non-explicit deps should be handled when checking the explicit deps' dependencies.
19:44 < jima> | 12:43 < mschwendt> Walking the entire dep tree is not needed
19:44 < thl> | awjb had plans for one but didn#t work on it yet (afaik)
19:44 < jima> | irt that
19:45 < thl> | k, guys, let's forget about this topic for today and let's move on
19:46 < jima> | forget about what topic?
19:46 < thl> | jima, the "Incompatible package upgrade policy"
19:46 < jima> | thl: _what topic?_ (sorry...)
19:46 < warren> | It is a bit more complicated and difficult to fix than we can figure out during this meeting.
19:46 < thl> | warren, exactly
19:47 --- | thl has changed the topic to: FESCO meeting -- Define how SIGs should work
19:47 < thl> | that's still on the schedule
19:47 < tibbs> | The games SIG is running nicely.
19:47 < XulChris> | what does that mean?
19:47 < thl> | do we still want do to that or do we just proceed as currrently?
19:47 < XulChris> | ya i was just gonna say..
19:48 < warren> | Aren't SIG's working fine now?
19:48 * | _wart_ thinks so
19:48 < XulChris> | well there is some confusion between the music SIG and "sound" SIG
19:48 < thl> | warren, they are, but we have no real "rules" how they should wroks
19:48 < thl> | work
19:48 < jima> | isn't "how do we start up a new SIG?" more the issue? :|
19:48 < thl> | the question is: do we need such rules?
19:49 < tibbs> | SIGs may start to overlap or conflict as more of them appear.
19:49 < _wart_> | thl: I don't think rules are necessary at this point. Things seem to be working fine without strict rules for now.
19:49 < warren> | thl, I've kind of been handling that. I've been demanding that each group write their Wiki page with goals and such before they get their mailing list. Games went through this.
19:49 < warren> | thl, so I could just write that down on the wiki.
19:49 < jima> | s/rules/guidelines/ ?
19:49 < tibbs> | FESCO may be asked to step in for conflicts, but without rules any decision will be treated as arbitrary.
19:50 * | thl needs to leave soon
19:50 < jima> | the process should probably be listed someplace (as warren said)
19:50 < warren> | I'll just write it down.
19:50 < thl> | warren, thx
19:50 < warren> | It is pretty clear to me, and it worked more than once.
19:50 * | jima stops interfering with the swift passage of the meeting.
19:50 --- | thl has changed the topic to: FESCO meeting -- Free discussion
19:50 <-- | Foolish has quit (Read error: 104 (Connection reset by peer))
19:51 < thl> | anything else the needs to be discussed?
19:51 < jima> | thl: crap. now you're never gonna get out of here. ;)
19:51 < nirik> | anyone have thoughts on the muse/emacs namespace issues?
19:51 < XulChris> | when can we vote for fesco members?
19:51 < XulChris> | sorry if this was already discussed
19:51 < skvidal> | what do people think about multiple maintainers for a single package?
19:51 < skvidal> | either per-branch or just in general?
19:51 < thl> | XulChris, when the voting system is ready
19:51 < thl> | skvidal, we need co-maintainership
19:51 < skvidal> | ie: maintainer1 takes care of fc4 and f3, maintainer2 takes care of fc5
19:51 < che> | skvidal, good idea
19:51 < skvidal> | thl: is there anything stopping it?
19:52 < skvidal> | thl: any roadblocks we need to clear?
19:52 < thl> | skvidal, lack of a proposal how to do it exactly
19:52 < thl> | and support in owners.list
19:52 < thl> | guys, sorry, I have to leave now
19:52 < scop> | just use initial cc in owners.list
19:52 < nirik> | in reguards to emacsen/muse, proposal from jonathan: http://www.redhat.com/archives/fedora-extras-list/2006-May/msg00297.html
19:52 < thl> | warren, can you handle the rest of the meeting please?
19:52 < che> | skvidal, id even say that it should be mandatory to have atleast 2
19:52 < tibbs> | Sponsorship needed for co-maintainers?
19:52 < skvidal> | okay so we need a mutliple-maintainers porposal and owner's list needs to be less crappy
19:52 < jwb> | skvidal, scop and i are already doing it
19:52 < che> | skvidal, what if one goes on holidays?
19:52 < jpo> | warren: can we still access the fedora.us tickets?
19:52 < skvidal> | che: I like holidays
19:53 < jima> | tibbs: err, they're contributors, so i'd think they'd need to be sponsored.
19:53 < che> | skvidal, me too... but what about updates/security patches etc
19:53 < skvidal> | I like holidays
19:53 < jima> | thl: have fun/good luck/whatever. :)
19:53 < jima> | i think everyone likes holidays.
19:53 < warren> | jpo, I'm wanting to archive the fedora.us tickets in static pages at the same URL, I need some help to do this.
19:53 < warren> | hoping noa will help, because he originally setup fedora.us bugzilla =)
19:53 < che> | skvidal, also you got a 4 eyes principle then for new builds
19:53 < che> | skvidal, cant hurt either
19:54 < jpo> | I was trying to find a couple of perl-Net-SSLeay tickets
19:54 * | thl afk now
19:54 < noa> | warren, I'll have a look at that that in a few days
19:54 < ixs> | warren: the bugzilla system is still running? small shellscript with wget and sed should be able to mirror that. Friend of mine did this many months back...
19:54 < jpo> | Help needed?
19:55 < skvidal> | che: I don't disagree - but I think requiring it for every package would be onerous
19:56 < che> | skvidal, well for every small packaged script it would be overhead probably.
19:56 < ixs> | skvidal: not to mention that it would probably mean too much work.
19:56 < che> | skvidal, for complex things -> defnitely.
19:57 < jpo> | warren: mail me if you need help to export the tickets
19:57 < che> | skvidal, also what if someone stops maintaining it... because of time reasons e.g.
19:57 --> | cwickert (Christoph Wickert) has joined #fedora-extras
19:57 < skvidal> | che: then they orphan it
19:57 < warren> | jpo, ok, I'll mail you and noa
19:57 < che> | skvidal, it would take some time for someone else to get into it etc... it would take time to find a new maintainer etc.
19:57 --> | Foolish (Sindre Pedersen Bjordal) has joined #fedora-extras
19:57 < che> | skvidal, yeah... means its hanging around without updates and still gets built...
19:57 < che> | skvidal, dont think thats a really good approach though
19:57 < skvidal> | che: but nevertheless - I'd like to work to remove the roadblocks to multiple pkg owners
19:57 < skvidal> | so I'll see what I can do to get us a proposal and layout for owners.list
19:58 < scop> | can anyone identify those roadblocks?
19:58 < jpo> | warren: another problem
19:58 < jpo> | it is not possible to CC the fedora-security mailing list from bugzilla
19:58 < jwb> | skvidal, scop and i are already doing it
19:58 < che> | skvidal, good luck on it. i basically only see "pro"
19:58 < jwb> | skvidal, so what roadblocks?
19:58 < skvidal> | jwb: making it official
19:58 < warren> | jpo, who has admin access to the list?
19:59 < tibbs> | jpo: I asked about that yesterday on fedora-security-list but haven't seen a response yet.
19:59 < warren> | jpo, the list admin can create a bugzilla account without that admin mail hitting the list. He can read it in the moderation queue.
19:59 < warren> | jpo, only after the account is created can the list be added CC.
19:59 < jpo> | tibbs: I saw the archives a couple of minutes ago
19:59 < jpo> | warren: thks
20:00 < jwb> | thl, as far as the voting system goes... i have yet to hear anything back from Sopwith
20:00 < tibbs> | Anyone interested in writing PHP/PEAR packaging guidelines?
20:00 < jwb> | step 1) don't do it
20:00 * | jwb kids
20:01 < scop> | :)
20:01 < tibbs> | Several modules up for review, but lack of guidelines makes it tough to do a reasonable review.
20:01 * | jima doesn't volunteer
20:01 < XulChris> | php-pear > perl-* ;-)
20:01 < jima> | mainly because i don't especially care for php. :P
20:01 <-- | Anvil has quit (Remote closed the connection)
20:01 < XulChris> | maybe send an email to f-e-l about it?
20:01 < warren> | I move that we close this meeting.
20:01 < jwb> | seconded
20:01 < tibbs> | Nothing for me to add.
20:01 < ixs> | tibbs: php-review is a bitch. I tried doing a review of php-pear-mailparse but gave up as there are way too many different opinions of "ho to do it right"(tm)
20:02 --> | Anvil (Dona Nobis Pacem E Dona Eis Requiem) has joined #fedora-extras
20:02 < abadger1999> | (10:52:27) nirik: in reguards to emacsen/muse, proposal from jonathan: http://www.redhat.com/archives/fedora-extras-list/2006-May/msg00297.html
20:02 < RemiFedora> | hi tibbs, i'm the "remi.collet" who submit this php-pear*.rpm
20:02 < abadger1999> | Did anyone have any comments on this?
20:02 < warren> | Meeting End.
20:02 < nirik> | abadger1999: we can possibly get it on the adgenda for next week?
20:02 < ixs> | tibbs: there are several possible ways of packaging the php stuff, I'd volunteer to work on guidelines if I'm supported by some other people.
20:02 < abadger1999> | nirik: Sounds god.
20:02 < tibbs> | emacsen-* seems distasteful, but I don't see how any proposal could be much better.
20:03 < jima> | ...and so Typo Hour in #fedora-extras begins.
20:03 < tibbs> | ixs: I'm willing to help a bit, but I'm no PHP expert.
20:03 < nirik> | yeah, I think emacsen is the best we can do...
20:03 < cweyl> | ixs: I'll be happy to lend a hand
20:03 < abadger1999> | tibbs: yeah... Debian has an emacsen-common for files shared between xemacs and emacs....
20:03 < XulChris> | is there a php SIG?
20:03 < ixs> | tibbs: Great. Then I'll just put on the php-expert hat. ;-D
20:03 < ixs> | tibbs: anyone else?
20:03 < jpo> | scop: if you have a couple of minutes could you browse ticket #191351
20:04 < nirik> | of course that doesn't solve the muse issue... since there are potentially 2 other projects called that that could be packaged.
20:04 < nirik> | but it gets the emacsen one out of the way at least. :)
20:04 < scop> | jpo, will take a look tonight
20:04 < ixs> | XulChris: no php sig yet.
20:04 < jpo> | scop: thanks
20:04 --> | blippie (Noa Resare) has joined #fedora-extras
20:05 < scop> | I wonder if the bugzilla component name == srpm name rule is carved in stone
20:05 < ixs> | scop: it's been that way in the past. changing it sounds like a bad idea.
20:05 < ixs> | how else is one supposed to gather the component name from the rpm?
20:06 < ixs> | rpm -qi foo gives you the souce rpm name aka the component.
20:06 < scop> | I was more like thinking there could be both emacs-muse and xemacs-muse components in bugzilla
20:07 < scop> | if people are worried that xemacs-muse users can't find the emacs-muse component
20:07 < |Jef|> | scop: ill let you do that.. if we also have a component for each -devel subpackage too!
20:07 < warren> | We had talked about sub-package names being components in Bugzilla before.
20:07 < warren> | But I don't think it is a good idea.
20:07 < scop> | |Jef|, *I* am not worried about that
20:08 < warren> | |Jef|, each debuginfo package too =)
20:08 < |Jef|> | warren: sweet
20:08 < |Jef|> | warren: i wonder what bugzilla's limit is for component list length?
20:09 < |Jef|> | scop: i think its pretty silly to break that rule for xemacs subpackages... if it doesn't make sense to break that rule more generally
20:09 < scop> | what I find odd is that "emacs-muse" wouldn't work just fine as the component (and SRPM) name, but yet another one, emacsen-muse has to be invented
20:09 < scop> | |Jef|, I agree
20:09 < warren> | |Jef|, I'm not sure we want to make bugzilla go slower than it already does =)
20:10 < |Jef|> | warren: can it?
20:10 < blippie> | no, the low speed limit has been reached
20:10 < warren> | scop, I supported emacs-muse personally.
20:10 < nirik> | the name 'emacs' is kinda overloaded tho... most people think of gnu-emacs then... or at least I do... not the generic emacs term...
20:10 < ixs> | personally, I think emacsen sounds stupid.
20:10 < ixs> | why not name it foomacsfoo-muse. ;-D
20:11 <-- | has quit (Remote closed the connection)
20:13 < tibbs> | ixs: we can just start a wiki page for packaging guidelines.
20:13 < ixs> | tibbs: wiki/extras/PHPPackagingGuidelines
20:14 < ixs> | something like that?
20:14 < tibbs> | Probably wiki/Packaging/PHP to match Packaging/Perl and Packaging/Python
20:15 < ixs> | hmmm. sounds reasonable.
20:17 < ixs> | http://fedoraproject.org/wiki/Packaging/PHP done
20:17 < RemiFedora> | if i can. I think a great job have already be done on php-* rpm
20:17 --> | che_ (Che Guevara) has joined #fedora-extras
20:18 <-- | che has quit (Nick collision from services.)
20:18 < ixs> | RemiFedora: Your input would be greatly appreciated. Problem is, as I said above, there are way too many opinions on packaging php stuff, as can be seen on your review bugs.
20:18 --- | che_ is now known as che
20:18 < RemiFedora> | On bug 19066, 190252, 183359, 185423
20:19 < RemiFedora> | yes, i agree for the need of a guidelines. Buf for example, the use of /usr/share/pear/.pkgxml is now in the "core" php-pear.
20:22 < scop> | jpo, still here?
20:22 < jpo> | yes
20:22 < scop> | I'm wondering what kind of input are you looking for for the Net-SSLeay issue?
20:23 < dgilmore> | jpo i was wondering that also
20:23 < jpo> | A second opinion
20:24 < jpo> | if I should apply the patch to 1.26
20:24 < tibbs> | Is the patch destabilizing in some way, or does it break compatibility?
20:24 < jpo> | I don't think so (but have to look again)
20:25 < dgilmore> | jpo: do you have a bug# or the patch somewhere?
20:25 < scop> | https://bugzilla.redhat.com/191351
20:25 < jpo> | in the FC-5 and devel SRPM
20:27 < dgilmore> | jpo: cool i had only seen the email posted about it to fedora-security
20:28 < jpo> | I will try to ping the current module maintainer about it
20:28 < scop> | so the issue is that if $EGD_PATH is not defined in the environment, SSLeay reads some "entropy" from /tmp/entropy
20:28 <-- | noa has quit ("Leaving")
20:28 --- | blippie is now known as noa
20:28 < scop> | ...which can be created by anyone, thus injecting some known data into the seeding process
20:29 < scop> | ...right?
20:29 < jpo> | yep
20:29 < dgilmore> | scop: thats what it looks like to me
20:30 < scop> | see man RAND_egd (if you have openssl installed)
20:30 --> | Belegdol (Julian Sikorski) has joined #fedora-extras
20:30 < scop> | "On systems without /dev/*random devices providing entropy from the kernel, the EGD entropy gathering daemon can be used to collect entropy."
20:30 < scop> | also openssl FAQ:
20:31 <-- | Belegdol has quit (Read error: 104 (Connection reset by peer))
20:31 --> | Belegdol (Julian Sikorski) has joined #fedora-extras
20:31 < scop> | "On systems without /dev/urandom and /dev/random, it is a good idea to use the Entropy Gathering Demon (EGD) ..."
20:31 < scop> | so the patch looks innocent enough to me
20:34 < jpo> | I will try to apply it to the FC-3 and FC-4 branches
20:34 < Belegdol> | hi. what rpm targets can be installed in i386 fedora?
20:35 < Belegdol> | i was able to install i686, but unable to install pentium4
20:35 < jpo> | sould I worry about old fedora.us FC-1 and FC-2 branches?
20:35 < jpo> | s/sould/should/
20:35 < che> | Belegdol, rpm --eval %configure
20:35 < dgilmore> | jpo: looks ok to me the only othere way to do it would be to start the egd daemon with its socket at /tmp/entropy
20:36 < che> | Belegdol, thats what happens if you dont specify a target
20:36 < dgilmore> | jpo: ask warren but i dont think there is anyway to build and get the updates out
20:36 < jpo> | ok
20:36 --> | homeas (Thomas Vander Stichele) has joined #fedora-extras
20:36 < dgilmore> | skvidal: does the extras build system handle fc1 and fc2?
20:37 < scop> | dgilmore, ne
20:37 < skvidal> | nope
20:37 < scop> | s/ne/no/
20:37 < warren> | jpo, don't worry about FC-1 and FC-2
20:37 < jpo> | thanks.