I used brasero successfully many times, but in the last days I had to burn a couple of cds and I ended up throwing 5 or 6 into the basket. I always compiled brasero with cdrkit and without libburn support, but now it seems like it's impossible to burn anything: no-plugins.png shows that the system sees the blank cd but is unable to burn. Messages are in italian, but they basically say "impossible to burn with the current set of plugins". I added libburn support by changing the USE flags on brasero, and the application says it can burn the cd; but it never finishes, it's always stopped by a SCSI error, which I report on error-while-burning.png and brasero-session.log. I thought it could be some kernel issue, and I downgraded from 2.6.28-r1 to 2.6.27-r8: same as before. The really weird issue is that libburn exits with the same error even when *simulating*, as described in brasero-session_simulated.log. I tried brasero 2.25.90 with libburn 0.6.0_p01, now I'm back to brasero 0.8.4-r1 and libburn 0.5.8. This problem occurs trying to burn audio cds, I still haven't tested the other burning modes. Reproducible: Always Steps to Reproduce:
Created attachment 182010 [details] Impossibile to burn with the current set of plugins
Created attachment 182011 [details] Error while burning
Created attachment 182013 [details] Error during a real burning session
Created attachment 182014 [details] Error during a simulated burning session
This is weird. I sent pygi from libburn a note.
Report this bug upstream, it might be some libburnia versions problem.
I'll report the bug about libburn upstream in a few days, but maybe I found something to explain why brasero doesn't recognize cdrkit. This is what comes out when compiling brasero *with* cdrkit and *without* libburn: brasero configuration summary: ---------------------------------- Version: 0.8.4 Update caches: no Build with GNOME2 : yes Build Nautilus extension : yes Build inotify: yes Build search pane : no Build playlist pane : yes Build Preview pane : yes Build cdrtools plugins : no Build cdrkit plugins : no Build libburnia plugins : no This *has to be* wrong. In fact lanching a simple "./configure && make" inside the sources directory I see this: brasero configuration summary: ---------------------------------- Version: 0.8.4 Update caches: yes Build with GNOME2 : yes Build Nautilus extension : yes Build inotify: yes Build search pane : no Build playlist pane : yes Build Preview pane : yes Build cdrtools plugins : yes Build cdrkit plugins : yes Build libburnia plugins : no Notice the difference in the first the cdrkit plugin is disabled even if the USE flag is enabled. Inside brasero-0.8.4-r1.ebuild I deleted the line 52, "$(use_enable cdrkit)" and now the plugin si correctly enabled. My patch is just an ugly workaround, but I think that someone should take care of this.
sounds like someone broke the brasero ebuild..
Created attachment 191511 [details, diff] app-cdr/brasero/files/brasero-2.26.1-configure-enable.patch Patch for configure.in
Created attachment 191512 [details] app-cdr/brasero/brasero-2.26.1.ebuild Updated ebuild from gnome overlay that uses above patch
It appears that when user specifies any option to configure script that outcome is always disabling this option.
Wow, I successfully burnt the first audio cd in a long time! Great work, Michal! I'm using only cdrkit backend. Minor issue (maybe unrelated), the normalization plugin seems to stall; I had to disable it to be able to burn the cd.
(In reply to comment #11) > It appears that when user specifies any option to configure script that outcome > is always disabling this option. > Michal: Has this patch been sent upstream? +*brasero-2.26.1-r2 (17 May 2009) + + 17 May 2009; Peter Alfredsen <loki_val@gentoo.org> -brasero-0.7.1.ebuild, + -brasero-2.26.0.ebuild, -brasero-2.26.1-r1.ebuild, + +brasero-2.26.1-r2.ebuild, +files/brasero-2.26.1-configure.patch: + Beat configure.in into submission with patch from Michal Kurgan + <moloh@moloh.net> of bug 258981. + Tomaso: If there are any issues left after this has been resolved, please file a new bug.
(In reply to comment #13) > (In reply to comment #11) > > It appears that when user specifies any option to configure script that outcome > > is always disabling this option. > > > > Michal: Has this patch been sent upstream? No, we have upstream here in this bug. Submit it anyway Luis?
Yes please submit upstream, I'll review it there and try to fix your problem.