Re: Please test zfsutils 9.0~svn226163-1
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hello Robert,
On 21.10.2011 22:52, Robert Millan wrote:
> Thanks a lot for your effort, this looks very nice. I've split your
> patch into each of its logical changes and committed separately (it's
> always nice to have granular SVN history):
Yes, I noticed. The commit bot in IRC is really nice to keep me up to
date with changes.
> - debian/rules adjustments. The variable initialization I just copied
> it from kfreebsd-10/debian/rules one (better if they're kept more in
> sync).
Fair enough.
> - zfsutils.zfs.init runlevel change (I just have no idea what's the
> right thing, go ahead with it if you know what you're doing, please
> document your change ;-))
At least I couldn't find any issue with it while it increases the
archive-wide compatibility with other LSB init scripts.
> I think Guillem's point is that providing GPL-incompatible facilities
> to other users (i.e. outside of Debian GNU/kFreeBSD project) can lead
> to trouble. It's better to avoid that IMHO.
You could ask to remove OpenSSL for the very same reason. :)
That said, I am perfectly fine an appreciate if anyone wants to wrap a
API compatible, GPL friendly wrapper around a license compatible crypto
library. As far as I know, Guillem is pretty much done in doing so.
I noticed you committed my patch adding libmd-dev to the
build-dependencies. This means the binary package can't be built right
now, are you aware of this?
>> Regardless of that issue /I/ can't upload anyway as I'm lacking upload
>> permissions. If you, or anyone else wants to, just go ahead. :)
>
> Unless someone objects I can set Dm-Upload-Allowed with next upload.
I would need to be in Uploaders as well. :)
Note, I don't feel comfortable in uploading a crucial component like
zfsutils anyway. However I am happy to help occasionally. Moreover, I am
in NM already, so I possibly become a Debian Developer in a foreseeable
future too.
Until then I am perfectly ok to send you updates or commit smaller
changes to the repository.
> What actual symptoms did you find? zfsutils init on Wheezy currently
> gives an error (before your update) but there was another reason for
> this (it's related to #637086).
On my machine it works just fine (zfs volinit that is) when using the
Wheezy kernel and tools (although I see your point in #637086). However,
using the newer zfsutils which do not have the volinit command anymore,
I can't restore sub-volumes upon boot anymore, although "zfs list" still
lists them. Additionally I do not have /dev/zvol anymore for some
reasons I do not quite understand.
This problem disappears as soon as I upgrade to the 9.0 kernel from
experimental or keep zfsutils and kernel at 8.2
> The problem I see with this is that if you link the libraries
> statically into each binary, the overall size increases. Binary size
> is important in zfsutils because it affects D-I download time and
> image size.
You are absolutely right.
> Could we keep shipping the shared objects (either in their own package
> or in zfsutils itself) and only get rid of the static library and
> headers?
Not quite. The problem aren't the headers and the libfoo.a archive. That
would only be a problem for third party packages which use our headers
to link against our library (e.g. like grub does right now).
The problem is our own zfsutils (the binary package of that name I mean
here) have this problem as well. As our libraries do not export any
version definition and we didn't (and shouldn't) bump SONAME,
dpkg-shlibdeps assumes every version ever installed of lib* suits as
dependency for zfsutils.
But yes, could keep shipping the shared objects as they are. We could
embed the libraries into the zfsutils binary package and install them to
a private location, say /lib/zfsutils. That way we wouldn't consume more
space and solve the dependency problem as the libraries are always
upgraded with the zfsutils package itself.
We would just need to make sure the libraries aren't installed into a
public library search path (/lib, /usr/lib/, ...) to avoid that anyone
accidentally links against it.
I tried this approach as well, but I didn't succeed. You need to feed
the linker with a RPATH in LDFLAGS and hack dh_shlibdeps to find
libraries in such a private location. That's not trivial to achieve in
our hackish build process.
>> * I fixed hyphen-used-as-minus-sign by a Perl hack in debian/rules
>
> I'll send that upstream.
Makes sense, thanks.
>
>> I made the rules targets cleaner
>
> Please could you commit that?
>
Will do.
- --
with kind regards,
Arno Töll
IRC: daemonkeeper on Freenode/OFTC
GnuPG Key-ID: 0x9D80F36D
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQIcBAEBAgAGBQJOoenbAAoJEMcrUe6dgPNtpf4QAJIKWxFYra4uD4Toqqpa6fPm
iQDi7Z3+9JPneFGAg68LjI84OqjUuF+KHkkhIhX+8VVNRNbvh6VsOsZiitjdNfTC
1MALH0wN2r59DznYwTqpCu1rq7MPBw+GdP+cLPwCcCt5ukC4YBYMsu0IwuHwwCsq
XomhBC5XU756BAO52yDNlDFwLxpDEFNYB+4zEoTtcAvYpd/tSnS2ISWUlnELPxQV
4CNycpLJW7muyhEfP40qO+QIbcfYKmg6l6SyuGyxjvAtXWFyDD3XxQ5bM2pqA7Im
sLduaNDQhhHhAOxdJGQILsIiOAZkqTHimgdy1F6GKofnCb0joV4LjJFIgQ56UvuC
eDYGBjhvfrRiZo1Jx39fcyc1vEdKcJvlCXJRQA494YOyl5fD8Jb06M7w2ns3bGeX
JMOfxzjjW5wvWOyuLCPeEc3MA4CQ0jbngNKxxolML55mSsEkb6vGXr8RZYPrLelM
2eG7oNYmlchYNl5MIDI5GcQgGfS/FvkDVqJyyowKarksWJF26rcRQ9i6B34XIA+a
/xotmpYxyUPbL8IGlDrygwDLa5wD0YFuNVTIuciahIWXRajMYocxJFNfGSF1AHy0
uMf5O8bbjyNF8NK26BDQt0sbLrPCzds7GHAKGoQ1Cske8W+2MjwQuongTS0s4FxQ
7qFDYV5+IehQyCk9hXNF
=XwQi
-----END PGP SIGNATURE-----
Reply to: