Source: proot
Section: utils
Priority: optional
Maintainer: Package Salvaging Team <team+salvage@tracker.debian.org>
Uploaders: Rémi Duraffort <ivoire@videolan.org>,
           Andreas Tille <tille@debian.org>
Build-Depends: debhelper-compat (= 13), libtalloc-dev, pkgconf, uthash-dev, libarchive-dev, python3-docutils <!nodoc>
Standards-Version: 4.7.2
Vcs-Browser: https://salsa.debian.org/salvage-team/proot
Vcs-Git: https://salsa.debian.org/salvage-team/proot.git
Homepage: https://proot-me.github.io/

Package: proot
Architecture: amd64 arm64 armel armhf i386 sh4 x32
Depends: ${shlibs:Depends}, ${misc:Depends}
Description: emulate chroot, bind mount and binfmt_misc for non-root users
 PRoot is a user-space implementation of chroot, mount --bind,
 and binfmt_misc.
 .
 This means that users don't need any privileges or setup to do things like
 using an arbitrary directory as the new root filesystem, making files
 accessible somewhere else in the filesystem hierarchy, or executing programs
 built for another CPU architecture transparently through QEMU user-mode.
 .
 Also, developers can add their own features or use PRoot as a Linux process
 instrumentation engine thanks to its extension mechanism.
 .
 Technically PRoot relies on ptrace, an unprivileged system-call available in
 every Linux kernel.

Package: care
Architecture: amd64 arm64 armel armhf i386 sh4 x32
Depends: ${shlibs:Depends}, ${misc:Depends}
Replaces: proot (<< 5.1.0-2)
Description: make linux programs reproducible on all linux systems
 CARE monitors the execution of the specified command to create an archive that
 contains all the material required to re-execute it in the same context.
 .
 That way, the command will be reproducible everywhere, even on Linux systems
 that are supposed to be not compatible with the original Linux system. CARE is
 typically useful to get reliable bug reports, demonstrations, artifact
 evaluation, tutorials, portable applications, minimal rootfs, file-system
 coverage, ...
 .
 By design, CARE does not record events at all. Instead, it archives
 environment variables and accessed file-system components -- before
 modification -- during the so-called initial execution. Then, to reproduce
 this execution, the re-execute.sh script embedded into the archive restores
 the environment variables and relaunches the command confined into the saved
 file-system.