Re: [Pkg-opencl-devel] opencl-icd virtual package(s)?
On Mon, 2023-06-19 at 11:04 +0100, Simon McVittie wrote: > Older Intel integrated GPUs are not very fast anyway, so this might not > be a particularly significant loss. Plenty fast enough to run the FOSS 3D games in Debian like 0ad though. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: Default network configuration system (was Re: proposal: dhcpcd-base as standard DHCP client starting with Trixie)
On Tue, 2023-06-20 at 11:19 +0200, Lukas Maerdian wrote: > Netplan allows to configure both of those tools and is already being > used across Ubuntu and in Debian cloud-images for this purpose. All > while keeping full flexibility to use the underlying tool's native > config files, should Netplan's simple YAML settings not be enough for > a given complex usecase. Is Netplan able to parse an existing native config for each of the tools and then output either Netplan configs or native configs for each of the other network config tools? For example could you use Netplan to auto-migrate from ifupdown to systemd-networkd or NetworkManager etc? -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#1038814: RFP: python-mt-940 -- MT940 banking files parser
Package: wnpp Severity: wishlist X-Debbugs-Cc: debian-devel@lists.debian.org, debian-pyt...@lists.debian.org Control: block 1024494 by -1 * Package name: python-mt-940 Upstream Author : Rick van Hattem (Wolph) * URL : https://github.com/wolph/mt940 * License : BSD-3-clause Programming Lang: Python Description : python library parser for MT940 banking files A library to parse MT940 files and returns smart Python collections for statistics and manipulation.
Re: Mass bug filing / call for testing: dependencies on SDL 1.2
On Wed, 21 Jun 2023 10:33:01 +0100, Simon McVittie wrote: > On Wed, 21 Jun 2023 at 08:50:30 +0200, Stephen Kitt wrote: > > On Mon, 12 Jun 2023 17:24:03 +0100, Simon McVittie > > wrote: > > > SDL 1.2 was superseded by SDL 2 several years ago, and no longer > > > receives upstream maintenance or releases. Maintained software that > > > uses SDL 1.2 should be ported to SDL 2. > > > > Given the time scales involved, is it worth waiting for SDL 3 (soon...) > > before porting SDL 1.2 software? I’m assuming that SDL 3 will be available > > for Trixie, and this would avoid two porting efforts. > > I don't know what the timescale for a stable release of SDL 3 is like - > I hope it'll be ready before trixie, but I can't guarantee anything. Many > games will not be able to move to SDL 3 until additional libraries like > SDL2_image have a SDL 3 version, so even after everything is API-stable, > it's going to take several trips through NEW before we can ask maintainers > to port to it. > > The first step in porting from SDL 1.2 to SDL 3 will be porting to SDL 2 > (both the core library and the version of addons like SDL_image), and > the second step would be moving away from any deprecated SDL-2-era APIs, > so I think it's worth doing those regardless. Right, so in any case the effort involved in porting to SDL 2 won’t be “wasted” by a subsequent port to SDL 3. > What I would prefer to try to avoid here is for maintainers to think > "I'll just wait for SDL 3", and then time passes, maintainers are busy > with something else, we freeze, and we have to ship trixie with *three* > major versions of SDL (or at least their -compat equivalents). > > Ideally these bugs would have been opened in 2013 or 2014, but better late > than never. (I was not involved in SDL maintenance at that point.) Indeed! Regards, Stephen pgpCmvhueWNnW.pgp Description: OpenPGP digital signature
Bug#1038812: ITP: sexp -- S-expressions parser and generator C++ library and command-line tool
Package: wnpp Severity: wishlist Owner: Daniel Kahn Gillmor X-Debbugs-Cc: debian-devel@lists.debian.org, d...@fifthhorseman.net * Package name: sexp Version : 0.8.5 Upstream Contact: Maxim Samsonov * URL : https://github.com/rnp/sexp * License : MIT Programming Lang: C++ Description : S-expressions parser and generator C++ library and command-line tool S-expressions are data structures fr representing complex data as a variation on LISP S-Expressions. They are similar to (but older than) JSON. There are a handful of variations in format and canonicalization that it can be useful to translate between, and to abstract away from. This C++ library inherits from the the original canonical MIT-licensed s-expression code offered by Rivest and Lampson, and is augmented to include parsing capabilities for extensions made by the GnuPG project. This library is used by the current upstream version of librnp (Ribose's OpenPGP implementation), for the purpose of interoperability with GnuPG's local file storage.
Bug#1038811: general: Unable to poweroff and suspend after upgrading to Debian 12 from Debian 11
Package: general Severity: important X-Debbugs-Cc: bete...@web.de Dear Maintainer, * What led up to the situation? After upgrading to Debian 12 bookworm from Debian 11 I couldn't shutdown or suspend anymore because of several components waiting indefinitely like f.i. - kvm authentication preventing shutdown - systemd-udevd (waiting for process 405) - modprobe (waiting for process modprobe 572) - Booting up was also taking much longer than on Debian 11 because of "ifupdown" package searching for entropy. * What exactly did you do (or not do) that was effective (or ineffective)? I tried downgrading affected packages and also disabling services at boot - no success. I upgraded my BIOS on my Thinkpad W540 - still same problem. What led to success: Booting with lower/older Kernel solved it and everything works smoothly from then - Setting default Kernel: 5.10.0-23-amd64 (instead of 6.1) * What was the outcome of this action? Poweroff and suspend works smoothly like in previous Debian. I no longer have to forcibly shut down my machine by interruption of power. Booting works fast again. * What outcome did you expect instead? I expected everything to work with the new Kernel 6.1. Downgrading the kernel was my last resort. How is 6.1 an LTS when these issues are present? Regards, Johannes Wülk
Re: Enabling branch protection on amd64 and arm64
Hey Moritz, On 2022-10-26 08:20, Moritz Mühlenhoff wrote: > I think this should rather be applied early after the Bookworm > release (and ideally we can also finish off the necessary testing > and add -fstack-clash-protection at least for amd64 and other archs > which are ready for it (#918914)). Can we go ahead with the dpkg patch now, any specific tests you had in mind before applying it? ema
Re: Mass bug filing / call for testing: dependencies on SDL 1.2
On Wed, 21 Jun 2023 at 08:50:30 +0200, Stephen Kitt wrote: > On Mon, 12 Jun 2023 17:24:03 +0100, Simon McVittie wrote: > > SDL 1.2 was superseded by SDL 2 several years ago, and no longer receives > > upstream maintenance or releases. Maintained software that uses SDL 1.2 > > should be ported to SDL 2. > > Given the time scales involved, is it worth waiting for SDL 3 (soon...) > before porting SDL 1.2 software? I’m assuming that SDL 3 will be available > for Trixie, and this would avoid two porting efforts. I don't know what the timescale for a stable release of SDL 3 is like - I hope it'll be ready before trixie, but I can't guarantee anything. Many games will not be able to move to SDL 3 until additional libraries like SDL2_image have a SDL 3 version, so even after everything is API-stable, it's going to take several trips through NEW before we can ask maintainers to port to it. The first step in porting from SDL 1.2 to SDL 3 will be porting to SDL 2 (both the core library and the version of addons like SDL_image), and the second step would be moving away from any deprecated SDL-2-era APIs, so I think it's worth doing those regardless. What I would prefer to try to avoid here is for maintainers to think "I'll just wait for SDL 3", and then time passes, maintainers are busy with something else, we freeze, and we have to ship trixie with *three* major versions of SDL (or at least their -compat equivalents). Ideally these bugs would have been opened in 2013 or 2014, but better late than never. (I was not involved in SDL maintenance at that point.) smcv
Bug#1038771: ITP: magnum-cluster-api -- cluster API driver for Magnum
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: magnum-cluster-api Version : 0.6.0 Upstream Contact: Mohammed Naser * URL : https://github.com/vexxhost/magnum-cluster-api * License : Apache-2.0 Programming Lang: Python Description : cluster API driver for Magnum Magnum is an OpenStack project which offers container orchestration engines for deploying and managing containers as first class resources in OpenStack. . This plugin for Magnum uses the Kube's cluster API for deploying.
Bug#1038767: ITP: python-pykube-ng -- client library for Kubernetes
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: python-pykube-ng Version : 22.9.0 Upstream Contact: Eldarion, Inc. * URL : https://codeberg.org/hjacobs/pykube-ng * License : Apache-2.0 Programming Lang: Python Description : client library for Kubernetes Pykube (pykube-ng) is a lightweight Python client library for Kubernetes. It is a Platform as a Service (PaaS) that makes it easy to manage web application deployment and hosting through the entire lifecycle from development through testing to production. It adds components and tools on top of Kubernetes that help developers manage their application infrastructure. This is a dependency for: https://github.com/vexxhost/magnum-cluster-api that I also intend to package.
