Mailing List Archive

1 2  View All
Re: modular X - 7.0 RC1 [ In reply to ]
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
Re: modular X - 7.0 RC1 [ In reply to ]
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: modular X - 7.0 RC1 [ In reply to ]
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: modular X - 7.0 RC1 [ In reply to ]
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
Re: modular X - 7.0 RC1 [ In reply to ]
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: modular X - 7.0 RC1 [ In reply to ]
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
Re: modular X - 7.0 RC1 [ In reply to ]
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: modular X - 7.0 RC1 [ In reply to ]
-----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: modular X - 7.0 RC1 [ In reply to ]
-----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: modular X - 7.0 RC1 [ In reply to ]
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
Re: modular X - 7.0 RC1 [ In reply to ]
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
Re: modular X - 7.0 RC1 [ In reply to ]
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
Re: modular X - 7.0 RC1 [ In reply to ]
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: modular X - 7.0 RC1 [ In reply to ]
-----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: modular X - 7.0 RC1 [ In reply to ]
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
Re: modular X - 7.0 RC1 [ In reply to ]
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: modular X - 7.0 RC1 [ In reply to ]
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: modular X - 7.0 RC1 [ In reply to ]
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

1 2  View All