Re: About i386 support
On 5/19/24 17:30, r...@neoquasar.org wrote: I have an N270 system I can use to contribute, if someone is willing to explain what I need to do to make it useful. Hi, If you allow me ... I was expecting someone else to write it before me, but seeing nobody does, let me try. ... The issue isn't only about how many contributors, or how much effort they put into it, but how much *everyone* in the project wants to spend time on i386 support. For example, *I* don't care at all about 32 bits arch, and would prefer if these were to be sent to ports.debian.org. I really mean *all* 32 bits arch, including armhf for example. Indeed, it's annoying each time when: - I have to pin Arch: in debian/tests/control for example, only because some packages have dropped 32 bits support (hint: sometimes, because some of them also maintained by myself as well, like OpenVSwitch, for example). - I have to care for failed build (often because of unit tests) in i386 of packages I know wont mater for these arch. And this is only 2 examples. This is a considerable loss of my (limited) contributor time. If 32 bits support was removed from Debian, this would make my (Debian) life easier, while I have zero use of 32 bits. If I had to setup Linux on a pi-zero, I probably would choose a more embedded distro than Debian anyways, and that's what I would recommend to anyone. Anyone running Debian on a non-amd64 capable laptop, at this time, should stop procrastinate, and get decent hardware (as mentioned earlier in this thread, cheap 2nd hands amd64 laptops are *very* cheap). Because I know others care, I continue to make the effort when possible. But these others should remember that's annoying me, and should weight the collective cost, because I might not be the only one... and everyone slightly involved in maintaining Debian might have, at some point, loss some time on 32 bits support. So this is a collective decision we should make: is 32 bits still relevant enough for spending (wasting?) our collective (limited) time on it? I'd vote no ... Especially considering i386 can become an unofficial port for those who care. Even if I will respect our community decision until the majority agrees, and will continue to do my best with i386 support until then, it has to happen one day. The only question is how long. Can Trixie be the last release with 32 bits support? Cheers, Thomas Goirand (zigo)
Re: Silent hijacking and stripping records from changelog
On 4/9/24 03:25, James McCoy wrote: When I first started looking into Rust packaging it was initially going to be for a workspace of crates. I didn't receive any pushback when I asked about taking over the one crate that had already been packaged and handling it from a single source package for that workspace. In the end I changed my mind and continued using the monorepo for the rest of the crates. If you allow me give my perspective from an outsider: the monorepo thingy for crates is the only place in Debian where I've seen it, and it's *VERY* confusing. Plus there are many reasons where one may want to package something in a different team, so IMO it's not a good idea. Plus what if some project hold a multi-language thing, like rust and another language, as source package, and then we need to generate multiple binaries? (real-life thingy, but can't remember which package) Just my 2 cents... :P Cheers, Thomas Goirand (zigo)
Bug#1069230: ITP: python-sherlock -- distributed inter-process locks with a choice of backend
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: python-sherlock Version : 0.4.1 Upstream Contact: Vaidik Kapoor * URL : https://github.com/py-sherlock/sherlock * License : Expat Programming Lang: Python Description : distributed inter-process locks with a choice of backend Sherlock is a library that provides easy-to-use distributed inter-process locks and also allows you to choose a backend of your choice for lock synchronization. Note: this is a new dependency of magnum-cluster-api OpenStack module.
Bug#1069229: ITP: python-haproxyadmin -- work with HAProxy via the stats socket
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: python-haproxyadmin Version : 0.2.4 Upstream Contact: Pavlos Parissis * URL : https://github.com/unixsurfer/haproxyadmin * License : Apache-2.0 Programming Lang: Python Description : work with HAProxy via the stats socket Haproxyadmin is a Python library for interacting with HAProxy load balancer to perform operations such as enabling/disabling servers. It does that by issuing the appropriate commands over the stats socket provided by HAProxy. It also uses that stats socket for retrieving statistics and changing settings. Note: this is a new dependency of the magnum-cluster-api module for OpenStack.
Re: Seeking a small group to package Apache Arrow (was: Bug#970021: RFP: apache-arrow -- cross-language development platform for in-memory analytics)
On 3/25/24 19:17, Julian Gilbey wrote: Hi all, [NB: sent to d-science, d-python, d-devel and the RFP bug; reply-to set to d-science and the RFP bug only] An update on Apache Arrow, and in particular the Python library PyArrow. For those who don't know: Apache Arrow is a development platform for in-memory analytics. It contains a set of technologies that enable big data systems to process and move data fast. It specifies a standardized language-independent columnar memory format for flat and hierarchical data, organized for efficient analytic operations on modern hardware. The project is developing a multi-language collection of libraries for solving systems problems related to in-memory analytical data processing. This includes such topics as: * Zero-copy shared memory and RPC-based data movement * Reading and writing file formats (like CSV, Apache ORC, and Apache Parquet) * In-memory analytics and query processing (from: https://arrow.apache.org/docs/index.html) Pandas has announced that Pandas 3.x will depend on PyArrow in a critical way (it will back the "string" datatype), and it is due to be released imminently. So this is a plea for anyone looking for something really helpful to do: it would be great to have a group of developers finally package this! There was some initial work done (see the RFP bug report for details: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=970021), but that is fairly old now. As Apache Arrow supports numerous languages, it may well benefit from having a group of developers with different areas of expertise to build it. (Or perhaps it would make more sense to split the upstream source into a collection of different Debian source packages for the different supported languages. I don't know.) Unfortunately I don't have the capacity to devote any time to it myself. Thanks in advance for anyone who can step forward for this! Best wishes, Julian Hi, I may not have much available time to help, though I'd love to have Arrow in Debian, as Ceph uses it, and currently use an embedded version. Cheers, Thomas Goirand (zigo)
Re: Validating tarballs against git repositories
On 3/30/24 08:02, Gioele Barabucci wrote: For too many core packages there is an opaque "something happens on the Debian maintainer laptop" step that has no place in 2024. Let's replace this by an opaque "something happens on the Salsa CI". Cheers, Thomas Goirand (zigo)
Re: Validating tarballs against git repositories
On 4/1/24 00:32, Stefano Rivera wrote: So... for Python packages using setuptools-scm, we're pushed towards depending on upstream-created source tarballs (sdists), rather than upstream git archives, because we don't have the ".git" directory in our source packages. Hi Stefano, Thanks for jumping in this thread, though I'll have to disagree with you... with all due respect! :) As you know, I'm by far the biggest uploader of Python modules in Debian, due to the fact I'm maintaining OpenStack. As you may know as well, the reason I'm not maintaining all of that inside the Debian Python Team, is only because it's forbidden to use an upstream git tag workflow in the team, and that I have to use pristine-tar. I very much regret this fact, but live with it when I have to package within the Debian Python Team. Anyways, on the 400+ packages that I maintain within the OpenStack team, I did come across some upstream using setuptools-scm. To my experience, using the: git archive --prefix=$(DEBPKGNAME)-$(VERSION)/ $(GIT_TAG) \ | xz >../$(DEBPKGNAME)_$(VERSION).orig.tar.xz workflow out of an upstream always work, including for those that are using setuptools-scm. One simply needs to add the dependency, and correctly set, with something like this: SETUPTOOLS_SCM_PRETEND_VERSION=$(shell dpkg-parsechangelog -SVersion \ | sed -e 's/^[[:digit:]]*://' \ -e 's/[-].*//' \ -e 's/~/.0/' \ -e 's/+dfsg1//' \ | head -n 1) Because I'm dealing with the DPT packages as well, I can tell, and I insist: the workflow to to work with upstream Git is a way nicer than the pristine-tar / gbp import-orig one. The upstream tag workflow *ALWAYS* work, and often (even: always, for the case of Python modules) contain less pre-built artifacts. Also, sdists are *not* "upstream-created source tarballs". I consider the binary form built for PyPi. Just like we have .debs, PyPi has tarballs and wheels, rather than how you describe them. By the way, am I the only one to think that's so lame to use tarballs in so many ways... Isn't this a so ... legacy retro-computing format? :) Cheers, Thomas Goirand (zigo)
Bug#1067011: ITP: python-observabilityclient -- OpenStack Observability Client
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: python-observabilityclient Version : 0.1.1 Upstream Contact: OpenStack Foundation * URL : https://infrawatch.github.io/documentation/ * License : Apache-2.0 Programming Lang: Python Description : OpenStack Observability Client observabilityclient is an OpenStackClient (OSC) plugin implementation that implements commands for management of Prometheus. This is a new dependency of OpenStack.
Re: Package marked for autoremoval due to closed bug?
On 3/15/24 07:14, Andreas Tille wrote: I simply remove all those testing removal warnings in my mailbox to cope with this and by doing so I'm probably missing real issues I should rather care about. I know what you're talking about: anyone that maintains a lot of packages always receive waves of multiple dozens of email, and often, it's hardly actionable. Then I just end up ignoring them, hoping the fix is already under way by the person in charge of that new dependency I never heard of before. I hope one day, someone will have the skill/time/courage to refactor these messages into something humanly readable. One message per day per DD, with a summary of the possible AUTORM pointing at the list of RC bugs with links, would be a way more useful than ONE message per package, for example. Thanks to all who are involved in this complex migration Yeah, +1 Thomas Goirand (zigo)
Re: Package marked for autoremoval due to closed bug?
On 3/15/24 21:52, Paul Gevers wrote: Hi, Disclaimer: exception only valid while the time_t transition is ongoing. On 15-03-2024 6:15 a.m., Steve Langasek wrote: Migration to testing is largely out of control of the maintainers at this point, it's very much dependent on folks rebootstrapping armel and armhf against the new library names. Should these bugs be downgraded again to important severity? As I'm normally watching out for out-of-sync packages, I'm fine (with my Release Team hat on) with maintainers downgrading RC bugs in testing that have been fixed in unstable and that don't require a quick update in testing (e.g. security issues probably warrant discussing the tpu path with the RT). Once time_t 64 bit is done, I'll be filling bugs for packages that don't migrate again, so the lack of the fix in testing won't go unnoticed. For bookkeeping purposes, please usertag downgraded bugs with user release.debian@packages.debian.org and usertag time_t-downgrade. Please be careful with downgrading RC bugs. Paul Hi Paul, I leave this to your own judgement, of course (with your "release team hat"). But when the AUTORM period was announced as reduced, I thought like it was probably a bad call, and that the previous AUTORM was aggressive enough. I didn't dare to express myself about it at the time, as maybe you knew better. My thinking was: after all, people should fix their bugs, no? Plus release team people must know better... But after a few months with the shorter AUTORM period, my opinion is growing firmer: the previous one (whatever it was) seemed more appropriate to me with the way Debian is being developed (ie: largely by volunteers on their free time), and for those of us in charge of maintaining a long (and sometimes complicated) chain of dependencies. Now, with this type of (breaking) transition, would growing back the AUTORM period (to what it used to be) help? Or are you still in the opinion making it shorter was a good move? Your thoughts? Cheers, Thomas Goirand (zigo)
Bug#1066927: ITP: python-momepy -- Urban Morphology Measuring Toolkit
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: python-momepy Version : 0.7.0 Upstream Contact: Martin Fleischmann * URL : https://github.com/pysal/momepy * License : BSD-3-clause Programming Lang: Python Description : Urban Morphology Measuring Toolkit Momepy is a library for quantitative analysis of urban form - urban morphometrics. It is part of PySAL (Python Spatial Analysis Library) and is built on top of GeoPandas, other PySAL modules, and networkX. Note: this is a new dependency of networkx, so we can continue to build its documentation.
Bug#1066925: ITP: python-contextily -- Context geo-tiles in Python
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: python-contextily Version : 1.5.2 Upstream Contact: Dani Arribas-Bel * URL : https://github.com/geopandas/contextily * License : BSD-3-clause Programming Lang: Python Description : Context geo-tiles in Python Contextily is a package to retrieve tile maps from the internet. It can add those tiles as basemap to matplotlib figures or write tile maps to disk into geospatial raster files. Bounding boxes can be passed in both WGS84 (EPSG:4326) and Spheric Mercator (EPSG:3857). Note: this is a new build-depends for networkx, so we can continue to build its documentation.
Bug#1066922: ITP: python-mercantile -- Web mercator XYZ tile utilities
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: python-mercantile Version : 1.2.1 Upstream Contact: Sean Gillies * URL : https://github.com/mapbox/mercantile * License : BSD-3-clause Programming Lang: Python Description : Web mercator XYZ tile utilities The mercantile module provides ul(xtile, ytile, zoom) and bounds(xtile, ytile, zoom) functions that respectively return the upper left corner and bounding longitudes and latitudes for XYZ tiles, a xy(lng, lat) function that returns spherical mercator x and y coordinates, a tile(lng, lat, zoom) function that returns the tile containing a given point, and quadkey conversion functions quadkey(xtile, ytile, zoom) and quadkey_to_tile(quadkey) for translating between quadkey and tile coordinates. Note: This is a new build-dependency for networkx so we can continue to build its documentation.
Bug#1066184: ITP: networking-generic-switch -- OpenStack virtual network service - networking-generic-switch
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: networking-generic-switch Version : 7.2.0 Upstream Contact: OpenStack Foundation * URL : https://github.com/openstack/networking-generic-switch * License : Apache-2.0 Programming Lang: Python Description : OpenStack virtual network service - networking-generic-switch Neutron provides an API to dynamically request and configure virtual networks. These networks connect "interfaces" from other OpenStack services (such as vNICs from Nova VMs). The Neutron API supports extensions to provide advanced network capabilities, including QoS, ACLs, and network monitoring. . This package provides the networking-generic-switch ML2 plugin.
Bug#1066089: ITP: python-reactivex -- asynchronous and event-based programs using observable collections
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: python-reactivex Version : 4.0.4 Upstream Contact: Dag Brattli * URL : http://reactivex.io, https://github.com/ReactiveX/RxPY * License : Expat Programming Lang: Python Description : asynchronous and event-based programs using observable collections This package provides a library for composing asynchronous and event-based programs using observable collections and query operator functions in Python. Using Rx, developers represent asynchronous data streams with Observables, query asynchronous data streams using operators, and parameterize concurrency in data/event streams using Schedulers.
Bug#1066087: ITP: python-influxdb-client -- InfluxDB 2.0 Python client library
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: python-influxdb-client Version : 1.40.0 Upstream Contact: InfluxData, Inc. * URL : https://github.com/influxdata/influxdb-client-python * License : Expat Programming Lang: Python Description : InfluxDB 2.0 Python client library Client library for use with InfluxDB 2.x and Flux. InfluxDB 3.x users should instead use the lightweight v3 client library (influxdb3-python). InfluxDB 1.x users should use the v1 client library (influxdb-python). For ease of migration and a consistent query and write experience, v2 users should consider using InfluxQL and the v1 client library (influxdb-python). . The API of the influxdb-client is not the backwards-compatible with the old one influxdb-python.
Bug#1065823: ITP: lenovolegionlinux -- CLI and GUI for Lenovo Legion laptops fan and power control
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: lenovolegionlinux Version : 0.0.9 Upstream Contact: johnfanv2 * URL : https://github.com/johnfanv2/LenovoLegionLinux/ * License : GPL-2 Programming Lang: C, Python Description : CLI and GUI for Lenovo Legion laptops fan and power control This package provides a command line interface and a graphical user interface for controlling many power and fan behavior for Lenovo Legion Laptops. It is implemented in Python. . This package also sets fan curve on startup for Lenovo Legion laptops, and apply different profiles if the battery charge is plugged or not.
Bug#1064502: ITP: python-aiounittest -- test asyncio code more easily
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: python-aiounittest Version : 1.4.2 Upstream Contact: Krzysztof Warunek * URL : https://github.com/kwarunek/aiounittest * License : Expat Programming Lang: Python Description : test asyncio code more easily The aiounittest is a helper library to ease of your pain (and boilerplate), when writing a test of the asynchronous code (:code:`asyncio`). With this library, it is possible to test: * synchronous code (same as the unittest.TestCase from the std lib) * asynchronous code: it supports syntax like async/await (Python 3.5+) and asyncio.coroutine/yield from (Python 3.4). Note: this is a new build-dependency for python-ddt, which is used for testing OpenStack.
Bug#1063899: ITP: auxilium -- tool for parse args in many shell (bash, ksh,zsh)
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: auxilium Version : 0.0.9 Upstream Contact: Philippe Seraphin * URL : https://salsa.debian.org/openstack-team/third-party/auxilium * License : Apache-2.0 Programming Lang: Bash Description : tool for parse args in many shell (bash, ksh,zsh) This help you to parse command-line arguments. You can source it in your shell script and use different function to add argument, print usage and parse arguments
Bug#1059614: ITP: ikvswitch -- virtual switch infrastructure designed for complex network deployment testing
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: ikvswitch Version : 0.0.1 Upstream Contact: Thomas Goirand * URL : https://salsa.debian.org/openstack-team/debian/ikvswitch * License : Apache-2.0 Programming Lang: Shell Description : virtual switch infrastructure designed for complex network deployment testing This package sets up virtual machines that will act as 2 spine switches and 3 racks with 2 leaf switches each, to simulate a datacenter setup. All 8 switches are connected to each other over un-numbered IPv6 link-local addresses over which a BGP link is established (ie: this is a bgp-to-the-host setup, or L3 only networking). . Once setup, it is possible for the user to connect virtual machines to this virtual infrastructure. Each VM can be connected to 2 rack switches over BGP as well. . The goal of this package is to be able to experiment with virtual machines, as if they were physical machines installed into 3 physical racks, with this type of L3 connectivity only. Note: I'm planning to use this for testing complex OpenStack networking setup, but that's far from being the only use case: this is very general purpose.
Bug#1058361: ITP: python-pyasyncore -- asyncore for Python 3.12 onwards
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: python-pyasyncore Version : 1.0.2 Upstream Contact: Simon Robinson * URL : https://github.com/simonrob/pyasyncore * License : Python Software Foundation License Programming Lang: Python Description : asyncore for Python 3.12 onwards This package contains the asyncore module as found in Python versions prior to 3.12. It is provided so that existing code relying on "import asyncore" is able to continue being used without significant refactoring. . The module's source code is taken directly from the Python standard library. The specific version of asyncore.py used is the last update before the addition of removal warnings at import time, and is essentially equivalent to the version provided with Python 3.9. . Please note that new projects should prefer asyncio. Note that I'm creating this package as a temporary measure to fix some of the 3.12 issues that are ongoing. Projects like Taskflow cannot be easily converted to asyncio, because some other packages are using both Eventlet and Taskflow, and asyncio is not compatible with Eventlet. So we have to live with this for a while more, until Eventlet can be fixed to use asyncio...
Bug#1057636: ITP: swift-tools -- Swift cluster cli helpers utilities
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: swift-tools Version : 0.0.1 Upstream Contact: Philippe Seraphin * URL : https://salsa.debian.org/openstack-team/third-party/swift-tools * License : Apache-2.0 Programming Lang: Python Description : Swift cluster cli helpers utilities This package contains a set of utilities to help managing Swift cluster. It helps, for example: * check rebalance status * check status of the cluster * check max oldest completion
Bug#1057389: ITP: haproxy-cmd -- command line utility to control backends of haproxy
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: haproxy-cmd Version : 0.0.1 Upstream Contact: Thomas Goirand * URL : https://salsa.debian.org/openstack-team/third-party/haproxy-cmd * License : Apache-2.0 Programming Lang: Python Description : command line utility to control backends of haproxy This package contains a helper to send commands through the haproxy socket, so it is possible to maintain servers part of a cluster by draining, enabling and stopping servers part of a backend. . This utility is, in fact, a wrapper around the haproxy admin socket, so it is easier to use, with bash-completion and so on.
Bug#1056044: ITP: python-jsonschema-specifications -- JSON Schema meta-schemas and vocabularies, exposed as a Registry
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: python-jsonschema-specifications Version : 2023.11.1 Upstream Contact: Julian Berman * URL : https://github.com/python-jsonschema/jsonschema-specifications * License : Expat Programming Lang: Python Description : JSON Schema meta-schemas and vocabularies, exposed as a Registry This package contains JSON support files from the JSON Schema Specifications (metaschemas, vocabularies, etc.), packaged for runtime access from Python as a referencing-based Schema Registry. Note: This package is needed to update python-jsonschema to the latest upsteram release.
Bug#1054116: ITP: puppet-module-puppet -- Puppet module for Puppet itself (client and server)
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: puppet-module-puppet Version : 18.0.0 Upstream Contact: Theforeman * URL : https://github.com/theforeman/puppet-puppet * License : Apache-2.0 Programming Lang: Puppet, Ruby Description : Puppet module for Puppet itself (client and server) Puppet lets you centrally manage every important aspect of your system using a cross-platform specification language that manages all the separate elements normally aggregated in different files, like users, cron jobs, and hosts, along with obviously discrete elements like packages, services, and files. . This module contains a puppet to setup, configure and maintain puppet itself, client and server.
Bug#1054113: ITP: puppet-module-extlib -- Puppet module for Extlib
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: puppet-module-extlib Version : 7.0.0 Upstream Contact: Vox Pupuli * URL : https://github.com/voxpupuli/puppet-extlib * License : Apache-2.0 Programming Lang: Puppet, Ruby Description : Puppet module for Extlib Puppet lets you centrally manage every important aspect of your system using a cross-platform specification language that manages all the separate elements normally aggregated in different files, like users, cron jobs, and hosts, along with obviously discrete elements like packages, services, and files. . This module contains extlib: functions and facts that are out of scope for stdlib. Some of them are even intrinsically tied to stdlib.. This is a dependency to package puppet-module-puppet (ie: a puppet module to setup and configure the puppet agent & server).
Re: Is there a generic canonical way for a package script to check network connectivity?
On 10/9/23 07:20, Simon Richter wrote:
Hi,
On 09.10.23 11:49, Jonathan Kamens wrote:
I need to be able to tell from one of my package scripts whether the
host has networking connectivity.
無. There is no such thing as "networking connectivity."
There is "has access to a particular service, at this precise moment in
time" and "is usually connected to an unmetered Internet connection so
there is a reasonable expectation that a particular service can be
reached and should be made part of a workflow."
I very much agree with Simon. There's all sorts of "networking
connectivity", partial or not. For example, would you consider that your
server has network connectivity if it only has L2 link local
connectivity to the neighboring switches? In some case, you shouldn't.
In some case (like using bgp-to-the-host setup), you should first check
if FRR is using it to provide wider connectivity. In the case of an
OpenStack cluster, in some setup, FRR would do that, but typically the
nodes don't have internet access.
After many wrong designs, I ended up having a process that pings the
service I need to access to, with a script like this one:
TRIALS=300
while ! timeout 2 ping -q -c 1 ${DST_SERVER} >/dev/null \
&& [ "${TRIALS}" -gt 0 ] ; do
sleep 1
TRIALS=$(( ${TRIALS} - 1 ))
done
if [ "${TRIALS}" = 0 ] ; then
exit 1
else
exit 0
fi
Since I use this, I never had any issue.
(comments on the above script welcome... one improvement would be using
a timestamp using date to write the timeout in seconds, but in this
particular instance, I don't really care, I just care the caller script
waits until there's connectivity)
Cheers,
Thomas Goirand (zigo)
Bug#1053215: ITP: needrestart-gui -- web interface for needrestart
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: needrestart-gui Version : 0.0.1 Upstream Contact: Axel Jacquet * URL : https://salsa.debian.org/openstack-team/third-party/needrestart-gui * License : most-permissive Programming Lang: Python Description : web interface for needrestart This package provides a Python implementation to monitor services and provides a GUI to show their status and package versions. It uses in the background the needrestart package.
Re: [idea]: Switch default compression from "xz" to "zstd" for .deb packages
On 9/16/23 07:01, Hideki Yamane wrote:
* So, if we change {data,control}.tar file format in .deb from xz to zst,
we can reduce package installation time than ever since less decompression
time. It saves our lifetime a bit :)
* Downside: package file size is a bit larger than now, but enough bandwidth
will ease it for download time
- Not sure how repository size will be, need an experiment
Hi,
I'm not sure if we should switch to zstd, or if xz will do the work,
though I'd be delighted if the dpkg performances could be improved. I'm
spending all of my days installing server, sometimes with 1.5 TB of RAM
and 128 core (AMD Epyc...), on last gen NVMe, using a local mirror, it's
really painful to see how slow the debootstrap process is, compared to
what it could be. Unpacking multiple .deb at the same time seems a very
good idea to me, as well as parallelizing everything we can.
Just my 2 cents, as I wont be working on this,
Cheers,
Thomas Goirand (zigo)
Bug#1051838: ITP: python-scrapli-replay -- enable easy testing of scrapli programs
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: python-scrapli-replay Version : 2023.7.30 Upstream Contact: Carl Montanari * URL : https://github.com/scrapli/scrapli_replay * License : Expat Programming Lang: Python Description : enable easy testing of scrapli programs Easily test scrapli code with Pytest, or create mock SSH servers to play with. . Within Debian, this package is only useful for running unit tests for the package python-scrapli. Note: this is an indirect dependency for netmiko
Bug#1051831: ITP: python-ntc-templates -- TextFSM Templates for Network Devices, and wrapper for TextFSM's CliTable
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: python-ntc-templates Version : 3.5.0 Upstream Contact: Network to Code * URL : https://github.com/networktocode/ntc-templates/ * License : Apache-2.0 Programming Lang: Python Description : TextFSM Templates for Network Devices, and wrapper for TextFSM's CliTable This package contains TextFSM Templates for Network Devices, and a Python wrapper for TextFSM's CliTable. TextFSM helps make parsing cli commands more manageable. Note: this is a new dependency of netmiko that I would like to upgrade to the latest upstream release. Netmiko, itself, is a dependency of OpenStack networking-generic-switch, that configures vendor specific stuff of switches, so that Ironic (OpenStack baremetal) can work and setup things like VLANs automatically.
Bug#1051275: ITP: python-pyasn1-lextudio -- ASN.1 types and codecs
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: python-pyasn1-lextudio Version : 1.1.2 Upstream Contact: 2005-2019, Ilya Etingof * URL : https://github.com/lextudio/pyasn1 * License : BSD-2-clause Programming Lang: Python Description : ASN.1 types and codecs This package provides an implementation of ASN.1 types and codecs. It has been first written to support particular protocol (SNMP) but then generalized to be suitable for a wide range of protocols based on the ASN.1 specification.
Bug#1051272: ITP: python-pyasn1-modules-lextudio -- collection of ASN.1-based protocols modules
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: python-pyasn1-modules-lextudio Version : 0.2.9 Upstream Contact: Lex Li * URL : https://github.com/lextudio/pyasn1-modules * License : BSD-2-clause Programming Lang: Python Description : collection of ASN.1-based protocols modules The pyasn1-modules package contains a collection of ASN.1 data structures expressed as Python classes based on pyasn1 data model. . If ASN.1 module you need is not present in this collection, try using Asn1ate (from https://github.com/kimgr/asn1ate) tool that compiles ASN.1 documents into pyasn1 code.
Bug#1051265: ITP: python-pysmi-lextudio -- SNMP/SMI MIB parsing and conversion library
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: python-pysmi-lextudio Version : 1.0.4 Upstream Contact: Ilya Etingof * URL : https://github.com/lextudio/pysmi * License : BSD-2-clause Programming Lang: Python Description : SNMP/SMI MIB parsing and conversion library PySMI is a pure-Python implementation of SNMP SMI MIB parser. This tool is designed to turn ASN.1 MIBs into various formats. As of this moment, JSON and pysnmp modules can be generated from ASN.1 MIBs.
Bug#1051262: ITP: python-pysnmp-lextudio -- SNMP library v.1/v.2c/v.3 for agents and managers
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: python-pysnmp-lextudio Version : 5.0.26 Upstream Contact: LeXtudio Inc. * URL : https://github.com/lextudio/pysnmp * License : BSD-2-clause Programming Lang: Python Description : SNMP library v.1/v.2c/v.3 for agents and managers This is a Python implementation of SNMP v.1/v.2c/v.3 engine. Its general functionality is to assemble/disassemble SNMP messages from/into given SNMP Object IDs along with associated values. PySNMP also provides a few transport methods specific to TCP/IP networking. . PySNMP is written entirely in Python and is self-sufficient in terms that it does not rely on any third party tool (it isn't a wrapper). . This version is a fork of Ilya Etingof's project etingof/pysnmp. Ilya sadly passed away on 10-Aug-2022.
Bug#1049868: ITP: ceph-tools -- utilities to manage a Ceph cluster
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: ceph-tools Version : 0.0.1 Upstream Contact: Philippe Seraphin * URL : https://salsa.debian.org/openstack-team/third-party/ceph-tools * License : Apache-2.0 Programming Lang: bash, python Description : utilities to manage a Ceph cluster This package contains a set of utilities to help managing a Ceph cluster. It helps, for example: * managing rebalance * adding multiple OSD in a scheduled way * display the dispersion of OSD fillings
Re: debci / salsa ci: support for qemu runner
On 7/25/23 19:49, Johannes Schauer Marin Rodrigues wrote: having kvm available in debci and salsaci would be a big plus. The issue with nested virt, is that they prevent live-migration of VMs (Qemu doesn't support live-migrating nested MMU pages...). There's ongoing work to allow this in upstream Qemu, but as far as I know, this isn't ready yet. Once we have the feature in, we'll go from a "mostly unsupported" in public clouds to "mostly, everyone has it". Until then, I would recommend against using nested-virt whenever possible. Cheers, Thomas Goirand (zigo)
Re: Policy consensus on transition when removing initscripts.
On 6/27/23 17:45, Andreas Henriksson wrote: Dropping things and letting people pick them up if they think they are still useful seems to be the only practical way forward. It's not. As written by Russ in this thread, filling a bug against orphan-sysvinit-scripts so it takes over the abandoned script is. I wouldn't mind seeing this mandatory, and written in the policy. Cheers, Thomas Goirand (zigo)
Re: Policy consensus on transition when removing initscripts.
On 6/25/23 16:15, Mark Hindley wrote: Hello friends and colleagues, Debian Policy no longer requires that packages which provide a systemd .service file also provide an initscript. This permits maintainers who so wish to remove initscripts from their packages. However, initscripts remain used and useful[1], and uncoordinated removal can have significant effects on users' systems[2]. With the encouragement of the Technical Committee[3] and despite some unavoidable deficiencies resulting consequent on keeping initscripts without their intended package[4], orphan-sysvinit-scripts has collected and maintained some dropped initscripts. However, the process surrounding this has not been defined in Policy. Indeed, #975075[5] contains a number of suggestions that have not yet been followed through. The most recent proposal[6] for updating the Policy with a requirement to use tmpfiles.d(5) states "Init systems other than ``systemd`` should allow providing the same functionality as appropriate for each system, for example managing the directories from the init script shipped by the package." This creates an inconsistency whereby non-systemd inits are required to provide functionality in their initscript, but that initscript is not required to be present. To avoid breakage of existing systems and facilitate ongoing support for non-systemd inits, I would like to establish a consensus for - stating that initscripts remain useful. - requiring a coordinated transition of any initscript a maintainer wishes to drop to the orphan-sysvinit-scripts package and providing the relevant copyright information. Best wishes Mark There's some ongoing (or already working?) work for OpenRC to support systemd .service files. Contributing to this would be a much better use of your time, IMO. Cheers, Thomas Goirand (zigo)
Bug#1038771: ITP: magnum-cluster-api -- cluster API driver for Magnum
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: magnum-cluster-api Version : 0.6.0 Upstream Contact: Mohammed Naser * URL : https://github.com/vexxhost/magnum-cluster-api * License : Apache-2.0 Programming Lang: Python Description : cluster API driver for Magnum Magnum is an OpenStack project which offers container orchestration engines for deploying and managing containers as first class resources in OpenStack. . This plugin for Magnum uses the Kube's cluster API for deploying.
Bug#1038767: ITP: python-pykube-ng -- client library for Kubernetes
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: python-pykube-ng Version : 22.9.0 Upstream Contact: Eldarion, Inc. * URL : https://codeberg.org/hjacobs/pykube-ng * License : Apache-2.0 Programming Lang: Python Description : client library for Kubernetes Pykube (pykube-ng) is a lightweight Python client library for Kubernetes. It is a Platform as a Service (PaaS) that makes it easy to manage web application deployment and hosting through the entire lifecycle from development through testing to production. It adds components and tools on top of Kubernetes that help developers manage their application infrastructure. This is a dependency for: https://github.com/vexxhost/magnum-cluster-api that I also intend to package.
Bug#1034869: ITP: puppet-module-rally -- Puppet module for OpenStack Rally
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: puppet-module-rally Version : 10.0.0 Upstream Contact: OpenStack Foundation * URL : https://github.com/openstack/puppet-rally * License : Apache-2.0 Programming Lang: Puppet Description : Puppet module for OpenStack Rally Puppet lets you centrally manage every important aspect of your system using a cross-platform specification language that manages all the separate elements normally aggregated in different files, like users, cron jobs, and hosts, along with obviously discrete elements like packages, services, and files. . Rally is a Benchmark-as-a-Service project for OpenStack. . Rally is intended to provide the community with a benchmarking tool that is capable of performing specific, complicated and reproducible test cases on real deployment scenarios. . This module manages both the installation and configuration of OpenStack Rally.
Bug#1033934: ITP: puppet-module-voxpupuli-kmod -- Puppet module for manipulating modprobe and kernel modules
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: puppet-module-voxpupuli-kmod Version : 3.2.0 Upstream Author : Voxpupuli * URL : https://github.com/voxpupuli/puppet-kmod * License : Apache-2.0 Programming Lang: Puppet Description : Puppet module for manipulating modprobe and kernel modules Puppet lets you centrally manage every important aspect of your system using a cross-platform specification language that manages all the separate elements normally aggregated in different files, like users, cron jobs, and hosts, along with obviously discrete elements like packages, services, and files. . This module manages kernel module loading and options.
Bug#1032269: ITP: python-sphinx-code-include -- include source code from any Sphinx project using only its import path
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: python-sphinx-code-include Version : 1.1.1 Upstream Author : Colin Kennedy * URL : https://github.com/ColinKennedy/sphinx-code-include * License : BSD-2-clause Programming Lang: Python Description : include source code from any Sphinx project using only its import path Sphinx-code-include is an extension for Sphinx that lets you render source-code of any class or function directly into your Sphinx documentation using only as string.
Re: Bug#1032137: ITP: python-hardware -- hardware detection and classification utilities
On 3/1/23 17:20, Antoine Beaupré wrote: On 2023-02-28 15:18:33, Thomas Goirand wrote: * Package name: python-hardware Description : hardware detection and classification utilities Detect hardware features of a Linux systems: * RAID * hard drives * IPMI * network cards * DMI infos * memory settings * processor features . Filter hardware according to hardware profiles. Oh, this is interesting! There's very little documentation on the upstream site, what do you plan on using this for? It looks like a library I could very well use to rewrite stressant into something more sane... It seems it even has benchmarks... Thanks for any clarification! Hi, FYI, that's a dependency of ironic-python-agent [1], which does hardware discovery and image install for Ironic. I've just uploaded both packages and I intend to deploy my first Ironic-enabled cloud soonish. :) Cheers, Thomas Goirand (zigo) [1] https://opendev.org/openstack/ironic-python-agent
Bug#1032137: ITP: python-hardware -- hardware detection and classification utilities
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: python-hardware Version : 0.30.0 Upstream Author : Red Hat * URL : https://github.com/redhat-cip/hardware * License : Apache-2.0 Programming Lang: Python Description : hardware detection and classification utilities Detect hardware features of a Linux systems: * RAID * hard drives * IPMI * network cards * DMI infos * memory settings * processor features . Filter hardware according to hardware profiles.
Bug#1032135: ITP: ironic-python-agent -- bare metal hypervisor API for OpenStack - Python Agent
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: ironic-python-agent Version : 9.1.0 Upstream Author : OpenStack Discuss * URL : https://opendev.org/openstack/ironic-python-agent * License : Apache-2.0 Programming Lang: Python Description : bare metal hypervisor API for OpenStack - Python Agent Ironic provision bare metal machines instead of virtual machines. It is a fork of the Nova Baremetal driver. It is best thought of as a bare metal hypervisor API and a set of plugins which interact with the bare metal hypervisors. By default, it will use PXE and IPMI in concert to provision and turn on/off machines, but Ironic also supports vendor-specific plugins which may implement additional functionality. . This package provides the Python agent, to be deployed on the discovery image or ramdisk.
Re: MariaDB 10.11 in Bookworm - call for contributions
On 2/23/23 17:22, Otto Kekäläinen wrote: Hello! (Stop reading if you don't use MariaDB) I am currently preparing the upload of MariaDB 10.11.2-2 to Debian unstable and aim for the highest possible quality. I am currently doing the bulk of the testing and packaging alone and to make sure that the quality is top notch, I would be glad to see more people contribute. If you have time to help, please consider these (in order of importance): 1. Review current open MRs at https://salsa.debian.org/mariadb-team/mariadb-server/-/merge_requests 2. Review items highlighted by Debian QA systems (Lintian, builds etc) and submit a fix to improve the quality: https://tracker.debian.org/pkg/mariadb 3. Review what testing we have at https://salsa.debian.org/mariadb-team/mariadb-server/-/pipelines and think about potential gaps - CI is very important as it is the only way we can prevent regressions in a scalable way 4. Review/follow-up on existing bugs that currently need more information: https://bugs.debian.org/cgi-bin/pkgreport.cgi?repeatmerged=no=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
On 2/19/23 17:04, Cyril Brulebois wrote: Cyril Brulebois (2023-02-19): I tried to hotpatch it, but failed to so far. Second attempt seems better. Might take an extra dinstall (+ indexing in the following hours) to have all the things in place though. If people still see problems tomorrow, please follow up with details. Cheers, Hi Cyril, Thanks a lot for this! :) Thomas
Bug#1029545: ITP: ceilometer-instance-poller -- OpenStack ceilometer instance poller
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: ceilometer-instance-poller Version : 0.0.8 Upstream Author : Thomas Goirand * URL : https://salsa.debian.org/openstack-team/services/ceilometer-instance-poller/ * License : Apache-2.0 Programming Lang: Python Description : OpenStack ceilometer instance poller Ceilometer aims to deliver a Single Point Of Contact for billing systems, providing all the counters they need to establish customer billing, across all current and future OpenStack components. The delivery of counters must be traceable and auditable, the counters must be easily extensible to support new projects, and agents doing data collections should be independent of the overall system. . (A ceilometer is an instrument that measures cloud coverage.) . This package contains a libvirt and guestfs inspection script to poll what type of operating system is running in OpenStack VMs.
Re: SONAME bumps (transitions) always via experimental
On 1/5/23 12:28, Sebastiaan Couwenberg wrote: On 1/5/23 12:26, Paul Gevers wrote: Are there objections against this workflow? (Or voices from people who This has been a best practice for quite a while, high time to make it hard requirement. Kind Regards, Bas +1
Re: Boost 1.81 in Debian Testing
On 1/4/23 06:24, Anton Gladky wrote: apt install libboost-dev -t experimental FYI, Ceph FTBFS with it... :/ IMO, this was expected. Help fixing this would be greatly appreciated. Cheers, Thomas Goirand (zigo)
Re: Boost 1.81 in Debian Testing
On 1/4/23 06:24, Anton Gladky wrote: Dear valued contributors, I am pleased to announce that the latest version of Boost, version 1.81, is now available in Debian Testing [1]. We encourage all contributors whose packages depend on Boost libraries to consider building against Boost 1.81 in order to facilitate a smooth transition. Installing the -dev Boost packages from the experimental repository is simple, as shown in the following command: sudo apt install libboost-dev -t experimental. If you encounter any issues or have suggestions for improvement, please do not hesitate to file bugs or prepare merge requests on salsa [2]. Thank you. [1] https://tracker.debian.org/pkg/boost1.81 [2] https://salsa.debian.org/debian/boost Sincerely, Anton Hi, The latest update of boost was in late 2020. Why are we waiting so late in the release cycle to do such a transition? The month of the freeze is *NOT* a good moment to do it. Cheers, Thomas Goirand (zigo)
Bug#1026017: ITP: designate-tlds -- Designate TLDs population
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: designate-tlds Version : 0.0.1 Upstream Author : Axel Jacquet * URL : https://salsa.debian.org/openstack-team/services/designate-tlds * License : Apache-2.0 Programming Lang: Python Description : Designate TLDs population Designate provides DNSaaS services for OpenStack. It provides a multi-tenant REST API for domain & record management. It is Integrated with Keystone for authentication, and provides a framework in place to integrate with Nova and Neutron notifications (for auto-generated records). Designate supports PowerDNS and Bind9 out of the box. This package fill-up the Designate database with the global TLDs list downloaded from Mozilla.
Re: Q: How about versions/features in bookworm?
On 11/6/22 05:58, Hideki Yamane wrote: Q7: Will python3.11 be default in bookworm? What we discussed during Debconf is that we will *try* to make this happen, but if it doesn't go well, we will revert and ship Bookworm with 3.10 only. 3.11 is tempting, because it has nice features, and it goes a way faster than 3.10. However, to me, it's already too late for it: we need to check 3000+ packages over the next 2 months, and IMO, that's too risky. But that's only my opinion... Cheers, Thomas Goirand (zigo)
Bug#1022930: ITP: golang-github-iancoleman-strcase -- converting string case to various cases
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: golang-github-iancoleman-strcase Version : 0.2.0 Upstream Author : Ian Coleman * URL : https://github.com/iancoleman/strcase * License : Expat Programming Lang: Golang Description : converting string case to various cases Strcase is a go package for converting string case to various cases (like snake case, or camel case). Strcase can deal with common acronyms that it knows it shouldn't modify. Note: this is a dependency for mgmt-config that I'm packaging.
Bug#1022929: ITP: golang-github-coredhcp-coredhcp -- multithreaded, modular and extensible DHCP server
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: golang-github-coredhcp-coredhcp Version : 0.0.0+git.2022.04.07.a2552c5c1b Upstream Author : The CoreDHCP Authors * URL : https://github.com/coredhcp/coredhcp * License : Expat Programming Lang: Golang Description : multithreaded, modular and extensible DHCP server Coredhcp is a fast, multithreaded, modular and extensible DHCP server written in Go. In CoreDHCP almost everything is implemented as a plugin. Every request is evaluated calling each plugin in order, until one breaks the evaluation and responds to, or drops, the request. Note: this is a dependency of mgmt-config that I'm packaging.
Bug#1022928: ITP: golang-github-d-tux-go-fstab -- simple fstab parser
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: golang-github-d-tux-go-fstab Version : 0.0.0+git.2014.12.04.eb4090f265 Upstream Author : Denis Wernert * URL : https://github.com/d-tux/go-fstab * License : BSD-3-clause Programming Lang: Golang Description : simple fstab parser This Go package provides a /etc/fstab parser, and facitities to be able to mount and unmount. It supports UUID, labels, partuuid, parlabel, nfs, swap, and more. Note: This is a dependency for mgmt-config
Bug#1022915: ITP: golang-github-pin-tftp -- TFTP server and client library for Golang
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: golang-github-pin-tftp Version : 3.0.0 Upstream Author : Dmitri Popov * URL : https://github.com/pin/tftp * License : Expat Programming Lang: Golang Description : TFTP server and client library for Golang This package provides a TFTP server and client library for Golang. It implements: * RFC 1350 - The TFTP Protocol (Revision 2) * RFC 2347 - TFTP Option Extension * RFC 2348 - TFTP Blocksize Option . Partially implements (tsize server side only): * RFC 2349 - TFTP Timeout Interval and Transfer Size Options . Its set of features is sufficient for PXE boot support. Note: this is another dependency for mgmt-config that I'm packaging.
Bug#1022902: ITP: golang-github-libvirt-libvirt-go-xml -- API for manipulating libvirt XML documents
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: golang-github-libvirt-libvirt-go-xml Version : 7.4.0 Upstream Author : Lian Duan * URL : https://github.com/libvirt/libvirt-go-xml * License : Expat Programming Lang: Golang Description : API for manipulating libvirt XML documents This package provides a Go API that defines a set of structs, annotated for use with "encoding/xml", that can represent libvirt XML documents. There is no dependency on the libvirt library itself, so this can be used regardless of the way in which the application talks to libvirt. Note: This is a dependency of mgmt-config that I'm packaging.
Bug#1022880: ITP: golang-github-x-cray-logrus-prefixed-formatter -- text formatter based on logrus.TextFormatter
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: golang-github-x-cray-logrus-prefixed-formatter Version : 0.5.2 Upstream Author : Denis Parchenko * URL : https://github.com/x-cray/logrus-prefixed-formatter * License : Expat Programming Lang: Golang Description : text formatter based on logrus.TextFormatter Logrus formatter mainly based on original logrus.TextFormatter but with slightly modified colored output and support for log entry prefixes, e.g. message source followed by a colon. In addition, custom color themes are supported. Note: This is a dependency for mgmt-config.
Bug#1022877: ITP: golang-github-chappjc-logrus-prefix -- text formatter based on logrus.TextFormatter
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: golang-github-chappjc-logrus-prefix Version : 0.0.0+git.2018.02.26.3a1d64819a Upstream Author : Jonathan Chappelow * URL : https://github.com/chappjc/logrus-prefix * License : Expat Programming Lang: Golang Description : text formatter based on logrus.TextFormatter Logrus formatter mainly based on original logrus.TextFormatter but with slightly modified colored output and support for log entry prefixes, e.g. message source followed by a colon. In addition, custom color themes are supported. Note: This is a dependency of mgmt-config
Bug#1022872: ITP: golang-github-blynn-nex -- lexer similar to Lex/Flex
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: golang-github-blynn-nex Version : 0.0.0+git.2021.03.30.1a3320dab9 Upstream Author : Ben Lynn * URL : https://github.com/blynn/nex * License : GPL-3.0 Programming Lang: Golang Description : lexer similar to Lex/Flex Nex is a lexer similar to Lex/Flex that: * generates Go code instead of C code * integrates with Go's yacc instead of YACC/Bison * supports UTF-8 * supports nested structural regular expressions. Note: This is a dependency of mgmt-config which I intend to package.
Bug#1022853: ITP: golang-github-felixge-httpsnoop -- capture http related metrics from http.Handlers
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
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#1022834: ITP: golang-opentelemetry-contrib -- Collection of 3rd-party packages for OpenTelemetry-Go
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
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
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
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
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.
Re: Firmware GR result - what happens next?
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
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?
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?
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
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
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: A mail relay server for Debian Members is live
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
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
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
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
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
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
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)
Bug#1010003: ITP: dynamic-motd -- gives some informations when you log into a server through SSH
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: dynamic-motd Version : 0.04 Upstream Author : Luc Didry * URL : https://github.com/ldidry/dynamic-motd * License : GPL-2 Programming Lang: Python Description : gives some informations when you log into a server through S dynamic-motd replaces the standard /etc/motd prompt by a more dynamic thingy, which is also modular, so you can customize the SSH motd with information from your system.
Re: Firmware - what are we going to do about it?
On 4/19/22 02:27, Steve McIntyre wrote: TL;DR: firmware support in Debian sucks, and we need to change this. See the "My preference, and rationale" Section below. Hi Steve, Thanks a lot for this proposal. Like many, I agree with your option 5. In many installation (especially the so-many servers I setup every day at work), I've enabled non-free only to be able to reach the firmware I need. That's annoying, because I don't need anything else but firmware, and knowing all the rest is also available makes me feel uncomfortable. So, definitively, having a new non-free-firmware section would be a very good thing and address the above concern. Having the ISO image including those being more visible would be great too. Cheers, Thomas Goirand (zigo)
Re: d/copyright: sunweaver's best practice write-up (was: Re: secnet_0.6.2_multi.changes REJECTED)
On 4/11/22 21:59, Mike Gabriel wrote: Hi Ian, On Mo 11 Apr 2022 18:51:35 CEST, Ian Jackson wrote: Another team member identified that there is code in this package under a number of different licenses other than GPL-3+, but that is not specified in sufficient detail in d/copyright. That contravenes both Debian Policy and the terms of those licenses. My apologies. You are completely correct. I don't understand how I came to think that the approach I took was sufficient. I guess it is a long time since I prepared a package with so many different bits and pieces in it. sharing some best practice here, feel free to adopt or give feedback on. For d/copyright maintenance I use my update-copyright.in script [1]. I run it on the source package's base folder. The script creates a d/copyright.in file. I keep this file as-is as part of my debian/ folder and use it for later reference. When wrapping up a new DEB package, I copy over d/copyright.in to d/copyright and complete it manually (plus doing some manual checks to see if the licensecheck tool got things right). Note, that I don't use file globbing in d/copyright, at all; every source file is listed individually. This catches 99% of all DFSG licenses on 80-95% of files in the src:pkg's source tree (depending on upstream being good at using proper license headers on individual files or not). Whenever an upstream version bump is due, I import the new upstream and re-run the update-copyright.in script on the src:pkg's base folder again. I get a diff between my previous debian/copyright.in version and the new version. This diff I then work into the actual d/copyright manually and thus have an easy workflow for tracking copyright changes in upstream projects (on a per individual file basis). This workflow is esp. helpful on projects where many copyright holders/years and/or licenses are involved and get updated every year or maybe with every changeset / new contributor. Greets, Mike [1] https://github.com/sunweaver/MyHomeConfig/blob/master/bin/update-copyright.in Mike, I'd very much welcome this script within the devscripts package! :) Thanks for sharing it. I probably will give it a try. Cheers, Thomas Goirand (zigo)
Re: writing REJECTED messages publicly on the ITP bugs (was: secnet_0.6.2_multi.changes REJECTED)
On 4/11/22 19:04, Jonas Smedegaard wrote: Quoting Ian Jackson (2022-04-11 18:51:35) For transparency, I am CCing this reply to debian-devel, and quoting the whole of the REJECTED mail. There does not seem to be anything in here that ought to be private. Please let me know if there is somewhere better. (I considered -legal but it didn't seem appropriate.) Since you ask: Seems to me that more suitable would be to file an ITP bugreport and post followups like this to that bugreport. Filing an ITP would also serve as an invitation for ftpmasters to post their followup to that bugreport on their own. Kind regards, - Jonas I'd approve if the FTP masters were doing this by default. I wouldn't mind if my (licensing or others) mistakes were discussed publicly. So now I wonder what's the FTP team members (and other DDs) opinion about this. Maybe it'd be nicer to have an opt-in for it, but then that'd be very annoying for the FTP team to know when to do what (with possible mistakes). Any idea how we could automate the Reply-To: thingy in a REJECTED action, depending on uploader's preference? (not: I'm not volunteering, just trowing a piece of idea... :) Cheers, Thomas Goirand (zigo)
Bug#1009056: ITP: puppet-module-voxpupuli-unbound -- Puppet module for unbound
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: puppet-module-voxpupuli-unbound Version : 5.0.0 Upstream Author : Voxpupuli * URL : https://github.com/voxpupuli/puppet-unbound * License : Apache-2.0 Programming Lang: Puppet Description : Puppet module for unbound 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. . puppet-unbound installs and configure Unbound.
Bug#1006965: ITP: python-datetimerange -- library that handles time ranges
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: python-datetimerange Version : 1.2.0 Upstream Author : Tsuyoshi Hombashi * URL : https://github.com/thombashi/DateTimeRange * License : Expat Programming Lang: Python Description : library that handles time ranges DateTimeRange is a Python library to handle a time range. e.g. check whether a time is within the time range, get the intersection of time ranges, truncating a time range, iterate through a time range, and so forth. Note: This is a new (direct) dependency of OpenStack Rating (cloudkitty).
Bug#1006964: ITP: python-typepy -- library for variable type checker/validator/converter at a run time
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: python-typepy Version : 1.3.0 Upstream Author : Tsuyoshi Hombashi * URL : https://github.com/thombashi/typepy * License : Expat Programming Lang: Python Description : library for variable type checker/validator/converter at a run time Typepy is a Python library for variable type checker/validator/converter at a run time. . Feature: * checking a value type * validate a value for a type * convert a value from a type to the other type Note: this is a new indirect dependency for Cloudkitty.
Bug#1006963: ITP: python-mbstrdecoder -- multi-byte character string decoder
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: python-mbstrdecoder Version : 1.1.0 Upstream Author : Tsuyoshi Hombashi * URL : https://github.com/thombashi/mbstrdecoder * License : Expat Programming Lang: Python Description : multi-byte character string decoder Mbstrdecoder is a Python library for multi-byte character string decoder. Note: This is a new indirect dependency for Cloudkitty (OpenStack rating).
Re: access forbiden salsa.debian.org
On 3/1/22 14:24, Jonathan Carter wrote: Hi Phil (and everyone) On 2022/03/01 15:10, Philip Wyett wrote: Thank you for the terse response. The two examples i.e. micronews and the infra list do not sound that this is scheduled work at all. Better communication from teams would possibly give better understanding and the patience of users/developers that is being asked for. Our GitLab instance (Salsa), have fallen behind multiple versions. This is due to a bunch of different hurdles that all came with their own decisions (I'm going to urge the Salsa admins again to do a write-up about it). So what's happening now is point-to-point upgrades between all the GitLab versions needed on this upgrade path, along with the migrations between them (which are quite large, Salsa is one of the biggest GitLab instances out there). So while a huge amount of pent up maintenance is all happening at once now, at least regular updates (and security updates) will be able to run again on short cycles. (I hope salsa admins don't mind me posting this, but I hope it helps all our contributors better understand what's going on). On a practical note, please take note of any uploads you do during this downtime, and be sure to do a git push along with the tags when Salsa is back up again. -Jonathan Like everyone, I am thankful for the volunteer time given by the Salsa admins, and it feels great to know Salsa is fully updated. While I very much appreciate the work, and understand the pain behind migrating a huge db, I'd say the communication could be perfected. The initial announcement explained none of the above, and the list archive storing the announcement was down (because the list archive needed Salsa to run). People even outside of Debian (like some managing the Kolla OpenStack CI that uses Debian and extrepo) were affected. They asked me multiple times what was going on, and it was painful to be annoying asking on IRC (sorry guys, and thank you formorer and pabs for replying), and then relaying the small amount of info I could gather. A status page (anywhere) would have help a lot (not everyone knows how to read the topic on the #salsa channel). BTW, is there a public status page for the Debian infra monitoring? Cheers, Thomas Goirand (zigo)
Re: Is removing smell from packages OK? (Was: Why? "Marked for autoremoval on 24 March due to xdelta3: #965883")
On 2/25/22 11:38, Philip Hands wrote: Having looked at how it was done, I applaud Andreas for doing a proper job. +1 Anyone complaining about this kind of contribution to Debian is a moron and a barrier to progress. We really need to get rid of this toxic mentality in Debian. Jonas, I strongly disagree with using this type of example like you just did in this thread. In many cases, switching from long-form dh to short form is by the way a very nice improvement (if the result is obviously very minimal, as opposed to a very verbosy-for-nothing long form, for example). Though you've decided to take the extreme example when one is strongly opposed to short-form dh, because of "packaging style". So IMO, your reply is inappropriate, we should only give encouragements to Andreas, and welcome progress. Cheers, Thomas Goirand (zigo)
Bug#1004899: ITP: numberstation -- TOTP Authenticator application
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: numberstation Version : 1.0.1 Upstream Author : Martijn Braam * URL : https://git.sr.ht/~martijnbraam/numberstation * License : LGPL-3 Programming Lang: C, Python Description : TOTP Authenticator application A Gnome Authenticator clone. This generates 2fa tokens based on secrets installed. It registers as uri-handler for otpauth:// urls so they can be added from Megapixels.
Re: Cloud team plans for cloud-hosted mirrors
On 1/26/22 10:04, Marc Haber wrote: On Tue, 25 Jan 2022 22:38:00 -0800, Ross Vandegrift wrote: On Wed, Jan 26, 2022 at 07:25:18AM +0100, Marc Haber wrote: On Tue, 25 Jan 2022 21:47:49 -0800, Ross Vandegrift wrote: The cloud team wants to make folks aware of a possible change to the cloud images. The team plans to register a new domain, debian.cloud, for mirrors inside of cloud provider infrastructure. For such mirrors, sources.list will look like: deb http://.debian.cloud/debian/ bullseye main Are the IP ranges of the Cloud Providers registered that badly that deb.debian.org wouldn't reliably point to the mirrors inside the provider's infrastructure? Or are the cloud providers' mirrors differnet from what we expect from a Debian mirror? deb.debian.org is served from fastly and AWS CDNs - so it's outside of most cloud provider's infrastructure. So it is not possible to hook arbitrary mirrors into deb.debian.org and we're dependent on Fastly and AWS here? Correct. Cheers, Thomas Goirand (zigo)
Bug#1004291: ITP: php-dapphp-radius -- pure PHP RADIUS client based on the SysCo/al implementation
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: php-dapphp-radius Version : 2.5.6 Upstream Author : Drew Phillips * URL : https://github.com/dapphp/radius/ * License : LGPL-3 Programming Lang: PHP Description : pure PHP RADIUS client based on the SysCo/al implementation Dapphp\Radius is a pure PHP RADIUS client for authenticating users against a RADIUS server in PHP. It currently supports basic RADIUS auth using PAP, CHAP (MD5), MSCHAP v1, and EAP-MSCHAP v2. The current 2.5.x branch is tested to work with Microsoft Windows Server 2012 to 2019 Network Policy Server and FreeRADIUS 2 and above. . PAP authentication has been tested on: * Microsoft Radius server IAS * Mideye RADIUS Server * Radl * RSA SecurID * VASCO Middleware 3.0 server * WinRadius * ZyXEL ZyWALL OTP . The PHP openssl extension is required if using MSCHAP v1 or v2. For older PHP versions that have mcrypt without openssl support, then mcrypt is used. Note: This package is to replace the gap left with php-radius removal. I intend to use that in OCI (OpenStack cluster installer) if php-radius PECL extension is not available, which hopefully makes it possible to keep Radius auth in OCI.
Re: The future of src:ntp
On 1/19/22 20:34, Richard Laager wrote: For people that want something more than systemd-timesyncd, e.g. to get NTS, I think either are acceptable choices. It seems that the consensus for new installs is towards chrony over ntpsec. But I don't think we as the distro need to push either over systemd-timesyncd. For people who don't care, systemd-timesyncd should be fine. Do you disagree on that point (that systemd-timesyncd is fine for people who don't care about NTP)? If so, can you elaborate? Well, could you elaborate why you didn't write "chrony is fine for people who don't care"? I fail to understand why you're having a preference on systemd-timesyncd... Cheers, Thomas Goirand (zigo)
Re: The future of src:ntp
On 1/17/22 21:13, Marco d'Itri wrote: On Jan 17, Bernhard Schmidt wrote: What do you think? chrony is MUCH better since Debian 10, I agree that it should be the preferred NTP client for when systemd-timesyncd is not enough. You can definitely spend your time on something more fun and more useful. +1 "chronyc tracking" r0x! :) Thomas Goirand (zigo)
Bug#1003442: ITP: refstack-client -- OpenStack platform validation client
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: refstack-client Version : 0.0.0~2021.08.18.fa73ef2524 Upstream Author : OpenStack Foundation * URL : https://opendev.org/openinfra/refstack-client * License : Apache-2.0 Programming Lang: Python Description : OpenStack platform validation client Refstack-client is a command line utility that allows you to execute Tempest test runs based on configurations you specify. When finished running Tempest it can send the passed test data to a RefStack API server.
Bug#1003441: ITP: python-tempestconf -- automatic tempest configuration
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: python-tempestconf Version : 2.1.0 Upstream Author : OpenStack Foundation * URL : https://opendev.org/openinfra/python-tempestconf * License : Apache-2.0 Programming Lang: Python Description : automatic tempest configuration python-tempestconf will automatically generate the tempest configuration based on your cloud. Note: This is an indirect dependency for refstack-client, which is a tool to validate an OpenStack deployment that I'm also going to package.
