1 |
On 29/01/2017 16:02, John Covici wrote: |
2 |
> On Sun, 29 Jan 2017 08:41:59 -0500, |
3 |
> Responses in line. |
4 |
> |
5 |
> Alan McKinnon wrote: |
6 |
>> |
7 |
>> On 29/01/2017 12:11, John Covici wrote: |
8 |
>>> Hi. I am having a couple of preserved rebuild problems which I have |
9 |
>>> no idea how to fix. |
10 |
>> |
11 |
>> Ugh. Those problems are horrid to fix |
12 |
>> |
13 |
>>> |
14 |
>>> The first one is like this: |
15 |
>>>>>> package: sys-libs/binutils-libs-2.27 |
16 |
>>> * - /usr/lib64/libbfd-2.25.1.so |
17 |
>>> * used by |
18 |
>>> /usr/lib64/binutils/x86_64-pc-linux-gnu/2.25.1/libopcodes-2.25.1.so |
19 |
>>> (sys-devel/binutils-2.25.1-r1) |
20 |
>>> |
21 |
>>> And no matter how many times I recompile the suggested package(s) it |
22 |
>>> remains. Why is this happening and how can I fix? |
23 |
>> |
24 |
>> Let's establish first what portage thinks the problem is. What is the |
25 |
>> output of |
26 |
>> |
27 |
>> ldd /usr/lib64/binutils/x86_64-pc-linux-gnu/2.25.1/libopcodes-2.25.1.so |
28 |
>> |
29 |
> |
30 |
> linux-vdso.so.1 (0x00007fff91936000) |
31 |
> libbfd-2.25.1.so => /usr/lib64/libbfd-2.25.1.so |
32 |
> (0x00007fd3deeb7000) |
33 |
> libc.so.6 => /lib64/libc.so.6 |
34 |
> (0x00007fd3deb1e000) |
35 |
> libz.so.1 => /lib64/libz.so.1 |
36 |
> (0x00007fd3de906000) |
37 |
> libdl.so.2 => /lib64/libdl.so.2 |
38 |
> (0x00007fd3de702000) |
39 |
> /lib64/ld-linux-x86-64.so.2 |
40 |
> (0x000055f4cd0d2000) |
41 |
> |
42 |
>> and just for fun |
43 |
>> |
44 |
>> ldd /usr/lib64/libbfd-2.25.1.so |
45 |
> linux-vdso.so.1 (0x00007ffeac123000) |
46 |
> libz.so.1 => /lib64/libz.so.1 (0x00007fbaf1838000) |
47 |
> libdl.so.2 => /lib64/libdl.so.2 |
48 |
> (0x00007fbaf1634000) |
49 |
> libc.so.6 => /lib64/libc.so.6 (0x00007fbaf129a000) |
50 |
> /lib64/ld-linux-x86-64.so.2 |
51 |
> (0x00005643cb966000) |
52 |
> |
53 |
>> |
54 |
>> Plus, what are your USE flags for binutils. |
55 |
> I seem to have several binutils -- here is what I have: |
56 |
> Installed versions: 2.25.1-r1(2.25.1)(01:06:59 AM |
57 |
> 01/11/2017)(cxx nls zlib -multitarget -static-libs -test |
58 |
> -vanilla) 2.26.1(2.26.1)(07:16:43 AM 12/27/2016)(cxx nls |
59 |
> -multitarget -static-libs -test -vanilla) 2.27(2.27)(07:23:40 AM |
60 |
> 12/27/2016)(cxx nls -multitarget -static-libs -test -vanilla) |
61 |
|
62 |
|
63 |
All of that looks normal and correct, no problems. I can't see any |
64 |
reason why portage lost track of what it's preserving for binutils |
65 |
|
66 |
Unless someone else has a bright idea, I suggest you log a bug and see |
67 |
what the devs have to say |
68 |
|
69 |
> |
70 |
>> |
71 |
>>> |
72 |
>>> Now the second one is more complicated: |
73 |
>>>>>> package: media-video/ffmpeg-3.2.2 |
74 |
>>> * - /usr/lib64/libswscale.so.3 |
75 |
>>> * - /usr/lib64/libswscale.so.3.1.101 |
76 |
>>> * used by /usr/lib64/gstreamer-0.10/libgstffmpegscale.so |
77 |
>>> (media-plugins/gst-plugins-ffmpeg-0.10.13_p201211-r3) |
78 |
>>> * - /usr/lib64/libpostproc.so.53 |
79 |
>>> * - /usr/lib64/libpostproc.so.53.3.100 |
80 |
>>> * used by /usr/lib64/gstreamer-0.10/libgstpostproc.so |
81 |
>>> (media-plugins/gst-plugins-ffmpeg-0.10.13_p201211-r3) |
82 |
>>> * - /usr/lib64/libavcodec.so.56 |
83 |
>>> * - /usr/lib64/libavcodec.so.56.60.100 |
84 |
>>> * used by /usr/lib64/gstreamer-0.10/libgstffmpeg.so |
85 |
>>> (media-plugins/gst-plugins-ffmpeg-0.10.13_p201211-r3) |
86 |
>>> * used by /usr/lib64/gstreamer-0.10/libgstpostproc.so |
87 |
>>> (media-plugins/gst-plugins-ffmpeg-0.10.13_p201211-r3) |
88 |
>>> * - /usr/lib64/libavformat.so.56 |
89 |
>>> * - /usr/lib64/libavformat.so.56.40.101 |
90 |
>>> * used by /usr/lib64/gstreamer-0.10/libgstffmpeg.so |
91 |
>>> (media-plugins/gst-plugins-ffmpeg-0.10.13_p201211-r3) |
92 |
>>> * - /usr/lib64/libavutil.so.54 |
93 |
>>> * - /usr/lib64/libavutil.so.54.31.100 |
94 |
>>> * used by |
95 |
>>> /usr/lib64/gstreamer-0.10/libgstffmpeg.so |
96 |
>>> (media-plugins/gst-plugins-ffmpeg-0.10.13_p201211-r3) |
97 |
>>> * used by |
98 |
>>> /usr/lib64/gstreamer-0.10/libgstffmpegscale.so |
99 |
>>> (media-plugins/gst-plugins-ffmpeg-0.10.13_p201211-r3) |
100 |
>>> * used by |
101 |
>>> /usr/lib64/gstreamer-0.10/libgstpostproc.so |
102 |
>>> (media-plugins/gst-plugins-ffmpeg-0.10.13_p201211-r3) |
103 |
>>> * - /usr/lib64/libswresample.so.1 |
104 |
>>> * - /usr/lib64/libswresample.so.1.2.101 |
105 |
>>> |
106 |
>>> Now when I try to recompile it wants to upgrade, but the upgrade does |
107 |
>>> not emerge and there are so many depricated warnings and errors that I |
108 |
>>> have a link to the build log instead |
109 |
>>> |
110 |
>>> https://covici.com/owncloud/index.php/s/LOysHMSxcFDfLDD |
111 |
>>> |
112 |
>>> There is no ebuild for the original version in the tree, so I am |
113 |
>>> stumped here. |
114 |
>> |
115 |
>> This one rings a bell but I can't recall exactly what. |
116 |
>> |
117 |
>> I have several times in the past resolved these by brute force, |
118 |
>> unmerging the problem package and the thing it depends or or links to, |
119 |
>> then rebuilding both. |
120 |
>> |
121 |
>> Are you by chance running a mixed stable/testing system here? |
122 |
>> |
123 |
> |
124 |
> No, just testing. I could unmerge and re-emerge ffmpeg, but not the |
125 |
> plugin. |
126 |
|
127 |
Ah, but you can :-) |
128 |
|
129 |
portage keeps a copy of all installed ebuilds, very useful for cases |
130 |
like this: |
131 |
|
132 |
/var/db/pkg/cat/pkg-version/*ebuild |
133 |
|
134 |
Copy that to your local overlay so you can reinstall it. |
135 |
Alternatively, copy it somewhere safe and run |
136 |
ebuild /path/to/copy/of/<plugin>ebuild merge. |
137 |
This is ebuild, not portage, so it won't figure out dependencies for |
138 |
you; but that shouldn't be a problem as it's already installed and |
139 |
emerge world is happy with the situation |
140 |
|
141 |
|
142 |
|
143 |
-- |
144 |
Alan McKinnon |
145 |
alan.mckinnon@×××××.com |