Bug#1079857: ITP: uwsgi-plugin-ruby -- Ruby plugins for uWSGI
Package: wnpp Severity: wishlist Owner: Alexandre Rossi X-Debbugs-Cc: debian-devel@lists.debian.org, Jonas Smedegaard * Package name: uwsgi-plugin-ruby Version : 0.0.1 * URL : https://uwsgi-docs.readthedocs.io/en/latest/ * License : GPL-2 Programming Lang: C Description : ruby plugins for uWSGI uWSGI source packages build many plugins. Some plugins inplement language bindings and building them in the core source package can create transition difficulties. Also, building many plugins in the same d/rules makes it complicated and looses the semantic association between the plugin and its build dependencies, which are mixed for all plugins. This new source package proposes to build the ruby java plugin packages from a separate source package, as this has been done for php, mongo and luajit. Work is happenning here: https://salsa.debian.org/uwsgi-team/uwsgi-plugin-ruby Alex
Bug#1079859: ITP: python-ntruprime -- python-ntruprime
Package: wnpp Severity: wishlist Owner: Jan Mojzis X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: python-ntruprime Version : 20240825.1 Upstream Contact: Jan Mojzis * URL : https://github.com/janmojzis/python-ntruprime * License : CC0 Programming Lang: Python Description : Python wrapper around libntruprime library libntruprime is a Streamlined NTRU Prime microlibrary. libntruprime has a very simple stateless API based on the SUPERCOP API, with wire-format inputs and outputs, providing functions that directly match the KEM operations provided by Streamlined NTRU Prime, such as functions ntruprime1277.keypair() ntruprime1277.enc() ntruprime1277.dec() for the ntruprime1277 KEM. This package is related to: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1079669 I'm going to maintain the package using https://salsa.debian.org/ It is being prepared here: https://salsa.debian.org/janmojzis/python-ntruprime I need sponsor for the first upload (I'm DM). Jan
Bug#1079860: ITP: python-threadloop -- Tornado IOLoop Backed Concurrent Futures
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: python-threadloop Version : 1.0.2 Upstream Author : Grayson Koonce * URL : https://github.com/TomerFi/aioswitcher * License : Expat Programming Lang: Python Description : Tornado IOLoop Backed Concurrent Futures This package provides a way to run Tornado Coroutines from Synchronous Python. This is a new indirect dependency for OpenStack.
Bug#1079909: ITP: python-jaeger-client -- OpenTracing tracer implementation
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: python-jaeger-client Version : 4.8.0 Upstream Contact: Yuri Shkuro * URL : https://github.com/jaegertracing/jaeger-client-python * License : Apache-2.0 Programming Lang: Python Description : OpenTracing tracer implementation This is a client-side library that can be used to instrument Python apps for distributed trace collection, and to send those traces to Jaeger. See the OpenTracing Python API for additional detail. I intend to maintain this package within the OpenStack team.
Re: removing a non-static version of qemu-user?
On 8/26/24 08:27, Michael Tokarev wrote: I'd love to get some input about an idea which I expressed in https://bugs.debian.org/1079603 - namely, to move static qemu-user emulation binaries from qemu-user-static package to qemu-user package (which contains dynamically-linked binaries with exactly the same functionality), effectively keeping just one, static, build of qemu-user instead of two. I see no reason of building two versions of qemu-user binaries, since static version is well-suited for all usages, while dynamically-linked one, while obviously smaller, is limited to just a few use cases. The details are expressed in the bugreport mentioned above. The resulting layout is compatible with current expectations, so nothing should be (immediatly) changed in existing packages/habits. If there are other reasons to keep non-static build of qemu-user which I didn't think of, please tell me. IMHO qemu-user is one of the rare packages, where you want and need static built binaries. That said, I fully support your proposal to drop non-static qemu-user binaries. Helge
Re: DEP-18 discussion summary (Re: Request for feedback on draft: DEP-18: Enable true open collaboration on all Debian packages)
Il 28/08/2024 04:13, Otto Kekäläinen ha scritto: Hi! While I intend to continue on iterating DEP-18, here is a summary to those who did not wade through the 140+ messages on the topic. Unfortunately, the summary itself is also a bit long :) Big thanks for your work and of other people that are trying to improve contribution and collaboration in Debian. ## Maintainer Workflows There were concerns that requiring specific Git and Gitlab practices could create burdens for existing maintainers, especially single-person maintainers. Sean Whitton described his own preferences as a maintainer: I am happy to use salsa for git hosting and access management. I love that I can easily grant push access to my non-DD team members. But, I turn off salsa MRs for the repos of all packages I regularly upload. I would hope that this DEP can be written such as to account for these sorts of choices. Fabio Fantoni suggested allowing maintainers to specify their preferred collaboration methods in a machine-readable way, for example through a "Collaboration-Policy" field in debian/control. As pointed by other people there is debian/README.source that can be used for that. So if don't want to add a new field/s to d/control, and/or a new file we could simply use that one making this thing more known. and in the case of teams or people who manage many packages (even hundreds or thousands) with the same methods could put a link in d/README.source so as to point to a single page/site/repository to keep updated in a simpler and faster way with all the information ## Performance and Reliability Multiple participants, including Salvo Tomaselli, Johannes Schauer Marin Rodrigues, Andrea Pappacoda, and Gioele Barabucci, complained about Salsa/GitLab being slow or unreliable at times, which deterred contribution. Improvements to performance and uptime were seen as important. In response, Otto Kekäläinen noted that the Salsa admins had posted about upcoming hardware upgrades and other improvements to address these issues at https://salsa.debian.org/salsa/support/-/issues. Thanks for working to improving Salsa. However, there have also been numerous performance problems and unavailability of other parts useful to both contributors and users, in particular packages.debian.org and wiki.debian.org which don't seems has been considered, or am I wrong? ## Machine-Readable Metadata Fabio Fantoni and Niels Thykier proposed including more machine-readable metadata about packaging workflows (e.g. in debian/control) to help automate contributor onboarding. Niels Thykier outlined some specific examples of information that could be captured: Does this package use `gbp dch` (or some other mechanisms) to generate the changelog OR should I include a changelog entry with my patch. Does this package use some form of automatic formatting that I should apply when I do my changes (if `wrap-and-sort`, then which options)? Does the maintainer prefer MR via salsa or BTS with patches for when I want to submit my changes for review. Even if don't want to add them as Machine-Readable Metadata, I think can put them at least in debian/README.source (more details above), I think the important thing would be to advise maintainers more to make such information easily available. OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Debian installation problem on Macbook pro from 2019
On 8/23/24 00:24, lina wrote: Hi, During the Debian (stable) installation on Macbook pro from 2019, my internal keyboard is not recognizable even I exhausted all possible keyboard options listed during dpkg-reconfiguration keyboard-configuration # more /etc/default/keyboard # KEYBOARD CONFIGURATION FILE # Consult the keyboard(5) manual page. *XKBMODEL="apple_laptop"* XKBLAYOUT="us" XKBVARIANT="dvorak-classic" XKBOPTIONS="lv3:ralt_alt" BACKSPACE="guess" I also tried *XKBMODEL="macbook79" XKBMODEL="macbook78" XKBMODEL="macintosh"** XKBMODEL="macintosh_old"* *XKBMODEL="apple"* *XKBMODEL="applealu_ansi"* # dmesg | grep -i keyboard [ 2.237578] usb 1-1.2: Product: Magic Keyboard [ 2.464951] usb 1-1.3: Product: USB Keyboard [ 2.466381] apple 0003:05AC:0267.0002: fixing up Magic Keyboard battery report descriptor [ 2.466464] apple 0003:05AC:0267.0002: Fn key not found (Apple Wireless Keyboard clone?), disabling Fn key handling [ 2.466485] input: Apple Inc. Magic Keyboard as /devices/pci:00/:00:14.0/usb1/1-1/1-1.2/1-1.2:1.0/0003:05AC:0267.0002/input/input6 [ 2.466530] apple 0003:05AC:0267.0002: input,hiddev0,hidraw1: USB HID v1.10 Keyboard [Apple Inc. Magic Keyboard] on usb-:00:14.0-1.2/input0 [ 2.466686] input: Apple Inc. Magic Keyboard as /devices/pci:00/:00:14.0/usb1/1-1/1-1.2/1-1.2:1.1/0003:05AC:0267.0003/input/input7 [ 2.471679] hid-generic 0003:2109:D101.0005: hiddev1,hidraw2: USB HID v1.10 Device [VIA Labs, Inc. USB Keyboard ] on usb-:00:14.0-1.3/input0 [ 2.523233] apple 0003:05AC:0267.0003: input,hiddev2,hidraw3: USB HID v1.10 Keyboard [Apple Inc. Magic Keyboard] on usb-:00:14.0-1.2/input1 [ 2.523305] apple 0003:05AC:0267.0004: hiddev3,hidraw4: USB HID v1.10 Device [Apple Inc. Magic Keyboard] on usb-:00:14.0-1.2/input2 [ 4.231170] systemd[1]: Starting keyboard-setup.service - Set the console keyboard layout... I have done a lot of installs on a 2011 iMac, and in my experience, you need to do it with a wired USB keyboard. After the install, you can manage the system with any keyboard you can manage to get working, but for the purposes of installation, the Debian Installer and the Macintosh together seem to need a wired USB keyboard.
Intend to package Cuttlefish (Android virtual device)
Hi all, I intend to package Cuttlefish. But I'd like some clarification. Cuttlefish, an open-source project (source: https://source.android.com/docs/devices/cuttlefish/get-started), requires downloading or building additional open-source components like AOSP images and crosvm for full functionality. For the meanwhile, we need to put this package into "contrib". Am I right? The concept of "contrib" typically refers to packages that depend on non-free components, even if the package itself is open-source. However, in this case, the required tools might not be officially packaged for Debian yet. While they are all open-source, their absence from Debian repositories could justify placing Cuttlefish in the "contrib" section. Am I correct? Yours, Paul OpenPGP_0x44173FA13D05.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Intend to package Cuttlefish (Android virtual device)
On Thu, Aug 29, 2024 at 04:20:20AM +0800, Ying-Chun Liu (PaulLiu) wrote: > Hi all, > > I intend to package Cuttlefish. But I'd like some clarification. > > Cuttlefish, an open-source project (source: > https://source.android.com/docs/devices/cuttlefish/get-started), requires > downloading or building additional open-source components like AOSP images > and crosvm for full functionality. > > For the meanwhile, we need to put this package into "contrib". Am I right? > > The concept of "contrib" typically refers to packages that depend on > non-free components, even if the package itself is open-source. However, in > this case, the required tools might not be officially packaged for Debian > yet. While they are all open-source, their absence from Debian repositories > could justify placing Cuttlefish in the "contrib" section. Am I correct? > Hi, If all components are free software with acceptable licences and freedom to distribute the results - this should be able to go into Debian main though not yet into Debian stable. If it gets into unstable and testing, it could be released with Debian 13 Trixie when it releases. Hope this helps, Andy (amaca...@debian.org) > Yours, > Paul
Bug#1079947: ITP: senpai -- senpai is a terminal IRC client that works best with bouncers
Package: wnpp Severity: wishlist Owner: Mae Miller X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: senpai Version : x.y.z Upstream Contact: ~delthas/senpai-...@lists.sr.ht * URL : https://sr.ht/~delthas/senpai/ * License : ISC Programming Lang: Go Description : senpai is a terminal IRC client that works best with bouncers senpai is an IRC client that works best with bouncers: no logs are kept, history is fetched from the server via CHATHISTORY, networks are fetched from the server via bouncer-networks, messages can be searched in logs via SEARCH, files can be uploaded via FILEHOST (with drag & drop!) - why is this package useful/relevant?: This software is far better than alternative console-based irc clients at connecting to IRC bouncers seamlessly, especially soju-based bonucers. The application is also very snappy and intuitive. Weechat is good but I think this makes onboarding new IRC users easier which is relevant for the debian project - I need a sponsor and guidance as my last packaging foray didn't pan out. publickey - mmiller@wanderingwires.net - 0xC21D2CFF.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Re: Intend to package Cuttlefish (Android virtual device)
Hi, > > I intend to package Cuttlefish. But I'd like some clarification. > > > > Cuttlefish, an open-source project (source: > > https://source.android.com/docs/devices/cuttlefish/get-started), requires > > downloading or building additional open-source components like AOSP images > > and crosvm for full functionality. > > > > For the meanwhile, we need to put this package into "contrib". Am I right? > > > > The concept of "contrib" typically refers to packages that depend on > > non-free components, even if the package itself is open-source. However, in > > this case, the required tools might not be officially packaged for Debian > > yet. While they are all open-source, their absence from Debian repositories > > could justify placing Cuttlefish in the "contrib" section. Am I correct? > > > If all components are free software with acceptable licences and freedom to > distribute the results - this should be able to go into Debian main > though not yet into Debian stable. If it gets into unstable and testing, it > could be released with Debian 13 Trixie when it releases. Depends on how strong the dependency is [1], what depends of how relevant the missing functionality is. Rather "nice to have but unneeded" or more like "people would expect this to work, when using this software" or even "this software is useless without this functionality"? [1] https://www.debian.org/doc/debian-policy/ch-archive.html#the-main-archive-area "packages in main must not require or recommend a package outside of main for compilation or execution (thus, the package must not declare a Pre-Depends, Depends, Recommends, Build-Depends, Build-Depends-Indep, or Build-Depends-Arch relationship on a non-main package" signature.asc Description: This is a digitally signed message part.
Bug#1079011: ITP: marknote -- Simple markdown note management app.
Package: wnpp Followup-For: Bug #1079011 Owner: Weng Chichih X-Debbugs-Cc: debian-devel@lists.debian.org, chic...@foxmail.com I'm interested in packaging marknote too, and have spent some time on it that try to package it, and try to get familiar with Debian packaging. Happy to see marknote to be introduced into Debian, thanks for your work, I can assist if needed. Cheers.
Bug#1079969: ITP: rpi-bad-power -- Detect bad power supply on Raspberry Pi
Package: wnpp Severity: wishlist Owner: Edward Betts X-Debbugs-CC: debian-devel@lists.debian.org * Package name: rpi-bad-power Version : 0.1.0 Upstream Author : Xiaonan Shen * URL : https://github.com/shenxn/rpi-bad-power * License : MIT Programming Lang: Python Description : Detect bad power supply on Raspberry Pi This library detects issues with the power supply on a Raspberry Pi. It monitors the system for under-voltage conditions, helping users identify power supply problems. The library reads system entries to determine if the Raspberry Pi is experiencing under-voltage, allowing users to take necessary actions to ensure stable power. It supports kernel 4.14 and above and provides a straightforward way to check for power supply reliability. This library is a dependency of Home Assistant, the Python smart home platform. I plan to maintain it as part of the Home Assistant team.
Bug#1079970: ITP: rtsp-to-webrtc -- Library for converting RTSP streams to WebRTC
Package: wnpp Severity: wishlist Owner: Edward Betts X-Debbugs-CC: debian-devel@lists.debian.org * Package name: rtsp-to-webrtc Version : 0.6.1 Upstream Author : Allen Porter * URL : https://github.com/allenporter/rtsp-to-webrtc-client * License : Apache-2.0 Programming Lang: Python Description : Library for converting RTSP streams to WebRTC This library connects to RTSPtoWeb or RTSPtoWebRTC proxy servers to convert RTSP streams to WebRTC streams. It registers with camera integrations to provide WebRTC live streams for any RTSP camera. The setup involves initiating a connection to a specified server URL and discovering the type of server. The library handles signalling, sending offers and receiving answers to establish peer connections. It enables direct communication between the frontend and the proxy server for live streaming. This library is a dependency of Home Assistant, the Python smart home platform. I plan to maintain it as part of the Home Assistant team.
Bug#1079971: ITP: buteo-sync-plugin-carddav -- Buteo Synchronization Framework CardDav synchronization plugin
Package: wnpp Severity: wishlist Owner: Mike Gabriel X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: buteo-sync-plugin-carddav Version : 0.1.10 Upstream Contact: https://sailfishos.org/contact/ * URL : https://github.com/sailfishos/buteo-sync-plugin-carddav/ * License : LGPL-2.1, BSD-3-clause Programming Lang: C++ Description : Buteo Synchronization Framework CardDav synchronization plugin The Buteo Synchronization Framework relies on plugins in order to synchronize with a variety of data sources. . This package provides a plugin for synchronizing contact data with CardDav servers for the Buteo Synchronization Framework. . This package is required by Lomiri's addressbook app and will be maintained by the Debian UBports Packaging Team.
Bug#1079974: ITP: ruuvitag-ble -- Handle RuuviTag BLE devices
Package: wnpp Severity: wishlist Owner: Edward Betts X-Debbugs-CC: debian-devel@lists.debian.org * Package name: ruuvitag-ble Version : 0.1.2 Upstream Author : Aarni Koskela * URL : https://github.com/Bluetooth-Devices/ruuvitag-ble * License : MIT Programming Lang: Python Description : Handle RuuviTag BLE devices This library provides essential functionality to manage RuuviTag Bluetooth Low Energy (BLE) devices. It allows for the efficient parsing and interpreting of data transmitted by these devices, enabling users to monitor various environmental parameters like temperature, humidity, and air pressure. Additionally, it supports the automatic discovery of RuuviTag devices once Bluetooth integration is enabled and operational. Users can ensure their devices are running the latest firmware to fully utilize the library's features. This library is well-suited for applications that require local data push from sensor devices. This library is a dependency of Home Assistant, the Python smart home platform. I plan to maintain it as part of the Home Assistant team.
