[gentoo-user] emerge util-linx; util-linux and sysvinit block eachother.

[gentoo-user] emerge util-linx; util-linux and sysvinit block eachother.

[Alan Mackenzie]

Hi, Gentoo!

The latest episode of my months long update saga.

I do

    emerge -p --color y util-linux | less -F

, and get the following on my screen:

    [ebuild     U  ] sys-apps/util-linux-2.24.1-r2 [2.22.2] USE="bash-completion%* pam%* python%* -caps% -cytune% -fdformat% -tty-helpers%" PYTHON_SINGLE_TARGET="python2_7%* -python3_2% -python3_3% (-python3_4)" PYTHON_TARGETS="python2_7%* python3_3%* -python3_2% (-python3_4)"
     * Error: The above package list contains packages which cannot be
    [blocks B      ] <sys-apps/sysvinit-2.88-r7 ("<sys-apps/sysvinit-2.88-r7" is blocking sys-apps/util-linux-2.24.1-r2)
    [blocks B      ] >=sys-apps/util-linux-2.23 (">=sys-apps/util-linux-2.23" is blocking sys-apps/sysvinit-2.88-r4)
     * installed at the same time on the same system.

.  The up to date versions of these two packages are sysvinit-2.88.r7 and
util-linux-2.24.1-r2.

Am I right in thinking that the first of these "blocks B" lines is saying
that the latest util-linux is incompatible with the latest sysvinit -
that util-linux needs _less_ than sysvinit-2.88.r7?  This feels like a
bug.

What about the second "blocks B" line.  It seems to be saying that the
_old_ version util-linux-2.23 is blocking the _new_ sysvinit.  Why is
this comparison being done this way?

This all seems crazy.  Keeping Gentoo up to date shouldn't be this
difficult.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: [gentoo-user] emerge util-linx; util-linux and sysvinit block eachother.

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 1787 bytes --]

On Mon, 9 Jun 2014 11:28:03 +0000, Alan Mackenzie wrote:

>     emerge -p --color y util-linux | less -F
> 
> , and get the following on my screen:
> 
>     [ebuild     U  ] sys-apps/util-linux-2.24.1-r2 [2.22.2]
> USE="bash-completion%* pam%* python%* -caps% -cytune% -fdformat%
> -tty-helpers%" PYTHON_SINGLE_TARGET="python2_7%* -python3_2%
> -python3_3% (-python3_4)" PYTHON_TARGETS="python2_7%* python3_3%*
> -python3_2% (-python3_4)"
>      * Error: The above package list contains packages which cannot be
>     [blocks B      ] <sys-apps/sysvinit-2.88-r7
> ("<sys-apps/sysvinit-2.88-r7" is blocking
> sys-apps/util-linux-2.24.1-r2) [blocks B      ]
> >=sys-apps/util-linux-2.23 (">=sys-apps/util-linux-2.23" is blocking
> >sys-apps/sysvinit-2.88-r4)
>      * installed at the same time on the same system.
> 
> .  The up to date versions of these two packages are sysvinit-2.88.r7
> and util-linux-2.24.1-r2.
> 
> Am I right in thinking that the first of these "blocks B" lines is
> saying that the latest util-linux is incompatible with the latest
> sysvinit - that util-linux needs _less_ than sysvinit-2.88.r7?  This
> feels like a bug.
> 
> What about the second "blocks B" line.  It seems to be saying that the
> _old_ version util-linux-2.23 is blocking the _new_ sysvinit.  Why is
> this comparison being done this way?

Because you are only upgrading util-linux, so portage is trying to
install it alongside the older sysvinit you have installed (the latest
stable version is 2.88-r7). If you emerge -u @system, portage should
resolve it correctly, it is your trying to update interdependent packages
piecemeal that results in the blocker.


-- 
Neil Bothwick

Did you hear about the blind prostitute? You have to hand it to her.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [gentoo-user] emerge util-linx; util-linux and sysvinit block eachother.

[Andreas K. Huettel]

[-- Attachment #1: Type: Text/Plain, Size: 797 bytes --]

Am Montag, 9. Juni 2014, 13:28:03 schrieb Alan Mackenzie:
> Hi, Gentoo!
> 
> The latest episode of my months long update saga.
> 
[snip]
> 
> This all seems crazy.  Keeping Gentoo up to date shouldn't be this
> difficult.

You are making it artificially complicated by doing it piecewise. Whenever you 
try to update only part of your tree, emerge cannot do changes anywhere else, 
which means that other stuff can block your intended changes.

emerge can do a lot more if you let it run over the whole world set. 

[which doesnt mean that blockers are impossible then. just that emerge has a 
lot more free hand to work around them.]

emerge -uDNavt --backtrack=100 world

-- 

Andreas K. Huettel
Gentoo Linux developer 
dilfridge@gentoo.org
http://www.akhuettel.de/


[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 966 bytes --]

Re: [gentoo-user] emerge util-linx; util-linux and sysvinit block eachother.

[Alan McKinnon]

On 09/06/2014 21:15, Andreas K. Huettel wrote:
> Am Montag, 9. Juni 2014, 13:28:03 schrieb Alan Mackenzie:
>> Hi, Gentoo!
>>
>> The latest episode of my months long update saga.
>>
> [snip]
>>
>> This all seems crazy.  Keeping Gentoo up to date shouldn't be this
>> difficult.
> 
> You are making it artificially complicated by doing it piecewise. Whenever you 
> try to update only part of your tree, emerge cannot do changes anywhere else, 
> which means that other stuff can block your intended changes.
> 
> emerge can do a lot more if you let it run over the whole world set. 
> 
> [which doesnt mean that blockers are impossible then. just that emerge has a 
> lot more free hand to work around them.]
> 
> emerge -uDNavt --backtrack=100 world
> 


+1 to just letting portage work with world.

What I have found useful when trying to do what Alan is attempting, is
to select a chunk of packages at a time (like say all of kde, then a
bunch of daemons). If I get a block, drop it and try the next chunk.
Don't try fiddle, just proceed with things that will update without
tripping over everything else.

In this way you can whittle down the gigantic list of things portage
wants to update bit by bit till a world update gets to a manageable length.

Still easier to just do everything at once



-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] emerge util-linx; util-linux and sysvinit block eachother.

[thegeezer]

On 06/09/2014 10:01 PM, Alan McKinnon wrote:
> On 09/06/2014 21:15, Andreas K. Huettel wrote:
>> Am Montag, 9. Juni 2014, 13:28:03 schrieb Alan Mackenzie:
>>> Hi, Gentoo!
>>>
>>> The latest episode of my months long update saga.
>>>
>> [snip]
>>> This all seems crazy.  Keeping Gentoo up to date shouldn't be this
>>> difficult.
>> You are making it artificially complicated by doing it piecewise. Whenever you 
>> try to update only part of your tree, emerge cannot do changes anywhere else, 
>> which means that other stuff can block your intended changes.
>>
>> emerge can do a lot more if you let it run over the whole world set. 
>>
>> [which doesnt mean that blockers are impossible then. just that emerge has a 
>> lot more free hand to work around them.]
>>
>> emerge -uDNavt --backtrack=100 world
>>
>
> +1 to just letting portage work with world.
>
> What I have found useful when trying to do what Alan is attempting, is
> to select a chunk of packages at a time (like say all of kde, then a
> bunch of daemons). If I get a block, drop it and try the next chunk.

you might also like to know about my favourite flag "keep-going", which
drops the failed emerge and goes to the next non-dependent on what failed.
emerge -uDNa --keep-going

> Don't try fiddle, just proceed with things that will update without
> tripping over everything else.
>
> In this way you can whittle down the gigantic list of things portage
> wants to update bit by bit till a world update gets to a manageable length.
>
> Still easier to just do everything at once
>
>
>

Re: [gentoo-user] emerge util-linx; util-linux and sysvinit block eachother.

[Alan McKinnon]

On 10/06/2014 12:36, thegeezer wrote:
>> +1 to just letting portage work with world.
>> >
>> > What I have found useful when trying to do what Alan is attempting, is
>> > to select a chunk of packages at a time (like say all of kde, then a
>> > bunch of daemons). If I get a block, drop it and try the next chunk.
> you might also like to know about my favourite flag "keep-going", which
> drops the failed emerge and goes to the next non-dependent on what failed.
> emerge -uDNa --keep-going
> 


I know about --keep-going, I don't like it much.

It's also a different topic, what's being mentioned here is how to get
past the bit where portage fails to give an emerge list due to blockers.



-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] emerge util-linx; util-linux and sysvinit block eachother.

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 396 bytes --]

On Tue, 10 Jun 2014 15:35:57 +0200, Alan McKinnon wrote:

> I know about --keep-going, I don't like it much.

What's not to like? Do you like a long emerge list aborting as soon as
you turn your back because of a missing patch file in a minor package?


-- 
Neil Bothwick

How is it that we put man on the moon before we figured out it would be a
good idea to put wheels on luggage?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [gentoo-user] emerge util-linx; util-linux and sysvinit block eachother.

[Alan McKinnon]

On 10/06/2014 16:27, Neil Bothwick wrote:
> On Tue, 10 Jun 2014 15:35:57 +0200, Alan McKinnon wrote:
> 
>> I know about --keep-going, I don't like it much.
> 
> What's not to like? Do you like a long emerge list aborting as soon as
> you turn your back because of a missing patch file in a minor package?
> 
> 

Yes, exactly. For two reasons:

1. In the vast majority of cases, there's something to deal with and I
like to deal with it now. Missing patch files are comparatively rare for
me, whereas X doesn't build with the latest version of Y is somewhat
common. I'd rather mask the new version of Y and let portage re-figure
things out.

2. My over-the-top OCDness won't let me leave the bloody thing alone and
let it finish, if I know there's an error in there I feel compelled to
hit Ctrl-C and find out what the error is :-)



-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] emerge util-linx; util-linux and sysvinit block eachother.

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 1590 bytes --]

On Tue, 10 Jun 2014 19:06:19 +0200, Alan McKinnon wrote:

> > What's not to like? Do you like a long emerge list aborting as soon as
> > you turn your back because of a missing patch file in a minor package?
> 
> Yes, exactly. For two reasons:
> 
> 1. In the vast majority of cases, there's something to deal with and I
> like to deal with it now. Missing patch files are comparatively rare for
> me, whereas X doesn't build with the latest version of Y is somewhat
> common. I'd rather mask the new version of Y and let portage re-figure
> things out.

Yes, but the packages that continue have nothing to do with the error, so
it makes sense to get them out the way so only the problem packages are
left. Also, when there's yet-another-bloody-chromium-update and I set it
running and go to do something useful, I don't want to come back two
hours later to find it didn't even try to build chromium because
sys-unrelated/foo failed.

Also, occasionally, I find that running the update again compiles the
program correctly this time. This happens quite often with KDE updates
when kdm and one or two others fail on the first pass, but work next
time.

> 2. My over-the-top OCDness won't let me leave the bloody thing alone and
> let it finish, if I know there's an error in there I feel compelled to
> hit Ctrl-C and find out what the error is :-)

I understand that only too well, but I find it less destructive to look
at the log for the failed build while the others continue :P


-- 
Neil Bothwick

Evolution stops when stupidity is no longer fatal!

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [gentoo-user] emerge util-linx; util-linux and sysvinit block eachother.

[Alan McKinnon]

On 10/06/2014 20:29, Neil Bothwick wrote:
> On Tue, 10 Jun 2014 19:06:19 +0200, Alan McKinnon wrote:
> 
>>> What's not to like? Do you like a long emerge list aborting as soon as
>>> you turn your back because of a missing patch file in a minor package?
>>
>> Yes, exactly. For two reasons:
>>
>> 1. In the vast majority of cases, there's something to deal with and I
>> like to deal with it now. Missing patch files are comparatively rare for
>> me, whereas X doesn't build with the latest version of Y is somewhat
>> common. I'd rather mask the new version of Y and let portage re-figure
>> things out.
> 
> Yes, but the packages that continue have nothing to do with the error, so
> it makes sense to get them out the way so only the problem packages are
> left. Also, when there's yet-another-bloody-chromium-update and I set it
> running and go to do something useful, I don't want to come back two
> hours later to find it didn't even try to build chromium because
> sys-unrelated/foo failed.
> 
> Also, occasionally, I find that running the update again compiles the
> program correctly this time. This happens quite often with KDE updates
> when kdm and one or two others fail on the first pass, but work next
> time.
> 
>> 2. My over-the-top OCDness won't let me leave the bloody thing alone and
>> let it finish, if I know there's an error in there I feel compelled to
>> hit Ctrl-C and find out what the error is :-)
> 
> I understand that only too well, but I find it less destructive to look
> at the log for the failed build while the others continue :P
> 
> 


I understand you completely, and I also understand Alan completely :-)

I'm an old fart, set in my ways, I found something long ago that works
for me with unsufficient pain to provoke a change.

So I ain't changin' :-)



-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] emerge util-linx; util-linux and sysvinit block eachother.

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 533 bytes --]

On Tue, 10 Jun 2014 21:33:16 +0200, Alan McKinnon wrote:

> I'm an old fart, set in my ways, I found something long ago that works
> for me with unsufficient pain to provoke a change.

I clearly have a lower pain threshold than you :(
 
> So I ain't changin' :-)

Good thing it's an option then ;-)

And no, I don't have it turned on by default, but it is in my alias for a
world update - but not in my system alias update, I ain't that trusting...


-- 
Neil Bothwick

The thrill of victory, the agony of delete.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [gentoo-user] emerge util-linx; util-linux and sysvinit block eachother.

[Alan Mackenzie]

Hi, Andreas.

On Mon, Jun 09, 2014 at 09:15:48PM +0200, Andreas K. Huettel wrote:
> Am Montag, 9. Juni 2014, 13:28:03 schrieb Alan Mackenzie:
> > Hi, Gentoo!

> > The latest episode of my months long update saga.

> [snip]

> > This all seems crazy.  Keeping Gentoo up to date shouldn't be this
> > difficult.

> You are making it artificially complicated by doing it piecewise. Whenever you 
> try to update only part of your tree, emerge cannot do changes anywhere else, 
> which means that other stuff can block your intended changes.

I tried to break it down into manageable pieces when doing the whole
world at once gave too many errors.

> emerge can do a lot more if you let it run over the whole world set. 

> [which doesnt mean that blockers are impossible then. just that emerge has a 
> lot more free hand to work around them.]

I've not got blockers at the moment.  They might come back again later.

> emerge -uDNavt --backtrack=100 world

    emerge -vtpuND --backtrack=100 --color y world 2>&1 | less

gives me this (without deletia):

    These are the packages that would be merged, in reverse order:
 
    Calculating dependencies  ... done!

    !!! Multiple package instances within a single package slot have been pulled
    !!! into the dependency graph, resulting in a slot conflict:

    dev-libs/icu:0

      (dev-libs/icu-51.1::gentoo, installed) pulled in by
        dev-libs/icu:0/51.1= required by (media-libs/harfbuzz-0.9.23::gentoo, installed)

      (dev-libs/icu-52.1::gentoo, ebuild scheduled for merge) pulled in by
        dev-libs/icu:=[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?] required by (dev-libs/libxml2-2.9.1-r4::gentoo, ebuild scheduled for merge)

    dev-lang/perl:0

      (dev-lang/perl-5.16.3::gentoo, ebuild scheduled for merge) pulled in by
        (no parents that aren't satisfied by other packages in this slot)

      (dev-lang/perl-5.12.4-r1::gentoo, installed) pulled in by
        dev-lang/perl:0/0= required by (net-print/cups-filters-1.0.53::gentoo, installed)

    app-text/poppler:0

      (app-text/poppler-0.24.3::gentoo, installed) pulled in by
        app-text/poppler:0/43=[cxx,jpeg,lcms,tiff,xpdf-headers(+)] required by (net-print/cups-filters-1.0.53::gentoo, installed)

      (app-text/poppler-0.26.1::gentoo, ebuild scheduled for merge) pulled in by
        (no parents that aren't satisfied by other packages in this slot)


    It may be possible to solve this problem by using package.mask to
    prevent one of those packages from being selected. However, it is also
    possible that conflicting dependencies exist such that they are
    impossible to satisfy simultaneously.  If such a conflict exists in
    the dependencies of two different packages, then those packages can
    not be installed simultaneously.

    For more information, see MASKED PACKAGES section in the emerge man
    page or refer to the Gentoo Handbook.


    emerge: there are no ebuilds to satisfy "media-libs/libpng:0/0=".
    (dependency required by "app-text/poppler-0.24.3" [installed])
    (dependency required by "net-print/cups-filters-1.0.53" [installed])
    (dependency required by "net-print/cups-1.7.1-r1" [installed])
    (dependency required by "x11-libs/gtk+-2.24.23[cups]" [ebuild])
    (dependency required by "www-client/firefox-bin-24.5.0" [ebuild])
    (dependency required by "@selected" [set])
    (dependency required by "@world" [argument])

    !!! The ebuild selected to satisfy ">=dev-libs/libattica-0.4.2" has unmet requirements.
    - dev-libs/libattica-0.4.2::gentoo USE="-debug -qt4 (-qt5) -test"

      The following REQUIRED_USE flag constraints are unsatisfied:
        exactly-one-of ( qt4 qt5 )

    (dependency required by "kde-base/kdelibs-4.12.5" [ebuild])
    (dependency required by "@selected" [set])
    (dependency required by "@world" [argument])


.  dev-libs/icu is a low(ish) level system utility.  Why should I, as a
user, have to worry about icu-51.1 and icu-52.1?  That's the job of the
package manager.  The fact that portage has, somehow, got its internal
records into a state where it wants to merge both of these is surely a
bug.  Is this, perhaps, the situation that revdep-rebuild used to solve
so inelegantly?

Likewise, I have libpng-1.6.10, the latest version, installed.  Why
"there are no ebuilds to satisfy "media-libs/libpng:0/0="" isn't
something I feel I should have to worry about.  I don't even know what
":0/0=" means, although I remember other Alan explaining it to me in an
email back in Februrary. 

I feel a victim of portage's flexibility and rich feature set, much like
I feel a victim of CUPS's flexibility and rich feature set.  At the
moment, I'm determined not to become a victim of systemd's flexibility
and rich feature set.  I long for infrastructure components which are
simple and robust.  (I put openrc and lprng into that category.)

I have never done anything adventurous with portage, only regularly
updated my (stable) system, while I still could.  Things went crazy when
Gnome 3 was made stable and I tried to switch to xfce to avoid having to
switch to systemd.  I started my latest update attempt in February, but
it fell to one side as I had lots of other things to do.  I foresee
several weekends more of mind-numbing drudgery before finally getting my
system back to a state where it can be regularly updated.

Anyhow, thanks for all the help, and hope you had a good bank holiday.
:-)

> -- 

> Andreas K. Huettel
> Gentoo Linux developer 
> dilfridge@gentoo.org
> http://www.akhuettel.de/

-- 
Alan Mackenzie (Nuremberg, Germany)

Re: [gentoo-user] emerge util-linx; util-linux and sysvinit block eachother.

[Andreas K. Huettel]

[-- Attachment #1: Type: Text/Plain, Size: 3117 bytes --]


Hi Alan, 

first of all, which portage version are you using? Even if you are otherwise 
always running a stable system, in this case it might be useful to update 
portage (only) to ~arch. The errors that you are seeing are in an area of the 
dependency resolver that people are actively working on now, and nearly all 
gentoo devs are running ~arch portage. 

Add 
sys-apps/portage ~amd64
in /etc/portage/package.accept_keywords, then
emerge -a1u portage

Then, let's first fix the REQUIRED_USE issue from the end of the log. This is 
something portage cannot do on its own.

>     !!! The ebuild selected to satisfy ">=dev-libs/libattica-0.4.2" has
> unmet requirements. - dev-libs/libattica-0.4.2::gentoo USE="-debug -qt4
> (-qt5) -test"
> 
>       The following REQUIRED_USE flag constraints are unsatisfied:
>         exactly-one-of ( qt4 qt5 )
> 
>     (dependency required by "kde-base/kdelibs-4.12.5" [ebuild])
>     (dependency required by "@selected" [set])
>     (dependency required by "@world" [argument])

I suggest you set the qt4 use flag for libattica (since qt5 is not in the tree 
yet), e.g. add 
dev-libs/libattica qt4
to /etc/portage/package.use

Then try again... Things might work now. 
If not, try backtrack 1000. 
If not, ... better send the new error message. 

Alternatively, 

>     app-text/poppler:0
> 
>       (app-text/poppler-0.24.3::gentoo, installed) pulled in by
>         app-text/poppler:0/43=[cxx,jpeg,lcms,tiff,xpdf-headers(+)] required
> by (net-print/cups-filters-1.0.53::gentoo, installed)
> 
>       (app-text/poppler-0.26.1::gentoo, ebuild scheduled for merge) pulled
> in by (no parents that aren't satisfied by other packages in this slot)

All the other messages are caused by the subslot rebuild mechanism: If you 
check in detail, from the "two different packages" pulled in, the old one 
always has a "subslot setting", e.g. app-text/poppler:0/43 (the "/43") and the 
new required version has a different subslot (not printed unfortunately, but 
app-text/poppler-0.26.1 has "/46"). Similar reasoning applies to ICU, Perl, 
and libpng. 

This is the area actively under improvement that I mentioned above. Basically 
the difference between "/44" and "/46" tells portage "After upgrading poppler, 
rebuild everything that links against it".

While the automated rebuilds are a very nice thing (they make revdep-rebuild 
and perl-cleaner obsolete), they also make figuring things out for portage 
very very difficult. So, one last resort is to switch them off. Not 
recommended for regular operation, just if there is absolutely no way to get 
around problems. 

emerge -vtpuND --backtrack=100 --color y --ignore-built-slot-operator-deps y 
world

What happens now?

(If you run this command without the -p you will have to run "emerge 
@preserved-rebuild" and "perl-cleaner --all" immediately afterwards, maybe 
more than once. Just like in old times.)

Cheers from Regensburg, 
Andreas

-- 

Andreas K. Huettel
Gentoo Linux developer 
dilfridge@gentoo.org
http://www.akhuettel.de/


[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 966 bytes --]

Re: [gentoo-user] emerge util-linx; util-linux and sysvinit block eachother.

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 759 bytes --]

On Mon, 9 Jun 2014 21:04:30 +0000, Alan Mackenzie wrote:

> > You are making it artificially complicated by doing it piecewise.
> > Whenever you try to update only part of your tree, emerge cannot do
> > changes anywhere else, which means that other stuff can block your
> > intended changes.  
> 
> I tried to break it down into manageable pieces when doing the whole
> world at once gave too many errors.

Except that by breaking it down it becomes less manageable for portage.
You are asking portage to manage dependencies with one hand tied behindit
back.

If emerge -u @world is too long a list, update @system first, which will
take care of sysvinit and util-linux.


-- 
Neil Bothwick

Always remember to pillage before you burn.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 181 bytes --]