Hi Arno, 2011/10/10 Arno Töll <deb...@toell.net>: > Hence I tried to port the corresponding zfsutils for the kfreebsd-9 > kernel. The package I produced works fine with the kfreebsd kernel > 9.0~svn225873-1 which is in experimental right now. On the other hand I > didn't achieve any major problems with kfreebsd 8.2 either.
Nice work. Would be nice if you could put this on SVN untill it can be uploaded to experimental. What would be a good layout for 8.x/9.x branches? Maybe put 9.x version in trunk/ and move 8.x version to branches/freebsd-8/? What do you think? > * We could get rid of the last delta in 01_glibc_kludge.diff and the > whole (hacky and ugly) 16-wrap-cdefs.diff if kfreebsd-kernel-headers > would export cdefs.h like it does upstream [2]. Could you fix this in kfreebsd-kernel-headers instead? > * zfsutils depend on libmd now (lib/libmd). That's a crypto library, but > I couldn't find anything which is API compatible in Debian already. > Hence, 05_makefile.diff statically links this library into the binaries > where needed. This wouldn't be accepted in Debian archive. There's an RFP for this library, but it needs some cleanup in debian/copyright before it can be uploaded IIRC. Maybe you can help Guillem with this? > * 10_zpool_import.diff seems not to be needed anymore, and the utils > build fine without. I tried to port it to the new utils snapshot, but > the code is pretty much a new implementation so much of the patch does > not apply anymore. Also I am not sure what the original intention of the > patch was, so I removed it. According to SVN log, there's a former version of this patch (10_dev_dsk.diff), which looks much more straightforward. If both versions have the same intention, maybe that helps understanding. > * 15_pthread_compat.diff is a terrible hack. The upstream source uses > pthread_mutex_isowned_np now which is supported in FreeBSD's libthr, but > not in glibc pthread (apparently). The implementation of the function is > simple, unfortunately our pthread_mutex_t type is not compatible either > (seems to be a struct on FreeBSD, but (apparently) a scalar on glibc), > so I made the code to be a no-op instead. Its usage is on assert() only, > checking entry points of some functions. I guess disabling the call has > no unwanted side effects on the functionality I hope. Maybe we can put it as inline stub in glibc headers instead? E.g. static inline pthread_mutex_isowned_np (...) { ... } > problem. It can also be found in the current stable version by the way. > zfsutils builds a lot of shared libraries, but many of them aren't > properly versioned (like using a proper SONAME), they aren't intended to > be shared and break happily ABIs, for example: If they don't use SONAME, upstream considers this a bug (we've hit this before e.g. libgeom). The solution is to bump sonames where needed (in upstream). > Maybe we should link them statically instead: That should be a last ressort option. -- Robert Millan -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caofdtxpuuacmxa6j8nnxsznkedlrz2qbgnvvppj-i8hmaoq...@mail.gmail.com