Bug#983401: [Pkg-zfsonlinux-devel] Bug#983401: zfs-zed: Update of zfs-zed from buster-backports fails.
Dear Antonio, dear Yurii, Yes, I remember following the guide on the openzfs site when I set up the zfs volume as Yurii pointed out. I did not remember creating the symlink. Sorry for creating confusion. Best, Andreas On 2/24/21 1:07 AM, Antonio Russo wrote: Control: tag -1 patch Hello Andreas, Deleting these old symlinks from (presumably) another ZFS packaging is indeed the correct fix. I do think we could handle this case slightly more nicely, and I've opened an MR on salsa [1] that should fix this. Best, Antonio [1] https://salsa.debian.org/zfsonlinux-team/zfs/-/merge_requests/38
Bug#983401: zfs-zed: Update of zfs-zed from buster-backports fails.
Package: zfs-zed Version: 2.0.2-1~bpo10+1 Severity: normal Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? I tried to upgrade the package zfs-zed to the new version in buster-backports. * What exactly did you do (or not do) that was effective (or ineffective)? apt-get dist-upgrade * What was the outcome of this action? Setting up zfs-zed (2.0.2-1~bpo10+1) ... Installing new version of config file /etc/init.d/zfs-zed ... Installing new version of config file /etc/zfs/zed.d/zed-functions.sh ... Installing new version of config file /etc/zfs/zed.d/zed.rc ... ln: failed to create symbolic link '/etc/zfs/zed.d/history_event-zfs-list- cacher.sh': File exists dpkg: error processing package zfs-zed (--configure): installed zfs-zed package post-installation script subprocess returned error exit status 1 Processing triggers for systemd (241-7~deb10u6) ... Errors were encountered while processing: zfs-zed E: Sub-process /usr/bin/dpkg returned an error code (1) * What outcome did you expect instead? I expected the upgrade to terminate without errors. I deleted the symlink to /etc/zfs/zed.d/history_event-zfs-list-cacher.sh. Then the package upgraded without errors. Please see also http://forums.debian.net/viewtopic.php?f=5=148979 Best regards, Andreas -- System Information: Debian Release: 10.8 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-14-amd64 (SMP w/16 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages zfs-zed depends on: ii init-system-helpers 1.56+nmu1 ii libc6 2.28-10 ii libnvpair3linux 2.0.2-1~bpo10+1 ii libudev1241-7~deb10u6 ii libuuid12.33.1-0.1 ii libuutil3linux 2.0.2-1~bpo10+1 ii libzfs4linux2.0.2-1~bpo10+1 ii zfs-dkms [zfs-modules] 2.0.2-1~bpo10+1 ii zfsutils-linux 2.0.2-1~bpo10+1 zfs-zed recommends no packages. zfs-zed suggests no packages. -- no debconf information
Bug#920633: bumblebee: Entry 'Driver=nvidia' not added in bumblebee.conf after bumblebee installation
Package: bumblebee Version: 3.2.1-19 Severity: important Dear Maintainer, I installed bumblebee on a fresh installation of buster on a Dell G3 3579 with GTX1060 MaxQ following the instructions on https://wiki.debian.org/Bumblebee. Before installing bumblebee, I had added i386 architecture. Optirun then returned: [ 1778.285793] [ERROR]Cannot access secondary GPU - error: Could not enable discrete graphics card [ 1778.285868] [ERROR]Aborting because fallback start is disabled. In bumblebee.conf, I had to make the following changes: [bumblebeed] Driver=nvidia [driver-nvidia] PMMETHOD=none Driver was empty before, and PPMETHOD was set to auto. I am not sure if the latter setting is needed. With these changes, optirun and primusrun work: christ@CARTMAN:~$ optirun inxi -G Graphics: Device-1: Intel UHD Graphics 630 driver: i915 v: kernel Device-2: NVIDIA GP106M [GeForce GTX 1060] driver: nvidia v: 390.87 Display: x11 server: X.Org 1.20.3 driver: modesetting unloaded: fbdev,vesa resolution: 1920x1080~60Hz OpenGL: renderer: GeForce GTX 1060 with Max-Q Design/PCIe/SSE2 v: 4.6.0 NVIDIA 390.87 As I found a lot of reports about problems with bumblebee and tlp, I wanted to mention that I do not have tlp installed. Best regards, Andreas Christ -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-1-amd64 (SMP w/12 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages bumblebee depends on: ii bbswitch-dkms 0.8-8 ii dpkg 1.19.2 ii libbsd00.9.1-1 ii libc6 2.28-5 ii libglib2.0-0 2.58.2-3 ii libkmod2 25-2 ii libx11-6 2:1.6.7-1 ii lsb-base 10.2018112800 ii xserver-xorg-core 2:1.20.3-1 Versions of packages bumblebee recommends: ii primus 0~20150328-7 Versions of packages bumblebee suggests: ii bumblebee-nvidia 3.2.1-19 -- Configuration Files: /etc/bumblebee/bumblebee.conf changed: [bumblebeed] VirtualDisplay=:8 KeepUnusedXServer=false ServerGroup=bumblebee TurnCardOffAtExit=false NoEcoModeOverride=false Driver=nvidia XorgConfDir=/etc/bumblebee/xorg.conf.d XorgBinary=/usr/lib/xorg/Xorg [optirun] Bridge=auto VGLTransport=proxy PrimusLibraryPath=/usr/lib/x86_64-linux-gnu/primus:/usr/lib/i386-linux-gnu/primus:/usr/lib/primus:/usr/lib32/primus AllowFallbackToIGC=false [driver-nvidia] KernelDriver=nvidia PMMethod=none LibraryPath=/usr/lib/x86_64-linux-gnu/nvidia:/usr/lib/i386-linux-gnu/nvidia:/usr/lib/nvidia XorgModulePath=/usr/lib/nvidia/nvidia,/usr/lib/xorg/modules XorgConfFile=/etc/bumblebee/xorg.conf.nvidia AlwaysUnloadKernelDriver=false [driver-nouveau] KernelDriver=nouveau PMMethod=auto XorgConfFile=/etc/bumblebee/xorg.conf.nouveau -- no debconf information
Bug#890374: lirc: 'pre' and 'post' in *.conf is ignored if no 'pre_data', 'post_data'
Package: lirc
Version: 0.9.4c-9
Severity: normal
Tags: patch
Dear Maintainer,
In a configuration file for a remote control, I use 'post' to send a pulse
(30 us) and a space (460 us) after the data, then ptrail for a trailing pulse.
The 'post' cannot be part of 'data' as the space of 'zero' and 'one' is 650 us
and 830 us (not 460 us). The pulse and space configured in 'post' is, however,
not sent, i.e., the 'post' directive is silently ignored.
Looking into the source code I found the issue in lib/transmit.c:
'post' (i.e., a pulse and a space of specific lengths) is only sent if also
'post_data' (i.e., a sequence of 'zero' and 'one') is configured. The function
send_post(remote) checks if has_post(remote) is true; this is only true if
remote->post_data_bits > 0.
Same applies to 'pre' and 'pre_data'.
This limitation is not described in the documentation
(see http://www.lirc.org/html/lircd.conf.html). Thus, I suggest to either
update the documentation or fix the code. I prefer the latter as I see no logic
why a directive should be ignored. I attach a patch.
For my specific use case, I have a workaround: I replace 'ptrail' by a single
bit 'post_data'. This only works because the 'ptrail' pulse happens to have
the same duration as the pulse of 'one'. Thus, I now have 'post_data' and
therefore 'post' is no longer ignored. My workaround results in having two
spaces at the end (the space of the 'one' from 'post_data' and the 'gap'); this
does no harm.
I have not found a generic workaround that can be used if the trailing pulse
has a different duration than 'one' and 'zero', nor for repeat sequences.
Best regards
Andreas
-- System Information:
Distributor ID: Raspbian
Description:Raspbian GNU/Linux 9.3 (stretch)
Release:9.3
Codename: stretch
Architecture: armv7l
Kernel: Linux 4.9.59-v7+ (SMP w/4 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages lirc depends on:
ii init-system-helpers 1.48
ii libasound2 1.1.3-5+rpi3
ii libc62.24-11+deb9u1
ii libftdi1-2 1.3-2
ii libgcc1 1:6.3.0-18+rpi1
ii liblirc-client0 0.9.4c-9
ii liblirc0 0.9.4c-9
ii libportaudio219.6.0-1
ii libstdc++6 6.3.0-18+rpi1
ii libsystemd0 232-25+deb9u1
ii libudev1 232-25+deb9u1
ii libusb-0.1-4 2:0.1.12-30
ii libusb-1.0-0 2:1.0.21-1
ii lsb-base 9.20161125+rpi1
ii python3 3.5.3-1
Versions of packages lirc recommends:
pn gir1.2-vte
ii python3-gi3.22.0-2
ii python3-yaml 3.12-1
Versions of packages lirc suggests:
pn ir-keytable
pn lirc-compat-remotes
pn lirc-doc
pn lirc-drv-irman
pn lirc-x
pn setserial
-- no debconf information
diff --git a/lib/transmit.c b/lib/transmit.c
index 178e889..28a4af4 100644
--- a/lib/transmit.c
+++ b/lib/transmit.c
@@ -302,20 +302,20 @@ static void send_pre(struct ir_remote* remote)
{
if (has_pre(remote)) {
send_data(remote, remote->pre_data, remote->pre_data_bits, 0);
+}
if (remote->pre_p > 0 && remote->pre_s > 0) {
send_pulse(remote->pre_p);
send_space(remote->pre_s);
}
- }
}
static void send_post(struct ir_remote* remote)
{
- if (has_post(remote)) {
if (remote->post_p > 0 && remote->post_s > 0) {
send_pulse(remote->post_p);
send_space(remote->post_s);
}
+if (has_post(remote)) {
send_data(remote, remote->post_data, remote->post_data_bits,
remote->pre_data_bits + remote->bits);
}
}
