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=mariadb=mariadb-10.6=mariadb-10.5=mariadb-10.3=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)

Bug#1026017: ITP: designate-tlds -- Designate TLDs population

[Thomas Goirand]

Package: wnpp
Severity: wishlist
Owner: Thomas Goirand 
X-Debbugs-Cc: debian-devel@lists.debian.org

* Package name: designate-tlds
  Version : 0.0.1
  Upstream Author : Axel Jacquet 
* URL : 
https://salsa.debian.org/openstack-team/services/designate-tlds
* License : Apache-2.0
  Programming Lang: Python
  Description : Designate TLDs population

Designate provides DNSaaS services for OpenStack. It provides a multi-tenant
REST API for domain & record management. It is Integrated with Keystone for
authentication, and provides a framework in place to integrate with Nova and
Neutron notifications (for auto-generated records). Designate supports
PowerDNS and Bind9 out of the box.

This package fill-up the Designate database with the global TLDs list
downloaded from Mozilla.

Re: libpaper and gnulib

[Reuben Thomas]

On Mon, 21 Nov 2022 at 21:30, Helmut Grohne  wrote:


> It is known to build and run on some architectures.


Excellent point! I already mitigate this risk by building most of my
(upstream) packages on macOS and Windows as well as GNU/Linux, but still.

And if you decide to vendor gnulib anyway, don't forget to register
> yourself with the security tracker!
>

Excellent suggestion, thanks.

-- 
https://rrt.sc3d.org

Re: libpaper and gnulib

[Reuben Thomas]

On Wed, 16 Nov 2022 at 09:47, Helmut Grohne  wrote:

>
> I think bug fixes is something you'd want. API changes less so.
>

My point was that there are frequently bug fixes and API changes since
whatever version of gnulib is packaged in Debian.


> Also note that gnulib is a piece that regularly faces portability issues
> (as it tries to provide portability). As such, it is particularly
> annoying for porters to not only have to fix gnulib, but then also have
> to get it updated in tons of downstreams.


How is this a problem for Debian packagers? Once software is packaged for
Debian, it's already known to build and run.

I stopped counting the number
> of bug reports "... ships a broken, outdated, embedded copy of gnulib"
> that I've sent. As a porter, I very much wish people wouldn't embed
> gnulib.
>

I agree, gnulib as a whole shouldn't be embedded. I also agree that
software that uses gnulib, even small parts of it (like libpaper) will have
to update from time to time to fix bugs and portability problems.

-- 
https://rrt.sc3d.org

Re: libpaper and gnulib

[Reuben Thomas]

Thanks very much to all those who have given advice, offered help, and
spelt out some of the background of gnulib use in Debian.

The summary seems to be that using gnulib in its usual way to embed files
used by APIs a package uses is acceptable.

-- 
https://rrt.sc3d.org

libpaper and gnulib

[Reuben Thomas]

I am the upstream maintainer of libpaper (which used to be a pure-Debian
project), and also a Debian Maintainer trying to get a new version of
libpaper into Debian. (It involves an API/ABI transition, from the current
libpaper1 to libpaper2.)

Bastian Germann (b...@debian.org) is kindly helping with the packaging and
sponsoring my upload.

I just got a rejection for libpaper_2.0.3-1 from ftp-master (in this case,
Thorsten Alteholz), who said "I didn't find any explanation why you
embedded a copy of gnulib in your source tarball. Do you really need that?"

Like many GNU packages, my rewrite of libpaper uses gnulib, a source
library that's effectively a polyfill for POSIX & GNU APIs, and my libpaper
releases distribute some gnulib source files as part of the release
tarball. Other Debian packages that work this way include coreutils and
grep.

Some other Debian packages build-depend on Debian's gnulib package. This
won't necessarily work for libpaper, because gnulib is not versioned:
libpaper depends on a specific commit of gnulib, and there are often bug
fixes or API changes.

Bastian asked me to build-depend on gnulib, which I have so far declined to
do, as that would make the Debian package's sources effectively different
from those that I release as upstream maintainer.

Also, a build-depend on gnulib would not directly address Thorsten's
problem with the package, as the source archive would still contain gnulib
sources (although maybe it would be OK if they weren't used?). I had a look
at a package that does build-depend on gnulib, wget2, and its source
tarball contains gnulib files.

I have searched the debian-devel archives and found a few reference s to
gnulib, but no definitive ruling about how gnulib should be treated.
Bastian rightly points out that by including gnulib sources, packages such
as coreutils cannot easily be updated for security bugs in gnulib; but to
me this seems to be a problem with gnulib itself (it's a source library,
that's how it works), rather than with the packaging of programs that use
gnulib.

Another of Bastian's suggestions is that I base the Debian package on a git
snapshot, as that does not include gnulib files; but this still has the
problem that the Debian package would not be built from a release of
libpaper.

I am a bit torn here: with my DM hat on, stripping out gnulib sources where
possible and using Debian's gnulib package seems the right thing to do.
With my upstream hat on it leads potentially to bug reports that don't
correspond to an upstream release; and further few Debian packages that use
gnulib actually seem to use this method (there are 26 build-rdeps of
gnulib).

Help? (With many thanks to the several DDs that have already helped on the
nearly 10-year journey to get libpaper updated!)

-- 
https://rrt.sc3d.org

Re: Q: How about versions/features in bookworm?

[Thomas Goirand]

On 11/6/22 05:58, Hideki Yamane wrote:

  Q7:  Will python3.11 be default in bookworm?


What we discussed during Debconf is that we will *try* to make this 
happen, but if it doesn't go well, we will revert and ship Bookworm with 
3.10 only.


3.11 is tempting, because it has nice features, and it goes a way faster 
than 3.10.


However, to me, it's already too late for it: we need to check 3000+ 
packages over the next 2 months, and IMO, that's too risky. But that's 
only my opinion...


Cheers,

Thomas Goirand (zigo)

Bug#1022930: ITP: golang-github-iancoleman-strcase -- converting string case to various cases

[Thomas Goirand]

Package: wnpp
Severity: wishlist
Owner: Thomas Goirand 
X-Debbugs-Cc: debian-devel@lists.debian.org

* Package name: golang-github-iancoleman-strcase
  Version : 0.2.0
  Upstream Author : Ian Coleman 
* URL : https://github.com/iancoleman/strcase
* License : Expat
  Programming Lang: Golang
  Description : converting string case to various cases

 Strcase is a go package for converting string case to various cases (like
 snake case, or camel case). Strcase can deal with common acronyms that it
 knows it shouldn't modify.

Note: this is a dependency for mgmt-config that I'm packaging.

Bug#1022929: ITP: golang-github-coredhcp-coredhcp -- multithreaded, modular and extensible DHCP server

[Thomas Goirand]

Package: wnpp
Severity: wishlist
Owner: Thomas Goirand 
X-Debbugs-Cc: debian-devel@lists.debian.org

* Package name: golang-github-coredhcp-coredhcp
  Version : 0.0.0+git.2022.04.07.a2552c5c1b
  Upstream Author : The CoreDHCP Authors
* URL : https://github.com/coredhcp/coredhcp
* License : Expat
  Programming Lang: Golang
  Description : multithreaded, modular and extensible DHCP server

 Coredhcp is a fast, multithreaded, modular and extensible DHCP server written
 in Go. In CoreDHCP almost everything is implemented as a plugin. Every request
 is evaluated calling each plugin in order, until one breaks the evaluation and
 responds to, or drops, the request.

Note: this is a dependency of mgmt-config that I'm packaging.

Bug#1022928: ITP: golang-github-d-tux-go-fstab -- simple fstab parser

[Thomas Goirand]

Package: wnpp
Severity: wishlist
Owner: Thomas Goirand 
X-Debbugs-Cc: debian-devel@lists.debian.org

* Package name: golang-github-d-tux-go-fstab
  Version : 0.0.0+git.2014.12.04.eb4090f265
  Upstream Author : Denis Wernert 
* URL : https://github.com/d-tux/go-fstab
* License : BSD-3-clause
  Programming Lang: Golang
  Description : simple fstab parser

 This Go package provides a /etc/fstab parser, and facitities to be able to
 mount and unmount. It supports UUID, labels, partuuid, parlabel, nfs, swap,
 and more.

Note: This is a dependency for mgmt-config

Bug#1022915: ITP: golang-github-pin-tftp -- TFTP server and client library for Golang

[Thomas Goirand]

Package: wnpp
Severity: wishlist
Owner: Thomas Goirand 
X-Debbugs-Cc: debian-devel@lists.debian.org

* Package name: golang-github-pin-tftp
  Version : 3.0.0
  Upstream Author : Dmitri Popov 
* URL : https://github.com/pin/tftp
* License : Expat
  Programming Lang: Golang
  Description : TFTP server and client library for Golang

 This package provides a TFTP server and client library for Golang. It
 implements:
  * RFC 1350 - The TFTP Protocol (Revision 2)
  * RFC 2347 - TFTP Option Extension
  * RFC 2348 - TFTP Blocksize Option
 .
 Partially implements (tsize server side only):
  * RFC 2349 - TFTP Timeout Interval and Transfer Size Options
 .
 Its set of features is sufficient for PXE boot support.

Note: this is another dependency for mgmt-config that I'm packaging.

Bug#1022902: ITP: golang-github-libvirt-libvirt-go-xml -- API for manipulating libvirt XML documents

[Thomas Goirand]

Package: wnpp
Severity: wishlist
Owner: Thomas Goirand 
X-Debbugs-Cc: debian-devel@lists.debian.org

* Package name: golang-github-libvirt-libvirt-go-xml
  Version : 7.4.0
  Upstream Author : Lian Duan 
* URL : https://github.com/libvirt/libvirt-go-xml
* License : Expat
  Programming Lang: Golang
  Description : API for manipulating libvirt XML documents

 This package provides a Go API that defines a set of structs, annotated for
 use with "encoding/xml", that can represent libvirt XML documents. There is no
 dependency on the libvirt library itself, so this can be used regardless of
 the way in which the application talks to libvirt.

Note: This is a dependency of mgmt-config that I'm packaging.

Bug#1022880: ITP: golang-github-x-cray-logrus-prefixed-formatter -- text formatter based on logrus.TextFormatter

[Thomas Goirand]

Package: wnpp
Severity: wishlist
Owner: Thomas Goirand 
X-Debbugs-Cc: debian-devel@lists.debian.org

* Package name: golang-github-x-cray-logrus-prefixed-formatter
  Version : 0.5.2
  Upstream Author : Denis Parchenko 
* URL : https://github.com/x-cray/logrus-prefixed-formatter
* License : Expat
  Programming Lang: Golang
  Description : text formatter based on logrus.TextFormatter

 Logrus formatter mainly based on original logrus.TextFormatter but with
 slightly modified colored output and support for log entry prefixes, e.g.
 message source followed by a colon. In addition, custom color themes are
 supported.

Note: This is a dependency for mgmt-config.

Bug#1022877: ITP: golang-github-chappjc-logrus-prefix -- text formatter based on logrus.TextFormatter

[Thomas Goirand]

Package: wnpp
Severity: wishlist
Owner: Thomas Goirand 
X-Debbugs-Cc: debian-devel@lists.debian.org

* Package name: golang-github-chappjc-logrus-prefix
  Version : 0.0.0+git.2018.02.26.3a1d64819a
  Upstream Author : Jonathan Chappelow 
* URL : https://github.com/chappjc/logrus-prefix
* License : Expat
  Programming Lang: Golang
  Description : text formatter based on logrus.TextFormatter

 Logrus formatter mainly based on original logrus.TextFormatter but with
 slightly modified colored output and support for log entry prefixes, e.g.
 message source followed by a colon. In addition, custom color themes are
 supported.

Note: This is a dependency of mgmt-config

Bug#1022872: ITP: golang-github-blynn-nex -- lexer similar to Lex/Flex

[Thomas Goirand]

Package: wnpp
Severity: wishlist
Owner: Thomas Goirand 
X-Debbugs-Cc: debian-devel@lists.debian.org

* Package name: golang-github-blynn-nex
  Version : 0.0.0+git.2021.03.30.1a3320dab9
  Upstream Author : Ben Lynn 
* URL : https://github.com/blynn/nex
* License : GPL-3.0
  Programming Lang: Golang
  Description : lexer similar to Lex/Flex

 Nex is a lexer similar to Lex/Flex that:
  * generates Go code instead of C code
  * integrates with Go's yacc instead of YACC/Bison
  * supports UTF-8
  * supports nested structural regular expressions.

Note: This is a dependency of mgmt-config which I intend to package.

Bug#1022853: ITP: golang-github-felixge-httpsnoop -- capture http related metrics from http.Handlers

[Thomas Goirand]

Package: wnpp
Severity: wishlist
Owner: Thomas Goirand 
X-Debbugs-Cc: debian-devel@lists.debian.org

* Package name: golang-github-felixge-httpsnoop
  Version : 1.0.3
  Upstream Author : Felix Geisendörfer 
* URL : https://github.com/felixge/httpsnoop
* License : Expat
  Programming Lang: Golang
  Description : capture http related metrics from http.Handlers

 Httpsnoop provides an easy way to capture http related metrics (i.e. response
 time, bytes written, and http status code) from your application's
 http.Handlers.
 .
 Doing this requires non-trivial wrapping of the http.ResponseWriter interface,
 which is also exposed for users interested in a more low-level API.

Note: This is another indirect dependency of Etcd 3.5.5

Bug#1022852: ITP: golang-github-aws-smithy-go -- Smithy code generators for Go

[Thomas Goirand]

Package: wnpp
Severity: wishlist
Owner: Thomas Goirand 
X-Debbugs-Cc: debian-devel@lists.debian.org

* Package name: golang-github-aws-smithy-go
  Version : 1.13.3
  Upstream Author : 2020-2022, Amazon.com, Inc. or its affiliates.
* URL : https://github.com/aws/smithy-go
* License : Apache-2.0, BSD-3-clause
  Programming Lang: Golang
  Description : Smithy code generators for Go

 Smithy code generators for Go

Note: This is another new dependency for Etcd 3.5.5.

Bug#1022845: ITP: super-speedy-syslog-searcher -- Speedily search and merge log file entries by datetime

[James Thomas Moon]

Package: wnpp
Severity: wishlist
Owner: James Thomas Moon 

* Package name: super-speedy-syslog-searcher
  Version : 0.1.39
  Upstream Author : James Thomas Moon 

* URL : https://crates.io/crates/super-speedy-syslog-searcher
* License : MIT
  Programming Lang: Rust
  Description : Speedily search and merge log file entries by datetime

Super Speedy Syslog Searcher (s4) is a command-line tool to search and merge 
plain log files by datetime, including log compressed log files (.gz, .xz) and 
within archives (.tar). The first goal of s4 is speedy searching and printing.

Why is this package relevant? Simple and fast tool for reviewing large amounts 
of log files, in a datetime-oriented manner. A common activity for Power Users 
and Engineers.

Is this a dependency for another package? No

Do you use it? Yes, on all my local Linux and Windows machines.

Do other packages provide functionality? No.

How do you plan to maintain it? At minimum, ongoing watchful eye of Rust 
dependency changes. I setup a github dependabot alerts for needed fixes.
    I have created several Enhancement Issues at the project page. If this tool 
proves useful to anyone, then I may implement some Enhancements.
    However, I am new to packaging Debian packages. Not sure if I'll need an 
assist from an expert.

Are you looking for co-maintainer? No. I imagine once I get the hang of package 
maintanence, I'll be able to handle it on my own.

Bug#1022834: ITP: golang-opentelemetry-contrib -- Collection of 3rd-party packages for OpenTelemetry-Go

[Thomas Goirand]

Package: wnpp
Severity: wishlist
Owner: Thomas Goirand 
X-Debbugs-Cc: debian-devel@lists.debian.org

* Package name: golang-opentelemetry-contrib
  Version : 0.25.0
  Upstream Author : The OpenTelemetry Authors
* URL : https://github.com/open-telemetry/opentelemetry-go-contrib/
* License : Apache-2.0
  Programming Lang: Go
  Description : Collection of 3rd-party packages for OpenTelemetry-Go

 OpenTelemetry-Go Contrib is a collection of extensions for the
 opentelemetry project. It provides 3rd parth resource detectors,
 propagators, samplers, and instrumentation as submodules.
 .
 OpenTelemetry-Go Contrib contains common values used across all
 instrumentation, exporter, and detector contributions.

Note: this is yet another intdirect dependency of etcd 3.5.5

Bug#1022829: ITP: golang-opentelemetry-proto -- OpenTelemetry Go API and SDK - proto

[Thomas Goirand]

Package: wnpp
Severity: wishlist
Owner: Thomas Goirand 
X-Debbugs-Cc: debian-devel@lists.debian.org

* Package name: golang-opentelemetry-proto
  Version : 0.19.0
  Upstream Author : The OpenTelemetry Authors
* URL : https://github.com/open-telemetry/opentelemetry-proto-go
* License : Apache-2.0
  Programming Lang: Go
  Description : OpenTelemetry Go API and SDK - proto

 OpenTelemetry-Go is the Go implementation of OpenTelemetry. It provides a set
 of APIs to directly measure performance and behavior of your software and send
 this data to observability platforms.
 .
 This package contains the proto module.

Note: This is an indirect new dependency for Etcd 3.5.5 that I would like to
upload for Bookworm.

Bug#1022819: ITP: golang-github-go-logr-stdr -- implements the logr interface from the golang-github-go-logr-logr

[Thomas Goirand]

Package: wnpp
Severity: wishlist
Owner: Thomas Goirand 
X-Debbugs-Cc: debian-devel@lists.debian.org

* Package name: golang-github-go-logr-stdr
  Version : 1.2.2
  Upstream Author : The logr Authors
* URL : https://github.com/go-logr/stdr
* License : Apache-2.0
  Programming Lang: Go
  Description : implements the logr interface from the 
golang-github-go-logr-logr

 This package implements the logr interface from the golang-github-go-logr-logr
 package (see also https://github.com/go-logr/logr), in terms of Go's standard
 log package.

Note: this is a new dependency for Etcd 3.5.5

Bug#1022807: ITP: golang-github-etcd-io-gofail -- implementation of failpoint

[Thomas Goirand]

Package: wnpp
Severity: wishlist
Owner: Thomas Goirand 
X-Debbugs-Cc: debian-devel@lists.debian.org

* Package name: golang-github-etcd-io-gofail
  Version : 0.0.0+git.2022.09.25.d0d2a96a6e
  Upstream Author : CoreOS INC
* URL : https://github.com/etcd-io/gofail
* License : Apache-2.0
  Programming Lang: Go
  Description : implementation of failpoint

 This package provides an implementation of failpoint for golang. Failpoints
 are special comments that include a failpoint variable declaration and some
 trigger code.

Note: This is a new dependency for Etcd which I'm trying to upgrade to 3.5.5
for Bookworm.

Bug#1022805: ITP: golang-github-cockroachdb-datadriven -- extension of Table-Driven Testing

[Thomas Goirand]

Package: wnpp
Severity: wishlist
Owner: Thomas Goirand 
X-Debbugs-Cc: debian-devel@lists.debian.org

* Package name: golang-github-cockroachdb-datadriven
  Version : 1.0.2
  Upstream Author : The Cockroach Authors
* URL : https://github.com/cockroachdb/datadriven
* License : Apache-2.0
  Programming Lang: Go
  Description : extension of Table-Driven Testing

 This package provides an implementation of an extension of Table-Driven
 Testing. Instead of building and iterating over a table in the test code, the
 input is further separated into files (or inline strings). For certain classes
 of tests, this can significantly reduce the friction involved in writing and
 reading these tests.

Note: This is a new dependency of etcd, which I'm trying to upgrade to 3.5.5.

Bug#1021572: RFP: la-capitaine-icon-theme -- icon theme inspired by macOS and Google's material design

[Thomas Uhle]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: Debian Developers 

* Package name: la-capitaine-icon-theme
  Version : 0.6.2
  Upstream Author : Keefer Rourke
* URL or Web page : https://krourke.org/projects/art/la-capitaine-icon-theme/
* License : GPL-3+, MIT
  Description : icon theme inspired by macOS and Google's material design

La Capitaine is basically an icon theme for the modern Linux desktop, 
designed to integrate with most desktop environments. It is inspired by 
macOS and Google's material design through the use of visually pleasing 
gradients, shadowing, and simple icon geometry.

Re: Firmware GR result - what happens next?

[Thomas Goirand]

On 10/3/22 02:23, Charles Plessy wrote:

Le Mon, Oct 03, 2022 at 12:33:20AM +0200, Mattia Rizzolo a écrit :


I can live with an APT hook warning me if I have non-free but not
non-free-firmware, but I would prefer to even do without that.


In addition, how about distributing the firmware in both 'non-free' and
'non-free-firmware' at the same time for a release or two ?


How about being smarter than this? :)

Cheers,

Thomas Goirand (zigo)

Bug#1021188: ITP: ovn-bgp-agent -- OpenStack virtual network service - OVN BGP agent

[Thomas Goirand]

Package: wnpp
Severity: wishlist
Owner: Thomas Goirand 
X-Debbugs-Cc: debian-devel@lists.debian.org

* Package name: ovn-bgp-agent
  Version : 0.2.0
  Upstream Author : OpenStack Foundation 
* URL : https://opendev.org/x/ovn-bgp-agent
* License : Apache-2.0
  Programming Lang: Python
  Description : OpenStack virtual network service - OVN BGP agent

 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 OVN BGP agent.

Re: Firmware GR result - what happens next?

[Thomas Goirand]

Hi Steve,

On 10/2/22 21:26, Steve Langasek wrote:

I heartily endorse ubuntu-release-upgrader, it has been useful in addressing
uncounted upgrade issues over the years and I think something like this
would be a nice addition to Debian as well.  Two caveats:

  - Despite this being the sanctioned upgrade path in Ubuntu for over a
decade, every single cycle we get bug reports from users who have run
into issues because they have bypassed it and done the manual sed
/etc/apt/sources.list && apt dist-upgrade.  So in Debian where this has
been the norm for /two/ decades, I would not expect this to substantially
reduce the error rate in the first release where such a mechanism is
introduced.  (After all, whether telling users to use a new upgrader tool
or telling them to manually add a component to sources.list, they will
have to read the release notes to know about it!)

  - There are always some users that end up with buggy systems after upgrade
despite using the supported interface because they upgrade to the devel
release, and the release-upgrader is still under development up until
release so they miss out on quirks being applied - and there is no
interface for users to replay the quirks that they missed out on.  Don't
repeat the same design mistake.


I very much dislike the Ubuntu approach, but not only because of the 
above. Also because this approach forgets the fact that we also maintain 
2 rolling-updates distro (testing and unstable).



In the absence of a release-upgrader, the only way I see to automate this on
upgrade would be to handle it in the maintainer scripts of either base-files
(which I don't think the base-files maintainer would like) or apt.


If the base-files maintainer (ie: Santiago Vila) doesn't like doing 
things like this in "his" package, maybe we could have base-file >> 12.2 
depend on another package (called non-free-upgrade?) that would do the 
work instead. We could even have only base-file to depend on that 
package for a single release (ie: only for the lifetime of bookworm, and 
we get rid of the package after the release).


I think that's an even better approach than having this done in 
base-files itself.


Your thoughts?

Cheers,

Thomas Goirand (zigo)

Re: Firmware GR result - what happens next?

[Thomas Goirand]

On 10/2/22 22:02, Russ Allbery wrote:

Michael Biebl  writes:


The main difference is, that the renaming caused an error message by
apt, so you knew something needed to be fixed.


One could argue that having non-free but not non-free-firmware is
sufficiently strange that it would be worth a suppressable apt warning
(that you could turn off in apt.conf).  I have no idea how easy that would
be to implement, though.


Hi!

I would very much prefer having this implemented in the base_files 
package. This is *the* package that follows releases, so that's IMO the 
best location.


I would hate having to use an upgrade program like in Ubuntu. :/

An easy check could be:
1/ are we upgrading from base-files << 12.3 (we're currently at 12.2 in Sid)
AND
2/ is there the non-free repo installed in the default sources.list
AND
3/ non-free-firmware repo isn't installed

THEN

warn user with debconf.

Checking the configuration of a non-free and non-free-firmware is kind 
of hard, because just reading/parsing source.list and source.list.d that 
could be filled with non-debian repos can be quite hard. Though we could 
imagine tricks, like where both repo would include a special package 
present only for that test, and we just see if it is available with 
apt-cache policy for example (this is just an idea... not sure if 
there's better options).


Eventually, and propose automatically adding the n-f-f repo, if some of 
you really want to, but I'd prefer if at least this could be the 
non-default debconf answer (because on non-interactive setup, without 
access to internet (only to a local mirror), this could really mess 
things up).


Your thoughts everyone?
Cheers,

Thomas Goirand (zigo)

P.S: I'm unfortunately *not* volunteering for implementing the above as 
I wont have enough time to do it properly, though I just hope my above 
suggestion helps...

Bug#1019730: ITP: python-ephemeral-port-reserve -- binds to an ephemeral port, force it into the TIME_WAIT state, and unbind it

[Thomas Goirand]

Package: wnpp
Severity: wishlist
Owner: Thomas Goirand 
X-Debbugs-Cc: debian-devel@lists.debian.org

* Package name: python-ephemeral-port-reserve
  Version : 1.1.4
  Upstream Author : Yelp
* URL : https://github.com/Yelp/ephemeral-port-reserve/
* License : Expat
  Programming Lang: Python
  Description : binds to an ephemeral port, force it into the TIME_WAIT 
state, and unbind it

 Sometimes you need a networked program to bind to a port that can't be 
hard-coded.
 Generally this is when you want to run several of them in parallel; if they all
 bind to port 8080, only one of them can succeed.
 .
 The usual solution is the "port 0 trick". If you bind to port 0, your kernel 
will
 find some arbitrary high-numbered port that's unused and bind to that. 
Afterward
 you can query the actual port that was bound to if you need to use the port 
number
 elsewhere. However, there are cases where the port 0 trick won't work. For 
example,
 mysqld takes port 0 to mean "the port configured in my.cnf". Docker can bind 
your
 containers to port 0, but uses its own implementation to find a free port which
 races and fails in the face of parallelism.
 .
 ephemeral-port-reserve helps you using port 0.

Note: this is a new build-depends for python-werkzeug, needed to run tests.

Bug#1019316: ITP: vector -- high-performance data pipeline for collecting all your logs and metrics

[Thomas Goirand]

Package: wnpp
Severity: wishlist
Owner: Thomas Goirand 
X-Debbugs-Cc: debian-devel@lists.debian.org

* Package name: vector
  Version : 0.24.0
  Upstream Author : Datadog, Inc.
* URL : https://vector.dev/
* License : MPL-2.0
  Programming Lang: Rust
  Description : high-performance data pipeline for collecting all your logs 
and metrics

 Vector is a high-performance, end-to-end (agent & aggregator) observability
 data pipeline that puts you in control of your observability data. It can
 collect, transform, and route all your logs, metrics, and traces to any
 vendors you want today and any other vendors you may want tomorrow. Vector
 enables dramatic cost reduction, novel data enrichment, and data security
 where you need it, not where it is most convenient for your vendors.
 Additionally, it is 10x faster than every alternative in the space.

Re: Unsolicited GNU bc patch

[Thomas DiModica]

Philip, thank you,

I'm sorry: I have sent this to upstream, but haven't heard anything from them.
At least with a mailing list, I get feedback as to whether or not my mail was
eaten by the void of the Internet. Also, if it gets into Debian, then the
patches filter through to everything based on Debian.

Philip, your change to the patch looks right. Sorry, I based the patch off
upstream. You do say it needs a better description, so I'm going to try to
give you a sense of what's going on.

What I think is happening is that, somewhere in the parser, "that an error
occurred" is getting suppressed, and the parser continues to generate bytecode
with the previous instruction incomplete, and then it tries to execute that.
Sometimes, the bytecode reads an instruction while trying to read a reference.
This appears to be most catastrophic in array handling. While what ought to be
fixed is the code generation to not generate these erroneous references, it is
easier to fix the bytecode interpreter to defend itself from them.

To begin, starting in execute.c: for change one, it has read a label number,
but then walks off the list looking for it. In change two, sometimes the
function number is invalid. And change three protects from the string not
being terminated. Looking at this again, if I had just added an 'else' to
"if (ch != '\\')" then I could have made a less invasive change. Also: if you
want to give any of these error messages better text, or if I've broken the
internationalization with them, please change them to suite your preferences.
What I gave you is better than the "DANGER, WILL ROBINSON!" that I had before.

In storage.c, initializing 'v_next' is one of the things I consider a bug.
Sometimes, it has a "valid" pointer in it. The next six changes are defensive
error checks to ensure that the array being requested is plausible. The line
"params++;" looks like a hold-over from an earlier version of the code, where
the parameters were stored in an array. With the linked-list, the proper way
to advance to the next parameter is "params = params->next;", which always
occurs a few lines later.

That leaves util.c. I think they were trying to save memory, at some point.
Possibly: variable names are treated differently from array and function
names, and I don't see the reason for that. What happens is that the value
from lookup() is used to initialize av_name in nextarg(). Then, av_name is
directly used to index v_names right above that removed "params++;" line. In
this retrospective dive through the code, that may be it. The line in
storage.c could be changed, I think, but, in my opinion, it is better to move
the code so that it more consistently handles all types. In addition, while
the line "if (id->v_name <= MAX_STORE)" is annoying in that it is different,
it isn't guarding against an invalid access.

Thank you again,
Thomas DiModica

Unsolicited GNU bc patch

[Thomas DiModica]

Greetings,

Yes, I keep spamming this trying to find an appropriate mailing list. I don't
remember how or why I initially stumbled across this bug report
(https://bugs.launchpad.net/ubuntu/+source/bc/+bug/1775776), but, given that
I have some familiarity with GNU bc, I decided to fix some of the issues.
Turns out, this also seems to fix the crashes reported here
(https://www.openwall.com/lists/oss-security/2018/11/28/1). I think it would
be a lot more useful to share this, as there isn't a lot to review. There are
three bug fixes and some self-defensive checks in the runtime for malformed
bytecode. Address Sanitizer tells me that these previously invalid memory
references now just leak memory. I don't appear to have broken anything in the
process, either. I'm not a member of any Debian mailing list, but I will try
to watch for responses.

Just trying to be somewhat helpful,
Thomas DiModica
From 3ecfe21c965956f3913e9bc340df729234e4453b Mon Sep 17 00:00:00 2001
From: Thomas DiModica 
Date: Tue, 19 Jul 2022 19:28:12 -0600
Subject: [PATCH] Resolving the crashes found through fuzz testing by
 HongxuChen.

---
 bc/execute.c | 54 +---
 bc/storage.c | 38 ++--
 bc/util.c|  2 +-
 3 files changed, 71 insertions(+), 23 deletions(-)

diff --git a/bc/execute.c b/bc/execute.c
index 256e4b7..d30c6f5 100644
--- a/bc/execute.c
+++ b/bc/execute.c
@@ -130,7 +130,7 @@ execute (void)
  gp = functions[pc.pc_func].f_label;
  l_gp  = label_num >> BC_LABEL_LOG;
  l_off = label_num % BC_LABEL_GROUP;
- while (l_gp-- > 0) gp = gp->l_next;
+ while ((l_gp-- > 0) && (gp != NULL)) gp = gp->l_next;
   if (gp)
 pc.pc_addr = gp->l_adrs[l_off];
   else {
@@ -146,6 +146,13 @@ execute (void)
if ((new_func & 0x80) != 0) 
  new_func = ((new_func & 0x7f) << 8) + byte();
 
+   /* Check to make sure it is valid. */
+   if (new_func >= f_count)
+ {
+   rt_error ("Internal error.");
+   break;
+ }
+
/* Check to make sure it is defined. */
if (!functions[new_func].f_defined)
  {
@@ -204,25 +211,32 @@ execute (void)
 
   case 'O' : /* Write a string to the output with processing. */
while ((ch = byte()) != '"')
- if (ch != '\\')
-   out_schar (ch);
- else
-   {
- ch = byte();
- if (ch == '"') break;
- switch (ch)
-   {
-   case 'a':  out_schar (007); break;
-   case 'b':  out_schar ('\b'); break;
-   case 'f':  out_schar ('\f'); break;
-   case 'n':  out_schar ('\n'); break;
-   case 'q':  out_schar ('"'); break;
-   case 'r':  out_schar ('\r'); break;
-   case 't':  out_schar ('\t'); break;
-   case '\\': out_schar ('\\'); break;
-   default:  break;
-   }
-   }
+ {
+   if (pc.pc_addr == functions[pc.pc_func].f_code_size)
+ {
+   rt_error ("Broken String.");
+   break;
+ }
+   if (ch != '\\')
+ out_schar (ch);
+   else
+ {
+   ch = byte();
+   if (ch == '"') break;
+   switch (ch)
+ {
+ case 'a':  out_schar (007); break;
+ case 'b':  out_schar ('\b'); break;
+ case 'f':  out_schar ('\f'); break;
+ case 'n':  out_schar ('\n'); break;
+ case 'q':  out_schar ('"'); break;
+ case 'r':  out_schar ('\r'); break;
+ case 't':  out_schar ('\t'); break;
+ case '\\': out_schar ('\\'); break;
+ default:  break;
+ }
+ }
+ }
fflush (stdout);
break;
 
diff --git a/bc/storage.c b/bc/storage.c
index c79db82..28e933b 100644
--- a/bc/storage.c
+++ b/bc/storage.c
@@ -349,6 +349,7 @@ get_var (int var_name)
 {
   var_ptr = variables[var_name] = bc_malloc (sizeof (bc_var));
   bc_init_num (_ptr->v_value);
+  var_ptr->v_next = NULL;
 }
   return var_ptr;
 }
@@ -370,6 +371,12 @@ get_array_num (int var_index, unsigned long idx)
   unsigned int ix, ix1;
   int sub [NODE_DEPTH];
 
+  if (var_index >= a_count)
+{
+  rt_error ("Internal Error.");
+  return NULL;
+}
+
   /* Get the array entry. */
   ary_ptr = arrays[var_index];
   if (ary_ptr == NULL)
@@ -588,6 +595,12 @@ store_array (int var_name)
   bc_num *num_ptr;
   long idx;
 
+  if (var_name >= a_count)
+{
+  rt_error ("Internal Error.");
+  return;
+}
+
   if (!check_stack(2)) return;
   idx = bc_num2long (ex_stack->s_next->s_num);
   if (idx < 0 |

Re: A mail relay server for Debian Members is live

[Thomas Goirand]

On 7/16/22 23:49, Pierre-Elliott Bécue wrote:

Dear developers,

In the past months, it's been clear that sending mails from an
@debian.org address to some mail providers, including GMail, has become
harder and harder. While user DKIM feature (documented on [0]) can help,
we thought providing a relay server for our users to send their Debian
mail was a more long-term solution.

This service is now operational behind mail-submit.debian.org (AKA
stravinsky.debian.org). Documentation about how to use this service can
be accessed via [1]. The page behind [0] will be updated on the next
release we make of userdir-ldap-cgi.

Mails sent via this server will be DKIM-signed if the from is a
debian.org, debconf.org or ftp-master.debian.org address. If any
additional domain should be considered, feel free to ask.

This server requires an active Debian Account, and that one sets their
mailPassword up (again, see [1]) to be able to use the service. I've
tried to provide some useful tips on the doc.

If you have any question or issue, please don't hesitate to reach out.

Cheers!


Thanks a lot for this really useful feature.

Cheers,

Thomas Goirand (zigo)

Bug#1015186: ITP: jruby-rake -- ruby make-like utility - jruby version

[Thomas Goirand]

Package: wnpp
Severity: wishlist
Owner: Thomas Goirand 
X-Debbugs-Cc: debian-devel@lists.debian.org

* Package name: jruby-rake
  Version : 12.3.3
  Upstream Author : Ruby upstream
* URL : https://github.com/ruby/rake
* License : Expat
  Programming Lang: Ruby
  Description : ruby make-like utility - jruby version

 Rake is a simple ruby build program with capabilities similar to make.
 .
 Rake has the following features:
   * Rakefiles (rakes version of Makefiles) are completely defined in
 standard Ruby syntax. No XML files to edit. No quirky Makefile
 syntax to worry about (is that a tab or a space?)
   * Users can specify tasks with prerequisites.
   * Rake supports rule patterns to sythesize implicit tasks.
   * Rake is lightweight. It can be distributed with other
 projects as a single file. Projects that depend upon
 rake do not require that rake be installed on target
 systems.
 .
 This version of the package is for building JRuby itself. Do not use it with
 the standard Ruby interpreter.

Re: Re: questionable massive auto-removal: buggy deps nvidia-graphics-drivers-tesla-470

[Thomas Goirand]

On 5/27/22 09:26, Andreas Tille wrote:

Am Thu, May 26, 2022 at 08:47:20AM +0200 schrieb Nilesh Patra:

Would it be possible to manually remove this item from the list that generates
autoremovals?


... or generate a blacklist of packages that should not trigger those removals.

The autoremoval warnings are pretty helpful in general but if I'm forced to mass
remove this subject from my mailbox I might loose other sensible autoremoval
warnings.


In general, it's massively spamming me, just it should be spamming you 
as well (well, anyone maintaining a large amount of packages).


I recieved 536 mails (2 days ago)...

On 5/27/22 09:48, Paul Gevers wrote:
> Patches welcome. Code is here:
> 
https://salsa.debian.org/release-team/release-tools/-/blob/master/mailer/mail_autoremovals.pl 



IMO, if nobody has time to do it, the person who designed the tool 
should take care of fixing it. Instead of sending 536 mail, it should be 
sending a single mail with 536 entries in it... And it's not the first 
time I'm writing this.


Cheers,

Thomas Goirand (zigo)

Re: Firmware: Scope of non-free-firmware

[Thomas Goirand]

On 5/12/22 23:26, Paul Wise wrote:

On Thu, 2022-05-12 at 16:56 +0200, Thomas Goirand wrote:


If protected by a debconf prompt (by default, doing nothing...), all
of your remarks are going away.


That means that people who only ever upgrade via unattended-upgrades or
other mechanisms that disable debconf/dpkg prompts etc aren't going to
see the prompt. At work we disable them even when upgrading from one
release to the next.


Yeah, of course, but this is because you know what you're doing. If you 
do, then you also probably read the release notes, don't you? :)


Here, we're trying to find a way to warn the people who don't know...

Cheers,

Thomas Goirand (zigo)

Re: Firmware: Scope of non-free-firmware

[Thomas Goirand]

On 5/12/22 04:52, Paul Wise wrote:

On Wed, 2022-05-11 at 17:14 +0200, Thomas Goirand wrote:


A work around would be to have some automation to check if non-free is
activated, and (propose to) update the sources.list automatically to add
non-free-firmware.


That isn't feasible, since apt sources are managed external to Debian.

At my workplace we have $foo-apt-config* packages that manage our apt
sources, modifying them would cause us conffile prompts and that would
mean that upgrades to our $foo-apt-config* packages would get blocked,
since unattended-upgrades skips packages with conffile prompts.

Other people use configuration management systems that overwrite
modified files and probably manage their apt sources using those
systems, so Debian changes to apt sources would get removed.

Others might be running Debian on read-only squashfs images so they
would never get the apt sources modifications needed to get firmware
from non-free, their image builds could either just fail or maybe
silently fail to install the needed firmware files.


I'd prefer doing this, as having copies of the same package in both
non-free and non-free-firmware is (IMO) a mess.


Having the same package in unstable and testing works fine, I don't
see why it would be different for non-free and non-free/firmware.


If protected by a debconf prompt (by default, doing nothing...), all of 
your remarks are going away.


Example text:

> It looks like you have non-free firmware package(s) installed in your
> system, but the non-free-firmware repository doesn't look like present
> in your sources.list. Do you wish to add a new file to
> /etc/apt/sources.list.d/debian-non-free-firmware.list to add this
> repository?

Just my 2 cents idea, hoping it helps,
Cheers,

Thomas Goirand (zigo)

Re: Firmware: Scope of non-free-firmware

[Thomas Goirand]

On 5/11/22 17:24, Johannes Schauer Marin Rodrigues wrote:

Quoting Thomas Goirand (2022-05-11 17:14:57)

For backwards compatibility, I think that the firmware component is
going to need to be a subset of non-free; i.e. packages are going to
need to be *copied* not moved from non-free to the firmware component,
which means they would be available from both non-free components.


I think that's a good idea as it wouldn't break any setups. The number of
packages in non-free-firmware is probably very small and the package data would
not be duplicated on the mirrors anyways because non-free and non-free-firmware
would both reference the same deb archives in the /pool directory, right?


A work around would be to have some automation to check if non-free is
activated, and (propose to) update the sources.list automatically to add
non-free-firmware. I'd prefer doing this, as having copies of the same
package in both non-free and non-free-firmware is (IMO) a mess.


Maybe I'm lacking imagination but which approach would you take to do this
reliably? If you go that route, then a heuristic is not enough. You must not
break existing setups and you must also make sure never to get into a situation
where that automation has to bail out or otherwise a system will end up without
non-free-firmware even though it had non-free enabled.

What do you propose?

I'm also curious because I would like to do arbitrary machine-edits of
user-supplied apt sources.list files but so far nothing worked reliably enough.

Thanks!

cheers, josch


I was thinking about some kind of debconf prompt when upgrading from an 
older version of apt, of course disabled by default, that would propose 
adding the non-free-firmware repo. This is safe enough, IMO, and can 
also be used in the installer.


Cheers,

Thomas Goirand (zigo)

Re: Firmware: Scope of non-free-firmware

[Thomas Goirand]

On 5/11/22 03:48, Paul Wise wrote:

On Tue, 2022-05-10 at 14:30 -0600, Sam Hartman wrote:


So let's assume that at least all those packages can move to
non-free-firmware.


For backwards compatibility, I think that the firmware component is
going to need to be a subset of non-free; i.e. packages are going to
need to be *copied* not moved from non-free to the firmware component,
which means they would be available from both non-free components.


A work around would be to have some automation to check if non-free is 
activated, and (propose to) update the sources.list automatically to add 
non-free-firmware. I'd prefer doing this, as having copies of the same 
package in both non-free and non-free-firmware is (IMO) a mess.


Cheers,

Thomas Goirand (zigo)