Bug#1068032: stimfit 0.16.4-1.1 packaged for debian

2024-08-16 Thread Alois Schlögl

Dear Yaroslav,

yes, everything for 0.16.4-1 avaiable in [1] at
commit 416e655f02085118ffc7dbf2da85c52415b42f57 (tag: v0.16.4debian, 
origin/master, origin/HEAD)
Currently, I can not push the attached patch for 0.16.4-1-1 into [1], 
therefore I attached the patch.
A clone of the repo is also available here [2], which includes that 
latest patch.


Let me know if you need anything else.


Cheers,
  Alois




[1] https://github.com/neurodroid/stimfit
[2] https://git.ista.ac.at/alois.schloegl/stimfit


Am 8/16/24 um 14:32 schrieb Yaroslav Halchenko:

Hi Alois

Sorry for radio silence.  Now I have my attention on this, let's get
stimfit updated.

On 5 Apr 2024 you also shared new orig and .deb for 0.16.4-1 but forgot
to share sources (.dsc or at least .debian.tar.gz) -- could you do that?
Or may be you already have it all in git, e.g. in a debian branch on
your https://github.com/neurodroid/stimfit ?

Cheers,

On Fri, 16 Aug 2024, Alois Schlögl wrote:


Dear Debian maintainers,
Upgrading to the latest release of stimfit v0.16.4 fixes this issue.
The resulting debian packages are available from here:
  https://pub.ista.ac.at/~schloegl/src/stimfit/0.16.4-1.1/
The debian packages can be rebuild with this command (tested on
Debian12/bookworm)
     git clone https://github.com/neurodroid/stimfit
     patch -p1 < stimfit-0.16.4-1.1-debian-release-changes.patch
or
     git clone https://git.ista.ac.at/alois.schloegl/stimfit
and run this script to build the debian packages:
     (. dist/debian/mkdeb.sh)



Cheers,
   Alois




commit 020ba74efafa5e76e263cf13c67babc88ca63025
Author: Alois Schlögl 
Date:   Thu Aug 15 23:06:28 2024 +0200
 prepare debian release 0.16.4-1.1
diff --git a/dist/debian/changelog b/dist/debian/changelog
index abb6b13b..e5a49571 100644
--- a/dist/debian/changelog
+++ b/dist/debian/changelog
@@ -1,3 +1,11 @@
+stimfit (0.16.4-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * use external libbiosig instead of internal
+(configure --with-biosig instead of --with-biosiglite)
+
+ -- Alois Schloegl   Thu, 15 Aug 2024 12:56:35 +1300
+
  stimfit (0.16.4-1) unstable; urgency=medium
* Non-maintainer upload.
diff --git a/dist/debian/control b/dist/debian/control
index 38d85c55..aaff7404 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, libbiosig-dev (>= 2.1.0), 
python3-dev, python3-numpy, libhdf5-dev, swig, python3-sip-dev, python3-wxgtk4.0 (>= 
4.0.7), libwxgtk3.2-dev, libfftw3-dev, liblapack-dev, chrpath, help2man, zlib1g-dev, 
dh-autoreconf, pkg-config
+Build-Depends: debhelper (>= 10), dh-python, libbiosig-dev (>= 2.1.0), 
python3-dev, python3-numpy, libhdf5-dev, swig, python3-sip-dev, python3-wxgtk4.0 (>= 
4.0.7), libwxgtk3.2-dev, libfftw3-dev, liblapack-dev, chrpath, help2man, zlib1g-dev, 
dh-autoreconf, pkg-config
  Standards-Version: 3.9.8
  Homepage: http://www.stimfit.org
diff --git a/dist/debian/copyright b/dist/debian/copyright
index 4d12ebad..4ba47f1c 100644
--- a/dist/debian/copyright
+++ b/dist/debian/copyright
@@ -7,10 +7,6 @@ Files: *
  Copyright: 2011, Christoph Schmidt-Hieber 
  License: GPL-2+
-Files: src/libbiosiglite/*
-Copyright: 2005-2016, Alois Schloegl 
-License: GPL-3
-
  Files: src/libstfio/abf/axon/*
  Copyright: 1993-2000, Axon Instruments 
  License: axon1
diff --git a/dist/debian/mkdeb.sh b/dist/debian/mkdeb.sh
index 661c8962..dd0c333f 100644
--- a/dist/debian/mkdeb.sh
+++ b/dist/debian/mkdeb.sh
@@ -10,6 +10,8 @@ cp -v stimfit-${VERSION}.tar.gz 
../deb/stimfit_${VERSION}.orig.tar.gz
  cd ../deb/
  tar -xzf stimfit_${VERSION}.orig.tar.gz
  cd stimfit-${VERSION}
-cp -rv ../../../dist/debian ./
-debuild -S -sa
-sudo pbuilder build --basetgz /var/cache/pbuilder/base.tgz ../*.dsc
+cp -rv ../../stimfit/dist/debian ./
+# debuild -S -sa
+debuild -i -us -uc -S
+debuild -i -us -uc -b
+# sudo pbuilder build --basetgz /var/cache/pbuilder/base.tgz ../*.dsc
diff --git a/dist/debian/rules b/dist/debian/rules
index 0354214f..4460f7b2 100755
--- a/dist/debian/rules
+++ b/dist/debian/rules
@@ -42,11 +42,9 @@ clean:
find -name '*.la' | xargs -r rm -f
find -name '*.so' | xargs -r rm -f
rm -f $(CURDIR)/test.h5
-   dh_autoreconf_clean
dh_clean
  install: build
-   dh_autoreconf
PYTHON=/usr/bin/python$(PYVER) PYTHON_VERSION=$(PYVER) ./configure 
--enable-python --enable-debian --with-biosig --prefix=$(DEBPREFIX) 
$(WXCONFIG_OPTS)
$(MAKE)
  ifeq (,$(filter nocheck,$(DEB_BUILD_OPTIONS)))






Bug#1068032: stimfit 0.16.4-1.1 packaged for debian

2024-08-15 Thread Alois Schlögl

Dear Debian maintainers,

Upgrading to the latest release of stimfit v0.16.4 fixes this issue.
The resulting debian packages are available from here:
 https://pub.ista.ac.at/~schloegl/src/stimfit/0.16.4-1.1/

The debian packages can be rebuild with this command (tested on 
Debian12/bookworm)

    git clone https://github.com/neurodroid/stimfit
    patch -p1 < stimfit-0.16.4-1.1-debian-release-changes.patch
or
    git clone https://git.ista.ac.at/alois.schloegl/stimfit
and run this script to build the debian packages:
    (. dist/debian/mkdeb.sh)


Cheers,
  Alois


commit 020ba74efafa5e76e263cf13c67babc88ca63025
Author: Alois Schlögl 
Date:   Thu Aug 15 23:06:28 2024 +0200

prepare debian release 0.16.4-1.1

diff --git a/dist/debian/changelog b/dist/debian/changelog
index abb6b13b..e5a49571 100644
--- a/dist/debian/changelog
+++ b/dist/debian/changelog
@@ -1,3 +1,11 @@
+stimfit (0.16.4-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * use external libbiosig instead of internal
+(configure --with-biosig instead of --with-biosiglite)
+
+ -- Alois Schloegl   Thu, 15 Aug 2024 12:56:35 +1300
+
 stimfit (0.16.4-1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff --git a/dist/debian/control b/dist/debian/control
index 38d85c55..aaff7404 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, libbiosig-dev (>= 2.1.0), python3-dev, python3-numpy, libhdf5-dev, swig, python3-sip-dev, python3-wxgtk4.0 (>= 4.0.7), libwxgtk3.2-dev, libfftw3-dev, liblapack-dev, chrpath, help2man, zlib1g-dev, dh-autoreconf, pkg-config
+Build-Depends: debhelper (>= 10), dh-python, libbiosig-dev (>= 2.1.0), python3-dev, python3-numpy, libhdf5-dev, swig, python3-sip-dev, python3-wxgtk4.0 (>= 4.0.7), libwxgtk3.2-dev, libfftw3-dev, liblapack-dev, chrpath, help2man, zlib1g-dev, dh-autoreconf, pkg-config
 Standards-Version: 3.9.8
 Homepage: http://www.stimfit.org
 
diff --git a/dist/debian/copyright b/dist/debian/copyright
index 4d12ebad..4ba47f1c 100644
--- a/dist/debian/copyright
+++ b/dist/debian/copyright
@@ -7,10 +7,6 @@ Files: *
 Copyright: 2011, Christoph Schmidt-Hieber 
 License: GPL-2+
 
-Files: src/libbiosiglite/*
-Copyright: 2005-2016, Alois Schloegl 
-License: GPL-3
-
 Files: src/libstfio/abf/axon/*
 Copyright: 1993-2000, Axon Instruments 
 License: axon1
diff --git a/dist/debian/mkdeb.sh b/dist/debian/mkdeb.sh
index 661c8962..dd0c333f 100644
--- a/dist/debian/mkdeb.sh
+++ b/dist/debian/mkdeb.sh
@@ -10,6 +10,8 @@ cp -v stimfit-${VERSION}.tar.gz ../deb/stimfit_${VERSION}.orig.tar.gz
 cd ../deb/
 tar -xzf stimfit_${VERSION}.orig.tar.gz
 cd stimfit-${VERSION}
-cp -rv ../../../dist/debian ./
-debuild -S -sa
-sudo pbuilder build --basetgz /var/cache/pbuilder/base.tgz ../*.dsc
+cp -rv ../../stimfit/dist/debian ./
+# debuild -S -sa
+debuild -i -us -uc -S
+debuild -i -us -uc -b
+# sudo pbuilder build --basetgz /var/cache/pbuilder/base.tgz ../*.dsc
diff --git a/dist/debian/rules b/dist/debian/rules
index 0354214f..4460f7b2 100755
--- a/dist/debian/rules
+++ b/dist/debian/rules
@@ -42,11 +42,9 @@ clean:
 	find -name '*.la' | xargs -r rm -f
 	find -name '*.so' | xargs -r rm -f
 	rm -f $(CURDIR)/test.h5
-	dh_autoreconf_clean
 	dh_clean
 
 install: build
-	dh_autoreconf
 	PYTHON=/usr/bin/python$(PYVER) PYTHON_VERSION=$(PYVER) ./configure --enable-python --enable-debian --with-biosig --prefix=$(DEBPREFIX) $(WXCONFIG_OPTS)
 	$(MAKE)
 ifeq (,$(filter nocheck,$(DEB_BUILD_OPTIONS)))


Bug#1074847: biosig 2.6.1 provides bug fixes

2024-08-04 Thread Alois Schlögl



biosig 2.6.1 is released and tries to address these bugs #1074847, #1076868

Downloads are available from here:
https://biosig.sourceforge.net/download.html
https://sourceforge.net/projects/biosig/files/BioSig%20for%20C_C%2B%2B/src/biosig-2.6.1.src.tar.xz



Bug#1077516: amdgpu (xorg) crashes with kernel: [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx_0.0.0 timeout, signaled

2024-07-29 Thread Alois Schlögl

Package: firmware-amd-graphics
Version: 20230210-5


*** Reporter, please consider answering these questions, where 
appropriate ***


   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

   Occasionally, the screen of my Lenovo/T14s goes black or the 
X-session is restarted.


   Here is a procedure how reproduce this issue:
   - running the installer of flowjo [1] within wine [2] crashes the 
x-sessions or the
   [1] 
https://fjinstallers.s3.amazonaws.com/FlowJo/FlowJo-Win64-10.10.0.exe
   [2] I used wine-devel (wine 9.13), but I expect this this will be 
reproducible with wine 8.x too.

   However, occassianally the issue occurs also in other cases.

   The logs during this crash are attached.
   After uninstalling "firmware-amd-graphics/20230210-5" from debian 
bookworm  and rebooting the machine, the problem went away (also at the 
cost that no 2nd screen is available).


   Installing the more recent version of
  firmware-amd-graphics/20240709-1
   from testing repository fixes this issue.

   Therefore, I believe that firmware-amd-graphics/20230210-5 is buggy, 
and the more recent version of firmware-amd-graphics should be used.




*** End of the template - remove these template lines ***


-- System Information:
Debian Release: 12.6
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.1.0-23-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en

Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

firmware-amd-graphics depends on no packages.

firmware-amd-graphics recommends no packages.

Versions of packages firmware-amd-graphics suggests:
ii  initramfs-tools  0.142Jul 29 15:27:49 pascal kernel: [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx_0.0.0 timeout, signaled seq=834899, emitted seq=834901
Jul 29 15:27:49 pascal kernel: [drm:amdgpu_job_timedout [amdgpu]] *ERROR* Process information: process Xorg pid 23803 thread Xorg:cs0 pid 23804
Jul 29 15:27:49 pascal kernel: amdgpu :c3:00.0: amdgpu: GPU reset begin!
Jul 29 15:27:49 pascal kernel: [drm] REG_WAIT timeout 1us * 10 tries - optc1_wait_for_state line:817
Jul 29 15:27:49 pascal kernel: [drm] REG_WAIT timeout 1us * 10 tries - optc1_wait_for_state line:817
Jul 29 15:27:49 pascal kernel: [drm] REG_WAIT timeout 1us * 10 tries - optc1_wait_for_state line:817
Jul 29 15:27:50 pascal kernel: [drm:mes_v11_0_submit_pkt_and_poll_completion.constprop.0 [amdgpu]] *ERROR* MES failed to response msg=3
Jul 29 15:27:50 pascal kernel: [drm:amdgpu_mes_unmap_legacy_queue [amdgpu]] *ERROR* failed to unmap legacy queue
Jul 29 15:27:50 pascal kernel: [drm:mes_v11_0_submit_pkt_and_poll_completion.constprop.0 [amdgpu]] *ERROR* MES failed to response msg=3
Jul 29 15:27:50 pascal kernel: [drm:amdgpu_mes_unmap_legacy_queue [amdgpu]] *ERROR* failed to unmap legacy queue
Jul 29 15:27:50 pascal kernel: [drm:mes_v11_0_submit_pkt_and_poll_completion.constprop.0 [amdgpu]] *ERROR* MES failed to response msg=3
Jul 29 15:27:50 pascal kernel: [drm:amdgpu_mes_unmap_legacy_queue [amdgpu]] *ERROR* failed to unmap legacy queue
Jul 29 15:27:50 pascal kernel: [drm:mes_v11_0_submit_pkt_and_poll_completion.constprop.0 [amdgpu]] *ERROR* MES failed to response msg=3
Jul 29 15:27:50 pascal kernel: [drm:amdgpu_mes_unmap_legacy_queue [amdgpu]] *ERROR* failed to unmap legacy queue
Jul 29 15:27:50 pascal kernel: [drm:mes_v11_0_submit_pkt_and_poll_completion.constprop.0 [amdgpu]] *ERROR* MES failed to response msg=3
Jul 29 15:27:50 pascal kernel: [drm:amdgpu_mes_unmap_legacy_queue [amdgpu]] *ERROR* failed to unmap legacy queue
Jul 29 15:27:50 pascal kernel: [drm:mes_v11_0_submit_pkt_and_poll_completion.constprop.0 [amdgpu]] *ERROR* MES failed to response msg=3
Jul 29 15:27:50 pascal kernel: [drm:amdgpu_mes_unmap_legacy_queue [amdgpu]] *ERROR* failed to unmap legacy queue
Jul 29 15:27:51 pascal kernel: [drm:mes_v11_0_submit_pkt_and_poll_completion.constprop.0 [amdgpu]] *ERROR* MES failed to response msg=3
Jul 29 15:27:51 pascal kernel: [drm:amdgpu_mes_unmap_legacy_queue [amdgpu]] *ERROR* failed to unmap legacy queue
Jul 29 15:27:51 pascal kernel: [drm:mes_v11_0_submit_pkt_and_poll_completion.constprop.0 [amdgpu]] *ERROR* MES failed to response msg=3
Jul 29 15:27:51 pascal kernel: [drm:amdgpu_mes_unmap_legacy_queue [amdgpu]] *ERROR* failed to unmap legacy queue
Jul 29 15:27:51 pascal kernel: [drm:mes_v11_0_submit_pkt_and_poll_completion.constprop.0 [amdgpu]] *ERROR* MES failed to response msg=3
Jul 29 15:27:51 pascal kernel: [drm:amdgpu_mes_unmap_legacy_queue [amdgpu]] *ERROR* failed to unmap legacy queue
Jul 29 15:27:51 pascal kernel: [drm:gfx_v11_0_hw_fini [amdgpu]] *ERROR* failed to halt cp gfx



Bug#1056122: slurmctld.log not available after logrotate

2023-11-17 Thread Alois Schlögl



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

2023-11-09 Thread Alois Schlögl



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.

2023-09-05 Thread Alois Schlögl




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

2023-08-24 Thread Alois Schlögl

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

2023-07-25 Thread Alois Schlögl
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

2023-07-23 Thread Alois Schlögl



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)

2023-01-05 Thread Alois Schlögl




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)

2023-01-04 Thread Alois Schlögl

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

2022-10-26 Thread Alois Schlögl



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.

2022-10-04 Thread Alois Schlögl




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

2022-09-05 Thread Alois Schlögl



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

2022-04-21 Thread Alois Schlögl
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.

2022-03-29 Thread Alois Schlögl




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)

2022-03-28 Thread Alois Schlögl



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

2022-03-17 Thread Alois Schlögl




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

2021-12-29 Thread Alois Schlögl


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

2021-05-31 Thread Alois Schlögl




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 inte

Bug#924913: trackpad on L480 unusable after upgrade to testing

2021-05-30 Thread 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 uname -a)
  - Check if your problem is 

Bug#987044: libbiosig3: certain files can crash save2gdf and produce invalid json output

2021-04-16 Thread Alois Schlögl

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

2021-02-21 Thread Alois Schlögl
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

2020-11-15 Thread Alois Schlögl
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 (&biosig_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 "gui_impl/gui_h

Bug#973435: biosig build-depends on python3-all-dev, but only builds for the default python3 version

2020-11-12 Thread Alois Schlögl



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

2020-08-19 Thread Alois Schlögl
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(¤tTime));
+time_t currentTime = time(nullptr);
+std::string timeString = asctime(localtime(¤tTime));
 timeString.pop_back(); //we don't need '\n' at the end
 XDFdata->streams.back().streamHeader =
 ""


Bug#936207: biosig4c++: Python2 removal in sid/bullseye

2019-11-30 Thread Alois Schlögl

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

2019-09-27 Thread Alois Schlögl
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

2019-09-25 Thread Alois Schlögl


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

2019-05-29 Thread Alois Schlögl
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-

Bug#924913: trackpad on L480 unusable after upgrade to testing

2019-03-20 Thread Alois Schlögl
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

2019-03-18 Thread Alois Schlögl
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

2019-03-18 Thread Alois Schlögl


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

2019-02-07 Thread Alois Schlögl
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

2018-10-24 Thread Alois Schlögl

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)

2015-06-15 Thread Alois Schlögl
> 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

2015-01-31 Thread Alois Schlögl
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  

-- 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

2012-05-22 Thread Alois Schlögl

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
#include
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

2010-09-06 Thread Alois Schlögl

On 08/30/2010 05:49 PM, Jordi Gutiérrez Hermoso wrote:

On 30 August 2010 10:35, Alois Schlögl  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

2010-08-31 Thread Alois Schlögl

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-nan&Display=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=33493299&type=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: [Pkg-octave-devel] Bug#594906: update octave-nan and bug fix

2010-08-31 Thread Alois Schlögl

On 08/30/2010 06:58 PM, Jordi Gutiérrez Hermoso wrote:

On 30 August 2010 10:49, Jordi Gutiérrez Hermoso
wrote:
   

On 30 August 2010 10:35, Alois Schlögl
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 Hauberg  to update
this page, as it's not completely automatically generated.


I've figured out a way to update this file myself.


  Thomas
Weber  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=33493299&type=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

2010-08-30 Thread Alois Schlögl

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=5807&r2=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#594906: update octave-nan and bug fix

2010-08-30 Thread Alois Schlögl

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#501016: [Pkg-octave-devel] Bug#501016: octave3.0: sumskipnan undefined?

2009-03-19 Thread Alois Schlögl
-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

2007-04-25 Thread Alois Schlögl

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

2007-04-23 Thread Alois Schlögl

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]