http://bugzilla.rpmfusion.org/show_bug.cgi?id=289 Erik van Pienbroek <erik-rpmfusion(a)vanpienbroek.nl&gt; changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |3 -- Configure bugmail: http://bugzilla.rpmfusion.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. You are the assignee for the bug.

http://bugzilla.rpmfusion.org/show_bug.cgi?id=289 --- Comment #3 from Erik van Pienbroek <erik-rpmfusion(a)vanpienbroek.nl&gt; 2009-01-01 20:35:54 --- (In reply to comment #2) I think this is a small misunderstanding. The point I'm trying to make here is that this package requires win32 codecs in order to be functional, so these win32 codecs should also be packaged for RPMFusion (in a seperate package). I'm not saying that this a task for the submitter. This is just meant as a general statement for the people reading along on the mailing list so that anybody who is interested in packaging win32 codecs can do so. The .spec file lacks a '%dir %{_libdir}/codecs/' in the files list, so this created directory is ignored by rpm. -- Configure bugmail: http://bugzilla.rpmfusion.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. You are the assignee for the bug.

http://bugzilla.rpmfusion.org/show_bug.cgi?id=289 --- Comment #5 from Erik van Pienbroek <erik-rpmfusion(a)vanpienbroek.nl&gt; 2009-01-01 23:36:06 --- (In reply to comment #4) So you're saying the win32 codecs which are published at http://www.mplayerhq.hu/design7/dload.html can't be used in RPMFusion due to legal issues? What is it that makes it illegal for RPMFusion? -- Configure bugmail: http://bugzilla.rpmfusion.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. You are the assignee for the bug.

http://bugzilla.rpmfusion.org/show_bug.cgi?id=289 --- Comment #7 from Erik van Pienbroek <erik-rpmfusion(a)vanpienbroek.nl&gt; 2009-01-04 15:05:31 --- Here's the review: Please add an extra comment to the description mentioning this plugin requires external win32 codecs which can't be redistributed in RPMFusion due to legal reasons and that these codecs need to be saved in the directory /usr/lib/codecs --- While testing, I've found out you need to install the win32 codecs BEFORE installing this plugin. If you don't, the win32 codecs won't be detected by gstreamer: $ gst-inspect pitfdll Plugin Details: Name: pitfdll Description: DLL-loader elements Filename: /usr/lib/gstreamer-0.10/libpitfdll.so Version: 0.9.1.1 License: GPL Source module: pitfdll Binary package: PitfDLL Origin URL: http://ronald.bitfreak.net/pitfdll/ 0 features: If this plugin was installed while the win32 codecs weren't installed yet, you can force a gstreamer recheck by removing the directory ~/.gstreamer-0.10 : $ rm -rf ~/.gstreamer-0.10 $ gst-inspect-0.10 pitfdll Plugin Details: Name: pitfdll Description: DLL-loader elements Filename: /usr/lib/gstreamer-0.10/libpitfdll.so Version: 0.9.1.1 License: GPL Source module: pitfdll Binary package: PitfDLL Origin URL: http://ronald.bitfreak.net/pitfdll/ qtadec_bin: quicktime binary audio decoder dmodec_wmspdmodv1: DMO wmspdmod decoder version 1 dmodec_wmadmodv3: DMO wmadmod decoder version 3 dmodec_wmadmodv2: DMO wmadmod decoder version 2 dmodec_wmadmodv1: DMO wmadmod decoder version 1 dmodec_wmvdmodv3: DMO wmvdmod decoder version 3 dmodec_wmvdmodv2: DMO wmvdmod decoder version 2 dmodec_wmvdmodv1: DMO wmvdmod decoder version 1 dmodec_wmv9dmodv3: DMO wmv9dmod decoder version 3 dshowdec_ir41_32v4: DS ir41_32 decoder version 4 dshowdec_ir50_32v5: DS ir50_32 decoder version 5 11 features: +-- 11 elements Perhaps it is a good idea to add this information to the description to avoid future (false) bug reports. --- During the %install phase, the directory /usr/lib/codecs is generated, but it isn't part of the %files list. I don't know if this directory should really be owned by this package as it is also used by MPlayer and Xine. Can somebody on the mailing list clarify whether two or more packages can own a directory? --- This package only works on the i386 architecture (it doesn't even compile on x86_64). Please add an 'ExclusiveArch: i386' to the .spec file --- rpmlint has indicated that the plugin has an executable stack. This causes issues with SELinux. To fix this, add the line ... export LDFLAGS="-Wl,-znoexecstack" ... to the .spec file, right above the %configure line. I haven't tested if this causes any breakage as I don't have any files at hand which can only be decoded by the win32 codecs. -- Configure bugmail: http://bugzilla.rpmfusion.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. You are the assignee for the bug.

http://bugzilla.rpmfusion.org/show_bug.cgi?id=289 --- Comment #9 from Andrea Musuruane <musuruan(a)gmail.com&gt; 2009-01-05 14:04:02 --- (In reply to comment #8) Please delete end user information from description and put them in a file called README.Fedora or similar that must be included among the doc files. http://fedoraproject.org/wiki/Packaging/Guidelines#Summary_and_description -- Configure bugmail: http://bugzilla.rpmfusion.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. You are the assignee for the bug.

http://bugzilla.rpmfusion.org/show_bug.cgi?id=289 --- Comment #11 from Erik van Pienbroek <erik-rpmfusion(a)vanpienbroek.nl&gt; 2009-01-09 17:29:32 --- (In reply to comment #9) This is kind of a 'chicken and egg' situation. The w32codecs need to be installed before this plugin is installed. If this isn't done, the user is forced to perform some manual action (removing the ~/.gstreamer-0.10 directory) before this plugin becomes functional. The README.Fedora file is only readable after this plugin is installed. I realize this is a diverge from the Fedora package guidelines, but I think we don't really have another option... The only other solution I can think about is patching this plugin so that it somehow triggers a gstreamer plugin cache regeneration when new/changed files are detected in /usr/lib/codecs, but I don't know if that is actually possible (I don't have any experience with the GStreamer API yet..) -- Configure bugmail: http://bugzilla.rpmfusion.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. You are the assignee for the bug.

http://bugzilla.rpmfusion.org/show_bug.cgi?id=289 --- Comment #13 from Erik van Pienbroek <erik-rpmfusion(a)vanpienbroek.nl&gt; 2009-01-09 17:53:55 --- That package isn't allowed in RPMFusion (according to https://bugzilla.rpmfusion.org/show_bug.cgi?id=289#c4) -- Configure bugmail: http://bugzilla.rpmfusion.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. You are the assignee for the bug.

http://bugzilla.rpmfusion.org/show_bug.cgi?id=289 Andreas Thienemann <andreas(a)bawue.net&gt; changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |andreas(a)bawue.net --- Comment #15 from Andreas Thienemann <andreas(a)bawue.net&gt; 2009-01-09 18:19:06 --- (In reply to comment #14) Having a Requires: dependency on the w32 codecs makes this package not installable on most systems. This is surely not what is intended. I'm perfectly happy with having this gstreamer plugin installable from rpmfusion with the user manually needing to download the w32codecs. That way we're shipping the free bits and the user has to see for himself where to get the w32codecs. We could probably tie this in with the game-downloader (forgot the correct name) to get the needed files in the %post script but this is not needed IMHO. -- Configure bugmail: http://bugzilla.rpmfusion.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. You are the assignee for the bug.

http://bugzilla.rpmfusion.org/show_bug.cgi?id=289 --- Comment #17 from Erik van Pienbroek <erik-rpmfusion(a)vanpienbroek.nl&gt; 2009-01-09 20:49:19 --- I just looked into autodownloader. Unfortunately this program is a non-root program, so it can't write files to /usr/lib/codecs. If we patch gstreamer-pitfdll so it also searches in the user's homedir for the w32codecs and integrate autodownloader in it, users will get to see the autodownloader dialog at the first time any GStreamer application (Totem e.g.) is started. This should be do-able, however it introduces some caveats: - If the user presses the 'cancel' button when autodownloader is run, the user needs to remove the ~/.gstreamer-0.10 directory before the gstreamer plugin cache can be updated - Autodownloader is a GUI program. If some non-graphical gstreamer application is started (when no graphical environment is available) things will mess up - The autodownloader dialog will even get shown when the user tries to play an 'open format' media file (like .ogg files) using a gstreamer-based application - It is possible that the autodownloader dialog will get shown directly after the user login (when a gstreamer based application gets started during the login) On second guess, I don't think autodownloader is a (user-friendly) solution to the problem were having here. Perhaps we can ask the upstream gstreamer devs whether it is possible to add some trick that will allow plugins to request a (forced) plugin cache regeneration? That way, gstreamer-pitfdll can automatically request a plugin cache regeneration whenever new/changed files are found in /usr/lib/codecs -- Configure bugmail: http://bugzilla.rpmfusion.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. You are the assignee for the bug.

http://bugzilla.rpmfusion.org/show_bug.cgi?id=289 --- Comment #19 from Andreas Thienemann <andreas(a)bawue.net&gt; 2009-01-09 21:07:22 --- (In reply to comment #18) No, it isn't. The w32codecs are delivered as a tar.gz. Without building your own rpm, this dependency cannot be resolved. We're here to make software installation easier to our users not to ask them to jump through hoops. After all, httpd does need some html files to really be useful. Nevertheless, we allow people to install it even without a dependency on the meta-package "website". -- Configure bugmail: http://bugzilla.rpmfusion.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. You are the assignee for the bug.

http://bugzilla.rpmfusion.org/show_bug.cgi?id=289 --- Comment #21 from Conrad Meyer <konrad(a)tylerc.org&gt; 2009-01-09 21:18:35 --- (Mine came from ATrpms, but it appears they no longer ship it.) -- Configure bugmail: http://bugzilla.rpmfusion.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. You are the assignee for the bug.

http://bugzilla.rpmfusion.org/show_bug.cgi?id=289 --- Comment #23 from Conrad Meyer <konrad(a)tylerc.org&gt; 2009-01-09 21:42:32 --- As opposed to not explicitly listing the dependency at all and expecting users to somehow provide the pieces? How is that better? -- Configure bugmail: http://bugzilla.rpmfusion.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. You are the assignee for the bug.

http://bugzilla.rpmfusion.org/show_bug.cgi?id=289 --- Comment #25 from Gianluca Sforna <giallu(a)gmail.com&gt; 2009-01-10 13:57:29 --- (In reply to comment #24) In the latter case (i.e. if user intervention is needed after installation) it would be nice to mention it in the package description, see for instance mailman spec file. -- Configure bugmail: http://bugzilla.rpmfusion.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. You are the assignee for the bug.

http://bugzilla.rpmfusion.org/show_bug.cgi?id=289 --- Comment #27 from Erik van Pienbroek <erik-rpmfusion(a)vanpienbroek.nl&gt; 2009-01-10 17:53:55 --- (In reply to comment #26) No, that doesn't solve the problem. The problem is that the w32codecs need to be installed before any gstreamer application is launched after the installation of gstreamer-pitfdll. If this isn't done, the w32codecs won't be detected and the user is forced to remove the ~/.gstreamer-0.10 directory before the w32codecs will be detected by gstreamer. The only situation where this command would give the right effect is in a w32codecs RPM package...but as we can't put it in RPMFusion it's a no-go.. -- Configure bugmail: http://bugzilla.rpmfusion.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. You are the assignee for the bug.

http://bugzilla.rpmfusion.org/show_bug.cgi?id=289 --- Comment #29 from Erik van Pienbroek <erik-rpmfusion(a)vanpienbroek.nl&gt; 2009-01-11 13:53:14 --- (In reply to comment #28) Not really. GStreamer only performs a plugin recheck when a new or changed file in %{_libdir}/gstreamer-0.10 is detected. So, after the installation of gstreamer-pitfdll, gstreamer notices there's a new plugin and thus performs a plugin recheck. However, if at this time, the w32codecs aren't installed in /usr/lib/codecs, the pitfdll plugin will be detected, but no 'features' (supported audio/video formats) will be provided by the plugin. Without any 'features', this plugin is useless. -- Configure bugmail: http://bugzilla.rpmfusion.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. You are the assignee for the bug.

http://bugzilla.rpmfusion.org/show_bug.cgi?id=289 Allisson Azevedo <allisson(a)gmail.com&gt; changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |WONTFIX --- Comment #31 from Allisson Azevedo <allisson(a)gmail.com&gt; 2009-01-13 23:20:33 --- Hi all, There is some problems with this package for inclusion on rpmfusion, and the upstream is probably dead. Thanks for all comments, i close this bug as wontfix. -- Configure bugmail: http://bugzilla.rpmfusion.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. You are the assignee for the bug.

http://bugzilla.rpmfusion.org/show_bug.cgi?id=289 --- Comment #33 from Allisson Azevedo <allisson(a)gmail.com&gt; 2009-01-14 00:23:37 --- Hi Erik, Thanks for your review, if anyone wish work on this package feel free to use my spec file. I'll submit other packages for rpmfusion soon. -- Configure bugmail: http://bugzilla.rpmfusion.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. You are the assignee for the bug.