Bug#1063633: ITP: python-autodocsumm -- API that automatically extends sphinx
Package: wnpp Severity: wishlist Owner: "Marcos Rodrigues de Carvalho (aka oday)" X-Debbugs-Cc: debian-devel@lists.debian.org, marcosrcarvalh...@gmail.com * Package name: python-autodocsumm Version : 0.2.12 Upstream Contact: Philipp S. Sommer * URL : https://github.com/Chilipp/autodocsumm/ * License : apache-2.0 Programming Lang: Python Description : API that automatically extends sphinx The Python autodocsumm module is a tool that helps developers write documentation for their Python programs in an easier and faster way. It does this automatically, creating summaries or "shortcuts" to the important parts of the code, such as functions and methods. . The module is capable of: - automatically create summaries - produces explanatory comments - customize summaries with extra details - Allows Integration with Other Tools
Re: Changes to abi=+time64 behavior (was Re: 64-bit time_t transition in progress)
So when introducing a new soname (no just a new package name), then one should move to time64 even on i386 ? The problem with doing this is that 1. A reverse dependency may depend on more than one library that uses time_t in it's API. Said reverse dependency would not be able to be sanely built if libfoo uses 32-bit time_t in it's API and libbar uses 64-bit time_t in it's API. 2. If any of your reverse dependencies are libraries that expose time_t in their API they would have a similar problem.
Bug#1063628: ITP: python-command-runner -- a platform-agnostic external command execution library for python with extra goodies
Package: wnpp Severity: wishlist Owner: Harlan Lieberman-Berg X-Debbugs-Cc: debian-devel@lists.debian.org, an...@beanfield.com, hlieber...@debian.org * Package name: python-command-runner Version : 1.6.0 Upstream Contact: Orsiris de Jong * URL : https://github.com/netinvent/command_runner * License : BSD-3-clause Programming Lang: Python 3 Description : a platform-agnostic external command execution library for python command_runner's purpose is to run external commands from python, just like subprocess on which it relies, while solving various problems a developer may face among: - Handling of all possible subprocess.popen / subprocess.check_output scenarios / python versions in one handy function without encoding / timeout hassle - Allow stdout/stderr stream output to be redirected to callback functions / output queues / files so you get to handle output in your application while commands are running - Callback to optional stop check so we can stop execution from outside command_runner - Callback with optional process information so we get to control the process from outside command_runner - Callback once we're finished to ease thread usage - Optional process priority and io_priority settings - System agnostic functionality, the developer shouldn't carry the burden of Windows & Linux differences - Optional Windows UAC elevation module compatible with CPython, PyInstaller & Nuitka - Optional Linux sudo elevation compatible with CPython, PyInstaller & Nuitka My plan is to maintain this package under the auspices of the Debian Python Team. I am packaging this module in part because it is a direct dependency of LibreNMS, though I don't currently have plans to package that. Sincerely, -- Harlan Lieberman-Berg ~hlieberman
Bug#1063612: ITP: corrosion -- Tool for integrating rust with an existing CMake project
Package: wnpp Severity: wishlist Owner: Nilesh Patra X-Debbugs-Cc: debian-devel@lists.debian.org, nil...@debian.org * Package name: corrosion Version : 0.4.7 Upstream Contact: Andrew Gaspar * URL : https://github.com/corrosion-rs/corrosion * License : MIT Programming Lang: C++ Description : Tool for integrating rust with an existing CMake project Corrosion, formerly known as cmake-cargo, is a tool for integrating Rust into an existing CMake project. . Corrosion can automatically import executables, static libraries, and dynamic libraries from a workspace or package manifest (Cargo.toml file). Needed for angelfish to manage it easily. This will be maintained in the debian namespace.
Bug#1063591: ITP: anew -- Tool for adding new lines to files, skipping duplicates (program)
Package: wnpp Severity: wishlist Owner: "Marcos Rodrigues de Carvalho (aka oday)" X-Debbugs-Cc: debian-devel@lists.debian.org, debian...@lists.debian.org , marcosrcarvalh...@gmail.com * Package name: anew Version : 0.1-1 Upstream Contact: Tom Hudson * URL : https://github.com/tomnomnom/anew * License : Expat Programming Lang: Go Description : Tool for adding new lines to files, skipping duplicates (program) This program provides a tool for adding new lines to files while ensuring that duplicate lines are skipped. It offers a convenient solution for managing text files by preventing redundant data. The tool is designed to streamline file editing processes and improve efficiency when working with large datasets or configuration files. It can be useful in various scenarios, such as log management, data processing, and configuration management tasks.
Can we switch off the testing removal messages related to t64 migration? (Was: Confusion over t64 migration)
Hi, Am Fri, Feb 09, 2024 at 06:46:58PM +0100 schrieb Andreas Metzler: > Looking at "your" bug #1062097 it looks like you were unlucky, mine all > had a fat warning "NOTICE: these changes must not be uploaded to > unstable yet!". I also was trapping into that pitfall when I was intending to fix an RC bug quickly and simply failed to read the whole message. Just happens and was reverted soon. > There was a little bit of discussion about the delay on > https://lists.debian.org/debian-release/2024/02/msg00272.html but it > has not yielded a plan yet. I perfectly understand that complex things might lead to delays. However, given that I'm in several teams with lots of libraries my mailbox gets filled with lots of messages about testing removals which are absolutely useless since I can't do anything about this. I wonder how we can get rid of these messages. Two things come into my mind: 1. Demote severity of the time_t related bugs to non-RC 2. Patch the script that sends testing removal warnings to ignore time_t related bugs It would be very convinient if this could be solved. Currently I simply remove all mails containing the pattern "testing removal" since I can't handle the current amount sensibly. Unfortunately that way I'm missing perfectly valid messages caused by "real" RC bugs. Just using the chance to thank all people working on time_t transition and release team for the generally helpful mails Andreas. -- http://fam-tille.de
Re: Confusion over t64 migration
On 2024-02-09 John Goerzen wrote: [...] > So at the moment, I am unclear why there are bugs filed with severity > serious that apparently cannot be fixed. Shouldn't they be normal with > a tag wontfix until the relevant dpkg changes are in unstable? > To put it another way, I'm not seeing why we are reporting RC bugs > against a bunch of packages before it is possible to fix them. [...] Hello John, Afaiui the transition has been delayed unexpectly. (#1063329). I *think* the priority was also chosen as signal to avoid unstable uploads for the already staged packages. Stuff should have happened quickly, before we entered the autoremoval timer. Looking at "your" bug #1062097 it looks like you were unlucky, mine all had a fat warning "NOTICE: these changes must not be uploaded to unstable yet!". There was a little bit of discussion about the delay on https://lists.debian.org/debian-release/2024/02/msg00272.html but it has not yielded a plan yet. cu Andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure'
Re: Changes to abi=+time64 behavior (was Re: 64-bit time_t transition in progress)
On Fri, Feb 09, 2024 at 05:36:53PM +0100, Ansgar wrote: > Hi, > > On Fri, 2024-02-09 at 15:24 +, Bill Allombert wrote: > > when introducing a new soname (no just a new package name), then one > > should move to time64 even on i386 ? > > If you know all consumers of the package will be using appropriate > compiler flags to get 64-bit time_t, then this is fine. > > Otherwise provider and consumer would disagree about ABI and likely not > work fully correct. > > > But fundamentally, how do we know how third-party binaries are > > compiled ? > > They have to use `dpkg-buildflags` with equivalent ABI settings. Third-party binaries might not be build on a Debian-based distro... Cheers, -- Bill. Imagine a large red swirl here.
Re: Changes to abi=+time64 behavior (was Re: 64-bit time_t transition in progress)
Hi, On Fri, 2024-02-09 at 15:24 +, Bill Allombert wrote: > when introducing a new soname (no just a new package name), then one > should move to time64 even on i386 ? If you know all consumers of the package will be using appropriate compiler flags to get 64-bit time_t, then this is fine. Otherwise provider and consumer would disagree about ABI and likely not work fully correct. > But fundamentally, how do we know how third-party binaries are > compiled ? They have to use `dpkg-buildflags` with equivalent ABI settings. Ansgar
Confusion over t64 migration
Hi everyone, Thanks to all that have put so much time and thought into the time_t migration. I am late to this party and am trying to figure my way through it. Quite a few of my packages are marked for removal from testing because time_t migration bugs have been filed with severity serious. Some of these are filed against my own packages, but most are filed against other packages which are dependencies of ones I maintain. I am an uploader for gensio, which had a bug #1062097 reported for this issue. Like the others, it was reported as severity serious, tagged found in the version in unstable. This, of course, prevents migrations to testing and also leads to removals from testing. I uploaded a package with the enclosed patch quickly, but then was told that was not the right thing to do. I then uploaded a new version of gensio with the change removed... but again (and I'm not even sure how this is the case, since the bug was resolved) it is marked for autoremoval from testing. So at the moment, I am unclear why there are bugs filed with severity serious that apparently cannot be fixed. Shouldn't they be normal with a tag wontfix until the relevant dpkg changes are in unstable? To put it another way, I'm not seeing why we are reporting RC bugs against a bunch of packages before it is possible to fix them. A key use case for me is uploading to bookworm-backports. Of course, that requires being in testing first. What will happen with time_t in bookworm-backports? Thanks! - John
Re: Changes to abi=+time64 behavior (was Re: 64-bit time_t transition in progress)
On Fri, 09 Feb 2024 at 15:24:50 +, Bill Allombert wrote: > But fundamentally, how do we know how third-party binaries > are compiled ? We don't, but we can make some inferences. If they are i386 binaries that already worked on Debian 12 or older, and they call into time_t-sensitive ABIs (for instance X509_cmp_time() in OpenSSL might be a good example), then they must have been compiled with the expectation that time_t was 32-bit, because that's the ABI that Debian 12 provided. If they didn't already work on Debian 12 or older, then it isn't a regression that they also don't work on Debian 13. smcv
Re: Changes to abi=+time64 behavior (was Re: 64-bit time_t transition in progress)
Le Fri, Feb 09, 2024 at 10:20:40AM +, Simon McVittie a écrit : > On Fri, 09 Feb 2024 at 05:03:23 +0100, Guillem Jover wrote: > > if the maintainer > > has requested it explicitly via DEB_BUILD_OPTIONS=abi=+time64, then > > it should enable it also on i386 (changed behavior). > > > > The reason is that this does not now break ABI for any package (in Debian > > or out of Debian) that might have already opted-in to that feature, it > > does not require adding all the necessary flags manually if one wants > > to opt-in on i386, and makes it possible to selectively enable time64 > > on [non-library] packages where the binary backwards compatibility make > > no sense > > I think this is a good improvement. Another advantage of this change is > that libraries that use time_t internally, but have been confirmed not to > break ABI when it's enabled and don't call time_t APIs in their non-glibc > dependencies, can easily opt-in to enabling it on i386 too. Some do this > upstream already (like dbus and libsdl3 in experimental) but many don't. > > To put this another way, the argument for not doing the transition to > time64-everywhere on i386 was "we don't want to break third-party i386 > binaries", but ideally we should still be enabling time64, even on i386, > in the cases where it *won't* break third-party binaries. So when introducing a new soname (no just a new package name), then one should move to time64 even on i386 ? But fundamentally, how do we know how third-party binaries are compiled ? Cheers, -- Bill. Imagine a large red swirl here.
Bug#1063532: ITP: ford -- Fortran Documentation tool
Package: wnpp Severity: wishlist Owner: Alastair McKinstry X-Debbugs-Cc: debian-devel@lists.debian.org, debian-scie...@lists.debian.org * Package name: ford Version : 7.0.5 Upstream Contact: Christopher MacMackin * URL : https://github.com/Fortran-FOSS-Programmers/ford * License : GPL Programming Lang: Python Description : Fortran Documentation tool The goal of FORD is to be able to reliably produce documentation for modern Fortran software which is informative and nice to look at. The documentation should be easy to write and non-obtrusive within the code. While it will never be as feature-rich as Doxygen, hopefully FORD will be able to provide a good alternative for documenting Fortran projects. Ford is already used (if present) by several projects packaged in Debian. I intend to manage it in Salsa; perhaps in Debian-Science team.
Bug#1063521: ITP: pymbolic -- Easy Expression Trees and Term Rewriting library
Package: wnpp Severity: wishlist Owner: Alastair McKinstry X-Debbugs-Cc: debian-devel@lists.debian.org, debian-pyt...@lists.debian.org * Package name: pymbolic Version : 2022.2 Upstream Contact: Andreas Klöckner * URL : https://github.com/inducer/pymbolic * License : MIT/X Programming Lang: Python Description : Easy Expression Trees and Term Rewriting library I am packaging this as Pymbolic is a small expression tree and symbolic manipulation library. Two things set it apart from other libraries of its kind: * Users can easily write their own symbolic operations, simply by deriving from the builtin visitor classes. * Users can easily add their own symbolic entities to do calculations with. Pymbolic currently understands regular arithmetic expressions, derivatives, sparse polynomials, fractions, term substitution, expansion. It automatically performs constant folding, and it can compile its expressions into Python bytecode for fast(er) execution. It is not expected to be a replacement for Sympy, which is more complex.
Bug#1063520: ITP: codetiming -- A Timer package for Python code
Package: wnpp Severity: wishlist Owner: Alastair McKinstry X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: codetiming Version : 1.4.0 Upstream Contact: David Beazley * URL : https://pypi.python.org/pypi/codetiming * License : MIT Programming Lang: Python Description : A Timer package for Python code This is a dependency of loki-ecmwf, already submitted. It is a simple timer class for Python.
Bug#1063517: ITP: adios4dolfinx -- ADIOS2Wrappers for DOLFINx
Package: wnpp Severity: wishlist Owner: Francesco Ballarin X-Debbugs-Cc: debian-devel@lists.debian.org, debian-scie...@lists.debian.org, francesco.balla...@unicatt.it * Package name: adios4dolfinx Version : 0.7.3 Upstream Contact: Jørgen S. Dokken * URL : http://jsdokken.com/adios4dolfinx/ * License : MIT Programming Lang: Python Description : ADIOS2Wrappers for DOLFINx adios4dolfinx is an extension for DOLFINx to checkpoint meshes, meshtags and functions using ADIOS2. The code uses the adios2 Python-wrappers to write DOLFINx objects to file, supporting N-to-M (recoverable) and N-to-N (snapshot) checkpointing. For scalability, the code uses MPI Neighbourhood collectives for communication across processes. The package will be maintained within the Debian Science team, in collaboration with Drew Parsons.
Re: Changes to abi=+time64 behavior (was Re: 64-bit time_t transition in progress)
On Fri, 09 Feb 2024 at 05:03:23 +0100, Guillem Jover wrote: > if the maintainer > has requested it explicitly via DEB_BUILD_OPTIONS=abi=+time64, then > it should enable it also on i386 (changed behavior). > > The reason is that this does not now break ABI for any package (in Debian > or out of Debian) that might have already opted-in to that feature, it > does not require adding all the necessary flags manually if one wants > to opt-in on i386, and makes it possible to selectively enable time64 > on [non-library] packages where the binary backwards compatibility make > no sense I think this is a good improvement. Another advantage of this change is that libraries that use time_t internally, but have been confirmed not to break ABI when it's enabled and don't call time_t APIs in their non-glibc dependencies, can easily opt-in to enabling it on i386 too. Some do this upstream already (like dbus and libsdl3 in experimental) but many don't. To put this another way, the argument for not doing the transition to time64-everywhere on i386 was "we don't want to break third-party i386 binaries", but ideally we should still be enabling time64, even on i386, in the cases where it *won't* break third-party binaries. smcv
Re: Transparency into private keys of Debian
Hans-Christoph Steiner writes: >> In business, such things are confirmed (often badly) by independent >> audit. For a volunteer-driven community effort, we have to rely on >> everyone to exercise their best judgement in these sorts of matters. > > Debian could also get independent, professional audits. I think it > would be a good use of the Debian pot of money, for example. Or > someone could submit a proposal to get Debian audited. I'll be either > Open Tech Fund or NLnet would do it: > > https://www.opentech.fund/labs/red-team-lab/ > > Open Tech Fund already funds Tails, which is based on Debian. That would be useful for the important keys like the apt release keys, and would set an example for others to follow. If there are things to improve, it would be better if we know about them than allowing attackers to find out on their own. For DD keys, as Jemery noticed, I don't think it is useful: uses of DD keys leave a quite auditable flow already. /Simon signature.asc Description: PGP signature
