Re: [gentoo-user] Re: Argh, palemoon again ** 3 [Was: GCC 5.4.0]

[Walter Dnes]

On Wed, Apr 26, 2017 at 06:01:20AM +0800, Bill Kenworthy wrote

> That flag isn't mentioned here.

  I checked the source code.  It forces the old ABI, so it should work,
compiled with GCC 5.4.0, even on a Gcc 4.9.4 system...

[CentOS65][pmbuilder][~/pmmaster] grep -r GLIBCXX_USE_CXX11_ABI pmsrc
pmsrc/configure:   CXXFLAGS="$CXXFLAGS -D_GLIBCXX_USE_CXX11_ABI=0"
pmsrc/configure:   HOST_CXXFLAGS="$HOST_CXXFLAGS -D_GLIBCXX_USE_CXX11_ABI=0"
pmsrc/configure.in:   CXXFLAGS="$CXXFLAGS -D_GLIBCXX_USE_CXX11_ABI=0"
pmsrc/configure.in:   HOST_CXXFLAGS="$HOST_CXXFLAGS -D_GLIBCXX_USE_CXX11_ABI=0"

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

Re: [gentoo-user] replacement for ftp?

[Danny YUE]

On 2017-04-26 20:25, R0b0t1  wrote:
> On Tue, Apr 25, 2017 at 8:26 PM, Danny YUE  wrote:
>>
>> 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.
>>
>
> I was actually going to come back and suggest rscync over ssh. I
> didn't originally mention it because I typically associate rsync with
> backups.

I recently found that rsnapshot (based on rsync) is a good and solid
tool for backup...You may try it out ;-)

Re: [gentoo-user] replacement for ftp?

[Poison BL.]

On Tue, Apr 25, 2017 at 10:29 AM, 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.
>
>
> --
> "Didn't work" is an error.
>
>
The one issue I have with all the answers I've seen is that they all lack
the most important question. You're asking for alternatives for an old tool
that was used for many use cases that, these days, have evolved to have
very different requirements for security, integration of access methods,
and general workflows for use. FTP used to be the go-to for long distance
file sharing for *all* use cases, one to one (user managing a website's
content), many to one (upload site), one to many (download site), etc.
What's your use case?

-- 
Poison [BLX]
Joshua M. Murphy

Re: [gentoo-user] replacement for ftp?

[R0b0t1]

On Tue, Apr 25, 2017 at 8:26 PM, Danny YUE  wrote:
>
> 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.
>

I was actually going to come back and suggest rscync over ssh. I
didn't originally mention it because I typically associate rsync with
backups.

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

[tuxic]

On 04/26 06:22, Floyd Anderson wrote:
> On Mi, 26 Apr 04:38:29 +0200
> tu...@posteo.de wrote:
> > On 04/25 07:38, Floyd Anderson wrote:
> > > On Di, 25 Apr 17:47:22 +0200
> > > tu...@posteo.de wrote:
> > 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...
> Yes, my test (and probably my response to you) was too quick. I’m using
> ‘URxvt*skipScroll: false’ here (cannot recall exactly why), which defaults
> to ‘true’ normally. The same time-cat-test with `urxvt -ss` now finish
> within a second instead of 25. Just another example that shows
> comparing test results might be misleading, especially across multiple
> computers.
> 
> > What the heck slows down the output of the terminals on my
> > Gentoo and only let urxvt shine?
> That was one of my first thought when I was noticing the performance
> difference between virtual terminal and terminal emulator(s). I happily
> ended up by using rxvt-unicode after a relative short quest due to its low
> resource requirements (can additionally decreased by using urxvtd),
> extensibility, responsive and so on. And true colour — maybe some day; but
> to be honest, 256 colours is more than enough for a terminal, at least for
> me — even more as long as applications like Mutt, struggles by using only a
> dozen of different colours.
> 
> I’m sure the way answering this question will cost quite some time of
> comparisons and/or investigations — too much vectors and special cases, too
> much ‘too much’ for my taste (for a single feature).
> 
> One thing (as you can see by my test result above) is the configuration
> itself — one nondescript parameter with a so noticeable impact. Also, with
> different font sizes you’ll get different test results.
> 
> Other reasons may be hardware acceleration, the font handling/renderer
> (anti-aliasing, sub-pixel addressing, hinting, colouring, combining
> characters, buffering), graphical features (transparency, background image,
> scroll bar).
> 
> And the main question that follows those considerations: Which of the
> terminal appearance/behaviour is well documented and can be controlled by
> the user? This were my next starting point at the quest for a new emulator
> nowadays.
> 
> > PS: I found XVilka before. That's why I asked for some experiences
> > of other users :)
> Yes, I thought as much because it is one of the top web search results by
> now. I put it in for the case you haven’t recognised it and due to the
> terminal overview and its still ongoing discussion.
> 
> 
> -- 
> Regards,
> floyd
> 
> 

Hi FLoyd,

thanks for your words and explanations! :)

Yes, testing/comparing starts with syncing test conditions.
I didn't know about that config item of urxvt you mentioned, too.

urxvt displays smaller fonts more nicely than sakura (for example)
which may be point to different font rendering "engines"
(nowadays everything seems to be a "system" et least - if
not a complete "engin"...my mutt is a "mail composing engine
with a great configuration sustem"...hahahha).

Sakura seems currently the only one handling some of vims
colorschemes more correctly.

H...

Will what happens GL as suggested in a previous post...

Keep scrolling!!1 :)
Cheers
Meino

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

[Floyd Anderson]

On Mi, 26 Apr 04:55:46 +0200
tu...@posteo.de wrote:

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.

See my previous response for this.

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?
Just to clarify, I doesn’t suggest you to install/use xfce4-terminal. 
It was only used as a reference by and for me. But since you could be 
happy with xfce4-terminal, try to find out the reasons by:

 - selecting a bitmap font
 - turn off anti-aliasing
 - turn off fancy visual/graphical stuff
 - decrease the terminal size
for example and look if it hopefully makes any differences so you get a 
basis for your next decision(s). :-)


--
Regards,
floyd

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

[Fernando Rodriguez]

On 04/26/2017 11:27 AM, tu...@posteo.de wrote:

On 04/26 11:17, Fernando Rodriguez wrote:

On 04/25/2017 10:38 PM, tu...@posteo.de wrote:

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?


Possibly your use flags and/or openbox (if not using a GL compositor). Try
enabling all GL related flags for the terminal emulator and it's
dependencies and use a GL compositor like kwin or compiz. Modern graphics
cards are designed with modern software in mind. Many don't even have a 2D
engine anymore.





Cheers
Meino

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










--

Fernando Rodriguez



Hi Fernando,

thanks for the informations! :)

I am not using compiz or such

Openbox is installed as follows:

[I] x11-wm/openbox
 Available versions:  (3) 3.5.2-r1 (~)3.6 3.6.1 **
   {branding debug imlib nls session startup-notification static-libs svg xdg 
PYTHON_TARGETS="python2_7"}
 Installed versions:  3.6.1(3)(11:01:40 AM 02/18/2017)(nls session -branding -debug 
-imlib -startup-notification -static-libs -svg -xdg PYTHON_TARGETS="python2_7")
 Homepage:http://openbox.org/
 Description: A standards compliant, fast, light-weight, extensible 
window manager

My USE_FLAGS (make.conf) are:
USE="nvidia X lua sdl mp3 flac jack alsa gtk cairo sndfile qt3support kpathsea gif 
tga jpeg png jpeg2k mad dvb dvdr encode lzo bzip2 ogg sox v4l v4l2 vorbis x264 x265 
zsh-completion -hal -lirc"

Wpuld you suggest to change a flag?


I would start by enabling opengl globally. Then look at the dependency 
graph for the packages that you want to accelerate (especially the 
toolkits and the whole x11 stack) and if any of them have egl or gles 
and not opengl then enable it. You can't enable them all on make.conf 
because sometimes they conflict.





Thanks a lot for any help in advance!

Cheers
Meino



--

Fernando Rodriguez

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

[Floyd Anderson]

On Mi, 26 Apr 04:38:29 +0200
tu...@posteo.de wrote:

On 04/25 07:38, Floyd Anderson wrote:

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

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...
Yes, my test (and probably my response to you) was too quick. I’m using 
‘URxvt*skipScroll: false’ here (cannot recall exactly why), which 
defaults to ‘true’ normally. The same time-cat-test with `urxvt -ss` now 
finish within a second instead of 25. Just another example that shows
comparing test results might be misleading, especially across multiple 
computers.



What the heck slows down the output of the terminals on my
Gentoo and only let urxvt shine?
That was one of my first thought when I was noticing the performance 
difference between virtual terminal and terminal emulator(s). I happily 
ended up by using rxvt-unicode after a relative short quest due to its 
low resource requirements (can additionally decreased by using urxvtd), 
extensibility, responsive and so on. And true colour — maybe some day; 
but to be honest, 256 colours is more than enough for a terminal, at 
least for me — even more as long as applications like Mutt, struggles by 
using only a dozen of different colours.


I’m sure the way answering this question will cost quite some time of 
comparisons and/or investigations — too much vectors and special cases, 
too much ‘too much’ for my taste (for a single feature).


One thing (as you can see by my test result above) is the configuration 
itself — one nondescript parameter with a so noticeable impact. Also, 
with different font sizes you’ll get different test results.


Other reasons may be hardware acceleration, the font handling/renderer 
(anti-aliasing, sub-pixel addressing, hinting, colouring, combining 
characters, buffering), graphical features (transparency, background 
image, scroll bar).


And the main question that follows those considerations: Which of the 
terminal appearance/behaviour is well documented and can be controlled 
by the user? This were my next starting point at the quest for a new 
emulator nowadays.



PS: I found XVilka before. That's why I asked for some experiences
of other users :)
Yes, I thought as much because it is one of the top web search results 
by now. I put it in for the case you haven’t recognised it and due to 
the terminal overview and its still ongoing discussion.



--
Regards,
floyd

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

[Mick]

On Wednesday 26 Apr 2017 17:27:27 tu...@posteo.de wrote:

> I am not using compiz or such
> 
> Openbox is installed as follows:
> 
> [I] x11-wm/openbox
>  Available versions:  (3) 3.5.2-r1 (~)3.6 3.6.1 **
>{branding debug imlib nls session startup-notification static-libs
> svg xdg PYTHON_TARGETS="python2_7"} Installed versions:  3.6.1(3)(11:01:40
> AM 02/18/2017)(nls session -branding -debug -imlib -startup-notification
> -static-libs -svg -xdg PYTHON_TARGETS="python2_7") Homepage:   
> http://openbox.org/
>  Description: A standards compliant, fast, light-weight,
> extensible window manager
> 
> My USE_FLAGS (make.conf) are:
> USE="nvidia X lua sdl mp3 flac jack alsa gtk cairo sndfile qt3support
> kpathsea gif tga jpeg png jpeg2k mad dvb dvdr encode lzo bzip2 ogg sox v4l
> v4l2 vorbis x264 x265 zsh-completion -hal -lirc"
> 
> Wpuld you suggest to change a flag?
> 
> Thanks a lot for any help in advance!
> 
> Cheers
> Meino

If you're not using a compositor, but the terminal you are trying out wants 
one, then any compositing will take place in software, which will load the 
CPU.
-- 
Regards,
Mick

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

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

[tuxic]

On 04/26 11:17, Fernando Rodriguez wrote:
> On 04/25/2017 10:38 PM, tu...@posteo.de wrote:
> > 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?
> 
> Possibly your use flags and/or openbox (if not using a GL compositor). Try
> enabling all GL related flags for the terminal emulator and it's
> dependencies and use a GL compositor like kwin or compiz. Modern graphics
> cards are designed with modern software in mind. Many don't even have a 2D
> engine anymore.
> 
> 
> 
> > 
> > Cheers
> > Meino
> > 
> > PS: I found XVilka before. That's why I asked for some experiences
> > of other users :)
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> 
> 
> -- 
> 
> Fernando Rodriguez
> 

Hi Fernando,

thanks for the informations! :)

I am not using compiz or such

Openbox is installed as follows:

[I] x11-wm/openbox
 Available versions:  (3) 3.5.2-r1 (~)3.6 3.6.1 **
   {branding debug imlib nls session startup-notification static-libs svg 
xdg PYTHON_TARGETS="python2_7"}
 Installed versions:  3.6.1(3)(11:01:40 AM 02/18/2017)(nls session 
-branding -debug -imlib -startup-notification -static-libs -svg -xdg 
PYTHON_TARGETS="python2_7")
 Homepage:http://openbox.org/
 Description: A standards compliant, fast, light-weight, extensible 
window manager

My USE_FLAGS (make.conf) are:
USE="nvidia X lua sdl mp3 flac jack alsa gtk cairo sndfile qt3support kpathsea 
gif tga jpeg png jpeg2k mad dvb dvdr encode lzo bzip2 ogg sox v4l v4l2 vorbis 
x264 x265 zsh-completion -hal -lirc"

Wpuld you suggest to change a flag?

Thanks a lot for any help in advance!

Cheers
Meino

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

[Fernando Rodriguez]

On 04/25/2017 10:38 PM, tu...@posteo.de wrote:

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?


Possibly your use flags and/or openbox (if not using a GL compositor). 
Try enabling all GL related flags for the terminal emulator and it's 
dependencies and use a GL compositor like kwin or compiz. Modern 
graphics cards are designed with modern software in mind. Many don't 
even have a 2D engine anymore.






Cheers
Meino

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










--

Fernando Rodriguez

[gentoo-user] GCC 5.4.0 again

[Peter Humphrey]

Hello list,

I issued this command:

# revdep-rebuild --library 'libstdc++.so.6' -- --exclude="gcc gentoo-
sources" --jobs --load-average=48

...only to find that gentoo-sources was indeed emerged, though gcc wasn't. 
What's gone wrong here? I've always found that style of specifying 
exclusions to work before.

-- 
Regards
Peter