Re: [gentoo-dev] use.desc and use.local.desc cleanup

[Kumba]

Sven Wegener wrote:


Unused local flags:
sys-kernel/mips-headers: cobalt


It's used, it just looks like I forgot to add it to IUSE in the 2.6.11-r1 
ebuild.

Should be fixed.


--Kumba

--
Gentoo/MIPS Team Lead
Gentoo Foundation Board of Trustees

"Such is oft the course of deeds that move the wheels of the world: small hands 
do them because they must, while the eyes of the great are elsewhere."  --Elrond

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] inetd/xinetd useflags

[Donnie Berkholz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Mike Frysinger wrote:
> personally i'd support a doxinetd func that would check to see if xinetd is 
> installed rather than go with a USE flag ...

This kind of auto-enabling stuff is our bane upstream, so I don't see
that creating more of it ourselves is a good idea.

Thanks,
Donnie
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFCy1E8XVaO67S1rtsRAobrAJ98Z6cb98l9+tf1r77dh0Ya4KrJ5QCgqC6i
SU9hvWrffRNV6YFd/XrcfeI=
=JnZC
-END PGP SIGNATURE-
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] splitting build deps out from depends

[Martin Schlemmer]

On Tue, 2005-07-05 at 20:59 -0500, Brian Jackson wrote:
> Martin Schlemmer wrote:
> 
> >>
> >>Big picture here:
> >>* BDEPEND does nothing now, so don't worry about it if you don't want to
> >>* in the future it will make other things possible
> >>* give the man problems you see with the proposal, not just tell him that 
> >>portage doesn't handle it right now... I think out of anyone, he knows what 
> >>portage does and doesn't handle
> >>
> > 
> > 
> > I did ask Brian in another reply how he thought to implement it.
> > 
> > This one however I read as Drake saying/asking that we should start
> > doing it now, and I tried to explain why we could not up until now, and
> > still cannot.   Correct me if I interpreted it wrongly.
> > 
> > 
> 
> I don't know why we can't start now if we want. BDEPEND will be silently
> ignored, so current versions of portage will just be blissfully ignorant.
> 
> Am I missing something?
> 

Yeah, I thought Drake was talking about DEPEND (that was at least what
he said), not BDEPEND.

> Some of us think we can't start now, others think we can. I was under the
> impression from ferringb that we could.
> 

BDEPEND should be fine to start now depending on faith.


-- 
Martin


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

Re: [gentoo-dev] splitting build deps out from depends

[Brian Jackson]

Martin Schlemmer wrote:

>>
>>Big picture here:
>>* BDEPEND does nothing now, so don't worry about it if you don't want to
>>* in the future it will make other things possible
>>* give the man problems you see with the proposal, not just tell him that 
>>portage doesn't handle it right now... I think out of anyone, he knows what 
>>portage does and doesn't handle
>>
> 
> 
> I did ask Brian in another reply how he thought to implement it.
> 
> This one however I read as Drake saying/asking that we should start
> doing it now, and I tried to explain why we could not up until now, and
> still cannot.   Correct me if I interpreted it wrongly.
> 
> 

I don't know why we can't start now if we want. BDEPEND will be silently
ignored, so current versions of portage will just be blissfully ignorant.

Am I missing something?

Some of us think we can't start now, others think we can. I was under the
impression from ferringb that we could.

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

Re: [gentoo-dev] splitting build deps out from depends

[Martin Schlemmer]

On Tue, 2005-07-05 at 18:17 -0500, Brian Jackson wrote:
> Martin Schlemmer wrote:
> > On Fri, 2005-07-01 at 15:59 -0700, Drake Wyrm wrote:
> > 
> >>Mike Frysinger <[EMAIL PROTECTED]> wrote:
> >>
> >>>On Friday 01 July 2005 12:25 pm, Brian D. Harring wrote:
> >>>
> Currently, we pretty much leave out the big dogs of build depends from
> ebuilds- basically we rely on the profile to require a suitable
> toolchain.  Couple of issues with this though-
> >>>
> >>>so what you're proposing is that we add binutils/gcc/glibc to every 
> >>>package 
> >>>that compiles something
> >>
> >>Can you compile without binutils/gcc/glibc? No? Then you need it.
> >>
> >>
> >>>make to every package that uses make, 
> >>
> >>Again, if you depend on make, then DEPEND on make.
> >>
> >>
> >>>sed/grep/bash/coreutils to every package which runs configure
> >>
> >>That's quite an interesting case. Yes, those should be in DEPEND, but it
> >>might be prudent to create an appropriate shortcut instead of explicitly
> >>adding each of those.
> >>
> > 
> > 
> > This is all well and dandy, but try to add coreutils as a dependency of
> > itself, or gcc of itself, or sed ... or grep ... etc, and then try to do
> > a stage1 install (probably stage2/3 as well, but I never do those, so
> > rather wont comment).
> 
> Big picture here:
> * BDEPEND does nothing now, so don't worry about it if you don't want to
> * in the future it will make other things possible
> * give the man problems you see with the proposal, not just tell him that 
> portage doesn't handle it right now... I think out of anyone, he knows what 
> portage does and doesn't handle
> 

I did ask Brian in another reply how he thought to implement it.

This one however I read as Drake saying/asking that we should start
doing it now, and I tried to explain why we could not up until now, and
still cannot.   Correct me if I interpreted it wrongly.


-- 
Martin Schlemmer
Gentoo Linux Developer, Desktop/System Team Developer
Cape Town, South Africa



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

Re: [gentoo-dev] use.desc and use.local.desc cleanup

[Martin Schlemmer]

On Wed, 2005-07-06 at 00:36 +0200, Sven Wegener wrote:
> Hi all!
> 
> Please see below for a list of use.desc and use.local.desc entries that
> are currently unused. I also include a list of local flags for which a
> global flag with the same name exists.
> 
> If no developer speaks up within the next day, I'm going to remove the
> unused local entries and also check if the description of the duplicate
> local flags matches the global one and remove the local description if
> appropriate. You can for sure go ahead and remove your own stale
> entries, means less work for me. ;)
> 
> Cheers,
> Sven
> 

> Unused local flags:

>   www-client/mozilla: mozaccess
>   www-client/mozilla: mozcalendar
>   www-client/mozilla: mozctl
>   www-client/mozilla: moznocompose
>   www-client/mozilla: moznoirc
>   www-client/mozilla: mozp3p
>   www-client/mozilla: mozplaintext

As far as I know many of these are still in use .. Aron ?


-- 
Martin Schlemmer
Gentoo Linux Developer, Desktop/System Team Developer
Cape Town, South Africa



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

Re: [gentoo-dev] *DEPEND mismatches

[Robin H. Johnson]

On Wed, Jul 06, 2005 at 02:00:24AM +0200, Sven Wegener wrote:
[snip]
Could you possibly split the stuff into two files?
one for RDEPEND.only and one for DEPEND.only?

I see a lot more FP for RDEPEND.only.

Many of the RDEPEND.only are correct, as the packages are just scripts
that call other binaries to do their work. On the flipside, there are a
lot of packages that only need something to build properly (eg
sys-cluster/torque needs sys-apps/ed, and dev-libs/openssl has a build
system that needs perl).

I suspect that you'd end up with a massive whitelist if we tried to
catch everything.

For the moment however, I can offer some general items:
anything inheriting php-ext*eclass is correct with DEPEND of dev-php/php but
and RDEPEND of virtual/php.

-- 
Robin Hugh Johnson
E-Mail : [EMAIL PROTECTED]
Home Page  : http://www.orbis-terrarum.net/?l=people.robbat2
ICQ#   : 30269588 or 41961639
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85


pgp10pJYrtzcY.pgp
Description: PGP signature

Re: [gentoo-dev] *DEPEND mismatches

[Sven Wegener]

On Tue, Jul 05, 2005 at 08:12:31PM -0400, Mike Frysinger wrote:
> you should def whitelist for DEPEND only:
> app-arch/zip
> app-arch/unrar
> dev-util/jam
> media-gfx/nvidia-cg-toolkit
> games-util/loki_patch

I added them to the list of packages being safe to be used in DEPEND
only.

Sven

-- 
Sven Wegener
Gentoo Developer
http://www.gentoo.org/


pgp4Pqd482Pq6.pgp
Description: PGP signature

Re: [gentoo-dev] *DEPEND mismatches

[Diego 'Flameeyes' Pettenò]

On Wednesday 06 July 2005 02:12, Mike Frysinger wrote:
> you should def whitelist for DEPEND only:
dev-util/cvs is used by vlc during build process (BDEPEND?)

Still there are a few other RDEPEND which makes sense to not be DEPEND, 
especially for scripts.

-- 
Diego "Flameeyes" Pettenò
Gentoo Developer - http://dev.gentoo.org/~flameeyes/
(Gentoo/FreeBSD, Video, Gentoo/AMD64, Sound, PAM)


pgpR61tTrABw8.pgp
Description: PGP signature

Re: [gentoo-dev] *DEPEND mismatches

[Mike Frysinger]

On Tuesday 05 July 2005 08:00 pm, Sven Wegener wrote:
> contains a lot of false positives. I can whitelist packages for DEPEND
> or RDEPEND either general, based on eclass usage or for a specific
> package. If you are sure that your package has a safe mismatch, I can
> add it to the whitelist. But please one after the other, this is just an
> initial test.

you should def whitelist for DEPEND only:
app-arch/zip
app-arch/unrar
dev-util/jam
media-gfx/nvidia-cg-toolkit
games-util/loki_patch
-mike
-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] *DEPEND mismatches

[Sven Wegener]

Hi all!

Short explanation for the subject: A *DEPEND mismatch is when a package
is listed in DEPEND, but missing in RDEPEND and vice versa. I have a
list of ebuilds at http://dev.gentoo.org/~swegener/qa/depend-mismatches
that contain such mismatches. I've already whitelisted packages like
automake and autoconf, that are safe to be only in DEPEND. And I also
whitelisted packages like emul-linux-x86-baselibs for being
RDEPEND-only. Pure meta packages like gnome-base/gnome or kde-base/kde
have everything whitelisted for RDEPEND and everything blacklisted for
DEPEND. Additional blacklistings include virtual/modutils for DEPEND.

This check is important, because when merging binary packages portage
will only install RDEPEND and when building stages (via ROOT support)
DEPEND will go to / and RDEPEND will got to the specified ROOT. I want
to clean *DEPEND up, so that we have sane dependencies. Currently, for
normal merging, portage forces both DEPEND and RDEPEND to be installed,
even after the merging is complete. This might or will change in the
future and break packages that have these mismatches.

I want developers to take a look at the list and see if packages they
maintain are listed. I'm aware that the list is quite large and still
contains a lot of false positives. I can whitelist packages for DEPEND
or RDEPEND either general, based on eclass usage or for a specific
package. If you are sure that your package has a safe mismatch, I can
add it to the whitelist. But please one after the other, this is just an
initial test.

Cheers,
Sven

-- 
Sven Wegener
Gentoo Developer
http://www.gentoo.org/


pgphkVXD5qV5M.pgp
Description: PGP signature

Re: [gentoo-dev] use.desc and use.local.desc cleanup

[Diego 'Flameeyes' Pettenò]

On Wednesday 06 July 2005 01:23, Mike Frysinger wrote:
> nothing should be using freetype ... i'll go ahead and delete that from
> global since it shouldnt have been added in the first place
Doesn't this remember you of some dupe bugs of us? :P

-- 
Diego "Flameeyes" Pettenò
Gentoo Developer - http://dev.gentoo.org/~flameeyes/
(Gentoo/FreeBSD, Video, Gentoo/AMD64, Sound, PAM)


pgpdSG2DM18DY.pgp
Description: PGP signature

Re: [gentoo-dev] inetd/xinetd useflags

[Mike Frysinger]

On Tuesday 05 July 2005 06:17 pm, Diego 'Flameeyes' Pettenò wrote:
> inetd is the old-unix-insecure implementation that it's usually used.
> xinetd is a (drop-in?) replacement for it which is now used by quite
> everyone who wants an inetd-style daemons.

you cant technically say it's a drop in since you have to redo the config 
files, but for all intents and purposes, it is ... old school inetd suffered 
from many issues (resource management being the foremost) so xinetd was 
born ... it is the preferred inetd in Gentoo

> [EMAIL PROTECTED] ~ $ grep inetd devel/gentoo-x86/profiles/use.*
> devel/gentoo-x86/profiles/use.local.desc:dev-db/firebird:inetd - If you
> want inetd version instead of a superserver (daemon)

unrelated to anything in this e-mail

> so what we should do?
> Add a global xinetd useflag and a doxinetd function to add/remove the
> installed config files?
> Yeah i know they aren't so big.. but "the less, the best".

personally i'd support a doxinetd func that would check to see if xinetd is 
installed rather than go with a USE flag ...
-mike

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] use.desc and use.local.desc cleanup

[Mike Frysinger]

On Tuesday 05 July 2005 06:36 pm, Sven Wegener wrote:
>   x11-base/kdrive: freetype
>   x11-libs/fox: truetype

nothing should be using freetype ... i'll go ahead and delete that from global 
since it shouldnt have been added in the first place
-mike
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] splitting build deps out from depends

[Brian Jackson]

Martin Schlemmer wrote:

On Fri, 2005-07-01 at 15:59 -0700, Drake Wyrm wrote:


Mike Frysinger <[EMAIL PROTECTED]> wrote:


On Friday 01 July 2005 12:25 pm, Brian D. Harring wrote:


Currently, we pretty much leave out the big dogs of build depends from
ebuilds- basically we rely on the profile to require a suitable
toolchain.  Couple of issues with this though-


so what you're proposing is that we add binutils/gcc/glibc to every package 
that compiles something


Can you compile without binutils/gcc/glibc? No? Then you need it.


make to every package that uses make, 


Again, if you depend on make, then DEPEND on make.



sed/grep/bash/coreutils to every package which runs configure


That's quite an interesting case. Yes, those should be in DEPEND, but it
might be prudent to create an appropriate shortcut instead of explicitly
adding each of those.




This is all well and dandy, but try to add coreutils as a dependency of
itself, or gcc of itself, or sed ... or grep ... etc, and then try to do
a stage1 install (probably stage2/3 as well, but I never do those, so
rather wont comment).


Big picture here:
* BDEPEND does nothing now, so don't worry about it if you don't want to
* in the future it will make other things possible
* give the man problems you see with the proposal, not just tell him that 
portage doesn't handle it right now... I think out of anyone, he knows what 
portage does and doesn't handle


--Iggy



The point that Mike and I make, is that portage cannot handle this (and
probably wont be able to in future without a _lot_ of black magic), and
this is why we need the system profile which have just the right amount
of DEPEND magic to make it work, and then everything else depends
automagically on the system profile (and everything in it).  Making the
adding of system packages to non system packages really redundant.

Sure it might be fixable, but the only way I see how, is to have a
complete system profile (with all the dependencies that are currently
lacking), and then

  # emerge --oneshot --nodeps $(cat /some/path/system-profile)

But this gets to the verge of being too static, having the effect that
some optional dependencies for the system profile cannot be used. (There
are probably other ways, but this is the first that I could think of,
and more as an example ...)


Thanks,


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Proposed security policy for web-based apps

[Marius Mauch]

On Tue, 05 Jul 2005 21:21:35 +0100
Stuart Herbert <[EMAIL PROTECTED]> wrote:

> Hi,
> 
> I'd like to introduce the following security policy for web-based
> apps. If there are no objections, every new web-based app will have
> to conform to the policy before it can be added to the tree.  Every
> existing web-based app will have to conform to the policy by the end
> of August, or I will remove it from the tree.

[snip]

Hmm, what's the criteria to decide if something falls under this policy
or not? Package category, maintainership, dependency on webserver, ...?

Marius

-- 
Public Key at http://www.genone.de/info/gpg-key.pub

In the beginning, there was nothing. And God said, 'Let there be
Light.' And there was still nothing, but you could see a bit better.


pgpYnGgYbSlEK.pgp
Description: PGP signature

Re: [gentoo-dev] Proposed security policy for web-based apps

[Renat Lumpau]

On Tue, Jul 05, 2005 at 05:52:47PM -0400, Alec Warner wrote:
> > 3. This information will be checked every three months to ensure it
> >remains valid.
> 
> Are you volunteering to do 3?  If not, who will?

I'll help.

-- 
Renat Lumpau
Gentoo developer
GPG key id #C6A838DA on http://pgp.mit.edu
Key fingerprint = 04AF B5EE 17CB 1000 DDA5  D3FC 1338 ADC2 C6A8 38DA


pgpBEzk2Uu6a8.pgp
Description: PGP signature

[gentoo-dev] inetd/xinetd useflags

[Diego 'Flameeyes' Pettenò]

Time for cleanups in Gentoo/FreeBSD.. we already disabled inetd building in 
our latest ebuilds, but that isn't exactly sorted out for a reason: I don't 
know how to deal with xinetd.

Let me summarize:

inetd is the old-unix-insecure implementation that it's usually used.
xinetd is a (drop-in?) replacement for it which is now used by quite everyone 
who wants an inetd-style daemons.

Now the problem is: I don't really know how inetd/xinetd works, I just used 
them some time ago to have a cvs pserver, but that was a very long time ago.
Right now, we have a couple of packages with xinetd useflag, one with inetd 
useflag, and others which doesn't care and just installs the configuration 
file unconditionally:

[EMAIL PROTECTED] ~ $ grep inetd devel/gentoo-x86/profiles/use.*
devel/gentoo-x86/profiles/use.local.desc:dev-db/firebird:inetd - If you want 
inetd version instead of a superserver (daemon)
devel/gentoo-x86/profiles/use.local.desc:net-ftp/proftpd:xinetd - Enable 
support for starting from xinetd
devel/gentoo-x86/profiles/use.local.desc:net-ftp/vsftpd:xinetd - Add support 
for running under xinetd
devel/gentoo-x86/profiles/use.local.desc:net-mail/qpopper:xinetd - If you want 
inetd version instead of standalone
devel/gentoo-x86/profiles/use.local.desc:net-misc/linux-identd:xinetd - Use 
xinetd instead of the initscript
[EMAIL PROTECTED] ~ $ ls /etc/xinetd.d/
cups-lpdcvspserver  svnserveswattelnetd

so what we should do?
Add a global xinetd useflag and a doxinetd function to add/remove the 
installed config files?
Yeah i know they aren't so big.. but "the less, the best".

-- 
Diego "Flameeyes" Pettenò
Gentoo Developer - http://dev.gentoo.org/~flameeyes/
(Gentoo/FreeBSD, Video, Gentoo/AMD64, Sound, PAM)


pgpTcyniwL2q1.pgp
Description: PGP signature

Re: [gentoo-dev] Proposed security policy for web-based apps

[David Morgan]

> > 1. The Gentoo package's maintainer will identify one *named* contact
> >UPSTREAM for security-related matters, and one named general contact
> >UPSTREAM (as a fallback for when the security contact is
> >unreachable).

And what happens if upstream is only one person?


-- 
djm

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Proposed security policy for web-based apps

[Alec Warner]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Stuart Herbert wrote:
> Hi,
> 

> 
> 1. The Gentoo package's maintainer will identify one *named* contact
>UPSTREAM for security-related matters, and one named general contact
>UPSTREAM (as a fallback for when the security contact is
>unreachable).
> 2. This information will be held on the Dev Wiki.
> 3. This information will be checked every three months to ensure it
>remains valid.

Are you volunteering to do 3?  If not, who will?

> 4. In situations where the UPSTREAM contacts are unreachable, and no
>new contact can be identified, the package will be masked and
>marked for removal from the Portage tree (ie it fails this policy)
> 
> Thoughts, comments, other (constructive) feedback?
> 
> Best regards,
> Stu
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iQIVAwUBQssBL2zglR5RwbyYAQKf8Q//QqbVG+xReAF5WyZMHOfOS0zoM0UJZRFJ
M7WM28JVR6aNAD4hVcv8EKVMLvt6nPiIu2REsO9ZrZwzIdBm8uLxqdnX76ZysW/6
h10igkCBa78RfuNHbul4muPk1SyAWg3ZextltaMXPrO8bDfoTENcLzp8+NqDyqel
6Ncr/pEcZnEJABKmDfuT/ehtI89+wps51Fkdq7wa8z+EXGCDd1HGNTA3x1OImgDM
VaHlLjGVS1lLcXGmZYKCZGvfKzbF/d9xJZ/LwdG+CpJD02avJ4iVv/51y/eGiVzm
CwB9d+5wCq5YZFBLOXr8HXFJhYkzSXuGZfbKXisdhzui5MqpErpMQw1TNATY//ha
HfFlYjnftS2vjzO/M9aiQqdqXF4HiejKRJGWVwxcqenFjj566t+uTvomwgI/2YLi
/yimNyoyG3/ueLLSEMtyo6MURrjT9bbohUVH7pMr3RHNbNjtn3K9omEB4Ngh8L2q
kA3hjoQRy1a6gNhG6eHg0j9sBmGb2TEBK/nMKCdyqONH+X/cdGCMIreMxcZ5pqu7
hBD/azcZI8jJr+tb0y3NHcfaT653HDAyeyOCD1OiDDlZeqzi1IGGW1p0ZHqg5J/+
NiGXnbCBT6NKzjvYfQ4nMYJaHGoZQDj8wHyFSUGKUFLjQ+L9X1ros8a1URhfinRf
0pDyFPfTmAI=
=6nmQ
-END PGP SIGNATURE-
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Proposed security policy for web-based apps

[Lance Albertson]

Mike Frysinger wrote:
> On Tuesday 05 July 2005 04:21 pm, Stuart Herbert wrote:
> 
>>1. The Gentoo package's maintainer will identify one *named* contact
>>   UPSTREAM for security-related matters, and one named general contact
>>   UPSTREAM (as a fallback for when the security contact is
>>   unreachable).
>>2. This information will be held on the Dev Wiki.
> 
> 
> wtf is the Dev Wiki ?  what's wrong with metadata.xml ?

Yeah, having it in metadata.xml would make more sense.

-- 
Lance Albertson <[EMAIL PROTECTED]>
Gentoo Infrastructure | Operations Manager

---
GPG Public Key:  
Key fingerprint: 0423 92F3 544A 1282 5AB1  4D07 416F A15D 27F4 B742

ramereth/irc.freenode.net


signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Proposed security policy for web-based apps

[Mike Frysinger]

On Tuesday 05 July 2005 04:21 pm, Stuart Herbert wrote:
> 1. The Gentoo package's maintainer will identify one *named* contact
>UPSTREAM for security-related matters, and one named general contact
>UPSTREAM (as a fallback for when the security contact is
>unreachable).
> 2. This information will be held on the Dev Wiki.

wtf is the Dev Wiki ?  what's wrong with metadata.xml ?
-mike
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] DEPEND on alternative release series of a package

[Sebastian Bergmann]

Sebastian Bergmann schrieb:
> While this seems to work with emerge, I get DEPEND.bad and RDEPEND.bad
> errors from repoman.

 Nevermind,

   || ( =dev-php/php-4*
=dev-php/php-5.1* )"

 seems to work.

--
Sebastian Bergmann  http://www.sebastian-bergmann.de/
GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69


signature.asc
Description: OpenPGP digital signature

[gentoo-dev] Proposed security policy for web-based apps

[Stuart Herbert]

Hi,

I'd like to introduce the following security policy for web-based apps.
If there are no objections, every new web-based app will have to conform
to the policy before it can be added to the tree.  Every existing
web-based app will have to conform to the policy by the end of August,
or I will remove it from the tree.

The proposed policy is simply that:

1. The Gentoo package's maintainer will identify one *named* contact
   UPSTREAM for security-related matters, and one named general contact
   UPSTREAM (as a fallback for when the security contact is
   unreachable).
2. This information will be held on the Dev Wiki.
3. This information will be checked every three months to ensure it
   remains valid.
4. In situations where the UPSTREAM contacts are unreachable, and no
   new contact can be identified, the package will be masked and
   marked for removal from the Portage tree (ie it fails this policy)

I believe that security holes will be discovered from time to time.  I
want to make sure that, when a hole has been found, everything's in
place for us to work with UPSTREAM at the greatest possible speed to get
things resolved.

I would rather we only distributed web-based apps where we can be
confident that security is taken appropriately seriously UPSTREAM.  Web
servers are too easy a target for us to be distributing software we
can't be confident about.

Thoughts, comments, other (constructive) feedback?

Best regards,
Stu
-- 
Stuart Herbert [EMAIL PROTECTED]
Gentoo Developer  http://www.gentoo.org/
  http://stu.gnqs.org/diary/

GnuGP key id# F9AFC57C available from http://pgp.mit.edu
Key fingerprint = 31FB 50D4 1F88 E227 F319  C549 0C2F 80BA F9AF C57C
--


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

Re: [gentoo-dev] Software patents

[Chris Gianelloni]

On Tue, 2005-07-05 at 04:07 +0100, twofourtysix wrote:
> Are these people prepared to back up their views by removing from the
> tree all those ebuilds for software made by companies who make heavy
> use of software patents? That would be far more effective, and may
> even encourage a few mainstream tech news sources to stop ignoring the
> issue. I can think of quite a few software-patent friendly companies
> who are currently gaining significant good PR from being 'supported'
> by Gentoo.

I can tell you one thing.  If anyone removes a package that *I* maintain
just because of software patents, then there will be hell to pay.

I could give a damn about this issue, but removing choice from our
users, especially without contacting the maintainer of the package, is
grounds for disciplinary action in my eyes.  Some of our users don't
care about patents one way or another.  Why should we have a vocal group
out there forcing their position on another?  Maybe we should start
giving back all of our donations from AMD and NVidia.  After all, they
have lots of patents.

This is really starting to get out of hand.

Don't bother responding to my post, as I'm adding a procmail rule for
this as we speak.  It has nothing to do with Gentoo development, and
doesn't belong on *this* list.

-- 
Chris Gianelloni
Release Engineering - Strategic Lead/QA Manager
Games - Developer
Gentoo Linux


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

[gentoo-dev] DEPEND on alternative release series of a package

[Sebastian Bergmann]

 I want to add an ebuild for APC 3.0.0 (dev-php/PECL-apc) to portage but
 am stuck with the following problem: APC 3.0.0 works with PHP 4.3.X and
 PHP 5.1.X but not with PHP 5.0.X.

 To block the installation of APC 3.0.0 with PHP 5.0.X I added the
 following to the ebuild:

   DEPEND="...
   || ( =dev-php/php-4.0*
=dev-php/php-5.1* )"

 While this seems to work with emerge, I get DEPEND.bad and RDEPEND.bad
 errors from repoman.

 Any help appreciated,
Sebastian

--
Sebastian Bergmann  http://www.sebastian-bergmann.de/
GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69


signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] New virtual: virtual/pcmcia

[Henrik Brix Andersen]

On Thu, 2005-06-30 at 07:35 -0400, Ned Ludd wrote:
> On that note.. Would you mind compiling it one time with a gcc built 
> with +boundschecking and then enabling CFLAGS+= -fbounds-checking as a
> basic q/a check. Reason being that if nobody has ever included it
> anywhere the chances of it being audited are slim to none and
> -fbounds-checking helps ferret out alot of common coding mistakes.
> gcc-3.4.4 works good for this.

I've tested this with CFLAGS+=-fbounds-checking as suggested, and I see
a couple of "cc1: warning: htb stub: bounds checking is not supported"
warnings. Please advice.

./Brix
-- 
Henrik Brix Andersen <[EMAIL PROTECTED]>
Gentoo Metadistribution | Mobile computing herd


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

[gentoo-dev] 2005.1 x86 pre GRP-set

[Benjamin Judas]

Heare, Heare,

his royal highness Forman has just uploaded the prerelease GRP-set, universal 
install-cd and the snapshot into the experimental-branch on the mirrors 
(experimental/x86/livecd/x86/).

If you feel like testing the media, I would really appreciate it.
All bugs concerning the media should go to bug #97716 and NOWHERE ELSE (!!).

Regards
-- 
Benjamin Judas   http://dev.gentoo.org
Release-Coordinator x86  http://www.gentoo.org
Giessen, Germany

Gentoo Foundation

GPG-Key: 0xC31DEDD8
Fingerprint: 4E65 AAFE 785B 61D8 E4D9 1671 E017 87B7 C31D EDD8
Jabber:  [EMAIL PROTECTED]


pgpNpk8uq4AIl.pgp
Description: PGP signature

[gentoo-dev] Adding perl to packages.build

[Chris Gianelloni]

First off, I'm going to ask that everyone please respond on gentoo-dev,
I am sending this to -core to try to catch everyone.

I am wanting to add dev-lang/perl to packages.build in default-linux.
Now, allow me to explain before you guys break out the torches and
pitchforks.  The new current stable version of perl supports a "minimal"
and "build" USE flag that builds only the core perl.  This is very
useful for us in creating a stage1 tarball, as it gives us a tiny (800K)
perl that resolves circular dependency problems with openssl<->perl.
The reason for adding it to packages.build is so it is available before
bootstrap, making it safe for any combination of USE flags.

I have tested this locally with not only a complete catalyst run, but
also using it to bootstrap with several different combinations of USE
flags.  I was completely unable to produce any circular dependency
problems on x86, amd64, or ppc.

Anyway, if nobody has any objections to this, I'll be adding it on
Thursday.

-- 
Chris Gianelloni
Release Engineering - Strategic Lead/QA Manager
Games - Developer
Gentoo Linux


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

Re: [gentoo-dev] New virtual: virtual/pcmcia

[Martin Schlemmer]

On Tue, 2005-07-05 at 15:24 +0200, Henrik Brix Andersen wrote:
> On Thu, 2005-06-30 at 07:35 -0400, Ned Ludd wrote:
> > On that note.. Would you mind compiling it one time with a gcc built 
> > with +boundschecking and then enabling CFLAGS+= -fbounds-checking as a
> > basic q/a check. Reason being that if nobody has ever included it
> > anywhere the chances of it being audited are slim to none and
> > -fbounds-checking helps ferret out alot of common coding mistakes.
> > gcc-3.4.4 works good for this.
> 
> I am still on gcc-3.3.x - will that work for this test?
> 

Yup .. there might just be an bug with bounds-checking that breaks make
jobs .. so if it borks, try with make -j1 ...


-- 
Martin Schlemmer
Gentoo Linux Developer, Desktop/System Team Developer
Cape Town, South Africa



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

Re: [gentoo-dev] New virtual: virtual/pcmcia

[Henrik Brix Andersen]

On Thu, 2005-06-30 at 07:35 -0400, Ned Ludd wrote:
> On that note.. Would you mind compiling it one time with a gcc built 
> with +boundschecking and then enabling CFLAGS+= -fbounds-checking as a
> basic q/a check. Reason being that if nobody has ever included it
> anywhere the chances of it being audited are slim to none and
> -fbounds-checking helps ferret out alot of common coding mistakes.
> gcc-3.4.4 works good for this.

I am still on gcc-3.3.x - will that work for this test?

Sincerely,
Brix
-- 
Henrik Brix Andersen <[EMAIL PROTECTED]>
Gentoo Metadistribution | Mobile computing herd


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

Re: [gentoo-dev] Software patents

[M. Edward (Ed) Borasky]

Of course not -- Grunthos the Flatulent was the inventor of vaporware



Ioannis Aslanidis wrote:

>On 7/5/05, Kumba <[EMAIL PROTECTED]> wrote:
>  
>
>>2) This pointless debate will eventually die, because if it doesn't
>>   I'm going to start quoting select excerpts from Vogon Poetry.
>>
>>3) If the Vogon Poetry fails, I'll start reading excerpts from
>>   Grunthos the Flatulent's "Ode To A Small Lump Of Green Putty
>>   I Found In My Armpit One Midsummer Morning".
>>
>>
>
>Can we have a demo?
>
>  
>
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] New virtual: virtual/pcmcia

[Martin Schlemmer]

On Tue, 2005-07-05 at 14:11 +0200, Henrik Brix Andersen wrote:
> On Tue, 2005-07-05 at 11:25 +0200, Martin Schlemmer wrote:
> > A bit late I know, but just for interest sake .. virtuals is usually
> > used when more than one package usually provides the same compatible
> > api/tool ... which basically means pcmcia-cs and pcmciautils do the same
> > thing and cannot be installed together ?  Sorry if my non-pcmcia
> > cluedup-ness shows ...
> 
> Yes, that is correct. pcmciautils will replace pcmcia-cs starting with
> linux-2.6.13, and the two can not be installed side-by-side as they have
> file collisions (not to mention the fact that they provide the same
> functionality).
> 

Thanks for clearing that up!


Regards,

-- 
Martin Schlemmer
Gentoo Linux Developer, Desktop/System Team Developer
Cape Town, South Africa



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

Re: [gentoo-dev] Software patents

[Henrik Brix Andersen]

On Tue, 2005-07-05 at 15:14 +1000, Stuart Longland wrote:
> Good luck finding a decent video card for that lovely desktop of yours. :-)

Who needs video cards? My old VT-100 A4 terminal works just fine.

./Brix
-- 
Henrik Brix Andersen <[EMAIL PROTECTED]>
Gentoo Metadistribution | Mobile computing herd


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

Re: [gentoo-dev] New virtual: virtual/pcmcia

[Henrik Brix Andersen]

On Tue, 2005-07-05 at 11:25 +0200, Martin Schlemmer wrote:
> A bit late I know, but just for interest sake .. virtuals is usually
> used when more than one package usually provides the same compatible
> api/tool ... which basically means pcmcia-cs and pcmciautils do the same
> thing and cannot be installed together ?  Sorry if my non-pcmcia
> cluedup-ness shows ...

Yes, that is correct. pcmciautils will replace pcmcia-cs starting with
linux-2.6.13, and the two can not be installed side-by-side as they have
file collisions (not to mention the fact that they provide the same
functionality).

Sincerely,
Brix
-- 
Henrik Brix Andersen <[EMAIL PROTECTED]>
Gentoo Metadistribution | Mobile computing herd


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

Re: [gentoo-dev] splitting build deps out from depends

[Martin Schlemmer]

On Fri, 2005-07-01 at 15:59 -0700, Drake Wyrm wrote:
> Mike Frysinger <[EMAIL PROTECTED]> wrote:
> > On Friday 01 July 2005 12:25 pm, Brian D. Harring wrote:
> > > Currently, we pretty much leave out the big dogs of build depends from
> > > ebuilds- basically we rely on the profile to require a suitable
> > > toolchain.  Couple of issues with this though-
> > 
> > so what you're proposing is that we add binutils/gcc/glibc to every package 
> > that compiles something
> 
> Can you compile without binutils/gcc/glibc? No? Then you need it.
> 
> > make to every package that uses make, 
> 
> Again, if you depend on make, then DEPEND on make.
> 
> > sed/grep/bash/coreutils to every package which runs configure
> 
> That's quite an interesting case. Yes, those should be in DEPEND, but it
> might be prudent to create an appropriate shortcut instead of explicitly
> adding each of those.
> 

This is all well and dandy, but try to add coreutils as a dependency of
itself, or gcc of itself, or sed ... or grep ... etc, and then try to do
a stage1 install (probably stage2/3 as well, but I never do those, so
rather wont comment).

The point that Mike and I make, is that portage cannot handle this (and
probably wont be able to in future without a _lot_ of black magic), and
this is why we need the system profile which have just the right amount
of DEPEND magic to make it work, and then everything else depends
automagically on the system profile (and everything in it).  Making the
adding of system packages to non system packages really redundant.

Sure it might be fixable, but the only way I see how, is to have a
complete system profile (with all the dependencies that are currently
lacking), and then

  # emerge --oneshot --nodeps $(cat /some/path/system-profile)

But this gets to the verge of being too static, having the effect that
some optional dependencies for the system profile cannot be used. (There
are probably other ways, but this is the first that I could think of,
and more as an example ...)


Thanks,

-- 
Martin Schlemmer
Gentoo Linux Developer, Desktop/System Team Developer
Cape Town, South Africa



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

Re: [gentoo-dev] Discussion: alternative compatible utilities

[Martin Schlemmer]

On Tue, 2005-06-21 at 14:45 -0400, Aron Griffis wrote:
> Azarah wrote:[Sat Jun 18 2005, 07:23:19AM EDT]
> > You might however say install all gnuish tools with the 'g' prefix,
> > and then install wrapper scripts/stubs into say /usr/bin/gnu/ or
> > /bin/gnu/ (with /usr/bin/gnu/find calling gfind, etc), and portage
> > just adds this path as the first path to $PATH ...
> > 
> > This should cover the fact that aliases might not work in all cases,
> > and is bsd specific implementation.
> 
> That would actually cause a lot of problems because the PATH would be
> inherited by configure and/or make.  The result is that programs get
> GNU tools when they are built, but BSD tools at run-time.  I can only
> imagine that causing a lot of confusion.
> 

Ahh, right - didn't think about that.  Although you realise that the
same issues will be present when eselecting something before and after
emerge ?


Thanks,

-- 
Martin Schlemmer
Gentoo Linux Developer, Desktop/System Team Developer
Cape Town, South Africa



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

Re: [gentoo-dev] Software patents

[Martin Schlemmer]

On Tue, 2005-07-05 at 10:09 +0100, twofourtysix wrote:
> On 05/07/05, Patrick Lauer <[EMAIL PROTECTED]> wrote:
> > On Tue, 2005-07-05 at 06:13 +0100, twofourtysix wrote:
> > > Mostly, I was hoping that all those people who seem more than happy to
> > > advocate something with *words* would be prepared to back them up with
> > > *actions*. I think it's a shame that Gentoo is prepared to encourage
> > > people to pester their politicians whilst simultaneously refusing to
> > > spend a few minutes practising what it preaches.
> > 
> > Ok ... let's remove all software that might violate a european patent.
> 
> Who was talking about removing ebuilds for software just because that
> software violates a patent? I certainly wasn't... Strange that I'm
> being accused of trolling when I'm not the one with the straw man
> arguments.

Strange that you still have not given your true identity after it being
pointed out.

Strange that some people cannot see that some of us just love working on
Gentoo, and do not want it to become yet another Political debacle.

Strange that the same people cannot fight their own battle, but need to
do it under the cover of some group.

Strange that the same people only wake up now.

Strange that some people cannot realise that others might have a
different point of view, and way of doing things.

--

-core was humorous, but I really do not see why we need to start it all
over again due to some nameless person that is too much of a coward to
post as himself.


Thanks.

-- 
Martin Schlemmer
Gentoo Linux Developer, Desktop/System Team Developer
Cape Town, South Africa



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

Re: [gentoo-dev] splitting build deps out from depends

[Martin Schlemmer]

On Fri, 2005-07-01 at 13:42 -0500, Brian D. Harring wrote:
> On Fri, Jul 01, 2005 at 02:30:12PM -0400, Mike Frysinger wrote:
> > On Friday 01 July 2005 02:11 pm, Brian D. Harring wrote:
> > > Meanwhile, back to the "you want us to add what?", our dependency
> > > graph *is* incomplete.
> > 
> > so what ?  i dont see it being a bug
> 
> I do. :)
> 

I don't as well, until you can prove that portage can handle a system
install without a system profile, and everything depending on the system
profile.

Just an example what an 'innocent' fix can do by adding a system profile
item somewhere into an DEPEND where it does not belong, see bug #96209.

> We do a lot of work to have deps accurate, ignoring a fairly critical 
> class of dependencies cause it's extra work seems a bit short sighted.
> 
> Beyond that, see the user profile bit below, it shades incomplete 
> toolchain dependencies as being a bug...
> 
> 
> > > Something like 600 ebuilds in the tree state a 
> > > dependency on gcc- we have 19000 ebuilds.  Not all requires gcc to
> > > build, but I'd bet it's a tad bit more then 600.
> > 
> > and i continue to work day after day to make sure that 600 reaches 0 :p
> > 
> > considering your system requires a virtual/libc in order to boot, tell me 
> > again why we must list it in every package which uses glibc ?
> > 
> > > Full dependency information hasn't be viable due to resolver issues,
> > > which will be fixed.
> > 
> > so why dont you come back once you have something that is supposed to work 
> > ?  
> > you're proposing we start generating a ton of circular dependencies which 
> > we 
> > arent even close to handling now
> 
> Floating the idea.  BDEPEND implementation (if people thought it was a 
> good idea) would go alongside use/slot dep implementation.
> 
> The short version is BDEPEND is fairly heavily related to domain work 
> for collapsing config/ROOT into a single groupping portage can work 
> with.
> 
> No BDEPEND means that things are nastier for dealing with x-compile 
> from portage's standpoint, so a general yay/nay on the concept is 
> needed (hence it being raised now).
> 

Like every other idea, it might be nice - just as the
multi-slot-per-version idea would have been cool for x-compiling ... but
still are not implemented.

Do not get me wrong .. I assume this will do wonders for x-compiling and
prevent world war, etc, but as Linus (or some other guy) would say:
Show me the Code.

On another note .. how do you guys plan to handle this BDEPEND .. just
for x-compile, or global?  If global, any ideas how to solve the
circular issues ???

> 
> > > Regarding the "require whatever is used to uncompress the source",
> > > hadn't thought about it, but that _should_ be specified imo.  That's
> > > also being a bit anal, but frankly, if the resolver can handle it, why
> > > shouldn't we specify the full deps?
> > 
> > portage could be smart about it ... it can easily parse the contents of 
> > SRC_URI and put tar into whatever DEPEND rather than forcing a stupid 
> > policy 
> > of listing tar in thousands of ebuilds
> 
> Dep should be represented imo, regardless if portage automatically 
> handles it (as mentioned above) or manually tacked in.
> Automatic tagging of such a dep makes a helluva lot more sense then 
> manual.
> 

True, but its not always viable .. how much longer will it take portage
to compute a dep graph that is 200 times more complete? 2 times? 10?
Also as already asked, what about the chicken egg issue ... (think tar
needing tar, or gzip needing gzip to unpack)?

> > > To head off the "profile has it, so we don't need it", consider a
> > > user profile, literally, a user desktop profile.  Kde, gnome, office
> > > crap, etc.  Right now, for such a profile you would need the toolchain
> > > tagged in, which I posit is invalid.
> > 
> > considering if you try to `emerge` something while under said profile and 
> > you 
> > already removed binutils/gcc from the system, the emerge will fail ... the 
> > reason why is pretty obvious
> 
> Err... missing the point, and proving my point.  Current portage 
> _will_ fail because it's an unstated dependency.  Why shouldn't 
> portage be provided the deps it needs so it can figure out what is 
> needed to get to what the user requested?
> 

I do not think so .. his point is: htf do you build binutils without
binutils installed ?  Same for gcc.


Thanks,

-- 
Martin Schlemmer
Gentoo Linux Developer, Desktop/System Team Developer
Cape Town, South Africa



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

Re: [gentoo-dev] New virtual: virtual/pcmcia

[Martin Schlemmer]

On Wed, 2005-06-29 at 11:18 +0200, Henrik Brix Andersen wrote:
> Hi,
> 
> Starting from linux-2.6.13-rc1 the PCMCIA subsystem has been patched to
> exports certain internals to sysfs, which allows using hotplug for
> handling insertion/ejection of 16bit PCMCIA cards.
> 
> For this to work, a new package called pcmciautils [1] will need to be
> added to portage. Therefore, a new virtual/pcmcia (which will default to
> sys-apps/pcmcia-cs in base/virtuals for now) will be added as well.
> 
> I have had sys-apps/pcmciautils in my portage overlay [2] for quite a
> while now, just waiting for the needed functionality to be merged into
> Linus' tree.
> 
> The linux-mod eclass will be changed to depend on virtual/pcmcia for
> pcmcia support. Future ebuilds that just need a PCMCIA card manager
> should depend on virtual/pcmcia as well.
> 
> If anybody has any objections and/or questions to this new virtual,
> please drop me an e-mail.
> 

A bit late I know, but just for interest sake .. virtuals is usually
used when more than one package usually provides the same compatible
api/tool ... which basically means pcmcia-cs and pcmciautils do the same
thing and cannot be installed together ?  Sorry if my non-pcmcia
cluedup-ness shows ...


Thanks,

-- 
Martin Schlemmer
Gentoo Linux Developer, Desktop/System Team Developer
Cape Town, South Africa



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

Re: [gentoo-dev] Software patents

[Jon Portnoy]

On Mon, Jul 04, 2005 at 11:59:26PM -0700, Anthony Gorecki wrote:
> On Monday, July 04, 2005 11:19 pm, Jon Portnoy wrote:
> > I am wondering why we have anonymous trolls on this mailing list.
> 
> This is a public mailing list that doesn't use message filters.
> 

I am aware of this, however generally we don't have anonymous folks 
coming out of the woodwork advocating removal of huge chunks of the 
Portage tree for their soapbox cause 8)

-- 
Jon Portnoy
avenj/irc.freenode.net
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Software patents

[twofourtysix]

On 05/07/05, Patrick Lauer <[EMAIL PROTECTED]> wrote:
> On Tue, 2005-07-05 at 06:13 +0100, twofourtysix wrote:
> > Mostly, I was hoping that all those people who seem more than happy to
> > advocate something with *words* would be prepared to back them up with
> > *actions*. I think it's a shame that Gentoo is prepared to encourage
> > people to pester their politicians whilst simultaneously refusing to
> > spend a few minutes practising what it preaches.
> 
> Ok ... let's remove all software that might violate a european patent.

Who was talking about removing ebuilds for software just because that
software violates a patent? I certainly wasn't... Strange that I'm
being accused of trolling when I'm not the one with the straw man
arguments.

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Software patents

[Patrick Lauer]

On Tue, 2005-07-05 at 06:13 +0100, twofourtysix wrote:
> Mostly, I was hoping that all those people who seem more than happy to
> advocate something with *words* would be prepared to back them up with
> *actions*. I think it's a shame that Gentoo is prepared to encourage
> people to pester their politicians whilst simultaneously refusing to
> spend a few minutes practising what it preaches.

Ok ... let's remove all software that might violate a european patent.

As some people stated, the kernel will go. As far as I know glibc and
gcc will be removed too.
All programs using sockets could potentially be an abuse, so no network
for you.
No progress bars.
Etc. etc.

I think skel.ebuild will be among the few survivors - 30.000 patents
don't leave much space for non-violating software, especially once you
realize that many of those patents are for trivial ideas (which are
unpatentable)

Or in other words:
Stop using "Free" Software since it's theft ;-)

wkr,
Patrick
-- 
Stand still, and let the rest of the universe move


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

Re: [gentoo-dev] Software patents

[Stuart Longland]

twofourtysix wrote:
> On 05/07/05, Robert Paskowitz <[EMAIL PROTECTED]> wrote:
> 
>>You have encouraged gentoo to remove patent-encoumbered software from
>>portage. I'd like to see you personally work with only software that
>>does not contain any patented work.
> 
> No, I have encouraged Gentoo to remove software written by companies
> who are strongly behind software patents. Big difference. It's so easy
> to get software patents in the USA currently that it's likely that
> every single thing in the tree is covered by some bogus software
> patent. However, in most cases, these patents are not held by the same
> people who are making the software.

Actually, you'd be suprised.  _Quite a few_ companies, quite actively
involved in promoting Linux, also, have quite a few software patents,
that directly affect things like the Linux kernel.  Some of these
companies own quite big chunks of the Linux kernel source.

So your suggestion is neither practical, nor does it help the patent
case in any way shape or form.
-- 
    _ Stuart Longland (a.k.a Redhatter)
/  _ \   ______  __| |__  __   __ Gentoo Linux/MIPS Cobalt and Docs
- (_) \ /   \  ;   \(__   __)/  \ /  \Developer
 \//  O _| / /\ \  | |  | /\ | /\ |
 /   / \   /__| /  \ \ | |  | \/ | \/ |
(___/   \/|_;  |_| \_/   \__/ \__/ http://dev.gentoo.org/~redhatter


signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Software patents

[Ioannis Aslanidis]

On 7/5/05, Kumba <[EMAIL PROTECTED]> wrote:
> 2) This pointless debate will eventually die, because if it doesn't
>I'm going to start quoting select excerpts from Vogon Poetry.
> 
> 3) If the Vogon Poetry fails, I'll start reading excerpts from
>Grunthos the Flatulent's "Ode To A Small Lump Of Green Putty
>I Found In My Armpit One Midsummer Morning".

Can we have a demo?

-- 
Ioannis Aslanidis

 0xB9B11F4E
 0xC2539DA3
 0xF202D067


Hellenic Gentoo GNU/Linux project manager (http://hellenicgentoo.sf.net)
FIRECOPS++ project manager (http://firecops.sf.net)
Digger Realoaded (http://digger-reloaded.sf.net)
Gentoo Forums Global Moderator (http://forums.gentoo.org)

Computer Engineering student at Universitat Rovira i Virgili

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Software patents

[Kumba]

twofourtysix wrote:


Not being privy to -core either, I am wondering about the apparently
hypocritical stance being taken on this issue.


I'm not sure if you caught the last few mails, but as stated, opinions posted on 
the Planet/Blog/Bathroom Stall are simply _opinions_ of individual entities. 
They are _not_ opinions of the entire organization, no matter how many opinions 
for or against there may be.


As such, the following events can be expected to occur:
1) Software will _not_ be removed from the tree simply because
   it is made by a company who just so happens to favour
   software patents.

2) This pointless debate will eventually die, because if it doesn't
   I'm going to start quoting select excerpts from Vogon Poetry.

3) If the Vogon Poetry fails, I'll start reading excerpts from
   Grunthos the Flatulent's "Ode To A Small Lump Of Green Putty
   I Found In My Armpit One Midsummer Morning".

4) If that happens to fail, which it shouldn't, I'll be forced to
   depths I haven't visited in quite a long time: Poetry from
   Paul Neil Milne Johnstone.

5) Everyone will become happy, and help Save the Pikachus.


--Kumba

--
Gentoo/MIPS Team Lead
Gentoo Foundation Board of Trustees

"Such is oft the course of deeds that move the wheels of the world: small hands 
do them because they must, while the eyes of the great are elsewhere."  --Elrond

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Software patents

[Anthony Gorecki]

On Monday, July 04, 2005 10:13 pm, twofourtysix wrote:
> Mostly, I was hoping that all those people who seem more than happy to
> advocate something with *words* would be prepared to back them up with
> *actions*.

I advocate that more rapid stabilization of the tree would be very useful for 
the users; unfortunately, the (wo)man-power doesn't exist, even if the desire 
does. It's just not that simple.


-- 
Anthony Gorecki
Ectro-Linux Foundation


pgpl4G5OkiV31.pgp
Description: PGP signature

Re: [gentoo-dev] Software patents

[Stuart Longland]

Anthony Gorecki wrote:
> On Monday, July 04, 2005 10:14 pm, Stuart Longland wrote:
> 
>>Why stop there?  Why not extend it to hardware manufacturers that make
>>heavy use of patents?
>>
>>Good luck finding a decent video card for that lovely desktop of yours. :-)
> 
> I'm still holding out hope that the open sourced video card project (of which 
> I can't recall the name) will have some degree of success. It'll likely be 
> some time before they'll even be able to release a (conservative) moderately 
> powerful graphics card.
> 
> The likelyhood of them competing with nVidia is fairly low, but I suppose 
> that 
> the same was once said of AMD versus Intel.

I think I recall that one... Tech Source if I'm not mistaken...
http://marc.theaimsgroup.com/?l=linux-kernel&m=109831011607347&w=2

I too would love to see a decent open-source friendly graphic card.  ATI
have been pretty good with their r200-based cards... although the
driver's still got quite a bit to be desired.  I think a completely open
player in the field might just be what the industry needs.

But that's offtopic for this thread :-)

-- 
    _ Stuart Longland (a.k.a Redhatter)
/  _ \   ______  __| |__  __   __ Gentoo Linux/MIPS Cobalt and Docs
- (_) \ /   \  ;   \(__   __)/  \ /  \Developer
 \//  O _| / /\ \  | |  | /\ | /\ |
 /   / \   /__| /  \ \ | |  | \/ | \/ |
(___/   \/|_;  |_| \_/   \__/ \__/ http://dev.gentoo.org/~redhatter


signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Software patents

[Anthony Gorecki]

On Monday, July 04, 2005 11:19 pm, Jon Portnoy wrote:
> I am wondering why we have anonymous trolls on this mailing list.

This is a public mailing list that doesn't use message filters.


-- 
Anthony Gorecki
Ectro-Linux Foundation


pgp3MElZoJB2f.pgp
Description: PGP signature