I'm running KDE4 and using dolphin to display a directory containing ISO images. If I right-click on an ISO file, and choose Open With > Brasero, the usual burn window opens and burns the disk correctly. When I get the Success pop-up, I click Close, and brasero windows disappear. Except brasero itself does not end. If you try to do the same thing again, no window will open because brasero refuses to start a second instance. "ps" shows the old instance of brasero still executing with the first ISO file name in the command line. This does *not* happen if I start brasero from the Applications Menu and burn an ISO. The problem appears to be limited to invoking brasero via the "Open With" option.
Try this: sed -i 's,Exec=brasero %U,Exec=brasero -i %U,' /usr/share/applications/brasero.desktop then as user 'kbuildsycoca4', then try again.
Keywords: (none) => NEEDINFO
Worked like magic, thanks. Does this require something similar to be done someplace in real code, or was this just a blip on my system (in which case I'll close this) ?
That's a hacky workaround, it has a bad side effect, as the same .desktop file is used to launch brasero from the menu, and -i switch doesn't make it show the default brasero window, but the window where it asks you to select an image to burn. It was just to test the issue. I suggest you file a bug report upstream, so this gets fixed properly.
Keywords: NEEDINFO => Triaged
OK. Do you know what's happening, and whether the problem is with brasero or KDE ?
It's a problem with brasero, I think. When launched with -i: -i, --image=PATH TO IMAGE URI of an image file to burn (autodetected) and when you close it, it exists, but the .desktop file has by default: Exec=brasero %U when doesn't leave a brasero process running after closing the window.
URL: (none) => https://bugzilla.gnome.org/show_bug.cgi?id=655513
Assignee: bugsquad => eandry
Keywords: (none) => UPSTREAMCC: (none) => marja11
Ping. Upstream isn't moving on this, so I think we should patch Ahmad's fix before release.
CC: (none) => fundawang, jani.valimaa, olavAssignee: eandry => bugsquadSource RPM: brasero-3.0.0-4.mga2.x86_64.rpm => brasero
CC: jani.valimaa => (none)
Hi, This bug was filed against cauldron, but we do not have cauldron at the moment. Please report whether this bug is still valid for Mageia 2. Thanks :) Cheers, marja
@ Frank I admit it isn't likely that this bug got solved, but since bugs do sometimes get solved contrary to my expectation: Is this bug valid for Mageia 2 or current cauldron, too? If so, please remove NEEDINFO from the Keywords and put MGA2TOO on the whiteboard. Thanks :)
Well, the hack suggested by Ahmad is still in brasero.desktop, and: [root@ftgme2 applications]# rpm -V brasero S.5....T. /usr/share/applications/brasero.desktop so it looks like the problem was still there the last time brasero was installed, and I had to reapply the hack. Removing the hack, opening brasero for an ISO, and clicking CANCEL leaves the brasero process in `ps`, so I guess it hasn't been fixed in KDE either.
Keywords: NEEDINFO => (none)Whiteboard: (none) => MGA2TOO
Ping ? As it appears upstream has no interest in fixing this, can we please add the hack as a patch until they do ?
(In reply to comment #10) > Ping ? > > As it appears upstream has no interest in fixing this, can we please add the > hack as a patch until they do ? There is no maintainer for brasero. I'll cc some more committers
CC: (none) => dmorganec, jani.valimaa, pterjan
ping ?
nothing changed in the upstream bug...
Keywords: (none) => NO_PATCH
The "ping" is about adding a patch as detailed above to our own package. I have little hope that upstream is doing anything with brasero ;-P
ah oups, unmaintained package in both side it seems anyway
Keywords: NO_PATCH => PATCH
Can we PLEASE get this fixed for MGA3 ? All it requires is a patch to insert the three characters " -i" in a desktop file by someone who knows how to submit changes. The annoying part of this is that doing this manually gets reverted every time the desktop file is replaced.
CC: (none) => balcaen.john, nicolas.lecureuil
so what is the fix ? to change : Exec=brasero %U by Exec=brasero -i %U ?
That's it exactly. Presumably the kbuildsycoca4 comes along for the ride after the desktop file is installed. Thanks for picking this up.
(In reply to Frank Griffin from comment #16) > Can we PLEASE get this fixed for MGA3 ? All it requires is a patch to > insert the three characters " -i" in a desktop file by someone who knows how > to submit changes. I don't think we can do this : it will "break" brasero startup for all users. With -i by default, launching from menu, brasero will start with the "Image Burning Setup" dialog box instead of its main application window. I'm quite sure that gnome's users won't appreciate such change :-) > > The annoying part of this is that doing this manually gets reverted every > time the desktop file is replaced. To avoid this, you should copy /usr/share/applications/brasero.desktop to another filename like brasero-iso.desktop, adapt Name and GenericName to this specific use, and add the -i in its Exec. regards, Luc
Keywords: PATCH => (none)CC: (none) => lmenut
I see your point, but the fact is that executing brasero from the "Open With" menu of an ISO image is supposed to do just that - launch the image burning dialog. And, in fact, with no modification to the desktop file, that's what happens, presumably because brasero sees an *.iso file on its command line. Possibly, this is actually a brasero bug then, and when it passes through to the image burning dialog based on filename, it leaves the parent application dialog hanging around. But you're correct. KDE appears to use the desktop file for both "Open With" and direct invocation from the Application Launcher, and with the workaround applied, invocation from the Application Launcher does indeed bring up the image burning dialog rather than the entry window. Is there a way in KDE to provide a separate Exec spec for each of these activities ? Failing that, I guess your solution is next best.
As commented on the upstream bug[1] I've just pushed a patch[2] which I believe resolves this issue. 1. https://bugzilla.gnome.org/show_bug.cgi?id=655513 2. https://git.gnome.org/browse/brasero/commit/?id=f122ee0620380b7c21edce722cfe347f10c8c827
CC: (none) => joshuagl
Marking FIXED, as upstream bug is so marked.
Status: NEW => RESOLVEDResolution: (none) => FIXED
fixed upstream yes but is the fix on our package ? it it confirmed as fixed for us ?
Status: RESOLVED => REOPENEDResolution: FIXED => (none)
$ ps -A|grep brasero 6734 ? 00:00:00 brasero It is not fixed in our package.
CC: (none) => davidwhodgins
Will apply the fix.
CC: (none) => remiAssignee: bugsquad => remi
The fix is already applied in version 3.11.3 in cauldron, and also in version 3.10.0 in Mageia 4. Frank, can you confirm the fix on Mageia 4/cauldron? Then I can do an update for Mageia 3.
Well brasero segfaults on Cauldron actually... But that's a separate gtk issue.
Yes, it's been doing that for several weeks, along with some other apps.
The brasero segfault is finally history, and I confirm that this is fixed on cauldron.
Status: REOPENED => RESOLVEDResolution: (none) => FIXED