Bug#1008607: xine-lib-1.2: FTBFS with dav1d 1.0.0

2022-03-29 Thread Dylan Aïssi
Source: xine-lib-1.2
Version: 1.2.12-1
Severity: important
Tags: sid bookworm ftbfs patch
Forwarded: https://sourceforge.net/p/xine/tickets/11/


xine-lib-1.2 FTBFS with dav1d 1.0.0 in experimental:
|libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I../../include -I../..
-I../../include -I../../include -I../../src -I../../src/xine-engine
-I../../src/xine-engine -I../../src/xine-utils -I../../src/input
-I../../src/input -I../../lib -I../../lib -DNDEBUG -D_REENTRANT
-DXINE_COMPILE -Wdate-time -D_FORTIFY_SOURCE=2 -O3
-fexpensive-optimizations -ffast-math -fvisibility=hidden
-I/usr/include/libpng16 -pipe -Wall -Wformat=2 -Wno-format-zero-length
-Wmissing-format-attribute -Werror-implicit-function-declaration
-Wstrict-aliasing=2 -Wchar-subscripts -Wmissing-declarations
-Wmissing-prototypes -Wwrite-strings -Wpointer-arith -g -g -O2
-ffile-prefix-map=/build/xine-lib-1.2-1.2.12=.
-fstack-protector-strong -Wformat -Werror=format-security -O3
-fexpensive-optimizations -ffast-math -Wall -Wchar-subscripts
-Wnested-externs -Wcast-align -Wmissing-declarations
-Wmissing-prototypes -Wmissing-format-attribute -Wno-pointer-sign
-Wformat=2 -Wno-format-zero-length -Wformat-security
-Wstrict-aliasing=2 -Werror=implicit-function-declaration -c libpng.c
-fPIC -DPIC -o .libs/xineplug_decode_libpng_la-libpng.o
|dav1d.c: In function '_open_plugin':
|dav1d.c:547:11: error: 'Dav1dSettings' has no member named 'n_frame_threads'
|  547 |   settings.n_frame_threads = (ncpu > 8) ? 4 : (ncpu < 2) ? 1 : ncpu/2;
|  |   ^
|dav1d.c:548:12: error: 'Dav1dSettings' has no member named
'n_tile_threads'; did you mean 'n_threads'?
|  548 |   settings.n_tile_threads = MAX(1, ncpu -
settings.n_frame_threads + 1);
|  |^~
|  |n_threads
|In file included from ../../lib/os_internal.h:71,
| from ../../include/config.h:47,
| from dav1d.c:23:
|dav1d.c:548:51: error: 'Dav1dSettings' has no member named 'n_frame_threads'
|  548 |   settings.n_tile_threads = MAX(1, ncpu -
settings.n_frame_threads + 1);
|  |   ^
|libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I../../include -I../..
-I../../include -I../../include -I../../src -I../../src/xine-engine
-I../../src/xine-engine -I../../src/xine-utils -I../../src/input
-I../../src/input -I../../lib -I../../lib -DNDEBUG -D_REENTRANT
-DXINE_COMPILE -Wdate-time -D_FORTIFY_SOURCE=2 -O3
-fexpensive-optimizations -ffast-math -fvisibility=hidden -pipe -Wall
-Wformat=2 -Wno-format-zero-length -Wmissing-format-attribute
-Werror-implicit-function-declaration -Wstrict-aliasing=2
-Wchar-subscripts -Wmissing-declarations -Wmissing-prototypes
-Wwrite-strings -Wpointer-arith -g -g -O2
-ffile-prefix-map=/build/xine-lib-1.2-1.2.12=.
-fstack-protector-strong -Wformat -Werror=format-security -O3
-fexpensive-optimizations -ffast-math -Wall -Wchar-subscripts
-Wnested-externs -Wcast-align -Wmissing-declarations
-Wmissing-prototypes -Wmissing-format-attribute -Wno-pointer-sign
-Wformat=2 -Wno-format-zero-length -Wformat-security
-Wstrict-aliasing=2 -Werror=implicit-function-declaration -c
group_raw.c  -fPIC -DPIC -o .libs/group_raw.o
|dav1d.c:548:51: error: 'Dav1dSettings' has no member named 'n_frame_threads'
|  548 |   settings.n_tile_threads = MAX(1, ncpu -
settings.n_frame_threads + 1);
|  |   ^
|In file included from ../../include/xine/input_plugin.h:28,
| from ../../include/xine/xine_internal.h:35,
| from dav1d.c:38:
|dav1d.c:551:21: error: 'Dav1dSettings' has no member named 'n_frame_threads'
|  551 | settings.n_frame_threads, settings.n_tile_threads);
|  | ^
|../../include/xine/xineutils.h:687:40: note: in definition of macro 'xprintf'
|  687 | xine_log(xine, XINE_LOG_TRACE, __VA_ARGS__);
  \
|  |^~~
|dav1d.c:551:48: error: 'Dav1dSettings' has no member named
'n_tile_threads'; did you mean 'n_threads'?
|  551 | settings.n_frame_threads, settings.n_tile_threads);
|  |^~
|../../include/xine/xineutils.h:687:40: note: in definition of macro 'xprintf'
|  687 | xine_log(xine, XINE_LOG_TRACE, __VA_ARGS__);
  \
|  |^~~

The attached upstream patch fix this issue.

Best,
Dylan
From b0d8e56959af72e9ece0a44d746231ac80b85de9 Mon Sep 17 00:00:00 2001
From: Petri Hintukainen 
Date: Thu, 24 Mar 2022 19:19:19 +0200
Subject: [PATCH] dav1d 1.0.0 support

https://sourceforge.net/p/xine/tickets/11/
---
 ChangeLog | 2 ++
 src/video_dec/dav1d.c | 6 ++
 2 files changed, 8 insertions(+)

diff --git a/src/video_dec/dav1d.c b/src/video_dec/dav1d.c
index 06187295c..187b357cc 100644
--- a/src/video_dec/dav1d.c
+++ b/src/video_dec/dav1d.c
@@ -544,11 +544,17 @@ static video_decoder_t

Bug#1008616: /etc/schroot/setup.d/05zfs: make ZFS snapshot removal more robust

2022-03-29 Thread Florian Ernst
Package: schroot
Version: 1.6.10-12
Severity: minor
File: /etc/schroot/setup.d/05zfs
Tags: patch

Dear maintainer,

thank you for enabling ZFS usage.

Please consider the following patch to make clone removal a little more
robust:

| diff --git a/schroot/setup.d/05zfs b/schroot/setup.d/05zfs
| index 6ecc0196..785aee5f 100755
| --- a/schroot/setup.d/05zfs
| +++ b/schroot/setup.d/05zfs
| @@ -49,10 +49,10 @@ if [ "$CHROOT_TYPE" = "zfs-snapshot" ] && [ -n 
"$CHROOT_ZFS_CLONE_NAME" ]; then
|  if zfs list "$CHROOT_ZFS_CLONE_NAME" >/dev/null 2>&1
|  then
|  if [ "$VERBOSE" = "verbose" ]; then
| -zfs destroy "$CHROOT_ZFS_CLONE_NAME"
| +zfs destroy -r "$CHROOT_ZFS_CLONE_NAME"
|  zfs destroy "$CHROOT_ZFS_SNAPSHOT_NAME"
|  else
| -zfs destroy "$CHROOT_ZFS_CLONE_NAME" > /dev/null
| +zfs destroy -r "$CHROOT_ZFS_CLONE_NAME" > /dev/null
|  zfs destroy "$CHROOT_ZFS_SNAPSHOT_NAME" > /dev/null
|  fi
|  else

I.e. recursively destroy all children of that clone via the "-r" option.
Otherwise I can all too easily happen that such children exist in the
form of snapshots, e.g. when using zfsnap or any such tool that might
automatically create a snapshot of a ZFS dataset while it is in use.

For illustration, let's consider the following sequence of actions:

1. a user enters a ZFS-based chroot via
   $ schroot -c unstable-amd64-sbuild
2. schroot creates a snapshot of the base dataset and then a clone of
   that snapshot, e.g.
   $ zfs list -t all
   [...]
   
zfspool/SYSTEM/srv/chroot/unstable-amd64-sbuild@unstable-amd64-sbuild-44e762df-cab6-4cf3-99dd-15f0fd018d18
 0B  -  359M  -
   
zfspool/SYSTEM/srv/chroot/unstable-amd64-sbuild/schroot-unstable-amd64-sbuild-44e762df-cab6-4cf3-99dd-15f0fd018d18
 8K  62.2G  359M  legacy
3. some tool - here done manually - creates a snapshot of that clone
   $ sudo zfs snapshot 
zfspool/SYSTEM/srv/chroot/unstable-amd64-sbuild/schroot-unstable-amd64-sbuild-44e762df-cab6-4cf3-99dd-15f0fd018d18@test
4. the user exits their schroot session and schroot complains
   E: 05zfs: cannot destroy 
'zfspool/SYSTEM/srv/chroot/unstable-amd64-sbuild/schroot-unstable-amd64-sbuild-44e762df-cab6-4cf3-99dd-15f0fd018d18':
 filesystem has children
   E: 05zfs: use '-r' to destroy the following datasets:
   E: 05zfs: 
zfspool/SYSTEM/srv/chroot/unstable-amd64-sbuild/schroot-unstable-amd64-sbuild-44e762df-cab6-4cf3-99dd-15f0fd018d18@test
   E: unstable-amd64-sbuild-44e762df-cab6-4cf3-99dd-15f0fd018d18: Chroot setup 
failed: stage=setup-stop
5. $CHROOT_ZFS_CLONE_NAME and $CHROOT_ZFS_SNAPSHOT_NAME must be cleaned
   up manually

Cheers,
Flo


signature.asc
Description: PGP signature


Bug#988354: schroot: fails to enter zfs source chroots

2022-03-29 Thread Florian Ernst
Hello there,

On Tue, May 11, 2021 at 10:48:00AM +0200, Sebastian Ramacher wrote:
> Thanks for adding zfs support to schroot. While entering a zfs-backed
> chroot works fine, i.e., schroot -c unstable-amd64-sbuild, trying to
> enter the source chroot fails:
> [...]

FWIW, this works for me, so it might simply be that some additional
configuration is required. Thus the following just for reference:

My bash history tells me that I actually applied

# zfs set mountpoint=legacy zfspool/SYSTEM/srv/chroot/unstable-amd64-sbuild

when migrating to a ZFS-based schroot setup as per

# cat /etc/schroot/chroot.d/unstable-amd64-sbuild-*
[unstable-amd64-sbuild]
description=Debian unstable/amd64 autobuilder
groups=root,sbuild
root-groups=root,sbuild
profile=sbuild
type=zfs-snapshot
zfs-dataset=zfspool/SYSTEM/srv/chroot/unstable-amd64-sbuild
mount-options=-o relatime,async
command-prefix=/var/cache/pbuilder/ccache/sbuild-setup,eatmydata
aliases=UNRELEASED,sid,rc-buggy,experimental

and indeed it just works for me, cf. for illustration

$ schroot -c unstable-amd64-sbuild # normal access
(unstable-amd64-sbuild)fernst@fernst:~$ df -hT
Filesystem  
   Type   Size  Used Avail Use% Mounted on
zfspool/SYSTEM/srv/chroot/unstable-amd64-sbuild/schroot-unstable-amd64-sbuild-caeca563-8016-4209-a022-77f59f5d4058
 zfs 65G  359M   64G   1% /
tmpfs   
   tmpfs   16G 0   16G   0% /dev/shm
zfspool/SYSTEM/var  
   zfs 50G   33G   18G  65% /build
zfspool/SYSTEM/home/fernst  
   zfs264G  201G   64G  76% 
/home/fernst/debian
/dev/mapper/lvmpool-root
   ext415G   11G  4.0G  73% 
/etc/sudoers.d/local-reprotest
(unstable-amd64-sbuild)fernst@fernst:~$ # CTRL+D here
exit
$ schroot -c source:unstable-amd64-sbuild # accessing the source chroot as a 
normal user
E: Access not authorised
I: You do not have permission to access the schroot service.
I: This failure will be reported.
$ sudo schroot -c source:unstable-amd64-sbuil # accessing the source chroot via 
sudo
(unstable-amd64-sbuild)root@fernst:/home/fernst# touch /blubber # apply some 
change
(unstable-amd64-sbuild)root@fernst:/home/fernst# # CTRL+D here
exit
$ schroot -c unstable-amd64-sbuild
(unstable-amd64-sbuild)fernst@fernst:~$ ls -al /blubber # check whether the 
above change persisted
-rw-r--r-- 1 root root 0 Mar 29 16:09 /blubber
(unstable-amd64-sbuild)fernst@fernst:~$ # CTRL+D here
exit

The only glitch I had so far with ZFS-based schroot I just reported in
, and there is a simple fix available.

Cheers,
Flo


signature.asc
Description: PGP signature


Bug#990334: sbuild: Make usage of zfs snapshot/rollback and clone

2022-03-29 Thread Florian Ernst
Hello there,

On Sat, Jun 26, 2021 at 06:54:16AM +0200, Johannes Schauer Marin Rodrigues 
wrote:
> Quoting Juri Grabowski (2021-06-25 23:00:39)
> > overlayfs doesn't work with ZFS right now.  I mean, that through zfs
> > snapshot/rollback and clone features we can achieve better performance in
> > spawning and destroying new schroots.
> 
> Possibly. But if so, then that's something that schroot has to offer. Not
> sbuild.

JFTR, schroot already supports ZFS datasets with snapshotting and
cloning to create new sessions. For reference, I put a description of my
personal setup into
.

Cheers,
Flo


signature.asc
Description: PGP signature