1 |
On 06/04/2014 08:02 PM, Samuli Suominen wrote: |
2 |
> |
3 |
> On 05/06/14 02:15, Dutch Ingraham wrote: |
4 |
>> On 06/04/2014 03:17 PM, Samuli Suominen wrote: |
5 |
>>> On 04/06/14 20:11, Dutch Ingraham wrote: |
6 |
>>>> On 06/04/2014 07:22 AM, Daniel Troeder wrote: |
7 |
>>>>> Am 04.06.2014 06:05, schrieb Samuli Suominen: |
8 |
>>>>>> On 04/06/14 05:17, Dutch Ingraham wrote: |
9 |
>>>>>>> No, "sys-fs/udev" is not masked, but an update is indicated in the |
10 |
>>>>>>> emerge above. That's a good catch, the MATE stuff is from the overlay. |
11 |
>>>>>>> Unfortunately, the xfce stuff is not, so even if the overlay currency |
12 |
>>>>>>> was an issue, I'll still be showing some dependencies. |
13 |
>>>>>>> |
14 |
>>>>>> Try re-emerging on un-emerging the offending packages, like |
15 |
>>>>>> xfce4-session and xfce4-power-manager, |
16 |
>>>>>> it has helped some people, to refresh the .ebuild copy that is installed |
17 |
>>>>>> with the .ebuild copy from |
18 |
>>>>>> Portage |
19 |
>>>>>> |
20 |
>>>>>> - Samuli |
21 |
>>>>>> |
22 |
>>>>> Thanks - that fixed it for me: |
23 |
>>>>> |
24 |
>>>>> # emerge -C xfce-base/xfce4-session xfce-extra/xfce4-power-manager |
25 |
>>>>> xfce-extra/xfce4-systemload-plugin |
26 |
>>>>> # emerge -uND xfce-base/xfce4-meta xfce-extra/xfce4-power-manager |
27 |
>>>>> xfce-extra/xfce4-systemload-plugin |
28 |
>>>>> |
29 |
>>>>> |
30 |
>>>>> Greetings |
31 |
>>>>> Daniel |
32 |
>>>>> |
33 |
>>>> Unfortunately, this doesn't work for me. So let me re-cap: I have |
34 |
>>>> |
35 |
>>>> 4. masked virtual/udev-208-r2; that has not worked. |
36 |
>>> First, remove that mask. Masking it will certainly cause more blockers, |
37 |
>>> than solve them. |
38 |
>>> |
39 |
>>>> [ebuild N ~] mate-extra/mate-power-manager-1.6.3::mate-overlay |
40 |
>>>> USE="applet policykit -gnome-keyring -man {-test}" 0 kB |
41 |
>>>> [ebuild N ~] mate-base/mate-session-manager-1.6.1-r1::mate-overlay |
42 |
>>>> USE="ipv6 -debug -systemd" 0 kB |
43 |
>>>> |
44 |
>>> see "::mate-overlay", it's presumably broken or outdated. stop using the |
45 |
>>> overlay and use MATE from Portage instead. |
46 |
>>> or you can mask the packages from overlay, the syntax is like: |
47 |
>>> |
48 |
>>> /etc/portage/package.mask |
49 |
>>> |
50 |
>>> mate-extra/mate-power-manager::mate-overlay |
51 |
>>> mate-base/mate-session-manager::mate-overlay |
52 |
>>> |
53 |
>>> - Samuli |
54 |
>>> |
55 |
>>> |
56 |
>> Thanks everybody for your help. I've made the further suggested |
57 |
>> changes, but I remain with the three hard blocks. |
58 |
>> |
59 |
>> I've now spent about 7 hours over the last two days on this issue (about |
60 |
>> 2x the fresh install time), when all I wanted to do was a routine |
61 |
>> update. I've reworked a large part of my system, adding a new |
62 |
>> package.mask file and populating it with six packages. |
63 |
>> |
64 |
>> I suppose its now time for an uninstall. Kind of disappointing; we are |
65 |
>> told Gentoo is about choices, and in fact that's true. I made the |
66 |
>> choice to use a pure openRC system. The last 7 hours of free time, |
67 |
>> though, was spent trying, and ultimately failing, to correct a problem |
68 |
>> not chosen, not wanted, and not invited. |
69 |
>> |
70 |
>> The sine qua non is unarguably systemd. Even though my choice was to |
71 |
>> not deploy it, apparently it takes a significant time commitment and/or |
72 |
>> developer-level knowledge to choose to not use it. Quite the inelegant |
73 |
>> end to my once-trusty OS. |
74 |
>> |
75 |
> |
76 |
> Gentoo doesn't have write access to ::mate-overlay, it's completely |
77 |
> unofficial |
78 |
> Gentoo developers are just as much users as you are for ::mate-overlay |
79 |
> |
80 |
> Enough said |
81 |
> |
82 |
> - Samuli |
83 |
> |
84 |
> |
85 |
Sorry, but this isn't just a MATE overlay problem. Once I made your |
86 |
suggested changes, the MATE "mask change" requests disappeared. What I |
87 |
did get was XFCE mask requirements: |
88 |
|
89 |
[snip] |
90 |
|
91 |
The following mask changes are necessary to proceed: |
92 |
(see "package.unmask" in the portage(5) man page for more details) |
93 |
# required by xfce-base/xfce4-meta-4.10 |
94 |
# required by @selected |
95 |
# required by @world (argument) |
96 |
# /etc/portage/package.mask: |
97 |
# problems with systemd, upower shift to upower.pm.utils |
98 |
=xfce-base/xfce4-session-4.10.1-r1 |
99 |
# required by virtual/udev-208-r2 |
100 |
# required by sys-power/upower-0.9.23-r3 |
101 |
# required by xfce-base/xfce4-session-4.10.1-r1[udev] |
102 |
# required by xfce-base/xfce4-meta-4.10 |
103 |
# required by @selected |
104 |
# required by @world (argument) |
105 |
# /etc/portage/package.mask: |
106 |
# problems with systemd, upower shift to upower.pm.utils |
107 |
=sys-apps/systemd-212-r5 |
108 |
# required by sys-apps/systemd-212-r5[-vanilla] |
109 |
# required by sys-power/upower-0.9.23-r3 |
110 |
# required by xfce-base/xfce4-session-4.10.1-r1[udev] |
111 |
# required by xfce-base/xfce4-meta-4.10 |
112 |
# required by @selected |
113 |
# required by @world (argument) |
114 |
# /etc/portage/package.mask: |
115 |
# problems with systemd, upower shift to upower.pm.utils |
116 |
=sys-apps/gentoo-systemd-integration-4 |
117 |
|
118 |
[snip] |
119 |
|
120 |
I had already <emerge - C>'d those two XFCE applications because, early |
121 |
in this process an <equery depends upower> had shown them to be |
122 |
dependent upon "upower" even after emerging "upower-pm-utils." I have |
123 |
no confidence at this point that my particular problem is reasonably |
124 |
solvable, as I have been caught in this circle for three days now. |