Lubomir Rintel <lkundrak(a)v3.sk> changed:
What |Removed |Added
--- Comment #2 from Lubomir Rintel <lkundrak(a)v3.sk> 2009-08-20 09:01:46 ---
Correct path to XOrg driver SRPM:
(In reply to comment #0)
However, the driver is entirely
non-functional without the proprietary (but redistributable) packages
psb-firmware and xpsb-glx. I believe therefore that psb-firmware and xpsb-glx
should go in rpmfusion-nonfree.
I'm not sure about psb-firmware. Yes, it's indeed closed, but in case it does
not run on host CPU it would comply with Fedora's requirements; therefore I
think it might make sense to consider it for "free" instead?
akmod-psb.i586: E: devel-dependency libdrm-poulsbo-devel
akmod-psb.i586: E: explicit-lib-dependency libdrm-poulsbo-devel
the dependency is correct; the module needs libdrm-poulsbo-devel to
to build, so the akmod package must obviously require it.
(0) Are you sure the kernel code needs that? I was in doubt, forced the build
with --nodeps and it succeeded (I didn't test the result though).
akmod-psb.i586: W: no-documentation
no-documentation - I
think this is normal for a kmod package? If not, please advise how to add docs.
No need to. Documentation (license file, etc.) should be included in userspace
package that corresponds to the kmod.
libdrm-poulsbo.i586: W: non-conffile-in-etc
The config file
is also intended: there's no reason an end user should modify this file.
(1) Please mark it %config (but not %config(noreplace)). That's basically a
configuration file, whose contents is not to be preserved upon updates
(therefore user should not modify it), but if he does his changes will be
backed up in a .rpmsave file. I guess rpmfusion will download as well.
psb-firmware.i586: E: no-binary
it's just a firmware file. The package is arched because I
believe the firmware
to be arch specific, not that there's ever going to be a Poulsbo graphics chip
in anything but an i586 system.
(2) Looking at the firmware file it doesn't seem it is a valid i386 code
therefore I assume it does not run on a host CPU and therefore is not arch
specific. Please make that package noarch, so that it's not unnecessarily built
redundantly on other plattforms (You could eventually make it ExclusiveArch
i386/i586/i686 on f10, f11, f12 respectively, but I don't believe that would be
needed, since there's no problem with having this on other arches, it doesn't
depend on anything that won't be there, therefore doesn't break dependencies).
xorg-x11-drv-psb.i586: W: non-conffile-in-etc
Please apply (1) here as well.
xorg-x11-drv-psb.i586: W: service-default-enabled
A side note: I believe we're abusing a service to autoconfigure XOrg here, we
should probably do this from udev upon load of psb module. (I'm not advising
you to change that, since we're doing this for nvidia module already.)
xorg-x11-drv-psb.i586: W: incoherent-subsys /etc/rc.d/init.d/psb
xorg-x11-drv-psb.i586: W: incoherent-init-script-name psb ('xorg-x11-drv-psb',
I'm not quite sure what
the incoherent-subsys warning means
Safe to ignore. It's just that you call your subsystem lock and init script
"psb", not "xorg-x11-drv-psb". You're probably more correct here
but the script in question is based
directly on the one from the NVIDIA package.
Oh, by the way, please s/nvidia/psb/ in comments ;)
This will be my first RPM Fusion package (set), if accepted. However,
I am a
sponsored packager for Fedora itself, I maintain congruity and gst-mixer there.
What's your RPM Fusion Account's name?
Note to other RPM Fusion contributors: I'm formally taking this for review, but
since there are multiple packages I'd appreciate if anyone else interested
contributed to the review; just please post status (whether the packages are
being reviewed, or are approved) at the end of each comment, so that we don't
loose track. Thanks!
xorg-x11-drv-psb BEING REVIEWED (1)
libdrm-poulsbo not started (1)
psb-firmware BEING REVIEWED (2)
psb-kmod BEING REVIEWED (0)
xpsb-glx not started
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.