[gentoo-user] Re: beegfs goes opensource!

[James]

Andrew Savchenko  gentoo.org> writes:


> While it is good to have another solution available, I don't see
> any real benefits of FhgFS/BeeGFS compared to Lustre these days.
> At the time where FhgFS was created, Lustre indeed was unable to
> use multiple metadata servers, so this was a bottleneck. But now
> Lustre also supports distributed metadata, so they should on par in
> this matter.

Interesting thesis. I only have anecdotal information, from those
I've encountered who are willing to converse, privately. Many more sites
exist than are publicized as I think most (scientific) groups have a keen
interest in distributed processing, in an open source semantic.
I did notice the '' version of lustre in portage (science overlay), but
reading elsewhere I did not know it was still being actively developed?

> On the other hand, Lustre has much larger community (e.g. see
> TOP-500 list) and is much better tested (and even under such
> conditions it has problems in some corner cases). Thus I see no
> advantage in FhgFS for HPC setups.

Strangely, the folks I have chatted up do not publish their test results
as that would be quite a large undertaking to assure critics that the
tests are fair and equivalent, with the only thing different being the 
local and cluster file systems. Lustre seems to have a bad rap, but that
may be due to folks testing much earlier versions. I'm no authority on the
subject; just trying to ferret out pathways for robust cluster computing
on gentoo; although containers are useful, my focus is on the
leanest/fastest bare metal HPC Opensource approach. to clusters on gentoo. 


> Of course world of parallel distributed file systems is very
> versatile, so for different tasks/workloads different file systems
> are the most suitable, but for typical IB-based HPC storage I see
> no better solution than Lustre at this moment.


YES. But also these test/benchmarks should include Cephfs, gluster, and
tachyon if not many others. [1]  Perhaps we should encourage some of our
gentoo-devs, to put up a wiki for gentoo-HPC, with at least a working
framework of packages suggested, including all the DFS tricks therein ? 
Me, I'm just stumbling my way around to try to figure out a resonable
pathway to HPC on gentoo.

I thought that systemd was going to dominate these cluster-container wars
until I started reading up on Docker's acquisition of the main dev at Alpine
linux and the rapid movement of Docker to 'subsume' Alpine linux as it's
distro for releases [2]. Alpine leverages OpenRC and eudev and Docker is
preparing for battle with other container offerings, commercially, so this
does suggest that the performance battle with clusters is now openly
challenging the systemd proponents for performance bragging rights. Combined
with the question of the DFS, it does lsuggest some publish test comparing
these different approaches would be of keen interest to a wide audience.

The only test code I am aware of for HPC on gentoo is sys-cluster/hpl
and I'm not sure how well that will exercise the DFS performance questions.


> Best regards,
> Andrew Savchenko

James


[1]
http://www.datanami.com/2016/02/23/meet-alluxio-the-distributed-file-system-formerly-known-as-tachyon/

[2] https://www.brianchristner.io/docker-is-moving-to-alpine-linux/

[gentoo-user] ABI_X86=

[James]

Hello,

> 
>
so on one system, I run a amd default profile::
[1] default/linux/amd64/13.0 

A while back I tested converting the system to only 64 bit libs, then
changed it back, so I thought. Several updated where fine. Now quite a few
packages
are complaining [A]. So looking around is this the correct fix, just
add this line to make.conf::

ABI_X86="32 64"

A better or more appropriate fix? The system 'emerge -UDNvp @world shows
these many conflicts now below are a few. I run a minimal desktop (lxde).

James


[A] virtual/libiconv:0

  (virtual/libiconv-0-r2:0/0::gentoo, ebuild scheduled for merge) conflicts with
>=virtual/libiconv-0-r1[abi_x86_32(-),abi_x86_64(-)] required by
(dev-libs/glib-2.46.2-r1:2/2::gentoo, installed)


x11-libs/libXv:0

  (x11-libs/libXv-1.0.10:0/0::gentoo, ebuild scheduled for merge) conflicts with
>=x11-libs/libXv-1.0.10[abi_x86_32(-),abi_x86_64(-)] required by
(x11-libs/libXvMC-1.0.9:0/0::gentoo, installed)

  >=x11-libs/libX11-1.6.2[abi_x86_32(-)] required by
(dev-util/android-studio-1.2.2.0.141.1980579:0/0::gentoo, installed)

Re: [gentoo-user]

[Dale]

Neil Bothwick wrote:
> On Sun, 28 Feb 2016 13:18:17 -0600, Dale wrote:
>
>> Donahue Trevor wrote:
>>>  
>> What was that again?  I can't hear you.  ROFLMBO 
> Couldn't you read it? Maybe you need to change your font colour.
>
>


Funny you mention that.  A long time ago a news article published a
supposedly super secret list of words and phrases that the NSA searches
for.  I put them in my emails as white text on a white background. 
People couldn't see it but I figure the NSA was confused as heck since
computers would.  lol 

Dale

:-)  :-) 

P. S.  See, I do have a sense of humor, sometimes. 

Re: [gentoo-user] useflag hell.

[Alan Grimes]

Alan McKinnon wrote:
> On a plasma system like you have this will probably cause similar issues
> for other packages, so you must iteratively solve those as well till no
> more inconsistencies remain.
I have a fvwm system. KDE has been the suck since 3.5.x because qt
turned to crap with 4.0.

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

Powers are not rights.

[gentoo-user] Re:

[Nikos Chantziaras]

On 28/02/16 21:18, Dale wrote:

Donahue Trevor wrote:




What was that again?  I can't hear you.  ROFLMBO


Just HTML-only spam :-)

Re: [gentoo-user]

[Neil Bothwick]

On Sun, 28 Feb 2016 13:18:17 -0600, Dale wrote:

> Donahue Trevor wrote:
> >  
> 
> What was that again?  I can't hear you.  ROFLMBO 

Couldn't you read it? Maybe you need to change your font colour.


-- 
Neil Bothwick

God is real, unless specifically declared integer.


pgpWB6SbBqQZs.pgp
Description: OpenPGP digital signature

Re: [gentoo-user]

[Dale]

Donahue Trevor wrote:
>

What was that again?  I can't hear you.  ROFLMBO 

Dale

:-)  :-) 

[gentoo-user]

[Donahue Trevor]

Re: [gentoo-user] useflag hell.

[Alan McKinnon]

On 28/02/2016 20:14, Alan Grimes wrote:
> I've been running number theory code for a few weeks, so haven't been
> updating my machine too often...
> 
> I for the last day or so I'm in a run my "pretendupdate" script, look at
> the results, decide whether to run ufed or bleep with package.use
> run the pretendupdate script again, do something while it computes, come
> back to it hours later, and repeat the cycle... This is really getting
> silly and I'm starting to suspect that I'm stuck in useflag hell and
> there isn't a solution to this.


There's always a solution, and they are seldom hard to solve. However,
portage doesn't exactly make it easy for you with the output. Mere
information is often obfuscated and looks like stuff you must fix,
whereas the real nuggets can be hidden in the noise.

Often running without -v can help considerably.

So, here goes, comments inline
> 
> 
> 
> 
> tortoise ~ # ./pretendupdate
> 
> These are the packages that would be merged, in order:
> 
> Calculating dependencies... done!
> 
> !!! Multiple package instances within a single package slot have been pulled
> !!! into the dependency graph, resulting in a slot conflict:
> 
> dev-libs/icu:0
> 
>   (dev-libs/icu-56.1:0/56::gentoo, ebuild scheduled for merge) pulled in by
> (no parents that aren't satisfied by other packages in this slot)
> 
>   (dev-libs/icu-55.1:0/55::gentoo, installed) pulled in by
> dev-libs/icu:0/55=[abi_x86_32(-),abi_x86_64(-)] required by
> (dev-qt/qtcore-4.8.7-r1:4/4::gentoo, installed)
>
> ^^  

Despite what it looks like all this is mere information.
Two separate things result in different version of Qt being pulled into
the problem solution. And it's exactly the form you'd expect.

The first chunk is really saying that icu-56.1 is the most recent
version and all other things being equal, that's the one portage would
install. The second chunk is saying that qtcore-4.8.7-r1 requires
icu-55.1 (not the most recent), so portage spews forth heaps of junk to
helpfully let you not figure it out.

What portage really should say is more like:

Most recent version of icu (icu-56.1) not installed due to these
requirements:
qtcore-4.8.7-r1 requires icu-55.1

Ignore the multiple OMG! bangs before all of the above output


> 
> 
> 
> It may be possible to solve this problem by using package.mask to
> prevent one of those packages from being selected. However, it is also
> possible that conflicting dependencies exist such that they are
> impossible to satisfy simultaneously.  If such a conflict exists in
> the dependencies of two different packages, then those packages can
> not be installed simultaneously.
> 
> For more information, see MASKED PACKAGES section in the emerge man
> page or refer to the Gentoo Handbook.
> 
> 
> !!! The ebuild selected to satisfy
> ">=media-libs/mlt-0.9.8-r1[ffmpeg,kdenlive,melt,qt5,sdl,xml]" has unmet
> requirements.

This is the expression portage needs to install based on dependencies,
most recent version, maskings, and your USE flags. It's informational.

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

This is the actual problem, According to the ebuild, if you set
USE="kde", then you also need USE="qt4". Your USE has qt5 enabled, and
that's the problem.

Presumably, mtl does not yet support KDE with Qt5
> 
>   The above constraints are a subset of the following complete expression:
> python? ( python_targets_python2_7 ) qt5? ( !qt4 ) kde? ( qt4 )

And this is the helpful gigantic USE expression, all of which must be
satisfied to install mlt. The bit above this shows just the part that is
problematic, so this is also informational. Note
> 
> (dependency required by "kde-apps/kdenlive-15.12.1::gentoo" [ebuild])
> (dependency required by "kde-apps/kdemultimedia-meta-15.12.1-r1::gentoo"
> [ebuild])
> (dependency required by "kde-apps/kde-apps-meta-15.08.3-r3::gentoo"
> [ebuild])
> (dependency required by "kde-apps/kde-meta-15.08.3::gentoo" [ebuild])
> (dependency required by "@selected" [set])
> (dependency required by "@world" [argument])

And the is a part of the full dep tree that leads to mlt being included
> tortoise ~ #
> 
> 
> ##
> 
> 
> The attached files are whatever is left after --- six years of resolving
> similar issues on this same install...


What you need to do now is set one of the following combinations in
package.use for mlt:

USE=-kde qt4 -qt5
USE=kde qt4 -qt5

On a plasma system like you have this will probably cause similar issues
for other packages, so you must iteratively solve those as well till no
more inconsistencies remain.

Portage does an atrocious job of presenting it's output to 

Re: [gentoo-user] useflag hell.

[Neil Bothwick]

On Sun, 28 Feb 2016 13:14:30 -0500, Alan Grimes 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 fftw gtk kde kdenlive lua
> melt opengl python qt5 sdl xine xml -compressed-lumas -debug -frei0r
> -jack -libav -libsamplerate -qt4 -rtaudio (-ruby) -vdpau" ABI_X86="64"
> CPU_FLAGS_X86="mmx sse sse2" PYTHON_TARGETS="python2_7"
> 
>   The following REQUIRED_USE flag constraints are unsatisfied:
> kde? ( qt4 )

If you want to enable the kde flag, you have to also enable qt4.

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

However, that will conflict with qt5 so you must either set qt4 and unset
qt5 or unset kde for this package.


-- 
Neil Bothwick

Keyboard: (n.) a device used by programmers to write software for a mouse
or joystick and by operators for playing games such as 'word processing.'


pgp0SHXdfvizM.pgp
Description: OpenPGP digital signature

[gentoo-user] useflag hell.

[Alan Grimes]

I've been running number theory code for a few weeks, so haven't been
updating my machine too often...

I for the last day or so I'm in a run my "pretendupdate" script, look at
the results, decide whether to run ufed or bleep with package.use
run the pretendupdate script again, do something while it computes, come
back to it hours later, and repeat the cycle... This is really getting
silly and I'm starting to suspect that I'm stuck in useflag hell and
there isn't a solution to this.




tortoise ~ # ./pretendupdate

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

Calculating dependencies... done!

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

dev-libs/icu:0

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

  (dev-libs/icu-55.1:0/55::gentoo, installed) pulled in by
dev-libs/icu:0/55=[abi_x86_32(-),abi_x86_64(-)] required by
(dev-qt/qtcore-4.8.7-r1:4/4::gentoo, installed)
   
^^  
  



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

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


!!! The ebuild selected to satisfy
">=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 fftw gtk kde kdenlive lua
melt opengl python qt5 sdl xine xml -compressed-lumas -debug -frei0r
-jack -libav -libsamplerate -qt4 -rtaudio (-ruby) -vdpau" 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.1::gentoo" [ebuild])
(dependency required by "kde-apps/kdemultimedia-meta-15.12.1-r1::gentoo"
[ebuild])
(dependency required by "kde-apps/kde-apps-meta-15.08.3-r3::gentoo"
[ebuild])
(dependency required by "kde-apps/kde-meta-15.08.3::gentoo" [ebuild])
(dependency required by "@selected" [set])
(dependency required by "@world" [argument])
tortoise ~ #


##


The attached files are whatever is left after --- six years of resolving
similar issues on this same install...


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

Powers are not rights.

# These settings were set by the catalyst build script that automatically
# built this stage.
# Please consult /usr/share/portage/config/make.conf.example for a more
# detailed example.
CFLAGS="-march=native -pipe "
CXXFLAGS="${CFLAGS}"

MAKEOPTS="-j 6"

# WARNING: Changing your CHOST is not something that should be done lightly.
# Please consult http://www.gentoo.org/doc/en/change-chost.xml before changing.
CHOST="x86_64-pc-linux-gnu"

INPUT_DEVICES="keyboard mouse"

LINGUAS="en en_US"
ACCEPT_KEYWORDS="amd64 ~amd64"
ACCEPT_LICENSE="*"

# These are the USE flags that were used in addition to what is provided by the
# profile used for building.
USE="3dnow 3dnowext amr apache2 ares audiofile autoipd avahi bittorrent
 blender-game bmp boost c++0x caps cg cgi clang contrib cpudetection css
 cuda curl custom-cflags custom-tune debugger declarative device-mapper
 dga discouraged dolbyinrec double-precision drm egl evdev expat extras
 fbcon ffcall ffmpeg fftw firmware fluidsynth fontconfig foomaticdb
 freeimage ftp g3dvl gbm gd gflags gfortran ggz gl glade glut gmp gnome
 gnome-keyring gphoto2 graphviz gsl gstreamer gtk3 heterogeneous high-ints
 hpijs hwdb icu ide imlib introspection ithreads jadetex java jit joystick
 jpeg2k kde kdenlive kdrive lame lapack legacy-systray libffi libkms
 libwww llvm-shared-libs lm_sensors lua lzo matroska mdnsresponder-compat
 melt metis midi minizip mmap mms mmxext mozilla mp3rtp mpeg2 multicore
 multilib multislot mysql mysqli nas natspec netpbm nowin nsplugin ode
 ogre ois okteta openal opencl openexr openssl opus orc pae parport pch
 pcre16 pdo perl pgo plasma posix postproc povray private-headers
 pulseaudio python python3 qml qt5 qthelp quicktime r600-llvm-compiler
 reiserfs script scripttools sdk seamonkey secure-delete semantic-desktop
 server sftp sip smp soprano sql sqlite sse2 sse3 sse4 static-ppds
 subversion system-boost system-icu system-jpeg system-libvpx
 system-sqlite t1lib theora threads threadsafe 

Re: [gentoo-user] Re: beegfs goes opensource!

[Tanstaafl]

On 2/28/2016 9:09 AM, Rich Freeman  wrote:
> I'm not really sure what the "conservative" recommendation.  Ext4 (or
> even ext3) is the obvious one, but both zfs and btrfs have
> checksumming of all data written to disk which is a huge data security
> improvement.  That is a compelling feature that should give even
> conservative sysadmins pause before just rejecting them, unless
> they're mitigating silent corruptions in some other way.

This is precisely why I'm interested in it...

Thanks for the comments...

Re: [gentoo-user] Re: beegfs goes opensource!

[Rich Freeman]

On Sun, Feb 28, 2016 at 8:34 AM, Tanstaafl  wrote:
>
> Also, it has been a while since I read anything - what is the current
> state of BTRFS vs ZFS? Is it stable/mature enough to use for production?
> What can ZFS do that it cannot?
>

This is obviously a topic people will have various opinions on.

I'd say that zfs is more stable, but long-term less likely to be the
mainstream linux solution.

At the current time I'd say that btrfs single-disk or in raid1 is
mature enough to be usable, with a bunch of caveats.  It definitely
isn't up there with the likes of ext4.  Besides some stuff just not
being handled gracefully like low-disk-space it is fairly prone to
regressions.  I've found I've gotten the best experience by sticking
with longterm kernels and not updating to the next one until it
reaches maybe x.x.16 or so (maybe 6mo after release), and I always
check the lists before updating.

As far as features go, zfs tends to have more enterprise-oriented
features and btrfs tends to have more small-system-oriented features.
For example, in zfs with 100 drives you can arrange them into 10 neat
raid-6s with 10 drives each or something along those lines, and have a
few SDDs servicing the entire array as read and write caches.  On the
other hand, if you have a 4-drive raid5 and want to turn it into a
5-drive raid5 this is impossible to do in zfs without copying all the
data off the drives, but trivial to do in btrfs.  When you have 100
drives adding or removing 10 at a time probably isn't a big deal, but
when you 4 drives having to first add 5 drives and then remove the
previous 4 seems almost comical.  It just has to do with the original
goals of the two filesystems.

Oh, I've heard that zfs is ram-hungry, and many of its advocates
suggest it should only be used with ECC RAM.  Honestly, I've never
seen an argument for ECC on zfs that wouldn't apply equally to any
other filesystem, but whatever.  I haven't found btrfs to be terribly
RAM hungry, but I have found that it doesn't seem to do a good job
with IO scheduling classes (though I have no idea how zfs does on this
front).  Btrfs at least seems to accept too many writes into its queue
and then everything backlogs with getting it all out to disk,
resulting in processes that should be low-priority blocking writes
even on processes marked as realtime.  I suspect that this is just the
whole bufferbloat phenomena in another context.

I'm not really sure what the "conservative" recommendation.  Ext4 (or
even ext3) is the obvious one, but both zfs and btrfs have
checksumming of all data written to disk which is a huge data security
improvement.  That is a compelling feature that should give even
conservative sysadmins pause before just rejecting them, unless
they're mitigating silent corruptions in some other way.

-- 
Rich

Re: [gentoo-user] Re: beegfs goes opensource!

[Neil Bothwick]

On Sun, 28 Feb 2016 08:34:56 -0500, Tanstaafl wrote:

> >> I would be using this on a server, so, for security reasons, no
> >> module support.  
> > 
> > echo sys-fs/zfs kernel-builtin >/etc/portage/package.use
> > 
> > You need to unmask the kernel-builtin USE flag.  
> 
> Wow...! How long has that been available?

I last used it a couple of years ago, before I switched to btrfs.
 
> I also recall something about being able to use the latest/greatest too,
> but the overlay would have to pull the sources from Oracle...?

AFAIK the sources for more recent versions of ZFS were never released.
 

-- 
Neil Bothwick

Beware! The end is... 


pgp6ycuwuPryx.pgp
Description: OpenPGP digital signature

Re: [gentoo-user] Re: beegfs goes opensource!

[Tanstaafl]

On 2/28/2016 4:24 AM, Neil Bothwick  wrote:
> On Sat, 27 Feb 2016 22:51:13 -0500, Tanstaafl wrote:
>>> I recall a list conversation about this, explaining that it would be
 trivial for someone who knows how to do ebuilds, to have their own
 ZFS-in-kernel system available, and that it would also be possible to
 accomplish this via an overlay...  

>>> sys-fs/zfs-kmod  

>> I would be using this on a server, so, for security reasons, no module
>> support.
> 
> echo sys-fs/zfs kernel-builtin >/etc/portage/package.use
> 
> You need to unmask the kernel-builtin USE flag.

Wow...! How long has that been available?

I also recall something about being able to use the latest/greatest too,
but the overlay would have to pull the sources from Oracle...?

So, would appreciate comments on what version of ZFS this would pull in,
limitations, caveats, dangers, etc...

Also, it has been a while since I read anything - what is the current
state of BTRFS vs ZFS? Is it stable/mature enough to use for production?
What can ZFS do that it cannot?

Thanks Neil!

[gentoo-user] app-emulation/free42: Any additional sources for programm examples?

[Meino . Cramer]

Hi,

For the fun of it I installed free42 - the emulator of
the legendary HP42s by Hewlett and packard - and I must
confess that my interest now goes further than "just for fun"  ;)

I googled through the web and found the programs ("*.raw") the
author of free42 has published on his homepage and programs
from this site http://www.underhill.ca/software/free42-more

I did a quick search on www.archive or for HP-42s and found nothing.

Are there any other sources known for programs and/or informations
around the HP-42s/Free42 which may not be able to be found via
Google and friends (for example ftp archives or sources with totally
different names, which a newbie like me will not easily find) ?

Thank you very much in advance for any help!
Best regards,
Meino

Re: [gentoo-user] beegfs goes opensource!

[Andrew Savchenko]

Hi all,

On Thu, 25 Feb 2016 22:03:59 + (UTC) James wrote:
> This smoking hot (many HPC scientist agree) distributed file
> system will surely rock the cluster, container and Hi Performance
> Computing worlds. [1] Now if I were only smart enough to get this
> puppy into portage...

By the way, does anyone have any real performance comparison with
Lustre?

While it is good to have another solution available, I don't see
any real benefits of FhgFS/BeeGFS compared to Lustre these days.
At the time where FhgFS was created, Lustre indeed was unable to
use multiple metadata servers, so this was a bottleneck. But now
Lustre also supports distributed metadata, so they should on par in
this matter.

On the other hand, Lustre has much larger community (e.g. see
TOP-500 list) and is much better tested (and even under such
conditions it has problems in some corner cases). Thus I see no
advantage in FhgFS for HPC setups.

Of course world of parallel distributed file systems is very
versatile, so for different tasks/workloads different file systems
are the most suitable, but for typical IB-based HPC storage I see
no better solution than Lustre at this moment.

Best regards,
Andrew Savchenko


pgpVsIgQrkjpx.pgp
Description: PGP signature

Re: [gentoo-user] Re: beegfs goes opensource!

[Neil Bothwick]

On Sat, 27 Feb 2016 22:51:13 -0500, Tanstaafl wrote:

> >> I recall a list conversation about this, explaining that it would be
> >> trivial for someone who knows how to do ebuilds, to have their own
> >> ZFS-in-kernel system available, and that it would also be possible to
> >> accomplish this via an overlay...  
> 
> > sys-fs/zfs-kmod  
> 
> I would be using this on a server, so, for security reasons, no module
> support.

echo sys-fs/zfs kernel-builtin >/etc/portage/package.use

You need to unmask the kernel-builtin USE flag.


-- 
Neil Bothwick

Why is bra singular and pants plural?


pgpjOZCDtVY2d.pgp
Description: OpenPGP digital signature

Re: [gentoo-user] weird (?) dependency is blocking freeze

[Meino . Cramer]

Franz Fellner  [16-02-28 09:08]:
> > > Calculating dependencies... done!
> > >   media-libs/mlt-0.9.0 pulled in by:
> > > media-video/openshot-1.4.3 requires 
> > > >=media-libs/mlt-0.8.2[ffmpeg,frei0r,gtk,melt,python,sdl,xml]
> > > 
> > > Checking the kind of packages:
> > > 
> > > * app-arch/freeze
> > >  Available versions:  2.5.0-r1
> > >  Homepage:http://www.ibiblio.org/pub/Linux/utils/compress/
> > >  Description: Freeze/unfreeze compression program
> > > 
> > > [I] media-libs/mlt
> > >  Available versions:  0.9.0 ~0.9.8 ~0.9.8-r2 {compressed-lumas debug 
> > > dv ffmpeg fftw frei0r gtk jack kde kdenlive libav libsamplerate lua melt 
> > > opengl python qt4 qt5 quicktime rtaudio ruby sdl vdpau vorbis xine xml 
> > > CPU_FLAGS_X86="mmx sse sse2" KERNEL="linux" PYTHON_TARGETS="python2_7"}
> > >  Installed versions:  0.9.0(18:22:19 06/06/15)(ffmpeg frei0r gtk jack 
> > > kdenlive lua melt python qt4 sdl vdpau vorbis xml -compressed-lumas 
> > > -debug -dv -kde -libav -libsamplerate -quicktime -rtaudio -ruby -xine 
> > > CPU_FLAGS_X86="mmx sse sse2" KERNEL="linux")
> > >  Homepage:http://www.mltframework.org/
> > >  Description: Open source multimedia framework for television 
> > > broadcasting
> > > 
> > > [I] media-video/openshot
> > >  Available versions:  (~)1.4.3 {+ffmpeg libav +python 
> > > PYTHON_TARGETS="python2_7"}
> > >  Installed versions:  1.4.3(18:33:24 06/06/15)(ffmpeg python -libav 
> > > PYTHON_TARGETS="python2_7")
> > >  Homepage:http://www.openshotvideo.com
> > >  Description: Free, open-source, non-linear video editor to 
> > > create and edit videos and movies
> > > 
> > > 
> > > ...what is the common dominator which creates this blocking effect? ;)
> > 
> > As always with such things, look in the ebuild.
> > 
> > In /var/portage/app-arch/freeze/freeze-2.5.0-r1.ebuild:
> > 
> > RDEPEND="
> > !<=media-libs/mlt-0.4.2
> > !media-libs/mlt[melt]
> > 
> > The solution is to set USE="-melt" for mlt if you want to use freeze.
> 
> Which won't work because openshot obviously depends on media-libs/mlt[melt].
> So it really looks like openshot can't be installed together with freeze -- If
> the dependencies in both the ebuilds are really correct...
> 
> 

Hi Franz,

"You took the words right out of my mouth..."
"Bat out of hell" Meat loaf

yes ... it was the reason for asking for the common dominator of
both...

Best regards
Meino