11:26 p.m.
https://bugzilla.rpmfusion.org/show_bug.cgi?id=1991
Brian Behlendorf <behlendorf1(a)llnl.gov> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |behlendorf1(a)llnl.gov
--- Comment #10 from Brian Behlendorf <behlendorf1(a)llnl.gov> 2013-03-14 00:26:47 CET
---
I'd like to revive this packaging request. The following are refreshed
packages using the latest source from http://zfsonlinux.org.
User space utilities:
SPEC: https://www.dropbox.com/s/fz69p42k0fxdeeu/zfs.spec
SRPM: https://www.dropbox.com/s/4ylhyk66e7ygig2/zfs-0.6.0-rc14.fc18.src.rpm
Kernel modules:
SPEC: https://www.dropbox.com/s/1xxgkahef80g2y4/zfs-kmod.spec
SRPM:
https://www.dropbox.com/s/9pawh7fsp2yk488/zfs-kmod-0.6.0-rc14.fc18.src.rpm
These packages depend on the kmodtool patch in bug #2714. The patch adds
generic support for kmod-<package>-devel packages which allows us to build the
zfs kmod packages cleanly using the kmod-spl-devel packages. We also leverage
it to create kmod-zfs-devel packages which we can use in the future to package
Lustre which depends on the zfs kmod. Since those changes are still under
review the SRPM contains a patched version of the kmodtool script which is
used. The kmodtool script was also extended to take a --prefix argument so it
can be used for fc[16-18].
The output from rpmlint is still a little more chatty than I'd like. However,
many of the errors are related to the package version. I've chosen to ignore
them for now because they will be cleanly addressed when the official 0.6.1
release is tagged. That should be within a few weeks, but before that happens
I wanted to get an initial review started to address any concerns.
$ rpmlint zfs*
zfs.src:5: E: hardcoded-library-path in %{_prefix}/lib/dracut
zfs.src:8: E: hardcoded-library-path in /lib/dracut
* These are done conditionally based on the fedora version. If someone has a
cleaner way to ensure the dracut and udev helpers get installed in the correct
place I'm all ears.
zfs.src: W: invalid-url Source0: zfs-0.6.0.tar.gz
zfs-kmod.src: W: invalid-url Source0: zfs-0.6.0.tar.gzzfs.x86_64: W:
incoherent-version-in-changelog 0.6.0-1 ['0.6.0-rc14.fc18', ...]
* Ignore these for now until a proper spl-0.6.1 release is tagged by upstream.
zfs.x86_64: W: shared-lib-calls-exit /lib64/libuutil.so.1.0.1 exit(a)GLIBC_2.2.5
* This is legit, it's an unfortunate bit of code inherited from the upstream
OpenSolaris sources. This should be addressed in the ZoL implementation but in
practice it never occurs.
zfs.x86_64: W: no-manual-page-for-binary zhack
zfs.x86_64: W: no-manual-page-for-binary fsck.zfs
* Not yet provided by upstream.
zfs-devel.x86_64: W: no-documentation
zfs-test.x86_64: W: no-documentation
* Devel packages don't need documentation that goes in the primary package.
zfs-dracut.x86_64: W: spelling-error %description -l en_US initramfs ->
ministrants
* Spelled correctly.
zfs-dracut.x86_64: W: only-non-binary-in-usr-lib
* This is the correct install location for dracut helpers.
zfs-kmod.src: W: strange-permission kmodtool 0775L
* Expected to be executable, this script can be retired if the suggested
kmodtool extensions described above are merged.
8 packages and 0 specfiles checked; 2 errors, 11 warnings.
$ rpmlint kmod-zfs-*
kmod-zfs.x86_64: W: spelling-error Summary(en_US) Metapackage -> Meta package,
Meta-package, Prepackage
kmod-zfs.x86_64: W: no-documentation
kmod-zfs-3.8.2-206.fc18.x86_64.x86_64: W: summary-not-capitalized C zfs kernel
module(s) for 3.8.2-206.fc18.x86_64
kmod-zfs-3.8.2-206.fc18.x86_64.x86_64: W: no-documentation
* My understanding is that this is expected noise for kmod2 packages.
kmod-zfs-3.8.2-206.fc18.x86_64.x86_64: W: unstripped-binary-or-object
/usr/lib/modules/3.8.2-206.fc18.x86_64/extra/zfs/nvpair/znvpair.ko
kmod-zfs-3.8.2-206.fc18.x86_64.x86_64: W: unstripped-binary-or-object
/usr/lib/modules/3.8.2-206.fc18.x86_64/extra/zfs/avl/zavl.ko
kmod-zfs-3.8.2-206.fc18.x86_64.x86_64: W: unstripped-binary-or-object
/usr/lib/modules/3.8.2-206.fc18.x86_64/extra/zfs/zfs/zfs.ko
kmod-zfs-3.8.2-206.fc18.x86_64.x86_64: W: unstripped-binary-or-object
/usr/lib/modules/3.8.2-206.fc18.x86_64/extra/zfs/zcommon/zcommon.ko
kmod-zfs-3.8.2-206.fc18.x86_64.x86_64: W: unstripped-binary-or-object
/usr/lib/modules/3.8.2-206.fc18.x86_64/extra/zfs/unicode/zunicode.ko
kmod-zfs-3.8.2-206.fc18.x86_64.x86_64: W: unstripped-binary-or-object
/usr/lib/modules/3.8.2-206.fc18.x86_64/extra/zfs/zpios/zpios.ko
kmod-zfs-3.8.2-206.fc18.x86_64.x86_64: W: no-documentation
* The objects have the correct permissions, I'm not entirely sure why they
didn't get stripped.
kmod-zfs-devel.x86_64: W: summary-not-capitalized C zfs kernel module(s) devel
common
kmod-zfs-devel.x86_64: W: no-documentation
kmod-zfs-devel-3.8.2-206.fc18.x86_64.x86_64: W: summary-not-capitalized C zfs
kernel module(s) devel for 3.8.2-206.fc18.x86_64
kmod-zfs-devel-3.8.2-206.fc18.x86_64.x86_64: W: no-documentation
kmod-zfs-devel-3.8.2-206.fc18.x86_64.x86_64: W: devel-file-in-non-devel-package
/usr/src/zfs-0.6.0/3.8.2-206.fc18.x86_64/zfs_config.h
* The new kmod development packages. The common kmod-zfs-devel package
contains any required headers, and the kmod-zfs-devel-<kernel> package contains
per-kernel build objects such as Modules.symvers file.
4 packages and 0 specfiles checked; 0 errors, 15 warnings.
The full package list produced by these two source rpms for the latest 3.8.2
kernel is as follows:
zfs-0.6.0-rc14.fc18.src.rpm
zfs-kmod-0.6.0-rc14.fc18.src.rpm
zfs-0.6.0-rc14.fc18.x86_64.rpm
zfs-debuginfo-0.6.0-rc14.fc18.x86_64.rpm
zfs-devel-0.6.0-rc14.fc18.x86_64.rpm
zfs-dracut-0.6.0-rc14.fc18.x86_64.rpm
zfs-kmod-debuginfo-0.6.0-rc14.fc18.x86_64.rpm
zfs-test-0.6.0-rc14.fc18.x86_64.rpm
kmod-zfs-0.6.0-rc14.fc18.x86_64.rpm
kmod-zfs-3.8.2-206.fc18.x86_64-0.6.0-rc14.fc18.x86_64.rpm
kmod-zfs-devel-0.6.0-rc14.fc18.x86_64.rpm
kmod-zfs-devel-3.8.2-206.fc18.x86_64-0.6.0-rc14.fc18.x86_64.rpm
This is also my first RPM fusion package and I'm looking for a sponsor. Thanks
in advance!
--
Configure bugmail: https://bugzilla.rpmfusion.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
You are the assignee for the bug.