Bug#1081993: ITP: python-infoblox-client -- client for interacting with Infoblox NIOS over WAPI
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: python-infoblox-client Version : 0.6.0 Upstream Author : John Belamaric * URL : https://github.com/infobloxopen/infoblox-client * License : Apache-2.0 Programming Lang: Python Description : client for interacting with Infoblox NIOS over WAPI This package provides a client for interacting with Infoblox NIOS over WAPI. . Network Identity Operating System (NIOS) is the operating system that powers Infoblox core network services, ensuring non-stop operation of network infrastructure. The basis for Next Level Networking, NIOS automates the error-prone and time-consuming manual tasks associated with deploying and managing DNS, DHCP, and IP address management (IPAM) required for continuous network availability and business uptime. This is a new dependency of OpenStack Designate, aka OpenStack DNSaaS.
Bug#1081203: ITP: python-threadloop -- Tornado IOLoop Backed Concurrent Futures
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: python-threadloop Version : 1.0.2 Upstream Contact: Grayson Koonce * URL : https://github.com/TomerFi/aioswitcher * License : Expat Programming Lang: Python Description : Tornado IOLoop Backed Concurrent Futures This package provides a way to run Tornado Coroutines from Synchronous Python. . Tornado is a Python web framework and asynchronous networking library, originally developed at FriendFeed. By using non-blocking network I/O, Tornado can scale to tens of thousands of open connections, making it ideal for long polling, WebSockets, and other applications that require a long-lived connection to each user.
Bug#1080977: ITP: oscs -- OpenStack cloud selector parses credentials from clouds.yaml
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: oscs Version : 0.0.1 Upstream Contact: Bertrand Lanson * URL : https://salsa.debian.org/openstack-team/clients/oscs * License : Expat Programming Lang: Python Description : OpenStack cloud selector parses credentials from clouds.yaml This package provides a parser for the ~/.config/openstack/clouds.yaml and makes it possible to select one of the, by exporting the OS_CLOUD environment variable. When using "oscs set" without any argument, oscs displays a nice fzf ncurse dialogue where uses can select what cloud to use with the arrow keys. . The way to use it, is to source /usr/share/oscs/oscs from your .bashrc.
Re: Community survey on network stack for Trixie
On 9/2/24 21:02, Andrej Shadura wrote: On Mon, 2 Sep 2024, at 19:41, Daniel Gröber wrote: I promise you I'm not intentionally, but I do recognize that it may be a side-effect. Likewise I feel like you're just interested in pushing this through as quickly as possible. Consider that for you time is an ally, being employed to work on this (AFAICT?). For the rest of us not so much. Debian is a primarily a volunteer project. Please stop pushing for doing things faster. I don’t think Lukas is rushing things too much. Indeed, Lukas should be thanks for putting so much effort on his proposal, and doing it in a way to gather consensus, with a lot of discussion involved. Cheers, Thomas Goirand (zigo)
Re: Network stack for Trixie
On 8/20/24 16:25, Daniel Gröber wrote: Frankly I think the problem we have here is that this shouldn't be a technical decision. We should focus on what the majority of our users actually want not our preferences. I strongly do not agree with the above. This is not a question of who likes what, it's a question of what we can, and should support. At this time, ifupdown as a concept, is just dead. Systemd raises events, and we must have the logic to implement it. This is one of the reason why the cloud image switched to netplan and systemd-networkd: it needed to respond to PCI hotplug events, and perform DHCP on a new NIC hotplug. With ifupdown, the way to do it, is to write udev rules. These more and more, are a bad concept that is being actively removed from systemd. For example, in Bookworm, you cannot rename a NIC using an udev rule, you must use a file under /etc/systemd/network. So we're already in, like it or not... It is also super hackish style of scripts with ifupdown. At this time, ifupdown isn't a good fit for the job, and I don't see anyone volunteering to change the situation. The ifupdown path is just reaching a dead end. If you find volunteers, we may reconsider. And then, you're saying it is a question of taste, and we should vote? I do not agree. This isn't the case. Please don't go that path of making people vote on something they may not know about, and will have no time to investigate or read about: this is just wrong. Instead, either get ifupdown actively maintained and fixed for newer systemd (and then come back to us), or give-up the idea, so we can switch to a more modern, systemd-compatible stack. I propose taking an informal vote on this to gather data on networking tool preference among DDs and the wider Debian community to settle this. Please don't. We do not need another systemd vote... @d-devel has this been done on decisions like these beore? How should we go about doing this? Would a GR be more appropriate? No, it would not. We haven't even finished discussing it internally in this team, yet even raised a topic in debian-project. Please do not just fire a GR so fast, we should discuss it calmly first. Did you also think that maybe, the technical committee could be involved, if we can't agree reasonably, rather than yet-another-GR ? We aren't even there yet... If it turns out I'm alone in wanting Debian to retain it's identity as Debian I will (grudingly) step aside on this matter, but in the absence of tangible data my current view is that this is not the case and I will take appropriate steps to protect that identity. This sounds like a threat, rather than getting involved in the decision making process. Can't we have a normal (technical) discussion instead? Cheers, Thomas Goirand (zigo)
Bug#1080389: ITP: cyborg -- OpenStack Acceleration as a Service
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: cyborg Version : 12.0.0 Upstream Contact: OpenStack Foundtaion * URL : https://opendev.org/openstack/cyborg * License : Apache-2.0 Programming Lang: Python Description : OpenStack Acceleration as a Service Cyborg provides a general management framework for accelerators such as FPGA, GPU, SoCs, NVMe SSDs, CCIX caches, DPDK/SPDK, pmem and so forth. It provides a REST API for basic accelerator life cycle management, and has a generic driver for common accelerator support.
Bug#1079909: ITP: python-jaeger-client -- OpenTracing tracer implementation
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: python-jaeger-client Version : 4.8.0 Upstream Contact: Yuri Shkuro * URL : https://github.com/jaegertracing/jaeger-client-python * License : Apache-2.0 Programming Lang: Python Description : OpenTracing tracer implementation This is a client-side library that can be used to instrument Python apps for distributed trace collection, and to send those traces to Jaeger. See the OpenTracing Python API for additional detail. I intend to maintain this package within the OpenStack team.
Bug#1079860: ITP: python-threadloop -- Tornado IOLoop Backed Concurrent Futures
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: python-threadloop Version : 1.0.2 Upstream Author : Grayson Koonce * URL : https://github.com/TomerFi/aioswitcher * License : Expat Programming Lang: Python Description : Tornado IOLoop Backed Concurrent Futures This package provides a way to run Tornado Coroutines from Synchronous Python. This is a new indirect dependency for OpenStack.
Re: Validating tarballs against git repositories
On 8/27/24 22:30, Jeremy Stanley wrote: On 2024-08-27 19:41:54 +0200 (+0200), tho...@goirand.fr wrote: [...] All you wrote is precisely why I am not using these tarballs. I know we don't agree... :) Also, the FTP master do NOT want the changeLog as they are too big and provide no value when one can check the git repo to find the same info. Sure, but the assembled release notes are not nearly as large as the changelog while still relying on having Git history available to build, and the generated authorship list is referred to in the license information for at least one OpenStack project as a stand-in for referencing Git committer metadata. To put it another way, upstream in OpenStack when the project was started in 2010, we were aware that package maintainers preferred signed and clearly versioned tarballs for every release, so that's what we structured our workflows and tooling around providing. In the meantime, package maintainers decided to take advantage of the fact that we use Git repositories in our development workflow but the release process we settled on isn't designed with that in mind, and changing workflows and processes in a developer community that size is sometimes like trying to steer a train. Well, I don't want to just package the generated stuff, I would prefer to have the tools to generate them myself from source at build time. And that's what has been bothering me since the beginning: I do not know how to do that, currently, neither for the authorship list or the release notes. In both case, the Git repo is needed, and that doesn't fit at all a packaging workflow, unless I embed all of the .git folder in the source package. This was truth in 2010, and still is in 2024... As a consequence, I decided not to care, as I haven't find a solution to "build from source", so I'm not packaging release notes and authorship list. It's probably my fault that I didn't contribute some fixes to reno though. Cheers, Thomas Goirand (zigo)
Bug#1079821: ITP: python-aiosomecomfort -- client for Honeywell's US-based cloud devices
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: python-aiosomecomfort Version : 0.0.25 Upstream Author : Mike Kasper * URL : https://github.com/mkmer/AIOSomecomfort * License : GPL-3 Programming Lang: Python Description : A client for Honeywell's US-based cloud devices This package provides a client for Honeywell's US-based cloud devices. This is for the US model and website. Be aware that EU models are different! . This package is a dependency of Home Assistant. I intend to maintain this package within the Home Assistant team.
Bug#1079692: ITP: python-sushy-oem-idrac -- Dell EMC iDRAC OEM extension package for the sushy library
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: python-sushy-oem-idrac Version : 5.0.0 Upstream Contact: OpenStack * URL : https://github.com/openstack/sushy-oem-idrac * License : Apache-2.0 Programming Lang: Python Description : Dell EMC iDRAC OEM extension package for the sushy library The sushy-oem-idrac package is a sushy extension package that aims at adding high-level hardware management abstractions, that are specific to Dell EMC BMC (which is known under the name of iDRAC), to the tree of sushy Redfish resources. I intend to maintain this package within the OpenStack team, as this is a recommends: for Ironic (aka: OpenStack baremetal as a service).
Bug#1079586: ITP: python-aioesphomeapi -- Python API for interacting with ESPHome devices
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: python-aioesphomeapi Version : 25.1.0 Upstream Contact: Otto Winter * URL : https://github.com/esphome/aioesphomeapi/ * License : Expat Programming Lang: Python Description : Python API for interacting with ESPHome devices The aioesphomeapi Python package allows one to interact with devices flashed with ESPHome. . This package is a dependency of Home Assistant. I intend to maintain this package within the Home Assistant team.
Bug#1077721: ITP: python-aiolifx -- API for local communication with LIFX devices over a LAN with asyncio
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: python-aiolifx Version : 1.0.6 Upstream Contact: François Wautier * URL : http://github.com/aiolifx/aiolifx * License : Expat Programming Lang: Python Description : API for local communication with LIFX devices over a LAN with asyncio This package provides a Python 3, asyncio library to control Lifx LED lightbulbs over your LAN. Most of it was taken from Meghan Clarkk lifxlan package (https://github.com/mclarkk) and adapted to Python 3 and asyncio. I intend to maintain this package within the Home Assistant team.
Bug#1077719: ITP: python-inquirerpy -- collection of common interactive command-line user interfaces
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: python-inquirerpy Version : 0.3.4 Upstream Contact: Kevin Zhuang * URL : https://github.com/kazhala/InquirerPy * License : Expat Programming Lang: Python Description : collection of common interactive command-line user interfaces InquirerPy is a Python port of the famous Inquirer.js: a collection of common interactive command line user interfaces. This project is a re-implementation of the PyInquirer project, with bug fixes of known issues, new prompts, backward compatible APIs, as well as more customisation options. I intend to maintain this package within the Home Assistant team.
Bug#1077562: ITP: python-chacha20poly1305 -- chacha20-poly1305 implementation based on tlslite-ng
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: python-chacha20poly1305 Version : 0.0.3 Upstream Contact: Dusan Klinec * URL : https://github.com/ph4r05/py-chacha20poly1305 * License : LGPL-2.1 Programming Lang: Python Description : chacha20-poly1305 implementation based on tlslite-ng Simple pure-python chacha20-poly1305 implementation based on tlslite-ng code. Designed to be compatible with Cryptography API. . This package is a dependency of Home Assistant. I intend to maintain this package in the Home Assistant team.
Bug#1077382: ITP: python-aiodhcpwatcher -- watch for DHCP packets with asyncio
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: python-aiodhcpwatcher Version : 1.0.2 Upstream Contact: J. Nick Koston * URL : https://github.com/bdraco/aiodhcpwatcher * License : GPL-2+ Programming Lang: Python Description : watch for DHCP packets with asyncio This Python library makes it possible to watch for DHCP packets with asyncio. Users of this library will simply provide a callback function that this library will call whenever a DHCP packet is detected. I intend to maintain this package in the Home Assistant team.
Bug#1077245: ITP: python-fnv-hash-fast -- fast version of fnv1a
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: python-fnv-hash-fast Version : 0.5.0 Upstream Contact: J. Nick Koston * URL : https://github.com/bdraco/fnv-hash-fast * License : Expat Programming Lang: Python Description : fast version of fnv1a This package provides a Python library which is a fast version of fnv1a. It use a CPP implementation of fnv1a (32) if cython is available, and will fallback to pure python from the fnvhash package if it is not. I intend to maintain this package in the Home Assistant team.
Bug#1077211: ITP: python-aioairq -- asynchronous library to retrieve data from air-Q devices
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: python-aioairq Version : 0.4.2 Upstream Contact: Daniel Lehmann * URL : https://github.com/CorantGmbH/aioairq * License : Apache-2.0 Programming Lang: Python Description : asynchronous library to retrieve data from air-Q devices This Python library provides asynchronous data access to local air-Q devices. . This package is a dependency of Home Assistant. I intend to maintain this package in the Home Assistant team.
Re: Packaging homeassistant in Debian
Hi Joerg, Thanks for voicing your opinion. On 7/26/24 15:25, Joerg Jaspert wrote: Not going to stop you - I actually think it would be a nice thing to have something like this packaged for real - but how realistic is this in a Debian stable release (assuming you ever manage to get all of it packaged and uploaded). Using HA myself, that thing and all around it is changing faster than anything else I ever saw. One basically finished updating ones install and it goes again "Update available". That's part of my motivation for having HA in Debian: I hate that it wants to update too fast: faster than I can cope with, demanding too much of my time. I do not really care having the latest shiny last thing, I want something that works, that is reliable, and that I don't have to maintain too much. Also, what really is there in the updates? Maybe one doesn't care about them 99% of the time. That driver foo for the device bar that you don't even use, do we really need to update it? I hope the core of Home Assistant itself doesn't move *THAT* fast. It's hard to tell without inspecting all pieces of the puzzle. Combined with upstreams focus on their HassOS thing (and yes, that *is* damn easy and low-effort to use!) I very much like Homeassistant. But there's many things I hate with HassOS, like the fact it is focused on using containers, and trying all it can to avoid exposing anything to users. I feel very uncomfortable using it. I'm currently using their Virtualbox image. My current process is to, every month, spend a few hours maintaining it doing this: - shutdown - snapshot - start - upgrade - stop - snapshot - start This is clearly what I would like to stop doing. I currently have to, because a few times, the automated upgrades of Home Assistant broke badly on me. I'm sure it's going to happen again: it also happened to some of my friends. is upstream support for "oh gosh you outdated distro" even there, in case this ends up in a stable release? That's probably what they will say. Nothing new, this is what all upstream tell. Frankly, I do not know what's going to happen with HA in a stable release or not. But even running Unstable would be a better solution for me than their "OS". I sure would like if it ever goes with an "apt install homeassistant" and you have what "put this HASSOS image into a VM/raspy and automate away" does now, thats a cool target. But you found yourself a hill even larger than the OpenStack one - and one that changes even more often and faster. :) OpenStack needs roughly 200 packages upgrade every 6 months, in a predictable way. I currently am not sure what it's going to be with HA. I'm convince that *a lot* of device drivers for many stuff (heatings, air-cond, etc.) will not change, because I'm seeing that what we're packaging smells like old stuff already. It doesn't mean unmaintained, it's probably doing what it should already, and doesn't need update. Also, for OpenStack, I've been mostly alone. We're currently 5 enthusiastic DDs in the Home Assistant team. It's possible even more will join us. I don't think I'm even going to be the main driver behind this packaging, Edward seems very motivated, and he's done a lot already. Anyways, that's the beginning of an adventure. Where this will lead us, I'm not sure yet... For sure, looking at how, and even more importantly what things get updated by upstream will be interesting, and this will tell us if it's possible to have this in Debian Stable. Maybe the only solution will be having most drivers in Debian Stable (the huge list of 680+ python modules we're packaging), and have HA only in a non-official backport repo. IMO this would already be a great achievement. Cheers, Thomas Goirand (zigo)
Bug#1077136: ITP: python-aio-geojson-generic-client -- generic async GeoJSON client library
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: python-aio-geojson-generic-client Version : 0.4 Upstream Contact: Malte Franken * URL : https://github.com/exxamalte/python-aio-geojson-generic-client * License : Apache-2.0 Programming Lang: Python Description : generic async GeoJSON client library This library provides convenient async generic access to GeoJSON https://datatracker.ietf.org/doc/html/rfc7946 feeds. It uses asyncio and aiohttp. . This package is a dependency for Home Assistant. I itend to maintain this package within the home assistant team.
Packaging homeassistant in Debian
Dear friends, Together with a bunch of people during debcamp, we decided to package homeassistant. This is a huge task, with hundreds of dependencies. Since there's too many, we've been told to no Cc: debian-devel@l.d.o when filing the ITPs, and instead write a summary (as per developper's ref). Well, we wont write such a summary, but everyone can follow our progress on this wiki page, which fills the same purpose: https://wiki.debian.org/Python/HomeAssistant As you may see, there are 600+ packages to do. Since we're a lot of people on the task, we believe it can be done. I've written 13 packages myself, and uploaded most already. Edward Betts beated me by a very much higher numbers! billchenchina1 and omnidapps already wrote many packages waiting in the NEW queue too. Note that we decided to push these packages to a separate team, as we don't really see drivers for heaters or air cond systems as very useful for any other things than homeassistant. Things that do make sense for a more general purpose will be pushed to the Python team as we see fit. Cheers, Thomas Goirand (zigo)
Bug#1077008: ITP: python-advantage-air -- API helper for Advantage Air's MyAir and e-zone API
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: python-advantage-air Version : 0.4.4 Upstream Contact: Brett Adams * URL : https://github.com/Bre77/advantage_air * License : Expat Programming Lang: Python Description : API helper for Advantage Air's MyAir and e-zone API API helper for Advantage Air's MyAir and e-zone API I intend to maintain this package within the Home Assistant team.
Bug#1077007: ITP: python-adguardhome -- Asynchronous Python client for the AdGuard Home API
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: python-adguardhome Version : 0.7.0 Upstream Contact: Franck Nijhof * URL : https://github.com/frenck/python-adguardhome * License : Expat Programming Lang: Python Description : Asynchronous Python client for the AdGuard Home API This package allows you to control and monitor an AdGuard Home instance programmatically. It is mainly created to allow third-party programs to automate the behavior of AdGuard. . An excellent example of this might be Home Assistant, which allows you to write automations, to turn on parental controls when the kids get home. I intend to maintain this package within the Home Assistant team.
Bug#1076985: ITP: python-alarmdecoder -- interface for the AlarmDecoder (AD2) family of alarm devices
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: python-alarmdecoder Version : 1.13.11 Upstream Contact: Nu Tech Software Solutions, Inc. * URL : http://github.com/nutechsoftware/alarmdecoder * License : Expat Programming Lang: Python Description : interface for the AlarmDecoder (AD2) family of alarm devices This Python library aims to provide a consistent interface for the AlarmDecoder product line: AD2USB, AD2SERIAL and AD2PI. This also includes devices that have been exposed via ser2sock, which supports encryption via SSL/TLS. I intend to maintain this package within the home assistant team.
Bug#1076982: ITP: python-adext -- AlarmDecoder extended
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: python-adext Version : 0.4.3 Upstream Contact: AJ Schmidt * URL : https://github.com/ajschmidt8/adext * License : Expat Programming Lang: Python Description : AlarmDecoder extended Adext is a small package that extends alarmdecoder to include some additional methods for Home Assistant. I intend to maintain this package within the home assistant team.
Bug#1076980: ITP: python-aemet-opendata -- AEMET OpenData Rest API library
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: python-aemet-opendata Version : 0.5.3 Upstream Contact: Álvaro Fernández Rojas * URL : https://github.com/Noltari/AEMET-OpenData * License : GPL-2 Programming Lang: Python Description : AEMET OpenData Rest API library AEMET-OpenData is a Python module implementing an interface to the AEMET OpenData Rest API. It allows a user to gather all the public weather information from AEMET (Agencia Estatal de Meteorología). I intend to maintain this package within the home assistant team.
Bug#1076979: ITP: python-adb-shell -- implementation of ADB with shell and FileSync functionality
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: python-adb-shell Version : 0.4.4 Upstream Contact: Jeff Irion * URL : https://github.com/JeffLIrion/adb_shell * License : Apache-2 Programming Lang: Python Description : implementation of ADB with shell and FileSync functionality This Python package implements ADB shell and FileSync functionality. I itend to maintain this package within the home asssistant team.
Bug#1076978: ITP: python-adax-local -- library to communicate with Adax heating systems
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: python-adax-local Version : 0.1.5 Upstream Contact: Daniel Hjelseth Høyer * URL : https://github.com/Danielhiversen/pyAdaxLocal * License : Expat Programming Lang: Python Description : library to communicate with Adax heating systems This package provides a library to communicate locally to Adax heating systems. I intend to maintain this package within the home asssistant team.
Bug#1076977: ITP: python-adax -- library to communicate with Adax heaters
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: python-adax Version : 0.4.0 Upstream Contact: Daniel Hjelseth Hoyer * URL : https://github.com/Danielhiversen/pyAdax * License : Expat Programming Lang: Python Description : library to communicate with Adax heaters This package provides a library to communicate with Adax heaters. . To use this library, one needs account ID and password in the Adax system. I intend to maintain this package in the homeasssistant team.
Bug#1076947: ITP: python-accuweather -- wrapper for getting weather data from AccuWeather API
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: python-accuweather Version : 3.0.0 Upstream Contact: Maciej Bieniek * URL : https://github.com/bieniu/accuweather * License : Apache-2 Programming Lang: Python Description : wrapper for getting weather data from AccuWeather API This package is a python wrapper for getting weather data from the AccuWeather HTTP API. One needs to generate an API key at the AccuWeather site at https://developer.accuweather.com/user/register, and after registration it is possible to use the API. I'm packaging this within the Home Assistant team.
Re: what about Netplan?
On 7/14/24 18:09, Steve McIntyre wrote: I understand what you're trying to say, but that's a disingenuous comparison. systemd is a massive (some would say *too* massive) project with fingers in many pies. How many of those people have touched *networking* bits? I agree. Also, Netplan is just a configuration layer. That's a way simpler than NM or sd-networkd. Cheers, Thomas Goirand (zigo)
Re: what about Netplan?
On 7/11/24 09:16, Philip Hands wrote: I've only seen netplan mentioned in passing in this thread so far. It seems like it is exactly what we need as a replacemtent for ifupdown (given that is what it's designed for AFAICT -- I've not yet tried it out myself though) and it already supports configuring systemd-networkd, so seems like a more sensible route than duplicating that effort in D-I. See: https://netplan.readthedocs.io/ Cheers, Phil. Systemd networkd is nice, it reacts correctly to event and such, but its configuration without Netplan is just horrible. So Netplan fills nicely the gap, IMO. Cheers, Thomas Goirand (zigo)
Re: default network management tools
On 7/10/24 20:03, Michael Biebl wrote: Since there is a lot of support for this idea, the next logical step as smcv said, would be to make d-i/netcfg networkd aware. At the beginning, this could be opt-in (for testing purposes) and we could make it the default later on. Any takers? If someone were to add that support in d-i for Trixie, that'd be great. Even better IMO, if it had support for Netplan. Then we could switch the default for Forky? Cheers, Thomas Goirand (zigo)
Re: default network management tools
On 7/9/24 12:45, Simon McVittie wrote: To some extent, we are already there: for new laptop/desktop installations, NM is already the default (certainly true for GNOME, and hopefully for most/all of the other tasksel-supported desktops). Right. For new server/embedded installations, I think networkd would be a better default than ifupdown[...] networkd seems like an entirely reasonable implementation of "make the easy things easy"[...] You're probably right. However, such a change is best to be planned early in the development stage, like just right after a freeze. I'm wondering if it's not already too late for Trixie. Also, you may have seen that the official Debian cloud images have moved to using Ubuntu's Netplan. Don't we want to also move to it? Cheers, Thomas Goirand (zigo)
Re: ifupdown maintenance
On 7/9/24 13:31, Simon McVittie wrote:
I would tend to count "execute arbitrary user-supplied code on
networking changes" as a specialized requirement - by definition,
for this to happen, someone (the sysadmin) needs to have written and
installed the user-supplied hook script. If the sysadmin has made the
decision to do that, then they can equally well make the decision to
install networkd-dispatcher, or ifupdown{,-ng,2} or any other networking
management framework of their choice that supports the feature they need.
Things aren't as easy as you describe. Some packages (like openvswitch)
are currently working out-of-the-box in Debian. I certainly wouldn't
like it to stop working by default. (note: I haven't looked at it yet...
hopefully, it can also work with sd-networkd. but this was just an example)
(Because non-trivial networking is dynamic and can be shared between
multiple components, and in practice this has been the case for years,
I would personally say that if you want arbitrary actions to happen
as a side-effect of networking state changes, a better way to achieve
that is for long-running processes to monitor the network interfaces
via e.g. netlink, and trigger those arbitrary actions whenever there is
a state change, regardless of whether the state change was initiated
by the ifupdown family, NM, networkd, Docker, libvirtd, VPN services, or
something else. But I realise opinions might vary.)
Nice wishful thinking, but that's not the current state of things.
Such a simple thing as sshd isn't even binding properly when the IP of a
server is missing, and in some cases, needs restart (for example if
non-local-ip bind isn't set in sysctl). And there's lower profile
packages we need to address too...
Cheers,
Thomas Goirand (zigo)
Re: Bug#1073496: ITP: requests-mock -- Python module to stub HTTP requests in testing code
On 6/16/24 20:48, Julian Gilbey wrote: On Sun, Jun 16, 2024 at 05:20:37PM +0200, Bastian Blank wrote: On Sun, Jun 16, 2024 at 03:43:38PM +0100, Julian Gilbey wrote: * Package name: requests-mock Version : 1.12.1 Upstream Author : Jamie Lennox * URL : https://github.com/jamielennox/requests-mock * License : Apache-2.0 Programming Lang: Python Description : Python module to stub HTTP requests in testing code This module creates a custom adapter that allows one to predefine responses when certain URIs are called when using the `requests` module. Is this something different then the already exising python-requests-mock? Oh, oops - I somehow missed that. Closing this ITP then. Julian Hi, I always welcome co-maintainer! :) Cheers, Thomas Goirand (zigo)
Bug#1072208: ITP: python-coriolisclient -- client bindings and cli to the Coriolis migration API
Package: wnpp
Severity: wishlist
Owner: Thomas Goirand
X-Debbugs-Cc: debian-devel@lists.debian.org
* Package name: python-coriolisclient
Version : 1.0.9
Upstream Contact: Cloudbase Solutions Srl
* URL : https://github.com/cloudbase/python-coriolisclient
* License : Apache-2.0
Programming Lang: Python
Description : client bindings and cli to the Coriolis migration API
The Coriolis command-line API offers an interface over the REST API provided
by the Coriolis migration service.
.
This package contains the a client for the Coriolis API. There's a Python API
(the "coriolisclient" module), and a command-line script ("coriolis").
Re: About i386 support
On 5/19/24 17:30, r...@neoquasar.org wrote: I have an N270 system I can use to contribute, if someone is willing to explain what I need to do to make it useful. Hi, If you allow me ... I was expecting someone else to write it before me, but seeing nobody does, let me try. ... The issue isn't only about how many contributors, or how much effort they put into it, but how much *everyone* in the project wants to spend time on i386 support. For example, *I* don't care at all about 32 bits arch, and would prefer if these were to be sent to ports.debian.org. I really mean *all* 32 bits arch, including armhf for example. Indeed, it's annoying each time when: - I have to pin Arch: in debian/tests/control for example, only because some packages have dropped 32 bits support (hint: sometimes, because some of them also maintained by myself as well, like OpenVSwitch, for example). - I have to care for failed build (often because of unit tests) in i386 of packages I know wont mater for these arch. And this is only 2 examples. This is a considerable loss of my (limited) contributor time. If 32 bits support was removed from Debian, this would make my (Debian) life easier, while I have zero use of 32 bits. If I had to setup Linux on a pi-zero, I probably would choose a more embedded distro than Debian anyways, and that's what I would recommend to anyone. Anyone running Debian on a non-amd64 capable laptop, at this time, should stop procrastinate, and get decent hardware (as mentioned earlier in this thread, cheap 2nd hands amd64 laptops are *very* cheap). Because I know others care, I continue to make the effort when possible. But these others should remember that's annoying me, and should weight the collective cost, because I might not be the only one... and everyone slightly involved in maintaining Debian might have, at some point, loss some time on 32 bits support. So this is a collective decision we should make: is 32 bits still relevant enough for spending (wasting?) our collective (limited) time on it? I'd vote no ... Especially considering i386 can become an unofficial port for those who care. Even if I will respect our community decision until the majority agrees, and will continue to do my best with i386 support until then, it has to happen one day. The only question is how long. Can Trixie be the last release with 32 bits support? Cheers, Thomas Goirand (zigo)
Re: Silent hijacking and stripping records from changelog
On 4/9/24 03:25, James McCoy wrote: When I first started looking into Rust packaging it was initially going to be for a workspace of crates. I didn't receive any pushback when I asked about taking over the one crate that had already been packaged and handling it from a single source package for that workspace. In the end I changed my mind and continued using the monorepo for the rest of the crates. If you allow me give my perspective from an outsider: the monorepo thingy for crates is the only place in Debian where I've seen it, and it's *VERY* confusing. Plus there are many reasons where one may want to package something in a different team, so IMO it's not a good idea. Plus what if some project hold a multi-language thing, like rust and another language, as source package, and then we need to generate multiple binaries? (real-life thingy, but can't remember which package) Just my 2 cents... :P Cheers, Thomas Goirand (zigo)
Bug#1069230: ITP: python-sherlock -- distributed inter-process locks with a choice of backend
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: python-sherlock Version : 0.4.1 Upstream Contact: Vaidik Kapoor * URL : https://github.com/py-sherlock/sherlock * License : Expat Programming Lang: Python Description : distributed inter-process locks with a choice of backend Sherlock is a library that provides easy-to-use distributed inter-process locks and also allows you to choose a backend of your choice for lock synchronization. Note: this is a new dependency of magnum-cluster-api OpenStack module.
Bug#1069229: ITP: python-haproxyadmin -- work with HAProxy via the stats socket
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: python-haproxyadmin Version : 0.2.4 Upstream Contact: Pavlos Parissis * URL : https://github.com/unixsurfer/haproxyadmin * License : Apache-2.0 Programming Lang: Python Description : work with HAProxy via the stats socket Haproxyadmin is a Python library for interacting with HAProxy load balancer to perform operations such as enabling/disabling servers. It does that by issuing the appropriate commands over the stats socket provided by HAProxy. It also uses that stats socket for retrieving statistics and changing settings. Note: this is a new dependency of the magnum-cluster-api module for OpenStack.
Re: Seeking a small group to package Apache Arrow (was: Bug#970021: RFP: apache-arrow -- cross-language development platform for in-memory analytics)
On 3/25/24 19:17, Julian Gilbey wrote: Hi all, [NB: sent to d-science, d-python, d-devel and the RFP bug; reply-to set to d-science and the RFP bug only] An update on Apache Arrow, and in particular the Python library PyArrow. For those who don't know: Apache Arrow is a development platform for in-memory analytics. It contains a set of technologies that enable big data systems to process and move data fast. It specifies a standardized language-independent columnar memory format for flat and hierarchical data, organized for efficient analytic operations on modern hardware. The project is developing a multi-language collection of libraries for solving systems problems related to in-memory analytical data processing. This includes such topics as: * Zero-copy shared memory and RPC-based data movement * Reading and writing file formats (like CSV, Apache ORC, and Apache Parquet) * In-memory analytics and query processing (from: https://arrow.apache.org/docs/index.html) Pandas has announced that Pandas 3.x will depend on PyArrow in a critical way (it will back the "string" datatype), and it is due to be released imminently. So this is a plea for anyone looking for something really helpful to do: it would be great to have a group of developers finally package this! There was some initial work done (see the RFP bug report for details: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=970021), but that is fairly old now. As Apache Arrow supports numerous languages, it may well benefit from having a group of developers with different areas of expertise to build it. (Or perhaps it would make more sense to split the upstream source into a collection of different Debian source packages for the different supported languages. I don't know.) Unfortunately I don't have the capacity to devote any time to it myself. Thanks in advance for anyone who can step forward for this! Best wishes, Julian Hi, I may not have much available time to help, though I'd love to have Arrow in Debian, as Ceph uses it, and currently use an embedded version. Cheers, Thomas Goirand (zigo)
Re: Validating tarballs against git repositories
On 3/30/24 08:02, Gioele Barabucci wrote: For too many core packages there is an opaque "something happens on the Debian maintainer laptop" step that has no place in 2024. Let's replace this by an opaque "something happens on the Salsa CI". Cheers, Thomas Goirand (zigo)
Re: Validating tarballs against git repositories
On 4/1/24 00:32, Stefano Rivera wrote: So... for Python packages using setuptools-scm, we're pushed towards depending on upstream-created source tarballs (sdists), rather than upstream git archives, because we don't have the ".git" directory in our source packages. Hi Stefano, Thanks for jumping in this thread, though I'll have to disagree with you... with all due respect! :) As you know, I'm by far the biggest uploader of Python modules in Debian, due to the fact I'm maintaining OpenStack. As you may know as well, the reason I'm not maintaining all of that inside the Debian Python Team, is only because it's forbidden to use an upstream git tag workflow in the team, and that I have to use pristine-tar. I very much regret this fact, but live with it when I have to package within the Debian Python Team. Anyways, on the 400+ packages that I maintain within the OpenStack team, I did come across some upstream using setuptools-scm. To my experience, using the: git archive --prefix=$(DEBPKGNAME)-$(VERSION)/ $(GIT_TAG) \ | xz >../$(DEBPKGNAME)_$(VERSION).orig.tar.xz workflow out of an upstream always work, including for those that are using setuptools-scm. One simply needs to add the dependency, and correctly set, with something like this: SETUPTOOLS_SCM_PRETEND_VERSION=$(shell dpkg-parsechangelog -SVersion \ | sed -e 's/^[[:digit:]]*://' \ -e 's/[-].*//' \ -e 's/~/.0/' \ -e 's/+dfsg1//' \ | head -n 1) Because I'm dealing with the DPT packages as well, I can tell, and I insist: the workflow to to work with upstream Git is a way nicer than the pristine-tar / gbp import-orig one. The upstream tag workflow *ALWAYS* work, and often (even: always, for the case of Python modules) contain less pre-built artifacts. Also, sdists are *not* "upstream-created source tarballs". I consider the binary form built for PyPi. Just like we have .debs, PyPi has tarballs and wheels, rather than how you describe them. By the way, am I the only one to think that's so lame to use tarballs in so many ways... Isn't this a so ... legacy retro-computing format? :) Cheers, Thomas Goirand (zigo)
Bug#1067011: ITP: python-observabilityclient -- OpenStack Observability Client
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: python-observabilityclient Version : 0.1.1 Upstream Contact: OpenStack Foundation * URL : https://infrawatch.github.io/documentation/ * License : Apache-2.0 Programming Lang: Python Description : OpenStack Observability Client observabilityclient is an OpenStackClient (OSC) plugin implementation that implements commands for management of Prometheus. This is a new dependency of OpenStack.
Re: Package marked for autoremoval due to closed bug?
On 3/15/24 07:14, Andreas Tille wrote: I simply remove all those testing removal warnings in my mailbox to cope with this and by doing so I'm probably missing real issues I should rather care about. I know what you're talking about: anyone that maintains a lot of packages always receive waves of multiple dozens of email, and often, it's hardly actionable. Then I just end up ignoring them, hoping the fix is already under way by the person in charge of that new dependency I never heard of before. I hope one day, someone will have the skill/time/courage to refactor these messages into something humanly readable. One message per day per DD, with a summary of the possible AUTORM pointing at the list of RC bugs with links, would be a way more useful than ONE message per package, for example. Thanks to all who are involved in this complex migration Yeah, +1 Thomas Goirand (zigo)
Re: Package marked for autoremoval due to closed bug?
On 3/15/24 21:52, Paul Gevers wrote: Hi, Disclaimer: exception only valid while the time_t transition is ongoing. On 15-03-2024 6:15 a.m., Steve Langasek wrote: Migration to testing is largely out of control of the maintainers at this point, it's very much dependent on folks rebootstrapping armel and armhf against the new library names. Should these bugs be downgraded again to important severity? As I'm normally watching out for out-of-sync packages, I'm fine (with my Release Team hat on) with maintainers downgrading RC bugs in testing that have been fixed in unstable and that don't require a quick update in testing (e.g. security issues probably warrant discussing the tpu path with the RT). Once time_t 64 bit is done, I'll be filling bugs for packages that don't migrate again, so the lack of the fix in testing won't go unnoticed. For bookkeeping purposes, please usertag downgraded bugs with user release.debian@packages.debian.org and usertag time_t-downgrade. Please be careful with downgrading RC bugs. Paul Hi Paul, I leave this to your own judgement, of course (with your "release team hat"). But when the AUTORM period was announced as reduced, I thought like it was probably a bad call, and that the previous AUTORM was aggressive enough. I didn't dare to express myself about it at the time, as maybe you knew better. My thinking was: after all, people should fix their bugs, no? Plus release team people must know better... But after a few months with the shorter AUTORM period, my opinion is growing firmer: the previous one (whatever it was) seemed more appropriate to me with the way Debian is being developed (ie: largely by volunteers on their free time), and for those of us in charge of maintaining a long (and sometimes complicated) chain of dependencies. Now, with this type of (breaking) transition, would growing back the AUTORM period (to what it used to be) help? Or are you still in the opinion making it shorter was a good move? Your thoughts? Cheers, Thomas Goirand (zigo)
Bug#1066927: ITP: python-momepy -- Urban Morphology Measuring Toolkit
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: python-momepy Version : 0.7.0 Upstream Contact: Martin Fleischmann * URL : https://github.com/pysal/momepy * License : BSD-3-clause Programming Lang: Python Description : Urban Morphology Measuring Toolkit Momepy is a library for quantitative analysis of urban form - urban morphometrics. It is part of PySAL (Python Spatial Analysis Library) and is built on top of GeoPandas, other PySAL modules, and networkX. Note: this is a new dependency of networkx, so we can continue to build its documentation.
Bug#1066925: ITP: python-contextily -- Context geo-tiles in Python
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: python-contextily Version : 1.5.2 Upstream Contact: Dani Arribas-Bel * URL : https://github.com/geopandas/contextily * License : BSD-3-clause Programming Lang: Python Description : Context geo-tiles in Python Contextily is a package to retrieve tile maps from the internet. It can add those tiles as basemap to matplotlib figures or write tile maps to disk into geospatial raster files. Bounding boxes can be passed in both WGS84 (EPSG:4326) and Spheric Mercator (EPSG:3857). Note: this is a new build-depends for networkx, so we can continue to build its documentation.
Bug#1066922: ITP: python-mercantile -- Web mercator XYZ tile utilities
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: python-mercantile Version : 1.2.1 Upstream Contact: Sean Gillies * URL : https://github.com/mapbox/mercantile * License : BSD-3-clause Programming Lang: Python Description : Web mercator XYZ tile utilities The mercantile module provides ul(xtile, ytile, zoom) and bounds(xtile, ytile, zoom) functions that respectively return the upper left corner and bounding longitudes and latitudes for XYZ tiles, a xy(lng, lat) function that returns spherical mercator x and y coordinates, a tile(lng, lat, zoom) function that returns the tile containing a given point, and quadkey conversion functions quadkey(xtile, ytile, zoom) and quadkey_to_tile(quadkey) for translating between quadkey and tile coordinates. Note: This is a new build-dependency for networkx so we can continue to build its documentation.
Bug#1066184: ITP: networking-generic-switch -- OpenStack virtual network service - networking-generic-switch
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: networking-generic-switch Version : 7.2.0 Upstream Contact: OpenStack Foundation * URL : https://github.com/openstack/networking-generic-switch * License : Apache-2.0 Programming Lang: Python Description : OpenStack virtual network service - networking-generic-switch Neutron provides an API to dynamically request and configure virtual networks. These networks connect "interfaces" from other OpenStack services (such as vNICs from Nova VMs). The Neutron API supports extensions to provide advanced network capabilities, including QoS, ACLs, and network monitoring. . This package provides the networking-generic-switch ML2 plugin.
Bug#1066089: ITP: python-reactivex -- asynchronous and event-based programs using observable collections
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: python-reactivex Version : 4.0.4 Upstream Contact: Dag Brattli * URL : http://reactivex.io, https://github.com/ReactiveX/RxPY * License : Expat Programming Lang: Python Description : asynchronous and event-based programs using observable collections This package provides a library for composing asynchronous and event-based programs using observable collections and query operator functions in Python. Using Rx, developers represent asynchronous data streams with Observables, query asynchronous data streams using operators, and parameterize concurrency in data/event streams using Schedulers.
Bug#1066087: ITP: python-influxdb-client -- InfluxDB 2.0 Python client library
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: python-influxdb-client Version : 1.40.0 Upstream Contact: InfluxData, Inc. * URL : https://github.com/influxdata/influxdb-client-python * License : Expat Programming Lang: Python Description : InfluxDB 2.0 Python client library Client library for use with InfluxDB 2.x and Flux. InfluxDB 3.x users should instead use the lightweight v3 client library (influxdb3-python). InfluxDB 1.x users should use the v1 client library (influxdb-python). For ease of migration and a consistent query and write experience, v2 users should consider using InfluxQL and the v1 client library (influxdb-python). . The API of the influxdb-client is not the backwards-compatible with the old one influxdb-python.
Bug#1065823: ITP: lenovolegionlinux -- CLI and GUI for Lenovo Legion laptops fan and power control
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: lenovolegionlinux Version : 0.0.9 Upstream Contact: johnfanv2 * URL : https://github.com/johnfanv2/LenovoLegionLinux/ * License : GPL-2 Programming Lang: C, Python Description : CLI and GUI for Lenovo Legion laptops fan and power control This package provides a command line interface and a graphical user interface for controlling many power and fan behavior for Lenovo Legion Laptops. It is implemented in Python. . This package also sets fan curve on startup for Lenovo Legion laptops, and apply different profiles if the battery charge is plugged or not.
Bug#1064502: ITP: python-aiounittest -- test asyncio code more easily
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: python-aiounittest Version : 1.4.2 Upstream Contact: Krzysztof Warunek * URL : https://github.com/kwarunek/aiounittest * License : Expat Programming Lang: Python Description : test asyncio code more easily The aiounittest is a helper library to ease of your pain (and boilerplate), when writing a test of the asynchronous code (:code:`asyncio`). With this library, it is possible to test: * synchronous code (same as the unittest.TestCase from the std lib) * asynchronous code: it supports syntax like async/await (Python 3.5+) and asyncio.coroutine/yield from (Python 3.4). Note: this is a new build-dependency for python-ddt, which is used for testing OpenStack.
Bug#1063899: ITP: auxilium -- tool for parse args in many shell (bash, ksh,zsh)
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: auxilium Version : 0.0.9 Upstream Contact: Philippe Seraphin * URL : https://salsa.debian.org/openstack-team/third-party/auxilium * License : Apache-2.0 Programming Lang: Bash Description : tool for parse args in many shell (bash, ksh,zsh) This help you to parse command-line arguments. You can source it in your shell script and use different function to add argument, print usage and parse arguments
Bug#1059614: ITP: ikvswitch -- virtual switch infrastructure designed for complex network deployment testing
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: ikvswitch Version : 0.0.1 Upstream Contact: Thomas Goirand * URL : https://salsa.debian.org/openstack-team/debian/ikvswitch * License : Apache-2.0 Programming Lang: Shell Description : virtual switch infrastructure designed for complex network deployment testing This package sets up virtual machines that will act as 2 spine switches and 3 racks with 2 leaf switches each, to simulate a datacenter setup. All 8 switches are connected to each other over un-numbered IPv6 link-local addresses over which a BGP link is established (ie: this is a bgp-to-the-host setup, or L3 only networking). . Once setup, it is possible for the user to connect virtual machines to this virtual infrastructure. Each VM can be connected to 2 rack switches over BGP as well. . The goal of this package is to be able to experiment with virtual machines, as if they were physical machines installed into 3 physical racks, with this type of L3 connectivity only. Note: I'm planning to use this for testing complex OpenStack networking setup, but that's far from being the only use case: this is very general purpose.
Bug#1058361: ITP: python-pyasyncore -- asyncore for Python 3.12 onwards
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: python-pyasyncore Version : 1.0.2 Upstream Contact: Simon Robinson * URL : https://github.com/simonrob/pyasyncore * License : Python Software Foundation License Programming Lang: Python Description : asyncore for Python 3.12 onwards This package contains the asyncore module as found in Python versions prior to 3.12. It is provided so that existing code relying on "import asyncore" is able to continue being used without significant refactoring. . The module's source code is taken directly from the Python standard library. The specific version of asyncore.py used is the last update before the addition of removal warnings at import time, and is essentially equivalent to the version provided with Python 3.9. . Please note that new projects should prefer asyncio. Note that I'm creating this package as a temporary measure to fix some of the 3.12 issues that are ongoing. Projects like Taskflow cannot be easily converted to asyncio, because some other packages are using both Eventlet and Taskflow, and asyncio is not compatible with Eventlet. So we have to live with this for a while more, until Eventlet can be fixed to use asyncio...
Bug#1057636: ITP: swift-tools -- Swift cluster cli helpers utilities
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: swift-tools Version : 0.0.1 Upstream Contact: Philippe Seraphin * URL : https://salsa.debian.org/openstack-team/third-party/swift-tools * License : Apache-2.0 Programming Lang: Python Description : Swift cluster cli helpers utilities This package contains a set of utilities to help managing Swift cluster. It helps, for example: * check rebalance status * check status of the cluster * check max oldest completion
Bug#1057389: ITP: haproxy-cmd -- command line utility to control backends of haproxy
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: haproxy-cmd Version : 0.0.1 Upstream Contact: Thomas Goirand * URL : https://salsa.debian.org/openstack-team/third-party/haproxy-cmd * License : Apache-2.0 Programming Lang: Python Description : command line utility to control backends of haproxy This package contains a helper to send commands through the haproxy socket, so it is possible to maintain servers part of a cluster by draining, enabling and stopping servers part of a backend. . This utility is, in fact, a wrapper around the haproxy admin socket, so it is easier to use, with bash-completion and so on.
Bug#1056044: ITP: python-jsonschema-specifications -- JSON Schema meta-schemas and vocabularies, exposed as a Registry
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: python-jsonschema-specifications Version : 2023.11.1 Upstream Contact: Julian Berman * URL : https://github.com/python-jsonschema/jsonschema-specifications * License : Expat Programming Lang: Python Description : JSON Schema meta-schemas and vocabularies, exposed as a Registry This package contains JSON support files from the JSON Schema Specifications (metaschemas, vocabularies, etc.), packaged for runtime access from Python as a referencing-based Schema Registry. Note: This package is needed to update python-jsonschema to the latest upsteram release.
Bug#1054116: ITP: puppet-module-puppet -- Puppet module for Puppet itself (client and server)
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: puppet-module-puppet Version : 18.0.0 Upstream Contact: Theforeman * URL : https://github.com/theforeman/puppet-puppet * License : Apache-2.0 Programming Lang: Puppet, Ruby Description : Puppet module for Puppet itself (client and server) Puppet lets you centrally manage every important aspect of your system using a cross-platform specification language that manages all the separate elements normally aggregated in different files, like users, cron jobs, and hosts, along with obviously discrete elements like packages, services, and files. . This module contains a puppet to setup, configure and maintain puppet itself, client and server.
Bug#1054113: ITP: puppet-module-extlib -- Puppet module for Extlib
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: puppet-module-extlib Version : 7.0.0 Upstream Contact: Vox Pupuli * URL : https://github.com/voxpupuli/puppet-extlib * License : Apache-2.0 Programming Lang: Puppet, Ruby Description : Puppet module for Extlib Puppet lets you centrally manage every important aspect of your system using a cross-platform specification language that manages all the separate elements normally aggregated in different files, like users, cron jobs, and hosts, along with obviously discrete elements like packages, services, and files. . This module contains extlib: functions and facts that are out of scope for stdlib. Some of them are even intrinsically tied to stdlib.. This is a dependency to package puppet-module-puppet (ie: a puppet module to setup and configure the puppet agent & server).
Re: Is there a generic canonical way for a package script to check network connectivity?
On 10/9/23 07:20, Simon Richter wrote:
Hi,
On 09.10.23 11:49, Jonathan Kamens wrote:
I need to be able to tell from one of my package scripts whether the
host has networking connectivity.
無. There is no such thing as "networking connectivity."
There is "has access to a particular service, at this precise moment in
time" and "is usually connected to an unmetered Internet connection so
there is a reasonable expectation that a particular service can be
reached and should be made part of a workflow."
I very much agree with Simon. There's all sorts of "networking
connectivity", partial or not. For example, would you consider that your
server has network connectivity if it only has L2 link local
connectivity to the neighboring switches? In some case, you shouldn't.
In some case (like using bgp-to-the-host setup), you should first check
if FRR is using it to provide wider connectivity. In the case of an
OpenStack cluster, in some setup, FRR would do that, but typically the
nodes don't have internet access.
After many wrong designs, I ended up having a process that pings the
service I need to access to, with a script like this one:
TRIALS=300
while ! timeout 2 ping -q -c 1 ${DST_SERVER} >/dev/null \
&& [ "${TRIALS}" -gt 0 ] ; do
sleep 1
TRIALS=$(( ${TRIALS} - 1 ))
done
if [ "${TRIALS}" = 0 ] ; then
exit 1
else
exit 0
fi
Since I use this, I never had any issue.
(comments on the above script welcome... one improvement would be using
a timestamp using date to write the timeout in seconds, but in this
particular instance, I don't really care, I just care the caller script
waits until there's connectivity)
Cheers,
Thomas Goirand (zigo)
Bug#1053215: ITP: needrestart-gui -- web interface for needrestart
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: needrestart-gui Version : 0.0.1 Upstream Contact: Axel Jacquet * URL : https://salsa.debian.org/openstack-team/third-party/needrestart-gui * License : most-permissive Programming Lang: Python Description : web interface for needrestart This package provides a Python implementation to monitor services and provides a GUI to show their status and package versions. It uses in the background the needrestart package.
Re: [idea]: Switch default compression from "xz" to "zstd" for .deb packages
On 9/16/23 07:01, Hideki Yamane wrote:
* So, if we change {data,control}.tar file format in .deb from xz to zst,
we can reduce package installation time than ever since less decompression
time. It saves our lifetime a bit :)
* Downside: package file size is a bit larger than now, but enough bandwidth
will ease it for download time
- Not sure how repository size will be, need an experiment
Hi,
I'm not sure if we should switch to zstd, or if xz will do the work,
though I'd be delighted if the dpkg performances could be improved. I'm
spending all of my days installing server, sometimes with 1.5 TB of RAM
and 128 core (AMD Epyc...), on last gen NVMe, using a local mirror, it's
really painful to see how slow the debootstrap process is, compared to
what it could be. Unpacking multiple .deb at the same time seems a very
good idea to me, as well as parallelizing everything we can.
Just my 2 cents, as I wont be working on this,
Cheers,
Thomas Goirand (zigo)
Bug#1051838: ITP: python-scrapli-replay -- enable easy testing of scrapli programs
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: python-scrapli-replay Version : 2023.7.30 Upstream Contact: Carl Montanari * URL : https://github.com/scrapli/scrapli_replay * License : Expat Programming Lang: Python Description : enable easy testing of scrapli programs Easily test scrapli code with Pytest, or create mock SSH servers to play with. . Within Debian, this package is only useful for running unit tests for the package python-scrapli. Note: this is an indirect dependency for netmiko
Bug#1051831: ITP: python-ntc-templates -- TextFSM Templates for Network Devices, and wrapper for TextFSM's CliTable
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: python-ntc-templates Version : 3.5.0 Upstream Contact: Network to Code * URL : https://github.com/networktocode/ntc-templates/ * License : Apache-2.0 Programming Lang: Python Description : TextFSM Templates for Network Devices, and wrapper for TextFSM's CliTable This package contains TextFSM Templates for Network Devices, and a Python wrapper for TextFSM's CliTable. TextFSM helps make parsing cli commands more manageable. Note: this is a new dependency of netmiko that I would like to upgrade to the latest upstream release. Netmiko, itself, is a dependency of OpenStack networking-generic-switch, that configures vendor specific stuff of switches, so that Ironic (OpenStack baremetal) can work and setup things like VLANs automatically.
Bug#1051275: ITP: python-pyasn1-lextudio -- ASN.1 types and codecs
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: python-pyasn1-lextudio Version : 1.1.2 Upstream Contact: 2005-2019, Ilya Etingof * URL : https://github.com/lextudio/pyasn1 * License : BSD-2-clause Programming Lang: Python Description : ASN.1 types and codecs This package provides an implementation of ASN.1 types and codecs. It has been first written to support particular protocol (SNMP) but then generalized to be suitable for a wide range of protocols based on the ASN.1 specification.
Bug#1051272: ITP: python-pyasn1-modules-lextudio -- collection of ASN.1-based protocols modules
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: python-pyasn1-modules-lextudio Version : 0.2.9 Upstream Contact: Lex Li * URL : https://github.com/lextudio/pyasn1-modules * License : BSD-2-clause Programming Lang: Python Description : collection of ASN.1-based protocols modules The pyasn1-modules package contains a collection of ASN.1 data structures expressed as Python classes based on pyasn1 data model. . If ASN.1 module you need is not present in this collection, try using Asn1ate (from https://github.com/kimgr/asn1ate) tool that compiles ASN.1 documents into pyasn1 code.
Bug#1051265: ITP: python-pysmi-lextudio -- SNMP/SMI MIB parsing and conversion library
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: python-pysmi-lextudio Version : 1.0.4 Upstream Contact: Ilya Etingof * URL : https://github.com/lextudio/pysmi * License : BSD-2-clause Programming Lang: Python Description : SNMP/SMI MIB parsing and conversion library PySMI is a pure-Python implementation of SNMP SMI MIB parser. This tool is designed to turn ASN.1 MIBs into various formats. As of this moment, JSON and pysnmp modules can be generated from ASN.1 MIBs.
Bug#1051262: ITP: python-pysnmp-lextudio -- SNMP library v.1/v.2c/v.3 for agents and managers
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: python-pysnmp-lextudio Version : 5.0.26 Upstream Contact: LeXtudio Inc. * URL : https://github.com/lextudio/pysnmp * License : BSD-2-clause Programming Lang: Python Description : SNMP library v.1/v.2c/v.3 for agents and managers This is a Python implementation of SNMP v.1/v.2c/v.3 engine. Its general functionality is to assemble/disassemble SNMP messages from/into given SNMP Object IDs along with associated values. PySNMP also provides a few transport methods specific to TCP/IP networking. . PySNMP is written entirely in Python and is self-sufficient in terms that it does not rely on any third party tool (it isn't a wrapper). . This version is a fork of Ilya Etingof's project etingof/pysnmp. Ilya sadly passed away on 10-Aug-2022.
Bug#1049868: ITP: ceph-tools -- utilities to manage a Ceph cluster
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: ceph-tools Version : 0.0.1 Upstream Contact: Philippe Seraphin * URL : https://salsa.debian.org/openstack-team/third-party/ceph-tools * License : Apache-2.0 Programming Lang: bash, python Description : utilities to manage a Ceph cluster This package contains a set of utilities to help managing a Ceph cluster. It helps, for example: * managing rebalance * adding multiple OSD in a scheduled way * display the dispersion of OSD fillings
Re: debci / salsa ci: support for qemu runner
On 7/25/23 19:49, Johannes Schauer Marin Rodrigues wrote: having kvm available in debci and salsaci would be a big plus. The issue with nested virt, is that they prevent live-migration of VMs (Qemu doesn't support live-migrating nested MMU pages...). There's ongoing work to allow this in upstream Qemu, but as far as I know, this isn't ready yet. Once we have the feature in, we'll go from a "mostly unsupported" in public clouds to "mostly, everyone has it". Until then, I would recommend against using nested-virt whenever possible. Cheers, Thomas Goirand (zigo)
Re: Policy consensus on transition when removing initscripts.
On 6/27/23 17:45, Andreas Henriksson wrote: Dropping things and letting people pick them up if they think they are still useful seems to be the only practical way forward. It's not. As written by Russ in this thread, filling a bug against orphan-sysvinit-scripts so it takes over the abandoned script is. I wouldn't mind seeing this mandatory, and written in the policy. Cheers, Thomas Goirand (zigo)
Re: Policy consensus on transition when removing initscripts.
On 6/25/23 16:15, Mark Hindley wrote: Hello friends and colleagues, Debian Policy no longer requires that packages which provide a systemd .service file also provide an initscript. This permits maintainers who so wish to remove initscripts from their packages. However, initscripts remain used and useful[1], and uncoordinated removal can have significant effects on users' systems[2]. With the encouragement of the Technical Committee[3] and despite some unavoidable deficiencies resulting consequent on keeping initscripts without their intended package[4], orphan-sysvinit-scripts has collected and maintained some dropped initscripts. However, the process surrounding this has not been defined in Policy. Indeed, #975075[5] contains a number of suggestions that have not yet been followed through. The most recent proposal[6] for updating the Policy with a requirement to use tmpfiles.d(5) states "Init systems other than ``systemd`` should allow providing the same functionality as appropriate for each system, for example managing the directories from the init script shipped by the package." This creates an inconsistency whereby non-systemd inits are required to provide functionality in their initscript, but that initscript is not required to be present. To avoid breakage of existing systems and facilitate ongoing support for non-systemd inits, I would like to establish a consensus for - stating that initscripts remain useful. - requiring a coordinated transition of any initscript a maintainer wishes to drop to the orphan-sysvinit-scripts package and providing the relevant copyright information. Best wishes Mark There's some ongoing (or already working?) work for OpenRC to support systemd .service files. Contributing to this would be a much better use of your time, IMO. Cheers, Thomas Goirand (zigo)
Bug#1038771: ITP: magnum-cluster-api -- cluster API driver for Magnum
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: magnum-cluster-api Version : 0.6.0 Upstream Contact: Mohammed Naser * URL : https://github.com/vexxhost/magnum-cluster-api * License : Apache-2.0 Programming Lang: Python Description : cluster API driver for Magnum Magnum is an OpenStack project which offers container orchestration engines for deploying and managing containers as first class resources in OpenStack. . This plugin for Magnum uses the Kube's cluster API for deploying.
Bug#1038767: ITP: python-pykube-ng -- client library for Kubernetes
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: python-pykube-ng Version : 22.9.0 Upstream Contact: Eldarion, Inc. * URL : https://codeberg.org/hjacobs/pykube-ng * License : Apache-2.0 Programming Lang: Python Description : client library for Kubernetes Pykube (pykube-ng) is a lightweight Python client library for Kubernetes. It is a Platform as a Service (PaaS) that makes it easy to manage web application deployment and hosting through the entire lifecycle from development through testing to production. It adds components and tools on top of Kubernetes that help developers manage their application infrastructure. This is a dependency for: https://github.com/vexxhost/magnum-cluster-api that I also intend to package.
Bug#1034869: ITP: puppet-module-rally -- Puppet module for OpenStack Rally
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: puppet-module-rally Version : 10.0.0 Upstream Contact: OpenStack Foundation * URL : https://github.com/openstack/puppet-rally * License : Apache-2.0 Programming Lang: Puppet Description : Puppet module for OpenStack Rally Puppet lets you centrally manage every important aspect of your system using a cross-platform specification language that manages all the separate elements normally aggregated in different files, like users, cron jobs, and hosts, along with obviously discrete elements like packages, services, and files. . Rally is a Benchmark-as-a-Service project for OpenStack. . Rally is intended to provide the community with a benchmarking tool that is capable of performing specific, complicated and reproducible test cases on real deployment scenarios. . This module manages both the installation and configuration of OpenStack Rally.
Bug#1033934: ITP: puppet-module-voxpupuli-kmod -- Puppet module for manipulating modprobe and kernel modules
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: puppet-module-voxpupuli-kmod Version : 3.2.0 Upstream Author : Voxpupuli * URL : https://github.com/voxpupuli/puppet-kmod * License : Apache-2.0 Programming Lang: Puppet Description : Puppet module for manipulating modprobe and kernel modules Puppet lets you centrally manage every important aspect of your system using a cross-platform specification language that manages all the separate elements normally aggregated in different files, like users, cron jobs, and hosts, along with obviously discrete elements like packages, services, and files. . This module manages kernel module loading and options.
Bug#1032269: ITP: python-sphinx-code-include -- include source code from any Sphinx project using only its import path
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: python-sphinx-code-include Version : 1.1.1 Upstream Author : Colin Kennedy * URL : https://github.com/ColinKennedy/sphinx-code-include * License : BSD-2-clause Programming Lang: Python Description : include source code from any Sphinx project using only its import path Sphinx-code-include is an extension for Sphinx that lets you render source-code of any class or function directly into your Sphinx documentation using only as string.
Re: Bug#1032137: ITP: python-hardware -- hardware detection and classification utilities
On 3/1/23 17:20, Antoine Beaupré wrote: On 2023-02-28 15:18:33, Thomas Goirand wrote: * Package name: python-hardware Description : hardware detection and classification utilities Detect hardware features of a Linux systems: * RAID * hard drives * IPMI * network cards * DMI infos * memory settings * processor features . Filter hardware according to hardware profiles. Oh, this is interesting! There's very little documentation on the upstream site, what do you plan on using this for? It looks like a library I could very well use to rewrite stressant into something more sane... It seems it even has benchmarks... Thanks for any clarification! Hi, FYI, that's a dependency of ironic-python-agent [1], which does hardware discovery and image install for Ironic. I've just uploaded both packages and I intend to deploy my first Ironic-enabled cloud soonish. :) Cheers, Thomas Goirand (zigo) [1] https://opendev.org/openstack/ironic-python-agent
Bug#1032137: ITP: python-hardware -- hardware detection and classification utilities
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: python-hardware Version : 0.30.0 Upstream Author : Red Hat * URL : https://github.com/redhat-cip/hardware * License : Apache-2.0 Programming Lang: Python Description : hardware detection and classification utilities Detect hardware features of a Linux systems: * RAID * hard drives * IPMI * network cards * DMI infos * memory settings * processor features . Filter hardware according to hardware profiles.
Bug#1032135: ITP: ironic-python-agent -- bare metal hypervisor API for OpenStack - Python Agent
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: ironic-python-agent Version : 9.1.0 Upstream Author : OpenStack Discuss * URL : https://opendev.org/openstack/ironic-python-agent * License : Apache-2.0 Programming Lang: Python Description : bare metal hypervisor API for OpenStack - Python Agent Ironic provision bare metal machines instead of virtual machines. It is a fork of the Nova Baremetal driver. It is best thought of as a bare metal hypervisor API and a set of plugins which interact with the bare metal hypervisors. By default, it will use PXE and IPMI in concert to provision and turn on/off machines, but Ironic also supports vendor-specific plugins which may implement additional functionality. . This package provides the Python agent, to be deployed on the discovery image or ramdisk.
Re: MariaDB 10.11 in Bookworm - call for contributions
On 2/23/23 17:22, Otto Kekäläinen wrote: Hello! (Stop reading if you don't use MariaDB) I am currently preparing the upload of MariaDB 10.11.2-2 to Debian unstable and aim for the highest possible quality. I am currently doing the bulk of the testing and packaging alone and to make sure that the quality is top notch, I would be glad to see more people contribute. If you have time to help, please consider these (in order of importance): 1. Review current open MRs at https://salsa.debian.org/mariadb-team/mariadb-server/-/merge_requests 2. Review items highlighted by Debian QA systems (Lintian, builds etc) and submit a fix to improve the quality: https://tracker.debian.org/pkg/mariadb 3. Review what testing we have at https://salsa.debian.org/mariadb-team/mariadb-server/-/pipelines and think about potential gaps - CI is very important as it is the only way we can prevent regressions in a scalable way 4. Review/follow-up on existing bugs that currently need more information: https://bugs.debian.org/cgi-bin/pkgreport.cgi?repeatmerged=no&src=mariadb&src=mariadb-10.6&src=mariadb-10.5&src=mariadb-10.3&src=mariadb-10.1 MariaDB and C++ skills are useful, but not required. For example reviewing the NEWS for 10.11 requires no coding skills: https://salsa.debian.org/mariadb-team/mariadb-server/-/merge_requests/37 - Otto Another issue, My package depends on default-mysql-server, which doesn't pull mariadb-server 10.11, but 10.6. As a result, I can't install both... :/ Can this be fixed? Cheers, Thomas Goirand (zigo)
Re: packages.debian.org hasn't been updated for non-free-firmware
On 2/19/23 17:04, Cyril Brulebois wrote: Cyril Brulebois (2023-02-19): I tried to hotpatch it, but failed to so far. Second attempt seems better. Might take an extra dinstall (+ indexing in the following hours) to have all the things in place though. If people still see problems tomorrow, please follow up with details. Cheers, Hi Cyril, Thanks a lot for this! :) Thomas
Bug#1029545: ITP: ceilometer-instance-poller -- OpenStack ceilometer instance poller
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: ceilometer-instance-poller Version : 0.0.8 Upstream Author : Thomas Goirand * URL : https://salsa.debian.org/openstack-team/services/ceilometer-instance-poller/ * License : Apache-2.0 Programming Lang: Python Description : OpenStack ceilometer instance poller Ceilometer aims to deliver a Single Point Of Contact for billing systems, providing all the counters they need to establish customer billing, across all current and future OpenStack components. The delivery of counters must be traceable and auditable, the counters must be easily extensible to support new projects, and agents doing data collections should be independent of the overall system. . (A ceilometer is an instrument that measures cloud coverage.) . This package contains a libvirt and guestfs inspection script to poll what type of operating system is running in OpenStack VMs.
Re: SONAME bumps (transitions) always via experimental
On 1/5/23 12:28, Sebastiaan Couwenberg wrote: On 1/5/23 12:26, Paul Gevers wrote: Are there objections against this workflow? (Or voices from people who This has been a best practice for quite a while, high time to make it hard requirement. Kind Regards, Bas +1
Re: Boost 1.81 in Debian Testing
On 1/4/23 06:24, Anton Gladky wrote: apt install libboost-dev -t experimental FYI, Ceph FTBFS with it... :/ IMO, this was expected. Help fixing this would be greatly appreciated. Cheers, Thomas Goirand (zigo)
Re: Boost 1.81 in Debian Testing
On 1/4/23 06:24, Anton Gladky wrote: Dear valued contributors, I am pleased to announce that the latest version of Boost, version 1.81, is now available in Debian Testing [1]. We encourage all contributors whose packages depend on Boost libraries to consider building against Boost 1.81 in order to facilitate a smooth transition. Installing the -dev Boost packages from the experimental repository is simple, as shown in the following command: sudo apt install libboost-dev -t experimental. If you encounter any issues or have suggestions for improvement, please do not hesitate to file bugs or prepare merge requests on salsa [2]. Thank you. [1] https://tracker.debian.org/pkg/boost1.81 [2] https://salsa.debian.org/debian/boost Sincerely, Anton Hi, The latest update of boost was in late 2020. Why are we waiting so late in the release cycle to do such a transition? The month of the freeze is *NOT* a good moment to do it. Cheers, Thomas Goirand (zigo)
Bug#1026017: ITP: designate-tlds -- Designate TLDs population
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: designate-tlds Version : 0.0.1 Upstream Author : Axel Jacquet * URL : https://salsa.debian.org/openstack-team/services/designate-tlds * License : Apache-2.0 Programming Lang: Python Description : Designate TLDs population Designate provides DNSaaS services for OpenStack. It provides a multi-tenant REST API for domain & record management. It is Integrated with Keystone for authentication, and provides a framework in place to integrate with Nova and Neutron notifications (for auto-generated records). Designate supports PowerDNS and Bind9 out of the box. This package fill-up the Designate database with the global TLDs list downloaded from Mozilla.
Re: Q: How about versions/features in bookworm?
On 11/6/22 05:58, Hideki Yamane wrote: Q7: Will python3.11 be default in bookworm? What we discussed during Debconf is that we will *try* to make this happen, but if it doesn't go well, we will revert and ship Bookworm with 3.10 only. 3.11 is tempting, because it has nice features, and it goes a way faster than 3.10. However, to me, it's already too late for it: we need to check 3000+ packages over the next 2 months, and IMO, that's too risky. But that's only my opinion... Cheers, Thomas Goirand (zigo)
Bug#1022930: ITP: golang-github-iancoleman-strcase -- converting string case to various cases
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: golang-github-iancoleman-strcase Version : 0.2.0 Upstream Author : Ian Coleman * URL : https://github.com/iancoleman/strcase * License : Expat Programming Lang: Golang Description : converting string case to various cases Strcase is a go package for converting string case to various cases (like snake case, or camel case). Strcase can deal with common acronyms that it knows it shouldn't modify. Note: this is a dependency for mgmt-config that I'm packaging.
Bug#1022929: ITP: golang-github-coredhcp-coredhcp -- multithreaded, modular and extensible DHCP server
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: golang-github-coredhcp-coredhcp Version : 0.0.0+git.2022.04.07.a2552c5c1b Upstream Author : The CoreDHCP Authors * URL : https://github.com/coredhcp/coredhcp * License : Expat Programming Lang: Golang Description : multithreaded, modular and extensible DHCP server Coredhcp is a fast, multithreaded, modular and extensible DHCP server written in Go. In CoreDHCP almost everything is implemented as a plugin. Every request is evaluated calling each plugin in order, until one breaks the evaluation and responds to, or drops, the request. Note: this is a dependency of mgmt-config that I'm packaging.
Bug#1022928: ITP: golang-github-d-tux-go-fstab -- simple fstab parser
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: golang-github-d-tux-go-fstab Version : 0.0.0+git.2014.12.04.eb4090f265 Upstream Author : Denis Wernert * URL : https://github.com/d-tux/go-fstab * License : BSD-3-clause Programming Lang: Golang Description : simple fstab parser This Go package provides a /etc/fstab parser, and facitities to be able to mount and unmount. It supports UUID, labels, partuuid, parlabel, nfs, swap, and more. Note: This is a dependency for mgmt-config
Bug#1022915: ITP: golang-github-pin-tftp -- TFTP server and client library for Golang
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: golang-github-pin-tftp Version : 3.0.0 Upstream Author : Dmitri Popov * URL : https://github.com/pin/tftp * License : Expat Programming Lang: Golang Description : TFTP server and client library for Golang This package provides a TFTP server and client library for Golang. It implements: * RFC 1350 - The TFTP Protocol (Revision 2) * RFC 2347 - TFTP Option Extension * RFC 2348 - TFTP Blocksize Option . Partially implements (tsize server side only): * RFC 2349 - TFTP Timeout Interval and Transfer Size Options . Its set of features is sufficient for PXE boot support. Note: this is another dependency for mgmt-config that I'm packaging.
Bug#1022902: ITP: golang-github-libvirt-libvirt-go-xml -- API for manipulating libvirt XML documents
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: golang-github-libvirt-libvirt-go-xml Version : 7.4.0 Upstream Author : Lian Duan * URL : https://github.com/libvirt/libvirt-go-xml * License : Expat Programming Lang: Golang Description : API for manipulating libvirt XML documents This package provides a Go API that defines a set of structs, annotated for use with "encoding/xml", that can represent libvirt XML documents. There is no dependency on the libvirt library itself, so this can be used regardless of the way in which the application talks to libvirt. Note: This is a dependency of mgmt-config that I'm packaging.
Bug#1022880: ITP: golang-github-x-cray-logrus-prefixed-formatter -- text formatter based on logrus.TextFormatter
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: golang-github-x-cray-logrus-prefixed-formatter Version : 0.5.2 Upstream Author : Denis Parchenko * URL : https://github.com/x-cray/logrus-prefixed-formatter * License : Expat Programming Lang: Golang Description : text formatter based on logrus.TextFormatter Logrus formatter mainly based on original logrus.TextFormatter but with slightly modified colored output and support for log entry prefixes, e.g. message source followed by a colon. In addition, custom color themes are supported. Note: This is a dependency for mgmt-config.
Bug#1022877: ITP: golang-github-chappjc-logrus-prefix -- text formatter based on logrus.TextFormatter
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: golang-github-chappjc-logrus-prefix Version : 0.0.0+git.2018.02.26.3a1d64819a Upstream Author : Jonathan Chappelow * URL : https://github.com/chappjc/logrus-prefix * License : Expat Programming Lang: Golang Description : text formatter based on logrus.TextFormatter Logrus formatter mainly based on original logrus.TextFormatter but with slightly modified colored output and support for log entry prefixes, e.g. message source followed by a colon. In addition, custom color themes are supported. Note: This is a dependency of mgmt-config
Bug#1022872: ITP: golang-github-blynn-nex -- lexer similar to Lex/Flex
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: golang-github-blynn-nex Version : 0.0.0+git.2021.03.30.1a3320dab9 Upstream Author : Ben Lynn * URL : https://github.com/blynn/nex * License : GPL-3.0 Programming Lang: Golang Description : lexer similar to Lex/Flex Nex is a lexer similar to Lex/Flex that: * generates Go code instead of C code * integrates with Go's yacc instead of YACC/Bison * supports UTF-8 * supports nested structural regular expressions. Note: This is a dependency of mgmt-config which I intend to package.
