[gentoo-user] ...again compile problems due to texinfo...

2017-06-28 Thread tuxic
Hi,

previously the compilation of glibc failed, because docs
cpuld not be build.
This was caused in the context of texinfo.
"Solved" was this by not building the docs via
deinstallation of texinfo temporarily.

No screen jumps over the edge and again texinfo seems
to cause this:

>>> Source configured.
>>> Compiling source in 
>>> /var/tmp/portage/app-misc/screen-4.6.0/work/screen-4.6.0 ...
make -j6 comm.h term.h 
AWK=gawk CC="x86_64-pc-linux-gnu-gcc -march=native -O2 -pipe -D_GNU_SOURCE" 
srcdir=. sh ./comm.sh
AWK=gawk srcdir=. sh ./term.sh
make -j6 osdef.h 
CPP="x86_64-pc-linux-gnu-gcc -E -DMAXWIN=100 -DNONETHACK 
-DETCSCREENRC='"/etc/screenrc"' 
-DSCREENENCODINGS='"/usr/share/screen/utf8encodings"'" srcdir=. sh ./osdef.sh
make -j6 -C doc screen.info 
make: Entering directory 
'/var/tmp/portage/app-misc/screen-4.6.0/work/screen-4.6.0/doc'
makeinfo ./screen.texinfo -o screen.info
./screen.texinfo:3154: `@end' expected `deffn', but saw `example'
./screen.texinfo:3154: unmatched `@end example'
./screen.texinfo:3156: unmatched `@end deffn'
make: *** [Makefile:31: screen.info] Error 1
make: Leaving directory 
'/var/tmp/portage/app-misc/screen-4.6.0/work/screen-4.6.0/doc'
 * ERROR: app-misc/screen-4.6.0::gentoo failed (compile phase):
 *   emake failed
 * 
 * If you need support, post the output of `emerge --info 
'=app-misc/screen-4.6.0::gentoo'`,
 * the complete build log and the output of `emerge -pqv 
'=app-misc/screen-4.6.0::gentoo'`.
 * The complete build log is located at 
'/var/tmp/portage/app-misc/screen-4.6.0/temp/build.log'.
 * The ebuild environment file is located at 
'/var/tmp/portage/app-misc/screen-4.6.0/temp/environment'.
 * Working directory: '/var/tmp/portage/app-misc/screen-4.6.0/work/screen-4.6.0'
 * S: '/var/tmp/portage/app-misc/screen-4.6.0/work/screen-4.6.0'
 * 
 * The following package has failed to build, install, or execute postinst:
 * 
 *  (app-misc/screen-4.6.0:0/0::gentoo, ebuild scheduled for merge), Log file:
 *   '/var/tmp/portage/app-misc/screen-4.6.0/temp/build.log'
 * 

 * GNU info directory index is up-to-date.
 * After world updates, it is important to remove obsolete packages with
 * emerge --depclean. Refer to `man emerge` for more information.


How can I fix this ... by fixing it and not by uninstalling texinfo ?
;)

Cheers
Meino





[gentoo-user] Re: Copy'n'Paste...but not for all?

2017-06-28 Thread Nikos Chantziaras

On 29/06/2017 12:53 πμ, Neil Bothwick wrote:

On Wed, 28 Jun 2017 20:43:03 +0200, tu...@posteo.de wrote:


I dont like CTRL-V/CTRL-P that much...its a windows way.


Ctrl-C/Ctrl-V pre-dates Windows.


Yep: https://en.wikipedia.org/wiki/Control-C#In_graphical_environments




Re: [gentoo-user] Copy'n'Paste...but not for all?

2017-06-28 Thread Neil Bothwick
On Wed, 28 Jun 2017 20:43:03 +0200, tu...@posteo.de wrote:

> I dont like CTRL-V/CTRL-P that much...its a windows way.

Ctrl-C/Ctrl-V pre-dates Windows.


-- 
Neil Bothwick

Talk is cheap because supply exceeds demand.


pgp4j5C7EOegU.pgp
Description: OpenPGP digital signature


[gentoo-user] [Was: Radeon driver not happy] mesa-17.0.6 caused the mess!

2017-06-28 Thread Mick
On Tuesday 20 Jun 2017 15:57:46 Adam Carter wrote:
> On Sun, Jun 18, 2017 at 2:00 AM, Mick  wrote:
> > Since the last radeon/xorg/mesa update things have been rather ropey on
> > two
> > different boxen
>
> If you're changed kernels since you last rebuilt xorg-server (shown in the
> top of the Xorg.0.log file) then there's a very small chance rebuilding it
> will help. Otherwise just mask the new packages and downgrade.

I've updated to gentoo-sources-4.9.34 and emerged @x11-modules-rebuild for
good measure.  The desktop freezes continued at an annoying pace, on various
Gtk & Qt applications (LibreOffice, Qpdfview, Kwrite, Kmail).  Thankfully
Chromium and Firefox haven't had problems so far, probably because this
freezing takes place when hardware accelerated tooltips popup as the mouse
moves over the menu.

I have captured a backtrace which points to libdri and mesa-17.0.6.  Should I
file a bug, or shall I start keywording and trying later mesa versions?

Here's my current USE flags:

emerge -1aDv media-libs/mesa

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

Calculating dependencies... done!
[ebuild   R] media-libs/mesa-17.0.6::gentoo  USE="classic dri3 egl gallium
gbm gles2 llvm nptl vaapi vdpau wayland xvmc -bindist -d3d9 -debug -gles1 -
opencl -openmax -osmesa -pax_kernel -pic (-selinux) -valgrind -vulkan -xa"
ABI_X86="32 (64) (-x32)" VIDEO_CARDS="r600 radeon (-freedreno) -i915 -i965 -
imx -intel -nouveau -r100 -r200 -r300 -radeonsi (-vc4) (-vivante) -vmware" 0
KiB


Captured bt following a crash is also attached in case you can see something
obvious there.
--
Regards,
MickGNU gdb (Gentoo 7.12.1 vanilla) 7.12.1
Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-pc-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word".
(gdb) handle SIG33 pass nostop noprint
SignalStop  Print   Pass to program Description
SIG33 NoNo  Yes Real-time event 33
(gdb) set pagination 0
(gdb) attach 4108
Attaching to process 4108
[New LWP 4111]
[New LWP 4113]
[New LWP 4114]
[New LWP 4115]
[New LWP 4148]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Traceback (most recent call last):
  File "/usr/share/gdb/auto-load/usr/lib64/libeo.so.1.18.4-gdb.py", line 7, in 

import eo_gdb
ImportError: No module named 'eo_gdb'
syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
38  ../sysdeps/unix/sysv/linux/x86_64/syscall.S: No such file or directory.
(gdb) bt full
#0  syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
No locals.
#1  0x7f5d5d0fec9e in xshmfence_await () from /usr/lib64/libxshmfence.so.1
No symbol table info available.
#2  0x7f5d5d95d0ec in dri3_fence_await (buffer=0x2e1afd0, c=) at 
/var/tmp/portage/media-libs/mesa-17.0.6/work/mesa-17.0.6/src/loader/loader_dri3_helper.c:65
No locals.
#3  dri3_get_buffer (driDrawable=, draw=0x27c7f58, 
buffer_type=loader_dri3_buffer_front, format@98) at 
/var/tmp/portage/media-libs/mesa-17.0.6/work/mesa-17.0.6/src/loader/loader_dri3_helper.c:1285
buffer = 0x2e1afd0
buf_id = 4
dri_context = 0x1e4b290
#4  loader_dri3_get_buffers (driDrawable=, format@98, 
stamp=0x3007970, loaderPrivate=0x27c7f58, buffer_mask=2, 
buffers=0x7ffdd2b44800) at 
/var/tmp/portage/media-libs/mesa-17.0.6/work/mesa-17.0.6/src/loader/loader_dri3_helper.c:1371
draw = 0x27c7f58
front = 0x0
back = 0x0
#5  0x7f5d5ba0271a in dri_image_drawable_get_buffers 
(statts_count=, statts=, images=, 
drawable=) at 
/var/tmp/portage/media-libs/mesa-17.0.6/work/mesa-17.0.6/src/gallium/state_trackers/dri/dri2.c:351
pf = PIPE_FORMAT_B8G8R8X8_UNORM
buffer_mask = 2
i = 
image_format = 4098
bind = 10
#6  dri2_allocate_textures (ctx=0x1e4b2d0, drawable=0x3007970, 
statts=0x7ffdd2b44940, statts_count=1) at 
/var/tmp/portage/media-libs/mesa-17.0.6/work/mesa-17.0.6/src/gallium/state_trackers/dri/dri2.c:475
sPriv = 0x1e2d640
dri_drawable = 0x2702ad0
templ = {reference = {count = 10}, screen = 0xf291bc83a5348e00, target 
= PIPE_BUFFER, format = PIPE_FORMAT_NONE, width0 = 30914608, height0 = 0, 
depth0 = 0, array_size = 0, last_level = 0, nr_samples = 0, usage = 0, bind = 
0, flags = 30914632, next = 0x1d7b830}
alloc_depthstencil = 0 '\000'
i = 
j = 
bind = 32765
  

Re: [gentoo-user] Copy'n'Paste...but not for all?

2017-06-28 Thread tuxic
On 06/26 05:14, Nils Freydank wrote:
> Hi,
> 
> Am Sonntag, 25. Juni 2017, 20:12:38 CEST schrieb tu...@posteo.de:
> > [...]
> > 
> > Looks a little weird to me...
> > Is that an error, which fails to fail completly
> > or is a half working feature (or do I fail
> > in both cases ... ;) ?
> 
> all this sounds like the magic of different clipboards under X. I’m not into 
> the details anymore, so I’ll just drop link that looks useful (and mentions
> autocutsel as in x11-misc/autocutsel) to solve this:
> 
> https://bbs.archlinux.org/viewtopic.php?id=22682
> 
> -- 
> GPG fingerprint: '00EF D31F 1B60 D5DB ADB8  31C1 C0EC E696 0E54 475B'
> Nils Freydank


Hi,

oh thanks for all the input...it seems I am not alone (this time).

As said: My workaround is the URL input field of Firefox...

I dont like CTRL-V/CTRL-P that much...its a windows way. I am on 
UNIX. And VirtualBox/VMware/Vwhatever should use the way to do
it as the guest system would do it. It should translate
from select'n'copy to CTRL-V if the guest is Windows
and select'n'copy to click'n'Paste if it is a UNIX/Linux.
And Firefox should not "infect" UNIX/Linux with this
CTRL-C/CTRL-V-way-of-life if not running on Windows.

...but as I also think, that the HP42s was the best
pocket calculator ever made, this may only be
worth the two cents of the currency, which may vary
(or not). ;)

Cheers
Meino

PS: Who, who wants back the charm of a HP42s build
into modern electronic with a bigger display, more RAM
and run by open source software ("Free42" by Thomas
Okken) should check SwissMicros. They are currently
on the way to reinkarnate a new HP42s called DM42.
I am only an ethusiast and by no way affiliated with
SwissMicros. Check YouTube for DM42 for some short
impressions.
Can't wait for its birthday: Welcome back, HP42s!
:)
Sorry for the OT part...but...couldn't resist...;))









Re: [gentoo-user] Gentoo vs Raspbian on Raspberry Pi 3?

2017-06-28 Thread Peter Humphrey
On Wednesday 28 Jun 2017 06:21:00 Bill Kenworthy wrote:

> rpi1 ~ # genlop -t gcc
>  * sys-devel/gcc
> 
>  Fri Jul  1 10:01:57 2016 >>> sys-devel/gcc-4.9.3
>merge time: 1 day, 4 hours, 32 minutes and 26 seconds.
> 
>  Fri Nov  4 10:49:45 2016 >>> sys-devel/gcc-4.9.4
>merge time: 1 day, 4 hours, 43 minutes and 51 seconds.
> 
> rpi1 ~ #
> 
> rpi1 ~ # genlop -t glibc
>  * sys-libs/glibc
> 
>  Fri May 20 02:48:34 2016 >>> sys-libs/glibc-2.22-r4
>merge time: 5 hours, 30 minutes and 52 seconds.
> 
>  Thu Sep  1 20:07:48 2016 >>> sys-libs/glibc-2.22-r4
>merge time: 4 hours, 58 minutes and 44 seconds.
> 
>  Fri Jan 13 15:11:12 2017 >>> sys-libs/glibc-2.23-r3
>merge time: 5 hours, 19 minutes and 51 seconds.
> 
> rpi1 ~ #
> 
> pi model B (512M ram), ccache and distcc to a single vm with crossdev

Why not just NFS-export your $PORTDIR to a chroot on your host machine, and 
build everything there? --sync takes quite a while, but that would easily be 
recouped in compilation. That's what I do with a little Atom N270 box here.

$ genlop -t gcc -f /mnt/atom/var/log/emerge.log | grep minutes
[...]
   merge time: 13 minutes and 11 seconds.
   merge time: 13 minutes and 35 seconds.
   merge time: 12 minutes and 51 seconds.
   merge time: 14 minutes and 16 seconds.
   merge time: 14 minutes.
   merge time: 26 minutes and 49 seconds.
   merge time: 28 minutes and 41 seconds.

-- 
Regards
Peter