Ubuntu

emacs23/24 and other GTK applications do not start when run in Kubuntu 13.04 with oxygen-gtk theme enabled

Reported by Paul White on 2013-03-03
458
This bug affects 96 people
Affects Status Importance Assigned to Milestone
GNU Emacs
Fix Released
High
easytag
New
Undecided
Unassigned
emacs23 (Ubuntu)
Undecided
Unassigned
Raring
Undecided
Unassigned
emacs24 (Ubuntu)
Undecided
Unassigned
Raring
Undecided
Unassigned
gtk2-engines-oxygen (Debian)
Fix Released
Unknown
oxygen-gtk3 (Ubuntu)
Undecided
Unassigned
Raring
Undecided
Unassigned

Bug Description

[Impact]

* Emacs24 does not startup in KDE

[Test Case]

* Install emacs24
* Set gtk3 theme to oxygen-gtk via systemsettings > Application Appearence > GTK
* Run emacs24
* Install update
* Try and run emacs24 again

[Regression Potential]
* Minimal
* Upstream release for oxygen-gtk3 is only a bug fix release

If I try to run emacs23 in Kubuntu 13.04, (KDE 4.10.0) I am finding that the GUI starts only some of the time.

If the GUI doesn't start then I will only see a process running in htop or similar.

Starting emacs in a terminal window with the -nw argument or installing the Lucid interface shows that emacs does run each time it starts so the problem is either with the emacs GTK interface or the GTK libraries.

Emacs24 exhibits the same problem.

ProblemType: Bug
DistroRelease: Ubuntu 13.04
Package: emacs23 (not installed)
ProcVersionSignature: Ubuntu 3.8.0-9.18-generic 3.8.1
Uname: Linux 3.8.0-9-generic x86_64
ApportVersion: 2.9-0ubuntu2
Architecture: amd64
Date: Sun Mar 3 14:19:01 2013
InstallationDate: Installed on 2013-01-05 (57 days ago)
InstallationMedia: Kubuntu 13.04 "Raring Ringtail" - Alpha amd64 (20130104)
MarkForUpload: True
ProcEnviron:
 LANGUAGE=en_GB:en
 TERM=screen-256color
 PATH=(custom, no user)
 LANG=en_GB.UTF-8
 SHELL=/bin/bash
SourcePackage: emacs23
UpgradeStatus: No upgrade log present (probably fresh install)

Paul White (paulw2u) on 2013-03-03
tags: added: kubuntu
tbjablin (tjablin) wrote :

I can confirm this bug. Switch the gtk theme to Raliegh causes emacs to start reliably. The relevant part of the gdb backtrace is:

#0 0x00007f48f1bf63cd in poll () from /lib/x86_64-linux-gnu/libc.so.6
#1 0x00007f48f50e915c in g_main_context_poll (n_fds=1, fds=0xee1330, timeout=-1, context=0xd51620, priority=<optimized out>)
    at /build/buildd/glib2.0-2.35.8/./glib/gmain.c:3995
#2 g_main_context_iterate (context=0xd51620, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>)
    at /build/buildd/glib2.0-2.35.8/./glib/gmain.c:3696
#3 0x00007f48f50e963a in g_main_loop_run (loop=0xee1280) at /build/buildd/glib2.0-2.35.8/./glib/gmain.c:3895
#4 0x00007f48f512b101 in g_spawn_sync (working_directory=working_directory@entry=0x0, argv=<optimized out>, envp=envp@entry=0x0,
    flags=flags@entry=G_SPAWN_SEARCH_PATH, child_setup=child_setup@entry=0x0, user_data=user_data@entry=0x0,
    standard_output=standard_output@entry=0x7fffd2ec6ad8, standard_error=standard_error@entry=0x0, exit_status=exit_status@entry=0x0,
    error=error@entry=0x0) at /build/buildd/glib2.0-2.35.8/./glib/gspawn.c:434
#5 0x00007f48f512b578 in g_spawn_command_line_sync (command_line=<optimized out>, standard_output=0x7fffd2ec6ad8, standard_error=0x0,
    exit_status=0x0, error=0x0) at /build/buildd/glib2.0-2.35.8/./glib/gspawn.c:735
#6 0x00007f48e9bca184 in Oxygen::QtSettings::kdeConfigPathList() const ()

I believe this patch to glib is ultimately responsible: https://git.gnome.org/browse/glib/commit/glib/gspawn.c?id=ce0022933c255313e010b27f977f4ae02aad1e7e

Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in emacs23 (Ubuntu):
status: New → Confirmed
Andy Choens (andy-choens) wrote :

This bug affects me too. If there is an update to glib (or anything else) I am willing to be a tester.

Recent tests show that the problem is with the oxygen-gtk themes (GTK2 and GTK3).

When other themes are enabled both the GUI for emacs23 and emacs24 start every time.

summary: - emacs23 does not start reliably when run in Kubuntu 13.04
+ emacs23 does not start reliably when run in Kubuntu 13.04 with oxygen-
+ gtk theme enabled
no longer affects: oxygen-gtk3 (Ubuntu)
Paul White (paulw2u) on 2013-03-21
summary: - emacs23 does not start reliably when run in Kubuntu 13.04 with oxygen-
- gtk theme enabled
+ emacs23/24 GUI does not start when run in Kubuntu 13.04 with oxygen-gtk
+ theme enabled
tags: added: oxygen

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in emacs24 (Ubuntu):
status: New → Confirmed
Changed in gtk2-engines-oxygen (Ubuntu):
status: New → Confirmed
Changed in oxygen-gtk3 (Ubuntu):
status: New → Confirmed
2 comments hidden view all 154 comments
Andy Choens (andy-choens) wrote :

If someone could offer a suggestion on how to approach looking into this, I'll try to help in anyway that I can. I don't know squat about theming or GTK theme engines, but this affects me and I'd like to get it resolved. Pitching in is one way to help make that happen, so here I am.

Paul White (paulw2u) wrote :

Andy, we need to establish exactly in which package the bug lies. I added the gkt-engines package after a little research. I might be right, I might be wrong, I really don't know. The bug probably isn't in emacs itself anyway.

Seeing that there are just four weeks to go before Kubuntu 13.04 is released and that only three of us have acknowledged the bug I fear that it won't be fixed in time. I think there needs to be more testing to establish under what conditions emacs will or will not run and then some research done to establish which package is at fault.

I've done my bit, I believe Kubuntu's oxygen themes to be the problem.

Andy Choens (andy-choens) wrote :

That is too bad. In the meantime, I guess I will force GTK3 apps to use the Adwaita theme. Seems to work and looks better than a plain, unthemed GTK3.

tags: added: oxygenreg ression-release
removed: oxygen
tags: added: regression-release
removed: ression-release
tags: added: oxygen
removed: oxygenreg
Mikael Gerdin (mgerdin) wrote :

Proably affects Firefox and Thunderbird too, see Bug 963736

Alain (alaindelplanque) wrote :

I have the same problem. Both with emacs23 and emacs24

Alain (alaindelplanque) wrote :

When I compile emacs24.3, the problem remains with
./configure --with-x-toolkit=gtk2
./configure --with-x-toolkit=gtk3

emacs doesnt start, no error report in the console

When I use
./configure --with-x-toolkit=athena
It's OK

Imad (imaduddinh) wrote :

Just upgraded to Kubuntu 13.04 today and find that Emacs24 is no longer usable.

As tbjablin states above, switching to Raleigh theme provides a workaround.

13 comments hidden view all 154 comments

after i use the do-release-upgrade to upgrade from 12.10 to 13.04.
the hime and gcin no longer work.
just ibus can work.
is there any package or config i need to remove in 13.04?
or this is a bug in 4.10.2 13.04 version?

Reproducible: Always

This gcin input method server is not created by the KDE community. For help, please ask in the forums of your distribution at http://ubuntuforums.org/

If you believe there is a bug, please report any issues related to gcin directly to the bug tracker of your distribution via https://bugs.launchpad.net/ubuntu

i have found the bug of this problem.
it seems the .gtkrc-2.0 config has something error with the hime.
and i found that file is create by the kde gtk config.
is this kde problem or the input method problem?

> is create by the kde gtk config

Can you be more specific what you do to create the broken .gtkrc file?

Created attachment 79489
this is the config that cause the hime could not start.

if this config remove or let it broken.
the hime turn normal.

i also try the livecd kubuntu.
it will cause this problem too.
because the ubuntu unity did not has oxygen style.
so i did not try.

Bugs for the GTK configuration in System Settings are not tracked at the KDE bug tracker, because the GTK configuration module is a distribution-specific add-on.

Please report this issue directly to the bug tracker of your distribution via https://bugs.launchpad.net/ubuntu

Other than that, I fail to see any error in the attached .gtkrc configuration file. If other components fail to correctly initialize because of this file, they are probably disabled by default, and need to be enabled in the .gtkrc file.

i am i little sure about the gtk error.
when i change the style to the Raleigh, which is the gtk default on the kde.
and the hime error is gone.
are you sure that is not the kde problem?

and the .xsession-error is continue show this message
QPixmap: It is not safe to use pixmaps outside the GUI thread

this is the error maybe opening the gtk config
systemsettings(332)/kcontrol KCModuleLoader::loadModule: This module still uses K_EXPORT_COMPONENT_FACTORY. Please port it to use KPluginFactory and K_EXPORT_PLUGIN.

and since upgrade to the 13.04.
the kde has crash frequently because of the gtk.

22 comments hidden view all 154 comments
Kevin Hearn (kbhearn) wrote :

Also recently upgraded to Kubuntu 13.04 and am having a similar issue with another gtk2 application (eboard) - how do i go about changing the theme engine to try to work around it?

Kevin Hearn (kbhearn) wrote :

Nevermind, found it. It is the same bug that was causing eboard to freeze, switching to Raleigh fixed it.

22 comments hidden view all 154 comments

i have found the error in the oxygen-engines-gtk the settings.
gtkrc file
inside " style "oxygen-default" "
"
     engine "oxygen-gtk"
     {}
"
this two line cause the gtk engine error.
without this two line.
the hime work normal

21 comments hidden view all 154 comments
Olof Staffans (olof-staffans) wrote :

I've got the same problems (see Bug 1173857).

Sorry for my ignorance, but how do I change the theme from oxygen to something else?

I just did some testing to se what causes emacs23 to hang:

- If I start emacs from a terminal, then it most of the time does to open a new window.
- emacs -nw from a terminal works fine (as also noticed above)
- If I start emacs from the kubuntu menu, then it (almost) always starts, and does not hang immiately. After that there are many things that I can do before Emacs hangs, such as:

- compose an E-mail message (using M-X mail). It hangs only when I try to send the mail (using Ctl-C).
- Write some text in the scratch-window, and save it to the disk.
- I can edit some more, and do a "recover file" to get back what I saved earlier, and it still works fine.
- Many of the the help menues under Ctl-H work fine. However, Ctl-H r makes it hang. After that I have to wait some time before it again starts properly.
- The window splitting commands work fine.

However, there are certain commands that always make Emacs hang:

- Find file (Ctl-X Ctl-F)
- Visit File (Ctl-X Ctl-V)
- Dired
- Sending of Mail
- Ctl-H r (Display the Emacs manual in Info mode.)

Colin Bell (colbell) wrote :

>> Olof Staffans (olof-staffans) wrote 22 minutes ago:
>> Sorry for my ignorance, but how do I change the theme from oxygen to something else?

Go into the KDE System settings.
Then click "Application Appearance" under the "Common Appearance and Behavior"
Then click GTK.

I changed the GTK2 theme to Raleigh and the GTK3 to Emacs. I'm not sure which of the two was required but Emacs now works for me.

BTW I noticed that emacs-snapshot didn't have this problem.

Olof Staffans (olof-staffans) wrote :

For me it was enought to switch GTK3 to "Emacs". The GTK2 was already someting else than oxygen-gtk.

20 comments hidden view all 154 comments

we need a backtrace of what is really causing the failure to start.
Can you try run hime and gcin from gdb, then "bt" (after the program crashed), and post the result here ?

Also: what is the version of oxygen-gtk that you are using ?

19 comments hidden view all 154 comments
Vasilis Vasaitis (vvas) wrote :

Same problem here, with Kubuntu 13.04 and the oxygen-gtk theme. All the mentioned workarounds work, but of course they're just workarounds. (In my case I addressed this by using the emacs-snapshot package from ppa:cassou/emacs, which doesn't exhibit the problem for whatever reason).

Jan Schneider (yunosh) wrote :

The same behavior can be seen when using the QtCurve GTK theme.

93 comments hidden view all 154 comments

Yeah, me too. Maybe will appear later. You still can pull it in your local git and see the diff there.

@Ruslan
Thanks for fixing. My bad.
Too bad I was fixing at the same time.
So now: using size *=2, rather than incrementing linearly the size is known to be more efficient algorithmically. So I'd rather push that. (will do on top of your changes after first discarding the ones I was about to push)

Concerning the use of std::string.
There is No conversion from const char* to std::string in the current code
the call runCommand( "..." ) implicitely calls the std::string directly
as for the call string.c_str() it access directly the const char* stored internally in the string

the advantage of using std::string instead of const char* is that it is freed automatically. You do not need to call neither malloc nor free anywhere. In the current code it makes no difference (but not overhead either), but it might makes some future use of the same method.
All in all, that's the whole idea behind using c++ instead of c, and limit c to where you have to (namely when calling gtk, glib or other functions).

i fix by manual :))))

> So now: using size *=2, rather than incrementing linearly the size is known to be more efficient algorithmically.
Yeah, surely, but with chunks of 512 bytes this isn't gonna increase much more than to 2KiB, so this inefficiency can be neglected in favor of cleaner code.

> There is No conversion from const char* to std::string in the current code
> the call runCommand( "..." ) implicitely calls the std::string directly
> as for the call string.c_str() it access directly the const char* stored internally in the string
Why no conversion? You call runCommand("str") and this calls std::string("str") potentially doing some initialization there. And then you call a function which needs const char*, in which case although you don't convert, but this still is redundant.

> All in all, that's the whole idea behind using c++ instead of c, and limit c to where you have
> to (namely when calling gtk, glib or other functions).
Yeah I do understand this, but you have a POSIX function here - this is just like gtk function, and we pass string literal here, for which std::string has no advantage at all.

(In reply to comment #90)
> > So now: using size *=2, rather than incrementing linearly the size is known to be more efficient algorithmically.
> Yeah, surely, but with chunks of 512 bytes this isn't gonna increase much
> more than to 2KiB, so this inefficiency can be neglected in favor of cleaner
> code.

Depends how long the string you want to read, right ?
in principle runCommand could be re-used elsewhere for any type of command (like "cat very_long_file_with_no_linebreak")

>
> > There is No conversion from const char* to std::string in the current code
> > the call runCommand( "..." ) implicitely calls the std::string directly
> > as for the call string.c_str() it access directly the const char* stored internally in the string
> Why no conversion? You call runCommand("str") and this calls
> std::string("str") potentially doing some initialization there.

yes the initialization of the extra members of std::string on top of the const char* (which is kept unchanged, passed as a pointer).

> And then you
> call a function which needs const char*, in which case although you don't
> convert, but this still is redundant.
redundant with what ?
std::string is a pointer to const char* with a proper destructor and copy constructor. Nothing more. (well, more or less :))

>
> > All in all, that's the whole idea behind using c++ instead of c, and limit c to where you have
> > to (namely when calling gtk, glib or other functions).
> Yeah I do understand this, but you have a POSIX function here - this is just
> like gtk function, and we pass string literal here, for which std::string
> has no advantage at all.

But that's the point: disregarding of the internals of the function, I don't want it to spread.
I do not what to have to ask myself, every time I call runCommand, whether I need to free the string or not (disregarding whether it uses posix or gtk in there).

The idea is not about what's done internally, but what to expect when called by the rest of the world, without knowing what's done internally. With passing std::string, I know I don't have to care about allocation deallocation. That's the same spirit behind my writting of the oxygencairosurface, pattern, context; the timers, etc. In general, the more "self-deallocating" things you use for the arguments in your methods, the more stable your code will be. (my oppinion at least)

In any case, I'm not sure here is the right place to have this discussion.

> yes the initialization of the extra members of std::string on top of the const char* (which is kept unchanged, passed as a pointer).
It's copied in fact. You thus have first copy - a string literal, and second one - created in constructor. That's why my objection. Even though I recognize that command line is negligible in size, this way of handling string literals is just unclean.
And you don't need to worry about deletion since you can use std::string in caller and then pass it like mycmd.c_str() to runCommand().
In general, I do agree about using self-deallocating objects, but this case doesn't really look like the one which really needs this.

Anyway, if you still aren't convinced, then I won't argue anymore and will agree to have it left alone.

97 comments hidden view all 154 comments
Dan Parnham (teadriven) wrote :

Looks like it's not specific to emacs, seeing the same issue with other GTK2 apps in kubuntu 13.04: https://sourceforge.net/p/codelite/bugs/895/

Vertago1 (vertago1) wrote :
Download full text (8.9 KiB)

This affects a lot more than emacs. I have had thunderbird and acroread both lockup repeatedly.

Here is the stack trace for acroread:
#0 0xf77b5425 in __kernel_vsyscall ()
#1 0xf5b5fdcb in poll () from /lib/i386-linux-gnu/libc.so.6
#2 0xf5dbe2db in g_poll () from /lib/i386-linux-gnu/libglib-2.0.so.0
#3 0xf5daf6d0 in ?? () from /lib/i386-linux-gnu/libglib-2.0.so.0
#4 0xf5dafc2b in g_main_loop_run () from /lib/i386-linux-gnu/libglib-2.0.so.0
#5 0xf5df5c21 in g_spawn_sync () from /lib/i386-linux-gnu/libglib-2.0.so.0
#6 0xf5df6094 in g_spawn_command_line_sync () from /lib/i386-linux-gnu/libglib-2.0.so.0
#7 0xf332be4c in Oxygen::QtSettings::kdeConfigPathList() const ()
   from /usr/lib/i386-linux-gnu/gtk-2.0/2.10.0/engines/liboxygen-gtk.so
#8 0xf332e8f3 in Oxygen::QtSettings::initialize(unsigned int) ()
   from /usr/lib/i386-linux-gnu/gtk-2.0/2.10.0/engines/liboxygen-gtk.so
#9 0xf3341b18 in Oxygen::Style::initialize(unsigned int) () from /usr/lib/i386-linux-gnu/gtk-2.0/2.10.0/engines/liboxygen-gtk.so
#10 0xf3341ef3 in Oxygen::Style::fileChanged(_GFileMonitor*, _GFile*, _GFile*, GFileMonitorEvent, void*) ()
   from /usr/lib/i386-linux-gnu/gtk-2.0/2.10.0/engines/liboxygen-gtk.so
#11 0xf4c4e48e in ffi_call_SYSV () from /usr/lib/i386-linux-gnu/libffi.so.6
#12 0xf4c4e1ef in ffi_call () from /usr/lib/i386-linux-gnu/libffi.so.6
#13 0xf5e77a2a in g_cclosure_marshal_generic_va () from /usr/lib/i386-linux-gnu/libgobject-2.0.so.0
#14 0xf5e76ee1 in ?? () from /usr/lib/i386-linux-gnu/libgobject-2.0.so.0
#15 0xf5e9065a in g_signal_emit_valist () from /usr/lib/i386-linux-gnu/libgobject-2.0.so.0
#16 0xf5e91233 in g_signal_emit () from /usr/lib/i386-linux-gnu/libgobject-2.0.so.0
#17 0xf4d39229 in ?? () from /usr/lib/i386-linux-gnu/libgio-2.0.so.0
#18 0xf5dabf10 in ?? () from /lib/i386-linux-gnu/libglib-2.0.so.0
#19 0xf5daf3b3 in g_main_context_dispatch () from /lib/i386-linux-gnu/libglib-2.0.so.0
#20 0xf5daf750 in ?? () from /lib/i386-linux-gnu/libglib-2.0.so.0
#21 0xf5dafc2b in g_main_loop_run () from /lib/i386-linux-gnu/libglib-2.0.so.0
#22 0xf612c710 in gtk_main () from /usr/lib/i386-linux-gnu/libgtk-x11-2.0.so.0
#23 0x0850d0bd in _start ()

Here is the trace for thunderbird:
#0 0x00007f9b459483cd in poll () at ../sysdeps/unix/syscall-template.S:81
#1 0x00007f9b404501dc in g_main_context_poll (n_fds=1, fds=0x7f9af37f6d28, timeout=-1, context=0x7f9af37a7680,
    priority=<optimized out>) at /build/buildd/glib2.0-2.36.0/./glib/gmain.c:3995
#2 g_main_context_iterate (context=0x7f9af37a7680, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>)
    at /build/buildd/glib2.0-2.36.0/./glib/gmain.c:3696
#3 0x00007f9b404506ba in g_main_loop_run (loop=0x7f9afb710370) at /build/buildd/glib2.0-2.36.0/./glib/gmain.c:3895
#4 0x00007f9b40491e41 in g_spawn_sync (working_directory=working_directory@entry=0x0, argv=<optimized out>, envp=envp@entry=0x0,
    flags=flags@entry=G_SPAWN_SEARCH_PATH, child_setup=child_setup@entry=0x0, user_data=user_data@entry=0x0,
    standard_output=standard_output@entry=0x7fff584be268, standard_error=standard_error@entry=0x0,
    exit_status=exit_status@entry=0x0, error=error@entry=0x0) at /build/buildd/glib2.0-2...

Read more...

I've got lockups with Firefox and Thunderbird.

Sam Azer (samazer) wrote :

Enjoying k/ubuntu 13.04 very much. Switched to the development snapshot of emacs for now.

This is just to let you know that putty is also affected probably by this bug. I have exactly same problems described here for emacs.

94 comments hidden view all 154 comments

Are there any plans of a new release with these patches anytime soon? This bug breaks using emacs with oxygen-gtk2 after upgrading libglib to version 2.36 in Debian. That update is already in unstable, so it will probably migrate to testing soon and start hitting Debian testing desktop users.

93 comments hidden view all 154 comments
Ruslan (b7-10110111) wrote :

See also https://bugs.kde.org/show_bug.cgi?id=318891 . We've worked around this bug in oxygen-gtk, commits are in current git.

Changed in emacs:
importance: Unknown → High
status: Unknown → Fix Released
Paul White (paulw2u) on 2013-05-15
summary: - emacs23/24 GUI does not start when run in Kubuntu 13.04 with oxygen-gtk
- theme enabled
+ emacs23/24 and other GTK applications do not start when run in Kubuntu
+ 13.04 with oxygen-gtk theme enabled
Changed in gtk2-engines-oxygen (Debian):
status: Unknown → Fix Released
94 comments hidden view all 154 comments
Sergio Callegari (callegar) wrote :

Seems rather serious to me. Currently there are at least three packages in the ubuntu repos (oxygen-gtk for gtk2 and gtk3 and qtcurve) that - once installed - may make many gtk applications stop working, in such a way that they silently hang.

A troublesome aspect is thatI would like to report that after upgrading to raring, some kde systems come out without the module that enables the configuration of the gtk themes in the kde systems settings (the deb is not installed). This means that working around the issue by inviting kde users to configure gtk not to use the oxygen or the qtcurve theme may be tricky. Here the workaround involves root permissions to force the uninstall of oxygen-gtk, qtcurve or the install of the kde system settings module, or alternatively inviting users to hand edit the gtkrc file.

Rohan Garg (rohangarg) wrote :

Hi everyone, I've uploaded the 1.3.3 package for gtk2-engines-oxygen to raring-proposed : https://launchpad.net/ubuntu/+source/gtk2-engines-oxygen/1.3.3-2ubuntu0.1

Please give your feedback on bug 963736 whether everything works fine now.

Regards
Rohan Garg

Petr Sedlacek (petr-sedlacek) wrote :

I can confirm that with the new package gtk2-engines-oxygen_1.3.3-2ubuntu0.1_amd64.deb EasyTag is starting correctly (I'm not using Emacs but EasyTag had the exact same problem)

Vasilis Vasaitis (vvas) wrote :

The update of gtk2-engines-oxygen has no effect on emacs24, as it's compiled against GTK3. I've just checked, and indeed installing it doesn't make the problem go away, at least for me.

Rohan Garg (rohangarg) on 2013-06-05
description: updated
no longer affects: gtk2-engines-oxygen (Ubuntu Raring)
no longer affects: gtk2-engines-oxygen (Ubuntu)
Changed in oxygen-gtk3 (Ubuntu):
status: Confirmed → In Progress
Rohan Garg (rohangarg) wrote :

Fix for oxyge-gtk3 uploaded to raring, waiting in approval queue

Hello Paul, or anyone else affected,

Accepted into raring-proposed. The package will build now and be available in a few hours in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Changed in emacs23 (Ubuntu Raring):
status: New → Fix Committed
Changed in emacs24 (Ubuntu Raring):
status: New → Fix Committed
Changed in oxygen-gtk3 (Ubuntu Raring):
status: New → Fix Committed
tags: added: verification-needed
Paul White (paulw2u) wrote :

Proposed already enabled and can confirm emacs23 now starts every time so oxygen-gtk2 fix works here.
Will test emacs24 when oxygen-gtk3 fix available.

Rohan/Scott, thanks for fixing.

Rohan Garg (rohangarg) wrote :

@Paul Fix should now be available via -proposed, once you've tested, please set the tag as verification-done.

Paul White (paulw2u) wrote :

Super! emacs24 now started 6 times in a row successfully. Thanks Rohan. Now setting tag.....

tags: added: verification-done
removed: verification-needed
Rohan Garg (rohangarg) wrote :

Thanks Paul, Fix will migrate from -proposed to -release 7 days from now.

Changed in oxygen-gtk3 (Ubuntu):
importance: Undecided → Critical
importance: Critical → Undecided
Vasilis Vasaitis (vvas) wrote :

Yeap, after upgrading gtk3-engines-oxygen, emacs24 starts ok here too.

The verification of this Stable Release Update has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regresssions.

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package oxygen-gtk3 - 1.1.4-0ubuntu0.1

---------------
oxygen-gtk3 (1.1.4-0ubuntu0.1) raring; urgency=low

  [ Rohan Garg ]
  * New upstream release (LP: #1142213)
    - Fixes issues where gtk3 applications like emacs24 would not start

  [ Dmitry Smirnov ]
  * Corrected "Expat" license name in debian/copyright
 -- Rohan Garg <email address hidden> Wed, 05 Jun 2013 13:14:25 +0100

Changed in oxygen-gtk3 (Ubuntu Raring):
status: Fix Committed → Fix Released

Comming back to this bug, because I am not happy with the use of popen (which is less portable than g_spawn):
testing with g_spawn again and glib-2.36.2, I do not get the issue anymore.
could someone double check ?

(would require some oxygen-gtk checked-out at, e.g. a515ab451f54cbc930d0a09d250669255dd8a741^ and build from source, for gtk2 applications.)

... digging:
https://bugzilla.gnome.org/show_bug.cgi?id=698081

seems, it was indeed a glib bug, that got fixed in glib.
I would be inclined to revert this change to popen, and close (again) this bug as upstream.
Ruslan ? oppinion ?

Changed in emacs:
status: Fix Released → Confirmed

> Ruslan ? oppinion ?
Well, I'd in fact rather use "#define popen _popen" etc. on Windows (if this is what you mean by portability), not return to glib-specific code.
popen() is much less likely to fail, and this is why I'd prefer using it instead.

@Ruslan
problem with popen:
- it is defined on windows (with mingw at least) and works, but opens a terminal to execute a command. (not so nice). And I'm not sure _popen would fix this, would it ?

- on unix, it does not allow to easily redirect stderr, so you get an error message (for every application) when kde4-config is not installed. So that I had to add a 2> /dev/null (committed), to hide the (armless) error message, in current master, because users were already complaining.
But this, in turn, is not portable to windows.

All this is nicely handled in g_spawn, when it works ...

popen being more likely to work on windows depends on MinGW (not even sure if it is implemented with VC ...). While g_spawn depends on glib. Which one is more error prone I do not know (I would assume glib, but ...)

So bottomline: if we want to stick to popen (to be more glib-error safe), we'd likely need more code (and more #ifdef) than what we have now ...

PS: maybe we can revert the change in popen, in master only ...
(which will become our next feature release) ?

> - it is defined on windows (with mingw at least) and works, but opens a terminal to execute a command. (not so nice). And I'm not sure _popen would fix this, would it ?
Most likely it won't. But we can make something like this:
#ifdef _WIN32
    ShowWindow(GetConsoleWindow(),SW_HIDE);
#endif
before running popen(). (Ugly, but should do the trick.)
> - on unix, it does not allow to easily redirect stderr, so you get an error message (for every application) when kde4-config is not installed. So that I had to add a 2> /dev/null (committed), to hide the (armless) error message, in current master, because users were already complaining.
This is more serious. Not sure how to fix this well enough...
> popen being more likely to work on windows depends on MinGW (not even sure if it is implemented with VC ...).
_popen() is listed in MSDN, so this one should be available with VC.

> So bottomline: if we want to stick to popen (to be more glib-error safe), we'd likely need more code (and more #ifdef) than what we have now ...
Yeah, hard to decide. Seems you're right and we should go back to glib. (But we should make sure this doesn't break any distro again if they still use unfixed glib version).

@Ruslan
So I'd suggest:
- keep current branches as they are (with popen).
- revert the change (sort of: I would like to keep the RunCommand method :)) for master (and gtk3 branch).
- if we want to be extra sure, add a minimal requirement on the glib version in our (master) CMakefiles.

What do you think ?

> if we want to be extra sure, add a minimal requirement on the glib version in our (master) CMakefiles.
No, that's bad. This way you'll disable any older distros from being able to use latest oxygen-gtk release.

I'd suggest that we leave both variants - via popen() and g_spawn...() - and use popen() only for that glib version(s) which fails (and warn user in cmake output that current glib version is bad).

yeah well. More ifdefs ... not sure I want that. Especially if it is to bypass a bug that is present in only one _minor_ release of glib.

The only advantage of keeping popen is if other (future) versions of glib break, which the suggestion you propose would not prevent either ...

So in the end, gspawn it should be, and gspawn only, I'd say, assuming that upstream is reliable. (especially a low level library such as glib)

And too bad for the systems running with broken glib (in fact, I expect that if it also breaks pidgin, distros would be quite quick at patching glib)

Git commit ccf7f9c46e521f3966751cbf822beb242579abe3 by Hugo Pereira Da Costa.
Committed on 19/06/2013 at 12:17.
Pushed by hpereiradacosta into branch 'gtk3'.

Re-added use of g_spawn_command_line_sync in place of popen, to execute an external comment.
This effectively reverts commit 51b662b0cd86fd7a960cc2f0c436441d64b2dd44
Rational:
- the failure of g_spawn_command_line_sync was a glib bug 3.6.0, that got fixed since then (3.6.2)
- the use of popen generates unnecessary console when compiled for windows
- the use of popen makes it difficult to redirect stderr, which results in error messages being printed
on screen when the executed command failed (for instance because the relevant application is not
installed.

M +3 -26 src/oxygenqtsettings.cpp

http://commits.kde.org/oxygen-gtk/ccf7f9c46e521f3966751cbf822beb242579abe3

Git commit 2068101234271725def6fe91de4a26543b260cba by Hugo Pereira Da Costa.
Committed on 19/06/2013 at 12:17.
Pushed by hpereiradacosta into branch 'master'.

Re-added use of g_spawn_command_line_sync in place of popen, to execute an external comment.
This effectively reverts commit 51b662b0cd86fd7a960cc2f0c436441d64b2dd44
Rational:
- the failure of g_spawn_command_line_sync was a glib bug 3.6.0, that got fixed since then (3.6.2)
- the use of popen generates unnecessary console when compiled for windows
- the use of popen makes it difficult to redirect stderr, which results in error messages being printed
on screen when the executed command failed (for instance because the relevant application is not
installed.

M +3 -26 src/oxygenqtsettings.cpp

http://commits.kde.org/oxygen-gtk/2068101234271725def6fe91de4a26543b260cba

the 1.3.3 gtk engine in my system will cause stcok from the konsole to the whole kde GUI when i use the ctrl + z to try to move the hime to the background.
so i still decide to use the fix version.

the 1.3.3 gtk engine in my system will cause stock from the konsole to the whole kde GUI when i use the ctrl + z to try to move the hime to the background.
so i still decide to use the fix version.

because the konsole got stock, i can not be able get the backtrace.
even use the another konsole to open the new konsole.

Paul Abrahams (abrahams) wrote :

This problem also shows up with easytag (see Bug #1160729).

aanno (thomas-pasch) wrote :

I believe this is also a problem with Ubuntu 13.10/saucy, eclipse/java and oxgen-gtk2. See https://bugs.launchpad.net/ubuntu/+source/glib2.0/+bug/1245468 for details.

is this bug still valid ?
It requires a recent enough version of glib, for g_spawn to be working properly.

now is fixed, i did not know why is reopened

Changed in emacs:
status: Confirmed → Fix Released
Rohan Garg (rohangarg) on 2014-02-12
Changed in oxygen-gtk3 (Ubuntu):
status: In Progress → Fix Released
Changed in emacs23 (Ubuntu):
status: Confirmed → Fix Released
Changed in emacs23 (Ubuntu Raring):
status: Fix Committed → Fix Released
Paul White (paulw2u) wrote :

Just cleaning up, emacs24 working ok in both Kubuntu 13.10 and 14.04. Marking as fix released.

Changed in emacs24 (Ubuntu):
status: Confirmed → Fix Released
Displaying first 40 and last 40 comments. View all 154 comments or add a comment.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.