Bug#1068024: revert to version that does not contain changes by bad actor
On Fri, 29 Mar 2024 22:32:23 +0100 Aurelien Jarno wrote: > Having dpkg in that list means that such downgrade has to be planned > carefully. Might be easier overall to spend that effort on a hard switch to zstd instead. mfG mow
Bug#1037346: cyrus-imapd: all emails disappeared after upgrading from bullseye to bookworm (similar to #1007965)
Hi, I had the same problem (mails were not displayed in the mail client any more after upgrading from Bullseye to Bookworm). What worked in the end for me was this: - restored /var/lib/cyrus/ and /var/spool/cyrus/ from backup, to the old state from before the Debian upgrade. - built Cyrus 3.4.6, and installed and started it temporarily. The mails were now visible in the mail client again. - upgraded to the normal Cyrus version from Bookworm. The mails were still visible in the mail client. And since I had already kept the server running for some hours with the broken mail archive, I then also restored the getmail6 status files (/var/lib/getmail) to the state from before the Debian upgrade. This caused getmail to re-fetch the mails that were missing. I don't know how to detect whether the mail archive was really migrated successfully; but since Cyrus 3.6.1 is now running and Thunderbird can connect and sees all mails, I suppose the migration was successful? Regarding the build of Cyrus 3.4.6, in the end I built it using the existing Debian packaging data, and using the "debocker" tool to build inside a clean Docker container. Unfortunately debocker will always run the "lintian" tool to check the package, which failed for me with error "E: cyrus-common: depends-on-obsolete-package Depends: lsb-base". I didn't know how to fix this error or how to correctly disable the lintian step; so I edited the debocker files to disable this check. Very ugly, but it worked. So from my notes, these must have been the steps that I did for building the Cyrus 3.4.6 Debian package: - installed "debocker" and "devscripts" packages: `sudo apt install debocker devscripts` - downloaded the Debian cyrus-imapd packaging info: `debcheckout cyrus-imapd` - downloaded the original source package: `wget https://github.com/cyrusimap/cyrus-imapd/releases/download/cyrus-imapd-3.4.6/cyrus-imapd-3.4.6.tar.gz` - renamed the source package so it would be found in the next steps: `mv cyrus-imapd-3.4.6.tar.gz cyrus-imapd_3.4.6.orig.tar.gz` - `cd cyrus-imapd/` - started new Git branch at the state of Cyrus 3.4.3-4: `git checkout -b cyrus-3.4.6 debian/3.4.3-4` - added changelog entry: `dch -v '3.4.6-1.1' "use new upstream version 3.4.6"` - the warning about missing DEBEMAIL can be ignored - committed change: `git commit debian/changelog -m 'update changelog'` - modified the "debocker" template files to disable the lintian step: `sudo nano /usr/share/debocker/bundle-files/steps/05-build` and then commented out the line for "lintian --pedantic --display-info *.changes" - created build bundle: `debocker bundle --image debian:bookworm -f "-b -us -uc"` - did the actual build: `sudo debocker build-bundle ../cyrus-imapd_3.4.6-1.1_bundle.tar` - whether the "sudo" is necessary depends on your local Docker setup - the build took a while (half an hour or more?); and then there was a message like "LOG Build successful", and there were lots of Cyrus packages in the current directory. I then copied cyrus-clients_3.4.6-1.1_amd64.deb, cyrus-common_3.4.6-1.1_amd64.deb and cyrus-imapd_3.4.6-1.1_amd64.deb to the server and installed them. Remember to undo the change to the debocker file (/usr/share/debocker/bundle-files/steps/05-build) after the build. Kind regards, Oliver
Bug#1062250: Please add ucd-snmp/lmSensors MIB module to monitor lm_sensors data
Package: net-snmp Version: 5.9.3+dfsg-2 Severity: wishlist snmpd currently is build with the MIB-module: ucd-snmp/lmsensorsMib on Linux. While this causes linkage against libsensors and the dependency for that is also added, it seems that this is insufficient to actually list sensors information. On a system reporting temperatures via "sensors", trying to enumerate the corresponding OIDs via: snmpwalk -v 2c -c public localhost LM-SENSORS-MIB::lmSensors yields no result. According to upstream "documentation" in a code comment at the beginning of the implementation of "lmSensors" in net-snmp[0], it seems the MIB-module: ucd-snmp/lmSensors is required for this to work as expected (i.e. provide sensors data). It would be great and likely helpful to many Debian users if this MIB-module could be added to the build configuration in the rules file. Many thanks in advance! [0] https://github.com/net-snmp/net-snmp/blob/65b413fe634155d067e91c25628dac18b0307097/agent/mibgroup/ucd-snmp/lmSensors.c
Bug#996329: pal: re glib error(s)
Package: pal Version: 0.4.3-9 Followup-For: Bug #996329 Actually appears to be the same bug as reported earlier. I don't think it's important, the duplicate should be closed. Interactive mode obviously got never fully implemented to put it mildly, and what's left is aging badly. Not too surprising considering the application is 20 years old, the current version about 15 and the package is unmaintained. If the curses interface wasn't entirely useless by now, its usefulness could still be doubted. It should have been left out from the package, that would've also removed the ncurses dependencies, perhaps glib's too. Pal is still doing its trick as a simple command line utility, or what it originally was likely intented to be. But that would probably call for a maintainer. At least it should be made clear that the .pal files are supposed to be maintained manually, it's easy to crash the whole thing from the TUI, not much harder to garble your event files. Regards, Oliver
Bug#1060305: libifd-cyberjack6: Package is out of date. 3 new hardware devices are not supported, which are already supported in upstream
Package: libifd-cyberjack6 Version: 3.99.5final.sp14-2 Severity: important Tags: a11y upstream X-Debbugs-Cc: s...@kernelport.com, siret...@tauware.de, kreuzritter2...@gmx.de The current version available in the Debain Stable's (12) repository is 3.99.5final.sp14-2 and 3.99.5final.sp14-2+b1 in unstable (SID). But the manufacturer's version is 3.99.5final.sp16. See here for the upstream deb package: https://support.reiner-sct.de/downloads/LINUX/V3.99.5_SP16/libifd- cyberjack6_3.99.5final.sp16_amd64_d12.deb And the source release: https://support.reiner-sct.de/downloads/LINUX/V3.99.5_SP16/pcsc- cyberjack-3.99.5final.SP16.tar.bz2 The changelog of this much newer version 3.99.5final.sp16 shows the following: Begin changelog: pcsc-cyberjack (3.99.5final.sp16) unstable; urgency=low * add REINER SCT cyberJack RFID standard EN -- Frank Neuber Thu, 26 Oct 2023 22:46:54 +0200 pcsc-cyberjack (3.99.5final.sp15) unstable; urgency=low * add REINER SCT cyberJack wave HUN * add REINER SCT cyberJack RFID komfort FON -- Frank Neuber Fri, 01 Oct 2021 08:11:04 + pcsc-cyberjack (3.99.5final.sp14) unstable; urgency=low * Update to the Reiner-SCT repository rev cyberJack@1454 -- Frank Neuber Mon, 02 Dec 2019 16:57:46 +0100 ### End changelog This means, that the devices: * REINER SCT cyberJack RFID standard EN * REINER SCT cyberJack wave HUN and * REINER SCT cyberJack RFID komfort FON are not supported in the current version of Debian. The device REINER SCT cyberJack RFID komfort FON device is for users with disabilities. As of now, all three devices are not supported by Debian 12 because this package is out of date. You should also read bug report: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1010675 It might be related to this bug #1010675, because the new upstream version ships as .bz2 file and in the other bug report has someone mentioned, that the old uscan filter does only search for .tar.gz files. But this is definitely not a minor bug, like the this other bug report claims, when you can't use these new three devices. The devices * REINER SCT cyberJack wave HUN and * REINER SCT cyberJack RFID komfort FON got a patch in upstream on Fri, 01 Oct 2021. Debian stable was released in June 10, 2023. So it's high time that the new version is added to Debian SID and a Debian backport version for Debian 12 or an update with the next Debian 12 point release is added. After all, this is about driver support and support for new hardware. -- System Information: Debian Release: 12.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-17-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.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 libifd-cyberjack6 depends on: ii libc6 2.36-9+deb12u3 ii libgcc-s1 12.2.0-14 ii libstdc++612.2.0-14 ii libusb-1.0-0 2:1.0.26-1 ii pcscd 1.9.9-2 libifd-cyberjack6 recommends no packages. Versions of packages libifd-cyberjack6 suggests: ii pcsc-tools 1.6.2-1 -- no debconf information changelog.Debian.gz Description: application/gzip
Bug#1059766: Support for tokenized interface identifiers with ifupdown in /etc/network/interfaces
Package: ifupdown Version: 0.8.41 Severity: wishlist Issue = Using "ip token", a command to specify a fixed Interface ID for IPv6 addressing, is not yet abstracted by ifupdown. A common use case are dynamic-prefix environments in which a fixed interface ID is wanted, e.g. for firewall openings of home routers etc. Using "ip token" manually requires several non-obvious "hacks" in /etc/network/interfaces. Functional Workaround = Using the following interface config: auto eth0 iface eth0 inet dhcp iface eth0 inet6 manual pre-up ip token set ::192.168.1.35 dev eth0 post-up IF_ADDRESS=:: IF_NETMASK=0 /lib/ifupdown/settle-dad.sh yields a functional setup. This takes care of two things: - Setting the "ip token" before the interface is first taken up. This is required to disable other addressing, such as EUI-64. - Ensuring DAD is settled for all dynamic addresses on the interface, e.g. global addresses and ULAs, so IPv6 is fully up before other services start. Proposed solution = I initially considered something like: auto eth0 iface eth0 inet dhcp iface eth0 inet6 manual token ::192.168.1.35 to be a good solution, see also this report for bridge-utils (since my actual case is with a bridge, which has the additional problem that the bridge's pre-up is not accessible): https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1059332 However, since settling DAD is also required, potentially this would be easier / more straightforward, i.e. using "token" instead of "manual" as scheme? auto eth0 iface eth0 inet dhcp iface eth0 inet6 token token ::192.168.1.35
Bug#1059332: bridge-utils: Using tokenized interface identifiers with bridge-utils ifupdown via /etc/network/interfaces fails
Package: bridge-utils Version: 1.7.1-1 Severity: normal Issue = Using "ip token", a command to specify a fixed Interface ID for IPv6 addressing, fails with bridges in Debian Bookworm, as the token needs to be set in between interface creation and taking the interface up. /lib/bridge-utils/ifupdown.sh currently does not allow to hook into that stage. Using the following interface config: auto br0 iface br0 inet dhcp bridge_ports enp1s0 bridge_hw 12:34:56:78:90:12 iface br0 inet6 manual pre-up ip token set ::192.168.1.35 dev br0 causes the system to end up with the usual EUI-64 based global IPv6 addresses in addition to the token-based addresses. The kernel then keeps the EUI-64 based addresses in addition to the wanted token-based addresses until they expire, at which point only the tokized interface identifiers keep being used. Workaround == As a "hack", the following workaround configuration can be used: auto br0 iface br0 inet dhcp pre-up brctl addbr br0 pre-up ip link set dev br0 address 12:34:56:78:90:12 pre-up ip token set ::192.168.1.35 dev br0 bridge_ports enp1s0 bridge_hw 00:1e:06:45:2e:fa iface br0 inet6 manual This causes the "ip token" command to apply between interface creation and taking the interface up, which works as expected (i.e. the system only has global addresses based on the token). Of course, any required feature dealt with in /lib/bridge-utils/ifupdown.sh in between interface creation and taking the interface up needs to be replicated manually via pre-up. Proposed fix Adding the lines: if [ "$IF_BRIDGE_TOKEN" ] then ip token set $IF_BRIDGE_TOKEN dev $IFACE fi right before: # We activate the bridge ip link set dev $IFACE up in /lib/bridge-utils/ifupdown.sh and using the interface config: auto br0 iface br0 inet dhcp bridge_ports enp1s0 bridge_hw 12:34:56:78:90:12 bridge_token ::192.168.1.35 fixes the problem. However, this necessarily introduces a dependency on iproute2 (i.e. it should probably be a "recommends", existence of "/sbin/ip" might be necessary to check, documentation needs to be adapted).
Bug#1055804: kio: Copying from NFS or FAT32 not supporting all features via kio (e.g. dolphin) triggers endless loop
Package: kio Version: 5.78.0-5 Severity: important Tags: patch X-Debbugs-Cc: freyerm...@physik.uni-bonn.de The version of kio shipped with Debian 11 is affected by: https://bugs.kde.org/show_bug.cgi?id=441446 This issue can be triggered e.g. copying from a FAT32 FS to an FS supporting SELinux attributes, or from an NFS share not supporting ACLs to an external USB drive. A patch is available as: https://invent.kde.org/frameworks/kio/-/commit/d4e0b6223cdc740a75b001badd09aded41a89723 -- System Information: Debian Release: 11.8 APT prefers oldstable-updates APT policy: (500, 'oldstable-updates'), (500, 'oldstable-security'), (500, 'oldstable-proposed-updates-debug'), (500, 'oldstable-debug'), (500, 'oldstable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-26-amd64 (SMP w/12 CPU threads) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages kio depends on: ii kded5 5.78.0-2 ii libacl1 2.2.53-10 ii libc6 2.31-13+deb11u7 ii libgcc-s1 10.2.1-6 ii libgssapi-krb5-2 1.18.3-6+deb11u4 ii libkf5archive55.78.0-2 ii libkf5authcore5 5.78.0-2 ii libkf5codecs5 5.78.0-2 ii libkf5completion5 5.78.0-3 ii libkf5configcore5 5.78.0-4 ii libkf5configwidgets5 5.78.0-2 ii libkf5coreaddons5 5.78.0-4 ii libkf5dbusaddons5 5.78.0-2 ii libkf5doctools5 5.78.0-2 ii libkf5i18n5 5.78.0-2 ii libkf5itemviews5 5.78.0-2 ii libkf5kiocore55.78.0-5 ii libkf5kiontlm55.78.0-5 ii libkf5kiowidgets5 5.78.0-5 ii libkf5notifications5 5.78.0-2 ii libkf5service-bin 5.78.0-2 ii libkf5service55.78.0-2 ii libkf5solid5 5.78.0-2 ii libkf5textwidgets55.78.0-2 ii libkf5wallet-bin 5.78.0-2 ii libkf5wallet5 5.78.0-2 ii libkf5widgetsaddons5 5.78.0-2 ii libkf5windowsystem5 5.78.0-2 ii libqt5core5a 5.15.2+dfsg-9 ii libqt5dbus5 5.15.2+dfsg-9 ii libqt5gui55.15.2+dfsg-9 ii libqt5network55.15.2+dfsg-9 ii libqt5qml55.15.2+dfsg-6 ii libqt5widgets55.15.2+dfsg-9 ii libqt5x11extras5 5.15.2-2 ii libqt5xml55.15.2+dfsg-9 ii libstdc++610.2.1-6 ii libxml2 2.9.10+dfsg-6.7+deb11u4 ii libxslt1.11.1.34-4+deb11u1 kio recommends no packages. kio suggests no packages. -- no debconf information
Bug#1053683: libsdbus-c++-dev: missing dependency on libsystemd-dev
Package: libsdbus-c++-dev Version: 1.1.0-3 Severity: normal Dear Maintainer, libsystemd-dev is a hard requirement for libsdbus-c++-dev, please add it to the package dependencies. Thanks! ~oliver -- System Information: Debian Release: bookworm/sid APT prefers jammy-updates APT policy: (500, 'jammy-updates'), (500, 'jammy-security'), (500, 'jammy'), (100, 'jammy-backports') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.2.0-34-generic (SMP w/12 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libsdbus-c++-dev depends on: ii libsdbus-c++1 1.1.0-3 libsdbus-c++-dev recommends no packages. Versions of packages libsdbus-c++-dev suggests: pn libsdbus-c++-bin -- no debconf information
Bug#941214: Completion for mutt's -a command line switch
On 20 Jun, martin f krafft wrote: > mutt allows attaching files from the command-line: > > mutt -a /file/one /file/two /file/three -- … > > Basically, the rules are: -a takes a list of files, terminated by --. > > Zsh's completion of mutt treats the argument to -a as optional: > > '*-a[attach file using MIME]::file attachment:_files' \ In theory, this should be possible with: '*-a[attach file using MIME]:*--:file attachment:_files' \ However, _mutt also calls _arguments with -S so if it sees -- it takes that as the end of all options and only completes recipients thereafter. Oliver
Bug#1037629: Upgrade libtins to latest version?
Hello, the mentioned bug is fixed in the latest version of libtins: /usr/include/tins/ip_address.h:220:31: error: ‘uint32_t’ is not a member of ‘std’; did you mean ‘wint_t’? I have also created this bug report to ask for the upgrade on 2023-08-21: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1050161 However on 2023-08-24 the package was removed from testing, I guess because of this open bug report? https://tracker.debian.org/news/1456620/libtins-removed-from-testing/ So can the package be added back, and get upgraded to the latest version? Thanks! -- - Oliver Smith https://www.sysmocom.de/ === * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte
Bug#1050161: libtins build against ip_address.h fails
Package: libtins Version: 4.0-1 Building against libtins 4.0-1 on Debian testing and unstable fails: [ 142s] /usr/include/tins/ip_address.h: In member function ‘std::size_t std::hash::operator()(const Tins::IPv4Address&) const’: [ 142s] /usr/include/tins/ip_address.h:220:31: error: ‘uint32_t’ is not a member of ‘std’; did you mean ‘wint_t’? [ 142s] 220 | return std::hash()(addr); [ 142s] | ^~~~ [ 142s] | wint_t This has been fixed in the 4.5 release: https://github.com/mfontanini/libtins/pull/496 Can libtins be upgraded to 4.5 to resolve this? Thanks! -- - Oliver Smith https://www.sysmocom.de/ === * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte
Bug#1042977: crossfire-server does not work with Python 3.11
Package: crossfire-server
Version: 1.75.0-5+b2
Severity: important
Dear Maintainer,
It seems crossfire-server was compiled using the
PyUnicode_EncodeRawUnicodeEscape workaround for Python 3.3 - 3.9 which is
deprecated in Python 3.11.
On each start crossfire-server logs the following error message in
/var/log/crossfire/logfile:
23/08/03 16:56:50 [II] plugins: loading cfanim.so
23/08/03 16:56:50 [II] plugins: loading cfcitybell.so
23/08/03 16:56:50 [II] plugins: loading cfpython.so
23/08/03 16:56:50 [EE] Error trying to load
/usr/lib/x86_64-linux-gnu/crossfire/plugins/cfpython.so:
/usr/lib/x86_64-linux-gnu/crossfire/plugins/cfpython.so: undefined symbol:
PyUnicode_EncodeRawUnicodeEscape
Subsequently game functions that require a python script do not work. Instead
errors are logged like:
[EE] The requested plugin doesn't exist: Python at 11/23 in map Old City
[EE] The requested plugin doesn't exist: Python at 5/34 in map world_105_115
[EE] The requested plugin doesn't exist: Python at 11/7 in map Starting House
[EE] The requested plugin doesn't exist: Python at 1/3 in map apartments
However, nm -gD cfpython.so | grep PyUnicode finds the symbol in
/usr/lib/crossfire/plugins/cfpython.so:
U PyUnicode_AsUnicode
U PyUnicode_AsUTF8
U PyUnicode_AsUTF8String
U PyUnicode_DecodeUnicodeEscape
U PyUnicode_EncodeRawUnicodeEscape
U PyUnicode_FromString
but it is missing from libpython3.11.so (in Debian bookworm). It was still
available in libpython3.9 in Debian buster.
I found this in the upstream source in plugins/cfpython/cjson.c :
if (PyUnicode_Check(string)) {
// PyUnicode_EncodeRawUnicodeEscape() is deprecated as of Python 3.3,
scheduled for removal in Python 3.11
#ifndef IS_PY3K3
/* HACK: Workaround for crash bug in Python3's
PyUnicode_AsRawUnicodeEscapeString... */
str = PyUnicode_EncodeRawUnicodeEscape(PyUnicode_AS_UNICODE(string),
PyUnicode_GET_SIZE(string));
#else
// The Python docs recommend using PyUnicode_AsRawUnicodeEscapeString()
or PyUnicode_AsEncodedString() over PyUnicode_EncodeRawUnicodeEscape().
str = PyUnicode_AsRawUnicodeEscapeString(string);
#endif
So it seems IS_PY3K3 was #defined at compile time, even though it should not be
for Python 3.11?
Kind regards
Oliver
-- System Information:
Debian Release: 12.1
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 6.1.0-10-amd64 (SMP w/12 CPU threads; PREEMPT)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8),
LANGUAGE=de_DE:de
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages crossfire-server depends on:
ii bzip21.0.8-5+b1
ii crossfire-common 1.75.0-5
ii crossfire-maps 1.75.0+dfsg1-1
ii init-system-helpers 1.65.2
ii libc62.36-9+deb12u1
ii libcrypt11:4.4.33-2
ii libcurl3-gnutls 7.88.1-10+deb12u1
ii libpython3.113.11.2-6
ii python3 3.11.2-1+b1
ii python3-bsddb3 6.2.9-2+b4
crossfire-server recommends no packages.
crossfire-server suggests no packages.
-- Configuration Files:
/etc/crossfire/dm_file changed [not included]
-- no debconf information
Bug#1042868: kde-plasma-desktop: KDE Lockscreen Wakes Monitor up After It Is Turned Off via Escape Button and kscreen-doctor
Package: kde-plasma-desktop Version: 5:142 Severity: normal X-Debbugs-Cc: place4...@gmail.com Dear Maintainer, When the screen is locked, either via timeout or shortcut, I am unable to turn off the monitor. Seconds after pressing Escape, the lockscreen turns the monitor back on. I also tried to run a command that listens to the lock screen event, ``` kscreen-doctor -d off ``` but this too, cannot prevent the monitor from waking itself after it is turned off. Related posts: https://bugs.kde.org/show_bug.cgi?id=422455 https://bugs.kde.org/show_bug.cgi?id=462695 After reading the above posts, I think the problem might lie in the package `kidletime`, since this patch claims to fix the problem: https://bugs.kde.org/show_bug.cgi?id=462695#c40 https://src.fedoraproject.org/rpms/kf5-kidletime/c/2a096ad8d7e9ab9a838156021991d86e76971117?branch=rawhide -- System Information: Wayland session, Debian Bookworm, everything is up to date. Debian Release: 12.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-10-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages kde-plasma-desktop depends on: ii kde-baseapps 4:22.12.3+5.142 ii plasma-desktop4:5.27.5-2 ii plasma-workspace 4:5.27.5-2 ii udisks2 2.9.4-4 ii upower0.99.20-2 Versions of packages kde-plasma-desktop recommends: ii kwin-x11 4:5.27.5-3 ii sddm 0.19.0-5 ii xserver-xorg 1:7.7+23 Versions of packages kde-plasma-desktop suggests: ii kdeconnect 22.12.3-1 -- no debconf information
Bug#1042360: RFP: open-vmdk -- tool for creating Open Virtual Appliances (OVAs)
Package: open-vmdk Severity: wishlist open-vmdk can be used to create OVA and OVF files, to deploy virtual machines for VMware (vSphere, or Fusion/Workstation). It contains two tools: * vmdk-convert to convert raw disk images to vmdk format * ova-compose to create OVF files, and OVAs with the vmdk file(s) URL: https://github.com/vmware/open-vmdk
Bug#963151: suboptimal libzstd usage due to different build/runtime versions
Package: tor Version: 0.4.7.13-1 Followup-For: Bug #963151 The same thing has again been popping up for a couple of months, we're just at a later version of course. Tor was compiled with zstd 1.5.2, but is running with zstd 1.5.4. For safety, we'll avoid using advanced zstd functionality. Unstable actually has 1.5.5 already. Looks like we'd need a rebuild while there's little pressing incentive; fair enough, as tor itself is up to date even in Bookworm. May not be a bug at all. Regards, Oliver
Bug#1006871: Bug is not fixed in pmacct 1.7.7 from bookworm
Package: pmacct X-Debbugs-Cc: deb...@seufer.de Version: 1.7.7-1+b1 Severity: important Dear Maintainer, this is not fixed in pmacct 1.7.7 from bookworm. Paolos patch is still valid: https://github.com/pmacct/pmacct/commit/73af9545ea33cd87846306f648f634063ac41765 Please fix this at least in Debian Bookworm 12 Stripped down configuration file to reproduce: daemonize: true pidfile: /var/run/pmacctd.pid pcap_interface: enp8s0f1 promisc: true plugins: pgsql[all] plugin_pipe_size: 1024 sql_db: pmacct sql_host: localhost sql_user: pmacct sql_passwd: *** sql_table_version: 5 sql_history: 1m sql_history_roundoff: m sql_refresh_time: 60 sql_dont_try_update: true aggregate[all]: src_mac,dst_mac,vlan,src_host,dst_host,src_port,dst_port,tos,proto,flows Then capture ICMP/ICMPv6 traffic. Best regards, Oliver Seufer
Bug#1036637: RFP: plio - "Pleasant Image Order", image viewer with many sort options
Package: wnpp Severity: wishlist Package name: plio Upstream Author: Oliver Bandel URL: https://codeberg.org/klartext/plio License: GPL-3.0-or-later Description: image viewer with many sort options and bulk renaming Programming Language: C Used libraries: SDL2, FreeImage, System-Libs PLIO is an image viewer that allows images to be sorted by many properties. Default sorting is name, but width, height, size, aspect ratio, modification time, brightness, color are possible also. After sorting, bulk renaming images is possible and easy (press 'r'). The new filenames reflect the order that was established by the sorting (integer index value prepended to basename). In case of sort-by-modification-time, the epoch with subseconds instead of the index number is prepended. (Using Index number is also possible - with two keystrokes.) Arbitrarily reordering of the images can also be done. (switch x-pos, switch y-pos, move current image to index position 0.) The images of a directory are represented as thumbnails in a 2D array (like sxiv does it). Additionally, directories are also represented by a thumbnail. The Image-View currently supports only fit-to-window, but more options might be added later. Navigation in x- and y-direction is possible not only in thumbview, but also while viewing the images. Moving in y-direction allows skimming through a huge collection of images quickly. So far all commands are given as keyboard-strokes. plio works best with tiling window managers, but intended usage is fullscreen mode anyway. The bulk-renaming allows the images to be renamed, so that the filenames reflect the order. Using other image viewers or working on the shell with the images can then be done, even when only listing by name. No database is used; thumb caching might be added later, but it is intended also in the future not to be dependent on databases. Cheers, Oliver Bandel
Bug#1035946: RFS: justbuild/1.1.0-1 [ITP] -- Justbuild generic build system
Hi Wookey On Tue, May 16, 2023 at 8:19 PM Wookey wrote: > I used 0~0-1 to start with. 0~ is a quite a good way of > versioning things like this that don't have versions. (that 0~ lets > you switch neatly to real versions in the future should they > appear). Adding git hashes mostly makes for unreadable versions and > doesn't add much IMHO, but we can do that if it's important. Yes, the git hash clutters up the version, but at least you can easily identify which exact commit is packaged. The date alone might not be sufficient, in particular with rebasing. > Debian generally tries to pick a version and make depending packages > work with it, rather than try to suport multiple versions unless it > really is necessary. I do not have a good feel for what the best > approach here is, and would greatly appreciate input from someone more > familiar with the codebase on what the best approach in debian might be. I see. I just wonder how useful such a package is. Many packages might have a hard time using it without significant upstream changes. Just as an example, even gRPC (another Google project itself) uses a 2 year old version, which is incompatible with what Fedora packaged last year, which is already incompatible with current master. It's kind of a mess... > I will put my unfinished project on salsa, file an ITP, and find my > notes, then mail you and we can see if we can sort this with a > reasonable level of effort. Sure, I would be very happy to help. Oliver
Bug#1035946: RFS: justbuild/1.1.0-1 [ITP] -- Justbuild generic build system
Hi Paul, On Tue, May 16, 2023 at 5:07 AM Paul Wise wrote: > Generally all build dependencies should be packaged separately instead. > > https://wiki.debian.org/EmbeddedCopies > > Many thanks for that hint. I'm basically aware of the build dependencies policy and all of my binary and header-only dependencies are satisfied from packages. However, my package additionally depends on 11 proto files (i.e., architecture-independent interface of data encoding [1]) from google-apis [2] and bazel-remote-apis [3] as a pure build dependency. In the past, it seems that there was made an exception for packages that depend on these proto files: - buildstream and bazel-bootstrap (both only build-dep) - bazel-bootstrap-source (seems temporary/hackish though) - golang-github-gogo-googleapis-dev and golang-github-grpc-ecosystem-grpc-gateway-dev (both even shipping these files in their deb package) Interestingly, none of these packages is mentioned in the list of source packages that embed code from other projects [4]. For that reason, I was initially hoping that embedding these files would be fine for my package as well, albeit as a tarball. Currently, I see 3 options: 1. Keep the tarballs in debian/third_party, which would be the cleanest solution for our bootstrap, _but_ according to your last message this is probably not a viable option for Debian. 2. If the problem is only the tarballs, I could unpack them and embed only the exact 11 proto files that we need and explicitly mention them in the copyrights file of course. 3. Taking the longer road and package google-apis and bazel-remote-apis first. However, that raises a few more questions: a. google-apis is not versioned/tagged upstream. What version would I use? I've seen that Fedora uses the version string "0-1.git". b. Where should proto files be installed to? I know that libprotobuf-dev puts it in /usr/include, but /usr/share could be also viable. What is the recommended location? c. As the file structure of google-apis changes rather frequently, should there be any prefix, so multiple versions could be installed in parallel? Could you please comment on which option you would suggest to take, and also briefly address the potential follow-up questions? Many thanks in advance, I really appreciate your help! Kind regards, Oliver [1] https://protobuf.dev/ [2] https://github.com/googleapis/googleapis [3] https://github.com/bazelbuild/remote-apis [4] https://salsa.debian.org/security-tracker-team/security-tracker/raw/master/data/embedded-code-copies
Bug#1035946: RFS: justbuild/1.1.0-1 [ITP] -- Justbuild generic build system
> > > I know that is is possible to create source packages consisting out of > more than 1 .orig.tar.gz. Maybe it is a better idea to split that > additional source into a new tar.gz. > > I'm not a DD, hence I can't sponsor your package anyway. Sorry! I see. That's already very helpful information. Many thanks for your help! Oliver
Bug#1035946: RFS: justbuild/1.1.0-1 [ITP] -- Justbuild generic build system
Dear Hilmar, I just updated the package again, with the upstream beta2 release. Could you please tell me if it is acceptable for Debian that I have build dependencies (proto files) in ./debian/third_party, with the copyright file explicity mentioning those? Many thanks! Oliver Hilmar Preuße schrieb am Do., 11. Mai 2023, 15:28: > On 5/11/23 15:11, Oliver Reiche wrote: > > Hi, > > > The source builds the following binary packages: > > > >justbuild - Justbuild generic build system > > > > To access further information about this package, please visit the > following URL: > > > >https://mentors.debian.net/package/justbuild/ > > > If you look at that page you see a few points, which needs to be > addressed. Please fix at least the lintian errors and warnings. > > The initial upload should not go to testing, either use unstable or > experimental. > > H. > -- > Testmail > >
Bug#1035946: RFS: justbuild/1.1.0-1 [ITP] -- Justbuild generic build system
Dear Hilmer, If you look at that page you see a few points, which needs to be > addressed. Please fix at least the lintian errors and warnings. > > The initial upload should not go to testing, either use unstable or > experimental. > I updated the package to fix the lintian issues and moved it to unstable. Many thanks for your help and quick response. Kind regards, Oliver >
Bug#1035946: RFS: justbuild/1.1.0-1 [ITP] -- Justbuild generic build system
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "justbuild": * Package name : justbuild Version : 1.1.0-1 Upstream contact : Oliver Reiche * URL : https://github.com/just-buildsystem/justbuild * License : Apache-2.0 * Vcs : https://github.com/just-buildsystem/justbuild Section : devel The source builds the following binary packages: justbuild - Justbuild generic build system To access further information about this package, please visit the following URL: https://mentors.debian.net/package/justbuild/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/j/justbuild/justbuild_1.1.0~beta1+1683736997-1.dsc Please note that this is currently a preliminary package (version 1.1.0~beta1+1683736997-1) for initial sponsor review. We plan to release the final upstream version 1.1.0 within the next days. Once a sponsor is found, we will address any possible issues and prepare an updated package ASAP. Changes for the initial release: justbuild (1.1.0~beta1+1683736997-1) testing; urgency=medium . * Initial release. (Closes: #1035930) Regards, -- Oliver Reiche
Bug#1035930: ITP: justbuild -- Justbuild generic build system
Package: wnpp Severity: wishlist Owner: Oliver Reiche X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: justbuild Version : 1.1.0 Upstream Author : Oliver Reiche * URL : https://github.com/just-buildsystem/justbuild * License : Apache-2.0 Programming Lang: C++, Python Description : Justbuild generic build system Justbuild is a generic build system supporting multi-repository builds. A peculiarity of the tool is the separation between global names and physical location on the one hand, and logical paths used for actions and installation on the other hand (sometimes referred to as "staging"). The language-specific information to translate high-level concepts (libraries, binaries) into individual compile action is taken from user-defined rules described by functional expressions. Justbuild is a build tool that shares similarities with Bazel and Buck2. Our main focus is on reproducible builds. We deeply integrated git in Justbuild to benefit from a-priori computed hashes of git repositories. Furthermore, Justbuild can spawn an execution service that can also be used as a single-node remote execution server for other build systems supporting the same remote execution protocol, such as Bazel and Buck2. We plan to actively maintain this package but are currently looking for a sponsor.
Bug#1034573: note: Note not setting non-default database path
Package: note Version: 1.3.26-3 Severity: normal Tags: patch Hey guys, due to a mistake in the package provided config file, if copied as is, changing the directory for the DBM backend has no effect. /usr/share/doc/note/examples/noterc.gz: 60c60 < dbm::directory = ~/.notedbm # directory --- > dbm::dbname = ~/.notedbm # directory The package appears to be unmaintained, perhaps QA or the Debian Perl Group could have a look into this. Regards, Oliver
Bug#1031643: some tests …
Hi Andi, On Sat, 8 Apr 2023 17:38:10 +0200 "Andreas B. Mundt" wrote: • However, I also ran an installation with the original, unpatched initrd and the boot parameters: 'auto=true priority=critical hostname=somename url=tftp://192.168.122.1 playbook=minimal.yml ---' That works fine too. The pressed file is [1] with minor, unrelated changes. So that's kind of confusing to me right now. FWIW, I've never used "priority=critical" on the kernel commandline. Maybe that is making the difference here? The full commandline I used is: initrd=boot/debian-initrd.gz interface=auto url=http://foreman.example.com/unattended/provision ramdisk_size=10800 root=/dev/rd/0 rw auto auto=true locale=en_US.UTF-8 netcfg/disable_dhcp=false ethdetect/prompt_missing_firmware=false hw-detect/load_firmware=false locale=en_US.UTF-8 hostname=laptop.example.com domain=example.com This commandline does not show any questions in Buster / Bullseye, but raises the hostname question in Bookworm alpha2 and rc1, and it's gone again in the patched version (while the preseed file in my case always specifies d-i netcfg/get_hostname and d-i netcfg/get_domain, but that's parsed too late in the game). Cheers, Oliver
Bug#1031643: Bug#1034062: netcfg prompts for hostname even though preseeded, preventing unattended installation
Hello Cyril,
Am 08.04.23 um 23:50 schrieb Cyril Brulebois:
Oliver Freyermuth (2023-04-08):
Interestingky, without the "hostname=" parameter, running hostname on
a tty (while the question is shown) echoes:
~ # hostname
?
I found that part slightly strange. From earlier on IRC:
fun how we get '(none)' by default and '?' instead with -s.
('?' comes from safe_gethostname depending on uts.nodename[0])
so I'm not exactly sure why you're getting '?' by default instead of
'(none)'. Maybe that's once you've reached the network step and stuff
has happened? My observations were right after setting a keymap,
switching to a VT.
For context, I was initially wondering which options were supported by
busybox's hostname, hence my looking into this. (Wasn't entirely sure
how safe / future-proof hardcoding “(none)” would be; still unclear at
this point, but I haven't spent much time on this.)
Likely, that's indeed since stuff has already happened at that point. It seems that the
newly added "if" worked as expected,
so it must have been "(none)" at the time of checking, and only changed to "?"
afterwards.
However, that "question mark hostname" is also shown when doing this
with Bullseye, so that seems to be expected behaviour.
That part's reassuring.
Indeed :-).
Cheers,
Oliver
Bug#1034062: netcfg prompts for hostname even though preseeded, preventing unattended installation
Hallo Cyril, Am 08.04.23 um 14:53 schrieb Cyril Brulebois: Oliver Freyermuth (2023-04-08): I concur that the question is where to go from here — my real-world use case is using Foreman [0] for machine deployment, which currently passes "hostname" exclusively in its preseed/PXE templates. If the decision is to drop support for the hostname alias, deployment software like this one will of course need to be adapted (considering the alternatives, that is certainly a viable option). Thanks for bringing this topic up. I'm not sure whether that triggered Andi's looking into it, but there's a patch available in #1031643, and netboot(-gtk) build artifacts with patched preseed binaries available for a limited time at: https://people.debian.org/~kibi/bug-1031643/ That's entirely untested (by me), Salvatore might test that later on. I can build an amd64 netinst image if that's easier for you to test and confirm with. thanks! The patched preseed binaries are in fact ideal for testing on my end: Foreman usually downloads kernel and initrd from the upstream source, and takes care of all the parts which may be different for the local environment (PXE/bootloader/Preseed/Kickstart/Autoyast...) itself. So I just replaced the linux and initrd.gz which Foreman downloaded with the linux and initrd.gz from the patched source, and re-tried, with no other changes to Foreman, i.e. it was still using the hostname alias only on the kernel command line. I can confirm that the question is not shown anymore, and installation proceeds unattendedly, so the patched versions test fine on my end :-). During installation, when switching to a tty and running "hostname -f", I see the FQDN assigned via the hostname parameter, as expected. Then of course we also need to test what happens without the "hostname=" paraemter on the kernel commandline. I removed it, re-tried, and the question was shown again, so that also seems to work as expected. Interestingky, without the "hostname=" parameter, running hostname on a tty (while the question is shown) echoes: ~ # hostname ? However, that "question mark hostname" is also shown when doing this with Bullseye, so that seems to be expected behaviour. I'll hold back on upstreaming this change to Foreman until a decision on how to proceed with #1031643 is made. Thanks again for mentioning it, that definitely shifted the balance (at least for me) in the “let's try and restore the feature” direction. Seeing the unintrusiveness of the patch, and taking into account that adapting existing deployment software can be avoided (there's certainly much more affected tooling out there), that feels like a good approach to me, too. Cheers, Oliver
Bug#1034062: netcfg prompts for hostname even though preseeded, preventing unattended installation
Hello Cyril, Am 07.04.23 um 23:23 schrieb Cyril Brulebois: Oliver Freyermuth (2023-04-07): Potentially relevant kernel commandline parameters: netcfg/disable_dhcp=false ethdetect/prompt_missing_firmware=false hw-detect/load_firmware=false locale=en_US.UTF-8 hostname=laptop.example.com domain=example.com This is likely #1031643, try using the full netcfg/get_hostname name instead of the hostname alias on the kernel command line? indeed, that seems to be the case — I can confirm using the full netcfg/get_hostname name on the kernel command line prevents the question from being shown, and preseeding proceeds unattendedly again. :-) That easily explains why I did not find any code changes in netcfg which could explain this change in behaviour, since the reason is due to a kernel behavipur change. So this can probably be closed as a duplicate of #1031643. I concur that the question is where to go from here — my real-world use case is using Foreman [0] for machine deployment, which currently passes "hostname" exclusively in its preseed/PXE templates. If the decision is to drop support for the hostname alias, deployment software like this one will of course need to be adapted (considering the alternatives, that is certainly a viable option). I'll hold back on upstreaming this change to Foreman until a decision on how to proceed with #1031643 is made. Thanks a lot and cheers, Oliver [0] https://theforeman.org/
Bug#1034062: netcfg prompts for hostname even though preseeded, preventing unattended installation
Package: netcfg Version: 1.184 With both the Bookworm alpha2 and rc1 netinstaller, I am prompted to confirm the preseeded hostname (also sent via DHCP), preventing unattended installation. The very same preseed file did not show any such prompt neither in Buster nor Bullseye. The prompt is pre-filled with the correct hostname (not the FQDN, just the hostname part), but of course this prevents unattended preseed installation. Relevant logs follow, hostname and FQDN modified to examples. Potentially relevant kernel commandline parameters: netcfg/disable_dhcp=false ethdetect/prompt_missing_firmware=false hw-detect/load_firmware=false locale=en_US.UTF-8 hostname=laptop.example.com domain=example.com Potentially relevant part of preseed file: d-i ethdetect/prompt_missing_firmware boolean false d-i netcfg/choose_interface select auto d-i netcfg/get_hostname string laptop.exmaple.com d-i netcfg/get_domain string example.com d-i netcfg/wireless_wep string d-i hw-detect/load_firmware boolean true Relevant part of installer syslog: Apr 6 16:56:31 netcfg[1051]: DEBUG: State is now 1 Apr 6 16:56:31 netcfg[1051]: DEBUG: State is now 2 Apr 6 16:56:31 netcfg[1051]: DEBUG: State is now 5 Apr 6 16:56:31 netcfg[1051]: INFO: DHCP hostname: "laptop.example.com" Apr 6 16:56:31 netcfg[1051]: DEBUG: laptop.example.com is a valid FQDN Apr 6 16:56:31 netcfg[1051]: DEBUG: We have a real FQDN Apr 6 16:56:31 netcfg[1051]: DEBUG: Preseeding domain from global: example.com < at this point, the prompt for the hostname is shown, pre-filled with "laptop" >
Bug#1033547: dblatex invokes inkscape with deprecated options
Package: dblatex Version: 0.3.12py3-1 dblatex uses Inkscape to convert svgs to pdfs. The options --without-gui and --export-pdf it uses for this are deprecated. This generates a lot of unrelated warnings that make the output hard to read, and Inkscape may stop supporting these options altogether in the future. Fedora ships a patch that replaces inkscape with rsvg-convert, maybe that makes sense for Debian too: https://src.fedoraproject.org/rpms/dblatex/blob/rawhide/f/dblatex-0.3.11-replace-inkscape-by-rsvg.patch Example output: inkscape -z -D --export-pdf=fig0.pdf /build/doc/manuals/aoip-mgw-options__1.svg Warning: Option --without-gui= is deprecated Warning: Option --export-pdf= is deprecated Unable to init server: Could not connect: Connection refused Failed to get connection ** (inkscape:40184): CRITICAL **: 09:22:51.887: dbus_g_proxy_new_for_name: assertion 'connection != NULL' failed ** (inkscape:40184): CRITICAL **: 09:22:51.887: dbus_g_proxy_call: assertion 'DBUS_IS_G_PROXY (proxy)' failed ** (inkscape:40184): CRITICAL **: 09:22:51.887: dbus_g_connection_register_g_object: assertion 'connection != NULL' failed ** (inkscape:40184): WARNING **: 09:22:51.999: Fonts dir '/usr/share/inkscape/fonts' does not exist and will be ignored. Best regards, Oliver -- - Oliver Smith https://www.sysmocom.de/ === * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte
Bug#1033039: kde-config-flatpak: settings page "flatpak | permissions" is not populated
Package: kde-config-flatpak Version: 5.27.2-1 Severity: grave Justification: renders package unusable X-Debbugs-Cc: logisti...@yahoo.com Dear Maintainer, after installing kde-config-flatpak the flatpak settings page is shown in KDE system settings and all installed flatpak apps are listed correctly. But when I click on any application, the "permissions" area of the window is not populated. There remains a line in the permissions' section saying "select an application from the list to view its permissions here". I do not see any missing package dependencies that might cause this issue. Setting to "grave" since this renders the package unusable. -- System Information: Debian Release: bookworm/sid APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-6-amd64 (SMP w/16 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.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 kde-config-flatpak depends on: ii libc6 2.36-8 ii libflatpak0 1.14.3-1 ii libglib2.0-02.74.6-1 ii libkf5configcore5 5.103.0-1 ii libkf5coreaddons5 5.103.0-1 ii libkf5i18n5 5.103.0-1 ii libkf5quickaddons5 5.103.0-1 ii libqt5core5a5.15.8+dfsg-3 ii libqt5qml5 5.15.8+dfsg-3 ii libstdc++6 12.2.0-14 ii systemsettings 4:5.27.2-1 kde-config-flatpak recommends no packages. kde-config-flatpak suggests no packages. -- no debconf information
Bug#1032663: ITP: eludris -- A simple CLI to help you with setting up and managing your Eludris instance
Located at https://github.com/eludris/eludris/tree/main/cli, this is a package for creating an Eludris instance with ease. It is officially supported and maintained by Eludris and reduces the barrier to entry for new instance owners. An Eludris instance is your own personally managed node of the Eludris server protocol, found at https://github.com/eludris/eludris. More info about what Eludris is all about can be found here: https://eludris.github.io/docs/index.html. On 11/03/2023 18:50, Gunnar Wolf wrote: Please explain briefly in your package description what is an Eludris instance and why it might be useful or interesting to a Debian user who stumbles upon your package! Oliver Wilkes dijo [Fri, Mar 10, 2023 at 04:43:19PM +]: Package: wnpp Severity: wishlist Owner: Oliver Wilkes X-Debbugs-Cc: debian-de...@lists.debian.org * Package name : eludris Version : 0.3.2 Upstream Author : Oliver Wilkes * URL : https://github.com/eludris/eludris/tree/main/cli/ * License : MIT Programming Lang: Rust Description : A simple CLI to help you with setting up and managing your Eludris instance Located at https://github.com/eludris/eludris/tree/main/cli, this is a package for creating an Eludris instance with ease. It is officially supported and maintained by Eludris and reduces the barrier to entry for new instance owners. ### Why is this package useful/relevant? This CLI provides an easy way for users to create their own Eludris instance from scratch. There are currently no alternatives as Eludris is relatively new and this is an 'official' CLI. ### How do you plan to maintain it? I am not all too sure how this works as this is my first time packaging for Debian. I plan to maintain it solo for now, unless if anyone has any better suggestions as to what team to maintain it under.
Bug#1032663: ITP: eludris -- A simple CLI to help you with setting up and managing your Eludris instance
Package: wnpp Severity: wishlist Owner: Oliver Wilkes X-Debbugs-Cc: debian-de...@lists.debian.org * Package name : eludris Version : 0.3.2 Upstream Author : Oliver Wilkes * URL : https://github.com/eludris/eludris/tree/main/cli/ * License : MIT Programming Lang: Rust Description : A simple CLI to help you with setting up and managing your Eludris instance Located at https://github.com/eludris/eludris/tree/main/cli, this is a package for creating an Eludris instance with ease. It is officially supported and maintained by Eludris and reduces the barrier to entry for new instance owners. ### Why is this package useful/relevant? This CLI provides an easy way for users to create their own Eludris instance from scratch. There are currently no alternatives as Eludris is relatively new and this is an 'official' CLI. ### How do you plan to maintain it? I am not all too sure how this works as this is my first time packaging for Debian. I plan to maintain it solo for now, unless if anyone has any better suggestions as to what team to maintain it under.
Bug#913916: grub-efi-amd64: UEFI boot option removed after update to grub2 2.02~beta3-5+deb9u1
Hi,
I observe the very same issue on a Dell Latitude 3590, but it only started to
affect the laptop running Bullseye all of a sudden after one of many
reinstallations.
19 other laptops (same model, same date of purchase, same hardware) with
exactly the same installation (preseed + configuration management via Puppet)
are (as of yet) unaffected.
I believe the described issue matches this one observed on various Dell laptops:
https://github.com/rhboot/efibootmgr/issues/86
To be more explicit, using:
efibootmgr -c -e 3 -v -L debian -l "\EFI\debian\shimx64.efi"
creates a working boot entry, using an EDD 3.0 path similar to the one created if an
entry is created via the UEFI firmware "by hand".
Using:
efibootmgr -c -v -L debian -l "\EFI\debian\shimx64.efi"
creates a boot entry invisible in the UEFI firmware.
This matches the observation of Gábor Gombás ("Debian" in the "efibootmgr -v" output for
an EDD 3.0 entry vs. "debian", an EDD 1.0 entry).
As of the fix for #891434 , grub-install does not leverage efibootmgr anymore,
but implements part of its functionality to reduce writes (and always seems to
use EDD 1.0).
From my observation and the one in the linked GitHub issue, I deduce the
following:
- There's actually a firmware bug on these Dell laptops (and maybe more
devices), causing the UEFI firmware to start ignoring EDD 1.0 entries after
some event (a number of write cycles? some corruption?).
- EDD 3.0 entries still work.
- Since grub-install always uses EDD 1.0 entries, it overwrites the entry with
an EDD 1.0 entry during each reinstall, causing such devices not to be bootable
anymore.
Workarounds appear to be:
- Create an EDD 3.0 entry (either via firmware, or via efibootmgr), name it
differently and inject it first in the boot order.
- Use --force-extra-removable to install to the fallback loader path (if this
is the only bootloader on the system).
Notably, the workaround described by ArchLinux at:
https://wiki.archlinux.org/title/Unified_Extensible_Firmware_Interface#Boot_entries_created_with_efibootmgr_fail_to_show_up_in_UEFI
does not work on Debian, since efibootmgr is not called by grub-install.
While the GitHub issue describes a user who could make EDD 1.0 entries work
again on an affected system by purging all entries, in my tests neither that
nor an UEFI update nor loading of firmware defaults nor a full RTC reset could
make the firmware accept EDD 1.0 entries again on the affected device.
A potential solution could be to probe whether the firmware accepts EDD 3.0
entries and preferrably create those over EDD 1.0, or allow to configure this.
Cheers and hope this helps,
Oliver
Bug#1027956: manpages: mtrace and sprof have been moved to optional package libc-devtools
Package: manpages Version: 6.02-1 Severity: minor Hi, mtrace, sprof and sotruss are now shipped by libc-devtools, with the manpage for the latter already included there. I suggest moving the others too. Regards, Oliver
Bug#1024875: vifm: Dito colorschemes
Package: vifm Version: 0.12-1+b1 Followup-For: Bug #1024875 The path under /usr/share/vifm doesn't appear to be honored other than vifm on first run copying the vifm-help.txt, itself already a copy of the manpage, to $HOME/.config/vifm. The purpose is unclear, :help fails with the error described in any case. Removing it brings it back at next run. The colors folder isn't touched, vifm does however look into /etc/vifm/colors, where there's just a lone default scheme. We can copy or link the schemes to the configuration in $HOME as a workaround, but that's hardly the way to go. Not sure whether it's ok to install the schemes under /etc, vifm should allow to change where it looks for its data. Regards, Oliver
Bug#1024215: libqt5opengl5 depends on: libqt5gui5, libqt5gui5 | libqt5gui5-gles
Package: libqt5opengl5
Version: 5.15.6+dfsg-2+b1
Source: qtbase-opensource-src (5.15.6+dfsg-2)
Architecture: arm64
Installed-Size: 582
Depends: libc6 (>= 2.17), libqt5core5a (>= 5.15.1), libqt5gui5 (>=
5.1.0), libqt5gui5 (>= 5
.8.0) | libqt5gui5-gles (>= 5.8.0), libqt5widgets5 (>= 5.9.0~beta),
libstdc++6 (>= 5), qtbas
e-abi-5-15-6
libqt5opengl5 depends on libqt5gui5 and on libqt5gui5 or
libqt5gui5-gles. Thus, it will never be possible to have libqt5gui5-gles
installed as dependency, as libqt5gui5 is always pulled in.
I guess those dependencies are automatically drawn in by the control
file, due to:
Depends: ${misc:Depends}, ${shlibs:Depends}
Tested on debian bookworm.
Bug#1020276: Fwd: Bug#1020276: linux-image-5.19.0-1-amd64: NFC device not detected
Thanks Mark, I worked my way through these build instruction and got successfully to Step 15: There, I don't know to do. What is my target platform? Is it "custom"? If so, what are the correct values to set? I also wonder whether that part is optional. In 8./9. I make and install the software. Then I modify the code (in 15.) and make/install again (16./17.) That's a bit confusing. Running the demo after the first make/install also doesn't work: ~/linux_libnfc-nci(master)> sudo nfcDemoApp nfcDemoApp: error while loading shared libraries: libnfc_nci_linux-1.so.0: cannot open shared object file: No such file or directory ~/linux_libnfc-nci(master)> echo $LD_LIBRARY_PATH /usr/local/lib/ ~/linux_libnfc-nci(master)> ls $LD_LIBRARY_PATH libnfc_nci_linux-1.so.0 libnfc_nci_linux.la pkgconfig python3.10 python3.9 libnfc_nci_linux-1.so.0.0.0 libnfc_nci_linux.so python2.7 python3.8 That may be me doing something stupid, though. smime.p7s Description: S/MIME Cryptographic Signature
Bug#1020276: linux-image-5.19.0-1-amd64: NFC device not detected
Package: src:linux Version: 5.19.6-1 Severity: normal I have a ThinkPad X1 Yoga (4th gen). It has an NFC device built in. The NFC device appears in the BIOS, and it is enabled there. However, I cannot see it from Debian at all. Neither lsusb nor lspci show anything ressembling an NFC device. I would gladly help to debug this, but I don't know what to do in such a situation. -- Package-specific info: ** Version: Linux version 5.19.0-1-amd64 (debian-ker...@lists.debian.org) (gcc-11 (Debian 11.3.0-5) 11.3.0, GNU ld (GNU Binutils for Debian) 2.38.90.20220713) #1 SMP PREEMPT_DYNAMIC Debian 5.19.6-1 (2022-09-01) ** Command line: BOOT_IMAGE=/boot/vmlinuz-5.19.0-1-amd64 root=UUID=1a64cfce-790c-4909-943a-4b0eae472280 ro quiet ** Tainted: W (512) * kernel issued warning ** Kernel log: [50279.964287] usb 1-2.3.3.2: SerialNumber: [50280.044948] input: Lenovo ThinkPad USB-C Dock Gen2 USB Audio as /devices/pci:00/:00:14.0/usb1/1-2/1-2.3/1-2.3.3/1-2.3.3.2/1-2.3.3.2:1.3/0003:17EF:A396.0008/input/input35 [50280.103999] hid-generic 0003:17EF:A396.0008: input,hidraw5: USB HID v1.11 Device [Lenovo ThinkPad USB-C Dock Gen2 USB Audio] on usb-:00:14.0-2.3.3.2/input3 [50280.183667] usb 1-2.3.3.4: new full-speed USB device number 22 using xhci_hcd [50280.290956] usb 1-2.3.3.4: New USB device found, idVendor=0b0e, idProduct=0422, bcdDevice= 2.31 [50280.290962] usb 1-2.3.3.4: New USB device strings: Mfr=0, Product=2, SerialNumber=3 [50280.290964] usb 1-2.3.3.4: Product: Jabra SPEAK 510 USB [50280.290965] usb 1-2.3.3.4: SerialNumber: 3050752CC7E7021F00 [50280.576445] input: Jabra SPEAK 510 USB as /devices/pci:00/:00:14.0/usb1/1-2/1-2.3/1-2.3.3/1-2.3.3.4/1-2.3.3.4:1.3/0003:0B0E:0422.0009/input/input36 [50280.634984] usb 1-2.3.3.4: 1:1: cannot set freq 48000 to ep 0x3 [50280.635890] jabra 0003:0B0E:0422.0009: input,hiddev1,hidraw6: USB HID v1.11 Device [Jabra SPEAK 510 USB] on usb-:00:14.0-2.3.3.4/input3 [50280.669158] usbcore: registered new interface driver snd-usb-audio [50280.842220] wlp0s20f3: authenticate with f4:4e:05:b5:37:dd [50280.843533] wlp0s20f3: send auth to f4:4e:05:b5:37:dd (try 1/3) [50280.939101] wlp0s20f3: authenticated [50280.943667] wlp0s20f3: associate with f4:4e:05:b5:37:dd (try 1/3) [50280.945310] wlp0s20f3: RX AssocResp from f4:4e:05:b5:37:dd (capab=0x111 status=0 aid=11) [50280.946668] wlp0s20f3: associated [50281.051857] wlp0s20f3: Limiting TX power to 17 dBm as advertised by f4:4e:05:b5:37:dd [50281.051931] IPv6: ADDRCONF(NETDEV_CHANGE): wlp0s20f3: link becomes ready [50281.085188] input: Lenovo ThinkPad USB-C Dock Gen2 USB Audio as /devices/pci:00/:00:14.0/usb1/1-2/1-2.3/1-2.3.3/1-2.3.3.2/1-2.3.3.2:1.3/0003:17EF:A396.000A/input/input37 [50281.147813] hid-generic 0003:17EF:A396.000A: input,hidraw5: USB HID v1.11 Device [Lenovo ThinkPad USB-C Dock Gen2 USB Audio] on usb-:00:14.0-2.3.3.2/input3 [50281.162696] usbhid 1-2.3.3.1:1.1: can't add hid device: -32 [50281.162704] usbhid: probe of 1-2.3.3.1:1.1 failed with error -32 [50281.360066] usb 1-2.3.3.1: USB disconnect, device number 20 [50281.623686] usb 1-2.3.3.1: new full-speed USB device number 23 using xhci_hcd [50281.731344] usb 1-2.3.3.1: New USB device found, idVendor=04b4, idProduct=521a, bcdDevice= 0.00 [50281.731347] usb 1-2.3.3.1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [50281.731348] usb 1-2.3.3.1: Product: USB-I2C Bridge [50281.731349] usb 1-2.3.3.1: Manufacturer: Cypress Semiconductor [50284.799365] IPv6: ADDRCONF(NETDEV_CHANGE): enx482ae3771609: link becomes ready [50284.799711] r8152 4-1.1:1.0 enx482ae3771609: carrier on [50312.180563] wlp0s20f3: disconnect from AP f4:4e:05:b5:37:dd for new auth to f4:4e:05:ae:21:ed [50312.247452] wlp0s20f3: authenticate with f4:4e:05:ae:21:ed [50312.257584] wlp0s20f3: send auth to f4:4e:05:ae:21:ed (try 1/3) [50312.296792] wlp0s20f3: authenticated [50312.299718] wlp0s20f3: associate with f4:4e:05:ae:21:ed (try 1/3) [50312.301711] wlp0s20f3: RX ReassocResp from f4:4e:05:ae:21:ed (capab=0x111 status=0 aid=2) [50312.305238] wlp0s20f3: associated [50312.337849] wlp0s20f3: Limiting TX power to 17 dBm as advertised by f4:4e:05:ae:21:ed [50631.655067] wlp0s20f3: disconnect from AP f4:4e:05:ae:21:ed for new auth to f4:4e:05:b5:37:dd [50631.702978] wlp0s20f3: authenticate with f4:4e:05:b5:37:dd [50631.712151] wlp0s20f3: send auth to f4:4e:05:b5:37:dd (try 1/3) [50631.751766] wlp0s20f3: authenticated [50631.754022] wlp0s20f3: associate with f4:4e:05:b5:37:dd (try 1/3) [50631.755982] wlp0s20f3: RX ReassocResp from f4:4e:05:b5:37:dd (capab=0x111 status=0 aid=12) [50631.759006] wlp0s20f3: associated [50631.798424] wlp0s20f3: Limiting TX power to 17 dBm as advertised by f4:4e:05:b5:37:dd [50631.799678] wlp0s20f3: disconnect from AP f4:4e:05:b5:37:dd for new auth to f4:4e:05:ae:21:ed [50631.849425] wlp0s20f3: authenticate with f4:4e:05:ae:21:ed [50631.857225] wlp0s20f3: send auth to f4:4e:05:ae:21:ed (try 1/3)
Bug#990797: most: upstream is now 5.2.0 (was: most: Please package new upstream release (5.1.0))
Package: most Version: 5.0.0a-4 Followup-For: Bug #990797 Dear Maintainer, the upstream version of most is now at 5.2.0. Please update, or if you are not able to update, please set package to "orphan". Greetings, SvOlli -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: arm64 (aarch64) Kernel: Linux 5.18.0-4-arm64 (SMP w/2 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 /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages most depends on: ii libc6 2.34-7 ii libslang2 2.3.3-1 most recommends no packages. most suggests no packages. -- no debconf information
Bug#1017414: Upstream issue
Hi, I am also an affected user, and can reproduce on a Gentoo Linux system with nvidia graphics, but not on a Gentoo Linux system with Intel graphics. I have skimmed Firefox' bug tracker and found: https://bugzilla.mozilla.org/show_bug.cgi?id=1758473 which explains why the crashing test is executed during each startup of Firefox (especially also when opening URLs), and that it is caused by a defect in the nvidia driver. I have subsequently opened: https://bugzilla.mozilla.org/show_bug.cgi?id=1787182 highlighting that this causes coredumps on each Firefox start on user systems. Cheers, Oliver
Bug#1016697: RFS: diodon/1.13.0-1 -- GTK+ Clipboard manager
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "diodon": * Package name: diodon Version : 1.13.0-1 Upstream Author : Oliver Sauder * URL : https://launchpad.net/diodon * License : LGPL-3+, GPL-2+, LGPL-2.1+ * Vcs : https://git.launchpad.net/~diodon-team/+git/debian-packaging Section : utils The source builds the following binary packages: diodon - GTK+ Clipboard manager libdiodon0 - GTK+ Clipboard manager (main library) gir1.2-diodon-1.0 - GTK+ Clipboard manager (GObject introspection data) diodon-dev - GTK+ Clipboard manager (development files) To access further information about this package, please visit the following URL: https://mentors.debian.net/package/diodon/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/d/diodon/diodon_1.13.0-1.dsc Changes since the last upload: diodon (1.13.0-1) unstable; urgency=medium . * New upstream release. * Bump Standards-Version to 4.6.1. Regards,
Bug#1016144: codequery: Exuberant Ctags dependency should be optional
Package: codequery Version: 0.24.0+dfsg1-1 Severity: minor Hi! exuberant-ctags was superseded by universal-ctags that's been in Debian for a couple of years now. Codequery's website explicitly states both are supported and I can confirm as much. Please add universal-ctags as an alternative, thanks. Oliver
Bug#1011629: minidlna: can't access localhost:8200 - DNS rebinding attack suspected
On Fri, 8 Jul 2022 21:50:32 +0800 =?UTF-8?Q?Marcos_Ra=C3=BAl_Carot?= wrote: Oh, so there is no way now to access the web page from minidlna? Cheers. The code (as also used upstream[0]) validates that the hostname in the HTTP request consists only of numbers, dots or colons. Given this change, it seems the only remaining functional way is to visit the IPv4 IP address of the minidlna server directly, e.g. if your server is running at 192.168.178.32, you would visit: http://192.168.178.32:8200 in your browser. An upstream bug about this issue has reported already at: https://sourceforge.net/p/minidlna/bugs/346/ [0] https://sourceforge.net/p/minidlna/git/ci/c21208508dbc131712281ec5340687e5ae89e940/
Bug#1000944: Business Proposal
-- Premier Oil Plc, 23 Lower Belgrave Street SW1W 0NR. London. Attention: Account/Finance manager Hello, My name is Mr Oliver Baruch, Account/Finance manager in (Premier Oil PLC). I have a business proposal that will be beneficial to you and me. please contact me for more details of the business to you. thanks. Forward your response to this email: oliverbaru...@gmail.com
Bug#927012: Redesign of libravatar.cgi and testing
Hi!
Yes, libravatar never had the option to query with the plaintext identity
for good reasons.
Again, if there is anything I can do, please let me know!
Oliver
On Sat, Apr 9, 2022 at 6:09 AM Don Armstrong wrote:
> On Fri, 08 Apr 2022, Oliver Falk wrote:
> > When I checked it yesterday, the script was still called with the mail
> > address !?
>
> The script is, but libravatar and gravatar are no longer called with the
> mail address; they're all using the md5 of the e-mail address now. [The
> script caches responses from libravatar and gravatar and serves them
> directly, so there's limited leakage of information on who is visiting a
> specific page.]
>
> > Let me know if I can help you in some way, I'm happy to do so if I
> > know what exactly is required.
>
> Thanks! To be honest, I haven't looked at the issue recently, so I'll
> have to dig in to see what was failing. [It's probably time to just have
> it use mod_perl directly instead of the CGI-based mod_perl.]
>
> --
> Don Armstrong https://www.donarmstrong.com
>
> If you wish to strive for peace of soul, then believe; if you wish to
> be a devotee of truth, then inquire.
> -- Friedrich Nietzsche
>
> --
> To unsubscribe, send mail to 927012-unsubscr...@bugs.debian.org.
>
>
--
Oliver Falk, RHCE
He/Him/His
Manager Customer Success - Germany
Red Hat <https://www.redhat.com>
fa...@redhat.com
M: +436641665645 IM: ofalk
@RedHat <https://twitter.com/redhat> Red Hat
<https://www.linkedin.com/company/red-hat> Red Hat
<https://www.facebook.com/RedHatInc>
<https://www.redhat.com>
Red Hat Austria GmbH, Legal form: Limited company ("Gesellschaft mit
beschränkter Haftung") Registered seat: Vienna
Commercial registry file: FN 479668w, Commercial Court ("Handelsgericht") Vienna
Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Laurie Krebs, Michael O'Neill, Brian Klemm
Bug#927012: Redesign of libravatar.cgi and testing
On Fri, Apr 8, 2022 at 6:27 AM Don Armstrong wrote: > The basic code is working, but we were having performance issues which > is why it was disabled on bugs.debian.org. > > I haven't had a chance to dig into exactly why it was failing, though > now that everything is using md5sum of the e-mail addresses, I think the > privacy concerns that were mentioned previously have been addressed. > When I checked it yesterday, the script was still called with the mail address !? > It's not super high on my priority list to fix, but I'll try to get to > it when I have some time. > Let me know if I can help you in some way, I'm happy to do so if I know what exactly is required. Oliver
Bug#927012: libravatar.cgi on bugs.debian.org fails with 500 error
On Fri, Apr 8, 2022 at 2:10 AM Paul Wise wrote:
> On Thu, 2022-04-07 at 12:39 +0200, Oliver Falk wrote:
>
> > IMHO, the current solution doesn't really provide more security.
>
> Its about not asking browsers to do third-party requests, which is the
> policy for all Debian domains (where possible) and yes isn't a security
> issue, but it is a privacy and trust issue.
>
Fair point and if that's the policy, it's perfectly fine.
> > Currently, what happens is that the local CGI script is actually
> > called with the mail address instead of the hash, which I'd see as a
> > bigger issue.
>
> That issue does need to be fixed yeah, please file a separate bug
> report about that issue.
>
I thought about this again and well, this would actually break the
federation :-{
> > Note that Libravatar has a privacy policy in
> > place: https://www.libravatar.org/privacy/
>
> This privacy policy and your practices are different to Debian's, for
> example we don't log IP addresses by default, we don't use cookies or
> JavaScript by default, we prefer to use static HTML by default, we have
> Tor Onion sites, we delete old logs after a short period of time etc.
>
> > Libravatar is a community driven project with a lot of eyes on it and
> > we're fully committed to stay neutral; Read: We're not going to share
> > or sell data.
>
> I expect the Libravatar community is definitely trustworthy in general,
> but visitors to Debian websites shouldn't have to review the privacy
> policies and trustworthyness of third-parties when visiting our sites.
>
Again, fair point!
[ ... ]
> > Without digging much into it (esp. because I don't have the relevant
> > modules + config in place), I'd say the script should work; No idea
> > why it's currently throwing a server error.
>
> The script in the git repository has execute permissions, but the
> script on the server does not and this is reflected in the server logs.
> Other folks on the IRC channel said it has been disabled due to
> overloading the server, referring me to previous discussions.
>
OK, that explains the server error.
> > > so I'll leave it up to the Debian BTS admins to check and respond
> > > and maybe re-enable execution of the script again.
> > Thanks for checking!
>
> The Debian BTS admin has confirmed that the script needs fixing:
>
> pabs: yeah, the design of libravatar.cgi needs to be
> readdressed before it gets renabled
>
Again, if I know exactly what is requested, I'm happy to help out with my
coding knowledge!
Oliver
Bug#927012: libravatar.cgi on bugs.debian.org fails with 500 error
On Thu, Apr 7, 2022 at 11:52 AM Paul Wise wrote: > On Thu, 2022-04-07 at 11:01 +0200, Oliver Falk wrote: > > > I remember the CGI was disabled quite some time ago, but I have to > > admit, I never had the chance to engage with the right people to see > > how we can fix it. > > To be clear, I'm not the right person, just relaying some info that got > dug up on IRC today when other people noticed the script was broken. > Thanks for clarifying that - noted! > > I understand the script was added in order to provide additional > > caching, right? > > I think it was mainly for privacy; not sending the avatar image > requests to third-party domains such as libravatar.org. > IMHO, the current solution doesn't really provide more security. Yes, Libravatar doesn't see the client IPs, but that's all. Currently, what happens is that the local CGI script is actually called with the mail address instead of the hash, which I'd see as a bigger issue. Note that Libravatar has a privacy policy in place: https://www.libravatar.org/privacy/ Libravatar is a community driven project with a lot of eyes on it and we're fully committed to stay neutral; Read: We're not going to share or sell data. > > What about if we change this to directly access libravatar.org and > > see if the performance is sufficient? (doesn't address > > federation...). > > That would presumably work, but there is the privacy issue. > I do understand people are concerned about privacy - I am too and that was one of the reasons why I stepped in as the core maintainer when fmarier decided to give up on the project and even added an option to proxy requests to Gravatar instead of redirecting. > > There is a very simple libravatar proxy python script: > > > https://git.linux-kernel.at/oliver/ivatar/-/blob/master/libravatarproxy.py > > Since the Debian BTS is written in Perl I assume the admins prefer it. > Fair point! > > Since I do have some Perl experience as well, if you want to stick > > with Perl, I can also look into the existing CGI and depending on if > > you want or not, also add federation. > > That would be helpful I think. > Without digging much into it (esp. because I don't have the relevant modules + config in place), I'd say the script *should* work; No idea why it's currently throwing a server error. > I also note from looking at the Apache config today that the script > might have already been migrated to mod_perl, but I wasn't sure, so > I'll leave it up to the Debian BTS admins to check and respond and > maybe re-enable execution of the script again. > Thanks for checking! mod_perl should definitely help a bit to speed things up, but currently it looks like there is some error and not like someone disabled the script, but I have no insights of course. Cheers, Oliver
Bug#927012: libravatar.cgi on bugs.debian.org fails with 500 error
Hi all!
I remember the CGI was disabled quite some time ago, but I have to admit, I
never had the chance to engage with the right people to see how we can fix
it.
I understand the script was added in order to provide additional caching,
right?
What about if we change this to directly access libravatar.org and see if
the performance is sufficient? (doesn't address federation...).
There is a very simple libravatar proxy python script:
https://git.linux-kernel.at/oliver/ivatar/-/blob/master/libravatarproxy.py
Note, this doesn't take into account any federation, but that could be
added easily and it's on my todo list.
Since I do have some Perl experience as well, if you want to stick with
Perl, I can also look into the existing CGI and depending on if you want or
not, also add federation.
Point is: I'm very willing to help out to get this running again - for
obvious reasons. :-)
Oliver
On Thu, Apr 7, 2022 at 9:39 AM Paul Wise wrote:
> On Sat, 13 Apr 2019 15:51:12 +0100 Laurence Parry wrote:
>
> > My avatar (and indeed all avatars) are not showing up on bugs.debian.org
> .
> >
> > When I tried to access the URL:
> >
> https://bugs.debian.org/cgi-bin/libravatar.cgi?email=greenreaper%40gmail.com
> > I got an 500 Internal Server Error:
>
> FTR; this CGI script was disabled some years ago because it was
> overloading the Debian bug servers. There was a plan to switch the
> script from CGI to mod_perl but that never happened. As an example of
> traffic, yesterday there were 21408 attempted executions of the script.
> If anyone wants to work on the script, the source code for it is here:
>
>
> https://salsa.debian.org/debbugs-team/debbugs/-/blob/master/cgi/libravatar.cgi
>
> --
> bye,
> pabs
>
> https://wiki.debian.org/PaulWise
>
--
Oliver Falk, RHCE
He/Him/His
Manager Customer Success - Germany
Red Hat <https://www.redhat.com>
fa...@redhat.com
M: +436641665645 IM: ofalk
@RedHat <https://twitter.com/redhat> Red Hat
<https://www.linkedin.com/company/red-hat> Red Hat
<https://www.facebook.com/RedHatInc>
<https://www.redhat.com>
Red Hat Austria GmbH, Legal form: Limited company ("Gesellschaft mit
beschränkter Haftung") Registered seat: Vienna
Commercial registry file: FN 479668w, Commercial Court ("Handelsgericht") Vienna
Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Laurie Krebs, Michael O'Neill, Brian Klemm
Bug#998877: can-utils asc2log timestamp generation error
Hello Alexander, On Wed, 10 Nov 2021 14:14:58 +0300 Alexander Gerasiov wrote: On Tue, 09 Nov 2021 10:16:01 +0100 Andre Naujoks wrote: > Package: can-utils > Version: 2020.11.0-1 > Severity: normal > Tags: upstream > > Dear Maintainer, > > the asc2log log file converter tool generates wrongly formatted > timestamps in some rare cases. > > I.e. it writes e.g. 1.100 instead of 2.00 into the resulting > log file. > > This bugs is fixed upstream in commit > 9c2de072a076236410f6c5a112bd7b9075a9e77d. > > Would it be possible to update the package to a version, which > contains this fix? I've prepared new package will check and upload it to archive this weekend. In fact there are several new improvements and fixes in the upstream repository now that would make sense to get packaged. Many thanks & best regards, Oliver
Bug#1006871: pmacctd: SEGV when ICMP/ICMPv6 traffic was processed and 'flows' are used
Package: pmacct X-Debbugs-Cc: deb...@seufer.de Version: 1.7.6-2 Severity: important Dear Maintainer, The pmacct version (1.7.6) segfaults in Debian Bullseye, when you use the 'flows' feature. I already reported this problem upstream: https://github.com/pmacct/pmacct/issues/586 And Paolo provided a patch for this problem: https://github.com/pmacct/pmacct/commit/73af9545ea33cd87846306f648f634063ac41765 Please also fix this in Debian Bullseye 11 Stripped down configuration file to reproduce: daemonize: true pidfile: /var/run/pmacctd.pid pcap_interface: enp8s0f1 promisc: true plugins: pgsql[all] plugin_pipe_size: 1024 sql_db: pmacct sql_host: localhost sql_user: pmacct sql_passwd: *** sql_table_version: 5 sql_history: 1m sql_history_roundoff: m sql_refresh_time: 60 sql_dont_try_update: true aggregate[all]: src_mac,dst_mac,vlan,src_host,dst_host,src_port,dst_port,tos,proto,flows Then capture ICMP/ICMPv6 traffic. Best regards, Oliver Seufer
Bug#1005993: Add additional command line options
Diodon is a desktop utility and not a command line tool. So far the only two things you can do from the command line is to open diodon or to open it in debug mode by setting `G_MESSAGES_DEBUG` to `all`. Both those options are documented in the man page. It would be great to have more options but need to be added first. There is also a upstream issue reported for this at https://bugs.launchpad.net/diodon/+bug/1309898 Oliver
Bug#1004936: RFS: diodon/1.12.0-1 -- GTK+ Clipboard manager
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "diodon": * Package name: diodon Version : 1.12.0-1 Upstream Author : Oliver Sauder * URL : https://launchpad.net/diodon * License : LGPL-2.1+, GPL-2+, LGPL-3+ * Vcs : https://git.launchpad.net/~diodon-team/+git/debian-packaging Section : utils It builds those binary packages: diodon - GTK+ Clipboard manager libdiodon0 - GTK+ Clipboard manager (main library) gir1.2-diodon-1.0 - GTK+ Clipboard manager (GObject introspection data) diodon-dev - GTK+ Clipboard manager (development files) To access further information about this package, please visit the following URL: https://mentors.debian.net/package/diodon/ Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/d/diodon/diodon_1.12.0-1.dsc Changes since the last upload: diodon (1.12.0-1) unstable; urgency=medium . * New upstream release. * Avoid history being empty on first run (Closes: #961604) Regards,
Bug#1004263: Gwyddion's application/x-stmprg-spm mime type pattern is too broad (breaks fwupd)
Package: gwyddion Version: 2.57-1 Tags: fixed-upstream Installing Gwyddion breaks other programs, such as fwupd on Debian. For example, the file: /usr/share/fwupd/quirks.d/tpm.quirk shipped by fwupd is labelled as application/x-stmprg-spm type, and starting the fwupd daemon causes device detection to break with: failed to build silo: failed to compile /usr/share/fwupd/quirks.d/tpm.quirk:ctime=1640972058.748411: cannot process content type application/x-stmprg-spm There's also a Lanchpad bug created by affected Ubuntu users: https://bugs.launchpad.net/ubuntu/+source/fwupd/+bug/1899036 I have sent a patch to upstream: https://sourceforge.net/p/gwyddion/mailman/gwyddion-devel/thread/9e1f6694-c39b-6131-796b-667f6e25f7e9%40googlemail.com/#msg37595049 which was merged via: https://sourceforge.net/p/gwyddion/code/24576/ After applying this patch to the sources, and recreating autoconf, the issue is resolved. Alternatively, the following patch can be applied to the generated gwyddion.xml: --- a/data/gwyddion.xml +++ b/data/gwyddion.xml @@ -1071,8 +1071,6 @@ - - Cheers, Oliver
Bug#1003207: pngphoon: new version available: 1.3
Package: pngphoon Version: 1.3-0svolli1 Severity: wishlist Dear Maintainer, as the developer of pngphoon, I'd like to inform you that a new version is available. I've created also a "debian-tarball" for building with different versions of Debian and Ubuntu. While it will most probably not satisfy the quality requirements of Debian, it contains an updated manual page in sgml format. Everything is available at https://svolli.de/software/pngphoon/ Greetings, SvOlli
Bug#1002517: File name tab completion attempts to allocate buffer with st_size of containing directory
Package: alpine
Version: 2.24+dfsg1-1
When invoking file name tab completion in alpine (e.g. tabbing attachments) or
alpine-pico (e.g. opening files),
in case the last fully tpyed directory has a large st_size (larger than free
system RAM), tabbing fails.
strace reveals (trying to attach in alpine):
-
stat("/home/", {st_mode=S_IFDIR|0710, st_size=39307106551, ...}) = 0
mmap(NULL, 39307108352, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= -1 ENOMEM (Cannot allocate memory)
mmap(NULL, 39307108352, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= -1 ENOMEM (Cannot allocate memory)
brk(0x561a2882d000) = 0x5611019f7000
mmap(NULL, 39307243520, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= -1 ENOMEM (Cannot allocate memory)
write(1, "\7\33[33;1H"..., 144) = 144
write(1, "\33[33;1H\33[7mFile to attach: "..., 160) = 160
write(1, "\33[7mDow "..., 132) = 132
-
This can be traced to a malloc call in the getfnames() function in pico, used
in pico_fncomplete(),
which tries to allocate a buffer of size st_size of the directory, used as
best-guess size to hold the file names.
This breaks for file systems which report actual directory content size in
st_size (e.g. CephFS):
In that case, a malloc of macroscopic size (in this case >36 GB) is attempted upon each
press of "tab".
Upstream has already fixed the issue and it is part of the recent 2.25.1 tag:
https://repo.or.cz/alpine.git/blobdiff/9b7d799cadf5d17b408b52d948bfb05d96e01c12..bc15b12b7f13ec9c9cd855aae0e62be4d0ef9e31:/pico/osdep/filesys.c
(the buffer is re-alloced if too small anyways later in the code).
Cheers,
Oliver
smime.p7s
Description: S/MIME Cryptographic Signature
Bug#1002066: a2x crashes with "IndexError: tuple index out of range"
Package: asciidoc Version: 10.1.0-1 Severity: important Tags: upstream Dear Maintainer, asciidoc 10.1.0 has a regression, depending on parameters given to a2x it crashes with: "IndexError: tuple index out of range" This is fixed in 10.1.1 by this patch: https://github.com/asciidoc-py/asciidoc-py/pull/228 Best regards, Oliver -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-9-amd64 (SMP w/4 CPU threads) Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: unable to detect Versions of packages asciidoc depends on: ii asciidoc-base 10.1.0-1 Versions of packages asciidoc recommends: ii asciidoc-dblatex 10.1.0-1 asciidoc suggests no packages. -- no debconf information -- - Oliver Smith https://www.sysmocom.de/ === * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte
Bug#1000472: bullseye-pu: package rustc-mozilla/1.51.0+dfsg1-1~deb11u1
On Sat, 27 Nov 2021 14:09:19 -0500 Roberto =?iso-8859-1?Q?C=2E_S=E1nchez?= wrote: On Sat, Nov 27, 2021 at 05:47:45PM +, Adam D. Barratt wrote: > > As a matter of interest, why was 1.51 the version chosen? I'm mostly > curious as that version is not currently in any suite in Debian. > I am assuming that this is also acceptable, but if it is not, please let me know. The choice of 1.51 was requested by Adrian Bunk, as rustc 1.51 is the (minimum?) version required by FireFox and ThunderBird 91. Wouldn't it be wiser to use Rustc 1.57.0? I ask because Rust 1.57.0 is upstream a stable version and will become the default compiler version in the Linux Kernel for the next couple of months. From kernel.org: > "### Stable compiler & Rust Edition 2021 > > We moved from the beta Rust compiler to using stable releases, > migrating each time a new one gets released. Currently we just moved > to Rust 1.57.0, released last Thursday." Source: https://lore.kernel.org/rust-for-linux/20211206140313.5653-1-oj...@kernel.org/T/ See also: https://github.com/Rust-for-Linux/linux/blob/rust/Documentation/rust/quick-start.rst Best Regards, Oliver C.
Bug#1000150: Spurious message 'cannot open folder tags:/'
I found an upstream bugreport: https://bugs.kde.org/show_bug.cgi?id=437176 The workaround mentioned there (balooctl purge) worked for me. Thanks for your work on Debian. smime.p7s Description: S/MIME Cryptographic Signature
Bug#1000150: Spurious message 'cannot open folder tags:/'
I forgot to mention that the following message are printed at the command line when the message widget opens: [17::40:54.472] unknown: PostingDB::open MDB_NOTFOUND: No matching key/data pair found [17::40:54.472] unknown: PositionDB::open MDB_NOTFOUND: No matching key/data pair found [17::40:54.472] unknown: DocumentDB::open docterms MDB_NOTFOUND: No matching key/data pair found [17::40:54.472] unknown: DocumentDB::open docfilenameterms MDB_NOTFOUND: No matching key/data pair found [17::40:54.472] unknown: DocumentDB::open docxatrrterms MDB_NOTFOUND: No matching key/data pair found [17::40:54.472] unknown: IdTreeDB::open MDB_NOTFOUND: No matching key/data pair found [17::40:54.472] unknown: IdFilenameDB::open MDB_NOTFOUND: No matching key/data pair found [17::40:54.472] unknown: DocumentTimeDB::open MDB_NOTFOUND: No matching key/data pair found [17::40:54.472] unknown: DocumentDataDB::open MDB_NOTFOUND: No matching key/data pair found [17::40:54.472] unknown: DocumentIdDB::open indexingleveldb MDB_NOTFOUND: No matching key/data pair found [17::40:54.472] unknown: DocumentIdDB::open failediddb MDB_NOTFOUND: No matching key/data pair found [17::40:54.472] unknown: MTimeDB::open MDB_NOTFOUND: No matching key/data pair found [17::40:54.472] unknown: dbis is invalid [17::40:54.472] unknown: tag fetch failed: "Failed to open the database" [17::40:54.472] unknown: "tags:/" list() invalid url [17::40:54.472] unknown: "Ordner tags:/ lässt sich nicht öffnen." smime.p7s Description: S/MIME Cryptographic Signature
Bug#1000150: Spurious message 'cannot open folder tags:/'
Subject: kate: Spurious message 'cannot open folder tags:/' Package: kate Version: 4:21.08.2-1 Severity: normal Disclaimer: this is most likely not a bug in kate, but I don't know what package to assign this bug report to. Please reassign appropriately. Every time I open the 'file open' dialog in kate or a number of other KDE apps such as kile or okular, I get a little error widget saying 'Cannot open folder tags:/' (My own translation: My German GUI actually says 'Ordner tags:/ lässt sich nicht öffnen.' ) If I click on the OK button the 'file open' dialog appears, and there are no further problems. -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.14.0-4-amd64 (SMP w/8 CPU threads) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.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 kate depends on: ii kate5-data 4:21.08.2-1 ii kio 5.86.0-1 ii ktexteditor-katepart 5.86.0-1 ii libc62.32-4 ii libkf5bookmarks5 5.86.0-1 ii libkf5completion55.86.0-1 ii libkf5configcore55.86.0-1 ii libkf5configgui5 5.86.0-1 ii libkf5configwidgets5 5.86.0-1 ii libkf5coreaddons55.86.0-1 ii libkf5crash5 5.86.0-1 ii libkf5dbusaddons55.86.0-1 ii libkf5guiaddons5 5.86.0-1 ii libkf5i18n5 5.86.0-1 ii libkf5iconthemes55.86.0-1 ii libkf5kiocore5 5.86.0-1 ii libkf5kiofilewidgets55.86.0-1 ii libkf5kiogui55.86.0-1 ii libkf5kiowidgets55.86.0-1 ii libkf5newstuff5 5.86.0-3 ii libkf5parts5 5.86.0-1 ii libkf5plasma55.86.0-1 ii libkf5service-bin5.86.0-1 ii libkf5service5 5.86.0-1 ii libkf5syntaxhighlighting55.86.0-1 ii libkf5texteditor55.86.0-1 ii libkf5textwidgets5 5.86.0-1 ii libkf5wallet-bin 5.86.0-1 ii libkf5wallet55.86.0-1 ii libkf5widgetsaddons5 5.86.0-1 ii libkf5windowsystem5 5.86.0-1 ii libkf5xmlgui55.86.0-1 ii libkuserfeedbackcore11.0.0-3 ii libkuserfeedbackwidgets1 1.0.0-3 ii libqt5concurrent55.15.2+dfsg-12 ii libqt5core5a 5.15.2+dfsg-12 ii libqt5dbus5 5.15.2+dfsg-12 ii libqt5gui5 5.15.2+dfsg-12 ii libqt5sql5 5.15.2+dfsg-12 ii libqt5widgets5 5.15.2+dfsg-12 ii libqt5xml5 5.15.2+dfsg-12 ii libstdc++6 11.2.0-10 ii plasma-framework 5.86.0-1 ii qml-module-org-kde-kquickcontrolsaddons 5.86.0-1 ii qml-module-qtquick-layouts 5.15.2+dfsg-8 ii qml-module-qtquick2 5.15.2+dfsg-8 Versions of packages kate recommends: ii sonnet-plugins 5.86.0-1 Versions of packages kate suggests: pn darcs pn exuberant-ctags ii git 1:2.33.0-1 ii khelpcenter 4:21.08.0-1 ii konsole-kpart4:21.08.2-1 pn mercurial ii subversion 1.14.1-3+b1 -- no debconf information smime.p7s Description: S/MIME Cryptographic Signature
Bug#999834: asciidoc: variable in include is not expanded properly
Package: asciidoc Version: 10.0.2-1 Severity: important Tags: upstream Dear Maintainer, in asciidoc 10, variables in includes are not expanded properly. I've made another upstream bugreport: https://github.com/asciidoc-py/asciidoc-py/issues/223 Best regards, Oliver -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-9-amd64 (SMP w/4 CPU threads) Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: unable to detect Versions of packages asciidoc depends on: ii asciidoc-base 10.0.2-1 Versions of packages asciidoc recommends: ii asciidoc-dblatex 10.0.2-1 asciidoc suggests no packages. -- no debconf information -- - Oliver Smith https://www.sysmocom.de/ === * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte
Bug#999345: redis-server: if "dir" is set in redis.conf redis won't work after update because the "redis.service" lacks write permission
Package: redis-server Version: 5:5.0.14-1+deb10u1 Severity: normal X-Debbugs-Cc: o...@ppw.de Dear Chris, we set the dir option in the redis.conf file to our fastest disc: dir /srv/redis Of couse we adjust the redis.service file to this setting: ReadWriteDirectories=-/srv/redis After any update of the package: redis stops working with this in the logs: 46060:C 08 Nov 2021 14:11:42.019 # Failed opening the RDB file dump.rdb (in server root dir /srv/redis) for saving: Read-only file system The ReadWriteDirectories=-/srv/redis is lost in the redis.service. Is there any known workaround? Can we preserve the redis.service anyhow? Would linking of /var/lib/redis to /srv do the job or do we run into other problems then? Best Regards, keep up the good work! Oliver -- System Information: Debian Release: 10.11 APT prefers oldstable-updates APT policy: (500, 'oldstable-updates'), (500, 'oldstable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-18-amd64 (SMP w/6 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages redis-server depends on: ii init-system-helpers 1.56+nmu1 ii lsb-base 10.2019051400 ii redis-tools 5:5.0.14-1+deb10u1 redis-server recommends no packages. redis-server suggests no packages. -- Configuration Files: /etc/redis/redis.conf changed: bind 127.0.0.1 protected-mode yes port 6379 tcp-backlog 511 timeout 0 tcp-keepalive 300 daemonize yes supervised no pidfile /var/run/redis/redis-server.pid loglevel notice logfile /var/log/redis/redis-server.log databases 16 always-show-logo yes save 900 1 save 300 10 save 60 1 stop-writes-on-bgsave-error yes rdbcompression yes rdbchecksum yes dbfilename dump.rdb dir /srv/redis replica-serve-stale-data yes replica-read-only yes repl-diskless-sync no repl-diskless-sync-delay 5 repl-disable-tcp-nodelay no replica-priority 100 maxmemory 400M maxmemory-policy allkeys-lru lazyfree-lazy-eviction no lazyfree-lazy-expire no lazyfree-lazy-server-del no replica-lazy-flush no appendonly no appendfilename "appendonly.aof" appendfsync everysec no-appendfsync-on-rewrite no auto-aof-rewrite-percentage 100 auto-aof-rewrite-min-size 64mb aof-load-truncated yes aof-use-rdb-preamble yes lua-time-limit 5000 slowlog-log-slower-than 1 slowlog-max-len 128 latency-monitor-threshold 0 notify-keyspace-events "" hash-max-ziplist-entries 512 hash-max-ziplist-value 64 list-max-ziplist-size -2 list-compress-depth 0 set-max-intset-entries 512 zset-max-ziplist-entries 128 zset-max-ziplist-value 64 hll-sparse-max-bytes 3000 stream-node-max-bytes 4096 stream-node-max-entries 100 activerehashing yes client-output-buffer-limit normal 0 0 0 client-output-buffer-limit replica 256mb 64mb 60 client-output-buffer-limit pubsub 32mb 8mb 60 hz 10 dynamic-hz yes aof-rewrite-incremental-fsync yes rdb-save-incremental-fsync yes -- no debconf information -- ::: DIGITALE ERLEBNISSE ::: ++ PPW || Referenz-Projekte und Agentur-News -> www.ppw.de Aktuelle Informationen Ihrer Digitalagentur in unserem Newsletter - hier anmelden: www.ppw.de/ppw-newsletter --- Diese Mitteilung ist ausschließlich für den beabsichtigten Empfänger bestimmt. Sie kann vertrauliche Informationen enthalten, die dem Schutz des Gesetzes unterliegen. Jede unberechtigte Weitergabe ist untersagt. This message is intended exclusively for the intended recipient. It may contain confidential information which are subject to the protection of the law. Any unauthorized disclosure is prohibited. pietzpluswild GmbH - Internetagentur Köln + Münster Gesellschaft mit beschränkter Haftung (GmbH) / Company with limited liability Geschäftsführer/CEOs: Michael Pietz und/and Michael Wild von Hohenborn Sitz der Gesellschaft Köln und Münster/Registered offices Cologne and Münster, Germany Registergericht/Registered at Amtsgericht Köln, Germany Eintragungs-Nr./Registration no. HRB 63609 USt-IdNr./VAT ID no. DE 260 789 354
Bug#998831: asciidoc: fails with "missing configuration file"
Package: asciidoc Version: 10.0.1-3 Severity: important Tags: upstream Dear Maintainer, a2x in asciidoc 10 does not parse --asciidoc-opts correctly from the command-line. I've made a detailed upstream bugreport, but was asked to also report this to the debian bugtracker, as we ran into the bug on debian unstable and testing, where asciidoc was recently upgraded to version 10. Upstream bug report: https://github.com/asciidoc-py/asciidoc-py/issues/218 Best regards, Oliver -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-9-amd64 (SMP w/4 CPU threads) Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: unable to detect Versions of packages asciidoc depends on: ii asciidoc-base 10.0.1-3 Versions of packages asciidoc recommends: ii asciidoc-dblatex 10.0.1-3 asciidoc suggests no packages. -- no debconf information -- - Oliver Smith https://www.sysmocom.de/ === * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte
Bug#998679: firefox-esr freezes shortly after start
Firefox-ESR 91.3 doesn't use OpenGL GLX anymore. Instead it uses EGL by default. EGL requires at least mesa version 21.x. Debian stable (bullseye) ships with mesa version 20.3.5 For the nvidia users the following bug report might be important: https://bugzilla.mozilla.org/show_bug.cgi?id=1737428 It's possible to switch back to GLX. To do this you need to open about:config in FF and then change the entry gfx.x11-egl.force-disabled from false to true Suggestion: Try to change gfx.x11-egl.force-disabled to true maybe it solves this bug. If it does, the easiest solution might be to change the code in a away to make FF use GLX by default again for all upcoming ESR versions. The more tortuous solution would be to upgrade mesa to 21.x in Debian stable and newer nvidia drivers in non-free. Best Regards, Oliver C.
Bug#996670: Enable compositor on startup switched off
>> But I guess you had, or some cosmic radiation induced bit switch did it >> for you on your hard disk ;-) The default for all installations is being >> on. > yeah, then lets say "maybe" or "probably" I did that, nevertheless, at least it was a couple of years ago and I cannot remeber ;-) This sounds familiar. Wasn't "Enable compositor..." being disabled also the cause of this week's #998216 ? And I checked: On my system the setting is also disabled, with me not remembering ever having disabled it. My original installation happened many years ago. Did the default maybe change afterwards? Best, Oliver smime.p7s Description: S/MIME Cryptographic Signature
Bug#998517: RFS: diodon/1.11.2-1 [RC] -- GTK+ Clipboard manager
Package: sponsorship-requests Severity: important Dear mentors, I am looking for a sponsor for my package "diodon": * Package name: diodon Version : 1.11.2-1 Upstream Author : Oliver Sauder * URL : https://launchpad.net/diodon * License : LGPL-2.1+, GPL-2+, LGPL-3+ * Vcs : https://git.launchpad.net/~diodon-team/+git/debian-packaging Section : utils It builds those binary packages: diodon - GTK+ Clipboard manager libdiodon0 - GTK+ Clipboard manager (main library) gir1.2-diodon-1.0 - GTK+ Clipboard manager (GObject introspection data) diodon-dev - GTK+ Clipboard manager (development files) To access further information about this package, please visit the following URL: https://mentors.debian.net/package/diodon/ Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/d/diodon/diodon_1.11.2-1.dsc Changes since the last upload: diodon (1.11.2-1) unstable; urgency=medium . * New upstream release. * Fix custom-library-search-path * Removed invalid configure.in file (Closes: #997655) * Bump Standard-Version to 4.6.0 Regards, Oliver
Bug#997655: diodon: FTBFS: autoreconf: error: configure.in: AC_INIT not found; not an autoconf script?
Never mind. Because of custom-library-search-path error [0] there needs to be a new upstream version anyway and with that new release this build error can then be fixed as well. Oliver [0] https://lintian.debian.org/tags/custom-library-search-path
Bug#997655: diodon: FTBFS: autoreconf: error: configure.in: AC_INIT not found; not an autoconf script?
Lucas, Thanks for reporting. This issue has actually been resolved upstream but it seems that I uploaded an invalid orig tarball for version 1.11.1 for the Debian package. Instead of the new upstream tarball 1.11.1, 1.11.0 was still used (when opening the tarball from [0] the folder name is still 1.11.0). Not so sure how this happened. Upstream tarball [1] is correct though. Do you know a way to fix the invalid orig tarball without a new release upstream? Oliver [0] http://deb.debian.org/debian/pool/main/d/diodon/diodon_1.11.1.orig.tar.xz [1] https://launchpad.net/diodon/trunk/1.11.1/+download/diodon-1.11.1.tar.xz
Bug#996781: luarocks: Installation fails with dpkg error
Package: luarocks Version: 3.7.0+dfsg1-1 Severity: grave Justification: renders package unusable Hi, thanks for reviving the package. Now I'm getting this when attempting to install however: Error: Cannot access repository at /root/.luarocks/lib/luarocks/rocks-5.3 dpkg: error processing package luarocks (--configure): installed luarocks package post-installation script subprocess returned error exit status 1 luarocks.postinst: mkdir -p /usr/local/lib/luarocks/rocks/ luarocks-admin make_manifest --local-tree <--- Using local-tree here is probably wrong. Regards, Oliver Versions of packages luarocks depends on: ii liblua5.3-dev 5.3.6-1 ii lua-any27 ii lua5.3 5.3.6-1 ii unzip 6.0-26 ii wget 1.21.2-2+b1 ii zip3.0-12 Versions of packages luarocks recommends: ii lua-sec 1.0.1-1 luarocks suggests no packages.
Bug#954093: desktop-base: Integration with KDE Plasma on Debian 11 no longer works
Hi,
after a quick investigation, I found that even for an initial profile (i.e.
purged before),
the "Image" for [Wallpaper][org.kde.image][General] is already set to the
default image of the utilized theme
before any Plasma script is actually executed.
So the if-condition:
if (!d[i].readConfig('Image')) {
will never be true.
Cheers,
Oliver
Bug#841020: 3.0.0-alpha.2 available without run compilation dependencies
Since version 3.0.0 the library is Java-only. This should ease packaging.
Bug#466407: Automated way to get suite names
Dear Nye Liu /usr/lib/os-release does have enough informations to read the current suite name of the installed system. PRETTY_NAME="Debian GNU/Linux 10 (buster)" NAME="Debian GNU/Linux" VERSION_ID="10" VERSION="10 (buster)" VERSION_CODENAME=buster ID=debian HOME_URL="https://www.debian.org/; SUPPORT_URL="https://www.debian.org/support; BUG_REPORT_URL="https://bugs.debian.org/; and running a single command like "apt search base-files" will give you the information if it is oldstable, stable, testing or something else. Example: apt search base-files Sortierung... Fertig Volltextsuche... Fertig base-files/oldstable,now 10.3+deb10u10 amd64 [installiert] Debian base system miscellaneous files oldstable is in the line base-files/oldstable. If you combine both, you will know the stable/testing to suite name mapping of the current installed system. I hope this helps. Best Regards Oliver
Bug#991446: RFS: diodon/1.11.1-1 [RC] -- GTK+ Clipboard manager
Package: sponsorship-requests Severity: important Dear mentors, I am looking for a sponsor for my package "diodon": * Package name: diodon Version : 1.11.1-1 Upstream Author : Oliver Sauder * URL : https://launchpad.net/diodon * License : LGPL-3+, LGPL-2.1+, GPL-2+ * Vcs : https://git.launchpad.net/~diodon-team/+git/debian-packaging Section : utils It builds those binary packages: diodon-dev - GTK+ Clipboard manager (development files) gir1.2-diodon-1.0 - GTK+ Clipboard manager (GObject introspection data) libdiodon0 - GTK+ Clipboard manager (main library) diodon - GTK+ Clipboard manager To access further information about this package, please visit the following URL: https://mentors.debian.net/package/diodon/ Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/d/diodon/diodon_1.11.1-1.dsc Changes since the last upload: diodon (1.11.1-1) unstable; urgency=medium . * New upstream release. * Removed obsolete apport configuration files (Closes: #990435) * Properly handled previously renamed autostart config file (Closes: 990137) * Use dh gir addon to properly calcuate gir:Depends (Closes: 991081) * Bump Standard Version to 4.5.1 Regards, Oliver
Bug#945229: pinfo exits if lynx is not found
Package: pinfo Version: 0.6.13-1.1 Followup-For: Bug #945229 Yes, but with a clean exit you're even lucky, hit on a broken manpage link (it line breaks on all with a hyphen in it) and it's crashing without even resetting your terminal, which is a bit rude but a different issue. There is a setting for it in pinforc: HTTPVIEWER. Lynx is just the tentative default. Looks like a reasonable choice when pinfo was cooked up, it's been in Debian for 20 years. These days maybe something like w3m might fare slightly better, but a lot of people don't even have a text browser anymore. I use links. About the best one could do I suppose is replacing it with 'sensible-browser' or 'www-browser', it's what we have it for. This is still a solid info browser though. Oliver
Bug#991081: gir1.2-diodon-1.0 lacks dependencies
On 13.07.21 22:19, Adrian Bunk wrote:
> Package: gir1.2-diodon-1.0
> Version: 1.8.0-1
> Severity: serious
>
> ${gir:Depends} needs "dh --with gir" in debian/rules.
> The manual dependency on gir1.2-glib-2.0 is no longer necessary
> when this is fixed.
>
> Something still seems to go wrong afterwards,
> when trying it did not generate a dependency on libdiodon0.
>
Hi Adrian,
Thanks. This is missing indeed. I tried your suggestion and it works but
libdiodon0 dependency is not added as well.
I guess it won't hurt when I add the libdiodon0 manually to depends or
what do you think?
Oliver
Bug#990435: diodon: /etc/apport/ needed?
Hi Chris, Thanks for reporting this. This file is actually obsolete and was only needed when Diodon was only available on Launchpad before publishing it to Debian and synced to Ubuntu from there. See here [0] for more information. This file should indeed be removed from the Debian package. Oliver [0] https://wiki.ubuntu.com/Apport/DeveloperHowTo#Applications_not_included_in_Ubuntu.27s_repositories_but_hosted_on_Launchpad
Bug#990137: diodon: legacy conffiles leftover
Hi Chris Thanks for your report. Actually this was an unnoticed rename of /etc/xdg/autostart/diodon.desktop to /etc/xdg/autostart/diodon-autostart.desktop when Diodon moved to the Meson Build system. I guess using the `dh_installdeb` with a `diodon.mainscript` file will be the easiest as per [0] Oliver [0] https://manpages.debian.org/buster/debhelper/dh_installdeb.1.en.html
Bug#989987: installation-report Bullseye rc2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hello Cyril, you are welcome. On Thu, 17 Jun 2021 15:23:02 +0200 Cyril Brulebois wrote: > Hallo Oliver, > > And thanks for your report. > > Oliver Psotta (2021-06-17): > > [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it > > > > Initial boot: [O ] > > Detect network card:[E ] > > Configure network: [O ] > > Detect media: [E ] > > Load installer modules: [E ] > > Clock/timezone setup: [O ] > > User/password setup:[O ] > > Detect hard drives: [O ] > > Partition hard drives: [O ] > > Install base system:[O ] > > Install tasks: [O ] > > Install boot loader:[O ] > > Overall install:[O ] > > > > Comments/Problems: Graphical Install did not find ethernet, because > > laptop is not equipped with it. But it did not try to search for > > wireless. Instead I was able to choose my wireless Realtek chip in > > ethernet window. > > I do have some laptops around that I'm testing firmware-related issues > with, and I think I've noticed this (to be confirmed): > - on a laptop without wired Ethernet, I'm getting a prompt for the >wireless card and its firmware. > - when booting it with a USB→Ethernet adapter, I'm getting a prompt > for the (possibly missing but actually unimportant) firmware for the >USB→Ethernet adapter, but no mention of the wireless card or > missing firmware. If you want I can send you a screenshot of the Ethernet screen, where I can select WIFI drivers. When I plugged in the USB-Ethernet adapter, I will not be asked anything. Installation then automatically configures network, IP, time and so on. > > > It could not activate the supplied driver from 2nd USB drive. > > Mounting of 2nd USB drive was unreliable. Installation worked well > > after using USB-Ethernet adapter. > > OK, that part I'm not familiar with, and I cannot really comment. > > You could have used one of the unofficial/non-free images that come > with all firmware packages: > > https://cdimage.debian.org/cdimage/unofficial/non-free/cd-including-firmware/ > Good to know, thank you. I will use it for the next installation. > > Installation process of install via ethernet worked well. Gnome > > desktop not useable on built in screen because resolution and > > brightness not changeable, no sound, no BT. > > Alright, I'm currently chasing that kind of issues. You can double > check you're using a software-based rendering by installing the > mesa-utils package, running `glxinfo | grep renderer` should give you > llvmpipe. > > Wild guess, you're lacking: > - firmware-iwlwifi for bluetooth support (I do have a realtek > wireless card here, but the kernel complains about files that are > shipped in that package instead). > - firmware-amd-graphics for proper display support. > - firmware-sof-signed for sound support. > > All those wouldn't have been solved by using the firmware-enabled > images because we're currently lacking some detection, but I'm > working on this. > > For users of official installation images (main-only), I'm wondering > whether to advertise something like this in the installation guide: > > sudo apt install isenkram-cli > sudo isenkram-autoinstall-firmware > sudo reboot > > Please note that due to #989884, one should install isenkram-cli from > unstable to make sure the firmware file to firmware package lookup > works. > > More on such issues on #989863 and follow-up bug reports when I get a > chance to sum up my findings. > The situation right now is: - - Screen resolution, brightness controls and sound are working. Probably because of the AMD firmware I've installed. Also the laptop is not getting warm anymore. - - BT is working with the non-free Realtek firmware. WiFi chip cannot be activated because of the known bug: "rtw88 / rtl_8821ce: rfe 2 is not supported". This bug is fixed on Ubuntu, but the range of WiFi is only 2 meters (also known). On Ubuntu there's a proprietary driver for this which works well. I'm not sure if it is possible to install that on Bullseye. - - Suspend is not working, also known bug. I was reading somewhere that will be fixed in the next main linux kernel. - - Now my renderer is GLX_MESA_query_renderer and for OpenGL it's AMD Renoir. > > Tschüss, Tschüss, Oliver -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEsG582PEz+8y62k/U1tubkH9v9PMFAmDLdpEACgkQ1tubkH9v 9PP4Jw/+KBmCXqtJLFVm1LF8AA92WYju+Hb3o1alr0Xm++DrkR24LY5mvAL9Le6A T9WekudaSMZPp73TBHa2l4UxA1hmHabgQ7b6BeyKEaADLvIWyqlZbcKs8oMCZYKD vaut0VPi0ylNKYt/U6LL2axwO9JMdiI1Hu4XFDvtNNDhP2fi4mo6yy5v6VYO/87u Kl5
Bug#989987: installation-report Bullseye rc2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 PS: I forgot to mention that Gnome forgets the settings of screen brightness after restarts. Same bug with Ubuntu. I could file a bug report. Could you point me to the package that is relevant here? Thanks! -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEsG582PEz+8y62k/U1tubkH9v9PMFAmDLd94ACgkQ1tubkH9v 9PNqnBAAs2ttJNc0VxCoYz1ZVefa/7RzNWSYDQSZ+BM6AZppb8POeyTnYlUZYRjw Qm2i3e3g1kzIVdIAUHJbT5triMJHMxDLIyh21b4h+6/vZ3qOmclXV3JVd0nlSgMA OyzDYJjXAtiUgfuxhVa8XAtPUZMZbYtizXtqB754CpT1VLYUR399m0c41lc/aY1i PfujsXtdR+ozjQ1jRyBl8S0oVzQUEU12gdhNn7uNUMv4JzcNnApiAy6B849JWv/3 CziWIBkxeZK7Puw5ADjLsk7PlsERrf53jeMbLN8VKhXcb39H/wtMCEzZBWwPgV+d nlv8So6qty/HVLrK0BOFDSXrCTxVoQH31BGyxdRHRQ0IpZAUJ1L0K78jSTc8SgVG zoBqYX1jLmLY1qrQHy3rBIuzBfmsbHedvs3tAgn/U19lmSN6UR+ADnI4eWn0Adv0 cm3SiCAuyhA2Ze4naFR2iEDzX4sn+LWSAnkjJ7XYLybi2cXPZQlttgUFFELFMkQw nF7BmK1UaEo5d+qNv4sXdJtYHWYYfKcjlNSTDB9pBzpzuH4V0Wr1TX+Z3a9IcCPd a1F4vjNQBySwHkgSN0756yGaJpsNAQHnJSEXculGErJkMLzMaTooLgbTJfhWppuG z4udK2sA5FSTR93KOypAGxWbvnqfztC/O1GNDtpvMAlGljQwC/w= =8pzZ -END PGP SIGNATURE-
Bug#989987: installation-report Bullseye rc2
Package: installation-reports Severity: normal (Please provide enough information to help the Debian maintainers evaluate the report efficiently - e.g., by filling in the sections below.) Boot method: USB Image version: https://cdimage.debian.org/cdimage/bullseye_di_rc2/amd64/iso-cd/debian-bullseye-DI-rc2-amd64-netinst.iso Date: June 16 2021, 22:00 Machine: HP Pavilion Laptop 15-eh1557ng Partitions: Filesystem Type 1K-blocks Used Available Use% Mounted on udev devtmpfs 78330720 7833072 0% /dev tmpfs tmpfs 1577796 1704 1576092 1% /run /dev/nvme0n1p5 ext4 199490896 4304316 184980220 3% / tmpfs tmpfs 788897263320 7825652 1% /dev/shm tmpfs tmpfs 51204 5116 1% /run/lock /dev/nvme0n1p1 vfat26214472160189984 28% /boot/efi tmpfs tmpfs 1577792 152 1577640 1% /run/user/1000 Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot: [O ] Detect network card:[E ] Configure network: [O ] Detect media: [E ] Load installer modules: [E ] Clock/timezone setup: [O ] User/password setup:[O ] Detect hard drives: [O ] Partition hard drives: [O ] Install base system:[O ] Install tasks: [O ] Install boot loader:[O ] Overall install:[O ] Comments/Problems: Graphical Install did not find ethernet, because laptop is not equipped with it. But it did not try to search for wireless. Instead I was able to choose my wireless Realtek chip in ethernet window. It could not activate the supplied driver from 2nd USB drive. Mounting of 2nd USB drive was unreliable. Installation worked well after using USB-Ethernet adapter. Installation process of install via ethernet worked well. Gnome desktop not useable on built in screen because resolution and brightness not changeable, no sound, no BT. Please make sure that any installation logs that you think would be useful are attached to this report. Please compress large files using gzip. -- Package-specific info: == Installer lsb-release: == DISTRIB_ID=Debian DISTRIB_DESCRIPTION="Debian GNU/Linux installer" DISTRIB_RELEASE="11 (bullseye) - installer build 20210606" X_INSTALLATION_MEDIUM=cdrom == Installer hardware-summary: == uname -a: Linux bullseye 5.10.0-7-amd64 #1 SMP Debian 5.10.40-1 (2021-05-28) x86_64 GNU/Linux lspci -knn: 00:00.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Renoir Root Complex [1022:1630] lspci -knn: Subsystem: Hewlett-Packard Company Device [103c:88d0] lspci -knn: 00:00.2 IOMMU [0806]: Advanced Micro Devices, Inc. [AMD] Renoir IOMMU [1022:1631] lspci -knn: Subsystem: Hewlett-Packard Company Device [103c:88d0] lspci -knn: 00:01.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Renoir PCIe Dummy Host Bridge [1022:1632] lspci -knn: 00:01.3 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Renoir PCIe GPP Bridge [1022:1634] lspci -knn: Kernel driver in use: pcieport lspci -knn: 00:02.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Renoir PCIe Dummy Host Bridge [1022:1632] lspci -knn: 00:02.2 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Renoir PCIe GPP Bridge [1022:1634] lspci -knn: Kernel driver in use: pcieport lspci -knn: 00:02.4 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Renoir PCIe GPP Bridge [1022:1634] lspci -knn: Kernel driver in use: pcieport lspci -knn: 00:08.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Renoir PCIe Dummy Host Bridge [1022:1632] lspci -knn: 00:08.1 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Renoir Internal PCIe GPP Bridge to Bus [1022:1635] lspci -knn: Kernel driver in use: pcieport lspci -knn: 00:08.2 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Renoir Internal PCIe GPP Bridge to Bus [1022:1635] lspci -knn: Kernel driver in use: pcieport lspci -knn: 00:14.0 SMBus [0c05]: Advanced Micro Devices, Inc. [AMD] FCH SMBus Controller [1022:790b] (rev 51) lspci -knn:Subsystem: Advanced Micro Devices, Inc. [AMD] FCH SMBus Controller [1022:790b] lspci -knn: 00:14.3 ISA bridge [0601]: Advanced Micro Devices, Inc. [AMD] FCH LPC Bridge [1022:790e] (rev 51) lspci -knn: Subsystem: Advanced Micro Devices, Inc. [AMD] FCH LPC Bridge [1022:790e] lspci -knn: 00:18.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Renoir Device 24: Function 0 [1022:1448] lspci -knn: 00:18.1 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Renoir Device 24: Function 1 [1022:1449] lspci -knn: 00:18.2 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Renoir Device 24: Function 2 [1022:144a] lspci -knn: 00:18.3 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Renoir Device 24:
Bug#988117: flatpak: Resolved, please close.
Package: flatpak Followup-For: Bug #988117 Sorry, turns out flatpak fish is bound to the SDK runtime, which I didn't want to install. There is no bug. Regards
Bug#988117: flatpak: Some flatpaks unusable with /bin linked
Package: flatpak Version: 1.10.2-1 Severity: normal Tags: upstream Hi! I'm reporting this for flatpak even though point of failure and error message refer to bubblewrap (here 0.4.1-3), but it's clearly more of a flatpak (or flathub) issue. Some of their packages cannot be started once /bin is a link to /usr/bin, as is by now the installation default I think. To give an example, let's say I'm pulling in the fish shell, single partition scenario, then doing the obvious: flatpak run com.visualstudio.code.tool.fish I'll just get an exec error for /bin/sh: no such file There a good reasons for generally not using CLI apps via flatpak to begin with, but that's not the point of this report of course. Regards, Oliver
Bug#950604: gitg crashes even at startup
I get the same crash, but at every start of the program (i.e. without clicking at a specific commit). This makes gitg completely unusable for me. smime.p7s Description: S/MIME Cryptographic Signature
Bug#788176: diodon logs copious sensitive information to zeitgeist and does not clear it
Thanks Sam for reporting this. This is actually not fully related to the original report of this issue as it is a bug that `Clear` method does not completely remove clipboard content from the Zeitgeist database as I agree it really should. As discussed on the upstream issue [0] I will look into this and will track the progress there. [0] https://bugs.launchpad.net/diodon/+bug/1921507
Bug#815196: Hello
Hello Dear How are you doing? Ella
Bug#979622: Wayland: No image on external display when reconnecting
I still see this with current Testing, but now I sometimes have the same problem with X11 too. So I guess it is likely that this is not a Plasma problem but rather a kernel one. Please feel free to close this. Thanks for your work on Debian. smime.p7s Description: S/MIME Cryptographic Signature
Bug#983442: QT_SCREEN_SCALE_FACTORS erroneously set in Wayland session
Package: plasma-desktop Version: 4:5.20.5-3 Severity: normal When I boot and start a Plasma session, the environment variable QT_SCREEN_SCALE_FACTORS is set: ~> echo $QT_SCREEN_SCALE_FACTORS eDP-1=1.5;DP-1=1.5;HDMI-1=1.5;DP-2=1.5;DP-1-1=1.5;DP-1-2=1.5;DP-1-3=1.5; AFAIU this is correct: I did select 1.5 screen scaling via the GUI earlier. When I boot and start a Plasma Wayland session, the same variable is not set. Again, the seems to be correct: Wayland apparently communicates the screen scaling by other means. However, when I boot, and then 1) start a Plasma session 2) log out without reboot 3) start a Plasma Wayland session then QT_SCREEN_SCALE_FACTORS *is* set. And this leads to all sorts of dubious effects, because now the X11 and Wayland scaling mechanisms interfere. Apologies if I am reporting this for the wrong package. Please correct me. Likewise if this is really an upstream problem that should be reported there. -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-3-amd64 (SMP w/8 CPU threads) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.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 plasma-desktop depends on: ii accountsservice 0.6.55-3 ii breeze 4:5.20.5-2 ii kactivitymanagerd5.20.5-1 ii kde-cli-tools4:5.20.5-2 ii kded55.78.0-2 ii kio 5.78.0-4 ii kpackagetool55.78.0-3 ii libaccounts-qt5-11.16-2 ii libc62.31-9 ii libcrypt11:4.4.17-1 ii libglib2.0-0 2.66.7-1 ii libibus-1.0-51.5.23-2 ii libkaccounts24:20.12.1-1 ii libkf5activities55.78.0-2 ii libkf5activitiesstats1 5.78.0-2 ii libkf5authcore5 5.78.0-2 ii libkf5baloo5 5.78.0-2 ii libkf5codecs55.78.0-2 ii libkf5completion55.78.0-3 ii libkf5configcore55.78.0-4 ii libkf5configgui5 5.78.0-4 ii libkf5configwidgets5 5.78.0-2 ii libkf5coreaddons55.78.0-2 ii libkf5crash5 5.78.0-3 ii libkf5dbusaddons55.78.0-2 ii libkf5declarative5 5.78.0-2 ii libkf5globalaccel-bin5.78.0-2 ii libkf5globalaccel5 5.78.0-2 ii libkf5guiaddons5 5.78.0-3 ii libkf5i18n5 5.78.0-2 ii libkf5iconthemes55.78.0-2 ii libkf5itemviews5 5.78.0-2 ii libkf5kcmutils5 5.78.0-3 ii libkf5kdelibs4support5 5.78.0-2 ii libkf5kiocore5 5.78.0-4 ii libkf5kiofilewidgets55.78.0-4 ii libkf5kiogui55.78.0-4 ii libkf5kiowidgets55.78.0-4 ii libkf5notifications5 5.78.0-2 ii libkf5notifyconfig5 5.78.0-2 ii libkf5package5 5.78.0-3 ii libkf5plasma55.78.0-3 ii libkf5plasmaquick5 5.78.0-3 ii libkf5quickaddons5 5.78.0-2 ii libkf5runner55.78.0-3 ii libkf5service-bin5.78.0-2 ii libkf5service5 5.78.0-2 ii libkf5solid5 5.78.0-2 ii libkf5sonnetcore55.78.0-2 ii libkf5sonnetui5 5.78.0-2 ii libkf5wallet-bin 5.78.0-2 ii libkf5wallet55.78.0-2 ii libkf5widgetsaddons5 5.78.0-2 ii libkf5windowsystem5 5.78.0-2 ii libkf5xmlgui55.78.0-2 ii libkworkspace5-5 4:5.20.5-3 ii libnotificationmanager1 4:5.20.5-3 ii libphonon4qt5-4 4:4.11.1-3 ii libprocesscore9 4:5.20.5-1 ii libqt5concurrent55.15.2+dfsg-4 ii libqt5core5a 5.15.2+dfsg-4 ii libqt5dbus5 5.15.2+dfsg-4 ii libqt5gui5 5.15.2+dfsg-4 ii libqt5network5 5.15.2+dfsg-4 ii libqt5qml5 5.15.2+dfsg-4 ii libqt5quick5
Bug#981704: Attempting to use Wacom stylus freezes system
I saw this, too. The latest kernel from unstable fixed it. smime.p7s Description: S/MIME Cryptographic Signature
Bug#979622: Wayland: No image on external display when reconnecting
Package: kscreen Version: 4:5.20.5-1 Severity: normal Apologies if I am not reporting this for the correct package. I try the following steps: 1) Reboot my laptop (ThinkPad X1 Yoga) with external monitor plugged in. The external monitor works as expected. 2) At the SDDM prompt, log into Plasma Wayland. The external monitor still works as it should. 3) Disconnect the external monitor Still everything appears to work as it should. 4) Reconnect the monitor -- it remains black and tells me 'no signal' Nevertheless, the system settings dialog shows me that the external display is correctly recognized. From looking at that dialog everything seems to be in order. 5) Log out of Plasma Wayland, and log back in. 6) The external display is back! This does not happen with Plasma X11. -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-1-amd64 (SMP w/8 CPU threads) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.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 kscreen depends on: ii kde-cli-tools 4:5.20.5-2 ii libc6 2.31-9 ii libkf5configcore5 5.77.0-2 ii libkf5coreaddons5 5.77.0-2 ii libkf5dbusaddons5 5.77.0-2 ii libkf5declarative5 5.77.0-2 ii libkf5globalaccel-bin 5.77.0-3 ii libkf5globalaccel5 5.77.0-3 ii libkf5i18n55.77.0-2 ii libkf5plasma5 5.77.0-2 ii libkf5plasmaquick5 5.77.0-2 ii libkf5quickaddons5 5.77.0-2 ii libkf5screen-bin 4:5.20.5-1 ii libkf5screen7 4:5.20.5-1 ii libkf5xmlgui5 5.77.0-2 ii libqt5core5a 5.15.2+dfsg-2 ii libqt5dbus55.15.2+dfsg-2 ii libqt5gui5 5.15.2+dfsg-2 ii libqt5qml5 5.15.2+dfsg-2 ii libqt5quick5 5.15.2+dfsg-2 ii libqt5sensors5 5.15.2-2 ii libqt5widgets5 5.15.2+dfsg-2 ii libstdc++6 10.2.1-3 ii plasma-framework 5.77.0-2 ii qml-module-qtgraphicaleffects 5.15.2-2 Versions of packages kscreen recommends: ii upower 0.99.11-2 kscreen suggests no packages. -- no debconf information smime.p7s Description: S/MIME Cryptographic Signature
Bug#979354: Acknowledgement (ucf: ucfr aborting when upgrading with diverted config (dpkg-divert))
Attached the patch as a file.
*** usr/bin/ucf~ 2020-06-16 07:37:53.0 +0200
--- usr/bin/ucf 2021-01-05 16:36:12.097133824 +0100
***
*** 439,454
fi
# Follow dpkg-divert as though we are installed as part of $opt_package
! divert_line=$(dpkg-divert --list "$dest_file")
if [ -n "$divert_line" ]; then
!if [ echo "$divert_line" | grep "^local" ]; then
!# local diversion; pick something not in the package namespace
!divert_package="LOCAL"
!else
!# extract the name of the diverted package.
!# The fact that this requires output parsing is bug #485012
!divert_package=$(dpkg-divert --listpackage "$dest_file")
!fi
if [ "$divert_package" != "$opt_package" ]; then
dest_file=$(dpkg-divert --truename "$dest_file")
--- 439,448
fi
# Follow dpkg-divert as though we are installed as part of $opt_package
! divert_line=$(dpkg-divert --listpackage "$dest_file")
if [ -n "$divert_line" ]; then
!# name of the package or 'LOCAL' for a local diversion
!divert_package="$divert_line"
if [ "$divert_package" != "$opt_package" ]; then
dest_file=$(dpkg-divert --truename "$dest_file")
*** usr/bin/ucfr~ 2020-06-16 07:37:53.0 +0200
--- usr/bin/ucfr 2021-01-05 16:39:06.592853096 +0100
***
*** 112,121
awk '{print $1;}' );
if [ "$pkg" != "$old_pkg" ]; then
! if [ "X$FORCE" = "X" ]; then
! echo >&2 "$progname: Attempt from package $pkg to take ${real_conf_file} away from package $old_pkg";
! echo >&2 "ucfr: Aborting.";
! exit 4;
fi
else
if [ "X$VERBOSE" != "X" ]; then
--- 112,129
awk '{print $1;}' );
if [ "$pkg" != "$old_pkg" ]; then
! divert_package=$(dpkg-divert --listpackage "$conf_file")
! if [ -n "$divert_package" ]; then
! if [ "X$VERBOSE" != "X" ]; then
! echo >&2 "$progname: Package $pkg will not take away diverted ${conf_file} from package $divert_package";
! fi
! exit 0;
! else
! if [ "X$FORCE" = "X" ]; then
! echo >&2 "$progname: Attempt from package $pkg to take ${real_conf_file} away from package $old_pkg";
! echo >&2 "ucfr: Aborting.";
! exit 4;
! fi
fi
else
if [ "X$VERBOSE" != "X" ]; then
Bug#979354: ucf: ucfr aborting when upgrading with diverted config (dpkg-divert)
Package: ucf
Version: 3.0043
Severity: important
Dear Maintainer,
ucfr aborts during an unattended upgrade of dovecot when a diverted
configuration file is present:
> Replacing config file /etc/dovecot/dovecot.conf.mypackage with new
version
> ucfr: Attempt from package dovecot-core to take
/etc/dovecot/dovecot.conf.mypackage away from package mypackage
> ucfr: Aborting.
ucf fails when trying to complete the installation (via another
invocation of apt install):
> Setting up dovecot-core (1:2.2.33.2-1ubuntu4.7) ...
> /usr/bin/ucf: 444: [: missing ]
> grep: ]: No such file or directory
> /usr/bin/ucf: 444: [: missing ]
> grep: ]: No such file or directory
The patch below
* makes ucfr respect diverted configuration files,
* fixes the syntax error in ucf and
* makes ucf correctly detect 'local' diversions, bringing it in line
with stable dpkg-divert output as provided by '--listpackage'.
The patch has been tested successfully with ucf/3.0043 backported to
Ubuntu 18.04.
*** usr/bin/ucf~2020-06-16 07:37:53.0 +0200
--- usr/bin/ucf 2021-01-05 16:36:12.097133824 +0100
***
*** 439,454
fi
# Follow dpkg-divert as though we are installed as part of
$opt_package
! divert_line=$(dpkg-divert --list "$dest_file")
if [ -n "$divert_line" ]; then
!if [ echo "$divert_line" | grep "^local" ]; then
!# local diversion; pick something not in the package namespace
!divert_package="LOCAL"
!else
!# extract the name of the diverted package.
!# The fact that this requires output parsing is bug #485012
!divert_package=$(dpkg-divert --listpackage "$dest_file")
!fi
if [ "$divert_package" != "$opt_package" ]; then
dest_file=$(dpkg-divert --truename "$dest_file")
--- 439,448
fi
# Follow dpkg-divert as though we are installed as part of
$opt_package
! divert_line=$(dpkg-divert --listpackage "$dest_file")
if [ -n "$divert_line" ]; then
!# name of the package or 'LOCAL' for a local diversion
!divert_package="$divert_line"
if [ "$divert_package" != "$opt_package" ]; then
dest_file=$(dpkg-divert --truename "$dest_file")
*** usr/bin/ucfr~ 2020-06-16 07:37:53.0 +0200
--- usr/bin/ucfr2021-01-05 16:39:06.592853096 +0100
***
*** 112,121
awk '{print $1;}' );
if [ "$pkg" != "$old_pkg" ]; then
! if [ "X$FORCE" = "X" ]; then
! echo >&2 "$progname: Attempt from package $pkg to
take ${real_conf_file} away from package $old_pkg";
! echo >&2 "ucfr: Aborting.";
! exit 4;
fi
else
if [ "X$VERBOSE" != "X" ]; then
--- 112,129
awk '{print $1;}' );
if [ "$pkg" != "$old_pkg" ]; then
! divert_package=$(dpkg-divert --listpackage "$conf_file")
! if [ -n "$divert_package" ]; then
! if [ "X$VERBOSE" != "X" ]; then
! echo >&2 "$progname: Package $pkg will not take
away diverted ${conf_file} from package $divert_package";
! fi
! exit 0;
! else
! if [ "X$FORCE" = "X" ]; then
! echo >&2 "$progname: Attempt from package
$pkg to take ${real_conf_file} away from package $old_pkg";
! echo >&2 "ucfr: Aborting.";
! exit 4;
! fi
fi
else
if [ "X$VERBOSE" != "X" ]; then
Bug#978699: sockstat: Manpage should mention privilege needed
Package: sockstat Version: 0.4.1-1 Severity: normal Hi, in contrast to `ss` (and others) I'm getting no output with `sockstat` being run as a normal user, which is unclear from the manpage or README and cannot be expected for something living under /usr/bin. (It lists holding process by default.) Of course, a usage note to this effect would be better still, considering a lone header line isn't all that helpful. And I'm ending up with this even with open sockets that are my own. The output also isn't exactly consistent even when run as root: `sockstat -4 -l` shows some connected ones, whereas '-4 -c' whill show (some) from the other group. I don't even see a pattern here, it's rather confusing as is anything that's not exclusive if the default is already all-inclusive (according to the manpage). `sockstat` on FreeBSD also works very differently. Regards, Oliver
Bug#978581: libjs-vue-router mismatched path-to-regexp
Package: libjs-vue-router
Version: 3.4.9+ds-1
3.4.9+ds-1 packages an incompatible version of path-to-regexp. This was
reported and fixed in bug #927254, but is now reproducible again in
version 3.4.9+ds-1.
Specifically, the tokensToRegExp function is lacking the attachKeys
wrapper around its return value.
>From upstream 3.4.9:
function tokensToRegExp (tokens, keys, options) {
[...]
return attachKeys(new RegExp('^' + route, flags(options)), keys)
}
>From 3.4.9+ds-1
function tokensToRegexp(tokens, keys, options) {
[...]
return new RegExp(route, flags(options));
}
Bug#977586: diodon: list of clipboard items not updating (database or disk is full)
I assume the sqlite database got corrupted or is too big. There is an article here [0] which describes why this could happen. Diodon uses Zeitgeist to store clipboard items and zeitgeist manages the sqlite database itself. So you find the database at ~/.local/share/zeitgeist/. Best have a look what size the database has in this folder to see whether that is the issue. Simply renaming/removing the zeitgeist folder should fix the issue. (I guess you need to stop/kill the zeitgeist-daemon first though) Oliver [0] https://stackoverflow.com/questions/5274202/sqlite3-database-or-disk-is-full-the-database-disk-image-is-malformed
Bug#977503: sssd-krb5: DIR: credential cache collection creates directory with wrong mode (0600) and subsequently fails
Package: sssd-krb5
Version: 1.16.3-3.2
Severity: important
Dear maintainers,
credential collections of type "DIR:dirname" fail since the directory is
created by sssd-krb5 with broken permissions 0600,
as also mentioned in #977375.
This has already been reported upstream in [0] by another user, and after I
bumped the problem, a patch has been posted at that URL,
which I have tested on top of sssd-1.16.3-3.2 by rebuilding the package with
the patch applied,
configuring /etc/krb5.conf accordingly:
[libdefaults]
...
default_ccache_name = DIR:/tmp/krb5cc_%{uid}
purging all existing such directories and retrying. I can confirm that the
patch works as expected.
The issue is now also reported to upstream's bugtracker[1]
and a PR[2] against their master branch has been made by the patch developer.
Note that the very same patch applies fine against 1.16.3 with slightly
different offsets and was verified as discussed above.
-- System Information
Debian Release: 10.7
Kernel: 4.19.0-13
Architecture: amd64 (x86_64)
[0]
https://lists.fedorahosted.org/archives/list/sssd-us...@lists.fedorahosted.org/thread/3FH5A2M64KKVTPRUCWV4LLGWEYTV7CL5/
[1] https://github.com/SSSD/sssd/issues/5436
[2] https://github.com/SSSD/sssd/pull/5437
Bug#977375: sssd(-krb5): All Kerberos credential cache collections unusable
Package: sssd-krb5 Version: 1.16.3-3.2 Severity: important Dear maintainers, all Kerberos credential cache collections are unusable with sssd and the Debian kernel in Buster. Details: 1) KEYRING:persistent fails to work since CONFIG_PERSISTENT_KEYRINGS is not set in the Kernel. Effectively, this yields a flaky (sometimes working, sometimes not) setup at runtime, since Kerberos falls back to the user keyring, and sssd-krb5's krb5_child and the kernel keyring garbage collector race. This is likely also one of the causes of #861222 (affects Jessie, in CC). Since the kernel option has been set to "yes" as of 5.5.17-1, I'm also CCing debian-kernel ML. 2) DIR:dirname fails since the directory is created by sssd-krb5 with broken permissions 0600. This has already been reported upstream in [0] by another user, but upstream recommended to use KEYRING:persistent instead, since DIR:dirname is not well tested. 3) KCM: fails with many or large tickets, as outlined in an upstream bug[1] only fixed in very recent sssd versions (>= 2.3) by a series of large patches. I can open separate bugs on (1), (2) and (3) if wanted, but I imagine starting with an overview (since all collections are broken) is a better starting point (and fixing a single one definitely lower severity). On a side-note, cache collections are needed in case tickets for multiple realms are to be stored, i.e. this issue affects any users working in multiple realms (and relying on SSSD). Non-SSSD consumers can work around the issue by using (2). -- System Information Debian Release: 10.7 Kernel: 4.19.0-13 Architecture: amd64 (x86_64) [0] https://lists.fedorahosted.org/archives/list/sssd-us...@lists.fedorahosted.org/thread/3FH5A2M64KKVTPRUCWV4LLGWEYTV7CL5/ [1] https://github.com/SSSD/sssd/issues/4413 smime.p7s Description: S/MIME Cryptographic Signature
