Bug#1028207: ITP: vkroots -- framework for writing Vulkan layers that takes all the complexity away
Package: wnpp Severity: wishlist Owner: Stephan Lachnit X-Debbugs-Cc: debian-devel@lists.debian.org, stephanlach...@debian.org * Package name: vkroots Version : git Upstream Contact: Joshua Ashton * URL : https://github.com/Joshua-Ashton/vkroots * License : Apache-2.0 OR MIT Programming Lang: C++ Description : framework for writing Vulkan layers that takes all the complexity away Required for latest gamescope. Will be maintained under the Games Team.
Re: setting sysctl net.ipv4.ping_group_range
On Sat, 2023-01-07 at 16:55 -0800, Steve Langasek wrote: > On Tue, Jan 03, 2023 at 03:26:37AM +0100, Marco d'Itri wrote: > > > Nowadays systemd is a source of common sysctl settings among different > > distributions. > > Debian still supports other init systems in the archive besides systemd. Not really: we only support exploring and developing alternative init systems. That doesn't mean full support and random things might not work correctly (and that is accepted). > Should ping fail to run on a Debian system that is not using systemd? Why not? It's not different from other software where we allow this? > We also recently ran into a bug with systemd in Ubuntu because the "common > sysctl settings among different distributions" that they had added clobbered > settings that had been shipped for years already in the Ubuntu procps > package. No thank you. > > https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1962038 > > What would really be a great place for shipping common sysctl settings among > different distributions would be in the Linux kernel, instead of diverging > from the kernel defaults in userspace and representing this as "common". I think I read somewhere that linux upstream is not enthusiastic about choosing more appropriate defaults and leaves that to downstream. Diverting those is only possible in userspace as we still support using self-built kernels (which can come from upstream) ;-) If you want some other "common" ground, I guess it would need to be created and adopted instead of the current one first. Ansgar
Re: SONAME bumps (transitions) always via experimental
Hi All On Fri, 6 Jan 2023 at 00:33, Bastian Blank wrote: > However, please describe an actionable plan. What do you want to be > rejected, in a codified form. > > It would be nice if you could provide a patch for process-new that > displays this information. Would it be a bad thing to require all uploads that need to go through NEW (source and binary) to target experimental? I have been doing this for my own, and sponsored, uploads for some years already. There's usually some reason for another upload after acceptance anyway; e.g. source upload for arch:all, breaking changes in toolchain or other dependencies, symbols file needs tweaking, autopkgtest needs tweaking, bump Standards-Version, update debian/copyright years, etc. Regards Graham
Bug#1028188: ITP: python-validate-pyproject -- Automated checks on pyproject.toml by JSON Schema definitions
Package: wnpp Severity: wishlist Owner: Carsten Schoenert X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: python-validate-pyproject Version : 0.10.1 Upstream Contact: Anderson Bravalheri * URL : https://github.com/abravalheri/validate-pyproject * License : BSD, MIT, MPL-2.0 Programming Lang: Python Description : Automated checks on pyproject.toml by JSON Schema definitions With the approval of PEP 517 and PEP 518, the Python community shifted towards a strong focus on standardisation for packaging software, which allows more freedom when choosing tools during development and make sure packages created using different technologies can interoperate without the need for custom installation procedures. . This shift became even more clear when PEP 621 was also approved, as a standardised way of specifying project metadata and dependencies. . validate-pyproject was born in this context, with the mission of validating pyproject.toml files, and make sure they are compliant with the standards and PEPs. Behind the scenes, validate-pyproject relies on JSON Schema files, which, in turn, are also a standardised way of checking if a given data structure complies with a certain specification. This package is a dependency for pdm-backend (not yet filed a ITP) and will be maintained within the Debian Python team. Upstream uses a vendored version of fastjsonschema shipped in the folder src/validate_pyproject/_vendor/. The reasoning isn't currently clear why this is needed. Due this vendoring there are multiple licenses comes to play. I've tried to entagle this vendoring but hadn't luck until yet. pdm-backend calles itself it is the successor for pdm-pep517 but hasn't reached a stable version number yet.
