Bug#1056122: slurmctld.log not available after logrotate
Package: slurmctld
Version: 22.05.8-4+deb12u1
Severity: normal
Tags: patch
X-Debbugs-Cc: alois.schlo...@gmail.com
Dear Maintainer,
After migrating the slurmctld from debian11/slurm20 to a host with
debian12/slurm22,
/var/log/slurm/slurmctld.log was rotated at midnight, to
/var/log/slurm/slurmctld.log.1.gz
but no /var/log/slurm/slurmctld.log was generated.
syslog of logrotate showed this log message:
2023-11-17T00:00:01.825407+01:00 l74 logrotate[3441040]:
start-stop-daemon: matching only on non-root pidfile
/var/run/slurm/slurmctld.pid is insecure
2023-11-17T00:00:03.356036+01:00 l74 logrotate[3440981]: error:
Compressing program wrote following message to stderr when compressing
log /var/log/slurm/slurmctld.log.1:
2023-11-17T00:00:03.356307+01:00 l74 logrotate[3440981]: gzip:
stdin: file size changed while zipping
I believe the following patch fixes the issue:
l74:# diff -uw /etc/logrotate.d/slurmctld.orig
/etc/logrotate.d/slurmctld
--- /etc/logrotate.d/slurmctld.orig 2023-11-17 10:15:45.751842740 +0100
+++ /etc/logrotate.d/slurmctld 2023-11-17 10:15:30.132636120 +0100
@@ -3,7 +3,7 @@
missingok
nocopytruncate
nocreate
- nodelaycompress
+ delaycompress
nomail
notifempty
noolddir
I'd like suggesting to include this change in the slurmctld package.
-- System Information:
Debian Release: 12.2
APT prefers stable-security
APT policy: (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 6.1.0-13-amd64 (SMP w/56 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN,
TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE
not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages slurmctld depends on:
ii libc6 2.36-9+deb12u3
ii munge 0.5.15-2
ii slurm-client 22.05.8-4+deb12u1
ii slurm-wlm-basic-plugins 22.05.8-4+deb12u1
ii ucf 3.0043+nmu1
slurmctld recommends no packages.
slurmctld suggests no packages.
-- Configuration Files:
/etc/logrotate.d/slurmctld changed:
/var/log/slurm-llnl/slurmctld.log /var/log/slurm/slurmctld.log {
compress
missingok
nocopytruncate
nocreate
delaycompress
nomail
notifempty
noolddir
rotate 12
sharedscripts
size=5M
postrotate
/usr/sbin/invoke-rc.d --quiet slurmctld reconfig >/dev/null
/bin/sleep 1
endscript
}
Bug#1050446: nfs over rdma between debian12 client and debian11 server can cause data corruption
Severity: wishlist We run more tests, and observed that pgrading the storage server to Debian12(/bookwork solves the issue. The storage server can be accessed through rdma from debian11 and 12. That means, the problem occurs only when the storage server is on debian11, the client is on debian11 mounted with proto=rdma. This information is good enough for us, as we'll upgrade first the storage server. Another workaround is to switch to proto=tcp As this issue (proto=rdma from debian12 client to debian11 server) is difficult to fix and a workaround exists, I'll downgrade the severity.
Bug#1051264: 2 bugs in reading ABF2 files - patches are available.
Package: biosig Version: 2.5.0 -1 I'd like to make you also aware of two bugs in the ABF2 format. One is about how information about sweeps is not included in the eventable, there other is about some scaling issues on float32 ABF2 file . https://github.com/neurodroid/stimfit/issues/104 https://github.com/neurodroid/stimfit/issues/102 These two bugs have been fixed in biosig 2.5.1 and later by these two patches: https://sourceforge.net/p/biosig/code/ci/662c1b34e13758f8d0fc16a98cae2de802366ee9/ https://sourceforge.net/p/biosig/code/ci/4bbbcf3b906092ee316f6331f19c96757b5c6a12/ It would be great if these fixes could be applied in the debian releases, too. Either be applying these patches against biosig 2.5.0 release in stable/bookworm, or by providing biosig 2.5.2 in backports. Alois ||
Bug#1050446: nfs over rdma between debian12 client and debian11 server can cause data corruption
Package: nfs-common,rdma-core I've been testing the upgrade of a compute node from Debian11 to Debian12. That node was connected through nfs with rdma protocol to a zfs-storage server running on Debian11. The compute node and the storage server are part of a high-performance compute cluster, connected over infiniband. Not sure whether this is important, but the storage server is using zfs. After the upgrade of the compute node (node client) to Debian 12, this machine could not correctly read a few (small) files. The files were correctly shown with "ls", and the size matched as well. However the content was corrupted (looked like random garbage). In one case the .ssh/authorized_keys was corrupted, in some other case the "version.lua" from the lmod system was affected, rendering lmod unusable. Interestingly, only very few files seemed to be affected. Most files were correctly retrieved. So this is a very subtle error, and not obvious. When retrieving these files, no error was reported, but data of the expected size was retrieved. Effectively, the retrieved data was corrupted, and could lead to potential data loss. The compute node on Debian12 had ii libnfsidmap1:amd641:2.6.2-4 amd64NFS idmapping library ii nfs-common1:2.6.2-4 amd64NFS support files common to client and server ii librdmacm1:amd64 44.0-2 amd64Library for managing RDMA connections ii rdma-core 44.0-2 amd64RDMA core userspace infrastructure and documentation ii rdmacm-utils 44.0-2 amd64Examples for the librdmacm library The storage server on Debian11 had ii nfs-common 1:1.3.4-6 amd64 NFS support files common to client and server ii nfs-kernel-server 1:1.3.4-6 amd64 support for NFS kernel server ii librdmacm1:amd64 33.2-1 amd64 Library for managing RDMA connections The problem went away, when changing nfs mount protocal from proto=rdma to proto=tcp. I tried to learn about this incompatibility, but did not find any information. I'm also curious whether an nfs 2.6 server would correctly talk to an nfs 1.3 client over rdma ? Can anyone provide more information on that topic ?
Bug#1037349: Switch to PipeWire with Debian 12
On Tue, 25 Jul 2023 08:19:23 + Marc Leurent wrote: > Hello > > I was coping with the same problem after and upgrade Debian 11->12 and was starting pulseaudio manually like you > Here is the solution I used > Debian 12 now also comes with https://wiki.debian.org/PipeWire which has a pulseaudio implementation > I did fix the problem by using "apt install pipewire pipewire-audio-client-libraries" + reboot > It did purge pulseaudio and now provides sound via pipewire > > Start-Date: 2023-07-25 10:02:41 > Commandline: apt install pipewire pipewire-audio-client-libraries > Requested-By: mlr (1000) > Install: pipewire-pulse:amd64 (0.3.65-3, automatic), pipewire-audio-client-libraries:amd64 (0.3.65-3), pipewire:amd64 (0.3.65-3), pipewire-jack:amd64 (0.3.65-3, automatic), pipewire-audio:amd64 (0.3.65-3, automatic), wireplumber:amd64 ( > 0.4.13-1, automatic), pipewire-alsa:amd64 (0.3.65-3, automatic), libwireplumber-0.4-0:amd64 (0.4.13-1, automatic) > Remove: pulseaudio-module-gsettings:amd64 (16.1+dfsg1-2+b1), pulseaudio:amd64 (16.1+dfsg1-2+b1), pulseaudio-module-bluetooth:amd64 (16.1+dfsg1-2+b1) > End-Date: 2023-07-25 10:02:44 > > > > Best Regards Thanks for these hints. These lead in the right directions but was not sufficient for me. So I followed also the instructions from https://wiki.debian.org/PipeWire#Debian_12 and run also # apt install wireplumber pipewire-media-session- $ systemctl --user --now enable wireplumber.service This did not immediately provide a solution, and then after trying connect head phones and installing qpwgraph, I got sound. And sound was still available after reboot - so the is no need anymore to run "systemctl --user " after a reboot. I'm not sure which step was decisive here - fiddling with the headphone plug, or installing one of these other packages. Here is my apt/history on this: Start-Date: 2023-07-25 19:45:52 Commandline: apt install pipewire pipewire-audio-client-libraries Install: pipewire-audio-client-libraries:amd64 (0.3.65-3), pipewire-jack:amd64 (0.3.65-3, automatic), pipewire-alsa:amd64 (0.3.65-3, automatic) Remove: pulseaudio:amd64 (16.1+dfsg1-2+b1) End-Date: 2023-07-25 19:45:57 Start-Date: 2023-07-25 19:54:34 Commandline: apt purge pulseaudio Purge: pulseaudio:amd64 () End-Date: 2023-07-25 19:54:37 Start-Date: 2023-07-25 19:59:56 Commandline: apt install wireplumber pipewire-media-session- Install: wireplumber:amd64 (0.4.13-1), libwireplumber-0.4-0:amd64 (0.4.13-1, automatic) End-Date: 2023-07-25 19:59:58 Start-Date: 2023-07-25 20:04:46 Commandline: apt install qpwgraph Install: libqt6network6:amd64 (6.4.2+dfsg-10, automatic), qt6-gtk-platformtheme:amd64 (6.4.2+dfsg-10, automatic), libqt6widgets6:amd64 (6.4.2+dfsg-10, automatic), libqt6dbus6:amd64 (6.4.2+dfsg-10, automatic), libqt6gui6:amd64 (6.4.2+dfsg-10, automatic), libqt6xml6:amd64 (6.4.2+dfsg-10, automatic), qpwgraph:amd64 (0.3.9-1), qt6-qpa-plugins:amd64 (6.4.2+dfsg-10, automatic), libts0:amd64 (1.22-1+b1, automatic) End-Date: 2023-07-25 20:05:00
Bug#1037349: pulseaudio: PulseAudio daemon does not start after upgrade to Debian 12
I observe the same issue on an Lenovo L480 laptop. After upgrading from Debian11 to Debian12, audio/sound did not work anymore. Running these commands systemctl --user stop pulseaudio.socket systemctl --user stop pulseaudio.service systemctl --user start pulseaudio.socket systemctl --user start pulseaudio.service enables the the audio system. But the settings do not survive a reboot. I'm using the Mate desktop. Let me know if you need anymore information. Cheers, Alois
Bug#1010001: Acknowledgement (libbiosig3: incorrect sample rate when reading IBW files)
Am 1/5/23 um 08:09 schrieb Andreas Tille:
Hi Alois,
Am Wed, Jan 04, 2023 at 11:00:13PM +0100 schrieb Alois Schlögl:
Yes, providing an update through debian-backports would be very helpful.
In the meantime, v2.5.0 has been released with several more bugfixes and new
features [1].
I've tried upgrading the debian build [1] but was not able to complete this.
It would be great if you would take care of packaging biosig v2.5.0 for
debian backports and sid.
The simple fix for the watch file was s/gz$/xz/. I've updated the package.
Seems you are the last man standing on sourceforge. Interesting that active
developers are not yet moved to git{hub,lab} these days. BTW, the download
tarball always contains pretty superflous autom4te.cache/ dir which should
be removed - possibly also without config.guess, config.status and config.h.in~
- maybe even without configure and all the auto-generated stuff.
Kind regards
Andreas.
Thanks for the hints about the superfluous files, I'll adapt my release
procedure.
configure and some autogenerated stuff is useful when autoconf, gawk is
not installed, so that
./configure && make && make install
just work.
Concerning SF and GITLAB, there is a copy of the git repo at
https://git.ista.ac.at/alois.schloegl/code
If you prefer to work with tags in git{lab,} you can use also the
release from here
https://git.ista.ac.at/alois.schloegl/code/-/tags/libbiosig-2.5.0
Kind regards,
Alois
Bug#1010001: Acknowledgement (libbiosig3: incorrect sample rate when reading IBW files)
Hi Alois, thank you for your bug report with patch. Unfortunately we can only fix RC bugs in Debian stable. I wonder whether you would consider it a sensible solution to backport biosig 2.3.3 to debian-backports? Kind regards Andreas. Hi Andreas, Yes, providing an update through debian-backports would be very helpful. In the meantime, v2.5.0 has been released with several more bugfixes and new features [1]. I've tried upgrading the debian build [1] but was not able to complete this. It would be great if you would take care of packaging biosig v2.5.0 for debian backports and sid. Kind regards, Alois [1] https://sourceforge.net/p/biosig/code/ci/190d4fb71a1069c4cbfb43a4fc2891f56a325133/
Bug#1019791: stimfit: Please transition to wxwidgets3.2
In order to upgrade the dependency of stimfit to wxwidgets 3.2 the patch [1] should be sufficient. However, I recommend to upgrade stimfit to tag v0.16.1debian [2]. Cheers, Alois [1] https://github.com/neurodroid/stimfit/commit/a929d364c19195230e3b923726aef477479484a3 [2] https://github.com/neurodroid/stimfit/releases/tag/v0.16.1debian
Bug#1007832: vulkaninfo,vkcube seg-faults on remote access.
Control: reassign 1007832 mesa 20.3.5-1 Further testing shows that this bug is related to mesa 20.3.5-1 (on bullseye). Therefore, this bug should be assigned to the mesa package. The issue goes away when a more recent version of mesa is compiled from source and the resulting libGL.so is preloaded on the remote machine. Then, vulkan-tools, vulkaninfo will not crash. This suggests the problem is caused by libgl1 from mesa 20.3.5-1. Most likely, libGL.so from libgl1 package is the culprit. The test was successful test, when using using mesa/22.1.5 (and later versions including 22.2.0) libdrm/2.4.112 and llvm/13.0.1 and configuring mesa with the following options -Degl=disabled \ -Dgles1=enabled \ -Dgles2=enabled \ -Dshared-glapi=enabled \ -Dglx=xlib \ -Dgallium-drivers=swrast \ -Dvulkan-drivers=intel,swrast \ -Dplatforms=x11 \ -Ddri3=enabled \ -Ddri-drivers="" \ -Dswr-arches=avx,avx2,skx \ -Dcpp_rtti=false \ The test is also successful when compiling mesa/22.2.0 with the following configuration -Dcpp_rtti=false \ -Ddri3=enabled \ -Ddri-drivers="" \ -Degl=disabled \ -Dgallium-drivers=swrast,virgl,svga,d3d12,zink,iris,crocus,i915 \ -Dgallium-xa=enabled \ -Dgles1=enabled \ -Dgles2=enabled \ -Dglx=xlib \ -Dosmesa=true \ -Dplatforms=x11 \ -Dshared-glapi=enabled \ -Dvulkan-drivers=intel,swrast,virtio-experimental,imagination-experimental \ Maybe this helps to bisect the issue.
Bug#1007832: vulkan-tools: vulkaninfo,vkcube seg-faults on head-less cuda/gpu machine
Control: retitle -1 vulkaninfo,vkcube seg-faults on remote access. The issue is unrelated to cuda, but seems to be related to any remote access. The issue can be easily reproduced on a local machine, when doing this: ssh -X localhost $ vkcube MESA-INTEL: warning: Haswell Vulkan support is incomplete Segmentation fault $ vkcubepp MESA-INTEL: warning: Haswell Vulkan support is incomplete Segmentation fault vulkaninfo shows a lot of information, seg-faults also at the and.
Bug#1010001: libbiosig3: incorrect sample rate when reading IBW files
Package: libbiosig3
Version: 2.1.2-4
Severity: normal
Tags: patch
X-Debbugs-Cc: alois.schlo...@gmail.com
Dear Maintainer,
libbiosig supports reading many different data formats, including the
IgorBinaryWaveform (IBW) format.
When reading this data, an incorrect sampling rate (e.g. 25 Hz instead of 25
kHz)
is returned, because the scaling of the scaling of physical units for the
sampling interval
milli-seconds is not correctly considered. This affacts all tools using
libbiosig,
including biosig-tools, mexSLOAD and mexSOPEN in octave-biosig, sigviewer,
stimfit,
and all other language bindings.
The attached patch fixes this bug, and fixes als uninitialized data in the
event table.
I suggest to backport this to the current stable release.
-- System Information:
Debian Release: 11.3
APT prefers stable-security
APT policy: (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.10.0-13-amd64 (SMP w/8 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages libbiosig3 depends on:
ii libc6 2.31-13+deb11u3
ii libdcmtk15 3.6.5-1
ii libgcc-s1 10.2.1-6
ii libstdc++6 10.2.1-6
ii libtinyxml2.6.2v5 2.6.2-4
libbiosig3 recommends no packages.
libbiosig3 suggests no packages.
-- no debconf information
diff --git a/biosig4c++/t210/sopen_igor.c b/biosig4c++/t210/sopen_igor.c
index deb82631..c4d1ced6 100644
--- a/biosig4c++/t210/sopen_igor.c
+++ b/biosig4c++/t210/sopen_igor.c
@@ -383,7 +383,7 @@ void sopen_ibw_read (HDRTYPE* hdr) {
int16_t type = 0; // See types (e.g. NT_FP64)
above. Zero for text waves.
hdr->NS = 1;
- hdr->SampleRate = 1;
+ hdr->SampleRate = 1.0;
hdr->CHANNEL = (CHANNEL_TYPE*) realloc(hdr->CHANNEL, hdr->NS *
sizeof(CHANNEL_TYPE));
// Read some of the WaveHeader fields.
@@ -407,7 +407,7 @@ void sopen_ibw_read (HDRTYPE* hdr) {
hdr->CHANNEL[0].DigMin =
(w2->botFullScale-w2->hsB) / w2->hsA;
*/
#else
- hdr->SampleRate = 1.0 / w2->hsA;
+ hdr->SampleRate /= w2->hsA *
PhysDimScale(PhysDimCode(w2->xUnits));
hdr->CHANNEL[0].PhysMax = w2->topFullScale;
hdr->CHANNEL[0].PhysMin = w2->botFullScale;
#endif
@@ -446,6 +446,8 @@ void sopen_ibw_read (HDRTYPE* hdr) {
for (n = 0; n < hdr->EVENT.N; n++) {
hdr->EVENT.TYP[n] = 0x7ffe;
hdr->EVENT.POS[n] =
(n+1)*w5->nDim[0];
+ hdr->EVENT.DUR[n] = 0;
+ hdr->EVENT.CHN[n] = 0;
}
}
@@ -458,7 +460,10 @@ void sopen_ibw_read (HDRTYPE* hdr) {
hdr->CHANNEL[0].PhysDimCode =
PhysDimCode(w5->dataUnits);
hdr->CHANNEL[0].SPR = hdr->SPR = 1;
hdr->NRec= w5->npnts;
- hdr->SampleRate /= w5->sfA[0];
+ hdr->SampleRate /= w5->sfA[0] *
PhysDimScale(PhysDimCode(w5->dimUnits[0]));
+
+ if (VERBOSE_LEVEL>7) fprintf(stdout,"%s (line
%i): %g.x+%g \n",__FILE__,__LINE__,w5->sfA[0],w5->sfB[0]);
+ if (VERBOSE_LEVEL>7) fprintf(stdout,"%s (line
%i):
|%s|%s|%s|%s|\n",__FILE__,__LINE__,w5->dimUnits[0],w5->dimUnits[1],w5->dimUnits[2],w5->dimUnits[3]);
#ifdef IGOROLD
hdr->CHANNEL[0].Cal = 1.0;
@@ -916,6 +921,8 @@ void sopen_itx_read (HDRTYPE* hdr) {
hdr->EVENT.SampleRate = hdr->SampleRate;
hdr->EVENT.POS = (uint32_t*) realloc(hdr->EVENT.POS,
hdr->EVENT.N * sizeof(*hdr->EVENT.POS));
hdr->EVENT.TYP = (uint16_t*) realloc(hdr->EVENT.TYP,
hdr->EVENT.N * sizeof(*hdr->EVENT.TYP));
+ hdr->EVENT.CHN = (uint16_t*) realloc(hdr->EVENT.TYP,
hdr->EVENT.N * sizeof(*hdr->EVENT.TYP));
+ hdr->EVENT.DUR = (uint32_t*) realloc(hdr->EVENT.POS,
hdr->EVENT.N * sizeof(*hdr->EVENT.POS));
#if (BIOSIG_VERSION >= 10500)
hdr->EVENT.TimeStamp = (gdf_time*)realloc(hdr->EVENT.TimeStamp,
hdr->EVENT.N*sizeof(gdf_time));
#endif
@@ -979,6 +986,8 @@ void sopen_itx_read (HDRTYPE* hdr) {
if (sweepNo > 0 && chanNo==0) {
hdr->EVENT.POS[sweepNo-1] = SPR;
hdr->EVENT.TYP[sweepNo-1] = 0x7ffe;
+ hdr->EVENT.DUR[sweepNo-1] = 0;
+
Bug#1007832: seg-fault in mesa-vulkan-driver when connected to a remote headless machine.
Further investigation shows that part of the issue is package "mesa-vulkan-drivers" and also on machines without nvidia-gpus. When uninstalling nvidia-drivers, and mesa-vulkan-drivers, vulkan-tools reports correctly an error that no vulkan device is found When installing mesa-vulkan-driver, and having the nvidia-driver in place, "gdb vulkaninfo" results in this backtrace Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". ERROR: [Loader Message] Code 0 : loader_scanned_icd_add: Could not get 'vkCreateInstance' via 'vk_icdGetInstanceProcAddr' for ICD libGLX_nvidia.so.0 ERROR: [Loader Message] Code 0 : /usr/lib/i386-linux-gnu/libvulkan_intel.so: wrong ELF class: ELFCLASS32 ERROR: [Loader Message] Code 0 : /usr/lib/i386-linux-gnu/libvulkan_radeon.so: wrong ELF class: ELFCLASS32 ERROR: [Loader Message] Code 0 : /usr/lib/i386-linux-gnu/libvulkan_lvp.so: wrong ELF class: ELFCLASS32 Program received signal SIGSEGV, Segmentation fault. 0x15554aa4d3fc in ?? () from /usr/lib/x86_64-linux-gnu/libvulkan_intel.so (gdb) bt #0 0x15554aa4d3fc in ?? () from /usr/lib/x86_64-linux-gnu/libvulkan_intel.so #1 0x15554aa4ea65 in ?? () from /usr/lib/x86_64-linux-gnu/libvulkan_intel.so #2 0x14bef7e7 in ?? () from /usr/lib/x86_64-linux-gnu/libvulkan.so.1 #3 0x14befc22 in ?? () from /usr/lib/x86_64-linux-gnu/libvulkan.so.1 #4 0x15554a96fde4 in ?? () from /usr/lib/x86_64-linux-gnu/libVkLayer_MESA_device_select.so #5 0x14bef2a3 in ?? () from /usr/lib/x86_64-linux-gnu/libvulkan.so.1 #6 0x14bf1e05 in vkEnumeratePhysicalDevices () from /usr/lib/x86_64-linux-gnu/libvulkan.so.1 #7 0x555b5639 in ?? () #8 0x555638b6 in ?? () #9 0x14fead0a in __libc_start_main (main=0x55563670, argc=1, argv=0x7fffe458, init=, fini=, rtld_fini=, stack_end=0x7fffe448) at ../csu/libc-start.c:308 #10 0x5556580a in ?? () When having mesa-vulkan-drivers installed, and nvidia drivers are disabled (e.g. with "rmmod nvidia-drm nvidia-settings"), or on machines without nvidia-gpu's, vulkan-tools shows a lot of properties, but fails also with a segmentation fault. Running "gdb vulkaninfo", I get this backtrace: Thread 1 "vulkaninfo" received signal SIGSEGV, Segmentation fault. 0x7fffcd2f52bc in ?? () from /usr/lib/x86_64-linux-gnu/libvulkan_lvp.so (gdb) bt #0 0x7fffcd2f52bc in ?? () from /usr/lib/x86_64-linux-gnu/libvulkan_lvp.so #1 0x7fffcd2f57f1 in ?? () from /usr/lib/x86_64-linux-gnu/libvulkan_lvp.so #2 0x555a7140 in ?? () #3 0x555a123e in ?? () #4 0x55564565 in ?? () #5 0x7fffd6fa2d0a in __libc_start_main (main=0x55563670, argc=1, argv=0x7fffda98, init=, fini=, rtld_fini=, stack_end=0x7fffda88) at ../csu/libc-start.c:308 #6 0x5556580a in ?? () Though the behavior is slightly different, both libraries libvulkan_intel.so and libvulkan_lvp.so, are part of the mesa-vulkan-drivers package. So this indicates that this is a bug in package mesa-vulkan-drivers.
Bug#1007832: Acknowledgement (vulkan-tools: vulkaninfo,vkcube seg-faults on head-less cuda/gpu machine)
When checking for possible causes, I noticed that the framebuffer is now (in Debian11) associated with the first gpu. This seems wrong as this is a headless machine, and the nvidia-gpu's are used only as a computational accelerator for cuda workloads, and not for visualization. This is shown with the command lshw -C display which has this entry logical name: /dev/fb0 The full log is attached. When running Debian10, this entry is not shown, and vulkaninfo was working. Is there an (easy?) way to disable /dev/fb0 ? *-display description: VGA compatible controller product: GP102 [GeForce GTX 1080 Ti] vendor: NVIDIA Corporation physical id: 0 bus info: pci@:05:00.0 logical name: /dev/fb0 version: a1 width: 64 bits clock: 33MHz capabilities: pm msi pciexpress vga_controller bus_master cap_list rom fb configuration: depth=32 driver=nvidia latency=0 mode=1024x768 visual=truecolor xres=1024 yres=768 resources: iomemory:27f0-27ef iomemory:27f0-27ef irq:27 memory:c400-c4ff memory:27fe000-27fefff memory:27ff000-27ff1ff ioport:b000(size=128) memory:c500-c507 *-display description: VGA compatible controller product: GP102 [GeForce GTX 1080 Ti] vendor: NVIDIA Corporation physical id: 0 bus info: pci@:06:00.0 version: a1 width: 64 bits clock: 33MHz capabilities: pm msi pciexpress vga_controller bus_master cap_list rom configuration: driver=nvidia latency=0 resources: iomemory:27f0-27ef iomemory:27f0-27ef irq:27 memory:c200-c2ff memory:27fc000-27fcfff memory:27fd000-27fd1ff ioport:a000(size=128) memory:c300-c307 *-display description: VGA compatible controller product: GP102 [GeForce GTX 1080 Ti] vendor: NVIDIA Corporation physical id: 0 bus info: pci@:07:00.0 version: a1 width: 64 bits clock: 33MHz capabilities: pm msi pciexpress vga_controller bus_master cap_list rom configuration: driver=nvidia latency=0 resources: iomemory:27f0-27ef iomemory:27f0-27ef irq:27 memory:c000-c0ff memory:27fa000-27fafff memory:27fb000-27fb1ff ioport:9000(size=128) memory:c100-c107 *-display description: VGA compatible controller product: GP102 [GeForce GTX 1080 Ti] vendor: NVIDIA Corporation physical id: 0 bus info: pci@:08:00.0 version: a1 width: 64 bits clock: 33MHz capabilities: pm msi pciexpress vga_controller bus_master cap_list rom configuration: driver=nvidia latency=0 resources: iomemory:27f0-27ef iomemory:27f0-27ef irq:27 memory:be00-beff memory:27f8000-27f8fff memory:27f9000-27f91ff ioport:8000(size=128) memory:bf00-bf07 *-display description: VGA compatible controller product: GP102 [GeForce GTX 1080 Ti] vendor: NVIDIA Corporation physical id: 0 bus info: pci@:0b:00.0 version: a1 width: 64 bits clock: 33MHz capabilities: pm msi pciexpress vga_controller bus_master cap_list rom configuration: driver=nvidia latency=0 resources: iomemory:27f0-27ef iomemory:27f0-27ef irq:29 memory:bc00-bcff memory:27f6000-27f6fff memory:27f7000-27f71ff ioport:7000(size=128) memory:bd00-bd07 *-display description: VGA compatible controller product: GP102 [GeForce GTX 1080 Ti] vendor: NVIDIA Corporation physical id: 0 bus info: pci@:0c:00.0 version: a1 width: 64 bits clock: 33MHz capabilities: pm msi pciexpress vga_controller bus_master cap_list rom configuration: driver=nvidia latency=0 resources: iomemory:27f0-27ef iomemory:27f0-27ef irq:29 memory:ba00-baff memory:27f4000-27f4fff memory:27f5000-27f51ff ioport:6000(size=128) memory:bb00-bb07 *-display description: VGA compatible controller product: GP102 [GeForce GTX 1080 Ti] vendor: NVIDIA Corporation physical id: 0 bus info: pci@:0d:00.0 version: a1 width: 64 bits clock: 33MHz capabilities: pm msi pciexpress vga_controller bus_master cap_list rom configuration: driver=nvidia latency=0 resources: iomemory:27f0-27ef iomemory:27f0-27ef irq:29 memory:b800-b8ff memory:27f2000-27f2fff memory:27f3000-27f31ff ioport:5000(size=128) memory:b900-b907 *-display description: VGA compatible controller product: GP102 [GeForce GTX 1080 Ti] vendor: NVIDIA Corporation physical id: 0 bus info: pci@:0e:00.0 version: a1 width: 64 bits clock: 33MHz capabilities: pm msi pciexpress vga_controller bus_master cap_list rom configuration:
Bug#1007832: vulkan-tools: vulkaninfo,vkcube seg-faults on head-less cuda/gpu machine
Package: vulkan-tools Version: 1.2.162.0+dfsg1-1 Severity: normal X-Debbugs-Cc: alois.schlo...@ist.ac.at Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? Trying to run wine-staging on a GPU/cuda compute node failed because vulkan was not correctly configured. see also https://bugs.winehq.org/show_bug.cgi?id=52647 In the course of investigation, I noticed that vulkaninfo did always seg-fault on headless cuda/GPU machines under Debian11. * What exactly did you do (or not do) that was effective (or ineffective)? I've tried to install and uninstall various graphics/vulkan driver. Testing a machine without GPU's did not show this issue. Here is the output when running the debugger on vulkaninfo $ gdb vulkaninfo For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from vulkaninfo... (No debugging symbols found in vulkaninfo) (gdb) r Starting program: /usr/bin/vulkaninfo [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Program received signal SIGSEGV, Segmentation fault. 0x15554ceb23fc in ?? () from /usr/lib/x86_64-linux-gnu/libvulkan_intel.so (gdb) Quit quit) The output of these commands is attached $ vulkaninfo $ vkcube $ vkcubepp $ lspci|grep VGA $ nvidia-smi $ ls -altr /usr/share/vulkan/icd.d/ $ cat /usr/share/vulkan/icd.d/* $ dpkg -l|grep "icd\|xorg\|nvid\|cuda\|mesa\|vulkan" $ glxinfo * What was the outcome of this action? vulkaninfo, vkcube always ended up in a seg-fault when running on Cuda/GPU machines. Doing this on machines without Nvidia GPU's does not show this issue. * What outcome did you expect instead? I understand that Cuda is proprietary technology and therefore this platform is difficult to support. I'd expect that vulkaninfo does not seg-fault, and finishes gracefully with a more or less meaning full error message. Ideally, I should indicate what is needed to fix this issue. Afterall, it should be possible to run vulkaninfo on a headless GPU/cuda machine, that should enable also runing wine-staging on that machine. *** End of the template - remove these template lines *** -- System Information: Debian Release: 11.2 APT prefers stable APT policy: (990, 'stable'), (500, 'stable-security') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-12-amd64 (SMP w/24 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages vulkan-tools depends on: ii libc6 2.31-13+deb11u2 ii libgcc-s1 10.2.1-6 ii libstdc++6 10.2.1-6 ii libvulkan1 1.2.162.0-1 ii libwayland-client0 1.18.0-2~exp1.1 ii libx11-6 2:1.7.2-1 ii libxcb1 1.14-3 vulkan-tools recommends no packages. vulkan-tools suggests no packages. -- no debconf information
Bug#948020: fix from upstream available
This patch in the upstream repository https://github.com/neurodroid/stimfit/commit/efd90830aa930498e5861f98839228bcf7086237 fixes this bug. The patch is also attached. Alois commit efd90830aa930498e5861f98839228bcf7086237 Author: Alois SCHLOEGL Date: Mon Jan 18 12:12:52 2021 +0100 dependency on python3-dev instead of python3-all-dev (closes #972423 #948020) diff --git a/dist/debian/changelog b/dist/debian/changelog index 4b8ea1e4..2524f4fb 100644 --- a/dist/debian/changelog +++ b/dist/debian/changelog @@ -4,6 +4,7 @@ stimfit (0.16.0-2) unstable; urgency=low this ensures that the latest features and data formats of libbiosig (v2.1.2 and later) are supported by Stimfit, too. * remove dependency on libboost since -std=c++17 (default in gcc-8) is used + * dependency on python3-dev instead of python3-all-dev (closes #972423 #948020) -- Alois Schlögl Sun, 17 Jan 2021 17:05:41 +0100 diff --git a/dist/debian/control b/dist/debian/control index bb94c817..b3c48306 100644 --- a/dist/debian/control +++ b/dist/debian/control @@ -3,7 +3,7 @@ Section: science Priority: optional Maintainer: Christoph Schmidt-Hieber Uploaders: Yaroslav Halchenko -Build-Depends: debhelper (>= 9), dh-python, python3-all-dev, python3-numpy, libhdf5-dev, swig, python3-sip-dev, python3-wxgtk4.0 (>= 4.0.7), libwxgtk3.0-gtk3-dev, libfftw3-dev, liblapack-dev, chrpath, help2man, libbiosig-dev, zlib1g-dev, dh-autoreconf, pkg-config +Build-Depends: debhelper (>= 9), dh-python, python3-dev, python3-numpy, libhdf5-dev, swig, python3-sip-dev, python3-wxgtk4.0 (>= 4.0.7), libwxgtk3.0-gtk3-dev, libfftw3-dev, liblapack-dev, chrpath, help2man, libbiosig-dev, zlib1g-dev, dh-autoreconf, pkg-config Standards-Version: 4.4.1 Homepage: http://www.stimfit.org
Bug#924913: trackpad on L480 unusable after upgrade to testing
Am 5/31/21 um 8:19 AM schrieb Alois Schlögl: Am 5/29/21 um 1:59 PM schrieb Salvatore Bonaccorso: Control: tags -1 + moreinfo Hi Alois, On Fri, May 31, 2019 at 09:24:03PM +0200, Romain Perier wrote: On Wed, May 29, 2019 at 05:54:22PM +0200, Alois Schlögl wrote: On 3/26/19 9:03 PM, Romain Perier wrote: On Wed, Mar 20, 2019 at 08:24:33AM +0100, Alois Schlögl wrote: On 3/18/19 7:46 PM, Romain Perier wrote: On Mon, Mar 18, 2019 at 12:43:10PM +0100, Alois Schlögl wrote: On 3/18/19 12:20 PM, Romain Perier wrote: Hello, On Mon, Mar 18, 2019 at 11:27:41AM +0100, Alois Schlögl wrote: Source: linux Severity: normal Dear Maintainer, On a Lenovo L480 laptop, I've upgraded Debian from 9 (stretch) to 10 (testing). After the upgrade, the touchpad and the trackpoint was not usable anymore. This already has some bug report here, https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1803600 As a workaround, one can run the command, sudo sh -c 'echo -n "elantech"> /sys/bus/serio/devices/serio1/protocol' in order to use the touchpad. However, on a GUI Interface and without an external mouse, it's impossible to apply this workaround (switching to the terminal -F1, login, and run the command above might work) I expect to be able to use the touchpad just out of the box, not needing to run the above workaround Could you : - Test with the last kernel uploaded to unstable (4.19.0-4:4.19.28) and confirm or not is the problem still exists ? Dear Romain I upgraded the kernel and rebooted: schloegl@debian10:~$ uname -a Linux debian10 4.19.0-4-amd64 #1 SMP Debian 4.19.28-2 (2019-03-15) x86_64 GNU/Linux With this kernel the trackpoint is working, the trackpad is still not usable. (This improves the situation because now at least one pointer device is available). Good, we did some progress :) - According to the bug on launchpad and to the fix pushed upstream, the fix seems to be an hardware quirks, could you give me the output of the following command : $ /sys/bus/serio/devices/serio1/firmware_id root@debian10:~# cat /sys/bus/serio/devices/serio1/firmware_id PNP: LEN2036 PNP0f13 Could you test the patch attached to this reply ? (if you don't know how to do this, I can provide support) Regards, Romain I tried to followed these instructions: https://kernel-team.pages.debian.net/kernel-handbook/ch-comm 4.5. Building a custom kernel from Debian kernel source Specifically using the patched the sources, *scripts/config --disable MODULE_SIG* **scripts/config --disable DEBUG_INFO** ||*|make clean|* ||*|make deb-pkg |* and ended up with a kernel that does not boot (missing HD audio firmware), Which procedure do you recommend to build and install a modified kernel ? Hi, Section 4.2 from https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html#s-common-official , until test-patches should work. For the test-patches script, use the flavour and a featureset as argument, when you invoke it, like this : # debian/bin/test-patches -f amd64 -s none /path/to/0001-Input-elantech-disable-elan-i2c-for-L480.patch This will apply the patch on the fly, configure the kernel for amd64 and build a version with a special changelog entry and a special suffix version dedicated to the test version you generate. In case of troubles, I can provide another way, from git with few commands. Hope this helps, Regards, Romain Dear Romain, your instructions to build the kernel worked fine, when trying to install the kernel, sudo dpkg -i linux-headers-4.19.0-5-amd64_4.19.37-3a~test_amd64.deb linux-image-4.19.0-5-amd64-unsigned_4.19.37-3a~test_amd64.deb I run into problem, getting this warning. │ You are running a kernel (version 4.19.0-5-amd64) and attempting to remove the same version. │ │ │ │ This can make the system unbootable as it will remove /boot/vmlinuz-4.19.0-5-amd64 and all modules under the directory /lib/modules/4.19.0-5-amd64. This can only be fixed with a copy │ │ of the kernel image and the corresponding modules. │ │ │ │ It is highly recommended to abort the kernel removal unless you are prepared to fix the system after removal. │ │ │ │ Abort kernel removal? I'm not sure if I'm "prepared to fix the system". Can you recommend a reasonable save way to go forward ? Cheers, Alois Hello, Well, this is something I have tested here myself, from the linux git repository (on salsa.debian.org). I have built a 4.19.37-4a~test with the patch , then I have forced the install with the same question than you. And he did the trick ! So what you can do is: - When the dialog interface (the blue one) asks you to abort or continue the install, press "no" to don't abort and continue the install - Once done, you can reboot - Check that the boot is working fine and you're running the intended kernel: 4.19.37-3a~test (via un
Bug#924913: trackpad on L480 unusable after upgrade to testing
Am 5/29/21 um 1:59 PM schrieb Salvatore Bonaccorso: Control: tags -1 + moreinfo Hi Alois, On Fri, May 31, 2019 at 09:24:03PM +0200, Romain Perier wrote: On Wed, May 29, 2019 at 05:54:22PM +0200, Alois Schlögl wrote: On 3/26/19 9:03 PM, Romain Perier wrote: On Wed, Mar 20, 2019 at 08:24:33AM +0100, Alois Schlögl wrote: On 3/18/19 7:46 PM, Romain Perier wrote: On Mon, Mar 18, 2019 at 12:43:10PM +0100, Alois Schlögl wrote: On 3/18/19 12:20 PM, Romain Perier wrote: Hello, On Mon, Mar 18, 2019 at 11:27:41AM +0100, Alois Schlögl wrote: Source: linux Severity: normal Dear Maintainer, On a Lenovo L480 laptop, I've upgraded Debian from 9 (stretch) to 10 (testing). After the upgrade, the touchpad and the trackpoint was not usable anymore. This already has some bug report here, https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1803600 As a workaround, one can run the command, sudo sh -c 'echo -n "elantech"> /sys/bus/serio/devices/serio1/protocol' in order to use the touchpad. However, on a GUI Interface and without an external mouse, it's impossible to apply this workaround (switching to the terminal -F1, login, and run the command above might work) I expect to be able to use the touchpad just out of the box, not needing to run the above workaround Could you : - Test with the last kernel uploaded to unstable (4.19.0-4:4.19.28) and confirm or not is the problem still exists ? Dear Romain I upgraded the kernel and rebooted: schloegl@debian10:~$ uname -a Linux debian10 4.19.0-4-amd64 #1 SMP Debian 4.19.28-2 (2019-03-15) x86_64 GNU/Linux With this kernel the trackpoint is working, the trackpad is still not usable. (This improves the situation because now at least one pointer device is available). Good, we did some progress :) - According to the bug on launchpad and to the fix pushed upstream, the fix seems to be an hardware quirks, could you give me the output of the following command : $ /sys/bus/serio/devices/serio1/firmware_id root@debian10:~# cat /sys/bus/serio/devices/serio1/firmware_id PNP: LEN2036 PNP0f13 Could you test the patch attached to this reply ? (if you don't know how to do this, I can provide support) Regards, Romain I tried to followed these instructions: https://kernel-team.pages.debian.net/kernel-handbook/ch-comm 4.5. Building a custom kernel from Debian kernel source Specifically using the patched the sources, *scripts/config --disable MODULE_SIG* **scripts/config --disable DEBUG_INFO** ||*|make clean|* ||*|make deb-pkg |* and ended up with a kernel that does not boot (missing HD audio firmware), Which procedure do you recommend to build and install a modified kernel ? Hi, Section 4.2 from https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html#s-common-official , until test-patches should work. For the test-patches script, use the flavour and a featureset as argument, when you invoke it, like this : # debian/bin/test-patches -f amd64 -s none /path/to/0001-Input-elantech-disable-elan-i2c-for-L480.patch This will apply the patch on the fly, configure the kernel for amd64 and build a version with a special changelog entry and a special suffix version dedicated to the test version you generate. In case of troubles, I can provide another way, from git with few commands. Hope this helps, Regards, Romain Dear Romain, your instructions to build the kernel worked fine, when trying to install the kernel, sudo dpkg -i linux-headers-4.19.0-5-amd64_4.19.37-3a~test_amd64.deb linux-image-4.19.0-5-amd64-unsigned_4.19.37-3a~test_amd64.deb I run into problem, getting this warning. │ You are running a kernel (version 4.19.0-5-amd64) and attempting to remove the same version. │ │ │ │ This can make the system unbootable as it will remove /boot/vmlinuz-4.19.0-5-amd64 and all modules under the directory /lib/modules/4.19.0-5-amd64. This can only be fixed with a copy │ │ of the kernel image and the corresponding modules. │ │ │ │ It is highly recommended to abort the kernel removal unless you are prepared to fix the system after removal. │ │ │ │ Abort kernel removal? I'm not sure if I'm "prepared to fix the system". Can you recommend a reasonable save way to go forward ? Cheers, Alois Hello, Well, this is something I have tested here myself, from the linux git repository (on salsa.debian.org). I have built a 4.19.37-4a~test with the patch , then I have forced the install with the same question than you. And he did the trick ! So what you can do is: - When the dialog interface (the blue one) asks you to abort or continue the install, press "no" to don't abort and continue the install - Once done, you can reboot - Check that the boot is working fine and you're running the intended kernel: 4.19.37-3a~test (via uname -a) - Check if your problem is fixed - Once you want to re-use the debian
Bug#987044: libbiosig3: certain files can crash save2gdf and produce invalid json output
Package: libbiosig3
Version: 2.1.2-3
Severity: important
Tags: patch
Dear Maintainer,
as suggested by you [1], I'm filing this bug report.
* What led up to the situation?
Trying to handle this files
https://www.physionet.org/files/sleep-edfx/1.0.0/sleep-cassette/SC4001EC-Hypnogram.edf?download
with Biosig-tools causes these two issues :
1) save2gdf -JSON SC4001EC-Hypnogram.edf
fails to produce valid JSON, because it contains the field
SampleRate : inf
You can check with
save2gdf -JSON SC4001EC-Hypnogram.edf | json_pp
or python
import biosig, json
HDR = json.loads(biosig.header('SC4001EC-Hypnogram.edf'))
2) Converting the edf into a gdf file crashes. You can test with:
save2gdf SC4001EC-Hypnogram.edf SC4001EC-Hypnogram.edf.gdf
and does not produce the expected output.
* What exactly did you do (or not do) that was effective (or
ineffective)?
The patch as suggested [1] solves both issues, and a similar issue for
other file formats (ACQ, BKR, and HEKA).
The issue was most likely introduced in Jan 2018, when the initial read
page size was increased from 512 to 4096 bytes.
It most likely affects also libbiosig2 (v1.9.3) in buster.
Moreover, it might also affect the package Stimfit, which uses an
outdated copy of libbbiosig.
The best solution would be to rebuild stimfit with
./configure --with-biosig ...
or
./configure --with-biosig2 ...
with a build-dependency on libbiosig-dev, and a runtime dependency on
libbiosig2 | libbiosig3
The patches are already in upstream (see Jan 2021 in [2]);
The package sigviewer is also affected but updating libbiosig is
sufficient there because it is dynamically linked, and the API did not
change.
[1]
https://alioth-lists.debian.net/pipermail/debian-med-packaging/2021-April/091120.html
[2] https://github.com/neurodroid/stimfit/commits/master
Cheers,
Alois
Bug#983255: firmware-realtek: Direct firmware load for rtw88/rtw8821c_fw.bin failed with error -2
Package: firmware-realtek Version: 20210208-1 Severity: normal Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? security update, on linux backports kernel (upgrade from 5.9 to 5.10) * What exactly did you do (or not do) that was effective (or ineffective)? apt update && apt upgrade && reboot * What was the outcome of this action? wlan adapter was not available after reboot dmesg has these lines: lspci | grep -i wire 02:00.0 Network controller: Realtek Semiconductor Co., Ltd. RTL8821CE 802.11ac PCIe Wireless Network Adapter dmesg contains these lines: [4.938468] rtw_8821ce :02:00.0: Direct firmware load for rtw88/rtw8821c_fw.bin failed with error -2 [4.938472] rtw_8821ce :02:00.0: failed to request firmware [4.938543] rtw_8821ce :02:00.0: failed to load firmware [4.938571] rtw_8821ce :02:00.0: failed to setup chip efuse info [4.938599] rtw_8821ce :02:00.0: failed to setup chip information [4.939514] rtw_8821ce: probe of :02:00.0 failed with error -22 tried to install also latest firmware-realtek from unstable ii firmware-realtek20210208-1 all Binary firmware for Realtek wired/wifi/BT adapters but this did also not change anything. * What outcome did you expect instead? wlan working as before. *** End of the template - remove these template lines *** -- System Information: Debian Release: 10.8 APT prefers stable APT policy: (990, 'stable'), (500, 'stable-updates') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-0.bpo.3-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_WARN Locale: LANG=de_AT.UTF-8, LC_CTYPE=de_AT.UTF-8 (charmap=UTF-8), LANGUAGE=de_AT:de (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled firmware-realtek depends on no packages. firmware-realtek recommends no packages. Versions of packages firmware-realtek suggests: ii initramfs-tools 0.133+deb10u1 -- no debconf information
Bug#964688: cherry-pick patch from upstream - fixes #964688
Adrian is right. I want to make you aware of another patch set (see
attachment) which I recommend to add.
The patch is fixing an issue when importing an event file, and the
sample rate in the event file does not match the data file.
The patch set is currently maintained here
https://git.ist.ac.at/alois.schloegl/sigviewer
and corresponds to the last three patches (currently this 'git diff
7e26e4da 7303ba9d0' )
The changes have been sent to the maintainer (Clemens Brunner), but
there is no release yet.
I can contact the maintainer, or submit another bug report. The easiest
approach would be if you could just add the patch here.
Alois
On 11/14/20 11:08 PM, Adrian Bunk wrote:
On Sat, Nov 14, 2020 at 09:28:53PM +0100, Andreas Tille wrote:
Control: tags -1 pending
Control: tags 922571 pending
Hi,
I have moved sigviewer to Debian Med team[1], fixed the other bug and
tried to build the new upstream version 0.6.4 but failed:
...
g++ -c -pipe -g -O2 -fdebug-prefix-map=/build/sigviewer-0.6.4=.
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time
-D_FORTIFY_SOURCE=2 -std=gnu++11 -D_REENTRANT -Wall - Wextra -fPIC
-DVERSION_MAJOR=0 -DVERSION_MINOR=6 -DVERSION_BUILD=4 -DQT_NO_DEBUG_OUTPUT
-DQT_NO_DEBUG -DQT_WIDGETS_LIB -DQT_GUI_LIB -DQT_XML_LIB -DQT_CORE_LIB -I.
-I/build/sigviewer-0.6.4/ external/include -Isrc
-I/usr/include/x86_64-linux-gnu/qt5
-I/usr/include/x86_64-linux-gnu/qt5/QtWidgets
-I/usr/include/x86_64-linux-gnu/qt5/QtGui -I/usr/include/x86_64-linux-gnu/qt5/
QtXml -I/usr/include/x86_64-linux-gnu/qt5/QtCore -Itmp/release
-Itmp/release -I/usr/lib/x86_64-linux-gnu/qt5/mkspecs/linux-g++ -o
tmp/release/undo_redo_gui_command.o src/gui_impl/commands/
undo_redo_gui_command.cpp
src/gui_impl/commands/open_file_gui_command.cpp: In member function 'void
sigviewer::OpenFileGuiCommand::importEvents()':
src/gui_impl/commands/open_file_gui_command.cpp:200:23: error: redeclaration of
'sigviewer::FileSignalReader* file_signal_reader'
200 | FileSignalReader* file_signal_reader =
FileSignalReaderFactory::getInstance()->getHandler (file_path);
| ^~
src/gui_impl/commands/open_file_gui_command.cpp:185:23: note:
'sigviewer::FileSignalReader* file_signal_reader' previously declared here
185 | FileSignalReader* file_signal_reader =
FileSignalReaderFactory::getInstance()->getHandler (file_path);
| ^~
make[1]: *** [Makefile:2576: tmp/release/open_file_gui_command.o] Error 1
Any help would be welcome
This is from 0002-add-support-for-reading-GDF-formated-event-file.patch,
which seems to be upstream now - and adding the same code twice is what
failed.
Andreas.
cu
Adrian
diff --git a/src/file_handling_impl/biosig_reader.cpp b/src/file_handling_impl/biosig_reader.cpp
index 41fce69..42c12ae 100644
--- a/src/file_handling_impl/biosig_reader.cpp
+++ b/src/file_handling_impl/biosig_reader.cpp
@@ -121,10 +121,6 @@ QString BioSigReader::open (QString const& file_name)
QString BioSigReader::loadFixedHeader(const QString& file_name)
{
QMutexLocker locker (_access_lock_);
-char *c_file_name = new char[file_name.length() + 1];
-strcpy (c_file_name, file_name.toLocal8Bit ().data());
-c_file_name[file_name.length()] = '\0';
-
tzset();
if(biosig_header_==NULL)
@@ -134,7 +130,7 @@ QString BioSigReader::loadFixedHeader(const QString& file_name)
biosig_header_->FLAG.OVERFLOWDETECTION = 1;
}
-biosig_header_ = sopen(c_file_name, "r", biosig_header_ );
+biosig_header_ = sopen(file_name.toStdString().c_str(), "r", biosig_header_ );
basic_header_ = QSharedPointer
(new BiosigBasicHeader (biosig_header_, file_name));
@@ -145,8 +141,6 @@ QString BioSigReader::loadFixedHeader(const QString& file_name)
destructHDR(biosig_header_);
biosig_header_ = NULL;
-delete[] c_file_name;
-
qDebug() << "File doesn't exist.";
QMessageBox msgBox;
msgBox.setIcon(QMessageBox::Warning);
@@ -167,17 +161,11 @@ QString BioSigReader::loadFixedHeader(const QString& file_name)
destructHDR(biosig_header_);
biosig_header_ = NULL;
-delete[] c_file_name;
-
return "file not supported";
}
convert2to4_eventtable(biosig_header_);
-delete[] c_file_name;
-
-c_file_name = NULL;
-
basic_header_->setNumberEvents(biosig_header_->EVENT.N);
if (biosig_header_->EVENT.SampleRate)
diff --git a/src/gui_impl/commands/open_file_gui_command.cpp b/src/gui_impl/commands/open_file_gui_command.cpp
index 094e1d9..d7ed693 100644
--- a/src/gui_impl/commands/open_file_gui_command.cpp
+++ b/src/gui_impl/commands/open_file_gui_command.cpp
@@ -2,7 +2,7 @@
// Licensed under the GNU General Public License (GPL)
// https://www.gnu.org/licenses/gpl
-
+#include
#include "open_file_gui_command.h"
#include
Bug#973435: biosig build-depends on python3-all-dev, but only builds for the default python3 version
Thanks for the hint on py3versions, this helped solving the issue for v2.1.0. I believe bug #972684, #973435 are fixed now. Debian packages of biosig 2.1.0-1 are now availab https://pub.ist.ac.at/~schloegl/biosig/debian/unstable/?C=M;O=D On 11/10/20 11:28 AM, Andreas Tille wrote: Hi again, On Tue, Nov 10, 2020 at 10:10:21AM +0100, Alois Schlögl wrote: Ok, I see. Biosig can be build with any python version (it is just using the general API for module extension which is not) That means, building it for any python version will work like this (cd biosig4c++/python && python3 setup.py sdist ) (cd biosig4c++/python && python2.7 setup.py install ) This is not needed since python2.7 will be removed. (cd biosig4c++/python && python3.8 setup.py install ) (cd biosig4c++/python && python3.9 setup.py install ) This would be for py in $(py3versions -s) ; do (cd biosig4c++/python && $py setup.py install ) The question is: when packaging this in debian, how to tell which python versions are available, and how to trigger the build for that version ? See above. Will there be a python3.8-biosig and python3.9-biosig package, and how does this affect debian/control ? It does not affect debian/control but debian/rules. OK, if you want the *easy* solutition just use s/python3-all-dev/python3-dev/ in d/control, which solves the issue since only the default python3 will be used (py3versions -d). This is the *quick* fix for the bug. It simply depends what you *want* from your users. I hope Michael or Yaroslav could comment on this. I'm out at this point since I'm not a user of this package. I've reverted the change, and partially fixed the build. Some issues remain unsolved - as described before. Hope this helps. Other hints might be given by debian-pyt...@lists.debian.org. Kind regards Andreas.
Bug#964688: cherry-pick patch from upstream - fixes #964688
attached is a patch that fixes bug #964688 (FTBFS).
The patch corresponds to commit 93d5cec298ec6c787e45f7b3486cf47ff3461c75
in upstream.
Upgrading to sigviewer 0.6.4 would also solve this issue.
Best,
Alois
commit 93d5cec298ec6c787e45f7b3486cf47ff3461c75
Author: Alois Schloegl
Date: Wed Oct 24 00:06:10 2018 +0200
fix compilation on Debian 9 with Qt v5.7.1
diff --git a/src/file_handling/file_signal_reader.h b/src/file_handling/file_signal_reader.h
index eeac188..39d3207 100644
--- a/src/file_handling/file_signal_reader.h
+++ b/src/file_handling/file_signal_reader.h
@@ -10,6 +10,7 @@
#include "base/data_block.h"
#include "application_context_impl.h"
+#include
#include
#include
#include
diff --git a/src/gui/gui_action_factory.h b/src/gui/gui_action_factory.h
index 07586e4..dc99c0d 100644
--- a/src/gui/gui_action_factory.h
+++ b/src/gui/gui_action_factory.h
@@ -12,6 +12,7 @@
#include
#include
#include
+#include
namespace sigviewer
{
diff --git a/src/gui_impl/signal_browser/signal_graphics_item.cpp b/src/gui_impl/signal_browser/signal_graphics_item.cpp
index cc60066..0572ed1 100644
--- a/src/gui_impl/signal_browser/signal_graphics_item.cpp
+++ b/src/gui_impl/signal_browser/signal_graphics_item.cpp
@@ -457,8 +457,8 @@ void SignalGraphicsItem::mousePressEvent (QGraphicsSceneMouseEvent * event )
//check whether a user added stream has already been existing
XDFdata->userAddedStream = XDFdata->streams.size();
XDFdata->streams.emplace_back();
-std::time_t currentTime = std::time(nullptr);
-std::string timeString = std::asctime(std::localtime());
+time_t currentTime = time(nullptr);
+std::string timeString = asctime(localtime());
timeString.pop_back(); //we don't need '\n' at the end
XDFdata->streams.back().streamHeader =
""
Bug#936207: biosig4c++: Python2 removal in sid/bullseye
On Tue, 5 Nov 2019 12:27:42 -0800 Steve Langasek
wrote:
However, after applying that patch, the package fails to build because:
- it tries to invoke python, which is not present. Fixed by setting
PYTHON=python3 in MAKEOPTS from debian/rules.
- the python3 pkgconfig handling is completely messed up in
python/setup.py; it tries to find a pkgconfig file in the system
directory (why, when it's part of the same source package we're just
building right now?), and when it doesn't find it, under python3 it
raises a different exception than ValueError, so the fallback code
doesn't work. And if I set PKG_CONFIG_PATH to point at the libbiosig.pc
in the parent directory, it just fails later at linking time because ../
isn't on the linker path.
I'm stopping my investigation there, it really looks like this needs some
upstream cleanup.
-- Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
Dear Steve,
the attached patch should fix this problem.
Moreover, the dependency on python-pkgconfig (and pythen3-pkgconfig)
becomes obsolote.
Kind regards,
Alois
diff --git a/biosig4c++/python/setup.py b/biosig4c++/python/setup.py
index 556d306a..4e046e29 100644
--- a/biosig4c++/python/setup.py
+++ b/biosig4c++/python/setup.py
@@ -6,23 +6,12 @@ except ImportError:
from distutils.extension import Extension
import numpy.distutils.misc_util as mu
-try:
-import pkgconfig
-PKG=pkgconfig.parse('libbiosig')
-CPATH=PKG['include_dirs']
-LIBS=PKG['libraries']
-LIBDIR=PKG['library_dirs']
-except ValueError:
-print('cannot load pkgconfig(libbiosig) - use default location')
-CPATH='/usr/local/include'
-LIBS='-lbiosig'
-LIBDIR='/usr/local/lib'
module_biosig = Extension('biosig',
define_macros = [('MAJOR_VERSION', '1'), ('MINOR_VERSION', '9')],
-include_dirs = [CPATH, mu.get_numpy_include_dirs()[0]],
-libraries= LIBS,
-library_dirs = LIBDIR,
+include_dirs = ['./..', mu.get_numpy_include_dirs()[0]],
+libraries= ['biosig'],
+library_dirs = ['./..'],
sources = ['biosigmodule.c'])
setup (name = 'Biosig',
@@ -34,6 +23,6 @@ setup (name = 'Biosig',
url = 'https://biosig.sourceforge.io',
long_description = '''This is the biosig demo package.''',
keywords = 'EEG ECG EKG EMG EOG Polysomnography ECoG biomedical signals SCP EDF GDF HEKA CFS ABF',
- install_requires=['numpy','pkgconfig','setuptools'],
+ install_requires=['numpy','setuptools'],
ext_modules = [module_biosig])
Bug#941121: upgrade to debian 9.11 removes config entry
On 9/27/19 12:20 PM, Gennaro Oliva wrote:
> Hi Alois,
>
> On Wed, Sep 25, 2019 at 09:41:40AM +0200, Alois Schlögl wrote:
>> [remark: this might be a problem of systemd, I'm not sure whether this
>> is an issue of slurm or of systemd.]
>>
>> When upgrading from debian 9.10 to 9.11 [2], a configuration entry in
>> /etc/systemd/system/multi-user.target.wants/slurmd.service
>> got lost.
>>
>> In order to address an issue ("Cannot allocate memory" when running mpi
>> jobs under slurm, it is described in [1]) we had to add in
>> /etc/systemd/system/multi-user.target.wants/slurmd.service
> This file is a symbolic link to /lib/systemd/system/slurmd.service that
> is managed by the package.
>
>> this entry
>>
>> [Service]
>> ...
>> LimitMEMLOCK=1
> According to systemd documentation you need to add this entry to:
>
> /etc/systemd/system/slurmd.service
>
> or inside a file under:
>
> /etc/systemd/system/slurmd.service.d
>
> man systemd.unit(5) for details.
>
> Best regards,
Thank you very much for this hint. This solved the issue.
Best regards,
Alois
Bug#941121: upgrade to debian 9.11 removes config entry
Package: slurm-llnl
Version: 16.05.9-1
Severity: normal
[remark: this might be a problem of systemd, I'm not sure whether this
is an issue of slurm or of systemd.]
When upgrading from debian 9.10 to 9.11 [2], a configuration entry in
/etc/systemd/system/multi-user.target.wants/slurmd.service
got lost.
In order to address an issue ("Cannot allocate memory" when running mpi
jobs under slurm, it is described in [1]) we had to add in
/etc/systemd/system/multi-user.target.wants/slurmd.service
this entry
[Service]
...
LimitMEMLOCK=1
After upgrading to debian 9.11 [2] this entry configuration disappeared.
It took some time to identify the issue. The fix/workaround is to
manually add the entry in the configuration file again, and run
systemctl daemon-reload
systemctl restart slurmd
I'd have expected that the configuration is maintained when doing
apt update && apt upgrade
Below is the system information from a machine that is not upgraded yet,
and it happens also on machines with Debian 9.10.
Thanks for considering.
Alois
[1]
https://stackoverflow.com/questions/39512931/segfaults-when-running-openmpi-job-inside-slurm-runscript
[2] http://ftp.debian.org/debian/dists/stretch/ChangeLog
-- System Information:
Debian Release: 9.9
APT prefers oldstable
APT policy: (990, 'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.9.0-8-amd64 (SMP w/24 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 /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages slurm-llnl depends on:
ii slurm-wlm 16.05.9-1+deb9u2
slurm-llnl recommends no packages.
slurm-llnl suggests no packages.
-- no debconf information
Bug#924913: trackpad on L480 unusable after upgrade to testing
On 3/26/19 9:03 PM, Romain Perier wrote: > On Wed, Mar 20, 2019 at 08:24:33AM +0100, Alois Schlögl wrote: >> On 3/18/19 7:46 PM, Romain Perier wrote: >>> On Mon, Mar 18, 2019 at 12:43:10PM +0100, Alois Schlögl wrote: >>>> On 3/18/19 12:20 PM, Romain Perier wrote: >>>>> Hello, >>>>> >>>>> On Mon, Mar 18, 2019 at 11:27:41AM +0100, Alois Schlögl wrote: >>>>>> Source: linux >>>>>> Severity: normal >>>>>> >>>>>> Dear Maintainer, >>>>>> >>>>>> On a Lenovo L480 laptop, I've upgraded Debian from 9 (stretch) to 10 >>>>>> (testing). >>>>>> After the upgrade, the touchpad and the trackpoint was not usable >>>>>> anymore. >>>>>> >>>>>> >>>>>> This already has some bug report here, >>>>>> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1803600 >>>>>> >>>>>> As a workaround, one can run the command, >>>>>> sudo sh -c 'echo -n "elantech"> >>>>>> /sys/bus/serio/devices/serio1/protocol' >>>>>> in order to use the touchpad. However, on a GUI Interface and without >>>>>> an external mouse, it's impossible to apply this workaround >>>>>> (switching to the terminal -F1, login, and run the command >>>>>> above might work) >>>>>> >>>>>> I expect to be able to use the touchpad just out of the box, not >>>>>> needing >>>>>> to run the above workaround >>>>>> >>>>> Could you : >>>>> >>>>> - Test with the last kernel uploaded to unstable (4.19.0-4:4.19.28) and >>>>> confirm or >>>>> not is the problem still exists ? >>>> Dear Romain >>>> >>>> >>>> I upgraded the kernel and rebooted: >>>> >>>> schloegl@debian10:~$ uname -a >>>> Linux debian10 4.19.0-4-amd64 #1 SMP Debian 4.19.28-2 (2019-03-15) >>>> x86_64 GNU/Linux >>>> >>>> >>>> With this kernel the trackpoint is working, the trackpad is still not >>>> usable. >>>> >>>> (This improves the situation because now at least one pointer device is >>>> available). >>>> >>>> >>> Good, we did some progress :) >>> >>>>> - According to the bug on launchpad and to the fix pushed upstream, the >>>>> fix seems to be an hardware quirks, could you give me the output of the >>>>> following command : >>>>> $ /sys/bus/serio/devices/serio1/firmware_id >>>> root@debian10:~# cat /sys/bus/serio/devices/serio1/firmware_id >>>> PNP: LEN2036 PNP0f13 >>>> >>> Could you test the patch attached to this reply ? >>> (if you don't know how to do this, I can provide support) >>> >>> Regards, >>> Romain >> >> >> I tried to followed these instructions: >> >> https://kernel-team.pages.debian.net/kernel-handbook/ch-comm >> >> 4.5. Building a custom kernel from Debian kernel source >> >> Specifically using the patched the sources, >> >> *scripts/config --disable MODULE_SIG* >> **scripts/config --disable DEBUG_INFO** >> ||*|make clean|* ||*|make deb-pkg >> >> |* >> >> and ended up with a kernel that does not boot (missing HD audio firmware), >> >> >> Which procedure do you recommend to build and install a modified kernel ? >> >> > Hi, > > Section 4.2 from > https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html#s-common-official > , until test-patches should work. For the test-patches script, use the > flavour and a > featureset as argument, when you invoke it, like this : > > # debian/bin/test-patches -f amd64 -s none > /path/to/0001-Input-elantech-disable-elan-i2c-for-L480.patch > > This will apply the patch on the fly, configure the kernel for amd64 > and build a version with a special changelog entry and a special suffix > version dedicated to the test version you generate. > > > In case of troubles, I can provide another way, from git with few > commands. > > > Hope this helps, > Regards, > Romain Dear Romain, your instructions to build the kernel worked fine, when trying to install the kernel, sudo dpkg -i linux-headers-4.19.0-5-amd64_4.
Bug#924913: trackpad on L480 unusable after upgrade to testing
On 3/18/19 7:46 PM, Romain Perier wrote: > On Mon, Mar 18, 2019 at 12:43:10PM +0100, Alois Schlögl wrote: >> On 3/18/19 12:20 PM, Romain Perier wrote: >>> Hello, >>> >>> On Mon, Mar 18, 2019 at 11:27:41AM +0100, Alois Schlögl wrote: >>>> Source: linux >>>> Severity: normal >>>> >>>> Dear Maintainer, >>>> >>>> On a Lenovo L480 laptop, I've upgraded Debian from 9 (stretch) to 10 >>>> (testing). >>>> After the upgrade, the touchpad and the trackpoint was not usable >>>> anymore. >>>> >>>> >>>> This already has some bug report here, >>>> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1803600 >>>> >>>> As a workaround, one can run the command, >>>> sudo sh -c 'echo -n "elantech"> >>>> /sys/bus/serio/devices/serio1/protocol' >>>> in order to use the touchpad. However, on a GUI Interface and without >>>> an external mouse, it's impossible to apply this workaround >>>> (switching to the terminal -F1, login, and run the command >>>> above might work) >>>> >>>> I expect to be able to use the touchpad just out of the box, not needing >>>> to run the above workaround >>>> >>> Could you : >>> >>> - Test with the last kernel uploaded to unstable (4.19.0-4:4.19.28) and >>> confirm or >>> not is the problem still exists ? >> Dear Romain >> >> >> I upgraded the kernel and rebooted: >> >> schloegl@debian10:~$ uname -a >> Linux debian10 4.19.0-4-amd64 #1 SMP Debian 4.19.28-2 (2019-03-15) >> x86_64 GNU/Linux >> >> >> With this kernel the trackpoint is working, the trackpad is still not >> usable. >> >> (This improves the situation because now at least one pointer device is >> available). >> >> > Good, we did some progress :) > >>> - According to the bug on launchpad and to the fix pushed upstream, the >>> fix seems to be an hardware quirks, could you give me the output of the >>> following command : >>> $ /sys/bus/serio/devices/serio1/firmware_id >> root@debian10:~# cat /sys/bus/serio/devices/serio1/firmware_id >> PNP: LEN2036 PNP0f13 >> > Could you test the patch attached to this reply ? > (if you don't know how to do this, I can provide support) > > Regards, > Romain I tried to followed these instructions: https://kernel-team.pages.debian.net/kernel-handbook/ch-comm 4.5. Building a custom kernel from Debian kernel source Specifically using the patched the sources, *scripts/config --disable MODULE_SIG* **scripts/config --disable DEBUG_INFO** ||*|make clean|* ||*|make deb-pkg |* and ended up with a kernel that does not boot (missing HD audio firmware), Which procedure do you recommend to build and install a modified kernel ? Regards, Alois
Bug#924913: trackpad on L480 unusable after upgrade to testing
On 3/18/19 12:20 PM, Romain Perier wrote: > Hello, > > On Mon, Mar 18, 2019 at 11:27:41AM +0100, Alois Schlögl wrote: >> Source: linux >> Severity: normal >> >> Dear Maintainer, >> >> On a Lenovo L480 laptop, I've upgraded Debian from 9 (stretch) to 10 >> (testing). >> After the upgrade, the touchpad and the trackpoint was not usable >> anymore. >> >> >> This already has some bug report here, >> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1803600 >> >> As a workaround, one can run the command, >> sudo sh -c 'echo -n "elantech"> >> /sys/bus/serio/devices/serio1/protocol' >> in order to use the touchpad. However, on a GUI Interface and without >> an external mouse, it's impossible to apply this workaround >> (switching to the terminal -F1, login, and run the command >> above might work) >> >> I expect to be able to use the touchpad just out of the box, not needing >> to run the above workaround >> > Could you : > > - Test with the last kernel uploaded to unstable (4.19.0-4:4.19.28) and > confirm or > not is the problem still exists ? Dear Romainm I upgraded the kernel and rebooted: schloegl@debian10:~$ uname -a Linux debian10 4.19.0-4-amd64 #1 SMP Debian 4.19.28-2 (2019-03-15) x86_64 GNU/Linux With this kernel the trackpoint is working, the trackpad is still not usable. (This improves the situation because now at least one pointer device is available). > - According to the bug on launchpad and to the fix pushed upstream, the > fix seems to be an hardware quirks, could you give me the output of the > following command : > $ /sys/bus/serio/devices/serio1/firmware_id root@debian10:~# cat /sys/bus/serio/devices/serio1/firmware_id PNP: LEN2036 PNP0f13 > > Thanks, > Regards, > Romain Thank You, Alois >> -- System Information: >> Debian Release: buster/sid >> APT prefers testing >> APT policy: (990, 'testing'), (500, 'stable') >> Architecture: amd64 (x86_64) >> >> Kernel: Linux 4.19.0-2-amd64 (SMP w/8 CPU cores) >> Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE >> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), >> LANGUAGE=en_US:en (charmap=UTF-8) >> Shell: /bin/sh linked to /bin/dash >> Init: systemd (via /run/systemd/system) >> LSM: AppArmor: enabled
Bug#924913: trackpad on L480 unusable after upgrade to testing
Source: linux Severity: normal Dear Maintainer, On a Lenovo L480 laptop, I've upgraded Debian from 9 (stretch) to 10 (testing). After the upgrade, the touchpad and the trackpoint was not usable anymore. This already has some bug report here, https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1803600 As a workaround, one can run the command, sudo sh -c 'echo -n "elantech"> /sys/bus/serio/devices/serio1/protocol' in order to use the touchpad. However, on a GUI Interface and without an external mouse, it's impossible to apply this workaround (switching to the terminal -F1, login, and run the command above might work) I expect to be able to use the touchpad just out of the box, not needing to run the above workaround -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (990, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-2-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#921613: mediathekview: fails to run with openjdk-11
Package: mediathekview Version: 13.2.1-2 Severity: important Dear Maintainer, * What led up to the situation? I removed openjdk-8 and installed openjdk-11 because there are plans not to include openjdk-8 in buster. * What exactly did you do (or not do) that was effective (or ineffective)? I tried openjdk-11,medithekview from stretch as well as from testing (buster) it did not start w/o openjdk-8. * What was the outcome of this action? starting mediathekview from command line fails to start with these message: [warning] /usr/bin/mediathekview: JVM flavor 'java9' not understood [warning] /usr/bin/mediathekview: No java runtime was found * What outcome did you expect instead? mediathekview should start, and it's gui should be shown. *** End of the template - remove these template lines *** -- System Information: Debian Release: 9.7 APT prefers stable APT policy: (990, 'stable'), (80, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386, armhf Kernel: Linux 4.19.0-0.bpo.1-amd64 (SMP w/4 CPU cores) Locale: LANG=de_AT.UTF-8, LC_CTYPE=de_AT.UTF-8 (charmap=UTF-8), LANGUAGE=de_AT:de (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages mediathekview depends on: ii java-wrappers 0.1.28 ii libcommons-compress-java 1.13-1 ii libcommons-configuration2-java 2.2-1 ii libcommons-dbcp2-java 2.5.0-1 ii libcommons-lang3-java 3.5-1 ii libcommons-pool2-java 2.6.0-1 ii libcontrolsfx-java 9.0.0+hg20181001-1 ii libguava-java 19.0-1 ii libh2-java 1.4.197-4 ii libjackson2-core-java 2.8.6-1 ii libjchart2d-java 3.2.2+dfsg-2 ii libjiconfont-font-awesome-java 4.7.0.0-1 ii libjiconfont-java 1.0.0-1 ii libjiconfont-swing-java 1.0.1-1 ii libjide-oss-java 3.6.16+dfsg-2 ii liblog4j2-java 2.11.1-2 ii libmbassador-java 1.3.1-1 ii libmiglayout-java 5.1-2 ii libokhttp-java 3.12.1-2 ii libopenjfx-java 11.0.2+1-1 ii libswingx-java 1:1.6.2-2 ii libxz-java 1.6-1 ii openjdk-11-jre [java9-runtime] 11.0.2+9-3 Versions of packages mediathekview recommends: ii flvstreamer 2.1c1-1+b2 ii mpv 0.23.0-2+deb9u2 ii vlc 3.0.6-0+deb9u1 Versions of packages mediathekview suggests: ii ffmpeg 7:3.2.12-1~deb9u1 -- debconf-show failed
Bug#911743: enabling orange-fs in linux
Package: linux Version: unstable Severity: wishlist Source: linux We are looking into distributed, parallel filesystems like beegfs and orangefs. I'd prefer orangefs (mainly because of its license terms). We'd like to use Debian/stable for this set up, unfortunately, the current debian kernel has orange-fs support disabled. Based on an initial response from https://lists.debian.org/debian-kernel/2018/10/msg00181.html I'm asking to enable orange-fs support in the linux kernel Thanks for considering, Alois
Bug#776726: Acknowledgement (rdesktop 1.8.2-3 fails to connect to Windows Server 2008)
control: severity -1 important thanks Does the workaround in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=763599 work? No, this is not working for me. After doing apt-get source rdesktop cd rdesktop-1.8.2 ./configure --disable-credssp --disable-smartcard make ~/rdesktop-1.8.2$ ./rdesktop myserver.win7_2008.local There is still no remote connection. The problem after installing rdesktop from testing sudo apt-get -t testing install rdesktop Then rdesktop myserver.win7_2008.local opens the desired connection; although it still presents the following message on the terminal. Autoselected keyboard map de Connection established using SSL. disconnect: Invalid licensing message. Alois -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#776726: rdesktop 1.8.2-3 fails to connect to Windows Server 2008
Package: rdesktop Version: 1.8.2-3 Severity: grave Dear Maintainer, trying to connect to a Windows Server 2008 using this command rdesktop -n -f -u IST\\schloegl win2008.domain did not open a connection but reports this message It ERROR: CredSSP: Initialize failed, do you have correct kerberos tgt initialized ? Connection established using SSL. disconnect: Invalid licensing message. and a windows is briefly opened and disappears immediately, so no message can be read. The problem seems to be related to the version in testing (rdesktop 1.8.2-3) only. 1.7.1-1 (stable) as well as 1.8.3-1 (unstable) do open a connection to the same server. -- System Information: Debian Release: 8.0 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=de_AT.UTF-8, LC_CTYPE=de_AT.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages rdesktop depends on: ii libasound21.0.28-1 ii libc6 2.19-13 ii libgssglue1 0.4-2 ii libpcsclite1 1.8.13-1 ii libssl1.0.0 1.0.1k-1 ii libx11-6 2:1.6.2-3 ii libxrandr22:1.4.2-1+b1 rdesktop recommends no packages. Versions of packages rdesktop suggests: pn pcscd none -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#674072: memory leak in getpwuid/nsswitch.c
Package: libc6-bin
Version: 2.11.3-3
Severity:important
Using the function getpwuid() in my application, resulted in a memory leak. The
minimal test case is this:
$ cat c.c
#includepwd.h
main() {
struct passwd *q = getpwuid(geteuid());
}
$ gcc c.c valgrind --leak-check=full ./a.out
==22230== Memcheck, a memory error detector
==22230== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==22230== Using Valgrind-3.6.0.SVN-Debian and LibVEX; rerun with -h for
copyright info
==22230== Command: ./a.out
==22230==
==22230==
==22230== HEAP SUMMARY:
==22230== in use at exit: 300 bytes in 11 blocks
==22230== total heap usage: 68 allocs, 57 frees, 9,898 bytes allocated
==22230==
==22230== 300 (60 direct, 240 indirect) bytes in 1 blocks are definitely lost
in loss record 11 of 11
==22230==at 0x4C244E8: malloc (vg_replace_malloc.c:236)
==22230==by 0x4F08A3C: nss_parse_service_list (nsswitch.c:622)
==22230==by 0x4F0922D: __nss_database_lookup (nsswitch.c:164)
==22230==by 0x558D34F: ???
==22230==by 0x558DFA4: ???
==22230==by 0x4EC8D8C: getpwuid_r@@GLIBC_2.2.5 (getXXbyYY_r.c:253)
==22230==by 0x4EC867E: getpwuid (getXXbyYY.c:117)
==22230==by 0x40054C: main (in /tmp/a.out)
==22230==
==22230== LEAK SUMMARY:
==22230==definitely lost: 60 bytes in 1 blocks
==22230==indirectly lost: 240 bytes in 10 blocks
==22230== possibly lost: 0 bytes in 0 blocks
==22230==still reachable: 0 bytes in 0 blocks
==22230== suppressed: 0 bytes in 0 blocks
==22230==
==22230== For counts of detected and suppressed errors, rerun with: -v
==22230== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 4 from 4)
The bug is described here:
http://sourceware.org/bugzilla/show_bug.cgi?id=14122
The fix is here:
http://sourceware.org/git/?p=glibc.git;a=commitdiff;h=d44638b0a7fc1f01c3b2153cfa1bbb849f01f217
Since this is fixed only in glibc v2.16, and debian squeeze is using 2.11 and
wheezy uses 2.13 it would be great if this could be fixed also Debian stable
and testing.
Alois
Bug#594906: [Pkg-octave-devel] Bug#594906: update octave-nan and bug fix
On 08/30/2010 05:49 PM, Jordi Gutiérrez Hermoso wrote: On 30 August 2010 10:35, Alois Schlöglalois.schlo...@gmail.com wrote: I've uploaded a new release to Octave.sf.net: http://sourceforge.net/projects/octave/files/Octave%20Forge%20Packages/Individual%20Package%20Releases/NaN-2.0.4.tar.gz/download which was not picked up by debian. Thanks, I'll prepare an updated package. That would be great. Please note, the latest release (v2.3.0) is available here http://biosig-consulting.com/matlab/NaN/nan-2.3.0.tar.gz and here: https://sourceforge.net/projects/octave/files/Octave%20Forge%20Packages/Individual%20Package%20Releases/nan-2.3.0.tar.gz/download If there is anything I can do making it easier for debian to pick up the latest release, please let me know. We might need to update our debian/watch file to have it inform us of new releases. Indeed, it looks like it's giving us 404 errors right now. I'll look into it. That would be great. Alois -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#594906: [Pkg-octave-devel] Bug#594906: update octave-nan and bug fix
On 08/30/2010 06:58 PM, Jordi Gutiérrez Hermoso wrote: On 30 August 2010 10:49, Jordi Gutiérrez Hermosojord...@gmail.com wrote: On 30 August 2010 10:35, Alois Schlöglalois.schlo...@gmail.com wrote: I've uploaded a new release to Octave.sf.net: http://sourceforge.net/projects/octave/files/Octave%20Forge%20Packages/Individual%20Package%20Releases/NaN-2.0.4.tar.gz/download which was not picked up by debian. Thanks, I'll prepare an updated package. I see that the old version still shows up here: http://octave.sourceforge.net/nan/index.html You might need to ping Søren Haubergso...@hauberg.org to update this page, as it's not completely automatically generated. I've figured out a way to update this file myself. Thomas Webertwe...@debian.org has in fact updated this package's watch file, but I don't see this update in a release. However, we depend on the above link for determining the latest version of the NaN package. The latest centralized release of octave-forge packages was done in Jun 2009(!!!). I think Soren took over only after this date. Since then, packages were released only in an individual basis. http://sourceforge.net/projects/octave/files/Octave%20Forge%20Packages/Individual%20Package%20Releases/ The debian watch file http://dehs.alioth.debian.org/wwiz_detail.php?id=33493299type=watch contains this: version=3 http://octave.sourceforge.net/packages.html \ http://downloads\.sourceforge\.net/octave/nan-([\d.]+)\.tar\.gz\?download However http://octave.sourceforge.net/packages.html yields a 404 error. http://downloads.sourceforge.net/octave resolves to http://sourceforge.net/projects/octave/files/ and http://sourceforge.net/projects/octave/files/nan-2.3.0.tar.gz results in this error The /nan-2.3.0.tar.gz file could not be found or is not available. Please select another file. Probably, this was caused by changes at directory structure of the sourceforge release system. Because of this changes at sourceforge, it seems that the debian watch file might need some modification, as well. The latest release of Octave-NaN is always available from here: http://biosig-consulting.com/matlab/NaN/ Do you want us to point our watch file to that location and bypass the Octave-Forge distribution? I would prefer not to, unless you think your distribution method is irreconcilable with the 'Forge distribution. I like to make it as simple as possible. This is currently not the case. I'm trying to keep the following links updated, each need manual interaction. [1] https://mloss.org/software/view/206/ [2] http://biosig-consulting.com/matlab/NaN/ [3] http://sourceforge.net/projects/octave/files/Octave%20Forge%20Packages/Individual%20Package%20Releases/ I would appreciate, if we can find a way to simplify this. What is your suggestion for updating the debian octave-nan package with a smaller turn-around time ? Is there a way that I can trigger the generation of a new octave-nan package (perhaps from the SVN-repository) for debian ? Alois -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#594906: [Pkg-octave-devel] Bug#594906: update octave-nan and bug fix
On 08/30/2010 10:14 PM, Thomas Weber wrote: Hi Alois, thanks for caring about your software in distributions. On Mon, Aug 30, 2010 at 05:35:28PM +0200, Alois Schlögl wrote: Version 1.0.9 is really outdated and contains a bug. e.g. https://savannah.gnu.org/bugs/index.php?30905 Is there something more critical than this bug fixed? Debian is in freeze right now, so getting a new version into the next stable version is difficult, unless: - the change is small (which ususally rules out a new upstream release) - the bug is critical. The bug was fixed in Oct 2009, and several new releases of octave-nan have been made. That's strange. I uploaded 1.0.9 at the end of december and I'm reasonably sure that was the latest version I found at Sourceforge back then. Some information about 'watch' files: we use them to check upstream's pages automatically for updates. In the case of NaN, Sourceforge still lists 1.0.9 as the latest release. It seems the debian watch file for octave-nan is also broken: http://dehs.alioth.debian.org/report.php?package=octave-nanDisplay=Submit+Query * *Name:* octave-nan http://packages.qa.debian.org/octave-nan o *Pop Inst:* o *Upstream version: * none o *Debian version: *1.0.9-1 o *Last time checked: *2010-08-29 06:16:05 o *Last time found up to date: *2010-08-29 06:16:05 o *Total continuous failures: *42 o *Tot Upstream Bugs: *0 o *Avg days opened: *0 o *Distrib: *unstable http://packages.debian.org/unstable/octave-nan o *Watch: *view http://dehs.alioth.debian.org/wwiz_detail.php?id=33493299type=watch o *Uscan errors: * uscan.pl warning: In watchfile /tmp/octave-nan_watchpNjOQe, reading webpage http://octave.sourceforge.net/packages.html failed: 404 Not Found o *Copyright: *view http://packages.debian.org/changelogs/pool/main/o/octave-nan/octave-nan_1.0.9-1/copyright Alois
Bug#594906: update octave-nan and bug fix
Package: octave-nan Version: 1.0.9 Version 1.0.9 is really outdated and contains a bug. e.g. https://savannah.gnu.org/bugs/index.php?30905 The bug was fixed in Oct 2009, and several new releases of octave-nan have been made. I've uploaded a new release to Octave.sf.net: http://sourceforge.net/projects/octave/files/Octave%20Forge%20Packages/Individual%20Package%20Releases/NaN-2.0.4.tar.gz/download which was not picked up by debian. The latest release of Octave-NaN is always available from here: http://biosig-consulting.com/matlab/NaN/ http://biosig-consulting.com/matlab/NaN/nan-2.3.0.tar.gz If there is anything I can do making it easier for debian to pick up the latest release, please let me know. Kind regards, Alois Schloegl -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#594906: [Pkg-octave-devel] Bug#594906: update octave-nan and bug fix
On 08/30/2010 10:14 PM, Thomas Weber wrote: Hi Alois, thanks for caring about your software in distributions. On Mon, Aug 30, 2010 at 05:35:28PM +0200, Alois Schlögl wrote: Version 1.0.9 is really outdated and contains a bug. e.g. https://savannah.gnu.org/bugs/index.php?30905 Is there something more critical than this bug fixed? Debian is in freeze right now, so getting a new version into the next stable version is difficult, unless: - the change is small (which ususally rules out a new upstream release) - the bug is critical. The patch to fix this bug is http://octave.svn.sourceforge.net/viewvc/octave/trunk/octave-forge/extra/NaN/inst/var.m?r1=5807r2=6295 --- trunk/octave-forge/extra/NaN/inst/var.m 2009/05/12 11:32:58 5807 +++ trunk/octave-forge/extra/NaN/inst/var.m 2009/10/06 10:56:59 6295 @@ -72,6 +72,10 @@ return; end; +if isempty(opt), + opt = 0; +end; + if isempty(DIM), DIM=min(find(size(x)1)); if isempty(DIM), DIM=1; end; The bug was fixed in Oct 2009, and several new releases of octave-nan have been made. That's strange. I uploaded 1.0.9 at the end of december and I'm reasonably sure that was the latest version I found at Sourceforge back then. v2.0.4 was uploaded, but the script generating nan/index.html did not pick it up. Some information about 'watch' files: we use them to check upstream's pages automatically for updates. In the case of NaN, Sourceforge still lists 1.0.9 as the latest release. Now that I'm aware of the problem, I changed the watch file manually. I've uploaded a new release to Octave.sf.net: http://sourceforge.net/projects/octave/files/Octave%20Forge%20Packages/Individual%20Package%20Releases/NaN-2.0.4.tar.gz/download which was not picked up by debian. The latest release of Octave-NaN is always available from here: http://biosig-consulting.com/matlab/NaN/ http://biosig-consulting.com/matlab/NaN/nan-2.3.0.tar.gz If there is anything I can do making it easier for debian to pick up the latest release, please let me know. If the above is a canonical place for the NaN package, that suffices. Now, that the watch-file at octave-forge is fixed, it's ok to use this. However, right now an upload to Debian unstable (the normal development version of Debian) is not possible, sorry. I can upload it to Debian experimental, but Ubuntu will not pick this up (I think). Thomas The patch for 1.0.9 should go in immediately. Concerning the latest release, I would appreciate if 2.3.0 would go into experimental as fast as possible. Alois -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#501016: [Pkg-octave-devel] Bug#501016: octave3.0: sumskipnan undefined?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Recently, another bug on sumskipnan.oct was reported here http://www-old.cae.wisc.edu/pipermail/bug-octave/2009-February/008061.html because sumskipnan.oct does not support complex numbers. This is actually more serious because it affects also the stable release. A quick fix is to remove sumskipnan.oct, then the (presumably slower) sumskipnan.m is used http://www-old.cae.wisc.edu/pipermail/bug-octave/2009-February/008065.html At least the problem is gone. This should also solve the problem reported above. More recently, I updated the NaN-toolbox and made several improvments (especially with respect to performance). Therefore, I recommend to make a new release for octave-nan from the sources at octave-forge/extra/NaN, this bug should be fixed, too. Please note, that sumskipnan.oct is not maintained anymore, but its recommended to use sumskipnan_mex.mex instead. Cheers, Alois -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAknCedEACgkQzSlbmAlvEIiisgCgtbxeOWUvO0RPtZB7Dd26LnH/ +lwAoIw4j6gRqLzVjMMKUXGqmMMz1VYp =SFJU -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#419556: [Pkg-octave-devel] Bug#419556: ambigous results in matrix multipliication
Thomas Weber wrote: Am Montag, 23. April 2007 22:01:44 schrieb Alois Schlögl: Thomas Weber wrote: I guess the best fix for this problem is installing one of the atlas3-* packages. Yes, I agree. Setting the dependences accordingly would solve the problem for the debian users of octave. Well, we actually have atlas3-base | lapack3 | liblapack.so.3 as Depends-line. So you should get atlas3-base if you install Octave and only if it's not available, one of the alternatives. The problem is: if you already have lapack installed, atlas3 won't be installed. Do you have OpenOffice.org on the same machine? Yes, OO is installed. Regarding the fix for dgemm: sorry, but dgemm is a known and documented reference implementation. I don't think we should tinker with that. Following that line of thinking, the consequence is to change the list of dependencies in such a way that atlas3-* must be used and lapack is not a viable alternative anymore. Regards Thomas Regards, Alois -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#419556: [Pkg-octave-devel] Bug#419556: ambigous results in matrix multipliication
Thomas Weber wrote:
Hi,
Am Montag, 16. April 2007 17:32 schrieb Alois Schloegl:
One expects that a matrix multiplication (A*B)' gives the same result than
for (B'*A'). This is not the case for the debian octave package (tested
with 2.9.10-3 and 2.1.73-13)
Here is the test script:
repmat(0,2)*repmat(NaN,2)
repmat(NaN,2)*repmat(0,2)
repmat(0,2)*repmat(inf,2)
repmat(inf,2)*repmat(0,2)
version
octave_config_info('BLAS_LIBS')
I take it for granted that you didn't have ATLAS installed. Is this correct?
The answer in my last mail was just a guess (I did not have access to
the same machine). Now, I was able to check this on a different machine.
Yes, I can confirm that the result depends on the fact whether atlas is
installed or not.
Unless I'm mistaken, the reference implementation of dgemm is supposed to do
exactly this, see
http://velveeta.che.wisc.edu/octave/lists/bug-octave/2002/310
The problem seems to be in the lapack or blas library. Because this problem
disappears (the result is always NaN) when I compile Octave from the
sources using Atlas.
I guess the best fix for this problem is installing one of the atlas3-*
packages.
Yes, I agree. Setting the dependences accordingly would solve the
problem for the debian users of octave.
Regards
Thomas
Regards,
Alois
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
