Bug 201077
Summary: | gfs-kmod | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Chris Feist <cfeist> |
Component: | Package Review | Assignee: | Jeremy Katz <katzj> |
Status: | CLOSED NOTABUG | QA Contact: | Fedora Package Reviews List <fedora-package-review> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | rawhide | ||
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2007-04-19 19:28:34 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | |||
Bug Blocks: | 163779, 208687 |
Description
Chris Feist
2006-08-02 17:33:44 UTC
Note that I had to slightly modify kmodtool to get it to build properly. I also found that I had to run 'make prepare' in the kernel subdirectories as well. I don't know how to get around this (other than making sure it's done during the kernel-devel packages install). rpmlint is not silent. I got following errors on SRPM W: gfs-kmod summary-not-capitalized gfs kernel modules Summary doesn't begin with a capital letter. ==> Summary information must start with capital letter E: gfs-kmod no-changelogname-tag There is no %changelog tag in your spec file. To insert it, just insert a '%changelog' in your spec file and rebuild it. ==>Add chnagelog to SPEC file W: gfs-kmod strange-permission kmodtool 0755 A file that you listed to include in your package has strange permissions. Usually, a file should have 0644 permissions. ==> Change permissions of kmodtool to 0644 and then build package E: gfs-kmod invalid-spec-name gfs-kernel.spec Your spec filename must end with '.spec'. If it's not the case, rename your file and rebuild your package. ==> You have not followed kernel module packaging guidelines. Go thru' http://fedoraproject.org/wiki/Packaging/KernelModules. Kernel module package and SPEC name must start with %{kernel_module_name}-kmod E: gfs-kmod configure-without-libdir-spec A configure script is run without specifying the libdir. configure options must be augmented with something like --libdir=%{_libdir}. ==> Add libdir to configure script Also you need to specify here why this kernel module is not in main kernel source tree yet and when will be it added to main kernel source tree? Also there is no gfs-kmod-common package you added to bugzilla. This is kenrel module package then how are you using configure script thats giving rpmlint error for not adding libdir?? When i mockbuild this package for fc6 i got + pushd _kmod_build_ ~/build/BUILD/gfs-kmod-0.1.0/_kmod_build_ ~/build/BUILD/gfs-kmod-0.1.0 + ./configure --kernel_src=/usr/src/kernels/2.6.17-1.2462.fc6-i686 --incdir=/usr/include Configuring Makefiles for your system... Can't open /usr/src/kernels/2.6.17-1.2462.fc6-i686/include/linux/utsrelease.h at ./configure line 107. error: Bad exit status from /var/tmp/rpm-tmp.65056 (%build) You need to change utsrelease.h to uts.h, then configure succeeds But i got then compilation error /usr/src/redhat/SOURCES/gfs-kernel-0.1.0/src/gfs/acl.c: In function âgfs_check_aclâ: /usr/src/redhat/SOURCES/gfs-kernel-0.1.0/src/gfs/acl.c:177: error: âstruct inodeâ has no member named âi_privateâ i did not find any i_private member of gfs_inode struct in incore.h (In reply to comment #1) > Note that I had to slightly modify kmodtool to get it to build properly. Why? kmodtool works fine for a lot of other packages and is on the way into redhat-rpm-config-8.0.40-1 -- modification per-package shouldn't be needed and not be allowed. Looking closer: -/lib/modules/${verrel}${variant}/extra/${kmod_name}/ +/lib/modules/${verrel}${variant}/kernel/extra/${kmod_name}/ This is wrong. Kernel-Modules have to live below /lib/modules/${verrel}${variant}/extra/ If GFS doesn't isntall them there fix your package. -BuildRequires: kernel${dashvariant}-devel-%{_target_cpu} = ${verrel} +#BuildRequires: kernel${dashvariant}-devel-%{_target_cpu} = ${verrel} +#BuildRequires: kernel${dashvariant}-devel = ${verrel} This seems totally wrong to me. In response to Comment #2 - Summary isn't capitalized because I was using the kernel module package guidlines (http://fedoraproject.org/wiki/Packaging/KernelModules). The line they show is what I'm using: Summary: %{kmod_name} kernel modules - Changelog has been added - kmodtool needs to have that permission because it is script that is run from the .spec file - The .spec file does end in .spec, I'm not sure why this is an error. - According to the kernel module specification, the name of the module should be specified this way: (which it is) Name: %{kmod_name}-kmod - This package will most likely never be in the mainstream kernel as it provides support for GFS1 and we are only attempting to get GFS2 into the kernel. - The userspace utilities are in gfs-utils, I'll get those in the proper format according to the kernel module package guidlines. In response to comment #3 & #4 - I've updated the kmodtool (from comment #5) this should work better now. - Unfortunately utsrelease.h has the data that we need (#define UTS_RELEASE "2.6.17-1.2462.fc6"), uts.h doesn't. In response to comment #5 - I've put kmodtool back to the original, I had made modifications to get it to work with an earlier version of the .spec file, and no longer needed those modifications. New SRPM/spec are here: http://people.redhat.com/cfeist/gfs-kmod-0.1.0-1.2.6.17_1.2505.fc6.src.rpm http://people.redhat.com/cfeist/gfs-kernel.spec (In reply to comment #6) > In response to Comment #2 > - Summary isn't capitalized because I was using the kernel module package > guidlines (http://fedoraproject.org/wiki/Packaging/KernelModules). The line > they show is what I'm using: > > Summary: %{kmod_name} kernel modules > If you will see other SPEC files for kernel modules then you will see its not mandatory to copy same wording written in kernel module packaging guidelines for Summary. > - Changelog has been added > - kmodtool needs to have that permission because it is script that is run from > the .spec file oops i forgot you are very correct. > - The .spec file does end in .spec, I'm not sure why this is an error. Still i think you should change SPEC file name to gfs-kmod.spec. I did that and didnt got any rpmlint error for SPEC file name. > - According to the kernel module specification, the name of the module should be > specified this way: (which it is) > Name: %{kmod_name}-kmod > > - This package will most likely never be in the mainstream kernel as it provides > support for GFS1 and we are only attempting to get GFS2 into the kernel. > - The userspace utilities are in gfs-utils, I'll get those in the proper format > according to the kernel module package guidlines. OK > > In response to comment #3 & #4 > - I've updated the kmodtool (from comment #5) this should work better now. > - Unfortunately utsrelease.h has the data that we need (#define UTS_RELEASE > "2.6.17-1.2462.fc6"), uts.h doesn't. But i found only uts.h. May be i am missing something, can you tell me what am i missing that made my system not to show utsrelease.h under installed kernel sources. > > In response to comment #5 > - I've put kmodtool back to the original, I had made modifications to get it to > work with an earlier version of the .spec file, and no longer needed those > modifications. > > New SRPM/spec are here: > http://people.redhat.com/cfeist/gfs-kmod-0.1.0-1.2.6.17_1.2505.fc6.src.rpm > http://people.redhat.com/cfeist/gfs-kernel.spec > Will check now your new package. I just did mockbuild for this package and found same error utlrelease.h not found also, as previously suggested if you chage Summary information and spec name to gfs-kmod.spec then rpmlint will give only single error that is of kmodtool permissions. Not that it would be a big issue at all, but kmodtool is defined as "bash kmodtool" in the specfile so there seems to be no reason for it to be executable. so kmodtool permissions must be 0666 not 0755 No, there's no need to make it group or world writable. I created SRPM for this package on new fc6 kenrel 2.6.17-1.2647.fc6 and i got rpmlint warnings as W: kmod-gfs summary-not-capitalized gfs kernel module(s) Summary doesn't begin with a capital letter. W: kmod-gfs no-version-in-last-changelog The last changelog entry doesn't contain a version. Please insert the version that is coherent with the version of the package and rebuild it. W: kmod-gfs unstripped-binary-or-object /lib/modules/2.6.17-1.2647.fc6/extra/gfs/gfs.ko W: kmod-gfs no-documentation The package contains no documentation (README, doc, etc). You have to include documentation files. Update package and post new links here. I've fixed the comments so it provides a version number. The documentation is provided in the user level package (which is why there are no docs). Also, the package name follows the kernel package name guidlines (which is why it is not capitalized). New packages here: http://people.redhat.com/cfeist/gfs-kmod.spec http://people.redhat.com/cfeist/gfs-kmod-0.1.0-4.2.6.18_1.2708.fc6.src.rpm I mockbuild this package on FC6 devel. It got built successfully. rpmlint is NOT silent I: kmod-gfs checking W: kmod-gfs summary-not-capitalized gfs kernel module(s) Summary doesn't begin with a capital letter. =>This is well known rpmlint Warning. Forget it. W: kmod-gfs no-version-in-last-changelog The last changelog entry doesn't contain a version. Please insert the version that is coherent with the version of the package and rebuild it. => You miss to add changelong entry W: kmod-gfs unstripped-binary-or-object /lib/modules/2.6.18-1.2699.fc6/extra/gfs/gfs.ko =>This is well known rpmlint Warning. Forget it. W: kmod-gfs no-documentation The package contains no documentation (README, doc, etc). You have to include documentation files. =>Not harmfull. Everything looks OK. Update Chnagelog and give new package locations. If nobody is willing to Sponsor this package I can do a Full Review and APPROVE package provided FESCO is not having any problem to allow this kmod in FE. SRPM is also NOT rpmlint Silent W: gfs-kmod strange-permission kmodtool 0755 A file that you listed to include in your package has strange permissions. Usually, a file should have 0644 permissions. => This is well known rpmlint Warning on kmod packages. Forget it. E: gfs-kmod invalid-spec-name gfs-kernel.spec Your spec filename must end with '.spec'. If it's not the case, rename your file and rebuild your package. => You Need to change SPEC file name from gfs-kernel.spec to gfs-kmod.spec W: gfs-kmod mixed-use-of-spaces-and-tabs (spaces: line 35, tab: line 45) The specfile mixes use of spaces and tabs for indentation, which is a cosmetic annoyance. Use either spaces or tabs for indentation, not both. => USE sed -i -e 's|\t| |g' gfs-kernel.spec The SPEC file should be gfs-kmod.spec, the spaces are also fixed and the changelog entry contains the proper date. New packages are here: http://people.redhat.com/cfeist/gfs-kmod-0.1.0-5.2.6.18_1.2726.fc6.src.rpm http://people.redhat.com/cfeist/gfs-kmod.spec BTW, this kmod was not yet approved by FESCo afaics (see fourth para in the kernel-module package section on http://www.fedoraproject.org/wiki/Packaging/KernelModules ) Now, Packaging and rpmlint output looks ok. Now only major remaining thing is to get Approval from FESCO. This package will not be put in the upstream kernel because it's for legacy GFS support. I'm sending an email to the FESCO list as well. This module was allowed for Extras by FESCo. I took a quick look at the spec-file: "ExclusiveArch: i586 i686 x86_64 ppc" missing, needed for buildsys, please fix The header needs to be adjusted; look at the end of http://www.fedoraproject.org/wiki/Packaging/KernelModules for hints (then you'll also build for the PAE kernel). Site note: Why is the build for xen disabled? Gets the second APPROVED herby (needed for kmod-packages) if you fix the above issues after importing. thl, can i sponsor this package? (In reply to comment #21) > thl, can i sponsor this package? You don't have sponsor status yet, so no. Is there anyone else available to sponsor this package, I'd really like to get this in extras as soon as possible. (In reply to comment #23) > Is there anyone else available to sponsor this package, [...] Packages don't get sponsored -- contributors get sponsored. See http://www.fedoraproject.org/wiki/Extras/HowToGetSponsored for some hints how to get sponsored. The list of sponsors is at: https://admin.fedora.redhat.com/accounts/dump-group.cgi?group=cvsextras&role_type=sponsor&format=html -- maybe someone of that list knows you already and is willing to sponsor you. Package looks sane and I'll sponsor cfeist. Did this ever get built? Is it going to get built? I'll try to track down what the current status is. It looks like for now we'll be putting this package in an external repo for users. If we want to include this in the future we'll re-open this bug. |