Re: [gentoo-user] Do we have any Blender build experts in the house?

[Andrew Lowe]

On 05/29/16 10:46, J. García wrote:

El sáb, 28-05-2016 a las 17:26 -0600, J. García escribió:


BTW, eix won't help you here, I tried it, so the next step is to find
what provides the symbol 'Imf_2_1::Header::view', after some searches
with find and then google, I arrived at opencv(though not 100% sure),
so you might need to rebuild that and make sure(read the log) g++ is
being called with std=c++11. tracking this sort of stuff might be
tricky.

I was left with the doubt if opencv was the package causing trouble,
and it is not, so I searched a bit more in depth, and I have found the
library you need to rebuild, it is libIlmImf.so, and this time I'm
sure.

Looking for the package:

$ qfile /usr/lib64/libIlmImf.so
media-libs/openexr (/usr/lib64/libIlmImf.so)

Looking for the symbol:

$ readelf -s /usr/lib64/libIlmImf.so  | grep   '.*Header.*view.*'
  1617: 0004a35025 FUNCGLOBAL DEFAULT   10
_ZNK7Imf_2_16Header4viewB
  2248: 00049e6025 FUNCGLOBAL DEFAULT   10
_ZN7Imf_2_16Header4viewB5

So you need to: emerge --oneshot media-libs/openexr


	I kicked off a revdep-rebuild between your previous email and this one. 
I got 280 packages that needed a rebuild so I've let it go and in turn 
I'll rerun the Blender install.


Fingers crossed,
Andrew

Re: [gentoo-user] Re: [OT] How to be a penguin.

[Daniel Frey]

On 05/28/2016 06:17 PM, Gregory Woodbury wrote:
> Furthermore, the current portage doesn't require the revdep-rebuild step
> because
> of the @preserved-rebuild set creation.

I beg to differ, portage still misses stuff more often than you think. I
always run revdep-rebuild after an emerge.

Dan

Re: [gentoo-user] downloading remote eix data file

[Thanasis]

On 05/29/2016 01:16 AM, Andrew Savchenko wrote:


   eix-remote update

works fine here, http://gpo.zugaina.org/eix_cache/eix-cache.tbz2
is also available via any tool (e.g. wget).

Maybe it was a temporary server glitch or some provider issues.

However,
   eix-remote update2
fails for me for a long time (over a year, I guess).

Best regards,
Andrew Savchenko



This time I tried, it worked for me too.
I really don't know what was changed though.
Thanks :)

Re: [gentoo-user] Do we have any Blender build experts in the house?

[J.]

El sáb, 28-05-2016 a las 17:26 -0600, J. García escribió:
> 
> BTW, eix won't help you here, I tried it, so the next step is to find
> what provides the symbol 'Imf_2_1::Header::view', after some searches
> with find and then google, I arrived at opencv(though not 100% sure),
> so you might need to rebuild that and make sure(read the log) g++ is
> being called with std=c++11. tracking this sort of stuff might be
> tricky.
I was left with the doubt if opencv was the package causing trouble,
and it is not, so I searched a bit more in depth, and I have found the
library you need to rebuild, it is libIlmImf.so, and this time I'm
sure.

Looking for the package:

$ qfile /usr/lib64/libIlmImf.so 
media-libs/openexr (/usr/lib64/libIlmImf.so)

Looking for the symbol: 

$ readelf -s /usr/lib64/libIlmImf.so  | grep   '.*Header.*view.*'
  1617: 0004a35025 FUNCGLOBAL DEFAULT   10
_ZNK7Imf_2_16Header4viewB
  2248: 00049e6025 FUNCGLOBAL DEFAULT   10
_ZN7Imf_2_16Header4viewB5

So you need to: emerge --oneshot media-libs/openexr

Re: [gentoo-user] Re: [OT] How to be a penguin.

[Gregory Woodbury]

On Sat, May 28, 2016 at 4:53 PM, Neil Bothwick  wrote:

> On Sat, 28 May 2016 21:54:09 +0200, Volker Armin Hemmann wrote:
>
> > thanks a lot. My eyes are bleeding.
>
> Serves you right for being daft enough to read it again!
>
> I'd suggest that Alan RTFM for the commands he uses, but that would be a
> waste of keystrokes.
>
>
I have to agree with ng0

WOW!

Alan just wants to start it and walk away, as if Gentoo was a binary
distribution
that handles it all upstream.  He doesn't want to take the time to review
what
emerge is proposing and see if changes are needed first.

Hey Alan: Gentoo is NOT a start an update and walk away setup. Some human
mind needs to be involved if troubles arise.  Also, read make.conf(5) and
set up
the various variables correctly; PYTHON_SINGLE_TARGET should only have
one python version set.

Furthermore, the current portage doesn't require the revdep-rebuild step
because
of the @preserved-rebuild set creation.

In any case, to try and force things through without looking at what
problems are occuring
is just (excuse my language) batshit crazy stupid.


I use my update generator script so make the emerge command(s) just so
I can preview the packages and modify the sequences or leave out some
updates
if i need/want to do so. (E.g. I may want to defer a chromium or
libreoffice update
to after other updates are done and/or set them to occur with a lower
niceness or
an ionice idle class.)

-- 
G.Wolfe Woodbury
redwo...@gmail.com

Re: [gentoo-user] Do we have any Blender build experts in the house?

[J.]

El dom, 29-05-2016 a las 01:58 +0800, Andrew Lowe escribió:
> Hi all,
>   I'm attempting to build Blender, 2,7,6 but am running into a
> problem 
> during linking. I am getting a series of errors referring to an, for 
> example:
> 
> unresolved reference to 'Imf_2_1::Header::view[abi:cxx11]() const
> 
I've hit this sort of errors a few times(libreoffice mainly), no need
for blender experts.
The problem is your when linking the libraries/binaries, it is trying
to link code compiled with -std=c++11 and some library compiled with an
older standard,and thus it the linker cannot find binary code that
maches what your newly compiled programs wants. there was a news item
about this, you should read/revisit it, named:
  Title GCC 5 Defaults to the New C++11 ABI
  AuthorMike Frysinger 
  Posted2015-10-22
  Revision  2

The proposed solution is:
(quote from the news item)
For gentoolkit-0.3.1 or higher:
# revdep-rebuild --library 'libstdc++.so.6' -- --exclude gcc

For previous versions of gentoolkit:
# revdep-rebuild --library 'libstdc\+\+\.so\.6' -- --exclude gcc

But I've encountered some packages that weren't rebuild with that, so
what I do is: search for the library that needs rebuild(hint e.g. for
your case,  eix imf) and then emerge -av1 that library, and try again
rebuilding the package I wanted in the first place(blender for you). I
say rebuild but I really just manually call ´ebuild $PORDTDIR/cat/pkg-
ver' install as the portage user, and then package, and install it as a
binary at the end, but how to do this is out of the scope of the
interest of this thread.
BTW, eix won't help you here, I tried it, so the next step is to find
what provides the symbol 'Imf_2_1::Header::view', after some searches
with find and then google, I arrived at opencv(though not 100% sure),
so you might need to rebuild that and make sure(read the log) g++ is
being called with std=c++11. tracking this sort of stuff might be
tricky.

Re: [gentoo-user] downloading remote eix data file

[Andrew Savchenko]

On Mon, 23 May 2016 15:57:35 +0300 Thanasis wrote:
> On 05/23/2016 03:39 PM, Neil Bothwick wrote:
> 
> >
> > The other question is: why are you using wget when eix already has the
> > facility to download and import this file built in.
> >
> >
> Hmmm, I suspect, that *should* be the reason why it fails for me ... 
> However, I don't remember having specified the use *wget* somewhere ...
> 
> /etc/eixrc/00-eixrc has everything commented out...
> 
> So, I run the following to get a log and here is how it goes ...
> --
> eix-remote update 2>&1 |tee log

  eix-remote update

works fine here, http://gpo.zugaina.org/eix_cache/eix-cache.tbz2
is also available via any tool (e.g. wget).

Maybe it was a temporary server glitch or some provider issues.

However,
  eix-remote update2
fails for me for a long time (over a year, I guess).

Best regards,
Andrew Savchenko


pgp8WzywMzqRm.pgp
Description: PGP signature

Re: [gentoo-user] what goes on with duplicity?

[Andrew Savchenko]

On Sun, 22 May 2016 03:47:43 -0400 cov...@ccs.covici.com wrote:
> Hi.  I  have been using (on advise from someone here),
> app-backup/duplicity from the rinaldus overlay, but in the latest update
> which I have postponed, gentoo has updated to the same version as the
> overlay, but has chosen to have a mandatory use flag of -azure which
> would cause my backups not to work, as I am updating to azure storage.
> How can I prevent this from happening?  The versions are the same, so is
> there a way to mask this off?

There is no azure USE flag in duplicity from the main tree, the
"(-azure)" notation you see means that flag is no longer here in
the new version to install.



> Note that I had to patch the back end for azure with something to fix a
> typo, so I wonder if this has something to do with the  problem?

No, it isn't. Your problem comes from a way how you installed
duplicity from rinaldus overlay. How this overlay is enabled? What
priority have you set?

What you basically need is to prefer overlay version over version
from the tree.

Eix shows me 6 overlays with this ebuild, but there is no
"rinaldus" on the list, it isn't in layman either. You should have
a record of your overlay somewhere in
  /etc/portage/repos.conf/*.conf
set
  priority = 50
for this overlay, so it will have precedence over the main
portage tree.

Another way to solve this issue is to mask duplicity only from
gentoo tree, add to your /etc/portage/package.mask:

  app-backup/duplicity::gentoo

This way it will be installed only from overlay(s), even if in-tree
version is newer.

Of course, the best solution is to file bug for
app-backup/duplicity and ask maintainers to add azure USE flag.

Best regards,
Andrew Savchenko


pgpTDHGbaRW2N.pgp
Description: PGP signature

Re: [gentoo-user] Re: [OT] How to be a penguin.

[Neil Bothwick]

On Sat, 28 May 2016 21:54:09 +0200, Volker Armin Hemmann wrote:

> thanks a lot. My eyes are bleeding.

Serves you right for being daft enough to read it again!

I'd suggest that Alan RTFM for the commands he uses, but that would be a
waste of keystrokes.


-- 
Neil Bothwick

One-seventh of life is spent on Monday.


pgpH9rxHizmdr.pgp
Description: OpenPGP digital signature

Re: [gentoo-user] Re: [OT] How to be a penguin.

[ng0]

On 2016-05-28(01:49:22PM-0500), Dale wrote:
> Dale wrote:
> > Gregory Woodbury wrote:
> >> Has Alan ever posted his "jackhammer" script for some experts to look
> >> at?
> >>
> >> I get by really well with a small script that reads the eix outputs,
> >> finds the "[U]"
> >> tagged packages, and then runs "emerge -u1" on that list.
> >>
> >> Doing anything more than that will be a cause of pain and suffering.
> >>
> >> If a package needs patches for something special, it is better to
> >> make a local
> >> repository with modified ebuilds and distfiles, rather than try to
> >> force the gentoo repo
> >> into your own mess. I do this for a few tthings that Gentoo doesn't
> >> ship. Portage
> >> is actuallly quite flexible underneath, itt just takes a bit of learning.
> >>
> >> --
> >> G.Wolfe Woodbury
> >> redwo...@gmail.com 
> >
> >
> > He did a while back.  Some very experienced Gentoo users here
> > explained to him that his script was the problem.  From memory which
> > isn't all that good, it syncs the tree which is fine.  After that, it
> > gets bad.  I think it did the updates and then repeated that several
> > times within the script.  That is done without him looking to see if
> > anything needs to be changed, USE flags etc, or if something shouldn't
> > be updated at all.  I'm pretty sure that it then deletes all the logs
> > of what was done, which means anything broken is broke and no record
> > of what or even why.
> >
> > Yes, some things can be done with a script.  However, there needs to
> > be a point in there where the user, the real brain of what is wanted,
> > looks at the list of what will be updated.  Only a human can look and
> > see if there is USE flag changes or other issues that need a config
> > file to be edited.   Alan skips all that.
> >
> > If you want, I can go dig it out and post it.  I should have a copy of
> > the script in my local email.  I keep them for like 2 years or
> > something then it deletes the old stuff.  I'm not sure if you will
> > laugh your head off or cry tho.
> >
> > Dale
> >
> > :-)  :-)
>
>
> What the heck.  I went back and found it.  It only took a few minutes.
> The rest of this message is the email where he has his script.  I'll do
> my usual sign off at the bottom, rest is his post.   For those who have
> already seen it, you might want to skip past the rest.  No need
> torturing yourself again.
>
>
> > I use two scripts for all emerge use, the goal is to run one command and
> > then walk away:
> >
> > Standard general update script:
> > ###
> > tortoise ~ # cat sysupdate
> >
> > #they must have moved or removed the logs, might have to track them down
> > again...
> > #rm /var/log/emerge*
> >
> > # cache /usr/portage
> > echo "caching /usr/portage.  This will take a long time."
> > time ls -R /usr/portage > /dev/null
> >
> > emerge --sync
> > layman --sync ALL
> >
> > emerge --update --verbose portage
> > emerge --update --newuse --deep --with-bdeps=y system --keep-going
> > emerge --update --newuse --deep --with-bdeps=y world --keep-going
> >
> > rm -f /var/cache/revdep-rebuild/*.rr
> > revdep-rebuild
> > emerge --skipfirst --resume
> > emerge --skipfirst --resume
> > etc-update
> > eclean-dist
> > 
> >
> > The eclean line was added just a few days ago from this thread...
> >
> > This one is intended to be a nice gentle update script.
> > It caches the portage tree, then syncs everything, then updates
> > everything starting with critical system packages, then all world
> > packages...
> >
> > Then it cleans stuff up, it jcakhammers the revdep-rebuild but not too
> > hard
> >
> >
> > This next script is what I use when emerge starts giving me shit:
> >
> > ##
> > tortoise ~ # cat keepgoing
> > emerge --update --newuse --deep --with-bdeps=y system
> > emerge --skipfirst --resume --nodeps
> > emerge --skipfirst --resume --nodeps
> > emerge --skipfirst --resume --nodeps
> >
> > emerge --update --newuse --deep --with-bdeps=y world
> > emerge --skipfirst --resume --nodeps
> > emerge --skipfirst --resume --nodeps
> > emerge --skipfirst --resume --nodeps
> > emerge --skipfirst --resume --nodeps
> > emerge --skipfirst --resume --nodeps
> > emerge --skipfirst --resume --nodeps
> > emerge --skipfirst --resume --nodeps
> > emerge --skipfirst --resume --nodeps
> > emerge --skipfirst --resume --nodeps
> > emerge --skipfirst --resume --nodeps
> >
> > rm /var/cache/revdep-rebuild/*.rr
> > revdep-rebuild
> > emerge --skipfirst --resume --nodeps
> > emerge --skipfirst --resume --nodeps
> > emerge --skipfirst --resume --nodeps
> > emerge --skipfirst --resume --nodeps
> >
> > etc-update
> > ###
> >
> > It's basically the same as the working section of the above but instead
> > of letting emerge do it's thing, it jackhammers that bitch as hard as
> > possible to get as much updated as possible, but it requires emerge to
> > do something and not error out for no 

Re: [gentoo-user] Re: [OT] How to be a penguin.

[Dale]

Volker Armin Hemmann wrote:
> Am 28.05.2016 um 20:49 schrieb Dale:
>> Dale wrote:
>>
>> What the heck.  I went back and found it.  It only took a few
>> minutes.  The rest of this message is the email where he has his
>> script.  I'll do my usual sign off at the bottom, rest is his post.  
>> For those who have already seen it, you might want to skip past the
>> rest.  No need torturing yourself again. 
>>
>> <<>>
>> Dale
>>
>> :-)  :-) 
>
> thanks a lot. My eyes are bleeding.


Well, I did warn you to skip it. 

I wonder, does he ever have a upgrade that goes smoothly?  That script
should bring out just about every single thing that can go wrong.  Just
wondering. 

Now, I got that air filter, cleaned the grease off the engine, removed
the bird nest as well,, changed the oil, new sparky plug and now I'm
going to test the tiller.  See, that is something productive to do. 

Dale

:-)  :-) 

Re: [gentoo-user] Re: [OT] How to be a penguin.

[Volker Armin Hemmann]

Am 28.05.2016 um 20:49 schrieb Dale:
> Dale wrote:
>> Gregory Woodbury wrote:
>>> Has Alan ever posted his "jackhammer" script for some experts to
>>> look at?
>>>
>>> I get by really well with a small script that reads the eix outputs,
>>> finds the "[U]"
>>> tagged packages, and then runs "emerge -u1" on that list.
>>>
>>> Doing anything more than that will be a cause of pain and suffering.
>>>
>>> If a package needs patches for something special, it is better to
>>> make a local 
>>> repository with modified ebuilds and distfiles, rather than try to
>>> force the gentoo repo 
>>> into your own mess. I do this for a few tthings that Gentoo doesn't
>>> ship. Portage
>>> is actuallly quite flexible underneath, itt just takes a bit of
>>> learning.
>>>
>>> -- 
>>> G.Wolfe Woodbury
>>> redwo...@gmail.com 
>>
>>
>> He did a while back.  Some very experienced Gentoo users here
>> explained to him that his script was the problem.  From memory which
>> isn't all that good, it syncs the tree which is fine.  After that, it
>> gets bad.  I think it did the updates and then repeated that several
>> times within the script.  That is done without him looking to see if
>> anything needs to be changed, USE flags etc, or if something
>> shouldn't be updated at all.  I'm pretty sure that it then deletes
>> all the logs of what was done, which means anything broken is broke
>> and no record of what or even why. 
>>
>> Yes, some things can be done with a script.  However, there needs to
>> be a point in there where the user, the real brain of what is wanted,
>> looks at the list of what will be updated.  Only a human can look and
>> see if there is USE flag changes or other issues that need a config
>> file to be edited.   Alan skips all that. 
>>
>> If you want, I can go dig it out and post it.  I should have a copy
>> of the script in my local email.  I keep them for like 2 years or
>> something then it deletes the old stuff.  I'm not sure if you will
>> laugh your head off or cry tho. 
>>
>> Dale
>>
>> :-)  :-) 
>
>
> What the heck.  I went back and found it.  It only took a few
> minutes.  The rest of this message is the email where he has his
> script.  I'll do my usual sign off at the bottom, rest is his post.  
> For those who have already seen it, you might want to skip past the
> rest.  No need torturing yourself again. 
>
>
>> I use two scripts for all emerge use, the goal is to run one command and
>> then walk away:
>>
>> Standard general update script:
>> ###
>> tortoise ~ # cat sysupdate
>>
>> #they must have moved or removed the logs, might have to track them down
>> again...
>> #rm /var/log/emerge*
>>
>> # cache /usr/portage 
>> echo "caching /usr/portage.  This will take a long time."
>> time ls -R /usr/portage > /dev/null
>>
>> emerge --sync
>> layman --sync ALL
>>
>> emerge --update --verbose portage
>> emerge --update --newuse --deep --with-bdeps=y system --keep-going
>> emerge --update --newuse --deep --with-bdeps=y world --keep-going
>>
>> rm -f /var/cache/revdep-rebuild/*.rr
>> revdep-rebuild
>> emerge --skipfirst --resume
>> emerge --skipfirst --resume
>> etc-update
>> eclean-dist
>> 
>>
>> The eclean line was added just a few days ago from this thread...
>>
>> This one is intended to be a nice gentle update script.
>> It caches the portage tree, then syncs everything, then updates
>> everything starting with critical system packages, then all world
>> packages...
>>
>> Then it cleans stuff up, it jcakhammers the revdep-rebuild but not too
>> hard
>>
>>
>> This next script is what I use when emerge starts giving me shit:
>>
>> ##
>> tortoise ~ # cat keepgoing
>> emerge --update --newuse --deep --with-bdeps=y system
>> emerge --skipfirst --resume --nodeps
>> emerge --skipfirst --resume --nodeps
>> emerge --skipfirst --resume --nodeps
>>
>> emerge --update --newuse --deep --with-bdeps=y world
>> emerge --skipfirst --resume --nodeps
>> emerge --skipfirst --resume --nodeps
>> emerge --skipfirst --resume --nodeps
>> emerge --skipfirst --resume --nodeps
>> emerge --skipfirst --resume --nodeps
>> emerge --skipfirst --resume --nodeps
>> emerge --skipfirst --resume --nodeps
>> emerge --skipfirst --resume --nodeps
>> emerge --skipfirst --resume --nodeps
>> emerge --skipfirst --resume --nodeps
>>
>> rm /var/cache/revdep-rebuild/*.rr
>> revdep-rebuild
>> emerge --skipfirst --resume --nodeps
>> emerge --skipfirst --resume --nodeps
>> emerge --skipfirst --resume --nodeps
>> emerge --skipfirst --resume --nodeps
>>
>> etc-update
>> ###
>>
>> It's basically the same as the working section of the above but instead
>> of letting emerge do it's thing, it jackhammers that bitch as hard as
>> possible to get as much updated as possible, but it requires emerge to
>> do something and not error out for no good reason... I expect prune and
>> depclean to be useless but I kinda need update to basically work every
>> time. 

[gentoo-user] Re: Do we have any Blender build experts in the house?

[James]

Andrew Lowe  wht.com.au> writes:


> unresolved reference to 'Imf_2_1::Header::view[abi:cxx11]() const

I have no idea what that is, nor can I find it.

I have this installed::


Installed versions:  2.72b-r3(12:54:31 PM 03/24/2016)(boost bullet dds
elbeem ffmpeg game-engine jack jpeg2k openexr openmp opennl tiff -collada
-colorio -cycles -debug -doc -fftw -libav -ndof -nls -openal -openimageio
-player -redcode -sdl -sndfile CPU_FLAGS_X86="sse sse2"
PYTHON_TARGETS="python3_4")


> There are a whole series of these errors all referencing undefined 
> things contained within a library called "Imf_2_1". I've done some 
> googling and I think this is something to do with a library from 
> Industrial Light & Magic but other than that, I can't work things out. 
> Has anyone come across this sort of problem before I have to post the 
> whole gory details of this problem.


I'm no whiz at blender, but it is installed. You can post snippets
and questions and I'll compare to my system, if that helps.


Did you look in bgo for any relevant bugs?


hth,
James

Re: [gentoo-user] kde-base/baloo is blocking an upgrade

[Dale]

Mick wrote:
> On Saturday 28 May 2016 11:25:47 Dale wrote:
>> Mick wrote:
>>> On Saturday 28 May 2016 10:53:53 Alan McKinnon wrote:
 On 28/05/2016 10:49, Mick wrote:
> On Saturday 28 May 2016 09:27:06 Neil Bothwick wrote:
>> On Sat, 28 May 2016 09:08:10 +0100, Mick wrote:
>>> I came across this blocker and I'm not sure how to overcome it:
>>> ===
>>> [ebuild  NS] kde-apps/kmix-15.12.3:5::gentoo
>>> [4.14.3-r1:4/4.14::gentoo] USE="alsa -debug -pulseaudio" 381 KiB
>>> [uninstall ] kde-apps/kmix-4.14.3-r1:4/4.14::gentoo  USE="alsa
>>> handbook (- aqua) -canberra -debug -pulseaudio"
>>> [blocks b  ] kde-apps/kmix:4 ("kde-apps/kmix:4" is blocking kde-
>>> apps/kmix-15.12.3)
>>> [ebuild  NS] kde-apps/kdemultimedia-meta-15.12.3:5::gentoo
>>> [4.14.3:4::gentoo] USE="ffmpeg" 0 KiB
>>> [uninstall ] kde-apps/kdemultimedia-meta-4.14.3:4::gentoo
>>> USE="ffmpeg (- aqua) -mplayer"
>>> [blocks b  ] kde-apps/kdemultimedia-meta:4
>>> ("kde-apps/kdemultimedia-
>>> meta:4" is blocking kde-apps/kdemultimedia-meta-15.12.3)
>>> [blocks B  ] kde-base/baloo:4[-minimal(-)] ("kde-base/baloo:4[-
>>> minimal(-)]" is blocking kde-frameworks/baloo-5.21.0)
>> Have you tried adding "kde-base/baloo minimal" to package.use?
>>
>> There have been a few cases where a software combination means you end
>> up
>> with both KDE4 and KDE5 versions of a package as dependencies and the
>> solution is usually to emerge the KDE4 version with USE="minimal".
> Thank you Alan and Neil for your replies.  I have tried:
>
> 1. --backrack 90
> 2. Adding USE="minimal" to kde-base/baloo
> 3. Unmerging kde-base/baloo and running emerge -uaDv world.
>
> but the clash remains.  On this box the user uses kmail, knotes,
> korganiser. I don't mind upgrading to the latest kde-frameworks
> equivalent, but I'd rather I stayed with stable packages as far as I can
> and I am not sure what the kde- frameworks kdepim-meta equivalent is,
> unless portage tells me.
>
> These are the dependencies equery shows for kdepim-common-libs:
>
> # equery depends kdepim-common-libs
>
>  * These packages depend on kdepim-common-libs:
> kde-apps/akonadiconsole-4.14.10 (>=kde-apps/kdepim-common-
> libs-4.14.10:4[aqua=])
> kde-apps/akregator-4.14.10
> (>=kde-apps/kdepim-common-libs-4.14.10:4[aqua=])
> kde-apps/blogilo-4.14.10
> (>=kde-apps/kdepim-common-libs-4.14.10:4[aqua=])
> kde-apps/calendarjanitor-4.14.10 (>=kde-apps/kdepim-common-
> libs-4.14.10:4[aqua=])
> kde-apps/kaddressbook-4.14.10
> (>=kde-apps/kdepim-common-libs-4.14.10:4[aqua=]) kde-apps/kalarm-4.14.10
> (>=kde-apps/kdepim-common-libs-4.14.10:4[aqua=])
> kde-apps/kdepim-kresources-4.14.10 (>=kde-apps/kdepim-common-
> libs-4.14.10:4[aqua=])
> kde-apps/kjots-4.14.10 (>=kde-apps/kdepim-common-libs-4.14.10:4[aqua=])
> kde-apps/kleopatra-4.14.10
> (>=kde-apps/kdepim-common-libs-4.14.10:4[aqua=])
> kde-apps/kmail-4.14.10 (>=kde-apps/kdepim-common-libs-4.14.10:4[aqua=])
> kde-apps/knode-4.14.10
> (>=kde-apps/kdepim-common-libs-4.12.1-r1:4[aqua=])
> kde-apps/knotes-4.14.10 (>=kde-apps/kdepim-common-libs-4.14.10:4[aqua=])
> kde-apps/konsolekalendar-4.14.10 (>=kde-apps/kdepim-common-
> libs-4.14.10:4[aqua=])
> kde-apps/kontact-4.14.10
> (>=kde-apps/kdepim-common-libs-4.14.10:4[aqua=])
> kde-apps/korganizer-4.14.10
> (>=kde-apps/kdepim-common-libs-4.14.10:4[aqua=])
> kde-apps/ktimetracker-4.14.10
> (>=kde-apps/kdepim-common-libs-4.14.10:4[aqua=])
 Neil is on the right track, kde-base/baloo[minimal] works with
 kde-frameworks/baloo

 I suspect you have a kdepim package that requires
 kde-base/baloo[-minimal], so please
>>> I have tried both minimal and -minimal, neither of which overcame the
>>> blocker.> 
 equery depends baloo

 and lets see what wants it
>>> # equery depends baloo
>>>
>>>  * These packages depend on baloo:
>>> kde-apps/baloo-widgets-4.14.3 (>=kde-base/baloo-4.14.3:4[aqua=])
>>> kde-apps/dolphin-4.14.3-r1 (semantic-desktop ? >=kde-
>>> base/baloo-4.14.3:4[aqua=])
>>> kde-apps/gwenview-4.14.3 (semantic-desktop ?
 =kde-base/baloo-4.14.3:4[aqua=]) kde-apps/kdepim-common-libs-4.14.10
>>> (>=kde-base/baloo-4.14.3:4[aqua=])
>>>
>>>
>>> # grep minimal -r /etc/portage/package.use
>>> # required by virtual/ssh-0[-minimal]
>>>
 =kde-apps/kde4-l10n-15.08.3-r2:4 minimal
>>> I recall having to add minimal to kde-apps/kde4-l10n a few weeks ago to
>>> overcome some blocker for plasma5, but I can't recall the exact situation
>>> was.
>> I haven't seen you post this yet.  Could you add -t to the emerge update
>> command and post it?  That may help Alan and Neil see what is pulling it
>> in.  The what may lead to the why.   Heck, 

Re: [gentoo-user] Re: [OT] How to be a penguin.

[Dale]

Dale wrote:
> Gregory Woodbury wrote:
>> Has Alan ever posted his "jackhammer" script for some experts to look
>> at?
>>
>> I get by really well with a small script that reads the eix outputs,
>> finds the "[U]"
>> tagged packages, and then runs "emerge -u1" on that list.
>>
>> Doing anything more than that will be a cause of pain and suffering.
>>
>> If a package needs patches for something special, it is better to
>> make a local 
>> repository with modified ebuilds and distfiles, rather than try to
>> force the gentoo repo 
>> into your own mess. I do this for a few tthings that Gentoo doesn't
>> ship. Portage
>> is actuallly quite flexible underneath, itt just takes a bit of learning.
>>
>> -- 
>> G.Wolfe Woodbury
>> redwo...@gmail.com 
>
>
> He did a while back.  Some very experienced Gentoo users here
> explained to him that his script was the problem.  From memory which
> isn't all that good, it syncs the tree which is fine.  After that, it
> gets bad.  I think it did the updates and then repeated that several
> times within the script.  That is done without him looking to see if
> anything needs to be changed, USE flags etc, or if something shouldn't
> be updated at all.  I'm pretty sure that it then deletes all the logs
> of what was done, which means anything broken is broke and no record
> of what or even why. 
>
> Yes, some things can be done with a script.  However, there needs to
> be a point in there where the user, the real brain of what is wanted,
> looks at the list of what will be updated.  Only a human can look and
> see if there is USE flag changes or other issues that need a config
> file to be edited.   Alan skips all that. 
>
> If you want, I can go dig it out and post it.  I should have a copy of
> the script in my local email.  I keep them for like 2 years or
> something then it deletes the old stuff.  I'm not sure if you will
> laugh your head off or cry tho. 
>
> Dale
>
> :-)  :-) 


What the heck.  I went back and found it.  It only took a few minutes. 
The rest of this message is the email where he has his script.  I'll do
my usual sign off at the bottom, rest is his post.   For those who have
already seen it, you might want to skip past the rest.  No need
torturing yourself again. 


> I use two scripts for all emerge use, the goal is to run one command and
> then walk away:
>
> Standard general update script:
> ###
> tortoise ~ # cat sysupdate
>
> #they must have moved or removed the logs, might have to track them down
> again...
> #rm /var/log/emerge*
>
> # cache /usr/portage 
> echo "caching /usr/portage.  This will take a long time."
> time ls -R /usr/portage > /dev/null
>
> emerge --sync
> layman --sync ALL
>
> emerge --update --verbose portage
> emerge --update --newuse --deep --with-bdeps=y system --keep-going
> emerge --update --newuse --deep --with-bdeps=y world --keep-going
>
> rm -f /var/cache/revdep-rebuild/*.rr
> revdep-rebuild
> emerge --skipfirst --resume
> emerge --skipfirst --resume
> etc-update
> eclean-dist
> 
>
> The eclean line was added just a few days ago from this thread...
>
> This one is intended to be a nice gentle update script.
> It caches the portage tree, then syncs everything, then updates
> everything starting with critical system packages, then all world
> packages...
>
> Then it cleans stuff up, it jcakhammers the revdep-rebuild but not too
> hard
>
>
> This next script is what I use when emerge starts giving me shit:
>
> ##
> tortoise ~ # cat keepgoing
> emerge --update --newuse --deep --with-bdeps=y system
> emerge --skipfirst --resume --nodeps
> emerge --skipfirst --resume --nodeps
> emerge --skipfirst --resume --nodeps
>
> emerge --update --newuse --deep --with-bdeps=y world
> emerge --skipfirst --resume --nodeps
> emerge --skipfirst --resume --nodeps
> emerge --skipfirst --resume --nodeps
> emerge --skipfirst --resume --nodeps
> emerge --skipfirst --resume --nodeps
> emerge --skipfirst --resume --nodeps
> emerge --skipfirst --resume --nodeps
> emerge --skipfirst --resume --nodeps
> emerge --skipfirst --resume --nodeps
> emerge --skipfirst --resume --nodeps
>
> rm /var/cache/revdep-rebuild/*.rr
> revdep-rebuild
> emerge --skipfirst --resume --nodeps
> emerge --skipfirst --resume --nodeps
> emerge --skipfirst --resume --nodeps
> emerge --skipfirst --resume --nodeps
>
> etc-update
> ###
>
> It's basically the same as the working section of the above but instead
> of letting emerge do it's thing, it jackhammers that bitch as hard as
> possible to get as much updated as possible, but it requires emerge to
> do something and not error out for no good reason... I expect prune and
> depclean to be useless but I kinda need update to basically work every
> time. =\
> Whatever fails on this script, I just live with until next week/month.
>
> ###
> tortoise ~ # ./pretendupdate
>
> These are the packages that would be merged, 

Re: [gentoo-user] Re: [OT] How to be a penguin.

[Dale]

Neil Bothwick wrote:
> On Sat, 28 May 2016 12:06:20 -0500, Dale wrote:
>
>> What is also a surprise, Alan hasn't figured out that his script is the
>> problem.
> I believe that there are actually two scripts at play here. One that does
> its best to defeat portage's attempts to keep a system clean and
> consistent and another that posts abusive rants to the list on behalf of
> the first.
>
>

I like how it blames portage instead of the real problem.  Yea, we run
into a occasional bump in the road on this list but overall, emerge does
one heck of a job sorting this mess out.  If it can find a path to
complete a upgrade, it gets there even if it has to spin the wheel a
little longer.  Poor Alan tho, he just keeps shooting himself in the
foot.   I'm saving my band-aids for someone who has at least learned to
use a better method.  Heck, if you or the smart Alan tells me I am doing
a upgrade wrong, I listen.  Thing is, even I know his script is a
disaster without even running it.  And I don't even try to claim to be a
expert on scripts or that I can eve write one.  lol   I just know his
creates a mess and every once in a while, he posts so that we know we
are right. 

It does serve as a good source of giggles tho.  ROFL

Dale

:-)  :-) 

Re: [gentoo-user] Re: [OT] How to be a penguin.

[Dale]

Gregory Woodbury wrote:
> Has Alan ever posted his "jackhammer" script for some experts to look at?
>
> I get by really well with a small script that reads the eix outputs,
> finds the "[U]"
> tagged packages, and then runs "emerge -u1" on that list.
>
> Doing anything more than that will be a cause of pain and suffering.
>
> If a package needs patches for something special, it is better to make
> a local 
> repository with modified ebuilds and distfiles, rather than try to
> force the gentoo repo 
> into your own mess. I do this for a few tthings that Gentoo doesn't
> ship. Portage
> is actuallly quite flexible underneath, itt just takes a bit of learning.
>
> -- 
> G.Wolfe Woodbury
> redwo...@gmail.com 


He did a while back.  Some very experienced Gentoo users here explained
to him that his script was the problem.  From memory which isn't all
that good, it syncs the tree which is fine.  After that, it gets bad.  I
think it did the updates and then repeated that several times within the
script.  That is done without him looking to see if anything needs to be
changed, USE flags etc, or if something shouldn't be updated at all. 
I'm pretty sure that it then deletes all the logs of what was done,
which means anything broken is broke and no record of what or even why. 

Yes, some things can be done with a script.  However, there needs to be
a point in there where the user, the real brain of what is wanted, looks
at the list of what will be updated.  Only a human can look and see if
there is USE flag changes or other issues that need a config file to be
edited.   Alan skips all that. 

If you want, I can go dig it out and post it.  I should have a copy of
the script in my local email.  I keep them for like 2 years or something
then it deletes the old stuff.  I'm not sure if you will laugh your head
off or cry tho. 

Dale

:-)  :-) 

Re: [gentoo-user] Re: [OT] How to be a penguin.

[Alec Ten Harmsel]

On Sat, May 28, 2016 at 02:05:11PM -0400, Gregory Woodbury wrote:
> Has Alan ever posted his "jackhammer" script for some experts to look at?

Yes. You can probably find it on gmane. It basically consists of running
emerge with --keep-going and --ignore-failures multiple times, running
some depcleans, running revdep-rebuild a few times, and probably doing
all of this a few times.

> I get by really well with a small script that reads the eix outputs, finds
> the "[U]"
> tagged packages, and then runs "emerge -u1" on that list.

That sounds cool. `emerge -uDN --with-bdeps=y @world' should do
approximately the same thing, though.

Alec

Re: [gentoo-user] Re: [OT] How to be a penguin.

[Neil Bothwick]

On Sat, 28 May 2016 12:06:20 -0500, Dale wrote:

> What is also a surprise, Alan hasn't figured out that his script is the
> problem.

I believe that there are actually two scripts at play here. One that does
its best to defeat portage's attempts to keep a system clean and
consistent and another that posts abusive rants to the list on behalf of
the first.


-- 
Neil Bothwick

LISP: Lots of Infuriating & Silly Parentheses


pgp21htuZyK2d.pgp
Description: OpenPGP digital signature

Re: [gentoo-user] Re: [OT] How to be a penguin.

[Neil Bothwick]

On Sat, 28 May 2016 14:05:11 -0400, Gregory Woodbury wrote:

> Has Alan ever posted his "jackhammer" script for some experts to look
> at?

Yes, some are still recovering from the experience of seeing what it does!


-- 
Neil Bothwick

If a stealth bomber crashes in a forest, will it make a sound?


pgp6mnvRB28sl.pgp
Description: OpenPGP digital signature

Re: [gentoo-user] Re: [OT] How to be a penguin.

[Gregory Woodbury]

Has Alan ever posted his "jackhammer" script for some experts to look at?

I get by really well with a small script that reads the eix outputs, finds
the "[U]"
tagged packages, and then runs "emerge -u1" on that list.

Doing anything more than that will be a cause of pain and suffering.

If a package needs patches for something special, it is better to make a
local
repository with modified ebuilds and distfiles, rather than try to force
the gentoo repo
into your own mess. I do this for a few tthings that Gentoo doesn't ship.
Portage
is actuallly quite flexible underneath, itt just takes a bit of learning.

-- 
G.Wolfe Woodbury
redwo...@gmail.com

[gentoo-user] Do we have any Blender build experts in the house?

[Andrew Lowe]

Hi all,
	I'm attempting to build Blender, 2,7,6 but am running into a problem 
during linking. I am getting a series of errors referring to an, for 
example:


unresolved reference to 'Imf_2_1::Header::view[abi:cxx11]() const

There are a whole series of these errors all referencing undefined 
things contained within a library called "Imf_2_1". I've done some 
googling and I think this is something to do with a library from 
Industrial Light & Magic but other than that, I can't work things out. 
Has anyone come across this sort of problem before I have to post the 
whole gory details of this problem.


Any thoughts greatly appreciated,
Andrew

Re: [gentoo-user] Re: [OT] How to be a penguin.

[Dale]

»Q« wrote:
> On Sat, 28 May 2016 12:05:02 -0400
> Alan Grimes  wrote:
>
>> I feel that my jackhammer script has been deliberately defeated.
> IMO, that's overly pessimistic.  The script seems to be defeating
> portage pretty consistently, and that's clearly the job it was designed
> for.
>
>> It's getting to the point that I can't remember a time when running
>> emerge has not been a week-long ordeal.
> I wouldn't be satisfied with the jackhammer script until it's capable
> of creating at least a month-long ordeal each time.  Then it will be
> ready to ship to all users.
>
> [Sorry, everybody, occasionally I just can't keep my fingers off the
> keys.]
>
>
>

Well, he has been told by just about everyone who bothers to reply that
his script is the problem not emerge.  It's amazing how so many of us
use emerge all the time and generally it does what it is supposed to do
but for this Alan, it does something different. 

What is also a surprise, Alan hasn't figured out that his script is the
problem.  One thing about a jackhammer, it will tear up whatever you put
it on.  His jackhammer script and methodology has sure done that for him. 

Me, I'm going to town and find a air filter for my neighbors tiller. 
That is something more productive.  ;-)

Dale

:-)  :-) 

Re: [gentoo-user] kde-base/baloo is blocking an upgrade

[Mick]

On Saturday 28 May 2016 11:25:47 Dale wrote:
> Mick wrote:
> > On Saturday 28 May 2016 10:53:53 Alan McKinnon wrote:
> >> On 28/05/2016 10:49, Mick wrote:
> >>> On Saturday 28 May 2016 09:27:06 Neil Bothwick wrote:
>  On Sat, 28 May 2016 09:08:10 +0100, Mick wrote:
> > I came across this blocker and I'm not sure how to overcome it:
> > ===
> > [ebuild  NS] kde-apps/kmix-15.12.3:5::gentoo
> > [4.14.3-r1:4/4.14::gentoo] USE="alsa -debug -pulseaudio" 381 KiB
> > [uninstall ] kde-apps/kmix-4.14.3-r1:4/4.14::gentoo  USE="alsa
> > handbook (- aqua) -canberra -debug -pulseaudio"
> > [blocks b  ] kde-apps/kmix:4 ("kde-apps/kmix:4" is blocking kde-
> > apps/kmix-15.12.3)
> > [ebuild  NS] kde-apps/kdemultimedia-meta-15.12.3:5::gentoo
> > [4.14.3:4::gentoo] USE="ffmpeg" 0 KiB
> > [uninstall ] kde-apps/kdemultimedia-meta-4.14.3:4::gentoo
> > USE="ffmpeg (- aqua) -mplayer"
> > [blocks b  ] kde-apps/kdemultimedia-meta:4
> > ("kde-apps/kdemultimedia-
> > meta:4" is blocking kde-apps/kdemultimedia-meta-15.12.3)
> > [blocks B  ] kde-base/baloo:4[-minimal(-)] ("kde-base/baloo:4[-
> > minimal(-)]" is blocking kde-frameworks/baloo-5.21.0)
>  
>  Have you tried adding "kde-base/baloo minimal" to package.use?
>  
>  There have been a few cases where a software combination means you end
>  up
>  with both KDE4 and KDE5 versions of a package as dependencies and the
>  solution is usually to emerge the KDE4 version with USE="minimal".
> >>> 
> >>> Thank you Alan and Neil for your replies.  I have tried:
> >>> 
> >>> 1. --backrack 90
> >>> 2. Adding USE="minimal" to kde-base/baloo
> >>> 3. Unmerging kde-base/baloo and running emerge -uaDv world.
> >>> 
> >>> but the clash remains.  On this box the user uses kmail, knotes,
> >>> korganiser. I don't mind upgrading to the latest kde-frameworks
> >>> equivalent, but I'd rather I stayed with stable packages as far as I can
> >>> and I am not sure what the kde- frameworks kdepim-meta equivalent is,
> >>> unless portage tells me.
> >>> 
> >>> These are the dependencies equery shows for kdepim-common-libs:
> >>> 
> >>> # equery depends kdepim-common-libs
> >>> 
> >>>  * These packages depend on kdepim-common-libs:
> >>> kde-apps/akonadiconsole-4.14.10 (>=kde-apps/kdepim-common-
> >>> libs-4.14.10:4[aqua=])
> >>> kde-apps/akregator-4.14.10
> >>> (>=kde-apps/kdepim-common-libs-4.14.10:4[aqua=])
> >>> kde-apps/blogilo-4.14.10
> >>> (>=kde-apps/kdepim-common-libs-4.14.10:4[aqua=])
> >>> kde-apps/calendarjanitor-4.14.10 (>=kde-apps/kdepim-common-
> >>> libs-4.14.10:4[aqua=])
> >>> kde-apps/kaddressbook-4.14.10
> >>> (>=kde-apps/kdepim-common-libs-4.14.10:4[aqua=]) kde-apps/kalarm-4.14.10
> >>> (>=kde-apps/kdepim-common-libs-4.14.10:4[aqua=])
> >>> kde-apps/kdepim-kresources-4.14.10 (>=kde-apps/kdepim-common-
> >>> libs-4.14.10:4[aqua=])
> >>> kde-apps/kjots-4.14.10 (>=kde-apps/kdepim-common-libs-4.14.10:4[aqua=])
> >>> kde-apps/kleopatra-4.14.10
> >>> (>=kde-apps/kdepim-common-libs-4.14.10:4[aqua=])
> >>> kde-apps/kmail-4.14.10 (>=kde-apps/kdepim-common-libs-4.14.10:4[aqua=])
> >>> kde-apps/knode-4.14.10
> >>> (>=kde-apps/kdepim-common-libs-4.12.1-r1:4[aqua=])
> >>> kde-apps/knotes-4.14.10 (>=kde-apps/kdepim-common-libs-4.14.10:4[aqua=])
> >>> kde-apps/konsolekalendar-4.14.10 (>=kde-apps/kdepim-common-
> >>> libs-4.14.10:4[aqua=])
> >>> kde-apps/kontact-4.14.10
> >>> (>=kde-apps/kdepim-common-libs-4.14.10:4[aqua=])
> >>> kde-apps/korganizer-4.14.10
> >>> (>=kde-apps/kdepim-common-libs-4.14.10:4[aqua=])
> >>> kde-apps/ktimetracker-4.14.10
> >>> (>=kde-apps/kdepim-common-libs-4.14.10:4[aqua=])
> >> 
> >> Neil is on the right track, kde-base/baloo[minimal] works with
> >> kde-frameworks/baloo
> >> 
> >> I suspect you have a kdepim package that requires
> >> kde-base/baloo[-minimal], so please
> > 
> > I have tried both minimal and -minimal, neither of which overcame the
> > blocker.> 
> >> equery depends baloo
> >> 
> >> and lets see what wants it
> > 
> > # equery depends baloo
> > 
> >  * These packages depend on baloo:
> > kde-apps/baloo-widgets-4.14.3 (>=kde-base/baloo-4.14.3:4[aqua=])
> > kde-apps/dolphin-4.14.3-r1 (semantic-desktop ? >=kde-
> > base/baloo-4.14.3:4[aqua=])
> > kde-apps/gwenview-4.14.3 (semantic-desktop ?
> > >=kde-base/baloo-4.14.3:4[aqua=]) kde-apps/kdepim-common-libs-4.14.10
> > (>=kde-base/baloo-4.14.3:4[aqua=])
> > 
> > 
> > # grep minimal -r /etc/portage/package.use
> > # required by virtual/ssh-0[-minimal]
> > 
> >> =kde-apps/kde4-l10n-15.08.3-r2:4 minimal
> > 
> > I recall having to add minimal to kde-apps/kde4-l10n a few weeks ago to
> > overcome some blocker for plasma5, but I can't recall the exact situation
> > was.
> I haven't seen you post this yet.  Could you add -t to the emerge update
> command and post it?  That may help Alan and Neil see what is pulling it
> in.  The what 

Re: [gentoo-user] kde-base/baloo is blocking an upgrade

[Dale]

Mick wrote:
> On Saturday 28 May 2016 10:53:53 Alan McKinnon wrote:
>> On 28/05/2016 10:49, Mick wrote:
>>> On Saturday 28 May 2016 09:27:06 Neil Bothwick wrote:
 On Sat, 28 May 2016 09:08:10 +0100, Mick wrote:
> I came across this blocker and I'm not sure how to overcome it:
> ===
> [ebuild  NS] kde-apps/kmix-15.12.3:5::gentoo
> [4.14.3-r1:4/4.14::gentoo] USE="alsa -debug -pulseaudio" 381 KiB
> [uninstall ] kde-apps/kmix-4.14.3-r1:4/4.14::gentoo  USE="alsa
> handbook (- aqua) -canberra -debug -pulseaudio"
> [blocks b  ] kde-apps/kmix:4 ("kde-apps/kmix:4" is blocking kde-
> apps/kmix-15.12.3)
> [ebuild  NS] kde-apps/kdemultimedia-meta-15.12.3:5::gentoo
> [4.14.3:4::gentoo] USE="ffmpeg" 0 KiB
> [uninstall ] kde-apps/kdemultimedia-meta-4.14.3:4::gentoo
> USE="ffmpeg (- aqua) -mplayer"
> [blocks b  ] kde-apps/kdemultimedia-meta:4 ("kde-apps/kdemultimedia-
> meta:4" is blocking kde-apps/kdemultimedia-meta-15.12.3)
> [blocks B  ] kde-base/baloo:4[-minimal(-)] ("kde-base/baloo:4[-
> minimal(-)]" is blocking kde-frameworks/baloo-5.21.0)
 Have you tried adding "kde-base/baloo minimal" to package.use?

 There have been a few cases where a software combination means you end up
 with both KDE4 and KDE5 versions of a package as dependencies and the
 solution is usually to emerge the KDE4 version with USE="minimal".
>>> Thank you Alan and Neil for your replies.  I have tried:
>>>
>>> 1. --backrack 90
>>> 2. Adding USE="minimal" to kde-base/baloo
>>> 3. Unmerging kde-base/baloo and running emerge -uaDv world.
>>>
>>> but the clash remains.  On this box the user uses kmail, knotes,
>>> korganiser. I don't mind upgrading to the latest kde-frameworks
>>> equivalent, but I'd rather I stayed with stable packages as far as I can
>>> and I am not sure what the kde- frameworks kdepim-meta equivalent is,
>>> unless portage tells me.
>>>
>>> These are the dependencies equery shows for kdepim-common-libs:
>>>
>>> # equery depends kdepim-common-libs
>>>
>>>  * These packages depend on kdepim-common-libs:
>>> kde-apps/akonadiconsole-4.14.10 (>=kde-apps/kdepim-common-
>>> libs-4.14.10:4[aqua=])
>>> kde-apps/akregator-4.14.10
>>> (>=kde-apps/kdepim-common-libs-4.14.10:4[aqua=])
>>> kde-apps/blogilo-4.14.10 (>=kde-apps/kdepim-common-libs-4.14.10:4[aqua=])
>>> kde-apps/calendarjanitor-4.14.10 (>=kde-apps/kdepim-common-
>>> libs-4.14.10:4[aqua=])
>>> kde-apps/kaddressbook-4.14.10
>>> (>=kde-apps/kdepim-common-libs-4.14.10:4[aqua=]) kde-apps/kalarm-4.14.10
>>> (>=kde-apps/kdepim-common-libs-4.14.10:4[aqua=])
>>> kde-apps/kdepim-kresources-4.14.10 (>=kde-apps/kdepim-common-
>>> libs-4.14.10:4[aqua=])
>>> kde-apps/kjots-4.14.10 (>=kde-apps/kdepim-common-libs-4.14.10:4[aqua=])
>>> kde-apps/kleopatra-4.14.10
>>> (>=kde-apps/kdepim-common-libs-4.14.10:4[aqua=])
>>> kde-apps/kmail-4.14.10 (>=kde-apps/kdepim-common-libs-4.14.10:4[aqua=])
>>> kde-apps/knode-4.14.10 (>=kde-apps/kdepim-common-libs-4.12.1-r1:4[aqua=])
>>> kde-apps/knotes-4.14.10 (>=kde-apps/kdepim-common-libs-4.14.10:4[aqua=])
>>> kde-apps/konsolekalendar-4.14.10 (>=kde-apps/kdepim-common-
>>> libs-4.14.10:4[aqua=])
>>> kde-apps/kontact-4.14.10 (>=kde-apps/kdepim-common-libs-4.14.10:4[aqua=])
>>> kde-apps/korganizer-4.14.10
>>> (>=kde-apps/kdepim-common-libs-4.14.10:4[aqua=])
>>> kde-apps/ktimetracker-4.14.10
>>> (>=kde-apps/kdepim-common-libs-4.14.10:4[aqua=])
>> Neil is on the right track, kde-base/baloo[minimal] works with
>> kde-frameworks/baloo
>>
>> I suspect you have a kdepim package that requires
>> kde-base/baloo[-minimal], so please
> I have tried both minimal and -minimal, neither of which overcame the blocker.
>
>> equery depends baloo
>>
>> and lets see what wants it
> # equery depends baloo
>  * These packages depend on baloo:
> kde-apps/baloo-widgets-4.14.3 (>=kde-base/baloo-4.14.3:4[aqua=])
> kde-apps/dolphin-4.14.3-r1 (semantic-desktop ? >=kde-
> base/baloo-4.14.3:4[aqua=])
> kde-apps/gwenview-4.14.3 (semantic-desktop ? >=kde-base/baloo-4.14.3:4[aqua=])
> kde-apps/kdepim-common-libs-4.14.10 (>=kde-base/baloo-4.14.3:4[aqua=])
>
>
> # grep minimal -r /etc/portage/package.use
> # required by virtual/ssh-0[-minimal]
>> =kde-apps/kde4-l10n-15.08.3-r2:4 minimal
> I recall having to add minimal to kde-apps/kde4-l10n a few weeks ago to 
> overcome some blocker for plasma5, but I can't recall the exact situation was.
>

I haven't seen you post this yet.  Could you add -t to the emerge update
command and post it?  That may help Alan and Neil see what is pulling it
in.  The what may lead to the why.   Heck, maybe I will see something
that will help shed some light on this problem. 

Dale

:-)  :-) 

[gentoo-user] Re: [OT] How to be a penguin.

[»Q«]

On Sat, 28 May 2016 12:05:02 -0400
Alan Grimes  wrote:

> I feel that my jackhammer script has been deliberately defeated.

IMO, that's overly pessimistic.  The script seems to be defeating
portage pretty consistently, and that's clearly the job it was designed
for.

> It's getting to the point that I can't remember a time when running
> emerge has not been a week-long ordeal.

I wouldn't be satisfied with the jackhammer script until it's capable
of creating at least a month-long ordeal each time.  Then it will be
ready to ship to all users.

[Sorry, everybody, occasionally I just can't keep my fingers off the
keys.]

[gentoo-user] How to be a penguin.

[Alan Grimes]

1. Fuck shit up royally.
2. Waddle around squawking about how everything works perfectly for you
and that it's the user's fault.


It's getting to the point that I can't remember a time when running
emerge has not been a week-long ordeal.


I feel that my jackhammer script has been deliberately defeated. Instead
of permitting the user, in the ancient tradition, hit the thing until it
works, emerge honors every package with an excessively specific version
dependency specifier (all set to different versions, of course.)

Of course, if a version of a package is required by hundreds of
packages, it is therefore masked instead of the version that all
packages will probably work just fine with but have e-builds that
prevent them from actually working out of pure spite towards the user. =\


It took me two days to gut my package base enough to get emerge to do
anything, which means I'm getting more skillful at this...

One of my mistakes was uninstalling findutils, which I had to manually
patch.. I never mastered using find because it always takes much less
time to do it with a gui file manager, than to look up the garbled
syntax that stupid utility requires...

Anyway, I have several dozen packages failing due to file collisions
around:


>>> Failed to install net-libs/gnutls-3.4.12, Log file:

>>>  '/var/tmp/portage/net-libs/gnutls-3.4.12/temp/build.log'

 * Messages for package net-libs/gnutls-3.4.12:

 * This package will overwrite one or more files that may belong to other
 * packages (see list below). You can use a command such as `portageq
 * owners / ` to identify the installed package that owns a
 * file. If portageq reports that only one package owns a file then do
 * NOT file a bug report. A bug report is only useful if it identifies at
 * least two or more packages that are known to install the same file(s).
 * If a collision occurs and you can not explain where the file came from
 * then you should simply ignore the collision since there is not enough
 * information to determine if a real problem exists. Please do NOT file
 * a bug report at http://bugs.gentoo.org unless you report exactly which
 * two packages install the same file(s). See
 * http://wiki.gentoo.org/wiki/Knowledge_Base:Blockers for tips on how to
 * solve the problem. And once again, please do NOT file a bug report
 * unless you have completely understood the above message.
 *
 * Detected file collision(s):
 *
 *  /usr/share/doc.ecompress.dir
 *  /usr/share/man.ecompress.dir
 *
 * Searching all installed packages for file collisions...
 *
 * Press Ctrl-C to Stop
 *
 * media-libs/libpng-1.6.22:0::gentoo
 *  /usr/share/doc.ecompress.dir
 *  /usr/share/man.ecompress.dir
 *
 * sys-libs/gdbm-1.12:0::gentoo
 *  /usr/share/doc.ecompress.dir
 *  /usr/share/man.ecompress.dir
 *
 * Package 'net-libs/gnutls-3.4.12' NOT merged due to file collisions. If
 * necessary, refer to your elog messages for the whole content of the
 * above message.

 * GNU info directory index is up-to-date.
Scanning Configuration files...
Exiting: Nothing left to do; exiting. :)
tortoise ~ #

mostly..


So I need a new translation of "FUCK YOU" that will cause emerge to
actually install the packages instead of using this as an excuse to
waste my time. I did google this but it was only reporting threads from
2008, and I'm sure the syntax and best practices have changed...

-- 
IQ is a measure of how stupid you feel.

Powers are not rights.

Re: [gentoo-user] Re: Updating pretty old system - portage fail, stage3 gcc also broken...

[Marcin Cieslak]

On Wed, 25 May 2016, James wrote:

> Marcin Cieslak  saper.info> writes:
> 
> Sometimes a fresh install is a good idea. Make sure all your system
> fans are in place and running to keep the system cool as you compile.

This is a rented server in a datacenter, so things run smoothly,
even recently got all hard drives replaced.

A fresh install will come, but this will be a different
operating system, I'm afraid.

Thank you everyone for their insights!

Marcin

Re: [gentoo-user] tablet

[Thanasis]

On 05/28/2016 09:03 AM, Bill Kenworthy wrote:

I was just about to spring for a mid range MS surface pro 4 tablet when
I saw a few posts about hardware problems ... MS hardware is usually
solid (in contrast to their software! :)

Are there any other similar tablets out there that are gentoo/Linux
friendly that are worth looking at?

I have been using an old Samsung android tablet and google has just
crossed the line and creeped me out past what I can tolerate so its time
to move on  :(

BillK



Aquaris M10

https://store.bq.com/gl/

Re: [gentoo-user] tablet

[Bill Kenworthy]

On 28/05/16 16:00, Giampiero Gabbiani wrote:
> In data sabato 28 maggio 2016 14:03:16, Bill Kenworthy ha scritto:
>> I was just about to spring for a mid range MS surface pro 4 tablet when
>> I saw a few posts about hardware problems ... MS hardware is usually
>> solid (in contrast to their software! :)
>>
>> Are there any other similar tablets out there that are gentoo/Linux
>> friendly that are worth looking at?
> I have a surface pro and one surface pro 3, each of them purchased as soon 
> as they appeared in Italy and all of them with Gentoo running since the very 
> beginning.
> 
> Skipping the patches I had to apply initially for having all the HW working, 
> currently in the pro 3 the running gentoo has a kernel 4.0.4 on which I retro 
> applied the MS button module from a successive kernel release for the volume 
> and power buttons to work and a patch for having both the cams working too.
> 
> If you need I can send them both.
> 
> I'm very satisfied with it (I have also the MS docking station) I use it for 
> office and as DAW (with jackd)
> 
> Regards
> Giampiero
>> I have been using an old Samsung android tablet and google has just
>> crossed the line and creeped me out past what I can tolerate so its time
>> to move on  :(
>>
>> BillK
> 
> 


I went to a couple of stores and decided that if I keep dithering I'll
never do it - so I now have a surface pro 4 :)

Waiting for it charge/complete the windows updates before I force it
into a corner to make room for gentoo.  Thankyou for the offer of the
patches - I'll contact you when I get that far.

I'll be going with kernel 4.4.11 (to match everything else I have here)

BillK

Re: [gentoo-user] kde-base/baloo is blocking an upgrade

[Mick]

On Saturday 28 May 2016 10:53:53 Alan McKinnon wrote:
> On 28/05/2016 10:49, Mick wrote:
> > On Saturday 28 May 2016 09:27:06 Neil Bothwick wrote:
> >> On Sat, 28 May 2016 09:08:10 +0100, Mick wrote:
> >>> I came across this blocker and I'm not sure how to overcome it:
> >>> ===
> >>> [ebuild  NS] kde-apps/kmix-15.12.3:5::gentoo
> >>> [4.14.3-r1:4/4.14::gentoo] USE="alsa -debug -pulseaudio" 381 KiB
> >>> [uninstall ] kde-apps/kmix-4.14.3-r1:4/4.14::gentoo  USE="alsa
> >>> handbook (- aqua) -canberra -debug -pulseaudio"
> >>> [blocks b  ] kde-apps/kmix:4 ("kde-apps/kmix:4" is blocking kde-
> >>> apps/kmix-15.12.3)
> >>> [ebuild  NS] kde-apps/kdemultimedia-meta-15.12.3:5::gentoo
> >>> [4.14.3:4::gentoo] USE="ffmpeg" 0 KiB
> >>> [uninstall ] kde-apps/kdemultimedia-meta-4.14.3:4::gentoo
> >>> USE="ffmpeg (- aqua) -mplayer"
> >>> [blocks b  ] kde-apps/kdemultimedia-meta:4 ("kde-apps/kdemultimedia-
> >>> meta:4" is blocking kde-apps/kdemultimedia-meta-15.12.3)
> >>> [blocks B  ] kde-base/baloo:4[-minimal(-)] ("kde-base/baloo:4[-
> >>> minimal(-)]" is blocking kde-frameworks/baloo-5.21.0)
> >> 
> >> Have you tried adding "kde-base/baloo minimal" to package.use?
> >> 
> >> There have been a few cases where a software combination means you end up
> >> with both KDE4 and KDE5 versions of a package as dependencies and the
> >> solution is usually to emerge the KDE4 version with USE="minimal".
> > 
> > Thank you Alan and Neil for your replies.  I have tried:
> > 
> > 1. --backrack 90
> > 2. Adding USE="minimal" to kde-base/baloo
> > 3. Unmerging kde-base/baloo and running emerge -uaDv world.
> > 
> > but the clash remains.  On this box the user uses kmail, knotes,
> > korganiser. I don't mind upgrading to the latest kde-frameworks
> > equivalent, but I'd rather I stayed with stable packages as far as I can
> > and I am not sure what the kde- frameworks kdepim-meta equivalent is,
> > unless portage tells me.
> > 
> > These are the dependencies equery shows for kdepim-common-libs:
> > 
> > # equery depends kdepim-common-libs
> > 
> >  * These packages depend on kdepim-common-libs:
> > kde-apps/akonadiconsole-4.14.10 (>=kde-apps/kdepim-common-
> > libs-4.14.10:4[aqua=])
> > kde-apps/akregator-4.14.10
> > (>=kde-apps/kdepim-common-libs-4.14.10:4[aqua=])
> > kde-apps/blogilo-4.14.10 (>=kde-apps/kdepim-common-libs-4.14.10:4[aqua=])
> > kde-apps/calendarjanitor-4.14.10 (>=kde-apps/kdepim-common-
> > libs-4.14.10:4[aqua=])
> > kde-apps/kaddressbook-4.14.10
> > (>=kde-apps/kdepim-common-libs-4.14.10:4[aqua=]) kde-apps/kalarm-4.14.10
> > (>=kde-apps/kdepim-common-libs-4.14.10:4[aqua=])
> > kde-apps/kdepim-kresources-4.14.10 (>=kde-apps/kdepim-common-
> > libs-4.14.10:4[aqua=])
> > kde-apps/kjots-4.14.10 (>=kde-apps/kdepim-common-libs-4.14.10:4[aqua=])
> > kde-apps/kleopatra-4.14.10
> > (>=kde-apps/kdepim-common-libs-4.14.10:4[aqua=])
> > kde-apps/kmail-4.14.10 (>=kde-apps/kdepim-common-libs-4.14.10:4[aqua=])
> > kde-apps/knode-4.14.10 (>=kde-apps/kdepim-common-libs-4.12.1-r1:4[aqua=])
> > kde-apps/knotes-4.14.10 (>=kde-apps/kdepim-common-libs-4.14.10:4[aqua=])
> > kde-apps/konsolekalendar-4.14.10 (>=kde-apps/kdepim-common-
> > libs-4.14.10:4[aqua=])
> > kde-apps/kontact-4.14.10 (>=kde-apps/kdepim-common-libs-4.14.10:4[aqua=])
> > kde-apps/korganizer-4.14.10
> > (>=kde-apps/kdepim-common-libs-4.14.10:4[aqua=])
> > kde-apps/ktimetracker-4.14.10
> > (>=kde-apps/kdepim-common-libs-4.14.10:4[aqua=])
> Neil is on the right track, kde-base/baloo[minimal] works with
> kde-frameworks/baloo
> 
> I suspect you have a kdepim package that requires
> kde-base/baloo[-minimal], so please

I have tried both minimal and -minimal, neither of which overcame the blocker.

> equery depends baloo
> 
> and lets see what wants it

# equery depends baloo
 * These packages depend on baloo:
kde-apps/baloo-widgets-4.14.3 (>=kde-base/baloo-4.14.3:4[aqua=])
kde-apps/dolphin-4.14.3-r1 (semantic-desktop ? >=kde-
base/baloo-4.14.3:4[aqua=])
kde-apps/gwenview-4.14.3 (semantic-desktop ? >=kde-base/baloo-4.14.3:4[aqua=])
kde-apps/kdepim-common-libs-4.14.10 (>=kde-base/baloo-4.14.3:4[aqua=])


# grep minimal -r /etc/portage/package.use
# required by virtual/ssh-0[-minimal]
>=kde-apps/kde4-l10n-15.08.3-r2:4 minimal

I recall having to add minimal to kde-apps/kde4-l10n a few weeks ago to 
overcome some blocker for plasma5, but I can't recall the exact situation was.

-- 
Regards,
Mick

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

Re: [gentoo-user] kde-base/baloo is blocking an upgrade

[Alan McKinnon]

On 28/05/2016 10:49, Mick wrote:
> On Saturday 28 May 2016 09:27:06 Neil Bothwick wrote:
>> On Sat, 28 May 2016 09:08:10 +0100, Mick wrote:
>>> I came across this blocker and I'm not sure how to overcome it:
>>> ===
>>> [ebuild  NS] kde-apps/kmix-15.12.3:5::gentoo
>>> [4.14.3-r1:4/4.14::gentoo] USE="alsa -debug -pulseaudio" 381 KiB
>>> [uninstall ] kde-apps/kmix-4.14.3-r1:4/4.14::gentoo  USE="alsa
>>> handbook (- aqua) -canberra -debug -pulseaudio"
>>> [blocks b  ] kde-apps/kmix:4 ("kde-apps/kmix:4" is blocking kde-
>>> apps/kmix-15.12.3)
>>> [ebuild  NS] kde-apps/kdemultimedia-meta-15.12.3:5::gentoo
>>> [4.14.3:4::gentoo] USE="ffmpeg" 0 KiB
>>> [uninstall ] kde-apps/kdemultimedia-meta-4.14.3:4::gentoo
>>> USE="ffmpeg (- aqua) -mplayer"
>>> [blocks b  ] kde-apps/kdemultimedia-meta:4 ("kde-apps/kdemultimedia-
>>> meta:4" is blocking kde-apps/kdemultimedia-meta-15.12.3)
>>> [blocks B  ] kde-base/baloo:4[-minimal(-)] ("kde-base/baloo:4[-
>>> minimal(-)]" is blocking kde-frameworks/baloo-5.21.0)
>>
>> Have you tried adding "kde-base/baloo minimal" to package.use?
>>
>> There have been a few cases where a software combination means you end up
>> with both KDE4 and KDE5 versions of a package as dependencies and the
>> solution is usually to emerge the KDE4 version with USE="minimal".
> 
> Thank you Alan and Neil for your replies.  I have tried:
> 
> 1. --backrack 90
> 2. Adding USE="minimal" to kde-base/baloo
> 3. Unmerging kde-base/baloo and running emerge -uaDv world.
> 
> but the clash remains.  On this box the user uses kmail, knotes, korganiser.  
> I don't mind upgrading to the latest kde-frameworks equivalent, but I'd 
> rather 
> I stayed with stable packages as far as I can and I am not sure what the kde-
> frameworks kdepim-meta equivalent is, unless portage tells me.
> 
> These are the dependencies equery shows for kdepim-common-libs:
> 
> # equery depends kdepim-common-libs
>  * These packages depend on kdepim-common-libs:
> kde-apps/akonadiconsole-4.14.10 (>=kde-apps/kdepim-common-
> libs-4.14.10:4[aqua=])
> kde-apps/akregator-4.14.10 (>=kde-apps/kdepim-common-libs-4.14.10:4[aqua=])
> kde-apps/blogilo-4.14.10 (>=kde-apps/kdepim-common-libs-4.14.10:4[aqua=])
> kde-apps/calendarjanitor-4.14.10 (>=kde-apps/kdepim-common-
> libs-4.14.10:4[aqua=])
> kde-apps/kaddressbook-4.14.10 (>=kde-apps/kdepim-common-libs-4.14.10:4[aqua=])
> kde-apps/kalarm-4.14.10 (>=kde-apps/kdepim-common-libs-4.14.10:4[aqua=])
> kde-apps/kdepim-kresources-4.14.10 (>=kde-apps/kdepim-common-
> libs-4.14.10:4[aqua=])
> kde-apps/kjots-4.14.10 (>=kde-apps/kdepim-common-libs-4.14.10:4[aqua=])
> kde-apps/kleopatra-4.14.10 (>=kde-apps/kdepim-common-libs-4.14.10:4[aqua=])
> kde-apps/kmail-4.14.10 (>=kde-apps/kdepim-common-libs-4.14.10:4[aqua=])
> kde-apps/knode-4.14.10 (>=kde-apps/kdepim-common-libs-4.12.1-r1:4[aqua=])
> kde-apps/knotes-4.14.10 (>=kde-apps/kdepim-common-libs-4.14.10:4[aqua=])
> kde-apps/konsolekalendar-4.14.10 (>=kde-apps/kdepim-common-
> libs-4.14.10:4[aqua=])
> kde-apps/kontact-4.14.10 (>=kde-apps/kdepim-common-libs-4.14.10:4[aqua=])
> kde-apps/korganizer-4.14.10 (>=kde-apps/kdepim-common-libs-4.14.10:4[aqua=])
> kde-apps/ktimetracker-4.14.10 (>=kde-apps/kdepim-common-libs-4.14.10:4[aqua=])
> 


Neil is on the right track, kde-base/baloo[minimal] works with
kde-frameworks/baloo

I suspect you have a kdepim package that requires
kde-base/baloo[-minimal], so please

equery depends baloo

and lets see what wants it


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

Re: [gentoo-user] kde-base/baloo is blocking an upgrade

[Mick]

On Saturday 28 May 2016 09:27:06 Neil Bothwick wrote:
> On Sat, 28 May 2016 09:08:10 +0100, Mick wrote:
> > I came across this blocker and I'm not sure how to overcome it:
> > ===
> > [ebuild  NS] kde-apps/kmix-15.12.3:5::gentoo
> > [4.14.3-r1:4/4.14::gentoo] USE="alsa -debug -pulseaudio" 381 KiB
> > [uninstall ] kde-apps/kmix-4.14.3-r1:4/4.14::gentoo  USE="alsa
> > handbook (- aqua) -canberra -debug -pulseaudio"
> > [blocks b  ] kde-apps/kmix:4 ("kde-apps/kmix:4" is blocking kde-
> > apps/kmix-15.12.3)
> > [ebuild  NS] kde-apps/kdemultimedia-meta-15.12.3:5::gentoo
> > [4.14.3:4::gentoo] USE="ffmpeg" 0 KiB
> > [uninstall ] kde-apps/kdemultimedia-meta-4.14.3:4::gentoo
> > USE="ffmpeg (- aqua) -mplayer"
> > [blocks b  ] kde-apps/kdemultimedia-meta:4 ("kde-apps/kdemultimedia-
> > meta:4" is blocking kde-apps/kdemultimedia-meta-15.12.3)
> > [blocks B  ] kde-base/baloo:4[-minimal(-)] ("kde-base/baloo:4[-
> > minimal(-)]" is blocking kde-frameworks/baloo-5.21.0)
> 
> Have you tried adding "kde-base/baloo minimal" to package.use?
> 
> There have been a few cases where a software combination means you end up
> with both KDE4 and KDE5 versions of a package as dependencies and the
> solution is usually to emerge the KDE4 version with USE="minimal".

Thank you Alan and Neil for your replies.  I have tried:

1. --backrack 90
2. Adding USE="minimal" to kde-base/baloo
3. Unmerging kde-base/baloo and running emerge -uaDv world.

but the clash remains.  On this box the user uses kmail, knotes, korganiser.  
I don't mind upgrading to the latest kde-frameworks equivalent, but I'd rather 
I stayed with stable packages as far as I can and I am not sure what the kde-
frameworks kdepim-meta equivalent is, unless portage tells me.

These are the dependencies equery shows for kdepim-common-libs:

# equery depends kdepim-common-libs
 * These packages depend on kdepim-common-libs:
kde-apps/akonadiconsole-4.14.10 (>=kde-apps/kdepim-common-
libs-4.14.10:4[aqua=])
kde-apps/akregator-4.14.10 (>=kde-apps/kdepim-common-libs-4.14.10:4[aqua=])
kde-apps/blogilo-4.14.10 (>=kde-apps/kdepim-common-libs-4.14.10:4[aqua=])
kde-apps/calendarjanitor-4.14.10 (>=kde-apps/kdepim-common-
libs-4.14.10:4[aqua=])
kde-apps/kaddressbook-4.14.10 (>=kde-apps/kdepim-common-libs-4.14.10:4[aqua=])
kde-apps/kalarm-4.14.10 (>=kde-apps/kdepim-common-libs-4.14.10:4[aqua=])
kde-apps/kdepim-kresources-4.14.10 (>=kde-apps/kdepim-common-
libs-4.14.10:4[aqua=])
kde-apps/kjots-4.14.10 (>=kde-apps/kdepim-common-libs-4.14.10:4[aqua=])
kde-apps/kleopatra-4.14.10 (>=kde-apps/kdepim-common-libs-4.14.10:4[aqua=])
kde-apps/kmail-4.14.10 (>=kde-apps/kdepim-common-libs-4.14.10:4[aqua=])
kde-apps/knode-4.14.10 (>=kde-apps/kdepim-common-libs-4.12.1-r1:4[aqua=])
kde-apps/knotes-4.14.10 (>=kde-apps/kdepim-common-libs-4.14.10:4[aqua=])
kde-apps/konsolekalendar-4.14.10 (>=kde-apps/kdepim-common-
libs-4.14.10:4[aqua=])
kde-apps/kontact-4.14.10 (>=kde-apps/kdepim-common-libs-4.14.10:4[aqua=])
kde-apps/korganizer-4.14.10 (>=kde-apps/kdepim-common-libs-4.14.10:4[aqua=])
kde-apps/ktimetracker-4.14.10 (>=kde-apps/kdepim-common-libs-4.14.10:4[aqua=])

-- 
Regards,
Mick

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

Re: [gentoo-user] kde-base/baloo is blocking an upgrade

[Neil Bothwick]

On Sat, 28 May 2016 09:08:10 +0100, Mick wrote:

> I came across this blocker and I'm not sure how to overcome it:
> ===
> [ebuild  NS] kde-apps/kmix-15.12.3:5::gentoo
> [4.14.3-r1:4/4.14::gentoo] USE="alsa -debug -pulseaudio" 381 KiB
> [uninstall ] kde-apps/kmix-4.14.3-r1:4/4.14::gentoo  USE="alsa
> handbook (- aqua) -canberra -debug -pulseaudio" 
> [blocks b  ] kde-apps/kmix:4 ("kde-apps/kmix:4" is blocking kde-
> apps/kmix-15.12.3)
> [ebuild  NS] kde-apps/kdemultimedia-meta-15.12.3:5::gentoo 
> [4.14.3:4::gentoo] USE="ffmpeg" 0 KiB
> [uninstall ] kde-apps/kdemultimedia-meta-4.14.3:4::gentoo
> USE="ffmpeg (- aqua) -mplayer" 
> [blocks b  ] kde-apps/kdemultimedia-meta:4 ("kde-apps/kdemultimedia-
> meta:4" is blocking kde-apps/kdemultimedia-meta-15.12.3)
> [blocks B  ] kde-base/baloo:4[-minimal(-)] ("kde-base/baloo:4[-
> minimal(-)]" is blocking kde-frameworks/baloo-5.21.0)

Have you tried adding "kde-base/baloo minimal" to package.use?

There have been a few cases where a software combination means you end up
with both KDE4 and KDE5 versions of a package as dependencies and the
solution is usually to emerge the KDE4 version with USE="minimal".


-- 
Neil Bothwick

Things which must be shipped together as a set, aren't.


pgpcxZv09STH6.pgp
Description: OpenPGP digital signature

Re: [gentoo-user] kde-base/baloo is blocking an upgrade

[Alan McKinnon]

On 28/05/2016 10:08, Mick wrote:
> I came across this blocker and I'm not sure how to overcome it:
> ===
> [ebuild  NS] kde-apps/kmix-15.12.3:5::gentoo [4.14.3-r1:4/4.14::gentoo] 
> USE="alsa -debug -pulseaudio" 381 KiB
> [uninstall ] kde-apps/kmix-4.14.3-r1:4/4.14::gentoo  USE="alsa handbook (-
> aqua) -canberra -debug -pulseaudio" 
> [blocks b  ] kde-apps/kmix:4 ("kde-apps/kmix:4" is blocking kde-
> apps/kmix-15.12.3)
> [ebuild  NS] kde-apps/kdemultimedia-meta-15.12.3:5::gentoo 
> [4.14.3:4::gentoo] USE="ffmpeg" 0 KiB
> [uninstall ] kde-apps/kdemultimedia-meta-4.14.3:4::gentoo  USE="ffmpeg (-
> aqua) -mplayer" 
> [blocks b  ] kde-apps/kdemultimedia-meta:4 ("kde-apps/kdemultimedia-
> meta:4" is blocking kde-apps/kdemultimedia-meta-15.12.3)
> [blocks B  ] kde-base/baloo:4[-minimal(-)] ("kde-base/baloo:4[-
> minimal(-)]" is blocking kde-frameworks/baloo-5.21.0)
> 
> Total: 142 packages (76 upgrades, 34 new, 31 in new slots, 1 reinstall, 28 
> uninstalls), Size of downloads: 123,018 KiB
> Conflict: 30 blocks (1 unsatisfied)
> 
> !!! Multiple package instances within a single package slot have been pulled
> !!! into the dependency graph, resulting in a slot conflict:
> 
> sys-process/procps:0
> 
>   (sys-process/procps-3.3.11-r3:0/5::gentoo, ebuild scheduled for merge) 
> pulled in by
> (no parents that aren't satisfied by other packages in this slot)
> 
>   (sys-process/procps-3.3.10-r1:0/0::gentoo, installed) pulled in by
> sys-process/procps:0/0= required by (dev-db/mysql-5.6.30:0/18::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. You may want to try a larger value of
> the --backtrack option, such as --backtrack=30, in order to see if
> that will solve this conflict automatically.
> 
> For more information, see MASKED PACKAGES section in the emerge man
> page or refer to the Gentoo Handbook.
> 
> 
>  * Error: The above package list contains packages which cannot be
>  * installed at the same time on the same system.
> 
>   (kde-frameworks/baloo-5.21.0:5/5.21::gentoo, ebuild scheduled for merge) 
> pulled in by
> >=kde-frameworks/baloo-5.21.0:5 required by (kde-
> apps/gwenview-15.12.3:5/5::gentoo, ebuild scheduled for merge)
> >=kde-frameworks/baloo-5.21.0:5 required by (kde-apps/dolphin-15.12.3-
> r1:5/5::gentoo, ebuild scheduled for merge)
> >=kde-frameworks/baloo-5.21.0:5 required by (kde-apps/baloo-
> widgets-15.12.3:5/5::gentoo, ebuild scheduled for merge)
> 
>   (kde-base/baloo-4.14.3:4/4.14::gentoo, installed) pulled in by
> >=kde-base/baloo-4.14.3:4[aqua=] (>=kde-base/baloo-4.14.3:4[-aqua]) 
> required by (kde-apps/kdepim-common-libs-4.14.10:4/4.14::gentoo, installed)
> ===
> 
> I also attach the complete output in case there is something evident in there 
> that I have missed.
> 

I think you're screwed, and kdepim is at the bottom of it.

gwenview dolphin require kde-frameworks/baloo
kdepim-common-libs requires kde-base/baloo

Those 2 versions of baloo are mutually incompatible, you have to let one
go or move onto whatever Frameworks offers to replace kdepim.

What bits of kdepim do you use?

equery depends kdepim-common-libs

rinse repeat till we get a clear view of the deps (or run emerge world
again with -t)


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

[gentoo-user] kde-base/baloo is blocking an upgrade

[Mick]

I came across this blocker and I'm not sure how to overcome it:
==[ebuild  NS] 
kde-apps/kmix-15.12.3:5::gentoo [4.14.3-r1:4/4.14::gentoo]
USE="alsa -debug -pulseaudio" 381 KiB
[uninstall ] kde-apps/kmix-4.14.3-r1:4/4.14::gentoo  USE="alsa handbook (-
aqua) -canberra -debug -pulseaudio"
[blocks b  ] kde-apps/kmix:4 ("kde-apps/kmix:4" is blocking kde-
apps/kmix-15.12.3)
[ebuild  NS] kde-apps/kdemultimedia-meta-15.12.3:5::gentoo
[4.14.3:4::gentoo] USE="ffmpeg" 0 KiB
[uninstall ] kde-apps/kdemultimedia-meta-4.14.3:4::gentoo  USE="ffmpeg (-
aqua) -mplayer"
[blocks b  ] kde-apps/kdemultimedia-meta:4 ("kde-apps/kdemultimedia-
meta:4" is blocking kde-apps/kdemultimedia-meta-15.12.3)
[blocks B  ] kde-base/baloo:4[-minimal(-)] ("kde-base/baloo:4[-
minimal(-)]" is blocking kde-frameworks/baloo-5.21.0)

Total: 142 packages (76 upgrades, 34 new, 31 in new slots, 1 reinstall, 28
uninstalls), Size of downloads: 123,018 KiB
Conflict: 30 blocks (1 unsatisfied)

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

sys-process/procps:0

  (sys-process/procps-3.3.11-r3:0/5::gentoo, ebuild scheduled for merge)
pulled in by
(no parents that aren't satisfied by other packages in this slot)

  (sys-process/procps-3.3.10-r1:0/0::gentoo, installed) pulled in by
sys-process/procps:0/0= required by (dev-db/mysql-5.6.30:0/18::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. You may want to try a larger value of
the --backtrack option, such as --backtrack0, in order to see if
that will solve this conflict automatically.

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


 * Error: The above package list contains packages which cannot be
 * installed at the same time on the same system.

  (kde-frameworks/baloo-5.21.0:5/5.21::gentoo, ebuild scheduled for merge)
pulled in by
>=kde-frameworks/baloo-5.21.0:5 required by (kde-
apps/gwenview-15.12.3:5/5::gentoo, ebuild scheduled for merge)
>=kde-frameworks/baloo-5.21.0:5 required by (kde-apps/dolphin-15.12.3-
r1:5/5::gentoo, ebuild scheduled for merge)
>=kde-frameworks/baloo-5.21.0:5 required by (kde-apps/baloo-
widgets-15.12.3:5/5::gentoo, ebuild scheduled for merge)

  (kde-base/baloo-4.14.3:4/4.14::gentoo, installed) pulled in by
>=kde-base/baloo-4.14.3:4[aqua=] (>=kde-base/baloo-4.14.3:4[-aqua])
required by (kde-apps/kdepim-common-libs-4.14.10:4/4.14::gentoo, installed)
==
I also attach the complete output in case there is something evident in there
that I have missed.
--
Regards,
Mick # emerge -uaDv world

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild U  ] app-arch/bzip2-1.0.6-r7::gentoo [1.0.6-r6::gentoo] 
USE="-static -static-libs" 764 KiB
[ebuild U  ] sys-apps/debianutils-4.7::gentoo [4.4::gentoo] USE="-static" 
153 KiB
[ebuild U  ] sys-apps/which-2.21::gentoo [2.20-r1::gentoo] 146 KiB
[ebuild  N ] dev-db/lmdb-0.9.18:0/0.9.18::gentoo  USE="-static-libs" 136 KiB
[ebuild U  ] sys-apps/file-5.25::gentoo [5.22::gentoo] USE="zlib -python 
-static-libs" PYTHON_TARGETS="python2_7 python3_4 (-pypy) -python3_3" 723 KiB
[ebuild U  ] sys-libs/cracklib-2.9.6::gentoo [2.9.1-r1::gentoo] USE="nls 
zlib -python -static-libs {-test}" PYTHON_TARGETS="python2_7" 628 KiB
[ebuild U  ] media-libs/libpng-1.6.21:0/16::gentoo [1.6.19:0/16::gentoo] 
USE="apng (-neon) -static-libs" 932 KiB
[ebuild U  ] sys-devel/m4-1.4.17::gentoo [1.4.16::gentoo] USE="-examples" 
1,123 KiB
[ebuild  N ] virtual/fortran-0::gentoo  USE="openmp" 0 KiB
[ebuild  N ] sci-libs/fftw-3.3.4:3.0/3::gentoo  USE="fortran openmp 
(-altivec) -doc -mpi (-neon) -quad -static-libs {-test} -threads (-zbus)" 
CPU_FLAGS_X86="sse sse2 -avx -fma3 -fma4" 3,849 KiB
[ebuild U  ] net-misc/iputils-20151218::gentoo [20121221-r1::gentoo] 
USE="filecaps ipv6 ssl -SECURITY_HAZARD -arping% -caps -clockdiff% -doc 
-gcrypt% -idn (-libressl) -rarpd% -rdisc% -static -tftpd% -tracepath% 
-traceroute% (-gnutls%)" 176 KiB
[ebuild U  ] media-libs/freetype-2.6.3-r1:2::gentoo [2.5.5:2::gentoo] 
USE="X adobe-cff bzip2 png -bindist -debug -doc -fontforge -harfbuzz 
-infinality -static-libs -utils (-auto-hinter%)" 1,712 KiB
[ebuild U  ] net-misc/curl-7.49.0::gentoo [7.45.0::gentoo] USE="ipv6 ssl 
-adns -http2 -idn -kerberos -ldap -metalink -rtmp -samba -ssh -static-libs 
{-test} 

Re: [gentoo-user] tablet

[Giampiero Gabbiani]

In data sabato 28 maggio 2016 14:03:16, Bill Kenworthy ha scritto:
> I was just about to spring for a mid range MS surface pro 4 tablet when
> I saw a few posts about hardware problems ... MS hardware is usually
> solid (in contrast to their software! :)
> 
> Are there any other similar tablets out there that are gentoo/Linux
> friendly that are worth looking at?
I have a surface pro and one surface pro 3, each of them purchased as soon 
as they appeared in Italy and all of them with Gentoo running since the very 
beginning.

Skipping the patches I had to apply initially for having all the HW working, 
currently in the pro 3 the running gentoo has a kernel 4.0.4 on which I retro 
applied the MS button module from a successive kernel release for the volume 
and power buttons to work and a patch for having both the cams working too.

If you need I can send them both.

I'm very satisfied with it (I have also the MS docking station) I use it for 
office and as DAW (with jackd)

Regards
Giampiero
> I have been using an old Samsung android tablet and google has just
> crossed the line and creeped me out past what I can tolerate so its time
> to move on  :(
> 
> BillK

[gentoo-user] tablet

[Bill Kenworthy]

I was just about to spring for a mid range MS surface pro 4 tablet when
I saw a few posts about hardware problems ... MS hardware is usually
solid (in contrast to their software! :)

Are there any other similar tablets out there that are gentoo/Linux
friendly that are worth looking at?

I have been using an old Samsung android tablet and google has just
crossed the line and creeped me out past what I can tolerate so its time
to move on  :(

BillK