[Bug 1530] Review request: gstreamer-vaapi - A collection of VA-API based plugins for GStreamer and helper libraries
https://bugzilla.rpmfusion.org/show_bug.cgi?id=1530 --- Comment #6 from Sam Hegarty 2012-01-27 03:13:27 CET --- Created attachment 789 --> https://bugzilla.rpmfusion.org/attachment.cgi?id=789 patch that goes with the spec file -- Configure bugmail: https://bugzilla.rpmfusion.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 1530] Review request: gstreamer-vaapi - A collection of VA-API based plugins for GStreamer and helper libraries
https://bugzilla.rpmfusion.org/show_bug.cgi?id=1530 --- Comment #5 from Sam Hegarty 2012-01-27 03:12:34 CET --- Created attachment 788 --> https://bugzilla.rpmfusion.org/attachment.cgi?id=788 updated spec file -- Configure bugmail: https://bugzilla.rpmfusion.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 2104] Review request: TestU01 - Utilities for the statistical testing of uniform random number generators
https://bugzilla.rpmfusion.org/show_bug.cgi?id=2104 Jeremy Newton changed: What|Removed |Added AssignedTo|rpmfusion-package-review@rp |alexjn...@hotmail.com |mfusion.org | -- Configure bugmail: https://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.
[Bug 2104] Review request: TestU01 - Utilities for the statistical testing of uniform random number generators
https://bugzilla.rpmfusion.org/show_bug.cgi?id=2104 Jeremy Newton changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #7 from Jeremy Newton 2012-01-27 01:32:49 CET --- Thanks! I try to do a review this weekend. -- Configure bugmail: https://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.
How can Fedora sponsored packager become a rpm fusion sponsored packager?
Hello everybody, I'm a Fedora sponsored packager. I have now created my rpmfusion account and according to http://rpmfusion.org/Contributors#head-643ba68e754c44d2db673ad9aea6a843ad0b7fb3 I should be now able to review rpmfusion packages as well. However it's not clear to me what is the process to become a rpmfusion sponsored packager. Do I need to apply for it somehow? Thanks a lot Jirka
[Bug 2101] Review request: vbam - High compatibility Gameboy Advance Emulator combining many VBA developments
https://bugzilla.rpmfusion.org/show_bug.cgi?id=2101 --- Comment #16 from Jeremy Newton 2012-01-27 01:29:24 CET --- Thanks! :) Also, earlier today I managed to figure out the issue I had with the latest version 1.8.0.1054 and I just updated the SPEC. So here's the newer version instead: SPEC: http://dl.dropbox.com/u/42480493/vbam.spec SRPM: http://dl.dropbox.com/u/42480493/vbam-1.8.0.1054-1.fc16.src.rpm Unfortunately this new build gives me a rpmlint error, which I can't seem to figure out how to fix: vbam-wx.x86_64: E: binary-or-shlib-defines-rpath /usr/bin/wxvbam ['/home/makerpm/rpmbuild/BUILD/vbam-1.8.0.1054'] If this does pose a problem, the WX gui can be disabled until a solution is found; note the GTK gui does not have this error. -- Configure bugmail: https://bugzilla.rpmfusion.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 2104] Review request: TestU01 - Utilities for the statistical testing of uniform random number generators
https://bugzilla.rpmfusion.org/show_bug.cgi?id=2104 --- Comment #6 from Jirka 2012-01-27 01:21:53 CET --- Hi Jeremy, I took your BZ https://bugzilla.rpmfusion.org/show_bug.cgi?id=2101 and I plan to review it over the weekend. Review guidelines are at http://fedoraproject.org/wiki/Packaging/ReviewGuidelines Please note that above are Fedora guidelines so please omit the restrictions regarding the license. Thanks Jirka -- Configure bugmail: https://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.
[Bug 2101] Review request: vbam - High compatibility Gameboy Advance Emulator combining many VBA developments
https://bugzilla.rpmfusion.org/show_bug.cgi?id=2101 Jirka changed: What|Removed |Added AssignedTo|rpmfusion-package-review@rp |hladky.j...@googlemail.com |mfusion.org | -- Configure bugmail: https://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.
[Bug 1252] Review request: swftools - SWF manipulation and generation utilities
https://bugzilla.rpmfusion.org/show_bug.cgi?id=1252 Mohamed El Morabity changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #30 from Mohamed El Morabity 2012-01-27 01:13:59 CET --- Built. Closing. -- Configure bugmail: https://bugzilla.rpmfusion.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 2101] Review request: vbam - High compatibility Gameboy Advance Emulator combining many VBA developments
https://bugzilla.rpmfusion.org/show_bug.cgi?id=2101 --- Comment #15 from Jirka 2012-01-27 01:12:34 CET --- Hi Jeremy, I have taken this BZ as I plan to do the formal review hopefully over the weekend. Thanks Jirka -- Configure bugmail: https://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.
[Bug 2101] Review request: vbam - High compatibility Gameboy Advance Emulator combining many VBA developments
https://bugzilla.rpmfusion.org/show_bug.cgi?id=2101 Jirka changed: What|Removed |Added Status|NEW |ASSIGNED CC||hladky.j...@googlemail.com -- Configure bugmail: https://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.
[Bug 1034] Review request: sinthgunt - An easy to use GUI for ffmpeg
https://bugzilla.rpmfusion.org/show_bug.cgi?id=1034
--- Comment #19 from Richard 2012-01-26 16:12:24 CET ---
Figured it out! The montage command actually handles this nicely.
Something like this should do it:
# Create square icons from logo file.
montage -crop +0+1 -background white -geometry +0+18 logo.png icon.png
convert -resize 48x48 icon.png
%{buildroot}%{_sharedir}/icons/hicolor/48x48/apps/sinthgunt.png
mv icon.png %{buildroot}%{_sharedir}/icons/hicolor/128x128/apps/sinthgunt.png
--
Configure bugmail: https://bugzilla.rpmfusion.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.
[Bug 1034] Review request: sinthgunt - An easy to use GUI for ffmpeg
https://bugzilla.rpmfusion.org/show_bug.cgi?id=1034 --- Comment #18 from Richard 2012-01-26 15:09:10 CET --- (In reply to comment #17) > Small ping to say that I'm not dead! I'm overwhelmed by my current job right > now and don't have all the time I would wish for this package but that will > come soon. No problem! I occasionally have the same problem. > I got to the point that I placed all the icons in /usr/share/icons/. So I just > need to fire up Gimp and work on the icons itself. Gimp is fine but I wonder if there's a magic incantation of "mogrify" that would do it on the fly... That way if upstream changes something it will automatically get updated. I'll ponder that when I have a moment. Richard -- Configure bugmail: https://bugzilla.rpmfusion.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 1034] Review request: sinthgunt - An easy to use GUI for ffmpeg
https://bugzilla.rpmfusion.org/show_bug.cgi?id=1034 --- Comment #17 from Jean-Francois Saucier 2012-01-26 14:00:22 CET --- Small ping to say that I'm not dead! I'm overwhelmed by my current job right now and don't have all the time I would wish for this package but that will come soon. I got to the point that I placed all the icons in /usr/share/icons/. So I just need to fire up Gimp and work on the icons itself. -- Configure bugmail: https://bugzilla.rpmfusion.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 1615] openni-nite - OpenNI-based toolbox for hand movement tracking
https://bugzilla.rpmfusion.org/show_bug.cgi?id=1615 --- Comment #4 from Tim Niemueller 2012-01-26 10:35:16 CET --- Yes I am! I have uploaded a new version at http://www.niemueller.de/share/openni-nite-1.4.1.2-1.fc15.src.rpm. The spec file has been changed in place. -- Configure bugmail: https://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.
Re: Corner cases for -kmod-common packages
Philip Prindeville wrote on 26.01.2012 09:04: > On 1/26/12 12:43 AM, Kevin Kofler wrote: >> Philip Prindeville wrote: > [...] > It's more of a tooling issue as I see it than an organizational > requirement on how the .spec should be managed. > > I'd rather fix the tool than work around it. Then I'd say: Go and work towards fixing the tools and the tools and workflows behind it (when I was handling the pushes for RPM Fusion I sometimes removed old kmods by simply removing old SRPMs, then the push scripts removed all the compiled kmods -- with a scheme like your that would delete the common package, too). Until then I'd say the split is the easiest. CU knurd P.S.: And I'd say the kmod scheme has way bigger problems that might be worth addressing first. Just my point of view.
Re: Bundling exception
Alec Leamas wrote: > The standard questions: > - Yes, the library has been modified. The overall diff is >6000 lines, > baselined w latest svn version. > - Ilya, the Bombono developer, has been in contact w John Torjo, the > author of the package. As I understand the situation, John torjo has > lost interest in it when it was rejected from inclusion in boost core. > He has not made any attempts to fix things after 2008, including input > from Ilya. > - The package does not exist in Fedora, no maintainer to discuss with. > - The 'bombono version' is of no interest to others as explained above, > nor is the unpatched original sources. > - Upstream is dead. > - Upstream's attitude towards bundling is unknown. > - This is a logging package, basically stream io to files and console. > I see no immediate security concerns in this type of software(?) > - The plan is to unbundle the package when boost-log becomes part of > boost. This should be a minor fix. I'm usually the bundling police ;-) , but considering all of the above, I agree that an exception seems warranted here. (And I see Hans, who definitely has more authority here on RPM Fusion than me, agrees.) Kevin Kofler
Re: Corner cases for -kmod-common packages
Philip Prindeville wrote: > This is a variant of that scenario. If the version number of the rpm has > changed (as well as the timestamp), but the content manifest and hash of > the contents themselves remains identical, rpm should not update the > package. Changing RPM would achieve almost nothing: Updating the package on disk isn't the expensive part, downloading it (and getting needlessly prompted by the updater!) is. You would also need to change yum (and zif) there, which also includes changing the repository metadata backwards-incompatibly, because there's no metadata for a checksum covering package contents only (without the RPM header). So yum shouldn't prompt you for the useless update, but it will need to change the version recorded in the RPM database in case there are RPM dependencies on the new version, so it'd silently change the RPM database, which opens a HUGE can of worms. Things aren't as easy and straightforward as you seem to think… > It's more of a tooling issue as I see it than an organizational > requirement on how the .spec should be managed. > > I'd rather fix the tool than work around it. Sorry, but you have to expect that RPM and yum will NEVER be changed the way you ask. You need to work with what's there. That's what guidelines are for. I don't see how a specfile you basically never have to touch, and which got reviewed and approved in one go along with the other one, is a burden in any way. Kevin Kofler
Re: Bundling exception
Hi, On 01/25/2012 11:00 PM, Alec Leamas wrote: Applying for bundling exception: boost-logging in bombono-dvd I think this is a reasonable request, so ack from me (but lets wait a few days to see if others disagree). Regards, Hans
[Bug 1615] openni-nite - OpenNI-based toolbox for hand movement tracking
https://bugzilla.rpmfusion.org/show_bug.cgi?id=1615 Gianluca Sforna changed: What|Removed |Added CC||gia...@gmail.com --- Comment #3 from Gianluca Sforna 2012-01-26 09:28:49 CET --- Hi, are you still interested in packaging this? If so I'd like to help with the review. BTW, for the Source0, Source1 tags you can use links like: http://www.openni.org/downloads/NITE-Bin-Linux-x64-v1.5.2.21.tar.bz2 -- Configure bugmail: https://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.
Re: Corner cases for -kmod-common packages
On 1/26/12 12:43 AM, Kevin Kofler wrote: > Philip Prindeville wrote: >> In the case of a trivial (and invariant!) -kmod-common file, should we be >> allowed to keep everything in a single .spec? > > That would mean the package gets needlessly updated each time the kmod is > rebuilt from a new kernel, even though it never changed at all. So that's > exactly the reason why a separate specfile and SRPM is needed! > > Kevin Kofler > Yeah, but this is an artifact of rpm/yum and indeed a previous issue: when you built a library (for instance) as both x86_64 and i686 binaries on Fedora 16, the first one installed might create a yyy.conf file and then when rpm tried to install the same file again (but with a slightly different timestamp as they would have been built sequentially) rpm would assume that the file had been modified and leave you both an xxx.conf file and a yyy.conf.rpmnew file. This was eventually fixed in rpm so that the size, modes, and hash of the contents were used, but the timestamp was ignored. This is a variant of that scenario. If the version number of the rpm has changed (as well as the timestamp), but the content manifest and hash of the contents themselves remains identical, rpm should not update the package. It's more of a tooling issue as I see it than an organizational requirement on how the .spec should be managed. I'd rather fix the tool than work around it. -Philip
