Re: [gentoo-dev] Unmasking modular X
Ciaran McCreesh wrote: > On Mon, 23 Jan 2006 23:06:12 -0800 Donnie Berkholz > <[EMAIL PROTECTED]> wrote: > | Here's my proposal for dealing with modular X entering ~arch. > > What's wrong with the original idea of just making any unported ebuild > pull in all of modular X (minus drivers)? Yes, it means that some > people will pick up unnecessary deps until all packages are ported, but > it avoids anyone having to see flashy red errors. The problem with that is that it removes all motivation to ever port the packages. They'll just stay that way forever, where forever means "until I threaten to remove that from the virtual," in which case we'll be in the same scenario we are now. Why? Because people have better things to do than fix stuff that isn't broken. Donnie signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Unmasking modular X
On Mon, 23 Jan 2006 23:06:12 -0800 Donnie Berkholz <[EMAIL PROTECTED]> wrote: | Here's my proposal for dealing with modular X entering ~arch. What's wrong with the original idea of just making any unported ebuild pull in all of modular X (minus drivers)? Yes, it means that some people will pick up unnecessary deps until all packages are ported, but it avoids anyone having to see flashy red errors. -- Ciaran McCreesh : Gentoo Developer (King of all Londinium) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
[gentoo-dev] Unmasking modular X
Here's my proposal for dealing with modular X entering ~arch. Yes, some packages are going to break. But I intend to keep this to a minimum on packages people care about, as measured by the existence of an open porting bug. So here's my plan: Before modular X enters ~arch, I will ensure that all porting bugs blocking #112675 are closed. As new bugs are filed, I will ensure that they are closed within 2 days, giving their maintainers that long to respond and close it themselves. After 2 days, I, or other members of the x11 team and any volunteers, will jump in and fix it ourselves. Earlier tonight, I discussed with halcy0n our differing opinions of the need for modular X to enter ~arch and break trees for some ~arch users. In my opinion, this is acceptable and beneficial, as ~arch users should already be those willing to help out. It will assist in learning which of the still-unported apps are actually in use and help compile a possible list of tree removal candidates. halcy0n, on the other hand, feels that any breakage of the ~arch tree is anathema. Please contact me if you'd like to be one of these volunteers. Requirements: A) You have commit access to gentoo-x86, AND B) you're comfortable with the porting process OR are adept with ebuilds and would like to help It's my earnest hope that this proposal makes everyone happy, because I refuse to let modular X get old and rusty in package.mask while hundreds of unmaintained (or undermaintained, for whatever reason) applications hold it back. Thanks, Donnie signature.asc Description: OpenPGP digital signature
Re: "Environement categories" (was Re: [gentoo-dev] fix binary debug support, part elevenity billion 1/2)
On Mon, Jan 23, 2006 at 07:28:05PM +0100, Danny van Dyk wrote:
> Donnie Berkholz schrieb:
> | Marius Mauch wrote:
> |>I meant the option is redundant if it just triggers a feature setting,
> |>as it's the same as `FEATURES=debug-build emerge foo`
> |
> | OK, where's my package.features and packages.cflags files then? I can do
> | what I want through Mike's proposal, which is to build a specific
> | collection of packages with debugging. I also don't need to duplicate
> | the same list of packages in one file with FEATURES=nostrip and in
> | another with debugging CFLAGS.
>
> I'd love to have one package.env (or similarly named) file that can set
> environmental options on a per-package-base. This is just a proposal,
> but i personally would like it this way:
>
> # First define a category of environmental options:
> stable=( \
> "ACCEPT_KEYWORDS=\"arch\"" \
> "CFLAGS=\"-pipe -O -march=foo\"" \
> )
We've already got package.keywords...
Not saying it's the best, but muddying up the existing configuration
with N ways of saying the same thing imo isn't the sanest.
> debug=( \
> "FEATURES=\"debug-build keepwork\"" \
And there is the kicker. Portage has globals, which are in various
states of use- most of the features you're looking to tweak *are*
effectively globals already.
So... you need seperate configuration instances. This gets ugly since
not all code uses a passed in config instance, some falls back to
global access (just the same as not all code uses passed in dbapi's,
they use the global portage.db).
The config representation does a nasty little dance where it pushes
changes on, then pops them (moreso it just flat out regenerates the
settings)- extending usage of that really isn't a good thing imo,
since it's fundamentally the wrong design. Hell, such an approach
won't fly anyways for any real possibility of threaded execution
(parallel-fetch doesn't count, it's a fork for exactly this reason).
See where I'm going with this, and why the portage crew occasionally
make reference to design flaws? :)
Might I suggest this one just get shelved for a while? I'm not much
for spanky's proposal from an implementation side of things, but it
skirts the areas I'm concerned about (thus I'm mostly neutral on it),
but varying all configuration data per node is a whole different beast
from spanky's proposal- it's not skirting the areas that are icky.
Realistically, need to design the bugger so configuration data is
pushed down to each level/abstraction rather then a global obj; do
that, and it's easy to vary settings per node; rewrite is designed
this way, just not finished.
Personally, I'd rather revisit this a few months down the line- right
now it's too nasty of a hack to even consider it in stable.
> This proposed format could even be more easily parsed when split into to
> files. One file to define the categories and one to define the
> package-to-category bindings. The first file would be pure bash and
> could be loaded like this:
>
> mycat=$(
> . ${CATEGORY_FILE}
> cat=${!cat}
> for i in $(seq 0 $(( [EMAIL PROTECTED] - 1)) ) ; do
> echo -e "${cat[${i}]}"
> done
> )
Bash side overrides are a no go; either the resolver would have to
spawn a shell instance for processing each node, or portage would have
to know how to parse and execute shell (hard... very hard).
So... at least the bash side of it, not really doable imo. Same
reason you can't use bashrc to affect features (for the most part),
by the time that code is executed it's too late in the game.
~harring
pgpZMabwXoRwB.pgp
Description: PGP signature
Re: [gentoo-dev] coreutils: deprecated behavior not so deprecated
On Mon, 23 Jan 2006 23:04:48 -0500 Mike Frysinger <[EMAIL PROTECTED]> wrote: | as a heads up, the next version of coreutils i add to portage (5.93) | drops support for all those options upstream had labeled before as | simply "deprecated" ... this isnt a patch i'm adding or not adding, | upstream finally cut out all the code with these latest releases Pretty much the same issue for findutils-4.3. You'll have to get the argument order correct and remember to include the path. -- Ciaran McCreesh : Gentoo Developer (King of all Londinium) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
[gentoo-dev] coreutils: deprecated behavior not so deprecated
as a heads up, the next version of coreutils i add to portage (5.93) drops support for all those options upstream had labeled before as simply "deprecated" ... this isnt a patch i'm adding or not adding, upstream finally cut out all the code with these latest releases for those who dont know what i'm talking about, consider: tail -1 head -1 these things wont work anymore ... you had your warn time, now get over it note: for those who think they can argue for support of these features to be kept in Gentoo, you're barking up the wrong tree so dont waste your time -mike -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] [POLL] portage-2.1 USE flag ordering
Hi all, I've started a poll on the specific question of USE flag ordering in portage-2.1_pre3 at http://forums.gentoo.org/viewtopic-t-426033.html The result of the poll will pretty much dictate what will happen in the next release so if you'd like to go over and cast your vote... :) There's also a more general poll at http://forums.gentoo.org/viewtopic-t-423275.html which also allows further discussion if anybody is wanting to offer detailed opinions. Thanks in advance. -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: "Environement categories" (was Re: [gentoo-dev] fix binary debug support, part elevenity billion 1/2)
On Monday 23 January 2006 13:28, Danny van Dyk wrote: > I'd love to have one package.env (or similarly named) file that can set > environmental options on a per-package-base. i thought this was already implemented -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] New developer: Patrick Mclean
On Mon, 2006-01-23 at 11:21 -0600, Mike Doty wrote: > > Please take a moment to welcome our newest developer, chutzpah. > Patrick > joins us to help the sound and AMD64 herds. Congratz Patrick! -- Homer Parker Gentoo/AMD64 Team Gentoo/AMD64 Arch Tester Strategic Lead Gentoo Developer Relations [EMAIL PROTECTED] -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] New developer: Patrick Mclean
Mike Doty wrote: > Please take a moment to welcome our newest developer, chutzpah. Patrick > joins us to help the sound and AMD64 herds. Welcome and good work! -- Sandro (Sanchan) -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: RFC - new category dev-tos
The new category dev-tinyos is now in portage. If somebody is interested in having all the ebuilds related to TinyOS in portage, please feel free to follow bug# 78908 and its bloker bugs. Actually I'm focusing on bug #98662 and #101663, the ebuilds for these 2 bugs doesn't satisfy me, any idea on how to manage these 2 ebuilds is welcome. -- Sandro (Sanchan) -- gentoo-dev@gentoo.org mailing list
"Environement categories" (was Re: [gentoo-dev] fix binary debug support, part elevenity billion 1/2)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
[Please excuse the improper naming for this subject. I'll take any
suggestions to improve it :-) ]
Donnie Berkholz schrieb:
| Marius Mauch wrote:
|>I meant the option is redundant if it just triggers a feature setting,
|>as it's the same as `FEATURES=debug-build emerge foo`
|
| OK, where's my package.features and packages.cflags files then? I can do
| what I want through Mike's proposal, which is to build a specific
| collection of packages with debugging. I also don't need to duplicate
| the same list of packages in one file with FEATURES=nostrip and in
| another with debugging CFLAGS.
I'd love to have one package.env (or similarly named) file that can set
environmental options on a per-package-base. This is just a proposal,
but i personally would like it this way:
# First define a category of environmental options:
stable=( \
"ACCEPT_KEYWORDS=\"arch\"" \
"CFLAGS=\"-pipe -O -march=foo\"" \
)
debug=( \
"FEATURES=\"debug-build keepwork\"" \
"CFLAGS=\"-pipe -O0 -ggdb\"" \
)
# then tell portage to use a env-category for certain packages:
app-foo/totallybroken debug
=app-bar/anotherbrokenpkg debug
# Also, system packages should get their own category that would
# be used by default on them.
system=( \
"ACCEPT_KEYWORDS=\"arch\"" \
"FEATURES=\"buildpkg\"" \
)
This proposed format could even be more easily parsed when split into to
files. One file to define the categories and one to define the
package-to-category bindings. The first file would be pure bash and
could be loaded like this:
mycat=$(
. ${CATEGORY_FILE}
cat=${!cat}
for i in $(seq 0 $(( [EMAIL PROTECTED] - 1)) ) ; do
echo -e "${cat[${i}]}"
done
)
Comments? Please keep in mind that the code snippets here are just
proof-of-concept code and not meant literally!
Danny
- --
Danny van Dyk <[EMAIL PROTECTED]>
Gentoo/AMD64 Project, Gentoo Scientific Project
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (GNU/Linux)
iD8DBQFD1SA1aVNL8NrtU6IRAn/eAKCl2VcCAayy6TgsU3voRZvd+JQtOgCgpXNX
+9G+//2+O/DxhcSXXyMjE6w=
=LtXA
-END PGP SIGNATURE-
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] New developer: Patrick Mclean
On Monday 23 January 2006 18:56, Simon Stelling wrote: > (Not going to make a lame joke here, as I was the one who asked for a new > RESTRICT feature ;)) Well you did broke that RESTRICT already a few times :P -- Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/ Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpcMsJoRb3XN.pgp Description: PGP signature
Re: [gentoo-dev] New developer: Patrick Mclean
On Mon, 2006-01-23 at 11:21 -0600, Mike Doty wrote: > > Please take a moment to welcome our newest developer, chutzpah. Patrick > joins us to help the sound and AMD64 herds. > Congrats and welcome to amd64 and sound herds. -- Luis Medinas <[EMAIL PROTECTED]> http://dev.gentoo.org/~metalgod Gentoo Linux Developer: AMD64,Printing,Media-Optical,Sound -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] New developer: Patrick Mclean
Yo, welcome! (Not going to make a lame joke here, as I was the one who asked for a new RESTRICT feature ;)) -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] New developer: Patrick Mclean
Olivier Crete wrote: On Mon, 2006-23-01 at 11:21 -0600, Mike Doty wrote: I am currently working as a systems administrator for McGill University School of Computer Science, Montreal, Quebec, Canada. I live with my girlfriend in an apartment in the east of Montreal. Hey, I'm not longer the only one in Montreal! And we're what, 4 in Quebec now! I know of two more people in Quebec who are working on becoming devs too :) -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] New developer: Patrick Mclean
On Mon, Jan 23, 2006 at 12:34:47PM -0500, Olivier Crete wrote: > Hey, I'm not longer the only one in Montreal! And we're what, 4 in > Quebec now! Wow! That's like - 50 percent of the population there? ;) Welcome aboard, Patrick. ./Brix -- Henrik Brix Andersen <[EMAIL PROTECTED]> Gentoo Metadistribution | Mobile computing herd pgpIV57hS0fxW.pgp Description: PGP signature
Re: [gentoo-dev] New developer: Patrick Mclean
On Mon, 2006-23-01 at 11:21 -0600, Mike Doty wrote: > I am currently working as a systems administrator for McGill University > School of Computer Science, Montreal, Quebec, Canada. I live with my > girlfriend in an apartment in the east of Montreal. Hey, I'm not longer the only one in Montreal! And we're what, 4 in Quebec now! -- Olivier Crête [EMAIL PROTECTED] Gentoo Developer -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] New developer: Patrick Mclean
On Monday 23 January 2006 18:21, Mike Doty wrote: > Please take a moment to welcome our newest developer, chutzpah. Patrick > joins us to help the sound and AMD64 herds. Welcome Patrick... and now get to work! ;) Finally someone new in the sound team to give some bugs' share :P And he's also my doomed victim for ifp stuff, so that's really make this good news :D -- Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/ Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpGtMAsW7AJg.pgp Description: PGP signature
Re: [gentoo-dev] New developer: Patrick Mclean
Mike Doty wrote: I am currently working as a systems administrator for McGill University School of Computer Science, Montreal, Quebec, Canada. I live with my girlfriend in an apartment in the east of Montreal. Other than computers, my main hobbies are Downhill Skiing, reading and when I get a chance canoing and sailing." Girlfriend? Outdoor activities? What kind of geek are you? :) -- Andrew Gaffneyhttp://dev.gentoo.org/~agaffney/ Gentoo Linux Developer Installer Project -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] New developer: Patrick Mclean
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 All- Please take a moment to welcome our newest developer, chutzpah. Patrick joins us to help the sound and AMD64 herds. In his own words, "I was born and raised in Lennoxville, Quebec, Canada. I have a DEC (college diploma) in Computer Information Systems from Champlain College, Lennoxville and a BSc in Computer Science from Bishop's University in Lennoxville, QC, Canada. I am currently working as a systems administrator for McGill University School of Computer Science, Montreal, Quebec, Canada. I live with my girlfriend in an apartment in the east of Montreal. Other than computers, my main hobbies are Downhill Skiing, reading and when I get a chance canoing and sailing." - -- === Mike Doty [EMAIL PROTECTED] Gentoo/AMD64 Strategic Lead PGP Key: 0xA797C7A7 Gentoo Developer Relations ===GPG Fingerprint=== 0094 7F06 913E 78D6 F1BB 06BA D0AD D125 A797 C7A7 === -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFD1RCA0K3RJaeXx6cRAiV8AJwNydOKdYpEbwv2leAxG6NRmrkphgCfaomv gUIQmnwSzYehm9YfyUT4UJY= =P7nI -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] webapp.eclass documentation
Kalin KOZHUHAROV wrote: > 1. I can see this in many places of the Gentoo docs, so it is not specific > to this particular doc, but still: the CSS for span.code would better be > changed to use another color than the links. I very often catch myself > trying to click on it (e.g. I expected "man 5 webapp.eclass" to be a link to > the on-line man page; BTW that would not be a bad idea at all if it can be > kept in sync). > So if this is not supposed to be changed locally, (I see it is coming from > http://www.gentoo.org/css/main.css?d=20051010 ) whom shall I contact? Please use the gentoo-doc mailing list or #gentoo-doc at freenode or file a bug against Docs-user component on our Bugzilla. You might also want to check the new appearance on our redesign site (not in sync with the fresh contents) [1]. > 2. Consider this paragraph: [...] Submit a bug, please. > BTW, is there an easy way to get the source XML of this (and other) doc? So > I can send patches directly. Append "?passthru=1" to the end of the URL (or "&passthru=1" of the URL string already contains the "?" sign). See [2]. [1] http://wwwredesign.gentoo.org/ [2] http://www.gentoo.org/proj/en/gdp/doc/doc-tipsntricks.xml#doc_chap1 Cheers, -jkt -- cd /local/pub && more beer > /dev/mouth signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: packages without homepages
On Wednesday 11 January 2006 05:54, Duncan wrote: > Matthias Langer posted <[EMAIL PROTECTED]>, > > excerpted below, on Wed, 11 Jan 2006 05:08:31 +0100: > > After reading the response for bug 118607, which i filed, i was > > woundering if there isn't a more appropriate default procedure for > > packages with no homepages then just leaving the invalid > > 'homepage-link' alone ... Shouldn't there be a way to tell portage > > that a certain package simply doesn't have a homepage ? Matthias > > There was a recent thread on this, probably a month or two ago. > Various devs offered various suggestions, most of which they've been > using in packages they maintain. Apparently repoman complains if the > variable isn't there, so devs simply put "none" or "" or > "http://www.gentoo.org"; or their dev page address as the homepage. > Again, look around, you'll see these "solutions" and others, such as > leaving the stale address in place as in the case at hand. There's was > no single standard solution agreed to, as it appeared no one was > sufficiently interested to push one, figuring more important things, > like squashing real functionality bugs, was more important, with the > limited time every Gentoo dev has, being they are all volunteers. Better solution is to use something like the freshmeat directory, or if possible the directory of the webserver/ftp server where the packages get released. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpndu3qTPMQa.pgp Description: PGP signature
Re: [gentoo-dev] Projects and simple guides
On Tuesday 10 January 2006 19:44, Stuart Herbert wrote: > > Why not just let herds carry on creating entries under /proj/en/? If > they're part of a larger project, that project can just link to the > herd's page. Our directory structure doesn't have to reflect a > biological classification tree :) Because if they do so they probably are projects. Of course that means they just have an identity crisis, and should be allowed to go ahead while they seek help ;-) Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpKZVsiXDpgO.pgp Description: PGP signature
Re: [gentoo-dev] Projects and simple guides
On Tuesday 10 January 2006 16:09, Michael Cummings wrote: > I have to side with lance on this one (ouch) - i have some docs i'd > love to post for perl herd related stuff, but we are by no means a > project, nor do we fit nicely into anything. > > *sigh* now there's the story of my life in a nutshell... Why not have a nice perl maintenance project? You could even start subprojects that try to find things out and are abandoned when finished. Projects are not big things that should exist forever. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpolUhbNglYE.pgp Description: PGP signature
Re: [gentoo-dev] Projects and simple guides
On Tuesday 10 January 2006 15:20, Lance Albertson wrote: > Donnie Berkholz wrote: > > Lance Albertson wrote: > > | I understand the block was lifted for projects, but that doesn't > > | mean herds should all should fit underneath proj/. > > > > I agree. What I meant is that herds should be grouping together to > > form new projects if they don't fit in an existing one; not that they > > should create one project per herd. > > But herd != project. They are two distinct things. There are a couple > of cases where they both are the same, but others where it isn't. For > example, what project would netmon fit under? They aren't actively > trying to create a specific idea inside of gentoo. To me that's one > thing that defines a project from a herd. A herd mainly deals with > organizing a group of ebuilds. I don't see how you can label every herd > into a project. Actually, although most people apparently forgot or ignored it, herds are defined as just groups of ebuilds. Not groups of people (although it came to that). The idea about the herds.xml file was to connect it to bugzilla so that bugwranglers had an easier job. Projects are groups of people with a certain goal. Such a goal might be to maintain a herd of ebuilds. In that case they might have the same name. Other projects maintain multiple herds, or no herds at all (like the GDP, or infra). It is my opinion that every herd should be maintained by a project. (Possibly assisted by another project). Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgp5nzpH5YSkm.pgp Description: PGP signature
Re: [gentoo-dev] [GLEP] Manifest2 format
On Tue, 6 Dec 2005 17:04:53 +0100 Marius Mauch <[EMAIL PROTECTED]> wrote: > Hi, > > As promised here the GLEP for Manifest2 support: > http://www.gentoo.org/proj/en/glep/glep-0044.html > > This will NOT be voted upon the next council meeting on thursday ;) Ok, made a few minor corrections, mainly s/SRCURI/DISTFILE/ so people don't get confused about the underscore (and as someone pointed out those entries aren't uris anyway). I'd like to get this voted upon the next meeting. Marius -- Public Key at http://www.genone.de/info/gpg-key.pub In the beginning, there was nothing. And God said, 'Let there be Light.' And there was still nothing, but you could see a bit better. signature.asc Description: PGP signature
[gentoo-dev] Re: Duplicate licences
Peter Cech posted <[EMAIL PROTECTED]>, excerpted below, on Mon, 23 Jan 2006 01:00:11 +0100: > What leads you to believe the license texts distributed in portage tree > are legaly binding with respect to the packages? Each packgage carries > (or at least should carry) its license embeded inside. In my > understanding, licanse pointers in ebuilds are purely informative and > allow you to check the terms of the license (and decide if the license > is acceptable) before you actually perform any legaly binding action > (like running 'emerge app-foo/bar'). One of the legal issues involved is that Gentoo normally strips the COPYING or similar files that would normally come with the package and be placed in /usr/share/doc/. The idea is that one copy of the GPLv2 (for example) on the system is enough. Thus, what the package carries is stripped out in favor of the Gentoo placeholder version, and the question is whether that placeholder version is then satisfactory from a legal standpoint, or not. The points made to date indicate that the old timers tend to be comfortable with the current situation, but nobody has provided a satisfactory legal reference or opinion that justifies this position. Just because it's been done that way for some time doesn't mean it's legally correct, and that's what's worrying to some posters (myself included, altho I'm not a Gentoo dev). -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman in http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Find apps not ported to modular X
Donnie Berkholz wrote: > Yesterday's drop: 17 to 871. Not as impressive as Saturday, but not bad. Sorry, that's 917. So it dropped by 36. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Find apps not ported to modular X
Yesterday's drop: 17 to 871. Not as impressive as Saturday, but not bad. Progress graph: http://dev.gentoo.org/~spyderous/broken_modular/broken_modular_progress.png Latest list: http://dev.gentoo.org/~spyderous/broken_modular/broken_modular_maintainers.txt.20060122 Herds and individuals with 10 or more unported packages: 190 games 136 (no metadata) 110 none (individual maintainer) Of these, 20 also have no individual maintainer listed 83 desktop-dock 48 cjk 43 gnustep 35 desktop-wm 28 sci 20 xemacs 18 video 18 sound 18 vapier 15 media-tv 10 text-markup Documentation: http://www.gentoo.org/proj/en/desktop/x/x11/modular-x-howto.xml http://www.gentoo.org/proj/en/desktop/x/x11/porting-modular-x-howto.xml Metabug: http://bugs.gentoo.org/112675 If you can't figure out what needs to get done and you've already read the docs, feel free to ask on the list or ping me on IRC. Thanks, Donnie signature.asc Description: OpenPGP digital signature
