Bug#1081203: ITP: python-threadloop -- Tornado IOLoop Backed Concurrent Futures

[Thomas Goirand]

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

[Thomas Goirand]

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

[Thomas Goirand]

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

[Thomas Goirand]

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

[Thomas Goirand]

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

[Thomas Goirand]

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

[Thomas Goirand]

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

[Thomas Goirand]

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

[Thomas Goirand]

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.

Re: Validating tarballs against git repositories

[thomas]

On Aug 27, 2024 12:07 PM, Jeremy Stanley  wrote:

>

> On 2024-08-26 21:28:38 -0700 (-0700), Otto Kekäläinen wrote: 

> > On Tue, 2 Apr 2024 at 17:19, Jeremy Stanley wrote: 

> > > On 2024-04-02 16:44:54 -0700 (-0700), Russ Allbery wrote: 

> > > [...] 

> > > > I think a shallow clone of depth 1 is sufficient, although that's not 

> > > > sufficient to get the correct version number from Git in all cases. 

> > > [...] 

> > > 

> > > Some tools (python3-reno, for example) want to inspect the commits 

> > > and historical tags on branches, in order to do things like 

> > > assembling release notes documents. I don't know if any reno-using 

> > > projects packaged in Debian get release notes included, but if they 

> > > do then shallow clones would break that process. The python3-pbr 

> > 

> > You could use --depth=99 perhaps? 

> > 

> > Usually the difference of having depth=1 or 99 isn't that big unless 

> > there was a recent large refactoring. Git repositories that are very 

> > big (e.g. LibreOffice, MariaDB) have hundreds of thousands of commits, 

> > and by doing a depth=99 clone you avoid 99.995% of the history, and in 

> > projects where changelog/release notes is based on git commits, then 

> > 99 commits is probably enough. 

> [...] 

>

> Maybe, but only if you want authorship, release note or changelog 

> generation truncated at 99 commits worth of information at build 

> time. Take OpenStack Nova for example, which has historically 

> averaged around a thousand non-merge commits between major releases 

> every 6 months; --depth=99 would be an order of magnitude too low to 

> find just one major release's worth of notes and tags on a stable 

> branch. 

>

> Granted, this is why upstream in OpenStack we recommend package 

> maintainers use our source distribution changelogs rather than 

> rebuilding source themselves from code from version control. Our 

> community considers our version control to be an implementation 

> detail of our development workflow, not the primary means of 

> supplying source code to downstream consumers. Where version control 

> is concerned, we consider our source code to include the full Git 

> metadata and not merely the files held in the worktree. For a 

> hassle-free source distribution, we extract that metadata and 

> incorporate the relevant parts as files in our signed source 

> tarballs. 

> -- 

> Jeremy Stanley 


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.


Thomas Goirand (zigo)

Bug#1079692: ITP: python-sushy-oem-idrac -- Dell EMC iDRAC OEM extension package for the sushy library

[Thomas Goirand]

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

[Thomas Goirand]

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

[Thomas Goirand]

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

[Thomas Goirand]

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

[Thomas Goirand]

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

[Thomas Goirand]

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

[Thomas Goirand]

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

[Thomas Goirand]

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

[Thomas Goirand]

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

[Thomas Goirand]

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

[Thomas Goirand]

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

[Thomas Goirand]

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

[Thomas Goirand]

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

[Thomas Goirand]

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

[Thomas Goirand]

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

[Thomas Goirand]

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

[Thomas Goirand]

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

[Thomas Goirand]

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

[Thomas Goirand]

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

[Thomas Goirand]

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?

[thomas]

On Jul 16, 2024 4:55 PM, Lukas Märdian  wrote:

> Netplan is integrated with [cloud-init] "v2" network configuration and the 
> "cloud-config" 

> is adopted by many major public cloud providers (AWS, GCE, Azure, ...) as a 
> deployment 

> method, which makes it a well-known format. Similarly default configuration 
> for 

> [debian-cloud] is provided via Netplan. It is already supported in 
> [Calamares] for our 

> live-images and as of recently landed in [debian-installer] as well. 


It'd be very nice if it could also support a bgp-to-the-host setup natively as 
well. Maybe I can catch you in Busan to explain that use case?


Cheers,


Thomas Goirand (zigo)

Re: what about Netplan?

[thomas]

On Jul 15, 2024 10:48 PM, Luca Boccassi  wrote:

> and without being tied to 

> the internal decisions made in Canonical that we cannot do anything to 

> influence.


Could you please stop this FUD campaign ? We aren't talking about MIR or Unity, 
but about a small tool to generate some configuration. It is NOT the same, as 
we could fork such a small(er) tool. Plus we DO have some influence (look when 
we decided to switch to systemd, Canonical followed... because they wanted to 
follow, whatever our decision!).


Cheers,


Thomas Goirand (zigo)

Re: what about Netplan?

[Thomas Goirand]

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?

[Thomas Goirand]

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

[Thomas Goirand]

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

[Thomas Goirand]

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

[Thomas Goirand]

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

[Thomas Goirand]

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

[Thomas Goirand]

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

[Thomas Goirand]

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: About i386 support

[Thomas Hochstein]

Victor Gamper wrote:

> Is there a reason to do this? If so, what would be required to keep
> the i386 version, seeing as it still is important and used?

Re: Silent hijacking and stripping records from changelog

[Thomas Goirand]

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

[Thomas Goirand]

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

[Thomas Goirand]

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)

[Thomas Goirand]

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

[Thomas Goirand]

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

[Thomas Goirand]

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)

Re: xz backdoor

[thomas]

On Mar 31, 2024 2:37 PM, Pierre-Elliott Bécue  Wrote:

> The PGP submodule of a Yubikey can host 3 keys, one signing, one 

> authent, and one encrypt. ISTR accessing the signing key is always 

> prompting for the PIN. Same for the encryption key. (I think both can be 

> configured otherwise)


Only for the signing operation, one can turn on the "force-sig" option so that 
the key always prompt for a pin. And that is not the default.


Thomas

Re: [Summary]: Another take on package relationship substvars

[thomas]

Sent from Workspace ONE Boxer

On Mar 25, 2024 7:44 AM, Niels Thykier  wrote:

>

> Niels Thykier: 

> A follow up on this: 

>

>   * The proposal is now implemented in debhelper compat 14 (as of version 

> 13.15+) and debputy (0.1.21+). 

>

>   * The `debputy` migration tool will flag any obsolete substvars that 

> are 1:1 with what `debputy` would have applied for you. No tool for 

> debhelper-based packages exist at this time. 

>

>   * Lintian is not updated yet and will still complain about missing 

> relationship substvars. I have filed #1067653 to have that changed. 

>

> I expect this to be final on this topic for this round. :) 

>

> Best regards, 

> Niels 


Hi Niels,


Thanks a lot for your work on this, I very much agreed with the premiss that 
subst vars were a thing easy to fall into traps. It is a very welcomed 
improvement to automate them and avoid mistakes.


Is there a place where you wrote some kind of doc about how to use debputy or 
debhelper compat 14? Does one need to add debputy as build-depends, and that is 
it? Pointers to URLs welcome.


Cheers,


Thomas Goirand (zigo)

Bug#1067011: ITP: python-observabilityclient -- OpenStack Observability Client

[Thomas Goirand]

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?

[Thomas Goirand]

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?

[Thomas Goirand]

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

[Thomas Goirand]

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

[Thomas Goirand]

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

[Thomas Goirand]

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

[Thomas Goirand]

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

[Thomas Goirand]

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

[Thomas Goirand]

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

[Thomas Goirand]

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

[Thomas Goirand]

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)

[Thomas Goirand]

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

[Thomas Goirand]

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.

bring a newer version of a package into stable (nsis-3.09-1 into Debian "bookworm")

[Thomas Gaugler]

Hi,

I thought a package in Debian "bookworm" could be updated via a 
"bookworm proposed updates request" <https://bugs.debian.org/1050588>.


It looks like I did not fully understand the process. Therefore I kindly 
ask for assistance in updating the nsis-3.08-3 package in Debian 
"bookworm" to nsis-3.09-1.


The nsis-3.09-1 package is available in Debian "trixie" / testing and 
the maintenance of this package happens on 
<https://salsa.debian.org/debian/nsis>.


Thanks in advance,
Thomas

Bug#1058361: ITP: python-pyasyncore -- asyncore for Python 3.12 onwards

[Thomas Goirand]

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

[Thomas Goirand]

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

[Thomas Goirand]

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.

Clarification for broken packages in IPv6-only environments

[Thomas Braun]

(please CC me, as I'm not subscribed)

Hi,

I'm one of the upstream authors of cppTango [1] and that is a direct 
dependency of pytango [2].


Some time ago a bug report titled "pytango FTBFS on IPv6-only buildds" 
[3] was filed (tagged: serious) and the package maintainer "hacked" 
around the problem and could close the issue.


Now I would like to know if being able to run in an IPv6-only 
environment is a must have feature for any debian package?


I've found a long-standing release goal [4] and some prior discussion 
[5] but no definite answer.


The thing is from our users we have zero requests for this kind of setup 
so I'm having a hard time justifying the effort.


Thanks,
Thomas

[1]: https://packages.debian.org/trixie/libtango9-4
[2]: https://packages.debian.org/trixie/python3-tango
[3]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1014179
[4]: https://wiki.debian.org/ReleaseGoals/FullIPv6Support
[5]: https://lists.debian.org/debian-devel/2022/02/msg00061.html

Bug#1056044: ITP: python-jsonschema-specifications -- JSON Schema meta-schemas and vocabularies, exposed as a Registry

[Thomas Goirand]

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)

[Thomas Goirand]

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

[Thomas Goirand]

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?

[Thomas Goirand]

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

[Thomas Goirand]

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

[Thomas Goirand]

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

[Thomas Goirand]

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

[Thomas Goirand]

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

[Thomas Goirand]

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

[Thomas Goirand]

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

[Thomas Goirand]

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

[Thomas Goirand]

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.

Questionable Package Present in Debian: fortune-mod

[Thomas Ward]

Hello.

Debian Bug #1024501 [1]indicates that data files are present in the 
fortune-mod package which are against Debian policy:



Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?

As mentioned on Debian-project mailing list:
This is no longer appropriate for Debian. Fortunes-off binary package has
been removed: can we remove the data files, please.

These were questioned by upstream as early as 1997. They contain ethnic and
homophobic content and also Nazism quotes from Mein Kampf - none of these
would fit Debian Codes of Conduct today. A complaint has been raised.

It would seem sensible to remove these quotes and content immediately prior
to the release of Debian Bookworm


This is not yet removed if I read the changelog from Debian.There are 
additional components in the source code which quote these that suggest 
it may be prudent for a complete deletion. Downstream in Ubuntu, this 
package was removed due to violation of the Ubuntu Code of Conduct [2], 
and as the package in Ubuntu and the package in Debian are identical to 
each other, it may be prudent for the Debian community to remove the 
package in Unstable and Testing for similar reasons.  However, this was 
extended to the source package as the *source contents* contain the 
offensive wording, etc.



Can we put this package into the 'considered for removal' list or simply 
remove the package as violation of the Debian Code of Conduct from all 
releases?




Thomas



[1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1024501

[2]: https://bugs.launchpad.net/ubuntu/+source/fortune-mod/+bug/1996682

Bug#1049868: ITP: ceph-tools -- utilities to manage a Ceph cluster

[Thomas Goirand]

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

[Thomas Goirand]

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)

Bug#1039947: ITP: flooxs -- The Florida Object-Oriented Process/Device/Reliability/Superconductor Simulator (FLOOXS) is an open source TCAD tool

[Thomas Weingartner]

Package: wnpp
Severity: wishlist
Owner: Thomas Weingartner 
X-Debbugs-Cc: debian-devel@lists.debian.org, t.weingart...@ufl.edu

  Package name: flooxs
  Version : v2022
  Upstream Contact: Thomas Weingartner 
  URL : 
http://www.flooxs.ece.ufl.edu/index.php/Installation_from_Debian_package#Install_the_package
  License : Custom, license is included in package
  Programming Lang: Tcl/Tk, C/C++
  Description : The Florida Object-Oriented 
Process/Device/Reliability/Superconductor Simulator (FLOOXS) is an open source 
TCAD tool.

FLOOXS is a Technology Computer Aided Design (TCAD) tool used for semiconductor 
process modeling and semiconductor device modeling that will descretize and 
solve a set of partial and ordinary differential equations on a 1, 2 or 3D mesh 
using numerical methods such as the Finite Element Method (FEM) and the Finite 
Volume Method (FVM). FLOOXS is built in C++, and uses several well-known math 
packages such as BLAS, LAPACK, and SuiteSparse to handle the linear algebra. 
The user-interface is command-line tcl (tool control language), a scripting 
language, with additional FLOOXS-specific Alagator commands added in.

This package is one of a small number of tools that provide an open source TCAD 
platform.
This package is not a dependency for other packages and no other package
provides similar functionality to my knowledge. We are a small team of
developers, but maintaining this package should not be an issue since we
release infrequent updates and are not used as a dependency for any
other packages. Getting flooxs into the debian package system (and
ultimately ubuntu) will allow students ease of install for educational
purposes.

Re: Policy consensus on transition when removing initscripts.

[Thomas Goirand]

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.

[Thomas Goirand]

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

[Thomas Goirand]

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

[Thomas Goirand]

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

[Thomas Goirand]

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.

Re: Debian 9/stretch moved to archive.debian.org

[Thomas Kähn]

Bug#1033934: ITP: puppet-module-voxpupuli-kmod -- Puppet module for manipulating modprobe and kernel modules

[Thomas Goirand]

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

[Thomas Goirand]

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

[Thomas Goirand]

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

[Thomas Goirand]

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

[Thomas Goirand]

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

[Thomas Goirand]

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

[Thomas Goirand]

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

[Thomas Goirand]

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

[Thomas Goirand]

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

[Thomas Goirand]

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

[Thomas Goirand]

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)