Bug#1072588: ITP: bluetooth-auto-recovery -- Tool to automatically recover stuck Bluetooth adapters
Package: wnpp Severity: wishlist Owner: Edward Betts X-Debbugs-Cc: debian-devel@lists.debian.org, debian-pyt...@lists.debian.org * Package name: bluetooth-auto-recovery Version : 1.4.0 Upstream Author : J. Nick Koston * URL : https://github.com/bluetooth-devices/bluetooth-auto-recovery * License : MIT Programming Lang: Python Description : Tool to automatically recover stuck Bluetooth adapters Python library designed to address a common issue where Bluetooth adapters remain in a stuck state, rendering them unresponsive. This package provides a mechanism to automatically detect and reset such adapters, ensuring they remain functional without requiring manual intervention. I plan to maintain this package as part of the Python team.
Bug#1072614: ITP: habluetooth -- High availability Bluetooth in Python
Package: wnpp Severity: wishlist Owner: Edward Betts X-Debbugs-Cc: debian-devel@lists.debian.org, debian-pyt...@lists.debian.org * Package name: habluetooth Version : 2.4.1 Upstream Author : J. Nick Koston * URL : https://github.com/bluetooth-devices/habluetooth * License : Apache-2.0 Programming Lang: Python Description : High availability Bluetooth in Python Python interface for managing Bluetooth devices with high availability features, designed to support robust wireless communication setups. Facilitates reliable connectivity and efficient handling of multiple devices, making it suitable for applications like home automation where consistent device availability is crucial. I plan to maintain this package as part of the Python team.
Bug#1075838: ITP: pygml -- Pure Python parser and encoder for OGC GML Geometries
Package: wnpp Severity: wishlist Owner: Edward Betts X-Debbugs-Cc: debian-devel@lists.debian.org, debian-pyt...@lists.debian.org * Package name: pygml Version : 0.2.2 Upstream Author : Fabian Schindler * URL : https://github.com/geopython/pygml * License : MIT Programming Lang: Python Description : Pure Python parser and encoder for OGC GML Geometries The Open Geospatial Consortium (OGC) is an international industry consortium that develops standards for geospatial and location-based services. Geographic Markup Language (GML) is an XML grammar defined by OGC for expressing geographical features. . Pygml supports GML versions 3.1, 3.2, compact encoded GML 3.3, and GeoRSS geometries, converting them to a Geo Interface compliant class. I plan to maintain this package as part of the Python team.
Bug#1076138: ITP: korean-lunar-calendar -- Korean lunar to Gregorian calendar conversion library
Package: wnpp Severity: wishlist Owner: Edward Betts X-Debbugs-Cc: debian-devel@lists.debian.org, debian-pyt...@lists.debian.org * Package name: korean-lunar-calendar Version : 0.3.1 Upstream Author : Jinil Lee * URL : https://github.com/usingsky/korean_lunar_calendar_py * License : MIT Programming Lang: Python Description : Korean lunar to Gregorian calendar conversion library Convert between the Korean lunar calendar and the Gregorian calendar. The Korean calendar, while similar to the Chinese lunar calendar, features different dates. The library adheres to the standards set by the Korea Astronomy and Space Science Institute (KARI). . Supports lunar date conversions from 1000-01-01 to 2050-11-18 and solar date conversions from 1000-02-13 to 2050-12-31. . No network connection is required for these operations. I plan to maintain this package as part of the Python team.
Bug#1076525: ITP: exchange-calendars -- Python library for security exchange calendars
Package: wnpp Severity: wishlist Owner: Edward Betts X-Debbugs-Cc: debian-devel@lists.debian.org, debian-pyt...@lists.debian.org * Package name: exchange-calendars Version : 4.5.5 Upstream Author : Gerry Manoim * URL : https://github.com/gerrymanoim/exchange_calendars * License : Apache-2.0 Programming Lang: Python Description : Python library for security exchange calendars This package provides a Python library for defining and querying calendars of securities exchanges. It allows users to work with trading schedules and calendars for over 50 exchanges worldwide. . The library is useful for financial analysis, algorithmic trading, and market data processing applications that need to handle exchange trading hours, breaks, and holidays accurately. . Key features include: . - Pre-defined calendars for major stock exchanges - Methods to query trading sessions, minutes, and schedules - Ability to create custom exchange calendars - Command-line utility for printing exchange calendars . This package is intended for developers and analysts working with financial market data. It requires basic knowledge of Python and financial markets terminology. I plan to maintain this package as part of the Python team.
Bug#1076628: ITP: aioimaplib -- Asynchronous IMAP4rev1 client library using Python asyncio
Package: wnpp Severity: wishlist Owner: Edward Betts X-Debbugs-Cc: debian-devel@lists.debian.org, debian-pyt...@lists.debian.org * Package name: aioimaplib Version : 1.1.0 Upstream Author : Bruno Thomas * URL : https://github.com/bamthomas/aioimaplib * License : GPL-3 Programming Lang: Python Description : Asynchronous IMAP4rev1 client library using Python asyncio Python library that implements the IMAP4rev1 protocol with an asynchronous model using asyncio. This package allows users to handle IMAP communication in a non-blocking manner, enhancing the performance of applications by leveraging the asyncio framework to manage tasks concurrently. . Key features include: - Implementation of the IDLE command (RFC2177) for efficient real-time email monitoring. - Threading support with asyncio for safe concurrent operations. - Enhanced logging capabilities and OAuth2 authentication support for services like Microsoft Outlook and potentially Google Mail. . This library is ideal for developers needing to integrate IMAP support into applications that benefit from asynchronous programming, providing capabilities like email fetching, mailbox management, and real-time notifications without blocking the application's main thread. I plan to maintain this package as part of the Python team.
Bug#1076630: ITP: python-didl-lite -- Python tools for handling DIDL-Lite XML data
Package: wnpp Severity: wishlist Owner: Edward Betts X-Debbugs-Cc: debian-devel@lists.debian.org, debian-pyt...@lists.debian.org * Package name: python-didl-lite Version : 1.4.0 Upstream Author : Steven Looman * URL : https://github.com/StevenLooman/python-didl-lite * License : Apache-2.0 Programming Lang: Python Description : Python tools for handling DIDL-Lite XML data Tools to read and write DIDL-Lite XML, aligned with the Digital Item Declaration Language (DIDL) standards used widely in multimedia systems. This library facilitates the manipulation of DIDL-Lite documents necessary for interacting with UPnP Media Servers and other digital media distribution protocols. . Key features: - Supports parsing and generating DIDL-Lite XML, following specifications from UPnP AV content directory services. - Requires manual data type coercion by the user, ensuring flexibility in data handling. - Includes examples within the package to demonstrate usage and integration. I plan to maintain this package as part of the Python team.
Bug#1076641: ITP: async-upnp-client -- Asynchronous UPnP client library for Python
Package: wnpp Severity: wishlist Owner: Edward Betts X-Debbugs-Cc: debian-devel@lists.debian.org, debian-pyt...@lists.debian.org * Package name: async-upnp-client Version : 0.39.0 Upstream Author : Steven Looman * URL : https://github.com/StevenLooman/async_upnp_client * License : Apache-2.0 Programming Lang: Python Description : Asynchronous UPnP client library for Python Designed originally for integration with Home Assistant to control DLNA DMR devices, this library offers a comprehensive toolkit for asynchronous interaction with UPnP-enabled devices using Python's asyncio. It provides robust modules for discovering, controlling, and event handling of UPnP devices as detailed in the UPnP Device Architecture, such as: . - SSDP discovery and advertisement handling through custom listeners that maintain state and callback upon device changes. - Detailed device and service interaction via client factories and server setups. - Event subscription and management, enabling responsive applications that can react to changes in device state. . With additional support for specific device profiles like Internet Gateway Devices (IGD), DLNA, and printers, this library is versatile enough for a variety of UPnP-related projects. Note that full UPnP spec compliance is not claimed, and the library may have occasional bugs or incomplete features. I plan to maintain this package as part of the Python team.
Bug#1076645: ITP: getmac -- Get MAC addresses of remote hosts and local interfaces in Python
Package: wnpp Severity: wishlist Owner: Edward Betts X-Debbugs-Cc: debian-devel@lists.debian.org, debian-pyt...@lists.debian.org * Package name: getmac Version : 0.9.4 Upstream Author : Christopher Goes * URL : https://github.com/GhostofGoes/getmac * License : MIT Programming Lang: Python Description : Get MAC addresses of remote hosts and local interfaces in Python This pure-Python package retrieves the MAC address of network interfaces and hosts on the local network. It supports various platforms, providing a consistent interface to fetch MAC addresses by interface name, IPv4/IPv6 address, or hostname. The primary function is `get_mac_address()`. . Features: - Platform-independent and pure-Python implementation. - Fetch MAC addresses of system network interfaces. - Retrieve MAC addresses of remote hosts on the local network. . Usage examples include fetching MAC addresses for different interfaces, IP addresses, and hostnames. The package also includes a command-line tool for quick usage. I plan to maintain this package as part of the Python team.
Bug#1076698: ITP: haversine -- Geographic distance calculation library for Python
Package: wnpp Severity: wishlist Owner: Edward Betts X-Debbugs-Cc: debian-devel@lists.debian.org, debian-pyt...@lists.debian.org * Package name: haversine Version : 2.8.1 Upstream Author : Julien Deniau * URL : https://github.com/mapado/haversine * License : MIT Programming Lang: Python Description : Geographic distance calculation library for Python The Haversine library provides functions to calculate the distance between two points on Earth from their latitude and longitude. Suitable for various applications in geospatial analyses, navigation, and travel optimization, the library supports distance calculations in multiple units such as kilometres, meters, miles, nautical miles, feet, and inches, as well as in radians and degrees for angular distances. I plan to maintain this package as part of the Python team.
Bug#1076707: ITP: aioairzone -- Asynchronous Python library for managing Airzone HVAC systems
Package: wnpp Severity: wishlist Owner: Edward Betts X-Debbugs-Cc: debian-devel@lists.debian.org, debian-pyt...@lists.debian.org * Package name: aioairzone Version : 0.8.0 Upstream Author : Álvaro Fernández Rojas * URL : https://github.com/Noltari/aioairzone * License : Apache-2.0 Programming Lang: Python Description : Asynchronous Python library for managing Airzone HVAC systems This library offers asynchronous control of Airzone HVAC devices, making it suitable for integration into smart home systems or custom automation scripts. It provides comprehensive functions to interact with Airzone systems through an intuitive Python API, enabling the fetching and setting of HVAC parameters such as system configuration, zone management, and device states. . Designed with home automation enthusiasts and developers in mind, the library supports modern Python versions and leverages aiohttp for efficient asynchronous HTTP requests. Users can retrieve detailed information about their HVAC zones and systems, adjust settings, and monitor changes through straightforward API calls. Examples and usage instructions are included, simplifying the process of integrating Airzone devices into broader home automation solutions. I plan to maintain this package as part of the Python team.
Bug#1076710: ITP: aioaseko -- Async Python package for the Aseko Pool Live API
Package: wnpp Severity: wishlist Owner: Edward Betts X-Debbugs-Cc: debian-devel@lists.debian.org, debian-pyt...@lists.debian.org * Package name: aioaseko Version : 0.1.1 Upstream Author : Milan Meulemans * URL : https://github.com/milanmeu/aioaseko * License : MIT Programming Lang: Python Description : Async Python package for the Aseko Pool Live API This library simplifies the process of managing pool systems by offering asynchronous methods to authenticate, retrieve account information, and interact with pool units remotely. . Key features include: - Support for both mobile and web API interactions through distinct `MobileAccount` and `WebAccount` classes. - Ability to fetch detailed pool unit states including metrics like water flow and other variable readings. - Built on aiohttp, ensuring efficient and non-blocking HTTP requests within an asyncio event loop. I plan to maintain this package as part of the Python team.
Bug#1076712: ITP: aiobafi6 -- Asynchronous Python library for controlling Big Ass Fans via the i6 protocol
Package: wnpp Severity: wishlist Owner: Edward Betts X-Debbugs-Cc: debian-devel@lists.debian.org, debian-pyt...@lists.debian.org * Package name: aiobafi6 Version : 0.9.0 Upstream Author : Jean-Francois Roy * URL : https://github.com/jfroy/aiobafi6 * License : Apache-2.0 Programming Lang: Python Description : Asynchronous Python library for controlling Big Ass Fans via the i6 protocol Python library designed to interact asynchronously with Big Ass Fans products that use the i6 protocol, including both i6 and Haiku fans updated to firmware 3.0 or later. This library provides comprehensive support for querying and controlling these fans, replicating nearly all functionalities of the older "SenseMe" protocol, but with enhancements such as occupancy support introduced in firmware 3.1. . The library includes a minimal command-line interface for direct device interaction and debugging, making it a valuable tool for developers integrating fan controls into home automation systems or custom applications. Additionally, it utilizes protocol buffers for efficient message serialization, ensuring robust and scalable communication with fan devices. I plan to maintain this package as part of the Python team.
Bug#1076714: ITP: aiocomelit -- Python library for asynchronous control of Comelit Simplehome systems
Package: wnpp Severity: wishlist Owner: Edward Betts X-Debbugs-Cc: debian-devel@lists.debian.org, debian-pyt...@lists.debian.org * Package name: aiocomelit Version : 0.9.1 Upstream Author : Simone Chemelli * URL : https://github.com/chemelli74/aiocomelit * License : Apache-2.0 Programming Lang: Python Description : Python library for asynchronous control of Comelit Simplehome systems Designed for integration with Comelit Simplehome environments, this Python library enables asynchronous interaction with Comelit's home automation systems. It provides developers with the tools to query and manage home devices efficiently within an event-driven architecture, leveraging aiohttp for high-performance asynchronous communications. . The library supports an array of functionalities to control various aspects of a Comelit Smart home, facilitating tasks from basic command execution to more complex automation and monitoring setups. I plan to maintain this package as part of the Python team.
Bug#1076719: ITP: aioeagle -- Asynchronous Python library for interfacing with Rainforest EAGLE-200 energy meters
Package: wnpp Severity: wishlist Owner: Edward Betts X-Debbugs-Cc: debian-devel@lists.debian.org, debian-pyt...@lists.debian.org * Package name: aioeagle Version : 1.1.0 Upstream Author : Paulus Schoutsen * URL : https://github.com/home-assistant-libs/aioeagle * License : Apache-2.0 Programming Lang: Python Description : Asynchronous Python library for interfacing with Rainforest EAGLE-200 energy meters This Python library provides asynchronous capabilities for interacting with Rainforest EAGLE-200 devices, enabling real-time data querying and management of home energy meters. It utilizes aiohttp for efficient network communications within an asyncio-driven architecture, suitable for modern asynchronous applications. I plan to maintain this package as part of the Python team.
Bug#1076744: ITP: meteocalc -- Python library for calculating meteorological variables
Package: wnpp Severity: wishlist Owner: Edward Betts X-Debbugs-Cc: debian-devel@lists.debian.org, debian-pyt...@lists.debian.org * Package name: meteocalc Version : 1.1.0 Upstream Author : Alex (Oleksii) Markov * URL : https://github.com/malexer/meteocalc * License : MIT Programming Lang: Python Description : Python library for calculating meteorological variables This library includes functionalities to compute the dew point, heat index, wind chill, and the 'Feels Like' temperature, which integrates air temperature, humidity, and wind speed to determine perceived temperature. I plan to maintain this package as part of the Python team.
Bug#1076746: ITP: aioecowitt -- Python library for interfacing with the EcoWitt Protocol
Package: wnpp Severity: wishlist Owner: Edward Betts X-Debbugs-Cc: debian-devel@lists.debian.org, debian-pyt...@lists.debian.org * Package name: aioecowitt Version : 2024.2.2 Upstream Author : Home Assistant Team * URL : https://github.com/home-assistant-libs/aioecowitt * License : Apache-2.0 Programming Lang: Python Description : Python library for interfacing with the EcoWitt Protocol This library provides a straightforward approach for interacting with devices that use the EcoWitt Protocol, a popular standard for home weather stations. It enables asynchronous communication and data handling, ensuring efficient integration into applications that require real-time environmental data collection and analysis. . Inspired by similar projects like pyecowitt and ecowitt2mqtt, this library aims to simplify the development process for home automation enthusiasts and developers looking to incorporate weather-related data from EcoWitt devices into their systems. The library supports asynchronous operations, making it ideal for use in larger, event-driven projects that depend on timely data updates. I plan to maintain this package as part of the Python team.
Bug#1076756: ITP: dataproperty -- Python library for extracting detailed properties from data
Package: wnpp Severity: wishlist Owner: Edward Betts X-Debbugs-Cc: debian-devel@lists.debian.org, debian-pyt...@lists.debian.org * Package name: dataproperty Version : 1.0.1 Upstream Author : Tsuyoshi Hombashi * URL : https://github.com/thombashi/DataProperty * License : MIT Programming Lang: Python Description : Python library for extracting detailed properties from data Designed to assist with the analysis and manipulation of data, this library provides a structured approach to extracting properties from various data types. It enables users to derive detailed attributes from numbers, strings, dates, and boolean values, enhancing the capability to perform in-depth data assessments and transformations. . The library supports multiple types of data property extractions including determining numerical precision, string length, and the specific nature of datetime and boolean data. Additionally, it offers tools to process matrices of data, identifying unique properties for each column or for the entire dataset, which can be integral for data cleaning, exploration, and preparing for further statistical analysis. I plan to maintain this package as part of the Python team.
Bug#1076758: ITP: python-tabledata -- Python library for tabular data representation and manipulation
Package: wnpp Severity: wishlist Owner: Edward Betts X-Debbugs-Cc: debian-devel@lists.debian.org, debian-pyt...@lists.debian.org * Package name: python-tabledata Version : 1.3.3 Upstream Author : Tsuyoshi Hombashi * URL : https://github.com/thombashi/tabledata * License : MIT Programming Lang: Python Description : Python library for tabular data representation and manipulation This library provides a comprehensive solution for representing and manipulating tabular data within Python applications. It is ideal for projects involving data tables, such as generating reports, creating data transformations, or integrating with databases. . The core functionality includes the ability to represent any dataset as a table with rich formatting and conversion options. . Additionally, it offers compatibility with other libraries like pytablewriter, pytablereader, and SimpleSQLite, enhancing its utility in database operations and data serialization/deserialization tasks. I plan to maintain this package as part of the Python team.
Bug#1076762: ITP: python-id -- Python tool for generating and managing OIDC identities
Package: wnpp Severity: wishlist Owner: Edward Betts X-Debbugs-Cc: debian-devel@lists.debian.org, debian-pyt...@lists.debian.org * Package name: python-id Version : 1.4.0 Upstream Author : The Sigstore Authors * URL : https://github.com/di/id * License : Apache-2.0 Programming Lang: Python Description : Python tool for generating and managing OIDC identities This is a versatile Python tool designed for generating and managing OpenID Connect (OIDC) identities across various environments including GitHub Actions, GitLab pipelines, and Google Cloud platforms. This tool simplifies the process of OIDC credential generation and supports automatic detection and production of credentials in supported environments. . With 'id', users can efficiently handle OIDC tokens and authentication procedures, streamlining deployment and CI/CD workflows. The tool is also equipped to work in environments like Buildkite and CircleCI, ensuring broad compatibility and utility. I plan to maintain this package as part of the Python team.
Bug#1076765: ITP: asyncio-dgram -- Enhanced Datagram protocol support for Asyncio
Package: wnpp Severity: wishlist Owner: Edward Betts X-Debbugs-Cc: debian-devel@lists.debian.org, debian-pyt...@lists.debian.org * Package name: asyncio-dgram Version : 2.2.0 Upstream Author : Justin Bronder * URL : https://github.com/jsbronder/asyncio-dgram * License : MIT Programming Lang: Python Description : Enhanced Datagram protocol support for Asyncio This package offers advanced Datagram protocol support tailored for Asyncio, inspired by suggestions for a more intuitive approach to handling datagrams in Python. It simplifies the use of datagrams by providing high-level operations that eliminate the repetitive need to extend `asyncio.DatagramProtocol` for common use cases. . The design philosophy is to streamline datagram-based communication by offering a straightforward API that diverges from the broader, sometimes cumbersome, options provided by native asyncio. It includes easy-to-use functions for connecting to a specific endpoint, binding to an address to receive data from any source, and integrating with existing sockets for custom configurations. . Ideal for applications looking to implement network communication where UDP is involved, it facilitates quick and efficient setup of UDP servers and clients, supports voice/video streaming services, or lightweight IoT protocols, all without the lower-level intricacies of socket programming. I plan to maintain this package as part of the Python team.
Bug#1076770: ITP: pytablewriter -- Library to write tables in multiple formats with custom styling
Package: wnpp Severity: wishlist Owner: Edward Betts X-Debbugs-Cc: debian-devel@lists.debian.org, debian-pyt...@lists.debian.org * Package name: pytablewriter Version : 1.2.0 Upstream Author : Tsuyoshi Hombashi * URL : https://github.com/thombashi/pytablewriter * License : MIT Programming Lang: Python Description : Library to write tables in multiple formats with custom styling This package allows you to write tables in various formats including AsciiDoc, CSV, HTML, JavaScript, JSON, LaTeX, Markdown, MediaWiki, NumPy, Excel, Pandas, Python, reStructuredText, SQLite, TOML, TSV, and YAML. . Users can benefit from automatic table cell formatting for alignment, padding, and precision of numbers. Style customization is also available, including text and background colors, text alignment, and font size or weight. Support for thousand separators in numbers is provided to enhance readability. . The table can be written to a stream such as a file, standard output, string buffer, or a Jupyter Notebook, allowing for versatile use across different applications. Additionally, the package supports rendering tabular data directly into formatted text, making it ideal for documentation or data display in various environments. I plan to maintain this package as part of the Python team.
Bug#1076777: ITP: colorthief -- Python module for extracting color palettes from images
Package: wnpp Severity: wishlist Owner: Edward Betts X-Debbugs-Cc: debian-devel@lists.debian.org, debian-pyt...@lists.debian.org * Package name: colorthief Version : 0.2.1 Upstream Author : Shipeng Feng * URL : https://github.com/fengsp/color-thief-py * License : MIT Programming Lang: Python Description : Python module for extracting color palettes from images Color Thief is a Python library that allows for extracting a color palette or the dominant color from any image. Utilizing the median cut algorithm, it provides methods to assess the primary hues and build a palette of a specified size. This tool can be useful in graphic design, art projects, and data visualization tasks. Its functionality is accessible both as a Python module and a command-line interface. I plan to maintain this package as part of the Python team.
Bug#1076781: ITP: zigpy-xbee -- Python library to interface with XBee radios using the zigpy library
Package: wnpp Severity: wishlist Owner: Edward Betts X-Debbugs-Cc: debian-devel@lists.debian.org, debian-pyt...@lists.debian.org * Package name: zigpy-xbee Version : 0.20.1 Upstream Author : Russell Cloran * URL : https://github.com/zigpy/zigpy-xbee * License : GPL-3+ Programming Lang: Python Description : Python library to interface with XBee radios using the zigpy library This library facilitates the integration of XBee modules with various home automation systems, especially Home Assistant, via the Zigbee Home Automation standard. It supports a range of Digi XBee radio modules and allows for configurations through UART connections. Users can manage their XBee devices within their Zigbee networks to control a wide array of compatible Zigbee smart devices. I plan to maintain this package as part of the Python team.
Bug#1076786: ITP: pyatag -- Asynchronous Python library for controlling Atag One thermostats
Package: wnpp Severity: wishlist Owner: Edward Betts X-Debbugs-Cc: debian-devel@lists.debian.org, debian-pyt...@lists.debian.org * Package name: pyatag Version : 0.3.7.1 Upstream Author : @MatsNL * URL : https://github.com/MatsNl/pyatag * License : MIT Programming Lang: Python Description : Asynchronous Python library for controlling Atag One thermostats PyAtag is an asynchronous Python library designed to interact with Atag One heating systems. Utilizing asyncio, and aiohttp, it provides capabilities to discover, connect, and control Atag One thermostats over a network. This includes functions to set temperature, change preset modes, and retrieve detailed device reports. I plan to maintain this package as part of the Python team.
Bug#1076790: ITP: python-rova -- Python API wrapper for accessing the ROVA waste management calendar
Package: wnpp Severity: wishlist Owner: Edward Betts X-Debbugs-Cc: debian-devel@lists.debian.org, debian-pyt...@lists.debian.org * Package name: python-rova Version : 0.4.1 Upstream Author : Gido Hakvoort * URL : https://github.com/GidoHakvoort/rova * License : MIT Programming Lang: Python Description : Python API wrapper for accessing the ROVA waste management calendar ROVA is a waste management service in the Netherlands focused on maintaining clean and sustainable living environments. This Python library serves as an API wrapper for programmatically accessing ROVA's waste collection schedules through their unofficial API. . Users can retrieve waste collection dates by providing a zip code and house number, making it easier to manage waste disposal schedules. I plan to maintain this package as part of the Python team.
Bug#1076791: ITP: pyiss -- Library for accessing real-time data of the International Space Station
Package: wnpp Severity: wishlist Owner: Edward Betts X-Debbugs-Cc: debian-devel@lists.debian.org, debian-pyt...@lists.debian.org * Package name: pyiss Version : 1.0.1 Upstream Author : Hydreliox * URL : https://github.com/HydrelioxGitHub/pyiss * License : MIT Programming Lang: Python Description : Library for accessing real-time data of the International Space Station PyIss is a Python library designed to provide real-time location and other relevant data of the International Space Station (ISS). Utilizing the open API from open-notify.org, PyIss offers users easy access to ISS positional data, upcoming pass predictions, crew details, and more. Perfect for educational purposes, space enthusiasts, or any application requiring ISS tracking and data retrieval. I plan to maintain this package as part of the Python team.
Bug#1076792: ITP: pyyardian -- Python module for controlling Yardian irrigation systems
Package: wnpp Severity: wishlist Owner: Edward Betts X-Debbugs-Cc: debian-devel@lists.debian.org, debian-pyt...@lists.debian.org * Package name: pyyardian Version : 1.2.0 Upstream Author : Marty Sun * URL : https://github.com/h3l1o5/pyyardian * License : MIT Programming Lang: Python Description : Python module for controlling Yardian irrigation systems PyYardian enables direct communication with Yardian devices using their IP addresses. This module simplifies the integration and automation of Yardian controllers in home automation or custom applications, providing an efficient way to manage irrigation schedules, monitor system status, and execute commands remotely. I plan to maintain this package as part of the Python team.
Bug#1076793: ITP: python-base36 -- Python implementation of base36 encoding and decoding
Package: wnpp Severity: wishlist Owner: Edward Betts X-Debbugs-Cc: debian-devel@lists.debian.org, debian-pyt...@lists.debian.org * Package name: python-base36 Version : 0.1.1 Upstream Author : Jiangge Zhang * URL : https://github.com/tonyseek/python-base36 * License : MIT Programming Lang: Python Description : Python implementation of base36 encoding and decoding Base36 is a Python library providing yet another implementation for the base36 encoding system, a positional numeral system with a radix of 36. It allows for the encoding of integers into a compact alphanumeric string and the decoding back to integers. This package supports direct conversion between numbers and their base36 representations, making it suitable for applications that require short, human-readable numeric identifiers. I plan to maintain this package as part of the Python team.
Bug#1076794: ITP: brottsplatskartan -- API wrapper for accessing Brottsplatskartan crime data
Package: wnpp Severity: wishlist Owner: Edward Betts X-Debbugs-Cc: debian-devel@lists.debian.org, debian-pyt...@lists.debian.org * Package name: brottsplatskartan Version : 1.0.5 Upstream Author : chrillux * URL : https://github.com/chrillux/brottsplatskartan * License : MIT Programming Lang: Python Description : API wrapper for accessing Brottsplatskartan crime data This Python package provides a simple API wrapper for accessing Swedish crime data from Brottsplatskartan.se. It allows developers to easily retrieve information about incidents based on geographical areas or specific coordinates. This library is a dependancy of Home Assistant, the Python smart home platform. I plan to maintain it as part of the Python team.
Bug#1076795: ITP: open-garage -- Python library for OpenGarage automation
Package: wnpp Severity: wishlist Owner: Edward Betts X-Debbugs-Cc: debian-devel@lists.debian.org, debian-pyt...@lists.debian.org * Package name: open-garage Version : 0.2.0 Upstream Author : Daniel Hjelseth Høyer * URL : https://github.com/Danielhiversen/pyOpenGarage * License : MIT Programming Lang: Python Description : Python library for OpenGarage automation This library provides Python bindings for interacting with OpenGarage devices, which offer smart garage door control. It enables developers to integrate garage door operations within their Python applications, utilizing asynchronous communication through aiohttp. The library supports various features of the OpenGarage API, allowing for monitoring and control of garage doors remotely. Ideal for home automation projects, this tool facilitates seamless integration with OpenGarage's innovative garage solutions, enhancing the functionality and accessibility of home automation systems. This library is a dependancy of Home Assistant, the Python smart home platform. I plan to maintain it as part of the Python team.
Bug#1076798: ITP: python-fullykiosk -- Python library for Fully Kiosk Browser's REST API
Package: wnpp Severity: wishlist Owner: Edward Betts X-Debbugs-Cc: debian-devel@lists.debian.org, debian-pyt...@lists.debian.org * Package name: python-fullykiosk Version : 0.0.14 Upstream Author : Charles Garwood * URL : https://github.com/cgarwood/python-fullykiosk * License : Apache-2.0 Programming Lang: Python Description : Python library for Fully Kiosk Browser's REST API This Python wrapper provides an interface to interact with the Fully Kiosk Browser's REST API, a robust kiosk browser designed for Android devices. The browser offers extensive features for device management and control, ideal for deployments in kiosk settings. With this library, developers can programmatically access functionalities like device status, control commands, and settings management. It supports comprehensive control over the browser's features, including motion detection, screensaver settings, and media playback controls. It also facilitates device monitoring, providing details on battery level, storage space, and RAM usage. This library is a dependancy of Home Assistant, the Python smart home platform. I plan to maintain it as part of the Python team.
Bug#1076799: ITP: pykmtronic -- Python library for interfacing with KM-Tronic web relays
Package: wnpp Severity: wishlist Owner: Edward Betts X-Debbugs-Cc: debian-devel@lists.debian.org, debian-pyt...@lists.debian.org * Package name: pykmtronic Version : 0.3.0 Upstream Author : Diogo Gomes * URL : https://github.com/dgomes/pykmtronic * License : MIT Programming Lang: Python Description : Python library for interfacing with KM-Tronic web relays KM-Tronic web relays are widely used for remote control applications across various industries. This library allows users to programmatically manage and automate the operations of KM-Tronic web relays through a straightforward Python interface. It supports specific models like the W2CR two-channel web relay, enabling developers to integrate relay control into their applications effectively. This library is a dependancy of Home Assistant, the Python smart home platform. I plan to maintain it as part of the Python team.
Bug#1076801: ITP: py-nextbusnext -- Python client for accessing real-time transit data from the NextBus API
Package: wnpp Severity: wishlist Owner: Edward Betts X-Debbugs-Cc: debian-devel@lists.debian.org, debian-pyt...@lists.debian.org * Package name: py-nextbusnext Version : 2.0.3 Upstream Author : ViViDboarder * URL : https://github.com/ViViDboarder/py_nextbusnext * License : MIT Programming Lang: Python Description : Python client for accessing real-time transit data from the NextBus API A minimalistic Python client that interfaces with the NextBus public API, which delivers real-time public transport arrival data. This library facilitates the retrieval of information on transport routes, predictions, and schedules, making it ideal for applications that depend on current public transit updates. This library is a dependancy of Home Assistant, the Python smart home platform. I plan to maintain it as part of the Python team.
Bug#1076804: ITP: faadelays -- Python package to access FAA airport status data
Package: wnpp Severity: wishlist Owner: Edward Betts X-Debbugs-Cc: debian-devel@lists.debian.org, debian-pyt...@lists.debian.org * Package name: faadelays Version : 2023.9.1 Upstream Author : Nathan Tilley * URL : https://github.com/ntilley905/faadelays * License : MIT Programming Lang: Python Description : Python library for FAA airport status data This library facilitates access to real-time airport status data from the Federal Aviation Administration's (FAA) NAS Status API. The FAA, an agency of the United States Department of Transportation, regulates all aspects of civil aviation in the U.S. . This library provides detailed information about various aspects of airport operations including delays, ground stops, closures, and runway configurations. Each type of information is encapsulated in specific classes such as ArriveDepartDelay, GroundDelay, GroundStop, Closure, and AirportConfig, offering developers comprehensive insights into the operational status at different airports across the United States. This library is a dependancy of Home Assistant, the Python smart home platform. I plan to maintain it as part of the Python team.
Bug#1076807: ITP: python-qnapstats -- Python API for accessing QNAP NAS system statistics
Package: wnpp Severity: wishlist Owner: Edward Betts X-Debbugs-Cc: debian-devel@lists.debian.org, debian-pyt...@lists.debian.org * Package name: python-qnapstats Version : 0.4.0 Upstream Author : Colin O'Dell * URL : https://github.com/colinodell/python-qnapstats * License : MIT Programming Lang: Python Description : Python API for accessing QNAP NAS system statistics This library provides a Python interface to retrieve system information from QNAP NAS devices. It allows for the extraction of comprehensive system statistics, including health data, disk information, network bandwidth usage, and more. This library is a dependancy of Home Assistant, the Python smart home platform. I plan to maintain it as part of the Python team.
Bug#1076842: ITP: aiohttp-fast-url-dispatcher -- Enhanced URL dispatcher for aiohttp for improved performance
Package: wnpp Severity: wishlist Owner: Edward Betts X-Debbugs-Cc: debian-devel@lists.debian.org, debian-pyt...@lists.debian.org * Package name: aiohttp-fast-url-dispatcher Version : 0.3.1 Upstream Author : J. Nick Koston * URL : https://github.com/bdraco/aiohttp-fast-url-dispatcher * License : Apache-2.0 Programming Lang: Python Description : Enhanced URL dispatcher for aiohttp for improved performance This library introduces an optimized URL dispatcher for the aiohttp web server framework, designed to enhance routing performance by using an indexing system. Unlike the default UrlDispatcher which performs a linear search, potentially slowing down response times with a large number of routes, the FastUrlDispatcher maintains an index of URLs to ensure quick URL dispatch. This improvement is especially beneficial for applications with extensive routing requirements. This library is a dependancy of Home Assistant, the Python smart home platform. I plan to maintain it as part of the Python team.
Bug#1076844: ITP: aiozoneinfo -- Asynchronous tools for fetching timezone information in Python
Package: wnpp Severity: wishlist Owner: Edward Betts X-Debbugs-Cc: debian-devel@lists.debian.org, debian-pyt...@lists.debian.org * Package name: aiozoneinfo Version : 0.2.1 Upstream Author : J. Nick Koston * URL : https://github.com/bluetooth-devices/aiozoneinfo * License : Apache-2.0 Programming Lang: Python Description : Asynchronous tools for fetching timezone information in Python This library provides asynchronous tools for efficiently fetching timezone information, ensuring non-blocking operations within applications using asyncio. By utilizing an internal cache and an executor for disk operations, aiozoneinfo avoids I/O blocking in the event loop, thereby enhancing performance in applications requiring time zone data. This library is a dependancy of Home Assistant, the Python smart home platform. I plan to maintain it as part of the Python team.
Bug#1076855: ITP: mopeka-iot-ble -- Python library for parsing Mopeka IoT BLE sensor data
Package: wnpp Severity: wishlist Owner: Edward Betts X-Debbugs-Cc: debian-devel@lists.debian.org, debian-pyt...@lists.debian.org * Package name: mopeka-iot-ble Version : 0.7.0 Upstream Author : J. Nick Koston * URL : https://github.com/bluetooth-devices/mopeka-iot-ble * License : MIT Programming Lang: Python Description : Python library for parsing Mopeka IoT BLE sensor data This library provides tools for integrating and parsing Bluetooth Low Energy (BLE) data from Mopeka IoT sensors. It is designed to facilitate the development of applications that interact with Mopeka's innovative sensor technology, which is widely used for monitoring various environmental parameters via BLE. The library simplifies the process of connecting to and interpreting data from Mopeka sensors, making it easier for developers to implement IoT solutions that leverage real-time sensor data. This library is a dependancy of Home Assistant, the Python smart home platform. I plan to maintain it as part of the Python team.
Bug#1076856: ITP: freenub -- Open-source fork of PubNub with an MIT license for real-time messaging
Package: wnpp Severity: wishlist Owner: Edward Betts X-Debbugs-Cc: debian-devel@lists.debian.org, debian-pyt...@lists.debian.org * Package name: freenub Version : 0.1.0 Upstream Author : J. Nick Koston * URL : https://github.com/bdraco/freenub * License : MIT Programming Lang: Python Description : Open-source fork of PubNub with an MIT license for real-time messaging Freenub is an open-source Python library originally forked from PubNub, a service for real-time messaging over the web. Maintaining its basis on an earlier version that was under the MIT license, Freenub enables developers to easily implement real-time data streaming and broadcasting functionalities within their applications. This library supports various features like real-time messaging, presence indicators, and scalable channels for communications across devices and platforms. This library is a dependancy of Home Assistant, the Python smart home platform. I plan to maintain it as part of the Python team.
Bug#1076857: ITP: notifications-android-tv -- Python API to send notifications to Android TV and Fire TV devices
Package: wnpp Severity: wishlist Owner: Edward Betts X-Debbugs-Cc: debian-devel@lists.debian.org, debian-pyt...@lists.debian.org * Package name: notifications-android-tv Version : 1.2.2 Upstream Author : Rami Mosleh * URL : https://github.com/engrbm87/notifications_android_tv * License : MIT Programming Lang: Python Description : Python API to send notifications to Android TV and Fire TV devices This library interfaces with the "Notifications for Android TV" and "Notifications for Fire TV" applications, allowing users to display customized messages on their television screens. Features include customizable titles, duration, font sizes, positions, background colors, and transparency levels for the notifications. The package supports interactive notifications that can be dismissed or expanded for more details, and it can handle local or remote image sources for notification icons. This library is a dependancy of Home Assistant, the Python smart home platform. I plan to maintain it as part of the Python team.
Bug#1076936: ITP: pyeverlights -- Python library for controlling EverLights lighting systems
Package: wnpp Severity: wishlist Owner: Edward Betts X-Debbugs-Cc: debian-devel@lists.debian.org, debian-pyt...@lists.debian.org * Package name: pyeverlights Version : 0.1.0 Upstream Author : Jon Caruana * URL : https://github.com/joncar/pyeverlights * License : MIT Programming Lang: Python Description : Python library for controlling EverLights lighting systems Users can program different zones with specific colors or patterns directly through Python scripts. The library supports tasks such as setting solid colors, activating saved patterns, and retrieving the status of the control box. It leverages asyncio for asynchronous communication, making it suitable for integration into home automation systems or complex lighting setups requiring real-time control. This library is a dependancy of Home Assistant, the Python smart home platform. I plan to maintain it as part of the Python team.
Bug#1076937: ITP: fivem-api -- Library for querying server info from FiveM, a multiplayer platform for GTA V
Package: wnpp Severity: wishlist Owner: Edward Betts X-Debbugs-Cc: debian-devel@lists.debian.org, debian-pyt...@lists.debian.org * Package name: fivem-api Version : 0.1.2 Upstream Author : Sander Jochems * URL : https://github.com/Sander0542/fivem-api * License : MIT Programming Lang: Python Description : Library for querying server info from FiveM, a multiplayer platform for GTA V This library enables interaction with FiveM servers—platforms that extend Grand Theft Auto V by Rockstar Games with the ability to play online with custom modifications. The library allows for efficient querying of server details, including the current list of active players, maximum player capacities, and resources loaded on the server. Utilizing asynchronous HTTP requests through aiohttp, it provides a robust toolset for integrating real-time FiveM server data into applications or for monitoring server status. Ideal for community tools, game server dashboards, or enhancing gaming experiences with external data access. This library is a dependancy of Home Assistant, the Python smart home platform. I plan to maintain it as part of the Python team.
Bug#1076938: ITP: airthings-cloud -- Python library for interfacing with Airthings devices
Package: wnpp Severity: wishlist Owner: Edward Betts X-Debbugs-Cc: debian-devel@lists.debian.org, debian-pyt...@lists.debian.org * Package name: airthings-cloud Version : 0.2.0 Upstream Author : Daniel Hjelseth Høyer * URL : https://github.com/Danielhiversen/pyAirthings * License : MIT Programming Lang: Python Description : Python library for interfacing with Airthings devices This library enables efficient communication with Airthings air quality sensors, particularly those that measure radon levels. Airthings devices are designed to monitor and report on various environmental parameters, enhancing indoor air quality management. This library requires an Airthings account and a valid API setup to function correctly, allowing users to authenticate and retrieve data seamlessly. It supports asynchronous operations and can be integrated into systems that require continuous environmental monitoring. This library is a dependancy of Home Assistant, the Python smart home platform. I plan to maintain it as part of the Python team.
Bug#1076941: ITP: airthings-ble -- Control Airthings devices via BLE for Python environments
Package: wnpp Severity: wishlist Owner: Edward Betts X-Debbugs-Cc: debian-devel@lists.debian.org, debian-pyt...@lists.debian.org * Package name: airthings-ble Version : 0.9.0 Upstream Author : Vincent Giorgi * URL : https://github.com/Airthings/airthings-ble * License : MIT Programming Lang: Python Description : Control Airthings devices via BLE for Python environments This library provides the tools necessary to interface with Airthings devices using Bluetooth Low Energy (BLE) technology. It supports direct communication with various Airthings products, facilitating the monitoring and control of air quality sensors from Python applications. The library is primarily designed for integration with systems that utilize BLE for device interaction. It includes functionality for device discovery, data retrieval, and command transmission, enhancing the ease of integrating air quality monitoring into tech-driven solutions. This library is a dependancy of Home Assistant, the Python smart home platform. I plan to maintain it as part of the Python team.
Bug#1076942: ITP: python-luftdaten -- Python API for accessing air quality data from Sensor.Community
Package: wnpp Severity: wishlist Owner: Edward Betts X-Debbugs-Cc: debian-devel@lists.debian.org, debian-pyt...@lists.debian.org * Package name: python-luftdaten Version : 0.7.4 Upstream Author : Fabian Affolter * URL : https://github.com/home-assistant-ecosystem/python-luftdaten * License : MIT Programming Lang: Python Description : Python API for accessing air quality data from Sensor.Community This library provides an interface to interact with the open data from Sensor.Community, formerly known as luftdaten.info. It allows users to retrieve air quality measurements and other environmental data from a variety of self-built sensor stations. By utilizing the API, developers can monitor particulate matter, temperature, humidity, and other relevant environmental parameters from sensors registered on the Sensor.Community network. The library simplifies the integration of real-time environmental data into applications, making it particularly valuable for projects related to health, environmental awareness, or scientific research. This module facilitates easy access to sensor data, empowering users to make informed decisions based on air quality indicators. This library is a dependancy of Home Assistant, the Python smart home platform. I plan to maintain it as part of the Python team.
Bug#1076945: ITP: progettihwsw -- Control ProgettiHWSW relay boards via Python
Package: wnpp Severity: wishlist Owner: Edward Betts X-Debbugs-Cc: debian-devel@lists.debian.org, debian-pyt...@lists.debian.org * Package name: progettihwsw Version : 0.1.3 Upstream Author : Arda Seremet * URL : https://github.com/ardaseremet/progettihwsw * License : MIT Programming Lang: Python Description : Control ProgettiHWSW relay boards via Python This library provides tools for controlling ProgettiHWSW relay boards, which are used in various automation and control systems. This opens up possibilities for applications in home automation, industrial settings, or any system requiring reliable hardware control. This library is a dependancy of Home Assistant, the Python smart home platform. I plan to maintain it as part of the Python team.
Bug#1076948: ITP: switchbot-api -- Asynchronous Python library for interacting with Switchbot API
Package: wnpp Severity: wishlist Owner: Edward Betts X-Debbugs-Cc: debian-devel@lists.debian.org, debian-pyt...@lists.debian.org * Package name: switchbot-api Version : 2.2.1 Upstream Author : Ravaka Razafimanantsoa * URL : https://github.com/SeraphicCorp/py-switchbot-api * License : MIT Programming Lang: Python Description : Asynchronous Python library for interacting with Switchbot API This Python library offers asynchronous capabilities to interact with the Switchbot API, enabling control over both devices and remotes. The library supports commands such as device listing, status checking, and sending specific commands to devices. This library is a dependancy of Home Assistant, the Python smart home platform. I plan to maintain it as part of the Home Assistant team.
Bug#1076951: ITP: ourgroceries -- Async Python library for interfacing with OurGroceries API
Package: wnpp Severity: wishlist Owner: Edward Betts X-Debbugs-Cc: debian-devel@lists.debian.org, debian-pyt...@lists.debian.org * Package name: ourgroceries Version : 1.5.4 Upstream Author : Leonardo Merza * URL : https://github.com/ljmerza/py-our-groceries * License : MIT Programming Lang: Python Description : Async Python library for interfacing with OurGroceries API This library provides a means to interact with the OurGroceries API, allowing for management of grocery lists programmatically. Designed for asynchronous operations, it supports functionalities like logging in, retrieving, creating, and modifying grocery lists and their items. Additionally, users can manage categories within the lists, cross off items, and handle list deletions. This library is a dependancy of Home Assistant, the Python smart home platform. I plan to maintain it as part of the Home Assistant team.
Bug#1077081: ITP: voluptuous-openapi -- Convert Voluptuous schemas to OpenAPI Schema object
Package: wnpp Severity: wishlist Owner: Edward Betts X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: voluptuous-openapi Version : 0.0.4 Upstream Author : Denis Shulyaka * URL : https://github.com/Shulyaka/voluptuous-openapi * License : Apache-2.0 Programming Lang: Python Description : Convert Voluptuous schemas to OpenAPI Schema object Voluptuous OpenAPI allows for the transformation of Voluptuous schemas into OpenAPI Schema objects. It supports custom serializers for processing custom validators, ensuring flexibility in schema definition. This library is a dependancy of Home Assistant, the Python smart home platform. I plan to maintain it as part of the Home Assistant team.
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#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.
Bug#1079986: ITP: hatasmota -- Library for interacting with Tasmota devices via MQTT
Package: wnpp Severity: wishlist Owner: Edward Betts X-Debbugs-CC: debian-devel@lists.debian.org * Package name: hatasmota Version : 0.9.2 Upstream Author : Erik Montnemery * URL : https://github.com/emontnemery/hatasmota * License : MIT Programming Lang: Python Description : Library for interacting with Tasmota devices via MQTT This library allows communication with Tasmota-enabled devices using the MQTT protocol. It effectively handles the parsing and construction of MQTT messages for integration with Tasmota firmware. The library supports various Tasmota functionalities including buttons, fans, lights, relays, sensors, shutters, and switches. 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#1080015: ITP: python-energyzero -- Fetch dynamic energy and gas prices from EnergyZero
Package: wnpp Severity: wishlist Owner: Edward Betts X-Debbugs-CC: debian-devel@lists.debian.org * Package name: python-energyzero Version : 2.1.1 Upstream Author : Klaas Schoute * URL : https://github.com/klaasnicolaas/python-energyzero * License : MIT Programming Lang: Python Description : Fetch dynamic energy and gas prices from EnergyZero This library retrieves dynamic energy and gas prices from EnergyZero, providing detailed information such as current and next hour electricity market prices, average electricity price, lowest and highest energy prices, and the specific times when these prices are at their extremes. For gas prices, it retrieves the current and next hour prices, which are updated daily. The data is beneficial for those who need to understand daily and hourly fluctuations in energy costs. 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#1080016: ITP: pyhomematic -- Provides communication with Homematic devices
Package: wnpp Severity: wishlist Owner: Edward Betts X-Debbugs-CC: debian-devel@lists.debian.org * Package name: pyhomematic Version : 0.1.78 Upstream Author : Daniel Perna * URL : https://github.com/danielperna84/pyhomematic * License : MIT Programming Lang: Python Description : Provides communication with Homematic devices This library enables bi-directional communication with Homematic devices through a central control unit (CCU) or Homegear. Utilizing XML-RPC, it supports setting values on devices and subscribing to receive events emitted by these devices and the control unit. This library ensures integration of a wide range of device types such as binary sensors, climate devices, light controls, and more. Additionally, convenient methods are provided for interacting with devices, including querying statuses and executing commands. Users can also establish multiple interfaces for different protocols, manage system variables, and handle events to trigger automations or other processes. 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.
Re: dhcpcd procedure
Dpk <[EMAIL PROTECTED]> wrote: > What would be the best way to check for this? A simple 'ps |grep > dhcpcd' ? Would doing so make my package dependent on procps? or is > there a convenient way to check the installed version of dhcpcd > someway? Check $2 Debian Packaging Manual --- 6.2. Summary of ways maintainer scripts are called -- * `install' * `install' * `upgrade' * `abort-upgrade' * `configure' * `abort-upgrade' * `abort-remove' `in-favour' * `abort-deconfigure' `in-favour' `removing' * `remove' * `upgrade' * `failed-upgrade' * `remove' `in-favour' * `deconfigure' `in-favour' `removing' * `remove' * `purge' * `upgrade' * `failed-upgrade' * `abort-install' * `abort-install' * `abort-upgrade' * `disappear' overwrit>r> -- I consume, therefore I am
Re: SSH never free
Joel Klecker <[EMAIL PROTECTED]> wrote: > If we step into the "patents make something non-free" trap, then we > probably have a lot of things in main that should be moved to > non-free because they technically infringe on someone's stupid patent. Living in the UK, where there are currently no software patenets, I tend to agree with you. But there is some inconsistancy, for example all the gif that is in non-free because of patents. -- I consume, therefore I am pgp7VRzSf3p51.pgp Description: PGP signature
Debian recommended software
Martin Mitchell <[EMAIL PROTECTED]> wrote: > "J.H.M. Dassen \(Ray\)" <[EMAIL PROTECTED]> writes: > > I switched to lftp myself at the time of the previous ncftp license issue, > > and haven't looked back. Is there anything in ncftp that lftp doesn't have? > > If there isn't, I'd say just drop it. > > I did likewise, and haven't looked back either. I am in exactly the same position, I think lftp is a great ftp client. I think that one of the problems with Debian is the extreme numbers of packages, how do people know which to pick? We have the standard priority, which is where we put `standard' software in, but what does this mean to the user? If the bog standard ftp is in standard, does that mean that we recommend that people run normally ftp. If they want a better ftp client they have got to go through the net section, trying all of them until they get to a good one. It is the same for other things like list server. I used berolist to start with, and it is terrible. Then I tried smartlist, and it was great. The problem is there are so many to look at. I understand it would be almost impossible for Debian to provided a list of software we all recommend, because we are all individuals and would disagree, but here is my list: Shell: bash This is the default, and the only other shell that I would think of using is zsh, some people run tcsh. MTA: exim Again this is the default, I was running when smail was the default (had to hunt it out as described above) MUA: mutt This is not the default, the only two mail clients with standard priority are mailx and elm++, do we recommend people run them? MDA: procmail This is standard priority, but exim is not configured to use it, people have to mess with .forward files. list server: smartlist Needs modifications to exim.conf found on the www.exim.org homepage to function well. pop3 fetcher: fetchmail I think this is the only pop3 mail fetcher in debian, there used to be loads more, where did they go? news-client: slrn I use trn but I would recommend slrn to others. vi: vim I am not arguring this should be the recommended editor, just the recommended version of vi. I do not think that any package should be the recommended editor, I use vim as my default editor, but I would not recommend it for newbies, I think we need an editor like the DOS Edit or MS-Windows Notepad, and we do not have it, fte, comes close, but does not work over telnet. ftp server: proftp/wuftp what is the difference? proftp has security holes, but supports non-ip based virtual hosting? wuftp doesn't? ftpd actually has a recommendation that people run proftp or wuftp web server: apache web-robot: wget ftp client: lftp irc-client: epic4 Another problem is that all of these are console based tools. What happens when people move to X windows, the toolset changes completely. Do the task-* packages go some way to solving this problem? -- I consume, therefore I am pgpyLRQFNEJR7.pgp Description: PGP signature
Re: Debian recommended software (moving off-topic)
Martin Bialasinski <[EMAIL PROTECTED]> wrote: > > * "Edward" == Edward Betts <[EMAIL PROTECTED]> wrote: > > Edward> MDA: procmail > Edward> This is standard priority, but exim is not configured to use it, > people have > Edward> to mess with .forward files. > > exim has its own filter facility, that is easier to understand and use > by new users. Can users alter the exim config? I suppose we are thinking off single user machines where sysadmin == user. > Edward> ftp server: proftp/wuftp > Edward> what is the difference? proftp has security holes, > > had not has. Or are you aware of any open ones? Sorry, that was not far of me at all was it. I think proftp had some security bugs, that have been fixed, but there is a thought based on the way it was designed that there are probably more. -- I consume, therefore I am
Re: Debian recommended software
Alexander Koch <[EMAIL PROTECTED]> wrote: > Transport-wise: > > |local_delivery: > | driver = pipe > | command="/usr/bin/procmail" > | umask=0022 > > (This can be enhanced with a "required_files = ~/:~/.procmailrc" or > any such things (needing the procmail binary itself, the other > transport (the old local_delivery) can still be in there) Does this check whether the procmail executable exists on every mail delivery? is that going to slow the whole thing down a bit. Otherwise I think this is a good idea. Another possiblity would be to stick the check in the exim config script, Would you like to use procmail are your MTA [n/Y]? You could check if it the procmail executable is installed, but exim might be configured before procmail is installed. -- I consume, therefore I am
Re: doom source GPL'd
Andre Majorel <[EMAIL PROTECTED]> wrote: > Please by all means use the latest semi-public beta (no link from the > home page) http://www.teaser.fr/~amajorel/yadex/yadex-1.1.0.tar.gz. > Yadex 1.0.1 is severely obsolete. Now that I'm done with DeuTex, I hope > to resume work on Yadex and release v1.1.1 this month. Let me know how > it goes for you. > > I would also love to see the following utilities packaged : > > - xwadtools (ftp://ftp.cdrom.com/pub/idgames/source/xwadtools-*.tar.gz) > A large collection of Doom hacking utilities, including an editor, > tkwadcad. Definitely a must. > > - DeuTex (http://www.teaser.fr/~amajorel/deutex/) At this rate we are going to need a tasks-doom > > I'm unsure whether Doom hacking utils can go in the main section at > all because I seem to remember that id set some conditions on them. They should have a clear licence in the .tar.gz files surely? If somebody writes a wad editor from scratch then ID can have no affect on the licencing surely? > They shouldn't work with the shareware iwad, the resulting wads > shouldn't be sold for profit, stuff like that. Would the GPLization > of Doom change that ? How can they put limitations on your piece off work, I do not understand, do they have a patent on wad files (I do not think so). -- I consume, therefore I am
linking binfmt_misc with mime-types
Brian May <[EMAIL PROTECTED]> wrote: > The only thing that comes to mind, is to implement a mini-program > (unless it already has been written) that takes two parameters, eg > > run-mime-type text/html /path/to/file.html > > That would automatically parse /etc/mailcap and do the `right' thing, > for the file /path/to/file.html, given it is text/html. > > Entries in /etc/binfmt_misc would contain statements like the above > instead of the end program. > > This could be implemented with you original proposal with no changes > (except the extra program), but having it integrated with the mime setup > would be nice ;-). Could I clarify some stuff please? Are we proposing that all mime-types have binfmt_misc setup? Does that mean, the kernel will be able to `run' any file in mailcap? Is that what we really want? I am neither fore, nor against this idea. On the one hand it would be quite cool, entering the name of an html document on the command line and it loading in lynx. On the other hand it goes against the Unix philosophy a bit, documents are programs are documents. Another question is are their mime-types for all the programs we might want to run in this way? The programs I can think of off-hand, are Java, DOS EXE, and Windows EXE, are there any others? If we go with the ability to run documents like images and so on, do we have all the mime-types? Are we going to have to invent new mime-types? Is that a bad thing to do? Some more questions. Is it possible to recognise an html file by a couple of magic numbers at the beginning? Most html starts or , but it is not certian that it will look like this. Another thought is the possiblilty of running perl scripts without the bang path, but then how would the shell tell it is a perl script. If we put loads of entries into binfmt_misc are we likely to fill some kernel data table? What happens if it overloads? Do we significantly affect the performance of the system? If the kernel is checking each file against a list of magic numbers will it take a long time to run a file? (Probably not the kernel is fast, and most files we will run will be ELF, which is probably checked first.) This is not user independant is it? The system can not be set so that one user has support for running Java/JPEGs from the command line, and another does not? -- I consume, therefore I am
Some developers still using slink?
Santiago Vila <[EMAIL PROTECTED]> wrote: > As a general rule, as long as you can run the result in potato without > using oldlibs packages, it should be fine. [ Personal note: Most of the > packages I maintain depend on libc6 and nothing more. For this reason I > have not upgraded to potato yet. This way my uploads are usable by both > slink and potato users ]. So how many other developers are not using unstable? Is everybody have going to produced glibc 2.1 packages by the time potato ships? When do people plan to change? During the freeze? Just before? -- I consume, therefore I am
Re: So, what's up with the XFree86 4.0 .debs?
Branden Robinson <[EMAIL PROTECTED]> wrote: > Also, in case it was unclear in my previous mail, I have no plans to > support full versions of XFree86 3.3.x and 4.x in the same Debian release. > By the time official 4.0 .debs are ready, it is my hope that the legacy > chipsets currently only supported in 3.3.x will be supported in 4.x as > well. 3.3.x libc5-compatibility libraries will be provided for i386 and > m68k per my previous mail until and unless consensus is reached that this > support should be dropped. I thought the plan was to drop support for ISA VGA cards in 4.x, so people who want to keep using old hardware HAVE to stick with 3.3.x I am not actually suggesting that you try and maintain both. It would make the upgrade path easier if everything had a 4 in it, so that people stay with 3.3.x and do not move until they decide they want the new version. I mean how do you plan to handle the fact that the config file format has changed? Does anybody have a converter? On the other hand, I suppose it is probably useful to force people to upgrade to the new version. The old version will probably not be maintained upstream. You are going to keep /usr/X11R6 for this release right? I guess that the XFree86 people might get a bit irritated if you tried to drop it. (No, I am not using an ISA VGA card. No, I do not know anybody who is using one. But, I did use X 3.3.x on a EGA card for a while, I see that xega is not even in the archive now.) -- while :;do read x;echo \?;done
Re: So, what's up with the XFree86 4.0 .debs?
Branden Robinson <[EMAIL PROTECTED]> wrote: > On Mon, Mar 13, 2000 at 02:22:10AM +0000, Edward Betts wrote: > > I thought the plan was to drop support for ISA VGA cards in 4.x, so people > > who want to keep using old hardware HAVE to stick with 3.3.x > > If so, that's news to me and I've been following the XFree86 developers' > list for months. Support for the ISA bus is not being dropped. Whether > the legacy hardware is supported depends on if anybody ports the old 3.3.x > drivers to the new server model or not. Okay. I am being vague and annoying. I will give some flesh to my rambling. I went to Linux Kongress in Germany last year and saw a talk on XFree86 4 by some of the XFree86 developers. They said `Hands up people in the audience who are using ISA VGA cards' and then said they would not support them in XFree86. They said that the core developers probably will not be providing drivers, if other people write drivers and are willing to MAINTAIN them then they will go in. The deal was that they did not want drivers without people committed to looking after them and updating them. But then again I might be wrong. > > You are going to keep /usr/X11R6 for this release right? I guess that the > > XFree86 people might get a bit irritated if you tried to drop it. > > Actually, I've evilly been toying with the idea of #defining ProjectRoot to > /usr for 4.0. Upstream has already moved almost entirely to the way Debian > currently does things as far as filesystem layout goes. Go on! Do it! #define ProjectRoot /usr I dare you. -- while :;do read x;echo \?;done
Re: Single architecture on -announce lists
Tom Lees <[EMAIL PROTECTED]> wrote: > On Sat, Mar 18, 2000 at 05:30:41PM +0100, Paul Seelig wrote: > > Currently i've subscribed to devel-changes on another mail account which > > only serves for sorting out the relevant (at least for me) parts. These > > are sorted out using procmail (which is not supported by my usual mail > > server) and are forwarded this way to my usual mail account, dropping the > > rest (IMHO the major part) into the bit bucket. > > Could you possibly post/email me your procmail recipes to do this? There are a set of rules for handling this that come with devscripts. Install devscripts and have a look in /usr/share/doc/devscripts/examples/ -- while :;do read x;echo \?;done
ITP: cmatrix
Package: cmatrix Status: install ok installed Priority: optional Section: misc Installed-Size: 76 Maintainer: Edward Betts <[EMAIL PROTECTED]> Version: 1.0b-1 Depends: libc6 (>= 2.1), libncurses4 (>= 4.2-3.1), xbase-clients (>= 3.3.3.1-5), kbd-compat | kbd Description: Console Matrix simulates the display from "The Matrix" It is based on the screensaver from the movie's website. It works with terminal settings up to 132x300 and can scroll lines all at the same rate or asynchronously and at a user-defined speed. GPL. -- while :;do read x;echo \?;done pgpb4DxThH1h0.pgp Description: PGP signature
Re: ITP: cmatrix
David Starner <[EMAIL PROTECTED]> wrote: > On Sun, Mar 26, 2000 at 05:32:13PM +0100, Edward Betts wrote: > > Did this message mess with GnuPG on any one else's system? > I had to kill gpg (1.0.1-2) to get mutt to continue, and then > I got > [-- PGP output follows --] > ... > Good signature from ... > ... > gpg: waiting for lock (hold by 829 - probably dead) ... > gpg: waiting for lock (hold by 829 - probably dead) ... > gpg: waiting for lock (hold by 829 - probably dead) ... > gpg: waiting for lock (hold by 829 - probably dead) ... > gpg: waiting for lock (hold by 829 - probably dead) ... > gpg: waiting for lock (hold by 829 - probably dead) ... > [-- End of PGP output --] > > GnuPG bug or local configuration problem? Works fine on my machine, I have version 1.0.1-2 installed. -- while :;do read x;echo \?;done
Re: ITP: cmatrix
Edward Betts <[EMAIL PROTECTED]> wrote: > Package: cmatrix > Status: install ok installed > Priority: optional > Section: misc > Installed-Size: 76 > Maintainer: Edward Betts <[EMAIL PROTECTED]> > Version: 1.0b-1 > Depends: libc6 (>= 2.1), libncurses4 (>= 4.2-3.1), xbase-clients (>= > 3.3.3.1-5), kbd-compat | kbd Sorry, I relise the versions are a bit out of date, I built the packages ages ago. I would rebuild before an upload. -- while :;do read x;echo \?;done
gpm in vim
Craig Sanders <[EMAIL PROTECTED]> wrote: > On Sun, Mar 26, 2000 at 05:57:38PM +0200, [EMAIL PROTECTED] wrote: > >* Enable gpm support (except in vim-tiny of course) on popular request. > > can this be disabled in ~/.vimrc? The opposite is infact true, console mouse support has to be enabled in the ~/.vimrc to be used. > text-mode programs which use the mouse make it difficult to use the > mouse for the purpose that the gods intended (cut & paste with left, > right, and middle buttons). having to remember to press shift every time > you want to cut and paste sucks...it upsets the natural order of things > and is a blasphemy against all that is good and right in the world. :) > > if it cant be disabled, then please consider this a wishlist bug report > to make it do so. -- while :;do read x;echo \?;done
Re: no freeramdisk? -> util-linux
Eric Delaunay <[EMAIL PROTECTED]> wrote: > I'm attempting to write support for scsidev at boot time in conjonction with > a fork of hwtools to create a new scsitools package that will provide only the > scsi stuff of hwtools and compile on non-i386 Debian architectures. > However, my scripts will eventually make use of freeramdisk which is not > available on all architectures. In fact, it is currently only provided by > loadlin on i386 :(( (see wishlist bug #49878). > > I don't think it's worth creating a stand alone package for freeramdisk (which > is 3k) so the best package I found to move to is util-linux. > > Do you agree with this proposal? It should go under /bin or /sbin (/sbin > preferably) because I need it early at boot time, before any partition (like > /usr) is mounted. > > I will file a bug against loadlin & util-linux if I get a consensus on it. Seconded. -- while :;do read x;echo \?;done pgpfqGIY2JhMt.pgp Description: PGP signature
Subpackaging (Was: Potato now stable)
Drake Diedrich <[EMAIL PROTECTED]> wrote: >Under the Irix packaging system (quite nice UI except that it has to > handle Irix packages..) packages exist in a hierarchy, with lowest level > packages quite fine grained. For example: > > I fw_bzip2 02/28/2000 bzip2-0.9.0c Compress/decompress files > I fw_bzip2.man 02/28/2000 bzip2-0.9.0c man pages > I fw_bzip2.man.bzip2 02/28/2000 bzip2-0.9.0c man pages > I fw_bzip2.man.info02/28/2000 bzip2-0.9.0c info pages > I fw_bzip2.man.relnotes 02/28/2000 bzip2-0.9.0c Release Notes > I fw_bzip2.sw 02/28/2000 bzip2-0.9.0c execution only env > I fw_bzip2.sw.bzip202/28/2000 bzip2-0.9.0c execution only env > I fw_bzip2.sw.hdr 02/28/2000 bzip2-0.9.0c header files > I fw_bzip2.sw.lib 02/28/2000 bzip2-0.9.0c shared libraries > I fw_bzip2.sw6402/28/2000 bzip2-0.9.0c 64-bit execution only env > I fw_bzip2.sw64.lib02/28/2000 bzip2-0.9.0c 64-bit shared libs This looks cool. I like it. How about a little brainstorming to pick some categories that could be used in debian. Possible layout ~~~ control.tar.gzpackage system stuff, depends, postinst, etc signatures.tar.gz signatures for each part of the package binary/*.tar.gz arch-dependent data and programs for each arch data.tar.gz arch-independent data and programs doc.tar.gzdocs not in packages below (includes copyright) doc/html.tar.gz html format doc/ps.tar.gz postscript format doc/dvi.tar.gzdvi format doc/text.tar.gz text format doc/man.tar.gzman pages doc/info.tar.gz info pages doc/examples.tar.gz /usr/share/doc/examples/* locale/*/gettext.tar.gz gettext translations locale/*/doc/html.tar.gz html translations locale/*/doc/ps.tar.gzpostscript translations locale/*/doc/dvi.tar.gz dvi translations locale/*/doc/text.tar.gz text translations locale/*/doc/man.tar.gz manpage translations locale/*/doc/info.tar.gz info translations source/original.tar.gzupstream source source/debian.diff.gz debian diff copyright copy of copyright or symlink to common-licence Packages could be made available for each $(ARCH), including packages optimised for subarchs. The locale support is sorted by locale, rather than by file format, so that ftp users can more easily just download their locale, by downloading the directory for their locale. All the parts of the package would be optional apart from the control.tar.gz, in that way it would be possible to build task packages with no filesystem, just a copyright notice with the package on the mirror. How would it be implemented? My recommendation would be one directory per package. Each subpackage could just be part of a .tar.gz file. Having the binary dependent parts listed here would imply that the package locate could change from looking like this: dists/unstable/main/binary-*/admin/at_3.1.8-10.deb to looking like this: dists/main/admin/at/* apt, dselect and friends would be changed so that when a package was selected the default set of subpackages would be installed to match the current behaviour. When a package is selected all of the subpackages would be selected except for the binaries and the source. Only the binary of the current arch would be installed. The user could selected a more detailed screen in dselect, or use command line switches with apt-get to select the subpackages to be installed or not installed. What use would this be? ~~~ * Disk space Machines with small hard drives could have packages installed without docs or translations. Single-user systems could save space by only installing translations for languages that were needed. Docs could be installed in preferred formats only. A set of binaries built could be built with -Os passed to gcc and with extra build options turned off to try and make them as small as possible. This would be like the *-tiny packages now, but without needing to replicate the docs and man pages. Some space would be saved on the server because man pages and friends would not be stored for each arch. For an even more compact system each executable and library in the package could be split into a separate subpackage, but means we tend to lose some of the benefits of the packaging system, and just have a load of files. The Gnome applets could be packaged as one package, called gnome-applets, but within that package there is one .tar.gz for each applet. By default all the applets are installed, but the user can select with more details the exact binaries they want. If some modules are not selected this would save space on an install, during install and save bandwidth when downloading. An alternative would be to include all the applets in one .tar.gz and selective not install binaries. This would save space in the installed form, but
Re: Subpackaging (Was: Potato now stable)
Decklin Foster <[EMAIL PROTECTED]> wrote: > I like the plan a lot. some thoughts: Glade to hear it. > I wonder if the default docs should not go in a locale/ subdir for the > proper language (English for most of what exists now). I know very > little about i18b so I won't comment on the implementation. This does > have this advantages of: > > (a) not appearing to be English-centric > (b) allowing for a package whose upstream docs are entirely in a > different language (while most non-English-speaking authors also > know some English or are fluent in it, many may not). Yes, this could work. > > We are breaking the rules on copyright at the moment. We distribute > > binaries licensed under the GPL without a copy of the GPL. > > I disagree. We distribute base-files on the same server. You are right, I am probably trying to fix a problem that is not there. Feel free to ignore the bit of copyrights. > > Packages that provide the same documentation in different formats do not > > always include the same documents in the different formats, but instead > > different documents are included in different formats. An example might be > > useful: > > > > Not: README, README.html and README.ps > > > > But: README, manual.html and specification.ps > > IMHO, doc-$FORMAT should only apply if the same documentation is built > in different formats. There should be one 'doc' tarball for > documentation which comes in a single format, and 'doc-*' or 'doc/*' > for the multiple case (and then none of those files should be in the > base 'doc'.) That was about what I was thinking. > > What happens when a user selects to install binary-i386 and binary-m68k > > packages? > > I don't see a reason to allow this; is there one? No probably not. I was thinking it would be cool to build a server on an i386, and then decide to upgrade to Alpha. You can get ATX Alpha boards these days, in terms of hardware you just need to replace the m/b and chip; it would be cool if you could take a debian install, tell apt that you were about to change the processor from i386 to alpha and it automatically changed all the binaries. This is probably not very likely to happen, and if it could be written to be supported by my suggested layout, then it could probably be handled by the current layout. Just remove all the binary packages and install the new ones from the new arch. This is all a bit side tracked, and does not give a reason for wanting binaries from two archs installed at once. Oh! I have thought of a reason! Something to do with a network server that supplies /usr/bin for a load of machines, and they are different archs. Probably far-fetched, and the package management system should not be used for something this complicated. -- Don't worry -- shop.
Re: Subpackaging (Was: Potato now stable)
Edward Betts <[EMAIL PROTECTED]> wrote: > How would it be implemented? > > My recommendation would be one directory per package. Each subpackage could > just be part of a .tar.gz file. Having the binary dependent parts listed here > would imply that the package locate could change from looking like this: > > dists/unstable/main/binary-*/admin/at_3.1.8-10.deb > > to looking like this: > > dists/main/admin/at/* I thought of another problem. Versions. Are they in the control.tar.gz for each subpackage? Or is there a small control file in each subpackage that contains the info? Another thought. Should signatures be in a single .tar.gz, like I suggested, or should they be in each .tar.gz If they are the single .tar.gz, then translators would have to get it updated when releasing a new version of a translation. -- Don't worry -- shop.
Re: Subpackaging (Was: Potato now stable)
Anthony Towns wrote: > First, including each architecture and source in every .deb suddenly > balloons our 3 CD set to get i386 binaries to a ~15 CD set. It also > kills non-broadband net upgrades (you *really* want to download six > copies of emacs plus all its source?). I'm not sure how you'd build > such a .deb either, without having personal access to machines of every > supported arch. Who says I want to put all the subpackages in one package. These are individual .tar.gz on the ftp server. What I was thinking was to have them all in a directory. If I want to make i386 CDs then I just do a find on the directories and dumb the binary-*.tar.gz that I do not want. > Second, it breaks compatability with earlier versions of dpkg. If dpkg > adopts this format, then dpkg won't be able to upgrade itself. At best, > dpkg -i dpkg_blah.deb seems likely to at least lost all the optional > components (copyrights, docs, manpages...). There is that, I admit. I agreed with everything else that you said, you give a good example of how subpackaging could be implemented using dpkg. However, one of my concerns as a low bandwidth user is transferring stuff. Great, I can split my debs up into subpackages inside the deb, but what about downloading. If I do not want to download man pages, then I do not want to download man pages, if they are all together in a deb, then I have to. -- Don't worry -- shop.
Re: Implementing "testing" (was: Re: Potato now stable)
Jules Bean <[EMAIL PROTECTED]> wrote: > I'd just like to bring up the only point which really worries me about > all this... what is the incentive for people to run their machines on > 'unstable'? I for one like the bleeding-edge. I like stuff that breaks, because I get to fix it. I like filing bug reports. There are other twisted people like me. I will run unstable. -- Don't worry -- shop.
Re: Subpackaging (Was: Potato now stable)
Anthony Towns wrote: > On Thu, Aug 17, 2000 at 08:58:31PM +0100, Edward Betts wrote: > First, including each architecture and source in every .deb suddenly > balloons our 3 CD set to get i386 binaries to a ~15 CD set. It also > kills non-broadband net upgrades (you *really* want to download six > copies of emacs plus all its source?). I'm not sure how you'd build > such a .deb either, without having personal access to machines of every > supported arch. My suggestion was that packages would look like this on the ftp server: dists/unstable/main/admin/at/ instead of: dists/unstable/main/binary-i386/admin/at_3.1.8-10.deb But that is a bit dumb, so forget it, have it looking like this: dists/unstable/main/binary-i386/admin/at/ and: dists/unstable/main/binary-all/admin/at/ Maybe stick some symlinks in binary-i386 for the man pages in binary-all. If you keep everything in a single .deb that means that there are multiple copies of the man pages. On a machine with 8 archs, that is 8 copies of the man page you are storing. -- Don't worry -- shop.
Realplayer
So Joey and Manoj are having a `friendly' discussing about the best way to implement an installer package for realplayer, I wondered how the other distributions do it. Now I have not bothered to look because I am to lazy, but my best guess is that RedHat includes a copy of the Realplayer code. They have talked to RealNetworks and sorted this all out, the version of RealPlayer that the current Debian installer uses is the rpm. So maybe we could do the same, ask for permission to include the code in a .deb in non-free on our mirror sites, and on non-free CDs. I know that this would mean that we would be going out of the way to support non-free software, but so is an installer. In September 1999 I sent an e-mail to RealNetworks asking them about this idea. When I got the following response in December 1999 I gave up: Date: Mon, 27 Dec 1999 20:57:06 -0800 From: [EMAIL PROTECTED] Subject: Realplayer for Debian GNU/Linux [#6430953] To: [EMAIL PROTECTED] Hello Edward, Thanks for contacting RealNetworks Technical Support. Please note that RealPlayer G2 will be available on the following operating systems at some point in the future: Macintosh Irix SunOS Linux DEC Unix If you are interested in seeing the RealPlayer G2 ported to a different operating system than those listed, please send your plan, including the amount you or your organization is willing to pay RealNetworks for this development, via post to the following: RealNetworks, Inc. 3rd Ave. Suite 2900 Seattle, WA 98101 Attn: Dave Hardwick, Technical Support Manager ** There is an ALPHA version of G2 available on our Developer site for testing only. There is no technical suppport available for this product, but you can submit a bug or issue a report at [EMAIL PROTECTED] (where are the devleopers hang out and answer questions.). Until the product is more stable and signed off by every department, it will not be supported technically from the department I reside in. Thanks for your interest in the RealPlayer. Wish you Merry Christmas!! Thank you. Thirumalesh.M Aditi Corporation RealNetworks Authorized Support Provider. -- Don't worry -- shop.
Abuse is still being worked on
Joey Hess <[EMAIL PROTECTED]> wrote: > Are you a new debian developer, looking for some packages to maintain? > If so, this list is for you. I need to drop some of my simpler packages > to make way for other work. All of the below are up for adoption -- just > mail me. Otherwise, I will continue to maintain them. > > abuse and abuse-lib > > The side scrolling action game from crack dot com. It has one bug, > which a competant X programmer could probably fix easily. If you take > these you should at least consider taking abuse-sfx, which currently > has no maintainer and is non-free. Note that abuse is orphaned > upstream, and I can't find anyone working on it. Just FYI Abuse is being worked on. http://sourceforge.net/projects/v3abuse/ -- Don't worry -- shop. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Alternatives to ftp.debian.org
Matt Taggart <[EMAIL PROTECTED]> wrote: > By hand I run the list of mirrors > (http://www.debian.org/misc/README.mirrors) thru netselect to get the > best one for the machine I'm on, then stick that in sources.list. I tried that, I got a mirror with a low ping, low round trip and good response, but it did not have the highest level of bandwidth of the mirrors. Netselect does not measure bandwidth, which is the thing I am most interested in when picking a mirror. It says in the README file for netselect that the author knows about this, and might try and steal some code from bing to implement this. -- Don't worry -- shop. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian banner ad outdated
Florian Hinzmann <[EMAIL PROTECTED]> wrote: > I just browsed freshmeat and a Debian banner appeared at the > top of that page. Unfortunately it reads "version 2.1". > > Who might be able to fix this? Same on sourceforge.net -- Don't worry -- shop. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: mass bug filing on packages that are blocking use of cdebconf
Joey Hess <[EMAIL PROTECTED]> wrote: > This is your third and final reminder. I count 542 packages remaining, > down only 9 from last month. I assume most of the people below do not > read debian-devel, so I've taken the librerty of BCCing you all. :-P [-SNIP-] > Edward Betts <[EMAIL PROTECTED]> >joystick > Thanks, I'll upload a package sometime later today. -- Edward -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#585583: ITP: pymarc -- read, write and modify MARC bibliographic data
Package: wnpp Severity: wishlist Owner: Edward Betts * Package name: pymarc Version : 2.60 Upstream Author : Gabriel Farrell, Mark Matienzo, Ed Summers * URL : http://github.com/edsu/pymarc * License : BSD Programming Lang: Python Description : read, write and modify MARC bibliographic data pymarc is a Python library for working with MARC21 bibliographic data loosely based on the MARC/Perl suite of modules (http://marcpm.sf.net). I'm in contact with the authors, they're excited about having the module in Debian. The source package will be called pymarc, the binary package will be python-pymarc. Sample packages are here: http://edwardbetts.com/debian -- Edward. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100611222120.18425.6736.report...@4angle.com
Bug#277498: ITP: libdate-simple-perl -- a simple date object
Package: wnpp Severity: wishlist * Package name : libdate-simple-perl Version : 3.01 Upstream authors : Marty Pauley <[EMAIL PROTECTED]>, John Tobey <[EMAIL PROTECTED]>, Yves Orton <[EMAIL PROTECTED]> * URL : http://search.cpan.org/CPAN/authors/id/Y/YV/YVES/ * License : GPL or Artistic Description : a simple date object Dates are complex enough without times and timezones. This module may be used to create simple date objects. It handles validation, interval arithmetic, day-of-week calculation and transparent date formatting. It does not deal with hours, minutes, seconds, and time zones. Sample package at: http://people.debian.org/~edward/packages/
Re: xplanet can use ssystem image file!
Bill Allombert <[EMAIL PROTECTED]> wrote: > I know there are lot of xplanet-lover here, and I just discover > you can use ssystem file with xplanet! > > xplanet --window --body mars --image /usr/lib/ssystem/mars.jpg > --orthographic > > (no there aren't any Debian developpers on Mars (yet ?).) > BTW this should be in /usr/share/ssystem/mars.jpg per FHS. Newer versions of ssystem are called openuniverse. -- Edward Betts (GPG: 1BC4E32B)
Re: call for lintian patches
Sean 'Shaleh' Perry <[EMAIL PROTECTED]> wrote: > The lintian maintainer is back! I am slowly reading up on the new policy and > my bug list. So, if you have any beefs or patches please read the BTS and > submit accordingly. I presume you are looking for patches for lintian 1.x rather than lintian 2. Am I right? -- Edward Betts (GPG: 1BC4E32B)
Re: call for lintian patches
Sean 'Shaleh' Perry <[EMAIL PROTECTED]> wrote: > > On 12-Sep-2001 Edward Betts wrote: > > Sean 'Shaleh' Perry <[EMAIL PROTECTED]> wrote: > >> The lintian maintainer is back! I am slowly reading up on the new policy > >> and > >> my bug list. So, if you have any beefs or patches please read the BTS and > >> submit accordingly. > > > > I presume you are looking for patches for lintian 1.x rather than lintian 2. > > Am I right? > > > > what is lintian 2.x? (-: http://cvs.debian.org/lintian2/?cvsroot=lintian -- Edward Betts (GPG: 1BC4E32B)
Re: root rm: Permission denied - solution found
Martijn van Oosterhout wrote: > The point is that if there is corruption in the filesystem then the > immutable flag may have be switched on accedently. > > You notice this on ext2 when an inode has been corrupted. There's a 50% > chance the immutable bit may have been set, leading people to wonder why > they can't delete the file even as root. I had the same problem, just worked out how to fix it, I used the chattr program, see the chattr man page for more details. -- Edward Betts (GPG: 1BC4E32B)
Re: Issue with Bug#112121: procmail-lib: Recipes belong in /usr/share, not /usr/lib
Elie Rosenblum <[EMAIL PROTECTED]> wrote: > I would happily move it to /usr/share, however I am worried about users > who are already using the current version. Users can use the provided > recipes with the procmail INCLUDERC directive, and if I move the files > it will break all of the user rcfiles that already use these includes. > > Would turning /usr/lib/procmail-lib into a symlink to the appropriate > location be acceptable? I would really rather avoid breaking every rcfile > that currently uses any of these recipes. Debconf question: do you want a symlink. -- Edward Betts (GPG: 1BC4E32B)
Re: root rm: Permission denied - solution found
"Tille, Andreas" <[EMAIL PROTECTED]> wrote: > On Thu, 13 Sep 2001, Edward Betts wrote: > > > I had the same problem, just worked out how to fix it, I used the chattr > > program, see the chattr man page for more details. > Could you please be a little bit more detailed? > > # chattr -V -i postgres.log.7.gz > chattr 1.22, 22-Jun-2001 for EXT2 FS 0.5b, 95/08/09 > chattr: Permission denied while trying to stat postgres.log.7.gz chattr -V -ai postgres.log.7.gz maybe? -- Edward Betts (GPG: 1BC4E32B)
Re: Issue with Bug#112121: procmail-lib: Recipes belong in /usr/share, not /usr/lib
Steve Greenland <[EMAIL PROTECTED]> wrote: > On 13-Sep-01, 18:37 (CDT), Edward Betts <[EMAIL PROTECTED]> wrote: > > Debconf question: do you want a symlink. > > Please, no. The fact that debconf provides an easy, consistent way to > interact with the user does not mean that every possible choice that > a package makes needs to ask the user. If I wanted to make all the > choices, I'll build from source :-). Either put in the symlink, or > don't, but don't bug me about it. Your scheme works, but at least tell the sys admin what is going on with a debconf note. If you don't want to be bugged change the debconf priority. -- Edward Betts (GPG: 1BC4E32B)
Re: Installed sortmail 19910421-8 (i386 source)
Hamish Moffatt <[EMAIL PROTECTED]> wrote: > sortmail (19910421-8) unstable; urgency=low > . >* Applied patch to included prototypes for all functions > that return 64-bit integers. Thanks to John R. Daily > (closes: #126741) >* Fixed default mail spool path in /usr/bin/sortmail and > sortmail(1) (was /usr/spool/mail, now /var/spool/mail). > Changelog says this was fixed in 1998, wonder what > happened to that Shouldn't that be /var/mail? -- The enemy's gate is down
Re: EURO and CENT signs in the console keymaps
Eduard Bloch <[EMAIL PROTECTED]> wrote: > - Most keyboards have AltGr-e as Euro > - the French keymap (relative to US layout: <]>) > - the Hungarian keymap (relative to US layout: <\>) > - the Norwegian and Swedish keymap (relative to US layout: <4>) > > Did I miss anything or is something wrong? I bought my i386 laptop in the US with a US qwerty keyboard. Soon after I bought it the keyboard sunk slightly near the plus key, it did not affect my typing, but it was visible, so I did not bother getting it fixed. Moved back to the UK and it was coming close to the end of the one year warranty period. Sent the laptop off so they could fix some other problems that had shown up, and asked for the keyboard to be fixed whilst they were at it. I knew that the policy was to replace with local parts, so when I got the laptop back I was not surprised that it had a UK qwerty keyboard, took me a while to get used to the new layout, but not a problem. The Euro is on the `4' of my keyboard, I think it should display a Euro when used with the `Alt gr' modifier. Most UK keyboards that have been made in the last few years have a Euro symbol in the same place. I have only seen one exception, my Dad bought a new computer last month, and it has the Euro symbol on the `e' key, otherwise it is similar to other UK keyboards I have seen (it has a £ symbol) and so on. The machine is running Windows, and `Alt gr' + `e' gives an accented `e' of some kind, while `Alt gr' + `4', gives the Euro (nasty looking character in the typeface it was using). So I guess it is just some cheap keyboard, made abroad, and they put the euro symbol in the wrong place. -- The enemy's gate is down
Re: GPG key signing: Wisconsin.
Scott Dier <[EMAIL PROTECTED]> wrote: > I'm going to Milwaukee, Wisconsin from Minneapolis, Minnesota this > weekend, and I want to let developers and non-developers alike that if > they need a gpg key signing to let me know in private. Minneapolis Lat: 44 58 N Long: 093 15 W (represented in degrees minutes direction) Lat: 44.967 Long: -93.250 (represented in decimal degrees) There are two Debian developers within 10 miles. -- The enemy's gate is down http://people.debian.org/~edward/
Re: GPG key signing: Wisconsin.
Scott Dier <[EMAIL PROTECTED]> wrote: > I'm going to Milwaukee, Wisconsin from Minneapolis, Minnesota this > weekend, and I want to let developers and non-developers alike that if > they need a gpg key signing to let me know in private. Milwaukee Lat: 43 02 N Long: 087 54 W (represented in degrees minutes direction) Lat: 43.033 Long: -87.900 (represented in decimal degrees) No Debian developers within 50 miles. -- The enemy's gate is down http://people.debian.org/~edward/
Bug#516710: ITP: libdata-pageset-perl -- Page numbering and page sets
Package: wnpp Severity: wishlist Owner: Edward Betts * Package name: libdata-pageset-perl Version : 1.05 Upstream Author : Leo Lapworth * URL : http://search.cpan.org/dist/Data-Pageset/ * License : Artistic | GPL-1+ (like perl) Programming Lang: Perl Description : Page numbering and page sets The object produced by Data::Pageset can be used to create page navigation, it inherits from Data::Page and has access to all methods from this object. In addition it also provides methods for dealing with set of pages, so that if there are too many pages you can easily break them into chunks for the user to browse through. You can even choose to view page numbers in your set in a 'sliding' fassion. The object can easily be passed to a templating system such as Template Toolkit or be used within a script. This package will be maintained by the pkg-perl team. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Upcoming Section changes in the archive
How about: webfeed - RSS/Atom feed readers, aggregator and utilities akregator blam canto cl-rss claws-mail-feeds-reader dcoprss evolution-rss feed2imap firefox-sagefirefox-sage kitty liferea* magpierss miro* newsbeuter nrss olive php-xml-rss planet python-feedparser python-feedvalidator python-pyrss2gen rawdog rss2email rsskit.framework rssreader.app rsstail snownews yarssr yocto-reader -- Edward. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: init system policy
Philip Hands wrote: > Not if you take into account the fact that someone will have had to do > something like :wq! to get past the read-only state of the file. > > vim put's a [RO] after the filename when you open it, and says this when > you try to write it: > > E45: 'readonly' option is set (add ! to override) > > in emacs, you get %% in the status line, and it tells you the file's > read-only when you start trying to edit it, and refuses to do so until > you type C-x C-q to flip it's read-only status. > > nano sadly doesn't seem to notice :-/ I just tried this, when you open a read-only file as a normal user it gives you a warning. edward@x230:~$ touch test edward@x230:~$ chmod 400 test edward@x230:~$ nano test Nano says: [ Read 0 line ( Warning: No write permission) ] It won't let me save the file with the same name, I get this error: [ Error writing test: Permission denied ] When running as root the warning and error disappear, there is no indication that the file is read-only. -- Edward. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141123092558.GA12017@x230
Bug#781282: ITP: python-fuzzywuzzy -- fuzzy string matching in Python
Package: wnpp Severity: wishlist Owner: Edward Betts * Package name: python-fuzzywuzzy Version : 0.5.0 Upstream Author : Adam Cohen * URL : https://github.com/seatgeek/fuzzywuzzy * License : MIT Programming Lang: Python Description : fuzzy string matching in Python This module provides various methods for fuzzy matching of strings in Python. See http://chairnerd.seatgeek.com/fuzzywuzzy-fuzzy-string-matching-in-python/ I plan to maintain it as part of the Debian Python Modules Team. fuzzywuzzy is a dependency of lettuce, a Cucumber-ish BDD for Python. I have a package ready to upload to mentors.debian.net -- Edward. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150326211334.GA30597@x230
