Bug 18511 - multixterm window unresponsive
Summary: multixterm window unresponsive
Status: RESOLVED OLD
Alias: None
Product: Mageia
Classification: Unclassified
Component: RPM Packages (show other bugs)
Version: 5
Hardware: i586 Linux
Priority: Normal critical
Target Milestone: ---
Assignee: Shlomi Fish
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-05-22 23:23 CEST by nikos papadopoulos
Modified: 2018-07-12 13:38 CEST (History)
1 user (show)

See Also:
Source RPM: expect-5.43.0-26.mga5.src.rpm
CVE:
Status comment:


Attachments
the unresponsive window (10.66 KB, image/jpeg)
2016-05-22 23:25 CEST, nikos papadopoulos
Details
the About window (13.54 KB, image/jpeg)
2016-05-22 23:52 CEST, nikos papadopoulos
Details

Description nikos papadopoulos 2016-05-22 23:23:55 CEST
Description of problem:
Executing " multixterm " will produce an unresponsive window (see attachments).



Version-Release number of selected component (if applicable):


How reproducible:
everytime


Steps to Reproduce:
1. execute  " multixterm " in a terminal
2. try to click on the window options, menus, etc; nothing happens
3. close the window (the window manager's buttons work)
Comment 1 nikos papadopoulos 2016-05-22 23:25:13 CEST
Created attachment 7836 [details]
the unresponsive window
Comment 2 nikos papadopoulos 2016-05-22 23:40:50 CEST
terminal output 1
---------------------------------------------------------------------

[bash 4.3]$ multixterm
hello

###### the window appears ######
###### then, I click on the area that says "stdin window", on the window ######

version conflict for package "Tk": have 8.5, need exactly 8.5.15
    while executing
"package require -exact Tk  8.5.15"
    (file "/usr/share/tk8.5/tk.tcl" line 18)
    invoked from within
"source /usr/share/tk8.5/tk.tcl"
    (in namespace eval "::" script line 1)
    invoked from within
"namespace eval :: $auto_index($name)"
    (procedure "auto_load" line 13)
    invoked from within
"auto_load $name [uplevel 1 {::namespace current}]"
    (autoloading "tk::ScreenChanged")
    (procedure "::unknown" line 30)
    invoked from within
"tk::ScreenChanged :0.0"
    (changing screen in event binding)

###### I close the window, with the window manager's |X| button ######

[bash 4.3]$ 

-----------------------------------------------------------------------
Comment 3 nikos papadopoulos 2016-05-22 23:41:41 CEST
terminal output 2
-----------------------------------------------------------------------

###### trying the command, with some options ######
###### no window come up, just this console output ######

[bash 4.3]$ multixterm -xv -xa -h
Application initialization failed: Command-specific options:
 -colormap: Colormap for main window
 -display:  Display to use
 -geometry: Initial geometry for window
 -name:     Name to use for application
 -sync:     Use synchronous mode for display server
 -visual:   Visual for main window
 --:        Pass all remaining arguments through to script
 -command:  Command(s) to execute immediately
 -diag:     Enable diagnostics
 -norc:     Don't read ~/.expect.rc
 -NORC:     Don't read system-wide expect.rc
 -version:  Print version and exit
 -Debug:    Enable debugger
Error in startup script: can't read "tk_version": no such variable
    while executing
"if {$tk_version < 8.3} {
    tkBad
} elseif {$tk_version == 8.3} {
    if {[lindex [split $tk_patchLevel .] 2] < 3} tkBad
}"
    (file "/usr/bin/multixterm" line 325)
[bash 4.3]$ 

-----------------------------------------------------------------------
Comment 4 nikos papadopoulos 2016-05-22 23:47:43 CEST
terminal output 3

This time the window appears... and it works!!!

-----------------------------------------------------------------------
[bash 4.3]$ multixterm -xv -command date
Application initialization failed: invalid command name "date"
main: verbose on
main: remaining args: -command date
main: /home/nikos/.multixtermrc: not found
xtermStartAll: xtermNames = "-command date"
xtermStart: starting new xterm running /bin/bash with name -command
xtermStart: spawn -pty: pid = 0, spawn_id = exp7
xtermStart: uniqueness of -command: 1
xtermStart: xterm: pid = 32083
xtermStart: /bin/bash: pid = 32085, spawn_id = exp8
xtermStart: starting new xterm running /bin/bash with name date
xtermStart: spawn -pty: pid = 0, spawn_id = exp9
xtermStart: uniqueness of date: 1
xtermStart: xterm: pid = 32093
xtermStart: /bin/bash: pid = 32095, spawn_id = exp10
hello
[bash 4.3]$
Comment 5 nikos papadopoulos 2016-05-22 23:52:12 CEST
Created attachment 7837 [details]
the About window

After the window has worked, the About dialogue will show this information, which contradict the error messages from the terminal.
Comment 6 Marja Van Waes 2016-05-23 10:47:34 CEST
Assigning to maintainer

CC: (none) => marja11
Assignee: bugsquad => shlomif

Comment 7 nikos papadopoulos 2016-05-23 12:35:36 CEST
I just saw here... https://sourceforge.net/projects/expect/files/Expect/
that the latest version of "expect" package is 5.45 (2010-11-09).
Comment 8 Shlomi Fish 2016-05-23 20:31:37 CEST
This works fine here on mga6 x86-64 on Xfce. I can try on an mga5 i586 vm as well.
Comment 9 Shlomi Fish 2016-05-23 20:35:05 CEST
OK, I can reproduce the problem on an mga5 i586 VM. I wonder if upgrading expect to the latest version fixes the problem - I'll have to check that.
Comment 10 Shlomi Fish 2016-05-23 20:40:33 CEST
(In reply to Shlomi Fish from comment #9)
> OK, I can reproduce the problem on an mga5 i586 VM. I wonder if upgrading
> expect to the latest version fixes the problem - I'll have to check that.

Checked now - upgrading to the latest self-built expect rpm does fix the problem there. Perhaps I should issue an update.
Comment 11 Shlomi Fish 2017-02-09 13:47:14 CET
Hi!

Sorry it took me so long but since so many packages depend on expect in Mageia, I believe that upgrading it in the stable release will be too intrusive. You can try updating to a local package or installing a newer version under a prefix.

Can I close this bug as WONTFIX?

Status: NEW => ASSIGNED

Comment 12 Marja Van Waes 2018-07-12 13:38:12 CEST
(In reply to Shlomi Fish from comment #11)
> Hi!
> 
> Sorry it took me so long but since so many packages depend on expect in
> Mageia, I believe that upgrading it in the stable release will be too
> intrusive. You can try updating to a local package or installing a newer
> version under a prefix.
> 
> Can I close this bug as WONTFIX?

Yes, a maintainer has the right to do that.

However, since Mga5 is no longer officially maintained now, I prefer to close it as OLD, because this bug isn't present in Mageia 6.

Status: ASSIGNED => RESOLVED
Resolution: (none) => OLD


Note You need to log in before you can comment on or make changes to this bug.