[Bug 2803] New: Review request: opencv - Collection of algorithms for computer vision
by RPM Fusion Bugzilla
https://bugzilla.rpmfusion.org/show_bug.cgi?id=2803
Bug #: 2803
Summary: Review request: opencv - Collection of algorithms for
computer vision
Classification: Unclassified
Product: Package Reviews
Version: Current
Platform: All
OS/Version: GNU/Linux
Status: NEW
Severity: normal
Priority: P5
Component: Review Request
AssignedTo: rpmfusion-package-review(a)rpmfusion.org
ReportedBy: sanjay.ankur(a)gmail.com
CC: rpmfusion-package-review(a)rpmfusion.org
SPEC/SRPM:
http://ankursinha.fedorapeople.org/opencv-rpmfusion/opencv.spec
http://ankursinha.fedorapeople.org/opencv-rpmfusion/opencv-2.4.4-3.fc20.s...
Description:
OpenCV means Intel® Open Source Computer Vision Library. It is a collection of
C functions and a few C++ classes that implement some popular Image Processing
and Computer Vision algorithms.
fas username: ankursinha (package maintainer)
This package includes only the nonfree and gpu shared objects that aren't
available in the fedora package. I haven't been able to build the CUDA related
stuff yet.
It's my first rpmfusion package :)
[ankur@ankur-pc SRPMS]$ rpmlint
/var/lib/mock/fedora-rawhide-x86_64/result/*.rpm ../SPECS/opencv.spec
./opencv-2.4.4-3.fc19.src.rpm
opencv-free.x86_64: W: spelling-error Summary(en_US) Nonfree -> Non free,
Non-free, Freon
opencv-free.x86_64: W: spelling-error %description -l en_US nonfree -> non
free, non-free, Freon
opencv-free.x86_64: W: no-documentation
opencv-free-devel.x86_64: W: spelling-error Summary(en_US) Nonfree -> Non free,
Non-free, Freon
opencv-free-devel.x86_64: W: spelling-error %description -l en_US nonfree ->
non free, non-free, Freon
opencv-free-devel.x86_64: W: no-documentation
opencv-nonfree.x86_64: W: no-documentation
opencv-nonfree-devel.x86_64: W: no-documentation
opencv.src: W: invalid-url Source0:
http://downloads.sourceforge.net/opencvlibrary/OpenCV-2.4.4a.tar.bz2 timed out
7 packages and 1 specfiles checked; 0 errors, 9 warnings.
[ankur@ankur-pc SRPMS]$
--
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.
10 years, 10 months
[Bug 2455] New: Review request: pcsx2 - A Sony Playstation2 emulator
by RPM Fusion Bugzilla
https://bugzilla.rpmfusion.org/show_bug.cgi?id=2455
Bug #: 2455
Summary: Review request: pcsx2 - A Sony Playstation2 emulator
Classification: Unclassified
Product: Package Reviews
Version: Current
Platform: All
OS/Version: GNU/Linux
Status: NEW
Severity: normal
Priority: P5
Component: Review Request
AssignedTo: rpmfusion-package-review(a)rpmfusion.org
ReportedBy: gbirchley(a)blueyonder.co.uk
CC: rpmfusion-package-review(a)rpmfusion.org
The SPEC file and SRPM of this package are available at the following URLs (the
files are compressed as tarballs to upload to forum)-
SRPM: http://forums.pcsx2.net/attachment.php?aid=39887
SPEC - http://forums.pcsx2.net/attachment.php?aid=39888
Description: PCSX2 is an open source Playstation 2 emulator. It requires a dump
of a real Playstation 2 BIOS, which is not included.
Why this package is not eligible to be included in Fedora: Fedora does not
allow emulators
The output rpmlint gives on both the source and binary packages:
$ rpmlint pcsx2-1.0-2.fc16.src.rpm
pcsx2.src:23: E: buildarch-instead-of-exclusivearch-tag i686
[Comment: needs i686 packages to compile, will run in x86_64]
pcsx2.src: W: invalid-url Source0:
http://pcsx2.googlecode.com/svn/branches/1.0/pcsx2-1.0.tar.gz HTTP Error 404:
Not Found
[Comment: Compiled from subversion - have included shell script to build a
tarball as a source and instructions for in comments]
1 packages and 0 specfiles checked; 1 errors, 1 warnings.
$ rpmlint pcsx2-1.0-2.fc16.i686.rpm
pcsx2.i686: W: no-manual-page-for-binary pcsx2_ZZCGReplayLoader
[Comment:this is a debugging tool as pcsx2 is a WIP. Will help development to
include this package, so users can follow debug insructions from developers but
no man page available]
pcsx2.i686: W: no-manual-page-for-binary pcsx2_ZZReplayLoader
[Comment:ditto above comment]
pcsx2.i686: W: no-manual-page-for-binary pcsx2_GSReplayLoader
[Comment:ditto above comment]
1 packages and 0 specfiles checked; 0 errors, 3 warnings.
This is my first RPM fusion package. It is built with the help of a packager on
fedora forums - I am a packaging novice - and then maintained by me on the
fedora forum for about a year]
I am seeking a sponsor.
--
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.
10 years, 11 months
Moving xine-lib and dependent apps to RPM Fusion Free for F17?
by Kevin Kofler
Hi,
the current xine-lib maintainer speaking. :-)
The Xine project:
http://www.xine-project.org/home
has recently released a new major version, version 1.2.0.
Unfortunately, among the list of changes:
http://sourceforge.net/projects/xine/files/xine-lib/1.2.0/README.txt.asc/...
there are these new "features":
* Use libavutil-provided implementations for CRC, SHA1 and BASE64 algorithms,
this makes use of libavutil even outside the FFmpeg decoding plugin,
but avoid duplication of algorithms between different plugins.
* Use av_mallocz() when xine_xmalloc_aligned() wouldn't be needed.
* FFmpeg is now required as an external dependency; if you want to build
xine-lib from source, please download a copy of FFmpeg from their SVN
server.
which basically mean that xine-lib now has a global, non-optional dependency
on FFmpeg's libavutil library.
So there are 4 possible ways forward:
(a) Stick with 1.1.x forever. I don't think that's a good idea in the long
run, upstream won't be providing security fixes for the old branch forever.
(b) Package libavutil (and only libavutil) from FFmpeg in Fedora. (I don't
think libavutil, as opposed to libavcodec, is actually patent-encumbered,
though that'd also have to be checked.) The issue there is that FFmpeg
upstream obviously doesn't support this. It would need some more black
packaging magic of the kind already done in xine-lib, and more legal
auditing. I don't think I want to investigate going down that road.
(c) Bundle parts or all of libavutil with xine-lib. Yuck!!!
(d) Move the whole thing (back) to RPM Fusion (where it originally was, before
we started needing xine-lib for Amarok and Phonon, which both no longer
use it). It would go to the Free section, of course.
My proposal is to go with (d).
The following packages currently depend on xine-lib:
* gxine
* (k9copy – already in RPM Fusion, not affected)
* kaffeine (my package, the reason why I maintain xine-lib in the first place)
* oxine
* xine-plugin
* xine-ui
These packages would have to move to RPM Fusion along with xine-lib.
In Kaffeine's case, upstream is switching from xine-lib to MPlayer in their git
repository, so it will likely have to move to RPM Fusion sooner or later
anyway. This means the affected packages are basically *xine*.
So my plan is to retire (for my packages, resp. have the respective maintainer
retire) the listed packages in Fedora for Fedora ≥ 17 and get (or have the
respective maintainer get) them into RPM Fusion Free instead. (I'd take care
of xine-lib and kaffeine myself, I hope the maintainers of the other packages
will take care of them.)
Comments? Objections?
Kevin Kofler
11 years, 1 month
[RPM Fusion] Issue with fedora's openssl package for libbluray/libaacs
by Nicolas Chauvet
Hi,
As you may know, the libaacs package from RPM Fusion rely on openssl
functions that have been disabled in the fedora package for some
reason.
This lead the libaacs package to be partially unuseable for it's target usage.
I would like to list what would be possible workarounds for this
issue. We likely need to build a openssl-freeworld package:
- Build a similar package and drop a file in ld.conf.d to make it
system wide ? (the freetype-freeworld way)
This seems unpractical as we may produce unknown behavior and
un-certified code path with others applications.
- Build a shared object with another SONAME so packages liked with the
freeworld version will not conflict with package linked with the
fedora version.
(It will eventually be possible to relink the so to the the fedora
SONAME manually in a second step).
- Build the freeworld version statically.
The question to sync the patch between fedora and RPM Fusion VCS is a
big question until we move to git, so I hope that progress will be
made in this area soon.
If not we may experiment an openssl-freeworld to be possibily behind
the fedora version.
Any thoughts on that ?
Nicolas (kwizart).
11 years, 1 month
[Bug 2550] New: Review request: wl-bcm43142-kmod - X86_64 Kernel module for Broadcom wireless devices BCM43142
by RPM Fusion Bugzilla
https://bugzilla.rpmfusion.org/show_bug.cgi?id=2550
Bug #: 2550
Summary: Review request: wl-bcm43142-kmod - X86_64 Kernel
module for Broadcom wireless devices BCM43142
Classification: Unclassified
Product: Package Reviews
Version: Current
Platform: x86_64
OS/Version: GNU/Linux
Status: NEW
Severity: normal
Priority: P5
Component: Review Request
AssignedTo: rpmfusion-package-review(a)rpmfusion.org
ReportedBy: nicolas.vieville(a)univ-valenciennes.fr
CC: rpmfusion-package-review(a)rpmfusion.org
SPEC file:
http://dl.dropbox.com/u/25699833/rpmfusion/F-18/wl-bcm43142-kmod/wl-bcm43...
SRPMS file:
http://dl.dropbox.com/u/25699833/rpmfusion/F-18/wl-bcm43142-kmod/wl-bcm43...
Sources URL:
http://jas.gemnetworks.com/wireless-bcm43142/
Description:
These packages contain x86_64 Broadcom's IEEE 802.11a/b/g/n hybrid Linux device
driver for use with Broadcom's BCM43142-based hardware also known as Broadcom
bcm4365 or Dell 1704 wireless device.
rpmlint wl-bcm43142-kmod.spec
0 packages and 1 specfiles checked; 0 errors, 0 warnings.
rpmlint wl-bcm43142-kmod-6.20.55.19-1.fc18.src.rpm
1 packages and 0 specfiles checked; 0 errors, 0 warnings.
Package not eligible to be included in Fedora as it contains some
non-modifiable binary.
As the maintainer of the actual wl-kmod package for rpmfusion, a user asked me
if I could provide the last broadcom wireless drivers for BCM43142-based
hardware, because this chipset is not driven by the actual package. He pointed
me to the actual maintainer site of this package for Debian, and these packages
(broadcom-wl-bcm43142 review request will follow) are largely inspired from
this site (http://jas.gemnetworks.com/wireless-bcm43142/).
The original package was shipped with Ubuntu's Dell laptop, but as far as I
know (digging the Web for 2 days) neither Broadcom or Dell provided on their
websites any sources for this driver. The only source cited by the Debian
packager is actually this site:
http://wielki.tk/vostro/
According to message #60 in this thread
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=688823#60, Broadcom will not
update the official Broadcom STA driver (aka 5.100.82.112) as the new one was a
Dell/Ubuntu specific only.
While preparing these packages, I had to make some choices and I wonder if
someone could review and comment them if needed:
1.
These new package are x86_64 architecture only. Broadcom/Dell didn't provided
any binary library for i386 (32 bits) platform. I had to make these packages
x86_64 platform only by adding a "ExclusiveArch: x86_64" directive in the SPEC
file, and adding checking in the %prep section of this file too. Is this
correct?
2.
As this new driver doesn't work with some older Broadcom chipset (mine is
bcm4313 and doesn't work with it for example) that still work correctly with
5.100.82.112 driver, I didn't choice to use conflict directive in the SPEC
file. If one has a new chipset in his laptop and plug-in an old one via USB
port the problem will be unsolvable. I preferred to rename the new build module
with a different name to let users deal with there configuration more smoothly
(I hope that modifying some udev rules might be necessary to get them working).
So the new build module was rename from wl.ko to wl_bcm43142.ko at build time.
Is this correct, or am I wrong?
3.
As stated by all the users owning such laptop and wanting to upgrade their
original Ubuntu 11.10 to the last 12.04 or 12.10, this chipset is hybrid but
actually no bluetooth is working. Some efforts are made by Ubuntu developers to
get it working, but for the moment this part of the chipset is not supported
(see
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/863051/+index?commen...).
What is the best thing to do to inform users of such a limitation in this
package?
4.
After all, is it worth packaging this driver?
I can provide rawhide SPEC and SRPMS files if needed.
I plan to make it available since F-17 if accepted.
Same request made for the broadcom-wl-bcm43142 package.
As I do not own myself such a device, I would not be able to test new packages
as they would be build. Are there any volunteers to achieve this task?
Last question: as I'm already a rpmfusion packager, but not so experienced, do
I need a sponsor?
Thanks in advance for your comments.
Cordially,
--
NVieville
--
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.
11 years, 2 months
[Bug 2549] New: Review request: broadcom-wl-bcm43142 - Common files for Broadcom 802.11 STA driver for BCM43142 devices
by RPM Fusion Bugzilla
https://bugzilla.rpmfusion.org/show_bug.cgi?id=2549
Bug #: 2549
Summary: Review request: broadcom-wl-bcm43142 - Common files
for Broadcom 802.11 STA driver for BCM43142 devices
Classification: Unclassified
Product: Package Reviews
Version: Current
Platform: x86_64
OS/Version: GNU/Linux
Status: NEW
Severity: normal
Priority: P5
Component: Review Request
AssignedTo: rpmfusion-package-review(a)rpmfusion.org
ReportedBy: nicolas.vieville(a)univ-valenciennes.fr
CC: rpmfusion-package-review(a)rpmfusion.org
SPEC file:
http://dl.dropbox.com/u/25699833/rpmfusion/F-18/broadcom-wl-bcm43142/broa...
SRPMS file:
http://dl.dropbox.com/u/25699833/rpmfusion/F-18/broadcom-wl-bcm43142/broa...
Sources URL:
http://jas.gemnetworks.com/wireless-bcm43142/
Description:
This package contains the license, copyright and configuration files for the
Broadcom 802.11 Linux STA Driver for WiFi, a Linux device driver for use with
Broadcom's BCM43142-based hardware also known as Broadcom bcm4365 or Dell 1704
wireless device.
rpmlint broadcom-wl-bcm43142.spec
0 packages and 1 specfiles checked; 0 errors, 0 warnings.
rpmlint broadcom-wl-bcm43142-6.20.55.19-1.fc18.src.rpm
1 packages and 0 specfiles checked; 0 errors, 0 warnings.
Package not eligible to be included in Fedora as it contains some
non-modifiable binary.
As the maintainer of the actual broadcom-wl package for rpmfusion, a user asked
me if I could provide the last broadcom wireless drivers for BCM43142-based
hardware, because this chipset is not driven by the actual package. He pointed
me to the actual maintainer site of this package for Debian, and these packages
(wl-bcm43142-kmod review request will follow) are largely inspired from this
site (http://jas.gemnetworks.com/wireless-bcm43142/).
The original package was shipped with Ubuntu's Dell laptop, but as far as I
know (digging the Web for 2 days) neither Broadcom or Dell provided on their
websites any sources for this driver. The only source cited by the Debian
packager is actually this site:
http://wielki.tk/vostro/
According to message #60 in this thread
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=688823#60, Broadcom will not
update the official Broadcom STA driver (aka 5.100.82.112) as the new one was a
Dell/Ubuntu specific only.
While preparing these packages, I had to make some choices and I wonder if
someone could review and comment them if needed:
1.
These new package are x86_64 architecture only. Broadcom/Dell didn't provided
any binary library for i386 (32 bits) platform. I had to make these packages
x86_64 platform only by adding a "ExclusiveArch: x86_64" directive in the SPEC
file, and adding checking in the %prep section of this file too. Is this
correct?
2.
As this new driver doesn't work with some older Broadcom chipset (mine is
bcm4313 and doesn't work with it for example) that still work correctly with
5.100.82.112 driver, I didn't choice to use conflict directive in the SPEC
file. If one has a new chipset in his laptop and plug-in an old one via USB
port the problem will be unsolvable. I preferred to rename the new build module
with a different name to let users deal with there configuration more smoothly
(I hope that modifying some udev rules might be necessary to get them working).
So the new build module was rename from wl.ko to wl_bcm43142.ko at build time.
Is this correct, or am I wrong?
3.
As stated by all the users owning such laptop and wanting to upgrade their
original Ubuntu 11.10 to the last 12.04 or 12.10, this chipset is hybrid but
actually no bluetooth is working. Some efforts are made by Ubuntu developers to
get it working, but for the moment this part of the chipset is not supported
(see
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/863051/+index?commen...).
What is the best thing to do to inform users of such a limitation in this
package?
4.
After all, is it worth packaging this driver?
I can provide rawhide SPEC and SRPMS files if needed.
I plan to make it available for F-17 if accepted.
Same request made for the wl-bcm43142-kmod package.
As I do not own myself such a device, I would not be able to test new packages
as they would be build. Are there any volunteers to achieve this task?
Last question: as I'm already a rpmfusion packager, but not so experienced, do
I need a sponsor?
Thanks in advance for your comments.
Cordially,
--
NVieville
--
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.
11 years, 2 months
[Bug 2795] New: Review request: caja-dropbox - Dropbox extension for caja (MATE file manager)
by RPM Fusion Bugzilla
https://bugzilla.rpmfusion.org/show_bug.cgi?id=2795
Bug #: 2795
Summary: Review request: caja-dropbox - Dropbox extension for
caja (MATE file manager)
Classification: Unclassified
Product: Package Reviews
Version: Current
Platform: All
OS/Version: GNU/Linux
Status: NEW
Severity: normal
Priority: P5
Component: Review Request
AssignedTo: rpmfusion-package-review(a)rpmfusion.org
ReportedBy: chat-to-me(a)raveit.de
CC: rpmfusion-package-review(a)rpmfusion.org
Spec URL: http://raveit65.fedorapeople.org/Mate/SPECS/caja-dropbox.spec
SRPM URL:
http://raveit65.fedorapeople.org/Mate/SRPM/caja-dropbox-1.6.0-1.fc20.src.rpm
Dropbox extension for caja file manager.
Dropbox cloud allows you to sync your files online and across
your computers automatically.
The package himself use GPLv3+ and CC-BY-ND licenses and it is only a extension
for the file manager, but it use a "dropbox.in" script inside the tarball,
which installs the main proprietary software from dropbox.
Caja-dropbox needs this proprietary software for useful and proper function.
"Packages which are not useful without external bits "
For this reason i can't package caja-dropbox directly in fedora.
Rpmlint
-------
Checking: caja-dropbox-1.6.0-1.fc20.x86_64.rpm
1 packages and 0 specfiles checked; 0 errors, 0 warnings.
Rpmlint (installed packages)
----------------------------
# rpmlint caja-dropbox
1 packages and 0 specfiles checked; 0 errors, 0 warnings.
This is my first package for rpmfusion but i'm sponsored packager for fedora.
--
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.
11 years, 4 months