[gentoo-dev] modular X - 7.0 RC1

[gentoo-dev] modular X - 7.0 RC1

[Donnie Berkholz]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

The first release candidate was announced roughly 12 hours ago. And
fitting the Gentoo you know as up to the minute, so far beyond the
bleeding edge that it's wearing a Band-Aid before it starts to bleed,
comes the complete package in Portage -- all 296 packages worth.

Thanks to the dedicated work of Joshua Baergen and me, you've got just
what you asked for -- newer X than even money can buy. Pound on it, test
it, break it, and file bugs. Let us know how it works.

Metabuilds should be forthcoming shortly. I'd appreciate input on
http://dev.gentoo.org/~spyderous/xorg-x11/metabuilds.txt and in
particular from people on the GNOME and KDE teams.

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

iD8DBQFDV0MuXVaO67S1rtsRAk7VAKCue2oygLGEozl0FZFqOzGGJKs0ZgCg7pux
yNovZJUdo5UzhtEdZXFuxTg=
=fGcc
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] modular X - 7.0 RC1

[Simon Strandman]

Donnie Berkholz skrev:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> The first release candidate was announced roughly 12 hours ago. And
> fitting the Gentoo you know as up to the minute, so far beyond the
> bleeding edge that it's wearing a Band-Aid before it starts to bleed,
> comes the complete package in Portage -- all 296 packages worth.
>
> Thanks to the dedicated work of Joshua Baergen and me, you've got just
> what you asked for -- newer X than even money can buy. Pound on it, test
> it, break it, and file bugs. Let us know how it works.
>
> Metabuilds should be forthcoming shortly. I'd appreciate input on
> http://dev.gentoo.org/~spyderous/xorg-x11/metabuilds.txt and in
> particular from people on the GNOME and KDE teams.
>
> Thanks,
> Donnie

Will you add a ebuild for the 6.9-RC1 release also, or will gentoo go 
completely for the modular tree?

-- 
Simon Strandman <simon.strandman@telia.com>

-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: modular X - 7.0 RC1

[Duncan]

Simon Strandman posted <43575756.8060908@telia.com>, excerpted below,  on
Thu, 20 Oct 2005 10:37:42 +0200:

> Donnie Berkholz skrev:
> 
>> The first release candidate was announced roughly 12 hours ago. And
>> fitting the Gentoo you know as up to the minute, so far beyond the
>> bleeding edge that it's wearing a Band-Aid before it starts to bleed,
>> comes the complete package in Portage -- all 296 packages worth.
> 
> Will you add a ebuild for the 6.9-RC1 release also, or will gentoo go 
> completely for the modular tree?

Donnie mentioned some weeks/months ago here on dev, when discussing the
move to modular, that Gentoo would be going totally modular.  It fits with
the way Gentoo does things, allowing folks to avoid installing what they
don't need, AND the 6.9 monolithic release has been announced as basically
the end of the monolithic line upstream, so we'd have to move to it
eventually in any case.

Note that even the monolithic X ebuilds have had a couple modules split
out, for some time, xterm's the example I remember.

That's why... if you've been following, there hasn't been anything beyond
the monolithic 6.8.99.15 snapshot in portage, as work had switched to
modular, altho .15 has had a few -rX releases.

FWIW, I tried unmasking the modular ebuilds and merging using Donnie's
HOWTO, as posted here earlier, but while it all compiled, something wasn't
right and X wouldn't launch.  I never had time to track it down, tho I
really wanted to get it running as I've been hacking up the monolithic
ebuilds to remove stuff I didn't want, for some time, so the best
I've been able to do is run those .15 monolithic snapshots mentioned
earlier.  (It's quite possible the issue was related to gcc4 or the masked
binutils and glibc I'm running in relation to that, or it could have been
that in combination with my arch, amd64, or... it could have been just my
particular installation...)

I'm currently in the middle of compiling KDE-3.5.0-beta2, which is out,
and will probably take a couple days to recuperate after that before
attempting modular-X again.  However, it's a pretty safe bet I'll be
trying it before the end of next week!

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] modular X - 7.0 RC1

[Spider (D.m.D. Lj.)]

[-- Attachment #1: Type: text/plain, Size: 1085 bytes --]

On Thu, 2005-10-20 at 00:11 -0700, Donnie Berkholz wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> The first release candidate was announced roughly 12 hours ago. And
> fitting the Gentoo you know as up to the minute, so far beyond the
> bleeding edge that it's wearing a Band-Aid before it starts to bleed,
> comes the complete package in Portage -- all 296 packages worth.
> 
> Thanks to the dedicated work of Joshua Baergen and me, you've got just
> what you asked for -- newer X than even money can buy. Pound on it, test
> it, break it, and file bugs. Let us know how it works.
> 
> Metabuilds should be forthcoming shortly. I'd appreciate input on
> http://dev.gentoo.org/~spyderous/xorg-x11/metabuilds.txt and in
> particular from people on the GNOME and KDE teams.


Bloody awesome!


A question, do you want test-builds against the current -stable- tree or
the current ~ tree for various architectures?


//Spider
-- 
begin  .signature
Tortured users / Laughing in pain
See Microsoft KB Article Q265230 for more information.
end


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] modular X - 7.0 RC1

[Dan Armak]

[-- Attachment #1: Type: text/plain, Size: 1473 bytes --]

On Thursday 20 October 2005 09:11, Donnie Berkholz wrote:
> Metabuilds should be forthcoming shortly. I'd appreciate input on
> http://dev.gentoo.org/~spyderous/xorg-x11/metabuilds.txt and in
> particular from people on the GNOME and KDE teams.

KDE doesn't have any special requirements. It doesn't use any kind of X11 
build tool (what is there other than imake?). It does use some X apps like 
xmessage, xset etc. After you commit your metaebuilds we'll update the deps 
as needed. The only metaebuild we'll need to depend on is -libs.

However, consider this usecase: user (who's used to the old docs) installs new 
stage3, types 'emerge kde', runs kdm... oops, no X server...

To keep the current behaviour, the kde metaebuild (and gnome and the other 
WMs) would have to depend on xorg-x11, which strictly speaking is 
unnecessary. Opinions? How can we educate the users to manually 'emerge 
xorg-x11'? Personally I'm in favor of updating the docs, making a big 
announcement on all channels, and preparing a nice bug to close duplicates 
against.

We'll also need to educate them about xorg-x11 not installing fonts any 
longer. The way I understood your metabuilds.txt, 'emerge xorg-x11 kde' would 
result in an unusable system without any fonts at all...

-- 
Dan Armak
Gentoo Linux developer (KDE)
Public GPG key: http://dev.gentoo.org/~danarmak/danarmak-gpg-public.key
Fingerprint: DD70 DBF9 E3D4 6CB9 2FDD  0069 508D 9143 8D5F 8951

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] modular X - 7.0 RC1

[Olivier Crête]

[-- Attachment #1: Type: text/plain, Size: 681 bytes --]

On Thu, 2005-20-10 at 15:26 +0200, Dan Armak wrote:
> On Thursday 20 October 2005 09:11, Donnie Berkholz wrote:
> > Metabuilds should be forthcoming shortly. I'd appreciate input on
> > http://dev.gentoo.org/~spyderous/xorg-x11/metabuilds.txt and in
> > particular from people on the GNOME and KDE teams.
>
> We'll also need to educate them about xorg-x11 not installing fonts any 
> longer. The way I understood your metabuilds.txt, 'emerge xorg-x11 kde' would 
> result in an unusable system without any fonts at all...

If this is the case, xorg-x11 should pull in at least minimal fonts
(fixed, etc). 

-- 
Olivier Crête
tester@gentoo.org
x86 Security Liaison

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] modular X - 7.0 RC1

[Mike Williams]

On Thursday 20 October 2005 14:26, Dan Armak wrote:
> To keep the current behaviour, the kde metaebuild (and gnome and the other
> WMs) would have to depend on xorg-x11, which strictly speaking is
> unnecessary. Opinions? How can we educate the users to manually 'emerge
> xorg-x11'? Personally I'm in favor of updating the docs, making a big
> announcement on all channels, and preparing a nice bug to close duplicates
> against.
>
> We'll also need to educate them about xorg-x11 not installing fonts any
> longer. The way I understood your metabuilds.txt, 'emerge xorg-x11 kde'
> would result in an unusable system without any fonts at all...

As a fairly average joe user when it comes to all things X, I feel it would be 
best to keep the current X USE flag behaviour, i.e. a full working Xserver. 
The same goes for xorg-x11, or virtual/x11.
KDE needs some X libs, so obviously must always depend on them, but having the 
X USE set should call in a complete working server.

For packages that can work with, or without X, and should give the option to 
have a full server, or not, perhaps a new USE flag is needed? Xlibs?

-- 
Mike Williams
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] modular X - 7.0 RC1

[Dan Armak]

[-- Attachment #1: Type: text/plain, Size: 1967 bytes --]

On Thursday 20 October 2005 17:23, Mike Williams wrote:
> On Thursday 20 October 2005 14:26, Dan Armak wrote:
> > To keep the current behaviour, the kde metaebuild (and gnome and the
> > other WMs) would have to depend on xorg-x11, which strictly speaking is
> > unnecessary. Opinions? How can we educate the users to manually 'emerge
> > xorg-x11'? Personally I'm in favor of updating the docs, making a big
> > announcement on all channels, and preparing a nice bug to close
> > duplicates against.
> >
> > We'll also need to educate them about xorg-x11 not installing fonts any
> > longer. The way I understood your metabuilds.txt, 'emerge xorg-x11 kde'
> > would result in an unusable system without any fonts at all...
>
> As a fairly average joe user when it comes to all things X, I feel it would
> be best to keep the current X USE flag behaviour, i.e. a full working
> Xserver. The same goes for xorg-x11, or virtual/x11.
That's not the meaning of the flag. Its meaning is 'enable optional X11 
support'. Usually (almost always) this means client X support.

For apps that really have optional support for the xorg-x11 server, a new USE 
flag might be introduced.

> KDE needs some X libs, so obviously must always depend on them, but having
> the X USE set should call in a complete working server.
>
> For packages that can work with, or without X, and should give the option
> to have a full server, or not, perhaps a new USE flag is needed? Xlibs?
No. That would change the meaning of the X USE flag. We could add a new USE 
flag, but we shouldn't rename existing ones.

In any case, the decision of optional clientside X support (the X USE flag 
today) should be completely separate from the decision of installing a local 
X server.

-- 
Dan Armak
Gentoo Linux developer (KDE)
Public GPG key: http://dev.gentoo.org/~danarmak/danarmak-gpg-public.key
Fingerprint: DD70 DBF9 E3D4 6CB9 2FDD  0069 508D 9143 8D5F 8951

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] modular X - 7.0 RC1

[Luca Barbato]

Dan Armak wrote:
> On Thursday 20 October 2005 09:11, Donnie Berkholz wrote:
> To keep the current behaviour, the kde metaebuild (and gnome and the other 
> WMs) would have to depend on xorg-x11, which strictly speaking is 
> unnecessary. Opinions? How can we educate the users to manually 'emerge 
> xorg-x11'? Personally I'm in favor of updating the docs, making a big 
> announcement on all channels, and preparing a nice bug to close duplicates 
> against.
> 
> We'll also need to educate them about xorg-x11 not installing fonts any 
> longer. The way I understood your metabuilds.txt, 'emerge xorg-x11 kde' would 
> result in an unusable system without any fonts at all...
> 

a useflag could solve the issue as well a all inclusive metaebuild for X.


-- 

Luca Barbato

Gentoo/linux Developer		Gentoo/PPC Operational Leader
http://dev.gentoo.org/~lu_zero

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] modular X - 7.0 RC1

[Dan Armak]

[-- Attachment #1: Type: text/plain, Size: 1443 bytes --]

On Thursday 20 October 2005 17:28, Luca Barbato wrote:
> Dan Armak wrote:
> > On Thursday 20 October 2005 09:11, Donnie Berkholz wrote:
> > To keep the current behaviour, the kde metaebuild (and gnome and the
> > other WMs) would have to depend on xorg-x11, which strictly speaking is
> > unnecessary. Opinions? How can we educate the users to manually 'emerge
> > xorg-x11'? Personally I'm in favor of updating the docs, making a big
> > announcement on all channels, and preparing a nice bug to close
> > duplicates against.
> >
> > We'll also need to educate them about xorg-x11 not installing fonts any
> > longer. The way I understood your metabuilds.txt, 'emerge xorg-x11 kde'
> > would result in an unusable system without any fonts at all...
>
> a useflag could solve the issue as well a all inclusive metaebuild for X.
To solve this issue it would have to be an on-by-default flag, i.e. 
'noxserver'. I know some people are strongly against nofoo flags. 

Also, we'd have to include RDEPEND="!noxserver? ( x11-base/xorg-x11 )" in 
every ebuild in the tree being updated to depend on x11-base/xorg-libs. Or an 
eclass to the same effect. This would be easily forgotten in new ebuilds, and 
then we'd get inconsistent behavior.

-- 
Dan Armak
Gentoo Linux developer (KDE)
Public GPG key: http://dev.gentoo.org/~danarmak/danarmak-gpg-public.key
Fingerprint: DD70 DBF9 E3D4 6CB9 2FDD  0069 508D 9143 8D5F 8951

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] modular X - 7.0 RC1

[Donnie Berkholz]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Dan Armak wrote:
| On Thursday 20 October 2005 17:28, Luca Barbato wrote:
|>a useflag could solve the issue as well a all inclusive metaebuild for X.
|
| To solve this issue it would have to be an on-by-default flag, i.e.
| 'noxserver'. I know some people are strongly against nofoo flags.

Or, you could just activate it in the base profile.

| Also, we'd have to include RDEPEND="!noxserver? ( x11-base/xorg-x11 )" in
| every ebuild in the tree being updated to depend on
x11-base/xorg-libs. Or an
| eclass to the same effect. This would be easily forgotten in new
ebuilds, and
| then we'd get inconsistent behavior.

That's a good point. Any ideas on how to deal with it?

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

iD8DBQFDV+VJXVaO67S1rtsRAoLsAJ0aiEOHDnpTJ/8vM5ImM23qmz1oXwCeLgG4
LVQZG0Vp/BG5IiAw5IlYc7Q=
=jMQO
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] modular X - 7.0 RC1

[Dan Armak]

[-- Attachment #1: Type: text/plain, Size: 775 bytes --]

On Thursday 20 October 2005 20:43, Donnie Berkholz wrote:
> - gpg control packet
>
> Dan Armak wrote:
> | On Thursday 20 October 2005 17:28, Luca Barbato wrote:
> |>a useflag could solve the issue as well a all inclusive metaebuild for X.
> |
> | To solve this issue it would have to be an on-by-default flag, i.e.
> | 'noxserver'. I know some people are strongly against nofoo flags.
>
> Or, you could just activate it in the base profile.
True. I forget - why can't we solve the problem of all nofoo USE flags this 
way? Or is the (remaining) problem only with local flags?

-- 
Dan Armak
Gentoo Linux developer (KDE)
Public GPG key: http://dev.gentoo.org/~danarmak/danarmak-gpg-public.key
Fingerprint: DD70 DBF9 E3D4 6CB9 2FDD  0069 508D 9143 8D5F 8951

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] modular X - 7.0 RC1

[Donnie Berkholz]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Dan Armak wrote:
| On Thursday 20 October 2005 20:43, Donnie Berkholz wrote:
|>Or, you could just activate it in the base profile.
|
| True. I forget - why can't we solve the problem of all nofoo USE flags
this
| way? Or is the (remaining) problem only with local flags?

Some people have issues with adding local flags to profiles. As for the
others, I dunno. Maybe they're just too lazy to get their flag in profiles.

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

iD8DBQFDV/CdXVaO67S1rtsRArZhAKDhNOuRs24Fh5B4kiB3+FC3FYHY2gCg3b4l
9HULcG30xudaDdwsOwV9xJg=
=zLAN
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] modular X - 7.0 RC1

[Diego 'Flameeyes' Pettenò]

[-- Attachment #1: Type: text/plain, Size: 531 bytes --]

On Thursday 20 October 2005 21:25, Dan Armak wrote:
> True. I forget - why can't we solve the problem of all nofoo USE flags this
> way? Or is the (remaining) problem only with local flags?
Too many people using -* (due to auto flags) so that will break for most of 
them.
It's one of the reasons we have nocxx for example (you see how many people 
would break with -cxx on useflags? :P).

-- 
Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/
Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] modular X - 7.0 RC1

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 620 bytes --]

On Thu, 20 Oct 2005 21:35:39 +0200 "Diego 'Flameeyes' Pettenò"
<flameeyes@gentoo.org> wrote:
| On Thursday 20 October 2005 21:25, Dan Armak wrote:
| > True. I forget - why can't we solve the problem of all nofoo USE
| > flags this way? Or is the (remaining) problem only with local flags?
| Too many people using -* (due to auto flags) so that will break for
| most of them.

People using -* will just have to deal with the consequences...

-- 
Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] modular X - 7.0 RC1

[Donnie Berkholz]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Diego 'Flameeyes' Pettenò wrote:
| On Thursday 20 October 2005 21:25, Dan Armak wrote:
|
|>True. I forget - why can't we solve the problem of all nofoo USE flags
this
|>way? Or is the (remaining) problem only with local flags?
|
| Too many people using -* (due to auto flags) so that will break for
most of
| them.
| It's one of the reasons we have nocxx for example (you see how many
people
| would break with -cxx on useflags? :P).

I think you're missing the context. He's saying we solve the nofoo
problem by adding foo to profiles instead, not by adding nofoo.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFDV/MmXVaO67S1rtsRAh1HAJ4+StXYt4k/ylB5bd3b7v9wPjgnAQCdHleY
RElr49K+bgam51S/ZHJlUzo=
=34il
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] modular X - 7.0 RC1

[Mike Frysinger]

On Thursday 20 October 2005 03:42 pm, Donnie Berkholz wrote:
> I think you're missing the context. He's saying we solve the nofoo
> problem by adding foo to profiles instead, not by adding nofoo.

but you seem to be missing what Diego is saying

even if we put 'cxx' into all profiles, people who put '-*' into their 
make.conf will have '-cxx'

so gcc and stuff will no longer generate C++
-mike
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] modular X - 7.0 RC1

[Diego 'Flameeyes' Pettenò]

[-- Attachment #1: Type: text/plain, Size: 441 bytes --]

On Thursday 20 October 2005 21:42, Donnie Berkholz wrote:
> I think you're missing the context. He's saying we solve the nofoo
> problem by adding foo to profiles instead, not by adding nofoo.
Exactly

Add foo to profiles, users sets -* to remove the use.defaults flags, then the 
user has no foo :)

-- 
Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/
Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] modular X - 7.0 RC1

[Mike Owen]

On 10/20/05, Diego 'Flameeyes' Pettenò <flameeyes@gentoo.org> wrote:
> Add foo to profiles, users sets -* to remove the use.defaults flags, then the
> user has no foo :)
>

Which is exactly as it should be. If someone is going to use -*, then
they should learn to live with the consequences. Even I, as a regular
user know that.

Mike

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] modular X - 7.0 RC1

[Donnie Berkholz]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Diego 'Flameeyes' Pettenò wrote:
| On Thursday 20 October 2005 21:42, Donnie Berkholz wrote:
|
|>I think you're missing the context. He's saying we solve the nofoo
|>problem by adding foo to profiles instead, not by adding nofoo.
|
| Exactly
|
| Add foo to profiles, users sets -* to remove the use.defaults flags,
then the
| user has no foo :)

The point of -* being to get rid of everything, I don't see how this
makes sense.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFDV/vYXVaO67S1rtsRApjQAKDej1AY27LXFGJm4/SSb1g6hQzYGACdFhug
Tq3OXv1pxRa/oLvKdaI0JTw=
=kBIL
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] modular X - 7.0 RC1

[Carsten Lohrke]

[-- Attachment #1: Type: text/plain, Size: 429 bytes --]

On Thursday 20 October 2005 21:35, Diego 'Flameeyes' Pettenò wrote:
> Too many people using -* (due to auto flags) so that will break for most of
> them.

So we have the three things we should deprecate in a single thread:

a) no* flags
b) auto flags
c) -* and -<foo> for all architectures in one ebuild.

How about tackling that now, instead living with the consequences for yet 
another unknown while?


Carsten

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] modular X - 7.0 RC1

[Alec Warner]

Carsten Lohrke wrote:
> On Thursday 20 October 2005 21:35, Diego 'Flameeyes' Pettenò wrote:
> 
>>Too many people using -* (due to auto flags) so that will break for most of
>>them.
> 
> 
> So we have the three things we should deprecate in a single thread:
> 
> a) no* flags
> b) auto flags
> c) -* and -<foo> for all architectures in one ebuild.
> 
> How about tackling that now, instead living with the consequences for yet 
> another unknown while?
> 
> 
> Carsten

All of these are basically hacks around portage deficiences.  The 
portage team knows of them, the portage team is working to make sure 
they aren't needed in the future.  However none of the fixes will be out 
'soon', so unless you have patches to fix them or suggestions that don't 
involve code changes, there isn't much that can be done.
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] modular X - 7.0 RC1

[Matthijs van der Vleuten]

On 10/20/05, Dan Armak <danarmak@gentoo.org> wrote:
> To solve this issue it would have to be an on-by-default flag, i.e.
> 'noxserver'. I know some people are strongly against nofoo flags.

What about an off-by-default 'xserver' flag?

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] modular X - 7.0 RC1

[Dan Armak]

[-- Attachment #1: Type: text/plain, Size: 911 bytes --]

On Thursday 20 October 2005 20:58, Matthijs van der Vleuten wrote:
> On 10/20/05, Dan Armak <danarmak@gentoo.org> wrote:
> > To solve this issue it would have to be an on-by-default flag, i.e.
> > 'noxserver'. I know some people are strongly against nofoo flags.
>
> What about an off-by-default 'xserver' flag?
It wouldn't solve the problem at hand. 

Without any flag at all, the user needs to 'emerge xorg-x11' manually to get 
eg KDE to run locally. With an off-by-default flag, he needs to set it on 
manually, _before_ installing KDE, to get an xorg-x11 server. As long as he 
needs to do something manually, explicitly, it should just be an 'emerge 
xorg-x11', which after all is a very simple operation.

-- 
Dan Armak
Gentoo Linux developer (KDE)
Public GPG key: http://dev.gentoo.org/~danarmak/danarmak-gpg-public.key
Fingerprint: DD70 DBF9 E3D4 6CB9 2FDD  0069 508D 9143 8D5F 8951

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] modular X - 7.0 RC1

[Kevin F. Quinn]

On 20/10/2005 21:16:47, Dan Armak (danarmak@gentoo.org) wrote:
> On Thursday 20 October 2005 20:58, Matthijs van der Vleuten wrote:
> > On 10/20/05, Dan Armak <danarmak@gentoo.org> wrote:
> > > To solve this issue it would have to be an on-by-default flag, i.e.
> > > 'noxserver'. I know some people are strongly against nofoo flags.
> >
> > What about an off-by-default 'xserver' flag?
> It wouldn't solve the problem at hand. 
> 
> Without any flag at all, the user needs to 'emerge xorg-x11' manually to 
> get eg KDE to run locally. With an off-by-default flag, he needs to set 
> it on manually, _before_ installing KDE, to get an xorg-x11 server. As 
> long as he needs to do something manually, explicitly, it should just be 
> an 'emerge xorg-x11', which after all is a very simple operation.

Maybe I'm being stupid, but I don't understand why a user would need to
emerge xorg-x11 manually when doing 'emerge kde'.  Surely somewhere in kde's
dependency graph the X server is called up in RDEPEND?  An X server
is clearly a run-time dependency.

Like, konqueror RDEPENDS on qt which RDEPENDS on xorg-xserver, or whatever.

Kev.

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] modular X - 7.0 RC1

[Dan Armak]

[-- Attachment #1: Type: text/plain, Size: 1717 bytes --]

On Thursday 20 October 2005 21:48, Kevin F. Quinn wrote:
> On 20/10/2005 21:16:47, Dan Armak (danarmak@gentoo.org) wrote:
> > On Thursday 20 October 2005 20:58, Matthijs van der Vleuten wrote:
> > > On 10/20/05, Dan Armak <danarmak@gentoo.org> wrote:
> > > > To solve this issue it would have to be an on-by-default flag, i.e.
> > > > 'noxserver'. I know some people are strongly against nofoo flags.
> > >
> > > What about an off-by-default 'xserver' flag?
> >
> > It wouldn't solve the problem at hand.
> >
> > Without any flag at all, the user needs to 'emerge xorg-x11' manually to
> > get eg KDE to run locally. With an off-by-default flag, he needs to set
> > it on manually, _before_ installing KDE, to get an xorg-x11 server. As
> > long as he needs to do something manually, explicitly, it should just be
> > an 'emerge xorg-x11', which after all is a very simple operation.
>
> Maybe I'm being stupid, but I don't understand why a user would need to
> emerge xorg-x11 manually when doing 'emerge kde'.  Surely somewhere in
> kde's dependency graph the X server is called up in RDEPEND?  An X server
> is clearly a run-time dependency.
>
> Like, konqueror RDEPENDS on qt which RDEPENDS on xorg-xserver, or whatever.

No, KDE (like all X11 apps) only needs the client X11 libs and headers. It can 
then contact a remote X11 server over the network.

Now that the client libs and headers are available in separate ebuilds, 
there's no reason for KDE to depend on the server ebuild, so it won't.

-- 
Dan Armak
Gentoo Linux developer (KDE)
Public GPG key: http://dev.gentoo.org/~danarmak/danarmak-gpg-public.key
Fingerprint: DD70 DBF9 E3D4 6CB9 2FDD  0069 508D 9143 8D5F 8951

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] modular X - 7.0 RC1

[Alec Joseph Warner]

Dan Armak wrote:
> On Thursday 20 October 2005 21:48, Kevin F. Quinn wrote:
> 
>>On 20/10/2005 21:16:47, Dan Armak (danarmak@gentoo.org) wrote:
>>
>>>On Thursday 20 October 2005 20:58, Matthijs van der Vleuten wrote:
>>>
>>>>On 10/20/05, Dan Armak <danarmak@gentoo.org> wrote:
>>>>
>>>>>To solve this issue it would have to be an on-by-default flag, i.e.
>>>>>'noxserver'. I know some people are strongly against nofoo flags.
>>>>
>>>>What about an off-by-default 'xserver' flag?
>>>
>>>It wouldn't solve the problem at hand.
>>>
>>>Without any flag at all, the user needs to 'emerge xorg-x11' manually to
>>>get eg KDE to run locally. With an off-by-default flag, he needs to set
>>>it on manually, _before_ installing KDE, to get an xorg-x11 server. As
>>>long as he needs to do something manually, explicitly, it should just be
>>>an 'emerge xorg-x11', which after all is a very simple operation.
>>
>>Maybe I'm being stupid, but I don't understand why a user would need to
>>emerge xorg-x11 manually when doing 'emerge kde'.  Surely somewhere in
>>kde's dependency graph the X server is called up in RDEPEND?  An X server
>>is clearly a run-time dependency.
>>
>>Like, konqueror RDEPENDS on qt which RDEPENDS on xorg-xserver, or whatever.
> 
> 
> No, KDE (like all X11 apps) only needs the client X11 libs and headers. It can 
> then contact a remote X11 server over the network.
> 
> Now that the client libs and headers are available in separate ebuilds, 
> there's no reason for KDE to depend on the server ebuild, so it won't.
> 

Take the X use flag out, since X is horribly not descriptive.

Xclient, Xserver, both tell you what they are doing, both probably 
global use flags.  Announce it loudly, and fix everything at once, since 
that is probably how it will go anyway :)

I think it's really cool to be able to build a server that has no X, but 
has KDE on it, especially since 99% of the time I'd never actually log 
in locally.

There is nothing wrong with 2 flags here, IMHO.  Yeah you have to set 
them, either in default-linux/$arch ( not base here however, set it 
higher up, not everyone wants friggin x installed *shakes fist* ) or 
wherever.  That or auto-use, either way people using -* are screwed, we 
know this and they know it.  It's something they deal with every day.  I 
dout their system is going to be horribly screwed as long as they are 
paying attention.  If they randomly --depclean without looking, then 
yeah X will probably get ripped out from under them :)  Thats their risk.
  (antarus)
-Alec warner
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] modular X - 7.0 RC1

[Chris Gianelloni]

[-- Attachment #1: Type: text/plain, Size: 1401 bytes --]

On Thu, 2005-10-20 at 21:48 +0200, Kevin F. Quinn wrote:
> On 20/10/2005 21:16:47, Dan Armak (danarmak@gentoo.org) wrote:
> > On Thursday 20 October 2005 20:58, Matthijs van der Vleuten wrote:
> > > On 10/20/05, Dan Armak <danarmak@gentoo.org> wrote:
> > > > To solve this issue it would have to be an on-by-default flag, i.e.
> > > > 'noxserver'. I know some people are strongly against nofoo flags.
> > >
> > > What about an off-by-default 'xserver' flag?
> > It wouldn't solve the problem at hand. 
> > 
> > Without any flag at all, the user needs to 'emerge xorg-x11' manually to 
> > get eg KDE to run locally. With an off-by-default flag, he needs to set 
> > it on manually, _before_ installing KDE, to get an xorg-x11 server. As 
> > long as he needs to do something manually, explicitly, it should just be 
> > an 'emerge xorg-x11', which after all is a very simple operation.
> 
> Maybe I'm being stupid, but I don't understand why a user would need to
> emerge xorg-x11 manually when doing 'emerge kde'.  Surely somewhere in kde's
> dependency graph the X server is called up in RDEPEND?  An X server
> is clearly a run-time dependency.
> 
> Like, konqueror RDEPENDS on qt which RDEPENDS on xorg-xserver, or whatever.

DISPLAY="remote:0" startkde

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

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] modular X - 7.0 RC1

[Kevin F. Quinn]

On 20/10/2005 21:16:47, Dan Armak (danarmak@gentoo.org) wrote:
> On Thursday 20 October 2005 20:58, Matthijs van der Vleuten wrote:
> > On 10/20/05, Dan Armak <danarmak@gentoo.org> wrote:
> > > To solve this issue it would have to be an on-by-default flag, i.e.
> > > 'noxserver'. I know some people are strongly against nofoo flags.
> >
> > What about an off-by-default 'xserver' flag?
> It wouldn't solve the problem at hand. 
> 
> Without any flag at all, the user needs to 'emerge xorg-x11' manually to 
> get eg KDE to run locally. With an off-by-default flag, he needs to set 
> it on manually, _before_ installing KDE, to get an xorg-x11 server. As 
> long as he needs to do something manually, explicitly, it should just be 
> an 'emerge xorg-x11', which after all is a very simple operation.

Maybe I'm being stupid, but I don't understand why a user would need to
emerge xorg-x11 manually when doing 'emerge kde'.  Surely somewhere in kde's
dependency graph the X server is called up in RDEPEND?  An X server
is clearly a run-time dependency.

Like, konqueror RDEPENDS on qt which RDEPENDS on xorg-xserver, or whatever.

Kev.

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] modular X - 7.0 RC1

[Donnie Berkholz]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Dan Armak wrote:
| KDE doesn't have any special requirements. It doesn't use any kind of X11
| build tool (what is there other than imake?). It does use some X apps
like
| xmessage, xset etc. After you commit your metaebuilds we'll update the
deps
| as needed. The only metaebuild we'll need to depend on is -libs.

I'd prefer that people don't come to depend on metabuilds at all. See
http://dev.gentoo.org/~spyderous/xorg-x11/porting_to_modular_x_howto.txt.

| However, consider this usecase: user (who's used to the old docs)
installs new
| stage3, types 'emerge kde', runs kdm... oops, no X server...
|
| To keep the current behaviour, the kde metaebuild (and gnome and the
other
| WMs) would have to depend on xorg-x11, which strictly speaking is
| unnecessary. Opinions? How can we educate the users to manually 'emerge
| xorg-x11'? Personally I'm in favor of updating the docs, making a big
| announcement on all channels, and preparing a nice bug to close
duplicates
| against.

Couple of ideas here.

1) We do as you suggest, and make people emerge xorg-x11
2) KDE could add a USE=X and dep X? ( xorg-server )

| We'll also need to educate them about xorg-x11 not installing fonts any
| longer. The way I understood your metabuilds.txt, 'emerge xorg-x11
kde' would
| result in an unusable system without any fonts at all...

We will still install some fonts, but not all, and I'll note that in the
metabuilds text.

Thanks for the comments,
Donnie
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFDV+PhXVaO67S1rtsRAryFAJ4rQJ1FNcnDDiw0gYDAhUwGPFx9vACeOGor
uc7ieRH+D73hVLXt8hxAJF4=
=MNDF
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] modular X - 7.0 RC1

[Dan Armak]

[-- Attachment #1: Type: text/plain, Size: 2050 bytes --]

On Thursday 20 October 2005 20:37, Donnie Berkholz wrote:
> I'd prefer that people don't come to depend on metabuilds at all. 
OK, we can do this.

> See 
> http://dev.gentoo.org/~spyderous/xorg-x11/porting_to_modular_x_howto.txt.
That file says there won't be any x11-related virtuals anymore. Are you sure 
no package uses it in the sense of 'any X server' instead of 'any X client 
libs+headers'?

> Couple of ideas here.
>
> 1) We do as you suggest, and make people emerge xorg-x11
> 2) KDE could add a USE=X and dep X? ( xorg-server )

(2) is bad for several reasons:

Firstly, as I said in my other replies, this would change the current meaning 
of the X USE flag. The original meaning would stay without a flag.

Today it means 'enable support for clienside X11'. You want to make it mean 
'install X11 server'. If I'm building a headless box without an X11 server, 
but I do want to emerge KDE and run it over ssh -Y from another box, I need 
two useflags to specify this. But even if we introduce a new USE flag 
'Xserver', on by default where X is on by default, and used as you describe 
above, the problems I describe below will remain.

Secondly, there can be more than one X11 server (kdrive, etc). Depending on 
xorg-server is bad. If anything, we should introduce a virtual/x11-server.

Thirdly, it's a 'convenience dep': whether xorg-server is installed or not 
won't affect the behavior of KDE in any way (given a working DISPLAY 
setting).

Finally, it requires that extra change to (ideally) all X11 client apps. It's 
not intuitive, and so easy to forget when writing new ebuilds.

> We will still install some fonts, but not all, and I'll note that in the
> metabuilds text.
Which ones? Selected how? I'm asking because I don't want to work too hard on 
deciding which fonts KDE should depend on :-)

-- 
Dan Armak
Gentoo Linux developer (KDE)
Public GPG key: http://dev.gentoo.org/~danarmak/danarmak-gpg-public.key
Fingerprint: DD70 DBF9 E3D4 6CB9 2FDD  0069 508D 9143 8D5F 8951

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] modular X - 7.0 RC1

[Donnie Berkholz]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Dan Armak wrote:
| On Thursday 20 October 2005 20:37, Donnie Berkholz wrote:
|
|>I'd prefer that people don't come to depend on metabuilds at all.
|
| OK, we can do this.
|
|
|>See
|>http://dev.gentoo.org/~spyderous/xorg-x11/porting_to_modular_x_howto.txt.
|
| That file says there won't be any x11-related virtuals anymore. Are
you sure
| no package uses it in the sense of 'any X server' instead of 'any X
client
| libs+headers'?

I'm not aware of any. The only similar thing I'm aware of is a few
incredibly broken packages that require Xvfb at build time.

If there are packages that need to run any X server at build time,
they're even more broken.

| Firstly, as I said in my other replies, this would change the current
meaning
| of the X USE flag. The original meaning would stay without a flag.
|
| Today it means 'enable support for clienside X11'. You want to make it
mean
| 'install X11 server'. If I'm building a headless box without an X11
server,
| but I do want to emerge KDE and run it over ssh -Y from another box, I
need
| two useflags to specify this. But even if we introduce a new USE flag
| 'Xserver', on by default where X is on by default, and used as you
describe
| above, the problems I describe below will remain.

Does it really mean that? How about all of the X USE flags in font
ebuilds? They mean basically what I'm saying.

| Secondly, there can be more than one X11 server (kdrive, etc).
Depending on
| xorg-server is bad. If anything, we should introduce a virtual/x11-server.
|
| Thirdly, it's a 'convenience dep': whether xorg-server is installed or
not
| won't affect the behavior of KDE in any way (given a working DISPLAY
| setting).

Right, the intent is to basically say "I'm part of the 90% of users who
has X installed locally and wants things to just work."

| Finally, it requires that extra change to (ideally) all X11 client
apps. It's
| not intuitive, and so easy to forget when writing new ebuilds.

Yeah.


|>We will still install some fonts, but not all, and I'll note that in the
|>metabuilds text.
|
| Which ones? Selected how? I'm asking because I don't want to work too
hard on
| deciding which fonts KDE should depend on :-)

Selected arbitrarily by the x11 team based on requirement, common use
and prettiness factor. Probably font-misc-misc, font-bh-ttf,
font-adobe-utopia-type1 and maybe some others that are brought to my
attention.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFDV+1NXVaO67S1rtsRAlmXAJ4zr0ZCvF29BZwmDv/n/iagMMkIpgCgyO2h
lckxp/jpUG4FZxr0PQQAyjQ=
=x7RY
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] modular X - 7.0 RC1

[Dan Armak]

[-- Attachment #1: Type: text/plain, Size: 3613 bytes --]

Your mua or some gateway has inserted really ugly linebreaks in the text you 
quoted. I tried to make it prettier.

On Thursday 20 October 2005 21:17, Donnie Berkholz wrote:
> I'm not aware of any. The only similar thing I'm aware of is a few
> incredibly broken packages that require Xvfb at build time.
>
> If there are packages that need to run any X server at build time,
> they're even more broken.
Agreed.

> | Firstly, as I said in my other replies, this would change the current 
> | meaning of the X USE flag. The original meaning would stay without a flag.
> | Today it means 'enable support for clienside X11'. You want to make it
> | mean 'install X11 server'. If I'm building a headless box without an X11
> | server, but I do want to emerge KDE and run it over ssh -Y from another 
> | box, I need two useflags to specify this. But even if we introduce a new 
> | USE flag 'Xserver', on by default where X is on by default, and used as 
> | you describe above, the problems I describe below will remain.
> Does it really mean that? How about all of the X USE flags in font
> ebuilds? They mean basically what I'm saying.
Until today we've only had a single xorg-x11 ebuild. So all the ebuilds today 
have DEPEND="X? (virtual/x11 )", which includes an X server. But they only 
really need the clientside libs+headers and so (I argued) what they /really/ 
mean is 'enable support for clientside X', because the presence of the server 
doesn't affect them in any way.

But forget about what the flag is supposed to mean today. How can my scenario 
above be resolved without using two useflags?

> | Secondly, there can be more than one X11 server (kdrive, etc).
> | Depending on xorg-server is bad. If anything, we should introduce a
> | virtual/x11-server.
I'm just explicitly noting that you didn't comment on this.

> | Thirdly, it's a 'convenience dep': whether xorg-server is installed or
> | not won't affect the behavior of KDE in any way (given a working DISPLAY
> | setting).
>
> Right, the intent is to basically say "I'm part of the 90% of users who
> has X installed locally and wants things to just work."
They will just work if they just 'emerge xorg-server'. Just as they need to 
manually 'emerge KDE' and probably 'emerge openoffice' and mplayer and 
mozilla and lots of other things. They have to do all this when installing a 
new system anyway, so my opinion is that adding an extra manual emerge 
instruction to the handbook isn't any more bother to them and makes things a 
lot easier for us.

Gentoo has a tradition of minimalism in the system package list and so on. 
It's against the usual and correct Gentoo behavior, IMHO, to install (big!) 
stuff by default just because 90% of the users want it. A desktop sub-profile 
or meta-ebuild would be a better tool for this.

> |>We will still install some fonts, but not all, and I'll note that in the
> |>metabuilds text.
> |
> | Which ones? Selected how? I'm asking because I don't want to work too
> | hard on deciding which fonts KDE should depend on :-)
>
> Selected arbitrarily by the x11 team based on requirement, common use
> and prettiness factor. Probably font-misc-misc, font-bh-ttf,
> font-adobe-utopia-type1 and maybe some others that are brought to my
> attention.
Which other new font ebuilds were included in the monolithic xorg-x11 ebuild? 
media-fonts/font-*?

-- 
Dan Armak
Gentoo Linux developer (KDE)
Public GPG key: http://dev.gentoo.org/~danarmak/danarmak-gpg-public.key
Fingerprint: DD70 DBF9 E3D4 6CB9 2FDD  0069 508D 9143 8D5F 8951

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] modular X - 7.0 RC1

[Donnie Berkholz]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Dan Armak wrote:
| Your mua or some gateway has inserted really ugly linebreaks in the
text you
| quoted. I tried to make it prettier.
|
| On Thursday 20 October 2005 21:17, Donnie Berkholz wrote:
|>Selected arbitrarily by the x11 team based on requirement, common use
|>and prettiness factor. Probably font-misc-misc, font-bh-ttf,
|>font-adobe-utopia-type1 and maybe some others that are brought to my
|>attention.
|
| Which other new font ebuilds were included in the monolithic xorg-x11
ebuild?
| media-fonts/font-*?

Yep. And I see no reason to not just install the best format out of any
given selection rather than all of them, roughly like this:

1. ttf
2. type1
3. 100dpi
4. 75dpi
5. misc, sometimes
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFDV/yNXVaO67S1rtsRAgY2AJ0XLIcuj/kKxbjmumGHQbVok3+U+gCgk05b
nWLzi6KtA78NlG3K0o5D4S0=
=qVfK
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] modular X - 7.0 RC1

[Chris Gianelloni]

[-- Attachment #1: Type: text/plain, Size: 2705 bytes --]

On Thu, 2005-10-20 at 12:17 -0700, Donnie Berkholz wrote:
> |>See
> |>http://dev.gentoo.org/~spyderous/xorg-x11/porting_to_modular_x_howto.txt.
> |
> | That file says there won't be any x11-related virtuals anymore. Are
> you sure
> | no package uses it in the sense of 'any X server' instead of 'any X
> client
> | libs+headers'?
> 
> I'm not aware of any. The only similar thing I'm aware of is a few
> incredibly broken packages that require Xvfb at build time.

I know that we have used it to mean "requires an X server locally" for
some games.

> If there are packages that need to run any X server at build time,
> they're even more broken.

Nah, these were RDEPEND.  There's probably a better way to go about it
anyway.  If you've got any ideas, I'd love to hear them, as this is
something I'm going to have to tackle shortly.

> 
> | Firstly, as I said in my other replies, this would change the current
> meaning
> | of the X USE flag. The original meaning would stay without a flag.
> |
> | Today it means 'enable support for clienside X11'. You want to make it
> mean
> | 'install X11 server'. If I'm building a headless box without an X11
> server,
> | but I do want to emerge KDE and run it over ssh -Y from another box, I
> need
> | two useflags to specify this. But even if we introduce a new USE flag
> | 'Xserver', on by default where X is on by default, and used as you
> describe
> | above, the problems I describe below will remain.
> 
> Does it really mean that? How about all of the X USE flags in font
> ebuilds? They mean basically what I'm saying.

...or games ebuilds.  Apparently, we've been doing it wrong for a while,
too.  Granted, many of these games *also* happen to require libX11, but
not all of them do.

> | Secondly, there can be more than one X11 server (kdrive, etc).
> Depending on
> | xorg-server is bad. If anything, we should introduce a virtual/x11-server.
> |
> | Thirdly, it's a 'convenience dep': whether xorg-server is installed or
> not
> | won't affect the behavior of KDE in any way (given a working DISPLAY
> | setting).
> 
> Right, the intent is to basically say "I'm part of the 90% of users who
> has X installed locally and wants things to just work."

Right.

> | deciding which fonts KDE should depend on :-)
> 
> Selected arbitrarily by the x11 team based on requirement, common use
> and prettiness factor. Probably font-misc-misc, font-bh-ttf,
> font-adobe-utopia-type1 and maybe some others that are brought to my
> attention.

Nnnoooo! No Type1 bloat! :P

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

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] modular X - 7.0 RC1

[Dan Armak]

[-- Attachment #1: Type: text/plain, Size: 659 bytes --]

On Thursday 20 October 2005 23:06, Chris Gianelloni wrote:
> > Selected arbitrarily by the x11 team based on requirement, common use
> > and prettiness factor. Probably font-misc-misc, font-bh-ttf,
> > font-adobe-utopia-type1 and maybe some others that are brought to my
> > attention.
>
> Nnnoooo! No Type1 bloat! :P
To preserve existing behavior we can use the type1 USE flag. The monolithic 
xorg-x11 ebuild does that. The same can be done with truetype fonts.

-- 
Dan Armak
Gentoo Linux developer (KDE)
Public GPG key: http://dev.gentoo.org/~danarmak/danarmak-gpg-public.key
Fingerprint: DD70 DBF9 E3D4 6CB9 2FDD  0069 508D 9143 8D5F 8951

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] modular X - 7.0 RC1

[Donnie Berkholz]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Chris Gianelloni wrote:
| On Thu, 2005-10-20 at 12:17 -0700, Donnie Berkholz wrote:
|>Selected arbitrarily by the x11 team based on requirement, common use
|>and prettiness factor. Probably font-misc-misc, font-bh-ttf,
|>font-adobe-utopia-type1 and maybe some others that are brought to my
|>attention.
|
|
| Nnnoooo! No Type1 bloat! :P

There is no TTF alternative for Utopia, at least in portage or
distributed by X.Org.

Donnie
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFDWA4RXVaO67S1rtsRAiPTAJ4+wF9o8ybZ2MQdghKuCAnItATr0QCg7BXz
zk5+ZgDlsXtgslGK5Rc7MdQ=
=aUoz
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] modular X - 7.0 RC1

[Ben Skeggs]

[-- Attachment #1: Type: text/plain, Size: 826 bytes --]

Am Donnerstag, den 20.10.2005, 00:11 -0700 schrieb Donnie Berkholz:
> Thanks to the dedicated work of Joshua Baergen and me, you've got just
> what you asked for -- newer X than even money can buy. Pound on it, test
> it, break it, and file bugs. Let us know how it works.
> 
I had some issues updating xorg-server on amd64, it turns out
eselect-opengl was pointing /usr/include/GL/glxproto.h towards the emul
headers.  Which, don't contain some changes needed for the later modular
builds.  I filed bug #109922 about this issue.

Apart from that, everything I had installed for modular updated
successfully.

The only issue I've encountered so far is that XKB appears to be
completely broken for me.  I can't quite track down why at this stage.

Thanks guys for the quick work in updating the ebuilds!
Ben.

[-- Attachment #2: Dies ist ein digital signierter Nachrichtenteil --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] modular X - 7.0 RC1

[Herbie Hopkins]

On Fri, 2005-10-21 at 01:46 +1100, Ben Skeggs wrote:
> The only issue I've encountered so far is that XKB appears to be
> completely broken for me.  I can't quite track down why at this stage.

bug 109926

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] modular X - 7.0 RC1

[Ben Skeggs]

[-- Attachment #1: Type: text/plain, Size: 442 bytes --]

Am Donnerstag, den 20.10.2005, 16:28 +0100 schrieb Herbie Hopkins:
> On Fri, 2005-10-21 at 01:46 +1100, Ben Skeggs wrote:
> > The only issue I've encountered so far is that XKB appears to be
> > completely broken for me.  I can't quite track down why at this stage.
> 
> bug 109926
> 
Thanks!  That got rid of the XKB error messages in Xorg.0.log.  But..  I
still can't VT switch and the "windows" keys don't work at all either :(


[-- Attachment #2: Dies ist ein digital signierter Nachrichtenteil --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] modular X - 7.0 RC1

[Dan Armak]

[-- Attachment #1: Type: text/plain, Size: 563 bytes --]

On Thursday 20 October 2005 09:11, Donnie Berkholz wrote:
> Metabuilds should be forthcoming shortly. I'd appreciate input on
> http://dev.gentoo.org/~spyderous/xorg-x11/metabuilds.txt and in
> particular from people on the GNOME and KDE teams.

Don't forget a new virtual/x11-libs.

And we'll need to update the entire tree to depend on that instead of 
virtual/x11.

-- 
Dan Armak
Gentoo Linux developer (KDE)
Public GPG key: http://dev.gentoo.org/~danarmak/danarmak-gpg-public.key
Fingerprint: DD70 DBF9 E3D4 6CB9 2FDD  0069 508D 9143 8D5F 8951

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] modular X - 7.0 RC1

[Donnie Berkholz]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Dan Armak wrote:
| On Thursday 20 October 2005 09:11, Donnie Berkholz wrote:
|
|>Metabuilds should be forthcoming shortly. I'd appreciate input on
|>http://dev.gentoo.org/~spyderous/xorg-x11/metabuilds.txt and in
|>particular from people on the GNOME and KDE teams.
|
|
| Don't forget a new virtual/x11-libs.
|
| And we'll need to update the entire tree to depend on that instead of
| virtual/x11.

Again, I'll point to the porting guide.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFDV+RgXVaO67S1rtsRAqq9AKDZ9jI7KeLCl+3rH4D/GU0fjWbVbQCePc8A
mcxaDlhUStCFTnvn3R3U1Lo=
=tAko
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: modular X - 7.0 RC1

[R Hill]

Donnie Berkholz wrote:

> Thanks to the dedicated work of Joshua Baergen and me, you've got just
> what you asked for -- newer X than even money can buy. Pound on it, test
> it, break it, and file bugs. Let us know how it works.

You probably already know of it, but when following your modular-X HOWTO 
xorg-server has to be emerged with USE=-motif.  otherwise xorg-x11 
monolithic gets pulled in by openmotif.

root ~ #  emerge -aDtv xorg-server

These are the packages that I would merge, in reverse order:

Calculating dependencies ...done!
[blocks B     ] <x11-base/xorg-x11-7 (is blocking 
x11-proto/randrproto-1.1.1)
[blocks B     ] <x11-base/xorg-x11-7 (is blocking 
x11-proto/fixesproto-3.0.1)
[blocks B     ] <x11-base/xorg-x11-7 (is blocking x11-apps/xinit-0.99.2-r1)
[blocks B     ] <x11-base/xorg-x11-7 (is blocking 
x11-proto/xf86bigfontproto-1.1.1)
[blocks B     ] <x11-base/xorg-x11-7 (is blocking 
x11-apps/xkbcomp-0.99.1-r1)
[blocks B     ] <x11-base/xorg-x11-7 (is blocking 
x11-misc/xkbdata-0.99.1-r1)
[blocks B     ] <x11-base/xorg-x11-7 (is blocking 
x11-base/xorg-server-0.99.2-r1)
[blocks B     ] <x11-base/xorg-x11-7 (is blocking x11-misc/xbitmaps-0.99.1)
[blocks B     ] <x11-base/xorg-x11-7 (is blocking x11-apps/xauth-0.99.1)
[blocks B     ] <x11-base/xorg-x11-7 (is blocking x11-proto/evieext-1.0.1)
[blocks B     ] <x11-base/xorg-x11-7 (is blocking 
x11-misc/makedepend-0.99.1)
[blocks B     ] <x11-base/xorg-x11-7 (is blocking x11-libs/libXi-0.99.1)
[blocks B     ] <x11-base/xorg-x11-7 (is blocking 
x11-proto/printproto-1.0.1)
[ebuild  N    ] x11-base/xorg-server-0.99.2-r1  -dri -ipv6 -minimal 
-xprint 8,521 kB
[ebuild  N    ]  x11-proto/randrproto-1.1.1  37 kB
[ebuild  N    ]  x11-proto/fixesproto-3.0.1  37 kB
[ebuild  N    ]  x11-apps/xinit-0.99.2-r1  86 kB
[ebuild  N    ]  x11-proto/xf86bigfontproto-1.1.1  36 kB
[ebuild  N    ]  x11-misc/xkbdata-0.99.1-r1  272 kB
[ebuild  N    ]   x11-apps/xkbcomp-0.99.1-r1  171 kB
[ebuild  N    ]  x11-misc/xbitmaps-0.99.1  53 kB
[ebuild  N    ]  x11-apps/xauth-0.99.1  91 kB
[ebuild  N    ]  x11-proto/evieext-1.0.1  36 kB
[ebuild  N    ]  media-libs/mesa-6.3.2-r1  +motif 0 kB
[ebuild  N    ]   x11-misc/makedepend-0.99.1  78 kB
[ebuild  N    ]   x11-libs/libXi-0.99.1  185 kB
[ebuild  N    ]   x11-proto/printproto-1.0.1  42 kB
[ebuild  N    ]   x11-libs/openmotif-2.2.3-r7  5,029 kB
[ebuild  N    ]    x11-base/xorg-x11-6.8.2-r6  -3dfx -3dnow 
+bitmap-fonts -cjk -debug +dlloader -dmx -doc -font-server 
-insecure-drivers -ipv6 -minimal +mmx -nls -nocxx +opengl -pam -sdk +sse 
-static +truetype-fonts +type1-fonts (-uclibc) -xprint +xv 0 kB
[ebuild  N    ]    x11-libs/motif-config-0.9  0 kB
[ebuild  N    ]   x11-libs/libdrm-1.0.4  258 kB
[ebuild  N    ]  x11-libs/libXxf86vm-0.99.1  151 kB
[ebuild  N    ]   x11-proto/xf86vidmodeproto-2.2.1  38 kB
[ebuild  N    ]  x11-proto/glproto-1.4.1  52 kB
[ebuild  N    ]  media-fonts/font-cursor-misc-0.99.0  41 kB
[ebuild  N    ]  x11-libs/libxkbui-0.99.0  184 kB
[ebuild  N    ]   x11-libs/libxkbfile-0.99.1  199 kB
[ebuild  N    ]  media-fonts/font-misc-misc-0.99.0  1,773 kB
[ebuild  N    ]   x11-apps/mkfontdir-0.99.1  58 kB
[ebuild  N    ]   x11-apps/bdftopcf-0.99.1  71 kB
[ebuild  N    ]    x11-libs/libXfont-0.99.1  -bitmap-fonts -cid -ipv6 
-speedo +truetype 527 kB
[ebuild  N    ]     x11-proto/fontcacheproto-0.1.1  37 kB
[ebuild  N    ] media-fonts/font-alias-0.99.0  40 kB
[ebuild  N    ]   media-fonts/font-util-0.99.1  89 kB
[ebuild  N    ]   media-fonts/encodings-0.99.0  598 kB
[ebuild  N    ]   x11-apps/mkfontscale-0.99.1  83 kB
[ebuild  N    ]    x11-libs/libfontenc-0.99.1  153 kB
[ebuild  N    ]  x11-proto/xf86rushproto-1.1.1  36 kB
[ebuild  N    ]  x11-proto/fontsproto-2.0.1  43 kB
[ebuild  N    ]  x11-apps/iceauth-0.99.1  80 kB
[ebuild  N    ]  x11-apps/rgb-0.99.1  83 kB
[ebuild  N    ]  x11-libs/libdmx-0.99.1  153 kB
[ebuild  N    ]  x11-proto/xineramaproto-1.1.1  37 kB
[ebuild  N    ]  x11-libs/libXtst-0.99.1  150 kB
[ebuild  N    ]   x11-proto/recordproto-1.13.1  38 kB
[ebuild  N    ]  x11-proto/scrnsaverproto-1.0.1  37 kB
[ebuild  N    ]  x11-libs/libXaw-0.99.1  -xprint 441 kB
[ebuild  N    ]   x11-libs/libXpm-3.5.3  282 kB
[ebuild  N    ]   x11-libs/libXmu-0.99.1  222 kB
[ebuild  N    ]    x11-libs/libXt-0.99.1  416 kB
[ebuild  N    ]     x11-libs/libSM-0.99.1  164 kB
[ebuild  N    ]      x11-libs/libICE-0.99.0  -ipv6 223 kB
[ebuild  N    ]  x11-proto/videoproto-2.2.1  41 kB
[ebuild  N    ]  x11-proto/xf86dgaproto-2.0.1  38 kB
[ebuild  N    ]  x11-libs/libXres-0.99.1  149 kB
[ebuild  N    ]   x11-proto/resourceproto-1.0.1  35 kB
[ebuild  N    ]  x11-proto/damageproto-1.0.1  36 kB
[ebuild  N    ]  x11-proto/dmxproto-2.2.1  38 kB
[ebuild  N    ]  x11-libs/libXrender-0.9.0  202 kB
[ebuild  N    ]   x11-proto/renderproto-0.9.1  38 kB
[ebuild  N    ]  x11-proto/compositeproto-0.2.1  36 kB
[ebuild  N    ]  x11-proto/trapproto-3.4.1  47 kB
[ebuild  N    ]  x11-libs/libXxf86misc-0.99.1  147 kB
[ebuild  N    ]   x11-proto/xf86miscproto-0.9.1  37 kB
[ebuild  N    ]   x11-libs/libXext-0.99.1  194 kB
[ebuild  N    ]   x11-libs/libX11-0.99.2  -ipv6 1,269 kB
[ebuild  N    ]    x11-libs/xtrans-0.99.1  86 kB
[ebuild  N    ]    x11-proto/xcmiscproto-1.1.1  35 kB
[ebuild  N    ]    x11-libs/libXdmcp-0.99.1  157 kB
[ebuild  N    ]    x11-libs/libXau-0.99.1  154 kB
[ebuild  N    ]    x11-proto/inputproto-1.3.1  44 kB
[ebuild  N    ]    x11-proto/bigreqsproto-1.0.1  35 kB
[ebuild  N    ]    x11-proto/xproto-7.0.1  101 kB
[ebuild  N    ]    x11-proto/xextproto-7.0.1  66 kB
[ebuild  N    ]    x11-proto/kbproto-1.0.1  56 kB
[ebuild  N    ]     x11-misc/util-macros-0.99.1  35 kB

Total size of downloads: 24,538 kB

!!! Error: The above package list contains packages which cannot be 
installed
!!!        on the same system.

--de.

-- 
gentoo-dev@gentoo.org mailing list