Description of problem: The kernelheaders package of FC2, FC3, and, according to user reports, FC4 are all totally outdated, so that the new pam_mount-0.10.0 does not build, because /usr/include/linux/loop.h does not have the struct for 'loop_info64'. Version-Release number of selected component (if applicable): How reproducible: Pull newest pam_mount version and try compiling. It fails. Steps to Reproduce: 1. wget heanet.dl.sf.net/sourceforge/pam-mount/pam_mount-0.10.0.tbz2 2. tar -xvjf pam_mount-0.10.0.tbz2 3. cd pam_mount-0.10.0 && ./configure && make Actual results: /usr/include/linux/loop.h:31:2: error: #error "Wrong dev_t in loop.h" mount.c:77: warning: 'struct loop_info64' declared inside parameter list Expected results: (no warnings) Additional info: Mailing list post http://sourceforge.net/mailarchive/forum.php?thread_id=9052402&forum_id=47022
Recent versions of pam_mount do not compile because of this bug. The pam_mount package is included in Fedora Extras. /usr/include/linux/loop.h does not include a definition of loop_info64. /lib/modules/2.6.14-1.1806_FC5/build/include/linux/loop.h does include loop_info64. So glibc-kernheaders is out of date vs. kernel-devel.
I just added a note at http://www.fedoraproject.org/wiki/Extras/FC5Status pointing to this bug.
Fixing summary. Had it been at all useful in the first place, this bug probably would have been fixed up by FC5; as it is, it missed the boat.
Do I understand correctly, that this bug will not be fixed earlier than in FC6 and therefore pam_mount will not be in extras earlier than in FC6?
No, we can probably fix it in an erratum -- pam_mount could use its own copy of the header in question in the meantime.
Well then, roll a .diff and use %patch in the .spec file.
Could we get this fixed soon (sadms.sf.net has a dependency on the package) ? In the meantime, compile now works with the following 2 hacks : [bbou@janus ~]$ ls -l /usr/include/linux/loop.h /usr/include/asm/posix_types.h lrwxrwxrwx 1 root root 65 avr 2 11:46 /usr/include/asm/posix_types.h -> /usr/src/kernels/2.6.16-1.2080_FC5-i686/include/asm/posix_types.h lrwxrwxrwx 1 root root 60 avr 2 11:39 /usr/include/linux/loop.h -> /usr/src/kernels/2.6.16-1.2080_FC5-i686/include/linux/loop.h the posix_types.h also having to be borrowed from the newer versions of the headers (the older version not defining _kernel_old_dev_t).
I just patched and build pam_mount for Fedora Extras Rawhide. Once this package is signed, please test it. If no one has any complaints, then I will build it for FC5. I have patched pam_mount to contain a local copy of loop.h. I will pull this patch out of the package once this bug is fixed.
Because the Fedora Extras pam_mount package caused this bug to be identified, I wanted to attach the following note (sent to the Fedora Extras mailing list): I have chosen to stop maintaining the pam_mount package in Fedora Extras because: 1. I am no longer the upstream maintainer 2. I no longer use the package myself Therefore, pam_mount is now orphaned. I sincerely hope that an appropriate individual becomes interested in maintaining pam_mount. The module has been very useful to me in the past.
I create i386 and src rpms including the local copy of loop.h. These packages can be downloaded here: http://ingo.exphysik.uni-leipzig.de/~useidel/projekte/pam_mount.htm
Added CC for the new maintainer of the Fedora pam_mount package.
I just verified that this is fixed in Rawhide's kernel-headers-2.6.17-1.2586 (possibly before). However, I can't speak for Fedora Core 4. Can someone check into FC4 and either set this to WONTFIX or explain how this bug will be fixed?
This report targets the FC3 or FC4 products, which have now been EOL'd. Could you please check that it still applies to a current Fedora release, and either update the target product or close it ? Thanks.
Works with FC6. Man this should have been fixed long ago, not by introducing kernel-headers.
see comment #16
Fedora Core 4 is now completely unmaintained. These bugs can't be fixed in that version. If the issue still persists in current Fedora Core, please reopen. Thank you, and sorry about this.