Re: [RFH] Running Python tests that require the source to be installed
Hi Adrian,
* John Paul Adrian Glaubitz
* [2024-10-24 13:11]:
I had to look it up and the mechanism used is called
"entry_points". The kiwi package adds such entry_points and wants
to test them in its testsuite.
Thus, I need to figure out how to make those entry_points visible
from the build environment so that the testsuite can find and test
them.
Is there any other Debian Python package that uses entry points?
I ran into this issue with old-style setuptools packages (i.e.,
packages with a setup.py); AFAIK the entry_points mechanism needs
valid egg-info or dist-info metadata in the PYTHONPATH. My
workaround was
export PYBUILD_BEFORE_TEST=\
{interpreter} setup.py egg_info; \
cp -r {dir}/src/*.egg-info {build_dir}
export PYBUILD_AFTER_TEST=\
rm -r {dir}/src/*.egg-info {build_dir}/*.egg-info
Cheers
Timo
--
⢀⣴⠾⠻⢶⣦⠀ ╭╮
⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │
⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │
⠈⠳⣄ ╰╯
signature.asc
Description: PGP signature
Re: BuildProfileSpec example equivalence question
Hi Josch, * Johannes Schauer Marin Rodrigues [2024-10-16 * 09:21]: The third example on https://wiki.debian.org/BuildProfileSpec is: I now changed the example to one that is actually used in the wild. I hope I didn't mess up the wording. Hope this makes things clearer. The final sentence in the explanation states that the build profile restrictions are a conjunctive normal form expression; is that actually correct? Because CNF would be the AND'ing of OR's, but if I understand it correctly, the terms *inside* the angle brackets are AND'ed and the brackets themselves OR'd, which makes it a DNF, *disjunctive* normal form. Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭────╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Bug#1083119: ITP: papilo -- Parallel Presolve for Integer and Linear Optimization
Package: wnpp Severity: wishlist Owner: Timo Röhling X-Debbugs-Cc: debian-devel@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: papilo Version : 2.3.0 Upstream Author : Zuse Institute Berlin (ZIB) * URL : https://github.com/scipopt/papilo * License : LGPL-3+, BSL-1, Zlib, Apache-2, BSD-3-clause, Expat Programming Lang: Python, C, C++ Description : Parallel Presolve for Integer and Linear Optimization PaPILO, a C++14-based software package, provides parallel presolve routines for (mixed integer) linear programming problems. The routines are implemented using templates which allows switching to higher precision or rational arithmetic using the boost multiprecision package. The package will be team-maintained under the umbrella of the Debian Math Team at https://salsa.debian.org/math-team/papilo -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEmwPruYMA35fCsSO/zIxr3RQD9MoFAmb8fO4ACgkQzIxr3RQD 9Mr0Wg/+KBhlTlB4Kqp94bz2rbpU9C3ealKPLz0ER2SB9dVGDdTjEhwd6HzvXHlp a5xp/QkhrbwmtBbf7nA1fVcuAlvNLraRbhO9wqCdFtppB3U1WFDKVmJxrMbw3DFo q0JNyS3bUAVdC3u++23u90Pkyt8SatuvJhzwsT9bsGxtvlbNuRqVlyNAYyPKvJ7A N6dXj/DC4bUkMGXaKEOKbhinUDpmoQPO6byVMQBDqLTL5HePHnld9iwLINrEAXf5 8ZfFLqgwMuQCIlXEFly1CLI7yBCHb6pXdRKA91ckAJlYuvB34aonxYt8xIZ/+T2J sB6SMnUp0wNbNzl9ieFRmS5rILEt6MLNxlKLWuYGA4vjtQGn62VC8c4oLGn0EpvN Nhi+Jb6N62fanphrZKLswZNrXm1amVzeKxj2icmYlvXTwFN4StNRWv4hnV/1ngKK Cr2SI1oeRJmRQbbljkarJUhBDenpUlP8tTxxuva7o5TW54QWvOpDq9TZ7rX8SU+W ql2pciVvjC4tf/d59NJ4PYRShqGxLSefWfw6OBxbSAQGwtu1LvauBU/DBR53aVQZ UbyrSRj32B7sBQiuK6rjyAt6swojQGxEXtKg3U17LybnPzN9fgKSqpUIKZrWq0VW V6JAvD5hBSiPuSu5Q7GdD9xwgKqzIfD3vHGtPoIeaBU2Ew755TA= =XIGK -END PGP SIGNATURE-
Re: Strange armel build error
Hi Alec, * Alec Leamas [2024-08-16 17:46]: /usr/include/c++/14/bits/atomic_futex.h:278:(.text+0x16dc): undefined reference to `std::__atomic_futex_unsigned_base::_M_futex_notify_all(unsigned int*)' /usr/bin/ld: /usr/include/c++/14/bits/atomic_futex.h:278:(.text+0x29d8): undefined reference to `std::__atomic_futex_unsigned_base::_M_futex_notify_all(unsigned int*) AFAIK the armel architecture has no lock-free atomic primitives, so you probably need to link against the atomic library because opencpn uses std::atomic somewhere in its codebase. Try adding export DEB_CXXFLAGS_MAINT_APPEND += -latomic to your debian/rules. Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Re: BIMI verified email logo for @debian.org addresses
* gregor herrmann [2024-06-27 14:50]: Hanno also gave a talk at the MiniDebConf in Berlin earlier this year: https://berlin2024.mini.debconf.org/talks/17-breaking-dkim-and-bimi-with-the-2008-debian-openssl-bug/ Video at https://meetings-archive.debian.net/pub/debian-meetings/2024/MiniDebConf-Berlin/ TL;DW: 26:02 to 26:20 https://laotzu.ftp.acc.umu.se/pub/debian-meetings/2024/MiniDebConf-Berlin/33-breaking-dkim-and-bimi-with-the-2008-debian-openssl-bug.lq.webm#t=1562,1580 -- ⢀⣴⠾⠻⢶⣦⠀ ╭╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Bug#1072781: ITP: python-cmake-build-extension -- Setuptools extension to build and package CMake projects
Package: wnpp Severity: wishlist Owner: Timo Röhling X-Debbugs-Cc: debian-devel@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: python-cmake-build-extension Version : 0.6.0 Upstream Author : Diego Ferigo * URL : https://github.com/diegoferigo/cmake-build-extension * License : BSD-3-clause, Expat Programming Lang: Python, C++ Description : Setuptools extension to build and package CMake projects This extension aims to simplify the integration of C++ projects based on CMake with Python packaging tools. CMake provides out-of-the-box support to either SWIG and pybind11, that are two among the most used projects to create Python bindings from C++ sources. If you have any experience with these hybrid projects, you know the challenges to make packaging right! This project takes inspiration from pre-existing examples (pybind/cmake_example, among many others) and provides a simple, flexible, and reusable setuptools extension with the following features: * Bridge between CMake projects and Python packaging * Configure and build the CMake project from setup.py * Install the CMake project in the resulting Python package * Allow passing custom CMake options * Allow creating a top-level __init__.py * Expose C++ executables to the Python environment * Provide a context manager to import CPython modules reliably on all major OSs * Disable the C++ extension in editable installations (requiring to manually call CMake to install the C++ project) The package will be team-maintained under the umbrella of the Debian Python Team at https://salsa.debian.org/python-team/packages/cmake-build-extension -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEmwPruYMA35fCsSO/zIxr3RQD9MoFAmZjY4YACgkQzIxr3RQD 9MqGvg//VlaEUgFyHvAoIv37IPVMvDRj3nUt+IO210T0sSeqowswdQC/qVPz2wj4 nk2WXEfjgPUO98caa/YYKjHCW68rg9KgAFu+Ypiizu5Tw5xQ4SFIf5gbonBqetSw acqmGzZPhh9VsI1cRICsRFsO8JDdZ6HNVbliWqRaFd3nQJFiLxeCh/5Rw5XxEmQU f86h23XdeMi9N/qiRhTNQsYIoxvXSpCvJLsn+u+yt7Xizz1k2ufGMHKJPe8EuO6F Mkh8hYLfCPugDpy6TGB/DCpxs4f7IG1/oUZBCWqRDGzK3uwyUrLFK6DRrMLigURT sqbhT/XzHn+4d8j/kGp1ZnV8Wm92W3gl3DPI6hRyM6qS8fmYiROU8F+eNDZJs8fk 6QxCQroesk6lJ9Be5Zx2DTvosAY2p9/ythUPXr+y44CBcu7MyZuHU1C3aeVVPDPx wOFPob8/ePLAM+vfVX7bgROt6ggwK9tEGwrjwtadtbSslIs/F1g54ScNfmqB1Zfm whubrSpbupFatEospoz9K6owVenVb4XDb2XCs9DPrsDnEr8iIpE9GxcV6JliAsPU 3+Xm8fjM0WGqJ+c/AhcUL7G0ff9CvkyDA5t+0qOt+7Jifpx4u+WASRh1F6tYsJa/ U6POUN7T9VpLrYdqu2m8Ld17XYWLFfqmbQfuePrcak2plipiDBU= =zIQr -END PGP SIGNATURE-
Bug#1072738: ITP: manif -- Lie theory library for state estimation
Package: wnpp Severity: wishlist Owner: Timo Röhling X-Debbugs-Cc: debian-devel@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: manif Version : 0.0.4 Upstream Author : Jeremie Deray * URL : https://github.com/artivis/manif * License : BSD-2-clause, CC0, Expat Programming Lang: Python, C++ Description : Lie theory library for state estimation manif is a Lie theory library for state estimation targeted at robotics applications. It is developed as a header-only C++11 library with Python 3 wrappers. The package will be team-maintained under the umbrella of the Debian Robotics Team at https://salsa.debian.org/robotics-team/manif -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEmwPruYMA35fCsSO/zIxr3RQD9MoFAmZi2G8ACgkQzIxr3RQD 9MoEjQ//YlC8VOUto9V5su74dvEwivEoEDv8no2ZtcLvbMRA8dQVU7BwkEYjlyUf EHS9slB3U8etfi5LMPfjVNGsfVwrY9650ULOkf/zTkzPebIjWCx3ufLMRNfdA3MC HQE+k4ihk2jemFv7DHrUe8zuGbaN0Ka9g16xWpU/MakN0x6bUB2dWseVdFS63ldP H74wqVLFKq/91Ka9LkAB/g0mLKy5UOuMNDpuVeJ6wL4nQkNhPi2j0JKAJDjvvCXf /OO+LYmSBdhMQZqak7jf1pxhZXeP/eDQHOs3K2enZ08/A0/DX+BBgQeCgFG7fLcG rTpAfJ1Pxds6EkCuLhMj4x68MAb/R0lvJXo5XozizOQ3RGxGeVDd0B3SZT+RF1Ef ZZjdHdYq/wQCE8MnWy3OEmGj+5e0yh77l7f8lOss/T6jvUyyBEDQLcuZ5BKSoGCf bGOHqIzRAULy3EkcZBU3iJ2VIRDuzsA0DPIomIYmcA5npbWIcTT7TGEKjz+EFM5q WrLGvrqugY1hYFx7thP+Sp3IMraktbNDQedIvxfZLaI17bEVBWJITwsScurK7Ife r7YQvDp/YIhz3KPS6TFzbSSL4bHGOBtgos6FKictrFMDLCgaDlnxpXOUtg/8IMps ImvQ61/V10dR0yltO+DeCg7gRt+F+8a91XrQG2fuGn6LMzAf/Ag= =ydle -END PGP SIGNATURE-
Bug#1072684: ITP: tl-optional -- C++11/14/17 std::optional with functional-style extensions
Package: wnpp Severity: wishlist Owner: Timo Röhling X-Debbugs-Cc: debian-devel@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: tl-optional Version : 1.1.0 Upstream Author : Sy Brand * URL : https://github.com/TartanLlama/optional * License : CC0, Expat Programming Lang: C++ Description : C++11/14/17 std::optional with functional-style extensions std::optional is the preferred way to represent an object which may or may not have a value. Unfortunately, chaining together many computations which may or may not produce a value can be verbose, as empty-checking code will be mixed in with the actual programming logic. This implementation provides a number of utilities to make coding with optional cleaner. The package will be maintained by Timo Röhling at https://salsa.debian.org/debian/tl-optional -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEmwPruYMA35fCsSO/zIxr3RQD9MoFAmZhvxUACgkQzIxr3RQD 9Mpxbw//QA6mWkPqESGuOdq0etTY5tKCtfTuDt45ZgI5DnbyVi2nGfJIaVddpe5W smX9YOaW+2YJaXzaP6+BC6deltrQh9I4nq80bnW7BfmAoCILfk3u+KzuPi8EdwN+ R01dTBHmsdeG5yea3E0apazcGOL0reV/R3ZexfmJc04B5DM0Qp8YSAVAzVno/E7u aVQBATb7ccbhVxc90MihFGpTvLNUIhazueLlyAo8Lt3qZ/VuBnUSms+fy61IE7Mz CURNTYO6SrODHHx82i2wqG52GGDxDnEzOZLeIc1JiU1fgTqVsKh4GgY9nrQf3csg 3UPC0+AGVSEUonuQhSF0DOaZODAv0LAxwlVDUDbkIUD5ULwYsXlXq6hbWLTRcUof CA7hrPCFQQu+jQzjldPghxYM9z4XjsCVXSAOTtv35PGJ40wW6/zvmHLPBqp/+EGP YMWF28VG0D4hdbwRg1qJ2h6EnCXieiSqNZkuo6igOw3VVbvvf/R84bt6+lLYu1CH x1Z4vLAyAl+lA5RFkyYIaalf1doQ5Zdd0eopf46UyXRKc81iyuIdH71dj8n0YoDu I2bYfvu4hYBgUDdvJ7kBrIat9xMtkWX1lflcZlH730E6kM0hRm/UgMDwVVPdfMoZ aRaSruBDhEqyWJq90vGbMbIaGa4SuZ7o0A58NOFD2PQGCa4RdkE= =dj3T -END PGP SIGNATURE-
Re: Tool to build Debian packages not requiring root in containers ?
Hi Charles, * Charles Plessy [2024-05-08 07:27]: I want to leverage our cluster to automate as much of the rebuilds as I can, but could not find the right tool. I tried to run sbuild in a Singularity image and this failed. However, I do not need the whole power of engines like sbuild, as none of the packages involved require root priviledges to build. Have you tried the unshare backend for sbuild? It uses Linux namespaces instead of full-blown root privileges, and works really great for my regular packaging work. I have not tried running it inside a virtualization container, though. Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Re: Silent hijacking and stripping records from changelog
Hi, * Jonathan Dowland [2024-04-18 08:35]: Sorry, Jonathan, for being difficult to read here. No problem: Sorry for lapsing in assuming good faith on my part. The way both of you handled this misunderstanding was... exemplary. SCNR Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Re: Validating tarballs against git repositories
Hi, * Simon Josefsson [2024-03-30 12:19]: Relying on signed git tags is not reliable because git is primarily SHA1-based which in 2019 cost $45K to do a collission attack for. FWIW, Gitlab is working on support for SHA 256 hashing [1], and as of Git 2.42, the SHA 256 repository format has matured enough that backwards incompatible breaks are very unlikely [2]. Cheers Timo [1] https://about.gitlab.com/blog/2023/08/28/sha256-support-in-gitaly/ [2] https://lore.kernel.org/lkml/xmqqr0nwp8mv.fsf@gitster.g/ -- ⢀⣴⠾⠻⢶⣦⠀ ╭╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Bug#1058958: ITP: laszip -- Lossless LiDAR compression
Package: wnpp Severity: wishlist Owner: Timo Röhling X-Debbugs-Cc: debian-devel@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: laszip Version : 3.5.0 Upstream Author : Rapidlasso GmbH * URL : https://laszip.org/ * License : BSD-2-clause, BSD-3-clause, Apache-2.0, BSL-1.0 Programming Lang: Python, C, C++ Description : Lossless LiDAR compression LASzip quickly turns bulky LAS files into compact LAZ files without information loss. The package is reintroduced by the Science Team, with consent of the GIS team, the previous maintainers. Among other things, it is needed for the Python LASzip bindings, which in turn enable the optional LASzip support in LASpy. -BEGIN PGP SIGNATURE- iQGzBAEBCgAdFiEEJvtDgpxjkjCIVtam+C8H+466LVkFAmWAvtAACgkQ+C8H+466 LVkcqwwAwetn4chREePE+wrc171arleRn8sVAD6+BH5TKTVDhkwQdqc6p/9Yad3n yZSmZv8oI59pSDqx/7iVtD3KL0y86x/UQL75nC2nfhDAMJ3VDQbcOIhD7G0RxTzE vqE2EsRhogydUlwQdUTaDbZVpdexInww3rXrRpkptczQ4PxwFZZR8frduqHwFO7F pCfWITZb4eA3zavw7DrkGqLv0hojdYLXcth+jtQwuvzqLaJQZdHGA79oSFJV65YL nhxyyVtgImDf8LcogM+KEJ+3Joa+Er8MfE+CQjLep8nwzTwFiPOcLo0GyQaixGNV Wy9+JfFGM0QirQ3zQPFMxO3k0+OqNw3CVyZV5GIISLuoUCAl5a5Bh1KDPCNRDsZU bPeDYwrAr2zjgPY3OZfJH67eyIfVsz0w2hPqV1MsnB2qDUm+LsWrRkdb5kbWh3+0 hILlsyYNrbgdazJs3AL1eqIO/IMyXHQbPgqKNRNDuplTJoMaiHEmo4dY+qHSTuM6 otwGKu9D =2IoO -END PGP SIGNATURE-
Bug#1056619: ITP: soplex -- sequential object-oriented simplex solver
Package: wnpp Severity: wishlist Owner: Timo Röhling X-Debbugs-Cc: debian-devel@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: soplex Version : 6.0.3 Upstream Author : Zuse Institute Berlin (ZIB) * URL : https://github.com/scipopt/soplex * License : Apache-2, LGPL-2.1+, BSD-3-clause Programming Lang: C, C++ Description : sequential object-oriented simplex solver This package is part of the SCIP Optimization Suite. SoPlex is an optimization package for solving linear programming problems (LPs) based on an advanced implementation of the primal and dual revised simplex algorithm. It provides special support for the exact solution of LPs with rational input data. The package will be team-maintained under the umbrella of the Debian Math Team at https://salsa.debian.org/math-team/soplex -BEGIN PGP SIGNATURE- iQGzBAEBCgAdFiEEJvtDgpxjkjCIVtam+C8H+466LVkFAmVfzOsACgkQ+C8H+466 LVnexAwAv47byYfXLrXInUiK/H2iFsLMynDDe6RB4eE/kQ0UJmJ769+ZEIU2PPF0 LyHp7SwlJykCrIgmfFI6RFkfpG0Nxk/V3ZmA6jtYr0qEif19062ykIEfkhueCvPY cr7jLBkYTRWpqOA4Ot9d4dc/ZDzmsWHkKmxD5TbRkppgevxnXsbvbOtPtWeGlOgc G4FKW3O+YyyXE14vc2hrwsQILO7zmTzDBnlZa4HYCCn+CNhhzfkIXACafM8nXERg J+MIpJ+e+VQQXwVhIbP1T4XNS20ARyWLBaKkyDRIsa1ieyK95ajZyL7W/v9yRspp vdoFfCWXVqeqr7rg1qFHYB7cbXY0D+W3zOHzEZgm2DHZc6+Ifc6LsLrvGwrmETKT L8iBRiOwA+UUu9ENPV20pn3jUYl/SR975wFjZzwezEbJcQ+KCFiYZmPAWQYEoyWC lI8b7rsw2NO/PBGInJH4vPxUefbhp1MGGIrDQBsUnvaSQHqABj9KZThB+wJzrC0L NfYRW/iB =h/nn -END PGP SIGNATURE-
Bug#1056212: ITP: sphinxcontrib-moderncmakedomain -- Sphinx domain for Modern CMake
Package: wnpp Severity: wishlist Owner: Timo Röhling X-Debbugs-Cc: debian-devel@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: sphinxcontrib-moderncmakedomain Version : 3.27.0 Upstream Author : Kitware, Inc * URL : https://github.com/scikit-build/moderncmakedomain * License : BSD-3-clause Programming Lang: Python Description : Sphinx domain for Modern CMake This is the stand-alone version of Kitware's Sphinx code to generate the official CMake documentation, taken directly from the CMake sources. The package will be team-maintained under the umbrella of the Debian Python Team at https://salsa.debian.org/python-team/packages/sphinxcontrib-moderncmakedomain -BEGIN PGP SIGNATURE- iQGzBAEBCgAdFiEEJvtDgpxjkjCIVtam+C8H+466LVkFAmVZVuQACgkQ+C8H+466 LVnX1QwApgxr9rEY7qwtK9drW4aDxiSVWcXbl7beYcOdD3AHls0VXAWXK3XLmnlZ QNebR90PtzkhvWvyehJweSYjxE0YAOe/LOYvsfJJOcpKpm8AohnyZPnPlslmaFUI ck9j8GPJXbCEIUyApFxp/X0okDL00MsR5RuBAOVzgFmbZpJDM3ypEO3WmvGWBcZs ZEqwQ2zyDdM8guKi4uCkvWRzOAhHgEj9m1vcudj6KXxwYhuV85V442xQo6WPtFsb 78fhVgfFgjzWBkTrzGD4kCbIVTFUD1MkzmRCOgp4QEBx95nArsVOgZrlkkrmKBsF UV+UFaEB4hfRDQPQLME82q3Dr2+VHzDwTYCpGOOIzGHg+ulFya9LUxcy3/S/bRBn L1jumCoWuntWTjWVaevXxoDShYX2RF/coD0fHRbQsL8oYtrWIP9JGoXJaeyxf8y2 7TpeHHhnza/RzDDDnx6pIlqHBGVKmOidn9yyaBNJjvIx0mnKiEXdSNDGgid3ozIg l+tBHUkp =Z45h -END PGP SIGNATURE-
Bug#1055995: ITP: python-laszip -- Python bindings for LASzip
Package: wnpp Severity: wishlist Owner: Timo Röhling X-Debbugs-Cc: debian-devel@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: python-laszip Version : 0.2.3 Upstream Author : Thomas Montaigu * URL : https://github.com/tmontaigu/laszip-python * License : Expat Programming Lang: Python, C++ Description : Python bindings for LASzip This module provides LASzip bindings in Python, primarily intended for use with laspy. LASzip is a specialized compression for the ASPRS LAS file format to store data from LiDAR sensors much more efficiently. The package will be team-maintained under the umbrella of the Debian Python Team at https://salsa.debian.org/python-team/packages/python-laszip -BEGIN PGP SIGNATURE- iQGzBAEBCgAdFiEEJvtDgpxjkjCIVtam+C8H+466LVkFAmVVGKUACgkQ+C8H+466 LVlGCQwA3K3CGbqHT4sEWWRBkc2KrtTaY2IWbylUQjGaN+JyeEicBvNauYrLf2qy Z69BOoUi2vFc8tQihmH+Ogi2wcENoZ9dtx1GrP89Jfz4rwY++1ylMpr3wjzRMYd+ ulu8rTPdu52GxaFracNMY4trNktP2hO8HpqKCPQ1lWJHGQyc/yASwD1ultV9PsgS cPkAUwXcLyn3qyXzkCfNQEH1wOG69Zizh8dsqFi4ZfHRZ4iQC4X3SbRL3UtylYcr FMu6ZsbZgiv3Y/+OmKbkGKX4kbw+OZU4wPCyhjBRZAR+d0UrNkBVzQkIEqH6rB3A CKsjBdzohOQaeC6hfvyinC9VwWALFOy7HJVb9oY3UbS5gov1aKYoFMS+fhRH8EtB VNLggfgpXKH9XusUE89i9TJR9943WdM2/Y4nu1Djc88GmxmP1R17UedXjmVDmBcc cOAt19eOvvP9AzjTaYGwfquO3erPM+6HmRouX3zZWP+tOOICcwpMvekBX5gQTUWt umj7J766 =V5l9 -END PGP SIGNATURE-
Bug#1055829: ITP: nanobind -- Tiny and efficient C++/Python bindings
Package: wnpp Severity: wishlist Owner: Timo Röhling X-Debbugs-Cc: debian-devel@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: nanobind Version : 1.8.0 Upstream Author : Wenzel Jakob * URL : https://github.com/wjakob/nanobind * License : BSD-3-clause Programming Lang: Python, C++ Description : Tiny and efficient C++/Python bindings nanobind is a small binding library that exposes C++ types in Python and vice versa. It is reminiscent of Boost.Python and pybind11 and uses near-identical syntax. In contrast to these existing tools, nanobind is more efficient: bindings compile in a shorter amount of time, produce smaller binaries, and have better runtime performance. The package will be team-maintained under the umbrella of the Debian Python Team at https://salsa.debian.org/python-team/packages/nanobind -BEGIN PGP SIGNATURE- iQGzBAEBCgAdFiEEJvtDgpxjkjCIVtam+C8H+466LVkFAmVQpFMACgkQ+C8H+466 LVk6/wwAtd3RjzQiYoBeO2WwquWnQWwrNTJj2/IXs+J1GO1u3yoSJjm1fTTNmyGi iYU5zFcMuUizZ2gEChOHUQ+50xcAtTBUAIMYPgDRD6D+vZrtcFTAGk5DbotCZ8i+ +ER+jCdBMJa3et+Cpz2ryhgqM9ZyFRRkNQfya26aOBiacCsR3B0XxBjOg6eiXlQ3 J/hbi2le+7ukp84cwphWVchqXgeEEkyc5IFfBm3P2sTLIr2K8WazcRhOvnc7NczL zdIldu1k8lQ82GyTsUIyBLBbt7yjZeg+8xvj5ww2IWi1kWxIJZI6S4ac8LT03lfV ezpmoNNY0REsvT2ASa03RO+C9wIxCLZ4rnkK/R2CvOXLb0COszfRVowxXsY3tIMm qcq8yz4z4elHGeFkKjeCq7+Ype5F2NLXQ3hHP44DKBzrECdrPC45KNXzX5zigdnU 9Vi2YDdWR8ZWm3M3NF1FMz/XNwIKdPjPLaKuXsh7jFfxeirhbRDQrQ2moSrDMuYW H1boyhwy =tka6 -END PGP SIGNATURE-
Re: Bug#1055198: ITP: lzfse -- LZFSE Compression library
* Andreas Henriksson [2023-11-04 23:03]: I hope I understood you correctly and this now adresses your concerns: https://salsa.debian.org/bananas-team/asahi-fwextract/-/commit/bfbd6f53c2e8721b9457c3a37421280a8a86dbc8 Yes, that looks good! I also like the fallback. Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Re: Bug#1055198: ITP: lzfse -- LZFSE Compression library
Hi, * Andreas Henriksson [2023-11-04 18:05]: I've previously suggested that maybe it would be better to set a debian-specific version (0d?), to avoid the theoretical situation that upstream one day ships a different ABI under the 1 so version. Normally, I would agree, but in this particular case, Fedora already went ahead and used SOVERSION 1 [1], so that version is "burned" and we might just as well use it, too. [1] https://src.fedoraproject.org/rpms/lzfse/blob/rawhide/f/60.patch I would welcome peoples input here on what you think is best from the debian perspective. Obviously we're going to be incompatible with everyone else. I don't think that "incompatible" patch you linked creates much of an issue, because very few (if any) other library consumers will do this rather unusual dlopen() "soft linking" dance (normal linking with e.g. "gcc -llzfse" will automatically use the proper SONAME); besides, it is easy to patch in Debian packages and trivial to work around with "apt install liblzfse-dev" for everyone else. I do have one remark, though: the idea behind SONAME/SOVERSION is that you have a common name for all versions which are binary backwards compatible. Using the full version liblzfse.so.1.0 instead of libltfse.so.1 (i.e., the SONAME) in your patch defeats that purpose: it will only work with the exact version 1.0, but not any (hypothetical) future, backwards-compatible versions. Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭────────╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Bug#1052619: ITP: pydantic-core -- Rust implementation of pydantic core functionality
Package: wnpp Severity: wishlist Owner: Timo Röhling X-Debbugs-Cc: debian-devel@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: pydantic-core Version : 2.9.0 Upstream Author : Samuel Colvin * URL : https://github.com/pydantic/pydantic-core * License : Expat Programming Lang: Python, Rust Description : Rust implementation of pydantic core functionality pydantic uses type hinting (PEP 484) and variable annotation (PEP 526) to validate that untrusted data takes the desired form. There is also support for an extension to dataclasses where the input data is validated. The core library is implemented in Rust and up to seventeen times faster than the original pure Python implementation. This is a new dependency for pydantic 2. The package will probably be team-maintained under the umbrella of the Debian Python Team . -BEGIN PGP SIGNATURE- iQGzBAEBCgAdFiEEJvtDgpxjkjCIVtam+C8H+466LVkFAmURdfQACgkQ+C8H+466 LVkUawwAjCO9wWXpdir5lVlaQa0b5niJ/JGEWC2qg6bZxBELJHyniYlyUtAl+qeb AsySa6hSQ+4nCgQEinCo9JHwwhERlY9MlceVeez4EuP1Xt4udbvx8l9RUUAlUP7b BYxgw8GAWMQsrn+ZCPdv0jjvzjI9u1LOzJqwV8w6E0XpuQTi7ZsqNegKsEg0jfVk NKUGaCyWKvEmhh1rfn7iPO0QGiufbsjp568JCA1LGX/OKL8oXD3LEu+ji9P9gCRq ym6iqrmrRtNH3vIBi29chaQUkEZRQvkzAocWXF5F8Ba6j2B9dMiuNsPT7ylBFGF/ tEbg+9ELAHlV7Ab9yAH2VPM1gpmblOs9rpp0+F+fCfW+raTH3OByXYGgMbyryOeD P+YtP2awBSpQSrS6YGjK83MTPRxrv0UflK6+XL3eDHN7GsMMQuAv4TkA9HX7BDUf 7+JP2urP0gjL4sdkRtZncHQWhEIc2HWHGUW3OAlJEClMyu/HVslomsEcS8zxKIUk UCc5c91X =J7bx -END PGP SIGNATURE-
Re: What licenses should be included in /usr/share/common-licenses?
* Russ Allbery [2023-09-10 09:16]: In order to structure the discussion and prod people into thinking about the implications, I will make the following straw man proposal. This is what I would do if the decision was entirely up to me: Licenses will be included in common-licenses if they meet all of the following criteria: * The license is DFSG-free. * Exactly the same license wording is used by all works covered by it. * The license applies to at least 100 source packages in Debian. * The license text is longer than 25 lines. In the thread so far, there's been a bit of early convergence around my threshold of 100 packages above. I want to make sure people realize that this is a very conservative threshold that would mean saying no to most new license inclusion requests. My guess is that with the threshold set at 100, we will probably add around eight new licenses with the 25 line threshold (AGPL-2, Artistic-2.0, CC-BY 3.0, CC-BY 4.0, CC-BY-SA 3.0, CC-BY-SA 4.0, and OFL-1.1, and I'm not sure about some of those because the CC licenses have variants that would each have to reach the threshold independently; my current ad hoc script does not distinguish between the variants), and maybe 10 to 12 total without that threshold (adding Expat, zlib, some of the BSD licenses). This would essentially be continuing current practice except with more transparent and consistent criteria. It would mean not including a lot of long legal license texts that people have complained about having to duplicate, such as the CDDL, CeCILL licenses, probably the EPL, the Unicode license, etc. If that's what people want, that's what we'll do; as I said, that's what I would do if the choice were left entirely up to me. But I want to make sure I give the folks who want a much more relaxed standard a chance to speak up. For me, this outcome would already be an improvement over the current situation and alleviate my biggest pain point (CC licenses). Still, I'd like to be significantly more relaxed. I propose the following three criteria must be satisfied for inclusion in /usr/share/common-licenses: * The license is DFSG-free. * Exactly the same license wording is used by all works covered by it. * The license is in the SPDX list of common licenses (https://spdx.org/licenses/) OR The license applies to at least 100 source packages in Debian. I am not committed to the 100 source packages threshold, it is mostly intended as fallback for a hypothetical future license which is super popular but for some reason does not make it to the SPDX list in a timely manner. One very intentional side effect of my proposal is a nudge towards using SPDX License Identifiers in d/copyright files. Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭────────╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Bug#1051430: ITP: python-laspy -- Library for working with LAS LiDAR files
Package: wnpp Severity: wishlist Owner: Timo Röhling X-Debbugs-Cc: debian-devel@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: python-laspy Version : 2.5.1 Upstream Author : Grant Brown * URL : https://github.com/laspy/laspy * License : BSD-2-clause Programming Lang: Python Description : Library for working with LAS LiDAR files Laspy is a Python library for reading, modifying, and creating LAS LiDAR files. The ASPRS LAS format is a sequential binary file format used to store data from LiDAR sensors and by LiDAR processing software for data interchange and archival. The package will be team-maintained under the umbrella of the Debian Python Team at https://salsa.debian.org/python-team/packages/python-laspy -BEGIN PGP SIGNATURE- iQGzBAEBCgAdFiEEJvtDgpxjkjCIVtam+C8H+466LVkFAmT6KxwACgkQ+C8H+466 LVndKAwAwgyox6Pw9oGiQr4B9NLQ46BqdaBNkfNDUq5IXIIsdaE2+m2Q3L58HB+r 1AqX2hA5HzEVk9UW/2MaH5wvbbNmjuoPq7Ov0e6Qz2Gy5zKRZWUiFCJLjslinmfI wUm43POIFt4Ss7fEwPZHUEUHb4Qn5M4JffEgUqeXrjdlylVlkZBM11vzOpeEjhpv 8c5zXEtQT4V98vzSe9y59dpbk91tBWihG6SeDpn1+jamBp8EA+WM4Q6YYJQoVAjX gmMylOHsAp+C03vxqqvQg7QSIHn/mS5v8xlDT/Vj0v6813Uq791uTko8Ac7F6+MG jLPlblXri8jhhImcOiLgQ/BA7sMsMH28cCbW0kpudqyG2agrwdxVu9rewm3O8DU6 5VoTdQU1/wm8nhxJ0e5ZjQUp4GX1lSGxdz16lD5u59Sfi8K2OGPipP7+LJkmpqnE U52OCp1/ZQrrh9gPN5cdtM2qttAIPH8ZSJ29KDwmyDIEROC9TP6iINjAMpwc28X/ weJITNvP =Ii5X -END PGP SIGNATURE-
Re: Bug#1051025: ITP: tiny-proxy -- Simple proxy server (SOCKS4, SOCKS5, HTTP tunneling) for Python
Hi, * Benjamin Drung [2023-09-01 13:57]: Package: wnpp Severity: wishlist Owner: Benjamin Drung X-Debbugs-Cc: debian-devel@lists.debian.org, bdr...@debian.org * Package name: tiny-proxy We have a (not Python related) proxy implementation called tinyproxy in Debian already. May I suggest you use python-tiny-proxy as source package name? Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Re: Potential MBF: packages failing to build twice in a row
* Jeremy Stanley [2023-08-13 21:18]: Similarly, I got one for __pycache__/*.cpython-311.pyc file overwrites... is that something dh_python should clean? As a matter of fact, I also have one like that, ironically it is not even a Python package, it just happens to run Sphinx for its documentation. Thus, I'm seriously wondering if dh_clean should start removing __pycache__ folders, as it already cleans up some other random stuff like autom4te.cache folders, *.orig and *.rej patch backups, and even DEADJOE files. Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Re: Potential MBF: packages failing to build twice in a row
Hi, * Johannes Schauer Marin Rodrigues [2023-08-13 22:28]: since this issue seems to be affecting a few more packages than plakativ, I wanted to ask here what the canonical way is to fix this issue? There's talk on #d-python if pybuild could/should deal with it; I'd give it a few days and see if that pans out. If not, extend-diff-ignore as Scott suggested or simply removing the egg-info folders with a *.egg-info/ line in d/clean should both work. (Personally, I'd use extend-diff-ignore if the egg-info is also shipped in the source tarball and d/clean if not) Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭────╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Re: Potential MBF: packages failing to build twice in a row
* Jonas Smedegaard [2023-08-10 12:32]: Example: An organisation has examines licensing of Chromium as installed ontheir Android and Linux systems, expressed as SPDX datasets with SHA1 checksums for upstream tarballs. They need to do a full analysis for each upstream release, but would prefer to only need a partial analysis for each Debian repackaging if possible. If Debian included a SHA1 which matched a SHA1 in their SPDX dataset then they benefit. If SHA1 for one reason or another don't match then it not a sign if insecurity, only a more expensive process for them because they then need to analyze that repackaged tarball as unique instead of as a derivation of something known to them. I agree that you describe a valid use-case and a good reason why Debian maintainers should not repack source archives arbitrarily, but it does not refute my point. A cryptographic hash is not a signature, it merely represents a particular binary blob (such as a source archive) and makes no claim about the authorship of that blob. In fact, you can even compute it yourself if upstream refuses to do so, and your described use-case would still work: You don't need to know about authorship, you only need to know if some tarball has content you have already seen and examined before. Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Re: Potential MBF: packages failing to build twice in a row
Hi, * Helmut Grohne [2023-08-10 06:43]: When repacking, the upstream signature becomes useless and external parties can no longer verify it at ease. Including that upstream signature increases trust in the source shipped by Debian being good. I don't think that problem is very relevant in practise. On the one hand, the vast majority of upstreams I have encountered so far do not ship any signatures at all. Some upstreams do not even have an immutable release archive; Github (for example) generates TARs and ZIPs on the fly and changes the exact format from time to time. On the other hand, those upstream developers who care enough to go the extra mile with a meaningful [1] cryptographic signature, probably also pay more attention to the actual files they ship, making it less likely to require repacks in the first place. Cheers Timo [1] A signature is only meaningful if the signing key is kept secure. If you upload a GPG private key to your favorite code hoster and have it sign releases automatically, you have a very convenient workflow that achieves nothing at all, because the integrity of the release still depends on the integrity of the hosting platform. -- ⢀⣴⠾⠻⢶⣦⠀ ╭╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Re: Potential MBF: packages failing to build twice in a row
Hi Lucas, * Lucas Nussbaum [2023-08-05 17:06]: An example sbuild invocation to reproduce failures is: [omitted the command line equivalent of Tolstoy's War and Peace] If we decide that this issue is important enough that people should care and mass bugs be filed, sbuild will need a more concise way to test this; something like pbuilder's --twice option. Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Re: Help with the nftables package: the embedded python module
Hi, * Arturo Borrero Gonzalez [2023-07-28 18:38]: I would appreciate additional suggestions and hints. Patches welcome. If you have bad interactions between the Python and non-Python parts of your package, you can try and build them independently, i.e., override_dh_auto_build: dh_auto_build --package=python3-nftables --sourcedirectory=py --buildsystem=pybuild dh_auto_build --remaining-packages and similar for the other dh_auto_* commands. I did something like that for tinyobjloader and it worked quite nicely. Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Re: Behavior change for Python packages built with CMake
Hi Adrian, * Adrian Bunk [2023-07-27 18:02]: The real problem are the unknown number of packages that are affected but don't FTBFS where this will only have an effect after the next upload or binNMU. I looked at the archive and tried to gauge the number of possibly affected packages. First, I compiled a list of all packages which install into /usr/lib/python3/dist-packages and mapped them to their source packages. As pybuild does the right thing and dh_python3 will move Python modules to the correct path even from /usr/local, I figured only packages which use neither can break. So I ran codesearch.d.n with queries like path:debian/rules --buildsystem pybuild path:debian/rules dh_python3 path:debian/rules --with python3 path:debian/control dh-sequence-python3 ... to compile a second list of well-behaved packages. Taking the difference between both lists, I got ~60 packages, which I inspected manually (because codesearch.d.n seems to have missed some results), finally ending up with the following 34 suspicious packages: android-platform-build cairo-dock-plug-ins cappuccino chiark-utils dh-coq gammastep gexiv2 gmsh gnome-browser-connector gr-dab libaccounts-glib libgit2-glib libgom libmodulemd libsignon-glib llvm-toolchain-13 llvm-toolchain-14 llvm-toolchain-15 llvm-toolchain-16 lomiri-url-dispatcher meep meep-mpi-default meep-openmpi minetest-mod-pycraft ortools python-x2go ratpoison renderdoc sugar tulip typeshed ubertooth unattended-upgrades uwsgi Some of those use CDBS or dh plugins which I don't know well enough to determine whether or not they could be broken. The others do a lot of manual stuff which is at least brittle. A dd-list is attached. Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ Agathe Porte ortools (U) Alexandre Rossi uwsgi (U) Amin Bandali gexiv2 (U) Android Tools Maintainers android-platform-build Anton Gladky gmsh (U) Antonio Terceiro typeshed (U) Bernhard R. Link ratpoison Breno Leitao cappuccino Chirayu Desai android-platform-build (U) Christophe Trophime gmsh (U) Debian Cairo-dock Maintainers cairo-dock-plug-ins Debian Games Team minetest-mod-pycraft Debian GNOME Maintainers gexiv2 gnome-browser-connector libgit2-glib libgom Debian OCaml Maintainers dh-coq Debian Python Team typeshed Debian QA Group gammastep Debian Qt/KDE Maintainers libaccounts-glib Debian Remote Maintainers python-x2go Debian Science Maintainers gmsh ortools Debian Science Team tulip Debian Sugar Team sugar Debian UBports Team lomiri-url-dispatcher Debian X Strike Force renderdoc Debian/Kubuntu Qt/KDE Maintainers libsignon-glib Diane Trout libsignon-glib (U) Gianfranco Costamagna llvm-toolchain-13 (U) llvm-toolchain-14 (U) llvm-toolchain-15 (U) llvm-toolchain-16 (U) Hans-Christoph Steiner android-platform-build (U) Ian Jackson chiark-utils James Turton tulip (U) Jason Crain gexiv2 (U) Jeremy Bicha libgom (U) Jeremy Bicha gnome-browser-connector (U) libgit2-glib (U) Jeremy Bícha gexiv2 (U) Jonas Smedegaard sugar (U) uwsgi (U) Jordan Justen renderdoc (U) Julien Puydt dh-coq (U) Kai-Chung Yan android-platform-build (U) Kurt Kremitzki gmsh (U) Laurent Bigonville gexiv2 (U) libgit2-glib (U) libgom (U) LLVM Packaging Team llvm-toolchain-13 llvm-toolchain-14 llvm-toolchain-15 llvm-toolchain-16 Marius Gripsgard lomiri-url-dispatcher (U) Michael Biebl libgom (U) Michael Vogt unattended-upgrades Mike Gabriel lomiri-url-dispatcher (U) python-x2go (U) Nobuhiro Iwamatsu cairo-dock-plug-ins (U) Peter Pentchev libmodulemd (U) Petter Reinholdtsen minetest-mod-pycraft (U) Pino Toscano libaccounts-glib (U) Ritesh Raj Sarraf gnome-browser-connector (U) RPM packaging team libmodulemd Ruben Undheim gr-dab ubertooth Santiago Ruano Rincón sugar (U) Sylvestre Ledru llvm-toolchain-13 (U) llvm-toolchain-14 (U) llvm-toolchain-15 (U) llvm-toolchain-16 (U) Thorsten Alteholz meep meep-mpi-default meep-openmpi uWSGI packaging team uwsgi Youhei SASAKI cairo-dock-plug-ins (U) signature.asc Description: PGP signature
Re: Behavior change for Python packages built with CMake
* Simon McVittie [2023-07-27 14:24]: The patched sysconfig and distutils.sysconfig modules in Debian have a (somewhat poorly documented) override for package builds: set the DEB_PYTHON_INSTALL_LAYOUT environment variable to "deb_system". This is used internally by pybuild Would it make sense for debhelper to set this, either unconditionally or in a sufficiently new compat level, and either unconditionally or for the cmake and meson build systems? Yes, I think that is a good idea. One thing I am a bit afraid of is upstream cargo-culting, i.e., someone setting this variable unconditionally in their build system as a "Debian workaround", which would defeat its purpose, distinguishing a package build from a regular user build. Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭────╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Re: Behavior change for Python packages built with CMake
* Enrico Zini [2023-07-27 15:51]: Are we at a situation where we can pick one and document it as an accepted standard, until some build tool will set it by default, in which case it'll only become redundant? Yes, I believe this is the case. Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Re: Behavior change for Python packages built with CMake
* Sebastiaan Couwenberg [2023-07-27 15:30]: On 7/27/23 15:24, Simon McVittie wrote: Is "deb_system" and not "deb" the canonical thing to use here? The GNOME team has been using "DEB_PYTHON_INSTALL_LAYOUT = deb" to work around the corresponding issue with Meson-built packages. It's effectively the same: Yes. Stefano told me off-list that "deb" is supposed to be the canonical value, actually. The Python install scheme it activates is called "deb_system", though, which led me to believe otherwise. The two hardest problems in computer science are naming, caching, and off-by-one-errors. ;) Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭────────╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Behavior change for Python packages built with CMake
Hi,
recently there have been two independent changes in the Python and
CMake world which conspired to FTBFS a number of packages.
TL;DR: export DEB_PYTHON_INSTALL_LAYOUT=deb_system in d/rules
The first change introduced a Debian-specific 'posix_local'
installation scheme to sysconfig [1]. This change occurred because
distutils is now deprecated, and we wanted to retain a long-standing
distutils.sysconfig behavior: It has diverted user installs to
/usr/local/lib, to prevent locally built packages from messing with
the dpkg-managed /usr/lib directory.
However, the distutils.sysconfig API also had a "is_plat_specific"
switch which caused the API to return /usr/lib/python3/dist-packages
anyway; many build tools such as CMake and meson exploited it to
avoid the diversion, limiting the effect to "pip install" and
friends. The newer sysconfig API is slightly different, with
"schemes" for different sets of installation paths. Most
importantly, it no longer has a simple "is_plat_specific" override.
This brings us to the second change: CMake 3.27 migrated from the
deprecated distutils.sysconfig to sysconfig, which caused it to use
/usr/local/lib paths for Python builds now. This is actually what we
wanted in the first place, because user-built CMake projects should
never have installed to /usr/lib/python3. However, a few Debian
packages have also relied on the old, broken behavior, which is
why about 30 packages have been hit by FTBFS bugs from Lucas' latest
archive rebuild ("dh_install: error: missing files, aborting")
The patched sysconfig and distutils.sysconfig modules in Debian
have a (somewhat poorly documented) override for package
builds: set the DEB_PYTHON_INSTALL_LAYOUT environment variable to
"deb_system". This is used internally by pybuild, which is why
most Python packages never noticed the changes. Maintainers of Python
packages which do not use pybuild need to set this variable
manually.
Alternatively, there is also a CMake plugin for pybuild, which
automatically takes care of everything and even builds the sources
for all available Python versions:
export PYBUILD_SYSTEM = cmake
export PYBUILD_CONFIGURE_ARGS =
%:
dh $@ --buildsystem=pybuild
The latter solution is more robust against other potential future
changes in the Python ecosystem, but it is more involved to get to
work with some packages.
Cheers
Timo
N.B. It looks like Meson has been affected in a similar way [2].
[1] https://lists.debian.org/debian-python/2022/03/msg00039.html
[2] https://bugs.debian.org/1041537
--
⢀⣴⠾⠻⢶⣦⠀ ╭────╮
⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │
⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │
⠈⠳⣄ ╰╯
signature.asc
Description: PGP signature
Re: systmd-analyze security as a release goal
Hi, * Colin Watson [2023-07-14 11:50]: On Fri, Jul 14, 2023 at 08:08:39AM +0100, Matthew Garrett wrote: On Thu, Jul 13, 2023 at 08:03:39PM +0200, Timo Röhling wrote: > qemu is basically an interpreter for foreign machine code. If your > threat model allows access to qemu-user-static for an attacker, they > can run pretty much any binary is if it were native, and the whole > SystemCallArchitectures hardening becomes meaningless. My understanding of the threat is that compatibility syscalls (eg, x32 on amd64) are less well-tested than the local architecture syscalls, and so allowing apps to call them increases the risk - a compromised app that can make compatibility syscalls stands a higher probability of being able to elevate privileges, either in userland or to the kernel itself. Allowing qemu to translate syscalls from other architectures to the local syscall ABI doesn't increase that risk, so isn't a concern. The goal isn't to prevent code form other architectures from running, it's to reduce the attack surface by preventing calls to the compatbility syscalls. Not just that, but also using compatibility syscalls allows circumventing other systemd hardening that filters syscalls (RestrictAddressFamilies=, MemoryDenyWriteExecute=, SystemCallFilter=). Allowing qemu also doesn't make much difference either way to that though - if your process can't make a syscall directly, it can't make it via qemu either. Hm, I didn't think of it that way. Thank you both for your insights! Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭────────╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Re: systmd-analyze security as a release goal
* Guillem Jover [2023-07-13 19:36]: The same would apply to any other interpreted program, as long as the interpreter matches the systemd native architecture. This, by the way, includes the following scenario: * Trent W. Buck [2023-07-06 10:41]: dpkg --add-architecture arm64 apt update apt install mg:arm64 qemu-user-static systemctl edit dpkg-db-backup qemu is basically an interpreter for foreign machine code. If your threat model allows access to qemu-user-static for an attacker, they can run pretty much any binary is if it were native, and the whole SystemCallArchitectures hardening becomes meaningless. Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Re: proposal: dhcpcd-base as standard DHCP client starting with Trixie
Hi Lukas, * Lukas Märdian [2023-07-12 12:53]: Thank you for pointing this out. It's been on my TODO list for a while to split the netplan.io package, and make the Python-CLI parts optional. They are not strictly required to configure a system at boot time. I took your mail as an occation to finally draft something up along those lines: https://salsa.debian.org/debian/netplan.io/-/merge_requests/9 I hope to land that package-split in the not too distant future. Just be aware that you you will likely have to move files from / to /usr for the merged-/usr transition during the trixie release cycle as well. That might become slightly more complicated if you also split the package. (I'm not saying it can't be done, just that it might be less straight forward and require some extra care.) Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭────╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Re: Second take at DEP17 - consensus call on /usr-merge matters
Hi Gioele, * Gioele Barabucci [2023-07-08 10:53]: Even the most convoluted and lock-stepped procedure can surely be carried out over a single day in an all-hands-on-deck effort. Especially if the files of non-critical packages are moved before the flag day. I agree. Maybe my wording was too harsh; as a matter of fact, I think the flag day will work just fine, and even if we stretch the upload over more than a dinstall cycle, the absolute worst that will happen is that bootstrapping will not work for a few hours or days. I initially thought that the unpack order would be simpler to implement without breaking compatibility with older releases, but after Helmut's sibling reply in this thread, I don't think there is much of a difference, if at all. Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Re: Second take at DEP17 - consensus call on /usr-merge matters
Hi Sam,
* Sam Hartman [2023-07-07 08:50]:
TL;DR:
It looks like if we do not want to encode merged /usr into the bootstrap
protocol, we must keep some aliases and cannot move all files in
data.tar.
I think removing all aliasing is important and so I am firmly in the
camp of doing usrmerge in the bootstrap protocol.
We seem to agree on the goal (if by "removing all aliasing" you mean
stop shipping any files in /bin and /lib), but I firmly disagree
with your premise.
Let me elaborate.
So, my understanding of the specific proposal is that:
We in are in category 1:
1. Don't move. We just keep those files that require a particular
location (such as /bin/sh or the dynamic loader) in their
non-canonical location. As such, maintainer scripts will be able to
run and perform the conversion to symbolic links afterwards.
In Helmut's mail to which you are referring, he later explains that
the bootstrap categories come from two orthogonal questions:
Q1. Who is responsible for the top-level symlinks?
Q2. Are there any packages which install files through a top-level
symlink, i.e, an aliased path?
We want the answer of Q2 to be No. The answer to Q1 has, as far as I
can tell, three alternatives:
Q1a. Symlinks are created by the bootstrap tool early on
Q1b. Symlinks are shipped in a package (e.g. base-files) and will
be created in the initial unpack phase
Q1c. Symlinks are created by a usrmerge conversion, either in a
maintainer script in the configuration phase or in the final
cleanup phase by the bootstrap tool
Q1a puts us in Category 4 in Helmut's taxonomy (or as I am going to
call it from now on, HC-4); I'll skip that discussion for now.
Q1c defers the symlink creation to such a late stage that we run
into the ABI problems outlined in other mails; basically, this is
the answer that may force us to ship the dynamic loader in /lib{64,}
and the POSIX shell in /bin forever, and firmly entrench the
usrmerge conversion into our bootstrap process. In my opinion, we
can rule this out completely, because it does not finish the
usrmerge transition as much as hide it away in a dark place where
nobody dares to look. We would end up in HC-1 or HC-3.
Q1b is where it gets interesting, because the way our bootstrapping
protocol currently works, *all* packages will be unpacked first, and
only *then* the configuration phase begins and maintainer scripts
are executed. This means that we *can* move all files to their
canonical paths, because the top-level symlinks will be created
juuust early enough. Depending on the answer to Q2, we end up in
HC-1 or HC-2.
Q1b is my favorite, because it allows us to move the files, finish
the transition, and regain the property that a Debian system is
fully described by package metadata (HC-2).
Q1b has one important failure mode while there is any package left
in the essential set which has not moved its files to the canonical
location: as the initial unpack order is undefined, it is possible
that such a package gets unpacked early enough to create real /bin
or /lib directories, which would then conflict with the subsequently
unpacked top-level symlinks. I think this is the "fragility" other
people keep referring to. Any other usrmerge transition
problem will affect Q1a as much as Q1b, because after the unpack
phase, both are in the exact same state.
The simplest solution for the unpack problem would be to amend the
bootstrap protocol and have base-files be unpacked first. As soon as
all packages have properly transitioned and moved their files to
/usr, we are free to remove that requirement again, because the
unpack order will no longer matter.
Alternatively, we could move all files except for the few critical
ones (/bin/sh, dynamic loader), and then have a coordinated flag day
upload where we add the base-files symlinks *and* move all remaining
files, but this feels quite a bit more fragile to me.
Cheers
Timo
--
⢀⣴⠾⠻⢶⣦⠀ ╭────────╮
⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │
⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │
⠈⠳⣄ ╰╯
signature.asc
Description: PGP signature
Bug#1040176: ITP: cppdap -- C++11 implementation of the Debug Adapter Protocol
Package: wnpp Severity: wishlist Owner: Timo Röhling X-Debbugs-Cc: debian-devel@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: cppdap Version : 1.58.0a Upstream Author : Google LLC * URL : https://github.com/google/cppdap * License : Apache-2.0 Programming Lang: C++ Description : C++11 implementation of the Debug Adapter Protocol cppdap is a C++11 library to implement a Debug Adapter Protocol (DAP) client or server. It provides C++ type-safe structures for the full DAP specification, and provides a simple way to add custom protocol messages. cppdap is a new dependency of CMake 3.27+ The package will be maintained by Timo Röhling at https://salsa.debian.org/debian/cppdap -BEGIN PGP SIGNATURE- iQGzBAEBCgAdFiEEJvtDgpxjkjCIVtam+C8H+466LVkFAmSh1o8ACgkQ+C8H+466 LVnkyAv+Pll6YrJ7fHA25vJfWdXPY4DmjX8G2EXxoi2o+ZYlDJbEVwG+ShL8+d7u 2r7r6aC13UmiSVxpTTFVdW4BCKX0ZTib4VtlNB02DJF1J1pBaS5iDBjtZv7YKRsB 65sZhCbl4FxR0F3+7AqcEgYlRAQnCAfKqcVilBOKgpI6ABfab46VHn3djOkvES2w qJDqk/awqGc1ziYZfMmXTwrpry+ZekXVps+19O8LNMbdirkdWpTKs81JVMlq5ak+ k6jDrQEBJ6GyZ672biM9ejFVIdH6fv/5WpElKDqbv52xTDxgV7LjeAK7KTE4Ra3u wJOrZrgYVfkq3dRc/CisGSmcA6Xotuy0NG8FyFsXInfm217tdj1xIBzsmzjlrNNT hx00YqFxINiSE3Mo3bgg3jqCDsBkJhx4L3qKL5TkPk8QwA6ayyXNCjpBdPYFyy5f AcSVpsm0peN7znMFsE0ADdjfV/lQ8VvdJ1Ko33m62/kNi/eyfag6MLPl9OjMl7F+ EbLLc+Os =BlS+ -END PGP SIGNATURE-
Re: Second take at DEP17 - consensus call on /usr-merge matters
Hi Luca, * Luca Boccassi [2023-06-29 12:49]: The sole benefit is that one of the two bootstrapping tools in widespread use keeps its internal code a bit 'cleaner' from the point of view of some technically unnecessary and self-imposed design constraints (yes there's 2 more tools as pointed out yesterday, but they appear to be at least under-maintained judging from tracker.d.o). I believe you are narrowing the focus too much on an implementation instead of taking the concept into consideration. If I understand Josch correctly, he is aiming for a fully declarative way to describe how to setup a Debian system, and I believe that the idea has a lot of merit. It is also consistent with a general trend in Debian: just look at d/rules and see how little actual code a modern debhelper rule script needs; with dh-sequence-* and other declarative files in debian/, it is often little more than %: dh $@ It makes packaging simpler, avoids code duplication and also makes it much easier for tools like lintian to reason about package behavior. For instance, good luck coming up with a reliable check to see if a hand-written d/rules without dh_auto_test properly obeys the "nocheck" profile. I don't see how it's worth the risk. This is essentially a problem in the bootstrapping tools, so solving it in the bootstrapping tools is not only the safest approach - worst case scenario, creating a new sid chroot might not work for a couple days, not a big deal given it happens all the time for various reasons as we've seen this week - it's also the right approach. Josch already made a good analogy that this is "essentially a bootstrapping tools problem" in the same way that dependency resolution is "esssentially a dpkg problem", yet nobody patches dpkg if someone omits "Depends: libbar-dev" in a libfoo-dev which happens to include stuff from bar in its headers. I do concede that we need not limit ourselves to just two options, either have a bootstrapping that works with package dependencies as-is, or have a free-for-all with random and arbitrarily complex code in bootstrapping tools. We could also declare a bootstrapping protocol that always unpacks a specific package (let's call it "first-package"), which may contain additional configuration options to guide the bootstrapping process. We could also teach dpkg to always upgrade that particular package first, as a way to get something like a dist-upgrade script. My point is, Josch raises some interesting points, which we should at least take into consideration and not dismiss them out of hand because bootstrapping is not important for us. Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Bug#1038973: ITP: python-hatch-fancy-pypi-readme -- Hatch metadata plugin for fancy PyPI READMEs
Package: wnpp Severity: wishlist Owner: Timo Röhling X-Debbugs-Cc: debian-devel@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: python-hatch-fancy-pypi-readme Version : 23.1.0 Upstream Author : Hynek Schlawack and the hatch-fancy-pypi-readme contributors * URL : https://github.com/hynek/hatch-fancy-pypi-readme * License : Expat Programming Lang: Python Description : Hatch metadata plugin for fancy PyPI READMEs This plugin is for everyone who cares about the first impression of their project’s PyPI landing page. It allows you to define your PyPI project description in terms of concatenated fragments that are based on static strings, files, and most importantly: parts of files defined using cut-off points or regular expressions. Once you’ve assembled your readme, you can additionally run regular expression-based substitutions over it. For instance to make relative links absolute or to linkify users and issue numbers in your changelog. This is a new dependency of python-attrs. The package will be team-maintained under the umbrella of the Debian Python Team at https://salsa.debian.org/python-team/packages/python-hatch-fancy-pypi-readme -BEGIN PGP SIGNATURE- iQGzBAEBCgAdFiEEJvtDgpxjkjCIVtam+C8H+466LVkFAmSV/+oACgkQ+C8H+466 LVmBMQv/QdiPzR3mGuV/nbHKFstOyD4+cV2Qs3LqWdKoWa5HqdJQ3OnOz7Td/EUn p4dBYnQhfGTOSf4+SCMkkMA9OzBusvFTZ7V4h5SCIyGjxeqlzz+V39cNsQmYrSpk c1De8I4539VvfyMGUAMvwUQEm6ZiJC6wNU/eC421UVBtUHZ828jHbiyV6nAYeO7B p5hAdx0DG1RBDDM9+21uS1rM4n73boidt1y63FFb2N2FlqeiUzjGI0atGnArg6MU QHdvSQ7FIx5FPo9Jtl8uJTLpbo8rJ9TFjHPwVY9Fu6lgSdo0PLDMA94yJTDttsWR Zk+PxipSwvtSGZCjQ0eEi3LJ06NxvQUoCbLod81UDOaDkUjSgtHMaN1rCuT5PT04 YRuZba/vMfs9FbPd8AErBzTr7ldehKhKyJbMr9VnYJdF+2pz2mn9Z+VevegLTjQs q47266yQuxnAHX+5Ng8jMndpuyVif7OJnnKLNaVibuyEHavDWabUAKcA1eikIyAz 2UMfLnlM =Buse -END PGP SIGNATURE-
Re: New deprecation warning in CMake 3.27
Hi Kyle, * Kyle Edwards [2023-06-19 09:18]: CMake upstream here. We do have a tutorial that we've put together and improved over the last few years that teaches modern CMake and avoids using the old directory-level commands. You can find it here: https://cmake.org/cmake/help/latest/guide/tutorial I agree that tutorial has improved over the last years. If you have a cmake_minimum_required() that's older than some of the commands you're using, the expected pattern to avoid using them is: if(NOT CMAKE_VERSION VERSION_LESS 3.25) # Version-gated code here endif() Still, I need to be *aware* that a particular command is newer than my targeted minimum version. I'm really glad that you added the version info to the documentation with CMake 3.20, but it is still manual labor. Maybe there is a linter for that, though, I did not check. More elegant is a version range: if your script does not give any policy warnings with a recent CMake (say CMake 3.26), you can write something like "cmake_minimum_required(VERSION 3.0...3.26)" Please keep in mind that if you set an upper bound, any policies up to that upper bound will automatically be set to NEW, so be sure that your code is ready for that. You could potentially get some unexpected behavior if you have code that uses the OLD behavior of a policy in an older version of CMake and the NEW behavior in a newer version. You are absolutely right, and that is what I meant to convey with "does not give any policy warnings": If the newer CMake warns you that your script relies on some OLD behavior, you need to address that first. That also implies that you cannot bump the upper bound beyond a version you have actually tested. Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭────────╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Re: New deprecation warning in CMake 3.27
Hi David, * David Kalnischkies [2023-06-17 13:23]: fwiw apt would trigger this in its autopkgtest as one of them (the main run-tests) builds a sub-directory of helpers with cmake via the main "upstream" CMakeList.txt file. That test is allowed to have stderr output through, so no problem on that front. I just report this back as I think its a bit optimistic to assume everything building something in tests would do so from within debian/tests. I would actually hope most would build some part of upstream like apt instead… just saying. That is true, but I could not think of a simple way to detect that from source code only. Looking for all cmake_minimum_required() created *a lot* of false positives, where the warning will only show up in the buildd log and do no harm otherwise. (I doubt there is any reason apt uses that particular version, but my cmake knowledge is on a pure edit-semi-randomly-until-it-seems-to- work-as-wanted basis) You are not the only one, not by a long shot. :) Being backwards compatible is CMake's greatest blessing and greatest curse at the same time, because people still run into crappy, 20 year old tutorials and needlessly complicated (but working) code snippets from CMake 2.x on the Internet, making them believe that CMake is crappy and needlessly complicated. It is better than its reputation. It does lack good, recent tutorials though. Can you recommend a relatively safe & old version to use instead of < 3.5 which doesn't need bumping next month but is also available in most semi-current releases of all major distributions (as that is what most upstreams will care about if they don't have special needs)? The *correct* minimum version is actually not that easy to determine, because CMake, for some reason, will let you say "cmake_minimum_required(VERSION 3.0)" and still use newer commands such as "add_link_options" (introduced in CMake 3.13) without warning. Speaking of 3.13, Buster aka oldoldstable ships with CMake 3.13 (released in 2018) and Repology tells me that any relevant distribution with an older CMake is either completely unsupported or you need to buy LTS for it. That sounds like a reasonable support baseline to me. More elegant is a version range: if your script does not give any policy warnings with a recent CMake (say CMake 3.26), you can write something like "cmake_minimum_required(VERSION 3.0...3.26)", which will continue to work with old CMake releases but not trigger any support warnings for the forseeable future, because only the upper bound is considered for that. Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭────╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
New deprecation warning in CMake 3.27
Hi, this is an advance notice that CMake 3.27, scheduled for July 2023, will begin issuing a deprecation warning if a script requests backwards compatibility to versions older than 3.5. CMake will remain backwards compatible, but autopkgtests may break due to stderr output. If you build tests with CMake in your autopkgtest suite, please check that cmake_minimum_required() and cmake_policy() ask for at least version 3.5 and there is no cmake_policy(SET ... OLD) for policies CMP to CMP0065. Attached is a list of most likely affected packages, which I generated with a code search for (?i)cmake_minimum_required\s*\(\s*version\s*(?:3\.[01234]|2)(?:[.)]|\s) path:debian/tests There are no relevant cmake_policy() calls in debian/tests anywhere. I will file bugs on affected packages when CMake 3.27 hits the archive. Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ Andrea Pappacoda glm (U) Andreas Tille libthread-pool (U) Anton Gladky boost1.74 (U) boost1.81 (U) vtk6 (U) vtk9 (U) Barak A. Pearlmutter qhull (U) Debian Boost Team boost1.74 boost1.81 Debian Med Packaging Team ciftilib libthread-pool Debian PhotoTools Maintainers field3d Debian QA Group palabos Debian Qt/KDE Maintainers qca2 Debian Robotics Team fastcdr foonathan-memory Debian Science Maintainers qhull Debian Science Maintainers clblas clfft docopt.cpp fclib glbinding gli glm globjects nanoflann octomap orocos-kdl pybind11 ros-catkin Debian Science Team vtk6 vtk7 vtk9 Debichem Team chemps2 Gert Wollny vtk6 (U) vtk7 (U) vtk9 (U) Ghislain Antony Vaillant ciftilib (U) clblas (U) clfft (U) docopt.cpp (U) field3d (U) glbinding (U) gli (U) globjects (U) pybind11 (U) Giovanni Mascellani boost1.74 (U) boost1.81 (U) James McCoy msgpack-c msgpack-cxx Jerome Kieffer clfft (U) Jochen Sprickerhof orocos-kdl (U) ros-catkin (U) Jose Luis Rivero octomap (U) José Luis Blanco Claraco nanoflann (U) Juhani Numminen octomap (U) Leopold Palomo-Avellaneda octomap (U) orocos-kdl (U) ros-catkin (U) Michael Banck chemps2 (U) Nicholas Guriev ms-gsl Nico Schlömer vtk7 (U) vtk9 (U) Peter Pentchev libzstd (U) Pino Toscano qca2 (U) Riku Voipio orocos-kdl (U) RPM packaging team libzstd Sebastian Wouters chemps2 (U) Stephen Sinclair fclib (U) Steve M. Robbins boost1.74 (U) boost1.81 (U) Timo Röhling astc-encoder fastcdr (U) foonathan-memory (U) nanoflann (U) qhull (U) ros-catkin (U) tinyexr tinygltf tinyobjloader Timo Röhling liblzf Tom Lee capnproto tony mancill capnproto (U) signature.asc Description: PGP signature
Re: booststrapping /usr-merged systems
* Luca Boccassi [2023-06-10 19:54]: I would caution to avoid interpreting clarifying questions being asked as dissent. It's good to ask questions and clarify details about corner cases, but I wouldn't automatically write them down as disagreement. At least that's my reading of recent parts of this thread. This is also my understanding. And for the record, I want to emphasize that I am very much in favor of the plan that Helmut came up with, for a number of reasons: [Full disclosure: I had a few in-person discussions with Helmut in Hamburg last month, so I am probably somewhat biased by now.] 1. Helmut has shown experimentally that his transition plan can work. There are always unknown unknowns, of course, but at the very least, we do not have to break any use-cases intentionally. 2. The transition will leave us in a well-defined state post-trixie without the need to add (and continue to maintain) any clutches (or "special cases") for dpkg. 3. Almost all problematic cases can be dealt with by some black magic in a single usrmerge-support package. It is not pretty, but it will get the job done; a bunch of trickery to make dpkg do the Right Thing despite its incomplete knowledge of aliased paths. 4. We will be able detect the few cases where the Right Thing does not happen transparently, and we can even give advance warning to affected package maintainers what they should and should not do. If the maintainers of those packages pre-upload their transitioned packages to experimental for some automated tests and verification, we can avoid any breakage in unstable and testing. Of course, you do not have to take my word for any of this. I am a big fan of Helmut's approach with experimental verification and data-driven discovery. Have a look at his published test scripts and try to poke holes in them. The more people do this, the more confidence we can have that this might actually work after all. Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭────╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Bug#1037131: ITP: stdgpu -- Efficient STL-like Data Structures on the GPU
Package: wnpp Severity: wishlist Owner: Timo Röhling X-Debbugs-Cc: debian-devel@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: stdgpu Version : 1.3.0+git20220507.32e0517 Upstream Author : Patrick Stotko * URL : https://github.com/stotko/stdgpu * License : Apache-2, BSD-3-clause, CC-BY-SA-3 Programming Lang: C++ Description : Efficient STL-like Data Structures on the GPU stdgpu is an open-source library providing several generic GPU data structures for fast and reliable data management. Multiple platforms such as CUDA, OpenMP, and HIP are supported allowing you to rapidly write highly complex agnostic and native algorithms that look like sequential CPU code but are executed in parallel on the GPU. The package will be maintained by Timo Röhling at https://salsa.debian.org/debian/stdgpu -BEGIN PGP SIGNATURE- iQGzBAEBCgAdFiEEJvtDgpxjkjCIVtam+C8H+466LVkFAmR+OGMACgkQ+C8H+466 LVn5jgv9H09msVcdx84aRR+l4Ny6OFp498xVdttQvJZah2CN8vEC/BCJP7EQcv1o D9OB02xOSvGwk5/qgPEzoJdgkuEyrjvw4hebkbw0y6owQN2uuCRCx77ncse2td81 9pAhb7cH4P+bBhf9ITtmhHjDZ7/g+8mcatRUFwITixzbuK2DqNplsDKyyK8G4PAz nXXIpPaPA9CsW6LzHbISaVb1MK8ESLWIwsjiPabxEc+kmC4635QjCNI9pcY2LyIM zTou7WIdd0mpxtXKU7Jlk1nkqJzfGdyL2c+AhBMg7JGnq/CLNkpRwzoMBTDyz0Dc l7EBelMetVnTz35wQZTraC5icKsYOlTfMlhnZWa4kDHqtQwah8RrMeVjHp2Lrj8J DfKyB821zQx/B5R/mUHBEkdJjcG9yqAFPWjhjeX0TWO5SI3zHZVaa+42LxBk5f8W Vp6Y3rtdP0d+5FJh4CP5cwEFCSTUCCDj6a9R9WT3MzBt1As31qfJZ9Ymf6xU6fPO 0nBMOZNl =K7Cv -END PGP SIGNATURE-
Re: DEP 17: Improve support for directory aliasing in dpkg
Hi, * Simon Richter [2023-05-05 17:59]: - it is not an error to register a diversion for an alias of an existing diversion, provided the package and target matches, this is a no-op - it is not an error to unregister a diversion for an alias of a path that has been unregistered previously, that is a no-op as well How do you distinguish between aliased diversions and "real" ones? Because if you allow the registration of duplicate diversions, the following can happen: - Package A is installed, preinst creates a diversion - Package B is installed, preinst creates the same diversion - Package A is uninstalled, postrm removes the diversion Now package B has lost its diversion. Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Re: DEP 17: Improve support for directory aliasing in dpkg
* Luca Boccassi [2023-04-28 10:12]: Which part of config-package-dev causes a conflict here? Is it something that can be fixed? Given it's declarative, an upload + rdeps rebuild should be all that's needed, assuming we know what the issue is and how to fix it. As far as I can remember, it's a build-time utility and everything it does is embedded in the target package's maintainer scripts. But it's been a few years since I last used it, so I might remember wrongly. You remember correctly. It is relatively straight-forward to patch config-package-dev to create additional diversions for files in / and /usr (if we decide that is the way forward), but admins will have to rebuild their local config packages for these changes to take effect. Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭────╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Re: Please, minimize your build chroots
* Wouter Verhelst [2023-01-30 12:07]: What is "RC" is defined by the release team, not by policy. The release team has clarified that these bugs are not RC. My mistake, I conflated policy violation and RC. Other than that, my original point stands: if you think Policy is wrong, please help fix it, don't dismiss it as "outdated" and filled with "many bugs". Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭────────╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Re: Please, minimize your build chroots
Hi Andreas, * Andreas Henriksson [2023-01-28 12:50]: Policy is not a religion. Policy has many bugs. Policy is very outdated. [...] Here's an example you could follow: https://lists.debian.org/debian-policy/2022/12/msg00023.html Your argument cuts both ways. Right now, Policy says that the bugs are RC, and if you believe that should be different, why don't you propose such a change and seek consensus yourself? Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Bug#1027185: ITP: python-linetable -- Parse and generate linetable attributes for Python 3 code objects
Package: wnpp Severity: wishlist Owner: Timo Röhling X-Debbugs-Cc: debian-devel@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: python-linetable Version : 0.0.2 Upstream Author : Alessandro Molina * URL : https://github.com/amol-/linetable * License : Expat Programming Lang: Python Description : Parse and generate linetable attributes for Python 3 code objects This module provides a simple interface to parse and generate co_linetable attributes for Python 3 code objects, dealing with the version-specific changes in the CPython implementation. The package is a new dependency of python-kajiki and indirectly for python-pecan. The package will be team-maintained under the umbrella of the Debian Python Team at https://salsa.debian.org/python-team/packages/python-linetable -BEGIN PGP SIGNATURE- iQGzBAEBCgAdFiEEJvtDgpxjkjCIVtam+C8H+466LVkFAmOs2g4ACgkQ+C8H+466 LVkyQwwAgqgNq7Zfs8GyfsHmGWmtjop91x/j2qxd1qrs0tfJGk234ASOR96PqV3b ybxXdqZKmawqUvKh1sPm563yGrC2eOyP9LFyecfDVoQr/Lf0Os3QDXJ1Fi4gyyKh 1yrIKbZzSJourH+tJv/EPzLTkYB00eBPxXku8VNth7no1OOSs5+XmT5sCA5k8KbN gdnPit3zNT9rUO32WpWPRMvUcETNzKu5Y0Qa2lXE0p0NCBMiPVpVBQQ7ubmctxXc GdBevK0aQ8XUf13WI6cTePGU0PJFB4SqVVesxMc012ju+7bIBTQV8g0X6IJMY1/H tjKAgfBztLdoK4AQhljFQz3JhAU5Y1H9gRzXRIxwB8zkQokAsm6MVR9+emjtVAzV 718lTka8sJRJCFjBjItSSGZDjLCnuOIt3GJxnZccWhJiS4DlusA0IkWf+hc9rzr2 fyMdAV+U0As7XFRTVigg8zDiKCspZ7FIwgdMdMjibu5f6zt6FadyP89+M7PJF6Of lKmpc1Zk =84ed -END PGP SIGNATURE-
Re: Build libzstd using cmake; add a non-cmake build profile?
* Peter Pentchev [2022-12-26 08:37]: Hi, In #1020403 there is a request to install the CMake build glue for the zstd library in its -dev package. I think that this is a good idea, and I have a pretty much ready-for-uploading set of changes that do that. For the purposes of this discussion I have uploaded the proposed "switch to CMake and install the CMake build glue" commits to my own fork of the libzstd repository at https://salsa.debian.org/roam/libzstd The main thing that gave me a bit of a pause before running `dgit push-source` (and *thanks* for making it that easy!) is that right now libzstd is effectively an essential package (ObXThread: not in the Policy sense) since dpkg pre-depends on it to support e.g. recent Ubuntu debs that use zstd as the compression method for the data part of the package. So... if I introduce a build-time dependency on CMake, this will probably create a non-trivial dependency loop for people who try to bootstrap Debian onto new architectures. Does this mean that it would be best for me to include an e.g. stage1 build profile that does not build-depend on cmake and falls back to the old/current way of building directly using `make`? Hm, but if I do that, it seems that it might be best to put the CMake build glue files into a separate package and make libzstd-dev depend on that new package in the case, since IIUC the stage1 build profile is not allowed to change the contents of a binary package, so I cannot simply drop all the files in the /usr/lib//cmake/ directory. That's not a big hurdle; if people say that this is the way to go, then this is what will be done. Many thanks to all the people who keep working on all the tools and toolchains that make this message make sense at all! I appreciate your concern for the implications for the Debian ecosystem as a whole; in this particular case, I believe I can put your mind at ease: cmake has a bootstrap profile already, because dependency loops have come up before (e.g. libjsoncpp). I am Cc'ing debian-cross in case I overlooked something important, but I am reasonably sure that you need not deal with this issue in libzstd. Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭────╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Re: my package uploads silently rejected
* Gunnar Wolf [2022-11-30 10:54]: While I cannot comment on the DAK side of this, I can confirm that your key was updated in this month's upload, three days ago: https://salsa.debian.org/debian-keyring/keyring/-/commit/f12a437730fc5f1f5ac72a0b914ef97a78d7f7a9 https://salsa.debian.org/debian-keyring/keyring/-/commits/master/debian-keyring-gpg/0x2C7C3146C1A00121 Your currently active key is set to expire on 2023.11.13. So, that _should_ not be the problem. I just updated the keyring with rsync from keyring.debian.org::keyrings/keyrings/ and still get Jonas' expired key (2022-11-12), so it seems there is *something* going wrong (even if it is not related to DAK activity). Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Bug#1024306: ITP: elpa-cmake-mode -- Emacs major mode for editing CMake sources
Package: wnpp Severity: wishlist Owner: Timo Röhling X-Debbugs-Cc: debian-devel@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: elpa-cmake-mode Version : 3.25.0 Upstream Author : Kitware, Inc., Insight Software Consortium * URL : https://cmake.org * License : BSD-3-Clause Programming Lang: Perl Description : Emacs major mode for editing CMake sources cmake-mode provides syntax highlighting and indentation for CMakeLists.txt and *.cmake source files. This is a split from the CMake source package to avoid the rather heavy-weight dependency chain pulled in by dh_elpa. Ideally, I will maintain this package under the umbrella of the Debian Emacsen team , but if they decline I will maintain it as part of the CMake team instead. -BEGIN PGP SIGNATURE- iQGzBAEBCgAdFiEEJvtDgpxjkjCIVtam+C8H+466LVkFAmN2E3UACgkQ+C8H+466 LVk3DgwAmLW65R2QK/Si0mHpo/Kixhl6CJZk7JqDMG/dE8sz5q9uJ9y7qAmjM5j8 dtujEc9wSIeb0tnzvD61W24OZes4yB1z7so3lwcDz627MzftNa1rN23Em210c88+ cqXO0oyMXyHP6q1RCL+jKpLUFklmk2ZbSdx9Q+CUEavsCRAQkNPXXPQsGIJb93ds PoZ9MWNZ51VW+H3ZXnlFYVIRxZCLYV2pAX36IyABwZKvIacxqsEYfQmEt4YliUyA WvoZYktIRb3WL92zw4OOsY729iL6L7sxUS0s9sEq1eXAXeclgENYrYpXFdmZIE1V 1haXdUwca3wB59tQuOPW7Sgj4YkxnosnUk607EA1m/dE7yxfqVKHXb5I3pgtp+gy zk4df+wKzKI6r2sxgBh4aic6bGTNH9WSSgnv0SiwlU1BLf8UtOMsFXi5KlBro03U 4cnGF8EUC9Rbz6QlcL7FGSvuTrYULP1QV3/Pvv9hH8UqG+BHSFiAntrY/C4LvPFa GVVO+3vt =ccAM -END PGP SIGNATURE-
Re: Epoch for node-markdown-it
* Wouter Verhelst [2022-08-22 14:55]: Someone using 22.something rather than 12.something in a version number, to me, sounds like someone making a "serious mistake". So this is *exactly* what epochs are meant for! +1 The something+reallysomethingelse convention is evil and should never have been invented in the first place. It's extremely confusing to users, and an epoch is *hidden* from them. I find it very useful to temporarily downgrade a package. For instance, it is a great stop-gap measure if an ABI breakage happened in a shared library, and you need a bit of time to talk to upstream and arrange for a proper transition to a new SONAME. The key word is "temporary"; personally, I'm thinking more in terms of weeks or months, not years or decades. Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭────╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Re: faker,ruby-faker: error when trying to install together
On Mon, 23 May 2022 01:58:56 +0200 Andreas Beckmann wrote: Package: faker,ruby-faker Severity: serious Tags: sid bookworm User: trei...@debian.org Usertags: edos-file-overwrite Control: found -1 0.9.3-0.1 Control: found -1 2.20.0-1 [...] Here is a list of files that are known to be shared by both packages (according to the Contents file for sid/amd64, which may be slightly out of sync): /usr/bin/faker This bug is assigned to both packages. If you, the maintainers of the two packages in question, have agreed on which of the packages will resolve the problem please reassign the bug to that package. I'm posting to d-devel because I failed to make contact with the Ruby Team directly: ruby-faker primarily ships a Ruby module while faker's sole purpose is the faker executable, so I believe ruby-faker should yield. There are two reverse dependencies: - ruby-devise-two-factor builds fine without /usr/bin/faker in ruby-faker - ruby-omniauth-openid-connect FTBFS for unrelated reasons with and wihout /usr/bin/faker If the Ruby Team agrees with my analysis, I'd appreciate it if someone could upload a fixed version (I am not a team member). Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭────╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Re: enabling link time optimizations in package builds
Hi Matthias, * Matthias Klose [2022-06-17 10:18]: The proposal is to turn on LTO by default on most 64bit release architectures. Not proposing to do this on 32bit architectures because of the limited address space at link time, and up to now nobody tested LTO on 32bit archs. In test rebuilds, there were 373 packages (dd-list in the wiki page) found not to build with link time optimizations for various reasons. These range from easily fixable issues in symbols files to some upstream issues. The idea is to fix as many of these as possible, and then change the packaging for the others to just turn off LTO in the package build. In one of my packages, turning on LTO did not fail the build, but exposed a dormant static initialization bug, as LTO apparently messes with the initialization order [1]. I'd expect more bugs of this kind to come up once LTO is enabled by default. Cheers Timo [1] https://github.com/isl-org/Open3D/issues/4747 -- ⢀⣴⠾⠻⢶⣦⠀ ╭╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Bug#1014075: ITP: python-mapbox-earcut -- Python bindings for the Mapbox Earcut library
Package: wnpp Severity: wishlist Owner: Timo Röhling X-Debbugs-Cc: debian-devel@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: python-mapbox-earcut Version : 1.0.0 Upstream Author : Samuel Kogler * URL : https://github.com/skogler/mapbox_earcut_python * License : ISC Programming Lang: Python, C++ Description : Python bindings for the Mapbox Earcut library The Mapbox Earcut library implements a modified ear slicing algorithm, optimized by z-order curve hashing and extended to handle holes, twisted polygons, degeneracies and self-intersections in a way that doesn't guarantee correctness of triangulation, but attempts to always produce acceptable results for practical data like geographical shapes. The package will be team-maintained under the umbrella of Debian Math Team at https://salsa.debian.org/math-team/python-mapbox-earcut -BEGIN PGP SIGNATURE- iQGzBAEBCgAdFiEEJvtDgpxjkjCIVtam+C8H+466LVkFAmK8wTMACgkQ+C8H+466 LVngnwv/YnLmuSWjKiIxbNcODQiThAaLCGXn9w1mLo28sSKgm8maTfEBTwSryNf3 AthmkjiWTQbsZb5LL5sgh6Qh9Cdm6b+GC7VZ52cboT21mD8+dcYdn37yQrn0VmES seJPrLdHvo0QLxRybTsaPx6mHlZjJWF3sDpWiIJ3i619Hef0qHXM4zUYDMpyuv+G QexPfzevynwc9mJS9nKRLHA/7gdGS+yUDIowAWnNt+8E/8vmjHNT+Qk2Uh7eJftC UrIK2wPp6Xd0Hp7eueovZr0v84EGiGJWvxTOeRd2XzGN/3hKUTMzUfS7mxa6TlMN ermcuvBCl6HQs+39kbZJ0HBIC6CpLebqORV8/IPOPjD/H5JFFYOroxYB3IYVmDwb BW7igEfANmi4A8/A+fmE8UCNXCMAt2Cvuo6QUVu8Wi+/do5kDyiwZ5qLS/ar4ey8 EPgmYTYNL8/V6XAbs6rjBaRpFVo63CCIIIpB3XSr3PxuzKKDh1e5oQw8n5FL+YDx UaqsAhrU =Y2vC -END PGP SIGNATURE-
Bug#1014072: ITP: python-srt -- Python library to handle SRT subtitle files
Package: wnpp Severity: wishlist Owner: Timo Röhling X-Debbugs-Cc: debian-devel@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: python-srt Version : 3.5.2 Upstream Author : Christopher Down * URL : https://github.com/cdown/srt * License : Expat Programming Lang: Python Description : Python library to handle SRT subtitle files srt is a tiny but featureful Python library for parsing, modifying, and composing SRT subtitle files. It has a very robust parser that can deal with many broken SRT files, and needs no dependencies beyond the Python Standard Library. The Python library is a required dependency for manim, the animation engine for explanatory math videos. The package will be team-maintained under the umbrella of Debian Python Team at https://salsa.debian.org/python-team/packages/python-srt -BEGIN PGP SIGNATURE- iQGzBAEBCgAdFiEEJvtDgpxjkjCIVtam+C8H+466LVkFAmK8nYwACgkQ+C8H+466 LVkN/wv/Z7+VOlwj4iKxcEPVbOtJoG4/SUJwaN0YCnILA6gNn3HyDaOH0rU9aeca z8cc1v9N4hYWEAzuiewIohE3zpMRHIw8PB6QoshMT6nwiakYQnGgc9igCNAvWBdk 43hU2k/2d6bIcZ+8LN7EB1wVb8WapnU4XXoMOGpcJpU5I1h+p2vwzrKJJEyX63wV Zxl6CRV7qo8VQaxZ/83Yr7LbKhMDeiEME8+bScz45t/c2BHkR6B1Fl0SMhrf4CCE po51zUILSCoY8URqYBiDwNQzVBcC5YBMXsVxPmxLE8FpRtbuNyyE3XDvESqGxHFc drx5cFUagf9KK0UVepQpZ8Zel3ztfcpMeag7QCz91r1mzC7YxTB8VNsY2aAnhqTN u53Eh23TeJmtiORevhTOVYKo0EvybIklM9wE+pUZ76BMZ0tAso/M7MLHYf6HqgB7 SUm0GumsmqzMp5ZoqhkRFOqvhztbaNCnv6n/tqg0OIm4zspajVkq+pk7Y57GKijo 11sLODDT =V2Tz -END PGP SIGNATURE-
Bug#1013323: ITP: python-isosurfaces -- Compute isolines/isosurfaces of scalar fields
Package: wnpp Severity: wishlist Owner: Timo Röhling X-Debbugs-Cc: debian-devel@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: python-isosurfaces Version : 0.1.0+git20211002.4ae4d8d Upstream Author : Jared Hughes * URL : https://github.com/jared-hughes/isosurfaces * License : Expat Programming Lang: Python Description : Compute isolines/isosurfaces of scalar fields Construct isolines/isosurfaces of a 2D/3D scalar field defined by a function, i.e. curves over which `f(x,y)=0` or surfaces over which `f(x,y,z)=0`. Most similar libraries use marching squares or similar over a uniform grid, but this uses a quadtree to avoid wasting time sampling many far from the implicit surface. The package will be team-maintained under the umbrella of Debian Math Team at https://salsa.debian.org/python-team/packages/python-isosurfaces -BEGIN PGP SIGNATURE- iQGzBAEBCgAdFiEEJvtDgpxjkjCIVtam+C8H+466LVkFAmKx+aAACgkQ+C8H+466 LVmSUAv/TVFef4vgjldHKYIoMAjQepmdNo4WFHPvFj/x1E5KEknDQyJWlqO6eRD2 KTbdEIw5HO6wb8CwglIkhTeAQ6eCgfLTwKF2rHVoV1U9WhUMzzy5ptOKJSZnSrFR P5hgo1T5YTvYde7YtylZceUcQEI9SpnO62fogbgwN45s+TpWVVF4BIWajCx+qupK 7OAZBsGKT7jK7o4XVApKSAG8BKlt0z0ikZEkvZ02SLyRqzSx3DqyVyzDFADKDBHs 4DNQmSiI+ELSo0jXQf8clRTqfMxY9fhjmnrH3VUyzOUsXMt6PupGsaNszIcVN9Mw hVg7cXhKBiLrFk2R2owkus6RCIbLX+JNqTdSU5q8bVQ1qSFmmqCP5IV/neLwgzHJ O/itZ9gxBYq+wj8MltNeXlQnROGl5y+co2BueqQHm/MxohMy7Mzl3XXP5MN3xJpv WeI/PdIbzHRsRSXxB8ZjCygAT65SrwmdKt+15HIlEfyCyZzHiGbx+h42yxy4CrIT ZpSk3BAA =PpxC -END PGP SIGNATURE-
Re: Bug#1013317: ITP: python3-banking -- FinTS banking application suitable for small screens
* Evangelos Ribeiro Tzaras [2022-06-21 16:20]: * Package name: python3-banking Not sure about the package name, could also go with banking-gtk or similar. How do you feel about "tabos-banking"? It avoids the very generic "banking" but does not refer to circumstantial attributes such as programming language or GUI toolkit. Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭────╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Bug#1013151: ITP: ros2-test-interface-files -- Test interface files for ROS 2
Package: wnpp Severity: wishlist Owner: Timo Röhling X-Debbugs-Cc: debian-devel@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: ros2-test-interface-files Version : 0.10.0 Upstream Author : Open Source Robotics Foundation, Inc * URL : https://github.com/ros2/test_interface_files * License : Apache-2 Programming Lang: Description : Test interface files for ROS 2 This package provides message definitions and fixtures which are used exclusively for testing purposes. It is a required dependency for some ROS 2 packages such as rosidl and rcl-interfaces. The package will be team-maintained under the umbrella of Debian Robotics Team at https://salsa.debian.org/robotics-team/ros2-test-interface-files -BEGIN PGP SIGNATURE- iQGzBAEBCgAdFiEEJvtDgpxjkjCIVtam+C8H+466LVkFAmKs5PIACgkQ+C8H+466 LVmLcgv/RoCnoPgO72WgzO18tiagCaRw9hsWp5Tzbea4CrxYSovQN6DuCBqxbY9S ebGeexxzI59kKbfLMmF9nM8ynGr9cdb3ehOLT95mw2X1OkEEKqE3DizYWlDQePoP +7P910NpswgZcJn6yrwMnHQMYuAz2DiO58LGmNieXtU9DcfZrqDl9/jfPPBcNeL8 FbZvNJsim35Qra8/14JklasR7xkvzfZ55jbxsrGnJS5smqCWTObe2MV8MdjWhYbO c8oU6o/RX5w7Zty7O3jT8xl8T2kjTWjM4p1X6miDVQAAlzZw/G2fc/0ZmwsopEzo V2qnDmsYe+FjZ24NXMUv9jUIFnCcLF6I49hcBaFhbsUm33ki/ka8XS8UY67SNaip K98513pTW1fKDcJfBfIFf03hJ6S5SVtspv9ylPXJHxjMmttCO6JEE9p4Vhe2aTYp 7uNZxfifWmMygweb6zlOM9mYS54DCEgo9VI0vVNxiJKE8Fe+2M50i0k5OxfqMQLz pvirHvIW =WxGm -END PGP SIGNATURE-
Bug#1012839: ITP: ros-catkin-tools -- Command line tools for catkin workspaces
Package: wnpp Severity: wishlist Owner: Timo Röhling X-Debbugs-Cc: debian-devel@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: ros-catkin-tools Version : 0.9.0 Upstream Author : Open Source Robotics Foundation, Inc * URL : https://github.com/catkin/catkin_tools * License : Apache-2 Programming Lang: Python Description : Command line tools for catkin workspaces This package is part of ROS, the Robot Operating System. The catkin tools provide similar functionality to ROS 1 as the colcon tools do for ROS 2, such as building and testing packages. The package will be team-maintained under the umbrella of Debian Robotics Team at https://salsa.debian.org/robotics-team/ros-catkin-tools -BEGIN PGP SIGNATURE- iQGzBAEBCgAdFiEEJvtDgpxjkjCIVtam+C8H+466LVkFAmKpnUMACgkQ+C8H+466 LVlnuwwAofS3gQHzd9BI1MhMsorcnUB8EoIDdGZulLqTpb782cxLLKxK09ZxBMX6 oYfxGcEWTZhR29kS5bBfF3w5t8eWCB3RMeb0/TFcC2cmBGbqZermiC/SHFRxgtL7 xkWPM+a9K3P4JYmtZiJboscb+hHSfDS5J4G8gHzu54GGFl9J87DEcrM1stWx9HwP DpW68Rv8MeWInJU4VtQDVkP1urvPvMyALb6iJetm8fAmE9PjDJbKns0VEeibRlJN LWfN79Ss74tohC2dJ1DT+NreZYJxcKuuqFCEu/OSpw7RKMWJIuNfi1Bsb76o1V+J OaqYd4JhQDF/xJe9JyM8ITtcfb5db2A/wele2H9URGnbbgSfrmMnCwDi2yHThVvo mMDeoCmf3xQZ8xFnCMYZqerhHRwENYG75JsdBkD+88Fw2ywAIdMw7764sPgNhhIu oTFPqQuN4T1RKQ+W1U6cA1XwptoV74JZid+HrOcnxEqhS2BLF00tIOdRdTdFnQEl 1UIeZTl8 =HrFV -END PGP SIGNATURE-
Bug#1012687: ITP: python-cloup -- Click with option groups
Package: wnpp Severity: wishlist Owner: Timo Röhling X-Debbugs-Cc: debian-devel@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: python-cloup Version : 0.14.0 Upstream Author : Gianluca Gippetto * URL : https://github.com/janluke/cloup * License : BSD-3-clause Programming Lang: Python Description : Click with option groups Cloup enriches Click with several features that make it more expressive and configurable: * option groups and an (optional) help section for positional arguments * constraints, like mutually_exclusive, that can be applied to option groups or to any group of parameters, even conditionally subcommand aliases * subcommands sections, i.e. the possibility to organize the subcommands of a Group in multiple help sections * a themeable HelpFormatter that: - has more parameters for adjusting widths and spacing, which can be provided at the context and command level use a different layout when the terminal width is below a certain threshold in order to improve readability - suggestions like "did you mean ?" when you mistype a subcommand Moreover, Cloup improves on IDE support providing decorators with detailed type hints and adding the static methods Context.settings() and HelpFormatter.settings() for creating dictionaries of settings. Cloup is a dependency of manim-ce [1] The package will be team-maintained under the umbrella of Debian Python Team at https://salsa.debian.org/python-team/packages/python-cloup [1] https://bugs.debian.org/1012608 -BEGIN PGP SIGNATURE- iQGzBAEBCgAdFiEEJvtDgpxjkjCIVtam+C8H+466LVkFAmKk4PoACgkQ+C8H+466 LVnuawv/ebpNfq/yyKo+ukQbtqRjLwtuOTR2WxAPlmIg82IhlNMRpIHJyUKemx2o LyzUAAHLzQf2eyEQrqpLHFM0hSYOcm4g56OE0RVCrII1HenBfIcwzQR70BOw3tLj w+7W3QP9sZl8MM/F3cA9DoFkmutd+o2nNZvccvAC9OhJinbb4a9U+ttXT8N+eJXZ E3ZlCN9a0ELZmzQCuvOFCt5I5fi4u6GBEIWAhygii3gJATxkVxJmcDUJj5z2rS8g qIgA99RzzaW2iO7UxP16SiN+mQj/dJsp2Hon01AH0qIY6EvBFezoQOg8SDhK4LnZ fnnj9Zq6uvCOGHTPARyOHKNI86RJMhYJZdmxJBvbGJan7zZvMNprA58MNzCvxuIh wooPUM7MSxKFPDWrfGXBjOc+iT8aK7oH8tfJJaAHbxggp162EUnpMJR5xYnV0sMP YT/8ZrG1XsV6pH9Qx+eU2muxibGMHGhu/5QdJuI+ef+HWRZiL6RRfeulklgycvoS lbfIoseM =+omT -END PGP SIGNATURE-
Bug#1012608: ITP: manim-ce -- Animation engine for explanatory math videos
Package: wnpp Severity: wishlist X-Debbugs-Cc: debian-devel@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: manim-ce Version : 0.15.1 Upstream Author : Grant Sanderson, Manim Community Developers * URL : https://www.manim.community/ * License : Expat Programming Lang: Python Description : Animation engine for explanatory math videos Manim is used to create precise animations programmatically, as demonstrated in the videos of 3Blue1Brown. All animations are written as Python code and rendered with the manim CLI tool. This is the Commmunity Edition of manim, which is a better maintained fork of Grant Sanderson's manim package. You will want this version unless you plan to re-render some old 3Blue1Brown Youtube videos from Grant's source code. The package will be team-maintained under the umbrella of Debian Python Team at https://salsa.debian.org/python-team/packages/manim-ce -BEGIN PGP SIGNATURE- iQGzBAEBCgAdFiEEJvtDgpxjkjCIVtam+C8H+466LVkFAmKjBKEACgkQ+C8H+466 LVkWXwwAux8xxF6BaG3yzIX9l9ilGESMzhsX+1HY5rHTNCaKkjyIwt2dyRACyEZF k/dJRVz05EA6oum0fr3OmPqF4rcoMcy+MX6oiKCrHG+zJF9fE3QimUCUDwk8RpHp eahT6kKFkp/59yLEyCYB1C0MhttbeA6aviRLYcnyqjF0ZU+6lX8reZ8Xd7Nhml/6 HQykbZS6wwzJbRWyTs/OLSEy5E1d4nNkBYzLLehaweKago9o7IEd53sSYNuQvr5O kv9+Us4jMFZPWc2up8PcQXNqoEEgTTr+fuEP6h09RuYWpganvIokPRMIPSRxOO5d w+WdqFmzDxaF9tdlAHYyNkDMyYVWptNUDkTPd2eKLIbjV8cSnIMbivJdf07uN+Bz lVFUiTaROF3RYUtjEVI9g9Jxjr4gOiRtj2cticNimz8bZF4I8mRDbNp7FZ1d38e0 0Tsa6VhkTbz4qTG3QZlaov4x5MZH4H5O7s2wOgyEES+p03+yEXdMTZOxBz4GuHH2 0lJU9Lyv =zAjx -END PGP SIGNATURE-
Re: Correct version and revision of upstream packaged Debian package
Hi Tuukka, * Tuukka Pasanen [2022-05-20 10:22]: Currently revision is for example: '10.6.7+maria~buster' which upgrades '10.6.7+maria~bullseye' which is lexical orderly lower than first one.To understand this bug report can be found here: https://jira.mariadb.org/browse/MDEV-28628 which contain more info about how apt works with current situation. Thing that like to ask should revision it be more like '+maria~deb11' or +mariadeb11. I understood that char '~' means it's build from upstream version control not from official release tag. As I seek for examples there is packages which just add '+' chars in revision when needed extra stuff and then revision is just build number without . Your understanding is a bit oversimplified, and that is the source of your confusion. There are two aspects to your question: For the actual sorting order of debian versions, you can read the deb-version(5) manpage [1]. The tilde '~' character is special because it sorts before anything else, even the empty string, but it has no inherent meaning. For the meaning of version numbers, there are conventions for different use-cases. They are designed to create a sane ordering of versions, so packages update smoothly the way you would expect. One such convention is the backport suffix ~bpo. The idea is that you can have a version 1.4 in an old release (let's say Debian 11), backport version 1.5 from testing, and give it the version 1.5~bpo11. This way, it will be considered newer than any 1.4 package (even 1.4.999), but still older than the original 1.5, so if you ever upgrade your system to the next Debian release, the backported version will be replaced by the original package automatically. Like all conventions, it is somewhat arbitrary, and there are other schemes that would achieve the same effect. The conventions used in Debian just happen to be thoroughly tested and work for a wide range of edge cases. Cheers Timo [1] https://manpages.debian.org/unstable/dpkg-dev/deb-version.5.en.html -- ⢀⣴⠾⠻⢶⣦⠀ ╭────╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Re: feedback for NEW packages: switch to using the BTS?
What does it help to have it sitting there instead of rejected? I gave it more thought, and I don't think it has to be sitting in the NEW queue at all. As far as I understand it, the main advantage to gain is additional context; a bug report provides documentation and a place to discuss solutions for packaging issues, especially if the NEW package is maintained by a team. None of this requires the packages to keep waiting in NEW, it just requires the BTS to learn about them, so the bug reports can be assigned properly. There are probably edge cases to consider (such as invalid package names or hijacking uploads) where it is not possible to assign the bugs. I still like the idea to expand the BTS scope to include pre-archive packaging bugs, provided that the assumption that most rejected package uploads will be fixed and accepted eventually, holds. Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Re: feedback for NEW packages: switch to using the BTS?
* Scott Kitterman [2022-04-29 23:32]: I don't understand why this is any better than just rejecting the package? Once it's been determined that the upload won't be accepted, I don't see a benefit to having it remain in New. I think this is a matter of perspective: for the FTP team, the upload is basically a stateless process; a package is either fit for inclusion in the archive or it is not. For the uploading DD, it is merely a particular (undesirable) state in the packaging process. The NEW queue is a mandatory review of their packaging effort, and the REJECT is feedback which they will (hopefully) address, and then try again. Maybe, in some circumstances, they will abandon the package, but I'd say that this not typical. Converting the NEW review process into a bug-centric approach instead of a mail-centric approach reinforces the DD's point of view, focusing more on the package upload as a part of package maintainership. The question is: how will this affect the FTP team's point of view? If it will clutter the NEW queue with half-processed packages, I'd say it is a bad tradeoff, because it adds mental load to the FTP team. At a minimum, there needs to be appropriate tooling which allows to distinguish easily between new packages requiring FTP team review and packages waiting for fixes to be applied. Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭────────╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Re: Firmware - what are we going to do about it?
Hi Steve, * Steve McIntyre [2022-04-19 01:27]: TL;DR: firmware support in Debian sucks, and we need to change this. See the "My preference, and rationale" Section below. [...] 5. We could split out the non-free firmware packages into a new non-free-firmware component in the archive, and allow a specific exception only to allow inclusion of those packages on our official media. We would then generate only one set of official media, including those non-free firmware packages. [...] Thanks to people who reviewed earlier versions of this document and/or made suggestions for improvement, in particular: • Cyril Brulebois • Matthew Garrett • David Leggett • Martin Michlmayr • Andy Simpkins • Neil Williams Thank you, Steve and everyone else involved, for this excellent write-up! I too find option 5 most convincing. Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Bug#1009239: ITP: python-moderngl-glcontext -- Python 3 abstraction layer for OpenGL contexts
Package: wnpp Severity: wishlist Owner: Timo Röhling X-Debbugs-Cc: debian-devel@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: python-moderngl-glcontext Version : 2.3.5 Upstream Author : Szabolcs Dombi * URL : https://github.com/moderngl/glcontext * License : Expat Programming Lang: Python, C++ Description : Python 3 abstraction layer for OpenGL contexts This package provides a framework for the platform-dependent OpenGL initialization code and is primarily used by ModernGL. The modularization makes it simple to add additional platform support. -BEGIN PGP SIGNATURE- iQGzBAEBCgAdFiEEJvtDgpxjkjCIVtam+C8H+466LVkFAmJRj0QACgkQ+C8H+466 LVmw0wv/QLmTMwOV1fQc35wgJbVrRiRnB1JBnB/T3iHBMrjr4di3Fj5DHfoCAGLV FYiSmJ70qZQpuihg4aI5+fWsffgbG6oRO2JufDcAL40j4MeUhDMTyHu6XT5jpZYk VJtfSUf+vAOjBT3QB19llBmUzFnSR4HdsS11yKsqUkVPSW/VbMdKQRtdN0kVdkbr ZSw+Sj3iyIU371G24yMaKQoXtA+wg4/QB6axAxMVLyOPCmvVxqCka8Hydr3Z7UEt JiQe+5XAzi6Qmo1VvejLpBYDP/e3c100eU2dlzy/NzrVwiEH71BIpT1MEz7I22+H ZAlbExiDOL0cR8Z/+k059axmiBTupSWxzSiUpJctqwS6j8/q32KWcSQUPuxKQlps c7bayyrpASniPZaoHzLjPKw/sSk9OOrOgMRdfHFdJ+gmKsD/77zxGX1lTKAKVkJW 6Izs6BDprND1E0QNvBvlDhsS1/yPyYkiObjDLe+snuNaXQX1iJJ63jqU7u/c5oSR R+PEimXh =7haP -END PGP SIGNATURE-
Bug#1009238: ITP: python-moderngl -- Python 3 wrapper for OpenGL 3.3+
Package: wnpp Severity: wishlist Owner: Timo Röhling X-Debbugs-Cc: debian-devel@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: python-moderngl Version : 5.6.4 Upstream Author : Szabolcs Dombi * URL : https://github.com/moderngl/moderngl * License : Expat Programming Lang: Python, C++ Description : Python 3 wrapper for OpenGL 3.3+ ModernGL is an OpenGL wrapper that simplifies the creation of simple graphics applications like scientific simulations, games or user interfaces. Usually, acquiring in-depth knowledge of OpenGL requires a steep learning curve. In contrast, ModernGL is easy to learn and use, moreover it is capable of rendering with high performance and quality, with less code written. The majority of the ModernGL code base is also written in C++ for high performance. ModernGL is a dependency of the Manim animation engine of 3blue1brown explanatory math video fame. I intend to maintain ModernGL under the umbrella of the Python Team. -BEGIN PGP SIGNATURE- iQGzBAEBCgAdFiEEJvtDgpxjkjCIVtam+C8H+466LVkFAmJRjp8ACgkQ+C8H+466 LVmClwwAzCqGYpzQi68TObvUjXyFINPVOQES5tsNLrgTWvQsRFt02QTqpJ59Ks6R AX4Gy0X1D5mPckJ8iZWpXDZGNfMr8GewjygaqZbFHsPbq3WaYCuGrZgUZwj5VhgR CoUU/tcCrevgZ/7FQLIbbj3s3FnEsAtXd3Ejw8k17yqfmr7QaGBQMoPMcyoAtPV2 uqgwNVEkr2DliPqp/C7XWHLdCghAFlbwq2xddDiBbgK+QI7a00nX+LY+F3auGMok XPfkDvZedFy0TGGOX+P+Wajb9ueMricyGnzhdhI0N0n7jayxqdI+qBR96xHCPgys mRQN5XMWl4tWta2gKI72R4O+jBQKb4iorqqBpYWp6sp+l/Pzy6sQ05mtk7fsl9Uo S/ctau6lRcLu7BZ8pMrcs47jKbhkUwMtw8G+S8u6NCe9m9wWSCN7r+VzKyDDaoYq aPEgKDJxFhxQLWAm+dia8uXHALflyyOAxwxOX+sOyJJO2Z9iMP71GSz38HPQsbxc Sef1B5MC =5pXq -END PGP SIGNATURE-
Re: cmake: get rid of -fno-fat-lto-objects
Hi Jerome, * Jerome BENOIT [2022-03-16 22:37]: Hello, One of my package builds with cmake. All is fine except that the built static library gets the no-code-sections error complaint from lintian. It appears [1,2] that /usr/share/cmake-3.22/Modules/Compiler/GNU.cmake enforces -fno-fat-lto-objects unconditionally for GCC + IPO What is the easiest way to revert the -fno-fat-lto-objects flags ? I recommend you explicitly disable LTO for the static library with: set_target_properties(staticlib PROPERTIES INTERPROCEDURAL_OPTIMIZATION OFF) LTO does not really achieve anything for static libraries: They are merely an archive of object files, so the linker is never invoked on them. You might think that LTO is useful when the static library is linked with an executable eventually. Alas, the LTO intermediate code is very compiler-specific, so it will not work with a different compiler and most likely not even with a different version of the same compiler. Alternatively, you could add a snippet such as if(CMAKE_CXX_COMPILER_ID MATCHES "GNU|Clang") target_compile_options(staticlib PRIVATE -ffat-lto-objects) endif() This will work because the target-specific compile options happen to end up after the LTO compile options on the command line right now. However, dh_strip will remove the intermediate code anyway, for the reasons outlined above. Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Re: Legal advice regarding the NEW queue
* Russ Allbery [2022-02-04 11:48]: No, that's fine, that's not a strawman argument. That is, in fact, my argument: I think it should be okay to put crap packages in the unstable archive and fix them later, and I would rather put more effort into the "noticing" part than in the pre-review part. [...] Now, all of that being said, I also want to say that I'm sketching out one end of the argument because I think that end has been underrepresented. I don't think this is an all-or-nothing binary choice. We could, for example, focus our review on only packages that are viewed as riskier (only packages with maintainer scripts or that start daemons, for instance, or stop doing NEW review for packages uploaded under the auspices of well-established Debian teams, or stop doing NEW review for shared libraries whose source packages are already in Debian), all of which would be improvements from my perspective. In my opinion, this is a very important train of thought, because not all crap is created equal. While some things can be fixed easily with a new upload, others have permanent repercussions, for example: - It is impossible to undo an epoch bump, or more generally, revert to an earlier version number. - The package namespace can be polluted, or existing names can be hijacked, potentially rendering names unusuable for future uploads (particularly if the hijacking version number is sufficiently large and/or epoch'd). I'm not implying any ill-will, merely observing that people make mistakes, and some mistakes are more costly to rectify than others. The FTP team review should focus on these types of mistakes, and not only with new packages: any "suspicious" upload should be rerouted to a POLICY queue for additional verification. There is some prior art with the auto-REJECT on Lintian errors, which could be extended to a three-way decision (ACCEPT, POLICY REVIEW, REJECT). For instance, we could flag epoch bumps or major version numbers which skip ahead significantly (think 020220101 instead of 0.20220101). We can certainly continue to flag new binaries and potential copyright violations (e.g., packages with incompatible licenses or files with "(?i)(?:do|must) not distribute" in their headers), or anything else we consider important. The automated checks need not be perfect as long as we avoid false negatives on the critical issues. And I imagine it will also speed up the review considerably if the FTP team already knows what problems (not) to look for. Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭────────╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Bug#1003221: ITP: unicorn-engine -- Lightweight multi-platform, multi-architecture CPU emulator framework
Package: wnpp Severity: wishlist Owner: Timo Röhling X-Debbugs-Cc: debian-devel@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: unicorn-engine Version : 1.0.3 Upstream Author : Nguyen Anh Quynh, Dang Hoang Vu * URL : https://www.unicorn-engine.org/ * License : GPL Programming Lang: C with bindings for various other languages Description : Lightweight multi-platform, multi-architecture CPU emulator framework Unicorn is a CPU emulator which is based on the CPU emulation code from QEMU. Unlike QEMU, it focuses on the emulation of CPU code without a full system emulation, but with the goal to make the emulation extensible and easy to integrate in custom tools. Unicorn provides language bindings for Python, Ruby, and Rust (among others) and has instrumentation hooks for various CPU events. This makes Unicorn well suited for malware analysis and reverse engineering. Unicorn is a dependency for pwntools. I am going to maintain this package out of personal interest in the topic. -BEGIN PGP SIGNATURE- iQGzBAEBCgAdFiEEJvtDgpxjkjCIVtam+C8H+466LVkFAmHXAfcACgkQ+C8H+466 LVnTQAwAljYMdPRNcKFxghBpeZYFSWQkH/NiBUjsX8CzsFuUvnlURYv98szwTYwB XSjMctcfNknq99FVo8W8Nou4V7Sofm41/6rXoDdY2GIqBMsEmbLyoCry0KWljJmg 8DK7xYVU9vBXlx8l0oZ8fq7tW61Z8oy6QqVzVhYCcj20evVbSuSf2eL+2e/4d7E7 Ws6bjJIfzRjT4PbncMYc6qwpiNrUKCT26VTm+c+Q9tRSiE1I7kpWKsKbdm1LOOYU ZYIDPCcUGJpacgRkXKI/yVHr0xj6+4lMOLlruFP27wGG2oX0vbuqi6Nc3BSQ4PdX NHW6AJY8NGD8ttu5ExzfbCcF/qO+xuSWfq7uQe6BNMcFqGIOYUtq9uUm7IQYnFH3 SufXipBqq2Eksj3+PBygG+xQquFARqKefnegFBUHQ4pvbxcMQIDSuwRqPslQv3QB Vsc+yb2lvtQF0cgetIX632oLOViZq2n3Z5lKpOG/Kk+ZK9yCBt/impibFwF1FR2A 0g1vAea6 =BJ5G -END PGP SIGNATURE-
Bug#1002935: ITP: pwntools -- CTF framework and exploit development library
Package: wnpp Severity: wishlist Owner: Timo Röhling X-Debbugs-Cc: debian-devel@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: pwntools Version : 4.7.0 Upstream Author : Gallopsled et al. * URL : https://pwntools.com * License : Expat, GPL, BSD Programming Lang: Python Description : CTF framework and exploit development library pwntools is designed for rapid prototyping and development, to make exploit writing as simple as possible. The primary use case of this framework are CTF hacking contests, where vulnerabilities in a sandbox environment are exploited to gain access to a "flag" file or secret string, as proof of success. I'm packaging this framework out of personal interest and intend to maintain it as part of the Python Team. Most dependencies are available in Debian already, with the exception of ROPgadget, colored_traceback, and the RPyC Remote Procedure Call library, which are currently waiting in NEW. -BEGIN PGP SIGNATURE- iQGzBAEBCgAdFiEEJvtDgpxjkjCIVtam+C8H+466LVkFAmHQavAACgkQ+C8H+466 LVnoUwv9EUqhQQckIF2ZX4iXwJeAc8Nwtju4XZ+bq8pB1BeSjeCrfqiXeZPLrxl+ 0iNS9m6uIt5dAVHcvivvyunnkKtZpc73HxUSOtbHiJd+D3Gs8CVaF32entfpqTys o4M2yIBViKzE8mFuBZ052akWNEMVijRXaUMH+DPUvsMi6Z/iuL80J77cTzoQlweq qoxnoI3XrY9lye58Dk5DHHTjAqIFiGju97tqxIiGs4ri3GW6MHFzflHCs65dPUt5 lpNNjGRk8p64s/wen5SAJumsVi9H8MA2u990RcYQ9WxwHISZ7FmXYfvEbgqklkx2 sWW+ENB4nRm+XeV1MVX/PG6yfRc3VUD6iR/++U+ZgBDacmjO50t152c6F1pK/MLc SG9bvMnup4L4btX4GXYNZwkPMHHZqNzeWSjp+WT2LNqcNMk/Y4ORmAvWWeRkAID7 WwJ5Ib5nI7fSYWIFmL33ZYnFJ8xM8ZixbsFuSV6mhjzfMHUhc2bfD6AAMjHeHx9T ef//esHq =F7Gm -END PGP SIGNATURE-
Re: releasing major library change to unstable without coordination
Hi Sandro! * Sandro Tosi [2021-12-22 19:24]: there's also a problem of resources: let's take the example of numpy, which has 500+ rdeps. am i expected to: * rebuild all its reverse dependencies with the new version * evaluate which packages failed, and if that failures is due to the new version of numpy or an already existing/independent cause * provide fixes that are compatible with the current version and the new one (because we cant break what we currently have and we need to prepare for the new version) * wait for all of the packages with issues to have applied the patch and been uploaded to unstable * finally upload to unstable the new version of numpy ? that's unreasonably long, time consuming and work-intensive for several reason That's true. However, I think it is reasonable to expect a maintainer to * look at the release notes for documented API breakage, * rebuild a few reverse dependencies (ideally the ones which exercise the most functionality, but a random pick is probably fine, too), * file bugs if you find any issues, and * monitor the PTS and check for autopkgtest failures, so you can help figure out (or even fix) what broke. Personally, I also like to run something like `git diff upstream/ upstream/ -- '*.h'` or `git diff upstream/ upstream/ how much has changed, and if I find breakage (either through inspection or rebuilding), look for other usage of the broken API with sources.debian.org. Maybe it's just lazy on my part, but there needs to be a cutoff between making changes/progress and dealing with the consequences, and walking on eggshells every time there's a new upstream release (or even a patch!) and you need to upload a new pkg. i choose making progress I believe if you are maintainer of an important package with many reverse dependencies, you should spend more time to avoid breakage because you have a huge lever effect. For instance, if you can cut corners to save 10 hours of work, but 100 other DDs will need to spend 30 minutes each to fix the breakage as a result, it is still a bad tradeoff. OTOH, as a maintainer of an unpopular leaf package, I can get away with atrocious uploads because nobody but me will notice or care. Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭────────╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Re: How to do 32-bit build in AMD64 chroot -- problem with SSE instructions?
Hi Steve, * Steven Robbins [2021-12-12 12:56]: Can you (or anyone) confirm whether the Debian i386 build SHOULD or SHOULD NOT enable SSE of any flavour? I've googled numerous times but can't seem to find this kind of detailed port information. https://wiki.debian.org/ArchitectureSpecificsMemo#i386-1 Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Re: uscan roadmap
Hi Yadd, thank you very much for your work on uscan. That new version 5 format looks really promising. * Yadd [2021-12-01 09:11]: * Version 5: * Main (first) paragraph contains "Version: 5" and optional options that change default values for source-paragraph * URL and regex are separated * Some default values change. For example, `dversionmangle` default value will be "auto" (drop +dfsg, ~ds,...), uversionmangle=s/-/~/g, filenamemangle=s/.*?(\d[\d\.]*@ARCHIVE_EXT@)/@PACKAGE@-$1/... [...] Of course, comments are welcome! I have a feature request regarding signature verification. As luck would have it, I maintain three packages with upstream signatures; one of them is me being my own upstream, and the other two do not use the "standard" approach with one GnuPG signature per source tarball: - cmake releases its sources in multiple archive formats and signs them indirectly (a text file with SHA256 hashes) [1]. - liblzf uses the BSD signify tool [2] and only GnuPG-signs the signify key. I don't know if any of these schemes are used elsewhere (more likely for the CMake approach, less likely for liblzf, I'd guess), but it would be nice if uscan offered some support for this; maybe a hook to run the signature verification by an external script with autopkgtest semantics (fail if output occurs on stderr the script returns with a non-zero exit code). Cheers Timo [1] https://cmake.org/install/#download-verification [2] http://dist.schmorp.de/signing-key.txt -- ⢀⣴⠾⠻⢶⣦⠀ ╭────────╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Re: merged-/usr transition: debconf or not?
* Russ Allbery [2021-11-19 11:46]: I also don't understand why this isn't the correct solution. It seems obvious to me that we should simply teach dpkg about path aliases and have it update both its internal state and its processing of new packages to canonicalize paths so that it has an accurate representation of the world, and then ensure dpkg is upgraded first. +1 Are we missing something? If not, what is blocking this solution? Is it simply a matter of someone digging into dpkg's code sufficiently to put these changes in the correct location? Or is there some other issue? AFAIR, Guillem has not commented on the solution when it was brought up on d-devel [1], so I'm not sure if he would accept patches, let alone support anyone working on this. I'd be willing to assist him and contribute code, but I'm not going to spend a good chunk of my spare time just to see me work summarily rejected. Cheers Timo [1] https://lists.debian.org/debian-devel/2021/08/msg00438.html -- ⢀⣴⠾⠻⢶⣦⠀ ╭────╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Bug#998146: ITP: iceoryx -- zero-copy interprocess communication library
Package: wnpp Severity: wishlist Owner: Timo Röhling X-Debbugs-Cc: debian-devel@lists.debian.org, roehl...@debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: iceoryx Version : 1.0.1 Upstream Author : Robert Bosch GmbH, Apex.AI Inc. * URL : https://projects.eclipse.org/proposals/eclipse-iceoryx * License : Apache-2. Programming Lang: C, C++ Description : zero-copy inter-process communication library Iceoryx is an inter-process communication (IPC) middleware for POSIX based operating systems. It features shared memory capabilities which allow a true zero-copy data transfer. Originating from the automotive domain, it is crucial to transfer a huge amount of data between multiple processes to realize driver assistance systems or automated driving applications. Moreover, the same efficient communication mechanism can be applied to a broader range of use cases, e.g. in the field of robotics or game development. Iceoryx is an optional dependency of Cyclone DDS and makes DDS communication on the same host more efficient. It can also be used as stand-alone middleware for ROS 2. It will be maintained by the Debian Robotics Team. -BEGIN PGP SIGNATURE- iQGzBAEBCgAdFiEEJvtDgpxjkjCIVtam+C8H+466LVkFAmF9usIACgkQ+C8H+466 LVnRTwv+IwRr0qJthh+cUcSTI+o1watY7eRUvotWqIKorinWkcd6Yx1K7b/KnVou JxQt/hE5sC1hE1NfB2vQxa9Lz1iArmfasmUVlrCt8AxWEzpL1UmTJiFzxWQmym06 ppnBIn0eTQTxBKn/TQuw5MNRbxJVxA7Cd08Dz0czgkrbsjP9WeiudAXRLCq1JEgA cl28I5qtnqAZflFSIcX+7nqqnLirwAEAF5iuhlmx3ibff5JaHMCObxfl0RrUqbA7 pVmD7l2cY/qqxMmdPQbwb/4pqCeoX5ZFGu566PBYCSFyYu6tGaACaF98RrrpfaPN +qisfFcc7RMi5KUnterx0CUuzQHYQ+9cCIvmzTgyDOA0SovA+DXRNOoY6VtvdynN j4MfFWeYSz38Spg2j9NjS9qnPEG+zecnpnjzy65hP3nboXpcMY7Mxcn4oN8+5ZFg vcCxdO5SVLe79ytA1NgqnQ+Onijnn/2Pa36JTX3dGRu4pvigtp79gKUmZzjy6LIP DNI4OhwW =L3rW -END PGP SIGNATURE-
Bug#998144: ITP: cpptoml -- C++ header-only library for parsing TOML configuration files
Package: wnpp Severity: wishlist Owner: Timo Röhling X-Debbugs-Cc: debian-devel@lists.debian.org, roehl...@debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: cpptoml Version : 0.1.1 Upstream Author : Chase Geigle * URL : https://github.com/skystrife/cpptompl * License : Expat Programming Lang: C++ Description : C++ header-only library for parsing TOML configuration files TOML is a file format for configuration files. It is intended to be easy to read and write due to obvious semantics which aim to be "minimal", and is designed to map unambiguously to a dictionary. cpptoml is a C++ header-only library that implements the TOML 0.5.0 standard. The library is a dependency of Eclipse Iceoryx, a library for true zero-copy interprocess communication. -BEGIN PGP SIGNATURE- iQGzBAEBCgAdFiEEJvtDgpxjkjCIVtam+C8H+466LVkFAmF9uMsACgkQ+C8H+466 LVkDDQwA0xL73OT4wQppC4AEac2QbMmJgxmBE5dvB5blI7b68r7mnbHo94UGtqz4 RKa33U7FSPCX08WuULxOQ18K2GVRIQWZPu0xtlI8eRBIRd/FGY/uY1nzG3rh39rm aHlgyRuL8QMfNX/dA/B78C33VAG2hAnYH+x6ocSBHQGfKwsp7XHr7d6ToTp0cwKW /b0QZ8gu/IA5sr165Y1tgk10mbVRBOp2KBpDZ6EUv0OfZy/FSVaticMvznIKd4ee oQeNdAV875pm848/ClYz4f1PdkqOzLoWXMjD8lR4FgJ2TafAtEoCM5vQ8RXxzQvR u4dbNaSAYJIEirNvtFe+gLRYY2Aew+7xuZVVi7ruOSX6z0mIH+ACHShXu6sakK9S LFwgFH9C1y3PRnmr2kjJuJ/wa/l+f60y3LLKppJrXfIHP2CeIKManDjpTELGMBrc OYorEXhIGjk55kmMzEFPyFcTPrlE/cSA8cvpRgQYVGKcdaMVQ16ogSt2IN2bOPaz zDzq4ayI =jkk0 -END PGP SIGNATURE-
Re: gbp vs. vcswatch - how to create automatic debian tags?
* John Paul Adrian Glaubitz [2021-10-05 11:45]: Could anyone tell me what the proper gbp command is for creating the changelog entries for the new release including the proper tag. The gbp manual [1] mentions Debian tags but it doesn't seem to explain how to create them. I usually run "gbp dch -R -c" first, then build and upload the package, and finalize with "gbp tag && gbp push". And if I wanted to add the tags later manually and push them, what is the expected format of the tags? Just "debian/$VERSION"? Yes. -- ⢀⣴⠾⠻⢶⣦⠀ ╭────────╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Re: Q. What is the best practice about +dfsg and +ds extension?
* Jonas Smedegaard [2021-10-02 15:03]: I use ~ (tilde) as delimiter when possible, to make room for an eventual later release with the issues fixed, without needing ugly versioning or being forced to wait for a later upstream release. Has this actually ever happened? I would expect that most upstream authors would rather create a new patch release than retroactively change the contents of an existing one. Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Bug#994609: ITP: python-exhale -- Sphinx automated C++ API generation support
Package: wnpp Severity: wishlist Owner: Timo Röhling X-Debbugs-Cc: debian-devel@lists.debian.org, roehl...@debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: python-exhale Version : Upstream Author : Stephen McDowell * URL : https://exhale.readthedocs.io/en/latest/ * License : BSD-3-Clause Programming Lang: Python Description : Sphinx automated C++ API generation support Exhale is a Sphinx extension that depends on the excellent Breathe extension which enables parsing Doxygen documentation into the Sphinx domain. Exhale provides a layer of automation, enabling launching Doxygen and generating the full website all from your conf.py. This package is a new dependency of CycloneDDS 0.8.0. I will package and maintain it as part of the Python Team. -BEGIN PGP SIGNATURE- iQGzBAEBCgAdFiEEJvtDgpxjkjCIVtam+C8H+466LVkFAmFF7RkACgkQ+C8H+466 LVnUuwwApQrc5TjTguqoBw/Ssne1Zet6IW6m7ojoiuznb23FF60nIyV7duzsuNQq 7l9+pD72tKCTAtD/6y8FiBysIWgCbbdMhcABMG3lptJ2dmZJgrD6mOOKXEecb+y7 ieaFbmzYE2meysXb7nHd/wfg3JGzjsMfZrpRPiTnX5B0vJ6v56vYPOSwsga15OVJ n8u9XkAjPypw7jDcxgmWxmOAtk4c4iHu0SlWRnXnLDfXIC/TMboCAhvV6EeuLK38 PJHYuM+2a4EgBIaXn1wz/ZDetBhrwon42fRVAaTE/V2uH08N+uYPn3KrTHMVfp7d 4BJ46dCAyXI7uXCZY4PVs7UUps0Q1MmX51dY49OQeX71ysX//7hj0q/REsiT1FKo SboUviunhR6dILXuBY1RZr4Qo3inqCboqRuPaduVQnw4iFEbk9iEGJhcCym0Z+Xy QrwocIW1Elw43xZ7cCUXVKUQ4AibcytP3YOL2e5ZL66QCOXwCon73ijuQEbUhv03 F8kTmf9Y =rUKn -END PGP SIGNATURE-
Re: Epoch bump request for ksh
* Anuradha Weeraman [2021-09-11 21:37]: However, I feel that given ksh93u+ is unmaintained upstream, existing users of src:ksh stands to gain from the defect fixes and improvements made without having to switch to a new package given that ksh93u+m is maintaining the same code base that would have been otherwise unmaintained. This would avoid having to maintain two packages, one which is unmaintained upstream and one that is. Open to your suggestions on the way forward. https://wiki.debian.org/RenamingPackages has a few good suggestions. Maybe the transition package method would be appropriate here? You could probably put the transitional package into the new source package and use "dh_gencontrol --package=ksh -v20210511" in d/rules to make it supersede the old binary package and ensure a clean upgrade path. Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Re: Bug#992692: general: Use https for {deb,security}.debian.org by default
* Michael Stone [2021-09-08 19:25]: I think the issue isn't certificate validation, it's that https proxy requests are made via CONNECT rather than GET. You could theoretically rewrite the proxy mechanism to MITM the CONNECT, but that wouldn't be a drop-in replacement. I suppose you could instead add an apt option to pass the https request to the proxy via GET instead of using CONNECT, but I think that also won't necessarily work on an existing proxy. apt-cacher-ng has a second mode of operation where you can prefix the source URL with the proxy URL, i.e. deb http://proxyhost:3142/deb.debian.org/debian unstable main Maybe we could introduce this as an "official" APT proxy mode, where http(s)://REPO gets replaced by http://PROXY_URL/REPO (and the proxy can decide whether or not to fetch via HTTPS as an implementation detail)? Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭────╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Re: Bug#992692: general: Use https for {deb,security}.debian.org by default
* Michael Stone [2021-09-09 09:05]: Because the controversy concerning changing the default is over whether it's reasonable for someone using auto-apt-proxy to have to manage additional configuration settings. Ah, I understand your point now and I agree. It would be an inconvenience, yes, not but much more. Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Re: Bug#992692: general: Use https for {deb,security}.debian.org by default
* Michael Stone [2021-09-09 08:32]: I'm honestly not sure who the target audience for auto-apt-proxy is--apparently someone who has an infrastructure including a proxy, possibly the ability to set dns records, etc., but can't change defaults at install time or via some sort of runtime configuration management? The same reason you might want to deploy WPAD instead of preconfiguring proxy settings in web browsers: flexibility. For example, we use auto-apt-proxy for laptops which roam between different networks. It's simple to configure, has virtually no maintenance overhead and degrades gracefully. None of that speaks to whether an organization that deploys such a thing has the ability to manage other configuration settings, even if for some settings there's a desire for additional flexibility. I don't understand your point. You asked for a target audience for auto-apt-proxy. I gave you a legitimate (and real-world) example for such a deployment. Why should it matter whether or not an organization has other configuration facilities? As another example, nobody says: "the target audience for DHCP is an organization who has an infrastructure with full control over a network, including IP address management, but apparently can't configure IP addresses at install time or via some sort of runtime configuration management" and concludes that DHCP is useless. auto-apt-proxy (or DHCP for that matter) *is* the runtime configuration management, and a quite efficient one at that. Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭────────╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Re: Bug#992692: general: Use https for {deb,security}.debian.org by default
* Michael Stone [2021-09-08 19:12]: Why not simply automate setting it at install time using preseed? I'm honestly not sure who the target audience for auto-apt-proxy is--apparently someone who has an infrastructure including a proxy, possibly the ability to set dns records, etc., but can't change defaults at install time or via some sort of runtime configuration management? The same reason you might want to deploy WPAD instead of preconfiguring proxy settings in web browsers: flexibility. For example, we use auto-apt-proxy for laptops which roam between different networks. It's simple to configure, has virtually no maintenance overhead and degrades gracefully. Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭────╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Re: merged /usr vs. symlink farms
Hi, * Sam Hartman [2021-08-26 08:56]: That may not matter so much for Debian (at least in some people's minds) but being compatible with the rest of the world has enough value in this instance that I consider the issue moot. I agree that this is a very convincing argument. A considerably weaker supportive argument would also be that these symlinks are here to stay for years, possibly even decades, which makes four or five static symlinks much simpler to maintain long-term. Still, I would prefer to know in advance if there are additional technical concerns which need to be fixed or worked around. Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Re: merged /usr vs. symlink farms
* Simon Richter [2021-08-26 14:51]: It makes a lot more sense to have a dpkg-internal tool that can investigate the differences between the file system and the dpkg database, resolve conflicts (possibly in an interactive process when required by a corner case like the one I mentioned earlier -- luckily, these should be really rare) and then leave a consistent state again that allows package maintainers to use all dpkg features again after the bookworm release. Agreed. Having yet another tool messing with dpkg "behind its back" will only exacerbate the problems we're trying to solve. Also, I wouldn't say it is the *only* possible way to move forward, but it is *a* possible way. I am also still trying to understand Guillem position and his objections better. This proposal addresses one half on Guillem's objections by making dpkg's point of view consistent with the actual filesystem reality. However, Guillem also seems to think that dpkg can manage file symlinks in a real directory better than an directory symlinks in /, which is why he proposed symlink farms in the first place. Assuming dpkg implements the proposed canonicalization, is there a scenario where the aliased dirs break, but would not break with a symlink farm? My apologies if this has been answered already. Just point me to the relevant emails/wiki pages then. Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭────╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Re: Making the dpkg database correspond with reality (Was Re: merged /usr vs. symlink farms)
Hi, * Theodore Ts'o [2021-08-23 20:48]: I want to ask a potentially stupid question. [...] This is pretty much what I was wondering about in https://lists.debian.org/debian-devel/2021/08/msg00372.html You, however, phrased it much more eloquently than I could. Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Re: merged /usr vs. symlink farms
Hi,
* Simon Richter [2021-08-22 02:15]:
There are two issues here: dpkg not handling certain corner cases, and
the usemerge package modifying the file system, bypassing dpkg.
Maybe this question has been answered elsewhere, but I keep
wondering: What prevents dpkg from updating/reparing its database
to match what usrmerge did? It's not like files got shifted around
arbitrarily.
The database rewrite would be irreversable, but switching back and
forth is not a required feature anyway. And the rewrite is
idempotent, so it might even be possible to run this unconditionally
as part of some future release upgrade.
Of course, dpkg would need a path canonicalization that
transparently maps /{bin,lib*,sbin} to /usr/{bin,lib*,sbin} on *all*
file operations and is enabled together with the database
conversion. This might take some effort to code, mostly because it
must be applied consistently. Still, it's best to have this done
right in dpkg once and for all, and I'm probably not the only one
who would be willing to help.
Cheers
Timo
--
⢀⣴⠾⠻⢶⣦⠀ ╭────╮
⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │
⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │
⠈⠳⣄ ╰╯
signature.asc
Description: PGP signature
Re: Need help with Multi-Arch in systemd
* Simon McVittie [2021-07-14 11:59]: Would it be feasible for dak to have a list of binary package name regexes mapped to a source package and a section/priority, and auto-accept packages from the given source package that match the regex, assigning the given section/priority, without manual action? That would let the ftp team pre-approve src:systemd to ship /^libsystemd-shared-[0-9]+$/ in libs/optional, for example. +1 Especially considering that library packages are subject to transitions anyway, so they already receive much more scrutiny than, say, an updated Python module. Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Re: Need help with Multi-Arch in systemd
* Michael Biebl [2021-07-09 13:24]: Let me be blunt here: I'm not willing to compromise on robustness here. Well, I have had my say and ultimately, it's your package and your decision, of course. Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Re: Need help with Multi-Arch in systemd
* Michael Biebl [2021-07-09 12:29]: That tightly versioned dependency doesn't help unfortunately. There is still a time window between the new libsystemd-shared and the new systemd being unpacked. There's also a time window between files in /usr/bin and files in /usr/lib being replaced. If you reboot your system with an unfinished/interrupted upgrade, you cannot assume a consistent or bootable state. Packaging all stuff in the same package *may* reduce the above time window somewhat, but it will not eliminate the underlying problem, so it is a non-solution. There may be other reasons to object Helmut's proposal, but this is not it. Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭────╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Re: Need help with Multi-Arch in systemd
* Michael Biebl [2021-07-09 11:01]: Splitting out libsystemd-shared (once) will make PID1 very brittle. It can lead to situations where old systemd + new libsystemd-private is installed. If the installation is aborted at this point, you have an unbootable system. Helmut suggested a tightly versioned dependency, so such a state would never be consistent. And given that system updates are not atomic transactions, I'm pretty confident you can interrupt *any* update of a boot-critical package at a point that leaves the system unbootable. Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Bug#990234: ITP: jello -- Filter for JSON and JSON Lines data with Python syntax (was: RFP)
X-Debbugs-Cc: debian-devel@lists.debian.org Control: retitle -1 ITP: jello -- Filter for JSON and JSON Lines data with Python syntax Control: owner ! Hi Kelly, I think jello would be a great addition to Debian; I'm willing to package and maintain it under the Python Team umbrella. * Package name: jello Version : 1.4.2 Upstream Author : Kelly Brazil * URL : https://github.com/kellyjonbrazil/jello * License : Expat Programming Lang: Python Description : Filter for JSON and JSON Lines data with Python syntax jello is similar to jq in that it processes JSON and JSON Lines data except jello uses standard python dict and list syntax. JSON or JSON Lines can be piped into jello (JSON Lines are automatically slurped into a list of dictionaries) and are available as the variable _. Processed data can be output as JSON, JSON Lines, bash array lines, or a grep-able schema. Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Re: Planning for libidn shared library version transition
Hi Simon! * Simon Josefsson [2021-05-24 19:34]: I want to upload a new upstream libidn release into Debian, but upstream has done a shared library transition. You should probably read the Release Team documentation [1] on library transitions if you haven't done so already. Is the first step on the transition to provide a libidn-dev package experimental (and after the release, unstable) and make all reverse build-dependencies use it? Generally, it is a good idea to have a libidn-dev package instead of libidn11-dev, so +1 on that. It will avoid sourceful uploads of reverse-dependencies in the future. However, I noticed that Debian ships with the successor library libidn2 already, and its homepage says it provides a compatibility layer for libidn. So wouldn't it be better to sunset libidn in favor of the new version? Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Re: Thanks and Decision making working group (was Re: General Resolution: Statement regarding Richard Stallman's readmission to the FSF board result)
* Wouter Verhelst [2021-04-20 13:50]: Not sure whether you consider this an issue, but I don't see that as a problem. There is a difference between "we can't reach an agreement and therefore decide on a no-outcome vote" (which the default option is), and "we have considered all the options and decide that a no-outcome vote is the best result" (which an explicit no-outcome ballot option represents). I think the RMS vote was somewhat unique, because (intentional or not) the options ended up in way that was almost equivalent to asking "on a scale from -3 to 3, how strongly should Debian as organization react to the RMS reinstatement". I would consider the outcome the neutral (0) option, and FD would have been the NULL option, i.e., "we can't/won't decide". If Steve's original intent to have a binary decision for signing the open letter had prevailed, an additional "no" option would not have been nearly as useful. Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭────╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
