[...] BtrfsUtils.cc: In function ‘void snapper::set_default_id(int, long long unsigned int)’: BtrfsUtils.cc:158:16: error: ‘BTRFS_IOC_DEFAULT_SUBVOL’ was not declared in this scope if (ioctl(fd, BTRFS_IOC_DEFAULT_SUBVOL, &id) != 0) ^ BtrfsUtils.cc: In function ‘long long unsigned int snapper::get_default_id(int)’: BtrfsUtils.cc:166:33: error: aggregate ‘snapper::get_default_id(int)::btrfs_ioctl_search_args args’ has incomplete type and cannot be defined struct btrfs_ioctl_search_args args; ^ BtrfsUtils.cc:170:4: error: invalid use of incomplete type ‘struct snapper::get_default_id(int)::btrfs_ioctl_search_key’ sk->tree_id = BTRFS_ROOT_TREE_OBJECTID; [...] Not fixed at upstream (yet). Current master gives a similar error: Btrfs.cc: In member function 'bool snapper::StreamProcessor::dumper(int)': Btrfs.cc:1153:69: error: too few arguments to function 'int btrfs_read_and_process_send_stream(int, btrfs_send_ops*, void*, int, u64)' r = btrfs_read_and_process_send_stream(fd, &send_ops, &*this, 0); ^ In file included from Btrfs.cc:44:0: /usr/include/btrfs/send-stream.h:59:5: note: declared here int btrfs_read_and_process_send_stream(int fd, ^ Makefile:536: recipe for target 'Btrfs.lo' failed
>Btrfs.cc:1153:69: error: too few arguments to function 'int this is actually due to btrfs-progs's api changes 3.14.1: int btrfs_read_and_process_send_stream(int fd, struct btrfs_send_ops *ops, void *user, int honor_end_cmd); 3.16 int btrfs_read_and_process_send_stream(int fd, struct btrfs_send_ops *ops, void *user, int honor_end_cmd, u64 max_errors);
I've just reported this to upstream
quote from upstream: The problem is known and fixed by 0d2966d. But this requires patches for btrfsprogs to define version macros, see http://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg36761.html. so, I think we can temporarily force version 0.2.3 depend on <sys-fs/btrfs-progs-3.16, and waiting for new release from snapper upstream, also fix from btrfs-progs side. cc @floppym and @slyfox, since they are btrfs-progs maintainers.
if there's a good chance btrfs-progs upstream is going to accept the patch (unfortunately no response yet) I'd recommend on pulling the patch.
(In reply to Tiziano Müller from comment #4) > if there's a good chance btrfs-progs upstream is going to accept the patch > (unfortunately no response yet) I'd recommend on pulling the patch. there is one comment for the btrfs-progs patch, but no further going, and is's not been accepted. snapper upstream kindly released version 0.2.4 which include the fix (depend on btrfs-progs part), I can't say for btrfs-progs upstream. but if put aside of this, do you guys (btrfs-progs maintainer, @floppym and @slyfox) willing to carry that patch here (in gentoo downstream)? for now, I've already pushed the <btrfs-progs-3.16 dep fix.
I don't think it makes sense to maintain a patch of this nature at the distro level.
+*snapper-0.2.4 (15 Nov 2014) + + 15 Nov 2014; Yixun Lan <dlan@gentoo.org> +snapper-0.2.4.ebuild, + snapper-9999.ebuild: + version bump, fix bug 522656