Bug 522656 – app-backup/snapper-0.2.3[btrfs] fails to build with sys-fs/btrfs-progs-3.16

• Status: RESOLVED FIXED
• Product: Gentoo Linux

[Description Tiziano Müller (RETIRED) 2014-09-12 16:59:50 UTC]

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

[Comment 1 Yixun Lan 2014-09-12 22:05:33 UTC]

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

[Comment 2 Yixun Lan 2014-09-12 22:11:39 UTC]

I've just reported this to upstream

[Comment 3 Yixun Lan 2014-09-15 06:30:33 UTC]

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/[e-mail]/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.

[Comment 4 Tiziano Müller (RETIRED) 2014-09-15 09:23:07 UTC]

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.

[Comment 5 Yixun Lan 2014-09-15 14:30:17 UTC]

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

[Comment 6 Mike Gilbert 2014-09-15 16:27:53 UTC]

I don't think it makes sense to maintain a patch of this nature at the distro level.

[Comment 7 Yixun Lan 2014-11-15 14:38:35 UTC]

+*snapper-0.2.4 (15 Nov 2014)
+
+  15 Nov 2014; Yixun Lan <[e-mail]> +snapper-0.2.4.ebuild,
+  snapper-9999.ebuild:
+  version bump, fix bug 522656