[gentoo-user] ~amd64 - my experience so far...

[gentoo-user] ~amd64 - my experience so far...

[Mark Knecht]

...is not so good actually. Certainly not the way I'd want others to
experience Gentoo.

OK, the ~amd64 upgrade to @system was easy and relatively painless.
The documents were fairly clear. There are things to learn, and old
friends like rc-update and df look different, but it worked and didn't
take long - less than an hour to reboot including editing - so that's
good.

Unfortunately, simply allowing all environments & apps on the system
to go ~amd64 isn't working out as nicely.

1) xfce4 had one build failure. I masked it and the build finished.
xfce starts and seems to mostly work, but I get no wallpaper and the
right click for a menu on the desktop doesn't work. It's usable, but
clearly 'not stable'.

2) gnome-2.28 simply doesn't build.

3) I'm currently left with lots of things in emerge @preserved-rebuild
that don't build. emerge -DuN @world is not clean.

QUESTION: Assume I'm happy with ~amd64 on @system, but want to build
the stable version of gnome or kde. How do I get it? Since gnome-2.26
worked yesterday I tried masking >=gnome-2.28. emerge -DuN gnome.
Portage then didn't try to emerge the meta-package but doesn't take
all of gnome back to 2.26. There's no point trying kde as gnome pulled
in kde components that doesn't build either. Hopefully it's not 'mask
every package in gnome by hand'.

At this point I'm left with a system that's not clean and to me not
terribly useful. Yesterday as stable I built xfce, gnome and kde in
under 4 hours and all 3 worked. Today both gnome and xfce aren't right
and I don't have kde. Probably this is some matter of learning to hold
back portage that I've never done before, rather than unleashing new
packages like you do on a stable system.

How does one accomplish this?

Thanks,
Mark

Re: [gentoo-user] ~amd64 - my experience so far...

[Alan McKinnon]

Are you merely ranting or asking for help?

If the former, well, OK i Hear you. But I don't care.

If the latter, then you need to provide info like logs, output etc.

~amd64 works like a charm for me here.








On Monday 12 April 2010 13:57:39 Mark Knecht wrote:
> ...is not so good actually. Certainly not the way I'd want others to
> experience Gentoo.
> 
> OK, the ~amd64 upgrade to @system was easy and relatively painless.
> The documents were fairly clear. There are things to learn, and old
> friends like rc-update and df look different, but it worked and didn't
> take long - less than an hour to reboot including editing - so that's
> good.
> 
> Unfortunately, simply allowing all environments & apps on the system
> to go ~amd64 isn't working out as nicely.
> 
> 1) xfce4 had one build failure. I masked it and the build finished.
> xfce starts and seems to mostly work, but I get no wallpaper and the
> right click for a menu on the desktop doesn't work. It's usable, but
> clearly 'not stable'.
> 
> 2) gnome-2.28 simply doesn't build.
> 
> 3) I'm currently left with lots of things in emerge @preserved-rebuild
> that don't build. emerge -DuN @world is not clean.
> 
> QUESTION: Assume I'm happy with ~amd64 on @system, but want to build
> the stable version of gnome or kde. How do I get it? Since gnome-2.26
> worked yesterday I tried masking >=gnome-2.28. emerge -DuN gnome.
> Portage then didn't try to emerge the meta-package but doesn't take
> all of gnome back to 2.26. There's no point trying kde as gnome pulled
> in kde components that doesn't build either. Hopefully it's not 'mask
> every package in gnome by hand'.
> 
> At this point I'm left with a system that's not clean and to me not
> terribly useful. Yesterday as stable I built xfce, gnome and kde in
> under 4 hours and all 3 worked. Today both gnome and xfce aren't right
> and I don't have kde. Probably this is some matter of learning to hold
> back portage that I've never done before, rather than unleashing new
> packages like you do on a stable system.
> 
> How does one accomplish this?
> 
> Thanks,
> Mark

-- 
alan dot mckinnon at gmail dot com

Re: [gentoo-user] ~amd64 - my experience so far...

[Mark Knecht]

On Mon, Apr 12, 2010 at 5:00 AM, Alan McKinnon <alan.mckinnon@gmail.com> wrote:
> Are you merely ranting or asking for help?
>
> If the former, well, OK i Hear you. But I don't care.
>
> If the latter, then you need to provide info like logs, output etc.
>
> ~amd64 works like a charm for me here.
>
>

Neither. I think I asked a simple question. How does one get ~amd64
@system and stable everything else? If the answer is 'you can't' or
'it's immensely hard because you have to -~arch everything by hand'
then I'll just go back to stable, whether it is easy or requires me to
rebuild the system from scratch.

I'm certainly not ranting. I don't think that tone should came across
in what I wrote and if you're reading that in then it's on your end
not mine. (Although I apologize for writing anything that made that
happen!) I have __nothing__ on this system. The hardware is brand new.
It's been said time and time again that running all ~arch on other
people's systems (like yours)  works great and I wanted to try it.
It's certainly not working for me at this point but I'm not upset,
mad, or anything like that. I'm asking a simple question. That's it.
Nothing more.

I am however documenting my experiences for others than come after me
to this question of "to ~amd64 or not ~amd64". Nothing more. It worked
for Alan who is a __very__ experienced and capable person. It didn't
work for Mark (at this point) who is a 10 year Gentoo user but
__nothing__ more than a user type Those people can decide who they are
closer to in capabilities and make their choice a bit more informed.

I didn't wake up this morning thinking I could do what you and Neil
and others on this list can with this distro. I'm not that silly! I
just wanted to try ~amd64 to see what happened. It will take me less
than 90 minutes to get to a new clean install if I blow everything
away and start over. It's not a big deal.

- Mark

Re: [gentoo-user] ~amd64 - my experience so far...

[William Kenworthy]

> I am however documenting my experiences for others than come after me
> to this question of "to ~amd64 or not ~amd64". Nothing more. It worked
> for Alan who is a __very__ experienced and capable person. It didn't
> work for Mark (at this point) who is a 10 year Gentoo user but
> __nothing__ more than a user type Those people can decide who they are
> closer to in capabilities and make their choice a bit more informed.
> 
> I didn't wake up this morning thinking I could do what you and Neil
> and others on this list can with this distro. I'm not that silly! I
> just wanted to try ~amd64 to see what happened. It will take me less
> than 90 minutes to get to a new clean install if I blow everything
> away and start over. It's not a big deal.
> 
> - Mark
> 

Is there a reason why you want to run all @system as ~amd64, and the
rest stable.  To me it makes more sense (especially for production
systems) to run @system as stable and only ~amd64 those apps and
dependencies you want/need to be bleeding edge.

Anyhow, what I really wanted to say is for more sensible unmasking,
check out autounmask:

moriah home # esearch autounmask
[ Results for search key : autounmask ]
[ Applications found : 1 ]

*  app-portage/autounmask
      Latest version available: 0.27
      Latest version installed: [ Not Installed ]
      Size of downloaded files: 3 kB
      Homepage:    http://download.mpsna.de/opensource/autounmask/
      Description: autounmask - Unmasking packages the easy way
      License:     GPL-2


moriah home #

Re: [gentoo-user] ~amd64 - my experience so far...

[Mark Knecht]

On Mon, Apr 12, 2010 at 5:42 AM, William Kenworthy <billk@iinet.net.au> wrote:
>
>> I am however documenting my experiences for others than come after me
>> to this question of "to ~amd64 or not ~amd64". Nothing more. It worked
>> for Alan who is a __very__ experienced and capable person. It didn't
>> work for Mark (at this point) who is a 10 year Gentoo user but
>> __nothing__ more than a user type Those people can decide who they are
>> closer to in capabilities and make their choice a bit more informed.
>>
>> I didn't wake up this morning thinking I could do what you and Neil
>> and others on this list can with this distro. I'm not that silly! I
>> just wanted to try ~amd64 to see what happened. It will take me less
>> than 90 minutes to get to a new clean install if I blow everything
>> away and start over. It's not a big deal.
>>
>> - Mark
>>
>
> Is there a reason why you want to run all @system as ~amd64, and the
> rest stable.  To me it makes more sense (especially for production
> systems) to run @system as stable and only ~amd64 those apps and
> dependencies you want/need to be bleeding edge.
>
> Anyhow, what I really wanted to say is for more sensible unmasking,
> check out autounmask:
>
> moriah home # esearch autounmask
> [ Results for search key : autounmask ]
> [ Applications found : 1 ]
>
> *  app-portage/autounmask
>      Latest version available: 0.27
>      Latest version installed: [ Not Installed ]
>      Size of downloaded files: 3 kB
>      Homepage:    http://download.mpsna.de/opensource/autounmask/
>      Description: autounmask - Unmasking packages the easy way
>      License:     GPL-2
>
>
> moriah home #
>

William,
   In general I agree logically. There was no _strong_ reason for me
to run ~arch on anything. I just wanted to try it out since the
machine was new and this was a good time to get the experience vs
having lots of stuff on the machine and trying to switch later.

   ~arch @system was mainly to get a jump on the OpenRC migration
before I had so much stuff on the system that I couldn't afford to
just reformat and start over if I had problems with it. Having done it
once I now know it won't be difficult later when it moves to stable.

   ~arch xfce/gnome/kde on the other hand is not something I needed.
It just comes with ~arch and for me didn't work so well. For me the
desktop environment is mostly just a platform to get a browser or
VMWare up and running. kde and it's brethren move forward but the
revision level changes hardly impact me in normal life.

   Again, based on Alan's response, this isn't about me being upset or
anything like that. I'm not upset in the least. Just trying things
out.

Thanks,
Mark

[gentoo-user] Re: ~amd64 - my experience so far...

[Kerin Millar]

On 12/04/2010 13:42, William Kenworthy wrote:
> Is there a reason why you want to run all @system as ~amd64, and the
> rest stable.  To me it makes more sense (especially for production

Perhaps he simply doesn't feel like re-installing. By going down this 
road, the breakage caused by dowgrading system packages - glibc in 
particular - can be avoided.

Chhers,

--Kerin

Re: [gentoo-user] ~amd64 - my experience so far...

[Alan McKinnon]

On Monday 12 April 2010 14:29:00 Mark Knecht wrote:
> On Mon, Apr 12, 2010 at 5:00 AM, Alan McKinnon <alan.mckinnon@gmail.com> 
wrote:
> > Are you merely ranting or asking for help?
> > 
> > If the former, well, OK i Hear you. But I don't care.
> > 
> > If the latter, then you need to provide info like logs, output etc.
> > 
> > ~amd64 works like a charm for me here.
> 
> Neither. I think I asked a simple question. How does one get ~amd64
> @system and stable everything else? If the answer is 'you can't' or
> 'it's immensely hard because you have to -~arch everything by hand'
> then I'll just go back to stable, whether it is easy or requires me to
> rebuild the system from scratch.

You can't do that easily, and it certainly is not advisable.

The only way I can think of would be to put every package in @system into 
package.keywords and leave ACCEPT_KEYWORDS at arch. This will cause problems:

1. stable is just that: stable. By and large the full stable set is known to 
work

2. when devs commit to ~arch, they tend to run ~arch on their test boxes. 
Issues are easy to spot and get fixed quickly. If you have a mixture of the 
two, then you have a combination that no-one but you is using, and it will not 
have been tested. The odds are good that you will often run into problems that 
are hard to trace (conflicting versions of packages). Running ~arch is 
actually more stable than a mixture as many folk have those packages and there 
are more eyeballs on it.



> 
> I'm certainly not ranting. I don't think that tone should came across
> in what I wrote and if you're reading that in then it's on your end
> not mine. (Although I apologize for writing anything that made that
> happen!) I have __nothing__ on this system. The hardware is brand new.
> It's been said time and time again that running all ~arch on other
> people's systems (like yours)  works great and I wanted to try it.
> It's certainly not working for me at this point but I'm not upset,
> mad, or anything like that. I'm asking a simple question. That's it.
> Nothing more.
> 
> I am however documenting my experiences for others than come after me
> to this question of "to ~amd64 or not ~amd64". Nothing more. It worked
> for Alan who is a __very__ experienced and capable person. It didn't
> work for Mark (at this point) who is a 10 year Gentoo user but
> __nothing__ more than a user type Those people can decide who they are
> closer to in capabilities and make their choice a bit more informed.
> 
> I didn't wake up this morning thinking I could do what you and Neil
> and others on this list can with this distro. I'm not that silly! I
> just wanted to try ~amd64 to see what happened. It will take me less
> than 90 minutes to get to a new clean install if I blow everything
> away and start over. It's not a big deal.

Considering the kind of software you use, I'd advise you to just run ~amd64 
and be done with it. Your usage-profile is of someone who needs recent 
features. I would only go back to amd64 if some genuine show-stopper blockage 
pops up, or if the packages you use are updated often (and usually with brand 
new shiny bugs - enlightenment is a lot like that which is why I had to stop 
using it)




-- 
alan dot mckinnon at gmail dot com

Re: [gentoo-user] ~amd64 - my experience so far...

[KH]

Am 12.04.2010 14:57, schrieb Alan McKinnon:
[...]
>
> 2. when devs commit to ~arch, they tend to run ~arch on their test boxes.
> Issues are easy to spot and get fixed quickly. If you have a mixture of the
> two, then you have a combination that no-one but you is using, and it will not
> have been tested. The odds are good that you will often run into problems that
> are hard to trace (conflicting versions of packages). Running ~arch is
> actually more stable than a mixture as many folk have those packages and there
> are more eyeballs on it.
>
>

Hi,

someone always brings that up. I think it might be right when mixing 
packages randomly. But not everybody is doing that.
Let's say: I only like to have personas for firefox. Unmasking firefox, 
xulrunner, nss and two more will not bring you in the problem mentioned.
In general I believe this is true for any program as long as it doesn't 
need a general library or anything like that unmasked.

kh

Re: [gentoo-user] ~amd64 - my experience so far...

[Alan McKinnon]

On Monday 12 April 2010 18:33:21 KH wrote:
> Am 12.04.2010 14:57, schrieb Alan McKinnon:
> [...]
> 
> > 2. when devs commit to ~arch, they tend to run ~arch on their test boxes.
> > Issues are easy to spot and get fixed quickly. If you have a mixture of
> > the two, then you have a combination that no-one but you is using, and
> > it will not have been tested. The odds are good that you will often run
> > into problems that are hard to trace (conflicting versions of packages).
> > Running ~arch is actually more stable than a mixture as many folk have
> > those packages and there are more eyeballs on it.
> 
> Hi,
> 
> someone always brings that up. I think it might be right when mixing
> packages randomly. But not everybody is doing that.
> Let's say: I only like to have personas for firefox. Unmasking firefox,
> xulrunner, nss and two more will not bring you in the problem mentioned.
> In general I believe this is true for any program as long as it doesn't
> need a general library or anything like that unmasked.

What you say is true enough - I usually recommend folks unmask portage as well 
to get the automated blocker resolving featurs and sets. 

But it usually doesn't end there. Once users have a recent Firefox, they 
probably eventually unmask gnome as well, openrc, etc, etc and before you know 
it, you have a mess.

So, in the rare case of a user who can discipline himself to say within the 
limits you describe, your advice is fine. But that's a theoretical situation 
:-) and the real one is quite different in my experience.



-- 
alan dot mckinnon at gmail dot com

Re: [gentoo-user] ~amd64 - my experience so far...

[William Kenworthy]

On Tue, 2010-04-13 at 09:09 +0200, Alan McKinnon wrote:
> On Monday 12 April 2010 18:33:21 KH wrote:
> > Am 12.04.2010 14:57, schrieb Alan McKinnon:
> > 
> 
> So, in the rare case of a user who can discipline himself to say within the 
> limits you describe, your advice is fine. But that's a theoretical situation 
> :-) and the real one is quite different in my experience.
> 
> 

This is exactly how I manage a number of gentoo systems - only unmasking
versions I need.  Ive actually never done a ~ system :)

However, on the other side of the coin is the fact I have also never run
a completely stable system either because I have never been able to get
the task done a system was built for without at least a few unstable
packages.  For an extreme example, remember when X was masked for some
security problem leaving stable with no X windows system (think it was
back in the xfree86 days).  You will quite often find that when trying
to build even a basic system, you have to keyword a few packages or you
get nowhere.  And if its a complex 1000 pkg plus system, you are
definitely going to have problems.

One hint I can give for long term stability is to try and specify
versions (either with = or ~) rather than just an open keywording.
Otherwise it gets out of hand with many unmasked packages needed and
needing maintaining on upgrades.

BillK

Re: [gentoo-user] ~amd64 - my experience so far...

[Mark Knecht]

On Tue, Apr 13, 2010 at 12:30 AM, William Kenworthy <billk@iinet.net.au> wrote:
> On Tue, 2010-04-13 at 09:09 +0200, Alan McKinnon wrote:
>> On Monday 12 April 2010 18:33:21 KH wrote:
>> > Am 12.04.2010 14:57, schrieb Alan McKinnon:
>> >
>>
>> So, in the rare case of a user who can discipline himself to say within the
>> limits you describe, your advice is fine. But that's a theoretical situation
>> :-) and the real one is quite different in my experience.
>>
>>
>
> This is exactly how I manage a number of gentoo systems - only unmasking
> versions I need.  Ive actually never done a ~ system :)
>

It's an experience. Like you in the past I've keyworded what I needed
and it's worked great for 10 years.

OK, so I've been pushing forward and finally I'm emerge -e @world
clean. xfce still doesn't work right. It's in fact pretty unusable at
the moment as it has no menus at all, but it's only a backup
environment so I'm going to ignore that for the moment and build KDE
which should be done in about 2 hours.

Notes about what I think happened here:
1) I missed the message about running perl-cleaner so I had to do that.
2) I had a gcc build that didn't allow the profile to get set so
emerge -1 gcc fixed that.
3) After that I tried emerge -e @system, emerge -e @world which failed
with more perl issues, but the same package seemed to be part of
@system and emerge -e @system was clean. A second pass at emerge -e
@world failed the same way. Thinking back to the old days, and I know
folks have negative opinions about this, I did emerge -e @system TWICE
in a row, and then emerge -e @world worked. Go figure.

I'm going to finish KDE and see if it works. If it does then cool,
I'll stick with ~amd64. If not I'm deleting the partitions and
starting over with stable. I've invested a day and a half in this
experiment and my results are not leaving me comfortable. I need to
the machine to work so I can use it starting this afternoon.

Thanks,
Mark

Cheers,
Mark

Re: [gentoo-user] ~amd64 - my experience so far...

[Paul Hartman]

On Tue, Apr 13, 2010 at 7:40 AM, Mark Knecht <markknecht@gmail.com> wrote:
> Notes about what I think happened here:
> 1) I missed the message about running perl-cleaner so I had to do that.
> 2) I had a gcc build that didn't allow the profile to get set so
> emerge -1 gcc fixed that.
> 3) After that I tried emerge -e @system, emerge -e @world which failed
> with more perl issues, but the same package seemed to be part of
> @system and emerge -e @system was clean. A second pass at emerge -e
> @world failed the same way. Thinking back to the old days, and I know
> folks have negative opinions about this, I did emerge -e @system TWICE
> in a row, and then emerge -e @world worked. Go figure.
>
> I'm going to finish KDE and see if it works. If it does then cool,
> I'll stick with ~amd64. If not I'm deleting the partitions and
> starting over with stable. I've invested a day and a half in this
> experiment and my results are not leaving me comfortable. I need to
> the machine to work so I can use it starting this afternoon.

I think you've gotten through the hard part and it should hopefully
work well from here. The gcc-config thing I have run into before after
a new gcc version (unrelated to migrating from amd64 to ~amd64), but I
don't think the ebuild tells you to do that...

Re: [gentoo-user] ~amd64 - my experience so far...

[Mark Knecht]

On Tue, Apr 13, 2010 at 8:12 AM, Paul Hartman
<paul.hartman+gentoo@gmail.com> wrote:
> On Tue, Apr 13, 2010 at 7:40 AM, Mark Knecht <markknecht@gmail.com> wrote:
>> Notes about what I think happened here:
>> 1) I missed the message about running perl-cleaner so I had to do that.
>> 2) I had a gcc build that didn't allow the profile to get set so
>> emerge -1 gcc fixed that.
>> 3) After that I tried emerge -e @system, emerge -e @world which failed
>> with more perl issues, but the same package seemed to be part of
>> @system and emerge -e @system was clean. A second pass at emerge -e
>> @world failed the same way. Thinking back to the old days, and I know
>> folks have negative opinions about this, I did emerge -e @system TWICE
>> in a row, and then emerge -e @world worked. Go figure.
>>
>> I'm going to finish KDE and see if it works. If it does then cool,
>> I'll stick with ~amd64. If not I'm deleting the partitions and
>> starting over with stable. I've invested a day and a half in this
>> experiment and my results are not leaving me comfortable. I need to
>> the machine to work so I can use it starting this afternoon.
>
> I think you've gotten through the hard part and it should hopefully
> work well from here. The gcc-config thing I have run into before after
> a new gcc version (unrelated to migrating from amd64 to ~amd64), but I
> don't think the ebuild tells you to do that...

Hi Paul,
   The KDE install completed although it did quit in the middle saying
a 'make failed!'. I restarted the emerge and it finished clean the
second time. The machine is now emerge -DuN @world clean and I'm
writing you from within KDE. So good so far.

   One minor annoyance is that the task bar at the bottom is about 1/3
black on the left. Resolution is 1920x1080 so I'd guess about the
first 800 pixels are painted the wrong color. The task bar still
works, it just doesn't look right.

   This install is now running xorg-server-1.8 with all the latest
drivers, but there was an announcement last night on LKML about
2.6.34_rc4 which had a number of ati driver improvements so I'll have
to wait for someone to update vanilla-sources to support that. I'm
currently running vanilla-2.6.34_rc3. I don't really want to deal with
git-sources unless I need to. Comments?

   As this is a very usable environment I'll stick with it for now.
However in parallel I'm doing to do a stable build on another
partition of my RAID just in case I need to fall back to stable for
some reason.

   Thanks for your help, as well as everyone else.

Cheers,
Mark

Re: [gentoo-user] ~amd64 - my experience so far...

[Alex Schuster]

Mark Knecht writes:

>    One minor annoyance is that the task bar at the bottom is about 1/3
> black on the left. Resolution is 1920x1080 so I'd guess about the
> first 800 pixels are painted the wrong color. The task bar still
> works, it just doesn't look right.

I think I have the same problem, although not all the time. I happens only 
sometimes after I run opengl Software like Quake3, or other games that 
change the graphics resolution. What sometimes works is to turn off 
compositing with Alt-Shift-F12 and on again.

	Wonko

Re: [gentoo-user] ~amd64 - my experience so far...

[Mark Knecht]

On Tue, Apr 13, 2010 at 10:34 AM, Alex Schuster <wonko@wonkology.org> wrote:
> Mark Knecht writes:
>
>>    One minor annoyance is that the task bar at the bottom is about 1/3
>> black on the left. Resolution is 1920x1080 so I'd guess about the
>> first 800 pixels are painted the wrong color. The task bar still
>> works, it just doesn't look right.
>
> I think I have the same problem, although not all the time. I happens only
> sometimes after I run opengl Software like Quake3, or other games that
> change the graphics resolution. What sometimes works is to turn off
> compositing with Alt-Shift-F12 and on again.
>
>        Wonko

Thanks. Seems I have this all the time in ~amd64. I didn't see it on
(mostly) stable. (Stable system, stable KDE, mostly stable apps,
~amd64 xorg-server & drivers) Alt-Shift-F12 isn't doing anything for
me.

In a few hours I'll have a second (and stable) install on the same
system so I can boot into each and compare results. Until then at
least ~amd64 is working well enough that I can do a little work. I'll
report back when I know anything new.

Again, thanks for the ideas.

Cheers,
Mark

Re: [gentoo-user] ~amd64 - my experience so far...

[Paul Hartman]

On Tue, Apr 13, 2010 at 7:40 AM, Mark Knecht <markknecht@gmail.com> wrote:
> OK, so I've been pushing forward and finally I'm emerge -e @world
> clean. xfce still doesn't work right. It's in fact pretty unusable at
> the moment as it has no menus at all, but it's only a backup
> environment so I'm going to ignore that for the moment and build KDE
> which should be done in about 2 hours.

Double-check that xfce-base/xfdesktop package has the menu-plugin USE
flag set (and also double-check that xfdesktop is running at all when
you're logged into xfce). Run xfconf, maybe it needs to generate the
configuration files, or try creating a new user and logging in as that
to see if it's just your user's xfce config that is wacky for some
reason. :)

Re: [gentoo-user] ~amd64 - my experience so far...

[Neil Bothwick]

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

On Mon, 12 Apr 2010 05:29:00 -0700, Mark Knecht wrote:

> It's certainly not working for me at this point but I'm not upset,
> mad, or anything like that. I'm asking a simple question. That's it.

Except you didn't really ask a question, at least not in  manner that
could be answered. Posting the output of the failures would make it a
question that could be answered. While you are getting multiple failures,
there may only be one or two problems, fix those and everything should
fall into place.


-- 
Neil Bothwick

I'm not anti-social, I'm just not user friendly

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

Re: [gentoo-user] ~amd64 - my experience so far...

[Zeerak Mustafa Waseem]

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

On Mon, Apr 12, 2010 at 04:57:39AM -0700, Mark Knecht wrote:
> ...is not so good actually. Certainly not the way I'd want others to
> experience Gentoo.
> 
> OK, the ~amd64 upgrade to @system was easy and relatively painless.
> The documents were fairly clear. There are things to learn, and old
> friends like rc-update and df look different, but it worked and didn't
> take long - less than an hour to reboot including editing - so that's
> good.
> 
> Unfortunately, simply allowing all environments & apps on the system
> to go ~amd64 isn't working out as nicely.
> 
> 1) xfce4 had one build failure. I masked it and the build finished.
> xfce starts and seems to mostly work, but I get no wallpaper and the
> right click for a menu on the desktop doesn't work. It's usable, but
> clearly 'not stable'.
> 

Are there any bugs on this? Perhaps it's a configurations thing :-)

> 2) gnome-2.28 simply doesn't build.
> 

Attatch the log? I doubt I can help you, but I'm pretty sure someone else on the list will be able to :-)

> 3) I'm currently left with lots of things in emerge @preserved-rebuild
> that don't build. emerge -DuN @world is not clean.
> 

it isn't? The way I see it, it's every bit as clean as emerge -DuN world, the difference is that now there's a set to take care of what revdep-rebuild did. I could be mistaken then ;)

> QUESTION: Assume I'm happy with ~amd64 on @system, but want to build
> the stable version of gnome or kde. How do I get it? Since gnome-2.26
> worked yesterday I tried masking >=gnome-2.28. emerge -DuN gnome.
> Portage then didn't try to emerge the meta-package but doesn't take
> all of gnome back to 2.26. There's no point trying kde as gnome pulled
> in kde components that doesn't build either. Hopefully it's not 'mask
> every package in gnome by hand'.
>

The way to hold packages back would be adding foo/bar -~arch to your package.keywords file. That way portage will only look at the stable packages. It's tedious to do it by hand (and I don't know any automated process), but if most of your system will be running ~arch then I'd suggest that you stay ~arch, and vice versa if most of the system is running arch.
 
> At this point I'm left with a system that's not clean and to me not
> terribly useful. Yesterday as stable I built xfce, gnome and kde in
> under 4 hours and all 3 worked. Today both gnome and xfce aren't right
> and I don't have kde. Probably this is some matter of learning to hold
> back portage that I've never done before, rather than unleashing new
> packages like you do on a stable system.
> 
> How does one accomplish this?
> 
> Thanks,
> Mark
> 

Hope it helps :-)

-- 
Zeerak Waseem

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

Re: [gentoo-user] ~amd64 - my experience so far...

[Mark Knecht]

On Mon, Apr 12, 2010 at 5:14 AM, Zeerak Mustafa Waseem
<zeerak.w@gmail.com> wrote:
> On Mon, Apr 12, 2010 at 04:57:39AM -0700, Mark Knecht wrote:
>> ...is not so good actually. Certainly not the way I'd want others to
>> experience Gentoo.
>>
>> OK, the ~amd64 upgrade to @system was easy and relatively painless.
>> The documents were fairly clear. There are things to learn, and old
>> friends like rc-update and df look different, but it worked and didn't
>> take long - less than an hour to reboot including editing - so that's
>> good.
>>
>> Unfortunately, simply allowing all environments & apps on the system
>> to go ~amd64 isn't working out as nicely.
>>
>> 1) xfce4 had one build failure. I masked it and the build finished.
>> xfce starts and seems to mostly work, but I get no wallpaper and the
>> right click for a menu on the desktop doesn't work. It's usable, but
>> clearly 'not stable'.
>>
>
> Are there any bugs on this? Perhaps it's a configurations thing :-)

Between xfce4 & gnome I've seen about a dozen packages fail to build
this morning and haven't yet checked bug reports. I suspect that many
or more kde packages would get added to the list if I tried ~amd64
kde. I'm sure you're possibly right about it being a 'configuration
thing'.

<SNIP>
>
>> QUESTION: Assume I'm happy with ~amd64 on @system, but want to build
>> the stable version of gnome or kde. How do I get it? Since gnome-2.26
>> worked yesterday I tried masking >=gnome-2.28. emerge -DuN gnome.
>> Portage then didn't try to emerge the meta-package but doesn't take
>> all of gnome back to 2.26. There's no point trying kde as gnome pulled
>> in kde components that doesn't build either. Hopefully it's not 'mask
>> every package in gnome by hand'.
>>
>
> The way to hold packages back would be adding foo/bar -~arch to your package.keywords file. That way portage will only look at the stable packages. It's tedious to do it by hand (and I don't know any automated process), but if most of your system will be running ~arch then I'd suggest that you stay ~arch, and vice versa if most of the system is running arch.

Thanks. The -~arch thing is what I was looking for info wise. However
doing that to all of gnome or kde's packages is too much work.

<SNIP>
>
> Hope it helps :-)
>
> --
> Zeerak Waseem
>

It does, very much! Thanks!

Cheers,
Mark

[gentoo-user] Re: ~amd64 - my experience so far...

[walt]

On 04/12/2010 05:35 AM, Mark Knecht wrote:

> Between xfce4&  gnome I've seen about a dozen packages fail to build
> this morning and haven't yet checked bug reports.

Let's start with xfce4 then because it's much smaller than gnome. What
fails to build, and with what errors?

I actually use gnome, so I could probably give you more help with that.
I haven't seen any build failures on my ~amd64 machine lately, so there
must be a fairly basic problem on your machine if you are seeing that
many build failures.  Some specific error messages would help, though.

Re: [gentoo-user] Re: ~amd64 - my experience so far...

[Mark Knecht]

On Mon, Apr 12, 2010 at 6:07 AM, walt <w41ter@gmail.com> wrote:
> On 04/12/2010 05:35 AM, Mark Knecht wrote:
>
>> Between xfce4&  gnome I've seen about a dozen packages fail to build
>> this morning and haven't yet checked bug reports.
>
> Let's start with xfce4 then because it's much smaller than gnome. What
> fails to build, and with what errors?
>
> I actually use gnome, so I could probably give you more help with that.
> I haven't seen any build failures on my ~amd64 machine lately, so there
> must be a fairly basic problem on your machine if you are seeing that
> many build failures.  Some specific error messages would help, though.
>

OK, let's start with xfce4-meta because there was only one failure.
eix-update was done this morning and emerge -DuN @system is clean
using ~arch in make.conf. I'll paste make.conf & emerge --info at the
end of this message

cruncher ~ # emerge -pvDuN @system

These are the packages that would be merged, in order:

Calculating dependencies... done!

Total: 0 packages, Size of downloads: 0 kB
cruncher ~ #

cruncher ~ # emerge -pvDuN xfce4-meta

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild     U ] dev-perl/glib-perl-1.222 [1.200] 0 kB
[ebuild  N    ] xfce-base/xfce4-meta-4.6.1  USE="session -minimal" 0 kB

Total: 2 packages (1 upgrade, 1 new), Size of downloads: 0 kB
cruncher ~ #

cruncher ~ # emerge -DuN xfce4-meta
Calculating dependencies... done!

>>> Verifying ebuild manifests

>>> Starting parallel fetch

>>> Emerging (1 of 2) dev-perl/glib-perl-1.222
 * Glib-1.222.tar.gz RMD160 SHA1 SHA256 size ;-) ...
                       [ ok ]
 * checking ebuild checksums ;-) ...
                       [ ok ]
 * checking auxfile checksums ;-) ...
                       [ ok ]
 * checking miscfile checksums ;-) ...
                       [ ok ]
 * CPV:  dev-perl/glib-perl-1.222
 * REPO: gentoo
 * USE:  amd64 elibc_glibc kernel_linux multilib userland_GNU
>>> Unpacking source...
>>> Unpacking Glib-1.222.tar.gz to /var/tmp/portage/dev-perl/glib-perl-1.222/work
>>> Source unpacked in /var/tmp/portage/dev-perl/glib-perl-1.222/work
>>> Preparing source in /var/tmp/portage/dev-perl/glib-perl-1.222/work/Glib-1.222 ...
>>> Source prepared.
>>> Configuring source in /var/tmp/portage/dev-perl/glib-perl-1.222/work/Glib-1.222 ...
 * Using ExtUtils::MakeMaker
Can't locate ExtUtils/Depends.pm in @INC (@INC contains:
/usr/lib64/perl5/site_perl/5.10.1/x86_64-linux
/usr/lib64/perl5/site_perl/5.10.1 /usr/lib64/perl5/site_perl
/usr/lib64/perl5/vendor_perl/5.10.1/x86_64-linux
/usr/lib64/perl5/vendor_perl/5.10.1 /usr/lib64/perl5/vendor_perl
/usr/lib64/perl5/5.10.1/x86_64-linux /usr/lib64/perl5/5.10.1 .) at
(eval 6) line 1.
BEGIN failed--compilation aborted at (eval 6) line 1.

Checking if your kit is complete...
Looks good
MakeMaker FATAL: prerequisites not found.
    ExtUtils::Depends not installed

Please install these modules first and rerun 'perl Makefile.PL'.
 * ERROR: dev-perl/glib-perl-1.222 failed:
 *   Unable to build! (are you using USE="build"?)
 *
 * Call stack:
 *     ebuild.sh, line   48:  Called src_configure
 *   environment, line 2616:  Called perl-module_src_configure
 *   environment, line 2362:  Called perl-module_src_prep
 *   environment, line 2423:  Called die
 * The specific snippet of code:
 *               perl Makefile.PL PREFIX=/usr INSTALLDIRS=vendor
INSTALLMAN3DIR='none' DESTDIR="${D}" ${myconf} <<< "${pm_echovar}" ||
die "Unable to build! (are you using USE=\"build\"?)";
 *
 * If you need support, post the output of 'emerge --info
=dev-perl/glib-perl-1.222',
 * the complete build log and the output of 'emerge -pqv
=dev-perl/glib-perl-1.222'.
 * The complete build log is located at
'/var/tmp/portage/dev-perl/glib-perl-1.222/temp/build.log'.
 * The ebuild environment file is located at
'/var/tmp/portage/dev-perl/glib-perl-1.222/temp/environment'.
 * S: '/var/tmp/portage/dev-perl/glib-perl-1.222/work/Glib-1.222'

>>> Failed to emerge dev-perl/glib-perl-1.222, Log file:

>>>  '/var/tmp/portage/dev-perl/glib-perl-1.222/temp/build.log'


That failure is not unlike many others I saw emerging other things.
Maybe we can find the error of my ways and I can move forward.

BTW - The -cups -java flags doesn't mean I don't want cups and java. I
found previously that putting those flags on the individual packages
that I wanted cups and java support reduced the number of packages
emerged during emerge -e @system and meant I could update @system more
often and faster, and then work on @world at more quiet times. It did
not change the number of packages emerged, just whether they were
called in during @system or @world.

Thanks,
Mark


make.conf:

# Please consult /usr/share/portage/config/make.conf.example for a more
# detailed example.
CFLAGS="-O2 -march=native -pipe"
#Safe CFlags for the Core-i7 (web info) saved for reference
#CFLAGS="-march=core2 -msse4 -mcx16 -msahf -O2 -pipe"
CXXFLAGS="${CFLAGS}"
# WARNING: Changing your CHOST is not something that should be done lightly.
# Please consult http://www.gentoo.org/doc/en/change-chost.xml before changing.
CHOST="x86_64-pc-linux-gnu"
# These are the USE flags that were used in addition to what is provided by the
# profile used for building.
FEATURES="buildpkg parallel-fetch userfetch"
USE="aac alsa cairo caps cdda cddb cdparanoia cdr dts dvd dvdr ffmpeg
flac fltk ftp gnome hal ieee1394 kde lame jpeg ladspa lame lash
libsamplerate mmx mp3 mp4 mpeg musepack nsplugin ogg semantic-desktop
sse sse2 ssse3 sse4 tifftruetype vorbis xine xv xvid vmware -bluetooth
-esound -timidity -cups -java -gdbmi X consolekit gtk qt3support png"
MAKEOPTS="-j13"
GENTOO_MIRRORS="http://gentoo.osuosl.org/ "
SYNC="rsync://rsync.namerica.gentoo.org/gentoo-portage"
EMERGE_DEFAULT_OPTS="--with-bdeps y"
INPUT_DEVICES="evdev"
VIDEO_CARDS="radeon fbdev"
ALSA_CARDS="intel-hda"
LINGUAS="en"
ACCEPT_LICENSE="dlj-1.1 PUEL"
ACCEPT_KEYWORDS="~amd64


cruncher ~ # emerge --info
Portage 2.2_rc67 (default/linux/amd64/10.0/desktop, gcc-4.3.4,
glibc-2.11-r1, 2.6.34-rc3 x86_64)
=================================================================
System uname: Linux-2.6.34-rc3-x86_64-Intel-R-_Core-TM-_i7_CPU_X_980_@_3.33GHz-with-gentoo-2.0.1
Timestamp of tree: Mon, 12 Apr 2010 10:45:01 +0000
app-shells/bash:     4.1_p5
dev-java/java-config: 2.1.10
dev-lang/python:     2.6.5-r1, 3.1.2-r2
dev-util/cmake:      2.8.1
sys-apps/baselayout: 2.0.1
sys-apps/openrc:     0.6.1-r1
sys-apps/sandbox:    2.2
sys-devel/autoconf:  2.13, 2.65
sys-devel/automake:  1.8.5-r4, 1.9.6-r3, 1.10.3, 1.11.1
sys-devel/binutils:  2.20.1
sys-devel/gcc:       4.3.4, 4.4.3
sys-devel/gcc-config: 1.4.1
sys-devel/libtool:   2.2.6b
virtual/os-headers:  2.6.33
ACCEPT_KEYWORDS="amd64 ~amd64"
ACCEPT_LICENSE="* -@EULA dlj-1.1 PUEL"
CBUILD="x86_64-pc-linux-gnu"
CFLAGS="-O2 -march=native -pipe"
CHOST="x86_64-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/share/X11/xkb /usr/share/config"
CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d
/etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release
/etc/revdep-rebuild /etc/sandbox.d /etc/terminfo"
CXXFLAGS="-O2 -march=native -pipe"
DISTDIR="/usr/portage/distfiles"
EMERGE_DEFAULT_OPTS="--with-bdeps y"
FEATURES="assume-digests buildpkg distlocks fixpackages news
parallel-fetch preserve-libs protect-owned sandbox sfperms strict
unmerge-logs unmerge-orphans userfetch"
GENTOO_MIRRORS="http://gentoo.osuosl.org/ "
LDFLAGS="-Wl,-O1"
LINGUAS="en"
MAKEOPTS="-j13"
PKGDIR="/usr/portage/packages"
PORTAGE_CONFIGROOT="/"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times
--compress --force --whole-file --delete --stats --timeout=180
--exclude=/distfiles --exclude=/local --exclude=/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
SYNC="rsync://rsync.namerica.gentoo.org/gentoo-portage"
USE="X a52 aac acl acpi alsa amd64 berkdb branding bzip2 cairo caps
cdda cddb cdparanoia cdr cli consolekit cracklib crypt cxx dbus dri
dts dvd dvdr emboss encode exif fam ffmpeg firefox flac fltk fortran
ftp gdbm gif gnome gpm gtk hal iconv ieee1394 ipv6 jpeg kde ladspa
lame lash lcms ldap libnotify libsamplerate mad mikmod mmx mng modules
mp3 mp4 mpeg mudflap multilib musepack ncurses nls nptl nptlonly
nsplugin ogg opengl openmp pam pango pcre pdf perl png ppds pppd
python qt3support qt4 readline reflection sdl semantic-desktop session
spell spl sse sse2 sse4 ssl ssse3 startup-notification svg sysfs tcpd
tiff tifftruetype truetype unicode usb vmware vorbis x264 xcb xine xml
xorg xulrunner xv xvid zlib" ALSA_CARDS="intel-hda"
ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty
extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul
mulaw multi null plug rate route share shm softvol"
APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon
authn_dbm authn_default authn_file authz_dbm authz_default
authz_groupfile authz_host authz_owner authz_user autoindex cache dav
dav_fs dav_lock deflate dir disk_cache env expires ext_filter
file_cache filter headers include info log_config logio mem_cache mime
mime_magic negotiation rewrite setenvif speling status unique_id
userdir usertrack vhost_alias" ELIBC="glibc" INPUT_DEVICES="evdev"
KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216
lcdm001 mtxorb ncurses text" LINGUAS="en" RUBY_TARGETS="ruby18"
USERLAND="GNU" VIDEO_CARDS="radeon fbdev"
Unset:  CPPFLAGS, CTARGET, FFLAGS, INSTALL_MASK, LANG, LC_ALL,
PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS,
PORTDIR_OVERLAY

cruncher ~ #

Re: [gentoo-user] Re: ~amd64 - my experience so far...

[Paul Hartman]

On Mon, Apr 12, 2010 at 1:44 PM, Mark Knecht <markknecht@gmail.com> wrote:
> Checking if your kit is complete...
> Looks good
> MakeMaker FATAL: prerequisites not found.
>    ExtUtils::Depends not installed

If part of your transition was upgrading from perl 5.8 to 5.10 you
need to run perl-cleaner like the ewarn says in the perl ebuild. If
you didn't do that yet then maybe that's the cause.

/usr/sbin/perl-cleaner --all

Otherwise if you've already done that, I would try unmerging and
emerging the following packages (if they are installed):

Archive-Tar
Digest-SHA
CPAN
CPANPLUS
Encode
ExtUtils-MakeMaker
Module-Build
Module-CoreList
PodParser
Test-Harness
podlators

Re: [gentoo-user] Re: ~amd64 - my experience so far...

[Paul Hartman]

On Mon, Apr 12, 2010 at 1:57 PM, Paul Hartman
<paul.hartman+gentoo@gmail.com> wrote:
> On Mon, Apr 12, 2010 at 1:44 PM, Mark Knecht <markknecht@gmail.com> wrote:
>> Checking if your kit is complete...
>> Looks good
>> MakeMaker FATAL: prerequisites not found.
>>    ExtUtils::Depends not installed
>
> If part of your transition was upgrading from perl 5.8 to 5.10 you
> need to run perl-cleaner like the ewarn says in the perl ebuild. If
> you didn't do that yet then maybe that's the cause.
>
> /usr/sbin/perl-cleaner --all
>
> Otherwise if you've already done that, I would try unmerging and
> emerging the following packages (if they are installed):
>
> Archive-Tar
> Digest-SHA
> CPAN
> CPANPLUS
> Encode
> ExtUtils-MakeMaker
> Module-Build
> Module-CoreList
> PodParser
> Test-Harness
> podlators

Oops, sorry, those are module names not package names.

Re: [gentoo-user] Re: ~amd64 - my experience so far...

[Mark Knecht]

On Mon, Apr 12, 2010 at 11:57 AM, Paul Hartman
<paul.hartman+gentoo@gmail.com> wrote:
> On Mon, Apr 12, 2010 at 1:44 PM, Mark Knecht <markknecht@gmail.com> wrote:
>> Checking if your kit is complete...
>> Looks good
>> MakeMaker FATAL: prerequisites not found.
>>    ExtUtils::Depends not installed
>
> If part of your transition was upgrading from perl 5.8 to 5.10 you
> need to run perl-cleaner like the ewarn says in the perl ebuild. If
> you didn't do that yet then maybe that's the cause.
>
> /usr/sbin/perl-cleaner --all
>

OK, it appears that this was part of the issue. Don't know how I
missed the warning other than there were a number of things and it
must have been in there somewhere. This allowed me to do  emerge -C
kde xfce4-meta and get old stuff off. Now emerge -DuN @world is clean
with 390 packages currently installed. I cleaned everything out of my
user directory just to ensure that any problems aren't caused by old
config files. First step behind me.

Now, at this point I started looking at emerging xfce4-meta again, it
failed with messages about rebuilding xorg-server. When I attempted
that I got error messages about invalid gcc profiles which led me to
discover this problem:

cruncher ~ # gcc-config -l
 * gcc-config: Active gcc profile is invalid!

 [1] x86_64-pc-linux-gnu-4.4.3
cruncher ~ # gcc-config 1
 * Switching native-compiler to x86_64-pc-linux-gnu-4.4.3 ...
 * gcc-config: Active gcc profile is invalid!

 * Your gcc has a bug with GCC_SPECS.
 * Please re-emerge gcc.
 * http://bugs.gentoo.org/68395

>>> Regenerating /etc/ld.so.cache...                                                           [ ok ]

 * If you intend to use the gcc from the new profile in an already
 * running shell, please remember to do:

 *   # source /etc/profile

cruncher ~ #

The bug report suggested the above idea but I couldn't set the profile
to '1' so I did emerge -1 gcc. Hey, at least it lets me watch 12
processor cores max out at 100%. ;-)

5 minutes later....

cruncher ~ # gcc-config -l
 [1] x86_64-pc-linux-gnu-4.4.3 *
cruncher ~ #

Now the profile is set and emerge -DuN xfce4-meta was clean. Progress,
I think, but when I try to log in I get logged out automatically with
a message to look at the .xession-errors file:

cruncher mark # cat .xsession-errors
/etc/X11/gdm/Xsession: Beginning session setup...
/etc/X11/gdm/Xsession: Cannot find Xclients
/etc/X11/gdm/Xsession: line 203: exec: xterm: not found
cruncher mark #

cruncher mark # eix -I xterm
No matches found.
cruncher mark # updatedb
cruncher mark # slocate xterm | grep bin
cruncher mark #

Unmet dependencies?

Because I'm paranoid about gcc problems and I need to run some errands
I'm going to send this now and start an emerge -e @world. That should
finish up in about 90 minutes I think (I'll time it for fun) and I'll
try again after that.

Thanks,
Mark

Re: [gentoo-user] Re: ~amd64 - my experience so far...

[Paul Hartman]

On Mon, Apr 12, 2010 at 4:03 PM, Mark Knecht <markknecht@gmail.com> wrote:
> cruncher mark # cat .xsession-errors
> /etc/X11/gdm/Xsession: Beginning session setup...
> /etc/X11/gdm/Xsession: Cannot find Xclients
> /etc/X11/gdm/Xsession: line 203: exec: xterm: not found
> cruncher mark #
>
> cruncher mark # eix -I xterm
> No matches found.
> cruncher mark # updatedb
> cruncher mark # slocate xterm | grep bin
> cruncher mark #
>
> Unmet dependencies?

In my system, xterm is a dependency of xinit, which in turn is a
dependency of xorg-server. That is weird and I don't know how it would
not be installed (assuming you've got xorg-server installed).

Re: [gentoo-user] Re: ~amd64 - my experience so far...

[Mark Knecht]

On Mon, Apr 12, 2010 at 2:14 PM, Paul Hartman
<paul.hartman+gentoo@gmail.com> wrote:
> On Mon, Apr 12, 2010 at 4:03 PM, Mark Knecht <markknecht@gmail.com> wrote:
>> cruncher mark # cat .xsession-errors
>> /etc/X11/gdm/Xsession: Beginning session setup...
>> /etc/X11/gdm/Xsession: Cannot find Xclients
>> /etc/X11/gdm/Xsession: line 203: exec: xterm: not found
>> cruncher mark #
>>
>> cruncher mark # eix -I xterm
>> No matches found.
>> cruncher mark # updatedb
>> cruncher mark # slocate xterm | grep bin
>> cruncher mark #
>>
>> Unmet dependencies?
>
> In my system, xterm is a dependency of xinit, which in turn is a
> dependency of xorg-server. That is weird and I don't know how it would
> not be installed (assuming you've got xorg-server installed).
>
>

Really? Doesn't seem to be true here. It doesn't seem to be installed
because of xorg-server nor included in xorg-server:

cruncher ~ # emerge -ep xorg-server | grep xterm
cruncher ~ # equery files xorg-server | grep xterm
cruncher ~ #

I see it as a separate package:

cruncher ~ # eix -c xterm
[N] lxde-base/lxterminal ((~)0.1.7): Lightweight vte-based tabbed
terminal emulator for LXDE
[N] net-misc/ajaxterm ((~)0.10): Ajaxterm is a web based terminal
[N] x11-misc/xtermcontrol ((~)2.10): xtermcontrol enables dynamic
control of XFree86 xterm properties
[N] x11-terms/cxterm (--): A Chinese/Japanese/Korean X-Terminal
[N] x11-terms/roxterm ((~)1.16.3): A terminal emulator designed to
integrate with the ROX environment
[N] x11-terms/xterm ((~)255): Terminal Emulator for X Windows
Found 6 matches.
cruncher ~ #

Very strange. Flag issue of some type? I emerged it explicitly and it
let me start an xsession which was only an xterm. When I typed exit X
locked up and didn't go back to the login screen. It's a mess.

So obviously I'm back from my errand and unfortunately my emerge -e
@world failed with another perl failure.

cruncher ~ # time emerge -e @world
<SNIP>

* Messages for package x11-libs/libdrm-2.4.20:

 * libdrm's ABI may have changed without change in library name
 * Please rebuild media-libs/mesa, x11-base/xorg-server and
 * your video drivers in x11-drivers/*.

 * Messages for package dev-lang/perl-5.10.1:

 * ERROR: dev-lang/perl-5.10.1 failed:
 *   emake failed
 *
 * Call stack:
 *     ebuild.sh, line   48:  Called src_compile
 *   environment, line 2844:  Called _eapi2_src_compile
 *     ebuild.sh, line  640:  Called die
 * The specific snippet of code:
 *              emake || die "emake failed"
 *
 * If you need support, post the output of 'emerge --info
=dev-lang/perl-5.10.1',
 * the complete build log and the output of 'emerge -pqv =dev-lang/perl-5.10.1'.
 * The complete build log is located at
'/var/tmp/portage/dev-lang/perl-5.10.1/temp/build.log'.
 * The ebuild environment file is located at
'/var/tmp/portage/dev-lang/perl-5.10.1/temp/environment'.
 * S: '/var/tmp/portage/dev-lang/perl-5.10.1/work/perl-5.10.1'

 * Regenerating GNU info directory index...
 * Processed 103 info files.

real    23m38.050s
user    28m16.088s
sys     4m42.603s
cruncher ~ #

Not that this should necessarily be posted to this list, but since
we've started I'll continue along until you tell me to go away. The
last two are huge so I'll only post the start and end for now. Keep in
mind that ALL of this worked in stable. This is only since going to
~amd64 that I've seen any of this.

cruncher ~ # emerge --info =dev-lang/perl-5.10.1
Portage 2.2_rc67 (default/linux/amd64/10.0/desktop, gcc-4.4.3,
glibc-2.11-r1, 2.6.34-rc3 x86_64)
=================================================================
                        System Settings
=================================================================
System uname: Linux-2.6.34-rc3-x86_64-Intel-R-_Core-TM-_i7_CPU_X_980_@_3.33GHz-with-gentoo-2.0.1
Timestamp of tree: Mon, 12 Apr 2010 10:45:01 +0000
app-shells/bash:     4.1_p5
dev-java/java-config: 2.1.10
dev-lang/python:     2.6.5-r1, 3.1.2-r2
sys-apps/baselayout: 2.0.1
sys-apps/openrc:     0.6.1-r1
sys-apps/sandbox:    2.2
sys-devel/autoconf:  2.13, 2.65
sys-devel/automake:  1.10.3, 1.11.1
sys-devel/binutils:  2.20.1
sys-devel/gcc:       4.4.3
sys-devel/gcc-config: 1.4.1
sys-devel/libtool:   2.2.6b
virtual/os-headers:  2.6.33
ACCEPT_KEYWORDS="amd64 ~amd64"
ACCEPT_LICENSE="* -@EULA dlj-1.1 PUEL"
CBUILD="x86_64-pc-linux-gnu"
CFLAGS="-O2 -march=native -pipe"
CHOST="x86_64-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/share/X11/xkb"
CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d
/etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release
/etc/revdep-rebuild /etc/sandbox.d /etc/terminfo"
CXXFLAGS="-O2 -march=native -pipe"
DISTDIR="/usr/portage/distfiles"
EMERGE_DEFAULT_OPTS="--with-bdeps y"
FEATURES="assume-digests buildpkg distlocks fixpackages news
parallel-fetch preserve-libs protect-owned sandbox sfperms strict
unmerge-logs unmerge-orphans userfetch"
GENTOO_MIRRORS="http://gentoo.osuosl.org/ "
LDFLAGS="-Wl,-O1"
LINGUAS="en"
MAKEOPTS="-j13"
PKGDIR="/usr/portage/packages"
PORTAGE_CONFIGROOT="/"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times
--compress --force --whole-file --delete --stats --timeout=180
--exclude=/distfiles --exclude=/local --exclude=/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
SYNC="rsync://rsync.namerica.gentoo.org/gentoo-portage"
USE="X a52 aac acl acpi alsa amd64 berkdb branding bzip2 cairo caps
cdda cddb cdparanoia cdr cli consolekit cracklib crypt cxx dbus dri
dts dvd dvdr emboss encode exif fam ffmpeg firefox flac fltk fortran
ftp gdbm gif gnome gpm gtk hal iconv ieee1394 ipv6 jpeg kde ladspa
lame lash lcms ldap libnotify libsamplerate mad mikmod mmx mng modules
mp3 mp4 mpeg mudflap multilib musepack ncurses nls nptl nptlonly
nsplugin ogg opengl openmp pam pango pcre pdf perl png ppds pppd
python qt3support qt4 readline reflection sdl semantic-desktop session
spell spl sse sse2 sse4 ssl ssse3 startup-notification svg sysfs tcpd
tiff tifftruetype truetype unicode usb vmware vorbis x264 xcb xine xml
xorg xulrunner xv xvid zlib" ALSA_CARDS="intel-hda"
ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty
extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul
mulaw multi null plug rate route share shm softvol"
APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon
authn_dbm authn_default authn_file authz_dbm authz_default
authz_groupfile authz_host authz_owner authz_user autoindex cache dav
dav_fs dav_lock deflate dir disk_cache env expires ext_filter
file_cache filter headers include info log_config logio mem_cache mime
mime_magic negotiation rewrite setenvif speling status unique_id
userdir usertrack vhost_alias" ELIBC="glibc" INPUT_DEVICES="evdev"
KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216
lcdm001 mtxorb ncurses text" LINGUAS="en" RUBY_TARGETS="ruby18"
USERLAND="GNU" VIDEO_CARDS="radeon fbdev"
Unset:  CPPFLAGS, CTARGET, FFLAGS, INSTALL_MASK, LANG, LC_ALL,
PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS,
PORTDIR_OVERLAY

=================================================================
                        Package Settings
=================================================================

dev-lang/perl-5.10.1 was built with the following:
USE="berkdb gdbm (multilib) -build -debug -doc -ithreads"

cruncher ~ #

cruncher ~ # emerge -pqv =dev-lang/perl-5.10.1
[ebuild   R   ] dev-lang/perl-5.10.1  USE="berkdb gdbm -build -debug
-doc -ithreads"
cruncher ~ #



mark@firefly ~ $ cat FAIL.build.log | more
 * CPV:  dev-lang/perl-5.10.1
 * REPO: gentoo
 * USE:  amd64 berkdb elibc_glibc gdbm kernel_linux multilib userland_GNU
>>> Unpacking source...
>>> Unpacking perl-5.10.1.tar.bz2 to /var/tmp/portage/dev-lang/perl-5.10.1/work
>>> Unpacking perl-5.10.1-9.tar.bz2 to /var/tmp/portage/dev-lang/perl-5.10.1/work
>>> Source unpacked in /var/tmp/portage/dev-lang/perl-5.10.1/work
>>> Preparing source in /var/tmp/portage/dev-lang/perl-5.10.1/work/perl-5.10.1 ...
 * Applying various patches (bugfixes/updates) ...
 *   0001-fixes_RT69056__postive__GPOS__leads__to__segv__on__first__match.diff
...                    [ ok ]
 *   0002-fixes_RT69973__disable__non__unicode__case__insensitive__trie__matching.diff
...            [ ok ]
 *   0003-gentoo_MakeMaker-RUNPATH.diff ...
                               [ ok ]
 *   0004-gentoo_config__over.diff ...
                               [ ok ]
 *   0005-gentoo_cpan__definstalldirs.diff ...
                               [ ok ]
 *   0006-gentoo_cpanplus__definstalldirs.diff ...
                               [ ok ]
 *   0007-gentoo_create-libperl-soname.diff ...
                               [ ok ]
 *   0008-gentoo_prelink-lpthread.diff ...
                               [ ok ]
 *   0009-gentoo_remove__single__quote__character__from__uname.diff
...                               [ ok ]
 *   0010-gentoo_reorder-INC.diff ...
                               [ ok ]
 *   0011-gentoo_Devel-PPPort-temporary-ICE-fix.diff ...
                               [ ok ]
 * Done with patching
>>> Source prepared.
>>> Configuring source in /var/tmp/portage/dev-lang/perl-5.10.1/work/perl-5.10.1 ...
First let's make sure your kit is complete.  Checking...
Locating common programs...
Checking compatibility between /bin/echo and builtin echo (if any)...
Symbolic links are supported.


<SNIP>


LD_LIBRARY_PATH=/var/tmp/portage/dev-lang/perl-5.10.1/work/perl-5.10.1
/var/tmp/portage/dev-lang/perl-5.10.1/work/perl-5.10.1/preload
/var/tmp/portage/dev-lang/perl-5.10.1/work/perl-5.10.1/libperl.so.5.10.1
 ./miniperl -Ilib configpm
LD_LIBRARY_PATH=/var/tmp/portage/dev-lang/perl-5.10.1/work/perl-5.10.1
/var/tmp/portage/dev-lang/perl-5.10.1/work/perl-5.10.1/preload
/var/tmp/portage/dev-lang/perl-5.10.1/work/perl-5.10.1/libperl.so.5.10.1
 ./miniperl -Ilib configpm
          CCCMD =  x86_64-pc-linux-gnu-gcc -DPERL_CORE -c
-fno-strict-aliasing -pipe -fstack-protector -D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64  -std=c89 -O2 -march=native -pipe  -Wall -ansi
-W -Wextra -Wdeclaration-after-statement -Wendif-labels -Wc++-compat
written lib/Config.pod
written lib/Config.pod
updated lib/Config.pm
updated lib/Config_heavy.pl
lib/Config.pm did not return a true value at configpm line 1023.
updated lib/Config.pm
updated lib/Config_heavy.pl
make: *** [lib/Config.pm] Error 255
make: *** Waiting for unfinished jobs....
written lib/Config.pod
 * ERROR: dev-lang/perl-5.10.1 failed:
 *   emake failed
 *
 * Call stack:
 *     ebuild.sh, line   48:  Called src_compile
 *   environment, line 2844:  Called _eapi2_src_compile
 *     ebuild.sh, line  640:  Called die
 * The specific snippet of code:
 *              emake || die "emake failed"
 *
 * If you need support, post the output of 'emerge --info
=dev-lang/perl-5.10.1',
 * the complete build log and the output of 'emerge -pqv =dev-lang/perl-5.10.1'.
 * The complete build log is located at
'/var/tmp/portage/dev-lang/perl-5.10.1/temp/build.log'.
 * The ebuild environment file is located at
'/var/tmp/portage/dev-lang/perl-5.10.1/temp/environment'.
 * S: '/var/tmp/portage/dev-lang/perl-5.10.1/work/perl-5.10.1'
mark@firefly ~ $



declare -x ABI="amd64"
declare -x ALSA_CARDS=""
declare -x ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop
empty extplug file hooks iec958
ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate
route share shm softvol"
declare -x APACHE2_MODULES="actions alias auth_basic authn_alias
authn_anon authn_dbm authn_default a
uthn_file authz_dbm authz_default authz_groupfile authz_host
authz_owner authz_user autoindex cache d
av dav_fs dav_lock deflate dir disk_cache env expires ext_filter
file_cache filter headers include in
fo log_config logio mem_cache mime mime_magic negotiation rewrite
setenvif speling status unique_id u
serdir usertrack vhost_alias"
declare -x ARCH="amd64"
declare -x ASFLAGS_x86="--32"
declare -x BUILD_BZIP2="0"
declare -x BZIP2_INCLUDE="/usr/include"
declare -x BZIP2_LIB="/usr/lib64"
declare -x CBUILD="x86_64-pc-linux-gnu"
declare -x CDEFINE_amd64="__x86_64__"
declare -x CDEFINE_default="__unix__"
declare -x CDEFINE_x86="__i386__"
declare -x CFLAGS="-O2 -march=native -pipe"
declare -x CFLAGS_default=""
declare -x CFLAGS_x86="-m32"
declare -x CHOST="x86_64-pc-linux-gnu"
declare -x CHOST_amd64="x86_64-pc-linux-gnu"
declare -x CHOST_default="x86_64-pc-linux-gnu"
declare -x CHOST_x86="i686-pc-linux-gnu"
declare -- COMMON_DEPEND="berkdb? ( sys-libs/db )
        gdbm? ( >=sys-libs/gdbm-1.8.3 )
        >=sys-devel/libperl-5.10.1
        !!<sys-devel/libperl-5.10.1
        app-arch/bzip2
        sys-libs/zlib"
declare -x CPPFLAGS=""
declare -x CROSSCOMPILE_OPTS=""
declare -x CTARGET_default="x86_64-pc-linux-gnu"
declare -x CVS_RSH="ssh"
declare -x CXXFLAGS="-O2 -march=native -pipe"
declare -x DEFAULT_ABI="amd64"
declare -- DEFINED_PHASES=" configure install postinst postrm prepare
setup test"
declare -- DEPEND="berkdb? ( sys-libs/db )
        gdbm? ( >=sys-libs/gdbm-1.8.3 )
        >=sys-devel/libperl-5.10.1
        !!<sys-devel/libperl-5.10.1
        app-arch/bzip2
        sys-libs/zlib
        elibc_FreeBSD? ( sys-freebsd/freebsd-mk-defs ) "
declare -- DESCRIPTION="Larry Wall's Practical Extraction and Report Language"
declare -x DESTTREE="/usr"
declare -x DIROPTIONS="-m0755"
declare -x EAPI="2"
declare -x ELIBC="glibc"
declare -- EPATCH_EXCLUDE=""
declare -- EPATCH_FORCE="no"



<SNIP>

validate_desktop_entries ()
{
    if [[ -x /usr/bin/desktop-file-validate ]]; then
        einfo "Checking desktop entry validity";
        local directories="";
        for d in /usr/share/applications $@;
        do
            [[ -d ${D}${d} ]] && directories="${directories} ${D}${d}";
        done;
        if [[ -n ${directories} ]]; then
            for FILE in $(find ${directories} -name "*\.desktop"
                             -not -path '*.hidden*' | sort -u
2>/dev/null);
            do
                local temp=$(desktop-file-validate ${FILE} | grep -v
"warning:" |                   sed -e "s|error: ||" -e
"s|${FILE}:|--|g" );
                [[ -n $temp ]] && elog ${temp/--/${FILE/${D}/}:};
            done;
        fi;
        echo "";
    else
        einfo "Passing desktop entry validity check. Install
dev-util/desktop-file-utils, if you want to help to improve Gentoo.";
    fi
}
cruncher ~ #

Re: [gentoo-user] Re: ~amd64 - my experience so far...

[Alex Schuster]

Mark Knecht writes:

> OK, let's start with xfce4-meta because there was only one failure.
> eix-update was done this morning and emerge -DuN @system is clean
> using ~arch in make.conf. I'll paste make.conf & emerge --info at the
> end of this message
[...]
> >>> Source prepared.
> >>> Configuring source in
> >>> /var/tmp/portage/dev-perl/glib-perl-1.222/work/Glib-1.222 ...
> 
>  * Using ExtUtils::MakeMaker
> Can't locate ExtUtils/Depends.pm in @INC (@INC contains:
[...]
> MakeMaker FATAL: prerequisites not found.
>     ExtUtils::Depends not installed
> 
> Please install these modules first and rerun 'perl Makefile.PL'.

wonko@weird ~ $ equery b $( locate ExtUtils/Depends.pm )
 * Searching for /usr/lib/perl5/vendor_perl/5.10.1/ExtUtils/Depends.pm ... 
dev-perl/extutils-depends-0.302 
(/usr/lib/perl5/vendor_perl/5.10.1/ExtUtils/Depends.pm)

So I guess you do not have dev-perl/extutils-depends installed? In this 
case, emerge it, and let's hope all the other errors are similar ones.

	Wonko

[gentoo-user] Re: ~amd64 - my experience so far...

[Kerin Millar]

On 12/04/2010 12:57, Mark Knecht wrote:
> QUESTION: Assume I'm happy with ~amd64 on @system, but want to build
> the stable version of gnome or kde. How do I get it? Since gnome-2.26

You could opt to retain the ~amd64 keyword on system packages alone. 
Consider the following (which requires portage-utils):

$ emerge -qep system | sed -rne '/^\[ebuild/{s/(^| )\[[^]]*\]( |$)//gp}' 
| xargs qatom | awk '{ print $1"/"$2 }'

You might then proceed to place the output of the above command in 
package.keywords then switch ACCEPT_KEYWORDS back to "amd64".

Cheers,

--Kerin

Re: [gentoo-user] ~amd64 - my experience so far...

[Paul Hartman]

On Mon, Apr 12, 2010 at 6:57 AM, Mark Knecht <markknecht@gmail.com> wrote:
> ...is not so good actually. Certainly not the way I'd want others to
> experience Gentoo.
>
> OK, the ~amd64 upgrade to @system was easy and relatively painless.
> The documents were fairly clear. There are things to learn, and old
> friends like rc-update and df look different, but it worked and didn't
> take long - less than an hour to reboot including editing - so that's
> good.
>
> Unfortunately, simply allowing all environments & apps on the system
> to go ~amd64 isn't working out as nicely.
>
> 1) xfce4 had one build failure. I masked it and the build finished.
> xfce starts and seems to mostly work, but I get no wallpaper and the
> right click for a menu on the desktop doesn't work. It's usable, but
> clearly 'not stable'.

Hi,

I'm using ~amd64 for my whole system (for years). I have a similar
system to yours, but only a Core i7 920, :) and at the moment every
package on my system builds fine.

Which package failed? Which profile and GCC are you using? I just
emerged xfce4-meta and everything worked. Here's my GCC, profile and
xfce versions (I also use unmasked portage):

[ebuild   R   ] sys-devel/gcc-4.4.3  USE="fortran gcj graphite gtk
mudflap (multilib) nls nptl objc objc++ objc-gc openmp (-altivec)
-bootstrap -build -doc (-fixed-point) (-hardened) (-libffi) -multislot
(-n32) (-n64) -nocxx -test -vanilla" 0 kB

 $ sudo gcc-config -l
 [1] x86_64-pc-linux-gnu-4.4.3 *

$ sudo eselect profile show
Current make.profile symlink:
  default/linux/amd64/10.0/desktop

My cflags:
CFLAGS="-march=native -O3 -floop-interchange -floop-strip-mine
-floop-block -ggdb -pipe"
CXXFLAGS="${CFLAGS}"
LDFLAGS="-Wl,--as-needed"


 $ emerge -vp xfce4-meta

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild  N    ] xfce-base/libxfce4util-4.7.1  USE="-debug" 0 kB
[ebuild  N    ] dev-util/xfce4-dev-tools-4.7.2  0 kB
[ebuild  N    ] x11-themes/xfce4-icon-theme-4.4.3  0 kB
[ebuild  N    ] x11-themes/gtk-engines-xfce-2.6.0  0 kB
[ebuild  N    ] xfce-base/xfconf-4.7.2  USE="perl -debug -profile" 0 kB
[ebuild  N    ] xfce-base/exo-0.3.106  USE="hal libnotify python -debug" 0 kB
[ebuild  N    ] xfce-base/libxfce4menu-4.6.1  USE="-debug" 0 kB
[ebuild  N    ] xfce-base/libxfcegui4-4.6.3  USE="startup-notification
-debug -glade" 0 kB
[ebuild  N    ] xfce-base/xfce4-panel-4.6.2-r1
USE="startup-notification -debug" 0 kB
[ebuild  N    ] xfce-base/xfce-utils-4.6.1  USE="dbus lock -debug" 0 kB
[ebuild  N    ] xfce-base/xfwm4-4.6.1  USE="startup-notification
xcomposite -debug" 0 kB
[ebuild  N    ] xfce-base/xfce4-settings-4.6.3-r1  USE="keyboard
libnotify -debug -sound" 0 kB
[ebuild  N    ] xfce-base/xfce4-session-4.6.1-r1  USE="-debug -fortune
-gnome -gnome-keyring -profile" 0 kB
[ebuild  N    ] xfce-base/thunar-1.0.1  USE="dbus exif hal pcre
startup-notification trash-plugin -debug -doc -gnome -test" 0 kB
[ebuild  N    ] xfce-base/xfdesktop-4.6.1-r1  USE="branding
menu-plugin thunar -debug -doc" LINGUAS="-be -ca -cs -da -de -el -es
-et -eu -fi -fr -he -hu -it -ja -ko -nb_NO -nl -pa -pl -pt_BR -ro -ru
-sk -sv -tr -uk -vi -zh_CN -zh_TW" 0 kB
[ebuild  N    ] xfce-base/xfce4-meta-4.6.1  USE="session -minimal" 0 kB


The xfce wallpaper thing sounds like what I experienced with xfce
during the jpeg-6-to-7 upgrade process. At the time, jpeg was not
slotted and there was jpeg-compat for programs that were incompatible
with jpeg-7. Now we have jpeg-8 as well, and 6/7/8 are in slots, so
maybe the solution is different. Back then, I unmerged and masked
jpeg-6, revdep-rebuild everything that depended on jpeg so that it was
built against jpeg-7 and then everything was fine. (Maybe there was a
gtk+ patch I had to apply on day 0, but that was long ago made
obsolete by newer versions of gtk+ in portage)


> 2) gnome-2.28 simply doesn't build.

I'm not a gnome user but I can try this if you want (135 packages to
emerge in my case), or if you have more specific info about which part
doesn't build I can try only the specifics.


> 3) I'm currently left with lots of things in emerge @preserved-rebuild
> that don't build. emerge -DuN @world is not clean.

Maybe you can unmerge those packages, allowing emerge to get rid of
the preserved libs, then emerge world to bring those packages back.

Re: [gentoo-user] ~amd64 - my experience so far...

[Paul Hartman]

On Mon, Apr 12, 2010 at 10:45 AM, Paul Hartman
<paul.hartman+gentoo@gmail.com> wrote:
> I'm not a gnome user but I can try this if you want (135 packages to
> emerge in my case), or if you have more specific info about which part
> doesn't build I can try only the specifics.


I went ahead and emerged gnome-base/gnome-2.28.2 while I was at lunch.
All packages emerged properly without any issues.

So the good news is there's nothing apparently wrong with ~amd64 in
general, and it's probably a configuration difference between my
system and yours, or maybe growing pains if you have still got some
packages at amd64 and some at ~amd64. If you'd like to compare set-ups
I'd be happy to try to help you get it sorted out (either on list or
in email).