Bug#1066126: RFA: rust-enum-unitary -- Trait and macro for unitary enums - Rust source code
Package: wnpp Severity: normal X-Debbugs-Cc: rust-enum-unit...@packages.debian.org, debian-r...@lists.debian.org, stephanlach...@debian.org Control: affects -1 + src:rust-enum-unitary I request an adopter for the rust-enum-unitary package. If you adopt this package, please remove me from the uploaders list. The package description is: This package contains the source for the Rust enum-unitary crate, packaged by debcargo for use with cargo and dh-cargo.
Bug#1066127: RFA: rust-kmon -- Interactive kernel monitor that combines dmesg and kmod
Package: wnpp Severity: normal X-Debbugs-Cc: rust-k...@packages.debian.org, debian-r...@lists.debian.org, stephanlach...@debian.org Control: affects -1 + src:rust-kmon I request an adopter for the rust-kmon package. If you adopt this package, please remove me from the uploaders list. The package description is: kmon is an interactive kernel monitor for the terminal. It can insepct and load kernel modules, and it can monitor kernel activity. It basically combines dmesg and kmod into one application. Note that is probably needs to run as root.
Bug#1066125: RFA: rust-enum-iterator-derive -- Procedural macro to iterate over the variants of a field-less enum - Rust source code
Package: wnpp Severity: normal X-Debbugs-Cc: rust-enum-iterator-der...@packages.debian.org, debian-r...@lists.debian.org, stephanlach...@debian.org Control: affects -1 + src:rust-enum-iterator-derive I request an adopter for the rust-enum-iterator-derive package. If you adopt this package, please remove me from the uploaders list. The package description is: This package contains the source for the Rust enum-iterator-derive crate, packaged by debcargo for use with cargo and dh-cargo.
Bug#1066124: RFA: rust-enum-iterator -- Tools to iterate over the variants of a field-less enum - Rust source code
Package: wnpp Severity: normal X-Debbugs-Cc: rust-enum-itera...@packages.debian.org, debian-r...@lists.debian.org, stephanlach...@debian.org Control: affects -1 + src:rust-enum-iterator I request an adopter for the rust-enum-iterator package. If you adopt this package, please remove me from the uploaders list. The package description is: This package contains the source for the Rust enum-iterator crate, packaged by debcargo for use with cargo and dh-cargo.
Bug#1066123: RFA: rust-colorsys -- Module for color conversion and mutation - Rust source code
Package: wnpp Severity: normal X-Debbugs-Cc: rust-color...@packages.debian.org, debian-r...@lists.debian.org, stephanlach...@debian.org Control: affects -1 + src:rust-colorsys I request an adopter for the rust-colorsys package. If you adopt this package, please remove me from the uploaders list. The package description is: Works with RGB(a)( as hexadecimal too), HSL(a), CMYK color models and with ANSI color codes . This package contains the source for the Rust colorsys crate, packaged by debcargo for use with cargo and dh-cargo.
Bug#1063076: asio: binary-any FTBFS
Ah shit, ftp-masters reject my new version to DEFERRED without notifying me but email. Thanks for the pointer, will fix it ASAP. Cheers, Stephan
Bug#1018679: libmsgpack-dev: Remove "Depends: libmsgpack-cxx-dev"
Hi James, I saw that you wrote patches for rocblas and dials, thanks a lot for this! Both have been uploaded since then. Since this were the last blockers, can we go ahead with this transition? Cheers, Stephan
Bug#1061497: msgpack-cxx: Please update to 6.1.0
Hi James, thanks for your swift replay and thanks for the bug report! I was not aware of it. Regarding the transition, the only missing package according to #1018679 is autobahn-cpp (#1019114), which is orphaned. However, there are indeed new packages that have appeared since then that depend on libmsgpack-dev: - neovim - dials - tmate-ssh-server - libdata-messagepack-stream-perl - tamte - rocblas - groonga - webdis - neovim-qt - libdata-messagepack-perl I did a quick codesearch via https://codesearch.debian.net/search?q=msgpack.hpp to find out which of those packages actually depend on msgpack-cxx: - ring - rocblas - dials - libdata-messagepack-stream-perl (unsure) Is there anything I can do to help speed up this transition? Given that number of affected packages is quite small, I don't think a forceful transition for the C++ library would be a problem (that is, removing libmsgpack-cxx-dev from libmsgpack-dev and updating msgpack-cxx). I am willing to invest time in writing bug reports and patches if you think this is doable before Feb 29th. Cheers, Stephan
Bug#1061497: msgpack-cxx: Please update to 6.1.0
Package: msgpack-cxx Severity: wishlist X-Debbugs-Cc: james...@debian.org, stephanlach...@debian.org Hi, would it be possible to upload msgpack 6.1.0 to Debian unstable soon? It would be nice to have the v6 API in Ubuntu 24.04 LTS, for which the import freeze is on the 29th February. I can also upload it as NMU if you want. Cheers, Stephan -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.6.13-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1054750: reuse: FTBFS: make: *** [debian/rules:4: binary] Error 1
Caused by dh-python #1055008
Bug#1055008: dh-python tries to remove LICENSES folder causing FTBFS
Package: dh-python
Version: 6.20231025
Severity: important
X-Debbugs-Cc: stephanlach...@debian.org
A recent change in dh-python [1] causes an FTBFS in reuse [2].
In particular, this is the error that causes the FTBFS:
```
dh_python3 -O--buildsystem=pybuild
Traceback (most recent call last):
File "/usr/bin/dh_python3", line 292, in
main()
File "/usr/bin/dh_python3", line 218, in main
fix_locations(package, interpreter, SUPPORTED, options)
File "/usr/share/dh-python/dhpython/fs.py", line 51, in fix_locations
share_files(srcdir, dstdir, interpreter, options)
File "/usr/share/dh-python/dhpython/fs.py", line 117, in share_files
share_files(fpath1, fpath2, interpreter, options)
File "/usr/share/dh-python/dhpython/fs.py", line 100, in share_files
os.remove(fpath1)
IsADirectoryError: [Errno 21] Is a directory:
'debian/reuse/usr/lib/python3.11/dist-packages/reuse-2.1.0.dist-info/LICENSES'
```
The following lines cause this bug:
```python3
if i.startswith(('LICENCE', 'LICENSE', 'COPYING', 'NOTICE', 'AUTHORS')):
os.remove(fpath1)
```
Instead of just blindly removing `fpath1`, it should be checked if this is a
file or a folder, and if it is a folder then `rmtree(fpath1)` should be called.
Alternatively a better file matching could be done (e.g. by checking the
filename before the file extension properly using pathlib).
Regards,
Stephan
[1]: https://salsa.debian.org/python-team/tools/dh-
python/-/commit/87907e588d1fc1ed52c5af4b9a7bded6327d
[2]: https://bugs.debian.org/1054750
-- System Information:
Debian Release: trixie/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 6.5.9-x64v3-xanmod1 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages dh-python depends on:
ii python3 3.11.4-5+b1
ii python3-distutils 3.11.5-1
ii python3-setuptools 68.1.2-2
dh-python recommends no packages.
Versions of packages dh-python suggests:
ii dpkg-dev 1.22.0
pn flit
ii libdpkg-perl 1.22.0
pn python3-build
pn python3-installer
ii python3-wheel 0.41.2-1
-- no debconf information
Bug#1054621: lutris: new dependencies
The new dependencies are marked as hard dependencies from upstream, we just mirror their debian packaging with as little adjustments as possible. I unfortunately do not have the time to look into whether the dependencies are actually hard or not. If you have the time, feel free to open an issue upstream and resolve the issue there. Regards, Stephan
Bug#1052421: ITP: control -- Python Control Systems Library
Hi, please go with python-control for the source package name. This is required for consistency with https://repology.org/. Regards, Stephan On Fri, Sep 22, 2023 at 12:30 AM Kurva Prashanth wrote: > > On 2023-09-21 23:50, Christoph Biedl wrote: > > Kurva Prashanth wrote... > > > >> * Package name: control > >> Version : 0.9.4 > >> Upstream Author : >> > > >> * URL : http://python-control.org/ > > > > While I cannot judge whether this package is a sensible addition to > > Debian - I strongly ask you to re-consider the package name as "control" > > can apply to many different areas, and is therefore not helping when > > trying to figure if that package helps in a particular situation. > > Also, as there's the debian/control file in each source package, this > > will create some confusion and possibly even to users asking you for > > help with their packaging. > > > > Just from the above website, perhaps something like > > python-feedback-control-systems or a bit shorter variant would be more > > appropriate. I might be wrong. > > > > Christoph > I get what you're saying. Yes, "control" is a bit too general in deb > source packages. Your suggestion of "python-feedback-control-systems" > makes sense, and we'll I change package name. > > Regards, > Kurva Prashanth >
Bug#1050339: RFP: python-annotated-types -- metadata objects for python annotations
Package: wnpp Severity: wishlist X-Debbugs-Cc: stephanlach...@debian.org * Package name: python-annotated-types Version : 0.5.0 Upstream Contact: Zac Hatfield-Dodds * URL : https://github.com/annotated-types/annotated-types/ * License : MIT Programming Lang: Python Description : metadata objects for python annotations >From GitHub: PEP-593 added typing.Annotated as a way of adding context-specific metadata to existing types, and specifies that Annotated[T, x] should be treated as T by any tool or library without special logic for x. This package provides metadata objects which can be used to represent common constraints such as upper and lower bounds on scalar values and collection sizes, a Predicate marker for runtime checks, and descriptions of how we intend these metadata to be interpreted. In some cases, we also note alternative representations which do not require this package. Not really important to me, but python3-iminuit has a possible test case using this package.
Bug#1035506: please update libliftoff
Thanks, uploaded
Bug#1035506: New upstream version 0.4.0
On Thu, 4 May 2023 12:26:28 +0200 Guido =?iso-8859-1?Q?G=FCnther?= wrote: > There's a new upstream version 0.4.1 > > https://gitlab.freedesktop.org/emersion/libliftoff/-/tags/v0.4.1 > > Would be great to have that in experimental as current sway, wlroots > requires it. > Cheers, > -- Guido Hi Guido, unfortunately I'm massively overworked right now, so I will not upload anything before the freeze ends. But feel free to to update it yourself, the Salsa repo is here: https://salsa.debian.org/debian/libliftoff Should be straight forward. Cheers, Stephan
Bug#1034098: reportbug: gamemode needs policykit-1 as a dependency
Hi Safir, thanks for the report. Can you open a MR on Salsa with this change? https://salsa.debian.org/games-team/gamemode Regards, Stephan
Bug#1032486: goverlay: Please add libglu1-mesa as a runtime dependency.
Hi Safir, thanks for the details. However I'm not sure if this is related to GOverlay. Can you reproduce this with just `mangohud --dlsym glxgears`? Cheers, Stephan
Bug#1032486: goverlay: Please add libglu1-mesa as a runtime dependency.
Hi Safir, can you provide more details why libglu1-mesa is required by GOverlay? I don't see any hints for it upstream. Regards, Stephan
Bug#1030392: ITP: python-moddb -- python module to scrape the ModDB.com website
Package: wnpp Severity: wishlist Owner: Stephan Lachnit X-Debbugs-Cc: debian-de...@lists.debian.org, stephanlach...@debian.org * Package name: python-moddb Version : 0.8.1 Upstream Contact: Clement Julia * URL : https://github.com/ClementJ18/moddb/ * License : MIT Programming Lang: python Description : python module to scrape the ModDB.com website Dependency for upcoming lutris version. Will be maintained in Games Team.
Bug#1029969: ITP: clad -- automatic differentiation for C/C++
Package: wnpp Severity: wishlist Owner: Stephan Lachnit X-Debbugs-Cc: debian-de...@lists.debian.org, stephanlach...@debian.org * Package name: clad Version : 1.1 Upstream Contact: Vassil Vassilev * URL : https://github.com/vgvassilev/clad * License : LGPL-3.0 Programming Lang: C, C++ Description : automatic differentiation for C/C++ Clad enables automatic differentiation (AD) for C++. It is based on LLVM compiler infrastructure and is a plugin for Clang compiler. Clad is based on source code transformation. Given C++ source code of a mathematical function, it can automatically generate C++ code for computing derivatives of the function. It supports both forward-mode and reverse-mode AD. Clad has extensive coverage of modern C++ features and a robust fallback and recovery system in place. Will maintain in the science team. Feature for ROOT.
Bug#1017679: RM: llvm-toolchain-13 -- ROM; Limit the number of llvm versions
Please don't remove LLVM 13 - ROOT [1] finally updated to LLVM 13 [2]. This allows to build ROOT without the builtin LLVM copy, which dramatically reduces build time and also brings Debian packaging of ROOT a lot closer to reality. I consider ROOT to be quite an important package considering it is unavoidable in HEP and upstream is open to make changes so that ROOT can get an official Debian package. If LLVM 13 would be removed before ROOT makes a transition to a newer LLVM version this would make the packaging efforts mostly useless. Note that I don't care about trixie for now, just please don't remove it from unstable after the bookworm release. Cheers, Stephan [1]: https://bugs.debian.org/981113 [2]: https://github.com/root-project/root/pull/10294
Bug#1016722: cvmfs sponor
Hi Benda, sorry for the late reply, I just didn't have time to look into it. I am not able to build it from Salsa since I can't find the proper source tarball - [1] does not seem to work. Could you write a `debian/watch file` (see [2] for details) for easy downloading of the source tarball? Otherwise I think you should remove the unused externals in the `externals` folder - you can do this via `debian/copyright` (see e.g. [3], multiple lines allowd) Cheers, Stephan [1]: https://ecsft.cern.ch/dist/cvmfs/cvmfs-2.9.4/source.tar.gz [2]: https://manpages.debian.org/unstable/devscripts/uscan.1.en.html [3]: https://salsa.debian.org/science-team/root/-/blob/193bb0bd05fd2da77549a8938d79301ca70a7466/debian/copyright#L5
Bug#1028207: ITP: vkroots -- framework for writing Vulkan layers that takes all the complexity away
Package: wnpp Severity: wishlist Owner: Stephan Lachnit X-Debbugs-Cc: debian-de...@lists.debian.org, stephanlach...@debian.org * Package name: vkroots Version : git Upstream Contact: Joshua Ashton * URL : https://github.com/Joshua-Ashton/vkroots * License : Apache-2.0 OR MIT Programming Lang: C++ Description : framework for writing Vulkan layers that takes all the complexity away Required for latest gamescope. Will be maintained under the Games Team.
Bug#1020595: marked as pending in tomlplusplus
On Mon, 7 Nov 2022 16:22:54 +0100 Bastian Germann wrote: > What is the status of this? Is Stephan still intending to sponsor > tomlplusplus? I currently lack time for Debian work. I would still do it before the freeze since I also need to upload some other things before that, but if you have the capacity please go ahead. Regards, Stephan
Bug#1023164: ITP: libtomlplusplus -- TOML config file parser and serializer for C++17
Duplicate of #1020595 [1]. Cheers, Stephan [1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1020595
Bug#312552: unrar-free: request for RAR 3.0 format support
On Wed, 13 Oct 2021 10:56:38 +0200 Bastian Germann wrote: > There is a new upstream version with RAR 3.0 and RAR 5.0 support via > libarchive. > A debdiff for that version is included. Does anyone plan to upload version >= 0.1.0? If not, I would be willing to do an NMU. Cheers, Stephan
Bug#1020294: reuse: rejects custom license name as invalid
Hi Ansgar, sorry for the late reply - this seems like an upstream issue to me, can you forward it please? [1] Cheers, Stephan PS: I've seen your mail about adding REUSE headers to other projects, really nice! I hope one day we can create d/copyright on the fly with REUSE... [1]: https://github.com/fsfe/reuse-tool/issues/new
Bug#1018459: Maintainer proposed patch to remove dep
Hi Felix, I'm terribly sorry that I didn't find the time to upload this earlier - I'm glad you found another sponsor. Please feel free to annoy me with pings in the future so that I don't forget things like this :) Cheers, Stephan
Bug#1020595: ITP: tomlplusplus -- TOML config parser and serializer for C++17
Hi Andrea, I find this library interesting as well, ping me if you need a sponsor. Cheers, Stephan On Sat, Sep 24, 2022 at 12:03 AM Andrea Pappacoda wrote: > Package: wnpp > Severity: wishlist > Owner: Andrea Pappacoda > X-Debbugs-Cc: debian-de...@lists.debian.org > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > * Package name: tomlplusplus > Version : 3.2.0 > Upstream Author : Mark Gillard au> > * URL : https://marzer.github.io/tomlplusplus/ > * License : MIT/Expat > Programming Lang: C++ > Description : TOML config parser and serializer for C++17 > > Features: > - - Supports the latest TOML release (v1.0.0), plus optional support for > some > unreleased TOML features > - - Passes all tests in the toml-test suite > - - Supports serializing to JSON and YAML > - - Proper UTF-8 handling (incl. BOM) > - - C++17 (plus some C++20 features where available, e.g. experimental > support > for char8_t strings) > - - Doesn't require RTTI > - - Works with or without exceptions > - - Tested on Clang (6+), GCC (7+) and MSVC (VS2019) > - - Tested on x64, x86 and ARM > > I've used this library in the past, and I was surprised to find out that > it is > not available in Debian. > > > -BEGIN PGP SIGNATURE- > > iIoEARYIADIWIQS6VuNIvZRFHt7JcAdKkgiiRVB3pwUCYy4sExQcYW5kcmVhQHBh > cHBhY29kYS5pdAAKCRBKkgiiRVB3p7IMAP9BKJ8/B6nrKHvKzREXrz8n2nqxGRr5 > Yuc+QCCNtjOL0wD+IWVXon6q2S5n4SUSMqRzAWw0zJXc7OppfpTaKzk7cgQ= > =dCnP > -END PGP SIGNATURE- > >
Bug#1019961: ITP: fast-float -- Implementation of the C++ from_chars functions for float and double types
While short on time, I have a interest in rapidyml, so you can try to ping me. Also maybe ask Gürkan Myczko (CC). Regards, Stephan
Bug#1019487: libembree-dev should depend on libtbb-dev
Package: libembree-dev Version: 3.13.4+dfsg-1 Severity: important Tags: patch X-Debbugs-Cc: stephanlach...@debian.org During a rebuild of VecGeom, I noticed that it fails from Embree: ``` CMake Error at /usr/lib/x86_64-linux-gnu/cmake/embree-3.13.4/embree- config.cmake:53 (FIND_PACKAGE): By not providing "FindTBB.cmake" in CMAKE_MODULE_PATH this project has asked CMake to find a package configuration file provided by "TBB", but CMake did not find one. Could not find a package configuration file provided by "TBB" with any of the following names: TBBConfig.cmake tbb-config.cmake Add the installation prefix of "TBB" to CMAKE_PREFIX_PATH or set "TBB_DIR" to a directory containing one of the above files. If "TBB" provides a separate development package or SDK, be sure it has been installed. Call Stack (most recent call first): CMakeLists.txt:388 (find_package) -- Configuring incomplete, errors occurred! ``` This can be simply fixed by adding libtbb-dev to the build dependencies. However, this dependency should be added to libembree-dev. Cheers, Stephan -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.19.0-1-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libembree-dev depends on: ii libembree3-3 3.13.4+dfsg-1 libembree-dev recommends no packages. Versions of packages libembree-dev suggests: pn embree-tools -- no debconf information
Bug#1017716: ITP: muon-meson -- Meson-compatible build system
Hi Andrea, I would ofc sponsor this when it is ready to upload. Wrt to the executable name: have you talked to upstream yet? I'm sure Debian isn't the only distro that has the muon problem, and I'm sure the maintainer would not like to see this program having different names on different distros. Maybe it also makes sense to talk to upstream KDE if they might consider renaming the executable (even though it is dead, I think everyone could tag a minor release with such a change). I think we should definitely avoid that muon has a non-standard binary name. It is used e.g. as meson build files formatter in certain IDE extensions, and they will not be aware of this. Regards, Stephan On Fri, Aug 19, 2022 at 2:00 PM Andrea Pappacoda wrote: > Package: wnpp > Severity: wishlist > Owner: Andrea Pappacoda > X-Debbugs-Cc: debian-de...@lists.debian.org > > * Package name: muon-meson > Version : git HEAD > Upstream Author : Stone Tickle > * URL : https://muon.build > * License : GPL-3.0 > Programming Lang: C > Description : Meson-compatible build system > > muon is an implementation of the Meson build system in c99 with > minimal dependencies. > . > It uses libpkgconf for dependency discovery, and is close to > feature-complete with the core of Meson for C and C++. > > While still not "stable", muon is capable of compiling quite complex C and > C++ > projects, and being written in C99 it can greatly help with > bootstrappability > when compared to Meson's dependency on a Python interpreter and standard > library. > > The upstream name is "muon", but this package and /usr/bin/ name is already > used by KDE Muon, a [dead] synaptic alternative. > > I'm not sure how to handle this conflict; naming the Debian package "muon- > meson" or "muon-build" seems fine, but renaming the "muon" binary might be > less > desirable. > > [dead]: https://www.reddit.com/r/kde/comments/wrnuq3/is_muon_dead/ > >
Bug#1018223: ITP: zarchive -- Library for creating and reading zstd-compressed file archives
Hi Andrea, I would love to see cemu in Debian, so I'll gladly sponsor zarchive and cemu once you think it is ready to review. Regards, Stephan On Sat, Aug 27, 2022 at 1:00 PM Andrea Pappacoda wrote: > Package: wnpp > Severity: wishlist > Owner: Andrea Pappacoda > X-Debbugs-Cc: debian-de...@lists.debian.org > > * Package name: zarchive > Version : 0.1.1 > Upstream Author : Exzap > * URL : https://github.com/Exzap/ZArchive > * License : MIT-0 > Programming Lang: C++ > Description : Library for creating and reading zstd-compressed file > archives > > ZArchive is yet another file archive format. Think of zip, tar, 7z, etc. > but > with the requirement of allowing random-access reads and supporting > compression. > > This is a dependency of cemu, see #1018037 > >
Bug#1018459: Maintainer proposed patch to remove dep
Hi Felix, Thank you for quickly taking care of this, please ping me again when the new version is ready to upload. Cheers, Stephan On Tue, Aug 30, 2022 at 7:24 PM Moessbauer, Felix < felix.moessba...@siemens.com> wrote: > Hi, > > > > I just got into contact with the upstream maintainer. > He already proposed a patch to remove this dependency and is willing to > cut a new release after we tested this. > > Then I’ll bump the version and close the bug (via Stephan). > > > > [1] https://github.com/purcell/airspeed/issues/59 > > -- > > Siemens AG, Linux Expert Center > Otto-Hahn-Ring 6, 81739 München, Germany > > >
Bug#1017594: cppzmq-dev: missing Replaces
As per policy: > This usage of Replaces only takes effect when both packages are at > least partially on the system at once. It is not relevant if the > packages conflict unless the conflict has been overridden. If I get this paragraph right, this will never happen since cppzmq breaks zeromq3 << 4.3.4-3 anyway and a) zeromq3 has no dependency on cppzmq at all b) cppzmq is in a different source package, so dpkg will upgrade zeromq3 and then install cppzmq At least I had no installation problems. Let me know if I got this wrong. Regards, Stephan
Bug#1017432: horizon-eda: zmq.hpp now in cppzmq-dev
Source: horizon-eda Version: 2.2.0-1 Severity: serious Tags: patch ftbfs Justification: fails to build from source (but built successfully in the past) X-Debbugs-Cc: stephanlach...@debian.org The zmq.hpp header moved from libzmq3-dev to cppzmq-dev. To fix this just replace libzmq3-dev with cppzmq-dev in d/control. Regards, Stephan -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.18.0-4-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#972785: zeromq3: Include cmake files for cppzmq
Hi Laszlo, ah ok, I thought maybe you just missed the mail. Anyway, of course I can ping users of the headers as I introduced the new package. Regards, Stephan On Mon, Aug 15, 2022 at 6:51 PM László Böszörményi (GCS) wrote: > Hi Stephan, > > On Mon, Aug 15, 2022 at 5:27 PM Stephan Lachnit > wrote: > > Sorry to annoy you, but please upload a new version of zeromq3, without > it cppzmq is uninstallable. > Wanted to ping users of those header files to update their build > dependencies. But then please do it yourself as you ship those files > now. > > Regards, > Laszlo/GCS >
Bug#972785: zeromq3: Include cmake files for cppzmq
Hi Laszlo, Sorry to annoy you, but please upload a new version of zeromq3, without it cppzmq is uninstallable. Regards, Stephan
Bug#972785: zeromq3: Include cmake files for cppzmq
Hi Laszlo, cppzmq was accepted [1], so you can proceed with uploading zeromq3. Cheers and thanks for maintaining zeromq, Stephan [1] https://tracker.debian.org/pkg/cppzmq
Bug#1016722: ITP: cvmfs -- The CernVM File System
Hi, that would be very useful to have indeed! I looked at this very briefly and figured it is probably not trivial to package, so good luck. Let me know if you need a sponsor or any other help for this. Cheers, Stephan On Sat, Aug 6, 2022 at 8:18 AM Yachen Wang wrote: > Package: wnpp > Severity: wishlist > Owner: Yachen Wang > X-Debbugs-Cc: debian-de...@lists.debian.org > > * Package name: cvmfs > Version : 2.9.4 > Upstream Author : CernVM Administrator (cvmadmin) < > cernvm.administra...@cern.ch> > * URL : https://github.com/cvmfs/cvmfs > * License : BSD 3-Clause, MIT, CC0-1.0, Apache-2.0 > Programming Lang: C++, Go > Description : The CernVM File System > > The CernVM File System provides a scalable, reliable and low-maintenance > software distribution service. It was developed to assist High Energy > Physics (HEP) collaborations to deploy software on the > worldwide-distributed computing infrastructure used to run data processing > applications. > > Although cvmfs is already packaged by cern, it will be more convenient > to deploy related software if distributed by Debian. > >
Bug#1016470: RFP: muon-meson -- an implementation of the meson build system
Package: wnpp Severity: wishlist X-Debbugs-Cc: stephanlach...@debian.org * Package name: muon-meson Version : any Upstream Author : https://git.sr.ht/~lattis/ * URL : https://muon.build/ * License : GPL v3 Programming Lang: C99 Description : an implementation of the meson build system muon is an implementation of the meson build system in c99 with minimal dependencies. It is interesting because it has some features that meson does not: - muon analyze - a static analyzer for meson.build files. Capable of doing type inference, checking unused variables, undeclared variables, etc. - muon fmt_unstable - a meson.build code formatter - An interactive stepping debugger with the dbg() function. muon is close to feature-complete with the core of meson for C and C++ (but still in early development IMHO). I think it should be fairly easy to package due to using meson and the minimal dependencies, but I won't put the time into packaging it (yet).
Bug#972785: zeromq3: Include cmake files for cppzmq
Hi, I want to tackle this issue again - I really want to package cppzmq as a separate package. Besides the already mentioned reason for not needing to patch downstream build systems, there is also the advantage that you can actually see from apt which version of cppzmq is in Debian. Also, I added pkg-config support. While yes, cppzmq is header only and you don't __need__ a pkg-config lookup, it is much simpler to just add `dependency(cppzmq)` than to check for the headers and depend on libzmq. Additionally I have added an autopkgtest, which is a nice bonus. Anyway, the change is relatively easy: I already have the packaging done in Salsa [1] and filled an ITP [2]. As I am a DD I can upload and maintain it, the only thing I need from you Laszlo is to remove zmq.hpp and zmq_addon.hpp from the binary package and add cppzmq in Suggests (which should be very low effort). I think it is also a good idea to write a NEWS entry so that users will know about the change, though I think this is not that important if you don't want to put in that much effort. To do the migration, I would first put cppzmq in NEW (after your ok), and after it has been accepted in NEW you would upload the new version of zeromq3. Overall I think the transition will be less painful than patching build systems downstream (and annoying Debian users that write software using the CMake files). [1]: https://salsa.debian.org/debian/cppzmq [2]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1016347
Bug#1016347: ITP: cppzmq -- C++ bindings for libzmq (headers)
Package: wnpp Severity: wishlist Owner: Stephan Lachnit X-Debbugs-Cc: debian-de...@lists.debian.org, stephanlach...@debian.org, gor...@chronitis.net, g...@debian.org * Package name: cppzmq Version : 4.8.1 Upstream Author : Gudmundur Adalsteinsson * URL : https://github.com/zeromq/cppzmq * License : MIT Programming Lang: C++ Description : C++ bindings for libzmq (headers) This package constains the default C++ headers for libzmq. The two headers (zmq.hpp and zmq_addon.hpp) are currently already contained in libzmq3-dev (src:zeromq3). However, the package does not provide the CMake packaging scripts. Also, there is a pending pull request to add a pkg-config file, so it makes sense to split this into a separate package. There was already an discussion to separate the headers in #972785 [2], but nothing happened from there. The packaging is done at https://salsa.debian.org/debian/cppzmq. [1]: https://github.com/zeromq/cppzmq/pull/564 [2]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=972785
Bug#989085: ITP: gamescope -- micro-compositor for games
Update: packaging is now available at https://salsa.debian.org/games-team/gamescope. Almost done, I will probably upload it next week :) Cheers, Stephan
Bug#1013425: ITP: wnpp -- Python Airspeed is a powerful templating engine compatible with Velocity for Java
Uploaded as well! (Comment on shtab ITP applies here as well) Cheers, Stephan On Mon, Jul 4, 2022 at 12:30 PM Moessbauer, Felix < felix.moessba...@siemens.com> wrote: > Hi Stephan, > > > > Thanks for the review. I changed the name of the package, renamed the > project on salsa and cut the release. > > This one should be ready to be uploaded. > > > > Happy Coding! > > Felix > > > > *From:* Stephan Lachnit > *Sent:* Sunday, July 3, 2022 11:43 AM > *To:* Moessbauer, Felix (T CED SES-DE) > *Cc:* 1013...@bugs.debian.org > *Subject:* Re: Bug#1013425: ITP: wnpp -- Python Airspeed is a powerful > templating engine compatible with Velocity for Java > > > > Hi Felix, > > > > Looking good as well. Please also rename the source to python-airspeed and > do a dch -r, then I'll upload. > > > > Cheers, > > Stephan > > > > On Thu, Jun 30, 2022 at 9:19 AM Stephan Lachnit > wrote: > > Hi Felix, > > > > If there is nobody else, I can sponsor this as well. Will try to find some > time on Sunday to review your work :) > > > > Cheers, > > Stephan > > > > On Wed, Jun 29, 2022 at 4:53 PM Moessbauer, Felix < > felix.moessba...@siemens.com> wrote: > > Dear maintainers, > > the initial packaging for python3-airspeed is now ready at [1] and has a > green salsa CI. > It should be ready for a review. > > @Stephan: Would you like to sponsor this package as well? > > [1] https://salsa.debian.org/python-team/packages/airspeed > <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsalsa.debian.org%2Fpython-team%2Fpackages%2Fairspeed=05%7C01%7Cfelix.moessbauer%40siemens.com%7C12c8e91803f2425eac3408da5cd8728d%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637924381944910507%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=hIHf6BGVN6PYFT%2FBhgmHAl5ksLaKuKxjMC%2BPTfYIOoA%3D=0> > > Best regards, > Felix Moessbauer > Siemens AG > >
Bug#1012761: ITP: shtab -- generator for shell tab completion files for python projects
Thanks, uploaded! FYI: you might be interested in running lintian with `lintian --pedantic -I -E`, there are some optional things that are relatively easy to fix (but none are important if you lack the time). Also, you might want to add the Debian CI running pytest, it is really easy: https://salsa.debian.org/python-team/packages/python-headerparser/-/blob/debian/latest/debian/tests/pytest. Again not really important, you can also just do it when there is a new release. Cheers, Stephan On Mon, Jul 4, 2022 at 12:32 PM Moessbauer, Felix < felix.moessba...@siemens.com> wrote: > Hi Stephan, > > > > Thanks for the review. I changed the name of the package, renamed the > project on salsa and cut the release. > > This one should be ready to be uploaded. > > > > PS: Looks like the repology site currently has some TLS issues. > > > > Happy Coding! > > Felix > > > > *From:* Stephan Lachnit > *Sent:* Sunday, July 3, 2022 11:35 AM > *To:* Moessbauer, Felix (T CED SES-DE) > *Cc:* 1012...@bugs.debian.org > *Subject:* Re: ITP: shtab -- generator for shell tab completion files for > python projects > > > > Hi Felix, > > > > The package is looking good so far, I only request one change, namely > renaming the source package from shtab to python-shtab. The reason for this > prefix is that else repology.org > <https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Frepology.org%2F=05%7C01%7Cfelix.moessbauer%40siemens.com%7C4fc331a448bf41d9ddef08da5cd74b31%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637924377004473576%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=LzOv7h88VjrbLZ6L%2B32Jc0CL8PIM4xCNU68LQAWJeC8%3D=0> > won't be able to map the package automatically. > > > > Cheers, > > Stephan > > > > On Wed, Jun 22, 2022 at 9:25 PM Stephan Lachnit > wrote: > > Hi Felix, > > > > I will take a look at the package sometime next week. I'm currently > packing my stuff to move to Geneva, so I don't really have that much time > right now. Feel free to ping though in case I forget :) > > > > Cheers, > > Stephan > > > > On Tue, Jun 21, 2022 at 4:30 PM Moessbauer, Felix < > felix.moessba...@siemens.com> wrote: > > Dear maintainers, > > the initial packaging of shtab is implemented in [1] and should be ready > for a review. > > @stephan It would be great if you could sponsor this package. > We talked about that at Debian Reunion Hamburg. > > [1] https://salsa.debian.org/python-team/packages/shtab > <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsalsa.debian.org%2Fpython-team%2Fpackages%2Fshtab=05%7C01%7Cfelix.moessbauer%40siemens.com%7C4fc331a448bf41d9ddef08da5cd74b31%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637924377004473576%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=IJNiSmE%2BPaFs4RfhI9SftWKZkaL2lD4StdeaDTXO6iE%3D=0> > > Best regards, > Felix Moessbauer > Siemens AG > >
Bug#1013425: ITP: wnpp -- Python Airspeed is a powerful templating engine compatible with Velocity for Java
Hi Felix, Looking good as well. Please also rename the source to python-airspeed and do a dch -r, then I'll upload. Cheers, Stephan On Thu, Jun 30, 2022 at 9:19 AM Stephan Lachnit wrote: > Hi Felix, > > If there is nobody else, I can sponsor this as well. Will try to find some > time on Sunday to review your work :) > > Cheers, > Stephan > > On Wed, Jun 29, 2022 at 4:53 PM Moessbauer, Felix < > felix.moessba...@siemens.com> wrote: > >> Dear maintainers, >> >> the initial packaging for python3-airspeed is now ready at [1] and has a >> green salsa CI. >> It should be ready for a review. >> >> @Stephan: Would you like to sponsor this package as well? >> >> [1] https://salsa.debian.org/python-team/packages/airspeed >> >> Best regards, >> Felix Moessbauer >> Siemens AG >> >
Bug#1012761: ITP: shtab -- generator for shell tab completion files for python projects
Hi Felix, The package is looking good so far, I only request one change, namely renaming the source package from shtab to python-shtab. The reason for this prefix is that else repology.org won't be able to map the package automatically. Cheers, Stephan On Wed, Jun 22, 2022 at 9:25 PM Stephan Lachnit wrote: > Hi Felix, > > I will take a look at the package sometime next week. I'm currently > packing my stuff to move to Geneva, so I don't really have that much time > right now. Feel free to ping though in case I forget :) > > Cheers, > Stephan > > On Tue, Jun 21, 2022 at 4:30 PM Moessbauer, Felix < > felix.moessba...@siemens.com> wrote: > >> Dear maintainers, >> >> the initial packaging of shtab is implemented in [1] and should be ready >> for a review. >> >> @stephan It would be great if you could sponsor this package. >> We talked about that at Debian Reunion Hamburg. >> >> [1] https://salsa.debian.org/python-team/packages/shtab >> >> Best regards, >> Felix Moessbauer >> Siemens AG >> >
Bug#1007742: ITP: solo2 -- command line interface for SoloKeys Solo 2 security key
Thanks for the update! I'm a bit limited with free time, but I've done Rust packaging before, so maybe I'll take a look at one of those when I have time. So updates on the ITP would be welcome :) Regards and thanks for your work, Stephan On Sun, Jul 3, 2022 at 11:19 AM Philip Rinn wrote: > Hi Stephan, > > On 03.07.22 at 11:07, Stephan Lachnit wrote: > > I would love to sponsor this. Are there any updates on packaging? Your > > Salsa repository is empty. > > great. I'm currently packaging the enormous amount of dependencies. I do > this with the rust team, so sponsoring it not an issue at the moment. > > The approximate dependency tree which I try to package is > > solo2 v0.2.0 > ├── anyhow v1.0.58 (in debian) > > ├── atty v0.2.14 (in debian) > > ├── chrono v0.4.19 (in debian) > > ├── clap v3.2.5 (in debian) > > ├── clap_complete v3.2.1 (in debian) > > ├── ctrlc v3.2.2 (in debian) > > ├── data-encoding v2.3.2 (in debian) > > ├── dialoguer v0.9.0 > > │ ├── console v0.15.0 > > │ │ ├── libc v0.2.126 (in debian) > > │ │ ├── once_cell v1.12.0 (in debian) > > │ │ ├── regex v1.5.6 (in debian) > > │ │ ├── terminal_size v0.1.17 (in debian) > > │ │ └── unicode-width v0.1.9 (in debian) > > │ ├── lazy_static v1.4.0 (in debian) > > │ ├── tempfile v3.3.0 (in debian) > > │ └── zeroize v1.4.3 (in debian) > > ├── flexiber v0.1.0 > > │ └── delog v0.1.4 > > │ └── log v0.4.17 (in debian) > > ├── getrandom v0.2.7 (in debian) > > ├── hex v0.4.3 (in debian) > > ├── hex-literal v0.3.4 (in debian) > > ├── hidapi v1.4.1 > > │ └── libc v0.2.126 (in debian) > > │ [build-dependencies] > > │ ├── cc v1.0.73 (in debian) > > │ └── pkg-config v0.3.25 (in debian) > > ├── indicatif v0.16.2 (in debian) > > ├── iso7816 v0.1.0 > > │ ├── delog v0.1.4 > > │ │ └── log v0.4.17 (in debian) > > │ └── heapless v0.7.14 > > │ ├── hash32 v0.2.1 > > │ │ └── byteorder v1.4.3 (in debian) > > │ ├── spin v0.9.3 > > │ │ └── lock_api v0.4.7 (in debian) > > │ └── stable_deref_trait v1.2.0 (in debian) > > │ [build-dependencies] > > │ └── rustc_version v0.4.0 (in debian) > > ├── lazy_static v1.4.0 (in debian) > > ├── log v0.4.17 (in debian) > > ├── lpc55 v0.1.1 > > │ ├── aes v0.7.5 > > │ │ ├── cfg-if v1.0.0 (in debian) > > │ │ ├── cipher v0.3.0 > > │ │ │ └── generic-array v0.14.5 (in debian) > > │ │ ├── cpufeatures v0.2.2 (in debian) > > │ │ └── opaque-debug v0.3.0 (in debian) > > │ ├── anyhow v1.0.58 (in debian) > > │ ├── atty v0.2.14 (in debian) > > │ ├── base64 v0.13.0 (in debian) > > │ ├── bitflags v1.3.2 (in debian) > > │ ├── chrono v0.4.19 (in debian) > > │ ├── clap v3.2.5 (in debian) > > │ ├── ctr v0.8.0 > > │ │ └── cipher v0.3.0 > > │ │ └── generic-array v0.14.5 (in debian) > > │ ├── delog v0.1.4 > > │ │ └── log v0.4.17 (in debian) > > │ ├── enum-iterator v0.7.0 > > │ │ └── enum-iterator-derive v0.7.0 > > │ │ ├── proc-macro2 v1.0.40 (in debian) > > │ │ ├── quote v1.0.20 (in debian) > > │ │ └── syn v1.0.98 (in debian) > > │ ├── hex v0.4.3 (in debian) > > │ ├── hidapi v1.4.1 > > │ │ └── libc v0.2.126 (in debian) > > │ │ [build-dependencies] > > │ │ ├── cc v1.0.73 (in debian) > > │ │ └── pkg-config v0.3.25 (in debian) > > │ ├── hmac v0.12.1 (in debian) > > │ ├── indicatif v0.16.2 (in debian) > > │ ├── lazy_static v1.4.0 (in debian) > > │ ├── log v0.4.17 (in debian) > > │ ├── nom v7.1.1 (in debian) > > │ ├── oid-registry v0.2.0 > > │ │ └── der-parser v6.0.1 (in debian) > > │ ├── pem-parser v0.1.1 > > │ │ ├── regex v1.5.6 (in debian) > > │ │ └── rustc-serialize v0.3.24 (in debian) > > │ ├── pkcs11 v0.5.0 > > │ │ ├── libloading v0.5.2 > > │ │ │ [build-dependencies] > > │ │ │ └── cc v1.0.73 (in debian) > > │ │ └── num-bigint v0.2.6 > > │ │ ├── num-integer v0.1.45 (in debian) > > │ │ └── num-traits v0.2.15 (in debian) > > │ │ [build-dependencies] > > │ │ └── autocfg v1.1.0 (in debian) > > │ ├── pkcs11-uri v0.1.3 > > │ │ ├── anyhow v1.0.58 (in debian) > > │ │ ├── log v0.4.17 (in debian) > > │ │ ├── percent-encoding v2.1.0 (in debian) > > │ │ ├── pkcs11 v0.5.0 > > │ │ │ ├── libloading v0.5.2 > > │ │ │ │ [build-dependencies] > > │ │
Bug#1007742: ITP: solo2 -- command line interface for SoloKeys Solo 2 security key
Hi Philip, I would love to sponsor this. Are there any updates on packaging? Your Salsa repository is empty. Cheers, Stephan
Bug#1013425: ITP: wnpp -- Python Airspeed is a powerful templating engine compatible with Velocity for Java
Hi Felix, If there is nobody else, I can sponsor this as well. Will try to find some time on Sunday to review your work :) Cheers, Stephan On Wed, Jun 29, 2022 at 4:53 PM Moessbauer, Felix < felix.moessba...@siemens.com> wrote: > Dear maintainers, > > the initial packaging for python3-airspeed is now ready at [1] and has a > green salsa CI. > It should be ready for a review. > > @Stephan: Would you like to sponsor this package as well? > > [1] https://salsa.debian.org/python-team/packages/airspeed > > Best regards, > Felix Moessbauer > Siemens AG >
Bug#1012761: ITP: shtab -- generator for shell tab completion files for python projects
Hi Felix, I will take a look at the package sometime next week. I'm currently packing my stuff to move to Geneva, so I don't really have that much time right now. Feel free to ping though in case I forget :) Cheers, Stephan On Tue, Jun 21, 2022 at 4:30 PM Moessbauer, Felix < felix.moessba...@siemens.com> wrote: > Dear maintainers, > > the initial packaging of shtab is implemented in [1] and should be ready > for a review. > > @stephan It would be great if you could sponsor this package. > We talked about that at Debian Reunion Hamburg. > > [1] https://salsa.debian.org/python-team/packages/shtab > > Best regards, > Felix Moessbauer > Siemens AG >
Bug#1012120: libwww-dict-leo-org-perl: does not connect anymore
Package: libwww-dict-leo-org-perl Version: 2.02-2 Severity: grave Tags: upstream Justification: renders package unusable X-Debbugs-Cc: stephanlach...@debian.org, gre...@debian.org The package does not seem to work anymore. Calling it results in `Connection failed:` with no further information. Tested on multiple networks and machines. A debug log is given below. Probably an upstream issue. Cheers, Stephan Debug log: $ leo --debug test %DEBUG: connecting to site: dict.leo.org port 443 %DEBUG: GET /dictQuery/m-vocab/ende/query.xml?lp=ende=test HTTP/1.0 Connection failed: $ -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.17.0-3-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libwww-dict-leo-org-perl depends on: ii libio-socket-ssl-perl 2.074-2 ii liburi-encode-perl 1.1.1-1 ii libxml-simple-perl 2.25-1 ii perl 5.34.0-4 libwww-dict-leo-org-perl recommends no packages. libwww-dict-leo-org-perl suggests no packages. -- no debconf information
Bug#1011937: python-debian: Please consider moving deb822 to a standalone distro-independent Python package
Hi Jelmer, Thanks for the quick response! I'm not an expert on python-debian and I don't use other distros than Debian, so I can only forward you some bug reports from https://github.com/fsfe/reuse-tool/issues/466: - https://github.com/fsfe/reuse-tool/issues/311 (fixed now) - https://github.com/fsfe/reuse-tool/issues/425: `apt_pkg.Error: W:Unable to read /etc/apt/apt.conf.d/ - DirectoryExists (2: No such file or directory), E:Unable to determine a suitable packaging system type` This one is probably tricky to solve, maybe python-debian can check if it is in a Debian env by checking /etc/os-release? Ofc if python-debian would ensure cross-platform operability, that would be great, then there would be no need for a package split. I guess it depends a bit on the policy: is it tested on non-Debian platforms or just an afterthought where bugs get fixed when reported in version? If it is the latter, REUSE will probably still try to replace it. If it is the former, I think there is little reason to move away from python-debian. cc/ Max Mehl? Looking quickly at the CI though, it does not seem that this is currently the case. Maybe you could add a `unit-tests-alpine` and `unit-tests-windows` job based on the official Python Docker images [1] (w/ dependencies pulled via pip)? IMHO this should give enough confidence in the cross-platform operability of this package (again cc/ Max Mehl, I'm not a developer of REUSE). Best, Stephan [1]: https://hub.docker.com/_/python On Fri, May 27, 2022 at 11:15 AM Jelmer Vernooij wrote: > > Hi Stephan, > > On Fri, May 27, 2022 at 10:05:47AM +0200, Stephan Lachnit wrote: > > I'm working on a project that aims to use REUSE [1] to automate the > > process of creating and maintaing the d/copyright file. > > > > tl;dr: REUSE is a specification to annote license and copyright holder > > in a machine-readable way in the source files itself. Since Debian has a > > similar per-file copyright concept, using information from source > > packages that follow this specification can in principle be automated to > > reduce the work maintainers have to do. > > > > > > For several reasons it would be nice to have a d/copyright parser at > > hand, and since python-debian provides this with the deb822 module, it > > would be unneccessary work to write this again. REUSE already uses > > python-debian for this, but wants to get rit of it because there are > > some issue with this module on non-Debian OSes [2]. > > > > > > To come to the topic of this wishlist-bugreport: would it be possible to > > factor the deb822 parser out in a completetly separate Python package > > (on PyPi), e.g. python3-deb822, that explicitly does not depend on a > > Debian environment? > > What are the portability issues that exist in non-Debian environments? I'd > prefer to address those if possible rather than factoring out the deb822 > module, since that complicates on an ongoing basis in the future. > > FWIW python-debian is packaged in other Linux distributions, so my guess > is that the issue is non-Linux rather than non-Debian environments? > https://repology.org/project/python:debian/versions > > Jelmer
Bug#1011937: python-debian: Please consider moving deb822 to a standalone distro-independent Python package
Source: python-debian Version: 0.1.43 Severity: wishlist X-Debbugs-Cc: stephanlach...@debian.org, max.m...@fsfe.org I'm working on a project that aims to use REUSE [1] to automate the process of creating and maintaing the d/copyright file. tl;dr: REUSE is a specification to annote license and copyright holder in a machine-readable way in the source files itself. Since Debian has a similar per-file copyright concept, using information from source packages that follow this specification can in principle be automated to reduce the work maintainers have to do. For several reasons it would be nice to have a d/copyright parser at hand, and since python-debian provides this with the deb822 module, it would be unneccessary work to write this again. REUSE already uses python-debian for this, but wants to get rit of it because there are some issue with this module on non-Debian OSes [2]. To come to the topic of this wishlist-bugreport: would it be possible to factor the deb822 parser out in a completetly separate Python package (on PyPi), e.g. python3-deb822, that explicitly does not depend on a Debian environment? Cheers, Stephan [1]: https://reuse.software/ [2]: https://github.com/fsfe/reuse-tool/issues/466 -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.17.0-2-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#989085: Description suggestion
Thanks for the description! Once I have time again to package this, I will use it. Best, Stephan On Fri, May 20, 2022 at 9:21 PM Joseph Carter wrote: > > Suggest something like… > > Description: Micro-compositor for game scaling > Gamescope wraps your games to give them scaling and fullscreen options. It > provides a Wayland compositor to your games, but gamescope runs under both > Wayland and X.org. > . > Your game sees a virtual display at the resolution you specified. You see a > scaled view in a window or fullscreen. This is useful when either the game or > your system do not permit running the game at native window/screen sizes. You > can also use integer scaling to keep your pixels sharp and pixelated. > > I think this should resolve any confusion as to whether or not a person wants > to install this. > > Joseph
Bug#1010638: ITP: gnome-shell-extension-proxy-switcher -- Gnome Shell Extension to switch the proxy mode
Package: wnpp Severity: wishlist Owner: Stephan Lachnit X-Debbugs-Cc: debian-de...@lists.debian.org, stephanlach...@debian.org, pkg-gnome-maintain...@lists.alioth.debian.org * Package name: gnome-shell-extension-proxy-switcher Version : 1.5.1 Upstream Author : Tom Flannaghan * URL : https://github.com/tomflannaghan/proxy-switcher * License : GPL-2.0 Programming Lang: JavaScript Description : Gnome Shell Extension to switch the proxy mode The title pretty much says it all. If wanted I would maintain it the Debian GNOME Maintainers team. Cheers, Stephan
Bug#1007970: ITP: cloudflare-ddns -- dynamically update a DNS record using Cloudflare
Hi Andrea, uploaded :) Cheers, Stephan On Sat, Apr 2, 2022 at 2:57 PM Andrea Pappacoda wrote: > > Hi Stephan, I've reuploaded my package to Mentors, following Thorsten > Alteholz's advice about the rejection; all the files should now have a > proper entry in d/copyright. > > You can find it here: > https://mentors.debian.net/package/cloudflare-ddns/ > > Thanks again :) > > -- > OpenPGP key: 66DE F152 8299 0C21 99EF A801 A8A1 28A8 AB1C EE49 > >
Bug#1008644: ITP: nala -- commandline frontend for the apt package manager
Hi, I think this is a wonderful looking tool, and I would be willing to sponsor this. Can you upload it to mentors.debian.net? Regards, Stephan On Wed, 30 Mar 2022, 03:39 Blake Lee, wrote: > Package: wnpp > Severity: wishlist > Owner: Blake Lee > X-Debbugs-Cc: debian-de...@lists.debian.org > > * Package name: nala > Version : 0.7.1 > Upstream Author : Blake Lee > * URL : https://gitlab.com/volian/nala > * License : GPLv3+ > Programming Lang: Python > Description : commandline frontend for the apt package manager > > nala is a frontend for the apt package manager. It has a lot > of the same functionality, but formats the output to be more > human readable. Also implements a history function to see past > transactions and undo/redo them. Much like Fedora's dnf history. > > This package is useful because it improves the UX of managing packages > through the command line with python3-apt. Additionally provides some > extra quality of life features such as a transaction history you can > interact with. I use nala daily, as do many others. Similar packages > include apt and aptitude. Nala improves upon the hardwork of the apt > team by formatting the output in a more readable manner. > > At the moment I maintain this program on our GitLab. That is where we > accept bug reports and feature requests. I don't have any problems > accepting bug reports from Debian's system, or emails for that matter. > I regularly accept bug reports from our GitHub as well. > > We currently have support for the German language, and I have someone > working on a Spanish po file as well. > > Nala is still in active development, but it is very usable. I've had > many people ask me about getting this into the Official Debian repos so > this is my request for that. > > I assume that I would be in need of a sponser considering I've never > uploaded anything into a Debian repository. But I did try my best to > make the debian files proper, and I personally use sbuild for building > the software. > > In case it is required I do have our repo already mirrored into debian > salse https://salsa.debian.org/volian-team/nala > > My users would be thrilled to hear this makes it into the official > repositories. I'm looking forward to your response. > >
Bug#1007970: ITP: cloudflare-ddns -- dynamically update a DNS record using Cloudflare
Hi Andrea, This sounds really cool and useful to have in Debian! Do you need a sponsor? If so, I would be willing to sponsor it. Regards, Stephan On Sat, Mar 19, 2022 at 8:09 PM Andrea Pappacoda wrote: > > Package: wnpp > Severity: wishlist > Owner: Andrea Pappacoda > X-Debbugs-Cc: debian-de...@lists.debian.org > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > * Package name: cloudflare-ddns > Version : 1.0.0 > Upstream Author : Andrea Pappacoda > * URL : https://github.com/Tachi107/cloudflare-ddns > * License : AGPL-3.0-or-later OR LGPL-3.0-or-later > Programming Lang: C++ > Description : dynamically update a DNS record using Cloudflare > > This is a little program that is really useful when you want to host something > but your ISP only provides you a dynamic IP address. It uses Cloudflare's API > to update a given DNS record when needed. It is a simple script, so to run it > periodically you can configure a cron job or a systemd timer (provided > upstream). > > It is written in C++, performs a low number of memory allocations, and is > really lightweight, making it a valid choice for constrained environments. > > It also provides a C API, so that third party programs can embed its > functionalities. > > The library portion of the project is licensed under the LGPL 3, while > everything else is under the AGPL 3. > > I couldn't find any alternative in the Debian archive, and while there are > some > other open source alternatives out there they are mostly written in more > resource-intensive languages and/or are harder to deploy for simple use cases. > And also because I'm the one who wrote this :D > > > -BEGIN PGP SIGNATURE- > > iIoEARYIADIWIQSlw/BqXszDGx3GlQz/yQfijUdG7QUCYjYplRQcYW5kcmVhQHBh > cHBhY29kYS5pdAAKCRD/yQfijUdG7T7cAQCTCY67bva7wnXpVjKrixLVsWeOy/cU > orsLD1f6BauB8wD/Rbs4w72xiM46pcQLMBkd0YivhGs9hshRqKk64eTqUwg= > =3xxd > -END PGP SIGNATURE- >
Bug#1005875: ITP: python-headerparser -- Python module to parse key-value pairs in the style of RFC 822 headers
Package: wnpp Severity: wishlist Owner: Stephan Lachnit X-Debbugs-Cc: debian-de...@lists.debian.org, stephanlach...@debian.org * Package name: python-headerparser Version : 0.4.0 Upstream Author : John T. Wodder II * URL : https://github.com/jwodder/headerparser * License : MIT Programming Lang: Python Description : Python module to parse key-value pairs in the style of RFC 822 headers I intend this maintain this in the Debian Python Team. I will use this library for my ongoing work to convert SPDX documents to DEP5 documents [1]. The reason I won't use python-debian is that it is apparently a bit buggy on non-Debian systems. Regards, Stephan [1] https://lists.debian.org/debian-devel/2022/02/msg00207.html The long description from the readme: headerparser parses key-value pairs in the style of RFC 822 (e-mail) headers and converts them into case-insensitive dictionaries with the trailing message body (if any) attached. Fields can be converted to other types, marked required, or given default values using an API based on the standard library’s argparse module. (Everyone loves argparse, right?) Low-level functions for just scanning header fields (breaking them into sequences of key-value pairs without any further processing) are also included. RFC 822-style headers are header fields that follow the general format of e-mail headers as specified by RFC 822 and friends: each field is a line of the form “Name: Value”, with long values continued onto multiple lines (“folded”) by indenting the extra lines. A blank line marks the end of the header section and the beginning of the message body. This basic grammar has been used by numerous textual formats besides e-mail, including but not limited to: HTTP request & response headers Usenet messages most Python packaging metadata files Debian packaging control files META-INF/MANIFEST.MF files in Java JARs a subset of the YAML serialization format - all of which this package can parse.
Bug#1004522: debian-policy: Proposing new virtual package: wayland-session
On Mon, Jan 31, 2022 at 10:38 AM Bill Allombert wrote: > > On Mon, Jan 31, 2022 at 10:13:19AM +0100, Stephan Lachnit wrote: > > > > Actually, just out of curiosity: the folder is called > > "wayland-sessions", but the files are all called "*.desktop". Are > > there other possibilities than "*.desktop", and if so what is the > > difference? > > .desktop is just a standard file format used to register applications > with desktop environment, see > <https://www.freedesktop.org/wiki/Specifications/desktop-entry-spec/> Ah thanks! I somehow didn't expect it to be the same as the usual .desktop file format as for applications. Then I agree on the "wayland-session" name. But maybe the description should remove the word "desktop" then. Regards, Stephan
Bug#1004522: debian-policy: Proposing new virtual package: wayland-session
On Sun, Jan 30, 2022 at 3:55 PM Andrei POPESCU wrote: > > On Du, 30 ian 22, 13:21:40, Stephan Lachnit wrote: > > > > I like the idea. Just another idea for the naming, about > > wayland-desktop-session? > > It's longer and Phosh is not exactly a "desktop" ;) Right, but then the description "a Wayland desktop session" and the file location (/usr/share/wayland-sessions/*.desktop) is also a bit off, right? I guess this depends on how one defines "desktop" ;) Actually, just out of curiosity: the folder is called "wayland-sessions", but the files are all called "*.desktop". Are there other possibilities than "*.desktop", and if so what is the difference? If yes, then maybe there is a point to make for "wayland-desktop-session", else the shorter name is preferable of course. Regards, Stephan
Bug#1004522: debian-policy: Proposing new virtual package: wayland-session
I like the idea. Just another idea for the naming, about
wayland-desktop-session?
Regards,
Stephan
On Sat, 29 Jan 2022, 21:15 Simon McVittie, wrote:
> Package: debian-policy
> Version: 4.6.0.1
> Severity: wishlist
> X-Debbugs-Cc: debian-de...@lists.debian.org
>
> GNOME's gdm3 and KDE's sddm both enumerate possible Wayland sessions in
> /usr/{,local/}share/wayland-sessions/*.desktop and make them available
> as desktop sessions that users can choose, in addition to listing the
> X11 sessions that they traditionally did.
>
> At the moment, installing gdm3 pulls in either gnome-session (a minimal
> GNOME desktop), or some sort of X11 thing (usually a session manager,
> but sometimes a window manager or an xterm), but it should ideally
> be possible to install gdm3 as a login prompt from which to launch a
> non-GNOME Wayland session like weston or sway.
>
> I propose this entry for virtual-package-names-list.yaml:
>
> - name: wayland-session
> description: a Wayland desktop session
> (/usr/share/wayland-sessions/*.desktop)
>
> According to `apt-file search`, it should initially be provided by these:
>
> gnome-session: /usr/share/wayland-sessions/gnome.desktop
> phosh: /usr/share/wayland-sessions/phosh.desktop
> plasma-workspace-wayland: /usr/share/wayland-sessions/plasmawayland.desktop
> sway: /usr/share/wayland-sessions/sway.desktop
> weston: /usr/share/wayland-sessions/weston.desktop
>
> and perhaps also (I don't know how practical this one is for actual use):
>
> mir-demos: /usr/share/wayland-sessions/mir-shell.desktop
>
> Rationale for not using the names people are probably going to suggest:
>
> - wayland-compositor would be wrong, because it's too low-level. Some
> Wayland compositors are a somewhat complete desktop environment in their
> own right, but for example plasma-workspace-wayland and gnome-session
> are larger components that merely *depend on* a Wayland compositor, plus
> the additional components needed to get a practical desktop environment;
> meanwhile, kwin-wayland and gnome-shell are Wayland compositors, but
> are not desktop environments on their own.
>
> - wayland-session-manager seems like it would be misleading, because an X
> session manager has specific functional expectations (XSMP) separating
> it from an mere x-window-manager, but there's no such thing in Wayland.
>
> smcv
>
>
Bug#1003895: lazarus: undefined reference to QLCLOpenGLWidget
Source: lazarus Version: 2.2.0+dfsg-2 Severity: important X-Debbugs-Cc: stephanlach...@debian.org, abou.almonta...@sfr.fr Control: affects -1 src:goverlay Dear maintainer, it looks like the update to 2.2.0 broke the Qt OpenGL Widget. I tried to compile goverlay [1] with the new version, but it fails with the following error message: (9015) Linking /<>/goverlay /usr/bin/ld.bfd: ./debian/.debhelper/generated/_source/home/.lazarus/lib/LazOpenGLContext/lib/x86_64-linux/qt5/qlclopenglwidget.o: in function `CREATEWIDGET': /usr/lib/lazarus/2.2.0/components/opengl//qlclopenglwidget.pas:58: undefined reference to `QLCLOpenGLWidget_Create' /usr/bin/ld.bfd: ./debian/.debhelper/generated/_source/home/.lazarus/lib/LazOpenGLContext/lib/x86_64-linux/qt5/qlclopenglwidget.o: in function `PAINTGL': /usr/lib/lazarus/2.2.0/components/opengl//qlclopenglwidget.pas:65: undefined reference to `QLCLOpenGLWidget_InheritedPaintGL' /usr/bin/ld.bfd: ./debian/.debhelper/generated/_source/home/.lazarus/lib/LazOpenGLContext/lib/x86_64-linux/qt5/qlclopenglwidget.o: in function `ATTACHEVENTS': /usr/lib/lazarus/2.2.0/components/opengl//qlclopenglwidget.pas:75: undefined reference to `QLCLOpenGLWidget_override_paintGL' /usr/bin/ld.bfd: ./debian/.debhelper/generated/_source/home/.lazarus/lib/LazOpenGLContext/lib/x86_64-linux/qt5/qlclopenglwidget.o: in function `DETACHEVENTS': /usr/lib/lazarus/2.2.0/components/opengl//qlclopenglwidget.pas:83: undefined reference to `QLCLOpenGLWidget_override_paintGL' /<>/goverlay.lpr(27,1) Error: (9013) Error while linking Maybe this is because libqtpas has not been updated for 2.2.0? If so, maybe it makes sense to rethink the decision of #922296 again to prevent this happening again in the future. Regards, Stephan [1] https://salsa.debian.org/games-team/goverlay -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.15.0-2-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1003732: node-duration: Package node-duration isn't published in js-team repo
On Fri, 14 Jan 2022 16:32:07 +0100 Yadd wrote: > Package: node-duration > Severity: important > > Package node-duration is marked as owned by JS Team but not available in > JS Team salsa area. It shouldn't owned JS-Team in this case. Hi Yadd, I requested access to the JS team on Salsa, but it has not been approved yet. Once approved, I will push the repo. My Salsa login is "stephanlachnit", in case you have the rights to add me. Regards, Stephan
Bug#1003724: libpqxx: Please update package to version 7.7.0
Source: libpqxx Version: 6.4.5-2 Severity: wishlist X-Debbugs-Cc: stephanlach...@debian.org, deb...@kulisz.net Dear maintainer, please update the package to the latest version, as there are some interface changes which newer software might require. Regards, Stephan -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.15.0-2-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1003321: RFP: openui5 -- framework for enterprise-ready web applications
Control: unblock 981113 by 1003321 Control: unblock 1003321 by 1003337 1003334 1003326 1003329 Hi Yadd, Thanks for the initial packaging of OpenUI5! I noticed that the installed source is not optimized. I'm not sure how this relates to real-world performance. ROOT histograms can contain a lot of data, so this could be an issue. I've taken a look at the lintian output and let's just say it's not pretty. Since I currently lack the time to take a look at it, I decided to delay this feature of ROOT (it can be built without support for OpenUI5). The usage of OpenUI5 is a feature of the still experimental ROOT v7 components, so I will focus on the ROOT v6 components first before tackling this issue. Regards, Stephan
Bug#1003321: [Pkg-javascript-devel] Bug#1003321: RFP: openui5 -- framework for enterprise-ready web applications
Hi Yadd, On Sat, Jan 8, 2022 at 1:48 PM Yadd wrote: > > On 08/01/2022 13:45, Yadd wrote: > > > > Grunt-timer seems needed only to build doc/sdk Ah shoot saw it too late, already packaged and uploaded^^ On 08/01/2022 13:45, Yadd wrote: > > OK, easy to do, I'll prepare the package Cool, thanks! On Sat, Jan 8, 2022 at 1:48 PM Yadd wrote: > > The same source provides all @openui5 and grunt is already packaged (and > not needed here to build @openui5/* packages). Ah right now I see it as well. How does one build the package then? For me it always wants to go through grunt and gives me the error " Cannot find module './.' ". Regards, Stephan
Bug#1003337: ITP: node-grunt-timer -- times the duration of your grunt tasks
Package: wnpp Severity: wishlist Owner: Stephan Lachnit X-Debbugs-CC: debian-de...@lists.debian.org Control: block 1003321 by -1 Control: block -1 by 1003326 1003329 1003334 * Package name: node-grunt-timer * Version : 0.6.0 * Upstream Author : Lee Crossley * URL : http://ilee.co.uk * License : MIT * Programming Lang: JavaScript * Description : times the duration of your grunt tasks This Node.js module times the duration of each of your grunt tasks automatically and outputs the execution time in milliseconds to the console after each task. It also logs the total time for all logged tasks at the end. Node.js is an event-based server-side JavaScript engine. This package is a dependency for openui5, which itself is a dependency for ROOT. I intend to maintain this in the JS team. I don't have a lot of JS experience, but the package seems simple enough to be consistently maintained.
Bug#1003334: ITP: node-functional.js -- Node.js module facilitating currying and tacit programming
Package: wnpp Severity: wishlist Owner: Stephan Lachnit X-Debbugs-CC: debian-de...@lists.debian.org Control: block 1003321 by -1 * Package name: node-functional.js * Version : 0.8.0 * Upstream Author : Lee Crossley * URL : https://github.com/functionaljs/functional-js * License : MIT * Programming Lang: JavaScript * Description : Node.js module facilitating currying and tacit programming This Node.js module is a functional JavaScript library. It facilitates currying and point-free / tacit programming, with optional lambda expressions. Node.js is an event-based server-side JavaScript engine. This package is a dependency for node-grunt-timer, which itself is a dependency for openui5, which itself is a dependency for ROOT. I intend to maintain this in the JS team. I don't have a lot of JS experience, but the package seems simple enough to be consistently maintained.
Bug#1003329: ITP: node-bash-color -- wrap strings in color codes for pretty printing in bash
Package: wnpp Severity: wishlist Owner: Stephan Lachnit X-Debbugs-CC: debian-de...@lists.debian.org Control: block 1003321 by -1 * Package name: node-bash-color * Version : 0.0.4 * Upstream Author : mykola bilokonsky * URL : https://github.com/mbilokonsky/bash-color#readme * License : Expat * Programming Lang: JavaScript * Description : wrap strings in color codes for pretty printing in bash This is a Node.js module for wrapping strings in color codes for pretty printing in bash. Node.js is an event-based server-side JavaScript engine. This package is a recursive dependency for OpenUI5. I intend to maintain this in the JS team. I don't have a lot of JS experience, but the package seems simple enough to be consistently maintained.
Bug#1003326: ITP: node-duration -- time duration utilities for Node.js
Package: wnpp Severity: wishlist Owner: Stephan Lachnit X-Debbugs-CC: debian-de...@lists.debian.org Control: block 1003321 by -1 * Package name: node-duration * Version : 0.2.2 * Upstream Author : Mariusz Nowak * URL : https://github.com/medikoo/duration#readme * License : ISC * Programming Lang: JavaScript * Description : time duration utilities for Node.js This Node.js module provides functions to calculate, convert and display the duration between JavaScript Date objects. Node.js is an event-based server-side JavaScript engine. I intend to maintain this in the JS team. I don't have a lot of JS experience, but the package seems simple enough to be consistently maintained.
Bug#1003321: [Pkg-javascript-devel] Bug#1003321: RFP: openui5 -- framework for enterprise-ready web applications
Hi Yadd, I've looked into this a bit now. Looking at https://github.com/root-project/root/blob/98d9a2064a0e25aebb9b4a8bf95fdc8f20e0f21c/builtins/openui5/openui5.tar.gz (sorry, that's how it is shipped), I think I need @openui5/sap.m, @openui5/sap.tnt, @openui5/sap.ui.codeeditor, @openui5/sap.ui.commons, @openui5/sap.ui.layout, @openui5/sap.ui.table, @openui5/sap.ui.unified and @openui5/sap.uxap from npm. I can then probably symlink it somehow. I have gather the following dependencies already: @openui5/sap.ui.core: path, moment, semver, grunt-timer, @openui5/sap.ui.layout: @openui5/sap.ui.core, @openui5/sap.ui.unified: @openui5/sap.ui.core, @openui5/sap.ui.codeeditor: @openui5/sap.ui.core @openui5/sap.ui.commons: @openui5/sap.ui.core, @openui5/sap.ui.layout, @openui5/sap.ui.unified, @openui5/sap.ui.table: @openui5/sap.ui.core, @openui5/sap.ui.unified, @openui5/sap.m: @openui5/sap.ui.core, @openui5/sap.ui.layout, @openui5/sap.ui.unified, @openui5/sap.tnt: @openui5/sap.m, @openui5/sap.ui.core, @openui5/sap.f: @openui5/sap.m, @openui5/sap.ui.core, @openui5/sap.ui.layout, @openui5/sap.uxap: @openui5/sap.f, @openui5/sap.m, @openui5/sap.ui.core, @openui5/sap.ui.layout, path: grunt-timer: bash-color, duration, functional.js, hooker, bash-color: duration: d, es5-ext, d: es5-ext: functional.js: The table is not finished yet though, as openui5 uses grunt and thus I need to fetch the recursive deps by hand. I'm almost done packaging node-duration, if you can give me access to the JS group on Salsa I can push the repo and upload the package. Regards and thanks for the fast reply, Stephan On Sat, Jan 8, 2022 at 12:23 PM Yadd wrote: > > On 08/01/2022 11:27, Stephan Lachnit wrote: > > Package: wnpp > > Severity: wishlist > > X-Debbugs-Cc: stephanlach...@debian.org, > > pkg-javascript-de...@lists.alioth.debian.org > > Control: block 981113 by -1 > > > > * Package name: openui5 > > * Version : 1.90.10 > > * Upstream Author : SAP > > * URL : https://openui5.org/ > > * License : Apache-2.0 > > * Programming Lang: JavaScript > > * Description : framework for enterprise-ready web applications > > > > OpenUI5 lets you build enterprise-ready web applications, responsive to all > > devices, running on almost any browser of your choice. It's based on > > JavaScript > > and follows web standards. It eases your development with a client-side > > HTML5 > > rendering library including a rich set of controls and supports data > > binding to > > different data models (JSON, XML and OData). > > > > > > This package is a dependency of ROOT (ITP: root-framework). Since I don't > > have > > any experience with JavsScript, I filled this as an RFS and Cc-ed the JS > > team, > > where I would like to team-maintain it. > > Hi, > > what do you want, the openui5-runtime, the openui5-sdk or @openui5/* > node packages ? > > It's easy to provide @openui5/* node package, but upstream doesn't > explain how it produces openui5-runtime (probably a rollup/webpack). > It is also possible to build openui5-sdk but it seems to be only some > docs/demos. > > Repo: https://github.com/SAP/openui5 > > Cheers, > Yadd
Bug#1003321: RFP: openui5 -- framework for enterprise-ready web applications
Package: wnpp Severity: wishlist X-Debbugs-Cc: stephanlach...@debian.org, pkg-javascript-de...@lists.alioth.debian.org Control: block 981113 by -1 * Package name: openui5 * Version : 1.90.10 * Upstream Author : SAP * URL : https://openui5.org/ * License : Apache-2.0 * Programming Lang: JavaScript * Description : framework for enterprise-ready web applications OpenUI5 lets you build enterprise-ready web applications, responsive to all devices, running on almost any browser of your choice. It's based on JavaScript and follows web standards. It eases your development with a client-side HTML5 rendering library including a rich set of controls and supports data binding to different data models (JSON, XML and OData). This package is a dependency of ROOT (ITP: root-framework). Since I don't have any experience with JavsScript, I filled this as an RFS and Cc-ed the JS team, where I would like to team-maintain it.
Bug#1002039: embree: add arm64 architecture
Source: embree Version: 3.13.2+dfsg-1 Severity: wishlist X-Debbugs-Cc: stephanlach...@debian.org, m...@debian.org Dear maintainer, please consider adding support for arm64, as it seems to be supported by embree, see [1] and [2] (under "Cross Platform"). Maybe this also gives an update to #976496 [3]. Regards, Stephan [1] https://github.com/embree/embree/releases/tag/v3.13.1 [2] https://www.embree.org/ [3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=976496 -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.15.0-2-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1001237: ptl: autopkgtest regression on armhf: Floating point exception
Control: forwarded -1 https://github.com/jrmadsen/PTL/issues/25 Hi Lukas, On Mon, 13 Dec 2021 15:39:18 +0100 =?utf-8?q?Lukas_M=C3=A4rdian?= wrote: > I can observe the same issue with 2.3.0-1 on Ubuntu and filed an upstream bug > at https://github.com/jrmadsen/PTL/issues/25 > > The intmax_t division seems to be the root-cause here, replacing the division > in the minimal.cc example with a constant is a (temporary) way to mitigate > this > problem. Thanks for looking into this! I didn't have the time to do it. Since I saw you fixed this upstream and 2.3.1 was released after that, I have uploaded the new version instead of adding the patch. Thanks again, Stephan
Bug#1000208: upload of pcmemtest
Thanks, uploaded. Feel free to contact me if there is a new version. Since you are already a DM maintaining a couple of packages, I would give you upload rights then. Regards, Stephan On Tue, Nov 30, 2021 at 8:41 PM Felix Zielcke wrote: > > Thanks again. > Yes somehow I missed it. > Changed now the salsa-ci.yml file to your latest suggestion. > > > Am Dienstag, dem 30.11.2021 um 20:28 +0100 schrieb Stephan Lachnit: > > Hi Felix, > > > > it seems like you missed my comment on Salsa [1]. Please take a look > > at it, should be quick to do. > > > > Regards, > > Stephan > > > > [1 > > ]https://salsa.debian.org/fzielcke/pcmemtest/-/merge_requests/1#note_285216 > > > > On Tue, Nov 30, 2021 at 8:23 PM Felix Zielcke > > wrote: > > > > > > Hi Stephan, > > > > > > did you already upload pcmemtest to NEW? > > > I didn't get a mail and I don't see it in the list. > > > > > > Regards > > > Felix >
Bug#1000833: src:python-license-expression: Package licenses not properly documented in debian/copyright
On Mon, 29 Nov 2021 16:33:17 -0500 Scott Kitterman wrote: > Package: src:python-license-expression > Version: 21.6.14-1 > Severity: serious > Justification: Policy 4.5 > > As mentioned during the review in New: > > I am going to accept this and file a bug because the issue alread exists in > the archive from the current package. The package debian/copyright claims > that _pyahocorasick.py is public domain. This appears to be incorrect. If > you check the source of the code documented in _pyahocorasick.ABOUT, it says > the license in BSD 3-Clause. See: > > https://github.com/WojciechMula/pyahocorasick/blob/master/LICENSE > > Scott K > > Hi Scott, I think this is incorrect. If you look at src/license_expression/_pyahocorasick.ABOUT, you will find the link to the file they imported [1]. Those files are clearly marked as public domain in their header. The overall project license might be BSD-3-Clause, but the python files are licensed differently. Please close this if you agree with my assessment. Regards, Stephan [1] https://github.com/WojciechMula/pyahocorasick/tree/ec2fb9cb393f571fd4316ea98ed7b65992f16127/py
Bug#1000208: ITP: pcmemtest -- stand-alone memory tester
Hi Felix, I'm finished with my review. I've opened a PR on Salsa [1] with my suggestions. Regards, Stephan [1] https://salsa.debian.org/fzielcke/pcmemtest/-/merge_requests/1 On Mon, Nov 29, 2021 at 4:17 PM Stephan Lachnit wrote: > > Hi Felix, > > thanks for the ping, looking at it right now. > > Regards, > Stephan > > On Mon, Nov 29, 2021 at 2:14 PM Felix Zielcke wrote: > > > > Am Freitag, dem 26.11.2021 um 15:34 +0100 schrieb Stephan Lachnit: > > > Hi Felix, > > > > > > I was a bit more stressed this week than I hoped, I'll try to look at > > > it > > > saturday or sunday. If you don't get a reply by monday morning, feel > > > free > > > to ping me again. > > > > Hi Stephan, > > > > here's your friendly ping. > > Did you have time to look at pcmemtest? > > > > Regards, > > Felix > >
Bug#1000208: ITP: pcmemtest -- stand-alone memory tester
Hi Felix, thanks for the ping, looking at it right now. Regards, Stephan On Mon, Nov 29, 2021 at 2:14 PM Felix Zielcke wrote: > > Am Freitag, dem 26.11.2021 um 15:34 +0100 schrieb Stephan Lachnit: > > Hi Felix, > > > > I was a bit more stressed this week than I hoped, I'll try to look at > > it > > saturday or sunday. If you don't get a reply by monday morning, feel > > free > > to ping me again. > > Hi Stephan, > > here's your friendly ping. > Did you have time to look at pcmemtest? > > Regards, > Felix >
Bug#1000208: ITP: pcmemtest -- stand-alone memory tester
Hi Felix, I was a bit more stressed this week than I hoped, I'll try to look at it saturday or sunday. If you don't get a reply by monday morning, feel free to ping me again. Regards, Stephan On Fri, 26 Nov 2021, 15:11 Felix Zielcke, wrote: > Am Samstag, dem 20.11.2021 um 18:47 +0100 schrieb Stephan Lachnit: > > Sounds interesting. > > > > On Fri, Nov 19, 2021 at 8:03 PM wrote: > > > > > > I'm happy to maintain it inside a team or with co-maintainer(s). > > > I'm only DM so if someone has interest in sponsoring this, feel > > > free to > > > contact me. > > > > If you need me as sponsor, ping me when the package is ready for > > upload. > > Hi Stephan, do you have time to review it? I think it's ready to > upload. > > > Regards > > Stephan > >
Bug#1000514: RM: symfit -- RoM; please remove src:symfit from NEW
Package: ftp.debian.org Severity: wishlist X-Debbugs-Cc: stephanlach...@debian.org Please remove symfit from the NEW queue (I uploaded the package). Thanks, Stephan [1] https://ftp-master.debian.org/new/symfit_0.5.4-1.html
Bug#1000208: ITP: pcmemtest -- stand-alone memory tester
Sounds interesting. On Fri, Nov 19, 2021 at 8:03 PM wrote: > > I'm happy to maintain it inside a team or with co-maintainer(s). > I'm only DM so if someone has interest in sponsoring this, feel free to > contact me. If you need me as sponsor, ping me when the package is ready for upload. Regards Stephan
Bug#998475: RM: boolean.py -- ROM; superseded by src:python-boolean.py
Package: ftp.debian.org Severity: normal X-Debbugs-Cc: stephanlach...@debian.org Control: block 997876 by -1 src:boolean.py has been replaced by src:python-boolean.py to remove ambiguity. Usually pure Python packages like this one have a "python-"-prefix. src:python-boolean.py is still in NEW [1], however no changes regarding the upstream source have been made and thus should be quick to review. Please remove src:boolean.py once src:python-boolean.py is accepted into Debian. Thanks, Stephan [1] https://ftp-master.debian.org/new/python-boolean.py_3.8-2.html
Bug#997876: license-expression: consider uploading 21.6.14-1 to unstable
On Tue, 26 Oct 2021 15:47:29 +0200 Romain Porte wrote: > Source: license-expression > Version: 1.2+ds1-1 > Severity: wishlist > X-Debbugs-Cc: deb...@microjoe.org > > Dear Maintainer, > > The current d/changelog in Salsa in indicating that 21.6.14-1 has been > uploaded to experimental, yet: > > - it does not seem present in experimental [1]; nor > - it does not seem present in the NEW queue [2]. > > Because of the strange status of this package, I am not sure how to > contribute as a member of the DPT to fix it. On the tracker page the > links to the VCS repository are wrong because the fixes in Salsa have > not been uploaded yet. > > Uploading the package to unstable seems a sensible move in order to > unblock the situation, but please let me know if something else can be > done. > > [1] https://tracker.debian.org/pkg/license-expression > [2] https://ftp-master.debian.org/new.html > > Bests. Hi Roman, the situation with this package is a bit unlucky, as this upload was rushed before I was DD during the freeze. During initial packaging I sadly messed up the correct source name of the package (which would be python-license-expression). The same is true for the package boolean.py (should be python-boolean.py). I plan to change the source package name, this also explain why the Salsa links changed [1][2]. For boolean.py, there already is a upload to NEW [3]. After this transition, I will do the same for license-expression. Packaging the new version is no problem and in fact even removes some (bundled thirdparty deps). The packaging is already done on Salsa. Since I did not find anything particular useful in the policy regarding source package renames (they happened before, e.g. gtk4), I'm not sure if anything can be done here except waiting for a review from the ftp-masters (which should be quick once they read the changelog). I considered opening a bug against ftp.debian.org, but did not pursuit this. Feel free to do so. Regards Stephan [1] https://salsa.debian.org/python-team/packages/python-license-expression [2] https://salsa.debian.org/python-team/packages/python-boolean.py [3] https://ftp-master.debian.org/new/python-boolean.py_3.8-2.html
Bug#994960: can't set RADV_DEBUG (apply patch or update to 0.5.8.4)
Control: fixed -1 0.5.8.4 Control: tags -1 fixed-upstream Control: severity -1 minor On Fri, 24 Sep 2021 03:38:41 +0200 "kolafl...@kolahilft.de" wrote: > Package: lutris > Version: 0.5.8.3-2 > > There's a bug in lutris-0.5.8.3 making it impossible to set the RADV_DEBUG environment variable. > https://github.com/lutris/lutris/issues/3419 > > Please either apply the small upstream patch for Bullseye or update to lutris-0.5.8.4. > > > Kind regards, > kolAflash > > Hi kolAflash, I will upload a backport of 0.5.9 for bullseye soon, is this sufficient for you? I fear the bug is not important enough to be fixed in a stable update. Best regards Stephan
Bug#992198: lutris: should recommend (or depend) on wine32
On Sun, 15 Aug 2021 17:46:37 +0100 Wolfgang Weisselberg wrote: > Package: lutris > Version: 0.5.8.4-1 > Severity: normal > > Dear Maintainer, > > lutris keeps putting > | it looks like wine32 is missing, you should install it. > | as root, please execute "apt-get install wine32" > into the window it was started from. > > Would it make sense to recommend wine32? > > > $ dpkg -l \*wine\* | egrep '^ii' > ii fonts-wine 5.0.3-3 all Windows API implementation - fonts > ii libkwineffects12a 4:5.20.5-1 amd64 KDE window manager effects library > ii libwine:amd64 5.0.3-3 amd64 Windows API implementation - library > ii libwine-dev:amd64 5.0.3-3 amd64 Windows API implementation - development files > ii libwine-development:amd64 6.0+repack-1 amd64 Windows API implementation - library > ii q4wine 1.3.12-1 amd64 Qt GUI for WINE > ii wine 5.0.3-3 all Windows API implementation - standard suite > ii wine-binfmt 5.0.3-3 all Register Wine as the interpreter for Windows executables > ii wine-development 6.0+repack-1 all Windows API implementation - standard suite > ii wine64 5.0.3-3 amd64 Windows API implementation - 64-bit binary loader > ii wine64-development 6.0+repack-1 amd64 Windows API implementation - 64-bit binary loader > ii wine64-tools 5.0.3-3 amd64 Windows API implementation - 64-bit developer tools > ii winetricks 0.0+20210206-2 all simple tool to work around common problems in Wine > $ control: tags -1 upstream control: severity -1 minor Hi Wolfgang, IMHO not really. Lutris manages wine versions itself, the only real reason would be dependencies (although Lutris can use system wine if wished). But its perfectly fine to use Lutris without wine32 if no win32 applications are used. In any case, for Lutris the policy is to deviate from upstream as little as possible, including the debian files and thus the recommends. Please contact upstream if this message bothers you to find a solution. Best regards Stephan
Bug#992277: protontricks: With any command, fails with "KeyError: 'LibraryFolders'"
Hi,
thanks for reporting. I can confirm this. I will fix it with the version
1.6.0, which has been released 3 weeks ago.
Since I don't have much time right now, it will probably stay in this
state for the next couple of weeks (sorry).
Regards
Stephan
On Mon, 16 Aug 2021 09:48:41 -0700 Brian Vaughan
wrote:
> Package: protontricks
> Version: 1.5.0-1
> Severity: grave
> Justification: renders package unusable
> X-Debbugs-Cc: bgvaug...@gmail.com
>
> Dear Maintainer,
>
> Simply executing 'protontricks' shows the usage instructions.
Executing it with
> commands results in a Python error message.
>
> $ protontricks -s "No Man's Sky"
> Traceback (most recent call last):
> File "/usr/bin/protontricks", line 33, in
> sys.exit(load_entry_point('protontricks==1.5.0', 'console_scripts',
> 'protontricks')())
> File "/usr/lib/python3/dist-packages/protontricks/cli.py", line 167,
in main
> steam_lib_paths = get_steam_lib_paths(steam_path)
> File "/usr/lib/python3/dist-packages/protontricks/steam.py", line 613, in
> get_steam_lib_paths
> library_folders = parse_library_folders(folders_vdf_path.read_text())
> File "/usr/lib/python3/dist-packages/protontricks/steam.py", line 597, in
> parse_library_folders
> Path(value) for key, value in vdf_data["LibraryFolders"].items()
> KeyError: 'LibraryFolders'
>
> $ protontricks --gui
> Traceback (most recent call last):
> File "/usr/bin/protontricks", line 33, in
> sys.exit(load_entry_point('protontricks==1.5.0', 'console_scripts',
> 'protontricks')())
> File "/usr/lib/python3/dist-packages/protontricks/cli.py", line 167,
in main
> steam_lib_paths = get_steam_lib_paths(steam_path)
> File "/usr/lib/python3/dist-packages/protontricks/steam.py", line 613, in
> get_steam_lib_paths
> library_folders = parse_library_folders(folders_vdf_path.read_text())
> File "/usr/lib/python3/dist-packages/protontricks/steam.py", line 597, in
> parse_library_folders
> Path(value) for key, value in vdf_data["LibraryFolders"].items()
> KeyError: 'LibraryFolders'
>
> I had previously installed protontricks as a normal user, using pipx,
following
> the instructions at https://github.com/Matoking/protontricks and used it
> successfully. I uninstalled it, using pipx, prior to installing the
Debian
> package.
>
>
> -- System Information:
> Debian Release: 11.0
> APT prefers unstable
> APT policy: (500, 'unstable'), (1, 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 5.10.0-8-amd64 (SMP w/12 CPU threads)
> Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
> TAINT_UNSIGNED_MODULE
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE not
> set
> Shell: /bin/sh linked to /usr/bin/dash
Bug#981113: ITP: root-framework -- data analysis framework
For everyone who is interested in the topic: Initial packaging for v6.24.02 is now on Salsa [1]. Let me know if you have issues with building. The following things still need to be done, orderd after importance: - write a DEP-5 copyright - remove builtins from the source tarball - split the package sanely - understand linking of libRInside.so - package UNU.RAN [2] - package VDT [3] - package VecGeom [4] - update Pythia8 [5, 6] Some notes: the usual library splitting is basically impossible for ROOT. There are several reasons for this, one being the insane amount of libraries, 142 to be precise. Some of them also have very general names like "libGui.so". The other reason is that ROOT works less like boost, which also has a lot of libraries, and more like one interwoven network of libraries where you want to have all (or at least most) of them. For these two reasons, libraries are installed to lib/multi-arch-triplet/root instead of lib/multi-arch-triplet, and a config for ld.so is added to pick the libraries up. This isn't ideal of course, but better than the alternative. Splitting thus will be more centered around additional dependencies, like for example the Python interface of ROOT. But I haven't started with that yet. The most important and still missing work is the DEP-5 copyright file. ROOT has tons of files, and looking through them will take a significant amount of time. ROOT also includes some thirdparty dependencies which we don't want and need to remove from the source tarball. Since I'm wiriting my Bachelor thesis at the moment, I don't have time for this anytime soon. If someone wants to help with that, I would appreciate it. Besides this, I'll still have to figure out how to properly link against the R library, one mail to the R team is probably enough but I haven't done it yet. All important dependencies are already packaged in Debian, but there are some features that require additional dependencies. UNU.RAN can be used for random number generation, but I haven't looked at the code yet at all. VDT can be used for fast vectorized function, but the CMake build file require some heavy modification to be actually usable. VecGeom is relatively straight forward to package and I will probably upload it in the near future, it is used for vectorized geometry. Pythia8 is a Monte-Carlo event generator, the package is in Debian, but completely outdated and unmaintained. - Stephan [1] https://salsa.debian.org/science-team/root [2] http://statistik.wu-wien.ac.at/unuran/ [3] https://github.com/dpiparo/vdt [4] https://bugs.debian.org/988526 [5] https://tracker.debian.org/pkg/pythia8 [6] https://pythia.org/
Bug#990625: piper: Svg images of mouse models are not packaged.
On Fri, 02 Jul 2021 19:10:49 -0300 =?utf-8?q?Sebasti=C3=A1n_Lacuesta?= wrote: > * What led up to the situation?: Mouse images do not show > * What exactly did you do (or not do) that was effective (or > ineffective)?: Check for package contents. > * What was the outcome of this action?: Mouse svg files are not packaged. > * What outcome did you expect instead?: I expect that piper show the image > of the mouse. Hi Sebastián, First of all I want to regard the title of the bugreport: the svgs are inside /usr/share/piper/piper.gresource, which is build from the upstream svgs at build time. Now, let's try to figure out why you don't see an image of your mouse. Not all mice supported by libratbag have images available, so it would be important to know which device you have. Please provide me with the output of `lsusb` and `ratbagctl list` with the mouse conntected. Then I can see if this is an actual bug or if there is just no image for your mouse. Regards, Stephan
Bug#989474: lutris: Needs patch for Python 3.9 compatibility
On Fri, 04 Jun 2021 19:47:09 +0200 Frederik Himpe wrote:
> Package: lutris
> Version: 0.5.8.3-1
> Severity: normal
> Tags: patch
> X-Debbugs-Cc: frede...@frehi.be
>
> Installation of the game Obduction from GOG failed with this message:
> AttributeError("'xml.etree.ElementTree.Element' object has no attribute
> 'getchildren'")
>
> This is fixed by this patch:
>
https://github.com/lutris/lutris/pull/3430/commits/8ac18d594c72d40308899e775868d49f2e4d98bd
Control: tags -1 pending
Hi Frederik,
thanks for reporting this. I prepared a new upload and requested an
unblock in #989506.
Regards,
Stephan
Bug#989506: unblock: lutris/0.5.8.3-2
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: stephanlach...@debian.org
Please unblock package lutris
[ Reason ]
This fixes an issue appearing with Python 3.9 in a part of the program.
Without this fix, the program will crash when this code is executed due to a
deprecated call.
Python 3.9 is the version shipped in bullseye.
[ Impact ]
The user might experience a crash.
[ Tests ]
No automatic tests cover this part of the code.
The code was not manually tested since I don't have the files required to test
it.
[ Risks ]
The risk of this change is very low.
The package is a end-user package with no reverse dependencies.
The code change is trivial (one line).
The code change follows the recommend new code for the deprecated code
according to the Python documentation [1].
[ Checklist ]
[x] all changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in testing
[ Other info ]
Closes #989474
unblock lutris/0.5.8.3-2
Regards,
Stephan
[1]
https://docs.python.org/3.8/library/xml.etree.elementtree.html#xml.etree.ElementTree.Element.getchildren
diff -Nru lutris-0.5.8.3/debian/changelog lutris-0.5.8.3/debian/changelog
--- lutris-0.5.8.3/debian/changelog 2021-01-23 12:45:21.0 +0100
+++ lutris-0.5.8.3/debian/changelog 2021-06-05 19:59:53.0 +0200
@@ -1,3 +1,9 @@
+lutris (0.5.8.3-2) unstable; urgency=medium
+
+ * Fix compatibility with Python 3.9 (Closes: #989474)
+
+ -- Stephan Lachnit Sat, 05 Jun 2021 19:59:53
+0200
+
lutris (0.5.8.3-1) unstable; urgency=medium
* New upstream version 0.5.8.3
diff -Nru lutris-0.5.8.3/debian/patches/0001-fix-python3_9.patch
lutris-0.5.8.3/debian/patches/0001-fix-python3_9.patch
--- lutris-0.5.8.3/debian/patches/0001-fix-python3_9.patch 1970-01-01
01:00:00.0 +0100
+++ lutris-0.5.8.3/debian/patches/0001-fix-python3_9.patch 2021-06-05
19:59:53.0 +0200
@@ -0,0 +1,16 @@
+From: 6d6178667269747a <https://github.com/6d6178667269747a>
+Description: Fix Python 3.9 compatibility
+Origin: upstream,
https://github.com/lutris/lutris/pull/3430/commits/8ac18d594c72d40308899e775868d49f2e4d98bd
+Applied-Upstream: yes
+Bug-Debian: http://bugs.debian.org/989474
+--- a/lutris/util/wine/cabinstall.py
b/lutris/util/wine/cabinstall.py
+@@ -124,7 +124,7 @@
+ arch = self.get_arch_from_manifest(root)
+ registry_keys =
root.findall("{urn:schemas-microsoft-com:asm.v3}registryKeys")
+ if registry_keys:
+-for registry_key in registry_keys[0].getchildren():
++for registry_key in list(registry_keys[0]):
+ key = self.process_key(registry_key.attrib["keyName"])
+ out += "[%s]\n" % key
+ for reg_value in
registry_key.findall("{urn:schemas-microsoft-com:asm.v3}registryValue"):
diff -Nru lutris-0.5.8.3/debian/patches/series
lutris-0.5.8.3/debian/patches/series
--- lutris-0.5.8.3/debian/patches/series1970-01-01 01:00:00.0
+0100
+++ lutris-0.5.8.3/debian/patches/series2021-06-05 19:59:53.0
+0200
@@ -0,0 +1 @@
+0001-fix-python3_9.patch
Bug#989101: ITP: libliftoff -- lightweight hardware composer library for libdrm
Package: wnpp Severity: wishlist Owner: Stephan Lachnit X-Debbugs-Cc: debian-de...@lists.debian.org, stephanlach...@debian.org * Package name: libliftoff Version : 0.0.0~git20210430.799 Upstream Author : Simon Ser <~emersion/public-in...@lists.sr.ht> * URL : https://github.com/emersion/libliftoff * License : MIT) Programming Lang: C Description : lightweight hardware composer library for libdrm Dependency for gamescope. Not sure where to maintain, will probably talk to the X Strike Force team. Description: libliftoff eases the use of KMS planes from userspace without standing in your way. Users create "virtual planes" called layers, set KMS properties on them, and libliftoff will pick planes for these layers if possible. Longer explaination: https://emersion.fr/blog/2019/xdc2019-wrap-up/#libliftoff - Stephan
Bug#989085: ITP: gamescope -- micro-compositor for games
Hi Sam, yes I know. I haven't come up with a good 3 line description yet. tl;dr: it's an application that allows to run programs in a nested environment originating from the SteamOS compositor. The main use is to run older games in their original resolution on a high dpi screen via upscaling. - Stephan On Tue, May 25, 2021 at 6:23 PM Sam Hartman wrote: > > >>>>> "Stephan" == Stephan Lachnit writes: > > Stephan> BSD-2-Clause Programming Lang: C Description : > Stephan> micro-compositor for games > > Stephan> Will maintain in Games team. > > Stephan> Description on GitHub: > > Stephan> In an embedded session usecase, gamescope does the same > Stephan> thing as steamcompmgr, but with less extra copies and > Stephan> latency: > > That description isn't good enough that I can tell what this is without > going and doing a bunch of additional research. > I'd recommend improving significantly so someone can tell from the > package description whether they want the package.
Bug#989085: ITP: gamescope -- micro-compositor for games
Package: wnpp Severity: wishlist Owner: Stephan Lachnit X-Debbugs-Cc: debian-de...@lists.debian.org, stephanlach...@debian.org.com * Package name: gamescope Version : 3.8.1 Upstream Author : Pierre-Loup A. Griffais * URL : https://github.com/Plagman/gamescope * License : BSD-2-Clause Programming Lang: C Description : micro-compositor for games Will maintain in Games team. Description on GitHub: In an embedded session usecase, gamescope does the same thing as steamcompmgr, but with less extra copies and latency: It's getting game frames through Wayland by way of Xwayland, so there's no copy within X itself before it gets the frame. It can use DRM/KMS to directly flip game frames to the screen, even when stretching or when notifications are up, removing another copy. When it does need to composite with the GPU, it does so with async Vulkan compute, meaning you get to see your frame quick even if the game already has the GPU busy with the next frame. It also runs on top of a regular desktop, the 'nested' usecase steamcompmgr didn't support. Because the game is running in its own personal Xwayland sandbox desktop, it can't interfere with your desktop and your desktop can't interfere with it. You can spoof a virtual screen with a desired resolution and refresh rate as the only thing the game sees, and control/resize the output as needed. This can be useful in exotic display configurations like ultrawide or multi-monitor setups that involve rotation. It runs on Mesa+AMDGPU, and could be made to run on other Mesa/DRM drivers with minimal work. Can support NVIDIA if/when they support accelerated Xwayland. - Stephan
Bug#988524: ITP: vc -- portable, zero-overhead C++ types for explicitly data-parallel programming
Ahh thanks, apparently I'm blind. - Stephan ‐‐‐ Original Message ‐‐‐ On Friday, May 14, 2021 10:10 PM, Boyuan Yang wrote: > X-Debbugs-CC: tsimo...@debian.org debian-de...@lists.debian.org > > 在 2021-05-14星期五的 21:59 +0200，Stephan Lachnit写道： > > > Package: wnpp > > Severity: wishlist > > Owner: Stephan Lachnit stephanlach...@debian.org > > X-Debbugs-Cc: debian-de...@lists.debian.org, stephanlach...@debian.org > > > > - Package name : vc > > Version : 1.4.1 > > Upstream Author : Matthias Kretz m.kr...@gsi.de > > > > - URL : https://github.com/VcDevel/Vc > > https://tracker.debian.org/pkg/vc > > > > Regards, > Boyuan Yang
Bug#988524: ITP: vc -- portable, zero-overhead C++ types for explicitly data-parallel programming
Package: wnpp Severity: wishlist Owner: Stephan Lachnit X-Debbugs-Cc: debian-de...@lists.debian.org, stephanlach...@debian.org * Package name: vc Version : 1.4.1 Upstream Author : Matthias Kretz * URL : https://github.com/VcDevel/Vc * License : BSD 3-Clause Programming Lang: C++ Description : portable, zero-overhead C++ types for explicitly data- parallel programming Library providing C++ types for parallel programming. Needed for VecCore / VecGeom, which in turn is an optional feature of Geant4 and ROOT. Will maintain in the science team. - Stephan
Bug#988526: ITP: vecgeom -- vectorized geometry library for particle-detector simulation
Package: wnpp Severity: wishlist Owner: Stephan Lachnit X-Debbugs-Cc: debian-de...@lists.debian.org, stephanlach...@debian.org * Package name: vecgeom Version : 1.1.14 Upstream Author : Geant4 Collaboration * URL : https://gitlab.cern.ch/VecGeom/VecGeom * License : Apache-2.0 Programming Lang: C++ Description : vectorized geometry library for particle-detector simulation Library mainly for Geant4, enabling better performance. Will maintain in science team. - Stephan
