Re: [gentoo-dev] cmake.eclass

2006-05-25 Thread Carsten Lohrke
Don't repeat a failure of the past. Do


NEED_CMAKE x.y

inherit foo

...


instead this ugly toplevel function call.


Carsten


pgpkzcuaeL675.pgp
Description: PGP signature


Re: [gentoo-dev] Re: Re: Gentoo Devmanual

2006-05-25 Thread Jakub Moc
Stephen Bennett wrote:
  Two names are credited on the front page. One is conspicuously absent,
 despite having done the vast majority of the original work.

snip
Large portions of the handbook were originally written by Ciaran McCreesh.
/snip

Maybe you need to read more carefully, or need better spectacles? Ah, we
just didn't have a pointless flamewar for a long time, right... :S

-- 
Best regards,

 Jakub Moc
 mailto:[EMAIL PROTECTED]
 GPG signature:
 http://subkeys.pgp.net:11371/pks/lookup?op=getsearch=0xCEBA3D9E
 Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95  B30F 8717 D5FD CEBA 3D9E

 ... still no signature   ;)



signature.asc
Description: OpenPGP digital signature


[gentoo-dev] Re: Re: Re: Gentoo Devmanual

2006-05-25 Thread Peter
On Thu, 25 May 2006 12:34:13 +0100, Stephen Bennett wrote:

snip...
 at a minimum such credit will appear where any other comparable
 authorship credit appears and in a manner at least as prominent as such
 other comparable authorship credit.
 
 Two names are credited on the front page. One is conspicuously absent,
 despite having done the vast majority of the original work.
 
The two names listed are as editors. Plainly, clearly. Ciaranm is clearly
listed alone as a main contributor and author. His name is more
conspicuous than any other. Not to mention on the contributors page where
is name is..first?

 However, Tim and Mark are currently
maintaining the body of work and
 are properly titled as editors. Tim and Mark are devs. ciaranm is not.
 
 What does being a dev have to do with anything?

Tim and Mark are maintaining this. I do not think a non dev would be
permitted to do so.

I've made my point. Any other writings by me on this subject would be
repetitive. Flame me if you feel like it, but please don't forget to
ignore facts along the way.

-- 
Peter


-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] cmake.eclass

2006-05-25 Thread Danny van Dyk
Hi Carsten,

Am Donnerstag, 25. Mai 2006 13:31 schrieb Carsten Lohrke:
 Don't repeat a failure of the past. Do


 NEED_CMAKE x.y

 inherit foo

 ...


 instead this ugly toplevel function call.
And this is no ugly toplevel function fall?
i currently see no major difference between doing 'need-cmake x.y' and 
'NEED_CMAKE x.y'...

Danny
-- 
Danny van Dyk [EMAIL PROTECTED]
Gentoo/AMD64 Project, Gentoo Scientific Project
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Gentoo Devmanual

2006-05-25 Thread Mark Loeser
Jan Kundrát [EMAIL PROTECTED] said:
 Nice job. Are the XML and XSLT sources available from our CVS? I wasn't
 able to find them.

Not yet.  The Contributing page shows where it is currently hosted,
and I'm going to have it moved over to Gentoo infra soon.  I just
haven't gotten around to it yet :)

Thanks,

-- 
Mark Loeser   -   Gentoo Developer (cpp gcc-porting qa toolchain x86)
email -   halcy0n AT gentoo DOT org
  mark AT halcy0n DOT com
web   -   http://dev.gentoo.org/~halcy0n/
  http://www.halcy0n.com


pgpI9MDgupHFZ.pgp
Description: PGP signature


Re: [gentoo-dev] Gentoo Devmanual

2006-05-25 Thread Grant Goodyear
Mark Loeser wrote: [Thu May 25 2006, 12:39:56PM CDT]
 I changed Authors to be Editors.  I hope that will kill some of the
 controversy.

Thanks.  That should certainly satisfy the license, and I, at least,
appreciate it.

 Ciaran, we recognized you on the front page and appreciate everything
 you did.  We cut the author list from the front page because it was
 getting incredibly long and we didn't feel it should take up that much
 room.  The only reason Tim and myself are listed there is because we are
 the ones maintaining it now, and want people to be able to easily find
 who they should contact about changes.

For what it's worth, I never suspected otherwise.  (Nor, I suspect, did
ciaranm, although I haven't asked him.)  Despite the lack of any
intentional malice, however, I do happen to believe that removing the
author list from the front page is a serious error that is worth fixing.
Giving people appropriate credit for writing documentation is just the
right thing to do, and that credit shouldn't be buried somewhere.
Indeed, my recollection was that a fair amount of thought went into
where the author list should go when drobbins created our documentation
XSL.

That said, I would certainly agree that a long list of authors, with one
author per line, down the center of the page would, indeed, not look so
good.  A simple set of names (with links to the contributors page which
provides additional detail, perhaps) would suffice, I'd think:

Authors
---

  Ciaran McCreesh, Grant Goodyear, Aaron Walker, Robert Coie, Tom
  Martin, Paul Varner, Ilya Volynets-Evenbakh, Diego Patteno Fernando J.
  Pareda, Simon Stelling, Alin Dobre, and Joseph Jezak

Seem reasonable?

-g2boojum-
-- 
Grant Goodyear  
Gentoo Developer
[EMAIL PROTECTED]
http://www.gentoo.org/~g2boojum
GPG Fingerprint: D706 9802 1663 DEF5 81B0  9573 A6DC 7152 E0F6 5B76


pgpnsnhtBOAF8.pgp
Description: PGP signature


Re: [gentoo-dev] Gentoo Devmanual

2006-05-25 Thread Grant Goodyear
Mark Loeser wrote: [Wed May 24 2006, 04:37:44PM CDT]
 Grant Goodyear [EMAIL PROTECTED] said:
  How was the conversion done?  Do we now have a tool to convert rst to
  guidexml, or was the conversion all done by hand (which would be a truly
  frightening thought), or something else entirely?
 
 Be prepared to be frightened then, because it was all done by hand :)

I'm certainly not complaining; I'm quite grateful that this document is
being maintained!  I am curious, though.  I thought that neysx had made
all of the desired modifications to guide-xml so that the dev guide
could be translated to standard guide-xml.  Is something still missing?

-g2boojum-
-- 
Grant Goodyear  
Gentoo Developer
[EMAIL PROTECTED]
http://www.gentoo.org/~g2boojum
GPG Fingerprint: D706 9802 1663 DEF5 81B0  9573 A6DC 7152 E0F6 5B76


pgpvfz7sZ6efE.pgp
Description: PGP signature


Re: [gentoo-dev] et_EE locale and language of error messages

2006-05-25 Thread Mike Frysinger
On Wednesday 24 May 2006 07:42, Jakub Moc wrote:
 Every other user that is asked to provide the messages with locales set
 to C comes back asking how do I do it. Then they come back saying, oh
 LC_ALL=C, or LC_MESSAGES=C didn't work, where do I put it exactly? Then
 they come back and say, oh, it still didn't work... Also, asking someone
 to provide errors in English when they occured say 10 hours into OO.org
 compile makes the user really happy, of course. :P

update the bugzilla howto guide then and point them to that
-mike


pgpH28U5mijjD.pgp
Description: PGP signature


Re: [gentoo-dev] Proposed package move

2006-05-25 Thread Mike Frysinger
On Wednesday 24 May 2006 08:04, Chris Gianelloni wrote:
 On Tue, 2006-05-23 at 22:09 -0400, Mike Frysinger wrote:
  On Tuesday 23 May 2006 21:18, Donnie Berkholz wrote:
   Mike Frysinger wrote:
On Thursday 18 May 2006 06:41, Paul de Vrieze wrote:
The package sys-apps/paludis is in the wrong category. It is a
package manager on par with rpm, dpkg, etc. Those live in app-arch.
   
app-arch is for things that manage archives
   
paludis is much more than an archive manager
  
   Do you propose we also move app-arch/rpm and app-arch/dpkg to wherever
   paludis goes?
 
  you could make an argument for rpm but not dpkg
 
  dpkg is used simply to manipulate .debs, it isnt apt-get

 Huh?  You can use dpkg directly to install software, just like rpm.  It
 would be like saying that rpm doesn't count because it isn't up2date
 or yum.

then you have a pretty simple choice ... either portage moves to app-arch as 
well or we look at it being a Gentoo thing

Gentoo package managers are critical thus sys-apps ... all other package 
managers are not critical thus app-arch
-mike


pgpl5RhbVkobU.pgp
Description: PGP signature


[gentoo-dev] no need to CONFIG_PROTECT /usr/kde/2/share/config

2006-05-25 Thread Jakub Moc
Please, finally kill this thing from CONFIG_PROTECT in
base/make.defaults, we are not Debian... :P

Thanks.

-- 
Best regards,

 Jakub Moc
 mailto:[EMAIL PROTECTED]
 GPG signature:
 http://subkeys.pgp.net:11371/pks/lookup?op=getsearch=0xCEBA3D9E
 Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95  B30F 8717 D5FD CEBA 3D9E

 ... still no signature   ;)



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] cmake.eclass

2006-05-25 Thread Panard
Ok, 
I removed need-cmake function and add :

if [ ! -z ${NEED_CMAKE} ]; then
DEPEND=dev-util/cmake
else
DEPEND==dev-util/cmake-${NEED_CMAKE}
fi
RDEPEND=

is it ok ?

http://backzone.net/~panard/patches/gentoo-overlay/eclass/cmake.eclass

Panard


Le Jeudi 25 Mai 2006 13:31, Carsten Lohrke a écrit :
 Don't repeat a failure of the past. Do


 NEED_CMAKE x.y

 inherit foo

 ...


 instead this ugly toplevel function call.


 Carsten

-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] cmake.eclass

2006-05-25 Thread Panard
Le Jeudi 25 Mai 2006 23:15, Mike Frysinger a écrit :
 use this instead ... makes for cleaner output:
 pushd ${BUILDDIR}  /dev/null

Yes... in fact i was using cd; cd $OLDPWD to avoid that /dev/null issue...

I've update the eclass.

Thanks


 otherwise i dont have any other real complaints ;P
 -mike

-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Gentoo Devmanual

2006-05-25 Thread Ciaran McCreesh
On Thu, 25 May 2006 14:37:57 -0500 Grant Goodyear [EMAIL PROTECTED]
wrote:
| That said, I would certainly agree that a long list of authors, with
| one author per line, down the center of the page would, indeed, not
| look so good.  A simple set of names (with links to the contributors
| page which provides additional detail, perhaps) would suffice, I'd
| think:
snip
| Seem reasonable?

That sounds good to me. It'd certainly be more in line with the level
of credit (you know, that thing that's used in place of paying people
or plying them with copious amounts of booze) that was originally given
to contributors.

-- 
Ciaran McCreesh
Mail: ciaran dot mccreesh at blueyonder.co.uk


-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] cmake.eclass

2006-05-25 Thread Danny van Dyk
Am Freitag, 26. Mai 2006 00:50 schrieb Panard:
 I removed need-cmake function and add :

 if [ ! -z ${NEED_CMAKE} ]; then
 DEPEND=dev-util/cmake
 else
 DEPEND==dev-util/cmake-${NEED_CMAKE}
 fi
 RDEPEND=

 is it ok ?
Rather use

  DEPEND=dev-util/cmake-${NEED_CMAKE+-${NEED_CMAKE}}

please.

Danny
-- 
Danny van Dyk [EMAIL PROTECTED]
Gentoo/AMD64 Project, Gentoo Scientific Project
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] cmake.eclass

2006-05-25 Thread Diego 'Flameeyes' Pettenò
On Friday 26 May 2006 01:10, Danny van Dyk wrote:
   DEPEND=dev-util/cmake-${NEED_CMAKE+-${NEED_CMAKE}}
And see it die of a strange death missing the = in front?

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


pgpbqO0tFujdd.pgp
Description: PGP signature


Re: [gentoo-dev] cmake.eclass

2006-05-25 Thread Danny van Dyk
Am Freitag, 26. Mai 2006 01:10 schrieb Danny van Dyk:
 Am Freitag, 26. Mai 2006 00:50 schrieb Panard:
  I removed need-cmake function and add :
 
  if [ ! -z ${NEED_CMAKE} ]; then
  DEPEND=dev-util/cmake
  else
  DEPEND==dev-util/cmake-${NEED_CMAKE}
  fi
  RDEPEND=
 
  is it ok ?

 Rather use

   DEPEND=dev-util/cmake-${NEED_CMAKE+-${NEED_CMAKE}}

 please.
Sigh, too tired. I meant
  DEPEND=dev-utils/cmake${NEED_CMAKE+-${NEED_CMAKE}}
of course.

Danny
-- 
Danny van Dyk [EMAIL PROTECTED]
Gentoo/AMD64 Project, Gentoo Scientific Project
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] move CONFIG_PROTECT to ebuilds out of profiles

2006-05-25 Thread Tuan Van
Mike Frysinger wrote:

 wtf is /usr/share/config for ?

kde-env covers that one.

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



[gentoo-dev] [ANNOUNCE] New eselect modules for blas, cblas, lapack

2006-05-25 Thread Donnie Berkholz
With great pleasure, I announce the testing release of new eselect
modules for BLAS, CBLAS and LAPACK implementations. You may say, But we
already have 'eselect blas' and 'eselect lapack,' Donnie! What are you
thinking? In reply, I would say, The current eselect modules have many
limitations.

One of the main problems with the existing setup is that available
implementations are hardcoded into the modules rather than being
autodetected from the system. This just doesn't scale well, and it ties
upgrades and changes to BLAS/LAPACK/whatever into a required update of
eselect.

A point of disagreement between Danny van Dyk (Kugelfang) and myself is
handling systems with multiple libdirs (e.g., AMD64). To understand our
quandary, you'll first need to understand how the new modules work.

My opinion is that if you want to switch implementations, you should be
warned if any available libdir failed to switch to the implementation
you selected. The tradition of Unix tools says they should be silent
when everything works as expected and be loud on errors.

Not switching for all libdirs when you explicitly said you wanted to
switch your whole system is an error, even if the implementation isn't
currently available for all your libdirs. Anything else will require
adding hackish special cases to the code and doesn't fit with my model
of how the modules should work.

Danny thinks instead that the modules should list all libdirs for which
the implementation was changed rather than warn about libdirs for which
it wasn't. This opposes the Unix philosophy. Danny also thinks that the
modules should silently fail when no implementations are available for a
 certain libdir when the user wants to switch the whole system. I
disagree and think the modules should warn the user.

In addition, Danny brings up a specific subprofile on amd64 called
no-symlink, in which lib32, lib, and lib64 are all directories rather
than symlinks. He says the 'lib' directory is only for arch-independent
(ABI-independent) files, so we should also add a special case for that.
Knowing my hatred of special casing, you may guess I disagree.

The main issue needing resolution is whether to warn on failures to
switch given libdirs when trying to switch the whole system, or whether
to say which successfully switched. One way is the Unix philosophy, and
the other way is ... something else.

Without further ado, you may get all the ported BLAS/CBLAS/LAPACK
implementations as well as the new eselect modules from my overlay [1].
They will remain there until more widespread testing is completed.

Please post all responses ONLY to the gentoo-dev list (unless you aren't
subscribed, in which case you can reply to whichever list you're
subscribed to).

Thanks,
Donnie

1. http://dev.gentoo.org/~spyderous/overlay/



signature.asc
Description: OpenPGP digital signature