Re: [gentoo-dev] nss_* and system users

2006-06-16 Thread Diego 'Flameeyes' Pettenò
On Friday 16 June 2006 05:03, Mike Frysinger wrote:
 nss is glibc-only, so such a solution would be inadequate
Actually this is one of the strange and rare cases that's not only glibc's. 
FreeBSD can use nss too :)

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


pgpc6fXCqO0w4.pgp
Description: PGP signature


Re: [gentoo-dev] New Forums Staff : NeddySeagoon

2006-06-16 Thread George Prowse
On 15/06/06, Curtis Napier [EMAIL PROTECTED] wrote:
Shyam Mani wrote: Hi everyone, Please take a moment to welcome our latest addition to the Forums gang, Roy Bamford aka NeddySeagoon.Thanks for volunteering your time Roy, we will all benefit from your
extensive knowledge and your patience with n00bs.--Curtisand his extensive knowlege of punch card technology :)George


[gentoo-dev] Re: Re: A heretical thought? Blessing project sunrise as an almost-fork.

2006-06-16 Thread Duncan
Chris Gianelloni [EMAIL PROTECTED] posted
[EMAIL PROTECTED], excerpted below, on 
Thu, 15 Jun 2006 14:39:35 -0400:

 On Thu, 2006-06-15 at 19:18 +0100, Stuart Herbert wrote:
 Hi Kevin,
 
 On 6/15/06, Kevin F. Quinn [EMAIL PROTECTED] wrote:
  I read the should as
  implying that all new packages must have it, and packages existing
  before the introduction of metadata should get it as and when
  maintainer gets around to it (i.e. at least on the next bump).
 
 Chris's argument was that this doc _requires_ packages to belong to
 herds (specifically, that all packages that are games automatically
 belong to the games herd).  The document clearly doesn't support his
 argument.
 
 I said no such thing.
 
 This is clearly a case of you trying to assume what I'm saying in such a
 way that it matches with what you want me to say.

I'd take exception to that clearly, as I don't see that being the case
at all, so it's clearly as mudly, to coin a phrase.  g

 I said that all games in the tree should be in the games herd.  We like
 it this way.  Trying to make it out like I said something that I didn't
 does what for you, exactly?

To me (and evidently to Stuart H), those say exactly the same thing, that
is:

Stu H (arguing that this is what you said, but against the viewpoint):
 this doc _requires_ packages to belong to herds (specifically, that
 all packages that are games automatically belong to the games herd).

to me is so similar as to be equivalent to:

Chris G:
 I said that all games in the tree should be in the games herd.

It has long been my personal observation that many arguments aren't in
fact arguments at all, once the meaning assigned by the different sides to
each word is translated.  That may or may not be the case here, but it's
certainly true that I (and evidently Stu H) see no difference between the
the two statements above, while you vehemently argue there IS a
difference, and that in fact it's apparently so clear that someone must be
deliberately distorting your statement to make it into the other.  (OK,
that's what I read into Trying to make it out like I said something I
didn't, but to be entirely fair, maybe you mean something different there
than the way I read it too?)

That being the case, perhaps if you could try to explain what you see as
the difference between the two statements, the discussion can progress
beyond this point.  It does (to me) seem useless to continue, if what
appears to be the very basic difference of whether the two above
statements are effectively equivalent cannot be resolved.  The arguments
are just going past each other, since the two sides apparently are arguing
different things due to differences in received meanings.

(General observation...  It generally does little to progress a
discussion, and much to heat it up, when someone accuses the other side of
deliberate distortion, when it may rather be a basic definitional
difference, and therefore not deliberate at all.  Even if there's no
conceivable way you can see that the opposing viewpoint makes sense, it's
generally far more conducive to progress to assume an honest attempt at
understanding on the part of the other side, an honest misunderstanding,
and try to find the definitional difference, than to heat up the
discussion by saying something is clear, when it's obviously not or the
statement wouldn't have been made in the first place.  That said, both
sides continued the discussion past the point where it was obvious this
was a sticking point, rather than stopping right there to address it, so
both sides are guilty. I just picked this point to step in and ask for the
clarification myself, since I honestly don't see the difference in the
two statements you say are so different, myself.)

-- 
Duncan - List replies preferred.   No HTML msgs.
Every nonfree program has a lord, a master --
and if you use the program, he is your master.  Richard Stallman

-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] nss_* and system users

2006-06-16 Thread Chris Gianelloni
On Thu, 2006-06-15 at 21:36 -0400, Mike Kelly wrote:
 Hi,
 
 As part of my original plans for my GLEP27 implementation, I was
 going to have my scripts automatically add the users requested by a
 package (for example, the cron user), to all the passwd backends
 listsed in /etc/nsswitch.conf. However, in consultation with some
 folks, it seems that what may be more desirable is to just add
 users/groups to the local files/compat backends instead, and not make
 any changes to the remote databases.
 
 Does anyone have any strong notion of any cases where it would be
 excessively bad for the package manager to try adding to, say, the
 nss_nis backend in addition to the nss_files backend, or cases where
 that would be a strongly desired behavior?

bad == many places use a ro backend for auth w/ mysql/ldap/etc

Writing to the local files would be acceptable with me.  I'm sure
someone will come up with an objection, though.

-- 
Chris Gianelloni
Release Engineering - Strategic Lead
x86 Architecture Team
Games - Developer
Gentoo Linux


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


Re: [gentoo-dev] nss_* and system users

2006-06-16 Thread Chris Gianelloni
On Fri, 2006-06-16 at 08:42 -0500, Grant Goodyear wrote:
 Mike Kelly wrote: [Thu Jun 15 2006, 08:36:25PM CDT]
  As part of my original plans for my GLEP27 implementation, I was
  going to have my scripts automatically add the users requested by a
  package (for example, the cron user), to all the passwd backends
  listsed in /etc/nsswitch.conf. However, in consultation with some
  folks, it seems that what may be more desirable is to just add
  users/groups to the local files/compat backends instead, and not make
  any changes to the remote databases.
  
  Does anyone have any strong notion of any cases where it would be
  excessively bad for the package manager to try adding to, say, the
  nss_nis backend in addition to the nss_files backend, or cases where
  that would be a strongly desired behavior?
 
 I think it's unlikely that one would want to add an account to both
 files and nis/ldap, but there's no good reason that I can think of not
 to let the user choose.  That said, I'm not exactly an uber-sysadmin.
 One thing that I might think would be common, though, would be to have
 system accounts pre-defined in ldap/nis, with the expectation that your
 scripts would look up the remote values and then create local accounts
 with those values.  Anybody who actually has a clue want to chime in?

Most things *should* not to *anything* if the account exists in
mysql/ldap/nis/etc as the account is already present.  It's just the
case of it *not* existing that causes the real problem.

 
 Oh, it might be a good idea to ask in [EMAIL PROTECTED], too.
 
 -g2boojum-
-- 
Chris Gianelloni
Release Engineering - Strategic Lead
x86 Architecture Team
Games - Developer
Gentoo Linux


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


[gentoo-dev] using specific gcc-version in ebuild

2006-06-16 Thread Sven Köhler
Hi,

i just wanted to ask, if the is an eclass or something else, that
enables me to temporarly select a certain gcc-version? or perhaps just
finding the path to the gcc and g++ executables of a specific
gcc-versions (like gcc-3.*)?

some software, like qemu and others, are simply not compatible with gcc
4.x and they will not become compatible due to severe conceptional issues.

So is there already something i could use?

Thanks,
  Sven



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] using specific gcc-version in ebuild

2006-06-16 Thread Joshua Jackson
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Forcing a change in your gcc version for compiling is less then
optimal. I don't believe the eclass has anything in it that will help
in what you are trying to do. I would probably do a pkg_setup with a
check for the version of gcc if it isn't a 3.* version then you exit
building and give the reason for this...This would probably be the
best way to do it, at this point.

[EMAIL PROTECTED] wrote:
 What about gcc-config - will that work?
 From: Sven Köhler [EMAIL PROTECTED] Date: 2006/06/16 Fri PM
 03:10:08 EDT To: gentoo-dev@lists.gentoo.org Subject:
 [gentoo-dev]  using specific gcc-version in ebuild





-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEkwcUSENan+PfizARAjLdAJ9u6zhasuWe4AT5x3+rcOAMlgqovwCeLPNf
NLU57K0Bl7uuneLhujKRLck=
=nSTb
-END PGP SIGNATURE-

-- 
gentoo-dev@gentoo.org mailing list



[gentoo-dev] Announce: Distro independent OSS QM Project

2006-06-16 Thread Enrico Weigelt

Hi folks,


I'm maintaining patches with fixes for dozens of packages for 
quite some time. These patches are needed since releases are 
often quite broken (ie. crosscompiling doesn't work) or there 
are other things which make sysop's or distro maintainer's 
life evrything but easy.

Most of the patches are just (little) fixes to get the packages
built properly or provide a finer build configuration. I had to 
learn that such things tend to require quite a long time to
get into the upstream.

So I'm maintaining a repository of patches which is directly used
by my distro builder (I've got my own buildsystem a little bit 
like emerge, but specialized on building for foreign systems
using sysroot'ed crosscompiling, etc, mainly for embedded systems)

Since many distros maintain their own patch repositories and 
ivest mucht work in QM each by their own, I'd like to get these
efforts merged to one great OpenSource QM project. 

The idea behind is:

+ Each individual release of a certain package is inspected
  by its own. 
+ The OSS-QM provides patches (hotfixes) for each individual 
  release, if necessary.
+ We've got several quality stamps, which an (maybe patched)
  release can get, ie. 
  * clean builds
  * clean installations
  * relocation capabilities (ie. GNU's or FHS style)
  * optimization capabilities (ie. can proper CFLAGS be passed ?)
  * stability (open bugs ? unsolved problems ? ...)
  ...
  

I've written down some lines about this project in my wiki:

http://wiki.metux.de/public/OpenSource_QM_Taskforce
 
 
Maybe someone here's interested in it ?


cu
-- 
-
 Enrico Weigelt==   metux IT service

  phone: +49 36207 519931 www:   http://www.metux.de/
  fax:   +49 36207 519932 email: [EMAIL PROTECTED]
  cellphone: +49 174 7066481
-
 -- DSL ab 0 Euro. -- statische IP -- UUCP -- Hosting -- Webshops --
-
-- 
gentoo-dev@gentoo.org mailing list



[gentoo-dev] Re: using specific gcc-version in ebuild

2006-06-16 Thread Sven Köhler
 some software, like qemu and others, are simply not compatible with gcc
 4.x and they will not become compatible due to severe conceptional issues.
 
 then they stay broken ... add a warning to the ebuild if `gcc-major-version` 
 is 4 (see toolchain-funcs.eclass)

Hmm, but ...

there is the possibility to have multiple gcc versions installed. So why
not set CC and/or CXX variables inside the ebuild, and then compile the
app with the right gcc-version?

At this point, it just bugs me, that gentoo is staying below its potential.

Well, hmmm, you might want to say, that there will be trouble because of
applications/libraries linked to different libstdc++ versions - or
something else.

I'm always willing to learn, but this really bugs me, because gentoo
really has potential for what's needed in this situation.



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Re: using specific gcc-version in ebuild

2006-06-16 Thread Arek (James Potts)

Sven Köhler wrote:

some software, like qemu and others, are simply not compatible with gcc
4.x and they will not become compatible due to severe conceptional issues.
  
then they stay broken ... add a warning to the ebuild if `gcc-major-version` 
is 4 (see toolchain-funcs.eclass)



Hmm, but ...

there is the possibility to have multiple gcc versions installed. So why
not set CC and/or CXX variables inside the ebuild, and then compile the
app with the right gcc-version?

At this point, it just bugs me, that gentoo is staying below its potential.

Well, hmmm, you might want to say, that there will be trouble because of
applications/libraries linked to different libstdc++ versions - or
something else.

I'm always willing to learn, but this really bugs me, because gentoo
really has potential for what's needed in this situation.

  
Well, the problem here is that compiling some packages with one version 
of GCC and others with another version of GCC (on the same system) is 
asking for trouble.  This means that ebuilds shouldn't change the GCC 
version in use.  If the user wants to try it and see if it works, let 
them have at it, but don't do it automatically - it *will* eventually 
break someone's system (maybe not with 3.4+4.0/4.1, but who knows with 
future versions...remember the migration from GCC 3.3 to 3.4?).


--Arek

P.S.  Who knows...eventually these incompatible packages might just make 
the move to GCC 4 (possibly on a major update).  Until they do, tho, 
they'll just have to be broken (which is a shame...I like qemu).

--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Herds suck, fix them

2006-06-16 Thread Christel Dahlskjaer
On Thu, 2006-06-15 at 00:26 -0500, Lance Albertson wrote:
 Alec Warner wrote:
  So apparently they suck, anyone have a new shiny idea on how to group
  packages and maintaining developers?

How exactly does one go about maintaining our developers? ;)

 I suggest we create a murder of developers! Then we can be cool and not
 suck! :-)

And hundreds of crows just flew past my eyes. 




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


[gentoo-dev] Re: Project Sunrise -- Proposal

2006-06-16 Thread Ryan Hill
Marius Mauch wrote:

 Functional changes, bugfixes, etc. Let people use common sense there.
 The intention is simply that people watching the bug don't have to track
 the overlay as well to get notifications of important changes (like a
 bugfix that prevented them from using the ebuild previously).
 Certainly you wouldn't consider whitespace changes or coding style
 updates as an *important*, would you?

Could this be automated through a post-commit hook in SVN?  I'm thinking of
something like the GCC bugzilla, which adds a comment to the relevant bug
whenever a checkin is made.

eg. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27601

--de.



signature.asc
Description: OpenPGP digital signature


[gentoo-dev] variable quoting, setting optional variables to , and depending on virtual/libc

2006-06-16 Thread Thomas Cort
What is the proper quoting style for using epatch? In the tree there
are about 3 different styles...

epatch ${FILESDIR}/some-fix.patch  # used by 7326 ebuilds
epatch ${FILESDIR}/some-fix.patch# used by 3092 ebuilds
epatch ${FILESDIR}/some-fix.patch# used by 1434 ebuilds

What is the proper quoting style for defining the S variable? In the
tree there are about 3 different styles...

S=${WORKDIR}/${MY_P}# used by 5270 ebuilds
S=${WORKDIR}/${MY_P}  # used by 43 ebuilds
S=${WORKDIR}/${MY_P}  # used by 2259 ebuilds

What is the purpose of setting DEPEND and RDEPEND to  if DEPEND and
RDEPEND are optional[1][2]? Isn't that just a waste of disk space /
bandwidth? DEPEND=virtual/libc seems like a waste too as it is an
implicit system dependency[3], any reason for using it?

DEPEND= # used by 1479 ebuilds
RDEPEND=# used by 884 ebuilds
DEPEND=virtual/libc # used by 809 ebuilds

[1] 
http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2chap=1#doc_chap_pre2
[2] 
http://devmanual.gentoo.org/ebuild-writing/variables/index.html#optional-variables
[3] 
http://devmanual.gentoo.org/general-concepts/dependencies/index.html#implicit-system-dependency


pgptiYOfnSCWC.pgp
Description: PGP signature


Re: [gentoo-dev] variable quoting, setting optional variables to , and depending on virtual/libc

2006-06-16 Thread Alin Nastac
Thomas Cort wrote:
 What is the proper quoting style for using epatch? In the tree there
 are about 3 different styles...

   epatch ${FILESDIR}/some-fix.patch  # used by 7326 ebuilds
   epatch ${FILESDIR}/some-fix.patch# used by 3092 ebuilds
   epatch ${FILESDIR}/some-fix.patch# used by 1434 ebuilds
   
2 and 3 are fine.
 What is the proper quoting style for defining the S variable? In the
 tree there are about 3 different styles...

   S=${WORKDIR}/${MY_P}# used by 5270 ebuilds
   S=${WORKDIR}/${MY_P}  # used by 43 ebuilds
   S=${WORKDIR}/${MY_P}  # used by 2259 ebuilds
   
ditto
 What is the purpose of setting DEPEND and RDEPEND to  if DEPEND and
 RDEPEND are optional[1][2]? Isn't that just a waste of disk space /
 bandwidth? DEPEND=virtual/libc seems like a waste too as it is an
 implicit system dependency[3], any reason for using it?

   DEPEND= # used by 1479 ebuilds
   RDEPEND=# used by 884 ebuilds
   DEPEND=virtual/libc # used by 809 ebuilds
   
If the package don't have dependencies, then don't set *DEPEND.
virtual/libc dependency is probably futile, unless the package is part
of the system class or is a dependency of a package which is part of the
system class.




signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] variable quoting, setting optional variables to , and depending on virtual/libc

2006-06-16 Thread Donnie Berkholz
Thomas Cort wrote:
 What is the proper quoting style for using epatch? In the tree there
 are about 3 different styles...
 
   epatch ${FILESDIR}/some-fix.patch  # used by 7326 ebuilds
   epatch ${FILESDIR}/some-fix.patch# used by 3092 ebuilds
   epatch ${FILESDIR}/some-fix.patch# used by 1434 ebuilds
 
 What is the proper quoting style for defining the S variable? In the
 tree there are about 3 different styles...
 
   S=${WORKDIR}/${MY_P}# used by 5270 ebuilds
   S=${WORKDIR}/${MY_P}  # used by 43 ebuilds
   S=${WORKDIR}/${MY_P}  # used by 2259 ebuilds

The reasoning for quoting here is at least twofold:

1) There may be spaces in paths (e.g. PORTDIR and PORTAGE_TMPDIR), so
you need to use quotes.
2) When you set a variable to a string, you should use quotes.

Older ebuilds probably mostly lack quoting around uses of $FILESDIR, $S
and $D in the ebuild.

Thanks,
Donnie



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] variable quoting, setting optional variables to , and depending on virtual/libc

2006-06-16 Thread Harald van Dijk
On Sat, Jun 17, 2006 at 12:35:30AM -0400, Thomas Cort wrote:
 What is the proper quoting style for using epatch? In the tree there
 are about 3 different styles...
 
   epatch ${FILESDIR}/some-fix.patch  # used by 7326 ebuilds
   epatch ${FILESDIR}/some-fix.patch# used by 3092 ebuilds
   epatch ${FILESDIR}/some-fix.patch# used by 1434 ebuilds

${FILESDIR} should be quoted, but as long as there are no wildcards in
the /some-fix.patch, it doesn't matter whether that is.

 What is the proper quoting style for defining the S variable? In the
 tree there are about 3 different styles...
 
   S=${WORKDIR}/${MY_P}# used by 5270 ebuilds
   S=${WORKDIR}/${MY_P}  # used by 43 ebuilds
   S=${WORKDIR}/${MY_P}  # used by 2259 ebuilds

Any is fine, there is no word splitting or wildcard expansion in
shell variable assignments.

 What is the purpose of setting DEPEND and RDEPEND to  if DEPEND and
 RDEPEND are optional[1][2]? Isn't that just a waste of disk space /
 bandwidth?

RDEPEND defaults to DEPEND (in ebuilds), so if DEPEND is set, and
RDEPEND should be empty, then RDEPEND must be set to  explicitly.
As for DEPEND=, that's mostly a stylistic issue, I think.

 DEPEND=virtual/libc seems like a waste too as it is an
 implicit system dependency[3], any reason for using it?

Not really.
-- 
gentoo-dev@gentoo.org mailing list