subject:"\[gentoo\-user\] Re\: checking for....."


Nikos Chantziaras wrote:


No, that's not it.  It's this:

 !!! Please attach the following file when seeking support:
 !!! /var/tmp/portage/sys-apps/sandbox-2.4/work/build-default/config.log




Hmmm.   Thought it was the same.  Here goes but it is lengthy:

root@smoker / # cat 
/var/tmp/portage/sys-apps/sandbox-2.4/work/build-default/config.log

This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.

It was created by sandbox configure 2.4, which was
generated by GNU Autoconf 2.65.  Invocation command line was

  $ ../sandbox-2.4//configure --prefix=/usr --build=i686-pc-linux-gnu 
--host=i686-pc-linux-gnu --mandir=/usr/share/man 
--infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc 
--localstatedir=/var/lib --libdir=/usr/lib


## - ##
## Platform. ##
## - ##

hostname = smoker
uname -m = i686
uname -r = 2.6.36-gentoo-r5
uname -s = Linux
uname -v = #1 PREEMPT Mon Dec 27 05:46:37 CST 2010

/usr/bin/uname -p = AMD Athlon(tm) XP 2500+
/bin/uname -X = unknown

/bin/arch  = unknown
/usr/bin/arch -k   = unknown
/usr/convex/getsysinfo = unknown
/usr/bin/hostinfo  = unknown
/bin/machine   = unknown
/usr/bin/oslevel   = unknown
/bin/universe  = unknown

PATH: /usr/lib/portage/bin/ebuild-helpers
PATH: /usr/local/sbin
PATH: /usr/local/bin
PATH: /usr/sbin
PATH: /usr/bin
PATH: /sbin
PATH: /bin
PATH: /opt/bin
PATH: /usr/i686-pc-linux-gnu/gcc-bin/4.4.4


## --- ##
## Core tests. ##
## --- ##

configure:2399: checking for a BSD-compatible install
configure:2467: result: /usr/bin/install -c
configure:2478: checking whether build environment is sane
configure:2528: result: yes
configure:2669: checking for a thread-safe mkdir -p
configure:2708: result: /bin/mkdir -p
configure:2721: checking for gawk
configure:2737: found /usr/bin/gawk
configure:2748: result: gawk
configure:2759: checking whether make sets $(MAKE)
configure:2781: result: yes
configure:2896: checking environment state
PORTAGE_FEATURES=assume-digests binpkg-logs buildpkg distlocks 
fixlafiles fixpackages news parallel-fetch preserve-libs protect-owned 
sandbox sfperms strict unknown-features-warn unmerge-logs 
unmerge-orphans userfetch

PVR=2.4
FETCHCOMMAND_SSH=bash -c x=\${2#ssh://} ; host=\${x%%/*} ; 
port=\${host##*:} ; host=\${host%:*} ; [[ \${host} = \${port} ]]  
port=22 ; exec rsync --rsh=\ssh -p\${port}\ -avP 
\\${host}:/\${x#*/}\ \\$1\ rsync ${DISTDIR}/${FILE} ${URI}
KEYWORDS=alpha amd64 arm hppa ia64 m68k ~mips ppc ppc64 s390 sh sparc 
x86 ~sparc-fbsd -x86-fbsd

A=sandbox-2.4.tar.xz
LDFLAGS=-Wl,-O1 -Wl,--as-needed
NUT_DRIVERS=cyberpower
SANE_BACKENDS=hp
ALSA_CARDS=
XTABLES_ADDONS=quota2 psd pknock lscan length2 ipv4options ipset ipp2p 
iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark 
dhcpmac delude chaos account

D=/var/tmp/portage/sys-apps/sandbox-2.4/image/
PORTAGE_IPC_DAEMON=1
SLOT=0
SANDBOX_WRITE=:/dev/console:/dev/fd:/dev/full:/dev/null:/dev/pts/:/dev/pty:/dev/shm:/dev/tts:/dev/tty:/dev/vc/:/dev/zero:/proc/self/fd:/tmp/:/usr/lib32/cf:/usr/lib32/conftest:/usr/lib64/cf:/usr/lib64/conftest:/usr/lib/cf:/usr/lib/conftest:/usr/tmp/cf:/usr/tmp/conftest:/var/tmp:/var/tmp/:/var/tmp/portage/sys-apps/sandbox-2.4/homedir/.bash_history
SANDBOX_LIB=libsandbox.so
ELIBC=glibc
LINGUAS=en_US en
SHELL=/bin/sh
TERM=screen
KERNEL=linux
KV=2.6.36-gentoo-r5
XDG_SESSION_COOKIE=d209e0650ffe67fde18419e94bf8e895-1304650290.725723-105440127
TMPDIR=/var/tmp/portage/sys-apps/sandbox-2.4/temp
CATEGORY=sys-apps
SSH_CLIENT=192.168.2.5 38142 22
CPPFLAGS=
PORT_ENOTICE_DIR=/var/tmp/portage/enotice/
FILESDIR=/usr/portage/sys-apps/sandbox/files
LD_PRELOAD=libsandbox.so
_E_DOCDESTTREE_=
EXEOPTIONS=-m0755
EBUILD_MASTER_PID=32719
ACCEPT_LICENSE=GPL-2
DESTTREE=/usr
SANDBOX_DEBUG=0
DUALCASE=1
DEFINED_PHASES= compile install postinst preinst test unpack
SSH_TTY=/dev/pts/0
SANDBOX_PREDICT=/var/tmp/portage/sys-apps/sandbox-2.4/homedir:/dev/crypto:/var/cache/fontconfig
PORTAGE_CONFIGROOT=/
LC_ALL=C
SANDBOX_PID=32638
ANT_HOME=/usr/share/ant
PROVIDE=
P=sandbox-2.4
ECLASSDIR=/usr/portage/eclass
_E_EXEDESTTREE_=
PORTAGE_ARCHLIST=ppc sparc64-freebsd ppc-openbsd x86-openbsd ppc64 
x86-winnt x86-fbsd ppc-aix alpha arm x86-freebsd s390 amd64 arm-linux 
x86-macos x64-openbsd ia64-hpux hppa x86-netbsd x86-cygwin amd64-linux 
ia64-linux x86 sparc-solaris x64-freebsd sparc64-solaris x86-linux 
x64-macos sparc m68k-mint ia64 mips ppc-macos x86-interix hppa-hpux 
amd64-fbsd x64-solaris mips-irix m68k sh x86-solaris sparc-fbsd

PORTAGE_PYM_PATH=/usr/lib/portage/pym
http_proxy=http://192.168.2.5:8080
USE=consolekit elibc_glibc kernel_linux policykit userland_GNU x86

Re: [gentoo-user] Re: checking whether the C compiler works... no Oooops !!

2011-05-06 Thread justin

On 06/05/11 11:08, Dale wrote:

 
 That shed any light?
 
 Dale
 
 :-)  :-)
 
 


Yes it does

/usr/libexec/gcc/i686-pc-linux-gnu/4.4.4/cc1: error while loading shared
libraries: libmpfr.so.1: cannot open shared object file: No such file or
directory

you upgraded your mpfr. Now you have to rebuild your gcc as well.



signature.asc
Description: OpenPGP digital signature

[gentoo-user] Re: checking whether the C compiler works... no Oooops !!

2011-05-06 Thread Nikos Chantziaras


On 05/06/2011 12:08 PM, Dale wrote:

Nikos Chantziaras wrote:


No, that's not it. It's this:

!!! Please attach the following file when seeking support:
!!! /var/tmp/portage/sys-apps/sandbox-2.4/work/build-default/config.log




Hmmm. Thought it was the same. Here goes but it is lengthy:

[...]

That shed any light?


Yep:

/usr/libexec/gcc/i686-pc-linux-gnu/4.4.4/cc1: error while loading shared 
libraries: libmpfr.so.1: cannot open shared object file


Meaning, run revdep-rebuild :)

Re: [gentoo-user] Re: checking whether the C compiler works... no Oooops !!


justin wrote:

On 06/05/11 11:08, Dale wrote:

   

That shed any light?

Dale

:-)  :-)


 


Yes it does

/usr/libexec/gcc/i686-pc-linux-gnu/4.4.4/cc1: error while loading shared
libraries: libmpfr.so.1: cannot open shared object file: No such file or
directory

you upgraded your mpfr. Now you have to rebuild your gcc as well.

   


It won't compile mpfr either.  I get the same error.  It appears that I 
can't compile ANYTHING right now.  This ain't good.  O_O


Would doing this from a CD work or would I get the same error?

I'm going to look for a binary.  It's been a while so I'm not sure what 
was left on there.  :/


Dale

:-)  :-)

Re: [gentoo-user] Re: checking whether the C compiler works... no Oooops !!

2011-05-06 Thread Alan McKinnon

Apparently, though unproven, at 11:15 on Friday 06 May 2011, justin did opine 
thusly:

 On 06/05/11 11:08, Dale wrote:
  That shed any light?
  
  Dale
  
  :-)  :-)
 
 Yes it does
 
 /usr/libexec/gcc/i686-pc-linux-gnu/4.4.4/cc1: error while loading shared
 libraries: libmpfr.so.1: cannot open shared object file: No such file or
 directory
 
 you upgraded your mpfr. Now you have to rebuild your gcc as well.

That's gonna be fun.

He doesn't have a working gcc to use to rebuild gcc.

-- 
alan dot mckinnon at gmail dot com

Re: [gentoo-user] Re: checking whether the C compiler works... no Oooops !!


Dale wrote:

justin wrote:

On 06/05/11 11:08, Dale wrote:


That shed any light?

Dale

:-)  :-)




Yes it does

/usr/libexec/gcc/i686-pc-linux-gnu/4.4.4/cc1: error while loading shared
libraries: libmpfr.so.1: cannot open shared object file: No such file or
directory

you upgraded your mpfr. Now you have to rebuild your gcc as well.



It won't compile mpfr either.  I get the same error.  It appears that 
I can't compile ANYTHING right now.  This ain't good.  O_O


Would doing this from a CD work or would I get the same error?

I'm going to look for a binary.  It's been a while so I'm not sure 
what was left on there.  :/


Dale

:-)  :-)



I found a binary for a older version.  That seems to be working.  I will 
run all the usual suspects, revdep-rebuild, python-updater and such and 
see what happens.  Python-updater is making its list now.  Still 
scratching my head on that one.


Thanks for the help.  Will post back if it gives any more problems.

Dale

:-)  :-)

Re: [gentoo-user] Re: checking whether the C compiler works... no Oooops !!


Nikos Chantziaras wrote:

On 05/06/2011 12:08 PM, Dale wrote:

Nikos Chantziaras wrote:


No, that's not it. It's this:

!!! Please attach the following file when seeking support:
!!! /var/tmp/portage/sys-apps/sandbox-2.4/work/build-default/config.log




Hmmm. Thought it was the same. Here goes but it is lengthy:

[...]

That shed any light?


Yep:

/usr/libexec/gcc/i686-pc-linux-gnu/4.4.4/cc1: error while loading 
shared libraries: libmpfr.so.1: cannot open shared object file


Meaning, run revdep-rebuild :)




On the list of things to do.  Running python-updater now will run that 
next.


Thanks.

Dale

:-)  :-)

Re: [gentoo-user] Re: checking whether the C compiler works... no Oooops !!


Alan McKinnon wrote:

Apparently, though unproven, at 11:15 on Friday 06 May 2011, justin did opine
thusly:

   

On 06/05/11 11:08, Dale wrote:
 

That shed any light?

Dale

:-)  :-)
   

Yes it does

/usr/libexec/gcc/i686-pc-linux-gnu/4.4.4/cc1: error while loading shared
libraries: libmpfr.so.1: cannot open shared object file: No such file or
directory

you upgraded your mpfr. Now you have to rebuild your gcc as well.
 

That's gonna be fun.

He doesn't have a working gcc to use to rebuild gcc.

   


It would be but having a older binary of mpfr saved my butt.  I knew I 
was keeping those around for some reason.  ;-)


Going to keep a eye on the next mpfr update tho.  o_O

Dale

:-)  :-)

Re: [gentoo-user] Re: checking whether the C compiler works... no Oooops !!

2011-05-06 Thread Albert Hopkins

On Fri, 2011-05-06 at 12:18 +0200, Andrea Conti wrote:
 AFAIK in order to avoid this kind of
 breakage system ebuilds such as mpfr never delete old library
 versions;
 they just print a warning saying that the old library  has been kept
 around and should be manually deleted after running revdep-rebuild.
 
 On all my sytems the transition to dev-libs/mpfr-3 was handled this
 way 

Perhaps the OP performed the latter step before performing the former?

Re: [gentoo-user] Re: checking whether the C compiler works... no Oooops !!

2011-05-06 Thread Andrea Conti


 /usr/libexec/gcc/i686-pc-linux-gnu/4.4.4/cc1: error while loading shared
 libraries: libmpfr.so.1: cannot open shared object file
 
 Meaning, run revdep-rebuild :)

Yeah, right. So revdep-rebuild does its thing, finds out that gcc is
broken and tries to rebuild it with the broken gcc :)

In this case the only way out involves backups or binary packages, or
doing a binary build of the old mpfr version on another machine with
CFLAGS compatible to those in use on the target.

What's strange however, is that AFAIK in order to avoid this kind of
breakage system ebuilds such as mpfr never delete old library versions;
they just print a warning saying that the old library  has been kept
around and should be manually deleted after running revdep-rebuild.

On all my sytems the transition to dev-libs/mpfr-3 was handled this way;
note that I am still using portage 2.1, so this has nothing to do with
the preserve feature in 2.2.

andrea

[gentoo-user] Re: checking whether the C compiler works... no Oooops !!

2011-05-06 Thread walt

On 05/06/2011 12:45 AM, Dale wrote:

 checking for i686-pc-linux-gnu-gcc... gcc
 checking whether the C compiler works... no

I know you have it fixed now, but just thought I'd mention that
you will see the same error when compiling something in a directory
where you don't have write privileges.

I doubt you'll ever see it when using emerge because portage warns
you when you try to emerge something as an ordinary user, but I run
into it occasionally when I unpack a tarball as root and then try
to compile it as me.

Re: [gentoo-user] Re: checking whether the C compiler works... no Oooops !!


Dale wrote:


On the list of things to do.  Running python-updater now will run that 
next.


Thanks.

Dale

:-)  :-)



Well, this ain't good.  Neither python-updater nor revdep-rebuild can 
complete.  Either it is a missing package or some other error.  Am I to 
the point where I have to reinstall?


I'm going to try that script from many ages ago that rebuilds after a 
gcc upgrade.  Maybe it will do something different.


Dale

:-)  :-)

P. S.  One would think a Gentoo system could sit idle for a couple 
months without this sort of mess.  :/   I could see this after many 
months or a year or longer but not a couple months.

Re: [gentoo-user] Re: checking whether the C compiler works... no Oooops !!


Albert Hopkins wrote:

On Fri, 2011-05-06 at 12:18 +0200, Andrea Conti wrote:
   

AFAIK in order to avoid this kind of
breakage system ebuilds such as mpfr never delete old library
versions;
they just print a warning saying that the old library  has been kept
around and should be manually deleted after running revdep-rebuild.

On all my sytems the transition to dev-libs/mpfr-3 was handled this
way
 

Perhaps the OP performed the latter step before performing the former?

   


I generally do my updates, run revdep-rebuild, then --depclean then 
revdep-rebuild again, in case --depclean broke something.   So far, that 
has always resulted in a clean system.  I'm not sure what happened this 
time tho.  I'm pretty sure I left it sane tho.  It certainly isn't sane 
now tho.  Neither am I right now.  lol


Dale

:-)  :-)

Re: [gentoo-user] Re: checking whether the C compiler works... no Oooops !!

2011-05-06 Thread Alex Schuster

Dale writes:

 Dale wrote:
  On the list of things to do.  Running python-updater now will run that
  next.

 Well, this ain't good.  Neither python-updater nor revdep-rebuild can
 complete.  Either it is a missing package or some other error.  Am I to
 the point where I have to reinstall?

Add the --keep-going option for emerge. Python-updater and revdep-rebuild 
then will continue after an error, and give you a list of packages that 
failed at the end. You can deal with them later.
I also suggest using -j (and --load-average=XX in EMERGE_DEFAULT_OPTS), this 
gives a nice overview of what's done and what not. 

You need to put '--' before these options for emerge so revdep-
rebuild/python-updater will not take them as their own arguments.

Wonko

Re: [gentoo-user] Re: checking whether the C compiler works... no Oooops !!


Alex Schuster wrote:

Dale writes:

   

Dale wrote:
 

On the list of things to do.  Running python-updater now will run that
next.
   
   

Well, this ain't good.  Neither python-updater nor revdep-rebuild can
complete.  Either it is a missing package or some other error.  Am I to
the point where I have to reinstall?
 

Add the --keep-going option for emerge. Python-updater and revdep-rebuild
then will continue after an error, and give you a list of packages that
failed at the end. You can deal with them later.
I also suggest using -j (and --load-average=XX in EMERGE_DEFAULT_OPTS), this
gives a nice overview of what's done and what not.

You need to put '--' before these options for emerge so revdep-
rebuild/python-updater will not take them as their own arguments.

Wonko


   


I already have --keep-going in make.conf.  Good thought tho.  Thing is, 
it errors before it even starts.  Complains about blockers and the 
packages aren't even installed to block anything.  Mostly KDE stuff too.


I'm running the script and will see what it does.  Maybe it will fix it 
since this is its purpose. Dale crosses fingers  If that doesn't work, 
I may go back to a bare system and try to start from there.  I can then 
emerge -k and see how long that takes.


Dale

:-)  :-)

[gentoo-user] Re: checking whether the C compiler works... no Oooops !!

2011-05-06 Thread Grant Edwards

On 2011-05-06, Dale rdalek1...@gmail.com wrote:

 P. S.  One would think a Gentoo system could sit idle for a couple 
 months without this sort of mess.

It depends on which couple of months you happen to pick. ;)

Most of the time a couple months is OK.  Once in a while there will
be several major updates for different packages in a short span and
for certain configurations if you don't do them incrementally stuff
breaks rather badly without some rather detailed shepherding from the
user along the way.

Still, it's nothing like the major upgrade disasters and RPM
dependency hell that I so vividly remember from my RedHat and Mandrake
days.

I specifically remember trying to upgrade from RedHat 6.x to 7.0.  It
was a complete disaster.  It turned out that even a clean install of
RH 7.0 was almost unusable, and the 7 series was really ready for
prime time until about 7.3.  That was when I gave up on RedHat -- and
I had been using RedHat since before they used version numbers (I
think I started with the Mother's Day release).

Mandrake seemd a little better, but it still had the same basic
problem: any time you wanted a package that wasn't on the base install
CD, the only viable choice was to build it from sources, because every
binary RPM that you could find always required different library
versions that what you hand installed.  When you tried to build from
source, you found out you didn't have have the devel versions of the
right libararies. If you tried to update libraries it would start a
chain-reaction of dependancy problems that didn't end until you were
standing there with a smoking gun picking bits of drive platter out of
your hair.

[gentoo-user] Re: Checking an HD for problems

2010-09-22 Thread walt


On 09/22/2010 01:26 PM, Stroller wrote:


On 22 Sep 2010, at 17:46, Grant wrote:

... I noticed some errors when I was cp -ax'ing everything
from my old drive to the new drive which were accompanied by loud
clicks.  Is there a way to do a comprehensive test/check of the old
drive to see if it has any problems?


You don't need to do a test. The disk that is making the noises is f**ked.

Assuming that it's the old drive that is knackered...


I was thinking the same.  In the past three or four years I've had more
brand new drives go bad than older ones.  Funny, though, the replacement
drives I've received under warranty work spectacularly well.  Just luck?

Re: [gentoo-user] Re: Checking an HD for problems

2010-09-22 Thread Alan McKinnon

Apparently, though unproven, at 23:00 on Wednesday 22 September 2010, walt did 
opine thusly:

 On 09/22/2010 01:26 PM, Stroller wrote:
  On 22 Sep 2010, at 17:46, Grant wrote:
  ... I noticed some errors when I was cp -ax'ing everything
  from my old drive to the new drive which were accompanied by loud
  clicks.  Is there a way to do a comprehensive test/check of the old
  drive to see if it has any problems?
  
  You don't need to do a test. The disk that is making the noises is
  f**ked.
  
  Assuming that it's the old drive that is knackered...
 
 I was thinking the same.  In the past three or four years I've had more
 brand new drives go bad than older ones.  Funny, though, the replacement
 drives I've received under warranty work spectacularly well.  Just luck?


No, not luck. It's a numbers game and that how the dice roll.

Modern drives are complex. As such they are more likely to fail than ancient 
drives simply because of the complexity. They are also better engineered than 
old ones but the loss from complexity is greater than the game from better 
engineering. Plus, they are incredibly cheap compared to ancient times.

Engineered products all have characteristic failure rates common across the 
model, the infamous bathtub curve. The factory can't do the full range of 
nurn-in tests they'd like to (bean counters rule), so you get a drive at the 
later end of the bathtub. Hence, you see elevated failure rates. The factory 
is willing to take a financial knock here as the loss from a few replacements 
is much lower than the gigantic loss from fully and properly testing every 
drive for hours and hours.

You get a replacement. Simple odds are that it is not one of the few that will 
fail early, so it doesn't and you think Wow! The gods like me. Nope, 
statistics like me.

If the factory was real smart, they would keep a small stock of fully tested 
drives on the replacement shelf, only to be released as under-warranty 
replacements. You'd be certain these drives would NOT fail and it's trivially 
easy to get this past the bean counters because you'd be winning back customer 
loyalty. And the cost of testing those few drives fully is not that much. The 
average bean counter has a ballistic orgasm at the thought of this, and yes 
they can even tell you the price they attach to winning back that loyalty.

So now you know. Accountants do not think like techies.

-- 
alan dot mckinnon at gmail dot com

[gentoo-user] Re: Checking sanity of system...

2010-04-04 Thread Nikos Chantziaras


On 04/04/2010 08:18 AM, meino.cra...@gmx.de wrote:


Hi,

this is no security issue in sense of attacks...it is related
to the consistency of the system.

Simple question (and may be complicate to answer... ;) )

How can I check, that my Gentoo system is uptodate


emerge --sync  emerge -uDN world



consistent and sane?


Define consistent and sane.  Those words don't say anything, really.

Re: [gentoo-user] Re: Checking sanity of system...

2010-04-04 Thread Dale


Nikos Chantziaras wrote:

On 04/04/2010 08:18 AM, meino.cra...@gmx.de wrote:


Hi,

this is no security issue in sense of attacks...it is related
to the consistency of the system.

Simple question (and may be complicate to answer... ;) )

How can I check, that my Gentoo system is uptodate


emerge --sync  emerge -uDN world



consistent and sane?


Define consistent and sane.  Those words don't say anything, really.





You may also want to run revdep-rebuild as well.  If you are talking 
about your packages being sane.  That should catch anything that has 
broken links or something else that leads to a package needing to be 
recompiled.


Dale

:-)  :-)

Re: [gentoo-user] Re: Checking sanity of system...

2010-04-04 Thread meino . cramer

Nikos Chantziaras rea...@arcor.de [10-04-04 08:28]:
 On 04/04/2010 08:18 AM, meino.cra...@gmx.de wrote:
 
 Hi,
 
 this is no security issue in sense of attacks...it is related
 to the consistency of the system.
 
 Simple question (and may be complicate to answer... ;) )
 
 How can I check, that my Gentoo system is uptodate
 
 emerge --sync  emerge -uDN world
 
 
 consistent and sane?
 
 Define consistent and sane.  Those words don't say anything, 
 really.
 

Ok...

Consistency: Following each logical branch of each logical tree of control 
relationship,
which is for example but not only the tree of dependancies, will end in a
leave. These are the control paths.

Sane: Following each logical branch of each logical tree of data
relationships. which is for example but not only the interaction of scripts 
under
/etc, will end in a leave. These are the data paths.

HTH

Best regards,
mcc

-- 
Please don't send me any Word- or Powerpoint-Attachments
unless it's absolutely neccessary. - Send simply Text.
See http://www.gnu.org/philosophy/no-word-attachments.html
In a world without fences and walls nobody needs gates and windows.

Re: [gentoo-user] Re: Checking sanity of system...

2010-04-04 Thread meino . cramer

Dale rdalek1...@gmail.com [10-04-04 08:36]:
 Nikos Chantziaras wrote:
 On 04/04/2010 08:18 AM, meino.cra...@gmx.de wrote:
 
 Hi,
 
 this is no security issue in sense of attacks...it is related
 to the consistency of the system.
 
 Simple question (and may be complicate to answer... ;) )
 
 How can I check, that my Gentoo system is uptodate
 
 emerge --sync  emerge -uDN world
 
 
 consistent and sane?
 
 Define consistent and sane.  Those words don't say anything, 
 really.
 
 
 
 
 You may also want to run revdep-rebuild as well.  If you are talking 
 about your packages being sane.  That should catch anything that has 
 broken links or something else that leads to a package needing to be 
 recompiled.
 
 Dale
 
 :-)  :-)
 

Hi Dale,

revdep-rebuild is currently running! :)

This was the only tool I knew before posting my question here :)

:)

Best regards,
mcc


-- 
Please don't send me any Word- or Powerpoint-Attachments
unless it's absolutely neccessary. - Send simply Text.
See http://www.gnu.org/philosophy/no-word-attachments.html
In a world without fences and walls nobody needs gates and windows.

[gentoo-user] Re: Checking sanity of system...

2010-04-04 Thread Nikos Chantziaras


On 04/04/2010 10:07 AM, meino.cra...@gmx.de wrote:

Nikos Chantziarasrea...@arcor.de  [10-04-04 08:28]:

On 04/04/2010 08:18 AM, meino.cra...@gmx.de wrote:


Hi,

this is no security issue in sense of attacks...it is related
to the consistency of the system.

Simple question (and may be complicate to answer... ;) )

How can I check, that my Gentoo system is uptodate


emerge --sync  emerge -uDN world



consistent and sane?


Define consistent and sane.  Those words don't say anything,
really.



Ok...

Consistency: Following each logical branch of each logical tree of control 
relationship,
which is for example but not only the tree of dependancies, will end in a
leave. These are the control paths.

Sane: Following each logical branch of each logical tree of data
relationships. which is for example but not only the interaction of scripts 
under
/etc, will end in a leave. These are the data paths.


These are very abstract things you speak of.  But I guess it boils down 
to are there bugs in my system.


Yes, there are.  All software has bugs.  There is a tool to check 
whether there are bugs: you.  You use the software and check whether it 
works correctly or not.


For anything more specific, you also need to be more specific with your 
questions. :)

Re: [gentoo-user] Re: Checking sanity of system...

2010-04-04 Thread Dale


meino.cra...@gmx.de wrote:

Dalerdalek1...@gmail.com  [10-04-04 08:36]:
   

Nikos Chantziaras wrote:
 

On 04/04/2010 08:18 AM, meino.cra...@gmx.de wrote:
   

Hi,

this is no security issue in sense of attacks...it is related
to the consistency of the system.

Simple question (and may be complicate to answer... ;) )

How can I check, that my Gentoo system is uptodate
 

emerge --sync  emerge -uDN world


   

consistent and sane?
 

Define consistent and sane.  Those words don't say anything,
really.



   

You may also want to run revdep-rebuild as well.  If you are talking
about your packages being sane.  That should catch anything that has
broken links or something else that leads to a package needing to be
recompiled.

Dale

:-)  :-)

 

Hi Dale,

revdep-rebuild is currently running! :)

This was the only tool I knew before posting my question here :)

:)

Best regards,
mcc

   


When I do my updates, I always do the following:

eix-sync   # This does my emerge --sync for me and updates eix since I 
use it sometimes for the FAST searches


emerge -uvDNa world   # My system is set up so that world includes 
system so this catches everything including deep dependencies (D) and 
changes of USE flags (N).


I then check USE flags and anything else that may be odd.  If I need to 
change something, I answer NO and repeat until I get it like it should 
be.  After emerge finishes:


emerge -p --depclean  # I run that about once a month or if I know 
something is unneeded and should be removed.  If it looks sane, I rerun 
without the -p.  You could use -a I guess.


revdep-rebuild -i  # This makes sure nothing is broken and I run it each 
time after the emerge world whether --depclean is ran or not.  It 
sometimes finds something broke and fixes it so I figure it is safer to 
run it and it do nothing than to not run it and something be broken.


One more optional thing to run, python-updater.  If I see python being 
updated, I run that too.  Note:  Python 3 should be popping its head up 
if it hasn't already.  If it does, do NOT switch the system to it.  A 
lot of packages do not work with it yet.  If you switch to it, you can 
keep the pieces if it breaks.  Sane thoughts did not prevail on -dev so 
you either have to mask it locally or it will be there basically doing 
nothing.  Don't ask me why they did it.  I was against the idea myself. 
 shrugs 


That's how I do it and my little rig runs pretty good.  I do have 
hiccups on occasion but everyone does eventually.


Dale

:-)  :-)

[gentoo-user] Re: checking for.....

2008-05-01 Thread reader

Alan McKinnon [EMAIL PROTECTED] writes:

 You are expecting autoconf to actually do something sane when it runs???

 Har har.
 You must be new here.

hehe... no not new... you'd never know it by the questions I ask but
I've been running linux since redhat 3 series circa 1995-6 or so.

I probably shouldn't admit it though..  It seems like there are
getting to be sharper and sharper newish users here.

Just a very slow learner... or as some have said... not the sharpest tool
in the shed.

But thinking it over a bit after the other response I can see where it
would be really difficult to cache that output I hadn't really
considered that packages may change the answers frequently.

-- 
gentoo-user@lists.gentoo.org mailing list

Re: [gentoo-user] Re: checking for XML::Parser... configure: error: XML::Parser perl module is required for intltool

2007-08-15 Thread Mick

On Monday 13 August 2007, Joseph wrote:
  On a second machine I tried:
  revdep-rebuild -X --library=libexpat.so.0
 
  it recompiles a lot of packages including subversion and apache, however
  both programs won't run because libexpat.so.0 is required somewhere. If
  I run revdep-rebuild again, only arputil will be re-emerged, however
  that doesn't help, so for the time being I'll create the symlink as I
  did on my other machine and see if that helps enough to get my server
  running again.
 
  Regards,
 
  Henk.

 I had the same problem, running:
 emerge -av XML-Parser

 helped; now I'm moving forward.

I wish I could . . .

Updated all the kde-3.5.7 packages, revdep-rebuild the libraries it asked me 
to and now when I run revdep-rebuild, it wants to downgrade all this lot:
===
All prepared. Starting rebuild...
emerge --oneshot -p -v =media-sound/vorbis-tools-1.1.1-r3 
=app-crypt/gnupg-1.4.7-r1 =kde-base/juk-3.5.5 
=media-libs/xine-lib-1.1.4-r2 =kde-base/kaudiocreator-3.5.5 
=media-video/xine-ui-0.99.5 

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

Calculating dependencies... done!
[ebuild UD] kde-base/kdelibs-3.5.5-r10 [3.5.7-r2] USE=acl alsa cups fam 
kerberos spell ssl%* 
tiff -arts -avahi -debug -doc -jpeg2k -kdeenablefinal -kdehidd
envisibility -legacyssl -lua -openexr -utempter -xinerama -zeroconf% 
(-branding%) LINGUAS=-he% 0 kB 
[ebuild   R   ] media-sound/vorbis-tools-1.1.1-r3  USE=flac nls speex 0 kB 
[ebuild   R   ] app-crypt/gnupg-1.4.7-r1  USE=bzip2 curl idea ldap nls 
readline usb zlib -bindist -ecc (-selinux) -smartcard -static 
LINGUAS=-ru 0 kB 
[ebuild   R   ] media-libs/xine-lib-1.1.4-r2  USE=X a52 aac aalib alsa dts 
dvd flac imagemagick mad mng modplug nls opengl oss sdl speex theora 
truetype vcd vidix vorbis win32codecs xv xvmc 
(-altivec) -arts -debug -directfb -dxr3 -esd -fbc
on -gnome -gtk -ipv6 -libcaca -mmap -musepack -pulseaudio -samba -v4l -wavpack 
-
xcb -xinerama 0 kB 
[ebuild   R   ] media-video/xine-ui-0.99.5  USE=X aalib curl ncurses nls 
readline -debug -libcaca -lirc -vdr -xinerama 0 kB 
[ebuild UD] kde-base/libkcddb-3.5.5 [3.5.7] 
USE=-arts -debug -kdeenablefinal -xinerama 0 kB 
[ebuild   R   ] kde-base/juk-3.5.5  USE=flac gstreamer mp3 
vorbis -akode -arts -debug -kdeenablefinal -xinerama 0 kB 
[ebuild UD] kde-base/kdemultimedia-kioslaves-3.5.5 [3.5.7] USE=encode 
flac mp3 vorbis -arts -debug -kdeenablefinal -xinerama 0 kB 
[ebuild   R   ] kde-base/kaudiocreator-3.5.5  USE=encode flac mp3 
vorbis -arts -debug -kdeenablefinal -xinerama 0 kB 

Total: 9 packages (3 downgrades, 6 reinstalls), Size of downloads: 0 kB
===

Have I missed something?  Did anyone else got this problem?
-- 
Regards,
Mick


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

Re: [gentoo-user] Re: checking for XML::Parser... configure: error: XML::Parser perl module is required for intltool

2007-08-15 Thread Naga

On Wednesday 15 August 2007 11:29:28 Mick wrote:
 On Monday 13 August 2007, Joseph wrote:
   On a second machine I tried:
   revdep-rebuild -X --library=libexpat.so.0
  
   it recompiles a lot of packages including subversion and apache,
   however both programs won't run because libexpat.so.0 is required
   somewhere. If I run revdep-rebuild again, only arputil will be
   re-emerged, however that doesn't help, so for the time being I'll
   create the symlink as I did on my other machine and see if that helps
   enough to get my server running again.
  
   Regards,
  
   Henk.
 
  I had the same problem, running:
  emerge -av XML-Parser
 
  helped; now I'm moving forward.

 I wish I could . . .

 Updated all the kde-3.5.7 packages, revdep-rebuild the libraries it asked
 me to and now when I run revdep-rebuild, it wants to downgrade all this
 lot: ===
 All prepared. Starting rebuild...
 emerge --oneshot -p -v =media-sound/vorbis-tools-1.1.1-r3
 =app-crypt/gnupg-1.4.7-r1 =kde-base/juk-3.5.5
^
 =media-libs/xine-lib-1.1.4-r2 =kde-base/kaudiocreator-3.5.5
^^
 =media-video/xine-ui-0.99.5

See the problem?

You need to upgrade some more packages (hopfully).

-- 
Naga
-- 
[EMAIL PROTECTED] mailing list

Re: [gentoo-user] Re: checking for XML::Parser... configure: error: XML::Parser perl module is required for intltool

2007-08-15 Thread Mick

On Wednesday 15 August 2007, Naga wrote:
 On Wednesday 15 August 2007 11:29:28 Mick wrote:

  =app-crypt/gnupg-1.4.7-r1 =kde-base/juk-3.5.5

 ^

  =media-libs/xine-lib-1.1.4-r2 =kde-base/kaudiocreator-3.5.5

 ^^

  =media-video/xine-ui-0.99.5

 See the problem?

 You need to upgrade some more packages (hopfully).

Thanks Naga, I should have said that a --update world did not pick these up.  
Having selectively emerged the update packages revdep rebuild is not showing 
anymore packages.
-- 
Regards,
Mick


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

Re: [gentoo-user] Re: checking for XML::Parser... configure: error: XML::Parser perl module is required for intltool

2007-08-15 Thread Neil Bothwick

On Wed, 15 Aug 2007 11:48:17 +0100, Mick wrote:

 Thanks Naga, I should have said that a --update world did not pick
 these up. 

Did you use --deep?


-- 
Neil Bothwick

It's only a hobby ... only a hobby ... only a


signature.asc
Description: PGP signature

Re: [gentoo-user] Re: checking for XML::Parser... configure: error: XML::Parser perl module is required for intltool

2007-08-15 Thread Mick

On Wednesday 15 August 2007, Neil Bothwick wrote:
 On Wed, 15 Aug 2007 11:48:17 +0100, Mick wrote:
  Thanks Naga, I should have said that a --update world did not pick
  these up.

 Did you use --deep?

# emerge -upDv world

-- 
Regards,
Mick


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

Re: [gentoo-user] Re: checking for XML::Parser... configure: error: XML::Parser perl module is required for intltool

2007-08-13 Thread Markus Schönhaber

Mark Knecht wrote:

 revdep-rebuild wanted to emerge again. I get quite tired, and frankly
 do not understand, why gcc itself should be on this list so often, 

Maybe because of this:
https://bugs.gentoo.org/show_bug.cgi?id=125728#c29

Regrads
  mks


-- 
[EMAIL PROTECTED] mailing list

Re: [gentoo-user] Re: checking for XML::Parser... configure: error: XML::Parser perl module is required for intltool

On 8/12/07, Mark Knecht [EMAIL PROTECTED] wrote:
SNIP

 I'll report back later as to the functionality of the system. It's
 still running mythbackend as this process goes on. At least it's
 helping my network do good things

 Cheers,
 Mark


Thanks to all who responded to this thread. Your help was greatly appreciated.

The machine has completed rebuilding and so far all the applications
I've tried seem to be functioning fine.

Great group of folks here! Unparalleled!

Cheers,
Mark
-- 
[EMAIL PROTECTED] mailing list

Re: [gentoo-user] Re: checking for XML::Parser... configure: error: XML::Parser perl module is required for intltool

On 8/13/07, Markus Schönhaber [EMAIL PROTECTED] wrote:
 Mark Knecht wrote:

  revdep-rebuild wanted to emerge again. I get quite tired, and frankly
  do not understand, why gcc itself should be on this list so often,

 Maybe because of this:
 https://bugs.gentoo.org/show_bug.cgi?id=125728#c29

 Regrads
   mks


Markus,
   Thanks. I tried the ~x86 version of gentoolkit and revdep-rebuild
does not generate the requirement to rebuild gcc. That's an
improvement.

Cheers,
Mark
--
[EMAIL PROTECTED] mailing list

Re: [gentoo-user] Re: checking for XML::Parser... configure: error: XML::Parser perl module is required for intltool

2007-08-13 Thread Bo Ørsted Andresen

On Monday 13 August 2007 20:35:58 Mark Knecht wrote:
   revdep-rebuild wanted to emerge again. I get quite tired, and frankly
   do not understand, why gcc itself should be on this list so often,
 
  Maybe because of this:
  https://bugs.gentoo.org/show_bug.cgi?id=125728#c29

Thanks. I tried the ~x86 version of gentoolkit and revdep-rebuild
 does not generate the requirement to rebuild gcc. That's an
 improvement.

No, it's really not.. There are several bugs open against it. I'm pretty 
convinced the latest revdep-rebuild is just broken.. 

-- 
Bo Andresen


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

Re: [gentoo-user] Re: checking for XML::Parser... configure: error: XML::Parser perl module is required for intltool

2007-08-13 Thread Denis

When I was upgrading on one of the machines, I did encounter this same
error on a couple gnome-related ebuilds (I don't actually have either
gnome or kde desktops installed - only fluxbox).  I ended up upgrading
XML-Parser, then did a revdep-rebuild, which told me to re-install
gettext, dbus, and dbus-glib.  Once those steps were done, the
packages that were giving me compile errors emerged smoothly.  In the
end, I had to also re-install audacious-plugins package.  Most of the
re-installs were due to expat lib as well.

However, on my other machine, the upgrade of the same packages was
seamless, and the list of packages to upgrade were somewhat different,
although the two machines are configured pretty much identically.

The only difference I could see is that my work machine has a
different default RSYNC mirror selected than the one at home.  Could
some of the packages have been out of sync on the different mirrors
and cause this messy upgrade procedure to happen on some machines?
-- 
[EMAIL PROTECTED] mailing list

Re: [gentoo-user] Re: checking for XML::Parser... configure: error: XML::Parser perl module is required for intltool

On 8/13/07, Bo Ørsted Andresen [EMAIL PROTECTED] wrote:
 On Monday 13 August 2007 20:35:58 Mark Knecht wrote:
revdep-rebuild wanted to emerge again. I get quite tired, and frankly
do not understand, why gcc itself should be on this list so often,
  
   Maybe because of this:
   https://bugs.gentoo.org/show_bug.cgi?id=125728#c29
 
 Thanks. I tried the ~x86 version of gentoolkit and revdep-rebuild
  does not generate the requirement to rebuild gcc. That's an
  improvement.

 No, it's really not.. There are several bugs open against it. I'm pretty
 convinced the latest revdep-rebuild is just broken..


Well, you know better than I do Bo. All I'm saying is that for this
problem I was not required to rebuild gvv for the 4th time in 3 days.

I could always use the stable version and then delete gcc from the
list of things to build. That would work also. However both ways leave
a dummy like me not knowing if my machine is correctly configured and
rebuilding gcc over and over again uses so much time and system power
that it gets in the way of really using the machine.

Anyway, thanks for the comments.

- Mark
--
[EMAIL PROTECTED] mailing list

Re: [gentoo-user] Re: checking for XML::Parser... configure: error: XML::Parser perl module is required for intltool

2007-08-13 Thread Bo Ørsted Andresen

On Monday 13 August 2007 21:47:05 Mark Knecht wrote:
Maybe because of this:
https://bugs.gentoo.org/show_bug.cgi?id=125728#c29
  
  Thanks. I tried the ~x86 version of gentoolkit and revdep-rebuild
   does not generate the requirement to rebuild gcc. That's an
   improvement.
 
  No, it's really not.. There are several bugs open against it. I'm pretty
  convinced the latest revdep-rebuild is just broken..

 Well, you know better than I do Bo. All I'm saying is that for this
 problem I was not required to rebuild gvv for the 4th time in 3 days.

 I could always use the stable version and then delete gcc from the
 list of things to build. That would work also. However both ways leave
 a dummy like me not knowing if my machine is correctly configured and
 rebuilding gcc over and over again uses so much time and system power
 that it gets in the way of really using the machine.

Or you could read the link to bugs.gentoo.org in the top of this mail. Or post 
the output from the stable version of revdep-rebuild --ignore.

-- 
Bo Andresen


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

Re: [gentoo-user] Re: checking for XML::Parser... configure: error: XML::Parser perl module is required for intltool

On 8/13/07, Bo Ørsted Andresen [EMAIL PROTECTED] wrote:
 On Monday 13 August 2007 21:47:05 Mark Knecht wrote:
 Maybe because of this:
 https://bugs.gentoo.org/show_bug.cgi?id=125728#c29
   
   Thanks. I tried the ~x86 version of gentoolkit and revdep-rebuild
does not generate the requirement to rebuild gcc. That's an
improvement.
  
   No, it's really not.. There are several bugs open against it. I'm pretty
   convinced the latest revdep-rebuild is just broken..
 
  Well, you know better than I do Bo. All I'm saying is that for this
  problem I was not required to rebuild gvv for the 4th time in 3 days.
 
  I could always use the stable version and then delete gcc from the
  list of things to build. That would work also. However both ways leave
  a dummy like me not knowing if my machine is correctly configured and
  rebuilding gcc over and over again uses so much time and system power
  that it gets in the way of really using the machine.

 Or you could read the link to bugs.gentoo.org in the top of this mail. Or post
 the output from the stable version of revdep-rebuild --ignore.


I did read it. It seemed that the stable revdep-rebuild solution was
to start editing system files. I didn't want to do that as I don't
know what they do. (Please remember, I am a DUMMY. I am NOT a computer
scientist, a sys admin or a programmer. I used to design chips and now
play music and trade stocks and options. I don't use ~x86 except when
I have a reason. I suspect I'll just go back to stable and join the
hordes looking for a fix to the stable version of revdep-rebuild.)

Anyway, thanks for the help.

Cheers,
Mark
--
[EMAIL PROTECTED] mailing list

Re: [gentoo-user] Re: checking for XML::Parser... configure: error: XML::Parser perl module is required for intltool

2007-08-13 Thread Bo Ørsted Andresen

On Monday 13 August 2007 22:54:59 Mark Knecht wrote:
  Maybe because of this:
  https://bugs.gentoo.org/show_bug.cgi?id=125728#c29
[SNIP]
  Or you could read the link to bugs.gentoo.org in the top of this mail. Or
  post the output from the stable version of revdep-rebuild --ignore.

 I did read it. It seemed that the stable revdep-rebuild solution was
 to start editing system files. I didn't want to do that as I don't
 know what they do. (Please remember, I am a DUMMY. I am NOT a computer
 scientist, a sys admin or a programmer. I used to design chips and now
 play music and trade stocks and options. I don't use ~x86 except when
 I have a reason. I suspect I'll just go back to stable and join the
 hordes looking for a fix to the stable version of revdep-rebuild.)

No no no. It's gcc with the gcj use flag that's broken. The stable version of 
revdep-rebuild is just showing you already existing breakage in gcc (or 
inconsistency if you will). Editing those .la files or creating those 
symlinks are proper solutions. Another solution if you don't need gcj anyway 
is to disable that use flag..

-- 
Bo Andresen


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

Re: [gentoo-user] Re: checking for XML::Parser... configure: error: XML::Parser perl module is required for intltool

On 8/13/07, Bo Ørsted Andresen [EMAIL PROTECTED] wrote:
 On Monday 13 August 2007 22:54:59 Mark Knecht wrote:
   Maybe because of this:
   https://bugs.gentoo.org/show_bug.cgi?id=125728#c29
 [SNIP]
   Or you could read the link to bugs.gentoo.org in the top of this mail. Or
   post the output from the stable version of revdep-rebuild --ignore.
 
  I did read it. It seemed that the stable revdep-rebuild solution was
  to start editing system files. I didn't want to do that as I don't
  know what they do. (Please remember, I am a DUMMY. I am NOT a computer
  scientist, a sys admin or a programmer. I used to design chips and now
  play music and trade stocks and options. I don't use ~x86 except when
  I have a reason. I suspect I'll just go back to stable and join the
  hordes looking for a fix to the stable version of revdep-rebuild.)

 No no no. It's gcc with the gcj use flag that's broken. The stable version of
 revdep-rebuild is just showing you already existing breakage in gcc (or
 inconsistency if you will). Editing those .la files or creating those
 symlinks are proper solutions. Another solution if you don't need gcj anyway
 is to disable that use flag..


Ah, OK, that's different. I looked up the gcj flag and got this:

gcj Enable building with gcj (The GNU Compiler for the Javatm
Programming Language)

I don't know if I *need* it. I don't know how I would tell if I'm even
using it today. Is thee some way for me to test whether I've ever
compiled Java code with with gcc? I personally would guess that I
haven't as it sounds like something you'd know if you were doing, but
possibly portage builds something this way that I'm not aware of?

Anyway, I don't *think* I need it so I'm happy to turn off the flag
and test how things work with the stable version of gentoolkit.

Thanks in advance,
Mark
--
[EMAIL PROTECTED] mailing list

Re: [gentoo-user] Re: checking for XML::Parser... configure: error: XML::Parser perl module is required for intltool

2007-08-13 Thread Joseph

 On a second machine I tried:
 revdep-rebuild -X --library=libexpat.so.0
 
 it recompiles a lot of packages including subversion and apache, however 
 both programs won't run because libexpat.so.0 is required somewhere. If 
 I run revdep-rebuild again, only arputil will be re-emerged, however 
 that doesn't help, so for the time being I'll create the symlink as I 
 did on my other machine and see if that helps enough to get my server 
 running again.
 
 Regards,
 
 Henk.

I had the same problem, running:
emerge -av XML-Parser

helped; now I'm moving forward.

-- 
#Joseph
-- 
[EMAIL PROTECTED] mailing list

Re: [gentoo-user] Re: checking for XML::Parser... configure: error: XML::Parser perl module is required for intltool

2007-08-12 Thread Shawn Haggett


Sven Köhler wrote:

   emerge gnome fails. Does anyone recognize what portage is
complaining about here?

I'm not really sure, but I solved it by reemerging dev-perl/XML-Parser.


expat has been updated. Some Apps are now broken. They have to
recompiled to link against the new libexpat.

For me, it was gettext and XML-Parser that had to be re-emerged. Without
it, emerging gnome failed.



Same here. Remerged dev-perl/XML-Parser, then my update world failed at 
a different point complaining about gettext, remerged that and now the 
update world is compiling normally.

--
[EMAIL PROTECTED] mailing list

Re: [gentoo-user] Re: checking for XML::Parser... configure: error: XML::Parser perl module is required for intltool

Shawn Haggett wrote:

 Same here. Remerged dev-perl/XML-Parser, then my update world failed
 at a different point complaining about gettext, remerged that and now
 the update world is compiling normally.

Same here on both problems.  Is this a bug since several have ran into
this?  Also, I have some Gnome stuff as a dependency but I use KDE. 

Dale

:-)  :-) 
-- 
[EMAIL PROTECTED] mailing list

Re: [gentoo-user] Re: checking for XML::Parser... configure: error: XML::Parser perl module is required for intltool

2007-08-12 Thread Naga

On Sunday 12 August 2007 11:39:43 Dale wrote:
 Same here on both problems.  Is this a bug since several have ran into
 this?  Also, I have some Gnome stuff as a dependency but I use KDE.

From the ebuild
ewarn Please note that the soname of the library changed!
ewarn If you are upgrading from a previous version you need
ewarn to fix dynamic linking inconsistencies by executing:
ewarn revdep-rebuild -X --library libexpat.so.0

-- 
Naga
--
[EMAIL PROTECTED] mailing list

Re: [gentoo-user] Re: checking for XML::Parser... configure: error: XML::Parser perl module is required for intltool

Naga wrote:
 On Sunday 12 August 2007 11:39:43 Dale wrote:
   
 Same here on both problems.  Is this a bug since several have ran into
 this?  Also, I have some Gnome stuff as a dependency but I use KDE.
 

 From the ebuild
 ewarn Please note that the soname of the library changed!
 ewarn If you are upgrading from a previous version you need
 ewarn to fix dynamic linking inconsistencies by executing:
 ewarn revdep-rebuild -X --library libexpat.so.0

   

I saw that too.  On mine, it didn't fix anything that I could see.  Here
is what mine did:

[EMAIL PROTECTED] / # revdep-rebuild --library libintl.so.7
Configuring search environment for revdep-rebuild

Checking reverse dependencies...

Packages containing binaries and libraries using libintl.so.7
will be emerged.

Collecting system binaries and libraries... done.
  (/root/.revdep-rebuild.1_files)

Checking dynamic linking...
 done.
  (/root/.revdep-rebuild_f93d0f1b.3_rebuild)

Assigning files to ebuilds... Nothing to rebuild

Evaluating package order... done.
  (/root/.revdep-rebuild_f93d0f1b.5_order)

There are no dynamic links to libintl.so.7... All done.
[EMAIL PROTECTED] / #

It appears that nothing was really done so shouldn't it have worked?  I
dunno, just sounds weird to me.

Dale

Re: [gentoo-user] Re: checking for XML::Parser... configure: error: XML::Parser perl module is required for intltool

2007-08-12 Thread Allan Gottlieb

You used the wrong lib in the revdep-rebuild (see below)

At Sun, 12 Aug 2007 06:18:02 -0500 Dale [EMAIL PROTECTED] wrote:

 Naga wrote:
 On Sunday 12 August 2007 11:39:43 Dale wrote:
   
 Same here on both problems.  Is this a bug since several have ran into
 this?  Also, I have some Gnome stuff as a dependency but I use KDE.
 

 From the ebuild
 ewarn Please note that the soname of the library changed!
 ewarn If you are upgrading from a previous version you need
 ewarn to fix dynamic linking inconsistencies by executing:
 ewarn revdep-rebuild -X --library libexpat.so.0

  ^

 I saw that too.  On mine, it didn't fix anything that I could see.  Here
 is what mine did:

 [EMAIL PROTECTED] / # revdep-rebuild --library libintl.so.7

   

allan
-- 
[EMAIL PROTECTED] mailing list

Re: [gentoo-user] Re: checking for XML::Parser... configure: error: XML::Parser perl module is required for intltool

2007-08-12 Thread Bo Ørsted Andresen

On Sunday 12 August 2007 13:18:02 Dale wrote:
  ewarn revdep-rebuild -X --library libexpat.so.0

 I saw that too.  On mine, it didn't fix anything that I could see.  Here
 is what mine did:

 [EMAIL PROTECTED] / # revdep-rebuild --library libintl.so.7

Maybe that would be because very few packages linked against libintl.so from 
gettext (which doesn't even exist in recent versions of gettext) whereas 
virtually everything links against libexpat.

It's worth noting that expat-2 has been in testing for over a year now but it 
was only stabled in the last few days. Hence the expat breakage at the moment 
only affects users of stable (which finally makes it a *LOT* less painful to 
switch between stable and testing)...

-- 
Bo Andresen


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

Re: [gentoo-user] Re: checking for XML::Parser... configure: error: XML::Parser perl module is required for intltool

2007-08-12 Thread Philip Webb

070812 Bo ??rsted Andresen wrote:
 Expat-2 has been in testing for over a year now
 but it was only stabled in the last few days.

I never do 'emerge world' (without 'Dup' for listing):
I do 'eix-sync', look at the output  update packages individually.

After updating Expat , Revdep-rebuild told me to remerge  15  packages:

  gettext XML-Parser dbus dbus-glib kdialog kcminit kreadconfig kdiff3
  krename mlterm xclock hal epiphany ghostscript-esp openoffice

 indeed Epiphany  OpenOffice wouldn't start without remerging.
I've done the former  will do OO while asleep later today.
Dillo  Gwenview also needed remerging after doing Dbus.

So it seems the answer is just to remerge whatever fails to open.
My count is  61  packages altogether today (wry smile),
incl many which have updates, but are not related to the Expat problem.

-- 
,,
SUPPORT ___//___,  Philip Webb : [EMAIL PROTECTED]
ELECTRIC   /] [] [] [] [] []|  Centre for Urban  Community Studies
TRANSIT`-O--O---'  University of Toronto
-- 
[EMAIL PROTECTED] mailing list

Re: [gentoo-user] Re: checking for XML::Parser... configure: error: XML::Parser perl module is required for intltool

2007-08-12 Thread Allan Gottlieb

At Sun, 12 Aug 2007 18:46:28 +0930 Shawn Haggett [EMAIL PROTECTED] wrote:

Sven Köhler wrote:
emerge gnome fails. Does anyone recognize what portage is
complaining about here?
I'm not really sure, but I solved it by reemerging dev-perl/XML-Parser.

expat has been updated. Some Apps are now broken. They have to
recompiled to link against the new libexpat.

For me, it was gettext and XML-Parser that had to be re-emerged. Without
it, emerging gnome failed.

Same here. Remerged dev-perl/XML-Parser, then my update world failed
at a different point complaining about gettext, remerged that and now
the update world is compiling normally.

My situation seems to be a little more difficult and I would
appreciate some advice/help.

I, like others, hit the expat problem and as directed did

revdep-rebuild -X --library libexpat.so.0

gettext failed to compile since emacs could not be run (libexpat
problem). This I fixed by emerging gettext with USE='-emacs'.

But now

USE='-emacs' revdep-rebuild -X --library libexpat.so.0

fails.

It attempts to emerge x11-libs/gtk+-2.10.13 but that needs pango

checking Pango flags... -DPNG_NO_MMX_CODE -I/usr/include/pango-1.0
-I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/cairo
-I/usr/include/freetype2 -I/usr/include/libpng12 -lpangocairo-1.0 -lpango-1.0
-lcairo -lgobject-2.0 -lgmodule-2.0 -ldl -lglib-2.0
configure: error:
*** Can't link to Pango. Pango is required to build
*** GTK+. For more information see http://www.pango.org

Pango fails to emerge with the expat problem
(/mnt/a/portage/tmp/portage/x11-libs/pango-1.16.4/work/pango-1.16.4/pango/.libs/lt-pango-querymodules:
error while loading shared libraries: libexpat.so.0: cannot open shared object
file: No such file or directory)

Thanks in advance for any help.

allan
--
[EMAIL PROTECTED] mailing list

Re: [gentoo-user] Re: checking for XML::Parser... configure: error: XML::Parser perl module is required for intltool

2007-08-12 Thread Bo Ørsted Andresen

On Sunday 12 August 2007 16:33:59 Allan Gottlieb wrote:
 I, like others, hit the expat problem and as directed did

revdep-rebuild -X --library libexpat.so.0

 gettext failed to compile since emacs could not be run (libexpat
 problem).  This I fixed by emerging gettext with USE='-emacs'.

Good.

[SNIP]
 It attempts to emerge x11-libs/gtk+-2.10.13 but that needs pango
[SNIP]
 Pango fails to emerge with the expat problem
 (/mnt/a/portage/tmp/portage/x11-libs/pango-1.16.4/work/pango-1.16.4/pango/.
libs/lt-pango-querymodules: error while loading shared libraries:
 libexpat.so.0: cannot open shared object file: No such file or directory)

pango may need glib and certainly needs cairo (in that order). If you need 
more help than that post the full list of remaining packages that 
revdep-rebuild --ignore lists as broken.

-- 
Bo Andresen


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

Re: [gentoo-user] Re: checking for XML::Parser... configure: error: XML::Parser perl module is required for intltool

2007-08-12 Thread Michael Niggli

Allan Gottlieb wrote:
At Sun, 12 Aug 2007 18:46:28 +0930 Shawn Haggett [EMAIL PROTECTED] wrote:
My situation seems to be a little more difficult and I would
appreciate some advice/help.

I, like others, hit the expat problem and as directed did

revdep-rebuild -X --library libexpat.so.0

gettext failed to compile since emacs could not be run (libexpat
problem). This I fixed by emerging gettext with USE='-emacs'.

But now

USE='-emacs' revdep-rebuild -X --library libexpat.so.0

fails.

It attempts to emerge x11-libs/gtk+-2.10.13 but that needs pango

checking Pango flags... -DPNG_NO_MMX_CODE -I/usr/include/pango-1.0
-I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/cairo
-I/usr/include/freetype2 -I/usr/include/libpng12 -lpangocairo-1.0
-lpango-1.0 -lcairo -lgobject-2.0 -lgmodule-2.0 -ldl -lglib-2.0
configure: error:
*** Can't link to Pango. Pango is required to build
*** GTK+. For more information see http://www.pango.org

Thanks in advance for any help.

allan

Pango needs fontconfig, which you'll have to rebuild, too...
There's a thread related to the expat update in the gentoo forums:
https://forums.gentoo.org/viewtopic-t-448550-postdays-0-postorder-asc-start-0.html
It seems to me the problem is still the same as it was back then.. Which
leaves me recompiling most of my system :(

I hope the link helps :)

Michael
--
[EMAIL PROTECTED] mailing list

Re: [gentoo-user] Re: checking for XML::Parser... configure: error: XML::Parser perl module is required for intltool

Allan Gottlieb wrote:
 You used the wrong lib in the revdep-rebuild (see below)

 At Sun, 12 Aug 2007 06:18:02 -0500 Dale [EMAIL PROTECTED] wrote:

   
 Naga wrote:
 
 On Sunday 12 August 2007 11:39:43 Dale wrote:
   
   
 Same here on both problems.  Is this a bug since several have ran into
 this?  Also, I have some Gnome stuff as a dependency but I use KDE.
 
 
 From the ebuild
 ewarn Please note that the soname of the library changed!
 ewarn If you are upgrading from a previous version you need
 ewarn to fix dynamic linking inconsistencies by executing:
 ewarn revdep-rebuild -X --library libexpat.so.0
   

   ^
   
 I saw that too.  On mine, it didn't fix anything that I could see.  Here
 is what mine did:

 [EMAIL PROTECTED] / # revdep-rebuild --library libintl.so.7
 



 allan
   

I copied the command from what I was given by portage.  I did the emerge
in Konsole and I used the copy and paste function to enter that
command.  It appears that something is different between our systems or
something. 

Weird again.

Dale

:-)  :-)

Re: [gentoo-user] Re: checking for XML::Parser... configure: error: XML::Parser perl module is required for intltool

2007-08-12 Thread Naga Toro

On Sunday 12 August 2007 18.50.24 Dale wrote:
 I copied the command from what I was given by portage.  I did the emerge
 in Konsole and I used the copy and paste function to enter that
 command.  It appears that something is different between our systems or
 something.

 Weird again.

Not at all you did the copy/paste from gettext not from expat.
-- 
[EMAIL PROTECTED] mailing list

Re: [gentoo-user] Re: checking for XML::Parser... configure: error: XML::Parser perl module is required for intltool

2007-08-12 Thread Mark Knecht

On 8/12/07, Naga [EMAIL PROTECTED] wrote:
 On Sunday 12 August 2007 11:39:43 Dale wrote:
  Same here on both problems.  Is this a bug since several have ran into
  this?  Also, I have some Gnome stuff as a dependency but I use KDE.

 From the ebuild
 ewarn Please note that the soname of the library changed!
 ewarn If you are upgrading from a previous version you need
 ewarn to fix dynamic linking inconsistencies by executing:
 ewarn revdep-rebuild -X --library libexpat.so.0

 --
 Naga

Thanks to all that answered. I ran the command:

revdep-rebuild -X --library libexpat.so.0

which rebuilt 22 packages. When finished I started the emerge -DuN
gnome operation which got past the problems in the title of this
thread and is not on package 15 or 56 so things are proceeding.

I suspect I will probably want to do a revdep-rebuild on the whole
machine when all of this is behind me and clean up any other problems
left hanging around.

Cheers,
Mark
-- 
[EMAIL PROTECTED] mailing list

Re: [gentoo-user] Re: checking for XML::Parser... configure: error: XML::Parser perl module is required for intltool

2007-08-12 Thread henkg

On Sun, Aug 12, 2007 at 04:39:43AM -0500, Dale wrote:
 Shawn Haggett wrote:
 
  Same here. Remerged dev-perl/XML-Parser, then my update world failed
  at a different point complaining about gettext, remerged that and now
  the update world is compiling normally.
 
 Same here on both problems.  Is this a bug since several have ran into
 this?  Also, I have some Gnome stuff as a dependency but I use KDE. 
 
 Dale
And another problem I had was with svn unable to find libexpat.so.0. 
emerging expat and subversion didn't help, so the only solution I could 
find was to to create an extra symlink for this.

Henk.
-- 
[EMAIL PROTECTED] mailing list

Re: [gentoo-user] Re: checking for XML::Parser... configure: error: XML::Parser perl module is required for intltool