Re: [gentoo-user] a couple of preserved-rebuild problems -- how to fix

[John Covici]

On Sun, 29 Jan 2017 09:13:34 -0500,
Alan McKinnon wrote:
>
> On 29/01/2017 16:02, John Covici wrote:
> > On Sun, 29 Jan 2017 08:41:59 -0500,
> > Responses in line.
> >
> > Alan McKinnon wrote:
> >>
> >> On 29/01/2017 12:11, John Covici wrote:
> >>> Hi.  I am having a couple of preserved rebuild problems which I have
> >>> no idea how to fix.
> >>
> >> Ugh. Those problems are horrid to fix
> >>
> >>>
> >>> The first one is like this:
> >>>>>> package: sys-libs/binutils-libs-2.27
> >>>  *  - /usr/lib64/libbfd-2.25.1.so
> >>>   *      used by
> >>>   /usr/lib64/binutils/x86_64-pc-linux-gnu/2.25.1/libopcodes-2.25.1.so
> >>>   (sys-devel/binutils-2.25.1-r1)
> >>>
> >>> And no matter how many times I recompile the suggested package(s)  it
> >>> remains.  Why is this happening and how can I fix?
> >>
> >> Let's establish first what portage thinks the problem is. What is the
> >> output of
> >>
> >> ldd /usr/lib64/binutils/x86_64-pc-linux-gnu/2.25.1/libopcodes-2.25.1.so
> >>
> >
> >         linux-vdso.so.1 (0x00007fff91936000)
> > 	           libbfd-2.25.1.so => /usr/lib64/libbfd-2.25.1.so
> > 	           (0x00007fd3deeb7000)
> > 			         libc.so.6 => /lib64/libc.so.6
> > 	           (0x00007fd3deb1e000)
> > 			         libz.so.1 => /lib64/libz.so.1
> > 	           (0x00007fd3de906000)
> > 			         libdl.so.2 => /lib64/libdl.so.2
> > 	           (0x00007fd3de702000)
> > 			         /lib64/ld-linux-x86-64.so.2
> > 	           (0x000055f4cd0d2000)
> >
> >> and just for fun
> >>
> >> ldd /usr/lib64/libbfd-2.25.1.so
> >         linux-vdso.so.1 (0x00007ffeac123000)
> > 	           libz.so.1 => /lib64/libz.so.1 (0x00007fbaf1838000)
> > 			         libdl.so.2 => /lib64/libdl.so.2
> >         (0x00007fbaf1634000)
> > 	           libc.so.6 => /lib64/libc.so.6 (0x00007fbaf129a000)
> > 			         /lib64/ld-linux-x86-64.so.2
> >         (0x00005643cb966000)
> >
> >>
> >> Plus, what are your USE flags for binutils.
> > I seem to have several binutils -- here is what I have:
> >      Installed versions:  2.25.1-r1(2.25.1)(01:06:59 AM
> > 	01/11/2017)(cxx nls zlib -multitarget -static-libs -test
> > 	-vanilla) 2.26.1(2.26.1)(07:16:43 AM 12/27/2016)(cxx nls
> > 	-multitarget -static-libs -test -vanilla) 2.27(2.27)(07:23:40 AM
> > 	12/27/2016)(cxx nls -multitarget -static-libs -test -vanilla)
>
>
> All of that looks normal and correct, no problems. I can't see any
> reason why portage lost track of what it's preserving for binutils
>
> Unless someone else has a bright idea, I suggest you log a bug and see
> what the devs have to say
>
> >
> >>
> >>>
> >>> Now the second one is more complicated:
> >>>>>> package: media-video/ffmpeg-3.2.2
> >>>  *  - /usr/lib64/libswscale.so.3
> >>>   *  - /usr/lib64/libswscale.so.3.1.101
> >>>    *      used by /usr/lib64/gstreamer-0.10/libgstffmpegscale.so
> >>>    (media-plugins/gst-plugins-ffmpeg-0.10.13_p201211-r3)
> >>>     *  - /usr/lib64/libpostproc.so.53
> >>>      *  - /usr/lib64/libpostproc.so.53.3.100
> >>> 	 *      used by /usr/lib64/gstreamer-0.10/libgstpostproc.so
> >>> 	 (media-plugins/gst-plugins-ffmpeg-0.10.13_p201211-r3)
> >>> 	  *  - /usr/lib64/libavcodec.so.56
> >>> 	   *  - /usr/lib64/libavcodec.so.56.60.100
> >>> 	    *      used by /usr/lib64/gstreamer-0.10/libgstffmpeg.so
> >>> 	    (media-plugins/gst-plugins-ffmpeg-0.10.13_p201211-r3)
> >>> 	     *      used by /usr/lib64/gstreamer-0.10/libgstpostproc.so
> >>> 		(media-plugins/gst-plugins-ffmpeg-0.10.13_p201211-r3)
> >>> 		 *  - /usr/lib64/libavformat.so.56
> >>> 		  *  - /usr/lib64/libavformat.so.56.40.101
> >>> 		   *      used by /usr/lib64/gstreamer-0.10/libgstffmpeg.so
> >>> 		   (media-plugins/gst-plugins-ffmpeg-0.10.13_p201211-r3)
> >>> 		    *  - /usr/lib64/libavutil.so.54
> >>> 		     *  - /usr/lib64/libavutil.so.54.31.100
> >>> 			 *      used by
> >>> 			 /usr/lib64/gstreamer-0.10/libgstffmpeg.so
> >>> 			 (media-plugins/gst-plugins-ffmpeg-0.10.13_p201211-r3)
> >>> 			  *      used by
> >>> 			  /usr/lib64/gstreamer-0.10/libgstffmpegscale.so
> >>> 			  (media-plugins/gst-plugins-ffmpeg-0.10.13_p201211-r3)
> >>> 			   *      used by
> >>> 			   /usr/lib64/gstreamer-0.10/libgstpostproc.so
> >>> 			   (media-plugins/gst-plugins-ffmpeg-0.10.13_p201211-r3)
> >>> 			    *  - /usr/lib64/libswresample.so.1
> >>> 			     *  - /usr/lib64/libswresample.so.1.2.101
> >>>
> >>> Now when I try to recompile it wants to upgrade, but the upgrade does
> >>> not emerge and there are so many depricated warnings and errors that I
> >>> have a link to the build log instead
> >>>
> >>> https://covici.com/owncloud/index.php/s/LOysHMSxcFDfLDD
> >>>
> >>> There is no ebuild for the original version in the tree, so I am
> >>> stumped here.
> >>
> >> This one rings a bell but I can't recall exactly what.
> >>
> >> I have several times in the past resolved these by brute force,
> >> unmerging the problem package and the thing it depends or or links to,
> >> then rebuilding both.
> >>
> >> Are you by chance running a mixed stable/testing system here?
> >>
> >
> > No, just testing.  I could unmerge and re-emerge ffmpeg, but not the
> > plugin.
>
> Ah, but you can :-)
>
> portage keeps a copy of all installed ebuilds, very useful for cases
> like this:
>
> /var/db/pkg/cat/pkg-version/*ebuild
>
> Copy that to your local overlay so you can reinstall it.
> Alternatively, copy it somewhere safe and run
> ebuild /path/to/copy/of/<plugin>ebuild merge.
> This is ebuild, not portage, so it won't figure out dependencies for
> you; but that shouldn't be a problem as it's already installed and
> emerge world is happy with the situation
>
>
>
> --
> Alan McKinnon
> alan.mckinnon@×××××.com
>
>
w
Thanks for that tip, I did not know about that, but unfortunately,
even when compiling that one, I get the same types of errors as with
the upgrade.

-- 
Your life is like a penny.  You're going to lose it.  The question is:
How do
you spend it?

         John Covici
         covici@××××××××××.com