Re: [gentoo-user] update problems

[lee]

Alan Mackenzie  writes:

> Hello, Lee.
>
> On Tue, Sep 29, 2015 at 08:45:10PM +0200, lee wrote:
>> Neil Bothwick  writes:
>
>> > Patches are always more welcome than suggestions. "Fix it!" is never as
>> > welcome as "here's how". I think it was Canek who said "code talks". 
>
>> Do you have an example for such a case?
>
> Yes, many.  I'm a contributor to Emacs, and relatively frequently (perhaps
> 10 - 30 times a yeaar) somebody reports a bug and simultaneously submits
> a patch for it.  This is always well received,

I sent in a contribution to emacs, too, and never even heard anything
back.

> On the other hand, "wouldn't X be a good idea"s which reach the mailing
> list only rarely get taken up by regular contributors - there's only so
> much time in the day, and such hackers usually have plenty of Xs of
> their own to fill their time with.

That apparently means that nobody is allowed to suggest something and/or
to discuss a suggestion, and that everyone must have an "I don't care"
attitude.

>> My experience has disproved this claim, and I've even seen people
>> fixing stuff multiple times after I told them it's broken and provided
>> a perfectly working version before telling them, much better coded,
>> which they could have used instead of insisting on their crappy code
>> and trying to fix it several times.
>
> That's not very friendly,

How is it not friendly to point out a bug when you find one, at the same
time pointing to what fixes it?

> and hardly inclined to gain extra contributors
> for your project.  A gentle guiding hand, helping these other people to
> reach a satisfactory fix themselves, would work much better.

It wasn't my project but software I'm using and had made a fork of.  So
I noticed what upstream changed, found it to be broken, fixed it and
notified them that it's broken and how, and that there's a fix they can
use.  They didn't use the fix, made a couple attempts to fix their own
code until it finally worked, and though it now works, their code still
sucks.

So the most logical conclusion is not to report bugs and not to provide
any fixes or contributions, and not dare to suggest anything because at
best, it leads to nothing, and most of the time, you're being told that
you're a clueless idiot and to shut up.  OTOH, you often times get to
hear and/or see that peoples' contributions and help are wanted and that
there are always not enough contributers.  But why ask for more
contributers when contributions aren't wanted anyway?

>> > On the contrary, it serves to illustrate that you do not grasp the
>> > complexity of the situation.
>
>> Perhaps you can enlighten me how it is so difficult to change a message
>> from "slot conflict" to "slot conflict (can probably be ignored while
>> there are other problems)" and what the complexity is which makes it
>> impossible to do so.
>
> It's not difficult, it's just tedious.  Something like that which is
> user facing needs to be agreed by the core of the project, and getting
> that agreement tends to involve lots of bike shedding on the project
> mailing lists - there's always a few people who'll prefer the message to
> stay the same.

That is a bad situation which might help to explain why projects neither
want contributions, nor contributers.  Yet it doesn't mean that those
who would like to contribute shall receive the blame for the bad
situation the project is in, nor that it is wise to put them off.

It also indicates that the argument "go ahead and supply a patch" is
entirely inappropriate beyond being merely condescending, and that
arguing along the lines that the contributers aren't being payed and
that /you/ aren't contributing anyway is even worse.  None of them are
acceptable under these conditions.  They are irrelevant.

> Then there's all the stuff about writing change logs for the change
> and commiting it.

How is that being too tedious?  If it really is too tedious, is there a
way to make it less tedious?

> Such a tiny change is scarcely achievable in less than an hour.  To
> the core developers, it barely seems worth it.

So nobody do anything because it isn't worth it.  That's a great
attitude.


-- 
Again we must be afraid of speaking of daemons for fear that daemons
might swallow us.  Finally, this fear has become reasonable.

Re: [gentoo-user] update problems

[lee]

Neil Bothwick  writes:

> On Tue, 29 Sep 2015 20:45:10 +0200, lee wrote:
>
>> Neil Bothwick  writes:
>> 
>> > Patches are always more welcome than suggestions. "Fix it!" is never
>> > as welcome as "here's how". I think it was Canek who said "code
>> > talks".   
>> 
>> Do you have an example for such a case?
>
> Just look at b.g.o. Many bug reports include a patch submitted by a user
> that makes its way into the tree.

What is b.g.o.?

>> My experience has disproved
>> this claim, and I've even seen people fixing stuff multiple times after
>> I told them it's broken and provided a perfectly working version before
>> telling them, much better coded, which they could have used instead of
>> insisting on their crappy code and trying to fix it several times.
>
> You cannot judge one group of people on the behaviour of an unrelated
> group.

But I can observe the behaviour of many similar groups of people, or of
people, and come to a conclusion about what behaviour can be
expected. That with very few exceptions, neither bug reports, nor fixes
are wanted, is an observation.  I suppose I should have expected the
same behaviour here, and I made the mistake to think that I might
encounter different behaviour here.


> [...]
> #!/usr/lib/python-exec/python-exec2-c
> [...]
>
> In there you will find python2.7/emerge and python3.4/emerge (depending
> on which Python versions you have installed).

ok

>> I don't believe that they let everyone modify what they're working on,
>> so they are the only ones who /can/ fix it.  Besides, show me where I
>> said something like "I want the devs to fix it".
>
> They don't. You submit the modifications in the bug report and they vet
> and apply the patches.

Obviously, no patch is wanted.

>> > Adding the word "just" to a demand does not make the task any
>> > simpler, nor does it increase your chances of getting what you want.  
>> 
>> Go ahead and show me where I have demanded something.
>
> Your insistence that it should be changed amounts to a demand. Your
> assertion that it can be done easily only demeans the efforts of the
> devs, implying that the fix is simple but they cannot be bothered.

I'm not insisting at all.  I'm merely saying that it could easily be
fixed.  So people say it's not easy to fix but incredibly difficult, and
I say that fixing a "print" statement in some script can't be so
incredibly difficult to fix.  Then people agree and give other reasons
--- which have nothing to do with changing a "print" statement --- for
why this is difficult to do.

Some of what they say indicates that the devs cannot be bothered.  How
you conclude that something which could be done easily and isn't demeans
anyones efforts escapes me.  However, you would have to blame the people
saying that the devs cannot be bothered, not me.

>> > On the contrary, it serves to illustrate that you do not grasp the
>> > complexity of the situation.  
>> 
>> Perhaps you can enlighten me how it is so difficult to change a message
>> from "slot conflict" to "slot conflict (can probably be ignored while
>> there are other problems)" and what the complexity is which makes it
>> impossible to do so.
>
> Changing the message is trivial, knowing when to change it is not. Unless
> you can provide a means to tell unimportant slot conflicts from important
> ones, Context is everything and the variety of Gentoo systems out there
> make it extremely difficult for portage to understand the context in
> human terms. 

You don't need to know when to change it.  Once someone finds that they
still cannot update after fixing all other issues, they are able to
figure out that they may not ignore the message.  Apparently it rarely
happens that they may not ignore the message.

Some time, there might be a way to know when to change the message, and
even better messages could be used.  Until then, a small change would go
a long way towards making the system more friendly for the users.  So
why make things difficult for everyone --- for the devs by asking for an
ultimate fix and for the users by giving them misleading messages ---
rather than making things easier by using messages less misleading while
the devs can their time until they find the ultimate fix?

I'd give them credit for taking that step.  Can you explain how taking
such a step, or even suggesting to take it, could demean their efforts?


-- 
Again we must be afraid of speaking of daemons for fear that daemons
might swallow us.  Finally, this fear has become reasonable.

Re: [gentoo-user] update problems

[allan gottlieb]

On Sat, Oct 03 2015, l...@yagibdah.de wrote:

> What is b.g.o.?

http://bugs.gentoo.org

allan

Re: [gentoo-user] update problems

[Neil Bothwick]

On Thu, 1 Oct 2015 07:10:52 -0400, Rich Freeman wrote:

> Short-term if somebody wants to write up a wiki page full of common
> confusing portage error messages and improved versions of the same,
> and instructions on how to handle each situation, that would both help
> users today, and give the portage devs something to contemplate in
> their enhancements.  There is no reason portage couldn't even figure
> out which case an error falls into and either output the text on the
> page or give the user a link to go look up instructions on how to
> resolve.

Yes, I mentioned that earlier in this thread, but haven't had a chance to
do anything more constructive about it yet.


-- 
Neil Bothwick

"It compiled? The first screen came up? Ship it!" -- Bill Gates


pgp7mLUPyDgTz.pgp
Description: OpenPGP digital signature

Re: [gentoo-user] update problems

[Rich Freeman]

On Thu, Oct 1, 2015 at 5:39 AM, Neil Bothwick  wrote:
> On Tue, 29 Sep 2015 20:45:10 +0200, lee wrote:
>
>> Go ahead and show me where I have demanded something.
>
> Your insistence that it should be changed amounts to a demand. Your
> assertion that it can be done easily only demeans the efforts of the
> devs, implying that the fix is simple but they cannot be bothered.

Guys, please take a break.  We're up to over 50 messages in this
thread, most of which are basically a back and forth on this.

Nobody likes the output of portage here, we get it...

The next council meeting will include proposals to stop relying on
dynamic deps, which should cut down on some of these issues.  There
are always ideas floating around for substantially changing how
dependencies are handled in portage, and those might help.

Short-term if somebody wants to write up a wiki page full of common
confusing portage error messages and improved versions of the same,
and instructions on how to handle each situation, that would both help
users today, and give the portage devs something to contemplate in
their enhancements.  There is no reason portage couldn't even figure
out which case an error falls into and either output the text on the
page or give the user a link to go look up instructions on how to
resolve.

I find more tends to happen when you direct your energy at creating
something.  Clearly you are both interested in Gentoo and going back
and forth isn't helping anybody.

-- 
Rich

Re: [gentoo-user] update problems

[Neil Bothwick]

On Tue, 29 Sep 2015 20:45:10 +0200, lee wrote:

> Neil Bothwick  writes:
> 
> > Patches are always more welcome than suggestions. "Fix it!" is never
> > as welcome as "here's how". I think it was Canek who said "code
> > talks".   
> 
> Do you have an example for such a case?

Just look at b.g.o. Many bug reports include a patch submitted by a user
that makes its way into the tree.

> My experience has disproved
> this claim, and I've even seen people fixing stuff multiple times after
> I told them it's broken and provided a perfectly working version before
> telling them, much better coded, which they could have used instead of
> insisting on their crappy code and trying to fix it several times.

You cannot judge one group of people on the behaviour of an unrelated
group.

> >> and now even if you
> >> came up with some pointer what to look at (since emerge, for
> >> example, is a wrapper script from which I couldn't see where to
> >> start),  
> >
> > Really? The first few lines of the script tell you where the real
> > scripts are? The wrapper seems to be there to deal with different
> > default Python versions.  
> 
> Yes, really.  I don't know python and I can see that emerge points to
> some library directory while I can not see which script would actually
> run other than the wrapper.

#!/usr/lib/python-exec/python-exec2-c
# vim:fileencoding=utf-8:ft=python
# (c) 2012 Michał Górny
# Released under the terms of the 2-clause BSD license.
#
# This is not the script you are looking for. This is just a wrapper.
# The actual scripts of this application were installed
# in subdirectories of /usr/lib/python-exec.
# You are most likely looking for one of those.

In there you will find python2.7/emerge and python3.4/emerge (depending
on which Python versions you have installed).

> I don't believe that they let everyone modify what they're working on,
> so they are the only ones who /can/ fix it.  Besides, show me where I
> said something like "I want the devs to fix it".

They don't. You submit the modifications in the bug report and they vet
and apply the patches.

> > Adding the word "just" to a demand does not make the task any
> > simpler, nor does it increase your chances of getting what you want.  
> 
> Go ahead and show me where I have demanded something.

Your insistence that it should be changed amounts to a demand. Your
assertion that it can be done easily only demeans the efforts of the
devs, implying that the fix is simple but they cannot be bothered.
 
> > On the contrary, it serves to illustrate that you do not grasp the
> > complexity of the situation.  
> 
> Perhaps you can enlighten me how it is so difficult to change a message
> from "slot conflict" to "slot conflict (can probably be ignored while
> there are other problems)" and what the complexity is which makes it
> impossible to do so.

Changing the message is trivial, knowing when to change it is not. Unless
you can provide a means to tell unimportant slot conflicts from important
ones, Context is everything and the variety of Gentoo systems out there
make it extremely difficult for portage to understand the context in
human terms. 


-- 
Neil Bothwick

Sometimes too much to drink is not enough.


pgpVoyZgOoNp9.pgp
Description: OpenPGP digital signature

Re: [gentoo-user] update problems

[lee]

Alec Ten Harmsel  writes:

> On Tue, Sep 29, 2015 at 12:52:41AM +0200, lee wrote:
>>
>> Alan McKinnon  writes:
>> 
>> > On 27/09/2015 21:17, lee wrote:
>> >
>> > Fellow, I'm done with you, really.
>> >
>> > You hold onto your issues with portage like they were some treasured
>> > memory of a long-since departed loved one, while all the time apparently
>> > ignoring the correct valid solutions offeered by kind folks on this list.
>> >
>> > Let it go. The devs know about portage output. I don't see you
>> > submitting patches though.
>> 
>> You ran out of arguments and remain at insisting that the problem is
>> known and cannot be fixed because it's too complicated while rejecting
>> suggestions but asking for patches.  So I have no reason to think that
>> patches would be any more welcome than suggestions, and now even if you
>> came up with some pointer what to look at (since emerge, for example, is
>> a wrapper script from which I couldn't see where to start), I wouldn't
>> waste my time with it.  Congratulations.
>> 
>
> Someone (I can't remember who, probably Rich Freeman or some other dev)
> described a problem with the general process of fixing the portage
> output a while ago. I believe the steps went something like this:
>
> 1. Think the portage output sucks
> 2. Learn what the output means
> 3. Lose all motivation to improve the output because it is no longer
>necessary for you

There seems to be a fourth step when it comes to portage:


4. Discourage everyone who has ideas for improvements and might be
   willing to implement them from actually doing so by telling them that
   they are idiots and should shut up --- and when they indicate that
   they are willing to do just that, complain about that they do just
   that.


> The portage output is not as good as it could be, but everyone with the
> knowledge to fix it doesn't because they neither care (because they
> understand it) *nor* are they being paid.
>
> In my opinion, the portage output is not that bad, in the same way that
> gcc's error messages are not that bad. They can be difficult to get used
> to and some of them are absolutely ridiculous, but after using gcc for a
> while they almost always make sense and are precise.

I find the error messages from gcc are pretty good.


-- 
Again we must be afraid of speaking of daemons for fear that daemons
might swallow us.  Finally, this fear has become reasonable.

Re: [gentoo-user] update problems

[lee]

Neil Bothwick  writes:

> Patches are always more welcome than suggestions. "Fix it!" is never as
> welcome as "here's how". I think it was Canek who said "code talks". 

Do you have an example for such a case?  My experience has disproved
this claim, and I've even seen people fixing stuff multiple times after
I told them it's broken and provided a perfectly working version before
telling them, much better coded, which they could have used instead of
insisting on their crappy code and trying to fix it several times.

>> and now even if you
>> came up with some pointer what to look at (since emerge, for example, is
>> a wrapper script from which I couldn't see where to start),
>
> Really? The first few lines of the script tell you where the real scripts
> are? The wrapper seems to be there to deal with different default
> Python versions.

Yes, really.  I don't know python and I can see that emerge points to
some library directory while I can not see which script would actually
run other than the wrapper.

>> I wouldn't waste my time with it.
>
> Then why on Earth would you expect the devs to do it for you with that
> attitude?

I don't believe that they let everyone modify what they're working on,
so they are the only ones who /can/ fix it.  Besides, show me where I said
something like "I want the devs to fix it".

> Adding the word "just" to a demand does not make the task any
> simpler, nor does it increase your chances of getting what you want.

Go ahead and show me where I have demanded something.

> On the contrary, it serves to illustrate that you do not grasp the
> complexity of the situation.

Perhaps you can enlighten me how it is so difficult to change a message
from "slot conflict" to "slot conflict (can probably be ignored while
there are other problems)" and what the complexity is which makes it
impossible to do so.


-- 
Again we must be afraid of speaking of daemons for fear that daemons
might swallow us.  Finally, this fear has become reasonable.

Re: [gentoo-user] update problems

[Alan Mackenzie]

Hello, Lee.

On Tue, Sep 29, 2015 at 08:45:10PM +0200, lee wrote:
> Neil Bothwick  writes:

> > Patches are always more welcome than suggestions. "Fix it!" is never as
> > welcome as "here's how". I think it was Canek who said "code talks". 

> Do you have an example for such a case?

Yes, many.  I'm a contributor to Emacs, and relatively frequently (perhaps
10 - 30 times a yeaar) somebody reports a bug and simultaneously submits
a patch for it.  This is always well received, and the patch is usually
applied, sometimes with a bit of to and fro and negotiation, sometimes
after waiting for the tedious paperwork to be completed.  One of my own
first contributions was a request for an enhancement (to enable
scrolling during an incremental search) together with a rough, but
working patch.  After some amendments, this was applied.

On the other hand, "wouldn't X be a good idea"s which reach the mailing
list only rarely get taken up by regular contributors - there's only so
much time in the day, and such hackers usually have plenty of Xs of
their own to fill their time with.

> My experience has disproved this claim, and I've even seen people
> fixing stuff multiple times after I told them it's broken and provided
> a perfectly working version before telling them, much better coded,
> which they could have used instead of insisting on their crappy code
> and trying to fix it several times.

That's not very friendly, and hardly inclined to gain extra contributors
for your project.  A gentle guiding hand, helping these other people to
reach a satisfactory fix themselves, would work much better.

[  ]

> > On the contrary, it serves to illustrate that you do not grasp the
> > complexity of the situation.

> Perhaps you can enlighten me how it is so difficult to change a message
> from "slot conflict" to "slot conflict (can probably be ignored while
> there are other problems)" and what the complexity is which makes it
> impossible to do so.

It's not difficult, it's just tedious.  Something like that which is
user facing needs to be agreed by the core of the project, and getting
that agreement tends to involve lots of bike shedding on the project
mailing lists - there's always a few people who'll prefer the message to
stay the same.  Then there's all the stuff about writing change logs for
the change and commiting it.  Such a tiny change is scarcely achievable
in less than an hour.  To the core developers, it barely seems worth it.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: [gentoo-user] update problems

[lee]

Alan McKinnon  writes:

> On 27/09/2015 21:17, lee wrote:
>
>
>
> [big snip]
>
>>> Seems to me you are thinking like a human (because you are one) and not
>>> > seeing portage's limits. Portage has no idea what would solve the issue
>>> > so can't give any recommendations worth a damn. The best it can do is
>>> > print some hardcoded logic that looks like it might apply.
>> According to that, the human is even less able to figure out what might
>> solve the problem than portage is: The human doesn't know anything about
>> the huge number of dependencies involved, and even if they did, it would
>> take them really really long to go through all of them to figure out
>> anything at all.  Now if they do it right, the human would come to the
>> same conclusion as portage, provided that portage does it right.
>> 
>
> [big snip]
>
> Fellow, I'm done with you, really.
>
> You hold onto your issues with portage like they were some treasured
> memory of a long-since departed loved one, while all the time apparently
> ignoring the correct valid solutions offeered by kind folks on this list.
>
> Let it go. The devs know about portage output. I don't see you
> submitting patches though.

You ran out of arguments and remain at insisting that the problem is
known and cannot be fixed because it's too complicated while rejecting
suggestions but asking for patches.  So I have no reason to think that
patches would be any more welcome than suggestions, and now even if you
came up with some pointer what to look at (since emerge, for example, is
a wrapper script from which I couldn't see where to start), I wouldn't
waste my time with it.  Congratulations.


-- 
Again we must be afraid of speaking of daemons for fear that daemons
might swallow us.  Finally, this fear has become reasonable.

Re: [gentoo-user] update problems

[Alec Ten Harmsel]

On Tue, Sep 29, 2015 at 12:52:41AM +0200, lee wrote:
>
> Alan McKinnon  writes:
> 
> > On 27/09/2015 21:17, lee wrote:
> >
> > Fellow, I'm done with you, really.
> >
> > You hold onto your issues with portage like they were some treasured
> > memory of a long-since departed loved one, while all the time apparently
> > ignoring the correct valid solutions offeered by kind folks on this list.
> >
> > Let it go. The devs know about portage output. I don't see you
> > submitting patches though.
> 
> You ran out of arguments and remain at insisting that the problem is
> known and cannot be fixed because it's too complicated while rejecting
> suggestions but asking for patches.  So I have no reason to think that
> patches would be any more welcome than suggestions, and now even if you
> came up with some pointer what to look at (since emerge, for example, is
> a wrapper script from which I couldn't see where to start), I wouldn't
> waste my time with it.  Congratulations.
> 

Someone (I can't remember who, probably Rich Freeman or some other dev)
described a problem with the general process of fixing the portage
output a while ago. I believe the steps went something like this:

1. Think the portage output sucks
2. Learn what the output means
3. Lose all motivation to improve the output because it is no longer
   necessary for you

The portage output is not as good as it could be, but everyone with the
knowledge to fix it doesn't because they neither care (because they
understand it) *nor* are they being paid.

In my opinion, the portage output is not that bad, in the same way that
gcc's error messages are not that bad. They can be difficult to get used
to and some of them are absolutely ridiculous, but after using gcc for a
while they almost always make sense and are precise.

Alec

Re: [gentoo-user] update problems

[Neil Bothwick]

On Tue, 29 Sep 2015 00:52:41 +0200, lee wrote:

> > You hold onto your issues with portage like they were some treasured
> > memory of a long-since departed loved one, while all the time
> > apparently ignoring the correct valid solutions offeered by kind
> > folks on this list.
> >
> > Let it go. The devs know about portage output. I don't see you
> > submitting patches though.  
> 
> You ran out of arguments

This thread ran out of arguments a long time ago. Repeating the same ones
doesn't count.

> and remain at insisting that the problem is
> known and cannot be fixed because it's too complicated

It's not that it cannot be fixed, just that it is very difficult to do
what you "just" want.

> while rejecting
> suggestions but asking for patches.  So I have no reason to think that
> patches would be any more welcome than suggestions,

Patches are always more welcome than suggestions. "Fix it!" is never as
welcome as "here's how". I think it was Canek who said "code talks". 

> and now even if you
> came up with some pointer what to look at (since emerge, for example, is
> a wrapper script from which I couldn't see where to start),

Really? The first few lines of the script tell you where the real scripts
are? The wrapper seems to be there to deal with different default
Python versions.

> I wouldn't waste my time with it.

Then why on Earth would you expect the devs to do it for you with that
attitude? Adding the word "just" to a demand does not make the task any
simpler, nor does it increase your chances of getting what you want. On
the contrary, it serves to illustrate that you do not grasp the
complexity of the situation.


-- 
Neil Bothwick

Three kinds of people: those who can count and those who can't.


pgppcNG6DDejN.pgp
Description: OpenPGP digital signature

Re: [gentoo-user] update problems

[Alan McKinnon]

On 26/09/2015 17:00, lee wrote:
> Alan McKinnon  writes:
> 
>> On 20/09/2015 17:28, lee wrote:
>>> Neil Bothwick  writes:
>>>
 On Sat, 19 Sep 2015 21:36:06 +0200, lee wrote:
> 
>> [...]
> !!! Multiple package instances within a single package slot have been
> pulled !!! into the dependency graph, resulting in a slot conflict:
>> [...]
 These are unimportant, it is simply portage telling you it is not
 updating some packages to the latest available and why. Personally, I
 believe this sort of output should only be shown when using --verbose. 
>>>
>> [...]
>>> Should I always ignore such messages?
>>
>> No, you should not ignore such messages. They are printed for a reason.
> 
> Well, what can I do other than ignore them?  With dependencies as they
> are, and given that I don't want to remove packages, some of the
> packages that could be upgraded to newer versions won't be upgraded
> because otherwise things might be broken.  There's nothing I could do
> about that, or is there?

Look, you are over-complicating this and making it way more difficult
than it needs to be.

We all agree portage would be easier to use if it was less wordy, and if
it drew a better distinction between debug, info, error and warning
messages. But right now it's not there, so unless you can step up with a
high quality patch to improve matters, you have to deal with what is there.

Look at the output, take each thing portage is saying and eveluate it on
it's own merits. Maybe you need to do something, maybe not. But you have
to read them and decide.

Your question was should you always ignore such messages, and I forget
what the such was. Obviously, no, you must not globally ignore what
software is telling you.

So clam down, take a chill pill or whatever and deal with portage on
it's own terms

> 
>> You have a SLOT conflict and whether that prevents you from proceeding
>> or not doesn't change the fact that portage knows you have that conflict.
> 
> Is it possible to solve this conflict without removing packages?

NO. YOU DO NOT JUST REMOVE PACKAGES WILLY-NILLY.

Neil already explained what a slot conflict is. Portage wants to install
two versions from the same slot. Find out why and deal with that.
Oftentimes the message is a mere info, telling you why portage won't
install the latest. This is actually the same thing as yesterday's
question on nvidia-drivers that I already answered. You treat SLOTs and
packages the same way, a SLOT is just a subset of all versions of a
packages.

> 
>> In your specific case today, I believe portage will simply install the
>> lesser version and be done with it, but it will only do that when you
>> fix the USE issue (a whole separate issue)
> 
> Probably --- yet it tells me about conflicts, makes them appear to be
> important, and leaves me wondering how to solve them.

A conflict is just a conflict, doesn't have to be serius. Maybe portage
can solve it, maybe not. Either way, you get to read and understand the
output.

> 
>> [...]
>> The USE conflict for sure. Maybe the SLOT conflict but I think portage
>> will just deal with that one
>> [...]
>>> This one doesn't look very important, or does it?
>>
>> Chill dude, seriously. The sky is not about to fall on your head and the
>> bits on your disk are not going to miraculously re-arrange themselves
>> into Windows just because you can't do this update.
> 
> Sure, yet why make unimportant messages look important and important
> ones unimportant?

Because the devs are human. Ask them.

> 
>> Portage is what it is, deal with it.
>>
>> The portage team are all unpaid volunteers just liek everyone else and
>> none of us have any right at all to make demands of them. Especially not
>> you and I who are not active contribution solutions.
> 
> I know --- however, making a suggestion to improve the messages is a
> contribution.

But freaking out and complaining helps no-one.

You appear to not fully understand the nature of the problem and your
emotional outbursts are not helping. You keep going round the same
circle, complaining about how the output doesn't suit you, but I don;t
see evidence yet that you are actually reading it. You need to read it.

> 
>> [...]
>>> How about adding comments to such messages, like "You don't need to do
>>> anything to be able to proceed." and "You need to fix this before you
>>> could proceed."?
>>
>> If emerge exited then you need to fix something in your config.
>> If emerge does not exit then your config can be used as-is.
> 
> Messages more helpful could make it easier to figure out what needs to
> be fixed.

Learn python, submit a high-quality patch.

> 
>> [...]
>>> The last sync I did before the one yesterday wasn't the day before
>>> yesterday but over three months ago, so don't ask me today (or next
>>> weekend or whenever I give it another try) when that exactly was.  See
>>> what I mean?  Asking me to mask all packages to a certain point in time

Re: [gentoo-user] update problems

[lee]

Alan McKinnon  writes:

> On 20/09/2015 17:28, lee wrote:
>> Neil Bothwick  writes:
>> 
>>> On Sat, 19 Sep 2015 21:36:06 +0200, lee wrote:

> [...]
 !!! Multiple package instances within a single package slot have been
 pulled !!! into the dependency graph, resulting in a slot conflict:
> [...]
>>> These are unimportant, it is simply portage telling you it is not
>>> updating some packages to the latest available and why. Personally, I
>>> believe this sort of output should only be shown when using --verbose. 
>> 
> [...]
>> Should I always ignore such messages?
>
> No, you should not ignore such messages. They are printed for a reason.

Well, what can I do other than ignore them?  With dependencies as they
are, and given that I don't want to remove packages, some of the
packages that could be upgraded to newer versions won't be upgraded
because otherwise things might be broken.  There's nothing I could do
about that, or is there?

> You have a SLOT conflict and whether that prevents you from proceeding
> or not doesn't change the fact that portage knows you have that conflict.

Is it possible to solve this conflict without removing packages?

> In your specific case today, I believe portage will simply install the
> lesser version and be done with it, but it will only do that when you
> fix the USE issue (a whole separate issue)

Probably --- yet it tells me about conflicts, makes them appear to be
important, and leaves me wondering how to solve them.

> [...]
> The USE conflict for sure. Maybe the SLOT conflict but I think portage
> will just deal with that one
> [...]
>> This one doesn't look very important, or does it?
>
> Chill dude, seriously. The sky is not about to fall on your head and the
> bits on your disk are not going to miraculously re-arrange themselves
> into Windows just because you can't do this update.

Sure, yet why make unimportant messages look important and important
ones unimportant?

> Portage is what it is, deal with it.
>
> The portage team are all unpaid volunteers just liek everyone else and
> none of us have any right at all to make demands of them. Especially not
> you and I who are not active contribution solutions.

I know --- however, making a suggestion to improve the messages is a
contribution.

> [...]
>> How about adding comments to such messages, like "You don't need to do
>> anything to be able to proceed." and "You need to fix this before you
>> could proceed."?
>
> If emerge exited then you need to fix something in your config.
> If emerge does not exit then your config can be used as-is.

Messages more helpful could make it easier to figure out what needs to
be fixed.

> [...]
>> The last sync I did before the one yesterday wasn't the day before
>> yesterday but over three months ago, so don't ask me today (or next
>> weekend or whenever I give it another try) when that exactly was.  See
>> what I mean?  Asking me to mask all packages to a certain point in time
>> is like asking me to do much of the package management by myself.
>
> Exactly. You DO need to do the package management yourself. The Gentoo
> devs provide useful tools in the form of portage and the tree with it's
> ebuilds and eclasses, plus some amazing automation.
>
> But, are here's the bit where so many people move away from Gentoo:
>
> You are required to do the management yourself, including most of the
> thinking and all of the sweeping up of broken pieces. That's what you
> signed up for when using Gentoo.

Perhaps not so many people would move away if the messages were
improved.

> If you want to roll back the tree, then you need to implement a
> solution that will let you do it as Gentoo does nto provide one. Git
> now makes this easier.

Converting to btrfs might work for that, if I can boot from it.

> However, tree rollbacks are inadvisable for excellent technical reasons
> - see if you can figure them out. Better to snapshot your entire system
> and revert the snapshot if it goes south.

That's not even advisable with sources, though IIRC, the reasons for
that might not apply here.  However, it's weird that a system like git
makes it inadvisable to undo something, considering that being able to
undo something very easily, is one important reason to invent and use
such a system in the first place.

Using snapshots for undoing things git is quite an application of
overengineering.


-- 
Again we must be afraid of speaking of daemons for fear that daemons
might swallow us.  Finally, this fear has become reasonable.

Re: [gentoo-user] update problems

[lee]

Alan McKinnon  writes:

> On 26/09/2015 11:47, lee wrote:
>> Rich Freeman  writes:
>> 
>>> On Sat, Sep 19, 2015 at 3:57 PM, Alan McKinnon  
>>> wrote:

> [...]
>> It gives the same results (after syncing again), plus a message that
>> wasn't there before:
>> 
>> 
>> ,
>> | x11-drivers/nvidia-drivers:0
>> | 
>> |   (x11-drivers/nvidia-drivers-355.11:0/0::gentoo, ebuild scheduled for 
>> merge) pulled in by
>> | (no parents that aren't satisfied by other packages in this slot)
>> | 
>> |   (x11-drivers/nvidia-drivers-340.93:0/0::gentoo, ebuild scheduled for 
>> merge) pulled in by
>> | ~x11-drivers/nvidia-drivers-340.93 required by 
>> (media-video/nvidia-settings-340.58:0/0::gentoo, ebuild scheduled for merge)
>> | ^   ^^
>> `
>> 
>> 
>> This looks kinda weird because I expect those drivers to be updated as
>> well, and if they aren't, I will have to remove nvidia-settings.
>> 
>> Let's try backtrack 500 ... same result, and doesn't take longer.
>
> That doesn't look like a block. It looks like an info message that
> portage is "helpfully" displaying (but really belongs only in -v output.
> Maybe even the non-existent -vvv...)
>
> Portage is telling you *why* it is not updating to latest stable
> nvidia-drivers even though a higher version is in the tree. It's because
> nvidia-settings is out of step with nvidia-drivers. Look at output of
> "eix nvidia":
>
> nvidia-drivers-355.11 is stable
> nvidia-settings-355.11 is unstable.
>
> The driver package will update to 355.11 when the settings package goes
> stable.
>
> A related question is "do you really need the latest nvidia drivers, or
> is 340.93 still good enough? It was good enough for the entire time you
> had it installed."

Do I need to update at all?  After all, the system has been running fine
all the time, except that I wanted the latest version of seamonkey and
that I tend to update every three months or so as time permits, and the
last update was almost haft a year ago or so.

Of course I want the latest nvidia drivers, so I removed
nvidia-settings.  (I have updated, and it took almost 2 days.)

Nvidia-settings is kinda weird anyway, like when you enable sync to
vblanc, apparently that is somehow being remembered, and the question is
"when is it applied":  When you start an X session or when you start
nvidia-settings.  Same goes for all the other settings you can make with
it.

And now, with nvidia drivers incompatible with nvidia-settings and
nvidia-settings not installed, what settings that have been made with it
are applied?

>>> If it is the rdepend issue then you can probably emerge -1 librevenge
>>> and whatever else is depending on the old version to fix it.
>>>
>>> Also, emerge running --changed-deps=y from time to time may make those
>>> kinds of problems less likely.  The first time you do it prepare to
>>> see a LOT of stuff get rebuilt - any of those packages could cause
>>> issues in the future but most probably will not.
>> 
>> Good to know, I'll keep that in mind.  I tried it and it's not too much
>> to rebuild, only a bit surprising:
> [...]
>> 
>> Should I do that before updating or after?  I guess I'm on the save side
>> doing it before, so I'll do that.
>
> Before, or just include the option in your emerge command. Portage will
> sort out the order to build them in.

Ok --- I did it before and after ...

> Remember something about portage - the only source of info it has about
> packages is what is in ebuilds. So if say a package from upstream now
> needs a different version of automake to build correctly, and the dev
> forgot to add that[1], portage can't take account of it and can't help.
>
> Portage also has many useful shortcuts, things like "you don't need to
> rebuild that package just yet as nothing in the current list needs it
> yet" so there are options to leave those packages out. But if "nothing
> needs it yet" is not true because it's missing from ebuilds, you run
> into a mess.
>
> And the really important thing is, portage cannot help resolve this.
> It's dumb software and has no clue why that build is failing.

Isn't that the same for all package management software?

 You fail to understand how gentoo works. At no time did Gentoo ever
 guarantee that updates would work like binary distros and the process
 would be trouble free. Quite the opposite - Gentoo is upfront in telling
 you that there will always be update issues and you are the person to
 solve them.

>>>
>>> While Gentoo doesn't do as much handholding as many distros, the
>>> portage output above should not be viewed as something we are proud
>>> of.
>> 
>> At least I'm learning here :)
>
> Good for you. Learning is always hard.

Some years ago I found out that the learning isn't the problem when I
was like "I don't want to do this (because I need to learn it)" and then
did and learned it.  The problem is bringing 

Re: [gentoo-user] update problems

[lee]

Rich Freeman  writes:

> On Sat, Sep 26, 2015 at 9:51 AM, lee  wrote:
>> |
>> |   (dev-libs/boost-1.56.0-r1:0/1.56.0::gentoo, ebuild scheduled for merge) 
>> pulled in by
>> | (no parents that aren't satisfied by other packages in this slot)
>> |
>> |   (dev-libs/boost-1.55.0-r2:0/1.55.0::gentoo, ebuild scheduled for merge) 
>> pulled in by
>> | dev-libs/boost:0/1.55.0= required by 
>> (dev-libs/librevenge-0.0.2:0/0::gentoo, installed)
>> |   ^^
>> | (and 2 more with the same problem)
>> |
>>>  (I wrote the below)
>>> that doesn't work just try running emerge -1 on the packages that are
>>> causing the block by depending on the older package version?
>>
>> I suppose the newer versions of the packages are the ones that are
>> causing the blocks.  You could argue that other versions of packages are
>> causing the blocks, but I would argue that there weren't any blocks
>> before the newer versions of the packages were available, hence the
>> newer versions obviously cause the blocks.  That is to say that I'm
>> unsure which packages you're referring to as those causing the blocks.
>
> Apologies if it was a bit unclear.

np :)

> In this example, I'd run emerge -1 =dev-libs/librevenge-0.0.2
>
> You also need to run it on the "2 more with the same problem" but we
> don't know what those are.  Adding --verbose might help.  It should be
> safe to run emerge -1 on anything you already have installed.  If this
> is a dynamic deps issue then emerge -1 pkg will probably help.
>
> Either way, after trying that can you post the output of this:
>
> emerge -j 8 -p --update --newuse --deep --with-bdeps=y --backtrack=500
> --verbose --tree @world
>
> That will show you what is pulling in updates to what.  I'm interested
> in the entire output of emerge, not just the parts you think are most
> relevant - feel free to attach a file containing it.

Well, what I did was basically:


emerge -a --changed-deps=y @world
emerge -j 8 -a --update --newuse --deep --with-bdeps=y --backtrack=100 @world
[fix USE flag]
emerge -j 8 -a --update --newuse --deep --with-bdeps=y --backtrack=100 @world
[remove nvidia-settings]
emerge -j 8 -a --update --newuse --deep --with-bdeps=y --backtrack=100 @world
emerge @preserved-rebuild


That took about 2 hours to update 233 packages.  Then I made the new
kernel and found that for unknown reasons, without warning, the zfs
startup scripts were disabled (very bad idea ...).  Today I updated the
LXC guest and went over the kernel settings and managed to get my
trackball not to work anymore, then took quite a while to figure out
what was missing (it needs a HID driver which, for unknown reasons, got
disabled ...).

So after two days, I finally got seamonkey 2.35 (and a cleaned-up
kernel) ... and I wonder why libreoffice hasn't been updated.  Not that
it matters, but why not?


-- 
Again we must be afraid of speaking of daemons for fear that daemons
might swallow us.  Finally, this fear has become reasonable.

Re: [gentoo-user] update problems

[Alan McKinnon]

On 27/09/2015 21:17, lee wrote:



[big snip]

>> Seems to me you are thinking like a human (because you are one) and not
>> > seeing portage's limits. Portage has no idea what would solve the issue
>> > so can't give any recommendations worth a damn. The best it can do is
>> > print some hardcoded logic that looks like it might apply.
> According to that, the human is even less able to figure out what might
> solve the problem than portage is: The human doesn't know anything about
> the huge number of dependencies involved, and even if they did, it would
> take them really really long to go through all of them to figure out
> anything at all.  Now if they do it right, the human would come to the
> same conclusion as portage, provided that portage does it right.
> 

[big snip]

Fellow, I'm done with you, really.

You hold onto your issues with portage like they were some treasured
memory of a long-since departed loved one, while all the time apparently
ignoring the correct valid solutions offeered by kind folks on this list.

Let it go. The devs know about portage output. I don't see you
submitting patches though.

-- 
Alan McKinnon
alan.mckin...@gmail.com

Re: [gentoo-user] update problems

[Alan McKinnon]

On 26/09/2015 11:47, lee wrote:
> Rich Freeman  writes:
> 
>> On Sat, Sep 19, 2015 at 3:57 PM, Alan McKinnon  
>> wrote:
>>> On 19/09/2015 21:36, lee wrote:

 dev-libs/boost:0

   (dev-libs/boost-1.56.0-r1:0/1.56.0::gentoo, ebuild scheduled for merge) 
 pulled in by
 (no parents that aren't satisfied by other packages in this slot)

   (dev-libs/boost-1.55.0-r2:0/1.55.0::gentoo, ebuild scheduled for merge) 
 pulled in by
 dev-libs/boost:0/1.55.0= required by 
 (dev-libs/librevenge-0.0.2:0/0::gentoo, installed)
   ^^
 (and 2 more with the same problem)
>>>
>>> I'm not sure why you are getting this one. Portage is only pulling in
>>> boost-1.56.0-r1 because it's the latest stable version, but librevenge
>>> requires something earlier. Portage should therefore shut up and install
>>> the only real solution - keep boost at 1.55.0
>>>
>>
>> librevenge doesn't require an earlier version.  This is either a
>> result of insufficient backtracking, or it might have to do with how
>> portage stores runtime dependencies for installed packages.
>>
>> Try adding --backtrack=50 to your command line and try again.  If
>> nothing else it might simplify the output.  It will take longer to
>> run.
> 
> It gives the same results (after syncing again), plus a message that
> wasn't there before:
> 
> 
> ,
> | x11-drivers/nvidia-drivers:0
> | 
> |   (x11-drivers/nvidia-drivers-355.11:0/0::gentoo, ebuild scheduled for 
> merge) pulled in by
> | (no parents that aren't satisfied by other packages in this slot)
> | 
> |   (x11-drivers/nvidia-drivers-340.93:0/0::gentoo, ebuild scheduled for 
> merge) pulled in by
> | ~x11-drivers/nvidia-drivers-340.93 required by 
> (media-video/nvidia-settings-340.58:0/0::gentoo, ebuild scheduled for merge)
> | ^   ^^
> `
> 
> 
> This looks kinda weird because I expect those drivers to be updated as
> well, and if they aren't, I will have to remove nvidia-settings.
> 
> Let's try backtrack 500 ... same result, and doesn't take longer.

That doesn't look like a block. It looks like an info message that
portage is "helpfully" displaying (but really belongs only in -v output.
Maybe even the non-existent -vvv...)

Portage is telling you *why* it is not updating to latest stable
nvidia-drivers even though a higher version is in the tree. It's because
nvidia-settings is out of step with nvidia-drivers. Look at output of
"eix nvidia":

nvidia-drivers-355.11 is stable
nvidia-settings-355.11 is unstable.

The driver package will update to 355.11 when the settings package goes
stable.

A related question is "do you really need the latest nvidia drivers, or
is 340.93 still good enough? It was good enough for the entire time you
had it installed."

> 
>> If it is the rdepend issue then you can probably emerge -1 librevenge
>> and whatever else is depending on the old version to fix it.
>>
>> Also, emerge running --changed-deps=y from time to time may make those
>> kinds of problems less likely.  The first time you do it prepare to
>> see a LOT of stuff get rebuilt - any of those packages could cause
>> issues in the future but most probably will not.
> 
> Good to know, I'll keep that in mind.  I tried it and it's not too much
> to rebuild, only a bit surprising:
> 
> 
> ,
> | [ebuild U  ] sys-devel/automake-wrapper-10 [9]
> | [ebuild   R] app-benchmarks/i7z-0.27.2 
> | [ebuild   R] net-misc/netkit-telnetd-0.17-r10 
> | [ebuild   R] virtual/editor-0 
> | [ebuild U  ] sys-devel/gcc-4.8.5 [4.8.4] USE="-debug%" 
> | [ebuild   R] net-dialup/ppp-2.4.7 
> | [ebuild U  ] sys-apps/openrc-0.17 [0.13.11] USE="-audit%" 
> | [ebuild   R] x11-terms/xterm-314 
> | [ebuild U  ] net-firewall/shorewall-4.6.10.1 [4.6.6.2]
> | [ebuild  NS] sys-devel/automake-1.15 [1.11.6-r1, 1.13.4]
> | [ebuild U  ] media-libs/alsa-lib-1.0.29 [1.0.28]
> | [ebuild U  ] media-sound/alsa-utils-1.0.29 [1.0.28]
> | [ebuild U  ] sys-apps/portage-2.2.20.1 [2.2.18] 
> PYTHON_TARGETS="python3_4* -python3_3*" 
> | [ebuild   R] app-portage/gentoolkit-0.3.0.9-r2  
> PYTHON_TARGETS="python3_4* -python3_3*" 
> | [ebuild U  ] dev-python/ssl-fetch-0.3 [0.2] PYTHON_TARGETS="python3_4* 
> -python3_3*" 
> | [ebuild U  ] app-portage/mirrorselect-2.2.2-r2 [2.2.2] 
> PYTHON_TARGETS="python3_4* -python3_3*" 
> | [ebuild U  ] media-gfx/gimp-2.8.14-r1 [2.8.14] USE="{-test%}" 
> | [ebuild U  ] media-video/mplayer-1.2_pre20150214-r1 [1.2_pre20130729]
> | [ebuild   R   ~] media-video/openshot-1.4.3  USE="-libav%" 
> | [ebuild U  ] app-editors/emacs-24.5 [24.4-r4]
> `
> 
> 
> Should I do that before updating or after?  I guess I'm on the save side
> doing it before, so I'll do that.

Before, or just include the option in your emerge command. Portage will
sort out the order to build them in.

Remember something about 

Re: [gentoo-user] update problems

[lee]

Rich Freeman  writes:

> On Sat, Sep 19, 2015 at 3:57 PM, Alan McKinnon  
> wrote:
>> On 19/09/2015 21:36, lee wrote:
>>>
>>> dev-libs/boost:0
>>>
>>>   (dev-libs/boost-1.56.0-r1:0/1.56.0::gentoo, ebuild scheduled for merge) 
>>> pulled in by
>>> (no parents that aren't satisfied by other packages in this slot)
>>>
>>>   (dev-libs/boost-1.55.0-r2:0/1.55.0::gentoo, ebuild scheduled for merge) 
>>> pulled in by
>>> dev-libs/boost:0/1.55.0= required by 
>>> (dev-libs/librevenge-0.0.2:0/0::gentoo, installed)
>>>   ^^
>>> (and 2 more with the same problem)
>>
>> I'm not sure why you are getting this one. Portage is only pulling in
>> boost-1.56.0-r1 because it's the latest stable version, but librevenge
>> requires something earlier. Portage should therefore shut up and install
>> the only real solution - keep boost at 1.55.0
>>
>
> librevenge doesn't require an earlier version.  This is either a
> result of insufficient backtracking, or it might have to do with how
> portage stores runtime dependencies for installed packages.
>
> Try adding --backtrack=50 to your command line and try again.  If
> nothing else it might simplify the output.  It will take longer to
> run.

It gives the same results (after syncing again), plus a message that
wasn't there before:


,
| x11-drivers/nvidia-drivers:0
| 
|   (x11-drivers/nvidia-drivers-355.11:0/0::gentoo, ebuild scheduled for merge) 
pulled in by
| (no parents that aren't satisfied by other packages in this slot)
| 
|   (x11-drivers/nvidia-drivers-340.93:0/0::gentoo, ebuild scheduled for merge) 
pulled in by
| ~x11-drivers/nvidia-drivers-340.93 required by 
(media-video/nvidia-settings-340.58:0/0::gentoo, ebuild scheduled for merge)
| ^   ^^
`


This looks kinda weird because I expect those drivers to be updated as
well, and if they aren't, I will have to remove nvidia-settings.

Let's try backtrack 500 ... same result, and doesn't take longer.

> If it is the rdepend issue then you can probably emerge -1 librevenge
> and whatever else is depending on the old version to fix it.
>
> Also, emerge running --changed-deps=y from time to time may make those
> kinds of problems less likely.  The first time you do it prepare to
> see a LOT of stuff get rebuilt - any of those packages could cause
> issues in the future but most probably will not.

Good to know, I'll keep that in mind.  I tried it and it's not too much
to rebuild, only a bit surprising:


,
| [ebuild U  ] sys-devel/automake-wrapper-10 [9]
| [ebuild   R] app-benchmarks/i7z-0.27.2 
| [ebuild   R] net-misc/netkit-telnetd-0.17-r10 
| [ebuild   R] virtual/editor-0 
| [ebuild U  ] sys-devel/gcc-4.8.5 [4.8.4] USE="-debug%" 
| [ebuild   R] net-dialup/ppp-2.4.7 
| [ebuild U  ] sys-apps/openrc-0.17 [0.13.11] USE="-audit%" 
| [ebuild   R] x11-terms/xterm-314 
| [ebuild U  ] net-firewall/shorewall-4.6.10.1 [4.6.6.2]
| [ebuild  NS] sys-devel/automake-1.15 [1.11.6-r1, 1.13.4]
| [ebuild U  ] media-libs/alsa-lib-1.0.29 [1.0.28]
| [ebuild U  ] media-sound/alsa-utils-1.0.29 [1.0.28]
| [ebuild U  ] sys-apps/portage-2.2.20.1 [2.2.18] 
PYTHON_TARGETS="python3_4* -python3_3*" 
| [ebuild   R] app-portage/gentoolkit-0.3.0.9-r2  
PYTHON_TARGETS="python3_4* -python3_3*" 
| [ebuild U  ] dev-python/ssl-fetch-0.3 [0.2] PYTHON_TARGETS="python3_4* 
-python3_3*" 
| [ebuild U  ] app-portage/mirrorselect-2.2.2-r2 [2.2.2] 
PYTHON_TARGETS="python3_4* -python3_3*" 
| [ebuild U  ] media-gfx/gimp-2.8.14-r1 [2.8.14] USE="{-test%}" 
| [ebuild U  ] media-video/mplayer-1.2_pre20150214-r1 [1.2_pre20130729]
| [ebuild   R   ~] media-video/openshot-1.4.3  USE="-libav%" 
| [ebuild U  ] app-editors/emacs-24.5 [24.4-r4]
`


Should I do that before updating or after?  I guess I'm on the save side
doing it before, so I'll do that.

>> You fail to understand how gentoo works. At no time did Gentoo ever
>> guarantee that updates would work like binary distros and the process
>> would be trouble free. Quite the opposite - Gentoo is upfront in telling
>> you that there will always be update issues and you are the person to
>> solve them.
>>
>
> While Gentoo doesn't do as much handholding as many distros, the
> portage output above should not be viewed as something we are proud
> of.

At least I'm learning here :)

> --backtrack fixes a lot of issues, and there aren't a lot of simple
> solutions for that without slowing down emerge.
>
> On the other hand, a lot of the runtime dependency issues could be
> fixed.  There is a discussion on -dev right now about getting rid of
> dynamic runtime deps, which would probably help cut down on some of
> the more bizarre behavior.

Making the output "nicer" --- i. e. more informative --- might go a long
way towards more handholding without slowing things down.  If emerge
would tell me "you can ignore this (and look for a 

Re: [gentoo-user] update problems

[Neil Bothwick]

On Sat, 26 Sep 2015 15:51:07 +0200, lee wrote:

> + need to rebuild (large) packages (like libreoffice) which I expect to
>   be upgraded and thus get rebuilt later anyway (to keep the package
>   management happy because it cannot figure this out for us and give us
>   a choice to upgrade these (large) packages as well while we are at
>   it),

They need to be rebuilt because a package they used has updated with a
changed API, poppler is the usual culprit here. It's an issue with all
distros, but for the binary one it's only an issue for the devs, they
build a set of packages that work together and you get to install them.
If a poppler update requires a new libreoffice package, the usual choice
is to skip the new poppler until a new LO is released.
 
> + have to do other things to keep the system up to date we somehow don't
>   know about, like 'emerge -a --changed-deps=y @world' (because the
>   package management doesn't really know how to update the whole system
>   to begin with (because it's so complicated))?

It's not that it is complicated but time-consuming. Options like
--changed-deps and --with-bdeps upgrade packages that don't really need
it, so why enable them by default. They not only increase the time needed
to compile everything but slow down portage's dependency resolution.


-- 
Neil Bothwick

Favorite Windoze game: Guess what this icon does?


pgpPNp0Jeyr2s.pgp
Description: OpenPGP digital signature

Re: [gentoo-user] update problems

[Rich Freeman]

On Sat, Sep 26, 2015 at 9:51 AM, lee  wrote:
> |
> |   (dev-libs/boost-1.56.0-r1:0/1.56.0::gentoo, ebuild scheduled for merge) 
> pulled in by
> | (no parents that aren't satisfied by other packages in this slot)
> |
> |   (dev-libs/boost-1.55.0-r2:0/1.55.0::gentoo, ebuild scheduled for merge) 
> pulled in by
> | dev-libs/boost:0/1.55.0= required by 
> (dev-libs/librevenge-0.0.2:0/0::gentoo, installed)
> |   ^^
> | (and 2 more with the same problem)
> |
>>  (I wrote the below)
>> that doesn't work just try running emerge -1 on the packages that are
>> causing the block by depending on the older package version?
>
> I suppose the newer versions of the packages are the ones that are
> causing the blocks.  You could argue that other versions of packages are
> causing the blocks, but I would argue that there weren't any blocks
> before the newer versions of the packages were available, hence the
> newer versions obviously cause the blocks.  That is to say that I'm
> unsure which packages you're referring to as those causing the blocks.

Apologies if it was a bit unclear.

In this example, I'd run emerge -1 =dev-libs/librevenge-0.0.2

You also need to run it on the "2 more with the same problem" but we
don't know what those are.  Adding --verbose might help.  It should be
safe to run emerge -1 on anything you already have installed.  If this
is a dynamic deps issue then emerge -1 pkg will probably help.

Either way, after trying that can you post the output of this:

emerge -j 8 -p --update --newuse --deep --with-bdeps=y --backtrack=500
--verbose --tree @world

That will show you what is pulling in updates to what.  I'm interested
in the entire output of emerge, not just the parts you think are most
relevant - feel free to attach a file containing it.

-- 
Rich

Re: [gentoo-user] update problems

[J. Roeleveld]

On Saturday, September 26, 2015 03:10:48 PM lee wrote:
> "J. Roeleveld"  writes:
> > On Sunday 20 September 2015 16:25:34 lee wrote:
> >> Alan McKinnon  writes:
> >> > On 19/09/2015 21:36, lee wrote:
> >> >> Hi,
> >> >>
> >> >> 
> >> >>
> >> >> how could I solve these updating problems:
> >> >> 
> >> >> 
> >> >>
> >> >> emerge -j 8 -a --update --newuse --deep --with-bdeps=y @world
> >> >>
> >> >> 
> >> >>  * IMPORTANT: 4 news items need reading for repository 'gentoo'.
> >> >>  * Use eselect news read to view new items.
> >> >> 
> >> >>
> >> >> These are the packages that would be merged, in 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/boost:0
> >> >>
> >> >> 
> >> >>   (dev-libs/boost-1.56.0-r1:0/1.56.0::gentoo, ebuild scheduled for
> >> >>merge)
> >> >>   pulled in by>>   
> >> >> (no parents that aren't satisfied by other packages in this slot)
> >> >>   
> >> >>   (dev-libs/boost-1.55.0-r2:0/1.55.0::gentoo, ebuild scheduled for
> >> >>merge)
> >> >>   pulled in by>>   
> >> >> dev-libs/boost:0/1.55.0= required by
> >> >> (dev-libs/librevenge-0.0.2:0/0::gentoo, installed)>> 
> >> >>   ^^
> >> >> 
> >> >> (and 2 more with the same problem)
> >> >
> >> > 
> >> >
> >> > I'm not sure why you are getting this one. Portage is only pulling in
> >> > boost-1.56.0-r1 because it's the latest stable version, but librevenge
> >> > requires something earlier. Portage should therefore shut up and
> >> > install
> >> > the only real solution - keep boost at 1.55.0
> >>
> >> 
> >>
> >> Maybe because it says that there's a slot conflict.  I had another one
> >> of those, and getting rid of it prevents me from having a pdf reader
> >> installed.  I haven't had the need to read a pdf since, but sooner or
> >> later I'll need to be able to.
> > 
> > Can you provide your world file?
> > should be located at:
> > /var/lib/portage/world
>
> The pdf problem was with mupdf blocking some library, so I removed
> mupdf.  However, llpp still works while I thought it required mupdf, so
> that was false information.  Sorry about that noise.

What else did you remove recently?

> >> > Try these possibilities:
> >> > 
> >> >
> >> > emerge =dev-libs/boost-1.55.0-r2
> >>
> >> 
> >>
> >> Why this particular version; how did you figure that out?  I read from
> >> the second message that boost doesn't work with itself because
> >> librevenge is installed.  So I could remove librevenge, but a lot of
> >> things depend on it, amongst them libreoffice.
> > 
> > Don't forget to add "-1" or "--oneshot" as options when installing 
> > dependencies manually.
> 
> ok
>
> >> From there, I don't know what the effects are.  Now libreoffice is still
> >> 4.4.1.2, and I would expect it being upgraded to 5.x maybe.  So I would
> >> have to remove boost instead --- IIRC I installed it only to try out
> >> regex_match() and regex_search() --- but removing boost seems a bit
> >> unreasonable, considering that it takes a while to build.  And even with
> >> boost removed, I have no good reason to think that there won't be other
> >> problems, and it leaves the question what to do when I need boost again:
> >> I don't even have a pdf reader ...
> >>
> >> 
> >>
> >> So I decided I'd better ask what to do.  It's hard to believe that we
> >> are seriously expected to remove lots of software which we might not be
> >> able to install again just to do an update.  All these conflicts give me
> >> the impression that something in the repo is broken and needs to be
> >> fixed.
> > 
> > I have no such issues, neither do most people.
> > Which seems to indicate the issue is not with the repo.
> > Lets look at the actual contents of your world-file. (see above)
> 
> It seems that everyone has the problem that some versions of some
> packages don't go together with some versions of other packages the
> 'some versions of some packages' depend on.
> 
> Then emerge comes along and points this out as an extremely serious
> problem while all it takes to solve this problem is someone convincing
> the person observing what emerge does that the apparently serious
> problems aren't relevant at all.
> 
> So who is at fault here?  The user taking emerges warnings seriously
> because they don't want to break their system, or emerge by making
> irrelevant warnings appear as being so serious problems that the
> unsuspecting user gets so confused and scared of breaking their system
> that they start to ask questions on mailing lists?
> 
> After all, that's what the smart user does while the not-so-smart users
> break their systems all the time and never learn from their experiences.

Libraries and other dependencies added to the world file unnecessarily.

> 

Re: [gentoo-user] update problems

[lee]

Rich Freeman  writes:

> On Sun, Sep 20, 2015 at 1:24 PM, J. Roeleveld  wrote:
>> On Sunday 20 September 2015 16:25:34 lee wrote:
>>> So I decided I'd better ask what to do.  It's hard to believe that we
>>> are seriously expected to remove lots of software which we might not be
>>> able to install again just to do an update.  All these conflicts give me
>>> the impression that something in the repo is broken and needs to be
>>> fixed.
>>
>> I have no such issues, neither do most people.
>> Which seems to indicate the issue is not with the repo.
>> Lets look at the actual contents of your world-file. (see above)
>>
>
> So, first, I don't think it is a good idea to just start uninstalling
> packages first and then try to fix them.  That might or might not
> work, but it certainly isn't the first thing I'd try.

+1

> Second, this could very well be a problem with the repo, which is the
> whole point of the debate around dynamic dependencies.  Current
> practices tend to create situations that our package managers can't
> handle.  They don't break for everybody instantly, which is why
> they're so insidious, and also why changing the practice was somewhat
> controversial when it first came up a year ago.

Which means?  I mean, I don't exactly have a lot of stuff installed and
nonetheless "slot conflicts".  Perhaps they don't matter and thereby
don't classify as something that the package management couldn't handle.

Now if there is something that the package management cannot handle,
what messages would I get?

> I hate to post it a 3rd time, but before we bicker 14 more times on
> this, could somebody please just try adding --backtrack=50, and if

Ok --- I haven't changed anything yet other than running emerge --sync
again today:


,
| heimdali ~ # emerge -j 8 -a --update --newuse --deep --with-bdeps=y 
--backtrack=500 @world
|
|  * IMPORTANT: 4 news items need reading for repository 'gentoo'.
|  * Use eselect news read to view new items.
|
|
| These are the packages that would be merged, in 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/boost:0
|
|   (dev-libs/boost-1.56.0-r1:0/1.56.0::gentoo, ebuild scheduled for merge) 
pulled in by
| (no parents that aren't satisfied by other packages in this slot)
|
|   (dev-libs/boost-1.55.0-r2:0/1.55.0::gentoo, ebuild scheduled for merge) 
pulled in by
| dev-libs/boost:0/1.55.0= required by 
(dev-libs/librevenge-0.0.2:0/0::gentoo, installed)
|   ^^
| (and 2 more with the same problem)
|
| dev-util/boost-build:0
|
|   (dev-util/boost-build-1.55.0:0/0::gentoo, installed) pulled in by
| =dev-util/boost-build-1.55* required by 
(dev-libs/boost-1.55.0-r2:0/1.55.0::gentoo, ebuild scheduled for merge)
| ^ ^
|
|   (dev-util/boost-build-1.56.0:0/0::gentoo, ebuild scheduled for merge) 
pulled in by
| =dev-util/boost-build-1.56* required by 
(dev-libs/boost-1.56.0-r1:0/1.56.0::gentoo, ebuild scheduled for merge)
| ^ ^
|
| x11-drivers/nvidia-drivers:0
|
|   (x11-drivers/nvidia-drivers-355.11:0/0::gentoo, ebuild scheduled for merge) 
pulled in by
| (no parents that aren't satisfied by other packages in this slot)
|
|   (x11-drivers/nvidia-drivers-340.93:0/0::gentoo, ebuild scheduled for merge) 
pulled in by
| ~x11-drivers/nvidia-drivers-340.93 required by 
(media-video/nvidia-settings-340.58:0/0::gentoo, ebuild scheduled for merge)
| ^   ^^
|
| media-video/ffmpeg:0
|
|   (media-video/ffmpeg-2.6.3:0/54.56.56::gentoo, ebuild scheduled for merge) 
pulled in by
| (no parents that aren't satisfied by other packages in this slot)
|
|   (media-video/ffmpeg-2.2.14:0/52.55.55::gentoo, installed) pulled in by
| media-video/ffmpeg:0/52.55.55=[vdpau] required by 
(media-libs/mlt-0.9.0:0/0::gentoo, installed)
|   
|
|
| 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.
|
|
| !!! The ebuild selected to satisfy "sci-libs/hdf5" has unmet requirements.
| - sci-libs/hdf5-1.8.14-r1::gentoo USE="cxx fortran threads zlib -debug 
-examples -fortran2003 -mpi -static-libs -szip"
|
|   The following REQUIRED_USE flag constraints are unsatisfied:
| threads? ( !cxx !fortran )
|
|   The above constraints are a subset of the following complete expression:
| cxx? ( !mpi ) mpi? ( !cxx ) threads? ( 

Re: [gentoo-user] update problems

[lee]

"J. Roeleveld"  writes:

> On Sunday 20 September 2015 16:25:34 lee wrote:
>> Alan McKinnon  writes:
>> > On 19/09/2015 21:36, lee wrote:
>> >> Hi,
>> >> 
>> >> how could I solve these updating problems:
>> >> 
>> >> 
>> >> emerge -j 8 -a --update --newuse --deep --with-bdeps=y @world
>> >> 
>> >>  * IMPORTANT: 4 news items need reading for repository 'gentoo'.
>> >>  * Use eselect news read to view new items.
>> >> 
>> >> These are the packages that would be merged, in 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/boost:0
>> >> 
>> >>   (dev-libs/boost-1.56.0-r1:0/1.56.0::gentoo, ebuild scheduled for merge)
>> >>   pulled in by>>   
>> >> (no parents that aren't satisfied by other packages in this slot)
>> >>   
>> >>   (dev-libs/boost-1.55.0-r2:0/1.55.0::gentoo, ebuild scheduled for merge)
>> >>   pulled in by>>   
>> >> dev-libs/boost:0/1.55.0= required by
>> >> (dev-libs/librevenge-0.0.2:0/0::gentoo, installed)>> 
>> >>   ^^
>> >> 
>> >> (and 2 more with the same problem)
>> > 
>> > I'm not sure why you are getting this one. Portage is only pulling in
>> > boost-1.56.0-r1 because it's the latest stable version, but librevenge
>> > requires something earlier. Portage should therefore shut up and install
>> > the only real solution - keep boost at 1.55.0
>> 
>> Maybe because it says that there's a slot conflict.  I had another one
>> of those, and getting rid of it prevents me from having a pdf reader
>> installed.  I haven't had the need to read a pdf since, but sooner or
>> later I'll need to be able to.
>
> Can you provide your world file?
> should be located at:
> /var/lib/portage/world




world.bz2
Description: BZip2 compressed data


The pdf problem was with mupdf blocking some library, so I removed
mupdf.  However, llpp still works while I thought it required mupdf, so
that was false information.  Sorry about that noise.

>> > Try these possibilities:
>> > 
>> > emerge =dev-libs/boost-1.55.0-r2
>> 
>> Why this particular version; how did you figure that out?  I read from
>> the second message that boost doesn't work with itself because
>> librevenge is installed.  So I could remove librevenge, but a lot of
>> things depend on it, amongst them libreoffice.
>
> Don't forget to add "-1" or "--oneshot" as options when installing 
> dependencies manually.

ok

>> From there, I don't know what the effects are.  Now libreoffice is still
>> 4.4.1.2, and I would expect it being upgraded to 5.x maybe.  So I would
>> have to remove boost instead --- IIRC I installed it only to try out
>> regex_match() and regex_search() --- but removing boost seems a bit
>> unreasonable, considering that it takes a while to build.  And even with
>> boost removed, I have no good reason to think that there won't be other
>> problems, and it leaves the question what to do when I need boost again:
>> I don't even have a pdf reader ...
>> 
>> So I decided I'd better ask what to do.  It's hard to believe that we
>> are seriously expected to remove lots of software which we might not be
>> able to install again just to do an update.  All these conflicts give me
>> the impression that something in the repo is broken and needs to be
>> fixed.
>
> I have no such issues, neither do most people.
> Which seems to indicate the issue is not with the repo.
> Lets look at the actual contents of your world-file. (see above)

It seems that everyone has the problem that some versions of some
packages don't go together with some versions of other packages the
'some versions of some packages' depend on.

Then emerge comes along and points this out as an extremely serious
problem while all it takes to solve this problem is someone convincing
the person observing what emerge does that the apparently serious
problems aren't relevant at all.

So who is at fault here?  The user taking emerges warnings seriously
because they don't want to break their system, or emerge by making
irrelevant warnings appear as being so serious problems that the
unsuspecting user gets so confused and scared of breaking their system
that they start to ask questions on mailing lists?

After all, that's what the smart user does while the not-so-smart users
break their systems all the time and never learn from their experiences.

>> > emerge -avuND world
>> > 
>> > or
>> > 
>> > emerge -j 8 -a --update --newuse --deep --with-bdeps=n @world
>> > 
>> > or quickpkg boost, then unmerge it and re-run emerge world.
>> > Boost is a pain to build so with a quickpkg you can put it back with a
>> > minimum of effort
>> 
>> Maybe next weekend or so, I don't feel like doing it now and don't
>> really have the time to.
>
> quickpkg is really quick.
> Then, to reinstall from that: emerge -vak1 dev-libs/boost

Oh, 

Re: [gentoo-user] update problems

[Neil Bothwick]

On Sat, 26 Sep 2015 15:10:48 +0200, lee wrote:

> It seems that everyone has the problem that some versions of some
> packages don't go together with some versions of other packages the
> 'some versions of some packages' depend on.

That's just life, and 99% of th time it either doesn't matter or is
handled by slots. A and B depend on C. A new version of C comes out but A
can't work with it, so portage doesn't update it. B is still happy because
it always worked with the older C, portage just tells you why it hasn't
updated C.
 
> Then emerge comes along and points this out as an extremely serious
> problem while all it takes to solve this problem is someone convincing
> the person observing what emerge does that the apparently serious
> problems aren't relevant at all.

It didn't say it was serious, although the overuse of exclamation marks
could be seen as implying that (I have an automatic exclamation mark
filter, so I don't really notice them).

> So who is at fault here?  The user taking emerges warnings seriously
> because they don't want to break their system, or emerge by making
> irrelevant warnings appear as being so serious problems that the
> unsuspecting user gets so confused and scared of breaking their system
> that they start to ask questions on mailing lists?

The problem is that portage does not clearly distinguish between
information, warnings and error messages. The simplest way of looking at
it is "does this stop the emerge proceeding". In your original case,
that was not the case. The emerge did stop, but because of the thing
with hdf5 and the threads USE flag. Once you had cleared that, the
emerge would most likely have proceeded despite the messages.
 
> > quickpkg is really quick.
> > Then, to reinstall from that: emerge -vak1 dev-libs/boost  
> 
> Oh, it's the whole updating thing.  Besides a chance that I'll have to
> fix something, it also brings in a new kernel to make and to install.
> That takes time.

Only if you do it. Unless your existing kernel has stopped working, why
the rush to build a new one?
 
> > The more freedom with the package manager, the more conflicts you
> > might encounter.  
> 
> That doesn't mean that the package manager should be unable to provide
> the user with a number of possible solutions and let them pick one.

It did, it told you to add one USE flag or remove another.

> Particularly, it doesn't mean that the package manager should give the
> impression that things might go horribly wrong when some action is
> performed unless they actually will.

No, it shouldn't. But it is already well established that portage's
output can be opaque from a user's perspective. That's a well trodden
path that is not worth revisiting unless you can help with a solution.
 
> >> Where and how do the above messages give me choices?  They are
> >> telling me that boost doesn't work with itself,  

No they aren't. They are saying that boost will not be upgraded, they are
not saying that anything will not work. I've been seeing almost identical
messages about ocaml for months now, things still work with the version I
had before the messages began.

> > There is, several in fact.
> > One is called "Backups"  
> 
> You seriously expect a backup just to be able to undo an emerge --sync?

Absolutely. All sync does is update the contents of a directory, if you
backed up that directory you could restore it.

> Ok, then make it as easy to boot from ZFS as it is to boot from ext4.
> 
> On a side note, how difficult or easy, and how advisable, is booting
> from btrfs, particularly for a xen PV guest which might have the kernel
> residing on the host?  (I might prefer that over using lvm.)

I don't know about Xen, but on real hardware it's as simple as ext4 with
a single drive, and transparently handled by dracut if you use RAID.

> > The other one is portage snapshots.  
> 
> That sounds like something I should learn about.

See above re backups, it's just a tarball of the portage tree.


-- 
Neil Bothwick

But there, everything has its drawbacks, as the man said when his
mother-in-law died, and they came down upon him for the funeral expenses.
-- Jerome K. Jerome


pgpxK9334L2fb.pgp
Description: OpenPGP digital signature

Re: [gentoo-user] update problems

[Neil Bothwick]

On Sat, 26 Sep 2015 20:16:09 +0200, Alan McKinnon wrote:

> Portage can't unwind the most recent merges so you have to rely on a
> side-effect - hoping that portage will notice your package of X isn't in
> the current tree then will downgrade it to one that is.

You can use app-portage/demerge for this. It's main limitation is that it
can try to emerge packages no longer in the tree, but if you rewind the
tree to a similar date that should go away.


-- 
Neil Bothwick

Hell:  Filling out the paperwork to get into Heaven.


pgpOwMIKIMhKy.pgp
Description: OpenPGP digital signature

Re: [gentoo-user] update problems

[Alan McKinnon]

On 26/09/2015 18:47, Neil Bothwick wrote:
>>> The other one is portage snapshots.  
>> > 
>> > That sounds like something I should learn about.
> See above re backups, it's just a tarball of the portage tree.


Just beware of one thing. Syncing the tree and then *using* it is often
a one-way street, especially if deps got in the mix.

Portage can't unwind the most recent merges so you have to rely on a
side-effect - hoping that portage will notice your package of X isn't in
the current tree then will downgrade it to one that is.

-- 
Alan McKinnon
alan.mckin...@gmail.com

Re: [gentoo-user] update problems

[J. Roeleveld]

On Sunday 20 September 2015 16:25:34 lee wrote:
> Alan McKinnon  writes:
> > On 19/09/2015 21:36, lee wrote:
> >> Hi,
> >> 
> >> how could I solve these updating problems:
> >> 
> >> 
> >> emerge -j 8 -a --update --newuse --deep --with-bdeps=y @world
> >> 
> >>  * IMPORTANT: 4 news items need reading for repository 'gentoo'.
> >>  * Use eselect news read to view new items.
> >> 
> >> These are the packages that would be merged, in 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/boost:0
> >> 
> >>   (dev-libs/boost-1.56.0-r1:0/1.56.0::gentoo, ebuild scheduled for merge)
> >>   pulled in by>>   
> >> (no parents that aren't satisfied by other packages in this slot)
> >>   
> >>   (dev-libs/boost-1.55.0-r2:0/1.55.0::gentoo, ebuild scheduled for merge)
> >>   pulled in by>>   
> >> dev-libs/boost:0/1.55.0= required by
> >> (dev-libs/librevenge-0.0.2:0/0::gentoo, installed)>> 
> >>   ^^
> >> 
> >> (and 2 more with the same problem)
> > 
> > I'm not sure why you are getting this one. Portage is only pulling in
> > boost-1.56.0-r1 because it's the latest stable version, but librevenge
> > requires something earlier. Portage should therefore shut up and install
> > the only real solution - keep boost at 1.55.0
> 
> Maybe because it says that there's a slot conflict.  I had another one
> of those, and getting rid of it prevents me from having a pdf reader
> installed.  I haven't had the need to read a pdf since, but sooner or
> later I'll need to be able to.

Can you provide your world file?
should be located at:
/var/lib/portage/world

> > Try these possibilities:
> > 
> > emerge =dev-libs/boost-1.55.0-r2
> 
> Why this particular version; how did you figure that out?  I read from
> the second message that boost doesn't work with itself because
> librevenge is installed.  So I could remove librevenge, but a lot of
> things depend on it, amongst them libreoffice.

Don't forget to add "-1" or "--oneshot" as options when installing 
dependencies manually.

> From there, I don't know what the effects are.  Now libreoffice is still
> 4.4.1.2, and I would expect it being upgraded to 5.x maybe.  So I would
> have to remove boost instead --- IIRC I installed it only to try out
> regex_match() and regex_search() --- but removing boost seems a bit
> unreasonable, considering that it takes a while to build.  And even with
> boost removed, I have no good reason to think that there won't be other
> problems, and it leaves the question what to do when I need boost again:
> I don't even have a pdf reader ...
> 
> So I decided I'd better ask what to do.  It's hard to believe that we
> are seriously expected to remove lots of software which we might not be
> able to install again just to do an update.  All these conflicts give me
> the impression that something in the repo is broken and needs to be
> fixed.

I have no such issues, neither do most people.
Which seems to indicate the issue is not with the repo.
Lets look at the actual contents of your world-file. (see above)

> > emerge -avuND world
> > 
> > or
> > 
> > emerge -j 8 -a --update --newuse --deep --with-bdeps=n @world
> > 
> > or quickpkg boost, then unmerge it and re-run emerge world.
> > Boost is a pain to build so with a quickpkg you can put it back with a
> > minimum of effort
> 
> Maybe next weekend or so, I don't feel like doing it now and don't
> really have the time to.

quickpkg is really quick.
Then, to reinstall from that: emerge -vak1 dev-libs/boost

> >> dev-util/boost-build:0
> >> 
> >>   (dev-util/boost-build-1.55.0:0/0::gentoo, installed) pulled in by
> >>   
> >> =dev-util/boost-build-1.55* required by
> >> (dev-libs/boost-1.55.0-r2:0/1.55.0::gentoo, ebuild scheduled for
> >> merge) ^ ^
> >>   
> >>   (dev-util/boost-build-1.56.0:0/0::gentoo, ebuild scheduled for merge)
> >>   pulled in by>>   
> >> =dev-util/boost-build-1.56* required by
> >> (dev-libs/boost-1.56.0-r1:0/1.56.0::gentoo, ebuild scheduled for
> >> merge) ^ ^
> > 
> > This is a consequence of boost.
> > Fix the boost issue and this one goes away
> 
> I thought it might.  It's yet another message telling me that boost
> doesn't work with boost.

You seem to want 2 different versions of boost, which are in the same slot.
Which isn't allowed.

> >> media-video/ffmpeg:0
> >> 
> >>   (media-video/ffmpeg-2.6.3:0/54.56.56::gentoo, ebuild scheduled for
> >>   merge) pulled in by>>   
> >> (no parents that aren't satisfied by other packages in this slot)
> >>   
> >>   (media-video/ffmpeg-2.2.14:0/52.55.55::gentoo, installed) pulled in by
> >>   
> >> media-video/ffmpeg:0/52.55.55=[vdpau] required by
> >> (media-libs/mlt-0.9.0:0/0::gentoo, installed)>> 
> >> 

Re: [gentoo-user] update problems

[Paul Colquhoun]

On Sat, 19 Sep 2015 21:05:27 Neil Bothwick wrote:
> On Sat, 19 Sep 2015 21:36:06 +0200, lee wrote:
> > emerge -j 8 -a --update --newuse --deep --with-bdeps=y
> > @world
> > 
> >  * IMPORTANT: 4 news items need reading for repository 'gentoo'.
> >  * Use eselect news read to view new items.
> > 
> > These are the packages that would be merged, in 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/boost:0
> > 
> >   (dev-libs/boost-1.56.0-r1:0/1.56.0::gentoo, ebuild scheduled for
> > 
> > merge) pulled in by (no parents that aren't satisfied by other packages
> > in this slot)
> > 
> >   (dev-libs/boost-1.55.0-r2:0/1.55.0::gentoo, ebuild scheduled for
> > 
> > merge) pulled in by dev-libs/boost:0/1.55.0= required by
> > (dev-libs/librevenge-0.0.2:0/0::gentoo, installed)
> > ^^ (and 2 more with the same problem)
> > 
> > dev-util/boost-build:0
> > 
> >   (dev-util/boost-build-1.55.0:0/0::gentoo, installed) pulled in by
> >   
> > =dev-util/boost-build-1.55* required by
> > 
> > (dev-libs/boost-1.55.0-r2:0/1.55.0::gentoo, ebuild scheduled for merge)
> > ^
> > ^
> > 
> >   (dev-util/boost-build-1.56.0:0/0::gentoo, ebuild scheduled for merge)
> > 
> > pulled in by =dev-util/boost-build-1.56* required by
> > (dev-libs/boost-1.56.0-r1:0/1.56.0::gentoo, ebuild scheduled for merge)
> > ^
> > ^
> > 
> > media-video/ffmpeg:0
> > 
> >   (media-video/ffmpeg-2.6.3:0/54.56.56::gentoo, ebuild scheduled for
> > 
> > merge) pulled in by (no parents that aren't satisfied by other packages
> > in this slot)
> > 
> >   (media-video/ffmpeg-2.2.14:0/52.55.55::gentoo, installed) pulled in by
> >   
> > media-video/ffmpeg:0/52.55.55=[vdpau] required by
> > 
> > (media-libs/mlt-0.9.0:0/0::gentoo, installed)
> > ^^^
> 
> These are unimportant, it is simply portage telling you it is not
> updating some packages to the latest available and why. Personally, I
> believe this sort of output should only be shown when using --verbose.


There is an open bug/feature request for portage to be able to drop all these 
blocked/blocking packages (and their dependencies) and continue installing all 
the unaffected packages.

https://bugs.gentoo.org/show_bug.cgi?id=476350


-- 
Reverend Paul Colquhoun, ULC. http://andor.dropbear.id.au/
  Asking for technical help in newsgroups?  Read this first:
 http://catb.org/~esr/faqs/smart-questions.html#intro

Re: [gentoo-user] update problems

[Neil Bothwick]

On Sat, 19 Sep 2015 20:37:53 -0400, Philip Webb wrote:

> My impression is that using Portage has become more complicated
> & its warning/error messages have not been given the necessary
> attention. Complaints or pleas for help like the OP's here are quite
> frequent & not all of them come from novices who don't understand what
> Gentoo does.
> 
> Portage sb able to report eg
> 
>   "Pkg1 & Pkg2 (of Version1 & Version2) can't be installed together ;
>   Pkg1 is needed for Pkg3, which you already have installed ;
>   Pkg2 is needed for Pkg4, which you are trying to install.
>   Please review your needs : you may need to remove a package
> temporarily in order for Portage to proceed, then restore a different
> version of it".

Maybe it should, but if there is no one willing or able to take on this
task, it won't. Assuming that the task is a major one, which I think it
is, an interim help may be a documentation page that explains the causes
of such messages in detail, as is so often done on this list, referenced
in the portage output.


-- 
Neil Bothwick

"Designing pages in HTML is like having sex in a bathtub. If you don't
know anything about sex, it won't help to know a lot about bathtubs."


pgpv531O2ccbp.pgp
Description: OpenPGP digital signature

Re: [gentoo-user] update problems

[Rich Freeman]

On Sun, Sep 20, 2015 at 7:52 AM, Neil Bothwick  wrote:
> On Sat, 19 Sep 2015 20:37:53 -0400, Philip Webb wrote:
>
>> My impression is that using Portage has become more complicated
>> & its warning/error messages have not been given the necessary
>> attention. Complaints or pleas for help like the OP's here are quite
>> frequent & not all of them come from novices who don't understand what
>> Gentoo does.
>>
>> Portage sb able to report eg
>>
>>   "Pkg1 & Pkg2 (of Version1 & Version2) can't be installed together ;
>>   Pkg1 is needed for Pkg3, which you already have installed ;
>>   Pkg2 is needed for Pkg4, which you are trying to install.
>>   Please review your needs : you may need to remove a package
>> temporarily in order for Portage to proceed, then restore a different
>> version of it".
>
> Maybe it should, but if there is no one willing or able to take on this
> task, it won't.

So, kicking the overworked portage team with stuff like "Gentoo has a
lousy package manager" is not helpful and certainly violates the CoC.
I don't see that here.

On the other hand, that doesn't mean that we all need to line up and
drink the kool aide and say that the behavior pointed out in the
original message is desired behavior.

We can acknowledge that bugs exist without lining up with signs
demanding their immediate fix.  The portage team does great work, but
the fact that package runtime dependencies can vary so much compared
to a binary distro greatly complicates the dependency-resolution
problem.  So do some of our package-maintenance practices, and those
are being looked at right now.

Something outsiders probably could contribute might be something like
a guide to portage troubleshooting on the wiki that lists some common
scenarios and their workarounds, or possibly working with the portage
team to get short references to such a guide added to the portage
output.  So, portage might suggest re-running it with --backtrack=# or
whatever if it outputs the sort of errors that backtracking is likely
to fix, and so on.  Just doing that alone would probably triage a
large number of issues that confuse users which makes them somewhat
happier and cuts down on list traffic.

-- 
Rich

Re: [gentoo-user] update problems

[Rich Freeman]

On Sun, Sep 20, 2015 at 11:28 AM, lee  wrote:
>
> Should I make feature requests?
>

First, don't believe every post you read in gentoo-user.  Just as you
can post anything you want here, so can anybody else.  People offer
advice they think is helpful.  That doesn't mean it is necessarily
correct, and that statement isn't directed at anybody in particular.
Anytime there is a post on -user you'll see about 5 right answers and
5 wrong answers, and the person who knows the least (the person asking
the question) gets to decide which one is which.  Short of moderating
the list we don't really have a solution for that.  Something like
stack exchange might be useful here.

As I already said (in one of the emails you haven't replied to yet),
we're fairly aware that portage output isn't very helpful here, and it
is something people are interested in changing.  I don't really see
the point in asking for a feature request, since it is already
well-known.

I would recommend trying out my suggestion of adding --backtrack=50
before doing anything else.  If that doesn't work, then try emerge
-1'ing the various packages listed as requiring the older version of
the library.

-- 
Rich

Re: [gentoo-user] update problems

[Neil Bothwick]

On Sun, 20 Sep 2015 17:28:25 +0200, lee wrote:

> Neil Bothwick  writes:
> > These are unimportant, it is simply portage telling you it is not
> > updating some packages to the latest available and why. Personally, I
> > believe this sort of output should only be shown when using
> > --verbose.   
> 
> Really?
> 
> That doesn't seem to be at all what it says.  It says, with huge
> exclamation marks even:
> 
> 
> "!!! Multiple package instances within a single package slot have been
> pulled !!! into the dependency graph, resulting in a slot conflict:"
> 
> 
> So obviously, something terrible is going on, preventing you from
> installing required packages, and there is a dependency conflict which
> cannot be solved because only one package of many can be used while
> several are required in its place.

A slot conflict is not a dependency conflict.
> 
> If this is irrelevant, then why doesn't it say that it is irrelevant?

Because portage's messages are not as helpful as we would like them to be.

> Why was suggested that I remove boost to resolve an irrelevant conflict?

No idea, the message didn't suggest it.

> Should I always ignore such messages?

You should read them. When a message says "I can't upgrade foo to a newer
version because bar requires the older version" you have no problems
unless something specifically needs the newer foo. Unless the emerge run
stops with blocks (with a capital B) or refuses to otherwise proceed, the
messages are not critical. What has happened here is that you received
these non-critical messages and a critical one, the hdf5 message. At
first glance, the boost messages could be seen as the reason for the
failure to proceed. If in doubt, look at the last message, or those marked
as errors, as the cause of the failure.

> >> !!! The ebuild selected to satisfy "sci-libs/hdf5" has unmet
> >> requirements.
> >> - sci-libs/hdf5-1.8.14-r1::gentoo USE="cxx fortran threads zlib
> >> -debug -examples -fortran2003 -mpi -static-libs -szip"
> >> 
> >>   The following REQUIRED_USE flag constraints are unsatisfied:
> >> threads? ( !cxx !fortran )  
> >
> > This is blocking you and the reason is given, if you have the threads
> > flag on, cxx and fortran must be off. You have both threads and cxx on
> > which won't work.  
> 
> Well, it doesn't say which of the problems that have been reported are
> the ones preventing me from going any further.  When I get error
> messages, especially ones that appear to be very important (see all the
> exclamation marks?), I usually try to find out what the problem is and
> try to fix it, and starting with the important ones is one possible
> approach.  That approach seems to be quite reasonable in this case,
> considering that I'm trying to upgrade and get messages which appear to
> be extremely important /and/ which tell me that I cannot upgrade, thus
> apparently proving that their importance is more than merely apparent.

See above. You are receiving multiple, unrelated messages, not all of
which are related to the failure to upgrade.

> Then someone comes along and says that the messages with double-apparent
> importance are actually irrelevant.  I find that very funny :)

The advice is based on experience but given for free. You are equally
free to follow or ignore it.

> Is that
> a general thing with Gentoo, that something is the less important the
> more important it seems to be, and that something that doesn't seem to
> be important at all is the most important?

The seems part is based on experience in reading portage messages. As
you get more experienced "seems" tends towards "is".
 
> > That's the real problem, that the messages are so cryptic. The
> > solution is simple, working out what needs to be done from the
> > messages is not.  
> 
> How about adding comments to such messages, like "You don't need to do
> anything to be able to proceed." and "You need to fix this before you
> could proceed."?
> 
> That's probably easy to do and would greatly help to distinguish between
> important and irrelevant messages and make it easier to decide which
> problem one wants to solve first.

If it were easy, it would have been done. I find the message frustrating
too, but accept that an improvement is unlikely to appear in the imminent
future. In fact, as portage gets ever cleverer with its dependency
resolution, the message are likely to get more complex before they become
simpler :(

> >> Once I used 'emerge --sync', there is no way to turn it back to
> >> continue to be able to install software if needed when the update
> >> cannot be performed.  Updates simply need to work, there's no way
> >> around that.  
> >
> > You can always roll back by masking the updates if necessary, and the
> > old ebuilds are always available. Now that the tree is using git, it
> > is probably possibly to sync back to yesterday if you need to.  
> 
> Something like 'emerge --unsync' or 'emerge --syncto
> ' would be much easier, taking you 

Re: [gentoo-user] update problems

[lee]

Alan McKinnon  writes:

> On 19/09/2015 21:36, lee wrote:
>> Hi,
>> 
>> how could I solve these updating problems:
>> 
>> 
>> emerge -j 8 -a --update --newuse --deep --with-bdeps=y @world
>>  
>>   
>> 
>>  * IMPORTANT: 4 news items need reading for repository 'gentoo'.
>>  * Use eselect news read to view new items.
>> 
>> 
>> These are the packages that would be merged, in 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/boost:0
>> 
>>   (dev-libs/boost-1.56.0-r1:0/1.56.0::gentoo, ebuild scheduled for merge) 
>> pulled in by
>> (no parents that aren't satisfied by other packages in this slot)
>> 
>>   (dev-libs/boost-1.55.0-r2:0/1.55.0::gentoo, ebuild scheduled for merge) 
>> pulled in by
>> dev-libs/boost:0/1.55.0= required by 
>> (dev-libs/librevenge-0.0.2:0/0::gentoo, installed)
>>   ^^ 
>>   
>> (and 2 more with the same problem)
>
> I'm not sure why you are getting this one. Portage is only pulling in
> boost-1.56.0-r1 because it's the latest stable version, but librevenge
> requires something earlier. Portage should therefore shut up and install
> the only real solution - keep boost at 1.55.0

Maybe because it says that there's a slot conflict.  I had another one
of those, and getting rid of it prevents me from having a pdf reader
installed.  I haven't had the need to read a pdf since, but sooner or
later I'll need to be able to.

> Try these possibilities:
>
> emerge =dev-libs/boost-1.55.0-r2

Why this particular version; how did you figure that out?  I read from
the second message that boost doesn't work with itself because
librevenge is installed.  So I could remove librevenge, but a lot of
things depend on it, amongst them libreoffice.

>From there, I don't know what the effects are.  Now libreoffice is still
4.4.1.2, and I would expect it being upgraded to 5.x maybe.  So I would
have to remove boost instead --- IIRC I installed it only to try out
regex_match() and regex_search() --- but removing boost seems a bit
unreasonable, considering that it takes a while to build.  And even with
boost removed, I have no good reason to think that there won't be other
problems, and it leaves the question what to do when I need boost again:
I don't even have a pdf reader ...

So I decided I'd better ask what to do.  It's hard to believe that we
are seriously expected to remove lots of software which we might not be
able to install again just to do an update.  All these conflicts give me
the impression that something in the repo is broken and needs to be
fixed.

> emerge -avuND world
>
> or
>
> emerge -j 8 -a --update --newuse --deep --with-bdeps=n @world
>
> or quickpkg boost, then unmerge it and re-run emerge world.
> Boost is a pain to build so with a quickpkg you can put it back with a
> minimum of effort

Maybe next weekend or so, I don't feel like doing it now and don't
really have the time to.

>> dev-util/boost-build:0
>> 
>>   (dev-util/boost-build-1.55.0:0/0::gentoo, installed) pulled in by
>> =dev-util/boost-build-1.55* required by 
>> (dev-libs/boost-1.55.0-r2:0/1.55.0::gentoo, ebuild scheduled for merge)
>> ^ ^  
>>  
>> 
>> 
>>   (dev-util/boost-build-1.56.0:0/0::gentoo, ebuild scheduled for merge) 
>> pulled in by
>> =dev-util/boost-build-1.56* required by 
>> (dev-libs/boost-1.56.0-r1:0/1.56.0::gentoo, ebuild scheduled for merge)
>> ^ ^  
>>  
>> 
>
> This is a consequence of boost.
> Fix the boost issue and this one goes away

I thought it might.  It's yet another message telling me that boost
doesn't work with boost.

>> media-video/ffmpeg:0
>> 
>>   (media-video/ffmpeg-2.6.3:0/54.56.56::gentoo, ebuild scheduled for merge) 
>> pulled in by
>> (no parents that aren't satisfied by other packages in this slot)
>> 
>>   (media-video/ffmpeg-2.2.14:0/52.55.55::gentoo, installed) pulled in by
>> media-video/ffmpeg:0/52.55.55=[vdpau] required by 
>> (media-libs/mlt-0.9.0:0/0::gentoo, installed)
>>      
>>   
>
> Similar to boost. try a similar approach

I tried 'emerge -j 8 -a --update --newuse --deep --with-bdeps=y ffmpeg'
to upgrade ffmpeg only because it seemed 

Re: [gentoo-user] update problems

[lee]

Neil Bothwick  writes:

> On Sat, 19 Sep 2015 21:36:06 +0200, lee wrote:
>
>> emerge -j 8 -a --update --newuse --deep --with-bdeps=y
>> @world   
>>  
>>
>> 
>>  * IMPORTANT: 4 news items need reading for repository 'gentoo'.
>>  * Use eselect news read to view new items.
>> 
>> 
>> These are the packages that would be merged, in 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/boost:0
>> 
>>   (dev-libs/boost-1.56.0-r1:0/1.56.0::gentoo, ebuild scheduled for
>> merge) pulled in by (no parents that aren't satisfied by other packages
>> in this slot)
>> 
>>   (dev-libs/boost-1.55.0-r2:0/1.55.0::gentoo, ebuild scheduled for
>> merge) pulled in by dev-libs/boost:0/1.55.0= required by
>> (dev-libs/librevenge-0.0.2:0/0::gentoo, installed)
>> ^^ (and 2 more with the same problem)
>> 
>> dev-util/boost-build:0
>> 
>>   (dev-util/boost-build-1.55.0:0/0::gentoo, installed) pulled in by
>> =dev-util/boost-build-1.55* required by
>> (dev-libs/boost-1.55.0-r2:0/1.55.0::gentoo, ebuild scheduled for merge)
>> ^
>> ^
>>
>> 
>>   (dev-util/boost-build-1.56.0:0/0::gentoo, ebuild scheduled for merge)
>> pulled in by =dev-util/boost-build-1.56* required by
>> (dev-libs/boost-1.56.0-r1:0/1.56.0::gentoo, ebuild scheduled for merge)
>> ^
>> ^
>>
>> 
>> media-video/ffmpeg:0
>> 
>>   (media-video/ffmpeg-2.6.3:0/54.56.56::gentoo, ebuild scheduled for
>> merge) pulled in by (no parents that aren't satisfied by other packages
>> in this slot)
>> 
>>   (media-video/ffmpeg-2.2.14:0/52.55.55::gentoo, installed) pulled in by
>> media-video/ffmpeg:0/52.55.55=[vdpau] required by
>> (media-libs/mlt-0.9.0:0/0::gentoo, installed)
>> ^^^  
>>
> These are unimportant, it is simply portage telling you it is not
> updating some packages to the latest available and why. Personally, I
> believe this sort of output should only be shown when using --verbose. 

Really?

That doesn't seem to be at all what it says.  It says, with huge
exclamation marks even:


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


So obviously, something terrible is going on, preventing you from
installing required packages, and there is a dependency conflict which
cannot be solved because only one package of many can be used while
several are required in its place.

If this is irrelevant, then why doesn't it say that it is irrelevant?
Why was suggested that I remove boost to resolve an irrelevant conflict?

Should I always ignore such messages?


> [...]
>> 
>> !!! The ebuild selected to satisfy "sci-libs/hdf5" has unmet
>> requirements.
>> - sci-libs/hdf5-1.8.14-r1::gentoo USE="cxx fortran threads zlib -debug
>> -examples -fortran2003 -mpi -static-libs -szip"
>> 
>>   The following REQUIRED_USE flag constraints are unsatisfied:
>> threads? ( !cxx !fortran )
>
> This is blocking you and the reason is given, if you have the threads
> flag on, cxx and fortran must be off. You have both threads and cxx on
> which won't work.

Well, it doesn't say which of the problems that have been reported are
the ones preventing me from going any further.  When I get error
messages, especially ones that appear to be very important (see all the
exclamation marks?), I usually try to find out what the problem is and
try to fix it, and starting with the important ones is one possible
approach.  That approach seems to be quite reasonable in this case,
considering that I'm trying to upgrade and get messages which appear to
be extremely important /and/ which tell me that I cannot upgrade, thus
apparently proving that their importance is more than merely apparent.

Then someone comes along and says that the messages with double-apparent
importance are actually irrelevant.  I find that very funny :)  Is that
a general thing with Gentoo, that something is the less important the
more important it seems to be, and that something that doesn't seem to
be important at all is the most important?

This one doesn't look very important, or does it?

>> Why can't we just update like we can with any other distribution but
>> have to run into dependency problems all the time instead?
>
> These aren't dependency problems, they are conflicting USE flags, a
> situation that 

Re: [gentoo-user] update problems

[Alan McKinnon]

On 20/09/2015 17:28, lee wrote:
> Neil Bothwick  writes:
> 
>> On Sat, 19 Sep 2015 21:36:06 +0200, lee wrote:
>>
>>> emerge -j 8 -a --update --newuse --deep --with-bdeps=y
>>> @world  
>>> 
>>>  
>>>
>>>  * IMPORTANT: 4 news items need reading for repository 'gentoo'.
>>>  * Use eselect news read to view new items.
>>>
>>>
>>> These are the packages that would be merged, in 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/boost:0
>>>
>>>   (dev-libs/boost-1.56.0-r1:0/1.56.0::gentoo, ebuild scheduled for
>>> merge) pulled in by (no parents that aren't satisfied by other packages
>>> in this slot)
>>>
>>>   (dev-libs/boost-1.55.0-r2:0/1.55.0::gentoo, ebuild scheduled for
>>> merge) pulled in by dev-libs/boost:0/1.55.0= required by
>>> (dev-libs/librevenge-0.0.2:0/0::gentoo, installed)
>>> ^^ (and 2 more with the same problem)
>>>
>>> dev-util/boost-build:0
>>>
>>>   (dev-util/boost-build-1.55.0:0/0::gentoo, installed) pulled in by
>>> =dev-util/boost-build-1.55* required by
>>> (dev-libs/boost-1.55.0-r2:0/1.55.0::gentoo, ebuild scheduled for merge)
>>> ^
>>> ^   
>>> 
>>>
>>>   (dev-util/boost-build-1.56.0:0/0::gentoo, ebuild scheduled for merge)
>>> pulled in by =dev-util/boost-build-1.56* required by
>>> (dev-libs/boost-1.56.0-r1:0/1.56.0::gentoo, ebuild scheduled for merge)
>>> ^
>>> ^   
>>> 
>>>
>>> media-video/ffmpeg:0
>>>
>>>   (media-video/ffmpeg-2.6.3:0/54.56.56::gentoo, ebuild scheduled for
>>> merge) pulled in by (no parents that aren't satisfied by other packages
>>> in this slot)
>>>
>>>   (media-video/ffmpeg-2.2.14:0/52.55.55::gentoo, installed) pulled in by
>>> media-video/ffmpeg:0/52.55.55=[vdpau] required by
>>> (media-libs/mlt-0.9.0:0/0::gentoo, installed)
>>> ^^^ 
>>> 
>> These are unimportant, it is simply portage telling you it is not
>> updating some packages to the latest available and why. Personally, I
>> believe this sort of output should only be shown when using --verbose. 
> 
> Really?
> 
> That doesn't seem to be at all what it says.  It says, with huge
> exclamation marks even:
> 
> 
> "!!! Multiple package instances within a single package slot have been
> pulled !!! into the dependency graph, resulting in a slot conflict:"
> 
> 
> So obviously, something terrible is going on, preventing you from
> installing required packages, and there is a dependency conflict which
> cannot be solved because only one package of many can be used while
> several are required in its place.
> 
> If this is irrelevant, then why doesn't it say that it is irrelevant?
> Why was suggested that I remove boost to resolve an irrelevant conflict?
> 
> Should I always ignore such messages?

No, you should not ignore such messages. They are printed for a reason.

You have a SLOT conflict and whether that prevents you from proceeding
or not doesn't change the fact that portage knows you have that conflict.

In your specific case today, I believe portage will simply install the
lesser version and be done with it, but it will only do that when you
fix the USE issue (a whole separate issue)


> 
> 
>> [...]
>>>
>>> !!! The ebuild selected to satisfy "sci-libs/hdf5" has unmet
>>> requirements.
>>> - sci-libs/hdf5-1.8.14-r1::gentoo USE="cxx fortran threads zlib -debug
>>> -examples -fortran2003 -mpi -static-libs -szip"
>>>
>>>   The following REQUIRED_USE flag constraints are unsatisfied:
>>> threads? ( !cxx !fortran )
>>
>> This is blocking you and the reason is given, if you have the threads
>> flag on, cxx and fortran must be off. You have both threads and cxx on
>> which won't work.
> 
> Well, it doesn't say which of the problems that have been reported are
> the ones preventing me from going any further.  

The USE conflict for sure. Maybe the SLOT conflict but I think portage
will just deal with that one

> When I get error
> messages, especially ones that appear to be very important (see all the
> exclamation marks?), I usually try to find out what the problem is and
> try to fix it, and starting with the important ones is one possible
> approach.  That approach seems to be quite reasonable in this case,
> considering that I'm trying to upgrade and get messages which appear to
> be extremely important /and/ which tell me that I cannot upgrade, thus
> apparently 

Re: [gentoo-user] update problems

[Rich Freeman]

On Sun, Sep 20, 2015 at 1:24 PM, J. Roeleveld  wrote:
> On Sunday 20 September 2015 16:25:34 lee wrote:
>> So I decided I'd better ask what to do.  It's hard to believe that we
>> are seriously expected to remove lots of software which we might not be
>> able to install again just to do an update.  All these conflicts give me
>> the impression that something in the repo is broken and needs to be
>> fixed.
>
> I have no such issues, neither do most people.
> Which seems to indicate the issue is not with the repo.
> Lets look at the actual contents of your world-file. (see above)
>

So, first, I don't think it is a good idea to just start uninstalling
packages first and then try to fix them.  That might or might not
work, but it certainly isn't the first thing I'd try.

Second, this could very well be a problem with the repo, which is the
whole point of the debate around dynamic dependencies.  Current
practices tend to create situations that our package managers can't
handle.  They don't break for everybody instantly, which is why
they're so insidious, and also why changing the practice was somewhat
controversial when it first came up a year ago.

I hate to post it a 3rd time, but before we bicker 14 more times on
this, could somebody please just try adding --backtrack=50, and if
that doesn't work just try running emerge -1 on the packages that are
causing the block by depending on the older package version?

-- 
Rich

Re: [gentoo-user] update problems

[Alan McKinnon]

On 19/09/2015 21:36, lee wrote:
> Hi,
> 
> how could I solve these updating problems:
> 
> 
> emerge -j 8 -a --update --newuse --deep --with-bdeps=y @world 
>   
> 
> 
>  * IMPORTANT: 4 news items need reading for repository 'gentoo'.
>  * Use eselect news read to view new items.
> 
> 
> These are the packages that would be merged, in 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/boost:0
> 
>   (dev-libs/boost-1.56.0-r1:0/1.56.0::gentoo, ebuild scheduled for merge) 
> pulled in by
> (no parents that aren't satisfied by other packages in this slot)
> 
>   (dev-libs/boost-1.55.0-r2:0/1.55.0::gentoo, ebuild scheduled for merge) 
> pulled in by
> dev-libs/boost:0/1.55.0= required by 
> (dev-libs/librevenge-0.0.2:0/0::gentoo, installed)
>   ^^  
>  
> (and 2 more with the same problem)

I'm not sure why you are getting this one. Portage is only pulling in
boost-1.56.0-r1 because it's the latest stable version, but librevenge
requires something earlier. Portage should therefore shut up and install
the only real solution - keep boost at 1.55.0

Try these possibilities:

emerge =dev-libs/boost-1.55.0-r2
emerge -avuND world

or

emerge -j 8 -a --update --newuse --deep --with-bdeps=n @world

or quickpkg boost, then unmerge it and re-run emerge world.
Boost is a pain to build so with a quickpkg you can put it back with a
minimum of effort

> 
> dev-util/boost-build:0
> 
>   (dev-util/boost-build-1.55.0:0/0::gentoo, installed) pulled in by
> =dev-util/boost-build-1.55* required by 
> (dev-libs/boost-1.55.0-r2:0/1.55.0::gentoo, ebuild scheduled for merge)
> ^ ^   
>   
>   
> 
>   (dev-util/boost-build-1.56.0:0/0::gentoo, ebuild scheduled for merge) 
> pulled in by
> =dev-util/boost-build-1.56* required by 
> (dev-libs/boost-1.56.0-r1:0/1.56.0::gentoo, ebuild scheduled for merge)
> ^ ^   
>   
>   

This is a consequence of boost.
Fix the boost issue and this one goes away

> 
> media-video/ffmpeg:0
> 
>   (media-video/ffmpeg-2.6.3:0/54.56.56::gentoo, ebuild scheduled for merge) 
> pulled in by
> (no parents that aren't satisfied by other packages in this slot)
> 
>   (media-video/ffmpeg-2.2.14:0/52.55.55::gentoo, installed) pulled in by
> media-video/ffmpeg:0/52.55.55=[vdpau] required by 
> (media-libs/mlt-0.9.0:0/0::gentoo, installed)
>   
>  

Similar to boost. try a similar approach
> 
> 
> 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.
> 
> 
> !!! The ebuild selected to satisfy "sci-libs/hdf5" has unmet requirements.
> - sci-libs/hdf5-1.8.14-r1::gentoo USE="cxx fortran threads zlib -debug 
> -examples -fortran2003 -mpi -static-libs -szip"
> 
>   The following REQUIRED_USE flag constraints are unsatisfied:
> threads? ( !cxx !fortran )

Come on, the problem is as clear as daylight and stated right there in
the output:

If you have threads in USE for hdf5, then you cannot have cxx and/or
fortran also in USE for hdf5

echo "=sci-libs/hdf5-1.8.14-r1 -cxx -fortran" >>
/etc/portage/package.use/package.use

> 
>   The above constraints are a subset of the following complete expression:
> cxx? ( !mpi ) mpi? ( !cxx ) threads? ( !cxx !mpi !fortran ) fortran2003? 
> ( fortran )
> 
> (dependency required by "media-libs/openimageio-1.3.5::gentoo" [installed])
> (dependency required by "@selected" [set])
> (dependency required by "@world" [argument])
> 
> 
> I could remove boost (and maybe reinstall it later), but I would like to
> keep ffmpeg.  hdf5 apparently goes back to having blender installed,
> which I would also like to keep.  And apparently, I would have to remove
> libreoffice before I could update.

What does libreoffice have to do with this?


> 
> Why can't we just 

Re: [gentoo-user] update problems

[Rich Freeman]

On Sat, Sep 19, 2015 at 3:57 PM, Alan McKinnon  wrote:
> On 19/09/2015 21:36, lee wrote:
>>
>> dev-libs/boost:0
>>
>>   (dev-libs/boost-1.56.0-r1:0/1.56.0::gentoo, ebuild scheduled for merge) 
>> pulled in by
>> (no parents that aren't satisfied by other packages in this slot)
>>
>>   (dev-libs/boost-1.55.0-r2:0/1.55.0::gentoo, ebuild scheduled for merge) 
>> pulled in by
>> dev-libs/boost:0/1.55.0= required by 
>> (dev-libs/librevenge-0.0.2:0/0::gentoo, installed)
>>   ^^
>> (and 2 more with the same problem)
>
> I'm not sure why you are getting this one. Portage is only pulling in
> boost-1.56.0-r1 because it's the latest stable version, but librevenge
> requires something earlier. Portage should therefore shut up and install
> the only real solution - keep boost at 1.55.0
>

librevenge doesn't require an earlier version.  This is either a
result of insufficient backtracking, or it might have to do with how
portage stores runtime dependencies for installed packages.

Try adding --backtrack=50 to your command line and try again.  If
nothing else it might simplify the output.  It will take longer to
run.

If it is the rdepend issue then you can probably emerge -1 librevenge
and whatever else is depending on the old version to fix it.

Also, emerge running --changed-deps=y from time to time may make those
kinds of problems less likely.  The first time you do it prepare to
see a LOT of stuff get rebuilt - any of those packages could cause
issues in the future but most probably will not.

> You fail to understand how gentoo works. At no time did Gentoo ever
> guarantee that updates would work like binary distros and the process
> would be trouble free. Quite the opposite - Gentoo is upfront in telling
> you that there will always be update issues and you are the person to
> solve them.
>

While Gentoo doesn't do as much handholding as many distros, the
portage output above should not be viewed as something we are proud
of.

--backtrack fixes a lot of issues, and there aren't a lot of simple
solutions for that without slowing down emerge.

On the other hand, a lot of the runtime dependency issues could be
fixed.  There is a discussion on -dev right now about getting rid of
dynamic runtime deps, which would probably help cut down on some of
the more bizarre behavior.

-- 
Rich

Re: [gentoo-user] update problems

[Mick]

On Saturday 19 Sep 2015 21:05:27 Neil Bothwick wrote:
> On Sat, 19 Sep 2015 21:36:06 +0200, lee wrote:
> > emerge -j 8 -a --update --newuse --deep --with-bdeps=y
> > @world
> > 
> >  * IMPORTANT: 4 news items need reading for repository 'gentoo'.
> >  * Use eselect news read to view new items.
> > 
> > These are the packages that would be merged, in 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/boost:0
> > 
> >   (dev-libs/boost-1.56.0-r1:0/1.56.0::gentoo, ebuild scheduled for
> > 
> > merge) pulled in by (no parents that aren't satisfied by other packages
> > in this slot)
> > 
> >   (dev-libs/boost-1.55.0-r2:0/1.55.0::gentoo, ebuild scheduled for
> > 
> > merge) pulled in by dev-libs/boost:0/1.55.0= required by
> > (dev-libs/librevenge-0.0.2:0/0::gentoo, installed)
> > ^^ (and 2 more with the same problem)
> > 
> > dev-util/boost-build:0
> > 
> >   (dev-util/boost-build-1.55.0:0/0::gentoo, installed) pulled in by
> >   
> > =dev-util/boost-build-1.55* required by
> > 
> > (dev-libs/boost-1.55.0-r2:0/1.55.0::gentoo, ebuild scheduled for merge)
> > ^
> > ^
> > 
> >   (dev-util/boost-build-1.56.0:0/0::gentoo, ebuild scheduled for merge)
> > 
> > pulled in by =dev-util/boost-build-1.56* required by
> > (dev-libs/boost-1.56.0-r1:0/1.56.0::gentoo, ebuild scheduled for merge)
> > ^
> > ^
> > 
> > media-video/ffmpeg:0
> > 
> >   (media-video/ffmpeg-2.6.3:0/54.56.56::gentoo, ebuild scheduled for
> > 
> > merge) pulled in by (no parents that aren't satisfied by other packages
> > in this slot)
> > 
> >   (media-video/ffmpeg-2.2.14:0/52.55.55::gentoo, installed) pulled in by
> >   
> > media-video/ffmpeg:0/52.55.55=[vdpau] required by
> > 
> > (media-libs/mlt-0.9.0:0/0::gentoo, installed)
> > ^^^
> 
> These are unimportant, it is simply portage telling you it is not
> updating some packages to the latest available and why. Personally, I
> believe this sort of output should only be shown when using --verbose.
> 
> > 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.
> > 
> > 
> > !!! The ebuild selected to satisfy "sci-libs/hdf5" has unmet
> > requirements.
> > - sci-libs/hdf5-1.8.14-r1::gentoo USE="cxx fortran threads zlib -debug
> > -examples -fortran2003 -mpi -static-libs -szip"
> > 
> >   The following REQUIRED_USE flag constraints are unsatisfied:
> > threads? ( !cxx !fortran )
> 
> This is blocking you and the reason is given, if you have the threads
> flag on, cxx and fortran must be off. You have both threads and cxx on
> which won't work.
> 
> > Why can't we just update like we can with any other distribution but
> > have to run into dependency problems all the time instead?
> 
> These aren't dependency problems, they are conflicting USE flags, a
> situation that cannot arise with a binary distro. If you want the
> flexibility that USE flags offer, you have to accept that not all
> combinations will work together.
> 
> > What do I do when I need to update /right now/ and find myself being
> > blocked with cryptic messages like the above that leave me stranded?
> 
> That's the real problem, that the messages are so cryptic. The solution
> is simple, working out what needs to be done from the messages is not.
> 
> > Once I used 'emerge --sync', there is no way to turn it back to continue
> > to be able to install software if needed when the update cannot be
> > performed.  Updates simply need to work, there's no way around that.
> 
> You can always roll back by masking the updates if necessary, and the
> old ebuilds are always available. Now that the tree is using git, it is
> probably possibly to sync back to yesterday if you need to.

As Alan said quickpkg boost, remove boost-1.55.0-r2, install boost-1.56.0-r1, 
emerge -1aDv dev-libs/librevenge and which-ever other package complains and 
you should be OK.  Apply a similar approach with ffmpeg.

Neil's comments on sci-libs/hdf5 stand.

-- 
Regards,
Mick


signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-user] update problems

[Alan McKinnon]

On 19/09/2015 22:05, Neil Bothwick wrote:
>> media-video/ffmpeg:0
>> > 
>> >   (media-video/ffmpeg-2.6.3:0/54.56.56::gentoo, ebuild scheduled for
>> > merge) pulled in by (no parents that aren't satisfied by other packages
>> > in this slot)
>> > 
>> >   (media-video/ffmpeg-2.2.14:0/52.55.55::gentoo, installed) pulled in by
>> > media-video/ffmpeg:0/52.55.55=[vdpau] required by
>> > (media-libs/mlt-0.9.0:0/0::gentoo, installed)
>> > ^^^
>> >  
> These are unimportant, it is simply portage telling you it is not
> updating some packages to the latest available and why. Personally, I
> believe this sort of output should only be shown when using --verbose. 
> 



Of course! I'm so used to dealing with portage output I always fail to
spot the mere info messages that are not problems. Like now.

I also never not see these things, I have "--verbose" in
EMERGE_DEFAULT_OPTS. Yes I know it clutters the screen and most of it is
useless, but it also satisfies my OCD obsessions to know everything all
the time



-- 
Alan McKinnon
alan.mckin...@gmail.com

Re: [gentoo-user] update problems

[Daniel Frey]

On 09/19/2015 12:36 PM, lee wrote:
> 
> 
> I could remove boost (and maybe reinstall it later), but I would like to
> keep ffmpeg.  hdf5 apparently goes back to having blender installed,
> which I would also like to keep.  And apparently, I would have to remove
> libreoffice before I could update.
> 
> Why can't we just update like we can with any other distribution but
> have to run into dependency problems all the time instead?
> 
> What do I do when I need to update /right now/ and find myself being
> blocked with cryptic messages like the above that leave me stranded?
> Once I used 'emerge --sync', there is no way to turn it back to continue
> to be able to install software if needed when the update cannot be
> performed.  Updates simply need to work, there's no way around that.
> 
> 

I just updated machines that were several months behind updates and ran
into similar problems. In my case, I had items in /var/lib/portage/world
that didn't really need to be there (as they were pulled in by a
dependency) that was causing portage to fall flat on its face.

For boost and ffmpeg, try running `equery depends ` and if no
result comes back it wasn't installed from a dependency. If it does say
another package is pulling it in, remove it from the world file by
using: `emerge --deselect ` - in the case of boost it would be
`emerge --deselect dev-libs/boost`.

Don't just remove them without seeing if they're being pulled in via
dependency though - if you manually compiled something outside of
portage you may have added the dependencies manually.

Once you've checked the packages for dependencies and/or removed some
items from the world file, try running the update again.

Dan

Re: [gentoo-user] update problems

[Alan McKinnon]

On 20/09/2015 00:17, Rich Freeman wrote:
> Also, emerge running --changed-deps=y from time to time may make those
> kinds of problems less likely.  The first time you do it prepare to
> see a LOT of stuff get rebuilt - any of those packages could cause
> issues in the future but most probably will not.

And you might be unlucky like I was to find that all KDE packages
suddenly had this weird dep on qt*[-phonon], and emerge would barf out
on the first one found. So I rebuilt that package and it barfed on the
next one. When I did this 20 times, I figured portage would do it for
all KDE packages - 300+

Not a chance I was going to do that. Instead:

emerge -e world

and wait 14 hours.

> 
>> > You fail to understand how gentoo works. At no time did Gentoo ever
>> > guarantee that updates would work like binary distros and the process
>> > would be trouble free. Quite the opposite - Gentoo is upfront in telling
>> > you that there will always be update issues and you are the person to
>> > solve them.
>> >
> While Gentoo doesn't do as much handholding as many distros, the
> portage output above should not be viewed as something we are proud
> of.

It's either due to it being a really hard problem or the portage team is
short of manpower. Either way, I'm content not to bitch about it mainly
as the tree is a unique thing in the Linux world

I personally think it's a hard problem. Portage only knows what it has
in it's internal data structures when it decides it can't continue. It
can't provide the user with a meaningful answer as is so often asked for
here so what is it supposed to do? It's not a human.



-- 
Alan McKinnon
alan.mckin...@gmail.com

Re: [gentoo-user] update problems

[Philip Webb]

150920 Alan McKinnon wrote:
> On 20/09/2015 00:17, Rich Freeman wrote:
>> While Gentoo doesn't do as much handholding as many distros,
>> the Portage output above should not be viewed
>> as something we are proud of.
> It's either due to it being a really hard problem
> or the Portage team is short of manpower.
> Either way, I'm content not to bitch about it mainly
> as the tree is a unique thing in the Linux world
> Portage only knows what it has in it's internal data structures
> when it decides it can't continue.  It can't provide the user
> with a meaningful answer as is so often asked for here,
> so what is it supposed to do?

My impression is that using Portage has become more complicated
& its warning/error messages have not been given the necessary attention.
Complaints or pleas for help like the OP's here are quite frequent
& not all of them come from novices who don't understand what Gentoo does.

Portage sb able to report eg

  "Pkg1 & Pkg2 (of Version1 & Version2) can't be installed together ;
  Pkg1 is needed for Pkg3, which you already have installed ;
  Pkg2 is needed for Pkg4, which you are trying to install.
  Please review your needs : you may need to remove a package temporarily
  in order for Portage to proceed, then restore a different version of it".

That's a common problem, which experienced users can diagnose themselves,
but the present Portage output is too opaque to help newcomers.

-- 
,,
SUPPORT ___//___,   Philip Webb
ELECTRIC   /] [] [] [] [] []|   Cities Centre, University of Toronto
TRANSIT`-O--O---'   purslowatchassdotutorontodotca

[gentoo-user] update problems

[lee]

Hi,

how could I solve these updating problems:


emerge -j 8 -a --update --newuse --deep --with-bdeps=y @world   



 * IMPORTANT: 4 news items need reading for repository 'gentoo'.
 * Use eselect news read to view new items.


These are the packages that would be merged, in 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/boost:0

  (dev-libs/boost-1.56.0-r1:0/1.56.0::gentoo, ebuild scheduled for merge) 
pulled in by
(no parents that aren't satisfied by other packages in this slot)

  (dev-libs/boost-1.55.0-r2:0/1.55.0::gentoo, ebuild scheduled for merge) 
pulled in by
dev-libs/boost:0/1.55.0= required by 
(dev-libs/librevenge-0.0.2:0/0::gentoo, installed)
  ^^
   
(and 2 more with the same problem)

dev-util/boost-build:0

  (dev-util/boost-build-1.55.0:0/0::gentoo, installed) pulled in by
=dev-util/boost-build-1.55* required by 
(dev-libs/boost-1.55.0-r2:0/1.55.0::gentoo, ebuild scheduled for merge)
^ ^ 

  

  (dev-util/boost-build-1.56.0:0/0::gentoo, ebuild scheduled for merge) pulled 
in by
=dev-util/boost-build-1.56* required by 
(dev-libs/boost-1.56.0-r1:0/1.56.0::gentoo, ebuild scheduled for merge)
^ ^ 

  

media-video/ffmpeg:0

  (media-video/ffmpeg-2.6.3:0/54.56.56::gentoo, ebuild scheduled for merge) 
pulled in by
(no parents that aren't satisfied by other packages in this slot)

  (media-video/ffmpeg-2.2.14:0/52.55.55::gentoo, installed) pulled in by
media-video/ffmpeg:0/52.55.55=[vdpau] required by 
(media-libs/mlt-0.9.0:0/0::gentoo, installed)
    
   


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.


!!! The ebuild selected to satisfy "sci-libs/hdf5" has unmet requirements.
- sci-libs/hdf5-1.8.14-r1::gentoo USE="cxx fortran threads zlib -debug 
-examples -fortran2003 -mpi -static-libs -szip"

  The following REQUIRED_USE flag constraints are unsatisfied:
threads? ( !cxx !fortran )

  The above constraints are a subset of the following complete expression:
cxx? ( !mpi ) mpi? ( !cxx ) threads? ( !cxx !mpi !fortran ) fortran2003? ( 
fortran )

(dependency required by "media-libs/openimageio-1.3.5::gentoo" [installed])
(dependency required by "@selected" [set])
(dependency required by "@world" [argument])


I could remove boost (and maybe reinstall it later), but I would like to
keep ffmpeg.  hdf5 apparently goes back to having blender installed,
which I would also like to keep.  And apparently, I would have to remove
libreoffice before I could update.

Why can't we just update like we can with any other distribution but
have to run into dependency problems all the time instead?

What do I do when I need to update /right now/ and find myself being
blocked with cryptic messages like the above that leave me stranded?
Once I used 'emerge --sync', there is no way to turn it back to continue
to be able to install software if needed when the update cannot be
performed.  Updates simply need to work, there's no way around that.


-- 
Again we must be afraid of speaking of daemons for fear that daemons
might swallow us.  Finally, this fear has become reasonable.

Re: [gentoo-user] update problems

[Neil Bothwick]

On Sat, 19 Sep 2015 21:36:06 +0200, lee wrote:

> emerge -j 8 -a --update --newuse --deep --with-bdeps=y
> @world
>   
>  
> 
>  * IMPORTANT: 4 news items need reading for repository 'gentoo'.
>  * Use eselect news read to view new items.
> 
> 
> These are the packages that would be merged, in 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/boost:0
> 
>   (dev-libs/boost-1.56.0-r1:0/1.56.0::gentoo, ebuild scheduled for
> merge) pulled in by (no parents that aren't satisfied by other packages
> in this slot)
> 
>   (dev-libs/boost-1.55.0-r2:0/1.55.0::gentoo, ebuild scheduled for
> merge) pulled in by dev-libs/boost:0/1.55.0= required by
> (dev-libs/librevenge-0.0.2:0/0::gentoo, installed)
> ^^ (and 2 more with the same problem)
> 
> dev-util/boost-build:0
> 
>   (dev-util/boost-build-1.55.0:0/0::gentoo, installed) pulled in by
> =dev-util/boost-build-1.55* required by
> (dev-libs/boost-1.55.0-r2:0/1.55.0::gentoo, ebuild scheduled for merge)
> ^
> ^ 
>   
> 
>   (dev-util/boost-build-1.56.0:0/0::gentoo, ebuild scheduled for merge)
> pulled in by =dev-util/boost-build-1.56* required by
> (dev-libs/boost-1.56.0-r1:0/1.56.0::gentoo, ebuild scheduled for merge)
> ^
> ^ 
>   
> 
> media-video/ffmpeg:0
> 
>   (media-video/ffmpeg-2.6.3:0/54.56.56::gentoo, ebuild scheduled for
> merge) pulled in by (no parents that aren't satisfied by other packages
> in this slot)
> 
>   (media-video/ffmpeg-2.2.14:0/52.55.55::gentoo, installed) pulled in by
> media-video/ffmpeg:0/52.55.55=[vdpau] required by
> (media-libs/mlt-0.9.0:0/0::gentoo, installed)
> ^^^   
>   
These are unimportant, it is simply portage telling you it is not
updating some packages to the latest available and why. Personally, I
believe this sort of output should only be shown when using --verbose. 

> 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.
> 
> 
> !!! The ebuild selected to satisfy "sci-libs/hdf5" has unmet
> requirements.
> - sci-libs/hdf5-1.8.14-r1::gentoo USE="cxx fortran threads zlib -debug
> -examples -fortran2003 -mpi -static-libs -szip"
> 
>   The following REQUIRED_USE flag constraints are unsatisfied:
> threads? ( !cxx !fortran )

This is blocking you and the reason is given, if you have the threads
flag on, cxx and fortran must be off. You have both threads and cxx on
which won't work.

> Why can't we just update like we can with any other distribution but
> have to run into dependency problems all the time instead?

These aren't dependency problems, they are conflicting USE flags, a
situation that cannot arise with a binary distro. If you want the
flexibility that USE flags offer, you have to accept that not all
combinations will work together.

> What do I do when I need to update /right now/ and find myself being
> blocked with cryptic messages like the above that leave me stranded?

That's the real problem, that the messages are so cryptic. The solution
is simple, working out what needs to be done from the messages is not.

> Once I used 'emerge --sync', there is no way to turn it back to continue
> to be able to install software if needed when the update cannot be
> performed.  Updates simply need to work, there's no way around that.

You can always roll back by masking the updates if necessary, and the
old ebuilds are always available. Now that the tree is using git, it is
probably possibly to sync back to yesterday if you need to.


-- 
Neil Bothwick

WINDOWS: Will Install Needless Data On Whole System


pgp1qoOW22Hya.pgp
Description: OpenPGP digital signature

[gentoo-user] update problems after profile update

[Arnau Bria]

Hi all,

today I've sync my portage and noticed that I had to change my profile,
from default/linux/x86/10.0/desktop to default/linux/x86/10.0.
*not sure if my problem comes from changing profile...

then I did my emerge -uDvpt world and found that I had to add some use
flags to some packages:

first:
emerge: there are no ebuilds built with USE flags to satisfy 
=x11-libs/qt-qt3support-4.5.1:4[accessibility,kde].
!!! One of the following packages is required to complete your request:
- x11-libs/qt-qt3support-4.5.3 (Change USE: +kde)

x11-libs/qt-qt3support kde

then
x11-libs/qt-core qt3support

and finally:
x11-libs/qt-gui qt3support

and after adding 3 use I found that now I had to:

- x11-libs/qt-core-4.5.3-r2 (Change USE: -qt3support)

how is it possible is previpously I was told to add qt3support to same
package? and how may I solve this issue?

TIA,

-- 
Arnau Bria
http://blog.emergetux.net
Bombing for peace is like fucking for virginity

Re: [gentoo-user] update problems after profile update

[Alan McKinnon]

On Tuesday 10 November 2009 12:14:13 Arnau Bria wrote:
 Hi all,
 
 today I've sync my portage and noticed that I had to change my profile,
 from default/linux/x86/10.0/desktop to default/linux/x86/10.0.
 *not sure if my problem comes from changing profile...

err, according to that you didn't change profile at all

 then I did my emerge -uDvpt world and found that I had to add some use
 flags to some packages:
 
 first:
 emerge: there are no ebuilds built with USE flags to satisfy
  =x11-libs/qt-qt3support-4.5.1:4[accessibility,kde]. !!! One of the
  following packages is required to complete your request: -
  x11-libs/qt-qt3support-4.5.3 (Change USE: +kde)
 
 x11-libs/qt-qt3support kde
 
 then
 x11-libs/qt-core qt3support
 
 and finally:
 x11-libs/qt-gui qt3support
 
 and after adding 3 use I found that now I had to:
 
 - x11-libs/qt-core-4.5.3-r2 (Change USE: -qt3support)
 
 how is it possible is previpously I was told to add qt3support to same
 package? and how may I solve this issue?


More output please, especially emerge -t

What you supplied should that there's trouble with some qt packages. Most 
likely you have two packages that have conflicting needs with regard to qt, 
but without the actual output we cannot help you.


-- 
alan dot mckinnon at gmail dot com

Re: [gentoo-user] update problems after profile update

[Arnau Bria]

On Tue, 10 Nov 2009 12:17:20 +0200
Alan McKinnon wrote:

 On Tuesday 10 November 2009 12:14:13 Arnau Bria wrote:
  profile, from default/linux/x86/10.0/desktop to
  default/linux/x86/10.0. *not sure if my problem comes from changing
  profile...
 
 err, according to that you didn't change profile at all
they are 2 diff profiles:
 # eselect profile list
Available profile symlink targets:
  [1]   default/linux/x86/10.0 *
  [2]   default/linux/x86/10.0/desktop
  [3]   default/linux/x86/10.0/developer
  [4]   default/linux/x86/10.0/server
[...]

[...]
 More output please, especially emerge -t
This is the original output, with no use change:

Calculating dependencies... done!

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

x11-libs/qt-script:4

  ('ebuild', '/', 'x11-libs/qt-script-4.5.3-r1', 'merge') pulled in by
=x11-libs/qt-script-4.5.1:4 required by ('ebuild', '/', 
'kde-base/akregator-4.3.1', 'merge')
~x11-libs/qt-script-4.5.3[-debug] required by ('ebuild', '/', 
'x11-libs/qt-gui-4.5.3-r2', 'merge')
=x11-libs/qt-script-4.5.1:4 required by ('installed', '/', 
'dev-python/PyQt4-4.5.4-r4', 'nomerge')

  ('installed', '/', 'x11-libs/qt-script-4.5.1', 'nomerge') pulled in by
~x11-libs/qt-script-4.5.1[-debug] required by ('installed', '/', 
'x11-libs/qt-gui-4.5.1', 'nomerge')

x11-libs/qt-dbus:4

  ('ebuild', '/', 'x11-libs/qt-dbus-4.5.3-r1', 'merge') pulled in by
=x11-libs/qt-dbus-4.5.1:4 required by ('installed', '/', 
'dev-python/PyQt4-4.5.4-r4', 'nomerge')

  ('installed', '/', 'x11-libs/qt-dbus-4.5.1', 'nomerge') pulled in by
~x11-libs/qt-dbus-4.5.1[-debug] required by ('installed', '/', 
'x11-libs/qt-gui-4.5.1', 'nomerge')

x11-libs/qt-core:4

  ('ebuild', '/', 'x11-libs/qt-core-4.5.3-r2', 'merge') pulled in by
~x11-libs/qt-core-4.5.3[-debug] required by ('ebuild', '/', 
'x11-libs/qt-script-4.5.3-r1', 'merge')
~x11-libs/qt-core-4.5.3[glib,-debug,-qt3support] required by ('ebuild', 
'/', 'x11-libs/qt-gui-4.5.3-r2', 'merge')
~x11-libs/qt-core-4.5.3[-debug] required by ('ebuild', '/', 
'x11-libs/qt-dbus-4.5.3-r1', 'merge')
(and 3 more)

  ('installed', '/', 'x11-libs/qt-core-4.5.1', 'nomerge') pulled in by
~x11-libs/qt-core-4.5.1[glib,qt3support,-debug] required by ('installed', 
'/', 'x11-libs/qt-gui-4.5.1', 'nomerge')
~x11-libs/qt-core-4.5.1[-debug] required by ('installed', '/', 
'x11-libs/qt-dbus-4.5.1', 'nomerge')
~x11-libs/qt-core-4.5.1[-debug] required by ('installed', '/', 
'x11-libs/qt-script-4.5.1', 'nomerge')
(and 2 more)

x11-libs/qt-gui:4

  ('ebuild', '/', 'x11-libs/qt-gui-4.5.3-r2', 'merge') pulled in by
~x11-libs/qt-gui-4.5.3[-debug,-qt3support] required by ('ebuild', '/', 
'x11-libs/qt-opengl-4.5.3-r1', 'merge')
x11-libs/qt-gui:4 required by ('installed', '/', 'x11-libs/qscintilla-2.4', 
'nomerge')
~x11-libs/qt-gui-4.5.3[-debug] required by ('ebuild', '/', 
'x11-libs/qt-svg-4.5.3-r1', 'merge')

  ('installed', '/', 'x11-libs/qt-gui-4.5.1', 'nomerge') pulled in by
=x11-libs/qt-gui-4.5.1:4[accessibility,dbus] required by ('ebuild', '/', 
'kde-base/akregator-4.3.1', 'merge')
~x11-libs/qt-gui-4.5.1[qt3support,accessibility,-debug] required by 
('installed', '/', 'x11-libs/qt-qt3support-4.5.1', 'nomerge')
~x11-libs/qt-gui-4.5.1[qt3support] required by ('installed', '/', 
'x11-libs/qt-core-4.5.1', 'nomerge')
(and 1 more)



 What you supplied should that there's trouble with some qt packages.
 Most likely you have two packages that have conflicting needs with
 regard to qt, but without the actual output we cannot help you.
you're right, I missed some importnat info... sorry about that.

so, do I have to remove old packages?

Cheers,
-- 
Arnau Bria
http://blog.emergetux.net
Bombing for peace is like fucking for virginity

Re: [gentoo-user] update problems after profile update

[Arnau Bria]

On Tue, 10 Nov 2009 04:40:28 -0600
Dale Dale wrote:

 Alan McKinnon wrote:

 I'm trying to figure out WHY he had to change it from a desktop
 profile to a plain profile.  Did the OP get told this by portage or
 did he change the requirements for his Gentoo install?  10.0 is the
 current set of profiles.

my first update attempt after syncing...

# emerge -uDvpt world

!!! Your current profile is deprecated and not supported anymore.
!!! Please upgrade to the following profile if possible:
default/linux/x86/10.0/desktop

To upgrade do the following steps:
# Check 'eselect profile list'.
# Find the number that corresponds with the default/linux/x86/10.0 profile.
# Use 'eselect profile set number' to set a new /etc/make.profile symlink.
#
# Reference: http://www.gentoo.org/doc/en/gentoo-upgrading.xml
# See: General instructions in Section 3. Profile updating instructions



# eselect profile list
Available profile symlink targets:
  [1]   default/linux/x86/10.0 *
  [2]   default/linux/x86/10.0/desktop
  [3]   default/linux/x86/10.0/developer
  [4]   default/linux/x86/10.0/server
  [5]   hardened/linux/x86/10.0
  [6]   selinux/2007.0/x86
  [7]   selinux/2007.0/x86/hardened
  [8]   selinux/v2refpolicy/x86
  [9]   selinux/v2refpolicy/x86/desktop
  [10]  selinux/v2refpolicy/x86/developer
  [11]  selinux/v2refpolicy/x86/hardened
  [12]  selinux/v2refpolicy/x86/server

I ws on 2 and now at 1.

 Maybe I am misreading something here.
Maybe I've not expressed my problem propertly :-(

 Dale
 
 :-)  :-) 
Cheers,

-- 
Arnau Bria
http://blog.emergetux.net
Bombing for peace is like fucking for virginity

Re: [gentoo-user] update problems after profile update

[Dale]

Alan McKinnon wrote:
 On Tuesday 10 November 2009 12:14:13 Arnau Bria wrote:
   
 Hi all,

 today I've sync my portage and noticed that I had to change my profile,
 from default/linux/x86/10.0/desktop to default/linux/x86/10.0.
 *not sure if my problem comes from changing profile...
 

 err, according to that you didn't change profile at all
   

I'm trying to figure out WHY he had to change it from a desktop profile
to a plain profile.  Did the OP get told this by portage or did he
change the requirements for his Gentoo install?  10.0 is the current set
of profiles.

Maybe I am misreading something here.

Dale

:-)  :-) 

Re: [gentoo-user] update problems after profile update

[Dale]

Arnau Bria wrote:
 On Tue, 10 Nov 2009 04:40:28 -0600
 Dale Dale wrote:

   
 Alan McKinnon wrote:
 

   
 I'm trying to figure out WHY he had to change it from a desktop
 profile to a plain profile.  Did the OP get told this by portage or
 did he change the requirements for his Gentoo install?  10.0 is the
 current set of profiles.
 

 my first update attempt after syncing...

 # emerge -uDvpt world

 !!! Your current profile is deprecated and not supported anymore.
 !!! Please upgrade to the following profile if possible:
 default/linux/x86/10.0/desktop

 To upgrade do the following steps:
 # Check 'eselect profile list'.
 # Find the number that corresponds with the default/linux/x86/10.0 profile.
 # Use 'eselect profile set number' to set a new /etc/make.profile symlink.
 #
 # Reference: http://www.gentoo.org/doc/en/gentoo-upgrading.xml
 # See: General instructions in Section 3. Profile updating instructions

 

 # eselect profile list
 Available profile symlink targets:
   [1]   default/linux/x86/10.0 *
   [2]   default/linux/x86/10.0/desktop
   [3]   default/linux/x86/10.0/developer
   [4]   default/linux/x86/10.0/server
   [5]   hardened/linux/x86/10.0
   [6]   selinux/2007.0/x86
   [7]   selinux/2007.0/x86/hardened
   [8]   selinux/v2refpolicy/x86
   [9]   selinux/v2refpolicy/x86/desktop
   [10]  selinux/v2refpolicy/x86/developer
   [11]  selinux/v2refpolicy/x86/hardened
   [12]  selinux/v2refpolicy/x86/server

 I ws on 2 and now at 1.

   
 Maybe I am misreading something here.
 
 Maybe I've not expressed my problem propertly :-(

   
 Dale

 :-)  :-) 
 
 Cheers,

   

I don't think it is you.  Alan, why is portage telling him that
10.0/desktop is deprecated?  I'm using that profile myself with no problems.

r...@smoker / # eselect profile list
Available profile symlink targets:
  [1]   default/linux/x86/10.0
  [2]   default/linux/x86/10.0/desktop *
  [3]   default/linux/x86/10.0/developer
  [4]   default/linux/x86/10.0/server
  [5]   hardened/linux/x86/10.0
  [6]   selinux/2007.0/x86
  [7]   selinux/2007.0/x86/hardened
  [8]   selinux/v2refpolicy/x86
  [9]   selinux/v2refpolicy/x86/desktop
  [10]  selinux/v2refpolicy/x86/developer
  [11]  selinux/v2refpolicy/x86/hardened
  [12]  selinux/v2refpolicy/x86/server
r...@smoker / #   

Dale

:-)  :-) 

Re: [gentoo-user] update problems after profile update

[Alan McKinnon]

On Tuesday 10 November 2009 12:33:37 Arnau Bria wrote:
 On Tue, 10 Nov 2009 12:17:20 +0200
 
 Alan McKinnon wrote:
  On Tuesday 10 November 2009 12:14:13 Arnau Bria wrote:
   profile, from default/linux/x86/10.0/desktop to
   default/linux/x86/10.0. *not sure if my problem comes from changing
   profile...
 
  err, according to that you didn't change profile at all
 
 they are 2 diff profiles:
  # eselect profile list
 Available profile symlink targets:
   [1]   default/linux/x86/10.0 *
   [2]   default/linux/x86/10.0/desktop
   [3]   default/linux/x86/10.0/developer
   [4]   default/linux/x86/10.0/server
 [...]
 
 [...]
 
  More output please, especially emerge -t
 
 This is the original output, with no use change:
 
 Calculating dependencies... done!
 
 !!! Multiple package instances within a single package slot have been
  pulled !!! into the dependency graph, resulting in a slot conflict:
 
 x11-libs/qt-script:4
 
   ('ebuild', '/', 'x11-libs/qt-script-4.5.3-r1', 'merge') pulled in by
 
 =x11-libs/qt-script-4.5.1:4 required by ('ebuild', '/',
  'kde-base/akregator-4.3.1', 'merge')
 
 ~x11-libs/qt-script-4.5.3[-debug] required by ('ebuild', '/',
  'x11-libs/qt-gui-4.5.3-r2', 'merge')
 
 =x11-libs/qt-script-4.5.1:4 required by ('installed', '/',
  'dev-python/PyQt4-4.5.4-r4', 'nomerge')
 
   ('installed', '/', 'x11-libs/qt-script-4.5.1', 'nomerge') pulled in by
 ~x11-libs/qt-script-4.5.1[-debug] required by ('installed', '/',
  'x11-libs/qt-gui-4.5.1', 'nomerge')
 
 x11-libs/qt-dbus:4
 
   ('ebuild', '/', 'x11-libs/qt-dbus-4.5.3-r1', 'merge') pulled in by
 
 =x11-libs/qt-dbus-4.5.1:4 required by ('installed', '/',
  'dev-python/PyQt4-4.5.4-r4', 'nomerge')
 
   ('installed', '/', 'x11-libs/qt-dbus-4.5.1', 'nomerge') pulled in by
 ~x11-libs/qt-dbus-4.5.1[-debug] required by ('installed', '/',
  'x11-libs/qt-gui-4.5.1', 'nomerge')
 
 x11-libs/qt-core:4
 
   ('ebuild', '/', 'x11-libs/qt-core-4.5.3-r2', 'merge') pulled in by
 ~x11-libs/qt-core-4.5.3[-debug] required by ('ebuild', '/',
  'x11-libs/qt-script-4.5.3-r1', 'merge')
  ~x11-libs/qt-core-4.5.3[glib,-debug,-qt3support] required by ('ebuild',
  '/', 'x11-libs/qt-gui-4.5.3-r2', 'merge') ~x11-libs/qt-core-4.5.3[-debug]
  required by ('ebuild', '/', 'x11-libs/qt-dbus-4.5.3-r1', 'merge') (and 3
  more)
 
   ('installed', '/', 'x11-libs/qt-core-4.5.1', 'nomerge') pulled in by
 ~x11-libs/qt-core-4.5.1[glib,qt3support,-debug] required by
  ('installed', '/', 'x11-libs/qt-gui-4.5.1', 'nomerge')
  ~x11-libs/qt-core-4.5.1[-debug] required by ('installed', '/',
  'x11-libs/qt-dbus-4.5.1', 'nomerge') ~x11-libs/qt-core-4.5.1[-debug]
  required by ('installed', '/', 'x11-libs/qt-script-4.5.1', 'nomerge') (and
  2 more)
 
 x11-libs/qt-gui:4
 
   ('ebuild', '/', 'x11-libs/qt-gui-4.5.3-r2', 'merge') pulled in by
 ~x11-libs/qt-gui-4.5.3[-debug,-qt3support] required by ('ebuild', '/',
  'x11-libs/qt-opengl-4.5.3-r1', 'merge') x11-libs/qt-gui:4 required by
  ('installed', '/', 'x11-libs/qscintilla-2.4', 'nomerge')
  ~x11-libs/qt-gui-4.5.3[-debug] required by ('ebuild', '/',
  'x11-libs/qt-svg-4.5.3-r1', 'merge')
 
   ('installed', '/', 'x11-libs/qt-gui-4.5.1', 'nomerge') pulled in by
 
 =x11-libs/qt-gui-4.5.1:4[accessibility,dbus] required by ('ebuild',
  '/', 'kde-base/akregator-4.3.1', 'merge')
 
 ~x11-libs/qt-gui-4.5.1[qt3support,accessibility,-debug] required by
  ('installed', '/', 'x11-libs/qt-qt3support-4.5.1', 'nomerge')
  ~x11-libs/qt-gui-4.5.1[qt3support] required by ('installed', '/',
  'x11-libs/qt-core-4.5.1', 'nomerge') (and 1 more)

You seem to have conflicting requirements for qt-gui

What do you have in make.conf and package.use regarding qt packages and those 
USE flags? Do you have any qt packages in your world file (you should not have 
for average use)?



-- 
alan dot mckinnon at gmail dot com

Re: [gentoo-user] update problems after profile update

[Daniel Pielmeier]

2009/11/10 Arnau Bria ar...@emergetux.net:
 my first update attempt after syncing...

 # emerge -uDvpt world

 !!! Your current profile is deprecated and not supported anymore.
 !!! Please upgrade to the following profile if possible:
        default/linux/x86/10.0/desktop

 To upgrade do the following steps:
 # Check 'eselect profile list'.
 # Find the number that corresponds with the default/linux/x86/10.0 profile.
 # Use 'eselect profile set number' to set a new /etc/make.profile symlink.
 #
 # Reference: http://www.gentoo.org/doc/en/gentoo-upgrading.xml
 # See: General instructions in Section 3. Profile updating instructions

 

 # eselect profile list
 Available profile symlink targets:
  [1]   default/linux/x86/10.0 *
  [2]   default/linux/x86/10.0/desktop
  [3]   default/linux/x86/10.0/developer
  [4]   default/linux/x86/10.0/server
  [5]   hardened/linux/x86/10.0
  [6]   selinux/2007.0/x86
  [7]   selinux/2007.0/x86/hardened
  [8]   selinux/v2refpolicy/x86
  [9]   selinux/v2refpolicy/x86/desktop
  [10]  selinux/v2refpolicy/x86/developer
  [11]  selinux/v2refpolicy/x86/hardened
  [12]  selinux/v2refpolicy/x86/server

 I ws on 2 and now at 1.

 Maybe I am misreading something here.
 Maybe I've not expressed my problem propertly :-(


Do you remember which profile you have used before. I am asking
because maybe it was the 2007 or 2008 profile which was depreciated
and portage somehow switched to the 10.0 profile but not the desktop
profile you had before. This caused some confusion when looking at
eselect profiles list, as it lead to the impression the 10.0 profile
got depreciated which is not the case. Try setting your profile to the
10.0/desktop profile and then again try to update world.

-- 
Daniel Pielmeier

Re: [gentoo-user] update problems after profile update

[Neil Bothwick]

On Tue, 10 Nov 2009 04:59:00 -0600, Dale wrote:

 I don't think it is you.  Alan, why is portage telling him that
 10.0/desktop is deprecated?  I'm using that profile myself with no
 problems.

It's not, it is telling him that x86/10.0 is deprecated and that he
should use x86/10.0/desktop. However, I've just tried switching to the
10.0 profile and emerge gave no deprecation warnings.

I'd suggest switching back to the desktop profile and resyncing before
messing with anything else.


-- 
Neil Bothwick

Strike any user to continue


signature.asc
Description: PGP signature

Re: [gentoo-user] update problems after profile update

[Arnau Bria]

On Tue, 10 Nov 2009 12:10:08 +0100
Daniel Pielmeier wrote:

[...]
 Do you remember which profile you have used before. 
nop :-( sorry.
when did the profile changed? cause my last update was 15/21 days ago...

 I am asking
 because maybe it was the 2007 or 2008 profile which was depreciated
 and portage somehow switched to the 10.0 profile but not the desktop
 profile you had before. This caused some confusion when looking at
 eselect profiles list, as it lead to the impression the 10.0 profile
 got depreciated which is not the case. Try setting your profile to the
 10.0/desktop profile and then again try to update world.

  # eselect profile set 2
[...]

emerge: there are no ebuilds built with USE flags to satisfy 
=x11-libs/qt-qt3support-4.5.1:4[accessibility,kde].
!!! One of the following packages is required to complete your request:
- x11-libs/qt-qt3support-4.5.3 (Change USE: +kde)

edit package.use and agian:

emerge: there are no ebuilds built with USE flags to satisfy 
=x11-libs/qt-webkit-4.5.1:4[kde].
!!! One of the following packages is required to complete your request:
- x11-libs/qt-webkit-4.5.3 (Change USE: +kde)

edit package.use and agian:

emerge: there are no ebuilds built with USE flags to satisfy 
=dev-db/mysql-5.0.76-r1[embedded,-minimal].
!!! One of the following packages is required to complete your request:
- dev-db/mysql-5.0.84-r1 (Change USE: +embedded)

edit package.use and agian:

works!

many thanks!

-- 
Arnau Bria
http://blog.emergetux.net
Bombing for peace is like fucking for virginity

Re: [gentoo-user] update problems after profile update

[Daniel Pielmeier]

2009/11/10 Arnau Bria ar...@emergetux.net:
 On Tue, 10 Nov 2009 12:10:08 +0100
 Daniel Pielmeier wrote:

 [...]
 Do you remember which profile you have used before.
 nop :-( sorry.
 when did the profile changed? cause my last update was 15/21 days ago...


The profile is never changed when running updates, the user has to
change it by using eselect or updating the make.profile symlink by
hand. There is a bug [1] open about a profile change without user
interaction. It seems something like this is only possible if there is
an ebuild which changes the profile, but imho this should not happen.

[1] http://bugs.gentoo.org/show_bug.cgi?id=292612

-- 
Daniel Pielmeier

Re: [gentoo-user] update problems after profile update

[Arnau Bria]

On Tue, 10 Nov 2009 12:44:48 +0100
Daniel Pielmeier wrote:

 The profile is never changed when running updates, the user has to
 change it by using eselect or updating the make.profile symlink by
 hand. There is a bug [1] open about a profile change without user
 interaction. It seems something like this is only possible if there is
 an ebuild which changes the profile, but imho this should not happen.
 
 [1] http://bugs.gentoo.org/show_bug.cgi?id=292612
well, I meant, when was older profile marked as deprecated? you asked
if I had 2007/2008 ...

anyway, from your replies i understood that I had an obsolete profile,
just that.

Thanks to all for your replies.

-- 
Arnau Bria
http://blog.emergetux.net
Bombing for peace is like fucking for virginity

[gentoo-user] Update problems

[Buwalda, A.]

Hi all,

A few days ago when doing an 'emerge -puD world' i got the message to
upgrade to the 2005.0 profile. I changed the link to make.profile to fit
the 2005.0 profile but since then I can't seem to update. I'm stuck with
the following error:

---
Calculating world dependencies |
!!! All ebuilds that could satisfy =sys-kernel/linux-headers-2.6 have
been masked.
!!! One of the following masked packages is required to complete your
request:
- sys-kernel/linux-headers-2.6.8.1-r2 (masked by: profile)
- sys-kernel/linux-headers-2.6.11 (masked by: profile, -* keyword)
- sys-kernel/linux-headers-2.6.8.1-r4 (masked by: profile)

For more information, see MASKED PACKAGES section in the emerge man page
or
section 2.2 Software Availability in the Gentoo Handbook.
!!!(dependency required by net-firewall/ipsec-tools-0.5-r1
[ebuild])


!!! Problem with ebuild net-firewall/ipsec-tools-0.5-r1
!!! Possibly a DEPEND/*DEPEND problem.

!!! Depgraph creation failed.
---

I've been playing around with the package.keywords file, but that
doesn't seem to have the solution :( Maybe unmerging ipsec-tools would
help, but i need racoon for the connection to the box :(

Does someone know how to fix this?

Thanx in advance,
-Arjen

--
gentoo-user@gentoo.org mailing list

RE: [gentoo-user] Update problems

[Buwalda, A.]

Whoa, this suprises even myself, am I messing things up here (its not my
only box)? Anyway, this is the path:

ls -al /etc/make.profile
lrwxr-xr-x  1 root root 52 Apr  8 22:30 /etc/make.profile -
../usr/portage/profiles/default-linux/x86/2005.0/2.4

I expected it to be 2.6? Now I'm even more confused :(

I thought I changed that to be 2.6.

Arjen Buwalda
Zis  Unix beheer
Concerndienst Automatisering
Universitair Medisch Centrum Utrecht
Huispost Fac.3.16
Tel: 030 - 2509074
Mail: [EMAIL PROTECTED]

 

 -Original Message-
 From: Edward Catmur [mailto:[EMAIL PROTECTED] 
 Sent: donderdag 14 april 2005 15:19
 To: gentoo-user@lists.gentoo.org
 Subject: Re: [gentoo-user] Update problems
 
  I changed the link to make.profile to fit the 2005.0 
 profile but since 
  then I can't seem to update. I'm stuck with the following error:
  
  ---
  Calculating world dependencies |
  !!! All ebuilds that could satisfy =sys-kernel/linux-headers-2.6 
  have been masked.
  !!! One of the following masked packages is required to 
 complete your
  request:
  - sys-kernel/linux-headers-2.6.8.1-r2 (masked by: profile)
  - sys-kernel/linux-headers-2.6.11 (masked by: profile, -* keyword)
  - sys-kernel/linux-headers-2.6.8.1-r4 (masked by: profile)
 
 Which profile are you using (full path)?
 
 --
 gentoo-user@gentoo.org mailing list
 
 

--
gentoo-user@gentoo.org mailing list