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
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.