Bug#982166: work around
I added more information. 1) vam remove -w ultisnips This program Error exit. It might try to remove `pythonx` directory. It seems to me that do "remove recursive". or "list all files" --- 2) Share my work around method. It is pretty danger but this method can remove vim-ultisnips package. Then reinstall vim-ultisnips. 2-1) see `lv /usr/share/vim/registry/vim-ultisnips.yaml` 2-2) Check Erased file(see below) - after/plugin/UltiSnips_after.vim - autoload/UltiSnips.vim - autoload/UltiSnips/map_keys.vim - autoload/neocomplete/sources/ultisnips.vim - autoload/unite/sources/ultisnips.vim - doc/UltiSnips.txt - ftdetect/UltiSnips.vim - ftdetect/snippets.vim - ftplugin/snippets.vim - plugin/UltiSnips.vim 2-3) Erase files manually (see below) - pythonx/UltiSnips - rplugin/python3/deoplete/sources/ultisnips.py - syntax/snippets.vim - syntax/snippets_snipmate.vim 2-4) status comfirm do `vam status` 2-5) do apt remove --purge vim-ultisnips 2-6) apt install vim-ultisnips -- ++++++++++++++ Yukiharu Yabuki (矢吹幸治) I use Debian GNU/Linux mail: yab...@netfort.gr.jp クレクレタコラは好き / クレクレタコだはイヤ ++++++++++++++ pgpPZhrM5ql4a.pgp Description: PGP signature
Bug#994598: dh_dwz: pass -l/-L options
Niels Thykier: > Control: tags -1 moreinfo > > On Sat, 18 Sep 2021 12:39:34 +0200 Matthias Urlichs > wrote: >> Package: debhelper >> Version: 13.5.1 >> Severity: normal >> >> "dwz" has limits which are too low for some programs, particularly when >> they're heavy on C++ and templates and such stuff. Thus, dh_dwz needs -l/-L >> options it can forward to dwz; see its manpage. >> >> Seen when building the latest upstream version of PrusaSlicer. >> >> >> [...] > Hi Matthias, > > You can pass -l/-L to dwz by using: > > override_dh_dwz: >dh_dwz -- > > And thereby tuning dwz better to your concrete package. > > > Thanks, > ~Niels > Hi Matthias, Did the above answer your question/request? ~Niels
Bug#995032: gnome-session segfaults - no GNOME session possible at all (white screen to contact the system administrator)
On Sat, Sep 25, 2021 at 12:30 AM Michael Ott wrote: > The problem is not gnome-shell. It is the gobject-introspection. > After downgrade this packages from 1.70.0-1+b1 to 1.70.0-1 it works > again. gobject-introspection was rebuilt as part of the libffi transition. (That's where the +b1 part of the version name comes from.) The transition is still in progress. Maybe the problem is that you didn't have the rebuilt gjs installed? The rebuilt gjs is version 1.68.4-1+b1 Here's the list of other packages involved in the transition: https://release.debian.org/transitions/html/auto-libffi.html Thanks, Jeremy Bicha
Bug#995044: esorex: FTBFS on mips64el: FAIL: 1
Source: esorex
Version: 3.13.5+ds1-1
Severity: serious
Tags: ftbfs sid bookworm
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: sramac...@debian.org
esorex failed to build on mips64el:
| FAIL: esorex_python-test
|
|
|
| Start time : 2021-09-24T15:38:49
| Program name : esorex_python-test
| Severity level : [ DEBUG ]
|
| 15:38:49 [ DEBUG ] cpl_test_init_macro: [tid=000] cpl_test_init_macro() was
called with errno=2: No such file or directory (Unless you are debugging code
prior to the cpl_init() call you can ignore this message)
| 15:38:49 [ DEBUG ] cpl_test_init_macro: [tid=000] sizeof(cpl_size): 8
| 15:38:49 [ DEBUG ] cpl_test_init_macro: [tid=000] sizeof(OFF_T)=8
| 15:38:49 [ DEBUG ] cpl_test_init_macro: [tid=000] CPL = 7.1.4, CFITSIO =
3.49, WCSLIB, FFTW (normal precision) = 3.3.8, FFTW (single precision) = 3.3.8,
CPL FLOP counting is unavailable, enable with -DCPL_ADD_FLOPS, OPENMP = 201511
| 15:38:49 [ DEBUG ] main: [tid=000] Test 1 OK at esorex_python-test.c:66:
(setenv("PATH", path, 0x1) == 0) = 1.
| 15:38:49 [ DEBUG ] cpl_errorstate_dump_debug: [tid=000] No error(s) to dump
| 15:38:49 [ DEBUG ] test_error_from_interpreter: [tid=000] Test 2 OK at
esorex_python-test.c:119: (modulelist != NULL) = 1.
| 15:38:49 [ DEBUG ] cpl_errorstate_dump_debug: [tid=000] No error(s) to dump
| 15:38:49 [ DEBUG ] mock_python: [tid=000] Test 3 OK at
esorex_python-test.c:93: (cpl_test_get_failed() == 0) = 1.
| 15:38:49 [ DEBUG ] cpl_errorstate_dump_debug: [tid=000] No error(s) to dump
| 15:38:49 [ DEBUG ] mock_python: [tid=000] Test 4 OK at
esorex_python-test.c:103: (file != NULL) = 1.
| 15:38:49 [ DEBUG ] cpl_errorstate_dump_debug: [tid=000] No error(s) to dump
| 15:38:49 [ DEBUG ] mock_python: [tid=000] Test 5 OK at
esorex_python-test.c:106: (bytes_written == bytes_to_write) = 1.
| 15:38:49 [ DEBUG ] cpl_errorstate_dump_debug: [tid=000] No error(s) to dump
| 15:38:49 [ DEBUG ] mock_python: [tid=000] Test 6 OK at
esorex_python-test.c:108: (fclose_result == 0) = 1.
| 15:38:49 [ DEBUG ] cpl_errorstate_dump_debug: [tid=000] No error(s) to dump
| 15:38:49 [ DEBUG ] mock_python: [tid=000] Test 7 OK at
esorex_python-test.c:112: (chmod("./mock_python_test/python", mode) == 0) = 1.
| 15:38:49 [ DEBUG ] cpl_errorstate_dump_debug: [tid=000] No error(s) to dump
| 15:38:49 [ DEBUG ] run_python_command: [tid=000] Command sent to Python
interpreter:
| import sys, os, json; _data = json.load(os.fdopen(3,'r'));
exec(_data['script'])
| 15:38:49 [ DEBUG ] run_python_command: [tid=000] Input to Python interpreter:
| 15:38:49 [ DEBUG ] run_python_command: [tid=000] 0001 {
| 15:38:49 [ DEBUG ] run_python_command: [tid=000] 0002 "script": "import
inspect\nvalid_modules = {}\nfor path in _data['paths']:\n module =
os.path.splitext(os.path.basename(path))[0]\n
sys.path.append(os.path.dirname(path))\n try:\n__import__(module)\nfor
name, cls in inspect.getmembers(sys.modules[module],
predicate=inspect.isclass):\n if len([base for base in cls.__mro__ if
base.__name__ == 'CplPlugin']) > 0:\nif path not in valid_modules:\n
valid_modules[path] = set()\nvalid_modules[path].add(cls)\n
except:\nimport traceback\ntraceback.print_exc()\n del
sys.path[-1]\nresults = {}\nfor path, clslist in valid_modules.items():\n
results[path] = []\n for cls in clslist:\nplugin = {'class':
cls.__name__}\ntry:\n inst = cls()\nexcept:\n continue\n
try:\n name = inst.name\nexcept:\n name = cls.__name__\n
try:\n version = inst.version\nexcept:\n version = None\n
try:\n synopsis = inst.synopsis
| 15:38:49 [ DEBUG ] run_python_command: [tid=000] 0003 "paths": [
| 15:38:49 [ DEBUG ] run_python_command: [tid=000] 0004 ".\/test.py"
| 15:38:49 [ DEBUG ] run_python_command: [tid=000] 0005 ]
| 15:38:49 [ DEBUG ] run_python_command: [tid=000] 0006 }
| FAIL esorex_python-test (exit status: 141)
See
https://buildd.debian.org/status/fetch.php?pkg=esorex&arch=mips64el&ver=3.13.5%2Bds-1%2Bb1&stamp=1632497947&raw=0
Cheers
--
Sebastian Ramacher
Bug#995045: llvm-toolchain-11: FTBFS with linux 5.14: fatal error: linux/cyclades.h: No such file or directory
Source: llvm-toolchain-11 Version: 1:11.0.1-2 Severity: serious Tags: ftbfs sid bookworm Justification: fails to build from source (but built successfully in the past) X-Debbugs-Cc: sramac...@debian.org | [ 8%] Building CXX object projects/compiler-rt/lib/sanitizer_common/CMakeFiles/RTSanitizerCommon.x86_64.dir/sanitizer_platform_limits_posix.cpp.o | cd /<>/build-llvm/projects/compiler-rt/lib/sanitizer_common && /usr/bin/g++-10 -DHAVE_RPC_XDR_H=0 -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -I/<>/build-llvm/projects/compiler-rt/lib/sanitizer_common -I/<>/compiler-rt/lib/sanitizer_common -I/<>/build-llvm/include -I/<>/llvm/include -I/<>/compiler-rt/lib/sanitizer_common/.. -g -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -fPIC -fvisibility-inlines-hidden -Werror=date-time -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wno-missing-field-initializers -pedantic -Wno-long-long -Wimplicit-fallthrough -Wno-maybe-uninitialized -Wno-class-memaccess -Wno-redundant-move -Wno-noexcept-type -Wdelete-non-virtual-dtor -Wno-comment -ffunction-sections -fdata-sections -Wall -std=c++14 -Wno-unused-parameter -O2 -DNDEBUG -g1 -m64 -fPIC -fno-builtin -fno-exceptions -fomit-frame-pointer -funwind-tables -fno-stack-protector -fvisibility=hidden -fno-lto -O3 -g -Wno-variadic-macros -Wno-non-virtual-dtor -fno-rtti -Wframe-larger-than=570 -std=c++14 -MD -MT projects/compiler-rt/lib/sanitizer_common/CMakeFiles/RTSanitizerCommon.x86_64.dir/sanitizer_platform_limits_posix.cpp.o -MF CMakeFiles/RTSanitizerCommon.x86_64.dir/sanitizer_platform_limits_posix.cpp.o.d -o CMakeFiles/RTSanitizerCommon.x86_64.dir/sanitizer_platform_limits_posix.cpp.o -c /<>/compiler-rt/lib/sanitizer_common/sanitizer_platform_limits_posix.cpp | /<>/compiler-rt/lib/sanitizer_common/sanitizer_platform_limits_posix.cpp:133:10: fatal error: linux/cyclades.h: No such file or directory | 133 | #include | | ^~ | compilation terminated. See https://buildd.debian.org/status/fetch.php?pkg=llvm-toolchain-11&arch=amd64&ver=1%3A11.0.1-2%2Bb1&stamp=1632526952&raw=0 Cheers -- Sebastian Ramacher
Bug#970013: pulseaudio-utils: cannot switch to headset_head_unit
On Wed, 22 Sep 2021 22:20:34 -0500 Chad wrote: > Package: pulseaudio > Version: 14.2-2 > Followup-For: Bug #970013 > > Dear Maintainer, > > As with the original reporter of this bug, I too cannot change the > profile of my associated bluetooth headsets to > headset_head_unit. Below is a clip of the output from "pactl list" > after associating a headset. I recall this working at some point in > the past, but I don't have a good fixture on when that changed, as it > has been quite some time since I've used any bluetooth headset to > record. > > This could also potentially be related to pulseaudio-module-bluetooth bug > #993011? > > -- Output from "pactl list": > Card #2 > Name: bluez_card.F4_4E_FC_22_A0_0A > Driver: module-bluez5-device.c > Owner Module: 21 > Properties: > device.description = "S17" > device.string = "F4:4E:FC:22:A0:0A" > device.api = "bluez" > device.class = "sound" > device.bus = "bluetooth" > device.form_factor = "headset" > bluez.path = "/org/bluez/hci0/dev_F4_4E_FC_22_A0_0A" > bluez.class = "0x240404" > bluez.alias = "S17" > device.icon_name = "audio-headset-bluetooth" > device.intended_roles = "phone" > Profiles: > a2dp_sink: High Fidelity Playback (A2DP Sink) (sinks: 1, sources: 0, > priority: 40, available: yes) > headset_head_unit: Headset Head Unit (HSP/HFP) (sinks: 1, sources: 1, > priority: 30, available: no) > off: Off (sinks: 0, sources: 0, priority: 0, available: yes) > Active Profile: a2dp_sink > Ports: > headset-output: Headset (type: Headset, priority: 0, latency offset: 0 usec, > availability unknown) > Part of profile(s): a2dp_sink, headset_head_unit > headset-input: Headset (type: Headset, priority: 0, latency offset: 0 usec, > not available) > Part of profile(s): headset_head_unit Hi Chad, You are running pulseaudio-14.2 so your problem is not related to bug #993011 Please check which bluetooth profiles your headset supports using 'bluetoothctl info F4:4E:FC:22:A0:0A' with headset connected. There are two bluetooth profiles which provide mic, HSP is indicated as "UUID: Headset (1108-..." and HFP is indicated as "UUID: Handsfree (111e-..." If your headset only lists HFP then pulseaudio-14.2 needs a properly configured oFono to connect with mic. With pulseaudio 15.0 oFono is no longer necessary so you might want to consider upgrading pulseaudio. If your headset also has HSP then it should work with both pulseaudio 14.2 and 15.0; if it does not I'd suggest you file an issue on pulseaudio tracker and provide output of 'bluetoothctl info' here https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/issues
Bug#995046: 3.2.3-7 fails with libc6-2.30
Package: rsync
Version: 3.2.3-7
Severity: important
Hello. After last update of Debian/testing (bookworm/sid) with rsync 3.2.3-4
to rsync-3.2.3-7, new version can't change file attributes. Example:
# rsync -va /etc/ld.so.cache /tmp
sending incremental file list
ld.so.cache
rsync: [receiver] failed to set permissions on "/tmp/.ld.so.cache.hvkXg2":
Function not implemented (38)
Proper permissions for file are not set.
Rsync 3.2.3-4 on the same system works good.
Ltrace for rsync-3.2.3-7 shows call to non-implemented function "lchmod":
[pid 5535] __lxstat(1, ".ld.so.cache.Hhy5UI", 0x7ffe8558e790
[pid 5535] SYS_lstat(".ld.so.cache.Hhy5UI", 0x7ffe8558e790) = 0
[pid 5535] <... __lxstat resumed> ) = 0
[pid 5535] utimensat(0xff9c, 0x7ffe85590a00, 0x7ffe8558e700, 256
[pid 5535] SYS_utimensat(0xff9c, 0x7ffe85590a00, 0x7ffe8558e700, 256) = 0
[pid 5535] <... utimensat resumed> ) = 0
[pid 5535] lchmod(0x7ffe85590a00, 420, 0x7ffe8558e700, 0)=
0x
___^^___
[pid 5535] __errno_location()=
0x7fc937826480
[pid 5535] __asprintf_chk(0x55c1a1db93d8, 1, 0x55c1a1d8e0cf, 0x55c1a1db8360) =
29
[pid 5535] __errno_location()=
0x7fc937826480
[pid 5535] __snprintf_chk(0x7ffe8558d270, 5120, 1, 5120) = 18
[pid 5535] __vsnprintf_chk(0x7ffe8558d282, 5102, 1, -1) = 58
[pid 5535] strerror(38) =
"Function not implemented"
[pid 5535] __snprintf_chk(0x7ffe8558d2bc, 5044, 1, -1) = 32
[pid 5535] memcpy(0x55c1a3b57924, "rsync: [receiver] failed to set permissions
on "/rz/etc/.ld.so.cache.Hhy5UI": Function not implemented (38)\n", 108) =
0x55c1a3b57924
List of packages for rsync-3.2.3-7 on broken system are:
||/ Name Version Architecture Description
+++--===--===
ii libacl1:amd642.3.1-1 amd64access control list - shared
library
ii libc6:amd64 2.30-4 amd64GNU C Library: Shared
libraries
ii liblz4-1:amd64 1.9.3-2 amd64Fast LZ compression algorithm
library - runtime
ii libpopt0:amd64 1.18-3 amd64lib for parsing cmdline
parameters
ii libssl1.1:amd64 1.1.1l-1amd64Secure Sockets Layer toolkit
- shared libraries
ii libxxhash0:amd64 0.8.0-2 amd64shared library for xxhash
ii libzstd1:amd64 1.4.8+dfsg-2.1 amd64fast lossless compression
algorithm
ii lsb-base 11.1.0 all Linux Standard Base init
script functionality
ii zlib1g:amd64 1:1.2.11.dfsg-2 amd64compression library - runtime
Upgrade libc6 to 2.32-4 solves the problem.
I suspect that lchmod() function appears in libc6-2.31 (or in some other
library), but dependency list for rsync mentions "libc6 (>= 2.15)".
Probably it should be corrected.
--
Eugene Berdnikov
Bug#994453: linux-image-5.14.0-trunk-amd64: Kernel hangs at loading initramfs Ryzon based laptop
Control: severity -1 important On Thu, Sep 16, 2021 at 10:23:53AM +0200, Gert Wollny wrote: > Package: src:linux > Version: 5.14.3-1~exp1 > Severity: critical > Justification: breaks the whole system No, it does not. The kernel is the system. Bastian
Bug#995021: osmnx: autopkgtest regression on armhf: iteration over a 0-d array
Hello Paul, thanks for pointing out the issue.
I will try to have a look this week-end.
Cheers,
Jerome
On 24/09/2021 22:23, Paul Gevers wrote:
Source: osmnx
Version: 1.1.1+ds-2
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: regression
Dear maintainer(s),
With a recent upload of osmnx the autopkgtest of osmnx fails in testing
on armhf when that autopkgtest is run with the binary packages of osmnx
from unstable. It passes when run with only packages from testing. In
tabular form:
passfail
osmnx from testing1.1.1+ds-2
all others from testingfrom testing
I copied some of the output at the bottom of this report. On top of the
failure, you test seems to be sending requests to the internet, please
use the needs-internet restriction [0] to mark is as such.
Currently this regression is blocking the migration to testing [1]. Can
you please investigate the situation and fix it?
More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation
Paul
[0]
https://salsa.debian.org/ci-team/autopkgtest/-/blob/master/doc/README.package-tests.rst
[1] https://qa.debian.org/excuses.php?package=osmnx
https://ci.debian.net/data/autopkgtest/testing/armhf/o/osmnx/15474259/log.gz
=== FAILURES
===
test_elevation
multiprocessing.pool.RemoteTraceback:
"""
Traceback (most recent call last):
File "/usr/lib/python3.9/multiprocessing/pool.py", line 125, in worker
result = (True, func(*args, **kwds))
File "/usr/lib/python3.9/multiprocessing/pool.py", line 51, in starmapstar
return list(itertools.starmap(args[0], args[1]))
File
"/tmp/autopkgtest-lxc.2hzrzn35/downtmp/build.elV/src/osmnx/elevation.py", line
49, in _query_raster
return zip(nodes.index, values)
TypeError: iteration over a 0-d array
"""
The above exception was the direct cause of the following exception:
def test_elevation():
G = ox.graph_from_address(address=address, dist=500,
dist_type="bbox", network_type="bike")
rasters = list(Path("tests/input_data").glob("elevation*.tif"))
# add node elevations from a single raster file (some nodes will
be null)
G = ox.elevation.add_node_elevations_raster(G, rasters[0], cpus=1)
# add node elevations from multiple raster files
G = ox.elevation.add_node_elevations_raster(G, rasters)
/usr/share/doc/python-osmnx-doc/examples/tests/test_osmnx.py:201:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _
osmnx/elevation.py:98: in add_node_elevations_raster
results = sma.get()
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _
self = , timeout = None
def get(self, timeout=None):
self.wait(timeout)
if not self.ready():
raise TimeoutError
if self._success:
return self._value
else:
raise self._value
E TypeError: iteration over a 0-d array
/usr/lib/python3.9/multiprocessing/pool.py:771: TypeError
--
Jerome BENOIT | calculus+at-rezozer^dot*net
https://qa.debian.org/developer.php?login=calcu...@rezozer.net
AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B
OpenPGP_signature
Description: OpenPGP digital signature
Bug#995047: /usr/share/initramfs-tools/hooks/mdadm: efivars module was renamed to efivarfs
Package: mdadm
Version: 4.2~rc2-6
Severity: normal
File: /usr/share/initramfs-tools/hooks/mdadm
Tags: patch
Dear Maintainer,
during boot I get a message about the "efivars" module not being found.
This happens during initramfs. While looking at:
/usr/share/initramfs-tools/hooks/mdadm
it seems the fix is simple enough:
---
--- /usr/share/initramfs-tools/hooks/mdadm.orig 2021-09-25 10:55:53.198883823
+0200
+++ /usr/share/initramfs-tools/hooks/mdadm 2021-09-24 22:45:33.090345701
+0200
@@ -66,7 +66,7 @@ for module in linear multipath raid0 rai
done
# load efivars for Intel RST IMSM, see Bug#962844
-force_load efivars || true
+force_load efivarfs || true
# copy the mdadm configuration
CONFIG=/etc/mdadm/mdadm.conf
---
Apparently, someone took the time do document when the change happened
(>=5.10.1-1~exp1):
https://michael-prokop.at/blog/2021/06/09/efivars-is-gone-with-debian-bullseye-
newinbullseye/
This would mean that this could be backported to bullseye maybe?
-- Package-specific info:
IMPORTANT:
please do not forget to include all relevant system information with this
bug report. You could run
/usr/share/bug/mdadm/script 3>&1
as root and attach or include the output.
-- System Information:
Debian Release: bookworm/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, powerpc, mips, arm64
Kernel: Linux 5.15.0-rc2-wt+ (SMP w/8 CPU threads)
Locale: LANG=en_DE.UTF-8, LC_CTYPE=C.UTF-8 (charmap=locale: Cannot set
LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
UTF-8), LANGUAGE=en_US:en
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)
Versions of packages mdadm depends on:
ii debconf [debconf-2.0] 1.5.77
ii init-system-helpers1.60
ii libc6 2.32-4
ii libudev1 247.9-2
ii lsb-base 11.1.0
ii udev 247.9-2
Versions of packages mdadm recommends:
ii exim4-daemon-light [mail-transport-agent] 4.95~RC2-1
ii kmod 29-1
Versions of packages mdadm suggests:
pn dracut-core
-- Configuration Files:
/etc/logcheck/ignore.d.server/mdadm [Errno 13] Permission denied:
'/etc/logcheck/ignore.d.server/mdadm'
/etc/logcheck/violations.d/mdadm [Errno 13] Permission denied:
'/etc/logcheck/violations.d/mdadm'
-- debconf information:
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = "en_US:en",
LC_ALL = (unset),
LC_CTYPE = "C.UTF-8",
LANG = "en_DE.UTF-8"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
mdadm/autostart: true
mdadm/initrdstart_msg_errmd:
mdadm/start_daemon: true
mdadm/mail_to: root
* mdadm/initrdstart: all
mdadm/initrdstart_msg_errconf:
mdadm/initrdstart_msg_errexist:
mdadm/autoscan: true
mdadm/autocheck: true
mdadm/initrdstart_notinconf: false
mdadm/initrdstart_msg_intro:
mdadm/initrdstart_msg_errblock:
-- debsums errors found:
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = "en_US:en",
LC_ALL = (unset),
LC_CTYPE = "C.UTF-8",
LANG = "en_DE.UTF-8"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
debsums: changed file /usr/share/initramfs-tools/hooks/mdadm (from mdadm
package)
--- /usr/share/initramfs-tools/hooks/mdadm.orig 2021-09-25 10:55:53.198883823
+0200
+++ /usr/share/initramfs-tools/hooks/mdadm 2021-09-24 22:45:33.090345701
+0200
@@ -66,7 +66,7 @@ for module in linear multipath raid0 rai
done
# load efivars for Intel RST IMSM, see Bug#962844
-force_load efivars || true
+force_load efivarfs || true
# copy the mdadm configuration
CONFIG=/etc/mdadm/mdadm.conf
Bug#994664: Updating the vrms Uploaders list
Dear Mattia, On Sun, Sep 19, 2021 at 10:11:21AM +0200, Mattia Rizzolo wrote: > Rogério Brito has retired, so can't work on > the vrms package anymore (at least with this address). sigh. he actually died of Covid19. Could you please try to make sure for future deaths that you maybe choose a different wording? (no idea how to accomplish this in practice, but maybe you have one?) (and no offense or anything taken. rather, thanks for doing the MIA job. just pointing this out, as others in other circumstances could be offended or hurt to receive such a mail.) > We are tracking their status in the MIA team and would like to ask you > to remove them from the Uploaders list of the package so we can close > that part of the file. will do. and, rest in power, Rogério! -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ This is the year of gpg on the desktop! (Gunnar Wolf) signature.asc Description: PGP signature
Bug#992777: linux-image-5.10.0-0.bpo.8-amd64: does not raise ethernet interface Intel Corporation 82579LM Gigabit Network Connection (rev 04)
Hi, Salvatore, On Sun 2021-09-05 20.52.49, Salvatore Bonaccorso wrote: In the excerpt of the above log I do not see a related entry for the enp0s25 interface, which seems present according your other attached information. Can you attach the full build log to get a picture on it? Unfortunately I am not quite sure what to attach as I am using the precompiled kernel distributed by Debian (through Buster Backports, I think). Regards, Axel signature.asc Description: PGP signature
Bug#994762: warnings about session IDs
control: tag -1 upstream,help Thanks for your report! On Mon, 2021-09-20 at 11:42 -0400, Antoine Beaupre wrote: > I'm not sure how to use this program. FWIW I use it by launching from my .i3/config with: exec --no-startup-id exec xss-lock --transfer-sleep-lock -- i3lock -d --color 00 Which desktop env are you using? > I have tried to start it from > systemd using the `.service` file provided by the package, but this > fails with: > > sep 20 11:38:29 curie xss-lock[3803849]: Error getting session: > GDBus.Error:org.freedesktop.login1.NoSessionForPID: Caller does not > belong to any known session. > > When inspecting the service, the GRAPHICAL_SESSION_ID variable is not > actually set. In fact the only hit online is your bugreport AFAICT. I wonder if the author of that service file used it as a placeholder to be replaced with something specific to the actual environment or if it was something they arranged locally some other way? Have you tried just removing that bit of the service file? `-s` is documented as `Use the session **ID** instead of the current session.` so maybe it'll just DTRT? > > I have tried to run it from a xterm using: > > /usr/bin/xss-lock -l -n /usr/lib/xsecurelock/dimmer -- > xsecurelock > > and this fails with: > > ** (xss-lock:3806201): WARNING **: 11:41:13.273: Error getting > session: GDBus.Error:org.freedesktop.login1.NoSessionForPID: PID > 3806201 does not belong to any known session Hrm, I don't see those, perhaps it is desktop or session manager specific somehow. I'm using i3 under lightdm. > Somehow it still seems to work, however, so I'm not sure what to do > with those warnings... Me neither and I'm afraid upstream[0] has been dormant for several years so I'm rather reliant on contributions for issues people see which I don't. Perhaps https://bitbucket.org/raymonad/xss-lock/issues/13/allow-operation-as-systemd-user-unit#comment-45869112 is useful, since they appear to be the author of the `-s` feature. And https://bitbucket.org/raymonad/xss-lock/issues/13/allow-operation-as-systemd-user-unit#comment-46751262 then suggests using $XDG_SESSION_ID (but makes reference to having to export it somehow...). Worth a try I suppose, please let me know if it works and I'll update the service file in the package. Out-of-interest how does one go about activating the service file for your user, I suppose you copy it to ~/.config somewhere or pass it to some systemctl command -- it'd be great if I could add some instructions to the docs. Cheers, Ian. [0] https://bitbucket.org/raymonad/xss-lock/
Bug#995048: Alt+Up does not go to parent directory
Package: pcmanfm Version: 1.3.1-1 In the menu _Go_, there is an option, Parent Folder (alt+up). This hotkey does not work. The choice of alt+up is a good one for the parent functionality. It complements the alt+left and alt+right hotkeys; it is consistent with Windows explorer. Recommended fix: implement alt+up as a hotkey for the go-to-parent functionality.
Bug#992777: linux-image-5.10.0-0.bpo.8-amd64: does not raise ethernet interface Intel Corporation 82579LM Gigabit Network Connection (rev 04)
Hi Axel, On Sat, Sep 25, 2021 at 11:25:28AM +0200, Dr. Axel Stammler wrote: > Hi, Salvatore, > > On Sun 2021-09-05 20.52.49, Salvatore Bonaccorso wrote: > > > In the excerpt of the above log I do not see a related entry for the > > enp0s25 interface, which seems present according your other attached > > information. > > > > Can you attach the full build log to get a picture on it? > > Unfortunately I am not quite sure what to attach as I am using the > precompiled kernel distributed by Debian (through Buster Backports, > I think). I'm sorry for that, but I just typoed what i wanted to write, I meant boot log. Regards, Salvatore
Bug#992609: careless upload of Erlang v24 without a transition tracking with the release team (was: rabbitmq-server fails to start after erlang v24 update)
On Fri, Aug 27, 2021 at 10:26:39PM +0200, Paul Gevers wrote: > Hi, > > Sorry my previous message was weird. > > On 27-08-2021 22:11, Paul Gevers wrote: > > On 27-08-2021 21:58, Antonio Terceiro wrote: > >> One thing that happens when you do this type of change without > >> coordination is that all CI pipelines on unstable where rabbitmq-server > >> is installed are now broken. For example all merge requests against > >> debci at the moment have their tests in "failed" status. This creates > >> unnecessary noise for a lot of people. > > > > rabbitmq-server already got an update, so unstable should be fine (if > > not, shout (or better, file bugs)). I expect you mean testing, as I > > think that the point is that erlang already migrated before the issue > > was detected, otherwise an RC bug would have prevented the migration. > > > > That's why it was suggested earlier that rabbitmq-server should grow an > > autopkgtest as that have would prevented the migration. > > What I should have said: > we could have prevented migration of erlang until the reverse > dependencies were ready by having an RC bug on erlang. That would have > been totally appropriate if it would have lasted an reasonable time. I > *think* rabbitmq-server has problems migrating now *because* erlang > migrated, but that should clear up once the references are tested again. > However, it *also* has issues with being uninstallable. FWIW, I just did that: I made a new rabbitmq-server upload adding a superficial autopkgtest to rabbitmq-server that just checks if the service is running after installation. This should avoid testing being broken because erlang migrated before rabbitmq-server has been fixed. signature.asc Description: PGP signature
Bug#994969: jackd2: segfaults after today's upgrade of other Debian testing packages
Control: tags -1 - moreinfo
On Fri, 24 Sep 2021 21:46:57 +0200 Sebastian Ramacher wrote:
[...]
> I haven't tried that yet, but otherwise you can always install -dbgsym
> packages until all symbols are resolved.
I have just tried.
Not sure the Debuginfod method worked fine enough, but here's what I
did.
I first re-installed jackd2-firewire:
# aptitude install jackd2-firewire+M
The following NEW packages will be installed:
jackd2-firewire{a} libconfig++9v5{a} libffado2{a} libxml++2.6-2v5{a}
0 packages upgraded, 4 newly installed, 0 to remove and 0 not upgraded.
[...]
Then, as a regular user:
$ export DEBUGINFOD_URLS="https://debuginfod.debian.net";
$ gdb -batch -n -ex 'set pagination off' -ex run -ex bt -ex 'bt full' -ex
'thread apply all bt full' --args jackd --realtime -d alsa --device hw:PCH
--softmode --hwmeter --rate 44100 > jackd_bt.out 2>&1
The output file is attached (compressed with xz).
I am not familiar with jackd source code, hence I do not fully grasp
the backtrace, but I seem to understand that the segfault definitely
has something to do with some dl_open related to jackd2-firewire and
the libglibmm-2.4-1v5 package.
As I said in another message, jackd works flawlessly, as soon as I
purge jackd2-firewire .
Have you had a chance to try and reproduce the bug with jackd2-firewire
installed (assuming that you had previously tried without that package)?
P.S.: I dropped the moreinfo tag from the bug report, as I think I
provided the requested additional information. Needless to say, feel
free to re-add the tag, in case you need anything more!
--
http://www.inventati.org/frx/
There's not a second to spare! To the laboratory!
. Francesco Poli .
GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE
jackd_bt.out.xz
Description: application/xz
pgp9iwMGD64Kl.pgp
Description: PGP signature
Bug#995049: p11-kit: FTBFS on hurd-i386
Source: p11-kit Version: 0.24.0-2 Severity: important Tags: patch User: debian-h...@lists.debian.org debian-k...@lists.debian.org Usertags: hurd Hi, Currently p11-kit FTBFS on GNU/Hurd due to a missing implementation in common/unix-peer.c. Fortunately the function getpeereid() is available in the libbsd library. The same function is also available for kFreeBSD. The patch debian_control.diff adds a build dependency of libbsd0 for kFreeBSD and Hurd. configure.ac.diff adds the bsd library, while common_unix_peer.diff adds the declaration of the function getpeereid(). This is added so that the header file bsd/unistd.h is not necessarily included (which conflicts with parts of unistd.h). Note that with the attached patches the patch, 41_kfreebsd_LOCAL_PEERCRED.diff, for kFreeBSD is no longer needed. The patches have been used to successfully build p11-kit on Linux, Hurd and kFreeBSD. Thanks! Index: p11-kit-0.24.0-2.3/common/unix-peer.c === --- p11-kit-0.24.0-2.3.orig/common/unix-peer.c +++ p11-kit-0.24.0-2.3/common/unix-peer.c @@ -47,6 +47,11 @@ # include #endif +#ifdef HAVE_GETPEEREID +/* Declare getpeereid from /usr/include/bsd/unistd.h */ +extern int getpeereid(int s, uid_t *euid, gid_t *egid); +#endif + /* Returns the unix domain socket peer information. * Returns zero on success. */ @@ -73,7 +78,8 @@ p11_get_upeer_id (int cfd, uid_t *uid, u *pid = cr.pid; #elif defined(HAVE_GETPEEREID) - /* *BSD/MacOSX */ + /* *BSD/MacOSX/kFreeBSD/Hurd */ + uid_t euid; gid_t egid; Index: p11-kit-0.24.0-2.3/configure.ac === --- p11-kit-0.24.0-2.3.orig/configure.ac +++ p11-kit-0.24.0-2.3/configure.ac @@ -132,6 +132,16 @@ if test "$os_unix" = "yes"; then AC_CHECK_FUNCS([getpeereid]) AC_CHECK_FUNCS([getpeerucred]) AC_CHECK_FUNCS([issetugid]) + case "$host_os" in + kfreebsd*-gnu | gnu*) + have_getpeereid=no + AC_CHECK_LIB(bsd, getpeereid, have_getpeereid=yes) + if test "x$have_getpeereid" = "xyes"; then + AC_DEFINE([HAVE_GETPEEREID], [1], [have getpeereid]) + AC_SEARCH_LIBS([getpeereid], [bsd]) + fi + ;; + esac AC_CACHE_CHECK([for thread-local storage class], [ac_cv_tls_keyword], --- a/debian/control 2021-06-20 14:49:24.0 +0200 +++ b/debian/control 2021-09-25 01:02:28.693455906 +0200 @@ -7,7 +7,8 @@ gtk-doc-tools, libffi-dev, libtasn1-6-dev, - pkg-config + pkg-config, + libbsd0 [kfreebsd-any hurd-any] Standards-Version: 4.5.1 Rules-Requires-Root: no Section: libs
Bug#994969: jackd2: segfaults after today's upgrade of other Debian testing packages
Control: tags -1 =
Control: reassign -1 libglibmm-2.4-1v5 2.66.1-1
On 2021-09-25 12:03:54 +0200, Francesco Poli wrote:
> Control: tags -1 - moreinfo
>
>
> On Fri, 24 Sep 2021 21:46:57 +0200 Sebastian Ramacher wrote:
>
> [...]
> > I haven't tried that yet, but otherwise you can always install -dbgsym
> > packages until all symbols are resolved.
>
> I have just tried.
> Not sure the Debuginfod method worked fine enough, but here's what I
> did.
> I first re-installed jackd2-firewire:
>
> # aptitude install jackd2-firewire+M
> The following NEW packages will be installed:
> jackd2-firewire{a} libconfig++9v5{a} libffado2{a} libxml++2.6-2v5{a}
> 0 packages upgraded, 4 newly installed, 0 to remove and 0 not upgraded.
> [...]
>
> Then, as a regular user:
>
> $ export DEBUGINFOD_URLS="https://debuginfod.debian.net";
> $ gdb -batch -n -ex 'set pagination off' -ex run -ex bt -ex 'bt full' -ex
> 'thread apply all bt full' --args jackd --realtime -d alsa --device hw:PCH
> --softmode --hwmeter --rate 44100 > jackd_bt.out 2>&1
The relevant part seems to be:
Thread 1 "jackd" received signal SIGSEGV, Segmentation fault.
__strcmp_avx2 () at ../sysdeps/x86_64/multiarch/strcmp-avx2.S:101
Download failed: Invalid argument. Continuing without source file
./string/../sysdeps/x86_64/multiarch/strcmp-avx2.S.
101 ../sysdeps/x86_64/multiarch/strcmp-avx2.S: Inappropriate ioctl for
device.
#0 __strcmp_avx2 () at ../sysdeps/x86_64/multiarch/strcmp-avx2.S:101
#1 0x76bc4b19 in g_str_equal () from
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#2 0x76bc3563 in g_hash_table_lookup () from
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#3 0x76be674a in g_quark_from_static_string () from
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#4 0x76dfdbb0 in ?? () from
/usr/lib/x86_64-linux-gnu/libglibmm-2.4.so.1
#5 0x77fe210e in call_init (l=, argc=argc@entry=10,
argv=argv@entry=0x7fffe168, env=env@entry=0x7fffe1c0) at dl-init.c:74
#6 0x77fe21f0 in call_init (env=0x7fffe1c0, argv=0x7fffe168,
argc=10, l=) at dl-init.c:37
#7 _dl_init (main_map=0x5557ae80, argc=10, argv=0x7fffe168,
env=0x7fffe1c0) at dl-init.c:121
#8 0x77b41b6d in __GI__dl_catch_exception (exception=,
operate=, args=) at dl-error-skeleton.c:182
#9 0x77fe6484 in dl_open_worker (a=a@entry=0x7fffd3d0) at
dl-open.c:783
#10 0x77b41b10 in __GI__dl_catch_exception (exception=0x7fffd3b0,
operate=0x77fe60e0 , args=0x7fffd3d0) at
dl-error-skeleton.c:208
#11 0x77fe5d0a in _dl_open (file=0x7fffd3b0
"\340\323\377\377\377\177", mode=-2147483390, caller_dlopen=0x77f5f80c,
nsid=-2, argc=10, argv=0x7fffe168, env=0x7fffe1c0) at dl-open.c:864
#12 0x77817258 in dlopen_doit (a=a@entry=0x7fffd600) at dlopen.c:66
#13 0x77b41b10 in __GI__dl_catch_exception
(exception=exception@entry=0x7fffd5a0, operate=0x77817200
, args=0x7fffd600) at dl-error-skeleton.c:208
#14 0x77b41bcf in __GI__dl_catch_error (objname=0x5557ccb0,
errstring=0x5557ccb8, mallocedp=0x5557cca8, operate=,
args=) at dl-error-skeleton.c:227
#15 0x77817a65 in _dlerror_run (operate=operate@entry=0x77817200
, args=args@entry=0x7fffd600) at dlerror.c:170
#16 0x778172e4 in __dlopen (file=, mode=)
at dlopen.c:87
#17 0x77f5f80c in ?? () from
/usr/lib/x86_64-linux-gnu/libjackserver.so.0
#18 0x77f60a8d in ?? () from
/usr/lib/x86_64-linux-gnu/libjackserver.so.0
#19 0x77f64f5e in jackctl_server_create2 () from
/usr/lib/x86_64-linux-gnu/libjackserver.so.0
#20 0x8111 in ?? ()
#21 0x77a31e4a in __libc_start_main (main=0x75b0, argc=10,
argv=0x7fffe168, init=, fini=,
rtld_fini=, stack_end=0x7fffe158) at ../csu/libc-start.c:314
So this is crashing somewhere during the initialization of libglibmm.
Hence I'm reassigning to libglibmm.
Cheers
>
> The output file is attached (compressed with xz).
>
> I am not familiar with jackd source code, hence I do not fully grasp
> the backtrace, but I seem to understand that the segfault definitely
> has something to do with some dl_open related to jackd2-firewire and
> the libglibmm-2.4-1v5 package.
>
> As I said in another message, jackd works flawlessly, as soon as I
> purge jackd2-firewire .
> Have you had a chance to try and reproduce the bug with jackd2-firewire
> installed (assuming that you had previously tried without that package)?
>
>
> P.S.: I dropped the moreinfo tag from the bug report, as I think I
> provided the requested additional information. Needless to say, feel
> free to re-add the tag, in case you need anything more!
>
> --
> http://www.inventati.org/frx/
> There's not a second to spare! To the laboratory!
> . Francesco Poli .
> GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE
--
Sebastia
Bug#995050: ecere-sdk FTBFS with gcc 10
Source: ecere-sdk Version: 0.44.15-1 Severity: serious Tags: ftbfs https://buildd.debian.org/status/logs.php?pkg=ecere-sdk&ver=0.44.15-1%2Bb4 ... gcc -Wl,-z,relro -Wl,--no-undefined -Wl,--no-undefined -Wl,--no-undefined -Wl,--no-undefined -L../ecere/obj/bootstrap.linux -L../libec/obj/bootstrap.linux obj/bootstrap.linux/ecp.o obj/bootstrap.linux/ecp.main.o-lecereBootstrap -lecBootstrap -lm -ldl -o obj/bootstrap.linux/ecp /usr/bin/ld: obj/bootstrap.linux/ecp.main.o:./compiler/bootstrap/ecp/bootstrap/ecp.main.c:52: multiple definition of `__ecereVMethodID___ecereNameSpace__ecere__sys__File_Eof'; obj/bootstrap.linux/ecp.o:./compiler/bootstrap/ecp/bootstrap/ecp.c:388: first defined here /usr/bin/ld: obj/bootstrap.linux/ecp.main.o:./compiler/bootstrap/ecp/bootstrap/ecp.main.c:54: multiple definition of `__ecereVMethodID___ecereNameSpace__ecere__sys__File_Puts'; obj/bootstrap.linux/ecp.o:./compiler/bootstrap/ecp/bootstrap/ecp.c:384: first defined here /usr/bin/ld: obj/bootstrap.linux/ecp.main.o:./compiler/bootstrap/ecp/bootstrap/ecp.main.c:56: multiple definition of `__ecereVMethodID___ecereNameSpace__ecere__sys__File_Read'; obj/bootstrap.linux/ecp.o:./compiler/bootstrap/ecp/bootstrap/ecp.c:390: first defined here /usr/bin/ld: obj/bootstrap.linux/ecp.main.o:./compiler/bootstrap/ecp/bootstrap/ecp.main.c:58: multiple definition of `__ecereVMethodID___ecereNameSpace__ecere__sys__File_Seek'; obj/bootstrap.linux/ecp.o:./compiler/bootstrap/ecp/bootstrap/ecp.c:396: first defined here /usr/bin/ld: obj/bootstrap.linux/ecp.main.o:./compiler/bootstrap/ecp/bootstrap/ecp.main.c:60: multiple definition of `__ecereVMethodID___ecereNameSpace__ecere__sys__File_Write'; obj/bootstrap.linux/ecp.o:./compiler/bootstrap/ecp/bootstrap/ecp.c:392: first defined here ... /usr/bin/ld: ../libec/obj/bootstrap.linux/libecBootstrap.a(shortcuts.o):./compiler/bootstrap/libec/bootstrap/shortcuts.c:298: multiple definition of `__ecereVMethodID___ecereNameSpace__ecere__sys__File_Write'; obj/bootstrap.linux/ecp.o:./compiler/bootstrap/ecp/bootstrap/ecp.c:392: first defined here /usr/bin/ld: ../libec/obj/bootstrap.linux/libecBootstrap.a(shortcuts.o):./compiler/bootstrap/libec/bootstrap/shortcuts.c:300: multiple definition of `__ecereVMethodID___ecereNameSpace__ecere__sys__File_Seek'; obj/bootstrap.linux/ecp.o:./compiler/bootstrap/ecp/bootstrap/ecp.c:396: first defined here /usr/bin/ld: ../libec/obj/bootstrap.linux/libecBootstrap.a(type.o):./compiler/bootstrap/libec/bootstrap/type.c:392: multiple definition of `__ecereVMethodID___ecereNameSpace__ecere__sys__File_Seek'; obj/bootstrap.linux/ecp.o:./compiler/bootstrap/ecp/bootstrap/ecp.c:396: first defined here collect2: error: ld returned 1 exit status make[4]: *** [Makefile:101: obj/bootstrap.linux/ecp] Error 1
Bug#995051: python3.9: FTBFS on i386: test timeout
Source: python3.9 Version: 3.9.7-4 Severity: serious Tags: ftbfs sid bookworm Justification: fails to build from source (but built successfully in the past) X-Debbugs-Cc: sramac...@debian.org Control: block 994560 by -1 python3.9 fails to build on i386 due to tests that timeout: | 0:27:34 load avg: 0.91 [398/407/2] test_xmlrpc_net skipped (resource denied) | | test_xmlrpc_net skipped -- Use of the 'network' resource not enabled | | 0:27:34 load avg: 0.91 [399/407/2] test_xxtestfuzz passed | | 0:27:35 load avg: 0.92 [400/407/2] test_yield_from passed | | 0:27:35 load avg: 0.92 [401/407/2] test_zipapp passed | | 0:28:02 load avg: 0.95 [402/407/2] test_zipfile passed | | 0:28:03 load avg: 0.95 [403/407/2] test_zipfile64 skipped (resource denied) | | test_zipfile64 skipped -- test requires loads of disk-space bytes and a long time to run | | 0:28:03 load avg: 0.95 [404/407/2] test_zipimport passed | | 0:28:05 load avg: 0.95 [405/407/2] test_zipimport_support passed | | 0:28:06 load avg: 0.95 [406/407/2] test_zlib passed | | 0:28:07 load avg: 0.95 [407/407/2] test_zoneinfo passed | | E: Build killed with signal TERM after 150 minutes of inactivity https://buildd.debian.org/status/fetch.php?pkg=python3.9&arch=i386&ver=3.9.7-4&stamp=1632563540&raw=0 Cheers -- Sebastian Ramacher signature.asc Description: PGP signature
Bug#994275: Reverting breaking changes in debianutils
On Sat, 25 Sep 2021 at 02:22:44 +, Clint Adams wrote: > * debianutils gets closer to achieving its mission, by having >one fewer irrelevant utility that does not belong This seems a good opportunity to ask what I think is a key question here: what do you consider debianutils' mission to be? smcv
Bug#995052: ITP: python-suitesparse-graphblas -- Python CFFI binding around SuiteSparse:GraphBLAS
Package: wnpp X-Debbugs-Cc: debian-pyt...@lists.debian.org, debian-scie...@lists.debian.org Owner: Vincent Prat Severity: wishlist * Package name : python-suitesparse-graphblas Version : 5.1.7.0 Upstream Author : Michel Pelletier , James Kitchen , Erik Welch * URL : https://github.com/GraphBLAS/python-suitesparse-graphblas * License : Apache License 2.0 Programming Lang: Python Description : Python CFFI binding around SuiteSparse:GraphBLAS This is a base package that exposes only the low level CFFI API bindings and symbols. This package is shared by the syntax bindings pygraphblas and grblas. This package is a dependency for pygraphblas, which I use. I plan to maintain it inside the Science Team. I am not looking for co-maintainers and I do not need a sponsor.
Bug#995053: dh_assistant command for listing installed files
Package: debhelper
Version: 13.5.2
Severity: wishlist
Dear debhelper maintainers,
For lintian-brush, it would be really useful if it was possible to discover
which patterns it would be installing, why and where.
I have no idea how hard this would be to implement, and whether this
information is readily available in debhelper - but figured it's at least worth
starting the discussion and seeing where it goes. I suspect there are some
corner cases where it's impossible to discover like where dh-exec is in use
(but even some information would be great).
I imagine something like a "dh_assistant installed-files" that then reports:
[
{
'install_path': '/usr/share/man/man1/blah.1',
'tool': 'dh_installman',
'tool_config': 'debian/blah.manpages',
'source_path': 'debian/blah.1',
},
{
'install_path': '/usr/bin/blah',
'tool': 'dh_install',
'source_path': 'scripts/blah',
},
{
'install_path': '/usr/lib/*',
'tool': 'dh_install',
'source_path': 'debian/tmp/usr/lib/*',
},
...
]
-- System Information:
Debian Release: bookworm/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 5.10.0-8-amd64 (SMP w/2 CPU threads)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages debhelper depends on:
ii autotools-dev20180224.1+nmu1
ii dh-autoreconf20
ii dh-strip-nondeterminism 1.12.0-1
ii dpkg 1.20.9
ii dpkg-dev 1.20.9
ii dwz 0.14-1
ii file 1:5.39-3
ii libdebhelper-perl13.5.2
ii libdpkg-perl 1.20.9
ii man-db 2.9.4-2
ii perl 5.32.1-5
ii po-debconf 1.0.21+nmu1
debhelper recommends no packages.
Versions of packages debhelper suggests:
pn dh-make
-- no debconf information
Bug#990122: base-passwd: please support DPKG_ROOT in preinst and postinst
Hi Colin, Quoting Colin Watson (2021-09-24 23:03:12) > On Fri, Sep 24, 2021 at 08:18:23AM +0200, Johannes Schauer Marin Rodrigues > wrote: > > Quoting Johannes Schauer Marin Rodrigues (2021-08-20 17:42:02) > > > Quoting Johannes Schauer Marin Rodrigues (2021-06-21 13:28:05) > > > > Please consider applying the attached patch (post bullseye). We tested > > > > the > > > > patch using the scripts at > > > > https://salsa.debian.org/helmutg/dpkg-root-demo > > > > and can show that a chroot created that way is bit-by-bit identical to > > > > one > > > > that was created normally. > > > > > > for your convenience, I created a MR on salsa that implements the fix to > > > this > > > bug: > > > > > > https://salsa.debian.org/debian/base-passwd/-/merge_requests/9 > > > > would you mind me applying the above merge request and doing an NMU > > base-passwd? > > Sorry for the delay. I've just uploaded it myself. thanks a lot! I dropped the base-passwd patch from our CI job and the test remains green: https://salsa.debian.org/helmutg/dpkg-root-demo/-/jobs Once you find some time, you could have a look at my debconf merge request: https://salsa.debian.org/pkg-debconf/debconf/-/merge_requests/8 Thank you! :) cheers, josch signature.asc Description: signature
Bug#994560: Bug#995032: GNOME components segfault as a result of libffi transition
Control: retitle 995032 GNOME components segfault as a result of libffi transition On Sat, 25 Sep 2021 at 03:48:20 -0400, Jeremy Bicha wrote: > On Sat, Sep 25, 2021 at 12:30 AM Michael Ott wrote: > > The problem is not gnome-shell. It is the gobject-introspection. > > After downgrade this packages from 1.70.0-1+b1 to 1.70.0-1 it works > > again. > > gobject-introspection was rebuilt as part of the libffi transition. > (That's where the +b1 part of the version name comes from.) The > transition is still in progress. Maybe the problem is that you didn't > have the rebuilt gjs installed? > > The rebuilt gjs is version 1.68.4-1+b1 > > Here's the list of other packages involved in the transition: > https://release.debian.org/transitions/html/auto-libffi.html Last time we had a libffi transition, in early 2020, we ended up sprinkling versioned Breaks throughout GNOME to force the whole system to be either "old libffi" or "new libffi". This is because some GNOME components, notably gobject-introspection, have libffi data structures in their public API, so in partial upgrades we get one library passing an old-libffi data structure to another library that expects a new-libffi data structure, and crashes. See the gobject-introspection 1.62.0-4 and -5 changelogs for part of what we had to do to fix this. If libffi is going to continue to break ABI somewhat regularly, then I think we are going to need a more systematic way to prevent broken partial upgrades, and it would be very helpful for the libffi maintainer and the release team to keep this failure mode in mind when allocating transition slots (for example doing libffi transitions when there is not a new major version of GLib trying to migrate, as there is at the moment). smcv
Bug#994970: SSHD stops to work randomly
Control: reassign -1 openssh-server 1:7.9p1-10+deb10u2 On Vi, 24 sep 21, 09:20:05, Adrian Meier wrote: > Package: SSHD > Version: OpenSSH_7.9p1 Debian-10+deb10u2, OpenSSL 1.1.1d 10 Sep 2019 > > There is no problem to start sshd. But randomly it stops to work and I cannot > login remotely anymore for any user. > I have to restart sshd and it works again: > > > > Content of /etc/ssh/sshd_config (uncomment part only) > PasswordAuthentication no > ChallengeResponseAuthentication no > Subsystem sftpinternal-sftp > > Match Group sftp_users > X11Forwarding no > AllowTcpForwarding no > ChrootDirectory %h > ForceCommand internal-sftp > > Match Group sshtunnel > X11Forwarding no > AllowTcpForwarding yes > AllowAgentForwarding no > ForceCommand /bin/false > > I am using Debian version 5.11.22-4-pve (build@proxmox) (gcc (Debian > 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #1 SMP > PVE 5.11.22-8 (Fri, 27 Aug 2021 11:51:34 +0200) > Its running as CT on ProxMox 7.0-11 Reassigning to correct package. Kind regards, Andrei -- Looking after bugs assigned to unknown or inexistent packages. signature.asc Description: PGP signature
Bug#995055: transition: glew
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition X-Debbugs-Cc: debian-de...@lists.debian.org This transition is triggered by an SONAME change upstream. It does not appear to have any API transition though, and seems to cause no glew-related failures. Ben file: title = "glew"; is_affected = .depends ~ "libglew2.1" | .depends ~ "libglew2.2"; is_good = .depends ~ "libglew2.2"; is_bad = .depends ~ "libglew2.1"; I've rebuilt all dependencies, with a number of unrelated FTBFS: Bugs have been submitted against all FTBFS. glew OK info-beamer : : change bd libglew1.5-dev -> libglew-dev OK phlipple: change bd libglew1.5-dev -> libglew-dev OK pymol: change bd libglew1.5-dev -> libglew-dev OK rlvm: change bd libglew1.5-dev -> libglew-dev OK asymptote: OK avogarolibs: OK ball: FTBFS (#994480) unrelated (glibc/ rpc header change) bino: OK blastem: OK blender: OK bzflag: OK casparcg-server (sid only): FTBFS (#947518) colmap: OK colobot: OK compiz-plugins-experimental: OK darkradiant: OK ddnet: OK dreamchess: OK endless-sky: OK fife: OK freeorion: OK frogatto (contrib): OK gambas3: OK gource: OK hugin: OK hyperrogue: OK k3d (sid only): FTBFS (python2 issues) kicad: OK limesuite: OK logstalgia: OK mediastreamer2: (FTFBS with gcc-11), OK megaglest : OK mesa-demos: OK mupen64plus-video-z64: OK mygui: OK open3d: OK openclonk: opencsg: OK openctm: OK openmsx:: OK otb: OK paraview: OK qutemol: OK rbdoom3bfg: OK renpy (sid only):FTBFS - needs python-sphinx rss-glx: OK scorched3d: OK slic3r-prusa OK slop: FTBFS (#994824) unrelated sludge: OK sofa-framework: FTBFS (#875184): QT4 removed spring: OK supertux: OK supertuxkart: OK trigger-rally: OK tulip: OK vice (contrib): FTBFS #994835 (jpeg support missing) vtk7: OK vtk9: OK warzone2100: OK widelands: OK cegui-mk2: OK meshlab; OK openscad: FTBFS (#994937) CGAL-related ? pcl:OK
Bug#983538: debomatic: trivial suggestions for the packaging
tags 983538 + pending fixed-upstream thanks Hi Nicolas, first of all, thanks a lot for your patches! Most of them were imported either upstream when relevant or in Salsa, with the exception of the following: 0003-Merge-paragraphs-files-in-d-copyright.patch * I prefer to keep holders separate, although it's not strictly required as you mentioned. 0005-Fix-license-GPL-3-no-later-version.patch * This is clarified upstream and will be part of the next release, so I skipped it for the time being. 0008-Improve-debian-tests-build-with-variables.patch * Although it makes sense, would it be possible to provide patches implementing the same approach for the other tests too? Thanks again! -- Cheers, Luca
Bug#994969: jackd2: segfaults after today's upgrade of other Debian testing packages
On Sat, Sep 25, 2021 at 6:25 AM Sebastian Ramacher wrote: > So this is crashing somewhere during the initialization of libglibmm. > Hence I'm reassigning to libglibmm. Sebastian, My first guess is that this is more fallout from the incomplete libffi transition. See https://bugs.debian.org/995032 Thanks, Jeremy Bicha
Bug#994453: Bug confirmation
On 24.09.2021 23:03, Vincent Blut wrote: Le 2021-09-24 16:44, Alexander Kernozhitsky a écrit : Hello, > Is it still reproducible when adding 'mem_encrypt=off' to the kernel command > line? with `mem_encrypt=off` parameter, the kernel boots fine. Thanks for testing, Alexander! Jens-Michael, Gert, how does your system behave when disabling AMD Secure Memory Encryption? With 'mem_encrypt=off' the kernel (5.14.6-2) boots fine. Thank you! -- Alexander Kernozhitsky Cheers, Vincent
Bug#995032: gnome-session segfaults - no GNOME session possible at all (white screen to contact the system administrator)
Am Samstag, dem 25.09.2021 um 03:48 -0400 schrieb Jeremy Bicha: > On Sat, Sep 25, 2021 at 12:30 AM Michael Ott wrote: > > The problem is not gnome-shell. It is the gobject-introspection. > > After downgrade this packages from 1.70.0-1+b1 to 1.70.0-1 it works > > again. Indeed, version 1.70.0-1+b1 had already been installed on the system. > gobject-introspection was rebuilt as part of the libffi transition. > (That's where the +b1 part of the version name comes from.) The > transition is still in progress. Maybe the problem is that you didn't > have the rebuilt gjs installed? > > The rebuilt gjs is version 1.68.4-1+b1 I checked the apt logs and it seems this version was pulled into my system only today and may have not been available at the time of writing the report. Now the system seems to work again. I agree with Simon. If possibe we should avoid such breakages (even in Sid). Regards, Daniel -- Regards, Daniel Leidert | https://www.wgdd.de/ GPG-Key RSA4096 / BEED4DED5544A4C03E283DC74BCD0567C296D05D GPG-Key ED25519 / BD3C132D8B3805D1808123AB7ACE00941E338C78 https://www.fiverr.com/dleidert https://www.patreon.com/join/dleidert signature.asc Description: This is a digitally signed message part
Bug#994598: dh_dwz: pass -l/-L options
On 25.09.21 09:20, Niels Thykier wrote: Hi Matthias, Did the above answer your question/request? Sorry for not replying sooner. Yes, thanks. -- -- Matthias Urlichs OpenPGP_signature Description: OpenPGP digital signature
Bug#995056: dgit claims that files changing mode from 644 to 755 can't be represented by 3.0 (quilt), but they can be and are.
Package: dgit Severity: important 9.14 fixed the issue of new executable files created by quilt patches, but it turns out it's also possible for a quilt patch to change the mode of an existing file. glibc is once again the offending package. dget -d https://deb.debian.org/debian/pool/main/g/glibc/glibc_2.32-4.dsc mkdir dgittest cd dgittest git init dgit setup-gitattributes dgit import-dsc ../glibc_2.32-4.dsc ..workingbranch git checkout workingbranch dgit -wgf build-source Format `3.0 (quilt)', need to check/update patch stack examining quilt state (multiple patches, linear mode) dgit: base trees orig=4d59020ee480820a8076 o+d/p=239fec377a9200f2d4e4 dgit: quilt differences: src: ## orig ## gitignores: == orig == dgit: quilt differences: HEAD == o+d/p HEAD == o+d/p dgit: cannot represent change: mode or type changed (100644->100755): sysdeps/x86_64/configure dgit: error: HEAD has changes to .orig[s] which are not representable by `3.0 (quilt)'
Bug#982091: Please include some yaml.nanorc
Op 08-02-2021 om 16:46 schreef Benno Schulenberg:
> But it's unclear what license covers the file -- the site says nothing
> about the yaml.nanorc.
I mailed the author but did not get a response. So this morning I
constructed my own yaml.nanorc file -- see attached.
What I'm quite pleased with is that the keys in this construct:
[key1, key2]: [value1, value2]
will get colored as keys (which Vim and Emacs don't do).
Please try the syntax out and see if you have any comments.
Benno
## Syntax highlighting for YAML files.
## Original author: Benno Schulenberg
## License: GPL version 3 or newer
syntax yaml "\.ya?ml$"
header "^---"
tabgives " "
comment "#"
# Keys:
color green "\<[[:alnum:]_-]+:( |$)"
color green "\[[[:alnum:]_-, ]+\]:( |$)"
color normal ": "
# Booleans, numbers, strings:
color lightmagenta ":
+(Y(es)?|No?|y(es)?|no?|[Tt]rue|[Ff]alse|[Oo](n|ff))(\]|\}|, | |$)"
color lightmagenta " [+-]?[0-9]+(\.[0-9]+)?(\]|\}|, | |$)"
color lightmagenta "("[^"]+"|'[^']+')"
color normal ", "
# Anchors and references:
color pink "(&|\*)[[:alnum:]]+( |$)"
# Symbols:
color bold,lagoon "^(---|\.\.\.)( |$)" " [|>](\+|-)?$"
color yellow "(^ *- |[]{}[])"
# Types:
color mint " !!(binary|bool|float|int|map|null|omap|seq|set|str)( |$)"
color lime " ![[:alnum:]_-]+( |$)"
# Missing space, trailing space, or tabs:
color ,red ":[^ ]| *$| "
# Comments:
color italic,cyan "(^| +)#.*"
OpenPGP_signature
Description: OpenPGP digital signature
Bug#994923:
Control: retitle 994923 dirsearch -- A CLI tool designed to brute force directories and files in webservers
Bug#994923:
Control: retitle 994923 ITP: dirsearch -- A CLI tool designed to brute force directories and files in webservers
Bug#994923:
Control: retitle 994923 ITP: dirsearch -- A CLI tool designed to bruteforce directories and files in webservers
Bug#994560: Bug#995032: GNOME components segfault as a result of libffi transition
On 2021-09-25 11:49:39 +0100, Simon McVittie wrote: > Control: retitle 995032 GNOME components segfault as a result of libffi > transition > > On Sat, 25 Sep 2021 at 03:48:20 -0400, Jeremy Bicha wrote: > > On Sat, Sep 25, 2021 at 12:30 AM Michael Ott wrote: > > > The problem is not gnome-shell. It is the gobject-introspection. > > > After downgrade this packages from 1.70.0-1+b1 to 1.70.0-1 it works > > > again. > > > > gobject-introspection was rebuilt as part of the libffi transition. > > (That's where the +b1 part of the version name comes from.) The > > transition is still in progress. Maybe the problem is that you didn't > > have the rebuilt gjs installed? > > > > The rebuilt gjs is version 1.68.4-1+b1 > > > > Here's the list of other packages involved in the transition: > > https://release.debian.org/transitions/html/auto-libffi.html > > Last time we had a libffi transition, in early 2020, we ended up > sprinkling versioned Breaks throughout GNOME to force the whole system > to be either "old libffi" or "new libffi". This is because some GNOME > components, notably gobject-introspection, have libffi data structures > in their public API, so in partial upgrades we get one library passing an > old-libffi data structure to another library that expects a new-libffi > data structure, and crashes. > > See the gobject-introspection 1.62.0-4 and -5 changelogs for part of what > we had to do to fix this. > > If libffi is going to continue to break ABI somewhat regularly, then I > think we are going to need a more systematic way to prevent broken partial > upgrades, and it would be very helpful for the libffi maintainer and the > release team to keep this failure mode in mind when allocating transition > slots (for example doing libffi transitions when there is not a new major > version of GLib trying to migrate, as there is at the moment). Regardless of future transitions of libffi, if glib and the introspection ecosystems are closely tied to the the libffi ABI, the affected packages need to express that with the proper dependencies. We have the same situation with boost and icu and boost and python3.X. If you implement a similar solution to that in boost, this would also allows us to track this via ben in a future libffi transition. Cheers -- Sebastian Ramacher signature.asc Description: PGP signature
Bug#995057: packages.debian.org does not resolve versioned provides
Package: www.debian.org Severity: important User: www.debian@packages.debian.org Usertags: packages Dear Maintainer, It seems that packages.debian.org does not resolve versioned provides Javascript (node-) is based on it so this a major problem for the javascript teams See instance https://packages.debian.org/en/sid/node-resolve Bastien
Bug#994923: (no subject)
Control: retitle 994923 ITP: dirsearch -- A CLI tool designed to bruteforce directories and files in webservers
Bug#994784: mpi4py breaks gyoto autopkgtest on i386: 1 process returned, a non-zero exit code
Control: found -1 gyoto/1.4.4-4 Control: found -1 gyoto/1.4.4-3 Control: notfound -1 gyoto/1.4.4-5 Hi Paul, Le 24/09/2021 à 21:42, Paul Gevers a écrit : > Is the workaround inside the binary, or only (needed) in the test suite? > In other words, did openmpi *break* gyoto on i386 in some cases? If yes, > Ideally openmpi is updated with a versioned Breaks on gyoto with the > right unfixed package. The migration software then will schedule the set > and the migration will happen if everything's fine. The workaround is only in the test suite. There remains a bug, either within openmpi or within gyoto but triggered by the new version of openmpi. Concerning gyoto, I would only rate it "normal" though, not "serious", if you can confirm that the workaround actually worked in the testing testbed. If this is the case, I would decrease the severity of the bug and keep it opened. It would be great if the openmpi mainainers could have a look, but I guess they will need a me to provide a minimal example which will not be easy to provide, unless they experience the same symptoms in other situations. Regards, Thibaut.
Bug#994969: jackd2: segfaults after today's upgrade of other Debian testing packages
On Sat, 25 Sep 2021 12:25:16 +0200 Sebastian Ramacher wrote: [...] > So this is crashing somewhere during the initialization of libglibmm. > Hence I'm reassigning to libglibmm. [...] Thanks, Sebastian! By the way, I am now wondering whether I really need jackd2-firewire. Maybe I can keep it out of my system, even after this bug gets fixed?!? I don't think I have a FireWire port, hence maybe the JACK FireWire support is useless to me. Could you please confirm? -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpgMqnF5HNPu.pgp Description: PGP signature
Bug#995058: gtk-vnc: Please package 1.2.0
Source: gtk-vnc Version: 1.0.0-1 Severity: wishlist Please package gtk-vnc 1.2.0. https://gitlab.gnome.org/GNOME/gtk-vnc/-/blob/master/NEWS Thanks, Jeremy Bicha
Bug#994923: (no subject)
Control: retitle 994923 ITP: dirsearch -- A CLI tool designed to bruteforce directories and files in webservers
Bug#994923: update ITP format
Control: retitle 994923 ITP: dirsearch -- A CLI tool designed to bruteforce directories and files in webservers
Bug#995043: Mustang.vim has colors_name = "mustang": case skewed
forcemerge 975683 995043 found 975683 20210124 On Sat, Sep 25, 2021 at 03:41:05PM +0900, Osamu Aoki wrote: > Hi as reported to PR on salsa. > > https://salsa.debian.org/vim-team/vim-scripts/-/merge_requests/3 > > This odd ball capitalized filename choice caused telescope generated > configuration to cause untriguiging errors. There is no reason for this > filename to be capitalized despite the overwhelming defact convention. I already fixed this once for #975683, but it looks like I accidentally reverted the change while working on other fixes. I'm going to merge this with #975683 and re-add the fix. Cheers, -- James GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7 2D23 DFE6 91AE 331B A3DB
Bug#995060: RFP: behave-html-formatter -- HTML formatter for Behave
Package: wnpp Severity: wishlist X-Debbugs-Cc: ber...@debian.org, team+pyt...@tracker.debian.org * Package name: behave-html-formatter Version : GIT Upstream Author : Peter Bittner * URL : https://github.com/behave-contrib/behave-html-formatter * License : GPL3 Programming Lang: python Description : HTML formatter for Behave I need this package to be able to run the installed tests of eog package
Bug#994560: Bug#995032: GNOME components segfault as a result of libffi transition
On Sat, 25 Sep 2021 at 15:01:46 +0200, Sebastian Ramacher wrote: > Regardless of future transitions of libffi, if glib and the > introspection ecosystems are closely tied to the the libffi ABI, the > affected packages need to express that with the proper dependencies. It's not that they are closely tied to any specific libffi ABI - to the best of my knowledge, they're all fine with any reasonable version of libffi, old or new. The problem is that gobject-introspection and all users of girffi.h[1] (gjs, pygobject, etc.) all need to be using the *same* libffi, because girffi.h has functions that return pointers to ffi types or take pointers to ffi types as parameters. I don't know whether it is important that glib2.0 and gobject-introspection are *also* using the same libffi; in the past we assumed that they should, but it is probably not critical. [1] https://codesearch.debian.net/search?q=girffi.h&literal=1 smcv
Bug#994923: add more infomation
Package: wnpp Severity: wishlist Owner: clay stan * Package name: dirsearch Version : 0.4.2 Upstream Author : maurosoria * URL : https://github.com/maurosoria/dirsearch License : GPL-2 Programming Lang: Python Description : An advanced command-line tool designed to brute force directories and files in webservers, AKA web path scanner
Bug#986783: add more information
Package: wnpp Severity: wishlist Owner: clay stan * Package name: cpufetch Version : 0.97 Upstream Author : Dr-Noob * URL : https://github.com/Dr-Noob/cpufetch License : MIT Programming Lang: C Description : cpufetch is a command-line tool written in C that displays the CPU information in a clean and beautiful way
Bug#994560: Bug#995032: GNOME components segfault as a result of libffi transition
On 2021-09-25 14:55:23 +0100, Simon McVittie wrote: > On Sat, 25 Sep 2021 at 15:01:46 +0200, Sebastian Ramacher wrote: > > Regardless of future transitions of libffi, if glib and the > > introspection ecosystems are closely tied to the the libffi ABI, the > > affected packages need to express that with the proper dependencies. > > It's not that they are closely tied to any specific libffi ABI - to the > best of my knowledge, they're all fine with any reasonable version of > libffi, old or new. The problem is that gobject-introspection and all > users of girffi.h[1] (gjs, pygobject, etc.) all need to be using the > *same* libffi, because girffi.h has functions that return pointers to ffi > types or take pointers to ffi types as parameters. Sorry, that's not what I meant. they are tightly coupled in the sense that the whole gobject-introspection ecosystem needs to use the same libffi version. It's the same as boost and icu where also icu's ABI leaks into boost's ABI (via some icu structs that are passed around). Hence everything that uses Boost.Regex needs also be tracked in icu transitions. To track that, libboost-regexX provides libboost-regexX-icuY and reverse dependencies have dependencies on libboost-regexX-icuY. For libgirepository1.0-1 that would mean that libgirepository1.0-1 provides libgirepository1.0-1-ffiX and symbols from girffi that depend on the specific libffi ABI then declare in the symbols files that dependencies on libgirepository1.0-1-ffiX need to be generated. Cheers > > I don't know whether it is important that glib2.0 and gobject-introspection > are *also* using the same libffi; in the past we assumed that they should, > but it is probably not critical. > > [1] https://codesearch.debian.net/search?q=girffi.h&literal=1 > > smcv -- Sebastian Ramacher signature.asc Description: PGP signature
Bug#995046: 3.2.3-7 fails with libc6-2.30
Control: severity -1 normal Hello Eugene, thanks for your bug report :) I think I still need to understand a few things before proceeding, seems like there's something weird going on in your system. 1) Do you know how is it possible that you were running Debian testing with libc6 2.30-4? Even Debian stable has a newer version, I believe you could have missed running apt full-upgrade at some point. 2) Is your system under a chroot and/or without /proc mounted? We've had this issue in the near past [0], but it should be patched for 3.2.3-7 [1], even with older libc6. > Upgrade libc6 to 2.32-4 solves the problem. That's the current version available in testing and unstable, so anybody running those will be fine. Stable currently has libc6 2.31, and I plan on having a backports of rsync at some point in the future, so this issue could affect that, though I don't see how the changes between 3.2.3-4 and 3.2.3-7 could trigger this bug. I'm also considering that upstream's bug reports says this issue only started with libc6 2.32 [0][2]. If anything, 3.2.3-7 is fixing the very same issue you reported, which should have been happening in rsync 3.2.3 + libc6 2.32 (but you mention you had an older libc6). Overall I believe there might be something wrong in your system, related to libc6. I will lower the priority to normal, considering all of these, and will increase it if needed once we understand your issue better. [0] https://github.com/WayneD/rsync/issues/109 [1] https://salsa.debian.org/debian/rsync/-/commit/3320a1c1b9e9fcf4b4b759a194a6059380c56b88 [2] https://sourceware.org/bugzilla/show_bug.cgi?id=26401 Thank you, -- Samuel Henrique
Bug#995026: Update
I confirmed this also happens in Testing (bookworm) aside from it pulling in Nvidia 470 packages instead. I tested this on the same machine but in a bookworm chroot with: apt install nvidia-legacy-390xx-driver -s
Bug#698996: unrar-free: obsolete information in Description
This issue was already addressed and it should be closed.
Bug#987335: add more information
Package: wnpp Severity: wishlist Owner: clay stan * Package name: dpa-ext-gnomekeyring Version : 5.0.4 Upstream Author : linuxdeepin * URL : https://github.com/linuxdeepin/dpa-ext-gnomekeyring License : GPL-3+ Programming Lang: CPP Description :GNOME keyring extension for dde-polkit-agent. DDE Polkit Agent extension to automatically do some thing with GNOME keyring
Bug#994789: rsync: Errors out with "deflate on token returned 0 (8864 bytes left)" when tranferring 3GB file
Hello Faheem, > I did some investigation, but forgot to update the bug report. Based on > priors, I was not expecting to get a reply. Yeah, sometimes it's hard to keep up with the bug reports, thanks for not giving up! > The problem is that I'm connecting to a remote VPS, which is an OpenVZ > VM, and currently runs a badly outdated version of Debian, Debian 8 > (jessie). It was running the default version of rsync for that release > (3.1.1-3+deb8u2), which appears to be too old to do the handshake that > rsync expects for compression. Wow, that is quite outdated yes, at this point the only support there is for Jessie is the paid one by the Debian LTS project[0][1]. Since you're a customer, I would kindly suggest cutting a ticket to them, asking for an updated release. > However, as an error message, this really sucked. Unless the rsync > maintainers consider compatibility with older rsync versions not worth > bothering with, it would be good to have a more intelligible error > message. But I don't know if it is worth trying to follow up with the > rsync project. My experience with rsync upstream is that they would improve the error message if possible, so it might be worth reporting it. > I managed to backport the current version of rsync to Debian 8 on the > OpenVZ VPS, and the error went away. Other workarounds I tried (like > --compress-choice) all failed, because the rsync version seemed to be > too old. Happy to know your workaround fixed the issue, I always try to upload an updated rsync release to the backports repository as well, but that didn't happen with Jessie > The output of `apt-cache policy rsync` on that server now looks like > > rsync: >Installed: 3.2.3-7 >Candidate: 3.1.1-3+deb8u2 >Package pin: (not found) >Version table: > 3.2.3-7 1001 > 50 http://ftp.us.debian.org/debian/ testing/main amd64 Packages > 50 http://ftp.us.debian.org/debian/ unstable/main amd64 Packages > *** 3.2.3-7 1001 > 100 /var/lib/dpkg/status > 3.1.1-3+deb8u2 1001 > 500 http://security.debian.org/ jessie/updates/main amd64 > Packages > 3.1.1-3+deb8u1 1001 > 500 http://ftp.us.debian.org/debian/ jessie/main amd64 Packages By looking at these, it seems like your VPS provider is not using ELTS so it's possible they're not updating their images for more than a year now. However, this is just a guess, I suggest contacting them and explaining your concerns with outdated images. > If you don't think it's worth following up upstream regarding the > quality of their error messages, you can close this bug report. I think it's worth it, but I will let this up for you, so I'm resolving this bug report. [0] https://wiki.debian.org/LTS/Extended [1] https://deb.freexian.com/extended-lts/ Thank you, -- Samuel Henrique
Bug#995062: bullseye-pu: package speech-dispatcher/0.10.2-2+deb11u1
Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
Hello,
[ Reason ]
We have recently noticed that one cannot choose between the various
mbrola speech synthesis voices in the orca screen reader.
This is not a regression from previous releases.
[ Impact ]
This prevents users from being able to switch between e.g. male/female
voices to efficiently mark different contents.
[ Tests ]
This was tested in a VM as well as on the end-user system where the bug
was noticed first.
[ Risks ]
The code is very simple: it just moves a single line of code, and adds a
few debugging prints to make sure this gets effect.
[ Checklist ]
[X] *all* changes are documented in the d/changelog
[X] I reviewed all changes and I approve them
[X] attach debdiff against the package in (old)stable
[X] the issue is verified as fixed in unstable
[ Changes ]
The bug comes from the fact that there are several ways to specify the
voice to be used: either through language + voice type, or precise voice
name. The second way is of course very precise, but unfortunately it was
coming first, and thus overwritten by the other ways. The change is just
to use the voice name last, so that one takes precedence over the other
(more generic) types.
diff -Nru speech-dispatcher-0.10.2/debian/changelog
speech-dispatcher-0.10.2/debian/changelog
--- speech-dispatcher-0.10.2/debian/changelog 2020-12-16 01:17:56.0
+0100
+++ speech-dispatcher-0.10.2/debian/changelog 2021-09-19 15:55:15.0
+0200
@@ -1,3 +1,10 @@
+speech-dispatcher (0.10.2-2+deb11u1) bullseye; urgency=medium
+
+ * patches/generic-set-voice-name: Fix setting voice name for the generic
+module.
+
+ -- Samuel Thibault Sun, 19 Sep 2021 15:55:15 +0200
+
speech-dispatcher (0.10.2-2) unstable; urgency=medium
* speech-dispatcher: Handle moving configuration file from main package to
diff -Nru speech-dispatcher-0.10.2/debian/patches/generic-set-voice-name
speech-dispatcher-0.10.2/debian/patches/generic-set-voice-name
--- speech-dispatcher-0.10.2/debian/patches/generic-set-voice-name
1970-01-01 01:00:00.0 +0100
+++ speech-dispatcher-0.10.2/debian/patches/generic-set-voice-name
2021-09-19 15:55:15.0 +0200
@@ -0,0 +1,41 @@
+commit 2aff49e3b8eb49dceb2c135025bc19cea6b0fd2e
+Author: Samuel Thibault
+Date: Sun Sep 19 15:52:31 2021 +0200
+
+generic: Set voice name after setting voice language and type
+
+E.g. when using various mbrola languages, we want to be able to specify
+a precise voice name. Setting the voice language/type after the voice
+name would override that choice.
+
+diff --git a/src/modules/generic.c b/src/modules/generic.c
+index 5072867d..b62cdb58 100644
+--- a/src/modules/generic.c
b/src/modules/generic.c
+@@ -205,9 +205,9 @@ int module_speak(const gchar * data, size_t bytes,
SPDMessageType msgtype)
+ DBG("Speaking when requested to write");
+ return 0;
+ }
+- UPDATE_STRING_PARAMETER(voice.name, generic_set_synthesis_voice);
+ UPDATE_STRING_PARAMETER(voice.language, generic_set_language);
+ UPDATE_PARAMETER(voice_type, generic_set_voice);
++ UPDATE_STRING_PARAMETER(voice.name, generic_set_synthesis_voice);
+ UPDATE_PARAMETER(punctuation_mode, generic_set_punct);
+ UPDATE_PARAMETER(pitch, generic_set_pitch);
+ UPDATE_PARAMETER(pitch_range, generic_set_pitch_range);
+@@ -707,6 +707,7 @@ void generic_set_language(char *lang)
+
+ void generic_set_voice(SPDVoiceType voice)
+ {
++ DBG("Setting voice type %d", voice);
+ assert(generic_msg_language);
+ generic_msg_voice_str =
+ module_getvoice(generic_msg_language->code, voice);
+@@ -717,6 +718,7 @@ void generic_set_voice(SPDVoiceType voice)
+
+ void generic_set_synthesis_voice(char *name)
+ {
++ DBG("Setting voice name %s (%s)", name, msg_settings.voice.name);
+ assert(msg_settings.voice.name);
+ if (module_existsvoice(msg_settings.voice.name))
+ generic_msg_voice_str = msg_settings.voice.name;
diff -Nru speech-dispatcher-0.10.2/debian/patches/series
speech-dispatcher-0.10.2/debian/patches/series
--- speech-dispatcher-0.10.2/debian/patches/series 2020-11-25
00:43:56.0 +0100
+++ speech-dispatcher-0.10.2/debian/patches/series 2021-09-19
15:55:15.0 +0200
@@ -1,3 +1,4 @@
doc-figures
systemd-debian
mbrola-paths
+generic-set-voice-name
Bug#987336: add more information
Package: wnpp Severity: wishlist Owner: clay stan Control: retitle 987336 ITP: dtkcommon -- A public project for building DTK Library * Package name: dtkcommon Version : 5.5.2 Upstream Author : linuxdeepin * URL : https://github.com/linuxdeepin/dtkcommon License : GPL-3+ Programming Lang: CPP Description : A public project for building DTK Library DTK is short name of deepin tool kit,It is a set of beautiful and practical UI graphics library developed based on Qt5
Bug#995063: os-prober fails to detect partition when the device name is a substring of another device
Package: os-prober Version: 1.77 Severity: important Tags: patch Dear Maintainer, My system has another linux install located on /dev/sde1, which os-prober should detect There is also a /dev/sde127 which is part of a raid array In this case, os-prober line 141 incorrectly believes that /dev/sde1 is part of a raid array, because grep -q "^/dev/sde1" $OS_PROBER_TMP/raided-map returns true as it matches the /dev/sde127 line. This can be fixed by changing the line to read if grep -q "^$mapped\$" "$OS_PROBER_TMP/raided-map" ; then Thanks -- System Information: Debian Release: 10.10 APT prefers oldstable APT policy: (500, 'oldstable') Architecture: i386 (x86_64) Foreign Architectures: amd64 Kernel: Linux 4.19.0-17-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages os-prober depends on: ii grub-common 2.02+dfsg1-20+deb10u4 ii libc62.28-10 os-prober recommends no packages. os-prober suggests no packages. -- no debconf information
Bug#995006: init-system-helpers: deb-systemd-helper does not call daemon-reload despite unit files were changed
Am 24.09.21 um 21:36 schrieb Vasyl Gello: retitle -1 dh_installsystemd should call daemon-reload in postinst if unit files changed reassign -1 debhelper 13.5.1 >No, my point is that i-s-h is not called as part of the upgrade process, since you explicititly asked not to. So i-s-h can not call daemon-reload. >Whether dh_installsystemd should generate a blank "daemon-reload" in this case is another matter. OK, so I am re-assigning the bug to debhelper and temporary add the daemon-reload step into xpra postinst. So far, we call daemon-reload in the following cases: autoscripts/postrm-systemd-reload-only: systemctl --system daemon-reload >/dev/null || true autoscripts/postinst-systemd-restartnostart:systemctl --system daemon-reload >/dev/null || true autoscripts/postinst-systemd-restart: systemctl --system daemon-reload >/dev/null || true autoscripts/postinst-systemd-start: systemctl --system daemon-reload >/dev/null || true So, it is currently tied to start/restart requests, i.e. we only call daemon-reload at the exact point when it's actually needed before we (re)start a service and need the updated configuration, i.e. in cases where dh_installsystemd controls the life cycle of the service. daemon-reload is a costly operation, so we should try to avoid calling it too excessively. So I'm not convinced it is a good idea to generate a daemon-reload (via dh_installsystemd in postinst) for packages which do not actually (re)start a unit as part of the upgrade process. By using "--no-enable --no-start" you are basically leaving the management of the life cycle of the service entirely to the administrator. Wouldn't you agree? Shouldn't the administrator then call "systemctl daemon-reload" as well? systemd will even warn him in cases a .service file has changed (which thankfully doesn't happen too often) Is this actually an issue in practice? Do you have bug reports where users of your xpra package have asked for this? Regards, Michael OpenPGP_signature Description: OpenPGP digital signature
Bug#995006: init-system-helpers: deb-systemd-helper does not call daemon-reload despite unit files were changed
Am 25.09.21 um 16:50 schrieb Michael Biebl: daemon-reload is a costly operation, so we should try to avoid calling it too excessively. I've been trying hard to get rid of "daemon-reload" calls where not absolutely necessary, see e.g. [1-3] So I'd be very wary re-adding them too liberally. Regards, Michael [1] https://salsa.debian.org/debian/debhelper/-/merge_requests/43 [2] https://salsa.debian.org/systemd-team/systemd/commit/54ebb5500e75562d77fc5668ef7194af579f85bd [3] https://salsa.debian.org/debian/init-system-helpers/commit/f0cac594ab79ebe72c53529046304037cf5c09b8 OpenPGP_signature Description: OpenPGP digital signature
Bug#994551: libcifpp1: please split off static files to separate package
Hi Étienne, all, > I took the liberty to implement the change you suggest, and push > to Salsa [1]. I do not see your changes on salsa, the last commit is 3 months old there. Did you forget to push? > Since this is an RC bug which propagates on > several packages, and since it would have to go through NEW, for > manual review; Actually, this bug is now triggering an ugly autorm on several packages. And since it needs to travel via NEW, they might end up getting removed from testing. @Andrius, since you wrote: > So far, there has not been other libcifppX binary package, thus no > damage is done. However, future libcifppX packages should not contain > static files, in particular these: and since this is not doing any damage for now, do you think we could reduce the severity to important for now? We cannot do another upload on top of the one we will be sending to NEW w/o hooping via NEW again, anyway, so I find it safe to drop the severity for now. Let me know? Nilesh signature.asc Description: PGP signature
Bug#987336: update ITP description
Control: retitle 987336 ITP: dtkcommon -- A public project for building DTK Library
Bug#995064: golang-github-containers-storage: Please upgrade to upstream version 1.36
Package: golang-github-containers-storage Severity: wishlist X-Debbugs-Cc: none, Reinhard Tartler This is needed for podman 3.4, cf. #994601 -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (500, 'testing'), (50, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-8-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#995065: unrar-free: CVE-2017-11190 fix
Package: unrar-free Severity: minor Version: 1:0.0.1+cvs20140707-4 At https://gitlab.com/bgermann/unrar-free/-/commit/e4b3d2d974780af1 you can find a fix for CVE-2017-11190 which is unproblematic because the debug code is not compiled in Debian.
Bug#995066: mariadb-server: Incorrect warning about corrupt tables on mysql start
Package: mariadb-server
Version: 1:10.5.11-1
Severity: normal
Tags: l10n patch
Dear Maintainer,
/etc/mysql/debian-start incorrectly warns about corrupt tables if there're
databases and tables with non-ascii names.
ТемаWARNING: mysqlcheck has found corrupt tables
От root
Комуroot@neva.localnet
ДатаСегодня 13:45
ERROR 1146 (42S02) at line 1: Table '??? .??? ??' doesn't exist
ERROR 1146 (42S02) at line 1: Table '??? .GDP' doesn't exist
ERROR 1146 (42S02) at line 1: Table '??? .' doesn't exist
ERROR 1146 (42S02) at line 1: Table '??? .??' doesn't exist
ERROR 1146 (42S02) at line 1: Table '??? .??' doesn't exist
ERROR 1146 (42S02) at line 1: Table '??? .???' doesn't exist
ERROR 1146 (42S02) at line 1: Table '??? .bugs-old' doesn't exist
ERROR 1146 (42S02) at line 1: Table '??? .? ?? ??' doesn't exist
ERROR 1146 (42S02) at line 1: Table '??? .??? ???' doesn't exist
ERROR 1146 (42S02) at line 1: Table '??? .??' doesn't exist
ERROR 1146 (42S02) at line 1: Table '??? .?? ??' doesn't exist
ERROR 1146 (42S02) at line 1: Table '??? .?? ???' doesn't exist
ERROR 1146 (42S02) at line 1: Table '??? .bugs' doesn't exist
ERROR 1146 (42S02) at line 1: Table '??? .?' doesn't exist
ERROR 1146 (42S02) at line 1: Table '??? .?' doesn't exist
Improperly closed tables are also reported if clients are accessing
the tables *now*. A list of current connections is below.
+-+--+---++-+--+--+--+--+
| Id | User | Host | db | Command | Time | State| Info |
Progress |
+-+--+---++-+--+--+--+--+
| 441 | root | localhost || Query | 0| starting | show processlist |
0.000|
+-+--+---++-+--+--+--+--+
Uptime: 6 Threads: 1 Questions: 879 Slow queries: 0 Opens: 428 Open
tables: 421 Queries per second avg: 146.500
Suggested fix:
--- /usr/share/mysql/debian-start.inc.sh2021-09-25 16:15:00.757459188
+0300
+++ /usr/share/mysql/debian-start.inc.sh2021-09-25 16:16:05.448573230
+0300
@@ -23,7 +23,7 @@
# If a crashed table is encountered, the "mysql" command will return with a
status different from 0
set +e
- LC_ALL=C $MYSQL --skip-column-names --batch -e '
+ $MYSQL --skip-column-names --batch -e '
select concat('\''select count(*) into @discard from `'\'',
TABLE_SCHEMA, '\''`.`'\'', TABLE_NAME, '\''`'\'')
from information_schema.TABLES where
TABLE_SCHEMA<>'\''INFORMATION_SCHEMA'\'' and
TABLE_SCHEMA<>'\''PERFORMANCE_SCHEMA'\'' and ( ENGINE='\''MyISAM'\'' or
ENGINE='\''Aria'\'' )' | \
-- System Information:
Debian Release: 11.0
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 5.10.0-8-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages mariadb-server depends on:
ii mariadb-server-10.5 1:10.5.11-1
mariadb-server recommends no packages.
mariadb-server suggests no packages.
-- no debconf information
Bug#995046: 3.2.3-7 fails with libc6-2.30
Hi Samuel. On Sat, Sep 25, 2021 at 03:08:47PM +0100, Samuel Henrique wrote: > 1) Do you know how is it possible that you were running Debian testing > with libc6 2.30-4? Even Debian stable has a newer version, I believe > you could have missed running apt full-upgrade at some point. I have several hosts with old kernels (like 4.17) and their headers, and gcc-7, which are tied to libc6-2.30 by their dependences. On "aptitude install libc6" first resolver's proposal was to remove these packages. I agreed with this choice to install libc6-2.32. I have a copy of one such system on backup, it may be studied for more details if need... However, it looks pointless, because support for lchown() is definitely a new feature, so the right way, IMHO, is to correct dependences for rsync package: "libc6 (>= 2.31)". > 2) Is your system under a chroot and/or without /proc mounted? No, fault happens with physical hosts (not VMs or containers), where /proc is mounted. However, they are all running SysV init. > > Upgrade libc6 to 2.32-4 solves the problem. > That's the current version available in testing and unstable, so > anybody running those will be fine. Right. I also have some similar hosts with libc-2.32, probably they were upgraded to last version due to absence of old kernels, old gcc, etc. Rsync runs fine on them. > If anything, 3.2.3-7 is fixing the very same issue you reported, which > should have been happening in rsync 3.2.3 + libc6 2.32 (but you > mention you had an older libc6). > > Overall I believe there might be something wrong in your system, > related to libc6. Every system with periodic updates might have outdated packages, generally it's not a problem (and should not be a problem) if binary API is compatible and all package dependences are correct. -- Eugene Berdnikov
Bug#995067: bitlbee-libpurple: Crash if not stable connection
Package: bitlbee-libpurple Version: 3.6-1.2 Severity: important Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? I discovered the problem during a non stable Wifi connection. The network tends to be down during 30 seconds or 1 minute then bbe up * What exactly did you do (or not do) that was effective (or ineffective)? Sometimes, using weechat to connect to bitbeee on a local network, bitlbee crashes * What was the outcome of this action? The main problem is that the crash.log file is more than 4GB. I dont know how to send it, perhaps via the people./debian.org machine? * What outcome did you expect instead? *** End of the template - remove these template lines *** Regards -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'buildd-experimental'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.14.0-1-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages bitlbee-libpurple depends on: ii bitlbee-common 3.6-1.2 ii debianutils 5.5-1 ii libc6 2.32-4 ii libgcrypt20 1.9.4-3+b1 ii libglib2.0-02.70.0-1+b1 ii libgnutls30 3.7.2-2 ii libpurple0 2.14.1-1+b1 bitlbee-libpurple recommends no packages. bitlbee-libpurple suggests no packages. -- no debconf information
Bug#989600: /usr/bin/swift-container-reconciler: reconciler's memcache connections fail when using hostnames
On Fri, Sep 10, 2021 at 09:50:42PM +0200, Thomas Goirand wrote: > On 9/10/21 11:40 AM, Filippo Giunchedi wrote: > > On Thu, Sep 09, 2021 at 09:32:34AM +0200, Thomas Goirand wrote: > >> Hi, > >> > >> Thanks a lot for working on this, it really is helpful. > >> > >> The pull request you're pointing at contains multiple commits. Would you > >> be able to transform this into a patch against the Eventlet versions > >> 0.26.1 (currently in Stable) and 0.30.2 (in Unstable and Testing)? If > >> you provide it, then I'll be very happy to add the patches to these > >> Debian packages. If I'm asking it's not because I don't want to do it > >> myself, but because you wrote it, you may be better at understanding how > >> to backport the patches. > > > > Certainly, I did port the patch to our internal repo for Bullseye. You can > > find > > the commit below, which modulo the changelog version obviously should work > > as-is. > > > > https://github.com/wikimedia/operations-debs-python-eventlet/commit/a93d2e0cd2cdf3efcd7915cb781355d58e5728ab > > > > I didn't change > > 'Replace-dnspython-_compute_expiration-by-_compute_times.patch' > > for a cleaner diff, although that patch a whole I think can be replaced with > > the PR's diff. What do you think? > > > > best, > > Filippo > > > > Hi, > > I'll try to get this in Bullseye proper. Thanks a lot for your work, > this is definitively very helpful, and may solve troubles with swift's > cname middleware also. You are welcome, and thank you for pushing to get the update in Bullseye > > I'm not sure about > Replace-dnspython-_compute_expiration-by-_compute_times.patch, though > it's probably better, from the Debian Stable perspective, to not touch > the patches that are already there, so it is easier for the Stable > release team to review it. Agreed > I will also need a patch against the version 0.30.2-2 currently in > unstable/bookworms (again: otherwise the Debian Stable release team may > complain about it). Could you provide one? For sure, I have added the patches in this MR. Let me know what you think! https://salsa.debian.org/python-team/packages/python-eventlet/-/merge_requests/2 best, Filippo
Bug#992990: systemd: Does not clean up user session
On Thu, 26 Aug 2021 17:21:39 +0200 Samuel Thibault wrote: > Control: tags -1 wontfix > > So AIUI, to get a proper cleanup when the X server happens to go away > (lightdm restart, or main session process exit), the processes have to > notice that the X server went away? Not sure what to do about this bug report. Do you want to keep it open asking for `KillUserProcesses=yes` to be the new default? If not, is there a benefit to keep it open? Michael signature.asc Description: This is a digitally signed message part
Bug#975524: cmst/connman system-tray applet: please start automatically when installed
Control: reassign -1 cmst Hi, lxde uses connman-gtk not cmst. Sorry, my mistake. Cheers, Amy
Bug#995068: gnome-games-app: Rename to highscore
Source: gnome-games-app Version: 40.0-3 gnome-games-app appears to have been renamed to highscore so we should rename our Debian packaging to match, once there is a new release. I'm filing this bug as a reminder because our debian/watch won't pick up the new release automatically. https://gitlab.gnome.org/World/highscore Background is at https://gitlab.gnome.org/Archive/gnome-games/-/issues/243 Thanks, Jeremy Bicha
Bug#614051: Fine Morning. Is Mrs. Anna.
Can we talk please, is urgent, is about Mrs. Anna,
Bug#995023: improved patch: take care that the file doesn't exist on filesystems where link() fails
Hi,
the patch provided before does not take into account that the file
may exists before we call link() on a file system where link() fails
(and not with EEXIST). In that case, we would use the already existing
file.
The attached patch makes sure we try a new file name in that case.
Regards,
Andi
>From 0482adf516a914d9215ebd00b93ee63a15976836 Mon Sep 17 00:00:00 2001
From: "Andreas B. Mundt"
Date: Fri, 24 Sep 2021 21:10:52 +0200
Subject: [PATCH] Fix for sshfs.
---
debian/patches/series | 1 +
debian/patches/sshfs.patch | 23 +++
2 files changed, 24 insertions(+)
create mode 100644 debian/patches/sshfs.patch
diff --git a/debian/patches/series b/debian/patches/series
index e1ee4dfc..8c81fbe2 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1,2 +1,3 @@
03_kfreebsd.patch
05_skip-known-test-failures.patch
+sshfs.patch
diff --git a/debian/patches/sshfs.patch b/debian/patches/sshfs.patch
new file mode 100644
index ..a1f6ab5f
--- /dev/null
+++ b/debian/patches/sshfs.patch
@@ -0,0 +1,23 @@
+--- a/pkcs11/gkm/gkm-transaction.c
b/pkcs11/gkm/gkm-transaction.c
+@@ -294,16 +294,16 @@
+ * stat, the check on the increased link count
+ * will fail. Fortunately the case for
+ * hardlinks are not working solves it. */
+- if (link (filename, result) && errno == EEXIST) {
++ if (!access (result, F_OK) || (link (filename, result) && errno == EEXIST)) {
+ /* This is probably a valid error.
+ * Let us try another temporary file. */
+ } else if (stat (filename, &sb)) {
+ stat_failed = 1;
+ } else {
+-if ((sb.st_nlink == nlink + 1)
++if ((sb.st_nlink == nlink + 1) || !access (result, F_OK)
+ || !copy_to_temp_file (result, filename)) {
+- /* Either the link worked or
+- * the copy succeeded. */
++ /* Either the link worked (on sshfs, a copy is made
++ * instead) or the final copy_to_temp_file succeeded. */
+ gkm_transaction_add (self, NULL,
+ complete_link_temporary,
+ result);
--
2.30.2
Bug#994875: connman does not respect /etc/network/interfaces when upgrading from buster to bullseye and more general considerations
Hi, as far as I remember connman ignores /etc/network/interfaces by design. Lxde metapackage in buster recommends wicd which is not available in bullseye due to the deprecation of python 2. Therefore lxde metapackage in bullseye recommends connman-gtk (connman). Cheers, Amy
Bug#995069: libclc-12: tahiti-amdgcn-mesa-mesa3d.bc is missing
Package: libclc-12 Version: 1:12.0.1-9 Followup-For: Bug #993904 To add to this bug report, I'm getting a similer error message when trying to use OpenCL on my machine, that has a Polaris10 card. Trying to run even just clinfo gives the following error message: === CL_PROGRAM_BUILD_LOG === fatal error: cannot open file '/usr/lib/clc/polaris10-amdgcn-mesa-mesa3d.bc': No such file or directory As it turns out, /usr/lib/clc _does_ contain the .bc files; however, most of them are missing the 'mesa ' and/or 'mesa3d' part in the name, as shown by this listing of the directory: total 70M drwxr-xr-x 2 root root 4.0K Sep 21 20:51 . drwxr-xr-x 170 root root 36K Sep 24 22:14 .. -rw-r--r-- 1 root root 7.8M Sep 18 11:03 amdgcn--amdhsa.bc lrwxrwxrwx 1 root root 16 Sep 18 11:03 aruba-r600--.bc -> cayman-r600--.bc -rw-r--r-- 1 root root 4.3M Sep 18 11:03 barts-r600--.bc lrwxrwxrwx 1 root root 18 Sep 18 11:03 bonaire-amdgcn--.bc -> tahiti-amdgcn--.bc lrwxrwxrwx 1 root root 15 Sep 18 11:03 caicos-r600--.bc -> barts-r600--.bc lrwxrwxrwx 1 root root 18 Sep 18 11:03 carrizo-amdgcn--.bc -> tahiti-amdgcn--.bc -rw-r--r-- 1 root root 4.3M Sep 18 11:03 cayman-r600--.bc -rw-r--r-- 1 root root 4.3M Sep 18 11:03 cedar-r600--.bc -rw-r--r-- 1 root root 4.3M Sep 18 11:03 cypress-r600--.bc lrwxrwxrwx 1 root root 18 Sep 18 11:03 fiji-amdgcn--.bc -> tahiti-amdgcn--.bc lrwxrwxrwx 1 root root 18 Sep 18 11:03 gfx900-amdgcn--.bc -> tahiti-amdgcn--.bc lrwxrwxrwx 1 root root 18 Sep 18 11:03 gfx902-amdgcn--.bc -> tahiti-amdgcn--.bc lrwxrwxrwx 1 root root 18 Sep 18 11:03 gfx904-amdgcn--.bc -> tahiti-amdgcn--.bc lrwxrwxrwx 1 root root 18 Sep 18 11:03 gfx906-amdgcn--.bc -> tahiti-amdgcn--.bc lrwxrwxrwx 1 root root 18 Sep 18 11:03 hainan-amdgcn--.bc -> tahiti-amdgcn--.bc lrwxrwxrwx 1 root root 18 Sep 18 11:03 hawaii-amdgcn--.bc -> tahiti-amdgcn--.bc lrwxrwxrwx 1 root root 17 Sep 18 11:03 hemlock-r600--.bc -> cypress-r600--.bc lrwxrwxrwx 1 root root 18 Sep 18 11:03 iceland-amdgcn--.bc -> tahiti-amdgcn--.bc lrwxrwxrwx 1 root root 15 Sep 18 11:03 juniper-r600--.bc -> cedar-r600--.bc lrwxrwxrwx 1 root root 18 Sep 18 11:03 kabini-amdgcn--.bc -> tahiti-amdgcn--.bc lrwxrwxrwx 1 root root 18 Sep 18 11:03 kaveri-amdgcn--.bc -> tahiti-amdgcn--.bc lrwxrwxrwx 1 root root 18 Sep 18 11:03 mullins-amdgcn--.bc -> tahiti-amdgcn--.bc -rw-r--r-- 1 root root 8.0M Sep 18 11:03 nvptx64--.bc -rw-r--r-- 1 root root 8.0M Sep 18 11:03 nvptx64--nvidiacl.bc -rw-r--r-- 1 root root 7.9M Sep 18 11:03 nvptx--.bc -rw-r--r-- 1 root root 7.9M Sep 18 11:03 nvptx--nvidiacl.bc lrwxrwxrwx 1 root root 18 Sep 18 11:03 oland-amdgcn--.bc -> tahiti-amdgcn--.bc lrwxrwxrwx 1 root root 15 Sep 18 11:03 palm-r600--.bc -> cedar-r600--.bc lrwxrwxrwx 1 root root 18 Sep 18 11:03 pitcairn-amdgcn--.bc -> tahiti-amdgcn--.bc lrwxrwxrwx 1 root root 18 Sep 18 11:03 polaris10-amdgcn--.bc -> tahiti-amdgcn--.bc lrwxrwxrwx 1 root root 18 Sep 18 11:03 polaris11-amdgcn--.bc -> tahiti-amdgcn--.bc lrwxrwxrwx 1 root root 15 Sep 18 11:03 redwood-r600--.bc -> cedar-r600--.bc -rw-r--r-- 1 root root 2.5M Sep 18 11:03 spirv64-mesa3d-.spv -rw-r--r-- 1 root root 2.5M Sep 18 11:03 spirv-mesa3d-.spv lrwxrwxrwx 1 root root 18 Sep 18 11:03 stoney-amdgcn--.bc -> tahiti-amdgcn--.bc lrwxrwxrwx 1 root root 15 Sep 18 11:03 sumo2-r600--.bc -> cedar-r600--.bc lrwxrwxrwx 1 root root 15 Sep 18 11:03 sumo-r600--.bc -> cedar-r600--.bc -rw-r--r-- 1 root root 7.8M Sep 18 11:03 tahiti-amdgcn--.bc lrwxrwxrwx 1 root root 18 Sep 18 11:03 tonga-amdgcn--.bc -> tahiti-amdgcn--.bc lrwxrwxrwx 1 root root 15 Sep 18 11:03 turks-r600--.bc -> barts-r600--.bc lrwxrwxrwx 1 root root 18 Sep 18 11:03 verde-amdgcn--.bc -> tahiti-amdgcn--.bc This seems to be only a naming issue, as adding a symlink with the appropriate name fixes it for me. -- System Information: Debian Release: bookworm/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-8-amd64 (SMP w/16 CPU threads) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libclc-12 depends on: ii libclang-common-12-dev 1:12.0.1-9 ii libclc-12-dev 1:12.0.1-9 libclc-12 recommends no packages. libclc-12 suggests no packages. -- no debconf information
Bug#990501: connman: Connman disrupted network during upgrade on system where it does not manage network
Hi, in case you have plasma-nm installed, cmst (connman) shouldn't have been installed at all. Lxqt metapackage recommends cmst (connman) or nm-tray (network-manager) or network-manager-gnome (network-manager) or plasma-nm (network-manager) or wicd (wicd-daemon). In case you have network-manager without plasma-nm installed, avoid the lxqt metapackage, or add network-manager to its recommends. Cheers, Amy
Bug#815231: cmake: FTBFS on kfreebsd, hurd: 2 tests fail: BuildDepends, RunCMake.Configure
Control: severity -1 wishlist On Fri, 14 Oct 2016 14:03:48 -0400 Brad King wrote: FWIW I would not consider this test failure to be a blocking issue for packaging a new CMake on this platform. The behavior of this logic is the same as it has been for years in CMake. It is just that this test case did not exist before. Given this statement and the fact that the test failure seems to be quite elusive and difficult to reproduce outside the buildd environment, I ignored the failing tests for now. I'll leave this bug open, as it is technically not fixed, but drop the severity to wishlist. Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Bug#993903: Acknowledgement (xfce4-session: After resuming from suspend, the synaptic touchpad was no longer working)
Ok, I found the solution. With the "xinput" command, I got the following output: / Virtual core pointer id=2[master pointer (3)] | +--> Virtual core XTEST pointerid=4[slave pointer (2)] | +--> HID 062a: id=13 [slave pointer (2)] | +--> Synaptics TM3053-004 id=12 [slave pointer (2)] \ Virtual core keyboardid=3[master keyboard (2)] +--> Virtual core XTEST keyboard id=5[slave keyboard (3)] +--> Power Button id=6[slave keyboard (3)] +--> Video Bus id=7[slave keyboard (3)] +--> Sleep Button id=8[slave keyboard (3)] +--> Integrated Camera: Integrated C id=9[slave keyboard (3)] +--> AT Translated Set 2 keyboard id=10 [slave keyboard (3)] +--> ThinkPad Extra Buttonsid=11 [slave keyboard (3)] then the "xinput --list-props 12" command gives: Device 'Synaptics TM3053-004': Device Enabled (154):1 Coordinate Transformation Matrix (156):1.00, 0.00, 0.00, 0.00, 1.00, 0.00, 0.00, 0.00, 1.00 Device Accel Profile (286):1 Device Accel Constant Deceleration (287):2.50 Device Accel Adaptive Deceleration (288):1.00 Device Accel Velocity Scaling (289):12.50 Synaptics Edges (290):77, 1863, 57, 1005 Synaptics Finger (291):25, 30, 0 Synaptics Tap Time (292):180 Synaptics Tap Move (293):97 Synaptics Tap Durations (294):180, 180, 100 Synaptics ClickPad (295):1 Synaptics Middle Button Timeout (296):0 Synaptics Two-Finger Pressure (297):282 Synaptics Two-Finger Width (298):7 Synaptics Scrolling Distance (299):44, 44 Synaptics Edge Scrolling (300):0, 0, 0 Synaptics Two-Finger Scrolling (301):1, 0 Synaptics Move Speed (302):1.00, 1.75, 0.090457, 0.00 Synaptics Off (303):1 Synaptics Locked Drags (304):0 Synaptics Locked Drags Timeout (305):5000 Synaptics Tap Action (306):0, 0, 0, 0, 1, 3, 2 Synaptics Click Action (307):1, 3, 2 Synaptics Circular Scrolling (308):0 Synaptics Circular Scrolling Distance (309):0.10 Synaptics Circular Scrolling Trigger (310):0 Synaptics Circular Pad (311):0 Synaptics Palm Detection (312):0 Synaptics Palm Dimensions (313):10, 200 Synaptics Coasting Speed (314):20.00, 50.00 Synaptics Pressure Motion (315):30, 160 Synaptics Pressure Motion Factor (316):1.00, 1.00 Synaptics Grab Event Device (317):0 Synaptics Gestures (318):1 Synaptics Capabilities (319):1, 0, 0, 1, 1, 1, 0 Synaptics Pad Resolution (320):20, 20 Synaptics Area (321):0, 0, 0, 0 Synaptics Soft Button Areas (322):970, 0, 870, 0, 0, 0, 0, 0 Synaptics Noise Cancellation (323):11, 11 Device Product ID (278):1739, 0 Device Node (277):"/dev/input/event7" Wait! Why the "Synaptics Off" value (property 303) is 1?? I turned that off: "xinput set-prop 12 303 0" -- and voila, the trackpad worked again (mouse movement & taps). So, the problem is solved! BUT there is a lingering question. Which program turned off the touchpad and then not turn it on again? Here is my theory: In the "Mouse and Touchpad" setting, I have the "Disable touchpad while typing" option checked. I set a shortcut key to suspend the laptop, calling "xfce4-session-logout -s" . Once this shortcut combination was invoked, the suspend action began immediately, yet there was not enough time for the touchpad to be re-enabled. As a result, the trackpad was stuck in the "disabled" position even after resuming from sleep. So this should be filed as a bug with the XFCE4 settings daemon, I think (xfce4-settings). The bugfix should be fairly easy, I suppose, but it will require a hook that is invoked when the computer going to sleep: when the touchpad is supposed to be disabled only temporarily, it should be re-enabled upon resumption from sleep. Wirawan On Tue, Sep 7, 2021 at 6:27 PM Debian Bug Tracking System wrote: > > Thank you for filing a new Bug report with Debian. > > You can follow progress on this Bug here: 993903: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=993903. > > This is an automatically generated reply to let you know your message > has been received. > > Your message is being forwarded to the package maintainers and other > interested parties for their attention; they will reply in due course. > > As you requested using X-Debbugs-CC, your message was also forwarded to > wiraw...@gmail.com > (after having been given a Bug report number, if it did not have one). > > Your message has been sent to the packag
Bug#994910: tripwire segfaults while reading files in /etc
Package: tripwire Version: 2.4.3.7-3+b3 Followup-For: Bug #994910 Reproduced here following a libc6 upgrade. I suspect this is because tripwire is statically linked and there has been a new release of libc6, so I suspect the nsswitch interface has broken (which is a standard problem with statically linking with libc6 on Linux). This would also explain why rebuilding the package made the problem go away. If this is correct, a BinNMU should fix the problem. -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-8-amd64 (SMP w/4 CPU threads) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages tripwire depends on: ii debconf [debconf-2.0] 1.5.77 ii postfix [mail-transport-agent] 3.5.6-1+b1 tripwire recommends no packages. tripwire suggests no packages. -- Configuration Files: /etc/tripwire/twcfg.txt changed [not included] /etc/tripwire/twpol.txt changed [not included] -- debconf information: * tripwire/installed: * tripwire/use-sitekey: true tripwire/local-passphrase-incorrect: false tripwire/broken-passphrase: tripwire/upgrade: true tripwire/email-report: tripwire/change-in-default-policy: * tripwire/use-localkey: true tripwire/site-passphrase-incorrect: false * tripwire/rebuild-config: true * tripwire/rebuild-policy: true
Bug#995050: ecere-sdk FTBFS with gcc 10
Thank you Adrian for reporting this. We have fixes for this upstream: commit *c94efd6390599a4a291b7fe8b3d2d62699247380* Author: Jerome St-Louis Date: Sun Sep 6 03:35:01 2020 -0400 compiler/bootstrap: Updated for GCC 10 Common fixes commit *7d835dd5c6e17ad1626ec7b6f1725e0f7f8a9371* Author: Rejean Loyer Date: Mon Aug 3 13:18:51 2020 -0400 compiler/ecs: add -no-attribute-common for targetting wasm. workaround "Common symbols are not yet implemented for Wasm" message coming from emscripten-releases\llvm-project\llvm\li b\MC\MCWasmStreamer.cpp's MCWasmStreamer::emitCommonSymbol function. commit *ca58cfa4e26e03271e32ee6aae3206956fdc26fd* Author: Jerome St-Louis Date: Wed May 20 07:25:49 2020 -0400 compiler/libec: Fixed multiple definitions issues breaking on GCC 10 without -fcommon There is also a more recent commit fixes for GCC 11 which will surely show up sooner or later: commit *53ec01de1c42cf342a35dc125a4fef01ffb5fced* (origin/master, master) Author: Jerome St-Louis Date: Thu Aug 5 21:07:56 2021 -0400 compiler/libec/lexer.l: Initial fix for failure to build on GCC 11 - bootstrap updated - # 0 instead of # 1 generated by preprocessor triggered problem in lexer's preprocessor() - NOTE: This was likely resulting in declMode, defaultDeclMode and structDeclMode not being set properly - It may also be related to #1135 There are other important fixes on master since 0.44.15, including fixes for #898832 . In general, the master branch of our repo is currently (HEAD: 53ec01de1c42cf342a35dc125a4fef01ffb5fced) very conservatively stable, and would be a good candidate for a patch 0.44.15 release. On our side we are overdue for a new release, but we hope to bring in a lot of new improvements and functionality for the next 0.44.16 release, which is proving difficult to complete given that our development branch (/lates//t/) is now more than 1200 commits ahead of master. We are also quite busy with our geospatial software endeavours (making use of the Ecere SDK). If someone is willing to help with the Debian packaging / update to close these bugs, myself and possibly others in our community will be more than happy to provide assistance and otherwise contribute to the effort. Thank you! Best regards, -Jerome On 9/25/21 6:27 AM, Adrian Bunk wrote: Source: ecere-sdk Version: 0.44.15-1 Severity: serious Tags: ftbfs https://buildd.debian.org/status/logs.php?pkg=ecere-sdk&ver=0.44.15-1%2Bb4 ... gcc -Wl,-z,relro -Wl,--no-undefined -Wl,--no-undefined -Wl,--no-undefined -Wl,--no-undefined -L../ecere/obj/bootstrap.linux -L../libec/obj/bootstrap.linux obj/bootstrap.linux/ecp.o obj/bootstrap.linux/ecp.main.o-lecereBootstrap -lecBootstrap -lm -ldl -o obj/bootstrap.linux/ecp /usr/bin/ld: obj/bootstrap.linux/ecp.main.o:./compiler/bootstrap/ecp/bootstrap/ecp.main.c:52: multiple definition of `__ecereVMethodID___ecereNameSpace__ecere__sys__File_Eof'; obj/bootstrap.linux/ecp.o:./compiler/bootstrap/ecp/bootstrap/ecp.c:388: first defined here /usr/bin/ld: obj/bootstrap.linux/ecp.main.o:./compiler/bootstrap/ecp/bootstrap/ecp.main.c:54: multiple definition of `__ecereVMethodID___ecereNameSpace__ecere__sys__File_Puts'; obj/bootstrap.linux/ecp.o:./compiler/bootstrap/ecp/bootstrap/ecp.c:384: first defined here /usr/bin/ld: obj/bootstrap.linux/ecp.main.o:./compiler/bootstrap/ecp/bootstrap/ecp.main.c:56: multiple definition of `__ecereVMethodID___ecereNameSpace__ecere__sys__File_Read'; obj/bootstrap.linux/ecp.o:./compiler/bootstrap/ecp/bootstrap/ecp.c:390: first defined here /usr/bin/ld: obj/bootstrap.linux/ecp.main.o:./compiler/bootstrap/ecp/bootstrap/ecp.main.c:58: multiple definition of `__ecereVMethodID___ecereNameSpace__ecere__sys__File_Seek'; obj/bootstrap.linux/ecp.o:./compiler/bootstrap/ecp/bootstrap/ecp.c:396: first defined here /usr/bin/ld: obj/bootstrap.linux/ecp.main.o:./compiler/bootstrap/ecp/bootstrap/ecp.main.c:60: multiple definition of `__ecereVMethodID___ecereNameSpace__ecere__sys__File_Write'; obj/bootstrap.linux/ecp.o:./compiler/bootstrap/ecp/bootstrap/ecp.c:392: first defined here ... /usr/bin/ld: ../libec/obj/bootstrap.linux/libecBootstrap.a(shortcuts.o):./compiler/bootstrap/libec/bootstrap/shortcuts.c:298: multiple definition of `__ecereVMethodID___ecereNameSpace__ecere__sys__File_Write'; obj/bootstrap.linux/ecp.o:./compiler/bootstrap/ecp/bootstrap/ecp.c:392: first defined here /usr/bin/ld: ../libec/obj/bootstrap.linux/libecBootstrap.a(shortcuts.o):./compiler/bootstrap/libec/bootstrap/shortcuts.c:300: multiple definition of `__ecereVMethodID___ecereNameSpace__ecere__sys__File_Seek'; obj/bootstrap.linux/ecp.o:./compiler/bootstrap/ecp/bootstrap/ecp.c:396: first defined here /usr/bin/ld: ../libec/obj/bootstrap.linux/libecBootstrap.a(type.o):./compiler/bootstrap/libec/bootstrap/type.c:392: multiple definition of `__ecereVMethodID___ecereNameSpace__ecere__sys__File_Seek'; obj/bootstrap.l
Bug#995006: init-system-helpers: deb-systemd-helper does not call daemon-reload despite unit files were changed
Hi Michael,
>daemon-reload is a costly operation, so we should try to avoid calling it
too excessively.
>
>So I'm not convinced it is a good idea to generate a daemon-reload (via
dh_installsystemd in postinst) for packages which do not actually (re)start
a unit as part of the upgrade process.
>
>By using "--no-enable --no-start" you are basically leaving the
management of the life cycle of the service entirely to the administrator.
Wouldn't you agree?
>
>Shouldn't the administrator then call "systemctl daemon-reload" as well?
>systemd will even warn him in cases a .service file has changed (which
thankfully doesn't happen too often)
>
>Is this actually an issue in practice? Do you have bug reports where
users of your xpra package have asked for this?
I realize daemon-reload is a costly operation, and I also realize the unit
in question is used by proxy module of Xpra, which is optional.
That's why Dmitry intentionally left it for system administrators to
configure.
Your point that typically units are not changed daily is also perfectly
valid.
However, speaking of "Shouldn't the administrator then call "systemctl
daemon-reload" as well?"…
No, if one uses unattended-upgrades or any other automation like auter or
puppet etc.
Server gets rebooted or service gets restarted and start-up fails due to
requirement of
"daemon-reload" or worse, starts with previous configuration which fails too.
What I suggest is slightly different Debian-wise. We do have list of conffiles
and list of files
installable by the package. What prevents us from scanning the list for known
locations
of systemd units ({/usr}/lib/systemd/{system,user}?) and compare them by hash
or by diff
just like we do it with conffiles? If the units, timers, etc differ, we call
daemon-reload and
issue a warning to stderr so both user or script catches it. Of course it may
need some additions
to dpkg and debhelper (or to plain debhelper only?) but this issue will be
eradicated for all packages
rebuilt after the update.
Of course I can implement the same check in postinst script of Xpra, but I
decided to discuss
my idea with involved colleagues.
What do you think?
--
Vasyl Gello
==
Certified SolidWorks Expert
Mob.:+380 (98) 465 66 77
E-Mail: vasek.ge...@gmail.com
Skype: vasek.gello
==
호랑이는 죽어서 가죽을 남기고 사람은 죽어서 이름을 남긴다
Bug#993236: Acknowledgement (calibre: in calibredb --timeout parameter seems to be ignored)
I do not know how to classify it. It seems that calibredb timeout is determined by timeout setting at calibre server side. I.e if I set at server side I set timeout to 600 seconds calibredb started to behave as expected. So maybe calibredb behaviour is correct, but information about server timeout should be put in calibredb manual. KJ -- http://stopstopnop.pl/stop_stopnop.pl_o_nas.html
Bug#995006: init-system-helpers: deb-systemd-helper does not call daemon-reload despite unit files were changed
Am 25.09.21 um 18:46 schrieb Vasyl Gello:
Hi Michael,
>daemon-reload is a costly operation, so we should try to avoid calling it
too excessively.
>
>So I'm not convinced it is a good idea to generate a daemon-reload (via
dh_installsystemd in postinst) for packages which do not actually (re)start
a unit as part of the upgrade process.
>
>By using "--no-enable --no-start" you are basically leaving the
management of the life cycle of the service entirely to the administrator.
Wouldn't you agree?
>
>Shouldn't the administrator then call "systemctl daemon-reload" as well?
>systemd will even warn him in cases a .service file has changed (which
thankfully doesn't happen too often)
>
>Is this actually an issue in practice? Do you have bug reports where
users of your xpra package have asked for this?
I realize daemon-reload is a costly operation, and I also realize the unit
in question is used by proxy module of Xpra, which is optional.
That's why Dmitry intentionally left it for system administrators to
configure.
Your point that typically units are not changed daily is also perfectly
valid.
However, speaking of "Shouldn't the administrator then call "systemctl
daemon-reload" as well?"…
No, if one uses unattended-upgrades or any other automation like auter
or puppet etc.
Server gets rebooted or service gets restarted and start-up fails due to
requirement of
"daemon-reload" or worse, starts with previous configuration which fails
too.
A reboot is not relevant here.
And if you use an automation framework like puppet, you can just as well
add a daemon-reload there if you manage the service via puppet.
What I suggest is slightly different Debian-wise. We do have list of
conffiles and list of files
installable by the package. What prevents us from scanning the list for
known locations
of systemd units ({/usr}/lib/systemd/{system,user}?) and compare them by
hash or by diff
just like we do it with conffiles? If the units, timers, etc differ, we
call daemon-reload and
issue a warning to stderr so both user or script catches it. Of course
it may need some additions
to dpkg and debhelper (or to plain debhelper only?) but this issue will
be eradicated for all packages
rebuilt after the update.
systemd already warns you, if you (manually) try to restart a service
that has been modified on disk.
So I don't see the use case here.
Again, you you have any bug reports where users actually ask for this?
OpenPGP_signature
Description: OpenPGP digital signature
Bug#995006: init-system-helpers: deb-systemd-helper does not call daemon-reload despite unit files were changed
> Again, you you have any bug reports where users actually ask for this? No, I am experiencing this as a user who builds development version of Xpra for company and personal use. Version 4.x is not in Debian yet, and I haven't seen any reports from users making use of Xpra proxy server on Debian yet. -- Vasyl Gello == Certified SolidWorks Expert Mob.:+380 (98) 465 66 77 E-Mail: vasek.ge...@gmail.com Skype: vasek.gello == 호랑이는 죽어서 가죽을 남기고 사람은 죽어서 이름을 남긴다
Bug#994969: jackd2: segfaults after today's upgrade of other Debian testing packages
On 2021-09-25 15:31:31 +0200, Francesco Poli wrote: > On Sat, 25 Sep 2021 12:25:16 +0200 Sebastian Ramacher wrote: > > [...] > > So this is crashing somewhere during the initialization of libglibmm. > > Hence I'm reassigning to libglibmm. > [...] > > Thanks, Sebastian! > > > By the way, I am now wondering whether I really need jackd2-firewire. > Maybe I can keep it out of my system, even after this bug gets fixed?!? > I don't think I have a FireWire port, hence maybe the JACK FireWire > support is useless to me. > Could you please confirm? If you don't have a firewire port, then jackd2-firewire is of no use. Cheers > > -- > http://www.inventati.org/frx/ > There's not a second to spare! To the laboratory! > . Francesco Poli . > GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE -- Sebastian Ramacher signature.asc Description: PGP signature
Bug#992863: modsecurity-crs 3.1.0-1+deb10u2 flagged for acceptance
package release.debian.org tags 992863 = buster pending thanks Hi, The upload referenced by this bug report has been flagged for acceptance into the proposed-updates queue for Debian buster. Thanks for your contribution! Upload details == Package: modsecurity-crs Version: 3.1.0-1+deb10u2 Explanation: fix request body bypass issue [CVE-2021-35368]
Bug#993034: sabnzbdplus 2.3.6+dfsg-1+deb10u2 flagged for acceptance
package release.debian.org tags 993034 = buster pending thanks Hi, The upload referenced by this bug report has been flagged for acceptance into the proposed-updates queue for Debian buster. Thanks for your contribution! Upload details == Package: sabnzbdplus Version: 2.3.6+dfsg-1+deb10u2 Explanation: prevent directory escape in renamer function [CVE-2021-29488]
Bug#993228: gthumb 3.6.2-4+deb10u1 flagged for acceptance
package release.debian.org tags 993228 = buster pending thanks Hi, The upload referenced by this bug report has been flagged for acceptance into the proposed-updates queue for Debian buster. Thanks for your contribution! Upload details == Package: gthumb Version: 3.6.2-4+deb10u1 Explanation: fix heap-based buffer overflow issue [CVE-2019-20326]
Bug#991768: wireguard-dkms: wireguard-dmks autoinstall fails, not matching BUILD_EXCLUSIVE directive in Bullesye
Package: wireguard-dkms Version: 1.0.20210219-1 Followup-For: Bug #991768 Still an issue. However, wireguard works. root@fgx-laptop:~# dpkg-reconfigure wireguard-dkms -- Deleting module version: 1.0.20210219 completely from the DKMS tree. -- Done. Loading new wireguard-1.0.20210219 DKMS files... Building for 5.10.0-8-amd64 Building initial module for 5.10.0-8-amd64 Error! The /var/lib/dkms/wireguard/1.0.20210219/5.10.0-8-amd64/x86_64/dkms.conf for module wireguard includes a BUILD_EXCLUSIVE directive which does not match this kernel/arch. This indicates that it should not be built. Skipped. root@fgx-laptop:~# Best regards, Dario Susman -- System Information: Debian Release: 11.0 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-8-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages wireguard-dkms depends on: ii dkms 2.8.4-3 ii perl 5.32.1-4+deb11u1 Versions of packages wireguard-dkms recommends: ii wireguard1.0.20210223-1 ii wireguard-tools 1.0.20210223-1 wireguard-dkms suggests no packages. -- no debconf information
Bug#993898: btrbk 0.27.1-1+deb10u1 flagged for acceptance
package release.debian.org tags 993898 = buster pending thanks Hi, The upload referenced by this bug report has been flagged for acceptance into the proposed-updates queue for Debian buster. Thanks for your contribution! Upload details == Package: btrbk Version: 0.27.1-1+deb10u1 Explanation: fix arbitrary code execution issue [CVE-2021-38173]
Bug#994628: gexiv2: Please package 0.12.2 or higher
On Sat, 18 Sep 2021 19:02:16 -0400 Jeremy Bicha wrote: > Please package the new version of gexiv2. For GIMP master branch we are also waiting for at least version 0.12.2 to land. We have a long standing bug with many duplicates that requires 0.12.2, see: https://gitlab.gnome.org/GNOME/gimp/-/issues/5863 -- Jacob Boerema
Bug#993396: flatpak 1.10.3-0+deb11u1 flagged for acceptance
package release.debian.org tags 993396 = bullseye pending thanks Hi, The upload referenced by this bug report has been flagged for acceptance into the proposed-updates queue for Debian bullseye. Thanks for your contribution! Upload details == Package: flatpak Version: 1.10.3-0+deb11u1 Explanation: new upstream stable release; don't inherit an unusual $XDG_RUNTIME_DIR setting into the sandbox
Bug#993655: gnome-shell 3.38.6-1~deb11u1 flagged for acceptance
package release.debian.org tags 993655 = bullseye pending thanks Hi, The upload referenced by this bug report has been flagged for acceptance into the proposed-updates queue for Debian bullseye. Thanks for your contribution! Upload details == Package: gnome-shell Version: 3.38.6-1~deb11u1 Explanation: new upstream stable release; fix freeze after cancelling (some) system-modal dialogs; fix word suggestions in on-screen keyboard; fix crashes
Bug#993656: mutter 3.38.6-2~deb11u1 flagged for acceptance
package release.debian.org tags 993656 = bullseye pending thanks Hi, The upload referenced by this bug report has been flagged for acceptance into the proposed-updates queue for Debian bullseye. Thanks for your contribution! Upload details == Package: mutter Version: 3.38.6-2~deb11u1 Explanation: new upstream stable release; kms: Improve handling of common video modes that might exceed the possible bandwidth; ensure valid window texture size after viewport changes
Bug#995071: argyll: USB devices not found on big-endian (powerpc)
Package: argyll Version: 2.2.0+repack-1 Severity: important Tags: upstream Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** After installing argyll and enabling the appropriate udev rules, argyll fails to enumerate USB-based colorimeters and spectrometers on PowerPC (big-endian, 32-bit). Specifically, 'spotread -?' does not list any usb devices connected to the system. I can find no means of debugging why the device (an i1Display Pro Plus) fails to be detected, but it enumerates fine on my i386 and amd64 machines with the same udev rules. Manually setting the permissions on the appropriate /dev/bus/usb/*/* node does not fix things, either, so I am relatively sure this is not a simple permissions problem. I suspect that USB PID's and Vendor ID's are being read in an endian-specific (and incorrect) manner. Argyll should be able to run on big-endian machines as well as little-endian ones. The only way I was able to profile this machine was to run Argyll on an i386 system with X forwarding to the powerbook's display. As a side-note, I noticed that my argyll-ref package was out of date when I ran reportbug; I just upgraded it to 2.2.0+repack-1 and nothing changed. -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: powerpc (ppc) Foreign Architectures: amd64, i386 Kernel: Linux 5.13.0-rc2-wyatt Kernel taint flags: TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) LSM: AppArmor: enabled Versions of packages argyll depends on: ii argyll-ref 2.0.1+repack-2 ii libc62.31-12 ii libjpeg62-turbo 1:2.0.6-2 ii libpng16-16 1.6.37-3 ii libssl1.11.1.1k-1 ii libtiff5 4.2.0-1 ii libx11-6 2:1.7.1-1 ii libxext6 2:1.3.3-1.1 ii libxinerama1 2:1.1.4-2 ii libxrandr2 2:1.5.1-1 ii libxss1 1:1.2.3-1 ii libxxf86vm1 1:1.1.4-1+b2 Versions of packages argyll recommends: ii libpam-elogind-compat [libpam-systemd] 1.3 ii udev247.3-1 Versions of packages argyll suggests: pn argyll-doc ii colord1.4.5-3 pn gir1.2-colordgtk-1.0 -- no debconf information
Bug#995072: nmu: tripwire_2.4.3.7-3
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu X-Debbugs-Cc: 994...@bugs.debian.org tripwire now segfaults when it tries to read information about a file. Rebuilding the package from source makes the problem go away. The problem appeared to start after the libc6 update to 2.32. I suspect this is because tripwire is statically linked, and there are known issues with static linking with libc6 across version releases because the internal API to nsswitch modules changes. This is consistent with the pattern of segfaults, since it appears to happen around the point where tripwire would try to resolve a numeric UID or GID to a name. If this is correct, a binNMU against the latest libc6 should fix the problem. I have tested this by rebuilding the source package with no changes in a sid chroot and confirmed the resulting package works correctly. nmu tripwire_2.4.3.7-3 . ANY . unstable . -m "Rebuild with libc6 2.32"
Bug#995073: gitlab: yarnpkg fails with error An unexpected error occurred: "Release not found: 2.4.2".
Package: gitlab Version: 13.12.9+ds1-1~fto10+1 Severity: grave Justification: renders package unusable Dear Maintainer, installing gitlab 13.12.9+ds1-1~fto10+1 on buster amd64 fails with: Installing node modules... Resolving 2.4.2 to a url... error An unexpected error occurred: "Release not found: 2.4.2". info If you think this is a bug, please open a bug report with the information provided in "/var/lib/gitlab/yarn-error.log". info Visit https://yarnpkg.com/en/docs/cli/policies for documentation about this command. -- System Information: Debian Release: 10.10 APT prefers oldstable-proposed-updates-debug APT policy: (500, 'oldstable-proposed-updates-debug'), (500, 'oldstable-debug'), (500, 'oldstable'), (100, 'buster-fasttrack'), (100, 'buster-backports') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-0.bpo.8-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=sk_SK.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: unable to detect Versions of packages gitlab depends on: ii asciidoctor 2.0.10-2~bpo10+1 pn bc ii bundler 2.1.4-2~bpo10+1 ii bzip2 1.0.6-9.2~deb10u1 pn dbconfig-pgsql | dbconfig-no-t ii debconf [debconf-2.0] 1.5.71 pn gitlab-common pn gitlab-workhorse ii libruby2.7 [ruby-rexml] 2.7.3-2~fto10+1 ii lsb-base10.2019051400 ii msmtp-mta [mail-transport-agen 1.8.3-1 ii nginx-full [nginx] 1.14.2-2+deb10u4 pn node-autosize pn node-axios pn node-babel-loader pn node-babel-plugin-lodash pn node-babel7 pn node-bootstrap ii node-brace-expansion1.1.8-1 ii node-cache-loader 4.1.0-6~bpo10+1 pn node-chart.js pn node-clipboard pn node-codemirror pn node-compression-webpack-plugi pn node-copy-webpack-plugin ii node-core-js3.6.1-2~bpo10+2 ii node-css-loader 5.0.1+~cs14.0.5-1~bpo10+1 pn node-d3 pn node-d3-scale pn node-d3-selection pn node-dateformat pn node-exports-loader ii node-file-loader6.2.0-2~bpo10+1 pn node-font-awesome pn node-fuzzaldrin-plus ii node-glob 7.1.6-1~bpo10+1 ii node-imports-loader 0.8.0-2~bpo10+1 pn node-jed ii node-jquery 3.5.1+dfsg-4~bpo10+1 pn node-jquery-ujs pn node-js-cookie ii node-js-yaml3.13.1+dfsg-2~bpo10+1 pn node-jszip pn node-jszip-utils pn node-katex ii node-lodash 4.17.21+dfsg+~cs8.31.189.20210220-1~bpo10+1 pn node-marked pn node-mermaid ii node-minimatch 3.0.4-3 pn node-mousetrap pn node-pdfjs-dist pn node-popper.js pn node-prismjs pn node-prosemirror-markdown pn node-prosemirror-model pn node-raven-js ii node-raw-loader 4.0.2-2~bpo10+1 pn node-style-loader pn node-three-orbit-controls pn node-three-stl-loader ii node-timeago.js 4.0.2-2~bpo10+1 pn node-underscore ii node-url-loader 4.1.1-3~bpo10+1 ii node-uuid 8.3.2+~8.3.0-1~bpo10+1 pn node-vue pn node-vue-resource pn node-vue-template-compiler pn node-webpack-stats-plugin ii node-worker-loader 3.0.5-2~bpo10+1 pn node-xterm ii nodejs 10.24.0~dfsg-1~deb10u1 pn ohai ii openssh-client 1:7.9p1-10+deb10u2 ii postgresql-client 11+200+deb10u4 ii postgresql-client-11 [postgres 11.12-0+deb10u1 pn postgresql-contrib pn puma ii rake12.3.1-3+deb10u1 pn redis-server pn ruby-ace-rails-ap pn ruby-acme-client ii ruby-actioncable [node-rails-a 2:6.0.3.7+dfsg-1~fto10+1 pn ruby-activerecord-explain-anal ii ruby-acts-as-taggable-on7.0.0-1~bpo10+1 pn ruby-addressable ii ruby-akismet3.0.0-1~bpo10+1 pn ruby-apollo-upload-server ii ruby-asana 0.10.3-1~bpo10+1 pn ruby-asciidoctor-include-ext pn ruby-asciidoctor-kroki ii ruby-asciidoctor-plantuml 0.0.12-1~bpo10+1 pn ruby
Bug#995059: ITP: cubeb -- cross platform audio library
Package: wnpp Severity: wishlist Owner: Andrea Pappacoda X-Debbugs-Cc: debian-de...@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 * Package name: cubeb Version : 0.0~git20210801.6ce9596+ds-1 Upstream Author : Mozilla Foundation * URL : https://github.com/mozilla/cubeb * License : ISC Programming Lang: C++, C Description : Cross platform audio library cubeb is a cross platform audio library most notable for its use as the audio backend within Gecko, Mozilla's browser engine. It supports multiple audio backends and allows enumeration of audio devices and opening audio streams with control over latency, sample rate and more. This is a dependency of the yuzu emulator, see https://bugs.debian.org/947399 I'll upload the package to mentors soon. -BEGIN PGP SIGNATURE- iIoEARYIADIWIQRm3vFSgpkMIZnvqAGooSioqxzuSQUCYU8nlRQcYW5kcmVhQHBh cHBhY29kYS5pdAAKCRCooSioqxzuSW64AQD24d7gTbE/jpXmO4uwIfqNvlvNkdy1 5vJuIk81nphCvgD+JcWY6C3kV7VM9O0BfAA/MoFjoBM+5mmnPbMzqEU5Wws= =gpwq -END PGP SIGNATURE-
