Red Hat Bugzilla – Full Text Bug Listing
|Summary:||Review Request: Bonfire - CD/DVD burning app for gnome|
|Product:||[Fedora] Fedora||Reporter:||Rouquier Philippe <rouquier.p>|
|Component:||Package Review||Assignee:||John Mahowald <jpmahowald>|
|Status:||CLOSED NOTABUG||QA Contact:||Fedora Package Reviews List <fedora-package-review>|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2006-09-18 09:41:02 EDT||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Bug Depends On:|
Description Rouquier Philippe 2006-05-19 12:41:49 EDT
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.
Comment 1 John Mahowald 2006-05-29 17:21:00 EDT
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.
Comment 2 Parag AN(पराग) 2006-06-01 00:21:01 EDT
If you have made any changes to your Source tarball or SPEC file then you must update your chnagelog in SPEC file
Comment 3 Rouquier Philippe 2006-07-12 13:02:23 EDT
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
Comment 4 Vedran Miletić 2006-07-17 09:20:28 EDT
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.
Comment 5 Rouquier Philippe 2006-07-17 09:47:50 EDT
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
Comment 6 Vedran Miletić 2006-07-20 11:57:57 EDT
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?
Comment 7 Rouquier Philippe 2006-07-20 12:19:32 EDT
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.
Comment 8 Peter Gordon 2006-07-20 13:57:04 EDT
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.
Comment 9 John Mahowald 2006-07-20 20:21:34 EDT
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: *** [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
Comment 10 Rouquier Philippe 2006-07-21 03:13:33 EDT
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.
Comment 11 John Mahowald 2006-07-22 15:23:01 EDT
(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
Comment 12 Vedran Miletić 2006-07-23 07:18:12 EDT
(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.
Comment 13 Rouquier Philippe 2006-07-26 04:33:12 EDT
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?
Comment 14 John Mahowald 2006-07-26 23:50:52 EDT
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.
Comment 15 Rex Dieter 2006-09-18 09:41:02 EDT
Agreed, closing. Please (re)submit renamed submission.