Bug#686447: [RFC] First release of spl-dkms and zfs-linux packages for Debian
Hi! An update here. I was a bit busy later. Today I was talking with Aron on IRC and we agreed that we will push your repository on Alioth in order to keep the full history. In fact is already there: http://anonscm.debian.org/gitweb/?p=pkg-zfsonlinux/zfs.git http://anonscm.debian.org/gitweb/?p=pkg-zfsonlinux/spl.git And we will start from this codebase. I will be rebasing some of the changes I did on a separate branch (and splitting them in small commits) so we could discuss later each one of this changes. See below for the inline replies to your last mail: On 16/12/12 09:19, Darik Horn wrote: Strip from spl-dkms all files not related to kernel modules. Why are you removing copyright attributions like the AUTHORS file? This could upset ZoL contributors and cause legal exposure. I thought that debian/copyright file would be enough to give credit to the authors of the software. However you are right. A simple apt-file search AUTHORS give me more than enough reasons to keep this file. Rewrite postinst helper that ensures that /etc/hostid is valid and will remain constant across reboots. The __BYTE_ORDER__ test is interesting. I will likely add it to pkg-spl. However, randomizing the hostid violates the principle of least astonishment because it causes a zpool.cache mismatch that breaks subsequent imports, and it can break license management for non-Debian software. Stabilizing the hostid is safe, but changing the hostid is unsafe for the same reason that randomizing a missing hostname is wrong. I'm only randomizing it when the current host's hostid is 0x, which I understand is an invalid hostid for ZFS and would case it to stop working properly. Isn't this the case? The pristine-tar branch already exists in pkg-spl and pkg-zfs. Using the pristine-tar facility is certainly correct, but not currently practical for doing the frequent releases that ZoL users expect. We should agree on a common way of working. Either we use pristine-tar or not. I'm relative new to use git for Debian packages. So I'm open to follow yours and Aron advice. Fix clean target and use dh_autoreconf This breaks backports for Lucid (and its derivatives) because dh-autoreconf is a non-main package on those systems. Keeping compatibility with all officially supported Ubuntu variants is worthwhile and something that I want to do. Well. I love to have things as clean and small as possible. dh_autoreconf helps with that. But I understand your point. Not big deal. Update debian/watch to track upstream official release tarballs Is the Github redirector fully obsolete? (nb: http://wiki.debian.org/debian/watch/) The pkg-spl and pkg-zfs watch files were added after an earlier private ITP review. github redirector is not longer needed, so why use it? http://wiki.debian.org/debian/watch?action=diffrev2=10rev1=9 Also the url on the debian/watch on your packages is not working. This is what the current master on Alioth (your package) reports: $ uscan --report-status Processing watchfile line for package zfs-linux... Newest version on remote site is 0~master, local version is 0.6.0.97 zfs-linux: remote site does not even have current version This is what the package that I did previously reports: $ uscan --report-status Processing watchfile line for package zfs-linux... Newest version on remote site is 0.5.2, local version is 0.6.0~rc12 zfs-linux: remote site does not even have current version Strip from zfs-dkms all files not related to kernel modules. Clean debian directory for unneeded *.docs (copyright notices should be added to debian/copyright properly) The OPENSOLARIS.LICENSE file should be unmodified and bundled in every ZFS package, even if the CDDL is duplicated in the debian/copyright file. Modifying or omitting Oracle legal notices will attract Oracle lawyers. Saving less than 64 kilobytes of boilerplate per installation is just not worth the risk. Ok. Add zfs-linux metapackage for convenience to install all ZFS Consider naming this debian-zfs to fit the naming convention of other meta packages already in distribution, and to better accommodate the kFreeBSD platform in case the meta package can be shared. Big or important source packages do not typically provide their own meta. Doing this makes it more difficult for large sites to do local overrides and customization. (And it follows that I should rename the ubuntu-zfs source package to something like meta-ubuntu-zfs for better conformance.) I don't see the point of sharing such metapackage with kFreeBSD. The whole point of the metapackage is to pull the right versions of the spl and zfs dkms modules (which are linux specific) plus the right versions of the user space tools that are also linux specific. ensure dependencies are also always updated to the right version. This reintroduces a dkms ordering bug where the zfs build races the spl
Bug#686447: [RFC] First release of spl-dkms and zfs-linux packages for Debian
On Fri, Feb 15, 2013 at 5:18 PM, Carlos Alberto Lopez Perez clo...@igalia.com wrote: I'm only randomizing it when the current host's hostid is 0x, which I understand is an invalid hostid for ZFS and would case it to stop working properly. Isn't this the case? Where I used 0x earlier, it was used as a canary value so that an interrupted installation would fail gracefully. Given that hostid() deterministically generates a value when the /etc/hostid file is missing, this line 60 in the spl-dkms.postinst is still suspect: dd if=/dev/urandom bs=1 count=3 seek=1 of=/etc/hostid 2/dev/null My concern here is that changing the return of hostid() can break third-party software. (eg: FLEXlm.) The pristine-tar branch already exists in pkg-spl and pkg-zfs. Using the pristine-tar facility is certainly correct, but not currently practical for doing the frequent releases that ZoL users expect. We should agree on a common way of working. Either we use pristine-tar or not. Lets use pristine-tar then. This breaks backports for Lucid (and its derivatives) because dh-autoreconf is a non-main package on those systems. Keeping compatibility with all officially supported Ubuntu variants is worthwhile and something that I want to do. Well. I love to have things as clean and small as possible. dh_autoreconf helps with that. But I understand your point. Not big deal. I intend to cease Lucid builds when it goes out of extended desktop support this April, so this issue will soon be mooted. github redirector is not longer needed, so why use it? http://wiki.debian.org/debian/watch?action=diffrev2=10rev1=9 Also the url on the debian/watch on your packages is not working. Okay, it is obsolete. Modifying or omitting Oracle legal notices will attract Oracle lawyers. Saving less than 64 kilobytes of boilerplate per installation is just not worth the risk. Ok. Thanks. This is a relief. This reintroduces a dkms ordering bug where the zfs build races the spl build. Notice how the BUILD_DEPENDS directive is handled by dkms. Is that a bug on dkms? This is more of an enhancement than a bug. Lustre, ZFS, and SPL are all separate projects upstream. No other Linux modules have such build dependencies outside of the packaging subsystem. was reported? Yes. Note that zfsonlinux/dkms has a recent bug fix that has not yet been submitted upstream. I don't agree in this. Shipping a commented file in /etc/sudoers.d will only cause trouble when the package is upgraded and tries to overwrite your local changes. The right place for such file would be /usr/share/doc/$package/examples/ Okay, that is a fair substitute. I added this kind of nagging to some private builds and got negative feedback. YMMV. Consider disabling second-class architectures entirely because Debian publishes updates very slowly between major releases. IMHO enabling second-class architectures (non-x86) is a goal to achieve. It would help to find bugs on the codebase. ZFS depends on assumptions about the Linux vmalloc that are false for 32-bit kernels. It is worth noting that ARM support in ZoL is arguably better than 32-bit x86 support. Debian publishes updates very slowly between major releases? I don't understand what you mean with this. It sounded like there was an effort to get ZoL into Wheezy. Any version of ZoL that gets into a stable Debian release will have a very long lifetime, and it is likely that upstream will improve 32-bit support in the meantime. The warning is only show once. Once you have accepted it, it won't show anymore whenever you upgrade or reinstall. I understand that this could be annoying, but this is exactly for what's intended. Better annoy people when they install the package for the firs time, that let them run this without knowing that it could cause data corruption or instability on their systems on the long term. Okay, this is ultimately an issue of aesthetics, so I will defer. PS: Darik, subscribe yourself to pkg-zfsonlinux-de...@lists.alioth.debian.org if you are not already. I am subscribed. TTYS. -- Darik Horn dajh...@vanadac.com -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/capbcu1mzjfolebmxhk0aukjrddbjj+_gwnvexkuahargbrp...@mail.gmail.com
Bug#686447: [RFC] First release of spl-dkms and zfs-linux packages for Debian
The alioth project page is: https://alioth.debian.org/projects/pkg-zfsonlinux/ Please anyone interested in helping on the actual packaging apply and join the team. Currently I'll give admin privilege to anyone who is DD, and later to other people who need it when the project is on its right track. -- Regards, Aron Xu -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAMr=8w7xWxxMMeBnhS9cxcp7_zMD94rf8Lwv1cFy=0whxhg...@mail.gmail.com
Bug#686447: [RFC] First release of spl-dkms and zfs-linux packages for Debian
Hi! Finally found some time to work on the spl-dkms and zfs-linux packages. I started with debian helpers from Darik Horn and I ended rewriting many things. Hope all looks ok O:-) You have a summary of the most relevant changes on the commit message [1] Keep in mind that the packages are still in beta status. There are things to fix like all the pending lintian warnings, perhaps rewriting debian/copyright (copyright notices can be added together when they share one or more authors, there is not need for an entry for each one) Also I will wait until upstream releases 0.6.0. I don't want to release a -rc version. Also 0.6.0 would be the version where the ZPL layer will be considered stabilized. I founded that there is not possible to add two people as maintainers. debuild will complain about malformed maintainer address. So I guess we need to set-up a project on Alioth to handle the team maintenance. I'm not a DD, so I would be very grateful if some of you that are DDs (Aron?) could set-up the Alioth project to collaborative maintain this package and add us to it (my login-name on Alioth is clopez-guest). I removed from the control files lot of replaces/conflicts that didn't make sense to me. Perhaps for Ubuntu make sense (don't know). I guess Darik can review it and fix when needed so Ubuntu users can have a painless upgrade from the Darik's PPA packages to this ones. As you probably know Ubuntu steals the packages from Debian/sid for normal versions and from Debian/testing for LTS versions. So I guess this packages would end on Ubuntu's official repositories in a year or so. One question that floats over my mind is related to the name of the packages libzfs-dev libzfs1 and zfsutils. On Debian/kFreeBSD there are packages with the same name. Is allowed to have different source packages building binary packages with the same name when they are different architectures? If is not allowed then I guess we will have to rename the packages. The repositories with the packages are here: https://github.com/clopez/zfs-linux https://github.com/clopez/spl-dkms Just in case someone want to test it, I have uploaded all packages built for AMD64 as also the source packages to here: http://ftp.neutrino.es/zfs-linux/ To test it, at least the packages zfs-dkms and zfsutils should be installed (with all the required dependencies). I will be on holidays next week. So looking forward to see your replies when I come back. Keep in mind that the packages are still a work-in-progress. Patches/pull-requests/suggestions are welcome :) Best regards! - [1] https://github.com/clopez/spl-dkms/commit/a88b5bf72fe8f11f7dbd0ebe17ba7b46e00a4e6f https://github.com/clopez/zfs-linux/commit/8f3e1ef9a2dfbff9594e5d823e0d18121efba688 signature.asc Description: OpenPGP digital signature
