Re: [gentoo-user] some capital B blockers in world update
On 14/03/2017 19:00, allan gottlieb wrote:
> On Tue, Mar 14 2017, Alan McKinnon wrote:
>
>> On 14/03/2017 16:43, allan gottlieb wrote:
>>> I update roughly twice a week. On one machine (full output below) I was
>>> told that libinput and evdev are blocking xorg-drivers
>>>
>>> [blocks B ] >> (">> x11-base/xorg-drivers-1.19)
>>> [blocks B ] >> (">> x11-base/xorg-drivers-1.19)
>>>
>>> However the merge does propose to update xorg-drivers
>>> [ebuild U ] x11-base/xorg-drivers-1.19 [1.18-r1] VIDEO_CARDS="-ark%
>>> -i915% -i965% (-newport) -sis%"
>>>
>>> It also proposes to update libinput and evdev
>>> [ebuild U ] x11-drivers/xf86-input-libinput-0.24.0 [0.19.0]
>>> [ebuild U ] x11-drivers/xf86-input-evdev-2.10.5 [2.10.3]
>>>
>>> I do see that the versions of libinput and evdev to be used are higher
>>> than the versions that would block xorg-drivers. I am wondering why in
>>> this case emerge is telling me about the block (in red with a capital B)
>>> and more importantly would appreciate confirmation that I should let the
>>> emerge proceed.
>>
>>
>> Portage found a solution that satisfies all constraints, so you should
>> let it proceed.
>>
>> Did you run emerge with -v to get the above?
>> That looks like portage is doing it's usual -v thing which is to core
>> dump to your console in the hope that maybe you can figure it out and
>> you are willing to play the game called "let's find out what portage
>> thinks it means today!"
>>
>> I don't understand why those blockers are marked hard, as portage found
>> a solution. The blocker lines are really telling you why portage wants
>> to upgrade your libinput and evdev drivers - the current ones won't work
>> with your current drivers.
>>
>> Which is all totally pointless, as newer versions of everything are
>> available and you want a full update. There's very little point in
>> software going to great lengths to tell you why it won't keep old
>> versions when you explicitly told it to not keep old versions :-)
>
> Thank you for the confirmation! I also doubt the use of B when b would
> be appropriated. No this was not a --verbose run. I would guess that
> output would be even less illuminating.
:-)
Portage is a lot like Sheldon from The Big Bang Theory. Everything it
says is completely correct, and most of us have no clue what it is
talking abut!
--
Alan McKinnon
alan.mckin...@gmail.com
Re: [gentoo-user] some capital B blockers in world update
On Tue, Mar 14 2017, Alan McKinnon wrote:
> On 14/03/2017 16:43, allan gottlieb wrote:
>> I update roughly twice a week. On one machine (full output below) I was
>> told that libinput and evdev are blocking xorg-drivers
>>
>> [blocks B ] > ("> x11-base/xorg-drivers-1.19)
>> [blocks B ] > ("> x11-base/xorg-drivers-1.19)
>>
>> However the merge does propose to update xorg-drivers
>> [ebuild U ] x11-base/xorg-drivers-1.19 [1.18-r1] VIDEO_CARDS="-ark%
>> -i915% -i965% (-newport) -sis%"
>>
>> It also proposes to update libinput and evdev
>> [ebuild U ] x11-drivers/xf86-input-libinput-0.24.0 [0.19.0]
>> [ebuild U ] x11-drivers/xf86-input-evdev-2.10.5 [2.10.3]
>>
>> I do see that the versions of libinput and evdev to be used are higher
>> than the versions that would block xorg-drivers. I am wondering why in
>> this case emerge is telling me about the block (in red with a capital B)
>> and more importantly would appreciate confirmation that I should let the
>> emerge proceed.
>
>
> Portage found a solution that satisfies all constraints, so you should
> let it proceed.
>
> Did you run emerge with -v to get the above?
> That looks like portage is doing it's usual -v thing which is to core
> dump to your console in the hope that maybe you can figure it out and
> you are willing to play the game called "let's find out what portage
> thinks it means today!"
>
> I don't understand why those blockers are marked hard, as portage found
> a solution. The blocker lines are really telling you why portage wants
> to upgrade your libinput and evdev drivers - the current ones won't work
> with your current drivers.
>
> Which is all totally pointless, as newer versions of everything are
> available and you want a full update. There's very little point in
> software going to great lengths to tell you why it won't keep old
> versions when you explicitly told it to not keep old versions :-)
Thank you for the confirmation! I also doubt the use of B when b would
be appropriated. No this was not a --verbose run. I would guess that
output would be even less illuminating.
allan
Re: [gentoo-user] some capital B blockers in world update
On 14/03/2017 16:43, allan gottlieb wrote:
> I update roughly twice a week. On one machine (full output below) I was
> told that libinput and evdev are blocking xorg-drivers
>
> [blocks B ] (" x11-base/xorg-drivers-1.19)
> [blocks B ] (" x11-base/xorg-drivers-1.19)
>
> However the merge does propose to update xorg-drivers
> [ebuild U ] x11-base/xorg-drivers-1.19 [1.18-r1] VIDEO_CARDS="-ark%
> -i915% -i965% (-newport) -sis%"
>
> It also proposes to update libinput and evdev
> [ebuild U ] x11-drivers/xf86-input-libinput-0.24.0 [0.19.0]
> [ebuild U ] x11-drivers/xf86-input-evdev-2.10.5 [2.10.3]
>
> I do see that the versions of libinput and evdev to be used are higher
> than the versions that would block xorg-drivers. I am wondering why in
> this case emerge is telling me about the block (in red with a capital B)
> and more importantly would appreciate confirmation that I should let the
> emerge proceed.
Portage found a solution that satisfies all constraints, so you should
let it proceed.
Did you run emerge with -v to get the above?
That looks like portage is doing it's usual -v thing which is to core
dump to your console in the hope that maybe you can figure it out and
you are willing to play the game called "let's find out what portage
thinks it means today!"
I don't understand why those blockers are marked hard, as portage found
a solution. The blocker lines are really telling you why portage wants
to upgrade your libinput and evdev drivers - the current ones won't work
with your current drivers.
Which is all totally pointless, as newer versions of everything are
available and you want a full update. There's very little point in
software going to great lengths to tell you why it won't keep old
versions when you explicitly told it to not keep old versions :-)
>
> thanks in advance,
> allan
>
> [nomerge ] x11-base/xorg-x11-7.4-r2
> [nomerge ] media-fonts/font-daewoo-misc-1.0.3
> [nomerge ] x11-apps/bdftopcf-1.0.5
> [ebuild U ]x11-libs/libXfont-1.5.2 [1.5.1]
> [nomerge ] x11-apps/xdm-1.1.11-r3
> [ebuild U ] x11-apps/xconsole-1.0.7 [1.0.6]
> [nomerge ] app-office/libreoffice-5.2.3.3-r1
> [nomerge ] sci-mathematics/lpsolve-5.5.2.0
> [nomerge ] sci-libs/colamd-2.8.0
> [ebuild U ]sci-libs/suitesparseconfig-4.2.1-r1 [4.2.1]
> ABI_X86="(64%*) -32% (-x32)"
> [nomerge ] gnome-base/gnome-3.20.0
> [nomerge ] gnome-base/gnome-extra-apps-3.20.0
> [nomerge ] gnome-extra/gnome-characters-3.20.1
> [ebuild U ]dev-libs/libunistring-0.9.7 [0.9.5] ABI_X86="(64%*) -32%
> (-x32)"
> [nomerge ] media-video/gnome-mplayer-1.0.9
> [nomerge ] x11-themes/gnome-icon-theme-symbolic-3.12.0
> [nomerge ] x11-misc/icon-naming-utils-0.8.90
> [nomerge ]dev-perl/XML-Simple-2.200.0-r1
> [ebuild U ] dev-perl/XML-LibXML-2.12.800-r1 [2.12.100]
> USE="-examples% -minimal%"
> [ebuild U ] www-client/firefox-45.8.0 [45.7.0]
> [ebuild U ] www-client/chromium-57.0.2987.98 [56.0.2924.76-r1]
> USE="system-libvpx%* -component-build% -gconf%"
> [nomerge ] gnome-base/gnome-3.20.0
> [nomerge ] gnome-base/gnome-core-apps-3.20.0
> [nomerge ] gnome-base/gnome-control-center-3.20.2-r1
> [nomerge ]x11-drivers/xf86-input-libinput-0.24.0 [0.19.0]
> [nomerge ] x11-base/xorg-server-1.19.2 [1.18.4] USE="-debug%"
> [nomerge ] x11-base/xorg-drivers-1.19 [1.18-r1] VIDEO_CARDS="-ark%
> -i915% -i965% (-newport) -sis%"
> [ebuild U ] x11-drivers/xf86-input-synaptics-1.9.0 [1.8.3]
> [ebuild U ] x11-drivers/xf86-video-intel-2.99.917_p20170216
> [2.99.917_p20160621-r1] USE="-tools%"
> [ebuild U ] net-misc/wget-1.19.1-r1 [1.18]
> [ebuild U ] x11-base/xorg-drivers-1.19 [1.18-r1] VIDEO_CARDS="-ark%
> -i915% -i965% (-newport) -sis%"
> [ebuild U ] x11-drivers/xf86-input-evdev-2.10.5 [2.10.3]
> [nomerge ] x11-base/xorg-drivers-1.19 [1.18-r1] VIDEO_CARDS="-ark%
> -i915% -i965% (-newport) -sis%"
> [ebuild U ] x11-drivers/xf86-input-libinput-0.24.0 [0.19.0]
> [ebuild U ]x11-base/xorg-server-1.19.2 [1.18.4] USE="-debug%"
> [ebuild U ] x11-apps/xauth-1.0.10 [1.0.9-r2] USE="{-test}"
> [ebuild U ]dev-libs/libinput-1.6.2 [1.4.2]
> [nomerge ] net-libs/webkit-gtk-2.14.5
> [ebuild U ] x11-libs/cairo-1.14.8 [1.14.6]
> [nomerge ] x11-base/xorg-x11-7.4-r2
> [ebuild U ] x11-apps/sessreg-1.1.1 [1.1.0]
> [nomerge ] x11-base/xorg-drivers-1.19 [1.18-r1] VIDEO_CARDS="-ark%
> -i915% -i965% (-newport) -sis%"
> [nomerge ] x11-drivers/xf86-input-evdev-2.10.5 [2.10.3]
> [nomerge ]x11-base/xorg-server-1.19.2 [1.18.4] USE="-debug%"
> [ebuild N ] x11-libs/libXfont2-2.0.1 USE="bzip2 ipv6 truetype -doc
> -static-libs"
> [ebuild U ]dev-libs/libevdev-1.5.6 [1.5.2]
> [nomerge ]
