Spec URL: http://www.codon.org.uk/~mjg59/tmp/gobi/gobi_loader.spec SRPM URL: http://www.codon.org.uk/~mjg59/tmp/gobi/gobi_loader-0.6-1.src.rpm Description: gobi_loader is a firmware loader for Qualcomm Gobi USB chipsets. These devices appear in an uninitialized state when power is applied and require firmware to be loaded before they can be used as modems. gobi_loader adds a udev rule that will trigger loading of the firmware and make the modem usable.
I'll start the review if you update the spec and srpm to the latest upstream version.
Updated at http://www.codon.org.uk/~mjg59/tmp/gobi/
Okay. Here we go with a few notes: - Why do you define name, version and release seperately? It's pretty redundant, since you can use exactly those macros you %define to get the values you define in the Name, Version, and Release tags - The BuildRoot tag is wrong. If you're not planning to build for EPEL, remove it. Otherwise refer to http://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies#BuildRoot_tag - What's the "Prefix" doing in there? Thats very Red Hat 7.3-ish ;) - How is the note in %build relevant to the build process? (i.e. what is it refering to?) - The Makfile of gobi_loader could use some tweaking: 1. You pass the $RPM_OPT_FLAGS to the make command, the Makefile however doesn't use them in any way. 2. You are using the %makeinstall macro. This is discouraged by Fedora. While you're at fixing the Makefile, refer to http://fedoraproject.org/wiki/Packaging/Guidelines#MakeInstall for more info on that. rpmlint doesn't show anything suspicious, so that is fine. For the future you might want to look at using rpmdev-newspec to create new specfiles from an up-to-date template and rpmdev-bumpspec for making the changelog entries. Those commands are provided by the rpmdevtools package.
ping?
It work, thanks http://www.codon.org.uk/~mjg59/tmp/gobi/gobi_loader-0.7-1.src.rpm EliteBook 2540p (WK304EA) [sergeil@ua-dudn00000 ~]$ cat /etc/issue Fedora release 14 (Laughlin) Kernel \r on an \m (\l) [sergeil@ua-dudn00000 ~]$ uname -r 2.6.35.6-45.fc14.i686.PAE [sergeil@ua-dudn00000 ~]$ lsusb Bus 002 Device 002: ID 8087:0020 Intel Corp. Integrated Rate Matching Hub Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 001 Device 007: ID 03f0:251d Hewlett-Packard Gobi 2000 Wireless Modem Bus 001 Device 006: ID 04f2:b163 Chicony Electronics Co., Ltd Bus 001 Device 005: ID 138a:0007 DigitalPersona, Inc Fingeprint Reader Bus 001 Device 003: ID 03f0:231d Hewlett-Packard Bus 001 Device 002: ID 8087:0020 Intel Corp. Integrated Rate Matching Hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub PS: How quick rpm will be in standard repository or rpmfusion?
> It work, thanks > http://www.codon.org.uk/~mjg59/tmp/gobi/gobi_loader-0.7-1.src.rpm I tested this package on my system. Works for me. > PS: How quick rpm will be in standard repository or rpmfusion? Have the reviewer's comments been addressed in this new package? If not, you should fix the issues and resubmit a new package. Otherwise, the original reviewer (or any other fedora packager) should approve by toggling the fedora‑review flag to +.
Does anyone know what's going on with this package? It would be really useful to have as part of Fedora. Saves rebuilding etc.
Either Matthew isn't interested in this review or he just doesn't have the time to do the review/maintenance anymore. If you are interested in maintaining this package (provided you are a sponsored Fedora packager) you can open a new review request and mark this one as a duplicate of your new request.
(In reply to comment #8) > Either Matthew isn't interested in this review or he just doesn't have the time > to do the review/maintenance anymore. > > If you are interested in maintaining this package (provided you are a sponsored > Fedora packager) you can open a new review request and mark this one as a > duplicate of your new request. Sure, why not. I have the card in my laptop and the package is pretty much handed on a plate to me. Nothing better than taking credit for some else's hard work ;-)
Feel free - my Gobi machine died, so I'm not in so great a position to do much with it now.
*** This bug has been marked as a duplicate of bug 736163 ***
(In reply to comment #10) > Feel free - my Gobi machine died, so I'm not in so great a position to do much > with it now. As for me, my gobi usb device responds to commands, but I've never been able to get a CONNECT string with any of the firmware variants I tried. Does someone know how to query for things such as SIM presence, signal strength and carrier? Can a gobi device be hardware-locked to a particular telco?
(In reply to comment #12) > As for me, my gobi usb device responds to commands, but I've never been able to > get a CONNECT string with any of the firmware variants I tried. > > Does someone know how to query for things such as SIM presence, signal strength > and carrier? Google: "at command set in gobi". You should get a PDF that probably has that sort of thing. > Can a gobi device be hardware-locked to a particular telco? Product sheet claims that one device works with multiple carriers. See bottom of: http://www.thinkwiki.org/wiki/Qualcomm_Gobi_2000