Re: [gentoo-dev] revdep-rebuild bikeshedding

2013-01-17 Thread Sergey Popov
17.01.2013 00:43, Paul Varner wrote:
 Here is where the bikeshedding begins:
 1. What variable name do we prefer? REVDEP_DEFAULT_OPTS or
 REVDEP_EMERGE_DEFAULT_OPTS

REVDEP_REBUILD_DEFAULT_OPTS seems fine, IMO.

 2. What behavior do we want? append to EMERGE_DEFAULT_OPTS or replace
 EMERGE_DEFAULT_OPTS

replace is better

-- 
Best regards, Sergey Popov
Gentoo Linux Developer
Desktop-effects project lead



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] revdep-rebuild bikeshedding

2013-01-16 Thread Rich Freeman
On Wed, Jan 16, 2013 at 3:43 PM, Paul Varner fuzzy...@gentoo.org wrote:
 2. What behavior do we want? append to EMERGE_DEFAULT_OPTS or replace
 EMERGE_DEFAULT_OPTS

Replace is probably better.  You can always manually append if you
want to, but it is much harder to remove unless portage has logic to
handle a inverse of every option and processing them in order (ie
--with-bdeps=y --with-bdeps=n works out to a no, and vice-versa).  If
you just replace it you'll eliminate a bunch of issues.

Rich



Re: [gentoo-dev] revdep-rebuild bikeshedding

2013-01-16 Thread Ian Stakenvicius
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 16/01/13 03:43 PM, Paul Varner wrote:
 All:
 
 Time for some bikeshedding :)
 
 For the gentoolkit-0.3.0 series, I removed any filtering of emerge 
 options set in EMERGE_DEFAULT_OPS for revdep-rebuild.  This has
 caused some people to complain because some of the flags in their 
 EMERGE_DEFAULT_OPTS are not suitable for a revdep-rebuild run.
 
 I am not going to go back to filtering any of the emerge options, 
 however, I just added support for a make.conf variable called 
 REVDEP_DEFAULT_OPTS which currently gets appended to the list of
 options after the EMERGE_DEFAULT_OPTS and before the command line
 options.
 
 Here is where the bikeshedding begins: 1. What variable name do we
 prefer? REVDEP_DEFAULT_OPTS or REVDEP_EMERGE_DEFAULT_OPTS

+1 on REVDEP_DEFAULT_OPTS , but if things are going to be verbose
might as well make them completely verbose with
REVDEP_REBUILD_DEFAULT_EMERGE_OPTS

 2. What behavior do we want? append to EMERGE_DEFAULT_OPTS or
 replace EMERGE_DEFAULT_OPTS

+1 on the replace.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlD3FDIACgkQ2ugaI38ACPC3gQEAvUlApXInabHifnIXlqsUJhJX
syeaaDkOXLzSO1L3vskA/2xX2YxAMnnmtFkv+QLBi+Kx+fLi60ZE/0QD1Zd5LH/3
=h5CO
-END PGP SIGNATURE-



Re: [gentoo-dev] revdep-rebuild bikeshedding

2013-01-16 Thread Albert Hopkins


On Wed, Jan 16, 2013, at 03:57 PM, Ian Stakenvicius wrote:
[...]
 +1 on the replace.

+1



Re: [gentoo-dev] revdep-rebuild

2005-08-15 Thread Georgi Georgiev
maillog: 14/08/2005-21:16:01(-0700): Stefan Jones types
 Stefan Jones wrote:
 
 So I have started making a small C program which does the
 Checking dynamic linking consistency... part of the revdep-rebuild
 program (I think this the the most time intensive part).
 
 This program can then be called by the script.
 
 So far all I see the program needing to do is
 read /root/.revdep-rebuild.1_files and
 use /root/.revdep-rebuild.2_ldpath as the LD_LIBRARY_PATH
 and write any bad files to /root/.revdep-rebuild.3_rebuild
 
  
 
 
 I have finished doing the above for linux/glibc, it can be found at 
 http://dev.gentoo.org/~cretin/revdep-rebuild.tar.bz2
 
 I just made a small C-program to check the dependencies, it uses 
 ld-linux.so.2 check if the file is an ELF and then to check if it's 
 libraries are present.

On x86-64 the native ELFs do not use ld-linux.so.2, but
ld-linux-x86-64.so.2 instead.

-- 
 )   Georgi Georgiev) I'd put my money where my mouth is, but my)
( [EMAIL PROTECTED](  mouth keeps moving. -- Larry Wall in (
 )  +81(90)2877-8845) [EMAIL PROTECTED]  )
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] revdep-rebuild

2005-08-15 Thread Stefan Jones
On Mon, 2005-08-15 at 17:18 +0900, Georgi Georgiev wrote:
 On x86-64 the native ELFs do not use ld-linux.so.2, but
 ld-linux-x86-64.so.2 instead.

Okey, thanks, using /usr/include/gnu/lib-names.h would soon sort out
that problem at compile time!

Stefan
-- 
Stefan Jones [EMAIL PROTECTED]

-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] revdep-rebuild

2005-08-15 Thread Georgi Georgiev
maillog: 15/08/2005-07:25:36(-0700): Stefan Jones types
 On Mon, 2005-08-15 at 17:18 +0900, Georgi Georgiev wrote:
  On x86-64 the native ELFs do not use ld-linux.so.2, but
  ld-linux-x86-64.so.2 instead.
 
 Okey, thanks, using /usr/include/gnu/lib-names.h would soon sort out
 that problem at compile time!

I hope you do intend to support both types of executables on amd64.
After all the current method with ldd works fine for both and I guess
you don't want any regression.

[EMAIL PROTECTED] ~ $ ldd /bin/ls
librt.so.1 = /lib/librt.so.1 (0x2abc3000)
libncurses.so.5 = /lib/libncurses.so.5 (0x2accc000)
libacl.so.1 = /lib/libacl.so.1 (0x2ae27000)
libc.so.6 = /lib/libc.so.6 (0x2af2e000)
libpthread.so.0 = /lib/libpthread.so.0 (0x2b166000)
/lib64/ld-linux-x86-64.so.2 (0x2aaab000)
libdl.so.2 = /lib/libdl.so.2 (0x2b27c000)
libattr.so.1 = /lib/libattr.so.1 (0x2b37f000)
[EMAIL PROTECTED] ~ $ ldd /opt/RealPlayer/realplay.bin 
linux-gate.so.1 =  (0xe000)
libstdc++.so.5 = /emul/linux/x86/usr/lib/libstdc++.so.5 (0x55589000)
libgdk-x11-2.0.so.0 = /emul/linux/x86/usr/lib/libgdk-x11-2.0.so.0 
(0x5563c000)
libatk-1.0.so.0 = /emul/linux/x86/usr/lib/libatk-1.0.so.0 (0x556b6000)
libgdk_pixbuf-2.0.so.0 = 
/emul/linux/x86/usr/lib/libgdk_pixbuf-2.0.so.0 (0x556ce000)
libm.so.6 = /lib32/libm.so.6 (0x556e3000)
libpangoxft-1.0.so.0 = /emul/linux/x86/usr/lib/libpangoxft-1.0.so.0 
(0x5570a000)
libpangox-1.0.so.0 = /emul/linux/x86/usr/lib/libpangox-1.0.so.0 
(0x55711000)
libpango-1.0.so.0 = /emul/linux/x86/usr/lib/libpango-1.0.so.0 
(0x5571c000)
libgobject-2.0.so.0 = /emul/linux/x86/usr/lib/libgobject-2.0.so.0 
(0x55754000)
libgmodule-2.0.so.0 = /emul/linux/x86/usr/lib/libgmodule-2.0.so.0 
(0x55786000)
libdl.so.2 = /lib32/libdl.so.2 (0x5578a000)
libglib-2.0.so.0 = /emul/linux/x86/usr/lib/libglib-2.0.so.0 
(0x5578f000)
libgtk-x11-2.0.so.0 = /emul/linux/x86/usr/lib/libgtk-x11-2.0.so.0 
(0x5580d000)
libpthread.so.0 = /lib32/libpthread.so.0 (0x55ad5000)
libc.so.6 = /lib32/libc.so.6 (0x55ae8000)
libX11.so.6 = /emul/linux/x86/usr/lib/libX11.so.6 (0x55c1c000)
libgcc_s.so.1 = 
/usr/lib/gcc/x86_64-pc-linux-gnu/3.4.4/32/libgcc_s.so.1 (0x55ce6000)
libXrandr.so.2 = /emul/linux/x86/usr/lib/libXrandr.so.2 (0x55cf)
libXi.so.6 = /emul/linux/x86/usr/lib/libXi.so.6 (0x55cf3000)
libXinerama.so.1 = /emul/linux/x86/usr/lib/libXinerama.so.1 
(0x55cfb000)
libXft.so.2 = /emul/linux/x86/usr/lib/libXft.so.2 (0x55cfe000)
libfreetype.so.6 = /emul/linux/x86/usr/lib/libfreetype.so.6 
(0x55d1)
libfontconfig.so.1 = /emul/linux/x86/usr/lib/libfontconfig.so.1 
(0x55d8)
libXfixes.so.3 = /emul/linux/x86/usr/lib/libXfixes.so.3 (0x55da7000)
libXcursor.so.1 = /emul/linux/x86/usr/lib/libXcursor.so.1 (0x55dac000)
libXrender.so.1 = /emul/linux/x86/usr/lib/libXrender.so.1 (0x55db5000)
libXext.so.6 = /emul/linux/x86/usr/lib/libXext.so.6 (0x55dbd000)
/lib/ld-linux.so.2 (0x5000)
libpangoft2-1.0.so.0 = /emul/linux/x86/usr/lib/libpangoft2-1.0.so.0 
(0x55dcc000)
libexpat.so.0 = /emul/linux/x86/usr/lib/libexpat.so.0 (0x55df1000)
libz.so.1 = /emul/linux/x86/lib/libz.so.1 (0x55e11000)


-- 
\/   Georgi Georgiev   \/ You must be the change you wish to see in\/
/\[EMAIL PROTECTED]/\ the world. --Mahatma Gandhi  /\
\/  +81(90)2877-8845   \/  \/
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] revdep-rebuild

2005-08-15 Thread Stefan Jones
On Mon, 2005-08-15 at 23:35 +0900, Georgi Georgiev wrote:
 I hope you do intend to support both types of executables on amd64.
 After all the current method with ldd works fine for both and I guess
 you don't want any regression.

A quick look at /usr/bin/ldd shows that is just goes though using both
dynamic linkers and sees which one works. This could be done for amd64 I
suppose.

But first I have an idea to only use scanelf (but that may have issues
with 32/64 combined userspaces) which I would want to implement.

-- 
Stefan Jones [EMAIL PROTECTED]

-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] revdep-rebuild

2005-08-15 Thread Mike Frysinger
On Monday 15 August 2005 10:49 am, Stefan Jones wrote:
 On Mon, 2005-08-15 at 23:35 +0900, Georgi Georgiev wrote:
  I hope you do intend to support both types of executables on amd64.
  After all the current method with ldd works fine for both and I guess
  you don't want any regression.

 But first I have an idea to only use scanelf (but that may have issues
 with 32/64 combined userspaces) which I would want to implement.

no, it doesnt ... scanelf can handle any ELF format regardless of 
endian/bitsize of the host or target or any combo thereof

you can scan 32bit MSB ARM ELF's from a host 64bit LSB X86_64 host just as 
easily as say from a 32bit MSB PARISC host
-mike
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] revdep-rebuild

2005-08-15 Thread Stefan Jones
On Mon, 2005-08-15 at 15:57 -0400, Mike Frysinger wrote:
 
  But first I have an idea to only use scanelf (but that may have issues
  with 32/64 combined userspaces) which I would want to implement.
 
 no, it doesnt ... scanelf can handle any ELF format regardless of 
 endian/bitsize of the host or target or any combo thereof
 
 you can scan 32bit MSB ARM ELF's from a host 64bit LSB X86_64 host just as 
 easily as say from a 32bit MSB PARISC host

Sorry, was not clear enough, a 32bit library cannot resolve a 64bit
dependency. So when you read in the available libraries and there
dependencies you need to keep track of which type they are.

Anyway, the -i flag to scanelf fixes that and other issues, just group
all the data from scanelf by interpreter (so have multiple hashes, one
for each interp).

Stefan
-- 
Stefan Jones [EMAIL PROTECTED]

-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] revdep-rebuild

2005-08-15 Thread Mike Frysinger
On Monday 15 August 2005 04:19 pm, Stefan Jones wrote:
 On Mon, 2005-08-15 at 15:57 -0400, Mike Frysinger wrote:
   But first I have an idea to only use scanelf (but that may have issues
   with 32/64 combined userspaces) which I would want to implement.
 
  no, it doesnt ... scanelf can handle any ELF format regardless of
  endian/bitsize of the host or target or any combo thereof
 
  you can scan 32bit MSB ARM ELF's from a host 64bit LSB X86_64 host just
  as easily as say from a 32bit MSB PARISC host

 Sorry, was not clear enough, a 32bit library cannot resolve a 64bit
 dependency. So when you read in the available libraries and there
 dependencies you need to keep track of which type they are.

i debated adding a flag for that once and ended up with a 'not now, but maybe 
someday'

 Anyway, the -i flag to scanelf fixes that and other issues, just group
 all the data from scanelf by interpreter (so have multiple hashes, one
 for each interp).

yeah, that might be a better idea anyways ... after all, we dont want to limit 
our concept of different co-existing ABI's to just 32bit/64bit

also, you may want to use -F to control the output rather relying on the 
default output order
-mike
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] revdep-rebuild

2005-08-14 Thread Stefan Jones
On Sat, 2005-08-13 at 23:26 -0400, Mike Frysinger wrote:
 i've already contacted fuzzray about utilizing two packages solar put 
 together 
 (and can be found in portage already):
 pax-utils: scanelf
 portage-utils: qfile

Thanks for the ideas.

I had a quick look at the programs;

qfile: This would be useful in cleaning up the the last part of finding
which package the file belongs to. But that part is already fairly quick
compared to the rest.

scanelf: 

From what I can see scanelf can print what libraries a file needs but it
cannot say if the libraries are present.  For example:

/usr/bin/scanelf /bin/ls -n
 TYPE   NEEDED FILE
ET_EXEC librt.so.1,libncurses.so.5,libc.so.6 /bin/ls

So you would need to keep a list of all libraries to check against.
Thus I prefer using:
LD_TRACE_LOADED_OBJECTS=1 /lib/ld-linux.so.2 /bin/ls

But you could use ldconfig -p to gain a list of all the libraries, put
them in a hash table and then use scanelf.

All seems good,

Stefan

-- 
Stefan Jones [EMAIL PROTECTED]

-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] revdep-rebuild

2005-08-14 Thread Diego 'Flameeyes' Pettenò
On Sunday 14 August 2005 16:20, Stefan Jones wrote:
 But you could use ldconfig -p to gain a list of all the libraries, put
 them in a hash table and then use scanelf.
Please don't. FreeBSD's ldconfig is *not* the same and this would mean 
breaking (again) revdep-rebuild on Gentoo/FreeBSD.

-- 
Diego Flameeyes Pettenò
Gentoo Developer - http://dev.gentoo.org/~flameeyes/
(Gentoo/FreeBSD, Video, Gentoo/AMD64, Sound, PAM)


pgpwd9UQD69gb.pgp
Description: PGP signature


Re: [gentoo-dev] revdep-rebuild

2005-08-14 Thread Paul Varner
On Sun, 2005-08-14 at 16:32 +0200, Diego 'Flameeyes' Pettenò wrote:
 On Sunday 14 August 2005 16:20, Stefan Jones wrote:
  But you could use ldconfig -p to gain a list of all the libraries, put
  them in a hash table and then use scanelf.
 Please don't. FreeBSD's ldconfig is *not* the same and this would mean 
 breaking (again) revdep-rebuild on Gentoo/FreeBSD.
 

Actually, for the next major revision, I am planning on some major
collaboration between myself, the Gentoo/FreeBSD team, the OSX team,
solar/vapier, and anyone else that is interested.  

The biggest complaint right now is lack of speed and that means
investigating and exploring the different ways of determining library
breakage. Some of those solutions are definitely not portable.

Regards,
Paul

-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] revdep-rebuild

2005-08-14 Thread Stefan Jones
On Sun, 2005-08-14 at 09:52 -0500, Paul Varner wrote:
  Please don't. FreeBSD's ldconfig is *not* the same and this would mean 
  breaking (again) revdep-rebuild on Gentoo/FreeBSD.
  
  Some of those solutions are definitely not portable.
 

Well all we really need is the same utility to work across platforms,
different platforms could have different implementations for certain
functions. This has to be so if we are every going to have reasonable
performance.

But FreeBSD must have an equivalent function for it's dynamic linker to
ldconfig -p, if not some code could be written up to do it.

fuzzyray:
Want me to do anything useful in particular?

Had a quick look at Bug 63643. From what I can see that is a different
problem then what revdep-rebuild solves (missing shared libraries), as
you said. I think it can be best described as changing API between minor
revisions of libraries. Will think a bit more.

Stefan

-- 
Stefan Jones [EMAIL PROTECTED]

-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] revdep-rebuild

2005-08-13 Thread Yuri Vasilevski
Hi,

On Sat, 13 Aug 2005 18:01:05 -0700
Stefan Jones [EMAIL PROTECTED] wrote:

 So I have started making a small C program which does the
 Checking dynamic linking consistency... part of the revdep-rebuild
 program (I think this the the most time intensive part).

I think it'll be better/preferable if you make it an applet for
portage-utils.

Yuri.
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] revdep-rebuild

2005-08-13 Thread Mike Frysinger
On Saturday 13 August 2005 09:01 pm, Stefan Jones wrote:
 So I have started making a small C program which does the
 Checking dynamic linking consistency... part of the revdep-rebuild
 program (I think this the the most time intensive part).

i've already contacted fuzzray about utilizing two packages solar put together 
(and can be found in portage already):
pax-utils: scanelf
portage-utils: qfile

with scanelf, you can quickly build a list of all the files an ELF needs to 
run ... with qfile, you can identify the package the ELF belongs to

both packages are written in C and imho, are quite fast
-mike
-- 
gentoo-dev@gentoo.org mailing list