From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([69.77.167.62] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1JV6T4-0006Wg-Ez for garchives@archives.gentoo.org; Fri, 29 Feb 2008 14:44:10 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 6FB20E05F8; Fri, 29 Feb 2008 14:44:08 +0000 (UTC) Received: from smtp4.aruba.it (smtpd3.aruba.it [62.149.128.208]) by pigeon.gentoo.org (Postfix) with SMTP id 0AF71E05F8 for ; Fri, 29 Feb 2008 14:44:07 +0000 (UTC) Received: (qmail 24931 invoked by uid 89); 29 Feb 2008 14:44:04 -0000 Received: by simscan 1.1.0 ppid: 24922, pid: 24926, t: 0.0591s scanners: clamav: 0.88.4/m:40/d:1722 Received: from unknown (HELO ?198.135.0.108?) (contact@manuelmarano.com@62.101.126.208) by smtp4.aruba.it with SMTP; 29 Feb 2008 14:44:04 -0000 Message-ID: <47C81A07.6030200@manuelmarano.com> Date: Fri, 29 Feb 2008 15:43:19 +0100 From: manuel User-Agent: Thunderbird 2.0.0.9 (X11/20071031) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-amd64@lists.gentoo.org Reply-to: gentoo-amd64@lists.gentoo.org MIME-Version: 1.0 To: gentoo-amd64@lists.gentoo.org Subject: Re: [gentoo-amd64] Re: revdep-rebuild keep on detecting a broken link referred to libqt-mt.so.3 References: <47C6789C.2060508@manuelmarano.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------060407090905000600000800" X-Spam-Rating: smtp4.aruba.it 1.6.2 0/1000/N X-Archives-Salt: dacae509-1f8c-4935-b747-5ff1b2ba055b X-Archives-Hash: 9fca83ac589eebc5a999e80b7c4fd4f1 This is a multi-part message in MIME format. --------------060407090905000600000800 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Duncan ha scritto: > manuel posted 47C6789C.2060508@manuelmarano.com, > excerpted below, on Thu, 28 Feb 2008 10:02:20 +0100: > > >> Hi All, >> I've ran revdep-rebuild a couple of times this week and each time i >> run it it finds a broken link referred to libqt-mt.so.3 and each >> time It emerges >> app-emulation/emul-linux-x86-soundlibs-2007112 to correct the problem! >> but the broken link is still there!?? I can't fix it! any ideas? >> > > Realize that the emul-linux-x86 stuff is binary. That is, it's prebuilt; > the ebuild simply installs it, because compiling it as 32-bit on a 64-bit > multilib system is possible but rather a hassle to setup correctly, so > the 32-bit binary emul-linux stuff is provided as a convenience for those > who don't wish to go thru that hassle. > > As a binary, you can remerge it all day every day and it's not going to > change the binaries inside. Thus, you can't correct linking therein. A > new binary package would be required for that. > > However, such binaries aren't critical for a 64-bit system anyway. All > they do is support 32-bit binary-only games and the like, if you choose > to install and run them. Thus, the broken linkage isn't a big deal > unless it's stopping you from running that game or whatever, and even > then, it's not interfering with the normal functioning of the computer in > general. > > To fix it, you'd either need to wait for an updated build, merge whatever > additional emul-linux package it's linking against (but the remerge > should have cured the problem if it were that, as it would have pulled in > the other package), or do the whole 32-bit chroot thing and use it rather > than the emul-linux stuff. > > If all you wish to do is get revdep-rebuild to shutup, that is, set it to > ignore that package since remerging it isn't going to help, that's > possible too. See the revdep-rebuild manpage for the details, but > basically, you put an entry in either make.conf itself, or in a file in > /etc/revdep-rebuild, telling revdep-rebuild what to ignore. (This > feature has been in the ~arch revdep-rebuild version for some time. I > assume it's in arch-stable versions by now. If not and you're running > stable, consider running ~arch gentoolkit, using the appropriate > package.keywords entry.) > > Great!! thanks for the help Manuel --------------060407090905000600000800 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Duncan ha scritto: 
manuel <kaos@manuelmarano.com> posted 47C6789C.2060508@manuelmarano.com,
excerpted below, on  Thu, 28 Feb 2008 10:02:20 +0100:

  
Hi All,
I've ran revdep-rebuild a couple of times this week  and each  time i
run it it finds  a  broken link  referred  to  libqt-mt.so.3 and each
time It emerges
app-emulation/emul-linux-x86-soundlibs-2007112 to correct the problem!
but the broken link is still there!?? I can't fix it! any ideas?
    

Realize that the emul-linux-x86 stuff is binary.  That is, it's prebuilt; 
the ebuild simply installs it, because compiling it as 32-bit on a 64-bit 
multilib system is possible but rather a hassle to setup correctly, so 
the 32-bit binary emul-linux stuff is provided as a convenience for those 
who don't wish to go thru that hassle.

As a binary, you can remerge it all day every day and it's not going to 
change the binaries inside.  Thus, you can't correct linking therein.  A 
new binary package would be required for that.

However, such binaries aren't critical for a 64-bit system anyway.  All 
they do is support 32-bit binary-only games and the like, if you choose 
to install and run them.  Thus, the broken linkage isn't a big deal 
unless it's stopping you from running that game or whatever, and even 
then, it's not interfering with the normal functioning of the computer in 
general.

To fix it, you'd either need to wait for an updated build, merge whatever 
additional emul-linux package it's linking against (but the remerge 
should have cured the problem if it were that, as it would have pulled in 
the other package), or do the whole 32-bit chroot thing and use it rather 
than the emul-linux stuff.

If all you wish to do is get revdep-rebuild to shutup, that is, set it to 
ignore that package since remerging it isn't going to help, that's 
possible too.  See the revdep-rebuild manpage for the details, but 
basically, you put an entry in either make.conf itself, or in a file in 
/etc/revdep-rebuild, telling revdep-rebuild what to ignore.  (This 
feature has been in the ~arch revdep-rebuild version for some time.  I 
assume it's in arch-stable versions by now.  If not and you're running 
stable, consider running ~arch gentoolkit, using the appropriate 
package.keywords entry.)
Great!!
thanks for the help

Manuel
--------------060407090905000600000800-- -- gentoo-amd64@lists.gentoo.org mailing list