[gentoo-user] F77 Provided through /etc/portage/env/*

2008-02-22 Thread justin

Hi all!

I have a little nasty problem. I am using a couple of fortran progs and not
all are happy with ifort but some benefit allot of its use. As I am lazy
and dont want to change my make.conf all the time I provided the F77, FC
and FLAGS for those packages which support ifort through
/etc/portage/env/categorie/package. This worked for a long time, but
now some thing has changed and I dont know what. The variables are still
passed to the emerge but the F77 and FC isnt used by emake any more. See
following example: ifort is chosen by the fortran.eclass and configure uses
it as well. But in the make part only the ifort spezific FFLAGS are use
together with gfortran.

 Emerging (1 of 1) sci-chemistry/shelx-20060317 to /
 * shelx-20060317.tgz RMD160 SHA1 SHA256 size ;-) ...  
  [ ok ]
 * checking ebuild checksums ;-) ...   
  [ ok ]
 * checking auxfile checksums ;-) ...  
  [ ok ]
 * checking miscfile checksums ;-) ... 
  [ ok ]
 * checking shelx-20060317.tgz ;-) ... 
  [ ok ]
 * You need one of these Fortran Compilers: ifc gfortran
 * Installed are:  ifort gfortran
 * Using ifort
 Unpacking source...
 Unpacking shelx-20060317.tgz to
/var/tmp/portage/sci-chemistry/shelx-20060317/work
 * Applying 20060317-autotool.patch ...
  [ ok ]
 * Applying 20060317-gfortran.patch ...
  [ ok ]
 * Running eautoreconf in
'/var/tmp/portage/sci-chemistry/shelx-20060317/work/unix' ...
 * Running aclocal ... 
  [ ok ]
 * Running autoconf ...
  [ ok ]
 * Running automake --add-missing --copy --foreign ... 
  [ ok ]
 Source unpacked.
 Compiling source in
/var/tmp/portage/sci-chemistry/shelx-20060317/work/unix ...
./configure --prefix=/usr --host=i686-pc-linux-gnu --mandir=/usr/share/man
--infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc
--localstatedir=/var/lib FC=ifort --build=i686-pc-linux-gnu
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking for i686-pc-linux-gnu-gfortran... ifort
checking for Fortran compiler default output file name... a.out
checking whether the Fortran compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables... 
checking for suffix of object files... o
checking whether we are using the GNU Fortran compiler... no
checking whether ifort accepts -g... yes
checking for i686-pc-linux-gnu-g77... no
checking for i686-pc-linux-gnu-xlf... no
checking for i686-pc-linux-gnu-f77... no
checking for i686-pc-linux-gnu-frt... no
checking for i686-pc-linux-gnu-pgf77... no
checking for i686-pc-linux-gnu-cf77... no
checking for i686-pc-linux-gnu-fort77... no
checking for i686-pc-linux-gnu-fl32... no
checking for i686-pc-linux-gnu-af77... no
checking for i686-pc-linux-gnu-xlf90... no
checking for i686-pc-linux-gnu-f90... no
checking for i686-pc-linux-gnu-pgf90... no
checking for i686-pc-linux-gnu-pghpf... no
checking for i686-pc-linux-gnu-epcf90... no
checking for i686-pc-linux-gnu-gfortran... i686-pc-linux-gnu-gfortran
checking whether we are using the GNU Fortran 77 compiler... no
checking whether i686-pc-linux-gnu-gfortran accepts -g... yes
configure: creating ./config.status
config.status: creating Makefile
i686-pc-linux-gnu-gfortran  -O3 -march=prescott -openmp -parallel -c -o
ciftab.o ciftab.f
i686-pc-linux-gnu-gfortran: unrecognized option '-parallel'
i686-pc-linux-gnu-gfortran  -O3 -march=prescott -openmp -parallel -c -o
shelxa.o shelxa.f
i686-pc-linux-gnu-gfortran  -O3 -march=prescott -openmp -parallel -c -o
shelxc.o shelxc.f
i686-pc-linux-gnu-gfortran: unrecognized option '-parallel'
i686-pc-linux-gnu-gfortran  -O3 -march=prescott -openmp -parallel -c -o
shelxd.o shelxd.f
i686-pc-linux-gnu-gfortran: unrecognized option '-parallel'


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



[gentoo-user] Kernel upgrade broke NAT

2008-02-22 Thread Grant
I upgraded my router's kernel from linux-2.6.18-hardened-r6 to
linux-2.6.23-hardened-r7 and now I get errors when starting the
firewall:

requires NAT which is disabled

ERROR: Command /sbin/iptables -A FORWARD -m state --state
ESTABLISHED,RELATED -j ACCEPT Failed

I used make oldconfig carefully to update the config.  I've been back
over the current config carefully but I don't see what went wrong.
Does anyone have any ideas?

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



Re: [gentoo-user] Kernel upgrade broke NAT

2008-02-22 Thread Rumen Yotov
On (22/02/08 06:37) Grant wrote:
 I upgraded my router's kernel from linux-2.6.18-hardened-r6 to
 linux-2.6.23-hardened-r7 and now I get errors when starting the
 firewall:
 
 requires NAT which is disabled
 
 ERROR: Command /sbin/iptables -A FORWARD -m state --state
 ESTABLISHED,RELATED -j ACCEPT Failed
 
 I used make oldconfig carefully to update the config.  I've been back
 over the current config carefully but I don't see what went wrong.
 Does anyone have any ideas?
 
 - Grant
 -- 
 gentoo-user@lists.gentoo.org mailing list

Hi,

Too bad that 'oldconfig' isn't always working :-(
Specially from something 2.6.17-18 to  20.
Manually check your kernel config (enable NAT etc)
IIRC the netwoking sections moved, so much stuff is disabled by default.
Also recompile iptables, just to be on the safe side.
HTH. Rumen


pgprknH3jeN8T.pgp
Description: PGP signature


Re: [gentoo-user] Kernel upgrade broke NAT

2008-02-22 Thread Grant
   I upgraded my router's kernel from linux-2.6.18-hardened-r6 to
   linux-2.6.23-hardened-r7 and now I get errors when starting the
   firewall:
  
   requires NAT which is disabled
  
   ERROR: Command /sbin/iptables -A FORWARD -m state --state
   ESTABLISHED,RELATED -j ACCEPT Failed
  
   I used make oldconfig carefully to update the config.  I've been back
   over the current config carefully but I don't see what went wrong.
   Does anyone have any ideas?
  
   - Grant
   --
   gentoo-user@lists.gentoo.org mailing list
  
  Hi,

  Too bad that 'oldconfig' isn't always working :-(

Is there a better way to update the config for a new kernel?

  Specially from something 2.6.17-18 to  20.
  Manually check your kernel config (enable NAT etc)
  IIRC the netwoking sections moved, so much stuff is disabled by default.
  Also recompile iptables, just to be on the safe side.
  HTH. Rumen

Looks like I got it, thank you.

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



Re: [gentoo-user] F77 Provided through /etc/portage/env/*

2008-02-22 Thread Andrey Falko
On Fri, Feb 22, 2008 at 3:56 AM,  [EMAIL PROTECTED] wrote:

  Hi all!

  I have a little nasty problem. I am using a couple of fortran progs and not
  all are happy with ifort but some benefit allot of its use. As I am lazy
  and dont want to change my make.conf all the time I provided the F77, FC
  and FLAGS for those packages which support ifort through
  /etc/portage/env/categorie/package. This worked for a long time, but
  now some thing has changed and I dont know what. The variables are still
  passed to the emerge but the F77 and FC isnt used by emake any more. See
  following example: ifort is chosen by the fortran.eclass and configure uses
  it as well. But in the make part only the ifort spezific FFLAGS are use
  together with gfortran.

What version of portage is this? emerge --info? It is possible that
there might be a regression between portage versions. If you've
updated portage recently, try downgrading by masking the current
version in /etc/portage/package.mask.

   Emerging (1 of 1) sci-chemistry/shelx-20060317 to /
   * shelx-20060317.tgz RMD160 SHA1 SHA256 size ;-) ...
   [ ok ]
   * checking ebuild checksums ;-) ...
   [ ok ]
   * checking auxfile checksums ;-) ...
   [ ok ]
   * checking miscfile checksums ;-) ...
   [ ok ]
   * checking shelx-20060317.tgz ;-) ...
   [ ok ]
   * You need one of these Fortran Compilers: ifc gfortran
   * Installed are:  ifort gfortran
   * Using ifort
   Unpacking source...
   Unpacking shelx-20060317.tgz to
  /var/tmp/portage/sci-chemistry/shelx-20060317/work
   * Applying 20060317-autotool.patch ...
   [ ok ]
   * Applying 20060317-gfortran.patch ...
   [ ok ]
   * Running eautoreconf in
  '/var/tmp/portage/sci-chemistry/shelx-20060317/work/unix' ...
   * Running aclocal ...
   [ ok ]
   * Running autoconf ...
   [ ok ]
   * Running automake --add-missing --copy --foreign ...
   [ ok ]
   Source unpacked.
   Compiling source in
  /var/tmp/portage/sci-chemistry/shelx-20060317/work/unix ...
  ./configure --prefix=/usr --host=i686-pc-linux-gnu --mandir=/usr/share/man
  --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc
  --localstatedir=/var/lib FC=ifort --build=i686-pc-linux-gnu
  checking for a BSD-compatible install... /usr/bin/install -c
  checking whether build environment is sane... yes
  checking for a thread-safe mkdir -p... /bin/mkdir -p
  checking for gawk... gawk
  checking whether make sets $(MAKE)... yes
  checking for i686-pc-linux-gnu-gfortran... ifort
  checking for Fortran compiler default output file name... a.out
  checking whether the Fortran compiler works... yes
  checking whether we are cross compiling... no
  checking for suffix of executables...
  checking for suffix of object files... o
  checking whether we are using the GNU Fortran compiler... no
  checking whether ifort accepts -g... yes
  checking for i686-pc-linux-gnu-g77... no
  checking for i686-pc-linux-gnu-xlf... no
  checking for i686-pc-linux-gnu-f77... no
  checking for i686-pc-linux-gnu-frt... no
  checking for i686-pc-linux-gnu-pgf77... no
  checking for i686-pc-linux-gnu-cf77... no
  checking for i686-pc-linux-gnu-fort77... no
  checking for i686-pc-linux-gnu-fl32... no
  checking for i686-pc-linux-gnu-af77... no
  checking for i686-pc-linux-gnu-xlf90... no
  checking for i686-pc-linux-gnu-f90... no
  checking for i686-pc-linux-gnu-pgf90... no
  checking for i686-pc-linux-gnu-pghpf... no
  checking for i686-pc-linux-gnu-epcf90... no
  checking for i686-pc-linux-gnu-gfortran... i686-pc-linux-gnu-gfortran
  checking whether we are using the GNU Fortran 77 compiler... no
  checking whether i686-pc-linux-gnu-gfortran accepts -g... yes
  configure: creating ./config.status
  config.status: creating Makefile
  i686-pc-linux-gnu-gfortran  -O3 -march=prescott -openmp -parallel -c -o
  ciftab.o ciftab.f
  i686-pc-linux-gnu-gfortran: unrecognized option '-parallel'
  i686-pc-linux-gnu-gfortran  -O3 -march=prescott -openmp -parallel -c -o
  shelxa.o shelxa.f
  i686-pc-linux-gnu-gfortran  -O3 -march=prescott -openmp -parallel -c -o
  shelxc.o shelxc.f
  i686-pc-linux-gnu-gfortran: unrecognized option '-parallel'
  i686-pc-linux-gnu-gfortran  -O3 -march=prescott -openmp -parallel -c -o
  shelxd.o shelxd.f
  i686-pc-linux-gnu-gfortran: unrecognized option '-parallel'


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


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



What is LD_LIBRARY_PATH? (Was Re: [gentoo-user] OpenOffice 2.3.1 Won't Start As User)

2008-02-22 Thread Drew Tomlinson

Philip Webb wrote:

080221 Drew Tomlinson wrote:
  

I emerged OpenOffice 2.3.1 on my amd64 install running gentoo-2.6.23-r5.
I can start OpenOffice as root but not as a regular user.



How are you starting it ?  Do you enter eg 'oocalc' from a CLI
or do you click on an icon in a start menu ?  If the latter,
check that the menu is using the correct command (eg use Kmenuedit).
If the former, are there any error messages ?
  


I have started it both ways as a user.  As root, I start from the CLI 
after su to root from my user login.


There are no error messages.  When starting as a user, the splash 
graphic just sits there and the CPU usage is basically 100% for both X 
and oosplash.bin.  When starting as root, the splash graphic starts and 
then a progress bar at the bottom of the splash graphic progresses in 
about 10 seconds and OpenOffice starts.  The progress bar never 
progresses when starting as a user.  I have to kill oosplash.bin with 
signal 15 after starting as a user to return my system to normal.


Some more Googling turned up this post:

http://forums.gentoo.org/viewtopic-t-623771-postdays-0-postorder-asc-start-25.html?sid=1514fa8e48f6a12a86c6c66e920161e9

I found that when I su to root, LD_LIBRARY_PATH is not defined.  As a 
user, it is defined as:


LD_LIBRARY_PATH=/usr/lib32/xorg:/usr/lib64/xorg

If I unset LD_LIBRARY_PATH in a user terminal, then OpenOffice starts.  
So what is LD_LIBRARY_PATH and why am I seeing this behavior?


Thanks,

Drew





--
Be a Great Magician!
Visit The Alchemist's Warehouse

http://www.alchemistswarehouse.com

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



Re: [gentoo-user] How do I generate libguile-ltdl.so?

2008-02-22 Thread Alma J. Wetzker
Volker Armin Hemmann wrote:
 On Donnerstag, 21. Februar 2008, Alma J. Wetzker wrote:
 I just updated portage and tried to update gnucash.  The compile errors
 out trying to find libguile-ltdl.so.1 and libwthreads.so.12.  I have
 tried to re-emerge guile, g-wrap and slib, none of them build the
 library that I need.  (slib also does not link the scm functions that it
 looks like gnucash looks for, so I may need that too.)

 What settings or whatever do I need to set to generate libguile-ltdl.*?

 -- Alma
 
 have you followed Jakub's advise from the bug and done a revdep-rebuilt?

I have tried.

Configuring search environment for revdep-rebuild

Checking reverse dependencies...

Packages containing binaries and libraries broken by a package update
will be emerged.

Collecting system binaries and libraries... using existing
/root/.revdep-rebuild.1_files.

Collecting complete LD_LIBRARY_PATH... using existing
/root/.revdep-rebuild.2_ldpath.

Checking dynamic linking consistency... using existing
/root/.revdep-rebuild.3_rebuild.

Assigning files to ebuilds... using existing
/root/.revdep-rebuild.4_ebuilds.

Evaluating package order... using existing
/root/.revdep-rebuild.5_order.

All prepared. Starting rebuild...
emerge --oneshot  =dev-python/gnome-python-desktop-2.14.0
=sys-fs/cryptsetup-luks-1.0.3-r2 =gnome-base/gnome-panel-2.14.2
=gnome-base/gnome-applets-2.14.2 =app-text/evince-0.5.3-r1
=gnome-extra/deskbar-applet-2.14.2 =gnome-extra/evolution-webcal-2.6.0
=mail-client/evolution-2.6.2-r1
..........
Calculating dependencies  . .
!!! All ebuilds that could satisfy
=dev-python/gnome-python-desktop-2.14.0 have been masked.
!!! One of the following masked packages is required to complete your
request:
- dev-python/gnome-python-desktop-2.14.0 (masked by: )

For more information, see MASKED PACKAGES section in the emerge man page or
refer to the Gentoo Handbook.


revdep-rebuild failed to emerge all packages
you have the following choices:

- if emerge failed during the build, fix the problems and re-run
revdep-rebuild
or
- use -X or --package-names as first argument (trys to rebuild package,
not exact
  ebuild)
or
- set ACCEPT_KEYWORDS=~your platform and/or /etc/portage/package.unmask
  (and remove /root/.revdep-rebuild.5_order to be evaluated again)
or
- modify the above emerge command and run it manually
or
- compile or unmerge unsatisfied packages manually, remove temporary
files and
  try again (you can edit package/ebuild list first)

To remove temporary files, please run:
rm /root/.revdep-rebuild*.?_*

the first several libraries are masked, so that seems to be a long and
tedious exercise to correct them, one at a time.

This is what I did that worked


emerge guile(1.8.3)
New version, probably made no difference
emerge slib (3.1.5-r1)
New version, probably made no difference
emerge libpcre  (7.6-r1)
This seems to be the magic step that created
'libguile-ltdl.so.*' and 'libqthreads.so.*'
emerge -C gnucash  (2.0.5)
For some reason, I needed this step in order for the new version
of gnucash to compile correctly.  It must have been looking for
something from the 2.0.5 version.
emerge gnucash  (2.2.3)
This worked.

I am not sure what to do about the revdep-build problems, I will work on
it later.  Thanks for the response!

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



Re: [gentoo-user] F77 Provided through /etc/portage/env/*

2008-02-22 Thread Justin

Andrey Falko schrieb:

On Fri, Feb 22, 2008 at 3:56 AM,  [EMAIL PROTECTED] wrote:
  

 Hi all!

 I have a little nasty problem. I am using a couple of fortran progs and not
 all are happy with ifort but some benefit allot of its use. As I am lazy
 and dont want to change my make.conf all the time I provided the F77, FC
 and FLAGS for those packages which support ifort through
 /etc/portage/env/categorie/package. This worked for a long time, but
 now some thing has changed and I dont know what. The variables are still
 passed to the emerge but the F77 and FC isnt used by emake any more. See
 following example: ifort is chosen by the fortran.eclass and configure uses
 it as well. But in the make part only the ifort spezific FFLAGS are use
 together with gfortran.



What version of portage is this? emerge --info? It is possible that
there might be a regression between portage versions. If you've
updated portage recently, try downgrading by masking the current
version in /etc/portage/package.mask.
  
I tryed this first. The second thing I tried was downgrading bash but 
all that doesnt help.
  

  Emerging (1 of 1) sci-chemistry/shelx-20060317 to /
  * shelx-20060317.tgz RMD160 SHA1 SHA256 size ;-) ...
  [ ok ]
  * checking ebuild checksums ;-) ...
  [ ok ]
  * checking auxfile checksums ;-) ...
  [ ok ]
  * checking miscfile checksums ;-) ...
  [ ok ]
  * checking shelx-20060317.tgz ;-) ...
  [ ok ]
  * You need one of these Fortran Compilers: ifc gfortran
  * Installed are:  ifort gfortran
  * Using ifort
  Unpacking source...
  Unpacking shelx-20060317.tgz to
 /var/tmp/portage/sci-chemistry/shelx-20060317/work
  * Applying 20060317-autotool.patch ...
  [ ok ]
  * Applying 20060317-gfortran.patch ...
  [ ok ]
  * Running eautoreconf in
 '/var/tmp/portage/sci-chemistry/shelx-20060317/work/unix' ...
  * Running aclocal ...
  [ ok ]
  * Running autoconf ...
  [ ok ]
  * Running automake --add-missing --copy --foreign ...
  [ ok ]
  Source unpacked.
  Compiling source in
 /var/tmp/portage/sci-chemistry/shelx-20060317/work/unix ...
 ./configure --prefix=/usr --host=i686-pc-linux-gnu --mandir=/usr/share/man
 --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc
 --localstatedir=/var/lib FC=ifort --build=i686-pc-linux-gnu
 checking for a BSD-compatible install... /usr/bin/install -c
 checking whether build environment is sane... yes
 checking for a thread-safe mkdir -p... /bin/mkdir -p
 checking for gawk... gawk
 checking whether make sets $(MAKE)... yes
 checking for i686-pc-linux-gnu-gfortran... ifort
 checking for Fortran compiler default output file name... a.out
 checking whether the Fortran compiler works... yes
 checking whether we are cross compiling... no
 checking for suffix of executables...
 checking for suffix of object files... o
 checking whether we are using the GNU Fortran compiler... no
 checking whether ifort accepts -g... yes
 checking for i686-pc-linux-gnu-g77... no
 checking for i686-pc-linux-gnu-xlf... no
 checking for i686-pc-linux-gnu-f77... no
 checking for i686-pc-linux-gnu-frt... no
 checking for i686-pc-linux-gnu-pgf77... no
 checking for i686-pc-linux-gnu-cf77... no
 checking for i686-pc-linux-gnu-fort77... no
 checking for i686-pc-linux-gnu-fl32... no
 checking for i686-pc-linux-gnu-af77... no
 checking for i686-pc-linux-gnu-xlf90... no
 checking for i686-pc-linux-gnu-f90... no
 checking for i686-pc-linux-gnu-pgf90... no
 checking for i686-pc-linux-gnu-pghpf... no
 checking for i686-pc-linux-gnu-epcf90... no
 checking for i686-pc-linux-gnu-gfortran... i686-pc-linux-gnu-gfortran
 checking whether we are using the GNU Fortran 77 compiler... no
 checking whether i686-pc-linux-gnu-gfortran accepts -g... yes
 configure: creating ./config.status
 config.status: creating Makefile
 i686-pc-linux-gnu-gfortran  -O3 -march=prescott -openmp -parallel -c -o
 ciftab.o ciftab.f
 i686-pc-linux-gnu-gfortran: unrecognized option '-parallel'
 i686-pc-linux-gnu-gfortran  -O3 -march=prescott -openmp -parallel -c -o
 shelxa.o shelxa.f
 i686-pc-linux-gnu-gfortran  -O3 -march=prescott -openmp -parallel -c -o
 shelxc.o shelxc.f
 i686-pc-linux-gnu-gfortran: unrecognized option '-parallel'
 i686-pc-linux-gnu-gfortran  -O3 -march=prescott -openmp -parallel -c -o
 shelxd.o shelxd.f
 i686-pc-linux-gnu-gfortran: unrecognized option '-parallel'


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




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



Re: [gentoo-user] emerge can not work !

2008-02-22 Thread Eric Martin

Matthias Guede wrote:

Make sure your working directory is in the path:

PATH=${PATH}:./ ./python /usr/bin/emerge python
  


!!Big security hole!! ./ is purposely left out of the path so people 
can't sneak fake programs in there.


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



Re: [gentoo-user] How do I generate libguile-ltdl.so?

2008-02-22 Thread volker . armin . hemmann
On Freitag 22 Februar 2008, Alma J. Wetzker wrote:
 Volker Armin Hemmann wrote:
  On Donnerstag, 21. Februar 2008, Alma J. Wetzker wrote:
  I just updated portage and tried to update gnucash.  The compile errors
  out trying to find libguile-ltdl.so.1 and libwthreads.so.12.  I have
  tried to re-emerge guile, g-wrap and slib, none of them build the
  library that I need.  (slib also does not link the scm functions that it
  looks like gnucash looks for, so I may need that too.)
 
  What settings or whatever do I need to set to generate libguile-ltdl.*?
 
  -- Alma
 
  have you followed Jakub's advise from the bug and done a revdep-rebuilt?

 I have tried.

 Configuring search environment for revdep-rebuild

 Checking reverse dependencies...

 Packages containing binaries and libraries broken by a package update
 will be emerged.

 Collecting system binaries and libraries... using existing
 /root/.revdep-rebuild.1_files.

 Collecting complete LD_LIBRARY_PATH... using existing
 /root/.revdep-rebuild.2_ldpath.

 Checking dynamic linking consistency... using existing
 /root/.revdep-rebuild.3_rebuild.

 Assigning files to ebuilds... using existing
 /root/.revdep-rebuild.4_ebuilds.

 Evaluating package order... using existing
 /root/.revdep-rebuild.5_order.

 All prepared. Starting rebuild...
 emerge --oneshot  =dev-python/gnome-python-desktop-2.14.0
 =sys-fs/cryptsetup-luks-1.0.3-r2 =gnome-base/gnome-panel-2.14.2
 =gnome-base/gnome-applets-2.14.2 =app-text/evince-0.5.3-r1
 =gnome-extra/deskbar-applet-2.14.2 =gnome-extra/evolution-webcal-2.6.0
 =mail-client/evolution-2.6.2-r1
 ..........
 Calculating dependencies  . .
 !!! All ebuilds that could satisfy
 =dev-python/gnome-python-desktop-2.14.0 have been masked.
 !!! One of the following masked packages is required to complete your
 request:
 - dev-python/gnome-python-desktop-2.14.0 (masked by: )

 For more information, see MASKED PACKAGES section in the emerge man page or
 refer to the Gentoo Handbook.


 revdep-rebuild failed to emerge all packages
 you have the following choices:

 - if emerge failed during the build, fix the problems and re-run
 revdep-rebuild
 or
 - use -X or --package-names as first argument (trys to rebuild package,
 not exact
   ebuild)
 or
 - set ACCEPT_KEYWORDS=~your platform and/or /etc/portage/package.unmask
   (and remove /root/.revdep-rebuild.5_order to be evaluated again)
 or
 - modify the above emerge command and run it manually
 or
 - compile or unmerge unsatisfied packages manually, remove temporary
 files and
   try again (you can edit package/ebuild list first)

 To remove temporary files, please run:
 rm /root/.revdep-rebuild*.?_*

 the first several libraries are masked, so that seems to be a long and
 tedious exercise to correct them, one at a time.

 This is what I did that worked


 emerge guile(1.8.3)
   New version, probably made no difference
 emerge slib (3.1.5-r1)
   New version, probably made no difference
 emerge libpcre  (7.6-r1)
   This seems to be the magic step that created
   'libguile-ltdl.so.*' and 'libqthreads.so.*'
 emerge -C gnucash  (2.0.5)
   For some reason, I needed this step in order for the new version
   of gnucash to compile correctly.  It must have been looking for
   something from the 2.0.5 version.
 emerge gnucash  (2.2.3)
   This worked.

 I am not sure what to do about the revdep-build problems, I will work on
 it later.  Thanks for the response!

just put dev-python/gnome-python-desktop-2.14.0 into package.unmask or 
package.keywords-
-- 
gentoo-user@lists.gentoo.org mailing list



Re: [gentoo-user] F77 Provided through /etc/portage/env/*

2008-02-22 Thread Andrey Falko
On Fri, Feb 22, 2008 at 1:25 PM, Justin [EMAIL PROTECTED] wrote:
 Andrey Falko schrieb:

  On Fri, Feb 22, 2008 at 3:56 AM,  [EMAIL PROTECTED] wrote:
  
Hi all!
  
I have a little nasty problem. I am using a couple of fortran progs and 
 not
all are happy with ifort but some benefit allot of its use. As I am lazy
and dont want to change my make.conf all the time I provided the F77, FC
and FLAGS for those packages which support ifort through
/etc/portage/env/categorie/package. This worked for a long time, but
now some thing has changed and I dont know what. The variables are still
passed to the emerge but the F77 and FC isnt used by emake any more. See
following example: ifort is chosen by the fortran.eclass and configure 
 uses
it as well. But in the make part only the ifort spezific FFLAGS are use
together with gfortran.
  
  
   What version of portage is this? emerge --info? It is possible that
   there might be a regression between portage versions. If you've
   updated portage recently, try downgrading by masking the current
   version in /etc/portage/package.mask.
  
  I tryed this first. The second thing I tried was downgrading bash but
  all that doesnt help.

You can try running emerge --debug, maybe that will hint the problem?

 
 Emerging (1 of 1) sci-chemistry/shelx-20060317 to /
 * shelx-20060317.tgz RMD160 SHA1 SHA256 size ;-) ...
 [ ok ]
 * checking ebuild checksums ;-) ...
 [ ok ]
 * checking auxfile checksums ;-) ...
 [ ok ]
 * checking miscfile checksums ;-) ...
 [ ok ]
 * checking shelx-20060317.tgz ;-) ...
 [ ok ]
 * You need one of these Fortran Compilers: ifc gfortran
 * Installed are:  ifort gfortran
 * Using ifort
 Unpacking source...
 Unpacking shelx-20060317.tgz to
/var/tmp/portage/sci-chemistry/shelx-20060317/work
 * Applying 20060317-autotool.patch ...
 [ ok ]
 * Applying 20060317-gfortran.patch ...
 [ ok ]
 * Running eautoreconf in
'/var/tmp/portage/sci-chemistry/shelx-20060317/work/unix' ...
 * Running aclocal ...
 [ ok ]
 * Running autoconf ...
 [ ok ]
 * Running automake --add-missing --copy --foreign ...
 [ ok ]
 Source unpacked.
 Compiling source in
/var/tmp/portage/sci-chemistry/shelx-20060317/work/unix ...
./configure --prefix=/usr --host=i686-pc-linux-gnu 
 --mandir=/usr/share/man
--infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc
--localstatedir=/var/lib FC=ifort --build=i686-pc-linux-gnu
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking for i686-pc-linux-gnu-gfortran... ifort
checking for Fortran compiler default output file name... a.out
checking whether the Fortran compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU Fortran compiler... no
checking whether ifort accepts -g... yes
checking for i686-pc-linux-gnu-g77... no
checking for i686-pc-linux-gnu-xlf... no
checking for i686-pc-linux-gnu-f77... no
checking for i686-pc-linux-gnu-frt... no
checking for i686-pc-linux-gnu-pgf77... no
checking for i686-pc-linux-gnu-cf77... no
checking for i686-pc-linux-gnu-fort77... no
checking for i686-pc-linux-gnu-fl32... no
checking for i686-pc-linux-gnu-af77... no
checking for i686-pc-linux-gnu-xlf90... no
checking for i686-pc-linux-gnu-f90... no
checking for i686-pc-linux-gnu-pgf90... no
checking for i686-pc-linux-gnu-pghpf... no
checking for i686-pc-linux-gnu-epcf90... no
checking for i686-pc-linux-gnu-gfortran... i686-pc-linux-gnu-gfortran
checking whether we are using the GNU Fortran 77 compiler... no
checking whether i686-pc-linux-gnu-gfortran accepts -g... yes
configure: creating ./config.status
config.status: creating Makefile
i686-pc-linux-gnu-gfortran  -O3 -march=prescott -openmp -parallel -c -o
ciftab.o ciftab.f
i686-pc-linux-gnu-gfortran: unrecognized option '-parallel'
i686-pc-linux-gnu-gfortran  -O3 -march=prescott -openmp -parallel -c -o
shelxa.o shelxa.f
i686-pc-linux-gnu-gfortran  -O3 

Re: [gentoo-user] Gnucash 2.2.3 build not finding libguile-ltdl*

2008-02-22 Thread Eric Martin

Alma J. Wetzker wrote:

environment is huge, not sure what you want.

I emerged the latest guile (1.8.3) after the first error, then I looked
at the build description of fixes and emerged slib (3.1.5-r1), then I
reemerged guile.

I still do not have libguile-ltdl*, and libqthreads* anywhere that I can
find them.  Not sure what to do with the libguile.so.[17|12] concern.

I also cannot re-emerge gnucash 2.0.5, so nothing is working now.  I am
not near a guru level, so please be specific when asking for more
information.

How do I get the missing libraries?

-- Alma

Have you tried revdep-rebuild yet?
--
gentoo-user@lists.gentoo.org mailing list



Re: What is LD_LIBRARY_PATH? (Was Re: [gentoo-user] OpenOffice 2.3.1 Won't Start As User)

2008-02-22 Thread Willie Wong
On Fri, Feb 22, 2008 at 09:52:39AM -0800, Penguin Lover Drew Tomlinson squawked:
 There are no error messages.  When starting as a user, the splash 
 graphic just sits there and the CPU usage is basically 100% for both X 
 and oosplash.bin.  When starting as root, the splash graphic starts and 
 then a progress bar at the bottom of the splash graphic progresses in 
 about 10 seconds and OpenOffice starts.  The progress bar never 
 progresses when starting as a user.  I have to kill oosplash.bin with 
 signal 15 after starting as a user to return my system to normal.
 
 Some more Googling turned up this post:
 
 http://forums.gentoo.org/viewtopic-t-623771-postdays-0-postorder-asc-start-25.html?sid=1514fa8e48f6a12a86c6c66e920161e9
 
 I found that when I su to root, LD_LIBRARY_PATH is not defined.  As a 
 user, it is defined as:
 
 LD_LIBRARY_PATH=/usr/lib32/xorg:/usr/lib64/xorg
 
 If I unset LD_LIBRARY_PATH in a user terminal, then OpenOffice starts.  
 So what is LD_LIBRARY_PATH and why am I seeing this behavior?
 

See

 http://linuxmafia.com/faq/Admin/ld-lib-path.html
 http://wiki.services.openoffice.org/wiki/LD_LIBRARY_PATH

So the question is one of hunting down where this variable is set.
Your .bashrc? Perhaps grepping through /etc/env.d? 

W
-- 
What is the meaning of Life?

To search for truth and beauty.
To ask questions.
To find the answer to this question
To rigorously mathematically prove by epislon-delta treatment that this 
question has no answer. Proof? For all oranges greater than zero, there exists 
a banana such that for all fruits tastier than the banana, an orange sweeter 
than a banana implies the orange is yellow. So by the Jedi-Schwartz Inequality,
all oranges are not orange. This leads to an obvious contradiction.

It's too bad life is a departmental requirement, otherwise I'd P/D/F it.

 ~Phil Wei
Sortir en Pantoufles: up 441 days, 20:06
-- 
gentoo-user@lists.gentoo.org mailing list



[gentoo-user] emerge --update --deep --newuse world fails to update all packages

2008-02-22 Thread Erik

I did emerge --update --deep --newuse world and it says:
Calculating world dependencies... done!
 Auto-cleaning packages...

 No outdated packages were found on your system.


But it seems like it is wrong about No outdated packages were found on 
your system., because when I run emerge -p world it says:


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

Calculating world dependencies... done!
[ebuild U ] media-gfx/digikam-0.9.2 [0.9.1] LINGUAS=-fa% -nds%
[blocks B ] media-plugins/digikamimageplugins (is blocking 
media-gfx/digikam-0.9.2)



So it seems like media-gfx/digikam is outdated despite what emerge 
--update --deep --newuse world said. I just wonder how much sense this 
behaviour makes.


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



Re: [gentoo-user] emerge can not work !

2008-02-22 Thread Alan McKinnon
On Friday 22 February 2008, Eric Martin wrote:
 Matthias Guede wrote:
  Make sure your working directory is in the path:
 
  PATH=${PATH}:./ ./python /usr/bin/emerge python

 !!Big security hole!! ./ is purposely left out of the path so people
 can't sneak fake programs in there.

 ~eric

Very true but in this specific case it is superfluous.

With the sample command given, the PATH will not be searched at all as 
all executables are accessed via their directory path.

But you are correct with the warning. People do this solely and only 
because Windows does it and some folk are used to it. But WE all know 
that Windows is brain-dead :-)

Kids, don't try this at home and dream up false reasons to put . in your 
PATH

-- 
Alan McKinnon
alan dot mckinnon at gmail dot com

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



Re: [gentoo-user] Kernel upgrade broke NAT

2008-02-22 Thread Alan McKinnon
On Friday 22 February 2008, Grant wrote:
   Too bad that 'oldconfig' isn't always working :-(

 Is there a better way to update the config for a new kernel?

Not really.

You are dealing with a complex system of configuration settings that 
react in mysterious ways. AND that seeing as this is a kernel, the hard 
decisions are best left to humans, not software.

So all that oldconfig really does is look for settings that are present 
in the source tree but not accounted for in your .config

For everything else, you get to look yourself. Or, in the usual case, 
study it for 10 hours to find out what the heck it is, then look for 
yourself.

-- 
Alan McKinnon
alan dot mckinnon at gmail dot com

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



[gentoo-user] emerge -ef world and eclean --destructive distfiles do not agree

2008-02-22 Thread Erik

I am running
emerge -ef world
eclean --destructive distfiles'
emerge -ef world
eclean --destructive distfiles
...

Each time eclean removes the following files:
* Building file list for distfiles cleaning...
* Cleaning distfiles...
[ 258.9 K ] XML-LibXML-1.65.tar.gz
[ 478.6 K ] klibc-1.5.8.tar.bz2
[ 290.2 K ] libassuan-1.0.4.tar.bz2
[  67.7 K ] mftrace-1.2.9.tar.gz
[   9.2 M ] patch-2.6.24-rc7.bz2
[ 243.4 K ] setuptools-0.6c7.tar.gz
* Total space that has been freed in distfiles directory: 10.5 M

Then emerge downloads them again. I had expected that those 2 programs 
should agree on which files belong in the set of distfiles.

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



Re: [gentoo-user] emerge -ef world and eclean --destructive distfiles do not agree

2008-02-22 Thread Alan McKinnon
On Saturday 23 February 2008, Erik wrote:
 I am running
 emerge -ef world
 eclean --destructive distfiles'
 emerge -ef world
 eclean --destructive distfiles
 ...

 Each time eclean removes the following files:
  * Building file list for distfiles cleaning...
  * Cleaning distfiles...
  [ 258.9 K ] XML-LibXML-1.65.tar.gz
  [ 478.6 K ] klibc-1.5.8.tar.bz2
  [ 290.2 K ] libassuan-1.0.4.tar.bz2
  [  67.7 K ] mftrace-1.2.9.tar.gz
  [   9.2 M ] patch-2.6.24-rc7.bz2
  [ 243.4 K ] setuptools-0.6c7.tar.gz
  * Total space that has been freed in distfiles directory: 10.5 M

 Then emerge downloads them again. I had expected that those 2
 programs should agree on which files belong in the set of distfiles.

What happens if you use 'emerge -uNDf world instead of 'emerge -ef 
world'

-e is a special case and does not equate to the same thing as -uND

-- 
Alan McKinnon
alan dot mckinnon at gmail dot com

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



Re: [gentoo-user] emerge -ef world and eclean --destructive distfiles do not agree

2008-02-22 Thread Dale

Alan McKinnon wrote:

On Saturday 23 February 2008, Erik wrote:
  

I am running
emerge -ef world
eclean --destructive distfiles'
emerge -ef world
eclean --destructive distfiles
...

Each time eclean removes the following files:
 * Building file list for distfiles cleaning...
 * Cleaning distfiles...
 [ 258.9 K ] XML-LibXML-1.65.tar.gz
 [ 478.6 K ] klibc-1.5.8.tar.bz2
 [ 290.2 K ] libassuan-1.0.4.tar.bz2
 [  67.7 K ] mftrace-1.2.9.tar.gz
 [   9.2 M ] patch-2.6.24-rc7.bz2
 [ 243.4 K ] setuptools-0.6c7.tar.gz
 * Total space that has been freed in distfiles directory: 10.5 M

Then emerge downloads them again. I had expected that those 2
programs should agree on which files belong in the set of distfiles.



What happens if you use 'emerge -uNDf world instead of 'emerge -ef 
world'


-e is a special case and does not equate to the same thing as -uND

  


I think I see it the same way he does.  If you do a rm -rf 
/usr/portage/distfiles/* and then do a emerge -ef world, then do the 
eclean again, it should not remove anything since everything there is 
needed to recompile everything in world and their dependencies.  It 
should also not have to redownload anything either.


Isn't patch part of system?  setuptools too?

Dale

:-)  :-) 
--

gentoo-user@lists.gentoo.org mailing list



ATI Drivers Sets LD_LIBRARY_PATH (Was Re: What is LD_LIBRARY_PATH? (Was Re: [gentoo-user] OpenOffice 2.3.1 Won't Start As User))

2008-02-22 Thread Drew Tomlinson

Willie Wong wrote:

On Fri, Feb 22, 2008 at 09:52:39AM -0800, Penguin Lover Drew Tomlinson squawked:
  
There are no error messages.  When starting as a user, the splash 
graphic just sits there and the CPU usage is basically 100% for both X 
and oosplash.bin.  When starting as root, the splash graphic starts and 
then a progress bar at the bottom of the splash graphic progresses in 
about 10 seconds and OpenOffice starts.  The progress bar never 
progresses when starting as a user.  I have to kill oosplash.bin with 
signal 15 after starting as a user to return my system to normal.


Some more Googling turned up this post:

http://forums.gentoo.org/viewtopic-t-623771-postdays-0-postorder-asc-start-25.html?sid=1514fa8e48f6a12a86c6c66e920161e9

I found that when I su to root, LD_LIBRARY_PATH is not defined.  As a 
user, it is defined as:


LD_LIBRARY_PATH=/usr/lib32/xorg:/usr/lib64/xorg

If I unset LD_LIBRARY_PATH in a user terminal, then OpenOffice starts.  
So what is LD_LIBRARY_PATH and why am I seeing this behavior?





See

 http://linuxmafia.com/faq/Admin/ld-lib-path.html
 http://wiki.services.openoffice.org/wiki/LD_LIBRARY_PATH

So the question is one of hunting down where this variable is set.
Your .bashrc? Perhaps grepping through /etc/env.d? 
  


Thank you for your reply.  The culprit appears to be 
/etc/profile.d/ati-fglrx.sh.  So if setting LD_LIBRARY_PATH is not a 
good idea, why does the ATI driver do so?  And more importantly, how can 
I workaround this issue?


Thanks,

Drew

--
Be a Great Magician!
Visit The Alchemist's Warehouse

http://www.alchemistswarehouse.com

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



Re: [gentoo-user] emerge -ef world and eclean --destructive distfiles do not agree

2008-02-22 Thread Erik

Alan McKinnon skrev:

On Saturday 23 February 2008, Erik wrote:
  

I am running
emerge -ef world
eclean --destructive distfiles'
emerge -ef world
eclean --destructive distfiles
...

Each time eclean removes the following files:
 * Building file list for distfiles cleaning...
 * Cleaning distfiles...
 [ 258.9 K ] XML-LibXML-1.65.tar.gz
 [ 478.6 K ] klibc-1.5.8.tar.bz2
 [ 290.2 K ] libassuan-1.0.4.tar.bz2
 [  67.7 K ] mftrace-1.2.9.tar.gz
 [   9.2 M ] patch-2.6.24-rc7.bz2
 [ 243.4 K ] setuptools-0.6c7.tar.gz
 * Total space that has been freed in distfiles directory: 10.5 M

Then emerge downloads them again. I had expected that those 2
programs should agree on which files belong in the set of distfiles.

What happens if you use 'emerge -uNDf world instead of 'emerge -ef 
world'


-e is a special case and does not equate to the same thing as -uND  


emerge -uNDf world does nothing because the system is up to date. Even 
if all distfiles are missing, it does nothing (try to move the distfiles 
directory away while executing it). That command is supposed to 
download everything that is missing to update the system. And since 
the system is up to date, nothing is needed to update it and it will 
therefore not download anything.


What I wanted was download everything that is missing to reinstall 
everything that is currently installed. That is what emerge -ef world 
should do. Then I wanted to remov

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



Re: [gentoo-user] emerge -ef world and eclean --destructive distfiles do not agree

2008-02-22 Thread Erik

Alan McKinnon skrev:

On Saturday 23 February 2008, Erik wrote:
  

I am running
emerge -ef world
eclean --destructive distfiles'
emerge -ef world
eclean --destructive distfiles
...

Each time eclean removes the following files:
 * Building file list for distfiles cleaning...
 * Cleaning distfiles...
 [ 258.9 K ] XML-LibXML-1.65.tar.gz
 [ 478.6 K ] klibc-1.5.8.tar.bz2
 [ 290.2 K ] libassuan-1.0.4.tar.bz2
 [  67.7 K ] mftrace-1.2.9.tar.gz
 [   9.2 M ] patch-2.6.24-rc7.bz2
 [ 243.4 K ] setuptools-0.6c7.tar.gz
 * Total space that has been freed in distfiles directory: 10.5 M

Then emerge downloads them again. I had expected that those 2
programs should agree on which files belong in the set of distfiles.

What happens if you use 'emerge -uNDf world instead of 'emerge -ef 
world'


-e is a special case and does not equate to the same thing as -uND
  


emerge -uNDf world does nothing because the system is up to date. Even 
if all distfiles are missing, it does nothing (try to move the distfiles 
directory away while executing it). That command is supposed to 
download everything that is missing to update the system. And since 
the system is up to date, nothing is needed to update it and it will 
therefore not download anything.


What I wanted was download everything that is missing to reinstall 
everything that is currently installed. That is what emerge -ef world 
should do. Then I wanted to remove everything that is not needed to 
reinstall everything that is currently installed. That is what eclean 
--destructive distfiles should do. Doing both should result in a set of 
distfiles that is what is needed and only what is needed to reinstall 
everything that is currently installed (assuming that the system is up 
to date). But since the 2 commands do not agree, something is broken 
somewhere.

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



Re: [gentoo-user] emerge -ef world and eclean --destructive distfiles do not agree

2008-02-22 Thread forgottenwizard
On 02:41 Sat 23 Feb , Erik wrote:
 Alan McKinnon skrev:

 emerge -uNDf world does nothing because the system is up to date. Even if 
 all distfiles are missing, it does nothing (try to move the distfiles 
 directory away while executing it). That command is supposed to download 
 everything that is missing to update the system. And since the system is 
 up to date, nothing is needed to update it and it will therefore not 
 download anything.

 What I wanted was download everything that is missing to reinstall 
 everything that is currently installed. That is what emerge -ef world 
 should do. Then I wanted to remove everything that is not needed to 
 reinstall everything that is currently installed. That is what eclean 
 --destructive distfiles should do. Doing both should result in a set of 
 distfiles that is what is needed and only what is needed to reinstall 
 everything that is currently installed (assuming that the system is up to 
 date). But since the 2 commands do not agree, something is broken 
 somewhere.
 -- 
 gentoo-user@lists.gentoo.org mailing list



Have you checked to see if the files deleted by eclean are the current
versions, or are they old? If they are the most recent you have
installed, then there is a problem with eclean. If not, then the problem
is with --fetchonly

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



Re: ATI Drivers Sets LD_LIBRARY_PATH (Was Re: What is LD_LIBRARY_PATH? (Was Re: [gentoo-user] OpenOffice 2.3.1 Won't Start As User))

2008-02-22 Thread Willie Wong
On Fri, Feb 22, 2008 at 05:34:54PM -0800, Penguin Lover Drew Tomlinson squawked:
 LD_LIBRARY_PATH=/usr/lib32/xorg:/usr/lib64/xorg
 
 If I unset LD_LIBRARY_PATH in a user terminal, then OpenOffice starts.  
 So what is LD_LIBRARY_PATH and why am I seeing this behavior?
 
 
 
 See
 
  http://linuxmafia.com/faq/Admin/ld-lib-path.html
  http://wiki.services.openoffice.org/wiki/LD_LIBRARY_PATH
 
 So the question is one of hunting down where this variable is set.
 Your .bashrc? Perhaps grepping through /etc/env.d? 
   
 
 Thank you for your reply.  The culprit appears to be 
 /etc/profile.d/ati-fglrx.sh.  So if setting LD_LIBRARY_PATH is not a 
 good idea, why does the ATI driver do so?  And more importantly, how can 
 I workaround this issue?
 

As I don't use fglrx, I can't comment on that behaviour. A workaround
is simply to alias oocal in your bashrc to something that unsets the 
problematic path. 

W
-- 
W: You see, me and Willetta have been going on for a few weeks now.
Phil: Only a few weeks, and she's living in your room?
DJP: Will! What's that thing you said earlier about taking things slow!
MW rolling on the ground laughing.
Sortir en Pantoufles: up 442 days,  5:06
-- 
gentoo-user@lists.gentoo.org mailing list