Aron Xu [Fri, 2 Aug 2013 20:32:57 +0000 (04:32 +0800)]
Ensure /etc/zfs/ is present on the system
If /etc/zfs/ isn't present or isn't a directory, zpool.cache
won't be created when importing a pool. Also we need to make
sure when users purges the package zpool.cache is removed as
well.
zpool.cache does not need to be kept on user's system when
the package is purged since information in it is only some
status about the host and mounts. The only direct harm of
not having it is that users need to import the pool by hand
and specify -f parameter.
* Build udebs and optionally modules package(s) - both .deb and .udeb.
+ Find kernel source in $KSRC and kernel objects in $KOBJ.
+ linux-headers-_KVERS_ is a virtual package. Instead, depend on
linux-headers-_KVERS_-common AND linux-headers-_KVERS_-amd64.
* Improve upon initramfs-tools scripts.
+ Try three times to import the pool and only if the last one fails,
drop to a shell.
+ Print out the failed commands.
+ Support booting on crypted root by adding support to initramfs hook and script.
+ Only do crypto check(s) if 'zfs key -l' command is availible.
+ Don't add the list of crypto modules by default.
* Copy the zpool.cache file to the initrd.
* Update depends in zfs-initramfs.
Since the removal of /etc/init/rw, /etc/init/*.sh are treated as
internal APIs so that should not be sourced. The line is kept for
ease of back porting.
Since we are doing initial release, information currently in NEWS is
not that interesting to be treated as something new. However, those
information are useful and should be retained, thus moved to
README.Debian.
Aron Xu [Fri, 28 Jun 2013 18:19:43 +0000 (02:19 +0800)]
Disable trigger activation for now
Trigger activation is needed when initramfs support is properly
landing, but we don't have proper support from boot loader so that
initramfs zfs isn't much usable/reliable on user systems currently.
This Ensure that --with-spl-timeout waits for both SPL spl_config.h
and symvers files
The previous code was only waiting for the symver file. But the postinst
target of the DKMS script for SPL will not only create the symvers file,
but also the header spl_config.h.
If we are waiting in the configure script of ZFS for the SPL symvers file,
then we also need to wait for spl_config.h. Otherwise the configure script
will abort because the spl_config.h is not yet available.
On top of that, the function ZFS_AC_SPL_MODULE_SYMVERS is moved to the end
of the function ZFS_AC_SPL to allow both checks share the with-spl-timeout
parameter.
Add --with-spl-timeout=600 to the configure options when building the module with DKMS
This will make the configure script wait up to 600 seconds for the SPL
config and symver files to be available.
This is needed when upgrading the kernel version, because DKMS will start
the build for SPL and ZFS in parallel. And ZFS to be correctly built needs
the symvers of SPL. So ZFS can't start building until SPL has finished.
The proper fix would be implementing dependencies on DKMS. But in the
meanwhile this will do the trick.
* zdev.conf syntax is not longer supported by upstream.
* We aren't interested in shipping a patch with our _first_ _release_
to support an already deprecated feature by upstream that will only
make the future maintenance of the package harder in Debian.
* This was the last patch. So remove also the series file.
Add debconf helpers: Ask the user before building on a 32 bit kernel
* Detect at install time the kernel the user is running
* If a 64-bit kernel is detected skip any question and just build
the ZFS kernel module.
* If a 32-bit kernel is detected, then the user is warned (via debconf)
about that. And the user is asked to stop the build (the default
is to stop the build). If the user selects to stop the build then
we exit with status 0 on postinst before building the module so
the package gets as installed correctly on the dpkg database but
the module is not built.
* If we can't detect if the kernel is 32 or 64 bit we tell the user that
we couldn't detect that and we tell him that he shouldn't continue
building ZFS on a 32-bit kernel.
We also ask him to stop the build and we proceed like in the previous
case.
* If the user asks by mistake "no" to build the kernel and later he changes
his mind and wants to build it, he just needs to reconfigure the package:
dpkg-reconfigure zfs-dkms
* TODO: Add translations for the debhelper templates.
Call notify-reboot-required after the module was built
* The compilation of the module happens inside the #DEBHELPER# block
(automatically handled by dh_dkms). So call notify-reboot-required
after it was built.
Fix and improve the generation of the stripped kernel source tree
* Commit f3757573 broke the rules used for the generation of the
stripped kernel source tree because of the requirement of the
rpm directory to be present for CONFIG_KERNEL
(which is clearly not required for us).
* Add a new rule to sed Makefile.am and manually set "SUBDIRS" to
"module include" for CONFIG_KERNEL and remove it for the other
configs.
* This has the benefit that now running ./configure --with-config=user
&& make in the DKMS source tree is a nop while before it gave
an error.
* Improve the robustness of the rules by ensuring that they will
abort if something is not as expected.
Remove /etc/zfs/zdev.conf from configuration files and remove zdev.conf examples
* /etc/zfs/zdev.conf should not be a configuration file.
This is by policy:
E.2 Fully-featured maintainer script configuration handling
http://www.debian.org/doc/debian-policy/ap-pkg-conffiles.html
This kind of site-specific configuration files should not be added
to the package files.
You don't want this file to be removed when you purge the package.
* zdev.conf is not longer supported by upstream. We are carring a patch
patches/0001-Revert-Retire-zpool_id-infrastructure.patch that I would
like to remove ASAP.
* Remove also all the examples related to zdev.conf shipped.
Users should use vdev_id.conf instead.
[!] Don't add vdev_id.conf to configuration files.
* Upstream is not longer using github to distribute tarballs
* 0.6.1 tarballs were not added (as the time of writing this) to
https://github.com/zfsonlinux/zfs/downloads
* Update the url to http://zfsonlinux.org/
* uscan --report-status now says:
Newest version on remote site is 0.6.1, local version is 0.6.1
=> Package is up to date
Brian Behlendorf [Tue, 26 Mar 2013 15:40:44 +0000 (08:40 -0700)]
Include init scripts in packages
The distribution specific init scripts where excluded from the
packaging when it was reworked. The intention is to replace
them with systemd equivilants. However, that work has not yet
been done and the init scripts are still useful so they have
been added back in to the packaging.
Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Brian Behlendorf [Mon, 25 Mar 2013 18:28:18 +0000 (11:28 -0700)]
Provide ${kmodname}-devel-kmod for yum-builddep
In order to ensure that yum-builddep pulls in all the build
requirements a generic ${kmodname}-devel-kmod provides line is
added. This allows a version of the development headers to be
included without requiring knowledge of the kernel version.
This is important because unlike rpmbuild which does correctly
expand the source rpm spec file, yum-builddep does not. Without
this generic provides line mock which relies on yum-builddep is
unable to automatically satisfy the dependency.
Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Brian Behlendorf [Fri, 22 Mar 2013 21:46:11 +0000 (14:46 -0700)]
Use 'git describe' for working builds
When building from an arbitrary commit in the git tree it's useful
for the resulting packages to be uniquely identifiable. Therefore,
the build system has been updated to detect if your compiling in
git tree.
If you are building in a git tree, and there are commits after the
last annotated tag. Then the <id>-<hash> component of 'git describe'
will be used to overwrite the 'Release:' field in the META file.
The only tricky part is that to ensure the 'make dist' tarball is
built using the correct release. A dist-hook was added to the top
level make file to rewrite the META file using the correct release.
Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Darik Horn [Thu, 21 Mar 2013 03:52:53 +0000 (22:52 -0500)]
Fix minor typos and update marketing copy.
Correct spelling mistakes in the AUTHORS and DISCLAIMER files, and
update the README.markdown file to credit Illumos and mention that
the ZPL is finished.
The README.markdown file is also the first impression for a handful
of new users that discover ZoL through a web search because it
doubles as the splash page for the Github repository. The build blurbs
are therefore removed because these people should be encouraged to
visit the regular home page before installing the product.
Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Closes #1366
Brian Behlendorf [Wed, 20 Mar 2013 22:15:05 +0000 (15:15 -0700)]
Use requested kernel for dkms builds
The --with-linux and --with-linux-obj options must be specified
as part of the dkms build otherwise the package will be built
against the running kernel.
Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Brian Behlendorf [Wed, 20 Mar 2013 18:01:48 +0000 (11:01 -0700)]
Use BUILD_DEPENDS option for dkms builds
Support was added to dkms so build dependencies can be specified.
This allows us to ensure that the spl package will always be built
before the zfs package. Those patches have not yet been merged
upstream but they are available in the zfsonlinux/dkms repository.
Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Brian Behlendorf [Wed, 20 Mar 2013 18:28:00 +0000 (11:28 -0700)]
Remove zfs-dkms conflict with zfs-kmod
Because the zfs-dkms package also provides zfs-kmod for the
zfs user package yum flags this as a conflict. To avoid the
problem remove the Conflicts tag from zfs-dkms and just rely
on the one in zfs-kmod.
zfs-dkms-0.6.0-rc14.fc18.noarch has installed conflicts
zfs-kmod: zfs-dkms-0.6.0-rc14.fc18.noarch
Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
projects / mirror_zfs-debian.git / log