[gentoo-user] update problems

[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

[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 update like we can with any other distribution but
> have to run into dependency problems all the time instead?

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.

This is because of how Gentoo works. With a binary distro, there is only
one variant of a package. If package A depends on ldap, and cifs, and
kerberos and nfs, and you don't want any of those then that is tough
shit because you are going to get them. And you are going to get them
because the package maintainer said you are going to get them.

Gentoo gives you the choice, and sometimes your choices interfere with
other choices you make. Now you get to decide.

Binary distros run into the same problems as above, and the package
maintainer has to solve them. When that is done, the package gets pushed
out and you don't see what it took. You also don't have any choice.

In Gentoo, YOU have the role that a maintainer has on Fedora, YOU get to
find out how to solve the problem and YOU get to implement it. That is
the inevitable side-effect of having choice.

> 
> 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.

You seem unwilling to do what it takes to run Gentoo properly. I suggest
you delete your Gentoo systems and install Fedora instead. Gentoo is
obviously not for you.


-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] update problems

[Rich Freeman]

On Sat, Sep 19, 2015 at 3:57 PM, Alan McKinnon <alan.mckinnon@gmail.com> 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

[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.mckinnon@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

Re: [gentoo-user] update problems

[Neil Bothwick]

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

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."

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

Re: [gentoo-user] update problems

[Rich Freeman]

On Sun, Sep 20, 2015 at 7:52 AM, Neil Bothwick <neil@digimed.co.uk> 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

[gentoo-user] Re: update problems

[James]

Rich Freeman <rich0 <at> gentoo.org> writes:


> 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.

+1 

> 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.

Is the kool_aide spike with 151 rum?   just curious....


> 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.

DAG nabbit, I thought I understood the problem and then lost focus?


> 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.

and take our fun away?   Now you're moving to my side of the installer issue?

;-)


James

Re: [gentoo-user] update problems

[lee]

Rich Freeman <rich0@gentoo.org> writes:

> On Sat, Sep 19, 2015 at 3:57 PM, Alan McKinnon <alan.mckinnon@gmail.com> 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 solution later if you
like)" and "you need to fix this before you can proceed", I could be
straightforward by updating and looking into fixing things that bother
me eventually.  The system would still work fine, or better than before,
after the upgrade, which is the most important issue to begin with.

The software would be updated to the best achievable point then.  That's
like getting it 95%+ perfect with 0% effort from the user, and that's
pretty darn good.  The last 5% usually take 200% of the effort.  In this
case, it's impossible to get past 96.5% because the remaining 3.5%
inevitably must be decided by the user.  And if the users didn't have
their choices and their powers of making decisions, they'd become very
unhappy with Gentoo.


-- 
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 26/09/2015 11:47, lee wrote:
> Rich Freeman <rich0@gentoo.org> writes:
> 
>> On Sat, Sep 19, 2015 at 3:57 PM, Alan McKinnon <alan.mckinnon@gmail.com> 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 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.

> 
>>> 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.

Success has a small learning potential; failure has huge learning
potential. And with computing the most valuable lesson is often what not
to do.

> 
>> --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 solution later if you
> like)" and "you need to fix this before you can proceed", I could be
> straightforward by updating and looking into fixing things that bother
> me eventually.  The system would still work fine, or better than before,
> after the upgrade, which is the most important issue to begin with.

There's a huge problem with that.

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.

For instance, say you have two packages A and B, and both have USE flag
Z. On your system you have A build with Z and B built without Z. After a
sync, the latest ebuild for A says that is Z is enabled, then it
requires Z also be enabled in B.

Portage is not going to just change your USE preferences so it tells you
"dude, you need to disable Z for A, or enable it for B. I can't continue
till you fix that". Portage can tell you this because the data fits a
standard pattern.

Ah, but those things are rare. The real world we live in is much more
complicated than the exact thing in your PC's RAM - problems are more
like cyclic deps that conflict, and portage does not know what you want.

Instead it just dumps a crap load of related output and tells you to
figure it out, because it can't.

Binary distros get around this problem by removing your choice, so the
problem never happens there.


> 
> The software would be updated to the best achievable point then.

Err, that's exactly what portage already does. In the absence of errors,
it updates what it can. Some errors are considered serious enough, with
enough possible side-effects, that portage will not continue with a full
update till you fix them. You can often get around this by emerging
individual packages instead of everything using world

>  That's
> like getting it 95%+ perfect with 0% effort from the user, and that's
> pretty darn good.  The last 5% usually take 200% of the effort.  In this
> case, it's impossible to get past 96.5% because the remaining 3.5%
> inevitably must be decided by the user.  And if the users didn't have
> their choices and their powers of making decisions, they'd become very
> unhappy with Gentoo.


Again, that's exactly what portage does. Perhaps you don't see it yet
because portage doesn't pretty-print it's output much.

It's been said many times in this thread - the output could be more
useful. What usually goes unsaid is that doing that is insanely,
amazingly, frickingly HARD. The devs are improving portage all the time,
and I'm confident they will improve output when they know how to. Right
now, they probably don't, it's still a question without an answer.

If you know how to improve it, the devs will happily accept high-quality
patches.


[1] This is a very easy mistake to make. The dev can easily already have
the new version of automake so stuff just works for him.

-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] update problems

[lee]

Alan McKinnon <alan.mckinnon@gmail.com> writes:

> On 26/09/2015 11:47, lee wrote:
>> Rich Freeman <rich0@gentoo.org> writes:
>> 
>>> On Sat, Sep 19, 2015 at 3:57 PM, Alan McKinnon <alan.mckinnon@gmail.com> 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 oneself to do it.

> Success has a small learning potential; failure has huge learning
> potential. And with computing the most valuable lesson is often what not
> to do.

Not really: You end up learning so much about what not to do that you
can't do anything anymore because you have learned not to do it.  If you
don't experiment sufficiently and don't allow yourself to fail, you get
stuck and become unable to extend your limits.  Success is required for
without it, you won't make any progress and give up eventually.  A
failure can be a success, depending on your approach.

>>> --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 solution later if you
>> like)" and "you need to fix this before you can proceed", I could be
>> straightforward by updating and looking into fixing things that bother
>> me eventually.  The system would still work fine, or better than before,
>> after the upgrade, which is the most important issue to begin with.
>
> There's a huge problem with that.
>
> 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.

> For instance, say you have two packages A and B, and both have USE flag
> Z. On your system you have A build with Z and B built without Z. After a
> sync, the latest ebuild for A says that is Z is enabled, then it
> requires Z also be enabled in B.
>
> Portage is not going to just change your USE preferences so it tells you
> "dude, you need to disable Z for A, or enable it for B. I can't continue
> till you fix that". Portage can tell you this because the data fits a
> standard pattern.

That's the same thing the human would figure out.

> Ah, but those things are rare. The real world we live in is much more
> complicated than the exact thing in your PC's RAM - problems are more
> like cyclic deps that conflict, and portage does not know what you want.
>
> Instead it just dumps a crap load of related output and tells you to
> figure it out, because it can't.
>
> Binary distros get around this problem by removing your choice, so the
> problem never happens there.

That wasn't at all my point.  I don't expect portage to figure out what
a human cannot figure out.  I don't expect portage to make a decision a
human needs to make.

All I'm saying is, make it easier for the human to figure out what
portage has figured out by providing the human with better messages.

I'm sure portage does "know" which things *must* be "fixed" by a human
decision (like the USE flags) and which ones need not be fixed by human
decision.  So it could just tell the human, as I suggested, either: "you
must fix this" or "you my ignore this".

From there, the human can figure out what they need to fix and go from
there.  That's what I did in this case, and guess what, there were no
slot conflicts after fixing the USE flags.

>> The software would be updated to the best achievable point then.
>
> Err, that's exactly what portage already does. In the absence of errors,
> it updates what it can. Some errors are considered serious enough, with
> enough possible side-effects, that portage will not continue with a full
> update till you fix them. You can often get around this by emerging
> individual packages instead of everything using world

Then why should it be such a huge problem to have portage tell us what
we need to fix in the first place?  Let us humans fix just that and try
again and see what happens, breaking down the problem into more
manageable steps.  That would suit both the human and the computer.

>>  That's
>> like getting it 95%+ perfect with 0% effort from the user, and that's
>> pretty darn good.  The last 5% usually take 200% of the effort.  In this
>> case, it's impossible to get past 96.5% because the remaining 3.5%
>> inevitably must be decided by the user.  And if the users didn't have
>> their choices and their powers of making decisions, they'd become very
>> unhappy with Gentoo.
>
>
> Again, that's exactly what portage does. Perhaps you don't see it yet
> because portage doesn't pretty-print it's output much.

It throws lots of errors, making irrelevant ones appear as most
important and most important ones appear as minor.  It doesn't take
pretty-printing to do it the other way round, or to shut up about
irrelevant errors until the most important ones are fixed.

> It's been said many times in this thread - the output could be more
> useful. What usually goes unsaid is that doing that is insanely,
> amazingly, frickingly HARD. The devs are improving portage all the time,
> and I'm confident they will improve output when they know how to. Right
> now, they probably don't, it's still a question without an answer.
>
> If you know how to improve it, the devs will happily accept high-quality
> patches.

Ok, why is that so incredibly hard?

Somewhere, there must be a 'print' statement where it says "slot
conflict".  Add to that that those "can probably be ignored before other
problems are fixed" (and remove all these exclamation marks while you
are at it), and the human would tend to fix the other errors and the
slot conflicts might go away automagically just like they did in this
case.

If that is too hard, I would have to assume that portage doesn't "know"
whether there's a slot conflict or not and be amazed as to how it
produces any messages about them.


> [1] This is a very easy mistake to make. The dev can easily already have
> the new version of automake so stuff just works for him.

-- 
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.mckinnon@gmail.com

Re: [gentoo-user] update problems

[lee]

Alan McKinnon <alan.mckinnon@gmail.com> 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 <alan.mckinnon@gmail.com> 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

[lee]

Alec Ten Harmsel <alec@alectenharmsel.com> writes:

> On Tue, Sep 29, 2015 at 12:52:41AM +0200, lee wrote:
>>
>> Alan McKinnon <alan.mckinnon@gmail.com> 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

[Neil Bothwick]

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

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.

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

Re: [gentoo-user] update problems

[lee]

Neil Bothwick <neil@digimed.co.uk> 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 <neil@digimed.co.uk> 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 Mackenzie <acm@muc.de> writes:

> Hello, Lee.
>
> On Tue, Sep 29, 2015 at 08:45:10PM +0200, lee wrote:
>> Neil Bothwick <neil@digimed.co.uk> 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

[Neil Bothwick]

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

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

> Neil Bothwick <neil@digimed.co.uk> 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.

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

Re: [gentoo-user] update problems

[Rich Freeman]

On Thu, Oct 1, 2015 at 5:39 AM, Neil Bothwick <neil@digimed.co.uk> 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]

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

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

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

Re: [gentoo-user] update problems

[lee]

Neil Bothwick <neil@digimed.co.uk> writes:

> On Tue, 29 Sep 2015 20:45:10 +0200, lee wrote:
>
>> Neil Bothwick <neil@digimed.co.uk> 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, lee@yagibdah.de wrote:

> What is b.g.o.?

http://bugs.gentoo.org

allan

Re: [gentoo-user] update problems

[lee]

Alan McKinnon <alan.mckinnon@gmail.com> 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 to be smallest problem.  But
no, that requires quite a lot of packages and gives me a lengthy list
which looks like some kind of dependency hell.  So that was a no-go,
too.

Sure, I could also remove ffmpeg, but how do I know that I can reinstall
it after upgrading?

>> !!! 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

I gathered that much, but I didn't feel like trying to find out whether
it's better to disable threads or cxx and fortran because of the other
problems.  hdf5 was pulled in because of dependencies and not because I
installed it, so I didn't check its USE flags to begin with.

>> 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?

It depends on librevenge.

>> Why can't we just update like we can with any other distribution but
>> have to run into dependency problems all the time instead?
>
> 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.

It never told me that.

> This is because of how Gentoo works. With a binary distro, there is only
> one variant of a package. If package A depends on ldap, and cifs, and
> kerberos and nfs, and you don't want any of those then that is tough
> shit because you are going to get them. And you are going to get them
> because the package maintainer said you are going to get them.

That's one of the things that bothers me with binary distributions.

> Gentoo gives you the choice, and sometimes your choices interfere with
> other choices you make. Now you get to decide.
>
> Binary distros run into the same problems as above, and the package
> maintainer has to solve them. When that is done, the package gets pushed
> out and you don't see what it took. You also don't have any choice.
>
> In Gentoo, YOU have the role that a maintainer has on Fedora, YOU get to
> find out how to solve the problem and YOU get to implement it. That is
> the inevitable side-effect of having choice.

Where and how do the above messages give me choices?  They are telling
me that boost doesn't work with itself, that I cannot upgrade ffmpeg and
that I need to dis- or enable USE flags I've never touched.  I can make
a wild guess that removing boost and ffmpeg /might/ solve the problem,
and from my experience with the pdf reader, I can only assume that
chances that I cannot reinstall either after upgrading are pretty good.
My conclusion is that something in the repos might be broken because if
it wasn't, I wouldn't have these problems.

So my choices are to try to somehow force an upgrade and be left with a
non-working system, or to wait until the problems are fixed, or to ask
for help.

Asking for help turns out that I don't really have a choice because I
can either try to somehow force an upgrade and take the risk of being
left with a non-working system (because Gentoo gives me choices: perhaps
you can see the irony here), or not upgrade at all.

>> 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.
>
> You seem unwilling to do what it takes to run Gentoo properly. I suggest
> you delete your Gentoo systems and install Fedora instead. Gentoo is
> obviously not for you.

That is a really wild assumption you're making, to put it nicely.

Besides, IMO Fedora is run by stupid fascists who believe they can
dictate people what to think and take over the world --- which is
something I don't want to have anything to do with --- and I don't want
systemd, either, which appears to come along remarkably similar lines.
You'd have to suggest a better alternative, one that is better than
Gentoo.

Other than that, can't you imagine that there might be room for
improvement?  Like a way to undo an 'emerge --sync' and messages that
are more informative, or providing the user with actual choices that
would solve the problem and let them decide which solution they want
(think of aptitude, which Debian has)?

Or would you rather say that Gentoo seems unwilling to do what it takes
to make it easier to upgrade?  Yeah, I know, developer resources are
limited, but so are mine.


-- 
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

[J. Roeleveld]

On Sunday 20 September 2015 16:25:34 lee wrote:
> Alan McKinnon <alan.mckinnon@gmail.com> 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)>>     
> >>                       ^^^^^^^^^^^^
> > 
> > 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 to be smallest problem.  But
> no, that requires quite a lot of packages and gives me a lengthy list
> which looks like some kind of dependency hell.  So that was a no-go,
> too.
> 
> Sure, I could also remove ffmpeg, but how do I know that I can reinstall
> it after upgrading?

media-libs/mlt...
Lets have a look at your world-file.

> >> !!! 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
> 
> I gathered that much, but I didn't feel like trying to find out whether
> it's better to disable threads or cxx and fortran because of the other
> problems.  hdf5 was pulled in because of dependencies and not because I
> installed it, so I didn't check its USE flags to begin with.

Keep threads if you want performance.
Then again, what do you want to do with hdf?

> >> 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?
> 
> It depends on librevenge.

world-file?

> >> Why can't we just update like we can with any other distribution but
> >> have to run into dependency problems all the time instead?
> > 
> > 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.
> 
> It never told me that.

True, it's not clearly stated.

> > This is because of how Gentoo works. With a binary distro, there is only
> > one variant of a package. If package A depends on ldap, and cifs, and
> > kerberos and nfs, and you don't want any of those then that is tough
> > shit because you are going to get them. And you are going to get them
> > because the package maintainer said you are going to get them.
> 
> That's one of the things that bothers me with binary distributions.

The more freedom with the package manager, the more conflicts you might 
encounter.

> > Gentoo gives you the choice, and sometimes your choices interfere with
> > other choices you make. Now you get to decide.
> > 
> > Binary distros run into the same problems as above, and the package
> > maintainer has to solve them. When that is done, the package gets pushed
> > out and you don't see what it took. You also don't have any choice.
> > 
> > In Gentoo, YOU have the role that a maintainer has on Fedora, YOU get to
> > find out how to solve the problem and YOU get to implement it. That is
> > the inevitable side-effect of having choice.
> 
> Where and how do the above messages give me choices?  They are telling
> me that boost doesn't work with itself,

It does, just not versions that are too close and would end up overwriting 
each others files.

> that I cannot upgrade ffmpeg and
> that I need to dis- or enable USE flags I've never touched.

There are default USE-flags. 
In your config, in the profile and in the ebuilds.
Conflicts can always occur.

> I can make
> a wild guess that removing boost and ffmpeg /might/ solve the problem,
> and from my experience with the pdf reader, I can only assume that
> chances that I cannot reinstall either after upgrading are pretty good.
> My conclusion is that something in the repos might be broken because if
> it wasn't, I wouldn't have these problems.

I'm thinking world-file..

> So my choices are to try to somehow force an upgrade and be left with a
> non-working system, or to wait until the problems are fixed, or to ask
> for help.

force an upgrade?

> Asking for help turns out that I don't really have a choice because I
> can either try to somehow force an upgrade and take the risk of being
> left with a non-working system (because Gentoo gives me choices: perhaps
> you can see the irony here), or not upgrade at all.

How would you force an upgrade?

> >> 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.
> > 
> > You seem unwilling to do what it takes to run Gentoo properly. I suggest
> > you delete your Gentoo systems and install Fedora instead. Gentoo is
> > obviously not for you.
> 
> That is a really wild assumption you're making, to put it nicely.
> 
> Besides, IMO Fedora is run by stupid fascists who believe they can
> dictate people what to think and take over the world --- which is
> something I don't want to have anything to do with --- and I don't want
> systemd, either, which appears to come along remarkably similar lines.
> You'd have to suggest a better alternative, one that is better than
> Gentoo.

It depends, for someone who wants it all to work magically?
Or for someone who doesn't mind learning?

> Other than that, can't you imagine that there might be room for
> improvement?  Like a way to undo an 'emerge --sync' and messages that
> are more informative, or providing the user with actual choices that
> would solve the problem and let them decide which solution they want
> (think of aptitude, which Debian has)?

There is, several in fact.
One is called "Backups"
The other one is portage snapshots.

> Or would you rather say that Gentoo seems unwilling to do what it takes
> to make it easier to upgrade?  Yeah, I know, developer resources are
> limited, but so are mine.

Mine are even more limited, but I manage to upgrade multiple machines 
regularly (on average once every 2 months the whole lot)

--
Joost

Re: [gentoo-user] update problems

[Rich Freeman]

On Sun, Sep 20, 2015 at 1:24 PM, J. Roeleveld <joost@antarean.org> 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

[lee]

Rich Freeman <rich0@gentoo.org> writes:

> On Sun, Sep 20, 2015 at 1:24 PM, J. Roeleveld <joost@antarean.org> 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? ( !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])
| heimdali ~ #
`----


I tried without --backtrace, and it gives me the same output.


> 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.

Anyway:


,----
| heimdali ~ # emerge -a -1 boost
|
|  * 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!
| [ebuild     U  ] sys-devel/automake-wrapper-10 [9]
| [ebuild     U  ] dev-util/boost-build-1.56.0 [1.55.0] PYTHON_TARGETS="python2_7%*"
| [ebuild  r  U  ] dev-libs/boost-1.56.0-r1 [1.55.0-r2] PYTHON_TARGETS="python3_4* -python3_3*"
| [ebuild  rR    ] dev-libs/librevenge-0.0.2
| [ebuild     U  ] dev-util/mdds-0.12.1 [0.10.3]
| [ebuild  rR    ] app-text/libwps-0.3.1
| [ebuild  NS    ] sys-devel/automake-1.15 [1.11.6-r1, 1.13.4]
| [ebuild  r  U  ] dev-libs/icu-55.1 [54.1-r1]
| [ebuild  r  U  ] app-text/libetonyek-0.1.3 [0.1.1]
| [ebuild  rR    ] app-text/libebook-0.1.2
| [ebuild  rR    ] media-libs/libcdr-0.1.1
| [ebuild  rR    ] app-text/libmspub-0.1.2
| [ebuild  rR    ] media-libs/libvisio-0.1.1
| [ebuild  rR    ] gnustep-base/gnustep-base-1.24.6-r1
| [ebuild  rR    ] media-libs/raptor-2.0.9
| [ebuild  r  U  ] dev-cpp/libcmis-0.5.0-r1 [0.5.0]
| [ebuild  r  U  ] dev-libs/libixion-0.9.0 [0.7.0] PYTHON_TARGETS="python2_7%*"
| [ebuild  r  U  ] dev-libs/liborcus-0.7.1 [0.7.0]
| [ebuild  r  U  ] media-libs/harfbuzz-0.9.41 [0.9.38] USE="-fontconfig%"
| [ebuild  r  U  ] net-libs/webkit-gtk-2.4.9-r200 [2.4.8-r200]
| [ebuild  r  U  ] app-office/libreoffice-4.4.5.2 [4.4.1.2] PYTHON_TARGETS="python3_4* -python3_3*"
|
| The following packages are causing rebuilds:
|
|   (dev-libs/libixion-0.9.0:0/0.10::gentoo, ebuild scheduled for merge) causes rebuilds for:
|     (dev-libs/liborcus-0.7.1:0/0::gentoo, ebuild scheduled for merge)
|   (dev-libs/icu-55.1:0/55::gentoo, ebuild scheduled for merge) causes rebuilds for:
|     (media-libs/harfbuzz-0.9.41:0/0.9.18::gentoo, ebuild scheduled for merge)
|     (media-libs/libcdr-0.1.1:0/0::gentoo, ebuild scheduled for merge)
|     (app-text/libebook-0.1.2:0/0::gentoo, ebuild scheduled for merge)
|     (media-libs/libvisio-0.1.1:0/0::gentoo, ebuild scheduled for merge)
|     (gnustep-base/gnustep-base-1.24.6-r1:0/0::gentoo, ebuild scheduled for merge)
|     (app-office/libreoffice-4.4.5.2:0/0::gentoo, ebuild scheduled for merge)
|     (media-libs/raptor-2.0.9:2/2::gentoo, ebuild scheduled for merge)
|     (net-libs/webkit-gtk-2.4.9-r200:2/2::gentoo, ebuild scheduled for merge)
|     (app-text/libmspub-0.1.2:0/0::gentoo, ebuild scheduled for merge)
|   (dev-util/mdds-0.12.1:0/0.12.1::gentoo, ebuild scheduled for merge) causes rebuilds for:
|     (dev-libs/libixion-0.9.0:0/0.10::gentoo, ebuild scheduled for merge)
|     (app-office/libreoffice-4.4.5.2:0/0::gentoo, ebuild scheduled for merge)
|   (dev-libs/boost-1.56.0-r1:0/1.56.0::gentoo, ebuild scheduled for merge) causes rebuilds for:
|     (dev-cpp/libcmis-0.5.0-r1:0.5/0.5::gentoo, ebuild scheduled for merge)
|     (dev-libs/liborcus-0.7.1:0/0::gentoo, ebuild scheduled for merge)
|     (app-text/libetonyek-0.1.3:0/0::gentoo, ebuild scheduled for merge)
|     (app-text/libebook-0.1.2:0/0::gentoo, ebuild scheduled for merge)
|     (app-office/libreoffice-4.4.5.2:0/0::gentoo, ebuild scheduled for merge)
|     (dev-libs/librevenge-0.0.2:0/0::gentoo, ebuild scheduled for merge)
|     (app-text/libwps-0.3.1:0/0::gentoo, ebuild scheduled for merge)
|     (dev-libs/libixion-0.9.0:0/0.10::gentoo, ebuild scheduled for merge)
|
| !!! The following installed packages are masked:
| - net-firewall/shorewall-4.6.6.2::gentoo (masked by: package.mask)
| /usr/portage/profiles/package.mask:
| # Ian Delaney <idella4@gentoo.org> (21 Jul 2015)
| # Packages deprecated in favour of new form of
| # net-firewall/shorewall
| # Bug #560392
|
| For more information, see the MASKED PACKAGES section in the emerge
| man page or refer to the Gentoo Handbook.
|
|
| Would you like to merge these packages? [Yes/No]
`----


What should I learn from this?  That we


+ need to update kinda recursively (because the package management can't
  do that for us because it's so complicated that only users with many
  years of experience with Gentoo can figure out how to upgrade
  eventually, sometimes requiring the combined effort of a mailing
  list),

+ 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),

+ 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))?


You see me confused.  And now I don't really feel like updating
anymore.  But I still want to [pouts].


--
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

[Rich Freeman]

On Sat, Sep 26, 2015 at 9:51 AM, lee <lee@yagibdah.de> 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

[lee]

Rich Freeman <rich0@gentoo.org> writes:

> On Sat, Sep 26, 2015 at 9:51 AM, lee <lee@yagibdah.de> 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

[Neil Bothwick]

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

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?

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

Re: [gentoo-user] update problems

[lee]

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

"J. Roeleveld" <joost@antarean.org> writes:

> On Sunday 20 September 2015 16:25:34 lee wrote:
>> Alan McKinnon <alan.mckinnon@gmail.com> 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



[-- Attachment #2: world.bz2 --]
[-- Type: application/x-bzip2, Size: 933 bytes --]

[-- Attachment #3: Type: text/plain, Size: 13475 bytes --]



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, 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.

Compiling stuff doesn't bother you when you have 24 cores and 48GB.  You
don't even notice other than that the fans may run a little faster.


> [...]
>> >> !!! 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
>> 
>> I gathered that much, but I didn't feel like trying to find out whether
>> it's better to disable threads or cxx and fortran because of the other
>> problems.  hdf5 was pulled in because of dependencies and not because I
>> installed it, so I didn't check its USE flags to begin with.
>
> Keep threads if you want performance.
> Then again, what do you want to do with hdf?

heimdali ~ # equery d hdf5
 * These packages depend on hdf5:
media-libs/openimageio-1.3.5 (sci-libs/hdf5)
heimdali ~ # equery d openimageio
 * These packages depend on openimageio:
media-gfx/blender-2.72b-r3 (cycles ? media-libs/openimageio)
                           (openimageio ? media-libs/openimageio)

>> >> 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?
>> 
>> It depends on librevenge.
>
> world-file?

above

> [...]
>> > This is because of how Gentoo works. With a binary distro, there is only
>> > one variant of a package. If package A depends on ldap, and cifs, and
>> > kerberos and nfs, and you don't want any of those then that is tough
>> > shit because you are going to get them. And you are going to get them
>> > because the package maintainer said you are going to get them.
>> 
>> That's one of the things that bothers me with binary distributions.
>
> 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.
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.

>> > Gentoo gives you the choice, and sometimes your choices interfere with
>> > other choices you make. Now you get to decide.
>> > 
>> > Binary distros run into the same problems as above, and the package
>> > maintainer has to solve them. When that is done, the package gets pushed
>> > out and you don't see what it took. You also don't have any choice.
>> > 
>> > In Gentoo, YOU have the role that a maintainer has on Fedora, YOU get to
>> > find out how to solve the problem and YOU get to implement it. That is
>> > the inevitable side-effect of having choice.
>> 
>> Where and how do the above messages give me choices?  They are telling
>> me that boost doesn't work with itself,
>
> It does, just not versions that are too close and would end up overwriting 
> each others files.

They are apparently trying to tell me that things will go horribly
wrong.  They are speaking of "slot conflicts" and use a bunch of
exclamation marks to point out the importance.

WTH is a "slot conflict"?  I can guess what that is, and I can speculate
about what might happen.  One of the possibilities that come to mind is
definitely *not* what I would want.

It would be nice if the messages were simply telling me what's actually
going on and what emerge would actually do.  Perhaps this is one of the
cases in which the programmer hasn't considered the user.  For the
programmer, these messages might be totally clear because they know what
they mean.  They aren't clear for the user because the user doesn't know
what they mean.  That is so because the messages don't tell the user
what they mean.  The solution is simple:  replace messages with messages
that tell the user what's going on.

The programmer might think that's a bad solution because they want to
improve the package manager in some great way so that it can solve all
problems, and implementing the solution requires a lot of work and time.
Unfortunately, that isn't very practical because until the great
solution is implemented, the users remain confused.  So in the meantime,
why not simply improve the messages --- and perhaps it turns out that
the great solution isn't even required because the users just solve the
problems themselves.  Users have a way of doing that, and not seldwhen,
they find unexpected ways which would never occur to a programmer.


> [...]
>> My conclusion is that something in the repos might be broken because if
>> it wasn't, I wouldn't have these problems.
>
> I'm thinking world-file..

You think it's broken?  If so, how might that have happened?

>> So my choices are to try to somehow force an upgrade and be left with a
>> non-working system, or to wait until the problems are fixed, or to ask
>> for help.
>
> force an upgrade?

Yeah, I don't know, there's probably some way to force ignoring
dependencies or something.

If there's not, well, I do have physical and root access, so I can do
anything I want.  That's how I messed up my first Linux installation
over 20 years ago, by changing file permissions beyond the point of
repair because it won't let me create a file where I wanted it and I
didn't know any better.  So I finally created the file, and the next
moment, I suddenly learned about file permissions and figured I better
reinstall.  I suppose for intelligent people, their own stupidity is the
kind most painful.

It was a good learning experience, though.  Ever since, I never was
forced to reinstall until I recently found out that xen with HVM cannot
be done on a non-multilib Gentoo (which I still think is stupid and
should be fixed).  Talk about the unexpected ways of programmers now ...

>> Asking for help turns out that I don't really have a choice because I
>> can either try to somehow force an upgrade and take the risk of being
>> left with a non-working system (because Gentoo gives me choices: perhaps
>> you can see the irony here), or not upgrade at all.
>
> How would you force an upgrade?

I don't know, I don't want to do that, so I haven't looked into it.  I
want to do it right, that's why I'm asking here.

>> >> 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.
>> > 
>> > You seem unwilling to do what it takes to run Gentoo properly. I suggest
>> > you delete your Gentoo systems and install Fedora instead. Gentoo is
>> > obviously not for you.
>> 
>> That is a really wild assumption you're making, to put it nicely.
>> 
>> Besides, IMO Fedora is run by stupid fascists who believe they can
>> dictate people what to think and take over the world --- which is
>> something I don't want to have anything to do with --- and I don't want
>> systemd, either, which appears to come along remarkably similar lines.
>> You'd have to suggest a better alternative, one that is better than
>> Gentoo.
>
> It depends, for someone who wants it all to work magically?
> Or for someone who doesn't mind learning?

What, Fedora?  It's much like windoze, in that it works only as long and
as much as it does, though better, and when you have something that
doesn't work or want something to work the way you want or need it to,
you're screwed.

If you're fine with that and don't mind their attitude, and if you like
what you get presented with, go Fedora, if you can get past the
installer.  Everything aside, they do make a good distribution --- which
seems to be greatly underrated, or a lot more people would use it,
especially on laptops.

Updates with Fedora don't always magically work, though.  There have
been quite a few occasions when the nvidia drivers were broken in the
repo.  So I suppose you can't use that, either.

Look at my world file; you'll see that I'll never be the kind of user
Fedora would be particularly attractive to, especially not out of the
box.

>> Other than that, can't you imagine that there might be room for
>> improvement?  Like a way to undo an 'emerge --sync' and messages that
>> are more informative, or providing the user with actual choices that
>> would solve the problem and let them decide which solution they want
>> (think of aptitude, which Debian has)?
>
> There is, several in fact.
> One is called "Backups"

You seriously expect a backup just to be able to undo an emerge --sync?
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.)

> The other one is portage snapshots.

That sounds like something I should learn about.

>> Or would you rather say that Gentoo seems unwilling to do what it takes
>> to make it easier to upgrade?  Yeah, I know, developer resources are
>> limited, but so are mine.
>
> Mine are even more limited, but I manage to upgrade multiple machines 
> regularly (on average once every 2 months the whole lot)

Perhaps that's because you've already gone through all the required
learning, having used Gentoo for a long time.  Not everyone has arrived
there yet.  That doesn't mean everyone is unwilling to learn, or to go
to extreme lengths to use Gentoo.


-- 
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

[J. Roeleveld]

On Saturday, September 26, 2015 03:10:48 PM lee wrote:
> "J. Roeleveld" <joost@antarean.org> writes:
> > On Sunday 20 September 2015 16:25:34 lee wrote:
> >> Alan McKinnon <alan.mckinnon@gmail.com> 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.

> >> > 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, 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.

How often do you actually update?

> Compiling stuff doesn't bother you when you have 24 cores and 48GB.  You
> don't even notice other than that the fans may run a little faster.

24 cores and 48GB, hmm....
I'd have put in a lot more memory with that many cores, but that's just me.

> >> >> !!! 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
> >>
> >> 
> >>
> >> I gathered that much, but I didn't feel like trying to find out whether
> >> it's better to disable threads or cxx and fortran because of the other
> >> problems.  hdf5 was pulled in because of dependencies and not because I
> >> installed it, so I didn't check its USE flags to begin with.
> > 
> > Keep threads if you want performance.
> > Then again, what do you want to do with hdf?
> 
> heimdali ~ # equery d hdf5
>  * These packages depend on hdf5:
> media-libs/openimageio-1.3.5 (sci-libs/hdf5)
> heimdali ~ # equery d openimageio
>  * These packages depend on openimageio:
> media-gfx/blender-2.72b-r3 (cycles ? media-libs/openimageio)
>                            (openimageio ? media-libs/openimageio)

I checked your world-file.
Why do you have the dependency (media-libs/openimageio) for blender in your 
world-file?
You could try deleting that from the world-file and trying again.

> >> > This is because of how Gentoo works. With a binary distro, there is
> >> > only
> >> > one variant of a package. If package A depends on ldap, and cifs, and
> >> > kerberos and nfs, and you don't want any of those then that is tough
> >> > shit because you are going to get them. And you are going to get them
> >> > because the package maintainer said you are going to get them.
> >>
> >> 
> >>
> >> That's one of the things that bothers me with binary distributions.
> > 
> > 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.
> 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.

The output of portage actually has improved a lot.
Still leaves room for improvement, but as not that many people are actually 
working on it, the output doesn't get much attention.

> >> > Gentoo gives you the choice, and sometimes your choices interfere with
> >> > other choices you make. Now you get to decide.
> >> >
> >> > Binary distros run into the same problems as above, and the package
> >> > maintainer has to solve them. When that is done, the package gets
> >> > pushed
> >> > out and you don't see what it took. You also don't have any choice.
> >> >
> >> > In Gentoo, YOU have the role that a maintainer has on Fedora, YOU get
> >> > to
> >> > find out how to solve the problem and YOU get to implement it. That is
> >> > the inevitable side-effect of having choice.
> >>
> >> Where and how do the above messages give me choices?  They are telling
> >> me that boost doesn't work with itself,
> > 
> > It does, just not versions that are too close and would end up
> > overwriting 
> > each others files.
> 
> They are apparently trying to tell me that things will go horribly
> wrong.  They are speaking of "slot conflicts" and use a bunch of
> exclamation marks to point out the importance.
> 
> WTH is a "slot conflict"?  I can guess what that is, and I can speculate
> about what might happen.  One of the possibilities that come to mind is
> definitely *not* what I would want.

2 versions inside a single slot are marked for installation.
Usually happens when dependencies are actually listed in a world-file.

> It would be nice if the messages were simply telling me what's actually
> going on and what emerge would actually do.  Perhaps this is one of the
> cases in which the programmer hasn't considered the user.  For the
> programmer, these messages might be totally clear because they know what
> they mean.  They aren't clear for the user because the user doesn't know
> what they mean.  That is so because the messages don't tell the user
> what they mean.  The solution is simple:  replace messages with messages
> that tell the user what's going on.
> 
> The programmer might think that's a bad solution because they want to
> improve the package manager in some great way so that it can solve all
> problems, and implementing the solution requires a lot of work and time.
> Unfortunately, that isn't very practical because until the great
> solution is implemented, the users remain confused.  So in the meantime,
> why not simply improve the messages --- and perhaps it turns out that
> the great solution isn't even required because the users just solve the
> problems themselves.  Users have a way of doing that, and not seldwhen,
> they find unexpected ways which would never occur to a programmer.
> 
> > [...]
> > 
> >> My conclusion is that something in the repos might be broken because if
> >> it wasn't, I wouldn't have these problems.
> > 
> > I'm thinking world-file..
> 
> You think it's broken?  If so, how might that have happened?

emerge <some dependency>
instead of
emerge -1 <some dependency>
(That's how it usually happens with me)

> >> So my choices are to try to somehow force an upgrade and be left with a
> >> non-working system, or to wait until the problems are fixed, or to ask
> >> for help.
> > 
> > force an upgrade?
> 
> Yeah, I don't know, there's probably some way to force ignoring
> dependencies or something.

There is, but definitely not recommended.

> If there's not, well, I do have physical and root access, so I can do
> anything I want.  That's how I messed up my first Linux installation
> over 20 years ago, by changing file permissions beyond the point of
> repair because it won't let me create a file where I wanted it and I
> didn't know any better.  So I finally created the file, and the next
> moment, I suddenly learned about file permissions and figured I better
> reinstall.  I suppose for intelligent people, their own stupidity is the
> kind most painful.

Too many "how (not) to"s mention chown -R 777 to solve issues.

> It was a good learning experience, though.  Ever since, I never was
> forced to reinstall until I recently found out that xen with HVM cannot
> be done on a non-multilib Gentoo (which I still think is stupid and
> should be fixed).  Talk about the unexpected ways of programmers now ...

Why stupid?
To avoid bit-conflicts, various libraries and tools need to be installed with 
32 and 64bit versions.
Doesn't require a re-install though, just change your profile and run " emerge 
-e @world"
Or add the ABI-useflags for the specific packages.

> >> Asking for help turns out that I don't really have a choice because I
> >> can either try to somehow force an upgrade and take the risk of being
> >> left with a non-working system (because Gentoo gives me choices: perhaps
> >> you can see the irony here), or not upgrade at all.
> > 
> > How would you force an upgrade?
> 
> I don't know, I don't want to do that, so I haven't looked into it.  I
> want to do it right, that's why I'm asking here.

Remove dependencies from world-file and try again.

> >> >> 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.
> >> >
> >> > You seem unwilling to do what it takes to run Gentoo properly. I
> >> > suggest
> >> > you delete your Gentoo systems and install Fedora instead. Gentoo is
> >> > obviously not for you.
> >>
> >> That is a really wild assumption you're making, to put it nicely.
> >>
> >> Besides, IMO Fedora is run by stupid fascists who believe they can
> >> dictate people what to think and take over the world --- which is
> >> something I don't want to have anything to do with --- and I don't want
> >> systemd, either, which appears to come along remarkably similar lines.
> >> You'd have to suggest a better alternative, one that is better than
> >> Gentoo.
> > 
> > It depends, for someone who wants it all to work magically?
> > Or for someone who doesn't mind learning?
> 
> Look at my world file; you'll see that I'll never be the kind of user
> Fedora would be particularly attractive to, especially not out of the
> box.

Actually, I don't see anything special in there, just a bunch of packages and 
occasionally a dependency for them.

> >> Other than that, can't you imagine that there might be room for
> >> improvement?  Like a way to undo an 'emerge --sync' and messages that
> >> are more informative, or providing the user with actual choices that
> >> would solve the problem and let them decide which solution they want
> >> (think of aptitude, which Debian has)?
> > 
> > There is, several in fact.
> > One is called "Backups"
> 
> You seriously expect a backup just to be able to undo an emerge --sync?
> Ok, then make it as easy to boot from ZFS as it is to boot from ext4.

Yes, provided you back-up the portage-tree.

> 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.)
>
> > The other one is portage snapshots.
> 
> That sounds like something I should learn about.

http://distfiles.gentoo.org/releases/snapshots/current/

> >> Or would you rather say that Gentoo seems unwilling to do what it takes
> >> to make it easier to upgrade?  Yeah, I know, developer resources are
> >> limited, but so are mine.
> > 
> > Mine are even more limited, but I manage to upgrade multiple machines 
> > regularly (on average once every 2 months the whole lot)
> 
> Perhaps that's because you've already gone through all the required
> learning, having used Gentoo for a long time.  Not everyone has arrived
> there yet.  That doesn't mean everyone is unwilling to learn, or to go
> to extreme lengths to use Gentoo.

Perhaps, but any system requires maintenance.
Maintenance takes time.

Either you do it yourself, or you find someone to do it for you.
Gentoo expects people to do it themselves.

Fedora (and others like it) expect people to follow what the developers 
decided.

--
Joost

Re: [gentoo-user] update problems

[Neil Bothwick]

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

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

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

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.mckinnon@gmail.com

Re: [gentoo-user] update problems

[Neil Bothwick]

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

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.

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

Re: [gentoo-user] update problems

[Neil Bothwick]

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

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

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

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. 
> 

<head_slap>

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.mckinnon@gmail.com

Re: [gentoo-user] update problems

[Mick]

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

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

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

Re: [gentoo-user] update problems

[lee]

Neil Bothwick <neil@digimed.co.uk> 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 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.

That's fine --- I know I need to look into the USE flags here, the
message is somewhat clear.  I pasted it only for the sake of
completeness.

And I appreciate that kind of choice very much, to the point where I
don't really see a way back to binary distributions.  They don't make
sense anymore, though they still have their uses.

>> 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.

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.

>> 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
<particular-git-hash>' would be much easier, taking you back to where
you were before you did an 'emerge --sync', or to when things were at
the particular hash.

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.

Should I make feature requests?


-- 
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

[Rich Freeman]

On Sun, Sep 20, 2015 at 11:28 AM, lee <lee@yagibdah.de> 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

[Alan McKinnon]

On 20/09/2015 17:28, lee wrote:
> Neil Bothwick <neil@digimed.co.uk> 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 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?

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.

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.

> 
>>> 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.
> 
> That's fine --- I know I need to look into the USE flags here, the
> message is somewhat clear.  I pasted it only for the sake of
> completeness.
> 
> And I appreciate that kind of choice very much, to the point where I
> don't really see a way back to binary distributions.  They don't make
> sense anymore, though they still have their uses.
> 
>>> 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.
> 
> 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.


> 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.
> 
>>> 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
> <particular-git-hash>' would be much easier, taking you back to where
> you were before you did an 'emerge --sync', or to when things were at
> the particular hash.
> 
> 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. 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.

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.


> Should I make feature requests?


No. See Rich's mail


-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] update problems

[lee]

Alan McKinnon <alan.mckinnon@gmail.com> writes:

> On 20/09/2015 17:28, lee wrote:
>> Neil Bothwick <neil@digimed.co.uk> 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

[Alan McKinnon]

On 26/09/2015 17:00, lee wrote:
> Alan McKinnon <alan.mckinnon@gmail.com> writes:
> 
>> On 20/09/2015 17:28, lee wrote:
>>> Neil Bothwick <neil@digimed.co.uk> 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
>>> 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:

So what? Gentoo is what it is. There are hundreds of Linux distros out
there. If some users are not prepared to do what it takes to run Gentoo,
and find something more suited to their needs then they should use that
and the Gentoo community will wish them well for the future.

>> 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.

Gentoo is not here to be your personal distro.

I think you might be happier with Arch, come to think of it.

> 
>> 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.

See below. You are considering the wrong problem.

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

The problem is not the tree. The problem is what you do with the tree,
and then desire to undo THAT. By far the most common reason to want to
rewind the tree is to have used it first. Emerging something usually
takes you past the point of no return.

p.s. Package management is hard. Really truly fucking annoyingly
frustratingly hard. And difficult to solve. That's why Windows doesn't
even try, MacOS shoves a walled garden down your throat, Debian thinks
their view must be perfect just because, and Red Hat charges lots of
money. Other teams try with varying success, giving us abominations like
npm.

Gentoo is one of the very few (perhaps only) distros that have the balls
to tackle this problem head on. Cut it some slack, please. Stop whinging.


-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] update problems

[Neil Bothwick]

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

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

> Neil Bothwick <neil@digimed.co.uk> 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
> <particular-git-hash>' would be much easier, taking you back to where
> you were before you did an 'emerge --sync', or to when things were at
> the particular hash.

This would make a useful addition to something like demerge, which
currently can roll back to previous versions, but git should make it
possible to include the tree too.

> 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.

Why not, the information is in the logs, and can be extracted with genlop
-r or qlop -s (emerge genlop or portage-utils respectively).


-- 
Neil Bothwick

Nymphomania-- an illness you hear about but never encounter.

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

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

[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 <package>` 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 <package>` - 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

[gentoo-user] Re: update problems

[James]

Daniel Frey <djqfrey <at> gmail.com> writes:


> For boost and ffmpeg, try running `equery depends <package>` 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 <package>` - in the case of boost it would be
> `emerge --deselect dev-libs/boost`.

Yea, many of us forget the --oneshot option whilst admining about.....

This is a recurring theme. Didn't somebody post a scipt a while
back to do this for you in one effort. Then you read the list result
and decide which do remove from the world file?

I cannot seem to find that script....


James

Re: [gentoo-user] Re: update problems

[Daniel Frey]

On 09/20/2015 11:07 AM, James wrote:
> Daniel Frey <djqfrey <at> gmail.com> writes:
> 
> 
>> For boost and ffmpeg, try running `equery depends <package>` 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 <package>` - in the case of boost it would be
>> `emerge --deselect dev-libs/boost`.
> 
> Yea, many of us forget the --oneshot option whilst admining about.....
> 

Yep, in my case I did it about 25 times over many years. Eventually
you'll get enough crap in the world file that portage has a hard time
updating. I usually remember --oneshot but if I'm tired or distracted I
forget it. :-)

Dan

Re: [gentoo-user] Re: update problems

[Dale]

Daniel Frey wrote:
> On 09/20/2015 11:07 AM, James wrote:
>> Daniel Frey <djqfrey <at> gmail.com> writes:
>>
>>
>>> For boost and ffmpeg, try running `equery depends <package>` 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 <package>` - in the case of boost it would be
>>> `emerge --deselect dev-libs/boost`.
>> Yea, many of us forget the --oneshot option whilst admining about.....
>>
> Yep, in my case I did it about 25 times over many years. Eventually
> you'll get enough crap in the world file that portage has a hard time
> updating. I usually remember --oneshot but if I'm tired or distracted I
> forget it. :-)
>
> Dan
>
>
>


To avoid this, I added it to my make.conf.  When I *really* want to have
something in the world file, I can either add it myself or use --select
on the command line to add it.  Result, shouldn't be anything in the
world file that shouldn't be there. 

I sometimes wonder why that isn't the default way.  I guess because it
would confuse folks for a bit and because it has always been that way.  ;-)

Dale

:-)  :-) 

[gentoo-user] Re: update problems

[James]

Dale <rdalek1967 <at> gmail.com> writes:


> > I usually remember --oneshot but if I'm tired or distracted I
> > forget it. 


> To avoid this, I added it to my make.conf.  When I *really* want to have
> something in the world file, I can either add it myself or use --select
> on the command line to add it.  Result, shouldn't be anything in the
> world file that shouldn't be there. 

OK, I'll try this. 
I'll add --oneshot to the EMERGE_DEFAULT_OPTS=  in make.conf.

Works great.

> I sometimes wonder why that isn't the default way.  I guess because it
> would confuse folks for a bit and because it has always been that way.  

One thing I see, is now you have a system that is full of pkg that do
not update normally. I guess I'm say if you install pakages with --oneshot,
they are not automatically updated, or are they? (discussion).

'emerge -uDNv world' is the most common form of update, probably, used
by gentoo users. So how to best ferret out those oneshot packages for
update; and that's if they should be updated....  semantics on that?


James

Re: [gentoo-user] Re: update problems

[Alan McKinnon]

On 22/09/2015 17:55, James wrote:
> Dale <rdalek1967 <at> gmail.com> writes:
> 
> 
>>> I usually remember --oneshot but if I'm tired or distracted I
>>> forget it. 
> 
> 
>> To avoid this, I added it to my make.conf.  When I *really* want to have
>> something in the world file, I can either add it myself or use --select
>> on the command line to add it.  Result, shouldn't be anything in the
>> world file that shouldn't be there. 
> 
> OK, I'll try this. 
> I'll add --oneshot to the EMERGE_DEFAULT_OPTS=  in make.conf.
> 
> Works great.
> 
>> I sometimes wonder why that isn't the default way.  I guess because it
>> would confuse folks for a bit and because it has always been that way.  
> 
> One thing I see, is now you have a system that is full of pkg that do
> not update normally. I guess I'm say if you install pakages with --oneshot,
> they are not automatically updated, or are they? (discussion).
> 
> 'emerge -uDNv world' is the most common form of update, probably, used
> by gentoo users. So how to best ferret out those oneshot packages for
> update; and that's if they should be updated....  semantics on that?


I think you two have it backwards.

The intended workflow is that if you emerge something, you know what it
is, you don't have to make further decisions about it and you want it in
world.

@world, by definition, is the list of packages you want. That plus
@system plus all deps constitutes the set of what should be on the
system, anything you have not in that set is subject to depcleaning

If you are not sure about some package, by all means emerge it with -1.
Check it out, verify it, make sure it does what you want then get it in
world with emerge -n. Why would you want to have stuff around for
extended periods that is not in world?

If you have a package that you no longer want (as you know what is in
your world right), unmerge it with -C

Don't make life difficult for yourself. It's MUCH easier to know what's
in world than to try and remember what should be and isn't.



-- 
Alan McKinnon
alan.mckinnon@gmail.com

[gentoo-user] Re: update problems

[James]

Alan McKinnon <alan.mckinnon <at> gmail.com> writes:



> > I'll add --oneshot to the EMERGE_DEFAULT_OPTS=  in make.conf.

> >> I sometimes wonder why that isn't the default way.  I guess because it
> >> would confuse folks for a bit and because it has always been that way.  

> > One thing I see, is now you have a system that is full of pkg that do
> > not update normally. I guess I'm say if you install pakages with --oneshot,
> > they are not automatically updated, or are they? (discussion).

> > 'emerge -uDNv world' is the most common form of update, probably, used
> > by gentoo users. So how to best ferret out those oneshot packages for
> > update; and that's if they should be updated....  semantics on that?

> I think you two have it backwards.

mostly true for routine users. I myself find myself testing codes
and inter operability between codes and stuff I write, more that 
just installing from the portage tree. I guess you could say I'm moving
from user to hacker status (with extreme prejudice). I do not alway
remember (-1); particularly when manually cleansing problems like the recent
ncurses episode. I like Dale's approach. I just need a tool option or simple
script that tells me what is installed and not in @system or @world.
Surely this code/option exist and I have just missed it in the literature?


> The intended workflow is that if you emerge something, you know what it
> is, you don't have to make further decisions about it and you want it
> in world.

users yes, hackers no. For a long time, I just used gentoo.
Now I'm coding (specifcations --> architecture --> then code)
and hacking (modifying other codes) quite a lot. I have a robust
world file that migrates from workstation to workstation and only
update it, replace pkgs, or add a select few niftyones, like
trace-cmd and heaptrack.

So I'm not suggesting this for normal, new gentoo users.


 <at> world, by definition, is the list of packages you want. That plus
 <at> system plus all deps constitutes the set of what should be on the
system, anything you have not in that set is subject to depcleaning

true.

If you are not sure about some package, by all means emerge it with -1.
Check it out, verify it, make sure it does what you want then get it in
world with emerge -n. Why would you want to have stuff around for
extended periods that is not in world?

Again, user focused, mostly true.

If you have a package that you no longer want (as you know what is in
your world right), unmerge it with -C

It's not that simple. I'm spending a large amount of my gentoo-admin
time installing--testing--marinating--modifying--testing--removal.
Dale's simple suggesting is brilliant for my needs. (thx Dale).

Don't make life difficult for yourself. It's MUCH easier to know what's
in world than to try and remember what should be and isn't.

Users (YES)   hackers(??? no in my case).

Sorry bro, I'm running with Dale in this one.

Now, I still need a --oneshot parser solution for vdb (/var/db/pkg/)?
1] Glep-64 preliminary code?
2] a DAG?
3] Neil's mod to CheckInstall?
4] a 'man page option' would be keenest; that I have missed?
5] a script?
6] or a profile?  [10]  default/linux/amd64/13.0/developer

I've been looking for some details on the developer profile;
a list of additional packages only or some other keen settings
and other goodies ?



James



 

Re: [gentoo-user] Re: update problems

[Alan McKinnon]

On 22/09/2015 18:39, James wrote:
> Alan McKinnon <alan.mckinnon <at> gmail.com> writes:
> 
> 
> 
>>> I'll add --oneshot to the EMERGE_DEFAULT_OPTS=  in make.conf.
> 
>>>> I sometimes wonder why that isn't the default way.  I guess because it
>>>> would confuse folks for a bit and because it has always been that way.  
> 
>>> One thing I see, is now you have a system that is full of pkg that do
>>> not update normally. I guess I'm say if you install pakages with --oneshot,
>>> they are not automatically updated, or are they? (discussion).
> 
>>> 'emerge -uDNv world' is the most common form of update, probably, used
>>> by gentoo users. So how to best ferret out those oneshot packages for
>>> update; and that's if they should be updated....  semantics on that?
> 
>> I think you two have it backwards.
> 
> mostly true for routine users. I myself find myself testing codes
> and inter operability between codes and stuff I write, more that 
> just installing from the portage tree. I guess you could say I'm moving
> from user to hacker status (with extreme prejudice). I do not alway
> remember (-1); particularly when manually cleansing problems like the recent
> ncurses episode. I like Dale's approach. I just need a tool option or simple
> script that tells me what is installed and not in @system or @world.
> Surely this code/option exist and I have just missed it in the literature?
> 
> 
>> The intended workflow is that if you emerge something, you know what it
>> is, you don't have to make further decisions about it and you want it
>> in world.
> 
> users yes, hackers no. For a long time, I just used gentoo.
> Now I'm coding (specifcations --> architecture --> then code)
> and hacking (modifying other codes) quite a lot. I have a robust
> world file that migrates from workstation to workstation and only
> update it, replace pkgs, or add a select few niftyones, like
> trace-cmd and heaptrack.
> 
> So I'm not suggesting this for normal, new gentoo users.
> 
> 
>  <at> world, by definition, is the list of packages you want. That plus
>  <at> system plus all deps constitutes the set of what should be on the
> system, anything you have not in that set is subject to depcleaning
> 
> true.
> 
> If you are not sure about some package, by all means emerge it with -1.
> Check it out, verify it, make sure it does what you want then get it in
> world with emerge -n. Why would you want to have stuff around for
> extended periods that is not in world?
> 
> Again, user focused, mostly true.
> 
> If you have a package that you no longer want (as you know what is in
> your world right), unmerge it with -C
> 
> It's not that simple. I'm spending a large amount of my gentoo-admin
> time installing--testing--marinating--modifying--testing--removal.
> Dale's simple suggesting is brilliant for my needs. (thx Dale).
> 
> Don't make life difficult for yourself. It's MUCH easier to know what's
> in world than to try and remember what should be and isn't.
> 
> Users (YES)   hackers(??? no in my case).
> 
> Sorry bro, I'm running with Dale in this one.

Portage can help with that then.

The trick is to realise the exact question you are asking: what packages
do I have installed for testing purposes and that are not in world?

Seeing as @world is really just a regular set, use sets to your
advantage. Create as many or as few or you need in /etc/portage/sets/
and emerge them (or just add the set name to /var/lib/portage/world_sets)

They will update with a deep world update, but they are together in one
place where you can add and remove them at will. Just don't do

emerge @set_name, that won;t do an update, it will re-emerge everything
in the set

> Now, I still need a --oneshot parser solution for vdb (/var/db/pkg/)?

--depclean

If portage wants to take it out, it's not in world or a dep. To the best
of my knowledge portage does not record that you used -1, it simply does
not add the package to world. So you need to do it the long way, which
is what --depclean does

> 1] Glep-64 preliminary code?
> 2] a DAG?
> 3] Neil's mod to CheckInstall?
> 4] a 'man page option' would be keenest; that I have missed?
> 5] a script?
> 6] or a profile?  [10]  default/linux/amd64/13.0/developer
> 
> I've been looking for some details on the developer profile;
> a list of additional packages only or some other keen settings
> and other goodies ?
> 
> 
> 
> James
> 
> 
> 
>  
> 
> 


-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] Re: update problems

[Neil Bothwick]

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

On Tue, 22 Sep 2015 18:03:19 +0200, Alan McKinnon wrote:

> The intended workflow is that if you emerge something, you know what it
> is, you don't have to make further decisions about it and you want it in
> world.
> 
> @world, by definition, is the list of packages you want. That plus
> @system plus all deps constitutes the set of what should be on the
> system, anything you have not in that set is subject to depcleaning
> 
> If you are not sure about some package, by all means emerge it with -1.
> Check it out, verify it, make sure it does what you want then get it in
> world with emerge -n. Why would you want to have stuff around for
> extended periods that is not in world?
> 
> If you have a package that you no longer want (as you know what is in
> your world right), unmerge it with -C
> 
> Don't make life difficult for yourself. It's MUCH easier to know what's
> in world than to try and remember what should be and isn't.

I take a different approach, I have a set called temp in my world_sets. If
I want to try something out, I "echo cat/pkg >>/etc/portage/sets/temp"
then I can try it and keep it updated during the trial and not have to
worry about its deps. All I need to do is look at the temp file from time
to time and remove anything I no longer want, then it gets depcleaned
along with its dependencies.

Putting --oneshot is the defaults is fine as long as you remember to
emerge -n anything you know you want. I've been using Gentoo for so long
that I automatically add -1 without thinking about it even when using -p!


-- 
Neil Bothwick

If Wile E. Coyote had enough money to buy all that ACME crap, why didn't
he just buy dinner?

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

Re: [gentoo-user] Re: update problems

[Alan McKinnon]

On 22/09/2015 18:42, Neil Bothwick wrote:
> On Tue, 22 Sep 2015 18:03:19 +0200, Alan McKinnon wrote:
> 
>> The intended workflow is that if you emerge something, you know what it
>> is, you don't have to make further decisions about it and you want it in
>> world.
>>
>> @world, by definition, is the list of packages you want. That plus
>> @system plus all deps constitutes the set of what should be on the
>> system, anything you have not in that set is subject to depcleaning
>>
>> If you are not sure about some package, by all means emerge it with -1.
>> Check it out, verify it, make sure it does what you want then get it in
>> world with emerge -n. Why would you want to have stuff around for
>> extended periods that is not in world?
>>
>> If you have a package that you no longer want (as you know what is in
>> your world right), unmerge it with -C
>>
>> Don't make life difficult for yourself. It's MUCH easier to know what's
>> in world than to try and remember what should be and isn't.
> 
> I take a different approach, I have a set called temp in my world_sets. If
> I want to try something out, I "echo cat/pkg >>/etc/portage/sets/temp"
> then I can try it and keep it updated during the trial and not have to
> worry about its deps. All I need to do is look at the temp file from time
> to time and remove anything I no longer want, then it gets depcleaned
> along with its dependencies.
> 
> Putting --oneshot is the defaults is fine as long as you remember to
> emerge -n anything you know you want. I've been using Gentoo for so long
> that I automatically add -1 without thinking about it even when using -p!

That can also work. I thought of maybe suggesting it later in the thread
but you got in there first.

Either way the owner of a Gentoo system still has to keep track on what
he wants to be on it.


-- 
Alan McKinnon
alan.mckinnon@gmail.com

[gentoo-user] Re: update problems

[James]

Neil Bothwick <neil <at> digimed.co.uk> writes:


> I take a different approach, I have a set called temp in my world_sets. If
> I want to try something out, I "echo cat/pkg >>/etc/portage/sets/temp"
> then I can try it and keep it updated during the trial and not have to
> worry about its deps. All I need to do is look at the temp file from time
> to time and remove anything I no longer want, then it gets depcleaned
> along with its dependencies.

That's a good approach. But, what I'm looking for could be a general
purpose tool for *all* of the gentoo community to parse and identify
packages that are not being updated or at lease fall into the orphan
category. One common case is those packages installed (-1). I'd venture to
guess from time to time that most gentoo users have packages installed that
are not dependencies for any other packages. Often is it by accident or
extreme manual cleansing events (like the recent ncurses episode) that folks
stumble across these orphaned packages.   I just think a tool or option in
an existing tool does/should cover that scenario. It is a routine need, imho.

That said are there any make.conf mods need to use sets like this,
or just create the dir and and use your command line string?

I might not use it permanently the way you do, but I can see putting
a collection of (-1) packages into a set, for organizational structure.
With clustering now infecting my gentoo world, I'll need a master by
architecture, logically organized collection of "sets" to cover the myriad
of node set-ups. Each system will most likely have a different installation
of these sets. And the cluster is now moving to a multi-arch setup
with aarch64.


So you idea is worth pursuit for me at this time. I still need that tool
to at least identify the (-1) installed packages. I know we have 'equery
depends' but that does not traverse the entire list of installed packages,
or did I miss that syntax?  Any ideas on that sort of (-1) parsing are
keenly appreciated ?


James

Re: [gentoo-user] Re: update problems

[Neil Bothwick]

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

On Tue, 22 Sep 2015 17:35:10 +0000 (UTC), James wrote:

> > I take a different approach, I have a set called temp in my
> > world_sets. If I want to try something out, I "echo cat/pkg
> > >>/etc/portage/sets/temp" then I can try it and keep it updated
> > >>during the trial and not have to
> > worry about its deps. All I need to do is look at the temp file from
> > time to time and remove anything I no longer want, then it gets
> > depcleaned along with its dependencies.  
> 
> That's a good approach. But, what I'm looking for could be a general
> purpose tool for *all* of the gentoo community to parse and identify
> packages that are not being updated or at lease fall into the orphan
> category. One common case is those packages installed (-1). I'd venture
> to guess from time to time that most gentoo users have packages
> installed that are not dependencies for any other packages. Often is it
> by accident or extreme manual cleansing events (like the recent ncurses
> episode) that folks stumble across these orphaned packages.   I just
> think a tool or option in an existing tool does/should cover that
> scenario. It is a routine need, imho.

That's exactly what depclean is for, to find any packages that are not
dependencies of the installed sets.

> That said are there any make.conf mods need to use sets like this,
> or just create the dir and and use your command line string?

That's all you do. Any file in /etc/portage/sets containing a list of
atoms is taken to be a set definition.

> I might not use it permanently the way you do, but I can see putting
> a collection of (-1) packages into a set, for organizational structure.
> With clustering now infecting my gentoo world, I'll need a master by
> architecture, logically organized collection of "sets" to cover the
> myriad of node set-ups. Each system will most likely have a different
> installation of these sets. And the cluster is now moving to a
> multi-arch setup with aarch64.

I use sets like that too. I have one called base that I installed at the
chroot stage of installation, containing various essential and useful
packages - such as portage-utils, conf-update and eix. Then sets called
desktop and laptop - sets can contain other sets so when installing my
new laptop I only have to "emerge -u @laptop".


-- 
Neil Bothwick

Energizer Bunny arrested, charged with battery :)

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

Re: [gentoo-user] Re: update problems

[Dale]

Alan McKinnon wrote:
> On 22/09/2015 17:55, James wrote:
>> Dale <rdalek1967 <at> gmail.com> writes:
>>
>>
>>>> I usually remember --oneshot but if I'm tired or distracted I
>>>> forget it. 
>>
>>> To avoid this, I added it to my make.conf.  When I *really* want to have
>>> something in the world file, I can either add it myself or use --select
>>> on the command line to add it.  Result, shouldn't be anything in the
>>> world file that shouldn't be there. 
>> OK, I'll try this. 
>> I'll add --oneshot to the EMERGE_DEFAULT_OPTS=  in make.conf.
>>
>> Works great.
>>
>>> I sometimes wonder why that isn't the default way.  I guess because it
>>> would confuse folks for a bit and because it has always been that way.  
>> One thing I see, is now you have a system that is full of pkg that do
>> not update normally. I guess I'm say if you install pakages with --oneshot,
>> they are not automatically updated, or are they? (discussion).
>>
>> 'emerge -uDNv world' is the most common form of update, probably, used
>> by gentoo users. So how to best ferret out those oneshot packages for
>> update; and that's if they should be updated....  semantics on that?
>
> I think you two have it backwards.
>
> The intended workflow is that if you emerge something, you know what it
> is, you don't have to make further decisions about it and you want it in
> world.
>
> @world, by definition, is the list of packages you want. That plus
> @system plus all deps constitutes the set of what should be on the
> system, anything you have not in that set is subject to depcleaning
>
> If you are not sure about some package, by all means emerge it with -1.
> Check it out, verify it, make sure it does what you want then get it in
> world with emerge -n. Why would you want to have stuff around for
> extended periods that is not in world?
>
> If you have a package that you no longer want (as you know what is in
> your world right), unmerge it with -C
>
> Don't make life difficult for yourself. It's MUCH easier to know what's
> in world than to try and remember what should be and isn't.
>
>
>


For me at least, this way works best.  Before I did it this way, if I
had to workaround a portage block or some other issue, I would forget to
add -1 and ended up with a world file full of stuff that shouldn't be
there.  By the way, this doesn't effect updating at all, at least it
doesn't for me. 

If say I emerge googleeath and I want to keep it installed and added to
world, I then emerge it with --select y on the command line and it gets
added to the world file.  Basically, if something gets added to the
world file, I took a extra step to make sure it got there.  It doesn't
get there by mistake. 

Since I've been doing it this way, I have not had a single thing added
to my world file that I didn't want to be there.  For me at least, it
works.  It's just to easy to forget to add that -1.  It's not hard at
all to remember to add --select y when needed tho.  If it was something
you were testing, --select  y -n works like a charm. 

For my way of thinking, I think having a extra step to add something to
the world file leads to a cleaner system.  I wouldn't set it on a new
install until I was doing installing all the things I do want tho. 
After I had my usual stuff installed, that -1 would be added. 

To each his own tho. 

Dale

:-)  :-) 

Re: [gentoo-user] Re: update problems

[Neil Bothwick]

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

On Sun, 20 Sep 2015 18:07:58 +0000 (UTC), James wrote:

> Yea, many of us forget the --oneshot option whilst admining about.....
> 
> This is a recurring theme. Didn't somebody post a scipt a while
> back to do this for you in one effort. Then you read the list result
> and decide which do remove from the world file?

If it gets that messed up, it's probably easier to remove the world file,
read the output from emerge -cp and then emerge -n the programs you need.


-- 
Neil Bothwick

It is impossible to fully enjoy procrastination
unless one has plenty of work to do.

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

[gentoo-user] Major site redesign, SEO, and 301 redirects

[Tanstaafl]

Hi all,

I am not a web (or SEO) guy, but I manage our DNS and have for a long time.

The boss has contracted with a web development company to do a full
redesign of our website.

Our website has hundreds of thousands of pages, and years of SEO behind
it. The guys who was her until recently was adamant that we must be very
carefl with the redesign so as not to totally break SEO, and possibly
getting blacklisted by Google.

The web developers are insisting that they need full access to our DNS
(hosted by DNSMadeEasy), and the only reason I can think of for this is
they plan on setting up HTTP redirects (DNSMadeEasy equivalent of a 301
redirect) for these pages - but hundreds of thousands of them?

Wouldn't this be better done at the web server level? Or am I just ignorant?

Would love to hear experiences (good and bad), and a recommendation for
what I should do.

thanks

Re: [gentoo-user] Major site redesign, SEO, and 301 redirects

[J. Roeleveld]

On 29 September 2015 22:00:58 CEST, Tanstaafl <tanstaafl@libertytrek.org> wrote:
>Hi all,
>
>I am not a web (or SEO) guy, but I manage our DNS and have for a long
>time.
>
>The boss has contracted with a web development company to do a full
>redesign of our website.

Good luck with that. Hope you found a good company. :)

>Our website has hundreds of thousands of pages, and years of SEO behind
>it. The guys who was her until recently was adamant that we must be
>very
>carefl with the redesign so as not to totally break SEO, and possibly
>getting blacklisted by Google.

I never did anything with SEO. Would a mistake with that really get a site blacklisted?

>The web developers are insisting that they need full access to our DNS
>(hosted by DNSMadeEasy), and the only reason I can think of for this is
>they plan on setting up HTTP redirects (DNSMadeEasy equivalent of a 301
>redirect) for these pages - but hundreds of thousands of them?

Redirects with DNS?
I can only think of adding subdomains (like about.example.com or similar)

>Wouldn't this be better done at the web server level? Or am I just
>ignorant?

Page redirects are, afaik, only possible with a webserver. They are part of the HTTP protocol. 

>Would love to hear experiences (good and bad), and a recommendation for
>what I should do.

I would ask them what they actually want to achieve. Don't forget that your email and all other services are dependent of the DNS settings.
I can't think of many companies allowing a supplier for a website full access to a different part of the infrastructure.

Most companies I deal with wouldn't even let the people responsible for the databases to reconfigure the storage for said database directly.

--
Joost 


-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: [gentoo-user] Major site redesign, SEO, and 301 redirects

[Alan McKinnon]

On 29/09/2015 22:19, J. Roeleveld wrote:
> On 29 September 2015 22:00:58 CEST, Tanstaafl <tanstaafl@libertytrek.org> wrote:
>> Hi all,
>>
>> I am not a web (or SEO) guy, but I manage our DNS and have for a long
>> time.
>>
>> The boss has contracted with a web development company to do a full
>> redesign of our website.
> 
> Good luck with that. Hope you found a good company. :)
> 
>> Our website has hundreds of thousands of pages, and years of SEO behind
>> it. The guys who was her until recently was adamant that we must be
>> very
>> carefl with the redesign so as not to totally break SEO, and possibly
>> getting blacklisted by Google.
> 
> I never did anything with SEO. Would a mistake with that really get a site blacklisted?
> 
>> The web developers are insisting that they need full access to our DNS
>> (hosted by DNSMadeEasy), and the only reason I can think of for this is
>> they plan on setting up HTTP redirects (DNSMadeEasy equivalent of a 301
>> redirect) for these pages - but hundreds of thousands of them?
> 
> Redirects with DNS?
> I can only think of adding subdomains (like about.example.com or similar)
> 
>> Wouldn't this be better done at the web server level? Or am I just
>> ignorant?
> 
> Page redirects are, afaik, only possible with a webserver. They are part of the HTTP protocol. 
> 
>> Would love to hear experiences (good and bad), and a recommendation for
>> what I should do.
> 
> I would ask them what they actually want to achieve. Don't forget that your email and all other services are dependent of the DNS settings.
> I can't think of many companies allowing a supplier for a website full access to a different part of the infrastructure.
> 
> Most companies I deal with wouldn't even let the people responsible for the databases to reconfigure the storage for said database directly.

I agree with Joost, needing access to all your DNS is off-the-wall. Any
changes they need done, and they will be few, can be given to you as a
support ticket for action just like everyone else gets to do.

I would also have them specify exactly in their proposal what they
intend to do, with full engineering. Any sane service provider will do
that in their tender, and yours looks like a rather big tender.

Lastly, get a second opinion of the changes they make. SEO tweaks can
very easily get you blacklisted on search engines and a lot of methods
out there are interpreted by Google as being dodgy.


-- 
Alan McKinnon
alan.mckinnon@gmail.com

[gentoo-user] Re: Major site redesign, SEO, and 301 redirects

[James]

Alan McKinnon <alan.mckinnon <at> gmail.com> writes:


> On 29/09/2015 22:19, J. Roeleveld wrote:
> > On 29 September 2015 22:00:58 CEST, Tanstaafl <tanstaafl <at>
libertytrek.org> wrote:

> > Most companies I deal with wouldn't even let the people responsible for
the databases to reconfigure the
> storage for said database directly.

> I agree with Joost, needing access to all your DNS is off-the-wall. Any
> changes they need done, and they will be few, can be given to you as a
> support ticket for action just like everyone else gets to do.

> I would also have them specify exactly in their proposal what they
> intend to do, with full engineering. Any sane service provider will do
> that in their tender, and yours looks like a rather big tender.

Why cannot they just ask you guys to make the DNS changes they need,
transient or permanent. That way you stay in the loop on what they are doing
and participate with the upgrade.


Another point of concern. When radically changing infrastructure like this,
why not just do the entire thing under a new DNS and have both online for a
while, until the new site if vetted and the actual real bugs worked out?

Also, your company should force this contractor to take a large liability
policy, in the name of your company, should things go really fubar....

caveat emptor!


hth,
James

Re: [gentoo-user] Re: Major site redesign, SEO, and 301 redirects

[Tanstaafl]

On 9/29/2015 8:02 PM, James <wireless@tampabay.rr.com> wrote:
> Another point of concern. When radically changing infrastructure like this,
> why not just do the entire thing under a new DNS and have both online for a
> while, until the new site if vetted and the actual real bugs worked out?

Well... not sure how that would work, since we are not changing domain
names, only redesigning the site.

What I would do if I was a web dev is just set up a test site, then set
up the development site for the customer under a subdirectory, ie:

https://mycustomtestingsite.com/customer-a/index.html

> Also, your company should force this contractor to take a large liability
> policy, in the name of your company, should things go really fubar....

Interesting idea. Not sure how well it would go over.

Is that a common thing in the industry for large corporate redesigns
like this?

Thanks James

Re: [gentoo-user] Re: Major site redesign, SEO, and 301 redirects

[Alan McKinnon]

On 01/10/2015 13:22, Tanstaafl wrote:
> On 9/29/2015 8:02 PM, James <wireless@tampabay.rr.com> wrote:
>> Another point of concern. When radically changing infrastructure like this,
>> why not just do the entire thing under a new DNS and have both online for a
>> while, until the new site if vetted and the actual real bugs worked out?
> 
> Well... not sure how that would work, since we are not changing domain
> names, only redesigning the site.
> 
> What I would do if I was a web dev is just set up a test site, then set
> up the development site for the customer under a subdirectory, ie:
> 
> https://mycustomtestingsite.com/customer-a/index.html

Yes, that's the sane way

>> Also, your company should force this contractor to take a large liability
>> policy, in the name of your company, should things go really fubar....
> 
> Interesting idea. Not sure how well it would go over.
> 
> Is that a common thing in the industry for large corporate redesigns
> like this?

Oh yes, most definitely if the contractor is being paid to provide an
entire solution end-to-end.

Not so much if they are just providing a small definite component of a
larger system that you control and direct.


-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] Major site redesign, SEO, and 301 redirects

[Alan McKinnon]

On 29/09/2015 22:00, Tanstaafl wrote:
> Hi all,
> 
> I am not a web (or SEO) guy, but I manage our DNS and have for a long time.
> 
> The boss has contracted with a web development company to do a full
> redesign of our website.
> 
> Our website has hundreds of thousands of pages, and years of SEO behind
> it. The guys who was her until recently was adamant that we must be very
> carefl with the redesign so as not to totally break SEO, and possibly
> getting blacklisted by Google.
> 
> The web developers are insisting that they need full access to our DNS
> (hosted by DNSMadeEasy), and the only reason I can think of for this is
> they plan on setting up HTTP redirects (DNSMadeEasy equivalent of a 301
> redirect) for these pages - but hundreds of thousands of them?

I've been thinking about this some more.

We all assumed "full access" means "so we can change stuff". Maybe it
really means they want to see what's in "dig axfr" (a zone transfer)
which they normally can't see. There are TXT records in DNS that they
might be interested in.

It would be wise to clarify with the devs exactly what it is they are
looking for.

And overall, in your shoes I would be firm, adamant and above all polite
and say that infrastructure changes go through you and you alone, and
must be vetted by you with full transparency.



> 
> Wouldn't this be better done at the web server level? Or am I just ignorant?
> 
> Would love to hear experiences (good and bad), and a recommendation for
> what I should do.
> 
> thanks
> 


-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] Major site redesign, SEO, and 301 redirects

[Mick]

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

On Wednesday 30 Sep 2015 01:28:51 Alan McKinnon wrote:
> On 29/09/2015 22:00, Tanstaafl wrote:
> > Hi all,
> > 
> > I am not a web (or SEO) guy, but I manage our DNS and have for a long
> > time.
> > 
> > The boss has contracted with a web development company to do a full
> > redesign of our website.
> > 
> > Our website has hundreds of thousands of pages, and years of SEO behind
> > it. The guys who was her until recently was adamant that we must be very
> > carefl with the redesign so as not to totally break SEO, and possibly
> > getting blacklisted by Google.
> > 
> > The web developers are insisting that they need full access to our DNS
> > (hosted by DNSMadeEasy), and the only reason I can think of for this is
> > they plan on setting up HTTP redirects (DNSMadeEasy equivalent of a 301
> > redirect) for these pages - but hundreds of thousands of them?
> 
> I've been thinking about this some more.
> 
> We all assumed "full access" means "so we can change stuff". Maybe it
> really means they want to see what's in "dig axfr" (a zone transfer)
> which they normally can't see. There are TXT records in DNS that they
> might be interested in.
> 
> It would be wise to clarify with the devs exactly what it is they are
> looking for.
> 
> And overall, in your shoes I would be firm, adamant and above all polite
> and say that infrastructure changes go through you and you alone, and
> must be vetted by you with full transparency.
> 
> > Wouldn't this be better done at the web server level? Or am I just
> > ignorant?
> > 
> > Would love to hear experiences (good and bad), and a recommendation for
> > what I should do.
> > 
> > thanks

I couldn't agree more with all the warnings that have been posted.  However, 
it may simply be that they want to build a new website and they want to 
redirect your DNS from your currently hosted server to theirs.  Are they 
offering SaaS, or will you be hosting the new website on prem?  In any case, 
they could just ask you to do this, if you agree.  Given that "possession is 
nine-tenths of the law" I would not let them anywhere near your DNS records - 
period.

With regards to being blacklisted by Google, you have to be careful indeed.  
Google will blacklist bad code and malicious code.  If your code is clean, you 
don't fill your metadata with repetitive cr*ap and your topic is not faced 
with a competition of millions selling exactly the same undifferentiated 
product, then you should be OK in organic listing rankings.  Having mirrored 
websites on different DNS' will also blacklist you, although DNS or http 
redirects are of course legit.

A lot of so called SEO companies are not actually streamlining the content and 
metadata, but exploiting paid-for Google Ads and in a non-transparent way to 
milk the customer, on top of the Google charges.  Most of these companies set 
up Google Ads once and rarely if ever come back to to tune it.  I couldn't 
care to list the number of websites we switched off Google Ads and saw no 
discernible different in the rankings.

BTW, although SEO is not rocket science its not something you would leave to 
your marketing people alone, or for that matter to your coding people alone.  
You need both.  
-- 
Regards,
Mick

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

Re: [gentoo-user] Major site redesign, SEO, and 301 redirects

[Tanstaafl]

On 9/30/2015 3:36 AM, Mick <michaelkintzios@gmail.com> wrote:
> I couldn't agree more with all the warnings that have been posted.  However, 
> it may simply be that they want to build a new website and they want to 
> redirect your DNS from your currently hosted server to theirs.

You mean change the DNS servers at the Domain Registrar?

That would be even worse - they would need to completely reproduce
everything that is in there prior to transferring it, and then our DNS
is no longer ours.

> Are they offering SaaS, or will you be hosting the new website on
> prem?

That is one of my questions. Currently the site is hosted at Rackspace.

> In any case, they could just ask you to do this, if you agree. Given
> that "possession is nine-tenths of the law" I would not let them
> anywhere near your DNS records - period.

Hmmm... above it sounded like  you were ok with their desire to
'redirect our DNS from our currently hosted server to theirs'. Did I
misunderstand?

> With regards to being blacklisted by Google, you have to be careful indeed.  
> Google will blacklist bad code and malicious code.

At this point I'm more worried about bad links/hundreds of thousand
pages suddenly giving 404 errors, etc...

Re: [gentoo-user] Major site redesign, SEO, and 301 redirects

[Tanstaafl]

Thanks Alan (and everyone else),

One important follow-up below...

On 9/29/2015 8:28 PM, Alan McKinnon <alan.mckinnon@gmail.com> wrote:
> It would be wise to clarify with the devs exactly what it is they are
> looking for.

That is the purpose of my upcoming phone call with him.

> And overall, in your shoes I would be firm, adamant and above all polite
> and say that infrastructure changes go through you and you alone, and
> must be vetted by you with full transparency.

That is what I've been doing so far, but I think the boss is getting
close to just saying 'give it to them'...

But - no one has addressed my main question...

I understand that 301 redirects are performed by web servers only, you
can't really do these in DNS. However, some Managed DNS providers -
DNSMadeEasy included - offer this ability as a service. DNSMadeEasy
calls  them 'http redirects', and the actual redirect is accomplished by
one of their own web servers they have set up to handle these.

Is it 'normal' to do these 301 redirects at the DNS level like that? I
would think they should be using the current web server hosting the
current site to start doing the redirects as they get the new landing
pages done? Apache does this using a .htaccess file (if I'm interpreting
my googling responses correctly).

And now that I worded it that way - how would they do that exactly?
Would the proper method be to redirect it to a new test domain, ie:

www.example.com/page1.htm >> www.new-example.com/newpage1.htm ?

Or save the new page on the old server, then do:

www.example.com/page1.htm >> www.example.com/newpage1.htm ?

Now I'm confusing myself...

Re: [gentoo-user] Major site redesign, SEO, and 301 redirects

[Alan McKinnon]

On 01/10/2015 13:35, Tanstaafl wrote:
> Thanks Alan (and everyone else),
> 
> One important follow-up below...
> 
> On 9/29/2015 8:28 PM, Alan McKinnon <alan.mckinnon@gmail.com> wrote:
>> It would be wise to clarify with the devs exactly what it is they are
>> looking for.
> 
> That is the purpose of my upcoming phone call with him.
> 
>> And overall, in your shoes I would be firm, adamant and above all polite
>> and say that infrastructure changes go through you and you alone, and
>> must be vetted by you with full transparency.
> 
> That is what I've been doing so far, but I think the boss is getting
> close to just saying 'give it to them'...

Depending on how senior you are in the place, as technical guy you have
a duty to perform diligence. Persist.

> 
> But - no one has addressed my main question...
> 
> I understand that 301 redirects are performed by web servers only, you
> can't really do these in DNS. However, some Managed DNS providers -
> DNSMadeEasy included - offer this ability as a service. DNSMadeEasy
> calls  them 'http redirects', and the actual redirect is accomplished by
> one of their own web servers they have set up to handle these.

Information is still sparse, so I'm having to fill in the blanks a lot.
Here's what I imagine is probably happening:

The only useful thing you can get out of DNS for an HTTP request is an A
record for an IP address.

Say you are example.com and do your own DNS; www.example.com is 1.2.3.4.
A SaaS provider can control your DNS and they set the TTL on that A
record very low so (like DynDNS does) they can point it at their web
servers.

A request comes in for http://www.example.com/index.html, and your DNS
cache needs to query it. The provider's DNS returns 2.3.4.5 which is the
provider's front end web server. That web server figures out the address
is your's, and issues a 301 to the user, which takes them to the
production web server with the real site on it.

Providers do this a lot so they can load balance web sites, redirect
users to local nearby web servers and other optimizations. The downside
is they need to control your DNS.

Me, personally I would never allow that, not for the entire domain. I
would rather delegate the specific address they want to control
(www.example.com) and let them tweak that all day if they like.

> Is it 'normal' to do these 301 redirects at the DNS level like that? I
> would think they should be using the current web server hosting the
> current site to start doing the redirects as they get the new landing
> pages done?

Depends what their business model is. If they deliver the full service,
they'd have to do something like I described above for it to work.

This is assuming the contractor is a full SaaS provider and not only a
web-site developement company

> Apache does this using a .htaccess file (if I'm interpreting
> my googling responses correctly).

An .htaccess file is nothing special, all it is is a config file that
can contain whatever directives are allowed in httpd.conf but applies
only to the directive .htaccess is in. Everything in .htaccess is a
valid directive that can go in httpd.conf, but not necessarily the other
way round. They are especially useful for shared hosting where you want
your customers to be able to tweak specific directives for their sites
and you can't give them access to httpd.conf and really can't be
bothered doing it for them for every requested change :-)

So when google gives a result saying "do it in .htaccess", that's the
internetz being meaningless. What it really means is "configure apache
to do a redirect for URLs that look like so"


> And now that I worded it that way - how would they do that exactly?
> Would the proper method be to redirect it to a new test domain, ie:
> 
> www.example.com/page1.htm >> www.new-example.com/newpage1.htm ?
> 
> Or save the new page on the old server, then do:
> 
> www.example.com/page1.htm >> www.example.com/newpage1.htm ?
> 
> Now I'm confusing myself...


It can get confusing. Best to ask them directly what they intend to do.
We can presume all day and never figure it out.


-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] Major site redesign, SEO, and 301 redirects

[Tanstaafl]

Thanks to Alan and the others for the responses...

The main problem is this project is being managed by a non-tech manager
who apparently thinks they know a lot more than they do, and the Boss is
technically challenged, so it is easy for someone to convince him of
almost anything (like, he should delegate this to a non-tech person and
not involve his one tech guy)...

One reason he sometimes doesn't involve me until things get to this
point is because I tend to be a 'wet blanket', ruining bright shiny
sales pitches with injections of reality. You'd think he'd have learned
by now. The last time, about 5 years ago, the person who managed the
project (different person) didn't get ownership of the source code in
the contract, so we didn't get all of the source files for the Flash
junk they created, then when we wanted to make some changes to the text
embedded in  the Flash, I had to ask them for the source files, and
they wanted a bunch of money. Unbelievable.

We'll see how the dev(s) respond to my questions, but I may come back
here with more info and more advice if I need it.

Thanks again to all, it has been a big help!

On 10/1/2015 7:58 AM, Alan McKinnon <alan.mckinnon@gmail.com> wrote:
> On 01/10/2015 13:35, Tanstaafl wrote:
>> Thanks Alan (and everyone else),
>>
>> One important follow-up below...
>>
>> On 9/29/2015 8:28 PM, Alan McKinnon <alan.mckinnon@gmail.com> wrote:
>>> It would be wise to clarify with the devs exactly what it is they are
>>> looking for.
>>
>> That is the purpose of my upcoming phone call with him.
>>
>>> And overall, in your shoes I would be firm, adamant and above all polite
>>> and say that infrastructure changes go through you and you alone, and
>>> must be vetted by you with full transparency.
>>
>> That is what I've been doing so far, but I think the boss is getting
>> close to just saying 'give it to them'...
> 
> Depending on how senior you are in the place, as technical guy you have
> a duty to perform diligence. Persist.
> 
>>
>> But - no one has addressed my main question...
>>
>> I understand that 301 redirects are performed by web servers only, you
>> can't really do these in DNS. However, some Managed DNS providers -
>> DNSMadeEasy included - offer this ability as a service. DNSMadeEasy
>> calls  them 'http redirects', and the actual redirect is accomplished by
>> one of their own web servers they have set up to handle these.
> 
> Information is still sparse, so I'm having to fill in the blanks a lot.
> Here's what I imagine is probably happening:
> 
> The only useful thing you can get out of DNS for an HTTP request is an A
> record for an IP address.
> 
> Say you are example.com and do your own DNS; www.example.com is 1.2.3.4.
> A SaaS provider can control your DNS and they set the TTL on that A
> record very low so (like DynDNS does) they can point it at their web
> servers.
> 
> A request comes in for http://www.example.com/index.html, and your DNS
> cache needs to query it. The provider's DNS returns 2.3.4.5 which is the
> provider's front end web server. That web server figures out the address
> is your's, and issues a 301 to the user, which takes them to the
> production web server with the real site on it.
> 
> Providers do this a lot so they can load balance web sites, redirect
> users to local nearby web servers and other optimizations. The downside
> is they need to control your DNS.
> 
> Me, personally I would never allow that, not for the entire domain. I
> would rather delegate the specific address they want to control
> (www.example.com) and let them tweak that all day if they like.
> 
>> Is it 'normal' to do these 301 redirects at the DNS level like that? I
>> would think they should be using the current web server hosting the
>> current site to start doing the redirects as they get the new landing
>> pages done?
> 
> Depends what their business model is. If they deliver the full service,
> they'd have to do something like I described above for it to work.
> 
> This is assuming the contractor is a full SaaS provider and not only a
> web-site developement company
> 
>> Apache does this using a .htaccess file (if I'm interpreting
>> my googling responses correctly).
> 
> An .htaccess file is nothing special, all it is is a config file that
> can contain whatever directives are allowed in httpd.conf but applies
> only to the directive .htaccess is in. Everything in .htaccess is a
> valid directive that can go in httpd.conf, but not necessarily the other
> way round. They are especially useful for shared hosting where you want
> your customers to be able to tweak specific directives for their sites
> and you can't give them access to httpd.conf and really can't be
> bothered doing it for them for every requested change :-)
> 
> So when google gives a result saying "do it in .htaccess", that's the
> internetz being meaningless. What it really means is "configure apache
> to do a redirect for URLs that look like so"
> 
> 
>> And now that I worded it that way - how would they do that exactly?
>> Would the proper method be to redirect it to a new test domain, ie:
>>
>> www.example.com/page1.htm >> www.new-example.com/newpage1.htm ?
>>
>> Or save the new page on the old server, then do:
>>
>> www.example.com/page1.htm >> www.example.com/newpage1.htm ?
>>
>> Now I'm confusing myself...
> 
> 
> It can get confusing. Best to ask them directly what they intend to do.
> We can presume all day and never figure it out.
> 
> 

Re: [gentoo-user] Major site redesign, SEO, and 301 redirects

[Mick]

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

On Thursday 01 Oct 2015 13:21:48 Tanstaafl wrote:
> Thanks to Alan and the others for the responses...
> 
> The main problem is this project is being managed by a non-tech manager
> who apparently thinks they know a lot more than they do, and the Boss is
> technically challenged, so it is easy for someone to convince him of
> almost anything (like, he should delegate this to a non-tech person and
> not involve his one tech guy)...

This is uncanny!  Do you work in the same company as I?  O_o


> One reason he sometimes doesn't involve me until things get to this
> point is because I tend to be a 'wet blanket', ruining bright shiny
> sales pitches with injections of reality. You'd think he'd have learned
> by now. The last time, about 5 years ago, the person who managed the
> project (different person) didn't get ownership of the source code in
> the contract, so we didn't get all of the source files for the Flash
> junk they created, then when we wanted to make some changes to the text
> embedded in  the Flash, I had to ask them for the source files, and
> they wanted a bunch of money. Unbelievable.
> 
> We'll see how the dev(s) respond to my questions, but I may come back
> here with more info and more advice if I need it.

I bet they will ask to point the DNS record for your domain to their own (or 
Rackspace's) nameservers instead of your current nameservers.  However, as it 
has been commented already, the sane thing to do is develop the whole new 
website on their own subdomain with an appropriate robots.txt file, to stop 
spiders indexing it at this stage.  Once it is ready for UAT and assuming the 
boss approves it, they can ask *you* to point the DNS record to their 
Rackspace nameservers.

This way *you* can also point it back to a holding page/mirror/new site, when 
they no longer serve your needs.


> Thanks again to all, it has been a big help!

PS.  I hope someone will show them the door if they suggest designing a new 
Flash based web interface ...
-- 
Regards,
Mick

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

Re: [gentoo-user] Major site redesign, SEO, and 301 redirects

[Walter Dnes]

On Thu, Oct 01, 2015 at 03:35:48PM +0100, Mick wrote
> 
> PS.  I hope someone will show them the door if they suggest designing
> a new Flash based web interface ...

  Especially true given that Ipads/Iphones do not support Flash.  Another
major problem is websites that parse the user agent, and assume that any
browser they don't recognize is a mobile device.  It's a standing joke
amongst geeks... see https://xkcd.com/869/ and https://xkcd.com/1174/
Back in the day when "smartphones" only had 320x240 pixel screens, a
separate mobile site may have been necessary.  But not today with
pinch+zoom and smartphones/tablets with higher pixel counts than many
notebooks.  And with the idiots at Mozilla going off the deep end, there
are multiple forks of Firefox out there (Seamonkey, Palemoon, etc), by
people who are disgusted with Firefox's insanity.  A company that kicks
those browsers off their main website to a mobile site, or demands they
download an "app", will lose customers.

-- 
Walter Dnes <waltdnes@waltdnes.org>
I don't run "desktop environments"; I run useful applications

Re: [gentoo-user] Major site redesign, SEO, and 301 redirects

[Mick]

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

On Friday 02 Oct 2015 00:00:08 Walter Dnes wrote:
> On Thu, Oct 01, 2015 at 03:35:48PM +0100, Mick wrote
> 
> > PS.  I hope someone will show them the door if they suggest designing
> > a new Flash based web interface ...
> 
>   Especially true given that Ipads/Iphones do not support Flash.  Another
> major problem is websites that parse the user agent, and assume that any
> browser they don't recognize is a mobile device.  It's a standing joke
> amongst geeks... see https://xkcd.com/869/ and https://xkcd.com/1174/
> Back in the day when "smartphones" only had 320x240 pixel screens, a
> separate mobile site may have been necessary.  

I think the reason was that at the time we did not have CSS3 and responsive 
web design was not available for the majority of CMS themes.  Many web 
designers were providing a separate generic style sheet for mobile browsers.  
If for some reason the browser was not able to process the desktop style sheet 
it would drop to the mobile style sheet.  I am sure I have seen this happening 
with Opera.  With responsive design it is left to the device to resize the 
layout elements, which is a relief for the web developers - they now only have 
to sniff MSIE8 and friends and send to them a completely different (crippled) 
layout that they are able to render.  :-D

-- 
Regards,
Mick

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