Folks, we a have big problem. All gtk3+***** libs gtk+-3.18.7.ebuild gtk+-3.16.7.ebuild gtk+-3.18.6.ebuild breaks base core feature X11Forwarding over ssh. Step to reprod. Host_a(with xorg running server) ==> ssh -vvv -Y ==> host_b(lxc container) if !!!!! I install ANY gtk+3 series libs, I can not run no one gtk2-linked app. But java based GUI or FLTK apps work as expected, fine. ssh with -vvv flags say next: $ eclipse/eclipse debug3: receive packet: type 90 debug1: client_input_channel_open: ctype x11 rchan 3 win 65536 max 16384 debug1: client_request_x11: request from ::1 50513 debug2: fd 7 setting O_NONBLOCK debug3: fd 7 is O_NONBLOCK debug1: channel 1: new [x11] debug1: confirm x11 debug3: send packet: type 91 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ here wait infinity. PID exists. but! jconsole run as: $ jconsole debug3: receive packet: type 90 debug1: client_input_channel_open: ctype x11 rchan 3 win 65536 max 16384 debug1: client_request_x11: request from ::1 50514 debug2: fd 7 setting O_NONBLOCK debug3: fd 7 is O_NONBLOCK debug1: channel 1: new [x11] debug1: confirm x11 debug3: send packet: type 91 debug3: receive packet: type 90 debug1: client_input_channel_open: ctype x11 rchan 4 win 65536 max 16384 debug1: client_request_x11: request from ::1 50515 debug2: fd 8 setting O_NONBLOCK debug3: fd 8 is O_NONBLOCK debug1: channel 2: new [x11] debug1: confirm x11 debug3: send packet: type 91 debug2: channel 1: rcvd adjust 41772 debug2: channel 1: window 2047760 sent adjust 49392 debug2: channel 1: window 2032308 sent adjust 64844 ............... snip lot of output, jconsole works as expected. Also, X11-games work nice. I thinking, this is not problem of missconfigured software. I mean X11, ssh-ing... Remote GDB say me waiting on *gtk_init* library function. while(1){ If I do # emerge x11-libs/gtk+-3.18.7 - it compile & install without errors. but eclipse stop working. It is gtk2-linked. when I do # emerge -C =x11-libs/gtk+-3.18.7 - it remove lib and all gtk2-baset software continue to working again. } With besh whishes)
Strange... this looks to me more like this dri3 problem: https://bugzilla.redhat.com/show_bug.cgi?id=1221168 https://bugzilla.redhat.com/show_bug.cgi?id=1174257 https://bugs.freedesktop.org/show_bug.cgi?id=93261
(In reply to Pacho Ramos from comment #1) > Strange... this looks to me more like this dri3 problem: > https://bugzilla.redhat.com/show_bug.cgi?id=1221168 > https://bugzilla.redhat.com/show_bug.cgi?id=1174257 > https://bugs.freedesktop.org/show_bug.cgi?id=93261 AAAAAAAAA!!!!!!! THANKS!!!!!! This is DRI3 bug. Beer from me))) temporary solution and test results: 1-st test: $ SWT_GTK3=1 LIBGL_DRI3_DISABLE=1 eclipse/eclipse *** BUG *** In pixman_region32_init_rect: Invalid rectangle passed Set a breakpoint on '_pixman_log_error' to debug *** BUG *** In pixman_region32_init_rect: Invalid rectangle passed Set a breakpoint on '_pixman_log_error' to debug ....... skip lot of duplicated err records...... I can see GUI. Zoom of GUI elements aprox +15% 2-nd test: $ SWT_GTK3=0 LIBGL_DRI3_DISABLE=1 eclipse/eclipse I see no error & nice GUI. 3-rd test: SWT_GTK3=0 LIBGL_DRI3_DISABLE=0 eclipse/eclipse Result same as test 2. Should I close bug report? Who is manufacturer of this bug? GTK-team or Xorg-team? May be it kernel-related? I use $ uname -r 4.1.19 (Longterm), I not love extreme with kernel))) With besh whishes - Yuriy.
This is a bug in xorg-server it seems... or, at least, the patches that we need to get applied are for xorg-server :) Reassigning then https://patchwork.freedesktop.org/patch/67759/ https://patchwork.freedesktop.org/patch/67337/
(In reply to Pacho Ramos from comment #3) > This is a bug in xorg-server it seems... or, at least, the patches that we > need to get applied are for xorg-server :) > > Reassigning then > > https://patchwork.freedesktop.org/patch/67759/ > https://patchwork.freedesktop.org/patch/67337/ The 2nd one is in master (43eb5b6) but not the first one. A follow up patch was posted at : https://patchwork.freedesktop.org/patch/68504/ We could backport the patch that's in master but it will be useless if clients still report themselves as "local" when they aren't. TBH, I don't feel comfortable using patches that aren't even in master. I haven't really looked but I would feel better if we fixed sshd to use this trick instead: https://cgit.freedesktop.org/xorg/xserver/commit/?id=e2c7d70e5ddb8b17676a13ceebfbb87d14d63243 CCing @base-system: have you guys seen patches float about this ? Cheers
As I think, we are need more control DRI3 USE-flag. My investigation of kernel documentation follow me to support DRI3 in kernel for versios >=4.3 (redhat & ubuntu bugzilla) Today, we are need in GL libs .ebuild check, if (DRI3 enabled in kernel, AND kernel version >= 4.3) then we are can enable DRI3 by default. Else disable DRI3 in make.conf or packages.use. In my system, I DISABLE DRI3 on remote machine(make.conf). This is allow me to run gtk3+ apps over ssh. Patch for Xorg for exclusive ONE ssh app, I think, not elegant solution. With best wishes - Yuriy.
i'm not seeing changes for ssh ... those patches are all for xorg. what am i missing ?
(In reply to SpanKY from comment #6) > i'm not seeing changes for ssh ... those patches are all for xorg. what am > i missing ? As posted Rémi Cardona one comment above, https://patchwork.freedesktop.org/patch/68504/ This patch exactly.
This patch is for xorg-server and works around the issue by treating executables named "ssh" as non-local. Not very elegant I guess, but it will avoid the problem for most users.
(In reply to Yuriy Dmitriev from comment #7) that patch isn't for ssh. i'm not seeing why base-system@ is cc-ed here when there's nothing to be done (suggested or otherwise) in ssh itself.
(In reply to SpanKY from comment #9) ssh can do what is suggested in comment #4, namely use the two new values for byte order in order to denote whether the client is local or not. It doesn't strike me as particularly elegant either, though.
(In reply to Chí-Thanh Christopher Nguyễn from comment #10) those aren't patches against ssh which is what i was asking. but if those aren't upstream, i don't see Gentoo carrying them either, and X is still going to have to make changes if they want to work on all distros. the X guys really should be filing bugs on the openssh bugzilla and posting patches there or on the mailing list.
That's why I CCed base-system, to ask if you'd seen patches (through a list or a bug tracker) that implements the change suggested in https://cgit.freedesktop.org/xorg/xserver/commit/?id=e2c7d70e5ddb8b17676a13ceebfbb87d14d63243 I've taken a quick look at the openssh code base (the portable version mirrored on github) and didn't see any support for this (though I think I only looked at the ssh client side). I could not find any reference to this on the openssh mailing list either. As the packager of ssh, I felt you had more chances of finding the right info than the rest of us. Cheers
Thanks to all, folks. I trust, my love Gentoo in safe hands) With best wishes - Yuriy.
(In reply to Rémi Cardona from comment #12) the best place to submit patches is probably their bugzilla: https://bugzilla.mindrot.org/
Fixed upstream in 1.19.0.
