Re: [gentoo-user] In search of an truecolor-capable terminal emulator

2017-04-25 Thread tuxic
Hi R0b0t1,

On 04/25 02:15, R0b0t1 wrote:
> On Tue, Apr 25, 2017 at 10:47 AM,   wrote:
> > Hi,
> >
> > currently I am using urxvt as my standard terminal
> > application, which is FAST and reliable.
> > But it only emulates 24bit colors if instructed so.
> > It maps 24bit rgb to 256 color using a fast but not
> > total correct formula to to do (which is no critism -
> > its just the way ot is implemented).
> >
> 
> I suppose you have seen https://gist.github.com/XVilka/8346728, but if
> not, I will link it for you. Anyone following along who hasn't read it
> might be inclined to do so.

Yes, I found that before. It triggers my post here and asking
for experiences... ;)
> 
> > I googled qyite a bit to find 24color terminal
> > emulators and the one, which came closer to
> > what I want is sakure.
> > But comparing the speed of sakura with urxvt
> > (catting a long log file twice while measureing the time
> > of the second cat) it shows that sakura needs
> > six times more time than urxvt.
> >
> > Combining this with the compile sessions, which
> > are one of the core features of Gentoo ;)))...
> >
> 
> I would suggest looking at:
> *) https://github.com/jwilm/alacritty
> *) https://github.com/kovidgoyal/kitty

I tried alacritty before ... or better: I tried to solve
all dependencies and stopped at a certain point because
it got all too ... how should I call that fuzzy?

Kitty needs python3 ... I am on python2.
Last time I got in conflict with these pythons I finally
had to decide to reinstall my Gentoo from ground up 
(others things were also a reason, so not to blame
python alone).
So I stopped here also.

> 
> Both of which are OpenGL accelerated. Unfortunately I'm not entirely
> sure why sakura is slow. Finding out might be worthwhile. Alacritty is
> the shiniest, but unfortunately the rust build and setup process looks
> very insecure, similar to Haskell. Take into account that those
> languages are experimental.

I tried xfce4-terminal as suggested by Floyd...and got exactly the
reversed timings. He found xfce4-terminal six times faster than
urxvt and I got the reversed result.
If I could find the culprit on my box I would be happy with sakura
and/or xfve4-terminal.
Where can I start?
What may be the reasons?

> > What I want is the "fastest" possible (...)
> > terminal emulator supporting true color (24bit).
> > I dont need fancy configuring options (two exception:
> > TABS! and lightweighted) and I dont want KDE stuff (or
> > any other bloated thing with thousands of dependencies...)
> > I am simply using openbox.
> >
> 
> Tabs are probably a stretch though I admit they are a useful feature.

I dont like to insert just another layer of confusion ;) with
my terminal like screen of tmux. They are fine for in special cases
but for my daily tabbed terminal I would like to have native support
rigth in the terminal emulator.

> I would recommend that if you find a Desktop Environment that has a
> program you like you simply use it though the look may clash with your
> other programs. It's hard enough to find programs that do what you
> want on Linux.

I have no problems with the 'optical clash'. But I don want to
pull in dozenz of dependencies (KDE) just for a terminal emultor.
These will also increase the amount of stuff which needs to be
updated...

> > What are your experiences?
> >
> 
> Nothing really seems to do what I want, and that may translate into
> nothing really doing what you want.

...or in other words: I need to find the reason, why some terminal
emulators are slow on my box and not on others...

> > Any hint is heartly welcome! Thanks !
> >
> > Cheers
> > Meino
> >
> > PS: The terminal emulator dont need to be part
> > of Gentoo necessarily...if it is compilable
> > by a human being withoyt super powers... ;)
> >
> 
> Check the list on that gist - may as well keep trying them until you
> find one that you like.

To prevent exactly that was the reason for asking for experiences
others made with terminal emulators.
Blindly following the compile-install-test-desinstall cycle with
applications listed somewhere is not efficient.

Cheers
Meino






Re: [gentoo-user] In search of an truecolor-capable terminal emulator

2017-04-25 Thread tuxic
On 04/25 07:38, Floyd Anderson wrote:
> On Di, 25 Apr 17:47:22 +0200
> tu...@posteo.de wrote:
> > Hi,
> > 
> > currently I am using urxvt as my standard terminal
> > application, which is FAST and reliable.
> > But it only emulates 24bit colors if instructed so.
> > It maps 24bit rgb to 256 color using a fast but not
> > total correct formula to to do (which is no critism -
> > its just the way ot is implemented).
> > 
> > I googled qyite a bit to find 24color terminal
> > emulators and the one, which came closer to
> > what I want is sakure.
> > But comparing the speed of sakura with urxvt
> > (catting a long log file twice while measureing the time
> > of the second cat) it shows that sakura needs
> > six times more time than urxvt.
> > 
> > Combining this with the compile sessions, which
> > are one of the core features of Gentoo ;)))...
> > 
> > What I want is the "fastest" possible (...)
> > terminal emulator supporting true color (24bit).
> > I dont need fancy configuring options (two exception:
> > TABS! and lightweighted) and I dont want KDE stuff (or
> > any other bloated thing with thousands of dependencies...)
> > I am simply using openbox.
> > 
> > What are your experiences?
> > 
> > Any hint is heartly welcome! Thanks !
> > 
> > Cheers
> > Meino
> > 
> > PS: The terminal emulator dont need to be part
> > of Gentoo necessarily...if it is compilable
> > by a human being withoyt super powers... ;)
> > 
> I am using rxvt-unicode also as my main terminal emulator. Its true colour
> emulation bothers me also but just only a little bit.
> 
> As a second one, xfce4-terminal runs here from time to time (seldom). A
> quick time/cat test with a gcc-5.4.0 log file (approximately 25 MiB) shows
> surprisingly that xfce4-terminal runs six time faster than rxvt-unicode.
> Maybe one reason is that urxvt looks for URLs and email addresses to
> colourising them.
> 
> Maybe you can get a suggestion from [1].
> 
> 
> References:
> [1] 
> 
> -- 
> Regards,
> floyd
> 
> 

Hi Floyd,

thanks for the informations! :)

A few minutes ago I emerged xfce4-terminal and tried the
cat-time-test of yesterday: 29 secondes with xfce-terminal
and 5 seconds with urxvt. H...

You have got the reversed results compared with mine...

What the heck slows down the output of the terminals on my 
Gentoo and only let urxvt shine? 

Cheers
Meino

PS: I found XVilka before. That's why I asked for some experiences
of other users :)









Re: [gentoo-user] replacement for ftp?

2017-04-25 Thread Danny YUE

On 2017-04-25 19:59, R0b0t1  wrote:
> On Tue, Apr 25, 2017 at 10:05 AM, Danny YUE  wrote:
>>
>> On 2017-04-25 14:29, lee  wrote:
>>> Hi,
>>>
>>> since the usage of FTP seems to be declining, what is a replacement
>>> which is at least as good as FTP?
>>>
>>> I'm aware that there's webdav, but that's very awkward to use and
>>> missing features.
>>
>> What about sshfs? It allows you to mount a location that can be accessed
>> via ssh to your local file system, as if you are using ssh.
>>
>
> In a similar vein, scp.

And considering something still robust but a little more smart, rsync.



Re: [gentoo-user] GCC won't compile, don't understand the error

2017-04-25 Thread Dale
Kaizu Shibata wrote:
>
> Dale:
>> Kaizu Shibata wrote:
>>> I'm having trouble with an update. I can't seem to build the new gcc,
>>> and I don't understand the error. For some reason, a process has been
>>> killed. I do not know why this is.
>>>
>>> make[3]: *** [Makefile:2176: s-attrtab] Killed
>>> make[3]: *** Waiting for unfinished jobs
>>> /bin/bash
>>> /var/tmp/portage/sys-devel/gcc-5.4.0-r3/work/gcc-5.4.0/gcc/../move-if-change
>>> tmp-automata.c insn-automata.c
>>> echo timestamp > s-automata
>>> rm gcc.pod
>>> make[3]: Leaving directory
>>> '/var/tmp/portage/sys-devel/gcc-5.4.0-r3/work/build/gcc'
>>> make[2]: *** [Makefile:4367: all-stage1-gcc] Error 2
>>> make[2]: Leaving directory
>>> '/var/tmp/portage/sys-devel/gcc-5.4.0-r3/work/build'
>>> make[1]: *** [Makefile:18753: stage1-bubble] Error 2
>>> make[1]: Leaving directory
>>> '/var/tmp/portage/sys-devel/gcc-5.4.0-r3/work/build'
>>> make: *** [Makefile:19085: bootstrap-lean] Error 2
>>>  * ERROR: sys-devel/gcc-5.4.0-r3::gentoo failed (compile phase):
>>>  *   emake failed
>>>  *
>>>  * If you need support, post the output of `emerge --info
>>> '=sys-devel/gcc-5.4.0-r3::gentoo'`,
>>>  * the complete build log and the output of `emerge -pqv
>>> '=sys-devel/gcc-5.4.0-r3::gentoo'`.
>>>  * The complete build log is located at
>>> '/var/tmp/portage/sys-devel/gcc-5.4.0-r3/temp/build.log'.
>>>  * The ebuild environment file is located at
>>> '/var/tmp/portage/sys-devel/gcc-5.4.0-r3/temp/environment'.
>>>  * Working directory: '/var/tmp/portage/sys-devel/gcc-5.4.0-r3/work/build'
>>>  * S: '/var/tmp/portage/sys-devel/gcc-5.4.0-r3/work/gcc-5.4.0'
>>>  *
>>>  * Please include
>>> /var/tmp/portage/sys-devel/gcc-5.4.0-r3/work/gcc-build-logs.tar.bz2 in
>>> your bug report.
>>>
>>
>> You need to look back further.  There is a error further up the output. 
>> Look for Error 1 and then go back a little further still.  Sometimes it
>> can start a dozen or more lines back. 
>>
>> Dale
>>
>> :-)  :-) 
> There was no error in the build log, however I found an out of memory
> error in dmesg. I've created a swap file.
>
>

I saw error 2, usually there is a error 1.  Sometimes its hard to find
though.  It can be buried.  That said, if it ran out of memory, it may
not be there anymore.  It may have burped it out.  lol 

I hate when I run out of memory.  I have 16GBs here and I still run
short at times.  :/  Either way, glad you figured it out and hope it got
you back on the right path again. 

Dale

:-)  :-) 



Re: [gentoo-user] GCC won't compile, don't understand the error

2017-04-25 Thread Kaizu Shibata


Dale:
> Kaizu Shibata wrote:
>> I'm having trouble with an update. I can't seem to build the new gcc,
>> and I don't understand the error. For some reason, a process has been
>> killed. I do not know why this is.
>>
>> make[3]: *** [Makefile:2176: s-attrtab] Killed
>> make[3]: *** Waiting for unfinished jobs
>> /bin/bash
>> /var/tmp/portage/sys-devel/gcc-5.4.0-r3/work/gcc-5.4.0/gcc/../move-if-change
>> tmp-automata.c insn-automata.c
>> echo timestamp > s-automata
>> rm gcc.pod
>> make[3]: Leaving directory
>> '/var/tmp/portage/sys-devel/gcc-5.4.0-r3/work/build/gcc'
>> make[2]: *** [Makefile:4367: all-stage1-gcc] Error 2
>> make[2]: Leaving directory
>> '/var/tmp/portage/sys-devel/gcc-5.4.0-r3/work/build'
>> make[1]: *** [Makefile:18753: stage1-bubble] Error 2
>> make[1]: Leaving directory
>> '/var/tmp/portage/sys-devel/gcc-5.4.0-r3/work/build'
>> make: *** [Makefile:19085: bootstrap-lean] Error 2
>>  * ERROR: sys-devel/gcc-5.4.0-r3::gentoo failed (compile phase):
>>  *   emake failed
>>  *
>>  * If you need support, post the output of `emerge --info
>> '=sys-devel/gcc-5.4.0-r3::gentoo'`,
>>  * the complete build log and the output of `emerge -pqv
>> '=sys-devel/gcc-5.4.0-r3::gentoo'`.
>>  * The complete build log is located at
>> '/var/tmp/portage/sys-devel/gcc-5.4.0-r3/temp/build.log'.
>>  * The ebuild environment file is located at
>> '/var/tmp/portage/sys-devel/gcc-5.4.0-r3/temp/environment'.
>>  * Working directory: '/var/tmp/portage/sys-devel/gcc-5.4.0-r3/work/build'
>>  * S: '/var/tmp/portage/sys-devel/gcc-5.4.0-r3/work/gcc-5.4.0'
>>  *
>>  * Please include
>> /var/tmp/portage/sys-devel/gcc-5.4.0-r3/work/gcc-build-logs.tar.bz2 in
>> your bug report.
>>
> 
> 
> You need to look back further.  There is a error further up the output. 
> Look for Error 1 and then go back a little further still.  Sometimes it
> can start a dozen or more lines back. 
> 
> Dale
> 
> :-)  :-) 
There was no error in the build log, however I found an out of memory
error in dmesg. I've created a swap file.



[gentoo-user] Re: replacement for ftp?

2017-04-25 Thread Kai Krakow
Am Tue, 25 Apr 2017 15:29:18 +0100
schrieb lee :

> since the usage of FTP seems to be declining, what is a replacement
> which is at least as good as FTP?
> 
> I'm aware that there's webdav, but that's very awkward to use and
> missing features.

If you want to sync files between two sites, try rsync. It is supported
through ssh also. Plus, it's very fast also.

-- 
Regards,
Kai

Replies to list-only preferred.




Re: [gentoo-user] replacement for ftp?

2017-04-25 Thread R0b0t1
On Tue, Apr 25, 2017 at 10:05 AM, Danny YUE  wrote:
>
> On 2017-04-25 14:29, lee  wrote:
>> Hi,
>>
>> since the usage of FTP seems to be declining, what is a replacement
>> which is at least as good as FTP?
>>
>> I'm aware that there's webdav, but that's very awkward to use and
>> missing features.
>
> What about sshfs? It allows you to mount a location that can be accessed
> via ssh to your local file system, as if you are using ssh.
>

In a similar vein, scp.



Re: [gentoo-user] GCC 5.4.0

2017-04-25 Thread Daniel Frey

On 04/25/2017 12:18 PM, Dale wrote:

Frank Steinmetzger wrote:

On Sun, Apr 23, 2017 at 06:59:16PM +0200, Andreas K. Huettel wrote:


My personal advice & experience:
* install the new gcc-5.4
* switch to it
* run the revdep-rebuild command from the news item (see above)
... and everything should be fine.

I do remember having seen the item. And I copied the revdep rebuild command
from it. But when I do `eselect news list`, there is no mention of the item
any more. Where is it?



It's got a old date, not sure why.  Anyway, that makes it appear in a
odd place.  Here it is this:

[33] 2015-10-22  GCC 5 Defaults to the New C++11 ABI

Hope that helps.

Dale

:-)  :-)



A copy of it is also here:

https://wiki.gentoo.org/wiki/Upgrading_from_gcc-4.x_to_gcc-5.x

Dan



Re: [gentoo-user] GCC won't compile, don't understand the error

2017-04-25 Thread Dale
Kaizu Shibata wrote:
> I'm having trouble with an update. I can't seem to build the new gcc,
> and I don't understand the error. For some reason, a process has been
> killed. I do not know why this is.
>
> make[3]: *** [Makefile:2176: s-attrtab] Killed
> make[3]: *** Waiting for unfinished jobs
> /bin/bash
> /var/tmp/portage/sys-devel/gcc-5.4.0-r3/work/gcc-5.4.0/gcc/../move-if-change
> tmp-automata.c insn-automata.c
> echo timestamp > s-automata
> rm gcc.pod
> make[3]: Leaving directory
> '/var/tmp/portage/sys-devel/gcc-5.4.0-r3/work/build/gcc'
> make[2]: *** [Makefile:4367: all-stage1-gcc] Error 2
> make[2]: Leaving directory
> '/var/tmp/portage/sys-devel/gcc-5.4.0-r3/work/build'
> make[1]: *** [Makefile:18753: stage1-bubble] Error 2
> make[1]: Leaving directory
> '/var/tmp/portage/sys-devel/gcc-5.4.0-r3/work/build'
> make: *** [Makefile:19085: bootstrap-lean] Error 2
>  * ERROR: sys-devel/gcc-5.4.0-r3::gentoo failed (compile phase):
>  *   emake failed
>  *
>  * If you need support, post the output of `emerge --info
> '=sys-devel/gcc-5.4.0-r3::gentoo'`,
>  * the complete build log and the output of `emerge -pqv
> '=sys-devel/gcc-5.4.0-r3::gentoo'`.
>  * The complete build log is located at
> '/var/tmp/portage/sys-devel/gcc-5.4.0-r3/temp/build.log'.
>  * The ebuild environment file is located at
> '/var/tmp/portage/sys-devel/gcc-5.4.0-r3/temp/environment'.
>  * Working directory: '/var/tmp/portage/sys-devel/gcc-5.4.0-r3/work/build'
>  * S: '/var/tmp/portage/sys-devel/gcc-5.4.0-r3/work/gcc-5.4.0'
>  *
>  * Please include
> /var/tmp/portage/sys-devel/gcc-5.4.0-r3/work/gcc-build-logs.tar.bz2 in
> your bug report.
>


You need to look back further.  There is a error further up the output. 
Look for Error 1 and then go back a little further still.  Sometimes it
can start a dozen or more lines back. 

Dale

:-)  :-) 



Re: [gentoo-user] GCC 5.4.0

2017-04-25 Thread Dale
Frank Steinmetzger wrote:
> On Sun, Apr 23, 2017 at 06:59:16PM +0200, Andreas K. Huettel wrote:
>
>> My personal advice & experience:
>> * install the new gcc-5.4
>> * switch to it
>> * run the revdep-rebuild command from the news item (see above)
>> ... and everything should be fine.
> I do remember having seen the item. And I copied the revdep rebuild command
> from it. But when I do `eselect news list`, there is no mention of the item
> any more. Where is it?
>

It's got a old date, not sure why.  Anyway, that makes it appear in a
odd place.  Here it is this:

[33] 2015-10-22  GCC 5 Defaults to the New C++11 ABI

Hope that helps.

Dale

:-)  :-) 



Re: [gentoo-user] In search of an truecolor-capable terminal emulator

2017-04-25 Thread R0b0t1
On Tue, Apr 25, 2017 at 10:47 AM,   wrote:
> Hi,
>
> currently I am using urxvt as my standard terminal
> application, which is FAST and reliable.
> But it only emulates 24bit colors if instructed so.
> It maps 24bit rgb to 256 color using a fast but not
> total correct formula to to do (which is no critism -
> its just the way ot is implemented).
>

I suppose you have seen https://gist.github.com/XVilka/8346728, but if
not, I will link it for you. Anyone following along who hasn't read it
might be inclined to do so.

> I googled qyite a bit to find 24color terminal
> emulators and the one, which came closer to
> what I want is sakure.
> But comparing the speed of sakura with urxvt
> (catting a long log file twice while measureing the time
> of the second cat) it shows that sakura needs
> six times more time than urxvt.
>
> Combining this with the compile sessions, which
> are one of the core features of Gentoo ;)))...
>

I would suggest looking at:
*) https://github.com/jwilm/alacritty
*) https://github.com/kovidgoyal/kitty

Both of which are OpenGL accelerated. Unfortunately I'm not entirely
sure why sakura is slow. Finding out might be worthwhile. Alacritty is
the shiniest, but unfortunately the rust build and setup process looks
very insecure, similar to Haskell. Take into account that those
languages are experimental.

> What I want is the "fastest" possible (...)
> terminal emulator supporting true color (24bit).
> I dont need fancy configuring options (two exception:
> TABS! and lightweighted) and I dont want KDE stuff (or
> any other bloated thing with thousands of dependencies...)
> I am simply using openbox.
>

Tabs are probably a stretch though I admit they are a useful feature.
I would recommend that if you find a Desktop Environment that has a
program you like you simply use it though the look may clash with your
other programs. It's hard enough to find programs that do what you
want on Linux.

> What are your experiences?
>

Nothing really seems to do what I want, and that may translate into
nothing really doing what you want.

> Any hint is heartly welcome! Thanks !
>
> Cheers
> Meino
>
> PS: The terminal emulator dont need to be part
> of Gentoo necessarily...if it is compilable
> by a human being withoyt super powers... ;)
>

Check the list on that gist - may as well keep trying them until you
find one that you like.



[gentoo-user] GCC won't compile, don't understand the error

2017-04-25 Thread Kaizu Shibata
I'm having trouble with an update. I can't seem to build the new gcc,
and I don't understand the error. For some reason, a process has been
killed. I do not know why this is.

make[3]: *** [Makefile:2176: s-attrtab] Killed
make[3]: *** Waiting for unfinished jobs
/bin/bash
/var/tmp/portage/sys-devel/gcc-5.4.0-r3/work/gcc-5.4.0/gcc/../move-if-change
tmp-automata.c insn-automata.c
echo timestamp > s-automata
rm gcc.pod
make[3]: Leaving directory
'/var/tmp/portage/sys-devel/gcc-5.4.0-r3/work/build/gcc'
make[2]: *** [Makefile:4367: all-stage1-gcc] Error 2
make[2]: Leaving directory
'/var/tmp/portage/sys-devel/gcc-5.4.0-r3/work/build'
make[1]: *** [Makefile:18753: stage1-bubble] Error 2
make[1]: Leaving directory
'/var/tmp/portage/sys-devel/gcc-5.4.0-r3/work/build'
make: *** [Makefile:19085: bootstrap-lean] Error 2
 * ERROR: sys-devel/gcc-5.4.0-r3::gentoo failed (compile phase):
 *   emake failed
 *
 * If you need support, post the output of `emerge --info
'=sys-devel/gcc-5.4.0-r3::gentoo'`,
 * the complete build log and the output of `emerge -pqv
'=sys-devel/gcc-5.4.0-r3::gentoo'`.
 * The complete build log is located at
'/var/tmp/portage/sys-devel/gcc-5.4.0-r3/temp/build.log'.
 * The ebuild environment file is located at
'/var/tmp/portage/sys-devel/gcc-5.4.0-r3/temp/environment'.
 * Working directory: '/var/tmp/portage/sys-devel/gcc-5.4.0-r3/work/build'
 * S: '/var/tmp/portage/sys-devel/gcc-5.4.0-r3/work/gcc-5.4.0'
 *
 * Please include
/var/tmp/portage/sys-devel/gcc-5.4.0-r3/work/gcc-build-logs.tar.bz2 in
your bug report.

# emerge --info '=sys-devel/gcc-5.4.0-r3::gentoo'
Portage 2.3.3 (python 3.4.5-final-0, hardened/linux/amd64/no-multilib,
gcc-4.9.4, glibc-2.23-r3, 4.8.17-hardened-r2-magickvm-0.04 x86_64)
=
 System Settings
=
System uname:
Linux-4.8.17-hardened-r2-magickvm-0.04-x86_64-Common_KVM_processor-with-gentoo-2.3
KiB Mem: 1009480 total,816432 free
KiB Swap: 375804 total,333160 free
Timestamp of repository gentoo: Mon, 24 Apr 2017 19:00:01 +
sh bash 4.3_p48-r1
ld GNU ld (Gentoo 2.26.1 p1.0) 2.26.1
app-shells/bash:  4.3_p48-r1::gentoo
dev-lang/perl:5.24.1-r1::gentoo
dev-lang/python:  2.7.12::gentoo, 3.4.5::gentoo
dev-util/pkgconfig:   0.28-r2::gentoo
sys-apps/baselayout:  2.3::gentoo
sys-apps/openrc:  0.23.2::gentoo
sys-apps/sandbox: 2.10-r3::gentoo
sys-devel/autoconf:   2.69::gentoo
sys-devel/automake:   1.11.6-r1::gentoo, 1.15::gentoo
sys-devel/binutils:   2.26.1::gentoo
sys-devel/gcc:4.9.4::gentoo
sys-devel/gcc-config: 1.7.3::gentoo
sys-devel/libtool:2.4.6-r3::gentoo
sys-devel/make:   4.2.1::gentoo
sys-kernel/linux-headers: 4.4::gentoo (virtual/os-headers)
sys-libs/glibc:   2.23-r3::gentoo
Repositories:

gentoo
location: /usr/portage
sync-type: rsync
sync-uri: rsync://rsync.gentoo.org/gentoo-portage
priority: -1000

ACCEPT_KEYWORDS="amd64"
ACCEPT_LICENSE="* -@EULA"
CBUILD="x86_64-pc-linux-gnu"
CFLAGS="-march=native -O2 -pipe"
CHOST="x86_64-pc-linux-gnu"
CONFIG_PROTECT="/etc"
CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/gconf
/etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo"
CXXFLAGS="-march=native -O2 -pipe"
DISTDIR="/usr/portage/distfiles"
FCFLAGS="-O2 -pipe"
FEATURES="assume-digests binpkg-logs config-protect-if-modified
distlocks ebuild-locks fixlafiles merge-sync news parallel-fetch
preserve-libs protect-owned sandbox sfperms strict unknown-features-warn
unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync xattr"
FFLAGS="-O2 -pipe"
GENTOO_MIRRORS="https://mirrors.lug.mtu.edu/gentoo/;
LANG="en_US.utf8"
LDFLAGS="-Wl,-O1 -Wl,--as-needed"
MAKEOPTS="-j5"
PKGDIR="/usr/portage/packages"
PORTAGE_CONFIGROOT="/"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times
--omit-dir-times --compress --force --whole-file --delete --stats
--human-readable --timeout=180 --exclude=/distfiles --exclude=/local
--exclude=/packages --exclude=/.git"
PORTAGE_TMPDIR="/var/tmp"
USE="acl amd64 berkdb bzip2 cli cracklib crypt cxx dri gdbm hardened
iconv ipv6 justify modules ncurses nls nptl openmp pam pax_kernel pcre
pie readline seccomp session ssl ssp tcpd unicode urandom xattr xtpax
zlib" ABI_X86="64" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x
ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel
intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem
ymfpci" APACHE2_MODULES="authn_core authz_core socache_shmcb unixd
actions alias auth_basic authn_alias authn_anon authn_dbm authn_default
authn_file authz_dbm authz_default authz_groupfile authz_host
authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock
deflate dir disk_cache env expires ext_filter file_cache filter headers
include info log_config logio mem_cache 

Re: [gentoo-user] In search of an truecolor-capable terminal emulator

2017-04-25 Thread Floyd Anderson

On Di, 25 Apr 17:47:22 +0200
tu...@posteo.de wrote:

Hi,

currently I am using urxvt as my standard terminal
application, which is FAST and reliable.
But it only emulates 24bit colors if instructed so.
It maps 24bit rgb to 256 color using a fast but not
total correct formula to to do (which is no critism -
its just the way ot is implemented).

I googled qyite a bit to find 24color terminal
emulators and the one, which came closer to
what I want is sakure.
But comparing the speed of sakura with urxvt
(catting a long log file twice while measureing the time
of the second cat) it shows that sakura needs
six times more time than urxvt.

Combining this with the compile sessions, which
are one of the core features of Gentoo ;)))...

What I want is the "fastest" possible (...)
terminal emulator supporting true color (24bit).
I dont need fancy configuring options (two exception:
TABS! and lightweighted) and I dont want KDE stuff (or
any other bloated thing with thousands of dependencies...)
I am simply using openbox.

What are your experiences?

Any hint is heartly welcome! Thanks !

Cheers
Meino

PS: The terminal emulator dont need to be part
of Gentoo necessarily...if it is compilable
by a human being withoyt super powers... ;)

I am using rxvt-unicode also as my main terminal emulator. Its true 
colour emulation bothers me also but just only a little bit.


As a second one, xfce4-terminal runs here from time to time (seldom). A 
quick time/cat test with a gcc-5.4.0 log file (approximately 25 MiB) 
shows surprisingly that xfce4-terminal runs six time faster than 
rxvt-unicode. Maybe one reason is that urxvt looks for URLs and email 
addresses to colourising them.


Maybe you can get a suggestion from [1].


References:
[1] 

--
Regards,
floyd




Re: [gentoo-user] GCC 5.4.0

2017-04-25 Thread Frank Steinmetzger
On Sun, Apr 23, 2017 at 06:59:16PM +0200, Andreas K. Huettel wrote:

> My personal advice & experience:
> * install the new gcc-5.4
> * switch to it
> * run the revdep-rebuild command from the news item (see above)
> ... and everything should be fine.

I do remember having seen the item. And I copied the revdep rebuild command
from it. But when I do `eselect news list`, there is no mention of the item
any more. Where is it?

-- 
Gruß | Greetings | Qapla’
Please do not share anything from, with or about me with any social network.

Computer publishers produce computer books that explain
what you didn’t understand in computer magazines.


signature.asc
Description: Digital signature


Re: [gentoo-user] GCC 5.4.0

2017-04-25 Thread Frank Steinmetzger
On Mon, Apr 24, 2017 at 04:07:03PM +, J. Roeleveld wrote:

> >> I've had the odd rebuild failure here & there, don't bother re-emerging
> >> it until revdep-rebuild has finished.  Any dependencies it needs would
> >> have been rebuilt by then and it should complete without problem.

> Usually an emerge -e @world works. But this time the dependency tree has
> some issues as I have had several failures. 

Here too. The revdep-rebuild only knows portage dependencies. But since it's
a rebuild of existing packages, I think it doesn't see any reason to alter
the order of merges. Thus we have the occasional failure because a
linked-with lib has not yet been rebuilt, so you get an undefined reference.

> Now just running the revdeprebuild line till it completes without error.
> Then will try an emerge -e again.

As I just found out: it will rebuild the entire list of packages again,
because gcc-5.4.0 supplies the same libstdc++.so.6 as did gcc-4 (only with
different ABI). To counteract that, I wrote the list of packages into a file
and feed that to emerge in smaller chunks. That way I can keep tabs ob which
packages have already been built (using genlop) and then remove those
packages from my list file for subsequent emerge runs.

-- 
Gruß | Greetings | Qapla’
Please do not share anything from, with or about me with any social network.

Laziness is the habit of resting before you are tired.


signature.asc
Description: Digital signature


Re: [gentoo-user] Re: GCC 5.4.0

2017-04-25 Thread Frank Steinmetzger
On Tue, Apr 25, 2017 at 08:51:22AM +0100, Peter Humphrey wrote:

> > >> Quite so, but it was an internal compiler error, so that may not help.
> > >> I'll remerge it when the machine's quiet and see.
> > > 
> > > It did help. It's emerged okay.
> > 
> > In my experience, internal GCC errors that show up intermittently
> > and/or only under heavly load usually means failing RAM (or more
> > rarely, some other hardware problem: something bad on the PCI bus,
> > failing swap parition, etc.).
> > 
> > I'd run memtest86 overnight, if I were you...
> 
> Oo-er! I hope it's not that: this box is only just out of guarantee.

I can confirm this. End of last year I experienced more and more internal
errors. Turned out that I indeed had a faulty RAM module. The fault was
shown by memtest86 almost instantly. I then rebuilt my system from scratch,
because I coulnd't know what parts of my system had already been affected.

Thankfully I have two of those 16 gig kits installed, so I can still run
comfortably on half the fumes.
-- 
Gruß | Greetings | Qapla’
Please do not share anything from, with or about me with any social network.

One cannot be too careful when choosing one’s enemies.


signature.asc
Description: Digital signature


Re: [gentoo-user] GCC 5.4.0

2017-04-25 Thread Dale
Philip Webb wrote:
> I've been following the thread re GCC 5.4.0 & after 'eix-sync' installed it.
> There's a news item warning that there's a new ABI
> & it mb necessary to run 'revdep-rebuild' if it fails with a linking error.
>
> The first pkg I tried to compile with 5.4.0 indeed failed at that point,
> so I followed the advice & ran
> 'revdep-rebuild --library 'llibstdc++.so.6' -- --exclude gcc'.
> It wanted to rebuild  223  pkgs & stalled with an unfound ebuild.
>
> I went back to GCC 4.9.3 & the pkg merged without any problem.
>
> What are other users' experiences using GCC 5.4.0 ?
>

I just did this myself.  After I switched to the new gcc, I ran
revdep-rebuild.  It had a large list of packages.  I was planning to do
a emerge -e world anyway, so I just did it instead.  No sense doing most
of it twice.  During the rebuild, I had a qt package to fail.  For some
reason, it was stuck on a old qt4 version, even tho a qt5 version was
there and ready to upgrade.  I went ahead and manually upgraded it then
restarted the emerge process again, since it didn't build many packages
before that one failed anyway.  It completed the whole emerge without a
single failure that time. 

I will say this, I had to switch to Fluxbox for a while.  KDE got pretty
weird.  I logged out, back in and it was really weird.  I got a few
pop-ups about things not starting correctly etc.  It was unusable at
that point.  I then went to Fluxbox and used it for a while.  Once the
emerge got mostly done, KDE started working correctly again.  As I
suspected, some things just didn't like the difference in the gcc
versions.  No surprise there really. 

The only hitch so far, digikam is complaining with this error. 

digikam: symbol lookup error: /usr/lib64/libdigikamcore.so.5.5.0:
undefined symbol:

I'm currently rebuilding it after revdep-rebuild said it needed it.  I
suspect it will work once that is done.  I hope so.  I got pics to
download from my camera. 

All in all, it got weird for a bit but in the end, it went fairly well. 
The one failure I had wasn't related to the gcc upgrade.  I still have
no idea why that one package was stuck on that qt4 version.  For anyone
using KDE and doing this, I'd do it from a console and have a time where
you either have a backup desktop to use or some time to let it sit and
compile and at least get most of KDE re-emerged.  For me at least, KDE
was unusable for a while there.

It's amazing that emerge can compile about 1500 packages and not have a
failure.  Those devs are really doing some good work back there.  :-D 

Oh, I skipped palemoon.  I'm not using it and may unmerge it anyway.  I
almost forgot that one.  That is talked about elsewhere in this thread. 

Dale

:-)  :-) 



[gentoo-user] In search of an truecolor-capable terminal emulator

2017-04-25 Thread tuxic
Hi,

currently I am using urxvt as my standard terminal
application, which is FAST and reliable.
But it only emulates 24bit colors if instructed so.
It maps 24bit rgb to 256 color using a fast but not
total correct formula to to do (which is no critism -
its just the way ot is implemented).

I googled qyite a bit to find 24color terminal
emulators and the one, which came closer to
what I want is sakure.
But comparing the speed of sakura with urxvt
(catting a long log file twice while measureing the time
of the second cat) it shows that sakura needs
six times more time than urxvt.

Combining this with the compile sessions, which
are one of the core features of Gentoo ;)))...

What I want is the "fastest" possible (...) 
terminal emulator supporting true color (24bit).
I dont need fancy configuring options (two exception:
TABS! and lightweighted) and I dont want KDE stuff (or 
any other bloated thing with thousands of dependencies...)
I am simply using openbox. 

What are your experiences?

Any hint is heartly welcome! Thanks !

Cheers
Meino

PS: The terminal emulator dont need to be part
of Gentoo necessarily...if it is compilable
by a human being withoyt super powers... ;)






Re: [gentoo-user] replacement for ftp?

2017-04-25 Thread Danny YUE

On 2017-04-25 14:29, lee  wrote:
> Hi,
>
> since the usage of FTP seems to be declining, what is a replacement
> which is at least as good as FTP?
>
> I'm aware that there's webdav, but that's very awkward to use and
> missing features.

What about sshfs? It allows you to mount a location that can be accessed
via ssh to your local file system, as if you are using ssh.

Also samba can be a replacement. I have a samba server on my OpenWRT
router and use mount.cifs to mount it...

May these be helpful.

Danny



Re: [gentoo-user] replacement for ftp?

2017-04-25 Thread Mick
On Tuesday 25 Apr 2017 16:45:37 Alan McKinnon wrote:
> On 25/04/2017 16:29, lee wrote:
> > Hi,
> > 
> > since the usage of FTP seems to be declining, what is a replacement
> > which is at least as good as FTP?
> > 
> > I'm aware that there's webdav, but that's very awkward to use and
> > missing features.
> 
> Why not stick with ftp?
> Or, put another way, why do you feel you need to use something else?
> 
> There's always dropbox


Invariably all web hosting ISPs offer ftp(s) for file upload/download.  If you 
pay a bit more you should be able to get ssh/scp/sftp too.  Indeed, many ISPs 
throw in scp/sftp access as part of their basic package.

Webdav(s) offers the same basic upload/download functionality, so I am not 
sure what you find awkward about it, although I'd rather use lftp instead of 
cadaver any day. ;-)

As Alan mentioned, with JavaScript'ed web pages these days there are many 
webapp'ed ISP offerings like Dropbox and friends.

What is the use case you have in mind?
-- 
Regards,
Mick

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


Re: [gentoo-user] replacement for ftp?

2017-04-25 Thread Alan McKinnon
On 25/04/2017 16:29, lee wrote:
> 
> Hi,
> 
> since the usage of FTP seems to be declining, what is a replacement
> which is at least as good as FTP?
> 
> I'm aware that there's webdav, but that's very awkward to use and
> missing features.
> 
> 

Why not stick with ftp?
Or, put another way, why do you feel you need to use something else?

There's always dropbox

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




[gentoo-user] replacement for ftp?

2017-04-25 Thread lee

Hi,

since the usage of FTP seems to be declining, what is a replacement
which is at least as good as FTP?

I'm aware that there's webdav, but that's very awkward to use and
missing features.


-- 
"Didn't work" is an error.



Re: [gentoo-user] Re: GCC 5.4.0

2017-04-25 Thread Peter Humphrey
On Monday 24 Apr 2017 21:09:36 Grant Edwards wrote:
> On 2017-04-24, Peter Humphrey  wrote:
> > On Monday 24 Apr 2017 16:45:58 I wrote:
> >> On Monday 24 Apr 2017 14:47:32 Mick wrote:
> >> > I've had the odd rebuild failure here & there, don't bother
> >> > re-emerging
> >> > it until revdep-rebuild has finished.  Any dependencies it needs
> >> > would
> >> > have been rebuilt by then and it should complete without problem.
> >> 
> >> Quite so, but it was an internal compiler error, so that may not help.
> >> I'll remerge it when the machine's quiet and see.
> > 
> > It did help. It's emerged okay.
> 
> In my experience, internal GCC errors that show up intermittently
> and/or only under heavly load usually means failing RAM (or more
> rarely, some other hardware problem: something bad on the PCI bus,
> failing swap parition, etc.).
> 
> I'd run memtest86 overnight, if I were you...

Oo-er! I hope it's not that: this box is only just out of guarantee.

-- 
Regards
Peter




Re: [gentoo-user] How to get rid of sys-fs/static-dev, or do I really need it?

2017-04-25 Thread Neil Bothwick
On Tue, 25 Apr 2017 01:30:07 +0200, wabe wrote:

> > Do you have virtual/udev installed? That should be enough to keep
> > virtual/dev-manager happy.  
> 
> Thanks for your answer. virtual/udev is already installed. Tomorrow
> I'll make a backup of my system and after that I'll remove
> sys-fs/static-dev.

I can't see it doing any harm, because any static nodes in /dev/ are
hidden once udev starts.


-- 
Neil Bothwick

Committee (noun): A group of people spending hours taking minutes


pgpVnEkquboGE.pgp
Description: OpenPGP digital signature