[gentoo-user] KDE5 stuff and media-libs/mlt conflict

[Dale]

Howdy,

I was going to try out some of the KDE5 stuff just to see if I'm going
to like it or not.  Anyway, I added a BUNCH of stuff to a keywords file
related to KDE and got past that part.  I think I got them all.  Now I
get this:


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

Calculating dependencies... done!

!!! The ebuild selected to satisfy
">=media-libs/mlt-0.9.8-r1[ffmpeg,kdenlive,melt,qt5,sdl,xml]" has unmet
requirements.
- media-libs/mlt-0.9.8-r2::gentoo USE="ffmpeg frei0r gtk kde kdenlive
melt opengl python qt5 sdl xml -compressed-lumas -debug -fftw -jack
-libav -libsamplerate -lua -qt4 -rtaudio (-ruby) -vdpau -xine"
ABI_X86="64" CPU_FLAGS_X86="mmx sse sse2" PYTHON_TARGETS="python2_7"

  The following REQUIRED_USE flag constraints are unsatisfied:
kde? ( qt4 )

  The above constraints are a subset of the following complete expression:
python? ( python_targets_python2_7 ) qt5? ( !qt4 ) kde? ( qt4 )

(dependency required by "kde-apps/kdenlive-15.12.0-r1::gentoo" [ebuild])
(dependency required by "kde-apps/kdemultimedia-meta-15.08.3::gentoo"
[ebuild])
(dependency required by "=kde-apps/kdemultimedia-meta-15.08.3" [argument])
root@fireball / # 


There used to be more than that but I got rid of some by disabling qt4
on some packages in package.use.  It seems some can't handle both being
enabled so disabled it is for now.  Still, I can't figure out what
emerge is trying to tell me here.  I don't have a decoder ring but I
know a couple here do.  To try and get a idea on this for the future,
I'm going to ask this way. 

When it says kde?, what does that mean?  Does it want me to specify a
version or something?  I couldn't find a USE flag for a version of KDE,
just the plain kde flag. 

Before it had a !qt4 in the error.  I assume that ! means NO.  After I
disabled qt4 for the packages, that part of the error went away.  Am I
right on that or just lucky?  Keep in mind, I'm not even a script
kiddy.  :/ 

OK Alan and Neil.  Whip out your decoder ring.  What is this thing
trying to tell me.  lol

Dale

:-)  :-) 

[gentoo-user] Why sci-libs/vtk asks for media-video/nvidia-settings ?

[Francisco Ares]

Hi, and happy new year to all.

I have a not so old nvidia video board, but the recent closed source driver
complains, saying that I should stick to an earlier version:

x11-drivers/nvidia-drivers-340.93-r1 (it is recommended if I unmask it and
emerge a new one)

Then, in an excerpt from emerge -tpvuDN world:

...
[nomerge   ] media-gfx/freecad-0.15.4671::gentoo
 PYTHON_TARGETS="python2_7"
[nomerge   ]  sci-libs/opencascade-6.9.0:6.9.0::gentoo  USE="qt4 tbb
vtk -debug -doc -examples -freeimage -gl2ps -java"
[nomerge   ]   sci-libs/vtk-6.1.0-r1::gentoo  USE="X ffmpeg qt4 theora
-R -all-modules (-aqua) -boost -cg -doc (-examples) -gdal -imaging -java
-json -kaapi -mpi -mysql -odbc -offscreen -postgres -python -rendering -smp
-tbb -tcl {-test} -tk -views -web -xdmf2" PYTHON_TARGETS="python2_7"
VIDEO_CARDS="nvidia"
[ebuild  N ]media-video/nvidia-settings-340.58::gentoo
 USE="-examples" 0 KiB
...
...
[ebuild U  ]   media-libs/libjpeg-turbo-1.4.2::gentoo [1.3.1::gentoo]
USE="static-libs -java" ABI_X86="(64) -32 (-x32)" 0 KiB

Total: 10 packages (6 upgrades, 2 new, 3 reinstalls), Size of downloads: 0
KiB

WARNING: One or more updates/rebuilds have been skipped due to a dependency
conflict:

x11-drivers/nvidia-drivers:0

  (x11-drivers/nvidia-drivers-340.96:0/340::gentoo, ebuild scheduled for
merge) conflicts with
~x11-drivers/nvidia-drivers-340.93 required by
(media-video/nvidia-settings-340.58:0/0::gentoo, ebuild scheduled for merge)
^   ^^



What should I do?  Although not entirely satisfied in using a closed-source
driver, and as far as I know, the alternative xf86-video-nouveau isn't as
complete.

Any ideas?

Thanks a lot and best regards,
Francisco

Re: [gentoo-user] KDE5 stuff and media-libs/mlt conflict

[Dale]

Neil Bothwick wrote:
> On Tue, 5 Jan 2016 04:26:20 -0600, Dale wrote:
>
>> !!! The ebuild selected to satisfy
>> ">=media-libs/mlt-0.9.8-r1[ffmpeg,kdenlive,melt,qt5,sdl,xml]" has
>> unmet requirements.
>> - media-libs/mlt-0.9.8-r2::gentoo USE="ffmpeg frei0r gtk kde kdenlive
>> melt opengl python qt5 sdl xml -compressed-lumas -debug -fftw -jack
>> -libav -libsamplerate -lua -qt4 -rtaudio (-ruby) -vdpau -xine"
>> ABI_X86="64" CPU_FLAGS_X86="mmx sse sse2" PYTHON_TARGETS="python2_7"
>>
>>   The following REQUIRED_USE flag constraints are unsatisfied:
>> kde? ( qt4 )
> This says that if you have the kde flag enabled, you also need qt4.
>
>>   The above constraints are a subset of the following complete
>> expression: python? ( python_targets_python2_7 ) qt5? ( !qt4 ) kde?
>> ( qt4 )
> This says you can't have qt5 and qt4 plus the above about kde.
>
> It looks like the qt5 and kde USE flags are incompatible. Try with
> USE="-kde".
>
> Also, I have the -r2 ebuild in my portage tree but not -r1, so I suggest
> you sync before trying anything else.
>
>


I sort of thought about it that way but it didn't make sense.  How can I
have KDE and not a kde USE flag was my thinking.  After reading your
post, I found out it likes the profile set to plasma, currently #8 on
the list, instead of kde.  Changing the profile got rid of this error
and seems to have changed a few other things too.  All I'm looking at
now is a hard block on kde-apps/kde4-l10n-15.08.0-r1.  I will sync again
before actually starting the build. 

So, we have to change the profile setting to get to KDE5 as well. 
Interesting. 

Thanks.  You got me closer.  I'm doing all this in a separate file so
that I can revert easily too.  Since I have buildpkg set, it wouldn't
take long to undo.

Thanks much.

Dale

Re: [gentoo-user] Re: Difficulty fixing GLSA 201512-07 (gstreamer-0.10)

[Grant]

>> >> GLSA 201512-07 requires that I remove gstreamer-0.10 but I'm
>> >> finding it rather inextricable due to dependencies.  Has anyone
>> >> else run into this problem?
>> >
>> > I think this is another case of glsa-check not handling slots
>> > correctly.
>>
>> I believe it handles ranges fine, but it seems that we occasionally
>> have GLSAs that don't correctly specify ranges.  You can log a bug
>> against it.
>
> AFAICT, details of the gstreamer bug itself haven't been made public
> yet, and nobody is sure whether the unmaintained 0.10 branch needs a
> patch.  See  and
> the following comment.


So everyone is just living with the supposed security vulnerability on
their system?

- Grant

Re: [gentoo-user] KDE5 stuff and media-libs/mlt conflict

[Dale]

Peter Humphrey wrote:
> On Tuesday 05 January 2016 04:26:20 Dale wrote:
>> Howdy,
>>
>> I was going to try out some of the KDE5 stuff just to see if I'm going
>> to like it or not.  Anyway, I added a BUNCH of stuff to a keywords file
>> related to KDE and got past that part.  I think I got them all.  Now I
>> get this:
> --->8
>
> I was afraid to mess up my KDE4 system with KDE5 in some sort of parallel 
> fashion, so I found some spare disk space and installed KDE5 into it, using 
> the kde overlay and the .../desktop/plasma profile. It's much easier to 
> manage the two systems separately (dual-boot), and there's far less risk of 
> running, say, two versions of KMail on the same data [1]. I have all my 
> usual user's stuff in ~/common, a separate partition that's mounted on 
> whichever home partition is in use.
>
> There was a helpful web page somewhere too but I can't find it now - sorry 
> Dale.
>
> 1. I'm not saying the versions of KMail do differ, but they may later during 
> development of KDE5.
>


Since I install with kde-meta, kmail is installed here but I do not use
Kmail.  I use Seamonkey for my emails.  I haven't used Kmail is many
years. 

This info may be good for others to think about tho. 

Dale

:-)  :-) 

Re: [gentoo-user] emerging with distcc: What's taking so long?

[Jeremi Piotrowski]

On Tue, Jan 5, 2016 at 12:49 PM, lee  wrote:
> The gui monitor doesn't seem to exist.

Recompile distcc with the gtk use flag.

Re: [gentoo-user] KDE5 stuff and media-libs/mlt conflict

[lee]

Peter Humphrey  writes:

> On Tuesday 05 January 2016 04:26:20 Dale wrote:
>> Howdy,
>> 
>> I was going to try out some of the KDE5 stuff just to see if I'm going
>> to like it or not.  Anyway, I added a BUNCH of stuff to a keywords file
>> related to KDE and got past that part.  I think I got them all.  Now I
>> get this:
>
> --->8
>
> I was afraid to mess up my KDE4 system with KDE5 in some sort of parallel 
> fashion, so I found some spare disk space and installed KDE5 into it, using 
> the kde overlay and the .../desktop/plasma profile. It's much easier to 

How did you manage to install that?  I tried it yesterday (without the
overlays) and found it impossible to resolve the dependency problems, so
I ended up installing the 'normal' kde (I'm running out of time).  I'd
rather switch that over to plasma from the beginning.

Re: [gentoo-user] emerging with distcc: What's taking so long?

[Peter Humphrey]

On Tuesday 05 January 2016 14:18:12 lee wrote:

> Is there a way to offload the preprocessing to the server, and can
> compiling on localhost be avoided as much as possible somehow?

Try Neil's suggestion of using a chroot and NFS exporting. I use it here to 
good effect.

-- 
Rgds
Peter

Re: [gentoo-user] KDE5 stuff and media-libs/mlt conflict

[Peter Humphrey]

On Tuesday 05 January 2016 14:34:38 lee wrote:
> Peter Humphrey  writes:
> > On Tuesday 05 January 2016 04:26:20 Dale wrote:
> >> Howdy,
> >> 
> >> I was going to try out some of the KDE5 stuff just to see if I'm going
> >> to like it or not.  Anyway, I added a BUNCH of stuff to a keywords file
> >> related to KDE and got past that part.  I think I got them all.  Now I
> > 
> >> get this:
> > --->8
> > 
> > I was afraid to mess up my KDE4 system with KDE5 in some sort of
> > parallel
> > fashion, so I found some spare disk space and installed KDE5 into it,
> > using the kde overlay and the .../desktop/plasma profile. It's much
> > easier to
> How did you manage to install that?  I tried it yesterday (without the
> overlays) and found it impossible to resolve the dependency problems, so
> I ended up installing the 'normal' kde (I'm running out of time).  I'd
> rather switch that over to plasma from the beginning.

I found I needed the overlay. It greatly simplifies the dependencies. It 
still isn't perfect, as changes occur during development, but it's definitely 
well worth having.

Here's my current package.keywords:

~kde-frameworks/attica-5.17.0
~kde-frameworks/extra-cmake-modules-5.17.0
~kde-frameworks/kactivities-5.17.0
~kde-frameworks/karchive-5.17.0
~kde-frameworks/kauth-5.17.0
~kde-frameworks/kbookmarks-5.17.0
~kde-frameworks/kcmutils-5.17.0
~kde-frameworks/kcodecs-5.17.0
~kde-frameworks/kcompletion-5.17.0
~kde-frameworks/kconfig-5.17.0
~kde-frameworks/kconfigwidgets-5.17.0
~kde-frameworks/kcoreaddons-5.17.0
~kde-frameworks/kcrash-5.17.0
~kde-frameworks/kdbusaddons-5.17.0
~kde-frameworks/kdeclarative-5.17.0
~kde-frameworks/kded-5.17.0
~kde-frameworks/kdelibs4support-5.17.0
~kde-frameworks/kdesignerplugin-5.17.0
~kde-frameworks/kdoctools-5.17.0
~kde-frameworks/kemoticons-5.17.0
~kde-frameworks/kglobalaccel-5.17.0
~kde-frameworks/kguiaddons-5.17.0
~kde-frameworks/ki18n-5.17.0
~kde-frameworks/kiconthemes-5.17.0
~kde-frameworks/kinit-5.17.0
~kde-frameworks/kio-5.17.0
~kde-frameworks/kitemmodels-5.17.0
~kde-frameworks/kitemviews-5.17.0
~kde-frameworks/kjobwidgets-5.17.0
~kde-frameworks/knewstuff-5.17.0
~kde-frameworks/knotifications-5.17.0
~kde-frameworks/kpackage-5.17.0
~kde-frameworks/kparts-5.17.0
=kde-frameworks/plasma-5.17.0-r2
~kde-frameworks/kross-5.17.0
~kde-frameworks/krunner-5.17.0
~kde-frameworks/kservice-5.17.0
~kde-frameworks/ktextwidgets-5.17.0
~kde-frameworks/kunitconversion-5.17.0
~kde-frameworks/kwallet-5.17.0
~kde-frameworks/kwidgetsaddons-5.17.0
~kde-frameworks/kwindowsystem-5.17.0
~kde-frameworks/kxmlgui-5.17.0
~kde-frameworks/solid-5.17.0
~kde-frameworks/sonnet-5.17.0
~kde-frameworks/threadweaver-5.17.0

I've no doubt that after the next overlay update I'll have to add or remove 
some things.

Oh, and eix-update of the overlay takes huge lengths of time, so I do it 
less often than on my main system.

-- 
Rgds
Peter

Re: [gentoo-user] KDE5 stuff and media-libs/mlt conflict

[lee]

Peter Humphrey  writes:

> On Tuesday 05 January 2016 14:34:38 lee wrote:
>> Peter Humphrey  writes:
>> > On Tuesday 05 January 2016 04:26:20 Dale wrote:
>> >> Howdy,
>> >> 
>> >> I was going to try out some of the KDE5 stuff just to see if I'm going
>> >> to like it or not.  Anyway, I added a BUNCH of stuff to a keywords file
>> >> related to KDE and got past that part.  I think I got them all.  Now I
>> > 
>> >> get this:
>> > --->8
>> > 
>> > I was afraid to mess up my KDE4 system with KDE5 in some sort of
>> > parallel
>> > fashion, so I found some spare disk space and installed KDE5 into it,
>> > using the kde overlay and the .../desktop/plasma profile. It's much
>> > easier to
>> How did you manage to install that?  I tried it yesterday (without the
>> overlays) and found it impossible to resolve the dependency problems, so
>> I ended up installing the 'normal' kde (I'm running out of time).  I'd
>> rather switch that over to plasma from the beginning.
>
> I found I needed the overlay. It greatly simplifies the dependencies. It 
> still isn't perfect, as changes occur during development, but it's definitely 
> well worth having.
>
> Here's my current package.keywords:
> [...]
>
> I've no doubt that after the next overlay update I'll have to add or remove 
> some things.

It seemed to me that it's daring to try this because it's a work in
progress, and with the overly, it seemed to be even worse.  So I went
with the "normal" kde when I found out that plasma it doesn't work.
That's already painful to install.  Install on a slow machine, and you
can't even try much simply because it takes too long.

Should I try to upgrade?  That might take another day, which I don't
have ...

Re: [gentoo-user] Re: Difficulty fixing GLSA 201512-07 (gstreamer-0.10)

[waltdnes]

On Tue, Jan 05, 2016 at 06:36:06AM -0600, »Q« wrote

> I couldn't follow everything in the bug linked from c12;  I've been
> using Firefox latest with gstreamer-1.0 for a while without problems,
> but maybe that's because I don't use libav.
> 
> This probably won't affect Pale Moon at all, but Mozilla has gotten rid
> of gstreamer support in Firefox (not yet in released versions):
> 

  When I go to https://www.youtube.com/html5 it shows that my browser
(i.e. Pale Moon) supports HTMLVideoElement, H.264, and WebM VP8.  What
will removal of Gstreamer support from Firefox do?

-- 
Walter Dnes 
I don't run "desktop environments"; I run useful applications

Re: [gentoo-user] Re: Difficulty fixing GLSA 201512-07 (gstreamer-0.10)

[Neil Bothwick]

On Tue, 5 Jan 2016 08:26:42 -0800, Grant wrote:

> So everyone is just living with the supposed security vulnerability on
> their system?

It's not clear whether the vulnerability applies to 0.10 or not. I played
safe and uninstalled the only program depending on the 0.0 slot and then
depcleaned.


-- 
Neil Bothwick

God said, "div D = rho, div B = 0, curl E = - @B/@t, curl H = J + @D/@t,"
and there was light.


pgpP0TFyNOUum.pgp
Description: OpenPGP digital signature

Re: [gentoo-user] Why sci-libs/vtk asks for media-video/nvidia-settings ?

[Neil Bothwick]

On Tue, 5 Jan 2016 14:35:52 -0200, Francisco Ares wrote:

> What should I do?  Although not entirely satisfied in using a
> closed-source driver, and as far as I know, the alternative
> xf86-video-nouveau isn't as complete.

What's wrong with trying nouveau? It works fine for me but you can
always switch back if it doesn't suit you. 


-- 
Neil Bothwick

I distinctly remember forgetting that.


pgp_fNdEfulyF.pgp
Description: OpenPGP digital signature

Re: [gentoo-user] emerging with distcc: What's taking so long?

[lee]

Peter Humphrey  writes:

> On Tuesday 05 January 2016 14:18:12 lee wrote:
>
>> Is there a way to offload the preprocessing to the server, and can
>> compiling on localhost be avoided as much as possible somehow?
>
> Try Neil's suggestion of using a chroot and NFS exporting. I use it here to 
> good effect.

I must be missing his posting?

So export / via NFS, mount it on the server and chroot into it?  That
might not work because of the stupid multilib requirement:  The server
is no-multilib, the client is not.

Of course, I installed the client no-multilib and found that gnome
cannot be installed on no-multilib, so I had to reinstall.  Then I
decided to use KDE because I don't want systemd, and installing gnome
without it is a PITA.

However, I don't see why gnome --- or anything else --- should require
multilib.  It's not like I'd want to run anything 32bit.

Why are there no no-multilib profiles when you need a desktop profile?

It has taken two days now to install Gentoo, and it's still not finished
...

Re: [gentoo-user] emerging with distcc: What's taking so long?

[lee]

Jeremi Piotrowski  writes:

> On Tue, Jan 5, 2016 at 12:49 PM, lee  wrote:
>> The gui monitor doesn't seem to exist.
>
> Recompile distcc with the gtk use flag.

Oh, I thought that was an extra package ...

Re: [gentoo-user] emerging with distcc: What's taking so long?

[Neil Bothwick]

On Tue, 05 Jan 2016 18:41:25 +0100, lee wrote:

> > Try Neil's suggestion of using a chroot and NFS exporting. I use it
> > here to good effect.  
> 
> I must be missing his posting?

It's in the "QEMU/distcc combination question" thread, among other places.

> Of course, I installed the client no-multilib and found that gnome
> cannot be installed on no-multilib, so I had to reinstall.  Then I
> decided to use KDE because I don't want systemd, and installing gnome
> without it is a PITA.
> 
> However, I don't see why gnome --- or anything else --- should require
> multilib.  It's not like I'd want to run anything 32bit.

What about things like flash plugins? Those are often wanted on desktops
and need multilib.


-- 
Neil Bothwick

If only the good die young then what does that say about senior citizens?


pgpl6RcOwSQzT.pgp
Description: OpenPGP digital signature

Re: [gentoo-user] KDE5 stuff and media-libs/mlt conflict

[Neil Bothwick]

On Tue, 5 Jan 2016 22:23:22 +0200, Alan McKinnon wrote:

> /etc/portage/package.use/package.use:kde-apps/solid-runtime -bluetooth
> /etc/portage/package.unmask/package.unmask:kde-apps/print-manager

I take it you started to migrate to having /etc/portage/package.* as
directories and then got bored :)


-- 
Neil Bothwick

Better to understand a little than to misunderstand a lot.


pgpzemTrbhlky.pgp
Description: OpenPGP digital signature

Re: [gentoo-user] KDE5 stuff and media-libs/mlt conflict

[Alan McKinnon]

On 05/01/2016 19:26, Dale wrote:
> Neil Bothwick wrote:
>> On Tue, 5 Jan 2016 04:26:20 -0600, Dale wrote:
>>
>>> !!! The ebuild selected to satisfy
>>> ">=media-libs/mlt-0.9.8-r1[ffmpeg,kdenlive,melt,qt5,sdl,xml]" has
>>> unmet requirements.
>>> - media-libs/mlt-0.9.8-r2::gentoo USE="ffmpeg frei0r gtk kde kdenlive
>>> melt opengl python qt5 sdl xml -compressed-lumas -debug -fftw -jack
>>> -libav -libsamplerate -lua -qt4 -rtaudio (-ruby) -vdpau -xine"
>>> ABI_X86="64" CPU_FLAGS_X86="mmx sse sse2" PYTHON_TARGETS="python2_7"
>>>
>>>   The following REQUIRED_USE flag constraints are unsatisfied:
>>> kde? ( qt4 )
>> This says that if you have the kde flag enabled, you also need qt4.
>>
>>>   The above constraints are a subset of the following complete
>>> expression: python? ( python_targets_python2_7 ) qt5? ( !qt4 ) kde?
>>> ( qt4 )
>> This says you can't have qt5 and qt4 plus the above about kde.
>>
>> It looks like the qt5 and kde USE flags are incompatible. Try with
>> USE="-kde".
>>
>> Also, I have the -r2 ebuild in my portage tree but not -r1, so I suggest
>> you sync before trying anything else.
>>
>>
> 
> 
> I sort of thought about it that way but it didn't make sense.  How can I
> have KDE and not a kde USE flag was my thinking.  After reading your
> post, I found out it likes the profile set to plasma, currently #8 on
> the list, instead of kde.  Changing the profile got rid of this error
> and seems to have changed a few other things too.  All I'm looking at
> now is a hard block on kde-apps/kde4-l10n-15.08.0-r1.  I will sync again
> before actually starting the build. 

set USE=minimal for kde4-l10n. Set it individually for packages that
need it, not globally

Without it, there will be file collisions with the equivalent KDE5
packages. USE=minimal doesn't install those files leaving only those
needed for remaining kde4 apps to still work.

Anytime you have a blocker between similar kde4 and kde5 packages, try
set USE=minimal for the kde4 versions. Most times, that fixes it.

> 
> So, we have to change the profile setting to get to KDE5 as well. 
> Interesting. 

The profile sets a bunch of stuff that are pretty much required for KDE5
and Qt5, and most of it relates to plasma. It's either that or do a
bunch of icky stuff by hand
> 
> Thanks.  You got me closer.  I'm doing all this in a separate file so
> that I can revert easily too.  Since I have buildpkg set, it wouldn't
> take long to undo.
> 
> Thanks much.
> 
> Dale
> 
> 


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

Re: [gentoo-user] Re: Difficulty fixing GLSA 201512-07 (gstreamer-0.10)

[Alan McKinnon]

On 05/01/2016 20:43, waltd...@waltdnes.org wrote:
> On Tue, Jan 05, 2016 at 06:36:06AM -0600, »Q« wrote
> 
>> I couldn't follow everything in the bug linked from c12;  I've been
>> using Firefox latest with gstreamer-1.0 for a while without problems,
>> but maybe that's because I don't use libav.
>>
>> This probably won't affect Pale Moon at all, but Mozilla has gotten rid
>> of gstreamer support in Firefox (not yet in released versions):
>> 
> 
>   When I go to https://www.youtube.com/html5 it shows that my browser
> (i.e. Pale Moon) supports HTMLVideoElement, H.264, and WebM VP8.  What
> will removal of Gstreamer support from Firefox do?
> 

it will use something other than gstreamer to play content.

According to the mozilla bug quoted above, gstreamer was removed from
firefox as everything that used it was gone

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

[gentoo-user] apache SSL error

[thelma]

I changed in apache: 00_default_ssl_vhost.conf

SSLProtocol ALL -SSLv2 -SSLv3
SSLHonorCipherOrder on
SSLCipherSuite 
EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:ECDHE-RSA-AES128-SHA:DHE-RSA-AES128-GCM-SHA256:AES256+EDH:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DH$

and now apache will not start. Error:
Unable to configure permitted SSL ciphers
error] SSL Library Error: 151441516 error:0906D06C:PEM routines:PEM_read_bio:no 
start line Bad file contents or format - or even just a forgotten 
SSLCertificateKeyFile?
[error] SSL Library Error: 151441516 error:0906D06C:PEM 
routines:PEM_read_bio:no start line Bad file contents or format - or even just 
a forgotten SSLCertificateKeyFile?
[error] SSL Library Error: 336486680 error:140E6118:SSL 
routines:SSL_CIPHER_PROCESS_RULESTR:invalid command


I re-emerge dev-libs/openssl 
but it deosn't help. Which one I need to re-emerge? 

-- 
Thelma

Re: [gentoo-user] apache SSL error

[thelma]

On 01/05/2016 08:45 PM, the...@sys-concept.com wrote:
> I changed in apache: 00_default_ssl_vhost.conf
> 
> SSLProtocol ALL -SSLv2 -SSLv3
> SSLHonorCipherOrder on
> SSLCipherSuite 
> EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:ECDHE-RSA-AES128-SHA:DHE-RSA-AES128-GCM-SHA256:AES256+EDH:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DH$
> 
> and now apache will not start. Error:
> Unable to configure permitted SSL ciphers
> error] SSL Library Error: 151441516 error:0906D06C:PEM 
> routines:PEM_read_bio:no start line Bad file contents or format - or even 
> just a forgotten SSLCertificateKeyFile?
> [error] SSL Library Error: 151441516 error:0906D06C:PEM 
> routines:PEM_read_bio:no start line Bad file contents or format - or even 
> just a forgotten SSLCertificateKeyFile?
> [error] SSL Library Error: 336486680 error:140E6118:SSL 
> routines:SSL_CIPHER_PROCESS_RULESTR:invalid command
> 
> 
> I re-emerge dev-libs/openssl 
> but it deosn't help. Which one I need to re-emerge? 

Fixed, I didn't copy correctly the "SSLCipherSuite..."

Re: [gentoo-user] snapshots?

[lee]

Rich Freeman  writes:

> On Fri, Jan 1, 2016 at 5:42 AM, lee  wrote:
>> "Stefan G. Weichinger"  writes:
>>
>>> btrfs offers RAID-like redundancy as well, no mdadm involved here.
>>>
>>> The general recommendation now is to stay at level-1 for now. That fits
>>> your 2-disk-situation.
>>
>> Well, what shows better performance?  No btrfs-raid on hardware raid or
>> btrfs raid on JBOD?
>
> I would run btrfs on bare partitions and use btrfs's raid1
> capabilities.  You're almost certainly going to get better
> performance, and you get more data integrity features.

That would require me to set up software raid with mdadm as well, for
the swap partition.

> If you have a silent corruption with mdadm doing the raid1 then btrfs
> will happily warn you of your problem and you're going to have a
> really hard time fixing it,

BTW, what do you do when you have silent corruption on a swap partition?
Is that possible, or does swapping use its own checksums?

> [...]
>
>>>
>>> I would avoid converting and stuff.
>>>
>>> Why not try a fresh install on the new disks with btrfs?
>>
>> Why would I want to spend another year to get back to where I'm now?
>
> I wouldn't do a fresh install.  I'd just set up btrfs on the new disks
> and copy your data over (preserving attributes/etc).

That was the idea.

> I wouldn't do an in-place ext4->btrfs conversion.  I know that there
> were some regressions in that feature recently and I'm not sure where
> it stands right now.

That adds to the uncertainty of btrfs.


> [...]
>>
>> There you go, you end up with an odd setup.  I don't like /boot
>> partitions.  As well as swap partitions, they need to be on raid.  So
>> unless you use hardware raid, you end up with mdadm /and/ btrfs /and/
>> perhaps ext4, /and/ multiple partitions.
>
> [...]
> There isn't really anything painful about that setup though.

It's still odd.  I already have two different file systems and the
overhead of one kind of software raid while I would rather stick to one
file system.  With btrfs, I'd still have two different file systems ---
plus mdadm and the overhead of three different kinds of software raid.

How would it be so much better to triple the software raids and to still
have the same number of file systems?

>> When you use hardware raid, it
>> can be disadvantageous compared to btrfs-raid --- and when you use it
>> anyway, things are suddenly much more straightforward because everything
>> is on raid to begin with.
>
> I'd stick with mdadm.  You're never going to run mixed
> btrfs/hardware-raid on a single drive,

A single disk doesn't make for a raid.

> and the only time I'd consider
> hardware raid is with a high quality raid card.  You'd still have to
> convince me not to use mdadm even if I had one of those lying around.

>From my own experience, I can tell you that mdadm already does have
significant overhead when you use a raid1 of two disks and a raid5 with
three disks.  This overhead may be somewhat due to the SATA controller
not being as capable as one would expect --- yet that doesn't matter
because one thing you're looking at, besides reliability, is the overall
performance.  And the overall performance very noticeably increased when
I migrated from mdadm raids to hardware raids, with the same disks and
the same hardware, except that the raid card was added.

And that was only 5 disks.  I also know that the performance with a ZFS
mirror with two disks was disappointingly poor.  Those disks aren't
exactly fast, but still.  I haven't tested yet if it changed after
adding 4 mirrored disks to the pool.  And I know that the performance of
another hardware raid5 with 6 disks was very good.

Thus I'm not convinced that software raid is the way to go.  I wish they
would make hardware ZFS (or btrfs, if it ever becomes reliable)
controllers.

Now consider:


+ candidates for hardware raid are two small disks (72GB each)
+ data on those is either mostly read, or temporary/cache-like
+ this setup works without any issues for over a year now
+ using btrfs would triple the software raids used
+ btrfs is uncertain, reliability questionable
+ mdadm would have to be added as another layer of complexity
+ the disks are SAS disks, genuinely made to be run in a hardware raid
+ the setup with hardware raid is straightforward and simple, the setup
  with btrfs is anything but


The relevant advantage of btrfs is being able to make snapshots.  Is
that worth all the (potential) trouble?  Snapshots are worthless when
the file system destroys them with the rest of the data.

> [...]
>> How's btrfs's performance when you use swap files instead of swap
>> partitions to avoid the need for mdadm?
>
> btrfs does not support swap files at present.

What happens when you try it?

> When it does you'll need to disable COW for them (using chattr)
> otherwise they'll be fragmented until your system grinds to a halt.  A
> swap file is about the worst case scenario for any 

Re: [gentoo-user] KDE5 stuff and media-libs/mlt conflict

[Alan McKinnon]

On 05/01/2016 22:57, Neil Bothwick wrote:
> On Tue, 5 Jan 2016 22:23:22 +0200, Alan McKinnon wrote:
> 
>> /etc/portage/package.use/package.use:kde-apps/solid-runtime -bluetooth
>> /etc/portage/package.unmask/package.unmask:kde-apps/print-manager
> 
> I take it you started to migrate to having /etc/portage/package.* as
> directories and then got bored :)
> 
> 


Something like that. package.*/package.* is for permanent stuff.
If I use a separate file it's just temporary and for testing

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

Re: [gentoo-user] KDE5 stuff and media-libs/mlt conflict

[Alan McKinnon]

On 05/01/2016 21:55, Dale wrote:
> Dale wrote:
>> Howdy,
>>
>> I was going to try out some of the KDE5 stuff just to see if I'm going
>> to like it or not.  Anyway, I added a BUNCH of stuff to a keywords file
>> related to KDE and got past that part.  I think I got them all.  Now I
>> get this:
>>
>>
>> <<<  SNIP >>>
>>
>> OK Alan and Neil.  Whip out your decoder ring.  What is this thing
>> trying to tell me.  lol
>>
>> Dale
>>
>> :-)  :-) 
>>
>>
> 
> 
> OK.  After fixing one thing, I run into something else.  I removed the
> blocker yet it still complains about the blocker, even tho it is
> removed, and adds another if I read it right..  It seems that maybe this
> is going to take more time than I am willing to give it right now. 
> Maybe later on when the kinks get worked out I'll give it another shot. 
> Right now, it's just not worth all the effort and time to mess with it. 
> 
> Thanks to all. 
> 
> Dale
> 
> :-)  :-) 
> 

This works for me. I don't use the KDE overlay, just what's in the
regular tree. Apps appear and upgrade to KDE5 as the devs migrate them.

I found that the overlay left me with quite a few apps that don't work
with Qt5 so I'd have to jump through hoops to get the Qt4 version from
the tree to install. With the tree it's a case of what works with KDE5
is installed, everything else remains KDE4

# grep -r kde /etc/portage/
/etc/portage/make.conf: kde
/etc/portage/package.use/package.use:kde-plasma/kde-gtk-config gtk3
/etc/portage/package.use/package.use:kde-plasma/plasma-desktop touchpad
/etc/portage/package.use/package.use:kde-plasma/plasma-meta mediacenter
/etc/portage/package.use/package.use:media-libs/mlt kdenlive -kde melt
/etc/portage/package.use/package.use:kde-apps/kde-wallpapers minimal
/etc/portage/package.use/package.use:kde-apps/kde4-l10n minimal
/etc/portage/package.use/package.use:kde-apps/kdeartwork-meta minimal
/etc/portage/package.use/package.use:=kde-apps/kdebase-kioslaves-4* minimal
/etc/portage/package.use/package.use:kde-apps/kdebase-runtime-meta minimal
/etc/portage/package.use/package.use:=kde-apps/konsole-4* minimal
/etc/portage/package.use/package.use:=kde-apps/kwalletmanager-4* minimal
/etc/portage/package.use/package.use:=kde-base/baloo-4* minimal
/etc/portage/package.use/package.use:=kde-base/kactivities-4* minimal
/etc/portage/package.use/package.use:kde-apps/kdesu -handbook
/etc/portage/package.use/package.use:kde-apps/knetattach -handbook
/etc/portage/package.use/package.use:kde-plasma/plasma-desktop gtk2 gtk3
qt4 legacy-systray
runtime-meta-4.14.3
/etc/portage/package.use/package.use:kde-apps/solid-runtime -bluetooth
/etc/portage/package.unmask/package.unmask:kde-apps/print-manager


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

Re: [gentoo-user] KDE5 stuff and media-libs/mlt conflict

[Neil Bothwick]

On Tue, 5 Jan 2016 04:26:20 -0600, Dale wrote:

> !!! The ebuild selected to satisfy
> ">=media-libs/mlt-0.9.8-r1[ffmpeg,kdenlive,melt,qt5,sdl,xml]" has
> unmet requirements.
> - media-libs/mlt-0.9.8-r2::gentoo USE="ffmpeg frei0r gtk kde kdenlive
> melt opengl python qt5 sdl xml -compressed-lumas -debug -fftw -jack
> -libav -libsamplerate -lua -qt4 -rtaudio (-ruby) -vdpau -xine"
> ABI_X86="64" CPU_FLAGS_X86="mmx sse sse2" PYTHON_TARGETS="python2_7"
> 
>   The following REQUIRED_USE flag constraints are unsatisfied:
> kde? ( qt4 )

This says that if you have the kde flag enabled, you also need qt4.

>   The above constraints are a subset of the following complete
> expression: python? ( python_targets_python2_7 ) qt5? ( !qt4 ) kde?
> ( qt4 )

This says you can't have qt5 and qt4 plus the above about kde.

It looks like the qt5 and kde USE flags are incompatible. Try with
USE="-kde".

Also, I have the -r2 ebuild in my portage tree but not -r1, so I suggest
you sync before trying anything else.


-- 
Neil Bothwick

Always remember to pillage before you burn.


pgpsbUaTC6RIU.pgp
Description: OpenPGP digital signature

Re: [gentoo-user] KDE5 stuff and media-libs/mlt conflict

[Peter Humphrey]

On Tuesday 05 January 2016 04:26:20 Dale wrote:
> Howdy,
> 
> I was going to try out some of the KDE5 stuff just to see if I'm going
> to like it or not.  Anyway, I added a BUNCH of stuff to a keywords file
> related to KDE and got past that part.  I think I got them all.  Now I
> get this:

--->8

I was afraid to mess up my KDE4 system with KDE5 in some sort of parallel 
fashion, so I found some spare disk space and installed KDE5 into it, using 
the kde overlay and the .../desktop/plasma profile. It's much easier to 
manage the two systems separately (dual-boot), and there's far less risk of 
running, say, two versions of KMail on the same data [1]. I have all my 
usual user's stuff in ~/common, a separate partition that's mounted on 
whichever home partition is in use.

There was a helpful web page somewhere too but I can't find it now - sorry 
Dale.

1. I'm not saying the versions of KMail do differ, but they may later during 
development of KDE5.

-- 
Rgds
Peter

Re: [gentoo-user] emerging with distcc: What's taking so long?

[lee]

Frank Steinmetzger  writes:

> On Mon, Jan 04, 2016 at 04:38:56PM -0600, Dale wrote:
>
>> >>> what's taking so long when emerging packages despite distcc is used?
>> >>> […]
>> >>> Some compilations are being run on the remote machine, so distcc does
>> >>> work.  The log file on the remote machine shows compilation times of a
>> >>> few milliseconds up to about 1.5 seconds at most.  The distcc server
>> >>> would be finished with the emerging within maybe 15 minutes, and the
>> >>> client takes several hours already.
>> >>>
>> >>> Is there something going wrong?  Is there a way to speed things up as
>> >>> much as I would expect from using distcc?
>> > […]
>> > Can it be that the client is simply too slow compared to the server to
>> > give it any significant load?  (The client isn't exactly slow; it's slow
>> > compared to the server.)
>>
>> Once a really long time ago I tried doing this sort of thing.  What I
>> found is that the network speed between the two systems was what was
>> slowing it down.  It just couldn't transfer the data back and forth fast
>> enough.  I had a network card that really didn't have any good drivers
>> for it.  Anyway, it may not be your problem but it may be worth looking
>> at to be sure.  Using iftop or some similar tool should tell you
>> something.
>
> Well I’m using distcc over WiFi which gives me shy of 2 MB per second (only
> the big PC which acts as server is connected to the router via cable). For
> such cases I recommend using compression. It definitely increased throughput.

Wireless is a bad crutch which is only useful when it's entirely
impossible to use a cable.  I'd recommend using a cable, especially in
this case where the CPU is already compiling so slow.

Dale, thanks for the suggestion --- the network is fine and transfers
about 100MB/sec+.

> What I observe on my setup, though, is that sometimes a package builds with
> distcc, and then all of a sudden I get (the meaning of) “distributing via
> distcc failed, building locally” and after a while it works again. No idea
> what’s going on there.

The server might be busy, or it's not possible to compile remotely.

Re: [gentoo-user] emerging with distcc: What's taking so long?

[lee]

 writes:

> lee  wrote:
>
>>  writes:
>> 
>> > lee  wrote:
>> >
>> >> Hi,
>> >> 
>> >> what's taking so long when emerging packages despite distcc is
>> >> used?
> [...]
>> Can it be that the client is simply too slow compared to the server to
>> give it any significant load?  (The client isn't exactly slow; it's
>> slow compared to the server.)
>
> I used a pentium 4 laptop as client and two phenom2 quadcore pc as 
> server. I don't remember the settings that I used but I think it
> was something about -j10 or so.
>
> When I compiled large programs, the load count of the servers was
> high most of the time and they were very busy with compiling. Only
> at linking time they were waiting for new data.
> Compilation time was much lower than without distcc.

The load average only goes high on the client.  The server is too fast
to notice.

> However when I compiled small programs, the benefit of distcc was 
> very small or even null. Also compilation time of OpenOffice was
> very long, because of the -j1 setting in the ebuild.

I haven't emerged libreoffice yet --- that might take very long.

> I don't know the reason of your problem. Maybe you should try it
> without pump mode to see if this makes a difference.

Hm, that's worth a try.

> Have you used distccmon to see what happens while compiling? IIRC
> it shows you exactly what's going on at each host (preprocessing,
> compiling, waiting). Maybe this will bring some light into the 
> whole thing.

It doesn't show anything but blank lines --- it might compile too fast
for anything to show up.  I can see in /var/log/messages that things are
being compiled, like this:


distccd[29727]: (dcc_job_summary) client: 192.168.3.33:38604 COMPILE_OK
exit:0 sig:0 core:0 ret:0 time:372ms x86_64-pc-linux-gnu-g++ drvvtk.cpp


The gui monitor doesn't seem to exist.

Re: [gentoo-user] emerging with distcc: What's taking so long?

[lee]

 writes:

> Frank Steinmetzger  wrote:
>
>> On Mon, Jan 04, 2016 at 09:48:42PM +0100, waben...@gmail.com wrote:
>> 
>> > P.S.: distccmon is a good tool to watch the compilation processes.
>> 
>> I never got it to display anything. I just tried it again: synced
>> portage and ran a world update -- 16 Packages, among them
>> kdevplatform, a lengthy Qt package (which by the way is one of those
>> who benefit greatly from compression if distcc’ed over a slow
>> network).
>> 
>> At no time during building did I see any activity in distccmon-gui. I
>> started it on both client and server and as my own user as well as
>> root. Nada. Can you give a suggestion? Thanks.
>> 
>
> I remembered something:
>
> It is important to use the same value for the DISTCC_DIR environment 
> variable as the user running the client and that this directory is 
> readable by the user that is running distccmon. 

Hm.  Are you saying you can run it only on the client?

Oh, I can see it now!  Preprocessing seems to be done on localhost only,
and some compilation, too.  Some is compiled on the server.

I tried to remove 'distcc' and leaving only 'distcc-pump' in make.conf
to force preprocessing to the server.  With that, nothing shows up.

Is there a way to offload the preprocessing to the server, and can
compiling on localhost be avoided as much as possible somehow?

Re: [gentoo-user] emerging with distcc: What's taking so long?

[lee]

Frank Steinmetzger  writes:

> On Mon, Jan 04, 2016 at 09:48:42PM +0100, waben...@gmail.com wrote:
>
>> P.S.: distccmon is a good tool to watch the compilation processes.
>
> I never got it to display anything. I just tried it again: synced portage
> and ran a world update -- 16 Packages, among them kdevplatform, a lengthy
> Qt package (which by the way is one of those who benefit greatly from
> compression if distcc’ed over a slow network).
>
> At no time during building did I see any activity in distccmon-gui. I
> started it on both client and server and as my own user as well as root.
> Nada. Can you give a suggestion? Thanks.

I've set log level to 'notice' and can see messages in
/var/log/messages.  distccmon-gui doesn't seem to exist, and nothing
shows up with distccmon-txt.

Re: [gentoo-user] emerging with distcc: What's taking so long?

[lee]

 writes:

>  wrote:
>
>> 
>> I used a pentium 4 laptop as client and two phenom2 quadcore pc as 
>> server. I don't remember the settings that I used but I think it
>> was something about -j10 or so.
>
> Sorry, I think it was about -j16 (twice the totally amount of CPUs).

The wiki says to use twice CPUs plus 1.  That's 57 here.  That should be
fast.  I could add more servers and bring it up to -j81, but since the
server is pretty much idle, that won't help.

Re: [gentoo-user] KDE5 stuff and media-libs/mlt conflict

[Dale]

Dale wrote:
> Howdy,
>
> I was going to try out some of the KDE5 stuff just to see if I'm going
> to like it or not.  Anyway, I added a BUNCH of stuff to a keywords file
> related to KDE and got past that part.  I think I got them all.  Now I
> get this:
>
>
> <<<  SNIP >>>
>
> OK Alan and Neil.  Whip out your decoder ring.  What is this thing
> trying to tell me.  lol
>
> Dale
>
> :-)  :-) 
>
>


OK.  After fixing one thing, I run into something else.  I removed the
blocker yet it still complains about the blocker, even tho it is
removed, and adds another if I read it right..  It seems that maybe this
is going to take more time than I am willing to give it right now. 
Maybe later on when the kinks get worked out I'll give it another shot. 
Right now, it's just not worth all the effort and time to mess with it. 

Thanks to all. 

Dale

:-)  :-) 

Re: [gentoo-user] snapshots?

[Neil Bothwick]

On Tue, 05 Jan 2016 23:16:48 +0100, lee wrote:

> > I would run btrfs on bare partitions and use btrfs's raid1
> > capabilities.  You're almost certainly going to get better
> > performance, and you get more data integrity features.  
> 
> That would require me to set up software raid with mdadm as well, for
> the swap partition.

There's no need to use RAID for swap, it's not like it contains anything
of permanent importance. Create a swap partition on each disk and let
the kernel use the space as it wants.
 
> The relevant advantage of btrfs is being able to make snapshots.  Is
> that worth all the (potential) trouble?  Snapshots are worthless when
> the file system destroys them with the rest of the data.

You forgot the data checksumming. If you use hardware RAID then btrfs
only sees a single disk. It can still warn you of corrupt data but it
cannot fix it because it only has the one copy.

> Well, then they need to make special provisions for swap files in btrfs
> so that we can finally get rid of the swap partitions.

I think there are more important priorities, its not like having a swap
partition or two is a hardship or limitation.


-- 
Neil Bothwick

Being politically correct means always having to say you're sorry.


pgpnzPE5AweUW.pgp
Description: OpenPGP digital signature

Re: [gentoo-user] snapshots?

[Rich Freeman]

On Tue, Jan 5, 2016 at 6:01 PM, Neil Bothwick  wrote:
> On Tue, 05 Jan 2016 23:16:48 +0100, lee wrote:
>
>> > I would run btrfs on bare partitions and use btrfs's raid1
>> > capabilities.  You're almost certainly going to get better
>> > performance, and you get more data integrity features.
>>
>> That would require me to set up software raid with mdadm as well, for
>> the swap partition.
>
> There's no need to use RAID for swap, it's not like it contains anything
> of permanent importance. Create a swap partition on each disk and let
> the kernel use the space as it wants.

So, while I tend not to run swap on RAID, it isn't an uncommon
approach because if you don't put swap on raid and you have a drive
failure while the system is running, then you are likely to have a
kernel panic.  Since one of the main goals of RAID is availability, it
is logical to put swap on RAID.

It is a risk thing.  If your system going down suddenly with no loss
to data in your regular filesystems isn't a huge problem (maybe this
is Google's 10,000th read-only caching server) then by all means don't
put swap on RAID.

The important thing is to understand the risks and make an informed decision.

-- 
Rich

Re: [gentoo-user] snapshots?

[Rich Freeman]

On Tue, Jan 5, 2016 at 5:16 PM, lee  wrote:
> Rich Freeman  writes:
>
>>
>> I would run btrfs on bare partitions and use btrfs's raid1
>> capabilities.  You're almost certainly going to get better
>> performance, and you get more data integrity features.
>
> That would require me to set up software raid with mdadm as well, for
> the swap partition.

Correct, if you don't want a panic if a single swap drive fails.

>
>> If you have a silent corruption with mdadm doing the raid1 then btrfs
>> will happily warn you of your problem and you're going to have a
>> really hard time fixing it,
>
> BTW, what do you do when you have silent corruption on a swap partition?
> Is that possible, or does swapping use its own checksums?

If the kernel pages in data from the good mirror, nothing happens.  If
the kernel pages in data from the bad mirror, then whatever data
happens to be there is what will get loaded and used and/or executed.
If you're lucky the modified data will be part of unused heap or
something.  If not, well, just about anything could happen.

Nothing in this scenario will check that the data is correct, except
for a forced scrub of the disks.  A scrub would probably detect the
error, but I don't think mdadm has any ability to recover it.  Your
best bet is probably to try to immediately reboot and save what you
can, or a less-risky solution assuming you don't have anything
critical in RAM is to just do an immediate hard reset so that there is
no risk of bad data getting swapped in and overwriting good data on
your normal filesystems.

> It's still odd.  I already have two different file systems and the
> overhead of one kind of software raid while I would rather stick to one
> file system.  With btrfs, I'd still have two different file systems ---
> plus mdadm and the overhead of three different kinds of software raid.

I'm not sure why you'd need two different filesystems.  Just btrfs for
your data.  I'm not sure where you're counting three types of software
raid either - you just have your swap.  And I don't think any of this
involves any significant overhead, other than configuration.

>
> How would it be so much better to triple the software raids and to still
> have the same number of file systems?

Well, the difference would be more data integrity insofar as hardware
failure goes, but certainly more risk of logical errors (IMO).

>
>>> When you use hardware raid, it
>>> can be disadvantageous compared to btrfs-raid --- and when you use it
>>> anyway, things are suddenly much more straightforward because everything
>>> is on raid to begin with.
>>
>> I'd stick with mdadm.  You're never going to run mixed
>> btrfs/hardware-raid on a single drive,
>
> A single disk doesn't make for a raid.

You misunderstood my statement.  If you have two drives, you can't run
both hardware raid and btrfs raid across them.  Hardware raid setups
don't generally support running across only part of a drive, and in
this setup you'd have to run hardware raid on part of each of two
single drives.

>
>> and the only time I'd consider
>> hardware raid is with a high quality raid card.  You'd still have to
>> convince me not to use mdadm even if I had one of those lying around.
>
> From my own experience, I can tell you that mdadm already does have
> significant overhead when you use a raid1 of two disks and a raid5 with
> three disks.  This overhead may be somewhat due to the SATA controller
> not being as capable as one would expect --- yet that doesn't matter
> because one thing you're looking at, besides reliability, is the overall
> performance.  And the overall performance very noticeably increased when
> I migrated from mdadm raids to hardware raids, with the same disks and
> the same hardware, except that the raid card was added.

Well, sure, the raid card probably had battery-backed cache if it was
decent, so linux could complete its commits to RAM and not have to
wait for the disks.

>
> And that was only 5 disks.  I also know that the performance with a ZFS
> mirror with two disks was disappointingly poor.  Those disks aren't
> exactly fast, but still.  I haven't tested yet if it changed after
> adding 4 mirrored disks to the pool.  And I know that the performance of
> another hardware raid5 with 6 disks was very good.

You're probably going to find the performance of a COW filesystem to
be inferior to that of an overwrite-in-place filesystem, simply
because the latter has to do less work.

>
> Thus I'm not convinced that software raid is the way to go.  I wish they
> would make hardware ZFS (or btrfs, if it ever becomes reliable)
> controllers.

I doubt it would perform any better.  What would that controller do
that your CPU wouldn't do?  Well, other than have battery-backed
cache, which would help in any circumstance.  If you stuck 5 raid
cards in your PC and put one drive on each card and put mdadm or ZFS
across all five it would almost certainly perform better because
you're 

[gentoo-user] Re: Difficulty fixing GLSA 201512-07 (gstreamer-0.10)

[»Q«]

On Mon, 4 Jan 2016 14:09:17 -0500
waltd...@waltdnes.org wrote:

> On Mon, Jan 04, 2016 at 11:20:57AM -0600, »Q« wrote
> 
> > AFAICT, details of the gstreamer bug itself haven't been made public
> > yet, and nobody is sure whether the unmaintained 0.10 branch needs a
> > patch.  See  and
> > the following comment.  
> 
>   As pointed out in comment 12 of that bug, 1.x broke the 0.10.x
> ABI/API and causes problems on Firefox.  I use Pale Moon, a Firefox
> fork, and it too will only build with gstreamer 0.10.x.

I couldn't follow everything in the bug linked from c12;  I've been
using Firefox latest with gstreamer-1.0 for a while without problems,
but maybe that's because I don't use libav.

This probably won't affect Pale Moon at all, but Mozilla has gotten rid
of gstreamer support in Firefox (not yet in released versions):

Re: [gentoo-user] Re: OT - Midnight Commander and hiding terminal output

[Håkon Alstadheim]

Den 03. jan. 2016 16:56, skrev Skippy:
>
> On 01/02/2016 12:38 AM, Håkon Alstadheim wrote:
>> Den 01. jan. 2016 00:49, skrev Linux:
>>> On 12/30/2015 10:32 AM, Roman Dobosz wrote:
>>>
>>> snip
>>   Should be as easy as hitting Ctrl-L when your screen is messed up,
>> should it not? Don't use MC, so haven't tried it. If it does not work,
>> look in manual for key-binding for "redraw" .
>>
> I didn't know about ctrl-L. Sure enough that works as well.
> Thank you.  Good work around until I fix it otherwise.
> Skippy
>
>

ctrl-L (C-l for short)  is old standard terminal key-binding, sending an
actual control-character. Control-characters are like their regular
counterparts but with a numeric value 0x40 less. Others that you
probably know are C-c (0x03, break) , C-d, C-/ . More obscure are C-s
(aka XOFF) to suspend terminal output, and C-q (aka XON) to continue
output. All these are control-characters used forever on unix terminals.

Also fairly standard C-h (backspace) C-p (previous) C-n (next). C-j is
synonym for carriage return aka \r, C-m is line-feed aka \n. Good to
know when keyboard mappings get screwed up.

In this context C-l is actually sending page-break control-character,
which will usually redraw the terminal window, unless the app decides to
use it for something else.

These control-codes can be seen in an acii table, they are the first ten
code-points.

Re: [gentoo-user] Getting rid of cups and physical printing ...

[Neil Bothwick]

On Sun, 3 Jan 2016 18:07:47 +0100, meino.cra...@gmx.de wrote:

> > You stipulate physical printing. Does that mean you want to retain th
> > ability to print to PDF or PS? If so, you would still need at least
> > Ghostscript and possibly CUPS too, although you should be able to get
> > rid of the PPD packages.

> ...my "I am no native english speaker" hit me again it seems... ;)
> 
> With "physical printing" I meant the step which "put it on
> paper"...or in other words: Everything which involves the device
> "printer" (...hrrmmm...NOT anything in /dev/the thing on the
> desktop, which has 9 needles in the past...;) 8) )
> 
> For creating PDF I use either TeX and friends. Or gimp or
> similiar (Image-/Graphicsmagick).

I would think USE="-cups" would help, but some packages do have a hard
dependency on printing, which has been the subject of rants on this list
in the past.


-- 
Neil Bothwick

"Of course, I could switch back to Windows. At least there, if I have a
problem, I don't suffer under the illusion that I could ever fix it." -


pgpF7OHmINQe_.pgp
Description: OpenPGP digital signature