[Bug 559254] New:=?UTF-8?Q?=20Add=20to=20F=2D11=20=2D=2D=20iwl5150=2Dfirmware=20=2D=20=20Firmware=20for=20Intel=C2=AE=20Wireless=205150=20A?=/G/N network adaptors
by Red Hat Bugzilla
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.
Summary: Add to F-11 -- iwl5150-firmware - Firmware for Intel® Wireless 5150 A/G/N network adaptors
https://bugzilla.redhat.com/show_bug.cgi?id=559254
Summary: Add to F-11 -- iwl5150-firmware - Firmware for Intel®
Wireless 5150 A/G/N network adaptors
Product: Fedora
Version: 12
Platform: All
OS/Version: Linux
Status: NEW
Severity: medium
Priority: medium
Component: iwl5150-firmware
AssignedTo: linville(a)redhat.com
ReportedBy: linville(a)redhat.com
QAContact: extras-qa(a)fedoraproject.org
CC: notting(a)redhat.com, linville(a)redhat.com,
jdieter(a)gmail.com, fedora-package-review(a)redhat.com
Depends on: 558550,559253
Estimated Hours: 0.0
Classification: Fedora
Target Release: ---
Clone Of: 559253
+++ This bug was initially created as a clone of Bug #559253 +++
+++ This bug was initially created as a clone of Bug #558550 +++
Spec URL: http://linville.fedorapeople.org/iwl5150-firmware.spec
SRPM URL:
http://linville.fedorapeople.org/iwl5150-firmware-8.24.2.2-1.fc11.src.rpm
Description:
This package contains the firmware required by the iwlagn driver
for Linux to support the iwl5150 hardware. Usage of the firmware
is subject to the terms and conditions contained inside the provided
LICENSE file. Please read it carefully.
--- Additional comment from jdieter(a)gmail.com on 2010-01-25 14:05:37 EST ---
Seeing as I'm the one who reported this, I'll go ahead and take it. I don't
actually have the hardware, so I can't test that it actually works.
--- Additional comment from jdieter(a)gmail.com on 2010-01-25 14:25:20 EST ---
SHA256SUM:
d253e6ff6624639aded67c82df98b2bc4a66eb66400848d5614921d513540cf9 from SRPM
d253e6ff6624639aded67c82df98b2bc4a66eb66400848d5614921d513540cf9 from
http://intellinuxwireless.org/iwlwifi/downloads/iwlwifi-5150-ucode-8.24.2...
Good:
* The package is named according to the Package Naming Guidelines.
* The spec file name matches the base package.
* The package meets the Packaging Guidelines.
* The package is licensed with a Fedora approved license (Redistributable, no
modification permitted - acceptable for firmware)
* The License field in the package spec file matches the actual license.
* LICENSE is included in %doc.
* The spec file is written in American English.
* The spec file for the package is legible.
* The sources used to build the package matches the upstream source.
* The package successfully compiles and builds into binary rpm on i386.
* All build dependencies are listed in BuildRequires.
* The package owns all directories that it creates.
* The package doesn't contain any duplicate files in the %files listing.
* Permissions on files are set properly.
* The package has a %clean section, which contains rm -rf $RPM_BUILD_ROOT.
* The package consistently uses macros.
* The package contains code and permissable content.
* All %doc files do not affect the runtime of the application.
* At the beginning of %install, the package runs rm -rf $RPM_BUILD_ROOT).
* All filenames in rpm packages are valid UTF-8.
* Source URL is canonical
* Buildroot has all required elementsx
* All necessary BuildRequires listed
* All desired features are enabled
* Group Tag is from the official list
Bad:
* All paths begin with macros - firmware is installed directly into
/lib/firmware rather than %lib/firmware, but I'm assuming this is necessary as
it lives in the same place on 32 and 64 bit architectures?
Based on the assumption above, I'm listing this as approved.
--- Additional comment from linville(a)redhat.com on 2010-01-25 15:00:11 EST ---
Yes, the /lib/firmware comment is correct. I dunno who influences/produces
such things, but a %{_yes_I_mean_slash_lib} macro would be nice -- of course,
if it is always /lib anyway I guess it doesn't really matter... :-)
--- Additional comment from linville(a)redhat.com on 2010-01-25 15:03:34 EST ---
New Package CVS Request
=======================
Package Name: iwl5150-firmware
Short Description: Firmware for Intel® Wireless 5150 A/G/N network adaptors
Owners: linville
Branches: F-11 F-12 EL-5
InitialCC: linville
--- Additional comment from tibbs(a)math.uh.edu on 2010-01-27 00:26:05 EST ---
CVS done (by process-cvs-requests.py).
--
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
14 years, 2 months
[Bug 557687] New: Review Request: kmid2 - A MIDI/karaoke player for KDE
by Red Hat Bugzilla
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.
Summary: Review Request: kmid2 - A MIDI/karaoke player for KDE
https://bugzilla.redhat.com/show_bug.cgi?id=557687
Summary: Review Request: kmid2 - A MIDI/karaoke player for KDE
Product: Fedora
Version: rawhide
Platform: All
OS/Version: Linux
Status: NEW
Severity: medium
Priority: medium
Component: Package Review
AssignedTo: nobody(a)fedoraproject.org
ReportedBy: kevin(a)tigcc.ticalc.org
QAContact: extras-qa(a)fedoraproject.org
CC: notting(a)redhat.com, fedora-package-review(a)redhat.com
Estimated Hours: 0.0
Classification: Fedora
Spec URL: http://repo.calcforge.org/f13/kmid2.spec
SRPM URL: http://repo.calcforge.org/f13/kmid2-0.1.1-1.fc12.src.rpm
Description:
KMid2 is a MIDI/karaoke file player, with configurable midi mapper, real
Session Management, drag & drop, customizable fonts, etc. It has a very
nice interface which let you easily follow the tune while changing the
color of the lyrics.
It supports output through external synthesizers, AWE, FM and GUS cards.
It also has a keyboard view to see the notes played by each instrument.
Additional information:
This replaces the old KMid snapshot (straight KDE 4 port of the KDE 3 KMid)
currently in Fedora. Obsoletes/Provides are present.
rpmlint output:
kmid2.i686: W: obsolete-not-provided kmid-devel
3 packages and 0 specfiles checked; 0 errors, 1 warnings.
This is intentional as there's no kmid-devel anymore, there is no libkmid
anymore. But nothing that I know of (other than KMid itself) ever used that
library, so I strongly doubt it will be missed.
--
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
14 years, 2 months
[Bug 554090] Review Request: sugar-physics - A physical world simulator and playground for Sugar
by Red Hat Bugzilla
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=554090
--- Comment #6 from Eric Smith <eric(a)brouhaha.com> 2010-01-31 19:01:28 EST ---
rpmlint output:
sugar-physics.spec:6: W: non-standard-group Sugar/Activities
sugar-physics.noarch: W: non-standard-group Sugar/Activities
Since the Fedora Packaging:SugarActivityGuidelines specifically use the group
Sugar/Activities in the sample spec, the rpmlint warnings are not a problem.
Ideally Sugar/Activities would get added to the official group list.
MUST: The package must be named according to the Package Naming Guidelines. OK
MUST: The spec file for the package is legible and macros are used
consistently. OK
MUST: The package must be licensed with a Fedora approved license and meet the
Licensing Guidelines. OK
MUST: The License field in the package spec file must match the actual license.
OK
MUST: If (and only if) the source package includes the text of the license(s)
in its own file, then that file, containing the text of the license(s) for the
package must be included in %doc. OK
MUST: The spec file must be written in American English. OK
MUST: The spec file for the package MUST be legible. OK
MUST: The sources used to build the package must match the upstream source, as
provided in the spec URL. OK
MUST: The package MUST successfully compile and build into binary rpms on at
least one primary architecture. OK
MUST: If the package does not successfully compile, build or work on an
architecture, then those architectures should be listed in the spec in
ExcludeArch. N/A
MUST: All build dependencies must be listed in BuildRequires, OK
MUST: The spec file MUST handle locales properly. OK
MUST: Every binary RPM package (or subpackage) which stores shared library
files (not just symlinks) in any of the dynamic linker's default paths, must
call ldconfig in %post and %postun. N/A
MUST: Packages must NOT bundle copies of system libraries. OK
MUST: If the package is designed to be relocatable, the packager must state
this fact in the request for review, along with the rationalization for
relocation of that specific package. Without this, use of Prefix: /usr is
considered a blocker. OK
MUST: A package must own all directories that it creates. If it does not create
a directory that it uses, then it should require a package which does create
that directory. OK
MUST: A Fedora package must not list a file more than once in the spec file's
%files listings. OK
MUST: Permissions on files must be set properly. Executables should be set with
executable permissions, for example. Every %files section must include a
%defattr(...) line. OK
MUST: Each package must have a %clean section, which contains rm -rf
%{buildroot} (or $RPM_BUILD_ROOT). OK
MUST: Each package must consistently use macros. OK
MUST: The package must contain code, or permissable content. OK
MUST: Large documentation files must go in a -doc subpackage. N/A
MUST: If a package includes something as %doc, it must not affect the runtime
of the application. OK
MUST: Header files must be in a -devel package. N/A
MUST: Static libraries must be in a -static package. N/A
MUST: Packages containing pkgconfig(.pc) files must 'Requires: pkgconfig' N/A
MUST: If a package contains library files with a suffix (e.g. libfoo.so.1.1),
then library files that end in .so (without suffix) must go in a -devel
package. N/A
MUST: In the vast majority of cases, devel packages must require the base
package using a fully versioned dependency N/A
MUST: Packages must NOT contain any .la libtool archives, these must be removed
in the spec if they are built. N/A
MUST: Packages containing GUI applications must include a %{name}.desktop file,
and that file must be properly installed with desktop-file-install in the
%install section N/A
MUST: Packages must not own files or directories already owned by other
packages. OK
MUST: At the beginning of %install, each package MUST run rm -rf %{buildroot}
(or $RPM_BUILD_ROOT). OK
MUST: All filenames in rpm packages must be valid UTF-8. OK
SHOULD: If the package does not include license text(s) as separate files from
upstream, the packager should query upstream to include it. NEEDSWORK
SHOULD: The description and summary sections in the package spec file should
contain translations for supported Non-English languages, if available.
NEEDSWORK
I'm not sure whether suitable translations are available, but based on the
inclusion of message translations in the package, it seems like they might be.
SHOULD: The package builds in mock. OK
SHOULD: The reviewer should test that the package functions as described. A
package should not segfault instead of running, for example. OK
SHOULD: If scriptlets are used, those scriptlets must be sane. This is vague,
and left up to the reviewers judgement to determine sanity. N/A
SHOULD: Usually, subpackages other than devel should require the base package
using a fully versioned dependency. N/A
SHOULD: The placement of pkgconfig(.pc) files depends on their usecase, and
this is usually for development purposes, so should be placed in a -devel pkg.
A reasonable exception is that the main pkg itself is a devel tool not
installed in a user runtime, e.g. gcc or gdb. N/A
SHOULD: If the package has file dependencies outside of /etc, /bin, /sbin,
/usr/bin, or /usr/sbin consider requiring the package which provides the file
instead of the file itself. N/A
SHOULD: your package should contain man pages for binaries/scripts. If it
doesn't, work with upstream to add them where they make sense. N/A
Review summary: The only NEEDSWORK items are two SHOULD items, to request that
upstream include the GPLv3 license text in a file in the source distribution,
and to include translated description and summary sections if available.
--
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
14 years, 2 months