[gentoo-dev] Re: [RFC] Create a JOBS variable to replace -jX in MAKEOPTS

2008-12-05 Thread Diego 'Flameeyes' Pettenò
Peter Volkov [EMAIL PROTECTED] writes:

 This variable will be used in eclasses so it's better to avoid portage
 in it's name, since not only portage will work with it. GENTOO_JOBS is
 really something new in sense of consistency. EJOBS looks most terse for
 me but I'll be ok with any name...

It's just I don't want to end up colliding with other stuff like
EclipseJobs or something else.

And my reason to not propose PORTAGE_JOBS is actually that it suggests
relation with -j option to emerge rather than make ;)

 For load average may be it's good to use another variable to avoid
 overloading of JOBS meaning?

Agreed, easier than ending up having to parse a variable content, after
all environment variables are kinda cheap.

-- 
Diego Flameeyes Pettenò
http://blog.flameeyes.eu/


pgpymSA9M4q04.pgp
Description: PGP signature


[gentoo-dev] [RFC] Create a JOBS variable to replace -jX in MAKEOPTS

2008-12-04 Thread Diego 'Flameeyes' Pettenò

Since not all the buildsystem we support use make for the actual build,
and they don't necessarily support make-like options (-jX -s and so on),
it would be nice to be able to express a JOBS variable that could be
used for parallel build with any build systems.

Right now there are ebuilds like openoffice or some scons-based ebuilds
that parse MAKEOPTS and get out of that the number of jobs from the -j
option, but this is a) suboptimal b) error-prone.

One has to consider people might be using -l for parallel building too,
for which reasons I'd be suggesting doing something like this to make
the change transparent:

 - ebuilds using non-make build systems would use JOBS;
 - ebuilds using make builds systems would just use emake as usual;
 - Portage takes care, if JOBS is unset, to parse it out of MAKEOPTS;
 - if user has set JOBS but not MAKEOPTS this defaults to -j${JOBS};
 - if user has JOBS and MAKEOPTS, MAKEOPTS keeps the same (for -l).

The result is that you can finally combine -l with parallel build on
OpenOffice and other packages, with a fallback number of maximum jobs
instead of using load-based decisions.

-- 
Diego Flameeyes Pettenò
http://blog.flameeyes.eu/



pgpcOEYmHztqL.pgp
Description: PGP signature


[gentoo-dev] Re: [RFC] Create a JOBS variable to replace -jX in MAKEOPTS

2008-12-04 Thread Diego 'Flameeyes' Pettenò
Tiziano Müller [EMAIL PROTECTED] writes:

 What do you do for other build systems which also decide on load-basis
 how many jobs to run? Parse again?
 In that case I'd like to see a more abstract definition of how many
 jobs to run in parallel which gets translated to the correct
 make-options for emake and which is query'able either via a variable or
 a function (something like JOBS=load=0.7||max=3 maybe?).

If you can come up with a good enough syntax.

-- 
Diego Flameeyes Pettenò
http://blog.flameeyes.eu/


pgp0CultBim8Q.pgp
Description: PGP signature


[gentoo-dev] Re: [RFC] Create a JOBS variable to replace -jX in MAKEOPTS

2008-12-04 Thread Diego 'Flameeyes' Pettenò
Alec Warner [EMAIL PROTECTED] writes:

 Looks Good To Me, but I would prefix the JOBS variable with some sort
 of namespace (EJOBS, GENTOO_JOBS, etc.) to avoid conflicts with other
 systems that may use JOBS internally already (seems vaguely likely).

Good point, GENTOO_JOBS sounds good to me.

-- 
Diego Flameeyes Pettenò
http://blog.flameeyes.eu/


pgp8ZBisU9A7b.pgp
Description: PGP signature


[gentoo-dev] Re: [RFC] Moving HOMEPAGE out of ebuilds for the future

2008-12-02 Thread Diego 'Flameeyes' Pettenò
James Cloos [EMAIL PROTECTED] writes:

 Searching is an important reason for every package to specify its homepage.

And?

metadata.xml already contains data that eix and other software should be
able to search in (like longdescriptions), and having each package in
kde-base report http://www.kde.org/ as its homepage is kinda pointless
if you think about search, since that's not data, it's noise.

Which only adds to my point.

-- 
Diego Flameeyes Pettenò
http://blog.flameeyes.eu/


pgpS3fcWfM3UH.pgp
Description: PGP signature


[gentoo-dev] Re: [RFC] Moving HOMEPAGE out of ebuilds for the future

2008-12-01 Thread Diego 'Flameeyes' Pettenò
Alec Warner [EMAIL PROTECTED] writes:

 - Space savings.  Certainly your scheme may be smaller, but the XML
 tag overhead may eat into the savings.  You should do some estimates
 to show the community how much smaller the tree will be from this
 proposal.

Sorry but you lost me on any point you might have brought across since
after this I feel like you were trying to put words in my mouth.

Beside, if you really want to go down that road you should be counting
that beside ReiserFS with tail, I don't remember any other Linux FS that
has block smaller than 512bytes, which means that each file in metadata
cache is taking up much more than just its size in characters.

All your math is thus wrong.

-- 
Diego Flameeyes Pettenò
http://blog.flameeyes.eu/


pgpcFFtmtOt8h.pgp
Description: PGP signature


[gentoo-dev] Re: [RFC] Moving HOMEPAGE out of ebuilds for the future

2008-12-01 Thread Diego 'Flameeyes' Pettenò
Jan Kundrát [EMAIL PROTECTED] writes:

 But also the need to replicate http://www.kde.org/ to metadata.xml of
 all KDE split ebuilds -- right now, this is set by an eclass.

The usefulness of this is IMHO debatable; why not just writing it one
package (say kde-base/kde or kde-meta) and just there? Having each
mini-package express itself as having that as its homepage is not very
useful to me, but I guess it's debatable.

 - allows proper handling of packages lacking a HOMEPAGE;

 Could you elaborate a bit about how different is handling of an
 empty/uninitialized shell variable from an empty XML element?

That you can provide _other_ links beside an homepage, like
unmaintained, gentoo:userguide and stuff like that so that user
don't just get no homepage at all, and they are not misdirected by
homepage being http://www.gentoo.org/ or something.

 - users can check the metadata much more easily by just opening the xml
   file or interfacing to that rather than having to skim through the
   ebuild, the xml files are probably more user readable then ebuilds
   using multiple eclasses;

 Haven't we already agreed that accessing ebuilds/... directly is
 broken by design?

For a software sure, but as an user I am automatically brought to just
look at the files if I'm looking for the homepage of a package I know,
and seeing a metadata.xml file I'm more likely to look at that rather
than the metadata cache in /var/db/... .

And it's certainly more user-readable an XML file than HOMEPAGE with
depend-like syntax for labels and conditionals and whatever else seems
like Alec is proposing for EAPI=3

 - webapps like packages.gentoo.org would be able to display basic
   information without having to parse the ebuilds or the metadata cache.

 Except for the ebuilds which still use the old format (that is 100% of
 the tree right now)

This of course is meant as whenever this is fully implemented

-- 
Diego Flameeyes Pettenò
http://blog.flameeyes.eu/


pgpfOxlYEmqMh.pgp
Description: PGP signature


[gentoo-dev] Re: debug/release builds extensions/clarification proposal

2008-12-01 Thread Diego 'Flameeyes' Pettenò
Maciej Mrozowski [EMAIL PROTECTED] writes:

 - USE=debug is useless  when CFLAGS/LDFLAGS or FEATURES are not appropriate

What are you saying here? I'm afraid you're mistaken here.

For the most part, USE=debug means enable debug code paths, which for
lots of projects simply means enable assertions; there are packages
that take this as enable debug symbols too but I don't think that's
very valid since users might want debug code paths but not symbols and
vice-versa (I indeed have debug symbols bug no debug codepaths enabled).

Now just to make sure the common misconceptions don't hit again:

- -ggdb *does not have any runtime performance hit*; neither in
   execution time nor in memory usage; the debug sections are not mapped
   into memory at all; this is true for both non-stripped and split
   executables;
- -O0 is not always a good idea; beside bugs in packages concealed by
   -O1+ [1], there are some further points: missing registers on x86
   causes build failures, and if ( 0 ) cases are not optimised away,
   resulting in stuff like FFmpeg not to link properly since undefined
   references are not pruned away; this means that using -O0
   unconditionally for any package for debug is not really an option;

[1] http://blog.flameeyes.eu/2008/09/02/testing-the-corner-cases

-- 
Diego Flameeyes Pettenò
http://blog.flameeyes.eu/


pgpJ5ioEeo3pE.pgp
Description: PGP signature


[gentoo-dev] Re: [RFC] Moving HOMEPAGE out of ebuilds for the future

2008-12-01 Thread Diego 'Flameeyes' Pettenò
Alec Warner [EMAIL PROTECTED] writes:

 That being said I still don't see the usefulness here.

 You seem to think that using the existing APIs for this data is wrong,
 and I think the opposite, so I guess we will agree to disagree on this
 matter.

Yeah I still think that there is no point in requiring using of a
specific API when the same data can easily be available in a format that
is more or less parsable with ease in any modern (and non) programming
language.

Beside, I find expanding the HOMEPAGE syntax to allow more than one link
a bit ... overkill, if the same thing can be achieved in metadata.xml...

 Beside, if you really want to go down that road you should be counting
 that beside ReiserFS with tail, I don't remember any other Linux FS that
 has block smaller than 512bytes, which means that each file in metadata
 cache is taking up much more than just its size in characters.

 All your math is thus wrong.

 As was pointed out on IRC, UTF8 characters are not a fixed size,
 making my math even more wrong ;)

If we consider HOMEPAGE, the assumption that characters are fixed size
to 1 byte is good enough; URLs are usually encoded in pure ascii
character space for compatibility; while IDN would break that
assumption, we can't even assume that IDN is always available and so on.

For description maybe it's different because there is space there for
UTF-8 characters, but that's going to bring us even farthest than the
point.

-- 
Diego Flameeyes Pettenò
http://blog.flameeyes.eu/


pgpfg98QhGFq3.pgp
Description: PGP signature


[gentoo-dev] Re: Name change s/drac/ssuominen/ for people wondering.

2008-11-30 Thread Diego 'Flameeyes' Pettenò
Samuli Suominen [EMAIL PROTECTED] writes:

 This is for the people wondering who I am.

And there goes for people not knowing the realnames of colleagues I
guess ;)  I'm glad I started calling people by first name whenever I
write something :P

By the way, I really hope you feel better now, and I certainly
understand that sometimes when you hit the bottom you feel like changing
your appearence, which online is... your nick ;)

Keep it up and try to make it fun!

-- 
Diego E. Flameeyes Pettenò -- who recently legally changed his first name
http://blog.flameeyes.eu/


pgpfoekrffmOI.pgp
Description: PGP signature


[gentoo-dev] [RFC] Moving HOMEPAGE out of ebuilds for the future

2008-11-30 Thread Diego 'Flameeyes' Pettenò

I have a very quick proposal: why don't we move the packages' homepage
in metadata.xml (since it's usually unique for all the versions) and we
get rid of the variable for the next EAPI version?

This makes it easier to get the package's homepage for submitting bugs
upstream (you just do a single lookup for the metadata.xml file rather
than checking the ebuild; ensures that homepage changes don't get stale
for old revisions, avoids commits on old ebuilds for home page changes
(and thus changes that propagates on mirrors, and so on. It also makes
searching by homepage easier (a search program would take much less time
to parse XML that an ebuild).

I would propose an implementation of this that takes in consideration
also older proposals of having a way to specify upstream and
gentoo-specific information, something among the lines of this:

link type=homepagehttp://package.foobar.com/link
link type=bugtrackerhttp://package.foobar.com/bugs/link

and for gentoo-specific

link type=gentoo:devel title=foobar maintainer's
guidehttp://www.gentoo.org/proj/en/foo/foobar/link

link
type=gentoo:user title=foobar usage
guidehttp://www.gentoo.org/doc/en/foobar.xml/link

Please submit all comments, as long as they are not I don't like XML
or XML is the wrong answer and similar since the point here is not to
discuss the format of metadata but rather where to have it.

-- 
Diego Flameeyes Pettenò
http://blog.flameeyes.eu/



pgpKz8EqcCHvB.pgp
Description: PGP signature


[gentoo-dev] Re: [RFC] Moving HOMEPAGE out of ebuilds for the future

2008-11-30 Thread Diego 'Flameeyes' Pettenò
Jan Kundrát [EMAIL PROTECTED] writes:

 I believe the reason was that HOMEPAGE might change with new versions
 and that metadata.xml didn't (doesn't?) support version-specific data.

At least the maintainer and (iirc, at least that's how we proposed
it the first time around) flag tags support a restrict attribute.

But I really expect that as long as the package is the same, homepage is
unlikely to change with version; maybe with slot I guess, but even that
is debatable and somewhat rare I think.

-- 
Diego Flameeyes Pettenò
http://blog.flameeyes.eu/


pgpB5SH1b5Viy.pgp
Description: PGP signature


[gentoo-dev] Re: [RFC] Moving HOMEPAGE out of ebuilds for the future

2008-11-30 Thread Diego 'Flameeyes' Pettenò
[EMAIL PROTECTED] (Diego 'Flameeyes' Pettenò) writes:

 I have a very quick proposal: why don't we move the packages' homepage
 in metadata.xml (since it's usually unique for all the versions) and we
 get rid of the variable for the next EAPI version?

I forgot to say that this also addresses, for the future EAPI, the
problem of what to do with missing HOMEPAGE. We still have to find a
solution for that on the EAPI 0, 1 and 2 though since it's a bit of a
big problem when we point to domain squatters.

If it was feasible to just make missing HOMEPAGE a softfail for the
other three it would be even better.

-- 
Diego Flameeyes Pettenò
http://blog.flameeyes.eu/


pgp3NTn0n5kOR.pgp
Description: PGP signature


[gentoo-dev] Re: [RFC] Moving HOMEPAGE out of ebuilds for the future

2008-11-30 Thread Diego 'Flameeyes' Pettenò
Tobias Scherbaum [EMAIL PROTECTED] writes:

 But what about additional slot or version attributes like
 link type=homepage slot=1.4http://java.sun.com/j2se/1.4.2//link
 (or a version attribute)? If slot and version aren't specified they'd be
 interpreted as wildcards.

link type=homepage restrict=dev-java/sun-jdk:1.4

The restrict attribute exists already and it's better to reuse the same
code, isn't it?

-- 
Diego Flameeyes Pettenò
http://blog.flameeyes.eu/


pgpJJ5dlUYEV7.pgp
Description: PGP signature


[gentoo-dev] Re: [RFC] Moving HOMEPAGE out of ebuilds for the future

2008-11-30 Thread Diego 'Flameeyes' Pettenò
Tobias Scherbaum [EMAIL PROTECTED] writes:

 dev-java/sun-jdk unnecessarily. Reducing this to restrict=1.4 isn't
 easily readable as you'd need to know that restrict would specify a
 slot. If your plan is to make it easier to find useful information about
 a package (without using a fancy frontend, just reading the metadata.xml
 with $EDITOR) slot=1.4 (or a version attribute) might be a tad more
 human readable. 

Well if we go to these things we should just apply the same to the other
attributes using restrict, since we want to have something coherent,
don't we? ;)

-- 
Diego Flameeyes Pettenò
http://blog.flameeyes.eu/


pgpqrcOBdsryo.pgp
Description: PGP signature


[gentoo-dev] Re: [RFC] Moving HOMEPAGE out of ebuilds for the future

2008-11-30 Thread Diego 'Flameeyes' Pettenò
Alec Warner [EMAIL PROTECTED] writes:

 Diego, What are the concrete benefits of your proposal?

As I said:

- no need to replicate homepage data between versions; even though forks
  can change homepage, I would expect that to at worse split in two a
  package, or have to be different by slot, like Java;
- allows proper handling of packages lacking a HOMEPAGE;
- less data in metadata cache;
- users can check the metadata much more easily by just opening the xml
  file or interfacing to that rather than having to skim through the
  ebuild, the xml files are probably more user readable then ebuilds
  using multiple eclasses;
- displaying info about the package does not require parsing the full
  ebuild file, with its eclasses;
- extensible to provide more links than just the homepage (forums,
  trackers, gentoo-specific documentation, ...);
- if we also move DESCRIPTION, search software can ignore everything
  about ebuild parsing, and just use the metadata.xml files; considering
  how many people actually use or used eix, it would make sense to allow
  third-party applications to be able to search through the tree;
- webapps like packages.gentoo.org would be able to display basic
  information without having to parse the ebuilds or the metadata cache.
- as much as people might think metadata is easier to parse than
  anything, XML has one huge advantage: there are plently of parsers for
  any language without having to actually write one, even as easy as it
  can be, and it's easily interfaced with anything; I wrote a simple XSL
  file that outputs the basic metadata details for packages without
  having any parser or executable code but xsltproc (or any other XSLT
  software), correlating data with herds.xml too;
- it really is metadata, and it makes very little sense to need parsing
  of eclasses and EAPI handling to get some data from a package that is
  non-functional in nature and free form (just like DESCRIPTION, and
  unlike LICENSE like Alec said), and that changes at worse once each
  slot (unlike LICENSE that can change at any given version).

Disadvantages:

- it requires user-interface software to parse metadata.xml to show
  data for a package; which is already needed to show per-package USE
  flag meaning;

General points:

- it does not solve unrelated problems like code replication;

Can someone come up with any other point beside I don't like XML
(which I already said is a puny answer) and it can theorically be 10
different homepages for 10 different versions (which I have sincerely
some beef with myself since if you fork a software you might as well
change its name)?

As I said, moving out the HOMEPAGE field from a package manager
prospective is non functional; if you're showing to the user some data
about a package you might as well show as much as you can, like long
descriptions, other links, and USE flags. And the fact that you can ask
the package manager for something is for me not a valid reason to avoi
moving something in a more approchable place for other software.

-- 
Diego Flameeyes Pettenò
http://blog.flameeyes.eu/


pgpJevDGzJEf0.pgp
Description: PGP signature


[gentoo-dev] Please avoid absolute paths in patched filenames

2008-11-17 Thread Diego 'Flameeyes' Pettenò

I ask it here as a favour, please avoid using absolute paths in the
filenames of patched files. This mean avoid having stuff like

--- foobar/foo.c
+++ /tmp/foobar/foobar.c

This tends to break from time to time, and I had to fix at least three
packages since I started my treewide build for these problems. I already
asked Zac about adding such a check on repoman, but in the mean time I'd
like to ask here for people to verify their packages.

I actually am culprit of doing this some time ago but I learnt my lesson
the hard way :P My suggestion for everybody else is to use quilt when
you need to write patches.

And if you have patches with the filenames like I shown above, you can
change it the git way so that it becomes:

--- a/foobar/foo.c
+++ b/foobar/foo.c

and the problem is usually solved.

Thanks,
-- 
Diego Flameeyes Pettenò
http://blog.flameeyes.eu/



pgp1IcCBfPorv.pgp
Description: PGP signature


[gentoo-dev] Re: Please avoid absolute paths in patched filenames

2008-11-17 Thread Diego 'Flameeyes' Pettenò
Serkan Kaba [EMAIL PROTECTED] writes:

 This check was added to epatch all of a sudden breaking all working
 patches in the tree, although defending those patches having absolute
 paths, we as Java team had several bugs filed due to that. Maybe the
 tree should be scanned for those and fixed.

Fun, I didn't really notice it was an epatch specific code that failed,
I know it fails when the paths don't add up between systems and I
thought that was it.. Okay, I guess I'll get to fix the rest tonight
after Bones...

-- 
Diego Flameeyes Pettenò
http://blog.flameeyes.eu/


pgpkepw47URBE.pgp
Description: PGP signature


[gentoo-dev] Re: Please avoid absolute paths in patched filenames

2008-11-17 Thread Diego 'Flameeyes' Pettenò
[EMAIL PROTECTED] (Diego 'Flameeyes' Pettenò) writes:

 Fun, I didn't really notice it was an epatch specific code that failed,
 I know it fails when the paths don't add up between systems and I
 thought that was it.. Okay, I guess I'll get to fix the rest tonight
 after Bones...

All the tree should be sanitised now for what concerns patches in
$FILESDIR ... It's up to you to see if there are broken patches on
mirrors, I guess. My tinderbox will try its best to find them anyway.

-- 
Diego Flameeyes Pettenò
http://blog.flameeyes.eu/


pgp6W1we1FJi0.pgp
Description: PGP signature


[gentoo-dev] Remember: workarounds don't warrant RESO FIXED!

2008-11-16 Thread Diego 'Flameeyes' Pettenò

Guys, please remember that if you work something around, you should
_not_ close the bug as RESO FIXED but keep the bug open so that the
issue can be addressed and fixed _properly_. Otherwise we'll end up with
ebuilds full of workarounds without even documentation on why the
workaround is applied!

With workarounds I mean, as examples:

- FEATURES=test failures;
- broken parallel make that requires -j1;
- flags filtering, included -Wl,--no-as-needed appending

This is important because:

a) we want test to work or get fixed upstream;
b) we want users to get parallel build if they request parallel build;
c) we want --as-needed to be used, not ignored.

If the bug is open and comes out on searches and all the rest, then we
have higher chances that someone might _fix_ it, without having to look
to see if there actually is one...

Thanks!

-- 
Diego Flameeyes Pettenò
http://blog.flameeyes.eu/



pgp9wm4rF3mnl.pgp
Description: PGP signature


[gentoo-dev] Re: Remember: workarounds don't warrant RESO FIXED!

2008-11-16 Thread Diego 'Flameeyes' Pettenò
Serkan Kaba [EMAIL PROTECTED] writes:

 I think, resolving as UPSTREAM might be more logical as we can't force
 every upstream to fix their *borked* build system and the bug will be
 left open forever.

If upstream refuses to fix an issue that _is an issue_ we have to fix
it, not work it around forever and ever.

RESO UPSTREAM is good for crashes that are left to upstream, but since
Gentoo si abuilt building, build problems needs to get fixed.

-- 
Diego Flameeyes Pettenò
http://blog.flameeyes.eu/


pgpdnNkROqeW7.pgp
Description: PGP signature


[gentoo-dev] [RFC] simple-build eclass

2008-11-14 Thread Diego 'Flameeyes' Pettenò

I've already written about the possibility of creating an ebuild to
simply _replace_ the entire buildsystem of a package if it's
non-existant (simple .c file thrown around by upstream), too minimal
and/or impossible to get upstream do adapt, or as a temporary measure
until upstream is beaten into common sense.

The whole story can be found at
http://blog.flameeyes.eu/2008/10/15/fixing-cflags-ldflags-handling-with-a-single-boilerplate-makefile

I'm attaching a proof of concept of the eclass, it's certainly not ready
for prime time: it does not support C++ programs, it does not have
pkg-config support, and so on. But in general it should work, I'm also
attaching a reworked ebuild for uif2iso (package I maintain and for
which I had to _rewrite_ the whole Makefile already).

This gets especially interesting to consider if we want to enable
--as-needed by default, since this will allow easy fix for packages that
don't otherwise build with --as-needed, like habak that I had to fix,
and takes care of quite a few different problems at once.

HTH,

# Copyright 2008 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $
#
# Author: Diego Pettenò [EMAIL PROTECTED]

inherit toolchain-funcs

EXPORT_FUNCTIONS src_compile src_install

simple-build_src_compile() {
cat -  Makefile EOF
OBJS = \$(patsubst %.c,%.o,\$(wildcard \$(SRCS)))
\$(TARGET): \$(OBJS)
\$(CC) \$(LDFLAGS) \$^ -o \$@ \$(LIBS)
EOF

emake \
CC=$(tc-getCC) \
SRCS=${SIMPLE_SOURCES} \
LIBS=${SIMPLE_LIBRARIES} \
TARGET=${SIMPLE_TARGET:-${PN}} \
|| die emake failed
}

simple-build_src_install() {
dobin ${SIMPLE_TARGET:-${PN}} || die dobin failed
}
# Copyright 1999-2008 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $

inherit simple-build flag-o-matic

DESCRIPTION=Converts MagicISO CD-images to iso
HOMEPAGE=http://aluigi.org/mytoolz.htm#uif2iso;
SRC_URI=mirror://gentoo/${P}.zip

LICENSE=GPL-2
SLOT=0
KEYWORDS=~amd64 ~x86
IUSE=

RDEPEND=sys-libs/zlib
DEPEND=${RDEPEND}
app-arch/unzip

SIMPLE_SOURCES='src/*.c'
SIMPLE_LIBRARIES='-lz'

src_compile() {
append-flags -DMAGICISO_IS_SHIT

simple-build_src_compile
}

src_install() {
simple-build_src_install

dodoc ${WORKDIR}/${PN}.txt ${WORKDIR}/README || die dodoc failed
}


-- 
Diego Flameeyes Pettenò
http://blog.flameeyes.eu/



pgp7HRsrICOry.pgp
Description: PGP signature


[gentoo-dev] Re: packages up for grabs

2008-11-09 Thread Diego 'Flameeyes' Pettenò
Daniel Drake [EMAIL PROTECTED] writes:

 dev-dotnet/evolution-sharp

I was going to ask you about this last week, I guess I'll look into it
(although it makes me feel dirty to work with .NET stuff, I've been
working with worse stuff :P).

-- 
Diego Flameeyes Pettenò
http://blog.flameeyes.eu/


pgpg2jdRM4KaJ.pgp
Description: PGP signature


[gentoo-dev] Re: virtualx eclass

2008-10-16 Thread Diego 'Flameeyes' Pettenò
Doug Goldstein [EMAIL PROTECTED] writes:

 It'd be a lot more consistent if ebuilds provided a USE flag or directly
 depended on the xorg-server and then used the functions in the eclass.
 So in summary, those are the changes I plan on making very shortly. If
 someone's got some input, please speak up.

Kinda like good ol' kde.eclass:

VIRTUALX_ONLY_TEST=yes

inherit virtualx

and instead of using IUSE=X for that, IUSE=test.

-- 
Diego Flameeyes Pettenò
http://blog.flameeyes.eu/


pgp02mjr9xxds.pgp
Description: PGP signature


[gentoo-dev] Re: [RFC] New keywords for non-Gentoo Linux platforms

2008-10-10 Thread Diego 'Flameeyes' Pettenò
Fabian Groffen [EMAIL PROTECTED] writes:

 - x64 is what the vendors (Apple, Sun) advertise themselves

Err I'm sure I haven't seen any x64 in the documentation or
advertisement of my MacBook Pro, are you sure _Apple_ uses that totally
bogus name?

Anyway, em64t might be better, but then again you're to the same point:
an Opteron using an Intel name? I think amd64 is totally fine since it's
the first commercial name it got by uh, those who introduced it, I
guess, but the only thing I don't ever want to see officially is
endorsing the x64 commercial speak.

-- 
Diego Flameeyes Pettenò
http://blog.flameeyes.eu/


pgpfWJJfNdLak.pgp
Description: PGP signature


[gentoo-dev] Re: Projects without a homepage, and valid contents of HOMEPAGE (per bug 239268)

2008-10-06 Thread Diego 'Flameeyes' Pettenò
Jeroen Roovers [EMAIL PROTECTED] writes:

 http://www.gentoo.org/proj/en/abandoned/

What about www.unmaintained-free-software.org? Possibly opening a page?

-- 
Diego Flameeyes Pettenò
http://blog.flameeyes.eu/




[gentoo-dev] Re: sci-libs/scipy - dev-python/scipy ?

2008-07-08 Thread Diego 'Flameeyes' Pettenò
Alec Warner [EMAIL PROTECTED] writes:

 'epkgmove' invokes bad memories for many ;)

Thanks for ruining the few hours of sleep I'll get in the next days by
bringing that name up...

J/K

-- 
Diego Flameeyes Pettenò
http://blog.flameeyes.eu/


pgpr7bNm44sJj.pgp
Description: PGP signature


[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-irc/quassel: ChangeLog quassel-9999-r1.ebuild quassel-0.2.0_rc1.ebuild quassel-0.2.9999.ebuild

2008-07-02 Thread Diego 'Flameeyes' Pettenò
Thomas Anderson [EMAIL PROTECTED] writes:

 The reason it's failing is because you have things after the . You
 can do this:

I actually don't... and it doesn't file for the git case, it fails for
the non-git case (I only updated the git versions so the next time I
copy over the git ebuild I don't have to fix it again)

 Doing it my way doesn't fail for, say, -r1

-r1 has this values:

P=quassel-
PN=quassel
PV=
PF=quassel--r1
PVR=-r1 (was this the right variable name? I sincerely forgot)

the -r1 part is only ever used for the revisions in PVR, not on PV.

-- 
Diego Flameeyes Pettenò
http://blog.flameeyes.eu/


pgpDthx7fgu6m.pgp
Description: PGP signature


[gentoo-dev] Re: Suggested default LDFLAGS+=-Wl,-O1,--hash-style=gnu,--sort-common

2008-06-24 Thread Diego 'Flameeyes' Pettenò
Fabian Groffen [EMAIL PROTECTED] writes:

 as long as it doesn't go in /base, but in the linux/freebsd profiles
 instead, it's fine with me.

--has-style=gnu should not be used on non-GLIBC systems (I'm unsure
about uclibc, but I'd be surprised if they do implement the GNU style
hash).

-- 
Diego Flameeyes Pettenò
http://blog.flameeyes.eu/


pgpmivCa8PtPJ.pgp
Description: PGP signature


[gentoo-dev] Re: A few questions to our nominees

2008-06-14 Thread Diego 'Flameeyes' Pettenò
Santiago M. Mola [EMAIL PROTECTED] writes:

 * media-sound/amarok: live version is 1.4.. Next version is 2.0,
 but that's a different branch so I'd expect 2.0.live to give me the
 latest 2.0 version available, not 1.4's.

1.4. has been switched from  because of the 2.0/1.4 branches,
 would be 2.0 (if I ever care enough to add that, not before a beta
is released for sure, and not before I can use KDE 4.1 daily, which is
not something I expect to happen soonish).

Just FYI.

-- 
Diego Flameeyes Pettenò
http://blog.flameeyes.eu/


pgpvaSuTaiUhN.pgp
Description: PGP signature


[gentoo-dev] Re: lastrite: dev-cpp/libherdstat and app-portage/herdstat

2008-06-09 Thread Diego 'Flameeyes' Pettenò
Donnie Berkholz [EMAIL PROTECTED] writes:

 I usually do something like this:

I used to do that too, but it's quite slower than the */*/$blah, because
it has to visit all the directories on the grep.

Give it a try, took me quite a while to get used to it but it works
nicely.

-- 
Diego Flameeyes Pettenò
http://blog.flameeyes.eu/


pgpG5kcB0pK0f.pgp
Description: PGP signature


[gentoo-dev] Re: glibc-2.8 / gcc-4.3 build failures

2008-06-09 Thread Diego 'Flameeyes' Pettenò
Robert Buchholz [EMAIL PROTECTED] writes:

 # [tracker] GCC 4.3 porting
 https://bugs.gentoo.org/show_bug.cgi?id=198121

or https://bugs.gentoo.org/show_bug.cgi?id=gcc-4.3


 # [TRACKER] ebuilds failing to build against sys-libs/glibc-2.8
 https://bugs.gentoo.org/show_bug.cgi?id=225459

or https://bugs.gentoo.org/show_bug.cgi?id=glibc-2.8


I love aliasing :)

-- 
Diego Flameeyes Pettenò
http://blog.flameeyes.eu/


pgprbDcyCeB7l.pgp
Description: PGP signature


[gentoo-dev] Re: lastrite: dev-cpp/libherdstat and app-portage/herdstat

2008-06-08 Thread Diego 'Flameeyes' Pettenò
Michael Sterrett -Mr. Bones.- [EMAIL PROTECTED] writes:

 The tree's small enough that grep -r gives enough performance.

Even better

grep */*/metadata.xml

the tree is not big enough that it exceeds the maximum arguments from bash.

-- 
Diego Flameeyes Pettenò
http://blog.flameeyes.eu/


pgpQqdIwTnEXe.pgp
Description: PGP signature


[gentoo-dev] Re: Nominations open for the Gentoo Council 2008/2009

2008-06-05 Thread Diego 'Flameeyes' Pettenò
Josh Saddler [EMAIL PROTECTED] writes:

 flameeyes

I'm glad to accept the nomination.

-- 
Diego Flameeyes Pettenò
http://blog.flameeyes.eu/


pgpLZOrCacFcT.pgp
Description: PGP signature


[gentoo-dev] Re: Nominations open for the Gentoo Council 2008/2009

2008-06-05 Thread Diego 'Flameeyes' Pettenò
Łukasz Damentko [EMAIL PROTECTED] writes:

 Nominations for the Gentoo Council 2008/2009 are open now and will be
 open for the next two weeks (until 23:59 UTC, 18/06/2008).

I wish to nominate Halcy0n, Cardoe and leio.

-- 
Diego Flameeyes Pettenò
http://blog.flameeyes.eu/


pgpeaQMLjTTgU.pgp
Description: PGP signature


Re: [gentoo-dev] Nominations open for the Gentoo Council 2008/2009

2008-06-05 Thread Diego 'Flameeyes' Pettenò
Roy Bamford [EMAIL PROTECTED] writes:

 1. Please tell us how/if you plan to fix GLEP 39. (You may not consider 
 it broken)

Need to address better when a meeting is considered official (right now
it's not addressed at all, so anything is better), for the rest is fine
as it is.

 2. As one of the first priorities will be setting policy for pending 
 appeals what policy do you propose ?

Council handles appeals, there's no conflict of interests: who gets
voted in is already known to not be entirely impartial and/or being in
charge of other decsion-making teams.

 4. How do you think the council and trustees can work together to make 
 Gentoo better?
 Not just the code base but the cooperative environment we all work 
 together in too. 
 Disclosure - I have a personal interest in responses as a trustee.

Staying independent one of the other, with no hierarchical relationship
one way or the other.

 5. Tell us a little about yourself - the skills and experience you can 
 bring to the council?

If you know me you know what I do, if you don't, I suggest just looking
at my blog (http://blog.flameeyes.eu/) there it's all you have to know,
and probably something you don't care about.

 6. Tell us one outstanding (in your own mind) contribution you made to 
 Gentoo in the last year.

Last year? Being a council member already, I'd say.

 Any candidate who does not have time/interest to prepare a manifesto 
 addressing the above and anything else they want to say to the 
 electorate will have a hard time convincing me that they have the time/
 interest to undertake the duties of a council member. 

You might want to revisit your ideas, unless you expect next council
elections to require primaries first. I sincerely don't want to spend
time to rewrite this as a manifesto because it makes really not much
sense. I don't take an opinion _just_ for the election, my opinions are
open to anybody to see. And I did have time and interest in stayin in
the council for two terms already.

With all sincerity, your threat makes me want to puke: if we're being
forced to write manifestos, I might just as well reject my nomination,
as I find that just useless bureaucracy.

And no I won't be wearing a Gentoo logo pin on my lapel.

-- 
Diego Flameeyes Pettenò
http://blog.flameeyes.eu/


pgpTH5y8bbTuP.pgp
Description: PGP signature


[gentoo-dev] Remember, please don't use upstream-provided bootstrap unless necessary

2008-06-04 Thread Diego 'Flameeyes' Pettenò

I stumbled across another ebuild today that used the upstream-provided
bootstrap script to rebuild autotools.

Please refrain from using those if you can.

Upstream doesn't always know better for our setup (it may try to second
guess our settings by looking for particular automake/autoconf
versions), it will show to the user information we don't care about,
almost all the bootstrap scripts I've seen don't even try to catch when
a step in the rebuild fails, they mask the need for autotools, and as
you don't inherit autotools eclass for running them, you usually forget
to add the autoconf/automake dependencies. And it makes very difficult
to track down which ebuilds do actually use autotools to track down if
there are changes to do.

Let's not even start to talk about bootstrap scritps that run
./configure by themselves, those are just plainly evil.

Please note that sometimes the bootstrap script is used to add extra m4
search directories and options like --foreign to automake. Well, here's
the deal:

- AT_M4DIR is the variable to use to pass extra m4 search directory to
  aclocal, no need for the bootstrap script;
- eautomake takes care by itself to identify the cases where --foreign
  is needed (this usually means when some of the standard documentation
  files are missign);

beside, if upstream is providing a bootstrap script for just these two
reasons, then it's time they learn about ACLOCAL_AMFLAGS.

Also make sure that autotools gets not rebuilt through maintainer mode,
that will make the configure run twice, wasting users' time, and is
usually evil if you are using unpack to check for the generated
configure (yes it happened to me a couple of time).

THANKS!

-- 
Diego Flameeyes Pettenò
http://blog.flameeyes.eu/



pgp2TEcsoe1ye.pgp
Description: PGP signature


[gentoo-dev] Re: Remember, please don't use upstream-provided bootstrap unless necessary

2008-06-04 Thread Diego 'Flameeyes' Pettenò
[EMAIL PROTECTED] (Diego 'Flameeyes' Pettenò) writes:

 Please refrain from using those if you can.

As I was asked for an example see this commit I made today:

http://sources.gentoo.org/viewcvs.py/gentoo-x86/app-backup/boxbackup/boxbackup-0.10.ebuild?r1=1.9r2=1.10

the original ebuild used the bootstrap script (in src_compile by the
way, which is very bad for me), and depended on autoconf directly,
without forcing which version should have been used.

The new version instead uses autotools.eclass, calls eautoreconf, sets
its AT_M4DIR as the bootstrap script did (and again, ACLOCAL_AMFLAGS is
what upstream should have used).

This way warnings and errors from autotools won't be seen by the users,
but will be logged in case stuff fialed, and you don't have to rely on
the bootstrap script not making stupid stuff.

-- 
Diego Flameeyes Pettenò
http://blog.flameeyes.eu/


pgpL2ZKCbyV3n.pgp
Description: PGP signature


[gentoo-dev] Re: packages up for grabs

2008-06-02 Thread Diego 'Flameeyes' Pettenò
Mike Frysinger [EMAIL PROTECTED] writes:

 dev-util/elfsh

I'll take a look, I might have some use for this.

-- 
Diego Flameeyes Pettenò
http://blog.flameeyes.eu/

-- 
gentoo-dev@lists.gentoo.org mailing list



[gentoo-dev] Re: RFC: Should preserve-libs be enabled by default?

2008-05-30 Thread Diego 'Flameeyes' Pettenò
Santiago M. Mola [EMAIL PROTECTED] writes:

 --as-needed breaking legitimate code is a problem, though. I wonder if
 we have that kind of code in any application in the tree and if we
 have some way to detect it.

You could be looking for code not supposed to work under Solaris or
Windows, as the --as-needed behaviour behaves a lot like the standard
Sun linker and the forced behaviour of the PE executable format.

The only thing that can be broken by using --as-needed is code that
assumes the order in calling the .init sections of a set of shared
objects. Such an order is not only changed by --as-needed usage but by
any other change in the loading mechanism. It is strictly related to
glibc at this point as far as I can tell.

-- 
Diego Flameeyes Pettenò
http://blog.flameeyes.eu/


pgpNOhQiIWOXd.pgp
Description: PGP signature


[gentoo-dev] Re: RFC: Should preserve-libs be enabled by default?

2008-05-30 Thread Diego 'Flameeyes' Pettenò
Rémi Cardona [EMAIL PROTECTED] writes:

 --as-needed breaks legitimate C++ code, I have yet to see it break
 plain C code (but I could be wrong).

This because C does not have constructors or static objects. I suppose I
can write a couple of C files that can present the problem, but really,
they would break as soon as I change the loading rules by moving to a
non-ELF system or a different dynamic loader.

It's interesting to note that Microsoft _did_ think of this problem when
designing the .NET framework, and they answer is ensuring just that the
static constructor will be called (right) before any static method or
attribute is referenced and (right) before any object of the given class
is istantiated. They don't get otherwise an absolute order in which
static constructors are called.

-- 
Diego Flameeyes Pettenò
http://blog.flameeyes.eu/


pgp6Q7c1XvJEy.pgp
Description: PGP signature


[gentoo-dev] Re: RFC: Should preserve-libs be enabled by default?

2008-05-30 Thread Diego 'Flameeyes' Pettenò
David Leverton [EMAIL PROTECTED] writes:

 It's not just the order, it also breaks things that rely on the .init
 section being called at all to register themselves with the core
 application (with --as-needed, the .so doesn't get loaded in the first
 place, so it doesn't get a chance to run anything).

This really is backward, solution-wise: you expect the core
application to know enough of the plugins to link them together, but
not enough to call their init functions...

And still, it breaks not only with --as-needed but also with the Sun
linker, with the PE file format and other non-ELF file formats. So it's
really not a problem _limited_ to --as-needed.

Beside, you can _force_ a link by using --no-as-needed before a given
library, that's what it's supposed to happen if you don't want to be
helped by the linker.

To a very minimum this can be said to be a _clash_ between two
designs. Saying that --as-needed is _broken_ because it breaks this case
is _quite_ an exaggeration...

-- 
Diego Flameeyes Pettenò
http://blog.flameeyes.eu/


pgpDGGzHF7XVV.pgp
Description: PGP signature


[gentoo-dev] Re: RFC: Should preserve-libs be enabled by default?

2008-05-29 Thread Diego 'Flameeyes' Pettenò
Marius Mauch [EMAIL PROTECTED] writes:

 Also it is not going to be a perfect solution against all runtime link
 errors, but if enabled it should eliminate the need for revdep-rebuild
 in most cases.

I'm afraid that it will turn, for complex libraries like libexpat and
users not using --as-needed, the message telling you the program cannot
be started with subtle crashes for symbol collision.

preserve-libs would be quite perfect if all libraries out there used
versioned symbol, but this is far from true (and some systems Gentoo
runs on don't even consider versioned symbol to begin with).

Example at hand? When the libexpat transition started, the choice of
keeling .so.0 around with .so.1 was discarded right away because:

- library libfoo links to libexpat;
- program bar links to libfoo;
- user is not using --as-needed, so bar has a NEEDED against both libfoo
  and libexpat;
- user rebuilds libfoo, but not bar; or bar and not libfoo, the result
  is the same;
- KABOOM! symbol collision and bar crashes.

As much as we want preserve-libs to be an all-curing magic, it's
not. When you need to replace a library you need to do so _for all its
users at once_, if you allow it to be gradually you're opening the
hellgate of symbol collision.

My solution would be to disallow _building_ anything that is or depends
directly or indirectly on a package on the set until it is removed, or
at the request of merging mickeymouse, depending on bar, re-emerging
libfoo first, and bar if the user is not using --as-needed (checking the
NEEDED lines).

With all due respect to everybody, the right course of action here has
to be selected by people who knows how the runtime linker works, symbol
collision and all the rest, as that's what's at stake here.

-- 
Diego Flameeyes Pettenò
http://blog.flameeyes.eu/


pgpR6kEe6MGbq.pgp
Description: PGP signature


[gentoo-dev] Re: About herds and their non-existant use

2008-05-23 Thread Diego 'Flameeyes' Pettenò
Robin H. Johnson [EMAIL PROTECTED] writes:

 The sole reason that isn't possible is that some teams would have names
 that conflict with system accounts. While it's possible to override
 those in the Gentoo mail server setup, the system account versions DO
 receive a _LOT_ of spam because they are so common (eg mysql@, ldap@).

What about standardising on a suffix too?

[EMAIL PROTECTED] or [EMAIL PROTECTED] or [EMAIL PROTECTED]

and then all the aliases following that

[EMAIL PROTECTED] [EMAIL PROTECTED] and so on

-- 
Diego Flameeyes Pettenò
http://blog.flameeyes.eu/

-- 
gentoo-dev@lists.gentoo.org mailing list



[gentoo-dev] Re: About herds and their non-existant use

2008-05-22 Thread Diego 'Flameeyes' Pettenò
Luis Francisco Araujo [EMAIL PROTECTED] writes:

 Unless a team can maintain several herds, I find the term 'herd'
 confusing and better understood as 'team' instead.

+1 on this. I always thought that if almost every dev misuses the term
herd, it was because the term had to be changed, rather than the devs
corrected...


-- 
Diego Flameeyes Pettenò
http://blog.flameeyes.eu/


pgpFE7rWRh6si.pgp
Description: PGP signature


[gentoo-dev] Re: Moving some packages around

2008-05-18 Thread Diego 'Flameeyes' Pettenò
Ulrich Mueller [EMAIL PROTECTED] writes:

 A Lexical Analyser and a Parser Generator are also required by
 IEEE Std 1003.1 (aka POSIX) as part of the C-Language Development
 Utilities.

 So it doesn't make much sense to remove flex and bison from system.

IIRC POSIX mandates vi too, and we don't have that in system.

-- 
Diego Flameeyes Pettenò
http://blog.flameeyes.eu/


pgpUtWRYxFly8.pgp
Description: PGP signature


[gentoo-dev] Re: FRC: debtools herd creation

2008-05-16 Thread Diego 'Flameeyes' Pettenò
Yuri Vasilevski [EMAIL PROTECTED] writes:

 I will be adding some debian build tools to the tree, and would like to
 create the debtools herd to associate with the packages.

Just please don't add Debian-OpenSSL ;)

-- 
Diego Flameeyes Pettenò
http://blog.flameeyes.eu/


pgpJFtnW9Ug70.pgp
Description: PGP signature


[gentoo-dev] Re: Bug wrangling

2008-05-14 Thread Diego 'Flameeyes' Pettenò
Steve Long [EMAIL PROTECTED] writes:

 It makes moving a bug from one package to another quite a complex task
 though, as it requires two confirmation screens... and trust me that
 happens often enough.

 Shouldn't that just be scripted via pybugz? A GUI for that would be nice;
 perhaps as a pida[1] module. Frankly it appals me that y'all have so much
 time to write bash scriptlets and none to develop tools for your own
 use.

I like Bugzilla for the very reason I can look, comment and in general
manage bugs with decency without needing client software beside a
webbrowser, and I'm rarely without a webbrowser, heck, I had one at hand
even while I was hospitalised (not in the ICU though, that was boring).
Anything that requires me an extra software is something that I'm more
likely _not_ going to use.

 Plus that would work fine if we had a bugzilla for ebuilds only, but
 would you really mix categories together with Infra, Portage, Gentoo
 Hosted Projects, ... ?
 
 Who cares?

Uh, I do, as I tend to report a lot of bugs and I don't want to have to
use the find command of my browser to see where the heck should I report
it. Don't even get me started on template bugs that I use to mass-report
problems.

And probably most users would find the huge and long product
list to choose from most likely confusing. Users can't get it right
already with the short list we have, reporting bugs on Bugzilla product
which have nothing to do with Bugzilla...

-- 
Diego Flameeyes Pettenò
http://blog.flameeyes.eu/


pgpLxXSM4xO5z.pgp
Description: PGP signature


[gentoo-dev] Re: Bug wrangling

2008-05-13 Thread Diego 'Flameeyes' Pettenò
Donnie Berkholz [EMAIL PROTECTED] writes:

 Would it be possible to add the tree categories as products and the 
 packages as components thereof?

It makes moving a bug from one package to another quite a complex task
though, as it requires two confirmation screens... and trust me that
happens often enough.

Plus that would work fine if we had a bugzilla for ebuilds only, but
would you really mix categories together with Infra, Portage, Gentoo
Hosted Projects, ... ?

-- 
Diego Flameeyes Pettenò
http://blog.flameeyes.eu/


pgpvHLX3kZ64t.pgp
Description: PGP signature


[gentoo-dev] Re: LaTeX documentation

2008-05-13 Thread Diego 'Flameeyes' Pettenò
Alexis Ballier [EMAIL PROTECTED] writes:

 - In some pkg_ functions so that it doesnt get removed; is this safe
 for binpkgs ? that'll leave stray files, but that's more or less the
 point of doing it like that.

Cache being cache, I'd say that it should be done in the ebuilds
installing the fonts in pkg_* functions. I'd say not in src_* because
packaging up the cache is not what one wants in almost all cases, you
wouldn't want a buggy TeX version creating broken packages when you can
avoid that.

-- 
Diego Flameeyes Pettenò
http://blog.flameeyes.eu/


pgplYuHKwq2Eq.pgp
Description: PGP signature


[gentoo-dev] Moving some packages around

2008-05-11 Thread Diego 'Flameeyes' Pettenò

I've been thinking today that we have a lot of things in sys-devel that
shouldn't probably be there, like pmake and bmake.

I'd propose the following move, if nobody has arguments aginst those:

sys-devel/bmake - dev-util/bmake
sys-devel/pmake - dev-util/pmake
sys-devel/bison - dev-util/bison
sys-devel/flex - dev-util/flex
sys-devel/autoconf-archive - dev-util/autoconf-archive
sys-devel/ac-archive - dev-util/ac-archive
sys-devel/cons - dev-util/cons
sys-devel/gdb - dev-util/gdb
sys-devel/omni - dev-lang/omni

Reasoning for the moves: 

- bmake and pmake are additional make commands from the basic one,
  G/*BSD will have their own in -ubin or -bin, while the rest of the
  system uses GNU make as sys-devel/make;
- bison and flex should get out of the system package set, what clearer
  than moving them out of sys-*? They are not so commonly used so there
  should no compelling reason to have them installed on every system;
- autoconf-archive and ac-archive are not really something for your
  system;
- cons is not commonly used as build system, so should probably be
  together with the other not-so-used build systems;
- gdb is not part of the system, this might be a problem for
  crossdev...;
- omni is ... well not something I'd look for in sys; plus it's a
  compiler so it would probably suite dev-lang better.

There are a few I'm not sure of because I don't know the package at all,
or because I have mixed feelings about them:

sys-devel/remake - dev-util/remake
sys-devel/sparse - dev-util/sparse
sys-devel/distcc - dev-util/distcc
sys-devel/icecream - dev-util/icecream
sys-devel/m4 - dev-lang/m4
sys-devel/patch - app-text/patch
sys-devel/prelink - sys-apps/prelink (something else? It's not a devel
 package...) 
sys-devel/autogen - dev-util/autogen
sys-devel/dev86 - dev-lang/dev86
sys-devel/bin86 - dev-lang/bin86
sys-devel/gettext - app-i18n/gettext (well, it's part of system for
G/FBSD, but I'd rather have deps expressed properly...)

Yes these are a lot of moves, sincerely I think sys-* categories are a
bit bloated as they are, and I suppose we should start moving the things
around rather than waiting forever ad ever..

-- 
Diego Flameeyes Pettenò
http://blog.flameeyes.eu/



pgpmmXnU0kfAK.pgp
Description: PGP signature


[gentoo-dev] Re: RFC: lzma tarball usage

2008-05-08 Thread Diego 'Flameeyes' Pettenò
Duncan [EMAIL PROTECTED] writes:

 So it would also be possible to compile lzmadec without any need for
 C++. Just call make in subdirs liblzmadec and lzmadec.

 What about USE=decode-only or something similar for lzma-utils, then?  If 
 desired, it could even be masked on normal profiles, but would then be 
 there for the embedded and releng folks.

USE=cxx should do just fine, it will disable the C++-related parts,
whatever they are. Sincerely I'd quite like to enable it on my vserver's
build chroots too.

(BTW I considered using lzma for backup compression, but I didn't get
much different results from bzip2 in term of size, but took quite longer
in case of compression... I still have some doubts whether lzma is worth
it).

-- 
Diego Flameeyes Pettenò
http://blog.flameeyes.eu/


pgpRSDaMmZtfS.pgp
Description: PGP signature


[gentoo-dev] Re: RFC: lzma tarball usage

2008-05-08 Thread Diego 'Flameeyes' Pettenò
Graham Murray [EMAIL PROTECTED] writes:

 Should that be USE=-cxx? The help for USE=cxx says that this builds
 support for C++.

It was meant as setting a cxx USE on the ebuild, I wasn't certainly
meaning to disable the C++ parts with USE=cxx enabled ;)

-- 
Diego Flameeyes Pettenò
http://blog.flameeyes.eu/


pgpZoYJGuVAYM.pgp
Description: PGP signature


[gentoo-dev] Re: RFC: lzma tarball usage

2008-05-08 Thread Diego 'Flameeyes' Pettenò
Ciaran McCreesh [EMAIL PROTECTED] writes:

 You miss my point. GNU tar sometimes changes its on disk format (and
 will be doing so again at some point for xattrs)

It's not really important to the discussion, but...

The TAR format is designed as such that on disk formats can be extended
without breaking entirely backward compatibility. For what it's worth,
extended attributes and ACLs are already supported by star (Schilling's)
and bsdtar (libarchive). The fact that GNU tar doesn't support them at
the moment is a different problem. On the other hand, even if the GNU
tar does not support reading those attributes, it does handle them
gracefully, warning the user of unknown extended headers, and then
proceeding to unpack the data without preserving the extended
attributes.

So what Doug said stands perfectly and does not interest GNU tar at all.

-- 
Diego Flameeyes Pettenò
http://blog.flameeyes.eu/


pgpP94k0pAIHZ.pgp
Description: PGP signature


[gentoo-dev] Re: Automagic dependencies in gegl

2008-05-01 Thread Diego 'Flameeyes' Pettenò
Hanno Böck [EMAIL PROTECTED] writes:

 Beside, I'm asking myself how to handle this situation. Hard-enable them all 
 as long as there are no patches? Let the automagic go in the tree? Opinions 
 welcome.

Automagic has _not_ to come to the tree, so hard-enable them all is the
way.
Have you looked at automagic.xml? It should help you for the task, and
if it doesn't, I can see to extend it.

-- 
Diego Flameeyes Pettenò
http://blog.flameeyes.eu/


pgp2shTJ9UczV.pgp
Description: PGP signature


[gentoo-dev] Reminder: re-run autotools if you change Makefile.am/configure.ac!

2008-04-21 Thread Diego 'Flameeyes' Pettenò

Please remember to re-run autotools if you change Makefile.am and/or
configure.ac (or configure.in if the package uses the old name, or
configure.in.in for KDE-based packages). Especially with autoconf 2.62
release this becomes important as some package might try to re-run
autotools on its own and find different versions, dying of an horrible
death.

Also, remember that unless the package you're using is _not_ using
automake (and thus aclocal), you should not run eautoconf, but
eautoreconf instead. In general if you're unsure, just run eautoreconf.

Exception can be made if you only touch Makefile.am, eautomake knows to
run eautoreconf if the versions of the tools has changed, but again if
you're unsure, just run eautoreconf.

Yeah of course it makes waste time to the users to re-run autotools
entirely, but it's better making every user waste those 30 seconds
rather than having users complain that $foo doesn't build at the next
autoconf bump. Or right now considering the amount of packages that
fails with autoconf 2.62.

-- 
Diego Flameeyes Pettenò
http://blog.flameeyes.eu/



pgpCG22ilYd0X.pgp
Description: PGP signature


[gentoo-dev] Re: New global USE flag: keyring

2008-04-20 Thread Diego 'Flameeyes' Pettenò
Peter Weller [EMAIL PROTECTED] writes:

   1) Nice and simple. Just force all packages to compile with
   --gnome-keyring

*cough* pambase *cough*

So discard this idea already, removing the flag is not an
option... unless you want pambase to stick with gnome USE flag as I did
in origin.

(I admit I didn't check if Remi renamed it or not, but he asked, so...).

-- 
Diego Flameeyes Pettenò
http://blog.flameeyes.eu/


pgp9gQ8NFvmG8.pgp
Description: PGP signature


[gentoo-dev] Re: Removing .la files...

2008-04-19 Thread Diego 'Flameeyes' Pettenò
Petteri Räty [EMAIL PROTECTED] writes:

 You would have to fix the vdb too.

Which is the tricky part, and the reason why I didn't instruct anybody
to do the sed on my ChangeLogs.p

-- 
Diego Flameeyes Pettenò
http://blog.flameeyes.eu/

-- 
gentoo-dev@lists.gentoo.org mailing list



[gentoo-dev] Re: Help offered - Portage tree

2008-03-13 Thread Diego 'Flameeyes' Pettenò
[EMAIL PROTECTED] writes:

 Then the chief architect of
 Sabayon is scotched over bugzilla output?

Can I declare myself Chief Architect of unieject? Does that give me
right to take and fix others' software without passing through the usual
ways?

Counting titles seems more an HR thing to me than looking at behaviour.

[and I didn't even want to write to this topic]
-- 
Diego Flameeyes Pettenò
http://blog.flameeyes.eu/


pgpLV5Q12WHWy.pgp
Description: PGP signature


[gentoo-dev] Re: [RFC] Renaming the caps USE flag to libcap

2008-03-07 Thread Diego 'Flameeyes' Pettenò
Tiziano Müller [EMAIL PROTECTED] writes:

 Well, I'm not sure whether libcap is a good choice: What about
 (not-yet-existing) apps which provide capability-support through another
 package (like a foobar language libcap-wrapper)? Should they also use
 libcap then?

Uhm, good point. What about fscaps for the other case then? Or filecaps?

-- 
Diego Flameeyes Pettenò
http://blog.flameeyes.eu/

-- 
gentoo-dev@lists.gentoo.org mailing list



[gentoo-dev] [RFC] Renaming the caps USE flag to libcap

2008-03-06 Thread Diego 'Flameeyes' Pettenò

I'd like to propose the rename of caps USE flag to libcap. The reason
for this is that I'd like to free the caps USE flag from the (runtime)
dependency of libcap, so that, one we have the framework to do so, we
could use the caps' USE flag to set file capabilities directly (rather
than setuid for instance).

The step right afterward would be, for me, to find a way to mirror the
capabilities from within Portage. I admit I have no clue how to achieve
that for now. But at least the rename is a simple task, and I suppose
the capabilities handling _could_ be a SoC project...

-- 
Diego Flameeyes Pettenò
http://blog.flameeyes.eu/


-- 
gentoo-dev@lists.gentoo.org mailing list



[gentoo-dev] Proposal for (next year's probably) SoC

2008-03-05 Thread Diego 'Flameeyes' Pettenò

I think it could be useful to learn from other projects' handling of
SoC. The FFmpeg project has a list of qualification tasks for the
students to complete before they can accepted into SoC, as you can see
From [1].

The tasks are minor tasks that don't require a lot of time at hand, but
gives a good way to judge if the person is in for the experience or the
money, and might be able to cut the deal even for Gentoo devs if that is
really wanted.

How to implement it for Gentoo? Well I think we have the tool already:
Bugzilla. We just need to add a keyword SOC_QUALIFICATION_TASK; when a
developer think of a working qualification task, he can add the keyword
and CC the soc team or something like that.

Then the users can deal with the problems whenever they want, for the
next SoC, even during the year. When they submit their application, we
ask users to put the link to the bug that represented the qualification
task they completed.

To make the checking more easy, we could make sure that the person who
completed the task is listed in the Whiteboard, and that only Gentoo
devs can change that for the bugs for qualification task (letting only
devs opening them, or cloning the feature requests from user that become
a SoC qualification task, for instance).

Then get a tracker that is blocked by all the SoC qualification task
bugs, monitored by the SoC team, that can make sure how stuff is going
with the qualification tasks, and finally add a default query for the
tasks to the documentation about SoC.

I'm sure we can easily get some qualification tasks on; with a bit more
work we might also get qualification points (so that for instance minor
tasks alone can't cut the deal).

Maybe a bit complex, but I think it might be worth discussing.

[1] http://wiki.multimedia.cx/index.php?title=FFmpeg_Summer_Of_Code_2008

-- 
Diego Flameeyes Pettenò
http://blog.flameeyes.eu/



pgplbNnqPp88m.pgp
Description: PGP signature


[gentoo-dev] One request for the next SoC: non already-devs students

2008-03-02 Thread Diego 'Flameeyes' Pettenò

I know this is going to stir up quite some discussion, but I do think
it's worth trying requesting it at least.

In the past two years we had quite a few applications from students that
were already full-fledged Gentoo developers. I sincerely would like that
this year we put as a rule that Gentoo developers cannot partecipate in
Summer of Code as students for Gentoo.

I'm not asking to penalise Gentoo developers are students. But I
sincerely think the main goal of Summer of Code is to allow new people
to enter the scene of Free Software, to understand how Free Software
projects work and so on. Gentoo Developers are already pretty well
inside this world.

I think it should be a self-made decision to abstain from applying as a
student for what you already partecipate in, but as such concerns don't
seem to be widespread (at least as the last two years shown), I'm asking
for a formal decision to all the developers. If that is requested, I'm
even willing to bring this in front of the council.

Gentoo's ranks are quite reduced nowadays, and a few persons have shown
conerns about our current recruiting methods being able to judge clearly
technical and social skills, as well as the time one is ready to pour
into the project. I think SoC could be used as a pretty good recruiting
method: as you are going to work quite a bit with the student, you can
easily judge availability and technical and social skills. Leaving SoC
applications open to developers means wasting this opportunity.

There are many other organisations partecipating, I think it would be
quite feasible for Gentoo developers wanting to be a student SoC to
choose another one, in which they are not involved already. Yes it's
easier for them to do something for Gentoo as they are already
contributing, but that is not the point of Summer of Code, the point is
to introduce new people into projects, not giving money to people to do
what they already do.

And just to take a stance, even if this request is to be rejected, I'm
not going to mentor a student that is already a Gentoo developer, for
sure.

So to be clear, I'm not trying to look down to anybody, I don't even
want to stop people from being paid for their work. I just wish that we
can focus this opportunity to improve the Gentoo project as a whole.

-- 
Diego Flameeyes Pettenò
http://blog.flameeyes.eu/



pgpRBzwP21UZC.pgp
Description: PGP signature


[gentoo-dev] Re: One request for the next SoC: non already-devs students

2008-03-02 Thread Diego 'Flameeyes' Pettenò
Richard Freeman [EMAIL PROTECTED] writes:

 Do we inspire them by telling them that anybody who has made this choice
 in the past is not to be rewarded financially for doing so?

This brings up a different point of view too. Why should just somebody
be rewarded financially and not someone else? Why only people who are
still in school, and not people who left school? I don't even want to
think what might happen if there was something like Debian's DunkTank
flame in here.

 A bigger concern is this.  Which is better for gentoo?  Taking somebody
 who has never worked on gentoo and paying them money to possibly
 accomplish something on the project, or taking somebody who is already
 doing quite a bit and pay them so that they can accomplish even more
 without the distraction of a day job?

Do you think that $4500 (which is, by now, less than €3000) during the
summer will stop anybody already contributing from finding a day job? I
sincerely don't think so.

It does, though, help new people to _try_ working on Free
Software. Students paid for SoC don't need to find a temporary job for
that summer to build up experience (which is what I suppose most
students would like to do, you can't expect a huge pay for three months
of work _in the summer_), it's a good pay, for three months of work, but
it's far from being a pay good enough for anybody to actively stop
looking for a job. They will have to understand, though, that Gentoo is
not a job and you won't end up always being paid to help that.

Sincerely, I find the without the distraction of a day job argument to
be pretty silly. How can an eventual, possible, not sure at all, and for
sure not stable, check of €3000 once an year stop anybody from finding a
dayjob? It's like counting on winning the lottery twice an year to
sustain yourself. I live with my parents still, in the past years I had
unstable jobs (paying more than €3000) during the start of the year and
then had almost nothing between spring and winter, I have no monthly
expenses, and I still struggle to find money to buy a new box.

It might be an added incentive to get experience in Free Software rather
than as a third-grade programmer helper in a small software company with
most of the stable programmers taking weeks off for the summer, but for
sure can't replace a stable job.

-- 
Diego Flameeyes Pettenò
http://blog.flameeyes.eu/


pgpVtsOBe18rv.pgp
Description: PGP signature


[gentoo-dev] Re: One request for the next SoC: non already-devs students

2008-03-02 Thread Diego 'Flameeyes' Pettenò
Alec Warner [EMAIL PROTECTED] writes:

 Your entire argument is based on the assumption that the Summer of
 Code program's primary goal is to recruit new developers for Open
 Source projects.  While this is one goal I am unsure if holding it
 above the others is necessary.

I know it's not the _sole_ goal of Summer of Code as intended by
Google. But I do think it should be the main goal for Gentoo as a
project. I also knew it was already discussed in the FAQ, and that there
is no _Google_ rule stopping Gentoo developers from partecipating as
Gentoo students. And that is why I'm bringing up the point on Gentoo
ground.

If this works, I'd take this time to add this as an official point for
the next council meeting.

-- 
Diego Flameeyes Pettenò
http://blog.flameeyes.eu/


pgpa5jjojYtSp.pgp
Description: PGP signature


[gentoo-dev] Re: One request for the next SoC: non already-devs students

2008-03-02 Thread Diego 'Flameeyes' Pettenò
[EMAIL PROTECTED] (Diego 'Flameeyes' Pettenò) writes:

 In the past two years we had quite a few applications from students that
 were already full-fledged Gentoo developers. I sincerely would like that
 this year we put as a rule that Gentoo developers cannot partecipate in
 Summer of Code as students for Gentoo.

Just to add material, Debian is also discussing a similar issue, see
http://www.lucas-nussbaum.net/blog/?p=280 .

-- 
Diego Flameeyes Pettenò
http://blog.flameeyes.eu/


pgp9DpQeBx80r.pgp
Description: PGP signature


[gentoo-dev] net-misc/zsync destiny?

2008-02-25 Thread Diego 'Flameeyes' Pettenò

I was just looking around in package.mask to see if I forgot to get rid
of something, and I've noticed that zsync is currently masked because it
contains an internal _vulnerable_ copy of zlib.

It is currently maintainer-needed, so I don't see anybody actually
fixing it to use system zlib anytime soon.

Any reason why it isn't simply lastrited unless someone wants to
maintain it? Treecleaners?

-- 
Diego Flameeyes Pettenò
http://blog.flameeyes.eu/


-- 
gentoo-dev@lists.gentoo.org mailing list



[gentoo-dev] Re: [EMAIL PROTECTED]: Google Summer of Code 2008 is on!]

2008-02-25 Thread Diego 'Flameeyes' Pettenò
Grant Goodyear [EMAIL PROTECTED] writes:

 I'm willing to help if help is wanted.

I already offer myself as a mentor if we get accepted.

-- 
Diego Flameeyes Pettenò
http://blog.flameeyes.eu/


pgpEQEI74mHlp.pgp
Description: PGP signature


[gentoo-dev] Re: [gentoo-commits] gentoo commit in xml/htdocs/proj/en/base/pam: upgrade-0.99.xml

2008-02-24 Thread Diego 'Flameeyes' Pettenò
On Sunday 24 February 2008, Robin H. Johnson wrote:
 Why did you take the version on the document backwards?

Because I mistyped it.

-- 
Diego Flameeyes Pettenò
http://blog.flameeyes.eu/



signature.asc
Description: This is a digitally signed message part.


[gentoo-dev] Re: Keyword amd64 - x86_64

2008-02-21 Thread Diego 'Flameeyes' Pettenò
Marius Mauch [EMAIL PROTECTED] writes:

 - x64 is IMO the worst name for the architecture (originally a MS
 marketing term later adopted by Sun, looks too similar to x86, name
 doesn't make any sense really if you compare it to x86)

Marius said all I wanted to say on that name.

Beside, does it really changes stuff for anybody beside Intel fanboys?

-- 
Diego Flameeyes Pettenò
http://blog.flameeyes.eu/


pgpJcqFsPOsVT.pgp
Description: PGP signature


[gentoo-dev] Re: [RFC] global useflags

2008-02-15 Thread Diego 'Flameeyes' Pettenò
Steve Long [EMAIL PROTECTED] writes:

 Well if you're going for a widely-known acronym outside Gentoo-land it'd be
 decss: http://en.wikipedia.org/wiki/DeCSS

 I've always wondered why that wasn't used in the first place (not that it
 helps now; just found css odd for the same reason as others.)

Because DeCSS and libdvdcss are not the same thing. It's like calling
acrobat the pdf USE flag: yeah Acrobat produces and read PDF, but it's
not Acrobat you're enabling.

libdvdcss uses part of the code of DeCSS to do its work, but it is not
DeCSS proper.

-- 
Diego Flameeyes Pettenò
http://farragut.flameeyes.is-a-geek.org/


pgp85UDAW9VS6.pgp
Description: PGP signature


[gentoo-dev] Re: [RFC] global useflags

2008-02-14 Thread Diego 'Flameeyes' Pettenò
Peter Volkov [EMAIL PROTECTED] writes:

 Seems that this arose from media-libs/libdvdcss... Can we rename this to
 dvdcss to make it clear that this have something to do with dvds and not
 with web technologies?

I'd actually agree on this, while css is currently just used for Content
Scramble System, I don't think we're going to have that mainstream
anytime soon. This CSS is tied to the DVD technology that people are
trying to replace (also because of the CSS debacle); the Cascading Style
Sheet is, well, not going to disappear anytime soon, in my opinion.

While changing an USE flag on the run is not a nice thing for users, I
think that disambiguating this is a good idea. _While_ users are
supposed to look up USE flags, it's no use to call, for instance, tar
the support for Tape Audio Recording, just because there was no tar
USE flag before ;)

So +1 from me for css - dvdcss renaming.

-- 
Diego Flameeyes Pettenò
http://farragut.flameeyes.is-a-geek.org/

-- 
gentoo-dev@lists.gentoo.org mailing list



[gentoo-dev] Re: [RFC] global useflags

2008-02-14 Thread Diego 'Flameeyes' Pettenò
Wulf C. Krueger [EMAIL PROTECTED] writes:

 Where is the pressing need to do that? Again, which current package would 
 use a re-defined css USE flag?

No package would use it, and there is no _pressing_ need. I still think
it's nicer to let the user understand. What if we had qt referring to
quicktime, and no qt package just yet? Would it be okay for you not to
be able to understand without looking up the flag if qt referred to
QuickTime or TrollTech's Qt? (being all downcase helps not here,
capitalisation would have helped distinguish between the two).

 I don't think any user will expect media-video/undvd, app-cdr/k3b or 
 media-video/cinelerra-cvs to support cascading style sheets but rather 
 the other CSS stuff. :-)

This assumes that users know that there are _two_ CSS
technologies. Which I sincerely doubt. Note that even Wikipedia defaults
CSS to Cascading Style Sheet. While it can't say anything aboug Gentoo
users, it says a lot on how that particular acronym is perceived among
the general public.

And I see no compelling reason to stick with a bad choice just for the
sake of not renaming an USE flag, when the alternative is to actually
give back sanity to the flag naming.

-- 
Diego Flameeyes Pettenò
http://farragut.flameeyes.is-a-geek.org/

-- 
gentoo-dev@lists.gentoo.org mailing list



[gentoo-dev] Re: [RFC] global useflags

2008-02-13 Thread Diego 'Flameeyes' Pettenò
Markus Meier [EMAIL PROTECTED] writes:

 hdf5: Adds support for the Hierarchical Data Format v5

And what the heck is the Hierarchical data Format v5? :P But I admit
it's still better than Adds support for HDF v5...

 djvu: Enable djvu support

Not much more useful than just djvu. beside the capitalization should
be DjVu (iirc), it would be nice to say at least what DjVu is supposed
to be...

 cxx: Enable support for C++

I'd rather use Builds support for C++ (bindings, extra libraries, code
generation, ...)

 css: Enables ripping of encrypted DVDs

Are we sure that nothing intends css as Cascading Style Sheet?

 fontconfig: Support for managing custom fonts via
 media-libs/fontconfig

A bit better, but it's not to manage custom fonts, more like custom
fonts options...

 highlight: Enable source code highlighting

Uh? I don't really want to look what does make that an option worth an
USE flag...

 cvs: Enable CVS (Concurrent Versions System) support

Maybe integration rather than support, if it's always integration
that is enabled...

-- 
Diego Flameeyes Pettenò
http://farragut.flameeyes.is-a-geek.org/


pgp5fohpgFJfm.pgp
Description: PGP signature


[gentoo-dev] Re: [RFC] Reducing the size of the system package set

2008-01-08 Thread Diego 'Flameeyes' Pettenò
Donnie Berkholz [EMAIL PROTECTED] writes:

 What is your goal? Is there something you're trying to accomplish that's 
 impossible? It's clear that changing this would be a fair amount of 
 work, and I don't understand the benefits.

With the current size of system packages set, having a complete deptree
is impossible. You're one of the main followers of the idea that if a
package is in system you don't have to depend on it, and I already
talked to you about the problems there are with emerge -e world when for
instance zlib is broken.

So my goals are:
 - have a deptree as complete as possible;
 - being able to have an emerge -e world that actually builds first the
 stuff that's going to be needed (zlib before packages using zlib);
 - avoid overriding the system package set in profiles like embedded
 where stuff like autoconf and perl might not be wanted on the resulting
 filesystem.

The first goal is a prerequisite if we want to move to other stuff like
a true multilib-handling package manager (we don't want to force down
the users' throats multiple copies of autoconf, considering it's a
script, do we?) or proper cross-building environments.

-- 
Diego Flameeyes Pettenò
http://farragut.flameeyes.is-a-geek.org/


pgpYLuxQrTHV9.pgp
Description: PGP signature


[gentoo-dev] Re: [RFC] Reducing the size of the system package set

2008-01-08 Thread Diego 'Flameeyes' Pettenò
Brian Harring [EMAIL PROTECTED] writes:

 Don't suppose you have a url for their reasoning? 

https://bugs.gentoo.org/show_bug.cgi?id=151758

-- 
Diego Flameeyes Pettenò
http://farragut.flameeyes.is-a-geek.org/

-- 
gentoo-dev@lists.gentoo.org mailing list



[gentoo-dev] Re: Projects and subproject status

2008-01-07 Thread Diego 'Flameeyes' Pettenò
Luca Barbato [EMAIL PROTECTED] writes:

  - video: Hopefully nothing much beside trying to give the best and
 freshest snapshots from the repository you started to know (mplayer,
 ffmpeg, xine, vlc...Hi Diego =))
I'm involved just in one and a half of those ;)

As for me, I mostly handle PAM (solo as usual).

Current status: PAM 0.99 is stable on all architectures beside one,
which means that PAM maintenance should be quite easier. It has been a
few months till last release so the water is also quite calm. The
upgrade was smooth for most people up to now, hopefully the
documentation on that will suffice.

Future plans: I hope to be able to complete the developers'
documentation, it's mostly a matter of finding time to work on it again,
probably I won't be able to make it before February, but I count on
writing something starting mid-february.

And for what concerns PulseAudio:

Current status: 0.9.8 is in tree for a while but contains a few new
features that should be tested well before marking it stable, so 0.9.7
is the current candidate. The new init script using Baselayout 2/OpenRC
functionalities is well tested at this point and mostly waiting for
OpenRC to enter ~arch.
Future plans: again not before mid-february I'll see to write some user
documentation about PulseAudio, like a Gentoo-specific Perfect Setup, to
integrate the generic documentation available on PulseAudio's wiki.

As for other misc stuff I maintain, I don't know exactly what's left,
but you can easily see what I'm doing on the blog :P

-- 
Diego Flameeyes Pettenò
http://farragut.flameeyes.is-a-geek.org/


pgpYdZPjU9Epq.pgp
Description: PGP signature


[gentoo-dev] [RFC] Reducing the size of the system package set

2008-01-07 Thread Diego 'Flameeyes' Pettenò

Here comes the official proposal, copy and paste from my blog with an
extra post scriptum at the end.

I already ranted about the fact that the dependency tree of our ebuilds
is vastly incomplete, as many lack dependency on zlib; trying to get
this fixed was impossible, as Donnie and other insisted that as zlib was
in system, we shouldn’t depend on it at all. I disagree, and I would
like to know why we can’t depend on a system package, but whatever.

Anyway, as having a complete dependency tree is almost impossible
because of that, I have an alternative proposal: reducing the size of
the system package set.  Right now system contains stuff like ncurses,
readline, zlib, autoconf, automake and m4, perl, gnuconfig, and so
on. Those are packages that certainly would be part of any base Gentoo
system, but are those actual part of the system set of packages? I
sincerely doubt it.

The reason of the existence of the system package set is related first
and foremost to breaking circular dependencies: for instance if any
package that used the C compiler would depend on gcc, then the packages
that gcc depends upon would create a circular dependency between gcc and
itself. Also, specifying libc in almost any ebuild would be quite
pointless, as well as coreutils (or freebsd-bin/ubin) for cp, mv,
install, …

But why autoconf and automake? Well the easy answer is that those are
often used without making sure they are depended upon explicitly… or at
least this was the case till me and Martin added autotools.eclass to the
tree; nowadays all the ebuilds using autotools should have proper
autoconf/automake dependency already, and if they don’t they are broken
anyway. So why leaving them in system? And what about m4? m4 is not part
of a common Unix system, it’s just an autoconf dependency, why isn’t it
just an autoconf dependency?

For what concern the three main libraries, there aren’t that many
packages using zlib directly nowadays, this is especially easy to spot
on a system built with --as-needed, as without that you actually do see
zlib used in every other binary, for indirect dependencies. Nor there
aren’t tons and tons of packages using readline, or ncurses. Actually in
my own vserver’s chroot I only found four packages using readline, none
of them part of system: ruby with the readline extension (uhm I wonder
if I should ask for this to become an USE flag, I certainly don’t need
it and I’d rather get rid of it), psql from postgresql (which maybe it’s
still good to have with readline compiled in, but I could easily get rid
of), bc (which is just an e2fsprogs build-dep, and I could build without
readline just fine), and mysql.

A little bit different the status of ncurses, which is used by screen,
gettext (only a build-dep, not needed for runtime on Linux anyway),
procps, psmisc and util-linux (and I wonder why we don’t have a switch
to turn it off), texinfo (wonder why we can’t remove it entirely
actually) and yet again ruby. Still, I wonder why ncurses is in system
rather than being properly on the dependencies list of those packages.

As for perl, that’s probably a bit more justified, there are tons of
packages using perl directly or indirectly, especially in build
systems. But I would like those to depend on perl properly rather than
having perl in system, as there are cases where perl is not really
needed at runtime at least.

And the only users of gnuconfig are the packages making use of the old
and deprecated gnuconfig.eclass, or portage’s econf. Why can’t it be a
dependency of portage then?

There are probably other packages that should, in my opinion, be removed
From system, but these are certainly some of the most
common. Unfortunately there’s a recursive problem here: to remove the
packages from system without breaking stuff you’d need a proper deptree,
and to get a proper deptree you need to remove the packages from
system. This is what actually stops me from proposing this right away…

P.S.:

So there are more things that were brought to my attention, like ssh,
flex, bison, e2fsprogs, and so on. We should probably look into what to
keep, rather than what to remove.

Also, rocket proposed me to try building a stage with a slimmed down
system. I could try, but it would be a waste of time if we then decide
not to go this route, and that's _a lot_ of time that would go to waste,
so I'd rather first see what the other devs think, before going to do
the actual tests.

-- 
Diego Flameeyes Pettenò
http://farragut.flameeyes.is-a-geek.org/


pgpj6JMlVTszU.pgp
Description: PGP signature


[gentoo-dev] Last rites for media-fonts/mikachan-font

2007-02-17 Thread Diego 'Flameeyes' Pettenò
As per summary, I've just masked mikachan-font for removal. Don't panic! I'm 
not removing the mikachan font from portage. This package installs, depending 
on version, either a TTF font (TrueType Fonts files) or a TTC font (TrueType 
Collection); the latter is not compatible with some software, like GD if I 
remember correctly, that expects only TTF fonts.

To get around this problem, mikachan is now split in three packages, each of 
which installs the same fonts in a different format:

media-fonts/mikachan-font-otf OpenType Fonts
media-fonts/mikachan-font-ttf TrueType Fonts
media-fonts/mikachan-font-ttc TrueType Collection

this way you can have fine grained selection of fonts to install.

-- 
Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/
Gentoo/Alt lead, Gentoo/FreeBSD, Video, Sound, ALSA, PAM, KDE, CJK, Ruby ...


pgp4Rpyq2lIaZ.pgp
Description: PGP signature


Re: [gentoo-dev] Google Summer of Code 2007

2007-02-16 Thread Diego 'Flameeyes' Pettenò
On Friday 16 February 2007, Grant Goodyear wrote:
 So, is there support among devs for hosting another round of Summer
 students?  Are there good problems for those students to work on, and,
 if so, what are they?  Were people happy with how last year's program
 went, or should we try to do something different?  For what it's worth,
 I think GSOC is worth putting our effort into, but I'd also like to see
 projects that at least have the potential to benefit more of the
 community than just Gentoo.  *Shrug*

Although last summer I wasn't too involved in the process (I was backup mentor 
for a couple of projects, but there was no need for a backup mentor for any 
of them, and I also passed the august offline), I did think with myself of a 
few issues with what SoC did for Gentoo (and the other way around too).

Out of the 14 projects listed in [1], these are the (public) results:

- I don't know of any GUI frontend to baselayout;
- Antarus's work on CVS migration produced some interesting results, but as we 
know, the migration isn't possible just yet;
- blubb's etc-update replacement is sort of complete, I wasn't able to get it 
to work yet, but at least blubb is still around;
- Gentoo/FreeBSD/AMD64 port is deadish, Victor disappeared for what I can 
tell, there weren't many patches that were followed till merge, and there's 
no near hope to get amd64-fbsd working in short time;
- I have no clue what's going on with gentoo-stats;
- Pioto's dynusers (now creandus, I think) is still work in progress, since 
starting, pioto became a dev;
- I have no clue what's going on with the web-based GuideXML frontend;
- JACK support hasn't moved a bit, if possible it became worse because of 
bitrot, as the student dropped off;
- I have no clue what's going on with NetworkManager, but it might actually 
have seen some work on it, considering it's now in portage, but 
metalgod/steev would probably know better;
- I don't know what happened to qaludis, nor I care to be honest as it's an 
external project;
- I don't know what happened to pkgcore, nor I care to be honest as it's an 
external project;
- Alex completed Gentoo/FreeBSD port of Sandbox, although Martin disappeared 
and thus we're forced to unmask sandbox on our profiles for now, and in the 
mean time he also fixed some FreeBSD bugs;
- I have no clue what's going on with SCIRE;
- I have no clue what's going on with the Xorg configuration too.

I admit I cannot of course judge all the progress, as you can see I have no 
clue on about half the projects, but that also means there wasn't a big new 
feature or fix that everybody knows about.
So maybe, the targets we put were too much fuzzy, and difficult to achieve. Of 
course there's also the big unknown of the students, that we can't easily 
judge if we don't know them.

This covers one point, but what most interest me to point out is that we have 
a real low conversion of developers. What I found interesting in the Summer 
of Code initiative was the ability to find new developers for a project, 
people that wouldn't have been involved in open sources projects otherwise.

We enrolled as students four Gentoo developers, and only one of the 
remaining ten students was converted into a dev.

Added to the little improvements done by the projects, maybe we could have 
spared a few more slots for the organizations that have achieved more.


[1] http://www.gentoo.org/proj/en/devrel/user-relations/summerofcode/

-- 
Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/
Gentoo/Alt lead, Gentoo/FreeBSD, Video, Sound, ALSA, PAM, KDE, CJK, Ruby ...


pgp6MPqCE7guX.pgp
Description: PGP signature


Re: [gentoo-dev] Google Summer of Code 2007

2007-02-16 Thread Diego 'Flameeyes' Pettenò
On Saturday 17 February 2007, Danny van Dyk wrote:
 a) It's _qualudis_ ;-)
Whatever, can we get back on track?

How much good did Google Summer of Code to the Gentoo _community_ ? How much 
the project were of use for the Gentoo (Linux) project?

[1] http://code.google.com/soc/kde/about.html
-- 
Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/
Gentoo/Alt lead, Gentoo/FreeBSD, Video, Sound, ALSA, PAM, KDE, CJK, Ruby ...


pgphnNh7HHtkr.pgp
Description: PGP signature


Re: [gentoo-dev] Re: Google Summer of Code 2007

2007-02-16 Thread Diego 'Flameeyes' Pettenò
On Saturday 17 February 2007, Markus Ullmann wrote:
 Also about last year, are there known improvements other mentoring
 organizations had out of SoC? (Like KDE, GNOME,...)
You can see the projects for KDE at [1], as well for the other organisations, 
but I'm not sure if they published the final overviews that the other 
projects published.

For what I can see by skimming through soc-admins right now, PHP project 
launched a new version of [2] last october, with SoC work embedded; KOffice 
1.6 contains at least two SoC projects results (KFormula and Krita 
improvements), as Luca pointed out FFmpeg got a working VC-1 decoder (and 
WMV3 came with that), and now the AC3 and AMR decoders are getting in shape; 
Amarok got DAAP support half working during SoC and completed afterward (in 
this case the developer was a previous Amarok developer anyway), 1.4.5 have 
working both client and server DAAP support.

For boost you can look at [3], quoting:
| Seven projects were completed or nearly completed and the students are
| expected to ask for a formal review within 2006 or early 2007. Four of
| these projects necessitated a goal reorientation during development,
| basically because the original plan was too ambitious for three months.
| Most of the projects are still in active development during the months
| following the Summer of Code program. Two projects did not reach the
| planned goals, but nevertheless produced useful material that could be
| expanded outside of the Summer of Code program. One project was abandoned
| shortly after the midterm review. The reasons for the abandonment are
| unknown.

And so Adium [4], NetBSD [5], Gallery [6].

There are a few more info that were posted directly on the list and as I'm not 
sure if they were public, so I didn't quote or copy out of them, and I don't 
have a pointer for them as the list is private.
I didn't find anything from us, note even as a post on the list, which is 
somewhat disappointing.

[1] http://code.google.com/soc/kde/about.html
[2] http://gcov.php.net/
[3] http://boost.org/more/boost_soc_06_overview.html
[4] http://www.adiumx.com/blog/2006/10/google-summer-of-code-2006-roundup.php
[5] http://www.netbsd.org/Foundation/press/soc2006-summary.html
[6] http://gallery.menalto.com/summer_of_code/2006/wrapup
-- 
Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/
Gentoo/Alt lead, Gentoo/FreeBSD, Video, Sound, ALSA, PAM, KDE, CJK, Ruby ...


pgp2IIL7RpCjf.pgp
Description: PGP signature


Re: [gentoo-dev] Google Summer of Code 2007

2007-02-16 Thread Diego 'Flameeyes' Pettenò
On Saturday 17 February 2007, Ciaran McCreesh wrote:
 So perhaps next time around mentors should accept concrete proposals
 that are really doable, rather than stuff that just seems shiny. Gentoo
 *could* benefit greatly from SoC, if things are done properly.

Apocalypse day may come soon this year, but for once I agree almost entirely 
with you.

-- 
Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/
Gentoo/Alt lead, Gentoo/FreeBSD, Video, Sound, ALSA, PAM, KDE, CJK, Ruby ...


pgpUWJ8gda9JI.pgp
Description: PGP signature


Re: [gentoo-dev] New network config for baselayout-ng

2007-02-08 Thread Diego 'Flameeyes' Pettenò
On Thursday 08 February 2007, Krzysiek Pawlik wrote:
 Deep Space Nine, then Voyager, then Enterprise... sounds good to me ;)
 baselayout-deep-space-nine ;) Portage would hate such versioning scheme ;)

I would love it, it would be perfect with the naming convention I'm using for 
my boxes :)

/me points to the @enterprise.flameeyes.is-a-geek.org message-id ;)

-- 
Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/
Gentoo/Alt lead, Gentoo/FreeBSD, Video, Sound, ALSA, PAM, KDE, CJK, Ruby ...


pgp6jVcUcQ9oH.pgp
Description: PGP signature


Re: [gentoo-dev] A major change coming in the rox packages

2007-02-08 Thread Diego 'Flameeyes' Pettenò
On Thursday 08 February 2007, Thomas Rösner wrote:
 AFAIR App Dirs provide internal arch distinction, so why not just put it
 in /usr/share/rox?

/usr/share is not a good place for any kind of executable. /usr/lib is more 
suitable for the purpose.

-- 
Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/
Gentoo/Alt lead, Gentoo/FreeBSD, Video, Sound, ALSA, PAM, KDE, CJK, Ruby ...


pgpsHVKNKs8IS.pgp
Description: PGP signature


Re: [gentoo-dev] Network configuration and bash

2007-02-08 Thread Diego 'Flameeyes' Pettenò
On Friday 09 February 2007, Ned Ludd wrote:
 baselayout is only about a half of a meg these days and probably
 getting smaller/faster with the addition of the multicall rc/runscript
 work he has been doing.

 Adding bash also requires ncurses which in turn mostly requires having
 a c++ aware compiler or using the nocxx,minimal flags. Even with those
 flags enabled I'm seeing 3M going to ncurses+bash. So I can for sure
 see the benefits.

 Also for a moment lets stop and think. Some XYZ update breaks
 ncurses/bash. Supporting this gives us a nice alternative way to still
 boot our boxes for rescue using ash or another shell which might not
 have such big deps.

From where I stand I can see Ned's point just fine: I'm interested in both 
having a sane baselayout that doesn't break on bash upgrade (I've seen the 
breakage with 3.1, 3.2.. I also masked bash 3.1 while Roy fixed baselayout 
for that version), and in a baselayout that can run on medium embedded 
systems (and not just for fun, trust me), so I wouldn't dismiss Roy's work 
as unneeded and/or not useful to anyone.

He's not going to waste someone else's time, and as he said there will be 
compatibility with current configuration files, I don't think there's any 
downside to users.

-- 
Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/
Gentoo/Alt lead, Gentoo/FreeBSD, Video, Sound, ALSA, PAM, KDE, CJK, Ruby ...


pgpg13D9POXYc.pgp
Description: PGP signature


Re: [gentoo-dev] Network configuration and bash

2007-02-06 Thread Diego 'Flameeyes' Pettenò
On Tuesday 06 February 2007, Michael Hanselmann wrote:
 XML! Actually, no. For me, libconfig[1] turned out to be very easy to
 work with. Its config file format is easy to write by hand and the
 parser resides in the library.

On a simialr note there's libconfuse[1], which uses one of the most common 
formats available: ini-like :)

[1] http://www.nongnu.org/confuse/
-- 
Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/
Gentoo/Alt lead, Gentoo/FreeBSD, Video, Sound, ALSA, PAM, KDE, CJK, Ruby ...


pgpYWPdBzIKuX.pgp
Description: PGP signature


Re: [gentoo-dev] Last rites for ruby-gnome (1) packages

2007-02-05 Thread Diego 'Flameeyes' Pettenò
On Saturday 03 February 2007, Diego 'Flameeyes' Pettenò wrote:
 dev-ruby/ruby-gtk

Following this, I'll be masking and removing www-client/gorua and 
www-client/ci because they depend on it.
For who needs an alternative to these, ochusha is probably a good idea, 
although it does miss alpha keywording at all at the moment, I'll see to get 
at least some ~alpha keywording.

-- 
Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/
Gentoo/Alt lead, Gentoo/FreeBSD, Video, Sound, ALSA, PAM, KDE, CJK, Ruby ...


pgpbDES0xBmaa.pgp
Description: PGP signature


Re: [gentoo-dev] Last rites for media-sound/poc

2007-02-05 Thread Diego 'Flameeyes' Pettenò
On Monday 05 February 2007, Mike Frysinger wrote:
 can you name another package which provides the features this one does ?
  no ?   then leave it be ... punting a package because upstream is not
 reachable is retarded

You saying you're going to maintain it? :)

Besides, if it's a streamer - can't really tell what else beside a streaming 
software it can be, as upstream is, well, unreachable - bossogg and/or 
icecast will probably cover it.

-- 
Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/
Gentoo/Alt lead, Gentoo/FreeBSD, Video, Sound, ALSA, PAM, KDE, CJK, Ruby ...


pgp7T9UtD5UmB.pgp
Description: PGP signature


Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for February

2007-02-04 Thread Diego 'Flameeyes' Pettenò
On Monday 05 February 2007, Ryan Hill wrote:
 Reply-to and SPF docs?  Isn't this the third month now?

I might be counting wrong, as last time I wasn't there, but it might be the 
fourth, counting the original one.

-- 
Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/
Gentoo/Alt lead, Gentoo/FreeBSD, Video, Sound, ALSA, PAM, KDE, CJK, Ruby ...


pgpmvWvwee2ZP.pgp
Description: PGP signature


[gentoo-dev] Last rites for media-sound/choad

2007-02-03 Thread Diego 'Flameeyes' Pettenò
During today's cleanup this package turned up missing an upstream site or 
sources, the package is mostly unmaintained for a while, jmglov, who's 
currently set as maintainer, is in kloeri's list to be retired.

As there are tons of different tools to do the same thing (rip audio from CD 
to mp3 and tag them), the package will be masked and removed in 30 days, as 
usual.

-- 
Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/
Gentoo/Alt lead, Gentoo/FreeBSD, Video, Sound, ALSA, PAM, KDE, CJK, Ruby ...


pgp0U3Cv6chQ1.pgp
Description: PGP signature


[gentoo-dev] Last rites for media-sound/gradio

2007-02-03 Thread Diego 'Flameeyes' Pettenò
This package too is unfetchable (upstream's site is password protected, wtf?), 
the last release is in 2000, and still using GTK 1.2

Scheduled for removal on March 3rd again.

-- 
Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/
Gentoo/Alt lead, Gentoo/FreeBSD, Video, Sound, ALSA, PAM, KDE, CJK, Ruby ...


pgppOIEcd17xU.pgp
Description: PGP signature


[gentoo-dev] Last rites for media-sound/liteamp

2007-02-03 Thread Diego 'Flameeyes' Pettenò
As per summary, the development seems to be stopped for more than three years 
now, and latest version does not build on either x86 or amd64; one of the old 
versions is not even fetchable anymore.

Unless somebody goes around to fix this, it will be removed March 3rd.

-- 
Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/
Gentoo/Alt lead, Gentoo/FreeBSD, Video, Sound, ALSA, PAM, KDE, CJK, Ruby ...


pgpLpaaUd7r7Z.pgp
Description: PGP signature


[gentoo-dev] Last rites for media-sound/pd-cyclone

2007-02-03 Thread Diego 'Flameeyes' Pettenò
This package was added and never maintained as far as I can see; the version 
in portage is versioned as 0.1_alpha (which is not a good foresight) and has 
incorrect PIC handling.

If nobody gets around fixing this, it is doomed to go away on March 3rd.

-- 
Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/
Gentoo/Alt lead, Gentoo/FreeBSD, Video, Sound, ALSA, PAM, KDE, CJK, Ruby ...


pgp9fhidMic6X.pgp
Description: PGP signature


[gentoo-dev] Last rites for media-sound/mpio

2007-02-03 Thread Diego 'Flameeyes' Pettenò
Another package that hasn't seen releases since 2004; it also requires 
specific hardware to be used (Digitalway/Adtec audio players), currently 
depending on hotplug too.

Unless someone can get around to fix this (and has the hardware to actually 
test this), it will go away on March 3rd.

-- 
Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/
Gentoo/Alt lead, Gentoo/FreeBSD, Video, Sound, ALSA, PAM, KDE, CJK, Ruby ...


pgpIliByTq41w.pgp
Description: PGP signature


[gentoo-dev] Last rites for media-sound/psmix

2007-02-03 Thread Diego 'Flameeyes' Pettenò
This time it's a fantastic package that can save state and window position, 
but what would you expect from a package added in 2002 that seems to still 
use gtk 1.2 (the dependencies aren't cleaned up, it depends on generic gtk+).

It is also unfetchable, so unless someone _really_ wants it, it will go away 
in the usual 30 days.

-- 
Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/
Gentoo/Alt lead, Gentoo/FreeBSD, Video, Sound, ALSA, PAM, KDE, CJK, Ruby ...


pgpujhNqYVuVh.pgp
Description: PGP signature


[gentoo-dev] Last rites for media-video/ks3switch

2007-02-03 Thread Diego 'Flameeyes' Pettenò
Missing upstream, requires an S3 card, even s3switch does not build here at 
all (not sure on x86 right now), so it will be removed on march 3rd unless 
someone can fix this _and_ s3switch.

-- 
Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/
Gentoo/Alt lead, Gentoo/FreeBSD, Video, Sound, ALSA, PAM, KDE, CJK, Ruby ...


pgpU64WW8BvZA.pgp
Description: PGP signature


[gentoo-dev] Last rites for sys-apps/s3switch

2007-02-03 Thread Diego 'Flameeyes' Pettenò
As I've already last rited ks3switch, this one is also going away, as it 
doesn't currently build at all.

Unless someone wants to pick this up (currently unmaintained), it will be 
removed in the usual 30 days.

-- 
Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/
Gentoo/Alt lead, Gentoo/FreeBSD, Video, Sound, ALSA, PAM, KDE, CJK, Ruby ...


pgpzWQvsFIkHa.pgp
Description: PGP signature


Re: [gentoo-dev] New developer: Samuli Suominen (drac)

2007-02-03 Thread Diego 'Flameeyes' Pettenò
On Saturday 03 February 2007, Petteri Räty wrote:
   It's my pleasure to introduce to you Samuli drac Suominen. He is
 joining us to look after the Xfce desktop environment and take care of
 packages that have been proxy maintained before.

YAI! Welcome Samuli, now you can take care of your bugs yourself :)

-- 
Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/
Gentoo/Alt lead, Gentoo/FreeBSD, Video, Sound, ALSA, PAM, KDE, CJK, Ruby ...


pgpJVaGTiAvZW.pgp
Description: PGP signature


[gentoo-dev] Last rites for app-admin/kcmgrunlevel

2007-02-03 Thread Diego 'Flameeyes' Pettenò
As per summary; unfetchable, it's probably incompatible with current 
baselayout, as it was developed in 2004, and the version number suggests an 
alpha/beta version.

If nobody wants to take over maintainership, it will be removed in 30 days.

-- 
Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/
Gentoo/Alt lead, Gentoo/FreeBSD, Video, Sound, ALSA, PAM, KDE, CJK, Ruby ...


pgp3nMjQ3ACgp.pgp
Description: PGP signature


  1   2   3   4   5   6   7   >