[gentoo-dev] (no subject)
unsubscribe
Re: [gentoo-dev] EAPI and system packages
Alexey Shvetsov wrote: On Воскресенье 20 сентября 2009 11:47:30 Rémi Cardona wrote: Le 20/09/2009 02:31, Ryan Hill a écrit : If not, when can we drop support for old EAPIs? Your opinions please. Let's drop it now. We've waited long enough. Portage with EAPI=2 has been stable for more than a year. Rémi Yes its good idea to drop EAPI2 from tree, but we should provide a way to upgrade for people that don't upgrades recently. So we can: 1 create a portage snapshot 2 write mini how to about upgrade 3 then drop EAPI=0 and EAPI=1 from tree to simplify tree EAPI isn't a question of the portage so much as the packages. So long as there are no more EAPI=0 EAPI=1 ebuilds in the tree it could be discussed, though I think that removing it is 1. going to require lots of work 2. this reaps minimal benefit if it's even possible. Andrew Andrew
Re: [gentoo-dev] Re: package.mask or package.mask.d
Dale wrote: While I like your example, if this were to happen and a couple other things has been updated, like for example expat a while back and other similar update nightmares, wouldn't a reinstall be easier and most likely recommended anyway? I have seen this recommended and even made that recommendation on -user a few times. I would also do a reinstall on my own system if I had been gone for 6 months or more. With the updates coming pretty fast for most things, you would most likely recompile most everything on the system anyway. Save the configs and the world file and just start over from a very fresh stage tarball. It is good to look out for those braves souls that would try to update anyway but thought it worth a mention. Would upgrading be recommended? back to my hole Dale :-) :-) Guys, if your Gentoo install is 6 months old, you're screwed anyway. This should really be a non-issue. I just spent 2 days dealing with being 3.5 weeks out of date. Might have been quicker to re-install. Ooh well. Andrew
Re: [gentoo-dev] Major problems in the tree in the last month
Torsten Veller wrote: * Andrew D Kirch trel...@trelane.net: This should really be a non-issue. I just spent 2 days dealing with being 3.5 weeks out of date. To help us improve the user experience, what were the problems that cost you two days? The major problem was getting caught up in the 'kdeprefix' use flag. The time loss can basically be explained as: 1. compile kde 4.3 which eventually fails 12+ hours 2. eradicate kde 4.2 and 4.3, 4 or so hours 3. clean up the resulting mess in @world, 8 hours 4. compile kde 4.3 again 12+hours This on a dual p4 3ghz takes a bit of time sadly. I also ran into bug 280443 with XOrg (and have commented appropriately). It appears dbus specific files aren't going where they should, and HAL is kicking unhelpful errors. Andrew D Kirch Funtoo.org
Re: [gentoo-dev] Re: package.mask or package.mask.d
Dale wrote: I'm just not sure that portage should be s backward compatible as it appears to be now. Dale, It really doesn't have to, unless you're not running portage... in which case we have to wait on all package managers to implement every major feature change the others want. The result of this was PMS and EAPIs. These are an effort to define feature sets the PM's can agree on. Interestingly some package managers, or perhaps their developers, are louder and more abrasive than others. This is causing an overall reduction in the implementation speed of these EAPI's and quite a bit of confusion with 10.0, along with much wharrgarbl and FUD. It also consumed nearly the entire agenda of the previous Gentoo Council. Things are getting better though. Andrew D Kirch Funtoo.org
Re: [gentoo-dev] Major problems in the tree in the last month
Jorge Manuel B. S. Vicetto wrote: Andrew D Kirch wrote: Torsten Veller wrote: * Andrew D Kirch trel...@trelane.net: This should really be a non-issue. I just spent 2 days dealing with being 3.5 weeks out of date. To help us improve the user experience, what were the problems that cost you two days? The major problem was getting caught up in the 'kdeprefix' use flag. The time loss can basically be explained as: 1. compile kde 4.3 which eventually fails 12+ hours 2. eradicate kde 4.2 and 4.3, 4 or so hours 3. clean up the resulting mess in @world, 8 hours 4. compile kde 4.3 again 12+hours This on a dual p4 3ghz takes a bit of time sadly. I also ran into bug 280443 with XOrg (and have commented appropriately). It appears dbus specific files aren't going where they should, and HAL is kicking unhelpful errors. Andrew D Kirch Funtoo.org As the KDE team Lead and to explain the above, this was an unfortunate requirement for the KDE team to get KDE-4 in the road to be marked stable. We should have probably announced it better and warned users about it sooner. This only affected users running the testing tree or users that had already switched to KDE-4 and was required as KDE upstream doesn't support multiple installs in the same prefix and we had a few nasty issues with python bindings (not being able to slot them as they install files into site-dir) and there's a bug in the qt plugin loader that would make it load plugins from the wrong prefix[1]. [1] - http://forums.gentoo.org/viewtopic-t-708282.html - FAQ section It wasn't a big deal. Sadly KDE takes darn near forever to compile. (or at least seems like it). If you get into a situation where you compile it twice that's at least a day lost. Andrew
Re: [gentoo-dev] Re: RFC: Make 10.0 profiles EAPI-2 'compliant'
Tiziano Müller wrote: As you can see currently, most time is needed to implemente the features in portage. It therefore doesn't make sense to make the EAPI process even faster. On the other hand, I think it would make sense to have a separate group developing new EAPIs instead of the council. Cheers, Tiziano I agree with what's being said here. The previous council ran into a huge road block with EAPI and GLEP's. I think that EAPI's should be moved to the Portage herd, and GLEPs assigned as necessary until final approval or dissent is given by the council. This would hopefully reduce contention with GLEP's as has happened in the past, and put EAPI's closer to the devs who will implement them. Andrew D Kirch Funtoo.org
Re: [gentoo-dev] Re: RFC: Make 10.0 profiles EAPI-2 'compliant'
Ryan Hill wrote: On Fri, 21 Aug 2009 17:29:12 -0700 Chip Parker infowo...@gmail.com wrote: If you were building a house, and the blueprints had been signed off on calling for 1 meter high doors, but the builder had built in 2 meter high doors, would you then go back to the builder and require him to do something that makes those doors unusable for the vast majority of people entering the house? Package managers can implement whatever extra bells and whistles they like, but they still have to follow the spec. Your metaphor is flawed in that you're talking about a single house here. If it doesn't match the plan you do an as-built and file a deviation with the registrar. The situation here is more like if you build a hundred houses to code, and then one above code, and then change code to match the one house and bulldoze the rest for not meeting minimal requirements. You're punishing anyone who implements a package manager to spec if you keep changing the spec in incompatible ways. Right, this is called punishing innovation. It's a hobby of bureaucrats everywhere. It could also be said to be punishing excellence. We've had a lot of political systems which try to implement a design which weeds out both the mediocre, and the excellent, leaving us with the average all have been failures. The reason why they fail is that it is the above average who do the heaviest lifting. Andrew D Kirch Funtoo.org
Re: [gentoo-dev] Re: Re: Re: Re: RFC: Make 10.0 profiles EAPI-2 'compliant'
Steven J Long wrote: Rémi Cardona wrote: Le 18/08/2009 03:30, Steven J Long a écrit : [snip] Steven, This thread was dead for more than 4 days. Yet you pick it up and you try to pick a fight with Ciaran. No I was answering the points he made, specifically he gave the fact that something's not used in the tree as a reason not to put it in PMS. The prior mail about an alternative perspective on the process was about his continual digs at portage and its developers. You're right that much of it was more relevant to -project, but when I post there it gets ignored: http://archives.gentoo.org/gentoo-project/msg_6c82019575749b628de20de060149782.xml http://archives.gentoo.org/gentoo-project/msg_28e2659029951f7edeab10b01cd21d53.xml I think it's clear at this point that Ciaran was the wrong person to have in charge of the PMS or EAPI spec's despite his willingness to do the work.. I tried to talk to him about having Paludis support an extension of PMS which Portage already supported. His response was to DEMAND that portage change his behavior and throw warnings about this because it wasn't in the PMS (which I will note is an accurately acronym'd document). ttp://bugs.gentoo.org/show_bug.cgi?id=273261 The users simply don't care about this stuff, and throwing warnings at every user in the manner advocated is abuse. This sort of behavior simply needs to stop. Using bugs.gentoo.org to attack Funtoo, which utilizes Portage, in the manner which has been done usurps the Gentoo Council's authority, the Portage devs, Funtoo, and most importantly our ability to innovate. And hell, if we're not going to innovate, lets all please pack up and go home. Andrew D Kirch Funtoo Andrew D Kirch Funtoo.org
Re: [gentoo-dev] Re: Re: Re: Re: RFC: Make 10.0 profiles EAPI-2 'compliant'
Ciaran McCreesh wrote: On Thu, 20 Aug 2009 06:13:59 -0400 Andrew D Kirch trel...@trelane.net wrote: I look forward to seeing Funtoo's creation of EAPI funtoo-2. Obviously you don't get it. We aren't going to spend time writing this sort of spurious and unnecessary specification documents. The fact that this is even conscionable would be hugely concerning except for the fact that you are not a Gentoo dev. Nor do you, as I have proven, have standing to file such a bug as you are not on the council (even as an alternate), and the SOLE option for packages violating PMS per the council is a council vote to mask the package. I'm having a hard time reconciling the following: The warnings don't make it to the user. The warnings make sure developers catch the problem and fix it. And: Just do it unconditionally. We're talking the tree here, not user configuration files, so enforcing QA can only be a good thing. Portage should instead warn or error when this happens to prevent people from accidentally abusing this. Also: No. It's in direct violation of PMS, and only accidentally works with Portage until Portage is fixed. And: Portage should instead warn or error when this happens to prevent people from accidentally abusing this. Portage is a tool used by users, repoman is a tool used by developers for tree QA. Considering the zeal with which you are pushing this accidentally works with Portage until Portage is fixed, I believe a reasonable person is going to look at the b.g.o bug, and at the Paludis bug and realize that you're more interested in process than innovation, and that you simply don't care about throwing needless confusing warnings at users (indeed a prima facia examination of Paludis would seem to confirm this, and my concerns WRT Paludis and the development methods are well known). I think they'll also realize that throughout this process you've been less than honest, and a huge impairment to the work going on at Funtoo. Would someone who has access please resolve the bug as WONTFIX? Thanks. Andrew D Kirch Funtoo.org
Re: [gentoo-dev] Preparing profiles for EAPI 3 IUSE strictness
Ciaran McCreesh wrote: On Tue, 07 Jul 2009 02:08:01 -0400 Andrew D Kirch trel...@trelane.net wrote: Given that your stated intention is for Paludis to fail, and that opposing [me] and everything [I] do was an initiative [you] started only after careful consideration, I'll kindly ask you to stop randomly jumping out and flinging turds, since it adds nothing to the discussion at hand and only serves to make it harder for Gentoo to function as a community. [response censored by fmmcor and devrel] Andrew D Kirch Funtoo.org (though I'd note the timing of Ciaran's response is 5.5 hours after a clear Mea Culpa that I had misspoken) http://archives.gentoo.org/gentoo-dev/msg_ff98cc6ecb9054a2938d1379d2c78d1f.xml @ 09:24 http://archives.gentoo.org/gentoo-dev/msg_a933ccf75960bba6d0a133d64454ebff.xml @ 14:52
Re: [gentoo-dev] Re: Re: A Little Council Reform Anyone?
Ciaran McCreesh wrote: trelane ciaranm: I want Paludis to fail. It's unhealthy (or at least the loudest and most visible of it's devs are) for Gentoo. trelane lets be VERY clear on that point. So long as Paludis, and the culture it creates are unhealthy for Gentoo I want it to fail. trelane ciaranm: that's put in a manner that seems to be a somewhat knee-jerk reaction. It should be clear that opposing you and everything you do was an initiative I started only after careful consideration. Ciaran, you are killing Gentoo. You wrote a demonstrably error prone GLEP 39, then tried to exploit it to ram through GLEP 55, and you got caught. You've created a huge amount of red tape, needless bickering argument, and have utterly hamstrung every council ever convened. Ciaran, you will not be doing this again. So there is now a moral question, do I have the right to oppose Ciaran, Paludis, and everything he does? Certainly I do, especially since he has created many, myriad, and manifest arguments in the community (amazingly we're having one now, and I was drug into it). Do I have the right to voice this opinion? Certainly I do. Is the opinion correct? In my eyes yes. Note though the second sentence, as it is incredibly important. Ciaran insists on continuing to create red tape for Gentoo, it has created a recent and MAJOR incident in a council meeting which has created bent feelings, and totally hijacked the initiative of the council. Until this behavior stops I will oppose it publicly and loudly. I would also point you to the recent council vote, wherein dev-zero was ousted (see the major incident) and peper, who I think is a nice, sane guy in my dealings ended up dead last. This is of course because of his relationship with you Ciaran. Ciaran, you are perhaps the least politically capable person I've ever met. It is not possible for you to holdiin your head at the same time two divergent ideas. Your idea of pluralism is that everyone does things your way. Then when that doesn't happen you throw a temper tantrum. You sir, are killing Gentoo for these and many other reasons, and I demand that you stop, I will also unilaterally oppose you until you do. Andrew D Kirch Funtoo.org PS: Ciaran, Thank you for comparing me to Rush Limbaugh, I consider it a compliment.
Re: [gentoo-dev] Preparing profiles for EAPI 3 IUSE strictness
Ciaran, I've talked with the pkgcore people and they don't use the EAPI's (or PMS) in the first place. This essentially leaves you writing documents you're requiring for paludis support. As this seems to be mostly a PM issue, it should be taken elsewhere. To that end, here is a gentoo-portage-dev mailing list that is more appropriate for minor process issues such as those brought up below. I think that ending this discussion here and moving it over to a forum more appropriate to package manager development would reduce the temperature around your proposals and get them implemented (as Zac seems willing to do so). While I realize this is a general purpose mailing list, it is general purpose, and there is a mailing list specifically for portage development. Andrew Ciaran McCreesh wrote: *SNIP*
Re: [gentoo-dev] Preparing profiles for EAPI 3 IUSE strictness
Yeah, that was definately a misunderstanding of something bonzaikitten said. Mea culpa. Andrew Brian Harring wrote: On Tue, Jul 07, 2009 at 02:08:01AM -0400, Andrew D Kirch wrote: Ciaran, I've talked with the pkgcore people and they don't use the EAPI's (or PMS) in the first place. No clue who you talked to, but they weren't speaking for pkgcore- I speak for pkgcore pretty much solely. Pkgcore utilizes EAPIs- hell I added the original support to portage. Not sure what info you got fed, but it was a bit off. I think that ending this discussion here and moving it over to a forum more appropriate to package manager development would reduce the temperature around your proposals and get them implemented (as Zac seems willing to do so). I don't particularly care one way or another (subscribed to both MLs), just mostly correcting one large misstatement... ~harring
Re: [gentoo-dev] 2009 Council Elections
Ciaran McCreesh wrote: On Fri, 26 Jun 2009 12:04:14 +0530 Nirbheek Chauhan nirbh...@gentoo.org wrote: The spirit and the letter of the rules are clear: the electorate can vote in whoever they want, and council members can appoint whoever they want so long as no-one has multiple votes at any given meaning. GLEP 39 is very clear and explicit about all the restrictions. No one, and I mean no one (other than dev-zero apparently) wants you voting on anything. If your ties to GLEP's 54/55 are not sufficient to cause you a conflict of interests then your ties to exherbo do. I would not _ever_ be able to accept a proxy offer in good conscience because of my work on Funtoo. Your lack of integrity, followed by your bellicose attitude simply astounds me. dev-zero should not have offered, and I think there needs to be a discussion as to why he did. Ciaran, you should not EVER have accepted it. The council was right in throwing it out. This isn't hard, we don't need a whole new set of rules and amendments to glep 39, we need developers and participants with common sense. Your behavior disgusts me (though I can point out that this is a continuous problem rather than simply contained in this one incident.) Andrew D Kirch Funtoo
Re: [gentoo-dev] 2009 Council Elections
Benny Pedersen wrote: On Fri, June 26, 2009 03:13, Andrew D Kirch wrote: Please be quiet. why ?, maillists is imho made to be used in non silent mode else one could aswell argue to close it down Mailing lists he's been booted from twice for astroturfing and abuse. Andrew
Re: [gentoo-dev] 2009 Council Elections
Petteri Räty wrote: Nirbheek Chauhan wrote: On Fri, Jun 26, 2009 at 1:27 AM, Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Fri, 26 Jun 2009 01:20:09 +0530 Nirbheek Chauhan nirbh...@gentoo.org wrote: Allowing him to proxy in a council meeting is both disallowed (non-gentoo devs cannot be on the council) Please point to the rule that says that a non-developer cannot be on the Council, and please point to the rule that says that a Council member cannot appoint a non-developer as their proxy. I see no mention of either in GLEP 39, which only restricts voting of Council members to developers, and only restricts proxies to not having one person with multiple votes. Oh so you'll argue semantics now? The spirit of the rule is excessively clear. No non-gentoo-developer can be a member of council -- permanent, temporary, or proxy. If a council member can't find a gentoo developer to be their proxy, that says a lot about the council member. In any case, discussing this with you is completely m00t given my past experiences with discussions with you. -- ~Nirbheek Chauhan Actually, please read GLEP 39 and you will see that it doesn't restrict council members to developers only. Basically under the current rules I think it's technically right to be proxied by anyone. If you don't think being proxied by non developers is wise, don't vote for those council members next time. If we want to restrict the council to developers only, we should think about modifying GLEP 39 (which should be done via a vote among developers as that's they way 39 was agreed upon). Regards, Petteri I move that we elect George W Bush and Ciaran McCreesh Council Members For Life. Are these people serious? Andrew
Re: [gentoo-dev] Jun 11th, 2009 Council Meeting Format
Doug Goldstein wrote: All, The current council meetings have gotten completely out of hand for weeks meetings have become nothing more then a continuation of the senseless bicker-fest that have become the e-mail threads on GLEP54, GLEP55, and EAPI-3 without any real progress or sense coming of them. It's taken me a little bit to step up and put a stop to it but I fully intend on putting a stop to it. The point of the council meetings is to bring up a topic and decide on its merits whether it should be brought into the Gentoo Project or not. I quote from the first line of the Gentoo Council website: I would strongly advice that EAPI-3 and GLEP's 54/55 be dropped at least for the time being (at a minimum 90 days). The argument has left any trappings of merit or rational behind, and has replaced them with religion. As this is now a dogmatic issue a resolution cannot be reached at this time. We have all collectively failed the Gentoo Project since we have not been doing this for the past several weeks. Vigorous debate fails no one. Religious zealotry however fails us all. In recognizing that this is what's happening iwth EAPI-3, and GLEP's 54/55 is the first step towards moving on to a new and fair debate on these issues down the road. Andrew
Re: [gentoo-dev] `paludis --info' is not like `emerge --info'
Timothy Redaelli wrote: On Saturday 04 April 2009 18:12:09 Thilo Bangert wrote: 'guess'. Like how you have to guess what use flags are really being used for the package in question, because it doesn't tell you? i'd like to ask the developers of package managers to standardize this. having packagmanager --info be the same no matter who you like best is incredibly usefull. while we are at it, emerge --info output may or may not be made even more usefull... i think it's better to develop an emerge --info package like paludis --info package. Since it's better to have an ebuild-scope environment than a global one (for package.use/bashrc) I think it's best as a general rule to NEVER _EVER_ under any circumstances emulate paludis. Andrew
Re: [gentoo-dev] `paludis --info' is not like `emerge --info'
Andrew Gaffney wrote: Andrew D Kirch wrote: I think it's best as a general rule to NEVER _EVER_ under any circumstances emulate paludis. While I'm not personally a fan of paludis, it doesn't help anyone to post crap like that to any mailing list. Please take it elsewhere. Thanks. Why is it inappropriate to discuss the poor UI, and implementation of software we use especially in open source? Maybe if we're closed to valid argument against poor methodology we can fail like everyone else who develops closed minded (Debian) and closed source (long list here) software. Larry the Cow is deeply disappointed in you sir. Why is it not appropriate to note the prolonged damage that paludis and its associated personalities have done to the Gentoo community? This damage and resulting tree situation caused many to stop using Gentoo, myself included for a time. The diminished quality of the portage tree, and the open hostility of those involved with paludis caused injury to Gentoo, and it's reputation which is both significant and lasting. Why is it not appropriate to note that commandline arguments for paludis read like war and peace, and are a leading cause of repetitive stress injury in the open source community? And if a development mailing list where the merits of paludis and portage are being debated is not the correct forum to note the manifest shortcomings of one, then where is it? Andrew
Re: [gentoo-dev] `paludis --info' is not like `emerge --info'
Nirbheek Chauhan wrote: On Mon, Apr 6, 2009 at 9:19 AM, Andrew D Kirch trel...@trelane.net wrote: Why is it inappropriate to discuss the poor UI, and implementation of software we use especially in open source? Maybe if we're closed to valid argument against poor methodology we can fail like everyone else who develops closed minded (Debian) and closed source (long list here) software. Larry the Cow is deeply disappointed in you sir. Discuss, sure. Flamebait, no. If you flame, the other side gets a license to flame. Let's keep things civil, and restrict ourselves to technical critique. If you want things to prevent war, measure yourself with the same yardstick as you expect others to be. That will be all, Thank you. I reject the premise that war should always be prevented. I am however concerned that criticism where criticism is due is flame baiting. Andrew
[gentoo-dev] http://bugs.gentoo.org/show_bug.cgi?id=232084
I was looking to do a workaround on a per compiler basis.
I'm looking at toolchain-funcs.eclass, and specifically
${gcc-fullversion}. I've got a broken ebuild (dhcdbd) which requires
-U_FORTIFY_SOURCE to compile correctly with GCC 4.3.3. But reading
tells me that I should not use this eclass to set compiler settings
directly. Will this work, and other than the merit of the fix is there
a more desirable structure for such a solution?
inherit flag-o-matic toolchain-funcs
if [ ${gcc-fullversion} -eq 4.3.3 ] #(or whatever the 4.3.3
$gcc-fullversion} outputs)
then
append-flags -U_FORTIFY_SOURCE
fi
Thanks for the help.
Re: [gentoo-dev] The Plethora of Patches
Rémi Cardona wrote:
Andrew D Kirch wrote:
Obviously the software needs to work, and therefore we need patches, but
Gentoo has not done enough to date to get them pushed upstream. Lets
look at some cringeworthy statistics on outstanding patches.
Have you even _looked_ at the patches? Can you tell which ones are :
- backports?
- Gentoo-specific (for build issues)?
- shared with other distros?
Did you count the patches we apply because upstream is either dead,
unresponsive or downright wrong?
Yes, we have a lot of patches, but then again, we have a lot of open
bugs too. I, for one, am much more worried about the latter.
Please back this up with _real_ statistics.
Thanks
Rémi
Here's the script that I used to generate this. I have not manually
reviewed all of thousands of patches to determine the unique situation
of each patch, however I would like a suggestion on how to demonstrate
_real_ statistics short of auditing each and every patch in portage
which I personally don't have time to do.
for I in `ls`; do
PATCH=`ls -R ${I} | grep patch | wc -l`
DIFF=`ls -R ${I} | grep diff | wc -l`
COUNT=$(( ${PATCH} + ${DIFF} ))
if ! [ ${COUNT} == 0 ]
then
echo $I $COUNT
fi
done
Andrew
Re: [gentoo-dev] The Plethora of Patches
Denis Dupeyron wrote: On Thu, Aug 14, 2008 at 4:17 AM, Andrew D Kirch [EMAIL PROTECTED] wrote: [...] Looks like you counted the number of files in the files/ subdirectories. Not all of these are patches. Also, you probably forgot to count seds, as some of us use sed more than patches. Oh, and like Jeremy was hinting, please contact QA. They need somebody like you. Denis. How would one get ahold of this QA? Andrew
[gentoo-dev] The Plethora of Patches
It has become abundantly clear that distribution maintainers should have as few patches as possible. Patches waste time due to duplicate work, resources (portage disk space and bandwidth), and as the Debian project recently found out after a major vulnerability was discovered in the OpenSSH packages (see http://www.milw0rm.com/exploits/6094, and http://www.securityfocus.com/bid/30276 among others), they can become a source of great embarrassment, and liability since they are not nearly so well audited as code in heavily used mainstream projects (an unintentional Cathedral if you will). I therefore propose the following changes: Patches in the metadata.xml should have some sort of status tracking for each patch, repoman should flag any that don't, and warn on any that have not been submitted upstream unless the status is signed off on by a herd leader (such as Gentoo specific patches). This would provide visual feedback for users and developers with regard to a pretty important metric on how successful Gentoo is at getting patches pushed back to developers. Developers who consistantly clear a large quantity of patches upstream should also be recognized in the Gentoo Monthly Newsletter, and otherwise as appropriate. Obviously the software needs to work, and therefore we need patches, but Gentoo has not done enough to date to get them pushed upstream. Lets look at some cringeworthy statistics on outstanding patches. (NB these are only patches in portage, and not patches which don't meet portage's maximum size) app-accessibility 48 app-admin 178 app-antivirus 10 app-arch 101 app-backup 55 app-benchmarks 20 app-cdr 58 app-crypt 90 app-dicts 28 app-doc 26 app-editors 90 app-emacs 51 app-emulation 186 app-forensics 21 app-i18n77 app-laptop 23 app-misc 181 app-mobilephone 34 app-office 64 app-pda 50 app-portage 36 app-shells 91 app-text 334 app-vim 13 app-xemacs 4 dev-ada 1 dev-cpp 30 dev-db 141 dev-dotnet 27 dev-embedded17 dev-games 27 dev-haskell 12 dev-java 264 dev-lang 313 dev-libs 391 dev-lisp 112 dev-ml 15 dev-perl78 dev-php 6 dev-php511 dev-python 202 dev-ruby63 dev-scheme 37 dev-tcltk 33 dev-tex 24 dev-tinyos 3 dev-util 328 distfiles 26 eclass 21 games-action58 games-arcade76 games-board 58 games-emulation 88 games-engines8 games-fps 58 games-kids 9 games-misc 15 games-mud 19 games-puzzle65 games-roguelike 26 games-rpg 15 games-server 7 games-simulation14 games-sports17 games-strategy 54 games-util 31 gnome-base 45 gnome-extra 60 gnustep-apps22 gnustep-base 3 gnustep-libs 9 kde-base 146 kde-misc52 mail-client 71 mail-filter 49 mail-mta21 media-fonts 5 media-gfx 188 media-libs 494 media-plugins 273 media-radio 2 media-sound411 media-tv44 media-video253 metadata72 net-analyzer 213 net-dialup 121 net-dns 45 net-firewall33 net-fs 47 net-ftp 76 net-im 91 net-irc 68 net-libs 111 net-mail 113 net-misc 428 net-nds 11 net-news16 net-nntp21 net-p2p 67 net-print 49 net-proxy 53 net-voip 9 net-wireless89 net-www 14 net-zope 6 perl-core2 rox-base11 rox-extra6 sci-astronomy 32 sci-biology 32 sci-calculators 31 sci-chemistry 104 sci-electronics 21
