| Summary: | TDE doesn't open in Arch Linux when libice-1.0.10-1 package is installed | ||
|---|---|---|---|
| Product: | TDE | Reporter: | Lucas dos Santos <lucasrodrigo> |
| Component: | tdebase | Assignee: | Timothy Pearson <kb9vqf> |
| Status: | RESOLVED FIXED | ||
| Severity: | critical | CC: | bugwatch, buingoc67, lucasrodrigo, mrmazda, roma251078, rossi.f, schnet, slavek.banko, trin |
| Priority: | P1 | ||
| Version: | R14.0.x [Trinity] | ||
| Hardware: | amd64 | ||
| OS: | Linux | ||
| URL: | https://gitlab.freedesktop.org/xorg/lib/libice/issues/8, https://bugzilla.opensuse.org/show_bug.cgi?id=1142530 | ||
| Compiler Version: | TDE Version String: | 14.0.5-1 | |
| Application Version: | Application Name: | ||
| Bug Depends on: | |||
| Bug Blocks: | 3010 | ||
| Attachments: |
libICE6-1.0.9-4.7.i586.rpm
libICE6-1.0.9-4.7.x86_64.rpm |
||
|
Description
Lucas dos Santos
2019-07-23 11:58:03 CDT
Can you just try to rebuild Trinity packages with this new version of libice on a board? (In reply to Slávek Banko from comment #1) > Can you just try to rebuild Trinity packages with this new version of libice > on a board? Unfortunately I don't have the required knowledge to do this. But, another user just figured out what is wrong: http://trinity-users.pearsoncomputing.net/?0::15847 I reported this upstream. Stefan Dirsch in the openSUSE bug asks anyone to bisect in 5 steps libICE6's 31 commits between 1.0.9 and 1.0.10. (In reply to Felix Miata from comment #3) > I reported this upstream. Stefan Dirsch in the openSUSE bug asks anyone to > bisect in 5 steps libICE6's 31 commits between 1.0.9 and 1.0.10. Stefan mean finding this commit? https://cgit.freedesktop.org/xorg/lib/libICE/commit/?id=b484311c92 This issue was also confirmed on opensuse/KDE3 on Tumbleweed. There is apparently a libice issue. The bug report there is: https://bugzilla.opensuse.org/show_bug.cgi?id=1142530 Slávek,
Looking at the commit you reference, what the heck is:
+ const char *ICEauthority_name = ".ICEauthority";
and then
+ /* If it's in the XDG_RUNTIME_DIR, don't use a dotfile */
+ if ((name = getenv ("XDG_RUNTIME_DIR")))
+ ICEauthority_name++;
If that occurs, ICEauthority_name now points to next address in the .rodata sction where who knows what is stored. ICEauthority_name cannot be both a string-literal and have the pointer incremented as ICEauthority_name++.
That certainly looks suspicious.
(In reply to David C. Rankin from comment #6) > Slávek, > > Looking at the commit you reference, what the heck is: > > + const char *ICEauthority_name = ".ICEauthority"; > > and then > > + /* If it's in the XDG_RUNTIME_DIR, don't use a dotfile */ > + if ((name = getenv ("XDG_RUNTIME_DIR"))) > + ICEauthority_name++; > > If that occurs, ICEauthority_name now points to next address in the .rodata > sction where who knows what is stored. ICEauthority_name cannot be both a > string-literal and have the pointer incremented as ICEauthority_name++. > > That certainly looks suspicious. Because ICEauthority_name is defined as a pointer to char, then the increment should result in it then referring to the next character => omitting the leading dot in the filename. *** Bug 3044 has been marked as a duplicate of this bug. *** Although it might seem that if the same KDE3 problem in openSUSE is already solved, it will be possible to use the same TDE patch, it is not possible - the patch is inappropriate. The openSUSE-KDE3 patch fixes compatibility with libice >= 1.0.10, but it breaks compatibility with libice < 1.0.10. That's why we need a proper patch. Today I upgraded my 3 TW/TDE systems to TW20191112/14.0.6. Hosts gx620 and k8mmv suffered this problem after they were upgraded to libICE6-1.0.10-1.1, but I was able to work around by reverting to libICE6-1.0.9-4.7. On host gx78b, the upgrade to libICE6-1.0.10-1.1 is failing to cause the problem only if I login as root instead of normal user. As yet I've been unable to isolate any material difference between gx78b and the other two hosts. What should I be looking for?
# pinxi -SM
System: Host: gx78b Kernel: 5.2.14-1-default x86_64 bits: 64 Desktop: Trinity R14.0.6
Distro: openSUSE Tumbleweed 20191112
Machine: Type: Desktop System: Dell product: OptiPlex 780 v: N/A
Mobo: Dell model: 03NVJ6 v: A01 BIOS: Dell v: A15 date: 08/06/2013
# rpm -qa | grep libICE
libICE6-1.0.10-1.1.x86_64
# set | grep XDG
XDG_CONFIG_DIRS=/etc/xdg
XDG_CURRENT_DESKTOP=Trinity
XDG_DATA_DIRS=/opt/trinity/share:/usr/local/share:/usr/share
XDG_RUNTIME_DIR=/run/user/0
XDG_SEAT=seat0
XDG_SESSION_CLASS=greeter
XDG_SESSION_DESKTOP=tde
XDG_SESSION_ID=1
XDG_SESSION_TYPE=x11
XDG_VTNR=7
local -a dirs=(${BASH_COMPLETION_USER_DIR:-${XDG_DATA_HOME:-$HOME/.local/share}/bash-completion}/completions);
for dir in ${XDG_DATA_DIRS:-/usr/local/share:/usr/share};
# inxi -SM
System: Host: k8mmv Kernel: 5.2.14-1-default x86_64 bits: 64 Desktop: IceWM 1.5.4
Distro: openSUSE Tumbleweed 20191112
Machine: Type: Desktop Mobo: MICRO-STAR model: MS-7142 v: 1.00 serial: N/A BIOS: Phoenix v: 6.00 PG
date: 06/27/2006
# rpm -qa | grep libICE
libICE6-1.0.10-1.1.x86_64
# set | grep XDG
XDG_CONFIG_DIRS=/etc/xdg
XDG_CURRENT_DESKTOP=ICEWM
XDG_DATA_DIRS=/usr/local/share:/usr/share
XDG_RUNTIME_DIR=/run/user/0
XDG_SEAT=seat0
XDG_SESSION_CLASS=greeter
XDG_SESSION_DESKTOP=icewm
XDG_SESSION_ID=3
XDG_SESSION_TYPE=x11
XDG_VTNR=7
local -a dirs=(${BASH_COMPLETION_USER_DIR:-${XDG_DATA_HOME:-$HOME/.local/share}/bash-completion}/completions);
for dir in ${XDG_DATA_DIRS:-/usr/local/share:/usr/share};
(In reply to Lucas dos Santos from comment #2) > But, another user just figured out what is wrong: > http://trinity-users.pearsoncomputing.net/?0::15847 This is the relevant part of that URL: [quote]A workaround is to simply set an ICEAUTHORITY environment variable... export ICEAUTHORITY=/home/yourname/.ICEauthority I just added that variable to the top of my ~/.xinitrc file that I use with startx export ICEAUTHORITY=/home/grogan/.ICEauthority exec starttde[/quote] How can this be automated so that every user on every system doesn't have to discover the need and apply it to his own login configuration? The following is copied and pasted from the related openSUSE bug report: [copy]I believe the issue is in DCOP not using libice, but hardcode ICEAUTHORITY file instead. http://bugs.pearsoncomputing.net/show_bug.cgi?id=3044 explains how to fix this using libice. I wasn't able to find dcop, let alone the sources for it. Probably this died together with KDE3. https://en.wikipedia.org/wiki/DCOP[/copy] (In reply to Felix Miata from comment #12) > The following is copied and pasted from the related openSUSE bug report: > > [copy]I believe the issue is in DCOP not using libice, but hardcode > ICEAUTHORITY file instead. > > http://bugs.pearsoncomputing.net/show_bug.cgi?id=3044 > > explains how to fix this using libice. > Unfortunately this will not work. The dcop/KDE-ICE/authutil.c file contains the IceAuthFileName function of the same name. Here the difficulty lies in the compatibility of the DCOP header files with the libice header files. I think the implementation was not thought out. Theoretically, this can be made much simpler using ready-made libice functions and header files. Unfortunately, a lot of changes will be required to implement this. Please, what is the XDG_RUNTIME_DIR path on your distributions? On Debian, /run/user/$UID is used, and I have no idea whether this is the standard for all distributions or whether other ways of building a path are used on other distributions. /run/user/$UID for openSUSE Tumbleweed, Fedora 29 and Mageia 7. Hello everyone, I have this problem on a opensuse tumbleweed. As soon as i update the system. The export on .xinitrc not work, but plasma works fine. (fine is a way of say, i didnt like plasma) I dont know how revert the package libice Created attachment 2934 [details]
libICE6-1.0.9-4.7.i586.rpm
To install on openSUSE TW 32 bit, download, then as root:
rpm -Uvh --oldpackage libICE6-1.0.9-4.7.i586.rpm
Created attachment 2935 [details]
libICE6-1.0.9-4.7.x86_64.rpm
To install on openSUSE TW 64 bit, download, then as root:
rpm -Uvh --oldpackage libICE6-1.0.9-4.7.x86_64.rpm
Following installation of libICE6, the next zypper dup will upgrade it to the current version unless prior you lock it: zypper al libICE6. *** Bug 3053 has been marked as a duplicate of this bug. *** Dear, Thanks you. Now is Working. I will do not update Tumbleweed until tde gets fixed. And hope that get fixed soon Best regards, and thanks you Christian The major patches for solving this problem can be found in TGW as pull requests TDE/tdelibs#55 and TDE/tdebase#103: https://mirror.git.trinitydesktop.org/gitea/TDE/tdelibs/pulls/55 https://mirror.git.trinitydesktop.org/gitea/TDE/tdebase/pulls/103 Since libice 1.0.10 is already a part of Ubuntu 19.10 (Eoan), this has made it easier for me to verify the correct behavior of both libice >= 1.0.10 and libice < 1.0.10. Please, who can, test the patches in your distribution. OS Gentoo. I applied these patches to TDELIBS and TDEBASE packages. It works with the libice-1.0.10 package. (In reply to Roman from comment #23) > OS Gentoo. > I applied these patches to TDELIBS and TDEBASE packages. > It works with the libice-1.0.10 package. Great, thank you for testing. Pull request merged. Building updated packages for PSB and PTB repositories is in progress. RPM packages will be updated by François. Sorry for ask. Do you know witch time will take to reach the next TW update? Thanks you (In reply to Christian from comment #26) > Sorry for ask. Do you know witch time will take to reach the next TW update? > Thanks you Unfortunately, I don't know when François will update packages. However, very soon we plan to freeze for R14.0.7, so building packages will certainly follow for official release. |