Bug#1052614: RFP: python-skbuild-core -- next generation Python CMake adaptor and Python API for plugins
On 2023-09-26 01:10, Emmanuel Arias wrote: Control: retitle -1 ITP: python-skbuild-core -- next generation Python CMake adaptor and Python API for plugins Control: owner -1 Emmanuel Arias I've seen it before. I will work on it and maintain it under the DPT umbrella. Thanks for raising this. ps: for some reason I didn't receive the cc mail Thanks Emmanuel. Weird about the cc. Maybe a spam filter somewhere got overzealous. Wouldn't surprise me if these wnpp emails trigger them.
Bug#1052614: RFP: python-skbuild-core -- next generation Python CMake adaptor and Python API for plugins
Control: retitle -1 ITP: python-skbuild-core -- next generation Python CMake adaptor and Python API for plugins Control: owner -1 Emmanuel Arias Hi Drew, On Mon, Sep 25, 2023 at 8:00 AM Drew Parsons wrote: > Package: wnpp > Severity: wishlist > X-Debbugs-Cc: debian-pyt...@lists.debian.org, eam...@debian.org > Control: affects -1 src:fenics-basix > > * Package name: scikit-build-core > Version : 0.5.1 > Upstream Contact: Henry Schreiner > * URL : https://github.com/scikit-build/scikit-build-core > * License : Apache2 > Programming Lang: Python > Description : next generation Python CMake adaptor and Python API > for plugins > > Scikit-build-core is a ground-up rewrite of the classic Scikit-build, > a bridge between Python package build systems and CMake, the most > popular compiled language build system. The key features of > scikit-build classic (which is setuptools based) are also present > here: > > -Great support for or by most OSs, compilers, IDEs, and libraries > -Support for C++ features and other languages like Fortran > -Support for multithreaded builds > -Simple CMakeFiles.txt instead of up to thousands of lines of fragile > setuptools/distutils code > -Cross-compile support for Apple Silicon and Windows ARM > > > Scikit-build-core is required by the future version of Basix. > > The Debian Pythom Team is a natural home for the package. > > cc: Emmanuel Arias in his role as Uploader for the old scikit-build > package. I've seen it before. I will work on it and maintain it under the DPT umbrella. Thanks for raising this. ps: for some reason I didn't receive the cc mail Cheers, Emmanuel >
Processed: Re: Bug#1052614: RFP: python-skbuild-core -- next generation Python CMake adaptor and Python API for plugins
Processing control commands: > retitle -1 ITP: python-skbuild-core -- next generation Python Bug #1052614 [wnpp] RFP: python-skbuild-core -- next generation Python CMake adaptor and Python API for plugins Changed Bug title to 'ITP: python-skbuild-core -- next generation Python' from 'RFP: python-skbuild-core -- next generation Python CMake adaptor and Python API for plugins'. -- 1052614: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1052614 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1052673: ITP: golang-github-bazelbuild-bazelisk -- A user-friendly launcher for Bazel.
Package: wnpp Severity: wishlist Owner: Arthur Diniz * Package name: golang-github-bazelbuild-bazelisk Version : 1.18.0-1 Upstream Author : Bazel * URL : https://github.com/bazelbuild/bazelisk * License : Apache-2.0 Programming Lang: Go Description : A user-friendly launcher for Bazel. Bazelisk is a user-friendly wrapper/launcher for Bazel written in Go. It automatically picks a good version of Bazel given your current working directory, downloads it from the official server (if required) and then transparently passes through all command-line arguments to the real Bazel binary. . You can call it just like you would call Bazel. . Before Bazelisk was rewritten in Go, it was a Python script. This still works and has the advantage that you can run it on any platform that has a Python interpreter, but is currently unmaintained and it doesn't support as many features.
Bug#1026333: ITP: rustup -- the rust toolchain installer
Hi all, I have created an RFS request for this package: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1052424 If you are interested, you are welcome to review and/or sponsor this prospective package. Thanks, Zixing
Bug#1030835: More updates
newer versions of ruff now use a forked vendored copy of rustpython, and upstream says they're diverging. I've updated the packaging to ruff 0.0.291, which is the point after the vendoring. State of unmet dependencies: * lalrpop/lalrpop-util needs updating to 0.20. unstable has 0.19, updating it is nontrivial - help appreciated! * argfile v0.1.6 (in NEW queue) * clearscreen v2.0.1 (in NEW queue) * imperative v1.0.5 (in NEW queue) * rust-stemmers (in NEW queue) * libcst v0.1.0 (in NEW queue) * syn-ext v0.4.0 (in NEW queue) * serde_with v3.3.0 (in NEW queue) * result-like-derive v0.4.6 (in NEW queue) * result-like v0.4.6 (in NEW queue) That's probably an incomplete list; "cargo debstatus" runs out of stack space analyzing ruff now :-/ Cheers, Jelmer
Processed: ITP: tuning-library -- Surge Synth Team Tuning Library
Processing control commands: > block 1025206 by -1 Bug #1025206 [wnpp] ITP: bespokesynth -- modular music synthesizer 1025206 was blocked by: 1052621 1025206 was not blocking any bugs. Added blocking bug(s) of 1025206: 1052636 -- 1025206: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1025206 1052636: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1052636 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1052636: ITP: tuning-library -- Surge Synth Team Tuning Library
Package: wnpp Owner: Andrius Merkys Severity: wishlist Control: block 1025206 by -1 * Package name: tuning-library Version : 1.1.0+ds Upstream Author : Paul Walker * URL : https://github.com/surge-synthesizer/tuning-library * License : Expat Programming Lang: C Description : Surge Synth Team Tuning Library Standalone C++ header only library for microtuning. MTS-ESP is needed by bespokesynth (ITP #1025206) Remark: This package is to be maintained with Debian Multimedia Maintainers at https://salsa.debian.org/merkys/tuning-library I preemptively pushed the package to personal space on salsa, but will ask to have it moved to Debian Multimedia Maintainers space.
Processed: ITP: mts-esp -- microtuning support to audio and MIDI plugins
Processing control commands: > block 1025206 by -1 Bug #1025206 [wnpp] ITP: bespokesynth -- modular music synthesizer 1025206 was not blocked by any bugs. 1025206 was not blocking any bugs. Added blocking bug(s) of 1025206: 1052621 -- 1025206: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1025206 1052621: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1052621 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1052621: ITP: mts-esp -- microtuning support to audio and MIDI plugins
Package: wnpp Owner: Andrius Merkys Severity: wishlist Control: block 1025206 by -1 * Package name: mts-esp Version : 0.0~git20230110.9df9a9c Upstream Author : ODDSound Ltd. * URL : https://github.com/ODDSound/MTS-ESP * License : 0BSD Programming Lang: C Description : microtuning support to audio and MIDI plugins The MTS-ESP library is a simple but versatile C/C++ library for adding microtuning support to audio and MIDI plugins. It allows for a single master plugin to simultaneously control the tuning of any number of connected client plugins across a DAW session. Connection between a master and clients is automatic and invisible. MTS-ESP is needed by bespokesynth (ITP #1025206) Remark: This package is to be maintained with Debian Multimedia Maintainers at https://salsa.debian.org/multimedia-team/mts-esp
Bug#1052431: RFP: rust-tonic -- rust implementation of gRPC
On 9/22/23 1:42 PM, Jonas Smedegaard wrote: Quoting Reinhard Tartler (2023-09-22 13:09:08) How about I take care of hyper-timeout and prettyplease in debcargo-conf (i.e., the rust team mass-packaging repo), and try to assist you with packaging the workspace builds of tonic (which includes tonic-build, cf. https://github.com/hyperium/tonic/tree/master/tonic-build) and axum? Deal! :-) hyper-timeout: https://ftp-master.debian.org/new/rust-hyper-timeout_0.4.1-1.html prettyplease: https://tracker.debian.org/pkg/rust-prettyplease both versions currently in the archive should satisfy requirements for tonic. Let me know what other dependencies are missing, happy to add them to debcargo-conf.git -rt
Bug#1052619: ITP: pydantic-core -- Rust implementation of pydantic core functionality
Package: wnpp Severity: wishlist Owner: Timo Röhling X-Debbugs-Cc: debian-de...@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: pydantic-core Version : 2.9.0 Upstream Author : Samuel Colvin * URL : https://github.com/pydantic/pydantic-core * License : Expat Programming Lang: Python, Rust Description : Rust implementation of pydantic core functionality pydantic uses type hinting (PEP 484) and variable annotation (PEP 526) to validate that untrusted data takes the desired form. There is also support for an extension to dataclasses where the input data is validated. The core library is implemented in Rust and up to seventeen times faster than the original pure Python implementation. This is a new dependency for pydantic 2. The package will probably be team-maintained under the umbrella of the Debian Python Team . -BEGIN PGP SIGNATURE- iQGzBAEBCgAdFiEEJvtDgpxjkjCIVtam+C8H+466LVkFAmURdfQACgkQ+C8H+466 LVkUawwAjCO9wWXpdir5lVlaQa0b5niJ/JGEWC2qg6bZxBELJHyniYlyUtAl+qeb AsySa6hSQ+4nCgQEinCo9JHwwhERlY9MlceVeez4EuP1Xt4udbvx8l9RUUAlUP7b BYxgw8GAWMQsrn+ZCPdv0jjvzjI9u1LOzJqwV8w6E0XpuQTi7ZsqNegKsEg0jfVk NKUGaCyWKvEmhh1rfn7iPO0QGiufbsjp568JCA1LGX/OKL8oXD3LEu+ji9P9gCRq ym6iqrmrRtNH3vIBi29chaQUkEZRQvkzAocWXF5F8Ba6j2B9dMiuNsPT7ylBFGF/ tEbg+9ELAHlV7Ab9yAH2VPM1gpmblOs9rpp0+F+fCfW+raTH3OByXYGgMbyryOeD P+YtP2awBSpQSrS6YGjK83MTPRxrv0UflK6+XL3eDHN7GsMMQuAv4TkA9HX7BDUf 7+JP2urP0gjL4sdkRtZncHQWhEIc2HWHGUW3OAlJEClMyu/HVslomsEcS8zxKIUk UCc5c91X =J7bx -END PGP SIGNATURE-
Processed (with 1 error): your mail
Processing commands for cont...@bugs.debian.org: > retitle 1051779 ITP: python-docopt-ng -- command-line argument parser Bug #1051779 [wnpp] ITP: docopt-ng -- command-line arguments parser (python3) Changed Bug title to 'ITP: python-docopt-ng -- command-line argument parser' from 'ITP: docopt-ng -- command-line arguments parser (python3)'. > (Python 3) Unknown command or malformed arguments to command. > thanks Stopping processing here. Please contact me if you need assistance. -- 1051779: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1051779 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1052562: ITP: eza -- Modern replacement for ls
* Sylvestre Ledru [230924 15:57]: > Package: wnpp > Severity: wishlist > Owner: Sylvestre Ledru > X-Debbugs-Cc: debian-de...@lists.debian.org > > * Package name: eza > * URL : https://github.com/eza-community/eza > * License : MIT > > it is a replacement of exa (dead upstream). > it will break/replace it. Why? If they are not co-installable, this is the correct dependency. Also, if you are the maintainer of the old package, and you are planning to remove the old package after the next release, and are doing this to automatically upgrade users from the old package to the new package, then this, as well as the rest of the advice at https://wiki.debian.org/RenamingPackages, is appropriate. However, just because eza is the _logical_ replacement for a dead-upstream package is not a reason for it to have a Debian package dependency forcing the removal of the old package when installing the new. If they are co-installable, and the removal of the old package is not imminent, I would simply coordinate with the maintainer of the old package (if he/she is amenable), and when yours is uploaded, add a sentence to the bottom of the old package description stating that the package is obsolete and naming your package as the preferred, actively maintained replacement. Also add a NEWS entry with that info in the old package. ...Marvin
Bug#1052562: ITP: eza -- Modern replacement for ls
Le 25/09/2023 à 13:40, Marvin Renich a écrit : * Sylvestre Ledru [230924 15:57]: Package: wnpp Severity: wishlist Owner: Sylvestre Ledru X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: eza * URL : https://github.com/eza-community/eza * License : MIT it is a replacement of exa (dead upstream). it will break/replace it. Why? If they are not co-installable, this is the correct dependency. Also, if you are the maintainer of the old package, and you are planning to remove the old package after the next release, and are doing this to automatically upgrade users from the old package to the new package, then this, as well as the rest of the advice at https://wiki.debian.org/RenamingPackages, is appropriate. yeah, i know :) I am the maintainer of the two Cheers Sylvestre
Processed: RFP: python-skbuild-core -- next generation Python CMake adaptor and Python API for plugins
Processing control commands: > affects -1 src:fenics-basix Bug #1052614 [wnpp] RFP: python-skbuild-core -- next generation Python CMake adaptor and Python API for plugins Added indication that 1052614 affects src:fenics-basix -- 1052614: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1052614 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1052614: RFP: python-skbuild-core -- next generation Python CMake adaptor and Python API for plugins
Package: wnpp Severity: wishlist X-Debbugs-Cc: debian-pyt...@lists.debian.org, eam...@debian.org Control: affects -1 src:fenics-basix * Package name: scikit-build-core Version : 0.5.1 Upstream Contact: Henry Schreiner * URL : https://github.com/scikit-build/scikit-build-core * License : Apache2 Programming Lang: Python Description : next generation Python CMake adaptor and Python API for plugins Scikit-build-core is a ground-up rewrite of the classic Scikit-build, a bridge between Python package build systems and CMake, the most popular compiled language build system. The key features of scikit-build classic (which is setuptools based) are also present here: -Great support for or by most OSs, compilers, IDEs, and libraries -Support for C++ features and other languages like Fortran -Support for multithreaded builds -Simple CMakeFiles.txt instead of up to thousands of lines of fragile setuptools/distutils code -Cross-compile support for Apple Silicon and Windows ARM Scikit-build-core is required by the future version of Basix. The Debian Pythom Team is a natural home for the package. cc: Emmanuel Arias in his role as Uploader for the old scikit-build package.
