Re: proposal: dhcpcd-base as standard DHCP client starting with Trixie
Martin-Éric Racine writes: > On Mon, Jun 19, 2023 at 9:11 PM Santiago Ruano Rincón > wrote: >> El 19/06/23 a las 13:54, Martin-Éric Racine escribió: >> > Greetings, >> > >> > Seeing how the ISC DHCP suite has reached EOL upstream, now might be a >> > good time to re-visit Debian's choice of standard DHCP client shipping >> > with priority:important. >> > >> > I hereby propose bin:dhcpcd-base: >> > >> > 1) already supported by ifupdown. >> > 2) dual stack (DHCPv4, Bonjour, RA, DHCPv6 with PD) with privilege >> > separation. >> > 3) writes both IPv4 and IPv6 name servers to /etc/resolv.conf >> > 4) supports /etc/resolv.conf.head and /etc/resolv.conf.tail >> > 5) a mere inet line in /etc/network/interfaces is sufficient to >> > configure both stacks. >> ... >> >> I agree that dhcpcd seems the best alternative to isc-dhcp-client for >> the moment, and I'll make the relevant changes in ifupdown as soon as I >> can. Josué, any thoughts? > > 1) As someone pointed out in the thread, the reason why > isc-dhcp-client had priority:important probably was to ensure that > debootstrap would pull it, since debootstrap ignores Recommends and > packages with a priority lower than standard. > > 2) However, as long as ifupdown explictly depends on a package, it can > also pull dependencies with a lower priority. Right now ifupdown > Recommends "isc-dhcp-client | dhcp-client" which debootstrap would > ignore. It would have to Depends "dhcpcd-base | dhcp-client" instead. > > 3) At that point, swapping the priority of isc-dhcp-client and > dhcpcd-base merely becomes "nice to have". Heck, the priority of both > could, in principle, be optional, just as long as ifupdown explicitly > Depends on a DHCP client, and the first alternative is a real package. That would make the order of operations for a smooth migration as follows: 1. ifupdown switches from Recommends "isc-dhcp-client | dhcp-client" to Depends "isc-dhcp-client | dhcp-client". 2. isc-dhcp-client drops from Priority: important to Priority: optional 3. ifupdown switches from isc-dhcp-client to dhcpcd-base. -- Arto Jantunen
Re: RFP: virtme-ng -- Tool to build and run a kernel inside a virtualized snapshot of your live system
On Mon, Jun 19, 2023 at 09:54:41PM +0200, Ricardo Ribalda Delgado wrote:
> Hi
>
> I have updated my repo to uprev v1.10 and support argcomple3.
>
> https://salsa.debian.org/ribalda/virtme-ng/-/tree/debian
>
> Hector, Andrea, can you take a look at it?
>
> Hector the fun bits are at
> https://salsa.debian.org/ribalda/virtme-ng/-/merge_requests/1/diffs?commit_id=943dd90136e5e30fc39d0061347fea3bcbe44c4c
Reviewed and added some comments, thanks!
>
> Andrea: the build seems to be having issues with 32 bits:
> https://salsa.debian.org/ribalda/virtme-ng/-/jobs/4338837
Ah yes, I hit that yesterday as well:
https://launchpadlibrarian.net/673040751/buildlog_ubuntu-mantic-armhf.virtme-ng_1.12-1ubuntu1_BUILDING.txt.gz
Part of these errors are fixed by:
`879b4d4 ("virtme-ng-init: support 32-bit architectures")`
But there are still some 32-bit related errors, I'll push an additional
fix later today.
-Andrea
Re: proposal: dhcpcd-base as standard DHCP client starting with Trixie
On Mon, Jun 19, 2023 at 9:11 PM Santiago Ruano Rincón wrote: > El 19/06/23 a las 13:54, Martin-Éric Racine escribió: > > Greetings, > > > > Seeing how the ISC DHCP suite has reached EOL upstream, now might be a > > good time to re-visit Debian's choice of standard DHCP client shipping > > with priority:important. > > > > I hereby propose bin:dhcpcd-base: > > > > 1) already supported by ifupdown. > > 2) dual stack (DHCPv4, Bonjour, RA, DHCPv6 with PD) with privilege > > separation. > > 3) writes both IPv4 and IPv6 name servers to /etc/resolv.conf > > 4) supports /etc/resolv.conf.head and /etc/resolv.conf.tail > > 5) a mere inet line in /etc/network/interfaces is sufficient to > > configure both stacks. > ... > > I agree that dhcpcd seems the best alternative to isc-dhcp-client for > the moment, and I'll make the relevant changes in ifupdown as soon as I > can. Josué, any thoughts? 1) As someone pointed out in the thread, the reason why isc-dhcp-client had priority:important probably was to ensure that debootstrap would pull it, since debootstrap ignores Recommends and packages with a priority lower than standard. 2) However, as long as ifupdown explictly depends on a package, it can also pull dependencies with a lower priority. Right now ifupdown Recommends "isc-dhcp-client | dhcp-client" which debootstrap would ignore. It would have to Depends "dhcpcd-base | dhcp-client" instead. 3) At that point, swapping the priority of isc-dhcp-client and dhcpcd-base merely becomes "nice to have". Heck, the priority of both could, in principle, be optional, just as long as ifupdown explicitly Depends on a DHCP client, and the first alternative is a real package. Martin-Éric
FTBFS on all recent uploads
Hi. I have a FTBFS on all uploads after the end of the freeze. Example: https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/gap-aclib.html All these packages had been changed to compat 13. Unfortunately I have no idea why I get these. I can see two logs of successful builds and a diff for them. At the end of each log I find reproducible ➤ FTBFS, so this probably is because my build fails to be reproducible. However the only diff I see is the diff between the build logs. Any hints on what to do about these would be helpful. Thanks, Joachim
Bug#1038681: ITP: golang-github-bep-simplecobra -- simpler API for the popular Cobra CLI
Package: wnpp Severity: wishlist Owner: Anthony Fok * Package name: golang-github-bep-simplecobra Version : 0.3.2-1 Upstream Author : Bjørn Erik Pedersen * URL : https://github.com/bep/simplecobra * License : Expat Programming Lang: Go Description : simpler API for the popular Cobra CLI So, Cobra (https://github.com/spf13/cobra) is a Go CLI library with a feature set that's hard to resist for bigger applications (autocompletion, docs and man pages auto generation etc.). But it's also complex to use beyond the simplest of applications. This package was built to help rewriting Hugo's (https://github.com/gohugoio/hugo) commands package to something that's easier to understand and maintain. Reason for packaging: Needed by hugo v0.112.0 and up
Bug#1038680: ITP: golang-github-bep-helpers -- Go utils package with a less burdened name by @bep
Package: wnpp Severity: wishlist Owner: Anthony Fok * Package name: golang-github-bep-helpers Version : 0.4.0-1 Upstream Author : Bjørn Erik Pedersen * URL : https://github.com/bep/helpers * License : Expat Programming Lang: Go Description : Go utils package with a less burdened name by @bep Some helper packages with some helper code that Bjørn Erik Pedersen (@bep) has had a tendency to copy from project to project over the years, prompting him to consider some reuse and create this Go package. Reason for packaging: Needed by e.g. hugo v0.112.0 and up
Re: opencl-icd virtual package(s)?
(beignet's FTBFS is #974792, my previous attempts to fix it are in Salsa, and I was planning to remove it and accept that older hardware would only be able to use CPU (pocl) OpenCL. Please use that bug for further discussion of that.) I'd leave the loader packages alone, i.e. ocl-icd-libopencl1 stays the default, and the libopencl1 virtual package continues to exist. (And yes, loaders are not ICDs, so libreoffice Suggesting them as alternatives to each other is probably a bug.) For the actual ICDs themselves, yes, my proposal was to have a metapackage depending on all the DFSG-free ones, and also keep the existing opencl-icd virtual package. Paul Wise wrote: > maybe now is the time to do this, so that the problems can be found via bug reports? Simon Richter wrote: > Yes, but the others correctly report that no hardware can be found, and it's up to the application to disregard them. This generally works, because pocl also reports "no hardware can be found" if you ask for a GPU, so this is a well-tested code path. Not necessarily: not every application asks for a GPU (rather than 'any OpenCL device'), and if the application silently falls back to running without OpenCL on failure, it might not be obvious that it didn't find OpenCL when it should have done. Since ocl-icd 2.2.5, ocl-icd-libopencl1 sorts the ICDs to make the first one a reasonable default choice, which fixed some issues of this kind, but not all of them. These look like they'd still have issues: https://sources.debian.org/src/asl/0.1.7-4/src/acl/aclHardware.cxx/#L70 https://sources.debian.org/src/erlang-cl/1.2.4-1/c_src/cl_nif.c/#L6759 (maybe) https://sources.debian.org/src/ocl-icd/2.3.2-1/ocl_icd_loader.c/#L1249 (if the device type you ask for isn't the first platform's type) and there may be more.
Re: proposal: dhcpcd-base as standard DHCP client starting with Trixie
On 2023-06-19 21:37 +0100, Simon McVittie wrote: > On Mon, 19 Jun 2023 at 21:42:08 +0300, Martin-Éric Racine wrote: >> I've never had to do this before, so I wonder if moving packages to >> severity: standard or higher (in this case, important) requires any >> decision from the CTTE or a similar authority, before we proceed? > > Regarding *whether* to make that change: as Luca said, I don't think a > DHCP client really needs to be at an elevated Priority at all. I think > it would be better to lower the priority of isc-dhcp-client to optional, > but *not* raise the priority of dhcpcd-base, and instead have ifupdown > pull in the DHCP client of its choice (currently isc-dhcp-client, but > you'd prefer this to be dhcpcd-base) as a Recommends or Depends. > My understanding is that because ifupdown is (currently) > Priority: important, that dependency would still pull your chosen DHCP > client into a default debootstrap. Unfortunately that assumption is not correct, because ifupdown only "Recommends: isc-dhcp-client | dhcp-client", and debootstrap ignores Recommends. So as long as ifupdown is installed by debootstrap, either it would have to change that recommendation to "Depends: dhcpcd-base | dhcp-client", or the priority of dhcpcd-base needs to be bumped so that debootstrap picks it up due to its priority. > Years ago we had a rule in Policy that if package A depends on package B, > then the priority of B must be >= the priority of A; but we dropped that > rule, because it wasn't particularly helpful, and sometimes led to wrong > situations where packages get installed for no good reason. So there's no > need to follow that rule any more. As far as debootstrap is concerned, it only handles Depends, ignores everything but the first alternative and cannot deal with virtual packages. For dependencies on libraries computed by dpkg-shlibdeps this usually works, but manually inserted relationships do not always fulfill these constraints. > If you agree with the way forward that I'm suggesting, then I think the > way to do it would be: > > 1. open an override bug asking for isc-dhcp-client to be lowered from >important to optional > 2. wait for the ftp team to do that > 3. ask the ifupdown maintainer to switch the Recommends to point to >dhcpcd-base instead of isc-dhcp-client If my above statements about debootstrap are correct, this will result in no dhcp-client being installed at all by debootstrap unless the override bug also requests bumping dhcpcd-base's priority from optional to important. Cheers, Sven
Re: proposal: dhcpcd-base as standard DHCP client starting with Trixie
Am 19.06.23 um 22:37 schrieb Simon McVittie: If you agree with the way forward that I'm suggesting, then I think the way to do it would be: 1. open an override bug asking for isc-dhcp-client to be lowered from important to optional 2. wait for the ftp team to do that 3. ask the ifupdown maintainer to switch the Recommends to point to dhcpcd-base instead of isc-dhcp-client +1 OpenPGP_signature Description: OpenPGP digital signature
Re: proposal: dhcpcd-base as standard DHCP client starting with Trixie
On Mon, 19 Jun 2023 at 21:42:08 +0300, Martin-Éric Racine wrote: > I've never had to do this before, so I wonder if moving packages to > severity: standard or higher (in this case, important) requires any > decision from the CTTE or a similar authority, before we proceed? Regarding *whether* to make that change: as Luca said, I don't think a DHCP client really needs to be at an elevated Priority at all. I think it would be better to lower the priority of isc-dhcp-client to optional, but *not* raise the priority of dhcpcd-base, and instead have ifupdown pull in the DHCP client of its choice (currently isc-dhcp-client, but you'd prefer this to be dhcpcd-base) as a Recommends or Depends. My understanding is that because ifupdown is (currently) Priority: important, that dependency would still pull your chosen DHCP client into a default debootstrap. Years ago we had a rule in Policy that if package A depends on package B, then the priority of B must be >= the priority of A; but we dropped that rule, because it wasn't particularly helpful, and sometimes led to wrong situations where packages get installed for no good reason. So there's no need to follow that rule any more. Separately, regarding *how* to make that change: as an ordinary package maintainer you cannot change the Priority of an existing package either upward or downward yourself, you have to ask the ftp team to do it, via an 'override' bug. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1018690 is an example. It's up to the ftp team how they manage priorities, but how I imagine they do it is to make obvious/uncontroversial changes immediately, or check for distribution consensus (for example in a thread like this one) if the change is non-obvious or controversial. The technical committee doesn't generally get involved in this sort of thing unless there's a dispute that needs resolving, or some maintainer asks for advice. If you agree with the way forward that I'm suggesting, then I think the way to do it would be: 1. open an override bug asking for isc-dhcp-client to be lowered from important to optional 2. wait for the ftp team to do that 3. ask the ifupdown maintainer to switch the Recommends to point to dhcpcd-base instead of isc-dhcp-client (The reason I'm suggesting that sequence is that it avoids installing two DHCP clients in a default debootstrap, which would definitely be unnecessary.) smcv (without technical committee hat on in this case)
Re: RFP: virtme-ng -- Tool to build and run a kernel inside a virtualized snapshot of your live system
Hi I have updated my repo to uprev v1.10 and support argcomple3. https://salsa.debian.org/ribalda/virtme-ng/-/tree/debian Hector, Andrea, can you take a look at it? Hector the fun bits are at https://salsa.debian.org/ribalda/virtme-ng/-/merge_requests/1/diffs?commit_id=943dd90136e5e30fc39d0061347fea3bcbe44c4c Andrea: the build seems to be having issues with 32 bits: https://salsa.debian.org/ribalda/virtme-ng/-/jobs/4338837 Thanks! On Mon, Jun 19, 2023 at 2:27 PM Andrea Righi wrote: > > On Mon, Jun 19, 2023 at 02:15:51PM +0200, Héctor Orón Martínez wrote: > > Hello, > > > > On Mon, 19 Jun 2023 at 13:56, Andrea Righi > > wrote: > > > > > > On Mon, Jun 19, 2023 at 01:20:04PM +0200, Héctor Orón Martínez wrote: > > > > Hello Andrea, > > > > > > > > On Wed, 31 May 2023 at 20:47, Andrea Righi > > > > wrote: > > > > > > > > > On Mon, May 15, 2023 at 10:45:15PM +0200, Ricardo Ribalda Delgado > > > > > wrote: > > > > > > > > > > I think I have the first version of virtme-ng. > > > > > > > > > > > > @Héctor Orón Martínez can you help reviewing and pushing > > > > > > https://salsa.debian.org/ribalda/virtme-ng ? > > > > > > > > > > > > Maybe you could also create salsa.debian.org/debian/virtme-ng > > > > > > > > > > Is there any update on this? Anything I can do to help? > > > > > > > > I tried to build the package posted in the salsa repo, but failed for > > > > me, then I was unable to get back to this. Have you been able to > > > > review such a source tree? > > > > > > I'm able to build the package from Ricardo's repo. It's still at v1.6 > > > and upstream is already v1.10, but in general it looks good to me. > > > > > > What error did you get? > > > > I tried in a different machine now: > > > > register-python-argcomplete virtme-ng > virtme-ng-prompt > > /bin/sh: line 1: register-python-argcomplete: command not found > > > > This should be register-python-argcomplete3, solving that issue I was > > able to build it. > > Oh I see, in Ubuntu python3-argcomplete provides > register-python-argcomplete, while in Debian it's > register-python-argcomplete3. > > Not sure why it's different, maybe we should just do something like the > following to support both (if you like it I'll apply it upstream). > > Thanks for checking! > -Andrea > > debian/rules | 8 +++- > 1 file changed, 7 insertions(+), 1 deletion(-) > > diff --git a/debian/rules b/debian/rules > index db18ccd..0888cf2 100755 > --- a/debian/rules > +++ b/debian/rules > @@ -1,7 +1,13 @@ > #!/usr/bin/make -f > > +ARGCOMPLETE := $(shell command -v register-python-argcomplete3 2>/dev/null > || command -v register-python-argcomplete 2>/dev/null) > + > +ifeq ($(strip $(ARGCOMPLETE)),) > +$(error Neither register-python-argcomplete nor > register-python-argcomplete3 found in PATH) > +endif > + > virtme-ng-prompt: > - register-python-argcomplete virtme-ng vng > $@ > + $(ARGCOMPLETE) virtme-ng vng > $@ > > %: > dh $@ --with python3 --buildsystem=pybuild >
Re: proposal: dhcpcd-base as standard DHCP client starting with Trixie
On Mon, 19 Jun 2023 at 18:21, Philipp Kern wrote: > > On 2023-06-19 14:37, Luca Boccassi wrote: > > The advantage of doing that is that it's what Ubuntu does IIRC, so > > there will be extra pooling&sharing of resources to maintain those > > setups, and the road should already be paved for it. > > I am not sure if I have seen this play out in practice[1]. > Ubuntu^WCanonical has been doing its own development in this space as > well with netplan. Ubuntu will continue to do its own fixes to glue > things together. > > Kind regards > Philipp Kern > > [1] With notable exceptions like doko maintaining the toolchain - and > I'm sure I'm not crediting everyone. But that's also explicit package > maintainership. I've been working for a long time with many Canonical engineers, happily and fruitfully, to the benefit of both Debian and Ubuntu, so my experience is quite different. This includes the developers working on src:systemd. Kind regards, Luca Boccassi
Re: proposal: dhcpcd-base as standard DHCP client starting with Trixie
On Mon, 19 Jun 2023 at 20:00, Martin-Éric Racine wrote: > > On Mon, Jun 19, 2023 at 9:11 PM Santiago Ruano Rincón > wrote: > > El 19/06/23 a las 13:54, Martin-Éric Racine escribió: > > > Seeing how the ISC DHCP suite has reached EOL upstream, now might be a > > > good time to re-visit Debian's choice of standard DHCP client shipping > > > with priority:important. > > > > > > I hereby propose bin:dhcpcd-base: > > > > > > 1) already supported by ifupdown. > > > 2) dual stack (DHCPv4, Bonjour, RA, DHCPv6 with PD) with privilege > > > separation. > > > 3) writes both IPv4 and IPv6 name servers to /etc/resolv.conf > > > 4) supports /etc/resolv.conf.head and /etc/resolv.conf.tail > > > 5) a mere inet line in /etc/network/interfaces is sufficient to > > > configure both stacks. > > > > I agree that dhcpcd seems the best alternative to isc-dhcp-client for > > the moment, and I'll make the relevant changes in ifupdown as soon as I > > can. Josué, any thoughts? > > I've never had to do this before, so I wonder if moving packages to > severity: standard or higher (in this case, important) requires any > decision from the CTTE or a similar authority, before we proceed? As mentioned elsewhere in the thread, there shouldn't be any need to change the priority, adjusting ifupdown's dependencies should be all that's needed. Kind regards, Luca Boccassi
Re: proposal: dhcpcd-base as standard DHCP client starting with Trixie
On Mon, Jun 19, 2023 at 9:11 PM Santiago Ruano Rincón wrote: > El 19/06/23 a las 13:54, Martin-Éric Racine escribió: > > Seeing how the ISC DHCP suite has reached EOL upstream, now might be a > > good time to re-visit Debian's choice of standard DHCP client shipping > > with priority:important. > > > > I hereby propose bin:dhcpcd-base: > > > > 1) already supported by ifupdown. > > 2) dual stack (DHCPv4, Bonjour, RA, DHCPv6 with PD) with privilege > > separation. > > 3) writes both IPv4 and IPv6 name servers to /etc/resolv.conf > > 4) supports /etc/resolv.conf.head and /etc/resolv.conf.tail > > 5) a mere inet line in /etc/network/interfaces is sufficient to > > configure both stacks. > > I agree that dhcpcd seems the best alternative to isc-dhcp-client for > the moment, and I'll make the relevant changes in ifupdown as soon as I > can. Josué, any thoughts? I've never had to do this before, so I wonder if moving packages to severity: standard or higher (in this case, important) requires any decision from the CTTE or a similar authority, before we proceed? Martin-Éric
Re: proposal: dhcpcd-base as standard DHCP client starting with Trixie
Hi, El 19/06/23 a las 13:54, Martin-Éric Racine escribió: > Greetings, > > Seeing how the ISC DHCP suite has reached EOL upstream, now might be a > good time to re-visit Debian's choice of standard DHCP client shipping > with priority:important. > > I hereby propose bin:dhcpcd-base: > > 1) already supported by ifupdown. > 2) dual stack (DHCPv4, Bonjour, RA, DHCPv6 with PD) with privilege separation. > 3) writes both IPv4 and IPv6 name servers to /etc/resolv.conf > 4) supports /etc/resolv.conf.head and /etc/resolv.conf.tail > 5) a mere inet line in /etc/network/interfaces is sufficient to > configure both stacks. ... I agree that dhcpcd seems the best alternative to isc-dhcp-client for the moment, and I'll make the relevant changes in ifupdown as soon as I can. Josué, any thoughts? Cheers, -- S signature.asc Description: PGP signature
Re: proposal: dhcpcd-base as standard DHCP client starting with Trixie
On Mon, 19 Jun 2023 at 14:13:11 +0200, Ansgar wrote: > On Mon, 2023-06-19 at 13:35 +0200, Michael Biebl wrote: > > Why does isc-dhcp-client have priority:important to begin with? > > I don't think users care so much about a dhcp client but rather a > > network configuration system > > The priority question isn't the important one. The real question is: > > What network configuration system should users end up with (by > default)? Yes, whatever DHCP client ifupdown would prefer to use, that seems like an implementation detail of ifupdown: it should pull it in via an appropriate level of dependency, and that's orthogonal to whether a particular class of installation has its networking managed by ifupdown, NetworkManager, systemd-networkd or something else by default. At the moment I believe the status quo for d-i is that networking is managed by NetworkManager if a desktop task happens to have pulled it in, or ifupdown otherwise? And that seems reasonable (although I personally prefer to set up systemd-networkd on servers). Of our desktop tasks, all except possibly LXDE and LXQT pull in NetworkManager via Recommends or stronger, which seems right. LXDE and LXQT might pull in connman as a higher preference than NM, via an alternative dependency that includes connman-gtk or cmst: it's not immediately obvious to me what actually happens, and I don't have a recent installation of either one to look at right now. The other possible reason to have a DHCP client is for recovery, but most bootable Debian systems will have busybox (via Recommends from initramfs-tools-core), and that has a small DHCP client included anyway. > I also think that installing both ifupdown and NetworkManager on > desktop environments is worse than only NM. ifupdown should be fairly harmless when not configured to manage any non-loopback interfaces (which is what d-i does when NM is installed), but I agree that it seems better not to have it if it's not needed. smcv
Re: proposal: dhcpcd-base as standard DHCP client starting with Trixie
On 2023-06-19 14:37, Luca Boccassi wrote: The advantage of doing that is that it's what Ubuntu does IIRC, so there will be extra pooling&sharing of resources to maintain those setups, and the road should already be paved for it. I am not sure if I have seen this play out in practice[1]. Ubuntu^WCanonical has been doing its own development in this space as well with netplan. Ubuntu will continue to do its own fixes to glue things together. Kind regards Philipp Kern [1] With notable exceptions like doko maintaining the toolchain - and I'm sure I'm not crediting everyone. But that's also explicit package maintainership.
Re: New deprecation warning in CMake 3.27
Hi Kyle, * Kyle Edwards [2023-06-19 09:18]: CMake upstream here. We do have a tutorial that we've put together and improved over the last few years that teaches modern CMake and avoids using the old directory-level commands. You can find it here: https://cmake.org/cmake/help/latest/guide/tutorial I agree that tutorial has improved over the last years. If you have a cmake_minimum_required() that's older than some of the commands you're using, the expected pattern to avoid using them is: if(NOT CMAKE_VERSION VERSION_LESS 3.25) # Version-gated code here endif() Still, I need to be *aware* that a particular command is newer than my targeted minimum version. I'm really glad that you added the version info to the documentation with CMake 3.20, but it is still manual labor. Maybe there is a linter for that, though, I did not check. More elegant is a version range: if your script does not give any policy warnings with a recent CMake (say CMake 3.26), you can write something like "cmake_minimum_required(VERSION 3.0...3.26)" Please keep in mind that if you set an upper bound, any policies up to that upper bound will automatically be set to NEW, so be sure that your code is ready for that. You could potentially get some unexpected behavior if you have code that uses the OLD behavior of a policy in an older version of CMake and the NEW behavior in a newer version. You are absolutely right, and that is what I meant to convey with "does not give any policy warnings": If the newer CMake warns you that your script relies on some OLD behavior, you need to address that first. That also implies that you cannot bump the upper bound beyond a version you have actually tested. Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Re: New deprecation warning in CMake 3.27
On 6/17/23 12:29, Timo Röhling wrote: Being backwards compatible is CMake's greatest blessing and greatest curse at the same time, because people still run into crappy, 20 year old tutorials and needlessly complicated (but working) code snippets from CMake 2.x on the Internet, making them believe that CMake is crappy and needlessly complicated. It is better than its reputation. It does lack good, recent tutorials though. CMake upstream here. We do have a tutorial that we've put together and improved over the last few years that teaches modern CMake and avoids using the old directory-level commands. You can find it here: https://cmake.org/cmake/help/latest/guide/tutorial Can you recommend a relatively safe & old version to use instead of < 3.5 which doesn't need bumping next month but is also available in most semi-current releases of all major distributions (as that is what most upstreams will care about if they don't have special needs)? The *correct* minimum version is actually not that easy to determine, because CMake, for some reason, will let you say "cmake_minimum_required(VERSION 3.0)" and still use newer commands such as "add_link_options" (introduced in CMake 3.13) without warning. If you have a cmake_minimum_required() that's older than some of the commands you're using, the expected pattern to avoid using them is: if(NOT CMAKE_VERSION VERSION_LESS 3.25) # Version-gated code here endif() Speaking of 3.13, Buster aka oldoldstable ships with CMake 3.13 (released in 2018) and Repology tells me that any relevant distribution with an older CMake is either completely unsupported or you need to buy LTS for it. That sounds like a reasonable support baseline to me. More elegant is a version range: if your script does not give any policy warnings with a recent CMake (say CMake 3.26), you can write something like "cmake_minimum_required(VERSION 3.0...3.26)", which will continue to work with old CMake releases but not trigger any support warnings for the forseeable future, because only the upper bound is considered for that. Please keep in mind that if you set an upper bound, any policies up to that upper bound will automatically be set to NEW, so be sure that your code is ready for that. You could potentially get some unexpected behavior if you have code that uses the OLD behavior of a policy in an older version of CMake and the NEW behavior in a newer version. Kyle
Processed: reassign 1038627 to pipewire
Processing commands for cont...@bugs.debian.org: > reassign 1038627 pipewire Bug #1038627 [general] general: Various applications log PipeWire-related errors on a Bookworm system using PulseAudio. Bug reassigned from package 'general' to 'pipewire'. Ignoring request to alter found versions of bug #1038627 to the same values previously set Ignoring request to alter fixed versions of bug #1038627 to the same values previously set > thanks Stopping processing here. Please contact me if you need assistance. -- 1038627: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1038627 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1038627: general: Various applications log PipeWire-related errors on a Bookworm system using PulseAudio.
Quoting splashed_overbuilt...@simplelogin.com (2023-06-19 14:31:11) > Thank you. Yes, I've read that page a couple of times before. And today I've > come to conclusion about replacing wireplumber with pipewire-media-session > after looking into its contents one more time. > > Although, it's worth pointing out that the page is probably out-of-date, > because it considers Debian 11 a stable version, when in fact it's already > oldstable and Debian 12 is stable. It is a wiki: You are quite welcome to help improve/update the page :-) - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: RFP: virtme-ng -- Tool to build and run a kernel inside a virtualized snapshot of your live system
On Mon, Jun 19, 2023 at 02:15:51PM +0200, Héctor Orón Martínez wrote: > Hello, > > On Mon, 19 Jun 2023 at 13:56, Andrea Righi wrote: > > > > On Mon, Jun 19, 2023 at 01:20:04PM +0200, Héctor Orón Martínez wrote: > > > Hello Andrea, > > > > > > On Wed, 31 May 2023 at 20:47, Andrea Righi > > > wrote: > > > > > > > On Mon, May 15, 2023 at 10:45:15PM +0200, Ricardo Ribalda Delgado wrote: > > > > > > > > I think I have the first version of virtme-ng. > > > > > > > > > > @Héctor Orón Martínez can you help reviewing and pushing > > > > > https://salsa.debian.org/ribalda/virtme-ng ? > > > > > > > > > > Maybe you could also create salsa.debian.org/debian/virtme-ng > > > > > > > > Is there any update on this? Anything I can do to help? > > > > > > I tried to build the package posted in the salsa repo, but failed for > > > me, then I was unable to get back to this. Have you been able to > > > review such a source tree? > > > > I'm able to build the package from Ricardo's repo. It's still at v1.6 > > and upstream is already v1.10, but in general it looks good to me. > > > > What error did you get? > > I tried in a different machine now: > > register-python-argcomplete virtme-ng > virtme-ng-prompt > /bin/sh: line 1: register-python-argcomplete: command not found > > This should be register-python-argcomplete3, solving that issue I was > able to build it. Oh I see, in Ubuntu python3-argcomplete provides register-python-argcomplete, while in Debian it's register-python-argcomplete3. Not sure why it's different, maybe we should just do something like the following to support both (if you like it I'll apply it upstream). Thanks for checking! -Andrea debian/rules | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/debian/rules b/debian/rules index db18ccd..0888cf2 100755 --- a/debian/rules +++ b/debian/rules @@ -1,7 +1,13 @@ #!/usr/bin/make -f +ARGCOMPLETE := $(shell command -v register-python-argcomplete3 2>/dev/null || command -v register-python-argcomplete 2>/dev/null) + +ifeq ($(strip $(ARGCOMPLETE)),) +$(error Neither register-python-argcomplete nor register-python-argcomplete3 found in PATH) +endif + virtme-ng-prompt: - register-python-argcomplete virtme-ng vng > $@ + $(ARGCOMPLETE) virtme-ng vng > $@ %: dh $@ --with python3 --buildsystem=pybuild
Bug#1038627: general: Various applications log PipeWire-related errors on a Bookworm system using PulseAudio.
Thank you. Yes, I've read that page a couple of times before. And today I've come to conclusion about replacing wireplumber with pipewire-media-session after looking into its contents one more time. Although, it's worth pointing out that the page is probably out-of-date, because it considers Debian 11 a stable version, when in fact it's already oldstable and Debian 12 is stable. Yura > In case you are not already aware of it, I suggest to read through this > wiki page: https://wiki.debian.org/PipeWire > > In my opinion the above page provides a nice overview of what parts of > PipeWire relates to audio - and therefore needs to be avoided/reverted > if used together with Pulseaudio.
Re: proposal: dhcpcd-base as standard DHCP client starting with Trixie
On Mon, 19 Jun 2023 at 13:13, Ansgar wrote: > > On Mon, 2023-06-19 at 13:35 +0200, Michael Biebl wrote: > > Why does isc-dhcp-client have priority:important to begin with? > > I don't think users care so much about a dhcp client but rather a > > network configuration system and each network configuration system > > has its own preferred dhcp implementation e.g NetworkManager no > > longer uses isc-dhcp-client by default and systemd-networkd doesn't > > use isc-dhcp-client either. > > > > So maybe simply demoting the priority of isc-dhcp-client to normal is > > a better route. > > ifupdown already recommends isc-dhcp-client and if ifupdown want's to > > use dhcpcd in the future it could change this recommends. > > The priority question isn't the important one. The real question is: > > What network configuration system should users end up with (by > default)? > > I think this should be NetworkManager for desktop environments and I > personally like systemd-networkd for other environments. In both cases > these replace both ifupdown and isc-dhcp-client. > > I also think that installing both ifupdown and NetworkManager on > desktop environments is worse than only NM. The advantage of doing that is that it's what Ubuntu does IIRC, so there will be extra pooling&sharing of resources to maintain those setups, and the road should already be paved for it. Kind regards, Luca Boccassi
Bug#1038640: ITP: vkmark -- Vulkan benchmarking tool
Package: wnpp Severity: wishlist Owner: Arnaud Ferraris X-Debbugs-Cc: debian-devel@lists.debian.org, aferra...@debian.org, debia...@lists.debian.org * Package name: vkmark Version : 2017.08+git20220909 Upstream Contact: Alexandros Frantzis * URL : https://github.com/vkmark/vkmark * License : LGPL Programming Lang: C++ Description : Vulkan benchmarking tool vkmark is an extensible Vulkan benchmarking suite with targeted, configurable scenes. It provides an interesting alternative to glmark2 for Vulkan-capable systems. I plan to maintain this package within the debian-x team.
Re: RFP: virtme-ng -- Tool to build and run a kernel inside a virtualized snapshot of your live system
Hello, On Mon, 19 Jun 2023 at 13:56, Andrea Righi wrote: > > On Mon, Jun 19, 2023 at 01:20:04PM +0200, Héctor Orón Martínez wrote: > > Hello Andrea, > > > > On Wed, 31 May 2023 at 20:47, Andrea Righi > > wrote: > > > > > On Mon, May 15, 2023 at 10:45:15PM +0200, Ricardo Ribalda Delgado wrote: > > > > > > I think I have the first version of virtme-ng. > > > > > > > > @Héctor Orón Martínez can you help reviewing and pushing > > > > https://salsa.debian.org/ribalda/virtme-ng ? > > > > > > > > Maybe you could also create salsa.debian.org/debian/virtme-ng > > > > > > Is there any update on this? Anything I can do to help? > > > > I tried to build the package posted in the salsa repo, but failed for > > me, then I was unable to get back to this. Have you been able to > > review such a source tree? > > I'm able to build the package from Ricardo's repo. It's still at v1.6 > and upstream is already v1.10, but in general it looks good to me. > > What error did you get? I tried in a different machine now: register-python-argcomplete virtme-ng > virtme-ng-prompt /bin/sh: line 1: register-python-argcomplete: command not found This should be register-python-argcomplete3, solving that issue I was able to build it. Regards -- Héctor Orón -.. . -... .. .- -. -.. . ...- . .-.. --- .--. . .-.
Re: proposal: dhcpcd-base as standard DHCP client starting with Trixie
On Mon, 2023-06-19 at 13:35 +0200, Michael Biebl wrote: > Why does isc-dhcp-client have priority:important to begin with? > I don't think users care so much about a dhcp client but rather a > network configuration system and each network configuration system > has its own preferred dhcp implementation e.g NetworkManager no > longer uses isc-dhcp-client by default and systemd-networkd doesn't > use isc-dhcp-client either. > > So maybe simply demoting the priority of isc-dhcp-client to normal is > a better route. > ifupdown already recommends isc-dhcp-client and if ifupdown want's to > use dhcpcd in the future it could change this recommends. The priority question isn't the important one. The real question is: What network configuration system should users end up with (by default)? I think this should be NetworkManager for desktop environments and I personally like systemd-networkd for other environments. In both cases these replace both ifupdown and isc-dhcp-client. I also think that installing both ifupdown and NetworkManager on desktop environments is worse than only NM. Ansgar
Bug#1038627: general: Various applications log PipeWire-related errors on a Bookworm system using PulseAudio.
Quoting splashed_overbuilt...@simplelogin.com (2023-06-19 12:55:14) > I've noticed that if pipewire.service is running, it'll prevent pulseaudio > from handling audio sub-system. So maybe it should be disabled together with > its pipewire.socket? The main question that still remains is that GNU/Linux > distributions somehow worked without PipeWire and there weren't such issues. > If the system already uses PulseAudio, what other components have to be > installed/configured to properly replace also the PipeWire video capturing > part? In case you are not already aware of it, I suggest to read through this wiki page: https://wiki.debian.org/PipeWire In my opinion the above page provides a nice overview of what parts of PipeWire relates to audio - and therefore needs to be avoided/reverted if used together with Pulseaudio. Kind regards, - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: RFP: virtme-ng -- Tool to build and run a kernel inside a virtualized snapshot of your live system
On Mon, Jun 19, 2023 at 01:20:04PM +0200, Héctor Orón Martínez wrote: > Hello Andrea, > > On Wed, 31 May 2023 at 20:47, Andrea Righi wrote: > > > On Mon, May 15, 2023 at 10:45:15PM +0200, Ricardo Ribalda Delgado wrote: > > > > I think I have the first version of virtme-ng. > > > > > > @Héctor Orón Martínez can you help reviewing and pushing > > > https://salsa.debian.org/ribalda/virtme-ng ? > > > > > > Maybe you could also create salsa.debian.org/debian/virtme-ng > > > > Is there any update on this? Anything I can do to help? > > I tried to build the package posted in the salsa repo, but failed for > me, then I was unable to get back to this. Have you been able to > review such a source tree? I'm able to build the package from Ricardo's repo. It's still at v1.6 and upstream is already v1.10, but in general it looks good to me. What error did you get? -Andrea
Bug#1038627: general: Various applications log PipeWire-related errors on a Bookworm system using PulseAudio.
UPD: for anyone facing the same issue. Most likely PipeWire for non-audio use-cases was in active use at least from Debian 11, or even earlier, and it totally makes sense to leave it installed and enabled in Debian 12 too. So to resolve the problem it was enough to follow these steps: 1. Ensure that pipewire and pipewire-media-session packages (without recommended packages) are installed. 2. Their services are enabled and running. 3. Reboot (optional). The PipeWire error log entries mentioned in the ticket description should no longer be added. Apparently, if the wireplumber session manager is used instead of pipewire-media-session, it'll try to take over the responsibility for audio subsystem as well. And, of course, it's not what we need, since the goal is for PulseAudio to keep fulfilling the respective role. As a side-note, after PipeWire issues, like the ones described in this ticket: https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3284 , are resolved in new versions of Debian packages, such steps as well as PulseAudio presence will no longer be necessary. Yura
Re: proposal: dhcpcd-base as standard DHCP client starting with Trixie
On Mon, 19 Jun 2023 at 12:36, Michael Biebl wrote: > > Am 19.06.23 um 12:54 schrieb Martin-Éric Racine: > > Greetings, > > > > Seeing how the ISC DHCP suite has reached EOL upstream, now might be a > > good time to re-visit Debian's choice of standard DHCP client shipping > > with priority:important. > > > > I hereby propose bin:dhcpcd-base: > > > > 1) already supported by ifupdown. > > 2) dual stack (DHCPv4, Bonjour, RA, DHCPv6 with PD) with privilege > > separation. > > 3) writes both IPv4 and IPv6 name servers to /etc/resolv.conf > > 4) supports /etc/resolv.conf.head and /etc/resolv.conf.tail > > 5) a mere inet line in /etc/network/interfaces is sufficient to > > configure both stacks. > > > > While dhcpcd development became somewhat erratic last year due to > > upstream's health issues, things are seemingly back to normal. > > Additionally, a new developer has joined and is willing to take over > > the development should upstream's health deteriorate again. > > > > Why does isc-dhcp-client have priority:important to begin with? > I don't think users care so much about a dhcp client but rather a > network configuration system and each network configuration system has > its own preferred dhcp implementation e.g NetworkManager no longer uses > isc-dhcp-client by default and systemd-networkd doesn't use > isc-dhcp-client either. > > So maybe simply demoting the priority of isc-dhcp-client to normal is a > better route. > ifupdown already recommends isc-dhcp-client and if ifupdown want's to > use dhcpcd in the future it could change this recommends. Yes, this sounds like a better approach to me as well. Kind regards, Luca Boccassi
Re: proposal: dhcpcd-base as standard DHCP client starting with Trixie
Am 19.06.23 um 12:54 schrieb Martin-Éric Racine: Greetings, Seeing how the ISC DHCP suite has reached EOL upstream, now might be a good time to re-visit Debian's choice of standard DHCP client shipping with priority:important. I hereby propose bin:dhcpcd-base: 1) already supported by ifupdown. 2) dual stack (DHCPv4, Bonjour, RA, DHCPv6 with PD) with privilege separation. 3) writes both IPv4 and IPv6 name servers to /etc/resolv.conf 4) supports /etc/resolv.conf.head and /etc/resolv.conf.tail 5) a mere inet line in /etc/network/interfaces is sufficient to configure both stacks. While dhcpcd development became somewhat erratic last year due to upstream's health issues, things are seemingly back to normal. Additionally, a new developer has joined and is willing to take over the development should upstream's health deteriorate again. Why does isc-dhcp-client have priority:important to begin with? I don't think users care so much about a dhcp client but rather a network configuration system and each network configuration system has its own preferred dhcp implementation e.g NetworkManager no longer uses isc-dhcp-client by default and systemd-networkd doesn't use isc-dhcp-client either. So maybe simply demoting the priority of isc-dhcp-client to normal is a better route. ifupdown already recommends isc-dhcp-client and if ifupdown want's to use dhcpcd in the future it could change this recommends. Regards, Michael OpenPGP_signature Description: OpenPGP digital signature
Re: RFP: virtme-ng -- Tool to build and run a kernel inside a virtualized snapshot of your live system
Hello Andrea, On Wed, 31 May 2023 at 20:47, Andrea Righi wrote: > On Mon, May 15, 2023 at 10:45:15PM +0200, Ricardo Ribalda Delgado wrote: > > I think I have the first version of virtme-ng. > > > > @Héctor Orón Martínez can you help reviewing and pushing > > https://salsa.debian.org/ribalda/virtme-ng ? > > > > Maybe you could also create salsa.debian.org/debian/virtme-ng > > Is there any update on this? Anything I can do to help? I tried to build the package posted in the salsa repo, but failed for me, then I was unable to get back to this. Have you been able to review such a source tree? Regards > > >> > El mar, 9 de may de 2023, 07:54, Emmanuel Arias > > >> > escribió: > > >> >> > > >> >> Oh, I did not note/check that virtme already exists in Debian. > > >> >> > > >> >> Anyway, I am interest in the package, so I will follow > > >> >> virtme/virme-ng project :-) > > >> >> > > >> >> El mar, 9 de may de 2023, 07:49, Ricardo Ribalda Delgado > > >> >> escribió: > > >> >>> > > >> >>> On Tue, May 9, 2023 at 12:46 PM Andrea Righi > > >> >>> wrote: > > >> >>> > > > >> >>> > On Tue, May 09, 2023 at 11:32:59AM +0200, Ricardo Ribalda Delgado > > >> >>> > wrote: > > >> >>> > > Hi > > >> >>> > > > > >> >>> > > > > >> >>> > > On Tue, May 9, 2023 at 11:28 AM Héctor Orón Martínez > > >> >>> > > wrote: > > >> >>> > > > > > >> >>> > > > Hello, > > >> >>> > > > > > >> >>> > > > El mar, 9 may 2023, 9:51, Andrea Righi > > >> >>> > > > escribió: > > >> >>> > > >> > > >> >>> > > >> On Tue, May 09, 2023 at 09:30:54AM +0200, Héctor Orón > > >> >>> > > >> Martínez wrote: > > >> >>> > > >> > Hello, > > >> >>> > > >> > > > >> >>> > > >> > virtme already exists in Debian, what would be the > > >> >>> > > >> > benefit of virtme-ng > > >> >>> > > >> > over virtme? > > >> >>> > > >> > > > >> >>> > > >> > https://salsa.debian.org/debian/virtme > > >> >>> > > >> > > > >> >>> > > >> > Regards > > >> >>> > > >> > > >> >>> > > >> The original virtme project is not maintained anymore > > >> >>> > > >> (https://github.com/amluto/virtme), so we decided to fork the > > >> >>> > > >> project > > >> >>> > > >> and continue the development / bug fixing in virtme-ng > > >> >>> > > >> (https://github.com/arighi/virtme-ng). > > >> >>> > > >> > > >> >>> > > >> Some people are already using and contributing to virtme-ng > > >> >>> > > >> and there > > >> >>> > > >> are plans to package it in SuSE. > > >> >>> > > >> > > >> >>> > > >> Honestly I don't know what would be the right procedure to > > >> >>> > > >> "obsolete" > > >> >>> > > >> the old virtme package and replace it virtme-ng (if > > >> >>> > > >> possible), but > > >> >>> > > >> ideally it would be nice to do something like this. Any > > >> >>> > > >> guidance or > > >> >>> > > >> suggestion is welcome. > > >> >>> > > > > > >> >>> > > > > > >> >>> > > > I suggest we evaluate switching upstream from virtme to > > >> >>> > > > virtme-ng, on the Debian virtme package. I would not mind if > > >> >>> > > > you want to be added as uploader for the package. > > >> >>> > > > > > >> >>> > > > Ricardo has been working on virtme. What do you think? > > >> >>> > > > > >> >>> > > SGTM. Maybe we can send an email out of courtesy to the old > > >> >>> > > virtme author. > > >> >>> > > > >> >>> > All good to me as well! I already sent an email to the virtme > > >> >>> > author > > >> >>> > (Andrew Lutomirski) to inform him that I was forking the project, > > >> >>> > but I > > >> >>> > didn't get any response. > > >> >>> > > >> >>> That sounds good. > > >> >>> > > >> >>> > > > >> >>> > Maybe I can try to ping him again and see if he's also happy about > > >> >>> > this > > >> >>> > plan. > > >> >>> > > >> >>> May I suggest that when you ping them, tell them about the plans to > > >> >>> replace virtme with virtme-ng on Debian and put me on cc? > > >> >>> > > >> >>> Thanks! > > >> >>> > > >> >>> > > >> >>> > > > >> >>> > -Andrea -- Héctor Orón -.. . -... .. .- -. -.. . ...- . .-.. --- .--. . .-.
proposal: dhcpcd-base as standard DHCP client starting with Trixie
Greetings, Seeing how the ISC DHCP suite has reached EOL upstream, now might be a good time to re-visit Debian's choice of standard DHCP client shipping with priority:important. I hereby propose bin:dhcpcd-base: 1) already supported by ifupdown. 2) dual stack (DHCPv4, Bonjour, RA, DHCPv6 with PD) with privilege separation. 3) writes both IPv4 and IPv6 name servers to /etc/resolv.conf 4) supports /etc/resolv.conf.head and /etc/resolv.conf.tail 5) a mere inet line in /etc/network/interfaces is sufficient to configure both stacks. While dhcpcd development became somewhat erratic last year due to upstream's health issues, things are seemingly back to normal. Additionally, a new developer has joined and is willing to take over the development should upstream's health deteriorate again. Martin-Éric
Bug#1038627: general: Various applications log PipeWire-related errors on a Bookworm system using PulseAudio.
I've noticed that if pipewire.service is running, it'll prevent pulseaudio from handling audio sub-system. So maybe it should be disabled together with its pipewire.socket? The main question that still remains is that GNU/Linux distributions somehow worked without PipeWire and there weren't such issues. If the system already uses PulseAudio, what other components have to be installed/configured to properly replace also the PipeWire video capturing part? Yura --- Original Message --- On Monday, June 19th, 2023 at 13:08, Simon McVittie - smcv at debian.org wrote: > Pipewire is not just for audio, it's also used for video capture > (that's why xdg-desktop-portal needs it, and the same is probably true > for other applications). > > To disable the audio side of Pipewire, my understanding is that it should > be sufficient to remove pipewire-pulse, pipewire-alsa, pipewire-jack > and libspa-0.2-bluetooth, while leaving pipewire and wireplumber installed. > > smcv
Bug#1038627: general: Various applications log PipeWire-related errors on a Bookworm system using PulseAudio.
Thank you for the repsonse, Simon! Should the pipewire service be left enabled, or it's better to disable it after the pipewire and wireplumber packages are installed? Will it cause conflicts with PulseAudio if both are enabled? Yura --- Original Message --- On Monday, June 19th, 2023 at 13:08, Simon McVittie - smcv at debian.org wrote: > On Mon, 19 Jun 2023 at 10:47:49 +0300, Yura wrote: > > > After upgrade to Bookworm, due to certain limitations of the current > > PipeWire implementation I had to switch to PulseAudio. The switch was > > done by installing pulseaudio package, deleting all PipeWire packages and > > finally enabling pulseaudio service on a user level. > > > Pipewire is not just for audio, it's also used for video capture > (that's why xdg-desktop-portal needs it, and the same is probably true > for other applications). > > To disable the audio side of Pipewire, my understanding is that it should > be sufficient to remove pipewire-pulse, pipewire-alsa, pipewire-jack > and libspa-0.2-bluetooth, while leaving pipewire and wireplumber installed. > > smcv
Bug#1038627: general: Various applications log PipeWire-related errors on a Bookworm system using PulseAudio.
On Mon, 19 Jun 2023 at 10:47:49 +0300, Yura wrote: > After upgrade to Bookworm, due to certain limitations of the current > PipeWire implementation I had to switch to PulseAudio. The switch was > done by installing pulseaudio package, deleting all PipeWire packages and > finally enabling pulseaudio service on a user level. Pipewire is not just for audio, it's also used for video capture (that's why xdg-desktop-portal needs it, and the same is probably true for other applications). To disable the audio side of Pipewire, my understanding is that it should be sufficient to remove pipewire-pulse, pipewire-alsa, pipewire-jack and libspa-0.2-bluetooth, while leaving pipewire and wireplumber installed. smcv
Re: [Pkg-opencl-devel] opencl-icd virtual package(s)?
At the risk of stating the obvious, OpenCL seems to be "the same shape"
as many other GPU-related APIs like GLX, EGL, Vulkan, VA-API and VDPAU:
- applications link to a loader library
- the loader library dlopens a concrete implementation of OpenCL
(an "ICD", Installable Client Driver)
- hopefully it chooses an ICD that will work on your hardware
- most ICDs are specific to a class of hardware, for instance one for all
AMD GPUs
- there is one ICD that runs on the CPU and has no special GPU requirements
(for GL this is llvmpipe, for Vulkan it's lavapipe, for OpenCL it's pocl)
Given that, it would probably make sense for the packaging of OpenCL to be
"the same shape" as the other GPU-related APIs.
As far as I understand it, there are two different models in the
graphics world:
- in GLX, EGL, VA-API and VDPAU, only one ICD gets loaded (hopefully the
right one)
- in Vulkan, every ICD gets loaded, and ICDs for hardware you don't have
are expected to report "no supported devices" in a graceful way; and
if you have more than one ICD supporting the same hardware, or more than
one GPU, or a software driver like lavapipe, then the application is
offered a choice between all the possible devices and will hopefully
choose an appropriate one to render on
It sounds as though OpenCL is more similar to Vulkan here?
It seems unfortunate that ocl-icd-libopencl1 has "icd" in its name,
but is not an ICD (instead it's an ICD loader). I believe that's because
ocl-icd is the source package name?
On Mon, 19 Jun 2023 at 13:01:21 +0900, Simon Richter wrote:
> Since these provide a shared library with a fixed name, the ICD loaders
> either need to conflict or provide alternatives.
Is there an obvious "best" loader - perhaps ocl-icd-libopencl1 - that
we can choose to be the only one that Debian supports, similar to
the way we use GLVND for GLX/EGL and the reference Vulkan-Loader for
Vulkan? It seems to me that the ecosystem would be simpler if the ICDs,
which should in principle be the only thing that is hardware-specific,
were the only thing that involves a choice.
(In particular, NVIDIA ship their own binary build of an unknown and
possibly patched version of GLVND with their drivers, but we don't
package that: we use the one built by us from src:libglvnd instead.)
On Mon, 19 Jun 2023 at 12:10:22 +0800, Paul Wise wrote:
> Package: some-opencl-using-package
> Recommends: opencl-icd-all | opencl-icd
Presumably it should also depend on ocl-icd-libopencl1 | libopencl1,
via ${shlibs:Depends}, since it will link to libOpenCL.so.1 and that's
usually going to be a hard dependency?
Perhaps it should be the loader that has a Recommends or Depends on
a selection of suitably high-quality Free ICDs?
In GLX and EGL, the loader Depends on Mesa's ICD.
In Vulkan, the loader Recommends Mesa's ICDs (there are several in one
package).
OpenCL is a bit more complicated than GLX/EGL/Vulkan here because the
Intel and on-CPU OpenCL drivers aren't part of Mesa, so there is no
completely obvious choice; so I agree that a metapackage that pulls in
all the (sufficiently high-quality) Free ICDs is probably useful to have.
> Depends:
> opencl-icd-all-free,
> nvidia-legacy-340xx-opencl-icd,
> nvidia-legacy-390xx-opencl-icd,
> nvidia-opencl-icd,
I'm not sure this is a good idea: having multiple versions of the
NVIDIA proprietary driver installed at the same time doesn't seem very
supportable, since only one of them (the one that matches the loaded
kernel module) will actually work.
Instead, I think nvidia*-driver-libs should probably pull in the
appropriate NVIDIA OpenCL ICD as a Depends/Recommends/Suggests (depending
on how important Debian considers OpenCL to be), the same way it currently
pulls in GLX and EGL as Depends, and GLES and Vulkan as Suggests.
Are there any significant proprietary OpenCL drivers other than NVIDIA's?
> > I have proposed this before (see 31-Jan-2015 pkg-opencl-devel), but
> > never actually did it, partly because there are applications that
> > implicitly assume that all the installed ICDs work, and may fail to find
> > the usable ICD if there are unusable ones installed. (I consider this
> > to be a bug in the application, but finding and fixing these would take
> > time.)
>
> Since we just opened trixie for development, maybe now is the time
> to do this, so that the problems can be found via bug reports?
As mentioned above, I believe Vulkan works this way.
> > intel-opencl-icd = Intel integrated GPUs (replacing beignet-opencl-icd,
> > which as you note, no longer builds)
>
> Unfortunately intel-opencl-icd can't replace beignet-opencl-icd
> because the former doesn't support old hardware. At least on my
> system, clinfo says only pocl and beignet have supported devices.
If beignet-opencl-icd no longer builds, then we can't ship it, however
much your older hardware might benefit from it. I think for trixie your
older hardware will have to fall back to running Op
Re: [Pkg-opencl-devel] opencl-icd virtual package(s)?
On 19/06/2023 06.10, Paul Wise wrote: On Sun, 2023-06-18 at 07:28 +0100, Rebecca N. Palmer wrote: Hence, such a package would need to Depend on or Recommend *all* the ICDs, similar to xorg-xserver-video-all. Ah. So considering what Vincent said, something like this? Should we distinguish between the device types CPU and GPU? CPU devices are likely available on buildds, ci-infrastructure, ... AFAICS CPU would be pocl-opencl-icd (but only available on x86, arm), all others should be GPU. (pocl supports more devices, e.g. cuda, vulkan, ... but so far we only build and ship the cpu drivers) pocl (cpu) builds for most platforms, but selftests are failing due to wrong results which seems to be a code generation issue either in pocl or llvm. Package: some-opencl-using-package Recommends: opencl-icd-all | opencl-icd Package: opencl-icd-all Section: metapackages Depends: beignet-opencl-icd, intel-opencl-icd, mesa-opencl-icd, pocl-opencl-icd, Package: opencl-icd-all-non-free Section: non-free/metapackages Depends: opencl-icd-all-free, nvidia-legacy-340xx-opencl-icd, nvidia-legacy-390xx-opencl-icd, nvidia-opencl-icd, nvidia-tesla-418-opencl-icd, nvidia-tesla-450-opencl-icd, nvidia-tesla-460-opencl-icd, nvidia-tesla-470-opencl-icd, nvidia-tesla-510-opencl-icd, nvidia-tesla-opencl-icd, The nvidia bits must be an ored list of alternatives, we don't want to pull in more than one driver. Leaving out all the EoL and transitional bits, this boils down to nvidia-opencl-icd | nvidia-tesla-opencl-icd | nvidia-tesla-470-opencl-icd for bookworm and trixie (at least for now, but I don't expect a new nvidia driver split (due to cards getting deprecated) soon) Andreas
Bug#1038627: general: Various applications log PipeWire-related errors on a Bookworm system using PulseAudio.
Package: general Severity: minor X-Debbugs-Cc: splashed_overbuilt...@simplelogin.com Dear Maintainer, After upgrade to Bookworm, due to certain limitations of the current PipeWire implementation I had to switch to PulseAudio. The switch was done by installing pulseaudio package, deleting all PipeWire packages and finally enabling pulseaudio service on a user level. After several reboots and usage of various applications I've noticed strange errors (visible using journalctl -p 3 -xb) logged that looked as follows: "pw.conf: can't load default config client.conf: No such file or directory" Primarily this error was logged by mpv and Telegram applications. Investigation of several sources has shown that maybe creation of an empty ~/.config/pipewire/client.conf" file might fix the error. And indeed it fixed the original error, but procreated a new type of errors: that look as follows: Jun 19 07:01:41 Yura-PC xdg-desktop-portal[1768]: pw.core: 0x55d8ca82c830: can't find protocol 'PipeWire:Protocol:Native': Operation not supp> Jun 19 07:01:42 Yura-PC Telegram[1528]: pw.core: 0x7f78f6ff3d80: can't find protocol 'PipeWire:Protocol:Native': Operation not supported Jun 19 08:48:37 Yura-PC mpv[4283]: pw.core: 0x5630b5b7c9f0: can't find protocol 'PipeWire:Protocol:Native': Operation not supported Jun 19 08:51:12 Yura-PC mpv[3200]: pw.core: 0x56312d870420: can't find protocol 'PipeWire:Protocol:Native': Operation not supported Jun 19 08:52:14 Yura-PC mpv[3200]: pw.core: 0x56312d7eff10: can't find protocol 'PipeWire:Protocol:Native': Operation not supported Jun 19 08:55:55 Yura-PC mpv[3200]: pw.core: 0x56312d8549b0: can't find protocol 'PipeWire:Protocol:Native': Operation not supported Jun 19 08:56:19 Yura-PC mpv[3200]: pw.core: 0x56312d8845d0: can't find protocol 'PipeWire:Protocol:Native': Operation not supported Jun 19 09:00:53 Yura-PC mpv[3200]: pw.core: 0x56312d7cc000: can't find protocol 'PipeWire:Protocol:Native': Operation not supported Jun 19 09:01:12 Yura-PC mpv[3200]: pw.core: 0x56312d883d40: can't find protocol 'PipeWire:Protocol:Native': Operation not supported Jun 19 09:03:41 Yura-PC mpv[3200]: pw.core: 0x56312d865130: can't find protocol 'PipeWire:Protocol:Native': Operation not supported Jun 19 09:05:15 Yura-PC mpv[3200]: pw.core: 0x56312d7fe5d0: can't find protocol 'PipeWire:Protocol:Native': Operation not supported Jun 19 09:07:39 Yura-PC mpv[3200]: pw.core: 0x56312d857cf0: can't find protocol 'PipeWire:Protocol:Native': Operation not supported Jun 19 09:09:31 Yura-PC mpv[3200]: pw.core: 0x56312d7f5740: can't find protocol 'PipeWire:Protocol:Native': Operation not supported Jun 19 09:10:56 Yura-PC mpv[3200]: pw.core: 0x56312d85e1e0: can't find protocol 'PipeWire:Protocol:Native': Operation not supported Jun 19 09:11:50 Yura-PC mpv[3200]: pw.core: 0x56312d8837c0: can't find protocol 'PipeWire:Protocol:Native': Operation not supported Jun 19 09:15:30 Yura-PC mpv[3200]: pw.core: 0x56312d8656a0: can't find protocol 'PipeWire:Protocol:Native': Operation not supported Jun 19 09:16:07 Yura-PC mpv[3200]: pw.core: 0x56312d802ab0: can't find protocol 'PipeWire:Protocol:Native': Operation not supported Jun 19 09:18:11 Yura-PC mpv[3200]: pw.core: 0x56312d861820: can't find protocol 'PipeWire:Protocol:Native': Operation not supported Jun 19 09:19:02 Yura-PC mpv[3200]: pw.core: 0x56312d85e270: can't find protocol 'PipeWire:Protocol:Native': Operation not supported Jun 19 09:20:36 Yura-PC mpv[3200]: pw.core: 0x56312d8828a0: can't find protocol 'PipeWire:Protocol:Native': Operation not supported Jun 19 09:22:40 Yura-PC mpv[3200]: pw.core: 0x56312d7f7e40: can't find protocol 'PipeWire:Protocol:Native': Operation not supported Jun 19 09:32:29 Yura-PC mpv[3200]: pw.core: 0x56312d8851a0: can't find protocol 'PipeWire:Protocol:Native': Operation not supported Jun 19 09:33:17 Yura-PC mpv[3200]: pw.core: 0x56312d8e0540: can't find protocol 'PipeWire:Protocol:Native': Operation not supported So it seems these are PipeWire-related errors logged on a system that doesn't use this audio subsystem. The expectation is that such errors aren't logged. It's worth noting that both input and output audio work fine, despite the error being logged. Best Regards, Yura
