Red Hat Bugzilla – Bug 192420
Review Request: Bonfire - CD/DVD burning app for gnome
Last modified: 2007-11-30 17:11:33 EST
Spec URL: http://perso.wanadoo.fr/bonfire/bonfire.spec SRPM URL: http://perso.wanadoo.fr/bonfire/bonfire-0.3.1-1.src.rpm Description: bonfire is a CD/DVD application for the GNOME desktop designed to be easy and simple to use.
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.