Re: Bug#1074242: ITP: opentelemetry -- C++ OpenTelemetry client
> This package will provide the C++ OpenTelemetry client. It will be a > dependency of tango 10.0. It will be maintained by the Freexian packaging > team. I hope it's opt-in to actually send anything. -- Salvo Tomaselli "Io non mi sento obbligato a credere che lo stesso Dio che ci ha dotato di senso, ragione ed intelletto intendesse che noi ne facessimo a meno." -- Galileo Galilei https://ltworf.codeberg.page/
reproducible Debian containers exists today (Re: Reviving schroot as used by sbuild)
hi, On Tue, Jun 25, 2024 at 02:02:11PM +0100, Simon McVittie wrote: > I have to ask: > > Could we use a container framework that is also used outside the Debian > bubble, rather than writing our own from first principles every time, and > ending up with a single-maintainer project being load-bearing for Debian > *again*? [...] +1 > Podman uses the same OCI images as Docker, so it can either pull from a > trusted OCI registry, or use images that were built by importing a tarball > generated by e.g. mmdebstrap or sbuild-createchroot. I assume that for > Debian we would want to do the latter, at least initially, to avoid > being forced to either trust an external registry like hub.docker.com > or operate our own. I'd just like to mention the less known fact, that https://docker.debian.net/ provides reproducible images for nine Debian architectures today... -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ 🔥 - this is fine. signature.asc Description: PGP signature
Bug#1074309: ITP: python-pysubs2 -- Python library for editing subtitle files.
Package: wnpp Severity: wishlist Owner: Alexandre Detiste X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: python-pysubs2 Version : 1.7.1 Upstream Contact: Tomáš Karabela * URL : https://github.com/tkarabela/pysubs2/ * License : MIT/X Programming Lang: Python Description : Python library for editing subtitle files. pysubs2 is a Python library for editing subtitle files. It’s based on SubStation Alpha, the native format of Aegisub; it also supports SubRip (SRT), MicroDVD, MPL2, TMP and WebVTT formats and OpenAI Whisper captions. There is a small CLI tool for batch conversion and retiming. --- This package is a new dependency of "subliminal". I will maintain this package inside Debian Python Team
Re: Reviving schroot as used by sbuild
On Tue, 25 Jun 2024 at 18:47:49 +0200, Guillem Jover wrote: > I manage my chroots with schroot (but not via sbuild, for dog fooding > purposes :), and use type=directory and union-type=overlay so that I > get a fast and persistent base, independent of the underlying filesystem, > with fresh instances per session. type=directory *with a union-type* is OK, and avoids the persistence issues I mentioned: it has many of the same properties as type=file (but different performance characteristics). type=directory *without* a union-type can trigger bugs like the ones I mentioned. > You can access the base via the source: names This is the same as with type=file. If you do this, be careful to avoid installing software that creates/relies on new uids existing inside the chroot, such as dbus or exim4, if a corresponding username does not already exist outside the chroot. That's what causes bugs like the ones I mentioned. I would recommend usually re-bootstrapping the base instead of modifying it in-place, to avoid having differences between a freshly-bootstrapped base and the current state of your base chroot building up over time (for example packages that are removed from the transitively Essential set remaining installed in your base chroot indefinitely, or non-dpkg-managed configuration files being different for new installations and upgraded older installations), which can result in a harder-to-reproduce build environment. smcv
Re: Reviving schroot as used by sbuild
Hi Helmut (2024.06.25_16:55:45_+) > lxd/incus also was on my list, Personally, I have been using LXD (and now Incus, as it made it into Debian, yay) for my experimentation and local package builds, for a number of years now. They have native support for btrfs snapshots, locally built images, and make it relatively simple to block network access for my builds. The autopkgtest-virt backed is a bit klunky, but I don't miss schroot at all. > but my understanding is that they do not work without their system > services at all Correct. LXC containers are essentially VMs without their own kernel. They run their own systemd. This does mean that I build packages in a fatter system than necessary. But that has yet to be an issue for me. > and being able to operate containers (i.e. being incus-admin or the > like) roughly becomes equivalent to being full root on the system > defeating the purpose of the exercise. You don't have to be incus-admin to use Incus. Users get their own incus project (see the incus-user.service). But I've never played with this much, on a single-user system, incus-admin is just much simpler (if less secure). Of course incus still has to be root itself to add network interfaces to bridges. It's nice to be able to control networking for the containers, but it would be even nicer for sbuild to not need setup that requires root. Stefano -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Re: Reviving schroot as used by sbuild
On Tue, 25 Jun 2024 at 18:55:45 +0200, Helmut Grohne wrote: > At least for me, building container images locally is a requirement. I > have no interest in using a container registry. I expected you'd say that. podman --rootfs is one way to use it without a registry; a trivially short Dockerfile like the one I mentioned, to convert a tarball into a container image locally, is another. (Debian's pseudo-official Docker images on Dockerhub use the latter.) But I think it would be great if some part of Debian - perhaps the cloud team? - could periodically publish genuinely official minbase sysroot tarballs and/or OCI images from Debian infrastructure, like the cloud team already does for VM images, which would avoid relying on a third-party registry while also avoiding requiring every developer to spend thought and CPU time on building their own before they can start on their actual development. > lxd/incus also was on my list, but my understanding is that they do not > work without their system services at all and being able to operate > containers (i.e. being incus-admin or the like) roughly becomes > equivalent to being full root on the system defeating the purpose of the > exercise. Perhaps, I haven't looked into lxd/incus in detail (podman seems to have the properties I wanted so I stopped there). I might have been misled by the fact that lxd can run rootless containers - but maybe it can only do that by making IPC requests to a privileged service, a bit like the way snapd operates. > I guess you understood my explanation differently than it was meant. > While the container is persisted into the filesystem, this is being done > for each package build individually. sbuild --chroot-mode=unshare and > unschroot use a tarball as their source and opening the session amounts > to extracting it. At the end of the session, the tree is disposed. The > session concept of schroot is being reused in unschroot and it very much > behaves like a type=file chroot except that you can begin a session, > reboot and continue using it until you end it without requiring a system > service to recover your sessions during boot. OK, good: this is "the same shape" as schroot type=file, which is not one of the modes that has the problems I described. If you're carrying over the underlying on-disk directory across reboots, you'll have to be a little careful about persisting state into that directory (only things that will still be true after a reboot can safely be stored), but I'm sure you're doing that. > The main difference to how everyone else does this is that in a typical > sbuild interaction it will create a new user namespace for every single > command run as part of the session. sbuild issues tens of commands > before launching dpkg-buildpackage and each of them creates new > namespaces in the Linux kernel (all of them using the same uid mappings, > performing the same bind mounts and so on). The most common way to think > of containers is different: You create those namespaces once and reuse > the same namespace kernel objects for multiple commands part of the same > session (e.g. installation of build dependencies and dpkg-buildpackage). Yes. My concern here is that there might be non-obvious reasons why everyone else is doing this the other way, which could lead to behavioural differences between unschroot and all the others that will come back to bite us later. > There two ways of > interacting with containers that use one set of namespaces for their > entire existence. One is setting up some IPC mechanism and receiving > commands to be run inside (for instance spawning a shell and piping > commands into it or driving the container via ssh) or an external > process joins (setns) the existing container (namespaces) and injects > code into it (docker exec). That latter approach has a history of > vulnerabilities closely related to vulnerabilities in setuid binaries, > because we are transitioning a process (and all of its context) from > outside the container into it and thus expose all of its context (memory > maps, open file descriptors and so on) to contained processes. As such, > I think that an approach based on an IPC mechanism should be preferred. An IPC-based approach is certainly going to provide better security hardening (especially if setuid helpers are used), and potentially better functionality as well. In Flatpak (which uses namespaces too, but is not really the same sort of container), the debugging command `flatpak enter` currently uses the setns approach (which comes with various limitations), and one of the items on my infinite to-do list is to make that be IPC-based instead, possibly by reusing code written for steam-runtime-tools during $dayjob. For whole-system containers running an OS image from init upwards, or for virtual machines, using ssh as the IPC mechanism seems pragmatic. Recent versions of systemd can even be given a ssh public key via the systemd.system-credentials(7) mechanism (
Re: Reviving schroot as used by sbuild
On Wed, Jun 26, 2024 at 1:11 PM Simon McVittie wrote: > > I don't think podman can do this within a single run. It might be feasible > to do the setup (installing build-dependencies) with networking enabled; > leave the root filesystem of that container intact; and reuse it as the > root filesystem of the container in which the actual build runs, this time > with --network=none? > > Or the "install build-dependencies" step (and other setup) could perhaps > even be represented as a `podman build` (with a Dockerfile/Containerfile, > FROM the image you had as your starting point), outputting a temporary > container image, in which the actual dpkg-buildpackage step can be invoked > by `podman run --network=none --rmi`? > > Lot's of things to catch up on for me, but I remember writing an article a few years ago related to this topic. I imagine that one could whip up some kind of wrapper that is building a container either from a tarball created via mmboostrap or similar using buildah, have it install all necessary build dependencies, and then use podman to run the actual build: https://tauware.blogspot.com/2020/04/building-packages-with-buildah-in-debian.html I also briefly started playing with debcraft, which I really like from a usability perspective. It clearly doesn't have all the bells and whistles that come with schroot, but I do like the fact that I can very easily enter into a container with the build results to play around and debug stuff. https://salsa.debian.org/otto/debcraft -- regards, Reinhard
Bug#1074349: ITP: meshtastic -- client shell for talking to Meshtastic devices
Package: wnpp Severity: wishlist Owner: Alex Myczko X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: meshtastic Version : 2.3.12 Upstream Authors: Meshtastic Developers URL : https://github.com/meshtastic/Meshtastic-python * License : GPL-3.0-only Description : client shell for talking to Meshtastic devices This is a Python client for use with Meshtastic devices. This small library (and example application) provides an easy API for sending and receiving messages over mesh radios. It also provides access to any of the operations/data available in the device user interface or the Android application. Events are delivered using a publish-subscribe model, and you can subscribe to only the message types you are interested in. . This package installs the library for Python 3.
