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

[Alois Schloegl]

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,


I'm not sure what debian expects, and what kind of changes you would
expect. If there is some documentation about this, please point me to
that, and I'll have a look what I can do.

If you say the "fallback code" does not work, beause of "rais[ing] a
different exception than ValueError", perhaps removing that part (see
attached
patch_remove-python-setup-pkgconfig-exception.diff
) might solve this.


In any case, the installation of biosig-python works if libbiosig is
available on the system, in which case one needs to do only

pip install numpy pkgconfig
pip install Biosig-1.9.1.tar.gz

where Biosig-1.9.1.tar.gz is just built in python/dist with this command:
cd python && make release

I provide the sources also here
 https://pub.ist.ac.at/~schloegl/biosig/prereleases/Biosig-1.9.1.tar.gz



Kind regards,
   Alois

diff --git a/biosig4c++/python/setup.py b/biosig4c++/python/setup.py
index 8539a20a..be9e437b 100644
--- a/biosig4c++/python/setup.py
+++ b/biosig4c++/python/setup.py
@@ -12,17 +12,11 @@ except ImportError:
 import os
 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'
+import pkgconfig
+PKG=pkgconfig.parse('libbiosig')
+CPATH=PKG['include_dirs']
+LIBS=PKG['libraries']
+LIBDIR=PKG['library_dirs']
 
 module_biosig = Extension('biosig',
 define_macros = [('MAJOR_VERSION', '1'), ('MINOR_VERSION', '9')],

Bug#925643: ignore error in missing symbol

[Alois Schloegl]

The severity of this bug should be changed to minor for the following
reason(s):


The symbol being lost is not from the API of biosig, and no application
using libbiosig could have used it in a meanigful way.

The missing symbol
_cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_M_constructIPKcEEvT_S8_St20forward_iterator_tag
is most likely a change in compiling tinyxml (which is c++), however
libbiosig prodes a C interface. If c++ symbols are exported, it is
unintentional, more overover, those are not part of the API of libbiosig
(see biosig.h and biosig-dev.h).

I admit that visibility of symbols should be managed in order to avoid
such issues, and I plan to do so with the upcoming release (1.9.6). I
could already provide a patch, however this would also change the
symbols and would not help with the present version.

No user application can break by removal of the symbol, because there is
no application that could have made use of that symbol in any meaningful
way. Therefore I suggest to ignore
"dpkg-gensymbols: error: some symbols or patterns disappeared in the
symbols file: see diff output below"
and reduce the severity of this bug to minor.



Cheers,
   Alois

Bug#910686: Pymol 2.2.0 sources available from github

[Alois Schloegl]

Package: pymol   

Version: 2.2.0

Severity: wishlist


The open source version of Pymol 2.2.0 is available from here now:

   https://github.com/schrodinger/pymol-open-source

   https://github.com/schrodinger/pymol-open-source/releases


It seems, debian/watch file is not aware of this new release, attached
is a revised watch file .


May I also suggest to package pymol 2.2.0 ?


Best regards,

  Alois









# See uscan(1) for format
# TODO: http://pymol.svn.sourceforge.net/viewvc/pymol/tags.tar.gz?view=tar
# 
opts=uversionmangle=s/^/0~svn\./,downloadurlmangle=s/xmds\?view.*$/xmds\/trunk\/xmds-doc.tar.gz\?view=tar/,filenamemangle=s/^.*revision=(\d+)$/xmds-doc-0~svn.$1.tar.gz/
 \
#
#  http://xmds.svn.sourceforge.net/viewvc/xmds/trunk/xmds-doc/ .*revision=(\d+)$
#
#version=3
#opts=uversionmangle=s/^(?!1)0?([\d]+)/0\.$1/;s/(.*)rc(.*)/$1~$2/, \
# http://pymol.svn.sourceforge.net/viewvc/pymol/tags/ 
/viewvc/pymol/tags/(?:[rv])?([\d\.]+(?:r\d+)?)(?:rc\d+)?/

version=4
opts=filenamemangle=s/.+\/v?(\d\S+)\.tar\.gz/pymol-$1\.tar\.gz/ \
  https://github.com/schrodinger/pymol-open-source/tags .*/v?(\d\S+)\.tar\.gz

Bug#783653: pymol: Segmentation fault immediately after loading pdb

[Alois Schloegl]

I confirm that this bug occurs under some specific conditions.
For testing I used this file
  http://www.pdb.org/pdb/files/1bl8.pdb
which works fine on a local installation of pymol (Debian/Stretch).

It works also when connecting to OSX (through xquartz 2.7.12 with "ssh
-Y " to a Debian/Jessie server with Pymol installed.

However, when I try to connect from my Debian/Stretch Laptop through
"ssh -X  " to the same Debian/Jessie server, and I try to open the same
file on the server, pymol crashes with the following error message:


>  PyMOL(TM) Molecular Graphics System, Version 1.8.4.0.
>  Copyright (c) Schrodinger, LLC.
>  All Rights Reserved.
>  
> Created by Warren L. DeLano, Ph.D. 
>  
> PyMOL is user-supported open-source software.  Although some versions
> are freely available, PyMOL is not in the public domain.
>  
> If PyMOL is helpful in your work or study, then please volunteer 
> support for our ongoing efforts to create open and affordable scientific
> software by purchasing a PyMOL Maintenance and/or Support subscription.
> 
> More information can be found at "http://www.pymol.org;.
>  
> Enter "help" for a list of commands.
> Enter "help " for information on a specific command.
> 
>  Hit ESC anytime to toggle between text and graphics.
> 
>  Detected OpenGL version 2.0 or greater. Shaders available.
>  Detected GLSL version 1.30.
>  OpenGL graphics engine:
>   GL_VENDOR:   VMware, Inc.
>   GL_RENDERER: Gallium 0.4 on llvmpipe (LLVM 3.8, 256 bits)
>   GL_VERSION:  3.0 Mesa 13.0.6
>  Detected 32 CPU cores.  Enabled multithreaded rendering.
> HEADERMEMBRANE PROTEIN23-JUL-98   1BL8
> TITLE POTASSIUM CHANNEL (KCSA) FROM STREPTOMYCES LIVIDANS
> COMPNDMOL_ID: 1;
> COMPND   2 MOLECULE: PROTEIN (POTASSIUM CHANNEL PROTEIN);
> COMPND   3 CHAIN: A, B, C, D;
> COMPND   4 ENGINEERED: YES;
> COMPND   5 MUTATION: YES
>  ObjectMolecule: Read secondary structure assignments.
>  ObjectMolecule: Read crystal symmetry information.
>  CmdLoad: "1bl8.pdb" loaded as "1bl8".
> Segmentation fault


I tried also with some other Debian machines, and it seems a
contributing factor is whether the GL_RENDERER is 128 or 256 bits.

>   GL_RENDERER: Gallium 0.4 on llvmpipe (LLVM 3.8, 256 bits)


It crashes in case of 256 bits, but does not crash when 128 bit renderer
is reported.

Maybe someone else can make use of this information ?



Cheers,
   Alois

Bug#866115: [Pkg-monitoring-maintainers] Bug#866115: dist-upgrade to Stretch broke ganglia-web

[Alois Schloegl]

On 2017-06-27 15:15, Daniel Pocock wrote:
> 
> 
> On 27/06/17 14:58, Alois Schloegl wrote:
>> Package: ganglia-web
>>
>>
>> The following ganglia packages are installed:
>>
>> ganglia:~# dpkg -l|grep ganglia
>> ii  ganglia-modules-linux 1.3.6-2
>> amd64Ganglia extra modules for Linux (IO, filesystems,
>> multicpu)
>> ii  ganglia-monitor   3.6.0-7+b1
>> amd64cluster monitoring toolkit - node daemon
>> ii  ganglia-monitor-python3.6.0-7
>> all  cluster monitoring toolkit - python modules
>> ii  ganglia-webfrontend   3.6.1-3
>> all  cluster monitoring toolkit - web front-end
>> ii  libganglia1   3.6.0-7+b1
>> amd64cluster monitoring toolkit - shared libraries
>>
>>
>> After dist-upgrading from Debian 8 to Debian 9, the ganglia web
>> interface is not working anymore, it just shows this error message.
>>
>>
>> === START-OF-MESSAGE ===
>>
>> Sorry, you do not have access to this resource.
>> "); } try { $dwoo = new Dwoo($conf['dwoo_compiled_dir'],
>> $conf['dwoo_cache_dir']); } catch (Exception $e) { print "
>> There was an error initializing the Dwoo PHP Templating Engine: ".
>> $e->getMessage() . "
>>
>> The compile directory should be owned and writable by the apache user.
> 
> 
> On my system it is working, I see the following owner and permissions:
> 
> $ ls -la /var/lib/ganglia-web/dwoo/
> total 16
> drwxr-xr-x 4 www-data root 4096 Jan 22  2015 .
> drwxr-xr-x 4 root root 4096 Jan 22  2015 ..
> drwxr-xr-x 2 www-data root 4096 Apr  4  2014 cache
> drwxrwxrwx 3 www-data root 4096 Mar 16  2015 compiled
> 
>>
>>
>> Do you have any suggests for debugging this issue ?
>>
> 
> Please send the output of this command:
> 
> $ ls -la /var/lib/ganglia-web/dwoo/
> 


These permissions are the same at my machine.

ganglia:~#  ls -la /var/lib/ganglia-web/dwoo/
insgesamt 16
drwxr-xr-x 4 www-data root 4096 Jun 27 12:37 .
drwxr-xr-x 4 root root 4096 Jun 27 12:37 ..
drwxr-xr-x 2 www-data root 4096 Jul  7  2016 cache
drwxrwxrwx 3 www-data root 4096 Jul 27  2015 compiled


I tried further, purging and reinstalling ganglia-web and apache did not
help.
What solved the problem was enabling all modules with

   a2enmod
Your choices are: access_compat actions alias allowmethods asis
auth_basic auth_digest auth_form auth_kerb authn_anon authn_core
authn_dbd authn_dbm authn_file authn_socache authnz_fcgi authnz_ldap
authz_core authz_dbd authz_dbm authz_groupfile authz_host authz_owner
authz_user autoindex buffer cache cache_disk cache_socache cern_meta cgi
cgid charset_lite data dav dav_fs dav_lock dbd deflate dialup dir
dump_io echo env expires ext_filter file_cache filter gnutls headers
heartbeat heartmonitor http2 ident imagemap include info
lbmethod_bybusyness lbmethod_byrequests lbmethod_bytraffic
lbmethod_heartbeat ldap log_debug log_forensic lua macro mime mime_magic
mpm_event mpm_itk mpm_prefork mpm_worker negotiation perl php7.0 proxy
proxy_ajp proxy_balancer proxy_connect proxy_express proxy_fcgi
proxy_fdpass proxy_ftp proxy_hcheck proxy_html proxy_http proxy_http2
proxy_scgi proxy_wstunnel ratelimit reflector remoteip reqtimeout
request rewrite sed session session_cookie session_crypto session_dbd
setenvif slotmem_plain slotmem_shm socache_dbm socache_memcache
socache_shmcb speling ssl status substitute suexec unique_id userdir
usertrack vhost_alias xml2enc

and enabling all of them solved the problem.

I'm not sure which of them I really need, but suspect that there is a
missing dependency on either to php7 or gnutls module.


Thanks for considering,
   Alois

Bug#866115: dist-upgrade to Stretch broke ganglia-web

[Alois Schloegl]

Package: ganglia-web


The following ganglia packages are installed:

ganglia:~# dpkg -l|grep ganglia
ii  ganglia-modules-linux 1.3.6-2
amd64Ganglia extra modules for Linux (IO, filesystems,
multicpu)
ii  ganglia-monitor   3.6.0-7+b1
amd64cluster monitoring toolkit - node daemon
ii  ganglia-monitor-python3.6.0-7
all  cluster monitoring toolkit - python modules
ii  ganglia-webfrontend   3.6.1-3
all  cluster monitoring toolkit - web front-end
ii  libganglia1   3.6.0-7+b1
amd64cluster monitoring toolkit - shared libraries


After dist-upgrading from Debian 8 to Debian 9, the ganglia web
interface is not working anymore, it just shows this error message.


=== START-OF-MESSAGE ===

Sorry, you do not have access to this resource.
"); } try { $dwoo = new Dwoo($conf['dwoo_compiled_dir'],
$conf['dwoo_cache_dir']); } catch (Exception $e) { print "
There was an error initializing the Dwoo PHP Templating Engine: ".
$e->getMessage() . "

The compile directory should be owned and writable by the apache user.
"; exit; } # Useful for addons. $GHOME = "."; if ($context == "meta" or
$context == "control") { $title = "$self ${conf['meta_designator']}
Report"; include_once "./header.php"; include_once "./meta_view.php"; }
else if ($context == "tree") { $title = "$self
${conf['meta_designator']} Tree"; include_once "./header.php";
include_once "./grid_tree.php"; } else if ($context == "cluster" or
$context == "cluster-summary") { if (preg_match('/cluster/i',
$clustername)) $title = "$clustername Report"; else $title =
"$clustername Cluster Report"; include_once "./header.php"; include_once
"./cluster_view.php"; } else if ($context == "physical") { $title =
"$clustername Physical View"; include_once "./header.php"; include_once
"./physical_view.php"; } else if ($context == "node") { $title =
"$hostname Node View"; include_once "./header.php"; include_once
"./show_node.php"; } else if ($context == "host") { $title = "$hostname
Host Report"; include_once "./header.php"; include_once
"./host_view.php"; } else if ($context == "views") { $title = "$viewname
view"; include_once "./header.php"; include_once "./views_view.php"; }
else if ($context == "compare_hosts") { $title = "Compare Hosts";
include_once "./header.php"; include_once "./compare_hosts.php"; } else
if ($context == "decompose_graph") { $title = "Decompose graph";
include_once "./header.php"; include_once "./decompose_graph.php"; }
else { $title = "Unknown Context"; print "Unknown Context Error: Have
you specified a host but not a cluster?."; } include_once
"./footer.php"; ?>


 END ===

When searching the web, there where some hints towards a permission
problem, but changing the permissions did not help.


I also purged and reinstalled ganglia-web and the apache, but it did not
help.


Do you have any suggests for debugging this issue ?

Bug#857121: biosig4c++ FTBFS on architectures where char is unsigned

[Alois Schloegl]

This bug was fixed upstream in
   commit 8e7c3d7e485e1d3af3f3094641282274424b7385

Attaches is the corresponding patch.


Thanks for consideration,
   Alois
commit 8e7c3d7e485e1d3af3f3094641282274424b7385
Author: Christoph Schmidt-Hieber 
Date:   Sat Dec 10 16:50:41 2016 +0100

Fix compilation with gcc6 on armhf. See Debian Bug #847526

diff --git a/biosig4c++/t210/codes.h b/biosig4c++/t210/codes.h
index 4db65b2..53affbf 100644
--- a/biosig4c++/t210/codes.h
+++ b/biosig4c++/t210/codes.h
@@ -22,7 +22,7 @@ Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA  02111-1307, USA.
 #ifndef __CODES_H__
 #define __CODES_H__
 
-static const char STR_END[]={-1,'\0'};
+static const char STR_END[]={(char)-1,'\0'};
 static char STR_NULL[]=" unspecified/unknown ";
 
 static alfabetic _special[]={

Bug#847309: libthrust-dev: cub::DeviceReduce::Min causes segmentation fault

[Alois Schloegl]

Package: libthrust-dev
Version: 1.7.0
Severity: normal

Dear Maintainer,


I tried to compile and run relion 2 beta with cuda enable.
nvidia-cuda-toolkit
7.5 from debian8/backports is installed on that machine.

When testing the application, it crashed with a segmentation fault.
The issue is also filed here,

https://bitbucket.org/tcblab/relion2-beta/issues/164/seg-fault-on-relion2-with-cuda
which includes also the data we used for testing, and long investigation
of the issue.


The problem went away when the output argument was initialized with
+Infinity, and after upgrading to libthrust-dev 1.8.1.

This indicates:
1) cub::DeviceReduce::Min from libthrust-dev 1.7.0 does not user a
proper initialization, and depends  on uninitialized data.
2) the problem seems to be solved in upstream in more recent version.

w.r.t to debian, I'd like suggesting that nvidia-cuda-toolkit from
backports should require libthrust-dev from backports. That could avoid
similar problems for others.


Best regards,
   Alois



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

Kernel: Linux 3.16.0-4-amd64 (SMP w/12 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

libthrust-dev depends on no packages.

libthrust-dev recommends no packages.

Versions of packages libthrust-dev suggests:
ii  nvidia-cuda-toolkit  7.5.18-4~bpo8+1

-- no debconf information







signature.asc
Description: OpenPGP digital signature

Bug#831387: Files and directories with Umlaut do not get backed up through smb

[Alois Schloegl]

Package: backuppc
Version: 3.3.1-3
Severity: important



I'm running backuppc 3.3.1-3 (from debian/testing) on Debian/Jessie.
When trying to backup through smb files and directories with umlauts in
its name, it will not backup those files, and the content of these
directories is ignored. When trying to debug the problem, I found that
the problem occurs only when starting through the web interface. When
triggering the backup from the command line on the backup server the
problem did not occur.

root@backup2:~# dpkg -l|grep backuppc
ii  backuppc  3.3.1-3
  amd64high-performance, enterprise-grade system for backing up PCs
root@backup2:~# dpkg -l|grep smbclient
ii  libsmbclient:amd642:4.2.10+dfsg-0+deb8u3
  amd64shared library for communication with SMB/CIFS servers
ii  smbclient 2:4.2.10+dfsg-0+deb8u3
  amd64command-line SMB/CIFS clients for Unix

I'm aware of this post:
   https://sourceforge.net/p/backuppc/mailman/message/35035066/
and have set according to Oliver Freyd's posting
 LANG=en_US.UTF-8 in /etc/init.d/backuppc


I'm not sure whether this is a bug in backuppc or in the debian
packaging, so this message is posting to debian bugs and the
backuppc-users mailinglist.

I did a number of tests with various configuration options (see below),
but running the smb backup through the backuppc server fails to backup
files and directories with umlaut in its name. Does anyone know how to
fix this ?



 check LANG ##
locale is set to en_US.UTF8 for root as well as user "backuppc"


root@backup2:~# locale
LANG=en_US.UTF-8
LANGUAGE=
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=
root@backup2:~# locale^C
root@backup2:~# su -c locale backuppc
LANG=en_US.UTF-8
LANGUAGE=
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=

 Test 0: preparation ##

For testing I've set up on the windows machines some test files and
directories with Umlauts in it. So, when I do

  CLIENTHOST=mywindowsmachine.local
  su -c "smbclient //$CLIENTHOST/C$ -W IST -k -D
/Users/schloegl/test.backuppc -c -E -d 5 -c tarmode full -TcX -
\BOOTSECT.BAK "   backuppc >t5.tar
  tar xvf t5.tar

und run
#   find Users/
  Users/
  Users/schloegl
  Users/schloegl/test.backuppc
  Users/schloegl/test.backuppc/withUmlautÖtest
  Users/schloegl/test.backuppc/withUmlautÖtest/test..001.txt
  Users/schloegl/test.backuppc/withUmlautÖtest/testÖ.001.txt
  Users/schloegl/test.backuppc/noUmlaut
  Users/schloegl/test.backuppc/noUmlaut/test..001.txt
  Users/schloegl/test.backuppc/noUmlaut/testÖ.001.txt

# cat Users/schloegl/test.backuppc/withUmlautÖtest/testÖ.001.txt
test
test

which is fine, all other files test*.txt have the same content.


 Test 4: Triggering the backup from the web interface
##

htop shows these processes:

0 0 0   5  4793 backuppc   20   0 65632 15980  3156 S  0.0
0.0  0:00.04 ├─ /usr/bin/perl /usr/share/backuppc/bin/BackupPC -d
 60.4 0  60.4  13  5145 backuppc   20   0 82932 26176  4380 S  7.1
0.1  0:00.89 │  ├─ /usr/bin/perl /usr/share/backuppc/bin/BackupPC_dump
-f mywindowsmachine.local
0 0 0   7  5149 backuppc   20   0  231M 12932 10708 R 20.9
0.0  0:02.81 │  │  ├─ /usr/bin/smbclient //w7test012.ist.local/C$ -W IST
-k -N -E -d 5 -c tarmode full verbose -Tc - /Users/schloegl
35010   239 34771   8  5148 backuppc   20   0 64368 17460  4100 D 41.7
0.0  0:04.61 │  │  └─ /usr/bin/perl
/usr/share/backuppc/bin/BackupPC_tarExtract mywindowsmachine.local C$ 0
0 0 0  11  4796 backuppc   30  10 46460 10048  3812 S  0.0
0.0  0:00.07 │  └─ /usr/bin/perl /usr/share/backuppc/bin/BackupPC_trashClean

And the files on the backup server are:

cat `ls -1td /var/lib/backuppc/pc/$CLIENTHOST/*/|head
-1`fC\$/fUsers/fschloegl/ftest.backuppc/fwithUmlautÖtest/ftestÖ.001.txt
cat:
/var/lib/backuppc/pc/w7test012.ist.local/111/fC$/fUsers/fschloegl/ftest.backuppc/fwithUmlautÖtest/ftestÖ.001.txt:
No such file or directory
root@backup2:~#
root@backup2:~# find `ls -1td /var/lib/backuppc/pc/$CLIENTHOST/*/|head
-1`fC\$/fUsers/fschloegl/ftest.backuppc
/var/lib/backuppc/pc/w7test012.ist.local/111/fC$/fUsers/fschloegl/ftest.backuppc
/var/lib/backuppc/pc/w7test012.ist.local/111/fC$/fUsers/fschloegl/ftest.backuppc/fnoUmlaut
ca
/var/lib/backuppc/pc/w7test012.ist.local/111/fC$/fUsers/fschloegl/ftest.backuppc/fnoUmlaut/fPaxHeader

Bug#816283: NVRM: API mismatch on cuda/jessie-backports

[Alois Schloegl]

On 2016-03-31 20:30, Luca Boccassi wrote:
> On Thu, 2016-03-31 at 18:23 +0200, Alois Schloegl wrote:
>> At the beginning, I used the .run installer, but thought to have cleaned
>> this up. Obviously, this was not the case. The are a few more files
>> installed on Sep 10 (mostly symbolic links). I've removed those and
>> reinstalled nvidia-smi. That fixed the problem.
>>
>>
>> Thanks a lot for the hint.
> 
> Hello Alois,
> 
> Are you happy with the result? Is it working fine now? If so, may I
> close this bug now?
> 
> Kind regards,
> Luca Boccassi
> 


Yes, thank you. The bug can be closed.

Best,
  Alois

Bug#816283: NVRM: API mismatch on cuda/jessie-backports

[Alois Schloegl]

On 03/31/2016 04:12 PM, Andreas Beckmann wrote:
> On 2016-03-31 11:46, Alois Schloegl wrote:
>> I'm trying to get Cuda working on debian/jessie. When running
>> nvidia-smi, dmesg shows this message:
>>
>> [ 2355.945623] NVRM: API mismatch: the client has the version 352.41, but
>> NVRM: this kernel module has the version 352.79.  Please
>> NVRM: make sure that this kernel module and all NVIDIA driver
>> NVRM: components have the same version.
>> [ 2355.970347] NVRM: nvidia_frontend_ioctl: minor 255, module->ioctl
>> failed, error -22
>>
>> Any ideas, where this client with version 352.41 comes from, and how to
>> fix this ?
> 
> We had 352.41-1 in experimental ... or did you install that driver from
> the .run installer?
> 
> This "client" is an old library ... try
> 
>   strace -e open nvidia-smi
> 
> to see which library is is openening and then see where this is
> pointing, it's probably /usr/lib/x86_64-linux-gnu/libnvidia-ml.so.1
> being incorrect in some way.


Yes, you are right. The are actually a bunch of other library files

# ls -atlr /usr/lib/x86_64-linux-gnu/lib*352*
-rwxr-xr-x 1 root root75400 Sep 10  2015
/usr/lib/x86_64-linux-gnu/libGLESv2.so.352.41
-rwxr-xr-x 1 root root51080 Sep 10  2015
/usr/lib/x86_64-linux-gnu/libGLESv1_CM.so.352.41
-rwxr-xr-x 1 root root   935112 Sep 10  2015
/usr/lib/x86_64-linux-gnu/libEGL.so.352.41
-rwxr-xr-x 1 root root   166848 Sep 10  2015
/usr/lib/x86_64-linux-gnu/libnvidia-encode.so.352.41
-rwxr-xr-x 1 root root 14280360 Sep 10  2015
/usr/lib/x86_64-linux-gnu/libcuda.so.352.41
-rwxr-xr-x 1 root root 15898960 Sep 10  2015
/usr/lib/x86_64-linux-gnu/libnvidia-opencl.so.352.41
-rwxr-xr-x 1 root root   159240 Sep 10  2015
/usr/lib/x86_64-linux-gnu/libnvidia-cfg.so.352.41
-rwxr-xr-x 1 root root  1652272 Sep 10  2015
/usr/lib/x86_64-linux-gnu/libnvcuvid.so.352.41
-rwxr-xr-x 1 root root   197704 Sep 10  2015
/usr/lib/x86_64-linux-gnu/libnvidia-ifr.so.352.41
-rwxr-xr-x 1 root root86088 Sep 10  2015
/usr/lib/x86_64-linux-gnu/libnvidia-fbc.so.352.41
-rwxr-xr-x 1 root root   967360 Sep 10  2015
/usr/lib/x86_64-linux-gnu/libnvidia-ml.so.352.41
-rwxr-xr-x 1 root root  1790568 Sep 10  2015
/usr/lib/x86_64-linux-gnu/libnvidia-gtk2.so.352.41
-rwxr-xr-x 1 root root  1784456 Sep 10  2015
/usr/lib/x86_64-linux-gnu/libnvidia-gtk3.so.352.41
-rw-r--r-- 1 root root 42469400 Jan 14 00:53
/usr/lib/x86_64-linux-gnu/libnvidia-glcore.so.352.79
-rw-r--r-- 1 root root12600 Jan 14 00:58
/usr/lib/x86_64-linux-gnu/libnvidia-tls.so.352.79
-rw-r--r-- 1 root root   486048 Jan 14 02:05
/usr/lib/x86_64-linux-gnu/libnvidia-glsi.so.352.79
-rw-r--r-- 1 root root75400 Jan 14 02:19
/usr/lib/x86_64-linux-gnu/libGLESv2.so.352.79
-rw-r--r-- 1 root root51080 Jan 14 02:19
/usr/lib/x86_64-linux-gnu/libGLESv1_CM.so.352.79
-rw-r--r-- 1 root root   935112 Jan 14 02:19
/usr/lib/x86_64-linux-gnu/libEGL.so.352.79
-rw-r--r-- 1 root root 40648712 Jan 14 02:19
/usr/lib/x86_64-linux-gnu/libnvidia-eglcore.so.352.79
-rw-r--r-- 1 root root 48309464 Jan 14 02:20
/usr/lib/x86_64-linux-gnu/libnvidia-compiler.so.352.79


At the beginning, I used the .run installer, but thought to have cleaned
this up. Obviously, this was not the case. The are a few more files
installed on Sep 10 (mostly symbolic links). I've removed those and
reinstalled nvidia-smi. That fixed the problem.


Thanks a lot for the hint.




















signature.asc
Description: OpenPGP digital signature

Bug#816283: nvidia-cuda-toolkit: cuda broken after upgrade (x86_64, Jessie, GTX980)

[Alois Schloegl]

In order to fix the installation of glx-alternative-nvidia, and fix some
other cuda related issues, I tried to update cuda to jessie-backports.
The update did not work out of the box, e.g

After uninstalling nvidia-cuda and reinstallung with
   apt-get -t jessie-backports install nvidia-cuda-toolkit,
there were still problems


nvidia-smi fails with this message
Failed to initialize NVML: GPU access blocked by the operating system

dmesg shows "API mismatch: the client has the version 352.41".


After the update, I noticed that the link pointed to
  /usr/lib/x86_64-linux-gnu/libEGL.so.1 -> libEGL.so.352.41

and
  dpkg -i libegl1-nvidia_352.79-1~bpo8+1_amd64.deb
did not fix this, so manual extracted
  /usr/lib/x86_64-linux-gnu/libEGL.so.352.79
and set the above link to it.




dmesg shows "API mismatch: the client has the version 352.41". The
details are:


# dmesg |grep -i "nvid\|nvrm"
[   16.782287] nvidia: module license 'NVIDIA' taints kernel.
[   16.813559] nvidia :03:00.0: enabling device ( -> 0003)
[   16.829365] nvidia :82:00.0: enabling device ( -> 0003)
[   16.845105] nvidia :83:00.0: enabling device ( -> 0003)
[   16.861001] [drm] Initialized nvidia-drm 0.0.0 20150116 for
:02:00.0 on minor 0
[   16.868905] [drm] Initialized nvidia-drm 0.0.0 20150116 for
:03:00.0 on minor 1
[   16.876789] [drm] Initialized nvidia-drm 0.0.0 20150116 for
:82:00.0 on minor 2
[   16.884678] [drm] Initialized nvidia-drm 0.0.0 20150116 for
:83:00.0 on minor 3
[   16.892467] NVRM: loading NVIDIA UNIX x86_64 Kernel Module  352.79
Wed Jan 13 16:17:53 PST 2016
[   18.702943] input: HDA NVidia HDMI/DP,pcm=3 as
/devices/pci:80/:80:02.0/:82:00.1/sound/card2/input7
[   18.711066] input: HDA NVidia HDMI/DP,pcm=3 as
/devices/pci:00/:00:02.0/:02:00.1/sound/card0/input8
[   18.711188] input: HDA NVidia HDMI/DP,pcm=7 as
/devices/pci:00/:00:02.0/:02:00.1/sound/card0/input12
[   18.711330] input: HDA NVidia HDMI/DP,pcm=8 as
/devices/pci:00/:00:02.0/:02:00.1/sound/card0/input17
[   18.711668] input: HDA NVidia HDMI/DP,pcm=9 as
/devices/pci:00/:00:02.0/:02:00.1/sound/card0/input21
[   18.754668] input: HDA NVidia HDMI/DP,pcm=7 as
/devices/pci:80/:80:02.0/:82:00.1/sound/card2/input11
[   18.766633] input: HDA NVidia HDMI/DP,pcm=3 as
/devices/pci:80/:80:03.0/:83:00.1/sound/card3/input6
[   18.767994] input: HDA NVidia HDMI/DP,pcm=3 as
/devices/pci:00/:00:03.0/:03:00.1/sound/card1/input9
[   18.770893] input: HDA NVidia HDMI/DP,pcm=7 as
/devices/pci:00/:00:03.0/:03:00.1/sound/card1/input13
[   18.771620] input: HDA NVidia HDMI/DP,pcm=8 as
/devices/pci:00/:00:03.0/:03:00.1/sound/card1/input16
[   18.771805] input: HDA NVidia HDMI/DP,pcm=9 as
/devices/pci:00/:00:03.0/:03:00.1/sound/card1/input20
[   18.820540] input: HDA NVidia HDMI/DP,pcm=8 as
/devices/pci:80/:80:02.0/:82:00.1/sound/card2/input14
[   18.832036] input: HDA NVidia HDMI/DP,pcm=9 as
/devices/pci:80/:80:02.0/:82:00.1/sound/card2/input19
[   18.843980] input: HDA NVidia HDMI/DP,pcm=7 as
/devices/pci:80/:80:03.0/:83:00.1/sound/card3/input10
[   18.855326] input: HDA NVidia HDMI/DP,pcm=8 as
/devices/pci:80/:80:03.0/:83:00.1/sound/card3/input15
[   18.867117] input: HDA NVidia HDMI/DP,pcm=9 as
/devices/pci:80/:80:03.0/:83:00.1/sound/card3/input18
[  731.363046] NVRM: API mismatch: the client has the version 352.41, but
NVRM: this kernel module has the version 352.79.  Please
NVRM: make sure that this kernel module and all NVIDIA driver
NVRM: components have the same version.
[  731.387767] NVRM: nvidia_frontend_ioctl: minor 255, module->ioctl
failed, error -22


Here is the list of current packages:


# dpkg -l|grep -i nvidia
ii  glx-alternative-nvidia 0.7.1~bpo8+1
amd64allows the selection of NVIDIA as GLX provider
ii  libcublas6.5:amd64 6.5.19-3~bpo8+1
amd64NVIDIA cuBLAS Library
ii  libcuda1:amd64 352.79-1~bpo8+1
amd64NVIDIA CUDA Driver Library
ii  libcudart6.5:amd64 6.5.19-3~bpo8+1
amd64NVIDIA CUDA Runtime Library
ii  libcufft6.5:amd64  6.5.19-3~bpo8+1
amd64NVIDIA cuFFT Library
ii  libcufftw6.5:amd64 6.5.19-3~bpo8+1
amd64NVIDIA cuFFTW Library
ii  libcuinj64-6.5:amd64   6.5.19-3~bpo8+1
amd64NVIDIA CUINJ Library (64-bit)
ii  libcurand6.5:amd64 6.5.19-3~bpo8+1
amd64NVIDIA cuRAND Library
ii  libcusparse6.5:amd64   6.5.19-3~bpo8+1
amd64NVIDIA cuSPARSE Library
ii  libegl1-nvidia:amd64   352.79-1~bpo8+1
amd64NVIDIA binary EGL libraries
ii  libgl1-nvidia-glx:amd64352.79-1~bpo8+1
amd64

Bug#816283: nvidia-cuda-toolkit: cuda broken after upgrade (x86_64, Jessie, GTX980)

[Alois Schloegl]

I was able to revert to a working state of cuda 6.5, by using dpkg -i
and the packges in /var/cache/apt/archives. Below are the output of
nvidia-smi and the gpuinfo test program.

The package list is attached in "pkglist.nvidia.working.txt".
Configuration of glx-alternative-nvidia failed with this message.

-- begin --
Processing triggers for glx-alternative-nvidia (0.7.1) ...
update-alternatives: error: alternative link /etc/modprobe.d/nvidia.conf
is already managed by nvidia
dpkg: error processing package glx-alternative-nvidia (--configure):
 subprocess installed post-installation script returned error exit status 2
Errors were encountered while processing:
 glx-alternative-nvidia
E: Sub-process /usr/bin/dpkg returned an error code (1)
-- end --

So, this issue is affected by #801952 [1], as well.

When upgrading to testing or backports, nvidia-driver 352.79-3 and some
other cuda dependancies are pulled in, which break cuda (package list
ist attached). Now, when looking at the package list, it seems more a
problem of nvidia-driver and not cuda. However, [2] says that 352.79
supports gtx980.

Currently, I'm suspecting a problem with the kernel module nvidia-uvm [3].



[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=801952
[2] http://www.nvidia.com/download/driverResults.aspx/97645/en-us
[3]
https://www.phoronix.com/scan.php?page=news_item=NVIDIA-New-Build-System






- output of test programs -


nvidia-smi shows this:


+--+

| NVIDIA-SMI 352.41 Driver Version: 352.41 |

|---+--+--+
| GPU  NamePersistence-M| Bus-IdDisp.A | Volatile
Uncorr. ECC |
| Fan  Temp  Perf  Pwr:Usage/Cap| Memory-Usage | GPU-Util
Compute M. |
|===+==+==|
|   0  GeForce GTX 980 Off  | :02:00.0 Off |
  N/A |
| 26%   28CP046W / 180W | 15MiB /  4095MiB |  0%
Default |
+---+--+--+
|   1  GeForce GTX 980 Off  | :03:00.0 Off |
  N/A |
| 26%   29CP045W / 180W | 15MiB /  4095MiB |  0%
Default |
+---+--+--+
|   2  GeForce GTX 980 Off  | :82:00.0 Off |
  N/A |
| 26%   28CP042W / 180W | 15MiB /  4095MiB |  0%
Default |
+---+--+--+
|   3  GeForce GTX 980 Off  | :83:00.0 Off |
  N/A |
|  0%   30CP033W / 180W | 15MiB /  4095MiB |  0%
Default |
+---+--+--+


+-+
| Processes:   GPU
Memory |
|  GPU   PID  Type  Process name   Usage
 |
|=|
|  No running processes found
  |
+-+


and "../bin/gpuinfo" gives:

Simple GPU info query.

You have 4 nVidia GPGPU.

DeviceID NameVersion Memory(Mb)
#0   GeForce GTX 980 5.2 4095
#1   GeForce GTX 980 5.2 4095
#2   GeForce GTX 980 5.2 4095
#3   GeForce GTX 980 5.2 4095

Wrote by Xueming Li @ Yifan Cheng Lab, UCSF









ii  glx-alternative-nvidia 0.7.1
amd64allows the selection of NVIDIA as GLX provider
ii  libcublas6.5:amd64 6.5.19-3 
amd64NVIDIA cuBLAS Library
rc  libcuda1:amd64 352.41-1 
amd64NVIDIA CUDA Driver Library
ii  libcudart6.5:amd64 6.5.19-3 
amd64NVIDIA CUDA Runtime Library
ii  libcufft6.5:amd64  6.5.19-3 
amd64NVIDIA cuFFT Library
ii  libcufftw6.5:amd64 6.5.19-3 
amd64NVIDIA cuFFTW Library
ii  libcurand6.5:amd64 6.5.19-3 
amd64NVIDIA cuRAND Library
ii  libcusparse6.5:amd64   6.5.19-3 
amd64NVIDIA cuSPARSE Library
ii  libegl1-nvidia:amd64   352.79-3 
amd64NVIDIA binary EGL libraries
ii  libgl1-nvidia-glx:amd64352.79-3 
amd64NVIDIA binary OpenGL libraries
ii  libgles1-nvidia:amd64  352.79-3 
amd64NVIDIA binary OpenGL|ES 1.x libraries
ii  libgles2-nvidia:amd64  352.79-3   

Bug#816283: nvidia-cuda-toolkit: cuda broken after upgrade (x86_64, Jessie, GTX980)

[Alois Schloegl]

On 2016-02-29 16:08, lumin wrote:
> Hi,
> 
> Thank you for reporting this bug.
> 
> It seems like a GCC ABI issue, rather than that of CUDA
> or nvidia-driver.
> If the nvidia-driver package ships binary then they are
> linked by GCC-5, which requires an different ABI to
> the one of Jessie. Hence installing stuff from unstable
> into Jessie may basically introduce ABI-broken ELFs.
> If the truth lies there, this bug cannot be fixed.
> And my advise is 1. try unstable 2. install nvidia stuff
> 
> Does this bug appear in version 7.0.28-3 or some former version?
> or is this the first time you trying to install these stuff from
> unstable into stable?



Before trying to upgrade, I was on
   nvidia-driver 352.41
   nvidia-cuda-toolkit 6.5.19
from debian/testing. This was working.

Now, I'm on
   nvidia-driver 352.79-4
   nvidia-cuda-toolkit 7.0.28-4
from debian/unstable.

This machine is part of a larger compute cluster, and I'd prefer to
stick with Jessie, if possible.

If your theory about incompatible ABI's is correct, it would not help
installing "nvidia stuff", because the ABI would still be incompatible.

Attached is the list of installed nvidia packages obtained with
dpkg -l|grep -i nvidia

Thanks,
   Alois




> 
> Thanks :-)
> 

ii  glx-alternative-nvidia 0.7.1
amd64allows the selection of NVIDIA as GLX provider
rc  libcublas6.5:amd64 6.5.19-3~bpo8+1  
amd64NVIDIA cuBLAS Library
ii  libcublas7.0:amd64 7.0.28-4 
amd64NVIDIA cuBLAS Library
ii  libcuda1:amd64 352.79-4 
amd64NVIDIA CUDA Driver Library
rc  libcudart6.5:amd64 6.5.19-3~bpo8+1  
amd64NVIDIA CUDA Runtime Library
ii  libcudart7.0:amd64 7.0.28-4 
amd64NVIDIA CUDA Runtime Library
rc  libcufft6.5:amd64  6.5.19-3~bpo8+1  
amd64NVIDIA cuFFT Library
ii  libcufft7.0:amd64  7.0.28-4 
amd64NVIDIA cuFFT Library
rc  libcufftw6.5:amd64 6.5.19-3~bpo8+1  
amd64NVIDIA cuFFTW Library
ii  libcufftw7.0:amd64 7.0.28-4 
amd64NVIDIA cuFFTW Library
rc  libcuinj64-6.5:amd64   6.5.19-3~bpo8+1  
amd64NVIDIA CUINJ Library (64-bit)
ii  libcuinj64-7.0:amd64   7.0.28-4 
amd64NVIDIA CUINJ Library (64-bit)
rc  libcurand6.5:amd64 6.5.19-3~bpo8+1  
amd64NVIDIA cuRAND Library
ii  libcurand7.0:amd64 7.0.28-4 
amd64NVIDIA cuRAND Library
ii  libcusolver7.0:amd64   7.0.28-4 
amd64NVIDIA cuSOLVER Library
rc  libcusparse6.5:amd64   6.5.19-3~bpo8+1  
amd64NVIDIA cuSPARSE Library
ii  libcusparse7.0:amd64   7.0.28-4 
amd64NVIDIA cuSPARSE Library
ii  libegl1-nvidia:amd64   352.79-4 
amd64NVIDIA binary EGL libraries
ii  libgl1-nvidia-glx:amd64352.79-4 
amd64NVIDIA binary OpenGL libraries
ii  libgles1-nvidia:amd64  352.79-4 
amd64NVIDIA binary OpenGL|ES 1.x libraries
ii  libgles2-nvidia:amd64  352.79-4 
amd64NVIDIA binary OpenGL|ES 2.x libraries
rc  libnppc6.5:amd64   6.5.19-3~bpo8+1  
amd64NVIDIA Performance Primitives core runtime library
ii  libnppc7.0:amd64   7.0.28-4 
amd64NVIDIA Performance Primitives core runtime library
rc  libnppi6.5:amd64   6.5.19-3~bpo8+1  
amd64NVIDIA Performance Primitives for image processing runtime library
ii  libnppi7.0:amd64   7.0.28-4 
amd64NVIDIA Performance Primitives for image processing runtime library
rc  libnpps6.5:amd64   6.5.19-3~bpo8+1  
amd64NVIDIA Performance Primitives for signal processing runtime library
ii  libnpps7.0:amd64   7.0.28-4 
amd64NVIDIA Performance Primitives for signal processing runtime library
ii  libnvidia-compiler:amd64   352.79-4 
amd64NVIDIA runtime compiler library
ii  libnvidia-eglcore:amd64352.79-4 
amd64NVIDIA binary EGL core libraries
ii  

Bug#816283: nvidia-cuda-toolkit: cuda broken after upgrade (x86_64, Jessie, GTX980)

[Alois Schloegl]

Package: nvidia-cuda-toolkit
Version: 7.0.28-4
Severity: important

Dear Maintainer,



I tried to upgrade the nvidia-drivers from 352.41-1
to  the current version "352.79-3" and nvidia-cuda-toolkit to a matching
version, cuda became unusable. Rebooting the machine did not help.

I used the following two tests.

First, nvidia-smi reports this error:

  # nvidia-smi
  Failed to initialize NVML: GPU access blocked by the operating system

Second, I do have a short cuda program from here
https://github.com/leschzinerlab/Motion-correction.git
and can be installed with the following commands

git clone https://github.com/leschzinerlab/Motion-correction.git
cd Motion-correction/motioncorr_v2.1/src/
make -B
../bin/gpuinfo

The compilation works without problems, but running the command
 ../bin/gpuinfo
results in this message:

Simple GPU info query.

You have 32720 nVidia GPGPU.

DeviceID NameVersion Memory(Mb)
Failed to get GPU info of Device #0
Failed to get GPU info of Device #1
Failed to get GPU info of Device #2
Failed to get GPU info of Device #3
...
Failed to get GPU info of Device #32568
Failed to get GPU info of Device #32569
Failed to get GPU info of Device #32570
Failed to get GPU info of Device #32571


I tried a number of additional things, like using the packages in
jessie-backports, and  nvidia-cuda 7.0 from debian/unstable. None of
these attempts solved the issue.


Best,
   Alois



-- System Information:
Debian Release: 8.3
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'unstable'), (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 3.16.0-4-amd64 (SMP w/12 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages nvidia-cuda-toolkit depends on:
ii  g++-4.8  4.8.4-1
ii  g++-4.9  4.9.2-10
ii  gcc-4.8  4.8.4-1
ii  gcc-4.9  4.9.2-10
ii  libc62.19-18+deb8u3
ii  libgcc1  1:5.3.1-8
ii  libnvvm3 7.0.28-4
ii  libstdc++6   5.3.1-8
ii  nvidia-cuda-dev  7.0.28-4
ii  nvidia-profiler  7.0.28-4
ii  ocl-icd-opencl-dev [opencl-dev]  2.2.3-1+deb8u1

Versions of packages nvidia-cuda-toolkit recommends:
ii  nvidia-cuda-doc 7.0.28-4
ii  nvidia-cuda-gdb 7.0.28-4
pn  nvidia-visual-profiler  

Versions of packages nvidia-cuda-toolkit suggests:
pn  libcupti-dev   
ii  nvidia-driver  352.79-4

-- no debconf information

Bug#807016: octave-plplot: toggle_plplot_use is broken on Jessie

[Alois Schloegl]

Package: octave-plplot
Version: 5.10.0+dfsg-1
Severity: normal
Tags: patch



I've tryied to use plplot from Octave on Jessie. Octave and
octave-plplot are installed. Starting octave and running
"toggle_plplot_use cases the following problem:


octave:1> use_plplot
This function is deprecated.  Use toggle_plplot_use instead.
octave:2> toggle_plplot_use
error: sq_string cannot be indexed with {
error: evaluating argument list element number 1
error: called from:
error:   /usr/share/octave/site/m/PLplot/toggle_plplot_use.m at line 42,
column 3


Attached are to possible patches, each of them works on Octave 3.8.

patch_fix2_toggle_plplot_use.diff seems shorter and more elegant, though
I did not check compatibility with older versions of Octave.


Best regards,
  Alois



-- System Information:
Debian Release: 8.2
  APT prefers stable
  APT policy: (990, 'stable'), (80, 'testing'), (50, 'unstable'), (40,
'experimental')
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 octave-plplot depends on:
ii  libc62.19-18+deb8u1
ii  libgcc1  1:5.1.1-14
ii  liboctave2   3.8.2-4
ii  libplplot12  5.10.0+dfsg-1
ii  libstdc++6   5.1.1-14
ii  octave   3.8.2-4

octave-plplot recommends no packages.

octave-plplot suggests no packages.

-- no debconf information


--- toggle_plplot_use.orig.m	2015-12-04 08:38:15.728228972 +0100
+++ toggle_plplot_use1.m	2015-12-04 08:39:37.018874374 +0100
@@ -39,7 +39,7 @@
 use_plplot_path = plplot_octave_path;
 plplot_path_to_remove = char(strsplit(genpath(use_plplot_path),pathsep));
 for use_plplot_i=1:size(plplot_path_to_remove)(1)
-  rmpath(plplot_path_to_remove{use_plplot_i});
+  rmpath(strtrim(plplot_path_to_remove(use_plplot_i,:)));
 endfor
 
 if (strcmp (use_plplot_state, "on"))
--- toggle_plplot_use.orig.m	2015-12-04 08:38:15.728228972 +0100
+++ toggle_plplot_use2.m	2015-12-04 08:37:18.766375290 +0100
@@ -37,7 +37,7 @@
 endif
 
 use_plplot_path = plplot_octave_path;
-plplot_path_to_remove = char(strsplit(genpath(use_plplot_path),pathsep));
+plplot_path_to_remove = strsplit(genpath(use_plplot_path),pathsep);
 for use_plplot_i=1:size(plplot_path_to_remove)(1)
   rmpath(plplot_path_to_remove{use_plplot_i});
 endfor

Bug#742503: [Pkg-octave-devel] Bug#742503: octave 3.8.1 requires java

[Alois Schloegl]

On 2015-07-16 07:00, Mike Miller wrote:
 On Wed, Jul 15, 2015 at 08:59:32 -0400, Mike Miller wrote:
 On Wed, Jul 15, 2015 at 10:00:33 +0200, Alois Schloegl wrote:
 Octave should not have a strong dependency on openjdk. Any of the
 following solutions would do:
 1) the dependency should be changed to recommended, and/or
 2) it should allow for some alternative java engine (e.g. gcj or
 whatever). (see also [4] ),
 3) keeping the java dependency in a octave package octave-java as it
 was before 3.8.x

 Before #1 or #3 are feasible, some upstream work will need to be done to
 allow Octave to detect the (presence of / version of / path to) JRE at
 runtime. Please see upstream bug #40111.
 
 Minor clarification: currently, when Octave is compiled with Java
 support but the JRE is not actually present, the error is handled and
 reported:
 
   octave:1 javaMethod (getRuntime, java.lang.Runtime)
   error: javaMethod: 
 /usr/lib/jvm/java-7-openjdk-amd64/jre/lib/amd64/server/libjvm.so: failed to 
 load: /usr/lib/jvm/java-7-openjdk-amd64/jre/lib/amd64/server/libjvm.so: 
 cannot open shared object file: No such file or directory
   octave:2 
 
 So Octave does handle this to some degree. The error reporting is not
 ideal and could be improved as part of #40111. But it does look feasible
 to be able to run Octave without a JRE. Users who opt out of installing
 default-jre-headless will see errors like the above if they try to use
 java functions, or functions that rely on java such as those in the
 octave-io package.
 
 Thoughts?
 


I changed the control file in the debian package (see attachments).

default-jre-headless is now not in Depends but in Build-Depends and
Recommends. The resulting octave-debian packages does the job.

In case somebody wants to use the java-interface, the above error
message seems good enough.

Please consider repackaging Octave with the modified control file.


Alois

















--- octave-3.8.4.deb/DEBIAN/control.orig	2015-07-16 09:11:00.860280895 +0200
+++ octave-3.8.4/DEBIAN/control	2015-07-16 09:38:50.716915697 +0200
@@ -1,10 +1,11 @@
 Package: octave
 Version: 3.8.2-4
-Architecture: arm64
+Architecture: amd64
 Maintainer: Debian Octave Group pkg-octave-de...@lists.alioth.debian.org
-Installed-Size: 3327
-Depends: libamd2.3.1, libarpack2 (= 2.1), libblas3 | libblas.so.3, libc6 (= 2.17), libcamd2.3.1, libccolamd2.8.0, libcholmod2.1.2, libcolamd2.8.0, libcxsparse3.1.2, libfftw3-double3, libfftw3-single3, libfltk-gl1.3 (= 1.3.0), libfltk1.3 (= 1.3.1), libfontconfig1 (= 2.11), libfreetype6 (= 2.2.1), libgcc1 (= 1:4.7), libgl1-mesa-glx | libgl1, libglpk36 (= 4.51), libglu1-mesa | libglu1, libgomp1 (= 4.2.1), libgraphicsmagick++3, libgraphicsmagick3 (= 1.3.5), liblapack3 | liblapack.so.3, liboctave2 (= 3.8.2-4), libqhull6 (= 2012.1), libqrupdate1 (= 1.0), libqscintilla2-11, libqt4-network (= 4:4.5.3), libqtcore4 (= 4:4.7.0~beta1), libqtgui4 (= 4:4.8.0), libstdc++6 (= 4.9), libumfpack5.6.2, libx11-6, texinfo, octave-common (= 3.8.2-4), default-jre-headless
-Recommends: gnuplot-x11 | gnuplot-qt, libopenblas-base | libatlas3-base, pstoedit
+Installed-Size: 3497
+Build-Depends: default-jre-headless
+Depends: libamd2.3.1, libarpack2 (= 2.1), libblas3 | libblas.so.3, libc6 (= 2.14), libcamd2.3.1, libccolamd2.8.0, libcholmod2.1.2, libcolamd2.8.0, libcxsparse3.1.2, libfftw3-double3, libfftw3-single3, libfltk-gl1.3 (= 1.3.0), libfltk1.3 (= 1.3.1), libfontconfig1 (= 2.11), libfreetype6 (= 2.2.1), libgcc1 (= 1:4.1.1), libgl1-mesa-glx | libgl1, libglpk36 (= 4.51), libglu1-mesa | libglu1, libgomp1 (= 4.2.1), libgraphicsmagick++3, libgraphicsmagick3 (= 1.3.5), liblapack3 | liblapack.so.3, liboctave2 (= 3.8.2-4), libqhull6 (= 2012.1), libqrupdate1 (= 1.0), libqscintilla2-11, libqt4-network (= 4:4.5.3), libqtcore4 (= 4:4.7.0~beta1), libqtgui4 (= 4:4.8.0), libstdc++6 (= 4.9), libumfpack5.6.2, libx11-6, texinfo, octave-common (= 3.8.2-4)
+Recommends: gnuplot-x11 | gnuplot-qt, libopenblas-base | libatlas3-base, pstoedit, default-jre-headless
 Suggests: octave-info, octave-doc, octave-htmldoc
 Conflicts: octave-java, octave3.2
 Breaks: dynare (= 4.4.1-1), libsbml5-octave (= 5.8.0-2), octave-audio (= 1.1.4-4), octave-biosig (= 1.3.0-2+b1), octave-communications (= 1.2.0-1), octave-control (= 2.6.2-1), octave-econometrics (= 1:1.1.1-2), octave-fixed (= 0.7.10-5+b1), octave-gdf (= 0.1.2-2+b1), octave-general (= 1.3.2-2), octave-geometry (= 1.7.0-1), octave-gmt (= 4.5.11-1), octave-gsl (= 1.0.8-5), octave-image (= 2.0.0-3), octave-io ( 1.3), octave-java (= 1.2.9-2), octave-lhapdf (= 5.9.1-3), octave-linear-algebra (= 2.2.0-1), octave-miscellaneous (= 1.2.0-2), octave-mpi (= 1.1.1-1), octave-nan (= 2.5.9-1), octave-nlopt (= 2.4.1+dfsg-1), octave-nurbs (= 1.3.7-1), octave-ocs (= 0.1.3-1), octave-octcdf (= 1.1.6-1), octave-octgpr (= 1.2.0-3), octave-odepkg (= 0.8.4-1), octave-openmpi-ext (= 1.1.0-2), octave-optim (= 1.2.2-2), octave-optiminterp (= 0.3.4-1), octave-parallel (= 2.2.0-1), octave-pfstools (= 1.8.5-1

Bug#742503: [Pkg-octave-devel] Bug#742503: octave 3.8.1 requires java

[Alois Schloegl]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256



Recently, I tried to remove openjdk-[6-8] from a number of machines
because of the large number of open security issues with openjdk
(currently there are 23, 21 and 20 open security issues on openjdk-6,
openjdk-7, and openjdk-8, resp.). I learned that due to some package
dependencies, octave gets removed too. That's not desired.

Octave should not have a strong dependency on openjdk. Any of the
following solutions would do:
1) the dependency should be changed to recommended, and/or
2) it should allow for some alternative java engine (e.g. gcj or
whatever). (see also [4] ),
3) keeping the java dependency in a octave package octave-java as it
was before 3.8.x


   Alois



[1] https://security-tracker.debian.org/tracker/source-package/openjdk-6
[2] https://security-tracker.debian.org/tracker/source-package/openjdk-7
[3] https://security-tracker.debian.org/tracker/source-package/openjdk-8
[4]
https://lists.alioth.debian.org/pipermail/pkg-octave-devel/2013-December
/010469.html




-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJVphMhAAoJEBdbD2J3nb+MIMsH/2oevdIY3lJsIrLpna49mKcj
zQo1Mc3zunsEZWLG8R+FyezLUrhnS0zeAIsjVSFbk3UznqaBuAgic+PjOE5uJDoU
DvkC8pi81VDIHvycIsNiHhaKXdxtmTZIVf24b3lIWB+N/18STqP9SzjByu4klLXR
pwG2Uq32cbbyWPm/xwSnQMew/5dWd8tEdsDaGGn1yD2pneiv2g4DbVSiVtGgEoBA
b7b66vLVwFH9jHXbzxRhaLU3Gbntk8KX2/F2YHjtGGjaM/GUQ7aEC1R0UTSfXfnM
/fpNkWhFmZW+CPFN2gmo7sU0xJqSTkU0tDLTE9FlO2KEuIAQjarFITVb0Fl7+mQ=
=ApCl
-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#698286: incorrect value for max vmem is reported : possible fix

[Alois Schloegl]

The attached patch should address this issue. The patch is essentially this

commit af73e397da01a4f70c01387f284e87262e42e7a3
Author: Dave Love d.l...@liverpool.ac.uk
Date:   Thu Apr 21 12:44:36 2011 +

Introduce lUlong64  to fix wrong vmem reporting on 64-bit GNU/Linux
(from Univa)


from http://arc.liv.ac.uk/repos/git/sge

combined with a minor change for backporting to 6.2u5-7.1

--- a/gridengine_add64bit_support.patch 2013-06-05 14:24:17.415377163 +0200
+++ b/gridengine_add64bit_support.patch 2013-06-05 15:15:59.137610718 +0200
@@ -366,7 +366,7 @@
 +   if (pos  0) {
 +  /* someone has called lGetPosUlong64() */
 +  /* makro with an invalid nm*/
-+  CRITICAL((SGE_EVENT, SFNMAX,
MSG_CULL_GETPOSULONG64_GOTINVALIDPOSITION ));
++  CRITICAL((SGE_EVENT, MSG_CULL_GETPOSULONG64_GOTINVALIDPOSITION ));
 +  DEXIT;
 +  abort();
 +   }





I've tested the patch using this procedure:

On wheezy machine, I downloaded the source package of gridengine 6.2u5-7.1

   apt-get -b source gridengine

Then applied the attached patch to the extracted source, and rebuild the
package in the following way:

   dpkg-buildpackage -rfakeroot -uc -b


and it builds cleanly and can be installed.








diff --git a/source/common/basis_types.h b/source/common/basis_types.h
index aa4fb28..12d21f3 100644
--- a/source/common/basis_types.h
+++ b/source/common/basis_types.h
@@ -30,6 +30,7 @@
  *   All Rights Reserved.
  * 
  /
+/* Portions of this code are Copyright (c) 2011 Univa Corporation. */
 /*___INFO__MARK_END__*/
 
 #include sys/types.h
@@ -122,17 +123,29 @@ extern C {
 #  define u_long32 u_long
 #endif
 
+#if defined(TARGET_64BIT)
+#  define u_long64 u_long
+#elif defined(WIN32NATIVE)
+#  define u_long64 unsigned long long
+#elif defined(FREEBSD) || defined(NETBSD)
+#  define u_long64 uint64_t
+#else
+#  define u_long64 unsigned long long
+#endif
+
 #define U_LONG32_MAX 4294967295UL
 #define LONG32_MAX   2147483647
 
 /* set sge_u32 and sge_x32 for 64 or 32 bit machines */
 /* sge_uu32 for strictly unsigned, not nice, but did I use %d for an unsigned? */
 #if defined(TARGET_64BIT) || defined(FREEBSD) || defined(NETBSD)
+#  define sge_u64%ld
 #  define sge_u32%d
 #  define sge_uu32   %u
 #  define sge_x32%x
 #  define sge_fu32   d
 #else
+#  define sge_u64%lld
 #  define sge_u32%ld
 #  define sge_uu32   %lu
 #  define sge_x32%lx
diff --git a/source/daemons/common/procfs.c b/source/daemons/common/procfs.c
index f78513a..6882ca5 100644
--- a/source/daemons/common/procfs.c
+++ b/source/daemons/common/procfs.c
@@ -28,6 +28,7 @@
  *   All Rights Reserved.
  * 
  /
+/* Portions of this code are Copyright (c) 2011 Univa Corporation. */
 /*___INFO__MARK_END__*/
 #if !defined(COMPILE_DC)
 
@@ -554,7 +555,7 @@ time_t last_time
  
  lSetPosUlong(pr, pos_utime, utime);
  lSetPosUlong(pr, pos_stime, stime);
- lSetPosUlong(pr, pos_vsize, vsize);
+ lSetPosUlong64(pr, pos_vsize, vsize);
  
  close(fd);
   }
@@ -770,7 +771,7 @@ time_t last_time
proc_elem-proc.pd_stime  = ((double)lGetPosUlong(pr, pos_stime)) /
  sysconf(_SC_CLK_TCK);
/* could retrieve uid/gid using stat() on stat file */
-   proc_elem-vmem   = lGetPosUlong(pr, pos_vsize);
+   proc_elem-vmem   = lGetPosUlong64(pr, pos_vsize);
 
/*
 * I/O accounting
diff --git a/source/libs/cull/cull_db.c b/source/libs/cull/cull_db.c
index f848902..4bbd6b2 100644
--- a/source/libs/cull/cull_db.c
+++ b/source/libs/cull/cull_db.c
@@ -28,6 +28,7 @@
  *   All Rights Reserved.
  * 
  /
+/* Portions of this code are Copyright (c) 2011 Univa Corporation. */ 
 /*___INFO__MARK_END__*/
 #include stdio.h
 #include stdlib.h
@@ -383,6 +384,9 @@ lList *lJoin(const char *name, int nm0, const lList *lp0,
 case lUlongT:
needed = (ep0-cont[lp0_pos].ul == ep1-cont[lp1_pos].ul);
break;
+case lUlong64T:
+   needed = (ep0-cont[lp0_pos].ul64 == ep1-cont[lp1_pos].ul64);
+   break;
 case lStringT:
needed = !strcmp(ep0-cont[lp0_pos].str, ep1-cont[lp1_pos].str);
break;
diff --git a/source/libs/cull/cull_dump_scan.c b/source/libs/cull/cull_dump_scan.c
index 95472bb..2df8af7 100644
--- a/source/libs/cull/cull_dump_scan.c
+++ b/source/libs/cull/cull_dump_scan.c
@@ -28,6 +28,7 @@
  *   All Rights Reserved.
  * 
  /
+/* Portions of this code are Copyright (c) 2011 Univa Corporation. */
 /*___INFO__MARK_END__*/
 #include stdio.h
 #include stdlib.h
@@ -63,6 +64,7 @@ static int fGetKet(FILE *fp);
 static int fGetDescr(FILE *fp, lDescr *dp);
 static int fGetInt(FILE *fp, 

Bug#701246: biosig4c++: ftbfs with GCC-4.8

[Alois Schloegl]

The same bug has been already reported against liboctave-dev
   http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=705485
This bug report can be merged.


  Alois


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#701246: debian bugreport in biosig4c++: ftbfs with GCC-4.8

[Alois Schloegl]

 In file included from /usr/include/octave-3.6.2/octave/mexproto.h:52:0,
  from /usr/include/octave-3.6.2/octave/mex.h:77,
  from mexSLOAD.cpp:15:
 /usr/include/c++/4.8/cstdlib: In function 'long long int std::abs(long long 
 int)':
 /usr/include/c++/4.8/cstdlib:174:20: error: declaration of C function 'long 
 long int std::abs(long long int)' conflicts with
abs(long long __x) { return __builtin_llabs (__x); }


The files /usr/include/octave-3.6.2/octave/mexproto.h and
/usr/include/octave-3.6.2/octave/mex.h are not part of biosig4c++ but
from octave.
Therefore, this bug report should be assigned to octave (not biosig4c++).

  Alois


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#703591: pdftk - support for AES encrypted pdf files missing

[Alois Schloegl]

Package: pdftk

Version: 1.44-7

Severity: Wishlist


I got an pdf file that could not be opened with pdftk.

pdftk /tmp/q.pdf data_dump
Error: Failed to open PDF file:
   /tmp/q.pdf
Done.  Input errors, so no output created.

Unfortunately, the file contains personal information, so I can not
share it.

The same pdf can be opened with evince and okular (without needing a
password).


Investigating the issue, I found this site:
http://www.thbimage.com/pdf/pdftk_can_t_open_pdf_file_gnr2sr_5lv_1_news_motzarella_org_.html

It describes the same problem, and my file contains also this sequence
.../StrF/StdCF/CF/StdCF/CFM/AESV2/AuthEvent/DocOpen/Length
16/StmF/StdCF/U
indicating an AES encryption.

The error message is different than in
  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=454140
so it's a different bug.

The workaround is, opening the file with okular and printing it to a new
pdf file.
However, it would be great if pdftk could also handle AES encrypted pdf
files in seamless way.


   Alois


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#698286: incorrect value for max vmem is reported

[Alois Schloegl]

Package: gridengine*

Version: 6.2u5-1


When a job has finished, the max vmem value as it was actually used is
reported to the user.
Unfortunately, the reported value is never larger than 4G also the
application has clearly used more than 4G of Memory.
I've been testing this with Octave as well as mathematica.

Based on some preliminary tests, it seems that the reported value is the
(real value module 2^32). Thus, if more then 4G of vmem are used, the
reported maxvmem value is meaningless.

attached are:

- an Octave sample script, allocating 600M of random double precision
numbers resulting in 4.8GB memory need.
- the script for submission to the grid engine
qsub memtest03.m

The e.mail report contains this:
Job 4709696 (MEMTEST02) Complete
 User = schloegl
 Queue= mai...@nick13.ista.local
 Host = nick13.ista.local
 Start Time   = 01/16/2013 11:19:11
 End Time = 01/16/2013 11:19:36
 User Time= 00:00:23
 System Time  = 00:00:02
 Wallclock Time   = 00:00:25
 CPU  = 00:00:25
 Max vmem = 710.246M
 Exit Status  = 0


The correct value of Max vmem should be 4.47GB or more. But its close
to mod(8*6e8,2^32)=505032704 (this is plausible when we assume 200MB
overhead by Octave).


maxvmem is an important variable of optimizing the use of a cluster.
Users can control how much memory is is required, which is then used by
the grid engine for scheduleing. For this reason, its important that a
meaningful value for maxvmem is reported. Therefore I suggest a severity
level important.


Severity: important


Alois






% Octave script 
clear
x=randn(6e8,1);

size(x)
whos
exit


memtest03.sh
Description: Bourne shell script

Bug#631831: [Pkg-octave-devel] Bug#631831: Bug#631831: build octave with --enable-openmp

[Alois Schloegl]

On 06/30/11 04:11, Jordi Gutiérrez Hermoso wrote:

On 29 June 2011 18:54,schlo...@ist.ac.at  wrote:

On Tue, Jun 28, 2011 at 09:03:32AM +0200, Alois Schloegl wrote:

adding -lgomp to  mkoctfile call does not do it. And I've not found
any another option to enable openmp at this stage.


Did you pass -fopenmp to the compiler?

   Thomas




I tried, but mkoctfile does not accept -fopenmp

$ mkoctfile --mex -fopenmp covm_mex.cpp  -lz -lgomp
mkoctfile: unrecognized argument -fopenmp


Pass it as an environment variable:

  CXXFLAGS=-O2 -fopenmp mkoctifle --mex covm_mex.cpp -lz -lgomp

Does that work?



Jordi,

thanks for the hint. I tried this too, as well as

CFLAGS=-g -O2 -pthread -fopenmp mkoctfile-3.2.4 --mex covm_mex.cpp 
-lz -lgomp


CXXFLAGS=-g -O2 -pthread -fopenmp mkoctfile-3.2.4 --mex covm_mex.cpp 
-lz -lgomp


In none of these case, more than one CPU core was used. The ratio 
between cputime() and wall time toc() was always close to 1, and also 
top showed only 100 % cpu usage at most; with openmp enabled, I saw up 
to 1200% at the 12 core machine.



   Alois







--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#631831: [Pkg-octave-devel] Bug#631831: build octave with --enable-openmp

[Alois Schloegl]

On 06/27/11 20:23, Thomas Weber wrote:

Hi Alois,

On Mon, Jun 27, 2011 at 05:30:18PM +0200, Alois Schloegl wrote:


Package: octave3.2
Severity: wishlist

Octave should be configured with --enable-openmp. This would enable
the use of multiple cpus.
https://mailman.cae.wisc.edu/pipermail/octave-maintainers/2011-May/023838.html


Is it really needed to build Octave with OpenMP support or just
octave-nan?

Thomas



adding -lgomp to  mkoctfile call does not do it. And I've not found  any 
another option to enable openmp at this stage.


If Octave is not built with --enable-openmp, the mex-files in octave-nan 
are not built with openmp enabled.



  Alois




--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#611070: Package: installation-reports

[Alois Schloegl]

Package: installation-reports

Boot method: CD
Image version: 
http://cdimage.debian.org/cdimage/daily-builds/daily/arch-latest/i386/iso-cd/

Date: Jan 25 2011 10:00-11:00 CET GMT+1

Machine: Asus EeePC 1008PGO
Processor: Atom N450
Memory: 1 GB
Partitions: df -Tl will do; the raw partition table is preferred
[default settings, single partition]
# df -Tl
FilesystemType   1K-blocks  Used Available Use% Mounted on
/dev/sda1 ext3   238395008   3926224 222359012   2% /
tmpfstmpfs  512408 0512408   0% /lib/init/rw
udev tmpfs  508060   232507828   1% /dev
tmpfstmpfs  512408 0512408   0% /dev/shm

Output of lspci -knn (or lspci -nn):
# lspci -knn
00:00.0 Host bridge [0600]: Intel Corporation N10 Family DMI Bridge 
[8086:a010]

Subsystem: ASUSTeK Computer Inc. Device [1043:83ac]
Kernel driver in use: agpgart-intel
00:02.0 VGA compatible controller [0300]: Intel Corporation N10 Family 
Integrated Graphics Controller [8086:a011]

Subsystem: ASUSTeK Computer Inc. Device [1043:83ac]
Kernel driver in use: i915
00:02.1 Display controller [0380]: Intel Corporation N10 Family 
Integrated Graphics Controller [8086:a012]

Subsystem: ASUSTeK Computer Inc. Device [1043:83ac]
00:1b.0 Audio device [0403]: Intel Corporation N10/ICH 7 Family High 
Definition Audio Controller [8086:27d8] (rev 02)

Subsystem: ASUSTeK Computer Inc. Device [1043:8398]
Kernel driver in use: HDA Intel
00:1c.0 PCI bridge [0604]: Intel Corporation N10/ICH 7 Family PCI 
Express Port 1 [8086:27d0] (rev 02)

Kernel driver in use: pcieport
00:1c.2 PCI bridge [0604]: Intel Corporation N10/ICH 7 Family PCI 
Express Port 3 [8086:27d4] (rev 02)

Kernel driver in use: pcieport
00:1c.3 PCI bridge [0604]: Intel Corporation N10/ICH 7 Family PCI 
Express Port 4 [8086:27d6] (rev 02)

Kernel driver in use: pcieport
00:1d.0 USB Controller [0c03]: Intel Corporation N10/ICH 7 Family USB 
UHCI Controller #1 [8086:27c8] (rev 02)

Subsystem: ASUSTeK Computer Inc. Device [1043:83ad]
Kernel driver in use: uhci_hcd
00:1d.1 USB Controller [0c03]: Intel Corporation N10/ICH 7 Family USB 
UHCI Controller #2 [8086:27c9] (rev 02)

Subsystem: ASUSTeK Computer Inc. Device [1043:83ad]
Kernel driver in use: uhci_hcd
00:1d.2 USB Controller [0c03]: Intel Corporation N10/ICH 7 Family USB 
UHCI Controller #3 [8086:27ca] (rev 02)

Subsystem: ASUSTeK Computer Inc. Device [1043:83ad]
Kernel driver in use: uhci_hcd
00:1d.3 USB Controller [0c03]: Intel Corporation N10/ICH 7 Family USB 
UHCI Controller #4 [8086:27cb] (rev 02)

Subsystem: ASUSTeK Computer Inc. Device [1043:83ad]
Kernel driver in use: uhci_hcd
00:1d.7 USB Controller [0c03]: Intel Corporation N10/ICH 7 Family USB2 
EHCI Controller [8086:27cc] (rev 02)

Subsystem: ASUSTeK Computer Inc. Device [1043:83ad]
Kernel driver in use: ehci_hcd
00:1e.0 PCI bridge [0604]: Intel Corporation 82801 Mobile PCI Bridge 
[8086:2448] (rev e2)
00:1f.0 ISA bridge [0601]: Intel Corporation NM10 Family LPC Controller 
[8086:27bc] (rev 02)

Subsystem: ASUSTeK Computer Inc. Device [1043:83ad]
00:1f.2 SATA controller [0106]: Intel Corporation N10/ICH7 Family SATA 
AHCI Controller [8086:27c1] (rev 02)

Subsystem: ASUSTeK Computer Inc. Device [1043:83ad]
Kernel driver in use: ahci
01:00.0 Ethernet controller [0200]: Atheros Communications AR8132 Fast 
Ethernet [1969:1062] (rev c0)

Subsystem: ASUSTeK Computer Inc. Device [1043:838a]
Kernel driver in use: atl1c
02:00.0 Network controller [0280]: Atheros Communications Inc. AR9285 
Wireless Network Adapter (PCI-Express) [168c:002b] (rev 01)

Subsystem: AzureWave Device [1a3b:1106]
Kernel driver in use: ath9k

Base System Installation Checklist:
[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it

Initial boot:   [O]
Detect network card:[O]
Configure network:  [O]
Detect CD:  [O]
Load installer modules: [O]
Detect hard drives: [O]
Partition hard drives:  [ ]
Install base system:[O]
Clock/timezone setup:   [O]
User/password setup:[O]
Install tasks:  [O]
Install boot loader:[O]
Overall install:[O]

Comments/Problems:
No Problems

Description of the install, in prose, and any thoughts, comments
  and ideas you had during the initial install.



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

[Alois Schloegl]

 Original-Nachricht 
Datum: Mon, 16 Apr 2007 21:38:12 +0200
Von: Thomas Weber [EMAIL PROTECTED]
An: Alois Schloegl [EMAIL PROTECTED], [EMAIL PROTECTED]
Betreff: Re: [Pkg-octave-devel] Bug#419556: ambigous results in matrix 
multipliication

 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?

Actually, it was the same machine that I used for compiling Octave with Atlas. 
So atlas-base-dev (which requires also atlas-base) was installed when I tested 
Octave 2.9.10-3.


 
 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

IMHO, this is a bug (and not a feature) of dgemm. Especially, because (A*B)' is 
not the same as (B'*A'). 

octave:16 [nan nan]*[0;0]
ans = 0
octave:17 [0,0]*[nan nan]'
ans = NaN

octave:20 [0,0]*[inf inf]'
ans = NaN
octave:21 [inf inf]*[0;0]
ans = 0


 
  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.
 

Do you mean that installing atlas3-* besides the debian octave package solves 
the problem? I do not think so, because the machine I used had Atlas  installed.

If you mean, that atlas3-* should be installed when the Octave package is 
compiled for debian, yes I agree to that. Perhaps, the dependency between 
Octave and atlas-* need to be changed, such that atlas is mandatory instead of 
one of several alternatives. 


 Regards
   Thomas

Regards, 
   Alois 


-- 
Feel free - 10 GB Mailbox, 100 FreeSMS/Monat ...
Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#419556: ambigous results in matrix multipliication

[Alois Schloegl]

Package: Octave2.9
Status: install ok installed
Priority: optional
Section: math
Installed-Size: 26220
Maintainer: Debian Octave Group [EMAIL PROTECTED]
Architecture: i386
Version: 2.9.10-3
Severity: Important


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


octave2.9:27 repmat(0,2)*repmat(NaN,2)
ans =

   NaN   NaN
   NaN   NaN

octave2.9:28 repmat(NaN,2)*repmat(0,2)
ans =

   0   0
   0   0

octave2.9:29 repmat(0,2)*repmat(inf,2)
ans =

   NaN   NaN
   NaN   NaN

octave2.9:30 repmat(inf,2)*repmat(0,2)
ans =

   0   0
   0   0

octave2.9:31 version
ans = 2.9.10
octave2.9:32 octave_config_info('BLAS_LIBS')
ans = -llapack-3 -lblas-3


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. The octae_config_info says

octave:64 version
ans = 2.9.10+
octave:65 octave_config_info('BLAS_LIBS')
ans = -llapack -lcblas -lf77blas -latlas



A related problem has been also discussed here and here
http://velveeta.che.wisc.edu/octave/lists/bug-octave/2001/104
http://velveeta.che.wisc.edu/octave/lists/bug-octave/2002/293
Obviously, it is not fixed for the debian package. 



Alois 



-- 
Feel free - 10 GB Mailbox, 100 FreeSMS/Monat ...
Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]