Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: alsa-firmware - Firmware for several ALSA-supported sound card https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=217259 tibbs@xxxxxxxxxxx changed: What |Removed |Added ---------------------------------------------------------------------------- Component|Package Review |ORBit ------- Additional Comments From tibbs@xxxxxxxxxxx 2007-07-26 23:13 EST ------- I finally have some free time now, so.... This builds fine; rpmlint says: W: alsa-firmware strange-permission alsa-firmware.spec 0660 Kind of weird and quite insecure on many systems. Should be 644. I don't know if this matters at all once things are in CVS. W: alsa-firmware mixed-use-of-spaces-and-tabs (spaces: line 10, tab: line 1) I don't see this as a problem; fix it if you like. W: alsa-firmware incoherent-version-in-changelog 0:1.0.12-1 1.0.12-1.fc8 rpmlint doesn't like seeing the epoch there, but I think this is an rpmlint issue. E: alsa-firmware arch-independent-package-contains-binary-or-object /usr/share/alsa/firmware/mixartloader/miXart8.elf E: alsa-firmware arch-independent-package-contains-binary-or-object /lib/firmware/mixart/miXart8.elf You explained these initially. So no big rpmlint problems. This does not install, due to an unsatisfied dependency on alsa-tools-firmware >= 1.0.12. I guess this is a subpackage of alsa-tools which is currently disabled. You own alsa-tools so it should be pretty easy to get it turned on. I have no hope of testing this anyway so not being able to install it isn't much of an impediment to a review. The license does concern me (GPL but there's no real source, just C files containing data) but if spot has already acked it then I suppose it's OK. I'll ping him on it before I approve anything. The specfile does not consistently use macros. If you want to use %{__make} and %{__rm}, you need to use them everywhere and also use %{__mv} and %{__cp}. The current version seems to be 1.0.14, which came out in June. Any reason not to package it? Because of the missing dependency, I can't determine whether /usr/share/alsa is properly owned. It's provided by alsa-utils, but I can't tell if it's in the dependency chain since alsa-tools-firmware doesn't exist. * source files match upstream: 6e7d3104c4de7d031790c1e750067b13e9481bf2855b0806a300d1e697549fbd alsa-firmware-1.0.12.tar.bz2 * package meets naming and versioning guidelines. * specfile is properly named X specfile does not use macros consistently. * summary is OK. * description is OK. * dist tag is present. * build root is OK. * license field matches the actual license. * license is open source-compatible. * license text included in package. X latest version is not being packaged. * BuildRequires are proper. * compiler flags are appropriate (not that it matters for a noarch package). * %clean is present. * package builds in mock (development, x86_64). X package fails to install properly due to a missing dependency. * rpmlint has acceptable complaints. * final provides and requires are sane: alsa-firmware = 1.0.12-1.fc8 = alsa-tools-firmware >= 1.0.12 udev * %check is not present; no test suite upstream. I have no hope of testing this pacakge. * no shared libraries are added to the regular linker search paths. ? owns the directories it creates. * doesn't own any directories it shouldn't. * no duplicates in %files. * file permissions are appropriate. * no scriptlets present. * This is acceptable content. * documentation is small, so no -docs subpackage is necessary. * %docs are not necessary for the proper functioning of the package. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. _______________________________________________ Fedora-package-review mailing list Fedora-package-review@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-package-review