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

[Peter Humphrey]

On Tuesday 05 January 2016 19:09:10 lee wrote:
> 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.

That's why I wanted to keep it separate. By building it in a chroot I could 
forget about it while it was emerging and continue using the main system.

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

I wouldn't. As you say, it's nowhere near finished yet and it's likely to 
make an awful mess of your existing setup.

-- 
Rgds
Peter

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

[Francisco Ares]

2016-01-05 16:39 GMT-02:00 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.
>

Thanks, Neil.

According to this site:

http://nouveau.freedesktop.org/wiki/FeatureMatrix/

nouveau is not complete on OpenCL (not OpenGL) implementation.

Not sure if it could be enough, though.  Gonna do some tests...

Best regards,
Francisco

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

[Peter Humphrey]

On Tuesday 05 January 2016 22:23:22 Alan McKinnon wrote:
--->8
> 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

Maybe I'll have another shot at it without the overlay then. I want to 
change from nouveau to nVidia anyway, to get cuda for boinc, and doing that 
on my main system left me with just a black screen.

-- 
Rgds
Peter

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

[Alan McKinnon]

On 06/01/2016 11:49, Peter Humphrey wrote:

On Tuesday 05 January 2016 22:23:22 Alan McKinnon wrote:
--->8

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


Maybe I'll have another shot at it without the overlay then. I want to
change from nouveau to nVidia anyway, to get cuda for boinc, and doing that
on my main system left me with just a black screen.




In that case there's something you need to be aware of:

You may well find that some KDE4 apps using Qt5 and new plasma look 
decidedly odd, as if they are using a toolkit they were not designed to 
use. Imagine 2 GTK apps on the screen, one using that horrible square 
blocky GTK+2 look you get without a proper theme, the other using nice 
new flashy GTK+3 goodness. Looks pretty gross and can throw you off.


Thankfully the KDE5 apps I use all work nicely now, I reckon most of 
them grossness has passed.


/alanm

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

[Peter Humphrey]

On Wednesday 06 January 2016 12:34:46 Alan McKinnon wrote:

> You may well find that some KDE4 apps using Qt5 and new plasma look
> decidedly odd, as if they are using a toolkit they were not designed to
> use. Imagine 2 GTK apps on the screen, one using that horrible square
> blocky GTK+2 look you get without a proper theme, the other using nice
> new flashy GTK+3 goodness. Looks pretty gross and can throw you off.
> 
> Thankfully the KDE5 apps I use all work nicely now, I reckon most of
> them grossness has passed.

Thanks for the warning, Alan. I'll keep my eye open.

-- 
Rgds
Peter

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

[Grant]

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


OK so that's where the GLSA bug comes in?  It reports a vulnerability
that may not be accurate?

Should we just wait for clarification of the vulnerability and a
subsequent update to glsa-check's data feed?

- Grant

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

[»Q«]

On Tue, 5 Jan 2016 08:26:42 -0800
Grant  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.   
> 
> So everyone is just living with the supposed security vulnerability on
> their system?

Not everyone.  SUSE and Debian seem to have patches for this for 0.10.

Re: [gentoo-user] eselect OpenCL is wrong.

[wabenbau]

Alan Grimes  wrote:

> Wrong, I say, WRONG!

No reason to go into hysterics. Think of your blood pressure! ;-)

> OpenCl is not OpenGL. It is more of a framework than an API. A high
> end machine may have a number of different OpenCL hosts, the cpu,
> vector cores built into the cpu as in the AMD APU line and intel's
> lame knockoff thereof. =P
> 
> There is also OpenCL support in GPUs, Xeon Phi, FPGA and potentially
> other devices too.
> 
> The game Planet Explorers (available on Steam) demonstrates how this
> should be used. You are given a menu at the start of the game that
> lists the available OpenCL implementations. You then select whatever
> device you want to use for OpenCL that day...
> 
> So there should not be eselect OpenCL, All gentoo needs to do is
> enforce standards on where the relevant libraries are stored and the
> application will select which one to use.

You should better report this to the developers of the respective
applications. I'm not an expert on this, but I think this is nothing 
that the gentoo developers can do.

And I think it's better to have "eselect OpenCL" than nothing.

--
Regards
wabe

Re: [OT] Re: [gentoo-user] snapshots?

[Neil Bothwick]

On Wed, 06 Jan 2016 16:56:57 +, Peter Humphrey wrote:

> > There's probably more chance of my winning the lottery...  
> 
> Hardly, since they reduced our odds by a factor of 50 x 51 x 52 x ... x
> 59 by adding ten more numbers.

The fact I was unaware of that should give an indication of my chances of
winning in the first place :)


-- 
Neil Bothwick

Biology is the only science in which multiplication means the same thing
as division.


pgprxdTXx7rno.pgp
Description: OpenPGP digital signature

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

[Neil Bothwick]

On Wed, 06 Jan 2016 16:08:36 +, Peter Humphrey wrote:

> > Thankfully the KDE5 apps I use all work nicely now, I reckon most of
> > them grossness has passed.  
> 
> Thanks for the warning, Alan. I'll keep my eye open.

To add some balance to all of this. I switched to KDE5 in July, when it
hit ~arch, and it all more or less worked. I did have one fairly serious
problem with KWin, but it turned out to be something else causing it, and
only one other person reported the issue on b.g.o.

The transition was a little bumpy with blockers popping up at times, but
it all seems to have smoothed out now, using the desktop/plasma/systemd
profile.


-- 
Neil Bothwick

Top Oxymorons Number 15: Extinct Life


pgpteb7uw8htv.pgp
Description: OpenPGP digital signature

Re: [gentoo-user] snapshots?

[Neil Bothwick]

On Tue, 5 Jan 2016 18:22:59 -0500, Rich Freeman wrote:

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

That's a point I hadn't considered, but I think I'll leave things as they
are for now. I have three drives with a swap partition on each. My system
uses very little swap as it is, so the chances of one of those drives
failing exactly when something is using that particular drive is pretty
small. There's probably more chance of my winning the lottery...


-- 
Neil Bothwick

[unwieldy legal disclaimer would go here - feel free to type your own]


pgpSnv49jgJZS.pgp
Description: OpenPGP digital signature

[OT] Re: [gentoo-user] snapshots?

[Peter Humphrey]

On Wednesday 06 January 2016 16:27:26 Neil Bothwick wrote:

> There's probably more chance of my winning the lottery...

Hardly, since they reduced our odds by a factor of 50 x 51 x 52 x ... x 59 
by adding ten more numbers.

:)

-- 
Rgds
Peter

[gentoo-user] eselect OpenCL is wrong.

[Alan Grimes]

Wrong, I say, WRONG!

OpenCl is not OpenGL. It is more of a framework than an API. A high end
machine may have a number of different OpenCL hosts, the cpu, vector
cores built into the cpu as in the AMD APU line and intel's lame
knockoff thereof. =P

There is also OpenCL support in GPUs, Xeon Phi, FPGA and potentially
other devices too.

The game Planet Explorers (available on Steam) demonstrates how this
should be used. You are given a menu at the start of the game that lists
the available OpenCL implementations. You then select whatever device
you want to use for OpenCL that day...

So there should not be eselect OpenCL, All gentoo needs to do is enforce
standards on where the relevant libraries are stored and the application
will select which one to use.

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

Powers are not rights.

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

[Mick]

On Wednesday 06 Jan 2016 12:27:30 »Q« wrote:
> On Tue, 5 Jan 2016 08:26:42 -0800
> 
> Grant  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.
> > 
> > So everyone is just living with the supposed security vulnerability on
> > their system?
> 
> Not everyone.  SUSE and Debian seem to have patches for this for 0.10.
> 
> 
> 
> 

I tried removing 0.10.36-r2, but stopped, because some applications (Opera, 
Pidgin, farstream) currently require it.

-- 
Regards,
Mick

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

Re: [gentoo-user] Gtypist does not accept ru.typ

[gevisz]

As an addition to the previous messages, below is given
the full output of


# emerge gtypist
Calculating dependencies... done!

>>> Verifying ebuild manifests

>>> Emerging (1 of 1) app-misc/gtypist-2.9.5::gentoo
 * gtypist-2.9.5.tar.xz SHA256 SHA512 WHIRLPOOL size ;-) ...

 [ ok ]
 * colemak.typ SHA256 SHA512 WHIRLPOOL size ;-) ...

 [ ok ]
>>> Unpacking source...
>>> Unpacking gtypist-2.9.5.tar.xz to 
>>> /var/tmp/portage/app-misc/gtypist-2.9.5/work
>>> Source unpacked in /var/tmp/portage/app-misc/gtypist-2.9.5/work
>>> Preparing source in 
>>> /var/tmp/portage/app-misc/gtypist-2.9.5/work/gtypist-2.9.5 ...
 * Applying gtypist-2.8.3-xemacs-compat.patch ...

 [ ok ]
>>> Source prepared.
>>> Configuring source in 
>>> /var/tmp/portage/app-misc/gtypist-2.9.5/work/gtypist-2.9.5 ...
 * econf: updating gtypist-2.9.5/config.sub with /usr/share/gnuconfig/config.sub
 * econf: updating gtypist-2.9.5/config.guess with
/usr/share/gnuconfig/config.guess
./configure --prefix=/usr --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --mandir=/usr/share/man
--infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc
--localstatedir=/var/lib --disable-dependency-tracking
--disable-silent-rules --libdir=/usr/lib64 --disable-nls EMACS=no
--with-lispdir=
checking for a BSD-compatible install...
/usr/lib/portage/python3.4/ebuild-helpers/xattr/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking for style of include used by make... GNU
checking for x86_64-pc-linux-gnu-gcc... x86_64-pc-linux-gnu-gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether x86_64-pc-linux-gnu-gcc accepts -g... yes
checking for x86_64-pc-linux-gnu-gcc option to accept ISO C89... none needed
checking whether x86_64-pc-linux-gnu-gcc understands -c and -o together... yes
checking dependency style of x86_64-pc-linux-gnu-gcc... none
checking how to run the C preprocessor... x86_64-pc-linux-gnu-gcc -E
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking minix/config.h usability... no
checking minix/config.h presence... no
checking for minix/config.h... no
checking whether it is safe to define __EXTENSIONS__... yes
checking for gawk... (cached) gawk
checking for x86_64-pc-linux-gnu-gcc... (cached) x86_64-pc-linux-gnu-gcc
checking whether we are using the GNU C compiler... (cached) yes
checking whether x86_64-pc-linux-gnu-gcc accepts -g... (cached) yes
checking for x86_64-pc-linux-gnu-gcc option to accept ISO C89...
(cached) none needed
checking whether x86_64-pc-linux-gnu-gcc understands -c and -o
together... (cached) yes
checking dependency style of x86_64-pc-linux-gnu-gcc... (cached) none
checking for library containing strerror... none required
checking whether ln -s works... yes
checking whether make sets $(MAKE)... (cached) yes
checking for x86_64-pc-linux-gnu-ranlib... x86_64-pc-linux-gnu-ranlib
checking for bison... bison -y
checking for ANSI C header files... (cached) yes
checking for unistd.h... (cached) yes
checking alloca.h usability... yes
checking alloca.h presence... yes
checking for alloca.h... yes
checking argz.h usability... yes
checking argz.h presence... yes
checking for argz.h... yes
checking errno.h usability... yes
checking errno.h presence... yes
checking for errno.h... yes
checking fcntl.h usability... yes
checking fcntl.h presence... yes
checking for fcntl.h... yes
checking langinfo.h usability... yes
checking langinfo.h presence... yes
checking for langinfo.h... yes
checking libintl.h usability... yes
checking libintl.h presence... yes
checking for libintl.h... yes
checking limits.h usability... yes
checking limits.h presence... yes
checking for limits.h... yes
checking locale.h usability... yes
checking locale.h presence... yes
checking for locale.h... yes
checking malloc.h usability... yes
checking malloc.h presence... yes
checking for malloc.h... yes
checking stddef.h usability... yes
checking stddef.h presence... yes
checking for stddef.h... yes
checking stdio_ext.h usability... yes
checking stdio_ext.h presence... yes
checking for stdio_ext.h... yes
checking for stdlib.h... (cached) yes
checking for string.h... (cached) yes
checking for strings.h... (cached) yes
checking sys/param.h 

Re: [gentoo-user] Gtypist does not accept ru.typ

[gevisz]

Sorry for double-posting, the previous copy of this message has been sent
only to Stroller and not to the gentoo-user mailing list.

2016-01-04 12:47 GMT+02:00 Stroller :

First of all, thank you for replying and excuse for the delay.

> A resend of this message, which I posted yesterday. Is the list dropping my 
> mail?

 Probably, yes, as I have received only this one.

> On Fri, 1 January 2016, at 4:59 p.m., gevisz  wrote:
>>
>> Below is the additional details of the second answer:
>>
>>> Since you build from source on gentoo:
>>> Can you check whether this appears when running ./configure?
>>> checking for nl_langinfo and CODESET… yes
>
> You should see this by re-emerging the package and watching the screen
> - there should be lots of "checking for" lines during the emerge output.
> You should be able to scroll back through it all when the package has
> finished emerging.
>
>>> Also, which arguments are used for ./configure?
>
> Look in the ebuild. [1]
>
> It looks like it's configured with --with-lispdir=/$path/$to/$directory if 
> you have the USE=emacs.

 No, I have emacs, nls and xemacs user flags all unset for this package:

 $ equery uses gtypist
 [ Legend : U - final flag setting for installation]
 [: I - package is installed with flag ]
 [ Colors : set, unset ]
  * Found these USE flags for app-misc/gtypist-2.9.5:
  U I
  - - emacs  : Add support for GNU Emacs
  - - nls: Add Native Language Support (using gettext - GNU locale
utilities)
  - - xemacs : Add support for XEmacs

> It looks like it applies an xemacs compatibility patch [2], but I doubt that 
> makes a difference.
>
> Otherwise, as far as I can see, it uses the makefile's defaults.
>
> I'm not sure what's going on with "$(use_enable nls)" in the ebuild
> - perhaps someone else on this list could explain what USE=nls does for this 
> package.
>
>>> /* printf("encoding is %s, UTF8=%d\n", locale_encoding, isUTF8Locale); */
>>>
>>> If that doesn't help, can you enable to printf above and post the output?
>
> If you run `sudo ebuild /usr/portage/app-misc/gtypist/gtypist-2.9.5.ebuild 
> unpack`
> you should be able to find the file with that line.

 I did it, and the ebuild has been unpacked to
 /var/tmp/portage/app-misc/gtypist-2.9.5/work

> The "/*" and "*/" make that line into a comment, so "uncomment" it [3] by 
> removing them. Save the file.

 Did it in the file
 /var/tmp/portage/app-misc/gtypist-2.9.5/work/gtypist-2.9.5/src/gtypist.c.

> Now you should be able to run `sudo ebuild 
> /usr/portage/app-misc/gtypist/gtypist-2.9.5.ebuild install`
> to install gtypist with the modified code.

 Did it as well, though without understanding why this command should
 take into account the changes I had done  in the file
 /var/tmp/portage/app-misc/gtypist-2.9.5/work/gtypist-2.9.5/src/gtypist.c

 There was nothing in the output from the uncommented line (/encoding
 finds nothing).

 Any further help would be appreciated.

> I haven't done this in a while, so hopefully someone will correct me if I've 
> got anything wrong.
> My first instinct was to epatch, but I don't think that's necessary.
>
> HTH,
>
> Stroller.
>
> [1] 
> https://gitweb.gentoo.org/repo/gentoo.git/plain/app-misc/gtypist/gtypist-2.9.5.ebuild
>
> [2] 
> https://gitweb.gentoo.org/repo/gentoo.git/plain/app-misc/gtypist/files/gtypist-2.8.3-xemacs-compat.patch
>
> [3] http://english.stackexchange.com/questions/33483/
>
>