Bug#1063762: Acknowledgement (Build path leaks in generated documents, introducing reproducibility issues)
Adding the missing attachment Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini output.html.gz Description: application/gzip
Bug#1063762: Build path leaks in generated documents, introducing reproducibility issues
Package: sphinx Version: 7.2.6-4 Severity: important Hello, and thank you for your work on sphinx! Possibly due to https://salsa.debian.org/python-team/packages/sphinx/-/commit/4a1ebb237fb0f10adef3df39c2844aa68b9da79c sphinx leaks the build path into the generated output (see attached output.html.gz). This looks like an accidental mistake that is currently making packages unreproducible. Thanks, Enrico -- System Information: Debian Release: 12.4 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-15-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), LANGUAGE=en_IE:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1050896: Packagesearch Copyright Statement
On Sun, Oct 01, 2023 at 12:42:39PM +0200, Benjamin Mesing wrote: > Bug #1050896 now states that I should clarify copyright: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1050896 > I would like to switch to GPL3+ and would like your approval for this > license switch. Sure, by all means please go ahead with the license switch to GPL3+. If it can he helpful to you in the future, I'm hereby tranfering all my copyright claims on packagesearch (if any) over to you. Thank you for your work on packagesearch! Enrico Zini -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini signature.asc Description: PGP signature
Bug#885698: What licenses should be included in /usr/share/common-licenses?
On Sat, Sep 09, 2023 at 08:35:27PM -0700, Russ Allbery wrote: > Licenses will be included in common-licenses if they meet all of the > following criteria: > > * The license is DFSG-free. > * Exactly the same license wording is used by all works covered by it. > * The license applies to at least 100 source packages in Debian. > * The license text is longer than 25 lines. I like this. I'd say that even if a license is shorter than 25 lines I'd appreciate to be able to link to it instead of copypasting it. I like to be able to fill the license field with a value, after checking that the upstream license didn't diverge from what it looks like. I'd love to use SPDX IDs there, for example. In an ideal world, I'd like to autofill debian/copyright with SPDX IDs from upstream metadata. Having a link to a file goes closer to having a declarative license ID. In general the less bytes I have to maintain in debian/* the happier I am, and as a personal aesthetic sense I feel like the less bytes we all have to maintain in debian/* the less is our collective maintenance burden. Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini
Bug#1041537: python3 platlib points again to /usr/local
On Tue, Aug 01, 2023 at 11:23:43PM +0300, Jussi Pakkanen wrote: > On Fri, 21 Jul 2023 at 14:09, Jeremy Bícha wrote: > > > We have been working around this in several Debian packages by setting > > this in debian/rules: > > export DEB_PYTHON_INSTALL_LAYOUT = deb > > I'm confused. Why is this not set by default when building packages? > FWICT this is a custom patch in Debian to make Python use deb paths.In > this case Meson is doing exactly what you ask it to do, which is to > use local paths because that environment variable is not set to `deb`. It will, though it's not there yet. See the thread starting from https://lists.debian.org/debian-devel/2023/07/msg00307.html and see https://salsa.debian.org/python-team/tools/dh-python/-/commit/fe7912b8ff386cf21478f2cd7f055b2a8665fdd4 Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini
Bug#1037898: wreport: ftbfs with GCC-13
On Thu, Jul 27, 2023 at 04:49:11PM +0800, Bo YU wrote: > The patch will fix the gcc-13 build issue and resovled the #1041537, > could you give a try on next upload? I confirm that it builds. I'll incorporate the `DEB_PYTHON_INSTALL_LAYOUT = deb` addition into the new upstream release that I had already prepared, and thanks for testing it for me! I was waiting to understand what was the proper way to fix this, and it looks like, from the last messages in debian-devel, that it's this one indeed Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini signature.asc Description: PGP signature
Bug#1041941: $ARCH-pkg-config reads a file ./$ARCH
Package: pkgconf Version: 1.8.1-1 Severity: normal Hello, this was surprising behaviour for which I cannot find documentation, which I discovered by accident by having a $ARCH file in my build directory: If invoking as pkg-config, everything is fine: $ rm x86_64-linux-gnu $ pkg-config --cflags libxml-2.0 -I/usr/include/libxml2 $ echo foo > x86_64-linux-gnu $ pkg-config --cflags libxml-2.0 -I/usr/include/libxml2 If invoking as /usr/bin/x86_64-linux-gnu-pkg-config instead, a file with called x86_64-linux-gnu gets parsed and influences the results: $ rm x86_64-linux-gnu $ /usr/bin/x86_64-linux-gnu-pkg-config --cflags libxml-2.0 -I/usr/include/libxml2 $ echo foo > x86_64-linux-gnu $ /usr/bin/x86_64-linux-gnu-pkg-config --cflags libxml-2.0 Package libxml-2.0 was not found in the pkg-config search path. Perhaps you should add the directory containing `libxml-2.0.pc' to the PKG_CONFIG_PATH environment variable Package 'libxml-2.0', required by 'virtual:world', not found It may be expected behaviour, or it may be something unintended that leads to unexpected code execution. I cannot find it documented in man pkg-config(1) or man pc(5) and I cannot tell what it's supposed to do, so I'll limit myself to reporting the surprising behaviour. It was pretty tricky to debug why this source which included such a file used to build before bookworm and in bookworm stopped being unable to find its dependencies Thanks, Enrico -- System Information: Debian Release: 12.1 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-9-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), LANGUAGE=en_IE:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages pkgconf depends on: ii pkgconf-bin 1.8.1-1 pkgconf recommends no packages. pkgconf suggests no packages. -- no debconf information
Bug#1041537: python3 platlib points again to /usr/local
Package: meson
Version: 1.2.0-1
Severity: serious
Hello,
Thank you for maintaining Meson!
At first glance it looks like there is a regression of
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1026312
On stable:
$ cat meson.build
project('test', 'cpp', version: '3.36', license : 'GPL-2.0-or-later')
pymod = import('python')
python3 = pymod.find_installation('python3', required: false)
message('PLATLIB', python3.get_path('platlib'))
$ meson setup /tmp/zz
The Meson build system
Version: 1.0.1
Source dir: [...]
Build dir: /tmp/zz
Build type: native build
Project name: test
Project version: 3.36
C++ compiler for the host machine: ccache c++ (gcc 12.2.0 "c++ (Debian
12.2.0-14) 12.2.0")
C++ linker for the host machine: c++ ld.bfd 2.40
Host machine cpu family: x86_64
Host machine cpu: x86_64
Program python3 found: YES (/usr/bin/python3)
Message: PLATLIB /usr/lib/python3/dist-packages
On sid:
$ cat meson.build
project('test', 'cpp', version: '3.36', license : 'GPL-2.0-or-later')
pymod = import('python')
python3 = pymod.find_installation('python3', required: false)
message('PLATLIB', python3.get_path('platlib'))
$ meson setup /tmp/zz
The Meson build system
Version: 1.2.0
Source dir: [...]
Build dir: /tmp/zz
Build type: native build
Project name: test
Project version: 3.36
C++ compiler for the host machine: c++ (gcc 13.1.0 "c++ (Debian 13.1.0-8)
13.1.0")
C++ linker for the host machine: c++ ld.bfd 2.40.90.20230714
Host machine cpu family: x86_64
Host machine cpu: x86_64
Program python3 found: YES (/usr/bin/python3)
Message: PLATLIB /usr/local/lib/python3.11/dist-packages
This is affecting wreport, and I guess the same list of packages as
#1026312
Enrico
-- System Information:
Debian Release: trixie/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 6.1.0-9-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages meson depends on:
ii ninja-build1.11.1-1
ii python33.11.4-5
ii python3-pkg-resources 68.0.0-1
ii python3-setuptools 68.0.0-1
Versions of packages meson recommends:
ii dpkg-dev 1.21.22
meson suggests no packages.
-- no debconf information
Bug#1033052: eviacam quits with "cvCreateCameraCapture doesn't support legacy API anymore"
Package: eviacam Version: 2.1.4-2.1 Severity: important Hello, thank you for packaging eviacam! I tried it out, and I don't seem to be able to make it work. From the output, it looks like some API has changed: $ eviacam [ERROR:0@0.026] global ./modules/core/src/persistence.cpp (505) open Can't open file: '/usr/share/eviacam/haarcascade_frontalface_default.xml' in read mode [ERROR:0@0.026] global ./modules/core/src/persistence.cpp (505) open Can't open file: '/usr/share/opencv/haarcascades/haarcascade_frontalface_default.xml' in read mode [ERROR:0@0.026] global ./modules/core/src/persistence.cpp (505) open Can't open file: '/usr/share/OpenCV/haarcascades/haarcascade_frontalface_default.xml' in read mode [libwebcam] Invalid V4L2 control type encountered: ctrl_id = 0x00980001, name = 'User Controls', type = 6 [libwebcam] Invalid or unsupported V4L2 control encountered: ctrl_id = 0x00980001, name = 'User Controls' [libwebcam] Invalid V4L2 control type encountered: ctrl_id = 0x009A0001, name = 'Camera Controls', type = 6 [libwebcam] Invalid or unsupported V4L2 control encountered: ctrl_id = 0x009A0001, name = 'Camera Controls' [ WARN:0@4.467] global ./modules/videoio/src/videoio_c.cpp (15) cvCreateCameraCapture cvCreateCameraCapture doesn't support legacy API anymore. Enrico -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-6-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), LANGUAGE=en_IE:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages eviacam depends on: ii debconf [debconf-2.0] 1.5.82 ii libc6 2.36-8 ii libgcc-s1 12.2.0-14 ii libgtk-3-0 3.24.37-2 ii libopencv-core406 4.6.0+dfsg-11 ii libopencv-imgproc4064.6.0+dfsg-11 ii libopencv-objdetect406 4.6.0+dfsg-11 ii libopencv-video406 4.6.0+dfsg-11 ii libopencv-videoio4064.6.0+dfsg-11 ii libstdc++6 12.2.0-14 ii libv4l-01.22.1-5+b1 ii libwxbase3.2-1 3.2.2+dfsg-2 ii libwxgtk3.2-1 3.2.2+dfsg-2 ii libx11-62:1.8.4-2 ii libxtst62:1.2.3-1.1 ii opencv-data 4.6.0+dfsg-11 Versions of packages eviacam recommends: pn wx3.0-i18n eviacam suggests no packages. -- debconf information: eviacamloader/eviacamloader_setuid: false
Bug#986357: Please improve package description
On Sat, Feb 25, 2023 at 03:58:34AM +, peter green wrote: > It looks like the description we have today was written when sq was > first packaged, but wasn't actually incorporated into the package > until later because of > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=993633 > > Version 0.25.0-1 simply had > > > Description: Command-line frontends for Sequoia > > This package contains the following binaries built from the Rust crate > > "sequoia-sq": > >- sq That's correct. I think now the description makes sense, and I like the improvements you propose. Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini
Bug#1032997: ITP: pylsl -- Python bindings for liblsl
Package: wnpp Severity: wishlist Owner: Enrico Zini X-Debbugs-Cc: debian-de...@lists.debian.org, debian-scie...@lists.debian.org * Package name: pylsl Version : 1.16.1 Upstream Contact: Christian A. Kothe * URL : https://github.com/labstreaminglayer/pylsl * License : MIT Programming Lang: Python Description : Python bindings for liblsl This is the Python interface to the Lab Streaming Layer (LSL). LSL is an overlay network for real-time exchange of time series between applications, most often used in research environments. LSL has clients for many other languages and platforms that are compatible with each other. - - - LSL seems to be a standard for taking data from devices like EEG sensors and making them availale to software that analyses them. I've packaged this for a personal project, and it would be straightforward to upload it to Debian. I can't take responsibility for supporting people with more professional needs besides trying to deal with FTBFS kind of issues, but after asking in the Debian Science Team mailing list, it can be maintained under the Science Team umbrella.
Bug#1032996: ITP: liblsl -- lsl library for multi-modal time-synched data transmission over the local network
Package: wnpp Severity: wishlist Owner: Enrico Zini X-Debbugs-Cc: debian-de...@lists.debian.org, debian-scie...@lists.debian.org * Package name: liblsl Version : 4.6.0 Upstream Contact: Christian A. Kothe * URL : https://github.com/sccn/liblsl * License : MIT Programming Lang: C++ Description : lsl library for multi-modal time-synched data transmission over the local network The lab streaming layer is a simple all-in-one approach to streaming experiment data between applications in a lab, e.g. instrument time series, event markers, audio, and so on LSL seems to be a standard for taking data from devices like EEG sensors and making them availale to software that analyses them. I've packaged this for a personal project, and it would be straightforward to upload it to Debian. I can't take responsibility for supporting people with more professional needs besides trying to deal with FTBFS kind of issues, but after asking in the Debian Science Team mailing list, it can be maintained under the Science Team umbrella.
Bug#1032586: Please add Provides: headers to provide names following the HDF5 Filter Plugin Packaging Guidelines
Source: h5py Version: 3.7.0-8 Severity: wishlist Tags: patch Hello, the HDF5 Filter Plugin Packaging Guidelines at https://salsa.debian.org/science-team/h5f-packaging-guidelines suggests a unified naming scheme for HDF5 filter plugin packages, so that packages that depend on a plugin can do so regardless of where it is implemented. I created a MR to add support for this for hdf5-plugin-lzf, which also adds autopkgtests to test that the plugins loads: https://salsa.debian.org/science-team/h5py/-/merge_requests/2 I tested the MR by creating a fork of h5py and setting "Settings/CI-CD/General pipelines/CI/CD configuration file" to recipes/debian.yml@salsa-ci-team/pipeline[1]: https://salsa.debian.org/enrico/h5py/-/pipelines/509549 Thanks, Enrico [1] see https://salsa.debian.org/salsa-ci-team/pipeline#basic-use -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-3-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), LANGUAGE=en_IE:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1032583: Please add Provides: headers to provide names following the HDF5 Filter Plugin Packaging Guidelines
Source: bitshuffle Version: 0.3.5-4 Severity: wishlist Tags: patch Hello, the HDF5 Filter Plugin Packaging Guidelines at https://salsa.debian.org/science-team/h5f-packaging-guidelines suggests a unified naming scheme for HDF5 filter plugin packages, so that packages that depend on a plugin can do so regardless of where it is implemented. I created a MR to add support for this to bitshuffle, which also adds autopkgtests to test that the plugins load from h5py: https://salsa.debian.org/alteholz/bitshuffle/-/merge_requests/2 I tested the MR by creating a fork of bitshuffle and setting "Settings/CI-CD/General pipelines/CI/CD configuration file" to recipes/debian.yml@salsa-ci-team/pipeline[1]: https://salsa.debian.org/enrico/bitshuffle/-/pipelines/509547 Thanks, Enrico [1] see https://salsa.debian.org/salsa-ci-team/pipeline#basic-use -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-3-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), LANGUAGE=en_IE:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1032203: Please backport version 4.4.0
Package: python3-typing-extensions Version: 4.4.0-1 Severity: wishlist Hello, thanks for packaging python3-typing-extensions! Now that 4.4.0 is in testing, would it be possible to also upload it to backports? It contains support for python 3.11 typing additions, and since python 3.11 is the version that is going to be in the new stable, having it in bullseye-backports would allow to start targeting bookworm a bit more during Python development. Thanks, Enrico -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-3-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), LANGUAGE=en_IE:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages python3-typing-extensions depends on: ii python3 3.11.2-1 python3-typing-extensions recommends no packages. python3-typing-extensions suggests no packages. -- no debconf information
Bug#1031022: Does not work on big endian machines
Source: h5z-zfp Version: 1.1.0+git20221021-4 Severity: important Tags: upstream X-Debbugs-Cc: debian-s...@lists.debian.org Hello, there are interoperability issues between big endian and little endian machines when using the H5Z-ZFP plugin, so I disabled building on big-endian machines for now. The problem is reported upstream, with an extensive analysis done by me and Helmut Grohne, at: https://github.com/LLNL/H5Z-ZFP/issues/100 Enrico -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 6.0.0-6-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), LANGUAGE=en_IE:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1030772: arm64 build failure
Package: hyperspy Version: 1.7.3-1 Severity: important Hello, the test suite segfaults multiple times on arm64: https://buildd.debian.org/status/fetch.php?pkg=hyperspy=arm64=1.7.3-1=1675767050=0 For now I opened an issue to remove of the old binary package from arm64. I'm opening this bug to track the situation. Enrico -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 6.0.0-6-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), LANGUAGE=en_IE:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1030770: RM: hyperspy [arm64] -- ROM; Does not build on a number of architectures
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove Hello, hyperspy 1.6.1-1 already failed to build on a number of architectures, and with 1.7.3-1 I also get segfaults when running tests on arm64. Given that this package is used mostly on amd64, I'd like to clear the situation on arm64 for now. Thanks, Enrico
Bug#1029965: RM: hdf5-filter-plugin-blosc -- ROM; Binary package renamed
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: hdf5-bl...@packages.debian.org Control: affects -1 + src:hdf5-blosc Hello, please remove the hdf5-filter-plugin-blosc binary package: since version 0.0~git20220616.9683f7d-4 it has been renamed to hdf5-filter-plugin-blosc-serial to follow https://salsa.debian.org/science-team/h5f-packaging-guidelines Thanks, Enrico
Bug#1029964: RM: hdf5-plugin-zfp -- ROM; Binary package renamed
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: h5z-...@packages.debian.org Control: affects -1 + src:h5z-zfp Hello, please remove the hdf5-plugin-zfp binary package: since version 1.1.0+git20221021-3 it has been renamed to hdf5-filter-plugin-zfp-serial to follow https://salsa.debian.org/science-team/h5f-packaging-guidelines Thanks, Enrico
Bug#1029761: RM: dballe -- ROM; Too fringe to be in Debian
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: dba...@packages.debian.org Control: affects -1 + src:dballe Hello, please remove dballe and all its binary packages from unstable (and testing). It doesn't see much use outside the agency where we're developing it, and the pace of internal development doesn't match Debian's release schedule, so keeping it in Debian seems currently like more trouble than it's worth. It's not a lot of trouble, but let's remove a little bit of trouble from the upcoming freeze :) Thanks, Enrico
Bug#1029102: Aborted (segmentation fault) when starting ssr
Package: soundscaperenderer
Version: 0.5.0~dfsg-6
Severity: important
Hello,
thank you for packaging soundscaperenderer!
I installed the package and tried to run it, but immediately got a
segfault:
$ ssr
Cannot connect to server socket err = Connection refused
Cannot connect to server request channel
jackdmp 1.9.21
Copyright 2001-2005 Paul Davis and others.
Copyright 2004-2016 Grame.
Copyright 2016-2022 Filipe Coelho.
jackdmp comes with ABSOLUTELY NO WARRANTY
This is free software, and you are welcome to redistribute it
under certain conditions; see the file COPYING for details
Cannot create RT messagebuffer thread: Operation not permitted (1)
Retrying messagebuffer thread without RT scheduling
Messagebuffer not realtime; consider enabling RT scheduling for user
no message buffer overruns
Cannot create RT messagebuffer thread: Operation not permitted (1)
Retrying messagebuffer thread without RT scheduling
Messagebuffer not realtime; consider enabling RT scheduling for user
no message buffer overruns
Cannot create RT messagebuffer thread: Operation not permitted (1)
Retrying messagebuffer thread without RT scheduling
Messagebuffer not realtime; consider enabling RT scheduling for user
no message buffer overruns
JACK server starting in realtime mode with priority 10
self-connect-mode is "Don't restrict self connect requests"
audio_reservation_init
Acquire audio card Audio0
creating alsa driver ... hw:0|hw:0|1024|2|48000|0|0|nomon|swmeter|-|32bit
configuring for 48000Hz, period = 1024 frames (21.3 ms), buffer = 2 periods
ALSA: final selected sample format for capture: 32bit integer little-endian
ALSA: use 2 periods for capture
ALSA: final selected sample format for playback: 32bit integer little-endian
ALSA: use 2 periods for playback
Cannot use real-time scheduling (RR/10) (1: Operation not permitted)
AcquireSelfRealTime error
terminate called after throwing an instance of 'std::runtime_error'
what(): Can't set scheduling priority for thread!
/usr/bin/ssr: line 52: 1189382 Aborted (core dumped)
$SSR_EXECUTABLE "${OPTIONS[@]}"
Unknown error...
terminate called after throwing an instance of 'Jack::JackTemporaryException'
what():
Enrico
-- System Information:
Debian Release: bookworm/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 6.0.0-6-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8),
LANGUAGE=en_IE:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages soundscaperenderer depends on:
ii jackd 5+nmu1
ii libc6 2.36-8
ii libecasoundc1v5 2.9.3-4+b1
ii libfftw3-single3 3.3.10-1
ii libgcc-s1 12.2.0-13
ii libgl11.6.0-1
ii libglu1-mesa [libglu1]9.0.2-1.1
ii libjack-jackd2-0 [libjack-0.125] 1.9.21~dfsg-1
ii libqt5core5a 5.15.7+dfsg-2
ii libqt5gui55.15.7+dfsg-2
ii libqt5opengl5 5.15.7+dfsg-2
ii libqt5widgets55.15.7+dfsg-2
ii libsndfile1 1.2.0-1
ii libstdc++612.2.0-13
ii libxml2 2.9.14+dfsg-1.1+b2
ii soundscaperenderer-common 0.5.0~dfsg-6
Versions of packages soundscaperenderer recommends:
ii ecasound 2.9.3-4+b1
soundscaperenderer suggests no packages.
-- no debconf information
Bug#1029099: soundgrain does not start
Package: soundgrain Version: 6.0.1-3 Severity: important Hello, Thank you for packaging soundgrain! I ran `apt install soundgrain` then tried to start it: $ soundgrain Traceback (most recent call last): File "/usr/bin/soundgrain", line 60, in app = SoundGrainApp(redirect=False) File "/usr/bin/soundgrain", line 41, in __init__ self.frame = MainFrame(None, -1, pos=(0, 20), size=(sizex, sizey), File "/usr/share/soundgrain/Resources/MainFrame.py", line 220, in __init__ self.controls = ControlPanel(self, self.panel) File "/usr/share/soundgrain/Resources/ControlPanel.py", line 193, in __init__ rec1Box.Add(self.but_folder, 1, wx.ALIGN_CENTER_VERTICAL | wx.EXPAND | wx.RIGHT, 10) wx._core.wxAssertionError: C++ assertion "CheckSizerFlags(!((flags) & (wxALIGN_RIGHT | wxALIGN_CENTRE_HORIZONTAL | wxALIGN_BOTTOM | wxALIGN_CENTRE_VERTICAL)))" failed at ./src/common/sizer.cpp(2288) in DoInsert(): wxALIGN_RIGHT | wxALIGN_CENTRE_HORIZONTAL | wxALIGN_BOTTOM | wxALIGN_CENTRE_VERTICAL will be ignored in this sizer: wxEXPAND overrides alignment flags in box sizers DO NOT PANIC !! If you're an end user running a program not developed by you, please ignore this message, it is harmless, and please try reporting the problem to the program developers. You may also set WXSUPPRESS_SIZER_FLAGS_CHECK environment variable to suppress all such checks when running this program. If you're the developer, simply remove this flag from your code to avoid getting this message. You can also call wxSizerFlags::DisableConsistencyChecks() to globally disable all such checks, but this is strongly not recommended. Running it with WXSUPPRESS_SIZER_FLAGS_CHECK=1 makes it work, with a number of Gtk warnings: $ WXSUPPRESS_SIZER_FLAGS_CHECK=1 soundgrain [...] (soundgrain:1181640): Gtk-WARNING **: 18:07:40.898: for_size smaller than min-size (8 < 14) while measuring gadget (node check, owner GtkCheckButton) (soundgrain:1181640): Gtk-WARNING **: 18:07:40.900: for_size smaller than min-size (8 < 14) while measuring gadget (node check, owner GtkCheckButton) (soundgrain:1181640): Gtk-WARNING **: 18:07:41.603: for_size smaller than min-size (8 < 14) while measuring gadget (node check, owner GtkCheckButton) Enrico -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 6.0.0-6-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), LANGUAGE=en_IE:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages soundgrain depends on: ii python3 3.10.6-3+b1 ii python3-markdown 3.4.1-2 ii python3-pyo 1.0.4-1+b4 ii python3-wxgtk4.0 4.2.0+dfsg-1+b3 soundgrain recommends no packages. soundgrain suggests no packages. -- no debconf information
Bug#1028548: New upstream version needed
Package: hyperspy
Version: 1.6.1-1
Severity: normal
Hello,
a new upstream version of hyperspy is needed to fix #997475 and to build
with the python/numpy/* toolchain currently in sid.
I started packaging it at https://salsa.debian.org/science-team/hyperspy/
and it's currently blocked by:
* python3-statsmodels and python3-dask not being coinstallable
(relevant issues: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1025393
and https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1027254 )
* seemingly numba-related errors in the test suite of this kind:
```
TestInteractive.test_lazy_interactive_snap[default]
_
[gw1] linux -- Python 3.11.1 /usr/bin/python3.11
self = , snap = True
@pytest.mark.parametrize('snap', [True, False, 'default'])
def test_interactive_snap(self, snap):
kwargs = {}
if snap != 'default':
kwargs['snap'] = snap
else:
# default is True
snap = True
s = self.s
r = RectangularROI(left=3, right=7, top=2, bottom=5)
> s.plot()
hyperspy/tests/utils/test_roi.py:705:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _
hyperspy/_signals/lazy.py:1234: in plot
super().plot(navigator=navigator, **kwargs)
hyperspy/_signals/signal1d.py:1658: in plot
super().plot(navigator=navigator,
hyperspy/signal.py:2898: in plot
self._plot.plot(**kwargs)
hyperspy/drawing/mpl_he.py:188: in plot
self.pointer.connect_navigate()
hyperspy/drawing/widget.py:225: in connect_navigate
self._on_navigate(self.axes_manager)# Update our position
hyperspy/drawing/widget.py:462: in _on_navigate
self.position = p# Use property to trigger events
hyperspy/drawing/widget.py:425: in
lambda s, v: s._set_position(v))
hyperspy/drawing/widget.py:419: in _set_position
position = self._validate_pos(position)
hyperspy/drawing/widget.py:404: in _validate_pos
pos = self._do_snap_position(pos)
hyperspy/drawing/widget.py:434: in _do_snap_position
value[i] = ax.index2value(ax.value2index(value[i]))
hyperspy/axes.py:1214: in value2index
round_half_towards_zero(index, decimals=0),
/usr/lib/python3/dist-packages/numba/core/dispatcher.py:468: in
_compile_for_args
error_rewrite(e, 'typing')
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _
e = TypingError('Failed in nopython mode pipeline (step: nopython
frontend)\n\x1b[1m\x1b[1m\x1b[1mNo implementation of fun... pragma: no cover\n
\n\n\x1b[1mreturn np.where(array >= 0,\n\x1b[0m
\x1b[1m^\x1b[0m\x1b[0m\n')
issue_type = 'typing'
def error_rewrite(e, issue_type):
"""
Rewrite and raise Exception `e` with help supplied based on the
specified issue_type.
"""
if config.SHOW_HELP:
help_msg = errors.error_extras[issue_type]
e.patch_message('\n'.join((str(e).rstrip(), help_msg)))
if config.FULL_TRACEBACKS:
raise e
else:
> raise e.with_traceback(None)
E numba.core.errors.TypingError: Failed in nopython mode pipeline
(step: nopython frontend)
E No implementation of function Function() found for signature:
E
E>>> where(bool, float64, float64)
E
E There are 4 candidate implementations:
E - Of which 4 did not match due to:
E Overload in function
'_OverloadWrapper._build..ol_generated': File:
numba/core/overload_glue.py: Line 129.
E With argument(s): '(bool, float64, float64)':
E Rejected as the implementation raised a specific error:
ETypeError: code() argument 13 must be str, not int
E raised from
/usr/lib/python3/dist-packages/numba/core/overload_glue.py:64
E
E During: resolving callee type: Function()
E During: typing of call at
/media/hyperspy/.pybuild/cpython3_3.11_hyperspy/build/hyperspy/misc/array_tools.py
(557)
E
E
E File "hyperspy/misc/array_tools.py", line 557:
E def round_half_towards_zero(array, decimals=0): # pragma: no cover
E
E
E return np.where(array >= 0,
E ^
/usr/lib/python3/dist-packages/numba/core/dispatcher.py:409: TypingError
```
I'm opening this issue to track progress on the situation.
Enrico
-- System Information:
Debian Release: bookworm/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 6.0.0-6-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=en_IE.UTF-8,
Bug#1026286: Unsatisfiable versioned dependency on python3-numpy
On Tue, Jan 10, 2023 at 01:07:07PM -0800, Diane Trout wrote: > Yeah I know. > > Numba frequently lags on python and numpy updates. > > I think they're closer to having numpy fixes done than python 3.11 > though. > > There's some patches, I've got some of them applied by the system I was > using for a build server broke and I haven't had a chance to fix it. Thanks! I've opened https://github.com/numba/numba/issues/8703 upstream to track the possibility of numba making it in time for testing: let's see what happens. Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini
Bug#1026286: Unsatisfiable versioned dependency on python3-numpy
On Sat, Dec 17, 2022 at 08:19:47PM +0100, Enrico Zini wrote: > thank you for maintaining python3-numba! > Unfortunately the package is currently uninstallable in sid. > It depends on `python3-numpy (<< 1:1.22), python3-numpy (>= 1:1.20.0)`, > but the version of python3-numpy in sid is 1:1.23.5-2. This seems to be the relevant upstream issue: https://github.com/numba/numba/issues/8464 Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini
Bug#1026312: Setuptools 65.5.0-1.1 breaks installing Python modules/extensions via meson
Source: setuptools Version: 65.5.0-1.1 Severity: important Hello, thank you for maintaining setuptools! After the 65.5.0-1.1 update, installing Python modules and extensions via meson makes them end up in /usr/local instead of /usr. More details are in this debian-devel thread: https://lists.debian.org/debian-devel/2022/12/msg00152.html This currently breaks wreport and dballe, and xraylib when I try to build its Python extensions. Enrico Fun fact: unless I missed something in sources.debian.net, there seems to be nobody else but me maintaining Debian packages which install Python modules via meson. -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 6.0.0-4-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), LANGUAGE=en_IE:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1026286: Unsatisfiable versioned dependency on python3-numpy
Package: python3-numba Version: 0.56.2+dfsg-2 Severity: serious Hello, thank you for maintaining python3-numba! Unfortunately the package is currently uninstallable in sid. It depends on `python3-numpy (<< 1:1.22), python3-numpy (>= 1:1.20.0)`, but the version of python3-numpy in sid is 1:1.23.5-2. Thanks, Enrico -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 6.0.0-4-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), LANGUAGE=en_IE:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1025686: Plugin cannot be loaded, not linked against hdf5
Package: hdf5-filter-plugin
Version: 0.0~git2022.49e3b65-2
Severity: serious
Tags: patch
Hello,
hdf5 cannot load the plugin dynamically:
>>> import h5py
>>> h5py.h5z.filter_avail(32004)
False
This is because the library cannot be loaded due to missing HDF5 symbols:
$ python3
Python 3.10.8 (main, Nov 4 2022, 09:21:25) [GCC 12.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import ctypes
>>> lib =
ctypes.CDLL("/usr/lib/x86_64-linux-gnu/hdf5/serial/plugins/libh5lz4.so")
Traceback (most recent call last):
File "", line 1, in
File "/usr/lib/python3.10/ctypes/__init__.py", line 374, in __init__
self._handle = _dlopen(self._name, mode)
OSError: /usr/lib/x86_64-linux-gnu/hdf5/serial/plugins/libh5lz4.so:
undefined symbol: H5E_PLINE_g
I filed a PR upstream that fixes the problem:
https://github.com/nexusformat/HDF5-External-Filter-Plugins/pull/27
I'm attaching the corresponding patch.
Thanks,
Enrico
-- System Information:
Debian Release: bookworm/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 6.0.0-4-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8),
LANGUAGE=en_IE:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages hdf5-filter-plugin depends on:
ii libbz2-1.0 1.0.8-5+b1
ii libc6 2.36-6
ii libhdf5-103-1 1.10.8+repack-4
ii liblz4-1 1.9.4-1
hdf5-filter-plugin recommends no packages.
hdf5-filter-plugin suggests no packages.
commit 3d93e1821dd10962f4477d8b3615024cf10f4cc6
Author: Enrico Zini
Date: Wed Dec 7 12:19:17 2022 +0100
Added missing libraries
diff --git a/LZ4/src/CMakeLists.txt b/LZ4/src/CMakeLists.txt
index b5bf34b..1823eff 100644
--- a/LZ4/src/CMakeLists.txt
+++ b/LZ4/src/CMakeLists.txt
@@ -1,7 +1,7 @@
set(SOURCES H5Zlz4.c lz4_h5plugin.c)
set(INCLUDE_DIRS ${HDF5_INCLUDE_DIRS} ${LZ4_INCLUDE_DIRS})
-set(LINK_LIBS ${LZ4_LIBRARIES})
+set(LINK_LIBS ${LZ4_LIBRARIES} ${HDF5_LIBRARIES})
if(CMAKE_SYSTEM_NAME MATCHES Windows)
#
Bug#1024804: Plugins cannot be found by libhdf5
Source: hdf5-filter-plugin Version: 0.0~git2022.49e3b65-1 Severity: important Hello, thank you for maintaining hdf5-filter-plugin! When working on packaging python-hdf5plugin ( https://salsa.debian.org/science-team/python-hdf5plugin ) I noticed that it cannot load the bitshuffle, bz2, and lz4 plugins. Investigating, I noticed that the package installs the plugins in /usr/lib/x86_64-linux-gnu/plugins, while hdf5 expects them in /usr/lib/x86_64-linux-gnu/hdf5/serial/plugins/ Indeed, moving the plugins there makes hdf5 find them again. At build time, you can get the expected plugin location with: pkg-config hdf5-serial --variable=PluginDir Thanks Enrico -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 6.0.0-4-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), LANGUAGE=en_IE:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#809443: autopkgtest: support systemd-nspawn as an isolation-container level virtualization tool
test: DBG: got reply from testbed: ok
autopkgtest: DBG: TestbedFailure sent `open', got `ok ' (0 result
parameters), expected 1 result parameters
autopkgtest: DBG: testbed stop
autopkgtest: DBG: testbed close, scratch=None
autopkgtest: DBG: sending command to testbed: quit
autopkgtest-virt-nspawn: DBG: executing quit
autopkgtest-virt-nspawn: DBG: cleanup...
autopkgtest [13:56:31]: ERROR: testbed failure: sent `open', got `ok ' (0
result parameters), expected 1 result parameters
autopkgtest: DBG: testbed stop
I know a thing or three about using nspawn containers, but I don't know
much about autopkgtest, and I'd love to team up with someone with the
opposite kind of knowledge to make this work.
Enrico
--
GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini
#!/usr/bin/python3
#
# autopkgtest-virt-nspawn is part of autopkgtest
# autopkgtest is a tool for testing Debian binary packages
#
# autopkgtest is Copyright (C) 2006-2015 Canonical Ltd.
#
# Author: Enrico Zini
#
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program; if not, write to the Free Software
# Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
#
# See the file CREDITS for a full list of credits information (often
# installed as /usr/share/doc/autopkgtest/CREDITS).
import sys
import os
import subprocess
import time
import argparse
import uuid
import signal
import errno
import shlex
from typing import Dict
sys.path.insert(0, '/usr/share/autopkgtest/lib')
sys.path.insert(0, os.path.join(os.path.dirname(os.path.dirname(
os.path.abspath(__file__))), 'lib'))
import VirtSubproc
import adtlog
capabilities = [
'revert',
'revert-full-system',
'root-on-testbed',
]
args = None
container_name = None
normal_user = None
container_properties: Dict[str, str] = {}
def parse_args():
global args
parser = argparse.ArgumentParser()
parser.add_argument('-d', '--debug', action='store_true',
help='Enable debugging output')
parser.add_argument('-r', '--gain-root', metavar='COMMAND',
help='can become root by prefixing commands with
COMMAND')
parser.add_argument('image', help='nspawn ostree name from under
/var/lib/machines/')
parser.add_argument('nspawnargs', nargs=argparse.REMAINDER,
help='Additional arguments to pass to systemd-nspawn')
args = parser.parse_args()
if args.debug:
adtlog.verbosity = 2
def get_available_container_name():
'''Return a container name that isn't already taken'''
return str(uuid.uuid4())
def determine_normal_user():
'''Check for a normal user to run tests as.'''
global capabilities, normal_user
# get the first UID in the Debian Policy §9.2.2 "dynamically allocated
# user account" range
cmd = []
if args.gain_root:
cmd += shlex.split(args.gain_root)
cmd += ['systemd-run', '--quiet', f'--machine={container_name}', '--',
'sh', '-c',
'getent passwd | sort -t: -nk3 | '
"awk -F: '{if ($3 >= 1000 && $3 <= 5) { print $1; exit } }'"]
out = VirtSubproc.execute_timeout(None, 10, cmd,
stdout=subprocess.PIPE)[1].strip()
if out:
normal_user = out
capabilities.append('suggested-normal-user=' + normal_user)
adtlog.debug('determine_normal_user: got user "%s"' % normal_user)
else:
adtlog.debug('determine_normal_user: no uid in [1000,5] available')
def stop_container():
"""
Stop the running container
"""
cmd = []
if args.gain_root:
cmd += shlex.split(args.gain_root)
cmd += ["machinectl", "terminate", container_name]
VirtSubproc.execute_timeout(None, 300, cmd)
# We cannot run this code because we are likely not root ourselves.
# Consider execing ourselves with the gain_root command instead of
# prepending it to all systemd-run commands
#
# # See https://github.com/systemd/systemd/issues/6458
# leader_pid = int(container_properties["Leader"])
# os.kill(leader_pid, signal.SIGRTMIN + 4)
# while True:
# try:
# os.kill(leader_pid, 0)
# except OSError as e:
# if e.errno == errno.ESRCH:
# break
# raise
# time.sleep(0.1)
def hook_open():
global args, container_name, capa
Bug#1024764: ITP: python-hdf5plugin -- Python library to make HDF5 compression filters usable from h5py
Package: wnpp Severity: wishlist Owner: Enrico Zini X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: python-hdf5plugin Version : 3.3.1 Upstream Author : "ESRF - Data Analysis Unit" * URL : https://github.com/silx-kit/hdf5plugin * License : MIT Programming Lang: C/Python Description : Python library to make HDF5 compression filters usable from h5py hdf5plugin provides HDF5 compression filters (namely: blosc, bitshuffle, lz4, FCIDECOMP, ZFP, zstd) and makes them usable from h5py. I am going to maintain this in the Debian Science Team group.
Bug#1024367: In 4.9.1, the example uses not recommended install -s
Package: debian-policy Version: 4.6.1.1 Severity: normal Hello, and thank you for maintaining the Policy! Policy paragraph 4.9.1 has an example debian/rules which contains these lines: INSTALL_PROGRAM = $(INSTALL) -p-o root -g root -m 755 ifeq (,$(filter nostrip,$(DEB_BUILD_OPTIONS))) INSTALL_PROGRAM += -s endif However, paragraph 10.1 recommends against it: It is not recommended to strip binaries by passing the "-s" flag to "install", because this fails to remove .comment and .note sections, and also prevents the automatic creation of dbgsym binary packages by tools like "dh_strip". I would personally prefer if the example built on debhelper. If the intention is to show what are the expectations at a lower level then I wish the example had a comment saying "This snippet serves to explain what are the expectations as a lower level. You usually want to use debhelper instead" Enrico -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 6.0.0-2-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), LANGUAGE=en_IE:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled debian-policy depends on no packages. Versions of packages debian-policy recommends: ii libjs-sphinxdoc 4.5.0-4 Versions of packages debian-policy suggests: ii doc-base 0.11.1 -- no debconf information
Bug#1024358: ITP: h5z-zfp -- Compression plugin for the HDF5 library using ZFP compression
Package: wnpp Severity: wishlist Owner: Enrico Zini X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: h5z-zfp Version : 1.1.0 Upstream Author : Mark C. Miller * URL : https://github.com/LLNL/H5Z-ZFP * License : BSD Programming Lang: C Description : Compression plugin for the HDF5 library using ZFP compression H5Z-ZFP is a compression filter for HDF5 using the ZFP compression library, supporting lossy and lossless compression of floating point and integer data to meet bitrate, accuracy, and/or precision targets. I'm going to maintain this package in the Debian Science Team salsa namespace.
Bug#1023922: dpkg-checkbuilddeps: please add an option to print the list of packages
On Sat, Nov 12, 2022 at 09:30:43PM +0100, Guillem Jover wrote: > There was a bug filed requesting adding custom output format support > (#214566) but it was closed “recently”. I think there might be some > value in that, but not for the intended use the submitters seemed > to want it. > > I'd be interested to know how you'd want to use this new output/option > as from the PoC script you provide it is not obvious to me, as it > prints both build-depends and build-conflicts in an indistinguishable > way, and it includes version constraints and alternative dependencies. My specific use case at the moment is setting up a container *description* (not a container) with all the dependencies I need to do development on a package[1]. I could run apt-get build-dep inside the container and get the development environment installed, but then I lose the ability of being able to describe it in a terse way, and I can only do something along the lines of listing all installed packages in the container and their versions, which is too noisy for an average bug report. The way I chopped dpkg-checkbuilddeps was a first approximation. Given that now we have `apt-get satisfy`, my next step would be to have my hacked version print a list of arguments for it, which can include "Conflicts:", but which can already be preprocessed to reduce some noise like packages required or not required from the target architecture. More generally, I'd like Debian to have, as a standard, something similar to `rpmspec --parse filename.spec | grep BuildRequires` because I see it reimplemented so many times (pbuilder, sbuild, and so on) that my instincts screams invoking the rule of three and refactor[2]. Enrico [1] some background context can be found in https://github.com/ARPA-SIMC/moncic-ci/issues/74 although I'm expanding on that, see for example https://github.com/ARPA-SIMC/moncic-ci/issues/77 [2] https://en.wikipedia.org/wiki/Rule_of_three_(computer_programming) -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini signature.asc Description: PGP signature
Bug#1023922: dpkg-checkbuilddeps: please add an option to print the list of packages
Package: dpkg-dev
Version: 1.21.9
Severity: wishlist
Hello,
thank you for maintaining dpkg!
I often find myself[1] in need of a tool that, given a source package,
prints a list of its build depends, given an architecture, a build
profile, and so on.
dpkg-checkbuilddeps does internally generate it, and then only print the
list of packages not currently installed.
Would it be possible to add a way to print the unfiltered list?
I've made something that does it by chopping away the filtering bits
from dpkg-checkbuilddeps (see attachment).
Ideally, it can become a --print-depends/--print-conflicts option to
dpkg-checkbuilddeps, instead of a separate tool. Unfortunately my
perl-foo is too rusty to pretend I could propose a competent patch :/
Enrico
[1] and I'm apparently in good company, considering how many times this
is reimplemented in various places in Debian
-- Package-specific info:
This system uses merged-usr-via-aliased-dirs, going behind dpkg's
back, breaking its core assumptions. This can cause silent file
overwrites and disappearances, and its general tools misbehavior.
See <https://wiki.debian.org/Teams/Dpkg/FAQ#broken-usrmerge>.
-- System Information:
Debian Release: bookworm/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 6.0.0-2-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8),
LANGUAGE=en_IE:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages dpkg-dev depends on:
ii binutils 2.39-8
ii bzip2 1.0.8-5+b1
ii libdpkg-perl 1.21.9
ii make 4.3-4.1
ii patch 2.7.6-7
ii perl 5.36.0-4
ii tar 1.34+dfsg-1
ii xz-utils 5.2.7-0.1
Versions of packages dpkg-dev recommends:
ii build-essential 12.9
ii clang-14 [c-compiler]1:14.0.6-2
ii fakeroot 1.29-1
ii gcc [c-compiler] 4:12.2.0-1
ii gcc-10 [c-compiler] 10.4.0-5
ii gcc-12 [c-compiler] 12.2.0-9
ii gnupg2.2.40-1
ii gpgv 2.2.40-1
ii libalgorithm-merge-perl 0.08-5
Versions of packages dpkg-dev suggests:
ii debian-keyring 2022.08.11
-- no debconf information
#!/usr/bin/perl
#
# dpkg-checkbuilddeps
#
# Copyright © 2001 Joey Hess
# Copyright © 2006-2009, 2011-2015 Guillem Jover
# Copyright © 2007-2011 Raphael Hertzog
# Copyright © 2022 Enrico Zini
#
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program. If not, see <https://www.gnu.org/licenses/>.
use strict;
use warnings;
use Getopt::Long qw(:config posix_default bundling_values no_ignorecase);
use Dpkg ();
use Dpkg::Gettext;
use Dpkg::ErrorHandling;
use Dpkg::Arch qw(get_host_arch);
use Dpkg::Vendor qw(run_vendor_hook);
use Dpkg::BuildProfiles qw(get_build_profiles set_build_profiles);
use Dpkg::Deps;
use Dpkg::Control::Info;
textdomain('dpkg-dev');
sub version()
{
printf g_("Debian %s version %s.\n"), $Dpkg::PROGNAME, $Dpkg::PROGVERSION;
}
sub usage {
printf g_(
'Usage: %s [...] []')
. "\n\n" . g_(
'Options:
-A ignore Build-Depends-Arch and Build-Conflicts-Arch.
-B ignore Build-Depends-Indep and Build-Conflicts-Indep.
-I ignore built-in build dependencies and conflicts.
-d build-deps use given string as build dependencies instead of
retrieving them from control file
-c build-conf use given string for build conflicts instead of
retrieving them from control file
-a archassume given host architecture
-P profilesassume given build profiles (comma-separated list)
--admindir=
change the administrative directory.
-?, --help show this help message.
--version show the version.')
. "\n\n" . g_(
' is the control file to process (default: debian/control).')
. "\n", $Dpkg::PROGNAME;
}
my $ignore_bd_arch = 0;
my $ignore_bd_indep = 0;
my $ignore_bd_builtin = 0;
my ($bd_value, $bc_value);
my $bp_value;
my $host_arch = get_host_arch();
my $admindir = $Dpkg::ADMINDIR;
my @options_spec = (
'help|?' => sub { usage(); exit(0); },
'version' => sub { version(); exit 0; },
'A' => \$ignore_bd_arch,
'B' => \$ignore_bd_indep,
'I' => \$ignore_bd_builtin,
'd=s' => \$bd_value,
'c=s' => \$bc_value,
'a=s
Bug#908853: Source of popups is needrestart
Control: reassign -1 needrestart Hello, after noticing that I did not have needrestart-session installed, it turns out that the source of the popups is in needrestart at needrestart/ex/notify.d/400-notify-send I'm reassigning the bug accordingly Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini
Bug#908853: needrestart-session: Produces multiple windows with duplicate information
Control: severity -1 important On Thu, May 14, 2020 at 10:15:18AM +0200, Enrico Zini wrote: > Screenshot attached, for laugh and desperation purposes. I needed to > click on each and every single one of them, and the top right > notification box is the level boss: it's actually a stack of > notification boxes, which takes several clicks to go away. On a sid or testing distribution with unattended upgrades running, this renders the desktop session completely unusable for minutes. Additionally, the popups don't mention what software is generating them, so it's really hard to figure out how to stop them. Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini
Bug#1023821: Compile with -DZFP_BIT_STREAM_WORD_SIZE=8 ?
Source: zfp Version: 1.0.0-2 Severity: normal Hello, and thanks for packaging zfp! I've been trying to build hdf5-zfp[1] in Debian, and it requires[2] zfp to be built with BIT_STREAM_WORD_SIZE=8. Indeed, while CMakeLists.txt defaults it to 64, the FAQ recommends setting it to 8 to have portable files[3]. I did verify that after adding -DZFP_BIT_STREAM_WORD_SIZE=8 to dh_auto_configure in zfp's debian/rules and rebuilding the package, tests for hdf5-zfp pass. Would it make sense to change the default to 8? Enrico [1] https://github.com/LLNL/H5Z-ZFP [2] https://github.com/LLNL/H5Z-ZFP/blob/master/src/H5Zzfp.c#L155 [3] https://github.com/LLNL/zfp/blob/develop/docs/source/faq.rst?plain=1#L391 -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 6.0.0-2-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), LANGUAGE=en_IE:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#481845: Workaround script
Hello,
this issue is sadly still a problem.
For those who may hit the same troublesome spot, I'm attaching the
script I'm using as a replacement, which is a lot less flexible (or one
could say, has a lot of hardcodable flexibility), but has a very low
memory footprint
Enrico
--
GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini
#!/usr/bin/python3
import argparse
from collections import defaultdict
import datetime
import mailbox
import sys
def main():
today = datetime.date.today()
this_month = today.replace(day=1)
parser = argparse.ArgumentParser(description="Make monthly archives of
maildir contents")
parser.add_argument("--until", action="store",
default=this_month.strftime("%Y-%m"),
help="stop archiving before this month")
parser.add_argument("maildir", action="store", help="maildir to archive")
args = parser.parse_args()
until = datetime.datetime.strptime(args.until, "%Y-%m").date()
src = mailbox.Maildir(args.maildir)
by_month = defaultdict(list)
for key in src.keys():
dt = datetime.datetime.fromtimestamp(int(key.split('.')[0])).date()
if dt >= until:
continue
by_month[dt.strftime("%Y-%m")].append(key)
for month, keys in sorted(by_month.items()):
dst = mailbox.mbox(args.maildir + "-" + month)
try:
dst.lock()
for key in keys:
email = src[key]
dst.add(email)
finally:
dst.flush()
dst.unlock()
dst.close()
for key in keys:
del src[key]
print(month, len(keys))
return
if __name__ == "__main__":
sys.exit(main())
signature.asc
Description: PGP signature
Bug#1014908: ITP: gender-guesser -- Guess the gender from first name
On Thu, Jul 14, 2022 at 12:43:16PM +0100, Edward Betts wrote: > I've been writing some code to work out the gender balance of speakers at a > conference. It parses the pentabarf XML of the schedule and feeds the speaker > names to this module. > > Here's the results for Debconf 22. > > 72 speakers > > male 48 66.7% > unknown 16 22.2% > female 45.6% > mostly_male22.8% > andy 11.4% > mostly_female 11.4% If the library works as the author intended, it will identify "Enrico" as male, which is a gender *I* don't identify with. This kind of extends to anything related to a person's identity: any software trying to determine an aspect of a person's identity is bound to eventually conflict with how a person lives their own identity. That conflict can be quite painful, so it's not surprising you get strong reactions when intending to package something that pretends to tell people what a person is, without asking them first. This external determination of identity will then extend to the library to any software or research using it. I totally understand the good intentions, but the result honestly amplifies the pain. I think the right way to get the statistics you're looking for would be to ask speakers to state their own identity on pentabarf, so that statistics are based on self-determination, rather than external overrides of it. Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini signature.asc Description: PGP signature
Bug#1008022: keepass2: CVE-2022-0725 information disclosure
On Fri, Jun 24, 2022 at 05:16:41PM +0200, Enrico Zini wrote: > I failed to reproduce this on Gnome on a freshly installed buster > system. > > I failed to reproduce this on Gnome on a freshly installed bullseye > system with wayland. I also failed to reproduce this on a freshly installed stretch system, both on an X11 and on a Wayland session Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini signature.asc Description: PGP signature
Bug#1008022: keepass2: CVE-2022-0725 information disclosure
On Sun, Mar 20, 2022 at 06:16:41PM +0100, Markus Koschany wrote: > Steps to reproduce the problem (according > to https://bugzilla.redhat.com/show_bug.cgi?id=2052696) > > Step 1: Run "journalctl -f" in a terminal window. > Step 2: Double click a password in KeePass. > Step 3: Wait for the clear timeout to trigger. > > Actual results: > See your plain text password logged in the terminal window > > Expected results: > Never see your plain text password logged anywhere > > Only users in the systemd-journal group can use journalctl. At the moment I > can't reproduce the problem on a custom XFCE system but I have not tried GNOME > or other desktop environments yet and I suspect this problem is not limited to > RedHat or Fedora. I failed to reproduce this on Gnome on a freshly installed buster system. I failed to reproduce this on Gnome on a freshly installed bullseye system with wayland. Also on bullseye: - I tried to install all the clipboard managers I could find in apt (clipit clipman copyq diodon gnome-shell-extension-gpaste parcellite qlipper xsel) and I still couldn't reproduce. - I ran keepass2 in a terminal, and it did not produce output. - I ran keepass2 from Gnome Shell, and I keep seeing nothing in logs. In RedHat's bugzilla at https://bugzilla.redhat.com/show_bug.cgi?id=2053688 they also failed to reproduce it. At this point, the only reproducers are in the two threads in the keepass discussion forum. In https://sourceforge.net/p/keepass/discussion/329220/thread/da7546b7e1/ Paul tried to reproduce it, too, and also failed. At this point I would suspect that something else was at play in the users' systems, independent from keepass2. Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini signature.asc Description: PGP signature
Bug#1010355: Fwd: Bug#1010355: CVE-2022-0530: null pointer dereference on invalid UTF-8 input
On Tue, Jun 14, 2022 at 07:06:37PM +0200, Santiago Vila wrote:
> But the github repository containing the test cases, namely this:
> https://github.com/ByteHackr/unzip_poc
> contains a test case for yet another problem called CVE-2022-0529
> which I would like to fix as well.
Hello Steven and Santiago,
I'm attaching a proposed patch to fix CVE-2022-0529.
Enrico
--
GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini
diff --git a/process.c b/process.c
index d2a846e..99b9c7b 100644
--- a/process.c
+++ b/process.c
@@ -2507,13 +2507,15 @@ char *wide_to_local_string(wide_string, escape_all)
char buf[9];
char *buffer = NULL;
char *local_string = NULL;
+ size_t buffer_size;
for (wsize = 0; wide_string[wsize]; wsize++) ;
if (max_bytes < MAX_ESCAPE_BYTES)
max_bytes = MAX_ESCAPE_BYTES;
- if ((buffer = (char *)malloc(wsize * max_bytes + 1)) == NULL) {
+ buffer_size = wsize * max_bytes + 1;
+ if ((buffer = (char *)malloc(buffer_size)) == NULL) {
return NULL;
}
@@ -2552,7 +2554,11 @@ char *wide_to_local_string(wide_string, escape_all)
/* no MB for this wide */
/* use escape for wide character */
char *escape_string = wide_to_escape_string(wide_string[i]);
-strcat(buffer, escape_string);
+size_t buffer_len = strlen(buffer);
+size_t escape_string_len = strlen(escape_string);
+if (buffer_len + escape_string_len + 1 > buffer_size)
+ escape_string_len = buffer_size - buffer_len - 1;
+strncat(buffer, escape_string, escape_string_len);
free(escape_string);
}
}
signature.asc
Description: PGP signature
Bug#1012561: Purging the package does not remove configuration in /usr/share/qtcreator/QtProject
Package: qtcreator Version: 4.14.1-1 Severity: normal Hello, if one uses sdktool to programmatically configure parts of QT Creator[1], the resulting configuration is saved in /usr/share/qtcreator/QtProject However, dpkg --purge qtcreator, which should also remove its configuration, does not remove that directory, which is then left as cruft in the filesystem, and found by a following reinstall of Qt Creator. I suppose adding a `rm -rf /usr/share/qtcreator/QtProject` of that directory in postinst is all that's required to fix this Thank you, Enrico [1] see for example https://embeddeduse.com/2020/11/21/cross-compiling-qt-embedded-applications-with-qtcreator-and-cmake/ and https://code.qt.io/cgit/yocto/meta-boot2qt.git/tree/meta-boot2qt/files/configure-qtcreator.sh -- System Information: Debian Release: 11.3 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-14-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_WARN Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), LANGUAGE=en_IE:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages qtcreator depends on: ii clang-11 1:11.0.1-2 ii libc6 2.31-13+deb11u3 ii libclang1-11 1:11.0.1-2 ii libdw1 0.183-1 ii libelf10.183-1 ii libgcc-s1 10.2.1-6 ii libkf5syntaxhighlighting5 5.78.0-2 ii libqt5concurrent5 5.15.2+dfsg-9 ii libqt5core5a [qtbase-abi-5-15-2] 5.15.2+dfsg-9 ii libqt5designer55.15.2-5 ii libqt5designercomponents5 5.15.2-5 ii libqt5gui5 5.15.2+dfsg-9 ii libqt5help55.15.2-5 ii libqt5network5 5.15.2+dfsg-9 ii libqt5printsupport55.15.2+dfsg-9 ii libqt5qml5 [qtdeclarative-abi-5-15-2] 5.15.2+dfsg-6 ii libqt5quick5 5.15.2+dfsg-6 ii libqt5quickwidgets55.15.2+dfsg-6 ii libqt5serialport5 5.15.2-2 ii libqt5sql5 5.15.2+dfsg-9 ii libqt5sql5-sqlite 5.15.2+dfsg-9 ii libqt5svg5 5.15.2-3 ii libqt5widgets5 5.15.2+dfsg-9 ii libqt5xml5 5.15.2+dfsg-9 ii libstdc++6 10.2.1-6 ii libyaml-cpp0.6 0.6.3-9 ii libzstd1 1.4.8+dfsg-2.1 ii qml-module-qtqml-models2 5.15.2+dfsg-6 ii qml-module-qtquick-controls5.15.2-2 ii qml-module-qtquick25.15.2+dfsg-6 ii qtchooser 66-2 ii qtcreator-data 4.14.1-1 Versions of packages qtcreator recommends: ii clang-tidy1:11.0-51+nmu5 ii gdb 10.1-1.7 ii gnome-terminal [x-terminal-emulator] 3.38.3-1 ii make 4.3-4.1 ii qmlscene 5.15.2+dfsg-6 ii qt5-doc 5.15.2-2 ii qt5-qmltooling-plugins5.15.2+dfsg-6 ii qtbase5-dev-tools 5.15.2+dfsg-9 ii qtcreator-doc 4.14.1-1 ii qtdeclarative5-dev-tools 5.15.2+dfsg-6 ii qttools5-dev-tools5.15.2-5 ii qttranslations5-l10n 5.15.2-2 ii qtxmlpatterns5-dev-tools 5.15.2-3 Versions of packages qtcreator suggests: pn clazy ii cmake 3.18.4-2+deb11u1 ii g++ 4:10.2.1-1 ii git 1:2.30.2-1 ii meson 0.56.2-1 ii subversion 1.14.1-3+deb11u1 ii valgrind1:3.16.1-1 -- no debconf information
Bug#1010559: Security updates don't need to have urgency=high
Package: developers-reference Version: 11.0.21 Severity: normal Tags: patch Hello, in this thread[1] it turned out that security updates don't need to have urgency=high, so I'm attaching a patch that removes the mention. [1] https://lists.debian.org/debian-lts/2022/05/msg7.html Thanks, Enrico -- System Information: Debian Release: 11.3 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-13-amd64 (SMP w/4 CPU threads) Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), LANGUAGE=en_IE:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled developers-reference depends on no packages. Versions of packages developers-reference recommends: ii debian-policy4.5.1.0 ii libjs-sphinxdoc 3.4.3-2 ii sensible-utils 0.0.14 Versions of packages developers-reference suggests: ii chromium [www-browser] 101.0.4951.41-1~deb11u1 ii doc-base 0.11.1 ii firefox-esr [www-browser] 91.8.0esr-1~deb11u1 ii w3m [www-browser] 0.5.3+git20210102-6 -- no debconf information >From 9a80bb88199118bff99caa7278fffcb93dee430a Mon Sep 17 00:00:00 2001 From: Enrico Zini Date: Wed, 4 May 2022 13:23:28 +0200 Subject: [PATCH] Remove requirement that security uploads have urgency=high It seems that this is obsolete and not relevant anymore. Details are in this thread: https://lists.debian.org/debian-lts/2022/05/msg7.html --- source/pkgs.rst | 2 -- 1 file changed, 2 deletions(-) diff --git a/source/pkgs.rst b/source/pkgs.rst index 8665f99..1689fda 100644 --- a/source/pkgs.rst +++ b/source/pkgs.rst @@ -949,8 +949,6 @@ Be sure to verify the following items: |codename-security| (e.g. |codename-stable-security|). Do not target *distribution*\ ``-proposed-updates`` or ``stable``! -- The upload should have **urgency=high**. - - Make descriptive, meaningful changelog entries. Others will rely on them to determine whether a particular bug was fixed. Add ``closes:`` statements for any **Debian bugs** filed. Always include an external -- 2.30.2
Bug#1010355: CVE-2022-0530: null pointer dereference on invalid UTF-8 input
notfixed 6.0-26 Correction: the issue also affects 6.0-26, but is only reproducible after export LANG=C Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini
Bug#1010355: CVE-2022-0530: null pointer dereference on invalid UTF-8 input
Package: unzip
Version: 6.0-21+deb9u2
Severity: serious
Tags: security upstream patch
X-Debbugs-Cc: Debian Security Team
Fixed: 6.0-26
Hello,
details are at https://security-tracker.debian.org/tracker/CVE-2022-0530
stretch and buster segfault:
$ unzip testcase-0530
Archive: testcase-0530
warning [testcase-0530]: 16 extra bytes at beginning or within zipfile
(attempting to process anyway)
error [testcase-0530]: reported length of central directory is
-16 bytes too long (Atari STZip zipfile? J.H.Holm ZIPSPLIT 1.1
zipfile?). Compensating...
error: zipfile probably corrupt (segmentation violation)
bullseye errors out without valgrind issues reported:
$ unzip testcase-0530
Archive: testcase-0530
warning [testcase-0530]: 16 extra bytes at beginning or within zipfile
(attempting to process anyway)
error [testcase-0530]: reported length of central directory is
-16 bytes too long (Atari STZip zipfile? J.H.Holm ZIPSPLIT 1.1
zipfile?). Compensating...
mp/zip-unzip-0/7/source/workdir/��6a9f01ad36a4ac3b68815bf6f83b3ff_inpu㉴�瑥:
mismatching "local" filename
(mp/zip-unzip-0/7/source/workdir/��6a9f01ad36a4ac3b6881PK^G^HQ�V�^Q),
continuing with "central" filename version
skipping:
mp/zip-unzip-0/7/source/workdir/��6a9f01ad36a4ac3b68815bf6f83b3ff_inpu㉴�瑥
unable to get password
The main issue here seems to be at utf8_to_local_string, defined in
process.c:2606, which doesn't check the result of utf8_to_wide_string
for a NULL value.
I'm attaching a proposed patch that adds the missing error handling.
Enrico
-- System Information:
Debian Release: 11.3
APT prefers stable-security
APT policy: (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 5.10.0-13-amd64 (SMP w/4 CPU threads)
Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8),
LANGUAGE=en_IE:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages unzip depends on:
ii libbz2-1.0 1.0.8-4
ii libc6 2.31-13+deb11u3
unzip recommends no packages.
Versions of packages unzip suggests:
ii zip 3.0-12
-- no debconf information
diff --git a/fileio.c b/fileio.c
index 6290824..77e4b5f 100644
--- a/fileio.c
+++ b/fileio.c
@@ -2361,6 +2361,9 @@ int do_string(__G__ length, option) /* return PK-type
error code */
/* convert UTF-8 to local character set */
fn = utf8_to_local_string(G.unipath_filename,
G.unicode_escape_all);
+ if (fn == NULL)
+return PK_ERR;
+
/* make sure filename is short enough */
if (strlen(fn) >= FILNAMSIZ) {
fn[FILNAMSIZ - 1] = '\0';
diff --git a/process.c b/process.c
index d2a846e..715bc0f 100644
--- a/process.c
+++ b/process.c
@@ -2605,6 +2605,8 @@ char *utf8_to_local_string(utf8_string, escape_all)
int escape_all;
{
zwchar *wide = utf8_to_wide_string(utf8_string);
+ if (wide == NULL)
+return NULL;
char *loc = wide_to_local_string(wide, escape_all);
free(wide);
return loc;
Bug#1008169: bootstrapping fedora34 or centos7 gives a system with an empty package database
On Thu, Mar 24, 2022 at 12:52:24AM +, Luca Boccassi wrote: > Have you checked if the --clean-package-metadata= option is the cause? > >CleanPackageMetadata=, --clean-package-metadata= > Enable/disable removal of package manager databases, caches, > and logs at the end of installation. > Can be specified as true, false, or “auto” (the default). > With “auto”, files will be removed if the > respective package manager executable is not present at the end > of the installation. I just tried, and that does not seem to be the cause: $ sudo /usr/bin/mkosi --distribution=fedora --release=34 --format=directory --output=target --base-packages=true --package=bash,rootfiles,dbus,dnf --clean-package-metadata=false … $ sudo systemd-nspawn --volatile -D target Spawning container target on /home/enrico/lavori/arpa/moncic-ci/target. Press ^] three times within 1s to kill container. -bash-5.1# rpm -qa -bash-5.1# rpmdb --rebuilddb -bash-5.1# rpm -qa -bash-5.1# ls -la /var/lib/rpm total 240 drwxr-xr-x 2 0 0100 Mar 24 13:08 . drwxr-xr-x 3 0 0 60 Mar 24 13:08 .. -rw-r--r-- 1 0 0 212992 Mar 24 13:08 rpmdb.sqlite -rw-r--r-- 1 0 0 32768 Mar 24 13:08 rpmdb.sqlite-shm -rw-r--r-- 1 0 0 0 Mar 24 13:08 rpmdb.sqlite-wal -bash-5.1# Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini signature.asc Description: PGP signature
Bug#1008169: bootstrapping fedora34 or centos7 gives a system with an empty package database
Package: mkosi Version: 12-1~bpo11+1 Severity: important Hello, I tried with fedora34 and centos7, but it might be the same for all rpm-based distributions. To reproduce: sudo /usr/bin/mkosi --distribution=fedora --release=34 --format=directory --output=target --base-packages=true --package=bash,rootfiles,dbus,dnf or: sudo /usr/bin/mkosi --distribution=centos --release=7 --format=directory --output=target --base-packages=true --package=bash,rootfiles,dbus,yum Then: $ sudo systemd-nspawn --volatile -D target Spawning container target on /home/enrico/lavori/arpa/moncic-ci/target. Press ^] three times within 1s to kill container. -bash-5.1# rpm -qa -bash-5.1# rpmdb --rebuilddb -bash-5.1# rpm -qa -bash-5.1# This might be related to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1004863 and if that is the case, that issue also contains a workaround. Thank you, Enrico -- System Information: Debian Release: 11.2 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-10-amd64 (SMP w/4 CPU threads) Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), LANGUAGE=en_IE:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages mkosi depends on: ii btrfs-progs5.10.1-2 ii debootstrap1.0.123 ii dosfstools 4.2-1 ii e2fsprogs 1.46.2-2 ii fdisk 2.36.1-8+deb11u1 ii python33.9.2-3 ii systemd-container 247.3-6 ii util-linux 2.36.1-8+deb11u1 ii xz-utils 5.2.5-2 Versions of packages mkosi recommends: ii cryptsetup-bin 2:2.3.5-1 ii debian-archive-keyring 2021.1.1 ii gnupg 2.2.27-2 ii ovmf2020.11-2+deb11u1 ii python3-cryptography3.3.2-1 ii squashfs-tools 1:4.4-2+deb11u2 pn ubuntu-archive-keyring mkosi suggests no packages. -- no debconf information
Bug#1008054: Remove debian-es.org links from website
Package: www.debian.org Severity: normal Hello, it looks like the debian-es.org domain has expired and has been picked up by some cybersquatter. We have some links to it in the website, which should probably be removed. Thanks, Enrico
Bug#1006958: RFP: pytype -- Pytype checks and infers types for your Python code
Package: wnpp
Severity: wishlist
* Package name: pytype
Version : 2022.3.8
Upstream Author : Google
* URL : https://google.github.io/pytype/
* License : Apache, with some code with BSD and MIT
Programming Lang: Python
Description : Pytype checks and infers types for your Python code
Pytype checks and infers types for your Python code - without
requiring type annotations. Pytype can:
* Lint plain Python code, flagging common mistakes such as misspelled
attribute names, incorrect function calls, and much more, even
across file boundaries.
* Enforce user-provided type annotations. While annotations are
optional for pytype, it will check and apply them where present.
* Generate type annotations in standalone files ("pyi files"), which
can be merged back into the Python source with a provided merge-pyi
tool.
Pytype is a static analyzer; it does not execute the code it runs on.
It seems like a great help in Python development. It has a different
approach than mypy, and would complement it quite nicely.
Bug#1006470: RFP: dduper -- Fast block-level out-of-band BTRFS deduplication tool.
Package: wnpp Severity: wishlist * Package name: dduper Version : 0.04 Upstream Author : Lakshmipathi * URL : https://github.com/lakshmipathi/dduper * License : GPL-2+ Programming Lang: Python Description : Fast block-level out-of-band BTRFS deduplication tool. dduper is a block-level out-of-band BTRFS dedupe tool. This works by fetching built-in checksum from BTRFS csum-tree, instead of reading file blocks and computing checksum itself. This hugely improves the performance. This seems the fastest and most lightweight deduplication tool for BTRFS made so far.
Bug#1004863: Bootstrapping a Fedora produces a system with an empty package database
On Sat, Feb 12, 2022 at 08:51:01PM +0100, Enrico Zini wrote: > That's even better, then: it becomes a matter of documenting the > procedure to bootstrap an rpm-based distro from Debian: I can test it > and produce a draft HOWTO. I tested, and I confirm that this works: dnf -c "$CONFFILE" -y --disablerepo=* --enablerepo=chroot-base --disableplugin=* \ --installroot="$DESTDIR" --releasever="$VERSION" install if [ -d "$DESTDIR/root/.rpmdb" ]; then rm -rf "$DESTDIR/var/lib/rpm" mv "$DESTDIR/root/.rpmdb" "$DESTDIR/var/lib/rpm" systemd-nspawn -D "$DESTDIR" -- /usr/bin/rpmdb --rebuilddb fi I wonder where would be the right place to document this. README.Debian maybe? Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini signature.asc Description: PGP signature
Bug#1004863: Bootstrapping a Fedora produces a system with an empty package database
On Sat, Feb 12, 2022 at 06:51:26PM +0100, Mihai Moldovan wrote: > I can offer a workaround, though: the installing user (probably root?) should > have an .rpmdb directory in its home directory. After creating the initial > chroot, IN THE CHROOT, move this directory (/root/.rpmdb, if I remember > correctly) to /var/lib/rpm and execute /usr/bin/rpmdb --rebuilddb. Afterwards, > all installed packages should be accounted for in the chroot. That's even better, then: it becomes a matter of documenting the procedure to bootstrap an rpm-based distro from Debian: I can test it and produce a draft HOWTO. Does this mean that boostrapping one rpm-based distro on another one (like, bootstrapping a fedora34 on a fedora32 system) would require the same workaround? > I apologize for the mess, but accounting for the already-broken RPM package > was > all I could do for the initial packaging of DNF. I don't think there's anything to apologise for, and thanks for taking care of these packages! I wonder if I've just made a 1:1 conceptual mapping between debootstrap and this feature of dnf, and set expectations for the tool that the tool isn't intended to provide for. Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini signature.asc Description: PGP signature
Bug#1004863: Bootstrapping a Fedora produces a system with an empty package database
On Fri, Feb 11, 2022 at 06:38:16AM +0100, Mihai Moldovan wrote: > While Debian's rpm utility uses a homedir-based RPMDB, nothing else, > especially > not Fedora, expects that and, since dnf uses the system-version of RPM to > bootstrap, you'll run into exactly such issues. > > I can't do anything about that, other than try to NMU a version of RPM that > has > this patch removed, but that might break tools like alien and I'm not very > interested in spending a lot of time on that. On Fri, Feb 11, 2022 at 12:23:52PM +, Holger Levsen wrote: > However I've downgraded it to important as eg Qubes 4.1 uses dnf on Debian to > download upgrades for dom0, which is Fedora based. So the package is certainly > not unusable for everyone, thus downgrading severity... Fair enough: it might be just a matter of documenting that dnf cannot be used to boostrap an RPM-based distribution from a Debian system. Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini
Bug#1005290: Quirk in defining *-security mirrors
Package: aptly Version: 1.4.0+ds1-4+b4 Severity: normal Hello, thanks for maintaining aptly! I stumbled on a quirk setting up a mirror of bullseye-security. The standard apt line would be something like: deb https://deb.debian.org/debian-security bullseye-security main contrib non-free However, the same in aptly does not work: $ aptly mirror create security http://deb.debian.org/debian-security/ bullseye-security main contrib non-free Downloading http://deb.debian.org/debian-security/dists/bullseye-security/InRelease... gpgv: Signature made Thu 10 Feb 2022 12:21:47 CET using RSA key ID E562B32A gpgv: Good signature from "Debian Security Archive Automatic Signing Key (10/buster) " gpgv: Signature made Thu 10 Feb 2022 12:21:47 CET using RSA key ID BBB6E853 gpgv: Good signature from "Debian Security Archive Automatic Signing Key (11/bullseye) " ERROR: unable to fetch mirror: component main not available in repo [security]: http://deb.debian.org/debian-security/ bullseye-security, use -force-components to override It turns out that https://deb.debian.org/debian-security/dists/bullseye-security/InRelease defines the components as: Components: updates/main updates/contrib updates/non-free And aptly needs them to be spelled out exactly that way, so this works: $ aptly mirror create security http://deb.debian.org/debian-security/ bullseye-security updates/main updates/contrib updates/non-free It's rather surprising behaviour, and there's a working workaround, although I did not dig into the root cause to figure out why Components are defined that way, how apt makes it work, and what the consequences of the work around could be. Thanks, Enrico -- System Information: Debian Release: 11.2 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-10-amd64 (SMP w/4 CPU threads) Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), LANGUAGE=en_IE:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages aptly depends on: ii bzip2 1.0.8-4 ii gnupg 2.2.27-2 ii gpgv 2.2.27-2 ii libc6 2.31-13+deb11u2 ii xz-utils 5.2.5-2 aptly recommends no packages. Versions of packages aptly suggests: ii graphviz 2.42.2-5 -- no debconf information
Bug#1005289: Aptly does not support gpg version 2
Package: aptly Version: 1.4.0+ds1-4+b4 Severity: normal Hello, thank you for maintaining aptly! Trying to use aptly with keyrings generated with the current version of gpg fails with semi-obscure gpg errors: gpgv: Signature made Sat 18 Dec 2021 11:39:50 CET using RSA key ID 22F3D138 gpgv: [don't know]: invalid packet (ctb=00) gpgv: keydb_search failed: invalid packet gpgv: Can't check signature: public key not found This is mentioned in a couple of upstream bugs: * https://github.com/aptly-dev/aptly/issues/838 * https://github.com/aptly-dev/aptly/issues/822 Given that gpg2 is the default version of gpg in Debian, this invalidates, for example, following the tutorial at https://www.aptly.info/tutorial/mirror/ I would consider this not a problem of Debian and rather a problem of aptly, though. Thanks, Enrico -- System Information: Debian Release: 11.2 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-10-amd64 (SMP w/4 CPU threads) Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), LANGUAGE=en_IE:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages aptly depends on: ii bzip2 1.0.8-4 ii gnupg 2.2.27-2 ii gpgv 2.2.27-2 ii libc6 2.31-13+deb11u2 ii xz-utils 5.2.5-2 aptly recommends no packages. Versions of packages aptly suggests: ii graphviz 2.42.2-5 -- no debconf information
Bug#1004863: Bootstrapping a Fedora produces a system with an empty package database
Package: dnf Version: 4.5.2-6 Severity: serious Hello, thank you for packaging dnf in Debian! I'm trying to use dnf to bootstrap rpm-based chroots, which seems to work, but the rpm package database on the resulting distribution is empty, as in, `rpm -qa` returns no output, and `rpm -q` on any package complains that it is not installed. The actual files that are supposed to be in the package are indeed present in the chroot. I'm attaching outputs of the same command as run on my Debian Bullseye system and one I made on a Fedora 34 system. The output seems the same (sadly I had different terminal sizes which make diffing a bit awkward), but at the end, the outcome of rpm commands in the chroot differ. I'm assuming this is an issue of dnf as distributed in Debian, since the same command on Fedora works, but that is a guess from someone with no knowledge of dnf workings. Running `/usr/bin/rpmdb --rebuilddb` doesn't change the situation, and `rpm -qa` keeps returning empty output. Steps to reproduce: # mkdir test # cat > test.repo [chroot-base] name=Linux $releasever - $basearch baseurl=http://download.fedoraproject.org/pub/fedora/linux/releases/34/Everything/$basearch/os/ enabled=1 gpgcheck=0 # /usr/bin/dnf -c test.repo -y '--disablerepo=*' --enablerepo=chroot-base '--disableplugin=*' --installroot=$(readlink -f test) --releasever=34 install bash vim-minimal dnf rootfiles git dbus [...] Complete! # chroot test [root@host /]# rpm -qa [root@host /]# Thank you, Enrico -- System Information: Debian Release: 11.2 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-10-amd64 (SMP w/4 CPU threads) Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), LANGUAGE=en_IE:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages dnf depends on: ii dnf-data 4.5.2-6 ii libmodulemd2 2.12.0-1 ii python3 3.9.2-3 ii python3-dbus 1.2.16-5 ii python3-dnf 4.5.2-6 ii sqlite3 3.34.1-3 dnf recommends no packages. dnf suggests no packages. -- no debconf information dnf-on-fedora43.log.gz Description: application/gzip dnf-on-debian-bullseye.log.gz Description: application/gzip
Bug#1004387: Filed RFP #1004388
Hello, I filed the RFP at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1004388 Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini
Bug#1004388: RFP: python3-inotify -- An adapter to Linux kernel support for inotify directory-watching
Package: wnpp Severity: wishlist * Package name: python3-inotify Version : 0.2.10 Upstream Author : Dustin Oprea * URL : https://github.com/dsoprea/PyInotify * License : GPL-2 Programming Lang: Python Description : An adapter to Linux kernel support for inotify directory-watching inotify functionality is available from the Linux kernel and allows you to register one or more directories for watching, and to simply block and wait for notification events. This is obviously far more efficient than polling one or more directories to determine if anything has changed. This is available in the Linux kernel as of version 2.6 . . We've designed this library to act as a generator. All you have to do is loop, and you'll see one event at a time and block in-between. After each cycle (all notified events were processed, or no events were received), you'll get a None. You may use this as an opportunity to perform other tasks, if your application is being primarily driven by inotify events. By default, we'll only block for one-second on queries to the kernel. This may be set to something else by passing a seconds-value into the constructor as block_duration_s. There exist two upstream inotify libraries significant here: https://github.com/dsoprea/PyInotify Subject of this RFP: note that it contains a module called 'inotify', not 'pyinotify' https://github.com/seb-m/pyinotify Currently ppackaged as python3-pyinotify Looking at https://github.com/dsoprea/PyInotify it says: This project is unrelated to the *PyInotify* project that existed prior to this one (this project began in 2015). That project is defunct and no longer available. and indeed, https://github.com/seb-m/pyinotify which is listed as upstream of python3-pyinotify, seems to be stuck in 2015. To the best that I could see, https://github.com/dsoprea/PyInotify is not currently packaged in Debian. If I understand correctly, the only way to access inotify functionality in Python with libraries in Debian at the moment is via the old pyinotify, and at least gunicorn is requiring the newer one for inotify-based reloading to work: https://docs.gunicorn.org/en/stable/settings.html#reload "In order to use the inotify reloader, you must have the inotify package installed." I reported an issue to python3-pyinotify to track the upstream abandonment, and I'm filing this RFP for a replacement that would also fulfill gunicorn requirements to activate inotify-based features Enrico
Bug#1004387: Upstream seems abandoned
Package: python3-pyinotify Version: 0.9.6-1.3 Severity: serious Hello, thank you for maintaining python3-pyinotify. Looking at https://github.com/dsoprea/PyInotify it says: This project is unrelated to the *PyInotify* project that existed prior to this one (this project began in 2015). That project is defunct and no longer available. and indeed, https://github.com/seb-m/pyinotify which is listed as upstream of python3-pyinotify seems to be stuck in 2015. To the best that I could see, https://github.com/dsoprea/PyInotify is not packaged in Debian. If I understand correctly, the only way to access inotify functionality in Python with libraries in Debian at the moment is via the old pyinotify, and at least gunicorn is requiring the newer one for inotify-based reloading to work: https://docs.gunicorn.org/en/stable/settings.html#reload "In order to use the inotify reloader, you must have the inotify package installed." I guess my next step could be filing an RFP for https://github.com/dsoprea/PyInotify ? Enrico -- System Information: Debian Release: 11.2 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-10-amd64 (SMP w/4 CPU threads) Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), LANGUAGE=en_IE:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages python3-pyinotify depends on: ii python3 3.9.2-3 python3-pyinotify recommends no packages. Versions of packages python3-pyinotify suggests: pn python-pyinotify-doc -- no debconf information
Bug#998168: Area selection doesn't always erase the selection rectangle
Control: reassign -1 xfwm4
On Thu, Nov 11, 2021 at 10:23:19AM -0300, Eriberto Mota wrote:
> Em qui., 11 de nov. de 2021 às 10:15, Enrico Zini
> escreveu:
> >
> > Hi Eriberto,
> >
> > it looks like both the workarounds that you suggested are working
> > (window manager is xfwm4).
> >
> > I guess scrot did all it could to manage the situation, and I wonder if
> > the bug should just be closed or reassigned to xfwm4
>
> Thanks Enrico.
>
> This is a bit of a complicated decision because several WM have
> similar problems. Maybe it is a problem in an intermediate lib.
>
> I support any decision from you.
Ok, then I'll reassign this issue to xfwm4.
Dear xfwm4 maintainers, this seems to be an issue that crops up with
some but not all window managers.
I am unsure and unable to tell whether this is a documentation issue for
scrot ("use -f if you get selection artifacts" with your WM), or an
issue in the window manager, so I'd leave it to you to decide.
Feel free to close this if you do not consider it a window-manager
issue, and thank you for maintaining xfwm4!
Enrico
--
GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini
signature.asc
Description: PGP signature
Bug#998168: Area selection doesn't always erase the selection rectangle
On Wed, Nov 10, 2021 at 05:29:53PM -0300, Eriberto wrote: > Do you have any news? Hi Eriberto, it looks like both the workarounds that you suggested are working (window manager is xfwm4). I guess scrot did all it could to manage the situation, and I wonder if the bug should just be closed or reassigned to xfwm4 Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini signature.asc Description: PGP signature
Bug#997990: tornado worker does not work with Tornado 6
On Thu, Oct 28, 2021 at 05:21:05PM -, Chris Lamb wrote: > Thanks for filing #997990 and #997992 for issues in gunicorn. As it > happens, though, I am no longer using the Debian package of gunicorn > and, as such, I wonder if it makes more sense for someone else to take > over maintainership. At the very least, this will ensure that fixes > for these two issues can reliably tested. > > Would this new maintainer be, perhaps, you? :) Thank you for the offer. I'm afraid I can't pick it up, as I'm heavily struggling to look after my own packages as it is. I concluded that #997992 is not fixable, and I"m redesigning our tornado-related architecture to move away from gunicorn and towards something like https://unrouted.io/ops/2017/04/26/multicore-twistd-with-systemd/ As I'm moving away from using gunicorn to run tornado, it's quite unlikely I'll also be able to test a fix for #997990 besides rerunning the test cases I attached to the upstream bug. Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini
Bug#997992: Using --max-requests with tornado workers creates an chaotically unreliable server
Package: gunicorn Version: 20.1.0-1 Severity: important Hello, reproducing this on bullseye needs the workaround to #997990 as a prerequisite. I reported this upstream as https://github.com/benoitc/gunicorn/issues/2672 TL;DR: when using --max-requests and the maximum number of requests is reached *twice*, then a server ends even if there are active long-running requests. On a busy production server, this causes hard to reproduce unrealiability and generalized mayhem. I'm reporting the issue so other users may be aware of it. I haven't yet found a workaround, and I'll post it if I get to a decent one. Unfortunately, using Tornado's own multithreaded webserver I haven't yet found a way to make it exit and restart after a set number of requests, which given the kind of code that ends up being run in my use case, is a much needed feature to contain potential memory issues. Enrico -- System Information: Debian Release: 11.1 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-8-amd64 (SMP w/4 CPU threads) Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), LANGUAGE=en_IE:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages gunicorn depends on: ii python3 3.9.2-3 ii python3-gunicorn 20.1.0-1 gunicorn recommends no packages. Versions of packages gunicorn suggests: pn python3-pastedeploy ii python3-setproctitle 1.2.1-1+b1 ii python3-tornado 6.1.0-1+b1 -- no debconf information
Bug#997990: tornado worker does not work with Tornado 6
Package: gunicorn Version: 20.1.0-1 Severity: important Hello, thank you for maintaining gunicorn! Upstream alread has an issue about this at https://github.com/benoitc/gunicorn/issues/2630 The problem boils down to /usr/lib/python3/dist-packages/gunicorn/workers/gtornado.py:109 where on Tornado >= 6, the tornado application is always wrapped into a WSGIContainer, even if it is already an instance of tornado.web.Application. This is quite obviously not what the check intends to do: if tornado.version_info[0] < 6: if not isinstance(app, tornado.web.Application) or \ isinstance(app, tornado.wsgi.WSGIApplication): app = WSGIContainer(app) elif not isinstance(app, WSGIContainer): app = WSGIContainer(app) A workaround for the time being until the fix makes it from upstream to bullseye, is to: 1. make a local copy of /usr/lib/python3/dist-packages/gunicorn/workers/gtornado.py as, say, fixed_gtornado.py 2. apply this change to it: https://github.com/duanhongyi/gunicorn/commit/c7eacb74ebbb2461743e9706d57c2733e23fa6fd 3. run gunicorn using the runner in that fixed module: gunicorn --worker-class=fixed_gtornado.TornadoWorker Enrico -- System Information: Debian Release: 11.1 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-8-amd64 (SMP w/4 CPU threads) Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), LANGUAGE=en_IE:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages gunicorn depends on: ii python3 3.9.2-3 ii python3-gunicorn 20.1.0-1 gunicorn recommends no packages. Versions of packages gunicorn suggests: pn python3-pastedeploy ii python3-setproctitle 1.2.1-1+b1 ii python3-tornado 6.1.0-1+b1 -- no debconf information
Bug#996253: liburiparser does not contain a .a library file
Package: liburiparser-dev Version: 0.9.4+dfsg-1 Severity: wishlist Hello, thank you for packaging uriparser! liburiparser-dev does not ship a liburiparser.a: https://packages.debian.org/sid/amd64/liburiparser-dev/filelist I could not find out if it is accidental or intentional. Not having a .a makes it impossible to create statically linked executables that use urparser, which would be helpful for some deploy workflows. Would it be possible to have it? Thank you, Enrico -- System Information: Debian Release: 11.1 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-8-amd64 (SMP w/4 CPU threads) Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), LANGUAGE=en_IE:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages liburiparser-dev depends on: ii liburiparser1 0.9.4+dfsg-1 liburiparser-dev recommends no packages. liburiparser-dev suggests no packages. -- no debconf information
Bug#995808: The option is documented in --extended-help
Severity: normal I found that the option is documented in -H (--extended-help) instead of --help, and I can successfully use that to figure out what API is expected by wkhtmltopdf. I suppose, for such a common use case, that command line option shouldn't be hidden outside of the normal help, or the error message should mention the existance of --enable-local-file-access: it really looks like wkhtmltopdf is unable to render local files! Depending on sensitivities, the severity and validity of this bug may vary: I'll leave it up to you to decide whether to keep it open, and what its severity should be Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini
Bug#995808: --help does not mention required --enable-local-file-access
Package: wkhtmltopdf Version: 0.12.6-1 Severity: important Hello, Thank you for packaging wkhtmltopdf! wkhtmltopdf version 0.12.6 blocks by default access to local files (note the "Warning: Blocked access to file"): $ wkhtmltopdf test.html test.pdf Loading page (1/2) Warning: Blocked access to file Error: Failed to load about:blank, with network status code 301 and http status code 0 - Protocol "about" is unknown Printing pages (2/2) Done Exit with code 1 due to network error: ProtocolUnknownError Using --enable-local-file-access makes it work: $ wkhtmltopdf --enable-local-file-access test.html test.pdf Loading page (1/2) Printing pages (2/2) Done However, earlier version of wkhtmltopdf did not support --enable-local-file-access, and using it would cause it to error out complaining about usage of a non-existing option. A program calling wkhtmltopdf for rendering needs to figure out when --enable-local-file-access is needed and when it's harmful, here's an example use case: https://github.com/Truelite/python-a38/issues/6 To avoid needing to parse and compare --version output, I had opted to parse the output of --help: if the option was documented, then it was needed; if it was not documented, then it wasn't supported. The version of wkhtmltopdf currently in stable requires --enable-local-file-access but does not document it (!!) causing both a conundrum for users who get an error message and no documentation on the option that would fix it, and for software trying to figure out the effective CLI interface for manipulating wkhtmltopdf as a backend tool. Enrico -- System Information: Debian Release: 11.0 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-8-amd64 (SMP w/4 CPU threads) Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), LANGUAGE=en_IE:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages wkhtmltopdf depends on: ii libc62.31-13 ii libgcc-s110.2.1-6 ii libqt5core5a 5.15.2+dfsg-9 ii libqt5gui5 5.15.2+dfsg-9 ii libqt5network5 5.15.2+dfsg-9 ii libqt5printsupport5 5.15.2+dfsg-9 ii libqt5svg5 5.15.2-3 ii libqt5webkit55.212.0~alpha4-11 ii libqt5widgets5 5.15.2+dfsg-9 ii libstdc++6 10.2.1-6 Versions of packages wkhtmltopdf recommends: ii tigervnc-standalone-server [xserver] 1.11.0+dfsg-2 ii xserver-xephyr [xserver] 2:1.20.11-1 ii xserver-xorg [xserver]1:7.7+22 wkhtmltopdf suggests no packages. -- no debconf information
Bug#993111: /usr/share/javascript/popper.js is an empty directory
Package: libjs-popper.js Version: 1.16.1+ds-3 Severity: serious Hello, the assets of libjs-popper.js do not appear under /usr/share/javascript. The only thing that is packaged there is `popper.js` as an empty directory. This is currently breaking all software that loads popper.js assets from its packaged version (and by extension all software that uses bootstrap4 in the same way) Enrico -- System Information: Debian Release: 11.0 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-0.bpo.7-amd64 (SMP w/4 CPU threads) Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), LANGUAGE=en_IE:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libjs-popper.js depends on: ii javascript-common 11+nmu1 Versions of packages libjs-popper.js recommends: pn node-jquery libjs-popper.js suggests no packages. -- no debconf information
Bug#993020: Please make a backport for bullseye
Package: syncmaildir Version: 1.3.0-1 Severity: wishlist Hello, bullseye has been released and syncmaildir is not in it. If/once the issues that prevented it being part of a release have been fixed, can you please also make a backport for bullseye? Thanks, Enrico -- System Information: Debian Release: 11.0 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-0.bpo.7-amd64 (SMP w/4 CPU threads) Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), LANGUAGE=en_IE:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages syncmaildir depends on: ii libc6 2.31-13 ii libglib2.0-02.66.8-1 ii lua5.1 5.1.5-8.1+b3 ii openssh-client 1:8.4p1-5 ii xdelta 1.1.3-9.3 syncmaildir recommends no packages. syncmaildir suggests no packages. -- no debconf information
Bug#992975: Acknowledgement (Does not work on bullseye)
Severity: normal Hello, update/correction: the plugin still works with the usual vim-addon-manager Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini
Bug#992975: Does not work on bullseye
Package: vim-syntastic Version: 3.10.0-2 Severity: serious Hello, the upgrade instructions for bullseye say: * Before upgrading, run "vam remove " for any addon in this package that has been installed with "vam install ". Adjust the command as necessary for system-wide installed addon. * After upgrading, add "packadd! " to your vimrc for any addon that you want to use. The addon name can be found in the package description or the list of directories under /usr/share/vim-scripts. However, when I add `packadd! syntastic` in .vimrc, I get this error: E919: Directory not found in 'packpath': "pack/*/opt/syntastic" Using packadd! on, say, nerd-commenter (distributed by vim-scripts) works fine. It looks like vim-syntastic missed the update that vim-scripts had. /usr/share/doc/vim-syntastic/README.Debian doesn't mention anything relevant (and there's a typo where it says "pathogen" instead of "syntastic"). Unfortunately I don't know anything about vim plugin packaging and I can't be much of use, besides reporting the issue :( Enrico -- System Information: Debian Release: 11.0 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-0.bpo.7-amd64 (SMP w/4 CPU threads) Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), LANGUAGE=en_IE:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages vim-syntastic depends on: ii vim2:8.2.2434-3 ii vim-addon-manager 0.5.10 vim-syntastic recommends no packages. Versions of packages vim-syntastic suggests: pn checkstyle pn chktex pn closure-linter ii cppcheck 2.3-1 pn foodcritic pn hlint pn lacheck pn libperl-critic-perl ii libxml2-utils2.9.10+dfsg-6.7 pn pep8 pn puppet-lint pn pyflakes ii pylint 2.7.2-3 pn python-flake8 pn shellcheck pn sparse pn splint ii tidy 2:5.6.0-11 -- no debconf information
Bug#986357: Please improve package description
Package: sq Version: 0.25.0-1 Severity: normal Hello, thanks for packaging Sequoia. The package contains a user-facing tool, and the package description contains mostly redundant technical details about how the package is generated. Could you please update the description so that it explains what the sq command is supposed to do, so that one could use the description to see if it's a package that might do some of what they need? Enrico -- System Information: Debian Release: 10.8 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-0.bpo.3-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_WARN Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), LANGUAGE=en_IE:en (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#981352: "VPN Connections" menu entry moves around and is frustrating to click
On Tue, Mar 30, 2021 at 02:28:08PM +0200, Michael Biebl wrote: > Since this is not a Debian specific / integration issue, but is likely to > require a UI redesign, this really needs input from upstream. > > Can you raise this at https://gitlab.gnome.org/GNOME/network-manager-applet/ > please and report back with the issue number. Done: https://gitlab.gnome.org/GNOME/network-manager-applet/-/issues/130 I referenced #83, which covers indeed only part of the problem. Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini
Bug#985364: Aborted (core dumped) drawing a simple GRIB file
Package: python3-magics++ Version: 2:1.5.5-1 Severity: important Hello, thank you for maintaining Magics in Debian! I'm attaching a test case which causes Magics to abort on current bullseye: $ python3 magics-crash.py ecCodes assertion failed: `h' in ./src/grib_query.c:572 Aborted (core dumped) grib_dump seems to open the GRIB file just fine. Enrico -- System Information: Debian Release: 10.8 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-0.bpo.3-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_WARN Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), LANGUAGE=en_IE:en (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages python3-magics++ depends on: ii libmagplus3v5 3.3.1-1 ii python3 3.7.3-1 ii python3-jinja2 2.10-2 ii python3-numpy [python3-numpy-abi9] 1:1.16.2-1 ii python3-simplejson 3.16.0-1 python3-magics++ recommends no packages. python3-magics++ suggests no packages. -- no debconf information magics-crash.tar.xz Description: application/xz
Bug#985137: Segfault plotting wind data
Package: python3-magics++ Version: 3.3.1-1 Severity: important Hello, thank you for packaging Magics. In Debian stable, plotting wind data with Magics causes a segmentation fault. I'm attaching a test case and test data: $ python3 wflags-segfault.py Magics :-- Magics : Magics : Magics 3.3.1 (64 bit) Magics : Magics : Meteorological Applications Graphics Integrated Colour System Magics : Magics :Developed By Magics : Magics : The European Centre for Medium-Range Weather Forecasts Magics : Magics : Magics :-- Segmentation fault (core dumped) Enrico -- System Information: Debian Release: 10.8 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-0.bpo.3-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_WARN Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), LANGUAGE=en_IE:en (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages python3-magics++ depends on: ii libmagplus3v5 3.3.1-1 ii python3 3.7.3-1 ii python3-jinja2 2.10-2 ii python3-numpy [python3-numpy-abi9] 1:1.16.2-1 ii python3-simplejson 3.16.0-1 python3-magics++ recommends no packages. python3-magics++ suggests no packages. -- no debconf information wflags-segfault.tar.gz Description: application/gzip
Bug#981352: "VPN Connections" menu entry moves around and is frustrating to click
Package: network-manager-openvpn-gnome Version: 1.8.10-1 Severity: normal Hello, thank you for maintaning Network Manager! The "VPN Connections" submenu in the NM applet appears after the WIFI connections list, and the WIFI connections list tends to often refresh once the menu is open. ISTR opening the menu triggers a rescan? The result is that often I want to turn on a VPN, open the menu, and before I managed to click on the VPN I want to activate, everything has suddenly moved, and I end up either activating a different VPN, or clicking somewhere else. Ideally, moving the "VPN Connections" submenu above the available networks list would work around this issue. More generally, I guess the part of the applet popup that refreshes while the popup is open should go right at the bottom. Even more generally, the menu refreshing while open is still tricky, as a badly timed refresh could still cause me to connect to a wifi network I didn't intend to connect. I guess the applet could use an invariant that options can appear at the end, or get grayed out, but not change position? But yeah, it would be plenty enough to me if I could reliably hit the VPN I want to connect to. It frustrates me multiple times during a work day :( Enrico -- System Information: Debian Release: 10.7 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.9.0-0.bpo.2-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_WARN Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), LANGUAGE=en_IE:en (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages network-manager-openvpn-gnome depends on: ii libc62.28-10 ii libglib2.0-0 2.58.3-2+deb10u2 ii libgtk-3-0 3.24.5-1 ii libnm0 1.14.6-2+deb10u1 ii libnma0 1.8.20-1.1 ii libsecret-1-00.18.7-1 ii network-manager-openvpn 1.8.10-1 network-manager-openvpn-gnome recommends no packages. network-manager-openvpn-gnome suggests no packages. -- no debconf information
Bug#968044: Choosing 'neomutt' as preferred mail reader silendly sends empty mails
On Tue, Aug 18, 2020 at 02:22:24PM +0200, Yves-Alexis Perez wrote: > I don't have a neomutt choice in the preferred applications settings, so I'm > unsure how you managed to do that. As far as I can tell, there's an helper for > mutt (/usr/share/xfce4/helpers/mutt.desktop) and muttng > (/usr/share/xfce4/helpers/muttng.desktop) but not for neomutt. > > Did you only select a neomutt choice, or did you create it yourself? Good question. I don't remember creating it myself, but it could have been so long ago that I forgot. I'll try to figure out what provides that option to the xfce4 settings, and work it backwards from there. Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini
Bug#968044: Choosing 'neomutt' as preferred mail reader silendly sends empty mails
Package: libexo-1-0 Version: 0.12.4-1 Severity: important Hello, in the xfce "Preferred Applications" dialog, I chose neomutt as the preferred mail reader. It seems to mean 'neomutt "%s"'. Try running 'neomutt t...@example.org' in the application run dialog of xfce, and you'll find that nothing seems to happen, but you just sent an empty email to t...@example.org. I manually changed the mail reader to: x-terminal-emulator -e 'neomutt "%s"' and now it all works fine, but meanwhile the empty mails I, curiously and without noticing, accidentally sent to lists for clicking on the wrong links, will be archived forever by the Internet. Unfortunately, I could not find where the 'neomutt "%s"' default comes from. Enrico -- System Information: Debian Release: 10.5 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.6.0-0.bpo.2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), LANGUAGE=en_IE:en (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libexo-1-0 depends on: ii libatk1.0-0 2.30.0-2 ii libc62.28-10 ii libcairo21.16.0-4 ii libexo-2-0 0.12.4-1 ii libexo-common0.12.4-1 ii libexo-helpers 0.12.4-1 ii libfontconfig1 2.13.1-2 ii libfreetype6 2.9.1-3+deb10u1 ii libgdk-pixbuf2.0-0 2.38.1+dfsg-1 ii libglib2.0-0 2.58.3-2+deb10u2 ii libgtk-3-0 3.24.5-1 ii libgtk2.0-0 2.24.32-3 ii libice6 2:1.0.9-2 ii libpango-1.0-0 1.42.4-8~deb10u1 ii libpangocairo-1.0-0 1.42.4-8~deb10u1 ii libpangoft2-1.0-01.42.4-8~deb10u1 ii libsm6 2:1.2.3-1 ii libx11-6 2:1.6.7-1 ii libxfce4ui-2-0 4.12.1-3 ii libxfce4util74.12.1-3 Versions of packages libexo-1-0 recommends: ii liburi-perl 1.76-1 libexo-1-0 suggests no packages. -- no debconf information
Bug#964949: Cannot open files beginning with a dash ('-')
Package: xdg-utils Version: 1.1.3-1+deb10u1 Severity: important Hello, thank you for maintaining xdg-open. There seems to be no way to use it to open a file whose name begins with a dash: $ sh -x `which xdg-open` -test.pdf + check_common_commands -test.pdf + [ 1 -gt 0 ] + parm=-test.pdf + shift + [ 0 -gt 0 ] + [ -z ] + unset XDG_UTILS_DEBUG_LEVEL + [ 0 -lt 1 ] + xdg_redirect_output= > /dev/null 2> /dev/null + [ x-test.pdf != x ] + url= + [ 1 -gt 0 ] + parm=-test.pdf + shift + exit_failure_syntax unexpected option '-test.pdf' + [ 1 -gt 0 ] + echo xdg-open: unexpected option '-test.pdf' xdg-open: unexpected option '-test.pdf' + echo Try 'xdg-open --help' for more information. Try 'xdg-open --help' for more information. + exit 1 I also tried the usual double-dash approach, which doesn't seem to be supported: $ sh -x `which xdg-open` -- -test.pdf + check_common_commands -- -test.pdf + [ 2 -gt 0 ] + parm=-- + shift + [ 1 -gt 0 ] + parm=-test.pdf + shift + [ 0 -gt 0 ] + [ -z ] + unset XDG_UTILS_DEBUG_LEVEL + [ 0 -lt 1 ] + xdg_redirect_output= > /dev/null 2> /dev/null + [ x-- != x ] + url= + [ 2 -gt 0 ] + parm=-- + shift + exit_failure_syntax unexpected option '--' + [ 1 -gt 0 ] + echo xdg-open: unexpected option '--' xdg-open: unexpected option '--' + echo Try 'xdg-open --help' for more information. Try 'xdg-open --help' for more information. + exit 1 Enrico -- Package-specific info: Desktop environment: XDG_CURRENT_DESKTOP=XFCE -- System Information: Debian Release: 10.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.6.0-0.bpo.2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), LANGUAGE=en_IE:en (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled xdg-utils depends on no packages. Versions of packages xdg-utils recommends: ii libfile-mimeinfo-perl 0.29-1 ii libnet-dbus-perl 1.1.0-5+b1 ii libx11-protocol-perl 0.56-7 ii x11-utils 7.7+4 ii x11-xserver-utils 7.7+8 xdg-utils suggests no packages. -- no debconf information
Bug#964723: Ordering of entries: the calibre opens everything problem
at it is that I could debug. How do priority values work at the moment, and are they being effectively used? I looked into https://wiki.debian.org/MimeTypesSupport which points to https://www.debian.org/doc/debian-policy/ch-opersys.html and I didn't see anything that, for example, the Calibre maintainer could do to give it less priority than evince on PDF files. I see /etc/mailcap.order exists and is not used in my system, and it seems something made for the system administrator, while I'd expect control of ordering to be done by package developers for a default, and users for an override. With regards to FreeDesktop, I see that https://specifications.freedesktop.org/desktop-entry-spec/latest/ar01s10.html There should be no priority for MIME Types in this field, or any form of priority in the desktop file. Priority for applications is handled external to the .desktop files. And I found this issue, which is effectively the same user issue of mailcap on xdg-open: https://gitlab.freedesktop.org/xdg/xdg-specs/-/issues/43 and it sounds like still a work in progress. I guess the issue for xdg-open is mitigated by a better UI, where users who are surprised by the selected program can right click on it, choose "Open with..." and have the system remember the proper one from that point on. Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini signature.asc Description: PGP signature
Bug#964723: Ordering of entries: the calibre opens everything problem
Package: mime-support Version: 3.62 Severity: important Hello, thank you for maintaining mime-support. >From what I understand, entries in /etc/mailcap are sorted by package name. As a consequence, people who install, for example, calibre, will find that it opens quite a lot of file types (which it can do), with a higher priority over the software one would expect: calibre comes alphabetically before evince, okular, libreoffice, and most other packages. There is only a limited way to control this system-wide with /etc/mailcap.order, and no way for users to control ordering. As a user, I can grep /etc/mailcap and paste my preferred entries in ~/.mailcap, but at that point I have hardcoded those command lines in a way outside the control of package maintainers. Suppose that a package has an exploitable command line, and given #928037 it might well be, and a new version fixes it in its mime information, my ~/.mailcap will be stuck with the exploitable version forever. Suppose that a package changes command line options and updates its mime information correctly, my ~/.mailcap will be stuck with a nonfunctioning command line, and I'll spend an afternoon trying to figure out why mutt suddenly can't open PDFs anymore, retracing and relearning the chain of commands and configuration files that go on behind the scenes. I personally found it really nontrivial to figure out. I'm trying to resist the temptation to write and package a tool called aaanything that uses aalib to display as many file types as possible, and provides mime informations accordingly, so that it will sort before pretty much any other package. What I did as a workaround in my system[1], was to add entries in my ~/.mailcap that delegate to xdg-open, like: application/pdf; xdg-open %s && sleep 0.3s; test=test -n "$DISPLAY" Is there a reason this kind of behaviour could not be a default? I'm opening this issue to document this kind of surprising and possibly dangerous behaviour coming out of the way mime-support works. I can't think of many options besides delegating to xdg-open: there doesn't seem a way for packages to declare a priority for their mime support, and even if there was, it would be arbitrary. I could think of packaging something that diverted run-mailcap to a wrapper to xdg-open, falling back to the original run-mailcap if xdg-open doesn't have a mapping, or if DISPLAY is not set. I could think of packaging a program called 0xdg-mime that depends on xdg-utils and registers xdg-open as mime handler for as many entries as possible. I really don't feel good about the current situation being the standard user interface for mime handling in Debian. Enrico [1] https://www.enricozini.org/blog/2020/debian/mime-type-associations/ -- System Information: Debian Release: 10.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.6.0-0.bpo.2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), LANGUAGE=en_IE:en (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled mime-support depends on no packages. Versions of packages mime-support recommends: ii bzip2 1.0.6-9.2~deb10u1 ii file 1:5.35-4+deb10u1 ii xz-utils 5.2.4-1 mime-support suggests no packages. -- no debconf information
Bug#964720: Wrong paths to pgpewrap
Package: neomutt
Version: 20180716+dfsg.1-1+deb10u1
Severity: important
Hello,
thank you for maintaining neomutt!
It looks like sometimes at some point the paths to pgpewrap changed from
/usr/libexec/ to /usr/lib/, and the default configuration did not get updated
accordingly:
$ dpkg -L neomutt|grep pgpewrap
/usr/lib/neomutt/pgpewrap
$ rgrep pgpewrap /etc/neomuttrc*
/etc/neomuttrc.d/gpg.rc:# set
pgp_encrypt_only_command="/usr/libexec/neomutt/pgpewrap gpg-2comp -v --batch
--output - --encrypt --textmode --armor --always-trust -- -r %r -- %f"
/etc/neomuttrc.d/gpg.rc:set
pgp_encrypt_only_command="/usr/libexec/neomutt/pgpewrap gpg --batch --quiet
--no-verbose --output - --textmode --armor --encrypt -- --recipient %r -- %f"
/etc/neomuttrc.d/gpg.rc:# set
pgp_encrypt_sign_command="/usr/libexec/neomutt/pgpewrap gpg-2comp
%?p?--passphrase-fd 0? -v --batch --output - --encrypt --sign %?a?-u %a?
%--armor --always-trust -- -r %r -- %f"
/etc/neomuttrc.d/gpg.rc:set
pgp_encrypt_sign_command="/usr/libexec/neomutt/pgpewrap gpg %?p?--pinentry-mode
loopback --passphrase-fd 0? --batch --quiet %--no-verbose --textmode --output -
%?a?--local-user %a? --armor --sign %--encrypt -- --recipient %r -- %f"
As a consequence, neomutt isn't currently able to send encrypted emails by
default.
Enrico
-- Package-specific info:
NeoMutt 20180716
Copyright (C) 1996-2016 Michael R. Elkins and others.
NeoMutt comes with ABSOLUTELY NO WARRANTY; for details type 'neomutt -vv'.
NeoMutt is free software, and you are welcome to redistribute it
under certain conditions; type 'neomutt -vv' for details.
System: Linux 5.6.0-0.bpo.2-amd64 (x86_64)
ncurses: ncurses 6.1.20181013 (compiled with 6.1.20181013)
libidn: 1.33 (compiled with 1.33)
hcache backends: tokyocabinet
Compiler:
Using built-in specs.
COLLECT_GCC=cc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/8/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 8.3.0-6'
--with-bugurl=file:///usr/share/doc/gcc-8/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr
--with-gcc-major-version-only --program-suffix=-8
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie
--with-system-zlib --with-target-system-zlib --enable-objc-gc=auto
--enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none --without-cuda-driver
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 8.3.0 (Debian 8.3.0-6)
Configure options: --build=x86_64-linux-gnu --prefix=/usr
{--includedir=${prefix}/include} {--mandir=${prefix}/share/man}
{--infodir=${prefix}/share/info} --sysconfdir=/etc --localstatedir=/var
--disable-silent-rules {--libdir=${prefix}/lib/x86_64-linux-gnu}
{--libexecdir=${prefix}/lib/x86_64-linux-gnu} --disable-maintainer-mode
--disable-dependency-tracking --mandir=/usr/share/man --libexecdir=/usr/lib
--with-mailpath=/var/mail --gpgme --lua --notmuch --with-ui --gnutls --gss
--idn --mixmaster --sasl --tokyocabinet
Compilation CFLAGS: -g -O2
-fdebug-prefix-map=/build/neomutt-HR05dz/neomutt-20180716+dfsg.1=.
-fstack-protector-strong -Wformat -Werror=format-security -std=c99
-D_ALL_SOURCE=1 -D_GNU_SOURCE=1 -D__EXTENSIONS__ -I/usr/include
-I/usr/include/lua5.3 -DNCURSES_WIDECHAR -isystem /usr/include/mit-krb5
Default options:
+attach_headers_color +compose_to_sender +compress +cond_date +debug
+encrypt_to_self +forgotten_attachments +forwref +ifdef +imap +index_color
+initials +limit_current_thread +multiple_fcc +nested_if +new_mail +nntp +pop
+progress +quasi_delete +regcomp +reply_with_xorig +sensible_browser +sidebar
+skip_quoted +smtp +status_color +timeout +tls_sni +trash
Compile options:
+bkgdset +color +curs_set +fcntl -flock -fmemopen +futimens +getaddrinfo
+gnutls +gpgme +gss +hcache -homespool +idn -locales_hack +lua +meta
+mixmaster +nls +notmuch -openssl +pgp +sasl +smime +start_color
+sun_attachment +typeahead
MAILPATH="/var/mail"
MIXMASTER="mixmaster"
PKGDATADIR="/usr/share/neomutt"
SENDMAIL="/usr/sbin/sendmail"
SYSCONFDIR="/etc"
To learn more about NeoMutt, visit: https://neomutt.org
If you find a bug in NeoMutt, please raise an issue at:
https://github.com/neomutt/neomutt/issues
or send an email to:
-- System Information:
Debian Release: 10.4
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture:
Bug#963961: Please backport exiv2
Package: exiv2 Version: 0.27.2-8 Severity: wishlist Hello, thank you for maintaining exiv2. exiv2 in testing adds support for the webp image format, not supported in stable. I tried building exiv2 with the build-deps from stable, and it builds and works, with the attached .symbols patch. Could you please backport exiv2? Enrico -- System Information: Debian Release: 10.4 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.5.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), LANGUAGE=en_IE:en (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages exiv2 depends on: ii libc62.28-10 ii libexiv2-27 0.27.2-8 ii libgcc1 1:8.3.0-6 ii libstdc++6 8.3.0-6 exiv2 recommends no packages. exiv2 suggests no packages. -- no debconf information --- old 2020-01-28 22:32:03.0 +0100 +++ libexiv2-27.symbols 2020-06-29 12:04:07.193452629 +0200 @@ -12,15 +12,15 @@ _ZN5Exiv210AsciiValueD2Ev@Base 0.25 (optional=templinst)_ZN5Exiv210BasicErrorIcE6setMsgEv@Base 0.25 (optional=templinst)_ZN5Exiv210BasicErrorIcEC1ENS_9ErrorCodeE@Base 0.27.2 - _ZN5Exiv210BasicErrorIcEC1IA10_cEENS_9ErrorCodeERKT_@Base 0.27.2 + (optional=templinst)_ZN5Exiv210BasicErrorIcEC1IA10_cEENS_9ErrorCodeERKT_@Base 0.27.2 (arch=armel armhf hppa hurd-i386 i386 m68k mipsel powerpc sh4 x32)_ZN5Exiv210BasicErrorIcEC1IA11_cEENS_9ErrorCodeERKT_@Base 0.27.2 (arch=armel armhf hppa hurd-i386 i386 m68k mipsel powerpc sh4 x32)_ZN5Exiv210BasicErrorIcEC1IA13_cEENS_9ErrorCodeERKT_@Base 0.27.2 (arch=armel armhf hppa hurd-i386 i386 m68k mipsel powerpc sh4 x32)_ZN5Exiv210BasicErrorIcEC1IA14_cA10_cEENS_9ErrorCodeERKT_RKT0_@Base 0.27.2 - _ZN5Exiv210BasicErrorIcEC1IA14_cA4_cEENS_9ErrorCodeERKT_RKT0_@Base 0.27.2 + (arch=armel armhf hppa hurd-i386 i386 m68k mipsel powerpc sh4 x32)_ZN5Exiv210BasicErrorIcEC1IA14_cA4_cEENS_9ErrorCodeERKT_RKT0_@Base 0.27.2 (arch=armel armhf hppa hurd-i386 i386 m68k mipsel powerpc sh4 x32)_ZN5Exiv210BasicErrorIcEC1IA14_cA5_cEENS_9ErrorCodeERKT_RKT0_@Base 0.27.2 (arch=armel armhf hppa hurd-i386 i386 m68k mipsel powerpc sh4 x32)_ZN5Exiv210BasicErrorIcEC1IA15_cEENS_9ErrorCodeERKT_@Base 0.27.2 _ZN5Exiv210BasicErrorIcEC1IA4_cEENS_9ErrorCodeERKT_@Base 0.27.2 - _ZN5Exiv210BasicErrorIcEC1IA5_cEENS_9ErrorCodeERKT_@Base 0.27.2 + (arch=armel armhf hppa hurd-i386 i386 m68k mipsel powerpc sh4 x32)_ZN5Exiv210BasicErrorIcEC1IA5_cEENS_9ErrorCodeERKT_@Base 0.27.2 _ZN5Exiv210BasicErrorIcEC1IA7_clEENS_9ErrorCodeERKT_RKT0_@Base 0.27.2 (optional=templinst)_ZN5Exiv210BasicErrorIcEC1INS_8Internal5IfdIdEEENS_9ErrorCodeERKT_@Base 0.27.2 (optional=templinst)_ZN5Exiv210BasicErrorIcEC1INSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEA3_cS8_EENS_9ErrorCodeERKT_RKT0_RKT1_@Base 0.27.2 @@ -35,15 +35,15 @@ (optional=templinst)_ZN5Exiv210BasicErrorIcEC1IiEENS_9ErrorCodeERKT_@Base 0.27.2 (optional=templinst)_ZN5Exiv210BasicErrorIcEC1IiPKcEENS_9ErrorCodeERKT_RKT0_@Base 0.27.2 (optional=templinst)_ZN5Exiv210BasicErrorIcEC2ENS_9ErrorCodeE@Base 0.27.2 - _ZN5Exiv210BasicErrorIcEC2IA10_cEENS_9ErrorCodeERKT_@Base 0.27.2 + (optional=templinst)_ZN5Exiv210BasicErrorIcEC2IA10_cEENS_9ErrorCodeERKT_@Base 0.27.2 (arch=armel armhf hppa hurd-i386 i386 m68k mipsel powerpc sh4 x32)_ZN5Exiv210BasicErrorIcEC2IA11_cEENS_9ErrorCodeERKT_@Base 0.27.2 (arch=armel armhf hppa hurd-i386 i386 m68k mipsel powerpc sh4 x32)_ZN5Exiv210BasicErrorIcEC2IA13_cEENS_9ErrorCodeERKT_@Base 0.27.2 (arch=armel armhf hppa hurd-i386 i386 m68k mipsel powerpc sh4 x32)_ZN5Exiv210BasicErrorIcEC2IA14_cA10_cEENS_9ErrorCodeERKT_RKT0_@Base 0.27.2 - _ZN5Exiv210BasicErrorIcEC2IA14_cA4_cEENS_9ErrorCodeERKT_RKT0_@Base 0.27.2 + (arch=armel armhf hppa hurd-i386 i386 m68k mipsel powerpc sh4 x32)_ZN5Exiv210BasicErrorIcEC2IA14_cA4_cEENS_9ErrorCodeERKT_RKT0_@Base 0.27.2 (arch=armel armhf hppa hurd-i386 i386 m68k mipsel powerpc sh4 x32)_ZN5Exiv210BasicErrorIcEC2IA14_cA5_cEENS_9ErrorCodeERKT_RKT0_@Base 0.27.2 (arch=armel armhf hppa hurd-i386 i386 m68k mipsel powerpc sh4 x32)_ZN5Exiv210BasicErrorIcEC2IA15_cEENS_9ErrorCodeERKT_@Base 0.27.2 _ZN5Exiv210BasicErrorIcEC2IA4_cEENS_9ErrorCodeERKT_@Base 0.27.2 - _ZN5Exiv210BasicErrorIcEC2IA5_cEENS_9ErrorCodeERKT_@Base 0.27.2 + (arch=armel armhf hppa hurd-i386 i386 m68k mipsel powerpc sh4 x32)_ZN5Exiv210BasicErrorIcEC2IA5_cEENS_9ErrorCodeERKT_@Base 0.27.2 _ZN5Exiv210BasicErrorIcEC2IA7_clEENS_9ErrorCodeERKT_RKT0_@Base 0.27.2 (optional=templinst)_ZN5Exiv210BasicErrorIcEC2INS_8Internal5IfdIdEEENS_9ErrorCodeERKT_@Base 0.27.2 (optional=templinst)_ZN5Exiv210BasicErrorIcEC2INSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEA3_cS8_EENS_9ErrorCodeERKT_RKT0_RKT1_@Base 0.27.2
Bug#963958: Please backport imlib2 to buster
Source: imlib2 Severity: wishlist Hello, thank you for maintaining imlib2. Testing imlib2 supports additional formats like webp, that stable imlib2 does not. I tried rebuilding imlib2 1.6.1-2 on stable+backports, and it built flawlessly. Installing just the shared library is enough to have, for example, feh, be able to show webp files. Could you please do a backport upload of imlib2? Enrico -- System Information: Debian Release: 10.4 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.5.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), LANGUAGE=en_IE:en (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#963130: [Pkg-xmpp-devel] Bug#963130: /show command could wait for enter before sending
On Fri, Jun 19, 2020 at 07:46:45PM +0200, Martin wrote: > > Ideally I would like to be able to disable it. > > Upstream did exactly this in the 1.2 line. > In Gajim from debian/experimental you get: > > "Command disabled. This command can be enabled by setting > 'command_system_execute' to True in ACE (Advanced Configuration Editor)." Ah, thanks, that's very nice to hear! <3 Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini
Bug#963136: libnss3-dev:amd64 not coinstallable with libnss3-dev:armhf
Package: libnss3-dev Version: 3.42.1-1+deb10u2 Severity: wishlist Hello, thank you for maintaining libnss3-dev. This might be closely related to #737855, which sadly doesn't seem to have had much activity since 2014. libnss3-dev:amd64 is not not coinstallable with libnss3-dev:armhf, either directly, or because the libnspr4-dev dependency is also not coinstallable between amd64 and armhf. This is the current blocker that I can't overcome for having qtwebengine compiled as part of a Qt5 integrated cross-development environment: https://www.enricozini.org/blog/2020/qt5/qt5-custom-build-for-armhf-embedded-development/ Also, I find coinstallable development libraries very desirable in all sorts of cross-development situations. Could nss (and I guess also nspr) please be made to be coinstallable across architectures? Enrico -- System Information: Debian Release: 10.4 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.5.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), LANGUAGE=en_IE:en (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libnss3-dev depends on: pn libnspr4-dev ii libnss3 2:3.42.1-1+deb10u2 libnss3-dev recommends no packages. libnss3-dev suggests no packages.
Bug#963134: /show can crash gajim on encoding errors
Package: gajim Version: 1.1.2-2 Severity: normal Hello, Thank you for maintaining gajim. I just learnt of the /show command, which runs a shell command and posts its output. It works exactly as intended. What could possibly go wrong? It even has 4 aliases: show, sh, execute, exec. The /show alias is particularly interesting because it looks quite innocuous if one doesn't already know what it does. Anyway, this makes gajim throw a nice UnicodeDecodeError: /show dd if=/dev/urandom bs=512 count=1 Enrico -- System Information: Debian Release: 10.4 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.5.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), LANGUAGE=en_IE:en (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages gajim depends on: ii gir1.2-gtk-3.0 3.24.5-1 ii python3 3.7.3-1 ii python3-cssutils 1.0.2-2 ii python3-gi 3.30.4-1 ii python3-gi-cairo 3.30.4-1 ii python3-idna 2.6-1 ii python3-keyring 17.1.1-1 ii python3-nbxmpp 0.6.10-1 ii python3-openssl 19.0.0-1 ii python3-precis-i18n 1.0.0-1 Versions of packages gajim recommends: ii alsa-utils1.1.8-2 ii aspell-en [aspell-dictionary] 2018.04.16-0-1 ii ca-certificates 20190110 ii dbus 1.12.16-1 ii fonts-noto-color-emoji0~20180810-1 ii gajim-omemo 2.6.27-1 ii gajim-pgp 1.2.24-1 ii gir1.2-farstream-0.2 0.2.8-4.1 ii gir1.2-geoclue-2.02.5.2-1 ii gir1.2-gspell-1 1.6.1-2 ii gir1.2-gst-plugins-base-1.0 1.14.4-2 ii gir1.2-gstreamer-1.0 1.14.4-1 ii gir1.2-gupnpigd-1.0 0.2.5-3 ii gir1.2-secret-1 0.18.7-1 ii gstreamer1.0-plugins-ugly 1.14.4-1 ii lxqt-notificationd [notification-daemon] 0.14.1-1 ii notification-daemon 3.20.0-4 ii pulseaudio-utils 12.2-4+deb10u1 ii python3-crypto2.6.1-9+b1 ii python3-dbus 1.2.8-3 ii python3-gnupg 0.4.4-1 ii python3-pil 5.4.1-2+deb10u1 ii xfce4-notifyd [notification-daemon] 0.4.3-1 Versions of packages gajim suggests: ii avahi-daemon 0.7-4+b1 ii libxss1 1:1.2.3-1 pn nautilus-sendto ii python3-kerberos 1.1.14-2 ii python3-pycurl7.43.0.2-0.1 -- no debconf information
Bug#963132: /show yes silently leaves process running indefinitely
Package: gajim Version: 1.1.2-2 Severity: normal Hello, Thank you for maintaining gajim. I just learnt of the /show command, which runs a shell command and posts its output. It works exactly as intended. What could possibly go wrong? I tried running "/show yes". Nothing happened, I could keep chatting normally, and the 'yes' command has been left running indefinitely. Interrupting it didn't flood the channel with millions of 'y' lines, either. I didn't investigate what gajim is doing behing the scenes. It didn't seem to use CPU and RAM usage didn't seem to increase significantly, but the process was left around. I suppose it was blocked while writing its standard output to a pipe. "/show yes > /tmp/foo", instead, happily filled the disk with no visible outcome in gajim's interface. I havent tried /show . All of this in theory is working exactly as intended. What I find surprising is the feedback, whereas it looks like the /show command did nothing, and instead it spawned a daemon running forever. Enrico -- System Information: Debian Release: 10.4 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.5.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), LANGUAGE=en_IE:en (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages gajim depends on: ii gir1.2-gtk-3.0 3.24.5-1 ii python3 3.7.3-1 ii python3-cssutils 1.0.2-2 ii python3-gi 3.30.4-1 ii python3-gi-cairo 3.30.4-1 ii python3-idna 2.6-1 ii python3-keyring 17.1.1-1 ii python3-nbxmpp 0.6.10-1 ii python3-openssl 19.0.0-1 ii python3-precis-i18n 1.0.0-1 Versions of packages gajim recommends: ii alsa-utils1.1.8-2 ii aspell-en [aspell-dictionary] 2018.04.16-0-1 ii ca-certificates 20190110 ii dbus 1.12.16-1 ii fonts-noto-color-emoji0~20180810-1 ii gajim-omemo 2.6.27-1 ii gajim-pgp 1.2.24-1 ii gir1.2-farstream-0.2 0.2.8-4.1 ii gir1.2-geoclue-2.02.5.2-1 ii gir1.2-gspell-1 1.6.1-2 ii gir1.2-gst-plugins-base-1.0 1.14.4-2 ii gir1.2-gstreamer-1.0 1.14.4-1 ii gir1.2-gupnpigd-1.0 0.2.5-3 ii gir1.2-secret-1 0.18.7-1 ii gstreamer1.0-plugins-ugly 1.14.4-1 ii lxqt-notificationd [notification-daemon] 0.14.1-1 ii notification-daemon 3.20.0-4 ii pulseaudio-utils 12.2-4+deb10u1 ii python3-crypto2.6.1-9+b1 ii python3-dbus 1.2.8-3 ii python3-gnupg 0.4.4-1 ii python3-pil 5.4.1-2+deb10u1 ii xfce4-notifyd [notification-daemon] 0.4.3-1 Versions of packages gajim suggests: ii avahi-daemon 0.7-4+b1 ii libxss1 1:1.2.3-1 pn nautilus-sendto ii python3-kerberos 1.1.14-2 ii python3-pycurl7.43.0.2-0.1 -- no debconf information
Bug#963131: /show could send as monospace
Package: gajim Version: 1.1.2-2 Severity: wishlist Hello, Thank you for maintaining gajim. I just learnt of the /show command, which runs a shell command and posts its output. It works exactly as intended. What could possibly go wrong? The first use case for this command that comes to my mind would be to find out how to turn it off. The second, is to admire how to make it easy to be annoying with something like "/show echo "LALALA" | figlet" However, the output is sent with a proportional font, breaking the formatting and making it hard to be annoying in a proper vintage fashion. If the feature is there to stay, can it at least send the output formatted with a monospace font? Enrico -- System Information: Debian Release: 10.4 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.5.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), LANGUAGE=en_IE:en (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages gajim depends on: ii gir1.2-gtk-3.0 3.24.5-1 ii python3 3.7.3-1 ii python3-cssutils 1.0.2-2 ii python3-gi 3.30.4-1 ii python3-gi-cairo 3.30.4-1 ii python3-idna 2.6-1 ii python3-keyring 17.1.1-1 ii python3-nbxmpp 0.6.10-1 ii python3-openssl 19.0.0-1 ii python3-precis-i18n 1.0.0-1 Versions of packages gajim recommends: ii alsa-utils1.1.8-2 ii aspell-en [aspell-dictionary] 2018.04.16-0-1 ii ca-certificates 20190110 ii dbus 1.12.16-1 ii fonts-noto-color-emoji0~20180810-1 ii gajim-omemo 2.6.27-1 ii gajim-pgp 1.2.24-1 ii gir1.2-farstream-0.2 0.2.8-4.1 ii gir1.2-geoclue-2.02.5.2-1 ii gir1.2-gspell-1 1.6.1-2 ii gir1.2-gst-plugins-base-1.0 1.14.4-2 ii gir1.2-gstreamer-1.0 1.14.4-1 ii gir1.2-gupnpigd-1.0 0.2.5-3 ii gir1.2-secret-1 0.18.7-1 ii gstreamer1.0-plugins-ugly 1.14.4-1 ii lxqt-notificationd [notification-daemon] 0.14.1-1 ii notification-daemon 3.20.0-4 ii pulseaudio-utils 12.2-4+deb10u1 ii python3-crypto2.6.1-9+b1 ii python3-dbus 1.2.8-3 ii python3-gnupg 0.4.4-1 ii python3-pil 5.4.1-2+deb10u1 ii xfce4-notifyd [notification-daemon] 0.4.3-1 Versions of packages gajim suggests: ii avahi-daemon 0.7-4+b1 ii libxss1 1:1.2.3-1 pn nautilus-sendto ii python3-kerberos 1.1.14-2 ii python3-pycurl7.43.0.2-0.1 -- no debconf information
Bug#963130: /show command could wait for enter before sending
Package: gajim Version: 1.1.2-2 Severity: wishlist Hello, Thank you for maintaining gajim. I just learnt of the /show command, which runs a shell command and posts its output. It works exactly as intended. What could possibly go wrong? Ideally I would like to be able to disable it. Failing that, I would prefer if it would default to filling the input box with the result of the command, allowing me to optionally edit it or just press enter to send it. Enrico -- System Information: Debian Release: 10.4 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.5.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), LANGUAGE=en_IE:en (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages gajim depends on: ii gir1.2-gtk-3.0 3.24.5-1 ii python3 3.7.3-1 ii python3-cssutils 1.0.2-2 ii python3-gi 3.30.4-1 ii python3-gi-cairo 3.30.4-1 ii python3-idna 2.6-1 ii python3-keyring 17.1.1-1 ii python3-nbxmpp 0.6.10-1 ii python3-openssl 19.0.0-1 ii python3-precis-i18n 1.0.0-1 Versions of packages gajim recommends: ii alsa-utils1.1.8-2 ii aspell-en [aspell-dictionary] 2018.04.16-0-1 ii ca-certificates 20190110 ii dbus 1.12.16-1 ii fonts-noto-color-emoji0~20180810-1 ii gajim-omemo 2.6.27-1 ii gajim-pgp 1.2.24-1 ii gir1.2-farstream-0.2 0.2.8-4.1 ii gir1.2-geoclue-2.02.5.2-1 ii gir1.2-gspell-1 1.6.1-2 ii gir1.2-gst-plugins-base-1.0 1.14.4-2 ii gir1.2-gstreamer-1.0 1.14.4-1 ii gir1.2-gupnpigd-1.0 0.2.5-3 ii gir1.2-secret-1 0.18.7-1 ii gstreamer1.0-plugins-ugly 1.14.4-1 ii lxqt-notificationd [notification-daemon] 0.14.1-1 ii notification-daemon 3.20.0-4 ii pulseaudio-utils 12.2-4+deb10u1 ii python3-crypto2.6.1-9+b1 ii python3-dbus 1.2.8-3 ii python3-gnupg 0.4.4-1 ii python3-pil 5.4.1-2+deb10u1 ii xfce4-notifyd [notification-daemon] 0.4.3-1 Versions of packages gajim suggests: ii avahi-daemon 0.7-4+b1 ii libxss1 1:1.2.3-1 pn nautilus-sendto ii python3-kerberos 1.1.14-2 ii python3-pycurl7.43.0.2-0.1 -- no debconf information
Bug#944757: endless-sky: please package Endless Sky 0.9.10
On Thu, Jun 18, 2020 at 04:28:38PM +0200, Enrico Zini wrote: > Please do :) > Upstream's latest stable release is now 0.9.12. Additionally, I can confirm that 0.9.12 builds and works just by plugging in the current debian/ contents. Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini
Bug#944757: endless-sky: please package Endless Sky 0.9.10
On Thu, Nov 14, 2019 at 10:01:49PM +0100, Martin Steigerwald wrote: > please package version 0.9.10 or whatever version is current when you decide > to do an updated package. Please do :) Upstream's latest stable release is now 0.9.12. Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini
Bug#961726: OK ! here are the tarballs
On Thu, May 28, 2020 at 02:49:38PM +0200, Paolo Greppi wrote: > This certainly makes sense and will be easier to digest by ftp-master > (although you'll have two packages in NEW). > > For the tarballs, they are here: > https://gitlab.eumetsat.int/open-source/PublicDecompWT/-/tags > (click on the Download icon at the right). Thanks! I don't see the sense of autogenerating a tarball from git in order to build a non-native package, though. Given that I'm also adding a CMakeLists.txt and a pkg-config template on top of it, I find that using a native package regularly rebase on upstream's git simplifies my work significantly. > gitlab works well with uscan, see for example: > https://codesearch.debian.net/search?q=gitlab+path%3Adebian%2Fwatch=0 Thanks, good tip! I've added a watchfile looking for new tags. Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini
Bug#961726: ITP: publicdecompwt -- Wavelet decompression tool for xRIT files from MeteoSat Second Generation
Package: wnpp Severity: wishlist Owner: Enrico Zini * Package name: publicdecompwt Version : 2.7.2 Upstream Author : EUMETSAT http://www.eumetsat.int/ * URL : https://gitlab.eumetsat.int/open-source/PublicDecompWT * License : Apache Programming Lang: C++ Description : Wavelet decompression tool for xRIT files from MeteoSat Second Generation This is a development-only library with the decompression code for MeteoSat Second Generation (MSG) images, provided by EUMETSAT. . It can be used to build software that can read MSG images. EUMETSAT has finally freed the source code of this library, and I need to package it as a build-dependency for meteosatlib: https://github.com/ARPA-SIMC/meteosatlib/ To the best of my understanding, upstream does not distribute tarballs, does not support shlibs, and provides only a rudimentary Makefile, so I've added a simple CMakeLists.txt to make it build as Debian tools expect it, and packaged it as a `-dev`-only native package. Enrico
Bug#961276: Messages received from blocked accounts
Package: gajim Version: 1.1.2-2 Severity: important Hello, today at 12:46 I received a SPIM with an invitation followed by a message. I denied the invitation, and blocked the account using "Manage Contact → Block". I closed the chat window with the spam message. At 13:37, that chat window reopened with a second message. I'm attaching two small screenshots of what my roster looks like and what's in the chat window. It looks like the blocked status of the account is not taking effect. Enrico -- System Information: Debian Release: 10.4 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.5.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), LANGUAGE=en_IE:en (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages gajim depends on: ii gir1.2-gtk-3.0 3.24.5-1 ii python3 3.7.3-1 ii python3-cssutils 1.0.2-2 ii python3-gi 3.30.4-1 ii python3-gi-cairo 3.30.4-1 ii python3-idna 2.6-1 ii python3-keyring 17.1.1-1 ii python3-nbxmpp 0.6.10-1 ii python3-openssl 19.0.0-1 ii python3-precis-i18n 1.0.0-1 Versions of packages gajim recommends: ii alsa-utils1.1.8-2 ii aspell-en [aspell-dictionary] 2018.04.16-0-1 ii ca-certificates 20190110 ii dbus 1.12.16-1 ii fonts-noto-color-emoji0~20180810-1 ii gajim-omemo 2.6.27-1 ii gajim-pgp 1.2.24-1 ii gir1.2-farstream-0.2 0.2.8-4.1 ii gir1.2-geoclue-2.02.5.2-1 ii gir1.2-gspell-1 1.6.1-2 ii gir1.2-gst-plugins-base-1.0 1.14.4-2 ii gir1.2-gstreamer-1.0 1.14.4-1 ii gir1.2-gupnpigd-1.0 0.2.5-3 ii gir1.2-secret-1 0.18.7-1 ii gstreamer1.0-plugins-ugly 1.14.4-1 ii lxqt-notificationd [notification-daemon] 0.14.1-1 ii notification-daemon 3.20.0-4 ii pulseaudio-utils 12.2-4+deb10u1 ii python3-crypto2.6.1-9+b1 ii python3-dbus 1.2.8-3 ii python3-gnupg 0.4.4-1 ii python3-pil 5.4.1-2+deb10u1 ii xfce4-notifyd [notification-daemon] 0.4.3-1 Versions of packages gajim suggests: ii avahi-daemon 0.7-4+b1 ii libxss1 1:1.2.3-1 pn nautilus-sendto ii python3-kerberos 1.1.14-2 ii python3-pycurl7.43.0.2-0.1 -- no debconf information
Bug#949974: More details
On Mon, Jan 27, 2020 at 09:46:35PM +0100, Enrico Zini wrote: > If there is still data to write, self._pending_write is not done when > future_add_done_callback is called, and RequestHandler.flush() won't get > stuck. Keeping the write buffer nonempty is not sufficient: if it remains with a few data, the problem is triggered anyway, as it will managed to get written right away and set the _pending_write future to done() before reaching the event loop, triggering the hang again. Since this depends on whether there is enough pending data to write to cause the buffer to block, it's hard to predict what is a reasonable amount of data to leave in the pipeline as a workaround. Meaning, I currently cannot find a way to await finish() in tornado 5. It would be important for me to do so, as it's the only way I have to be able to log an outcome of a request, figuring out for example if the remote has closed the connection early. - - - To answer Julien Puydt, this is fixed upstream in Tornado 6, which is not in Debian yet. I would call this by now a debian-specific bug, and I think it's useful to document it here, rather than waste upstream's time with an issue they have fixed in a version releases a year ago. Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini signature.asc Description: PGP signature
Bug#958441: debtags: Please add Cobol language tag (devel::lang:cobol)
On Wed, Apr 22, 2020 at 06:03:25AM +0200, Petter Reinholdtsen wrote: > Package: debtags > Severity: wishlist > > While tagging the gnucobol package, I discovered there is no tag for the > cobol language. I propose to add a tag devel::lang:cobol for this > purpose. Perhaps also add implemented-in::cobol for completeness, to > match other programming languages? Hi Petter, I like the idea. One of the policies for new tags, is to have at least 6 or 7 packages that would use them: https://wiki.debian.org/Debtags/FAQ#What_makes_a_tag_good_for_being_added_to_the_vocabulary.3F Could you make a list of packages that would fit? It would also help initializing the tag data so that we don't have tags matching no packages. If we still don't have so many packages for those tags in the archive, you can use devel::lang::TODO implemented-in::TODO for the time being, or given how well defined are those tags and how cobol is a historically well established language, we could make an exception. I would still prefer not to introduce tags without associated packages, though. Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini signature.asc Description: PGP signature
