Debian Bug report logs - #686447
ITP: zfs-linux -- The native Linux kernel port of the ZFS filesystem

[Message part 1 (text/plain, inline)]
Package: wnpp
Owner: Carlos Alberto Lopez Perez <clopez@igalia.com>
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org

* Package name    : zfs-linux
  Version         : 0.6.0
  Upstream Author : Brian Behlendorf <behlendorf1@llnl.gov>
* URL             : http://zfsonlinux.org/
* License         : CDDL
  Programming Lang: C
  Description     : The native Linux kernel port of the ZFS filesystem.

 ZFS is an advanced file system and volume manager which was originally
 developed for Solaris. It provides a number of advanced features like
 snapshots, clones, live integrity checksums, deduplication, compression
 and much more. The port to the Linux kernel includes a functional and
 stable SPA, DMU, ZVOL and ZFS Posix Layer (ZPL).
 .
 This package contains the source code for the native implementation of ZFS
 for the Linux Kernel, which can be used with DKMS, so that local kernel
 modules are automatically built and installed every time the kernel packages
 are upgraded.
 .
 This package also contains the user space utilities needed to manage ZFS.

[signature.asc (application/pgp-signature, attachment)]
On Sat, Sep 01, 2012 at 08:02:21PM +0200, Carlos Alberto Lopez Perez wrote:

>  This package contains the source code for the native implementation of ZFS
>  for the Linux Kernel, which can be used with DKMS, so that local kernel
>  modules are automatically built and installed every time the kernel packages
>  are upgraded.
>  .
>  This package also contains the user space utilities needed to manage ZFS.

Wow, this is actually very nice. I didn't know the implementation of
ZFS has advanced that much. I would really love to see this in Debian
anytime soon.

Do you know how it compares to the version of zfs available for the
FreeBSD kernels feature-wise?

Cheers,

Adrian

[Message part 1 (text/plain, inline)]
Hi,

On 01.09.2012 20:02, Carlos Alberto Lopez Perez wrote:
>  This package contains the source code for the native implementation of ZFS
>  for the Linux Kernel, which can be used with DKMS, so that local kernel
>  modules are automatically built and installed every time the kernel packages
>  are upgraded.

Question remains whether the resulting binary packages are distributable
by Debian. You'd basically need to ship source only binary packages
which are built on the installing platform - including utilities, not
only for the kernel driver.

-- 
with kind regards,
Arno Töll
IRC: daemonkeeper on Freenode/OFTC
GnuPG Key-ID: 0x9D80F36D

[signature.asc (application/pgp-signature, attachment)]
[Message part 1 (text/plain, inline)]
On 01/09/12 20:18, John Paul Adrian Glaubitz wrote:
> On Sat, Sep 01, 2012 at 08:02:21PM +0200, Carlos Alberto Lopez Perez wrote:
> 
>>  This package contains the source code for the native implementation of ZFS
>>  for the Linux Kernel, which can be used with DKMS, so that local kernel
>>  modules are automatically built and installed every time the kernel packages
>>  are upgraded.
>>  .
>>  This package also contains the user space utilities needed to manage ZFS.
> 
> Wow, this is actually very nice. I didn't know the implementation of
> ZFS has advanced that much. I would really love to see this in Debian
> anytime soon.
> 
> Do you know how it compares to the version of zfs available for the
> FreeBSD kernels feature-wise?
> 
> Cheers,
> 
> Adrian
> 
> 

Wikipedia has a nice table comparing the different ports of ZFS [1]
According to it, both the FreeBSD port and this Native Linux port (LLNL)
are based on zpool version 28, for which the relevant changelog is also
detailed on Wikipedia [2].

For the Linux port, the ZFS Posix Layer (ZPL) is available from version
0.6.0-rc1 and is expected to be completely stabilized for version 0.6.0 [3]

Regards!
--------

[1] https://en.wikipedia.org/wiki/ZFS#Comparisons
[2] https://en.wikipedia.org/wiki/ZFS#Release_history
[3] https://github.com/zfsonlinux/zfs/issues/7

[signature.asc (application/pgp-signature, attachment)]
[Message part 1 (text/plain, inline)]
On 01/09/12 20:36, Arno Töll wrote:
> Hi,
> 
> On 01.09.2012 20:02, Carlos Alberto Lopez Perez wrote:
>> This package contains the source code for the native implementation
>> of ZFS for the Linux Kernel, which can be used with DKMS, so that
>> local kernel modules are automatically built and installed every time
>> the kernel packages are upgraded.
> 
> Question remains whether the resulting binary packages are distributable
> by Debian. You'd basically need to ship source only binary packages
> which are built on the installing platform - including utilities, not
> only for the kernel driver.
> 
> 

The user space utilities are not linked against any GPL library so there
isn't any license problem distributing them in binary form.

The only external dependencies for the user-space utilities are:
libselinux1, zlib1g, and of course libc6.

[signature.asc (application/pgp-signature, attachment)]
On 1 September 2012 19:02, Carlos Alberto Lopez Perez <clopez@igalia.com> wrote:
> Package: wnpp
> Owner: Carlos Alberto Lopez Perez <clopez@igalia.com>
> Severity: wishlist
> X-Debbugs-CC: debian-devel@lists.debian.org
>
> * Package name    : zfs-linux
>   Version         : 0.6.0
>   Upstream Author : Brian Behlendorf <behlendorf1@llnl.gov>
> * URL             : http://zfsonlinux.org/
> * License         : CDDL
>   Programming Lang: C
>   Description     : The native Linux kernel port of the ZFS filesystem.
>
>  ZFS is an advanced file system and volume manager which was originally
>  developed for Solaris. It provides a number of advanced features like
>  snapshots, clones, live integrity checksums, deduplication, compression
>  and much more. The port to the Linux kernel includes a functional and
>  stable SPA, DMU, ZVOL and ZFS Posix Layer (ZPL).
>  .
>  This package contains the source code for the native implementation of ZFS
>  for the Linux Kernel, which can be used with DKMS, so that local kernel
>  modules are automatically built and installed every time the kernel packages
>  are upgraded.
>  .
>  This package also contains the user space utilities needed to manage ZFS.
>

If packaged properly, I am sure many people will find this useful.

The missing revisions / functionality are:

29 RAID-Z/mirror hybrid allocator.
30 ZFS encryption.
31 improved 'zfs list' performance.
32 One MB block support
33 Improved share support

I do have (personal?!) concerns about the ZFS future. After the zpool
version 28, no more source code was release by oracle (please correct
me if I am wrong). Are the specs released for the later zpool
versions? As it is now, all implementations are incomplete in
comparison with Oracle's implementation. And if no specs are
available, the open source / linux implementations are going to become
more and more incomplete in the future.

What is the status on trademarks? Can we use the name "zfs"? For
example, drdb trademark is actively being enforced.

While the future of alternative zfs implementations does look gloom, I
do think zfs (-like) implementations would be useful on linux and in
debian.

Regards,

Dmitrijs.

[Message part 1 (text/plain, inline)]
On 01/09/12 21:45, Dmitrijs Ledkovs wrote:
> On 1 September 2012 19:02, Carlos Alberto Lopez Perez <clopez@igalia.com> wrote:
>> Package: wnpp
>> Owner: Carlos Alberto Lopez Perez <clopez@igalia.com>
>> Severity: wishlist
>> X-Debbugs-CC: debian-devel@lists.debian.org
>>
>> * Package name    : zfs-linux
>>   Version         : 0.6.0
>>   Upstream Author : Brian Behlendorf <behlendorf1@llnl.gov>
>> * URL             : http://zfsonlinux.org/
>> * License         : CDDL
>>   Programming Lang: C
>>   Description     : The native Linux kernel port of the ZFS filesystem.
>>
>>  ZFS is an advanced file system and volume manager which was originally
>>  developed for Solaris. It provides a number of advanced features like
>>  snapshots, clones, live integrity checksums, deduplication, compression
>>  and much more. The port to the Linux kernel includes a functional and
>>  stable SPA, DMU, ZVOL and ZFS Posix Layer (ZPL).
>>  .
>>  This package contains the source code for the native implementation of ZFS
>>  for the Linux Kernel, which can be used with DKMS, so that local kernel
>>  modules are automatically built and installed every time the kernel packages
>>  are upgraded.
>>  .
>>  This package also contains the user space utilities needed to manage ZFS.
>>
> 
> If packaged properly, I am sure many people will find this useful.
> 
> The missing revisions / functionality are:
> 
> 29 RAID-Z/mirror hybrid allocator.
> 30 ZFS encryption.
> 31 improved 'zfs list' performance.
> 32 One MB block support
> 33 Improved share support
> 
> I do have (personal?!) concerns about the ZFS future. After the zpool
> version 28, no more source code was release by oracle (please correct
> me if I am wrong). Are the specs released for the later zpool
> versions? As it is now, all implementations are incomplete in
> comparison with Oracle's implementation. And if no specs are
> available, the open source / linux implementations are going to become
> more and more incomplete in the future.

This is true, the latest release of the ZFS source code is the zpool
version 28. After Oracle took over Sun, they turned Solaris into a
closed-source operating system effectively killing OpenSolaris.

However, several open source projects (OpenIndiana and Illumos) forked
OpenSolaris and continued its development in parallel. Also FreeBSD
added official support for ZFS on their Kernel.

So, while is true that possibly we can't expect Oracle supporting
further development for the open-source ZFS, we can (and should) expect
that this development effort continues in the open backed by the several
open source efforts behind this (zfsonlinux, freebsd, illumos,
openindiana, smartos, nexenta ...). There is already a working group
composed by some of the former communities working on further
development of the open source version of ZFS [1]

About the ZFS specifications for the Oracle's zpool greater than 28, I
don't know if they made this documents public (probably they didn't)

Anyway this ZFS working group is developing the open source ZFS version
independently from Oracle, so I guess (not sure about this) that the
last ZFS version compatible between all the ZFS ports and Oracle/Solaris
ZFS will be zfs=5,zpool=28. The ZFS working group has already shared a
proposal for allocating zfs/zpool version numbers that allows the
different parties to add features to ZFS independently without conflicts
between them [2]

For example, Illumos released a few months ago a new version of ZFS
(zpool=5000) which added support for "asynchronous destruction of ZFS
datasets" and "SPA versioning with zfs feature flags" [3], and the
FreeBSD folks are already merging this in their port [4]. Its expected
that the zfsonlinux project would also merge this changes on their port [5].

Also, ZFS in its current state (zfs=5 / zpool=28) is very stable and
more feature-wise than any of the other filesystems available for Linux.
Furthermore none of the features added from [29-33] is a killer feature,
for encryption we already have LUKS/dm-crypt on Linux (you can just
build a zfs volume on top of a LUKS/dm-crypt volume).

> 
> What is the status on trademarks? Can we use the name "zfs"? For
> example, drdb trademark is actively being enforced.
> 

We already have in the archives the following packages using the zfs name:

http://packages.debian.org/search?keywords=zfs&searchon=names&suite=all&section=all

So I don't see any problem there. If Oracle decide to enforce the zfs
trademark we simply can rename the package and problem solved.

Also, as I can see, Oracle not longer holds the ZFS trademark since they
abandoned the application for it [6]

> While the future of alternative zfs implementations does look gloom, I
> do think zfs (-like) implementations would be useful on linux and in
> debian.
> 

I also think that can be useful, ZFS has many nice features that would
boost Linux and Debian possibilities.

Regards!
--------

[1]
https://lwn.net/Articles/444882/
http://lanyrd.com/2012/illumos-user-group-meetup-january/smxwd/
http://blog.delphix.com/csiden/files/2012/01/ZFS_Feature_Flags.pdf
http://forums.freebsd.org/showthread.php?t=27159

[2]
http://mail.opensolaris.org/pipermail/zfs-discuss/2011-May/048514.html

[3]
http://blog.vx.sk/archives/35-New-features-in-open-source-ZFS.html
https://github.com/illumos/illumos-gate/commits/master/usr/src/uts/common/sys/fs/zfs.h

[4]
http://comments.gmane.org/gmane.os.freebsd.devel.file-systems/15125

[5]
https://github.com/zfsonlinux/zfs/issues/778

[6]
https://en.wikipedia.org/wiki/ZFS
http://tdrapi.uspto.gov/ts/cd/casestatus/sn85194050/content.html

[signature.asc (application/pgp-signature, attachment)]
Hello all,

For more than two years, I've been maintaining the Ubuntu PPA for ZoL:

  https://launchpad.net/~zfs-native/+archive/stable
  https://github.com/dajhorn/pkg-spl
  https://github.com/dajhorn/pkg-zfs

I put effort into keeping the packaging compatible with Debian Squeeze
and Debian Wheezy, and I support a significant number of Debian users.

If the Debian project is now willing to add the native ZFS
implementation to regular distribution, then please consider me for
the maintainer role.  I've been looking for a mentor and sponsorship.

-- 
Darik Horn <dajhorn@vanadac.com>

> For more than two years, I've been maintaining the Ubuntu PPA for ZoL:
> 
>   https://launchpad.net/~zfs-native/+archive/stable
>   https://github.com/dajhorn/pkg-spl
>   https://github.com/dajhorn/pkg-zfs
> 
> I put effort into keeping the packaging compatible with Debian Squeeze
> and Debian Wheezy, and I support a significant number of Debian users.
> 
> If the Debian project is now willing to add the native ZFS
> implementation to regular distribution, then please consider me for
> the maintainer role.  I've been looking for a mentor and sponsorship.

Hello all,

Speaking on behalf of the upstream ZoL developers at LLNL.  I'd like
to add that Darik has done an excellent job maintaining the Ubuntu PPA.
If sponsored I'm sure he would be a superb Debian maintainer for ZoL.

Because of his efforts to properly package the project for Ubuntu, we've
been able to attract a significant number of users and developers.  In
my opinion, this has substantially speed up our development schedule and
confidence in the code base.

Personally, I'd love to see the native ZFS implementation included in the
regular Debian distribution.  I know of no legal issues which would prevent
this.  And Carlos has already done nice job addressing the usual concerns
earlier in this thread.

-- 
Thanks,
Brian

[Message part 1 (text/plain, inline)]
On 05.09.2012 00:00, Brian Behlendorf wrote:
>> If the Debian project is now willing to add the native ZFS
>> implementation to regular distribution, then please consider me for
>> the maintainer role.  I've been looking for a mentor and sponsorship.

> Speaking on behalf of the upstream ZoL developers at LLNL.  I'd like
> to add that Darik has done an excellent job maintaining the Ubuntu PPA.
> If sponsored I'm sure he would be a superb Debian maintainer for ZoL.

Just for the archives:

It is neither me nor Dmitrijs to "decide" who shall maintain the ZFS
package in Debian (I am doing so for the kfreebsd port, i.e. the FreeBSD
native zfs-utils, JFTR). This is not how we are used to work.

We are basically implementing a first come, first served principle,
where first served in this case refers to the first person filing the
ITP bug. That's Carlos Alberto Lopez Perez in this case. That said -
without knowing Carlos - I am pretty sure he won't reject help from
Darik. Team maintenance is a good thing and I'm convinced Carlos agrees.
Eventually this is something you both shall agree upon.

The involved steps are documented in [1].

> Personally, I'd love to see the native ZFS implementation included in the
> regular Debian distribution.  I know of no legal issues which would prevent
> this.  And Carlos has already done nice job addressing the usual concerns
> earlier in this thread.

We are in a freeze currently. That shouldn't prevent you from working on
a package, but I'd like to point out it might take some time until it
really ends up in Debian. At very least it won't be in Debian Stable
until Jessie (Wheezy's successor) is released, which is, well, $long_ahead.

[1] http://mentors.debian.net/intro-maintainers
-- 
with kind regards,
Arno Töll
IRC: daemonkeeper on Freenode/OFTC
GnuPG Key-ID: 0x9D80F36D

[signature.asc (application/pgp-signature, attachment)]
[Message part 1 (text/plain, inline)]
On 04/09/12 00:37, Darik Horn wrote:
> Hello all,
> 
> For more than two years, I've been maintaining the Ubuntu PPA for ZoL:
> 
>   https://launchpad.net/~zfs-native/+archive/stable
>   https://github.com/dajhorn/pkg-spl
>   https://github.com/dajhorn/pkg-zfs
> 
> I put effort into keeping the packaging compatible with Debian Squeeze
> and Debian Wheezy, and I support a significant number of Debian users.
> 
> If the Debian project is now willing to add the native ZFS
> implementation to regular distribution, then please consider me for
> the maintainer role.  I've been looking for a mentor and sponsorship.
> 

Hello Darik,

I'm aware of your great work on the Ubuntu PPA and I'm happy to see that
you care also about Debian and not only Ubuntu.

Fist of all let me clarify that there isn't such thing as "The Debian
project willing" ... Debian hasn't any central authority deciding upon
which software is packaged and which isn't.
All the packages available on Debian are pushed either by individuals or
teams. Meanwhile the package you intent to introduce inside Debian meets
certain basic requirements you shouldn't have any problem at all to get
it inside the distribution or to find a sponsor. The Debian project is
always happy to accept new software that adds value to it. Among this
requirements are:

1. The license of the software that you are packaging allows Debian to
re-distribute it.
2. The software has certain quality (For ex: it don't introduce severe
security issues or breaks unrelated packages)
3. The software is useful (Silly example: you shouldn't introduce a
"hello world!" program)
4. The maintainer(s) behind the package are doing a good work packaging
the software and maintaining it.

And I'm sure that ZoL meets all this requirements without problems...
that's why I filled this ITP

Before filling this ITP I researched about previous tries of packaging
ZoL on Debian and I wasn't able to find any previous ITP related to ZoL
at all or even any discussion/thread on the Debian mailing lists about
packaging ZoL....
Did you tried to package or introduce ZoL on Debian previously?

If you want, I will be more than happy to co-maintain the package with
you inside Debian. As Arno said, team maintenance is a great thing.
Nowadays many of the Debian packages are maintained by teams rather than
individuals. This helps to ensure a very high quality of the packages.

So, let me know if you are willing to co-maintain ZoL inside Debian with
me (and with anybody else who wants to help with the effort also) and we
could start by setting up a repository for the team.

Best regards!

[signature.asc (application/pgp-signature, attachment)]
> Did you tried to package or introduce ZoL on Debian previously?

No, not formally.

> So, let me know if you are willing to co-maintain ZoL inside Debian with
> me (and with anybody else who wants to help with the effort also) and we
> could start by setting up a repository for the team.

Yes, this sounds ideal.

I will read the New Maintainers Guide again and contact you directly
for instructions and coordination.

In the meantime, please review the deb packaging that is already in
the zfsonlinux/zfs and dajhorn/pkg-zfs repositories at Github.

-- 
Darik Horn <dajhorn@vanadac.com>

Hi,

It has been one and a half months after these two ITPs get filed, I'm
curious about if there are any progress for us to look into, e.g. a
git repository.

I'm a DD and I'm willing to review them if you'd like me to, even if
zfs's future isn't clear to everyone it's still means a lot for some
users.

--
Regards,
Aron Xu

[Message part 1 (text/plain, inline)]
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 (application/pgp-signature, attachment)]
> I removed from the control files lot of replaces/conflicts that didn't make sense to me.

These dependency changes break upgrades from version 0.5, which is
technically the current stable release.  Upgrades across ABI revisions
in the 0.6 series are also broken.

Additionally, the libavl conflict still matters.  Not understanding
something is not a reason to delete it.

> Perhaps for Ubuntu make sense (don't know).

No, it applies to all distributions in the Debian family.

> 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.

The pkg-zfs packages are named like kFreeBSD, Illumos, and Solaris so
that third party software has basic control compatibility and can be
more easily shared between platforms.

(Further inline quotes are from the two commit messages.)

> 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.

> 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.

> Use pristine-tar and create the package from tarballs released from upstream.

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.

> Don't ignore all files (--extend-diff-ignore='.*').

This is a convenience for me.  It makes continuous integration easier.

> 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.

> 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.

> 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.

> 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.)

> ensure dependencies are also always updated to the right version.

This reintroduces a dkms ordering bug where the zfs build races the
spl build.  Notice how the BUILD_DEPENDS directive is handled by dkms.

> General cleaning of files not needed (dracut/sudoers.d/...)

These things were submitted by new ZoL contributors.  Stripping them
discourages further contribution from these people.

> Add a debconf helper that checks if the running kernel is a 64-bit one.
> If it detects that the kernel is 32-bit or it couldn't detect the kind of kernel
> shows a warning to the user asking for confirmation before continuing.

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.

Double-check that the debconf can handle a non-default
/etc/dkms/framework.conf file.  The "/boot/config-$(uname -r)" test
could be problematic.

> Add /etc/init.d/zfs and remove /etc/init.d/{zfs-mount,zfs-share}.
> There is not need at all for two different initscripts.

This races on systems that have event driven init stacks like upstart
or systemd, and it can break in a regular sysv init stack because
networking can come online a long time after local storage is ready.

What happens if /etc/fstab has a legacy line that causes an automatic
import before /etc/init.d/zfs is called?

What happens if zfs invokes /usr/bin/net or /usr/sbin/exportfs before
the network comes up?

What happens if /tmp, /usr, or /var is on a zfs mount point?

> Integrate all lib* packages into libzfs1. This keep the package cleaner.
> To me seems overkill have one package for each .so file

The libnvpair and libzfs packages are separate in all other ZFS
implementations, and I don't see the benefit in doing something
unusual for Debian.  Note that the current library breakout was
approved by upstream.

> when there is no real benefit (I don't expect any other package other than
> zfsutils to link against this libraries)

Why do you expect that ZFS libraries will not be linked by other
packages?  At least one person has mentioned on the discussion list
that they are working on a web interface, somebody else is working on
gparted and nagios integration, and there are several commercial
efforts doing things on top of ZoL.

> Many other minor cleans/fixes

The total diff is 6,515 lines.  Splitting functional changes into
separate commits would be easier to review.  Right now:

* General compatibility with Ubuntu and Linux Mint is broken.
* Upgrades to existing systems are broken.
* Third party consumers are broken.

-- 
Darik Horn <dajhorn@vanadac.com>

Hi,

On Sun, Dec 16, 2012 at 9:26 AM, Carlos Alberto Lopez Perez
<clopez@igalia.com> wrote:
> 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.
>

Darik said zfsonlinux upstream won't release 0.6.0 but go with 0.6.1
directly, because 0.6.0-rcX is actually numbers larger than 0.6.0.
Releasing to experimental is okay for wider testing, and only upload
to unstable when the versions/patches are acknowledged by upstream is
reasonable.

> 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've set up a pkg-zfsonlinux team on alioth, and you've been added to
the project already. Git hosting is okay now, but please don't create
repository before we've decided how to maintain it. I recommend to use
git-buildpackage, but you may like other ways.

> 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.
>

Those information is better to be preserved for compatibility, it
makes no sense to deliberately make other people's life harder. In the
future we can use experimental to provide upstream snapshots
periodically and Darik's stable PPA can just replicate it for Ubuntu
releases he would like to support.

>
> 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.
>

It is possible when there isn't architecture collision, but we need to
come into an agreement with kBSD people (and maybe ftp-masters) before
actually doing so.

>
> The repositories with the packages are here:
>
> https://github.com/clopez/zfs-linux
> https://github.com/clopez/spl-dkms
>
>

I'll have a look on them later, and I think it's better to host such
repositories on Debian's infrastructure after we've decided how to use
it.

> 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
>

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

ITP feedback is merged into the upstream repositories and, because we
missed the release deadline, native ZoL packages for Debian 7 will be
published at:

* deb http://archive.zfsonlinux.org/debian/ wheezy main contrib

The core ZoL packages are already posted for limited testing, and the
necessary helpers will appear sometime this week.  Afterwards, we
should discuss what should go into the Alioth repository.

[Message part 1 (text/plain, inline)]
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 "0xffffffff",
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=diff&rev2=10&rev1=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 build.  Notice how the BUILD_DEPENDS directive is handled by dkms.
> 
> 

Is that a bug on dkms? was reported?

>> General cleaning of files not needed (dracut/sudoers.d/...)
> 
> These things were submitted by new ZoL contributors.  Stripping them
> discourages further contribution from these people.
> 

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/

About dracut helpers, that should be moved to another package
(zfs-dracut) as there is already one zfs-initramfs.

But, honestly, given the popularity of dracut inside Debian/Ubuntu, I
won't spend time on this. However I don't have problems if you want to
work on it.

http://qa.debian.org/popcon.php?package=dracut

>> Add a debconf helper that checks if the running kernel is a 64-bit one.
>> If it detects that the kernel is 32-bit or it couldn't detect the kind of kernel
>> shows a warning to the user asking for confirmation before continuing.
> 
> 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.

Debian publishes updates very slowly between major releases? I don't
understand what you mean with this.

> Double-check that the debconf can handle a non-default
> /etc/dkms/framework.conf file.  The "/boot/config-$(uname -r)" test
> could be problematic.
> 

That check don't requires dkms for nothing. It basically checks in your
kernel config if you are running a 32 bit kernel.

If it detects your kernel is a 32 bit one, it requires you to explicit
accept the warning message.

If it is unable to find your kernel config then it prints another
warning saying that it couldn't detect if your kernel is 32 or 64 bit,
and that you should only install this on a 64-bit kernel.

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.

> 
>> Add /etc/init.d/zfs and remove /etc/init.d/{zfs-mount,zfs-share}.
>> There is not need at all for two different initscripts.
> 
> This races on systems that have event driven init stacks like upstart
> or systemd, and it can break in a regular sysv init stack because
> networking can come online a long time after local storage is ready.
> 
> What happens if /etc/fstab has a legacy line that causes an automatic
> import before /etc/init.d/zfs is called?
> 
> What happens if zfs invokes /usr/bin/net or /usr/sbin/exportfs before
> the network comes up?
> 
> What happens if /tmp, /usr, or /var is on a zfs mount point?
> 
> 

Ok. Makes sense.

>> Integrate all lib* packages into libzfs1. This keep the package cleaner.
>> To me seems overkill have one package for each .so file
> 
> The libnvpair and libzfs packages are separate in all other ZFS
> implementations, and I don't see the benefit in doing something
> unusual for Debian.  Note that the current library breakout was
> approved by upstream.
> 
> 
>> when there is no real benefit (I don't expect any other package other than
>> zfsutils to link against this libraries)
> 
> Why do you expect that ZFS libraries will not be linked by other
> packages?  At least one person has mentioned on the discussion list
> that they are working on a web interface, somebody else is working on
> gparted and nagios integration, and there are several commercial
> efforts doing things on top of ZoL.
> 
> 

Ok. Makes sense.

>> Many other minor cleans/fixes
> 
> The total diff is 6,515 lines.  Splitting functional changes into
> separate commits would be easier to review.  Right now:
> 
> * General compatibility with Ubuntu and Linux Mint is broken.
> * Upgrades to existing systems are broken.
> * Third party consumers are broken.
> 

Yes.

I will be rebasing some of this work on top of the current master that
is on Alioth on a new branch.

And will be posting a mail with a summary of the changes on the mailing
list pkg-zfsonlinux-devel@lists.alioth.debian.org to discuss them prior
merging it.

I will do it on small iterations to avoid this kind of big mails that
are hard to follow.

PS: Darik, subscribe yourself to
pkg-zfsonlinux-devel@lists.alioth.debian.org if you are not already.

Regards!
--------

[signature.asc (application/pgp-signature, attachment)]
On Fri, Feb 15, 2013 at 5:18 PM, Carlos Alberto Lopez Perez
<clopez@igalia.com> wrote:
> I'm only randomizing it when the current host's hostid is "0xffffffff",
> 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 0xFFFFFFFF 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=diff&rev2=10&rev1=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-devel@lists.alioth.debian.org if you are not already.

I am subscribed.

TTYS.

-- 
Darik Horn <dajhorn@vanadac.com>

Dear fellow developers,

It has been quite some time since native ZFS on Linux (zfsonlinux, or
ZoL) enters release candidate testing phrase, and a team has been
founded recently for the work in Debian (pkg-zfsonlinux). Here we have
several issues to be confirmed and coordinated between kBSD and ZoL,
so that we can work for the desirable direction.

1. Naming of the packages
In kFreeBSD, src:zfsutils produces libnvpair1{,-udeb},
libumem1{,-udeb}, libuutil1{,-udeb}, libzfs1{,-udeb},
libzpool1{,-udeb}, and zfsutils{,-udeb}. I'm curious if we can reuse
the names of these binary packages on linux-any architectures, and
choose a different source package name (zfs-linux, currently)?

2. Partman support
As far as I know, partman-zfs is GPL licensed, and does not need to
link against any CDDL stuff, so I think it would be OK to integrate
ZoL support if there are people do the work?

3. Compatibility (zpool, etc)
In ZoL RC14, zpool version has been bumped to 5000, following the step
of OpenIndiana. I'm curious what's the current zpool version in
kFreeBSD, and what's your plan? It would be great if people can import
existing ZoL partition to a kFreeBSD installation, or reversely.

There is also a question about /etc/hostid handling, do you know how
is it handled in kBSD? Existing packaging work of Fedora ZoL makes
hostid static, but I doubt it's desired.

4. About zfs-fuse on Linux
Debian package maintainer of zfs-fuse has joined the team of ZoL, and
he said we may remove zfs-fuse from the archive when ZoL is available
in unstable, so zfs-fuse won't get in the way of naming and
compatibility then.

5. Licensing
ZoL is an independent Linux kernel module developed by Lawrence
Livermore National Laboratory (LLNL) under a contract between U.S.
Department of Energy and LLNL, and is separated into two parts to
avoid violating CDDL. A Solaris Porting Layer (SPL) kernel module is
developed to provide many of the Solaris kernel APIs, and is licensed
under GPL-2+, while the zfs modules are CDDL, reusing existing
OpenSolaris code and cooperate with BSDs and OpenIndiana.

--
Regards,
Aron Xu

Hi,

There are a few goodies in zfsutils package which are useful to
different ZFS implementations but not (yet?) shared in a common package.
You might find them useful:

debian/local/bash_completion.d/zfsutils (stolen from zfs-fuse)
debian/zfsutils.cron.d (stolen from linux softraid)
debian/zfsutils.cron.daily (ToH snapshot management script I wrote
myself, very useful IMHO ;-))

If you think it's worth it, we could split them off zfsutils into a
separate binary-all package.

-- 
Robert Millan

> 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?

Btw doing this *used to* break stuff. I think it was the BTS, testing
migration scripts, or a combination of the two.

In order to avoid this, I recommend that you rename:

zfsutils   - command-line tools to manage ZFS filesystems

As for the other conflicting packages, there is little point in
providing them as separate libraries, as they have no users other than
those provided in zfsutils. I would suggest you merge them into whatever
becomes of zfsutils:

libnvpair1 - Solaris name-value library for Linux
libuutil1  - Solaris userland utility library for Linux
libzfs-dev - Native ZFS filesystem development files for Linux
libzfs1    - Native ZFS filesystem library for Linux
libzpool1  - Native ZFS pool library for Linux

-- 
Robert Millan

Hi guys,

I got interested to see on current status of the project to bring ZFS to
Debian Linux land.  In a brief search found your post
http://lists.alioth.debian.org/pipermail/pkg-zfsonlinux-devel/2014-February/000179.html
and wondered if there was any reply and either there are any objective
reasons why it is stuck in NEW for a while without any decision (could
may be the binary package name collision described in the ITP
report?)

Thank you in advance for the clarification(s)
-- 
Yaroslav O. Halchenko, Ph.D.
http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org
Senior Research Associate,     Psychological and Brain Sciences Dept.
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834                       Fax: +1 (603) 646-1419
WWW:   http://www.linkedin.com/in/yarik        

I'm basically Ccing half the world in this (only half sorry about that :) and I don't know who half
of you are :), but there have been very little information on what's happening with ZoL in Debian
GNU/Linux.

Aron (and in some part Carlos) seems to have gone a-wall and the list have been VERY quiet. It seems
like it's only Aron and me that is actually Debian GNU/Linux Developers (unless other things have
happened outside the list that I'm not aware of - Carlos was/is a maintainer if I don't
misremembering and Darik is in the wait queue?). And no actually status information/reason from the
FTP maintainers about why it have been stuck in incoming for so long (accepted into incoming Sun, 07
Jul 2013 16:00:06 - that's more than six months ago!). Have it been rejected? Is it held up for some
reason? What can I/we do to help move it along?

I'm now the current Debian GNU/Linux Wheezy package maintainer (and have been for quite some time)
for/in ZoL ("upstream" from Debian GNU/Linux I suppose) and I have contributed to both the packaging
(that is already in the Alioth repos) as well as bits and pieces to ZoL code (such as SMB and iSCSI
support - which will be accepted into post-0.6.3 which is due out "very soon now" we hope) and also
wrote support for ZoL to be used as installation target (debian installer, part-man) etc.

With that - I have a large vested interest in maintaining this and I work on it almost daily, so if
no one else have the time (Aron, Carlos)....

I know that Darik is also very busy working on this, and he already maintain (and have for a very
long time) the Ubuntu packages in ZoL, and much (most, all?) of the current packaging is from his
busy hands.

So I'd prefer to work with him on this (if aron/carlos don't have the time/interest that is - I'm not
proposing to steal the packaging!).

Since there have been next to no progress in the Debian GNU/Linux ZoL projects, I have done all my
packaging stuff in the ZoL repos, so if/when this project is revitalized, I'll push all my work to
the Debian GNU/Linux repos as individual commits.

Hello,

On 28 February 2014 09:30, Turbo Fredriksson <turbo@debian.org> wrote:
> I'm basically Ccing half the world in this (only half sorry about that :) and I don't know who half
> of you are :), but there have been very little information on what's happening with ZoL in Debian
> GNU/Linux.
>
> Aron (and in some part Carlos) seems to have gone a-wall and the list have been VERY quiet. It seems
> like it's only Aron and me that is actually Debian GNU/Linux Developers (unless other things have
> happened outside the list that I'm not aware of - Carlos was/is a maintainer if I don't
> misremembering and Darik is in the wait queue?). And no actually status information/reason from the
> FTP maintainers about why it have been stuck in incoming for so long (accepted into incoming Sun, 07
> Jul 2013 16:00:06 - that's more than six months ago!). Have it been rejected? Is it held up for some
> reason? What can I/we do to help move it along?
>

Apart from talking to ftp-masters, I don't know.

>
> I'm now the current Debian GNU/Linux Wheezy package maintainer (and have been for quite some time)
> for/in ZoL ("upstream" from Debian GNU/Linux I suppose) and I have contributed to both the packaging
> (that is already in the Alioth repos) as well as bits and pieces to ZoL code (such as SMB and iSCSI
> support - which will be accepted into post-0.6.3 which is due out "very soon now" we hope) and also
> wrote support for ZoL to be used as installation target (debian installer, part-man) etc.
>
> With that - I have a large vested interest in maintaining this and I work on it almost daily, so if
> no one else have the time (Aron, Carlos)....
>
> I know that Darik is also very busy working on this, and he already maintain (and have for a very
> long time) the Ubuntu packages in ZoL, and much (most, all?) of the current packaging is from his
> busy hands.
>
> So I'd prefer to work with him on this (if aron/carlos don't have the time/interest that is - I'm not
> proposing to steal the packaging!).
>
>
> Since there have been next to no progress in the Debian GNU/Linux ZoL projects, I have done all my
> packaging stuff in the ZoL repos, so if/when this project is revitalized, I'll push all my work to
> the Debian GNU/Linux repos as individual commits.

Where is the latest/greatest set of packaging repositories and/or
packages to look at?

I'd love to evaluate it on Ubuntu, after informal discussion with
Ubuntu ftp-master, I got an agreement that ZoL is a technology we'd be
willing to include in the Ubuntu Archive.

-- 
Regards,

Dimitri.

> Where is the latest/greatest set of packaging repositories and/or packages to look at?

For Debian GNU/Linux Wheezy, this would be

	https://github.com/zfsonlinux/pkg-zfs/tree/master/debian/wheezy/0.6.3-0.8_g540ce4_wheezy

I'm not sure which tag is the latest for Ubuntu (I'm a little unfamiliar which Ubuntu release that's
latest - Darik is managing that part).

But if I had to guess, it would be:

	https://github.com/zfsonlinux/pkg-zfs/tree/master/ubuntu/saucy/0.6.2-1_saucy

and possibly

	https://github.com/zfsonlinux/pkg-zfs/tree/master/ubuntu/quantal/0.6.2-1_quantal

I'm fairly certain Darik have been doing snapshots for quite some time, and the Ubuntu snapshots
I found would be

	https://github.com/zfsonlinux/pkg-zfs/tree/snapshot/ubuntu/saucy/0.6.2-2_saucy_2.gbp46f6df
	https://github.com/zfsonlinux/pkg-zfs/tree/snapshot/ubuntu/quantal/0.6.1-2_quantal_1.gbpfde0ad

> I'd love to evaluate it on Ubuntu, after informal discussion with
> Ubuntu ftp-master, I got an agreement that ZoL is a technology we'd be
> willing to include in the Ubuntu Archive.

Don't forget to talk to Darik about this first. He's been doing Ubuntu packages for ZoL for years.

On Feb 28, 2014, at 11:34 AM, Turbo Fredriksson wrote:

>> Where is the latest/greatest set of packaging repositories and/or packages to look at?
> 
> For Debian GNU/Linux Wheezy, this would be
> 
> 	https://github.com/zfsonlinux/pkg-zfs/tree/master/debian/wheezy/0.6.3-0.8_g540ce4_wheezy

Make that

	https://github.com/zfsonlinux/pkg-zfs/tree/snapshot/debian/wheezy/0.6.3-0.9_g540ce4_wheezy

On 28/02/2014 10:20, Dimitri John Ledkov wrote:
> Hello,
> 
> On 28 February 2014 09:30, Turbo Fredriksson <turbo@debian.org> wrote:
>> I'm basically Ccing half the world in this (only half sorry about that :) and I don't know who half
>> of you are :), but there have been very little information on what's happening with ZoL in Debian
>> GNU/Linux.
>>
>> Aron (and in some part Carlos) seems to have gone a-wall and the list have been VERY quiet. It seems
>> like it's only Aron and me that is actually Debian GNU/Linux Developers (unless other things have
>> happened outside the list that I'm not aware of - Carlos was/is a maintainer if I don't
>> misremembering and Darik is in the wait queue?). And no actually status information/reason from the
>> FTP maintainers about why it have been stuck in incoming for so long (accepted into incoming Sun, 07
>> Jul 2013 16:00:06 - that's more than six months ago!). Have it been rejected? Is it held up for some
>> reason? What can I/we do to help move it along?

Hi,

The proposed package is poorly integrated with existing ZFS packages (e.g. zfsutils for native
kFreeBSD support).

First and foremost, there's a namespace grab which is likely to result in trouble, as I explained
last November (and got no answer):

	https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=686447#117

There are also a number of implementation-independant add-ons which would be good practice to
coordinate in some way with the other ZFS maintainers. I explained this in November too, and
again got no answer:

	https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=686447#112

And annoyingly, there's also been complaints that ZoL developers broke partman-zfs by committing
porting updates that break existing support on kFreeBSD:

	https://lists.debian.org/debian-bsd/2014/02/msg00037.html

I'm happy to see partman-zfs support more platforms, and I don't mind myself if those platforms
are not yet part of Debian when support is merged. But I would at least find it reasonable that
porting changes include an effort to avoid breaking existing production environments. We do this
all the time when porting to kFreeBSD. I think it should work both ways. That I know of, nobody
has spent the time to fix this particular mess yet :-(

-- 
Robert Millan

[Message part 1 (text/plain, inline)]
On 28/02/14 10:30, Turbo Fredriksson wrote:
> I'm basically Ccing half the world in this (only half sorry about that :) and I don't know who half
> of you are :), but there have been very little information on what's happening with ZoL in Debian
> GNU/Linux.
> 
> Aron (and in some part Carlos) seems to have gone a-wall and the list have been VERY quiet. It seems
> like it's only Aron and me that is actually Debian GNU/Linux Developers (unless other things have
> happened outside the list that I'm not aware of - Carlos was/is a maintainer if I don't
> misremembering and Darik is in the wait queue?). And no actually status information/reason from the
> FTP maintainers about why it have been stuck in incoming for so long (accepted into incoming Sun, 07
> Jul 2013 16:00:06 - that's more than six months ago!). Have it been rejected? Is it held up for some
> reason? What can I/we do to help move it along?
> 
> 
> I'm now the current Debian GNU/Linux Wheezy package maintainer (and have been for quite some time)
> for/in ZoL ("upstream" from Debian GNU/Linux I suppose) and I have contributed to both the packaging
> (that is already in the Alioth repos) as well as bits and pieces to ZoL code (such as SMB and iSCSI
> support - which will be accepted into post-0.6.3 which is due out "very soon now" we hope) and also
> wrote support for ZoL to be used as installation target (debian installer, part-man) etc.
> 
> With that - I have a large vested interest in maintaining this and I work on it almost daily, so if
> no one else have the time (Aron, Carlos)....
> 
> I know that Darik is also very busy working on this, and he already maintain (and have for a very
> long time) the Ubuntu packages in ZoL, and much (most, all?) of the current packaging is from his
> busy hands.
> 
> So I'd prefer to work with him on this (if aron/carlos don't have the time/interest that is - I'm not
> proposing to steal the packaging!).
> 
> 
> Since there have been next to no progress in the Debian GNU/Linux ZoL projects, I have done all my
> packaging stuff in the ZoL repos, so if/when this project is revitalized, I'll push all my work to
> the Debian GNU/Linux repos as individual commits.
> 

Hi,

We are still waiting for ftp-masters. I already poked them yesterday and this was their answer:

Thu Feb 26 #debian-ftp on OFTC
[13:20] <clopez> anyone from the ftp team can quickly and gently tell me about the status of the package zfs-linux on NEW? It has been sitting there for 6 months already
[14:28] <paultag> clopez: no one has had time to properly ensure the CDDL / GPL linking mess is above the table
[14:29] <paultag> k
[14:29] <paultag> whoops
[14:29] <clopez> paultag: there is no CCDL / GPL linking: the package only ships the kernel module in source format, the kernel module binaries are built at install time with dkms
[14:29] <paultag> I understand that's the line
[14:30] <paultag> but the fact is it's transitively linking is something we have to look at
[14:30] <paultag> I know when the website copy says about it
[14:30] <clopez> sorry, what means transitively linking?
[14:31] <paultag> I need to leave for work, just because you link to a shim which links to something doesn't mean it's not all linked together.
[14:32] <clopez> paultag: I understand, but the package don't ships kernel binaries, only source code. So as long as binaries are not distributed (and the package don't distributes them) I think there is no problem
[14:32] <paultag> I understand what the website says
[14:33] <paultag> but you'll not be suprised when we take our time figuring out what the hell is going on with this one.
[14:34] <clopez> yes, I understand you need your time, only wanted to have an update regarding this because I felt it was somehow forgotten
[14:34] <clopez> thanks for the update
[14:34] <paultag> it's not forgotten, we just haven't had a slice of time to commune about it
[14:34] <paultag> feel free to email ftpmaster@ and poke
[14:37] <clopez> Liang Guo did that some weeks ago but he got not reply (AFAIK)

So, I don't know how more we can do other than wait.

Regards!

[signature.asc (application/pgp-signature, attachment)]
On Feb 28, 2014, at 1:29 PM, Robert Millan wrote:

> The proposed package is poorly integrated with existing ZFS packages (e.g. zfsutils for native
> kFreeBSD support).
> 
> First and foremost, there's a namespace grab which is likely to result in trouble, as I explained
> last November (and got no answer)

Why is this a problem?

Also, "eventually" _all_ open source ZFS implementations will be built from the source base.

A couple of months ago, OpenZFS.org was created to merge all (Illumos, BSD*, ZoL etc) current
implementations into one code tree. I don't exactly know the status of OpenZFS, Brian Behlendorf is
active/the driving force in both OpenZFS and ZoL and might know more.

ZoL is currently playing the catch-up game to get it in line with the rest, and I doubt there is some
kind of time schedule but hopefully it won't take to many years :).

So if we rename zfsutils for ZoL now, we'll have to rename it back later. With all the hassle that
will entail (especially since we know going in that we will have to rename it).

> There are also a number of implementation-independant add-ons which would be good practice to
> coordinate in some way with the other ZFS maintainers.

I'll add those then, thanx.

> And annoyingly, there's also been complaints that ZoL developers broke partman-zfs by committing
> porting updates that break existing support on kFreeBSD

!! No "ZoL developer" have "committed porting updates" to partman-zfs !!

_I_ have however, sent in patches to it/them for review, where I have clearly stated that discussion
was needed - and warned about possible breaking it for kBSD and asked for input and comments on
how it worked there so I could write a better patch.

It's very flattering that people thought my stuff was good enough to accept without further review,
but it's also a bit frightening - I'm good, but not THAT good (as we could see :).

On Feb 28, 2014, at 2:00 PM, Carlos Alberto Lopez Perez wrote:

> [14:34] <paultag> it's not forgotten, we just haven't had a slice of time to commune about it
> [14:34] <paultag> feel free to email ftpmaster@ and poke
> [14:37] <clopez> Liang Guo did that some weeks ago but he got not reply (AFAIK)
> 
> So, I don't know how more we can do other than wait.

Six months and counting... Ah, well. There's some issues with the following package any way, so maybe
we should take use the time and get it in good shape.

Is it ok/allowed to upload a new package, even though the initial one is still stuck in incoming?

On Fri, 28 Feb 2014, Turbo Fredriksson wrote:

> Is it ok/allowed to upload a new package, even though the initial one is still stuck in incoming?

yes!

-- 
Yaroslav O. Halchenko, Ph.D.
http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org
Senior Research Associate,     Psychological and Brain Sciences Dept.
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834                       Fax: +1 (603) 646-1419
WWW:   http://www.linkedin.com/in/yarik        

On 02/28/2014 04:13 PM, Turbo Fredriksson wrote:
> Is it ok/allowed to upload a new package, even though the initial one is still stuck in incoming?

I suggest asking the FTP masters to mark the package as REJECT if you
want to change something again. As long the package is still stuck
in NEW (not incoming, this is where the package goes once it's
been ACCEPTED), you can always have it rejected.

It's the cleaner solution in my opinion instead of uselessly bumping
the package revision to fix minor issues before the package isn't
even ACCEPTED.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz@debian.org
`. `'   Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

On Feb 28, 2014, at 5:23 PM, John Paul Adrian Glaubitz wrote:

> I suggest asking the FTP masters to mark the package as REJECT if you
> want to change something again.

Well, regarding the packaging, a lot have happened since this summer. And this is also true with the
code itself.

But doing a REJECT might be pointless/overkill, since it isn't the packaging that's at fault, but the
FTP maintainers inability to verify that there is no licensing issue.
-- 
Try not. Do. Or do not. There is no try!
- Yoda

[Message part 1 (text/plain, inline)]
On Fri, Feb 28, 2014 at 05:25:15PM +0100, Turbo Fredriksson wrote:
> FTP maintainers inability to verify that there is no licensing issue.

Your tone is not appreciated nor helpful.

-- 
 .''`.  Paul Tagliamonte <paultag@debian.org>  |   Proud Debian Developer
: :'  : 4096R / 8F04 9AD8 2C92 066C 7352  D28A 7B58 5B30 807C 2A87
`. `'`  http://people.debian.org/~paultag
 `-     http://people.debian.org/~paultag/conduct-statement.txt

[signature.asc (application/pgp-signature, inline)]
[Message part 1 (text/plain, inline)]
On 28/02/14 17:23, John Paul Adrian Glaubitz wrote:
> On 02/28/2014 04:13 PM, Turbo Fredriksson wrote:
>> Is it ok/allowed to upload a new package, even though the initial one is still stuck in incoming?
> 
> I suggest asking the FTP masters to mark the package as REJECT if you
> want to change something again. As long the package is still stuck
> in NEW (not incoming, this is where the package goes once it's
> been ACCEPTED), you can always have it rejected.
> 
> It's the cleaner solution in my opinion instead of uselessly bumping
> the package revision to fix minor issues before the package isn't
> even ACCEPTED.
> 
> Adrian
> 

I advise against this. The upload is to experimental, is OK if the
package has RC bugs.

Let the ftp-master team accept the package first, and once that is done
we can upload a better version to unstable.

In the meanwhile you can continue working on the package repository as
usual.

However, I will wait for a resolution from ftp-master before resuming my
work on the package, because there is the possibility of ftp-master not
allowing the upload and I don't like to waste my time.

Regards!

[signature.asc (application/pgp-signature, attachment)]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 02/28/2014 05:37 PM, Carlos Alberto Lopez Perez wrote:
> I advise against this. The upload is to experimental, is OK if the 
> package has RC bugs.

Why? If the maintainer has made some changes in the meantime while the
package has been waiting in NEW and the FTP team hadn't yet the
possibility to look at the package, why waste their time to review a
package which is going to be redone anyway?

> Let the ftp-master team accept the package first, and once that is
> done we can upload a better version to unstable.

But if you already start with a cleaner version in NEW, you have the
chance to get a feedback on the current package revision instead
of the old one. Makes much more sense to me.

> In the meanwhile you can continue working on the package repository
> as usual.

I don't see how you couldn't when just asking for the package to be
marked as REJECT. Like I said, I do that often and there is nothing
wrong when the package hasn't even been looked at yet.

I rather feel embarrassed about uploading a b0rked package into NEW.

> However, I will wait for a resolution from ftp-master before
> resuming my work on the package, because there is the possibility
> of ftp-master not allowing the upload and I don't like to waste my
> time.

Just because your package is rejected doesn't mean you can't get it
into unstable at all. Packages are rejected all the time. It just
means the package is not *yet* fit for ACCEPT.

Adrian

- -- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz@debian.org
`. `'   Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Icedove - http://www.enigmail.net/

iQIcBAEBCAAGBQJTEMAZAAoJEHQmOzf1tfkTHYMP/3iYWbT/9r/HdJ/eQLCNFyvv
Xk0tb1fRWUsvDrO2h+9I4IqDMD3UWxLtMvrGDkUrJEv5jXFsuWiMRRMRQTIN5wnS
ImnjMJgrtUIohGmn0UF8yDkNXduc9GWX/DToh/74n6hjXSRja+qxg8gTf/Ts3nxL
Th9AJLwSod6idgyC/keY64TkFLy5GKP73icMbF6SZCfwFyn5kFzPxarU+eDVnDDT
Ynog2VFkIu4oG7YNYkQQDVwljY7wxsxEAl82CZt7D+gAHOVt6qG65iDJ7OuacJ0c
McA5ZOnjIUf1EkX2xTzml8CddaF9pkJoXndqOObdsejdtxrRW97rb0Vo8+B7t7H8
NF8pSjooruRxNv08gF7g0m08++6Kh+qFFQmtHlAIirHhanffajX8r/LfVnMsK1Ts
IfJbSd8BzNPKeeAraQy9axeudkDUMpRFYHq6c1+tM2Bh0maZrATVtwdEm5UBk8yM
YRP+JUQY7n3ZYv13bEu5Ar1k0tpsIm51RLNFVQSowBOikPwABWZS78pr0dJ24sG4
y6whiqUno+93H0Jt9U3kkfVJgskYYZkpgSorZQMWMNCWQnmn9xrzI57iQjk2GTXP
pM5ENvTANpSPE2bdxciNteQI/o7wCP0F8FovBNGXfKa8V2DYPS/mrExynE7nmFfa
fpqhw8S4Bd/OPFyiroGX
=qeZj
-----END PGP SIGNATURE-----

On Fri, 28 Feb 2014, John Paul Adrian Glaubitz wrote:

> On 02/28/2014 05:37 PM, Carlos Alberto Lopez Perez wrote:
> > I advise against this. The upload is to experimental, is OK if the 
> > package has RC bugs.

> Why? If the maintainer has made some changes in the meantime while the
> package has been waiting in NEW and the FTP team hadn't yet the
> possibility to look at the package, why waste their time to review a
> package which is going to be redone anyway?

I am not an ftp-master but if I were one (and as a mentor for quite a
few projects) I would have preferred to have re-uploads because

- ftp masters already looked at some past version
- having old and new versions eases to see what has changed (debdiff)
  instead of starting all over or digging out previous version
- shows active interest of original maintainers

for original uploader benefit is that package doesn't loose its order in
the NEW (IIRC).

overall -- I am not sure what could be a benefit of REJECT+REUPLOAD

-- 
Yaroslav O. Halchenko, Ph.D.
http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org
Senior Research Associate,     Psychological and Brain Sciences Dept.
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834                       Fax: +1 (603) 646-1419
WWW:   http://www.linkedin.com/in/yarik        

[Message part 1 (text/plain, inline)]
On 28/02/14 17:58, John Paul Adrian Glaubitz wrote:
>> > However, I will wait for a resolution from ftp-master before
>> > resuming my work on the package, because there is the possibility
>> > of ftp-master not allowing the upload and I don't like to waste my
>> > time.
> Just because your package is rejected doesn't mean you can't get it
> into unstable at all. Packages are rejected all the time. It just
> means the package is not *yet* fit for ACCEPT.

What I'm afraid of is ftp-masters rejecting the package for license
issues (CDDL-GPL).

If the ftp-masters reject the package on a license issue basis this
would mean that zfs-linux won't get into Debian. So I rather will wait
for this before resuming my work on the current package.

I think the license isn't a problem at all because zfs-dkms only ships
source code (no binary distributed). And the binary utilities
distributed on zfsutils don't depend on any CDDL-incompatible
library/package.

[signature.asc (application/pgp-signature, attachment)]
On 28/02/14 15:13, Turbo Fredriksson wrote:
> It's very flattering that people thought my stuff was good enough to accept without further review,
> but it's also a bit frightening - I'm good, but not THAT good (as we could see :).

ISTR it was committed to master by mistake?  Then reverted, but when
Christian Perrier originally did this he rewrote git history;  Joey Hess
corrected that in the VCS, but Christian's next upload reintroduced it
all from his working copy.  Or something like that.

The actually useful bits for Linux were later reverted by KiBi due to
d-i build issues, but the other changes (including some that are
problematic for kFreeBSD) are still there.

Perhaps I could undo Turbo's changes in master, and we can later
carefully review, clean up and reintroduce changes ZoL really needs?

Regards,
-- 
Steven Chamberlain
steven@pyro.eu.org

[Message part 1 (text/plain, inline)]
Steven Chamberlain <steven@pyro.eu.org> (2014-02-28):
> The actually useful bits for Linux were later reverted by KiBi due to
> d-i build issues, but the other changes (including some that are
> problematic for kFreeBSD) are still there.
> 
> Perhaps I could undo Turbo's changes in master, and we can later
> carefully review, clean up and reintroduce changes ZoL really needs?

That's what I suggested in the last paragraph of <20140203224646.GB5386@mraw.org>:
  https://lists.debian.org/debian-bsd/2014/02/msg00043.html

Mraw,
KiBi.

[signature.asc (application/pgp-signature, inline)]
Hi!

On 02/28/2014 06:23 PM, Yaroslav Halchenko wrote:
> I am not an ftp-master but if I were one (and as a mentor for quite a
> few projects) I would have preferred to have re-uploads because
> 
> - ftp masters already looked at some past version

We are talking about packages in NEW, those haven't usually been
in the archives before. The case you are describing can only occur
if an existing package is stuck in NEW because of new binary components,
for example.

> - having old and new versions eases to see what has changed (debdiff)
>   instead of starting all over or digging out previous version

Not if there isn't any old version in the archives.

> - shows active interest of original maintainers

I don't understand this argument.

Again, what I am saying is that if you upload something into NEW and
you realized you messed something up or the package has been in the
queue for quite some time now without any of the FTP masters having
looked at the package yet and the maintainer has changed the packaging
a lot in the meantime, I think it's the proper approach to ask the
FTP team to mark the package as REJECT and upload a current version.

This way the FTP team doesn't waste their time on reviewing a package
which is going to be replaced very soon anyway. Especially when the
packaging was considerably changed in the mean time.

Who tells you that the maintainers didn't make any mistake in their
new package version that would normally have triggered a REJECT
by the FTP team, but the maintainers get to upload it into the
archives anyway because there is already a version in unstable
that has been accepted?

Honestly, I think packages should automatically be removed from
NEW after a certain grace period. This shouldn't be regarded as
a REJECT for the package in general, but simply that no one has
managed so far to review the package and it "fell out" of the
queue. Helps keeping the packages in NEW "fresh" in my opinion.

> for original uploader benefit is that package doesn't loose its order in
> the NEW (IIRC).

I don't see how this would be of any advantage.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz@debian.org
`. `'   Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

On 28/02/2014 15:13, Turbo Fredriksson wrote:
> On Feb 28, 2014, at 1:29 PM, Robert Millan wrote:
> 
>> The proposed package is poorly integrated with existing ZFS packages (e.g. zfsutils for native
>> kFreeBSD support).
>>
>> First and foremost, there's a namespace grab which is likely to result in trouble, as I explained
>> last November (and got no answer)
> 
> Why is this a problem?

I already explained. Nobody listens... (sigh)

I pointed to the explanation in my previous mail. Please have a look. I urge you to take care of
this now. If you'd rather ignore this, be aware that I won't lift a finger when actual breakage
happens and you realize that you're forced to rename.

> Also, "eventually" _all_ open source ZFS implementations will be built from the source base.

That would be great, but for now it's just wishful thinking.

-- 
Robert Millan

On Mar 1, 2014, at 2:25 PM, Robert Millan wrote:

> I already explained. Nobody listens... (sigh)

All I've seen is that you "think" that it "might" be a problem and that we "might" be better of renaming it...

Please give us/me a direct link to the Debian GNU/Linux policy point that explain that this is not acceptable.
--
Choose a job you love, and you will never have
to work a day in your life.

On 1 March 2014 15:46, Turbo Fredriksson <turbo@bayour.com> wrote:
> On Mar 1, 2014, at 2:25 PM, Robert Millan wrote:
>
>> I already explained. Nobody listens... (sigh)
>
> All I've seen is that you "think" that it "might" be a problem and that we "might" be better of renaming it...
>
>
> Please give us/me a direct link to the Debian GNU/Linux policy point that explain that this is not acceptable.

Hostile binary takeover is not allowed - that is two separate source
packages should not build the same binary package names, even if on
different architectures.

Since these are two different implementations that should be clearly
reflected in the binary package names.

There is no need to rename the command-line utilities themself.

Typically you'd still declare a common name as a virtual package name provider:
Package: zolutils
Provides: zfsutils
Description: zfs on linux utilities

The conflict is there, by virtue of enabling multiarch one can install
"zfsutils" for either a linux or kfreebsd architecutre, based on
higher version number kfreebsd one will win... thus it's in your own
interest to rename zfsutils binary package name.

Similarly you can't share library package names, since that will break
multiarch installations of those, since versions and files do not
match between kfreebsd/linux arches.

The packages that are ok, are "-dbg" "-dkms" and "-initramfs".

Also, if there is zfs-dkms module available, why existing zfsutils
packages just can't enable compilation on "linux-any"?! Which should
also reduce the scope of linux specific packages down to
-dkms/-initramfs, and maybe an arch specific patch-series.

Changes to partman-zfs on linux-any, confuse and surprise me, as that
implies providing a pre-build dmks module for the installer's Linux
kernel which is not redistributable. DId partman-zfs/linux-any relied
on compiling -dkms module? Debian has spent a long time to provide
fully free kernels, introducing a non-redistributable component into
the installer is a no-go.

-- 
Regards,

Dimitri.

On Mar 2, 2014, at 4:52 AM, Dimitri John Ledkov wrote:

> Hostile binary takeover is not allowed - that is two separate source
> packages should not build the same binary package names, even if on
> different architectures.

Ok, sounds reasonable when you say it like that. I'd still appreciate a link to the policy for that.

I think (explanation below) that in this case, it would/could be warranted to keep the names and do
the "hostile binary takeover" as you put it.

> Since these are two different implementations

> why existing zfsutils packages just can't enable compilation on "linux-any"?!

You said it yourself - they are different implementations. Yes, they share a lot (!!) of similar
code, but they are also not compilable on their "opposite" arch. 

That is what OpenZFS.org is for - eventually (hopefully sooner than later), you/we/I will be able to
do just that - one source base for all architectures (Linux, FreeBSD, Illumos etc). But we (they) 
aren't there yet.

As it stands today, there are two "upstream sources" for/in Debian GNU/Linux - one for the Linux
kernel and one for the FreeBSD kernel. These share _a lot_ (I can't give you an exact figure, but if
I had to give a "between thumb and index finger guess", I'd say 90%) of the same code (they both
originated from the last open Solaris release before Oracle closed the source again) and provide the
exact same functionality, in the exact same way with binary programs that behave the exact same way
(same options and parameters etc).

> The conflict is there, by virtue of enabling multiarch one can install
> "zfsutils" for either a linux or kfreebsd architecture

Are you saying that with multiarch, it's possible to install packages for two completely different
kernels - Linux and FreeBSD!?

> Changes to partman-zfs on linux-any, confuse and surprise me, as that
> implies providing a pre-build dmks module for the installer's Linux
> kernel which is not redistributable.

That was not (and I still haven't seen a categorical proof of this!) determined at the time.

Besides, even if this is eventually proved and decided, having the support for ZFS in d-i/partman
for linux would still be a good option. People can have their module loaded manually or manually put it on their own, private CD/DVD or FTP repo etc.

> DId partman-zfs/linux-any relied on compiling -dkms module?

Yes and no.

The module will off course be required to "enable" the functionality at the time of booting the
installation - I wrote it in such a way that if there is no ZoL support, that part of d-i/partman
will be disabled.

Installing on a ZFS filesystem on Linux will just not be available/possible/shown if the ZoL module
isn't available. It doesn't require any linking with any ZoL library etc when creating the
boot/install "stuff", so in that regard, there is no licensing issue by accepting the patches.

The changes [to d-i/partman] was quite minor, so not accepting them just because there is/might be a
licensing issue with distributing a binary module in/with Debian GNU/Linux might be a little
nitpicking.
-- 
I love deadlines. I love the whooshing noise they
make as they go by.
- Douglas Adams

On Mar 2, 2014, at 6:56 AM, Turbo Fredriksson wrote:

> On Mar 2, 2014, at 4:52 AM, Dimitri John Ledkov wrote:
> 
>> Since these are two different implementations
> 
> You said it yourself - they are different implementations.

Actually, this is not quite true either come to think of it.

> they both originated from the last open Solaris release before Oracle closed the source again

They are both the exact same (!) implementation, they're just two different ports from the Solaris
code they originate from. The *BSD versions are probably a little closer to the Solaris
implementation (I guess, because BSD is closer to Solaris than Linux is).

And since Illumos have been working on their ZFS implementation longer than ZoL, that's a reason why
their version is "more" (more function and more developed I guess would be a reasonable conclusion),
which is the reason why ZoL is currently trying to "catch up" with the Illumos version.

But again, that's what OpenZFS if for - merging all the current implementation into one code base.
-- 
Turbo Fredriksson
turbo@bayour.com

On 01/03/2014 15:46, Turbo Fredriksson wrote:
> Please give us/me a direct link to the Debian GNU/Linux policy point that explain that this is not acceptable.

I don't have that. I'm telling you that Debian infrastructure is not ready to handle cross-arch
namespace collisions based on my experience hitting the exact same problem before. There's a reason
we add a "freebsd-" prefix to functionally equivalent packages like:

freebsd-smbfs - mount command for the SMB/CIFS filesystem
freebsd-net-tools - FreeBSD networking tools
freebsd-nfs-common - NFS support files common to client and server
freebsd-nfs-server - FreeBSD server utilities needed for NFS on GNU/kFreeBSD
freebsd-ppp - FreeBSD Point-to-Point Protocol (PPP) userland daemon

Your repeated insistence on occupying the "zfsutils" namespace makes me think you have a self-serving
reason for this. How do you plan to react when actual breakage happens?

On 02/03/2014 05:56, Turbo Fredriksson wrote:
> That is what OpenZFS.org is for - eventually (hopefully sooner than later), you/we/I will be able to
> do just that - one source base for all architectures (Linux, FreeBSD, Illumos etc). But we (they) 
> aren't there yet.
> 
> 
> As it stands today, there are two "upstream sources" for/in Debian GNU/Linux - one for the Linux
> kernel and one for the FreeBSD kernel. These share _a lot_ (I can't give you an exact figure, but if
> I had to give a "between thumb and index finger guess", I'd say 90%) of the same code (they both
> originated from the last open Solaris release before Oracle closed the source again) and provide the
> exact same functionality, in the exact same way with binary programs that behave the exact same way
> (same options and parameters etc).

Unless I missed something, ZoL is not OpenZFS. And neither ZoL nor OpenZFS support the kernel of
FreeBSD at the time of writing.

You make it look like you're adding a portable package, when in fact it is a Linux-specific
package.

The idea that you're adding a portable package is very consistent with your pretension of occupying
the namespace. I think it would serve that agenda to imply that ZoL is OpenZFS and the source you're
adding is portable, but I don't think you even believe what you're implying.

If you truly believe in the "unification path", why don't you try Dimitri's suggestion? I notice
that you ignored it on your reply to him:

On 02/03/2014 03:52, Dimitri John Ledkov wrote:
> Also, if there is zfs-dkms module available, why existing zfsutils
> packages just can't enable compilation on "linux-any"?! Which should
> also reduce the scope of linux specific packages down to
> -dkms/-initramfs, and maybe an arch specific patch-series.

The packages are so similar, right? Maybe he has a point. Why don't you send patches for zfsutils to
enable compilation on linux-any? I'll be happy to work with you.

-- 
Robert Millan

On Mar 2, 2014, at 12:05 PM, Robert Millan wrote:

> There's a reason we add a "freebsd-" prefix to functionally equivalent packages like:
> 
> freebsd-smbfs - mount command for the SMB/CIFS filesystem
> freebsd-net-tools - FreeBSD networking tools
> freebsd-nfs-common - NFS support files common to client and server
> freebsd-nfs-server - FreeBSD server utilities needed for NFS on GNU/kFreeBSD
> freebsd-ppp - FreeBSD Point-to-Point Protocol (PPP) userland daemon

Might I suggest that the reason is that these is _completely_ different implementation, with
absolutly no common code?

> Your repeated insistence on occupying the "zfsutils" namespace makes me think you have a self-serving reason for this.

Of course I have - I have never denied this. But the same can be said for you - you have shown an
extreme "ill will" against us using that name. One could only guess why...

My/our reasoning is that it is based on the same code (even if not the same source package - yet),
gives the same functionality, with the same... etc, etc.

I've said that a few times by now, if you don't want to understand that part, let's wait for the FTP
maintainers ruling.

> How do you plan to react when actual breakage happens?

Rename it.

It's just that easy. IF someone can actually show me that this is actually illegal and can point me
to a policy AND/OR if the FTP maintainers (which have the final say in this - not you, not me, not
any one else!) say that this is not acceptable, then we'll rename it, without any bitching or
whining or expressing opinions that we can't backup with facts.

For now, I have not heard one word about this from them. The only thing I've heard is that there
"might" be a problem with the licensing and that they want to investigate this properly and be absolutly sure - it is their job, the one they where elected and trusted to do.

Basically, their ruling is law. Your opinion is just that - your opinion and bear no weight at this
moment.

Dimitri is the only one that have given something that is slightly more than just a personal opinion:

On Mar 2, 2014, at 4:52 AM, Dimitri John Ledkov wrote:

> Hostile binary takeover is not allowed - that is two separate source
> packages should not build the same binary package names, even if on
> different architectures.

This at least SOUNDS like something that could be a policy. You have not provided ANYTHING that can
be considered anything else than a personal opinion and "dislike/disdain" of the name.

I still want/need something that actually IS a policy. Until then, may I suggest we both table
further discussion about renaming the package until we get the FTP maintainers ruling on the package.
They have been Cc'd on this thread, so they will know that there "might" be a controversy in the
naming.

If they rule the license ok but the name wrong, they won't allow it into the archive as-is anyway, so
there is no danger in waiting and letting them do their job.

> Unless I missed something, ZoL is not OpenZFS.

No.... ? Where did you get/draw that conclusion from?

> And neither ZoL nor OpenZFS support the kernel of FreeBSD at the time of writing.

I can't say yes or no on that, I just don't know. I'm involved in ZoL, not OpenZFS. But it would
actually surprise me somewhat if it didn't. This because they, from what I understand (which might be
wrong) used the Illumos code as starting point. And, again from what I understand, is the code *BSD
is using.

But talking about what OpenZFS _IS_ and what it's _INTENDED_ to be is irrelevant at the moment. My
point have been that _eventually_, there won't BE a "FreeBSD/ZFS' or a "Linux/ZFS" version. There
will ONLY be OpenZFS!

And that is only partly irrelevant. In the sense that the current FreeBSD 'zfsutils' and the Linux
'zfsutils' is _basically_ the same, but still not _exactly_ the same....

> You make it look like you're adding a portable package

No I don't. I haven't even hinted to it..

> when in fact it is a Linux-specific package.

Yes. Have someone made you believe it to be something else?

> I think it would serve that agenda to imply that ZoL is OpenZFS and the source you're adding is
> portable, but I don't think you even believe what you're implying.

This is completely your complete misunderstanding and inability to read and understand what's been
said. You need to go back and read it again.

> If you truly believe in the "unification path"

I do. Whole heartedly - it's the only way forward into the future! Keeping X number of
implementations, sharing a huge part of the exact same code won't be sustainable in the long run (it
have already proved somewhat of a problem - both in ZoL and in Illumos).

> I notice that you ignored it on your reply to him:
> 
> On 02/03/2014 03:52, Dimitri John Ledkov wrote:
>> Also, if there is zfs-dkms module available, why existing zfsutils
>> packages just can't enable compilation on "linux-any"?! Which should
>> also reduce the scope of linux specific packages down to
>> -dkms/-initramfs, and maybe an arch specific patch-series.

I DID answer it:

On Mar 2, 2014, at 6:56 AM, Turbo Fredriksson wrote:

>> why existing zfsutils packages just can't enable compilation on "linux-any"?!
> 
> You said it yourself - they are different implementations. Yes, they share a lot (!!) of similar
> code, but they are also not compilable on their "opposite" arch. 

> Why don't you send patches for zfsutils to enable compilation on linux-any? I'll be happy to work
> with you.

Why would I do that?! That's what OpenZFS is intended for! If you like duplicating work and essentially waste time, feel free. But I'm not going to.

OpenZFS was started for this exact purpose - joining the code so that it could be compiled on
"anything/everything".
--
If something's hard to do, then it's not worth doing.
- Homer Simpson

On 02/03/2014 12:19, Turbo Fredriksson wrote:
> Basically, their ruling is law. Your opinion is just that - your opinion and bear no weight at this
> moment.

Ah, good. Finally you openly admit that you're requesting ftp-master support for your
hostile takeover instead of trying to coordinate with existing maintainers.

I won't waste one more minute of my time trying to talk sense into you.

-- 
Robert Millan

On 02/03/14 12:19, Turbo Fredriksson wrote:
> Might I suggest that the reason is that these is _completely_ different implementation, with
> absolutly no common code?

Right, so conversely, zfs-linux shares a lot of code already with
zfsutils and it makes no sense for them to be packaged separately or
compete over namespace?

> if the FTP maintainers [...] say that this is not acceptable,
> then we'll rename it, without any bitching or
> whining or expressing opinions that we can't backup with facts.

> Basically, their ruling is law. Your opinion is just that - your opinion and bear no weight at this
> moment.

It actually seemed to be an offer for collaboration with you, but I
don't see that working so well now.

Regards,
-- 
Steven Chamberlain
steven@pyro.eu.org

On 2 March 2014 16:05, Steven Chamberlain <steven@pyro.eu.org> wrote:
> On 02/03/14 12:19, Turbo Fredriksson wrote:
>> Might I suggest that the reason is that these is _completely_ different implementation, with
>> absolutly no common code?
>
> Right, so conversely, zfs-linux shares a lot of code already with
> zfsutils and it makes no sense for them to be packaged separately or
> compete over namespace?
>

I think it makes sense for myself to go through the differences and
propose packaging changes for Robert to review, to simply enable
linux-any targets in the existing zfs packages. This thus avoids the
packaging conflict all-together, but does impose compatability (e.g.
such that end-user binaries have compatible commandline interface,
flags, and operations - clearly different zfs api levels / options
will be supports, but the common base set should work the same across
all supported kernels).

If patches are intrusive, then conditionally applying the patches on
linux-any might work (as many other profilic packages do - binutils,
gcc, etc.)

>> if the FTP maintainers [...] say that this is not acceptable,
>> then we'll rename it, without any bitching or
>> whining or expressing opinions that we can't backup with facts.
>
>> Basically, their ruling is law. Your opinion is just that - your opinion and bear no weight at this
>> moment.
>
> It actually seemed to be an offer for collaboration with you, but I
> don't see that working so well now.
>

No ftp-masters decisions are not laws - rejects usually only happen
after contacting the developer, inquiring unclear technical points and
mitigating the problems. Quite often, if it's possible to fix, things
are reuploaded.

it's simply their archive you ask inclusion into and they are free to
include things or not and tell you why =)))

The maintainer of a package, ultimately has the power to veto what
goes into the packages they are maintaining. If you are not sure what
or who a maintainer is, here is reference to the policy you are so
after https://www.debian.org/doc/debian-policy/ch-binary.html#s-maintainer
Current maintainers and uploads of zfsutils are listed at
http://packages.qa.debian.org/z/zfsutils.html

Debian welcomes all contributions by everyone, as long as one
constructively interacts with Debian. (If you want a reference, here
you go https://www.debian.org/intro/diversity )

Since you acknowledge the code differences are small, can you refactor
zfsutils required portions as patch series to existing zfsutils
package (and hence the related libraries, utils and udebs) ? That
would be ultimately easier to maintain, and will go quicker through
NEW queue, as it's only the utils and not the kernel module.

And then kernel dkms module can go through as a separate package.

Not sure if it at all makes sense to ship -dkms module out of the
zfsutils package, as I'm expecting linux dkms module to move at a
faster pace than the utils.

Would that work you?

-- 
Regards,

Dimitri.

[Message part 1 (text/plain, inline)]
On 02/03/14 06:56, Turbo Fredriksson wrote:
> On Mar 2, 2014, at 4:52 AM, Dimitri John Ledkov wrote:
> 
>> > Hostile binary takeover is not allowed - that is two separate source
>> > packages should not build the same binary package names, even if on
>> > different architectures.
> Ok, sounds reasonable when you say it like that. I'd still appreciate a link to the policy for that.

One possible example of theoretical breakage is to run the command
"apt-get source libzfs1", right now it downloads the kfreebsd/zfsutils
sources, but I don't know what will happen when zfs-linux is allowed
into the archives.

Is apt intelligent enough to pick the source corresponding to the binary
package of the host arch?

[signature.asc (application/pgp-signature, attachment)]
[Turbo Fredriksson]
> I've said that a few times by now, if you don't want to understand
> that part, let's wait for the FTP maintainers ruling.

As a bystander with no influence whatsoever in this matter, it seem
obvious to me that the FTP masters ruling is that you all need to
figure out this between yourselves and that the zfs-linux package will
not be passing the NEW "queue" before you all agree on how to handle
zfs in Debian.

So the "wait and see" approach is simply to allow kFreeBSD to keep
going as they are, and Linux to be without zfs support in Debian.
Perhaps not the best option?

Please figure this out.  I would like to have zfs on Linux in
Debian. :)

-- 
Happy hacking
Petter Reinholdtsen

Hi,

So from https://github.com/zfsonlinux/pkg-spl we have:
> Package: libnvpair1
> Package: libnvpair1-dbg
> Package: libuutil1
> Package: libuutil1-dbg
> Package: libzfs1
> Package: libzfs1-dbg
> Package: libzfs-dev
> Package: libzpool1
> Package: libzpool1-dbg
> Package: zfs-dkms
> Package: zfs-initramfs
> Package: zfsutils
> Package: zfsutils-dbg

And in the existing zfsutils package, currently only built for
kfreebsd-any, we have:
> Package: libnvpair1
> Package: libnvpair1-udeb
> Package: libumem1
> Package: libumem1-udeb
> Package: libuutil1
> Package: libuutil1-udeb
> Package: libzfs1
> Package: libzfs1-udeb
> Package: libzpool1
> Package: libzpool1-udeb
> Package: zfsutils
> Package: zfsutils-udeb

With such an overlap implied by that, and knowing it all originated from
a common codebase at some time, I really hope it can be merged back into
a common package built for kfreebsd-any and linux-any.

Regards,
-- 
Steven Chamberlain
steven@pyro.eu.org

On Jun 2, 2014, at 3:37 PM, Steven Chamberlain wrote:

> With such an overlap implied by that, and knowing it all originated from
> a common codebase at some time, I really hope it can be merged back into
> a common package built for kfreebsd-any and linux-any.

That's what Open-ZFS.org is all about. I do not know the current
state of that project, but "they're working on it".

[Message part 1 (text/plain, inline)]
Control: user debian-legal@lists.debian.org
Control: usertags -1 one-copyright-review

Hi,

zfs-linux has been waiting in the NEW queue for more than 11 months, 
which is rather long.

In order to help the ftp-masters processing the NEW queue[1], I have 
reviewed the debian/copyright file of zfs-linux following the process at 
[2].
For this task I obtained the sources from 
https://github.com/zfsonlinux/pkg-spl, branch master/ubuntu/precise, 
which seems to contain the most recent changes.

Attached patch fixes most of the issues I noticed.
The most important problem is, that the man pages (man/man1/splat.1, 
man/man5/spl-module-parameters.5) do not have a proper license, but 
contain "All rights reserved.".
Therefore it seems as if they were not DFSG-free.
I have CCed the copyright holders of these man pages, to inform them 
that they have to license them under a DFSG-free license, or they won't 
be allowed into Debian main.

If these issues are fixed, zfs-linux will hopefully be available in the 
Debian archive soon.

Best regards,
Andreas

1: https://ftp-master.debian.org/new.html
2: https://wiki.debian.org/CopyrightReview

[zfs-linux_copyright.patch (text/x-diff, attachment)]
On Aug 8, 2014, at 1:29 AM, Andreas Cadhalpun wrote:

> For this task I obtained the sources from https://github.com/zfsonlinux/pkg-spl, branch master/ubuntu/precise, which seems to contain the most recent changes.

That is the code for the SPL (Solaris Porting Layer) that ZFS/ZoL depends on.

This have already been accepted (I saw a 0.6.3 update being accepted into the
archive a couple of days ago).

Could you try/look at https://github.com/zfsonlinux/pkg-zfs instead?

I'm going to take a closer look at the patch and see if I can apply it manually,
but as it is now, all but the first hunk fails.

On 08.08.2014 12:05, Turbo Fredriksson wrote:
> On Aug 8, 2014, at 1:29 AM, Andreas Cadhalpun wrote:
>
>> For this task I obtained the sources from https://github.com/zfsonlinux/pkg-spl, branch master/ubuntu/precise, which seems to contain the most recent changes.
>
> That is the code for the SPL (Solaris Porting Layer) that ZFS/ZoL depends on.

Oh, I mixed that up.

> This have already been accepted (I saw a 0.6.3 update being accepted into the
> archive a couple of days ago).

Probably it wasn't noticed, but man/man1/splat.1 still doesn't have a 
license. (The other manpage is not present in the Debian archive.)

> Could you try/look at https://github.com/zfsonlinux/pkg-zfs instead?

Yes. I just had a brief look there and noticed that most files are 
licensed under CDDL-1.0, because a lot of code comes from OpenSolaris.

But the first stanza in debian/copyright is:
Files: *
Copyright: Lawrence Livermore National Security, LLC.
License: CDDL-1.0

This contradicts the COPYRIGHT file, which states:
"The majority of the code in the ZFS on Linux port comes from 
OpenSolaris which has been released under the terms of the CDDL open 
source license.
[...]
Files which do not originate from OpenSolaris are noted in the file 
header and attributed properly."

So if a file doesn't contain a license header, it should be assumed to 
come from OpenSolaris, not Lawrence Livermore National Security.

This problem can be circumvented easily, by not listing every file with 
different copyright as separate stanza, but instead aggregation all 
copyright holders for files licensed under CDDL-1.0 into the first, 
general stanza (which also would make debian/copyright a lot easier to 
review/maintain, e.g. avoids duplicated stanzas etc.).
If you don't object to this idea, I'm going to send you a patch changing 
this (and fixing any other issues I might find).

> I'm going to take a closer look at the patch and see if I can apply it manually,
> but as it is now, all but the first hunk fails.

If it helps, my patch is based on:
commit 3a4902645c227439c1adbc689ae23e8760bacd14
Author: Darik Horn <dajhorn@vanadac.com>
Date:   Thu Jun 12 20:50:09 2014 -0400

    Update changelog for 0.6.3-1~precise release

commit a076ccc517e5c2e052542b4c5595a6029ac3223a

But from a brief look at the package uploaded to Debian I noticed that 
some files are not present in the commit I looked at, while some other 
files are missing in the uploaded package...

(BTW the first hunk, i.e. the change from Disclaimer: to Comment: is 
necessary, because the copyright format reserves Disclaimer: "for 
non-free or contrib packages to state that they are not part of Debian 
and to explain why (see Debian Policy section 12.5).")

Best regards,
Andreas

On Fri, Aug 8, 2014 at 6:05 AM, Turbo Fredriksson <turbo@bayour.com> wrote:
>
> This have already been accepted (I saw a 0.6.3 update being accepted into the
> archive a couple of days ago).

How were the licensing and namespace concerns resolved?  After two
years of waiting, it would be nice to know the decision criteria for
such important management issues.

On Fri, Aug 8, 2014 at 7:58 AM, Andreas Cadhalpun
<andreas.cadhalpun@googlemail.com> wrote:
>
> This problem can be circumvented easily, by not listing every file with
> different copyright as separate stanza, but instead aggregation all
> copyright holders for files licensed under CDDL-1.0 into the first, general
> stanza (which also would make debian/copyright a lot easier to
> review/maintain, e.g. avoids duplicated stanzas etc.).

When I did this code audit, in part to satisfy Debian import
requirements, the debian/copyright file was intentionally broken out
like this to avoid ambiguity and ensure copyright pedigree.

This is important because the downstream Debian sources are often
disjoint or unmergeable from the upstream git repository -- as you
just noticed -- and because there was an upstream conversion from svn
to git that mangled some of the commit history.

> I have CCed the copyright holders of these man pages, to inform them that they have to license them under a DFSG-free license, or they won't be allowed into Debian main.

Why are you making this request?  Surely this is the responsibility of
the package maintainers to do this work and maintain an upstream
rapport.

We haven't seen Aron Xu or Carlos Alberto Lopez Perez at the upstream
issue tracker or support lists in more than a year.  Conversely, Turbo
Fredriksson is active and should therefore be added to the primary
list of people with Debian FTP upload privileges.

[Message part 1 (text/plain, inline)]
Hi Darik,

On 09.08.2014 00:09, Darik Horn wrote:
> On Fri, Aug 8, 2014 at 6:05 AM, Turbo Fredriksson <turbo@bayour.com> wrote:
>>
>> This have already been accepted (I saw a 0.6.3 update being accepted into the
>> archive a couple of days ago).
>
> How were the licensing and namespace concerns resolved?  After two
> years of waiting, it would be nice to know the decision criteria for
> such important management issues.

I think he was talking about SPL [1], not zfs-linux here.

As far as I know nothing has been resolved with respect to zfs-linux, yet.

> On Fri, Aug 8, 2014 at 7:58 AM, Andreas Cadhalpun
> <andreas.cadhalpun@googlemail.com> wrote:
>>
>> This problem can be circumvented easily, by not listing every file with
>> different copyright as separate stanza, but instead aggregation all
>> copyright holders for files licensed under CDDL-1.0 into the first, general
>> stanza (which also would make debian/copyright a lot easier to
>> review/maintain, e.g. avoids duplicated stanzas etc.).
>
> When I did this code audit, in part to satisfy Debian import
> requirements, the debian/copyright file was intentionally broken out
> like this to avoid ambiguity and ensure copyright pedigree.
>
> This is important because the downstream Debian sources are often
> disjoint or unmergeable from the upstream git repository -- as you
> just noticed -- and because there was an upstream conversion from svn
> to git that mangled some of the commit history.

OK, it's fine to have them separated, but in that case shouldn't the 
copyright of the default stanza match what the COPYRIGHT file says, or 
maybe just add Sun Microsystems, Inc. to the default stanza?

>> I have CCed the copyright holders of these man pages, to inform them that they have to license them under a DFSG-free license, or they won't be allowed into Debian main.
>
> Why are you making this request?  Surely this is the responsibility of
> the package maintainers to do this work and maintain an upstream
> rapport.

I'm just trying to help here. Of course, it would have been better if 
the package maintainers had noticed this, but as it seems that a 
potentially not DFSG-free file made it into the Debian archive, it's now 
an issue that affects any Debian user.

As you are the author of the man page in question here, do you agree to 
license the file man/man1/splat.1 under a DFSG-free license, e.g. GPL-2+?

> We haven't seen Aron Xu or Carlos Alberto Lopez Perez at the upstream
> issue tracker or support lists in more than a year.  Conversely, Turbo
> Fredriksson is active and should therefore be added to the primary
> list of people with Debian FTP upload privileges.

I didn't know that. They are currently listed as the only uploaders of 
SPL, but as that package is team-maintained by the Debian ZFS on Linux 
maintainers, which Turbo is part of, I don't see a problem.

I haven't reviewed the debian/copyright of zfs-linux fully yet, but 
attached patch fixes some issues I already noticed:
 * changing Disclaimer: to Comment: as the first one is only meant for
   explanations, why a packages has to be in non-free
 * removing some stanzas for files not present in the repository
 * removing duplicated stanzas
 * converting the Source: field of 'Files: debian/*' to a comment, as
   the Source: field is only allowed in the header
 * adding the missing licenses for some files
 * adding the choice-of-venue of the CDDL to debian/copyright

Best regards,
Andreas

1: https://tracker.debian.org/pkg/spl-linux

[zfs-linux_copyright2.patch (text/x-diff, attachment)]
On Fri, Aug 8, 2014 at 7:21 PM, Andreas Cadhalpun
<andreas.cadhalpun@googlemail.com> wrote:
>
> OK, it's fine to have them separated, but in that case shouldn't the
> copyright of the default stanza match what the COPYRIGHT file says, or maybe
> just add Sun Microsystems, Inc. to the default stanza?

Yes.

> As you are the author of the man page in question here, do you agree to
> license the file man/man1/splat.1 under a DFSG-free license, e.g. GPL-2+?

Yes, of course, according to the mainline project license.

> I haven't reviewed the debian/copyright of zfs-linux fully yet, but attached
> patch fixes some issues I already noticed:

Thanks, syntax changes will happen on your advice.

Hi,

On 09.08.2014 02:33, Darik Horn wrote:
> On Fri, Aug 8, 2014 at 7:21 PM, Andreas Cadhalpun
> <andreas.cadhalpun@googlemail.com> wrote:
>>
>> OK, it's fine to have them separated, but in that case shouldn't the
>> copyright of the default stanza match what the COPYRIGHT file says, or maybe
>> just add Sun Microsystems, Inc. to the default stanza?
>
> Yes.

OK.

>> As you are the author of the man page in question here, do you agree to
>> license the file man/man1/splat.1 under a DFSG-free license, e.g. GPL-2+?
>
> Yes, of course, according to the mainline project license.

I suspected that, but it's a bit unclear when looking at the man page 
itself. Therefore I suggest to either add the standard GPL boilerplate 
to the man page or, if you prefer, just remove the scary "All rights 
reserved.", so that one doesn't have to wonder if the project license 
really applies to this file.

>> I haven't reviewed the debian/copyright of zfs-linux fully yet, but attached
>> patch fixes some issues I already noticed:
>
> Thanks, syntax changes will happen on your advice.

You're welcome.

Best regards,
Andreas

[Message part 1 (text/plain, inline)]
On 26/08/14 23:00, Paul Richards Tagliamonte wrote:
> Hello, ZFS on Linux maintainers,
> 
> At a recent ftpteam meeting we discussed this package, and what to do about it.
> 
> Our consensus was that this package appears to violate the spirit of the GPL at
> minimum, and may cause legal problems. Judges often interpret documents as they're
> intended to read, hacks to comply with the letter but not the intent are not
> looked upon fondly. This may be a hard thing for technical folks to accept, but
> in legal cases one usually isn't dealing with technical people.
> 
> As such, this package has been rejected with the following notes:
> 
>  * Please take care to fix your naming issues. Please talk with the kFreeBSD folks
>    on how to best handle the namespace. The kFreeBSD folks had these names
>    first, it's up to them how they're used.
> 
>  * We recommend that the DPL put a question to our lawyers, providing a full and
>    complete background on the situation. (We are happy to help reviewing it before
>    it gets sent off). We will defer judgement on the legality of distributing ZoL
>    in Debian to them.
> 
> Thanks,
>   Paul, on behalf of the ftpteam
> 

We (the Debian ZoL package maintainers) have been talking about this.

The Debian FTP Team wants us to write a summary of the situation regarding the license 
stuff describing how ZoL avoided violating the combination of GPL and CDDL. Then they 
may forward that to DPL (Lucas) and then to SPI's lawyer. They would be OK to accept 
the package if the lawyer says yes.

We are already writing this summary. If someone wants to help please send me or Aron an
e-mail. Maybe we could share a RFC of the summary here when we think is ready, in order
to double-check our understanding of the license stuff and get more feedback about it.

[signature.asc (application/pgp-signature, attachment)]
[Message part 1 (text/plain, inline)]
On 27/08/14 14:33, Carlos Alberto Lopez Perez wrote:
> Maybe we could share a RFC of the summary here when we think is ready, in order
> to double-check our understanding of the license stuff and get more feedback about it.

[...]

On 27/08/14 16:38, Andreas Dilger wrote:
> Hi Carlos,
> I've been dealing with ZoL and the GPL/CDDL issues for a number
> of years for the Lustre filesystem. IANAL, but know quite a bit about
> these issues so I'd be happy to help out if I can. 

Thanks for the offer to help.

Aron has posted our summary about the situation [1]. If you want to comment on it that would be great.

Regards.

[1] http://mid.gmane.org/20140829014229.GA9572@aron-laptop

[signature.asc (application/pgp-signature, attachment)]
[Message part 1 (text/plain, inline)]
On Aug 29, 2014, at 4:49 AM, Carlos Alberto Lopez Perez
<clopez@igalia.com> wrote:
> On 27/08/14 14:33, Carlos Alberto Lopez Perez wrote:
>> Maybe we could share a RFC of the summary here when we think is ready, in order to double-check our understanding of the license stuff and get more feedback about it.
> 
> On 27/08/14 16:38, Andreas Dilger wrote:
>> Hi Carlos,
>> I've been dealing with ZoL and the GPL/CDDL issues for a number
>> of years for the Lustre filesystem. IANAL, but know quite a bit about
>> these issues so I'd be happy to help out if I can. 
> 
> Thanks for the offer to help.
> 
> Aron has posted our summary about the situation [1]. If you want to comment on it that would be great.

In general I think this is a very well written summary of the issues.

I think it is a disservice to your argument that you equate CDDL with proprietary binary licenses such as those used for NVidia or Broadcom.

I would definitely seek clarification of what part of the "spirit" of the GPL is being violated.

I think the most important point is that CDDL is an OSI-approved _open_source_ license, which eliminates IMHO the biggest objection to proprietary binary modules, since the source for ZFS is available for debugging, modification, and redistribution.

The CDDL is actually a permissive license and even grants patent  indemnification for any patents embodied in the original ZFS code (similar to GPLv3).  It is the GPL that restricts distributing with CDDL code and not the reverse (CDDL 3.6 explicitly allows this).

A little-known fact is that the CDDL even permits releasing the executable under a different license from the CDDL (CDDL 3.5).  For example, it would be conceivable to distribute the module under the GPL, but that raises the question of what does a GPL license on an executable mean?  Would this expose the distributor to e.g. patent license issues because it is no longer covered by the CDDL?

> Regards.
> 
> 
> [1] http://mid.gmane.org/20140829014229.GA9572@aron-laptop

Cheers, Andreas

[signature.asc (application/pgp-signature, attachment)]
On Fri, Aug 29, 2014 at 03:33:15PM -0600, Andreas Dilger wrote:
> On Aug 29, 2014, at 4:49 AM, Carlos Alberto Lopez Perez
> <clopez@igalia.com> wrote:
> > On 27/08/14 14:33, Carlos Alberto Lopez Perez wrote:
> >> Maybe we could share a RFC of the summary here when we think is ready, in order to double-check our understanding of the license stuff and get more feedback about it.
> > 
> > On 27/08/14 16:38, Andreas Dilger wrote:
> >> Hi Carlos,
> >> I've been dealing with ZoL and the GPL/CDDL issues for a number
> >> of years for the Lustre filesystem. IANAL, but know quite a bit about
> >> these issues so I'd be happy to help out if I can. 
> > 
> > Thanks for the offer to help.
> > 
> > Aron has posted our summary about the situation [1]. If you want to comment on it that would be great.
> 
> In general I think this is a very well written summary of the issues.
> 
> I think it is a disservice to your argument that you equate CDDL with proprietary binary licenses such as those used for NVidia or Broadcom.
> 
> 
> I would definitely seek clarification of what part of the "spirit" of the GPL is being violated.
> 
> I think the most important point is that CDDL is an OSI-approved _open_source_ license, which eliminates IMHO the biggest objection to proprietary binary modules, since the source for ZFS is available for debugging, modification, and redistribution.
> 
> The CDDL is actually a permissive license and even grants patent  indemnification for any patents embodied in the original ZFS code (similar to GPLv3).  It is the GPL that restricts distributing with CDDL code and not the reverse (CDDL 3.6 explicitly allows this).

I probably could read the GPL and figure this out, but, in what way does
the GPL restrict distribution of GPL and CDDL code together? And maybe
how it specifically relates to this instance, as the ZFS code is
obviously not a derived work of any GPL project.

I try and ignore licensing issues as much as possible, but I'm curious.

-- 
Cheers, Prakash

> 
> A little-known fact is that the CDDL even permits releasing the executable under a different license from the CDDL (CDDL 3.5).  For example, it would be conceivable to distribute the module under the GPL, but that raises the question of what does a GPL license on an executable mean?  Would this expose the distributor to e.g. patent license issues because it is no longer covered by the CDDL?
> 
> > Regards.
> > 
> > 
> > [1] http://mid.gmane.org/20140829014229.GA9572@aron-laptop
> 
> 
> Cheers, Andreas
> 
> 
> 
> 
> 

[Message part 1 (text/plain, inline)]
On Aug 29, 2014, at 4:48 PM, Prakash Surya <me@prakashsurya.com> wrote:
> On Fri, Aug 29, 2014 at 03:33:15PM -0600, Andreas Dilger wrote:
>> On Aug 29, 2014, at 4:49 AM, Carlos Alberto Lopez Perez
>> <clopez@igalia.com> wrote:
>>> On 27/08/14 14:33, Carlos Alberto Lopez Perez wrote:
>>>> Maybe we could share a RFC of the summary here when we think is ready, in order to double-check our understanding of the license stuff and get more feedback about it.
>>> 
>>> On 27/08/14 16:38, Andreas Dilger wrote:
>>>> Hi Carlos,
>>>> I've been dealing with ZoL and the GPL/CDDL issues for a number
>>>> of years for the Lustre filesystem. IANAL, but know quite a bit about
>>>> these issues so I'd be happy to help out if I can. 
>>> 
>>> Thanks for the offer to help.
>>> 
>>> Aron has posted our summary about the situation [1]. If you want to comment on it that would be great.
>> 
>> In general I think this is a very well written summary of the issues.
>> 
>> I think it is a disservice to your argument that you equate CDDL with proprietary binary licenses such as those used for NVidia or Broadcom.
>> 
>> 
>> I would definitely seek clarification of what part of the "spirit" of the GPL is being violated.
>> 
>> I think the most important point is that CDDL is an OSI-approved _open_source_ license, which eliminates IMHO the biggest objection to proprietary binary modules, since the source for ZFS is available for debugging, modification, and redistribution.
>> 
>> The CDDL is actually a permissive license and even grants patent  indemnification for any patents embodied in the original ZFS code (similar to GPLv3).  It is the GPL that restricts distributing with CDDL code and not the reverse (CDDL 3.6 explicitly allows this).
> 
> I probably could read the GPL and figure this out, but, in what way does
> the GPL restrict distribution of GPL and CDDL code together? And maybe
> how it specifically relates to this instance, as the ZFS code is
> obviously not a derived work of any GPL project.

You are right, and I forgot to make this important point as I was writing
my first email.  It is clear that ZFS is _not_ a derived work of Linux
(originally written for Solaris), and Linus has himself said this in
the past about AFS [1], and the GPL only covers code which is derived:

    "If identifiable sections of that work are not derived from the
     Program, and can be reasonably considered independent and separate
     works in themselves, then this License, and its terms, do not
     apply to those sections when you distribute them as separate works."

and just distributing them together does not change this:

    "In addition, mere aggregation of another work not based on the
     Program with the Program (or with a work based on the Program)
     on a volume of a storage or distribution medium does not bring
     the other work under the scope of this License."

so if the ZoL module is not distributed as part of the kernel (i.e. in
a separate package) it is no more incompatible with the GPL than any
other piece of software that is available via download or on the same
DVD as others.

[1] http://yarchive.net/comp/linux/gpl_modules.html

> I try and ignore licensing issues as much as possible, but I'm curious.
> 
> -- 
> Cheers, Prakash
> 
>> 
>> A little-known fact is that the CDDL even permits releasing the executable under a different license from the CDDL (CDDL 3.5).  For example, it would be conceivable to distribute the module under the GPL, but that raises the question of what does a GPL license on an executable mean?  Would this expose the distributor to e.g. patent license issues because it is no longer covered by the CDDL?
>> 
>>> Regards.
>>> 
>>> 
>>> [1] http://mid.gmane.org/20140829014229.GA9572@aron-laptop
>> 
>> 
>> Cheers, Andreas
>> 
>> 
>> 
>> 
>> 
> 
> 
> To unsubscribe from this group and stop receiving emails from it, send an email to zfs-discuss+unsubscribe@zfsonlinux.org.

Cheers, Andreas

[signature.asc (application/pgp-signature, attachment)]
[Message part 1 (text/plain, inline)]
On 30/08/14 01:03, Andreas Dilger wrote:
> On Aug 29, 2014, at 4:48 PM, Prakash Surya <me@prakashsurya.com> wrote:
>> On Fri, Aug 29, 2014 at 03:33:15PM -0600, Andreas Dilger wrote:
>>> On Aug 29, 2014, at 4:49 AM, Carlos Alberto Lopez Perez
>>> <clopez@igalia.com> wrote:
>>>> On 27/08/14 14:33, Carlos Alberto Lopez Perez wrote:
>>>>> Maybe we could share a RFC of the summary here when we think is ready, in order to double-check our understanding of the license stuff and get more feedback about it.
>>>>
>>>> On 27/08/14 16:38, Andreas Dilger wrote:
>>>>> Hi Carlos,
>>>>> I've been dealing with ZoL and the GPL/CDDL issues for a number
>>>>> of years for the Lustre filesystem. IANAL, but know quite a bit about
>>>>> these issues so I'd be happy to help out if I can. 
>>>>
>>>> Thanks for the offer to help.
>>>>
>>>> Aron has posted our summary about the situation [1]. If you want to comment on it that would be great.
>>>
>>> In general I think this is a very well written summary of the issues.
>>>
>>> I think it is a disservice to your argument that you equate CDDL with proprietary binary licenses such as those used for NVidia or Broadcom.
>>>
>>> I would definitely seek clarification of what part of the "spirit" of the GPL is being violated.
>>>
>>> I think the most important point is that CDDL is an OSI-approved _open_source_ license, which eliminates IMHO the biggest objection to proprietary binary modules, since the source for ZFS is available for debugging, modification, and redistribution.
>>>
>>> The CDDL is actually a permissive license and even grants patent  indemnification for any patents embodied in the original ZFS code (similar to GPLv3).  It is the GPL that restricts distributing with CDDL code and not the reverse (CDDL 3.6 explicitly allows this).
>>
>> I probably could read the GPL and figure this out, but, in what way does
>> the GPL restrict distribution of GPL and CDDL code together? And maybe
>> how it specifically relates to this instance, as the ZFS code is
>> obviously not a derived work of any GPL project.
> 
> You are right, and I forgot to make this important point as I was writing
> my first email.  It is clear that ZFS is _not_ a derived work of Linux
> (originally written for Solaris), and Linus has himself said this in
> the past about AFS [1], and the GPL only covers code which is derived:
> 
>     "If identifiable sections of that work are not derived from the
>      Program, and can be reasonably considered independent and separate
>      works in themselves, then this License, and its terms, do not
>      apply to those sections when you distribute them as separate works."
> 
> and just distributing them together does not change this:
> 
>     "In addition, mere aggregation of another work not based on the
>      Program with the Program (or with a work based on the Program)
>      on a volume of a storage or distribution medium does not bring
>      the other work under the scope of this License."
> 
> so if the ZoL module is not distributed as part of the kernel (i.e. in
> a separate package) it is no more incompatible with the GPL than any
> other piece of software that is available via download or on the same
> DVD as others.
> 
> [1] http://yarchive.net/comp/linux/gpl_modules.html
> 

My understanding is that the part of the GPL that causes concerns is the
one related to derived works.

By comparing the CDDL with the proprietary licenses of the NVIDIA or Broadcom
drivers, I tried to stress the point that this same concern related to derived
works, would apply to any of this proprietary drivers.

And Debian is already distributing this proprietary drivers in their archives.
So it would be a non-sense that ZoL was deemed unsuitable for distribution by
Debian, while at the same time Debian continues to distribute this proprietary
drivers.

You are right that maybe that comparison was not very fortunate. However,
it should be kept in mind that the concerns of FTP Masters are not related
with the CDDL license itself, but with the combination of GPL and CDDL in
the same work.

We hold the view that ZFS is not a derived work of the Linux Kernel, so the
requirements of the GPL License for derived works would not apply to it,
therefore both licenses could be satisfied at the same time when Debian
distributes both the Linux Kernel and the ZFS driver (either in source
code form, or as a binary loadable kernel module).

Regards

[signature.asc (application/pgp-signature, attachment)]
[Message part 1 (text/plain, inline)]
Any movement on this? Wearing an OpenZFS t-shirt to the GSoC mentor summit,
I got a lot of questions about the status of ZoL and licensing issues in
particular, and I referred to the unresolved matter because I took Debian
to be reasonably meticulous in its consideration of such questions. I fear
meticulous and itinerant are not simply at cross purposes at this point in
the manner that genuine complexity often demands. If the offered summary
position on inclusion is found unsatisfactory, surely it should be possible
after 10 weeks to articulate objections and reservations clearly.

Cheers,
Bayard

On 31 August 2014 18:53, Carlos Alberto Lopez Perez <clopez@igalia.com>
wrote:

> On 30/08/14 01:03, Andreas Dilger wrote:
> > On Aug 29, 2014, at 4:48 PM, Prakash Surya <me@prakashsurya.com> wrote:
> >> On Fri, Aug 29, 2014 at 03:33:15PM -0600, Andreas Dilger wrote:
> >>> On Aug 29, 2014, at 4:49 AM, Carlos Alberto Lopez Perez
> >>> <clopez@igalia.com> wrote:
> >>>> On 27/08/14 14:33, Carlos Alberto Lopez Perez wrote:
> >>>>> Maybe we could share a RFC of the summary here when we think is
> ready, in order to double-check our understanding of the license stuff and
> get more feedback about it.
> >>>>
> >>>> On 27/08/14 16:38, Andreas Dilger wrote:
> >>>>> Hi Carlos,
> >>>>> I've been dealing with ZoL and the GPL/CDDL issues for a number
> >>>>> of years for the Lustre filesystem. IANAL, but know quite a bit about
> >>>>> these issues so I'd be happy to help out if I can.
> >>>>
> >>>> Thanks for the offer to help.
> >>>>
> >>>> Aron has posted our summary about the situation [1]. If you want to
> comment on it that would be great.
> >>>
> >>> In general I think this is a very well written summary of the issues.
> >>>
> >>> I think it is a disservice to your argument that you equate CDDL with
> proprietary binary licenses such as those used for NVidia or Broadcom.
> >>>
> >>> I would definitely seek clarification of what part of the "spirit" of
> the GPL is being violated.
> >>>
> >>> I think the most important point is that CDDL is an OSI-approved
> _open_source_ license, which eliminates IMHO the biggest objection to
> proprietary binary modules, since the source for ZFS is available for
> debugging, modification, and redistribution.
> >>>
> >>> The CDDL is actually a permissive license and even grants patent
> indemnification for any patents embodied in the original ZFS code (similar
> to GPLv3).  It is the GPL that restricts distributing with CDDL code and
> not the reverse (CDDL 3.6 explicitly allows this).
> >>
> >> I probably could read the GPL and figure this out, but, in what way does
> >> the GPL restrict distribution of GPL and CDDL code together? And maybe
> >> how it specifically relates to this instance, as the ZFS code is
> >> obviously not a derived work of any GPL project.
> >
> > You are right, and I forgot to make this important point as I was writing
> > my first email.  It is clear that ZFS is _not_ a derived work of Linux
> > (originally written for Solaris), and Linus has himself said this in
> > the past about AFS [1], and the GPL only covers code which is derived:
> >
> >     "If identifiable sections of that work are not derived from the
> >      Program, and can be reasonably considered independent and separate
> >      works in themselves, then this License, and its terms, do not
> >      apply to those sections when you distribute them as separate works."
> >
> > and just distributing them together does not change this:
> >
> >     "In addition, mere aggregation of another work not based on the
> >      Program with the Program (or with a work based on the Program)
> >      on a volume of a storage or distribution medium does not bring
> >      the other work under the scope of this License."
> >
> > so if the ZoL module is not distributed as part of the kernel (i.e. in
> > a separate package) it is no more incompatible with the GPL than any
> > other piece of software that is available via download or on the same
> > DVD as others.
> >
> > [1] http://yarchive.net/comp/linux/gpl_modules.html
> >
>
>
> My understanding is that the part of the GPL that causes concerns is the
> one related to derived works.
>
> By comparing the CDDL with the proprietary licenses of the NVIDIA or
> Broadcom
> drivers, I tried to stress the point that this same concern related to
> derived
> works, would apply to any of this proprietary drivers.
>
> And Debian is already distributing this proprietary drivers in their
> archives.
> So it would be a non-sense that ZoL was deemed unsuitable for distribution
> by
> Debian, while at the same time Debian continues to distribute this
> proprietary
> drivers.
>
> You are right that maybe that comparison was not very fortunate. However,
> it should be kept in mind that the concerns of FTP Masters are not related
> with the CDDL license itself, but with the combination of GPL and CDDL in
> the same work.
>
> We hold the view that ZFS is not a derived work of the Linux Kernel, so the
> requirements of the GPL License for derived works would not apply to it,
> therefore both licenses could be satisfied at the same time when Debian
> distributes both the Linux Kernel and the ZFS driver (either in source
> code form, or as a binary loadable kernel module).
>
> Regards
>
>

[Message part 2 (text/html, inline)]
[Message part 1 (text/plain, inline)]
Hi Lucas,

It has been already 3 months since you requested ftp-masters to ACK the
mail quoted below.

I have already requested several times on the IRC (#debian-ftp) to the
ftp-team to ACK your mail, and they ignored my requests.

I think that 3 months of waiting for an ACK is more than enough.

At this point, I kindly ask you to pass our mail regarding the license
issues about ZoL to the SFLC lawyer in the next couple of days if you
don't get an ACK or a reply from ftp-masters about this issue.

Thanks.

On 31/08/14 01:28, Lucas Nussbaum wrote:
> Hi,
> 
> On 29/08/14 at 09:42 +0800, Aron Xu wrote:
>> Dear DPL and FTP Masters,
>>
>> As agreed at DebConf 14, Debian ZFS on Linux Maintainers have concluded
>> into the following summary for the situation, please see as follows.
> 
> Thanks a lot for this work.
> 
> I think that adding an actual question to our legal counsel would help
> focus their work. If I understand correctly, that question should be:
>     Does this summary accurately represents your understanding of the
>     question?
>     Can Debian distribute a ZoL package using (1) Source code and (2)
>     Binary Linux LKM?
> 
> In any case, I'll wait for comments or ACK from ftpmasters before
> forwarding your mail to SFLC.
> 
> Lucas
> 
> 
> 
> _______________________________________________
> Pkg-zfsonlinux-devel mailing list
> Pkg-zfsonlinux-devel@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-zfsonlinux-devel
> 

[signature.asc (application/pgp-signature, attachment)]
Hi.  What is the current status for getting ZFS on Linux into Debian?
any news since the last message 2014-12-02?

-- 
Happy hacking
Petter Reinholdtsen

[Cutting down FTP team and DPL from CC]

It was agreed that FTP team would review the package as other packages
once it shows up in the NEW queue, and spl-linux was updated to
0.6.4.1 recently.

After the upload, we tried to talk with Debian installer team on how
to maintain an out-of-tree kernel module for the installer but
unfortunately it's not feasible at the moment. Apart from the
discussion, my hands are too filled by other stuff to proceed with
src:zfs-linux without udeb so it's still not in the queue yet.

Cheers,
Aron

On Fri, Jun 12, 2015 at 2:51 PM, Petter Reinholdtsen <pere@hungry.com> wrote:
>
> Hi.  What is the current status for getting ZFS on Linux into Debian?
> any news since the last message 2014-12-02?
>
> --
> Happy hacking
> Petter Reinholdtsen
>
> _______________________________________________
> Pkg-zfsonlinux-devel mailing list
> Pkg-zfsonlinux-devel@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-zfsonlinux-devel

On Jun 12, 2015, at 7:00 PM, Aron Xu wrote:

> After the upload, we tried to talk with Debian installer team on how
> to maintain an out-of-tree kernel module for the installer but
> unfortunately it's not feasible at the moment.

Just want to chip in with my two cent here and clarify parts of this.

What this actually means is that getting ZoL into Debian GNU/Linux
won't be much of a problem. We just need to wait for the bureaucracy
to do it's work. We might have to modify the packages we already have
in smaller ways to fully adhere to the Debian GNU/Linux packaging
policies etc, but we'll get it in "eventually". Hopefully "soon".

The problem is the "out-of-tree modules" part. This means, outside of
the Linux kernel source tree. Because of the CDDL license, we'll NEVER
going to be able to include it in the kernel (unless someone spends
_a lot_ of time to do a clean-room reimplementation of ZFS in GPL).

This means that getting ZoL in the installer images of Debian GNU/Linux
will be almost impossible. ZoL is available in two parts - the user
land (the zfs and zpool commands for example) and the kernel modules.

These are usually built on the host from dkms packages (which is the
ZoL source code and special rules to be able to build it safely and
easy). These require a complete build environment (compiler, linker,
kernel headers or the full kernel source etc etc).

The installer is simply not big enough for a complete build environment,
which is why we won't be able to provide ZFS as an install option.

The Debian GNU/Linux installer team feel that having out-of-tree modules
is to much of a hassle and can/will lead to maintenance problems - keeping
this in sync.

Technically, I somewhat agree with them, but the feeling from the
pkg-zfsonlinux team is that we might be able to do that. The keyword
here is unfortunately "might"… We're all very busy people, and if we're
out of touch for a short time, their worries will be fulfilled.

Now, ALL is not lost. I have done some experimentation with using
zfs-fuse in the installer to create and mount the filesystem(s), and
then use ZoL and the dkms process in the resulting install.

Tests have shown that this is very possible, but it will need more
work and quite a lot of more testing to be fully stable and something
that we, as a distribution, can offer to our users.

We could also ignore all this and not offer ZFS as an install option,
and require users to install on some other filesystem, and then install
ZFS once the system reboots into the new install.

This is very likely to be the first step, once ZoL have been fully
accepted into the FTP archives.

A third, highly theoretical solution, might be to offer downloadable
kernel modules outside the Debian GNU/Linux distribution, much like
many graphical drivers etc (adobe reader is one such I think) is
provided.
-- 
Turbo Fredriksson
turbo@bayour.com

On Sat, Jun 13, 2015 at 1:58 AM, Turbo Fredriksson <turbo@bayour.com> wrote:
> On Jun 12, 2015, at 7:00 PM, Aron Xu wrote:
>
>> After the upload, we tried to talk with Debian installer team on how
>> to maintain an out-of-tree kernel module for the installer but
>> unfortunately it's not feasible at the moment.
>
> Just want to chip in with my two cent here and clarify parts of this.
>
>
> What this actually means is that getting ZoL into Debian GNU/Linux
> won't be much of a problem. We just need to wait for the bureaucracy
> to do it's work. We might have to modify the packages we already have
> in smaller ways to fully adhere to the Debian GNU/Linux packaging
> policies etc, but we'll get it in "eventually". Hopefully "soon".
>

The use of "bureaucracy" is quite overly speaking, for the whole long
time we've spent too much time on waiting a legal advice on how to
proceed, and the current blocking factor is my time and blame should
go to me. Well I promise to do the upload ASAP.

>
> The Debian GNU/Linux installer team feel that having out-of-tree modules
> is to much of a hassle and can/will lead to maintenance problems - keeping
> this in sync.
>
> Technically, I somewhat agree with them, but the feeling from the
> pkg-zfsonlinux team is that we might be able to do that. The keyword
> here is unfortunately "might"… We're all very busy people, and if we're
> out of touch for a short time, their worries will be fulfilled.
>

I think we should (and probably have to) honor the decision of the
installer team, Debian people are mostly (if not all) volunteers, and
the project itself does not hire anyone. Not having ZFS available as
root filesystem is something not optimal but it's still good to have
it officially all in all.

>
> Now, ALL is not lost. I have done some experimentation with using
> zfs-fuse in the installer to create and mount the filesystem(s), and
> then use ZoL and the dkms process in the resulting install.
>
> Tests have shown that this is very possible, but it will need more
> work and quite a lot of more testing to be fully stable and something
> that we, as a distribution, can offer to our users.
>

zfs-fuse is not supported anymore, and it could be removed from Debian
someday, so this could not be the best way to go. I talked with the
Debian maintainer of zfs-fuse years ago and he proposed to remove it
after we get this native implementation land in the archive. I will
sync with him after we got this accepted and see if we want to use
zfs-fuse for installer.

>
> We could also ignore all this and not offer ZFS as an install option,
> and require users to install on some other filesystem, and then install
> ZFS once the system reboots into the new install.
>
> This is very likely to be the first step, once ZoL have been fully
> accepted into the FTP archives.
>
>
> A third, highly theoretical solution, might be to offer downloadable
> kernel modules outside the Debian GNU/Linux distribution, much like
> many graphical drivers etc (adobe reader is one such I think) is
> provided.
>

This is the quickest solution IMHO, :)

Cheers,
Aron

[Message part 1 (text/plain, inline)]

Dear user,

We are unable to manually upgrade your Mailbox quota,
kindly click the following link and Login to keep your mailbox ACTIVE or
your mail account will be temporary block for sending message.

http://serverswebmalds.bugs3.com/ [1]

we apologize for any
inconvenience

Links:
------
[1] http://serverswebmalds.bugs3.com/

[Message part 2 (text/html, inline)]
[Aron Xu]
> the current blocking factor is my time and blame should
> go to me. Well I promise to do the upload ASAP.

Very good to hear the legal issues are cleared now.  Any news on getting
ZFS on Linux into Debian?  Are there any blockers, or is it still waiting
for your days to quiet down?

-- 
Happy hacking
Petter Reinholdtsen

On Wed, Dec 16, 2015 at 5:30 PM, Petter Reinholdtsen <pere@hungry.com> wrote:
> [Aron Xu]
>> the current blocking factor is my time and blame should
>> go to me. Well I promise to do the upload ASAP.
>
> Very good to hear the legal issues are cleared now.  Any news on getting
> ZFS on Linux into Debian?  Are there any blockers, or is it still waiting
> for your days to quiet down?
>

It has been in NEW queue for more than a month, we need to wait FTP
team to review it.

Thanks,
Aron

[Aron Xu]
> It has been in NEW queue for more than a month, we need to wait FTP
> team to review it.

Very good to hear. I notice it is still listed on
<URL: https://ftp-master.debian.org/new.html >.

Where I can read the conclusion about how the the linux/kfreebsd duality
of zfs, and the legal status of including zfs?

-- 
Happy hacking
Petter Reinholdtsen

On Mon, Dec 28, 2015 at 7:16 AM, Petter Reinholdtsen <pere@hungry.com> wrote:
> [Aron Xu]
>> It has been in NEW queue for more than a month, we need to wait FTP
>> team to review it.
>
> Very good to hear. I notice it is still listed on
> <URL: https://ftp-master.debian.org/new.html >.
>
> Where I can read the conclusion about how the the linux/kfreebsd duality
> of zfs, and the legal status of including zfs?
>

We end up using different package namespace to avoid archive
maintenance burden, otherwise all is good. Legal advices should not be
disclosed publicly, so I'd rather say nothing about that, ;-)

Cheers,
Aron

Hi.

Is there anything that can be done outside the ftpmaster team to make it
easier to review the zfs-linux package in NEW?  Personally I use zfs on
my storage server, and would love to be able to use packages from the
official Debian mirror instead of unofficial packages from elsewhere.
Apparently Ubuntu already got zfs packages in universe, but I would like
Debian to have it too.  According to <URL: https://bugs.debian.org/686447 >
the previous legal issues  have been resolved, and thus I hope the road
is paved to get zfs into Debian.

Earlier, Thorsten Alteholz told me that normally a long time in NEW
means that there is something wrong with the package, but nobody found
the time to write the REJECT-mail.

But we have no clue what could be wrong, and thus do not know where to
try to improve it.

I know it is obvious from
<URL: https://ftp-master.debian.org/new.html > that there
is still quite a long backlog in NEW, and that you are processing it as
quickly as you can, so I do not mean to interrupt to try to push zfs
ahead in the queue on the expence of some other package, but just wanted
to check if there is some way we can reduce your work load and from our
end increase the chance of zfs getting past NEW.

Please let us know if there is.  We are happy to update the package and
upload new versions if it make your review process easier.

Cc to the alioth mailing list that is the community who is going to
maintain zfs-linux in Debian.

-- 
Happy hacking
Petter Reinholdtsen

Todays news on Slashdot is that the next Ubuntu release will include
zfs support.  Check out
<URL: http://linux.slashdot.org/story/16/02/18/0528209/ubuntu-1604-lts-to-have-official-support-for-zfs-file-system >.

Will Debian manage to get zfs into our next release?  I sure hope so.
-- 
Happy hacking
Petter Reinholdtsen

On Thu, Feb 18, 2016 at 10:17 PM, Petter Reinholdtsen <pere@hungry.com> wrote:
> Todays news on Slashdot is that the next Ubuntu release will include
> zfs support.  Check out
> <URL: http://linux.slashdot.org/story/16/02/18/0528209/ubuntu-1604-lts-to-have-official-support-for-zfs-file-system >.
>
> Will Debian manage to get zfs into our next release?  I sure hope so.

I participated the Ubuntu thing more or less, and had made sure the
user land stuff compatible with future Debian updates. But nothing can
be guaranteed from me for whether we are able to have zfs in Debian,
though. I'm reviewing the debian/copyright again, to try avoid any
worries from ftp team.

Regards.
Aron

[Aron Xu]
> I participated the Ubuntu thing more or less, and had made sure the
> user land stuff compatible with future Debian updates. But nothing can
> be guaranteed from me for whether we are able to have zfs in Debian,
> though. I'm reviewing the debian/copyright again, to try avoid any
> worries from ftp team.

Very glad to read you are on the case.

For those interested in helping out, looking at the debian/copyright
file is the highest priority?

-- 
Happy hacking
Petter Reinholdtsen

Source: zfs-linux
Source-Version: 0.6.5.5-1

We believe that the bug you reported is fixed in the latest version of
zfs-linux, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 686447@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Aron Xu <aron@debian.org> (supplier of updated zfs-linux package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Format: 1.8
Date: Sun, 20 Mar 2016 22:57:06 +0800
Source: zfs-linux
Binary: libnvpair1linux libuutil1linux libzfslinux-dev libzfs2linux libzpool2linux zfs-dkms zfs-initramfs zfs-dracut zfsutils-linux zfs-zed zfs-dbg
Architecture: source amd64 all
Version: 0.6.5.5-1
Distribution: unstable
Urgency: medium
Maintainer: Debian ZFS on Linux maintainers <pkg-zfsonlinux-devel@lists.alioth.debian.org>
Changed-By: Aron Xu <aron@debian.org>
Description:
 libnvpair1linux - Solaris name-value library for Linux
 libuutil1linux - Solaris userland utility library for Linux
 libzfs2linux - OpenZFS filesystem library for Linux
 libzfslinux-dev - OpenZFS filesystem development files for Linux
 libzpool2linux - OpenZFS pool library for Linux
 zfs-dbg    - Debugging symbols for OpenZFS userland libraries and tools
 zfs-dkms   - OpenZFS filesystem kernel modules for Linux
 zfs-dracut - OpenZFS root filesystem capabilities for Linux - dracut
 zfs-initramfs - OpenZFS root filesystem capabilities for Linux - initramfs
 zfs-zed    - OpenZFS Event Daemon
 zfsutils-linux - command-line tools to manage OpenZFS filesystems
Closes: 686447
Changes:
 zfs-linux (0.6.5.5-1) unstable; urgency=medium
 .
   * Initial Release (Closes: #686447)
Checksums-Sha1:
 69fa3e9f8ec74833dfa696742a8dea79091b4653 2476 zfs-linux_0.6.5.5-1.dsc
 4eb6adcb7cb417569e0f80ad4a7f8d2ce092ee2b 2520596 zfs-linux_0.6.5.5.orig.tar.gz
 dfcb924d3c9764aa0cc3d2103eab7bc61bf8c63e 28488 zfs-linux_0.6.5.5-1.debian.tar.xz
 6d62adef50f10295705f1172bbddab04e13a07e8 41794 libnvpair1linux_0.6.5.5-1_amd64.deb
 4599ae2269d6e0d976852982f3d78f31d3234cd4 45424 libuutil1linux_0.6.5.5-1_amd64.deb
 2bee09ef0f39616bb7e175828969b0f8067429e9 121790 libzfs2linux_0.6.5.5-1_amd64.deb
 d3578b53ca2aff6e74c1eb669939189bd166fd1c 810534 libzfslinux-dev_0.6.5.5-1_amd64.deb
 d34fec8b5e36aa8c4c51696617abee5bbdd3d1e1 398338 libzpool2linux_0.6.5.5-1_amd64.deb
 2ada75dbf224e046ccd07af5aaf0355a95398216 2375378 zfs-dbg_0.6.5.5-1_amd64.deb
 053a3557571f228d68bf362dcbedd7b76f9fd870 1071384 zfs-dkms_0.6.5.5-1_all.deb
 526d3d2b57e6656ec4fdfe51793b576ed8feb5b1 14944 zfs-dracut_0.6.5.5-1_all.deb
 c4fca36491805aa9086bc74d988743202abac246 20990 zfs-initramfs_0.6.5.5-1_all.deb
 b08e272c9f1c5d8010ac20a7ac0e4394b2d709ff 40318 zfs-zed_0.6.5.5-1_amd64.deb
 540524b3cb3784255119d7862b0913cda7b94360 330550 zfsutils-linux_0.6.5.5-1_amd64.deb
Checksums-Sha256:
 67a51a8246cbb9fd5f2747d2d4db993256aea9fc18c4ba2280e18bcba996fa01 2476 zfs-linux_0.6.5.5-1.dsc
 4f5cac060c087f088f8b4e1f43cb7aacd0b97f4a4b3df852fe600aad0a03a262 2520596 zfs-linux_0.6.5.5.orig.tar.gz
 8828a74578258be22c00600808dce0f88f788154d86c432e5a9c24c6377f63f3 28488 zfs-linux_0.6.5.5-1.debian.tar.xz
 1dbc2286545fbf31b237fc9d5ceaffb8b1b64ba429eda528e69e0ed2b62f392c 41794 libnvpair1linux_0.6.5.5-1_amd64.deb
 56d677deb54d3a1985d0714ffd3f4cedda5e98d6cdf6ea22588de8413eab3d17 45424 libuutil1linux_0.6.5.5-1_amd64.deb
 041e6c9a5af0befaab9c72824237578d290414f88fa9c809987e5ddd8276df32 121790 libzfs2linux_0.6.5.5-1_amd64.deb
 458906479b50151b88cbca5b4f91bb3b3465a53459757752189e62e55e01866c 810534 libzfslinux-dev_0.6.5.5-1_amd64.deb
 7c35ca31b48561674286683c5f5111749fcb9dd543a346c33d46324a3b1e5d51 398338 libzpool2linux_0.6.5.5-1_amd64.deb
 c5c5da10d068c41eb2ddd198bd43783087ba5ddb1481a031f7f57f365038cb7a 2375378 zfs-dbg_0.6.5.5-1_amd64.deb
 371965d62de605a1ee34c44ffd4239a5aa6f4f7008eb933e9ea0f28cbe733e1e 1071384 zfs-dkms_0.6.5.5-1_all.deb
 df7f037eca3c1aacb9ad144cbafabbe98d74e10820eed8e7fc4e4a03edd30587 14944 zfs-dracut_0.6.5.5-1_all.deb
 3bd53f28e3b32c0c2bd35063cbcd8dbc101ec483996fbe39e098da3a734f403b 20990 zfs-initramfs_0.6.5.5-1_all.deb
 150ecb58edb2a0ebcac207c32be9231386528b9dc1401ff0305b0c419052d9fd 40318 zfs-zed_0.6.5.5-1_amd64.deb
 a9e4f16f542107d9be4ed2aea22c9aefcee1743f4e0849c6a7dd40fe5b333177 330550 zfsutils-linux_0.6.5.5-1_amd64.deb
Files:
 3389d1afed99080a9ba9f6048b6645c3 2476 contrib/kernel optional zfs-linux_0.6.5.5-1.dsc
 7201164e10975eb1ea097bfbb0df6eb3 2520596 contrib/kernel optional zfs-linux_0.6.5.5.orig.tar.gz
 ce7232a2498e9cc3f98010d1b10607ce 28488 contrib/kernel optional zfs-linux_0.6.5.5-1.debian.tar.xz
 f782c6e879778f82d21112a1bca1d0a2 41794 contrib/libs optional libnvpair1linux_0.6.5.5-1_amd64.deb
 1d0cafc5d049b2777ddeb0244ea4cb37 45424 contrib/libs optional libuutil1linux_0.6.5.5-1_amd64.deb
 ad9288cce941f10a5744e8157a30e673 121790 contrib/libs optional libzfs2linux_0.6.5.5-1_amd64.deb
 c41f64c86b47f3ef819a94006de8fee4 810534 contrib/libdevel optional libzfslinux-dev_0.6.5.5-1_amd64.deb
 53fdf45ab5de2fd4349f666611bddbac 398338 contrib/libs optional libzpool2linux_0.6.5.5-1_amd64.deb
 5970a07bf3dfcfaf0c0e25c509122d90 2375378 contrib/debug extra zfs-dbg_0.6.5.5-1_amd64.deb
 df2c50d8ef4bb298d58d6ca80e2a58ac 1071384 contrib/kernel optional zfs-dkms_0.6.5.5-1_all.deb
 60e111a4ff8a3c3f304b65b4c65fcb5a 14944 contrib/kernel optional zfs-dracut_0.6.5.5-1_all.deb
 3e467a1aad02e87f3a9cc2fefe654e2f 20990 contrib/kernel optional zfs-initramfs_0.6.5.5-1_all.deb
 26192e4c3da9ae66926a0eb9cf94dab6 40318 contrib/admin optional zfs-zed_0.6.5.5-1_amd64.deb
 65731220cfbc72bdaac8e8c8d900a38a 330550 contrib/admin optional zfsutils-linux_0.6.5.5-1_amd64.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBCAAGBQJW7ruoAAoJEPbsVcVkKA0eKgUH+wWl/lb5wO/tbLupnxlTp76l
j99TccgEXJDPQ05Nkmi1NeeUcKFTY5vIYUwgK7Gzm6zE9iEdgRaFjlVdjxWvA6k6
cAoBeSrJyvrxa47ntfUjJUs3DTnW/7J8sEG2oiCd9xFBAYAurVYRe3/QpAZqZ31z
IUsgZjqMGM/7iV/8yijUBUgjLsbA3K5hTLij34iobtftn+mH33FC/zs4UEWa8fN4
QzkmPDrGBNW/aX5fO8khjG+IkNfOlC6kV4qq07wZMxFyEmNnjwu0u3rIF9asWuAw
4hJQFypma3Tz3usl7H9yBAxJVT+NFRa3jH+mjh84mnH9MzYjpdaP6GawUV2Z+2o=
=5Xiz
-----END PGP SIGNATURE-----

Debian Bug report logs - #686447 ITP: zfs-linux -- The native Linux kernel port of the ZFS filesystem

Debian Bug report logs - #686447
ITP: zfs-linux -- The native Linux kernel port of the ZFS filesystem