Downloaded source and srpm source don't match. These need to. md5sums:
db94c7ae5ac5c27cf7d66fafc3654f4f  bonfire-0.3.1.tar.bz2 (downloaded)
9e2cf4235be0a149f2dab2734e1b2c2a  bonfire-0.3.1.tar.bz2 (srpm)

Duplicate BuildRequires, courtesy the magic fedora-qa script:
glib2-devel (by gtk2-devel), libxml2-devel (by GConf2-devel), gtk2-devel (by
libgnomeui-devel), gnome-vfs2-devel (by libgnomeui-devel), GConf2-devel (by
libgnomeui-devel), libgnome-devel (by libgnomeui-devel), dbus-devel (by hal-devel)

rpmlint:
E: bonfire description-line-too-long Bonfire is a CD/DVD burning application for
the gnome desktop designed to be simple and easy to use.
Your description lines must not exceed 79 characters. If a line is exceeding
this number, cut it to fit in two lines.

W: bonfire incoherent-version-in-changelog 0.3.0-1 0.3.1-1.fc6
Your last entry in %changelog contains a version that is not coherent with
the current version of your package.

If you have made any changes to your Source tarball or SPEC file then you must
update your chnagelog in SPEC file

I updated everything for 0.4.0 and tried to remember your remarks for this new
one. Here is my second attempt at creating a package. I tried to remember the
previous remarks and used rpmlint. Except I didn't find the magic fedora-qa script.

Spec URL: http://perso.orange.fr/bonfire/bonfire.spec
SRPM URL: http://perso.wanadoo.fr/bonfire/bonfire-0.4.0-1.src.rpm

Fantastic package. Kind of "must add" to FC6 Extras.
I'm using 0.4.1 and it works just perfectly. I prefer it over GnomeBaker and
graveman already. It's not as powerful as k3b, but it's going in it's own
direction which I like. Thumbs up.

Thanks, that reminded me I needed to update for 0.4.1 et voilà...

Spec URL: http://perso.orange.fr/bonfire/bonfire.spec
SRPM URL: http://perso.wanadoo.fr/bonfire/bonfire-0.4.1-1.src.rpm

I have a question. Currently this package depends on totem (and, of course, some
other things). Can this dependancy on totem be avoided somehow, so people who
use totem-xine (instead of totem, as they conflict each other) can also use bonfire?

It can. Now, bonfire would become unable to use and parse any playlist which is
not a big deal if you don't often make audio CDs.

Vedran: As I understand it, when the binary RPM is built, it find the
dependencies on the shared libraries that this package would link to. Hence, it
would depend on things like libtotem-plparser.so.1 (or whatever the exact SO
name is). Thus, simply replacing totem with totem-xine should be fine on the
user's end, as they both (to my knowledge) provide the same shared libraries.
The reason it actually depends on 'totem' when you attempt to install it after
building it is that totem is the only RPM available in the default repositories
which contains these libraries. Hope that helps.

Build failed on development x86_64:

recorder-selection.c:870: error: 'NautilusBurnDrive' has no member named
'max_speed_write'
recorder-selection.c: In function 'bonfire_recorder_selection_button_cb':
recorder-selection.c:1100: error: 'NautilusBurnDrive' has no member named
'type'recorder-selection.c: In function 'bonfire_recorder_selection_get_drive':
recorder-selection.c:1138: error: 'NautilusBurnDrive' has no member named
'type'recorder-selection.c:1144: error: 'NautilusBurnDrive' has no member named
'display_name'
recorder-selection.c: In function 'bonfire_recorder_selection_select_default_drive':
recorder-selection.c:1180: warning: implicit declaration of function
'nautilus_burn_drive_get_list'
recorder-selection.c:1180: warning: assignment makes pointer from integer
without a cast
recorder-selection.c:1184: error: 'NautilusBurnDrive' has no member named
'type'make[2]: *** [recorder-selection.o] Error 1

And there's more has no member errors with NautilusBurnDrive.


The magic fedora-qa script is here, along with some other tools to make an
Extras packager's life easier: http://fedoraproject.org/wiki/Extras/UsefulScripts

John: that's because you must be using nautilus-cd-burner 2.15 which breaks
backward compatibility. It should work fine with ncb-2.14 which is supported by
fedora stable. Which brings me to the question:
What should be the version of nautilus-cd-burner that bonfire should support
2.14 or 2.15?
thanks for the script.

(In reply to comment #10)
> John: that's because you must be using nautilus-cd-burner 2.15 which breaks
> backward compatibility. It should work fine with ncb-2.14 which is supported by
> fedora stable. Which brings me to the question:
> What should be the version of nautilus-cd-burner that bonfire should support
> 2.14 or 2.15?

I'd like to build against development, because that's where Fedora's headed. So
2.15. Backward compatability would be nice too, however.

I filed a bug at SourceForge.
http://sourceforge.net/tracker/index.php?func=detail&aid=1527046&group_id=156415&atid=799692

(In reply to comment #8)
> Vedran: As I understand it, when the binary RPM is built, it find the
> dependencies on the shared libraries that this package would link to. Hence, it
> would depend on things like libtotem-plparser.so.1 (or whatever the exact SO
> name is). Thus, simply replacing totem with totem-xine should be fine on the
> user's end, as they both (to my knowledge) provide the same shared libraries.
> The reason it actually depends on 'totem' when you attempt to install it after
> building it is that totem is the only RPM available in the default repositories
> which contains these libraries. Hope that helps.

I actually noticed that some time later, but simple "yum install totem-xine"
after bonfire has been installed complains about unsatisfied dependancy, and
"yum remove totem" triest to remove bonfire as well. But that's not an issue on
bonfire side, since it can be made to work the way you mentioned. Thanks for
clarification.

We should postpone bonfire integration for two reasons:
- due to trademarks on the name, I'll have to change the name
- if you want ncb-2.15, I'll have to port bonfire which was planned for 0.4.91

I think backward compatibility will be hard but I'll make my best.

As for the new name I'm not sure. I'm still thinking about it but should I open
a new bug for reviewing and close this one?

It may be best to do the name change and the switch to later ncb at the same
time.  New name, new major release, new ncb requirements, might as well do it
all at once. 

Opening a new bug would be a good idea, less confusion.

Agreed, closing.  Please (re)submit renamed submission.